/srv/irclogs.ubuntu.com/2015/11/13/#ubuntu-devel.txt

=== waspinator_ is now known as waspinator
=== alvesadrian is now known as adrian
=== mhall119_ is now known as mhall119
pittiteward: no, in general package hooks are being run04:00
pittiteward: they might cause an exception of course, and then will be ignored04:00
pittimdeslaur: hm, you changed the pythons to rely on the new value of the -proposed openssl, not to work with either07:09
pittibut no bump of dependencies, so they block each other in -proposed now07:09
* pitti re-runs the two proposed versions against each other07:11
darkxstpitti, your piloting today? can you take a look at bug 1509946, i can't upload since its a new source package with the gdm3 rename08:36
ubottubug 1509946 in gdm (Ubuntu) "Update to 3.18.0" [Wishlist,Triaged] https://launchpad.net/bugs/150994608:36
pittidarkxst: oh, am I? indeed08:37
darkxstpitti, that is what the calender says!08:38
pittidarkxst: I'll have a look soon then08:39
darkxstpitti, thanks08:40
pitti@pilot in08:54
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
elbruspitti: do you now if the locale settings are different on the different autopkgtest machines for different archs?08:56
elbruswe propably found an issue with locales, postgresql and dbconfig-common08:57
pittielbrus: autopkgtest always sets C.UTF-8 for the tests08:57
elbrusLC_ALL I assume?08:57
pittielbrus: sorry, I didn't have time to look into the armhf failure yet, but still on my list08:57
pittielbrus: no, LANG=C.UTF-8 and it unsets all LC_*08:57
elbrusdoesn't look like regression.. this probably never works under the same circumstances08:57
pittiand unsets $LANGUAGE too08:58
elbruswhere does the en_US come from then?08:58
elbruspitti: and "LC_CTYPE setting requires encoding "LATIN1""08:58
* elbrus doesn't know all the details of locales08:59
pittien_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.gz08:59
pittioh, that's the "hostname: Temporary failure in name resolution" bit08:59
elbruspitti: it was the next log that failed on locale, this one failed on hostname not found09:00
pittihttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz09:00
pittiright09:00
elbrushttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/d/dbconfig-common/20151111_084807@/log.gz09:00
elbrusyes09:00
elbruspitti: 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
elbrusand yes, for utf-8 to work the locale should have been en_US.UTF-809:13
elbrusduring INSTALL of postgresql, so out of control of dbconfig-common09:14
pittielbrus: 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 cloud09:14
pittiso far I don't know where the en_US comes from, it's neither from dbconfig-common nor postgresql-common09:14
elbrusindeed09:16
elbruspitti: do you think there is anything that I can do at this moment?09:18
pitticurrently running this locally with lxc09:19
elbrusack09:19
pittito see if it reproduces there09:19
pitti(i. e. on amd64)09:19
elbrusaha, to check if it is lxc thingy09:19
elbrusmy lxc's work fine09:19
pittifirst run failed becuse it interactively asked for some host name09:20
elbrus(I did all my testing creating the autopkgtest in a lxc)09:20
pittinow running with < /dev/null to quiesce that09:20
elbrusbut I didn't do anything specific to the locales09:20
elbrusso I got the Debian default09:21
pittimight that be some default value of "locales" on installation if you don't specify anything?09:21
elbrusyou mean in postgresql? it takes it from the system, yes (reading on internet)09:22
elbrusspecifically LC_CTYPE09:23
pittipasses here09:23
pittiso, this needs to be investigated on the armhf machiens09:23
elbrusand LC_COLLATE09:24
pittiah, maybe debootstrap defaults to en_US; adt-run sets LANG=C.UTF-8 into the test env, but it doesn't change /etc/default/locale09:24
pittibut then this should apply to amd64 containers too09:25
pittireally, need to find some time to look into this09:25
elbrusdoes it makes sense to mark armhf as failed_always then for now? This is a new autopkgtest that fails.09:25
pittiI can't specifically mark armhf, but I can mark the test as broken for now09:26
elbrusthe previous one on willy was only one test, I now have three09:26
elbrusouch09:27
* elbrus wonders how many dbconfig-common based packages are actively setting the encoding (and thus may be buggy in this sense)09:28
pittielbrus: the production boxes have09:36
pitti# cat adt-xenial/rootfs/etc/default/locale09:36
pitti#  File generated by update-locale09:36
pittiLANG=en_US.UTF-809:36
pittielbrus: while my local container has LANG=de_DE.UTF-8; apparently it takes that from the environment you create the container in09:36
pittiso if anything, it ought to work *worse* in  my local one..09:37
elbrusyes, but it is utf-809:37
pittibut I don't see en_US anywhere; and that's latin1, and just ought to die, die, die09:37
elbrusso that's fine.09:37
elbrusalso not on the system that created the lxc?09:37
pittino, that's en_US.UTF-8 too09:38
pittielbrus: we never supported/created non-UTF-8 locales in ubuntu (aside from C)09:38
pittiso, where on earth does that come from09:39
* elbrus has to go for a while...09:41
LocutusOfBorg1pitti, why llvm-3.7 doesn't migrate? the previous one didn't build on i386 and powerpc too10:05
seb128LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html10:06
seb128LocutusOfBorg1, I think it was in binNEW10:07
seb128unsure when the binaries got NEWEd and if britney refreshed since10:07
pittihttp://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-3.7 in particular10:07
pittiright, NEW is empty now, so perhaps someone just did that10:07
rbasakSo 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:08
rbasakAm 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
LocutusOfBorg1thanks10:09
Unit193rbasak: Unless there's something new, correct.10:10
rbasakUnit193: thanks.10:11
seb128wooot pitti piloting10:14
seb128there goes the remaining for the queue! ;-)10:15
* seb128 donne une accolade à pitti10:15
* pitti te donne une accolade en retour10:15
* dholbach hugs pitti10:32
* pitti hugs dholback10:32
Unit193dhugbach10:32
dholbach:-)10:36
LocutusOfBorg1wow, how many merges done in a few minutes10:50
seb128pitti, 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 round10:57
ubottubug 525674 in update-notifier (Ubuntu) "apt-check hangs, preventing login via SSH" [Medium,Confirmed] https://launchpad.net/bugs/52567410:57
pittimeh @ bug 149837011:00
ubottubug 1498370 in neutron (Ubuntu Trusty) "[SRU] DHCP agent: interface unplug leads to exception" [Undecided,Incomplete] https://launchpad.net/bugs/149837011:00
pittithis is a sponsor's waste of time11:00
pittiseb128: looking11:02
seb128pitti, danke11:02
pittiseb128: meh, u-n is currently FTBFS11:22
pittiErr http://localhost:59762/canary-file.txt11:23
pitti  403  Forbidden file type or location: http://localhost:59762/canary-file.txt11:23
pittiE: Failed to fetch http://localhost:59762/canary-file.txt  403  Forbidden file type or location: http://localhost:59762/canary-file.txt11:23
pittiwhat on earth should that be11:23
seb128bah :-/11:23
Laneymvooooooooooooooooo11:24
pittiah, it trips over my proxy setting in the shroot11:26
pittidisabling it helps11:27
pittiseb128: there goes the remaining for the queue> can't -- I dealt with some 15 items in the queue, but it grows so far11:33
pittifast11:33
pittiI started with 48, it's still at 43..11:33
pittiok, and at least 4 just lag due to build/proposed-migration11:34
seb128pitti, sorry, I added some :-/11:35
dokosomebody just unblocked the ocaml/giflib/whatever transition. ta!11:35
seb128I do review +patches sometimes11:35
seb128doko, beers go to Laney I think11:35
seb128though I pressed some buttons so I wouldn't say no to a pint as well :p11:35
dokoseb128, next sprint or Debconf ;p11:36
seb128deal :-)11:36
Laneywas a good team effort11:36
Laneysil2100: slangasek: seb128: good work11:36
Laneywoah, you all start with s11:36
seb128hehe11:37
seb128indeed was a good team effort11:37
sil2100\o/11:37
* sil2100 just got spammed with no-change rebuild migration e-mail11:44
=== _salem is now known as salem_
mdeslaurpitti: huh? It should work with either11:57
=== nudtrobert1 is now known as nudtrobert
=== nudtrobert1 is now known as nudtrobert
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== balloons is now known as Guest56507
=== Guest56507 is now known as balloons_
cjwatsonstgraber,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:16
cjwatsonupgraded to lxc 1.1.5-0ubuntu1 last night, I expect it relates to that14:17
pittiwily and xenial containers start fine here, I don't have a trusty one at hand14:17
pitti(same lxc version)14:17
pittioh, I do have trusty containers as user container, not system one; that works too14:17
cjwatsonsame with precise containers14:18
=== balloons_ is now known as balloons
cjwatsonI don't have any containers newer than trusty ;-)14:18
pitticjwatson: we clearly work on different things :)14:18
cjwatsonI've also just rebooted, that made no difference14:19
cjwatsonpitti: are you running a wily/xenial kernel?14:25
cjwatsonclone(child_stack=0x7ffde67d2280, flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = 632414:25
cjwatsoncertainly seems odd ...14:25
pitticjwatson: xenial du jour14:25
cjwatsonaccess("/proc/6324/ns", X_OK)           = 014:25
cjwatsonopen("/proc/6324/ns/mnt", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)14:25
pitti4.2.0-17-generic14:25
cjwatsonditto14:25
pitticjwatson: is your's a system or user container?14:25
pittiI tried trusty/user (unpriv) and {wily,xenial}/system, not yet trusty/system14:26
cjwatsonsystem14:26
pittilxd also works, but that's more like user containers14:26
cjwatsonI'm sure I probably should migrate to user containers for a bunch of things, but haven't yet14:26
* pitti runs $ sudo lxc-create -n trusty1 -t download -- -d ubuntu -r trusty -a amd6414:26
pittiboots fine14:27
cjwatsonpitti: same thing for me after "sudo lxc-create -n trusty-test -t ubuntu -- -r trusty"14:29
cjwatsonit doesn't really seem to be about the container contents though, given that strace fragment14:29
pitticjwatson: do you get an AA violation in dmesg?14:30
pitti$ LANG= cat /proc/$$/ns/mnt14:30
pitticat: /proc/3924/ns/mnt: Invalid argument14:31
pittihm, that's a bit odd, but not EACCESS14:31
cjwatsonstrace: http://paste.ubuntu.com/13247663/14:31
cjwatsonpitti: no14:32
pitti1961  access("/proc/1974/ns", X_OK)     = 014:32
pitti1961  open("/proc/1974/ns/mnt", O_RDONLY|O_CLOEXEC) = 1514:32
pitti1961  open("/proc/1974/ns/pid", O_RDONLY|O_CLOEXEC) = 1614:32
pitti1961  open("/proc/1974/ns/uts", O_RDONLY|O_CLOEXEC) = 1714:32
pitti1961  open("/proc/1974/ns/ipc", O_RDONLY|O_CLOEXEC) = 1814:32
pitti1961  open("/proc/1974/ns/net", O_RDONLY|O_CLOEXEC) = 1914:32
pittihere14:32
pittistgraber: please fix the strcmp(pw->pw_nam, "cjwatson")14:33
cjwatsonlet's try downgrading lxc14:34
cjwatsonstarts fine with lxc 1.1.4-0ubuntu314:36
* cjwatson files https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/151603714:39
ubottuLaunchpad bug 1516037 in lxc (Ubuntu) "lxc-start fails with 1.1.5-0ubuntu1" [Undecided,New]14:39
=== smb` is now known as smb
hallyn_cjwatson: very odd.  grabbing the 1.1.4-0ubuntu3 source to looka t debdiff...15:33
stgraberhallyn_: hmm, why did preserve_ns kick in here15:53
stgraberhallyn_: FYI, that's 1.1.4 to 1.1.5: http://paste.ubuntu.com/13248147/15:58
stgraber8cecbd386123dfcb291b96b23a38fb9d74d2ea3b preserve container namespace15:58
stgraber5b657f6bfee3d6b238a37ad2f3dcac37a224a333 start.c:preserve_ns: added pid parameter15:58
stgraberhallyn_: those are the most likely candidate ^15:58
hallyn_stgraber: wondering whether getpid() is returning invalid number16:10
stgraberhallyn_: 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-processes16:12
stgraberhallyn_: 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 716016:12
stgraberhallyn_: 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
stgraberhallyn_: getting no such file or directory would indicate an invalid pid but here the process does seem to exist16:13
stgraberAnyway, 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:14
pitti@pilot out16:25
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
stgraberhallyn_: oh, nevermind that part, the failing preserve_ns is the second one, which uses handler->pid16:26
hallyn_hm16:27
stgraberhallyn_: 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 root16:27
stgraberhallyn_: 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/mnt16:28
hallyn_stgraber: but pitti said itworked for him on xenial16:28
hallyn_so it's even more weird, whatever's going on16:29
stgraberhallyn_: yep, and so does it here :)16:29
stgraberand in autopkgtest and in upstream jenkins16:29
stgraberhallyn_: also what's odd is that it's the open that's failing. Usually we see errors at setns instead :)16:30
* hallyn_ thinks ptrace is involved somehow,16:33
hallyn_yama16:34
stgraberhallyn_: 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 second16:34
stgraberoh, no, nevermind, I'm blind16:35
stgraberwas grepping for /ns/ which didn't get me the first access with just /proc/7160/ns16:35
stgraberhallyn_: and yeah, that's very much smells like a LSM messing with things but dmesg is clean...16:36
cjwatsonI can get a full dmesg if you need it, but the relevant bits were basically just witter about network interfaces coming up and down16:37
stgraberIf there was a denial, you'd have seen it. Unfortunately, LSMs don't have to log.16:38
stgrabercjwatson: 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
cjwatsonjust a minute while I stop containers16:40
stgraberit 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
cjwatsonstgraber: what's the restoration process after teardown?  reboot?16:41
stgrabercjwatson: /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, reboot16:42
cjwatsonstgraber: well, you're right, tearing down apparmor lets the container start16:43
=== greyback is now known as greyback|eow
stgraberoh, that's interesting16:43
stgrabercjwatson: can you try starting apparmor again and confirm that things fail again?16:44
stgraberfor lxc specifically, no reboot should be required, just start apparmor and start the container again16:44
hallyn_any chance you customized your usr.bin.lxc-start profile at some point?16:44
cjwatsonstgraber: it still works16:44
hallyn_!16:45
cjwatsonhallyn_: it is not impossible16:45
stgraberwell, I didn't expect that one :)16:45
cjwatson/etc/apparmor.d/local/usr.bin.lxc-start has nothing16:45
hallyn_do you have dpkg-backup copy of /etc/apparmor.d/abstractions/lxc/start-container by chance?16:45
cjwatsonhttp://paste.ubuntu.com/13248531/16:46
hallyn_(which doesn't contain "ptrace,")16:46
cjwatsonno .dpkg-foo files for that16:46
stgraberok, let me grab the magic apparmor command that dumps things in a way we can diff16:46
stgrabernot that any of this really makes sense because if it's a subtile profile difference, starting apparmor would have caused the issue to re-appear16:47
stgraberroot@castiana:~# apparmor_parser -p /etc/apparmor.d/lxc-containers /etc/apparmor.d/usr.bin.lxc-start | md5sum16:48
stgrabercd7c4c6466b21dc77bea45660674c933  -16:48
stgraberthat's on clean xenial (reproducible) ^16:48
cjwatson8e3943455937a5a09eccfa742d8c58c1  -16:48
stgraberoh16:48
stgrabercan you dump the output somewhere?16:49
cjwatsonit won't have anything private, right?16:49
cjwatsondoesn't especially look like it16:49
stgrabercorrect, it's just the expanded version of the lxc profile16:49
cjwatsonhttp://paste.ubuntu.com/13248559/16:49
stgraber-/usr/bin/lxc-start flags=(attach_disconnected) {16:51
stgraber+/usr/bin/lxc-start {16:51
stgraberand some different ordering (not as reproducible as it looks, then), but the above could very well explain what you're seeing16:52
* stgraber applies same change as cjwatson's usr.bin.lxc-start and reboots16:53
stgraberreminds 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
stgraberlxc-start: start.c: preserve_ns: 156 Permission denied - failed to open '/proc/1937/ns/mnt'16:55
stgrabercjwatson: bingo, that's the issue!16:56
stgrabercjwatson: 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:56
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 disconnected16:58
hallyn_since the fs isn't mounted anywhere16:58
hallyn_'fs'16:58
hallyn_jjohansen: ^ do you know whether that's the case?16:59
cjwatsonno idea how that happened - I might have modified that in the distant past16:59
stgraberalso, 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 again16:59
stgraberthe 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:00
stgrabercjwatson: 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
cjwatsonstgraber: confirmed, thanks17:02
stgrabercjwatson: great, closing the bug then17:02
cjwatsonI removed the file and used dpkg -i --force-confmiss17:02
stgraberah yeah, that'd trigger our postinst which does a straight apparmor_parser call :)17:03
cjwatsonwell, I rebooted too :)17:05
cjwatsonthanks for the debugging help, that was pretty opaque to me17:05
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:07
ubottuLaunchpad bug 1516008 in lxc (Ubuntu) "lxc: adt testing against v4.3 kernel failing" [Undecided,New]17:07
stgraberhallyn_: no, it's not17:09
stgraberhallyn_: it's just the cloud-image stream being broken, has been for days17:09
stgraberhallyn_: see, it's downloading xenial-server-cloudimg-amd64-lxd.tar.xz instead of xenial-server-cloudimg-amd64-root.tar.xz17:10
hallyn_doh.  i looked for that in the report but missed that failure17:10
hallyn_just saw the missing /etc/localtime or whatever17:10
stgraberso it's an "expected" failure until Odd_Bloke, utlemming, gaughen, rcj ... fix the daily stream17:10
stgraberapw: ^ 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 yet17:11
stgraberI'm just failing to understand why adding 20 lines of json is taking so long though17:12
apwstgraber, or reassign it to simplestreams, and then i will whine at them instead ;)17:13
stgraberapw: IIRC the CPC stuff is a private project, not sure how to re-assign to it.17:13
apwisn't simpletreams a thing in the archive, its not quite right, but17:13
stgraberapw: hopefully the highlight in here will be enough to get things moving, it's been breaking all our tests for a while now17:13
stgraberapw: the client is, yeah, the server isn't17:14
Laneycjwatson: I got an action item to ask you if ssh-askpass-gnome is still needed (it's seeded on desktop)17:53
cjwatsonLaney: I guess that depends on whether a system without it does something sensible when it needs to ask for a password17:54
cjwatsonI suppose it goes through the horrible seahorse agent nowadays?17:54
cjwatsonwhich e.g. doesn't support modern key formats17:55
cjwatsonso ... 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 desktop17:56
Unit193https://bugzilla.gnome.org/show_bug.cgi?id=754028 not bad progress though.17:58
ubottuGnome bug 754028 in Daemon "No support for ed25519 and ecdsa SSH keys" [Enhancement,New]17:58
LaneyDoesn't seem to be much on the g-k side18:03
Laneyanyway, thanks for info - got to go but I'll look at bit next week18:04
Laneybye!18:04
cjwatsonLaney: I could probably port ssh-askpass-gnome to GTK3 without too much trouble if that would help18:04
chilukhey arges.. what would need to happen in order to get an upstream version of findutils into xenial?18:18
chilukbasically the versino we have right now is cerca 200918:19
Unit193chiluk: There's one in experimental.18:20
argeschiluk: maybe we need to sync that version cvhecking18:35
richmbinfinity: 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:36
tdaitxpitti, 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:37
ubottuLaunchpad bug 1497420 in lxcfs (Ubuntu) "systemd 226 (moving pid 1 into /init.scope cgroup) breaks lxc-attach" [High,Fix released] https://launchpad.net/bugs/149742018:37
argeschiluk: $ requestsync findutils18:38
argesW: Target release missing - assuming xenial18:38
argesE: The versions in Debian and Ubuntu are the same already (4.4.2-10). Aborting.18:38
tdaitxpitti, 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
argeschiluk: 4.5.x is still an alpha version, maybe that's why it hasn't hit sid18:39
infinityrichmb: 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:40
richmbinfinity: 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:41
infinityrichmb: It's not going away any time soon.  It's also a handy and quick infrastructure test case. ;)18:42
chilukhmm thanks arges.18:45
chilukwell that's really ugly.  arges Unit193  .. how did you determine that 4.5.x is still an alpha version?18:48
chilukor is it just debian alpha.18:49
Unit193chiluk: I just mentioned it was in EXP, didn't look into it. :)18:49
chilukI'm looking at https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/134778818:50
ubottuLaunchpad bug 1347788 in findutils (Ubuntu) "find crashed when current working directory is not readable and -exec or -execdir used" [Low,Confirmed]18:50
chilukand it seems to have been resolved in upstream.18:50
chiluklet me check version18:50
argesi just found the source here: ftp://alpha.gnu.org/gnu/findutils18:50
argesinstead of at the normal ftp site18:50
chilukhmm that's odd.18:51
chilukwell the fix we need for 1347788 is in 4.5.918:51
chilukand a backport is proving as bad if not worse than the recent coreutils backport I pained through.18:52
richmbinfinity: How is ubuntu core related to ubuntu server and desktop.  Is it used to build them? or extracted from them?18:54
chilukrichmb: extracted from them afaik18:55
infinityNeither, really.18:57
infinityIt'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:58
mvoinfinity: https://launchpad.net/~mvo/+archive/ubuntu/apt-xenial will soon have some stuff, preparing the abi change merge18:59
Unit193Speaking of which...19:00
infinitymvo: ABI change?  Is that 1.1?19:00
infinitymvo: If it's 1.1, you're my favourite mvo in the whole world.19:00
bdmurraymvo: no phasing support?19:02
infinityI'm still dubious of phasing in apt proper.19:02
infinityI guess it would need to be an apt.conf tunable, defaulting to off, and we'd drop a conffile in.19:03
infinityOr something.19:03
infinityDefinitely needs to be overridable.19:03
richmbinfinity: Any reason why Ubuntu core would not be a suitable long term base rootfs for a industrial product?19:06
infinityrichmb: 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
infinityrichmb: 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:07
richmbinfinity: we did like snappy, but had troubles porting it.19:08
infinityrichmb: 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:12
infinityrichmb: 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:13
infinityrichmb: 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
infinitys/a think/a thing/19:15
richmbinfinity: we're more so in the embedded bucket.  non-internet connected product19:16
richmbinfinity: 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
infinityrichmb: 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:19
infinityOr, if you're confident in your QA, you don't even necessarily need the "we suck" updates.  Depends on your process, of course. :P19:20
richmbwe still want ability to update various os/kernel packages.  just for the sake of easier sharing code between new and old products.19:24
mvoinfinity: 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 digging19:53
popeypitti, got my apport / caja crash loop thing again, but I guess you're not around :)21:24
popeyOoh! I think I know what it is, dropbox!21:25
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!