[07:51] <pitti> Good morning
[07:52] <pitti> rbasak: cheers! removed/promoted
[08:12] <cpaelzer> good but somehow weird morning
[08:12] <cpaelzer> I'm slowly getting to the point that I just miss something.
[08:12] <cpaelzer> Could one of you try http://paste.ubuntu.com/23474596/ and tell me why it ends up with modifications to upstream files?
[08:13]  * cpaelzer is waiting for a shameful "there it is" pointer to come in :-/
[08:18] <sladen> cpaelzer: these all look like auto-generated files.
[08:19] <cpaelzer> yes
[08:19] <cpaelzer> but on all the packages I modified so far that never happened - so I wondered
[08:19] <sladen> cpaelzer: eg. suse.in (from ./configure), .pc/* (from quilt), .git-commit-message (artifact of an in-progress commit).  The rest is cut off
[08:20] <cpaelzer> what I wonder is if I'm supposed to undo those changes before an upload
[08:21] <cpaelzer> I was able to make a clean debdiff by dropping .pc
[08:21] <cpaelzer> but lintian still is mad at me on dput as the diff.gz contains changes outside of debian/
[08:21] <cpaelzer> e.g. all the .po changes
[08:23] <sladen> echo -e 'unapply-patches\nabort-on-upstream-changes\n' >> debian/source/local-options
[08:23] <sladen> should help with automatically unapplying the quilt patches
[08:23] <sladen> but I would check it out, manually change the debian/changelog.  Check it builds, and be done with it
[08:24] <sladen> I can't see the diff, but I expect most of it will be timetstamps
[09:25] <seb128> SRU team, could you review https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text=snapd ? snapd updates made gnome-software not able to install snaps anymore and that new package is needed to fix it (it has already been SRUed to yakkety but the xenial uploads is sitting in the queue for a while)
[09:36] <pitti> seb128: okay-ish, but it has a higher versino number than yakkety, so it should be reuploaded as ubuntu1.1~xenial
[09:37] <pitti> (rejected with that reason)
[09:37] <seb128> pitti, oh, doh, indeed, thanks for spotting that (and for the review)
[09:37] <pitti> please poke me after reuploading
[09:37] <seb128> k
[09:38] <seb128> thanks!
[12:06] <LocutusOfBorg> kees, hi, you around?
[12:07] <LocutusOfBorg> jdstrand, also ^^ I have an apparmor specific question
[12:08] <LocutusOfBorg> can I enforce some sort of global policy, where I forbid access to a specific file, no matter the process/application/user trying to open it?
[12:08] <pitti> not with AppArmor, as a process must be in a profile for that
[12:08] <LocutusOfBorg> I would like to secure my GPG private key with apparmor configuration
[12:08] <pitti> this is what DAC is for -- restrict user/group to root:root and set appropriate permissions
[12:09] <LocutusOfBorg> mmm ok, so there is no way to forbid root by looking at it
[12:10] <pitti> not towards root, no -- root can also just pry it out of the raw block device, unless you use encryption
[12:10] <pitti> but then it can ptrace a process that is allowed to access it
[12:10] <pitti> I'm afraid you can't lock root out of files
[12:11] <LocutusOfBorg> unless I patch the kernel, to forbid read syscall when the file matches a pattern, but I agree, for raw block device... there is no way
[12:12] <pitti> LocutusOfBorg: it's a more useful exercise to block access to the key from other user processes, IMHO
[12:12] <pitti> as these are the real danger
[12:12] <pitti> e. g. firefox
[12:54] <sladen> rbasak: Git double ++
[12:57] <rbasak> Thanks :)
[13:37] <juliank> Bah, the fixes I picked for fixing the locale stuff apt 1.2.16 should be correct, but they don't compile on travis because it's libstdc++6 is too old to have std::put_time (newer builds pull in a newer one by accident...). :(
[13:46] <juliank> bdmurray: pitti: What remains to be done about the apt/1.2.15 xenial SRU? The autopkgtest of sbuild and autopkgtest fail, but that's not apt's fault - the failures also happen for other packages. It's been about 2 (silent) weeks since the upload, and I've been running this for about 1.5 months now without any issues on my server.
[13:59] <juliank> ^ infinity (show a bit enthusiasm, you wanted the autoremove fix that's in there :D)
[14:01] <juliank> Meanwhile I got the 1.2.16 patch queue to compile, but it fails the test suite on travis' franken-trusty-wily-stein :/
[14:03] <pitti> juliank: right, sbuild fails due to removing procenv
[14:03] <pitti> actually no, it's there
[14:04] <pitti> and 100 is an apt error code
[14:04] <pitti> so that should at least be investigated
[14:05] <juliank> pitti: That also occurs with 1.2.10ubuntu1 in -updates as can be seen in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/sbuild/20160512_132544@/log.gz
[14:05] <juliank> (which was triggered by dpkg/1.18.4ubuntu1.1
[14:06] <juliank> With yakkety instead of zesty, of course
[14:06] <juliank> (that was back in may)
[14:08] <pitti> ah, ok; releasing then
[14:09] <juliank> Alright, thx
[14:17] <jdstrand> LocutusOfBorg: you theoretically can replace the unconfined template, but it gets crazy difficult to lock things down cause you'll define a profile that can access it, but unconfined can change_profile into that one, and then things spin out into full system policy, which is a lot of work
[14:17] <jdstrand> s/template/profile/
[14:19] <jdstrand> you can create a root strong policy fwiw, but your system also needs to run and access stuff and do things so there will be a process somewhere that has enough to access it. it is more fun to think about than to implement for a general purpose system
[14:21] <jdstrand> there are also hardware devices that can be used to aid in this sort of thing. eg, https://www.yubico.com/support/knowledge-base/categories/articles/use-yubikey-openpgp/
[15:29] <LocutusOfBorg> thanks jdstrand!
[16:16] <cpaelzer> having an issue with a build on LP infrastructure I wonder what else I could do to become more similar - it fails on LP, but works on autopkgtest
[16:16] <cpaelzer> whicih should both be cloudimg based right?
[16:17] <cpaelzer> with LP having a modified one (I wonder how slightly or extensive that is)
[16:17] <cpaelzer> I created a zesty instance on serverstack to be even closer, but there as well the issue doesn't trigger
[16:17] <cpaelzer> if there are common "make it more similar to LP for debuggung" hints that you have please feel free to share
[16:21] <cjwatson> cpaelzer: The usual thing is to take away network access other than to essential facilities like the archive.
[16:22] <doko> zul: rejected python-vmware-nsxlib , again missing information in debian/copyright
[16:22] <zul> doko: shoot thanks
[16:23] <cjwatson> cpaelzer: The base image is basically only modified to install launchpad-buildd and friends.
[16:24] <cjwatson> cpaelzer: You can look at lp:launchpad-buildd (especially sbuild-package and sbuildrc) to see how sbuild is run.
[16:25] <cjwatson> cpaelzer: And you can get the chroot that the build is executed in by starting from https://api.launchpad.net/devel/ubuntu/zesty/amd64 etc.
[16:25] <cjwatson> (or manage-chroot from lp:ubuntu-archive-tools)
[18:51] <smoser> slangasek, how did you make the ascii art showing cloud-init services ?
[18:51] <slangasek> smoser: by hand hnnngh :)
[18:51] <smoser> bah
[18:52] <smoser> well then, makes it harder for me to jsut change things and see how it changes therendering :)
[18:53] <sarnold> did you use something like http://www.vim.org/scripts/script.php?script_id=40 or the similar emacs thingy? or by-hand by hand? :)
[18:56] <smoser> sarnold, that looks neat
[18:58] <sarnold> smoser: the docs are thick enough that I've never actually -used- it -- I thankfully don't have to draw diagrams often :)
[19:06] <slangasek> sarnold: genuinely by hand ;)
[19:06] <slangasek> smoser: there are tools for graphing systemd unit deps, but nothing text-y AFAIK and I'm not proficient
[20:04] <slangasek> smoser: discussion with pitti suggests 'systemd-analyze dot "cloud*"' or 'systemd-analyze dot --order "cloud*"' might be the thing
[20:04] <pitti> smoser: dot --order "cloud*" → http://people.canonical.com/~pitti/tmp/cloud-all.svg
[20:05] <smoser> slangaseks' was prettier :)
[20:05] <pitti> slangasek also draws graphs with 50% more love than graphviz :)
[20:05] <slangasek> and I truncated the graph for legibility
[20:06] <nacc> smoser: what do you think about the importer doing no-clean on error?
[20:06] <nacc> smoser: i feel like that is a sane default, as i generally don't need to keep the repo around if it successfully imports, but if it fails, i need to debug :)
[20:07] <smoser> nacc, that seems reasonable.  you dont have to give a dir, though right ?
[20:08] <nacc> right, it just won't rm -rf the tmp dir
[20:08] <nacc> smoser: --^
[20:09] <smoser> so in that event if i run that 100 times in a loop (which i'm apt to do with the up arrow) i end up with a ton of wasted disk space.
[20:09] <teward> what bug type is for when someone files a bug with `ubuntu-bug`?
[20:09] <smoser> obviously solvable by passing --directory
[20:10] <smoser> but it seems that you end up with lots of space taken if you're not aware
[20:10] <nacc> smoser: it says pretty explicitly (when no-clean is used) that it's leaving a directory around
[20:10] <nacc> smoser: and the path to the same
[20:10] <nacc> smoser: again, the odds of anyone running the importer locally is very low :)
[20:11] <smoser> nacc, to my knowledge 100% of users of it have used it locally
[20:11] <nacc> smoser: yes, that's a limitation of the current deployment
[20:11] <smoser> so... while you might have one plan, that isnt' reality at the moment at least
[20:11] <nacc> smoser: yes, and almost *all* users run w/o --no-clean
[20:11] <nacc> smoser: and don't hit errors
[20:11] <nacc> smoser: and can't debug
[20:11] <nacc> smoser: fine, i'll add another flag
[20:12] <smoser> nacc, i dont really care. i dont think its bad.
[22:15]  * tsimonq2 hunts for patch pilot
[22:18] <tsimonq2> Seems Laney and henrix were scheduled for today? Hmmmmmmmmmmmmmm
[22:18] <tsimonq2> bug 1641315
[22:19] <tsimonq2> bug 1636655
[22:21] <tsimonq2> If a MOTU is willing to help me out, that would be awesome.
[22:22] <tsimonq2> The first one is a simple Debian sync, should be flawless.
[22:23] <tsimonq2> The second one fixes RAR support and needs to get in Zesty before we make an SRU, I assume.
[22:24] <tsimonq2> We got a prod from upstream, and it's just that. An upstream commit. acheronuk tested it on Zesty and Yakkety from my test uploads to a PPA.
[22:24] <tsimonq2> So I see no reason why that shouldn't be uploaded.
[22:24] <tsimonq2> Any takers? ;)
[22:33] <juliank> tsimonq2: That purpose thing seems a bit dubious. It mentions transitional packages for libkf5purposewidgets5, but there are none.
[22:34] <tsimonq2> acheronuk: ^^^^^^^^^^^^^^^^^^^^^^^^^^
[22:34] <juliank> All I see is libkf5purpose5 conflicting and replacing that
[22:36] <juliank> Hmm, seems like it was dropped in packaging git recently, but apparently the history in that git repo (https://anonscm.debian.org/git/pkg-kde/frameworks/purpose.git) does not quite match the uploads
[22:39] <tsimonq2> Kubuntu's packaging BTW, juliank: https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/purpose
[22:41] <tsimonq2> juliank: So is the problem in our package or Debian's?
[22:42] <juliank> tsimonq2: I was just wondering where the package is in 1.1-2, but if nothing rdepends on it, that seems fine
[22:42] <tsimonq2> On purpose or libkf5purposewidgets5?
[22:42] <juliank> (Because it was there in the old package, so syncing it would remove it, so better nothing depends on it)
[22:42] <juliank> The latter
[22:43] <tsimonq2> Correct, it seems it's fine.
[22:46] <juliank> tsimonq2: ack
[22:48] <tsimonq2> juliank: Thanks for taking a look at this. ;)
[22:49] <juliank> Bah, syncpackage "signed" that with my gmail
[22:49] <juliank> Ah, probably because I changed the lp email
[22:51] <juliank> tsimonq2: Seems like the sync is now dep-waiting on libkf5kio-dev, because it's actually called kio-dev here. Who could have expected this?
[22:51] <tsimonq2> Aha, yes, that's known.
[22:52] <tsimonq2> This will be fixed when we upload KDE Frameworks 5.27 soon. Debian transitioned to that package name but uUbuntu didn't yet.
[22:53] <juliank> Alright
[22:54] <tsimonq2> juliank: Could that be fixed by setting something like "libkf5kio-dev | kio-dev"? We could remove it when that package exists, but it will still allow for the dependency to be set.
[22:54] <tsimonq2> It will become a transitional package either way.
[22:54] <juliank> For example.
[22:55] <tsimonq2> (kio-dev will)
[22:55] <tsimonq2> Hm?
[22:55] <juliank> Another hack might be to just add a "transitional" libkf5kio-dev package to kio for the meantime, so new rdeps of kio can be synced.
[22:55] <juliank> And then that could become the real one fairly painlessly once 5.27 enters
[22:56] <tsimonq2> Oh sure.
[22:56] <tsimonq2> Yeah.
[22:56] <juliank> But I don't have any insight into which solution is the better way, that depends on how the rdeps of kio look like
[22:57] <tsimonq2> The thing is, the Kubuntu team's only person with upload access recently left, so we'll have to fall back to the old members who still have access but don't participate any more.
[22:57] <tsimonq2> So for these things we're going through the sponsorship process.
[22:57] <tsimonq2> So I think either one should work, but I don't have the access to Just Do It. :)
[22:58] <tsimonq2> Personally I'd rather just add the delta to purpose.
[23:00] <tsimonq2> I want to do that because kio-dev becomes a transitional package either way when we upload kio with the next FW.
[23:01] <tsimonq2> juliank: So would you like me to file a bug against purpose to go through the sponsorship process on that too, or would you be able to just do it? :)
[23:02] <juliank> tsimonq2: I can do that
[23:02] <tsimonq2> Thank you. :)
[23:03] <juliank> tsimonq2: I just can't built binaries right now, so we either get lucky or not. If not, we have to deal with this tomorrow (CET)
[23:04] <tsimonq2> Fair enough.
[23:04] <tsimonq2> juliank: You got a diff I can look at first?
[23:04] <tsimonq2> More pairs of eyes if we're relying on luck. ;)
[23:05] <tsimonq2> (If not, it should be fine, but still. More is always better. ;) :P)
[23:05] <juliank> Well, that part is not the problem. Just if some other part of the build fails somehow :)
[23:05] <tsimonq2> Oh ok
[23:05] <tsimonq2> Fair enough.
[23:10] <juliank> tsimonq2: That should be it: http://paste.ubuntu.com/23477837/ - there already is an equivalent dep on kio-dev further up the build-depends
[23:13] <juliank> Build Dependencies seem to be installing
[23:14] <tsimonq2> Why would Debian depend on kio-dev as well? O__o
[23:14] <tsimonq2> I'll poke the relevant person.
[23:14] <juliank> Accident probably
[23:15]  * tsimonq2 watches https://launchpad.net/ubuntu/+source/purpose/1.1-2ubuntu1/+build/11200190
[23:15] <juliank> tsimonq2: ppc64el is uploading
[23:15] <tsimonq2> \o/
[23:16] <tsimonq2> juliank: Thanks. :D
[23:16] <tsimonq2> Oh, seems kio is Plasma? We'll upload that soon anyways.
[23:18] <tsimonq2> juliank: Any chance you could look at ark as well?
[23:18]  * juliank does not know what KDE calls what these days ...
[23:19] <tsimonq2> juliank: Plasma is the desktop, Frameworks is the base APIs, and Applications is, well, the Applications.
[23:19] <tsimonq2> That's the short version. :)
[23:20] <juliank> tsimonq2: OK. Let me have a quick look at the ark thing
[23:22] <juliank> tsimonq2: Looks sane to me, uploaded it. If there's some issue, let me know when I'm awake again :D
[23:22] <tsimonq2> juliank: Ok, thank you. :)
[23:23] <Unit193> juliank: ...Do I get to bother you about command-not-found this month? :)
[23:23] <juliank> Unit193: aaah
[23:23] <juliank> Unit193: I want to go to sleep now ...
[23:24] <Unit193> juliank: Hah, lovely timing then!  Also perhaps wrong channel..
[23:24] <juliank> Yea, remind me in 21 hours
[23:25]  * juliank is doing university + apt stuff by day, and misc stuff before going to sleep...
[23:32] <juliank> This reminds me: If someone can test the apt 1.2.16~rc1 in the xenial PPA linked in bug 1592817 and 1611010 and verify that it fixes these bugs, that would be nice. I'm reasonably (like 95%) sure it does, but I can't really be bothered to do this
[23:33] <juliank> Anyway, I'm off now, will be back in about 8 hours