[00:13] <stokachu> micahg: thanks, yea its targetted for 12.04.1 but ill keep an eye on it and if you can't get to it by next week ill make sure to get it handled
[00:16] <micahg> stokachu: well, if you just make sure the current debdiff works on quantal so when I go to sponsor, I don't run into issues, that would be great
[00:16] <stokachu> micahg: sure ill do that
[00:16] <micahg> stokachu: thanks
[00:16] <stokachu> np thank you :)
[00:21] <infinity> micahg: Looks like firefox/thunderbird is another case of "using the buildd to determine the target arch".
[00:21] <infinity> micahg: Which means they're getting it wrong on armhf too (I see a NEON define in there, for instance)
[00:22] <micahg> infinity: awesome :), well, cross building probably isn't a priority for upstream, but they'd probably take patches
[00:23] <infinity> Building for a generic target isn't "cross-building".
[00:23] <infinity> If all their Windows builds emitted SSE3 instructions, they'd be just as miffed. :P
[00:24] <infinity> But people seem to make these mistakes on ARM a lot more than x86.
[00:24] <infinity> Anyhow, I might look at it later.  The build log just showed me it was doin' it wrong.
[00:24] <micahg> infinity: heh, ok, well, I'm sure chrisccoulson would love a patch for that
[01:23] <dobey> cjwatson: doh. sorry about that. uploading fix now
[02:18] <stokachu> micahg: i got that debdiff attached to 977940, let me know if there is anything else I can do to help
[02:51] <micahg> stokachu: oh, thanks, I just wanted to make sure it built :)
[02:54] <stokachu> micahg: yea it builds
[03:16] <vibhav> cjwatson: you there?
[03:18]  * xnox at 4AM ?!
[03:19] <vibhav> Ah, Time Zones :(
[03:20] <infinity> Timezone, timeschmones.
[03:21] <TheMuso> For the insane among us perhaps, but I like my sleep.
[03:21] <micahg> heh, sleep, was nice once upon a time
[03:22] <TheMuso> I guess one factor for me is that I am a morning person.
[03:22] <xnox> TheMuso: well, I'm up at 4AM ;-)
[03:22]  * xnox went to bed at 8PM and now woke up
[03:22] <TheMuso> As I said, for the insane among us. :)
[03:22]  * xnox is fiddling with cdbs
[03:22] <xnox> ah, are you in ~ 4AM as well ? =))))
[03:22] <micahg> xnox: you're still asleep, stuck in a nightmare :)
[03:22] <TheMuso> No, its 13:22.
[03:23] <TheMuso> On a Thursday.
[03:23] <xnox> TheMuso: are in australia / japan or something?
[03:24] <TheMuso> Sydney Australia.
[03:24] <xnox> micahg: =((((
[03:24] <vibhav> Its 9 Am here
[03:24] <micahg> xnox: that's what fiddling with cdbs at 4AM sounds like to me :)
[03:24] <ajmitch> micahg: s/4AM/any time/
[03:25] <nigelb> ajmitch: lol
[03:25] <vibhav> nigelb: hehe
[03:28] <xnox> micahg: you are so judgemental =)
[03:32] <infinity> xnox: Being judgemental doesn't make him wrong.
[03:35] <micahg> xnox: I would think 90% of maintainers agree :) http://upsilon.cc/~zack/stuff/dh-vs-cdbs/
[03:35] <pitti> Good morning
[03:35] <ajmitch> morning pitti
[03:36] <micahg> hrm ,about 15% of main uses cdbs
[03:37] <xnox> micahg: cdbs supports flavors. Running VPATH builds with different configure flags for each build: e.g. full, minimal, udeb, etc...
[03:37] <xnox> micahg: simply specify a list of flavours & configure flags for each one ;-)
[03:37] <micahg> xnox: that doesn't mean that it's not a bear to use :)
[03:37]  * xnox =(
[03:38] <xnox> pitti: Good morning, I'm about to go back for my second half of sleep ;-)
[03:38] <pitti> hey xnox, how are you?
[03:38]  * micahg just read an article about that
[03:38] <xnox> pitti: good good, went to bed early woke up in the middle of night =)
[03:41]  * vibhav wonders how large coffee cups devs have
[03:41]  * micahg goes to get some tea
[03:44] <xnox> vibhav: 0.35ltr
[03:44] <xnox> http://shop.canonical.com/product_info.php?products_id=828
[03:44] <xnox> I also have the previous cup, it's less capacity
[03:45] <xnox> was a nice upgrade =)
[03:46]  * vibhav drools
[03:46] <pitti> xnox: congratulations to your new core-dev badge!
[03:47] <xnox> pitti: thank you.
[03:48] <xnox> although i would still like code review before uploading core stuff
[03:48]  * xnox doesn't want to be the guy who broke quantal
[03:48] <infinity> xnox: Don't worry, that's me currently.
[03:49] <micahg> xnox: knowing when to ask for help is important, no one knows everything
[03:49] <vibhav> infinity: By breaking, you mean dpkg, right?
[03:50] <infinity> vibhav: Indeed.
[03:50] <micahg> infinity: don't worry, it falls under the title of uploader of eglibc :)
[03:51] <infinity> micahg: I only break eglibc in Debian.
[03:51] <infinity> micahg: Well, so far.
[03:51] <vibhav> hehe
[03:51] <xnox> vibhav: technically, whoever merged early multi arch support way back in precise (??) broke dpkg
[03:51] <infinity> Maybe I'll break it in Ubuntu with the next upstream.  Stay tuned.
[03:51] <micahg> infinity: I meant breaking the archive, it's all encompassing :)
[03:51] <infinity> xnox: natty.
[03:51] <xnox> infinity: was it still you?!
[03:51] <infinity> xnox: We've been multiarching for a long time.
[03:51] <infinity> xnox: And no, it wasn't me.
[03:51]  * xnox BINGO!
[03:52] <micahg> xnox: nope, not at all, the dpkg implementation multiarch changed after we introduced it
[03:52] <infinity> And what he said.
[03:52] <infinity> I'm still trying to sort out what the guard is preventing.
[03:52] <infinity> So, if you have a non-ma-same package in an rc state, and you want to install an ma-same version from another arch, it flips out.
[03:53] <infinity> That seems fair.
[03:53] <xnox> infinity: I think the brain damage of having 3 packages installed: pkg        pkg:i386      pkg:amd64
[03:53]  * ajmitch should try & upload some packages tonight
[03:53] <infinity> But wouldn't that be exactly the same situation if you have an old ma-same version in rc, and want to install a new on from another arch?
[03:53] <infinity> There's still a chance of whacky conflict.
[03:53] <infinity> xnox: But if it's just a mapping issue, we can kludge it the same way we did for triggers.
[03:53] <infinity> xnox: noarch = native, done.
[03:54] <xnox> yeap, but the files in the non-multiarch location must be identical
[03:54] <xnox> across all architectures
[03:54] <infinity> xnox: Yes, but they're NOT identical in the ma-same-rc plus ma-same-install case either.
[03:54] <xnox> noarch = native, will not help with triple arch
[03:54] <infinity> xnox: Eh?  it's not triple arch once you've mapped it.
[03:55] <xnox> infinity: if they are not, then it's an RC bug against the package. There were a few of those recently
[03:55] <infinity> xnox: pkg = pkg:native
[03:55] <infinity> xnox: No, no.  You're missing the point.
[03:55] <xnox> infinity: as it pkg = pkg:native will not help if you have i386, amd64 and armhf multiarches enabled
[03:55] <infinity> xnox: You remove libfoo:i386, it poops conffiles.  You later install a NEWER version of libfoo:amd64.  That's no guarantee of identical anything anymore.
[03:56] <infinity> xnox: If you have ma-same stuff installed this doesn't trigger.  It's only for the old skool pre-ma packages this is an issue, which is where you map noarch=native.
[03:56] <xnox> true
[03:56] <infinity> xnox: And, in that case, I fail to see how it's then any different from the scenario I paint above, with different versions.
[03:57]  * xnox needs to read multiarch spec again, what ma-same means
[03:57] <infinity> xnox: M-A:same means paclages can be co-installed.
[03:57] <infinity> xnox: So, most multiarch libraries.
[03:58] <micahg> infinity: I think the issue is without the package being marked m-a:same, there's no guarantee the conf files won't conflict
[03:58] <infinity> xnox: And this error specifically trips on M-A:same + pre-M-A-rc
[03:58] <infinity> micahg: There isn't anyway.
[03:58] <infinity> micahg: It's tripping on a REMOVED (but not purged) package.
[03:58] <micahg> infinity: yes, but I think that's what it's trying to guard against
[03:58] <infinity> micahg: You can't enforce the contents of mismatched packages.
[03:59] <xnox> and one of the requirement is that they (a) do not install anything in non-multiarch qualified locations (b) if the do install anything outside => they must be identical across all arches. So yeah, I see your point that rc should not matter, unless it's in like /usr/lib/$ANY_TRIPLET/libc6.so
[03:59] <infinity> micahg: Like i said, this is (afaict), no different than having a removed libfoo1:i386_1.2.3-1 and then installing a new libfoo1:amd64_1.2.3-2
[03:59]  * xnox wants to create config file /usr/lib/$ANY_TRIPLET/libc6.so for giggles
[04:00] <micahg> infinity: right, but maybe it's trying to do some conf file handling in some futile fashion (my best guess ATM)
[04:01] <xnox> infinity: well multiarched libraries do not ship conf / conffiles
[04:01] <infinity> xnox: I'm trying to wrap my head around how noarch=native would break things here (or, be any worse than the situation I've outlined above), but I suspect it's the way forward for now.
[04:01] <slangasek> infinity: so dpkg should regard the m-a: same package as implicitly replacing, and therefore taking over, any conffiles?
[04:01] <infinity> micahg: Even if it is, I don't see how the arch matters.
[04:01] <infinity> slangasek: Why not?  That's what it does on newer-same -> older-same?
[04:01] <infinity> slangasek: If so, I don't see why new-same -> old-non-same should be different.
[04:02] <micahg> infinity: it might be worried about the old conf file being broke in the multiarch world
[04:03]  * xnox want's to look at the sample dpkg tarball from the bug to see what library shipped a conf file in the first place
[04:03] <infinity> slangasek: Whatever it's doing in the old->new (but both same) scenario, that seems the sane thing to do for non-same->same.
[04:03] <infinity> micahg: That's just weird speculation.  It's a package's job to upgrade its broken conffiles, not dpkg's job to guess.
[04:04] <xnox> infinity: will that break upon people trying to use multiarch to do a cross-arch dist-upgrade / reinstall to migrate from i386 -> amd64
[04:05] <infinity> xnox: For one, that's not even remotely supported.  For two, how does it break it?
[04:05]  * xnox ponders
[04:06] <micahg> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676496 ?
[04:06] <xnox> it won't because there is only on :native at a time.
[04:06] <xnox> it won't because there is only one :native at a time.
[04:08] <infinity> micahg: Hrm.  That isn't the same bug/misfeature, is it? :P
[04:08] <micahg> infinity: not exactly, but looks like it might be close
[04:09] <infinity> No, definitely not the same bug.
[04:11] <micahg> I figured it might give some hint on where to look
[04:13] <infinity> Don't think it relates, really.
[04:13] <infinity> But I should merge that version...
[04:23] <xnox> infinity: if the new libfoo:native does not ship the config file anymore, and for example that file got moved into an foo:all package, that stale rc file will be removed?
[04:24] <xnox> libfoo:native is now ma-same, old libfoo is not.
[04:24] <infinity> xnox: To be honest, I'm not sure what happens, but I don't see why it should be any different than in the mismatched-versions-of-ma-same-packages case, do you?
[04:25] <infinity> There's no reason to assume that a migration a removed libfoo between and old non-ma version and a new ma-enabled version will be significantly more broken than between, say, two wildly skewed but both ma-same versions.
[04:26] <infinity> s/migration a/migration of a/
[04:26] <xnox> infinity: have you seen that in the bug 1015616 the problem got resolved by adding :native to the culprit packages
[04:27] <infinity> xnox: Actually, he added M-A:same headers, but the end result internally in the pkgset logic would be the same.
[04:28] <infinity> xnox: Anyhow, I've thought too much about this for today, but if you come up with any snazzy ideas that you want to talk over, I'll be awake sometime tomorrow. ;)
[04:29] <xnox> infinity: the kicker is that the conffile was not modified, it's untouched in both packages of the bugreporter
[04:30] <xnox> infinity: i'd just pre-purge those packages
[04:30] <infinity> xnox: I don't see why modified or not should matter, really.
[04:30] <xnox> no data loss ;-)
[04:31] <infinity> There's no data loss if you do a conffile takeover either.
[04:31] <xnox> if it fails with an rc package, would it also fail with an installed one?
[04:31] <infinity> Which is exactly what happens if you go "old i386 package removed" -> "new amd64 package installed" of different versions, with a modified and shared conffile.
[04:31] <infinity> xnox: With an installed one, it will force the upgrade.
[04:31] <infinity> xnox: Cause the versions have to match.
[04:32] <xnox> right.
[04:32]  * xnox has no concerns about going for rc -> :native
[04:32] <infinity> It seems like the sane way to go.
[04:32] <infinity> Might make your eyes bleed a bit sorting out where to do that.
[04:33] <xnox> infinity: are you doing the new merge first though?
[04:33] <infinity> Tracing back from the error message, and stepping back through every function until you get to the one that seems reasonable to fix. :P
[04:33] <xnox> or not.
[04:33] <infinity> xnox: I won't be merging tonight.  Shouldn't impact your fix anyway.
[04:34] <xnox> ok
[04:34]  * xnox off to sleep for shorter second half, before starting my day
[04:34] <infinity> xnox: Or, you can just merge if you like.  MoM actually got it right, except for a conflict in control.
[04:34] <xnox> hmmm. ok
[04:34] <infinity> xnox: (I assume due to the fiddling with xz-utils and lockfile deps)
[04:35] <infinity> Actually, since MoM got it right and I just need to eyeball it, I'll just upload this now.
[04:35] <xnox> still needed after precise, or is it to be backports safe?
[04:35] <infinity> And you can do your stuff when you wake up.
[04:35] <xnox> great. deal.
[04:35] <infinity> We don't aim to backport dpkg.
[05:13] <micahg> infinity:  MoM has a useful ../merge-buildpackage script :)
[05:14] <infinity> micahg: Hrm?
[05:14] <micahg> it calls its useful merge-genchanges script to auto add the -v from the previous Ubuntu verison :)
[05:14] <micahg> *version
[05:15] <infinity> micahg: Oh, I missed the -v after I went and added more changes.  Silly me.
[05:15] <infinity> micahg: Oh well.
[05:18] <infinity> jbicha_: Thanks for updating UML!
[05:24] <RAOF> But there *are* to AAs who have been active in #ubuntu-release in the last 10 minutes or so ☺
[05:24] <RAOF> Imagine that went into #ubuntu-desktop, where it was intended.
[05:27] <infinity> RAOF: Hahaha.
[05:27] <infinity> RAOF: What needs AAing?
[05:28] <robert_ancell> infinity, new package bug 1011361
[05:30] <infinity> robert_ancell: Ahh, doing a NEW source review probably isn't on my list of things to do at 23:30, I'll punt.
[05:30] <robert_ancell> infinity, fair enough
[05:30] <infinity> robert_ancell: But if no one's looked at it before tomorrow, you can give me a gentle nudge.
[06:14] <cjwatson> dobey: thanks
[06:40] <jibel> pitti, the crash I get while reporting a bug seems to be https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1015788
[06:41] <pitti> jibel: ah, that's not the one in DKMS again
[06:41] <pitti> jibel: I just fixed bug 1007826, currently fixing dkms, will then look at that one
[06:42] <pitti> jibel: could you please add what command you were trying to run?
[06:42] <jibel> pitti, right, it's different. dkms crashes which triggers apport which in turn crashed with the "invalid problem report" dialog
[07:01] <dholbach> good morning
[07:08] <enrico> Why is http://paste.ubuntu.com/1052137/ requiring me to log into launchpad to download the patch as text?
[07:08] <pitti> so that you cannot abuse it to anonymously store tons of data there (a la filesharing)
[07:10] <enrico> pitti: couldn't that have been done like any other pastebind does, or requiring the login only for contents >100Kb? I've been pushed that patch to be applied in Debian, not Ubuntu, and I find it ridiculous that I need to have a launchpad account in order to have a version that I can feed to patch
[07:10] <pitti> >100 kB sounds sensible indeed
[07:11] <pitti> enrico: need the patch? I can put it someplace else for you
[07:12] <enrico> pitti: thanks, copypaste seems to have done TRT
[07:18] <cjwatson> enrico: #canonical-sysadmin would be the place to complain about it - #ubuntu-devel doesn't admin the pastebin
[07:21] <enrico> cjwatson: any reasonable place I could file a bug instead?
[07:21] <cjwatson> I don't know, sorry
[07:22] <cjwatson> If there were, it would require a Launchpad account ;-)
[07:22] <smb> dupondje, For the Xen package I am waiting for the review of my merge. The current version in Quantal is only there because of the initial pocket copy done. It would not compile in Q.
[07:22] <enrico> cjwatson: I should still have a launchpad account I can use to report bugs; my problem is being forced to use it when doing things that are not ubuntu-specifc
[07:23] <cjwatson> sure
[07:34] <Laney> enrico: cjwatson: I once filed an RT about that and it was denied
[07:36] <diwic> Laney, for what reason? I'm curious, because I've got complaints from my upstream friends about it too.
[07:36] <bkerensa> anyone know why Quickly is install two versions of glade and potentially two versions of the depends for each version of glade?
[07:36] <bkerensa> on Quantal
[07:37] <Laney> diwic: enrico: https://rt.ubuntu.com/Ticket/Display.html?id=18758
[07:37] <Laney> (yes, you probably need to log in to see that …)
[07:37] <cjwatson> guest/guest IIRC
[07:38] <cjwatson> or maybe ubuntu/ubuntu
[07:38] <cjwatson> the latter
[07:38] <cjwatson> ... oh.  it used to be.  I guess it's all SSO now?
[07:38] <enrico> cjwatson: none of those. Now trying to work out how SSO works
[07:38] <Laney> using the same credentials as LP
[07:40] <enrico> Laney: found it, and sigh.
[07:40] <Laney> I just default to paste.d.n now
[07:41] <cjwatson> I'm sure most people supplying pastes would be happy to do so in a more convenient way if requested
[07:41] <enrico> Laney: I did indeed resolve to ask the person not to use paste.ubuntu when sending stuff to non-ubuntu developers
[07:41] <diwic> Laney, thanks
[07:44] <diwic> Laney, although I'm a little surprised that the spammers can't use the non-login version as well (just strip away some html code)
[07:45] <bkerensa> barry: do you know why might be installing two versions of glade?
[07:45] <bkerensa> quickly*
[07:55] <dupondje> smb: ok great :)
[07:56] <pitti> cjwatson: yay, thanks for change-override
[07:59] <xnox> good morning =)
[08:00] <cjwatson> pitti: You're welcome :-)
[08:00] <cjwatson> pitti: Do you know if it's been necessary to run firefox-overrides in recent times?  I have a feeling that the override ancestry bug that prompted that has been fixed
[08:01] <pitti> cjwatson: I have never used that oen
[08:01] <pitti> one
[08:01] <pitti> chrisccoulson, micahg: ^ do you know about this?
[08:01] <cjwatson> https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA FWIW
[08:02] <cjwatson> That script needs to be moved to client-side, but if it's no longer needed then I would be just as happy to remove it
[08:02] <micahg> pitti: I didn't know there was such a thing :)
[08:02] <cjwatson> OK, I'm going to take a punt and say that this has been fixed - the LP copying code looks up the new ancestry of binary packages it copies and tries to apply matching overrides
[08:03] <pitti> at least in precise and quantal, all binaries are in main anyway
[08:03] <melodie_> hello
[08:03] <cjwatson> This doesn't work for the kernel because package names tend to change, but it should be fine for firefox
[08:03] <micahg> cjwatson: lately, the only thing that needs overrides are new binaries
[08:03] <pitti> in oneiric, -mozsymbols is in universe
[08:03] <pitti> and so it is in oneiric-updates
[08:03] <pitti> so whavever is done for those, it works without that script apparently
[08:03] <pitti> cjwatson: *nod*
[08:04]  * cjwatson looks up the publishing history for that to check
[08:04] <pitti> cjwatson: even for the kernel, all packages that don't change keep their component
[08:06] <micahg> well, there was some work done to make copies to the archive end up in the proper component
[08:07] <micahg> or rather make copies respect existing components
[08:07] <cjwatson> I think that's what I'm referring to above
[08:07] <cjwatson> Assuming you mean work in LP as opposed to per-upload work
[08:08] <melodie_> I'll bb
[08:08] <micahg> yes
[08:10] <cjwatson> lib/lp/soyuz/adapters/overrides.py:UbuntuOverridePolicy is applied to binary copies, and looks like it should be right
[08:16] <cjwatson> And I've confirmed that none of the BPPHs for firefox-mozsymbols in oneiric since at least mid-March have been anywhere except universe
[08:27] <melodie_> hi
[08:28] <micahg> cjwatson: that's good news re: binaries ending up where they belong
[08:42] <melodie_> I am looking for a simple way to update with packages coming from another machine (a place where the connection is much faster). I failed when trying to just copy the apt directory from /var/cache : is there a simple way to do that ?
[08:43] <cjwatson> /usr/share/doc/apt-doc/offline.html/index.html talks about this
[08:44] <cjwatson> Don't know how current it is but my guess is it should require at most minor adjustments
[08:44] <melodie_> hi cjwatson, I look, thanks
[08:47] <melodie_> cjwatson: there is no "apt-doc" directory in /usr/share/doc in precise
[08:49] <melodie_> I am going to try to cheat and put the packages in the "partial" directory
[08:50] <cjwatson> melodie_: That's because you don't have the apt-doc package installed.
[08:50] <melodie_> It looks like it wants to work.
[08:57] <melodie_> cjwatson: you are probably right. well, putting the packages from /var/cache/apt/archives to /var/cache/apt/archives/partial, then "apt-get update && apt-get dist-ugrade" seems to work. I'll know in a moment when the unpacking and replacing will be finished.
[09:12] <melodie_> bbl
[09:17] <infinity> rbelem: And progress on the new snapshot for plasma-mobile?
[09:37] <jdstrand> cjwatson: fyi, I wrote that bit in AA for firefox some time ago. while firefox hasn't needed it for quite sometime, it seems I have had to use it on rare occasion for non-kernel stuff
[09:37] <jdstrand> cjwatson: however, I think it is fine to remove it-- it is really just my team and the SRU team that use it
[09:38] <jdstrand> my team knows about it and the SRU team has a documented process for the kernel still anyway
[09:43] <cjwatson> jdstrand: Well, you have find-bin-overrides still; firefox-overrides was hardcoded to firefox so was clearly of no use
[09:43] <cjwatson> jdstrand: When you next see this for something that isn't the kernel, I'd like to hear about it
[09:43] <cjwatson> jdstrand: There's still a section below explaining the use of find-bin-overrides
[09:45] <jdstrand> cjwatson: oh, I missed we were talking about firefox-overrides and not find-bin-overrides. yes, I haven't used firefox-overrides in ages
[09:45] <jdstrand> and yeah, the section below on find-bin-overrides was what I was referring to with "the SRU team has a documented process for the kernel"
[09:46] <cjwatson> I'd still like to know about non-kernel cases.  My reading of the code is that manual overrides should never be necessary when copying from PPAs, *unless* the binary packages in question are new to that distroarchseries
[09:46] <jdstrand> noted
[09:47] <infinity> We do sometimes get new packages in SRUs and security updates that aren't kernels.
[09:47] <jdstrand> I don't have specifics atm. I want to say openjdk-6, but it has been too long
[09:47] <infinity> mozilla.org sources introduce new translationy bits, if I recall.
[09:47] <jdstrand> infinity: re secureity updates> on occasion
[09:48] <jdstrand> bind9 might be another
[09:48] <cjwatson> Yeah, it does happen now and again.  My feeling is that fixing bug 192076 will sort out most of it, and for the rest, manual overrides would be OK.
[09:48] <infinity> Yeah, I'm happy with doing it manually when it comes up anyway.
[09:48] <infinity> And fixing that ancient bug would just make that process simpler.
[09:48] <cjwatson> I have a test case for half of it now.
[09:49] <cjwatson> There are two pieces: firstly, the override policy doesn't implement this suggestion; secondly, normal uploads (as opposed to copies) don't use the override policy as extensively as they should
[10:02] <ogra_> pitti, http://paste.ubuntu.com/1052388/ does that look sane to you ?
[10:04] <pitti> ogra_: if you really want to match the names that precisely, sure
[10:04] <pitti> ogra_: I don't have "Hardware" in my /proc/cpuinfo (amd64), all keys are lower-case; is that really right?
[10:05] <ogra_> pitti, well, once we get omap3 drivers there will be many boards our kernels work on but the pvr driver likely wont
[10:05] <ogra_> yeah, HArdware isnt in x86 but on all arm SoCs
[10:05] <pitti> ogra_: stick the file into /usr/share/ubuntu-drivers-common/detect/ and run "ubuntu-drivers debug", to ensure that it's working
[10:05] <tumbleweed> unfortunately, /proc/cpuinfo is completely different across archs
[10:06] <ogra_> ah., great, thats what i was missing, i just added a main() function and ran it with prints for testing
[10:06] <ogra_> tumbleweed, yeah, but luckily reliable at least on arm :)
[10:09] <ogra_> pitti, http://paste.ubuntu.com/1052397/ looks fine
[10:09] <pitti> ogra_: yep
[10:09] <ogra_> seems panda even has a modalias (most other arm paltforms wont though)
[10:14]  * Daviey tries to use apport to report an apport bug
[10:15] <Daviey> sadly, it fails.. and i'm expecting apport to try to report a bug, about the bug that i encountered a bug when trying to report a bug.. GOTO 10
[10:17] <pitti> Daviey: please update to apport 2.2.4, I fixed two major bugs this morning
[10:17] <Daviey> pitti: i'm running 2.2.4-0ubuntu1
[10:17] <pitti> ok, then I need more information, I'm afraid
[10:18] <Daviey> pitti: I'll raise a bug, but looks like a py3 issue... ""
[10:18] <Daviey> startswith first arg must be bytes or a tuple of bytes, not str
[10:19] <Daviey> bug 1015788
[10:20] <pitti> Daviey: hm, that's what I fixed this morning, or at leat I thought I did
[10:20] <pitti> Daviey: can you please attach your .crash file there? It might stumble over a different code path; I tested with jibel's and that works for me now
[10:24] <jml> running apt-get dist-upgrade, is there a way to specify "don't ask me any (debconf) questions?"
[10:24] <jml> this is for an automated process to spin up a new 12.04 server
[10:25] <astraljava> jml: With the -y option it should assume yes to questions.
[10:25] <cjwatson> astraljava: That doesn't affect debconf.
[10:25] <infinity> jml: DEBIAN_FRONTEND=noninteractive
[10:25] <astraljava> My apologies, I mixed things up.
[10:26] <infinity> But you do want -y as well for unattended apt-gettery.
[10:26] <jml> infinity: thanks. I'll try that out.
[10:27] <jml> nope.
[10:27] <infinity> jml: There's also --force-yes, but I'd contend that if your archive or system are in a state where that would be required, you're usually better off with the error. :P
[10:28] <jml> I still get prompted by console-setup
[10:28] <jml> I guess there I need to use debconf-set-selections or something?
[10:28] <cjwatson> Er
[10:28] <cjwatson> It shouldn't be able to prompt if you've *correctly* set DEBIAN_FRONTEND=noninteractive
[10:28] <cjwatson> Exactly what command line did you use?
[10:29] <jml> export DEBIAN_FRONTEND=noninteractive; sudo apt-get update -q; sudo apt-get dist-upgrade -q -y --force-yes
[10:29] <cjwatson> sudo filters the environment.
[10:29] <jml> ah right.
[10:29] <cjwatson> sudo apt-get update -q; sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -q -y --force-yes
[10:29]  * jml man sudo
[10:30] <cjwatson> (Though personally I wouldn't use --force-yes, for the reasons explained in apt-get(8).)
[10:30] <infinity> jml: And yeah, I'd skip --force-yes
[10:30] <infinity> jml: The error is almost always better than having it solve it for you.
[10:30] <jml> so, just -y
[10:30] <cjwatson> Yeah
[10:30]  * infinity nods.
[10:30] <jml> ok.
[10:30] <Laney> sudoers(8) → "env_reset"
[10:31] <jml> that bit is cargo-culting. I'll check out the man page so I can learn this proper.
[10:31] <infinity> Holy crap, → is a compose set?
[10:31] <jml> yeah
[10:31] <infinity> This changes everything.
[10:31] <jml> ->
[10:32] <infinity> → ←
[10:32] <jml> infinity: it's magical _and_ revolutionary.
[10:32] <infinity> Right.  That shouldn't excite me.  For the fifth attempt tonight, nap time.
[10:33] <Daviey> pitti: attached
[10:34] <pitti> Daviey: btw, I fixed that dkms bug this morning, too
[10:34] <pitti> i. e. the one that generated _usr_share_apport_package-hooks_dkms_packages.py.0.crash in the first place
[10:35] <Daviey> pitti: wine is for fglrx rather than virtualbox.. i marked the bug back to Confirmed.. I didn't think you'd want a seperate bug
[10:36] <Daviey> s/wine/mine
[10:36] <pitti> yes, the bug was in dkms' apport hook; not driver specific at all
[10:37] <pitti> Daviey: can you please check the version in dpkg -l python-apport ?
[10:37] <pitti> your .crash works for me (and in fact, it's the exact same as jibel's)
[10:38] <Daviey> pitti: ii  python-apport  2.2.4-0ubuntu1
[10:38] <pitti> ok, then I'm officially clueless why it still happens for you :/
[10:39] <Daviey> pitti: I upgraded, rebooted to get the fresh kernel.. and the timestamp on the .crash file is that of first boot.
[10:39] <pitti> Daviey: are you using apport-cli, and the "view report" option?
[10:39] <Daviey> pitti: i've not touched apport-cli, this was the gui error raised on first boot
[10:40] <pitti> ok, tested apport-gtk as well; but shouldn't make a difference, it's all the same backend code
[10:42] <Daviey> pitti: Okay, should i rm the .crash file and reboot, see if i get the same result?
[10:42] <pitti> followed up to the bug
[10:42] <pitti> Daviey: the .crash file is not the issue here
[10:42] <pitti> it's apport crashing if you try to report the DKMS bug
[10:43] <Daviey> pitti: well, i can confirm that apport-cli does work.
[10:43] <pitti> Daviey: if you run apport-bug /var/crash/_usr_share_apport_package-hooks_dkms_packages.py.0.crash, what happens?
[10:45] <Daviey> pitti: huh, problem cannot be reported... The problem happened with the program /usr/share/apport/package-hooks/dkms_packages.py which changed since the crash occurred.
[10:45] <pitti> ah, right
[10:45] <pitti> that wouldl be the fixed dkms :)
[10:45] <Daviey> but I haven't upgraded since...
[10:45] <pitti> dpkg -l dkms ?
[10:45] <Daviey> 2.2.0.3-1ubuntu4
[10:45] <pitti> Daviey: that's the new one from this morning
[10:45] <pitti> https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-1ubuntu4
[10:46] <pitti> which fixed that very bug (bug 1008092)
[10:46] <Daviey> pitti: Yes, but i am saying that i upgraded, rebooted, then hit this issue.. So how did it change without touching apt?
[10:47] <Daviey> Anyway, if this is gone for others.. and an oddity, i'm happy to ignore it.. just very peculiar.
[10:47] <pitti> so it seems the apport crash is confirmed fixed for you as well
[10:48] <pitti> Daviey: perhaps you opted to not report the dkms crash in the session where you did the upgrade?
[10:48] <Daviey> pitti: that sounds likely, and makes sense.
[10:48] <Daviey> thanks.
[10:48] <pitti> anyway, I'm fairly confident that both bugs are fixed now
[10:49] <pitti> Daviey: and on top of that, I wrote an ubuntu-drivers-common autopkgtest which will exercise the binary drivers, to ensure that they build, install, and work :)
[10:49] <pitti> I didn't add the virtualbox ones, though, but that's easy
[10:49] <pitti> Daviey: virtualbox-dkms, right?
[10:51] <pitti> jibel: speaking about this, do you have an idea how the u-d-common adt test can be triggered for each new kernel upload? I could add a linux-y dependency to it, but which depends do you parse exactly? debian/control b-deps, binary deps, or debian/tests/control ?
[10:51] <Daviey> pitti: no, my failure was fglrx.
[10:52]  * pitti -> lunch, bbl &
[10:58] <mterry> barry, is the goal for Quantal to have python3-only on only the Ubuntu Desktop CD or also the Ubuntu Server CD?
[11:00] <mterry> Ah, desktop I see in the blueprint
[11:00] <jibel> pitti, I added another case to reproduce 1015788 with apport 2.2.4-0ubuntu1 this time with accerciser.
[11:08] <Daviey> mterry: confirmed it's not a target for server this cycle.
[11:35] <jibel> pitti, binary deps
[11:36] <cjwatson> dupondje: Do you think you could take the courier merge from me, please?  You did the last substantive merge - all I did was rebuild it for a Perl transition
[11:40] <ogra_> pitti, hmpf, so to contribute to ubuntu-drivers-common i need a github account ? why is that not on LP as a bzr branch ?
[11:41] <ogra_> tseliot, ^^^
[11:42] <tseliot> ogra_: a matter of taste
[11:42] <ogra_> no, a matter of workflow imho ... i cant just file a merge request now
[11:42] <jibel> pitti, more precisely binary depends of all the binaries built from a source package. for u-d-common that'd be binary deps of u-d-common, dh-modaliases and nvidia-common
[11:43] <ogra_> nor will UDD work with it in any way
[11:48] <pitti> ogra_: I can just put in the file for you
[11:50] <pitti> jibel: hm, so we could only add a dependency like linux-generic to u-d-common
[11:52] <ogra_> pitti, tseliot bug 1016006
[11:52] <pitti> ogra_: thanks, will do
[11:52]  * ogra_ finds that massively annoying btw
[11:54] <pitti> it is indeed
[11:55] <pitti> but well, if someone will just upload or use UDD, it's always possible to import that into the git, too
[11:55] <ogra_> sure
[11:56] <ogra_> what bothers me is that it is a tool we ship on the CD and provide as a core component, there should at least be a bzr import from the github branch that we can work with on LP
[11:57] <ogra_> i dont mind if someone wants to use git because he prefers it, but excluding all other devs from committing doesnt look very ubuntu to me
[11:57] <pitti> just weird that there is no UDD branch for it
[11:58] <pitti> oh, there is
[11:58] <pitti> bzr lp-open lp:ubuntu/ubuntu-drivers-common
[12:00] <ogra_> well, i'll use this one in the future or just upload and leave it to tseliot to merge into his git branch
[12:02] <tseliot> ogra_: it's a shared branch and I can give you commit privileges if you like
[12:02] <pitti> jibel: are you sure it's the same crash? If I let accerciser crash and run apport on it, I get bug 1014341
[12:02] <tseliot> ogra_: otherwise your solutions are fine too
[12:02] <ogra_> tseliot, i dont want a github account
[12:02] <jibel> pitti, let me try again
[12:02] <ogra_> and i am already in a  team that should have full access to the source of the ubuntu core componnents
[12:03] <pitti> jibel: i. e. with apport-cli it works just fine, with apport-gtk I get above carsh (which does not affect -cli, as that does not parse desktop files)
[12:04] <jibel> http://paste.ubuntu.com/1052519/
[12:04] <jibel> pitti, ^
[12:04] <pitti> jibel: if line.startswith('tags:'):
[12:04] <pitti> that's not what apport 2.2.4 has
[12:04] <pitti> that fixed it to b'tags:'
[12:04] <pitti> jibel: dpkg -l python-apport?
[12:05] <pitti> jibel: err, dpkg -l python3-apport
[12:06] <pitti> jibel: argh, nevermind
[12:06] <pitti> that was b'bugs:'
[12:06] <pitti> as I actually got a string array here after the line splitting
[12:06] <jibel> pitti, http://paste.ubuntu.com/1052523/
[12:06] <pitti> so why the heck can't I reproduce this
[12:07] <pitti> jibel: anyway, will look into it harder, thanks
[13:04] <arges> mvo, hi. noticed a ftbfs in debtags. Just need to add 'dh-autoreconf' to Build-Depends. I have a patch if needed: http://people.canonical.com/~arges/plusone/debtags-ftbfs.debdiff     Laney mentioned this is also broken in Debian.
[13:09] <mvo> arges: uh, thanks
[13:11] <mvo> arges: pushed to the upstream git
[13:11] <vibhav> we use git for ubuntu?
[13:12] <Laney> he said upstream git
[13:12] <vibhav> ah
[13:12] <arges> mvo, cool.
[13:12] <vibhav> "Attention to Detail" :(
[13:25] <nuketro0p3r> #F2F2CEI edited the /usr/share/themes/Ambiance/gtk-2.0/gtkrc to fix my Eclipse tooltip. It worked, but how come my tooltip in other softwares is intact? - just curious o.O
[13:25] <nuketro0p3r> Any one have a clue?
[13:25] <nuketro0p3r> please ignore the color code in the beginning.
[13:33] <cjwatson> ailo: qjackctl is imported and synced to quantal now, although as predicted it's failing to build for much the same reason it was failing to import: https://launchpad.net/ubuntu/+source/qjackctl/0.3.9-1
[13:35] <cjwatson> ailo: For the record, three packages were affected, and all three are now fixed
[14:28] <xnox> cjwatson: slangasek about bug #1015567
[14:29] <xnox> i have created two packages: (a) no m-a, amd64, v1 with a conffile. (b) m-a, i386,v2 with same conffile
[14:29] <xnox> installing and removing the (a), installing (b) => succeeds
[14:29] <xnox> http://paste.ubuntu.com/1052700/
[14:30] <xnox> so I can't reproduce it in clean pbuilder
[14:30] <xnox> did I miss something?
[14:37] <cjwatson> xnox: I think you need to install (b) over (a) using precise's dpkg, and then upgrade to quantal's dpkg and try installing something else
[14:37] <ailo> cjwatson: Thanks. I guess the building failure will be fixed sometime soonish? I'll keep an eye out beginning next week. The haze of midsummer is shortly closing in
[14:37] <cjwatson> xnox: the problem isn't that quantal's dpkg corrupts things, AFAIK; it's that precise's dpkg left a corrupted database in place, and now quantal's dpkg objects to it
[14:38] <cjwatson> ailo: It won't happen automatically, and I'm not doing it, so I don't knw
[14:38] <cjwatson> *know
[14:38] <cjwatson> Hopefully somebody will pick it up, or you could send a patch ...
[14:39] <ailo> Ok. I'll investigate more next week then :)
[14:41] <xnox> cjwatson: ok. that will break.
[14:42] <xnox> cjwatson: so the bug is not due to left over rc config file
[14:50] <mpt> ev, hi, when updates are installed pre-login, where will the UI for that be? Will it be in Plymouth, like fsck?
[14:51] <cjwatson> xnox: I never thought it was :-)
[14:52] <cjwatson> It's not due to the config file itself, but due to the package being there in rc state with its .list file inadvertently removed from /var/lib/dpkg/info/
[14:52] <cjwatson> As Guillem/Raphael explained on -dpkg
[14:53] <xnox> ok. I get the error now, but it's different from the bug report message
[15:00] <xnox> cjwatson: do you have a link to the explanation the thread is long
[15:02] <cjwatson> No, just the first post in that thread by buxy
[15:02] <cjwatson> And the original post by Guillem
[15:08] <barry> kenvandine: https://bugs.launchpad.net/ubuntu/+source/libpeas/+bug/1015868 :)
[15:09] <kenvandine> barry, thx, saw your email!
[15:09] <kenvandine> yay!
[15:09] <kenvandine> i'll look at it soon
[15:09] <barry> awesome.  let me know if i can help with anything else for gwibber
[15:09] <kenvandine> barry, thx!
[15:23] <pitti> cjwatson: @ udeb expansion> will do that (tomorrow), thanks for pointing out
[15:26] <cjwatson> pitti: thanks
[15:29] <nemo> So, Like many people, I'm really missing not having notification-daemon in 12.04
[15:29] <nemo> If I search for the relevant crasher from what I see in gdb, I get a ton of hits on launchpad
[15:29] <nemo> unfortunately, they seem to be duped against https://bugs.launchpad.net/bugs/926583
[15:30] <nemo> which appears to either be missing or not accessible by me
[15:30] <nemo> Now, there's a debian bug (and fix) on exactly this problem.
[15:30] <nemo> AFAIK has even been packaged.
[15:31] <nemo> All I'd like to know is.  Is ubuntu planning to address this at some point? 'cause I really missing having notify-send.  And, if they aren't, and that is a locked bug, unlocking it would be appreciated so people could try to figure out workarounds
[15:31] <nemo> otherwise, duping stuff against something that either doesn't exist or won't be fixed any time soon isn't too helpful :(
[15:32] <nemo> https://www.google.com/search?q=site%3Alaunchpad.net+gdk_pixbuf_scale_simple+notification-daemon+crashed
[15:32] <nemo> https://bugzilla.gnome.org/show_bug.cgi?id=673749
[15:33] <nemo> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669883
[15:34] <mpt> nemo, notify-send works for me with notify-osd in 12.04, as it has for every version since 9.04. It doesn't require notification-daemon.
[15:35] <nemo> hum. is notify-osd unity only?
[15:35] <mpt> No, it predates Unity.
[15:36] <mpt> It looks like bug 926583 is waiting for the Apport retracer to retrace the crash report and then make it public
[15:36] <nemo> ah
[15:36] <nemo> mpt: well. has been happening a lot. and without notification-daemon running, I get no notifications
[15:36] <nemo> well. I don't get them with it running either
[15:37] <nemo> but I do get a crasher then, if I run gdb ... notification-daemon   and then try notify-send
[15:37] <mpt> nemo, if you want help with access to that bug report, try a member of this team: <https://launchpad.net/~ubuntu-crashes-universe>
[15:37] <nemo> oh. I'd just like it to be unlocked, really
[15:37] <nemo> since it has been happening on 3 different computers
[15:38] <mpt> That must be frustrating
[15:38] <rbelem> infinity, not yet. I will have the packages ready by the weekend
[15:38] <nemo> I figure from the huge number of hits on launchpad, that it must not be a coincidence
[15:40] <nemo> ah. notify-osd is installed, but not running
[15:40] <nemo> if I launch it from commandline, I get the notification
[15:41] <nemo> hm. I guess the fix is to uninstall notification-daemon, since it can't run at the same time anyway.
[15:41] <nemo> just the sort of thing I would say in the bug if it wasn't locked :-p
[15:42] <mpt> Maybe those packages should conflict with each other, since they try to do the same thing
[15:42] <nemo> yeep. removing notification-daemon prompts for removal of gnome and gnome-core :(
[15:42] <nemo> oh geez.
[15:42] <mpt> oh, maybe that's why they don't :-)
[15:42] <nemo> ugh. I can hack around this locally, but a clean solution would be nice
[15:42] <nemo> mpt: well. then we have one that gnome depends on, that crashes :-p
[15:42] <nemo> and one that it doesn't depend on, that works, but isn't launched
[15:42] <nemo> hey. more stuff to put in the bug once it is unlocked :-p
[15:43] <nemo> one odd thing is I've been sending crash reports every time I get prompted. a few a day
[15:43] <nemo> Does ubuntu not have the equivalent of Mozilla's "top crashers" ?
[15:43] <mpt> Aha. https://bugs.launchpad.net/notify-osd/+bug/357273/comments/5
[15:43] <mpt> That's why they don't conflict
[15:43] <nemo> you'd think if others are experiencing the same thing, that folks would notice eventually
[15:43] <mpt> nemo, we do indeed: https://errors.ubuntu.com/
[15:45] <nemo> huh. that's odd
[15:45] <mpt> Ubuntu has used a replacement for notification-daemon by default for three years now, so it's understandable that even a reproducible crash in it won't be showing up.
[15:46] <nemo> heh. why on earth does gnome depend on it then, if it isn't even supposed to be used
[15:46] <nemo> people do occasionally install other desktops ;)
[15:46] <xnox> nemo: gnome != ubuntu-desktop
[15:46] <mpt> I thought gnome-shell used its own embedded notification code now
[15:47] <nemo> welp. I see that it is indeed in the top crashers for the month
[15:47] <nemo> 157 for notification-daemon
[15:47] <nemo> and linked to the inaccessible https://launchpad.net/bugs/926583
[15:47] <nemo> ok. not *high* in the topcrashers
[15:47] <nemo> but still!
[15:48] <nemo> if I launch notification-daemon w/ notify-osd running then it exist immediately. so isn't even clear why I'd have it
[15:48] <nemo> apart from wanting gnome3 (and more importantly, MATE)
[15:48] <mpt> aha
[15:48] <nemo> hm. XFCE4 doesn't depend on it
[15:48] <nemo> mpt: MATE doesn't depend on it though, oddly
[15:48] <nemo> just gnome
[15:49] <nemo> well. I've only been keeping gnome around for testing, since it was crashing on this ATI card in the past
[15:49] <nemo> I guess I could just uninstall it.
[15:49] <nemo> Not sure what I'll do on the other machines though
[15:49] <mpt> MATE + notify-osd ~= Ubuntu 9.04 to 10.10
[15:50] <nemo> hrm. Depending on the syntax, that's either an attempt to do a pattern operation, specify inequality, or specify approximate equality :)
[15:51] <nemo> anyway. whatever. was just trying to find a clean fix.  I guess I'll just make sure notify-osd is started in startup apps or somesuch.  Not sure what is firing off notification-daemon though
[15:51] <nemo> as long as you guys are keeping the package around, it would be certainly nice if you picked up the fix :-p
[15:52] <nemo> heck. it even has the pretty little ubuntu symbol. so that means maintained core right?
[15:52] <nemo> and right now it doesn't really work at *all*
[15:57] <hallyn> SpamapS: cgroup lite is 1.1 in precise, 1.2 in q (we're upstream).  I'm calling the SRU to precise 1.1.12.04.1.  debuild seems happy with it.  lemme know if that's not quite right
[15:57] <hallyn> (it's my best guess per https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation)
[15:57] <cjwatson> I'd be inclined to just use 1.1.1 in such cases
[15:57] <hallyn> cjwatson: my fear is, it also exists in o
[15:58] <hallyn> oh wait,
[15:58] <hallyn> it has different versioning there.  so 1.1.1 is fine.  thanks
[15:58] <cjwatson> It's 0.37.1-1ubuntu7.11.10.1 in oneiric
[15:58] <cjwatson> (well, oneiric-proposed)
[15:59] <hallyn> cjwatson: yup.  i'll go with 1.1.1.  thanks.
[16:00] <mpt> nemo, notification-daemon is in Universe. <https://help.ubuntu.com/community/Repositories/Ubuntu>
[16:00] <nemo> huh. I thought the ubuntu logo meant core
[16:00] <nemo> or ubuntu maintained or something
[16:00] <seb128> ev, mpt: what's the "frequency" unit on errors.ubuntu.com? reports/day?
[16:01] <nemo> seb128: I assume it is reports over the time period selected
[16:01] <mpt> seb128, "in the past day" by default. It's not averaged at the moment
[16:01] <nemo> so notification-daemon got 157 reports to the secret bug over the last month
[16:01] <seb128> mpt, "by default", so it's just "number of report in the selected time period"?
[16:02] <mpt> seb128, yes
[16:02] <seb128> mpt, ok, thanks
[16:02] <seb128> nemo, yeah, seems some people are still running notification-daemon for whatever reason
[16:02] <seb128> nemo, what do you call "secret bug"?
[16:02] <nemo> seb128: well. apparently because gnome requires it
[16:03] <nemo> 11:47 < nemo> and linked to the inaccessible https://launchpad.net/bugs/926583
[16:03] <seb128> nemo, gnome-shell has its own notification service
[16:03] <nemo> seb128: if I mark notification-daemon for complete removal, synaptic package manager marks gnome and gnome-core
[16:03] <seb128> nemo, right, those are useless dummy packages coming from Debian
[16:03] <seb128> nemo, you can remove them
[16:03] <nemo> ah
[16:04]  * nemo did not know that
[16:04] <nemo> one more thing to put in the secret bug :)
[16:04] <seb128> nemo, they are dummy packages which depends on everything which is "GNOME"
[16:04] <seb128> nemo, that bug is not secret, it's just that segfault can have private infos in their dump and access is limited to bugsquad by default
[16:04] <nemo> so. I guess this happens to people who have been upgrading for a long time
[16:05] <nemo> seb128: sure. I figured. but amounts to same thing. and it has gotten duped a lot :-p
[16:05] <nemo> oh well. uninstalled notification-daemon. doing same on other machines that I can access over ssh. thanks
[16:05] <seb128> nemo, nobody is maintaining notification-daemon anyway
[16:05] <seb128> nemo, yw
[16:05] <nemo> seb128: well. it says ubuntu developers maintain it, and has the nice logo :)
[16:05] <seb128> we should probably fix that
[16:06] <nemo> I'll have to check on my mom's machine when it comes back online - it was also installed a long time ago
[16:06] <seb128> we recommend notify-osd for years
[16:06] <nemo> I'm guessing any of my machines that are old may have this issue.
[16:06] <nemo> which would be... hm. all of them :)
[16:06] <seb128> nemo, what's the issue? what session do you use?
[16:07] <nemo> seb128: periodic crash notifications
[16:07] <nemo> seb128: I'm guessing because notification-daemon is crashing due to the bugs I linked to prior (see debian and gnome ones in gtk3)
[16:08] <nemo> seb128: and I guess notification-daemon is running 'cause this is an old setup
[16:08] <nemo> I just checked w/ the MATE guys, MATE just uses dbus, so, should be able to use notify-osd just fine once I clean things up
[16:09] <seb128> nemo, great
[16:09] <nemo> My mom's on MATE as well after months of hate against the new tablet interfaces, so similar config. My SO alternates between Unity and MATE but currently is using MATE due to Unity brokenness with virtualbox
[16:09] <nemo> also her graphics card is a bit wimpy
[16:09] <nemo> and unfortunately unity2d is kind of broken with multiple desktops
[16:09] <nemo> really a pain to move apps around
[16:09] <nemo> also resizing windows in it
[16:10] <nemo> she did spend a couple of months doggedly learning the interface
[16:10] <nemo> major props to her
[16:10] <nemo> virtualbox was the final straw
[16:11] <seb128> nemo, your bug seems to be bug #926758 btw
[16:12] <seb128> nemo, there is a fix upstream for gtk: http://git.gnome.org/browse/gtk+/commit/?h=gtk-3-4&id=e694bd75f601d4796119b622ba2f2cd13ca86ddd
[16:12] <nemo> um
[16:12] <nemo> nooo
[16:12] <seb128> nemo, we will include it for precise in the next gtk SRU
[16:12] <nemo> not that one :)
[16:12] <pitti> cjwatson: autopkgtest fix uploaded
[16:12] <nemo> seb128: it is the bug I linked to :-p
[16:12] <nemo> the one that gets 157 hits
[16:12] <seb128> nemo, they are the same bug?
[16:12] <nemo> seb128: I'd have to reinstall it to grab another stack trace though
[16:12] <cjwatson> pitti: thanks
[16:12] <nemo> oh? huh. the place it crashes seems different
[16:12] <seb128> "gdk_pixbuf_scale_simple", expression=0xb703839e "dest_width > 0
[16:12] <nemo> ah. yep. that's the one
[16:13] <seb128> nemo, that's the one I pointed
[16:13] <nemo> and yeah. I saw the fix committed in the gnome bug
[16:13] <pitti> cjwatson: now I go rest my bleeding eyes from the autopkgtest source code :)
[16:13] <pitti> good night everyone!
[16:13] <seb128> nemo, we will get the gtk fix SRUed
[16:13] <seb128> nemo, thanks for pointing it
[16:13] <seb128> pitti, 'night
[16:13] <nemo> well. I don't need it anymore :)
[16:13] <nemo> but good to know. maybe I can skip on nagging family members
[16:13] <nemo> and/or sshing into their machines
[16:15] <nemo> seb128: FWIW the debian report has a second git ID as well (last comment)
[16:15] <nemo> the one from a month ago
[16:15] <seb128> nemo, thanks
[16:17] <nemo> BTW, only kind of ubuntu devel related, but I really liked this comment on linux video
[16:17] <nemo> http://linux.slashdot.org/comments.pl?sid=2927755&cid=40387313
[16:18] <nemo> guess I'm going ATI next time, esp after their recent announcement.
[16:45] <nemo> seb128: hey. just curious. because you guys forgot to drop notification-daemon - does that mean you have to maintain it for the entire LTS? :)
[16:53] <smoser> mdeslaur, you touched clamav last, does https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1015828 make any sense to you?
[16:54] <mdeslaur> smoser: http://www.ubuntu.com/usn/usn-1482-2/
[16:54] <mdeslaur> smoser: dupe of bug 1015337
[16:54] <smoser> mdeslaur, well, look at the bug.
[16:54]  * smoser reads that link more closely
[16:55] <mdeslaur> smoser: he probably needs to uninstall clamav and reinstall it
[16:55] <smoser> probably, yes, but how did he get there?
[16:55] <mdeslaur> the .1 release failed to install in the postinst
[16:55] <smoser> ah. ok.
[16:56] <mdeslaur> smoser: It's possible the .2 doesn't install over .1 cleanly depending on ordering...not all combinations were tested
[16:59] <tremolux> hrw: hi! I was just asking in #ubuntu-desktop about a weird graphics corruption issue that we've gotten two reports of for Ubuntu Software Center, bug 1015216
[17:00] <tremolux> hrw: and Laney mentioned that you had reported seeing this: http://marcin.juszkiewicz.com.pl/~hrw/shots/bad-fonts.jpg
[17:00] <tremolux> hrw: I just wondered if you've noticed anything similar in Software Center, that is, corruption of the toolbar icons when mousing over them
[17:00] <seb128> hrw, what video card do you use?
[17:57] <hrw> seb128: radeon 5430 with open driver
[17:57] <hrw> tremolux: never used software center
[17:57] <ogra_> how can you !
[17:57] <ogra_> :)
[17:58] <seb128> hrw, thanks, seems like it could be an ati issue
[17:58] <seb128> hrw, do you still get the corruption issue? do you get it easily?
[17:58] <hrw> ogra_: using U(unity)buntu on private machine is not a requirement but only suggestion ;)
[17:59] <hrw> seb128: open gvim with lot of text (:help is enough), scroll and watch for crazy lines
[17:59] <hrw> seb128: root logged into xterm+kwin+gvim did not had problem
[18:00] <Laney> hrw: Sarvatt said it might be a driver problem with the current drivers, and that the ones from debian should/might fix it
[18:01] <Laney> if you can reproduce it easily (I can't) then maybe its worth giving that a go
[18:01]  * ogra_ thinks its just because hrw never used software center .... its the wrath of mvo !
[18:02] <mterry> kenvandine, hey buddy!
[18:02] <hrw> Laney: ok
[18:02] <mterry> kenvandine, do you have spare review cycles?  I've got a load of update-manager branches that mvo is likely too busy to get to soon, if you can
[18:02] <tremolux> hrw: ok, no probs, thanks  :)
[18:03] <hrw> Laney: sarvatt's ppa with xorg-edgers would be fine too?
[18:03] <Laney> dunno, I just rebuilt x-x-v-ati from sid :-)
[18:04] <Laney> can give you the debs if you are on amd64
[18:04] <hrw> Laney: I am
[18:06] <hrw> Laney: anyway they are building now
[18:06] <Laney> hrw: http://people.canonical.com/~laney/xserver-xorg-video-ati/
[18:06] <hrw> thx
[18:06] <Laney> np
[18:08] <kenvandine> mterry, i'll do my best :)
[18:10] <mterry> kenvandine, you're the best!  I think if you start at https://code.launchpad.net/~mterry/update-manager/avail-cleanups/+merge/110914 and follow the chain of pre-req merges, you'll end up at the first one, which should be 'update-at-start'
[18:11] <mterry> kenvandine, any bits that you can get to are welcome!  I just didn't want to block on mvo if possible
[18:11] <hrw> Laney: looks like it was that
[18:11] <Laney> nice
[18:15] <hrw> good
[18:15]  * hrw -> off
[18:23] <kees> infinity: say, slangasek says you're busy. if you don't have anything staged for eglibc, can I upload my changes?
[18:26] <infinity> kees: Oh, I had planned to actually review that and such, but yeah, I seem to have let it slide.
[18:26] <infinity> kees: If it's wildly urgent to you, and you're sure it won't break anything, go ahead.
[18:28] <kees> infinity: yeah, the results pass my glibc regression test suite (fwiw). it's blocking some changes to the security tests suite, so that's why I've been pestering you. :)
[18:29] <kees> infinity: it's get it done. :)
[18:29] <kees> er, I'll get it done.
[19:17] <SpamapS> @pilot in
[19:17] <SpamapS> a day early, but looks like I may be too busy tomorrow
[19:22] <seb128> SpamapS, hey
[19:23] <seb128> SpamapS, do you know if the SRU team rotation schedule got written somewhere?
[19:23] <SpamapS> seb128: somebody had a TODO to put it .. somewhere
[19:24] <seb128> SpamapS, somebody ... somewhere ... sometime ... I see ;-)
[19:25] <SpamapS> seb128: I'd take responsibility, but that would be unfair to my other responsibilities. ;)
[19:25] <seb128> hehe
[19:26] <seb128> SpamapS, no worry, I just want to stop pinging the whole SRU team daily and try to get some reviews of whoever is on duty ;-)
[19:26] <seb128> slangasek, ^ do you know who has the rotation schedule?
[19:29] <SpamapS> seb128: there shouldn't be a need for pings.. we process the queue from oldest -> newest daily... unless there's some urgent regression which needs a queue jump.
[19:29]  * SpamapS hopes we do not have daily urgent regressions :)
[19:30] <seb128> SpamapS, libreoffice is stucked for over 3 weeks and I raised it to the TB and release team lists
[19:30] <seb128> SpamapS, but I guess nobody wants to be the one letting a libreoffice SRU in
[19:30] <seb128> SpamapS, still it's a real issue, we have data lose bugs in the LTS for over a months where fixes are available
[19:31] <SpamapS> What was the final decision on that?
[19:31] <jdstrand> seb128: is that the libreoffice on oneiric?
[19:31] <seb128> jdstrand, no, it's 3.5.4 for precise
[19:31] <SpamapS> I lost track of the thread.
[19:31] <seb128> SpamapS, the TB says the SRU team can ack those
[19:31] <seb128> SpamapS, slangasek said anyone in the SRU team can do it and that he will have a look on friday if nobody does this week, we are getting there...
[19:32] <seb128> jdstrand, there is no security fix in this one so it's not a security team concern (yet) ;-)
[19:32] <jdstrand> seb128: ok, the 11.10 Sweetshark told me could be dropped
[19:32] <jdstrand> s/11.10/11.10 one/
[19:32] <seb128> jdstrand, 3.5.5 might be in a different category and that's one of the reasons I would like 3.5.4 moving before that happens
[19:32] <slangasek> seb128: the rotation schedule is in a google doc; we'll get that published ASAP; and today is bdmurray's day
[19:32] <SpamapS> So we didn't actually try for an MRE yet? I really want to understand upstream's process before I just blindly accept it. :-P
[19:32] <jdstrand> seb128: /me nods
[19:33] <jdstrand> I'm fine with having the most up-to-date version in -updates, believe me :)
[19:33] <jdstrand> (for precise)
[19:33] <seb128> SpamapS, oh, MRE was asked 3 weeks ago and acked by some TB members, it's purely on the SRU team side
[19:33] <SpamapS> I saw a bunch of requests for more info.. didn't see the actual +1
[19:33] <seb128> SpamapS, but MRE doesn't mean we should avoid a SRU team sanity check
[19:33] <SpamapS> and then angry "if I have to do this I quit" type messages
[19:34] <jdstrand> (the oneiric one had a regression and is abandoned, and is going to need to be respun anyway very soon anyway)
[19:34] <jdstrand> s/ anyway)/)/
[19:34] <seb128> jdstrand, yeah, I followed that one, I though the old version was going to be uploaded with new.is.really.old changelog trick
[19:34] <SpamapS> https://lists.ubuntu.com/archives/technical-board/2012-June/001309.html
[19:34] <SpamapS> well here's the tech board +1
[19:35] <seb128> SpamapS, right
[19:35] <jdstrand> seb128: I wasn't going to do that since the one in -proposed can just be rejected
[19:35] <SpamapS> so yeah, it just needs the sanity check on versions and stuff
[19:35]  * SpamapS takes a look
[19:35] <seb128> jdstrand, well it means the security issue is still not addressed
[19:35] <seb128> jdstrand, but if that's fine for you guys I will not say anything ;-)
[19:35] <seb128> SpamapS, thanks
[19:35] <jdstrand> seb128: it is addressed, except for someone running -proposed and installing it
[19:35] <SpamapS> bdmurray: are you already looking at it?
[19:36] <seb128> SpamapS, my other concerns is that we have trivial items still taking over a week to be reviewed and it's the velocity we would like to see
[19:36] <infinity> barry: What was the point of uploading libpeas twice in a row? :)
[19:36] <SpamapS> I didn't do much SRU stuff yesterday, so I'm happy to grab it now
[19:36] <jdstrand> but our policy is not to try to be tricky with --proposed. we base of -updates and -security
[19:36] <seb128> jdstrand, oh ok, that was not my understanding
[19:36] <SpamapS> seb128: we'll need more people on the team if you want that improved.
[19:37] <seb128> jdstrand, my understand was that oneiric (release) had the issue but the easy fix can't be uploaded because the version would be < proposed
[19:37] <SpamapS> its been better the last 2 weeks
[19:37] <jdstrand> seb128: yeah-- once it hits -updates, we use it. if there is something in -proposed at the time we provide the -security update, we mention that the package in -proposed needs to be respun to incorporate the -security fixes
[19:37] <jdstrand> (in the bug)
[19:38] <jdstrand> (in the SRU bug that is)
[19:38] <seb128> jdstrand, does it mean you plan to get a 1:3.4.4-0ubuntu1.1 out with the security fix?
[19:38] <jdstrand> otherwise all our versions go haywire
[19:38] <seb128> jdstrand, I'm a bit lost
[19:38] <SpamapS> seb128: any reason quantal has not seen 3.5.4 yet?
[19:38] <seb128> jdstrand, that security issue is resolved in neither oneiric, oneiric-updates, nor oneiric-security as I understand it
[19:39] <jdstrand> seb128: yes. 1:3.4.4-0ubuntu1.2 will be going to -security (1.2 cause I had to respin 1.1 in the security ppa)
[19:39] <seb128> SpamapS, we target 3.6.0~beta1 directly to quantal and it's still not building thanks due to the new toolchain (taking a bit to resolve the toolchain issues)
[19:39] <SpamapS> seb128: roger that, I'll waive that req too then
[19:39] <seb128> jdstrand, oh ok, so you still plan a security update, just note  a weirdly versioned one to deal with proposed issues
[19:39] <seb128> SpamapS, thanks ;-)
[19:40] <seb128> jdstrand, I though you were saying you didn't do any update for oneiric
[19:40] <jdstrand> seb128: sorry for the confusion. I am providing the updates for oneiric based off of 3.4.4.
[19:40] <seb128> didn't->wouldn't
[19:40] <seb128> jdstrand, cool
[19:40] <seb128> jdstrand, thanks ;-)
[19:40] <jdstrand> seb128: right, I was just saying I wasn't going to use a weird version number for my update :)
[19:44] <SpamapS> seb128: accepted
[19:44] <seb128> SpamapS, thanks!
[19:46] <barry> infinity: stupidity on my part?
[19:46] <jdstrand> SpamapS: how does one remove a package from -proposed?
[19:47] <infinity> barry: Check.  Was just a curiosity. :P
[19:47] <jdstrand> neither StableReleaseUpdates#Removal_of_updates or ArchiveAdministration is helping me
[19:47] <barry> ;)
[19:47] <jdstrand> oh, I can just reject it
[19:47] <jdstrand> duh
[19:47] <jdstrand> SpamapS: nm
[19:48] <SpamapS> jdstrand: if its in queue, yeah, just reject. Otherwise I believe it is 'remove-package' but I've actually never done it
[19:48] <infinity> jdstrand: If you can reject it, it's not in proposed.
[19:48] <jdstrand> remove-package does way more than I want :)
[19:48] <infinity> jdstrand: And if it *is* in proposed, remove-package -m "This SRU sucked" -s foo-proposed -S source
[19:49] <jdstrand> infinity: ah, ok, then it doesn't do too much
[19:49] <jdstrand> infinity: can I quote you on the "This SRU sucked" bit?
[19:49] <infinity> Sure. :)
[19:49] <infinity> Not that I have context.
[19:49] <jdstrand> :)
[19:51] <jdstrand> infinity: hmm, why '-S' ("remove source only"). Note, that -S in remove-package is different than -S in change-override
[19:52] <jdstrand> I want it without -S
[19:58] <jdstrand> not sure why that was so hard for me to figure out... *shrug* it's done now
[19:59] <infinity> jdstrand: Oh indeed, I didn't read the help.
[19:59] <infinity> jdstrand: Though running it would have made that vaguely obvious. ;)
[19:59] <stgraber> is it just my amrhf build that's weirdly broken or python3 is broken on quantal armhf (at least)?
[20:00] <jdstrand> infinity: still, you were a great help (I updated the wiki btw)
[20:00] <infinity> stgraber: Context?
[20:00] <infinity> stgraber: What's breaking/broken?
[20:00] <stgraber> infinity: starting python3 (not script or anything) fails and gives me "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb2 in position 23: invalid start byte"
[20:01] <infinity> stgraber: That seems like the sort of thing that would cause a ton of build failures and we'd surely notice...
[20:01] <infinity> stgraber: Oh, except that buildds run in LANG=C
[20:01] <slangasek> except that the buildds don't run python interactively
[20:01]  * infinity checks here.
[20:02] <stgraber> infinity: http://paste.ubuntu.com/1053198/
[20:03] <stgraber> FWIW that image was missing langpacks initially but I fixed that a while ago including a reboot, copy/pasting chinese stuff seems to confirm utf8 is working as expected :)
[20:03] <stgraber> (and I still wouldn't expect python to blow up that badly even if I was lacking a utf8 locale)
[20:04] <infinity> stgraber: No can reproduce here, either in C or en_CA.UTF-8
[20:05] <infinity> stgraber: This is in a clean chroot where I just installed python3, FWIW.
[20:05] <infinity> stgraber: So, you may have Something Else(tm) blowing up your world.
[20:05] <infinity> stgraber: And I'd bet it's not ARM-specific, but who knows...
[20:05] <stgraber> installing debsums now to check what's broken on there :)
[20:06] <stgraber> it's a clean .img I dded on an sdcard and booted on a panda, so nothing fancy, well except for the fact it's the first time we build Edubuntu for armhf
[20:07] <infinity> Oh, except in this clean chroot, I don't actually HAVE any UTF-8 locales, so python's probably silently ignoring it.
[20:07] <infinity> Let me localegen some.
[20:08] <gr8linux> I need help with webkit and quickly
[20:08] <infinity> stgraber: Yeah, even with some langpacks installed, can't reproduce either with C or a UTF-8 locale.
[20:10] <stgraber> infinity: ok, will see if debsums finds anything weird here, I'd be happy to blame the sdcard ;)
[20:10] <stgraber> but dmesg doesn't seem to confirm it's just a bad media
[20:10] <infinity> stgraber: I like to blame SD cards for most of my problems.
[20:10] <gr8linux> It seems that there is a problem with import webkit and quickly
[20:10] <infinity> stgraber: In this case, though, I suspect it's an actual software bug, since bad media tends to be a bit louder.
[20:11] <infinity> stgraber: Just a bug that's a bit more subtle than "install python3 and watch it suck".
[20:16] <gr8linux> I need help with webkit and quickly
[20:16] <micahg> SpamapS: seb128: IMHO, it seems that sabdfl's +1 of the libreoffice MRE was premature given the poor track record before, but I think there was at least a consensus that 3.5.4 should be given a shot
[20:16] <infinity> gr8linux: You probably want #ubuntu-app-devel (see the topic)
[20:17] <SpamapS> micahg: Yes, I think not doing it is a greater risk than doing it.
[20:17] <gr8linux> infinity:tanx
[20:17] <seb128> micahg, I asked slangasek about it and he said there was enough "pro" on the TB discussion for the SRU team to pick it up and review it
[20:18] <micahg> seb128: yep :), I just saw SpamapS quoting the +1 and wanted to comment on that, that's all, everything seems like it's on the right track now though
[20:21] <seb128> right
[20:21] <stgraber> infinity: debsums didn't spot anything off on that system, so it's clearly something that's installed (or missing) that's messing with python3...
[20:22] <infinity> stgraber: Installed seems more likely than missing.  My chroot wasn't particularly polluted.
[20:22] <infinity> stgraber: Had a bit of junk in it from a previous build, but...
[20:35] <stgraber> infinity: rm /usr/lib/python3.2/__pycache__/traceback.cpython-32.pyc => fixed
[20:36] <infinity> stgraber: So, it got miscompiled?
[20:37] <infinity> stgraber: That's a tiny bit disconcerting.
[20:37] <stgraber> infinity: looks that way...
[20:37] <stgraber> barry: ^
[20:38] <barry> sorry, what's the issue?
[20:38] <stgraber> barry: http://paste.ubuntu.com/1053198/
[20:38] <stgraber> barry: that's what I got on a clean daily-preinstalled image on armhf
[20:38] <barry> stgraber: wtf?
[20:39] <barry>  ;)
[20:39] <stgraber> barry: after digging for a while I tracked it down to the .pyc for traceback being broken. Removing it to force it to re-generate fixed it
[20:39] <barry> stgraber: even with a corrupt .pyc, the crash looks *very* odd
[20:39] <barry> but okay :)
[20:39] <infinity> Do we generate those at install time, or runtime these days?
[20:39] <stgraber> barry: I'm making 100% sure that this .img contains the broken .pyc, if it does, you'll be able to download it and look :)
[20:40] <slangasek> infinity: install time
[20:40] <infinity> Kay, so the image SHOULD contain the broken one.
[20:40] <slangasek> infinity: (at runtime you don't get to write to /usr)
[20:40] <barry> pycs should never appear in the package, always at install time, even for the interpreter itself
[20:40] <infinity> But how it got broken, I dunno.
[20:40] <infinity> slangasek: Oh, err, right.  /usr.. Wasn't really thinking while I typed. :P
[20:42] <barry> do you have a copy of the .pyc file?  i could inspect it (it's essentially just a marshaled code object with some magic header bytes)
[20:42] <barry> that may not actually help in any useful way though
[20:44] <infinity> barry: Well, it would perhaps help to determine if it was either corrupt or miscompiled.
[20:45] <barry> infinity: any chance you can drop the bogus .pyc some place i can grab it from?
[20:45] <infinity> barry: I think stgraber's working on doing just that.
[20:46] <barry> cool
[20:46] <infinity> barry: Once he confirms that the one in the image is actually broken.
[20:46] <infinity> barry: (If it's not, I assume the one he rm'd was just corrupted on his SD)
[20:46] <stgraber> barry: I sadly removed it... writting a new sdcard to reproduce, for some reason reproducing with qemu-arm-static failed here, so I want to reproduce with the exact same setup
[20:46] <barry> stgraber: no worries.  ping me if/when you have something
[20:47] <infinity> stgraber: If could just have been a bitflip on your SD card.  Since debsums doesn't know about .pycs, you wouldn't have known.
[20:47] <jtaylor> SpamapS: re fftw3, which cflags?
[20:47] <slangasek> barry: when you say you get to the grub screen half the time... is it *about* half the time, or is it *exactly* half the time? ;D
[20:48] <slangasek> barry: because y'know, grub has handling for doing things differently the second time after a failed boot
[20:48] <barry> slangasek: interesting.  i think "about" but i'll gather more data points
[20:48] <slangasek> ok
[20:51] <stgraber> infinity: yeah, should be able to confirm that shortly... that'd confirm the whole always blame the sdcard rule ;)
[20:52] <stgraber> I guess I could check the md5sum of the partition post-zcat to detect that (but don't quite like the idea of having to wait 15min ...)
[21:05] <bryceh> @pilot in
[22:07] <SpamapS> jtaylor: sorry I went to lunch. ;) http://paste.ubuntu.com/1053382/
[22:07] <SpamapS> jtaylor: there are numerous changes to cflags in there
[22:07] <jtaylor> numerous = 1?
[22:08] <SpamapS> I count all the changes on those 3 lines as numerous :)
[22:08] <SpamapS> either way, its not clear from the changelog entry why
[22:09] <SpamapS> 2 lines rather, sorry. ;)
[22:09] <jtaylor> just to shut up debians built log checks
[22:09] <SpamapS> jtaylor: actually, the archconfflags is for mpi isn't it?
[22:09] <jtaylor> I added docs
[22:09] <jtaylor> yes
[22:09] <SpamapS> jtaylor: I was moving a bit fast, didn't notice that :-P
[22:10] <SpamapS> jtaylor: so I still don't understand why CFLAGS was changed
[22:10] <SpamapS> or rather, added
[22:11] <SpamapS> jtaylor: the rest looks great btw
[22:11] <jtaylor> in what way changed?
[22:11] <jtaylor> its only added to a gcc call that compiles a 5 lines test
[22:12] <jtaylor> it can be dropped in ubuntu if you like
[22:13] <SpamapS> Its not really about what I like. I'm just pointing out that I don't know why its there.
[22:14] <SpamapS> jtaylor: we tend to document all of the delta we have, as merges can get confusing every 6 months.
[22:14] <SpamapS> forgive me if it seems I'm being pedantic!
[22:22] <jtaylor> its fine, I was just lazy
[22:22] <jtaylor> also documented in debian now
[22:36] <infinity> tumbleweed: Hey, pypy only took 1 day and 19 hours on armel, that's not so bad. :P
[22:36] <infinity> tumbleweed: (Jury's still out on armhf...)
[22:37] <infinity> Riddell: Did ktp-contact-applet get superseded by ktp-contact-runner?  The former is the only thing that didn't get updated in the ktp-4.0 napalm upload.
[22:38] <infinity> Riddell: (And thanks to either your guidance or George's foresight for that being a self-managing library transition with sane dep-waits, so I didn't have to fix it after the fact)
[22:42] <barry> stupid question i should know the answer to: given debian/changelog, is there a cli for extracting the version number of the top entry?
[22:42] <micahg> barry: in what context?
[22:43] <barry> micahg: i'm sitting in the top directory for a native package (a udd source package if it matters, but it should work with `apt-get source).  in the setup.py script i want to extract the version number from the debian/changelog file
[22:44] <micahg> hrm, I haven't played with the python debian version library yet
[22:44] <barry> micahg: i could grep it of course, but just though there might be some dpkg-magic command that did it
[22:44] <micahg> well, there's dpkg-parsechangelog
[22:45] <barry> micahg: that could work, thanks /me reads the manpage
[22:53] <infinity> barry: dpkg-parsechangelog --format rfc822 | awk '/^Version:/ {print $2}'
[22:53] <infinity> barry: Can't think of anything less icky than that off the top of my head.
[22:53] <barry> infinity: perfect, thanks!
[22:55] <infinity> Of course, if you're sitting in python, you might want to use python's filthy string manipulations instead.
[22:55] <infinity> But awk's probably faster. ;)
[22:57] <StevenK> infinity: grep '^Version' | cut -d\  -f2 ? :-P
[22:58] <infinity> StevenK: I bet that's slower.
[22:58] <barry> this is a setup.py file.  speed is not the issue :)
[22:58] <StevenK> Haha
[22:58] <infinity> StevenK: Besides, the beautiful inreadability of awk always wins.
[22:58] <StevenK> infinity: Hang on, sed can do this itself, can't it?
[22:59] <infinity> StevenK: (Though, in this case, cut's far worse to visually parse)
[23:00] <StevenK> I will usually reach for grep and cut before awk. If I start chaining tr to cut and then sort, it's probably time to use awk. Or Perl.
[23:00] <infinity> StevenK: I tend to only use cut if the -d is oddball.
[23:02] <infinity> StevenK: Plus, I find '-d" "' or '-d\ ' (pick your poison) so wildly unintuitive to parse visually after it's been written.
[23:04] <StevenK> infinity: That isn't really cut's fault, though.
[23:04] <infinity> StevenK: No, lots of unintuitive programming isn't the tool's fault, it's the programmer for doing unmaintainable things.
[23:04] <StevenK> Haha
[23:04] <SpamapS> @pilot out
[23:05] <StevenK> infinity: To be fair, I use cut for one liners, nothing that is going to be around for more than 30 seconds.
[23:09] <mwhudson> StevenK: always a risky attitude that :)
[23:10] <mwhudson> i wrote some nasty sql once and now it's the trigger that keeps Branch.unique_name up to date in lp :)
[23:15] <StevenK> mwhudson: You're right, that is pretty horrible.
[23:17] <micahg> bryceh: please try to remember -v :)
[23:17] <bryceh> @pilot out
[23:18] <bryceh> micahg, for...?
[23:18] <micahg> uploads
[23:19] <RAOF> Of merges, presumably?
[23:19] <micahg> yes
[23:20] <bryceh> well too late now :-)
[23:20]  * ajmitch does like --package-merge with bzr-builddeb, even if the resulting branch isn't pushed 
[23:21] <micahg> bryceh: I ignored the first one, figured it was a goof :)
[23:23] <infinity> micahg: I forget all the time.  Maybe we could put a check in the same dpkg-dev policy checker that bitches about "this looks like it has ubuntu modifications, but you didn't change the maintainer, you naughty naughty developer".
[23:23] <bryceh> nah, I sponsor merges quite infrequently, I never remember all the myriad switches
[23:23] <bryceh> -uc -us -S -sa -i -v
[23:28] <RAOF> It shouldn't be too hard to automate ‘this looks like a merge’, right?
[23:28] <RAOF> (Note, NOT volunteering! ☺)
[23:28] <bryceh> well, in fact they're called out as merges in the pilot list, so we already can differentiate between the two
[23:29] <bryceh> and yeah, for the most part 80% of the steps are mechanical
[23:29] <micahg> there is sponsor-patch
[23:31] <bryceh> micahg, more switches to memorize!  ;-0
[23:31] <micahg> -v is listed as #2 to check
[23:33] <Valtam> hi folks
[23:34] <micahg> ajmitch: BTW, --package-merge still needs a sanity check :)
[23:39] <ajmitch> micahg: of course, everything needs a sanity check
[23:39]  * ajmitch now hopes that he got recent uploads right :)