=== kitterma is now known as ScottK
=== maclin1 is now known as maclin
[07:53] <weasel> moo.
[07:54] <weasel> On Debian, I'm dropping my tor-dbg package in favour of having the toolchain auto-build the -dbgsym package.
[07:54] <weasel> I notice that the toolchain on Ubuntu builds dbgsym ddebs when pkg-create-dbgsym is installed.
[07:54] <weasel> Are packages supposed to build-depend on that?
[07:55] <weasel> (/me is also building binaries for all the ubuntus for deb.torproject.org)
[07:56] <Unit193> weasel: They are not supposed to build-depend on that, and in artful and above Ubuntu is using a slightly modified debhelper to build dbgsym packages with a 'ddeb' extension.
[07:57] <weasel> ok.  So for my backport builds, the build environment is supposed to just have pkg-create-dbgsym installed?
[07:57] <weasel> how do I avoid getting almost empty .ddeb packages that aren't good for anything (and shouldn't exist) when building things that still do classic -dbg packages?
[07:59] <Unit193> Depending on the version of debhelper, you can force Debian style dbgsym packages without pkg-create-dbgsym by setting DH_BUILD_DDEBS=1, in eg .pbuilderrc.  But yes, pkg-create-dbgsym in the build-env would be fairly normal I *think*.  As far as dbgsym packages that only depend on the -dbg packages, I don't know how to skip ehtm, never looked into it.
=== apw_ is now known as apw
[08:00] <weasel> ah
[08:00] <weasel> it has a dependency on the -dbg.
[08:00] <Unit193> (For reference: https://launchpad.net/ubuntu/+source/debhelper/10.2.5ubuntu2)
[08:00] <weasel> that makes it actually useful.
[08:01] <Unit193> debhelper has also been backported to Xenial, so one could technically use the DH_BUILD_DDEBS=1 trick, but not sure that's what you're going for.)
[08:01] <weasel> well, I want to build binaries for precise, trusty, wily, xenial, yakkety, and zesty.  with the minimal amount of fuss and ugly :)
[08:02] <weasel> thanks, I think I'll figure something out.
[08:02] <Unit193> Very understandable, thanks for doing that too!
[08:02] <Unit193> You can also wait for someone that knows the subject better.
[08:02] <weasel> I guess the thing to do is make pkg-create-dbgsym be installed in anything pre-artful,
[08:03] <Unit193> Sounds like a plan.
[08:03] <weasel> and use the debian sid package unmodified.  (at least when it comes to the dbg stuff)
[08:03] <weasel> (source package, that is)
[08:05] <Unit193> The fun part may be if you mess with --dbgsym-migration..
[08:08] <weasel> I'm not sure I want to bother.
[08:08] <weasel> but yes, it's something I have thought of.
[08:20] <f_g> anybody else getting Timeout Errors when filing bugs @ LP?
[08:32] <Unit193> LocutusOfBorg: Thanks, also random:  < Unit193> I know you're no longer here, but just chef holding ruby-net-ssh back in proposed, either just a bump to allow newer, or the bump and https://github.com/chef/chef/pull/5726/commits/24d230b09a68c8b6857d060b398e779a23ba80bc would fix it.
[08:35] <LocutusOfBorg> Unit193, .
[08:35] <LocutusOfBorg> why you no MOTU?
[08:36] <Unit193> I've got a packageset...Also, I should do that one in Debian since specinfra is in. >_>
[08:37] <Unit193> (Though that has Ubuntu delta anyway, so will have to do both..)
[08:39] <LocutusOfBorg> Unit193, I can give you dm for debian, just give me a list of packages
[08:39] <LocutusOfBorg> but please apply for MOTU
[08:40] <Unit193> Will go through the normal pkg-ruby process for it, but I should look into MOTU again it seems.
[08:42] <mwhudson> omg python3-defaults migrated
=== fnordahl_ is now known as fnordahl
[08:43] <LocutusOfBorg> mwhudson, congrats!
[08:43] <LocutusOfBorg> Unit193, https://launchpad.net/ubuntu/+source/chef/12.14.60-2ubuntu4/+build/13210735
[08:45] <Unit193> LocutusOfBorg: There's no ruby-net-ssh bump as is needed for the version in -proposed.
[08:46] <LocutusOfBorg> patch?
[08:47]  * mwhudson glares at the pytest in -proposed
[08:48] <mwhudson> lol @ http://autopkgtest.ubuntu.com/packages/p/python-ltfatpy/artful/armhf
[08:48] <mwhudson> i presume the version without the build1 is marked badtest
[08:52] <mwhudson> hmm nope
[08:54] <LocutusOfBorg> Unit193, ^^ do you have a patch?
[08:54] <LocutusOfBorg> wrt ruby
[08:56] <Unit193> LocutusOfBorg: Yep, just testing now.
[08:56] <mwhudson> sil2100: hey ubuntu-image autopkgtests fail now that py35 is not supported
[08:56] <mwhudson> Test-Command: tox -e py35-nocov,py36-nocov
[08:56] <mwhudson> sil2100: just s/py35-nocov//?
[08:57] <LocutusOfBorg> thanks
[09:01] <sil2100> mwhudson: yeah, that should do it - although we'd have to create a delta for the stable series
[09:02] <mwhudson> sil2100: i don't suppose the py36-nocov tests pass on xenial either?
[09:02] <mwhudson> i guess you can do something involving py3versions -vs
[09:03] <sil2100> mwhudson: well, if the given interpreter is not available then the test is skipped
[09:03] <mwhudson> ah
[09:03] <sil2100> So py36-nocov doesn't cause a failure on xenial at least ;)
[09:03] <mwhudson> well that will start working again in artful sooner or later
[09:03] <sil2100> But yeah, this could be done better
[09:03] <mwhudson> but not quite yet
[09:06] <Unit193> LocutusOfBorg: Testsuite takes a bit...
[09:07] <sil2100> mwhudson: you need this to be unblocked? I guess it'll be fine for you to do that change as a manual upload for now
[09:08] <sil2100> I'll overwrite it with our next bigger release, which will probably take a while, I expect then the interpreter will be gone
[09:08] <mwhudson> sil2100: it's not blocking anything i'm super desperately waiting on but sure
[09:18] <Unit193> LocutusOfBorg: Gift wrapped: https://deb.li/3hIXF
[09:21] <fossfreedom_> anyone from the DMB around?  The agenda dates are need updating and there appears to be 3 candidates for the next meeting.  True? https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda
[09:23] <LocutusOfBorg> uploaded thanks
[09:24] <mwhudson> sil2100: https://launchpad.net/ubuntu/+source/ubuntu-image/1.1+17.10ubuntu4
[09:26] <Unit193> LocutusOfBorg: FYI, all Ubuntu delta is actually committed in the chef git repo. \o/
[09:28] <LocutusOfBorg> so upload in debian?
[09:30] <Unit193> Already pinged someone, yep! :D
[09:36] <sil2100> mwhudson: looks good, thanks!
[09:41] <Unit193> LocutusOfBorg: BTW, ruby-net-ssh-gateway and ruby-net-ssh-multi are held up on net-ssh, if they are re-tried with 4.0+, they'll pass.
[09:42] <Unit193> http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#ruby-net-ssh-gateway
[09:48] <LocutusOfBorg> I think I did them
[09:51] <Unit193> Ran against old net-ssh still.
[09:52] <Unit193> http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=ruby-net-ssh-gateway&trigger=ruby-net-ssh-gateway/2.0.0-1&trigger=ruby-net-ssh/1:4.1.0-1
[09:55] <Unit193> \o/
[09:55] <Unit193> As always, thanks muchly.
[09:56] <ouroumov> Hello, it's my opinion that there is something currently wrong with the instructions to sign the Ubuntu code of conduct. I followed to the letter the procedure to do that on launchpad, used seahorse to create the key, then attempted to gpg --clearsign with --default-key option, which according to google would clear a "gpg: no default secret key: secret key not available" error. Thing is, nothing worked, until I used "gpg2" instead of "gpg".
[09:57] <LocutusOfBorg> :)
[09:59] <sil2100> jamespage: hey! One final thing I'd like to have before formally accepting the MRE for openstack is: could you provide me with a list of openstack packages this exception would cover? Since the openstack packageset is quite big - are all of these needed for the exception? Are all of those updated to new upstream releases frequently?
[09:59] <sil2100> jamespage: (e.g. http://people.canonical.com/~ubuntu-archive/packagesets/artful/openstack )
[10:00] <jamespage> sil2100: its a subset of that list
[10:00] <jamespage> sil2100: do you just want me to add a list to the wiki page?
[10:01] <sil2100> jamespage: yeah, would be perfect, once you have a moment just add it to https://wiki.ubuntu.com/OpenStackUpdates somewhere at the beginning
[10:02] <Unit193> LocutusOfBorg: Do you know if http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=amd64&package=chef&trigger=ruby-net-ssh/1%3A4.1.0-1 needs re-run, or if it's good due to the latest run?
[10:04]  * Unit193 is learning the autopkgtests infra.
[10:04] <LocutusOfBorg> Unit193, I'm waiting for the update excuses to refresh :p
[10:12] <jamespage> cpaelzer: morning - are you planning an update for dpdk -> 17.05.1 ?  Prepping the ovs-2.8 branch snapshot and tripping over some build failures
[10:14] <cpaelzer> jamespage: hi
[10:14] <cpaelzer> jamespage: I expected you to have a public holidy today
[10:14] <cpaelzer> jamespage: first of all thanks for the work on the arm specific character console
[10:14]  * jamespage checks he should be working...
[10:14] <jamespage> nah I don't live in scotland
[10:15] <cpaelzer> jamespage: I updated the bug, last status is that I hope (diminishing) to make 3.6 happen and that would mean fixed in artful, otherwise I fall back to the backports for artful
[10:15] <cpaelzer> jamespage: yes we are working on dpdk 17.05.1 already
[10:15] <jamespage> cpaelzer: awesome
[10:15] <cpaelzer> jamespage: there is a OVS patch actually blocking this
[10:15] <cpaelzer> but I'm just back from PTO I need to check if it was accepted in the meantime
[10:16] <cpaelzer> jamespage: will you be on the september sprint to sync on this and so much more?
[10:17] <jamespage> cpaelzer: ovs 2.8 advertises 17.05.1 support (infact it ftbfs with the current version in artful)
[10:17] <jamespage> cpaelzer: if you can stage 17.05.1 in a bileto ppa, I'll upload what I have and we'll see if it works :-)
[10:18] <jamespage> cpaelzer: hope you had a nice break btw
[10:18] <cpaelzer> nice until I saw my inbox, but that was expected :-)
[10:20] <cpaelzer> jamespage: still waiting for https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334891.html to be accepted
[10:20] <cpaelzer> jamespage: but if I upload the latest packaging as it is prepared (but not yet released) it will need that
[10:20] <jamespage> cpaelzer: I can pick that and then poke upstream to get that into the 2.8 branch (hopefully)
[10:20] <cpaelzer> jamespage: let me sort that out and provide you something in a ppa with all but the change that requires this, so you can then try OVS-2.8
[10:20] <jamespage> cpaelzer: ta
[10:21] <cpaelzer> oh yeah, another "pro" voice would be nice
[10:21] <jamespage> cpaelzer: "o make 3.6 happen and that would mean fixed in artful" - libvirt bits right?
[10:21] <cpaelzer> Let me sort out how complex things are, I might provide two ppa's
[10:21] <cpaelzer> jamespage: yes  that comment was on libvirt
[10:22] <cpaelzer> jamespage: I'll ping you on a dpdk 17.05.1 once I have something usable
=== zyga-ubu1tu is now known as zyga-ubuntu
[10:41] <cpaelzer> jamespage: we have already uploaded 17.05.1 in Debian-experimental and in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2889 you'll find that building for Artful so you can test it
[10:42] <cpaelzer> jamespage: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2888 OTOH has further changes to fix multiarch but that needs the mentioned OVS patch to not FTBFS
[10:42] <cpaelzer> jamespage: You can find the OVS fix and would be welcome to chime in at https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336913.html
[10:42] <cpaelzer> I'm leaving for lunch, and will fix build errors if any after that
[10:42] <cpaelzer> jamespage: let me know if I can help more
[10:43] <jamespage> cpaelzer: are you ok for me to upload to the same ppa?
[10:43] <jamespage> or I can depend on that one elsewhere
[10:43] <cpaelzer> the ppas are all yours
[10:43] <cpaelzer> if you want
[10:43] <cpaelzer> I added you to the notified IRC nicks, so you'll get a ping on the successful build (or error)
[10:45] <cpaelzer> jamespage: also saw your update on the arm console bug, thanks now we are on one page there - I'll update that bug once I got to libvirt 3.6 (or the backports)
[10:45] <jamespage> cpaelzer: great - thanks
[10:45] <jamespage> cpaelzer: re the libvirt issue
[10:45]  * jamespage digs for another bug
[10:46] <jamespage> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1706630
[10:46] <ubottu> Launchpad bug 1706630 in libvirt (Ubuntu) "aarch64: MSI is not supported by interrupt controller" [Undecided,New]
[10:46] <cpaelzer> That is still unread atm
[10:46] <jamespage> having discussed with some folks at linaro I think that's a qemu 2.9 fixed issue but I've not tested yet
[10:47] <cpaelzer> That at leasts sounds like a plan, I'll tag it so I know to ping for retests once I have a newer qemu
[10:48] <LocutusOfBorg> Unit193, migrated! :D
[10:50] <cpaelzer> jamespage: if you can test that on artful instead of Xneial + UCA you could verify with https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream
[10:50] <cpaelzer> if that is iteresting to you
[10:50] <cpaelzer> otherwise I'll ping once a newer qemu to try is around
[11:23] <acheronuk> LocutusOfBorg: landing Qt any closer?
=== ogra_ is now known as ogra
[11:46] <cpaelzer> jamespage: the dpdk builds are both good now
[11:46] <cpaelzer> jamespage: feel free to use the ppas as you need them to check on OVS 2.8
=== freyes__ is now known as freyes
[12:49] <LocutusOfBorg> acheronuk, silo is sad when I click publish
[12:50] <LocutusOfBorg> I need an archive admin
=== zyga-ubu1tu is now known as zyga-ubuntu
=== marcoceppi_ is now known as marcoceppi
[14:21] <doko> jamespage, coreycb, rbasak: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  cmd2 and python-cryptography pull in new packages into main
=== fginther` is now known as fginther
[14:34] <sil2100> slangasek, stgraber: techboard/DMB related question - we have 2 vacancies in our DMB and only 2 candidates, are we thinking correctly that the two nominees get the seats without the need for a public vote?
[14:52] <ogra> mdeslaur, cyphermox https://lists.ubuntu.com/archives/ubuntu-users/2017-August/291140.html ... looking at trusty it seems that n-m actually depends on "libnl-3-200 (>= 3.2.7)" ?
[14:52] <ogra> (though that makes no sense, how would n-m have been installed before the security update)
[14:56] <mdeslaur> ogra: no idea why that would happen to him
[14:57] <ogra> mdeslaur, well, is there a 3.2.7 anywhere in the trusty archive ? (i dont see it)
[14:58] <mdeslaur> ogra: I don't understand what you mean
[14:58] <mdeslaur> ogra: 3.2.21 is higher than 3.2.7
[14:59] <ogra> uh, oh
[14:59] <ogra> ignore me :P
[14:59] <stgraber> sil2100: correct, they do need TB approval though
[14:59] <ogra> (pretty please)
[14:59] <mdeslaur> hehe
[15:00] <sil2100> stgraber: is there any formal process for that?
[15:02] <stgraber> sil2100: nope, just send the election results to the TB mailing-list, if nobody is opposed to the new candidates, we'll add them
[15:02] <stgraber> IIRC that's what we've usually done for the DMB
[15:02] <sil2100> stgraber: thanks! I'll guess I'll send out a final note just now, wait until EOW and send out the request to the mailing-list, since I'd like us to have 7 people for the meeting on Monday
[15:45] <doko> juliank: https://launchpad.net/ubuntu/+source/apt/1.5~beta1build1/+build/13212358
[15:47] <chiluk> so I'm trying to do my first sponsorship, and I have a feeling I'm doing something wrong.. I'm trying to use sponsor-patch, but of course it's trying to sign the package with the sponsee's keys... is there another tool?  or are people just not using sponsor-patch any more?
[15:47] <chiluk> sil2100: ^^ ??
[15:48] <nacc> chiluk: -k option
[15:48] <nacc> chiluk: and/or debsign -k after
[15:48] <chiluk> .. thanks..  knew I'd feel dumb after getting the answer.
[15:48] <chiluk> thanks ..
[15:51] <juliank> doko: Something changed in rounding floats
[15:51] <juliank> So it expected it to round one way and it now rounds the other
[15:52] <jbicha> chiluk: I have DEBSIGN_KEYID and DEBSIGN_MAINT set in my ~/.devscript so that I can just build source packages like normal regardless of who is listed in the changelog
[15:52] <jbicha> ~/.devscripts
[15:52] <doko> right, most likely the GCC 7 change, as it appears to be on i386 only
[15:55] <juliank> doko: yeah, it expects int(floor(float(0.9) * int(12-2)))=int(floor(float(0.9) * int(10))) to be 9 in the test, but now it's 8
[15:56] <juliank> Maybe we should use 0.9001 in install_progress_test.cc:19
[15:56] <juliank> Long term we should switch from float fractions to an integer
[15:57] <juliank> You know, n out of 255 instead of a float <= 1.0
[15:58] <juliank> Hmm or not
[15:59] <juliank> doko: It did not fail in our testing on Debian, though, people successfully built with gcc 7 on amd64, i386, and armhf IIRC
[16:01] <juliank> Oh, I guess we should not use 0..1 but 0..100 that should work better. Then 0.9 would be 90 and 90*10 would be 900, divide by 100 and you get 9
[16:02] <juliank> So instead of floor(0..1 * width), use floor(0..100 * width) / 100
[16:03] <juliank> Does that make sense?
[16:03] <juliank> floor(0.891 * 10) = 8 , float(89.1 * 10) / 100 = 891 / 100
[16:04] <juliank> uhm, 891.0 / 100.0
[16:04] <chiluk> so what's the process when you get upload collisions in the devel release?  in this case seb128 just uploaded bluez into artful-proposed ... can I just do the upload for 1674680 anyway?
[16:04] <chiluk> fixing versions as appropriate?
[16:05] <juliank> rebase on top of his upload?
[16:05] <chiluk> yeah is that ok?
[16:05] <chiluk> wasn't sure if we had a any sort of cool-down time in devel like there is with SRU releases..
[16:05] <juliank> I guess it would be nice to wait until it is out of proposed or stuck
[16:07] <juliank> So you don't accidentally make it wait longer due to your change (if that one is borken)
[16:07] <chiluk> just reviewed that change... looks like it's pretty small..
[16:08] <chiluk> and the upload I want to sponsor is mostly just code cleanup and upstart removal.
[16:08] <chiluk> upstart script removal.
[16:35] <chiluk> that and his upload was only a few minutes ago so the additional time is negligible.
[16:47] <seb128> xnox, hey, is using persistent journal for systemd something you are still looking at doing?
[17:00] <cjwatson> stgraber: Is installing snaps inside a nested LXD container (i.e. lxd -> lxd -> snapd) known to work or known to not work?  I'm getting EACCES on "apparmor_parser --replace --write-cache -O no-expr-simplify --cache-loc=/var/cache/apparmor /var/lib/snapd/apparmor/profiles/snap.core.hook.configure" here in the inner container
[17:00] <stgraber> cjwatson: won't work, apparmor can only do a single level of namespacing unfortunately
[17:01] <stgraber> cjwatson: so you can't load apparmor profiles in your nested container
[17:02] <cjwatson> right, sucks to be me then since I won't be able to test launchpad-buildd snap-in-lxd with my usual setup
[17:02] <cjwatson> is that something that might change in the future?
[17:05] <tyhicks> cjwatson: yeah, it might be possible in the future
[17:06] <tyhicks> cjwatson: it'll require coordination with other LSMs and the namespace folks to put the right hooks in place when namespaces are created
[17:06] <cjwatson> good to know I'm not permanently doomed :)  but in that case I probably want to select the backend dynamically
[17:07] <cjwatson> "lxd unless already running in lxd"
[17:08] <tyhicks> this is something that we'll likely discuss at the Linux Security Summit next month
[17:09] <cjwatson> thanks.  count me as a(n admittedly abstruse) use case ...
[17:53] <slangasek> sil2100, stgraber: I do find it weird that the voting system doesn't allow the developers to express a vote of no confidence in a candidate (i.e., ranking them below "none of the above" on a ballot); but seems that's the system we have
[17:59] <jbicha> does "none of the above" ever win anything?
[18:00] <jbicha> I guess it does for decisions but when we're voting on people?
[18:01] <Faux> There's a whole load of politic science about why you shouldn't have that as an option. (I do not understand it.)
[18:16] <slangasek> jbicha: I believe there have been DPL candidates who lost to NOTA in the past
=== JanC__ is now known as JanC
=== Foxtrot is now known as socketerror
=== socketerror is now known as foxtrot