[00:00] <doko> meh, just molds built. anything else fails on powerpc
[00:12] <nacc> slangasek: ok, i think i updated all the debdiffs
[00:13] <nacc> slangasek: also posted a v3 of my sequence
[02:22] <sarnold> slangasek,cyphermox, 1544809 is currently filed against 'linux' but grub or grub2 may be more appropriate
[02:33] <cyphermox> ack reassigning to grub2... I'll look tomorrow
[02:33] <sarnold> thanks cyphermox :)
[02:55] <happyaron> bdmurray: the open-gram upload is for LP: #1361764
[04:01] <PovAddict> who do I contact regarding blatant misuse of the ubuntu logo?
[04:01] <PovAddict> https://twitter.com/actoresargok
[04:02] <sarnold> wow
[04:02] <sarnold> that's not even close to right ;)
[04:02] <PovAddict> they have absolutely nothing to do with software, they found something that looked nice and slapped it there
[04:04] <PovAddict> they even put it on all photos they upload, so it's not just a matter of changing the twitter profile picture
[04:04] <slangasek> lolwut
[04:04] <slangasek> I think there's a contact address for Canonical Legal you can use to report this
[04:05] <slangasek> though fwiw, trademark law in most countries limits trademarks by field of endeavor; so /because/ it's not for software, it probably doesn't infringe Canonical's trademark
[04:05] <slangasek> PovAddict: http://www.ubuntu.com/legal/terms-and-policies/contact-us
[04:06] <slangasek> ok that's meant to be requests to use the trademark instead of requests to enforce the trademark, but I think it'll get to the right people ;)
[04:07] <PovAddict> could still be a copyright violation if they didn't draw the logo from scratch
[04:08] <tumbleweed> looks like they've been misusing it for a few years (based on the vintage of that ubuntu logo)
[04:08] <PovAddict> tumbleweed: or what their random logo search found happened to be old?
[04:09] <tumbleweed> yeah, or that
[04:10] <PovAddict> "Are you making the request on behalf of a company?" "No" and then the company website and street are required fields, wonderful
[04:10] <sarnold> haha
[04:10] <slangasek> PovAddict: how would it be a copyright infringement when the logos are under a free license?
[04:11] <PovAddict> what license lets them get away without even attribution?
[04:11] <slangasek> yes, perhaps there's an attribution problem
[04:11] <sarnold> I'll mail the lawyers, i can't find them on irc (go figure..)
[04:12] <PovAddict> just sent the form
[04:12] <sarnold> ah, thanks PovAddict, then i'll skip the email :)
[04:27] <kirkland> doko: thanks for the heads up;  I think (hope?) I just uploaded the right fix
[06:18] <pitti> Good morning
[06:30] <ginggs> doko:  well done! getdp failed because petsc hasn't built yet, which others did you try with -Og ? pochu add some info to the bug, could be a PPC970FX vs POWER7/8 thing
[06:31] <highvoltage> 9/win 27
[08:16] <dholbach> good morning
[08:23] <slangasek> nacc: sorry, I've just now had a chance to look at your guide.  what's not clear to me in this is what the sequence points are.  I don't want to be building one package at a time, waiting for completion before starting on the next; I want to be able to throw these packages out there in parallel as much as possible.  Do you have this kind of information available?
[08:55] <doko> ginggs, <doko> meh, just molds built. anything else fails on powerpc
[08:56] <doko> liggghts built on a porter box
[09:09] <ginggs> doko: anything special about that porterbox?  BTW i did try petsc 3.6.3 but not change.  I  did get petsc 3.6.2 to build by patching the tests to only run on one process (but that's defeating the point of MPI)
[09:11] <doko> ginggs, it's a POWER7+ machine, running qemu
[09:13] <ginggs> I did find this issue upstream that sounded vaguely similar https://github.com/open-mpi/ompi/issues/874
[09:13] <ginggs> endianness, -np 1 works, -np 2 fails - but apparently those patches have been included (and i can't even find those files)
[09:16] <doko> the test cases really should be turned on in the openmpi package itself
[09:17] <ginggs> doko: i think they are
[09:18] <ginggs> at least it says so in the changelog for 1.10.2-6
[09:21] <doko> ginggs, hmm, the files in the patch don't exist :-/
[09:26] <opny> hello, I would like to run xenial armhf on qemu. Do you think is feasible?
[09:29] <doko> kirkland, I hope you saw the build failure yourself this time ;p
[09:37] <ginggs> doko: btw should https://launchpadlibrarian.net/237705769/vtk6_6.2.0+dfsg1-7ubuntu1_6.2.0+dfsg1-7ubuntu2.diff.gz go to debian?
[09:42] <doko> ginggs, wouldn't hurt, I assume
[09:44] <ginggs> ok, i'll forward it, gladk's going to include our other delta as well
[10:00] <doko> pitti, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/amd64/   looks like a valid test results is superseded by an invalid one ...
[10:00] <doko> sil2100, ^^^
[10:01] <sil2100> doko: yeah, I actually re-ran those in the morning, I see 2 of them still fail
[10:06] <doko> hmm, looks like some autopkg test results are not picked up since midnight
[10:07] <Laney> doko: what's the actual problem?
[10:07] <doko> sil2100, no wonder if the tests are run with the wrong versions... I'm wondering where pitti even gets this version from
[10:07] <Laney> Tests try to minimise their use of proposed
[10:08] <Laney> the order of things on autopkgtest.u.c doesn't really matter, britney doesn't just take the latest
[10:10] <rbasak> caribou: o/
[10:10] <caribou> rbasak: o/
[10:11] <caribou> rbasak: so I rebuilt a new repo starting from the original merged version
[10:11] <rbasak> So for when Ubuntu pull in a new upstream, I'm breaking down the logical commit as follows. For each Ubuntu upload, there will be one commit that pulls in the new upstream, but no changes in debian/*, and subsequent commits only change debian/*
[10:11] <rbasak> Then one commit per logical change, which is generally one per changelog entry but a little subjective.
[10:12] <rbasak> That should be it.
[10:12] <rbasak> Before I get there the reconstruct stage additionally has one commit for all of debian/changelog changes per upload, and potentially another commit for update-maintaner/ubuntu-meta.
[10:12] <rbasak> Sorry, that's really the reconstruct.
[10:13] <rbasak> The logical then drops the upstream changes, changelog and ubuntu-meta.
[10:13] <rbasak> So you end up with logical only changing things in debian/* that are logical parts of the Ubuntu delta, so excluding upstream changes and meta-changes in debian/changelog, update-maintainer, etc.
[10:15] <doko> Laney, well, for a transition, this assumption is wrong
[10:16] <rbasak> caribou: here's a summary I wrote yesterday, but haven't finalised yet: http://paste.ubuntu.com/15023270/
[10:16] <doko> Laney, http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/i386/  shows a successful test, which is overridden by a bad one
[10:16] <Laney> it is not overridden
[10:16] <Laney> you need to look on excuses
[10:19] <doko> Laney, I did, libjsoncpp still lists these as fail
[10:23] <pitti> doko: WDYM with "invalid version"? 0.1.1+16.04.20160210-0ubuntu1 is -proposed
[10:23] <Laney> I think I retried those with the new -scope-click now
[10:23] <rbasak> caribou: minor updates in http://paste.ubuntu.com/15023288/ - I clarified logical/<version> wrt. your new upstream case.
[10:24] <Laney> pitti: It's a transition but retried with the non rebuilt -scope-click I think
[10:24] <caribou> rbasak: looking
[10:24] <pitti> Laney: ah, that again -- they don't have versioned Depends:, thus they need the old "rerun with both triggers" trick again?
[10:24] <Laney> well they have Depends on the old and new versioned packages
[10:28] <caribou> rbasak: so basically, when a new upstream is merged in as an ubuntu delta (my 0.98-7 case), you would lump all of the 'upstream' changes in one commit & the debian specific things in other logical commits ?
[10:28] <rbasak> caribou: right. And then for the "logical", I drop the commit containing all of the upstream changes.
[10:29] <caribou> rbasak: ah ok, got it. I'll rebuid my git repo according to this (mostly done) & will resubmit
[10:29] <rbasak> Since when later rebasing, the upstream changes will be present anyway, since we'll always be rebasing onto a newer upstream.
[10:29] <rbasak> caribou: OK. Thanks!
[10:30] <Saviq> pitti, hey, got two Qs about silo 51 excuses; 1: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html (just updated a few minutes ago) says "in progress" for a lot of items, but running.html shows none of them... 2: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-051/excuses.html has ♻ for qtmir-gles that tell sil2100 that it has no tests, so can't re-run ¿?
[10:40] <pitti> Saviq: hm, I had to kill ppc64el runs this morning as the lcoud was broken again
[10:40] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-051?format=plain does have a qtmir result from this morning, though
[10:43] <pitti> Saviq: for 2. indeed http://autopkgtest.ubuntu.com/packages/q/qtmir-gles/ does not yet have any results for vivid
[10:44] <pitti> Saviq: we currently check that to determine whether a package name is valid and has tests, to fend off invalid retries
[10:44] <pitti> (we need to be rather strict there as this quickly becomes a resource DoS)
[10:44] <pitti> Saviq: can you please file a bug report about that, with a summary of that (against auto-package-testing)
[10:44] <Saviq> pitti, ok, thanks
[10:44] <pitti> I need to think about how we can allow that without openign the floodgates
[10:45] <pitti> Saviq: I'll retry the tests in the meantime
[10:45] <Saviq> pitti, thank you
[10:45] <pitti> does anyone else than robru have access to the production CI train?
[10:46] <pitti> would be much easier to rm pending.json for that xenial silo than crafting the retry commands by hand
[10:46] <Mirv> I don't think sil2100 has either the access
[10:46] <Mirv> I don't at least
[10:47] <Saviq> pitti, I could toggle the lander ack there, that (I *think*) would retry the whole suite?
[10:48] <pitti> vivid retried
[10:50] <Saviq> pitti, bug #1544917
[10:52] <pitti> Saviq: thanks, updated
[10:54] <pitti> robru (CC: Saviq): Can you please remove pending.json for this silo? https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html
[10:54] <pitti> to get the tests re-ran?
[10:54] <pitti> run
[10:54] <robru> pitti: nope you need webops
[10:54] <pitti> (scalingstack glitch this morning, sorry)
[10:56] <robru> pitti: would be like /tmp/britney_data/landing-051-xenial/autopkgtests/pending.json or so
[10:58] <pitti> robru: what does "webops" translate to?
[10:58] <robru> pitti: talk to the vanguard in #webops
[11:02] <Saviq> pitti, re: qtmir-gles - it has tests since October, and somehow britney has decided that it was a regression, so ¿?
[11:03] <pitti> Saviq: within the silo, yes, but apparently it never ran in Ubuntu in vivid?
[11:03] <pitti> Saviq: xenial-051 sohuld now retry the missing tests on the next run
[11:04] <Saviq> pitti, hmm right, that makes sense
[11:11] <LocutusOfBorg> ginggs, I syncd scalapack and blacs-mpi from Debian
[11:12] <LocutusOfBorg> mapreri fixed all the delta there
[11:12] <ginggs> LocutusOfBorg: thanks
[11:12] <LocutusOfBorg> just a little change has been left out (adding fort to the linker flags), because he is pretty sure the fix has been in another package (pkg-config wasn't giving all the flags)
[11:12] <LocutusOfBorg> so that delta has been removed
[11:14] <LocutusOfBorg> don't remember where, but in a package I remember I syncd yesterday
[11:19] <LocutusOfBorg> let me know if I broke anything, and I'll bother mapreri to fix it :)
[11:20] <LocutusOfBorg> actually I think powerpc is the most important problem
[11:47] <caribou> doko: remember the reason why clamav was 'forced' to use LLVM 3.5 ?
[11:50] <doko> caribou, because it needs porting?
[11:50] <caribou> doko: yeah, I get clamav build failures with 3.7 & 3.8
[11:53] <doko> caribou, yes, the server team told me that they will port it
[11:53] <doko> rbasak, ^^^
[11:53] <caribou> doko: hmm, that means me
[11:53] <doko> caribou, forwarding you email
[11:54] <caribou> doko: thanks
[11:59] <doko> caribou, you might ask ScottK; he once cared about clamav
[12:14] <LocutusOfBorg> caribou, according to debian logs it should build fine with 3.6
[12:16] <caribou> LocutusOfBorg: yes, that's what they build with
[12:26] <rbasak> doko: when did we say that? Or did you just ask us to port it?
[12:28] <doko> rbasak, see email
[12:30] <ScottK> caribou: Every single llvm update seems to need a new patch for clamav.
[12:31] <ScottK> rbasak: If you are going to port it, you also really want to update to 0.99 first.
[12:31] <ScottK> Please send us (Debian) the patch if you come up with something.
[12:34] <pitti> Mirv: vivid is ok now (except for the unity8 NBS), xenial re-ran and now just has one regression
[12:35] <ricotz> hello developers
[12:35] <ricotz> doko, hi, please don't forget aptitude
[12:40] <caribou> ScottK: porting would be part of the 0.99 merge
[12:40] <ScottK> OK.
[12:40] <caribou> ScottK: right now, it doesn't like the fact that I'm using 3.8 (testing for 3.7)
[12:41] <caribou> ScottK: configure complaining
[12:41] <ScottK> I'm sure it doesn't.  The only reason it works with 3.6 is a Debian patch.
[12:41] <ScottK> I'm sure it'll need additional something for newer.
[12:42] <caribou> ScottK: ok, I'll look at what was done on the debian side
[12:43] <doko> ricotz, would like to wait until apt gets in
[12:43] <ScottK> Specifically debian/patches/add-LLVM-3.6-support.patch
[12:43] <Mirv> pitti: you mean Saviq?
[12:43] <pitti> Mirv: yes, I do, sorry :)
[12:43] <Mirv> np :)
[12:43] <ScottK> caribou: You can discuss what needs doing on pkg-clamav-devel@lists.alioth.debian.org.
[12:43]  * ScottK isn't the right person to answer any details.
[12:43] <caribou> ScottK: ok, thanks
[12:44] <cjwatson> pitti: could you add an "easy click/0.4.43+16.04.20160203-0ubuntu2 python-click/6.2-2ubuntu1" hint for me?  it's not going to work yet because of reverse dependencies, but those two will eventually need to go in together
[12:44] <ricotz> doko, alright
[12:44] <cjwatson> pitti: (renaming python3-click -> python3-click-package and also python{,3}-click-cli -> python{,3}-click)
[12:45] <Mirv> Saviq: rerunning the one remaining failed at http://autopkgtest.ubuntu.com/running.shtml#pkg-qtmir
[12:45] <Saviq> Mirv, thanks!
[12:46] <Saviq> Mirv, we should be rid of these soon, hopefully
[12:46] <Saviq> (flaky ones I mean)
[12:47] <pitti> cjwatson: committed (without knowing what I'm doing :) )
[12:48] <cjwatson> heh, thanks
[12:56] <rbasak> doko: thanks
[13:00] <doko> rbasak, also saw that the merged ntp is dep-wait
[13:01] <rbasak> doko: I emailed ubuntu-devel about that. I guess we'll MIR pps-tools.
[13:05] <rbasak> caribou: can I suggest that you merge and build against llvm 3.6 for now, since that's the easiest path? Then we'll at least be further forward.
[13:05] <caribou> rbasak: that was my idea
[13:06] <rbasak> If we can fix in a later upload to use a newer llvm then we can do that separately, but that realistically sounds unlikely to me to happen before FF.
[13:06] <rbasak> doko: ^
[13:06] <caribou> ScottK: the only delta left with debian then would be an override for armhf tests
[13:06] <caribou> ScottK: would that be accepted in Debian ?
[13:28] <seb128> doko, slangasek, would foundation like to subscribe to fonttools bugs (bug #1538173)? graphite2 is depwaiting on it and you probably know better about fonts than us
[13:40] <cyphermox> good morning!
[13:41] <seb128> hey cyphermox, happy friday!
[13:41] <cyphermox> hey, you too
[14:36] <ginggs> doko: are the powerpc openmpi builds working now?
[14:39] <cjwatson> ginggs: https://launchpad.net/ubuntu/+source/aces3/3.0.8-5build2/+build/8974836 managed to pass, which is a good sign I guess
[14:44] <doko> ginggs, cjwatson yes, this one and molds. the others still stuck, however there seems to be a bit more output
[14:44] <doko> seb128, isn't font stuff desktopish? ;)
[14:45] <seb128> doko, I don't think so ;-)
[14:45] <seb128> you have fonts on command lines as well :p
[14:49] <Mirv> mterry: LP chat is slow, would you want for me to consider another team for the foma or create a new team?
[14:50] <ginggs> doko, cjwatson: weird, aces3 is one that failed on the debian buildds.  aster, getdp and slepc all depend on petsc, so if we can shoehorn petsc in, it would be good
[14:51] <mterry> Mirv, creating a new team seems like a hassle, is there another good team fit?  It just seemed odd to have a team responsible that was really just you  :)
[14:52] <Mirv> mterry: I responded to the bug now once though, explaining how the team was the best fit of the existing teams I could think of - that is, it has at least two other active Ubuntu (technical) contributors that care about the package or the functionality it provides
[14:52] <ginggs> this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test)
[14:53] <ginggs> although the changelog entry is rubbish, i think we've established it isn't about ram
[14:54] <mterry> Mirv, oh didn't read bug comment
[14:55] <mterry> Mirv, that's fine then.  I just wanted to raise the point.  If you like that team, it's good enough for me
[14:55] <Mirv> mterry: ok then. thank you for raising it, it's always good to ask.
[14:56] <doko> ginggs, disable the tests on powerpc ;p
[14:57] <ginggs> doko: this version worked on a porterbox, shall i just upload it and see what happens?
[14:58] <doko> ginggs, how does it differ?
[14:59] <ginggs> err look at the diff? what do you mean?
[15:00] <doko> cjwatson, thanks for fixing the click mess =)
[15:01] <cjwatson> doko: Rather belatedly :)
[15:01] <cjwatson> I think it's mostly out of the way now but will probably require an adjustment to the p-m hint.
[15:15] <doko> pitti, python-numpy/pynfft is red, but the test is green
[15:16] <ginggs> doko: just to be clear, shall i upload petsc with the 2 process test disable? it is ready to go
[15:17] <doko> ginggs, but just disable it on powerpc. I fear at some point we'll have to remove the powerpc builds again
[15:20] <doko> pitti, looks like adt doesn't understand "Test-Command" on it's own? see python-pywcs
[15:22] <ginggs> doko: i can't think of an easy way to selectively apply a patch by arch.  i did post a link to the diff if you scroll up a bit.  this version i have tested on a porterbox, any big changes and i'd need to start from scratch
[15:24] <doko> ginggs, repaste?
[15:24] <ginggs> doko: [17:01:01] <ginggs> this should make petsc build https://launchpadlibrarian.net/237387369/petsc_3.6.2.dfsg1-3_3.6.2.dfsg1-3ubuntu1~ppa1.diff.gz (it skips the 2 process test)
[15:30] <pitti> doko: pynfft> I'll try to re-run proposed nfft against proposed numpy
[15:31] <doko> ginggs, is it really limited ram?
[15:32] <GunnarHj> mapreri: Hi Mattia, any thoughts on my latest comment on bug #1510198?
[15:32] <ginggs> doko: no no, i explained earlier the changelog entry is rubbish, it is fixed in the version ready to upload (along with removal of ~ppa from the version)
[15:34] <doko> ginggs, then go ahead
[15:34] <ginggs> doko: roger roger
[15:36] <pitti> doko: adt does understand Test-Command:; but as the log says, python-pywcs does't have any tests in xenial-release
[15:37] <pitti> that's indeed a nasty case which britney can't detect by herself, re-running
[15:42] <caribou> rbasak: I can't push my new clamav git repo to the previous one, the tags will collide
[15:42] <caribou> rbasak: want me to delete the previous one & recreate ?
[15:46] <bdmurray> happyaron: I figured out what bug it fixes my point was the upload was generated incorrectly, probably not on Ubuntu, so there is not a Launchpad-Bugs-Fixed field in it. Subsequently, the SRU report won't link to the bug, tools won't comment on it and the LP janitor won't close it.
[15:47] <nacc> slangasek: let me rewrite it in a better form for you!
[15:48] <nacc> slangasek: i apologize, i'll break it up by where the sync points are
[15:49] <rbasak> caribou: feel free to force push the tags. I would just do that.
[15:49] <rbasak> caribou: it only matters to those following the tags, and that's just us right now.
[15:49] <rbasak> Or if you like append .v2 onto the collided tags or something.
[15:49] <nacc> slangasek: cjwatson: infinity: for the purposes of php5 -> php7, are you ok if i send a merge proposal to demote/promote appropriately in the seeds now (as opposed to once the bootstrap and side builds are done) (with an eventual bug to altogether remove php5* from the archive?)
[15:50] <caribou> rbasak: want me to push it to a new branch ? or just force overwrite everything ?
[15:50] <rbasak> caribou: you can force overwrite everything if that's easiest.
[15:50] <caribou> rbasak: since I restarted from scratch
[15:50] <nacc> rbasak: can you (i should have emailed, sorry!) put up git trees for numactl and logwatch (so i can send the former's merge request and eventually logwatch's)?
[15:50] <rbasak> caribou: or just push to a new "repo". Anything you want :)
[15:50] <caribou> rbasak: fine
[15:52] <nacc> slangasek: also, i probably will need to update all the debdiffs to have the latest pkg-php-tools and php-pear versioned deps (to force the php7 versions)
[15:52] <rbasak> nacc: sorry, I'll do that now.
[15:52] <nacc> rbasak: no need to apologize!
[15:58] <rbasak> nacc: I've done numactl, I think. Please could you check that my tags and branches match our current expectations? I've also documented what I think is our current status in https://github.com/basak/ubuntu-git-tools/blob/master/SPECIFICATION
[15:59] <rbasak> I haven't imported the Ubuntu branches. I could, but I think it'd be easier if you did that. It won't matter that we won't have an official import/... tag for our process I think.
[16:05] <nacc> rbasak: looks right to me
[16:10] <caribou> rbasak: I pushed a new merge-v2 branch & updated the tags towards it
[16:11] <rbasak> Argh, I just screwed it up.
[16:11] <rbasak> Will fix in a moment.
[16:12] <rbasak> (numactl)
[16:23] <rbasak> nacc: numactl fixed, and I've pushed logwatch. I can't delete the master branch (as it's HEAD, and there's no protocol way for me to change that), but pretend it doesn't exist.
[16:23] <rbasak> nacc: apart from that I updated logwatch to fit our workflow for merge number 2 - you should be able to rebase the old logical delta as expected.
[16:26] <doko> pitti, openmpi/esys-particle: again, the version from testing is tested, not the fixed one in proposed. what's the rationale for testing with the release pocket first?
[16:26] <doko> openmpi/liggghts the same
[16:27] <doko> openmpi/lammps the same
[16:28] <doko> I assume, just retrying won't help here
[16:35] <doko> sil2100, please could you chase https://bugs.launchpad.net/ubuntu/+source/libgee/+bug/1502094  we really should that get fixed before the release. now having two versions ...
[16:37]  * rbasak figured out out to delete master
[16:58] <doko> sil2100, also https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1545078
[17:01] <rharper> it is considered bad form to leave an ADT test program (shell) with execution tracing on?  when/if the test fails the log with the trace would be most useful to avoid having to run it again to debug the failure
[17:04] <rharper> jderose: thanks!  Nice write up
[17:04] <sil2100> doko: hmmm, thanks, let me pick that up
[17:04] <doko> sil2100, attaching patches
[17:04] <jderose> rharper: my pleasure, thanks again for the help!
[17:05] <rbasak> rharper: I think it's good to leave it on. Similarly we try to do builds with (reasonable) verbosity on.
[17:05] <rbasak> rharper: you may need "allow-stderr" defined on the test though. I don't remember if "set -x" writes to stdout or stderr.
[17:05] <rharper> rbasak ok;  I do have that
[17:06] <rbasak> (IMHO, allow-stderr should have been the default)
[17:06] <rharper> one more todo on strongswan; dropping lfcgi and clearsilver-dev
[17:06] <rharper> oh, another question
[17:07] <rharper> a few of the plugins extend /usr/lib/ipsec/charon binary's required access to files and capabilities that aren't in the default apparmor profile
[17:07] <rbasak> We've hit this sort of thing before. It seems to be acceptable to add stuff to the default apparmor profile even if it isn't used by default.
[17:07] <rharper> the plugin that does this isn't installed by default;  how best to append these additional requests in the apparmor profile for only when the plugin is installed
[17:07] <rharper> rbasak: ok
[17:08] <rharper> one other thought was the include a #include libstronswan-plugin
[17:08] <rbasak> (it might be worth leaving a comment or two explaining the use though)
[17:08] <rharper> hrm
[17:08] <rharper> rbasak: right, in the changelog as well as the profile
[17:08] <rbasak> That might work too. I've done it the former way. I'd ask the security team for their thoughts on the latter way.
[17:09] <rharper> ok, I'll likely follow the former with comments in the profile; they may suggest the alternative then
[17:09] <tyhicks> I wouldn't add a new libstrongswan-plugin abstraction if the default strongswan profile is going to be the one and only consumer of that abstraction
[17:10] <tyhicks> just document that the group of added rules are for certain plugins
[17:10] <rbasak> Thanks tyhicks!
[17:10] <tyhicks> no problem
[17:11] <rharper> tyhicks: thanks!
[17:13] <rbasak> lamont: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016214.html
[17:15] <cjwatson> pitti,infinity: Could you apply http://paste.ubuntu.com/15027019/ to my hint file?  Won't quite work yet but hopefully will soon
[17:26] <infinity> cjwatson: Sure.
[17:32] <ginggs> doko, cjwatson: petsc, slepc and aster built successfully, now retrying getdp
[17:32] <doko> ginggs, you have to wait until it's published
[17:33] <ginggs> doko, itchy trigger finger :)
[17:36] <cjwatson> infinity: thanks
[17:36] <infinity> cjwatson: I assume this is the "rename click, so we don't have to keep renaming click" transition?
[17:36] <cjwatson> Yay, that worked.
[17:36] <infinity> cjwatson: If so, thanks!
[17:36] <cjwatson> infinity: Yup
[18:01] <ginggs> how can i tell when something is really published?  I must be looking in the wrong place on launchpad.  Also, why don't things fail with dep-wait any more?
[18:02] <cjwatson> ginggs: rmadison is the safest check; LP itself can only tell you when something is committed at the start of a publisher run, not when it hits disk
[18:02] <cjwatson> ginggs: and things do dep-wait, but there have always been exceptions that are hard to analyse correctly.  do you have an example?
[18:03] <ginggs> cjwatson: thanks - well i'm looking at https://launchpad.net/ubuntu/+source/getdp/2.7.0-0ubuntu2
[18:04] <nacc> rbasak: ok, thanks!
[18:04] <ginggs> powerpc shows the red failed build icon
[18:05] <ginggs> i seem to recall a yellow icon for dep-wait, or am i just confused?
[18:05] <cjwatson> ginggs: right, that's a case where we can't dep-wait; libslepc3.6.1-dev is available on powerpc but uninstallable, and as far as LP knows that could be resolved in any of various ways
[18:06] <cjwatson> ginggs: you get a dep-wait if the build-dep is just outright missing
[18:06] <ginggs> ah ok, that explains it
[18:19] <lamont> rbasak: yeah yeah
[18:20] <nacc> slangasek: how do i do the versioned dep for php-pear? the old binary package (built from src:php5) had versions like 56.11+dfsg-1ubuntu3. The new package (built from src:php-pear) has versions like 1.10.1. Should I do an exact match (meaning only in the 1.10.1 family? >= won't work, because i think the older package will match, if I understand it right?
[18:21] <lamont> rbasak: amusingly, that's what I'm working on right now
[18:29] <lamont> nacc: I suspect that the new version is actually 1:1.10.1, since the archive would reject it if it had a binary package of a higher version in the archive...  (without looking at the details myself)
[18:30] <nacc> lamont: ah! that's what i was missing. so they bumped, the epoch, basically?
[18:30] <nacc> lamont: and the old package had an implicit 0: epoch?
[18:31] <lamont> if not specified, it's (effectively) 0:.  and the UI hides it most everywhere
[18:31] <nacc> lamont: does that mean i can specify my build-dep as 'php-pear (>= 1:)' ?
[18:31] <lamont> generally, one would want >= 1:1.10.1 or such
[18:32] <nacc> i guess that's true, the first officially released version
[18:32] <nacc> lamont: thanks!
[18:32] <lamont> apt-cache policy php-pear <-- shows epoch, and there are other ways to see
[18:32] <lamont> heh.  starting with dpkg -l :(
[18:35] <bdmurray> kenvandine: Will you have a look at https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/285016?
[18:40] <kenvandine> bdmurray, i have that in a silo
[18:40] <kenvandine> haven't had a chance to test it though
[18:41] <kenvandine> bdmurray, but i should have it ready for qa early next week
[18:41] <bdmurray> kenvandine: okay, thanks!
[18:41] <kenvandine> bdmurray, thx for nagging me :)
[18:42] <kenvandine> i don't pay much attention to lxc-android-config, not sure if anyone is these days
[18:56] <Pharaoh_Atem> nacc: have you been updating the etherpad on the php stuff that's succeeded/failed?
[18:56] <Pharaoh_Atem> I don't see anything there
[18:57] <nacc> Pharaoh_Atem: no, i need to go and do that
[18:58] <nacc> the bug has been where i've been trying to document
[19:13] <slangasek> seb128: ummmm. I'm maintainer of freetype because it was a library that needed attention, I know almost nothing about fonts ;)
[19:15] <slangasek> nacc: MP for the seeds> fine to have that in advance.  php-pear versioned deps> the 1: at the front of that version number shown in the changelog is called an epoch, it matters for versioned comparisons and is a reset button on the version numbering.  So you want >= 1:1.10.1 for your versioned dep
[19:15] <nacc> slangasek: great, thanks!
[19:16] <nacc> slangasek: i put out a debdiff for pkg-php-tools, if that looked right to you, i'll update the other debdiffs to version php-pear and pkg-php-tools correclty
[19:16] <nacc> and i apologize for that, nuance i missed in working with just my PPA
[19:17] <slangasek> nacc: pkg-php-tools is already uploaded; I didn't think any further changes were needed on that one? it's already dep-wait in xenial-proposed
[19:18] <nacc> slangasek: ah ok, you're right, sorry ...
[19:18] <nacc> slangasek: but if i do the versioning right, then, they will all just dep-wait in -proposed until php-pear gets fixed?
[19:18] <nacc> "they" => the other packages
[19:18] <slangasek> nacc: yes
[19:20] <nacc> slangasek: can i ask you to review the seed merge for the php migration?
[19:22] <slangasek> nacc: juggling a couple of other critical things at the moment; if you drop me the URL to the MP I'll pick it up
[19:22] <nacc> slangasek: sure, i can also ask smoser or someone else, but figured you'd have the most context right now
[19:23] <nacc> slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285931
[19:24] <smoser> nacc, i just loaded that page and it says conflicts all over it
[19:25] <smoser> i assume that is not intended
[19:25] <nacc> smoser: hrm!
[19:25] <nacc> no not intended at all!
[19:25] <nacc> let me look at what i did wrong
[19:26] <nacc> smoser: argh! lp automatically chose to use platform.xenial again! fixing up
[19:26] <smoser> :)
[19:27] <nacc> smoser: slangasek: https://code.launchpad.net/~nacc/ubuntu-seeds/ubuntu.xenial/+merge/285932
[19:27] <nacc> sorry again!
[19:30] <smoser> well, that one looks better
[19:30] <nacc> :)
[19:30] <smoser> it looks generally sane to me. i'd really rather hvae slangasek do it, although its jsut about as straight forward as could be. s/5//
[19:31] <nacc> smoser: right, and i think the result (if i understand it right) is that both php-defaults and php7.0* will be in main ... but not sure how that all works (it's all still in the realm of 'magic' to me)
[21:10] <lamont> when did we change it so that non-root can reboot the box with simply 'reboot'
[21:14] <nacc> slangasek: ok, updated instructions posted at: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4
[21:14] <nacc> slangasek: i'll work on updating the debdiffs to version the deps now
[21:16] <nacc> slangasek: hrm, should i be submitting debdiffs even for the "rebuild" packages? since they will only rebuild properly if we use the version of pkg-php-tools and php-pear that support php7?
[21:19] <infinity> lamont: I think physical console users have been able to do that for quite a while.
[21:23] <lamont> ok
[21:24] <lamont> I guess I've always thrown an sudo in front of it...
[21:30] <slangasek> lamont, infinity: that would have to be when we switched to systemd, because the upstart implementation didn't hook into policykit etc
[21:30] <rharper> non-root on systemd says permission denied to /dev/initctl
[21:30] <rharper> when attempting reboot
[21:31] <rharper> ssh login; but doubt that local console will give access to /dev/initctl ;  which is a link to/run/systemd/initctl/fifo; which is prw------- 1 root root 0 Feb 12 21:29 /run/systemd/initctl/fifo;
[21:31] <cjwatson> I think that's only if it can't contact systemd using dbus
[21:31] <cjwatson> on a local console, I'd expect dbus to be available
[21:31] <rharper> huh
[21:32]  * rharper doesnt' really want to try on his laptop 
[21:32] <rharper> but I'm terribly interested
[21:32] <cjwatson> /dev/initctl is definitely fallback code in systemd
[21:32] <rharper> it tries others
[21:33] <rharper> first, Interactive authentication, logind, and then reboot.target; which all require interactive authentication;
[21:33] <infinity> Anyhow, it makes sense as a console policy, given we let people reboot from the display manager and the desktop sessions.
[21:33] <rharper> yeah
[21:33] <lamont> slangasek: ah!
[21:33] <infinity> Though I think we also block users from rebooting if *other* users are also logged in.
[21:33] <infinity> IIRC.
[21:33] <lamont> this was a window on the desktop
[21:46] <nacc> infinity: i think i need to transfer my discussions of the php5 -> php7 migration from slangasek to you or another admin :)
[21:46] <infinity> nacc: Indeed, slangasek is about to be attacked by babies.
[21:47] <nacc> infinity: :) i'm working on updating my debdiffs to version depend on the right pkg-php-tools package (which is already in dep-wait in proposed)
[22:18] <teward> cjwatson: can I pick your brain on sbuild, for a minute, in case you know the answer to my question?  I'm happy to go to an offtopic channel or PM to ask if you'd prefer, as it's not 100% an Ubuntu-related question
[22:20] <nacc> infinity: so i have a couple of questions i posed to slangasek earlier, that i'd like to ask you if you don't mind?
[22:29] <ilhami> hey guys.
[22:36] <ilhami> when will Ubuntu allow non-canonical apps to run in the background?
[22:37] <sarnold> ilhami: try #ubuntu-touch
[22:38] <ilhami> sarnold, I can't.
[22:38] <sarnold> ilhami: why not?
[22:38] <ilhami> banned.
[23:05] <infinity> nacc: Sorry, a bit in and out right now.
[23:05] <infinity> nacc: If you're around later, perhaps.  Or tomorrow?  Or Monday?
[23:10] <nacc> infinity: sure, i'll do my best. it's a holiday here on monday, but i might be able to check in at least a bit
[23:11] <nacc> infinity: i've done my best to update the instructions at https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4570466/+files/php7-archive-admins.howtov4
[23:11] <nacc> which should get the b-d loops closed off in a side build (with sequence points)
[23:30] <mapreri> GunnarHj: my thoughts are that most of the requests are reasonable.  I'll consider them better once the last upload of a couple of days ago get out of NEW (due to new dictionary=>new binary).
[23:31] <mapreri> I'd really love if Sweetshark (=> Björn, current owner of that bug) would comment on #1510198 :\
[23:32] <mapreri> ginggs: btw, if you have something to say about stuff I do in debian and then get synced here feel free to nag me ;) (though I'm not connected on freenode as often as on OFTC, I have my bouncer here too :P)
[23:40] <GunnarHj> mapreri: Sounds great. I think that some of the proposed changes in debian/control are important to allow for a pure sync, while others are 'negotiable'. I'm not an expert on the exact meaning of those fields.
[23:40] <GunnarHj> Yeah, a comment from Sweetshark would be great. OTOH I can't think of a reason why he would keep hesitating.