[00:00] <slangasek> Fix degenerate perspective due to collinear X and Z vanishing points and origin, which caused computing preimages of canvas points to not work.
[00:00] <slangasek> Now *that's* a changelog entry
[00:01] <jbf2> hi all
[00:01] <slangasek> jbf2: hello
[00:01] <Hobbsee> haha
[00:01] <jbf2> I got a bug assigned to me some time ago, and I just made a fix, now the big question is, do I change the "status" field in launchpad? :)
[00:02]  * Hobbsee wants launchpad to start sorting in random order, to show which ones she should look at
[00:02] <slangasek> jbf2: when you say you "made" a fix, what do you mean - it's fixed upstream, it's committed to a package VCS repository, it's uploaded?
[00:05] <jbf2> slangasek: the package (drscheme) is almost orphaned in debian, but a recent rebase (can I say that? :) in upstream made some init-scrips break/defunct, so I uploaded a debdiff to launchpad ... last time I did that someone assigned the bug to me .. :)
[00:05] <slangasek> "almost" orphaned, eh?
[00:05] <slangasek> I thought it's been orphaned at the end of every semester for the past 5 years...
[00:06] <jbf2> hehe
[00:06] <slangasek> well, so - if there's a diff uploaded to launchpad, the next step would be to subscribe ubuntu-universe-sponsors and mark the bug as *not* assigned to you
[00:07] <keescook> Hobbsee: thanks.  I'll ping them, they mentioned today they had finished the transitional packages.
[00:08] <Hobbsee> keescook: cool
[00:09] <jbf2> slangasek: asign to whom? ubuntu-universe-sponsors?
[00:09] <Hobbsee> jbf2: subscribe them.  see https://wiki.ubuntu.com/MOTU/Contributing
[00:10] <jbf2> Hobbsee: thx
[00:17] <slangasek> keescook: inkscape acked, go, go!
[00:17] <Hobbsee> hehe :)
[00:17]  * Hobbsee gives slangasek more work
[00:17]  * slangasek deftly dodges the approaching work
[00:17] <Hobbsee> you can't.  it's on your queue, and you don't want me doing it.
[00:18] <slangasek> where's your queue, so I can negate both halves of that sentence at once? :)
[00:19] <Hobbsee> slangasek: wlel, technically i'm still aprt of -archive.
[00:19] <keescook> slangasek: woot!  thank you muchly, sir!
[00:19] <Hobbsee> slangasek: so you *could* say i'ts my queue too.
[00:19] <slangasek> that's the spirit!
[00:19] <Hobbsee> slangasek: but you're paid for this.  i'm not.
[00:19] <Hobbsee> and i have uni stuff to do.
[00:20] <slangasek> well, there is that
[00:21] <Hobbsee> of course, if you *want* to do all my uni work, then i'll sync. but i'd need drescher access first :P
[00:21] <slangasek> heh
[00:21] <Hobbsee> and another bug to you.
[00:29] <jbf2> slangasek, Hobbsee: thanks for the hand-holding
[00:30] <jbf2> bye
[00:37] <TheMuso> asac: So far so good for network manager with ipw2100.
[00:38] <asac> TheMuso: wpa?
[00:38] <asac> TheMuso: or no encryption?
[00:39] <TheMuso> asac: WPA2.
[00:39] <asac> ok thanks
[00:39] <TheMuso> np
[00:39] <asac> TheMuso: can you test wep?
[00:39] <TheMuso> asac: Yep, give me 5.
[00:43] <TheMuso> asac: hrm ok it was WPA. I'll try WEP, and then try WPA2.
[00:46] <TheMuso> asac: Ok wep is good, only 64-bit atm, but I assume higher bitrates would also be ok. Can check if you like, now will do WPA2.
[00:48] <Hobbsee> doko: would it be a silly question if i asked why icedtea-java7-doc was effectively empty?
[00:48] <doko> Hobbsee: bug
[00:49] <doko> openjdk-6-doc is not empty
[00:49] <Hobbsee> doko: any ETA on it beign fixed?
[00:49] <doko> ^^
[00:52] <TheMuso> asac: Ok WPA2 is also good.
[00:53] <asac> TheMuso: thanks. that should be enough
[00:53] <TheMuso> np
[01:21] <protonchris> Any ubuntu main sponsors around?
[01:34]  * TheMuso sighs with satisfactino after working with an upstrea author to fix a bug found by stack smashing. :)
[01:35] <TheMuso> gah satisfaction
[02:15] <protonchris> LaserJock: Are you up for taking a look at a sync request and sponsoring it?
[02:16] <LaserJock> what's the app?
[02:16] <protonchris> https://bugs.launchpad.net/ubuntu/+source/libgda3/+bug/200292
[02:16] <ubotu> Launchpad bug 200292 in libgda3 "Sync libgda3_3.0.2-2 from debian unstable" [Undecided,Confirmed]
[02:17] <ScottK2> For a moment a read that as libyada and shuddered.
[02:18] <StevenK> Haha
[02:18] <protonchris> I haven't been forced to use yada ..... yet
[02:21] <protonchris> In general, how long does it take from an upload be available from the repositories?
[02:21] <StevenK> A few hours
[02:23] <protonchris> Hmm.  I had a package uploaded/sponsored 22 hours ago and I haven't seen it available on us.archive.ubuntu.com yet.
[02:23] <StevenK> It could be in NEW or so. What package/version?
[02:24] <protonchris> 2.9.82-0ubuntu1
[02:24] <protonchris> whoops.
[02:24] <protonchris> libgdamm3.0_2.9.82-0ubuntu1
[02:24] <protonchris> That is the source package.
[02:25] <StevenK>  hardy i386   Successfully built  (NEW)
[02:25] <StevenK> It's in binary NEW, so you have to wait for the archive admins to review it and approve it
[02:26] <protonchris> Ah.  Good to know.
[02:26] <protonchris> Thanks.
[02:26] <Frederick> folks which package is supposed to hold libmawt?
[02:27] <protonchris> Frederick: sun-java6-bin holds libmawt.so
[02:28] <Frederick> protonchris: thanks but I humbly think it doesnt :p
[02:28] <Frederick> my netbeans crashes Ive tried the fix but seems I dont have such lib
[02:30] <protonchris> Frederick: well, maybe that file is provided by more that one package :)
[02:34] <LaserJock> looks like iced-tea or the sun-java's have it
[02:45] <Hobbsee> ScottK2: you're evil.  now someone should package libyada.
[02:47] <ScottK2> Hobbsee: What would it do?
[02:49] <Hobbsee> ScottK2: rm -rf / in the postinst.
[02:49] <Hobbsee> with the appropriate force optoins.
[02:59] <ScottK2> Sounds about right.
[03:01] <ionstorm> latest hardy with latest libc update borked my system, I cannot boot nor chroot in, how can I chroot in?
[03:02] <RAOF> ionstorm: Since libc's borked you probably can't chroot in (because it'll be using the chroot's libc, which is borked).
[03:03] <RAOF> ionstorm: Option 2 might simply be to copy a known-good libc.so.whatever from your livecd to your real filesystem.  The nice thing is, it's really, really hard to break it more than it already is ;)
[03:05] <Amaranth> RAOF: so don't upgrade libc6 then? ;)
[03:05] <_MMA_> After spending the day on a clean install of Hardy, and just getting that update that ^^^ wasn't good to hear.
[03:06] <RAOF> Amaranth: Given that people have been kind enough to guinnie pig this for me, I'll be aptitude forbid-version'ing this libc tootsweet.
[03:11] <protonchris> LaserJock: I am going to step away for a bit.  Let me know if there is anything I need to do regarding my sync request.  Thanks.
[03:11] <LaserJock> protonchris: just ack'd it
[03:13] <protonchris> LaserJock: do I need to do anything other than wait?
[03:13] <LaserJock> nope, should be all good
[03:15] <protonchris> LaserJock: one last question. Do I need to do anything for my other package that is sitting in binary NEW?
[03:16] <LaserJock> nope
[03:16] <LaserJock> if it's in NEW it in the archive admins hands
[03:16] <protonchris> Thanks for all of your help
[03:16] <LaserJock> you might gently poke if it's nobody looks at it for a few days
[03:16] <LaserJock> s/it's//
[03:17] <protonchris> Thanks for the advice.  I am sure they are quite busy.
[05:45] <milli> Everything just blew up with latest package updates. :(   bug 201694.
[05:45] <ubotu> Launchpad bug 201694 in ubuntu "System crashed on the from the lastest update." [Undecided,New] https://launchpad.net/bugs/201694
[05:48] <RAOF> milli: #ubuntu+1 has links in the topic about what to do about your broken libc
[05:48] <StevenK> RAOF: Send scathing e-mail to ubuntu-devel-discuss?
[05:48] <RAOF> StevenK: Nah, that's already been done.  It'd just seem lame now :P
[05:49] <StevenK> Heh
[05:50] <milli> RAOF: ty
[05:54] <Mithrandir> StevenK: have you seen that bug?
[05:54] <Mithrandir> if it's correct, we should call elmo and get the update blocked.
[05:55] <Mithrandir> I'd rather not update my system and discover it blows up. :-P
[05:55] <superm1> Mithrandir, i saw it and so did minghua
[05:55] <superm1> and my system is going to blow up as soon as I reboot :)
[05:55] <RAOF> The magical incantation _should_ be "sudo aptitude forbid-version libc6=2.7-9ubuntu1" ;)
[05:56] <StevenK> Mithrandir: I've seen the bug in a new Hardy chroot
[05:56] <minghua> Mithrandir: Yes, I saw it.  It would be nice if the update can be blocked.
[05:57] <StevenK> Mithrandir: slangasek has also reproduced
[05:57] <Mithrandir> StevenK: do you want to wake elmo or should I?
[05:57] <Mithrandir> as for it seeming mean, he's asked us to do that when shit like this happens.
[05:58] <StevenK> Mithrandir: Go ahead
[06:08] <Mithrandir> ok, blocked in the DC.
[06:15] <minghua> Mithrandir: Thanks!  And thanks to elmo too, I assume.
[06:18] <compbrain> minghua: The update is blocked, afaict
[06:18] <compbrain> Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-i386_2.7-9ubuntu1_amd64.deb  403 Forbidden [IP: <IP_ADDRESS> 80]
[07:13] <dholbach> good morning
[07:17] <emgent> hyea :)
[08:34] <pitti> Good morning
[08:34] <seb128> hey hey pitti
[08:34] <emgent> heya pitti :)
[08:34] <Fujitsu> Hi pitti.
[08:34] <abogani> Hi Guys! I have just update my Hardy machine. All variants of the sudo commands (sudo -i, sudo -s , sudo command) abort with backtrace. It isn't possible use apt-get or simply reboot!
[08:35] <pitti> slangasek: samba FFe> sure, will look at it
[08:35] <Fujitsu> abogani: See #ubuntu+1.
[08:35] <Fujitsu> libc6 is broken.
[08:35] <Fujitsu> There is a link to a solution in there.
[08:36] <abogani> Fujitsu: Fiuuuu. Thanks for tip! Excuse for disturb! :-)
[08:38] <dholbach> we should add https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/201673 to the topic too
[08:38] <ubotu> Launchpad bug 201673 in glibc "Hardy: "invalid pointer: 0xb7ef4b70" no program will start." [Critical,Confirmed]
[08:39] <Fujitsu> dholbach: There's no +t here.
[08:41] <dholbach> hrm... chanserv won't give me op - can't fix it
[08:41] <soren> Funny... I was soooo close to convincing my wife to upgrade to hardy yesterday.
[08:42] <soren> dholbach: You can just change it, can't you?
[08:43] <Mithrandir> glibc, you mean?
[08:43] <dholbach> nghghghg, I knew it :)
[08:43] <seb128> oh glibc borkage
[08:43] <ln-> what releases are affected?
[08:43] <Mithrandir> hardy
[08:43] <seb128> thanks to whoever blocked the deb on the server
[08:43] <seb128> I would have updated otherwise
[08:43] <dholbach> gra
[08:43] <Mithrandir> seb128: his name is elmo and his uid is 0.
[08:44] <pitti> ah, I just wondered about the Forbidden: messages from apt
[08:44] <seb128> Mithrandir: ;-)
[08:44] <dholbach> can somebody fix the topic? somehow xchat-gnome does not like it
[08:44] <pitti> looking
[08:44] <dholbach> Archive: Feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | glibc broken: https://launchpad.net/bugs/201673
[08:44] <ubotu> Launchpad bug 201673 in glibc "Hardy: "invalid pointer: 0xb7ef4b70" no program will start." [Critical,Confirmed]
[08:44] <dholbach> something like that
[08:44] <pitti> ok, you beat me to it
[08:45] <dholbach> gracias
[08:45] <emgent> np :)
[08:45] <dholbach> xchat-gnome got a bit confused it seems - freenode gave me " application :Unknown command"
[08:45] <pitti> seb128: ah, libgnomeui is happy now, I'll do another give-back round if you don't mind?
[08:46] <seb128> pitti: sure
[08:50] <pitti> seb128: ok, give-back-from-hell started; there will likely be more fallouts, I'll just kick it again once this round built; sorry for the mail spam, but it's easiest that way IMHO
[08:52]  * pitti cleans up NBS too, that should make hardy_outdate.txt shorter
[08:53] <seb128> pitti: no problem, mails are easy to filter
[08:53] <pitti> seb128: I'd say, just delete all of the gnome FTBFS mails you got
[08:53] <pitti> seb128: we'll see them in outdate
[08:53] <seb128> alright
[08:53] <pitti> after a few rounds of give-back we'll see what's left
[09:47] <soren> slangasek: We should probably put up some semi-official instructions of how to recover.
[09:53] <seb128> pitti: any language pack update planned before beta?
[09:53] <seb128> pitti: now than GNOME 2.22 is in hardy we should update translations
[09:54] <pitti> seb128: they are automatically updated on Wednesdays and Sundays
[09:54] <pitti> seb128: so yesterday's should already have some bits
[09:54] <seb128> ok
[09:54] <pitti> seb128: the one from Sunday will be appropriate, I think?
[09:55] <seb128> should be yes
[09:55] <pitti> I create them two hours after LP exports them, so I can't be much faster than the cronjob
[09:55] <pitti> s/^I create/They are created/
[09:55]  * pitti pats his collection of "pitti does some work" scripts everywhere
[09:56] <pitti> seb128: btw, I looked at the retracers last night, seem to work now
[09:56] <seb128> pitti: yes, it was working after you left
[09:56] <seb128> I verified it retraced several bugs correctly
[09:56] <seb128> thanks again for fixing it
[09:57]  * seb128 hugs pitti
[09:57] <Tonio_> hi there
[09:57] <pitti> \o/
[09:57]  * pitti hugs seb128
[09:57] <pitti> hi Tonio_
[09:57] <Tonio_> can I install a debconf response file so that installing a new package via dist-upgrade goes silent ?
[09:58] <Tonio_> I know how to do that with FAI for example, but not on the desktop side
[09:58] <pitti> DEBCONF_PRIORITY=critical?
[09:58] <Tonio_> what will that do ?
[09:58] <pitti> it will only show critical questions, not 'high' priority ones
[09:59] <broonie> You can also get the relevant db_sets run prior to installing the package which will do the preseeding.
[09:59] <Tonio_> hum interesting
[09:59] <broonie> There's no namespace enforcement.
[10:01] <ogra_cmpc> pitti, could you take a look at bug #201536 ? any chance to get that in still ? stgraber is very confident it solves a lot of issues for us and given that he works extemly close with upstream to get all ubuntu changes in i think we should take the update
[10:01] <ubotu> Launchpad bug 201536 in italc "FF exception, new release of iTalc (1.0.7)" [Undecided,New] https://launchpad.net/bugs/201536
[10:01] <Tonio_> pitti: putting this in /etc/environment could help ?
[10:02] <pitti> Tonio_: preseeding might be more what you want; depends on your use cases, but in general we don't have a lot of debconf questions
[10:02] <Tonio_> pitti: that's for work, we have to replace sendmail by postfix silently
[10:02] <pitti> Tonio_: and sometimes dpkg asks about conffiles, etc., so getting the dist-upgrade completely automatic is not really recommended at least for hardy (development releasese)
[10:02] <Tonio_> I don't wan't to repackage postfix removing the debconf stuff
[10:02] <ogra_cmpc> Tonio_, sounds like you would also want DEBCONF_FRONTEND=noniteractive
[10:02] <pitti> ^ that's better in this case, yes
[10:03] <Tonio_> ogra_cmpc: hu mcould be this, yes
[10:03] <Tonio_> ogra_cmpc: simply export it and that's okay ?
[10:03] <cjwatson> soren: I think slangasek has gone to bed; do you have suitable instructions handy?
[10:03] <ogra_cmpc> well, you should preseed values for debconf if you dont want the package defaults
[10:04] <ogra_cmpc> but yes, simply exporting it before you run the package manager should be enough
[10:04] <Tonio_> ogra_cmpc: simply use defaults in that case, so no need to do it, but if you know how to proceed, that would be nice
[10:04] <Tonio_> ogra_cmpc: how to preseed values ?
[10:04] <Tonio_> on the client side, that's what I don't know in fact :)
[10:07] <soren> cjwatson: Not in any publishable form, no.
[10:07] <pitti> ogra_cmpc: ah, looking; (1) the [] are comments from you, right? (2) you shold actually subscribe ~ubuntu-release for FF exceptions :)
[10:08]  * cjwatson looks up #ubuntu+1 which apparently has held instructions on recovery
[10:08] <ogra_cmpc> pitti, ... wollte erst die lage sondiern :)
[10:08] <soren> cjwatson: I think there's something that's almost usable in the bug report (booting the live cd and doing dpkg --root or something, but I haven't tried it myself (as I was lucky enough to be lazy enough to not have updated this morning)).
[10:08] <Tonio_> ogra_cmpc: doesn't seem to work for me.... exporting doesn't change anything...
[10:08] <cjwatson> (I'm following DWCIU, in case that isn't obvious)
[10:08] <Tonio_> doesn't apt overrides the variable value ?
[10:09] <ogra_cmpc> Tonio_, DEBCONF_FRONTEND=noniteractive apt-get install blah
[10:09] <ogra_cmpc> that way it should work ...
[10:09] <pitti> ogra_cmpc: replied
[10:09] <ogra_cmpc> but exporting shoud as well, weird
[10:09] <Tonio_> ogra_cmpc: yes, but no, it doesn't :)
[10:09] <ogra_cmpc> pitti, thanks
[10:09] <mjg59> keescook: Not yet - still need to make it work. Just realised a subtle aspect that makes this all much harder
[10:10] <Tonio_> ogra_cmpc: I just tried with postfix, I'm still questionned
[10:11] <mjg59> keescook: The remaining issue is that there might be reads from the video ROM, and x86 doesn't let us separate readable and executable pages properly
[10:11] <mjg59> Except possibly with nx, but still
[10:15] <pitti> seb128: hm, is deskbar-applet still broken for you as well? I only see web searches, none of the other plugins (like devhelp)
[10:15] <seb128> pitti: yes
[10:15] <seb128> pitti: we will remove it for hardy
[10:16] <pitti> you mean deskbar?
[10:16] <pitti> erk, I now re-enabled some modules (devhelp, dict) and now it hangs
[10:18] <foka_> join #ubuntu-devel
[10:18] <foka_> Argh!  Oops, sorry...
[10:19] <pitti> but you are already here :)
[10:19] <emgent> ehehe
[10:19] <ogra_cmpc> impatience :)
[10:19] <foka_> Hehe, sorry.  I blame XChat for eating my key.  :-D
[10:22] <Tonio_> ogra_cmpc: interesting, it works if I dpkg-reconfigure debconf, but but setting the env variable..... I suspect there is a bug in there :)
[10:24] <ogra_cmpc> there are different veriables for the same purpose, might be that you need DEBIAN_FRONTEND here, try that
[10:26] <cjwatson> pitti: interestingly, I have reproduced mathiaz's postgresql installation problem; this kvm d-i run has a mode 0660 /dev/null
[10:27] <pitti> cjwatson: heh, new security feature?
[10:27] <pitti> preventing wearout of /dev/null
[10:27] <ion_> Heh
[10:29] <cjwatson> heh
[10:29] <cjwatson> I'll try to figure out at what stage it's happening, though only in the background since I'm dealing with the glibc thing
[10:36] <dholbach> Riddell: do you think somebody could update the kubuntu-leaflet in example-content to say 8.04 instead of 6.06?
[10:36] <emgent> glibc 2.7.9ubuntu2 FTBFS ? https://edge.launchpad.net/ubuntu/+source/glibc/2.7-9ubuntu2
[10:38] <mdz> asac: I just had firefox crash on a "Save link as..." while the gtk file save dialog was still loading.  unfortunately, apport wasn't able to save a core dump, and I tried again on the same link but it works
[10:40] <Riddell> dholbach: hmm, it would need the source from kwwii
[10:40] <ion_> Is there going to be a default configuration for ufw in hardy, or why is it installed by default?
[10:41] <dholbach> Riddell: that'd be nice
[10:42] <pitti> ion_: I don't know about jdstrand's plan, but I wouldn't think so
[10:42] <cjwatson> emgent: we know, we're dealing with it
[10:42] <pitti> ion_: if we wouldn't want a port being open by default, we wouldn't open it in the first place
[10:42] <ion_> Indeed. :-)
[10:42] <pitti> ion_: and we still ship with no open TCP ports by default (just the usual DNS/avahi UDP ones)
[10:42] <emgent> cjwatson: cool
[10:49] <asac> mdz: ok. thanks anyway.
[10:51] <mdz> asac: if you have any guesses about how I might try to trigger it further, or hear other reports, let me know
[10:52] <asac> mdz: sure .... but most likely a follow-up of something. there are still plenty of crashes getting fixed every day.
[10:52] <ogra_cmpc> asac, when is beta4 due (i'm eager to test the memory management improvements on teh cmpc)
[10:53] <Wartorn> i just noticed the e: lib6: subprocess error, what should i do?
[10:53] <asac> ogra_cmpc: we have a regression in epiphany which holds back the release.
[10:53] <ogra_cmpc> gah
[10:53] <asac> ogra_cmpc: otherwise the package is ready
[10:53] <asac> ogra_cmpc: currently performing a binary search respin to track down the bad commit
[10:53] <asac> cannot give an ETA though
[10:54] <ogra_cmpc> yeah understood
[10:58] <asac> pitti: how can it happen that there is no core dump created on crash?
[10:59] <pitti> asac: /var/log/apport.log usually tells
[10:59] <mdz> asac: it said there was not enough free memory
[10:59] <asac> oh. ok
[10:59] <mdz> not sure what that means, as I thought it streamed the core dump out to disk
[10:59] <mdz> pitti?
[10:59] <pitti> various reasons: the app has its own signal handler, or the core dump is too large
[11:00] <asac> too large in which regards? ulimit?
[11:00] <pitti> /etc/default/apport
[11:00] <pitti> # set maximum core dump file size (default: 209715200 bytes == 200 MB)
[11:00] <pitti> maxsize=209715200
[11:01] <pitti> they are also capped on available memory size, since processing them takes ages and swaps (we got tons of complaints about this)
[11:01] <Fujitsu> Hm, so lpia won't be official for Hardy?
[11:07] <jdstrand> ion_: ufw is installed by default as it's in the standard seed. it does have a default configuration when enabled, and works quite well as a host-based firewall after performing 'sudo ufw enable'
[11:07] <jdstrand> ion_: since having a 'default on' firewall would break things in non-obvious ways, it comes off by default, and is something users have to explicitly enable
[11:08] <jdstrand> pitti: ^^
[11:08] <ion_> k
[11:08] <ion_> Ok, that is.
[11:10] <zul> pitti: hi, I just uploaded the new version of samba-3.0.28a
[11:13] <\sh> oh well...good to know that glibc behaves like wine with introduced LDFLAGS ;)
[11:13] <Wartorn> what should i do? my update manager seems to have crashed, and i cant open the link in the topic
[11:13] <pitti> zul: ah, great
[11:59] <sabdfl> cjwatson: morning, thanks for your comments on #201673, makes me reassured
[12:00] <sabdfl> since i don't have a Live CD handy and nothing is working :-P
[12:01] <cjwatson> sabdfl: I'm preparing recovery notes now; see http://paste.ubuntu.com/5653/
[12:01] <cjwatson> if you have a root password set and haven't rebooted, you can recover on the spot, though a reboot would then be advisable
[12:02] <cjwatson> I haven't tested these yet though - am working on getting a spare system upgraded to the point where it exhibits the bug
[12:02] <cjwatson> there is a cunning trick from Keybuk to recover even without a live CD, though I'm a little hesitant to recommend it in general since it depends on exactly when you upgraded from
[12:04] <sabdfl> cjwatson: su b0rks for me too
[12:05] <cjwatson> sigh, somebody said that worked
[12:05] <cjwatson> yes, breaks in my chroot too
[12:06] <sabdfl> both sudo and su seem borked
[12:06] <Hobbsee> development releases and testing...
[12:06] <ogra_cmpc> init=/bin/bash ?
[12:06] <sabdfl> i have the .deb, though
[12:06] <cjwatson> ok, Keybuk's trick is to boot with break=mount, then 'cp /lib/libc.so.6 /root/lib/libc-2.7.so'
[12:07] <Keybuk> ogra_cmpc: bash will crash too
[12:07] <cjwatson> (init=/bin/dash works)
[12:07] <ogra_cmpc> dash then ?
[12:07] <sabdfl> dash seems to work
[12:07] <sabdfl> reboot to init=/bin/dash, then dpkg -i the .deb?
[12:07] <Keybuk> cjwatson: for a fully forked trick, it'd have to be
[12:07] <cjwatson> the break=mount trick works provided that the initramfs hasn't been regenerated since the break
[12:07] <Keybuk>   break=bottom
[12:07] <Fujitsu> cjwatson: Couldn't one ar and tar stuff out of an old deb which is likely present in /var/cache/apt/archives?
[12:07] <Keybuk>   mount -o rw,remount /root
[12:07] <Keybuk> then the cp
[12:07] <cjwatson> Fujitsu: why ar and tar when dpkg works fine?
[12:08] <Fujitsu> Does it? I presumed otherwise.
[12:08] <Keybuk> (I broke at mount and mounted it manually rw, but that's more hard-code than it needed to be - I just wasn't sure how much was broken)
[12:08] <cjwatson> Fujitsu: tested
[12:08] <Fujitsu> Ah, good.
[12:08] <cjwatson> sabdfl: yes, that will work
[12:09] <Keybuk> sabdfl: if you init=/bin/dash - you will need to mount -o rw,remount /
[12:09] <cjwatson> doh, yes
[12:11] <pitti> Keybuk: btw, didn't we complain about the absence of OMGKITTENSDIE bugs just yesterday on the phone? :)
[12:12] <asac> anyone here with ath_pci or hostap wifi?
[12:13] <soren> asac: Yes.
[12:13] <asac> soren: which?
[12:13] <asac> soren: do you run network manager?
[12:13] <soren> ath_pci
[12:13] <soren> Yes.
[12:14] <asac> 0.6.6?
[12:14] <soren> It's on my old laptop which is not up-to-date. I can fire it up and update if you want me to?
[12:14] <asac> soren: please do
[12:14] <asac> have to figure if we still need driver tweaks for it
[12:14] <soren> asac: Alright. It'll be a while :)
[12:14] <asac> trying to get input from bugs is just ... aehm ... cumbersome
[12:14] <asac> :)
[12:14] <soren> I feel your pain :)
[12:19] <sabdfl> so, to be certain:
[12:19] <sabdfl> reboot
[12:19] <sabdfl> at the grub menu, add init=/bin/dash to the kernel boot command
[12:19] <sabdfl> when at the root prompt
[12:20] <sabdfl> mount -o rw,remount /
[12:20] <sabdfl> dpkg -i /path/to/working/libc.deb
[12:20] <sabdfl> right?
[12:20] <cjwatson> note that (I am told) you will not see the root prompt when booting with init=/bin/dash due to some fuckedness somewhere; wait for a bit and type 'ls' to confirm the system's up
[12:20] <cjwatson> but otherwise that's right
[12:25] <ogra_cmpc> there he goes
[12:26] <Keybuk> pitti: yes ...
[12:27] <Keybuk> I was right, the phone call was too early for them to show up
[12:27] <Keybuk> a few hours too early ;)
[12:30] <cjwatson> oops, now everything segfaults
[12:31] <cjwatson> I guess gutsy's libc doesn't work so well for that trick
[12:33] <ogra_cmpc> Keybuk, did you bribe doko secretly to develop a proof of concept ?
[12:36] <Keybuk> we should just be glad we didn't get a libc security update, and find out after hardy was released :)
[12:36] <ogra_cmpc>  yeah
[12:38] <Fujitsu> Keybuk: You can be sure that a security update for something else will cause similar breakage due to that LDFLAGS change.
[12:39] <Wartorn> how can i fix the libc thing? i cant seem to update anymore, gotta format?
[12:39] <ogra_cmpc> Wartorn, see /topic
[12:41] <Pici> Wartorn: #ubuntu+1 is probably the place you want to be :)
[12:41] <cjwatson> Wartorn: I'm going to be posting semi-official workaround instructions as soon as I've got them tested
[12:41] <cjwatson> I will post them to the bug URL in the topic
[12:43] <Pici> cjwatson: Do you mind pinging me or another op  when you do so? So that the link can be added to the topic in #ubuntu+1?
[12:47] <Wartorn> thing is, i cant open firefox anymore
[12:49] <ogra_cmpc> Wartorn, w3m is installed by default ... you can use it from the commandline
[12:54] <slytherin> dholbach: I am trying to fix evolution-scalix package. I am patching configure.in. How do I generate configure script in build process?
[12:54] <slytherin> oops, wrong channel
[12:55] <seb128> asac: do we have any firefox bookmarks customization?
[12:55] <seb128> slytherin: don't, create a autoconf patch rather
[12:55] <seb128> slytherin: cdbs-edit-patch 99_autoconf_update; autoconf; rm -rf autom4te.cache; exit
[12:56] <slytherin> seb128: Ok. I will continue discussion with dholbach in #ubuntu-motu. :-)
[12:56] <dholbach> slytherin: I'm about to leave for a dogwalk
[12:56] <dholbach> slytherin: I recommend seb128's approach
[12:56] <asac> seb128: why?
[12:57] <seb128> asac: I want to do similar changes for epiphany and I could reuse the labels and urls you added for firefox if you did that
[12:57] <seb128> asac: https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/137491
[12:57] <ubotu> Launchpad bug 137491 in epiphany-browser "epiphany does not have launchpad customizations by default" [Wishlist,Triaged]
[12:57] <asac> i still have them ... but that might be from the old profile
[12:57] <asac> let me look
[12:57] <seb128> asac: I though it would be in ubufox but it doesn't seem to be there
[13:01] <asac> seb128: yes. we had patched that in ffox 2... i didn't move that to ubufox yet
[13:01] <asac> seb128: but its not even decided what to put there afaik
[13:01] <asac> seb128: anyway ... you could start firefox-2 and use the bookmarks.html created in your profile if you need something
[13:01] <asac> now
[13:02] <seb128> asac: ok, thanks
[13:08] <ogra_cmpc> oh sabdfl is alive
[13:08] <cjwatson> sabdfl: Keybuk and I figured out what was going on with dpkg; PATH wasn't set (or didn't contain /sbin and /usr/sbin), and stderr isn't set up properly in the initramfs
[13:09] <cjwatson> the advice I'm preparing for the bug report will not include using dpkg from the initramfs
[13:16] <sabdfl> that was an entertaining detour
[13:16] <sabdfl> thanks keybuk
[13:16] <sabdfl> and cjwatson
[13:16] <sabdfl> do we have any sort of download count on the number of people affected?
[13:17] <Fujitsu> From what I can tell, lots of people are still getting it from mirrors.
[13:17] <emgent> if mirror count download i think yes
[13:17] <cjwatson> probably not a terribly accurate one since most will be mirrors
[13:17] <cjwatson> FWIW, fixed versions are publishing now
[13:18] <cjwatson> they should be available from archive.u.c within the hour
[13:18] <ogra_cmpc> yippie
[13:19] <ogra_cmpc> these are the days where i realize how much deboootstrap my work involves
[13:23] <sabdfl> can we pulse mirrors?
[13:23] <cjwatson> no point yet
[13:24] <cjwatson> but once it is published, we automatically pulse all of the ones that we can, AIUI
[13:24] <cjwatson> the ones that don't update rapidly are the ones where we don't have push-mirroring
[13:24] <cjwatson> I will be doing an incident report afterwards, although not a full-blown one since this is a pre-beta development release
[13:25] <Hobbsee> cjwatson: who would have figures on how many bad SRU's there have been, that have gone and broken things?
[13:25] <Hobbsee> as in, while still being tested
[13:25] <ogra_cmpc> do we move the freeze by one day ? i imagine that a lot of work couldnt be done today
[13:25] <Hobbsee> (and excluding security fixes, which don't go thru sru)
[13:27] <cjwatson> Hobbsee: there have been three stable updates serious enough to warrant internal incident reports
[13:28] <Hobbsee> cjwatson: how many of those were security?
[13:28] <cjwatson> two
[13:28] <Hobbsee> cjwatson: what was the other?
[13:28] <cjwatson> the infamous X update in 2006
[13:29] <cjwatson> I wouldn't try to infer anything from that division though - the sample size is far too small for it to be statistically valid
[13:30] <Hobbsee> cjwatson: oh.  i thought that was the first security one.
[13:31] <cjwatson> no, it was a regular update
[13:32] <Hobbsee> ah
[13:33] <Hobbsee> cjwatson: thanks.  was just curious
[13:42] <juliank> Could version 0.6-0ubuntu3 of ndisgtk be removed from the archive? ndisgtk is now Architectures: i386, amd64 (changed in Debian, because it depends on packages only available on these platforms) - this old Architecture: all version is still in the archive.
[13:45] <ogra_cmpc> juliank, oh, why/how did the code change ? last time i looked it was pygtk ... did they port it to C ?
[13:46] <ogra_cmpc> i wouoldnt restrict it to two arches only if there are chances someone ports it for other driver installations etc
[13:47] <cjwatson> juliank: nobody's added it to Packages-arch-specific
[13:47] <juliank> ogra_cmpc: It's still Python, but it needs ndiswrapper which is only available on i386 and amd64. Windows drivers are only available for these architectures.
[13:48] <cjwatson> ogra_cmpc: it depends on ndiswrapper-utils-1.9 which is in P-a-s
[13:48] <cjwatson> juliank: could you please mail one of the addresses listed at the top of http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.738&root=dak&view=markup to get this corrected
[13:48] <cjwatson> ?
[13:49] <ogra_cmpc> juliank, its a frontend gui that could easily operate with xyzwrapper for sparc for example...
[13:49] <juliank> cjwatson: I did this a long time ago. In Debian, the old "all" package is removed, only i386 and amd64 packages are left.
[13:49] <cjwatson> juliank: if you did, it has not been applied
[13:49] <cjwatson> juliank: so I would advise doing so again
[13:50] <cjwatson> juliank: I've removed it from hardy, although until P-a-s is changed it may well try to build again
[13:54] <juliank> cjwatson: I also noted ndisgtk in my email "Adding Install-Architecture to debian/control" http://lists.debian.org/debian-devel/2008/02/msg00045.html
[14:01] <Riddell> siretart: can you play dvds in hardy xine?
[14:07] <dholbach> thekorn: what do you think about       <pitti>  dholbach: if plpbugs now gets along with the ffox 3 cookies.db, then we should probably extend the heuristics to check for ~/.mozilla/*/*/cookies.sqlite first? and then fall back to s/sqlite/txt/?
[14:07] <pitti> dholbach: NB that this shouldn't be a default in p-lp-bugs itself
[14:08] <pitti> but in the apps using it
[14:08] <dholbach> pitti: oh, hm
[14:08] <thekorn> I agree with pitti
[14:09] <dholbach> to me it looks like we'll have that check in a lot of different places then
[14:09] <pitti> well, maybe we can put that function into p-lp-bugs
[14:09] <pitti> find_mozilla_cookie() or so
[14:09] <pitti> but it shouldn't be called by default in the library IMHO
[14:10] <pitti> since it's prone to use cookies you don't intend to use
[14:10] <dholbach> that makes sense to me
[14:10] <dholbach> of course
[14:21] <ion_> 2.7-9ubuntu2 seems to have hit archive.ubuntu.com
[14:22] <cjwatson> correct
[14:22] <cjwatson> I already updated the bug
[14:22] <cjwatson> I do wish my test system would upgrade more quickly so that I could post tested workaround instructions
[14:34] <cjwatson> pitti: is bug 197667 yours? seems to be talking about usplash-fsck integration problems
[14:34] <ubotu> Launchpad bug 197667 in usplash "problem with new display of FSCK" [Undecided,New] https://launchpad.net/bugs/197667
[14:35] <pitti> cjwatson: yes, it is; I assigned it to mow
[14:35] <pitti> me, even
[14:36] <asac> soren: any ETA till your laptop has been upgraded to latest?
[14:36]  * pitti hopes that fsck will output useful progress information for this case; otherwise we are quite doomed
[14:40] <soren> asac: I needed to wait until there was a usable libc6.. It's running now. I need to downgrade nm, though (I was using the one from your ppa that we tested at the sprint in London).
[14:40] <soren> The upgrade is running now, I mean.
[14:41] <ryanakca> Ummm. I'm getting this when running an upgrade http://pastebin.ca/941103 (403 Forbidden). Is that what the topic means by "glibc is broken" ?
[14:43] <asac> soren: thanks. remember to downgrade wpasupplicant as well
[14:44] <asac> soren:  but nm 0.7 worked right?
[14:45] <soren> asac: Well, I left it installed, so I'm guessing yes. :)
[14:45] <Riddell> pitti: how do I test jockey if I don't have any proprietry drivers needed?
[14:46] <asac> soren: intersting. ok lets see how hard 0.6.6 striked you
[14:46] <pitti> Riddell: check out the ubuntu branch and run jockey-kde -H examples/handlers/
[14:47] <pitti> Riddell: tests/run-qt will also show it
[14:47] <pitti> Riddell: speaking about jockey, do you know anyone who is interested in fixing some UI bugs in the qt implementation?
[14:48] <Riddell> pitti: I was going to take a quick look at the ones you e-mailed mhb
[14:49] <pitti> ah, great
[14:49] <ryanakca> pitti: What kind of UI bugs? I have the day off. Do they involve much coding, or just fireing up qt-designer?
[14:50] <pitti> ryanakca: stuff like "default column width is wrong", "icon missing", etc.
[14:50] <pitti> ryanakca: so it's some lightweight pyqt coding (maybe this can be fixed in the designer, too, not sure
[14:50]  * pitti <- pyqt noob
[14:50] <ryanakca> pitti: oh, I could probably do that if Riddell/mhb don't have dibs on it. I'm guessing all the bugs are under Launchpad?
[14:51] <ryanakca> pitti: me too :)
[14:51] <Riddell> ryanakca: I can forward you pitti's e-mail
[14:51] <pitti> ryanakca: some are
[14:51] <ryanakca> Riddell: please :)
[14:51] <pitti> right, that would be good, thanks
[14:51] <pitti> ryanakca: in general it should behave similar to the gtk implementation
[14:51] <ryanakca> pitti: I'll try to get through as many as I can :)
[14:51] <pitti> ryanakca: so if you could install both and get a feeling what's missing?
[14:51] <ryanakca> pitti: ok
[14:51] <ryanakca> yep
[14:51] <pitti> ryanakca: awesome, thank you
[14:51] <superm1> asac, did you still need some input on ath_pci with nm 0.6.6?
[14:52] <ryanakca> pitti: Cheers :)
[14:52] <lamont> slangasek: I wonder... if a package is ftbfs in feisty, and unchanged since feisty, can we justify nuking the binary from the archive for hardy?
[14:53] <cjwatson> excellent, working initramfs restore instructions
[14:53] <cjwatson> now I just need this live CD to finish booting so I can test that
[14:53] <\sh> now recreating all hardy chroots ... fun :)
[15:01] <Wartorn> When will the libc error be fixed?
[15:01] <ion_> It has been fixed.
[15:01] <asac> superm1: yes
[15:01] <superm1> asac, what are you looking for exactly regarding it?
[15:02] <asac> superm1: does it work for you (open network, WEP, WPA1/2)?
[15:02] <superm1> asac, it kinda works - i use wpa2 here.  it doesn't come up on boot consistently
[15:02] <Wartorn> okay, cause i cant seem to use update manager, nor can i open a terminal, cant even use one of the tty terminals
[15:02] <Wartorn> any solution other than formatting?
[15:02] <superm1> asac, i've got to retry picking the network a few times
[15:02] <superm1> but once it's up, it stays up
[15:03] <asac> superm1: can you open a bug for the "not automatically" connecting issue?
[15:03] <asac> and attach the complete syslog?
[15:03] <asac> superm1: and if possible, please aslo try WEP
[15:03] <asac> and maybe HIDDEN network
[15:03] <ogra_cmpc> Wartorn, detailed instructions will be attached to the bugreport
[15:03] <superm1> asac, sure.
[15:04] <asac> superm1: are you sure you are using wpasupplicant from hardy (and not the one i released for nm 0.7)?
[15:04] <superm1> as for the hidden network, i've got a hidden wep one in my appt too on my AP :)
[15:04] <asac> superm1: hmm bad combination as i don't know if either works :)
[15:04] <asac> superm1: if it works then its most likely fine :)
[15:04] <superm1> asac, i've not enable your network manager 0.7 PPA - so i shouldn't have wpasupplicant from it
[15:05] <asac> superm1: which version?
[15:05] <superm1> 0.6.0+0.5.8-0ubuntu2
[15:06] <asac> ok thats fine
[15:06] <ion_> wartorn: There are workarounds mentioned in the bug report (see topic).
[15:08] <asac> superm1: did you ever manage to connect to hidden network with ath_pci?
[15:08] <superm1> asac, well yes - but i should warn this hidden network is on the same AP, so same BSSID (just different ESSID)
[15:08] <superm1> asac, so it starts to act wonky on that hidden network
[15:10] <asac> interesting what kind of setups exist
[15:11] <superm1> asac, i had to set it up that way to make nintendo ds's work on my network without buying a second AP :)
[15:11] <asac> nintendo can only do WEP?
[15:11] <superm1> the DS can only do WEP, the wii can do wpa2
[15:13] <superm1> asac, bug 201828
[15:13] <ubotu> Launchpad bug 201828 in network-manager "ath_pci doesn't consistently connect on boot to WPA2" [Undecided,New] https://launchpad.net/bugs/201828
[15:14] <superm1> I'll be able to test the WEP after work, and get back to you on that.
[15:16] <superm1> asac, i'll be afk for most of the rest of the day, so is there anything else you'd like me to append to that bug before hand?
[15:16] <asac> superm1: let me see
[15:18] <asac> superm1: i only see a successful connect attempt
[15:18] <asac> maybe post at what time i can see the failed one
[15:18] <asac> superm1: are you really sure you are running the hardy supplicant ?
[15:18] <asac> there are messages i have only seen in 0.6
[15:18] <asac> anyway
[15:19] <superm1> asac, mar 13 at 1:26 or so
[15:19] <superm1> it doesn't get fully connected
[15:19] <superm1> so it tries again
[15:19] <twi_> hi
[15:20] <ogra_cmpc> hmm, i still cant debbootstrap, strange
[15:20] <asac> superm1: can you post that time in the bug?
[15:20] <superm1> asac, sure will do
[15:20] <asac> at best the start line in syslog
[15:20] <asac> thanks a lot
[15:21] <twi_> pitti hi, I work on elisa
[15:22] <twi_> pitti re https://bugs.launchpad.net/ubuntu/+source/elisa/+bug/186647/ tell me if you need help with the MIR or anything else
[15:22] <ubotu> Launchpad bug 186647 in pigment "promote to main" [Undecided,New]
[15:23] <ogra_cmpc> heh, not using a mirror helps
[15:24] <superm1> ogra_cmpc, i understand there were a few updates needed for the mythbuntu LTSP plugin from laga, did you ever get those in place?
[15:24] <ogra_cmpc> superm1, not all of them yet, i'm on it ... my prob was that i need working debootsrap to test them so it wqasnt possible this morning yet
[15:25] <ogra_cmpc> i'm going through the ltsp buglist asw we speak, lagas are among them
[15:25] <superm1> ogra_cmpc, okay great thanks. good luck getting a good debootsrap :)
[15:25] <ogra_cmpc> seems to work now
[15:26] <ogra_cmpc> i had forgotten that my apt-proxy pointed to a mirror where the new libc isnt in place yet
[15:26] <protonchris> Is there a way to see what is currently in the binary NEW queue?
[15:31] <ryanakca> pitti: is jockey in a bzr branch or do I patch the package directly?
[15:32] <ryanakca> ... and nevermind, I figured it out myself :)
[15:34] <cjwatson> workaround instructions on bug 201673 now
[15:34] <ubotu> Launchpad bug 201673 in glibc "REGRESSION: glibc 2.7-9ubuntu1 NSS module broken due to toolchain changes" [Critical,Fix released] https://launchpad.net/bugs/201673
[15:34] <sistpoty|work> protonchris: https://launchpad.net/ubuntu/hardy/+queue
[15:35] <nixternal> cjwatson: groovy! thanks. I tried to forewarn people last night...the forums were active and had a viable fix up within an hour it seems
[15:35] <pitti> ryanakca: yes, it's in bzr (both upstream and the ubuntu package)
[15:47] <soren> asac: nm-applet gives me: nm-applet: symbol lookup error: nm-applet: undefined symbol: dbus_method_dispatcher_new
[15:48] <cody-somerville> infinity, Can you take a look at bug #194912 ? thanks.
[15:48] <ubotu> Launchpad bug 194912 in ghc6 "ghc6 6.8.2-1ubuntu1 FTBFS on sparc" [Undecided,Confirmed] https://launchpad.net/bugs/194912
[15:49] <asac> soren: downgraded as well?
[15:50] <soren> asac: Oh, sorry. Leftover libnm-* stuff
[15:50] <asac> k
[15:54] <\sh> hmm...
[15:54] <\sh> can someone explain why php5-modules on amd64 are installed in /usr/lib/php5/20060613 and on i386 in /usr/lib/php5/20060613+lfs ?
[15:55] <soren> IIRC the directory was changed on i386 because the ABI was broken (when adding large file support (hence the lfs suffix)).
[15:56] <soren> asac: Works fine (using WEP encryption).
[15:57] <\sh> soren: grmpf...
[15:57] <soren> \sh: What?
[15:57] <\sh> soren: it's bad when you provide .ini files for extentions and you need to change them depending on the arch
[15:58] <\sh> soren: question is, can we drop this +lfs for hardy and join back to one directory name for i386+amd64+others?
[16:02] <soren> Has the ABI been bumped?
[16:02] <Amaranth> wow, glibc had the same problem wine had?
[16:03] <ion_> amaranth: kexec-tools FTBFS’d because of a similar problem. :-)
[16:04] <\sh> soren: I have to check php src pkg...to see when it was introduced :)
[16:09] <soren> Amaranth: Lots of stuff broke.
[16:09] <cjwatson> Amaranth: I did not know that wine had the same problem; do you have a reference?
[16:09] <soren> Amaranth: dpkg itself, for instance :)
[16:09] <cjwatson> soren: it did? reference?
[16:10] <soren> I'm assuming "the same problem" refers to the failure to build when passed LDFLAGS and friends as environment variables?
[16:10] <pitti> seb128: FYI, triggering the next round of give-backs
[16:10] <soren> If not, pardon me for spreading FUD :)
[16:10] <cjwatson> soren: I don't see anything relevant in the dpkg changelog since the LDFLAGS change was made
[16:10] <Amaranth> cjwatson: https://edge.launchpad.net/ubuntu/hardy/+source/wine/0.9.56-0ubuntu1
[16:11] <cjwatson> soren: are you saying that dpkg failed to build or otherwise broke due to being passed LDFLAGS as an environment variable from dpkg-buildpackage?
[16:11] <cjwatson> Amaranth: thanks
[16:11] <soren> cjwatson: Er... Sorry, my mistake.
[16:11] <soren> cjwatson: Same upload, though. Different problem.
[16:11] <cjwatson> soren: I really need you to be verbose
[16:11] <seb128> pitti: ok
[16:11] <soren> cjwatson: Yes, sorry.
[16:13] <soren> cjwatson: grub failed to build due to it, though.
[16:13] <soren> 0.97-29ubuntu15 fixed that.
[16:15] <cjwatson> that looks like CFLAGS rather than LDFLAGS
[16:15] <soren> cjwatson: The dpkg problem I was thinking about was the one about pkg-create-dbgsym, which caused dpkg itself to fail to build.
[16:15] <cjwatson> right, that looks disconnected though?
[16:15] <soren> cjwatson: Hence the "and friends".
[16:15] <soren> cjwatson: Let me start over..
[16:15] <cjwatson> as in, that was a separate problem with dpkg's perl modules used by pkg-create-dbgsym
[16:16] <soren> cjwatson: The change to dpkg-buildpackage to make it pass a set of environment variables to was introduced at the same time as the change that broke pkg-create-dbgsym.  The former change broke grub, the latter broke a lot of stuff (including dpkg itself).
[16:17] <cjwatson> right, I only care about the former right now. :-)
[16:17] <cjwatson> wine is the only other case I've heard of where the failure was at run-time
[16:17] <soren> Ok. While it wasn't LDFLAGS specifically that broke it, it was "one of the environment variables the dpkg-buildpackage has recently started setting".
[16:18] <cjwatson> ok
[16:18] <soren> I seem to be causing more confusion than I'm helping, so I'll wander off now.
[16:18] <cjwatson> CFLAGS and friends seemed to be set to -g -O2 in the case of grub
[16:20] <cjwatson> it seems to be specifically -g that grub hates
[16:27] <nixternal> ahhh man, I am back in heaven here
[16:36] <soren> cjwatson: How do you come to that conclusion? I'm not contesting it, I'm just curious.
[16:38] <cjwatson> soren: because dpkg-buildpackage sets -O2 -g, and grub/configure.ac sets -O2
[16:38] <cjwatson> (and others)
[16:41] <keescook> infinity: can you check why "zsnes" isn't even attempting to build on amd64?  the control file lists "i386 amd64" ...
[16:42] <soren> cjwatson: Makes sense.
[16:43] <soren> zsnes: i386     # Mostly written in i386 assembler
[16:43] <soren> keescook: ^^ from p-a-s
[16:44] <keescook> soren: p-a-s ?
[16:44] <soren> Packages-arch-specific
[16:44] <keescook> what file is that?
[16:44] <soren> The file we share with Debian that actually defines which architectures we'll try to build stuff on.
[16:44] <keescook> *boggle* control file is ignored?
[16:44] <soren> Yes.
[16:44] <soren> I share your boggliness.
[16:44] <keescook> anyway, zsnes was specifically patched to build on amd64.
[16:45] <keescook> so, what is the process to fix p-a-s?
[16:45] <soren> Tell lamont, infinity, or slangasek.
[16:45] <soren> I believe they have access to the cvs repository where it's kept.
[16:46] <lamont> keescook: we share Packages-arch-specific with debian.  and no, we're not going to fork it.
[16:46] <lamont> and yes, control file is ignored.
[16:46] <lamont> well, not so much ignored as overridden
[16:46] <cjwatson> it's not quite ignored; if the control file says "don't build on this arch" then it will try but fail
[16:46] <lamont> cjwatson: right
[16:46] <soren> keescook: I believe the rationale is something along the lines of: buildd maintainers allegedly know better than package maintainers if a given package will build on their architecture, so the architectures: field is ignored.
[16:47] <keescook> fun
[16:47] <lamont> if PaS says to ignore it, then wanna-build (and the launchpad equivalent) ignore the package for that architecture
[16:47] <cjwatson> the rationale is that historically package maintainers demonstrably had no idea
[16:47] <soren> *g*.
[16:47] <keescook> okay, I will sum it up for the bug I saw.  :P
[16:47] <lamont> porters know better than package maintainers whether or not their architecture can handle it
[16:47] <lamont> keescook: and the issue I had was that the package still doesn't work for people who have been building it, apparently (from the bug)
[16:47] <soren> Well, a lot of folks know a lot of stuff better than a lot of other folks. :)
[16:48] <soren> That's why we file bugs against packages to fix such things.
[16:48] <keescook> lamont: I can believe that -- I was just curious about the lack of soyuz-build-attempt
[16:48] <soren> *shrug* I'm not really in the mood to discuss it again.
[16:49] <keescook> soren: what's the url for that file, btw?
[16:49] <soren> http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.738&root=dak&view=log
[16:49] <lamont> keescook: soyuz uses debian's Packages-arch-specific
[16:49] <lamont> always has
[16:50] <keescook> cool
[16:50] <soren> If the people with access to p-a-s are happy to make changes, it's not a problem per se.
[16:50] <soren> (and they are, so we're all good)
[16:51] <soren> I'm curious... Does anyone know if there's a large delta between what the packages' arch fields say and what p-a-s says?
[16:52] <soren> I mean... If we decided to trust the architectures field of our packages, how swamped would be we with build failures?
[16:53] <\sh> soren: even with the trust in the arch maintainers of our buildds we are bugged with many build failures for packages...
[16:53] <soren> Ok, rephrasing..
[16:53] <soren> If we decided to trust the architectures field of our packages, how *much more* swamped would we be with build failures?
[16:53] <YokoZar> lamont: speaking of PAS...would removing zsnes from there (or adding amd64 to it) be appropriate?  :)
[16:54] <\sh> soren: the problem is not the arch, but the developers who only know i386 and nowadays amd64 and who have no clue about other archs...
[16:54] <soren> Well, the default is to build on all archs.
[16:54] <\sh> soren: not for people who only know linux
[16:54] <\sh> soren: on i386
[16:54] <YokoZar> Is there anything horribly wrong with letting the buildd just fail?
[16:55] <soren> So, to limit it to a smaller set of archs, we'd just have to change the package rather than p-a-s. That's not much different.
[16:55] <soren> YokoZar: Waste of resources.
[16:55] <soren> YokoZar: And time. And it fills my inbox with build failure logs.
[16:56] <\sh> soren: tbh, most of the build failures nowdays are from hppa, sparc
[16:56] <soren> \sh: I don't see your point.
[16:58] <YokoZar> Well, once you get the build failures you could change the package, and then soon enough we'd have reliable control files to use instead of PAS
[16:59] <\sh> soren: there are archs which are not well supported...one is hppa (in our case) and also sparc, just because most of the people don't have a clue about those archs...how many people do you know in here who are actively trying to fix all failed packages e.g. on hppa?
[16:59] <soren> Well, the *real* point, as I see it, is that that's how they got added to p-a-s to begin with.
[17:00] <soren> \sh: How does that relate to whether we set the build architectures in p-a-s vs. the control file?
[17:05] <\sh> soren: it doesn't...but what you said, about "your|mine|our resources" it relates...well it's annoying to get every week a failed buildlog for <insert pkg here> on <insert port arch here> for software, which isn't even supported officially (means packages which are not in main)
[17:06] <soren> \sh: Yes.
[17:13] <\sh> ok..time to go home...
[17:13] <pitti> YokoZar: problem arises if the build succeeds, but the package wouldn't actually work
[17:15] <seb128> is there a policy about what perl applications should use betwen "env perl" and "/usr/bin/perl"?
[17:15] <Keybuk> I think it slants towards the latter
[17:17] <seb128> bug #199134 is the issue
[17:17] <ubotu> Launchpad bug 199134 in gnome-system-tools "Perl upgrade breaks gnome system tools" [Undecided,New] https://launchpad.net/bugs/199134
[17:17] <ion_> For tarballs ditributed for whatever platform, i’d go with /usr/bin/env perl, but for Debian packages, /usr/bin/perl.
[17:18] <Keybuk> doesn't the perl installer thing take care of setting the #! in the script to the correct full path of the interpreter?
[17:21] <ogra> argh
[17:22]  * ogra just came back to his desktop which is also his build server ....
[17:22] <ogra> i havent seen the desktop here since the weekend ... and my build scripts loop mount about ten times in every run
[17:23] <slytherin> can anyone of the buildd admins please give back evolution-jescs?
[17:23] <ogra> ps ax|grep nautilus|wc -l
[17:23] <ogra> 328
[17:23] <ogra> *sigh*
[17:25] <ion_> UUOG ;-)
[17:25] <cjwatson> Pici: belatedly, I've edited the description of https://launchpad.net/bugs/201673 with workaround documentation
[17:25] <ubotu> Launchpad bug 201673 in glibc "REGRESSION: glibc 2.7-9ubuntu1 NSS module broken due to toolchain changes" [Critical,Fix released]
[17:26] <pitti> slytherin: done
[17:26] <slytherin> pitti: thanks
[17:26] <Pici> cjwatson: okay, I had stuck that in the #u+1 topic anyhow :)
[17:31] <cjwatson> Pici: thanks
[17:32] <cjwatson> Keybuk: not everyone bothers using ExtUtils::MakeMaker and friends; too heavyweight for many purposes
[17:33] <Keybuk> cjwatson: not everybody bothers showering once a day
[17:34] <ion_> find debian/$(cdbs_curpkg) -name '*.pl' -print0 | xargs sed -i -re '1s,^#!.*,#!/usr/bin/perl,' :-)
[17:34] <ion_> xargs -0r, that is
[17:35] <ion_> Would it be appropriate for dh_make to do that, btw?
[17:37] <cjwatson> Keybuk: thpppt, using EU::MM is total overkill for an ordinary script :)
[18:10] <seb128> slangasek: what do you plan to put the freeze in action? ;-)
[18:26] <ogra_cmpc> seb128, do you have to poke him about it ... he probably forgot and now you reminded him
[18:26] <pitti> mvo: yay, I just fixed the last two conffile prompt bugs on the hardy milestone list
[18:26] <mvo> pitti: rock!
[18:27] <seb128> ogra_cmpc: yeah, but later ;-)
[18:27] <pitti> mvo: except, of course, bug 174128, which I still can't reproduce
[18:27] <ubotu> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
[18:27] <pitti> mvo: btw, do you get diff -Nur for /etc on upgrade tests now?
[18:27] <ogra_cmpc> seb128, well, given that much was blocked today i'd relly propose to slip one day
[18:27] <pitti> we should fix that as well for a really working upgrade
[18:28] <seb128> right
[18:28] <mvo> pitti: I can generate diffs now, haven't looked over them in a while though
[18:28] <slangasek> lamont: ah, if a package is ftbfs in feisty and unchanged since feisty, did anyone file a bug about the build failure or is this the first time anyone's noticed it? :)
[18:28] <ogra_cmpc> i know i wont make all i planned in time
[18:28] <pitti> mvo: could they be put onto p.u.c. automatically?
[18:28] <slangasek> lamont: but yes, nuking the binary in any case seems reasonable...
[18:29] <mvo> pitti: its a problem as the kvm based upgrade tester is not available in the data center
[18:29] <slangasek> soren: I don't have any commit access to P-a-s, btw
[18:29] <mvo> pitti: but I should setup something semi-automatic on my home machine
[18:29] <soren> slangasek: Noted :)
[18:33] <arcticpenguin380> why does every new *ubuntu neeed more ram/
[18:34] <slytherin> arcticpenguin380: what do you mean?
[18:34] <pitti> asac: are you handling bug 194379? if so, care to assign it to you? if not, want me to check the patch and apply/upload?
[18:34] <ubotu> Launchpad bug 194379 in gnash "enable xulrunner 1.9/firefox 3.0" [High,Confirmed] https://launchpad.net/bugs/194379
[18:35] <slytherin> pitti: I think it is already fixed.
[18:35] <arcticpenguin380> dapper.edgy fiesty required 256 but gutsy needs 320mb ram and now hardy needs 384MB
[18:35] <slytherin> pitti: Indeed that is fixed with latest gnash upload
[18:36] <pitti> slytherin: ah, thanks;  I'll close it then
[18:36] <pitti> indeed, I see it in the changelog
[18:36]  * pitti hugs asasc
[18:36] <cjwatson> arcticpenguin380: the gutsy number was probably not very accurate, to be honest, and 384 would probably have been closer for it; it was due to some problems in (we think) the kernel that have never been fully tracked down, as well as new desktop features
[18:36] <pitti> and asac too
[18:37] <arcticpenguin380> is that for just the live cd?
[18:37] <cjwatson> arcticpenguin380: there's been work done recently on something called 'compcache' which promises to be able to reduce the memory load significantly for intrepid (I think it's too late now for hardy, unfortunately), and we plan to do some other performance work then too
[18:37] <cjwatson> arcticpenguin380: it should be possible to install the alternate CD with significantly less memory, though 256MB is probably still about the lower end to be able to run the standard Ubuntu desktop
[18:37] <arcticpenguin380> cjwatson: is that for the next ubuntu release or the kernel itself?
[18:37] <slytherin> is anyone already working on OOo FTBFS for powerpc?
[18:38] <ion_> compcache ♥
[18:38] <cjwatson> arcticpenguin380: next Ubuntu release
[18:38] <cjwatson> (after hardy)
[18:38] <arcticpenguin380> i know itrepids next im on hardy now
[18:40] <ScottK2> FWIW, I run Hardy Kubuntu (KDE3) on a laptop with 256MB ram and it works reasonably (if slowly) well.
[18:42] <ion_> cjwatson: Does the compcache patch support the feature being disabled unless a kernel cmdline parameter is given?
[18:42] <arcticpenguin380> think ext4 will be in intrepid?
[18:43] <cjwatson> ion_: sorry, I don't know the answer to questions about compcache in general, I'm just vaguely aware of it
[18:43] <cjwatson> arcticpenguin380: depends on whether it's accepted upstream; we don't propose to inflict experimental filesystems on our users and then have to deal with the cleanup
[18:48] <cjwatson> pitti: what do you think of bug 201852?
[18:48] <ubotu> Launchpad bug 201852 in casper "[Hardy] casper should configure PolicyKit to avoid asking paswd for user ubuntu in live mode" [Undecided,New] https://launchpad.net/bugs/201852
[18:48] <cjwatson> seems to make sense to me
[19:03] <pitti> cjwatson: indeed it does; assigned to me, will fix tomorrow
[19:03] <pitti> thanks for pointing out
[19:05] <cjwatson> pitti: cool, thanks
[19:11] <ion_> cjwatson: Apparently compcache consists of a kernel module and nothing more intrusive, so it should be possible to include it in linux-ubuntu-modules and just not load it by default, or package it to be used with module-assistant.
[19:12] <ion_> cjwatson: I’d be very happy to get it to l-u-m. :-)
[19:18] <ion_> cjwatson: There seems to be a bug report about it with a debdiff, https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.24/+bug/200765
[19:18] <ubotu> Launchpad bug 200765 in linux-ubuntu-modules-2.6.24 "Add compcache modules, allowing ubiquity installs on 256MB machines." [Medium,Triaged]
[21:25] <TheMuso> slangasek: Just wondering whether any more of the FFe queue will be processed before beta freeze. I'd like to get eSpeak in if I could... bug 200370
[21:25] <ubotu> Launchpad bug 200370 in espeak "FF Exception, new upstrea version of Espeak." [Undecided,New] https://launchpad.net/bugs/200370
[21:30] <seb128> hey TheMuso
[21:30] <TheMuso> Hey seb128.
[21:30] <seb128> TheMuso: have you read the GNOME bug I pointed about the pulseaudio issue the other day?
[21:31] <TheMuso> seb128: Yes I have, and I tried the suggestion, which works. Not sure whether we shoudl install that package as well however.
[21:32] <seb128> why not?
[21:35] <TheMuso> seb128: Thats the conclusion I've come to.
[21:35] <TheMuso> The question is now whether its better to seed it, or make it a dependency.
[21:47] <jdstrand> lamont: I was curious as to the status of bug #200739
[21:47] <ubotu> Launchpad bug 200739 in bind9 "bind9 apparmor profile is named apparmor-profile" [Undecided,Fix committed] https://launchpad.net/bugs/200739
[21:48] <jdstrand> lamont: I see you requested a sync, but it's not in hardy yet
[21:49] <jdstrand> lamont: I issued bug #201954 and was preparing a fix
[21:49] <ubotu> Launchpad bug 201954 in bind9 "bind9 apparmor profile does not allow access to /var/lib/bind" [Medium,Triaged] https://launchpad.net/bugs/201954
[21:49] <lamont> jdstrand: that's a "pester the archive-admin-of-the-day" thing
[21:49]  * jdstrand goes to see who the admin is
[21:49] <lamont> jdstrand: git clone git://git.debian.org/~lamont/bind9.git :-)
[21:50] <lamont> and then git checkout -b v9.4.2 origin/stable/v9.4.2
[21:50] <lamont> jdstrand: or just grab the bits from debian
[21:50] <lamont> or pester $archive-admin to do the sync
[21:50]  * jdstrand nods
[21:51] <jdstrand> lamont: going the git route, since I know better now ;)
[21:52] <lamont> jdstrand: it was just pointed out that the git tree is a little sideways atm... gimme a minute
[21:53] <lamont> tags in place. doh
[21:54] <jdstrand> lamont: I am already running clone, I guess I'll just do a pull? (I'm a git newbie)
[21:54] <jdstrand> after it's done that is
[21:54] <lamont> git fetch origin
[21:54] <jdstrand> ok
[21:54] <lamont> it's just tags that are missing
[21:55] <emgent> hi jdstrand :)
[21:55] <jdstrand> hi emgent!
[21:56] <lamont> jdstrand: then git commit; git-format-patch (see man); git-send-email
[21:56] <jdstrand> \m/-- a git tutorial
[21:57] <lamont> jdstrand: and then pester the bzr folks to give you a bzr interface that sits on top of git plumbing so that you can use the bzr UI and still just fetch from the upstream git server....
[21:57] <jdstrand> I thouth bzr-git existed?
[21:59] <lamont> jdstrand: it gives you read access to a git tree
[21:59] <jdstrand> ok
[22:00] <lamont> and I don't know but what it just converts a git tree into a bzr tree, and then you can't freshen the tree without recreating it...
[22:00] <lamont> could be totally wrong, fiww
[22:00] <Mithrandir> git-bzr supports pulling, I think
[22:00] <Mithrandir> bzr-git, even
[22:02] <cjwatson_> I'd be amazed if it didn't
[22:02] <cjwatson> that's how bzr-$vcs works as a general rule
[22:02] <mdke> can anyone help in translating bug 144498, I don't really understand it
[22:02] <ubotu> Launchpad bug 144498 in gnome-user-docs "autopkgtest gutsy gnome-user-docs: erroneous package!" [High,New] https://launchpad.net/bugs/144498
[22:06] <cjwatson> mdke: you need to look at the original description, which has the full log; it's a build failure bug
[22:06] <cjwatson> mdke: it appears to be because:
[22:06] <cjwatson> /bin/bash /home/daniel/bzr/build-area/gnome-user-docs-2.18.2+svn20070912ubuntu1/install-sh -d /root/adt-downtmp/dsc0-build/gnome-user-docs-2.18.2+svn20070912ubuntu1/debian/gnome-user-guide//usr/share/gnome/help/user-guide/C
[22:06] <cjwatson> /bin/bash: /home/daniel/bzr/build-area/gnome-user-docs-2.18.2+svn20070912ubuntu1/install-sh: No such file or directory
[22:06] <cjwatson> mdke: i.e. hardcoded path to the home directory of whoever built the source package lying around in the source package
[22:06] <mdke> oh, the log is cut off?
[22:06] <cjwatson> yeah
[22:07] <mdke> hehe
[22:07] <mdke> is that test done regularly?
[22:07] <mdke> i.e. if there isn't a bug for it in hardy do I need to worry about it?
[22:07] <cjwatson> it was at one point, I don't think it is at the moment
[22:07] <cjwatson> grep for that path in the source package ...
[22:07] <cjwatson> assuming Daniel did the last build
[22:08] <cjwatson> oh, he didn't. grep for your home directory then
[22:08] <cjwatson> but, TBH, if it built on the buildds you're probably OK
[22:08] <mdke> I think he did
[22:08] <mdke> will try
[22:10] <mdke> thanks cjwatson
[22:13] <mdke> cjwatson: grepping for my home directory in the test source package I just did shows the path, also the latest gutsy package shows daniel's, but the various packages have never ftbfs on launchpad
[22:14] <mdke> at least afaik
[22:14] <cjwatson> it may be that they don't fail when run under dpkg-buildpackage, but do when run as 'debian/rules build; fakeroot debian/rules binary'
[22:14] <cjwatson> both are valid
[22:14] <cjwatson> it's possible for something never to fail in Launchpad builds but still be buggy
[22:15] <mdke> ok, so we should get it fixed. I'll ask Daniel if he knows how
[22:15] <mdke> i haven't got a clue
[22:42] <ompaul> cjwatson, btw figured that thing out - it was not looking for a proxy server so it hung on a network where there was a proxy server - solution - install while not networked -
[22:45] <infinity> mdke: A quick look at the build log would lead me to believe that some sort of configure script is running in the "clean" target, rather than the "build" target.  Since dpkg-buildpackage runs "clean" before "build", it works, but autopkgtest doesn't do so (so is stuck with the configured variables from the "clean" run right before the source package was built).
[22:46] <mdke> infinity: aha, that sounds very helpful, thanks.
[22:46] <infinity> mdke: A look at a launchpad build log confirms that; configure is being run in "clean", not in "build".
[22:48] <mdke> infinity: great, I've added that to the bug report.
[22:48] <mdke> cheers
[22:54] <seb128> mdke: speaking about gnome-user-docs, are you going to update it to the new gnome version?
[22:57] <mdke> seb128: I've filed the bug for sponsoring already :)
[22:57] <seb128> mdke: good, let me look at it
[22:57] <azeem> soo, would be possible and welcome to update opensync-related packages to 0.22 for hardy, or is it too late now?
[22:57] <mdke> seb128: bug 201955
[22:57] <ubotu> Launchpad bug 201955 in gnome-user-docs "Sync from upstream" [Undecided,New] https://launchpad.net/bugs/201955
[22:58] <seb128> doh
[22:58] <seb128> it's in bzr
[22:59] <seb128> I'll let dholbach do it tomorrow ;-)
[22:59] <seb128> slangasek: are we frozen now?
[22:59] <mdke> seb128: ok! Maybe he will fix the issue we talked about above too, I mailed him about it
[22:59] <slangasek> seb128: ... as soon as I can find the actual button in launchpad...
[22:59] <StevenK> Haha
[23:00] <seb128> slangasek: ok, in a few hours then ;-)
[23:00] <slangasek> I think it may have moved in the intervening months while we were doing soft freezes :/
[23:00] <TheMuso> slangasek: thank you.
[23:00] <mdke> it will be big, and red
[23:01] <compbrain> Can you make make-kpkg give you a source package instead of a binary
[23:04] <LaserJock> slangasek: so I wasn't totally sure, but does Beta Freeze apply just the same to Universe this time?
[23:05] <slangasek> LaserJock: beta freeze applies to universe in the sense that it's a hard freeze so all packages have to go through it
[23:05] <slangasek> I'm not planning on subjecting universe packages to any additional scrutiny during the beta freeze, though; I think we've always considered it a bug that freezing can't be done per-component
[23:05] <ogra_cmpc> oh, you really will freeze tonight ?
[23:06] <slangasek> ... yes? :)
[23:06] <slangasek> *if* someone can push the button for me, turns out the reason I can't find it is because of a permissions issue
[23:07]  * ogra_cmpc goes to make more coffee then ... having lost half the day due to not being able to build ltsp chroots didnt help much :/
[23:08] <persia> LaserJock: For gutsy, we treated BetaFreeze as guidance for universe, and RCFreeze as requiring motu-uvf approval for freeze exceptions.  For hardy, we likely want to take special care for xubuntu and ubuntustudio.
[23:10] <LaserJock> persia: hmm, we should perhaps have their seeds "germinated" into a list of "don't mess with" for freezes and such
[23:11] <LaserJock> I'm not sure if their deps would necessarily be easy to spot or not
[23:11] <LaserJock> but the rest of Universe surely doesn't care about Beta Freeze
[23:11] <persia> LaserJock: That sounds like a good idea, perhaps asking for approval from xubuntu-dev or ubuntustudio-dev for freeze exceptions.
[23:12] <persia> slangasek: How painful would an extra check for universe-based CDs be for your processes?
[23:13] <slangasek> persia: verbose++, please?
[23:14] <persia> slangasek: How painful would it be for your processes to check that post-BetaFreeze uploads to packages that will end up on xubuntu and ubuntustudio CDs close a freeze exception bug approved by the relevant -dev team?
[23:15] <infinity> persia: Very.
[23:15] <persia> Right.  We'll go with peer pressure then :)
[23:15] <infinity> persia: In the past, we just handed off universe uploads to the MOTU folk for approval.
[23:16] <infinity> persia: If the MOTU exception team wants to further divide their efforts to look for Xubuntu uploads, that works fine, but I'm not sure the people handling main will have the time to parse all universe uploads for "oh, this might be Xubuntu".
[23:17] <persia> infinity: I'm just talking about universe.  Packages in main already have to get BetaFreeze exception approval through ubuntu-archive review of the updates during the manual acceptance.  universe is typically waved through, but it might be nice to have a check for the CDs.
[23:18] <slangasek> if someone could provide a trivial (i.e., reviewable, and not painful to run) script to check whether the package is in one of the universe CDs, it might not slow us down too much to run that
[23:18] <infinity> persia: Right, but my point is that going from "we traditionally ignore universe entirely and/or offload it" to "we now have to check all universe uploads against a list" is rough.
[23:18] <slangasek> OTOH, I guess I would expect that most of the universe packages on the Xubuntu CD are maintained by the xubuntu developers, who know what they're about?
[23:19] <persia> infinity: Agreed, although it seems a sane consequence of allowing CD builds against universe.
[23:19] <persia> slangasek: Should be: I'd expect the number of exceptions to be fairly low.
[23:20] <infinity> Having a clever check in the soyuz queue that checked germinate output and tagged anything that will land on a CD with a marker would be cute, but very not doable before release.
[23:21] <infinity> Writing a screen-scraping filter around the queue tool that did the same thing would also be doable, but only if it's really necessary...
[23:21] <persia> infinity: Certainly not doable in the queue.  Having an unofficial script to do that is maybe less hard.
[23:21] <calc> so is firefox broken for everyone else on hardy?
[23:21] <infinity> (Though I concede that it would also be handy for main as well, so we can see at a glance if an upload will affect a CD build)
[23:22] <infinity> calc: Works For Me.  Slowly.
[23:22] <calc> it won't even start for me
[23:22] <calc> "Could not find compatible GRE between version 1.9b3 and 1.9b3.
[23:22] <calc> that shows up in xsession-errors
[23:22] <infinity> calc: And that's too cryptic for you?  Sheesh.  Get a compatible GRE already!
[23:22] <infinity> (Whatever that means...)
[23:22] <slangasek> and it's not just that you're running the broken glibc?
[23:23] <crimsun> firefox-3.0_3.0~b4+nobinonly-0ubuntu1_amd64.deb                                13-Mar-2008 22:06
[23:23] <persia> Given the timing, let's see if such a script appears by Monday.  If not, it's likely too annoying to change workflow for hardy.
[23:23] <crimsun> (http://archive.ubuntu.com/ubuntu/pool/main/f/firefox-3.0/)
[23:23] <calc> slangasek: i don't think i am other stuff still works
[23:23] <infinity> slangasek: So, we're hard frozen now.  Time to do my final import of the archive and start another test build run?
[23:24] <crimsun> calc: (I'm assuming you're using that arch - amd64)
[23:24] <calc> 2.7-9ubuntu2
[23:24] <slangasek> infinity: yes please
[23:24] <calc> on i386
[23:24] <slangasek> calc: ok, that's the !broken one :)
[23:24] <slangasek> I don't know then
[23:24] <calc> my laptop is just i386 since amd64 doesn't resume on it
[23:24] <crimsun> calc: and you're /certain/ both the xulrunner and firefox-3.0 packages are ~b4 ?
[23:24] <calc> crimsun: checking
[23:25] <calc> oh no my mozilla is still b3 for whatever reason
[23:25] <crimsun> (e.g., check  dpkg -l |awk '/^ii(.)*~b4/ {print $2}' )
[23:25]  * calc sees if the mirrors have b4 yet
[23:25] <calc> ah now they do
[23:25] <crimsun> they do for amd64, i386, and powerpc
[23:25] <calc> apparently it pushed out a bit later than xulrunner so i didn't get it yet
[23:25]  * cjwatson breathes a sigh of relief
[23:26] <calc> sorry for scaring everyone :)
[23:26] <cjwatson> I don't think I could have coped with firefox blowing up today
[23:26] <calc> i don't guess a tight dependency isn't wanted for it?
[23:27] <cjwatson> firefox-3.0 depends: xulrunner-1.9 (>= 1.9~b4~)
[23:27] <cjwatson> ah, but
[23:27] <calc> but xulrunner doesn't conflict with old firefox
[23:27] <cjwatson> xulrunner-1.9 Breaks: firefox-3.0 (<< 3.0~b3)
[23:27] <cjwatson> that should be b4
[23:27] <calc> ah
[23:27] <cjwatson> could you file a bug on xulrunner-1.9 for that?
[23:28] <calc> ok
[23:28] <calc> once i get firefox running again :)
[23:28] <calc> should be in a couple minutes
[23:28] <cjwatson> only affects intra-hardy upgrades, but still
[23:28] <calc> yea
[23:29] <slangasek> infinity: it may be advantageous for you to wait a few days before starting the rebuild tests, actually, since I'll be having my first look at o-o-d packages since the last alpha starting today and we might hammer some of those out without you needing to get duplicate failure reports
[23:30] <Amaranth> o-o-d?
[23:30] <crimsun> calc: I'll reopen, retitle, and reassign 201938 for that purpose
[23:31] <infinity> Amaranth: out-of-date.
[23:31] <Amaranth> thought so
[23:31] <calc> crimsun: ah ok :)
[23:31] <infinity> slangasek: I'm happy to hold off until Mondayish, if that gives you enough time to try to get some archive settling.
[23:31] <infinity> slangasek: Should give me fewer failures if I have a few more build-deps in sync by then too.
[23:32] <infinity> slangasek: (Every rebuild test seems to happen right after a new GNOME or new KDE, which invariably leads to dozens of false positives I need to filter through due to arch any/all sync issues)
[23:33] <crimsun> calc: d'oh, I pasted right after you ;)
[23:33] <slangasek> infinity: right
[23:35] <seb128> slangasek: should we ask you before uploading thing or do you review things in the queue once uploaded?
[23:36] <slangasek> seb128: if you're comfortable that it's sane, please upload and let the review happen in the queue; otherwise it's basically a double-review
[23:36] <infinity> seb128: I tend to prefer the "upload, then ask permission" workflow, as it's a bit faster than hunting people down before you upload (and with a hard freeze, it's trivial to reject).
[23:36] <slangasek> if you have doubts about whether it's sane, ask so that you don't spend a lot of time preparing packages that I'll reject :)
[23:37] <infinity> slangasek: Oh, but since I exercise my core-dev hat about once per release now, I should ask exactly *who* I'm asking permission from after I upload. ;)
[23:37] <infinity> slangasek: Just you?  Any of ubuntu-release (excluding the uploader)?
[23:39] <slangasek> any of ubuntu-release excluding the uploader, yes
[23:40] <slangasek> though anyone other than me has the luxury of passing the buck :)
[23:40] <infinity> slangasek: :)
[23:40] <seb128> would "Use printing devices" be a good description for lpadmin in users-admin?
[23:40] <seb128> that's for the list of groups in which ones the user is
[23:41] <infinity> Can only lpadmin write to printers?
[23:41] <slangasek> seb128: I guess by "printing devices" you mean "printer device nodes"?
[23:41] <seb128> anybody giving an opinion can run users-admin, unlock, click on add and look the list there
[23:42] <infinity> If so, I suppose "Access printers" "use printers" "print stuff" all work. ;)
[23:42] <seb128> slangasek: "Use printers"? ;-)
[23:42] <slangasek> (I wouldn't phrase it either of those two ways; the first is ambiguous -- what is a "printing device" but a "printer", the second is too jargony)
[23:42] <slangasek> seb128: yes, that's what I would've written :)
[23:42] <seb128> ok, thanks
[23:43] <infinity> "Transfer information from RAM to paper".
[23:44] <infinity> seb128: "Use audio devices" suffers from the same problem, sort of, but it's harder to rewrite than "Use printers"...
[23:44]  * infinity shrugs.
[23:44] <slangasek> "Use printers" "make noises"
[23:44] <infinity> Hah.
[23:45] <infinity> I can make noises all I want without any UNIX perms!
[23:45] <seb128> "click there to get a working computer"
[23:45] <infinity> *unf*
[23:45] <StevenK> chmod a-rwx infinity
[23:46] <seb128> slangasek: gnome-system-tools uploaded if you want to review it, I've added lpadmin to list of known groups so it can be used when adding users and did some quick description and patch cleaning which should not be an issue
[23:47] <crimsun> for straight syncs from Debian, at this point should I still be filing a bug/subscribing ~ubuntu-archive?  I'd think it's lighter to request a sync of gst-pulse from sid, which fixes bug 189854
[23:47] <ubotu> Launchpad bug 189854 in gst-pulse "sound is complete noise when pulseaudio is running" [Low,Incomplete] https://launchpad.net/bugs/189854
[23:48] <slangasek> seb128: ok; it's not in the queue yet and I'm working through other stuff at the moment, but I'll certainly review it later.  OOI, is this change in response to a bug?  I can't see why a user needs direct access to printer devices
[23:48] <slangasek> or are printer devices the issue, either?
[23:50] <seb128> bug #152107
[23:50] <ubotu> Launchpad bug 152107 in gnome-system-tools "users-admin doesn't add admin users to lpadmin" [High,Confirmed] https://launchpad.net/bugs/152107
[23:50] <seb128> the non lpamdin users can't modify the cups config
[23:51] <seb128> which means likely they can't add printers, etc
[23:52] <slangasek> seb128: ah, so really "Manage printers" might've been a better name, ohwell :)
[23:52] <infinity> crimsun: If a sync will be bugfix-only, and pretty much the same upload you'd make by hand to Ubuntu, yes, still request syncs, but they'll need RM approval and such now.
[23:53] <seb128> slangasek: hum, right
[23:53] <seb128> slangasek: can you reject the upload?
[23:53] <crimsun> infinity: nod.
[23:53] <seb128> I'll do an another one
[23:53] <infinity> crimsun: So the syn requests should include full debdiffs, and you should notify slangasek and friends.
[23:55] <seb128> "Configure printers"?
[23:55] <seb128> or is manage better there?
[23:55] <infinity> Configure, Manage, something like that.
[23:56] <infinity> Needs to be clear that you don't need to be in lpadmin to USE printers.
[23:56] <seb128> right
[23:56] <infinity> (WHich is why I asked earlier "You need to be in lpadmin to print stuff?")
[23:56] <seb128> I've changed to configure now
[23:57] <infinity> Do we have GUI tools for lpadmin to mangle print queues?
[23:57] <slangasek> seb128: rejected, cheers
[23:57] <infinity> (ie: deleting jobs owned by other users, etc)
[23:57] <infinity> seb128: ^^
[23:57] <slangasek> infinity: yes, the cups tools
[23:57] <infinity> seb128: If so, "Manage" is more correct.
[23:58] <infinity> seb128: "COnfigure" would be just about "creating printers, and changing their settings".
[23:58] <seb128> infinity: run system-config-printer
[23:58] <seb128> and tell me what you think he does exactly ;-)
[23:58] <infinity> seb128: I have no printers, so it's all a bit opaque here. ;)
[23:58] <infinity> seb128: But if I can mangle print queues (vorlon says yes), then I'd prefer "Manage" to "Configure".
[23:58] <StevenK> That's the best number of printers to have.
[23:59] <infinity> seb128: Since "Manage" encompasses "set up printers", "changes settings", and "fiddle with printer-related stuff, like active jobs".
[23:59] <seb128> "Configure and manage printers"?
[23:59] <infinity> seb128: "Configure" just sounds like setup, not ongoing job management.
[23:59] <seb128> I hate having to decide on labels
[23:59] <slangasek> I think "configuration" is a subset of "management"
[23:59] <seb128> or does manage include initial configuration?
[23:59] <slangasek> so "Manage printers" should be sufficient
[23:59] <seb128> ok
[23:59] <seb128> thanks


