[02:03] <carif> almost there with my first simple snap, an "echo" shell script. The script isn't executable in the snap, but is in the "source" directory. is that what 'caps: []' does?
[06:35] <dholbach> good morning
[07:14] <fgimenez> good morning
[07:37] <biezpal> Hi guys, can anyone help us with libs in .snapp package? Where we should place our libs in snapp package to make it visible for app?
[07:38] <ogra_> anywhere you want ... just make sure to point LD_LIBRARY_PATH to it and export it
[07:38] <biezpal> and how we can set the variable for all users?
[07:39] <biezpal> now we are doing it manually
[07:41] <ogra_> you usually set it in your wrapper script for the binary or service
[07:44] <biezpal> alaik, automatically generated wrapper script is stored in /apps/bin/<appname>, but we cannot customize it during snapp installation. Am I right?
[07:45] <biezpal> Or we should create our own wrapper script which will be executed by automatically generated wrapper script?
[07:46] <ogra_> yes
[07:46] <ogra_> (the latter)
[07:47] <ogra_> seb128, hmm, did you ever try snappy update on personal ?
[07:47]  * ogra_ gets out of space errors for /system-boot
[07:47] <biezpal> thanks
[07:48] <seb128> ogra_, yes, remember me reporting those kernel mismatch error some days ago :p
[07:48] <seb128> ogra_, let me try with today's image
[07:48] <ogra_> i guess u-d-f needs to learn to assign a bigger /boot
[07:48] <ogra_> well, my update actually failed, i didnt get to a point where i could even boot into the update
[07:49] <seb128> it was working for me yesterday
[07:49] <seb128> well "working"
[07:49] <seb128> the updated system failed to load modules and booted in debug mode
[07:50] <ogra_> right, i remember
[07:51] <seb128> but it's weird, /boot shouldn't be bigger on personal than core, should it?
[07:52] <seb128> we use the same kernel
[07:52] <ogra_> the initrd might be
[08:03] <ogra_> hah ... booting with "kvm -m 384 -vga qxl personal_x86.img" works !
[08:03] <ogra_> -m 256 sadly doesnt anymore :(
[08:04] <seb128> so I've a "snappy update --automatic-reboot" process
[08:04] <seb128> is there any way to query it for status?
[08:05] <ogra_> not sure, sergiusens would know i guess ... or mvo
[08:05] <seb128> mvo is hidding again!
[08:07] <ogra_> hmm, i take back the above ... 384MB boots ... but i cant log in
[08:07] <seb128> stop asking for more
[08:07] <ogra_> (512M works fine though)
[08:12] <seb128> ogra_, I'm getting that "no space left on device" as well now
[08:12] <ogra_> i think we duplicate kernl and initrd now ...
[08:12] <ogra_> with and withoout version in the name ...
[08:16] <ogra_> hmm, no, a and b only have a single copy each
[08:20] <biezpal> ogra_, is there are plans to add something like "LD_LIBRARY_PATH" parameter into meta/package.yml ?
[08:21] <ogra_> no, i dont think so ... but we might add a standard path that the launcher defaults to ... (we use <appinstalldir>/lib/<arch> in click packages for example ... ) so you have a place that always works with extra variable hackery
[08:21] <ogra_> s/with/without/
[08:22] <biezpal> ogra_, cool, thx
[08:42] <pitti> sorry, I forgot: what do I have to downgrade in wily again to make ubuntu-device-flash work?
[08:42] <seb128> ogra_, ubuntu-core is having the same upgrade /boot size issue
[08:43] <ogra_> yeah, i would have expected so
[08:43] <pitti> ("panic: cannot double map partitions')
[08:43] <pitti> (we've had this for weeks, is it so hard to fix?)
[08:43] <ogra_> pitti, i think you should just retry ... iirc Chipaca had the same issue yesterday and it just worked at some point
[08:43] <ogra_> IIRC
[08:44] <pitti> I remember fgimenez downgraded something and then it worked
[08:44] <seb128> pitti, nothing to "downgrade" afaik, I'm using wily standard and not having issues
[08:44] <pitti> some *mutter* *mutter* go incompatibility
[08:44] <pitti> http://paste.ubuntu.com/11854764/
[08:46] <Chipaca> pitti: yes, that's the error we're talking about
[08:46] <pitti> and --channel=alpha with rolling doesn't work at all ("Failed to locate latest image information")
[08:46] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 has a mr ready for review, you might want to give the fix a try?
[08:47] <pitti> seb128: ah, thanks for the bug pointer!
[08:47] <seb128> yw!
[08:47] <Chipaca> pitti: AIUI even though the error isn't handled (hence the panic), it is "real" and coming from a race in partx or sth like that
[08:47] <Chipaca> and AIUI the fix to the error is to print it prettier
[08:47] <fgimenez> pitti, yep, it's already reported, as ogra_ mentioned retrying helps
[08:47] <pitti> ah, it seems the 7th retry worked
[08:48] <seb128> ogra_, so, who need to be nagged about "snappy upgrade" being busted because /boot is too small now?
[08:48] <ogra_> seb128, well, i see we only assign 63M in total for that partition ... u-d-f defines the partition sizes i think
[08:49] <ogra_> a) we need to get back to normal size again ... b) we should assign more space by default anyway
[08:49] <pitti> do I need anything else to enable ssh? sshd is running inside, but trying to ssh in just hangs
[08:50] <pitti> (I ran with --developer-mode, which should include --enable-ssh)
[08:50] <ogra_> it should even copy your key inside
[08:50] <pitti> I see the open port in netstat too
[08:50] <pitti> ah - eth0 is not up
[08:50] <ogra_> how long did you wait ... creating the host keys takes a while (cloud-init is pretty slow)
[08:50] <pitti> that would do it :)
[08:50] <ogra_> ah
[08:51] <ogra_> well, there is no eth0 anymore because someone changed the device names :P
[08:51] <pitti> there is an eth0 in qemu, it's just not up :)
[08:51]  * pitti runs sudo ifup eth0 for now
[08:51] <ogra_> oh ... there should be an entry for it in /e/n/interfaces.d/ then
[08:52] <ogra_> wonder why it isnt brought up now ...
[08:52] <pitti> ogra_, Chipaca: thanks for your help! enough to test the updated autopkgtest snappy script
[08:52] <ogra_> Chipaca, ^^ i guess we need to re-visit the NIC changes
[08:52]  * Chipaca reads
[08:53] <ogra_> (the configuration is created fine on boot apparently ... but the interface isnt brought up)
[08:53] <Chipaca> very odd
[08:54] <pitti> perhaps it's created too late?
[08:55] <pitti> i. e. after /etc/init.d/networking already run, respectively after eth0 was already detected and thus ifup@eth0.service triggeerd?
[08:55] <pitti> then these need to be restarted
[09:05] <Chipaca> pitti: perhaps
[09:06] <Chipaca> in which case we need to move firstboot way up :)
[09:07] <pitti> Chipaca: note that allow-hotplug gets triggered via udev rules, so it'll run fairly early after udev trigger
[09:07] <pitti> Chipaca: probably better to just restart ifup@ after you wrote the file
[09:08] <Chipaca> pitti: but we can't restart a service from inside a service
[09:08] <Chipaca> it deadlocks
[09:08] <pitti> Chipaca: you can, with --no-block
[09:09] <pitti> Chipaca: you can also do it more indirectly, with udevadm trigger --sysname-match=eth0
[09:09] <pitti> (or whatever the interface name is)
[09:09] <pitti> that pretends eth* was "re-hotplugged", and you don't need to know the precise mechanics how it's brought up
[09:14] <JamesTait> Good morning all; happy Friday, and happy Don’t Step On A Bee Day! 😃
[09:14] <ogra_> save the bees !!
[09:15] <ogra_> (and the bumblebees too)
[09:32] <seb128> ogra_, so, who is to nag about snappy update being busted?
[09:32] <seb128> Chipaca? sergiusens? mvo?
[09:33] <ogra_> seb128, sergiusens i think
[09:34] <Chipaca> who shouldn't be here today
[09:34] <Chipaca> as it's a national holiday for him
[09:36] <ogra_> Chipaca, wasnt that yesterday ?
[09:37] <Chipaca> ogra_: yes, but the president got bored or something
[09:37] <ogra_> or did he take a bridge holiday
[09:37] <ogra_> ah
[09:37] <Chipaca> declared it a bridge
[09:37]  * ogra_ gets ready for dentist ... back later ... 
[09:37] <Chipaca> glad she chose that, as the other button was "declare war"
[10:47] <sergiusens> ogra_: seb128 Chipaca I am here today, but I've been playing fix the image for a week now, time to pass it on to someone else in the team
[10:47] <sergiusens> Chipaca: it's not a bridge
[10:48] <Chipaca> sergiusens: my sources have lied to me!
[10:48]  * Chipaca has them all go on reddit and bash kittens
[10:52] <sergiusens> Chipaca: http://www.mininterior.gov.ar/tramitesyservicios/feriados.php
[10:52] <sergiusens> Chipaca: or en.ar#holiday@group.v.calendar.google.com)
[10:53]  * Chipaca tries to decide whether continuing to be wrong would be more o rless fun than being correct
[11:29] <ogra_> sergiusens, well, i have no clue how the partitioning is done ... but 63M is definitely not enough for three kernels and three initrds on x86/amd64
[11:30]  * ogra_ is happy to take over parts of the image indeed
[11:30] <ogra_> >(but thats u-d-f which is a black hole for me)
[11:34] <sergiusens> ogra_: 63M
[11:35] <sergiusens> ogra_: supposed to be 512M
[11:35] <sergiusens> ogra_: and I'm not sure what you are talking about
[11:35] <ogra_> hmm, df shows 63
[11:35] <sergiusens> ogra_: oh, right, blame lool
[11:35] <sergiusens> ogra_: why are there 3 kernels?
[11:35] <sergiusens> should only be 2
[11:36] <ogra_> sergiusens, amd64 core and personal fail snppy update with an out of space error when copying the kernel to /boot
[11:36] <ogra_> there is one in /boot from the rootfs still
[11:36] <ogra_> (which we should get rid of, but didnt yet apparently)
[11:36] <ogra_> so you have three kernels and initrds
[11:37] <sergiusens> ogra_: /boot is part of system-a/b
[11:37] <sergiusens> ogra_: /boot/u-boot, /boot/grub and /boot-efi are mounted for system-boot
[11:38] <sergiusens> ogra_: and I thought my MP did get rid of the extra kernels fwiw
[11:38] <ogra_> right, /boot/efi is 63M for me here
[11:38] <sergiusens> ogra_: right, it is 64M (give or take for alignment), blame lool ;-)
[11:38] <ogra_> i'm currentl ylooking at personbal ... might be that this doesnt have the MP yet
[11:39]  * ogra_ blames lool in absence
[11:39] <sergiusens> ogra_: well it's the one you merged ;-)
[11:39] <ogra_> sergiusens, seb128 only merged it yesterday for personal
[11:39] <sergiusens> ogra_: the first red in https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158
[11:39] <ogra_> since it had a bunch of issues i fixed in core first (quoting)
[11:39] <sergiusens> ogra_: but that does not come into play for system-boot at all
[11:40] <ogra_> right, only for /boot
[11:40]  * davmor2 blames that ogra_ bloke bound to be his fault somewhere along the lines
[11:40] <sergiusens> ogra_: yeah, your code review was terrible ;-) just proving how shell scripting can go ;-)
[11:40] <seb128> ogra_, sergiusens, ubuntu-core has the same issue, I download core 98 and did a "snappy update" before lunch and it failed the same way
[11:41] <ogra_> sergiusens, well, i fixed it at least :P
[11:41] <sergiusens> seb128: it was 512M before and I was told to lower it to 64, I don't mind making it 512 again
[11:41] <ogra_> yeah, lets do that again
[11:41] <seb128> smaller is better
[11:41] <ogra_> who knows what people come up with and add to their initrd on custom images :)
[11:41] <seb128> ideally personal would fit on a 8G stick
[11:42] <seb128> but otherwise I've no strong opinion
[11:42] <ogra_> 8G ?
[11:42] <ogra_> i would say 4 ;)
[11:42] <seb128> the personal image doesn't fit on a 8Gb stick
[11:42] <seb128> ogra_, even better
[11:42] <sergiusens> seb128: btw, I did your s/ubuntu-core/ubuntu-personal/ thing, but this will play in negatively with the oem snaps, you might need to roll your own due to snappy config ubuntu-core
[11:42] <seb128> but today it's 10Gb
[11:42] <ogra_> (without libreoffice and thunderbird though :) )
[11:42] <seb128> sergiusens, oh, ok
[11:43] <seb128> ogra_, 4 is a bit short with system-a/b for a full desktop
[11:43] <ogra_> seb128, currently the booted personal image uses 2.3G writable space ...
[11:43] <seb128> why is our image take 10Gb then?
[11:43] <ogra_> system-a|b dupplicates that
[11:43] <ogra_> and you want some wiggle room
[11:44] <seb128> right, but 2.3*2=4.6
[11:44] <seb128> + boot = 64M atm
[11:44] <seb128> + writable
[11:44] <ogra_> right, 6 should be fine ... and i think we can slim it down a bit still
[11:44] <seb128> we should be able to do e.g a 6G
[11:44] <seb128> well, before sergiusens merged his changed with the 10G size, I tried to build with the size specified to 8 and it failed for some reason
[11:45] <seb128> I never debugged by it wanted more that 8 though
[11:45] <ogra_> anyway, i would at least go with 128M for /boot
[11:45] <sergiusens> seb128: ogra_ I chose 10 just to get started, we can lower that as soon as you have the right package set stabilized a bit
[11:46] <seb128> sergiusens, well, when you picked 10 I tried 8 locally because that's what I had as usb  stick, but it failed for some reason
[11:46] <seb128> so it seemed it wanted > 8G
[11:46] <seb128> ogra_, right
[11:46] <ogra_> seb128, we were recently discussing making the writable part realyl tiny in the img and then just expand it to full disk on first boot
[11:46] <sergiusens> seb128: yeah, the min required size is enforced so people don't have the disk full issue when creating images
[11:47] <ogra_> that should make everyhting way more flexible
[11:47] <ogra_> (and give you a way snaller image)
[11:48] <sergiusens> seb128: https://code.launchpad.net/~sergiusens/snappy/rollYourOwnCorePersonal/+merge/264405
[11:52] <seb128> sergiusens, should that maybe be discussed on the list? I think it is useful, would it only to let people know about the change
[12:20]  * ogra_ grumbles about the anesthesia not wearing off today ... annoying
[12:35] <sergiusens> Chipaca: did you get a chance to review the u-d-f MP?
[12:38] <Chipaca> sergiusens: url?
[12:39] <sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/unmapErr/+merge/264250
[12:40] <Chipaca> yes, i had
[12:40] <Chipaca> and now i told launchpad about it and all
[12:40] <sergiusens> Chipaca: that makes things better :)
[13:17] <rsalveti> sergiusens: is that just to help exposing the error or actually fixing it?
[13:18] <rsalveti> ogra_: sergiusens: do we want to remove the duplicated kernel from stable still?
[13:21] <rsalveti> sergiusens: moved the meeting to tuesday since we had conflicts on monday
[13:24] <rsalveti> mterry: what do we need to change regarding tarmac to land the snapcraft branches?
[13:25] <mterry> rsalveti, sergiusens: add ppa:hardware-certification/public to our tarmac machine
[13:36] <ogra_> rsalveti, not sure, i wonder what the risk is
[13:36] <ogra_> (the change would just be two rm's indeed)
[13:37] <rsalveti> ogra_: if it's fine to not fix it now, it's also ok
[13:37] <rsalveti> but would the kernel always be there after we fix and update?
[13:37] <ogra_> it should be handled like a normal file by s-i
[13:37] <ogra_> so if it goes away in the image it should go away on disk
[13:38] <rsalveti> yeah
[13:40] <rsalveti> fgimenez: any other issue with the image?
[13:42] <rsalveti> fgimenez: https://bugs.launchpad.net/snappy/+bug/1473014 should be fixed with latest
[13:49] <rsalveti> hm, created latest kvm image, did control+c on qemu after it booted completely, trying to boot again but I can't login now
[13:49] <rsalveti> and ssh is not giving me the login prompt either
[13:50] <ogra_> lovely :/
[13:50] <rsalveti> and boot took longer as well
[13:50] <rsalveti> this is with 15.04/edge
[13:51] <sergiusens> mterry: rsalveti k
[13:51] <sergiusens> rsalveti: ogra_ it doesn't really matter to ship those kernels
[13:52] <ogra_> sergiusens, rsalveti, hmm, though i wonder if elopio's second fake upgrade issue could be related to a full vfat on the BBB
[13:53] <rsalveti> Jul 10 13:50:09 localhost login[656]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', User not known to the underlying authentication module
[13:53] <rsalveti> user ubuntu unknown
[13:53] <ogra_> ugh
[13:54] <sergiusens> ogra_: rsalveti fwiw https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/biggerPartition/+merge/264421
[13:54] <rsalveti> Jul 10 13:49:36 localhost systemd[1]: Failed to start Login Service.
[13:54] <rsalveti> that is why
[13:54] <ogra_> sergiusens, will that automatically adjust the other sizes ?
[13:55] <ogra_> rsalveti, yeah, but why :P
[13:55] <sergiusens> but that makes our 4GiB images look like 512MB(system-boot), 1Gib (system-a/b), 512MB (writable)
[13:55] <rsalveti> ogra_: my boot log http://paste.ubuntu.com/11856027/
[13:55] <sergiusens> ogra_: yes, it adapts everything else
[13:55] <ogra_> sergiusens, 128M would suffice i guess
[13:55] <sergiusens> ogra_: that's what people said about 64 ;-)
[13:56] <rsalveti> 512 is a bit too much, isn't it?
[13:56] <rsalveti> and why are we changing?
[13:56] <rsalveti> sorry, no context
[13:56] <sergiusens> ogra_: give me numbers!
[13:56] <sergiusens> rsalveti: because ogra_ said so :-P
[13:56] <ogra_> well, people were at least cleverer than bill gates then ... he said 640k is enough ;)
[13:56] <sergiusens> rsalveti: ogra_ fwiw, 512 is the recommended size to hold grub stuff from cjwatson
[13:56] <ogra_> rsalveti, rolling has an issue with upgrading on core and personal
[13:57] <ogra_> rsalveti, fails with ENOSPC on /boot
[13:58] <ogra_> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,808 - cc_growpart.py[DEBUG]: '/' FAILED: failed to resize: disk=/dev/sda, ptnum=3: Unexpected error while running command.
[13:58] <ogra_> Jul 10 13:48:24 localhost cloud-init[605]: Command: ['growpart', '--dry-run', '/dev/sda', '3']
[13:58] <ogra_> whats that ?
[13:58] <ogra_> rsalveti, smells to me like we run cloud-init in some werd mode
[13:58] <ogra_> *weird
[13:59] <rsalveti> yeah, no idea
[13:59] <rsalveti> Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service: main process exited, code=exited, status=1/FAILURE
[13:59] <rsalveti> Jul 10 13:48:21 localhost systemd[1]: Failed to start Notify bootloader that boot was successful.
[13:59] <rsalveti> Jul 10 13:48:21 localhost systemd[1]: Unit ubuntu-snappy.boot-ok.service entered failed state.
[13:59] <rsalveti> Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service failed.
[13:59] <rsalveti> wow, why?
[13:59] <ogra_> you dont have any network device
[13:59] <rsalveti> Jul 10 13:48:21 localhost snappy[554]: invalid package on system
[13:59] <sergiusens> rsalveti: what system is this?
[14:00] <rsalveti> sergiusens: 15.04/edge, created latest with kvm, booted, hit control+c, started again
[14:00] <rsalveti> and now can't even login anymore
[14:00] <sergiusens> rsalveti: invalid package on system means you have a package with a . in it when it's no supposed to
[14:00] <rsalveti> this is just the base system + webdm
[14:00] <rsalveti> didn't change anything, was my second boot
[14:00] <sergiusens> rsalveti: created just now?
[14:00] <rsalveti> sergiusens: yes
[14:00] <sergiusens> rsalveti: no update happened?
[14:00] <rsalveti> sergiusens: nops, was latest already
[14:01] <sergiusens> rsalveti: command run so I can run
[14:01] <ogra_> rsalveti, hmm, works fine here
[14:01] <ogra_> sudo ubuntu-device-flash core --channel edge -o snappy_core_x86.img --developer-mode 15.04
[14:01] <rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem generic-amd64 --install=webdm --enable-ssh --output ubuntu-15.04-snappy-amd64-generic.img
[14:01] <ogra_> boots even in seconds
[14:01] <rsalveti> got image 121
[14:01] <sergiusens> rsalveti: fwiw, you don't need to specify  --oem generic-amd64 ;-)
[14:01] <ogra_> yep, same here
[14:01] <ogra_> (imagenumber)
[14:02] <ogra_> let me try with installing webdm
[14:02] <rsalveti> sergiusens: I know, this is because I was creating the released images, and wanted to be explicit in my script
[14:02] <sergiusens> rsalveti: that's fine
[14:04] <ogra_> rsalveti, with webdm boots fine too
[14:06] <rsalveti> ogra_: right, it seems to be a fs corruption issue or something along that line
[14:06] <rsalveti> can't reproduce every time
[14:06] <fgimenez> rsalveti, no new issues on my side, the upgrade from 106 (kernel 3.19.0-21) to 122 (kernel 3.19.0-22) went fine on bbb http://paste.ubuntu.com/11855291/
[14:06] <ogra_> i use the udf with personal enabled ... 0.26-0ubuntu1
[14:07] <ogra_> do you use an older one ?
[14:07] <fgimenez> rsalveti, i've been hitting the space problem on rolling http://paste.ubuntu.com/11855475/
[14:07] <rsalveti> fgimenez: great
[14:07] <rsalveti> right
[14:07] <ogra_> aha, so it affects arm too
[14:08] <sergiusens> rsalveti: works fine here too
[14:08] <elopio> good morning
[14:09] <fgimenez> hi elopio
[14:09] <rsalveti> sergiusens: yup, as I said, I can't always reproduce it either
[14:09] <rsalveti> https://bugs.launchpad.net/snappy/+bug/1473465
[14:10] <ogra_> rsalveti, bah, seems it hit it as well now
[14:11] <rsalveti> ogra_: \o/
[14:13] <ogra_> rsalveti, bah, seems it hit it as well now
[14:13] <ogra_> bah
[14:13] <ogra_> EFOCUS
[14:13] <rsalveti> hahah
[14:13] <sergiusens> ogra_: rsalveti second boot? So if I reboot reboot reboot I eventually hit it?
[14:13] <rsalveti> sergiusens: complete first boot then control + c on your kvm console
[14:14] <rsalveti> then start it again
[14:14] <ogra_> sergiusens, my first boot was fine ... not sure it was the second ... but now i cant get in at all anymore
[14:14] <sergiusens> ogra_: rsalveti get in meaning log in?
[14:14] <ogra_> yes
[14:14] <sergiusens> ogra_: ssh or console?
[14:14] <ogra_> login incorrect on all consoles
[14:15] <ogra_> tty and serial in kvm
[14:15] <sergiusens> meh, I've rebooted 10 times already
[14:15] <ogra_> cloud-init suddenly seems to write a lot of files
[14:15] <ogra_> i dont think i have seen that before
[14:16] <sergiusens> ogra_: rsalveti mount the writable partition and run 'find [mountpath] -ls' and pastebin for me
[14:16] <sergiusens> ogra_: rsalveti the growpart will surely break things I guess
[14:16] <ogra_> yeah, i think we hit a stramge cloud-init mode
[14:17] <ogra_> rsalveti, what was the dir you made writable ?
[14:17] <rsalveti> ogra_: waagent
[14:17] <rsalveti> but that is just for azure
[14:17] <sergiusens> rsalveti: there is no waagent anymore
[14:17] <rsalveti> /var/lib/waagent
[14:17] <sergiusens> rsalveti: it's all in cloud-init now
[14:17] <rsalveti> sergiusens: right, but it still uses that dir
[14:17] <ogra_> ah, not /var/lib/cloud
[14:17] <sergiusens> the logic
[14:17] <ogra_> k
[14:17] <rsalveti> that was for cloud-init
[14:20] <rsalveti> sergiusens: http://paste.ubuntu.com/11856151/
[14:20] <ogra_> sergiusens, http://paste.ubuntu.com/11856150/
[14:21] <ogra_> hah ! i beat you by 1
[14:21] <rsalveti> not here :P
[14:21] <sergiusens> yeah, rsalveti's showed first here, but ogra ran it faster :-P
[14:22] <rsalveti> I'm uploading the image as well
[14:22] <rsalveti> that will take a few minutes
[14:23] <sergiusens> ogra_: rsalveti now "find [mountpath] -name 'package.yaml' -exec cat {} \; "
[14:23] <rsalveti> nothing
[14:23] <rsalveti> guess the syntax is wrong
[14:23] <ogra_> same
[14:23] <sergiusens> rsalveti: maybe :-P
[14:23] <sergiusens> mnt/system-data/apps/webdm/0.9/meta/package.yaml
[14:24] <ogra_> ogra@anubis:~/datengrab/images$ sudo find mnt/ -name 'package.yaml'
[14:24] <ogra_> mnt/system-data/apps/webdm/0.9/meta/package.yaml
[14:24] <ogra_> mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml
[14:24] <sergiusens> and mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml
[14:24] <sergiusens> ogra_: rsalveti
[14:24] <sergiusens> oh
[14:24] <sergiusens> I see
[14:24] <sergiusens> size 0!
[14:24] <sergiusens> ogra_: rsalveti it's empty!!!
[14:24] <rsalveti> yup, size 0
[14:25] <sergiusens> rsalveti: everything is empty (checks paste again)
[14:25] <sergiusens> rsalveti: ogra_ some process did something nasty
[14:25] <rsalveti> everything is empty
[14:25] <rsalveti> lol
[14:25] <rsalveti> fuck
[14:25] <rsalveti> lol
[14:25] <ogra_> yeah
[14:25] <ogra_> the prowpart thing from cloud-init i bet
[14:25] <sergiusens> we can blame cloud-init and that growpart
[14:25] <ogra_> *grow
[14:25] <sergiusens> it's a cloud-init-utils
[14:25] <rsalveti> we have a suicidal process around
[14:26] <rsalveti> not everything in the partition is 0 size
[14:27] <rsalveti> actually no
[14:28] <rsalveti> everything is 0, the stuff that is not 0 is because of my other boot
[14:28] <sergiusens> rsalveti: directories have sizes different than 0?
[14:28] <rsalveti> mostly logs
[14:28] <sergiusens> rsalveti: and boots
[14:28] <rsalveti> etc/dbus-1/system.d all 0 as well, which explains why systemd is complaining
[14:32] <sergiusens> rsalveti: well given that system-data is made out of copies from system-a which is partition 3  which is what growpart wants to play with, I don't think this is surprising
[14:33] <rsalveti> right, do we know why it decided to play with that partition?
[14:33] <rsalveti> and why didn't this affect first boot
[14:33] <rsalveti> and why it works sometimes?
[14:33] <rsalveti> :-)
[14:33] <sergiusens> rsalveti: why would growpart run anyways? that's cloud-init world
[14:36] <rsalveti> sergiusens: I ask you the same question :P
[14:36] <sergiusens> rsalveti: darn, I'm always hand picked for debugging :P
[14:36] <ogra_> i dont see all that cloud-init output when removing waagent from writable paths and emptying system-data
[14:37] <rsalveti> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,777 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices': ['/']}
[14:38] <rsalveti> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,809 - cc_resizefs.py[DEBUG]: resize_info: dev=/dev/sda3 mnt_point=/ path=/
[14:38] <rsalveti> growpart actually failed
[14:38] <ogra_> but it tried to run ...
[14:38] <rsalveti> resizing went fine
[14:38] <sergiusens> rsalveti: ogra_ we can probably be safe from this if we write a cfg in /etc/cloud/... where we remove growpart's '/' option
[14:38] <ogra_> failed perhps because it was mounted
[14:38] <rsalveti> but also something we shouldn't be running
[14:39] <ogra_> sergiusens, well
[14:39] <ogra_> sergiusens, how did it get ther ein the first place
[14:39] <rsalveti> we need to understand why this is even required
[14:39] <ogra_> yes
[14:39] <rsalveti> maybe utlemming can give us a hand here
[14:39] <ogra_> it wasnt on yesterdays image
[14:39] <ogra_> i booted that a bunch of times
[14:39] <sergiusens> ogra_: SRU ;-)
[14:39] <rsalveti> the waagent change I did was earlier in the week
[14:39] <rsalveti> right, unless cloud-init itself changed
[14:40] <rsalveti> but it works sometimes
[14:40] <sergiusens> rsalveti: I don't think is related to waagent
[14:40] <sergiusens> at all
[14:40] <rsalveti> yeah
[14:40] <sergiusens> completely orthogonal
[14:40] <rsalveti> that would only make a difference for azure
[14:40] <ogra_> rsalveti, clud-init didnt change in the iage
[14:40] <ogra_> *image
[14:41] <ogra_> according to the manifest
[14:41] <sergiusens> rsalveti: not only that, it would only make a difference if we didn't provide a seed which we do
[14:41] <sergiusens> ogra_: this might have been there for a few weeks and you guys seeing, I haven't seen it yet
[14:42] <ogra_> sergiusens, well, yesterday i definitely booted the same image several times
[14:42] <rsalveti> right, I believe it was always there
[14:42] <ogra_> now even a fresh image only works once
[14:42] <sergiusens> ogra_: rsalveti we should just add a config with growpart/mode: false
[14:43] <sergiusens> ogra_: rsalveti or in ubuntu-core-config -> touch /etc/growroot-disabled
[14:44] <sergiusens> or growpart/devices: "" in the config
[14:44] <sergiusens> default is '/'
[14:44] <rsalveti> yeah, that looks better
[14:44] <rsalveti> #   if the file /etc/growroot-disabled exists, then cloud-init will not grow
[14:44] <rsalveti> #   the root partition.  This is to allow a single file to disable both
[14:44] <rsalveti> #   cloud-initramfs-growroot and cloud-init's growroot support.
[14:44]  * ogra_ still doesnt feel comfortable not knowing where that came from
[14:44] <sergiusens> ogra_: it comes from cloud-init
[14:45]  * sergiusens is reading the sources
[14:45] <ogra_> sergiusens, i know where it comes from
[14:45] <ogra_> how could that sneak into our image
[14:45] <sergiusens> ogra_: then I don't understand "ogra_ still doesnt feel comfortable not knowing where that came from
[14:45] <sergiusens> lolz
[14:45] <ogra_> especially on a stable channel
[14:45] <ogra_> yeah, badly phrased :)
[14:46] <jdstrand> dholbach: hey, I think there is a problem on the documentation site
[14:46] <sergiusens> ogra_: well, it's super hard to diff packages
[14:46]  * ogra_ sets up a changelo diff script 
[14:46]  * sergiusens wants an all source build system
[14:46] <jdstrand> dholbach: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ doesn't seem to be talking about the correct thing
[14:46] <ogra_> naaah
[14:46] <sergiusens> ogra_: well, that does not give me the diff of the orig tarballs which is what I want
[14:46] <ogra_> sergiusens, i want to see if a new clud-init version silently landed in the rootfs
[14:47] <ogra_> (for example)
[14:47] <jdstrand> dholbach: it doesn't describe the FHS at all, but instead how updates are applied
[14:47] <sergiusens> ogra_: it didn't silently land, it was SRUd
[14:47] <ogra_> without any testing on snappy ?
[14:47] <jdstrand> dholbach: it used to be another document I think (I'm not sure)
[14:47] <rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] stages.py[DEBUG]: Running module growpart (<module 'cloudinit.config.cc_growpart' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py'>) with frequency always
[14:47] <rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x7fb5149843c8>)
[14:47] <rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] cc_growpart.py[DEBUG]: growpart disabled: mode=False
[14:47] <ogra_> i guess we need to add that to the SRU reqs
[14:47] <sergiusens> ogra_: not sure, and growroot might have always been there
[14:47] <rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] cc_resizefs.py[DEBUG]: Skipping module named resizefs, resizing disabled
[14:47] <rsalveti> on first boot
[14:47] <rsalveti> it didn't run
[14:47] <dholbach> jdstrand: I think that's an issue in https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst then
[14:47] <ogra_> sergiusens, but hasnt been enabled
[14:48] <rsalveti> also didn't run now during my second boot
[14:48] <rsalveti> ogra_: sergiusens: so it's not always running
[14:49] <sergiusens> dholbach: I thought we were not supposed to use trunk for the stable documentation
[14:49] <sergiusens> dholbach: but lp:snappy/15.04 /docs
[14:49] <dholbach> sergiusens, sorry, wrong branch
[14:49] <dholbach> sergiusens, I doubt the file has changed since then
[14:49] <ogra_> http://launchpadlibrarian.net/208620766/cloud-init_0.7.7~bzr1091-0ubuntu2_0.7.7~bzr1091-0ubuntu3.diff.gz
[14:49] <dholbach> https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst
[14:50] <dholbach> jdstrand: ^ sorry, wrong branch earlier
[14:50] <jdstrand> I just filed bug #1473478 for this
[14:50] <nothal> Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1473478>
[14:50] <rsalveti> sergiusens: ogra_: the interesting piece: http://paste.ubuntu.com/11856263/
[14:50] <dholbach> thanks jdstrand
[14:50] <rsalveti> there is already a config disabling it
[14:51] <rsalveti> now why did it run? nobody knows yet
[14:51] <sergiusens> rsalveti: ogra_ might be related to making /etc/cloud/cloud.cfg.d a writable path and a race there
[14:51] <rsalveti> hm, that's a writable space
[14:52] <rsalveti> right
[14:52] <rsalveti> the broken image http://people.canonical.com/~rsalveti/ubuntu-15.04-snappy-amd64-generic-broken.img.xz
[14:52] <rsalveti> sergiusens: if you want to take a look
[14:52] <sergiusens> although writable paths are computed before anything else
[14:53] <rsalveti> yup, initrd
[14:53] <sergiusens> rsalveti: the only way for writable to be setup is for it run from initrd
[14:53] <sergiusens> ogra_: which begs the question, was the SRUd kernel+new init tested with snappy ;-)
[14:54] <ogra_> sergiusens, why initrd ?
[14:54] <ogra_> nothing should have changed there
[14:54] <sergiusens> rsalveti: so the initial copy went bad, cloud-init ran with its "default" config as all those file were empty
[14:54] <sergiusens> that settles it
[14:55] <rsalveti> right, growroot running is just a consequence
[14:55] <sergiusens> so the component that copies with the 'transition' rule is doing something bad
[14:55] <rsalveti> but, having such an important config as part of a writable space is dangerous
[14:56] <rsalveti> not sure if the copy was broken
[14:56] <rsalveti> control + c, might be that the fs was just corrupted
[14:57] <sergiusens> control + c?
[14:57] <rsalveti> on kvm
[14:57] <rsalveti> if I call sudo reboot it always works
[14:57] <rsalveti> the bug I got was when aborting kvm with a running system
[14:57] <ogra_> rsalveti, could your wait-for-root change trigger any races in the transition copying ?
[14:58] <rsalveti> ogra_: don't think so
[14:58] <ogra_> the PPA diff is a joke https://launchpadlibrarian.net/209263590/initramfs-tools-ubuntu-core_0.7.7~ppa1_0.7.7~ppa2.diff.gz
[14:58] <rsalveti> how are we mounting the writable dir?
[14:58] <ogra_> i assume you didnt only quieten the output there, right ?
[14:58] <ogra_> rsalveti, systemd shoudl parse fstab
[14:58] <ogra_> (which we feed from initramfs )
[14:59] <rsalveti> ogra_: that was the second upload, since wait-for-root was printing the fs format
[14:59] <ogra_> rsalveti, right, thats what i mean ... PPA diffs are the moste useless thing
[14:59] <ogra_> *most
[14:59] <rsalveti> /dev/sda5 on /writable type ext4 (rw,relatime,discard,data=ordered)
[14:59] <ogra_> sounds fine
[14:59] <rsalveti> yeah
[15:00] <jdstrand> rsalveti: fyi, bug #1473478 - dholbach says it is an issues in the snappy docs. I think it is a critical issue for devs
[15:00] <nothal> Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <Snappy:New> <http://launchpad.net/bugs/1473478>
[15:00] <mattyw> hey folks, my snap is producing the following error when I run it - fork/exec /usr/bin/ssh: operation not permitted. Can't quite work out what I should be adding to the seccomp stuff, seems like I might not even be allowed?
[15:02] <mattyw> sergiusens, do you know the answer ^^ ?
[15:03] <sergiusens> mattyw: that's not seccomp, that's apparmor; dmesg|grep DEN
[15:05] <mattyw> sergiusens, any idea what should I be putting in apparmor?
[15:05] <sergiusens> jdstrand: I don't understand the 'no longer' part as we haven't been updating the docs in lp:snappy/15.04 for this to be consumed incorrectly
[15:06] <sergiusens> mattyw: you need to go deeper into the apparmor world, jdstrand can help, you can start out by looking at the one in webdm
[15:06] <jdstrand> sergiusens: there used to be a doc that had a table of /apps, /var/lib/apps, /home, etc that described all the FHS bits. that doc used to be at https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. What is in https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ now seems a totally different doc
[15:07] <sergiusens> jdstrand: right, I don't see how a document explaining how updates work are the culprit for this...
[15:08] <jdstrand> sergiusens: actually, can we recommend looking at the one in hello-dbus-fwk going forward instead? webdm is a huge exception with its policy and lack of seccomp
[15:08] <jdstrand> mattyw: ^
[15:08] <rsalveti> sergiusens: ogra_: so the image only breaks if you hit control + c after the first boot
[15:08] <sergiusens> jdstrand: sure, but mattyw wants to exec ssh and on second though, he may need to provide it in his snap instead
[15:08] <ogra_> hmpf
[15:08] <rsalveti> because the fs gets corrupted
[15:08] <ogra_> ext4 should still recover
[15:09] <sergiusens> rsalveti: oh, ctrl+c from the terminal running kvm you mean?
[15:09] <jdstrand> sergiusens: no, I get that. what I am saying is the hello-dbus-fwk has security-policy that is better for people to model their stuff on than webdm. that is all
[15:09] <rsalveti> sergiusens: yes
[15:09] <sergiusens> jdstrand: sure, I'll recommend that, but typing webdm is faster than hello-dbus-fwk :-P
[15:09] <jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/
[15:10] <jdstrand> sergiusens: yes, but I was just in an hour meeting talking to people about how their policy is far too lenient because they used webdm as a template :P
[15:10] <jdstrand> to be fair, the whole meeting wasn't on that
[15:11] <davidcalle> jdstrand, about https://bugs.launchpad.net/developer-ubuntu-com/+bug/1473478
[15:11] <jdstrand> sergiusens: re the docs site, I don't claim to know where the problem lies, I only know there is a problem
[15:11] <davidcalle> jdstrand, are you looking at the page in "live" or "draft" mode?
[15:12] <jdstrand> davidcalle: I just went to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. I am not logged in
[15:12] <jdstrand> I think the mapping is wrong
[15:12] <jdstrand> ie, the url is https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
[15:13] <davidcalle> jdstrand, ok, then the fix needs to happen here https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst (afair, the doc has barely changed over time)
[15:13] <jdstrand> but the title is 'Snappy Transactional System Updates'
[15:13] <jdstrand> ie, it is just not the correct subject
[15:13] <elopio> fgimenez: (amd64)ubuntu@localhost:~$ which dpkg-query
[15:13] <elopio> /usr/bin/dpkg-query
[15:13] <elopio> that's 15.04
[15:13] <elopio> (amd64)ubuntu@localhost:~$ which dpkg-query
[15:13] <elopio> (amd64)ubuntu@localhost:~$
[15:13] <jdstrand> davidcalle: why does system-updates.rst refer to filesystem-layout?
[15:13] <elopio> that's rolling.
[15:13] <jdstrand> those are different topics
[15:14] <fgimenez> elopio, yes, makes sense
[15:14] <davidcalle> jdstrand, that's also the only doc talking about the layout
[15:14] <jdstrand> davidcalle: well, here is further proof of what I am saying
[15:14] <jdstrand> davidcalle: 'system-updates.rst' refers to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ for more info
[15:14] <jdstrand> at the bottom
[15:14] <jdstrand> something went wrong
[15:15] <jdstrand> look in section 10
[15:16] <davidcalle> jdstrand, oh... ok. I don't think that's a doc regression, though, as I don't remember anything else about the fs. But yes, we need a proper fs doc.
[15:16] <davidcalle> (otp, brb)
[15:16] <jdstrand> davidcalle: I promise you it is a regression. I refer to that doc all the time
[15:17] <jdstrand> I refer to it in the security.md
[15:17] <jdstrand> precisely because it used to go into the FHS in detail
[15:17]  * jdstrand attempts a google cache to prove
[15:18] <sergiusens> jdstrand: the title and the .rst pointed to correlate to me; the paritioning thing came from a google doc afaik
[15:18] <jdstrand> but clearly, even system-updates.rst expects this to gbe a different document-- it is referencing it in rreferences
[15:19] <jdstrand> sergiusens: ok, then can someone put the partitioning bits back?
[15:19] <jdstrand> ie, update system-updates.rst
[15:20] <jdstrand> really, I don't care-- either https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ needs to get the info back or a new page needs to be written and everything needs to be updated to refer to it. the former is easier by far
[15:20] <jdstrand> google cache is already updated
[15:21] <sergiusens> jdstrand: https://docs.google.com/document/d/1NdBgQXfuJWBOYT-iceTgagavE2r44dUs822gfAM9Srw/edit
[15:21] <sergiusens> jdstrand: I think the doc huys just imported the wrong docs
[15:22] <jdstrand> davidcalle: ^
[15:22] <rsalveti> sergiusens: ogra_: I think it's the same fs corruption issue we had with touch
[15:22] <jdstrand> yes!
[15:22] <rsalveti> which made us change from data=ordered to data=journal
[15:22] <jdstrand> that is the page I was referring to
[15:22] <sergiusens> jdstrand: I updated the bug report
[15:23] <jdstrand> thanks
[15:23] <sergiusens> np
[15:23] <sergiusens> rsalveti: change it then ;-)
[15:23] <rsalveti> ogra_: sergiusens: I think we should probably do the same with snappy
[15:23] <rsalveti> right
[15:23]  * jdstrand notes that dpm said "Content now published on http://developer.ubuntu.com/snappy/filesystem-layout/" in a comment in that google doc :) I knew I wasn't crazy
[15:23] <ogra_> rsalveti, yeah
[15:24] <jdstrand> davidcalle: this is what it used to be: http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
[15:25] <jdstrand> davidcalle: web.archive.org had the new cache around June 10th
[15:25] <sergiusens> mterry: http://paste.ubuntu.com/11856443/
[15:26]  * mterry hugs sergiusens
[15:26] <ogra_> hmm why does sudo halt not kill my kvm
[15:29] <ogra_> rsalveti, hmm, so after halting the system properly on first boot it doesnt fall over anymore if i ctrl-c
[15:29] <jdstrand> beuno: what does "Move to waiting for updates queue" do in the store? is that the correct thing to do if they need to perform an update before acceptance?
[15:29] <ogra_> i cant get into the broken state
[15:29] <rsalveti> ogra_: that's because the writable data is already there
[15:29] <beuno> jdstrand, it's to dismisss something from the queue until they reply or upload
[15:30] <rsalveti> ogra_: it's a first boot thing as it's when the writable data gets copied over
[15:30] <beuno> so I think, yes
[15:30] <beuno> if you ask for more info
[15:30] <beuno> it does that as well
[15:30] <ogra_> rsalveti, yes, but i think we dont need to change the mount options but call sync a few times in the right place
[15:30] <beuno> so it's more to do that, without having to write something becuase you've already communiuated
[15:30] <jdstrand> beuno: great, thanks!
[15:31] <rsalveti> ogra_: journal is a safe option, and also good since we can avoid the same apparmor issues we had
[15:31] <rsalveti> with phone
[15:31] <ogra_> rsalveti, the initrd script mouonts /writable and copies the stuff ... but never unmounts or syncs
[15:31] <rsalveti> ogra_: because it stays there
[15:31] <rsalveti> for the bind mounts
[15:31] <ogra_> so the partition content stays in cache
[15:31] <ogra_> and then you ctrl-c
[15:32] <ogra_> so simply adding a sync call at the end of the copying to flush the cache on boot already should save us
[15:32] <rsalveti> right, a sync would already help, but I think journal is still a better option
[15:32] <rsalveti> to avoid general writable space corruption issues
[15:33] <ogra_> yes, we should do that, but will it be enough (will it write synced then  ?)
[15:34] <rsalveti> ogra_: I think so, it gets to the journal first
[15:34] <rsalveti> we can try
[15:34] <ogra_> i suspect even with the mount option set you wont flush the cache in time
[15:34] <rsalveti> let me upload the change
[15:34] <ogra_> +1
[15:41] <sergiusens> rsalveti: ogra_ just do both
[15:41] <rsalveti> sergiusens: don't think we need sync with journal
[15:41] <rsalveti> but yeah, already uploaded just with journal
[15:41] <rsalveti> will test once the new image is out
[15:41] <ogra_> right, lets test that first
[15:42] <ogra_> a sync after copy makes sense in any case though ... but if journal helps for this image thats enough
[15:42] <davidcalle> jdstrand, can you confirm that doc is still valid with latest 15.04?
[15:45] <rsalveti> sergiusens: don't know if you replied, but for https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 we still need a fix, right?
[15:45] <ogra_> some poeople did hit it the last two-three days in here
[15:46] <rsalveti> yeah, I'm expecting a lot of people getting that bug once we promote it to tools
[15:46] <ogra_> merged 3h ao :)
[15:46] <ogra_> *ago
[15:46] <rsalveti> ogra_: but don't know if that is the fix
[15:46] <rsalveti> that was my question to sergiusens
[15:46] <ogra_> ah
[15:49] <sergiusens> rsalveti: ogra_ there's an MP at the end there
[15:49] <jdstrand> davidcalle: system-updates.rst is invalid with 15.04. http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ is correct
[15:49] <rsalveti> sergiusens: my question is if the mp really fixes the issue
[15:49] <jdstrand> davidcalle: I think that http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ should be restored and system-updates.rst mapped to something else
[15:49] <sergiusens> I can release that, it is related to error encapsulation; this would expose the actual issue and fail gracefully
[15:49] <sergiusens> rsalveti: I don't know, I can't reproduce
[15:50] <rsalveti> sergiusens: right, let's release this and copy to tools-proposed then
[15:50] <sergiusens> rsalveti: I just followed the trace
[15:50] <rsalveti> then we can get people to test it a bit more
[15:50] <rsalveti> at least Chipaca was getting it all the time
[15:50] <jdstrand> davidcalle: but, please talk to the snappy guys-- sergiusens suggested system-updates.rst may be wrong to begin with
[15:50] <sergiusens> rsalveti: yeah, that's why I asked him to review, not sure if he tested though
[15:50] <elopio> fgimenez: can you run the integration suite? In the latest #103 it can't ssh, but it seems to work in #102.
[15:51] <jdstrand> looking at the bzr commits, james hunt added ./system-updates.rst on 2015-04-15
[15:51] <davidcalle> jdstrand, ok, I'm finishing restoring the old one (as Filesystem layout). I'll rename the existing one to "Transactional updates", then we'll see what to do with it.
[15:51] <jdstrand> it references https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
[15:51] <jdstrand> it is intended to be a difference doc
[15:51] <jdstrand> davidcalle: that sounds perfect
[15:52] <jdstrand> davidcalle: thank you so much! :)
[15:52] <sergiusens> +1
[15:52] <Chipaca> rsalveti: sergiusens: i got it a lot, but not all the time; after N tries i got an image
[15:52] <Chipaca> sergiusens: i did not get the error with your branch, but i didn't try 20 times either
[15:52] <Chipaca> sergiusens: should i?
[15:52]  * Chipaca can do a for
[15:52] <rsalveti> would be nice, yeah
[15:52] <sergiusens> Chipaca: maybe :-P at least we can see the underlying error
[15:53] <fgimenez> elopio, i'm having problems with udf, let me try
[15:53] <Chipaca> sure
[15:53] <sergiusens> and I can fix before releasing
[15:53] <sergiusens> fgimenez too if time permit
[15:53] <fgimenez> sergiusens, ok
[15:54] <sergiusens> Chipaca: btw, pb has a race wrt to start and finish calls
[15:54] <jdstrand> vmayoral|pc, lool: fyi, the https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ wrong content issue is https://bugs.launchpad.net/snappy/+bug/1473478. davidcalle is fixing it as we speak
[15:54] <sergiusens> Chipaca: we might need a package update
[15:54] <lool> jdstrand: ah great thanks
[15:55] <Chipaca> sergiusens: goget-ubuntu-touch is missing gettext in dependencies?
[15:55] <mattyw> sergiusens, sorry, me again, any idea what a aa_change_onexec failed with -1 error is telling me?
[15:55] <fgimenez> elopio, btw, finally in azure with --vm-size Medium works fine for me :)
[15:56] <elopio> fgimenez: good, once we get the tests running we can put the instructions in the readme
[16:00] <sergiusens> Chipaca: oh, I added that to my release branch...
[16:00] <rsalveti> ogra_: sergiusens: elopio: building new image for 1473465
[16:00] <sergiusens> rsalveti: ok for 0987654321 (?)
[16:00]  * sergiusens takes a chance with a bad joke
[16:01]  * ogra_ has a lottery bill with exactly that number !
[16:01] <sergiusens> mattyw: most likely that your appamor profile is bad
[16:01] <sergiusens> or points to a file that doesn't exist
[16:01] <davidcalle> jdstrand, sergiusens : so, https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ and https://developer.ubuntu.com/en/snappy/guides/transactional-updates/
[16:01] <jdstrand> davidcalle: looks great!
[16:02] <jdstrand> davidcalle: thanks! :)
[16:02] <sergiusens> wfm
[16:05] <sergiusens> Chipaca: scratch that, I didn't upload the 0.26 branch :-/
[16:05]  * Chipaca scratches
[16:05] <davidcalle> np :)
[16:07] <sergiusens> Chipaca: grab trunk again and it will all bzr bd/sbuild just fine
[16:07] <Chipaca> i'll take your word for it :)
[16:07] <fgimenez> sergiusens, building from trunk works for me
[16:09] <fgimenez> but 0.25-0ubuntu1, don't know if that's right
[16:09] <fgimenez> elopio, it cannot ssh with latest rolling/edge, trying now with revision -1
[16:14] <fgimenez> elopio, 102 works fine
[16:16] <fgimenez> sergiusens, in fact i'm not sure if it works http://paste.ubuntu.com/11856655/
[16:24] <fgimenez> elopio, i'm getting the same error on 102 too eventually, will catch up next monday o/
[16:29] <mattyw> sergiusens, sorry, me again, nothing I do gives me anything other than that error message. Could I send you the snap to see what's wrong?
[16:30] <mattyw> sergiusens, and I'm sure nothing has changed - and I used to get a different error
[16:30] <mterry> rsalveti, if you can also review https://code.launchpad.net/~mterry/snapcraft/local-plugins/+merge/264305 that would be swell
[16:31] <mattyw> sergiusens, or suggest someone else who might be able to help?
[16:33] <mattyw> sergiusens, ah, I might have it
[16:34] <sergiusens> mattyw: send me the snap if you want (or link to it)
[16:35] <mattyw> sergiusens, I finally found it :) sorry for pestering :)
[16:35] <sergiusens> no worries
[16:36] <sergiusens> Chipaca: given http://paste.ubuntu.com/11856655/ I now know that format is failing, just need a better message, going to craft an MP
[16:37] <mattyw> sergiusens, it would be nice to have some tooling to parse package.yaml and apparmor/ seccomp files to at least check they parse ok, the problem seems to be that snaps can get built with that stuff not being valid
[16:37] <ogra_> mattyw, we have tools for that in snappy build ...
[16:37] <sergiusens> mattyw: yeh, we are discussing adding json-schema support to all yamls with ricmm
[16:37] <ogra_> they are just temporary disabled
[16:38] <sergiusens> jdstrand: btw, we are considering adding json-schema support to all our yamls
[16:38] <mattyw> ogra_, sergiusens awesome news
[16:39] <sergiusens> mattyw: for now, run click-reviewer-tools against the built package
[16:39] <vmayoral|pc> jdstrand: that's great thanks!
[16:39] <mattyw> sergiusens, what ppa is that in?
[16:40] <mterry> sergiusens, it would be nice if we had proper jenkins instances for snappy branches.  Could build the debian package, could install packages as needed, etc
[16:40] <sergiusens> mterry: ppa:snappy-dev/tools
[16:40] <mterry> mattyw, ^
[16:40] <sergiusens> yeah
[16:40] <mterry> :)
[16:40] <mattyw> mterry, sergiusens thanks :)
[16:41] <sergiusens> mterry: maybe; as I said, this tarmac thing was meant for go and snap packages not having debian packaging
[16:41] <sergiusens> mterry: I don't like jenkins so I'll leave that to someone else
[16:42] <sergiusens> already had my fair share of grief with it when I was with the ci+qa team
[16:42] <mterry> sergiusens, ah hrm.  Do you have a preferred tool in the same problem space?
[17:00] <sergiusens> mterry: I don't think we have one for launchpad, at least a one size fits all solution
[17:00] <jdstrand> sergiusens: json-schema support? you mean, supporting json in the yaml?
[17:01] <sergiusens> jdstrand: http://www.yaml.org/spec/1.2/spec.html#id2803231
[17:02] <sergiusens> mterry: I would love to just use travis fwiw
[17:14] <sergiusens> rsalveti: Chipaca https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/ErrExec/+merge/264440
[17:15] <sergiusens> rsalveti: Chipaca from fgimenez' pastebin I guess the error he gets either comes from dmsetup clear or kpartx -ds, both related to unmapping
[17:15]  * Chipaca thinks it's nigh on beer o'clock
[17:15] <Chipaca> sergiusens: 100 runs didn't get me the error here :-(
[17:16] <sergiusens> Chipaca: did you reboot? /me thinks kernel got confused
[17:17] <Chipaca> sergiusens: yesterday to fix it? dmsetup clear'ing between tries got it working
[17:17] <Chipaca> losetup/dmsetup/partx thing
[17:19] <sergiusens> Chipaca: what order is the suggested order?
[17:20] <sergiusens> Chipaca: dmsetup clear, kpartx -ds and last losetup -d ?
[17:20] <Chipaca> sergiusens: i did no research on this. i did it backwards to that though.
[17:20] <Chipaca> i think
[17:20] <Chipaca> not sure :)
[17:21] <sergiusens> Chipaca: you should delete the mapping for a loop device before deleting the loop device though
[17:22] <sergiusens> Chipaca: shouldn't
[17:32] <sergiusens> rsalveti: new u-d-f building
[17:58]  * elopio goes home before getting trapped here by the rain.
[18:02] <rsalveti> sergiusens: cool
[18:02] <rsalveti> builders are busy it seems
[18:03] <rsalveti> just built for ppc
[18:21] <rsalveti> webdm failed to install: Get https://public.apps.ubuntu.com/anon/download/canonical/webdm.canonical/webdm.canonical_0.9_multi.snap: EOF
[18:21] <rsalveti> niiice
[18:21] <rsalveti> trying again
[18:22] <rsalveti> ogra_: interesting https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/32102
[18:23] <rsalveti> started 2 hours ago, still running
[18:37] <rsalveti> let's try yet another build
[19:01] <carif_> is this channel archived somewhere?
[19:16] <Letozaf_> higgins, someone asked me if you can open a terminal in Snappy personal desktop, can it be done ?
[19:16] <Letozaf_> hi not higgins :( sorry
[19:19] <sergiusens> Chipaca: btw, I don't see you on untappd!
[19:20] <sergiusens> rsalveti: https://launchpad.net/builders seems to be availability for amd64 for only
[19:21] <rsalveti> sergiusens: yeah, everything is currently stuck
[19:21] <rsalveti> image, package builds, etc
[19:22] <Letozaf_> no matter, found out by myself how to do it, thanks
[19:43] <elopio> a man came and brought the internet \o/
[19:45] <rsalveti> elopio: \o/
[19:45] <rsalveti> sergiusens: yeah, builds are busted
[19:45] <rsalveti> database outage
[19:45] <rsalveti> so yeah, guess no release for today =\
[19:55] <sergiusens> rsalveti: oh well
[19:56] <rsalveti> sergiusens: at least it's already beer o clock for you it seems :-)
[19:57] <sergiusens> rsalveti: yup :-)
[20:05] <ogra_> carif_, on irclogs.ubuntu.com
[20:05] <ogra_> rsalveti, hmm, looks like it built fine
[20:06] <rsalveti> ogra_: image is still building
[20:06] <ogra_> well, the log disagrees
[20:06] <rsalveti> colin said the buildds should be mostly fine now
[20:06] <rsalveti> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
[20:06] <rsalveti> needs building here
[20:06] <rsalveti> that other one was canceled
[20:06] <rsalveti> since it got stuck
[20:06] <ogra_> i dont see amd64
[20:07] <ogra_> did you run it with ARCHES= set ?
 boiko,robru: lots of buildd breakage at the moment due to a partial database outage today, need to analyse the whole lot and repair
