=== achernya_ is now known as achernya
[02:41]  * robert_ancell wonders who chose the Launchpad group name 'ci-train-ppa-service'. Would love to type something shorter...
[02:42]  * infinity notes that ~ci is an inactive account we could probably rename and steal.
[06:45] <jamespage> slangasek, I'll get on that today - was on my list
=== marcusto_ is now known as marcustomlinson
[08:06] <Laney> doko: do you have a make rule or some helper for calculating it?
[08:15] <mvo> doko: I think I am mkaing progress
[08:37] <mvo> doko: new apt uploaded to the ppa, libept will also need a rebuild against it though. p-apt builds in my schroot now
[08:43] <tseliot> infinity: hey, tjaalton said you have problems with fglrx + linux 4.1. If so, please make sure to use fglrx 2:15.200.1-0ubuntu1 in wily, that will fix it. If not, I'm here
[08:55] <caribou> what is the most appropriate way to merge a debian package ? bzr or grab-merge ?
[08:55] <caribou> or it is up to who merges ?
[09:21] <Noskcaj> caribou, up to who merges
[09:21] <Noskcaj> sometimes only one will work
[09:21] <Noskcaj> some packages are also in lp:~ubuntu-desktop/PACKAGE/ubuntu
[09:23] <caribou> Noskcaj: ok, thanks
=== jamesh_ is now known as jamesh
=== mbiebl__ is now known as mbiebl
[12:03] <doko> mvo_, thanks, however tests still fail: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5224902/+listing-archive-extra
[12:08] <mvo_> doko: hm, thats new and different
=== _salem is now known as salem_
[12:39] <mvo_> doko: fix will be uploaded shortly
=== davidcalle_ is now known as davidcalle
=== MacSlow is now known as MacSlow|lunch
[13:27] <jamespage> slangasek, I've fixed up all of the openstack packages apart from openstack-trove
[13:28] <jamespage> I may dump in a snapshot as upstream master don't appear to have the same unit test failures, and I'm failing to bisect a single commit that fixes the problem
=== Malsasa_ is now known as Malsasa
=== marcusto_ is now known as marcustomlinson
=== MacSlow|lunch is now known as MacSlow
[14:39] <seb128> slangasek, seems like the pyqt5 python 3.5 rebuild is failing autopkgtest the 3.5 build seems invalid/failing to import
[14:49] <doko> seb128, see lp: #1477759
[14:49] <ubottu> Launchpad bug 1477759 in dh-python (Ubuntu Wily) "pyqt5 misbuild with python3.5" [Critical,Triaged] https://launchpad.net/bugs/1477759
[14:49] <seb128> doko, thanks
[14:59] <infinity> tseliot: Still around?
[14:59] <tseliot> infinity: yep
[14:59] <infinity> tseliot: 2:15.200.1-0ubuntu1 is broken with 4.1.0-2 (ie: 4.1.3 upstream), trust me. :P
[14:59]  * tseliot always forgets to update his IRC status...
[14:59] <infinity> tseliot: http://d-jenkins.ubuntu-ci:8080/job/dkms-wily-release_canonical_kernel_team_ppa-generic-fglrx_core/17/
[15:00] <tseliot> infinity: I tried mainline and it works fine. Maybe we're using some patches?
[15:00] <infinity> tseliot: I even pointed tjaalton at a potential patch from another distro at the time.
[15:00] <infinity> tseliot: I doubt we're carrying patches that make symbols GPL-only...
[15:01] <tseliot> infinity: the thing is, I already added support for linux 4.2. Maybe one of those changes was pulled into 4.1
[15:01] <tseliot> pci_ignore_hotplug is part of my patch for 4.2
[15:02] <tseliot> infinity: I'll give it another try, and move that fix from the patch for 4.2 to the one for 4.1. Maybe 4.1.3 is the problem
[15:02] <infinity> tseliot: Well, not sure what to tell you.  All I can say is that it's obviously failing.  The log doesn't lie.
[15:03] <tseliot> infinity: I'll check again with the kernel team ppa, and fix that, whatever the reason is
[15:03] <tseliot> ;)
[15:04] <tseliot> infinity: and yes, apparently I had only tested with 4.1.2 and with 4.2
[15:04] <tseliot> oh, well...
[15:05] <Sarvatt> tseliot: looks like it is going into 3.19 too https://lkml.org/lkml/2015/7/15/1170
[15:05] <Riddell> mvo_: what makes you think I know anything about git?!
[15:06] <tseliot> Sarvatt: aargh. Thanks for the heads-up
[15:06] <mvo_> Riddell: uh, I though we shared some code with that, my memory is sometimes blury
[15:06] <mvo_> Riddell: sorry
[15:06] <Riddell> :)
[15:36] <Laney> sladen: yo, are you interested in uploading the new version of the ubuntu font to the distro? I saw you've been active on the bug
[15:37] <sladen> Laney: I am.  But prior to that a new upstream version needs preparing!  ;-)
[15:38] <Laney> sladen: yah. willcooke says it exists or will exist or something. :)
[15:38] <willcooke> ohai
[15:39] <sladen> Laney: small delta 0.80->0.83 to recompile a couple of tables; so should be backportable to everything and its grandfather
[15:39] <Laney> cool
[15:39] <Laney> you mean SRU or backports?
[15:39] <sladen> Laney: willcooke: was meaning to do it last weekend, but insistent prodding helps ;)
[15:39] <Laney> well, whatever, I trust you can handle it
[15:39] <sladen> Laney: s/backport/SRU/ yes
[15:40] <Laney> thanks!
[15:40] <willcooke> super, thanks sladen laney.  I'll let Magdalena know you're on the case
[15:40]  * sladen grins
[15:41] <doko> seb128, fix for  1477759 uploaded, python3.5 still building on armhf and arm64
[15:42] <tseliot> infinity: it should be all fixed in fglrx-installer{-updates}_15.200.1-0ubuntu2
[15:42] <seb128> doko, thanks
[15:42] <infinity> tseliot: \o/
[15:42] <infinity> tseliot: Thanks.
[15:42] <tseliot> infinity: thanks for reporting the problem
[15:52] <ogra_> infinity, yo ... so i saw ubuntu-fan 0.3 on wily-changes ... do you think it is ready to seed it in snappy now ?
[15:52] <ogra_> apw, ^^^ same question to you
[15:53] <infinity> ogra_: Did you unseed it at some point?
[15:53] <ogra_> when you asked me with v0.1, yes
[15:53] <infinity> ogra_: Ahh, so you did.
[15:53] <infinity> ogra_: So, yeah, it should be good to go now.  It no longer depends on dnsmasq.
[15:54] <ogra_> sweet !
[15:54] <ogra_> (not sure i'll manage today, but i'll put it back then :) thanks !!)
[15:54] <infinity> ogra_: Seemed to me entirely unclever to have dnsmasq installed in a base image that people are trying to use as a border network device. ;)
[15:55] <ogra_> well, there are plenty of unclever thins in snappy still :)
[15:55] <ogra_> *things
[15:55] <infinity> Not that I agree with half the things in the base snappy image, but at least things in there shouldn't be actively harmful.
[15:55] <infinity> Bloat is acceptable (ish), things that might actually break higher level snaps, less ok.
[15:56] <ogra_> (cloud-init being the worst ... and no, a go rewrite wont help :P )
[15:58] <timrc> Glad to know go rewrite jokes are still alive and well ;)
[15:58] <ogra_> thats not a joke sadly
[16:00] <timrc> :~(
[16:40] <seb128> doko, slangasek, hum, shouldn't libprofobuf change soname with its gcc5 rebuild?
[16:40] <seb128> I'm looking at https://launchpadlibrarian.net/212134164/buildlog_ubuntu-wily-amd64.messaging-app_0.1%2B15.10.20150710.2-0ubuntu2~gcc5.1_BUILDING.txt.gz
[16:40] <seb128> (/usr/lib/libphonenumber.so.6: undefined symbol: _ZNK6google8protobuf11MessageLite25InitializationErrorStringEv)
[16:41] <seb128> doing a diff from the nm -D of the lib from wily/the ppa version gives things like
[16:41] <doko> I didn't change sonames yet
[16:41] <seb128> -000532d0 T _ZNK6google8protobuf11MessageLite25InitializationErrorStringEv
[16:41] <seb128> +00053cc0 T _ZNK6google8protobuf11MessageLite25InitializationErrorStringB5cxx11Ev
[16:41] <seb128> doko, it should no,  since the symbols changed in the rebuild?
[16:41] <doko> and we have a libphonenumber7 there too
[16:41] <doko> seb128, in principal, yes, but I can't handle 400 renamings
[16:42] <doko> so the best thing here is to collect these libraries at the bottom of the library stack, and then just rename these
[16:42] <seb128> doko, well, uploading libraries that change ABI without soname change is not any better is it?
[16:42] <seb128> do we have a list of libraries that need to be renamed?
[16:42] <doko> no, but you can do it with no-change uploads
[16:43] <seb128> how do we make sure those abi change don't land to the archive?
[16:43] <doko> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
[16:43] <doko> well, they go into -proposed next friday, and the dependency on libstdc++6 (>= 5.2) prevents them from migrating
[16:44] <seb128> but how do we detect where abi changes?
[16:44] <doko> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756
[16:44] <ubottu> Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open]
[16:44] <doko> well, you see it if you try to rebuild a package without first rebuilding it's dependencies
[16:45] <seb128> hum
[16:46] <seb128> it seems a bit of try & see, but that doesn't give me confidence on how we are making sure we don't overlook some issues
[16:46] <seb128> or that we rebuild things in the right order
[16:46] <slangasek> jamespage: cheers
[16:46] <doko> seb128, and for messaging-app: see the test failures at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5225831/+listing-archive-extra
[16:47] <slangasek> seb128: pyqt5, yes there's a bug open about this; it's a dh-python/python3.5 bug
[16:47] <seb128> slangasek, hey, doko replied earlier, thanks
[16:48] <doko> seb128, yes, so we should do the transition, but then again, we shouldn't do it twice (once for ourself, and then again when debian changes things=
[16:49] <seb128> I don't understand how things work
[16:49] <seb128> like that protobuf upload has an abi change without soname change
[16:49] <seb128> that can't be right
[16:49] <seb128> what's the rational/logic?
[16:49] <seb128> why don't we hold on the upload until it's properly checked/transitioned?
[16:50] <doko> because that doesn't work, to keep up packages in sync, and do 400 transitions
[16:50] <Laney> I think he means that you do the highest transition in any tree of packages
[16:50] <doko> it's already a pain to keep this ppa up to date
[16:50] <Laney> because this already forces rebuilding/upgrading everything further down
[16:50] <Laney> yes?
[16:50] <doko> right, but I do want to do these rebuilds in -proposed, not in the -ppa
[16:51] <seb128> I don't understand
[16:51] <seb128> what prevents that protobuf abi change to land in wily-proposed
[16:51] <doko> https://wiki.ubuntu.com/GCC5 has a list of the explicit transitions
[16:51] <seb128> or what guard us against it?
[16:51] <doko> nothing will guard you
[16:52] <seb128> so we might have updates that change abi without soname change landing in wily?
[16:53] <doko> why would that hurt? we don't guarantee partial upgrades. and as I said, for low level libs I plan to do that library rename
[16:53] <seb128> why would that hurt?
[16:54] <seb128> I though abi stability was one of the basic things we try to ensure
[16:54] <seb128> since when is that ok to change abi without changing the soname/renaming a deb?
[16:54] <seb128> sorry for the stupid questions
[16:54] <doko> we're ubuntu, not debian. and if we change the libraries at the bottom of the stacks, we should be good enough
[16:54] <seb128> I'm sure that transition is really tricky and people though about it
[16:55] <seb128> we are not debian, but we never said that ubuntu didn't ensure abi compatibility is maintained
[16:56] <slangasek> doko: what does http://bugs.python.org/issue24705 have to do with the pyqt5 build failure?  I didn't see any problems with prefixes
[16:57] <doko> slangasek, another issue with dh-python
[16:58] <slangasek> ok
[16:58] <doko> trying to generate some path name from a config var
[16:59] <seb128> doko, sorry but I still don't get it so I'm going to ask another question :-)
[17:00] <seb128> is protobuf going to be renamed before being uploaded to wily?
[17:00] <seb128> if yes, why didn't that happen in the ppa?
[17:00] <seb128> if no, why do we consider the abi change without rename as ok?
[17:00] <seb128> I could have a system with ubuntu core + libprotobuf + some custom application on top, it means upgrading my system is going to make my application fail on symbol errors
[17:01] <seb128> rather than having the packaging stopping me from upgrading
=== gshereme_ is now known as gshereme
[17:01] <seb128> slangasek, ^ you might be able to help me to understand things about that transition as well maybe? ;-)
[17:02] <doko> seb128, I don't plan to rename it on my own, however will take any renaming that comes from debian. if you think it is worth renaming, then please do it in the ppa, rebuild all reverse-deps, and keep these up to date during the next week
[17:02] <Laney> sorry to add to the doko pinging, but...
[17:02] <Laney> -rw-r--r-- root/root    640800 2015-07-24 12:26 ./usr/lib/python3/dist-packages/PySide/QtWebKit.cpython-34m-x86_64-linux-gnu.so
[17:02] <Laney> -rw-r--r-- root/root    642336 2015-07-24 12:26 ./usr/lib/python3/dist-packages/PySide/QtWebKit.cpython-35m.so
[17:02] <Laney> is that kind of thing fixed with this new dh-python?
[17:02] <doko> the problem is that you probably will find another dozen libraries while you are doing this
[17:02] <seb128> doko, well, if they need to be transitioned that's how thing are...
[17:02] <seb128> we can't just ignore the abi breakage
[17:03] <seb128> and randomly uploads changed abis without transition
[17:03] <slangasek> seb128: what you're suggesting is that we change all of the sonames of the affected libraries, when upstream has not. that's incredibly painful; historically in Debian what we've done when we've had issues like this , is to rename the binary packages and not change the sonames, since changing the sonames requires fiddling with umpteen different upstream build systems
[17:03] <doko> Laney, I don't know, the thing that I fixed was the doubled multiarch string in the soabi
[17:04] <seb128> slangasek, right, I said soname/or binary rename
[17:04] <Laney> doko: maybe the one slangasek just linked to?
[17:04] <seb128> slangasek, in the ppa protobuf changed abi but got neither
[17:04] <doko> seb128, I already have to babysit the touch guys, now I have people stomping with the foot to insist on 400 package renamings ;)
[17:04] <Laney> doko: in the buildlog I see dh-python3 renaming the 3.4 one to add the triplet but not for 3.5
[17:05] <seb128> doko, well, if the abi change they have to be renamed
[17:05] <Laney> so was curious as to whether this will fix it or if I should wrangle in the packaging
[17:05] <seb128> I don't see why it would be ok to not
[17:05] <seb128> slangasek, ^
[17:05] <slangasek> seb128: right. but a package name change without an soname change is not going to do anything to protect users of unpackaged software
[17:05] <seb128> slangasek, well it's going to ensure you don't upgrade a library and break softwares
[17:05] <Laney> guess I could just try it eh
[17:05] <seb128> apt is not going to let you update that lib
[17:06] <infinity> doko: Err, we don't guarantee stability of the final product on a partial upgrade, but we have to support partial upgrades in-progress.  Not transitioning a library correctly can lead to something breaking in a postinst halfway through an upgrade and breaking the world.
[17:06] <seb128> or it's going to ensure other packages are upgraded to use the new name as well
[17:06] <slangasek> seb128: you cited ubuntu-core as an example, and ubuntu-core doesn't use apt for updates ;)
[17:06] <doko> yes, that's why we have to rebuild everything before anything can migrate to the release pocket
[17:06] <seb128> slangasek, ubuntu-minimal? ;-)
[17:06] <seb128> or ubuntu server
[17:06] <seb128> whatever minimal base we provide
[17:07] <seb128> doko, well, "everything" is things in the archive, we might break third party debs
[17:07] <seb128> where a rename would protect them
[17:07] <slangasek> doko: rebuilding everything and migrating it at once does not ensure correct unpack order on upgrade, an infinity said
[17:07] <seb128> if feels fundamentaly wrong to change abi without renaming
[17:07] <infinity> slangasek: "We can't fix unpackaged software" is a perfect-enemy-of-good argument. :P
[17:08] <slangasek> (this is why we had the discussion about apt in particular)
[17:09] <slangasek> infinity: I agree with you and seb128 about renaming the affected libraries as part of the transition, I just want to be clear about what this does and doesn't accomplish
[17:09] <doko> slangasek, infinity: I didn't say that we shouldn't rename nothing. we will have the soname changes for some libraries, and we will have to rename some basic libs. but I don't see the point to rename everything, even if you don't know if the symbols form part of the library API
[17:09] <infinity> slangasek: Right, we've been through package-rename-without-sover-bump transitions before, I think the Debian community is well-versed in what that does and doesn't fix.
[17:09] <doko> however doing this in the ppa is the wrong thing to do
[17:09] <slangasek> doko: because it's safe to do so, and easier to script those conversions than to have this argument ;)
[17:10] <slangasek> doko: the ppa is meant to be binary copied en masse to the archive when ready; the ppa would be the place to do this
[17:10] <doko> slangasek, then please freeze -proposed for a week
[17:11] <seb128> it's over me why we upload "no change rebuilds that lead to a uncompatible abi" at all
[17:11] <seb128> shouldn't we check if the abi change and rename before upload
[17:11] <seb128> for every package
[17:11] <seb128> ?
[17:11] <doko> sure, please start doing so
[17:11] <seb128> we wouldn't have that discussion if every package includes a .symbol and failed build on changes :p
[17:11] <seb128> doko, I'm going to start on monday
[17:12] <seb128> but that ppa has already damages by changed-abi-but-not-renamed packages
[17:12] <doko> symbols files for c++ are crap
[17:12] <slangasek> seb128: damages meaning what?
[17:12] <seb128> slangasek, meaning we have abi changes sneaked in that we don't know about
[17:12] <seb128> since things were uploaded without checking if a rename was needed
[17:12] <seb128> e.g protobuf
[17:13] <Laney> When you fix it by starting a transition you'll have a to rebuild the reverse-deps anyway
[17:13] <doko> wrong, I confirmed issues in the debian bug tracker
[17:13] <slangasek> ok; "damages" suggested something stronger to me - I'm certainly aware of the state of the packages in the ppa
[17:13] <seb128> slangasek, how do we prevent those abi breaks to reach the archive?
[17:13] <doko> we shouldn't care for -proposed from my point of view
[17:14] <seb128> we could have a lib without archive rdepends going through without having britney having any reason to stop it
[17:14] <slangasek> seb128: do you have some time to work on this?  I haven't started the scripting yet
[17:14] <doko> and fix issues in -proposed
[17:14] <slangasek> seb128: but I have a rough plan I can describe
[17:14] <seb128> slangasek, not today but I can spend some time on that starting on monday
[17:15] <doko> and keep in mind that by heavily using the ppa you basically block the buildds for archive purposes
[17:15] <slangasek> seb128: here's the list of all build logs showing changed symbols; they correspond to the bugs doko filed in the Debian BTS, but this list is better to work from because it gives you the binary package names, search for 'BEGIN GCC CXX11 symbols': https://people.debian.org/~doko/logs/gcc5-20150701/
[17:16] <slangasek> doko: staging this transition is a high priority and a legitimate use of the distro builders
=== balloons_ is now known as balloons
[17:17] <slangasek> seb128: so my plan of attack was to extract each of those source packages, script up a package rename in debian/control and debian/$pkg.*, build, and see what breaks
[17:18] <seb128> slangasek, seems like a good plan to me. Why didn't we start by that rather than getting no change rebuilds in the ppa?
[17:18] <doko> slangasek, so when do you think these builds will finish?
=== balloons39 is now known as balloons
[17:20] <doko> seb128, would be a good task for +1 maintenance. so feel free to start. I'm already working 12+hours, weekends included
[17:20] <slangasek> doko: we would only need to make the source changes to the affected libraries before copying to -proposed; 361 packages; I don't think I could give you a very precise estimate of build time but would assume < 1 week
[17:20] <seb128> doko, you shouldn't have to kill yourself over it
[17:21] <seb128> but we shouldn't do it wrongly either before of manpower or buildd considerations
[17:22] <seb128> we can probably find more resources if needed, would it be on the buildds on on people to help with the transition...
[17:22] <doko> I still think this is too much overhead, choosing the very conservative road
[17:22] <slangasek> seb128: to be clear, the concern with buildd power is that if the buildds can't keep up with the ppa, by the time the builds are done the builds will be stale because of source uploads to -proposed and we'll have to spend more human time rebuilding again
[17:22] <doko> but fine, if you think you can do that ...
[17:23] <seb128> well, there is no "very conservative"
[17:23] <seb128> abi changes should lead to deb renames or soname change
[17:23] <seb128> it's the only right way
[17:23] <doko> no, the ppa unfortunately has priority, so any builds for the archive will be blocked
[17:23] <slangasek> I don't see why this is unfortunate in this case
[17:24] <slangasek> it's unfortunate when it's a different team's silo eating the resources ;)
[17:24] <doko> heh
[17:24] <slangasek> but it would still be a problem if a newer source package is in -proposed, regardless of whether it's had time to build
[17:26] <doko> slangasek, seb128: if you do this, you should consider omitting these packages where debian considers to upload a new upstream with a soname change
[17:27] <seb128> unsure
[17:27] <seb128> it would mean delaying those packages until Debian does the uploads
[17:27] <slangasek> doko: omitting those would mean stalling them in -proposed artificially; I think it's easier to just include them in the scripted rebuild
[17:27] <seb128> which might be longer than we want
[17:27] <doko> or just copy the new upstream to the ppa
[17:27] <seb128> it doesn't hurt much to rename now to sync the new soname later
[17:28] <doko> slangasek, I still doubt this can be all done until Friday, and then we'll have the problem with debian imports too, assuming the new ABI
[17:29] <doko> Laney, did you figure out your py3.5 issue?
[17:30] <seb128> doko, he's away now I think but I would assume he was waiting for a comment from you or he would have followed up to say he figured it out
[17:37] <seb128> ok, on that note calling it a week
[17:37] <seb128> I'm going to help as I can on that transition next week
[17:38] <seb128> have a good w.e everyone
=== vdrey changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not suport or app devel) | build failures -&gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== vdrey changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -&amp;gt; http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -&amp;gt; vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[17:42] <vdrey> oops.
[18:28] <slangasek> stgraber, hallyn: lxc has adt failures since the 22nd; I'm pretty sure the EPERM on overlayfs_mount is not caused by the python3.5 transition, but I don't particularly want to override these test failures for lxc itself.  Any ideas?
[19:17] <hallyn> slangasek: assuming you're talking about dh-systemd liblua5.2-dev , i was assuming psivaa had some busted code there he was working on
[19:17] <hallyn> (today was the first day i saw the failure email)
[19:18] <hallyn> (assumption was due to:   )
[19:18] <hallyn> + /home/psivaa/auto-package-testing/jenkins/run-autopkgtest
[19:18] <hallyn> RSYNC_DEST not defined
[19:19] <hallyn> yeah that must be something different as it passed the day before: https://jenkins.qa.ubuntu.com/job/wily-adt-squid3/23/
[19:19] <hallyn> oh htat's jul 11
[19:33] <slangasek> hallyn: mm? I'm talking about a failure of the lxc test case itself: https://jenkins.qa.ubuntu.com/job/wily-adt-lxc/lastBuild/
[19:34] <hallyn> urgh
[19:34] <hallyn> sforshee actually may have seen this before.
[19:34]  * hallyn tries to find the kernel version
[19:36] <hallyn> slangasek: i notice the console output is installing a new linux-image-generic, suggesting the current kernel is out of date?
[19:37] <slangasek> hallyn: I assume the autopkgtest runs in a guest of some sort (chroot or container) so the linux package inside doesn't actually matter?
[19:38] <hallyn> slangasek: doesn't matter unless the host kernel happens to be one with a overlayfs-related bug, or without the ubuntu sauce patch allowing this
[19:38] <hallyn> (meanwhlie, trying it out in a vm here)
[19:39] <hallyn> jiminy.  seems like i startd a trusty vm
[19:48] <slangasek> hallyn: sure - the host kernel may have a bug, but an upgrade of linux-image-generic in the guest enviroment gives no clue whether that's the case
[19:52] <hallyn> true.  but i still haven't found what kernel those things are running :)
[19:53] <sforshee> hallyn: I'm trying to find that too
[19:54] <smoser> is there a python friendly way of asking sysstemd "restart this service if it is running"
[19:56] <smoser> if i just 'systemctl restart service', then it will start it even if not running
[19:59] <hallyn> sforshee: current wily kernel fails for metoo
[19:59] <hallyn> slangasek: confirmed here
[19:59] <hallyn> sforshee: so does the kernel have the right version of eric's patch?
[20:00] <sforshee> hallyn: I'm looking now to see what it has
[20:02] <sforshee> hallyn: it has a patch to enable userns mounts, but apw is the author
[20:03] <sforshee> hallyn: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily/commit/?id=6a9e889d4a130e6445b0e9bbae2308dc4b139dfc
[20:03] <slangasek> smoser: systemctl try-restart
[20:04] <smoser> you'd think.
[20:04] <smoser> i just saw that too
[20:04] <slangasek> or maybe better yet, reload-or-try-restart
[20:04] <slangasek> (or force-reload which is a synonym)
[20:05] <hallyn> sforshee: hm, i don't know what i'm looking at.  i assume apw is EOW...
[20:05] <slangasek> I guarantee that systemctl try-restart doesn't start a running service, because I just found a bug due to dh-systemd using it where it shouldn't :P
[20:06] <sforshee> hallyn: likely. What patch from Eric are you talking about?
[20:06] <hallyn> sforshee: while i was on vacation (i think it was then) you had replied to a patch by eric saying that it stopped you running  unpriv containers
[20:07] <sforshee> hallyn: oh, yeah that was my mistake
[20:07] <hallyn> Subject: Re: [GIT PULL] User namespace related fixes for v4.2
[20:07] <hallyn> Message-ID: <20150706204748.GB22962@ubuntu-hedt>
[20:07] <sforshee> that's 4.2 anyway
[20:07] <sforshee> wily is still on 4.1
[20:07] <hallyn> i figured it was some patch backported to stable and into 4.1
[20:08] <sforshee> oh, you're right, it did hit 4.1 stable
[20:08] <hallyn> hm, my syslog has:
[20:08] <hallyn> Jul 24 19:58:45 lxctmp1 kernel: overlayfs: missing 'workdir'
[20:09] <smoser> slangasek, yeah, i was looking at rsyslog, and it seems its getting socket activated which confused my tests.
[20:09] <smoser> reload-or-try-restart
[20:09] <smoser> does 'reload' there mean "have the system reload its config" or "have *systemd* reload its unit files"
[20:11] <hallyn> sforshee: fwiw lxc always tries without workdir= first, and if that fails does overlay mount with workdir=
[20:12] <hallyn> wondering whether th enew patch may be messing that up
[20:12] <sforshee> that message definitely indicates that it thinks the option was missing, but that should fail with EINVAL, not EPERM
[20:15] <slangasek> smoser: "Note that this will reload the service-specific configuration, not the unit configuration file of systemd." systemctl(1)
[20:16] <smoser> yeah. thats what i want. just saw. thanks.
[20:18] <hallyn> sforshee: sadly i'm gonna have to builda new vm with bigger disk to clone the wily source tree :(
[20:19] <sforshee> hallyn: I'm getting a vm set up now to play with it.
[20:35] <hallyn> sforshee: what's the best url to uses for git clone of the wily kernel tree?
[20:35] <hallyn> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily/ seems a bit wrong
[20:36] <sforshee> hallyn: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily is what I used
=== salem_ is now known as _salem
[21:04] <sforshee> hallyn: so I think lxc is mounting with the overlay fstype instead of overlayfs, and only overalyfs has FS_USERNS_MOUNT set
[21:07] <infinity> Given that overlayfs in 4.x is implemented by overlay, that seems like an odd difference?
[21:09] <sforshee> infinity: there's some backward-compatibility patch that apw wrote that does it. I'm not sure if this distinction is intentional or accidental.
[21:10] <infinity> sforshee: I'd assume the latter.
[21:14] <sforshee> infinity: maybe. There are differences between mounting as overlay and overlayfs in our kernel though, so I think I'll let apw make the call.
[21:15] <infinity> sforshee: Well, the biggest differences are of the "overlayfs needs to pull some tricks to make overlay look like overlayfs" sort.  But yes, best to get Andy's input.
[21:15] <infinity> apw: If you're still awake and care about anything anymore on this Friday evening ^
[21:16] <sforshee> I'm about to stop caring myself
=== alvesadrian is now known as adrian
=== adrian is now known as Guest6127
=== Guest6127 is now known as adrian
=== _salem is now known as salem_
[22:01] <hallyn> sforshee: no, lxc is using type 'overlayfs'
[22:01] <hallyn> i think...
[22:04] <hallyn> then again, no, that code is going backward
[22:05] <hallyn> sforshee: 'overlay' was the old ubuntu-sauce one right?  overlayfs is the new one?  so 'workdir' should be used with 'overlayfs'?
[22:06] <hallyn> there, maybe pulling out 20 lines of code will help
[22:09] <infinity> hallyn: overlayfs is the old one, overlay is the new one.
[22:09] <hallyn> it does!
[22:09] <hallyn> infinity: hm, that's not good
[22:09] <infinity> hallyn: We provide an overlayfs compatibility layer in the Ubuntu kernel, but upstream only has overlay.
[22:15] <hallyn> sforshee: infinity: i suppose maybe apw's idea was that upstream doesn't yet support unprivileged mounts so 'overlay' shouldn't support it, only 'overlayfs' should
[22:16] <hallyn> but it used to work with 'overlay' so this is a regression in functionality
=== salem_ is now known as _salem
=== ev_ is now known as ev