[00:16] <slangasek> so apparently the mako kernel doesn't have PERF enabled, which means powertop doesn't run.  I'm surprised given how much focus there's been on power management on the phones - is there something other than powertop I should be using?
[09:54] <ppisati> brb
[09:59]  * apw reboots to see if any of his desktop will come back
[13:34]  * henrix -> late lunch
[13:41] <ppisati> any brave soul who is willing to review my packaging of an armhf/generic-lpae flavour for S?
[13:41] <ppisati> watch out: at the end of the packaging, it craps out with an error
[13:42] <ppisati> "dpkg-gencontrol: error: package linux-udebs-lpae not in control info"
[13:42] <rtg> ppisati, where is your repo ?
[13:42] <ppisati> "dh_gencontrol: dpkg-gencontrol -plinux-udebs-lpae -ldebian/changelog -Tdebian/linux-udebs-lpae.substvars -Pdebian/linux-udebs-lpae returned exit code 255'
[13:42] <ppisati> rtg: let me push it
[13:42] <ppisati> the problem is that $someone is passing 'linux-udebs-lpae' to dpkg-gencontrol instead of 'linux-udebs-generic-lpae'
[13:42] <ppisati> but i can't find where it comes from
[13:44] <apw> ppisati, that would be my fault
[13:44] <apw> rtg, the udebs thing is my fault
[13:47]  * rtg is still waiting on the repo location
[13:47] <apw> rtg, i'll fix the udebs bit ...
[13:48] <apw> ppisati, can you post your repo ... then i can test my fix
[13:50] <ppisati> http://kernel.ubuntu.com/git?p=ppisati/ubuntu-saucy.git;a=shortlog;h=refs/heads/master_generic-lpae
[13:50] <ppisati> apw: ^
[13:50] <ppisati> rtg: ^
[13:50] <apw> rtg, this packaging error is mine ... sigh
[13:51] <ppisati> it's a S/master-next of yesterday (my time)
[13:53] <rtg> ppisati, do you really need an inclusion list ? I think it would be simpler to just have a single linux-image package.
[13:54] <ppisati> rtg: ah, could be that we can away without it
[13:55] <ppisati> *we can go
[13:55] <rtg> ppisati,  its simpler, and I assume calxeda isn't all that worried about package size
[13:56] <ppisati> rtg: ok
[13:58] <rtg> ppisati, is there currently HW available that will run arm LPAE ?
[13:59] <ppisati> rtg: not in my hands, but cortex a15 are lpae capable
[13:59] <ppisati> rtg: and qemu can emulate the a15
[13:59] <ppisati> rtg: if we want something really cheap, there's the samsung chromebook
[13:59] <ppisati> ~250$
[14:00] <rtg> ppisati, ok, just making sure that this isn't a new flavour for vaporware. I don't follow arm developments as closely as you
[14:00] <ppisati> http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore
[14:01] <ppisati> rtg: ah, and of course, the new calxeda silicon :)
[14:01] <ogra_> ppisati, pfft, chromebook ... crap ... you want ubuntu edge !
[14:01] <ppisati> ogra_: auahauh :)
[14:02] <ogra_> 128G at SSD speed and 4G ram :)
[14:03] <rtg> ppisati, I'd be tempted to squash all of the config patches into 'UBUNTU: [Config] add an armhf/generic-lpae flavour' in order to make building somewhat bisectable, thought this has been good granularity for review.
[14:04] <rtg> though*
[14:05] <rtg> ppisati, I assume this flavour will be important for the LTS kernel as well ?
[14:07] <rtg> ppisati, cut and paste error in kernel-versions.in: 'armhf  PKGVER-ABINUM   generic-lpae            PKGVER-ABINUM-generic'
[14:18] <nessita> diwic, hola! I just saw your msg in the bug report. I'm not currently in the computer that has the issue, I will report back this afternoon, but I can tell audio does not work even on almost "0" load
[14:19] <diwic> nessita, okay...
[14:19] <diwic> nessita, these delays are really strange
[14:19] <nessita> diwic, also, this happens since my update to raring, in precise I had no audio issues at all
[14:19] <nessita> diwic, besides checking the load, which I will do, is there anything else I can check/try?
[14:20] <nessita> I'm happy to upgrade or fresh install saucy
[14:21] <diwic> nessita, you can surely test random things
[14:21] <rtg> diwic, perhaps she should go back to Precise, but run the Raring LTS kernel in order to isolate any upgrade differences.
[14:21] <diwic> rtg, yeah, that is not a bad idea
[14:21] <rtg> or, are you pretty sure it is kernel related ?
[14:22] <diwic> rtg, no I'm not sure where in the system it is, at all
[14:22] <diwic> rtg, all I see is sudden delays, up to 200 ms, that causes the PulseAudio process to freeze
[14:23] <diwic> rtg, and underruns as a result
[14:23] <diwic> rtg, I don't know where those delays come from
[14:23] <rtg> nessita, after re-installing Precise (and verifying that all works as it should), then install linux-generic-lts-raring-eol-upgrade
[14:24] <nessita> diwic, other apps such as mplayer and youtube on fierfox does not have this issue -- I guess those do not use PA?
[14:24] <diwic> I haven't ruled pulseaudio out completely either
[14:24] <diwic> nessita, it has to do with low latency I believe - when streaming media you can have higher latencies than when having phone conversations
[14:24] <rtg> I guess if things work well with the LTS kernel, then the issue likely is with PA
[14:25] <nessita> rtg, can do that, no problem (over the weekend)
[14:25] <diwic> nessita, so those delays of 200 ms are not a problem when the audio buffers are bigger than 200 ms, but in case of VoIP, buffers are more like 10 ms or so
[14:26] <nessita> diwic, ah, so that explains why mumble/skype/hangouts are the one that trigger the issue
[14:28] <apw> ppisati, yo ... i have just pushed a quicky fixy to saucy master-next which ought to fix your udebs issue
[14:28] <apw> ppisati, could you give that test for me
[14:28] <ppisati> apw: let me check
[14:30] <apw> you ought to be able to cherry-pick it
[14:30] <nessita> diwic, so, summarizing I should: report about system load on current installation when bug appears, and, wipe raring and install precise fresh, with raring kernel
[14:31] <rtg> nessita, install precise fresh, verify that all works well, _then_ install the Raring kernel
[14:31] <diwic> nessita, if raring kernel only does not show the problem, try with the raring X stack as well
[14:32] <nessita> diwic, any how to on how to pull the raring X stack in? is there a ppa?
[14:32] <nessita> rtg, right, yes
[14:32] <ppisati> apw: ok, it's building
[14:32] <rtg> though its easy enough to reboot with the desired kernel
[14:32] <diwic> nessita, hmm, rtg should probably know the name of that package
[14:33] <rtg> linux-generic-lts-raring-eol-upgrade ?
[14:33] <diwic> rtg, right, that's both kernel and X stack?
[14:33] <apw> rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional
[14:33] <rtg> diwic, no, just kernel
[14:34] <apw> ppisati, let me know ... thanks
[14:34] <rtg> maybe xserver-xorg-lts-raring. But there is no going back after installing that.
[14:34] <diwic> oh
[14:34] <diwic> and libgl1-mesa-glx-lts-raring
[14:35] <diwic> according to the wiki
[14:35] <diwic> wiki.ubuntu.com/Kernel/LTSEnablementStack
[14:35] <apw> rtg, i thought you could downgrade again by installing the xserver-xorg (in theory)
[14:35] <apw> not that i have ever tried of course
[14:35] <rtg> apw, perhaps, never tried it
[14:35] <apw> mlanghost is the one who should know i think
[14:36] <rtg> as would jmleddy or Sarvatt
[14:38] <nessita> ok, I guess that going back would be re-installing fresh after all those tests
[14:39] <nessita> (which is ok)
[14:40] <diwic> nessita, btw, there are no error messages or similar in dmesg that could give us a hint of the kernel is timing out waiting for something?
[14:42] <apw> rtg, this last commit on unstable, it seems to be a rebase commit, a start new release, and a removal of alx at the saem time, is this intencional
[14:42] <rtg> apw, oh yeah, I collapsed a bunch of noise
[14:42] <rtg> mostly useless history
[14:44] <nessita> diwic, will also check when I get to that computer. Would you please add this questions to the bug report, so I don't forget to check anything before wiping that raring?
[14:44] <rtg> apw, all that noise is well preserved with the 3.10 tags
[14:48] <diwic> nessita, hopefully the latest comment is sufficient?
[14:52] <nessita> diwic, right, I need to rememebr to check dmesg, but think I will remember :-)
[14:55] <ppisati> apw: ok, the udeb fix did it
[14:55] <ppisati> but now i've another error:
[14:55] <apw> whats the new one
[14:56] <ppisati> http://paste.ubuntu.com/5911420/
[14:57] <apw> ppisati, that implies the d-i config for is not being used i suspect
[14:57] <rtg> you need a firmware exclusion file in d-i
[14:58] <rtg> ppisati, did you fix the typo in kernel.versions.in ?
[14:58] <ppisati> rtg: yep
[14:58] <apw> ppisati, did you copy the armhf-generic files over in debian.master-/d-i
[14:58] <apw> ppisati, did you copy the armhf-generic files over in debian.master/d-i
[14:58] <apw> over to the new name
[14:59] <ppisati> uhm
[14:59] <ppisati> i'm actually missing debian.master/d-i/exclude-firmware.armhf-generic -> debian.master/d-i/exclude-firmware.armhf-generic-lpae
[15:12] <ppisati> rtg: if i delete my generic-lpae.inclusion-list, will it automagically pick generic.inclusion-list or do i need to do something particular?
[15:13] <rtg> jjohansen, apw, would you review http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commit;h=7e78ed6018577530d4ec1fe9f60486aa6d9de529 to make sure I've not done something stupid security wise.
[15:16] <rtg> ppisati, no, it simply doesn't use an inclusion list, and therefore only creates a single linux-image package.
[15:17] <rtg> at least, thats the theory.
[15:18] <ppisati> rtg: let's see
[15:22] <rtg> ppisati, you shuld also be OK if do_extras_package != true
[15:32] <BenC> apw: Can you look at this build failure and explain what I need to do for ppc? https://launchpadlibrarian.net/145776419/buildlog_ubuntu-saucy-powerpc.linux-ppc_3.10.0-0.6_FAILEDTOBUILD.txt.gz
[15:33] <rtg> BenC, apw just applied a patch to master-next that ought to fix it.
[15:33] <rtg> UBUNTU: [Packaging] fix SRCPKGNAME-udebs-FLAVOUR handling for complex flavours
[15:33] <BenC> rtg: Thanks…when's the next upload?
[15:34] <rtg> BenC, unless something critical comes along, likely not until next week. we're considering switching over to 3.11-rc*
[15:34] <rtg> we might sneak in a 3.10.y stable....
[15:37] <BenC> rtg: ack
[15:54] <ppisati> rtg: ok, i based my stuff on top of master-next and i'm doing the last build, can you refrain from committing to master-next?
[15:54] <infinity> BenC: You may also be missing the debian/control tweaks you need, unless Andy pushed those to you.
[15:55] <rtg> ppisati, I dunno, I'm kind of commit happy these days.
[15:55] <infinity> BenC: (We both noticed, FWIW, that we don't have write access to your saucy treee on github)
[15:58] <bjf> roadmr, just fyi, the newly respun precise kernel is in -proposed and ready for testing
[15:58] <rtg> bjf, I don't think he's on IRC
[15:58] <bjf> rtg, i just noticed :-(
[15:59] <ppisati> brb
[16:01] <BenC> infinity: Ah, I'll fix that up
[16:02] <infinity> zequence: We had to respin precise, FWIW.  Should be ready for a lowlatency rebase.
[16:03] <BenC> infinity: added both of you
[16:04] <apw> right BenC soz was in a meeting
[16:05] <apw> BenC, so that error is due to you needing the new control stanza for that package in the flavour-control.stub
[16:06] <apw> BenC, did rtg already point you at it ... i was oging to commit it last night but couldn't
[16:07] <BenC> apw: I added you to the repo, so if it's quick for you, please commit it
[16:07] <apw> BenC, ack
[16:17] <apw> BenC, i've pushed up what ought to be the right changes, could you do a build test, your kit is sooo much faster than mine
[16:18] <BenC> apw: starting a full build now
[16:32] <rtg> ppisati, is there any reason to call the new flavour generic-lpae as opposed to just lpae ? or maybe arm-lpae 'cause it _is_ specific to arm.
[16:33] <apw> rtg, well generic-<variant> the first part imples it is meant to be a common image for all systems ... right ?
[16:33] <ppisati> rtg: no reason, but that's what we had in x86 before (e.g. generic-lpae), wasn't it?
[16:33] <apw> in the smae vein as generic/generic-pae in x86
[16:33] <ppisati> and i think i heard someone sayign that the lpae version of arm should have been called generic-lpae
[16:34] <bjf> ppisati, are you going to respin precise ti-omap4 ?
[16:35] <ppisati> bjf: isn't it just a bluetooth fix?
[16:35] <bjf> yup
[16:35] <rtg> apw, ppisati: well, I think the 'generic' part of the flavour name is useless information. it doesn't really convey any meaning. (nor did it for x86 really)
[16:37] <apw> rtg generic is what we call kernels for things which arn't machine specific
[16:38] <apw> it has to have some name, well where we have a default variant
[16:38] <infinity> rtg: I can agree with the "it doesn't convey anything", but be consistent.  If you want to take it off the ARM kernels, ditch it from x86 too.  And that's way more effort than matters.
[16:38] <infinity> (In other words, don't bother)
[16:39]  * rtg is just stirring the mud, and doesn't _really_ care all that much.
[16:44] <ppisati> pull sent
[16:44] <rtg> on the other hand, I really don't want to give the x86 32 bit folks any hope that we might someday reinstate support for x86 LPAE.
[16:47] <apw> they will have to get that past you
[16:47] <rtg> I still get hate mail once in awhile
[16:49] <rtg> cyphermox, sforshee: if I've 2 APs with similar characteristics, but one has clearly inferior signal strength, why would NM _ever_ choose the weaker one on resume ?
[16:49] <apw> rtg, we should hold off merging this new flavour until we get the new buildds
[16:49] <apw> rtg, as we will be moving to 24 hours to build
[16:50] <rtg> apw, I can merge but just not enable the flavour in armhf.mk
[16:50] <apw> rtg, sure makes sense
[17:03]  * ppisati -> EOD
[17:04] <rtg> ppisati, CONFIG_KVM_ARM_MAX_VCPUS=0 ? the default is 4.
[17:05] <cyphermox> rtg: could it be a 2.4Ghz and the other a 5?
[17:06] <rtg> cyphermox, both are BG only
[17:34]  * rtg -> lunch
[19:52]  * rtg -> EOD