[20:10] <ogra_> from #ubuntu-ci-eng
[20:10] <ogra_> seems to affect a lot of LP
[20:10] <rsalveti> yup, what I said a bit earlier
[20:10] <rsalveti> all broken
[20:10] <rsalveti> :-)
[20:23] <ogra_> rsalveti, hmm, so that also means we dont know yet if the fix works ?
[20:23] <rsalveti> ogra_: nops
[20:24] <ogra_> damn
[20:24] <rsalveti> let me see if system-image imported the amd64 build at least
[20:25] <ogra_> cdimage seems to have it at least
[20:26] <ogra_> yup, system-image seems to have updated amd64
[20:26] <ogra_> has a timestamp that matches the cdimage build
[20:27] <ogra_> hmm, but no package changes
[20:27] <ogra_> oh
[20:27] <ogra_> heh
[20:28] <ogra_> ogra@anubis:~/datengrab/images$ ./compare-snappy-manifests.sh 20150709 20150710
[20:28] <ogra_> Package changes between 20150709 and 20150710
[20:28] <ogra_> [20:28] <ogra_> initramfs-tools-ubuntu-core from 0.7.7~ppa2 to 0.7.7~ppa3
[20:28] <ogra_> there we go ...
[20:28] <ogra_> my script only checked armhf
[20:31]  * ogra_ twiddles thumbs waiting for udf
[20:37] <rsalveti> yeah, let me give it a try
[20:38] <rsalveti> worked fine the first time, let me try a few more
[20:39]  * ogra_ is at the second time
[20:40] <ogra_> yup
[20:40] <ogra_> no matter if i close the window or ctrl-c ... seems fine
[20:41] <ogra_> 5 times no corruption ...
[20:41]  * ogra_ builds a new image and does another 10 
[20:41] <ogra_> bah, i wish it could cahe webdm
[20:41] <ogra_> *cache
[20:45] <rsalveti> ogra_: yeah, seems fine here
[20:46] <ogra_> yup, 10 10x killed and stable
[20:46] <ogra_> -10
[20:46] <ogra_> :P
[20:47] <rsalveti> :-)
[20:47] <rsalveti> now to wait the armhf image
[20:48] <ogra_> well, the build seems done
[20:48] <rsalveti> waiting https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.27-0ubuntu1 to be promoted as well