[00:01] <bryceh> stgraber, still about?
[00:02] <bryceh> I've got 7 branches from the sponsor queue that need set to Work In Progress.
[00:02] <bryceh> anyone able and willing to poke at merge proposal status buttons for me?
[00:07] <mdeslaur> infinity: texlive-base in uninstallable right now...you were doing the tex stuff, right?
[00:10] <slangasek> bryceh: I thought WIP was a status anyone with uploader rights could set?
[00:11] <bryceh> slangasek, yeah I don't know.  Some branches I can set it but most I can't.
[00:11] <slangasek> weird
[00:12] <bryceh> I seem to recall there was a bug filed against LP about it, but doubt it's going to get attention any time soon
[00:12] <infinity> mdeslaur: Seriously, who/what broke it this time? :/
[00:13] <mdeslaur> infinity: looks like texlive-base got bumped and now needs a newer texlive-bin
[00:13] <bryceh> 1000557, 1000558, 1000560, 1000561 were some textlive-* syncs that came through today
[00:13] <infinity> bryceh: Oh dear.  Those are wildly sensitive to ordering, it seems.
[00:14] <mdeslaur> infinity: so I now have an additional reason why lintian FTBFS :P
[00:14] <infinity> bryceh: And can't happen without also merging texlive-bin.
[00:14]  * infinity will do that now, and hopes this doesn't need another bootstrap.
[00:18] <jbicha> infinity: you should be able to sync texlive-bin, right?
[00:18] <jbicha> as in, I don't think we need to maintain a diff any more
[00:19] <infinity> jbicha: If I'm reading the changelog correctly, while he included our patch, he didn't enable it.
[00:20] <infinity> jbicha: Plus, there's the libpng transition (have we started that?)
[00:21] <jbicha> well the patch didn't work....
[00:21] <jbicha> I was told libpng-dev works fine on Ubuntu
[00:21] <infinity> Well, yes.  It should.
[00:21] <infinity> Cause our resolver's sane.
[00:21] <infinity> Or insane, depending on opinion.
[00:21] <infinity> Fair enough.
[00:21] <infinity> Also, lolwut:
[00:21] <infinity>    * move patches from debian/patches to debian/quilt, add quilt as
[00:21] <infinity>      build dep, and include quilt patching in debian/rules
[00:21] <infinity>      this gets us rid of the "strange" parts of the 3.0 format
[00:21] <infinity>      (see quilt vs dpkg-source fuzzyness acceptance).
[00:22] <jbicha> have you read the debian-devel discussion?
[00:22] <infinity> I'm pretty sure I don't want to.
[00:22] <infinity> Not if it resulted in the above.
[00:22] <mdeslaur> infinity: GAH! seriously??
[00:23] <jbicha> he doesn't like that dpkg fails on fuzzy patches, unlike quilt push
[00:23] <jbicha> quilt push; quilt refresh is too much work!
[00:23] <mdeslaur> wow, he wants to rely on fuzzy patches...awesome :)
[00:23]  * infinity shakes his head.
[00:25]  * infinity holds his nose and syncs.
[00:26] <infinity> mdeslaur: I dare you to publically call him out on why relying on fuzzy patches is a Really Bad Idea.
[00:26] <infinity> mdeslaur: But wear a false moustache, so no one knows you're from Ubuntu and/or Canonical.  Thanks.
[00:26] <infinity> mdeslaur: That should totally circumvent the CoC.
[00:27] <mdeslaur> infinity: uhm, yeah...I'll have to think about it...I get enough hate mail as it is :)
[00:27] <infinity> mdeslaur: Oh, I can stop sending those, if you need to free up some time.
[00:27] <mdeslaur> lol
[00:28] <bryceh> heh
[00:29] <slangasek> infinity: yeah, you don't want to read that thread
[00:31] <infinity> slangasek: You know I'm going to now.
[00:48] <psusi> wait, what the crap... he intentionally avoided the automatic quilt integration of 3.0 (quilt)?
[00:49] <mtx_init> Good evening.  I am making a custom install, english is the only language needed, How can I turn off the menu asking the user for language?  I found the langlist in the isolinux directory but that just limits my selection
[00:57] <infinity> psusi: Yeahp.  Which, to be fair, is commonly done for other reasons (like, when it violently disagrees with your VCS workflow), but his entire argument was that he *likes* quilt, but only if it allows fuzzy patches, which bare quilt does, dpkg-source doesn't.
[00:58] <psusi> so basically he doesn't want to have to run quilt refresh?
[00:59] <psusi> and isn't there something you can shove in debian/source/options to change that behavior?
[00:59] <infinity> psusi: No, he doesn't want to be "forced" to resolve fuzziness until he's good and ready to!
[00:59] <infinity> psusi: Read the thread.  Well, up until he stops responding.  It devolves into something unrelated after that.
[00:59] <lifeless> infinity: whats the subject ?
[01:00] <psusi> yea, but you resolve fuzzieness by just running quilt refresh
[01:00] <infinity> psusi: And then, if you're sane, checking that the refresh gave you the correct result, but yes.
[01:00] <infinity> lifeless: http://lists.debian.org/debian-devel/2012/05/msg00711.html
[01:01] <lifeless> oh
[01:01] <lifeless> I killfiled that on the subject alone
[01:01] <infinity> psusi: I mean, by definition, a fuzzy patch implies that it miiiiight not be applying correctly, so trusting quilt refresh blindly is as silly as trusting it to remain fuzzy.
[01:02] <infinity> psusi: But arguing that one should be allowed to upload their fuzzy patches and go check/unfuzz them "later, when I get around to it, how dare you force me, dpkg fascists" is a fun read.
[01:03] <lifeless> its almost as bad as using a vcs and doing merges.
[01:04] <infinity> I dunno.  I have little sympathy.  I used to maintain a package whose patch system was "for i in debian/patches/*; do patch -p1 < $i; done", and I used to review every patch and hand-edit for both fuzz and offsets on every upstream bump.
[01:05] <infinity> Made sure I definitely knew how and why they still applied, and let me scan to see if maybe they'd been duped a few lines up, etc.
[01:05] <infinity> I don't really grasp why this is "hard".
[01:11]  * RAOF pines for 3.0 (bzr)
[01:12] <infinity> RAOF: It's been pointed out that any of the 3.0 (vcs) formats present issues with license autiting, unless they're shallow clones/checkouts, which then loses most of the point.
[01:12] <infinity> auditing, too.
[01:12] <infinity> Typing hard.
[01:13] <RAOF> infinity: Yeah, I've read that.
[01:13] <RAOF> We're pretty much doing it anyway, though, just ad-hoc.
[01:14] <RAOF> I'm not sure if there's a huge difference between distributing as source-package on ftp.debian.org and distributing as, say, git branch on alioth. Perhaps there is.
[01:14] <infinity> I wouldn't be against doing it the way Nokia/maemo did with building from git tags.
[01:14] <infinity> RAOF: The difference is that alioth isn't mirrored.
[01:15] <infinity> RAOF: Nor is launchpad.
[01:16] <RAOF> So... we can potentially clean up a mess on Launchpad, but not on archive.ubuntu.com?  Is that it?  I guess there's another indirection of distribution, too, but that's surely not a problem for the vast majority of things.
[01:19] <infinity> Well, there's also the reality that branches-with-history as source packages would just bloat mirroring even more.  I do really like the "tag in a VCS, have a bot build a source package from the tag and upload it" way of doing things.
[01:19] <infinity> No other infrastructure needs to change, source mirrors still have source packages that are shallow checkouts, but the VCS becomes authoritative (which it currently isn't, no matter how much people pretend it is).
[01:20] <RAOF> That would also work, yes.
[01:21] <mdeslaur> we've been asked to be able to retrace tarballs to upstream releases with their signatures, to make sure they have not been trojaned during downloads and stuff
[01:22] <infinity> mdeslaur: pristine-tar solves that.
[01:23] <mdeslaur> infinity: ah, interesting
[01:23] <infinity> mdeslaur: And yes, I'm also in the "orig should be an exact copy of upstream's source, except when licenses prevent that" camp.
[01:23] <RAOF> Yeah, that's actually really useful.  You can just pull the package branch, and it'll reconstruct the tarball for you.
[01:24] <mdeslaur> I wonder how big the delta files it generates are, and if they're auditable
[01:25] <RAOF> It depends on the tarball; they're often sub-kibibyte.
[01:26] <RAOF> I'm not sure what you'd need for them to be auditable, though. The ability to see what they change from the VCS without applying them?
[01:26] <infinity> Yeah, auditing them isn't really required, since it's the result that matters.
[01:27] <infinity> checkout + pristine tar = orig + debiandiff + dsc = normal source package.
[01:27] <infinity> The tiny xdelta is opaque to people who don't speak fluent xdelta (which is, like, everyone), but it's the resulting tar that it creates that you care about, which is obviously identical to the upstream one, so you win.
[01:29] <mdeslaur> infinity: and are you building the package from the complete checkout, or just from the commits starting with the tarball's tag?
[01:31] <infinity> mdeslaur: See pristine-tar commit and pristine-tar checkout.  You generally point it at a tag that represents the clean source.
[01:32] <infinity> mdeslaur: Then you build the rest of the package from the tag that represents your Debian upload, now that you have a proper orig.tar.gz in ..
[01:33] <infinity> Not positive, cause I don't use them, but I'd be surprised to discover that svn/git/bzr-builddeb don't already incorporate all of this into some nicely-wrapped workflow.
[01:33] <mdeslaur> oh, right, so the metadata is stored at the same time, I see
[01:34] <mdeslaur> s/metadata/delta/
[01:34] <infinity> Given that the delta's metadata, it was right either way. :P
[01:35] <mdeslaur> heh
[01:39] <RAOF> infinity: bzr-builddeb does it in a somewhat more sophisticated way - it stores the delta as a commit property on the upstream merge, rather than using a dedicated pristine-tar branch.
[01:40] <RAOF> Which has the pleasant property that I don't forget to push the gorram pristine-tar branch back to alioth all the gorram time.
[01:41] <micahg> I think texlive-binaries is the last piece of the texlive puzzle
[01:41] <micahg> oh, nevermind, that's bin
[01:41]  * infinity nods.
[01:41] <infinity> Patience.
[01:42]  * micahg goes and grabs that hat off the shelf
[01:42] <infinity> RAOF: When I was working on maemo in git, I just got use to push --everything-damnit-argh.
[01:42] <infinity> s/use/used/
[01:43] <RAOF> Sadly my repositories almost always contain branches that shouldn't be pushed.
[01:43] <infinity> Well, yes.  I didn't actually push everything. ;)
[01:44] <infinity> But I got used to remembering what I needed.  I dunno.  It gets drilled in after a while.
[01:44] <infinity> Especially with an annoying bot that tells you you're a loser.
[01:45] <infinity> "Hai, you pushed Debian revision tag, but I no haz upstream version tag matching, plz fix and/or die, kthx."
[01:47] <RAOF> That'd work :)
[01:47] <RAOF> Rather than the current method, which is the first person who tries to use the branch pinging me and going “hey, could you please, you know, make this branch actually *useful*?”
[02:05] <psusi> so again, he's pitching a fit because he doesn't want to have to run quilt refresh after rebasing to a new upstream or inserting patches in the middle of the stack?
[02:19] <psusi> who's in charge of the ubuntu foundations bugbot?  I think it's buggy
[02:19] <micahg> psusi: nope, it's purposeful
[02:20] <psusi> a few times in the last 24 hours or so, it apparently has flagged bugs as private and not subscribed ubuntu-crashes-universe for no apparent reason
[02:20] <micahg> oh, hrm, that issue :), ask bdmurray
[02:20] <psusi> thus, I get emails about bugs being filed, but can't go triage them
[02:44] <dobey> ow. that thread hurt my brain :)
[02:52] <psusi> it is hurting my brain too
[02:54] <psusi> "We know what a primary concrete objection is.  We discussed it at length
[02:54] <psusi> at DebConf two years ago, and then on debian-devel afterwards.  Uploading
[02:54] <psusi> a Git archive requires reviewing the entire contents of the archive, not
[02:54] <psusi> just the current code, for licensing issues, which is pretty painful from
[02:54] <psusi> the ftp-master perspective."
[02:54] <psusi> what the hell does that mean?
[02:55] <dobey> i think the short version is "I have no idea what the hell I'm typing right now."
[02:58] <RAOF> psusi: It means that the ftp-masters, who among other things need to check that what's being distributed is actually *distributable*, would need to check that *every revision* in the git history was distributable rather than just the final tarball.
[03:00] <psusi> RAOF, I don't grok that... if the project is gpl, then it's distributable, regardless of whether you are distributing the head revision, or the full history
[03:01] <dobey> psusi: assuming it was always GPL and didn't ever include anything that conflicted with that
[03:01] <RAOF> psusi: Is every file in the full history GPL?  Has upstream ever made a mistake and committed something they shouldn't have?
[03:01] <dobey> who the heck would stick a git archive in as a debian package anyway
[03:02] <dobey> that's just insane.
[03:02] <RAOF> People who basically already *use* a git archive as their source package? It's not like we're not doing it with bzr branches, either.
[03:02] <dobey> "Here's 300K of code, and 5GB of history. Enjoy!"
[03:04] <psusi> if they did commit something they aren't authorized to distribute, then THEY have to expunge it from their git repo
[03:04] <dobey> RAOF: well, we're storing source packages inside bzr branches. the source package doesn't include the bzr history, no?
[03:05] <RAOF> dobey: Some people have the source package branched of upstream trunk, and that's really quite useful.
[03:06] <dobey> RAOF: well, they have a vcs which has the source. apt-get source package doesn't pull the bzr history, does it? or is it smart and pulls form Vcs-Foo now?
[03:06] <RAOF> psusi: Yeah, but that doesn't help Debian. Sure, upstream needs to not distribute things that they don't have a license for. Debian also needs to not distribute things that they don't have a license for, and as a practical matter are *vastly* more likely than upstream to care.
[03:06] <RAOF> dobey: apt-get source doesn't; debcheckout does.
[03:06] <dobey> ah ok
[03:07] <psusi> what's more, if they ever did put in unlicensed code, then simply not including the history doesn't help us does it?  because if the *current* code can be traced back to the unlicnesed code as a derived work, then the current code also can not be distributed
[03:07] <RAOF> dobey: But I think the (eventual) end-goal is for the bzr branch to be the primary object; that people no longer upload source packages, just appropriately tagged bzr branches.
[03:08] <lifeless> psusi: not if they got a license for it, which may involve changing it
[03:08] <psusi> in other words, if you really don't trust upstream when they say their history is distributable, then you still have to audiit the history fully whether or not you are only distributing the head, or full history
[03:08] <dobey> i basically never trust upstream when they say their code is distributable
[03:08] <lifeless> psusi: that doesn't follow
[03:08] <dobey> programmers, designers, and artists aren't lawyers
[03:08] <psusi> lifeless, you mean they obtained the right to distribute derived versions, but not the old one that they still retain in their history?
[03:08] <RAOF> dobey: Indeed! We care *much* more about copyright than the wast majority of upstreams.
[03:09] <lifeless> psusi: yes
[03:09] <psusi> then they are violating that grant
[03:09] <psusi> by still having the old version in thier repo
[03:09] <RAOF> But not in a way that Debian has to care.
[03:09] <dobey> i could throw a nanobot into the vast sea of the internet and hit at least 5 license violations :P
[03:09] <lifeless> psusi: not necessarily: say that the original version was distributable by them but not transitively
[03:09] <lifeless> psusi: thats fairly common in fact
[03:10] <dobey> indeed, distributable != redistributable
[03:10] <lifeless> psusi: to get a transitively distributable version, they do something, which results in the code being different; there is now something in the history that:
[03:10] <lifeless>  - they can have on the net
[03:10] <lifeless>  - users can suck down
[03:10] <lifeless>  - we cannot ship
[03:10] <lifeless>  - we can ship the tip of it
[03:10] <psusi> that's... fuck up ;)
[03:11] <psusi> fucked up rather
[03:11] <lifeless> psusi: its the exact complexity of this situation the ftp-masters quite rightly want to avoid
[03:11] <dobey> eh, it's normal, actually
[03:11] <RAOF> Hello, flash!
[03:12] <psusi> why would the copyright holder ever say to a project you can distribute this code, but not under gpl, unless you make changes to it, THEN you can call it gpl?
[03:12] <dobey> they don't
[03:13] <psusi> I thought that's the scenario we were talking about... old rev isn't gpl... slightly modified version is
[03:13] <psusi> both are in history
[03:13] <dobey> they say ONLY you can distribute this code, from this point
[03:13] <lifeless> right
[03:14] <psusi> until some later point, prior to head?
[03:14] <lifeless> the effect is old version == ship to your users, new version == ship under GPL/Apache/whatever
[03:14] <dobey> sorry, by point i meant location
[03:14] <lifeless> the old version being the one we can't redistribute
[03:14] <dobey> newer code could possibly just not use that old library any longer
[03:15] <infinity> psusi: Relicensing code isn't exactly uncommon.
[03:15] <dobey> but the old code that uses it, and the thing itself, may still be in history
[03:15] <psusi> but if they don't want their code to be redistributable, then why would they not only allow initial distribution, but redistribution on the later versions?
[03:15]  * infinity glances at launchpad.
[03:15] <lifeless> psusi: because they get petitioned by e.g. us.
[03:15] <dobey> psusi: because the license, dependencies, etc changed
[03:15] <lifeless> psusi: or they learn more about open source
[03:15] <dobey> psusi: basically, the code is not the same thing it used to be.
[03:15] <lifeless> psusi: or a patent got turned over
[03:15] <lifeless> psusi: lots and lots of reasons
[03:16] <psusi> dobey, changing the license requires the original copyright holder of all previous versions to agree though, not just whoever last touched it
[03:16] <dobey> psusi: no it doesn't.
[03:16] <dobey> it requires all copyright holders of current code to agree
[03:17] <infinity> psusi: It requires the copyright holder of the current version.
[03:17] <dobey> code that is no longer there doesn't have to change
[03:17] <infinity> holder(s).
[03:17] <psusi> huh?  version x is a derived work of version x-1... if the copyright holder of version x-1 doesn't say it can be relicensed under gpl, it doesn't matter what whoever touched version x says
[03:17] <infinity> psusi: In your scenario, the copyright holder of x-1 is also the copyright holder of x.
[03:17] <dobey> psusi: if my program used to have a huge block of code from you in it, but no longer does, i do not have to ask you to change the license of the new code
[03:18] <infinity> psusi: If the copyright holder of x is different from x-1 (assignments happen), then no, I don't need x-1's permission to relicense x.
[03:18] <infinity> Anyhow.  This is all rather moot.  I think it's clear (I hope?) that the license on an entire git archive doesn't have to be internally consistent.
[03:19] <infinity> Or bzr, or whatever.
[03:19] <infinity> And, more often than you'd think, they're not.
[03:19] <lifeless> well, I think it has to be internally consistent, but if its not its a) not our problem and b) it can be internally consistent and still not consistent with the license of HEAD.
[03:20] <lifeless> infinity: ^
[03:20] <infinity> lifeless: How can it be internally consistent, but not consistent with HEAD? :P
[03:21] <infinity> lifeless: (My meaning of "internally consistent" was "across revisions")
[03:21] <dobey> anyway, must go now. later :)
[03:21] <psusi> I would think that if the original file were non gpl, and even if after several revisions, none of the original code remains, and all of the revising authors grant gpl, a very solid argument could be made that the subsequent revisions were derived works and so the license could not be changed without the original author's ok
[03:21] <lifeless> infinity: ah! definitions.
[03:21] <lifeless> infinity: so, I think each revision needs to be internally consistent, or the owner of the archive may have trouble.
[03:22] <infinity> psusi: If it's a derived work, I need permission to relicense if I don't hold copyright, yes.
[03:22] <lifeless> infinity: I think cross-revision licenses can and do change, but there should be some capability granting relicenses that occur
[03:22] <lifeless> infinity: none of which implies that we can distribute the archive :)
[03:23] <infinity> psusi: You seem to be of the opinion that relicensing version 3.4 of my source magically retroactively relicenses all previous versions.  Which just plain isn't true, unless, again, clearly stated and agreed upon by all copyright holders.
[03:23] <Chipzz> wouldn't relicensing of a file be a problem for upstream too if they published a VCS containing the old version (ie in the case of copyright violation or patent issue)?
[03:23] <Chipzz> I basically don't see how this problem is unique to debian or ubuntu and not to upstream?
[03:24] <infinity> Chipzz: Upstreams don't *re*distribute, they distribute.  If they hold copyright, they can do whatever the heck they want.
[03:24] <infinity> Chipzz: Debian and Ubuntu not only redistrbute, but guarantee redistribution rights to others.
[03:24] <infinity> Chipzz: As we're NOT the copyright holders, we need licenses to grant that.
[03:24] <Chipzz> but wouldn't they have a problem with distributing the old version too?
[03:24] <infinity> Chipzz: The old version that's theirs?
[03:24] <Chipzz> since it's still available from their VCS
[03:24] <infinity> Chipzz: As a copyright holder, you can do anything you want.
[03:25] <infinity> As your downstream, I can't.
[03:25] <infinity> It's as simple as that.
[03:25] <Chipzz> infinity: I think you're missing the point :)
[03:25] <infinity> Your violation/patent strawman is an interesting one, and yes, upstream would have to go cleaning to purge that from their VCS.
[03:25] <Chipzz> upstream VCS contains file x, file x rev a has a problem (be it copyright or patent), file x rev y (which is in HEAD for example doesn't)
[03:26] <Chipzz> wonrg placement of ) but whatever
[03:26] <infinity> I try to operate from a default assumption that upstream has copyright on their code, and we have licenses to distribute it.
[03:26] <infinity> Proving the latter is very hard with a long revision history.
[03:26] <Chipzz> the problem is fixed in rev y but since ppl can still obtain rev x from VCS that revision (and hence the problem) hasn't really gone away
[03:27] <infinity> Proving the former is up to courts.
[03:27] <infinity> Chipzz: There are ways to purge a VCS, if upstream has that issue.
[03:27] <Chipzz> right, but upstream would have to purge their VCS then
[03:27] <infinity> Yes...?
[03:27] <infinity> But that's not what we're talking about at all.
[03:28] <infinity> We're not talking about the rare case of someone filing suit because upstream stole code.
[03:28] <infinity> We're talking about upstreams and downstreams having different distribution rights.
[03:28] <infinity> Which is always true.
[03:29] <Chipzz> I was basically wondering if in the situation described above (before I joined the conversation) there being a problem for debian/ubuntu wouldn't imply a problem for upstream too
[03:29] <Chipzz> but meh, it's getting late, and I should be sleeping :)
[03:30] <Chipzz> and IANAL :)
[03:30] <Chipzz> gn!
[03:38] <psusi> infinity, no, quite the reverse... I am saying that unless all of the original authors agree, you can not relicense the new revision, and so a project that goes and changes license without all of the old holders' permission is not only violating copyright by distributing the old versions in vcs, but the head as well
[03:40] <psusi> infinity, therefore, I don't see how you can have a situation where it is ok to redistribute the head, but not past revisions
[03:44] <RAOF> psusi: Because infringing code got removed?
[03:56] <lifeless> psusi: copyright isn't homogeneous, contributing to a single file (for instance) doesn't give you copyright over all files; even in books, contributing to a single chapter doesn't grant you copyright over the whole book
[03:58] <psusi> yes, but if the whole chapter is removed to get around that, then what it is still doing in upstream's revision history?  shouldn't they expunge it if they can't get permission to relicense it?
[03:58] <lifeless> why should they ?
[03:59] <stgraber> bryceh: not sure if you found someone else to do it yet, otherwise just dump me the links in pm and I'll do it
[04:02] <psusi> well, it seems really odd that 1) they would have a license to distribute, but it isn't redistributable, 2) they went to all the trouble of removing it completely without having any of the new code considered a derived work of the original, and 3) wouldn't care to expunge it from the history to avoid creating problems for downstreams when they have already done most of the work required to do so
[04:02] <stgraber> bryceh: got the list from your e-mail to ubutu-devel, all done
[04:04] <psusi> also I wouldn't think it would be that difficult if this were to occur, to figure out the point where the project was relicensed, and just refuse to import the history before that
[04:50] <TheMuso> t/quit
[06:34] <bryceh> stgraber, much thanks!
[07:12] <mlankhor1t> pitti: http://status.ubuntu.com/ubuntu-quantal/people.html how do I get added to that list?
[07:15] <pitti> Good morning
[07:15] <pitti> micahg: gegl binaries are in main now
[07:15] <mlankhor1t> morning :)
[07:16] <pitti> cjwatson: I have no idea about ~lp_queue/manual-queue/ I'm afraid; langpack uploads happen the regular way, there's no special magic for them
[07:17] <pitti> mlankhor1t: you need to be in https://launchpad.net/~canonical-desktop-team ; I added you now
[07:17] <pitti> mlankhor1t: it should catch up in a few hours, possibly a day
[07:22] <mlankhor1t> ah k :)
[07:22] <mlankhor1t> thanks
[07:41] <pitti> cjwatson: thanks for the universal_newlines=True subprocess hint! that's indeed one I didn't know about
[07:53] <seb128> bdmurray, hey, is that wanted that your bot is going through bugs cleaning VarLogDistupgradeSystemstatetargz.gz files?
[07:54] <seb128> bdmurray, would be nice to announce in some way when you do such cross archive run and why
[07:54] <seb128> bdmurray, (would it only be so people know they can filter out the spam generated)
[08:03] <tarzeau> are ppa's good for ubuntu? or should i put some effort/time/work into getting packages into universe (especially if it has been in there in a previous release)?
[08:03] <tarzeau> or when will ubuntu sync packages again from debian?
[08:04] <mpt> pitti, hi, how do I get the work item tracker to ignore work items for last cycle (other than by deleting them)? They're headered "Work items for precise:" but they're still showing up on the charts
[08:04] <pitti> mpt: please retitle it to something like "work done in precise:"
[08:04] <pitti> mpt: i. e. anything that does not contain "work items"
[08:05] <mpt> ok, I'll try that, thanks pitti
[08:05] <seb128> hey pitti, mpt
[08:05] <pitti> hey seb128, bonjour
[08:05] <mpt> Good morning
[08:06] <seb128> mpt, are they in the whiteboard or the workitem section? (not sure how the workitem section is handled, maybe you need to move those to the whiteboard)
[08:06] <mpt> seb128, they're in the whiteboard (remember, 6 months ago we didn't have a work items field)
[08:07] <seb128> right, ok, so yeah what pitti said ;-)
[08:07] <pitti> the tracker still looks at both
[08:07] <pitti> for backwards compat reasons
[08:07] <seb128> tarzeau, ubuntu packages are currently synced from Debian in Q
[08:07] <pitti> we sync new packages much less often, though
[08:08] <seb128> tarzeau, you can use a ppa if you want, universe give you better user exposure since it's in the default sources, where a ppa is something you need to look for and enable ... which most users will not do
[08:08] <tarzeau> it's about old packages, and Q doesn't have it yet. oh well i'm just putting the stuff in our own repo
[08:09] <geser> tarzeau: which package is it?
[08:09] <tarzeau> geser: condor among some others, let me check...
[08:09] <tarzeau> geser: and i don't get why darktable was not synced to the latest version
[08:09] <seb128> does anyone knows how to debug "ureadhead doesn't seem to be used" issues?
[08:10] <seb128> ivanka's login is slow, she sent me a bootchart and the ureadhead step on boot is taking less than a second, i.e seems to not be doing any preloading
[08:11] <geser> tarzeau: darktable has an ubuntu delta, which should be either merged or dropped, but in any case it need human inspection
[08:11] <tarzeau> geser: ubuntu has the experimental plugins package
[08:12] <geser> tarzeau: and condor is currently only in unstable (but can by synced, testing if it builds in Ubuntu right now)
[08:13] <tarzeau> geser: i'm building it on precise now.. condor was in ubuntu when it wasn't in debian yet, but they just threw out the a bit older version in precise
[08:13] <tarzeau> natty had it though
[08:15] <geser> tarzeau: the Ubuntu delta is for a FTBFS, Ubuntu has the still the pluings package because it got dropped after 1.0-1 (we still have 0.9.3-2)
[08:41] <geser> tarzeau: condor synced to quantal, you can request a backport in a few days if you want to have available in precise
[08:50] <geser> tarzeau: and darktable 1.0.3-1 synced to quantal too
[08:55] <bkerensa> cyphermox: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/972063 <-- more affected
[09:32] <janimo> cjwatson, but redefine it in a hook prior to 10_linux so it takes precendence?
[09:32] <janimo> cjwatson, sorry, accidentally repeated a question from histroy
[09:33] <cjwatson> slangasek: 900526> I was actually going to do a quick sweep through my own SRUs and verify them, rather than having to debate it :-)
[09:33] <cjwatson> now that we seem to have agreed that's kosher
[09:38] <cjwatson> pitti: I'll nuke ~lp_queue/manual-queue/ before I lose the ability to, then :-)  I was pretty sure it was dead
[09:39] <cjwatson> pitti: universal_newlines=True> yw, took me a while to figure out :)
[09:39] <pitti> cjwatson: so as long as you can rely on the output being correct UTF-8, that makes it more convenient indeed
[09:40] <cjwatson> pitti: FYI new packages are synced on every auto-sync run now - it's no longer true that it's a separate manual task that gets arbitrarily delayed
[09:40] <pitti> cjwatson: oh, good to know!
[09:40] <cjwatson> though auto-sync prompts and it's a manual decision
[09:40] <cjwatson> but it provides enough information that it's a lot easier to do than it used to be
[09:41] <cjwatson> janimo: np
[10:08] <tjaalton> is /run/user a systemd'ism, or will we get something like that in the future?
[10:10] <seb128> tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-xdg-runtime-dir
[10:10] <seb128> bug #894391
[10:14] <tjaalton> seb128: ooh, great
[10:15] <cjwatson> ScottK: per-packageset build scoring is deployable at whenever the next Launchpad nodowntime is (today or more likely Monday, I guess).
[10:16] <cjwatson> (depending on whether some other QA gets done first, it may or may not deploy with a different property name at first, but I don't think anyone will care)
[10:16] <tjaalton> I'd like to add ~/.xsession-errors to the per-user runtime dir, since it's currently possible to fill up $HOME if apps go haywire
[10:18] <seb128> tjaalton, is it better to file $HOME or /run?
[10:18] <seb128> tjaalton, what happens if run is full?
[10:19] <tjaalton> seb128: /run/user would be a separate tmpfs, but anyway
[10:19] <pitti> tjaalton: it's not really meant for things like that
[10:19] <tjaalton> pitti: well it's meant for krb5 cache apparently
[10:20] <pitti> runtime_dir should be small files which change often and don't need to be written to disk, such as lock files, temporary copies, etc.
[10:20] <seb128> tjaalton, isn't filling tmpfs a DoS?
[10:20] <pitti> log files both grow indefinitely as well as should survive a reboot/logging out
[10:20] <tjaalton> ok, I'm all ears how to fix this bug :)
[10:20] <seb128> tjaalton, what? .xsession-errors filling up the user dir?
[10:21] <seb128> I think old gdm used to truncate .xsession-errors to 500k or something
[10:21] <seb128> lightdm should maybe do the same
[10:21] <pitti> I think lightdm just creates a new files
[10:21] <tjaalton> seb128: that's only on startup, it'll move the old file away and truncate if it's too large
[10:21] <pitti> file
[10:21] <pitti> but that doesn't help for long-running sessions
[10:22] <tjaalton> aiui there's no way to reduce the logging
[10:22] <pitti> to fix this, I don't think we can keep the current simple structure -- we need a filter in between the session and just redirecting all of its output to a file
[10:23] <seb128> hum, are you sure that gdm didn't use to stop logging if the file was hitting 500k?
[10:23] <pitti> yes, but only on session start
[10:24] <pitti> once you have a running session there is nothing that can control this file
[10:26] <tjaalton> hmm, would be neat if it was possible to feed it to rsyslogd somehow
[10:26] <seb128> pitti, ok, it's a bit weird since the code is wipped out on session start so I'm not sure where the limit can kick in
[10:26] <seb128> or did gdm used to not wipe it out?
[10:27] <pitti> seb128: we do not have the problem on session start
[10:27] <tjaalton> that patch is in xorg
[10:27] <seb128> pitti, I'm pretty sure something stopped writting to .xsession-errors during session when the file hit 500k
[10:27] <pitti> /etc/X11/Xsession
[10:27] <seb128> but I might be wrong
[10:28] <pitti> seb128: I'm not aware of that; only that we had some gdm (/etc/gdm/Xsession) which truncated everything but the last 500 kB on session start
[10:28] <seb128> like it was adding "truncated..." and not logging after that
[10:28] <pitti> seb128: it's still in /etc/X11/Xsession
[10:28] <pitti> if [ "`stat -c%s \"$ERRFILE\"`" -gt 500000 ]; then
[10:28] <pitti>   T=`mktemp -p "$HOME"`
[10:28] <pitti>   tail -c 500000 "$ERRFILE" > "$T" && mv -f "$T" "$ERRFILE" || rm -f "$T"
[10:29] <pitti> fi
[10:29] <pitti> so if your disk gets full, you can at least log out and back in to win back some space
[10:32] <seb128> pitti, well, lightdm wipe that file at login so no need to truncate it
[10:33] <seb128> pitti, though nowadays it does rotate it
[10:33] <seb128> pitti, which means you don't win space
[10:33] <zyga> hey, has the llvm pipe stuff been rolled out to quantal yet?
[10:33] <pitti> seb128: I know; I added that a while ago for other window managers which didn't do that
[10:33] <pitti> zyga: it already works in precise, but unity-3d still blacklists it
[10:35] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=459293
[10:35] <seb128> in fact old gdm had code
[10:35] <seb128> 		if G_UNLIKELY (d->xsession_errors_bytes >= MAX_XSESSION_ERRORS_BYTES &&
[10:35] <seb128> 			       ! got_xfsz_signal) {
[10:35] <seb128> 			VE_IGNORE_EINTR (write (d->xsession_errors_fd,
[10:35] <seb128> 						"\n...Too much output, ignoring rest...\n",
[10:35] <seb128> 						strlen ("\n...Too much output, ignoring rest...\n")));
[10:35] <seb128>  
[10:35] <seb128> pitti, i.e the logger job was stopping logging over a limit
[10:35] <seb128> which is what I was remembering from it
[10:35] <pitti> seb128: ah, so that one did put something in between the session stdout/err and a mere file redirection?
[10:36] <seb128> yes
[10:37] <tjaalton> it had it's own Xsession script as well, and didn't redirect the stderr/stdout to the file
[10:37] <tjaalton> so ok, that'd fix it for lightdm if it had something like that
[11:04] <jamespage> is there any etiquette I should be following before uploaded an large number of no-change rebuilds?
[11:09] <pitti> jamespage: one thing that comes to my mind is to check whether the buildds might potentially be needed for an impending milestone or beta release
[11:09] <pitti> jamespage: but since that's not the case, and the buildds are all empty and getting cold, go ahead :)
[11:09] <jamespage> pitti, that had crossed my mind
[11:09] <pitti> jamespage: please just make sure to not introduce "ubuntu"ish versions, use "build1" prefixes for unmodified packages
[11:10] <pitti> err, suffixes
[11:10] <jamespage> pitti, yep - was aware of that 'dch -R' has been my friend!
[11:10]  * jamespage goes to warm up the buildd's
[11:11] <pitti> oh, I didn't know about -R, thanks
[11:11]  * pitti still uses an ancient script to do mass rebuilds
[11:42] <Damjanek> Hi. Got a quick question about dependiences in debian/control file: I'd like to create dependency to upstream version, not to upstream+release version. How to do it? as I can see, there's no „package-name (~ version)”.
[11:49] <jtaylor> upstream+release version?
[11:49] <jtaylor> whats that
[11:50] <Damjanek> 3.3.5+dfsg1-1ubuntu1 - this is upstream+release version
[11:50] <Damjanek> 3.3.5 is upstream version
[11:50] <jtaylor> (>> 3.3.5) ?
[11:53] <Damjanek> it behaves like >=, right?
[11:53] <jtaylor> that would be (>= 3.3.5) then
[11:53] <jtaylor> >> behaves like >
[11:53] <Damjanek> Ah.
[11:53] <jtaylor> > and < should not be used
[11:54] <Damjanek> I'll try it this way, then
[11:54] <dpm> hi pitti, I've just been trying to build a python app, which had been building fine until I actually added po files to it. I had not noticed it locally, but when I uploaded to a PPA, I get an intltool error. It seems that it is looking for the bin/qreator.py, but that file does not exist (only bin/qreator). IIRC, python-distutils-extra in auto mode generally creates a temporary bin/qreator.py file to extract translations from it, but it did not seem to
[11:54] <dpm> do it this time. Do you have any pointers on what could have gone wrong? Here's the build log -> https://launchpadlibrarian.net/105430456/buildlog_ubuntu-precise-i386.qreator_12.05.1_FAILEDTOBUILD.txt.gz
[12:00] <dpm> pitti, oh, I see what happened, Quickly or p-d-e added a po/POTFILES.in file listing the .py file, that's why it can't find it. IIRC, p-d-e uses a temporary POTFILES.in file when creating the .pot file, but this one seems to be a permanent one. Perhaps that's the problem
[12:07] <pitti> dpm: yes, that's correct; it won't create the "magic" POTFILES.in if one already exists
[12:09] <dpm> pitti, thanks. I think it might be a bug in quickly. It seems to create and commit POTFILES.in after using the 'quickly release' command, despite using p-d-e in auto mode in setup.py.
[12:11] <dpm> although quickly does not actually seem to touch any POTFILES.in files. Could it be that it got p-d-e or intltool to somehow create a permanent POTFILES.in file?
[12:11] <pitti> perhaps from a failed run, when it fails to clean it up?
[12:11] <pitti> but then it should have the "fake" .py entry
[12:12] <Damjanek> jtaylor: Thanks for your help.
[12:12] <Damjanek> Bye
[12:16] <dpm> I'll keep investigating, thanks pitti
[12:25] <elky> pitti, dpm is docutils involved in that?
[12:25] <pitti> I doubt it, it sounds unrelated
[12:25] <dpm> not that I know of
[12:25] <elky> with intltool i mean
[12:25] <elky> https://bugs.launchpad.net/ubuntu/+source/sphinx/+bug/997891
[12:28] <ScottK> cjwatson: Thanks for your work on the build priorities.  I think it's a good step forward.
[13:17] <stgraber> @pilot in
[13:36] <cyphermox> bkerensa: got it, looking
[14:03] <psusi> cjwatson: if grub fails to install under ubiquity, what log file would the error be in?
[14:03] <ogra_> syslog ?
[14:05] <cjwatson> psusi: should be in syslog and/or installer/debug
[14:07] <psusi> hrm.... weird.. I looked at both log files this user posted and don't see any grub error... bug #1000934
[14:18] <hallyn> say, is there an easy way to tell debootstrap to use my local .deb instead of one from the archive?
[14:23] <mlankhor1t> create a local repo :)
[14:32] <hallyn> can i create a virtual mirror which only overrides packages i install?  wonder if mini-dak does that
[14:43] <hallyn> maybe i can make it work just with --download-only and apt-move
[16:06] <yofel> jbicha: a question about the boot procedure (re bug 894456): Where is fsck.<FS> read from when mountall calls it? / or initrd?
[16:09] <yofel> I'm having a bit of a hard time finding out under what exact conditions fsck is called my mountall
[16:10] <yofel> *by
[16:13] <hallyn> stgraber: ischroot fails with -2 if /proc is not mounted.  Fix is to temporarily mount it :)  my q is, should i do that in ischroot, or do it in the initscripts.postinst that is using it and messing up as a result?
[16:14] <cjwatson> yofel: mountall runs in the real root
[16:16] <yofel> cjwatson: how does it call fsck for / ? with / mounted RO or does it unmount / before checking?
[16:16] <stgraber> hallyn: that's odd. I believe debootstrap mounts /proc so I'm not too sure why we don't have it mounted at the time we call ischroot
[16:17] <stgraber> hallyn: or is that because initscripts gets updated later on (after debootstrap) in an environment where /proc isn't mounted?
[16:17] <cjwatson> yofel: the former
[16:17] <yofel> ok, thanks
[16:17] <hallyn> stgraber: hm.  well then maybe i'm wrong about how i think it works
[16:18] <stgraber> hallyn: I'd expect much more things to blow up if /proc isn't mounted during bootstrap
[16:19] <xnox> Just started using 'request feedback' on blueprints... only to find bug #1000642
[16:20] <hallyn> stgraber: all right i guess i need to nail down the local archive thing so i can better test
[16:20] <cjwatson> tseliot: would you mind following up on bug 982710?  I copied it to -updates based on comment #46, but now there's a complaint about a regression
[16:20] <cjwatson> xnox: request feedback was always an utter disaster of a UI
[16:20] <tseliot> cjwatson: sure, thanks
[16:21] <xnox> cjwatson: =))))
[16:21] <kees> xnox: say, where do you want to coordinate raid documentation? I figure somewhere in the wiki. do you have a preference?
[16:23] <xnox> kees: my preference would be a bzr branch of LaTeX documents, but I do understand that this is not the most contributor friendly format.
[16:23] <xnox> kees: Wiki is probable, not sure if it will be the upstream RAID wiki or wiki.ubuntu.com
[16:23] <xnox> kees: to begin with wiki.ubuntu.com
[16:24] <xnox> depends how 'ubuntu' specific it will be
[16:25] <xnox> kees: I'm still going through a few things here. My plan was to talk to you more after I did my initial digging of historic work done on the topic first.
[16:25] <hallyn> kees: hey :)  (i answered late last night, but) yes, cap_sys_admin should be required for CLONE_NEWNS.
[16:25] <hallyn> enforced by kernel/nsproxy.c (supposedly)  you're finding it isn't?
[16:28] <xnox> kees: wiki.ubuntu.com ok with you? do you have a preference? (you have more knoweldge currently, so anything that works best for you is preferred)
[16:34] <mdeslaur> infinity: could you take a look at my lintian debdiff before I upload it? I'd appreciate a second opinion, I'm not quite sure that's the best way to handle readelf: http://paste.ubuntu.com/994477/
[16:37] <kees> hallyn: yeah, I think glibc was tricking me or something. my "child" function was getting called, but not after a clone. once I sorted things out, it correctly EPERMed.
[16:37] <kees> xnox: yeah, wiki.ubuntu.com is my preference. initially, my brain-dump of the history will be very ubuntu-specific.
[16:37] <kees> xnox: I was wondering what subtree to use in the wiki.  RAID/History or something?
[16:38] <cjwatson> kees: oh, hey, you know about seccomp.  I don't suppose you want to take a guess at why the seccomp_filter probe child process in my patch in https://bugzilla.mindrot.org/show_bug.cgi?id=2011 falls over with SIGSYS?
[16:39] <xnox> kees: Maybe https://wiki.ubuntu.com/ReliableRaid/History ? Cause there is https://wiki.ubuntu.com/Raid but that should really be part of the server guide / help.ubuntu.com
[16:39] <cjwatson> I haven't yet tried it in a more normal userspace/kernel combination
[16:41] <hallyn> kees: ah, ok.  cool.
[16:46] <bdmurray> slangasek: regarding https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/349469/comments/34 I think I see what clint was suggesting now
[16:46] <bdmurray> slangasek: if we see 'config.dat' in the error message we could gather the output of another command
[16:53] <kees> xnox: sure, that path sounds good.
[16:53] <kees> cjwatson: looking...
[16:55] <kees> cjwatson: fwiw, SIGSYS means seccomp killed it.
[16:57] <cjwatson> Right, I'd worked out that much (though it was a new one on me).  But the filter it's loading should allow exit_group, which is the only syscall used after prctl in that process.
[16:57] <kees> cjwatson: yeah... I was trying to find something to view the code....
[16:57] <cjwatson> just grab lp:openssh
[16:57] <kees> cjwatson: do you have a link to a vcs-viewer? I want to see the preauth filter
[16:58] <kees> okay
[16:58] <cjwatson> http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c
[16:59] <mlankhor1t> is mmap allowed with seccomp?
[16:59] <kees> I read this when Will was writing it originally. :P
[16:59] <kees> mlankhor1t: depends on the filter
[16:59] <SpamapS> is there no python3 bzrlib?
[16:59] <mlankhor1t> was still toying with my program
[16:59] <cjwatson> SpamapS: sounds like a project for you!
[16:59] <SpamapS> cjwatson: aww man, why didn't you warn me before I stepped in that?
[17:00] <SpamapS> ;)
[17:00] <cjwatson> it hasn't been ported
[17:01] <cjwatson> or, if it has, it hasn't been landed
[17:02] <SpamapS> I'll skip. Been trying to use python3 in one-off scripts lately to get used to the differences.. :-P
[17:02] <cjwatson> that said, they dropped pre-2.6 support in 2.4, which should help
[17:02] <SpamapS> My knowledge of python3 packaging is also weak.. not sure if bzr is the place to learn
[17:03] <SpamapS> though.. python-configobj might be
[17:03]  * xnox sees no bugs about python3 support in bugs.launchpad.net/bzr
[17:03] <kees> cjwatson: hunh
[17:03] <kees> cjwatson: so, this is extra weird
[17:03] <kees> cjwatson: I would expect your prctl to fail.
[17:04] <kees> cjwatson: is it possible the seccomp filter is already in place, and the prctl itself is killing it?
[17:04] <xnox> SpamapS: http://www.wefearchange.org/2012/01/debian-package-for-python-2-and-3.html
[17:04] <cjwatson> kees: Why would the prctl fail?
[17:04] <cjwatson> kees: I don't *think* that's possible, and strace shows the prctl returning 0
[17:05] <kees> cjwatson: for SECCOMP_MODE_FILTER to work, you either need CAP_SYS_ADMIN or to have called prctl(PR_SET_NO_NEW_PRIVS, 1, ...) first
[17:05] <kees> e.g. http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c#L200
[17:06] <kees> cjwatson: iirc, what Chrome does to detect seccomp is to do a SECCOMP_MODE_FILTER call with an empty filter. if it replies with EINVAL, seccomp exists. if it replies ENOSYS, there's no seccomp
[17:06] <kees> let me check that, though...
[17:06] <kees> EINVAL would get sent for non-mode-2 as well...
[17:07] <cjwatson> kees: oh, OK, I assumed the no-new-privs was unnecessary but I can go and do that now
[17:08] <cjwatson> [pid  3977] prctl(0x26 /* PR_??? */, 0x1, 0, 0, 0) = 0
[17:08] <cjwatson> [pid  3977] prctl(PR_SET_SECCOMP, 0x2, 0x80ac0b8, 0, 0) = 0
[17:08] <cjwatson> [pid  3977] +++ killed by SIGSYS +++
[17:08] <cjwatson> (adding no-new-privs doesn't help)
[17:09] <cjwatson> I could restore the approach from openssh/configure if that's more likely to work; maybe I last tried that before adding the fork
[17:10] <cjwatson> http://bazaar.launchpad.net/+branch/openssh/view/head:/configure.ac#L137
[17:12] <cjwatson> but, in any case, if I make the probe just pass unconditionally, the monitor child does nothing obviously useful - so I'm wondering if there's something else wrong
[17:12] <kees> ah! EFAULT, yes.
[17:12] <cjwatson> maybe I should try in a 64-bit userspace
[17:13] <kees> I do recommend the detection method from configure, though.
[17:13] <kees> that doesn't require the nnp prctl, and doesn't even require a filter.
[17:14] <kees> why it doesn't error out, though, is weird.
[17:18] <slangasek> bdmurray: right - in theory we want to be able to do this kind of thing via whoopsie in the future so we can change such things dynamically, but I don't think we have the security model nailed down yet... so an updated apport hook could indeed be useful there
[17:19] <cjwatson> kees: Has seccomp been tested in 32-on-64 systems
[17:19] <cjwatson> ?
[17:22] <bdmurray> slangasek: and what would that updated hook do?
[17:22] <infinity> mdeslaur: Gah.  Looking.
[17:22] <slangasek> bdmurray: some combination of 'fuser /var/cache/debconf/config.dat' and 'pstree', I think
[17:22] <bdmurray> slangasek: okay, thanks
[17:23] <mdeslaur> infinity: I'm still investigating why readelf works differently
[17:23] <slangasek> bdmurray: though TBH, I've asked for that in the bug description and some people have provided those answers... and I haven't managed yet to make heads or tails of them
[17:23] <infinity> mdeslaur: Yeah, I'm spinning up a sid chroot to poke too.
[17:24] <mdeslaur> infinity: kees mentioned maybe related to -Bsymbolic-functions that's by default on Ubuntu
[17:24] <mdeslaur> infinity: I was going to try that
[17:25] <kees> and why isn't -Wl,-Bsymbolic-functions listed on https://wiki.ubuntu.com/ToolChain/CompilerFlags ?
[17:25] <slangasek> bdmurray: still, if we were getting that info consistently from all duplicates, maybe we would see a pattern emerge
[17:25] <slangasek> kees: because it's a linker flag? ;)
[17:26] <kees> slangasek: *sigh*
[17:26] <slangasek> nah, that's clearly not the reason
[17:27] <stgraber> @pilot out
[17:27] <kees> cjwatson: yeah, works in compat mode
[17:27] <slangasek> but I don't know
[17:27] <kees> cjwatson: but if the arch test is wrong, it'll kill it.
[17:27] <cjwatson> kees: hmm, ok, I probably screwed up something arcane then.  I'll try again later
[17:27] <cjwatson> the arch test?
[17:29] <kees> cjwatson: http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c#L83 <- that verifies that the program hasn't switched architectures (i.e. started doing compat calls when built 64-bit)
[17:30] <kees> i.e. SECCOMP_AUDIT_ARCH must match the system that it's running on. (which is why it's best to avoid building a filter for the initial testing)
[17:31] <cjwatson> oh, yeah, openssh isn't going to do that
[17:31] <kees> cjwatson: oh! is $host wrong?
[17:31] <kees> (in configure.ac?)
[17:31] <cjwatson> oh, that's possible, I'm configuring by hand rather than via dh_auto_configure
[17:32] <cjwatson> $ ./config.guess
[17:32] <cjwatson> x86_64-unknown-linux-gnu
[17:32] <cjwatson> bah, yes, good catch
[17:32] <kees>         case "$host" in
[17:32] <kees>         x86_64-*)
[17:32] <kees>                 AC_DEFINE([SECCOMP_AUDIT_ARCH], [AUDIT_ARCH_X86_64],
[17:32] <kees> yeah, so it's trying to set up a 64-bit filter and getting killed by that failure
[17:33] <kees> cjwatson: so, looks like you'll need to adjust the SECCOMP_AUDIT_ARCH test a bit and skip the autodetection if there is no known arch, etc.
[17:34] <cjwatson> or just configure with the right --build=
[17:34] <cjwatson> so this is x86-only at the moment?
[17:34] <kees> yes, though ARM patches are currently being written
[17:35] <cjwatson> kees: thanks, that works now!  I'll fix up the test and resubmit upstream
[17:36] <kees> cjwatson: yay! :)
[17:40] <dylan-m> Hey, I'm writing some code that presents packages as applications (like "Text Editor" instead of 'gedit'). Looks like Software Centre has some pretty extensive logic to that end...
[17:40] <dylan-m> Do you think there would be interest in moving that code to a separate library?
[17:40] <dylan-m> So far I'm loading application .desktop files from app-install-data and the package's installed files, but there seem to be some discrepancies between my output and Software Centre's and I don't like duplicating lots of functionality.
[17:41] <hallyn> hm, debootstrap from my custom mirror isn't working.
[17:43] <infinity> mdeslaur: Okay, your patch looks sane.  And should also work on Debian.
[17:43] <infinity> mdeslaur: Also has the added bonus of getting versions back, which their invocation seemed to drop...
[17:45] <geofft> dylan-m: You might be interested in AppStream or PackageKit?
[17:47] <dylan-m> Oh, it's for Update Manager, by the way. Do you know if it would be okay to have PackageKit as a dependency, geofft?
[17:48] <mdeslaur> infinity: thanks for the review, I'll also add -U_FORTIFY_SOURCE, and I'll send it to debian
[17:49] <kees> mdeslaur: can you CC me when you open that bug?
[17:49] <geofft> I'm not the person to ask, I just lurk on distributions@l.fd.o :) But I recall hearing general "that should happen" regarding making software center and update manager use more of PackageKit.
[17:50] <geofft> someone else probably knows more than I do regarding current thinking there
[17:51] <dylan-m> geofft: Yeah, I've been getting that impression, too, but it looks like a bit of work to get everything talking to it :) I'm mostly concerned about being consistent for now.
[17:51] <mdeslaur> kees: sure
[17:52] <infinity> dylan-m: Wait, what?  You're making update-manager no longer display package names?
[17:52] <dylan-m> infinity: I'm working on this: https://wiki.ubuntu.com/SoftwareUpdates#Expanded_presentation_of_updates.
[17:53] <dylan-m> infinity: In short, it displays both ;)
[17:55] <infinity> dylan-m: The mockup doesn't make "both" particularly clear there.
[17:56] <infinity> dylan-m: (ie: what is "Terminal"?)
[17:56] <infinity> dylan-m: If I have gnome-terminal and xfce4-terminal installed and both are available for update, do I just get two uninformative "Terminal" entries?
[18:00] <dylan-m> infinity: Right now it's displayed as it would appear in the dash or an applications menu. I think there are a few ways to group apps and their packages that will behave slightly differently, so those will have to be played with as this goes along.
[18:06] <cnd> slangasek, we need to upload a rebuild of evdev in precise for some magical ABI break that doesn't make any sense but a rebuild fixes (bug 973297)
[18:06] <cnd> the current package version is 1:2.7.0-0ubuntu1
[18:06] <cnd> what would a rebuild package version be?
[18:06] <slangasek> 1:2.7.0-0ubuntu1.1, preferably
[18:06] <cnd> ok
[18:07] <cnd> so basically the same as a full sru
[18:07] <slangasek> yep
[18:07] <slangasek> the only time rebuild-only uploads get a special version number is when we're currently in sync with Debian
[18:08] <cnd> ahh
[18:12] <barry> ScottK: ping
[18:15] <cnd> slangasek, so I realized that this likely isn't fixed in quantal either since there hasn't been a rebuild of the package yet
[18:15] <cnd> should I be uploading a 1:2.7.0-0ubuntu2 to quantal and a 1:2.7.0-0ubuntu1.1 to precise?
[18:18] <cnd> or should I just upload to precise and somehow get it pocket copied to quantal like the current package has been?
[18:24] <cjwatson> cnd: both are possible; it probably doesn't make sense to do two separate rebuilds here ...
[18:24] <cnd> cjwatson, ok, so then should I forgo the SRU versioning and just upload version 1:2.7.0-0ubuntu2?
[18:25] <cjwatson> I'd tend to use 1.1 myself anyway
[18:25] <cnd> ok
[18:25] <cjwatson> though strictly, it only needs not to clash; but you'll probably get fewer questions this way
[18:26] <cjwatson> since it needs not to clash with potential future versions the SRU team doesn't know about as well :)
[18:26] <cnd> yeah
[18:26] <ScottK> barry: pong.  Replied to your mail.
[18:27] <barry> ScottK: thanks!  i couldn't wait.  :)  glad it worked out
[18:32] <kees> slangasek, xnox: ah-ha, in researching this raid brain-dump, now I know why the raid failure code wasn't running. :)
[18:32] <kees> (and am documenting it)
[18:53] <slangasek> kees: whee :)
[19:02] <infinity> pitti: Say, uhm... Where's nscd-dbgsym?
[19:04] <slangasek> infinity: did ev's blueprint eat it? :)
[19:04] <infinity> slangasek: :P
[19:05] <infinity> slangasek: My assumption is something more like ddebs doesn't deal sanely with packages with main/universe splits, or something, but you'd think someone would have noticed that...
[19:05] <infinity> slangasek: (Or maybe pitti just dumped a bunch of universe ddebs to make space)
[19:05] <slangasek> I wouldn't be so sure... it could easily be lost in the noise where ddeb bugs are concerned
[19:09] <kees> slangasek, xnox: https://wiki.ubuntu.com/ReliableRaid/History
[19:09] <slangasek> woot
[19:28] <kees> omg, I just figured out how LVM and md get out of sync sometimes.
[19:28] <kees> what a horrible race condition.
[19:29] <ion> Heh, sounds nice.
[19:29] <kees> I think it's because LVM lost a patch to have it ignore md devices.
[19:37] <slangasek> kees: well ugh
[19:37] <slangasek> which patch was that?
[19:37] <slangasek> since we, er, didn't merge lvm2 forever
[19:53] <kees> slangasek: I have no idea -- that will need much more digging
[19:54] <kees> s/ignore md devices/ignore md components/
[19:54] <hallyn> stgraber: could you ping me when you have a minute for me to pick your brain?
[19:58] <stgraber> hallyn: ping
[19:59] <hallyn> stgraber: thanks.  basically i'm doing https://wiki.ubuntu.com/SergeHallyn_localrepo  in the hopes of having debootstrap use my modified initscripts .debs
[19:59] <hallyn> but it fails (let me pastebin the errors)
[19:59] <hallyn> is it obvious to you why?  do i just need more packages than what debootstrap --download-only had grabbed?  (do i need to make it a full local mirror)?
[20:00] <hallyn> here is the debootstrap.log: http://paste.ubuntu.com/994779/
[20:03] <stgraber> hallyn: hmm, looks like something is wrong with your archive that confuses debootstrap and then dpkg
[20:04] <stgraber> hallyn: just thinking of what you're actually trying to do, couldn't you use the --foreign flag to have debootstrap download + unpack, then change your initscript and do "chroot path debootstrap/debootstrap --second-stage"?
[20:04] <slangasek> kees: this is of course an imminently SRUable issue, so let me know if you need us to do some legwork
[20:05] <hallyn> yes i was going to pursue that if i couldn't get this working.  couldn't find any docs on that (besides the manpage) so i figured that woudl involve experimentation as well
[20:05] <chrisccoulson> anyone got any bright ideas how to debug this? https://launchpadlibrarian.net/105416854/buildlog_ubuntu-quantal-amd64.firefox_13.0~b4%2Bbuild1-0ubuntu2_FAILEDTOBUILD.txt.gz
[20:06] <chrisccoulson> the buildd is literally the only place this problem happens :(
[20:06] <hallyn> stgraber: in particulary I'm not 100% clear on what state --foreign leaves it in, i.e. if i need to change a postintall script onthe chroot, or update the package in the chroot's cache
[20:07] <slangasek> chrisccoulson: have you identified the root error?  looks to me like it's probably at line 283157, is that right?
[20:07] <stgraber> hallyn: apparently you can do "sudo debootstrap --foreign precise my-chroot && sudo cp <your deb> precise/var/cache/apt/archives/<original deb> && sudo chroot my-chroot debootstrap/debootstrap --second-stage"
[20:08] <chrisccoulson> slangasek, it's the abort in dump_syms multiple times which fails the build
[20:08] <slangasek> chrisccoulson: have you ruled out it being a pkgbinarymangler issue?
[20:08] <hallyn> stgraber: ah! that's why it failed the one time i tried it,
[20:08] <slangasek> i.e., have you made sure to have that in your reproducing env?
[20:08] <hallyn> i wasn't doing second-stage from chroot
[20:09] <chrisccoulson> slangasek, no, good point!
[20:09] <chrisccoulson> thanks
[20:09] <chrisccoulson> i'll try that now
[20:09] <stgraber> hallyn: confirmed that it runs here, so I guess it'll do the trick for you
[20:09] <hallyn> it doesn't like my pkgs :)  it wants the same version as the original maybe
[20:10] <stgraber> oh yeah, you'll need to have the same version
[20:10] <stgraber> or manually mess with apt's list files (wouldn't recommend that)
[20:10] <slangasek> chrisccoulson: another possibility might be that the code is building differently because it's running on a hardy kernel on the buildds?
[20:11] <hallyn> stgraber: thanks.  i do wish i could get the mirror way working, but this gets me going :)
[20:11] <chrisccoulson> slangasek, is it still a hardy kernel? i saw this line at the top of the build log and assumed it wasn't:
[20:11] <chrisccoulson> Kernel version: 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64
[20:11] <chrisccoulson> but if it is, then i should try that too
[20:11] <hallyn> will keep working with that when i get time
[20:12] <slangasek> chrisccoulson: oh, looks like you got one of the shiny new buildds then :)
[20:48] <rbasak> "Failure while unpacking required packages.  This will be attempted up to five times." -- can this be made priority high rather than critical? I'd prefer my automated installs not to fail because of this.
[20:49] <slangasek> rbasak: short answer: yes, I think so
[20:50] <slangasek> rbasak: long answer: why is it failing?  is this more cloud apt love?
[20:51] <slangasek> oh, though that's not an answer is it ;)
[20:51] <rbasak> slangasek: this is d-i netinst on quantal, on ARM. It's from a static mirror, so I don't think it's apt. But it might be something I'm doing. Or it might be a temporary quantal issue. But after the retry it does work.
[20:51] <slangasek> hmm
[20:51] <slangasek> it's quite unusual that you should hit that
[20:52] <rbasak> It's reliably reproducable for me at the moment.
[20:52] <slangasek> can you grab the logs showing what failed?
[20:53] <slangasek> (/var/log/syslog, I believe)
[20:53] <rbasak> It's complicated, but let me try :)
[21:11] <hallyn> stgraber: for pete's sake.  in the end, it turns out the args to compat_link are just int he wrong order
[21:12] <ajmitch> heh
[21:12] <stgraber> hallyn: ;)
[21:13] <stgraber> hallyn: how comes that only broke containers?
[21:13] <hallyn> well it's a path only taken 'if ischroot'
[21:13] <stgraber> ah right
[21:14] <hallyn> and then, toward the end, because the link failed, it mkdirs it
[21:15] <hallyn> hm, there goes my battery again saying 'not present'
[21:17] <xnox> kees: slangasek: Added two clarification footnotes on to https://wiki.ubuntu.com/ReliableRaid/History
[21:19] <slangasek> xnox: o
[21:19] <slangasek> k
[21:26]  * xnox is worried. Is 'ok' split between two lines mean something dramatic?!
[21:27] <slangasek> it means "I have forgotten how to type in my old age"
[21:58] <hallyn> slangasek: hey - changelog for initscripts says you did the /dev/shm /run transition...  would you mind checking my debdiff on bug 974584 for sanity?  I can't help feel I'm doing something stupid
[22:24] <slangasek> hallyn: peeking
[22:25] <hallyn> thx
[22:29] <slangasek> hallyn: ln argument naming really is the worst
[22:29] <slangasek> why would anyone call the real file being pointed to by a symlink the "source"
[22:31] <slangasek> hallyn: yeah, looks like you're right
[22:31] <slangasek> I'm surprised to see this hasn't been fixed in Debian either
[22:32] <slangasek> well now, wait
[22:32] <slangasek> if compat_link /var/run /run; then
[22:32] <slangasek> how does that part 8ever* succeed, if this is backwards?
[22:33] <hallyn> bc if the target exists it exits early with success?
[22:33] <slangasek> heh
[22:33] <hallyn> (sorry, checking :)
[22:35] <hallyn> but no, when running debootstrap, at that point, /run/lock already exists.  so does some other package create /run/lock with /run as symlink to /var/run?
[22:36] <slangasek> good question
[22:36] <hallyn> dpkg -x initscripts*.deb x; ls -ld x/run.  run is there
[22:36] <slangasek> hallyn: base-files extracts /run/lock
[22:36] <slangasek> s/extracts/creates/
[22:36] <hallyn> ok, so on an upgrade that might not happen?
[22:37] <slangasek> hallyn: so is that consistent with your analysis?
[22:37] <hallyn> yes
[22:38] <slangasek> base-files creates /run/lock on initial package install only (so as part of debootstrap).  On an upgrade from a system / chroot initially installed using base-files lt 6.4, you won't have it from base-files
[22:39] <hallyn> on a system, you wont' hit that path.  only in a chroot.  so... does anyone do that?  if so, why didn't they hit this?
[22:39] <slangasek> hallyn: so my precise chroot has /var/run and /var/lock as directories - I guess that's the same problem?
[22:40] <slangasek> I guess everything one runs in a chroot was consistent enough in its own use of /run vs. /var/run that nobody actually noticed?
[22:40] <hallyn> yes
[22:40] <slangasek> so yeah
[22:40] <slangasek> I think your patch is correct
[22:40] <slangasek> and probably should get SRUed
[22:40] <hallyn> so the patch needs further fixing then
[22:40] <slangasek> ah, because it also needs the /var/run /run swapped
[22:40] <hallyn> i'm being told it's quittin' time though
[22:40] <slangasek> :)
[22:41] <hallyn> right, and /run/lock created
[22:41] <hallyn> i'll give tha ta shot on monday, but still not convinced i'm smart enough to test it right.
[22:41] <hallyn> slangasek: thanks.  ttyl
[22:41] <slangasek> hallyn: have a good weekend
[23:06] <bdmurray> slangasek: is there any reason not to won't fix bug 1001068?
[23:06] <slangasek> bdmurray: hmm
[23:07] <slangasek> bdmurray: I think we may have gone through this same through situation last cycle
[23:07] <bdmurray> I'll look for closed bugs then
[23:08] <slangasek> bdmurray: bug #870618
[23:08] <slangasek> we decided that it was better to keep $release defaulting to $release for the upload target, for the ppa use case
[23:08] <slangasek> even though for the distro, 'precise' is no longer a valid upload target
[23:09] <slangasek> so yeah, I'm gonna do the opposite of wontfixing it :)
[23:09] <bdmurray> willfix?
[23:09] <slangasek> yep!
[23:27] <cjwatson> slangasek: ln ordering> I think of it as directly analogous to cp -l
[23:28] <cjwatson> (or -s)
[23:49] <smallfoot-> why isn't AMD64 and AMD64 Mac merged into same image?
[23:51] <cjwatson> smallfoot-: because it's hard
[23:51] <smallfoot-> oh
[23:51] <smallfoot-> whats really the difference?
[23:51] <cjwatson> we'd like to, but it will take pretty noticeable work
[23:51] <smallfoot-> oh
[23:52] <cjwatson> http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image/40480#40480
[23:52] <smallfoot-> aren't like 99,99% the same?
[23:52] <smallfoot-> thanks
[23:52] <cjwatson> Matthew Garrett posted some terrifying instructions on how he's been working on a similar problem in Fedora of late, which will likely form the basis of a solution; however we're using some slightly different tools so it may take a while to port
[23:54] <smallfoot-> oki
[23:54] <smallfoot-> guess it wont be done for 12.10 :(
[23:55] <smallfoot-> im glad the alternative installer is gone
[23:55] <cjwatson> it is not yet; there is a large dependency to fix first
[23:56] <chrisccoulson> is there anyone who can bump up the score of https://launchpad.net/~chrisccoulson/+archive/ppa/+build/3500900 ?
[23:56] <smallfoot-> oh
[23:56] <cjwatson> chrisccoulson: done
[23:57] <chrisccoulson> cjwatson, excellent, thanks!
[23:58] <psusi> cjwatson, the partman port to libparted3? ;)
[23:58] <cjwatson> psusi: no