[00:12] <micahg> infinity: sorry, Fri night is the one night I'm not around :)
[00:54] <infinity> micahg: Crazy talk.
[00:54] <infinity> micahg: Was just trying to ping someone from the mozilla team to make sure you merge my build-dep change that I made in precise (and it probably applies to all other releases too)
[00:55] <infinity> micahg: Also, core-dev not being able to commit to those branches irks me. ;)
[00:55] <micahg> infinity: I noticed that, will do later tonight, when did that change or was it always not essential?
[00:55] <infinity> micahg: It never has been.  lamont's chroots are just dirty. :P
[00:55] <micahg> infinity: yeah, we should probably fix that
[00:56] <infinity> micahg: My armhf chroot is a bit more lean and policy-draconian.
[00:56] <micahg> infinity: that's good, gives us a chance to clean up old broken stuff :)
[00:59] <infinity> Oh, it might not be lamont's fault. :P
[00:59] <infinity> --variant=buildd is dirty.
[00:59] <infinity> Which he uses to build his chroots.
[00:59] <infinity> And, in fact, most people do.
[00:59] <infinity> I should fix that.
[01:28] <cjwatson> infinity: debootstrap never goes lower than everything in Priority: required
[01:28] <infinity> cjwatson: Yeah, I just read that.
[01:29] <infinity> cjwatson: I'm curious how my minbase chroot didn't have locales in it, but that may have been a bootstrapping artifact.
[01:29] <cjwatson> I guess you could make it do Essential: yes + Build-Essential: yes but then you'd also have to deal with expanding Essential's dependencies, since that isn't a closed set.
[01:29] <infinity> cjwatson: That said, it also makes --variant=buildd non-policy-compliant, and it has been since.. 2005, when that autodetection bit was written. :P
[01:29] <cjwatson> Which I think is basically why it doesn't.
[01:30] <infinity> cjwatson: expanding deps is already there.
[01:30] <infinity> Surely?
[01:30] <cjwatson> Mm, it might manage it.
[01:30] <cjwatson> I wouldn't be absolutely certain of it since some things in Essential are kind of weird.  Try it. :-)
[01:31] <infinity> For now, I'm just going to add packages to make my hand-crafted chroot match the current status quo.  But it would be nice for =buildd to actually match policy, I think.
[01:31] <cjwatson> It wouldn't surprise me if you ran into some trouble with the virtual-Essential awk.
[01:31] <infinity> I think something else in Essential has a mawk|awk Dependency to fix that.
[01:31] <infinity> If I recall.
[01:31] <infinity> Otherwise, we'd always pull gawk (which we don't).
[01:32] <cjwatson> I don't recall about Debian, but Ubuntu just has mawk explicitly in the required seed.
[01:33] <cjwatson> That causes Priority: required and debootstrap takes it from there.
[01:33] <infinity> Hr, yeah, apt-cache rdepends tells me I'm a liar.
[01:33] <infinity> Maybe I'm living a decade in the past.
[01:33] <infinity> Happens a lot. :P
[01:34] <cjwatson> I suspect in Debian it's just done by manual overrides.
[01:34] <infinity> Yeah, mawk is required in Debian.
[01:35] <infinity> But required, in neither distribution, would solve the trying to resolve Essential thing.
[01:35] <infinity> I'll have to try it out when I care more.
[01:35] <infinity> It's been like this for 6 years, according to the debootstrap changelog, obviously no one's cared that it's not compliant.
[01:36] <infinity> (I always used to hand-decruft my chroots, and never really bothered to look at why I had to)
[01:36] <broder> seems like at this point whatever debootstrap is doing has become de facto policy
[01:37] <infinity> I suppose rewriting that portion of Debian policy to declade Build-Essential as required+Build-Essential would be the path of least resistance, but it still leaves a bad taste in my mouth. :P
[01:38] <infinity> (and other than one FTBFS for a missing locales, I haven't noticed much abuse of the actual policy definition)
[01:39] <infinity> Mostly by luck, I'm sure, since the delta between Essential and required doesn't really give you many more toys to play with.
[01:58] <infinity> siretart: Were there plans to push a multiarch libav to precise?  I vaguely recall rejecting those changes to oneiric a week or two before release. :P
[01:58] <YokoZar> bdrung: ping
[01:59] <YokoZar> bdrung: Can I use wrap-and-sort for debian/copyright files?  I have some license text that has a lot of lines going beyond 80 characters and I'd appreciate something automated here.
[02:41] <micahg> infinity: your no-change rebuilds managed to drop the installed size of a lot of stuff as well :)
[02:54] <infinity> micahg: I live to give.
[02:54] <infinity> micahg: (Older packages that hadn't been rebuilt with the pkgbinarymangler doc stripping/symlinking magic, I guess?)
[02:56] <micahg> infinity: BTW, are we at the point yet where -meta packages should work with armhf or do either meta changes need to be made or some other change?
[02:56] <infinity> micahg: -meta stuff is kinda useless until enough packages exist for germinate to give you a sane list.
[02:57] <infinity> micahg: ubuntu-meta *might* be close, all the rest would be a lost cause.
[02:57] <micahg> ok, good to know
[07:18] <siretart> infinity: that's definitly the plan. is the lack of multiarch blocking something currently?
[07:22] <infinity> siretart: Nope, was just curious as I was building the oneiric version on my shiny new port. ;)
[07:22] <infinity> siretart: And I thought "hey, wasn't I supposed to have a new version in precise after it opened?"
[07:40] <siretart> infinity: right. but keep in mind that even if in debian, the package still depends on libraries that are not converted yet
[07:45] <infinity> siretart: I suspect we can fix that. :)
[07:45] <infinity> siretart: But no rush, either.
[07:45] <infinity> siretart: Like I said, I just remembered our near-release conversation and the rejected upload.
[07:49] <siretart> infinity: yeah, it's just a matter of reverting the revert in git. I just didn't get to it yet
[07:50] <siretart> infinity: currently sorting out the details for 3 CVE candidates in libav :-/
[08:02] <infinity> micahg: Hey, it's a weekend, stop uploading.
[08:02] <micahg> infinity: you first :P
[08:02] <infinity> micahg: (Besides, December is infinity month on -changes, didn't you get the memo?)
[08:03] <micahg> infinity: heh
[08:04] <micahg> luckily, so to speak,  I don't have time to fix the bigger stuff like chromium this weekend
[08:05] <infinity> Yeah.  I'm still mulling over putting in Real Work and fixing libicudata tomorrow, but I think I'll do the same thing and keep that particular aneurism for Monday.
[08:05] <infinity> s/same/sane/
[08:05] <micahg> infinity: so the real contest is can someone on the +1 maintenance team get more uploads than you this month :D
[08:07] <micahg> infinity: wow 295 and we're on Day 4 now :)
[08:07] <infinity> micahg: Not if I keep uploading (and I will).
[08:07] <infinity> micahg: On the other hand, I'm taking the entire second half of the month off.
[08:07] <infinity> micahg: So... Someone could catch up!
[08:08] <micahg> infinity: you're still almost 1200 uploads behind cjwatson
[08:08] <infinity> micahg: For the release?
[08:08] <micahg> yeah
[08:08] <infinity> micahg: He's had a few transitions ahead of me while I was bootstrapping. :/
[08:08] <infinity> micahg: I cry foul, I did those transitions in-situ on armhf!
[08:09] <micahg> heh, 'tis will be a fun release :)
[08:11] <micahg> anyways, I think I'm done for the night, so the buildds are all yours :)
[08:11] <infinity> They've been all mine all weekend.
[08:11] <infinity> And well into the week, I suspect.
[08:11] <infinity> Poor things.
[08:14] <micahg> I just saw the armhf FTBFS page, and I think I'll go back to ignoring it until the current queue is done
[08:15] <infinity> micahg: It's in pretty good shape, if you ignore the dep-waits.
[08:15] <infinity> micahg: And I'm unsnagging those.
[08:15] <micahg> well, I only have depwaits or meta packages in there (or stuff already failing on existing archs)
[08:15] <infinity> micahg: I have two recurring FTBFS issues I need to fix (libicudata, and a broken libc header), but the rest is pretty mundane.
[08:16] <infinity> micahg: And MOST of the current failures aren't ARM specific.  format-security and such.
[08:16] <infinity> micahg: Look at armhf as a free rebuild test for everyone.
[08:18] <micahg> infinity: yeah, the armel rebuild test last cycle caught some nice changes in various packages that affected all archs (include the -lm last minute gtk change)
[08:18] <infinity> micahg: Which is back, BTW, so -lm fixes all 'round for precise.
[08:19] <micahg> yeah, I think most of them got into Debian already
[08:19] <infinity> format-security seems to be more common than -lm issues right now, though.
[08:19] <infinity> As a member of the security team, you should fix all those. :P
[08:19] <infinity> 15 or 20 of the current armhf failures are format-securityt.
[08:19] <infinity> Maybe more.
[08:19] <infinity> I've lost count.
[08:19] <micahg> infinity: I fixes a few earlier this cycle, will probably do more later this month
[08:19] <micahg> *fixed
[17:01] <tomreyn> hi, to get the security team learn about a security bug, all i need to do is to report the bug and check the option to mark it as security related (which then causes the security contact to be subscribed to the bug)? Or is there anything else one needs to do? And what time frame should be expected until such a bug is first responded to?
[17:07] <Ampelbein> tomreyn: That's the correct way. For packages in main you should receive a reply on short notice, for packages in universe it may take longer.
[17:10] <tomreyn> thanks, that's good to have reconfirmed, but also not very specific. would 10 days rather fit 'shorter' or 'longer'?
[17:11] <tomreyn> oh it's indeed about universe, so it may take a while
[17:13] <Ampelbein> You could poke the folks in #ubuntu-hardened about it
[17:14] <tomreyn> it's not too severe so i guess i'll just wait.
[17:28] <JanC> tomreyn: if you have a well-tested(!) patch ready to fix it, poking people in #ubuntu-hardened might still help
[17:30] <JanC> if there exists no patch, it might be more useful to contact upstream
[17:35] <tomreyn> upstream knows, but i don't expect much to come out of it.
[17:35] <tomreyn> (and i have no patch)
[21:31] <ntr0py> I need some help building/creating a new debian/ubuntu package: Is someone here willing to help?
[21:57] <YokoZar> If a multiarch: allowed package depends on a non-multiarch package, what happens?  Does apt not let it install?  Does it show up in software center?
[21:57]  * YokoZar is considering the implications of having -extras and commercial be all Multiarch:Allowed for binary packages
[22:03] <SpamapS> YokoZar: if one of its dependencies isn't Multi-Arch: same then you won't be able to have two arches installed at once.
[22:04] <YokoZar> SpamapS: If one of its dependencies has no multiarch field at all, it'll just give up though rather than try to reinstall half the system into a diff arch right?
[22:07] <SpamapS> YokoZar: thats the idea yes, I believe sometimes it does the wrong thing and tries to remove libc-bin ..
[22:07] <SpamapS> YokoZar: so probably best to be conservative
[23:54] <doko> are you aware of the cyclic kde b-d?
[23:55] <doko> infinity, ^^^
[23:57] <Riddell> doko: which?
[23:58] <doko> kde-runtime:
[23:58] <doko> The following packages have unmet dependencies:
[23:58] <doko>  kdelibs5-plugins : Depends: katepart but it is not installable
[23:58] <doko> E: Unable to correct problems, you have held broken packages.
[23:58] <doko> apt-get failed.