[01:14] <mapreri> I see https://launchpad.net/ubuntu/+source/scribus-doc/1.4.5-1 is in universe, but shouldn't it be in multiverse instead?
[01:16] <meercat> why doesn't ubuntu 15.10 support uefi boots on macbooks
[01:16] <mapreri> in debian it's in non-free 'cause OPL
[01:17] <meercat> in virtualbox
[01:18] <mapreri> meercat: that doesn't sound a question for #ubuntu-devel, you might have better chances in #ubuntu instead (that's user support channel)
[01:18] <meercat> they don't  have an answer because its unsupported
[01:19] <mapreri> makes sense too
[01:20] <meercat> all of the other major distros support uefi boots in virtualbox on the mac
[01:21] <meercat> even mint, which is based on ubuntu, which leads me to believe this may be a bug in installation
[01:23] <meercat> there needs to be a startup.nsh script saved in /mnt
[01:23] <meercat> sudo sh -c "echo '\EFI\ubuntu\grubx64.efi' > startup.nsh"
[01:24] <meercat> this apparently goes back to 14.10
[01:31] <meercat> enough time has elapsed for this to take priority efibootmgr may create a duplicated boot entry, "breaking" UEFI boot.  Critical. 2014-08-31  https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1363719
[01:31] <ubottu> Launchpad bug 1363719 in efibootmgr (Ubuntu Utopic) "efibootmgr may create a duplicated boot entry, "breaking" UEFI boot." [Critical,Fix released]
[01:31] <meercat> fix is not working
[01:45] <meercat> xubuntu installs fine, then unity can be installed, so the workaround is to install xubuntu instead of ubuntu
[01:46] <hallyn> pitti: http://people.canonical.com/~serge/systemd.debdiff  and http://people.canonical.com/~serge/cgmanager.debdiff , considering those for xenial.
[01:46] <hallyn> (i'll also need a tweak to the lxc package - cherrypicked from upstream)
[01:46] <hallyn> pls let me know if you see anything bad there
[04:53] <nacc> rbasak: (or anyone else), let's say I've got a package (e.g., libgv-php5) that depends on (what appears to be) a symbol (e.g., phpapi-20131226) ... how do I look up reverse-depends on that symbol (which seems to be something generated by debian/rules in the php5 package). I think that's how we'll figure out all the packages that need to be updated that are PEAR/PECL/SWIG ... although as I type this, I r
[04:54] <nacc> ealize I might just be able to search for php5 and find them too :)
[04:58] <RAOF> nacc: That would probably be a virtual package to make ABI explicit; “apt-cache rdepends phpapi-20131226” would probably be your winner.
[05:24] <pitti> infinity: I looked at that last night
[05:24] <pitti> infinity, apw, stgraber: ah, I removed cloud-images.u.c. from $no_proxy, apparently there were some changes there; lxc tests now succeed again (on scalingstack anyway, i. e. not yet in LXC)
[05:25]  * pitti re-runs for the older ubuntu releases too
[05:25] <slangasek> pitti: hi, why do the ganeti autopkgtest failures get reported as a regression under http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#simplejson when basically every test with the version of ganeti in xenial has failed?
[05:25] <slangasek> maybe a problem with how we're calculating "regression" now that we record triggers?
[05:27] <pitti> slangasek: not every version, you see on http://autopkgtest.ubuntu.com/packages/g/ganeti/xenial/amd64/ that it did pass until the end of October and then started getting really flaky
[05:27] <slangasek> pitti: no, what I said is every test with this version of ganeti has failed
[05:28] <pitti> ah, we already have a force-badtest for it, excuses.html says that
[05:28] <slangasek> ah, and indeed you have a force-badtest hint in place, so this won't actually block
[05:28] <pitti> pitti:force-badtest ganeti/2.15.2-1
[05:28] <slangasek> it should be possible to determine automatically that this is not a regression vs. the package currently in xenial
[05:29] <slangasek> so maybe I'll file a wishlist bug
[05:29] <pitti> ah, I see what you mean
[05:30] <pitti> slangasek: right now it is like that because force-badtest was originally designed to "let your recently broken test not block other packages, but in your  next upload you have to fix them again"
[05:30] <pitti> slangasek: which is basically what we want for stuff we develop; but we are now also using it as a list of "broken tests we import from Debian and nobody cares about in Ubuntu"
[05:31] <pitti> slangasek: if we change it to what you have in mind, we'd allow more and more uncontrolled regressions
[05:31] <pitti> maybe that's what we'll have to do if the force-badtest lists grow too long; just explaining the current behaviour
[05:32] <slangasek> pitti: I see your point.  I guess since these packages had force-badtest to reach xenial in the first place, we don't need any added cleverness for labeling these "not-a-regression"
[05:32] <slangasek> I just need to read to the bottom of the excuses stanza ;)
[05:33] <pitti> slangasek: I guess what might be useful is to put the "ignored" lines right below the corresponding package
[05:33] <slangasek> could be
[05:33] <pitti> (which is surprisingly hard to do given how britney currently works, though)
[05:34] <pitti> but certainly possible
[05:34] <slangasek> pitti: btw, the semantics of the linux autopkgtest are a bit weird, have you noticed this?  it fails complaining about a "kernel version mismatch" if a newer version of the kernel is available in -proposed
[05:34] <slangasek> e.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#audit
[05:35] <slangasek> not urgent, audit can stay in -proposed and the tests can be rerun once 4.3.0-6.17 is promoted; but it's a wart
[05:35] <pitti> slangasek: yes, but I thought I fixed that yesterday
[05:35] <slangasek> oh :)
[05:36] <nacc> RAOF: ok, thanks!
[05:36] <pitti> slangasek: I just didn't re-run all affected tests I suppose
[05:36] <pitti> although I did a mass-retry last night, odd
[05:36] <pitti> slangasek: I'll look
[05:36] <slangasek> pitti: this test was triggered after your "yesterday"
[05:36] <slangasek> (new upload by me this afternoon)
[05:36] <nacc> RAOF: just returns "<phpapi-20131226>"
[05:36] <nacc> that's what i was hitting before
[05:36] <pitti> slangasek: oh, this is actually the inverse -- yesterday we had tests which used the kernel from -proposed but the source  from -release
[05:37] <slangasek> pitti: the kernel version it says it's triggering is the -proposed version; for most packages it's normally the release version, right?
[05:37] <nacc> RAOF: in this case, phpapi-20131226 is a "provides" value from php5 (generated by debian/rules)
[05:37] <pitti> slangasek: the running kernel there is right -- we expect to run audit against -release
[05:38] <nacc> RAOF: so not a proper package dependency, it's more like a command or something (I think I've seen packages depend on some command being available?)
[05:38] <pitti> slangasek: but there it should use the linux source from -release too
[05:38] <slangasek> pitti: right
[05:38] <nacc> RAOF: may not respond right away, sort of afk, but appreciate any insight you can provide
[05:38] <pitti> slangasek: this is a horrible piece of heuristics right now :/ http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/runner/adt-run#n343
[05:38] <RAOF> nacc: Yeah, it's what's called a virtual package. But it seems that the php5 package in xenial at least does not provide that package.
[05:43] <pitti> hallyn: hm, the patch still retains cg_create_everywhere_uid(), I suppose this should be dropped in favor of just cg_create_uid()?
[05:44] <pitti> hallyn: but I can do that (and update the patch header etc.), it should work like this already; but note that with your patch it will already grab some other controllers soo
[05:44] <pitti> hallyn: thanks!
[05:44] <pitti> infinity: ah, great; it now got uploaded to Debian too, I'll merge ifupdown again to mop up some more fixes
[05:47] <slangasek> pitti: I guess the issue is that 'apt-cache showsrc --only-source linux' will show both xenial and xenial-proposed binaries, which have different names
[05:47] <pitti> slangasek: yes, that was the problem yesterday too; this heuristic isn't strong enough for "linux", need to think about this
[05:47] <hallyn> pitti: oh i shouldve renamed it, but it's actually only creating name=systemd.  isn't it?  /me checks
[05:48] <slangasek> pitti: will also fail funny for soname transitions
[05:48] <pitti> hallyn: oh, I see -- you dropped the loop in cg_create_everywhere_uid(), it's essentially just an alias for cg_create_uid() now; I missed that
[05:49] <pitti> hallyn: so yes, it should work as you intend now (and I'll trim it down)
[05:49] <hallyn> yeah i left it bc we need to create the dir at that point (if i didn't, it didnt 'work)
[05:49] <hallyn> pitti: -awesome, thx
[05:49] <pitti> hallyn: eventually I think we can get the remaining bit into pam-cgm as well, it just needs to chown() the name= controller but otherwise don't touch it
[05:49] <hallyn> i'll push the cgmangaer and lxc patches probably tonight, the systemd can come whenever
[05:49] <hallyn> pitti: yeah, happy to move that over once we figureout how -
[05:50] <hallyn> would like to first convert to pam-lxcfs though
[05:50] <pitti> hallyn: yes, but not urgent
[05:50] <hallyn> pitti: thx - ttyl
[05:50] <pitti> hallyn: i. e. let's do that in these stages, easier
[06:01] <nacc> RAOF: ah it's provided in xenial by php5-common
[06:03] <nacc> RAOF: and a number of other packages -- is there handy command to search what provides a given virtual package?
[06:04] <RAOF> I knew one at some point, but can't seem to remember it.
[06:09] <pitti> apt-cache search isn't too bad, but it gets more hits than just the Provides:
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
[07:41] <dholbach> good morning
[08:00] <pitti> apw, stgraber: yay, green is back on http://autopkgtest.ubuntu.com/packages/l/lxc/ :)
[08:29] <apw> pitti, yay indeed :)
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
[08:46] <stgraber> pitti: great and I didn't even have to do anything about it :)
[09:10] <pitti> PSA: no autopkgtests for the next half hour or so, I need to re-deploy the env
[09:18] <apw> Unpacking fonts-tlwg-typo-ttf (1:0.6.2-2) ...
[09:18] <apw> dpkg: error processing archive /var/cache/apt/archives/fonts-tlwg-typo-ttf_1%3a0.6.2-2_all.deb (--unpack):
[09:18] <apw>  trying to overwrite '/usr/share/fonts/truetype/tlwg/TlwgTypo-Bold.ttf', which is also in package fonts-tlwg-typo 1:0.6.2-1
[09:18] <apw> is this known ^
[09:18] <cking> me too on that one
[09:18] <dholbach> I had the same issue earlier and reported it
[09:18] <apw> dholbach, cool thanks
[09:19] <dholbach> the usual  ... sudo apt install -f; sudo dpkg configure -a; ... dance fixed it for me
[09:19] <dholbach> "fixed"
[09:20] <cking> yep, that's what I did too :-)
[09:20] <cking> w/o the dancing
[09:21] <Laney> one of you going to fix it? :)
[09:44] <ginggs> Laney: hi, you renamed library packages for g++5 transition for package normaliz in Ubuntu, but Debian didn't (the only thing depending on it is itself). What is the best way to drop the Ubuntu delta and get back into sync?
[09:45] <Laney> ginggs: Add Breaks and Replaces until the next abi break
[09:45] <Laney> if you know or are the Debian maintainer you could add those there :)
[09:46] <ginggs> Laney: so just add breaks and replaces to the debian package, then sync?
[09:47] <Laney> ginggs: I think so, check it upgrades properly
[09:47] <ginggs> Laney: will do, thanks
[09:47] <Laney> thank you!
[09:47] <seb128> ginggs, Laney, have a Provides as well I think
[09:47] <seb128> C/R/P
[09:54] <Odd_Bloke> cjwatson: If you have a minute: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/s390x_cloud_images/+merge/282413 :)
[09:54] <Odd_Bloke> (xnox: ^)
[10:07] <pitti> wohoo!
[10:08] <cjwatson> Odd_Bloke: mostly LGTM, maybe lose the pointless bashism in 999-cpc-fixes?
=== tsdgeos_ is now known as tsdgeos
[10:19] <Odd_Bloke> cjwatson: Ah, yep, copy-pasta fail.  Fixed and pushed.
[10:31] <cjwatson> Odd_Bloke: merged and uploaded
[10:31] <Odd_Bloke> cjwatson: Thanks!
=== cpaelzer is now known as cpaelzer_afk
=== _salem is now known as salem_
[11:05] <cjwatson> bdrung: devscripts merged
[11:09] <ginggs> Laney: normaliz maintainer buttoned up things rather tight; libnormaliz0 already Provides and Conflicts libnormaliz, libnormaliz0-dbg  already Provides and Conflicts libnormaliz-dbg and it doesn't want to upgrade like that
[11:14] <Laney> ginggs: Doesn't want to how? Can't you add the v5 packages in there too?
[11:17] <ginggs> The v5 packages also Provide and Conflict with libnormaliz and  libnormaliz-dbg.  It is normaliz-bin that is getting kept back.  I'm trying something now that might help it along.
[11:23] <xnox> pitti, on s390x i need to set vm.allocate_pgste = 1 via sysctl. Where is it best to have this thing set? systemd package shipping such a snippet? or somewhere else?
[11:23] <pitti> xnox: /etc/sysctl.d/
[11:23] <pitti> xnox: oh, you mean not locally, but in a package?
[11:23] <xnox> pitti, =)
[11:24] <xnox> pitti, yeah, cause everyone who wants to run qemu will need it ;-)
[11:24] <pitti> xnox: /usr/lib/sysctl.d/ then, in whavever package that sounds suitable
[11:24] <xnox> pitti, i see on redhat they ship it in initscripts package such a snippet.
[11:24] <pitti> that looks a bit like an "unbreak my setup" option, this can't just be set in the kernel?
[11:25] <xnox> dunno, i can ask kernel people.
[11:25] <pitti> our procps package ships a ton of those already
[11:25] <pitti> so I guess for now it coudl go there as well
[11:25] <pitti> unfortunately it ships all of them in /etc/sysctl.d/, we should move to /usr/lib/sysctl.d/ for stuff shipped by packages
[11:26] <pitti> (man sysctl.d)
[11:26] <xnox> apw, can vm.allocate_pgste = 1 be the default? we seem to boot into =0, and qemu-system barks at me saying it must be =1 to boot vms.
[11:26] <pitti> xnox: so, changing the default in the kernel seems prudent, until then procps could ship that as an override?
[11:28] <mvo__> doko: quick question - will there be an update for gccgo before the 16.04 release? I have some build failures in snappy right now because we use some go 1.5 feature but apparently that is not supported in our gccgo yet. if there is a plan to update i will just wait, otherwise I need to think about a plan b :)
[11:35] <pitti> doko: FYI, new python3.5 has two regressions in test.test_csv.TestDialectRegistry: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python3.5/20160113_011050@/log.gz
[11:42] <ginggs> Laney: Now normaliz-bin and normaliz are getting kept back. :( I also don't see how libnormaliz0v5-dbg will get upgraded without a transitional package, there's nothing else that depends/recommends/suggests it.  I did something similar with xmpi in LP: #1245149 some time ago, this might be the only way.
[11:42] <ubottu> Launchpad bug 1245149 in xmpi (Ubuntu) "Please merge xmpi 2.2.3b8-13.1 from Debian testing (main)" [Undecided,Fix released] https://launchpad.net/bugs/1245149
[11:43] <Laney> ginggs: if it helps AFAIK you can drop -dbg packages now that Debian has automatic ones
[11:45] <Laney> Not sure if you'd get file conflicts with that one though
[11:45] <Laney> (I guess not)
[11:48] <Odd_Bloke> cjwatson: Another livecd-rootfs MP: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/i386_ovas/+merge/282427
[11:48] <Odd_Bloke> cjwatson: Sorry I didn't roll this in above, we discovered the omission as you were releasing my previous fix. :(
[11:49] <bdrung_work> cjwatson, thanks
[11:52] <cjwatson> Odd_Bloke: merged/uploaded
[11:55] <Odd_Bloke> cjwatson: Thanks again!
[11:56] <doko> mvo__, yes, I'll see to that
[12:00] <mvo__> doko: \o/
[12:00] <mvo__> doko: is there anything I could help with?
[12:01] <doko> mvo__, would be nice if somebody could figure out autopkg testing for golang packages
[12:02] <mvo__> doko: what kind of tests do you have in mind? the unit tests are running as part of the build by default afaik which is already quite nice
[12:02] <d0lph1n98> is it a good practice to have self-documented code for kernel space drivers?
[12:03] <doko> mvo__, the thing what is currently done for all ruby and perl packages
[12:03]  * mvo__ checks what is done there
[12:04] <ricotz> doko, hi
[12:04] <ricotz> doko, I hope you didnt miss my message about libtool
=== pitti is now known as Guest81048
=== Guest81048 is now known as pitti_
[12:07] <apw> xnox, and that cannot be changed after boot ?
[12:09] <doko> ricotz, no time yet
[12:10] <ricotz> doko, alright, just wanted to make sure it is on your list -- can you copy it to a non-virtualized ppa which builds it on all archs?
[12:10] <cjwatson> mvo__: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work.  It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right?
[12:10] <doko> pitti_, apport's gcc 6 detection could be better: No such file or directory: '/usr/bin/gcc-6-20160109-1ubuntu1
[12:14] <apw> xnox, it may be changable after boot, i wonder why its off, it seems to take some locks, so i odn't know if there is a performance hit in there
[12:14] <apw> xnox, anyhow, would you file a bug against linux for tracking pls
[12:15] <pitti_> doko: which test is that? I remember having to do some adjustments for gcc-4.9 -> gcc-5
[12:16] <doko> pitti: see https://launchpad.net/ubuntu/+archive/test-rebuild-20151218.1-gcc6/+build/8639224
[12:17] <pitti_> doko: what does "gcc --version" say?
[12:17] <doko> $ gcc --version
[12:17] <doko> gcc (Ubuntu 6-20160109-1ubuntu1) 6.0.0 20160109 (experimental) [trunk revision 232188]
[12:21] <pitti_> doko: thanks; I'll adjust it to cope with that
[12:21] <pitti_> i. e. 5.3 vs 6-something
[12:21] <pitti_> or perhaps better, take the third field isntaed of the second
[12:23] <pitti_> doko: fixed in trunk
[12:24] <doko> pitti_, you should just rely on the number which is not in the (...)
[12:24] <pitti_> right, that's what I did now
=== cpaelzer_afk is now known as cpaelzer
[12:46] <rbasak> cjwatson, infinity: I'd appreciate your comments on bug 1533639.
[12:46] <ubottu> bug 1533639 in livecd-rootfs (Ubuntu) "[ubuntu-cpc] please make /tmp a tmpfs in RAM" [High,Triaged] https://launchpad.net/bugs/1533639
[12:46] <rbasak> pitti: also.
[12:47] <cjwatson> rbasak: I'm afraid I'm unlikely to have time to get into this.  It was a rat-hole even when I was working on installer stuff routinely
[12:49] <rbasak> cjwatson: OK, np.
[12:55] <mvo__> cjwatson: uh, thats a sergiusens question
[12:59] <cjwatson> sergiusens: I'm pretty confused about how the "architectures" field in a snapcraft.yaml is meant to work.  It seems to override the architectures of the generated snap package, not specify which architectures the snap might be built for - is that right?
[12:59] <cjwatson> :-)
=== jincreator is now known as jincreator_
[13:03] <happyaron> how to let things like src:trafficserver migrate from -proposed? (ftbfs on archs previously can successfully build)
[13:09] <cjwatson> happyaron: Why can't the build failures be fixed?
=== salem_ is now known as _salem
[13:14] <happyaron> cjwatson: upstream is in the process of dropping 32 bit support
[13:14] <xnox> happyaron, s390x and ppc64el are 64-bit.
[13:14] <happyaron> but not actually removing existing stuff atm
[13:14] <cjwatson> happyaron: The arm64 case looks like incorrect link order, probably.  The ppc64el case seems to be something to do with passing -mcx16 when it's not recognised.
[13:14] <cjwatson> happyaron: And indeed, 32-bit support has nothing whatsoever to do with this.
[13:15] <cjwatson> s390x is not involved.
[13:15] <cjwatson> (I mean, it fails, but it's not a regression.)
[13:16] <happyaron> these (ppc64el/s390x) are known and being worked on, but probably no armhf
[13:16] <cjwatson> happyaron: armhf is not relevant, since it's not a regression.
[13:17] <happyaron> ok
[13:17] <cjwatson> happyaron: You need to fix the ones that are regressions (arm64, ppc64el).
[13:17] <cjwatson> I expect that not passing -mcx16 on non-x86 would help.
[13:17] <happyaron> arm64 does build...
[13:17] <cjwatson> Oh, I can't read.
[13:18] <cjwatson> Misread armhf as arm64.
[13:18] <happyaron> :)
[13:18] <cjwatson> We can remove existing binaries from architectures if they're definitely being dropped, but there has to actually be a decent argument for that.
[13:19] <happyaron> (upstream believes nobody is using the software on non-x86 platforms, though not a good claim
[13:19] <cjwatson> Looks like the ppc64el case would be fixed by not assuming that has_128bit_cas=1 in configure.ac always implies "we got there by passing -mcx16".
[13:20] <cjwatson> Just bad logic.
[13:20] <cjwatson> Yeah, upstreams always say that.  Sometimes they're right ...
[13:20] <cjwatson> Sometimes we care even if they don't
[13:21] <cjwatson> Anyway, if you can get ppc64el fixed, then we can look at armhf
[13:21] <happyaron> ok
=== cpaelzer_ is now known as cpaelzer_afk
=== mvo__ is now known as mvo
=== cpaelzer_afk is now known as cpaelzer_
[13:41] <doko> barry: cython tests still fail with the updated python3.5
[13:44] <doko> barry, and looks like the test_csv tests need adjustment too (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python3.5/20160113_011050@/log.gz)
=== rickspencer3_ is now known as rickspencer3
[14:14] <barry> doko: i'm pretty sure i fixed the csv failure in a following commit
[14:14] <doko> barry, can't currently look. mercurial times out for me
[14:14] <barry> doko: yay ;)
[14:14] <doko> barry, but for 3.5 I took the branch, so it should be included
[14:15] <barry> doko: interesting.  okay, let me try here from upstream
[14:16] <barry> doko: xnox reported the asyncio failure in the cython build.  fairly sure that's unrelated: LP: #1526613 (but still worth tracking down)
[14:16] <ubottu> Launchpad bug 1526613 in python3.5 (Ubuntu) "ftbfs asyncio test failure with 3.5.1-2, used to pass with 3.5.0-2" [Undecided,New] https://launchpad.net/bugs/1526613
[14:16] <barry> doko: hg is okay here
[14:17] <xnox> barry, i've emailed cypthon mailing list, no response.
[14:17] <xnox> barry, filed github issue against asyncio, and guido said "talk to cypthon people, it's their tests that are failing"
[14:17] <barry> xnox: yeah, i think i saw that.  :(  i'll see if i can bisect the commit
[14:17] <xnox> and asyncio generators is beyond me, to work out what cypthon is doing and why it's failing.
[14:19] <Saviq> pitti, can you please rerun the unity-scope-click failures http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#gsettings-qt :|
[14:20] <Saviq> I've already filed bug #1532358, will put heat on it
[14:20] <ubottu> bug 1532358 in unity-scope-click (Ubuntu) "flaky autopkgtests cause migration issues" [Undecided,New] https://launchpad.net/bugs/1532358
[14:20] <Saviq> alecu, hey, can you please put ↑ on the table somewhere
[14:26] <pitti> Saviq: kicked
[14:27] <sergiusens> cjwatson, architectures in snapcraft.yaml should probably just go away; it is only there since people wanted it on special request (using prebuilt binaries and manually constructing a fat package).
[14:27] <sergiusens> but yes, it is an override, not a "built this for" :-/
[14:27] <sergiusens> I guess the docs could make that clear, and yeah, it is backwards when comparted to debs
[14:40] <cjwatson> sergiusens: Have you put any thought into metadata that describes the architectures that the source code for a snap can be built for?  It would be useful for the LP/store interaction.
[14:40] <cjwatson> sergiusens: debs have this for a reason ;-)
[14:46] <barry> doko: upstream 3.5 head only fails for me on the ssl tests.  test_csv passes
[14:46] <barry> (ssl tests always fail)
[14:46] <barry> also interesting that test_asyncio doesn't fail for me
[14:47] <sergiusens> cjwatson, can you log a bug, I agree, but I'll forget https://bugs.launchpad.net/snapcraft :-)
[15:15] <cjwatson> sergiusens: OK, https://bugs.launchpad.net/snapcraft/+bug/1533713
[15:15] <ubottu> Launchpad bug 1533713 in Snapcraft "Add metadata describing the architectures that a snap can be built for" [Undecided,New]
[15:19] <sergiusens> thank you
[16:00] <xnox> pitti, why is nova missing tests on xenial? http://autopkgtest.ubuntu.com/packages/n/nova/
[16:01] <xnox> pitti, or has it lost its brains? http://autopkgtest.ubuntu.com/status/ looks a bit empty
[16:02] <jcastro> hi everyone, what's the process for removing a package from universe? We have an old unmaintained package for juju-jitsu that has been dead for years and shouldn't be in xenial
[16:03] <rbasak> jcastro: ask an archive admin to remove with that explanation, usually via a bug and subscribing ~ubuntu-archive
[16:03] <seb128> jcastro, open a removal bug and subscribe ubuntu-archive
[16:04] <jcastro> does it matter which package the bug is filed under? I am assuming under the package I want removed is fine?
[16:05] <cjwatson> jcastro: yes, that's best
[16:05] <jcastro> thanks folks!
[16:07] <smoser> hey. i'm trying to do this:
[16:07] <smoser> http://paste.ubuntu.com/14488062/
[16:08] <smoser> cjwatson, is there an easy way to tell grub-pc not to attempt grub-probe and such as I dont care about functional grub ?
[16:12] <cjwatson> smoser: no.  when I've had to do things like this in the past I've diverted grub-probe and replaced it with a simple script that output just the information I need (IIRC I had something like that in lp:lupin)
[16:12] <smoser> hm.. looks like if i can get running-in-container to exit 0 (true), then maybe
[16:12] <cjwatson> oh, no, that was grub-{install,mkimage}
[16:13] <cjwatson> ah, it's true that running-in-container might help
[16:16] <smoser> so replacing running-in-container with /bin/true seems to work.
[16:16] <smoser> wonder how far back that goes.
[16:19] <smoser> looks like that should work on trusty. and even precise!
[16:20] <cjwatson> yeah, looks like it
[16:20] <cjwatson> it was a precise SRU
[16:39] <pitti> xnox: I had to redeploy the entire thing today due to some juju troubles; it's still catching up with re-downloading all logs
[16:40] <xnox> pitti, cool =)
[16:40] <pitti> xnox: it downloads precise to xenial, currently at xenial/i386
[16:40] <pitti> xnox: so they should be there
[16:40] <pitti> xnox: if it's something on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, that has direct links to the logs (and they always work indepenently of autopkgtest.u.c.)
[17:00] <Saviq> pitti, looks like unity-scope-click failed again http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsettings-qt :/
[17:01] <nemo> So, due to the missing backport from upstream opensc detailed in https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770  which I've been a little too verbose in, I keep getting nagged to "upgrade" the .deb of opensc I built to the exact same version # - this happens every time I run an upgrade - in graphical client I can upcheck it, but I sometimes forget, and that's not as easy on co
[17:01] <ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
[17:01] <nemo> mmandline
[17:02] <nemo> I don't know if the opensc fix will be backported, is probably considered low priority, but is there any way to get ubuntu to stop trying to upgrade the .deb ?
[17:02] <nemo> the weird thing is they really are an identical version
[17:03] <cjwatson> put it on hold?
[17:03] <nemo> cjwatson: ooh. how?
[17:03] <cjwatson> if apt is trying to upgrade it then the checksum probably differs
[17:03] <nemo> cjwatson: well, that's very likely since I did build it locally and added the missing exports ☺
[17:03] <cjwatson> anyway, there's a dpkg-hold in the dlocate package (for some reason), or:   echo NAME-OF-PACKAGE hold | sudo dpkg --set-selections
[17:04] <nemo> cjwatson: is that maybe "Lock Version" in synaptic?
[17:04] <cjwatson> probably does the same
[17:04] <nemo> kk
[17:04] <cjwatson> can't say for certain, I don't use synaptic
[17:04] <nemo> it's my goto tool for getting anything done w/ apt - probably for same reason anyone uses a gui, lack of familiarity w/ cli
[17:05] <nemo> hm. stll wants to upgrade it :/
[17:05] <cjwatson> try the version I gave then
[17:05] <nemo> aight
[17:06] <nemo> echo opensc hold | sudo dpkg --set-selections
[17:06] <nemo> still wants to upgrade :/
[17:06] <nemo> oh wait
[17:06] <nemo> I'm a moron
[17:07] <nemo> that did work. awesome. thanks.
[17:07] <cjwatson> cool
[17:07] <nemo> I guess I'll be manually upgrading this for the forseeable future, but if I ever want to release the hold?
[17:07] <cjwatson> same but with unhold
[17:07] <nemo> Maybe I'll add your hint to my bug comments, since I've been trying to detail there how to get this vmware to work under ubuntu
[17:07] <cjwatson> wait, no, same but with install
[17:07] <nemo> ok
[17:08] <cjwatson> in general though, if you're doing this kind of thing it's better to change the version number
[17:08] <nemo> ah...
[17:08] <nemo> well, I'm not very savvy WRT building either ☺
[17:08] <cjwatson> and then you could e.g. put it in a PPA and either the version you choose is higher, or you could tell apt to pin the PPA such that it prefers that even if the version from the primary archive is higher
[17:09] <nemo> yeah, that sounds way too sophisticated for my simple needs ☺
[17:09] <nemo> but thanks
[17:09] <cjwatson> I mean, if you're intending to tell other people how to get it to work, a PPA is better then them all having to build it themselves
[17:09] <nemo> true. still don't wanna be responsible for it tho ☺
[17:09] <nemo> and maybe the upstream fix will be pulled into LTS someday
[17:09] <cjwatson> fair enough
=== juliank is now known as Guest54445
=== juliank0 is now known as juliank
[17:33] <bdmurray> pitti: Could you have a look at bug 1533349?
[17:33] <ubottu> bug 1533349 in Apport "StacktraceAddressSignature is generated using suboptimal function" [Undecided,New] https://launchpad.net/bugs/1533349
[17:50] <doko> barry, the upload only had your first commit, now uploaded again
=== pat_ is now known as Guest3393
[18:20] <ginggs> infinity: do you mind if I go ahead and merge pcre3?  You touched it last.
[18:22] <barry> doko: thanks
[18:23] <doko> ginggs, just do it
[18:23] <ginggs> doko said i can :)
[18:24] <infinity> ginggs: Go nuts.  Better yet, forward the changes to Debian, nothing in there is Ubuntu-specific.
[18:28] <doko> ricotz, why do you just remove the demos instead of adjusting for the changes?
[18:33] <ricotz> doko, do you think shipping those plain *.at files makes sense?
[18:34] <doko> so why not shipping the expanded/built ones?
[18:37] <ricotz> please add them then
[18:38] <doko> ricotz, patch please
[18:39] <ricotz> doko, if you say me how
[18:39] <doko> find out
[18:39] <ricotz> are they actually kept around after "make check"
[18:40] <ricotz> doko, you know how, but not saying?
[18:41] <doko> no, I'm trying to understand your changes, why they are necessary, why they are undocumented, and why you didn't try to fix these correctly
[18:42] <ricotz> doko, I don't see those demos expanded in a useful manner
[18:44] <ricotz> doko, all the removals in clean broke things, reverting the source tree to itself original state seems quite impossible
[18:45] <ricotz> reverting the "sed version" of libtoolize.in is broken too and doesnt seem to be fixable
[18:45] <ricotz> make those VERSION tweaks a proper patch would be cleaner
[18:45] <ricotz> making ...
[18:53] <Pharaoh_Atem> nacc: is it just me, or is php7.0-* not installable for you too?
[18:53] <Pharaoh_Atem> it's throwing an error for me saying that everything depends on php-common but it is not going to be installed
[18:55] <Pharaoh_Atem> nacc: nvm, it seems to be okay now...
[18:59] <nacc> Pharaoh_Atem: it worked in my first test, but Ill try it again
[19:38] <hallyn> pitti: i've pushed the other related packages, so if you get the systemd package to where you're happy please let me know - ican test first or you can just push and i'll test from archive
[20:39] <barry> smoser: can you confirm, cloud-image-utils is now python3 only?  re: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
[20:39] <smoser> barry, let me see.
[20:45] <smoser> barry, cloud-utils is good, but it depends on euca2ools, which is still
[20:45] <smoser>  Depends: python (>= 2.7), python (<< 2.8), python-lxml, python-requestbuilder, python-requests, python-six, python-setuptools
[20:46] <barry> smoser: can i update the blueprint and assign that to you?
[20:46] <smoser> um.. yeah.
[20:46] <gQuigs> any suggestions on how to approach this bug - https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1515446   I'm currently going service by service trying to determine what's different between desktop (has issue) and server (works) in a restart testing loop
[20:46] <ubottu> Launchpad bug 1515446 in systemd (Ubuntu) "NFS shares in FSTAB no longer mount at boot" [Medium,Confirmed]
[20:46] <gQuigs> (network-manager doesn't appear to be the obvious culprit)
[20:48] <barry> smoser: thanks ;)
=== rickspencer3_ is now known as rickspencer3
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[22:05] <nacc> why would a package's source be in multiverse but the binary be in universe?
[22:05] <nacc> (php-doc)
[22:12] <hallyn> pitti: hey, having a problem with the systemd job 'libvirt-guests.service' in wily's libvirt.  bug 1533839 .  it should only be stopped on shutdown, should be started after libvirt-bin.  but on pkg upgrades it's being stopped and restarted
[22:12] <ubottu> bug 1533839 in libvirt (Ubuntu) "vms shutting down on libvirt upgrade" [Critical,Triaged] https://launchpad.net/bugs/1533839
[22:47] <chiluk> mterry are you on the SRU team?
[22:49] <chiluk> mterry if you are can I get SRU approval for apache2 from pad.lv/1484696 ?
[23:13] <JayF> I'm working on building a cloud-style Ubuntu 14.04 image that can work on both RAID(md) and non-RAID hosts. I have everything working except /dev/disk/by-label/root is pointing to sda1 (a member of the raid) as opposed to md126p1 (the actual raid partition that should be root). When/what populates /dev/disk/by-label/ during boot? udev?
[23:16] <ari-tczew> coreycb: could you remerge amavisd-new, please? or eventually leave a meesage on bug 1357424 that you're not interested anymore
[23:16] <ubottu> bug 1357424 in amavisd-new (Ubuntu) "Please merge amavisd-new_2.9.0-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1357424
=== JanC_ is now known as JanC