[00:16] <bigon> what was the process again to ask for the pkg removal from ubuntu?
[00:18] <bigon> tyhicks: I see that you fix the build of https://launchpad.net/ubuntu/+source/refpolicy-ubuntu/ shouldn't the package be removed instead?
[00:20]  * tyhicks scratches his head
[00:20] <tyhicks> ha, that's why I don't remember fixing that
[00:20] <tyhicks> Wed, 18 Apr 2012
[00:21] <mwhudson> bigon: file a bug on the package asking for it's removal and subscribe ~ubuntu-archive
[00:21] <mwhudson> *its
[00:21] <bigon> thebwt: oh I saw 2016, but that when the archive for Yakkety Yak has been open I guess
[00:22] <bigon> thx
[00:23] <tyhicks> bigon: if we remove that, what is the replacement? selinux-policy-default?
[00:24] <bigon> probably
[00:24] <bigon> I'm pretty sure that the -ubuntu selinux policy is broken (no systemd support)
[00:24] <bigon> but it is probably broken for other stuffs too in the previous version
[00:26] <bigon> not sure that the current policy in debian is in better shape
[00:28] <tyhicks> bigon: yeah, I also expect it to be pretty broken
[00:29] <bigon> the one in debian is more or less my fault :p
[00:33] <psusi> pitti, have you spoken with Lenart at all lately?  it seems that libatasmart has not been updated upstream in 2 years and this patch has been waiting to be applied there for 3 years... is the upstream dead? https://bugs.freedesktop.org/show_bug.cgi?id=61998
[04:49] <tjaalton> I have DEB_BUILD_OPTIONS='parallel=8 noddebs' but sbuild still builds dbgsym packages, what's wrong?
[05:58] <pitti> Good morning
[05:58] <pitti> psivaa: I speak to Lennart a lot, but not about libatasmart -- this project is indeed unmaintained
[06:13] <pitti> @pilot in
[06:16] <seb128> pitti \o/
[06:28] <cpaelzer> good morning
[06:44] <cpaelzer> I guess the answer is no, but I might miss something. Does Launchpad on top of git also have some sort of integrated patch-review like gerrit/patchwork ?
[06:45] <cpaelzer> hmm, for bzr that is eventually on the merge step, let me see if there is a git merge ...
[06:46] <sarnold> there's this.. https://answers.launchpad.net/launchpad/+question/267929
[06:47] <cpaelzer> sarnold: thansk, reading through it
[07:07] <TJ-> is there a way to build a package using dh_auto_build that can have it use two Makefile targets, one after the other?
[07:22] <pitti> juliank: now that we have apt finally in sync, could you rather apply the patch in bug 1573547 straight at the Debian side? (looks good enough to me)
[07:27] <ricotz> hello, did dpkg-source 1.18.7 got stricter about appearing binary files (e.g. *.pyc) while creating a source-package? 1.18.4 worked/works
[07:55] <juliank> pitti: I have a pull request in github pending for that sort of thing (https://github.com/Debian/apt/pull/13/files), and it and the attached patch are both somewhat wrong
[07:55] <juliank> That is, build-dep can also take source package names, and takes folders, not .deb files
[07:56] <juliank> I think I'm going to do it myself, as the PR/patch submitters RTT gets a bit too high otherwise
[08:05] <juliank> pitti: It's also still missing options like -t/--target-release but I'm not really sure where to apply them
[08:08] <pitti> juliank: ah, thanks; so I won't apply this for now either
[08:11] <juliank> pitti: Should I add a apt moo completion ;)
[08:11] <pitti> juliank: what? that doesn't exist yet???
[08:11]  * pitti files an RC bug
[08:11] <pitti> "no apt is complete without completion for moo"
[08:13] <sil2100> cjwatson: hey! Frequently in the last few days certain touch builds are failing on cdimage due to 503 errors while fetching files from livefs - do you know anything about it?
[08:13] <sil2100> In the last two days it happened over three times now
[08:23] <pitti> @pilot out
[08:39] <juliank> pitti: This one seems really complete now: https://github.com/julian-klode/apt/commit/3dacc9806f1d51e0b963e2bca2be4d8f66e586df
[08:41] <juliank> pitti: Would be nice if you could take a quick look, maybe I made a silly mistake somewhere
[08:41] <juliank> typo, for example
[08:42] <pitti> moo!
[08:43] <juliank> pitti: I should count the number of moos to not suggest more moos than apt supports
[08:43] <pitti> juliank: around line 35, this uses $GENERIC_APT_GET_OPTIONS" but repeats a lot of the options again; this looks a bit weird?
[08:45] <pitti> same in line 144 (--target-release at least)
[08:45] <pitti> I suppose duplicates don't hurt, but I wonder whether these commands really support all options and thus should actually include GENERIC_A_G_O
[08:45] <juliank> pitti: Yeah, well, we do want to move them to more specific commands at some point anyway, I just added the entire list of options (for all apt-get style commands) there to catch them all
[08:46] <pitti> juliank: ack; looks good to me otherwise, many thanks!
[08:46] <juliank> pitti: The variable contains all the options our apt-get parser supports for all commands. This might not mean they are actually useable in there, but we have not really checked yet, I suppose (the parser code contains: // FIXME: move to the correct command(s))
[08:47] <pitti> juliank: that seems fine; there's only so much logic one should repeat in the completion :)
[08:47] <juliank> What I'd love to have is offer suggestions for --target-release, but I have not yet found a way to do so
[08:48] <juliank> So -t <TAB> gives you xenial,xenial-something,etc.
[08:48] <juliank> same for -t<TAB>
[08:48] <pitti> juliank: i. e. collect the series from /e/a/sources.list{,.d/*}?
[08:48] <pitti> that involves quite a bit of parsing indeed
[08:49] <juliank> Or from apt-cache policy output the a= and n= fields, although it's not that parseable in case they contain a comma (but why would they)
[08:49] <pitti> I wrote some parsing for sources.list with awk; it's not trivial because of the [] options, so it's not a fixed field
[08:50] <pitti> (bbl)
[08:50] <juliank> $(apt-cache policy | egrep -o 'a=[^,]*|n=[^,]*' | cut -f2 -d= | sort -u )
[08:50] <juliank> Should suffice
[08:51] <juliank> The question is more how to integrate that into the bash completion so both -t<TAB> and -t <TAB> are completed
[08:58] <juliank> I think I've got it working
[09:00] <LocutusOfBorg> thanks pitti for cmake
[09:03] <juliank> pitti: https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=5aba189
[09:06] <juliank> oh build-dep misses directory support (directory containing a debian/control file)
[09:08] <juliank> Hmm, I wish we could also have completion for pkg=version and pkg/distribution
[09:09] <juliank> But that probably gets insane
[09:19] <pitti> juliank: \o/
[09:21] <juliank> pitti: Long term it would be nice to have a complete helper inside the apt binaries that generates possible input. That would get rid of a lot of duplication
[09:23] <juliank> pitti: Do we also want that in xenial? If so, I'd cherry-pick that over into the 1.2.y branch
[09:24] <pitti> juliank: harmless enough I guess
[09:24] <juliank> The next 1.3~exp release is coming soonish, as I want to fix a bug WRT public key pinning (Signed-By in Release files)
[09:26] <Laney> caribou: you shall go to the ball!
[09:26] <Laney> and you can take apache 2.4.10 as your date
[09:44] <cjwatson> sil2100: do you have a sample build?
[09:45] <cjwatson> cpaelzer: right, you can just use merge proposals for git pretty much the same way that you do with bzr.  there are one or two missing features, but there are projects actively using git-based MPs.
[09:46] <sil2100> cjwatson: yeah, some example logs:
[09:46] <sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/vivid/daily-preinstalled-20160512.2.log
[09:46] <sil2100> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/xenial/daily-preinstalled-20160513.log
[09:59] <cjwatson> sil2100: I don't know of a specific cause, but 503s could just be transient load issues.  Somebody should probably try to get cdimage to backoff/retry in that case.
[10:30] <caribou> Laney: I can think of a better one but thanks ! :-D
[15:28] <nacc> slangasek: request for mind-refresh: drupal in debian/unstable is now indicating php7 support (although there's a bug in the dependencies and i've let the debian maintainer know). To sync that version down into Xenial, should I just file a new FFe/SRU bug? Trivial in the sense that our version now doesn't install and we released with this in mind?
[15:49] <slangasek> nacc: yes, new SRU bug, referencing the previous discussion in the rationale
[15:49] <hallyn> pitti: hi, libvirtd.service has "Alias=libvirt-bin.service", but it doesn't seem to work:
[15:49] <hallyn> pitti: http://paste.ubuntu.com/16390766/
[15:54] <rbasak> slangasek: would you mind reviewing the upgrade path seddery in https://github.com/ltangvald/mysql-5.7/commit/f57b068c956d0792bb35cec72fee8d66b0f513c7 please? Eg. version number check, leaving a backup file behind, and the quality/coverage of the regexp.
[15:55] <nacc> slangasek: thanks!
[15:56] <slangasek> rbasak: hi, great, I'll put that in my queue to take a look at; don't know that I'll get to it today
[16:12] <rbasak> slangasek: np, thanks.
[16:25] <hallyn> coreycb: pitti: hm, maybe it's a container issue.  or an upgrade issue.  when i cleanly install libvirt 1.3.4 in a vm, 'systemctl status libvirt-bin' does work
[16:28] <coreycb> hallyn, interesting
[16:28] <hallyn> coreycb: actually i htink it's an upgrade issue.  might be something i'm doing in the postinst in upgrade case
[16:29] <hallyn> but i'd really prefer that we update all userspace to use libvirtd whe nneeded so that at 18.04 we dont' have this issue again :)
[16:35] <coreycb> hallyn, I agree.  I'll sync with james on Mon.  but for now it sounds like I can upload nova with the original group fix only.
[16:39] <drab> hi any ubiquity developers around? trying to track down a possible bug with dhcp hostname setup
[16:39] <hallyn> coreycb: awesome, please do.
[16:39] <hallyn> coreycb: uh, do you want to show me the fix you have real quick? :)
[16:40] <hallyn> pastebin debdiff?
[16:40] <coreycb> hallyn, sure, that wouldn't be a bad idea :)
[16:40] <drab> if I install the sever version with the text installer the hostname is correctly set to what dhcp sends, but the same preseed file for a desktop version sets the hostname to "computer", which is what I have for d-i netcfg/get_hostname
[16:41] <drab> it seems to me that ought to depend on ubiquity, but not 100% sure, still, no desktop is getting its hostname right
[16:41] <coreycb> hallyn, http://paste.ubuntu.com/16392244/
[16:42] <hallyn> coreycb: uh.  hm.  is that test what you really want?
[16:42] <hallyn> or do you want '[ -n "$libvirt_group" ]' or something like that?
[16:42] <hallyn> hm, suppose it works
[16:43] <hallyn> ignore me
[16:43] <coreycb> hallyn, good news is I just installed the package on yakkety and it installs fine
[16:43] <coreycb> hallyn, ok ignoring and uploading then :)
[16:43] <hallyn> thanks :)  ttyl
[16:50] <BrAsS_mOnKeY> hello ;)
[17:06] <xnox> infinity, slangasek - no change rebuild of d-i failed on i386/amd64 with mcopy talking about cylinders, sectors and tracks (no idea what any of those things are, is it related to floppy drives?!)
[17:06] <xnox> mcopy -i./tmp/hd-media/boot.img ./tmp/hd-media/vmlinuz ::linux
[17:06] <xnox> Total number of sectors (1603584) not a multiple of sectors per track (63)!
[17:06] <xnox> Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
[17:06] <xnox> not sure what to do about that. bump sizes somewhere and/or trump/ignore the error?
[17:07] <infinity> xnox: Looking.
[17:07] <infinity> xnox: It's going to be the new dosfstools, but I'll sort out what needs fixing.
[17:22] <drab> any hint of what sets the hostname in an ubiquity autmatic installation? I'm looking at the code but can't find it
[17:22] <drab> there's a d-i/source/netcfg that i'm looking at, but its purpose does not seem to set the hostname for the install
[17:22] <drab> just to get the instance up and running
[17:27] <infinity> xnox: Fix committed/uploaded.
[17:28] <xnox> infinity, thank you! you are a star =)
[17:28] <infinity> xnox: Well, in this case, it had already been argued about and worked around in Debian. ;)
[17:28] <infinity> (But I tested locally to make sure it fixed it for us too, before uploading)
[17:28] <drab> actually nm, it's there, in netcfg_activate_dhcp(...), can't figure out why it's failing tho
[17:29] <xnox> drab, one moment.
[17:29] <xnox> drab, netcfg/get_hostname=myhostname on the kernel command line should do the trick
[17:29] <xnox> or d-i netcfg/get_hostname string myhostname in the pressed file as usual.
[17:30] <drab> sure, I've got all the moments, I need to figure this one out cuz I need to deploy a large fleet of desktops and bad hostname is breaking the rest
[17:30] <drab> xnox: I already have that and it's using it, but that's not what it's supposed to do
[17:30] <drab> per comment in the seed file itself, DHCP hsotname is supposed to take precedence
[17:30] <drab> and the dhcp server is sending that
[17:31] <drab> I see that in casper.log
[17:31] <drab> so the client is getting it, no questions about that
[17:31] <drab> and ubuntu server is doing the right thing and setting /etc/hostname to it
[17:31] <drab> but ubuntu dekstop xenial is not, even tho ubiquity installer is supposed to do anothing about netcfg (per wiki page)
[17:32] <drab> so I'm lost why the same version of d-i would work on server version but not desktop version to set the hostname from dhcp correctly
[17:32] <infinity> Because ubiquity is only sort of d-i.
[17:32] <infinity> And doesn't quite follow all the same codepaths.  Annoyingly.
[17:33] <drab> right, but isn't it supposed to be using d-i? it's in the repo and the wiki says "we leave d-i alone for a bunch of stuff, including netcfg"
[17:33] <drab> maybe I misunderstood the meaning of that
[17:34] <infinity> If I were setting up a d-i netboot infra for a mixed desktop/server environment, I wouldn't use the ISOs at all, I'd just netboot and change the task selection based on the target type.
[17:34] <drab> the only thing I can think of is that NetworkManager is getting in the way
[17:34] <drab> infinity: I was considering that and may just do that after all, I have the mini iso setup in pxe already
[17:35] <infinity> drab: Wouldn't even use the mini.  If you're PXEing, I'd just use the netboot kernel/initrd and a preseed.
[17:35] <infinity> drab: But whatever works for you.
[17:35] <drab> infinity: ok, will try that out, thank you
[17:36] <infinity> drab: The tasks you want are: "minimal" "standard", and "ubuntu{-server,-desktop}" (depending on target).
[17:38] <infinity> drab: Or if you're doing it based on packages instead of tasks, ubuntu-minimal, ubuntu-standard, and ubuntu-{desktop,server}.
[17:38] <drab> infinity: what if I want to setup something like lubuntu? I've seen metapackages for those, like lubuntu-desktop, would the netboot still work with that?
[17:38] <drab> I ahve some old machines I need to use lubuntu for
[17:38] <infinity> drab: Yup!
[17:38] <drab> cool, ok
[17:38] <drab> thank you very much
[17:38] <infinity> drab: minimal, standard, and lubuntu-desktop
[17:39] <infinity> drab: You can probably see a pattern here. ;)
[17:41] <drab> :)
[17:44] <infinity> drab: By all means, don't let me talk you out of submitting bugs/patches for ubiquity preseeding, but it'll always be annoyingly a bit different from a pure d-i environment.
[17:45] <infinity> drab: So, in your case, if you're deploying server, desktop (and other desktops), you'll probably lose less hair by using the same installer for everything and just tweaking the one task selection line in your preseeds.
[17:46] <infinity> (Note: it will be slower, though, since d-i netboot uses debootstrap for the inital rootfs, rather than blatting out a squashfs like the ISOs do).
[17:49] <drab> infinity: yeah, that was one of my worries, I was actually thinking of baking my own isos with a whole bunch of stuff we wanna ship
[17:49] <drab> I might just abandon the whole quest to get the hostname right at install time and just patch it up with ansible after the fact
[17:49] <drab> that may be faster overall
[17:49] <drab> but will test
[17:49] <drab> thanks again
[17:56] <Unit193> 1. Is there any reason Contents-foo.xz files aren't in the component sections like in Debian/all other repos?  2. It should function to use 'devel' in the changelog, but is that actually acceptable for an upload?
[17:58] <cjwatson> Unit193: 1. https://bugs.launchpad.net/launchpad/+bug/1579372  2. yes
[17:59] <drab> also any chance people around here have thoughts on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1370707 ?
[18:00] <drab> most of the people I'm setting up these labs for are windows users at home (small non profit) and they are freaking out at the initial blank screen, thinking the computer is broken
[18:00] <Unit193> cjwatson: Well dang, I didn't see that.  I'm sorry.  Thanks very much.  And wow, that's awesome!
[18:00] <drab> I've tried the framebuffer=y thing, but all I get is a blue screen (testing lubuntu) and no progress dots etc
[18:01] <cjwatson> Unit193: np, we should sort it out but it will probably take a while
[18:02] <Unit193> Very understandable, you're changing the archive structure (however little it may be.)  I'd expect that.
[18:05] <Unit193> That also helps, shows me I should change how my Contents files are generated. >_>
[18:30] <stgraber> pitti: hey, I've got about 300 systems reporting a critical package error (nagios) because you removed a package from trusty-updates (libnl3). That's something I'd expect for broken -proposed packages, but not for -updates.
[18:31] <stgraber> I now manually downgraded all those systems to the previous version, but it may have been better to upload the old source with a higher version number directly to -updates rather than just removing the package.
[18:32] <stgraber> (my monitoring system detected that case but I'm guessing most of our users aren't so lucky and will just end up with the broken version installed on their system not knowing that they should downgrade)
[18:51] <infinity> stgraber: Erk, we're never supposed to just remove things from updates.  Where did this happen?
[18:52] <ogra_> also, wouldnt you get a y/n question during dist-upgrade for that even if it happened ?
[18:52] <ogra_> (better dont have your scripts blindly apply -y .... )
[19:02] <infinity> stgraber: Okay, after looking at history, I'm going to upload a -1ubuntu1.1 that's a rever of -1ubuntu1, promote it immediately, and then a -1ubuntu2 that's -1ubuntu1 with a Breaks on network-manager.
[19:02] <infinity> stgraber: Concur that that's a sane path?
[19:02] <infinity> s/rever/revert/
[19:03] <stgraber> sounds reasonable I think, yeah
[19:03] <infinity> stgraber: Will be landing both in the queue shortly, if you want to review.
[19:03] <stgraber> at least the uploading a revert as ubuntu1.1 part, I'm not sure what the change actually was, I just know it got removed :)
[19:04] <stgraber> infinity: ok, I'll at least look at the revert one, should be easy enough to confirm it's sane :)
[19:04] <infinity> stgraber: Ahh, so, the gist is that -1ubuntu1 broke network-manager, but there was also an n-m SRU to fix that.  But with the joy of phased updates, people are getting libnl and not n-m.
[19:04] <infinity> stgraber: Hence, kaboom.
[19:04] <nacc> ack, there's an askubuntu topic on it getting a lot of activity and a lot of complaints in #ubuntu today
[19:05] <sarnold> phasing is applied per package on an individual system?
[19:05] <stgraber> infinity: oh, fun, ok, so yeah a versioned breaks sounds good
[19:07] <infinity> stgraber: Okay, revert hitting the queue now.  We can push that through ASAP.
[19:07] <infinity> stgraber: Versioned breaks one following shortly.
[19:10] <infinity> stgraber: And versioned Breaks version uploaded too, for after we promote the revert.
[19:12] <infinity> Unconvinced that the revert is strictly necessary, and maybe we should just go with promoting the Breaks version in a hurry, but doing it this way won't hurt either.
[19:12] <infinity> New NM and old libnl should be fine.  I think.
[19:13] <infinity> (old, as in reverted)
[19:16] <infinity> sarnold: Phasing is per-package, yes, but it won't allow you to do an impossible upgrade either, so a Versioned Breaks will force either both or neither to upgrade.
[19:16] <stgraber> infinity: ok, let me check. Didn't feel like uploading to -updates directly? :)
[19:16] <infinity> stgraber: Sort of forgot I can do that.
[19:16] <infinity> stgraber: Since I haven't included a pocket in my uploads for years.
[19:16]  * infinity shrugs.
[19:17] <infinity> Not a big deal to do it this way.
[19:17] <stgraber> nah, easy enough
[19:17] <infinity> stgraber: I'll do the -ubuntu2 accept and promotion after I promote 1.1, if you pre-review the Breaks to make sure I can type.
[19:17] <sarnold> infinity: ah, that's better than I feared, but I figured if wer're annoying a user to install updates, we might as well reduce the number of times we annoy the user..
[19:17] <stgraber> I never bother putting the pocket in my uploads except for backports, but something like this, I'd have uploaded to ubuntu/xenial-updates or whatever the magic dput path is
[19:18] <stgraber> infinity: yeah, just waiting for LP to give me diffs
[19:19] <infinity> sarnold: Annoying them less and phasing are sort of opposing concepts, unless you want to take some randomness out of it and just say "these 7 people are always our canaries, totally sucks to be them".
[19:19] <infinity> sarnold: Which is both unfriendly to those 7 people and also gets us crappier testing, as we're only testing the same machines over and over.
[19:19] <stgraber> hmm, wtf, pull-lp-source isn't happy either (trying to fetch 3.2.21-1), do we have some kind of librarian slow down
[19:20] <infinity> stgraber: Dunno.  pull-lp-souce worked for me.
[19:20] <infinity> For both versions.
[19:20] <stgraber> oh, pull-lp-source is happy now
[19:20] <sarnold> infinity: I figured it was done per upgrade thing.. "oh today's my day in the 10%", and just download all the updates available at that moment
[19:20] <stgraber> infinity: looks fine, except for your english skills :)
[19:21] <infinity> stgraber: I didn't english gud?
[19:21]  * infinity looks.
[19:21] <stgraber> infinity: kinda missed a t in there :)
[19:21] <infinity> Oh.  Lolz.
[19:21] <infinity> Can reupload with the T.
[19:21] <infinity> Or not, since we'll be overriding it shortly anyway.
[19:21] <stgraber> yeah, not worth the trouble
[19:22] <rlaager> stgraber! Are you going to file this upstream: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1567557
[19:22] <rlaager> I can copy-and-paste it, but it seems like it would be better if you filed it (since you've filed upstream before) so you can participate there.
[19:22] <infinity> stgraber: Pre-review -2ubuntu2 for me too, and you can walk away from this.  I'll babysit it from here.
[19:22] <stgraber> rlaager: possibly, I'd kinda like to get a better idea of what's going on first. As an upstream myself, I hate it when people say "performance isn't good" but can't show me more.
[19:23] <stgraber> infinity: I did a straight accept on 1.1 as sru-review is confused when you have more than one of the same source in the queue, not like we care anyway since we'll bypass the rest of the SRU process anyway
[19:23] <infinity> stgraber: Yeah, I didn't put bugs in the changelogs anyway, so sru-review isn't all that helpful. :P
[19:23] <sarnold> stgraber: probably this is good enough already, it's got numbers!
[19:25] <stgraber> infinity: that's nitpicking but wouldn't you want << 0.9.8.8-0ubuntu7.3~ in theory just in case people do random backports of that stuff?
[19:26] <infinity> stgraber: Probably, but if people are backporting libnl/n-m to << trusty, I'm not sure I'm full of sympathy for their cause.
[19:27] <infinity> stgraber: I also have time to reupload though, if you want to be picky. :)
[19:28] <stgraber> infinity: nah, indeed seems unlikely anyone would be backporting all that stuff (would be more likely if it was xenial) and if they are, they'll likely need to make other changes anyway
[19:28] <stgraber> infinity: so LGTM, feel free to self-accept once the other one has been moved to -updates
[19:28] <infinity> stgraber: Too late.  I uploaded.
[19:28] <stgraber> infinity: ok, well, let me diff that one too then :)
[19:30] <stgraber> infinity: LGTM
[19:30] <infinity> stgraber: Kay, reject the one you like least, and I'll work with the other.
[19:30] <stgraber> rejected
[19:30] <infinity> stgraber: Ta.
[19:48] <teward> how hyper concerned should I be when mk-sbuild fails to create an schroot with these errors...?  http://paste.ubuntu.com/16397041/
[19:48] <teward> (trying to make a Yakkety build environment in my sbuild)
[20:34] <teward> does anyone know whether there's issues getting Yakkety to have schroots made via sbuild debootstrap at all?
[20:36] <tumbleweed> worked just fine for me (on debian)
[20:42] <teward> tumbleweed: got these odd errors on Trusty sbuild making the schroot (these don't happen on Xenial schroots): http://paste.ubuntu.com/16397041/
[20:42] <tumbleweed> is that key in the keyring?
[20:55] <infinity> teward: That's a change in apt.  The error message is pretty clear about what needs fixing.
[20:56] <teward> infinity: okay, so where do I file the bugs, or whom do I stab with a stick to fix it?
[20:56] <teward> or is there already a bug on this?
[20:56] <infinity> I might fix it right now.
[20:56] <teward> infinity: ah, okay.  let me know, because it's blocking Yakkety test builds of the horribly-evil nginx merge
[20:56] <teward> (evil in that i basically had to start 'fresh' from Debian and readd the delta >.<)
[21:04] <infinity> teward: Fix uploaded.
[21:24] <fo0bar> http://pastebin.ubuntu.com/16394359/ <-- infinity
[21:25] <fo0bar> and the whole thing is currently way too immature to get into ubuntu proper so far, since that's going to be your next question :)
[21:25] <fo0bar> but if the kernel team wants to start working on a raspi3 arm64 defconfig, that's a good first start
[21:25]  * fo0bar is currently using Some Dude's Kernel
[21:33] <infinity> fo0bar: Good ol' Some Dude.
[21:38] <fo0bar> anyway, much faster than my previous qemu arm64 486-speed env
[21:38] <fo0bar> well, maybe pentium 2
[22:07] <sarnold> "BogoMIPS	: 38.40
[22:08] <sarnold> reminds me of my old pentium :)
[22:43] <teward> infinity: I don't see the fix anywhere, did it land, or is it stuck?
[22:48] <nacc> teward: i think some folks have been reporting the fix is in trusty-updates
[22:49]  * teward checks
[22:50] <teward> nacc: either the mirrors haven't updated or that's a lie
[22:50] <nacc> teward: presuming we are talking about the same nm/libnl fix?
[22:50] <teward> nacc: ah, no, actually, apt fixes
[22:50] <nacc> teward: ah sorry!
[22:50] <sarnold> nacc: http://paste.ubuntu.com/16397041/
[22:50] <teward> [2016-05-13 16:42:09] <teward> tumbleweed: got these odd errors on Trusty sbuild making the [Yakkety] schroot (these don't happen on Xenial schroots): http://paste.ubuntu.com/16397041/
[22:51] <teward> [2016-05-13 16:55:50] <infinity> teward: That's a change in apt.  The error message is pretty clear about what needs fixing.
[22:51] <teward> nacc: though, i've pulled in those fixes now ;)
[22:51] <nacc> sarnold: thanks
[22:51] <nacc> interesting
[23:57] <infinity> teward: The fix was in ubuntu-keyring.  I assume you realized that eventually?
[23:59] <teward> infinity: just ran mk-sbuild, same breakage
[23:59] <teward> hence the original question
[23:59] <teward> but yes i realized, ubuntu-keyring
[23:59] <infinity> teward: Yeah, it's just publishing to the release pocket now.
[23:59] <infinity> teward: Patience.
[23:59] <teward> ack