[04:08] <tsimonq2> Could a MOTU please take a look at bug 1703307 and upload the package to zesty-proposed to start the SRU process?
[04:25] <tsimonq2> Could someone also nominate bug 1690416 for Xenial and Trusty please?
[06:03] <infinity> juliank: Can you gimme a poke when you're around?
[06:04] <infinity> juliank: Also, is it an intentional change that repositories without Release files are now considered invalid?  That's a pretty major behaviour change.
[06:08] <juliank> infinity: As the news said, apt-get now also requires explictly setting allow-insecure-repositories
[06:08] <juliank> Then they work just fine
[06:09] <juliank> (with warnings)
[06:10] <infinity> juliank: Ahh.  Yeah, looks like [trusted=yes] works (I think suggesting people set the apt.conf option is irresponsible, as that allows ALL sources to be insecure, not just the one I know I trust)
[06:10] <juliank> All other apt frontends already worked that way for some time, it's just the switch now being toggled around for apt-get to
[06:10] <juliank> s/to/too/
[06:15] <infinity> juliank: To be fair, applying that policy to file:/ and copy:/ URIs (which is where I just had to add a trusted=yes to fix d-i) seems a bit busted.
[06:15] <infinity> juliank: I mean, sure, someone could hack my local filesystem and all, but I feel like I have bigger problems if I can't trust a local repo.
[06:15] <juliank> Well, maybe you use some partial mirroring tool, or it's on an NFS share, or whatever
[06:16] <infinity> Yeah, I suppose.
[06:32] <juliank> infinity: (re poke) Is there something else you wanted to discuss, or just that? I'm a bit slow right now, as I basically just woke up (brain is about to get carbs any minute now) :)
[06:34]  * juliank woke up figuring out if he actually wanted to get up or not, and then saw the messages and decided to actually get up.
[06:48] <infinity> juliank: That was it.  Just being grumpy because you made me do work. ;)
[06:49] <juliank> Ah, OK; the 'also' made me think it might be two separate things :)
[06:50] <juliank> infinity: You are not the first one, we also broke siduction's ISO building, or whatever
[07:45] <LocutusOfBorg> hello Adri2000 seems that _rene_ wants to team upload libfilezilla (see #debian-release channel)
[07:47] <Adri2000> LocutusOfBorg: thanks for the notice, that's ok if he has an upload ready, I don't have much time to do it myself now :/
[07:47] <LocutusOfBorg> I will do it, and upgrade to the latest release
[07:49] <Adri2000> thanks
[08:06] <ricotz> hello, are there plans to pick up boost 1.64 for artful?
[08:56] <LocutusOfBorg> ricotz, maybe you need to talk with xnox :)
[08:57] <xnox> ricotz, is there a need for 1.64?
[08:57] <xnox> i'd rather not go ahead of debian.
[08:57] <xnox> 62 is currently default, with 63 available
[08:58] <ricotz> xnox, not yet, I guess, currently libreoffice internally defaults to 1.63, but with 1.64 already available seems better to push for that
[08:59] <ricotz> so avoiding to do two transitions
[08:59] <ricotz> of course debian should update to 1.64 too
[08:59] <ricotz> xnox, I guess you are the right person to ask for a MIR of libboost-locale-dev
[09:00] <xnox> ricotz, it doesn't need an mir.
[09:00] <xnox> ricotz, you should simply poke archive admin to promote that binary if something needs it. E.g. ask infinity.
[09:00] <ricotz> ah, than just an component switch of those binaries
[09:00] <xnox> yes, boost itself is in main.
[09:00] <xnox> unfortunately.
[09:00] <ricotz> I see, libreoffice 5.4.0 will require it
[09:01] <xnox> so when that is uploaded, it will be highlighted in components missmatches, and then we promote things.
[09:01] <ricotz> I see
[09:01] <xnox> boost binaries move between main-universe a lot, depending on what we end up shipping in the distro.
[09:02] <xnox> ricotz, also if libboost-locale-dev is headers only, it needs not any promotion. can't remember if locale-dev is or isn't header/template only.
[09:02] <xnox> however things should be declaring built-using, but whatever.
[09:02] <ricotz> it has a library too
[09:03] <xnox> ack, so it will be a normal promotion of that library package to main.
[09:03] <xnox> debian might go with with 1.65 transition and just skip 1.64 to be honest.
[09:03] <seb128> cyphermox_, xnox, slangasek, hey, any news about the nplan/n-m issue?
[09:03] <ricotz> xnox, ok, I guess this mean artful will stay with 1.62
[09:16] <bdrung_work> Trevinho, regarding the mouse click event: i am currently testing the system with a different mouse. no issues so far.
[09:47] <xnox> Laney, is transition tracker ok? e.g. from http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html ocaml-melt and ocamlviz are not installable on amd64, but they seem like they are to me.
[09:47] <xnox> or maybe i am missing something.
[09:48] <LocutusOfBorg> xnox, they are both green here
[09:48] <LocutusOfBorg> cache?
[09:49] <xnox> LocutusOfBorg, ah, that! thanks
[09:49] <xnox> problem between the keyboard and chair
[09:49] <xnox> symptoms to be fixed with coffee
[09:49] <Laney> ._.
[09:50] <LocutusOfBorg> xnox, I'm doing a photo shot of my current t-shirt
[09:56] <LocutusOfBorg> http://imgur.com/e8GUJer
[09:56] <LocutusOfBorg> xnox, ^^ :)
[10:28] <Zta77> Hi. I'm having trouble building a package from source, perhaps someone could help, please?  I'm doing the build inside a docker container so my system isn't soiled with all sorts of weird dependencies. Here's a self-contained Dockerfile: https://pastebin.com/wutSLrWq And this is how to test it, ie. make it build (and fail): docker build -t aseprite .   Not that this builds fine when invoken the plain cmake/make commands (also specified in Dockerfile)
[10:30] <Zta77> 2 minutes and I'll post the error message =) ..
[10:38] <Zta77> https://pastebin.com/zatpVKhN
[10:46] <cjwatson> Zta77: You should really regard the packaging as (at least mostly) source code, rather than something you generate with dh_make; dh_make is usually at best only useful as a guideline.
[10:46] <cjwatson> Zta77: Anyway, I think the actual error is above what you cut off in that paste.
[10:49] <Zta77> I'm rebuilding now; I'll paste a complete error code if possible.  Perhaps there's more info further up in the scroll buffer.
[10:50] <Zta77> I basically want to git clone some source and build a .deb that I can install later.  I will start from scratch when I want to build an updated version (i.e. start a new docker container).
[10:52] <Zta77> cjwatson: There's more here: https://pastebin.com/VBicjBHa
[10:53] <cjwatson> Zta77: Looks like missing Build-Depends: pkg-config
[10:53] <cjwatson> Possibly others
[10:54] <Zta77> Thanks, I'll try adding them and rebuild.
[10:54] <cjwatson> (Also slightly odd that you're installing sbuild in your container but not actually using it, so with what you have at the moment you'd also need to specify additional build-dependencies in the Dockerfile)
[10:54] <cjwatson> Oh, and that error about -DCMAKE_BUILD_TYPE=None looks suspicious
[10:54] <cjwatson> Hm, no, that's debhelper's default
[10:55] <cjwatson> You might need to add -DCMAKE_BUILD_TYPE=Release or something like that
[10:55] <cjwatson> Which would go in override_dh_auto_configure
[10:56] <Zta77> (I think sbuild is a left over from another experiment where I was building locally on my own machine)
[10:56] <Zta77> Right.  What was the first Build-Depends you mentioned? I lost my history..
[10:56] <cjwatson> pkg-config
[10:57] <cjwatson> That's not the actual fatal error in this case (the fatal error appears to be about CMAKE_BUILD_TYPE), but I expect you'll run into it later anyway
[11:07] <Zta77> Isn't it weird that the build succeeds if run with plain cmake/make but fails when invoked though dpkg-buildpackage ?
[11:08] <cjwatson> Zta77: Not particularly, because debhelper (used via debian/rules) supplies a bunch of cmake defaults
[11:09] <cjwatson> Zta77: One of those is -DCMAKE_BUILD_TYPE=None, which apparently the embedded libarchive doesn't like
[11:09] <cjwatson> Zta77: See /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
[11:10] <cjwatson> Zta77: Like I say you can override that by adding parameters after "dh_auto_configure --"
[11:13] <cjwatson> (I think -DCMAKE_BUILD_TYPE=RelWithDebInfo is actually a better override)
[11:13] <cjwatson> See https://bugs.debian.org/701233 for the history here
[11:18] <Zta77> Now I'm getting somewhere! It's building.
[11:19] <Zta77> Using RelWithDebInfo
[11:53] <Zta77> cjwatson: So the build actually completes .. and then it fails =) Any idea what could be going on here? https://pastebin.com/Ngs7FABP
[11:54] <cjwatson> Zta77: Packages shouldn't install stuff into /usr/local
[11:55] <cjwatson> Zta77: You should be using /usr as the prefix
[11:56] <cjwatson> Zta77: If you reeeeeeeeeeally don't want to comply with that, you should (a) reconsider (b) if you still don't want to, override dh_usrlocal to do nothing
[11:56] <Zta77> Oh, I was just about to ask if this could be related to my custom prefix
[11:57] <Zta77> how do I override dh_usrlocal ?
[11:58] <Zta77> I'd like to be able to install my package side-by-side with the official package.
[11:58] <cjwatson> I don't really want to teach you the details because I think you are on a mistaken route
[11:58] <cjwatson> But if you really want to you can read "man dh" (which gives general advice on how to override debhelper commands)
[11:59] <cjwatson> There's a "Here is a way to prevent dh from running several commands that you don't want it to run" section
[11:59] <cjwatson> It's worth learning how overrides work anyway: it's easy and regular
[11:59] <Zta77> This whole project is a mistaken route.
[12:00] <cjwatson> :)
[12:03] <Zta77> But I'm learning docker, learning a but about .deb, learning how to populate a repository, and getting the latest build of aseprite. So it's not all bad.
[13:37] <coreycb> apw: hello, if you have some cycles, could you review a few openstack SRU uploads for me?  In the queue I have libvirt for zesty/xenial, and python-cinderclient/python-openstackclient for xenial.
[13:45] <apw> coreycb, are these two identicle in the zesty queue ?
[13:46] <apw> coreycb, and the same question for xenial
[13:47] <coreycb> apw: for libvirt there should be 2 uploads for zesty and 2 for xenial, of which the older ones can be rejected
[13:51] <apw> coreycb, there is already a libvirt in zesty-proposed
[13:51] <apw> are we replacing that ?
[13:58] <cpaelzer> coreycb: is that the update to have both rules?
[13:59] <coreycb> cpaelzer: yes
[13:59] <cpaelzer> coreycb: did you change the changelog - since I prefeched that into my merge and want history to be correct
[13:59] <coreycb> apw: checking
[13:59] <coreycb> cpaelzer: here's the zesty upload - http://launchpadlibrarian.net/327345846/libvirt_2.5.0-3ubuntu5.2_2.5.0-3ubuntu5.3.diff.gz
[14:00] <cpaelzer> ok thats the odl message - I'm good then
[14:01] <coreycb> cpaelzer: you probably want to release 5.2 rather than having the 5.3 version replace it, right?
[14:01] <coreycb> cpaelzer: in zesty-proposed
[14:01] <cpaelzer> coreycb: yeah 5.2 is in proposed quite a while now
[14:01] <cpaelzer> I'd prefer to not restart its amturing cycle
[14:03] <coreycb> apw: it looks like 5.2 is verified, perhaps we can release that to updates and accept 5.3 into proposed?
[14:03] <coreycb> cpaelzer: ^
[14:04] <apw> coreycb, ok its not marked verified according to the reports, i think they may have used the wrong tag form
[14:04] <cpaelzer> verification-zesty-done since 22. June
[14:05] <cpaelzer> there was the global change by sil2100 - maybe affected by that in some way
[14:05] <cpaelzer> apw: ^^
[14:05] <apw> i think the form is verification-done-zesty ...
[14:05] <sil2100> Yeah, it's verification-done-zesty as apw says ;)
[14:06] <cpaelzer> well I added the wrong way before you added it :-)
[14:06] <apw> cpaelzer, if you could flip that (too dangerous to overlap with you)
[14:06] <apw> then we can indeed release this one
[14:07] <coreycb> apw: cpaelzer: thanks
[14:07] <cpaelzer> apw: I corrected the tag
[14:11] <apw> cpaelzer, coreycb, ok that one released
[14:11] <cpaelzer> thanks apw
[14:11] <coreycb> apw: thanks
[14:11] <apw> i'll come back to the new one once the world notices
[14:45] <willcooke> mbiebl_, hi.  I copied  (more or less)  your patch for disabling bluetooth audio in gdm for Ubuntu, I wondering if it's likely to land in Debian soon, or did you decide that the a11y impact was too great?
[14:45] <willcooke> rdiff in question: https://paste.debian.net/975780/
[15:57] <seb128> cyphermox_, slangasek, xnox, hey again, sorry to nag but is annoying working on unblock that n-m update?
[15:57] <cyphermox_> yes, annoying is working on unblocking that
[15:58] <cyphermox_> fwiw, I told jbicha two weeks ago that it was a NM regression
[15:58] <cyphermox_> I think I can work around it in nplan, working on that right now
[16:40] <dmj_s76> Given the recent discovery of skylake/kabylake hyperthreading problems, could we get the latest intel-microcode backported to xenial?  That should fix the issue on a sizeable percentage of systems.
[16:40] <nacc> dmj_s76: LP: #1700373
[16:48] <dmj_s76> nacc: Thanks
[16:48] <nacc> dmj_s76: yw
[17:59] <bdrung_work> Trevinho, after one day use, i can say that the unwanted click events were caused by broken hardware
[19:55] <juliank> Seems like seviper's smtp does not speak TLS? gmail shows annoying red crossed-out locks for ubuntu-devel mails :(
[21:39] <Trevinho> bdrung_work: sad to hear for you, but also good for us :-D