[00:09] <mwhudson> ok
[00:09] <mwhudson> so what is git for 'bzr pull --overwrite'? :)
[00:10] <RAOF> mwhudson: “git reset --hard $ORIGIN/$BRANCH” (generally origin/master)
[00:10] <RAOF> After having run “git fetch $ORIGIN”, obviously.
[00:11] <mwhudson> RAOF: so i need to add the repo i want to blat over mine as a remote first?
[00:11] <mwhudson> right
[00:11] <RAOF> Yes.  As far as I know, the git doesn't have a concept of ‘just pull from this repository please’
[00:12] <mwhudson> i wonder what it's doing now
[00:12] <RAOF> What have you asked it to do? :)
[00:13] <mwhudson> git fetch git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
[00:14] <mwhudson> ah now it's doing things
[00:14] <RAOF> I have no idea what it's going to do :)
[00:15] <RAOF> I don't *think* it's going to do what you expect, though.
[00:16] <mwhudson> i think it fetched the objects from that repo into mine
[00:17] <mwhudson> and nothing else
[00:17] <RAOF> That seems both unusally helpful and unusually obvious for git.
[00:18] <mwhudson> i could only tell this by running diff -r on the copy of the cloned repo i made before doing anything :)
[00:18] <RAOF> I don't suppose git branch -a shows some new remote branches?
[00:19] <mwhudson> nope
[00:20] <mwhudson> so how do i add the branches from a remote?
[00:21] <mwhudson> is it just
[00:21] <mwhudson> git remote add natty git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
[00:21] <mwhudson> git fetch natty
[00:21] <mwhudson> ?
[00:21] <mwhudson> maybe git fetch natty master ?
[00:22] <TheMuso> mwhudson: git remote add natty as you wrote
[00:23] <TheMuso> then use git branch -r to see what natty remote branches there are.
[00:23] <TheMuso> To create a local mirror of a remote branch, you can do git checkout -b natty-master natty/master
[00:23] <TheMuso> Which will create a local branch called natty-master which tracks natty/master
[00:24] <mwhudson> git branch -r just says
[00:24] <mwhudson>   origin/HEAD -> origin/master
[00:24] <mwhudson>   origin/master
[00:25] <TheMuso> Did you add natty as a remote?
[00:25] <mwhudson> yes
[00:25] <TheMuso> ok then you want to run git fetch natty
[00:25] <mwhudson> ah ok
[00:25] <mwhudson> that was running while i ran git branch -r
[00:25] <mwhudson> now it's completed a bunch more stuff has appeared
[00:28] <mwhudson> ah now arararagh i don't know which patch tjaalton backported
[00:28] <mwhudson> oh phew, it's here: http://people.canonical.com/~lexical/bugs/lp791752/
[00:38] <mwhudson> git 1 : 0 mwhudson
[00:49] <mwhudson> ok building
[01:19] <mwhudson> ah hum, i changed the version of the packaging
[01:19] <mwhudson> which broke the build
[01:20] <mwhudson> ah i changed the version of the packaged, but not something else
[01:20] <lifeless> mwhudson: btw, #ubuntu-kernel usually gets this stuff :>
[01:20] <mwhudson> ah point
[03:05] <nemo> ok. why the !@#$ does pastebin.ubuntu.com require me to log in to download a paste as text?
[03:05] <nemo> regretting ever having sent user to that url for support :(
[03:05] <nemo> what silly silly silly idea
[03:06] <nemo> agh. requires whitelisting session cookies too
[03:06] <nemo> and doesn't work in w3m
[03:06] <nemo> geez
[03:13] <infinity> nemo: It was a simple solution to the very real problem of people distributing large binary files (like ISOs and movies) in raw pastebins.
[03:16] <ion> A size limit wasn’t? :-)
[03:19] <nemo> ion: amen brother
[03:20] <nemo> somehow everyone else manages
[03:53] <infinity> ion: Size limits don't help.  It's trivial to split an ISO into thousands of chunks and shove them into a bunch of bins.
[03:53] <infinity> ion: And yes, this happens.  A lot.
[03:53] <nemo> um
[03:54] <nemo> if someone is willing to go to all that trouble to distribute an ISO
[03:54] <nemo> they can also trivially extract base64 bits from your pastebin without the raw thing
[03:54] <infinity> nemo: This isn't theoretical.  If it was, no one would care.
[03:54] <nemo> so that makes the annoyingness pointless
[03:54] <infinity> nemo: The difference is that your assertion is theory, mine is fact. :P
[03:55] <infinity> nemo: (I don't disagree with your theory, but that's not the real-world data we've seen)
[03:55] <nemo> heh
[03:55] <nemo> I bet you're the dude who instituted this :)
[03:55] <infinity> Nope.
[03:55] <infinity> But I'm fairly familiar with it nonetheless.
[03:56] <nemo> ok. so you somehow ran into someone who was both clever and determined enough to split an iso into 10,000 pastebins, and do it in a way that would evade abuse detection, but too stupid to handle scraping
[03:56] <nemo> ahhh well
[03:56] <nemo> at least there's a reason for it
[03:57] <nemo> I'll just use pastebin.com
[03:57] <nemo> thanks for explaining though
[03:57] <nemo> seeya!
[04:19] <pitti> Good morning
[04:34] <pitti> SpamapS, RAOF: I'll be on vacation the next two weeks; can you handle SRUs during that time?
[04:36] <RAOF> pitti: Good morning!  I guess we can, yes.  I'll just punch down the queue more often.
[04:38] <pitti> RAOF: also, I think it's time for you to be able to twiddle the buttons yourself
[04:38] <pitti> RAOF: WDYT?
[04:38] <RAOF> pitti: Also, I had an SRU-calibration question: bug #744929.  From past behaviour I'd expect that to be accepted as an SRU, but I think it is too close to “core infrastructure” and too far from “serious regression” to fit the criteria.
[04:39] <pitti> that's https://launchpadlibrarian.net/72725131/dont-prompt-multiple-times-rebased.patch, right?
[04:40] <RAOF> YEah.
[04:41] <RAOF> It looks reasonably safe.  It's just touching what I'd regard to be core infrastructure to fix a bug that doesn't seriously undermine the usability of the desktop.
[04:41] <pitti> it certainly sounds like a regression, but it's indeed not a showstopper
[04:41] <pitti> admittedly 4 identical password prompts suck a bit, but it seems there aren't so many dupes
[04:42] <RAOF> I think this highlights a difference between accepted practice and what we've got written on wiki.ubuntu.com/StableReleaseUpdates.
[04:42] <pitti> RAOF: TBH I'm a bit on the edge there; I probably would have accepted it, but I guess my treshold is now pretty low after so many years
[04:42] <pitti> so I actually do appreciate a little more rigor in the process
[04:44] <infinity> I'd probably accept it, FWIW.  I'm okay with any "obviously correct" bugfixes that don't change expected interfaces.  Ish.
[04:44] <infinity> (But it's pretty case-by-case, which is why it's hard to codify such things in a policy)
[04:45] <RAOF> Right.  As I said, from past behaviour I'd expect that to be accepted.  But were we to go by what's written on StableReleaseUpdates, I don't think it would be accepted.
[04:45] <RAOF> Which means we should either update the documentation for what is acceptable in an SRU, or become stricter :)
[04:46] <infinity> Or accept that the docs reference the baseline level of "strictness", and as people get more comfortable with the spirit of the law, they can make a few borderline judgements?
[04:47] <infinity> Like I said, it's really hard to codify "acceptable updates" without erring on the side of caution.
[04:47] <infinity> Cause accidentally going the other way is ungood.
[04:47] <pitti> I agree
[04:47] <pitti> and while each single of these patches might be acceptable, I'm still a bit uncomfortable about the sheer number of updates that we do this way
[04:48] <pitti> some of them will eventually wreak havoc
[04:48] <pitti> and when looking at the kernel updates, this already happens all the time :)
[04:48] <infinity> Well, I'm also personally less inclined to fix every little bug in non-LTS releases too.
[04:48] <RAOF> Kernels are quite special :)
[04:48] <infinity> Whereas pushing well-tested and very correct patches to LTSes makes me happy.
[04:49] <infinity> (Given that I'm one of the people who does, in fact, run then for years)
[04:49] <pitti> RAOF: so if you want to reject this particular update because it doesn't fit the risk/benefit ratio, I think that's a very justifyable position
[04:49] <StevenK> infinity: +1
[04:50] <StevenK> infinity: I have an 8.04 machine around here some place
[04:50] <infinity> StevenK: My co-lo machine is still hardy too.
[04:51] <infinity> (Though, if mainlined Xen on 3.0 in oneiric proves stable, I might be tempted to upgrade pre-LTS..)
[05:18] <didrocks> good morning
[05:21] <RAOF> Oh, oh!  It's a didrocks!
[05:21] <RAOF> Morning didrocks :)
[05:21] <didrocks> hey RAOF ;)
[05:25] <RAOF> When's the NBN going to deliver a fibre connection to my home, damnit?  Uploading 150Mb worth of evolution core to launchpad takes too long! :)
[05:29] <lifeless> RAOF: retrace it locally.
[05:30] <RAOF> lifeless: That's effort.  Whereas I've got so much practice bitching about upload speed it's near effortless :P
[05:31] <lifeless> except for the whole uploading thing
[05:32] <RAOF> Eh.  That's computerised effort.
[05:35] <RAOF> …unless the upload 503s mere seconds before completing, of course.
[05:40] <lifeless> ewll
[05:40] <lifeless> to lp ?
[05:40] <lifeless> that means it completed but the insert boomed
[05:40] <lifeless> or the server instance was restarted
[05:40] <lifeless> did you get the OOPS id ?
[05:41] <RAOF> Apport doesn't give one; it hadn't opened the “please wait while we process your data” page yet.
[05:45] <lifeless> apport bug then
[06:03] <SpamapS> pitti: I'm still not clear on kernel SRU's ..
[06:04] <pitti> SpamapS: for accepting it's actually quite easy now
[06:04] <SpamapS> ugh.. TwinView is totally busted right now
[06:04] <pitti> SpamapS: https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED
[06:04] <pitti> SpamapS: that's the list of assigned SRU tasks, by the new kernel workflow
[06:04] <pitti> SpamapS: if there are promote-to-proposed tasks, you exercise the corresponding copy-proposed-kernel invocations from pending-sru.html and close the tasks
[06:05] <pitti> SpamapS: the main thing to watch out is to include all the -meta, -lbm etc. in the copying when there's an ABI bump
[06:05] <pitti> SpamapS: for releaseing a kernel to -security/-updates you need cocoplum access, as launchpad still times out when using launchpadlib
[06:05] <pitti> i. e. this part needs to be done by slangasek or cjwatson
[06:07] <SpamapS> Ok, any gotchyas other than the -meta and -lbm packages?
[06:07] <pitti> not really
[06:07] <pitti> we stopped running sru-accept.py on them, the bot/kernel team does that now
[06:07] <pitti> (with different verbiage etc.)
[06:07] <pitti> SpamapS: it's very mechanical on our end now
[06:09] <SpamapS> Ok, I'll give them a shot when I can.
[06:09] <pitti> SpamapS: we just went through a round for all releases, so I don't expect further updates until next week
[06:09] <SpamapS> pitti: I think we'll be able to keep the ship running.. we may even keep it from running aground. ;)
[06:09] <pitti> SpamapS: skaet also did copy-proposed-kernel already, so she can help/explain as well
[06:09] <pitti> lol
[06:09] <pitti> thanks :)
[06:12] <SpamapS> now to figure out why my twinview is refusing to show any windows
[06:17] <infinity> SpamapS: I'm happy to help with -security/-updates kernel magic too, if required.
[06:37] <superm1> pitti, re 799754, what about autologin?  ubiquity still would be writing out to /etc/lightdm/lightdm.conf, so if it's not a conffile that might be trouble
[06:41] <lifeless> infinity: how deep does the 'use lucid-updates during debootstrap' change go, do you think?
[06:44] <infinity> lifeless: Well, debootstrap isn't "deep" to start with, but mirror-handling and deb-fetching isn't particularly abstracted, so the change would touch several instances of shockingly-similar code.
[06:45] <infinity> lifeless: And, in the process, you'd also fix a longstanding bug that if there are two versions of a package available in the same Packages file, debootstrap just picks the first one it hits. :P
[06:45] <infinity> lifeless: (Which obviously would need to be fixed, to actually pick the highest version)
[06:46] <lifeless> just trying to assess whether I can explain to francis why I'm hacking on debootstrap :P
[06:47] <infinity> lifeless: It's something I always wanted to do if I found the tuits, and I could even potentially block time off later in this cycle to get David to agree to let me do it, but it's not something I could commit to right now.
[06:47] <dholbach> good morning
[06:47] <infinity> lifeless: So, if you can make it happen, please do.
[06:47] <lifeless> heh :P
[06:47] <lifeless> lxc is good for yak shaving apparently
[06:51] <pitti> superm1: ubiquity shouldn't modify lightdm.conf as long as it _is_ a conffile
[06:52] <pitti> superm1: but mythbuntu-default-settings and friends would install their's before ubiquity, so that should work?
[06:53] <infinity> lifeless: debootstrap actually already has preliminary support for multiple archives.  Where that falls short for us is that we use "pockets", which means some ugly s/$dist/\1-{updates,security,proposed}/ all over the place.
[07:00] <SpamapS> awesome.. so nvidia driver multi-monitor is completely broken on oneiric at the moment. :-/
[07:00] <SpamapS> and nouveau is refusing to recognize my NV96
[07:01] <superm1> pitti, yeah that would work as long as all packages installed it as a conffile
[07:01] <pitti> superm1: why a conffile?
[07:01] <superm1> my point was that ubiquity does modify that file in terms of changing automatic login
[07:01] <superm1> for gdm it did the same for custom.conf
[07:02] <pitti> I don't think it should be; multiple packages shipping the same conffile is icky to get right, as they'll cause conffile prompts
[07:02] <pitti> superm1: custom.conf was not a conffile
[07:02] <infinity> pitti: Multiple packages shipping the same conffile is just wrong, wrong, wrong.
[07:02] <pitti> and ubiquity modifying lightdm.conf conffile is nasty and shoudln't be done
[07:02] <pitti> infinity: my point
[07:02] <RAOF> SpamapS: nouveau doesn't recognise your nv96?  Got a pastebin of dmesg+/var/log/Xorg.0.log there?
[07:02] <superm1> pitti, so what should the right solution be here?
[07:02] <infinity> superm1: You might be confusing "conffile" (dpkg-managed files) and "config file" here?
[07:03] <pitti> superm1: *-default-settings should install a config file if it's not there already
[07:03] <superm1> yes i think so
[07:03] <superm1> how do you install something in /etc that isn't dpkg managed then?
[07:03] <infinity> superm1: A non-conffile config file that is created in maintainer scripts is the only way to have multiple packages play willy-nilly with the same file.
[07:03] <pitti> superm1: like, ship it in /usr/share/mythbuntu-default-settings/lightdm.conf and copy that to /etc/lightdm/ in postinst if not present already
[07:03] <superm1> oh right
[07:03] <superm1> okay that makes much more sense then
[07:03] <pitti> then ubiquity can apply as much seddery on it as it wants
[07:04] <pitti> and FWIW, yay for having so great names for config files vs. conffiles (which are also config files, of course)
[07:05] <infinity> Yeah, it's muddy. :P
[07:05] <pitti> so what I really ment was a non-conffile config file
[07:05] <infinity> But we still require everyone to know debian-policy, right? :)
[07:05] <pitti> (tell that to any non-DD and they will just stare at you in disbelief)
[07:06] <infinity> pitti: Well, you can scrap the "conffile" thing and say "non-dpkg-managed config file", which probably gets the point across better.
[07:06] <pitti> good idea
[07:06] <superm1> yeah if i read that i probably wouldn't have scratched my head as hard
[07:06] <SpamapS> RAOF: hrm, I don't think I do.. I've just reinstalled nvidia drivers.. really tired of fighting such a silly issue.
[07:07]  * SpamapS is installing XFCE to see if it fares better than Unity
[07:07] <pitti> superm1: anyway, with that sorted out, it would work in exactly the same way as with gdm's custom.conf
[07:07] <pitti> SpamapS: don't you guys all just plain X with a single xterm and byobu anyway? :-)
[07:07] <pitti> the "servity" desktop
[07:08] <SpamapS> pitti: kirkland is always trying to get me to use byobu. Not exactly my cup of tea. ;)
[07:08] <SpamapS> if I had it my way, I'd run the *stable* release of Ubuntu
[07:08] <SpamapS> but c'est la vie.. we must dog food
[07:09] <infinity> byobu is way too many bells and whistled (and constant pointless forking!) for a real CLI hack.
[07:09] <infinity> s/whistled/whistles/
[07:09] <SpamapS> infinity: I believe kirkland has been working on making the monitors resident... so they just work via pipes.
[07:09] <infinity> SpamapS: Still, who needs monitors?
[07:10] <infinity> Hold on, I had a great quote for just this occasion...
[07:10] <SpamapS> I'm with you.. but kirkland has put so much work into it.. I try to give it a fair shake whenever there's a major development.
[07:10] <infinity> < ron> procmeter3 does kind of look like the classic "I wanted to write a program, but don't actually have anything useful I want to do with computers" application
[07:10] <infinity> That one.
[07:10] <SpamapS> :-D
[07:12]  * micahg remembers evoking that comment a couple days ago
[07:12] <infinity> micahg: It was worth saving.
[07:13]  * SpamapS feels lost
[07:13] <nigelb> lovely quoet
[07:13] <nigelb> *quote
[07:13] <SpamapS> this giant 22" monitor on my desk just black.. :-/
[07:14]  * SpamapS ponders kde for a nanosecond
[07:19] <RAOF> I think KDE would be ok if I could get over the hump.  And learn to ignore options.
[07:23] <SpamapS> well xfce will be fine until they fix unity
[07:25] <Amoz> lol, willy- illy
[07:25] <Amoz> nilly*
[07:25] <poolie> :(
[07:32] <pitti> RAOF: have a look at https://launchpad.net/ubuntu/natty/+queue?queue_state=1
[07:33] <pitti> RAOF: of course I just processed all your ack'ed uploads some two hours ago, so there's nothing acceptable left right now
[07:33] <pitti> RAOF: unless you want to accept strongswan
[07:33] <pitti> RAOF: often I allow people to test the proposed package and fix oneiric in parallel, I just don't move these to -updates
[07:33] <pitti> it's not something I like to do, or happens often, but if you want to try :)
[07:34] <RAOF> Stronswan was the one I tentatively NAK'ed based on 3.0 (quilt) stylistic, right?
[07:34] <pitti> RAOF: no, that was w-scan or so, I already rejected it
[07:34] <pitti> RAOF: strongswan was delayed because a part needs fixing in oneiric
[07:34] <RAOF> queuediff says Strongswan was the one not fully fixed in oneiric.
[07:34] <pitti> wow, queuediff says that?
[07:35] <RAOF> No, but it does open the bug :)
[07:36] <RAOF> …which reminds me that I should have set the Ubuntu task back from fix released :)
[07:36] <pitti> infinity: did you ever see a build failure like https://launchpadlibrarian.net/75531471/buildlog_ubuntu-oneiric-i386.libreoffice_1%3A3.4.1-1ubuntu1~ppa2_FAILEDTOBUILD.txt.gz ?
[07:36] <RAOF> So, we *could* reject the gnome-keyring upload.
[07:37] <pitti> After installing, the following source dependencies are still unsatisfied:
[07:37] <pitti> libstlport4.6-dev(still installed)
[07:37] <pitti> Source-dependencies not satisfied; skipping libreoffice
[07:37] <pitti> RAOF: that's a lot less fun, though
[07:37] <pitti> Sweetshark: ^ FYI
[07:37] <infinity> pitti: Build-conflict.
[07:38] <pitti> Sweetshark: ^ oh, do you have a build-conflicts: there?
[07:38] <infinity> pitti: One of the build-deps is pulling in a build-conflict: Kaboom.
[07:38] <pitti> infinity: curious that it only happens on i386
[07:38] <pitti> infinity: thanks!
[07:40] <pitti> RAOF: another thing you can do now is running sru-release; there is a natty package which can go
[07:40] <RAOF> foolscap.
[07:41] <pitti> yeah, and pithos
[07:41] <RAOF> Hasn't pithos been there only 7 days?
[07:42] <cjwatson> lifeless: 802985 is surely moot now because the oneiric kernel is now 3.0.0 not 3.0, and AFAIK lucid's libc6.preinst will have no problem with that
[07:42] <cjwatson> lifeless: it's still a design issue, so the bug should stay open, but I see no reason why it should block you in any way
[07:43] <infinity> cjwatson: Oh, it was just choking on format, not on kvers != 2.6?  I didn't look.
[07:44] <Sweetshark> pitti: nah, thats not curious. stlport is only kept on i386 for binary compatibility with C++ extensions (a whole insanity of its own). amd64 dodged that bullet by means of the grace of late birth.
[07:44] <RAOF> pitti: Have I somehow managed to project a “SRUs stay in -proposed for at least 10 days” policy where there is none?
[07:44] <pitti> RAOF: it's 7 days :)
[07:45] <RAOF> I blame the lack of a decimal calendar.
[07:45] <cjwatson> infinity: yep
[07:46] <Amoz> 0.8 week
[07:46] <RAOF> pitti: So, that'd be ‘sru-release natty pithos foolscap’ to move those into -updates, right?
[07:46] <pitti> RAOF: actually, I don't see the 7 days on thehw iki page
[07:46] <pitti> RAOF: right
[07:46] <pitti> RAOF: please open the associated bugs before, and check that they are fixed in oneiric
[07:46] <cjwatson> infinity: lp:ubuntu/eglibc r157 was all that was needed to fix it; and having a 3.0.0 kernel on the host should do just as well
[07:46] <pitti> RAOF: and that there are no late comments about "OMGbroken"
[07:47] <cjwatson> RAOF: I think at one point it was 10 days; there was a time when I had that in my head too
[07:47] <pitti> I had always believed that the maturing period was on the wiki
[07:47] <Sweetshark> pitti: apropos OMGbroken. 3.3.3 in SRU seems to be just that (lost its themeing).
[07:48] <pitti> Sweetshark: yeah, I saw :(
[07:48] <RAOF> Heh.  Pithos hasn't been fixed in oneiric yet.
[07:48] <cjwatson> pitti: I think it is now
[07:48] <lifeless> cjwatson: well I had a bug on lxc-create duped on it overnight
[07:48] <pitti> ah, "After one week of maturing in -proposed"
[07:48] <pitti> I searched for "7", "10", and "days"
[07:48] <Sweetshark> pitti: Im building it again to see, what the heck went wrong there.
[07:48] <pitti> RAOF: ^
[07:48] <cjwatson> lifeless: I bet they're still running a slightly old oneiric kernel.  just tell them to upgrade
[07:49] <cjwatson> I've looked at the debootstrap change required; I know the code as well as most and it's still fairly scary
[07:49] <lifeless> cjwatson: I'm upgrading now
[07:49] <pitti> although this is only in the "special cases"
[07:49] <cjwatson> so I'm a lot more comfortable with leaving it alone for the moment :)
[07:49] <RAOF> pitti: Yeah, but that's only in the special-cases :)
[07:49] <RAOF> Anyway, pithos isn't a candidate because it's not yet fixed in oneiric.
[07:49] <cjwatson> the business of merging Packages files and taking the highest version will be the fiddly bit
[07:50] <pitti> RAOF: ah, it's at https://wiki.ubuntu.com/ArchiveAdministration#Stable_release_updates
[07:50] <infinity> cjwatson: Yeah, and that's the bug I want to fix ANYWAY.
[07:50] <cjwatson> and probably needs to go in the pkgdetails code (which has two implementations, one in debootstrap and one in base-installer, and they need to be kept in sync interface-wise)
[07:50] <infinity> cjwatson: (Nevermind the multiple Packages merging, which is a feature request, but the long-standing bug of not picking the highest version)
[07:51] <cjwatson> yep
[07:51] <pitti> RAOF: which is out of date wrt. "sru-pending", updating now
[07:51] <infinity> cjwatson: Hugely annoying when bootstrapping sid with more than one version of some packages publishes.
[07:51] <cjwatson> I agree it's a problem, but not blocking everyone on it would be pretty good
[07:51] <infinity> published*
[07:53] <pitti> RAOF: probably best to remove that entire paragraph, and fix the SRU page instead
[07:53] <RAOF> pitti: Aha.  Anyway, I'll send foolscap off to -updates, as that *has* been fixed in oneiric and no one's claimed that it set their dog on fire.
[07:54]  * cjwatson irritated to discover he made an archive mistake that he'd have told anyone else off for making
[07:54] <cjwatson> grr
[07:54] <RAOF> pitti: And maybe leave a link.
[07:54] <pitti> RAOF: yeah, doing
[07:54] <infinity> cjwatson: Which one?
[07:54] <infinity> cjwatson: The by-hand stuff?
[07:55] <cjwatson> d-i not copied to -updates properly, yeah
[07:55] <cjwatson> did somebody do that for me?  timestamped yesterday
[07:55] <infinity> S'ok, dist-upgrader hadn't been copied since before the LAST point release too.
[07:55] <infinity> Clearly, people need to be re-educated on by-hand.
[07:55] <cjwatson> *cough*
[07:55] <cjwatson> was that you?
[07:55] <infinity> And yeah, I fixed it for you.
[07:56] <cjwatson> cool.  thanks and sorry.
[07:56] <infinity> S'all good.
[07:56] <infinity> Might want to check dist-upgrader in other releases, I only did lucid.
[07:56] <infinity> Who knows what bugs we've fixed and never released!
[07:58] <saamm> hello I like new gwibber but is there any chance that 5 minute update time limit will be reduced? thanks
[07:58] <pitti> RAOF: docs updated
[07:58] <pitti> RAOF: sru-release worked?
[07:59] <RAOF> Yup.
[07:59] <RAOF> Whoop whoop!
[07:59] <pitti> nice
[07:59] <pitti> oh, my server came back, brg
[08:00] <cjwatson> published hardy-updates debian-installer properly
[08:01] <RAOF> pitti: Will you have time to give colord a once-over & upload to Debian, or shall I troll for other sponsors?
[08:01] <pitti> RAOF: no guarantees, I'm afraid; need to get some stuff done before my holidays and a3
[08:02] <infinity> cjwatson: Hahaha.  Seriously?
[08:02] <cjwatson> infinity: you're right, there's a bunch of other stuff that needs proper publication in -updates.  I'll look at it after the next publisher run
[08:02] <infinity> cjwatson: Yeah, it might be time for a mail to the list. ;)
[08:02] <cjwatson> infinity: yeah :-/
[08:02] <cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 19 Apr  6  2010 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-proposed/main/installer-i386/current -> 20070308ubuntu40.14
[08:02] <RAOF> pitti: That's fine.  Trolling for sponsors it is!
[08:02] <cjwatson> lrwxrwxrwx 1 lp_publish lp_publish 19 Jul 20 08:00 /srv/launchpad.net/ubuntu-archive/ubuntu/dists/hardy-updates/main/installer-i386/current -> 20070308ubuntu40.14
[08:02] <cjwatson> infinity: um, well - I suspect the fault is largely mine
[08:02] <infinity> cjwatson: You can totally do it while the publisher is running.  Do your work in dists.new and race the clock.
[08:02] <cjwatson> I've certainly at least been *around* when these were copied
[08:03] <cjwatson> infinity: oh, sure, I documented how to do that in ArchiveAdministration even :-)
[08:03] <cjwatson> infinity: but I prefer not to if there's no wild rush
[08:03] <pitti> cjwatson: want me to add a warning to sru-release when you run it on debian-instsaller? it should at least point to the part of ArchiveAdministration which explains how to do it
[08:03] <cjwatson> pitti: yes please
[08:03] <infinity> pitti: And ditto for update-manager.
[08:03] <pitti> infinity: uh, wasn't even aware of that one
[08:04] <infinity> pitti: No one seems to be, from the state of the archive. :P
[08:07] <pitti> committed
[08:10] <Sweetshark> pitti, infinity: thanks for the stlport tip. For once, it wasnt me who broke it this time.
[08:10] <infinity> Sweetshark: Always nice to be able to pass the buck. :)
[08:10] <Amoz> dholbach, hi *waves*
[08:10] <dholbach> heya Amoz
[08:11] <Amoz> dholbach, I was thinking about brainstorm.ubuntu.com...
[08:11] <Amoz> it's the old style 8-D
[08:13] <dholbach> Amoz, might be worth talking to these people about it: https://launchpad.net/~brainstorm-admins/+members#active
[08:13] <Sweetshark> infinity: in the rare occurances where I didnt bork it myself ;)
[08:13] <infinity> cjwatson: Do we know if dist-upgrader actually correctly looks at ${dist}-updates?  If so, I think we've been, quite embarassingly, missing a lot of fixes to update-manager. :/
[08:13] <infinity> cjwatson: (note that lucid-updates had *no* dist-upgrader directories until I copied the ones from -proposed yesterday)
[08:14] <Amoz> dholbach, is there a more "prioritized" website somewhere with the old style?
[08:14] <dholbach> Amoz, might be worth asking in #ubuntu-website
[08:16] <mvo> infinity: its using the url from http://changelogs.ubuntu.com/meta-release
[08:17] <mvo> infinity: often I did manually update it to point to the right version in -proposed (right as in the version that is also in updates). but having this correct by copying would be really good
[08:18] <infinity> mvo: Ahh, I see.  So, you've been working around our failure.  Excellent. :)
[08:18] <Amoz> dholbach, ah, of course..
[08:18] <infinity> mvo: But yes, we really should be moving them properly for you and having you reference -updates.
[08:18] <mvo> infinity: great!
[08:18] <dholbach> Amoz, I'll try to sort out the license/copyright stuff for the packaging guide thing today
[08:20] <Amoz> dholbach, niiiice
[08:35] <pitti> hm, what did I misunderstand about bash's regexps? why is [[ "aaaa" =~ "a*" ]] false?
[08:35] <poolie> i don't suppose you need to escape the *?
[08:35] <pitti> no, and I alraedy tried that
[08:36] <pitti> [[ "aaaa" =~ "aaaa" ]] works, but anythign more complex than that just fails on me :/
[08:36] <pitti> ah, [[ "aaaa" =~ a* ]]
[08:36] <poolie> no quotes
[08:36] <poolie> yeah
[08:36] <pitti> so seems quotes are special in [[ ]]
[08:36] <poolie> perhaps only special on the right side of =~
[08:37] <infinity> Quotes are special all over shell.
[08:37] <infinity> Anything in quotes is immediately a string.
[08:37] <poolie> > Any part of the pattern may be quoted to force it to be  matched  as  a  string
[08:37] <infinity> You'll see the same problem when testing for numeric equality.
[08:37] <pitti> ok, thanks
[08:38] <pitti> now I just need to figure out where X="pitti/ppa"; [[ "$x" =~ [[:alnum:]-]+/[[:alnum:]-]+ ]] goes wrong
[08:38] <poolie> well, i would have assumed like pitti the second argument to =~ was a string
[08:38] <poolie> aside from the first X being uppercase?
[08:39] <pitti> *headdesk*
[08:39] <infinity> *cough*
[08:39] <pitti> poolie: shame on me :)
[08:39] <poolie> :) any time
[08:39] <poolie> some problems are deceptively easy
[09:03] <bdrung> wgrant: did you filed a bug for the failed import at https://code.launchpad.net/~wgrant/lintian/master
[09:04] <bdrung> wgrant: i like to setup a daily build for lintian, but this code import fails
[09:09] <cjwatson> poolie: this is why I avoid bash [[ ]] - its behaviour is totally nonintuitive
[09:09] <cjwatson> better to use expr IMO
[09:09] <cjwatson> or case
[09:09] <cjwatson> case $string in pattern) ... ;; esac
[09:09] <poolie> it does seems like a layer violation that it changes the quoting rules
[09:09] <poolie> but, sh is full of them
[09:09] <poolie> i would tend to use case too
[09:09] <poolie> though, can you use regexps?
[09:10] <cjwatson> sure, but this is yet a new set of quoting rules :-)
[09:10] <cjwatson> no, but globs are often enough
[09:10] <bdrung> tumbleweed: do you have done something to fix bug #801945?
[09:10] <poolie> actually, i would tend to use zsh globs in personal use scripts
[09:10] <lifeless> cjwatson: ok, the oneiric cd for some reason hadn't installed linux-generic
[09:10] <cjwatson> you can use regexps in expr
[09:10] <lifeless> cjwatson: so kernel upgrades were not happening automatically
[09:10] <cjwatson> life	that's odd
[09:11] <cjwatson> poolie: the other reason I avoid [[ ]] is that much of my shell code has to run in plain POSIX sh
[09:11] <poolie> right
[09:11] <cjwatson> and it's easier for me to be in the habit of just writing in POSIX sh all the time
[09:11] <pitti> cjwatson: so should I get rid of that [[ ]] stuff in ubuntu-defaults-image then, and rewrite it using expr?
[09:11] <cjwatson> pitti: if it were me then I would use expr, yes
[09:12] <poolie> i wonder if posix expr understands regexp matches?
[09:12] <cjwatson> it's only one extra fork, I doubt it makes any realistic performance difference
[09:12] <pitti> I can replace the ( ) backref matching with some string operations, will just look a little more complicated
[09:12] <poolie> perhaps it's a quirk of linux we might try to use a minimal sh but not a minimal expr
[09:12] <lifeless> cjwatson: indeed
[09:12] <cjwatson> poolie: yes, it does.  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/expr.html
[09:13] <cjwatson> it's a basic RE anchored to the start of the string
[09:13] <poolie> but only the operator ':' not 'match'
[09:13] <wgrant> bdrung: There is a bug about that sort of thing already.
[09:13] <cjwatson> correct
[09:13] <bdrung> wgrant: can you give me a number?
[09:13] <cjwatson> I just have http://pubs.opengroup.org/onlinepubs/9699919799/nfindex.html bookmarked for this kind of thing
[09:14] <wgrant> bdrung: Bug #212195
[09:15] <dupondje> Somebody knows an easy way to get package version of a debian package in python?
[09:16] <cjwatson> given what, a .deb?
[09:17] <bdrung> wgrant: thanks.
[09:17] <dupondje> cjwatson: given the package name. It should check the debian repo's
[09:18] <bdrung> dholbach: is there a lp project that gathers code import bugs / daily build blockers?
[09:18] <dholbach> there's a tag - hang on
[09:18] <bdrung> dupondje: maybe python-debian?
[09:19] <cjwatson> you could either use python-apt and download the appropriate tagfiles and such yourself, or else just call out to rmadison -u debian with subprocess
[09:20] <lifeless> cjwatson: indeed, it is. I can get the date of the iso if that would help
[09:20] <dupondje> ubuntutools.requestsync.lp.getDebianSrcPkg exists also it seems :)
[09:20] <cjwatson> lifeless: the installer syslog would help more
[09:20] <cjwatson> (and contains the date of the iso)
[09:20] <dholbach> bdrung, https://bugs.launchpad.net/launchpad/+bugs?field.tag=recipe maybe?
[09:21] <dholbach> bdrung, there's "code-import" too
[09:21] <bdrung> dholbach: code-import seems more appropriate
[09:22] <bdrung> thanks
[09:22] <dholbach> de nada
[09:35] <johnt> hi folks, can anyone help me with a debian installer question?
[09:38] <cjwatson> johnt: possibly, what is it?
[09:39] <johnt> cjwatson: im trying to figure out whats the best way to disable the screensaver on a preseeded install cd, if that makes sense. i'm sure there is an easy way to do it but i cant figure it out :(
[09:40] <johnt> cjwatson: i tried using gconftool-2 but it doesn't seem to be present or working in the install environment. any ideas?
[09:41] <cjwatson> johnt: you're probably trying to run gconftool-2 in the installer environment rather than in the target system.  are you using preseed/late_command?
[09:41] <johnt> yeah - hold on one sec and ill tell you exactly what i have...
[09:41] <cjwatson> and if so can I see the preseed/late_command you're setting?
[09:41] <cjwatson> cool
[09:44] <johnt> d-i preseed/late_command string in-target /usr/bin/gconftool-2 --type bool --set /apps/gnome-screensaver/idle_activation_enabled "FALSE"
[09:46] <cjwatson> hm, that should work fine, although as good practice you should avoid hardcoding the path to gconftool-2 and just call it by its name
[09:46] <johnt> cjwatson: does that look like it should work?
[09:46] <cjwatson> do you have an installer syslog?
[09:47] <cjwatson> well, you might need to think about which gconf database you're trying to edit, since you don't have a user context here
[09:47] <johnt> probably - is the syslog stored somewhere on a system which has been installed using this preseed file?
[09:47] <cjwatson> /var/log/installer/syslog
[09:48] <johnt> ah cool - let me take a look...
[09:48] <johnt> how do you tell it which gconf database to use?
[09:48] <cjwatson> you might need something like '--config-source xml:readwrite:/etc/gconf/gconf.xml.defaults'
[09:53] <johnt> cjwatson: strange - there doesnt seem to be an error in the syslog where the command should execute.
[09:57] <johnt> cjwatson: should i use '--direct' ?
[09:58] <cjwatson> johnt: oh, yeah, probably
[09:59] <cjwatson> gconfd definitely won't be running
[09:59] <johnt> presumably there is no server running in the install environment?
[09:59] <cjwatson> indeed not
[09:59] <seb128> cjwatson, johnt: what ubuntu version?
[09:59] <johnt> 10.04
[09:59] <seb128> cjwatson, johnt: that command will not work in oneiric, gnome-screensaver stopped using gconf in GNOME3
[10:00] <seb128> ok
[10:00] <cjwatson> (it may be different if you're writing a preseed file for the desktop installer, but you aren't)
[10:00] <seb128> so that should work ;-)
[10:00] <johnt> cool!
[10:00] <johnt> cjwatson: ill give that a shot, thanks so much for your help - this problem has been bugging me for days!
[10:01] <cjwatson> surprised there's nothing in the installer syslog; that would imply that gconftool-2 is just failing silently without printing anything to stdout or stderr, which would be weird
[10:02] <johnt> i know - it doesnt make sense really
[10:02] <cjwatson> sure you're looking in the right place?
[10:02] <cjwatson> I'm generally happy to skim syslogs for people
[10:03] <johnt> yeah - i can see the next command running successfully
[10:03] <johnt> ill try it again and if i doesnt work ill paste the syslog :D
[10:04] <bigon> RAOF: hi, about strongswan SRU did you have actually accepted the pkg? I see nothing in the lp
[10:36] <pitti> RAOF: ah, strongswan accepted, too?
[11:26] <johnt> cjwatson: still there?
[11:26] <cjwatson> y
[11:27] <johnt> that doesnt seem to have worked - have you got a sec free to help me figure out why?
[11:33] <cjwatson> kind of, would be easier if you just described the problem
[11:33] <cjwatson> waiting for people to be free at the same time doesn't really work on irc :-)
[11:37] <johnt> ah
[11:37] <johnt> well
[11:37] <johnt> there still doesnt seem to be anything in the syslog
[11:37] <johnt> the screensaver is still enabled in gconf-editor when i log in
[11:38] <johnt> and /etc/gconf/gconf.xml.defaults/ seems to be empty for some reason
[11:39] <johnt> sorry, the config file %gconf-tree.xml is empty
[11:39] <johnt> http://dl.dropbox.com/u/124791/preseed_syslog.txt
[11:44] <cjwatson> this doesn't explain your entire problem, but you can't set preseed/late_command multiple times like that
[11:44] <cjwatson> rather than thinking of a preseed file like a program, think of it as setting a bunch of keys in a database which are then fetched later
[11:45] <cjwatson> only the last one will be used
[11:45] <davmor2> how do I go about requesting a driver for a wifi card is it just a bugreport with hardware details?
[11:45] <cjwatson> (so that might actually explain your problem if you have some other preseed/late_command entry after that in your preseed file)
[11:45] <cjwatson> for multiple commands, use:
[11:45] <cjwatson>   d-i preseed/late_command string in-target gconftool-2 blah; in-target gconftool-2 blah; ...
[11:47] <johnt> so you can only have one late_command?
[11:47] <cjwatson> actually I think that does explain your problem, since you appear to have 'd-i preseed/late_command string in-target /opt/VScan/kav_install.sh' after the entries you quoted
[11:47] <cjwatson> yes, but it can be a compound command
[11:47] <cjwatson> as in multiple commands separated by ; or &&
[11:47] <cjwatson> the whole thing is just passed to the shell
[11:47] <johnt> ah ok cool
[11:47] <johnt> so - why did the .sh run but the ones before it didnt?
[11:48] <cjwatson> because you set the same variable multiple times; the last setting won
[11:48] <johnt> ah
[11:48] <johnt> ok - very cool
[11:48] <cjwatson> it's not a program, it's a list of entries to insert into a database
[11:49] <johnt> sure - i was kind of treating it like a script which was run line by line
[11:49] <cjwatson> right, that's not an uncommon mistake to make
[11:50] <johnt> other than that, does the syntax of the gconftool-2 command look right?
[11:59] <cjwatson> johnt: I think so, but I am not a gconf expert, only an installer expert.  (again, though, you shouldn't hardcode the path to gconftool-2 - just write it as "gconftool-2", not "/usr/bin/gconftool-2")
[12:01] <johnt> cjwatson: ok, cool ill change that. thanks again for your help - much appreciated!!!
[12:02] <cjwatson> no problem
[12:15] <hallyn> this bug about groupadd failing to lock gshadow (as in bug 813180)  deja vu.  is there a known other bug causing it?
[12:30] <hallyn> i think we need a fix for groupadd to have *it* retry rather than failing dpkg -i
[12:54] <johnt> cjwatson: are you still there?
[13:07] <cjwatson> johnt: again, I recommend just saying what your problem is rather than checking if I'm here first
[13:09] <johnt> ok, will do. having the FALSE in "" shouldnt make any difference right? also, is it ok to split up the string into multiple lines with \ ? finally - does each seperate command need its own "in-target"?
[13:10] <cjwatson> FALSE in quotes or without makes no difference either way
[13:12] <cjwatson> splitting up into multiple lines: answered in https://help.ubuntu.com/10.04/installation-guide/i386/preseed-creating.html
[13:12] <cjwatson> either put in-target in front of each command, or use  in-target sh -c 'command; command; command'
[13:12] <cjwatson> the latter will be a bit faster but you may or may not regard it as harder to read
[13:18] <kirkland> infinity: there are two new utilities for byobu, byobu-quiet and byobu-silent, which disable all of the monitors
[13:18] <kirkland> infinity: while still maintaining the keybindings, etc.
[13:19] <kirkland> infinity: not that I expect to change your opinion, but when people make reasonable (and sometimes even unreasonable) critiques, I listen, and try to implement the suggestion
[13:23] <kirkland> infinity: SpamapS: with respect to the forks, I've reduced them tremendously (by perhaps 90%)
[13:53] <jjardon> Hi, Ubuntu One configuration will use the online accounts panel?
[13:56] <seb128> jjardon, try asking to dobey, he's on #ubuntu-desktop for example, but I doubt it, at least for this cycle, they have something that works for a while not sure they plan to rewrite it
[13:57] <seb128> jjardon, especially that they want their dialog to be cross platform I think and not linux specific
[13:59] <jjardon> seb128: who is "they" ?
[13:59] <seb128> jjardon, the ubuntuone team, they have a win client as well at least
[14:00] <seb128> jjardon, so not sure how much they want os specific integration rather than a standalone dialog they can build on different platforms
[14:00] <seb128> jjardon, dobey should know better
[14:01] <jjardon> seb128: ok, I'll ask. thanks!
[14:01] <seb128> yw
[14:18] <tkamppeter> mpt, hi
[14:18] <mpt> Hello tkamppeter
[14:30] <tkamppeter> mpt, I have put together all about s-c-p and but it into a bug on GNOME. Have I correctly CCed you?
[14:31] <tkamppeter> https://bugzilla.gnome.org/show_bug.cgi?id=654742
[14:39] <smb> doko_, Is there some flag to prevent gcc-4.6 from using a .text.startup section for main?
[14:42] <johnt> cjwatson: i got that working, thanks again for all your help!
[14:42] <cjwatson> excellent
[14:43] <davmor2> that would be a security issue then I can login without a password even though I select use a password to login from the oneiric installer :(
[14:44] <kees> davmor2: that seems not good :)
[14:45] <davmor2> kees: although the unity desktop doesn't start, and in ctrl-alt-f1 I need to login so may just be an issue with  light dm
[14:46] <smb> Sounds like a state I had after install a while ago
[14:46] <doko_> smb: don't know, would have to search myself
[14:46] <smb> But it seemed to have changed after last updates
[14:48] <smb> doko_, Hm, ok. Cause that seems to be the issue. When compiling with gcc-4.5 or with gcc-4.6+O1, it seems to bootstrap code remains the first thing, and that and the other code is in .text
[14:48] <smb> doko_, But otherwise the everything else goes into .text but main gets into a .text.startup and then is reordered when linking
[14:50] <doko_> smb: is this both oneiric?
[14:51] <smb> doko_, Yes, compiled the same code in a oneiric chroot.
[14:54] <Laney> cody-somerville: did you mail the TB about adding Rhonda's PPU access?
[14:56] <davmor2> Oh interesting, lightdm shows my name Dave Morley for login, if I click on it, it seems to magically login,  however if I click on other and use my nick it then asks for the password and I get unity up and running
[14:58] <smb> davmor2, Strangely I had just the same ting (except the unity running part) right after install last Friday. Since then I had been done upgrades and that went away. Even unity seems sort of willing in accelerated mode.
[15:02] <cody-somerville> Laney, Not yet. I wasn't aware I had to.
[15:05] <Laney> cody-somerville: Well, not necessarily mail, but you have to ask a TB member to do it
[15:08] <micahg> could I get someone to give back gupnp-igd (main) on all archs?
[15:09] <cjwatson> micahg: done
[15:11] <micahg> cjwatson: thanks!
[15:37] <climbe2> Problem!  If anyone is able to help.... running 10.04, recently upgraded to kernel 2.6.32-33, and can't boot up!!  See http://ubuntuforums.org/showthread.php?t=1807978 for my ongoing thread.  Any suggestions?!?!
[15:38] <climbe2> #Ubuntu is very busy...too many people with too many problems.... #ubuntu-kernel has not replied
[15:38] <climbe2> would love to hear from someone!
[15:40] <Pici> climbe2: That doesn't make this a support channel. Either ask again in #ubuntu or try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
[15:40] <climbe2> oh, ok. Understood.  Thank you!
[15:58] <Riddell> barry: don't forget the packaging guide reviews :)
[15:58] <barry> Riddell: gotcha, thanks for the reminder ;)
[15:58] <barry> Riddell: heading to lunch now, but will take a look after
[16:08] <debfx> kenvandine: install pidgin currently pulls in half of gnome through indicator-status-provider-pidgin -> indicator-messages
[16:08] <debfx> kenvandine: do you think we could drop the indicator-messages dependency?
[16:10] <kenvandine> debfx, is it a depends?
[16:10] <kenvandine> pidgin-libnotify recommends the provider
[16:11] <micahg> kenvandine: we install recommends by default
[16:11] <kenvandine> micahg, yeah... but we want a recommends there
[16:12] <debfx> kenvandine: installing indicator-status-provider-pidgin is fine but does it really have to depend on indicator-messages?
[16:12] <kenvandine> yes
[16:12] <kenvandine> it can't work without it
[16:13] <kenvandine> but indicator-messages shouldn't have any gnome depends
[16:13] <kenvandine> it depends on libindicate and a indicator-renderer
[16:13] <infinity> kirkland: It'll never be a product targetted at me (and that's fine, yay for free software not having to be one-size-fits-all), but I'm happy regardless to hear about the reduction in forks, and the slimmer options. :)
[16:14] <debfx> kenvandine: indicator-messages -> indicator-applet -> gnome-panel
[16:15] <kenvandine> indicator-applet | indicator-renderer (i think)
[16:15] <kirkland> infinity: agreed;  definitely not targeted at everyone (or a sysadmin of your persuasion)
[16:16] <infinity> kenvandine: That's a recommend.
[16:16] <kenvandine> yes
[16:17] <infinity> kenvandine: "apt-get --no-install-recommends install pidgin"?
[16:17]  * micahg sees KDE doesn't have an indicator-renderer
[16:17] <debfx> kenvandine: yes, but package mangers choose the first one if none is installed
[16:17] <kenvandine> kde does have one
[16:17] <kenvandine> i am pretty sure :)
[16:17] <kenvandine> i know indicators work in kde
[16:17] <kenvandine> something provides indicator-renderer
[16:17] <micahg> kenvandine: it's not providing the indicator-renderer virtual package then
[16:18] <infinity> Yeah, I don't see anything KDEish providing it.
[16:18] <infinity> So, that might be the real bug here. :P
[16:18] <kenvandine> somehow the indicators do get displayed in kde... at least they did
[16:18] <micahg> right, that's why xubuntu doesn't have the same issue
[16:18] <debfx> so plasma-widget-message-indicator should provide indicator-renderer?
[16:18] <kenvandine> probably
[16:19] <infinity> Almost certainly.
[16:19] <kenvandine> something should, and that sounds right
[16:20] <kenvandine> i am sure agateau in #ayatana knows for sure
[16:20] <kenvandine> which package that is
[16:20] <debfx> ah indicator-renderer is just about rendering StatusNotifierItems?
[16:20] <kenvandine> debfx, yes
[16:20] <kenvandine> indicator-messages is just the service that provides them
[16:22] <debfx> ok, then plasma-widgets-workspace should provide indicator-renderer
[16:33] <bdmurray> pitti: with regards to https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/conffile-handling/+merge/68477.  Source package hooks aren't translated so this translating the string in hook utils seems inconsistent to me.
[16:47] <dupondje> https://launchpad.net/ubuntu/+source/mlton/20100608-4 => Could some admin fix this? armel build waits on itself. Eventually sync the newest version from debian.
[18:15] <lfaraone> !regression-alert bug 788351 causes 4/8 bytes of kernel memory to be overwritten in certain circumstances
[18:15] <lfaraone> !regression-alert
[18:19] <skaet> lfaraone,  ack.
[18:30] <skaet> lfaraone, per pgraner,  the kernel to fix it is in -proposed.
[18:41] <seb128> bdrung, hey
[18:41] <bdrung> seb128: hi
[18:41] <seb128> bdrung, you will be happy, desrt is fixing the glib units handling ;-)
[18:42] <bdrung> \o/
[18:42] <seb128> he deprecating the current function, changing the default and adding a function that let you specify if you want base-2 or base-10 units
[18:42] <seb128> he->he's
[18:43] <bdrung> great
[18:45] <bdmurray> barry: how does computer-janitor sort the list of packages for removal?
[18:49] <barry> bdmurray: sorts by name by default.  there's a menu item to sort by size, but that's broken because of bug 806574
[18:50] <bdmurray> barry: really mine didn't seem sorted at all - too late for a screenshot though
[18:51] <barry> bdmurray: maybe file a bug, or follow up on the above?  i need to find time to get to it but i am planning on giving cj some love this cycle
[18:54] <bdrung> seb128: thanks
[18:55] <seb128> bdrung, thanks desrt, he's the one who worked on it ;-)
[18:55] <bdrung> seb128: on which channel is he?
[18:56] <seb128> bdrung, #ubuntu-desktop for example
[18:56] <seb128> though he seems to be away from his computer now but he will read the backlog when he's back I guess
[19:37] <Daviey> Anyone else noticed some oddities with python2.7 in the last few days?
[19:37] <Daviey> Can't quite put my finger on it, but some things seem to not be functioing correctly
[19:38] <jelmer> Daviey: there's a regression in the current snapshot in oneiric that breaks bzr
[19:38] <jelmer> other than that, python2.7 seems to be fine here
[19:42] <Daviey> odd, http://pb.daviey.com/gjyF/raw/
[19:44] <broder> ScottK: ping? i wanted to get your opinion on bug #784617. my inclination is to just refuse outright, given the core-ness of the package and the scope of the r-dep testing, but i'd like a second opinion
[19:44] <ScottK> broder: ssh backports are no sale.  I agree.
[19:44] <broder> ok, i'll close it
[19:56] <dupondje> Could somebody check https://launchpadlibrarian.net/75520549/buildlog_ubuntu-oneiric-i386.openmpi_1.4.3-2.1_FAILEDTOBUILD.txt.gz ?
[19:57] <dupondje> Would like to get a direction on how to solve/debug.
[19:58] <broder> dupondje: is there a .docs file?
[19:59] <broder> the issue is that the AUTHORS file in the upstream source is a symlink
[19:59] <broder> probably a relative symlink
[19:59] <dupondje> broder: there is no .docs file
[20:00] <smoser> barry, or doko_ around ? or, anyone have any ideas on bug 810019
[20:00] <broder> dupondje: yeah, the files are getting listed in the dh_installdocs invocation in debian/rules
[20:00] <smoser> I don't see it on my desktop oneiric system, but see it on the ec2 images
[20:01] <dupondje> Well it does 'dh_installdocs --all AUTHORS NEWS README'
[20:01] <dupondje> so those file are installed
[20:01] <broder> right
[20:01] <broder> look at the AUTHORS file, though
[20:01] <broder> it's probably a symlink
[20:01] <dupondje> nope
[20:01] <dupondje> its a text file in the source root
[20:02] <barry> smoser: i don't see that on my oneiric box, but i don't think i have paste installed
[20:02] <broder> hmm...maybe it's a pkgbinarymangler issue, then?
[20:02] <barry> smoser: and that's an odd warning ;)
[20:03] <smoser> barry, it shows up all the time.
[20:03] <smoser> (bug has a simple 'python -c' reproduce)
[20:03] <smoser> i can give you access to a system if you want
[20:03] <dupondje> broder: no idea ... Any idea how I can debug this?
[20:03] <barry> smoser: reproduced after installing python-paste
[20:04] <barry> smoser: so my guess is paste is doing something weird/evil/illogical/insane/mean/nasty/dumb/bogus/wacked
[20:04] <broder> dupondje: wait a second...i think the problem is that dh_installdocs is getting called twice for some reason
[20:05] <dupondje> Its in binary-arch and binary-indep indeed
[20:05] <broder> dupondje: with --all in both? that's a problem
[20:06] <smoser> hm.. i wonder what recommends got python-paste pulled into the images
[20:06] <dupondje> broder: both         dh_installdocs --all AUTHORS NEWS README
[20:06] <dupondje> guess it only needs to be in the indep ? as that one builds the doc ?
[20:06] <dupondje> or
[20:07] <broder> dupondje: no, you should pass -a and -i in -arch and -indep respectivelyt
[20:08] <broder> you shouldn't be acting on arch-indep packages in binary-arch, or arch-dep packages in binary-indep
[20:09] <dupondje> so: dh_installdocs -a --all AUTHORS NEWS README right ?
[20:09] <dupondje> and -i in indep
[20:09] <broder> dupondje: no --all
[20:09] <broder> in either
[20:09] <smoser> thank you barry
[20:09] <barry> smoser: good question.  i've updated the bug.  np!
[20:12] <Daviey> barry: Seen this: http://pb.daviey.com/gjyF/raw/ ?
[20:13] <barry> Daviey: nope, that's a new one for me ;)
[20:13] <Daviey> :(
[20:13] <Daviey> poor me
[20:13] <barry> Daviey: you might check on #launchpad-dev
[20:13] <Daviey> barry: i've seen some other oddities.. with 2.7 the last day.
[20:14] <barry> Daviey: dang, that's not good
[20:14] <Daviey> barry: if nobody else has seen it, it could just be a local issue.
[20:16] <barry> Daviey: could be.  wfm ;)
[20:16] <dupondje> broder: https://launchpadlibrarian.net/75642759/openmpi.debdiff guess this should do :)
[20:18] <broder> dupondje: LGTM. give me a few minutes and i'll sponsor it
[20:18] <dupondje> thanks for the assistance
[20:18] <dupondje> guess i'll better post it upstream also :)
[20:18] <broder> np
[20:23] <broder> dupondje: since you're looking at the package already, do you have any idea what's up with bug #697229?
[20:24] <dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621978
[20:25] <dupondje> got nmu'ed it seems
[20:25] <broder> ah, so we can close it?
[20:25] <dupondje> it just ftbfs on i386 due to that docs shizzle
[20:25] <dupondje> else its fine
[20:25] <dupondje> can be closes indeed
[20:25] <broder> k, will do
[20:25] <dupondje> reported the dh_installdocs bug upstream also :)
[20:32] <dupondje> broder: https://bugs.launchpad.net/ubuntu/+source/openmpi/+bug/697229 => doesn't seem to be a ftbfs, but a bug in the package itself
[20:32] <dupondje> checking if thats really fixed now
[20:32] <broder> dupondje: ah, i see
[20:33] <broder> dupondje: thanks for double-checking me
[20:34] <Daviey> dupondje: surely a ftbfs if not transient, is usually a bug in the package itself?
[20:35] <broder> Daviey: it's a bug from using the package
[20:35] <broder> openmpi does some code generation of one kind or another
[20:35] <Daviey> awesome.
[20:35] <dupondje> indeed :)
[20:38] <broder> dupondje: can you take care of reopening that bug if it isn't actually fixed?
[20:39] <dupondje> i'll do
[20:39] <broder> great
[20:47] <dupondje> broder: seems not fixed :)
[20:47] <broder> dupondje: alas
[20:48] <dupondje> can you change it to New again ?
[20:48] <dupondje> don't have the permissions it seems :s
[20:48] <broder> sure
[20:49] <smoser> barry, would you take a quick look at bug 813295
[20:55] <dupondje> broder: you requested a rebuild of openmpi ?
[20:55] <broder> dupondje: i'm doing a local test build with your patch now
[20:55] <broder> to make sure it works
[20:55] <broder> i'll upload once that finishes
[20:55] <broder> (it takes a *while* to build, apparently)
[20:56] <dupondje> no stress :D
[21:04] <barry> smoser: bug updated
[21:09] <smoser> barry, thanks again.
[21:09] <smoser> that issue is somewhat a big deal for us.
[21:11] <barry> smoser: let's see if anything happens upstream, and i can back port a fix.  if it gets critical for you, ping me and i'll try to spend some time on it
[22:37] <hallyn> is it possible to install debug symbols when running from live-usb?
[22:40] <RAOF> hallyn: Yup, they're essentially just regular packages.
[22:40] <hallyn> awesome, thanks :)
[22:40] <RAOF> hallyn: You'll need to add ddebs.ubuntu.com to the sources.list first, though.
[22:40] <hallyn> yup
[22:41] <hallyn> I may need to get my hands on an amd board to test kvm