[00:09] <matttbe> stgraber, kees: it seems that the apport bug is not fixed => http://pastebin.com/BXMyNmJR
[00:10] <matttbe> or https://bugs.launchpad.net/ubuntu/+source/apport/+bug/767829
[00:12] <ScottK> Apport upgrade still failing with the new one.
[00:12] <ScottK> Setting up apport (1.20.1-0ubuntu4) ...
[00:12] <ScottK> start: Job failed to start
[00:12] <ScottK> invoke-rc.d: initscript apport, action "start" failed.
[00:12] <ScottK> dpkg: error processing apport (--configure):
[00:12] <ScottK>  subprocess installed post-installation script returned error exit status 1
[00:12] <ScottK> (I did not manually fix the problem with ubuntu3)
[00:13] <ScottK> stgraber: ^^^
[00:13] <kees> hm, yeah, build log shows the wrong dh_installinit invocation
[00:14] <kees> dh_installinit -papport  "true"
[00:14] <cjwatson> hmph, I should have caught that
[00:14] <cjwatson> getting tired
[00:15] <kees> DEB_DH_INSTALLINIT_ARGS="--error-handler=true"   iiuc
[00:15] <kees> (is what it should be?)
[00:15] <kees> cjwatson: shall I fix it?
[00:16] <cjwatson> please.  and drop the spurious quotes while you're at it
[00:16] <kees> yuppers
[00:33] <sladen> cjwatson: +1 for spotting the %ss <-> %sp
[00:33] <cjwatson> thanks.  quite pleased with finding that. :)
[01:21] <poolie> can i do anything to escalate https://bugs.launchpad.net/bugs/749817 ?
[01:21] <poolie> for people with thinkpads (and it seems to affect many of them) it's a fairly serious regression
[01:31] <lifeless> raof was talking about that in #ubuntu-desktop before
[01:32] <RAOF> poolie: And bryceh was organising some kernels to test.
[01:33] <poolie> well, if you want testers, just ping me
[01:33] <poolie> if you were still in sydney i would lend you my laptop if that helped
[01:34] <stgraber> cjwatson, ScottK: doh, my bad, I did some test outside the branch, then applied manually to the branch ... Seems like I forgot --error-handler ...
[01:34] <stgraber> sorry for that
[01:35] <ScottK> It happens.
[01:41] <ScottK> kees: Fixed apport accepted.
[01:41] <ScottK> stgraber: ^^^
[01:54] <bryceh> poolie, yep, I have some things for you to test.
[01:55] <stgraber> ScottK: thanks
[01:56] <stgraber> kees: and thanks for uploading the fix I meant to upload ;) /me should stop trusting memory and believe more in "cp" instead
[01:57] <poolie> bryceh, sure just ask
[01:57] <poolie> is there any current plan or forecast on when ubuntu will drop python 2.x?
[02:00] <bryceh> poolie, is your system arrandale graphics?
[02:01] <bryceh> yep it is
[02:01] <bryceh> poolie, ok I recognize the bug
[02:11] <bryceh> poolie, alright check your bug; I posted two things I'm having people with these bugs test.
[02:18] <poolie> don't see anything yet...
[02:27] <kees> stgraber: cool, no worries
[03:55] <bdmurray> apport still doesn't seem well bug 767997
[03:58] <poolie> bryceh: i'm happy to say that kernel seems to have fixed it
[05:08] <ScottK> poolie: Not for a long time.
[05:59] <ohsix> grr is the drag & drop problems w/compiz going to be rectified, happens sometimes, other times not
[06:04] <ScottK> ohsix: #ubuntu-desktop is probably a better place to find people who would know the answer to that.
[06:04] <ScottK> kees: That worked (apport).  Thanks.
[06:04] <ohsix> it was mostly rhetorical, i'm amending the one bug i did report; as i've pretty much isolated it to compiz
[06:06] <YokoZar> hmm, dpkg installation error of apport package...I wonder if reporting it will generate a some sort of logical black hole
[06:06] <ScottK> YokoZar: Fixed. Wait for an update on a mirror near you.
[06:06] <YokoZar> Indeed.  Still it does pose a logical quandry.
[06:07] <ScottK> Agreed.
[06:07] <ScottK> My question to my wife tonight was, "Want to hear some computer related irony?"
[06:09] <ohsix> YokoZar: that was something in the post-install script about failure starting, it just moved from enabled=1 in /etc/default/apport before that update, i just enabled it again to get it to installed; but a new package has been uploaded already that properly ignores startup failure
[06:17] <stgraber> YokoZar: well, I found it even funnier as the specific update was meant to turn it off :) Instead it got triggered on anyone who upgraded to that version.
[06:18] <ohsix> that was cute, yea
[06:19] <ohsix> how did it update my changes in /etc/default anyways; i always have it enabled, i thought that was one of the config protect directories, does one of the hooks just force change it?
[07:12] <cjwatson> ohsix: if you haven't changed the conffile locally, package changes to it are applied automatically
[07:13] <ohsix> cjwatson: but i had, i had enabled=1 in there before i upgraded to natty alpha
[07:14] <jubei> hello :) Not sure if this is the right place to be asking. I've already asked in Eclipse to no avail. I'm trying to write C++0x on linux with Eclipse CDT. I want to use std::unique_pointer and even though gcc compiles it fine, I don't get normal auto-complete when i do std:: ... it only gives me the old std classes/templates. Any ideas on how to pursue this?
[07:19] <steveire> What's the bzr equivalent of git pull ?
[07:19] <lifeless> bzr pull
[07:21] <steveire> thanks
[07:21] <pitti> good morning
[07:21] <pitti> cjwatson: xulrunner> yeah, same problem as with openjade, it's a preferred alternative build dep in universe
[07:22] <RAOF> Of course, bzr pull is not a complete equivalent for git pull; git does madness on pull, wheras bzr just does what you'd expect :)
[07:22] <pitti> Ampelbein: presumably this has been fixed by kees' latest upload?
[07:22] <pitti> stgraber, ScottK: ^
[07:23] <ScottK> Yes.
[07:23] <ScottK> It fixed it for me.
[07:23] <pitti> kees: thanks
[07:25] <didrocks> good morning
[07:25] <ohsix> RAOF: separate fast forward?
[07:26] <RAOF> ohsix: Well, it'll pull other changes to other branches from the same remote (but not apply them), and it'll perform a merge if you're not careful :)
[07:26] <YokoZar> so were we calling this beta 3, release candidate, or neither?
[07:27] <pitti> YokoZar: we call it "natty"?
[07:27] <pitti> like, in the final?
[07:27] <YokoZar> I'm trying to make sense of "Release Quality Iteration" on the schedule
[07:27] <YokoZar> https://wiki.ubuntu.com/NattyReleaseSchedule
[07:28] <bryceh> pitti, btw when do the apport hooks get disabled?  Right at release or shortly before?
[07:28] <pitti> it means that today we should have buildable images without inconsistencies, and keep it that way until final
[07:28] <pitti> bryceh: crash reports got disabled with the upload from yesterday
[07:29] <bryceh> pitti, ah ok
[07:29] <pitti> bryceh: but that only affects signal and python crashes; I believe teh package install failures continue to happen
[07:29] <bryceh> pitti, does that include the apport-gpu-freeze hook?
[07:29] <pitti> bryceh: I'm not actually sure about the GPU freezes
[07:29] <bryceh> pitti, ok, please flip that off whenever it's convenient
[07:29] <pitti> the udev rule doesn't
[07:29] <bryceh> I was still getting new ones filed today (at least, as of several hours ago)
[07:29] <pitti> bryceh: ah, the hook checks
[07:29] <pitti>     if not packaging.enabled():
[07:29] <pitti>         return -1
[07:30] <pitti> bryceh: presumably because not everyone upgraded yet?
[07:30] <bryceh> oh maybe, yeah
[07:30] <pitti> so it sohuld be disabled now
[07:30] <bryceh> ok great
[07:44] <YokoZar> slangasek: ia32-libs contains some of the packages that are in krb5, which was just updated to be a multiarch thing.  How to proceed?
[07:44] <slangasek> YokoZar: how do you mean, "just updated"? krb5 was part of my initial batch
[07:45] <YokoZar> oh it seems it was a security team update nm
[07:45] <YokoZar> still fetch and build is complaining about an unavailable version, which it usually only does when an upload was recent and source/binary differ in the archive
[07:48] <ohsix> http://blog.kevinmehall.net/2010/bringing_pin_tab_to_wnck wow that's a great idea
[07:49]  * pitti revives the 6 died armel buildds; be team players!
[07:52] <Sweetshark> pitti: have they been exhausted by the load?
[07:52] <pitti> annonaceae keeps failing, but it seems the others are on duty again
[07:53] <pitti> Sweetshark: lamont didn't feed the hamsters enough :)
[07:53] <Sweetshark> pitti: ohh, thats just mean!
[07:54] <ScottK> YokoZar: krb5 was uploaded to -security.
[07:55] <YokoZar> ScottK: it's strange because the apt in ia32-libs fetch-and-build script is returning " E: Ignore unavailable version '1.8.3+dfsg-5ubuntu2.1' of package "  but I can apt-get source that easily
[07:55] <ScottK> Does it look in all pockets?
[07:56] <YokoZar> main/universe, natty natty-updates natty-security
[08:00] <ScottK> OK.
[08:01] <dholbach> good morning
[08:01] <ScottK> No idea then.
[08:01] <YokoZar> http://pastebin.ubuntu.com/596813/
[08:02] <ScottK> It looks like it's fetching krb5
[08:02] <ScottK> Fetching source krb5 1.8.3+dfsg-5ubuntu2 for libkrb5-3
[08:02] <YokoZar> oh wait a minute
[08:03] <ScottK> It claims unavailable at the end though
[08:04] <ScottK> Dunno.  Need to crash.  Good luck.
[08:05] <YokoZar> Thanks for thinking on it, good night
[08:12] <YokoZar> ScottK: ah hah, figured it out.  Turns out the "sort" command does not think that 2.1 > 2, but apt ordering does.
[08:12] <YokoZar> I think
[08:19] <YokoZar> Actually nevermind we may have another edge case bug in apt...
[08:19] <YokoZar> apt-get -d source krb5=1.8.3+dfsg-5ubuntu2 krb5=1.8.3+dfsg-5ubuntu2.1
[08:20] <YokoZar> both commands work individually
[08:35] <abhinav-> I am not able to upgrade to natty using the latest live iso, bug 768105 :-/
[08:42] <cjwatson> abhinav-: thanks
[08:44] <abhinav-> cjwatson: :)
[09:03] <cjwatson> Daviey: any word on reproducing bug 728088?
[09:37]  * abhinav- is puzzled on receiving an email saying that his translations have been imported for tomboy, though he didn't do any translations  
[09:38] <seb128> you did an upload probably
[09:38] <seb128> or got an update of your sponsored
[09:38] <seb128> launchpad import translations from uploaded sources so you get those with uploads
[09:41] <tjaalton> will universe freeze too? VDR is totally broken since 1.7.17 was synced from debian, since all the plugins need a rebuild, and it's best to sync them too from debian
[09:42] <abhinav-> seb128: I did propose a patch for merging, pitti merged it manually
[09:44] <seb128> abhinav-, your name is in the changelog for the upload that's why
[09:46] <micahg> tjaalton: unseeded stuff can still be sync'd until monday I think
[09:46] <abhinav-> seb128: oh thanks for clearing it up :)
[09:46] <iulian> tjaalton: We still have time.  Please file some bugs and subscribe ubuntu-release.  You can also let me know when you've done that so I can take a look.
[09:46] <tjaalton> micahg: good, I'll file sync requests then
[09:46] <abhinav-> that's nice, I get more karma :)
[09:46] <tjaalton> iulian: yeah, thanks
[09:46] <micahg> tjaalton: you can use -e with requestsync if you need an ubuntu-release ACK
[10:00] <Daviey> cjwatson: Sorry, missed the hilight.  I started doing this on tuesday, but seemed to have an unrelated issue with iscsi target.. I haven't dropped it, and will pick it back up today.  Sorry for the slow update.
[10:01] <cjwatson> Daviey: no problem, thanks - just checking up since skaet was asking me about it
[10:06] <Daviey> cjwatson: When you attempted to reproduce it, were you PXE booting or using local media?
[10:06] <cjwatson> Daviey: hm, I think local
[10:07] <cjwatson> only for the kernel and initrd though, which I wouldn't have expected to matter
[10:07] <Daviey> It /shouldn't/ be related, but that is a difference i will explore.
[10:08] <cjwatson> I think I did kvm -kernel -initrd -append
[10:08] <cjwatson> (etc.)
[10:08] <Daviey> ahh
[10:37] <tjaalton> micahg: yeah, filing them now
[10:44] <tjaalton> looks like the autosyncer didn't work properly, since some of these plugins have had releases that during the sync-period that didn't get synced
[10:47] <micahg> tjaalton: does ubuntu have a diff on any of them?  that would prevent them from being sync'd (BTW, auto import ended 30 Dec)
[10:48] <tjaalton> micahg: no, they were synced during maverick
[10:48] <cjwatson> what packages are these?
[10:49] <tjaalton> most of these only got a release for the new vdr version
[10:49] <cjwatson> some packages are blacklisted from autosyncing for one reason or another
[10:49] <tjaalton> cjwatson: let me check
[10:50] <tjaalton> vdr-plugin-osdteletext for one
[10:50] <tjaalton> _if_ the debian changelog is to be trusted
[10:50] <tjaalton> it could be that they weren't actually uploaded there, but to the e-tobi.net repository
[10:51] <tjaalton> hmm though they tend to use a different suffix then
[10:51] <micahg> tjaalton: http://packages.qa.debian.org/v/vdr-plugin-osdteletext.html, no upload until 2011-04-11
[10:52] <tjaalton> micahg: right, sorry for the noise :)
[10:53] <micahg> tjaalton: no problem, better to ask to be sure :)
[10:53] <tjaalton> 24 plugins in total, halfway through filing the bugs..
[11:07] <chrisccoulson> jam - there?
[11:23] <doko> ScottK: does boost-1.46 build with GCC-4.6?
[11:26] <pitti> tjaalton: ugh, a single bug with several task would have been easier..
[11:26] <ogra_> dholbach, my calendar shows i'm sponsoring next monday, shouldnt we postpone all sponsoring for that week, since the archive will be hard locked ?
[11:27] <ogra_> (i know i can do stuff without uploading, but it feels kind of pointless wiht a locked down archive)
[11:27] <dholbach> ogra_, we can still do SRU stuff or just review patches and upload them later or forward upstream - there's always something to do :)
[11:27] <ogra_> hmm,k
[11:28] <wolfe> what's SRU?
[11:28] <wolfe> I don't think it means Strategic Response Unit :P
[11:28] <dholbach> https://wiki.ubuntu.com/SRU
[11:29] <wolfe> ah okay :) I've done one of those for ubuntu before, I thought the acronym sounded familiar
[11:30] <wolfe> :( now it makes me curious, I haven't tried python-fam in the latest ubuntu, that broken code better not have reverted
[11:30]  * wolfe dislikes segfaulting python interpreters
[11:30] <wolfe> *scripts/programs
[11:34] <wolfe> oh bloody hell
[11:34] <tjaalton> pitti: yeah, well this way you get to see the changelog diffs :)
[11:34] <wolfe> that maintainer never updated the code, it is an abandoned project. I bet python-fam in Ubuntu is broken in the latest release
[11:57] <jam> chrisccoulson: I'm here now
[11:58] <chrisccoulson> jam, i reported bug 752919 a few weeks ago, and that got marked a duplicate of a bug which is fix released (which you are assigned too)
[11:58] <chrisccoulson> i'm just wondering if there's anything i can do, because i'm committing a lot of stuff to this branch locally, but i can't push it launchpad :(
[11:58] <jam> chrisccoulson: 2 things
[11:58] <jam> 1) upgrade your bzr
[11:58] <jam> 2) run 'bzr pack'
[11:59] <chrisccoulson> jam, what version do i need to upgrade too?
[11:59] <jam> the latter will find all the "missing" inventories and put them back together with their associated other content
[11:59] <jam> (it actually puts everything into 1 file so it is always together)
[12:00] <jam> chrisccoulson: according to the tracker, the fix is present in bzr-2.1.4, 2.2.5, and probably 2.0.7, 2.3.1/2 and 2.4b1. I'm not sure what has gone through final packaging.
[12:00] <jam> I know 2.4b1 is available in the ppa
[12:00] <jam> and probably 2.3.1
[12:00] <chrisccoulson> ok, i'm running 2.3.1 currently
[12:01] <jam> hmmm. Its listed as being fixed in 2.3.1, let me check
[12:01] <jam> chrisccoulson: ahh!!
[12:01] <jam> *launchpad* is running bzr-2.2
[12:01] <jam> and doesn't have the fix
[12:01] <jam> so you have to run "bzr pack lp:..."
[12:01] <chrisccoulson> oh, bzr pack seemed to work :)
[12:01] <jam> until Launchpad itself upgrades the server version of bzr
[12:02] <chrisccoulson> yay, it worked (http://bazaar.launchpad.net/~extension-hackers/globalmenu-extension/trunk/revision/145)
[12:02] <chrisccoulson> jam, thanks! :)
[12:45] <\sh> micahg, ping ZF...if you want, please take care of ZF while I'm on holiday for the next 6 weeks :) thx :)
[12:46] <bdrung_> doko: can you help us with an objcopy question / behaviour / bug?
[12:49] <bdrung_> doko: git clone git://git.debian.org/lintian/lintian.git
[12:49] <bdrung_> doko: then run debian/rules runtests onlyrun=binaries-general
[12:51] <bdrung_> file debian/tests/binaries-general/binaries-general-1.0/basic returns ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
[12:51] <bdrung_> the makefile calls objcopy --only-keep-debug basic $(DESTDIR)/usr/lib/debug/basic
[12:52] <bdrung_> file debian/tests/binaries-general/binaries-general-1.0/debian/binaries-general/usr/lib/debug/basic returns ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
[12:52] <bdrung_> doko: why does the library change from dynamically linked to statically linked?
[13:57] <barry> ev, cjwatson probably too late to do anything about it right now, but someone forwarded me a ubiquity failure on samsung series 9: bug 766740
[14:00] <cjwatson> barry: conveniently without any useful logs
[14:00] <barry> yeah ;)
[14:01] <cjwatson> (I've asked)
[14:01] <cjwatson> barry: I notice that he's using GPT, so it's possible that he's also using EFI in which case it's bug 765270 (fixed)
[14:01] <cjwatson> well, fixed in tomorrow's dailies anyway
[14:02] <barry> cjwatson: thanks, i'll forward that to him
[14:16] <ogra_> looking at bug 747229 ... is it even an oem-config UI i see there or is that just a debconf mode of aptd ?
[14:18] <cjwatson> ogra_: it's oem-config
[14:18] <ogra_> (in the graphical oem-config it looks like aptd)
[14:18] <ogra_> k
[14:43] <ScottK> doko: I didn't try to build it.
[14:59] <mterry> jcastro, does the naming scheme for oneiric blueprints no longer prefix the track type (like appdev or whatnot)?
[14:59] <jcastro> mterry: it does the tracknames are just back to normal
[15:00] <jcastro> mterry: you'd be desktop-o-dejadup
[15:02] <mterry> jcastro, OK.  Yeah, the deja dup one was made already, but now looking at quickly.  Quickly had a natty one too, but I assume since the -n- or -o- is part of the name, I should make new blueprint rather than rename the old one?
[15:10] <jcastro> mterry: it's up to you, I prefer to just rename
[15:41] <bdmurray> pitti: I wrote a bug pattern for bug 767829 and it works with test-local on the bug and a duplicate that got through (bug 768261)
[15:46] <pitti> bdmurray: oh, thanks
[15:46] <bdmurray> pitti: I'm curious why the duplicate got through even though there is a pattern
[15:46] <pitti> bdmurray: oh, you mean it came through after you wrote it?
[15:47] <bdmurray> pitti: yeah
[15:47] <pitti> hm, it looks good from here
[15:49] <pitti> it's also on people.c.c.
[15:49] <bdmurray> pitti: could it be related to bug 766516?  would maverick apport check for patterns named after the package?
[15:50] <pitti> bdmurray: yes, it would
[15:50] <pitti> but the bug didn't affect maverick in the first place
[15:51] <bdmurray> pitti: but if they were in the process of a dist upgrade?
[15:51] <pitti> bdmurray: that would work, yes
[15:51] <pitti> "work" -> cause this
[15:52] <ScottK> Does the desktop-file-utils in queue affect systems where software center isn't installed?
[15:52] <bdmurray> he first example wasn't a dist-upgrade but bug 768125 is
[15:54] <bdmurray> that one wouldn't match though because the attachment name is different though
[16:05] <bdmurray> pitti: I see you've cleaned up the dupes.  Is it a good idea to expand the bug pattern?
[16:06] <pitti> bdmurray: I didn't really go through them all; I just duped all package failures that came in in the last 24 hours
[16:06] <pitti> bdmurray: I think it'll quickly fade down now, but if we get many more, we might expand it, yes
[16:08] <bdmurray> pitti: okay, thanks. maverick not using bugpatterns.xml isn't going to create that many additional bugs I think.  What do you think?
[16:08] <pitti> bdmurray: right; I think bug patterns are very short-lived
[16:09] <pitti> and in fact it probably would make sense to clean up patterns for bugs which were fixed more than, say, a month ago, to avoid false positives
[16:10] <bdmurray> I wish patterns were automatically or semi-automatically written too
[16:10] <pitti> we really need a more generic way of extracting the gist out of an apt log, then we could use the auto-duper
[16:50] <abhinav-> when will ubiquity 2.6.7 make to the daily iso , today's ISO also had 2.6.6 ?
[16:52] <ev> abhinav-: the next daily live will have ubiquity 2.6.7
[16:52] <ev> either tonight or tomorrow morning
[16:52] <cjwatson> well, 2.6.8 :)
[16:52] <abhinav-> ev: oh great, I am eagerly waiting to upgrade :)
[16:52] <ev> err yes, 2.6.8
[16:52] <ev> :)
[17:12] <smoser> anyone know how i would configure firefox's home page for a new user ?
[17:17] <tumbleweed> smoser: you mean how you would configure it for all users? or just a programmatic way to change it for one user?
[17:17] <smoser> either woudl be suitable for this.
[17:17] <smoser> user is brand new, no .mozilla directory
[17:18] <tumbleweed> smoser: add something like pref("browser.startup.homepage", "file:/etc/firefox-homepage.properties"); to /etc/firefox-$VER/pref/ubufox.js
[17:19] <tumbleweed> then put browser.startup.homepage=http://foo.bar in that file
[17:19] <tumbleweed> (at least that's how we did it in ff 3.x)
[17:22] <LLStarks> spamaps, if i've lost VT access, would upstart be to blame?
[17:23] <SpamapS> LLStarks: probably not. When you say lost it, alt-F1 doesn't give you a getty?
[17:23] <SpamapS> LLStarks: I tend to blame plymouth first. ;)
[17:23] <SpamapS> because I understand it less
[17:23] <LLStarks> spamaps: no. and neither does recovery console.
[17:24] <SpamapS> LLStarks: have you tried booting with 'quiet' removed, and '--verbose'  on the kernel cmdline ?
[17:24] <LLStarks> i can try. i also have bootcharts at the ready.
[17:25] <smoser> tumbleweed, hm... http://paste.ubuntu.com/597036/ like that ?
[17:25] <LLStarks> brb.
[17:25] <ScottK> Someone else was complaining about lost VTs recently.
[17:25] <ScottK> I don't recall who.
[17:26] <TeTeT> smoser: should work, I can send you a hook file for this on custom builds, if needed
[17:26] <SpamapS> ScottK: I reproduced the opendkim thing *FINALLY*
[17:26] <ScottK> SpamapS: Cool.
[17:27] <smoser> TeTeT, doesn't seem to work for me.
[17:27] <SpamapS> ScottK: had to add ssh key and sudo NOPASSWD: ALL to make it break
[17:27] <ScottK> Lovely.
[17:27] <SpamapS> definitely a race between the parent exitting and setsid()
[17:27] <smoser> for that user i had already ran firefox, but then i did 'rm -Rf ~/.mozilla'
[17:27] <SpamapS> ScottK: so I may have a tiny patch :)
[17:27] <ScottK> Nice.
[17:28] <ScottK> Fortunately it's Universe so we have a few days for a fix yet.
[17:29] <LLStarks> yeah, still no VT. it might be related to the fact that a recovery boot will never finish. it'll just halt after loading bluetooth and usb
[17:29] <LLStarks> or something like that
[17:29] <SpamapS> LLStarks: try 'nosplash' too
[17:30] <LLStarks> isn't nosplash inherent to recovery boot?
[17:30] <LLStarks> whatever. brb again.
[17:31] <cjwatson> SpamapS: what do you believe implements nosplash?
[17:31] <SpamapS> cjwatson: I don't actually know. :)
[17:31] <cjwatson> (hint: nothing)
[17:31] <cjwatson> usplash used to ...
[17:32] <SpamapS> I am mostly fishing for something I'm familiar with outside of upstart.
[17:32] <SpamapS> because I don't know of anything in upstart that would cause vt's to go away... unless the getty's aren't starting for some reason
[17:33] <cjwatson> recovery mode options on the kernel command line automatically cause plymouth to go into details mode, much as LLStarks suggests
[17:33] <cjwatson> (src/main.c:plymouth_should_show_default_splash)
[17:33] <SpamapS> but yeah I don't know *anything* about how recovery console is implemented. :-P
[17:34] <LLStarks> still nothing with nosplash. i am running a custom plymouth, but also affects a fresh install.
[17:39] <SpamapS> LLStarks: did this just start today?
[17:41] <LLStarks> spamaps, no. this has been around since at least the start of the natty cycle.
[17:41] <LLStarks> well, maybe the beginning, but at least a few months.
[17:41] <LLStarks> *maybe not
[17:42] <SpamapS> whats your graphics hardware?
[17:42] <LLStarks> i945gm
[17:42] <LLStarks> i'd file a bug, but i'm not sure what package applies
[17:45] <LLStarks> os[Linux 2.6.38-8-generic i686] distro[Ubuntu "natty" 11.04] cpu[2 x Genuine Intel(R) CPU           T2050  @ 1.60GHz (GenuineIntel) @ 1.60GHz] mem[Physical: 2.0GB, 74.4% free] disk[Total: 115.2GB, 16.2% free] video[Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller] sound[HDA-Intel - HDA Intel]
[17:45] <JFo> LLStarks, file against linux with the lower case L
[17:45] <JFo> should send you my way
[17:47] <LLStarks> jfo, i can understand the loss of vt for an X boot, but would that also explain how a recovery boot doesn't even reach the recovery menu?
[17:48] <JFo> something odd afoot for sure
[17:48] <LLStarks> jfo: bug 768452
[17:48] <JFo> danke
[17:48]  * JFo goes to look
[18:02] <cjwatson> blueyed,mvo: this late zsh upload added a new build-dependency on yodl, which isn't in main
[18:03] <cjwatson> blueyed,mvo: I'm not convinced there's time to get yodl and icmake MIRed and promoted.  Can it please be excised?
[18:03] <cjwatson> (http://people.canonical.com/~ubuntu-archive/component-mismatches.txt)
[18:09] <SpamapS> ScottK: so with opendkim, moving setsid() before closing/duping the FDs didn't work.. trying some more drastic things.
[18:09] <ScottK> Thanks.
[18:10] <SpamapS> ScottK: definitely an interesting problem. I can reproduce 100% of the time now
[18:10] <ScottK> It's probably worth an email to the opendkim list saying you've reproduced it and are investigating.
[18:10] <ScottK> Cool.
[18:10] <ScottK> Please remember not to break BSD with your fix since that's upstream's native platform.
[18:15] <SpamapS> ScottK: I'll try it out on my netbsd VM :)
[18:16] <ScottK> :-)
[18:16] <SpamapS> I keep one around for testing libedit's complete and utter brokenness on Linux
[18:21] <pitti> cjwatson, mvo, blueyed: ok for me to just upload a reverted zsh?
[18:22] <cjwatson> pitti: I don't have a problem with it, but would be good for one of the uploaders to reply
[18:23] <pitti> I know, but it's getting tight
[18:23] <pitti> cjwatson: I'll prepare one and upload, then we have it in the queue
[18:23]  * cjwatson nods
[18:23] <cjwatson> I'm away as of now, though
[18:24] <pitti> cjwatson: enjoy the Easter weekend!
[18:24] <cjwatson> you too :)
[18:37] <mvo> pitti: sorry, sorry, I should have looked close, I have no personal attachment to this, feel free to revert
[18:39] <Cas07> i have a question about backporting a pygtk patch for ubuntu
[18:39] <Cas07> https://bugs.launchpad.net/bugs/708847
[19:00] <ScottK> !ask | Cas07
[19:08] <bryceh> is there a python module to do the equivalent of apt-cache show %s | grep ^Source ?
[19:08] <Cas07> ok I am wondering who can help get the recent pygtk patch http://git.gnome.org/browse/pygtk/commit/?id=4cbd3 backported to the ubuntu releases as the pygtks devs do not patch old versions. https://bugs.launchpad.net/bugs/708847
[19:08] <pitti> bryceh: python-apt can do that quite nicely
[19:09] <bryceh> pitti, thanks
[19:09] <pitti> bryceh: import apt
[19:09] <pitti> apt.Cache()['mypkg'].candidate.source_name
[19:09] <bryceh> nice
[19:09] <pitti> you need to do some error checking of course, candidate might be None
[19:09] <pitti> you can also use "installed" for the installed version (if it is installed)
[19:09] <pitti> but I guess for your case candidate is better
[19:10] <bryceh> yep
[20:12] <micahg> SpamapS: are you available for an SRU review?
[20:15] <SpamapS> micahg: Sure
[20:15] <micahg> SpamapS: bug 767966, I need to know if it's ok to push with the next round of security updates
[20:16] <LLStarks> jfo, need any additional info about my machine?
[20:18] <SpamapS> micahg: reading
[20:20] <SpamapS> micahg: I'm somewhat confused by the bug statuses .. what exactly do you want me to look for?
[20:21] <SpamapS> micahg: I see no test case, and I don't see it confirmed in any release.. just Fix Committed
[20:21]  * SpamapS goes afk for 5-10 min
[20:21] <micahg> SpamapS: ignore the statuses, I need to know if the change would be approved for an SRU and if I can include it in a security update given that I'll be running through regression tests for Firefox and Thunderbird
[20:25] <maco> geser, stgraber, cody-somerville, Laney, bdrung_:  it's been a week.
[20:26] <cody-somerville> maco, since last Friday? :)
[20:26] <cody-somerville> oh my
[20:26] <cody-somerville> Its Thursday, not Friday.
[20:26] <maco> cody-somerville: the emails were sent on the 14th...it's the 21st
[20:27] <stgraber> maco: I'm sitting next to cyphermox and we talked quite a bit last night so I don't have any question for him :) And I'm happy with the question that have been asked to Sylvestre, would just like to see some answers ...
[20:27] <cody-somerville> maco, which e-mails? Sorry, you'll have to jot my memory. I just got my wisdom teeth removed last evening. Pain meds have me a little out of it.
[20:27] <cyphermox> stgraber, you pang?
[20:28] <stgraber> oh hey cyphermox, long time no see
[20:28] <maco> cody-somerville: the 2 motu applications and 1 core dev application we're processing by email
[20:28] <maco> cody-somerville: today's the last day to pester them with questions, then we spend the weekend thinking & voting
[20:29] <stgraber> I'd also like to see RAOF answering Laney's questions (unless he did and that never made it to devel-permissions).
[20:32] <stgraber> so I'm fine voting on cyphermox's application as he answered all the questions that have been asked on the ML (AFAICS) but would rather wait for the two others
[20:36] <maco> RAOF: ping. answer questions on email ;-)
[20:37] <maco> and sylvestre isn't an irc person, so more pinging than the 3 emails in his inbox won't help
[20:37] <maco> i'm fine voting on cyphermox's too
[20:48] <SpamapS> micahg: the one red flag I have is that while polluting the global namespace is evil, if we do release w/ it this way, and people depend on that, then we change it.. we break those that depend on the behavior.
[20:48] <SpamapS> micahg: that said, thats in the "regression potential == LOW" category..
[20:49] <SpamapS> micahg: so yeah, I think I'd approve it through to -proposed
[20:49] <micahg> SpamapS: I don't think anyone would be depending on that behavior, also it's already been fixed "upstream"
[20:50] <micahg> SpamapS: do you approve it for me to include in the next security update?
[20:50] <SpamapS> micahg: Hrm.. I was evaluating it from the stand point of having it sit in -proposed for 7 days..
[20:51] <SpamapS> micahg: but you guys do testing probably twice as rigorous as -proposed -> -updates requires
[20:51] <SpamapS> micahg: so yes!
[20:51] <micahg> SpamapS: thanks!, I'll make sure we start testing the global menu with natty as well :)
[20:52] <micahg> SpamapS: could you please note that in the bug?
[20:54] <SpamapS> micahg: done
[20:55]  * SpamapS will now go for his first ever bike ride on the insane streets of Los Angeles.. wish me luck
[20:56] <micahg> SpamapS: thanks!
[20:56] <soren> SpamapS: It was nice knowing you.
[21:15]  * SpamapS still hasn't left due to the safety precautions he's reading about last minute
[21:18] <charlie-tca> Good luck and have fun, SpamapS
[21:19] <lamont> why would I have 187 irqbalance processes on a machine?
[21:19] <charlie-tca> I used to ride on the strip in Las Vegas
[21:19] <lamont> does it just want to be REALLY REALLY balanced?
[21:20] <soren> lamont: Do you have 187 cores?
[21:20] <lamont> 2.  I have 2 cores.
[21:21] <soren> lamont: Then I don't know.
[21:21] <soren> :p
[21:21] <lamont> I am a powermac running 2.6.35 on a lucid user base
[21:21] <lamont> IBM XServe, to be precise
[21:21] <lamont> I suspect that everytime udev gets installed in the livecd build, we get a new irqbalance process
[21:22] <lamont> soren: and thanks for the laugh
[21:22]  * soren tips his hat
[21:22]  * slangasek grins
[21:23] <soren> 187 would be a spectacular number of cores.
[21:23] <soren> Much more so than e.g. 256.
[21:24] <broder> now i want to start selling machines with prime numbers of cores or something, and have a bunch of marketing material that claims that makes the scheduling better or something
[21:24] <soren> Like... 2?
[21:24] <soren> That'd be something.
[21:25] <soren> :p
[21:25] <slangasek> I assume 187 processors is done as 17 tiles of 11-way cores
[21:25] <slangasek> you know, so that it scales symmetrically
[21:25] <maco> broder: pull some reasoning from http://designfestival.com/the-cicada-principle-and-why-it-matters-to-web-designers/ ?
[21:28] <lamont> slangasek: heh
[21:29] <lamont> in other news.... is it expected that after I type "reboot" on my laptop (inspiron N5010) that after ignoring it for a good long while, I finally use the "5 seconds of holding down the power switch" and another gentle push to complete that reboot?
[21:29] <lamont> I seem to remember that command used to function without operator involvement
[21:30] <maco> sounds like a bug to me
[21:32] <lamont> maco: yeah.. my thinking follows that line too.  OTOH, sometimes my flair for the written word and such just gets the better of me
[21:32] <lamont> soren: I think he means large primes
[21:33] <lamont> .... like 3.
[21:33] <soren> lamont: We'll know once we see the marketing material.
[21:34] <lamont> but will we truly?
[21:34] <lifeless> lamont: reboot -n
[21:35] <lifeless> lamont: or was the -n implied?
[21:35] <lamont> lifeless: sudo /sbin/reboot
[21:35] <lifeless>        When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call itself and directly reboots the system.  Otherwise this simply invokes the shutdown(8) tool with the appropriate arguments.
[21:35] <lamont> the pretty cylon/kit-car thing continues sweeping, but no response to keyboard or other visible changes in the machine behavior
[21:36] <lamont> lifeless: right
[21:36] <lifeless> hmm, by my reading sudo /sbin/reboot
[21:36] <lifeless> should be an error reporting 'no time' :)
[21:37] <lamont> ??
[21:37] <lamont> without args, reboot is equivalent to "reboot now"
[21:37] <soren> Wow, that was *incredibly* annoying.
[21:37] <lamont> soren: lifeless can be that way
[21:37] <soren> I ran "sudo reboot -h" to get its help output thing.
[21:37] <lamont> that's why we love him
[21:37] <soren> ...and it rebooted instead.
[21:37] <lamont> no, it halted
[21:37] <lifeless> soren: doofus :)
[21:38] <lamont> soren: awesome
[21:38] <soren> lifeless: Yeah, not my brightest moment :)
[21:38] <doctormo> Hey dpm, I'm trying to follow your devel app week guide for internationalization.
[21:39] <lamont> soren: thank you so much for that.
[21:39] <lifeless> lamont: man reboot doesn't mention now :)
[21:39] <soren> lamont: For saving you from a similar fate?
[21:39] <doctormo> So far I have almost everything, except I can't seem to generate a pot file from what I have.
[21:39] <lifeless> lamont: and man shutdown doesn't mention the way in which reboot will call it
[21:41] <lifeless> lamont: I'm sure you are correct [I'm not going to test :P] but the docs are stale/don't mention it
[21:41] <lamont> soren: no, I know about reboot -h
[21:41] <lamont> OTOH, I'm about done laughing
[21:41] <soren> lamont: Well, thanks for sharing :(
[21:41] <soren> :p
[21:42] <doctormo> I think dpm might be out, so I throw the question out to anyone who can anwser. python/distutils/glade/i18n
[21:43] <lamont> neat.  reboot's manpage also fails to mention -h
[21:43] <lamont> ah.  hardy has -h and -n and a few other options described.  lucid and natty do not
[21:44] <maco> haha halt is a symlink to reboot
[21:44] <lamont> yep
[21:44] <smoser> stgraber, ping
[21:44] <Ampelbein> lamont: hardy didn't use upstart? (wild guess)
[21:44] <lamont> Ampelbein: prolly
[21:45] <maco> i find it funny though that "shutdown -h" and "shutdown -r" aren't just scripts calling those
[21:45] <lamont> but without options, they just do what the command name seems to indicate
[21:45] <stgraber> smoser: pong
[21:45] <smoser> did you test bug 759545 ?
[21:45] <lamont> maco: used to be that reboot did just reboot(2).  then they "enhanced" it do be an alias for shutdown
[21:45] <stgraber> nope, I suggested a fix but indicated I couldn't do the tests as the archive was in a bad state at the time
[21:45] <stgraber> smoser: why ? still having issues with it ?
[21:45] <lamont> and then there was much complaining, and reboot --force was added to get the old-n-correct behavior
[21:45] <maco> lamont: its actually its own binary
[21:46] <maco> lamont: i just checked, expecting a symlink and a check for the value of $0
[21:46] <smoser> yeah.
[21:46] <lamont> if I want to shutdown, I'll say shutdown, thank you.
[21:46] <stgraber> smoser: ok, I'll have a look once my Windows XP is done installing (to test some wubi weirdness)
[21:46] <smoser> stgraber, i started an instance of ubuntu-maverick-10.10-i386-server-20101225 .  Installed in the image is 1.98+20100804-5ubuntu3. then sudo update && sudo dist-upgrade.  That went fine.
[21:47] <lamont> but then, I've grown tired of being pedantic about that difference
[21:47] <smoser> then, sudo do-release-upgrade -d, and i got the prompt
[21:47] <stgraber> smoser: can you get the md5sum and content of /etc/default/grub before the upgrade ?
[21:47] <stgraber> smoser: the one I whitelisted was the one you have when you install 10.10 from the CD and then run a dist-upgrade
[21:47] <smoser> yeah. http://paste.ubuntu.com/597141/ is the differences i was shown.
[21:48] <stgraber> hmm, seems similar/identical to the one I whitelisted, weird ...
[21:52] <tumbleweed> smoser: sorry, was out, yes looks reasonable
[21:52] <smoser> didn't seem to work for me.
[21:54] <stgraber> smoser: test install on its way (ubuntu 10.10 amd64 server). I'll try an upgrade from that and see if it works. If it does, then it means we have a slightly different config file on EC2 or something like that
[21:54] <tumbleweed> smoser: hrm, firefox 4?
[21:55] <smoser> yeah, tumbleweed
[21:55] <smoser> stgraber, i'll test it again and get you md5sums of all files
[22:00] <kees> slangasek: weird, I don't think "dist-upgrade" works correctly with multi-arch. I always have to do "dist-upgrade", have it fail on libgcc1, then "-f install", then "dist-upgrade" again and I'm fine.
[22:00] <kees>  libgcc1:amd64 1:4.5.2-8ubuntu4 cannot be configured because libgcc1:i386 is in a different version (1:4.5.2-8ubuntu3)
[22:00] <slangasek> kees: yes, it's an apt bug, let me find the ref
[22:00] <kees> ah-ha, okay. already known. :)
[22:00] <slangasek> kees: Debian bug #618288
[22:01] <smoser> stgraber, d44898904f347a5fad10f3b4903c4c28 is what i have.
[22:02] <slangasek> kees: that's the last "I don't think I want to point users at this yet" bug
[22:02] <kees> slangasek: yeah, agreed.
[22:02] <kees> slangasek: I'd hit it before but I thought it was legit publisher churn (i.e. I didn't have i386 yet). during final freeze now I got suspicious. :)
[22:03] <stgraber> smoser: 965e5137eff659cded3adb640357c33d  maverick_1.98+20100705-1ubuntu1
[22:03] <stgraber> smoser: that's what's in the whitelist
[22:03] <Cas07> how do I go about asking an ubuntu dev to create a backport of a pygtk patch to be applied to lucid, maverick and natty?
[22:03] <smoser> 1.98+20100804-5ubuntu3 is what is installed, stgraber
[22:04] <kees> slangasek: should that bug get added to http://wiki.debian.org/Multiarch/Bootstrapping ? it's not technically bootstrapping, but it sure seems like a sensible prereq to track somewhere.
[22:04] <smoser> and what is current in maverick-updates
[22:04] <stgraber> smoser: and that matches what I have on a clean ubuntu 10.10 amd64 server install
[22:04] <smoser> so that i would think is more relevant
[22:04] <stgraber> smoser: ok, I'm doing an upgrade now, I'll see if the file changes somehow
[22:04] <smoser> ie, you're probably supposed to have dist-upgraded before do-release-upgrade, right?
[22:04] <infinity> lamont: Hrm.  Does livecd-rootfs do the same "walk proc and slaughter" dance that launchpad-buildd does?
[22:04] <smoser> stgraber, well it *will* change, right?
[22:04] <stgraber> smoser: if it doesn't then we have some EC2 magic causing the file to have a different check sum
[22:04] <infinity> lamont: If I never got around to doing that, that would probably solve your issue.
[22:04] <smoser> stgraber, why would it not change when you install the newer 1.98+20100804-5ubuntu3
[22:04] <stgraber> smoser: upgrade as in, going from release 10.10 to up to date 10.10
[22:05] <stgraber> 965e5137eff659cded3adb640357c33d is what you have on the 10.10 CD, I'm now upgrading to an up to date 10.10 to compare, then dist-upgrading to natty
[22:06] <stgraber> yeah, you're supposed to have an up to date system before dist-upgrading
[22:06] <tumbleweed> smoser: looks like it's /etc/xul-ext/ubufox.js these days
[22:06] <infinity> Cas07: File a bug, ideally including both the patch, and the reason(s) why you think it needs to be included in old releases.
[22:07] <lamont> infinity: prolly not - I've never done it either, unless I did it early on
[22:07] <Cas07> infinity: what about updating an existing bug
[22:07] <infinity> lamont: Well, hooking that into the exit trap should be trivial.
[22:08] <infinity> lamont: Let me go have a loot.
[22:08] <infinity> lamont: Or a look.
[22:08] <Cas07> infinity: oh ive found another bug that mentions something about no ubuntu-sponsors
[22:08] <stgraber> smoser: ok, I still have 965e5137eff659cded3adb640357c33d with 1.98+20100804-5ubuntu3
[22:08] <lamont> infinity: ta
[22:08] <smoser> stgraber, yesh. it is ec2. i just realized its in the image build process.
[22:08] <smoser> -GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0"
[22:08] <smoser> +GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
[22:08] <smoser> but i swear it didn't show me that.
[22:09] <stgraber> smoser: ok, so d44898904f347a5fad10f3b4903c4c28 is what I should whitelist ?
[22:09] <smoser> well that would make it better. cjwatson has never done this for me before.
[22:10] <stgraber> oh, actually, no, I shouldn't whitelist that or it'll break on upgrade
[22:10] <stgraber> well, not "break" but you'll loose your "console=ttyS0"
[22:11] <stgraber> unless it's grub's postinst that sets that value, in which case it'd be fine to add the md5sum to the whitelist
[22:13] <smoser> stgraber, no, its not grub that does it. the uec images build does it in post install modification.
[22:13] <smoser> :-(
[22:14] <stgraber> hmm, ok, then better not to whitelist that in grub and have the user see the diff. Or we'll get bug reports saying that they don't get their console output anymore (as grub would reset /etc/default/grub to a regular non-ec2 one)
[22:14] <cjwatson> yeah, I hope to rearrange the nonsense that is that postinst after natty, but I really don't recommend trying to do it in a rush - the cure might well be worse than the disease
[22:16] <smoser> cjwatson, yeah, please keep me in mind when you're doing that work.
[22:16] <smoser> i know its not ideal, but i make modifications to that file in the iamge build process.
[22:17] <smoser> the changes beign made currently are because I want to see a grub prompt on boot.
[22:17] <smoser> -GRUB_TERMINAL=console
[22:17] <smoser> +#GRUB_TERMINAL=console
[22:17] <smoser> -#GRUB_HIDDEN_TIMEOUT_QUIET=true
[22:17] <smoser> +GRUB_HIDDEN_TIMEOUT_QUIET=true
[22:19] <infinity> lamont: Err, kay, livecd.sh has a proc walk, but it very much isn't the one I wrote for lp-buildd.  It screen-scrapes ls output with grep.
[22:20] <infinity> lamont: No idea if it's working as intended and perhaps PPC is just hating you, or if it's actually broken...
[22:20] <infinity> lamont: Though, given that it's meant to loop infinitely if processes remain in the chroot, my gut is that it's perhaps not working at all. :P
[22:22] <smoser> stgraber, cjwatson i'm looking at diff shown to me by grub-pc right now, and it doesn't even show my console=ttyS0 change.
[22:26] <infinity> lamont: I'm going to test some things here, and if the livecd.sh implementation seems completely broken (and, honestly, parsing ls output pretty much always is, even when it isn't), I'll commit some sort of shiny fix.
[22:26] <lamont> infinity: heh. thanks
[22:49] <lamont> hrm.. used to be that resizing  a window, I'd see lines/columns for the window... natty dropped that, and I want it back...
[22:51] <Pici> iirc, theres a compiz option that does that.
[23:21] <stgraber> cjwatson: for some reason I'm still getting the ucf prompt on upgrade even though my current md5sum matches the one that was added to the .md5sum ...
[23:21] <stgraber> on grub upgrade that's
[23:42] <stgraber> cjwatson: we apparently have an "old" md5sum in /var/lib/ucf/hashfile that's not in the .md5sum list (and I have no idea what that md5sum matches ...)
[23:43] <lool> https://launchpadlibrarian.net/70111656/ubuntuone-client_1.6.1-0ubuntu3_amd64.changes shows that ubuntuone-client-gnome_1.6.1-0ubuntu3_amd64.deb was uploaded, yet I don't see it in the archive
[23:43] <lool> and that was built 7 hours ago
[23:56] <slangasek> lool: it's in the archive, not on the mirrors; can you poke IS?