[00:20] <mup> PR snapd#1811 closed: interfaces/builtin: usb serial-port support via udev <Blocked> <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1811>
[01:43] <mouloud> hello  , how can i know what are the exact parts my snap will need !
[02:41] <liuxg> does anyone know how to find out whether my bluetooth on my raspberry pi is enabled or not? I want to make use of the bluetooth to find sth.
[02:45] <OerHeks> rfkill list all # should tell you
[05:26] <pitti> ogra_: hm, I cannot reproduce this with dnsmasq as server (just followed up to the bug); maybe you can attach your dhcpd config to the bug? can you reproduce this with a VM/container as well, or only with your device?
[06:22] <mup> PR snapd#1839 closed: interface: network_manager: enable resolvconf <Created by tonyespy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1839>
[07:00] <dholbach> hey hey
[07:07] <didrocks> good morning dholbach!
[07:08] <dholbach> salut didrocks
[07:08] <dholbach> good to see you're back again! :)
[07:08] <didrocks> thanks! :-) been a long time with your holidays starting a week before mine! :)
[07:09] <dholbach> yes :)
[07:21] <trijntje> Hi all, any devs around that know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930
[07:21] <mup> Bug #1609930: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
[08:13] <mvo> ogra_: hey, did you write the images for the pi2 that had the corruption problems with "dd conv=sparse" ?
[08:15] <mwhudson> morning
[08:16] <mwhudson> mvo, ogra_: any last minute console-conf / RTM panics?
[08:17] <mwhudson> i have on my machine here a UI that lets you plug in ESSID / password for wlan but i'm not proposing trying to get that into RTM
[08:20] <mvo> mwhudson: I had some strange error from the network on the pi2, that console-conf could not connect to the users api endpoint of the store, however I have not investigated further, as the pi2 as more (and bigger) problems currently
[08:21] <mwhudson> mvo: uh, hm
[08:44] <Kaleo> mvo, hey you had a failure in https://github.com/snapcore/snapd/pull/1845  TestSignBuildMissingKey.pN58_github_com_snapcore_snapd_cmd_snap_test.SnapSignBuildSuite
[08:44] <mup> PR snapd#1845: tests: use the real model assertion when creating the core test image <Created by mvo5> <https://github.com/snapcore/snapd/pull/1845>
[08:45] <Kaleo> mvo, I suppose it was unrelated to your PR, as I'm hitting the same issue locally with another PR
[08:45] <Kaleo> mvo, how did you get rid of it? :)
[08:47] <mvo> Kaleo: we noticed some minutes ago and we will debug/fix, just ignore until then, should be quick
[08:47] <Kaleo> mvo, sweet
[09:02] <ogra_> mvo, with and without
[09:04] <ogra_> mwhudson, err, why do you hold that ssid stuff back ? just to land it right after rtm ? (we will need it in any case)
[09:04] <mwhudson> ogra_: just wanting to avoid last minute breakage
[09:05] <ogra_> well, that means no dragonboard image then (only wlan)
[09:05] <mwhudson> ogra_: would you like an image to test?
[09:06] <mwhudson> well core snap
[09:07] <ogra_> we dont have a gadget for the dragon yet either ... but sure ... having something ready to test might be good once i got the gadget ...
[09:07] <ogra_> the vfat corruption klind of held us up
[09:07] <ogra_> so i didnt get to dragon yet
[09:10] <mwhudson> shipping is hard :(
[09:23] <mwhudson> bah, just missed a publisher run :(
[09:33] <mvo> ogra_: fwiw, I put some info into the fs corruption bug and a tiny reproducer
[09:34] <ogra_> ah, awesome
[09:36] <ogra_> well, i'm not sure it is mtools ... afauik for a vfat you also need to align the partition to the block size the vfat has ... i.e. if the vfat has 512 byte blocks, the partition nees to start and end on a pyhsical point thats divisible by 512 bytes
[09:36] <ogra_> i havent checvked that if we do that
[09:46] <mvo> ogra_: I pushed a potential fix to my branch
[09:47] <mvo> ogra_: check the LP page, I will play with the new image now, but its clear that mtools causes havoc, the fs is already corrupted when it finishes
[10:05] <mwhudson> ogra_: https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot <- latest core snaps there have wifi ui
[10:05] <mwhudson> in console-conf
[10:05] <mwhudson> (packages in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial)
[10:05] <ogra_> awesome, thanks ... will test that once i got to roll a new image
[10:06] <mwhudson> ogra_: np, hope it works, i haven't tested it at all! (the config it produces looks sane but that's as far as i can get)
[10:06] <mwhudson> qemu seems not to emulate any wlan interfaces
[10:06] <ogra_> yeah ... i think kvm allows to attach host wlan devices though
[10:12] <ogra_> mvo, afaik we have working mtools code in debian-cd somewhere
[10:12]  * ogra_ remembers that we used to run into similar probs back in the arm team days
[10:12] <mvo> ogra_: working as in not-corrupting?
[10:12] <ogra_> yes
[10:12] <mvo> ogra_: its interessting, it seems to be subdir releated or recursive copy
[10:13] <mvo> ogra_: my reproducer is fine when not using subdirs but I didn't want to sink too much time into finding workarounds
[10:14] <ogra_> how about if you do the recursion yourself in a shell loop ?
[10:14] <ogra_> and copy file by file
[10:14]  * ogra_ found the old code ... http://paste.ubuntu.com/23136465/
[10:14] <mvo> ogra_: that might work
[10:15] <ogra_> mkdosfs ... vs mkfs.vfat
[10:15] <mvo> ogra_: no subdirs no recursive (-s) in that script, I would bet this works fine
[10:16] <ogra_> yes, but we had to do the 512byte alignment ...
[10:16] <ogra_> dd if=/dev/zero of="$IMAGE" bs=512 count=0 seek="$IMG_SIZE_BLOCKS" >/dev/null 2>&1
[10:17] <ogra_> and
[10:17] <ogra_> VATSTART=$(parted $IMAGE unit B print|grep "^ 1"|awk '{print $2}')
[10:17] <ogra_> VATSIZE=$(LANG=C fdisk -l ${IMAGE} 2>/dev/null|grep W95 |awk '{print $5}')
[10:17] <ogra_> though that was using CHS with sfdisk
[10:17] <trijntje> Hi all, does anyone know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930
[10:17] <mup> Bug #1609930: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
[10:19] <mwhudson> ogra_: i am horrified to learn that this sort of thing is still a problem in 2016 :(
[10:19] <ogra_> haha
[10:20] <mwhudson> ogra_: at least you don't have to deal with the buggy FAT parser in omap3 (?) ROMs?
[10:20] <ogra_> yeah
[10:25] <mvo> ogra_: hm, no luck with recursion either
[10:27] <ogra_> IMAGE_SIZE=$((134217728/512))
[10:27] <ogra_> mkdosfs -F 32 -C $IMAGE.vfat $IMAGE_SIZE
[10:27] <ogra_> mvo, ^^^ no fsck errors for me with that ^^^
[10:28] <mvo> ogra_: oh?
[10:28] <ogra_> how the heck do i verify it now ... seems i cant loop mount it
[10:30] <mvo> ogra_: https://pastebin.ubuntu.com/23136501/ I still get that
[10:30] <mvo> ogra_: I mean, I still get fsck errors wit hthat
[10:30] <mvo> ogra_: or am I misunderstanding what you suggested?
[10:30] <ogra_> i'm suggesting to replace line 7
[10:31] <ogra_> mkdosfs -F 32 -C $IMAGE.vfat $((134217728/512))
[10:31] <ogra_> try that instead
[10:31] <mvo> ogra_: aha, mkdosfs
[10:32] <mvo> ogra_: like this https://pastebin.ubuntu.com/23136505/ ?
[10:32] <ogra_> well, you want the dd
[10:33] <ogra_> oh, or not
[10:33] <ogra_> -C might be enough actually
[10:34] <mvo> ogra_: I get the same corruption error with the pastebin script
[10:34] <ogra_> weird, i dont
[10:36] <ogra_> bah ...
[10:37] <ogra_> actually naming the image corrently helps :P
[10:37] <ogra_> *correctly
[10:39] <mvo> ogra_: oh, fun, it seems racy, I don't get it all the time
[10:40] <ogra_> heh
[10:41] <ogra_> mcopy has a-b option ...
[10:41] <Kaleo> fgimenez, you uploaded test snaps to the store for spread tests. Is that a typical thing to do? can I just upload one myself for my own tests?
[10:41] <ogra_> b
[10:41] <ogra_> Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy
[10:41] <ogra_> hmm, doesnt help either
[10:42] <Kaleo> morphis, I believe I fixed everything you noted in https://github.com/snapcore/snapd/pull/1775
[10:42] <mup> PR snapd#1775: interfaces: add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
[10:43] <Kaleo> morphis, I added a spread test but it depends on a snap that is pending review for publication in the store
[10:43] <ogra_> mvo, how about using mmd to create dir tree on the target and then iuse mcopy per file
[10:43] <Kaleo> morphis, can you check that everything is to your liking?
[10:43] <morphis> Kaleo: will have a look, thanks!
[10:43] <Kaleo> :)
[10:46] <fgimenez> Kaleo, hey :) yes, we have a bunch of test snaps uploaded to the store that are used by the snapd spread suite, previously we used snaps currently there (hello-world for instance) but we needed to control the state of these snaps in order to make proper assertions and have reliable results
[10:47] <mvo> ogra_: https://pastebin.ubuntu.com/23136531/ works 1/2 the time
[10:47] <fgimenez> Kaleo, these test snaps are owned by the canonical shared account, so that we don't get locked on a specific user
[10:47] <ogra_> mvo, well, then we just run it twice :P
[10:48] <mvo> *cough*
[10:48]  * mvo lunch
[10:49] <Kaleo> fgimenez, oh good, who can upload with that account?
[10:51] <ogra_> mvo, hmmm do you call "mdir /" in there ?
[10:52] <ogra_> err
[10:52] <ogra_> mmd / i mean
[10:56] <fgimenez> Kaleo, mvo can help you, and thanks for the test! :) looks great
[10:56] <Kaleo> fgimenez, :)
[10:57] <Kaleo> mvo, I would like to upload a test snap to the store
[10:57] <Kaleo> test-snapd-thumbnailer-consumer
[10:58] <Kaleo> mvo, http://people.canonical.com/~kaleo/test-snapd-thumbnailer-consumer_1.0_amd64.snap
[10:58] <Kaleo> mvo, generated from https://github.com/snapcore/snapd/pull/1775
[10:58] <mup> PR snapd#1775: interfaces: add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
[11:15] <mvo> Kaleo: did you upload this already under your account? if so we need to talk to nessita. you will need to delete it from your account and I can then upload it to the shared account
[11:20] <mup> PR snapd#1847 opened: many: discard preserved namespace after removing snap <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
[11:22] <Son_Goku> morning
[11:29] <ogra_> mvo, heh... thats what oi call pragmatic :) ... back to loop mounting
[11:29] <ogra_> s/oi/i/
[12:07] <jgdx> getting a build failure, missing a header file that builds fine without snapcraft. The dep is in the build-packages section.
[12:09] <jgdx> usr/include is missing in stage/. Wut
[12:11] <davidcalle> stub, hi, can you tell me a bit more about the magic names for license files? Is there somewhere (I guess no doc yet, so in code form maybe) where these are referenced?
[12:11] <stub> davidcalle: The magic names for license files are mentioned nowhere
[12:12] <stub> davidcalle: We used to have a way of referencing the license (using license: in snapcraft.yaml). Now we don't.
[12:13] <davidcalle> stub: ok, I'll let someone invested in re-adding the feature reply then.
[12:33] <ogra_> pitti, so looking at the leases file excerpt (attached to the bug), the uid stuff looks pretty inconsistent ...
[12:33] <ogra_> what creates that uid string ? networkd ?
[12:41] <pitti> ogra_: yes, that's a "DUID" (https://tools.ietf.org/html/rfc3315#section-9)
[12:42] <pitti> ogra_: by default it's generated from /etc/machine-id
[12:42] <ogra_> well, the non netplan images do not send it
[12:42] <pitti> right, isc-dhcp sends the  hostname
[12:42] <ogra_> see the top of the leases excerpt ...
[12:42] <pitti> we can also set ClientIdentifier=mac
[12:43] <pitti> (this is what isc-dhcp does, I suppose)
[12:43] <ogra_> we should probably do that then
[12:43] <pitti> ogra_: the question is, why does your /etc/machine-id change?
[12:43] <ogra_> hmm
[12:45] <ogra_> i wouldnt know anything that explicitly deletes it
[12:45] <ogra_> in our boot process
[12:45] <Kaleo> mvo, I had uploaded it but deleted it right away
[12:46] <pitti> ogra_: can you compare it between two boots, when the IP changes?
[12:46] <ogra_> sure
[12:47] <pitti> ogra_: i. e. I'm not too fussed about setting ClientIdentifier=mac, but /etc/machine-id changing sounds bad for many other reasons
[12:47] <ogra_> definitely ...
[12:47] <ogra_> it normally doesnt change .... but perhaps something in the way we now create images using ubuntu-image makes do so
[12:47] <Kaleo> pitti, is autopkgtest compatible with snaps?
[12:50] <pitti> ogra_: could be that /etc/machine-id is not writable or not a persistent file at all (then a random one is generated on boot and bind-mounted)
[12:50] <ogra_> it is writeable and our handling of writable files hasnt changed
[12:51] <mvo> Kaleo: yeah, now we need nessita, she will need to delte it from your account in the db so that I can reupload it, the name is now claimed :)
[12:51] <pitti> Kaleo: no, ATM it only knows about dsc and click; until the last CDO sprint at least there was no test specification for snaps
[12:51] <mvo> Kaleo: we will also need to change the hash, but unsquash/resquash is hopefully enough for this
[12:52] <nessita> mvo, hi! I'm here
[12:52] <nessita> what snap?
[12:52] <Kaleo> nessita, can you delete test-snapd-thumbnailer-consumer ?
[12:52] <Kaleo> nessita, from my account fboucault
[12:53] <nessita> Kaleo, one sec
[12:56] <morphis> niemeyer: ping
[12:58] <niemeyer> morphis: Heya
[12:58] <morphis> niemeyer: hope you had a good weekend :-)
[13:00] <zyga> morphis: hey
[13:03] <tvoss> mvo: hey there, any thoughts on my comment in https://github.com/snapcore/snapd/pull/1785
[13:03] <mup> PR snapd#1785: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
[13:07] <morphis> zyga: hey!
[13:07] <morphis> niemeyer: any reason why the hidraw and udisks2 interface PRs are not merged yet?
[13:07] <niemeyer> morphis: Yeah, it was good, thanks
[13:08] <niemeyer> morphis: hidraw we probably just need to rename it, udisks2 I didn't manage to get to it
[13:08] <niemeyer> morphis: Let's speak after the standup please
[13:08] <morphis> niemeyer: ok
[13:09] <nessita> Kaleo, do you have a link t your package? I can't find it
[13:09] <zyga> morphis: did you guys do the /media mount propagation change yet?
[13:10] <morphis> zyga: no, jdstrand and tyhicks are working on that
[13:10] <morphis> zyga: the patch ssweeny had didn't work so we followed up with jdstrand and tyhicks to get a solution in time for RTM
[13:11] <zyga> morphis: they are off today
[13:11] <zyga> morphis: and RTPM is today, right?
[13:11] <morphis> zyga: plan was actually ( ssweeny correct me if I am wrong) that a patch is ready on tuedsay
[13:11] <morphis> zyga: or better said, we provide a fix for this after RTM
[13:11] <Kaleo> nessita, I deleted it from the store's interface
[13:12] <zyga> morphis: I see, ok
[13:12] <Kaleo> nessita, it was at https://myapps.developer.ubuntu.com/dev/click-apps/5861/
[13:12] <nessita> Kaleo, so that's enough
[13:12] <Kaleo> nessita, oh ok
[13:12] <Kaleo> mvo, ^
[13:12] <nessita> Kaleo, is gone :-)
[13:13] <Kaleo> :)
[13:27] <mvo> Kaleo_: you should have mail
[13:28] <Kaleo_> mvo, I do :)
[13:28] <Kaleo_> mvo, what's the next step?
[13:32] <mvo> Kaleo_: in a meeting right now, lets talk in ~15min
[13:33] <Kaleo_> k
[13:41] <mvo> pitti: it looks like the latest images have no entries in /etc/resolv.conf for the nameserver (at least in kvm) with netplan, a second dhclient eth0 fixes it. is that something known? or can I do anything to debug this?
[13:43] <zyga> morphis: hey, niemeyer asked me to ensure that udisks2 gets merged only if it makes sense (snap-confine makes it really work as expected)
[13:44] <Kaleo_> pitti, thanks
[13:44] <morphis> zyga: ok, for that we miss the patch jdstrand and tyhicks are working on
[13:48] <pitti> mvo: not known, but confirmed in a container
[13:50] <pitti> mvo: is that actually breaking anything?
[13:51] <zyga> morphis: do you know if this will be ready tomorrow?
[13:51] <zyga> morphis: I think gustavo would rather not merge the interface before we merge this change
[13:51] <pitti> mvo: oh -- do you have libnss-resolve installed? I suppose not
[13:52] <morphis> zyga: https://paste.ubuntu.com/23137062/ is what I got from ssweeny, jdstrand and tyhicks
[13:53] <pitti> mvo: it's in ubuntu-standard, but maybe that isn't installed in snappy images; where would be the place to seed it?
[13:53] <mup> PR snapd#1848 opened: snap: ensure that plug and slot names are unique <Created by zyga> <https://github.com/snapcore/snapd/pull/1848>
[13:54] <ogra_> pitti, we dont even seed ubuntu-minimal ;)
[13:54] <ogra_> pitti, livecd-rootfs in the image PPA is the place for adding a package
[13:54] <ogra_> pitti, but why not just make it a dependency of nplan if it needs it
[13:54] <pitti> so that, or making it a dependency of netplan
[13:55] <pitti> well, it's not conceptually a netplan thing
[13:55] <pitti> would be the same with ifupdown or NM, we changed the resolver a while ago
[13:55] <ogra_> ogra@anubis:~/datengrab/devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5+mvo1_amd64.snap --devmode --force-dangerous
[13:55] <ogra_> [sudo] Passwort für ogra:
[13:55] <ogra_> error: unknown flag `force-dangerous'
[13:55] <ogra_> GRRR
[13:55] <ogra_> snapd ! stop changing every day !
[13:56] <mvo> ogra_: today just use "--dangerous"
[13:57] <ogra_> mvo, well --devmode is enough
[13:57] <mvo> ogra_: tomorrow it will "--might-exlode"
[13:57] <ogra_> haha
[13:57] <mvo> ogra_: aha, yeah, devmode adds it implicitely
[13:57] <ogra_> yep
[13:57] <mvo> pitti: thats fine, I can add it to livecdrotootffs
[13:57] <ogra_> ffs ? heh
[13:57]  * ogra_ notes mvo had a clown for breakfast :D
[13:58] <popey> pbek: did you know qownnotes in the store doesn't launch?
[13:58] <popey> pbek: alan@gort:~$ /snap/bin/qownnotes
[13:58] <popey> /snap/qownnotes/149/bin/desktop-launch: line 144: /home/alan/usr/bin/QOwnNotes: No such file or directory
[13:58] <pitti> mvo: still thinking where to put it -- container images have the same issue
[13:59] <pitti> (containers with netplan, I mean -- ifupdown calls resolvconf by itself)
[13:59] <mvo> pitti: I will add it manually for now to unblock us
[13:59] <popey> pbek: running it manually works, like this:- $ /snap/qownnotes/149/bin/desktop-launch /snap/qownnotes/149/usr/bin/QOwnNotes
[14:00] <pitti> mvo: ok; that should work, still doesn't feel completely right
[14:00] <ogra_> oh man ...
[14:00] <mvo> ogra_: one thing for classic, without ubuntu we have no password for the local sudo user anymore  so our sudo classic env needs a nopasswd
[14:00] <mvo> pitti: ok, once you have a different solution, just let me know
[14:00]  * ogra_ broke with his rule to never post political or religious statements on social media ... i should have known what happens :/
[14:01] <pitti> ogra_: Je suis McPomm?
[14:01] <ogra_> pitti, yeah
[14:01] <ogra_> mvo, did you see my PR for classic-snap ?
[14:02] <ogra_> (should perhaps be a bind-mount though ... but cp felt safer that moment)
[14:02] <mvo> ogra_: no, looking now
[14:03] <ogra_> :)
[14:03] <ogra_> fixes sudo
[14:03] <mvo> ogra_: does it? and its in the store already?
[14:03] <ogra_> yes
[14:03] <ogra_> happy to revert if you want to bind mount instead though
[14:03] <mvo> ogra_: hm, dosn't for me then :/
[14:03] <mvo> ogra_: no, copy is fine
[14:04] <ogra_> the issue is that the console-conf user isnt in the extrausers db
[14:04] <mvo> ogra_: and I'm not in the sudo group
[14:04] <ogra_> thats fine
[14:04] <ogra_> there should be a sudoers.d snippet for the user
[14:05] <mvo> ogra_: right, not in classic
[14:05] <ogra_> we cant change the sudo group since it needs to be in the readonly /etc/group
[14:05] <ogra_> oh, then we probably also need to copy the snippet
[14:05] <mvo> ogra_: yeah
[14:05] <niemeyer> morphis, zyga: To be clear, I'd like to hold the interface if it _only_ makes any sense once the snap-confine change goes in
[14:05] <ogra_> funny, why did that work for me
[14:05] <mvo> ogra_: I have no idea :)
[14:06] <ogra_> hmm, wasnt cyphermox' cloud-init stuff merged into u-i ? ... i still see the cloud-init mess on boot
[14:06] <niemeyer> morphis, zyga: Because snap-confine is in that tricky place right now where we have several non-trivial changes in progress, and I can't quite see which them will make it into RTM
[14:06] <zyga> niemeyer: I think that is the case today, morphis what do you think?
[14:06] <niemeyer> Having an interface that doesn't work at all for its intended purpose on RTM won't be very helpful
[14:13] <ogra_> pitti, so you are right, i get a new machine-id for whatever reason
[14:14] <ogra_> (sadly a reboot takes over 10min thanks to cloud-init on the pi currently ... no fun to test/debug)
[14:17] <ogra_> mvo, fix for u-i looks good ... third reboot and my image is still fine
[14:18] <mvo> ogra_: yay
[14:18]  * ogra_ shakes head
[14:18] <ogra_> [   47.485605] cloud-init[2662]: 2016-09-05 14:00:33,698 - util.py[WARNING]: did not find either path /sys/class/dmi/id or dmidecode command
[14:19] <ogra_> that was fixed in all distro tool using dmidecode like 5 years ago for arm ...
[14:19] <ogra_> i wish c-i would make use of existing tools, that would really save having to fix things over and over
[14:19] <ogra_> s/tool/tools/
[14:22] <mvo> ogra_: you will like the most recent livecd-rootfs upload ;)
[14:22]  * ogra_ checks
[14:22]  * ogra_ hugs mvo wildly 
[14:24] <ogra_> mvo, so that ubuntu-core -> core rename ... did i understand niemeyer correctly that only the handling in snapd is needed for RTM and we'll do the actual switch later ?
[14:24] <ogra_> also, what happens with the actual product name for the images
[14:24] <mvo> ogra_: this is still under investigation, maybe nothing for rtm because its too risky
[14:24] <ogra_> (i.e. the download area on cdimage)
[14:25] <ogra_> iirc slangasek and sabdfl both agreed the product name should be kept for the actual img files (especially in the light that we renamed ubuntu-core to ubuntu-base exactly for this)
[14:29] <ogra_> (renamed -> the old core tarballs that is)
[14:29]  * ogra_ will just wait til the investigation is done then :)
[14:29] <ogra_> hmm, the last snapd build in the PPA failed again on arm64 ...
[14:30] <mvo> ogra_: I upload a fix for classic with the sudoers.d now (unless you are already on it)
[14:30] <ogra_> nope, still poking around on the pi2 atm ... so many bugs :/
[14:31] <ogra_> ARGH !
[14:31] <ogra_> ogra@localhost:~$ sudo snap install classic --edge --devmode
[14:31] <ogra_> [-] Make snap "ubuntu-core" (354) available to the system
[14:31] <ogra_> ...
[14:32] <ogra_> damn ... forgot about the broken setup ... now it rolled me back to the last stable ubuntu-core
[14:32] <ogra_> ogra@localhost:~$ sudo snap install ubuntu-core --edge
[14:32] <ogra_> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
[14:32] <ogra_> evilo !
[14:34] <ogra_> about time that we get the model assertion
[14:35] <mvo> ogra_: we have it, I hope to be able to create an image today with it for the pi2, waiting for the cloud-init change to lnad first
[14:35] <ogra_> mvwell, there is a lot more ... like the machine-id changing every boot
[14:35] <ogra_> mvo, ^^
[14:35] <mvo> ogra_: aha, and I wanted to enable classic for multiple sessions, right now iirc we restrict to one but I think thats not needed
[14:35] <ogra_> and for dragonboard we probably need the console-conf with wlan support
[14:35] <mvo> ogra_: it does?
[14:36] <ogra_> mvo, yeah
[14:36] <mvo> meh
[14:36] <mvo> ogra_: do you happen to know why?
[14:36] <ogra_> https://bugs.launchpad.net/snappy/+bug/1619721
[14:36] <mup> Bug #1619721: IP changes with every reboot  <Snappy:New> <nplan (Ubuntu):Incomplete> <https://launchpad.net/bugs/1619721>
[14:36] <ogra_> not yet ... and a reboot taking 10min doesnt really help ... so i'm waiting for the cloud-init drop here too
[14:36] <mvo> ogra_: machine-id or IP?
[14:36] <pbek> popey: thank you for reporting, I couldn't even test for a while because I get: "multiple nvidia drivers detected, this is not supported"
[14:36] <mvo> ogra_: heh :)
[14:36] <ogra_> one is a result of the other
[14:37] <mvo> ogra_: ahhhh
[14:37] <ogra_> netplan transfers the machine-id now
[14:38] <ogra_> pbek, Bug 1615248
[14:38] <mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
[14:38] <ogra_> there is a workaround
[14:39] <pbek> ogra_: thank you, I know. but I fear removing my envidia directories because currently two are in use...
[14:39] <ogra_> in use ?
[14:39] <ogra_> how can there be more than one in use ? :)
[14:40] <mvo> ogra_: ordering again? dbus-uuidgen running before the writable-paths are mounted maybe?
[14:40] <pbek> I don't know
[14:40] <ogra_> if you tend to switch back and forth between two drivers, just rename the dir for the one not in use ...
[14:40] <ogra_> there is no way that both are in use on a single boot
[14:42] <ogra_> [  OK  ] Started Snappy daemon.
[14:42] <ogra_> [  OK  ] Stopped Snappy daemon.
[14:42] <ogra_> [FAILED] Failed to start Snappy daemon.
[14:42] <ogra_> See 'systemctl status snapd.service' for details.
[14:42] <ogra_> oh, lovely
[14:43] <ogra_> thats what you get when being auto-rolled-back by 20 revisions :P
[14:43] <popey> pbek: happy to test any time.
[14:43] <pbek> ogra_: I put my heart into it and moved some away ;)
[14:44] <ogra_> yeah, just rename them, worst case you can move them back
[14:44] <pbek> popey: thanks a lot, that's my current desktion file: https://git.launchpad.net/~pbek/qownnotes-snap/tree/setup/gui/QOwnNotes.desktop
[14:45] <pbek> and that's the yaml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
[14:50] <ogra_> uhm ...
[14:50] <ogra_> ogra@localhost:~$ mount |grep machine-id
[14:50] <ogra_> tmpfs on /etc/machine-id type tmpfs (ro,relatime,size=94216k,mode=755)
[14:50] <ogra_> ogra@localhost:~$ grep machine-id /etc/system-image/writable-paths
[14:50] <ogra_> ogra@localhost:~$
[14:50] <ogra_> mvo, ^^^ any idea where that bindmount comes from ?
[14:51] <ogra_> ogra@localhost:~$ grep -r machine-id /usr/share/initramfs-tools/*
[14:51] <ogra_> ogra@localhost:~$
[14:51] <ogra_> definitely not from the initrd
[14:52] <ogra_> why the heck is it a tmpfs at all
[14:53] <pitti> ogra_: systemd mounts it as that if the root fs lacks a machine-id and is not writable
[14:53] <pitti> ogra_: check dmesg
[14:53] <ogra_> oh my
[14:53] <ogra_> can we prevent that somehow ?
[14:53] <ogra_> ogra@localhost:~$ dmesg|grep machine-id
[14:53] <ogra_> [   11.400424] systemd[1]: Installed transient /etc/machine-id file.
[14:53] <ogra_> ogra@localhost:~$
[14:54] <ogra_> i assume it does that before processing fstab ?
[14:55] <pitti> yes
[14:55] <pitti> but the initrd should mount it if it's a symlink/mount, why doesn't it?
[14:55] <ogra_> the initrd doesnt mount anything
[14:55] <ogra_> it creates an fstab
[14:56] <pitti> I thought we changed it to mount the writable parts of /etc in initrd
[14:56] <ogra_> nope
[14:56] <pitti> well, that was for system-image
[14:56] <pitti> but it's the same problem
[14:56] <mvo> still suspect its the ordering, i.e. we mount too late, i vaguely remember a similra 15.04 issue
[14:56] <ogra_> i mounts one or two dirs that are actually needed by systemd to start at all ...
[14:56] <pitti> you *can't* mount stuff in /etc during boot
[14:56] <ogra_> but beyond that it only creates fstab
[14:57] <pitti> well, at least not stuff that is needed for boot
[14:58] <ogra_> iirc i even filed a bug that we should move it ... but james told me back then it was desired that systemd gets a chance to do fscks
[14:58] <ogra_> so we never moved it to the initrd
[14:58] <pitti> I do remember having written a PR which moves it
[14:58] <pitti> maybe it was moved back
[14:59] <ogra_> for initramfs-tools-ubuntu-core ?
[14:59] <ogra_> i'm sure it never landed
[14:59] <pitti> well, whatever we used in system-image
[14:59] <ogra_> you probably did it for the phone
[15:00] <pitti> *nod*
[15:01] <ogra_> Bug #1512361
[15:01] <mup> Bug #1512361: /etc/writable should be handled by the initrd, not by rootfs builds <Snappy:Triaged> <initramfs-tools-ubuntu-core (Ubuntu):Confirmed for ogra> <livecd-rootfs (Ubuntu):Confirmed for ogra> <https://launchpad.net/bugs/1512361>
[15:01] <pitti> curious that this even works at all -- stuff in /etc/systemd/ also won't be considered for boot if it gets mounted during boot only
[15:01] <ogra_> ah, no, thats something different
[15:01] <pitti> for snaps that install boot services
[15:02] <ogra_> aha, there is Bug 1423529
[15:02] <mup> Bug #1423529: writable partitions not fsck'd. <Snappy:Fix Released by jamesodhunt> <https://launchpad.net/bugs/1423529>
[15:04] <pitti> in comment #4 -> i-t has fsck'ed / and /usr for a while
[15:04] <pitti> it wuold then also need to fsck /writable
[15:04] <ogra_> well
[15:04] <ogra_> / is /writable nowadays
[15:04] <pitti> ah, so much the better
[15:05] <ogra_> http://bazaar.launchpad.net/~jamesodhunt/ubuntu/vivid/initramfs-tools-ubuntu-core/bug-1423529/revision/51
[15:05] <pitti> so why do we need any mounts in /etc in the first place?
[15:05] <ogra_> because there might be rw files ?
[15:05] <pitti> well, everything on / should be writable then :)
[15:06] <niemeyer> ogra_: regarding "iirc slangasek and sabdfl both agreed the product name should be kept for the actual img files (especially in the light that we renamed ubuntu-core to ubuntu-base exactly for this)"
[15:06] <ogra_> ogra@localhost:~$ grep -c etc /etc/system-image/writable-paths
[15:06] <ogra_> 23
[15:06] <pitti> plus /usr, /lib, /snap etc. bind-mounted from snaps/images
[15:06] <ogra_> and we dont want the whole of etc to be writable
[15:06] <niemeyer> ogra_: Yes, that's still right.. the rename is specifically for the *snap*, not the product, and not the images
[15:06] <pitti> argh -- I had hoped with the all-snaps thing the writable bind mounts madness would have gone :)
[15:06] <ogra_> niemeyer, ok, thanks for confirming :)
[15:06] <niemeyer> Part of the point of renaming the snap is exactly this, actually.. that snap is not the product
[15:06] <ogra_> yeah
[15:06] <niemeyer> ogra_: Yes, that's still right.. the rename is specifically for the *snap*, not the product, and not the images
[15:06] <niemeyer> Part of the point of renaming the snap is exactly this, actually.. that snap is not the product
[15:07] <mvo> pitti: hm, how far are we from an empty etc? i.e. would it even boot?
[15:07] <pitti> ogra_: well, IMHO we want /etc to be very small and completely writable
[15:07] <ogra_> there is an echo in the room :)
[15:07] <ogra_> pitti, i'm sure we dont :)
[15:07] <mvo> pitti: last time we talked about this, the software was not ready, is it now?
[15:07] <niemeyer> ogra_: I think there's a bug in my client, actually :)
[15:07] <ogra_> heh
[15:07] <pitti> mvo: this has never been started; I made a proposal a few years back but it got shot down
[15:08] <ogra_> pitti, well, probably not the thing to change a day before RTM now +
[15:08] <mvo> pitti: yeah, I remember that, I think there is a good chance for it to get resurrected
[15:08] <mvo> ogra_: yeah, not today, but I think there is agreement that we want to move into this direction, no?
[15:08] <pitti> ogra_: heh, yes
[15:08]  * didrocks remembers that as well, and also some proposals for the default systemd preset on the ML
[15:09] <ogra_> for now i guess we want to bind-mount machine-id from the initrd then
[15:10] <ogra_> that will be a bit fiddly ... but doable ... (we need to create it on first boot etc)
[15:10] <didrocks> oh you are still using my "Installed transient /etc/machine-id file" patch? :)
[15:11]  * didrocks just backlogged
[15:11] <ogra_> didrocks, ?
[15:11] <didrocks> I did that patch IIRC a year and half ago or so for snapd in systemd
[15:12] <didrocks> as you don't provide even an empty file by default IIRC
[15:12] <ogra_> hmm
[15:12] <ogra_> looking at the filesystem ...
[15:12] <ogra_> ogra@localhost:~$ ls -l /var/lib/dbus/machine-id
[15:12] <ogra_> lrwxrwxrwx 1 root root 15 Sep  5 13:58 /var/lib/dbus/machine-id -> /etc/machine-id
[15:12] <didrocks> hence the tmpfs
[15:12] <pitti> didrocks: it's not a patch, it landed upstream at that time and has lived a happy life ever since :)
[15:12] <ogra_> why cant we link it the other way around ?
[15:12] <pitti> didrocks: you actually did it for the life system, I think
[15:12] <didrocks> oh right, live system…
[15:13] <didrocks> pitti: I don't remember which ones went upstream and the ones which didn't
[15:13] <ogra_> make /var/lib/dbus writable and create the file in there ... and ship a dnagling link in the readonly image
[15:13] <pitti> doesn't help
[15:13] <pitti> it would still be dangling when booting
[15:13] <ogra_> it does help messing with /etc
[15:13] <pitti> also, that's opposite of what upstream dbus does
[15:14] <pitti> IMHO it's best to set up /etc in initrd, especially now that / alreaady gets fscked
[15:14] <pitti> everything else will keep causing bugs
[15:14] <pitti> we've had like 10 bugs due to that in touch, and now they all come back
[15:15] <pitti> /var and /usr are suported to be separate partitions, but not /bin, /sbin, /lib and /etc
[15:16] <mup> PR snapd#1674 closed: interfaces/builtin: add udisks2 and removable-media interfaces <Critical> <Reviewed> <Created by ssweeny> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1674>
[15:17] <ogra_> pitti, that sounds very buggy
[15:17] <ogra_> (that lasdt line of you)
[15:17] <ogra_> why would etc not be allowed to be a separate partition
[15:17] <ogra_> it surely was for decades
[15:17] <pitti> for sure not
[15:18] <pitti> you could never have /etc/init.d or /etc/rc?.d on a separate partition, for example
[15:18] <pitti> or stuff in /lib etc.
[15:19] <ogra_> well, technically you can since we use initramfs
[15:19] <pitti> it works a bit better now as we e. g. got rid of /etc/mtab madness
[15:19] <pitti> sure, if you mount it in the initrd, all is well
[15:20] <pitti> but you can't expect the init system to mount /etc when /etc is the place to describe what to mount and do for boot :)
[15:20] <ogra_> yeah, indeed
[15:21] <pitti> so, again: mount everything in /etc/, /lib, /bin/, /sbin in the initramfs, and we'll stop having subtle bugs like that
[15:22] <ogra_> mvo, triggering a new ubuntu-core ... seems snapd (amd64) and livecd-rootfs now got published
[15:22] <ogra_> running
[15:23]  * zyga would love to have a call around initramfs using code derived from snap-confine to setup the root fs
[15:24] <ogra_> zyga, sounds like a great series 18 feature :P
[15:25] <zyga> ogra_: perhaps earlier
[15:25] <ogra_> yeah, but definitely not for RTM ... and unlikely for GA
[15:25] <zyga> ogra_: feels fragile to differ on the root filesystem layout
[15:25] <zyga> ogra_: yes, I agree
[15:25] <zyga> ogra_: note: call != implemented
[15:25] <zyga> ogra_: just to figure out what we want in the end
[15:26] <ogra_> well, if you can get snap-confine into the initrd ... withough making it grow by tens of megabytes ...
[15:29] <zyga> ogra_: snap-confine is ~50KB stripped
[15:29] <zyga> ogra_: note, it would not be snap-confine, just code derived from it, like snap-setup-filesystem or something
[15:29] <zyga> ogra_: so that we have consistency
[15:29] <ogra_> zyga, ah, and i guess it is go and has no deps ?
[15:29] <zyga> ogra_: it's C
[15:30] <zyga> ogra_: no deps for this part
[15:30] <ogra_> hmm, lovely
[15:30] <ogra_> oh man ...
[15:30] <zyga> what?
[15:30] <ogra_> will we ever n3eed to use machine-id in the ubuntu-core running in classic ?
[15:31] <zyga> no
[15:31] <zyga> we will never ever ever see it
[15:31] <ogra_> to actually have the file rw bind mounted i need to create the file in the readonly rootfs
[15:31] <ogra_> but that will mean that only the initrd can actually put values in there
[15:31] <ogra_> else it would be an empty readonly file
[15:31] <zyga> ogra_: there are some tricks you can use
[15:31] <zyga> ogra_: to avoid the file altogether
[15:32] <zyga> ogra_: but note that we don't use /etc from the core snap
[15:32] <ogra_> ok, that should be safe then
[15:32] <ogra_> i just wonder if we will one day
[15:32] <zyga> ogra_: I doubt it, it's the same machine and hence same machine-id
[15:33] <ogra_> hmm,. why is there no uuidgen on the image
[15:35] <zyga> ogra_: use the kernel for that
[15:35] <ogra_> yeah
[15:35] <ogra_> cat /proc/sys/kernel/random/uuid|tr -d -
[15:35] <ogra_> that will do it
[15:35] <pbek> popey: I changed the snapcraft.yml: "    command: desktop-launch ${SNAP}/usr/bin/QOwnNotes --snap" (I added "${SNAP}/"), it seems to work now
[15:39] <mvo> pitti: hm, seeding libnss-resolve made things worse apparently, I have no name resolution on my pi2 currently
[15:39] <pbek> popey: I removed that on Aug 31th to make it build on Launchpad and deploy it to the store... we'll see what happens today
[15:39] <mvo> pitti: and can't login because of that to debug further (*sigh*)
[15:41] <pitti> mvo: ok, I think about how to fix that more properly (feel free to report a bug to track it)
[15:41] <ogra_> pitti, mvo http://paste.ubuntu.com/23137470/ ... (needs a "touch etc/machine-id" in livecd-rootfs too
[15:41] <ogra_> )
[15:42] <mvo> ogra_: typo " teh w"
[15:42] <ogra_> fixed already :P
[15:44] <mup> PR snapd#1845 closed: tests: use the real model assertion when creating the core test image <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1845>
[15:48] <ogra_> does the code look ok ?
[15:50] <ogra_> bah, reconnect
 does the code look ok ?
 what i still dont get is why this never showed up as an issue in u-d-f built images
 having the id change every boot must have more fallout
 pitti, does that mean you want the libnss-resolve addition rolled back ?
 (i need to touch livecd-rootfs now)
 (... and can do that in the same upload)
 or mvo ^^^
[15:51] <mvo> ogra_: I wonder if there is more ubuntu-image issues
[15:51] <mvo> ogra_: let me quickly retry this with u-d-f
[15:51] <ogra_> mvo, i would suspect so
[15:55] <mvo> ogra_: please revert my upload, I don't know what happend, but it seems like it break the core
[15:56] <ogra_> damn ... one second to late
[15:56] <mvo> ogra_: both the libnss-resolve and the masking of the unit
[15:56] <mvo> hm, ok
[15:56]  * ogra_ does another upload 
[15:56] <mvo> ogra_: maybe you can figure something out, I can't ssh into the image anymore with the latest edge
[15:56] <ogra_> mvo, masking of the unit means the clud-init one ?
[15:57] <mvo> ogra_: yes, well, I think so, I have no idea if it is related
[15:57] <mvo> ogra_: maybe not
[15:57] <ogra_> might be that you dont get host keys
[16:03] <ogra_> oh, lovely ... the initrde change means indeed i may also re-roll all kernels
[16:22] <morphis> zyga: just forwarded you the mail from ssweeny
[16:22] <zyga> morphis: yep, I see it
[16:22] <zyga> morphis: I'll investigate today
[16:22] <morphis> zyga: awesome!
[16:31] <SamYaple> is there a to get snappy to --no-install-recommends the stage/build packages?
[16:34] <pbek> popey: qownnotes 16.09.2 works again
[16:36] <popey> ooh pbek I'll update
[16:38] <pbek> popey: are you using it under Unity or under Mate?
[16:38] <popey> yes
[16:38] <popey> :)
[16:38] <popey> (unity)
[16:39] <pbek> 16.04 I suppose...
[16:40] <pbek> popey: could you please be so kind and test if some icons are not visible if you use the QOwnNotes dark mode?
[16:41] <pbek> Andrew from http://www.webupd8.org/2016/09/qownnotes-is-note-taking-and-todo-list.html mentioned something about that, but I can't reproduce it under my 15.10 Unity vm (I use KDE Neon on my desk)
[16:41] <ogra_> SamYaple, hmm, i thought thats the default
[16:42] <pbek> popey: you could switch to the #qownnotes room, if you don't want to pollute #snappy ;)
[16:42] <SamYaple> ogra_: oh it might be. i noticed a bloated install and assumed. ill double check!
[16:43] <ogra_> ogra@anubis:~/datengrab/devel/branches/snapcraft$ grep -r recommends *
[16:43] <ogra_> debian/changelog:  * Do not install recommends for build or stage pkgs. (LP: #1500375)
[16:43] <ogra_> snapcraft/internal/repo.py:                               '--no-install-recommends', '-y',
[16:43] <mup> Bug #1500375: inconsistent build results due to wrong usage of recommends <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1500375>
[16:43] <ogra_> looks like
[17:16] <stub> Where do I grant access to my private snap?
[17:45] <bull_> snapcraft pull
[17:46] <bull_> hello guys
[17:46] <bull_> what  snapcraft pull will do ??
[17:47] <niemeyer> ogra_: The ubuntu-core tests started working again.. did you fix anything on your end?
[17:48] <bull_> it will pull all parts right ??
[17:51] <ogra_> niemeyer, i reverted the former change
[17:51] <ogra_> on mvo's request
[17:51] <niemeyer> ogra_: What was the change?
[17:52] <ogra_> disabling of cloud-init and addition of libnss-resolve
[17:53] <ogra_> time to try another rpi image
[17:53] <bull_> guys pull, prime, and stage can be run for specified parts and alone to perform actions on all parts ??
[17:53] <niemeyer> ogra_: Ok, something is not quite right there then
[17:54] <ogra_> niemeyer, heh,. a *lot* is not quite right atm
[17:54] <niemeyer> ogra_: What else is not right?
[17:55] <ogra_> well, obviously nobody ever noticed that we re-generate the machine-id on every boot ... netplan brought that to light (every reboot now gets a new IP)
[17:55] <ogra_> cloud-init causes 5-10min boot time on pi images built using ubuntu-image
[17:56] <ogra_> we dont have support for wlan in console-conf yet (there is a test package, but debugging the other stuff kept me fry trying it yet) ... which excluded pi3 and dragonboard from RTM
[17:56] <ogra_> *excludes
[17:57] <ogra_> s/fry/from/
[17:59] <niemeyer> ogra_: Probably nobody ever noticed many bugs that we know about and many bugs that we also don't know about.. that's why we need a period of polishing after the RTM image goes out this week
[17:59] <ogra_> niemeyer, most of it is ubuntu-image related ... some of it is due to the missing bmodel assertion mvo told me (snap list is empty on arm builds, snap install trashes everything etc)
[17:59] <ogra_> -b
[17:59] <niemeyer> ogra_: Yes, we're not using ubuntu-image for this release due to those bugs
[18:00] <ogra_> niemeyer, sure. the issue is that we need working images for an RTM release
[18:00] <ogra_> niemeyer, oh, would have been nice if someone told me :P
[18:00] <niemeyer> ogra_: yep, and I believe we're going to have one :)
[18:00] <ogra_> right
[18:00] <ogra_> u-d-f images are fine and solid
[18:00] <niemeyer> ogra_: Yeah, we agreed to use that for the release on Friday, precisely because ubuntu-image looks too unstable ATM
[18:01] <ogra_> right
[18:01] <niemeyer> We have a few weeks to get that sorted
[18:01] <ogra_> what do we do with assertions ?
[18:01] <ogra_> i assume we want u-d-f to put them in place
[18:01] <niemeyer> Yeah, definitely
[18:01] <ogra_> so the resulting image doesnt need to be re-flashed
[18:01] <niemeyer> Indeed
[18:01] <niemeyer> Although that's not a blocker
[18:02] <niemeyer> the reflashing part, specifically
[18:02] <niemeyer> We do want the assertions in place for this release so we can test it
[18:02] <ogra_> oh, i thought that was how RTM was defined
[18:02] <ogra_> stable enough that you dont need to re-flash
[18:03] <ogra_> ogra@localhost:~$ mount|grep machine
[18:03] <ogra_> ogra@localhost:~$ mount|grep machine
[18:03] <ogra_> /dev/mmcblk0p2 on /etc/machine-id type ext4 (rw,relatime,data=ordered)
[18:03] <ogra_> \o/
[18:03] <ogra_> yay, at least one positive thing ... lets see if netplan behaves now
[18:05] <niemeyer> ogra_: The point of GA is precisely to have the golden image that may be flashed on devices
[18:05] <niemeyer> ogra_: So no "re-flash" would be an oxymoron on this case
[18:06] <SamYaple> what would be the best way to a2enmod something in apache2 with snappy? at runtime?
[18:07] <ogra_> niemeyer, well, that was what i understood regarding RTM ... we held back releasing any images for a long time because RTM was supposed to be at a quality that users do not need to re-flash but can upgrade to get to GA (and report bugs along the way)
[18:07] <ogra_> i dont really mind if it isnt like that anymore though
[18:08] <ogra_> it is just what i understood in the various discussions
[18:09] <niemeyer> ogra_: As I said, it'll probably still be the case.. we just won't block on that as we need to hit some deadlines
[18:10] <niemeyer> ogra_: If we can't generate the proper image because ubuntu-image is too buggy today, that's life.. we'll find a way to hit the deadline and release a proper image soon
[18:11] <ogra_> pitti, so i fixed the machine-id issue ... and the IP seems to persdist *after the second boot* ... i.e. i do a first boot, run console-conf, that tells me the ssh credentials and IP to use and after the second boot i get a new IP ... and this IP sticks on subsequent boots but is indeed not the IP that console-conf told me
[18:12] <ogra_> niemeyer, yeah, i'm not worried i think we did hit the worst bugs the last two days already, eveything aheadf wont be that bad :)
[18:12] <niemeyer> That's good to hear
[18:12] <ogra_> the vfat one was the hardest ...
[18:13] <ogra_> costed me two days and mvo one ... and lots of testing and poking in the dark
[18:14] <ogra_> (who would have guessed that mtools/mcopy cant handle subdirs with long names :) )
[18:22] <ogra_> mvo, so the machine-id stuff is fixed, new kernels and ubuntu-core is up with the fixes, libnss-resolve and the cloud-init drop were reverted ... (sadly my IP still changes til second boot so there is still something else) ... on my pi2 the name resolution works fine FWIW
[18:22] <ogra_> and indeed ...
[18:22] <ogra_> ogra@localhost:~$ snap list
[18:22] <ogra_> No snaps are installed yet. Try 'snap install hello-world'.
[18:22] <ogra_> ogra@localhost:~$
[18:23]  * ogra_ would really like tio be able to test the last classic shell fixes :/
[18:23] <mup> PR snapd#1849 opened: cmd/snap: fix test suite (no Exit(0) on tests!) <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1849>
[18:26]  * ogra_ decides thats enough for a day :)
[18:32] <ahasenack> do snaps have access to the environment proxy variables?
[18:32] <ahasenack> or is the env sanitized before running the commands inside the snap?
[18:33] <ahasenack> or, is there another way to tell a snap to use a proxy?
[18:33] <ogra_> i dont think the snap sees anything of the outer environment by default
[18:35] <ahasenack> this is not a service, it's a command I'm running while my env has the proxy vars
[18:35] <ahasenack> hm, sort of. This command talks to a daemon inside the snap
[18:35] <ogra_> well, even user commands run confined
[18:35] <ogra_> install hello-world ... run "hello-world.env"
[18:35] <ahasenack> good idea
[18:36] <ahasenack> heh, it has the proxy vars
[18:36] <ahasenack> "hello-world.env|grep -i proxy" shows them
[18:37] <ogra_> well, du you use a stack of wrappers in your command ?
[18:37] <ogra_> perhaps the next wrapper doesnt have them anymore
[18:37] <ahasenack> it's not my snap, I'm debugging it and I'm actually just about to file a bug
[18:37] <ahasenack> was just wondering if there was some sort of global proxy setting for snaps
[18:37] <ahasenack> like lxd has, for example
[19:02] <mup> PR snapd#1826 closed: interfaces: add interface for hidraw devices <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1826>
[19:02] <dave_uy> I'm working on a Snap package for the Bitsquare application. It is a Java FX application. Here is my https://github.com/dmp1ce/bitsquare-snap/blob/master/snapcraft.yaml. I am getting the error "Could not find any built jar files for part"
[19:02] <dave_uy> Can someone tell me where I might be going wrong?
[19:17] <mup> PR snapd#1848 closed: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
[19:17] <mup> PR snapd#1848 closed: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
[19:23] <morphis> niemeyer: thanks for merging!
[19:25] <niemeyer> morphis: np, it'd be nice to use that same function that joc added on that PR in the serial-port interface as well
[19:25] <niemeyer> But that's polishin
[19:25] <niemeyer> g
[19:25] <morphis> niemeyer: sure, I will chat with him tomorrow that we rework that in a follow up PR
[19:27] <tvoss> zyga: o/ so a rebuild later, the test only fails on amd64
[19:32] <tvoss> mvo: o/
[19:40] <mvo> hey tvoss
[19:40] <tvoss> mvo: hey, did you have a chance to take a look at my comment on the vendor branch?
[19:43] <mvo> tvoss: not yet, sorry
[19:43] <tvoss> mvo: ah okay, so not-installed does not work on trusty
[19:45] <mvo> tvoss: aha, yes, I saw that, have not looked yet, probably trivial to fix with a simple "rm tmp/usr/bin/uboot-go" in debian/rule
[19:46] <tvoss> mvo: ack
[19:49] <mup> PR snapd#1850 opened: tests: remove silly [Service] entry from snapd.socket.d/local.conf <Created by mvo5> <https://github.com/snapcore/snapd/pull/1850>
[20:52] <tvoss> zyga: are you fine with taking test_restrictions_working_args out of the check target? test failures seem to be spurious
[21:04] <tvoss> zyga: let me know what you think: https://github.com/snapcore/snap-confine/pull/124
[21:04] <mup> PR snap-confine#124: Remove test producing spurious results on trusty <Created by vosst> <https://github.com/snapcore/snap-confine/pull/124>
[21:25] <mwhudson> morning
[21:25] <elopio> mwhudson: good morning.