[00:08] <nacc> slangasek: actually, for those packages that only require sed, you mentioned i can hve one bug that lists them all. Should it have a debdiff for each package?
[00:08] <slangasek> nacc: I don't remember discussing sed... we talked about no-change rebuilds, not quite the same thing?
[00:14] <nacc> slangasek: right, so there's one set of packages that are nochange
[00:15] <nacc> but then once the bootstrap is done for phpunit/symfony/doctrine, there's a few hundred pakcages that at least on first view build with a  simple sed of their d/rules and d/control files to go from php5-* to php-*
[00:15] <slangasek> ah
[00:16] <nacc> i can do a bug per package, but we talked about that being overkill probably
[00:16] <slangasek> nacc: I'm happy with a flat list of those packages in a single bug, provided you have already tested on your side that running the sed over those packages gives a result that's both buildable and installable
[00:17] <nacc> alright, i'll work on that next
[00:17] <slangasek> and I'll put your name in the changelog for all of these uploads ;)
[00:21] <nacc> slangasek: 100% on board with that :)
[00:41] <robert_ancell> how often does the proposed migration run?
[00:47] <slangasek> robert_ancell: "as often as it can"; it's on a 1 minute cron, but individual runs take longer than that and can take /much/ longer depending on what all is clogging up -proposed
[00:48] <slangasek> the current britney run started 1 minute ago, however
[00:49] <robert_ancell> slangasek, ok, cool. The excuses showed it last ran ~25 mins ago, was wondering when the next run would be
[00:54] <robert_ancell> :( missed that run. Maybe in another 25mins...
=== alexisb is now known as alexisb-afk
[01:16] <cjwatson> Laney: I forgot to say, the improved uncompressed index files stuff is on LP production now.  Could you please retry your DEP-11 client?
=== xnox_ is now known as xnox
[02:36] <cherylj> mwhudson: just FYI - I think the juju env I was in was using old xenial images
[02:37] <cherylj> mwhudson: I rebootstrapped specifying "daily" images, and I don't see the same ssh -t problem
=== TheMuso` is now known as TheMuso
[03:31] <alexlist> some context to https://bugs.launchpad.net/debian/+source/squid3/+bug/1544400
[03:31] <ubottu> Launchpad bug 1544400 in squid3 (Ubuntu) "squid3: systemctl reports squid is running when there is a bungled squid.conf and it has exited." [Undecided,Confirmed]
[03:31] <alexlist> 1) install squid3 (wily)
[03:31] <alexlist> 2) systemd is able to start/stop squid3
[03:32] <alexlist> 3) change the config to make squid startup fail
[03:32] <alexlist> 4) neither manual nor systemd startup of squid3 work
[03:32] <alexlist> 5) fix the config
[03:32] <alexlist> 6) manual startup works, but systemd is not able to start squid again
[03:32] <alexlist> This is really hard to reproduce and find. The bug report contains a link to the respective Debian bug...
[03:36] <sarnold> alexlist: please paste that into the bug report ;) that's far from obvious..
[05:01] <chiluk> are any launchpad ops awake?
[05:02] <chiluk> if so i'd appreciate a launchpad op take a look at getting https://launchpad.net/ubuntu/+source/ceph/0.80.11-0ubuntu1.14.04.1  published..
[05:03] <alexlist> sarnold: done
=== rww is now known as rw
=== rw is now known as rww
=== \b is now known as benonsoftware
[06:45] <dholbach> good morning
[07:10] <Mirv> pitti: ppc64el autopkgtests seem stuck, same 16 "in progress" as in the evening at https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-032/excuses.html
[07:52] <pitti> Mirv: ppc64el was down Tue and yesterday, I had to kill a few jobs; I'll put them back
[07:52] <pitti> Good morning
[07:54] <pitti> meh, the workers are all down again
[08:12] <doko> kirkland, https://launchpad.net/ubuntu/+source/ssh-import-id/5.0-0ubuntu1  ftbfs, now for nearly two weeks
[08:16] <pitti> ok, this new cron job should revive the ppc64el workers every night until the images get fixed for good
[08:42] <mwhudson> cherylj: oh ok
[08:42] <mwhudson> cherylj: i guess that's a good-ish outcome
[08:46] <pitti> doko: err @ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gccgo-6
[08:46] <pitti> doko: I don't think gcc-go is supposed to build gcc-6-base or libgcc1?
[08:47] <Mirv> the autopkgtest queues seems respectably big again
[08:48] <doko> pitti, it is
[08:48] <pitti> Mirv: yeah, due to ^
[08:48] <doko> split-stack support for s390x
[08:48] <pitti> doko: but won't they flip between gcc6 and gccgo-6 sources then?
[08:49] <doko> we won't have a gcc-6 source in xenial
[08:49] <pitti> well, still
[08:49] <doko> ?
[08:49] <pitti> we do have libgcc1, and it should come from our default C compiler, not from a non-default Go  compiler
[08:50] <LocutusOfBorg> ginggs, wilco
[08:50] <doko> same thing as for gcc-4.8 / gccgo-4.9 in trusty
[08:51] <pitti> doko: so why is this?
[08:51] <doko> pitti, libgo9 needs libgcc1 (>= 6)
[08:52] <doko> pitti, if you would like to spend time on toolchain maintenance, maybe better work on demoting gcc-4.8 and gcc-4.9?
[08:53] <pitti> well, I just asked a question, as this is by far not obvious..
[08:53]  * pitti adjusts britney's hack for not triggering $world on gccgo-6 then
[08:54] <doko> I even verified that the new libgcc1 is not empty ;p
[08:58] <pitti> ok, hack in place and queues flushed
[09:03] <Laney> cjwatson: Oh yes, I noticed - and it tickled a bug in the client which I fixed - thanks!
[09:09] <pitti> Laney: sigh @ workers dying again -- what is it now, auth failure towards swift??
[09:10] <pitti> plus the usual acting up of lcy01 during image rebuilds, but that's known
[09:15] <Laney> pitti: BadStatusLine?
[09:15] <pitti> some network glitch I presume
[09:15] <pitti> swift list works fine on wendigo, I'll just restart and pretend I didn't see it the first time
[09:16] <Laney> la la la
[09:17] <Laney> hmm, how do I get debmirror to mirror Components and icons?
=== s1aden is now known as sladen
=== bigon_ is now known as bigon
[09:59] <ricotz> doko, hi, I am not allowed to get more archs enabled for this aptitude builds -- https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6059699/+listing-archive-extra
[10:06] <doko> ricotz, ok, that looks fine
[10:08] <ricotz> doko, thanks
[10:10] <ricotz> doko, ah, do you mind making me admin too in https://launchpad.net/~libreoffice/+members
[10:12] <doko> please ask Sweet5hark
[10:13] <ricotz> yeah did so too (let's when isn't away anymore)
[10:17] <doko> pitti, please ignore the ruby-rjb autopkg test failure; now reported to debian as well
[10:17] <ricotz> doko, also could you delete the superseded "gcc-6 - 6-20160117-1ubuntu1" from https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+packages
[10:17] <doko> when I have a new version, yes
[10:18] <pitti> doko: ok, adding a hint; OOI, do we aim for jdk8 in xenial? i. e. ignore some packages which get broken by it?
[10:18] <pitti> doko: (asking because of jsurf-alggeo
[10:18] <pitti> doko: ah, that's already hinted
[10:18] <ricotz> doko, there is a new version "gcc-6 - 6-20160206-0ubuntu11"
[10:18] <pitti> doko: libo/s390x is unrelated, I'll ignore that
[10:19] <ricotz> doko, this is to avoid overriding some exclusive libs from gcc-5
[10:19] <doko> pitti, yes. it's unfortunate to add 8 with 9 on the horizon, but 5 more years 7 ... no thanks
[10:20] <pitti> doko: ack
[10:20] <ricotz> doko, libmpx0 and lib32mpx0
[10:20] <pitti> doko: ruby-rjb is a leaf package; should we remove it then, if it's known to not work with jdk8?
[10:22] <pitti> doko: I'll let java-common in then
[10:22] <doko> pitti, works on amd64
[10:22] <pitti> doko: ok; "don't care" then :)
[10:22] <doko> but yes, we could remove it on i386
[10:22] <pitti> (i386 on a server → not really a thing)
[10:23] <pitti> doko: ok; I'll remove the binary; once Debian gets a new version, it'll come back automatically
[10:23] <pitti> doko: *flush*, removed
[10:24] <Laney> laney@cripps> dpkg-architecture -qDEB_HOST_ARCH                                                                                                                                                     ~
[10:24] <Laney> i386
[10:28] <pitti> Laney: do you use ruby-rjb there? :-)
[10:28] <Laney> no, that's not the line I was challengeing
[10:28] <Laney> -e
[10:28] <Laney> It's we don't care about server things for i386 because that doesn't exist
[10:33] <doko> pitti, barry, jtaylor, tumbleweed: so either we make some progress fixing python-numpy related autopkg tests, or we push it ...
[10:44] <pitti> doko: I hinted a few more broken tests, but numexpr and pyresample look real
[10:45]  * pitti currently runs them locally to confirm
[10:45] <doko> pitti, numexpr is weired. tests depend on python-pkg-resources, but it's not installed
[10:46] <pitti> indeed; I thought I already fixed that the other day, but maybe that was a different package
[10:47] <pitti> debian bug 812726
[10:47] <ubottu> Debian bug 812726 in numexpr "[PATCH] Fix autopkgtest" [Normal,Open] http://bugs.debian.org/812726
[10:47] <pitti> ... clearly not, I'll reopen and upload a fix
[10:48] <pitti> ah, it works when enabling all of -proposed
[10:48] <mardy> pitti: hi! I'm getting this error when running tests with libqtdbusmock (qt wrapper for python dbusmock): http://paste.ubuntu.com/15015374/
[10:48] <mardy> pitti: it doesn't happen all of the time, just sometimes, maybe 50% of the times
[10:48] <mardy> pitti: is it anything familiar?
[10:49] <doko> pitti, and openmpi maybe has two more to ignore ...
[10:50] <pitti> doko: ok, numexpr should go green
[10:50]  * pitti runs pyresample
[10:51] <pitti> doko: yep, already hinted during my daily "go through excuses" sweep
[10:57] <Unit193> Is it just me or is https://launchpadlibrarian.net/235789470/buildlog_ubuntu-xenial-amd64.ruby-rest-client_1.8.0-2_BUILDING.txt.gz only failing due to no network during tests?
[10:59] <LocutusOfBorg> Unit193, also https://launchpadlibrarian.net/237839768/buildlog_ubuntu-xenial-amd64.ruby-omniauth-azure-oauth2_0.0.6-1_BUILDING.txt.gz
[10:59]  * LocutusOfBorg is looking to see gitlab migrate
[11:00] <Unit193> Fun times.
[11:14] <doko> pitti, and maybe hint jquery? test failures don't look like jquery related (usually used in the docs only)
[11:27] <pitti> doko: jquery is already a valid candidate
[11:28] <pitti> (landed 4 mins ago)
[11:32] <ginggs> pitti, doko: i think python-scientific should be removed
[11:36] <Mirv> pitti: an optimization question that might be silly: couldn't a package be declared Valid Candidate already when the only remaining running tests are a) either always failed or b) overridden?
[11:36] <pitti> Mirv: that's already the case
[11:37] <Mirv> pitti: oh, ok, great! and right, I now found one claimed regression, unity-scope-click - https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-032/excuses.html
[11:37] <pitti> Mirv: it's the ... that
[11:37] <pitti> Mirv: I just retried that
[11:37] <Mirv> :)
[11:37] <pitti> just> maybe some 15 mins ago
[11:37] <pitti> http://autopkgtest.ubuntu.com/running.shtml#pkg-unity-scope-click
[11:37] <pitti> 11 mins :)
[11:37] <Mirv> pitti: wonderful, anyway. as train is naturally heavier with more testing, it's great to know it's pretty smooth overall despite the machinery that runs.
[11:38] <pitti> Mirv: -gles is already a valid candidate
[11:38] <Mirv> it's really rocking now, aside from the noticed issue yesterday with proposed/release clashing
[11:38] <pitti> Mirv: hoping that the u-s-c one succeeds after a few retries; I think that one has always been flaky, right?
[11:38] <Mirv> pitti: my memory says that red has been seen earlier in various excuses lists, yes
[11:39] <pitti> Mirv: ... or when the ppc64el ones go AWOL :)
[11:39] <Mirv> (regarding u-s-c)
[11:39] <pitti> http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/xenial/armhf/
[11:39] <pitti> it's a fairly hard gambling :/
[11:40] <Mirv> yes, poor ppc64el machines, almost like our jenkins' phone hardware
[11:40] <pitti> well, as long as they work they are actually quite fine
[11:40] <doko> ginggs, https://bugs.launchpad.net/ubuntu/+source/python-scientific/+bug/1542928
[11:40] <ubottu> Launchpad bug 1542928 in python-scientific (Debian) "python-scientific should be removed" [Unknown,Confirmed]
[11:40] <pitti> but our current images are broken, so everytime we get a new cloud image they all fail until I manualy build a newer one with a hack
[11:41] <pitti> I cronned that now, so should hopefully not hit so hard any more
[11:41] <ginggs> doko, i saw that.  can we do it?
[11:42] <pitti> Mirv: please prod me if it's still broken this afternoon, then I'll hint it
[11:42] <pitti> I mean, fix your tests or silently get broken by other packages :)
[11:42] <doko> ginggs, can you fix debian-med and debian-science?
[11:43] <ginggs> lemme look, if they are what i think they are, they just have recommends not depends. but let me confirm
[11:45] <doko> ginggs, you have to adjust tasks/*
[11:45] <doko> reverse-depends tells you which ones
[11:45] <Mirv> pitti: ok, I can retry a couple of times as well. was it that there is no way to find links to past silo autopkgtests at http://autopkgtest.ubuntu.com/packages/u/unity-scope-click/ ? I mean, I haven't found where to find test result after it disappears from running.shtml, before the hourly silo excuses page update
[11:46] <pitti> Mirv: silos aren't on a.u.c.
[11:46] <pitti> Mirv: the logs are still there, but a bit buried on swift
[11:47] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-032?format=plain&prefix=xenial/armhf/u/unity-scope-click
[11:47] <pitti> foor example
[11:48] <pitti> I think that's the one you want to look at
[11:49] <Mirv> pitti: thank you for the url! I tried experimenting from the final log url but didn't find anything useful
[11:50] <doko> sil2100, fyi, just mad no-change uploads for unity-scopes-api, unity-scope-mediascanner, unity-scope-click
[11:50] <pitti> ginggs: replied to the p-scientific removal bug
[11:51] <sil2100> doko: for the libjsoncpp transition? Those are in a silo
[11:52] <ginggs> ok doko, i see science-distributedcomputing, science-engineering-dev, science-meteorology, science-nanoscale-physics, science-viewing and science-viewing-dev but they are all reverse-recommends so i think no action is required.  I recall discussing a similar situation with cjwatson some months ago
[11:52] <sil2100> Waiting for sign-off since normal no-change rebuilds in the archive won't cut it, as their ABI checks will cause the scopes-api package to FTBFS
[11:52] <sil2100> doko: anyway, all of those are ready in the train and will be landed soon
[11:52] <doko> sil2100, ok, I'll let the builds fail
[11:57] <Mirv> pitti: ok I can indeed now real time monitor unity-scope-click both during and after a run, thanks. rerunning a few times over the afternoon.
[11:57] <pitti> Mirv: as I said, if it's that flaky, we can also hint it
[11:58] <Mirv> I'll ping if it seems too flaky. hmm, and seeing about a bug report
[11:59] <sil2100> doko: the CI Train silo with those is in QA testing now, so we should hopefully have it landing in the xenial archive in the nearest hour
[12:00] <cjwatson> Laney: Excellent, I'll mark my card for that done then.
[12:00] <doko> LocutusOfBorg, are you looking at https://launchpad.net/ubuntu/+source/insighttoolkit4/4.9.0-1ubuntu1 ?
=== _salem is now known as salem_
[12:01] <cjwatson> Laney: debmirror> you could file a bug for the new debmirror maintainer to look at *coughcough*
[12:01] <doko> pitti, is this one easy to fix, or should we just remove it? https://launchpad.net/ubuntu/+source/orthanc-postgresql/2.0-1build1
[12:01] <LocutusOfBorg> doko, refreshing each minute or so
[12:01] <LocutusOfBorg> I did revert amd64 slowliness
[12:01] <Laney> cjwatson: I tried hacking it in where it deals with i18n stuff but it wasn't that straightforward :)
[12:01] <Laney> cjwatson: new maintainer> good idea, he seems full of enthusiasm
[12:02] <LocutusOfBorg> if amd64 builds it should build in less than one week now, I'm not sure why you disabled parallel builds
[12:02] <pitti> doko: no response to debian bug 811141 in almost a month, so I'd say demote-to-proposed (removed from Debian testing)
[12:03] <ubottu> Debian bug 811141 in orthanc-postgresql "FTBFS: CMake Error: The following variables are used in this project" [Serious,Open] http://bugs.debian.org/811141
[12:03] <pitti> doko: doing
[12:03] <LocutusOfBorg> and for i386 failure we have a fix in gccxml, waiting for Gert to upload it on debian
[12:12] <ginggs> LocutusOfBorg: iirc parallel builds were disabled because of a lack of memory
[12:24] <cjwatson> doko: You can ignore the unity-scope-click/unity-scopes-api etc. build failures in the primary archive - that's being sorted out in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-037/+packages
[12:24] <cjwatson> doko: Oh, sorry, sil2100 already said that
[12:35] <pitti> smoser: did we talk about merging open-iscsi? or was that someone else? either way, https://tracker.debian.org/news/747283 took a lot of our changes, I think the remaining delta is just the autopkgtest addition
[12:47] <pitti> apw: hm, just started looking at bug 1542833
[12:47] <ubottu> bug 1542833 in Auto Package Testing "running.json queues not populated" [Undecided,New] https://launchpad.net/bugs/1542833
[12:48] <pitti> apw: I stopped all workers and submitted a few tests, so that http://autopkgtest.ubuntu.com/running.shtml has 5 queued tests now
[12:48] <pitti> apw: and http://autopkgtest.ubuntu.com/running.json has those too
[12:48] <pitti> I first tried to reproduce in juju-local, but running.json looks good there too
[12:49] <pitti> apw: can you exclude the possibility of having looked at an older running.shtml, i. e. you didn't reload or something such?
[12:50] <pitti> apw: erk, ignore me
[13:13] <pitti> apw: fixed
[13:13] <apw> pitti, yay
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:41] <smoser> pitti, we have talked. and that is great.
[13:41] <smoser> i had plan to merge it. i want to get an dep8 test that would pull ubuntu image and iscsi root boot it.
[13:54] <doko> pitti, could you have a look at the failing tests triggered by mpi-defaults? do these messages come from adt?
[13:54] <doko> same messages for all three packages
[13:56] <Mirv> pitti: got unity-scope-click to pass, once. then I accidentally reloaded the retry page and it failed again :) but meanwhile excuses page updated with a pass and QA's script picked the silo into their queue so primary goal achieved.
[13:57] <Mirv> also needed to rerun amd64 kwindowsystem, that passed too then
[14:04] <doko> pitti, ahh, no. this is the updated openmpi
[14:07] <barry> doko, pitti did you get the numpy stuff sorted out?
[14:09] <pitti> Mirv: yes, if it passes once, that's good enough for excuses
[14:09] <pitti> Mirv: ah, valid candidate
[14:10] <pitti> barry: no, pyresample still regresses in -proposed, and that's reproducible locally; the others are sorted out
[14:11] <barry> pitti: ah.  not sure i can help much but i saw the while-i-was-asleep-ping :)
[14:13] <pitti> doko: no, "adt" is just the hostname; something is writing those "2 more processes have sent help message" strings to stderr
[14:13] <pitti> curiously only on md64
[14:21] <doko> ginggs, so you verfied that all these are recommends?
[14:22] <ginggs> i'm going by what reverse-depends reported
[14:23] <ginggs> do i need to doublecheck?
[14:24] <doko> no, ok
[14:30] <ginggs> but i've confirmed in the control files https://sources.debian.net/src/scitools/0.9.0-2/debian/control/ and the science-* metapackages  https://sources.debian.net/src/debian-science/1.4/debian/control/
=== mhall119_ is now known as mhall119
[14:40] <doko> barry, cjwatson: six autopkg tests fail
[14:42] <barry> doko, cjwatson i'll look.  it's probably my fault
[14:44] <barry> looks like a pytest related build failure.  iirc that's because of a ubuntu delta on pytest which i believe i fixed in debian.  i'm working on sync/merges from debian today so i'll drill down on it
[14:52] <ginggs> doko thanks for cleaning up python-scientific
[14:52] <doko> ginggs, do you have news about openmpi on powerpc?
[14:54] <ginggs> i replied to debian bug #814183
[14:54] <ubottu> Debian bug 814183 in src:openmpi "openmpi 1.10.2 is broken on powerpc" [Serious,Open] http://bugs.debian.org/814183
[14:55] <ginggs> petsc failed on the powerpc porterbox with 2GB RAM, but built successfully on a buildd with 5GB RAM
[14:56] <ginggs> how much RAM do the ubuntu powerpc buildds have?
[15:00] <cjwatson> ginggs: sagari has 15GB, the others are VMs and I actually can't remember how much they have but it should be at least 4GB
[15:00] <cjwatson> ginggs: (infinity would know exactly)
[15:00] <ginggs> any chance we could schedule a rebuild of petsc on sagari?
=== vrruiz_ is now known as rvr
[15:05] <cjwatson> ginggs: looking
[15:06] <cjwatson> ginggs: will have to wait, there's a gcc-5 build there at the moment
[15:06] <ginggs> kick it off, doko won't mind :)
[15:06] <cjwatson> (this isn't something I can schedule in advance - the way to force a build onto a particular builder is to put all the other builders on manual and then get it to start)
[15:06] <cjwatson> ginggs: history does not agree with you :P
[15:07] <cjwatson> I get sad every time we have to schedule things on a particular builder, but if this is just memory then by the time powerpc is in scalingstack I guess guests will have adequate memory
[15:08] <pitti> cjwatson: the "ppa" nova flavor has 8 GB, but I suppose that's somehow not applying here?
[15:09] <cjwatson> pitti: that's ppc64el, not powerpc
[15:09] <cjwatson> pitti: and only upgraded to 8GB last night :)
[15:09] <cjwatson> pitti: powerpc scalingstack isn't a thing yet
[15:10] <pitti> oh, manual VMs
[15:10] <pitti> that explains it
[15:10] <cjwatson> yeah
[15:10] <pitti> I thought we ran powerpc on ppc64el instances somehow
[15:10] <cjwatson> no no
[15:10] <cjwatson> the plan is eventually to run it on the same hardware, but it requires different instances because you can't do the endian switch at run-time
[15:10] <cjwatson> and there are some complications with the current scalingstack infrastructure
[15:13] <ricotz> hi, which llvm versions will be kept around in xenial?
[15:21] <doko> I hope, 3.8 only. if we have to, maybe the current default
[15:22] <ricotz> doko, syncing clamav would be nice, but it doesnt like 3.8 yet
[15:23] <ricotz> doko, the current default is 3.8, isnt it?
[15:25] <doko> when it migrates, yes
[15:26] <rbasak> caribou is merging clamav at the moment.
[15:27] <rbasak> Is doko/recotz 's conversation relevant?
[15:27]  * rbasak isn't sure so he thought he'd check
[15:27] <ricotz> rbasak, hardcoding 3.7 should be enough
[15:28] <doko> rbasak, I thought you (server) wanted to port to the default version
[15:28] <doko> but now explicitly using 3.7, where mesa just dropped it?
[15:28]  * rbasak isn't sure
=== alexisb-afk is now known as alexisb
[15:33] <ogra_> hmm, if my kernel properly supports cgroups and is at a recent version, should i still see cgmanager run on my system (i thought it is a fallback thing only)
[15:35] <pitti> ogra_: cgmanager needs cgroups to work, otherwise it's useless
[15:35] <ogra_> pitti, yes, i know
[15:35] <pitti> ogra_: it's mostly a d-bus API for managing those, so that unpriv processes (like user LXC) can create those
[15:35] <pitti> plus the "fake" cgroup/proc/sys fs with lxcfs for containers
[15:35] <ogra_> pitti, but i thought there is another in--kernel mechanism to manage them and cgmanager is only used if thats missing
[15:36] <pitti> no, not really
[15:36] <ogra_> ok
[15:36] <pitti> the in-kernel mechanism is mkdir()/open()/write() :)
[15:36] <pitti> hmm, it seems ligo.org is currently being DDoSed ..
[15:36] <ogra_> heh
[15:36] <pitti> I guess it got hit by a gravitation wave
[15:37] <ogra_> haha
[15:37] <ogra_> trying to watch the stream live ?
[15:37] <pitti> I didn't find a stream URL before -- I'd be content with a live ticker
[15:39] <marlinc> Any chance of getting htop 2.0 in Xenial? http://hisham.hm/htop/
[15:39] <marlinc> :D
[15:41] <caribou> rbasak: doko: ricotz: that's a question I had; which version of llvm should we use; it currently explicitely uses 3.5
[15:41] <doko> caribou, 3.8
[15:42] <ricotz> caribou, please drop all ubuntu patches and use the debian package as base
[15:42] <ricotz> clamav is checking for llvm <= 3.7
[15:42] <caribou> ricotz: I removed a few delta
[15:43] <ogra_> pitti, see pm
[15:45] <ricotz> caribou, e.g. libmspack is in main
[15:51] <caribou> ricotz: yes, that got dropped in the merge
[15:52] <ricotz> caribou, alright, looking forward to the update
=== Zic is now known as Guest81014
[15:58] <ginggs> marlinc: subscribe to debian bug #814401
[15:58] <ubottu> Debian bug 814401 in htop "htop: new upstream 2.0 release" [Wishlist,Open] http://bugs.debian.org/814401
[15:59] <gatisp> hey, anyone knows whats up with "udisks" binary missing from Ubuntu 16 ?
[16:00] <cjwatson> It's there, in the udisks package, though in general it's been superseded by udisksctl in the udisks2 package
[16:00] <cjwatson> (as I understand it)
[16:00] <cjwatson> also, Ubuntu 16 isn't a thing, you probably mean Ubuntu 16.04
[16:00] <cjwatson> oh, wait, the udisks package was in fact removed
[16:01] <gatisp> yeah 16.04
[16:01] <cjwatson> so it's just udisksctl in udisks2 now
[16:01] <gatisp> cjwatson, will try, thanks for the feedback
[16:01] <cjwatson> https://bugs.launchpad.net/bugs/1288253 <- removal log
[16:01] <ubottu> Launchpad bug 1288253 in guymager (Debian) "Eliminate udisks 1 from Ubuntu" [Unknown,Confirmed]
[16:13] <marlinc> Cool ginggs
=== Guest81014 is now known as Zic
[16:43] <cjwatson> barry: pytest doesn't have an Ubuntu delta.  The problem appears to be that the python3-pytest in -proposed doesn't install any modules: see near the end of https://launchpadlibrarian.net/237085197/buildlog_ubuntu-xenial-amd64.pytest_2.8.7-1_BUILDING.txt.gz
[16:44] <cjwatson> barry: so that's kind of busted :)
=== smow is now known as pfsmorigo
=== pfsmorigo is now known as Guest98924
[16:45] <barry> cjwatson: yeah, i know what's going on but i don't have a fix just yet
[16:47] <cjwatson> barry: all right, can you retry python-click (not click) as well once a fix is in?
[16:47] <barry> cjwatson: yep
[16:47] <cjwatson> ta
[18:07] <marlinc> cjwatson, did boot=ZFS= support go into the ZFS packages in Xenial? Saw 'Require root=ZFS= syntax.  rpool= and bootfs= are no longer supported.' in the changelog on my laptop
[18:07] <cjwatson> marlinc: I only do GRUB, I don't know about the rest of the ZFS stuff
[18:07] <cjwatson> (and even then I'm only really doing what other people tell me to do)
[18:07] <cjwatson> I think there's still a patch to the update-grub stuff outstanding
[18:13] <marlinc> Ah, okay :)
[18:14] <marlinc> cThanks anyway
[18:22] <marlinc> cjwatson, do you know of a place where I can define the value of bootloader-id when installing GRUB? I want to create multiple boot entries in my UEFI for the OSes that I run
[18:23] <marlinc> The issue is that when I manually run grub-install using --bootloader-id it works just fine but then when a GRUB update comes it creates another entry with the default entry called 'ubuntu'
[18:25] <cjwatson> marlinc: GRUB_DISTRIBUTOR in /etc/default/grub.d/<something>.cfg (e.g. local.cfg).  Note that that will override the presentation in menus as well
[18:26] <marlinc> Ah, that's what that's for
[18:27] <marlinc> Is it rather strange that the entry in UEFI is all lowercase and that is Ubuntu with the uppercase U
[18:27] <cjwatson> debian/postinst.in:        bootloader_id="$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
[18:28] <marlinc> Ah
[18:29] <cjwatson> sorry to be terse, am trying to understand the internals of some web service authorisation code which is quite a different headspace
[18:29] <marlinc> No problem at all, I'm glad you guys here answering questions
[18:30] <marlinc> I'm a web developer so I can understand its something completely different :p
[18:46] <nacc> slangasek: would it be better for me to run update-maintainer and refresh my debdiffs (to include the bug #s) throughout?
[18:47] <slangasek> nacc: well, one of us will have to do it before upload ;)  if you do it, it speeds up my part
[18:47] <nacc> slangasek: ok, i can do that for sure
[18:47] <nacc> i'm trying to spend some time on swig right now just to see if i can get it done by next week
[18:47] <nacc> i'll refresh the debdiffs in teh bugs after that
[18:53] <slangasek> nacc: does one of the bugs you've opened point me towards what I need in order to start bootstrapping, and is that ready to happen?  that's the part that needs an archive admin, so I'd like to start on that sooner rather than later if possible
[19:09] <nacc> slangasek: sorry! let me upload that to the first bug in a text file
[19:11] <nacc> slangasek: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1522422/+attachment/4569477/+files/php7-archive-admins.howtov2
[19:11] <ubottu> Launchpad bug 1522422 in php5 (Ubuntu) "Update to php 7.0" [Wishlist,Triaged]
=== cpaelzer is now known as cpaelzer_afk
[19:12] <nacc> slangasek: let me know if that's not written in a way that makes sense
[19:37] <doko> ginggs, cjwatson: looks like mpi isn't any better on sagari: https://launchpad.net/ubuntu/+source/esys-particle/2.3.3+dfsg1-2ubuntu2/+build/8999028
[19:54] <ginggs> doko, i don't recall the exact place where esys-particle was failing, but yeah that doesn't look good. if giving it more ram did help, we would still be asking why openmpi 1.10 suddenly needs more ram on powerpc.
[19:56] <dobey> doko: oh, are you still here?
[20:18] <dobey> guess not
[20:22] <doko> dobey, ust ask
[20:23] <bdmurray> happyaron: There are no Launchpad-Bugs-Fixed in your open-gram upload in the trusty proposed queue
[20:24] <dobey> doko: ah, i need a core dev to copy some packages from a silo ppa to xenial-proposed; we already had a silo in the works to resolve the scopes api issues with new capnproto and jsoncpp, and was being tested by QA today, but i saw you uploaded some no-change packages to proposed this morning, as i went to publish the silo after QA approved it. wondering if you can copy the xenial packages over to xenial-proposed (which will clobb
[20:25] <sarnold> dobey: you were cut off at "(which will clobb"
[20:25] <doko> dobey, which silo? are there special scripts for silo copies?
[20:26] <dobey> doko: wondering if you can copy the xenial packages over to xenial-proposed (which will clobber the changelog from your uploads this morning)
[20:26] <dobey> one second, let me find my tab
[20:26] <dobey> doko: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-037/+packages
[20:27] <dobey> doko: if you can coy the unity-scope-click, unity-scope-mediascanner, unity-scopes-api, and unity-scopes-shell packages for xenial there to xenial-proposed, it should get things rolling again
[20:31] <doko> dobey, done
[20:31] <dobey> doko: great, thanks
=== cpaelzer_afk is now known as cpaelzer
=== mnepton is now known as mneptok
[23:28] <Saviq> slangasek, I think we have another britney situation like we had for qtmir/mir http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scope-click - old -click tested with new -api → regressions, do we know how to deal with those properly, yet?
[23:30] <slangasek> Saviq: you deal with it by flagging it to the release team for override.  However, I'm not seeing here the issue; which failing test are you saying is a false positive?
[23:30] <Saviq> slangasek, http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scope-api
[23:30] <Saviq> the unity-scope-click test here
[23:30] <slangasek> Saviq: there are no failing tests there that are blocking anything.  Maybe you mean http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#libjsoncpp ?
[23:30] <doko> ginggs, cjwatson: openmpi success \o/  building with -Og lets the rdeps build.  I'm not going to investigate why ...
[23:31] <Saviq> slangasek, humm, I did ask mterry to restart them, just in case, but in http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#unity-scopes-api I can still see three reds for unity-scope-click ¿?
[23:31] <tumbleweed> doko: :/
[23:31] <slangasek> Saviq: oh, sorry - I missed the unity-scope-api vs. unity-scope-click :)
[23:31] <slangasek> let's see
[23:32] <Saviq> slangasek, but yeah, the libjsoncpp looks like it's going to block it as well?
[23:32] <doko> tumbleweed, always happy to keep a dead arch alive :-/
[23:32] <slangasek> Saviq: the libjsoncpp one is blocking; but I don't know that this is related to any api/click skew
[23:33] <slangasek> needs investigating/confirming
[23:33] <Saviq> slangasek, right, that's a separate issue, and it isn't looking great, all the three failures are just segvs or abrts
[23:33] <slangasek> right
[23:33] <Saviq> so unlikely to be flaky or anything
[23:34] <slangasek> so if you can sort that out, then I can address the unity-scopes-api/unity-scope-click skew
[23:34] <slangasek> but both packages are blocked by the new libjsoncpp so that needs to be addressed first
[23:34] <Saviq> slangasek, yeah thanks, will likely have to wait until tomorrow, then
=== rww is now known as ezri
[23:53] <jderose> rharper: i wrote a blog post summarizing what i learned - http://blog.system76.com/post/139138591598/howto-qemu-w-ubuntu-xenial-host-uefi-guest thanks again for the help!