[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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>[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<PHONE_NUMBER> (?)
[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


[07:55] <TLE> dpm: hey
[08:46] <dpm> hey TLE, sorry for the late reply
[10:48] <TLE> dpm: about the schedule
[10:49] <TLE> I didn't do any work no it yet, and it is not waiting for something, I'm just pressed for time
[10:53] <dpm> TLE, no worries, thanks for letting me know
[10:54] <dpm> In that case, I'll start working on it and send it to you for review if you've got time. Perhaps we can talk about it at the next translations call, if you can make it
[10:54] <dpm> In any case, how's life going, btw?
[10:54] <TLE> dpm: if you wouldn't mind that would be great
[10:55] <dpm> sure, no worries
[10:56] <TLE> you can pretty much use the natty one as a template: https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule except you need to adjust the locations to be as close to the: 2, 6, 12 and 22 week locations as we decided a while back
[10:56] <TLE> https://wiki.ubuntu.com/Translations/NattyLanguagePackReleaseSchedule
[10:56] <TLE> whops
[10:56] <TLE> https://wiki.ubuntu.com/Specs/LanguagePackUpdatesSchedule
[10:56] <TLE> there we go
[10:57] <TLE> it's ok, quite busy trying to wrap or or hand of assignments in a responsible manner on my current job and still searching for a new one
[11:37] <dpm> ok, cool, yeah, will use the template, adjusting the 1st langpack date
[17:55] <gotwig> hey
[17:55] <gotwig> thats the hardest release ever, for the German Ubuntu Translator Team :/ :(
[22:02] <Geochr> https://bugs.launchpad.net/launchpad/+bug/975970


[21:24] <fta> mdeslaur, hi, do you know if the last Quagga vulnerability impacts bgpd?
[21:35] <chrisccoulson> micahg - i'm not sure how busy you are, but feel free to do the tbird build3 upload if you have a few spare minutes :)
[21:35] <chrisccoulson> i'm on vacation today
[21:36] <micahg> chrisccoulson: ah, enjoy your day off I was wondering where you were, I guess I should've answered some questions during the -desktop meeting :)
[21:36] <micahg> chrisccoulson: I'll do it later tonight, thanks
[21:36] <chrisccoulson> oh, what questions were there?
[21:36] <micahg> chrisccoulson: just a mention of couchdb
[21:37] <chrisccoulson> oh, that should be fixed now :/
[21:38] <micahg> chrisccoulson: yeah, I think they were just saying some other work was blocked because of it before


[03:28] <nhaines> Anyone in the SoCal area in here who might be interested in collaborating on a "Building & Managing Kubernetes-based Machine Learning environments" type of event around Ubuntu in late September or early October?
[05:07] <lyorian> nhaines: I don't know anything about kubernetes
[07:41] <nhaines> lyorian: it's a cloud thingy.
[07:41] <lyorian> nhaines yes I know that braod but have never used it
[07:51] <lyorian> ugh it assumes you are using a laptop in the docs
[08:01] <nhaines> I assume you could use any microcomputer.
[08:10] <nhaines> Maybe even a macrocomputer,
[13:06] <pleia2> a lot of people don't have desktops anymore ;)
[13:07] <pleia2> what they mean is "personal computer"
[13:07] <pleia2> laptop, desktop, whatever
[13:07] <DonkeyHotei> in the outside world, a lot of people don't have laptops anymore, either
[13:08] <DonkeyHotei> people have been migrating to mobile devices and IoT
[13:09] <pleia2> yeah, I was referring to the kubernetes discussion, anyone who is going to deploy/work with kubernetes will have some kind of proper workstation
[17:21] <lyorian> pleia2: I actually most of the laptops I have can't run kvm and the one that does my mom bought and I have great trouble opening the case to put an ssd in
[22:14] <nhaines> Well, I will let them know that we're interested in collaborating.


[19:38] <LLStarks> other than intel, what's holding back edgers oneiric?
[19:40] <LLStarks> Depends: xserver-xorg-core (>=2:<IP_ADDRESS>1) but 2:1.10.1-1ubuntu1 is to be installed
[19:40] <LLStarks> i guess abi?
[19:44] <Sarvatt> you have something providing the old abi, virtualbox? newer nvidia drivers?
[19:44] <Sarvatt> or fglrx
[19:44] <Sarvatt> fglrx doesn't work with 1.11, its not even in the ppa so if its installed you'll get that
[19:45] <jcristau> nvidia doesn't work right either.
[19:45] <bjsnider> does now
[19:45] <jcristau> well didn't last i checked, yesterday or so.
[19:46] <Sarvatt> nah nvidia doesn't work right, jcristau is right :)
[19:46] <Sarvatt> check debian-x mailing list if you dont believe him lol
[19:46] <jcristau> we were up to 13 or 14 dupes i think
[19:46] <Sarvatt> extremely high cpu usage
[19:46] <jcristau> aaronp said it'll be fixed in the next beta
[19:46] <bjsnider> using 285.05.09?
[19:47] <Sarvatt> bjsnider: yeah
[19:47] <jcristau> using whatever's current
[19:47] <Sarvatt> bjsnider: affects some generation nvidia's a lot more than others
[19:47] <jcristau> i'm not using nvidia, i just suffer from the bug log.
[19:47] <jcristau> s/log/mail
[19:48] <bjsnider> well, that's the first one that allegedly supports 1.11
[19:49] <Sarvatt> there's a nvnews post about it
[19:49] <Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=166698
[19:50] <Sarvatt> lots of people using debian on 8xxx and 9xxx nvidias apparently :)
[19:51] <jcristau> mostly using testing, even, as the bug flood pretty much started when X 1.11 got there :)
[19:52] <bjsnider> bug's about trapezoid acceleration?
[19:53] <bjsnider> my cheap little card must support full trapezoid acceleration
[19:54] <Sarvatt> gt200+ does
[19:54] <bjsnider> nvidia-settings -q AccelerateTrapezoids
[19:54] <bjsnider> that prints stuff, so i guess i'm ok
[19:54] <bjsnider> i've got a fanless gt210
[20:08] <LLStarks> sarvatt, i think synaptics and intel are holding me back
[20:08] <LLStarks> natty edgers is fine
[20:08] <Sarvatt> i dont know where you are getting those from then, another ppa active?
[20:09] <Sarvatt> LLStarks: btw if you use unity it doesn't work with xserver 1.11 in edgers
[20:09] <LLStarks> i'm mint
[20:09] <LLStarks> so don't care about unity
[20:10] <Sarvatt> there's an oneiric based mint?
[20:11] <LLStarks> no
[20:11] <Sarvatt> so dont use oneiric edgers
[20:11] <Sarvatt> it relies on other things in oneiric that arent in the ppa
[20:11] <LLStarks> ah ok.
[20:20] <LLStarks> does synaptics-dkms multitouch work with natty?
[20:22] <Sarvatt> was it made for natty wherever you got it?
[20:23] <Sarvatt> imagine it's probably already in the natty kernels if it was only built for earlier ones, no clue if mint uses ubuntu kernels
[20:24] <Sarvatt> i dont even know what it is so probably shouldn't be responding :)