[00:40] <elky> CasW: https://launchpad.net/hundredpapercuts but i don't know if it's actually active anymore
[00:41] <CasW> Thanks a lot!
[07:59] <fnordahl> I have prepared patches that cherry pick restart on configuration changes fix for rsyslog from Debian to Artful in LP 1668639.
[07:59] <fnordahl> Would anyone have a moment to review the patch?
[08:10] <mwhudson> uh what's the story with libssl1.0.2 and ubuntu?
[08:10] <mwhudson> https://launchpad.net/ubuntu/+source/pyelliptic/1.5.7-1.1 is depwait now, wondering if we should revert the commit or just wait
[08:11] <mwhudson> and what the heck is going on here, https://launchpadlibrarian.net/325564633/buildlog_ubuntu-artful-amd64.paste_1.7.5.1-6ubuntu3_BUILDING.txt.gz "dpkg-genbuildinfo: error: cannot fstat file ../python-paste_1.7.5.1-6ubuntu3_all.deb: No such file or directory"
[08:38] <geser> mwhudson: "dpkg-deb: error: obsolete compression type 'bzip2'; use xz or gzip instead" and as consequence "dh_builddeb.pkgbinarymangler: dpkg-deb -Z bzip2 --build debian/python-paste .. returned exit code 2"
[08:41] <infinity> mwhudson: We seem to be 3 years behind on merging paste for some reason.
[08:41]  * infinity wonders if the reason is him.
[08:59] <infinity> mwhudson: New paste uploaded.
[09:51] <rbasak> cpaelzer: OK, caught up.
[09:51] <rbasak> Oh, wrong channel.
[10:24] <mwhudson> geser: oh i thought that thing about bzip2 was just a warning
[10:25] <mwhudson> infinity: thanks
[10:46] <mwhudson> FAIL: test_Headbanging_Median_Rate_tabular
[10:46] <mwhudson> i think this means i should go to bed
[12:42] <ricotz> mapreri, hi :), could you look into syncing rustc/cargo?
[12:42] <mapreri> hold on, writing a mail
[12:45] <LocutusOfBorg> ricotz, can I do it?
[12:45] <ricotz> LocutusOfBorg, I assume chrisccoulson might have a thought too
[12:46] <LocutusOfBorg>  /tmp/cargo_0.17.0.orig-vendor.tar.gz has size 6526779 instead of expected 5023852
[12:46] <LocutusOfBorg> bad people out there, sigh
[12:46] <ricotz> chrisccoulson, I guess eventually firefox will require 1.17
[12:47] <mapreri> cargo can't be synced
[12:47] <mapreri> afaik
[12:47] <ricotz> mapreri, maybe, but cargo should be sufficient for rustc 1.17 already anyway
[12:48] <mapreri> it embeds a libgit2 that doko very much don't want to have embedded.
[12:48] <mapreri> OTOH, probably that embedded lib can go away on the debian side now
[12:48] <ricotz> ah I see
[12:49] <mapreri> [02:48:51 PM] <mapreri> infinity0: can cargo stop embedding libgit2 now?
[12:49] <mapreri> [02:49:02 PM] <infinity0> yeah i'll do that tomorrow hopefully
[12:49] <mapreri> rustc should be free to go, so syncing that.
[12:50] <ricotz> when was that?
[12:50] <ricotz> thanks!
[12:50] <mapreri> right now :)
[12:50] <ricotz> good :)
[12:51] <LocutusOfBorg> please don't use rustc 1.18
[12:51] <LocutusOfBorg> and forward that to debian folks
[12:52] <LocutusOfBorg> You are receiving this email because I have you listed as a downstream Rust packager.
[12:52] <LocutusOfBorg> There is a bug in Rust 1.18 that prevents bootstrapping from a local toolchain, and it has affected multiple packagers:
[12:52] <LocutusOfBorg> https://github.com/rust-lang/rust/issues/42543
[12:52] <LocutusOfBorg> Fix is in progress. Sorry for the delayed response. If you want to discuss, please do so on the linked issue.
[12:52] <mapreri> well, this is 1.17
[12:53] <mapreri> LocutusOfBorg: please talk about that with the debian folks :)
[12:54] <LocutusOfBorg> mapreri, done a few seconds ago
[12:54] <LocutusOfBorg> but I would like to avoid somebody "hey lets do 1.18 in Ubuntu as delta"
[12:56] <mapreri> ricotz: you asked for it, and I forgot to check…  are you aware it ftbfs on ppc64el?
[12:58] <ricotz> mapreri, haven't check for ftbfs, just want to draw some attention to get it updated
[12:59] <ricotz> mozilla kind of requires 1.17 it already
[12:59] <mapreri> well, infinity0 seems aware, the last upload was a debugging one
[12:59] <mapreri> I suppose he would appreciate help trying to fix it :P
[12:59] <ricotz> ok
[13:32] <zyga> jdstrand: hey
[13:33] <zyga> jdstrand: cannot unmount preserved mount namespace file /run/snapd/ns/snapd-hacker-toolbelt.mnt: Permission denied
[13:33] <zyga> jdstrand: cze 26 14:33:03 fyke kernel: audit: type=1400 audit(1498483983.583:116): apparmor="DENIED" operation="umount" profile="/usr/lib/snapd/snap-confine" name="/" pid=6500 comm="snap-confine"
[13:33] <zyga> jdstrand: note the name that makes no sense and mismatches what was attempted
[13:33] <zyga> jdstrand: this is after hopping into a namespace and then hopping out of it (via setns)
[13:33] <zyga> jdstrand: I think this confuses apparmor
[13:34] <zyga> CC jjohansen ^
[13:48] <jdstrand> zyga: if this is after a pivot_root, I think that is correct. but, yes, jjohansen would be the person to talk to
[14:25] <smoser> sil2100, around ?
[14:26] <smoser> i guess you had pinged me with regard to https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1697545
[14:26] <smoser> the change in debian/new-upstream-snapshot does not at all affect the running code and should not block its acceptance into xenial.
[14:27] <smoser> (i'm guessing thats why you didn't accept xenial when you did accept yakkety)
[14:31] <cpaelzer> I face two launchpad git based build recipes - one works and the other one asks me for user on https://git.launchpad.net
[14:31] <cjwatson> did you try to use a private repository?
[14:31] <cpaelzer> cjwatson: no all public on my lp user
[14:31] <cjwatson> links please
[14:32] <sil2100> smoser: hey! Thanks for the info, I think there was some other reason for that, need to remember now what that is!
[14:32] <cpaelzer> cjwatson: working http://paste.ubuntu.com/24956449/ failing http://paste.ubuntu.com/24956448/
[14:32] <sil2100> smoser: since I was pretty sure I did accept it
[14:32] <cpaelzer> I beg your pardon this is my first recipe, so it might suffer from all baby steps you can do
[14:32] <sil2100> Let me do a quick re-review
[14:34] <cjwatson> cpaelzer: https://git.launchpad.net/~paelzer/libvirt/+git/libvirt-daily either doesn't exist or is private
[14:34] <smoser> sil2100, fwiw, the delta from -updates to the uploaded version should be identical for yakkety and xenial
[14:34] <cjwatson> cpaelzer: looks like you put it in https://code.launchpad.net/~paelzer/qemu/+git/libvirt-daily by mistake
[14:34] <sil2100> hm, why didn't this get approved, it seems all fine
[14:34] <cjwatson> cpaelzer: so "change details" there and move it to the right project?
[14:35] <cjwatson> cpaelzer: (and change any local clones to have the correct remote)
[14:35] <cpaelzer> cjwatson: thanks will look into that repo confusion
[14:36] <smoser> sil2100, all i know is you had asked me a question about the new-upstream-snapshot.  i'mi sorry. i was on holiday last week, so i'm a bit behind.
[14:36] <smoser> away
[14:36] <sil2100> smoser: approved now, sorry about this - I either forgot to press the final button or something, I really don't remember considering this new-upstream-snapshot being a blocker
[14:37] <smoser> sil2100, thanks!
[14:41] <cpaelzer> cjwatson: of course that was it - thanks, now I'm in the land of build errors that I expected I have to fix
[14:49] <cjwatson> np
[15:23] <rbasak> xnox: if you're working on it, can you assign yourself and set to In Progress bug 1700373 please?
[15:24] <bdmurray> pitti: Why was 1000000 chosen as a number here for a core file to be expected? http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/test/test_signal_crashes.py#L18
[15:25] <bdmurray> pitti: I ask as it doesn't seem to be working - ERROR: apport (pid 12199) Mon Jun 26 08:22:55 2017: aborting core dump writing, size exceeds current limit 1000000
[15:30] <bdmurray> pitti: or rather the core file created is greater than 1000000 bytes.
[17:06] <ricotz> LocutusOfBorg, mapreri, while there is a delta for cargo already is it possible to update it to 1.18.0?
[17:23] <jjohansen> zyga, jdstrand: it may appear that way, but apparmor is not confused. You are seeing artifacts of how the vfs handles these. If the file was opened inside of one namespace, and you switch to another, that file is disconnected
[17:24] <jjohansen> so a file opened in the "child" namespace is disconnected when returning to the original ns
[17:33] <jdstrand> and then attach_disconnected put it at '
[17:33] <jdstrand> at '/'
[17:49] <sarnold> which is why attach_disconnected is so frustratingly terrible
[18:37] <gpiccoli> hi folks, sorry to bother. Anybody here can point me a Git repo for Ubuntu systemd?
[18:38] <gpiccoli> I'd like to know if there's a repo somewhat equivalent of Ubuntu's kernel gits
[18:38] <sarnold> nacc: do you have systemd in you track-all-the-things git repos?
[18:38] <gpiccoli> Thanks in advance
[18:38] <gpiccoli> track-all-the-things...seems nifty =O
[18:43] <nacc> sarnold: https://code.launchpad.net/~usd-import-team/ubuntu/+source/systemd/+git/systemd
[18:44] <sarnold> nacc: wow the branches so many branches :)
[18:44] <nacc> sarnold: yeah :)
[18:45] <nacc> sarnold: one for every release+pocket * 2 for patches-applied and patches-unapplied
[18:45] <gpiccoli> tnx sarnold and nacc
[18:45] <nacc> sarnold: with some extras for the importer itself (importer/) and then the 'always latest' ubuntu/devel
[18:45] <nacc> gpiccoli: to be clear, this is more like a mirror of the archive than it is where active development necessarily occurs
[18:46] <nacc> gpiccoli: it can be the latter, but no one is obligated to use it as such
[18:46] <nacc> gpiccoli: it reflects exactly what is uploaded for each upload, and provides history
[18:46] <gpiccoli> yes, that's exactly what I need naac
[18:46] <nacc> gpiccoli: cool
[18:46] <gpiccoli> Will check if some patches aren't applied yet, to request backport
[18:48] <nacc> gpiccoli: since systemd is a native package, i think every import/ and applied/ will be identical
[18:48] <gpiccoli> that's cool to hear
[18:48] <gpiccoli> tnx
[18:51] <nacc> gpiccoli: i would run `quilt push -a` to be sure, though :) ... and if something looks off, please file a bug (https://bugs.launchpad.net/usd-importer)
[18:52] <gpiccoli> ok, thanks a lot nacc! =D
[18:52] <nacc> gpiccoli: yw
[18:54] <gpiccoli> nacc, sorryto annoy more, but I'm having trouble to figure which systemd commits were applied from the repo
[18:54] <gpiccoli> is it a "meta-repo", that deals with histories and lists of patch applied, instead of the patches themselves?
[18:55] <gpiccoli> I'd like to check if a patch is on systemd 229
[19:07] <nacc> gpiccoli: right, it's just reflecting hte source packages as uploaded
[19:07] <nacc> gpiccoli: let me look in detail on this one
[19:08] <gpiccoli> ok naac, thanks and sorry for the annoyance
[19:10] <nacc> gpiccoli: which specific systemd pkg version? and which patch?
[19:13] <gpiccoli> systemd 229, from Xenial naac. Let me paste the patch info here
[19:13] <nacc> gpiccoli: systemd is at 229-4ubuntu4, 4ubuntu10 or 4ubuntu17 depending on the pocket
[19:13] <nacc> (release, security, updates respectively)
[19:14] <gpiccoli> hmm...what are the differences nacc?
[19:15] <gpiccoli> my version is the 17
[19:15] <gpiccoli> 229-ubuntu17
[19:15] <gpiccoli> There are 3 commits I'm interested in: https://github.com/systemd/systemd/commit/427a28e
[19:15] <gpiccoli> a5110c9
[19:15] <gpiccoli> b4c6f71
[19:15] <gpiccoli> the 3 are related to nvme devs
[19:16] <nacc> gpiccoli: e.g., you can do `git diff import/229-4ubuntu4 import/229-4ubuntu10` in your systemd repo clone to see the differences
[19:18] <nacc> gpiccoli: so to see if they are in the 'latest' xenila, you can do `git checkout <remote name (origin)>/ubuntu/xenial-devel`
[19:18] <gpiccoli> ok, thanks nacc
[19:18] <nacc> gpiccoli: and then do `quilt push -a` to push all the quilt patches
[19:19] <gpiccoli> but for example, in Ubuntu kernel repo, I can check the commits backported to Ubuntu kernel
[19:19] <gpiccoli> In 4.4.0-73, if I want. So, I can say if something need to go in or not...is there a quick way to do it for systemd?
[19:21] <nacc> gpiccoli: look at the source to see if the patches are applied?
[19:24] <gpiccoli> yes, this is the hard way nacc hehehe
[19:24] <gpiccoli> I'll take it, tnx
[19:24] <gpiccoli> Git are easier in general...
[19:24] <gpiccoli> *Gits
[19:24] <nacc> gpiccoli: it would appear the first two are present, but not he third
[19:25] <gpiccoli> that's really great nacc, thanks a lot
[19:25] <gpiccoli> So I might request the backport for https://github.com/systemd/systemd/commit/b4c6f71
[22:36] <sarnold> bdmurray: https://launchpadlibrarian.net/325392048/term.log  "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" *2 when trying to install openssl packages
[22:39] <bdmurray> sarnold: what bug number is that related to?
[22:40] <sarnold> bdmurray: 1692981
[22:41] <bdmurray> sarnold: Hmm, I meant which bug is that attachment from?
[22:43] <sarnold> bdmurray: the "openssl breaks updates forever" one
[22:48] <bdmurray> sarnold: right but the term.log file you linked to is from which bug number? Its not clear from the librarian url.
[22:50] <sarnold> bdmurray: ah. I duped all the openssl bugs to 1692981. I don't know how to get to just alister's version of the bug.
[22:51] <sarnold> bdmurray: oh hey the advanced search has a button to show dupes :) alister's bug is https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1697801