[04:00] <pitti> teward: no, in general package hooks are being run
[04:00] <pitti> teward: they might cause an exception of course, and then will be ignored
[07:09] <pitti> mdeslaur: hm, you changed the pythons to rely on the new value of the -proposed openssl, not to work with either
[07:09] <pitti> but no bump of dependencies, so they block each other in -proposed now
[07:11]  * pitti re-runs the two proposed versions against each other
[08:36] <darkxst> pitti, your piloting today? can you take a look at bug 1509946, i can't upload since its a new source package with the gdm3 rename
[08:37] <pitti> darkxst: oh, am I? indeed
[08:38] <darkxst> pitti, that is what the calender says!
[08:39] <pitti> darkxst: I'll have a look soon then
[08:40] <darkxst> pitti, thanks
[08:54] <pitti> @pilot in
[08:56] <elbrus> pitti: do you now if the locale settings are different on the different autopkgtest machines for different archs?
[08:57] <elbrus> we propably found an issue with locales, postgresql and dbconfig-common
[08:57] <pitti> elbrus: autopkgtest always sets C.UTF-8 for the tests
[08:57] <elbrus> LC_ALL I assume?
[08:57] <pitti> elbrus: sorry, I didn't have time to look into the armhf failure yet, but still on my list
[08:57] <pitti> elbrus: no, LANG=C.UTF-8 and it unsets all LC_*
[08:57] <elbrus> doesn't look like regression.. this probably never works under the same circumstances
[08:58] <pitti> and unsets $LANGUAGE too
[08:58] <elbrus> where does the en_US come from then?
[08:58] <elbrus> pitti: and "LC_CTYPE setting requires encoding "LATIN1""
[08:59]  * elbrus doesn't know all the details of locales
[08:59] <pitti> en_US> no idea right now; but I don't see LATIN1 anywhere in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_152940@/log.gz
[08:59] <pitti> oh, that's the "hostname: Temporary failure in name resolution" bit
[09:00] <elbrus> pitti: it was the next log that failed on locale, this one failed on hostname not found
[09:00] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz
[09:00] <pitti> right
[09:00] <elbrus> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz
[09:00] <elbrus> yes
[09:13] <elbrus> pitti: I think postgresql is installed with the wrong locale, but why only on armhf? i.e. why doesn't this happen on all archs the same?
[09:13] <elbrus> and yes, for utf-8 to work the locale should have been en_US.UTF-8
[09:14] <elbrus> during INSTALL of postgresql, so out of control of dbconfig-common
[09:14] <pitti> elbrus: the biggest difference between armhf and the other arches is that we run armhf tests in LXC containers, the others in full (QEMU) instances in the cloud
[09:14] <pitti> so far I don't know where the en_US comes from, it's neither from dbconfig-common nor postgresql-common
[09:16] <elbrus> indeed
[09:18] <elbrus> pitti: do you think there is anything that I can do at this moment?
[09:19] <pitti> currently running this locally with lxc
[09:19] <elbrus> ack
[09:19] <pitti> to see if it reproduces there
[09:19] <pitti> (i. e. on amd64)
[09:19] <elbrus> aha, to check if it is lxc thingy
[09:19] <elbrus> my lxc's work fine
[09:20] <pitti> first run failed becuse it interactively asked for some host name
[09:20] <elbrus> (I did all my testing creating the autopkgtest in a lxc)
[09:20] <pitti> now running with < /dev/null to quiesce that
[09:20] <elbrus> but I didn't do anything specific to the locales
[09:21] <elbrus> so I got the Debian default
[09:21] <pitti> might that be some default value of "locales" on installation if you don't specify anything?
[09:22] <elbrus> you mean in postgresql? it takes it from the system, yes (reading on internet)
[09:23] <elbrus> specifically LC_CTYPE
[09:23] <pitti> passes here
[09:23] <pitti> so, this needs to be investigated on the armhf machiens
[09:24] <elbrus> and LC_COLLATE
[09:24] <pitti> ah, maybe debootstrap defaults to en_US; adt-run sets LANG=C.UTF-8 into the test env, but it doesn't change /etc/default/locale
[09:25] <pitti> but then this should apply to amd64 containers too
[09:25] <pitti> really, need to find some time to look into this
[09:25] <elbrus> does it makes sense to mark armhf as failed_always then for now? This is a new autopkgtest that fails.
[09:26] <pitti> I can't specifically mark armhf, but I can mark the test as broken for now
[09:26] <elbrus> the previous one on willy was only one test, I now have three
[09:27] <elbrus> ouch
[09:28]  * elbrus wonders how many dbconfig-common based packages are actively setting the encoding (and thus may be buggy in this sense)
[09:36] <pitti> elbrus: the production boxes have
[09:36] <pitti> # cat adt-xenial/rootfs/etc/default/locale
[09:36] <pitti> #  File generated by update-locale
[09:36] <pitti> LANG=en_US.UTF-8
[09:36] <pitti> elbrus: while my local container has LANG=de_DE.UTF-8; apparently it takes that from the environment you create the container in
[09:37] <pitti> so if anything, it ought to work *worse* in  my local one..
[09:37] <elbrus> yes, but it is utf-8
[09:37] <pitti> but I don't see en_US anywhere; and that's latin1, and just ought to die, die, die
[09:37] <elbrus> so that's fine.
[09:37] <elbrus> also not on the system that created the lxc?
[09:38] <pitti> no, that's en_US.UTF-8 too
[09:38] <pitti> elbrus: we never supported/created non-UTF-8 locales in ubuntu (aside from C)
[09:39] <pitti> so, where on earth does that come from
[09:41]  * elbrus has to go for a while...
[10:05] <LocutusOfBorg1> pitti, why llvm-3.7 doesn't migrate? the previous one didn't build on i386 and powerpc too
[10:06] <seb128> LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[10:07] <seb128> LocutusOfBorg1, I think it was in binNEW
[10:07] <seb128> unsure when the binaries got NEWEd and if britney refreshed since
[10:07] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-3.7 in particular
[10:07] <pitti> right, NEW is empty now, so perhaps someone just did that
[10:08] <rbasak> So I'm working on merging monitoring-plugins, and the Debian maintainer would prefer to take patches and not have us maintain a delta in Ubuntu. But we need to drop a build dep in Ubuntu because it's in universe.
[10:09] <rbasak> Am I right in thinking that there's no way to do this conditionally based on dpkg-vendor, since it's a build dep?
[10:09] <LocutusOfBorg1> thanks
[10:10] <Unit193> rbasak: Unless there's something new, correct.
[10:11] <rbasak> Unit193: thanks.
[10:14] <seb128> wooot pitti piloting
[10:15] <seb128> there goes the remaining for the queue! ;-)
[10:15]  * seb128 donne une accolade Ã  pitti
[10:15]  * pitti te donne une accolade en retour
[10:32]  * dholbach hugs pitti
[10:32]  * pitti hugs dholback
[10:32] <Unit193> dhugbach
[10:36] <dholbach> :-)
[10:50] <LocutusOfBorg1> wow, how many merges done in a few minutes
[10:57] <seb128> pitti, unsure how much of the queue you are going to cover but you might want to look at bug #525674 you already reviewed/commented on it in a previous round
[11:00] <pitti> meh @ bug 1498370
[11:00] <pitti> this is a sponsor's waste of time
[11:02] <pitti> seb128: looking
[11:02] <seb128> pitti, danke
[11:22] <pitti> seb128: meh, u-n is currently FTBFS
[11:23] <pitti> Err http://localhost:59762/canary-file.txt
[11:23] <pitti>   403  Forbidden file type or location: http://localhost:59762/canary-file.txt
[11:23] <pitti> E: Failed to fetch http://localhost:59762/canary-file.txt  403  Forbidden file type or location: http://localhost:59762/canary-file.txt
[11:23] <pitti> what on earth should that be
[11:23] <seb128> bah :-/
[11:24] <Laney> mvooooooooooooooooo
[11:26] <pitti> ah, it trips over my proxy setting in the shroot
[11:27] <pitti> disabling it helps
[11:33] <pitti> seb128: there goes the remaining for the queue> can't -- I dealt with some 15 items in the queue, but it grows so far
[11:33] <pitti> fast
[11:33] <pitti> I started with 48, it's still at 43..
[11:34] <pitti> ok, and at least 4 just lag due to build/proposed-migration
[11:35] <seb128> pitti, sorry, I added some :-/
[11:35] <doko> somebody just unblocked the ocaml/giflib/whatever transition. ta!
[11:35] <seb128> I do review +patches sometimes
[11:35] <seb128> doko, beers go to Laney I think
[11:35] <seb128> though I pressed some buttons so I wouldn't say no to a pint as well :p
[11:36] <doko> seb128, next sprint or Debconf ;p
[11:36] <seb128> deal :-)
[11:36] <Laney> was a good team effort
[11:36] <Laney> sil2100: slangasek: seb128: good work
[11:36] <Laney> woah, you all start with s
[11:37] <seb128> hehe
[11:37] <seb128> indeed was a good team effort
[11:37] <sil2100> \o/
[11:44]  * sil2100 just got spammed with no-change rebuild migration e-mail
[11:57] <mdeslaur> pitti: huh? It should work with either
[14:16] <cjwatson> stgraber,hallyn_: did lxc break in xenial recently?  http://paste.ubuntu.com/13247579/
[14:16] <cjwatson> (repeatable: I can't start any of my containers at the moment)
[14:17] <cjwatson> upgraded to lxc 1.1.5-0ubuntu1 last night, I expect it relates to that
[14:17] <pitti> wily and xenial containers start fine here, I don't have a trusty one at hand
[14:17] <pitti> (same lxc version)
[14:17] <pitti> oh, I do have trusty containers as user container, not system one; that works too
[14:18] <cjwatson> same with precise containers
[14:18] <cjwatson> I don't have any containers newer than trusty ;-)
[14:18] <pitti> cjwatson: we clearly work on different things :)
[14:19] <cjwatson> I've also just rebooted, that made no difference
[14:25] <cjwatson> pitti: are you running a wily/xenial kernel?
[14:25] <cjwatson> clone(child_stack=0x7ffde67d2280, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 6324
[14:25] <cjwatson> certainly seems odd ...
[14:25] <pitti> cjwatson: xenial du jour
[14:25] <cjwatson> access("/proc/6324/ns", X_OK)           = 0
[14:25] <cjwatson> open("/proc/6324/ns/mnt", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
[14:25] <pitti> 4.2.0-17-generic
[14:25] <cjwatson> ditto
[14:25] <pitti> cjwatson: is your's a system or user container?
[14:26] <pitti> I tried trusty/user (unpriv) and {wily,xenial}/system, not yet trusty/system
[14:26] <cjwatson> system
[14:26] <pitti> lxd also works, but that's more like user containers
[14:26] <cjwatson> I'm sure I probably should migrate to user containers for a bunch of things, but haven't yet
[14:26]  * pitti runs $ sudo lxc-create -n trusty1 -t download -- -d ubuntu -r trusty -a amd64
[14:27] <pitti> boots fine
[14:29] <cjwatson> pitti: same thing for me after "sudo lxc-create -n trusty-test -t ubuntu -- -r trusty"
[14:29] <cjwatson> it doesn't really seem to be about the container contents though, given that strace fragment
[14:30] <pitti> cjwatson: do you get an AA violation in dmesg?
[14:30] <pitti> $ LANG= cat /proc/$$/ns/mnt
[14:31] <pitti> cat: /proc/3924/ns/mnt: Invalid argument
[14:31] <pitti> hm, that's a bit odd, but not EACCESS
[14:31] <cjwatson> strace: http://paste.ubuntu.com/13247663/
[14:32] <cjwatson> pitti: no
[14:32] <pitti> 1961  access("/proc/1974/ns", X_OK)     = 0
[14:32] <pitti> 1961  open("/proc/1974/ns/mnt", O_RDONLY|O_CLOEXEC) = 15
[14:32] <pitti> 1961  open("/proc/1974/ns/pid", O_RDONLY|O_CLOEXEC) = 16
[14:32] <pitti> 1961  open("/proc/1974/ns/uts", O_RDONLY|O_CLOEXEC) = 17
[14:32] <pitti> 1961  open("/proc/1974/ns/ipc", O_RDONLY|O_CLOEXEC) = 18
[14:32] <pitti> 1961  open("/proc/1974/ns/net", O_RDONLY|O_CLOEXEC) = 19
[14:32] <pitti> here
[14:33] <pitti> stgraber: please fix the strcmp(pw->pw_nam, "cjwatson")
[14:34] <cjwatson> let's try downgrading lxc
[14:36] <cjwatson> starts fine with lxc 1.1.4-0ubuntu3
[14:39]  * cjwatson files https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1516037
[15:33] <hallyn_> cjwatson: very odd.  grabbing the 1.1.4-0ubuntu3 source to looka t debdiff...
[15:53] <stgraber> hallyn_: hmm, why did preserve_ns kick in here
[15:58] <stgraber> hallyn_: FYI, that's 1.1.4 to 1.1.5: http://paste.ubuntu.com/13248147/
[15:58] <stgraber> 8cecbd386123dfcb291b96b23a38fb9d74d2ea3b preserve container namespace
[15:58] <stgraber> 5b657f6bfee3d6b238a37ad2f3dcac37a224a333 start.c:preserve_ns: added pid parameter
[15:58] <stgraber> hallyn_: those are the most likely candidate ^
[16:10] <hallyn_> stgraber: wondering whether getpid() is returning invalid number
[16:12] <stgraber> hallyn_: the thing is, I'm not seeing the getpid which returned 7170 in cjwatson's strace but 7170 is the pid of one of our sub-processes
[16:12] <stgraber> hallyn_: what doesn't make sense is that my reading of the code is that getpid and preserve_ns are happening in the same process, so I don't understand why getpid would have happened in 7170 and then preserve_ns in 7160
[16:13] <stgraber> hallyn_: not that any of this really explains everything, we're talking privileged container here, lxc-start is root, so permission denied shouldn't be possible...
[16:13] <stgraber> hallyn_: getting no such file or directory would indicate an invalid pid but here the process does seem to exist
[16:14] <stgraber> Anyway, I'm updating my laptop, will then reboot and see if I've got any luck at reproducing this. Also asked a few more question for cjwatson in the bug report.
[16:25] <pitti> @pilot out
[16:26] <stgraber> hallyn_: oh, nevermind that part, the failing preserve_ns is the second one, which uses handler->pid
[16:27] <hallyn_> hm
[16:27] <stgraber> hallyn_: at this point, I think we'd need to go dig in the kernel to figure out in what case can we get EACCES as root
[16:28] <stgraber> hallyn_: because AFAICT, lxc_clone succeeds, we get a valid pid back, then we attempt to open ns/mnt and get EACCES, so the process does exist, we are root and we can't open ns/mnt
[16:28] <hallyn_> stgraber: but pitti said itworked for him on xenial
[16:29] <hallyn_> so it's even more weird, whatever's going on
[16:29] <stgraber> hallyn_: yep, and so does it here :)
[16:29] <stgraber> and in autopkgtest and in upstream jenkins
[16:30] <stgraber> hallyn_: also what's odd is that it's the open that's failing. Usually we see errors at setns instead :)
[16:33]  * hallyn_ thinks ptrace is involved somehow,
[16:34] <hallyn_> yama
[16:34] <stgraber> hallyn_: something else which doesn't make sense is that looking at the code, we call preserve_ns twice but the strace from cjwatson only shows the second
[16:35] <stgraber> oh, no, nevermind, I'm blind
[16:35] <stgraber> was grepping for /ns/ which didn't get me the first access with just /proc/7160/ns
[16:36] <stgraber> hallyn_: and yeah, that's very much smells like a LSM messing with things but dmesg is clean...
[16:37] <cjwatson> I can get a full dmesg if you need it, but the relevant bits were basically just witter about network interfaces coming up and down
[16:38] <stgraber> If there was a denial, you'd have seen it. Unfortunately, LSMs don't have to log.
[16:40] <stgraber> cjwatson: just to confirm it's not some apparmor weirdness, could you unload all profile (sudo /etc/init.d/apparmor teardown) and try again?
[16:40] <cjwatson> just a minute while I stop containers
[16:41] <stgraber> it sure looks like something wrong's going on in the kernel here but I have no idea why it's apparently only hitting your system :)
[16:41] <cjwatson> stgraber: what's the restoration process after teardown?  reboot?
[16:42] <stgraber> cjwatson: /etc/init.d/apparmor start will reload all the profiles but won't apply them to running processes, for that you'd need to restart the various services, or indeed, reboot
[16:43] <cjwatson> stgraber: well, you're right, tearing down apparmor lets the container start
[16:43] <stgraber> oh, that's interesting
[16:44] <stgraber> cjwatson: can you try starting apparmor again and confirm that things fail again?
[16:44] <stgraber> for lxc specifically, no reboot should be required, just start apparmor and start the container again
[16:44] <hallyn_> any chance you customized your usr.bin.lxc-start profile at some point?
[16:44] <cjwatson> stgraber: it still works
[16:45] <hallyn_> !
[16:45] <cjwatson> hallyn_: it is not impossible
[16:45] <stgraber> well, I didn't expect that one :)
[16:45] <cjwatson> /etc/apparmor.d/local/usr.bin.lxc-start has nothing
[16:45] <hallyn_> do you have dpkg-backup copy of /etc/apparmor.d/abstractions/lxc/start-container by chance?
[16:46] <cjwatson> http://paste.ubuntu.com/13248531/
[16:46] <hallyn_> (which doesn't contain "ptrace,")
[16:46] <cjwatson> no .dpkg-foo files for that
[16:46] <stgraber> ok, let me grab the magic apparmor command that dumps things in a way we can diff
[16:47] <stgraber> not that any of this really makes sense because if it's a subtile profile difference, starting apparmor would have caused the issue to re-appear
[16:48] <stgraber> root@castiana:~# apparmor_parser -p /etc/apparmor.d/lxc-containers /etc/apparmor.d/usr.bin.lxc-start | md5sum
[16:48] <stgraber> cd7c4c6466b21dc77bea45660674c933  -
[16:48] <stgraber> that's on clean xenial (reproducible) ^
[16:48] <cjwatson> 8e3943455937a5a09eccfa742d8c58c1  -
[16:48] <stgraber> oh
[16:49] <stgraber> can you dump the output somewhere?
[16:49] <cjwatson> it won't have anything private, right?
[16:49] <cjwatson> doesn't especially look like it
[16:49] <stgraber> correct, it's just the expanded version of the lxc profile
[16:49] <cjwatson> http://paste.ubuntu.com/13248559/
[16:51] <stgraber> -/usr/bin/lxc-start flags=(attach_disconnected) {
[16:51] <stgraber> +/usr/bin/lxc-start {
[16:52] <stgraber> and some different ordering (not as reproducible as it looks, then), but the above could very well explain what you're seeing
[16:53]  * stgraber applies same change as cjwatson's usr.bin.lxc-start and reboots
[16:55] <stgraber> reminds me I need to talk to pitti about my laptop not shutting down properly (have to wait the 1m30 timeout for systemd to give up and force reboot)
[16:55] <stgraber> lxc-start: start.c: preserve_ns: 156 Permission denied - failed to open '/proc/1937/ns/mnt'
[16:56] <stgraber> cjwatson: bingo, that's the issue!
[16:56] <stgraber> cjwatson: so restore your /etc/apparmor.d/usr.bin.lxc-start to what we ship in our package and you should be fine. (clean content is http://paste.ubuntu.com/13248615/)
[16:58] <hallyn_> stgraber: i accept that that's what did it, but it doesn't really make sense.  /proc/pid/ns/mnt should not have been disconnected!
[16:58] <hallyn_> unless apparmor treats all the ns fds as disconnected
[16:58] <hallyn_> since the fs isn't mounted anywhere
[16:58] <hallyn_> 'fs'
[16:59] <hallyn_> jjohansen: ^ do you know whether that's the case?
[16:59] <cjwatson> no idea how that happened - I might have modified that in the distant past
[16:59] <stgraber> also, it's kinda annoying that "/etc/init.d/apparmor reload" no longer works in xenial, triggers some systemd thing which fails...
[16:59]  * stgraber reboots again
[17:00] <stgraber> the upside is, lxc in xenial actually works so I can get back to preparing my current upload and don't have to wait for us to bundle another bugfix in there :)
[17:02] <stgraber> cjwatson: can you confirm that restoring the profile to its default value and rebooting (unless you find a way to avoid the systemd issue and call reload) fixes things for you?
[17:02] <cjwatson> stgraber: confirmed, thanks
[17:02] <stgraber> cjwatson: great, closing the bug then
[17:02] <cjwatson> I removed the file and used dpkg -i --force-confmiss
[17:03] <stgraber> ah yeah, that'd trigger our postinst which does a straight apparmor_parser call :)
[17:05] <cjwatson> well, I rebooted too :)
[17:05] <cjwatson> thanks for the debugging help, that was pretty opaque to me
[17:07] <hallyn_> stgraber: well there is https://bugs.launchpad.net/bugs/1516008 but it's clearly a kernel (likely aa) regression (regarding xenial  lxc bugs :)
[17:09] <stgraber> hallyn_: no, it's not
[17:09] <stgraber> hallyn_: it's just the cloud-image stream being broken, has been for days
[17:10] <stgraber> hallyn_: see, it's downloading xenial-server-cloudimg-amd64-lxd.tar.xz instead of xenial-server-cloudimg-amd64-root.tar.xz
[17:10] <hallyn_> doh.  i looked for that in the report but missed that failure
[17:10] <hallyn_> just saw the missing /etc/localtime or whatever
[17:10] <stgraber> so it's an "expected" failure until Odd_Bloke, utlemming, gaughen, rcj ... fix the daily stream
[17:11] <stgraber> apw: ^ FYI, I'll be closing your bug report against lxc as invalid, the problem is a broken simplestream which I've mentioned to the CPC team a week ago and hasn't been fixed yet
[17:12] <stgraber> I'm just failing to understand why adding 20 lines of json is taking so long though
[17:13] <apw> stgraber, or reassign it to simplestreams, and then i will whine at them instead ;)
[17:13] <stgraber> apw: IIRC the CPC stuff is a private project, not sure how to re-assign to it.
[17:13] <apw> isn't simpletreams a thing in the archive, its not quite right, but
[17:13] <stgraber> apw: hopefully the highlight in here will be enough to get things moving, it's been breaking all our tests for a while now
[17:14] <stgraber> apw: the client is, yeah, the server isn't
[17:53] <Laney> cjwatson: I got an action item to ask you if ssh-askpass-gnome is still needed (it's seeded on desktop)
[17:54] <cjwatson> Laney: I guess that depends on whether a system without it does something sensible when it needs to ask for a password
[17:54] <cjwatson> I suppose it goes through the horrible seahorse agent nowadays?
[17:55] <cjwatson> which e.g. doesn't support modern key formats
[17:56] <cjwatson> so ... I don't think it's needed in the absolute default configuration, it just might be worth bearing in mind that users with not very unusual requirements might have needed to switch to openssh's agent and then it's needed.  but maybe that's not a strong enough reason to have a GTK2 thing in desktop
[17:58] <Unit193> https://bugzilla.gnome.org/show_bug.cgi?id=754028 not bad progress though.
[18:03] <Laney> Doesn't seem to be much on the g-k side
[18:04] <Laney> anyway, thanks for info - got to go but I'll look at bit next week
[18:04] <Laney> bye!
[18:04] <cjwatson> Laney: I could probably port ssh-askpass-gnome to GTK3 without too much trouble if that would help
[18:18] <chiluk> hey arges.. what would need to happen in order to get an upstream version of findutils into xenial?
[18:19] <chiluk> basically the versino we have right now is cerca 2009
[18:20] <Unit193> chiluk: There's one in experimental.
[18:35] <arges> chiluk: maybe we need to sync that version cvhecking
[18:36] <richmb> infinity: I was asking questions about the ubuntu core minimal rootfs in #snappy, orga referred me to you.  The Wiki page seems like it hasn't been updated in a while, but the releases have.  Is this going to be supported/updated in future releases?
[18:37] <tdaitx> pitti, I just saw LP: #1497420, while unrelated, I have been unable to lxc-attach into a Xenial container from my Wily host... http://paste.ubuntu.com/13249491/
[18:38] <arges> chiluk: $ requestsync findutils
[18:38] <arges> W: Target release missing - assuming xenial
[18:38] <arges> E: The versions in Debian and Ubuntu are the same already (4.4.2-10). Aborting.
[18:39] <tdaitx> pitti, attaching to precise, trusty, vivid, and wily containers works fine... besides it being a Xenial container the only difference is that it was created just now (the other containers have been around for a while)
[18:39] <arges> chiluk: 4.5.x is still an alpha version, maybe that's why it hasn't hit sid
[18:40] <infinity> richmb: Yeah, it continues to be updated.  As for "supported", there's not much to support.  It's a very minimal rootfs that pretty much does what it says on the tin.
[18:41] <richmb> infinity: we like it because it was very easy to port to various arm targets.  But we just wanted to make sure that future ubuntu releases would still be available before we chose to use it on a bunch of our products.
[18:42] <infinity> richmb: It's not going away any time soon.  It's also a handy and quick infrastructure test case. ;)
[18:45] <chiluk> hmm thanks arges.
[18:48] <chiluk> well that's really ugly.  arges Unit193  .. how did you determine that 4.5.x is still an alpha version?
[18:49] <chiluk> or is it just debian alpha.
[18:49] <Unit193> chiluk: I just mentioned it was in EXP, didn't look into it. :)
[18:50] <chiluk> I'm looking at https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
[18:50] <chiluk> and it seems to have been resolved in upstream.
[18:50] <chiluk> let me check version
[18:50] <arges> i just found the source here: ftp://alpha.gnu.org/gnu/findutils
[18:50] <arges> instead of at the normal ftp site
[18:51] <chiluk> hmm that's odd.
[18:51] <chiluk> well the fix we need for 1347788 is in 4.5.9
[18:52] <chiluk> and a backport is proving as bad if not worse than the recent coreutils backport I pained through.
[18:54] <richmb> infinity: How is ubuntu core related to ubuntu server and desktop.  Is it used to build them? or extracted from them?
[18:55] <chiluk> richmb: extracted from them afaik
[18:57] <infinity> Neither, really.
[18:58] <infinity> It's a separate build that just has a minimal set of packages and (as you've no doubt discovered, if you use it) no installer or initial setup.
[18:59] <mvo> infinity: https://launchpad.net/~mvo/+archive/ubuntu/apt-xenial will soon have some stuff, preparing the abi change merge
[19:00] <Unit193> Speaking of which...
[19:00] <infinity> mvo: ABI change?  Is that 1.1?
[19:00] <infinity> mvo: If it's 1.1, you're my favourite mvo in the whole world.
[19:02] <bdmurray> mvo: no phasing support?
[19:02] <infinity> I'm still dubious of phasing in apt proper.
[19:03] <infinity> I guess it would need to be an apt.conf tunable, defaulting to off, and we'd drop a conffile in.
[19:03] <infinity> Or something.
[19:03] <infinity> Definitely needs to be overridable.
[19:06] <richmb> infinity: Any reason why Ubuntu core would not be a suitable long term base rootfs for a industrial product?
[19:07] <infinity> richmb: IMO, it's fine for that use (and one of the reasons we produced it), though if you're swayed by the idea of transaction/image updates instead of apt-get, snappy's worth a look.
[19:07] <infinity> richmb: Right tool for the job, etc.  I'm not in the business of forcing decisions on others, evaluate what you need and go nuts.
[19:08] <richmb> infinity: we did like snappy, but had troubles porting it.
[19:12] <infinity> richmb: Well, if snappy's attractive, but giving you issues, ogra's team are the people to talk to.  But I won't recommend against classic ubuntu-core either, it gets the job done, just differently.
[19:13] <infinity> richmb: The key difference is just how you design your update strategy, since shipping 100k units of a network-connected product with no plan for how you're going to address, say, security issues or critical bugs, is generally unwise.  But that problem exists for both snappy and classic core, just that the solutions differ.
[19:15] <infinity> richmb: On the flip side, if it's a more classic pure embedded sort of device with no contact with the outside world, updates become a think no one really cares about, and your flexibility for how you construct it goes up a bit.
[19:15] <infinity> s/a think/a thing/
[19:16] <richmb> infinity: we're more so in the embedded bucket.  non-internet connected product
[19:19] <richmb> infinity: thanks a bunch.  I have a better feel for ubuntu core's future.  I'll ask about our snappy porting issues in  #snappy.
[19:19] <infinity> richmb: Yeah, then update stories are slightly less interesting.  You still need a way to get "our product sucks, here's an update" fixes out to users, but you don't need to worry about 0-day root exploits or anything.
[19:20] <infinity> Or, if you're confident in your QA, you don't even necessarily need the "we suck" updates.  Depends on your process, of course. :P
[19:24] <richmb> we still want ability to update various os/kernel packages.  just for the sake of easier sharing code between new and old products.
[19:53] <mvo> infinity: hm, hm, looks like the new apt does not like the ppa chroots https://launchpadlibrarian.net/226517672/buildlog_ubuntu-xenial-amd64.python-apt_1.1.0~alpha3ubuntu1~ppa1_BUILDING.txt.gz I will need to do some digging
[21:24] <popey> pitti, got my apport / caja crash loop thing again, but I guess you're not around :)
[21:25] <popey> Ooh! I think I know what it is, dropbox!