#snappy 2015-05-26
<dholbach> good morning
<mvo> hey dholbach, good morning!
<miken> Morning mvo, dholbach o/
<dholbach> hi mvo, hi miken
<mvo> hey miken
<davidcalle> Morning all
<D_Cent> help! my snappy won't let me install any snaps anymore - it always says "Warning: failed to remove /apps/<snap name>/<version>: '%s'". i don't know what that means but it doesn't install anything anymore :( any ideas on this=
<D_Cent> * ?
<mvo> D_Cent: uh, thats all its saying? no more information? thats bad. what snap is that that you try to install?
<mvo> D_Cent: this sounds like the "garbage collect" feature is broken for some reason
<mvo> D_Cent: and it happens for every snap you said?
<D_Cent> mvo: yeah, for everything - the exact message is e.g.:
<D_Cent> (just a sec)
<mvo> D_Cent: no rush, I'm here for at least 8 more hours :)
<D_Cent> good :) the message is: "2015/05/26 07:53:17 Warning: failed to remove /apps/webdm/0.6.1: %!s(<nil>)"
<D_Cent> followed by: "webdm failed to install: exit status 1"
<mvo> D_Cent: could you please pastebin "snappy list -v" ? is this a VM? if there is nothing "valuable" in it, could you make it available for download so that I can dig into it?
<mvo> (it being the VM if it is one)
<D_Cent> mvo: sure, here it is: http://pastebin.com/VXATTzaH it's a raspberry pi 2. unfortunately, i can't make it public because the device and software belongs to the company i work for :/
<mvo> D_Cent: sure, understood!
<mvo> D_Cent: thanks, so now you install webdm (or anything else) and it fails with the above message, correct? let me dig into the source and I will come back with more questions
<D_Cent> mvo: correct - thank you very much :)
<mvo> D_Cent: could you please edit /etc/system-image/channel.ini and set channel: to "ubuntu-core/15.04/edge" instead of the current "ubuntu-core/15.04/stable"? this should give you a updated version of the 15.04 image that has much improved error reporting. with a snappy update and a snappy reboot you could have the update version. its still based on 15.04 and is going to become a official update in some days
<D_Cent> mvo: the problem is that the raspberry pi 2 currently cannot update :/
<mvo> D_Cent: uh, once sec, you will need to "mount -o remount,rw /" the system first of course and you will also need to do the same for /writable/system/cache which holds the "other" parition of the snappy dual-partition layout
<mvo> D_Cent: meh, ok
<mvo> D_Cent: well, then we need to just update snappy in isolation :)
<mvo> D_Cent: please do "sudo mount -o remount,rw / ; sudo /usr/bin/apt update; sudo /usr/bin/apt install ubuntu-snappy ; sudo mount -o remount,ro /"
<mvo> D_Cent: that should give you the new snappy with the better error reporting
<D_Cent> mvo: and i don't destroy anything with that?
<mvo> D_Cent: no, but if you prefer a different approach, thats fine, one sec
<mvo> D_Cent: do (cd /tmp ; wget https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7401399/+files/ubuntu-snappy-cli_1.0.1-1%2B439%7Eubuntu15.04.1_armhf.deb; dpkg-deb -x *.deb .)
<mvo> D_Cent: this should give you /tmp/usr/bin/snappy that you can run and that hopefully gives the improved error messages and a clue what is wrong
<D_Cent> aah thank you :) trying that
<Chipaca> mo'in
<D_Cent> mvo: now it says (for webdm): "open /apps/webdm/0.6.1/www/public/images/app-placeholder.svg: permission denied" followed by "webdm failed to install: unpack /tmp/webdm918031435 to /apps/webdm/0.6.1 failed with exit status 1"
<Chipaca> D_Cent: and if you install something that isn't webdm?
<D_Cent> Chipaca: for my own package that i install locally, it says "/home/ubuntu/mdnsd_1.0_armhf.snap failed to install: hook command /usr/bin/aa-clickhook failed with exit status 1"
<Chipaca> D_Cent: and if you install, say, xkcd-webserver?
<D_Cent> Chipaca: also "xkcd-webserver failed to install: hook command /usr/bin/aa-clickhook failed with exit status 1"
<Chipaca> hmm
<Chipaca> D_Cent: and â/usr/bin/aa-clickhook --helpâ works?
<Chipaca> D_Cent: hold on, what's mdnsd? is that one from the store?
<mvo> my theory is that there is a incorrect apparmor file
<Chipaca> mvo: yeah, my next step was --froce, to rebuild them all
<Chipaca> but still waiting for --help
<mvo> what does "aa-clickhook --debug" yield?
<mvo> sure :)
<Chipaca> mvo: we should have a 'check' or somesuch that checks all files against hashes
<mvo> (if --debug is helpful I wonder if thats what we should do when we run hooks and present the stdout/stderr as part of the error)
<Chipaca> to ketch broken sd cards
<mvo> Chipaca: yeah, very much so, I like that idea a lot
<D_Cent> sorry, i was in a meeting - "/usr/bin/aa-clickhook --help" gives me "Usage: aa-clickhook [options]... (etc) (options -f, -h, -d, --include)"
<D_Cent> Chipaca: --debug outputs nothing
<Chipaca> D_Cent: what about âsudo /usr/bin/aa-clickhook --forceâ
<D_Cent> Chipaca: it finishes in a second, outputs nothing and exits with status 0
<Chipaca> well, that's fun :-(
<D_Cent> :(
<Chipaca> mvo: ideas?
<mvo> meh
<mvo>  so  /usr/bin/aa-clickhook --force && echo "all good" works? i.e. it also has a zero exitcode?
<D_Cent> mvo: exactly
 * mvo scratches head
<mvo> Chipaca: I think I will add some code to the hook runner that captures the output and presents it to us, maybe that gives us a clue
<mvo> D_Cent, Chipaca: in 5min or so a new snappy build should be available for testing (waiting for my cross toolchain to finish installing)
<D_Cent> mvo: thank you! can you post me the link to the deb file again then?
<mvo> D_Cent: http://people.canonical.com/~mvo/tmp/D_Cent/ contains the snappy binary and my gpg signature (if you want to verify the download)
<D_Cent> mvo: okay, this is the output now: http://pastebin.com/1sxzB6La
<D_Cent> mvo: the file "abstractions/mdns" really does not exist here
<mvo> D_Cent: ha! that gives us some clue :)
<D_Cent> mvo: looks good :)
<Chipaca> mvo: âµ!
<mvo> D_Cent: I have that file in /etc/apparmor.d/abstractions/mdns - for you its not there you say?
<mvo> Chipaca: looks like I need to push a branch with that improvement :)
<mvo> Chipaca: and ^5 back !
<D_Cent> mvo: yeah, i don't know why - i didn't do anything, but it seems to be in the image i applied on my SD card a month ago
<ogra_> did you manually edit any files in the webdm folder ?
<D_Cent> ogra_: no :)
 * ogra_ has seen that error when files were root owned in an app folder
<D_Cent> mvo: can you pastebin me this file please? :)
<mvo> D_Cent: good question what happend, maybe some sort of corruption :/ sd cards can be fragile
<mvo> D_Cent: the other thing thats strange is the webdm error, but maybe that is a red-herring and it does away once the mdns file is back, I will make it availale for you
<mvo> D_Cent: http://paste.ubuntu.com/11367079/
<D_Cent> mvo: thank you :)
<D_Cent> mvo: everything is working now :) webdm, xkcd-webserver, my own packages...
<D_Cent> mvo, Chipaca: thank you very, very much for your help! you saved me :)
<Chipaca> D_Cent: you've got it backwards!
<Chipaca> D_Cent: you helped us :)
<Chipaca> D_Cent: snappy is better thanks to you
<Chipaca> D_Cent: so thank *you* very much!
 * mvo hugs D_Cent
<D_Cent> Chipaca: that's why i like this community ;)
<mvo> Chipaca: \o/ exactly right!
<D_Cent> everyone is helping everyone :)
<Chipaca> now, back to figuring out what to call a method that checks things are ok to install a package
<JamesTait> Good morning all; happy Tuesday, and happy Lindy Hop Day! ð
<Chipaca> InstallCheck sounds like you're installing checks. CheckInstall sounds like you're checking and existing install.
<Chipaca> CheckForInstall?
<mvo> InstallOK?
<Chipaca> JamesTait: what ... what is a lindy hop?
<mvo> CanInstall?
<Chipaca> mvo: wfm :)
<mvo> CheckIfInstallIsOkOrNotOrMaybe
<Chipaca> PleasePleaseMakeTheInstallPainGoAway
<Chipaca> KThxBye
<mvo> CheckIfInstallIsOkOrNotAndAlsoLogAndComputeSomeRaondomStuff
<mvo> :)
 * mvo hugs Chipaca
<mvo> I llike KThxBye, we should have this somewhere
<JamesTait> Chipaca: energetic, jazzy, swing dance. I've never done it, but it looks quite fun.
<mvo> JamesTait: you made me watch a yt video of a 1960 lindy hop competition now. its â¦ interessting
<JamesTait> mvo, I may be mistake, but I think our very own Mr Westby participates.
<JamesTait> s/mistake/mistaken
<mvo> JamesTait: aha! I remembered it from somewhere and was wondering where I had heard it. fun!
<mvo> he will have to do a demo on the next sprint :)
<beowulf> Chipaca: is it possible, or planned, in snappy/webdm to cancel an install at the download phase?
<mvo> we have no support for this in the library yet I think but its a nice feature
<Chipaca> beowulf: that is something that would be easy to implement, but is not implemented yet
<beowulf> it seems like a thing webdm would like to have
<Chipaca> beowulf: create a card for it?
<beowulf> Chipaca: will do
<Chipaca> ta
<beowulf> ok, what's the difference between backlog and todo in the trello?
<mvo> beowulf: backlog is the big heap and todo is (in theory) the things to work on next. but its a bit muddled as we also have must-do
<beowulf> mvo: ack, i added ^ plus one other to backlog
<davidcalle> dholbach, I'm looking at your tools docs, can I start reviewing/integrating?
<dholbach> davidcalle, not quite yet
<davidcalle> dholbach, ok :)
<dholbach> davidcalle, for node-snapper I still have to talk to ogra_
<dholbach> and for the python doc I'd like to summarise it some more
<dholbach> davidcalle, did you have any general feedback about it?
<ogra_> i think node-snapper still needs some final SNAPP/SNAP changes
<dholbach> ogra_, is there a but about it or do you know what the issue is?
<ogra_> no, no bug ... its just cosmetic ... SNAPP_ vars are still supported afaik ... but will go away
<dholbach> oh ok... so just a case of renaming?
<ogra_> right in the start-service.sh script that gets produced
<Chipaca> beowulf: mvo: plus there's a whole another board of backlog i think
<Chipaca> beowulf: mvo: but i'd ask rsalveti about that one
<beowulf> simple review, add prettified bytes to snap model in webdm https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
<beowulf> (no css!)
<Chipaca> beowulf: are you intentionally dropping the âadd change:messageâ thing?
<sergiusens> mvo: Chipaca the webdm error is probably from changing from type app to type framework
<beowulf> Chipaca: yes, because i'm using parse rather than add... and sorry, i've just spotted a problem :(
<Chipaca> beowulf: k
 * Chipaca -> lunch and such, bbiab
 * Chipaca uploads the current branch to https://code.launchpad.net/~chipaca/snappy/clickety for if people want to take a peek. Not ready yet though.
<beowulf> Chipaca: when you get back, https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
<sergiusens> Chipaca: can you think of why this is like it is http://paste.ubuntu.com/11369583/ ?
<sergiusens> Chipaca: the 3 snaps there were installed with webdm
<Chipaca> sergiusens: interesting
<Chipaca> sergiusens: on the same version of snappy and webdm?
<Chipaca> sergiusens: webdm and hello-dbus-fwk are using a dbus launcher that's created a private /tmp for them
<Chipaca> sergiusens: pastebinit.mvo hasn't
<Chipaca> sergiusens: but pastebinit.mvo might be older
<Chipaca> sergiusens: do a find -ls instead of  ... whatever you did there :)
<Chipaca> so i see the dates
<sergiusens> Chipaca: I did a find with -printf
<Chipaca> sergiusens: find -ls is less work :)
<sergiusens> Chipaca: http://paste.ubuntu.com/11369660/
<sergiusens> Chipaca: it seems anything launched by webdm inherits webdm's tmpdir
<sergiusens> Chipaca: is that the desired behavior?
<Chipaca> ah! i think i got it
<Chipaca> /tmp/snaps/pastebinit.mvo/1.4.0.0.2/tmp is created by the bin wrapper
<Chipaca> the the launcher launches
<Chipaca> and creates the "right" /tmp/snap.1000_pastebinit.mvo_SFbTYJ as the tmpdir
<Chipaca> and then sets that to the actual /tmp/ and all is well
<sergiusens> mterry: in case you want to look at making the core go based http://npf.io/2015/05/pie/
<sergiusens> Chipaca: so what is at fault with these embedded tmp dirs? the service?
<Chipaca> sergiusens: /tmp/snap.0_webdm_KhJhaT/snaps/webdm/0.6.1/tmp is fine, it's webdm creating and using /tmp/snaps/webdm/0.6.1/tmp as its tmpdir when it's already got a private /tmp/
<Chipaca> sergiusens: we could drop the tmpdir from webdm as it's handled by the launcher, but we don't have to
<Chipaca> sergiusens: but also apparently webdm uses /tmp/snaps as the place to which to download things from the store?
<sergiusens> Chipaca: well, only in rolling, we still need to suport both
<sergiusens> Chipaca: it uses tmpdir as defined in launchpad.net/snappy/snappy
<Chipaca> sergiusens: which is why you have /tmp/snap.0_webdm_KhJhaT/snaps/docker031408365 (which webdm would see as /tmp/snaps) with what i presume is a docker package
<sergiusens> Chipaca: right!
<mterry> sergiusens, I imagine we could use a "run an executable" interface vs "load a plugin" if we really wanted language independence too (I bet it would be nice to let each language plugin be written in the respective language if that would be easiest)
 * sergiusens nods
<mvo> +1 for "run a executable"
<mvo> an executable
<Chipaca> sergiusens: and /tmp/snap.0_webdm_KhJhaT/snaps/.gmx.808.0 is davecheney's mdns thing
<sergiusens> Chipaca: yes, I'm not worried about those ;)
<Chipaca> sergiusens: so, in answer to your question, things that webdm installed are not inheriting webdm's tmpdir, no
<sergiusens> Chipaca: just the embedded packages, but it is the actual packages, I didn't look at the file attribs carefuly
<Chipaca> sergiusens: otherwise you would have /tmp/snap.0_webdm_sarasa/snap.1000_pastebinit.mvo_sarasa/....
<Chipaca> sergiusens: note how it's the new private tmpdir, snap.$UID_appname_random, and the old tmpdir snaps/appname/version/tmp
<sergiusens> beowulf: one of your MPs setup for review depends on this one which is on hold https://code.launchpad.net/~stephen-stewart/webdm/icons-icons-icons/+merge/259800
<Chipaca> and now, i think i'm going to go to get my lunch for real
<Chipaca> otherwise it'll be high tea instead of lunch :)
<mvo> sergiusens: was there anything new about the "FAT-fs (mmcblk0p1): IO charset iso" error from last week? I'm look at this right now and wonder if I missed anything
 * Chipaca goes back to bashing installClick into submission
<rsalveti> o/
<sergiusens> mvo: I don't think so, I went MIA after the standup on Friday
<sergiusens> beowulf: I tested query again and it works fine (from a webdm PoV)
<mvo> sergiusens: :) ok, no worries, I have some theories and will have a look
<sergiusens> beowulf: for some reason Chipaca's package makes the store return more results (even though it's super specific)
<sergiusens> nessita: any idea?
 * ogra_ thinks the charset error is just fallout of a corrupt partition
<mvo> ogra_: sergiusens had it as well
<sergiusens> nessita: context: searching for 8nzc1x4iim2xj1g2ul64 returns some apps that don't feel should be part of it
<sergiusens> ogra_: I had it, yes
<Chipaca> mvo: did you or sergiusens fsck up the partition once it was throwing those errors?
<ogra_> mvo, sure, but i dont think it is actually a charset thing
<beuno> sergiusens, can you pastebin what the request looks like?
<Chipaca> mvo: sergiusens: fsck -p, not fsck up. It was already fscked up.
<sergiusens> beuno: I fail to curl it up, but https://search.apps.ubuntu.com/api/v1/package/?q=8nzc1x4iim2xj1g2ul64 with all the headers
<Chipaca> mvo: sergiusens: both the mmcblk0p1, and the partition that would normally hold that .ko
<Chipaca> fsck ALL the things
<beuno> sergiusens, well, the headers is what will tell us what's going on  :)
<beowulf> sergiusens: ack, sorry, i'm feeling unwell so going to lie down for a bit
<sergiusens> Chipaca: hmmm, so the .ko is on system-b
<ogra_> Chipaca, why would a partition hold the .ko ...
<sergiusens> beuno: how do you set headers with curl, -H ?
<Chipaca> ogra_: well, something's got to hold it :)
<ogra_> for necessary filesystems all modules need to be in the initrd
<beuno> sergiusens, -H
<beuno> sergiusens, curl -sH 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' https://search.apps.ubuntu.com/api/v1/search?q=hello
<beuno> for example
<sergiusens> beuno: if that's the case, it should look like curl -H "X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1" -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: amd64" 'https://search.apps.ubuntu.com/api/v1/package/?q=8nzc1x4iim2xj1g2ul64'
<nessita> sergiusens, checking
<sergiusens> nessita: beuno here's the right copy paste: curl -H "X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1" -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: amd64" 'https://search.apps.ubuntu.com/api/v1/search?q=8nzc1x4iim2xj1g2ul64'
<nessita> sergiusens, I was about to say that /packages/ was not a search endpoint :-)
<sergiusens> nessita: yeah, it was the part where I was failing to curl :-P
<mvo> ogra_, sergiusens: fun! it appears like the initrd and kernel version went out of sync.
<nessita> sergiusens, try this https://search.apps.ubuntu.com/api/v1/search?q=%228nzc1x4iim2xj1g2ul64%22
<mvo> sergiusens: if you could boot your system and tell me "uname -a" and "ls -l /lib/modules/" that would be cool
<nessita> ie, with double quotes, I'll explain why
<mvo> sergiusens: your broken one
<ogra_> mvo, ah !
<ogra_> then the charset is indeed a valid complaint :)
<mvo> yes
<sergiusens> mvo: I need to recreate the env, but sure
<ogra_> mvo, that brings up an ancient plan from me ... putting modules into a separate overlay img that we mount inside the initrd ...
<sergiusens> mvo: but I was testing on 15.04, so being out of sync on 15.04 doesn't sound good
<ogra_> because else your only option would be to regenerate the initrd on the fly to get the new modules inside on kernel upgrades
<mvo> sergiusens: well, yes, one more reason to get to the bottom of this
<mvo> :)
<sergiusens> nessita: nice catch, I'll update lp:snappy to add what I presume are quotes
<mvo> sergiusens: is it a lot of work for your to re-create? or do you still have the sd card?
<nessita> sergiusens, our package index performs analysis for both the data being indexed, and the search term. The analysis, among other things, try to parse the given string to take out the most relevant part and also search for derivates
<sergiusens> mvo: let me check, I need to move away from the couch though :-)
<nessita> sergiusens, in this case I understand since the string is kind of "non sense" it searches some characters, such as the numbers
<mvo> sergiusens: haha
<jdstrand> dholbach, davidcalle: hey, a week or two back, I asked about updating https://developer.ubuntu.com/en/snappy/guides/frameworks/, https://developer.ubuntu.com/en/snappy/guides/package-metadata/ and https://developer.ubuntu.com/en/snappy/guides/security-policy/
<sergiusens> nessita: well now I am confused, not sure we should add this or take advantage of the backend and just blame Chipaca! :-)
<nessita> sergiusens, I would say the second :-)
<nessita> sergiusens, using quotes all the time is a bad idea, quotes mean exact match
<sergiusens> nessita: it's nice to blame Chipaca sometimes, but my troll hat has been off for a while :-P
<nessita> and I don't think you'd like that?
<mvo> is it just me or does "ci-info: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!Route info failed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!" look a bit excessive when it comes to "!" - I'm talking to you cloudinit
<jdstrand> dholbach, davidcalle: I think the security one may be ok... looking at the logs it seems I only card about the formatting and you fixed it. but the other two weren't updated
<sergiusens> nessita: right, so then beowulf using the strange package name for searching is a bad idea
<sergiusens> for testing it at least
<davidcalle> jdstrand, we must have missed that. Checking.
<sergiusens> as in eyeball testing
<sergiusens> jdstrand: we agreed that for docs, the team would only update from the 15.04 series and that trunk would roll with what comes next though
<nessita> sergiusens, indeed. Ideally, a user will search for keywords, such as "news" and we want to include results for "newspaper" for example
 * ogra_ hopes that eyeball testing doesnt involve needles, pins or fingers ...
<jdstrand> sergiusens: I missed that point. where is the 15.04 series branch?
<dholbach> thanks davidcalle
<sergiusens> jdstrand: lp:snappy/15.04
 * jdstrand prepares an MP
<sergiusens> jdstrand: it's basically to have stable docs; at least it's what I caught from the uos session, dholbach or dpm and confirm
<jdstrand> that's fine and makes sense. the stuff I have is all 15.04 anyway
<rsalveti> yeah, for trunk we want something more automated
<rsalveti> still need to think how to do that properly
<sergiusens> mvo: do you see that error that utlemming mentioned on snappy-devel@? I see it too and I wonder if it's trusty thing
<sergiusens> mvo: I'm also reconsidering going back to chroot [] snappy install (to alleviate the differences between 15.04 and rolling).
<davidcalle> dholbach, I'm reopening the snappy doc sprint trello to have a look at an old card, closing it back after that, don't freak out :D
<dholbach> sure, don't worry :)
<mvo> sergiusens: looks a lot like a trusty thing, we need this "re-generate sc profiles on boot so that we can inhibit this just like we do for apparmor
<Chipaca> mvo: re-generate *all* the things
<mvo> sergiusens, ogra_: so it appears the issue I see with my broken boot on BBB is releated to the kernel update from -15 to -16. it boots with -15 but find only the modules for -16 in /lib/modules (because thats what the new system is using)
<Chipaca> mvo: sc, apparmor, scripts, systemd service whatsits
<Chipaca> s/scripts/wrappers/
<mvo> Chipaca: +100
<ogra_> mvo, yeah, it would have to re-gen the initrd
<ogra_> which we cant really do :/
<ogra_> mvo, /lib/modules shouldnt matter in that case since youur issue is when mounting from the initrd
<mvo> sergiusens, ogra_: and for extra fun there is this bug that breaks fallover totally that the first reboot brings you to the good partition and the second boot to the bad one (fortunately sergiusens fixed this one)
<ogra_> well, i would really like us to find a way to make the initrd actually arch agnostic ...
<ogra_> well, perhaps not arch, but version ...
<mvo> ogra_: fwiw, we have the updated initrd it just does not get installed because of some brokenness in the snappy code that is responsible for this :(
<ogra_> aha
<ogra_> so we know the root cause even ...
<mvo> I hope so, digging into it now
<rsalveti> how are we managing the kernel update regarding the 2 partitions we have?
<rsalveti> I'd imagine we would also want a fallback for kernel updates
<ogra_> well, that is the a/b model
<mvo> rsalveti: there is code in snappy called "handleAssets and syncBootloaderFiles" that will check if there is a new kernel and copy that into the right place (unless it does not)
<ogra_> and it apparently works ...
 * ogra_ remembers sergiusens' video
<rsalveti> mvo: right, but will that reflect at both a and b?
<sergiusens> rsalveti: we have a fallback, yes; but it's all one thing today (ubuntu + kernel)
<rsalveti> or are we aligning the kernel snap with os?
<jdstrand> dholbach: fyi, https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161
<mvo> rsalveti: right now its aligned with the OS
<mvo> rsalveti: and in theory we have /boot/uboot/a that matches what OS-a needs and the same for b
<rsalveti> right, got it
<jdstrand> dholbach: that has the doc updates for the 3 files that correspond to the 3 pages that should be updated
<rsalveti> mvo: would that also contain the modules?
<rsalveti> as that can be quite big
<elopio> good morning.
<mvo> rsalveti: it contains the initrd, the modules are right now part of the system-{a,b} partitions, not part of system-boot
<rsalveti> morning elopio
<dholbach> davidcalle, did you see https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161 as well?
<mvo> hey elopio!
<jdstrand> mvo: fyi, after I finish the hashes.yaml (which is almost done) I plan to move to the sc regen on boot stuff
<mvo> elopio: sorry that I have not replied to your questions in the MP about merging the selftests yet
<mvo> jdstrand: \\o//
<dholbach> davidcalle, I'm currently busy finishing something else - let me know if you want me to take care of the above...
<mvo> jdstrand: great news, you ROCK
<jdstrand> davidcalle: all we need is https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161. that contains everyhting I want updated on the website
<davidcalle> dholbach, I'm enhancing the small script we had to convert doc, I'll look at it in a short moment, thanks for the heads up!
<rsalveti> mvo: right, need to play a bit more to better understand the ins and outs
<elopio> mvo: no problem, mostly things for the future, and I have plenty of things to do around it as it is anyway. The only thing I would like to know before getting it into trunk is about signing the deb.
 * dholbach hugs davidcalle
<mvo> rsalveti: no worries, its all going to change anyway when we make os/kernel independent
<rsalveti> jdstrand: nice, thanks for the doc updates
<mvo> elopio: cool, I will look into this
<jdstrand> np
<rsalveti> mvo: right, that's why I wanted to understand this better :-)
<ogra_> i think we should have the modules in a separate overlay
<mvo> :)
<ogra_> one that even the initrd can see, so we dont need to ship them inside (deduplication at its best :) )
<mvo> ogra_, rsalveti: its a bit of a challenge when we make them indepedent as the kernel contains userland stuff as well (nvidia user-space libs potentially etc). so it needs to be merged and I don't really like this as I want it to be as simple as possible
<mvo> ogra_: interessting
<rsalveti> mvo: right, that's indeed a concern (user space x kernel)
<rsalveti> and as a user, what would you expect from a rollback?
<mvo> would be all much more tidy if it was really kernel only and OS only
<mvo> rsalveti: exactly!
<ogra_> rsalveti, the exact same system i ran before the upgrade attempt
<mvo> the current model is mentally much simpler
<mvo> (maybe only because I'm lazy and haven't really thought through the new one of course :)
<ogra_> but it doesnt keep kenerl and userspace distinct
<ogra_> on the phone that would be fatal if we use a snappy base
<ogra_> (we'd need one rootfs per device)
 * mvo nods
<Chipaca> mvo: question for you sir: what's the reasoning behind helpers.EnsureDir, as distinct from os.MkdirAll?
<Chipaca> mvo: AFAICT the only difference is helpers.EnsureDir does not fail with error if the path exists and is not a directory
<Chipaca> mvo: which I might argue is a bug, or an unfortunate name :)
<mvo> Chipaca: laalalalalalalalala
<Chipaca> mvo: noted.
<mvo> Chipaca: is that enough of a answer ;) ? please kill it, its from my early go days when I did not realize that its legal to call MkdirAll() on exsiting dirs
 * Chipaca aliases 'bzr laalalalalala' to 'bzr remove'
<mvo> lol
<Chipaca> mvo: so much pain in your early go days
<mvo> Chipaca: not at all, I was just even more ignorant about the $world than today
<mvo> Chipaca: fortunately I have people who clean up after me :)
<Chipaca> mvo: who *claim* to clean up after you
<mvo> :P
<Chipaca> mvo: I would not have noticed, had it not being because in installClick we were using both helpers.EnsureDir and os.MkdirAll :)
<Chipaca> s/being/been/
<mvo> oh, both? meh, thats funny
<davidcalle> jdstrand, I don't get the sentence at l9 & 10 of https://code.launchpad.net/~jdstrand/snappy/15.04-docs/+merge/260161 , are you sure about it or is it just my english failing me?
<Chipaca> mvo: if that's funny, there's a lot of fun to be had :)
<jdstrand> davidcalle: that could be rephrased better
<jdstrand> davidcalle: let me do that
<jdstrand> davidcalle: done
<davidcalle> jdstrand, oh right, in the meantime I've figured out what "origin" is in that context, makes sense, thanks :)
<Chipaca> mvo: is it legit that we're unpacking with dropped privileges, but then writing the click manifest with full privs?
<Chipaca> mvo: and, followup question, would it be of the same or better legit-ness :) to write the click manifest from unpack? thus it happening with dropped privs automatically
 * Chipaca thinking of moving writeCompatManifestJSON to clickdeb
<mvo> Chipaca: I think that is a good idea and would improve things, yes
<Chipaca> ok, i'll see if it works (i expect it to) :)
<mvo> Chipaca: \o/
<mvo> Chipaca: I envy you, I spend my day in recovery shells so far
 * mvo takes a short break before the meeting ot get some $tea
 * Chipaca ignores those pesky details such as "does it *actually* work, on a device" for now
<davidcalle> jdstrand, merge acked
<kyrofa> sergiusens, ping
<Chipaca> ok, so, no, moving the click manifest creation to clickdeb is not workable at this point
<Chipaca> reverting that (for now!)
<sergiusens> kyrofa: pong
<sergiusens> Chipaca: yeah, it requires major rework
<Chipaca> sergiusens: i wouldn't say major, but as it's not the focus of this i'll postpone it for now
<kyrofa> sergiusens, I've run into something interesting with the webdm API
<kyrofa> sergiusens, I was hoping you could explain it?
<sergiusens> kyrofa: sure; I bet it's just a bug :-P
<kyrofa> sergiusens, haha! Well, let's see . . .
<kyrofa> sergiusens, first of all, a question: The install API requires the package NAME as specified in the RFC, not the ID, right?
<sergiusens> kyrofa: make me recall which one was the id and which one was the name
<kyrofa> sergiusens, I called INSTALL xkcd-webserver, which got accepted. I then QUERYd xkcd-webserver and got "uninstalled." But if I query xkcd-webserver.canonical (its ID), it's "installed"
<jdstrand> davidcalle: thanks!
<sergiusens> kyrofa: ah, yes, always the id
<kyrofa> Ah! Okay, for everything? (e.g. query, install, etc.)
<sergiusens> kyrofa: it will allow installing but all refs would be lost; this is all due to legacy support in some sense
<sergiusens> kyrofa: yes, always the id, the name is just for show
<kyrofa> sergiusens, very good, okay. I suggest updating the RFC when you're able
<kyrofa> sergiusens, thank you!
<sergiusens> kyrofa: right, let me do that
<davidcalle> jdstrand, and d.u.c updated. I now have a script that does most of the conversion and formatting work, so things should be faster in the future
<jdstrand> sounds great
<kyrofa> sergiusens, another difference between what I'm seeing and the RFC: calling INSTALL for a snap that's already installed still returns a 202, not a 200
<sergiusens> kyrofa: yeah, we have that problem in snappy proper as well
<Chipaca> mvo_: when is snappy in GOPATH? sergiusens?
<Chipaca> i don't think it would ever be there, so i'm missing something
<Chipaca> i mean the binary, to exec it
<kyrofa> Chipaca, it doesn't need to be to exec it, right?
<beowulf> mvo_: hey, thanks for the review, i don't have permission to top approve, would you mind also top approving? :) https://code.launchpad.net/~stephen-stewart/webdm/show-download-or-installed-size/+merge/260126
<Chipaca> kyrofa: we look for it in PATH and GOPATH, hence my question
<sergiusens> Chipaca: I think it's for snappy unpack and something mvo_ added to iterate faster
 * Chipaca waits for mvo_ then
<sergiusens> Chipaca: is it bothering you in some way?
<Chipaca> sergiusens: well, it reimplements exec.LookPath
<Chipaca> sergiusens: i was wondering whether we're doing that on purpose, or if it's code from early days :)
<Chipaca> (the only difference between this and LookPath is GOPATH)
<Chipaca> (and that LookPath is more careful with some error conditions)
<sergiusens> Chipaca: oh, I care less about looking in GOPATH
<sergiusens> Chipaca: ideas on this error? -> http://paste.ubuntu.com/11374504/
<sergiusens> Chipaca: aparently solved by passing --use-existing-dir
<sergiusens> mvo_: https://code.launchpad.net/~sergiusens/ubuntu-core-launcher/frameworkPathSupport/+merge/260189
<mvo_> beowulf: sure, top approving now, sorry for the delay
<mvo_> Chipaca: just to iterate faster on a real snappy its always in PATH not in GOPATH
<beowulf> mvo_: ta
<sergiusens> mvo_: what Chipaca implies is that it is rarely in GOPATH
<mvo_> sergiusens: yeah, we can kill that lookup if its not needed
<sergiusens> mvo_: where did ubuntu-core-config live again?
<mvo_> sergiusens: bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/ubuntu-core-config/
<sergiusens> mvo_: sounds good (allowing to remove code)
<mvo_> sergiusens: lp:ubuntu/ubuntu-core-config I think or lp:ubuntu/wily/ubuntu-core-config
<sergiusens> mvo_: thanks
<mvo_> yw
<sergiusens> mvo_: ubuntu branches are always hard to work with (personally), https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/frameworks-writable/+merge/260200
<sergiusens> mvo_: and maybe https://code.launchpad.net/~sergiusens/ubuntu/wily/ubuntu-core-config/azure-datasource/+merge/260201
<mvo_> sergiusens: looks good, I can merge/upload tomorrow morning
<sergiusens> mvo_: sure, no hurry
<kgunn> mterry: so i downloaded virtual machine manager cause i wanna be like mike :)
<mterry> kgunn, right, it was very easy to set up for me
<kgunn> ok...getting thru that now
<kgunn> mterry: complains about libvirt
<mterry> kgunn, when installing via apt-get?
<kgunn> mterry: i used sw store...
<mterry> sure
<mterry> kgunn, what was the error?
<kgunn> mterry: when it starts, just a dialog "Unable to connect to libvirt" so i should verify
<kgunn> that i have libvirt-bin installed, i do
<mterry> huh
<kgunn> The 'libvirtd' daemon has been started
<mterry> i didn't see that at all
<kgunn> mterry: ok...let me dork with it a bit
<kgunn> it's got some more details
<kgunn> i can try some stuff
<Chipaca> gah, missed mvo
<Chipaca> my question was *when* is snappy in GOPATH and not in PATH
<sergiusens> Chipaca: when testing, but he said you can remove
<kgunn> mterry: hehe, so apparently a reboot helped :)...so when you created your vm in vmm, do you recall what you picked for "OS type" and "version"
<mterry> kgunn, that's dumb.  :-/
<kgunn> i left generic...but then it warned "for better performance, pick an OS"
<mterry> kgunn, I think I left that blank, yeah
<kgunn> k
<mterry> kgunn, you know how to get a recent snappy image?
<kgunn> mterry: so i was just following instructions from here
<kgunn> https://developer.ubuntu.com/en/snappy/start/
<kgunn> so i got a 15.04 image
<mterry> kgunn, sure should be fine
<kgunn> mterry: sorry keep getting distracted, but is your work flow to create a vm within wmm ? or do launch outside and just connect to it?
<kgunn> just realizing vmm changes img group/owner
<mterry> kgunn, I make the .img file on my own.  Then inside WMM I add it?  Like going through that dialog that asked you for "OS type"
<kgunn> ok...that's what i did mterry, but then it when launched it says
<kgunn> failed to boot, no such device
<kgunn> arggg why is my connection being a dog all of the sudden
<mterry> kgunn, :(
<mterry> failed to boot...
<mterry> kgunn, and you pointed your new VM at the .img file during setup?
<kgunn> yep lemme grab a pic
<kgunn> mterry: https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFQVNvbmdnTVZaVVk/view?usp=sharing
<mterry> kgunn, when you made your VM, you chose "import existing disk image" in the first dialog?
<kgunn> mterry: oh...nope, i chose "local install"
<kgunn> so i goofed
<mterry> kgunn, eh, it's a weird dialog
<mterry> kgunn, but yeah, try again with existing disk
<kgunn> there we go
<kgunn> thanks mterry
<kgunn> ...back to fiddling
<mterry> kgunn, awesome
<kgunn> mterry: hey, the first part of your instructions, do you just do this to verify it's sane
<kgunn>  open VM
<kgunn>  ssh ubuntu@192.168.122.69
<kgunn>  ls
<kgunn>  snappy list
<kgunn> i'm building snappy-packaging....btw :D
<mterry> yeah
<mterry> Just to prove the VM is clean
<kgunn> ...and failed to build...dang it...
<kgunn> ah needs gfx drivers
#snappy 2015-05-27
<psusi> how do you switch to the alpha channel?  or maybe install a gui?
<psusi> also why is man not included and why is the root fs image ext4 instead of squashfs?
<dholbach> good morning
<davidcalle> Good morning all
<mvo> hey dholbach and davidcalle, good morning
<davidcalle> mvo, hello, I don't seem to be able to catch rcj on IRC, any idea at what time he is around?
<dholbach> hi mvo
<mvo> davidcalle: a good question, he is US timezone AFAIK
<davidcalle> mvo, thanks, I've noticed, but still no luck in my european evenings. Nothing urgent though, I'll drop him an email.
 * mvo nods
<willcooke> Morning folks, I've been asked a question on G+ which I'd like to check with you
<mvo> willcooke: what is the question?
<willcooke> Will it be possible to install Snaps on the U7/.deb based at some point in the future?
<willcooke> Either for developers to test their packages
<willcooke> or as an alternative to .deb based application installation
<mvo> willcooke: I think so, yes. not sure when, but conceptually I see no reason why that would not work. you can have snap/deb in parallel just fine
<willcooke> cool, thx mvo
<JamesTait> Good morning all; happy Senior Health & Fitness Day! ð
<rickspencer3> asac, https://code.launchpad.net/~rick-rickspencer3/+junk/go-template
<rickspencer3> Chipaca, ^ since you were there last week ;)
<rickspencer3> mvo, where do I file a bug against snappy build?
<ogra_> rickspencer3, see topic ;)
<rickspencer3> oops, it was beneath the fold in xchat-gnome and I didn't see it :)
<rickspencer3> thanks ogra_
<ogra_> np :)
<ogra_> pitti, do you happen to know what handles /etc/mtab in the boot process (pre and post systemd) ?
<ogra_> for pre-systemd i see /etc/init.d/checkroot.sh but i'm not sure that is used at all
<pitti> ogra_: how do you mean "handle"?
<pitti> <jedi wave> /etc/mtab is not the thing you are looking for :)
<pitti> ogra_: post-systemd> entirely ignored; the Debian package turns it into a symlink to /proc/mounts for legacy stuff that parses it, but systemd, util-linux, our boot scripts etc. all don't care
<pitti> ogra_: I'm not entirely sure about mountall, though
<pitti> ogra_: we never ran /etc/init.d/checkroot.sh, both upstart and systemd override it
<ogra_> hmm, k
<ogra_> pitti, we have some code on the system-image server that unpacks/repacks the rootfs tarball to enforce it being a symlink ... i'm not really sure why it is there
<pitti> ogra_: it's only there because some stone old software might look at it
<pitti> ogra_: which is hopefully not the case on touch, and most certainly not on snappy, so if we just want to remove it there, please let's
<ogra_> yes, and we dont use any such software on the phone and snappy images
<ogra_> yet stgraber once added code for it
<pitti> this is sorta like the x86 A20 gate -- everyone hates it, it's broken, but it's sticky as glue :)
<pitti> ogra_: I think we shoudl start dropping it from snappy; we can test the core, snapps should not ever care
<pitti> and drop it from touch as well if we ever aren't in a "deep freeze/product release round the corner" situation
<ogra_> well, we use systemd, so i guess on snappy it is already gone
<ogra_> touch not so much ... and i cant reqally find out why
<pitti> ogra_: as I said, our systemd package creates an /etc/mtab -> /proc/mounts symlink for legacy stuff compat
<ogra_> initrds /init makes it a symlink on start
<ogra_> but i dont find any code that turns it back into a file after run-init
<ogra_> yet, on my desktop installs it is a file
<pitti> ogra_: oh - we had a bug about that the other day
<pitti> ogra_: I don't remember which package any more, it was something like lxcfs or so
<ogra_> somethinng removes the link and makes it a "proper" mtab again
<pitti> which accidentally turned an mtab symlink into a file
<pitti> but I added a postinst to fix that, so maybe that got broken again
<ogra_> ogra@styx:~/Devel/tmp/meizu$ ls -l /etc/mtab
<ogra_> -rw-r--r-- 1 root root 1096 Mai 22 12:59 /etc/mtab
<ogra_> thats my utopic laptop
<Chipaca> rickspencer3: what problems did you bump into? (bug#?)
<pitti> ogra_: ah, utopic
<pitti> ogra_: yeah, we didn't have any transition code under upstart
<mvo> Chipaca: https://bugs.launchpad.net/snappy/+bug/1459212
<ubottu> Ubuntu bug 1459212 in Snappy "snappy build does odd things with poorly formed /meta/package.yaml" [Medium,Confirmed]
<ogra_> pitti, well, i doubt it is any different in upstarted vivid installs
<ogra_> which touch is
 * genii sips and ponders "odd things"
<Chipaca> mvo: maybe we should state âsnappy build is a SISO pipeâ
<pitti> ogra_: right
<pitti> ogra_: sorry, you said "desktop", and I implied "vivid/wily"
<ogra_> but grepping recursively for mtab in /etc/init* doesnt really reveal anything ...
<rickspencer3> Chipaca, Chipaca https://bugs.launchpad.net/snappy/+bug/1459212
<Chipaca> rickspencer3: yep, mvo pointed me at it
<ogra_> probably mountall :/
 * ogra_ goes to get the code
<pitti> ogra_: right, transition happens by /lib/systemd/system/debian-fixup.service calling /lib/systemd/debian-fixup
<Chipaca> rickspencer3: at least, an easy fix :)
<pitti> ogra_: so what are you looking for now?
<ogra_> pitti, a way to make mtab not being created in the vivid touch images
<ogra_> and just keep the symlink around that we get from the initrd
<pitti> ogra_: ah, right; TBH I have no idea what creates it in the first place
<ogra_> i want to drop the link creation from the system-iage server so we dont need to re-pack the rootfs anymore
<pitti> this thing is like "slap, go away", and it comes back
<ogra_> yeah
<ogra_> i remember discussion turning it into a symlink around dapper time :)
<ogra_> *discussing
 * pitti grep -w mtab * in /var/lib/dpkg/info
 * pitti sees bug 906293 and closes it
<ubottu> bug 906293 in util-linux (Ubuntu) "Get rid of /etc/mtab and store userspace options in /run" [Low,Triaged] https://launchpad.net/bugs/906293
<pitti> ogra_: hm, neither package maintscripts nor debootstrap
<pitti> live-build? livecd-rootfs?
<ogra_> pitti, yeah, it must be something in the boot process ... else the symlink the initrd created would just stay around
<pitti> Ãbereinstimmungen in BinÃ¤rdatei /sbin/mountall.
 * pitti RTFC
<ogra_> sigh, i knew it
<ogra_> yeah
<ogra_> so i will do then ...
<pitti> ./src/mountall.c:written_mtab = TRUE;
<pitti> ./src/mountall.c:if (written_mtab)
<pitti> fairly sure we have a "winner"
<ogra_> yep
<kgunn> mterry: hey, so made my snaps, but then when i ran clocks, it gave me
<kgunn> https://pastebin.canonical.com/132060/
<kgunn> did you ever hit that?
<kgunn> weird RAOF hit it last night as well when he tried...
<mterry> kgunn, oh right!
<mterry> kgunn, export LC_ALL=C.UTF-8
<mterry> kgunn, sorry, should have been part of my instructions
<kgunn> np!
<ogra_> kgunn, any specific reason to use a secret pastebin in the public channels ?
<ogra_> :)
<kgunn> nope sorry
<kgunn> mterry: success!....now matters of curiosity, why does it herald "bad system call" on running clocks
<ogra_> probably seccomp blocking it ?
<mterry> kgunn, interesting, not sure.  I'd have to look at a strace -- didn't remember seeing that
<mvo> kgunn: dmesg should tell you what syscall was blocked
<mvo> kgunn: then you can use "scmp_sys_resolver $nr" to figure out what the number means
<kgunn> thanks mvo
<kgunn> dirty dog....seems it no longer appears when i launch clocks, like a one time failure ?
<davidcalle> rcj, ping
<rcj> davidcalle, hi, what's up?
<davidcalle> rcj, hey, do you mind having a look at this Amazon ec2 doc bug? https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390?
<ubottu> Ubuntu bug 1456390 in Ubuntu Developer Portal "Snappy ec2 getting started - various issues" [Undecided,New]
<rcj> davidcalle, I can in a few minutes.  My mouse pointer has disappeared so I need to restart before I can do precision tasks like clicking on links.  I'll be back on in 5m.
<davidcalle> rcj, :)
<rcj> davidcalle, I've added our team to the bug and I'll get us started on this
<davidcalle> rcj, many thanks! I'll take care of updating the doc, just ping me or add changes in a comment on the report.
<rcj> davidcalle, I provided answers and assigned it back to you.
<davidcalle> rcj, great, thanks :)
<elopio> good morning.
<ogra_> bug 529993
<ubottu> bug 529993 in mountall (Ubuntu) "mountall produces unharmful error messages when /etc/mtab is symlink to /proc/mounts" [Low,Fix released] https://launchpad.net/bugs/529993
<elopio> sergiusens: what's the plan with the cmd directory?
<sergiusens> elopio: we need to rewrite what is inside the code; the external interface (cli) should behave the same
<sergiusens> elopio: but basically moving to client/server; so the client could be easily mocked when this happens too ;-)
<elopio> sergiusens: good. I was thinking that the cli conformance tests should be unit tests, leaving just a few functional tests. But I started digging how to fake the replies and that was not easy.
<beowulf> @reviewlist
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/remote-and-local-collections-with-sorting-and-filtering/+merge/260305 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/godepsForBuilding/+merge/260156 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/the-sun-is-the-same-in-a-relative-way/+merge/259933 | No reviews (4 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/icons-icons-icons/+merge/259800 | No reviews (5 days old)
<sergiusens> elopio: no, not at all; well you can set functions to var in as in var snappyInstall = snappy.Install and then in the tests set snappyInstall to your mock
<sergiusens> elopio: if you aspire to 100% coverage, this is the only way I think, unless Chipaca has a more clever idea
<sergiusens> elopio: the go stdlib is full of exported functions calling the internal function and testing just the internal functions
<sergiusens> beowulf: feeling better?
<beowulf> sergiusens: much
<beowulf> sergiusens: migraine
<beowulf> mvo: if you want some reviews ^^ i can start you by saying i haven't enough tests
<elopio> sergiusens: hum, Let me try that. I'm not looking for 100% coverage (yet), I just want to improve tests like 01_test_info, which just check that the reply conforms to the spec.
<beowulf> sergiusens: i added a card to trello to expose what would be the results of a GET of installed snaps to the GO templates, i want to bootstrap the app so it doesn't have to make an api call first time
<mvo> beowulf: heh :) dinner time here, probably needs to wait until tomorrow (unless someone lese beats me to it)
<sergiusens> elopio: the what I propose will get you going
<beowulf> mvo: no problem , dinner here too
<elopio> sergiusens: I'll play with that. But better wait and do it with the refactor of cmd, I think.
<sergiusens> beowulf: oh nice, if we do this, can we just do updates with websockets for all else?
<sergiusens> elopio: that will happen next month the soonest I guess
<sergiusens> beowulf: I'll do your reviews, and let me set something up for tomorrow to discuss websockets, that template you speak of and all else
<elopio> sergiusens: in the mean time we can work on tests for the functional part. Install a snap -> check the list, and things like that. Which are better without fakes and will survive the refactor.
<beowulf> sergiusens: yeah, but in the first instance i'm going to rely on a local (to the browser) list initially populated from the Go template, then sync the list in the background when the user won't notice
<sergiusens> elopio: agreed
<beowulf> sergiusens: also, sad face that we don't have https, is that correct?
<sergiusens> beowulf: works for me; initially we were going to go with a go template for most things so I'm not against it
<sergiusens> beowulf: no https as no cert, but there is a plan
<beowulf> no https would rule out a couple of browser apis that webdm could use
<Chipaca> sergiusens: elopio: I have zero clever ideas.
<beowulf> Chipaca: oh you
<sergiusens> beowulf: well, it's coming
<mterry> bzoltan, tedg: want to join a quick hangout to talk about IDEs & snapcraft?
<bzoltan> mterry: tedg: I can do a quick chat
<ogra_> isnt that just a plugin thing ?
<mterry> ogra_, well that's what I'm trying to determine, but it may influence how buildenvs are stored etc.  fact finding
<ogra_> ah, well, i thought we would have pluggable build envs too :)
<bzoltan> mterry: ogra_: I  am fine with wjatever plugin :) as long the rootfs and the tollchain of the target is directly accessible from the IDE :)
<ogra_> so it would just be a matter of picking the ones the IDE wants
<ogra_> bzoltan, right, but other parts might have different reqs ... so i would envision we have pluggable backends as well as pluggable frontends ... and the frontend just defines what it wants as backend env
<bzoltan> ogra_: mterry: so any sort of wrapping and confining of the toolchain+rootfs is a showstopper for the IDE
<ogra_> there might be parts that require a clean bootstrap ... others might want to  use a VM ... you want to use a chroot etc
<bzoltan> ogra_: I am fine with it... as long after plugging I can access the toolchain and the rootfs :)
<ogra_> sure, your backend plugin would have to do that then :)
<mterry> ogra_, why would there be so many options?  you just want a .snap sitting there, why require a VM?
<bzoltan> ogra_:  Noooooouuuuu :) I do not want chroot... I want sysroot + native toolchain_S_
<ogra_> mterry, no idea, i was just making up examples :)
 * bzoltan things that G+ hangouts are overrated :D
<ogra_> mterry, i think snapcraft should be flexible here
<bzoltan> s/things/thinks/
<ogra_> bzoltan, +1 .... excludes the community from the discussion :)
<mterry> ogra_, the more flexible we are, the less magic we can be.  We wanted to be very magic, ideally user never has to think about buildenvs
<bzoltan> mterry: I second that
<ogra_> mterry, not a user ... a provider for a certain setup
<mterry> bzoltan, talk me through the different options.  So VM doesn't make sense, sure.  chroot is bad because your plugin would need to be root to get in?  let me look at what sysroot is, /me is dumb about it
<ogra_> pypi will have different reqs than node-snapper ...
<ogra_> C++ will have another set of different reqs
<ogra_> or java ...
<mterry> ogra_, provider for a certain setup?  oh, the pypi plugin just gets pointed at the buildenv and uses it.  Why does it care what sort of chroot thing it is?
<bzoltan> mterry: Ok... I explain...
<mterry> bzoltan, ok, so sysroot is a gcc option?
<tedg> I thought a VM was fine as long as the build directory is in the local FS.
<tedg> i.e. we just need to be able to pull the directory through some magic into the VM.
<tedg> That way the IDE can get full source introspection.
<ogra_> tedg, you also want direct interaction from your Ui etc ...
<bzoltan> mterry:  In our present app dev SDK we use the chroot model.. it means that whatever Ubuntu you are on... even on LTS ... and you develop for 15.04 phone ...teh chroot will be an x86 15.04 chroot with the armhf libs and headers. And we use the x86 toolchain (make-compiler-linker) to build the armhf binaries
<tedg> Ah, so it needs some routing of STDIN/STDOUT
<ogra_> yeah, i guess so
<bzoltan> mterry:  that is a major hackaround ... but a huge saving because we do not need target specific toolchain... we simple use the target system's native one
<ogra_> but bzoltan experimented with VMs and can surely give you more details about the probs
<mterry> bzoltan, hold up
<mterry> bzoltan, you say "target specific toolchain" and "target system's native one"
<bzoltan> mterry:  yes
<mterry> bzoltan, can you please dumb that down a tad?  "target specific" is x86 toolchain that knows how to build armhf?
<mterry> And "target system's native one" is actual armhf binary toolchain?
<bzoltan> mterry:  so when you compile a phone app you do not use the LTS edition of the toolchain, but the one from the chroot
<tedg> I think he's also saying that it's the version of the target as well.
<bzoltan> tedg:  precisely!
<tedg> So the wily would default to gcc 5.2 but trusty would be a gcc 4.x
<mterry> Ok...  So "target specific" is same-arch-diff-version, and "target native" is same-arch-same-version?
<tedg> bzoltan, So then do you run the test suite using a QEMU hack? It seems like you still need to be able to exec armhf binaries in that chroot somehow.
<bzoltan> tedg: mterry: some bed time reading -> https://developer.ubuntu.com/en/blog/2015/03/18/everything-you-always-wanted-know-about-kits-were-afraid-ask/ Kits here are the chroots
<zbenjamin> mterry: a sysroot is nothing else than a rootfs, plain simple. The catch here is that you have a specially built toolchain that can use that rootfs as the source to get the headers and libraries. So instead of /usr/include, it usues /path/to/sysroot/usr/include. Same for libs
<mterry> And then the toolchain can also cross compile?
<ogra_> well, irt kind of does a native build
<zbenjamin> mterry: the toolchain itself is a cross toolchain running directly on the host. Its the standard way for most cross build SDKS, including android and Qt
<ogra_> but using the host toolchain inside the chroot for speed
<zbenjamin> mterry: thats why all lots of tools support it by default
<ogra_> in a cross way
<zbenjamin> tedg: for running cross build tests you need a emulator of course
<ogra_> it is the same ugly thing that scratchbox and the SuSE OBS use ...
<mterry> zbenjamin, yup.  Just trying to think of non-c++ stories too
<tedg> So then do we need kits to be more generic than QtCreator? We need "snapcraft Kits" ?
<zbenjamin> mterry: does a nodejs for example need to be installed systemwide? can't you use a nodejs installation from everywere to build your app?
<ogra_> mterry, as long as it is gcc you can use that model for all langs gcc compiles
<bzoltan> mterry: ogra_: We as the SDK team are lobbying for target specific toolchain + sysroot modell for years... the chroot solution is an acceptable ugly solution we can live with.. but hat is not troublefree either. VM is pointless.
<mterry> zbenjamin, I'm sure.  And Python can set PYTHONHOME and all that
<mterry> zbenjamin, but I'm not sure about other compiled language cross compile stories.  I'm sure they have something, but I've never done it in Go for example.  I know it can, just don't know what it needs
<zbenjamin> mterry: go as well can be used from everywhere afaik
<ogra_> zbenjamin, take a look at node-snapper ...
<mterry> bzoltan, zbenjamin: (A) you're IRC nicks are driving me crazy
<ogra_> i envision we'll use something similar for node in the end ... the prob with node  is that you need to compile the modules on the fly ...
<zbenjamin> mterry: lols :D
<mterry> bzoltan, zbenjamin: (B) it sounds like you guys just want a directory sitting on disk.  Nothing special to it.  It will just contain its own headers and build env setup.  Right?
<zbenjamin> ogra_: mterry: also i was wondering how to handle snaps that combine languages? For example C++ and go and nodejs ....
<tedg> mterry, I think they want the default paths changed. So, really, it's kinda snap-ifying the toolchain.
<ogra_> zbenjamin, good question ... on a snap level you just throw the binaries into the right places
<mterry> zbenjamin, I suspect each language plugin would know how to set up its own parts
<ogra_> zbenjamin, for building that gets interesting :)
<zbenjamin> mterry: almost yes, the qt tools need to be built for cross building but when we have the base sysroot + toolchain thats easy
<ogra_> there we will need the magic that mterry mentioned earlier ;)
<mterry> tedg, default paths?  I think they just want to set sysroot at build time to point at the buildenv, not by default
<zbenjamin> mterry: ogra_: so if we think about sysroots and chroots. We totally could use a chroot as sysroot, all we need is the toolchain and the cross build tools (in our case Qt) in a extra location
<ogra_> or copied in place ... or linked/bind-mounted/overlayfs-mounted
<zbenjamin> ogra_: don't say the bad word "overlayfs mounted" :D
<ogra_> might be our future :)
<mterry> zbenjamin, but you want to ideally be handed a directory that has usr/include usr/lib etc inside it, as well as usr/bin/gcc and friends.
<ogra_> mterry, quite a bit more ...
<ogra_> we're talking about gigs of build deps
<bzoltan> mterry: zbenjamin: yes, the sysroot is really not much else then the  directory structure of the target system + dev files ... PLUS we need the toolchain what knows the whereabout of that diretcory
<mterry> ogra_, yeah, the whole shebang.  everything needed to build
<ogra_> (the whole phone framework)
<zbenjamin> ogra_: as i said we could use the libraries from the chroots. We just need a external toolchain
<mterry> bzoltan, the toolchain which sits outside that directory?  why wouldn't it be the toolchain inside that dir?  for speed reasons in case we are cross compiling?
<bzoltan> ogra_:  are you sure it is gigs?
<ogra_> mterry, yeah
<zbenjamin> mterry: thats a gcc requirement
<zbenjamin> mterry: afaik a relocatable toolchain can not be inside the sysroot
<bzoltan> mterry:  the location of the toolchain is not relevan, as long it is not emulated but native
<ogra_> mterry, using the native armhf compiler in a qemu-user-static chroot works but is slower and less reliable ...
<mterry> OK, well that's fine
<ogra_> so you use the host one in cross setup
<mterry> Host toolchain is fine
<ogra_> and copy/link/mount it into the chroot
<mterry> But libs and everything inside the sysroot directory
<mterry> ogra_, wait, I thought it didn't need to be inside?
<zbenjamin> ogra_: mterry: catch is we can not move the toolchain around. Gcc does not like this. Except we compile it as relocatable.
<ogra_> yeah, they need to match the target
<mterry> zbenjamin, why is that a catch?
<mterry> zbenjamin, gcc outside, all libs inside, right?
<ogra_> yeah
<zbenjamin> mterry: i mean we can not use the default toolchain from the archive
 * tedg needs to run, but will catch up on the backlog when back (much better than hangouts) :-)
<zbenjamin> mterry: at least not how its compiled atm afaik
 * mterry *likes* hangouts
<mterry> zbenjamin, oh wait weird.  I didn't know we were using non-archive gcc
<ogra_> mterry, especially the transcripts that you can read from logs next week ?
<ogra_> :P
<mterry> zbenjamin, so there's some SDK-specific gcc we need to use?
<mterry> ogra_, I get it!  I just like your pretty faces is all
<ogra_> haha, we like yours too :)
<zbenjamin> mterry: either that, or we need to make sure the archive toolchain supports what we need
<zbenjamin> mterry: we probably need to ask a toolchain dev what is required here
<mterry> zbenjamin, (why hasn't that happened?  was it rejected?)
<mterry> zbenjamin, what exactly is it that we need that archive doens't do?
<zbenjamin> mterry: it needs to support the --sysroot switch.
<zbenjamin> mterry: and i think you need to compile that in
<mterry> zbenjamin, oh weird, that's not standard?  curious
<bzoltan> mterry:  yes, it was rejected with the explanation that they have no time and hands to maintain more than one toolchain
<zbenjamin> mterry: basically we need a toolchain that can select the sysroot its compiling against
<mterry> So this is not a solution we could build today
<mterry> Or on 14.04
<zbenjamin> bzoltan: mterry: yeah but back then we didn't come up with the idea that the default toolchain could do that maybe
<bzoltan> zbenjamin: mterry: we did not know
<mterry> yeah I get that.  I'm just trying to figure out how to move forward
<mterry> Sounds like this won't be sufficient for now
<bzoltan> mterry:  correct.. on LTS we are busted either way ... because we can not replace the toolchain there
<zbenjamin> mterry: yes so that would be only possible when we SRU that toolchain back
<mterry> that's not happening  :)
<ogra_> mterry, get doko really really drunk :)
<zbenjamin> :D
<zbenjamin> ogra_: add a "really" there :D
<ogra_> (step 1)
<bzoltan> ogra_:  you can not get doko _THAT_ drunk
<mterry> zbenjamin, bzoltan: OK...  so this sysroot solution is a future idea.  For next LTS
<ogra_> yeah, it is also very hard to get him drunk :)
<mterry> zbenjamin, bzoltan: what do you need on 14.04?  You need a chroot?
<bzoltan> mterry: sysroot + fixed toolchain on new releases and chroot on old releases
<mterry> If I give you a sysroot directory on 14.04, you can't compile using it?
<zbenjamin> bzoltan: mterry: since we switching to distribute the SDK from an installer rather the archive we could ship a new toolchain with it (maybe)
<bzoltan> mterry:  on LTS we already have the chroot based solution... kind of okey
<mterry> bzoltan, ok...  so on 14.04 give you a sysroot directory with toolchain *inside*
<bzoltan> zbenjamin:  +1
<mterry> hmm, ok...
<bzoltan> mterry:  yes, and we chroot to that sysroot
<zbenjamin> mterry: our problem is we are hitting a wall with backporting the SDK because of the new Qt that is incompatible
<ogra_> you dont really want to diverge from the archive toolchain
<mterry> bzoltan, zbenjamin: OK, so only difference is if toolchain is inside or outside sysroot
<zbenjamin> ogra_: true :/
<ogra_> we need to find a way to utilize it from the archive
<mterry> ogra_, yeah... but I'm ok having a copy of it inside a directory
<bzoltan> mterry:  yes.. and that with the present solution we chroot
<zbenjamin> ogra_: how about using exactly the same sources but enabling the sysroot caps?
<zbenjamin> ogra_: would that break ABI?
<ogra_> mterry, sure, but that looks more like "we need to recompile it first"
<mterry> zbenjamin, bzoltan: is there a bug for this yet?
<mterry> (to enable --sysroot)
<ogra_> zbenjamin, it could even get you different binary behavior ...
<zbenjamin> mterry: no i kind of just came up with it :D
<bzoltan> ogra_: crap
<mterry> zbenjamin, file one then from the SDK point of view, I'll subscribe and watch  :)
<zbenjamin> ogra_: yeah thats the problem , we probably need to ask someone who knows the toolchains by heart
<ogra_> right
<ogra_> either doko or infinity
<mterry> zbenjamin, bzoltan: so even if I gave you a chroot, that would still work in the --sysroot future, right?  You just wouldn't use the toolchain sitting inside of it
<bzoltan> mterry:  yes, it would work
<zbenjamin> mterry: you can even setup the very same chroot to do, lets say nodejs builds in it
<ogra_> mterry, how do you handle the "cross" part in that ?
<zbenjamin> ogra_: same as we do with the click chroots?
<ogra_> how do we handle it there ? qemu-user-static ?
<mterry> which is just build once per chroot, right?
<zbenjamin> ogra_: cross toolchains
<zbenjamin> ogra_: native cross toolchains
<mterry> oh do you still have one chroot that builds more than one arch output?
<ogra_> thats enough for QT ?
<bzoltan> mterry: ogra_: the present chroot solution in single run builds are pretty functional... the problem with it is that 1) takes time to set up 2) unstable for long run 3) needs root to set up
<zbenjamin> mterry: ogra_: 4) slows down the IDE horribly  5) leaks mounts
<mterry> bzoltan, zbenjamin: I'm not saying I love chroots.  By all means, get rid of them
<zbenjamin> 6) restores the leaked mounts after boot
<mterry> bzoltan, zbenjamin: but for now, they're the only game in town  :)
<ogra_> mterry, that might work for just Qt ... as soon as anything in the build tries to exec something inside the chroot you will need something like qemu-user-static again though
<bzoltan> mterry:  getting rid of chroot is good... but not by migrating to th even more messy VM
<mterry> bzoltan, I'm not advocating that.  I like the sysroot thing just fine, I think.  But it's just not available today is what I'm saying
<mterry> bzoltan, go get it added to our toolchain and then we can talk
<ogra_> and it is limited to the toolchain ...
<mterry> ogra_, yeah we may need one-chroot-per-arch
<bzoltan> mterry:  the funny things is that pretty much all otherplatform's sdk is using that sysroot + toolchain modell ... nobody is using chroot or builder VM
<ogra_> mterry, and something clever that notices if some build script tries to exec something inside the foreign chroot
<ogra_> this needs to be wrapped in qemu-user-static calls
<mterry> ogra_, or just run the build under qemu in the first place
<mterry> and be slow
<ogra_> no
<zbenjamin> +1 ogra_
<mterry> bzoltan, that's fine!  I can't control other platforms' sdks  :)
<ogra_> then your RPi will be faster :)
<bzoltan> mterry: that is called scratchbox :) NOOOOOO
<mterry> bzoltan, but nor can I flip a switch and fix our toolchain.  File a bug!
<mterry> ogra_, bzoltan, zbenjamin: OK, OK  :)  No qemu-by-default...
<bzoltan> mterry: +1 will be done
<ogra_> mterry, so your first focus shoilld be to develop such a switch then :)
<ogra_> *should
<mterry> ogra_, oh that's just for the toolchain-in-or-out-of-sysroot problem.  That doesn't solve the qemu problem, does it?
<zbenjamin> ogra_: atm all projects that are compiled for the phone need to be cross build capable. And so all tools since we have no qemu there. But thats just the phone story of course
<mterry> ogra_, yeah maybe if a snapcraft language plugin needs qemu, it will know that and do what's necessary.  but most won't need qemu, one hopes...
<ogra_> mterry, qemu-user-static (just syscall translation) is reasonably fast ... but also slightly unstable (not all syscalls can be translated) ... what i would do is to run such a syscall translated chroot and then replace the armhf toolchain with a cross x86 one that skips any syscall translation
<zbenjamin> mterry: ogra_: bzoltan: sorry guys i need to run, GF is already looking angry at me :D
<mterry> zbenjamin, thanks!
<zbenjamin> i will read teh backlog... man always the interesting conversations when i need to go D
<bzoltan> zbenjamin:  do you have GF? Duuude, where is your comitment? :D
<zbenjamin> bzoltan: lol , what was it with wife and kids you just mentioned?
<ogra_> mterry, that way your compiler runs at host speed ... and in cases where tools inside the chroot needs to exec some native binaries they can use the syscall translation and run natively
<bzoltan> zbenjamin:  that is after life
<mterry> ogra_, you're saying the x86 one inside the chroot would be able to skip the qemu translation being done on it?  qemu is fancy enough to not translate native code?
<ogra_> mterry, right
<mterry> neat
<ogra_> qemu-user-static uses the binfmt kernel module ... that checks the binary header of a file you try to exec
<ogra_> if it is foreign it wraps it
<ogra_> if not, it doesnt :)
<mterry> OK.  So sounds like the way forward is provide chroot directories to the SDK.  They'll have toolchains inside.  Which we may swap in and out for native toolchain as speed demands dictate.  We'll have one chroot per arch
<ogra_> sounds good
<mterry> That's not very controversial
<bzoltan> mterry: ogra_: sounds smart enough to me
<mterry> And in future, maybe we can skip stuffing the toolchain inside, if we get future --sysroot smarts
<ogra_> and at some point in the future we'll have --sysroot support
<ogra_> *snap*
<mterry> :)
<ogra_> (...py)
 * bzoltan lays back and opens the can
<ogra_> you havent yet ? tsk :)
<mterry> bzoltan, and that's basically the same as current SDK uses, right?
<mterry> This solution needs root though, which is a bummer.  I'd like that --sysroot option too
<bzoltan> https://www.youtube.com/watch?v=3YmMNpbFjp0
<ogra_> mterry, fakechroot :)
 * ogra_ hides in a hole
<bzoltan> :D :D
<bzoltan> mterry:  we already get used to the chroot what requires root access... it is not great but keeping it is not a regression :)
<mterry> ogra_, what is wrong with fakechroot?  I know I rarely use it for anything.  Does it just have holes in it's wall?
<ogra_> it is pretty similar to deb2snap :)
<mterry> Yeah, it uses preload too
<mterry> ogra_, but deb2snap is so great!  Surely fakechroot is too
<ogra_> mangling all sorts of vars and preloading
<ogra_> haha
<ogra_> well, it is surely not worse
<mterry> Hrm...
<ogra_> we should try it our
<ogra_> *out
<mterry> Someone hasn't learned to love deb2snap yet
<ogra_> i must admit i havent used it yet :)
<mterry> ogra_, eh, it's what you'd expect
 * ogra_ is still stuck with nodejs mostly :)
<bzoltan> mterry:  so what is the catch with that fakecroot?
<ogra_> and my shiny projects are usually shell ... foor that i just copy a busybox static binary in place ;)
<ogra_> (and snap that up)
<ogra_> bzoltan, you can run it as non-root
<mterry> ogra_, tsk tsk  :)
<zbenjamin> bzoltan: our chroots  do only need root for creation not for ru
<zbenjamin> ning tools
<bzoltan> zbenjamin:  I know that :)
<zbenjamin> Crappy.phone keyboard :)
<ogra_> yeah, somone needs to port ubuntu to the neo900
<mterry> zbenjamin, why not during a run?   I would think you'd still need to enter the chroot there?
<bzoltan> zbenjamin: I am sure your GF is delighted that you irc on the phone
<ogra_> haha
<zbenjamin> mterry: thr
<mterry> zbenjamin, yeah get out of here and kiss your SO
<zbenjamin> Schroot does not need root for running
<bzoltan> mterry:  it is true... we do not need  root to enter the schroot
<zbenjamin> bla
<zbenjamin> bzoltan: she loves it
<mterry> bzoltan, zbenjamin: Huh.  setuid then?
<zbenjamin> I guess so
<zbenjamin> But schroot is not optimal .. We should do better even with a chroot solution
<bzoltan> mterry:  I do not know how schroot does it
<mterry> zbenjamin, bzoltan: oh interesting -- what's wrong with schroot?  Seems like rest of Ubuntu uses it happily
<bzoltan> mterry:  there are lots of problems 1) bootstraping it takes ages and it is a fragile process 2) it leaks mount points... after some time you mind find 10k mount points, because schroot re-mounts sessions  what are dead 3) it does require root to set up 4) it is still an extra step between the rootfs and the IDE, so it is slow
<zbenjamin> mterry: worst thing, it leaks mounts. And then restores them all on boot. We once had a dev with 16k mountpoints
<bzoltan> mterry:  keep in mind that we hand this weapon over to entry level app developers... schroot is safe as long hard core gurus are using it
<bzoltan> zbenjamin:  dude if you jusr write redundant stuff then you are really better off kissimg your GF :)
<zbenjamin> mterry: every call to schroot.adds 3 seconds when executin something in it. Now imagine Qtc querys the qmake tool 5 times per kit when starting. also cmake. that adds.up.to a loong startup time
<zbenjamin> bzoltan: pff just because you.type faster on your fancy keyboard
<mterry> zbenjamin, bzoltan: so alright.  this is all solved by future --sysroot, I guess.  Is there some other chroot tool I should be using today until --sysroot happens?
<bzoltan> zbenjamin: I can switch over to the nexus10 just out of solidarity :D But my wife is out of the house... so no reason
<zbenjamin> bzoltan: lol
<bzoltan> mterry:  I think if you can be happy for the time being with schroot then we are on the safe track ... the VM idea we should forget as soon as possible :) that was a scary one
<sergiusens> bzoltan: as long as it works on Windows and Mac, the solutions are fine
<zbenjamin> sergiusens: well sysroots.do work
<bzoltan> sergiusens: yeps... sysroot with toolchains do work
<bzoltan> sergiusens:  it is the chroot what pulled off he cable from the portable SDK
<zbenjamin> bzoltan: redundancy dude.. Redundancy
<sergiusens> jdstrand: btw https://code.launchpad.net/~sergiusens/snappy/frameworkPath/+merge/260202
<bzoltan> zbenjamin:  LOL
<jdstrand> sergiusens: yeah, I saw that-- haven't had a chance to look at it yet
<sergiusens> jdstrand: ack, just in case
<bzoltan> sergiusens:  The VM idea for the above listed reasons is a big no for the app developer... even on OSX and Windows. Application development without IDE is not an application developer. And IDE without code completions, syntax highligh, context sensitive help, source code debuging and quick builds is not an IDE.
<bzoltan> sergiusens:  the VM might be good for some sort of system emulation and for packaging non compiled non UI projects.. for everything else VM does not deliver
 * tedg back
<tedg> I don't understand how a chroot works on Win/Mac?
<tedg> Seems like you need at least Linux kernel headersâ¦ I guessâ¦ but you'd really want more than that.
<bzoltan> tedg:  on Win it does not, at all.. on Mac it might, but still doubt that it is trivil
<tedg> So it seems on those we'd need VMs, eh?
<bzoltan> tedg: VM is a dead end ..  if no chroot  then the only viable solution is the sysroot + toolchain
<tedg> Ah, I see. So you're basically rolling the chroot into the toolchain.
<bzoltan> tedg:  few years back I have asked if we want a portable SDK. I have asked if we want to port the app development story to OSX and Windows. I was told on many occasions that I better focus on providing an Ubuntu based SDK and if sombeody from teh community picks up the porting stuff then fine
<tedg> Seems there's no way to get tests to work in that case though. Even one same arch. Without a VM.
<bzoltan> tedg:  I am not sure if I understand what you mean
<tedg> I mean if you build the test, and it links against let's say a kernel syscall, you couldn't run that test on Win32.
<tedg> Even if they were both x86
<bzoltan> tedg:  when we talk about running a test we talk about runtime use case... tests are runtime actions. For that case we need the emulator or a VM.
<beowulf> sergiusens: regarding your comment about reviewing code, mvo expressed an interest there :)
<bzoltan> tedg:  but that is runtime and not editing-compiling-linking-packaging
<tedg> Don't you really want it to be edit-compile-link-test-package ?
<sergiusens> beowulf: but mvo also mentioned he wasn't an expert in js, that is what I think we should have
<tedg> For things like unit tests, not integration.
<bzoltan> tedg:  no.. testing for me means running. Different game
<bzoltan> tedg:  true... unit tests brings an extra hook
<tedg> bzoltan, So if I'm correct, your issue with VMs is that you can't get a directory of source code out for highlighting, etc?
<bzoltan> tedg:  in the present app sdk we do not have much story for unit tests... functional tests we support, but that is runtime
<tedg> bzoltan, Why couldn't we mount a dir from the host system into the VM, and use the edits in the host system?
<bzoltan> tedg:  that is just one ... code completion, source code debugging, context sensitive help... al features what makes the IDE
<bzoltan> tedg:  it still would not give us access to the qmake in the VM
<tedg> bzoltan, Sure, but if we told the IDE that your sysroot is /foo/bar and to compile you run "in-vm-gcc" as long as that gcc could mount the VM, mount /foo/bar and run on it. Everyone is happy.
<tedg> bzoltan, I'm pretty sure I can do that :-)
<tedg> i.e. you run vm-qmake and perhaps that ssh's into the VM and runs qmake
<bzoltan> tedg:  and you give me 10 developers for 2 years and tell the Qt upstream that we have just forked their IDE :)
<tedg> It seems all you need is access to the files and the STDIN/STDOUT of the tools.
<tedg> How they do their job isn't important to the IDE.
<bzoltan> tedg: horrible slow ... already the chroot puts 3-5 seconds on each call.. with ssh and VM it would be horror
<tedg> So if I can make it fast, you'd be happy with a solution like that though?
<bzoltan> tedg: VMs just simple do not blend with IDEs
<tedg> I think we could do tricks with things like LXC to make it not be performance bound.
<bzoltan> tedg: but why?
<tedg> Well, we can use the toolchain we have for one :-)
<bzoltan> tedg:  I doubt you can even fix any VM to get even close to direct access...
<tedg> But once we abstract at that level the archiecture thing starts to fade away.
<tedg> Basically all the path/directory issues get handled by the container.
<bzoltan> tedg:  the real solutiuon is what we talked with mterry, ogra_ and zbenjamin
<tedg> That solution seems pretty limited, and requires some base changes in how our toolchain works. Which seems expensive.
 * mterry is happy with whatever you folks come up with
 * mterry is tired of thinking about toolkits
<tedg> Perhaps I'm not seeing it, but a relocatable toolchain really only solves the problem of building it. But not really the rest.
<bzoltan> tedg:  I give you a scenario... I am an app developer.. I have set up my project so it targets three devices ... one phone, one desktop and one legacy tablet. Very generic scenario ... One app different targets. I am editing my code .. each target have different API set... I push tab-tab to complete a property of a component... the IDE looks up for the name .. I change teh target and hit tab-tab ... I canhe again tab-tab ... do you want to pre-deploy 3 VMs and
<bzoltan>  access 3 times ssh/mounting for that simple property? Or do you start the VM when I hit tab-tab? It just does not work that way with IDEs... you want direct access to the rootfs and to the toolchain
<tedg> I only want to start the VM when you hit compile.
<tedg> So instead of gcc it calls lxc-gcc
<tedg> So all the code is available directly to the IDE in the host system.
<bzoltan> tedg:  compliation is just one thing.. code completion, syntax highligt, context sensitive help, etc
<tedg> Sure, and you get all of those with local access to the files.
<bzoltan> tedg:  developers want code completion before compilation
<bzoltan> tedg: how do you mount the rootfs + the qmake from a non deployed VM?
<tedg> I don't do it that way. The VM deployment mounts from the host fs.
<tedg> The VM's image is tiny, only enough to mount to host's exported filesystem.
<tedg> So all the files remain in the host.
<bzoltan> tedg:  so you expect the SDK to deploy _all_ VMs what the developer configures as target?
<mterry> Only for building one target, one VM right?
<bzoltan> tedg:  and even if you mount the file system... how do you expose the qmake?
<tedg> Correct
<tedg> Expose qmake via SSH
<bzoltan> mterry:  tedg: no .. building is the last step
<tedg> So you call lxc-qmake
<bzoltan> tedg:  not possible to expose the qmake via ssh
<tedg> It will start the container if need be, and give you STDIN/STDOUT of Qmake in the container.
<bzoltan> tedg: start the container on-demand? Wait for how long for a code completion?
<tedg> We're expecting to run containers for all of your legacy apps as well. They'll have to be fast :-)
<tedg> No, code completion is done on the host file system.
<tedg> You don't need the container to access the files.
<bzoltan> tedg:  but I need to run the container at least once to export the files
<tedg> I'm not sure what you mean by "export the files"
<bzoltan> tedg:  Simple... the IDE needs instant, random access to the files of the target and native access to the toolchain. that is it...
<tedg> I think that getting the files from the host FS to the container FS will just be a bind mount.
<bzoltan> tedg: we can not and will not fork the IDE :) to work around our VM hacks... Qt upstream already rolling eyeballs seeing our chroot hacks
<bzoltan> tedg:  opposite direction... the IDE on the host needs to access the target file system
<tedg> I guess I'm not asking you to. I'm saying that we have a compiler kit that is "lxc-gcc" and "lxc-g++" and those would be used in that case.
<tedg> The IDE doesn't need to know more about containers.
<bzoltan> tedg: I need to cross-check it... qmake is one level higher than gcc/g++
<tedg> I imagine we won't need to fork to make qmake configurable :-)
<bzoltan> tedg:  and as I said, the IDE needs editing time access to the files and qmake not only build time
<bzoltan> tedg:  well... that is exactly what we made with Meego :) back in stone age
<tvoss> bzoltan, how does eclipse solve that problem?
<bzoltan> tvoss: does it?
<tvoss> bzoltan, I used to use it in a somewhat vanilla configuration quite some time ago for embedded development and it works surprisingly well
<bzoltan> tvoss:  does eclipse support Qt development with VMs?
<bzoltan> tvoss:  with local sysroot and toolchains yes .. that is not a challange for QtCreator either
<tvoss> bzoltan, that's not the question, the question is: cross-compiling/building for a target that is not the host
<bzoltan> tvoss: the questio is where the IDE pulls the toolchain and the target fs
<tvoss> bzoltan, sure, just saying that eclipse has way more exposure to embedded dev environments than qt creator has ... likely to have some good ideas over there
<bzoltan> tvoss:  if it is local then it is a nobrainer
<tvoss> bzoltan, sure, the interesting questiion is non-local (vm/container/device)
<tvoss> whatever
<rsalveti> bzoltan: tedg: how is android solving this?
<bzoltan> tvoss:  no, it is not eclipse vs. qtc issue ... it is local sysroot versus container issue
<bzoltan> rsalveti:  with sysroot
<rsalveti> I think a native cross compiler + sysroot would generally fix the issue
<rsalveti> right
<rsalveti> as long we ship both, we're good
<bzoltan> rsalveti:  precisely
<rsalveti> we don't need anything else
<rsalveti> I don't want to rely on our toolchain at all
<tedg> So then Android apps don't have unit tests?
<rsalveti> we could consume it from the archive, but I prefer having a pre-built (static only) toolchain that we ship as part of the sdk or something
<bzoltan> tvoss:  rsalveti: both eclipse and qtc were primarily made for dealing with toolchains and sysroots
<rsalveti> same thing as android does
<tvoss> rsalveti, I don't think it would harm to investigate into other ides
<tvoss> in the sense of gaining inspiration
<rsalveti> anything besides sysroot (vms/chroot and so on) is just super complicated when you need to support multiple os
<bzoltan> tvoss:  just do not make the impression that :) this issue is about a shortcoming of the QtC :) code completion and syntaxt highlight, API help are the same in all IDEs
<rsalveti> bzoltan: right, and why are we not doing that *today* already with touch?
<rsalveti> I don't get this idea of relying on backporting a toolchain and such
<bzoltan> rsalveti:  I am asking that question since day zero :)
<rsalveti> well, and what is the answer that you got? :-)
<rsalveti> there must be at least one
<tvoss> bzoltan, I don't say that it's a shortcoming, just saying we should look around :)
<bzoltan> rsalveti:  we went thru this with ogra_ and zbenjamin with mterry. We need to check the possibility of enabling --sysroot in out toolchain and make it relocatable.
<rsalveti> bzoltan: right, my question is why can't we do that?
<rsalveti> you said above that nobody wanted to maintain 2 toolchains in the archive
<bzoltan> tvoss: Of course... what android sdk does better is that they use sysroot
<rsalveti> what I'm saying is that we don't necessarily even need to maintain this *in* the archive
<rsalveti> tvoss: the overall solution across IDEs is providing a native cross toolchain + sysroot
<bzoltan> rsalveti:  my hope is that this 2nd toolchain would be the same as the 1st... with some extra build options
<rsalveti> bzoltan: right, and that is something that your team could maintain, right?
<rsalveti> simple, create a snap for your toolchain ;-)
<bzoltan> rsalveti:  sysroot support and relocation of the toolchain are what we need
<bzoltan> rsalveti:  Yeps, i will  investigate this option
<rsalveti> bzoltan: right, then just fix it :-)
<bzoltan> rsalveti: duuuude
<rsalveti> on our side all we need to do is offer a way for a sysroot to be used/consumed
<rsalveti> the plugin can do whatever
<bzoltan> rsalveti:  my agenda here is to raise the red flag that the VM path is just a big hack and would cost us more then doing the right thing (tm)
<tedg> We're gonna need some sort of container solution if we expect to be able to install debs as dependencies anyway. (i.e. for nodejs core)
<tedg> Even if that ends up in a sysroot
<rsalveti> right
<bzoltan> tedg: +1 for that .. chrootable sysroots are fine
<rsalveti> bzoltan: it's fine, from the snapcraft perspective we could support sysroot, chroot and also vms
<bzoltan> rsalveti: \o/
<rsalveti> guess that's the basic requirement you were looking for
<zbenjamin> rsalveti: do we need apt there? I thought we will have devpacks for that
<tedg> I think that, at least for the short term, we'll need apt to get started.
<bzoltan> rsalveti: tedg: what we agreed with the boys before was that as an intermediate solution we keep the schroot alive and do not cause feature regression. As next step we investigate the toolchain issues and possible fix it and offer a sysroot + toolchain solution. For testing and runtime and all other non compiled non UI projects VM is just fine.
<rsalveti> yeah, I see we moving from apt -> devpacks
<zbenjamin> rsalveti: +1 for the android way but keepn in mind we need.a binary compatible tc to.our.libs
<rsalveti> since then we could have people providing devpacks as well
<rsalveti> like upstream and so on
<rsalveti> zbenjamin: sure
 * bzoltan EOD ... 10pm here
<zbenjamin> i wonder if its possible to let apt run against a sysroot/rootfs... something like apt-get --rootfs /somepath install somepackage
<zbenjamin> bzoltan: you are going to sleep? Now i need to wonder about your commitment :D
<rsalveti> that's kind of tricky indeed
<rsalveti> what we did on linaro was always creating the sysroot from scratch
<rsalveti> either building it (when using OE), or debootstraping it
<rsalveti> since you generally don't want to update the sysroot so often
<bzoltan> tedg: rsalveti: mterry: zbenjamin: ogra_: Thanks for this discussion.. let's itterate it :) I really enjoy that we move this ship forward
<tedg> I think for apt you probably want to just use LXC there. Then it thinks that the sysroot is /
<zbenjamin> bzoltan: +1
<tedg> It is also "root" and can change all the files it wants
 * tedg watches out for icebergs
<tedg> ;-)
<rsalveti> tedg: right, that's a way, more to the chroot direction
<zbenjamin> tedg: yeah sure, i just know that other package managers _can_ do that :D
<rsalveti> for sysroots I think devpacks will be very handy
<zbenjamin> rsalveti: +1 , devpacks sounds perfect for sysroots
<tedg> rsalveti, Do you imaging a devpack is a just an app snap with known paths that we mount into the sysroot?
<zbenjamin> rsalveti: and since we are doing the tool from scratch it should be able to use a sysroot... snapcraft --sysroot ~/device1/sysroot install-devpack touch-sdk
<tedg> i.e. /usr/include/foo for the foo devpack
<rsalveti> tedg: yeah, something like that
<rsalveti> we could have a small sysroot + a huge qt devpack for example (painful but to show how it could work)
<rsalveti> for personal it's easier since Qt is part of the core image
<rsalveti> so we could have a big sysroot including our supported libs by default
<rsalveti> *supported sdk libs
<tedg> So then my package definition would be something like: devpacks: [a, b, c], npm: [d, e, f], go: [x, y, x]
<tedg> And that builds up the dependencies for the environment.
<rsalveti> right
<rsalveti> the main advantage, I see, for devpacks is that we don't necessarily need to consume the dependencies from the archive
<rsalveti> of course we could have devpacks produced out of the archive, initially
<tedg> Perhaps someone could sell devpacks in the store ;-)
<rsalveti> maybe :-)
<zbenjamin> rsalveti: tedg: regarding snaps. Will it be possible for us as the SDK ship devtools for the device (gdbserver , custom app launcher) as a snap so we can pull it from the store for a device?
<zbenjamin> rsalveti: tedg: so we do not need to include them in the core image but can painless install them when required
<rsalveti> right, don't see why not
<tedg> zbenjamin, I think we need something like that, not sure exactly how that'll work quite yet.
<tedg> That way you could have stable/devel builds for the device as well.
<tedg> Using the example of needed gcc 5.2 for wily vs. gcc 4.9 for vivid
<zbenjamin> on the "other" Qt device they pull packages from the archives when developer mode is enabled
<tedg> Hmm, that's crazy :-)
<zbenjamin> :D
<tedg> Clearly they need more sunlight.
<zbenjamin> better than the current situation on our phone, where a developer manually needs to make the rootfs writeable to install gdbserver ;)
<tedg> I think we really want you to be able to build for a specific device without having that device available. For things like buildservers for instance.
<zbenjamin> yes definately
<rsalveti> right, either something we make available via the store
<rsalveti> or something that the sdk could sideload
<zbenjamin> rsalveti: sideloading from the SDK is problematic as soon as we have binaries
<rsalveti> zbenjamin: why?
<zbenjamin> rsalveti: gdbserver needs to have the right architecture for the device.
<tedg> zbenjamin, https://code.launchpad.net/~ted/ubuntu-seeds/gdbserver/+merge/257872
<rsalveti> right, but we could simply sideload the right snap
<zbenjamin> where do we get the correct package from is the better question
<zbenjamin> tedg: wow finally :D
<rsalveti> zbenjamin: right, depends on who is the owner of it :-) we could always consume what is available in the archive
<zbenjamin> rsalveti: we can hardly ship all possible snaps for the sdk, if we can provide a central place to download them thats fine too
<rsalveti> and produce something snappy compatible
<rsalveti> right, we can have something :-)
<zbenjamin> rsalveti: so you worked for linaro? Then you know exactly how to build a binary compatible static toolchain for our devices right? :D
<zbenjamin> its horrible to find informations about that topic
<rsalveti> zbenjamin: I was managing the team doing that
<rsalveti> but in a smaller scope
<rsalveti> we used sysroots for 2 things
<rsalveti> one was using open embedded to create the sysroot and the cross compiler in order to allow people building stuff for arm64 (when we didn't have any major os supporting it)
<rsalveti> and the other was to help bootstraping new architectures for debian/ubuntu, mostly using multi-arch
<rsalveti> getting the toolchain right is the painful thing
<rsalveti> which is why linaro was producing native toolchains based on their own gcc versions
<zbenjamin> i figured, we considered shippig a custom static tc for the click SDK but i was not sure i could make a compatible toolchain and could not find enough informations about how to test that
<rsalveti> to help people that were relying on codesourcery
<rsalveti> yeah, it's a bit painful, but I think we had that documented somwhere
<zbenjamin> rsalveti: i hope you still have that somewhere :D
<rsalveti> zbenjamin: I think I do, need to dig a bit :-)
<beowulf> sergiusens: hey, need help, trying out queryPackageNames branch and http://webdm.local:4200/api/v2/packages/?q=xkcd isn't returning what i'd expect, is the url i'm using correct?
<zbenjamin> rsalveti: \o/ thats good
<sergiusens> beowulf: it would exactly the same thing a "snappy search" from the cli would return
<sergiusens> beowulf: which would be similar to curl -H "X-Ubuntu-Release: rolling-core" https://search.apps.ubuntu.com/api/v1/search?q=xkcd |python -m json.tool
<beowulf> sergiusens: then i'm doing something wrong as http://webdm.local:4200/api/v2/packages/?q=xkcd returns 22 results, as does a search for 'foo'
<sergiusens> beowulf: are you running the version compiled from the MP?
<beowulf> sergiusens: yes
<beowulf> sergiusens: 0.6
<beowulf> current is 0.6.1
<beowulf> (as in, trunk is 0.6.1, i don't mean /apps/webdm/current is 0.6.1)
<sergiusens> beowulf: remember, just in case, that it case to be in $GOPATH/src/launchpad.net/webdm and not some random branch
<sergiusens> sorry for typos, ssh on a slow connection
<beowulf> sergiusens: *facepalm*
<sergiusens> beowulf: I thought it would be somethin like that
<tedg> mterry, I added a section "Snap from scratch" at the bottom of the doc. Thoughts?
<tedg> mterry, I think it distills a bit of what we've discussed today, with the idea of targets providing their own toolchain.
 * mterry looks
<tedg> I imagine we could build the first dev packs with chroot and deb2snap or something like that.
<tedg> And then in time we can make them smarter.
<beowulf> sergiusens: +1, \o/
<mterry> tedg, you and your snappy-native thinking  :)
<mterry> tedg, I'm still in desktop land
<tedg> Ha, I've been upset at dpkg for a long time :-)
<tedg> The reason I like that idea is that it basically inverts the cross-build problem.
<tedg> And, I think, then makes it simpler.
<mterry> tedg, so this is vearing toward an idea I was thinking about.  There is a lot of similarity between devpacks and our language plugins
<tedg> Hmm, that is true
<mterry> tedg, I don't think I'm ready to say one eclipses the other.  But maybe they could
<mterry> tedg, and more importantly, that would solve the problem of what to call the languages: key  ;)
<tedg> Perhaps they build on each other. It seems like you'll want a base target and then others.
<tedg> For instance, the base would have to provide the C compiler for Python modules.
<mterry> tedg, you're thinking about the gcc toolchain?
<mterry> tedg, I guess.  But then you'd just say "devpacks: python3, c++" (except in yaml)
<mterry> It's already a list field
<mterry> Or maybe the python3 devpack would dep on the c++ one?  (on the expectation that compiled modules are common)
<tedg> Yeah, that could provide more power to dev packs that are perhaps, non-standard in that they'd run other things.
<mterry> tedg, but for example, the codespell app doesn't need c++
<mterry> It would just need a python3 plugin (or devpack or whatever we call it)
<tedg> Hmm, it would still need to know the target platform though.
<tedg> i.e. whether python3 was installed there
<mterry> tedg, maybe.  I think it's reasonable for python3 to just always install python3 into the snap
<mterry> tedg, but you're talking about the version of Core that is targeted, right?
<tedg> Yeah, I can see that. Let deduplication solve the problem.
<tedg> Yes
<mterry> tedg, (also, some apps may want a specific version of python3)
<mterry> tedg, version of Core is a whole separate problem though I think.  early versions of snappy.yaml spec had (have?) a target: key
<mterry> where you specify core or whatever
<mterry> That seems reasonable to define in yaml vs build command
<mterry> slash devpack
<tedg> Hmm, I was thinking that you'd have multiple though, eh?
<mterry> tedg, multiple what?
<tedg> Are there fat snap packages?
<tedg> core-armhf, core-arm64, core-i386
<mterry> tedg, target multiple versions of coree?
<mterry> tedg, ah.  well that's not quite version.  that's arch
<tedg> core-mips ;-)
<mterry> we're talking two different things I realize
<mterry> I was talking 15.10 vs 16.04
<mterry> tedg, ok, regarding arch...  let me reread  :)
<tedg> Sure, I think they're related though. The version is a number and an architecture, no?
<mterry> tedg, well I was approaching from version may mean whether python3 is available in Core or not.  Whereas that's not an issue across arches
<mterry> so sure... python3 devpack is available for multiple arches.  no problem, right?
<mterry> tedg, ^
<tedg> I think so yes. But I think it has to then depend on a "core devpack" that is arch specific.
<tedg> For example, to build modules.
<mterry> tedg, well in each buildenv, the devpack would the right version of python in
<mterry> *put
<tedg> The right version of python, but what about the modules it downloads and installs?
<tedg> Seems also the Python devpack would then need to have a version of python to put into the environment for every target arch.
<rsalveti> you could have a base devpack for the interpreter
<mterry> tedg, it's the intermediary for that... so it can make sure
<rsalveti> and just use pypi for the other stuff
<mterry> tedg, sure
<mterry> rsalveti, right -- I assume pip is getting every dep we care about
<mterry> I mean, there are also compiled deps
<tedg> Yeah, so if I'm on x86 building an arm package. The python devpack would have a compiled armhf version of the interpreter that'd show up in the install directory.
<rsalveti> right
<rsalveti> you could as well have fat devpacks (multi-arch)
<rsalveti> and just install for the target snap arch you're creating
<tedg> Not sure if the python devpack needs to be target arch based. i.e. python-armhf-devpack, because we probably don't want to have everything in one.
<tedg> Does fat here mean multiple host arch or multiple target arch?
<rsalveti> depending on the case it could mean btoh
<rsalveti> since it could provide the cross compiler + target libs
<tedg> I think we're gonna have to support some minority architectures, so it might not be useful to be really fat.
<rsalveti> right
<tedg> We might need to kinda have a mixed situation there.
<rsalveti> yeah, it's just a convenience
<tedg> When snappy queries the store it'll look for the host architecture.
<tedg> So besides building, we can assume that's correct.
<rsalveti> right
<tedg> So it seems that a devpack needs the target architecture in the name?
<tedg> Or is there some way we can be more clever there?
<rsalveti> http://bazaar.launchpad.net/~lool/snappy/snappy.devpacks-definition/view/head:/devpacks.md
<rsalveti> what is a bit complicated is that this interferes directly with the snap naming
<rsalveti> same for apps, frameworks and such
<rsalveti> that same problem of starting an 'app' that is armhf only
<tedg> Ah, I didn't realize there was docs already for this.
<rsalveti> and then wanting to do the x86 version for it as well
<rsalveti> would you rename that? would you go with fat by default?
<rsalveti> fat might be too fat though
<rsalveti> when querying the store is a bit easier
<rsalveti> since you give the arch
<tedg> Oh, that doc describes a lot of how snapcraft should work...
<rsalveti> tedg: yeah, check the links part of that doc
<rsalveti> more how it could work at this stage
<tedg> So it might be that we can just support querying the devpack yaml directly to align all the architectures.
<mterry> tedg, we've been able to avoid dealing with a lot of what devpacks might entail by avoiding compiled languages in our first pass
<rsalveti> yeah
<rsalveti> solving the case for pure python/nodejs apps is already a big win
<tedg> Not sure that the dependencies don't kill us there before we get to the win. Seems like a lot of modules have a compiled part underneath
<mterry> tedg, medium win then  :)
<rsalveti> that could as well be true, but could still be a second step thing
<tedg> Heh
<tedg> Can we please bikeshed the amount of win it would be?
<tedg> :-)
<mterry> tedg, there's a lot of bootstrapping to get to even one win  :)
<mterry> I'll take a baby win from the ground up
<mterry> tedg, let me open a google doc for that
<tedg> mterry, So could a "language plugin" really be a devpack that provided a "snapcraft" command?
<mterry> tedg, I'm not sure they are perfectly overlappig
<mterry> tedg, it was just a quick thought
<mterry> tedg, it might be safer to continue with language plugins for now
<tedg> I think they overlap from the lifcycle perspective, which is really nice.
<psusi> how do you switch from 15.04 stable to rolling/alpha?
#snappy 2015-05-28
<dholbach> good morning
<davidcalle> Bonjour
<dholbach> salut davi
<dholbach> salut davidcalle
<JamesTait> Good morning all; happy Amnesty International Day! ð
<tbr> JamesTait: happy Pungenday, 2nd day of Confusion in the YOLD 3181
<JamesTait> Only the second day of confusion? That can't be right!
<tbr> run ddate and check for yourself (depending on your distro release you might need to install the ddate package nowadays)
<JamesTait> I'm sure I've been confused for more than just a day. ð
<sergiusens> morning
<Chipaca> sergiusens: morning!
<Chipaca> sergiusens: mvo: do you think https://code.launchpad.net/~chipaca/snappy/clickety/+merge/260456 is reviewable, or should i split it?
<sergiusens> Chipaca: I can spend my day on it :-P
<sergiusens> Chipaca: might need a repeat for mvo_
<Chipaca> yeah
<Chipaca> mvo_ and his fancy underscore
<Chipaca> mvo_: do you think https://code.launchpad.net/~chipaca/snappy/clickety/+merge/260456 is reviewable, or should i split it?
<Chipaca> as it stands, it's splittable fairly easily
<Chipaca> let me do that
<Chipaca> * famous last words
 * sergiusens can spend his day on it :-P
<sergiusens> Chipaca: if it were that way, you would of done it though
<Chipaca> sergiusens: well, maybe
<Chipaca> sergiusens: the first commit, and the last commit, are a set
<sergiusens> Chipaca: do one that gets rid of EnsureDir
<Chipaca> sergiusens: the junk in the middle are splittable
<sergiusens> Chipaca: that is splittable at least
 * Chipaca nods
<Chipaca> this feels like shuffling things around still; less than happy with it, but if i go on it gets massive
<Chipaca> so, small steps
<Chipaca> anyway, to split
<Chipaca> mvo__: we get it. you like underscores.
<sergiusens> Chipaca: well I already added a comment fwiw
<sergiusens> heh, mvo__ is on a connection rampage
<Chipaca> sergiusens: answered
<sergiusens> Chipaca: great answer ;-)
<Chipaca> oh dear
<Chipaca> there are more than a few places where we use path.Join instead of filepath.Join
<sergiusens> Chipaca: aren't any legit? like urls?
<Chipaca> sergiusens: i don't think so
<Chipaca> sergiusens: egrep --exclude \*_test.go -r '\bpath\.[A-Z]'
<Chipaca> none of it seems to be on build, so that should still work on non-/-systems
<sergiusens> Chipaca: partition was mostly unreviewed in the beginning of time
<Chipaca> in whoever-it-was's defence, path vs filepath is stupid/silly/asking for trouble
<sergiusens> Chipaca: indexURL := systemImageServer + "/" + path.Join(channel, device, "index.json") might be better as a url.Parse
<sergiusens> Chipaca: avoiding the escaping problem we had already
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/remote-and-local-collections-with-sorting-and-filtering/+merge/260305 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/godepsForBuilding/+merge/260156 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260112 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/use-skipdir/+merge/260465 | No reviews (less than a day old)
<Chipaca> it's weird what nothal chose to not report
<sergiusens> Chipaca: can you get the webdm one for building?
<sergiusens> there are indeed some missing things there
<Chipaca> sergiusens: i can't get it any more than it's already gotten
<sergiusens> Chipaca: thanks!
<mvo_> Chipaca: let me look at the branch now (re reviable>)
<mvo_> Chipaca: looks reviewable to me :) I see sergiusens already started(?)
<Chipaca> mvo_: too late :)
<Chipaca> mvo_: i've split out the unrelated bits, which are up for review now
<Chipaca> mvo_: then i need to merge those back and get it going
<mvo_> Chipaca: heh, ok
<rsalveti> morning
<Chipaca> sergiusens: mvo_: thanks for the reviews! all landed now. https://code.launchpad.net/~chipaca/snappy/clickety/+merge/260472 merged those.
<Chipaca> sergiusens: if an oem install fails, we don't clean up udev
 * Chipaca files a bug
<beuno> *cough*gadget*cough*
<Chipaca> beuno: no, those are fine
<beuno> Chipaca, what's an oem install?
<mvo_> Chipaca: cool, looking now
<Chipaca> beuno: there's no such thing, what are you talking about
<Chipaca> beuno: bug 1459642 is what i was talking about
<ubottu> bug 1459642 in Snappy "If a gadget install fails, udev is not cleaned up" [Undecided,New] https://launchpad.net/bugs/1459642
 * sergiusens watches how Chipaca plays beuno 
<beuno> Chipaca, you get points for confusing me in my pedantic correction
 * Chipaca wins
<beuno> I also now realise I'm not 100% awake
 * Chipaca wins *double*
<Chipaca> ok, i'm off to find lunch before the zomg backlog thing
<Chipaca> o/
 * sergiusens goes for breakfast
<kyrofa> sergiusens, ping
<kyrofa> sergiusens, got a question when you get back from breakfast :)
<sergiusens> kyrofa: I'm back
<kyrofa> sergiusens, haha sorry, I was in a meeting. Still there? :P
<beowulf> clurrrr: o/
<clurrrr> hello
<beowulf> clurrrr: do you have Vagrant installed?
<clurrrr> no, will i need it?
<mterry> tedg, can you flesh out the "What a buildenv looks like inside" section of the snappy doc to include your latest chats with the sdk team?
<beowulf> clurrrr: well, it's even easier than building a vm of snappy
<tedg> mterry, Sure
<beowulf> clurrrr: https://developer.ubuntu.com/en/snappy/start/#vagrant
<tedg> Trying to deal with this scalingstack build failure right now though :-/
<beowulf> clurrrr: and is free
<clurrrr> beowulf: thanks :)
<beowulf> clurrrr: after step 4 in that guide, you can 'sudo snappy install webdm' and you'll get the current webdm
<beowulf> but i think i should probably start something in a public cloud where people can see webdm trunk
<clurrrr> i can't speak to whether anyone else would need that, but it would help me
<elopio> good morning.
<elopio> fgimenez: welcome!
<fgimenez> elopio, thx! glad to be around
<Chipaca> mvo_: sergiusens: so, what do we need for a 15.04 release?
<mvo_> Chipaca: lets look at the must-do column :)
<Chipaca> mvo_: i think we killed it
<mvo_> :)
<Chipaca> \o/ ?
<seb128> does anyone know how to boot a snappy image on a laptop?
<seb128> I tried to create a 15.04 image using u-d-f and to dd that to a stick
<mvo_> Chipaca: re-generate existing systemd units, exec wrapper, seccomp on boot
<Chipaca> seb128: that should work
<seb128> but the machine doesn't reconnize the stick as bootable
<Chipaca> seb128: it's worked for me in the past
<Chipaca> seb128: the machine is full of lies :-p
<seb128> note that this machine wants things to be uefi compliant to list them in the boot menu
<seb128> so I guess the key is not
<mvo_> Chipaca: the terrible delay when the cp -a /boot/a -> /boot/b happens
<seb128> I had issues in the past trying to boot a valid ubuntu 32 bits image
<mvo_> Chipaca: but that one is a bit tricky as we do not have rsync on the image, we could add it of course
<Chipaca> mvo_: i thought jodh had had it added
<Chipaca> i distinctly remember him saying so, in fact
<mvo_> Chipaca: there was a branch for this, but it was solved in a different way iirc
<Chipaca> ahh
<seb128> Chipaca, mvo_, any idea on how to boot from an usb stick on an uefi machine?
<mvo_> Chipaca: getting the instal.yaml into the trunk would also be nice, but that needs u-d-f support too, so sergiusens needs to be involved, its hanging there for some time
<Chipaca> seb128: bug 1425370 is fix-released, so it should work
<ubottu> bug 1425370 in goget-ubuntu-touch (Ubuntu) ""ubuntu-device-flash core" images can't boot with UEFI" [Undecided,Fix released] https://launchpad.net/bugs/1425370
<seb128> Chipaca, using vivid?
<mvo_> seb128: uh, if it does not work, either slangasek or sergiusens should be able to help
<Chipaca> seb128: "vivid"?
<seb128> Chipaca, the laptop I called u-d-f on
<seb128> I did use "u-d-f core 15.04 -o iso.img" and dd-ed that to a stick
<Chipaca> seb128: presuming you're using the tools ppa, sure
<seb128> no I'm not
<seb128> I'm using plain Ubuntu
<seb128> let me enable the ppa :p
<seb128> thanks
<Chipaca> seb128: yeah, also that u-d-f invocation looks like any vegetable
<Chipaca> seb128: i mean, i'm not sure it's correct
<Chipaca> sergiusens: ^ could you check? i keep on losing track
<sergiusens> Chipaca: it looks correct
<sergiusens> mvo_: we need to discuss the u-d-f thing, should I only compile it against vivid?
<sergiusens> since trunk is long gone
<Chipaca> mvo_: i'll do the regeneration one, if that's alright
<jdstrand> dholbach, davidcalle: hey, I noticed yesterday that https://developer.ubuntu.com/en/snappy/guides/package-metadata/ is not formatted correctly
<Chipaca> seb128: you could also get http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<jdstrand> dholbach, davidcalle: this is the same issues we had with the security page before (that has been fixed). specifically, subpoints are not indented properly
<jdstrand> for example: 'security-template' should be a subpoint of 'caps'
<mvo_> Chipaca: sure!
<jdstrand> there seems to be a lot of stuff in there that isn't indented right
<dholbach> jdstrand, davidcalle (not here right now) worked on a script - he wanted to show it to me tomorrow - I'll make sure to mention to him what you just said
<dholbach> AFAIR the markdown command worked, right?
<jdstrand> dholbach: ok. in the meantime I will be doing a 1 character MP for meta.md for 15.04. will you see that automatically or should I ask you to review?
<jdstrand> re markdown> let me double check
<dholbach> just push it
<jdstrand> dholbach: yes, markdown is fine and resulting file is properly indented
<jdstrand> oh wait
<jdstrand> actually, it is for ports, but not caps
<jdstrand> let me look at this again
<jdstrand> I also totally said that wrong, security-template is not a subpoint of caps
<jdstrand> silly me
<jdstrand> dholbach: let me review it more carefully and get back to you
<jdstrand> dholbach: ah, yes
<jdstrand> dholbach: subpoints of services and binaries is not correct
<jdstrand> 'name', 'description', 'start', 'caps', security-template',e tc should all be subpoints under 'services'
<jdstrand> dholbach: and the markdown is correct for that
<jdstrand> dholbach: do disregard my previous comment: "for example: 'security-template' should be a subpoint of 'caps'", but do regard my comment on services and binaries :)
<dholbach> just so I understand it all now... using the markdown tool on https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/security.md should be fine now? :)
<jdstrand> dholbach: security.md has been fixed. it is meta.md that is the issue now
<dholbach> ok
<jdstrand> dholbach: fyi, pushed http://bazaar.launchpad.net/~snappy-dev/snappy/15.04/revision/442
<dholbach> thanks jdstrand
<jdstrand> np
<sergiusens> asac: fyi http://getgb.io/
<sergiusens> tvoss: ^
<seb128> k, just can't get something that boots on a laptop
<seb128> I emailed the list, let's see if somebody has a clue/can help there ;-)
<elopio> tedg: mterry: for snaps with a free license, do we want to enforce reproducible builds? Like, instead of uploading the .snap to the store, upload the snapcraft.yaml and build it in the store
<mterry> elopio, like a tarball of their source, plus the yaml?
<mterry> elopio, it's an interesting idea
<beuno> elopio, mterry, no  :)
<beuno> the store doesn't build stuff
<elopio> beuno: that's easy to fix, just add a builder ;)
<beuno> elopio, it's easier to not fix it!
<mterry> :)
<elopio> beuno: I agree. But I find this is awesome: https://wiki.debian.org/ReproducibleBuilds. For technologies that will control my house, I would love to be able to trust what I'm installing.
<beuno> it is great
<elopio> anyway, it was just a question to see if that was on the plan.
<beuno> it's also not a reality, really, atm
<beuno> and, that's for debs
<beuno> I'm not sure if that'll apply in any way to snaps
<elopio> snapcraft gives us the chance to get reproducible builds. But as I said, I was just wondering... I'll add it as a wishlist, somewhere.
<elopio> maybe it's enough with getting a link to the source, and the snapcraft yaml. Then I can compare the packages that I can build with the packages that I can install.
<beuno> elopio, it's explicetly out of scope for the store, FWIW, building anything
<elopio> beuno: because of limited resources, or because you think it's not useful?
<beuno> elopio, to give it a clear scope
<beuno> so we can do some things well instead of many things badly
<elopio> ack.
<beuno> launchpad, I think, will grow the capability to build snaps
<elopio> tedg: mterry: the only way I see to validate your work is to get a bunch of python hackers and tell them to make a snap.
<elopio> luckily, we have a bunch of python hackers at hand.
<mterry> elopio, :)
<mterry> elopio, I mean, LP could easily grow snap-building tech
<mterry> it's not far from a PPA
<beuno> mterry, right, so cjwatson is expecting you to loop him in
<beuno> so he can start seeing how to bring launchpad into the fun
<mterry> beuno, I know, I've talked to him
<mterry> beuno, we're not at the point that I have anything he can use yet
 * mterry goes afk
<damjan> sometime ago I installed core in kvm, since then it's been update up to version 146 â¦ is that ok?
<asac> Chipaca: can you paste he diff of https://code.launchpad.net/~chipaca/webdm/m1777/+merge/259864 in pastebin please?
<asac> i cannot open launchpad
<Chipaca> asac: neither can I, but let me see if I have that branch locally
<Chipaca> asac: http://pastebin.ubuntu.com/11415239/
<Chipaca> asac: however, it might no tbe that
<Chipaca> asac: because if you say it happens when starting a *service*, then something else is wrong
<Chipaca> asac: because webdm and your service would both be running as root
<Chipaca> ah, unless it's just being denied by apparmor
<Chipaca> asac: try it and tell me :)
<Chipaca> asac: easy way to try: chmod 01777 /tmp/snaps, and try to restart hte service
<jdstrand> beuno: is it safe to assume that "release" is only in the json for snaps and not clicks?
<asac> Chipaca: can you please try webdm on the release image?
<asac> it doesnt work it seems
<asac> in kvm?
<Chipaca> asac: sure, give me a sec
<beuno> jdstrand, yes, but also, not even in the snaps, as that's metadata really that lives on the server
<Chipaca> asac: you mean http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz right?
<asac> yeah
<jdstrand> beuno: I meant from the store json
<beuno> jdstrand, ah
<beuno> jdstrand, yes, only snaps
<jdstrand> beuno: I was adding filtering by extension and wanted to see if I could avoid hitting _links
<jdstrand> cool, thanks
<Chipaca> asac: what exactly doesn't work?
<Chipaca> asac: webdm itself does not run, you need to update first
<asac> Chipaca: i installed fresh webdm from store
<asac> and it doesnt run either
<Chipaca> asac: it's running fine here
<Chipaca> asac: how are you determining that it's not running?
<asac> Chipaca: grepping process
<asac> and looking at log
<asac> i have 0.6.1
<Chipaca> asac: yep, 0.6.1 works fine here
<asac> let me reboot
<Chipaca> asac: how is it failing for you?
<asac> i am on core 70
<asac> with the permission denied error
<asac> from above
<Chipaca> asac: did you do the chmod i suggested?
<asac> Chipaca: in webdm?
<asac> no
<asac> i thought its fixed in latest webdm
<Chipaca> asac: no, in trunk
<sergiusens> asac: core launcher had a bug wrt to tmpdir so I made webdm create the path as the fix to tmp dir in the core launcher would of taken ages to land
<sergiusens> asac: latest trunk, not in store webdm
<asac> right, should be in store i guess
<sergiusens> asac: I am releasing a new webdm today
<asac> i dont think the mkdir will even fix it
<sergiusens> asac: with this and the iot world fixes
<asac> the diff that Chipaca posted creawtes /tmp/snaps
<asac> but the error is about /tmp/snap.XXXXXX
<asac> but the error is about /tmp/snap.0_webdm_XXXXXX
<asac> so maybe check it against the released image
<sergiusens> asac: you say webdm from store does not work on 15.04/stable? I've tested that a lot before releasing
 * sergiusens recreates image
<asac> yes
<asac> sergiusens: just download the real image
<asac> sergiusens: http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<asac> wget it
<asac> use kvm
<asac> snappy remove webdm, snappy install webdm
<asac> bang
<Chipaca> sergiusens: otoh that worked for me :)
<Chipaca> asac: what else have you installed?
<asac> Chipaca: hello-world
<asac> ok i will wget again
<asac> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/20150423/ubuntu-15.04-snappy-amd64-generic.img.xz
<asac> J,,
<asac> HMM
<asac> maybe thts wrong :)
 * asac aborts
<asac> goes for http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<beuno> remember, the store is down, just in case  :)
<Chipaca> beuno: it's working fine here :)
<beuno> Chipaca, it won't serve any downloads
<Chipaca> beuno: ... it just did
<Chipaca> 6.08MB of webdm
<Chipaca> twice
<beuno> ah, maybe squids
<beuno> it lost all access to swift
<Chipaca> squids are awesome
 * Chipaca tries to sing it to the lego movie theme, and fails
<josepht> Everysquid is awesome
 * ogra_ humms Octopus's Garden
<beuno> Chipaca, yeah, so if something's in squid, you might still be able to get it for a short while
<beuno> but no new uploads, and stuff will get pushed out of squid soon
<sergiusens> asac: everything works here http://paste.ubuntu.com/11415739/
<Chipaca> asac: could you pastebin the output of "find /tmp/ -ls" please?
<asac> so webdm works now
<asac> but my go-example-webserver doesnt still
<asac> http://paste.ubuntu.com/11415807/
<asac> that bails with permission denied too
<asac> xkcd-webserver has same problem it seems
<asac> wow
<sergiusens> asac: you can't mkdir, that requires special privs
<sergiusens> Chipaca: ^
<asac> is this fixed on 15.04/edge?
<asac> the launcher bug
<sergiusens> asac: it is one of the tasks to get done before release, yes
<sergiusens> and Chipaca is on top of the fix
<asac> ok seems not fixed on edge
<asac> hmm edge seems to not even be newer than the release image?
<asac> are we not generating images?
<asac> rsalveti: ^ ?
<rsalveti> asac: no, it's our list to fix this
<rsalveti> missing the importing piece at system-image
<rsalveti> and updating the ppa and so on
<hreset> Has anyone seen the 500 Internal Server Error when trying to run updates in snappy on the Pi2?
<Chipaca> hreset: from the commandline?
<beuno> hreset, yes, sorry, some parts of the store are down
<Ross> Hi guys.
<Guest2840> Can I get any sort of GUI out of Snappy? Basically I want to run an RDP client on Snappy that just remotes to a Windows virtual machine. Is this possible with Snappy?
#snappy 2015-05-29
<rsalveti> sergiusens: what is the current process to release a new webdm version?
<rsalveti> beuno: is the store fully back already?
<pitti> ogra_: to avoid confusion, are you looking into fixing mountall to create a symlink instead of writing mtab?
<mvo> lool: re serial port support for grub - could we simply enable this why default? or is there a (security) risk here?
<mvo> pitti: one issue I noticed while writing upgrade/failover tests is that systemd will drop me into a emergency shell sometimes. I would prefer it to log and reboot, can I simply provide my own "emergency.service" unit that will override the default one (sorry if thats a silly question)?
<tbr> mvo: what would make serial different from a screen and keyboard in terms of security? If you have physical access to a system, security is toast.
 * tbr was unhappy that he had to screw around with grub configs and uefi to get snappy working on real embedded intel hardware
<mvo> tbr: I agreee but wanted to double check if there is something I might have missed
<mvo> if there is no risk I'm much in favor of just enalbing it by default
<pitti> mvo: yes, that should work fine; i. e. adding an /etc/systemd/system/emergency.service -> /lib/systemd/system/systemd-reboot.service ought to work
<mvo> pitti: sweet, thanks
<pitti> mvo: (warning, haven't tested -- but I see no reason why it shouldn't work)
<mvo> thats fine, I will test, just wanted to double check if its a valid assumption or not
<pitti> mvo: oh, for testing you probably want to put it into /run/, not /etc ?
<pitti> mvo: or is that something which should be done in snappy in general, not just for testing?
<mvo> pitti: in general
<pitti> mvo: if so, it shoudl be done differently to avoid /etc/
<pitti> mvo: ah ok, then I misunderstood you
<mvo> pitti: the idea is that it should auto-reboot if its in "try" mode at least so that it can fallback to the "good" partition
<pitti> mvo: so then snappy.deb could ship a /lib/systemd/system/emergency.service.d/snappy.conf with something like
<pitti> [Service]
<mvo> pitti: aha, nice
<pitti> ExecStartPre=
<pitti> ExecStart=
<pitti> ExecStart=/bin/systemctl --force reboot
<pitti> Type=oneshot
<pitti> mvo: i. e. rip out the parts from emergency.service which you don't want (reset the ExecStart* commands), and then call what you do want (from systemd-reboot.service)
<pitti> mvo: that can be shipped in a deb, statically, without having to touch /etc/
<mvo> pitti: cool
<mvo> pitti: I will do that then
<pitti> mvo: foo.service.d/something.conf is like upstart's *.override files
<mvo> (add it to the relevant bugreport for now and later to it to be precise :)
<pitti> mvo: see man systemd.unit, grep for foo.service.d/
<mvo> thanks
<dholbach> good morning
<lool> mvo: so I suspect the serial port name might differ (e.g. ttyS0 and ttyS1) and that people might want to disable that if they actually need the serial port for something else
<lool> mvo: it kind of feel like a deployment option to me: headless servers where you want to use an existing serial port, but some platforms wont have it; perhaps there's a smart way to detect it though, like "press space now to enable serial console" during grub startup?
<beowulf> morning
<Chipaca> mo'in
<davidcalle> dholbach, morning, just a heads up that the doc diff I was hoping for in my script is not possible, django cms is doing way too many annoying things when publishing. Well, it's possible of course, but at this point, that would just be a waste of time :)
<dholbach> ok... let's have a chat in a bit :)
<JamesTait> Good morning all; happy Friday, and happy Learn About Composting Day! ð
<Chipaca> mvo: you around?
<mvo> Chipaca: yes
<mvo> Chipaca: working on a fix for -lp1449032-
<mvo> Chipaca: what can I do for you?
<Chipaca> mvo: silly question: any reason why we're using âsetActive/unsetActiveâ instead of âactivateâ/âdeactivateâ ?
<mvo> Chipaca: none really, go for the new name
<Chipaca> k
<Chipaca> regen is basically unsetactive/setactive, hence why i'm in that code
<Chipaca> it's painfully obvious i haven't looked into this bit of code before :)
<mvo> heh :) is it that simple? thats very cool
<mvo> Chipaca: meh, I hope its not too terrible :/
<Chipaca> that thing about us not parsing yaml twice? all lies as soon as we look at these
<Chipaca> what's mroe
<Chipaca> we parse the yaml inside (un)setActive
<Chipaca> and then parse the click manifest
<Chipaca> to get the package type
<Chipaca> which is in the yaml
<mvo> ohh
<mvo> uff
<Chipaca> we win some kind of award for that
<Chipaca> not sure it's a good award :)
<Chipaca> but at least we're consistent :)
 * mvo hands Chipaca a broom stick and a janitor award
<mvo> Chipaca: lol@consistent
<mvo> Chipaca: well, time to kill that click compat stuff entirely, oh well
<mvo> Chipaca: thanks a lot for going into these stables of augean
<Chipaca> heh. 's not that bad :)
<beowulf> should i label "webdm front end stuff" as webdm or webdm client?
 * beowulf thinks 'webdm'
<Chipaca> augh! bad branch
 * Chipaca aborts it
<Chipaca> mvo: Alas! Needs fixing. Inline.
<zyga> hi, I'm following https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/, I installed the hello-world snap but when I execute it I get:
<zyga> (BeagleBoneBlack)ubuntu@localhost:~$ hello-world.echo
<zyga> mkdir: cannot create directory â/tmp/snaps/hello-world.sideloadâ: Permission denied
<zyga> any ideas?
<Chipaca> zyga: yes
<Chipaca> zyga: there's a bug :)
<Chipaca> zyga: or :-/ depending on your lookout
<Chipaca> zyga: easy to workaround
<zyga> Chipaca: thanks, what should I do?
<Chipaca> zyga: sudo chmod 01777 /tmp/snaps
<zyga> thanks
<zyga> Chipaca: any chance for the update to the core snap?
<Chipaca> zyga: and, if you want, edit snappyd in /apps/webdm/current/snappyd and add -m01777 to the mkdir
<zyga> Chipaca: oh, I removed webdm
<Chipaca> zyga: 15.04.1 is in progress
<Chipaca> zyga: ah, ok :)
 * zyga just rebooted
<zyga> let's see how that works
<Chipaca> zyga: then the error should go away on its own in a bit
<Chipaca> heh, ok
<Chipaca> zyga: let me know how it goes
<Chipaca> zyga: there might be other bits still making that directory with the wrong permissions
<Chipaca> zyga: in rolling the whole thing is avoided because you have private tmps
<zyga> thanks
<Chipaca> zyga: but that's still WIP a bit
<zyga> while we're talking, how reliable is deb2snap in practice? I read the code so I kind of know how it works, I want to try taking a big/complex set of debian packages and making them available in a snap
<Chipaca> zyga: thank you! and if anything seems wrong or inconvenient please do let us know
<zyga> Chipaca: (works after reboot, so that's good)
<Chipaca> zyga: I have not looked at at deb2snap, tbh
<zyga> Chipaca: thanks, I'll let you know after I try :)
<Chipaca> zyga: mterry is your guy for that, but he's not around right now
<Chipaca> zyga: or vanvugt
<Chipaca> zyga: (look at "top contributors" on https://launchpad.net/deb2snap )
<zyga> yep, I'll stay in touch
<beuno> rsalveti, downloads yes, uploads are working but I need to check if they are autonatically scanned
<sergiusens> beowulf: around?
<sergiusens> beowulf: what am I to expect from https://code.launchpad.net/~stephen-stewart/webdm/repent-harlequin-said-the-ticktockman/+merge/260120 ?
<beowulf> sergiusens: magic
<sergiusens> beowulf: because I don't see the description, download_size or installed_size anywhere
<ogra_> sergiusens, isnt that clear from the url ?
<ogra_> s/url/branch name/
<sergiusens> ogra_: yeah, but it doesn't do that ;-)
<beowulf> sergiusens: one sec, context switch
<sergiusens> beowulf: ok
 * sergiusens notices that at least a second has already pass
<Chipaca> asac: ogra_: the problem is that services don't have something mkdir'ing /tmp/snaps for them, and so some of them do it themselves, and they don't all set the right permissions to then allow other apps to create subdirs of /tmp/snaps
<beowulf> sergiusens: so you are the ticktockman!
<Chipaca> asac: ogra_: for webdm, it's fixed on trunk i think, but not released yet
<Chipaca> asac: ogra_: snappy itself fixes it in a better way, again on trunk
<ogra_> Chipaca, yeah
<sergiusens> Chipaca: was going to release yesterday, but hell came
<sergiusens> releasing today would hide the issue for people using webdm at least
<Chipaca> sergiusens: we call him "beuno" when he's in the room
 * beuno lols but opts-in Chipaca into "experimental" features
 * Chipaca hugs beuno 
<beowulf> sergiusens: updated the mp, it gives snap icons a label if they aren't 'app' types and adds the download size to the descriptions
<beowulf> sergiusens: the next branch allows you to then sort by download size
<sergiusens> beowulf: problem is, I don't see a description or any other text
<beowulf> sergiusens: do you mean on lp, or in webdm?
<sergiusens> beowulf: there, browser was caching the css it seems
<beowulf> sergiusens: yeah, i will add some cache busting tokens to the js and css urls
<sergiusens> beowulf: the ubuntu-core installed size is whack, maybe it should be hidden?
<sergiusens> beowulf: for now at least
<beowulf> sergiusens: yeah, i can hide it or make it "n/a" or something (which i'd prefer to do for symmetry)
<beowulf> sergiusens: but i wanted you to see and fix it :)
<sergiusens> beowulf: n/a is fine
<beowulf> sergiusens: i think if we're showing ubuntu-core as an installed snap it should have the same info (and it would be useful to see that, imo)
<sergiusens> beowulf: I already said that I agreed! :-)
<beowulf> fix it fix it fix it
<sergiusens> beowulf: also, in the column view I see the installed sizes but not the download_size, but what irks me is the column alignment or lack of ;-)
<beowulf> sergiusens: i think i fix that in the next branch
<sergiusens> beowulf: ah, k
<beowulf> sergiusens: fwiw, i'm not using download size at all until i get some time to think a bit more about how the store should look and work
<kyrofa> Hey sergiusens, what is your websocket vision for webdm?
<rsalveti> morning
<sergiusens> kyrofa: that is a broad question!
<sergiusens> kyrofa: not sure if I want to do something restful over a websocket or use it as a complimentary data channel for the http/rest stuff
<dholbach> jdstrand, davidcalle just made lp:~ubuntudeveloperportal-editors/+junk/snappy-docs available which should help us keep the site up to date
<sergiusens> kyrofa: I need to discuss with beowulf as well
<Chipaca> mvo: more bad news :(
<dholbach> jdstrand, I'm looking at meta.md right now - it's where you said yesterday:
<dholbach> <jdstrand> for example: 'security-template' should be a subpoint of 'caps'
<jdstrand> dholbach: yeah, that was the one to forget :)
<dholbach> ok
<jdstrand> I was being silling on security-template and caps
<sergiusens> beowulf: it is in Details though
<jdstrand> dholbach: but notice that services doesn't have subpoints
<beowulf> sergiusens: ah
<sergiusens> beowulf: can I add one more critique, can the snappy package type be left aligned?
<dholbach> jdstrand, ok cool - looking
<kyrofa> sergiusens, Haha, I can be less broad! We have a specific use-case I wanted to discuss
<jdstrand> dholbach: same with binaries
<davidcalle> jdstrand, and binaries as well
<beowulf> sergiusens: in grid style?
<jdstrand> dholbach: I haven't reviewed all of it, but those two for sure
<sergiusens> kyrofa: want to set something up for later today?
<sergiusens> beowulf: in row style
<kyrofa> Sure! What time works best?
<sergiusens> kyrofa: 1:30 PM ART?
<beowulf> sergiusens: yes, the row isn't in good shape and i want to tidy it up, these mps are mostly about grid style though
<davidcalle> jdstrand, dholbach, I'm trying to figure out why
<zyga> ogra_: nice
<kyrofa> sergiusens, sounds great! I'll make an invite
<jdstrand> davidcalle: I thought I saw some django things mentioned in lp:snappy for the docs. does snappy/15.04 need similar changes?
<beowulf> kyrofa: sergiusens: webdm client would probably benefit more from server sent events that websockets
<jdstrand> something about spacing the indents right
<kyrofa> beowulf... how do you do that without something like websockets?
<davidcalle> jdstrand, hmm...
 * davidcalle is afk for a moment, brb
<jdstrand> if that is needed, then I imagine everything in docs/* should be looked at in both snappy and snappy/15.04
<kyrofa> beowulf, do you maintain the web interface then?
<beowulf> jdstrand: that might have been me? django vrs githubmarkdown flavours?
<mvo> Chipaca: heh, thanks! looks like its not my day today
<beowulf> kyrofa: i do yes, with sergiusens and others here
<kyrofa> beowulf, want to be included in our HO?
<sergiusens> kyrofa: yeah, add him if the time works
<Chipaca> mvo: it isn't often i suggest more tests in an MP. I feel dirty.
<jdstrand> beowulf: maybe? this is developer.ubuntu.com/snappy vs docs/*
<beowulf> jdstrand: yeah, i tried to fix some issues with list indentation which i think were caused by people using github markdown, whereas developer.u.c uses django which uses a different flavour
<jdstrand> davidcalle: also another data point-- the services/binaries thing in meta.md on the website is the same sort of issue that security.md on the website had: subpoints weren't being indented correctly. you fixed the latter on your end iirc
<jdstrand> ah
<sergiusens> Chipaca: pretty please https://code.launchpad.net/~sergiusens/webdm/metaupdate/+merge/260579
<jdstrand> davidcalle: see what beowulf said ^
<jdstrand> we should probably document that and have a linter for docs/*
<Chipaca> sergiusens: s/Ubuntu Core Snappy/Snappy Ubuntu Core/ I guess?
 * sergiusens wants to kill readme.md and add a description entry in package.yaml
<Chipaca> also, an end to the name/title/description nonsense
<sergiusens> Chipaca: hmm, I think not, I conciously wrote it like that Ubuntu Core uses Snappy and this allow device management
<Chipaca> sergiusens: +1'ed, then
<sergiusens> Chipaca: thanks
<beowulf> kyrofa: not sure what your HO is about, but sure, why not :)
<Chipaca> sergiusens: ma che grazie, go do some reviews yourself now :)
<sergiusens> beowulf: websockets and the rest of the snappy vision
 * sergiusens tries to find inspiration and write something up before then
<kyrofa> beowulf, might be at the tail end of your day, so no pressure.
<kyrofa> beowulf, I'm writing the Unity8 scope for installing/uninstalling/launching snaps
<kyrofa> beowulf, like... the local version of the webdm web interface
<dholbach> davidcalle, looks like it works with the markdown command
<beowulf> kyrofa: have you looked at sse's?
<dholbach> davidcalle, at least for the type: app / oem / framework case
<kyrofa> beowulf, no I didn't know someone else was working on this
<beowulf> kyrofa: i looked briefly a while back, websockets might be a bit overkill and are reportedly a pain to work with
<kyrofa> beowulf, oh haha-- I thought you were saying someone named sse was making a unity8 scope, but you're talking about server-sent events... sorry
<beowulf> for webdm, it's mostly responding to events, what it sends to the server is occasional and regular xhr is fine for that
<D_Cent> hi, i've built a snappy ubuntu image for the raspberry pi 2 with the image by lool and for some reason, it only shows 128 MB RAM available although there should be 1 GB - how can i adjust that?
<kyrofa> beowulf, still early in the morning for me :P
<beowulf> kyrofa: haha
<ogra_> D_Cent, that seems to be an issue with the bootloader files used on that image ...
<kyrofa> beowulf, I've not actually looked into SSEs. Let me read a little
<beowulf> kyrofa: so for install, you're mainly listening for progress or success events, but you only send one 'install' event
<kyrofa> beowulf, see, this is good! You and I need to talk more often
<beowulf> kyrofa: try this too http://chimera.labs.oreilly.com/books/1230000000545/ch16.html#EVENTSOURCE_API
<beowulf> kyrofa: downside (for me, not you, i think) is sse's are not available on IE
<D_Cent> ogra_: is there a quick way to fix it myself?
 * beowulf breaks for lunch
<kyrofa> beowulf, not to mention I'm interacting with the API from Go. DOM manipulation may not help us there
<ogra_> D_Cent, not that i know of ... there were suspicions that it works if you replace start.elf with one from an official RPi2 image
<ogra_> D_Cent, i'm tasked to look into that but wont manage to do so before monday i fear
<kyrofa> sergiusens, I sent the invite-- did I get the time right?
<D_Cent> ogra_: okay thank you :) then i'll check back on monday
<sergiusens> kyrofa: yes, it could be 1h earlier if it help beowulf
<kyrofa> beowulf, ah, but behind the scenes it just keeps the SSEs just keep the TCP socket open, huh? I can probably work with that
<kyrofa> sergiusens, alright, I'll wait to hear what beowulf thinks after his lunch and modify if necessary
<lool> D_Cent: that's a known bug; ogra is looking into it; Paolo's image doesn't have this issue; we'll soon have this fixed
<ogra_> yeah, i'll merge paolos stuff in
<davidcalle> jdstrand, beowulf, django isn't involved in the current issue, the cms only takes html and docs are converted locally before uploading
<Chipaca> mvo: sergiusens: when regenerating systemd and binary wrappers and such, i should only look at frameworks and apps, not other types of packages, yes?
<sergiusens> Chipaca: seems correct
<ogra_> do we have other types ?
<ogra_> (yet)
<sergiusens> ogra_: gadget, os and kernel
<sergiusens> ogra_: as part of yet, we have oem
<ogra_> ah, i thought they dont exist yet
<ogra_> ah, right
<davidcalle> jdstrand, you were right, snappy trunk is fine, snappy 15.04 is not (https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md VS http://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md)
<davidcalle> Indentation issue in 15.04 markdown
<jdstrand> interesting
<jdstrand> I just use the 'markdown' command to see if there are errors. clearly it is not enough
<jdstrand> or at least in the way that I invoke it
 * jdstrand notes he did not write meta.md, but imagines others are doing something similar)
<beowulf> davidcalle: i made those changes, fwiw
<davidcalle> jdstrand, for the moment, are you aware of any changes between trunk and 15.04 for this file?
<davidcalle> beowulf, the bad ones or good ones ? ;)
<beowulf> davidcalle: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md is me
<jdstrand> davidcalle: when I merged my 1 char MP yesterday, there was a conflict
<davidcalle> beowulf, ok, thanks to you we have found the issue then
<jdstrand> I can't comment on the rest of the doc (I don't really modify too often)
<beowulf> davidcalle: without the correct indentation the list wasn't appearing in the guides, which made it hard to understand
<davidcalle> beowulf, indeed
<beowulf> davidcalle: i thought it was because the markdown in django needs 4 spaces not 2
<jdstrand> beowulf: is there a tool you use to make sure it will display well in django?
<beowulf> jdstrand: i don't know of one
 * davidcalle replaces current guide with one from trunk, text is identical
<beowulf> kyrofa: sergiusens: if you could move the ho an hour forward I would be grateful :)
<kyrofa> beowulf, done!
<kyrofa> beowulf, by the way, looks like libs exist to polyfill SSEs into IE. I'm sure you're aware?
<beowulf> kyrofa: yeah, my first thought was if we had everything working in webdm with hr polling, we'd add sse support as a conditional
<beowulf> s/hr/xhr
<beowulf> don't want to poll hr
<kyrofa> beowulf, hr may not give you what you're looking for
<beowulf> kyrofa: true
<D_Cent> lool: thank you for letting me know!
<beowulf> kyrofa: have you seen the latest webdm, it has install/uninstall progress (more correctly, it's download progress in the install phase)
<kyrofa> I think so, via polling yes?
<beowulf> kyrofa: yes
<beowulf> kyrofa: is polling not a option for a scope, or not a good option?
<kyrofa> beowulf, sort of. It's a bit of a long-winded discussion, perhaps best saved for the HO :)
<beowulf> kyrofa: np
<kyrofa> beowulf, thanks for coming, it'll be a good conversation! I'm looking forward to hearing another "client"s view
<beowulf> sergiusens: hey, i created a snap with no icon, sideloaded it, and the packages api has a value for the icon attribute (name + sideloaded + version)
<beowulf> sergiusens: this means that the browser shows a broken image, rather than, if it were empty, a default image
<Chipaca> pitti: you around perchance?
<beowulf> sergiusens: i can look for a file extension in the client, but maybe this is something to fix in the api results?
<pitti> hello Chipaca
<Chipaca> pitti: hello hello! i've got systemd questions, i think
<sergiusens> beowulf: I'll fix that, care to log a bug or task?
<beowulf> sergiusens: happy to, any preference?
<sergiusens> beowulf: non at all
<Chipaca> pitti: I'm wanting to have a thing (unit?) that runs on boot that regenerates the service unit files (for frameworks and apps)
<beowulf> sergiusens: bug it is
<Chipaca> pitti: the code i have, with no extra work, will try to start the unit after creating the unit file
<Chipaca> pitti: so I'm thinking that maybe there's a way to tell systemd not to try to start things itself, given i'll be doing so manually
<beowulf> sergiusens: https://bugs.launchpad.net/webdm/+bug/1460085
<ubottu> Ubuntu bug 1460085 in webdm "snaps with no icon should not have a value for the icon attribute in the api" [Undecided,New]
<pitti> Chipaca: "things" that synthesize unit files during boot from configuration are called "generators"
<Chipaca> pitti: ok :)
<Chipaca> pitti: i have generators! woo
 * Chipaca feels all sophisticated now
<pitti> Chipaca: see http://www.freedesktop.org/wiki/Software/systemd/Generators/ ; we have a few, look at some shell ones how they work: /lib/systemd/system-generators/openvpn-generator
<pitti> Chipaca: or the one from postgresql-common
 * Chipaca reads systemd.generator
<pitti> Chipaca: essentially, they create units in /run/systemd/generator.. somewhere, which systemd will then pick up
<pitti> Chipaca: they go well together with template units (but they don't necessarily have to use them)
<Chipaca> hmmm
<Chipaca> making snappy use these will take more work
<pitti> Chipaca: yes, whether or not, or when/how to start units is entirely up to you
<pitti> Chipaca: by default, a unit never gets started -- you have to make it a requires/wants of another unit; that's part of what the generator has to do
<Chipaca> pitti: will systemd then keep it running if i manually start it?
<pitti> Chipaca: sure
<Chipaca> that is:
<elopio> ping fgimenez: I've been playing with rewriting the tests in go, like http://paste.ubuntu.com/11433366/
<elopio> now I'm not sure if we should rewrite all of them, or leave them alone and work in tests with a controlled and deterministic environment.
<elopio> like: instead of matching edge|stable, run the tests once for edge and once for stable.
<pitti> Chipaca: it's nothing too magic -- it's just an unit which is in /run (thus doesn't survive a reboot), which happesn to be generated by a program called early at boot
<elopio> what do you think?
<Chipaca> pitti: ok
<Chipaca> pitti: but i should leave the requires bits in place so if a user manually restarts a framework, apps will restart appropriately
<pitti> Chipaca: ^ I don't understand what that has to do with generators?
<Chipaca> pitti: I think I *don't* want generators
<Chipaca> pitti: because if I use generators, unless i'm misunderstanding
<pitti> Chipaca: restarting dependencies when you restart a unit is done with PartOf=
<jdstrand> beuno: interesting: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/docker/com.ubuntu.snappy.docker_1.5.0.002_all.snap - I thought all the old snaps were removed?
<Chipaca> pitti: a daemon-reload regenerates them
<pitti> Chipaca: correct
<Chipaca> pitti: which would cause snappy to restart everything
<jdstrand> beuno: https://public.apps.ubuntu.com/download/com.ubuntu.snappy/go-example-webserver/com.ubuntu.snappy.go-example-webserver_1.0.4_multi.snap too
<pitti> Chipaca: err, no, why?
<Chipaca> and then systemd will try to start them, and snappy will have started them
<Chipaca> and everything will get in a fight
<pitti> Chipaca: is snappy inotifying /run/systemd/generators/ or something such and restart stuff on file changes?
<Chipaca> pitti: so, as I said perhaps too succinctly, i'd have to do more work to do this with generators
<beuno> jdstrand, not removed, but filtered out because they don't have a release. I can remove them if needed
<pitti> (that would be crazy -- don't do that!)
<Chipaca> pitti: no! no, it's that
<Chipaca> pitti: the generation of the unit files
<Chipaca> pitti: is done by snappy
<Chipaca> pitti: and the easy way to do them
<Chipaca> pitti: is to just deactivate and then reactivate the snap
<pitti> Chipaca: a generator should *never ever* start stuff by its own -- perhaps that's the confusion?
<Chipaca> pitti: and that causes the services to be (re)started
<Chipaca> pitti: i get that
<jdstrand> beuno: I see. I don't think they have to be removed on my account (I am just fetching everything and can fix the script here), but it feels a little odd that they are in there
<jdstrand> beuno: so, up to you :)
<Chipaca> pitti: that's why i say, if i wanted to use generators i'd have to do more work
<pitti> Chipaca: hm, the only "generated" unit files that I saw were in /etc/, i. e. the units which get build as a "transformation" of the yaml
<fgimenez> elopio, i'd prefer to run the tests for each environment, with the state as controlled as possible and with concrete regex's
<pitti> Chipaca: I still think we misunderstand each other in a major way
<Chipaca> pitti: perhaps :)
<Chipaca> pitti: let me start from the top
<pitti> Chipaca: daemon-reload will not restart units
<pitti> generators don't stop/start units
<Chipaca> pitti: wait
<Chipaca> pitti: let me start over
<pitti> ack
<Chipaca> pitti: snappy has this idea of "activating" and "deactivating" snaps
<Chipaca> pitti: when it activates a snap, it creates a bunch of files, including the unit files
<Chipaca> pitti: and then the services are started
<Chipaca> pitti: this is done as part of an install, for example
<pitti> ack; but that happens in /etc/systemd, right?
<Chipaca> pitti: the old version is deactivated, the new version is activated
<Chipaca> pitti: correct
<Chipaca> pitti: that is as things are right now, and it works just fine
<Chipaca> pitti: now
<elopio> fgimenez: so, I propose to write one simple test that installs a package and confirms it works. 04_test_install_hello sounds like a good candidate for a controlled environment.
<elopio> maybe we can have two versions, one that installs it from a snap we keep in our branch, and one that installs it from the store.
<Chipaca> pitti: we're wanting to regenerate those unit files on boot (or on os update, which is essentially the same thing)
<pitti> Chipaca: oh, that'd be a rather major difference design-wise
<Chipaca> pitti: the *easiest* way to do that, is to grab a list of all "active" snaps
<Chipaca> pitti: deactivate them
<Chipaca> pitti: and then reactivate them
<pitti> Chipaca: (I mentioned the possibility of building them at boot time in Austin, using a generator and /run -- that would avoid having to write into /etc/ entirely)
<Chipaca> evereything would get generated, services started, all fine
<pitti> Chipaca: but ok, let's follow along with the /etc/ approach for now
<pitti> Chipaca: ok, understood
<fgimenez> elopio, sounds great, the one that installs the local version could run in ci too, should we check for internet access at the first stages?
<Chipaca> pitti: so, to make this work, i *think* all i've got to do is remove the bits that makes systemd start the services automatically
<beowulf> ogra_: hi, i'm trying to debug a nodejs snap, where does log output go?
<Chipaca> pitti: is that right?
<ogra_> beowulf, nowhere by default ... you can hack the start script and put some env var in place
 * ogra_ checks the var name
<pitti> Chipaca: i. e. the "systemctl start" after you install a snap, generate the unit? :-)
<pitti> Chipaca: sure; you can rewrite units in /etc/ all the time, that won't affect running ones
<elopio> fgimenez: not sure how to handle that. For the experiments we did with the click store, we passed an environment variable, like: CLICK_STORE_URL=fake
<elopio> it defaulted to being not set, which would use the real store.
<Chipaca> pitti: no, i mean the requires or whatever it was in the unit files that causes them to be started on boot
<pitti> Chipaca: if you want to do this rewriting at runtime
<Chipaca> pitti: (because snappy would be starting them as part of the 'activate' dance)
<elopio> fgimenez: maybe we can make it smarter. It will default to fake if there is no internet connection. But we should still be able to specify if we want to run the tests with or without the real store.
<Chipaca> pitti: what does "at runtime" mean?
<Chipaca> pitti: just to be clear :)
<pitti> Chipaca: right; as I said, unit changes will only become active at boot in general; you can "force" the stopping/starting of new/old units with "systemd default", but that's a rare (and not widely known) operation
<pitti> Chipaca: well, not at early boot time or image build time; i. e. "while the system is running"
<Chipaca> pitti: not early boot; this would be a snappy command run from an ad-hoc systemd .. unit? target?, once "everything else" is up (ie, i want it to run more or less where ubuntu-snappy.frameworks-pre.target is today)
<ogra_> beowulf, i think it is just DEBUG=* ... or alternatively call node with the --debug option ... then logging should go to syslog
<elopio> fgimenez: actually, we can start even more simple. We need a test to check that a snap can be installed from the .snap file. Lets write that, package it, put it to run on CI. And then we figure out how to solve the one from the store.
<pitti> Chipaca: terminology: everything is a "unit", a target (or a service) is a particular type of unit
<pitti> Chipaca: right
<Chipaca> pitti: services stick around, targets come and go?
<pitti> Chipaca: so if I got your question right: systemd by itself will not stop/start stuff automatically when you change unit files on disk; you have to manually do that
<beowulf> ogra_: thanks, will try
<Chipaca> pitti: but nothing breaks if i create unit files from a unit file
<ogra_> backjlack, ah, found it ... NODE_DEBUG=*
<pitti> Chipaca: no; services start processes, targets are a kind of "meta-service" to provide synchronization points for services or group related services; but a target doesn't start processes by itself
<ogra_> http://www.juliengilli.com/2013/05/26/Using-Node.js-NODE_DEBUG-for-fun-and-profit/
<elopio> fgimenez: do you know about debian packaging for go?
<pitti> Chipaca: in sysvinit terms: service == init.d script, target == runlevel
<fgimenez> elopio, ok
<Chipaca> pitti: gotcha
<pitti> Chipaca: right; dynamically createing unit files from an unit file is unusual and brittle, but as long as you only expect them to become active at the next boot, it's all fine
<pitti> Chipaca: brittle in the sense of "it might not do what you think it does"
<Chipaca> i'll need to test it then :)
<fgimenez> elopio, not used it before, i've seen that dh-golang manages it
<Chipaca> pitti: the proper way in any case seems to be with generators
<Chipaca> pitti: i'll try to move things around first, and then look at generators
<Chipaca> otherwise it'll be two big changes in a single branch :)
<pitti> Chipaca: right, don't mingle them
<elopio> fgimenez: yes, seems simple. But I'm missing some details, like how to overwrite the build so the tests binary gets generated too.
<elopio> we need to add go test -c somewhere in the rules.
<pitti> Chipaca: from a behavioural POV at runtime systemd-generator units in /run and snappy-written units in /etc are pretty much identical
<pitti> Chipaca: /etc is harder to upgrade, as you have to deal with possibly admin-modified files; i. e. whenever you change the YAML â unit translation, you have a lot of work
<jdstrand> beuno: weird, check this out: http://paste.ubuntu.com/11433759/
<pitti> Chipaca: units in /run are nicer in the sense that you don't have to worry about upgrade issues, they are rebuilt at every boot and you don't need to have anything in /etc/
<jdstrand> beuno: the 'name' in the json is com.ubuntu.developer.zacharyigielman.piano, but the constructed download is com.ubuntu.developer.zacharyigielman.piano.upiano_2.0_all.click
<pitti> Chipaca: but of course generators need to run at boot, and thus they slow down boot (if you do trivial operations it doesn't matter, but if you have to do expensive stuff it might)
<jdstrand> beuno: (ie, 'upiano' is in the filename but not in the json)
<pitti> Chipaca: i. e. what snappy does now to build an /etc/systemd/foo.service is by and large a generator and coudl also run at boot to output to /etc/
<fgimenez> elopio, yes, probably override_dh_auto_build will do
<jdstrand> beuno: this is the only one I've seen like this
<pitti> Chipaca: so it's a "boot speed" vs. "upgrade maintenance" tradeoff, not more, not less
<beuno> jdstrand, interesting. nessita ^^^
<Chipaca> pitti: this work is exactly to regenerate unit files because we're changing them on upgrade
<pitti> Chipaca: stopping/starting etc. is exactly theh same
<Chipaca> pitti: so yeah, /run would be a better match
<jdstrand> beuno: should I be pestering nessita with all this stuff? (I feel like I am being a bother)
<beuno> jdstrand, you are not being a bother!
<jdstrand> I don't want to bother nessita either though...
<jdstrand> hehe
<ogra_> jdstrand, you are, but we pay you for that :P
<jdstrand> haha
<beuno> jdstrand, she's an expert botheree
<jdstrand> ogra_: nice one :)
<ogra_> :)
<beuno> jdstrand, file names don't mean anything to the system
<beuno> so we might have played  fast and loose during a data migration
<nessita> reading backlog
<jdstrand> beuno: yeah, it isn't a huge deal-- it is just the one. I do a cheap check in this store-fetch script to see if it is on disk and that one kept getting downloaded over and over again
<jdstrand> just the one so far
<beowulf> ogra_: just checking, i meant where would console.log stuff go; is it not logged in snappy without NODE_DEBUG?
<ogra_> node doesnt actually write anything to stdout by default
<nessita> beuno, jdstrand we have 3 or 4 apps in sca that have an badly formatted package name, I reported these a while ago in the onlineservices list
<ogra_> so yeah, prefix your node call in your service start script with the var and you get its output in syslog
<nessita> beuno, this is ont of them, the developer will not be able to upload a new version for the same package, he needs to upload a new package with a name without a dot in it
<ogra_> or if you manually run it (which you shouldnt, since the environment will differ) prefix your command line with it
<beowulf> ogra_: but console.log is process.stdout.write, maybe i misunderstand
<beowulf> ogra_: yeah, i couldn't run it manually without setting env vars
<nessita> beuno, in summary somehow we allowed (no longer allowed) the upload of a package with a dot in the short name, which breaks all assumptions about the dot being namespace-short name splitter
<beowulf> fwiw, it's confusing to get a perl error :)
<beowulf> heartwarming, but confusing
<jdstrand> beuno, nessita: fyi, I am not at all blocked. adjust the script: WARNING:store-fetch:Skipping 'com.ubuntu.developer.zacharyigielman.piano.upiano_2.0_all.click' (already present (v2))
<jdstrand> adjusted*
<jdstrand> so I have a very cheap check and a less cheap check for existence
<zyga> I have a conceptual snappy question, can I write (where I mean can I it means "should I, from snappy POV") a snap that gives you a test/benchmark tool and then another snap that knows how to use the first one _iff_ it is present?
<zyga> or should that other snap be a framework that knows how to run tests?
<zyga> and each test can still be a snap
<zyga> or should I build a very fat snap that has everything I can think of
<zyga> and about sandboxing
<asac> zyga: snaps can talk to each other through REST right now
<zyga> do I understand right that sandboxing is applied by ubuntu-core-launcher?
<asac> but maybe just bundle everything together
<asac> yes thats the launcher that puts the processes in the right realm
<zyga> asac: can snaps see each other as installed in the FS?
<asac> of compsec/cgroup/apparmor
<ogra_> yeah, i would just ship everything in one snap
<asac> zyga: i think they cannot right now...
<asac> but try :)
<zyga> yeah, I'm about to
<zyga> trying to wrap my head around this
<zyga> I want to take three example tests (something for storage, stomething for network, something for cpu)
<zyga> and bundle them with plainbox in a snap to run
<asac> right. if those are plugins to y our benchmark tool just bundle them all in one
<zyga> plainbox is mostly easy (apart from some .so files I currently bundle that I need to get from the archive)
<asac> try deb2snap i would say if its from the archive
<zyga> but all the tests are defined as thin wrappers (just metadata needed to run it) and a reference to a 3rd party tool which is typically just shipped straight from debian
<ogra_> you wont see much of the system though ...
<zyga> yeah, I already use it
<ogra_> in your snap env
<zyga> ogra_: can I get a shell somehow with all the constraints applied (for learning?)
<asac> zyga: so hello-world.env is a script
<zyga> asac: I played with that
<asac> you could make a hello-world.bash maybe
<zyga> asac: ah :D
<zyga> good idea
<zyga> thanks
<asac> maybe could work
<asac> guess a script that just starts bash or busybox-sh
<asac> might be interesting to put in hello-world in general
<ogra_> that wont realyl ive you the info how it looks *inside* the snap i guess
<zyga> asac: is python defined to be a part of the os snap for 15.04?
<asac> ogra_: it should
<ogra_> sadly
<zyga> ogra_: why not? should it not limit everything?
<zyga> ogra_: for that process
<asac> zyga: yes python is on the image
<asac> it should work zyga ... give it a try
<zyga> asac: +1 thanks for that! (we bundle python for .click but this saves a lot of effort)
<zyga> yep, will do
<ogra_> asac, well, it will give you env output ... but if you try to read /proc/cpuinfo from commandline, will it actually block ?
<ogra_> (which it should if run as a service)
<asac> yeah it will behave like it will behave for a normal snap app
<asac> not sure if its block
<ogra_> ah, cool
<asac> or just no permission
<ogra_> right, you cant read most of 7proc
<ogra_> */proc
<asac> binaries should see the world like 99.99% same as a service
<zyga> ogra_: is version important for local dev (do I need to increment it) or can I just keep changing and reinstalling without any changes to metadata
<ogra_> version is important fgor regenerating apparmor profiles
<ogra_> if your apparmor setup never changes you dont need to bump the version
<zyga> ok, thanks
<ogra_> (i personally usually edit my snaps in /apps/<snap name>/current ... )
<ogra_> way faster turnaround time than re-packing all the time ;)
<zyga> ogra_: so just hack on the device?
<ogra_> thats what i do
<zyga> yeah, works for non-compiled code, good point
<asac> jdstrand: [ 2678.082648] audit: type=1326 audit(1432913282.515:15): auid=1000 uid=1000 gid=1000 ses=7 pid=1197 comm="sh" exe="/bin/dash" sig=31 arch=c000003e syscall=109 compat=0 ip=0x7fbc7b91bd47 code=0x0
<asac> i cannot run sh
<ogra_> once i'm done, i tar up the whole dir and dump it back into my snap dir on the PC
<zyga> ogra_: do you have something for cross compilation?
<ogra_> (there are hidden subdirs you should remove before snapping it up then)
<ogra_> zyga, nope, not yet
<ogra_> i only did nodejs, shell and perl on snappy yet
<zyga> ogra_: I love pex and it works great but one thing it does do is that it builds everything locally
<zyga> ogra_: and that means .so files inside
<ogra_> yeah
<zyga> ogra_: I'll focus on python and whatever-tests-need
<ogra_> you could look at node-snapper ...
<zyga> yeah, I got bad-system-call
 * zyga needs to read a bit about the security stuff
<ogra_> it rolls a chroot, installs nodejs and then compiles the npm modules ...
<asac> jdstrand: i cannot run busybox sh either
<zyga> ogra_: oh, cute
<ogra_> zyga, on what host system ?
<asac> jdstrand: also 106
<asac> oh its different :(
<ogra_> i see bad-system-call on utopic ... but not on trusty
<asac> 109 and 106
<zyga> ogra_: I installed it to my snappy beagle
<asac> not sure what the diff iss
<zyga> ogra_: I did the /bin/bash snap
 * asac tries to remember how to locally hack it to see what problems come next
<ogra_> ah
<asac> hmm how to find which syscall it is?
<asac> tyhicks: what is 106 and 109?
<jdstrand> asac: what is the output of 'sudo sc-logresolve /var/log/syslog'
<asac> ahhh
<asac> May 29 15:28:02 localhost kernel: [ 2678.082648] audit: type=1326 audit(1432913282.515:15): auid=1000 uid=1000 gid=1000 ses=7 pid=1197 comm="sh" exe="/bin/dash" sig=31 arch=c000003e syscall=109(setpgid) compat=0 ip=0x7fbc7b91bd47 code=0x0
<asac> May 29 15:30:25 localhost kernel: [ 2820.891522] audit: type=1326 audit(1432913425.322:16): auid=1000 uid=1000 gid=1000 ses=7 pid=1237 comm="busybox" exe="/apps/hello-world.sideload/1.0.16/bin/busybox" sig=31 arch=c000003e syscall=106(setgid) compat=0 ip=0x7f974f849c03 code=0x0
<jdstrand> scmp_sys_resolver 106 would also do it
<asac> so setgid and setpgid
<asac> is that not good?
<zyga> ogra_: snapy could use a generic environment variable to detect snapy stuff is in effect, I love SNAP_xxx but something like XDG_$appropriate=snappy would be useful for libraries
<asac> now setuid
<jdstrand> we aren't allowing them because there is nothing for them to setgid to that we can control
<asac> and now it works :)
<asac> (amd64)ubuntu@localhost:~$ hello-world.shell
<asac> BusyBox v1.22.1 (Ubuntu 1:1.22.0-9ubuntu1) built-in shell (ash)
<asac> Enter 'help' for a list of built-in commands.
<asac> $
<zyga> asac: how do you tweak policy ?
<zyga> asac: I don't have experience with that
<asac> zyga: soi just did it the hardway:
<asac> sudo vi /var/lib/snappy/seccomp/profiles/hello-world.sideload_shell_1.0.16~
<asac> and then i added those names at the end
<asac> e.g. setgid
<asac> setpgid
<asac> etc.
<asac> until it worked
<asac> but thats just for quick hacking
<zyga> ahh
<zyga> but that's generated, right?
<asac> for each binary/service there should be such profile file
<asac> yeah gets generated on install/update
<asac> from templates etc.
<jdstrand> zyga: you likely want to look at https://developer.ubuntu.com/en/snappy/guides/security-policy/
<ogra_> this is why you need to bump the version if somethin there changed
<zyga> jdstrand: I already have that open, I need to read/understand it
<zyga> I know how seccomp works
<jdstrand> ogra_: you don't need to do that for seccomp changes
<zyga> but I'm green on apparmor
<ogra_> jdstrand, no, for apparmor
<jdstrand> what are we talking aboug, seccomp or apparmor?
<ogra_> both ?
<zyga> yeah, effective, I think
<asac> for busybox sh
<asac> it was just seccomp
<jdstrand> zyga: that guide also links to https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement if you want to go deep
<asac> zyga: to answer your question:
<asac> $ ls /apps
<asac> ls: can't open '/apps': Permission denied
<asac> :P
<asac> i love the hello-world shell
<ogra_> yeah
<zyga> asac: thanks
<asac> jdstrand: you say you dont like thhe idea to have setuid etc. in seccomp profile?
<jdstrand> asac: so, regarding setuid and friends
<asac> shouldn a process be able to setuid itself?
<ogra_> setuid has friends ?
<asac> like start as root, daemonize
<jdstrand> asac: what is it setuiding to?
<asac> change to unpriviliged user?
<jdstrand> daemonize to what?
<jdstrand> right
<jdstrand> so, 'yes'
<zyga> jdstrand: so (haven't read anything yet) in one sentence, how does apparmor interact with seccomp? can it grant extra rights? (eg allow via seccomp but filter in apparmor?)
<asac> jdstrand: http://paste.ubuntu.com/11434660/
<asac> jdstrand: i dont know what busybox sh does
<jdstrand> but snappy doesn't create a user for the app to drop to
<asac> seems something similar like bash does on start :)
<mvo> jdstrand: can you help me debugging a apparmor issue? I have the following in dmesg http://paste.ubuntu.com/11434557/ for the ubuntu-core-launcher. but the /etc/apparmor.d/usr.bin.ubuntu-core-launcher has http://paste.ubuntu.com/11434609/ which should be ok, no? apparmor_parse -d -r /etc/apparmor.d/usr.bin..ubuntu-core-launcher also tells me its loaded
<asac> jdstrand: try it ... let me give you the .snap
<zyga> mvo: o/
<jdstrand> jeez too many parallel conversations
<mvo> hey zyga
<jdstrand> why am I so popular in this instant :)
<asac> jdstrand: http://people.canonical.com/~asac/tmp/hello-world_1.0.16_all.snap
<jdstrand> ok, one thing at a time
<asac> jdstrand: it has a hello-world.shell
<asac> that calls bash
<jdstrand> asac: right, I get that
<asac> or rather dash
<asac> jdstrand: i dont know how to find out ... strace on my desktop maybe?
<jdstrand> so the problem is that dash is setuid to something, but we don't know what. we could allow setuid in general but we didn't yet because apps don't know what to setuid to as it is
<jdstrand> eg
<jdstrand> apache on Ubuntu drops to www-data
<asac> jdstrand: so seems dash only does setpgid
<jdstrand> if apache were packaged as a snap, we would want to create a user for apache
<asac> busybox also setuid
<asac> jdstrand: setpgid(0, 25652)
<jdstrand> that's fine. let me get to those in a moment
<asac> getpgrp()                               = 25647
<jdstrand> I'm trying to describe the situation
<asac> http://paste.ubuntu.com/11434743/
<jdstrand> there is a trello card for creating users
<jdstrand> and there is a trello card to add seccomp arg filtering
<jdstrand> in this manner, snappy would create the user and the generate policy that allows setuid/etc only to that user
<zyga> asac: how can I follow high-level snappy developmet plans (like that thing with creating users for snappy packages)
<jdstrand> but, since we don't have the user and the seccomp arg filtering and apps don't have a way to know what to go to, we disallow setuid and friends for now
<jdstrand> ok, that is the situation
<jdstrand> asac: what group is 25652?
<asac> jdstrand: so busybox sh runus setgid and setuid to my user
<asac> so just resets to my user
<asac> not sure why
<asac> setgid(1000)                            = 0
<asac> setuid(1000)                            = 0
<asac> thats me
<jdstrand> right
<jdstrand> that is odd
<asac> let me look at the dash one
<jdstrand> or maybe it isn't-- I don't know historically why an app would do that
<jdstrand> sarnold, tyhicks: can you comment on the conversation from the last minute or two?
<asac> jdstrand: the group it sets (25652) isnt one that i have
<asac> in /etc/gropup etc.
<asac> just something random it seems
<jdstrand> right
<asac> setpgid
<asac> whats that?
<tyhicks> jdstrand: the 25652 that is passed to setpgid() is not a group id - it is a pid
<jdstrand> setpgid is for the process group
<jdstrand> right
<asac> oh
<jdstrand> tyhicks: I'm thinking we are going to need to allow those since there is no way to arg filter it
<asac> so then i dont know what setpgid does
<asac> seems to take two pids as input
<jdstrand> tyhicks: unless it is unsafe and the app needs to simply not do it (or we allow them to make an exception)
<asac> maybe setpgid is safe?
<asac> let me see if dash works with just that one
<jdstrand> that is what we are thinking about
<asac> yeah seems to be enough
<asac> for dash
<asac> busybox seems to do fun stuff
<asac> i prefer busybox, but dash is fine to start i guess :P
<asac> i dont see why setgid and setuid would be safe either though
<jdstrand> tyhicks: I'm thinking setpgid and setpgrp we might allow
<asac> think its standard unix practices to use those to drop privileges, no?
 * zyga loves old system calls, with lots of magic values and special cases 
<jdstrand> tyhicks: if they are safe
<tyhicks> jdstrand: I'm thinking about those two atm
<tyhicks> asac: regarding setuid/setgid, there is no defined user and/or group to drop privileges to
<jdstrand> when the trello cards are implemented, we can do it. however, I don't think that will fix busybox
<tyhicks> asac: we need to provide guidance to snappy developers about what users/groups they can use when they need to drop privileges
<jdstrand> because busybox is changing to the current user (ie, 1000) and that won't be what is added to the policy
<tyhicks> jdstrand: agreed
<jdstrand> tyhicks: so, they could drop to something that already exists, like 'daemon' today
<jdstrand> tyhicks: but that makes me uneasy
<jdstrand> tyhicks: for the same reasons as the nobody user-- it doesn't actually mean 'totaly unprivileged'
<jdstrand> also, if everyone drops to the same user, then the isolation isn't as great
<tyhicks> that's my biggest issue with it
<jdstrand> although, we have no DAC isolation now with root
<jdstrand> so maybe it is a stepping stone
<asac> jdstrand: so if i run the shell as root maybe it works?
<asac> hmm. guess not
<asac> so i am sure it setuid to something tht exists
<asac> isnt a snappy root process allowed to just go to any uid?
<asac> why wouldnt it?
<tyhicks> jdstrand: should the launcher define env variables for the uid and gid that the process is allowed to drop to?
<jdstrand> ie, today we create snappy-unprivileged uid/gid, then add seccomp arg filtering then we say you can change to 'snappy-unprivileged' or in the future the uid/gid we create for you
<jdstrand> tyhicks: probably
<tyhicks> by creating env variables, we can change those later on without the app caring
<jdstrand> the uid/priv dropping/seccomp arg filtering needs to be prioritized and specced out
<tyhicks> and we can also dynamically generate the appropriate seccomp filter from the launcher
<jdstrand> asac: a snappy root process is not currently allowed to go to any uid, because we disallow setuid :)
<asac> i know, but cant see why we would get so much into the way of standard unix procedure... like apache surely wants to do that etc.
<jdstrand> asac: once snappy devs define how this is supposed to work, we can let apps do stuff in a controlled manner
<asac> through setuid syscall?
<jdstrand> asac: we don't want to be in the way of unix procedure, we want to allow this
<jdstrand> it just isn't implemented yet
<asac> hmmmmmmm
 * Chipaca going AFK for a few hours. Let's call this EOW \o/
<jdstrand> yes, through setuid syscall
<asac> ah ok
<jdstrand> there are trello cards for it
<asac> i wouldnt like to see another function etc.
<asac> we should just hook into the real thing and do the right thing
<asac> ok call now
<jdstrand> the thing is, today, apache isn't going to work right because there is no postinstall that creates the user it expects
<asac> yes we need to spec out how to do per-app-users
<jdstrand> (though, with apache we happen to have www-data predefined in /etc/passwd and /etc/group, but that is beside the point)
<asac> yeah thats awful and we shouldnt rest because of that
<jdstrand> no
<jdstrand> asac: this sounds like something for our architect group to discuss and bring on board. I think it would be them, mvo, me and tyhicks at a minimum
<jdstrand> for getting the design going
<jdstrand> but maybe they are busy now
<asac> sounds like something that fits into the developer experience epic
<fgimenez> elopio, will you begin with the 04_test_install_hello changes?
<zyga> asac: could I join some calls (just as an observer to track snappy development direction better?)
<jdstrand> so the problem and need are all understood (hence trello), it is just the experience and implementation are not specced out
<jdstrand> asac: oh, but there is a mechanism for allowing extra syscalls via 'security-override'
<elopio> fgimenez: yes, I'm on that. I'll send you an email when I EOD with what I could finish.
<fgimenez> elopio, ok thx
<jdstrand> that said, we might just allow setpgid and setpgrp
<jdstrand> tyhicks: let's not forget that ^
<mvo> fgimenez, elopio: do you already have a board or anything where you capture ideas? I would like to put "ensure services keep runing after a upgrade" on it :) (i.e. extend the current upgrade test to check that a intalled webserver is still listening)
<tyhicks> jdstrand: apps could attempt to do devious things with setpgid()/setpgrp(), such as placing themselves in a process group of a different app
<mvo> jdstrand: did you see my apparmor question from earlier? not rushing you, I noticed that you are busy, just wanted to ask if I should re-post the pastebins :)
<jdstrand> mvo: oh sorry, I did, then was trying to deal with one conversation at a time
<mvo> jdstrand: yeah, totaly fine, just ping me when you have a moment :)
<tyhicks> jdstrand: that could result in some unexpected behavior such as waitpid(0, ...) returning when unexecpted processes exit
<fgimenez> mvo, not yet afaik, it would be nice :)
<tyhicks> jdstrand: that might be solveable by having the launcher call setsid(2) before exec'ing a snap executable but I'd have to look into it more (would be best if someone that works on init systems told us what we need to do)
<jdstrand> mvo: the rules are ok. are you sure they are in effect?
<jdstrand> mvo: ie, did you run 'sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher' ?
<jdstrand> tyhicks: the init systems question kinda went by me-- perhaps ask slangasek?
<mvo> jdstrand: I did, is there some sort of caching or anything? I can run apparmor_parser -r -d for you to double check
<jdstrand> mvo: there is caching, but -r will ignore it
<jdstrand> mvo: also, '-d' I don't think actually loads it into the kernel
<mvo> jdstrand: http://paste.ubuntu.com/11435160 is the debug output from the loading
<mvo> jdstrand: oh, hold on a sec, let me re-run without -d then
<mvo> jdstrand: woah, see, I knew why I needed to talk to you, thanks!
<jdstrand> ah, good!
<jdstrand> I had to look at the man page for -d and saw it didn't load
<mvo> jdstrand: how does the caching work? i.e. does it compare files? I have a image here from rick that seems to be broken
<jdstrand> mvo: the launcher is a system profile, so its cache file is in /etc/apparmor.d/cache
<mvo> jdstrand: i.e. the apparmor.d/usr.bin.ubuntu-core-launcher looks correct but when I ran it it seems to apply a older config ? I will debug further now that I know about -d
<mvo> jdstrand: great, thanks a bunch. is there a way to "disassemble" the cache? as a way to compare that with the real file?
<jdstrand> if you look at rick's image, do stat /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher /etc/apparmor.d/usr.bin.ubuntu-core-launcher
<jdstrand> mvo: I don't think so, but will refer you to jjohansen here
<mvo> jdstrand: thanks, thats very helpful, I dig deeper
<jdstrand> mvo: so things to keep in mind: if the cache is older than the profile (mtime), then the apparmor boot script will regenerate the cache
<jdstrand> mvo: apparmor_parser -r does not consult the cache. you can use apparmor_parser -r -B /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher to load the cache
<mvo> jdstrand: thanks again
<jdstrand> jjohansen: actually, does apparmor_parser -r /path/to/profile consult the cache? the man page suggests it but I never thought it did
<jdstrand> mvo: so, you can use apparmor_parser -r -B /etc/apparmor.d/cache/usr.bin.ubuntu-core-launcher for sure to load the cache, and apparmor_parser -r --skip-cache /etc/apparmor.d/usr.bin.ubuntu-core-launcher to not load from cache for sure
<mvo> jdstrand: its the cache
<mvo> jdstrand: --skip-cache makes it work, -r alone is not enough
<jdstrand> mvo: also something to keep in mind, system image generation tries to precompile the cache so it doesn'
<jdstrand> t have to be done on first boot
<mvo> jdstrand: let me try again from a freshly booted rick image just to be sure I'm not running into side-effects
<jdstrand> at least on touch. I imagine we are doing the same on snappy (rsalveti could possibly confirm)
<jdstrand> mvo: if the cache file on the disk is newer than the profile but still has the old profile rules, then suggests something is wrong in the image generation process
<mvo> jdstrand: yes, that or something with the upgrade and the timestamps during the upgrade
<jdstrand> yes
<mvo> jdstrand: yep, fresh boot (qemu with --snapshot) pastebinit fails, apparmor_parser --skip-cache -r makes it work. I file a bug. thanks again for your help
<jdstrand> mvo: ok, 'cool'
<jdstrand> mvo: note this from touch: http://paste.ubuntu.com/11435517/
<mvo> jdstrand: heh :)
<jdstrand> mvo: just for context on the types of things to be thinking about with timestamps and the cache
<jdstrand> obviously, the launcher isn't a click
<jdstrand> and the directories are different
<jdstrand> but timestamps are pretty darn critical when dealing with cache files
<mvo> jdstrand: oh absolutely
<jdstrand> tyhicks: so, I'm conflicted on the setpgid/setpgrp. on the one hand, I totally hear what you're saying. on the other hand, it seems like something pretty common: http://paste.ubuntu.com/11435621/
<jdstrand> tyhicks: I'm leaning toward allowing it and then we file a bug to make it safer
<jdstrand> tyhicks: I'm not sure how we can make it safer... there are LSM hooks for task_setpgid. but clearly, seccomp won't be enough
<mvo> jjohansen: if you could give me a hint if its possible to get information out of a cache apparmor profile, that would be great! I suspect we have a bug in snappy (upgrade or image creation) when they get out of sync but to gather more data about the problem I need to figure out more about the content of the cached one
<jdstrand> mvo: that is where you need jjohansen
<mvo> yeah :)
<mvo> rickspencer3: here is your bug https://bugs.launchpad.net/snappy/+bug/1460152 - I was wrong about the permissions, I was looking at the wrong place, its really a issue with upgrade or image generation and that results in a stale apparmor cache :/
<ubottu> Ubuntu bug 1460152 in Snappy "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New]
<tyhicks> jdstrand: they're probably harmless to allow
<jdstrand> tyhicks: ok, then I'll allow them. if you feel more should be done with mediation, let's open a feature bug and add to backlog
<jdstrand> tyhicks: sound ok?
<tyhicks> jdstrand: ok - i'll think about if there's anything possible to do
<jdstrand> great, thanks
<jdstrand> I guess I should say 'great'
<jdstrand> asac: ok, uploaded ubuntu-core-security to wily for setpgid/setpgrp, so it should hit rolling/edge later today. 15.04 will get this as part of the SRU
<asac> jdstrand: ok, when will that hit?
<asac> the SRU? any news on the updated image schedule from rsalveti ?
<jdstrand> asac: not beyond what was discussed on wed. this is on the non-critical part currently
<jdstrand> ie, the stable promotion won't block on this being missing (currently, we can change that)
<zyga> jdstrand: how does ubuntu snappy core sru work?
<jdstrand> zyga: the same as the normal SRU process will get the updates into edge. then there is a manual process currently being defined by the snappy core team (ie, rsalveti) for promotion from edge -> beta -> alpha -> stable
<jdstrand> zyga: you might read this for background: https://developer.ubuntu.com/en/snappy/guides/channels/
<jdstrand> oh, I forgot 'rc' in my little ascii flow
 * rsalveti reads backlog
<zyga> jdstrand: thanks, I ask because currently the cert team is involved in the sru process for normal ubuntu
<zyga> jdstrand: and we're not (at least not yet) doing that for snappy
<jdstrand> zyga: ah, you might also be interested in this bit I am working on for the security team: https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#system-image_updates_.28DRAFT.29
<sarnold> jdstrand: I think you got your answer, but we definitely need to allow setpgid, setpgrp, setsid, if we want shell job control to work
<jdstrand> sarnold: ack. we already allowed setsid and the other two I just fixed
<jdstrand> sarnold: thanks! :)
<sarnold> jdstrand: woot :)
<rsalveti> mvo: jdstrand: apparmor cache is actually done as part of livecd-rootfs
<rsalveti> not in system-image, so let me check if we're actually running a similar script in there
<rsalveti> I remember we had super weird issues on touch when the rules were bind-mounted from the device tarball
<rsalveti> as that wasn't causing the cache to be regenerated (even when the timestamp was correct)
<rsalveti> which is why we now have a package in the archive with the device rules
<rsalveti> jdstrand: mvo: how we're pre-compiling the cache on touch http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/90-precompile-apparmor-policies.chroot
<ogra_> rsalveti, mvo, oh, i meant to ask about this, a big chunk of the hook scripts in the livecd-rootfs tree in core are not executable ...
 * ogra_ was wondering if that is on purpose to not have them run
<rsalveti> ogra_: remember we also have our own version in our ppa
<rsalveti> https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> of livecd-rootfs ?
<rsalveti> yeah
<ogra_> how does that work ?
<rsalveti> this ppa gets used when building the image
<ogra_> the buildd doesnt know the PPA when it install that package
<ogra_> *installs
<ogra_> only later once it created the build chroot ... or did that change
<rsalveti> asac: jdstrand: right, can you let me know about the bug number for it once you start the SRU process?
<rsalveti> asac: jdstrand: my goal is to have our first stable update during next week
<ogra_> also that feels pretty wrong ... we already have our own hooks dir, why do we need anything else forked from the main livecd-rootfs
<rsalveti> created a short meeting on monday to make sure we're not missing anything
<rsalveti> ogra_: mvo should know more
<ogra_> k
<rsalveti> one reason could be because of the freeze
<ogra_> ah ... didnt think of that
<mvo> rsalveti: hm, indeed aparmor.d/cache is a rw mount, I wonder why we have that, I assumed it would all be done on image generation time
<sergiusens> ogra_: because of system-image (we didn't package fork in time)
<mvo> ogra_: this sounds like a accident, are they really not run?
<rsalveti> mvo: right, on touch we create it as part of the image, then we copy it over at a rw path and bind-mount during boot time
<ogra_> mvo, i'm not sure, they all have a hashbang though
<rsalveti> we don't yet support pre-cached content during updates
<mvo> ok
<ogra_> i dont think they are piped into some shell call in live-build, but i might be wrong
<rsalveti> log should tell
<rsalveti> build log
<rsalveti> guess only if printing stuff though
<ogra_> yeah, most dont print anythin
<ogra_> g
<mvo> I can reproduce the  tempdir issue via stable->edge 15.04 update :/
<ogra_> damn
<asac> nice
<asac> mvo: well done
<asac> its one of those things that is dangerous i tell you
<rsalveti> yeah
<rsalveti> if the right apparmor cache is not in place, we can make the device useless
 * asac super worried
<ogra_> rsalveti, mvo all fine, seems they get executed even without executable bit set
<asac> that we dont have the upgrade under control fully
 * ogra_ sees + echo I: Remove unneeded files from /usr/share/doc 
<ogra_> I: Remove unneeded files from /usr/share/doc
<ogra_> which is non executable in the code
<elopio> mvo: we are using your document of better tests in the etherpad.
<ogra_> asac, we have a similar issue on the phone with /var/log ownership that nobody can explain
<ogra_> (being flipped after some upgrades ... not reliably reproducable ... )
<rsalveti> at least mvo found a way to reproduce it
<rsalveti> it seems :-)
<ogra_> i wonder if we face some core bug in system-image
<jdstrand> rsalveti: I'm only putting this out there as an option that you are free to ignore-- there are only 3 system profiles on core. pregenerated them doesn't buy us much on first boot-- about 2.2 seconds on bbb
<jdstrand> rsalveti: maybe on upgrade hook could simply rm -f /etc/apparmor.d/cache/*
<rsalveti> yeah, that sounds easy enough
<ogra_> wont that result in long boots ?
<rsalveti> just the first boot after install/upgrade
<rsalveti> but as it's just 3 system profiles
<rsalveti> not tons of click packages
<ogra_> ah, not apps ... k
<jdstrand> ogra_: 13:12 < jdstrand> rsalveti: I'm only putting this out there as an option that you are free to ignore-- there are only 3 system profiles on core. pregenerated them doesn't buy us much on first boot-- about 2.2 seconds on bbb
<jdstrand> right
<rsalveti> mvo: ^^
<ogra_> 2sec are bearable :)
<jdstrand> and it is only on boot after upgrade
<ogra_> yeah
<jdstrand> the first boot after upgrade
<jdstrand> rsalveti: could the a/b partitioning be getting in the way?
<jdstrand> rsalveti: ie, are the writable bind mounted areas a/b'd as well?
<rsalveti> that's an interesting question
 * ogra_ thought not 
<ogra_> we only have one writable and a and b
<jdstrand> rsalveti: eg, if a has old cache and old profile and we reboot into b with new profile, do we get a's old cache file?
<rsalveti> yeah, are we sharing the same writable path for the cache?
<rsalveti> if so, then, hmm
<jdstrand> idk
<ogra_> most likely
<rsalveti> not good
<ogra_> since we only have one writable partition
<rsalveti> ogra_: can you confirm?
<ogra_> yeah, i think i can
<ogra_> three partitions ... two readonly, one writable ...
<ogra_> writable gets mounted in initrd by label, no matter what readonly part is active
<ogra_> and /etc/apparmor.d/cache is in /etc/system-image/writable-paths
<ogra_> i guess we would want an a/b scheme there
<ogra_> in a subdir or some such
<ogra_> or via a bind mount that hides the real path
<jdstrand> ok, so I'm much more convinced that for now, we rm -f /etc/apparmor.d/cache/*
<jdstrand> cause the alternative would be too risky for sru
<jdstrand> we need to implement the alternative for touch anyway
<jdstrand> s/touch/personal/
<beowulf> sergiusens: are you waiting for something from me wrt my 2 reviews? i suspect you are but i've forgotten
<ogra_> jdstrand, +1
<sergiusens> beowulf: I was debugging something, let me grab those MPs now
<beowulf> sergiusens: sorry, there's no rush, just checking
<rsalveti> ogra_: jdstrand: yeah, let's just do this
<rsalveti> sharing same writable path can be indeed dangerous
<rsalveti> it's usually desirable
<rsalveti> but we need to be careful
<ogra_> yep
<ogra_> sounds like quite some research project to find out which other files are bound to the readonly version
<ogra_> s/are/should be/
<rsalveti> yup, will create a task/story for that in our board, so we don't forget
<rsalveti> actually, will just add as part of the 15.04.1 one
<rsalveti> since if there are additional bugs, we need to fix for the next release
<jdstrand> so, thinking about it-- a's cache timestamp should be older than b's profile in the normal case. but, if the cache somehow got invalidated/regenerated it is possible for it to be newer than what would be in 'b'
<rsalveti> what is the reference used by fixrtc?
<ogra_> last mount time
<rsalveti> right, but which mount partition?
<ogra_> you added another one with a recent patch
<ogra_> oh, good question
<ogra_> hmm
<ogra_> root= or systempart= is what it accepts
<rsalveti> right
<ogra_> so root in our case
<ogra_> BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=LABEL=system-a ro init=/lib/systemd/systemd console=tty1 console=ttyS0 panic=-1
<ogra_> that is what i see on my kvm image here
<rsalveti> so in theory it would still be correct
<ogra_> ah, and you added "creation date" as fallback
<rsalveti> unless we have a fallback I guess
<ogra_> in case it was never mounted
<rsalveti> right
<rsalveti> fallback/rollback
<ogra_> well
<rsalveti> so if you flash b, boot b, regenerate the cache, and then aborts, it will boot a again
<rsalveti> but the cache will be invalid
<rsalveti> from the a perspective
<rsalveti> or better, could be
<ogra_> i was just thinking about the clock .... if you switch from a to b but b was never mounted you might go backwards in time
<rsalveti> so yeah, sharing rw for apparmor is a bad idea
<rsalveti> ogra_: yup :-)
<ogra_> (with fixrtc)
<ogra_> oh
<ogra_> but you mount b to flash it :)
<ogra_> all fine then i guess
<rsalveti> that's the hope
<ogra_> even under the clock thats set for a ... so they shouldnt diverge to much
<rsalveti> right
<jdstrand> so, /var/cache/apparmor (the one for apps) is setup the same way
<rsalveti> alright, updated the bug
<jdstrand> but, for now I think it will handle things ok
<jdstrand> well, let me think
<jdstrand> actually, the mechanism it uses for deciding whether to regenerate the profiles is not taking a/b into account
<jdstrand> the mechanism it currently uses happens to really be poor and I wouldn't mind it being redone
<jdstrand> but I was going to replicate the mechanism for the seccomp policy regeneration work that I will be starting soon
<ogra_> OOOH !
 * ogra_ just hit ctrl-r in webdm 
<ogra_> shiny !
<rsalveti> :-)
<rsalveti> sergiusens just uploaded a new version it seems
<jdstrand> alright, I'll think about it-- I may have questions/ask for help in designing the implementation
<rsalveti> jdstrand: sounds good
<sergiusens> rsalveti: ogra_ yes, but the core problem I mentioned isn't solved, but I could easily replicate with 0.6.1
 * sergiusens needs to read the core launcher code
<rsalveti> sergiusens: why not?
<sergiusens> rsalveti: it's not a webdm afaik
<rsalveti> oh, right, isn't this the apparmor issue we're just discussing?
<rsalveti> https://bugs.launchpad.net/snappy/+bug/1460152
<ubottu> Ubuntu bug 1460152 in Snappy 15.04 "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New]
 * rsalveti still trying to understand the issues we currently have
<sergiusens> rsalveti: I don't see denials; I think it's more of running in namespaces
<rsalveti> hm, ok
<sergiusens> rsalveti: I don't get any apparmor denials nor seccomp issues, but the runtime thinks it's on some soft float hw env
<sergiusens> jdstrand: do you have a bbb, maybe it will pop up easy to you :-)
<rsalveti> hm, weird
<ogra_> snake !!
<rsalveti> is this only happening on bbb?
<ogra_> (in the snap store)
<rsalveti> hahaha
<mvo> snake?woah!
<sergiusens> rsalveti: well !amd64
 * mvo needsmorespaces
<ogra_> heh
<jdstrand> sergiusens: I just installed webdm on my bbb
<jdstrand> I am rebooting it
<jdstrand> give me a second to figure out what channel I am on, etc
<sergiusens> jdstrand: right, so my issue is, with the core launcher, webdm fails in weird ways, running from cli works just fine
<jdstrand> ubuntu-core/15.04/edge
<jdstrand> r60
<jdstrand> sergiusens: does that have what is needed to reproduce?
<sergiusens> jdstrand: http://paste.ubuntu.com/11434444/ the last three lines is what I see with no denials whatsoever; just try and install a package
<sergiusens> I also logged a but about the core launcher taking ver arg[0]
<ogra_> uuuh
<jdstrand> runtime: this CPU has no floating point hardware, so it cannot run
<jdstrand> this GOARM=6 binary. Recompile using GOARM=5.
<jdstrand> what is that??
<sergiusens> jdstrand: yeah, that only happens when running under the launcher
<sergiusens> jdstrand: 6, 5 are armv[5,6,7]
<ogra_> i guess it nneeds some info from /proc ?
<jdstrand> is this armhf vs armel?
<sergiusens> ogra_: right, there are no denials that I see of that make this obvious
<jdstrand> let me look at the profile
<sergiusens> jdstrand: https://code.google.com/p/go-wiki/wiki/GoArm
<mvo> ok, I think the problem with the apparmor is understood now, I updated the description of the bugreport in https://bugs.launchpad.net/snappy/+bug/146015 - I wonder if apparmor_parser could simply set the mtime of the cached file to the mtime of the source that was used to generate the cache, that would make this kind of issue go away
<ubottu> Ubuntu bug 146015 in Moblin Kernel "NTFS module can't be inserted" [High,Won't fix]
<rsalveti> maybe GOARM=5 is the default?
<mvo> eh https://bugs.launchpad.net/snappy/+bug/1460152
<ubottu> Ubuntu bug 1460152 in Snappy 15.04 "(sometimes?) becomes confused about apparmor rules for ubuntu-core-launcher" [Undecided,New]
<jdstrand> sergiusens: http://paste.ubuntu.com/11437590/
<sergiusens> jdstrand: are you using u-d-f from beta?
<jdstrand> sergiusens: I mintioned I am on ubuntu-core/15.04/edge r60
<jdstrand> mentioned
<jdstrand> I just ssh'd in then ran that command
<ogra_> sergiusens, hmm, whats the reason we build with GOARM=6 instead of 7 ?
<sergiusens> jdstrand: yeah, I need to know what u-d-f you used, I bet you have /oem/beagleblack.canonical instead of /oem/beagleblack
<sergiusens> ogra_: it's using 7
<sergiusens> ogra_: the message is completely bogus
<jdstrand> I have /oem/beagleblack.canonical
<ogra_> it says 6 above
<ogra_> ah
<jdstrand> I don't know what udf I used-- I generated the image weeks ago
<rsalveti> ogra_: I believe it's kind of what you said
<rsalveti> it needs to query the system for the right support
<ogra_> yeah
<rsalveti> and that might be br0k3n
<ogra_> i forgot where exactly that info lives
<rsalveti> i think it's /proc/cpuinfo
<rsalveti> isn't i?
<ogra_> something with /proc.../axfr
<rsalveti> right
<ogra_> or some such
<ogra_> it was some letter combo
<rsalveti> might be easy to just check go's code
<sergiusens> jdstrand: so quick hack to get going-> mkdir bak; sudo mv /oem/beagleblack.canonical bak
<sergiusens> jdstrand: and restart webdm; are you using a prerelease image by any chance?
 * ogra_ thought it would be easy by just using the right google search terms :P ... but i'm not lucky 
<jdstrand> sergiusens: prerelease image-- what do you mean? I am on ubuntu-core/15.04/edge r60, just booted into it
<rsalveti> 206 else ifeq ($(DEB_HOST_ARCH), armhf)
<rsalveti> 207     GOARM := 6
<rsalveti> we're actually building with goarm 6
<jdstrand> sergiusens: moving to bak and doing 'sudo systemctl start webdm_snappyd_0.7.service', it started
<jdstrand> $ ps auxww|grep webdm
<jdstrand> root       862  1.6  1.4 838992  7120 ?        Ssl  19:03   0:00 /apps/webdm/0.7/bin/arm-linux-gnueabihf/snappyd
<sergiusens> jdstrand: great, there's a bad strain somewhere and I need to find it, you are the second person today that has a bad image
<jdstrand> I can connect to port 4200
<rsalveti> it checks via syscall it seems
<rsalveti> so it could be seccomp
<jdstrand> sergiusens: I can say that even though I just rebooted, I am getting told I need to reboot again
<jdstrand> rsalveti: what syscall?
<rsalveti> http://paste.ubuntu.com/11437793/
<jdstrand> also, we would see a seccomp denial
<rsalveti> http://paste.ubuntu.com/11437796/
<rsalveti> the code the checks for the right arm support
<sergiusens> there is no seccomp denial though
<sergiusens> but, it also only fails when running under it
<jdstrand> seccomp only supports EABI iirc
<jdstrand> sergiusens: it isn't failing here now
<sergiusens> jdstrand: you can install from the ui with no failure?
<rsalveti> 	// do an EABI syscall
<rsalveti> 	MOVW	$20, R7 // sys_getpid
<rsalveti> yeah, that's the eabi syscall it does
<sergiusens> rsalveti: right, we are using GOARM=7 fwiw
<jdstrand> I think it is a nice touch that Chipaca's 8nzc1x4iim2xj1g2ul64 is at the top of the list
<rsalveti> sergiusens: debian/rules is only exporting GOARM=6
<sergiusens> rsalveti: and it works without confinement applied
<sergiusens> rsalveti: webdm is not a deb
<rsalveti> right, was checking for golang-go itself
<ogra_> trapped :P
<rsalveti> not sure how that would be connected to that
<jdstrand> sergiusens: no: http://paste.ubuntu.com/11437836/
<rsalveti> when building another project that uses go
<sergiusens> jdstrand: yeah, same error...
<jdstrand> I still have the old libseccomp2... 2.1.1-1ubuntu1~ppa1
<sergiusens> jdstrand: if you stop webdm and go to /apps/webdm/0.7 and run it manually it all works fine
<jdstrand> sergiusens: what version of libseccomp2 do you have?
<sergiusens> libseccomp2:armhf
<sergiusens> same
<jdstrand> why is this image telling me to reboot and not rebooting into the updated system?
<sergiusens> jdstrand: snappy list --updates
<sergiusens> jdstrand: cat /boot/uboot/snappy-system.txt | pastebinit.*
<mvo> thanks sergiusens
<jdstrand> sergiusens: right, but autopilot is setting shutdown
<sergiusens> mvo: I can't know for sure for what! :-)
<mvo> sergiusens: I'm sure you know plenty of good reasons
<mvo> sergiusens: but mostly for debugging why its showing that it needs to reboot when it does not
<mvo> I thought we had this fixed *loooong* ago :/
<jdstrand> sergiusens: http://paste.ubuntu.com/11437898/
<jdstrand> I'm doing snappy update manually now
<sergiusens> mvo: me too, but I suspect jdstrand is on some weird image ;-)
<mvo> we also need uEnv.txt I think
<sergiusens> mvo: boot logic is all in snappy-system.txt, uEnv.txt is just for enablement
<mvo> silly me, indeed
<sergiusens> jdstrand: what about snappy list --updates ?
<jdstrand> sergiusens: it said I needed to update to 69
<jdstrand> I guess I need to reflash it
<jdstrand> sergiusens: manually upgrading libseccomp didn't help
<jdstrand> sergiusens: so, webdm isn't running under seccomp:
<jdstrand> $ cat /var/lib/snappy/seccomp/profiles/webdm_snappyd_0.7
<jdstrand> @unrestricted
<nothal> jdstrand: No such command!
<ogra_> lol
<jdstrand> or at least, it shouldn't be
<sergiusens> jdstrand: right, so could it be a kernel namespace issue? I'm just throwing out ideas, this isn't my domain at all
<rsalveti> how could the hwcaps be wrong
<ogra_> they arent wrong, you just cant access them
<rsalveti> right, I mean, wrong from go's perspective
<sergiusens> rsalveti: ogra_ they aren't wrong as this works fine when launched without the core launcher
<ogra_> yeah, i think seccomp just blocks the syscall
<rsalveti> sure, it's what ogra said, it probably just can't access it
<jdstrand> sergiusens: we aren't using namespaces to any significant degree yet-- there is the new launcher work that adds the bit for /tmp
<sergiusens> ogra_: as jdstrand reminded me, it is @unrestricted
<jdstrand> but that shouldn't be on my image
<ogra_> hmm
<jdstrand> seccomp would kill the process and log a denial if it was it. however, there is no denial and it is @unrestricted
<ogra_> and does @unrestricted also actually mean unrestricted ? ... unconfined on the phone doesnt necessarily mean completely unrestricted
<jdstrand> sergiusens: fyi, I tried adding "GOARM=7" to the service file manually and it didn't make a different
<jdstrand> difference
<jdstrand> let me try something else
<sergiusens> jdstrand: that's a compile time thing
<sergiusens> jdstrand: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/build.sh#L37
<jdstrand> sergiusens: ok, I took the launcher out of it by using: http://paste.ubuntu.com/11438058/
<jdstrand> now, I will take AppArmor out of it
<rsalveti> it finds the hwcaps by using the elf auxiliary vectors
<rsalveti> http://articles.manugarg.com/aboutelfauxiliaryvectors.html
<ogra_> ah
<ogra_> it was /proc/$pid/auxv
<rsalveti> it can still use that
<rsalveti> http://ffmpeg.org/doxygen/trunk/arm_2cpu_8c_source.html
<rsalveti> like ffmpeg
<rsalveti> but you can also just use the elf auxiliary vectors
<rsalveti> https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures
<rsalveti> explains it nicely
<jdstrand> ok, if I use this, it worked: http://paste.ubuntu.com/11438101/
<jdstrand> let me try one more thing
<sergiusens> jdstrand: so no apparmor and no core launcher work
<sergiusens> jdstrand: leaving apparmor and using your ExecStart also works fine
<jdstrand> sergiusens: I'm ruling out the launcher now
<sergiusens> but I guess core launcher attaches the apparmor profile
<jdstrand> it does
<jdstrand> I am using some hackery to test with unconfned
<jdstrand> I can say that there are no explicit deny rules in the webdm profile
<jdstrand> if this comes done to kernel rate limiting I am going to strangle someone
<rsalveti> LD_SHOW_AUXV=1 exports the hwcap
 * jdstrand shakes fist at kernel rate limiting
<rsalveti> is there a way to export that when running it and get the output?
<sergiusens> heh, right, forgot about the rate limiting issues when we started on the phone
<sergiusens> rsalveti: yeh, in the systemd unit
 * sergiusens tries
<ogra_> in the environment of the systemd unit
<jdstrand> sergiusens: fyi, sergiusens unsurprisingly, this worked too: http://paste.ubuntu.com/11438162/ (after I created /var/lib/snappy/seccomp/profiles/unconfined)
<sergiusens> jdstrand: so unconfined seccomp and no apparmor works fine with the core launcher
<jdstrand> sergiusens: yes, the launcher is ruled out
<sergiusens> rsalveti: btw AT_HWCAP:        half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
<sergiusens> rsalveti: this env var breaks the magic bin thing though ;-)
<rsalveti> sergiusens: yeah, that's correct
<rsalveti> it's looking for vfpv3
<rsalveti> and vfp
<rsalveti> now why the hell go is not able to find that from the elf auxiliary vectors
<sergiusens> rsalveti: it is
<sergiusens> rsalveti: as I said, when running without our confinement it works fine (seccomp/u-c-l/apparmor)
<sergiusens> although u-c-l and seccomp have been discarded as the problem
<jdstrand> ok, so I disabled rate limiting
<jdstrand> sudo sysctl -w kernel.printk_ratelimit=0
<sergiusens> ah, that's how it was done!
<sergiusens> jdstrand: I don't see any denials here still
 * sergiusens imagine I used proper grammar
<sergiusens> meh
<sergiusens> friday
<Zwan> Hi
<Zwan> this seems like a good place to get some info about Snappy.
<Zwan> Don't worry, I'm not seeking tech support.
<Zwan> Is Snappy something that's going to completely replace apt-get in future releases or is it just going to be part of a sideproject thing?
<sergiusens> Zwan: ubuntu core will use snappy to drive it's package management as one of the things it does
<sergiusens> jdstrand: do you think something in the profile itself it wrong and the parser just let's it through?
<Zwan> Ah, okay. So average Ubuntu desktop people won't have to worry about losing apt-get...
<Zwan> Whew.
<jdstrand> ok, I ruled out systemd
<jdstrand> sergiusens: unlikely. the parser would bail if it couldn't compile it
<jdstrand> there could be a parser bug, but let me keep trying some things
<jdstrand> I found the issue
<jdstrand> sergiusens: ^
<jdstrand>   # snappy unpack
<jdstrand> #  /usr/bin/snappy                                                 Uxr,
<jdstrand>   /usr/bin/snappy                                                 uxr,
<sergiusens> oh man
<sergiusens> s/u/U/
<sergiusens> jdstrand: right?
 * sergiusens does a bzr log/blame to figure out when this changed
<jdstrand> sergiusens: see man apparmor.d 'ux - Unconfined execute mode'
<jdstrand> something is getting scrubbed out that snappy needs
<jdstrand> and ux prevents that from happening
<sergiusens> jdstrand: hmm, I wonder how this workds on kvm though
<sergiusens> as in amd64
<rsalveti> well, no cpu type check
<sergiusens> right
<rsalveti> it wouldn't cause any issue there
<sergiusens> right as well
<rsalveti> love typos
<jdstrand> jjohansen may be able to comment, but the secure exec stuff is used (the same as for setuid binaries) and perhaps there is a difference on arm and amd64 kernels
<rsalveti> but that was done on purpose I guess
<sergiusens> rsalveti: it was U on purpose though
<jjohansen> jdstrand: that will only get logged if debug is enabled, basically you will get a dmesg that the environment is being scrubbed on exec
<jdstrand> oh, interesting
<jdstrand> let me try that
<jdstrand> I hadn't gotten to setting debug=1 yet
<jjohansen> so secure exec clears out a whole bunch of dangerous environment stuff, that ld uses and can be used to exploit the system
<rsalveti> right
<jjohansen> not having those cleared is a BIG red flag
<rsalveti> that might effect the elf auxiliary vectors?
<jjohansen> yes
<jdstrand> it is interesting that this is a go, static executable
<rsalveti> there you go then
<jjohansen> rsalveti: apparmor is not in control of what gets cleared, it just sets the flag and then the loader associated with the application actually does the env scrubbing, so normally its a glibc thing but it could be something else depending on the executable
<jjohansen> jdstrand: even static executables have their startup loader stuff that is linked in
<rsalveti> right
<rsalveti> glad we know what is the problem now
<jdstrand> so, with debug=1, I'm not seeing what is scrubbed, just that stuff is scrubbed
<jdstrand> May 29 20:29:59 localhost kernel: [ 6004.539676] AppArmor: scrubbing environment variables for /bin/mountpoint profile=unconfined
<jdstrand> we do know the problem and the shorterm fix
<rsalveti> great
<rsalveti> ship it
<sergiusens> jdstrand: I guess I see it on arm and not amd64 as the binary is cross compiled for arm and locally (arch) compiled for amd64
<jdstrand> but I wonder if this is going to bite us again down the line for normal or framework apps
<jdstrand> granted, we use ix for apps
<rsalveti> sergiusens: shouldn't make a difference
<jdstrand> and Ux is a big red flag too
<rsalveti> it's just that amd64 is not checking for the same thing
<jdstrand> so we wouldn't normally allow that
<jdstrand> I can see frameworks (and even webdm) using Cx though
<sergiusens> jdstrand: this is legacy to what we did in capetown in december though
<sergiusens> jdstrand: any alternative? I don't mind doing the right thing now
<jdstrand> sergiusens: I'm not sure what you mean by legacy. webdm is fork/execing /usr/bin/snappy
<sergiusens> jdstrand: legacy as this profile piece was written when we were in capetown
<jjohansen> jdstrand: Ux, Cx, Px are the "safe" environment scrubbing variants, its ux, cx, px that don't scrub the env
<jdstrand> sure, I get that
<jdstrand> but it is still applicable :)
<jdstrand> jjohansen: yes
<jjohansen> so it looks the opposite this is failing because something isn't getting scrubbed out
<sergiusens> jdstrand: in any case once we move to the rest api being on snappy itself, we only need to worry about connecting to a unix socket
<jjohansen> (01:21:45 PM) jdstrand: #  /usr/bin/snappy                                                 Uxr,
<jjohansen> (01:21:45 PM) jdstrand:   /usr/bin/snappy                                                 uxr,
<jdstrand> jjohansen: hmmm? Ux didn't work, ux did
<jjohansen> that was the change causing the problem? correct?
<jdstrand> jjohansen: no, that was the 'solution'
<jjohansen> oh that was the fix, sorry misinterpretted and got very confused
<jdstrand> sergiusens: when is that api coming?
<sergiusens> jdstrand: this cycle
<jdstrand> sergiusens: alright, well let's just let the ux ride then. we can revisit proper confinement at that time
<sergiusens> jdstrand: I was supposed to be working on that today fwiw
<jdstrand> I was supposed to be working on things today too :P
<jdstrand> ah well :)
<sergiusens> jdstrand: many of these issues will go away; maybe you can easy prof a reserved "device_management" stanza ;)
<jdstrand> I thought we did that :)
<jdstrand> hardware assign ftw
<jdstrand> anyhoo, yeah, always more to think about
<sergiusens> jdstrand: heh; was thinking more a layer above "device" as in the product/box
<sergiusens> jdstrand: anyways, thanks, testing now
<jdstrand> sergiusens: fyi, you should probably try to get seccomp as restricted
<jdstrand> though, it would need som significant tuning
<sergiusens> jdstrand: sure, any pointers on how to get started on that side
<jdstrand> sergiusens: copy the syscalls from hello-world.env from /var/lib/snappy/seccomp/profiles and start there
<sergiusens> jdstrand: ok, and iterate with sc-log.* ?
<jdstrand> sergiusens: yes
<sergiusens> jdstrand: got it; I'll get to it just for the excercise of getting familiar with this
<sergiusens> I suspect again that moving to this rest api will move most of it away
<jdstrand> cool
<jdstrand> sergiusens: what is the design for the rest api? right now I see that the web interface is confined by this profile, and this profile allows a whole-lotta privilege. eg, if an attacker could take control of webdm, he could install a malicious snap with no confinement that provides a remote shell
<jdstrand> (via side loading)
<jdstrand> sergiusens: perhaps this is something that you would want to spec out with the security team and architects team?
<sergiusens> jdstrand: the rest api would look a lot like lxd's but yeah, I have to get the proposal and send out for review
<sergiusens> jdstrand: I bet you guys will be an integral part of it
<jdstrand> it might be that there isn't a terribly whole lot we can do here since this is a management interface that is designed to, well, manage. but perhaps we can have some security in depth here
<jdstrand> sergiusens: ok, cool
<sergiusens> jdstrand: this is where the macaroons come into place, I think lool has the high level architecture in his head already and waiting for some minion like me to do a brain dump for him :-)
<jdstrand> ah
<lool> haha
<jdstrand> tyhicks, mdeslaur (and jjohansen): we should be looking out for this ^ (see backscroll for 7 minutes)
<tyhicks> jdstrand: ack
<lool> (so every time I read minions, of course I try to think of despicable me, but I can't stop thinking about Mignons which was means "cuties" but were also the "favorites" of the prince)
<lool> (the king would allow them to dress as nicely as him, wear facial powder etc., and at some point it gained an homosexual connotation)
<jjohansen> jdstrand: ack
<lool> jdstrand: so my understanding is that secure channel is laptop -> my.ubuntu.com + snappy device -> my.ubuntu.com; either we then do direct connection to snappy device with a cookie with limited powers, or we go over my.u.c to do everything or a mixture of both
 * sergiusens doesn't want to spread facial powder over his face
<lool> but TBH, while I find macaroons and this bootstrap of the security story exciting, I suspect folks in Online Services are better clued at these topics
<sergiusens> rsalveti: mind taking action? https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625
<lool> sergiusens: you can be my mignon de couchette
<lool> you would be allowed to sleep in the same room as me
<lool> http://fr.wikipedia.org/wiki/Mignon_%28histoire%29 for the full story -- yes, this is an actual expression
<sergiusens> lool: lol
 * lool now expects an email from HR
<sergiusens> lool: lol at that again!
<sergiusens> jdstrand: or maybe you can https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625 stamp this?
<jdstrand> sure
<rsalveti> sergiusens: jdstrand did already it seems
<rsalveti> was walking the dog
<Chipaca> sergiusens: any progress with the mystery of the mysterious disappearing floating point?
<rsalveti> Chipaca: https://code.launchpad.net/~sergiusens/webdm/profileUnconfinedNoScrubSnappy/+merge/260625
<rsalveti> that made go not being able to find out the hwcaps via elf auxiliary vectors
#snappy 2015-05-30
<Chipaca> rsalveti: ouch. that's going to bite all go programs.
<sergiusens> Chipaca: it's not the go program itself, it the cmd.Exec to snappy internal-unpack that fails
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/properDeviceFiltering/+merge/260646 if you have a couple later today
<tbr> if I'm working on a hardware adaptation and e.g. need to change /etc/default/grub.d/50-system-image.cfg - what is the 'right' way to do this?
<tbr> (having a 9k6 console was cool during the 90s)
#snappy 2016-05-30
<hathor008> so wtf is this supposed to mean? 'NoneType' object has no attribute 'lstrip'
<sethj> hi hathor008. I see you are having no more luck than I am lol
<hathor008> https://gist.github.com/anonymous/0cb3931924b497dad9c73d597716bd74
<hathor008> yeah i mean this process is really confusing
<hathor008> http://askubuntu.com/questions/779315/how-do-i-create-a-snap-for-a-monogame-application
<sethj> I'll take a look at your case tomorrow if I can find some time.
<hathor008> thanks
<tptr> hi, I'd like to ask a question about publishing. If I build a snap package but I cannot make it public is there a way, like a private repo, to publish it only in my team or for my IoT devices?
<zyga> o/
<hathor008> hi
<pedronis> tptr: yes, there's a concept of private snaps (that can be shared with a selected group)
<tptr> pedronis: ok thanks, I will keep digging then.
<AndroUser> Whoami
<AndroUser> http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267
<AndroUser> Hey people, could someone take a look here?
<ogra_> heh ... fun that people always start packaging with the hardest tasks :)
<AndroUser> Yeah, I thought that too
<ogra_> looks like you want some additional python packages there
<AndroUser> But I just couldn't reproduce the error that OP filled in to
<ogra_> pythoon-apport comes to mind seeing the error
<ogra_> or rather python3-apport ... (not sure if that one is still needed though, py3 should be the default)
<AndroUser> I don't know too
<ogra_> same goes for python-dbus ...
<AndroUser> Why is that dependencies listed by setup.py are not getting installed and require being listed apart in the yaml file?
<ogra_> thats a question for sergiusens :)
<AndroUser> I am not Seth, just was very curious. If you happen to try anything, please answer in this thread ok?
<ogra_> what i see is that the OP is using python3-* packages everywhere ... could well be that in 16.04 these are just empty transitional packages ...
<AndroUser> I tried a lot of different stuff last night with Seth and we couldn't trace back the cause of errors
<ogra_> and python-apport is clearly missing
<AndroUser> Uhm, that's a great idea, I didn't checked to see what python3 packages were indeed installing
<ogra_> even if you get it packaged though ... you will need a lot of interface work still ... we dont have a way yet to attach to the system fonts ot themes from a snap ... you will only be able to run it in devmode for now
<AndroUser> I went to the ubuntuforums.org and couldn't find a topic for discussion on Snaps, where can I suggest a dedicated forum there?
<AndroUser> I see, so it wouldn't be able to change themes and unity options like usual?
<ogra_> well, you can suggest the snapcraft mailing list (at https://lists.ubuntu.com/mailman/listinfo/snapcraft )
<ogra_> and this IRC channel here
<ogra_> i dont think any developer actually monitors forums much
<AndroUser> Thanks. I will enter the mailing list :)
<sergiusens> ogra_ I don't see AndroUser on anymore nor did I see a mailinglist question so if he comes by, tell him that install_requires in setup.py is automatically taken care of.
<ogra_> sergiusens, well, the askubuntu thing seems to not find some deps (python-dbus, python-apport namely)
<ogra_> http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267
<sergiusens> ogra_ I bet python-apport is not on pypi or has a different name there
<ogra_> yeah
<sergiusens> it has already sort of been answered
<sborovkov> Hi. I have a python code running on snappy. It basically just accesses SNAP_USER_DATA. And some networking stuff. But I get a lot of apparmor warnings - any ideas what could be wrong? https://paste.kde.org/pawrdt7xc
<sergiusens> sborovkov seems you installed with devmode
<sergiusens> Not much of a problem if so. It all says ALLOWED
<sborovkov> sergiusens: yeah, I did. Thought that what's allowed in devmode would be forbidden without it :-)
<sborovkov> is that not the case?
<sabdfl> sborovkov, if you don't specify --devmode then the snap runs confined
<sabdfl> once your confinement description is correct, then you can drop the --devmode
<sabdfl> which is a good thing :)
<sabdfl> the point of --devmode is that it is sometimes hard to get the confinement description complete up front
<sabdfl> so --devmode lets you put things into "log only" mode (well, mostly, some things still shoot you in --devmode :))
<sabdfl> sergiusens, around?
<sergiusens> sabdfl yes I am
<sergiusens> sborovkov let me open your paste again
<sergiusens> sborovkov was mislead by the mention of "warnings"
<sergiusens> sborovkov is ldconfig run by the snap by any chance?
<sabdfl> sergiusens, would this work:
<sabdfl> ah
<sborovkov> sergiusens: sabdfl: I understand that devmode allows everything. But I thought any apparmor "allowed" message mean that it would not work without devmode.
<sborovkov> sergiusens: >is ldconfig run by the snap by any chance - that's relatively simple python program. So I don't understand where ldconfig is coming from at the moment. Thought that may be python is running it...
<sergiusens> sborovkov line 3 indicates this, not sure what your simple program is (or maybe a wrapper script you have going around)
<tyhicks> sborovkov, sergiusens: ldconfig is being ran and that is the cause of nearly all the AppArmor denials
<sergiusens> tyhicks it seems so from line 3. Trying to find out where :-)
<sergiusens> the /proc/.../mounts one isn't much of a problem
<tyhicks> sergiusens: the mount-observe interface allows reading /proc/PID/mounts
<sergiusens> tyhicks but do we need it? I was thinking of it as a harmless error
<sergiusens> for the python runtime case
<sborovkov> sergiusens: tyhicks: I have custom ld.so file. exec "$VIEWER_APP_PATH/lib/ld-linux-armhf.so.3" --inhibit-cache $@ This is how another part of snap is run... But this messages come from python part which is run as usual
<sborovkov> if this is relevant...
<tyhicks> sergiusens: I'm not sure if python will croak if it can't read /proc/PID/mounts - I'd be surprised if it was treated as a fatal error but I'm just not 100% sure
<sborovkov> sergiusens: tyhicks: also do you know if snap installed in --devmode can drop devmode somehow without manual interaction on snap upgrade let's say?
<sergiusens> tyhicks it has been fine so far
<tyhicks> sborovkov: I don't believe we have defined a way for a snap to automatically promote itself from devmode to non-devmode on an upgrade
<sborovkov> tyhicks: understood, thanks. Would using custom ld.so cause any apparmor issues? I have my application built in buildroot and for some reason it does not work without it.
<sergiusens> tyhicks we discussed this with nessita and niemeyer. IIRC going from "production" to devmode would trigger an alert. The other way around wasn't covered but it should be sort of fine, right?
<tyhicks> sergiusens: It should be fine as long as the user is using the snap as it was intended to be used by the snap packager
<tyhicks> sergiusens: it would have the potential to break the user if, for example, he/she is specifying file paths that don't jive with confinement
<tyhicks> that's not really something that we can protect against
<sergiusens> tyhicks right, the "product" would need to be solid to move from devmode to production mode for starters
<nessita> sergiusens, correct, the transition from strict to devmode is not automatic but devmode to strict is
<tyhicks> oh, cool
<tyhicks> sborovkov: regarding a custom ld.so> I think you should be able to get away with doing that within confinement since you're using --inhibit-cache
<sborovkov> wait, so how does automatic transition from from devmode to strict can be triggered?
<sborovkov> tyhicks: ok, thanks.
<sborovkov> nessita: do you know how that automatic transition could be triggered?
<nessita> sborovkov, when running snap refresh, if the store reports a newer revision, the snap will upgrade
<nessita> and the newer revision can be strict (even if the reported revision is devmode)
<sborovkov> nessita: thanks.
<nessita> sborovkov, you are welcome! I hope my answer made sense
<sborovkov> nessita: yes. I was just wondering because the application we are developing has some blockers on snappy side (/dev/vchiq inaccessible is the main thing). So was thinking if it would be possible to make images with snap installed in --devmode for alpha version and then later upgrade to proper mode without having people reflash the SD cards
<nessita> sborovkov, right, in that scenario you would push a new revision of your snap without devmode, and you need to make sure you publish that snap in the alpha channel
<nessita> sborovkov, then all your clients will get that revision on manuel or automatic "snap refresh"
<sborovkov> nessita: so it's a flag in the store then? whether it's devmode or not?
<nessita> sborovkov, nopes, is a flag inside each snap binary, so basically when you want to leave devmode and migrate to strict confinementn you need to do a new build and push to the store
<nessita> sborovkov, and release that new build in the same channel as the one that had the devmode revision published
<nessita> does that make sense?
<sborovkov> Yeah, I just did not know about the flag (or how to set it when building the snap) . Since I though that it's enabled when installing using `--devmode`.
<nessita> sborovkov, ah, right. So latest snapcraft allows you to define a confinement: devmode in your snapcraft.yaml that will make the confinement checks be treated as INFO instead of erroing
<sborovkov> nessita: thanks again. Now everything's clear :-)
<nessita> great!
<sborovkov> Are config interfaces still gone?
<qengho> This might be a 2.0.3->2.0.5 xenial-proposed regression. Not sure. https://bugs.launchpad.net/snappy/+bug/1587175
<ubottu> Launchpad bug 1587175 in Snappy "snapd "cannot find mounted snap" error in 2.0.5" [Undecided,New]
#snappy 2016-05-31
<zyga> o/
<davidcalle> didrocks: hey, can you have a quick look at https://github.com/ubuntu/snappy-playpen/pull/11 ? Thanks :)
<didrocks> davidcalle: can you expand a little bit what you are trying to fix?
<didrocks> ah, the Testing atom/parts/plugins
<didrocks> because we have a custom plugin
<didrocks> so subdir
<didrocks> davidcalle: I think that can be done maybe in an easier way (don't like the double xargs)
<davidcalle> didrocks: sure, note that if you just strip the second dir, you end up with duplicates, that was the shorter diff I could come up with :)
<davidcalle> didrocks: also, not sure if you have noticed, but travis is trying to apt-get an older rev of a package, hence, all runs are failing since a couple days. (https://travis-ci.org/ubuntu/snappy-playpen/builds/133371927#L544)
<didrocks> davidcalle: it's because I'm using sergiusens docker
<didrocks> davidcalle: let me set up ours + daily refresh
<didrocks> davidcalle: I'm playing with the regexp :)
<didrocks> davidcalle: got it in a way shorter, do you want me to setup a branch you can review (or pull or whatever)?
<davidcalle> didrocks: I'm fine with your branch replacing this one
<didrocks> davidcalle: mind reviewing? https://github.com/ubuntu/snappy-playpen/pull/14
<davidcalle> didrocks: hah, wfm :)
<didrocks> davidcalle: we should specialized those changes in ci-run btw :)
<davidcalle> didrocks: although... look at the ci-run :D
<didrocks> davidcalle: yeah, it tries to run on the top_dir
<didrocks> which was already the case
<didrocks> Let me try to special-case this
<davidcalle> didrocks: nope, yours considers the ci-run file as a folder
<didrocks> davidcalle: yeah, because it doesn't care of file type
<didrocks> we can just say "if file type == file" -> change is in the root dir
<didrocks> I guess that's the best fix for other files in root
<didrocks> davidcalle: refresh (see second commit)
<davidcalle> didrocks: ty :)
<didrocks> davidcalle: thanks for spotting it!
<didrocks> davidcalle: so, I guess having our own docker image refreshed daily makes sense, right?
<davidcalle> didrocks: sounds like a good solution, yes
<didrocks> davidcalle: ok, master have most of the tests passing with my image (which is daily built)
<didrocks> davidcalle: however, unsure who did merge ffmepg, but it seems to fail
<didrocks> davidcalle: I'll push the docker image change first, then, we can iterate to get other fixed
<davidcalle> popey: ^
<davidcalle> Thanks didrocks
<popey> eh?
<popey> I did ffmpeg as a standalone snap.
<popey> davidcalle merged them
<davidcalle> popey: was just a heads up in case you had a fix. didrocks, do you have a log for ffmpeg? The original pr was fine afair.
<popey> my snap worked fine, what did you do? :)
<didrocks> davidcalle: I did a local ci-run
<didrocks> it seems snapcraft can't find the ffmepg command (which is in bin/ffmepg)
<didrocks> note that this can be an upstream issue with latest snapcraft :)
<didrocks> popey: davidcalle: I did request cron enablement as well on Travis to build master regularly (the API token method don't work, despite saying success)
<davidcalle> ok
<vallettea> hello, I new to snappy and would like to know how can I monitor the the size of the update of my snap. I run a lot of sensors over 3G and the amount of data transfered is really important in my case
<hathor008> can anyone shed some insights on this? would be greatly appreciated :) http://gamedev.stackexchange.com/questions/122197/how-do-i-create-an-ubuntu-snap-for-a-monogame-application
<sborovkov> Hello. Are config interfaces back or still not?
<ogra_> not yet
<sborovkov> ogra_: is there some issue on launchpad for that? I did not find one :-(
<didrocks> sborovkov: you're right, there is none: please file one https://bugs.launchpad.net/ubuntu/+source/snapd
<sborovkov> Understood, thanks.
<didrocks> hathor008: the issue is in your snapcraft.yaml
<didrocks> you have:
<didrocks> files:
<didrocks>     "*":
<didrocks> you need:
<didrocks> files:
<didrocks>     "*": '.'
<didrocks> hathor008: but please, file a bug against https://bugs.launchpad.net/ubuntu/+source/snapcraft as the error message isn't obvious
<hathor008> lol that's all it is? i figured it was something simple like that
<hathor008> ok no problem
<didrocks> hathor008: please copy your invalid snapcraft.yaml and mention "copy plugin" :)
<didrocks> but yeah, that's all ;)
 * didrocks still thinks that the copy plugin shouldn't require a files: parameter for such cases "copy all"
<mhall119> hey guys,is there any known issue with running an OpenGL-using snap on proprietary graphics drivers?
<mhall119> someone trying to run a Krita snap on proprietary nvidia is gettign this: http://pastebin.com/WsUfEj8J
<mhall119> sergiusens: kyrofa: ^^ any help?
<zyga> tyhicks: hey
<noizer> Hi got a little problem with my snappy. is the tmp of the installation limited? error: cannot copy request into temporary file: write /tmp/snapd-sideload-pkg-130544461: no space left on device
<hathor008> thanks for your help, didrocks. i really appreciate it :)
<didrocks> hathor008: yw! :)
<sborovkov> Hello. What's the current status of syslog on snappy? Is there some interface so that snap can configure it? Or how would I go about it when I need to configure it remotely?
<didrocks> sborovkov: you have a log-observe interface, maybe give it a shot? (I don't think there anything for configuring it remotely yet)
<jdstrand> tyhicks, sergiusens, sborovkov: hey, fyi, in my experience access to /proc/<pid>/mounts is almost always non-fatal (unless you are a disk usage analyzer or something). this constitutes a potential information leak, which is why it is not in the default profile (and in mount-observe)
<jdstrand> sergiusens, sborovkov: fyi, tyhicks and I have been giving some thought to silencing logging of noisy denials
<sborovkov> didrocks: thanks
<sborovkov> jdstrand: is there a way to know what denial would be fatal?
<jdstrand> sergiusens, sborovkov: we can do that now with an explicit deny of course, but that doesn't always work the way you want
<sborovkov> jdstrand: since in the same log I had ldconfig run... I have no idea why, and don't know if it's fatal as well
<jdstrand> sborovkov: run it in strict mode and see if your program runs ok
<sborovkov> jdstrand: my program accesses /dev/vchiq as well, so it does not work in strict :-)
<mhall119> jdstrand: davidcalle is helping me debug the krita snap with snappy-debug.security scanlog, but he gets this: http://paste.ubuntu.com/16863706/
<davidcalle> Installing snappy-debug with --devmode helped http://paste.ubuntu.com/16863781/
<didrocks> mhall119: jdstrand: confirmed, everytime an exception is raised, getting the stacktrace as well
<noizer> what can I do with a snap thats not fits in the temporary dir while installing?
<zyga> noizer: hmm?
<zyga> noizer: how big is it?
<zyga> noizer: report a bug first please
<zyga> noizer: is your /tmp a tmpfs?
<noizer> zyga: its my /tmp
<noizer> zyga 250mb
<noizer> zyga ps how can i manually make a snap?
<noizer> zyga its for my armel build
<ogra_> and your HDD doesnt have 250MB free ?
<ogra_> (in /tmp)
<zyga> noizer: just use mksquashfs
<jdstrand> sborovkov: add '/dev/vchiq rw,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app
<ogra_> uh
<ogra_> no
<ogra_> use "snapcraft snap $dir"
<zyga> ogra_: that's less manual but non the less true :)
<ogra_> (to make sure the proper options are used for mksquashfs)
<ogra_> :)
<jdstrand> sborovkov: that will allow that access and let you see if the other ones are ok. I know you have a bug open on /dev/vchiq and that zyga gave comments on how the interface can move forward
<noizer> zyga ogra_ http://paste.ubuntu.com/16864020/
<noizer> here you can see my diskspace
<jdstrand> mhall119: that is the same error that we discussed last week. I submitted a PR to the log-observe interface and it was committed. it will be in the next snapd release
<ogra_> noizer, well, /tmp is a tmpfs ... so buy more ram or change that to use the disk instead
<noizer> heh its my raspi
<mhall119> jdstrand: yup, for now he's got snappy-debug working in devmode
<ogra_> oh, you are *on* snappy
<mhall119> which revealed a syscall to 'bind' that was blocked
<jdstrand> mhall119: let me find the commit and I can give you a workaround. yes, --devmode will work ok. when snapd 2.0.6 is out, it shouldn't be needed
<noizer> ogra_:  yes ofc
<mhall119> so running krita in --devmode gets it working for davidcalle
<ogra_> hmm
<mhall119> but someone else is having issues with OpenGL still, and running krita in --devmode doesn't help him
<mhall119> davidcalle is using open-source gpu drivers, and the other guy has proprietary nvidia
<jdstrand> mhall119: 774d721b0d4935fcdcb1146b8e38396eca67c17f (for snappy-debug)
<jdstrand> mhall119: opengl is a mvo/zyga thing (iirc)
<mhall119> mvo: zyga: can you guys help me debug this: http://pastebin.com/WsUfEj8J
<ogra_> noizer, thats a tricky one indeed
<jdstrand> mhall119: don't forget the socketcall workaround on i386. whoever hit that traceback you pasted likely will need to add socketcall to /var/lib/snapd/seccomp/profiles/snap.krita....
<mhall119> it's not a confinement issue, he's run krita in --devmode and it has the same error, and snappy-debug.security scanlog doesn't show anything before the krita launch fails
<mvo> mhall119: is that a nvidia (proprietary drive) system? or what HW do you use?
<ogra_> noizer, and i guess worth a bug to tell snapd to use its own TMPDIR on disk ... as zyga said, file a bug
<mhall119> jdstrand: he's on amd64
<jdstrand> mhall119: not confinement> yes, I know, hence comment regarding mvo/zyga
<mhall119> jdstrand: though I suspect that socketcall might be related to the bind denial that davidcalle sees
<mhall119> mvo: proprietary driver, yes
<noizer> ogra_: Is there for now a workaround?
<jdstrand> mhall119: re bind> maybe. might just need network-bind
<mvo> mhall119: do you happen to know what version?
<jdstrand> snappy-debug in devmode will help you decide
<mhall119> jdstrand: yeah, but it's a digital painting program, I don't see why it would need that in the first place
<mhall119> mvo: of what?
<ogra_> noizer, not that i know of ... ou could try remounting /tmp at runtime to disk manually but i guess that will break some bits that currently use the tmpfs /tmp
<jdstrand> mhall119: it is surprising what apps not designed for confinement require
<mhall119> mvo: let me get him in this channel, so I'm not passing messages around
<mvo> mhall119: is that a system you have direct access to? what is the output of "ls -ld /usr/lib/nvidia-*" ?
<jdstrand> mhall119: it could also be a kde think. bind is needed for binding to the server side of a unix socket too
<jdstrand> thinkg*
<jdstrand> err
<jdstrand> thing*
<mhall119> mvo: I don't, which is why I'm trying to get him to join in here
<jdstrand> mhall119: kde has this whole ipc infrastructure which I predict it going to be challenging
<mvo> mhall119: or tell me where he is and I join there, either way is fine
<mhall119> jdstrand: hmmm, maybe. I can add network-bind to see if that allows davidcalle to run without --devmode
<mhall119> mvo: he's in #krita
<kyrofa> mhall119, do you know what computer he has?
<mhall119> nick is  mattiasw
<mhall119> kyrofa: only that it's amd64 and proprietary nvidia driver
<kyrofa> Okay
<kyrofa> zyga, do you know anything about https://askubuntu.com/questions/779875/cant-download-the-snap-packages ?
<didrocks> kyrofa: swift is down
<didrocks> impacted CI and the store
<didrocks> impacting*
<didrocks> (and hey!)
<kyrofa> didrocks, oh. I guess that would do it! :P
<kyrofa> didrocks, hey!
<kyrofa> didrocks, that might also explain why my integration tests are having issues
<didrocks> kyrofa: not for your local test run though :p (j/k)
<noizer> ogra_: What is the difference between meta/snap.yaml and snapcraft.yaml
<kyrofa> noizer, meta/snap.yaml is what snapd itself requires inside the snap itself
<kyrofa> noizer, snapcraft.yaml is the "recipe" you give to snapcraft that tells it how to put the snap in question together, and it creates the meta/snap.yaml for you
<ogra_> noizer, what kyrofa said :)
<zyga> kyrofa: looking
<kyrofa> Sorry zyga, didrocks informed me that it was likely a temporary store issue
<noizer> hmmm ok but I can't snap my snap with snapcraft. So told me a few days earlier too snap it manualy but ... I don't understand it anymore
<zyga> kyrofa: I also replied: http://askubuntu.com/questions/779875/cant-download-the-snap-packages/779917#779917
<kyrofa> zyga, ah, good idea
<mterry> tedg, looking at the unity8 lifecycle thread -- it's not just saving state, but also having apps that understand they will be frozen when not focused.  So apps need to use the correct Touch apis to do background stuff, etc.
<popey> mhall119: do you know why the icon shows as a piece of paper for krita?
<popey> I have made a snap and I wonder if perhaps the meta/gui/foo.png is no longer the right way to deliver an icon?
<mhall119> it should be...it works for me anyway
<mhall119> popey: is it in /snap/krita/current/meta/gui/ ?
<popey> mhall119: yes
<mhall119> what does the .desktop list for Icon?
<popey> Icon=${SNAP}/meta/gui/calligrakrita.png
<mhall119> then it should be working...
<popey> $ file /snap/krita/current/meta/gui/calligrakrita.png
<popey> /snap/krita/current/meta/gui/calligrakrita.png: empty
<popey> that won't help
<popey> zero byte file
<mhall119> empty?
<qengho> zyga: howdy!
 * ogra_ hands popey a spare byte to add it to the file
<mhall119> how the heck...
<popey> what copies that file?
<mhall119> davidcalle: can you $ file /snap/krita/current/meta/gui/calligrakrita.png
<zyga> qengho: hey
<tedg> mterry: Yes, I guess I see that as advanced usage. In that, they just need to know they're gonna be killed, if they want to work around that they can.
<mhall119> popey: it's just in the setup/gui/ folder of the snapcraft directory
<popey> setup/gui, not meta/gui?
<mhall119> yeah, that's the snapcraft folder, it installs to meta/gui
<ogra_> setup/gui jin the source
 * zyga brb
<popey> k
<davidcalle> mhall119: /snap/krita/current/meta/gui/calligrakrita.png: empty
<popey> wooot, mine works
<popey> (once I put the png in the right place)  ð
<mterry> tedg, not *so* advanced.  Lots of apps assume they run in background (irc etc).  But also maybe it implies a set of APIs that belong in that interface -- the download api, the push notification api, I dunno
<mterry> Interfaces in Touch that let an app work in background, but the right way
<mhall119> davidcalle: ok, something's gone wrong with upstream's build then....
<tedg> So yes, I think those should all be in the unity8 interface. I think we might be agreeing?
<davidcalle> mhall119: looks like it
<mhall119> davidcalle: popey: that's probably my fault in how I submitted the patch upstream
<mterry> tedg, yeah yeah we agree.  I was just trying to give you more ammo.  Seemed like things had focused just on OOM, but background processing is another uniquely-Touch set of problems
<tedg> mterry: Makes sense, I think that this first PR is more about getting hello world off the ground. We're gonna need *a lot* more work after that. But I need a foothold to start attaching things like UAL to.
<mvo> mhall119: do you think you could chase our nvidia packagers to include a systemd bind mount unit from "sudo mount -o bind /usr/lib/nvidia-361 /var/lib/snapd/lib/gl/" ?
 * popey shoves a dosbox snapcraft to snappy-playpen
<popey> probably the leanest snapcraft.yaml I've ever made
<ogra_> popey, add doom too !!
<popey> hah
<mhall119> mvo: I don't even know who our nvidia packagers are...is that canonical, community, or nvidia?
<popey> mhall119: tseliot iirc
<ogra_> mhall119, tseliot
<mhall119> thanks
<popey> JINX
<ogra_> :)
<mhall119> will find him
<popey> sounded a bit http://s2.quickmeme.com/img/b3/b397b33ced963be59c76e2566b24f0547aa2ae596f148ee1339f3c8e5c5b058c.jpg
<ogra_> heh
<popey> which seems harsh, despite it being nvidia
<popey> didrocks: your jenkins is faulty... " g++: not found"
<popey> didrocks: https://travis-ci.org/ubuntu/snappy-playpen/builds/134182006
<mhall119> mvo: I assume the nvidia package fix needs to be SRU'd into 16.04's archives, it's not something that gets fixed in ubuntu-core images
<mvo> mhall119: yeah, we need to get this SRUed
<mvo> mhall119: not something we can fix in the image
<ogra_> also, in the image the driver would have to live in the kernel snap
<ogra_> (not in an nvidia package)
<mvo> mhall119: thanks a lot for helping with the bind mount, really much appreciated
<qengho> zyga, mvo: I do not remember anything in particular, but it's possible I pressed control-c during a "snap install" or "remove" before. Not to poison your debugging thoughts, but if nothing else seems obvious that might be a place to explore.
<zyga> qengho: that wouldn't change anything
<zyga> qengho: snapd carries the work, snap is just a rest client that says "do this please"
<zyga> qengho: thanks for state.json
<zyga> qengho: and for the syslog parts
<zyga> qengho: can you still reproduce this issue?
<zyga> qengho: and regardless, can you please pastebin the output of mount
<zyga> qengho: and ls -l /snap/*
<qengho> zyga: I'll try to reproduce now. mount is in the bug report already (|grep snap).
<zyga> qengho: thanks
<qengho> zyga: reproduced. Attached log.
<qengho> Aw, man, and 2.0.3 is gone from APT. I can't downgrade now.
<zyga> qengho: is there anything mounted under /snap/google-chrome/
<zyga> qengho: under the directory (not there directly)
<sethj> so, if one of my parts is a collection of bash and python scripts that uses an INSTALL file, what would I specify for a plugin? Or will I have to write my own? (there doesn't seem to be a list of included plugins anywhere)
<qengho> zyga: you have my full mount list.
<zyga> qengho: thanks, I'll check it out after this cal
<zyga> call
<qengho> lsof |grep chrome
<qengho> (wrong terminal. gah.)
<qengho> sethj: "Uses an INSTALL file"?
<qengho> sethj: I'm guessing plugin: copy
<sethj> qengho, https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install. copy does sound like it would be right. Lemme try. (and *is* there a list of these somewhere?)
<qengho> sethj: yes.   $ snapcraft list-plugins
<sethj> oh very nice.
<sethj> someone needs to write a manpage :P
<qengho> sethj: It's also very easy to put a file in parts/plugins/sethj.py, import snapcraft, class Anything(snapcraft.BasePlugin): def build(): super().build(); self.run(["something specific to you")
<qengho> sethj: in your snapcraft.yaml, that's "plugin: sethj"
<netphreak> I'm trying to install a snap via command line, and get the following error:
<netphreak> - Make snap "ubuntu-core" available to the system (cannot set next boot: cannot determine bootloader)
<netphreak> I'm on a RPI with ubuntu-core
<qengho> netphreak: that's a known bug. Should be fixed soon.
<netphreak> ... hopefully :)
<qengho> netphreak: subscribe: https://bugs.launchpad.net/snappy/+bug/1580403
<ubottu> Launchpad bug 1580403 in Snappy "snap tries to manage bootloader in snappy-on-ubuntu-classic mode" [High,Fix committed]
<qengho> netphreak: wait, "with ubuntu core"? Is that from a ubuntu core testing image, or from regular 16.04 image with ubuntu core from snapd?
<netphreak> Not quite sure what it is, got it setup a couple of weeks ago - don't seem to have the image file any more..
<netphreak> Any command i can run to see which version?
<qengho> netphreak: what's it look like to you? What do you see when you turn it on?
<qengho> Does "apt" do anything?
<netphreak> yes.. Apt is installed
<netphreak> i used apt to install snapcraft and snap
<joc_> zyga: i'm getting fails in the asserts section when executing run-checks, am I missing some setup?
<zyga> joc_: can you be more specific please
<joc_> zyga: yeah i'm running run-checks as per the README in snapd
<sergiusens> didrocks we agreed a while ago to even deprecate `files` in the copy plugin and direct people to `filesets`, `organize`, `stage` and `snap`
<joc_> zyga: it gets as far as github.com/jocave/snapd/asserts_test
<joc_> zyga: then i get:
<joc_> asserts/asserts_test.go:37: undefined: asserts.TestOnlyType
<joc_> asserts/asserts_test.go:37: too many errors
<qengho> netphreak: then you aren't using "ubuntu core", but ubuntu with snaps. And that is the bug here. snapd thinks it's the top OS, when it's not in your case and my case. And that bug is fixed in a few days.
<netphreak> ahh.. ok.. thx for explanation.
<netphreak> do you know the status of snappy classic-mode?
<qengho> netphreak: "apt" doesn't exist in the Ubuntu Core world. It's a specialty-device kind of place. We get to piggy-back on all its goodness, though.  :)
<netphreak> :)
<joc_> zyga: i've only add an interace as you suggested so wasn't expecting to get errors from anywhere else
<zyga> joc_: hmm, can you reproduce that on master?
<zyga> joc_: anyway, ignore run-checks
<zyga> joc_: just go test in interfaces/builtin initially
<zyga> joc_: and open a pull request or show me your branch
<zyga> tyhicks: hey
<qengho> netphreak: Not much. I used it back in February, but it's probably changed a lot since.
<zyga> jdstrand: hey :)
<zyga> jdstrand: I wanted to sync about snap-confine
<jdstrand> zyga: hey--ok, should tyhicks be here?
<zyga> jdstrand: I think so
<qengho> netphreak: it, like all of snap stuff, is in heavy development. To be released soon.
<zyga> jdstrand: I have a few questions and I want to know what you are working on, e.g. if tyler will look at the bind mount interface and if you saw what's posted to the repository lately
<popey> davidcalle: didrocks https://github.com/ubuntu/snappy-playpen/pull/15 - feel free to merge if you want :)
<tyhicks> zyga: hi
<zyga> tyhicks: hey, good to see you
<joc_> zyga: thanks, i'll get tests passing then get back to you
<jdstrand> zyga: currently I am not doing anything with the launcher. I am waiting for the seccomp arg filtering reviews (I saw you commented, waiting on tyhicks too). when that is done, I will start on trying to get that into xenial and then fix various bugs blocked on that
<zyga> joc_: note that for all the integration tests to pass you need the patched ubuntu-device-flash
<zyga> (in your path)
<tyhicks> jdstrand: I completed my seccomp arg filtering review friday evening
<jdstrand> setpriority is the big one, but others. I believe tyhicks is working on other things
<jdstrand> awesome
<zyga> jdstrand: note that we should be careful about releases of the code today
<jdstrand> I'm still behind on email and will get to it today
<zyga> jdstrand: as we're getting more and more snap-run/confine/exec story landed
<zyga> jdstrand: and that needs coordination
<jdstrand> zyga: yes, I was considering SRUing something as a patch to ubuntu-core-launcher for xenial and let all the other stuff be under your control
<jdstrand> it just depends on the timing
<zyga> jdstrand: that's sounds good, just let us know when this happens
<zyga> jdstrand: note that there's been an upload to debian that's not reflected in either tree today
<zyga> jdstrand: (the version is +1 there)
<zyga> jdstrand: ubuntu@localhost:/etc/modprobe.d/modprobe.d$ ll
<jdstrand> I'm getting asked every day though on when bug NNN will be fixed and I keep saying 'when seccomp arg filtering is there...)
<zyga> er
<zyga> bad paste
<zyga> jdstrand: heh
<tyhicks> zyga: I haven't started working on the bind mount support in interfaces - despite not having the time to work on it yet, it felt like a lot of things were in flux and I wasn't clear if plans had changed
<zyga> jdstrand: yes, I see that this should land as soon as we can
<zyga> tyhicks: can I ask you to review my chroot / pivot_root patch
<zyga> tyhicks: I suspect we'll go ahead with that approach (just polish it more)
<zyga> tyhicks: but I want a solid security review to preceed that
<tyhicks> zyga: sure, I can review that patch but I thought we were told not to make that change right now?
<zyga> tyhicks: yes, but the blocker is getting done :)
<jdstrand> zyga: is what is in the debian +1 patch at least in trunk? if not, what is that?
<zyga> tyhicks: and gustavo said that it should be the next thing after that
<tyhicks> zyga: ack - i'll have a look
<zyga> jdstrand: I think slangasek uploaded something to debian and there's a change that is not integrated anywhere
<zyga> other than that I'm proposing some tooling changes (autotools)
<jdstrand> http://metadata.ftp-master.debian.org/changelogs//main/u/ubuntu-core-launcher/ubuntu-core-launcher_1.0.29+1_changelog
<jdstrand> it's not code changes
<zyga> and I will have a few small patches that make lintian happier (lots of little issues), some of those are related to security so I'll poke you specifically on github
<zyga> jdstrand: with native packages it is hard to see
<jdstrand> zyga: if it's lintian, see slangasek's patch
<zyga> jdstrand: perhaps I should just ask slangasek to send that to snap-confine :-)
<zyga> slangasek: ^^
<jdstrand> :)
<zyga> tyhicks, jdstrand: are you both aware of what's changing to snap-run/confine/exec now?
<tyhicks> zyga: no, I'm not fully aware
<jdstrand> not really, no
<zyga> okay, so the quick big picture is that snap run (a new subcommand of snap) will run snap-confine (which is the current C codebase), that will apply process confinement as it does today and then execute /usr/lib/snapd/snap-exec (xi style) which will in turn read all the yaml bits and figure out what to exec
<zyga> that last program (snap-exec) will be written (is written by mvo actually) in go and will mainly do yaml parsing and environment setup
<zyga> I just want to keep both of you in the loop so that you're aware of what is going on
<jdstrand> zyga: xi style?
<tyhicks> he means ix
<zyga> yes
<zyga> sorry
<zyga> not changing the profile
<jdstrand> I see
<zyga> so snap-exec runs as the final application will
<zyga> one thing we will get out of that is that snap-exec will also know how to run pre commands, post commands, and hooks
<zyga> and that it will no longer have to get the command to run from command line, instead command line will just be the actual command line for the application being started
<tyhicks> FWIW, I don't think snap-exec should run under the confinement of the application
<tyhicks> it sounds like it'll be doing things that the application should not have access to do
<tyhicks> but maybe I'm wrong
<zyga> tyhicks: it will only read snap.yaml
<zyga> tyhicks: and exec the executable of the application
<tyhicks> zyga: you said pre/post commands and hooks
<zyga> tyhicks: those are just commands to run that are written down in snap.yaml
<jdstrand> so, instead of snap-confine exec'ing the binary, it executes snap-exec which executes the binary
<zyga> tyhicks: e.g. snap run apache --command=post
<zyga> jdstrand: yes
<zyga> tyhicks: and that goes and reads what to really execute from snap.yaml
<zyga> tyhicks: so that we don't have to pass it on the command line all the time
<zyga> this approach also kills a lot of the wrappers
<tyhicks> jdstrand: this is good - it moves code out of the setuid root launcher and the launcher won't need to learn how to read yaml
<mvo> the long version is here: https://docs.google.com/document/d/1Afjs72T43nN0J5DK6qiaKmIthOjhK8_bvrac6E56Bcc/edit#
<jdstrand> zyga: what is the motivation for this? does it provide snap-confine cleanups? (if so, what?) does it allow use to clean up other parts of the system? (if so, what?)
<zyga> to the point that we may end up having no wrappers (and /snap/bin might just contain symlinks to /usr/bin/snap
<zyga> jdstrand: it unlocks hook
<zyga> hooks
<mvo> tyhicks: yeah, the u-c-l (snap-confine) really now only needs to deal with the essential stuff, everything else is done in go
<zyga> sidesteps environment
<zyga> so that we can cleanly set environment for the process
<zyga> and makes launchers mostly redundant
<jdstrand> ah, that doc is helpful
<jdstrand> is it up to date?
<tyhicks> I hope the environment stuff isn't the main motivation
<zyga> tyhicks: I don't actually know, I think the main motivation is to clean up the command line part
<tyhicks> I'm about to SRU the apparmor changes that would allow the launcher to set up the environment
<zyga> so snap run looks nice
<jdstrand> tyhicks: it sounds like hooks is the price of admission
<zyga> as do all the things after that
<mvo> jdstrand: its up-to-date to the point of "previous dicussion"
<ara> zyga, kudos to your post about first contribution to snapd <3
<ara> zyga, maybe you can try to get the people at https://twitter.com/yourfirstpr to tweet about it
<zyga> ara: :-) when I saw that bug I just said "this has to be something other people can contribute"
<zyga> ara: will do
<zyga> tyhicks, jdstrand: that's all I had
<zyga> I think you are in the loop now :)
<jdstrand> tyhicks: so, I think in terms of security, this is good, if a little twistier. it reduces the number of lines of setuid code a bit
<jdstrand> but the setuid code is at least not twistier
<tyhicks> jdstrand: reducing the amount of code in the setuid launcher's address space is a good thing
<jdstrand> tyhicks: what was the env bits to the launcher you were talking about? the safe/unsafe stuff?
<tyhicks> jdstrand: also, this alleviates the launcher from needing to continually expand to do more things (stuff can go into snap-exec)
<jdstrand> well
<jdstrand> some stuff
<jdstrand> if it is root-stuff, then not so much
<tyhicks> jdstrand: yes, the safe/unsafe stuff that should land in lp:apparmor today
<tyhicks> sure
<jdstrand> ie, this doesn't help your mount code
<tyhicks> privileged stuff has to go into snap-confine
<jdstrand> yeah
<tyhicks> but stuff that doesn't require privs, such as parsing the yaml and/or setting up the env, can go into snap-exec
<jdstrand> which is a lot of what we've been doing, but I realize it isn't all everyone's been doing
<jdstrand> yes, that is good
<jdstrand> of course, the safe/unsafe is unneeded now, correct? since snap-exec will do it all and it is after dropping and past the exec barrier
<jdstrand> assuming I understand correctly-- if you can parse the yaml, you can setup the environment however you need to
<jdstrand> which snap-exec is in the position to do
<tyhicks> jdstrand: safe/unsafe is now unneeded for snappy but someone else will hit this issue during the life of 16.04 and the code is already finalized so I'm going to SRU it
<jdstrand> tyhicks: yes, I agree. just trying to make sure I understand
<slangasek> zyga: where is snap-confine, so that I might submit it?
<zyga> slangasek: github.com/ubuntu-core/snap-confine
<zyga> slangasek: it will move to snapcore later but just fork and submit away :)
<jdstrand> tyhicks: so I think I understand the snap-confine to snap-exec attack surface (it isn't appreciably different-- we are already under confinement and actually, snap-confine should be able to lose exec on code in /snap
<tyhicks> jdstrand: if snap-exec ends up getting its own profile, rather than using the profile of the app, then safe/unsafe would be required again
<jdstrand> tyhicks: that is what I was trying to tease out
<jdstrand> so today, we have the launcher that is confined calling the wrapper script
<slangasek> zyga: thanks
<jdstrand> with this, snap-run is unconfined, called snap-confine (confined) which changes profile to the confinement of the app and calling snap-exec <app>
<jdstrand> s/called/calling/
<jdstrand> snap-run doesn't need any provileges
<zyga> correct
<jdstrand> privileges beyond calling snap-confine
<zyga> one complication is that snap-exec will be from the OS snap
<zyga> not from the snapd package
<zyga> unless we do bind mount trickery to prevent that but I think that's okay as it is pretty well defined
<jdstrand> systemd unit's exec is still controlled (snap-run now instead of snap-confine). there is no wrapper, but the code needs to be written to make sure it call snap-confine with the correct args
<zyga> jdstrand: it would call snap run
<jdstrand> snap-confine if from the os snap
<zyga> jdstrand: all systemd units would just say "snap run $snap.$app --command=..."
<jdstrand> right, I get that
<zyga> jdstrand: AFAIR that's the agreement but I may be missing bits
<zyga> (it's not a big change)
<jdstrand> I may not have said it clearly that I understood that
<zyga> but yes, this has to migrate
<zyga> sorry then :)
<jdstrand> I'm trying to understand the attack surface
<jdstrand> systemd unit's attack surface is unchanged
<jdstrand> is all I meant
<jdstrand> tyhicks: so, snap-run is resolving its argv[0] to decide how to invoke snap-confine
<tyhicks> right
<jdstrand> tyhicks: obviously the code has to be correct, but I don't see that as any different from being able to run the wrapper or more to the point, running ubuntu-core-launcher today
<tyhicks> agreed
<tyhicks> jdstrand: the user can still run snap-confine directly
<jdstrand> right
<tyhicks> jdstrand: snap-confine will still have to do checks to make sure the arguments passed to it are safe
<jdstrand> and things running under snap-confine still can't run snap-confine, like today can't run ucl
<jdstrand> tyhicks: of for sure
<jdstrand> tyhicks: snap-confine needs to continue to be very carefully written
<tyhicks> yep
<jdstrand> and confined
<tyhicks> agreed
<jdstrand> but I don't see a reason to confine snap-run
<zyga> do we have to change anything in the apparmor profile for snap-confine?
<jdstrand> yes
<tyhicks> jdstrand: I don't either
<jdstrand> we can remove some stuff and need to add something to exec snap-exec
<zyga> jdstrand: I did some experiments and I didn't have to add anything
<zyga> jdstrand: is it possible that this is covered by /snap/** r, rule?
<jdstrand> no
<jdstrand> those would be symlinks
<jdstrand> to snap-run
<jdstrand> so you would've had to add a rule for snap-run to run those (which we will not)
<zyga> I mean snap-confine executing snap-exec
<zyga> I did an expeirment and I ended up with no permission chages required to do that
<jdstrand> zyga: perhaps it is working for you because it is running unconfined? that would happen if you changed the name to /usr/bin/snap-confine but didn't change the profile to have: /usr/bin/snap-confine (attach_disconnected) {...
<zyga> jdstrand: I was running out of master snap-confine (which currently uses snap-run)
<zyga> (as the name)
<jdstrand> I can't say why it worked for you. I can only speculate. you'll need snap-exec and we'll be able to remove several rules
<zyga> in any case, baby steps, mvo has all of the hard work done and we can see when that lands, what is the next step
<jdstrand> if you can come up with a reproducer for it working now when it shouldn't, I can walk through what is happening
<zyga> jdstrand: can you check if the way I patched maintainer scripts to handle the launcher rename is correct?
<jdstrand> zyga: where is that PR?
<sethj> well thanks for the help qengho! copy worked and it snapped successfully.
<zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c
<sethj> now I just need to figure out how to include a font/theme so the text shows up..
<jdstrand> boy
<jdstrand> I wonder why people aren't using apparmor_parser there
<zyga> jdstrand: apparmor_parser --remove didn't work because it wanted to parse the now-gone file
<sborovkov> Hello, how can I get snap preinstalled on the image with snappy? Can that be done with ubuntu-device-flash? Or is it supposed to be done in some other way?
<zyga> sborovkov: hey
<zyga> sborovkov: not yet :)
<zyga> sborovkov: it will be with ubuntu-image I'm working on with a few other brave souls
<zyga> sborovkov: if you have some spare time help is appreciated
<zyga> sborovkov: I can point you the way to the code and tell you where we are
<jdstrand> zyga: it's wrong
<sborovkov> zyga: understood I don't have a lot of time, need to get application we are doing working on snappy...
<jdstrand> oh wait
<zyga> jdstrand: mmm?
<qengho> sethj: you're welcome! make awesome stuff!
<zyga> sborovkov: no worries, we'll get to it in ~1/2 weeks
<didrocks> sergiusens: when I do try to run integration tests, I always have issues with the 15.04 image creation
<didrocks> sergiusens: any hint?
<zyga> jdstrand: can you say what is wrong and how it should look like instead?
<zyga> slangasek: https://github.com/ubuntu-core/snap-confine/pull/15
<didrocks> kyrofa: elopio: hey, maybe you will know about snapcraft integration tests ^ (no way for me to run them locally due to u-d-f wanting to create the 15.04 image)
<zyga> slangasek: and have a look at https://github.com/ubuntu-core/snap-confine/pull/14 please, I'd like to land it to iterate on top
<zyga> didrocks: get mvo's udf and stick it in /usr/local/bin
<didrocks> zyga: I'm pretty sure I tried this, but let me retry
<zyga> didrocks: same issue as with snapd tests
<jdstrand> zyga: yes it is wrong. See https://github.com/ubuntu-core/snap-confine/commit/3b85e3ec42a2ac837be48f78005d78248903161c#commitcomment-17681678
<didrocks> zyga: still http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash, right?
<zyga> didrocks: yes
 * didrocks gives it a try
<zyga> jdstrand: ah
<jdstrand> zyga: what was committed won't match
<zyga> jdstrand: that was a suggestion from tyhicks :)
<zyga> jdstrand: I'll commit your version right away
<zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/16
<didrocks> zyga: yeah, so I'm getting:
<didrocks> INFO:demos_tests.testbed:Creating a snappy image to run the tests.
<didrocks> building 15.04 core images is no longer supported. Please use the ppa:snappy-dev/tools 15.04 version of this tool
<didrocks> subprocess.CalledProcessError: Command '['sudo', 'ubuntu-device-flash', '--verbose', 'core', '15.04', '--channel', 'stable', '--output', '/tmp/tmpfu0iwno7/snappy.img', '--developer-mode']' returned non-zero exit status 1
<didrocks> with $ sudo which ubuntu-device-flash
<didrocks> /usr/local/bin/ubuntu-device-flash
<didrocks> (mvo's version)
<jdstrand> zyga: thanks, responded
<zyga> didrocks: well, you still call it with 15.04 bits
<jdstrand> zyga: also, thank you for getting tyhicks and me up to speed on the the changes
 * tyhicks scratches his head
<didrocks> zyga: snapcraft doesâ¦
<zyga> didrocks: ah, then that's snapcraft to tweak then
<didrocks> so I don't know how to run my integration tests on 16.04, which is issue
<tyhicks> I tested that grep command that I provided
<didrocks> I guess there is a reason they are calling out 15.04 :p
<tyhicks> I must have pasted in the wrong command :/
<zyga> tyhicks: is it possible that you got grep=egrep alias?
<zyga> anyway, I'm glad this had more eyes on it :)
<tyhicks> nope
<tyhicks> I rarely use egrep and definitely didn't use it while testing
<tyhicks> sorry for the screw up
<jdstrand> maybe there was a way to do it without egrep... anyway, that one works
<tyhicks> ah, the + needs to be escaped
<tyhicks> $ sudo grep '^/usr/bin/ubuntu-core-launcher ([[:alpha:]]\+)$' /sys/kernel/security/apparmor/profiles
<tyhicks> /usr/bin/ubuntu-core-launcher (enforce)
<tyhicks> anyways, egrep is fine
<sergiusens> didrocks no need to run udf for integration tests
<sergiusens> didrocks for example tests, we support testing on classic
<sergiusens> elopio ^
<didrocks> sergiusens: is there any example for this?
<sergiusens> didrocks but you can also just --skip-install
<sergiusens> didrocks for integration_tests just ./runtests.sh integration
<didrocks> sergiusens: yeah, I just wanted to run them in some way rather than sending that to the machinery everytime :)
<didrocks> sergiusens: yeah, those are running, so your comment is that one integration test is failing, you think?
<sergiusens> didrocks I really think so
<didrocks> that's possible, the fact that we don't fake the terminal sizeâ¦
<zyga> joc_: hey, did you get past the testing issues?
<sergiusens> didrocks `python3 -m unittest -v -b run integration_tests.test_list_plugins`
<didrocks> sergiusens: ah yeah, there is one :)
<didrocks> sergiusens: yep, will fix it and push
<joc_> zyga: yes thanks, sorted now
<didrocks> sergiusens: I need to think how we can have it in an terminal-independent size though
<didrocks> sergiusens: as it will be different on jenkins
<sergiusens> didrocks the ones that require u-d-f are the "demo" tests fwiw
<didrocks> sergiusens: yeah, and "tour" one (soon ;))
<sergiusens> didrocks `python3 -m demos_tests --help`
<didrocks> ok, so --skip-install
<didrocks> sergiusens: I'll fix and try to fine something to not be terminal-size dependent on the integration one
<sergiusens> didrocks or `SNAPCRAFT_FROM_INSTALLED=1 python3 -m demo_tests`
<sergiusens> didrocks that will install to classic
<didrocks> oh nice :)
<sergiusens> didrocks which is what we do in debian/tests/demostests
<didrocks> ah, for the adt testbed
<sergiusens> yup
<didrocks> sergiusens: just pushed a fix, it seems to be independent already of terminal size, we'll have to see how it goes under jenkins though once the tests run
<zyga> jdstrand, tyhicks: so how shall we call the new backend "modprobe" backend?
<tyhicks> zyga: is that something we need? I don't know if I've heard about those plans yet
<kyrofa> didrocks, are you still around?
<sergiusens> didrocks maybe `isatty` and affect the result accordingly
<sergiusens> but let's see
<jdstrand> tyhicks: I'll explain. remember how iptable_filter and ip6table_filter don't autoload but once loaded netfilter modules load fine?
<jdstrand> tyhicks: the backend zyga is talking about is an idea I had and presented to niemeyer and zyga that we agreed is a good idea. basically, there is an additional backend that an interface may implement but most would not
<jdstrand> tyhicks: so in the case of firewall-control, it would implement this new module backend and when a snap connects to firewall-control, snapd looks at the backend for the list of modules to load for the interface to be at all useful
<jdstrand> tyhicks: snapd will then drop a file into /etc/modules-load.d for reboots and load the modules on first connection
<jdstrand> tyhicks: in this manner, snaps niether get to specify the modules to load themselves (or there options) nor have SYS_MODULE, etc
<jdstrand> tyhicks: like with security policy, dbus policy and udev rules, snapd has a hardcoded list of what it will make sure is loaded
<jdstrand> tyhicks: as it turns out, this is likely useful for modem-manager as well as firewall-control
<zyga> tyhicks: yes, probably for modem manager
<jdstrand> tyhicks: you may recall snappy config ubuntu-core allowed for the admin/gadget developer to specify modules to load on a particular device. I suspect that may still be useful, but integrating into interfaces in this manner has a way better user experience
<jdstrand> tyhicks: the first iterations will only deal with a list of modules to load (ie, no options or other stuff). if we need that other stuff, we can look at it when requested
<jdstrand> zyga: I was initially thinking that rather than trying to maintain a single file in /etc/modules-load.d, snapd would manage one file per interface (so, snap.firewall-control, snap.ppp (or something)). I'm not married to it, but it seems consistent with other parts of the system
<zyga> jdstrand: I'll think about it, a single file might be easier on SD cards and it's all the same technically (otherwise)
<jdstrand> zyga: that said, garbage collection would be something to consider (removing those files on snap disconnect) and perhaps that isn't the best approach
<jdstrand> (just some random thoughts I had)
<zyga> jdstrand: on disconnect or connect we always rewrite the file after computing the content it has to have
<zyga> jdstrand: so it's not a problem to use one file unless that file would be huge but I don't think it is a problem here
<jdstrand> that's true
<jdstrand> probably actually easier in this case
<jdstrand> zyga: I think I prefer 'kernelModules' instead of 'modprobe'
 * tyhicks was lunching
<tyhicks> jdstrand: so snaps will not be able to provide their own modules - it'll only be modules shipped by the kernel snap?
<jdstrand> tyhicks: app snaps can't do anything with modules directly. all they can do is 'plugs: [ something ]' where the 'something' interface may define modules that snapd will load
<jdstrand> tyhicks: and snaps can't influence what is loaded or how
<nimoov> exit
<tyhicks> jdstrand: ohhh, I understand now
<ogra_> jdstrand, zyga, please dont forget about possible module options ;)
<jdstrand> I mentioned that. at first it is just a list. when there is something that needs options, we can expand
<zyga> jdstrand: ay, will do
<almejo_> Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?
<almejo_> like snap --forece remove <snap>
<almejo_> i can not delete packages becouse they are mounted
<almejo__> Hi... please please help me. I am using ubuntu 16.04 and a snap faild to uninstall. Now I can not uninstall nor install packages. IS there a way to remove all snaps and start from the beginig?
<sergiusens> zyga ^
<sergiusens> seems to be something widespread
<sergiusens> maybe we should add mention of your branch to /topic
<thibran> hello, someone there?
<sergiusens> thibran what's up?
<thibran> I solved a snap bitsize bug
<thibran> and now I would like to get it merged, but have some questions
<thibran> to sign the contributor agreement, I need a 'project contact'
<thibran> how do I get one?
<sergiusens> thibran let me check, but for starters you can start getting the PR up
<sergiusens> kyrofa you've been dealing with CLAs lately, where should it go to?
<sergiusens> thibran a review is not blocked by the CLA
<thibran> k
<thibran> than I upload the code
<sergiusens> thibran yeah, get your toes in technically first, leave the paper work for last :-)
<thibran> https://github.com/snapcore/snapd/pull/1249
<thibran> I hope I got the i18n stuff right, my compiled bin works
#snappy 2016-06-01
<ePierre> Hi there
<ePierre> I'm checking the snappy articles on developer.ubuntu.com and I saw a few mistakes
<ePierre> https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-advanced-features/ â references a 'examples' directory that is no longer. It has been replaced by a 'demos' directory
<ePierre> https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ â there is a formatting problem down around "Some more suggestions in our docs"
<Fart> i want a chicken nugger and a french fried
<stevebiscuit> haha
<zyga> ePierre: can you please open bugs on that and poke dholbah or mhall119 about this
<zyga> sergiusens: looking
<ePierre> zyga, ok! Do we have a project for the developer portal?
<zyga> ePierre: perhaps, I don't know, target snappy on launchpad and they can get re-assigned
<zyga> ara: o/
<ara> hey zyga!
<zyga> ara: it was worth putting that post up :-) There's already a person interested in contributing
<ara> zyga, cool :)
<noizer> zyga You know about my problem with the tmpfs dir that isn't large enough. can I resize that so I can develop further?
<zyga> noizer: tmpfs is using a fraction of your ram, unmount it and use regular storage there
<zyga> noizer: it's probably setup by /etc/fstabl
<zyga> noizer: it's probably setup by /etc/fstab
<RzR> hi
<RzR> Any artik owners around ?
<RzR> how to build artik5-snappy-20160317 ?
<zyga> RzR: hi, sorry I don't have an artik around
<ePierre> didrocks, hey! Thanks for your answer on the snapcraft mailing list!
<ePierre> didrocks, I thought by default, when using "python3", snapcraft would try to go to PyPi and download the latest available release. This is what it seems to do, so I'm not sure what the source would be for... But I'm gonna try anyway
<didrocks> ePierre: no, it doesn't know about the source, you can point it to a tar (and avoid naming the package)
<popey> Is it possible to have a part which just pulls data from an external source and puts it in the snap? Like a copy plugin, which does a git clone?
<popey> I can't figure an easy way to do this, but maybe I need more coffee
<didrocks> ePierre: so just use source: and point it to your tar, then setup.py will be run
<didrocks> popey: in copy plugin, you can do it
<didrocks> and use source:
<didrocks> then files: ['*': '.']
<popey> oooh
<didrocks> (yeah, I tried to argue that being useless and default should copy everything)
<didrocks> I tried a long time, but failed
 * popey tries this
<popey> hm, it doesn't like your format of files
<popey> Issue while loading plugin: properties failed to load for fgdata: [{'*': '.'}] is not of type 'object'
<didrocks> oh sorry, it's rather:
<didrocks> files:
<didrocks>   - '*': '.'
<popey> ah
<didrocks> my bad ;)
<popey> same error
<didrocks> oh?
<popey> yeah
<didrocks> popey: mind pastebining it?
<popey> sure
<popey> didrocks: lp:~popey/+junk/flightgear
<didrocks> sorry no "-"
<didrocks> files:
<didrocks>   '*': '.'
<didrocks> it's a dict :/
<didrocks> my fault
<zyga> popey: use make
<zyga> popey: git + make == bliss ;)
<zyga> oh, I see didrocks gave a better example :)
<popey> ahhh
<popey> thanks chaps :)
<popey> .oO( Wish I had a local cache for github like I have a cache for apt )
<didrocks> yw!
<vejmarie> Hi guys, I am closed to have fully debugged Freecad snap
<vejmarie> I still face some issue with locales
<vejmarie> got GTK-Warning: locale not supported by C library
<vejmarie> any idea on how to workaround this ?
<vejmarie> I have connected the application to locale-control but still the same issue
<noizer> zyga its not set in the /etc/fstab file
<noizer> zyga ow excuse me my mistake
<ogra_> zyga, noizer, fstab is generated by the initrd from /etc/system-image/writable-paths at boot
<noizer> ogra_:  Ok then its not good to change it there.
<ogra_> you wont be able to
<ogra_> it is readonly
<ogra_> (inside the snap)
<noizer> ogra_: I Changed it with a chrooted xenial
<noizer> ogra_: But how can i fix the no space left issue for now (just for development)
<ogra_> i dont know, you could try to unmount /tmp or some such ... so the disk is used ... but that will likely break everything that currently uses /tmp
<ogra_> so not sure that can work at all
<noizer> I'll give it a shot
<ogra_> i suspect it will just break the world ... so you will have to wait til snapd learns to use a different temp dir to unpack
<zyga> noizer: or bind mount /var/tmp over /tmp
<ogra_> bit try it :)
<ogra_> **but
<noizer> zyga I did that : sudo mount --bind /tmp/ /var/tmp/
<noizer> zyga but without any succes
<zyga> that's the other way around :)
<noizer> zyga ogra_ Does the desktop version got more memory over there?
<zyga> noizer: it's not desktop vs anything
<zyga> noizer: it's just that tmpfs is a ram-based filesystem
<ogra_> well
<zyga> noizer: so if you have 1GB of ram it will allow a fraction of that to be used to store files
<ogra_> the desktop version might find more ram :)
<ogra_> since your desktop is likely to khave mmore than a rpi
<noizer> ogra_: OK i will try that
<noizer> ogra_: where  can I find the desktop image?
<ogra_> there is no image
<ogra_> snapd runs on the desktop and installs the core snap
<ogra_> when you execute a snap app it gets run inside that env
<popey> ooh, managed to make a 1.2GB snap. Fun :)
<zyga> popey: what's in it?
<ogra_> data !
<ogra_> (and little planes i guess)
<zyga> lt cmd data!?
<ogra_> haha
<noizer> ogra_: huh how? I don't understand
<ogra_> snaps are executed inside the core snap
<ogra_> (this is why it gets installed automatically when you install your first snap on a desktop)
<noizer> oooh okay
<ogra_> mvo, is there any reason for us to still have snappy_ab= inside uboot.env.in ? (i just noticed thats still there)
<popey> zyga: flightgear
<thibran> zyga, I got a patch for the bite-size snappy bug and a PR, what is left to do? https://github.com/snapcore/snapd/pull/1249
<mvo> ogra_: no, that can go
<ogra_> yeah, thought so
<ogra_> thx
<zyga> thibran: hey
<thibran> hi
<zyga> thibran: looking :-)
<zyga> thibran: looks good
<zyga> thibran: if you want to go all the way I can show you how to add a simple test for this
<thibran> yes, why not
<thibran> (I'm a IRC n00b)
<zyga> thibran: look at this file: https://github.com/thibran/snapd/blob/e3b02f8807934eec904d1dd81e67608f67137c98/cmd/snap/cmd_list_test.go
<zyga> thibran: copy-paste the TestList function, call it TestListEmpty
<zyga> thibran: in the copy-pasted function, change the copy of this line https://github.com/thibran/snapd/blob/e3b02f8807934eec904d1dd81e67608f67137c98/cmd/snap/cmd_list_test.go#L39
<zyga> thibran: to return empty results there...
<zyga> 			fmt.Fprintln(w, `{"type": "sync", "result": [{"name": "foo", "status": "active", "version": "4.2", "developer": "bar", "revision":17}]}`)
<zyga> change it to
<zyga> 			fmt.Fprintln(w, `{"type": "sync", "result": []}`)
<zyga> finally change the copy pasted version of this line https://github.com/thibran/snapd/blob/e3b02f8807934eec904d1dd81e67608f67137c98/cmd/snap/cmd_list_test.go#L49
<zyga> to read something like c.Check(s.Stdout(), Equals, "")
<zyga> then run go test
<zyga> and see what it really says (the test should fail)
<zyga> and paste that thing in to the "" :-)
<zyga> try that, if you need anything, just ask
<zyga> thibran: how's it going?
<thibran> zyge, have truouble running the test in go (dont know right now why)
<zyga> thibran: what happens when you run "go test" from the cmd/snap directory?
<thibran> works, but it shouldn't
<zyga> thibran: can you git add the code
<zyga> and push it
<zyga> I'll have a look
<zyga> git add -p
<zyga> then you see what you are adding, very useful :)
<thibran> I dont understand, u want me to push the broken test?
<zyga> thibran: yes
<zyga> thibran: I just want to see it
<zyga> thibran: don't worry, it's not a problem
<thibran> done
<zyga> thibran: reading
<zyga> let me try to run it
<zyga> thibran: btw, did you see my 2nd post about how to set up development environment?
<zyga> thibran: if it passes for you it may do so because you are still running the "stock" version of snap source code in reality
<thibran> yes
<thibran> I moved the forked repo into the name-space of the official repo
<zyga> ah
<zyga> I see what happens
<zyga> zyga@x200t:~/work/src/github.com/snapcore/snapd/cmd/snap$ go test
<zyga> No snaps are installed yet. Try 'snap install hello-world'.
<zyga> No snaps are installed yet. Try 'snap install hello-world'.
<zyga> OK: 63 passed
<zyga> PASS
<zyga> ok  	github.com/snapcore/snapd/cmd/snap	0.944s
<zyga> we have a small thing in place to let us "redirect" (but not really) stdout for testing
<thibran> let me guess, I have to use tabWriter?
<zyga> thibran: http://paste.ubuntu.com/16887305/
<zyga> no, you just have to use Fprintf and print to Stdout :)
<zyga> then the test fails and you can fix it
 * zyga -> lunch
<zyga> thibran: push the code when ready, I think it will land shortly :-)
<zyga> thanks a lot for being here and welcome :-)
<thibran> thanks for the help and the kind words
<thibran> I signed the CLA, do I have to do anything to connect my launchpad account with my github account?
<kyrofa> thibran, just make sure the email address you used to commit is on your LP account
<Odd_Bloke> So I'm using snapcraft to create a snap; I'm using the copy plugin, and I need Python installed.
<Odd_Bloke> I've added `stage-packages: [ python ]`, and when I run `snapcraft snap`, it goes off and does an apt-get update.
<Odd_Bloke> However, it uses my host's sources.list.
<Odd_Bloke> Doesn't this make the build difficult to reproduce in another location with a different sources.list?
<Odd_Bloke> And, next question: I'm now seeing a "Bad system call" error from the app I'm snapping; is there a good way for me to identify what's causing that (debug logs etc.)?
<popey> Odd_Bloke: dmesg | grep <appname>
<popey> probably find something at the bottom of that which indicates which system call is being used/abused
<Odd_Bloke> Aha, it looks like Python is being denied some things.
<Odd_Bloke> Specifically: http://paste.ubuntu.com/16888573/
<Odd_Bloke> OK, so I'm seeing: ... apparmor="DENIED" operation="exec" profile="snap.google-cloud-sdk.gcloud" name="/sbin/ldconfig" pid=3420 comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
<Odd_Bloke> But /snap/google-cloud-sdk/current/sbin/ldconfig exists which I would expect to be usable (and the thing that is used).
<Odd_Bloke> What am I missing here?
<ogra_> /sbin/ldconfig != /snap/google-cloud-sdk/current/sbin/ldconfig
<ogra_> you are not in a chroot ;)
<ogra_> use ./sbin/ldconfig or sbin/ldconfig
<ogra_> (or the full path)
<Odd_Bloke> ogra_: Hmm, I _think_ it's Python that's making that call, any ideas how to instruct it to use the correct path?
<ogra_> well, python doesnt do that in other snaps
<ogra_> at least i havent heard of it
<zyga> re
<Guest40102> does anyone know if I can install ubuntu onto my HTC one M8#?
<ogra_> Guest40102, not with snappy :) (wrong channel, i guess you want #ubuntu-touch)
<zyga> ogra_: not _yet_ ;-)
<ogra_> yeah :)
<RzR> hi any artik5 owners in this channel ?
<ogra_> i think didrocks has one
<vejmarie> launching ubuntu-core-launcher snap.freecad.FreeCAD snap.freecad.FreeCAD /usr/bin/locale -a returns me C, C.UTF-8 and POSIX
<vejmarie> any idea on why I do not see the other locale ?
<vejmarie> I have change the app armor configuration to get access to the locale-archive but without any success
<zyga> vejmarie: did you try to add locale to your snap (in snapcraft)?
<vejmarie> yep it is inside
<zyga> hmm
<vejmarie> it looks like more an issue regarding access to the locale archive
<popey> didrocks: here's an odd one for you. I think I found a bug in the files copy thing. It seems to sometimes erroneously copy directories to the wrong place...  http://paste.ubuntu.com/16889987/
<vejmarie> on the host I got all my locale through locale -a
<vejmarie> but it is currently impossible to get access to the locale within the snap
<zyga> maybe ogra_ remembers our locale conversation, but I don't know how to fix that; I think everyone solves this somehow but details elude me
<vejmarie> I am trying to find out what we are missing
<vejmarie> i am connected to the locale-control interface
<ogra_> zyga, well, i guess you would need something that calls locale-gen in the snap before snapping it to get other languages
<RzR> ogra_, thx I'll ping him
<ogra_> though even that is probably not enough
<vejmarie> ogra_: I tried it but still no way to make it work
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh
<ogra_> this is what i use to make loacles work in my nethack package
<ogra_> (currently not buildable, it is still using the old pre-interfaces snapcraft.yaml)
<vejmarie> let me try that
<vejmarie> thanks will tell you if it works !
<ogra_> i have libc-bin, console-setup-linux and locales in my stage packages
<ogra_> line 7-21 in the nethack.sh script then actually set the locale before executing the game
<qengho> If I run a snap that quits with "Bad system call" in normal mode and runs successfully in devmode, I should expect some message in klog about the syscall being refused, right?
<vejmarie> ogra_: yes I have seen that
<vejmarie> I believe that my I18NPATH was wrong I pointed out to usr/share/il8n/locales instead of the parent dir, I am rebuilding my snap will tell you what it gives !
<ogra_> good luck :)
<vejmarie> ogra_: thanks
<ysionneau> sergiusens: https://github.com/ubuntu-core/snapcraft/pull/435 what's happening with  autopkgtest? I can't see the "details"
<Guest40102> Ok thanks for telling me ill wait to hear something about iut
<qengho> elopio: of the edge ppa you mentioned in -tech mailing list, should its version number be behind what is in x?  foo, versus foo~ppa42
<Odd_Bloke> Oh, OK, I actually needed the network-bind plug to make that error go away.
<noizer> zyga is it possible to install a lubuntu-desktop in a snap and get so an userinterface
<noizer> ?
<zyga> noizer: put all of lubuntu-desktop in a snap?
<zyga> noizer: maybe but then the integration with othe snaps wouln't be there really
<zyga> noizer: yes but that's a lot of work and has many prerequisites
<noizer> zyga maybe you have a other idea. I want to add a screen on my raspberry pi to view some things but for this there is a UI needed for
<ogra_> you wuold laso need to have a working xserver (or Mir)
<ogra_> *would also
<zyga> noizer: yeah, get a mir/x snap in place and stick it there
<noizer> zyga ok I will look into mir snap
<noizer> ty ogra and zyga
<vejmarie> ogre_: I got a localdef permission denied
 * zyga sees ogre
<vejmarie> ogra_: sorry
<ogra_> vejmarie, hmm, probably use the relative path in your script then
<vejmarie> ok
<ogra_> to make it use the localedef inside the snap
<ogra_> (as i siad, that nethack package comes from a time where we had diffeent security rules, it can well be that localedef isnt accessible anymore while it was back then)
<vejmarie> ogre_: I believe yes :(
<vejmarie> I am not sure that the current security rules allows to support locale
<vejmarie> which might be an issue for some application and translation
<ogra_> it surely does ... but you cant run the localedef from the os
<ogra_> (which my script does)
<vejmarie> why don't we allow to read the locale ? Where is the security issue there ?
<vejmarie> because presenting an app in english to a chinese person or french is not a good idea
<ogra_> the issue is that i.e. ubuntu-core doesnt have locales installed
<vejmarie> ogra_: yes I have seen that
<vejmarie> (this was the first place I looked at ;))
<vejmarie> but snapy should probably rely on the locale settings of the user who launch the snap
<ogra_> your snaps run inside ubuntu-core by default ... on classic interfaces can provide you bits from the outside world though
<vejmarie> yes, I have copied the locales into my snap, but it looks like that ubuntu-core setting is getting rid of this :(
<zyga> jdstrand, tyhicks: any objection for merging https://github.com/ubuntu-core/snap-confine/pull/14
<sergiusens> ysionneau that is behind a vpn, you can as elopio for exact details of what you are hitting
<tyhicks> zyga: hey - just got out of a meeting - let me have a look
<zyga> tyhicks: thanks
<sergiusens> Odd_Bloke there's `snapcraft cleanbuild` that does an isolated build
<sergiusens> Odd_Bloke wrt python I suggest looking at the python plugin. That ldconfig is probably run due to missing library paths. Another suggestion (I've been told it was easy to do). Is just grab python from sources.
<Odd_Bloke> sergiusens: The python{2,3} plugins look like they expect a setup.py; I don't have one for this. :(
<zyga> Odd_Bloke: add one!
<zyga> it's mostly trivial
<sergiusens> Odd_Bloke oh, launch your app in a snap
<sergiusens> Odd_Bloke with the env vars as if it "were" created from the python plugin
<jdstrand> zyga: I don't have an objection to it per se, but the timing isn't great. also, shouldn't it be s/snap-run/snap-confine/ for the binaries?
<zyga> jdstrand: that's piled in another branch
<zyga> jdstrand: can you tell me more about the timing?
<noizer> zyga can a webbrowser been shown in a mir snap?
<jdstrand> just the various branches that are in flight. people have to adjust for stuff (again)
<sergiusens> Odd_Bloke create the py3-example snap and copy the exported vars that show up in the snap directory (command nd wrapper are in the script names)
<jdstrand> it isn't the worst thing in the world I just find myself doing a lot of redoing things...
<Trevinho> mvo: hey, you here?
<vejmarie> ok I have been able to make work localdef
<vejmarie> but still have this stupid GTK issue :(
<ogra_> whats that ?
<vejmarie> Locale not supportted by C library
<vejmarie> Gtk-WARNING: Locale not supported by C library. Using the fallback 'C' locale
<vejmarie> might it be coming from the lack of locale in ubuntu-core
<vejmarie> that is crazy because the localedef is also in ubuntu-core
<ogra_> call "env" in your wrapper script and make it log somewhere to see what is actually set
<zyga> noizer: I suspect so though I don't know any details
<zyga> jdstrand: I hope the changes are minimal, only to list new files in Makefile.am
<vejmarie> I think that LC_ALL is properly set but let's try to see how it works
<zyga> jdstrand: btw, can we land the argument filtering branch
<zyga> jdstrand: I saw you made some changes
<zyga> jdstrand: I didn't do a 2nd review but I can do one quickly and we can have that one ticked off
<jdstrand> zyga: I'm not done with my changes. turns out tyhicks's point about the stored data affected 32 bit builds, so I'm fixing that
<sergiusens> vejmarie create an app under `apps` called "shell" and make the command be `bash`. Make sure the `plugs` and others match whatever you want to run
<vejmarie> ok
<zyga> jdstrand: ah, I remember that, the hash table thing
<zyga> ok
<vejmarie> my LOCPATH is set to /home/vagrant/snap/freecad/100001
<jdstrand> zyga: like I said, it isn't a huge deal
<zyga> jdstrand: in that case I'd like to merge the autotooling as is and let you rebase / merge and tweak the two affetcted makefiles
<vejmarie> where there is the en_US.UTF-8
<vejmarie> properly setup by localedef
<vejmarie> my I18NPATH is set tp /snap/freecad/1000001/usr/share/i18n
<jdstrand> zyga: I'm not blocking the autotools merge
<vejmarie> where the i18n data are
<ogra_> vejmarie, and are there locales in /home/vagrant/snap/freecad/100001 ?
<jdstrand> so if others agree-- that's fine
<zyga> jdstrand: thanks
<vejmarie> yes en_US.UTF-8
<zyga> jdstrand: did you review it? anything broken? :)
<ogra_> hmm
<vejmarie> when it does export LC_ALL=en_US.UTF-8
<vejmarie> it is complaining that it can't find the file
<ogra_> vejmarie, well http://manpages.ubuntu.com/manpages/xenial/en/man1/locale.1.html  ... see at the bottom
<ogra_> you might need LANG too
<zyga> ogra_: want to review my autotool branch? I'm really hoping someone more experienced with autoconf/make than I am will say "this looks sane"
<jdstrand> zyga: I didn't review it-- you asked if I had objections to landing it-- that's a different question :)
<ogra_> zyga, and you think that one would be me ?!?
<jdstrand> I mean, I perused it
<zyga> :D
<ogra_> zyga, i can look though
<ogra_> :)
<zyga> ogra_: thanks
<jdstrand> tyhicks: are you looking at the autotools PR? if not yet, do you want me to instead?
<zyga> https://github.com/ubuntu-core/snap-confine/pull/14
<jdstrand> tyhicks: I'm of course fine if you are doing it-- I just didn't think we both needed to do it
<mvo> Trevinho: hey, yes
<tyhicks> jdstrand: I've already left comments
<vejmarie> #!/bin/bash
<vejmarie> export I18NPATH=$SNAP/usr/share/i18n
<vejmarie> export LOCPATH=$SNAP_USER_DATA
<vejmarie> LANG=en_US
<Trevinho> mvo: hey, about the desktop file support in snappy... for unity7, I'd like to reiterate things a little
<vejmarie> ENC=UTF-8
<vejmarie> LOC="$LANG.$ENC"
<vejmarie> # generate a locale so we get properly working charsets and graphics
<vejmarie> if [ ! -e $SNAP_USER_DATA/$LOC ]; then
<vejmarie>   $SNAP/usr/bin/localedef --prefix=$SNAP_USER_DATA -f $ENC -i $LANG $SNAP_USER_DATA/$LOC
<vejmarie> fi
<vejmarie> export LC_ALL=$LOC
<vejmarie> This is what I put into my wrapper (sorry for the whole code)
<tyhicks> jdstrand: I'm going to do a before and after build to compare the logs and then my review will be done
<vejmarie> the export LC_ALL fails :(
<Trevinho> mvo: I mean, things work ok when we launch an app from dash, since we use some startup notification foo to get better results
<mvo> Trevinho: ok, what do you need?
<Trevinho> mvo: however in case of multiple  installed versions or in case we launch something froma  terminal (or from different sources than gio app launcher, using a desktop file) there might be matching issues
<ysionneau> elopio: can you tell me what's going wrong here please ? 162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/813/
<jdstrand> tyhicks: sounds good
<Trevinho> mvo: so, I've prepared a bamf version where if something is launched with BAMF_DESKTOP_FILE_HINT env var, pointing to a desktop fiel, then we use it... overriding any mathcing
<mvo> Trevinho: aha, so we need to put that into the generated desktop file?
<mvo> Trevinho: or how do you envision this to work?
<Trevinho> mvo: not the desktop fiel, but in the automatically generated launch script.
<Trevinho> mvo: is that something possible?
<mvo> Trevinho: I need to look at it, it will have to point to the /var/lib/snapd/application/desktop/foo_bar.desktop file (the envvar)?
<Trevinho> mvo: yes
<Trevinho> mvo: I mean actually all the desktop files will point to a script that initializes some SNAP_* env var... Would be possible to make sure that if a .desktop file launches that, then you also add the env var on it?
<Trevinho> err, all the launch scripts actually
<mvo> Trevinho: ok, doable but a bit of work, when we generate the env vars we will need need to iterate over the dekstop files and match there. so yes
<mvo> Trevinho: I add a trello card for this
<Trevinho> mvo: thanks, I wanted to know whether a bug or a card was better, but... well, what's work best for you
<mvo> jamiebennett: how would you like to track additional requirements like the one above? trello? bugs? if trello, which board?
<mvo> Trevinho: I have no strong preference, but I want to double check with jamie first :)
<Trevinho> mvo: I could even try to help in doing this, but my go or snappy knowledge isn't the best yet... So I could do with training :-)
<mvo> Trevinho: ha! deal! happy to train you - go is really fun and the codebase is quite nice
<jamiebennett> mvo: Trello is best as that is what most people are tracking on a daily basis
<jamiebennett> The Vancouver board is getting new requirements so add them there
<mvo> jamiebennett: thank you!
<mvo> Trevinho: https://trello.com/c/aEB6d6r0
<mvo> Trevinho: feel free to hack away!
<Trevinho> :)
<vejmarie> Yeees it works !
<ogra_> !
<didrocks> popey: yeah, I guess this happens when you don't clean up first
<didrocks> popey: I guess bug report for kyrofa, he loves the copy plugin :)
<kyrofa> :'(
<ogra_> dont we all ?
<ogra_> vejmarie, what was missing ?
<vejmarie> I had a redefine in my script of LOCPATH which was not pointing anywhere
<vejmarie> good to see FreeCAD fully working into a snap
<sergiusens> vejmarie \o/
<ogra_> awesome
<ogra_> also good to know that shipping your own loacales still works :)
<kyrofa> popey, can I see the YAML you're using?
<popey> kyrofa: lemme try and re-produce it first with a clean config
<kyrofa> vejmarie, nice job! Still in devmode?
<kyrofa> popey, alright, let me know
<popey> will do
<vejmarie> no longer
<vejmarie> I focused on fixing that normally
<ogra_> noce one :)
<ogra_> *nice even
<vejmarie> let me validate that and push it on the store if it works
<ogra_> +1
<popey> kyrofa: ok, reproduced it, http://paste.ubuntu.com/16889987/ https://code.launchpad.net/~popey/+junk/flightgear is the yaml etc
<kyrofa> popey, alright, let me play with it for a sec
<kyrofa> Oh. More than a sec. It's not small
<ogra_> only 1.5G
 * kyrofa grabs some more coffee
<kyrofa> You know it's going to be a long day when the coffee is gone before noon
<popey> :)
<popey> sorry, i should have warned you :)
<kyrofa> popey, haha, it's not a problem
<vejmarie> done published if some of you want test
<kyrofa> popey, can you confirm that parts/fgdata/build looks okay?
<sborovkov> Hello. I have created snap with confinement: devmode in snapcraft.yaml. After doing snap install though I get apparmor "denied" messages. What am I doing wrong?
<vejmarie> (it is still not passing automatic test due to the need to attach home and locale !
<vejmarie> I don't know who is doing the manual review but the process seems long ?
<kyrofa> sborovkov, you still need to install with --devmode
<kyrofa> sborovkov, eventually snapd will catch that and simply say "hey, you need to install with devmode"
<sborovkov> Ah, ok. Thanks.
<popey> kyrofa: parts/fgdata/build looks okay, same as ../src
<kyrofa> sborovkov, there are no plans to automatically put it into devmode (a social security issue, if you will)
<kyrofa> popey, yeah, this looks like a bug. An odd one
<sborovkov> kyrofa: understood. I was just surprised by what's happening
<ogra_> vejmarie, yeah, manual reviews can take very  long
<kyrofa> sborovkov, once the snapd side of things is done I hope it'll be more clear :)
<jdstrand> kyrofa: is snapd going to complain/inform in some manner in that case?
 * jdstrand is curious what it is going to say
<kyrofa> jdstrand, the plan as I understand it is to disallow installation of snaps that say they require devmode unless --devmode is provided
<kyrofa> jdstrand, no idea what the message will actually say. Chipaca is working on it
<kyrofa> jdstrand, and that's assuming of course that I understand correctly
<zyga> hmmm
<jdstrand> interesting. I figured complaining/informing that --devmode wasn't specified and installing as strict made sense. refusing to install as strict... not sure what that is intended to address, but I guess we'll see :)
<kyrofa> jdstrand, I think the idea is that if the developer knows the snap doesn't work under strict confinement, the only experience that can happen is a bad one
<popey> kyrofa: yay!
<kyrofa> popey, I'm not even sure what you'd say in that bug... but do you mind logging one?
<popey> sure thang, against what kyrofa ?
<kyrofa> popey, against snapcraft: https://bugs.launchpad.net/snapcraft/+filebug
<popey> kyrofa: i will try and create a smaller test case :)
<ogra_> one that is only 1.4GB ?
<kyrofa> So helpful ogra_ :P
 * ogra_ grins
<kyrofa> popey, ah, I figured it out
<kyrofa> popey, make `files` be `'*': 'fgdata/'`
<kyrofa> (note the ending slash)
<kyrofa> popey, still a bug obviously, but now I think I know what's happening
<popey> will do!
<popey> thanks kyrofa
<tyhicks> zyga: can you build the autotools branch as a debian package? dpkg-buildpackage fails for me
<ogra_> tyhicks, how
<tyhicks> ogra_, zyga: https://paste.ubuntu.com/16897029/
<tyhicks> dh_install is what fails
<ogra_> looks like it doesnt build anything at all
<tyhicks> it doesn't
<tyhicks> there isn't any compiler output on stdout
<ogra_> right
<tyhicks> I'll leave a comment in the PR
<mvo> jdstrand: do you think you could have a look at https://github.com/snapcore/snapd/pull/1251 ? it looks like python socket using apps on i386 needs this change
<jdstrand> mvo: that is bug 1576066
<ubottu> bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066
 * jdstrand steps away for a few minutes
<elopio> ysionneau: sorry, I missed your ping. Note: Bypassing https://pypi.python.org/simple/file-magic/ (disallowed host; see http://bit.ly/1dg9ijs for details).
<elopio> that's likely our firewall blocking the outside world. I'll make a note to request the firewall exception.
<elopio> sergiusens: kyrofa: all green here: https://github.com/ubuntu-core/snapcraft/pull/532 What else? Get a review from somebody who knows more macaroons than me?
<sergiusens> elopio I believe that is good already, let me have a look again
<sergiusens> or maybe nessita wants to look :-P ^
<elopio> qengho: hello (looking for old pings). Maybe we can now change that version, but the PPA was not made for people in x, it is for our image generators.
<elopio> we might actually need a ppa for people who want to follow what will come to proposed.
<qengho> I like PPA over Proposed because armhf is first class in PPAs. :P
<nessita> sergiusens, is python? if yes I can certainly take a look
<nessita> sergiusens, so facundo will take a look at the PR, he implemented the APIs and the macaroon work
<zyga> tyhicks: thanks for really trying my autotools branch, I fixed the thing you found
<zyga> tyhicks: now running comparative builds
<tyhicks> nice!
<sergiusens> nessita yes, python
<zyga> tyhicks: I'd say now the flags are stronger?
<nessita> sergiusens, colin already left some comments that I think should be addressed
<zyga> tyhicks: http://paste.ubuntu.com/16899272/ the - is the old packaging, + is the new packaging
<zyga> +gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2     -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o snap_run-main.o `test -f 'main.c' || echo './'`main.c
<zyga> -cc -c -D_GNU_SOURCE -O2 -Wall -Werror -g -O2 -fstack-protector-strong -Wformat -Werror=format-security main.c -o main.o
<zyga> jdstrand, tyhicks ^^
<zyga> tyhicks: is this sufficient?
<tyhicks> zzarr: looks like we lost -Wall and -Werror
<tyhicks> oops
<tyhicks> zyga: ^
<zyga> tyhicks: indeed, I can add those
<qengho> ls
<zyga> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Werror     -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c -o snap_run-main.o `test -f 'main.c' || echo './'`main.c
<zyga> tyhicks: fixed
<zyga> tyhicks: note that lintian complains about some hardening things
<zyga> slangasek: around?
<zyga> slangasek: did you fix some of those in ubuntu-core-launcher +1 in debian?
<zyga> http://paste.ubuntu.com/16899643/ (the list I see)
<zyga> tyhicks: merged! thanks for looking :)
<jdstrand> mvo: I commented in the PR but want tyhicks' input since this has been an ongoing prioritization discussion
<zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snap-confine/pull/18/files
<zyga> ideas welcome, should that cover more than apparmor?
<jdstrand> tyhicks: I'll take that ^
<jdstrand> zyga: commenting
<tyhicks> thanks!
<tyhicks> perfect timing
<nessita> sergiusens, hi! who can add facundo to the proper organization so he can comment in the PR?
<zyga> thanks!
<sergiusens> nessita you shouldn't need access for comment afaik
<nessita> sergiusens, ack, thanks, I blindly trusted facundo's comment
<sergiusens> well, thanks for the comments whatever they will be
<mhall119> jdstrand: The "home" interface flags snaps for manual review in the store, what's the plans for that? Is it always going to require manual review, even though it doesn't get connected automatically?
<mhall119> beuno: how long after a snap is published in the store before it's availble in the Software app or in "snap find"?
<mhall119> beuno: ignore me
<jdstrand> mhall119: there are changes coming in that area. home will be autoconnected and under certain circumstances it will be autoapproved
<jdstrand> zyga: so, I can't figure out how to get to a clean state for commiting after the autotools update (without manually removing files)
<jdstrand> zyga: I used to be able to do 'make clean' and then the tree would be clean for committing
<mhall119> jdstrand: can we share the timeline for those changes and the circumstances where it would apply? The krita snap is hitting this issue
<jdstrand> zyga: now I need to run 'debian/rules build' (for autoreconf), do things, etc and when ready to commit, I don't see how to get back to a clean state. I've tried 'clean', 'dist-clean', 'maintainer-clean', 'debian/rules clean', etc. there are files left over
<jdstrand> mhall119: use 'confinement: devmode' and it shouldn't block approval
<beuno> mhall119, ignore you more than usual?  that'll be hard!
<mhall119> beuno: not in a few weeks it won't be :-P
<mhall119> jdstrand: um...that won't block it for approval?
<jdstrand> mhall119: it will autoapprove when specified with unity7 and/or x11
<mhall119> jdstrand: ah, good, krita uses both, so the issue should eventually go away on it's own
<jdstrand> mhall119: no. confinement: devmode and uploading to edge is precisely to not block it for approval
<jdstrand> (for these confinement things)
<mhall119> edge is a channel?
<jdstrand> when you upload, you specify the series (ie, 16) and the channel (stable, ..., edge)
<jdstrand> zyga: I could git ignore them, but I'm thinking this isn't intentional
<jdstrand> mhall119: the review tools changes should be committed to trunk in the next few days and land in the store hopefully end of next week
<zyga> jdstrand: you can try make distclean
<zyga> jdstrand: which files are the problem?
<zyga> jdstrand: I'll get git ignore to behave better for all that autotool cruft
<zyga> jdstrand: I think some of those are intentional but I was expecting dist-clean to remove all of them really
<zyga> jdstrand: anyway, point taken, I'll make it  nicer
<jdstrand> I tried distclean
<jdstrand> debian/rules clean ; make distclean is close, but a few things remain
<ysionneau> elopio: if pypi is not allowed, then how are the "tests" passing then with the other dependencies?
#snappy 2016-06-02
<Gunther_> Good morning!
<Gunther_> Is an expert concerning u-d-f (vivid) available? We have a problem creating an image in Docker container (oem  generic-amd64). The generated image does not boot because it fails to locate the kernel.
<Gunther_> Out of the Docker container the image works. The udev workaround is applied (ln -s /bin/true ...)
<didrocks> Gunther_: hey! I guess ogra_ would be able to help you once he wakes up (few hours from now :))
<Gunther_> thank you. I will wait for him :)
<zzarr> tyhicks, -Wall and -Werror?
<zyga> o/
<Gunther_> didrocks: problem solved, and I did not need ogra :)
<Gunther_> didrocks: the docker container used u-d-f from vivid, whereas the native installation had u-d-f installed from ppa:snappy-dev
<dholbach> would it make sense to have packages have build-essential as an essential part of their build-packages declaration?
<dholbach> it'd certainly simplify things if you're using 'snapcraft cleanbuild' and don't have to spell out things like make, g++ and others
<didrocks> Gunther_: ahah, making sense!
<zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snap-confine/pull/18/files
<tptr> Hi, any word when ubuntu core 16.04 can be expected? (eagerly waiting for the newer docker version...:-)
 * nhaines just waits for the pulseaudio interface.
<zyga> nhaines: it's coming :)
<zyga> nhaines: it's merged and an SRU under way
<nhaines> zyga: \o/
<zyga> tptr: 16.04 is out, you can use snappy on that version directly
<zyga> tptr: as for an all-snap image, those are available as well but aren't finalized so you may need to re-flash a few times as we make big changes
<zyga> tptr: also the tooling around those is evolving so expect ubuntu-device-flash to go away
<nhaines> I have a little script that requires sox and then basically makes the same sound as the Enterprise NCC-1701-D's warp engines... perfect for background noise!  :D
<nhaines> And the moment the pulseaudio interface is available, I'll be all set!
<ogra_> you should make that a commercial app ... you will get rich in no time
<nhaines> ogra_: haha, tempting!
<nhaines> The code *is* available in my book, so a for-pay snap wouldn't be unconsciable.
<tptr> zyga: thx! I am using snappy on an Intel compute stick. So sg like ubuntu-16.04-snappy-amd64-generic.img.xz would b what I am after...
<kyrofa> zyga, images are available? Where are they?
<lool> ogra_, sergiusens: Ah right, I see vejmarie solved the locale issue in the end  :-)
<ogra_> yeah, just answered your mail :)
<ogra_> in fact the locale manpage tells you how :)
<erio> Wait
 * ogra_ waits
<erio> I am having a locale issue too, can someone send links
<erio> ?
<ogra_> http://manpages.ubuntu.com/manpages/xenial/en/man1/locale.1.html
<ogra_> scroll to the bottom
<lool> oh god, people can override locales with env vars
<lool> strings often contain %s and what not
<ogra_> here is also an old snap http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh (currently not functional, not fully proted to 16, but you should get what it does)
<erio> Thanks, favoriting all of this
<erio> https://github.com/ericoporto/fgmkPackaging/blob/master/snap/snapcraft.yaml
<erio> Made a simple test, but was failing on locale
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
<ogra_> you want to ship locale and libc-bin in your snap as well
<seb128> locales are workaroundable
<seb128> code using bindtextdomain() not so much
<ysionneau> tyhicks: Hi! Any news on the ptmx issue?
<erio> Thanks ogra_   !
<ogra_> :)
<jdstrand> zyga: cool, thanks :)
<vejmarie> great my snap has been approved !
<vejmarie> ;)
<ogra_> yay
<vejmarie> but how does users find it ? I thought this was through "Ubuntu software" / Store interface in the GUI ?
<ogra_> using "snap find" on the commandline ... or in the ubuntu-software tool
<eriow> Have you tried searching using snap in command line?
<ogra_> (not sure how fast the db of the tool is wrt getting the info about the new package though)
<zyga> jdstrand: hey
<zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/20
<zyga> jdstrand: trivial one
<zyga> jdstrand: I just have a few patches, I will be working on cleanups in the code, making it nicer and less ifdefy
<vejmarie> yes I see it in snap find ;)
<vejmarie> but not in the software tool
<vejmarie> (yet)
<zyga> jdstrand: we also need to plan for new way to test anything
<zyga> jdstrand: as we'll switch at some point (not today) to execing snap-exec
<zyga> jdstrand: so the command line will almost entirely go away
<zyga> jdstrand: we'll need some test-only environment variable
 * jdstrand nods
<zyga> jdstrand: I guess we can just have a secure_getenv-based test to exec a test playload (command) instead
<zyga> jdstrand: sorry for making so many changes lately, I hope we can land seccomp filtering now
<zyga> jdstrand: is the ubuntu kernel okay for that fature now/
<jdstrand> zyga: seccomp arg filtering will work on any kernel with newer seccomp
<sergiusens> dholbach I explicitly removed build-essential from this as it made building things that use nodejs incredibly and unnecessarily slow
<dholbach> sergiusens, I see
<vejmarie> quick question guys, how do you update manually the snap database ?
<zyga> vejmarie: what do you mean exactly?
<vejmarie> my colleague is looking at free cad within snap but when he kick snap find in a shell
<vejmarie> he doesn't find it
<zyga> vejmarie: that's always server side
<zyga> vejmarie: is that snap published?
<vejmarie> yes
<zyga> vejmarie: is it published to series 16
<vejmarie> I can see it on my system
<vejmarie> yes
<zyga> vejmarie: is he running snapd 2.0.5? (the latest one)
<ogra_> ogra@styx:~$ snap find|grep freecad
<ogra_> freecad                    0.17                       -        This is the first beta for freecad 0.17 supporting OCCT 7 / Netgen and new Smesh version
<zyga> vejmarie: can he snap install freecad?
<vejmarie> the main difference is that I am running 16.04 Desktop
<ogra_> i definitely see it on my xenial lappie
<vejmarie> he is running the server one
<vejmarie> with X installed on it
<ogra_> and i also see it in ubuntu-softare when i search for freecad
<zyga> vejmarie: that's no different
<ogra_> now ... why do i have to sign in to U1
<vejmarie> I do not see it in ubuntu software
<ogra_> i instaalled snaps yesterday and already did that ...
 * ogra_ sighs ... not a nice experience 
<vejmarie> he is running 2.0.3
<vejmarie> we are upgrading
<zyga> vejmarie: yeah upgrade to 2.0.5
 * ogra_ watches it installing now
<erio> ogra_: the old Ubuntu Software Center, even non snap related, had this losing logging every time problem.
<ogra_> i wouldnt mind it if i had no 2fa enabled ... it is just super annoying to search my phone every time i use sw-center
<sergiusens> ogra_ not necessary with `sudo` I believe
<ogra_> sergiusens, sudo ?
<sergiusens> ogra_ `sudo snap install freecad`
 * sergiusens is installing freecad now
<ogra_> sergiusens, i clicked on the organge paper bag in my launcher :P
<erio> Is there a way to publish a snap to the store, but make it invisible to others? I wanted to test, but using the store as provider. Similar to ppa maybe.
<ogra_> sergiusens, and ubuntu-software demands a new U1 login ... even though i did that yesterday when trying out another snap
<sergiusens> erio that should be coming soon iirc. nessita might have the details
<ogra_> now it would be really nice if the dash found any snaps that i search for :/
<erio> Ok, thanks surgiu sen, that would be great. Ma
<erio> Or maybe like Steam Early Access, just to put out really beta things, but that people using know upfront that the app is far from "finished
<erio> "
<nessita> sergiusens, details about...? :-)
<vejmarie> good luck sergiusens
<ogra_> nessita, to late, you are on the hook
<vejmarie> do not forget to connect the snap to the interfaces
<ogra_> so should the dash find any of the snaps i installed yet ?
<ogra_> (definiely doesnt here)
<vejmarie> by the way we still do not see free cad in ubuntu-software
<vejmarie> how do you connect to a user account through the tool ? I didn't find this option
<ogra_> if i search for "freecad" i see it here
<kyrofa> nessita, details about private snaps
<vejmarie> I think I am currently using the store without being connected to it, and perhaps do not have the credential to see my snap ;)
<ogra_> works if i start it from a terminal :)
<kyrofa> erio, for beta things we have the concept of "channels." edge, beta, candidate, and stable
<ogra_> the fonts are slightly awful ... but it runs and all :)
<kyrofa> erio, if something isn't stable, don't put it on the stable channel and the users who want to try out the unstable version can use another channel
<ogra_> wheee !!!
<ogra_> switching to german actually gets me german !
<erio> Nice kyrofa_ thanks. Will look into it.
<erio> This is the docs kyrofa ? https://developer.ubuntu.com/en/snappy/guides/channels/
<kyrofa> erio, yeah, though that seems kind of specific to ubuntu core
<vejmarie> ogra_: what are you testing ?
<ogra_> vejmarie, freecad :)
<kyrofa> erio, when you publish your snap, you just check the boxes for the channel(s) you'd like it to be released into
<vejmarie> ogra_: good to see it switching from languages
<ogra_> yeah
<vejmarie> ogra_: I have noticed the font issues
<vejmarie> this is a problem within the python code
<ogra_> it actually seems to ship quite a few fonts
<vejmarie> I am working on fixing it at the present time, but I am not yet an expert
<davidcalle> erio, kyrofa: yeah, this doc is mostly for core images themselves, although, it gives an overview of our concept of channels
<vejmarie> yes it ship the font
<vejmarie> but looks for them in the wrong places
<ogra_> ah
<vejmarie> which explain why it default to ugly ones
<vejmarie> I need to fix the code upstream
<kyrofa> davidcalle, indeed
<ogra_> vejmarie, well, in any case ... GOOD WORK !
<vejmarie> thanks
<vejmarie> I might be fixing the font during the night and we shall be good
<vejmarie> then I need to find a way to run highly build and automatize updates
<vejmarie> and we shall be good for ubuntu support
<vejmarie> (I normally do MacOS build)
<vejmarie> I shouldn't say that there, people will stop to speak with me
<sergiusens> vejmarie freecad launched ;-)
<vejmarie> good ;)
<sergiusens> vejmarie it has been a while since I last used it. I'll try it out later in the day
<sergiusens> vejmarie one sugary thing you can do is name the `FreeCAD` in apps just to be `freecad`, then you can launch it from the cli by just typing in `freecad` instead of `freecad.FreeCAD`
<sergiusens> up to you though ;-)
<vejmarie> no problem. Be careful this is a developper version (latest git), so there might be bugs
<vejmarie> yep I will upgrade that, this is my first snap still need some cleanup
<sergiusens> vejmarie ah, for developer versions and to make your users not run into unexpected expectations, you should use the approriate channels when publishing ;-)
<vejmarie> yes do not worry this is my intend, I moved the channel temporarly
<vejmarie> as to see if I can see it in the store (which is still not the case !)
<vejmarie> I will update it tonight when I will have understood why my store can't see it
<vejmarie> I would like to run nightly build and distribute it through snap which seems to be the best way to test a few crazy features into free cad which has some very heavy dependancy (OCCT is a massive stuff)
<vejmarie> by the way sergiusens, I think the developer version is quite stable
<vejmarie> if needed I can build a stable version
<kyrofa> vejmarie, no need if you think it's stable enough-- the beauty here is that it's all your call!
<kyrofa> vejmarie, the only limitation as I understand it is that you can't release a snap that _requires_ devmode into stable channels
<ogra_> now you just need to convince apple to support snaps too ... and only have to roll one package ;)
<vejmarie> kyrofa: it doesn't needs devmode ;)
<kyrofa> vejmarie, then you're all good
<vejmarie> ogra_: might be a challenge
<ogra_> yeah, thats the most awesome bit :)
<ogra_> vejmarie, just a "small" one :)
<vejmarie> :)
<roadmr> heya folks, I have a theoretical question :) how would I snap something like e.g. vim, which I'd like to be able to access pretty much any file in the system? not only in $HOME but say in /etc...
<ogra_> you would tell users to use --dvemode
<ogra_> *devmode
<ogra_> or wait til some content charing mechanism is in place that you can hook into
<ogra_> *sharing
<roadmr> is that planned?
<ogra_> well, unity8 has it ...
<roadmr> because devmode has other implications as well, right?
<ogra_> it makes the snap run unconfined
<ogra_> but thats peobably what you want for an editor anyway
<kyrofa> ogra_, I'm not sure the content sharing thing is what you want there, since I believe that's for inter-snap relationships
<kyrofa> roadmr, if vi isn't unconfined you need to limit where it can write-- can't have it both ways
<kyrofa> roadmr, sorry, my double negative made that hard to read
<elopio> ~
<sborovkov> hello, Is there some env variable for snap's common directory?
<zyga> sborovkov: AFAIR not yet but I may have rusty memory
<zyga> sborovkov: but there's a way to reach it using ../something/something reliably
 * zyga looks
<kyrofa> sborovkov, not yet
<kyrofa> sborovkov, you can get to it via SNAP_DATA/../common
<sborovkov> understood. thanks.
<kyrofa> sborovkov, the user-specific one is SNAP_USER_DATA/../common, but the launcher doesn't have the smarts to create it just yet
<kyrofa> (so it's not actually usable, sorry about that)
<kyrofa> But the system wide one (next to SNAP_DATA) works fine
<zyga> kyrofa: thanks
<kyrofa> zyga, no problem. sborovkov they'll be named soon!
<kyrofa> niemeyer, ^^
<kyrofa> elopio, test test
<elopio> works.
<plars> xcb
<plars> err
<plars> kyrofa: hi, I found https://github.com/kyrofa/qt-example-snaps/blob/master/systray/parts/plugins/x-qmake.py which was really helpful
<plars> kyrofa: I was wondering if there are plans to include it in snapcraft?
<plars> kyrofa: also, I am hitting an error with qt things that I try to snap, wondering if you've seen it:
<plars> This application failed to start because it could not find or load the Qt platform plugin "xcb"
<kyrofa> plars, I wasn't planning on it, I was just collecting some qt examples there, but I suppose it could be
<sergiusens> plars use `after` qt5conf` and in command do `command: qt5launch <cmd>`
<kyrofa> plars, you need the stage-package I have there
<kyrofa> And yes, the qt5conf bit
<sergiusens> kyrofa we should add the plugin, tag it experimental if you think it is not prime time ready yet
<kyrofa> sergiusens, I'm good with that. I wonder if kgunn might give us a review to make sure it's decent
<sergiusens> kyrofa maybe jamiebennett wants to contribute a plugin :-P
<kyrofa> plars, sergiusens oh oops, I didn't actually read the whole link, I thought plars was talking about the example, not the plugin. Yeah that should definitely be included
<plars> yes, the plugin itself would be really useful
<kyrofa> plars, agreed, we'll get that in there
<plars> sergiusens: kyrofa: I'll give the qt5conf bit a try, thanks!
<kyrofa> plars, we even have a bug for it.
<plars> err, qt5launch
<kyrofa> plars, yeah, refer to https://github.com/kyrofa/qt-example-snaps/blob/master/systray/snapcraft.yaml for details
 * jamiebennett hides
<kyrofa> jamiebennett, know anything about qmake?
<jamiebennett> I know how to spell it ;)
<sergiusens> jamiebennett that's a starter :-P
<jamiebennett> But thats about it
<sergiusens> elopio have you tried manually uploading with https://github.com/ubuntu-core/snapcraft/pull/532 ?
<elopio> sergiusens: yes.
<sergiusens> elopio than yay!
<plars> sergiusens: kyrofa: that seems to have worked great, thanks!
<kyrofa> jamiebennett, haha, no pressure, but if you feel like poking at snapcraft it should be a fairly easy one. Happy to take it though
<kyrofa> plars, excellent! And thanks for the qmake poke
<elopio> sergiusens: want me to update and rerun the tests?
<kyrofa> kgunn, any chance you'd be willing to review a qmake plugin?
<kgunn> kyrofa: sure
<kgunn> i may not be the best...but i can always get some support there
<kyrofa> kgunn, thanks-- I'm sure you'll be better than me! I'm mostly unclear about qt4 versus qt5
<elopio> sergiusens: kyrofa: jamiebennett: fgimenez: yesterday I got a green execution of snapcraft all-snaps in bos01.
<jamiebennett> \o/
<elopio> I can work on getting the all-snaps images updated everyday there.
<jamiebennett> elopio: Great work
<kyrofa> Awesom elopio!
<elopio> zyga: can you give me a short summary of the ubuntu-image status? Can I use it to generate images with core/edge ?
<kyrofa> With an e
<fgimenez> elopio, great!
<elopio> fgimenez: to take into account when uploading the images, we need to pass the arch property, and also the hypervisor.
<kgunn> kyrofa: was there a pull request, i checked your github activity didn't see it...
<kyrofa> kgunn, oh no, sorry-- I'll ping you once I have something
<kgunn> oh...nw
 * kgunn goes back to being buried ;-P
 * kyrofa shovels more dirt on kgunn
<zyga> elopio: no, I'm busy with other tasks and I don't think that anyone else is touching it
<elopio> zyga: ok, np, we will keep using the hacked one.
<zyga> elopio: I think it is on my plate right after my current task
<ysionneau> hmm for the extlinux.conf, am I supposed to put it inside the gadget snap ? or the kernel snap ?
<zyga> ysionneau: what is extlinux.conf?
<ysionneau> some kind of menu config for u-boot
<ysionneau> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/boot-assets/uboot.env.in < the uboot script searches for it
<zyga> ysionneau: that will be the gadget snap but only after the new ubuntu-image is in place
<zyga> ysionneau: contributions are very much welcome
<zyga> ysionneau: look at github.com/CanonicalLtd/ubuntu-image for details (there's a spec for gadget's image.yaml)
<zyga> ysionneau: that desribes how to put the image togeter
<ysionneau> ah, thanks!
<ysionneau> this ubuntu-image is the replacement for UDF ?
<sethj> looking through the latest snapd changelog it mentions a debian import/patch that fixes the XDG path issue. Does that mean this bug was fixed?
<sethj> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576303
<ubottu> Launchpad bug 1576303 in snapcraft (Ubuntu) "Needs fontconfig integration" [Undecided,Confirmed]
<zyga> ysionneau: yes
<zyga> ysionneau: I can tell you anything you want to know about it
<zyga> ysionneau: but I'm not currently working on it (preempted by other tasks)
<ysionneau> fair enough!
<zyga> ysionneau: I was going to implement and test the x86 side (there's no real difference but I was going to make new gadget snaps firsts)
<zyga> ysionneau: but I would love someone to look after uboot side (again, no real difference for u-i)
<ysionneau> well, if I can help somehow don't hesitate to ask
<zyga> ysionneau: sure
<zyga> ysionneau: you can help a lot by doing one simple thing
<zyga> ysionneau: read the image.yaml spec there
<zyga> ysionneau: and tell me how you'd describe an image using uboot
<zyga> ysionneau: make a demo .yaml, stick it in a branch
<zyga> ysionneau: at the same time, look at ...
 * zyga looks
<zyga> ysionneau: look at this http://paste.ubuntu.com/16922791/
<zyga> ysionneau: this is a shell "prototype"
<zyga> ysionneau: see if you can make a prototype like that, in shell, that assembles the image
<zyga> ysionneau: use local snaps for everything (u-i downloads them but let's not worry about that)
<ysionneau> hmmmm
<zyga> ysionneau: if you can make that prototype and the corresponding image.yaml that will help me a lot
<zyga> ysionneau: we have some code that takes the .yaml file and handles it so that we can create such shell scripts
<ysionneau> I've made a shell script to generate "image" for my board from rpi2 snaps :o
<ysionneau> is that of any interest?
<zyga> ysionneau: yes!
<zyga> ysionneau: note that u-i has one major design change from udf
<ysionneau> https://github.com/fallen/snappy-tools/blob/master/paros_image/genimage.sh
<zyga> ysionneau: it doesn't run any code that's system specific or that's shipped by the gadget
<zyga> ysionneau: all the code is either generic (making partitions, filesystems, pupulating filesystem)
<kyrofa> sergiusens, do you know anything about bug #1587193?
<ubottu> bug 1587193 in snapcraft (Ubuntu) "build of python3 snap fails with 'error: option --single-version-externally-managed not recognized'" [Undecided,New] https://launchpad.net/bugs/1587193
<elopio> sergiusens: didrocks: If you get an error on jenkins saying something bos01, it was my fault. I'm reverting that. Sorry.
<zyga> ysionneau: or the gadget has to ship a blob that we just stick at a given offset
<zyga> ysionneau: so images should be 100% reproducible
<zyga> ysionneau: the blobs can be built by the gadget snap
<zyga> ysionneau: but similarly to how snaps are built, that's done while the gadget snap is being built
<zyga> ysionneau: not when the image is assembled
<zyga> ysionneau: the image is more of a linker
<zyga> ysionneau: and takes pre-built things
<zyga> ysionneau: does that make sense?
<ysionneau> IIUC, the image.yaml is describing the flash layout and partitioning scheme and which file to flash where?
<zyga> ysionneau: so your script would need to be split into something that you can snapcraft (or make) into a gadget.samp (containing image.yaml, files to put into filesystems, blobs to put into a fixed offset)
<zyga> ysionneau: it describes how to create a big blob out of other "parts"
<zyga> ysionneau: some of those parts are filesystems that it can populate
<ysionneau> ah ok a big flashable blob
<zyga> ysionneau: either with files from the gadget or with magic stuff to make the core snap work
<ysionneau> right
<zyga> ysionneau: and some other parts are just fixed blobs to stick somewhere (not a filesystem, not a partition)
<zyga> ysionneau: e.g. boot code in the MBR
<zyga> ysionneau: or stage-2 grub in the bios bootloader partition
<zyga> ysionneau: or modem binary on dragon. etc
<zyga> ysionneau: if you start to arrange your script into two scripts
<zyga> ysionneau: one that builds the blobs or gets them from somewhere
<zyga> ysionneau: does any computing needed
<zyga> ysionneau: and spits out a gadget.snap
<zyga> ysionneau: and another that is more akin to what I pasted as the prototype in shell
<zyga> ysionneau: then we can align nicely
<zyga> ysionneau: if you see any issues in this desing please tell me early
<zyga> ysionneau: but I think the idea is flexible enough to build virtually any image (on any host OS)
<ysionneau> one thing I think is important to say, here the input format for our flashing tool is a .tar, and not a .img
<zyga> ysionneau: and without having to change ubuntu-image in any way (hence declartive image.yaml and prebuilt stuff in the gadget)
<zyga> ysionneau: what is the tar content?
<ysionneau> to flash, we basically send (via DFU or other) a bootloader, a kernel, and an installer (an ELF)
<ysionneau> then we speak through USB to the installer
<zyga> ysionneau: I see
<zyga> ysionneau: that's okay
<zyga> ysionneau: for 0.1 I'd like to just make an image reliably
<zyga> ysionneau: for 1.0 we can export parts into various other formats
<zyga> ysionneau: you can always take the image and export those with post-processing tools
<zyga> ysionneau: all that is important is that the image can be built reliably and (perhaps) with 100% reproducibility
<zyga> (apart from things like partition IDs but perhaps snapd will manage those on first boot, time will tell)
<zyga> ysionneau: please stay in touch, I want to ensure you are supported
<zyga> ysionneau: and please do consider hacking on ubuntu-image, I will gladly review patches and take new features
<ysionneau> 18:12 < zyga> ysionneau: what is the tar content? < basically the entire file system(S)
<ysionneau> it's nice that it is in Python and not go anyway
<zyga> :-)
<ysionneau> cause I can hack on Python and not at all on go =)
<zyga> ysionneau: and I think it should be fairly small and well-defined
<zyga> not open-ended like u-d-f with ever-growing list of "supported boards"
<didrocks> elopio: thanks for the head's up!
<ysionneau> to be more precise about our flashing process : we send a big .tar through USB and the installer 1Â°) formats the eMMC with the partition scheme 2Â°) mounts  partitions 3Â°) extracts the tar
<ysionneau> the fact that we mount the partitions before untaring allows to put contents for several partitions in the same .tar file
<zyga> ysionneau: note that ubuntu-image is precisely not ubuntu-flash
<zyga> flashing is a separate tool that I'm not making today
<ysionneau> (eg system-boot and writable)
<ysionneau> yes but the image generation tool should be able to produce a file that can be processed by the flashing tool, right?
<ysionneau> anyway, about the image generation process, Nvidia tools are doing a bit what your image.yaml is doing, except they use .xml
<ysionneau> you either specify an .img for each partition, or a blob and that's it
<zyga> ysionneau: that's a little open-ended, I think we will just make an image (intially), later on we might natively produce separate bits (just filesystem contents and the like)
<zyga> the flashing tool is complex because there are lots of different things to do there
<zyga> ysionneau: as long as we can take the  big image and build a target-specific tool that flashes it (doing anything it needs internally), I think we are good
<zyga> ysionneau: can you point me to those tools? I'd like to know this better
<tyhicks> zzarr: I accidentally highlighted your name with the message about -Wall and -Werror but meant to highlight someone else - sorry about that!
<tyhicks> ysionneau: sorry but I haven't been able to debug it any more
<ysionneau> zyga: Parrot tools unfortunately are not open source :/
<ysionneau> and Nvidia ones, I don't know
 * elopio <- afk.
<ysionneau> zyga: I've got to go, maybe I can drop you an email with more precise info about our image generation / flashing process?
<zyga> ysionneau: thanks
<zyga> ysionneau: please do
<zyga> ysionneau: do you have my address?
<ysionneau> zyga: yes :)
<ysionneau> see you soon!
<zzarr> tyhicks, no problem, shows you are human :-)
<kgunn> zyga: you about? finally got round to trying vm --visual, with mir i/f builtin to snapd
<kgunn> curious, if i install mir-server snap...i see mir:mir-server under the plug column
<kgunn> i would;ve thot mir slot would've shown up w.o mir-server snap being installed?
<kgunn> e.g. it only appears in the interface list after mir-server snap installation
<jdstrand> sergiusens: hey, looking at bug #1583259 I'm trying to understand what ends up in snap.yaml. snapcraft.yaml is clear-- will snap.yaml be the same or different?
<ubottu> bug 1583259 in Snapcraft "Snappy needs to influence environment variables in applications " [Wishlist,In progress] https://launchpad.net/bugs/1583259
<sergiusens> jdstrand it will be a direct copy, a global `environment` (same level as `name`) and one special to each app in `apps`
<sergiusens> jdstrand the consumer for this is snap-run
<jdstrand> sergiusens: ack, thanks
<zyga> kgunn: hmm
<zyga> kgunn: can you please re-state that?
<zyga> kgunn: which snaps did you install
<zyga> kgunn: in what order
<kgunn> zyga: sure...more a matter of curiosity as i see mir trying to launch...but here's what i did
<kgunn> used your run-devel-vm --visual, then rebuilt snap/snapd, setup, run-snapd, then on the vm ./devtools.snap installed mir-server snap
<kgunn> rebuilding snap/snapd b/c i added the mir interface to builtins
<kgunn> literally "mir" being the interface name
<zyga> okay
<zyga> ah
<zyga> hmmm
<zyga> can you please point me to the mir interface?
<zyga> it depends on how you made the interface
<zyga> you can think of mir-server having a mir socket
<zyga> s/socket/slot/
<kgunn> zyga: i actually figured you were gonna say that :)
<zyga> then the slot grants you permissions
<zyga> and it's not on the core snap
<zyga> (I think that is what we wanted)
<zyga> you can also stick it on the core snap but I think that's less desired
<zyga> because what we are still after is the mir plug for some demo client to run and talk to mir snap
<zyga> in any case, I'm very happy that it's progressing and that the tooling around snapd works fine
<zyga> if you have any questions please do ask
<kgunn> so i implemented them as "permanent slot"
<kgunn> and at this point, i'm not even to mir-client...this is just to get mir-server running on the core
<kgunn> and i should be able to make some progress, like i say..i see mir-server trying to launch
<zyga> kgunn: so the permissions to 'be mir' are on the permanent side of the mir slot?
<zyga> kgunn: that sounds good
 * zyga watches tests fly past his screen
<kallisti5> any plans for 16.04 based snappy core?
#snappy 2016-06-03
<elopio> kallisti5: hello. Our core is 16.04.
<elopio> you can install xenial, and run sudo snap install hello-world.
<sergiusens> elopio can you `gbp buildpackage` master?
<sethj> shoot, accidentally ctrl+c'd snap remove, now it won't remove the snap because "there are changes in progress".
<sethj> is there a lockfile somewhere?
<sethj> oh huh, seems to have fixed itself. Must have still been doing stuff. Nice.
<zyga> o/
<zyga> blackout24: hey
<didrocks> elopio: hey! do you need anything from me?
<elopio> didrocks: we were trying to land your branch yesterday, but Sergio already went to bed.
<elopio> there is one error on simple fix in your branch, that's updating the debian/tests. The big problem is that it throws a bad system call.
<didrocks> elopio: yeah, I have no idea on this
<elopio> didrocks: and anyway, we'll have to skip them until IS opens the proxy.
<didrocks> elopio: ok, let me repull on my PR if Sergio already went to bed and I can try having a look, just in case I can find what bad system calls it is (running in autopkgtests)
<didrocks> making sense?
<elopio> didrocks: sure. If you can fix it before he wakes up, awesome. Otherwise we can land it to get started and fix it in the following version.
<didrocks> elopio: yeah
<didrocks> sounds work, echo should be the built-in version in shell
<didrocks> weird*
<elopio> didrocks: building the package in a lxc I'm getting this error: https://paste.ubuntu.com/16941250/
<elopio> doesn't seem critical, because the build works in the ppa.
<didrocks> elopio: hum, will look as well, I wonder if others path are screwed as well when building inside the container
<didrocks> elopio: you should probably go to bed btw :)
<elopio> didrocks: yes, I'm done now. I just build your branch, installed the deb and verified that all looks good. This will be released for sure when Sergio gets up.
<elopio> thanks, and see you later.
<didrocks> elopio: thanks to you! I'm working on this test meanwhile
 * zyga -> off
<davidcalle> Morning o/
<didrocks> hey davidcalle
<dholbach> davidcalle, nice work on the summary!
<davidcalle> Hopefully, next week's will be much bigger thanks to the playpen :)
<dholbach> :-)
<dholbach> davidcalle, dpm, mhall119, popey: I set up https://gitter.im/ubuntu/snappy-playpen (as an experiment)
<davidcalle> dholbach: nice! Waiting for you in there :P
<dpm> thanks dholbach!
<zyga-phone> o/
<zyga-phone> Irc from ubuntu phone :-)
<ysionneau> tyhicks: hi! Will you be working on the issue some more or are you stuck?
<dholbach> please share:
<dholbach> https://plus.google.com/u/0/b/107265043789873157543/107265043789873157543/posts/PhXG5s7nBEQ
<dholbach> https://www.facebook.com/ubuntudev/posts/1133350713383215
<dholbach> https://twitter.com/ubuntudev/status/738658113100894208
<ePierre> dholbach, cool! Shared on G+
<dholbach> <3
<didrocks> dholbach: tuesday, midnight? :)
<dholbach> didrocks, it asked me for a time
<dholbach> the best I could do was 0:00 â 23:59
 * didrocks sends a pager to dholbach :)
<didrocks> 0:00 sharp! :)
<davidcalle> !remindme telegram dholbach at 0:00 on tuesday
<ubottu> davidcalle: I am only a bot, please don't think I'm intelligent :)
 * didrocks wants a dholbachnugger snap
<didrocks> nagger*
<dholbach> didrocks, dholbachhugger you wanted to say, right?
<didrocks> dholbach: oh right, right, rightâ¦ :)
<dpm> ogra_, zyga, sergiusens, have you or would you happen to know someone who has tried snapping Java apps for the desktop? A contributor submitted a Java example for the snappy-playpen repo, and I'm wondering if we could give them a hand with getting the snap to start
<dpm> https://github.com/ubuntu/snappy-playpen/pull/22/files
 * ogra_ has never packaged any java
<ogra_> i think lool has ... but quite a while ago (pre snapcraft iirc)
<dpm> ok, thanks ogra_, I'll ask him. Or jamiebennett, do you know if someone on the team has looked at snapping java apps and could give a hand to a community member? https://github.com/ubuntu/snappy-playpen/pull/22/files
<sgclark> hi all. I have a bunch of frameworks ( libraries ) that I would like to snap and use those snaps inside snaps rathers than rebuilding them a billion times. Is this possible? if so please point me to the docs, I cannot find them.
<ogra_> i'm not sure that is possible yet (it is definitely planned) ... zyga would know if the necessary interfaces exist already
<sergiusens> sgclark it will be possible, not just yet. As ogra_ mentions, zyga has the timelines for that
<sgclark> ah ok.
<sgclark> I look forward to it then lol
<sergiusens> sgclark as do we all :)
<mhall119> sgclark: are you talking about KDE frameworks?
<sgclark> mhall119: yep
<mhall119> if so, I think the content-sharing interface will allow us to share those libs with other snaps
<mhall119> but, as they said above, it's not available yet
<sgclark> ok cool
<mhall119> sgclark: for now we can just bundle them in the apps, like I did for Krita
<sgclark> I am breaking them out
<sgclark> not using archive for anything kde
<mhall119> sgclark: take a look at my final snapcraft.yaml for Krita: https://quickgit.kde.org/?p=krita.git&a=blob&h=821060a782043dd134c6975182830d29dea8e87c&hb=b11ca95c668a99e4c07c39641a0e85d5f24c3dee&f=packaging%2Flinux%2Fsnap%2Fsnapcraft.yaml
<mhall119> I split kdeframeworks and qt into separate parts
<mhall119> the just use archive packages now, but you could replaced the nil plugin with cmake or whatever KDE frameworks use, and point them to a git source
<mhall119> I actually have that on my list of things to try with Krita to get the newest Qt
<sgclark> ok
<sgclark> yeah I tried to break out qt but it failed, needs new plugin but I could not get it sorted yet
<mhall119> Qt doesn't use cmake?
<sgclark> nope
<mhall119> oh, right, it's qmake isn't it
<sgclark> it uses it's own form of configure and autotools plugin barfed
<sgclark> it needs a new plugin basically.
<mhall119> ok
<sgclark> I will hack at it more.
<mhall119> let me know if I can help, but it sounds like you know more about this than I do
<sgclark> ty
<mhall119> sgclark: is there a specific app your working on currently?
<sgclark> kdevelop
<mhall119> oh, that's a big one
<sgclark> aye
<sgclark> got it running and all, but some usage kinks I am working out.
<sgclark> Also I need to know where I can upload snaps for others to test
<sgclark> I prefer not testing in the store haha
<mhall119> there's actually a testing channel in the store, but I don't know if that's all working now or not
<mhall119> you can pretty much put the snap anywhere, even people.ubuntu.com
<sgclark> ok
<kyrofa> sgclark, a qmake plugin is scheduled for the next snapcraft release
<kyrofa> You can use a local qmake plugin temporarily until it's in place. Are you familiar with local plugins?
<sgclark> ah cool
<sgclark> yes I am familiar
<kyrofa> Okay good deal
<sgclark> part/plugins/myplugin.py
<kyrofa> Yep, you got it
<ysionneau> zyga: I'm reading this: https://github.com/CanonicalLtd/ubuntu-image/blob/master/docs/image-yaml.rst
<qengho_> Could there any mechanism for a snappy package to open a web page in the user's browser without providing a browser, or is that philosophically outside of snaps?
<ysionneau> what is it you call "an assertion" or "the model assertion" ?
<ysionneau> not clear to me (not native speaker)
 * ogra_ notes that qengho_ wears a ponytail today
<ogra_> oh, chopped off !
<ogra_> qengho, i'd say thats the job of an outside service ... but snappy/snapd should be able to invoke it and hand the url to it
<ogra_> much like we do on the phone
<qengho> "Connection lost to chat.freenode.net" <- hair source
<ogra_> heh
<qengho> ogra_: So, "One day, maybe."
<ogra_> yeah
<ogra_> well, once we switch to unity8 we'll get such stuff for free ... i guess it will only need some minor adjustments and some oof zyga's time to plumb an interface on top of the existing parts
<qengho> Hmm. 8. I bet there's some DBus thing that will do it now.
<ogra_> there is xdg-open as well
<ogra_> not sure that is considered secure enough though
<qengho> xdg utils would run inside the snap and try to search for one there.
<ogra_> no, i mean an interface to the desktop side that would spawn xdg-open with an url you hand to it
<ogra_> i guess that could work
<qengho> Yeah! Something could pretend to be xdg-open. xdg utils are hilariously primitive shell scripts, though.
<ogra_> the point is that snapd needs to trigger it through the unity7 interface or some such
 * ogra_ has no deep insight inot interfaces or how they actually work internally though ... probably i'm on the wrong track, thats zyga land :) )
<ogra_> oh
<ogra_> i wasnt aware jospoortvliet is actually lurking here :)
<kyrofa> ogra_, how do you think the owncloud snap started? :P
<ogra_> with you running after the guys in their channels :)
<ogra_> awesome to see him aound here
<Chipaca> jdstrand: if a snap says confinement:devmode the user must provide either --devmode or --confined
<Chipaca> jdstrand: (i'm implementing that now)
<Chipaca> it's going to be ~3 branches, fwiw
<jdstrand> ack
<jdstrand> Chipaca: though the yaml has confinement:devmode|strict. shouldn't the flags be --devmode|--strict?
<Chipaca> jdstrand: well, no: as a user, what does `snap install foo --strict` do?
<Chipaca> it's --confinement={devmode,strict}, with --devmode and --confined shortcuts for those
<Chipaca> *handwaving for things that are not implemented*
<jdstrand> Chipaca: fair point, though, I thought --confined was the default
<Chipaca> jdstrand: it is
<jdstrand> when would you use --confined?
<Chipaca> jdstrand: when you want to override the snap
<jdstrand> Chipaca: but if it is always installed confined unless you specify --devmode?
<Chipaca> jdstrand: if the snap specifies "confinement:devmode", asking to install it on its own will fail
<jdstrand> basically, my understanding was that you always had to use --devmode to install in devmode
<jdstrand> oh I see
<Chipaca> jdstrand: it's more a ux thing, i guess: if the snap says devmode, it probably won't work without --devmode, so bail
<jdstrand> if confinement:devmode, no args, fail with msg, --devmode installs, --confined allows install
<Chipaca> jdstrand: but still have a way for dev to override for testing or whatever
<Chipaca> exactly
<jdstrand> ok, that makes sense
<jdstrand> though, --confined does feel exactly right to me, but if that is what's designed, I certainly won't block on it
<jdstrand> doesn't*
<kyrofa> ogra_, FYI, Mark invalidated #1586400. I know you weren't a huge fan
<kyrofa> Darn pattern patching. bug #1586400
<ubottu> bug 1586400 in Canonical Click Reviewers tools "Snap type: change from "os" to "core"" [Wishlist,Fix committed] https://launchpad.net/bugs/1586400
<ogra_> kyrofa, well, i wasnt a fan of the rename
<ogra_> (teh package rename ... i dont really care about the internally used type)
<kyrofa> Oh, okay
<ogra_> the package will still have to be renamed
<kyrofa> Indeed, yes
<elopio> didrocks: https://launchpadlibrarian.net/263311094/buildlog_ubuntu-xenial-amd64.snapcraft_2.9~ppa5-1_BUILDING.txt.gz
<elopio> the gettour test failed /o\
<ysionneau> I guess the kernel/ubuntu-core fallback mechanism only works if u-boot supports the saveenv command?
<didrocks> elopio: seriously? (in a meeting, looking)
<didrocks> elopio: it did build in your ppa though?
<didrocks> it seems that PKGBUILDDIR wasn't expanded, any idea?
<elopio> didrocks: yesterday. But if failed today, not sure what's the difference.
<didrocks> elopio: this code isn't enabled, we can skip it to not block release
<elopio> I think PKGBUILDDIR is the name of the dir, isn't it.
<didrocks> yeah
<elopio> didrocks: ok, let me make the PR.
<didrocks> normally, setup.py expands it
<elopio> didrocks: sergiusens: https://github.com/ubuntu-core/snapcraft/pull/547
<didrocks> elopio: sorry for the additional work I'll have a look to the build system later
 * popey waves https://github.com/ubuntu/snappy-playpen/pull/24 at dholbach / didrocks  :)
<dholbach> popey, nice one
<lool> dpm, ogra_: Re: java âÂ there's a maven example in snapcraft (has been one of the first plugins :-)
<dholbach> popey, oh, can you add a line to https://github.com/ubuntu/snappy-playpen#current-project-status?
<elopio> didrocks: no worries. I'm ok with getting all these unskipped for the next week. And the tour is looking great, so I'm happy.
<lool> dpm, ogra_: it would need some love post xenial (moving to newer jre, allowing for oracle jre etc.) and I'm sure there are plenty of other systems which would need wrapping âÂ I believe there's also an ant plugin
<dpm> lool, I'm not familiar with maven, but if I understand it correctly, it does not have a GUI? The issue we've got is with getting a Java (GUI) app run on the destkop
<tyhicks`> ysionneau: I will be the one working on the issue but the problem is time
<tyhicks`> ysionneau: I've got a few too many things needing my attention today and I'm off all next week
<didrocks> popey: in meeting, will do next :)
<lool> dpm: maven is a build system
<lool> dpm: it might be used to build any piece of java software
<lool> dpm: I'm not sure java gui app is much different from any GUI app (outside of the interfaces you want to require)
<popey> dholbach: done https://github.com/ubuntu/snappy-playpen/pull/25
<lool> sorry I meant from any Java app
<dpm> lool, assuming we're running it in devmode, I'm guessing that a Java GUI app should have its own set of fonts and X env variables, though
<lool> dpm: X env is the same as for other GUI snaps; fonts is a good question, it depends on which java stack is being used; I would think the runtime pulls in enough by default though
<didrocks> sergiusens: elopio: I'll ensure I understand what the issue is in the build system
<dholbach> thanks popey
<lool> dpm: I guess it's a case for trying it out really; we can see how to best deal with the general case from there?
<popey> dholbach: np, thanks for reviewing
<ogra_> ysionneau, yes, but the enforced use of uboot.env makes sure that saveenv always works
<ogra_> ysionneau, thats one of the reasons we switched to it
<dpm> lool, I'm not sure, I'm not familiar with Java GUI apps at all, but with the experience of having snapped a couple of Qt apps that required 40+ lines of env variables being set, I would imagine that Java GUI apps would be similar in that regard
<dholbach> popey, so far the process and everything is working out quite nicely
<popey> ya
<popey> i agree
<popey> its fun
<popey> I am _starting_ to like github
<dpm> good work guys
<popey> i like doing ninja inline edits directly on github.com and turning those into PRs
<popey> which is what i did for the readme
<ogra_> popey, if only it would support bzr :P
<popey> cvs forever!
<ogra_> or that !
<fgimenez> hey jdstrand :) iirc you were asking a few days ago about security related integration tests, if you have any test cases in mind pls let me know and i can begin writing them
<didrocks> popey: "I am _starting_ to like github" -> I remember what you told during the sprint :p
<didrocks> see, you are getting at it!
<ysionneau> ogra_: so if I use default config (built in) and disable saveenv, fallback won't work
<ysionneau> good to know
<ysionneau> (for some reason we deactivated the uboot.env stuff)
<ogra_> well, just ennable it and you should be fine :)
<ysionneau> yep
<ogra_> i guess snapd would fall over when you do kernel snap updates ... it actually wants to update uboot.env
<jdstrand> fgimenez: oh I have a list!
<jdstrand> fgimenez: let me email you. should I CC anyone?
<fgimenez> jdstrand, great, sure elopio will be interested too
<jdstrand> ok, let me get that to you
<didrocks> ofc minetest
<mhall119> sgclark: is your kdevelop snapcraft.yaml available somewhere for me to try?
<ysionneau> ogra_: I could just put a fake uboot.env, that's what I do right now :p
<sgclark> nope, not done
<sgclark> mhall119: and I cannot get your sections thing to work with frameworks being parts
<mhall119> sgclark: are you using the nil plugin and archive packages like mine, or are you trying ot build from source?
<sgclark> no, I am using upstream source for frameworks
<popey> hey sgclark !
<mhall119> ok, what's not working? does it compile the upstream source?
<sgclark> upstream source for kde*
<popey> sgclark: you back from vacation / visiting family?
<sgclark> hi popey :)
<sgclark> yeah
<sgclark> sponsered to work on snappy, I am a happy camper
<sgclark> sponsored*
<mhall119> \o/
<popey> Wat! That's awesome news!
<sgclark> it is :)
<popey> I'm so happy for you!
<ogra_> ysionneau, well, there is code that calls fw_setenv in snapd
<popey> Today is a good day.
<ogra_> ysionneau, not sure what happens if it cant actually set the vars
<sgclark> ty
<ogra_> ysionneau, so i'd suggest to just support it
<ysionneau> I think even "snap list" just fails without a uboot.env
<ysionneau> how can I put a file in a directory using the gadget snap? (boot-assets)
<ogra_> yeah
<ogra_> (to both)
<ysionneau> like creating dir_a/file_b
<ogra_> :)
<ogra_> oh
<ogra_> subdirs ?
<ogra_> not supported
<ysionneau> so far the syntax I use is : - path: boot-assets/uboot.env
<ogra_> (currently)
<ysionneau> but I don't specify the target dir
<ysionneau> arg, too bad I needthis :x
<ogra_> right, everything will go into the toplevel of the vfat
<ogra_> file a bug please ...
<ysionneau> on which project?
<ogra_> (it would help for raspberry pi overlay dtbs too)
<ogra_> just snappy
<ogra_> (see topic)
<ysionneau> ah good, thanks
<ogra_> let me know the bug # ... i'll confirm it
<ysionneau> https://bugs.launchpad.net/snappy/+bug/1588864
<ubottu> Launchpad bug 1588864 in Snappy "unable to specify target directory for boot-assets in gadget snap" [Undecided,New]
<ogra_> thanks !
<ysionneau> you're welcome!
<ogra_> zyga, ^^^ thats technically a u-d-f limitation that we need to weed out in ubuntu-image
<sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/547
<sergiusens> elopio master is just missing that now
<elopio> crazy jenkins error
<elopio> sergiusens: updated, the tests are running again.
<sergiusens> elopio rebased even?
<elopio> this is good to merge as soon as the travis execution is good.
<sergiusens> elopio sounds good
<qengho> What's a good way to test from inside a snap if it's in devmode or not?
<ogra_> do something that would normally be confined and check the exit code ?
<qengho> Yeah. Trying to pick something good.
<ysionneau> hmmm
<ysionneau> I'm generating an image with ubuntu-device-flash for my Paros board. the initrd's init fails because it cannot mount the gadget/kernel/core snaps
<ysionneau> itsearches for them in system-data/var/lib/snappy/snaps instead of system-data/var/lib/snapd/snaps
<ysionneau> :o
<kgunn> jdstrand: hey, finally back to working on mir interface and it's trying to fire up now....so i'm seeing denials for aa "open" "r" on "/run/udev/data/+drm:card0-virtual1", 2,3,4
<ysionneau> what could make UDF generate wrong init in the initrd?
<kgunn> but i have in my aa slot /run/udev/data/* r,
<kgunn> and / run/udev/** rw,
<ysionneau> FYI I'm generating with : sudo ./ubuntu-device-flash --verbose core 16 -o paros.img --channel edge --gadget ../paros_1.0_all.snap --kernel ../paros_kernel/tmp/paros-kernel_3.10.67_armhf.snap --os ubuntu-core --enable-ssh
<jdstrand> kgunn: /dev/run/** rw, would cover it. I suspect it isn't in the right part of your policy (permanent vs connected slot and permanent vs connected plug)
<mhall119> hey guys, what's the process for getting a new interface added to snappy?
<kyrofa> mhall119, a zyga question
<kyrofa> mhall119, this might get you part of the way there: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html
<mhall119> thanks kyrofa
<mhall119> and am I correct in thinking that snaps can't deliver new interfaces?
<kgunn> they all have to builtin atm
<kyrofa> mhall119, correctly snaps don't deliver interfaces (they're a snapd thing), but they can deliver slots for interfaces
<kgunn> they==interfaces in my response
<kyrofa> s/correctly/correct/, not sure how I messed that one up
<mhall119> here's my use-case: ElementaryOS apps use a thing called Contractor, which is a dbus service for content-sharing between their apps, it's provided by ElementaryOS and Pantheon desktop, but not part of a stock Ubuntu
<kyrofa> Yeah, perfect candidate for an interface
<mhall119> kyrofa: ok, but ubuntu-core doesn't provide the actual service, so how will apps know if the system they're installed on actually has that dbus service?
<kyrofa> mhall119, there are a few options
<kyrofa> mhall119, first of all, while all interfaces have to be explicitly supported by snapd, there's also the concept of interface connections, i.e. there's the slot (the producer side of the interface) and a plug (the consumer side). If you install a snap with a plug for this interface, but there's no snap install providing the slot, that interface simply cannot connect
<kyrofa> So if a snap expects this dbus service to be present but nothing is serving it, snapd won't connect them and you'll see that reflected in `snap interfaces`
<kyrofa> mhall119, this may also fit into the new "assumes" work, which is a set of features that a snap can request of the system; if they're missing installation will fail
<kyrofa> mhall119, though I'm a little more fuzzy on that one
<kyrofa> mhall119, finally, we have some sort of content sharing interface planned, though not spec'd just yet. Those two things may overlap
<sergiusens> kyrofa mhall119 the scenario you describe seems pretty similar to what kgunn did with mir
<mhall119> kyrofa: ok, so if I understand correct, we would add a "contractor" interface to snapd, and then an actual snap that contains the dbus service and provides the "contractor" slot
<sergiusens> the interface is added to snapd, but the implementation of a slot for that interface would be a snap
<sergiusens> could be
<kyrofa> mhall119, you got it
<mhall119> sergiusens: ack, what I was thinking
<mhall119> ok, cool
<ysionneau> ogra_: I just recompiled the kernel snap and the initrd seems to be still old :o
<ogra_> oh ?
<ogra_> sergiusens, ^^ does the kernel plugin not pull the latest initrd when you re-build ?
<sergiusens> ysionneau ogra_ just like it doesn't pull new code from the kernel sources, pulling (as stated in your message) is a pull step ;-)
<ogra_> sergiusens, i assume deleting the initrd would pull it automatic ? or do you still need a manual pull ?
<ysionneau> I deleted the snap directory and the .snap file and did "snapcraft --target-arch arm64 snap"
<sergiusens> ogra_ same as if you deleted something from vcs
<sergiusens> we could make it warn you
<ogra_> (assuming initrd is an essential part, i would expect snapcraft to make sure it is there)
<ogra_> yeah, we definitely should
<ogra_> or make it fail the build even
<ogra_> it wont boot without initrd ...
<ogra_> so there is no use in building it
<ysionneau> except I do have an initrd :o
<ogra_> we have a long term plan for booting with two initrds ... the script bits would then come from the os snap
<ogra_> so you get the latest with an os upgrade ... (to de-couple the kernel snap )
<sergiusens> ogra_ the kernel plugin is experimental, so errors are allowed :-P
<ogra_> but thats a bit further down the roead
<ysionneau> is there any quick thing I can do to unblock me?
<sergiusens> ogra_ I don't feel like adding a bunch of logic for something that is scheduled to go away, so all I can say is, hurry up!
<sergiusens> ;-)
<ogra_> sergiusens, well, we shouldnt allow building unbootable kernel snaps imho :)
<sergiusens> ogra_ they will be unbootable as soon as the spec changes
<ogra_> go away ?
<ogra_> it will change ... why would it go away
<sergiusens> ogra_ the need to download the generic initrd is going away
<ogra_> ah
<ogra_> well, but thats definitely post GA
<ogra_> so rather far out
<sergiusens> so there is not much logic there; and we won't spend precious time on that
<ogra_> ok
<sergiusens> in the meantime, don't delete files in `parts`
<sergiusens> ysionneau to get around it, snapcraft clean is what you would need to do
<sergiusens> kyrofa we should consider making an explicit call on a command do it again and mark what follows dirty
<ysionneau> hmm ok, isn't it the same as removing all directories?
<ysionneau> because I did that :o
<sergiusens> ysionneau sort of, sometimes, depends on the directories removed
<ysionneau> ok let's rebuild
<sergiusens> elopio kyrofa https://github.com/ubuntu-core/snapcraft/pull/548
<kyrofa> ysionneau, snapcraft does a lot of state tracking for the directories and files it deals with. It currently doesn't do a good job of handling your blowing stuff out from under it
<kyrofa> ysionneau, if you can use the `snapcraft clean` command it'll keep it happy
<kyrofa> ysionneau, for example, if you stage two parts, you can actually `snapcraft clean partA --step=stage` and it'll unstage only partA's stuff
<kyrofa> ysionneau, try doing that by hand ;)
<ysionneau> nice!
<ysionneau> well done
<ysionneau> ogra_ sergiusens still using old paths in initrd
<ogra_> did it actually download an os snap ?
<ysionneau> I don't think so
<ysionneau> let me c/c
<ogra_> i wonder if you have an old cached os snap somewhere
<ysionneau> http://pastebin.com/DLbSHvcy
<ysionneau> I did a snapcraft login before, and a snapcraft pull
<ogra_> weird
<ysionneau> where would this os snap be cached?
<ysionneau> I also unsquafs'ed it, to modify meta/snap.yaml to adapt the architecture because of some UDF bug and then resquashfs'ed . But I doubt it is causing my issue
<ogra_> yeah
<ogra_> well ... https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/kernel.py has
<ogra_>         snapcraft.download(
<ogra_>             'ubuntu-core', 'edge', self.os_snap, self.project.deb_arch)
<ogra_> no idea where the snap it downloads goes though
<ysionneau> I have snapcraft 2.8.7
<ogra_> thats rather old ...
<ogra_> though i dont think that specific part of it changed actually
<ogra_> probably kyrofa knows where such downloads go
<ysionneau> ahah
<ysionneau> I think I got it
<ogra_> explicit "pull" ?
<ysionneau> download() is downloading in .... self.sourcedir + 'os.snap'
<ogra_> ah
<ysionneau> so os.snap is in my kernel source dir
<ysionneau> which I didn't clean
<ysionneau> and I bet snapcraft clean didn't remove it
<ogra_> evil
<ysionneau> "downloading ubuntu-core" ...
<ysionneau> o/
<ogra_> yay
<ysionneau> who was bragging about "snapcraft clean" again ? :p
<ogra_> lol
<ysionneau> ogra_: IT BOOTS
<ysionneau> \o/
<ogra_> yay
<ysionneau> let's call it a day
<ysionneau> thanks a lot
<ysionneau> see youhave a nice weekend
<ogra_> np :)
<ogra_> yeah, enjoy
<ysionneau> (shall I file a bug for os.snap being in kernel source ?Ã )
<ogra_> sergiusens, kyrofa ^^ ?
<ogra_> (sounds like a bug to me ... but might fall under the same "it will all change anyway" clause from sergiusens )
<ysionneau> yep
<ysionneau> afk!
<kyrofa> ogra_, yeah, probably a sergiusens question
<sergiusens> ysionneau kyrofa ogra_ that is easy to fix, but it is also all going away, right?
<ogra_> sergiusens, yeah, in a few months
<ogra_> (definitely post GA or earliest "around GA")
<gouchi> hi
<gouchi> can somebody test a snap package http://www.hastebin.com/jerahisuva.hs ?
<gouchi> I can't test it because there is an issue when I try to install it on live usb
<sergiusens> gouchi building works?
<gouchi> sergiusens: yes
<sergiusens> gouchi I can later today
<gouchi> sergiusens: thank you
<sergiusens> gouchi if not, just upload and publish to the edge channel of the store only ;-)
<gouchi> sergiusens: I need to see if we can launch it
<sergiusens> ok, building now, but my connection is slow
<gouchi> sergiusens: thank you
<gouchi> sergiusens: the software can work with drm/kms and egl
<gouchi> sergiusens: so not sure if need x11 for interfaces, I just added it for devices running on X
<ogra_> you surely want the gl interface
<gouchi> ogra_: yes I put it
<jdstrand> roadmr (cc beuno and noise): can you pull r669 into the store? I've got another couple of things I'm working on and may request another pull before that lands, but wanted to get r669 on the books as it helps with developer velocity
<roadmr> jdstrand: will do
<jdstrand> thanks!
<jdstrand> roadmr: note, this isn't an emergency pull, but sooner is better
<jdstrand> if that makes any sense
<jdstrand> :)
<roadmr> jdstrand: ok, I think we were looking into deploying in the next couple of days
<roadmr> jdstrand: yea : "Not in a hurry but would prefer not to wait until next month" :)
<jdstrand> great. also note the conversation with nessita-- the the lp team name changed from click-reviewers to store-reviewers
<jdstrand> roadmr: ^
<jdstrand> hehe, yeah, something like that :)
<roadmr> jdstrand: yes, I'm aware of that (*painfully* aware... haha)
<jdstrand> oh hrmm.. I didn't mean to cause pain. sorry
<roadmr> jdstrand: no worries, we'll get it fixed - honestly our code/spec/infrastructure shouldn't be so vulnerable to branches moving around, so this is a good time to figure that out
<jdstrand> I'm glad I could 'help' then :)
<roadmr> yeah :) thanks :D
<sethj> can anyone help me figure out why this check fails inside the snap, but works just fine when installed from a .deb? https://github.com/colinkeenan/silentcast/blob/master/genffcom#L48
<sethj> The files are where they're supposed to be..
<sergiusens> elopio https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/9858103/+files/buildlog_ubuntu-yakkety-amd64.snapcraft_2.10+16.10_BUILDING.txt.gz
<sergiusens> I do have your test skip too
<sergiusens> elopio it might seem like we need to remove the test modulee
<elopio> sergiusens: hum, I don't understand.
<kyrofa> sethj, I assume /usr/share/silentcast something that's supposed to be shipped within the project?
<elopio> let me enable the daily on yakkety, to give it a try
<kyrofa> sethj, but if it's contained within the snap, it's not in /usr/share
<sergiusens> elopio sure
 * sergiusens raises fist at didrocks :-P
<sethj> kyrofa, I thought that was the whole point of contained, isolated, snaps?
<kyrofa> sethj, indeed, what I mean to say is that silentcast isn't in /usr/share. It's in /snap/<snapname>/<snapversion>/usr/share (I assume)
<kyrofa> So that's why the check is failing
<kyrofa> sethj, snaps aren't chroots
<sethj> ah. well I guess that is where I went wrong..
<sethj> I was assuming they were like chroots.
<kyrofa> sethj, nope, they're not containers, they're just confined
<sethj> kyrofa, in which case how would I snap that app successfully then?
<kyrofa> sethj, so you could use the $SNAP environment variable in that check
<elopio> sergiusens: ah, I skipped the set tour. We have to skip also the get tour.
<elopio> pff, this will never end.
<sethj> kyrofa, doesn't seem like a successful packaging method if you have to modify the source.
<kyrofa> sethj, not a lot you can do with hard-coded source
<kyrofa> sethj, it'd be nice if it was more configurable
<sethj> hehe, well blaming the source because the packaging method doesn't allow you to set it up properly seems a bit silly ;)
<elopio> sergiusens: https://github.com/ubuntu-core/snapcraft/pull/549
<kyrofa> sethj, you have source that is hard-coded for an FHS that doesn't apply to snaps. /usr/share is for architecture-independent data. It was created as a place where packages can place their data side-by-side without interfering with one another
<kyrofa> sethj, however, snaps don't have to deal with that-- they're isolated
<kyrofa> sethj, I'm not saying your source is broken, I'm saying it's making assumptions that don't apply :)
<sethj> I'm not sure I would call it isolated if it doesn't act like a chroot.. but that's beside the point. I'm not sure the few pluses of snaps is worth the work of rewriting the app to fit your system, when it already works with the majority of the other packaging systems..
<sethj> I liked the idea originally :/
<kallisti5> elopio: oh... I was hoping for a minimal install we can base our product appliances on :-(
<kallisti5> we have an agreement with ubuntu, however we're starting to look to stripping down the ubuntu install iso
<kallisti5> a lot of the automaton on install media generation that Debian provides doesn't work with ubuntu stuff
<kallisti5> so we're stuck manually trimming down the os install media :-\
<elopio> kallisti5: you can create a minimal image too. We are currently working on the ubuntu-image tool that will make it easier. But you can generate an image only the three snaps: kernel, os and gadget.
<elopio> I'm not sure if that's what you are after, though.
<kallisti5> elopio: aahh.. that's right
<kallisti5> I saw the tool
<kallisti5> last time I played with it, it gave a disappointing "this doesn't work right now" :P
<sergiusens> kallisti5 the whole image building story in in flux right now, should happen soon though
<sergiusens> but not real soon, just soon
<kallisti5> huh.  That seems like a pretty important story :P
<elopio> ogra_: are you around? I don't know how to dput something to a PPA, for both xenial and yakkety. Only the xenial one appears.
<kallisti5> anyway, not judging.
<kallisti5> we have a hardware appliance that is BYOH
<kallisti5> I get tired of doing battle with ubuntu preseeds :-)
<elopio> kallisti5: I would recommend you to jump into the mailing list and explain what you want. You'll get tips of how to do it know, and you'll be able to influence how the new things will be.
<kyrofa> kallisti5, we agree that it's a super important story! That's why we're working to make sure the underlying requirements are in place :)
<AndyWojo> Is the snappy store live?
<kyrofa> AndyWojo, indeed it is
<AndyWojo> Where is it at?
<kyrofa> AndyWojo, still undergoing development, but definitely in a usable state
<kyrofa> AndyWojo, you can upload/publish snaps at http://myapps.developer.ubuntu.com/
<AndyWojo> cool
<AndyWojo> thanks
<AndyWojo> I want to create a snap for some scripts I'm writing in ruby that will just work so the user doesn't need to worry about gems etc
<kallisti5> kyrofa: i'd voice these in #ubuntu but I got banned long ago :-)
<kyrofa> AndyWojo, excellent idea! You may be the first person to try a snap with ruby, I'd be very curious to see how it goes!
<AndyWojo> kyrofa: cool.
<AndyWojo> It's a script that is used to copy config files and log files from an OpenStack environment, in a way so you can send to support / pastebin / irc
<kyrofa> AndyWojo, where are the config and log files typically located?
<kyrofa> AndyWojo, /etc and /var/log ?
<AndyWojo> yup
<AndyWojo> also does a ps -ef
<AndyWojo> to see what's running etc
<AndyWojo> custom openstack commands to see whats running
<kyrofa> AndyWojo, by default snaps can't reach outside of itself, so make sure you read up on interfaces for how to extend its capabilities: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<kyrofa> AndyWojo, also keep in mind that you can install with --devmode to run unconfined
<kyrofa> (should ease development of the snap so you can worry about confinement later)
<elopio> maybe it's not appearing because there is already a snapcraft 2.10 in the PPA. I'll wait until the changelog is landed to retry.
 * elopio lunch.
<sergiusens> elopio after lunch, mind going over the bugs to see if they have correct descriptions?
<sergiusens> It shouldn't be needed in theory, but who knows.
<elopio> sergiusens: like the SRU template? I've already done that for all 2.10
<sergiusens> elopio really? I thought some were missing when I was tagging
<sergiusens> I guess it is fine
<elopio> I might have missed one, the list is big. But I went one by one. I can quickly check again.
<elopio> yep, all good.
<elopio> sergiusens: I put the impact under the original description, so maybe you have to scroll to see some.
<vejmarie> ok I have been able to fix my free cad font issue
<vejmarie> still need to fix the theme issue
<vejmarie> and we will have a fully functional snap exactly like the original app
<sergiusens> elopio thanks. The only problem I have now is https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=snapcraft :-P
<elopio> well, that's a better problem to have than the others.
<vejmarie> (the font thing is ugly, but this can help you to understand what is needed)
<sergiusens> vejmarie when you say "you" who do you mean?
<vejmarie> argh sorry: people who are developing snapcraft
<vejmarie> I am trying to track down all the system file that are needed to make it work properly from a graphical perspective to either turn on AppArmor
<vejmarie> which in some way I believe is not the right way to proceed I had rather prefer to see the applications coming with there own fonts and theming system (which is the current broken part on freecad)
<vejmarie> )
<vejmarie> So I am pretty closed to have everything into the snap (by everything I mean things which are needed)
<vejmarie> I am checking the GTK theme but it shall be good by sunday night
<erio> hello!
<vejmarie> hello
<erio> vejmarie: I am having a little doubt on writing the snapcraft.yaml
<vejmarie> if this is just one it might be good ;) (I am kidding)
<vejmarie> I am not a specialist
<vejmarie> but let's try to see where is your issue (I am not the only one connected)
<erio> ok! I am using plugin: python3
<erio> damn
<erio> ok
<erio> I am using plugin: python3
<erio> and there I wrote python-packages:
<erio> but I also set a source (from github)
<erio> my problem is that my script is getting the source and trying to build things
<erio> instead of getting the python-packages first
<erio> the source contains a setup.py
<erio> and it works when I download and use `pip3 install .`
<erio> wait... it worked.
<erio> I forgot a dependency needed nevermind.
<erio> the end of this tutorial should include how to install
<erio> https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap
<vejmarie> good to see it working ;) congrats
<erio> yeah
<erio> I am getting...
<erio> Fatal Python error: Py_Initialize: Unable to get the locale encoding
<erio> ImportError: No module named 'encodings'
<erio> when running...
<erio> I added locales as stage-packages
<erio> could you guys add a python3 plugin hello world example for snapcraft.yaml somewhere?
<erio> is Python 3 the default python inside a snap ?
#snappy 2016-06-04
<dougb> On BeagleBone Black only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
<vejmarie> ok good new I fixed the font issue with FreeCAD
<vejmarie> the FEM module is now working with Calculix straight forward
<vejmarie> and the mathplotlib works
<vejmarie> so I am going to push for an update of the snap
#snappy 2016-06-05
<gouchi> hi
<gouchi> is it possible to install a snap package directly on snappy ?
<gouchi> I need to make some test before submitting
<gouchi> like snappy install XXX.snap ?
<gouchi> it is not valid
<vejmarie> good afternoon everybody
<dougb> On BeagleBone Black only ttyO0, the console serial, is enabled. How do I enable the other available serial ports in Snappy?
<vejmarie> hello
<vejmarie> any idea on how long the manual review process takes ?
<sethj> gouchi snap install XXX.snap
<gouchi> sethj: using ubuntu snappy
<gouchi> sethj: there is no snap command
<sethj> gouchi does that not work on snappy? oh.
<gouchi> sethj: only snappy command
<sethj> ah.
<gouchi> sethj: I tried to do it on Ubuntu Desktop but you can't right now as there is an issue with live usb
<sethj> is snappy playpen happening tomorrow or on the 7th?
<sethj> The blog post says the 7th, but Google sent me a reminder for tomorrow..
#snappy 2017-05-29
<Hilikus> how can i configure my wireless adapter in ubuntu core? in the initial setup i wanted to use the ethernet port but now i want to configure wifi
<zyga> morphis: hey
<morphis> zyga: hey!
<morphis> zyga: nice talk :-)
<zyga> morphis: thank you :)
<morphis> zyga: feedback was positive too?
<zyga> morphis: yes, though there were specific issues raised as well
<morphis> interesting :-)
<zyga> morphis: we need to get snapd into factory, piece by piece
<mup> PR snapd#3404 opened: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3404>
<zyga> morphis: from there we can go to tumbleweed and SLE
<morphis> you heard any response on the question for vendoring?
<zyga> no
<zyga> but the people packaging go were not present, we should reach out to them
<zyga> my suspicion is that we may have to devendorize
<morphis> zyga: you have any contacts at hand?
<zyga> no, but I know how to find them
<zyga> suse employee now manages all of golang, I just need a google to find ihm
<mup> PR snapd#3404 closed: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3404>
<morphis> zyga: great
<morphis> zyga: any other interesting things?
<zyga> morphis: btw, is it expected that socket and services are off after installation?
<morphis> yes
<morphis> we don't have a preset
<zyga> morphis: yes, plenty but I need to write down some things first
<morphis> same problem as on fedora
<morphis> zyga: see https://snapcraft.io/docs/core/install-opensuse
<morphis> you need to call: $ sudo systemctl enable --now snapd.socket
<zyga> oh
<zyga> those instructions
<zyga> need to patch them to include -r
<zyga> or something likethat
<zyga> to automatically refresh that repo
<zyga> otherwise you get stuck on stale
<morphis> -r for what?
<morphis> systemctl?
<zyga> no
<zyga> zypper addrepo
<zyga> run that with --help
<mup> PR snapd#3405 opened: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3405>
<morphis> zyga: I see
<abeato> zyga, hey, waiting for you input in https://github.com/snapcore/snapd/pull/3353
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<mup> PR snapd#3406 opened: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406>
<morphis> zyga: ^^
<zyga> abeato: hey, I'm traveling today so I think I will only get to that tomorrow, sorry
<abeato> zyga, ack, nw
<abeato> ogra_, hi, is https://github.com/snapcore/core-build/pull/13 good now or you need to do some further review?
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<ogra_> abeato, approved
 * zyga heads to the airport
<zyga> ttyl
<abeato> ogra_, thanks!
<ogra_> mvo, when exactly do we copy the kernel to the vfat on arm core images, is that in prepare-image when building the img or only later in firstboot ? (there is still quite a slowdown on arm boards before console-conf comes up on first boot)
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all} <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mvo> ogra_: pretty sure we do it in prepare-image, what kind of slowdown do you still see? minutes?
<ogra_> mvo, i worked on a new bbb gadget on the weekend and there it is about 1.5-2min sitting there before "please press enter"" shows up
<mvo> ogra_: ok, I need to look, pretty sure we skip unpacking the kenrel itself, but there is probably copying of snap from seed to disk, iirc we optimized this away but maybe I misremember
<mvo> ogra_: lets talk after lunch
<ogra_> yeah
<ogra_> mvo, btw ... new shiny https://github.com/ogra1/beaglebone-gadget ... ;) (builds everything completely from source from upstream u-boot)
<zyga> o/
<zyga> mvo: hey, how's everything?
<zyga> morphis: are you subscribed to the factory mailing lisdt?
<morphis> zyga: no
<morphis> zyga: you have a link?
<zyga> morphis: sure, one sec
<zyga> https://lists.opensuse.org/opensuse-factory/
<zyga> let's say hi there and announce our intent to package snapd golang dependencies
<zyga> snapd by itself will land last because of extra security review needs/
<ogra_> hmm ...
 * ogra_ looks at https://sourceforge.net/p/tuxbox-cvs/boot/ci/321c664f88011fa152031d7fbb22b68893daa320/tree/u-boot-tuxbox/fs/ ...
<zyga> I think that we want to have a feeling of how opensuse golang packages look like today
<ogra_> too mbad thats for a very old uboot version and also only uses squashfs 2.x
<zyga> and come up with a leaf package that can be sent out
<ogra_> but it could save us from kernel-in-vfat on arm ...
<morphis> zyga: sounds like a plan
<zyga> morphis: I asked on IRC but I'll keep looking
<zyga> morphis: I'm away from my suse machines now (and this laptop has not enough memory to run VMs for real :-( so I won't be able to try until tomorrow
 * zyga will be home at 23:00 :-(
<morphis> zyga: ok
<zyga> morphis: have you seen jamie bennett today?
<morphis> zyga: I saw mails from him :-)
<zyga> https://en.opensuse.org/openSUSE:Packaging_guidelines and https://en.opensuse.org/openSUSE:Packaging_Go
<morphis> zyga: yeah, I know these
<zyga> morphis: also https://lists.opensuse.org/opensuse-factory/2017-02/msg00002.html
<morphis> :-)
<morphis> smells like a world with no written rules yet
<pstolowski> mvo, hey, i need your help. i'm having issues with spread tests on my machine, they fail even in master when building the deb with 'dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere'
<pstolowski> mvo, evidence says you may know something about this package ;) (and I've it in my vendor/)
<mvo> pstolowski: have you merged master? could you please double check that your vendor is clean
<mvo> pstolowski: the uboot-go stuff recently got moved from something external to an internal thing so probably you see fallout from that
<pstolowski> mvo, git clean -fd would do it right?
<mvo> pstolowski: -x but its quite dangerous, rm -rf vendor/githhub.com might be easier. and then ./get-deps.sh
<pstolowski> mvo, ok, will try that, thanks
<mvo> pstolowski: good luck, please keep me update
<mvo> d
<morphis> mvo, pstolowski: I saw the same this morning, fetching deps again helped to solve that issue
<pstolowski> mvo, morphis yay, thanks, removing vendor and refreshing it helped
<mvo> great
<mvo> sorry for the trouble
<morphis> mvo: you have time for a review on https://github.com/snapcore/snapd/pull/3365 ?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<morphis> fgimenez: ^^
<fgimenez> morphis: sure, i'll take a look
<morphis> fgimenez: thanks!
<mup> PR snapd#3407 opened: interfaces: move seecomp profiles to /var/lib/snapd/seccomp/profiles-v2/ <Created by mvo5> <https://github.com/snapcore/snapd/pull/3407>
<mvo> morphis: I can look in a bit, a bit busy with the 2.24->2.25->2.24 revert problem. quick question - can we share code with snap-mgmnt.sh and snapd.postrm purge? it seems there is a bit of duplication and given that this is realy non-trivial it worries me a little bit that we duplicate it currently
<morphis> mvo: yes, but would like to do that in another PR
<morphis> mvo: as there are a few differences too
<mvo> morphis: aha, interessting, sure a different PR is totally fine. curious about the differences. just because of different paths? /snap vs /var/lib/snap ?
<morphis> mvo: no, not just the paths, but the Ubuntu variant does a rm -rf /var/lib/snapd where as the rpm pkg relies on rpm removing that etc.
<morphis> nothing fancy but small differences
<morphis> and actually Son_Goku wanted to do that if I remember right
<mvo> morphis: aha interessting,
<mvo> morphis: so rpm will remove even untracked files in there?
<morphis> no, the script as to clean those
<mvo> morphis: aha, I see its only removing things that are not tracked, we could do the same in the postrm
<morphis> but rpm isn't happy if the dir is removed by something else
<mvo> morphis: anyways, this should not be a blocker for unification :)
<morphis> jepp, we have that on the list and will unite those things, makes only sense and becomes easier now that we have all packaging bits together
<mvo> morphis: +1 - thank you!
<niemeyer> Morning all
<morphis> niemeyer: morning!
<niemeyer> morphis: Heya
<niemeyer> morphis: How's that SuSE machine going?  Do you want to give it a shot again?
<morphis> niemeyer: I didn't had time to clean it up yet again
<morphis> but will do that in the afternoon
<mvo> hey niemeyer, good morning
<morphis> niemeyer: time for a review on https://github.com/snapcore/snapd/pull/3365 and https://github.com/snapcore/snapd/pull/3394 today?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<mup> PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394>
<niemeyer> morphis: Looking now
<morphis> niemeyer: thanks!
<niemeyer> morphis, Son_Goku: One thing I was wondering about last week was that purging logic. It looks like we have a lot of duplicated logic between the deb package and the rpm package. This logic looks pretty easy to get wrong, and twice is twice the chances..
<morphis> niemeyer: I've just talked about the same thing with mvo minutes before you joined
<mvo> jdstrand: when you around I would love to talk about 3407
<morphis> niemeyer: the unification of that logic is the goal but that requires a few more small steps to do that right and refactorings
<morphis> niemeyer: actually Son_Goku wanted to do that
<mvo> jdstrand: i.e. something to do short term to unblock us and then I think a schema that makes seccomp similar to apparmor with cache etc would be cool
<morphis> niemeyer: I would leave that up to another PR and concentrate on the spread bits for fedora here but unification of that logic is definitely one of the next steps
<niemeyer> morphis, Son_Goku: Aha, okay.. yeah, not suggesting it to be done in this PR
<jdstrand> mvo: hey, I commented. I don't really think new directories are the path forward. have we seen this as a real issue people are facing (again, this is something that was there all along)
<jdstrand> ?
<mvo> jdstrand: yes, CE found this while doing testing on a real device and we have a reproducer, the particular issue is the network-manager snap which starts early and if it fails there is no networking
<mvo> jdstrand: I agree with your concerns, however I have a hard time finding a way to fix this issue without introducing a new path, i.e. violating this design contrain for this one time
<jdstrand> mvo: but it won't be for this one time. if you add the directory, then it will be there forever, no?
<mvo> jdstrand: yeah, the old dir will be phased out but yes, its ugly
<jdstrand> but it can't be phased out, right? I mean, you can revert to anywhere
<jdstrand> I'd much rather drop the mknod and reintroduce it later than add a directory
<mvo> jdstrand: correct, we can never remove it. however noone will see the old dir if the device starts out with snapd 2.26.X because only older versions would ever write it
<jdstrand> sure, but then we have -v2 there
<jdstrand> (icky)
<jdstrand> I mean, don't get me wrong, I understand why, just it's icky
<jdstrand> mvo: what are the requirements for this fix?
<mvo> jdstrand: yeah, I will not fight for it, I think its ugly too, I'm keen to find something better :)
<mvo> jdstrand: the fix would allow us to go 2.24->2.25->2.24 (and also other version like 2.21->2.26->2.21) without breaking, this is why I'm not sure that reverting the mknod one really helps that much as we will have to re-introduce it at some point and then we write an incompatilbe profile again and have the same issue as now (?)
<mvo> jdstrand: I have the standup now, so if you have time we can continue to brainstorm in ~45min ?
<jdstrand> ok
<mvo> jdstrand: fwiw, I'm also working on a seccomp-profile -> bpf tool that should also help but it won't help with 2.24 as that does not know anything about this yet (following your suggestions to model it after apparmor and its txt->cache)
 * jdstrand nods
<pstolowski> mvo, one more think i'm having issue with.. any idea where does a bizzare version number such as 'Get:1 /home/gopath/snapd_1337.2.26.3_amd64.deb snapd amd64 1337.2.26.3' may be coming from? that's what makes my tests fail still
<ogra_> but it is leet !
<Son_Goku> mrgh?
<Son_Goku> I seem to have been mentioned a lot in the last few hours...
<Son_Goku> mvo, niemeyer: the creation of snap-mgmt.sh is because there was a bug filed about how snapd couldn't clean itself up on uninstall in the Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1444422
<mvo> Son_Goku: yeah, the script is great, we would just like to share some more code but morphis_ assured us its already on the list
<Son_Goku> it took quite a few tries to generalize it :)
<morphis_> Son_Goku: :-)
<morphis_> Son_Goku: do you want to generalize is a bit more so it's usable on Debian/Ubuntu too?
<Son_Goku> there's really only one thing that has to be done: make it so that snapd.postrm's SNAP_MOUNT_DIR is taken into account
<Son_Goku> rest of it should work
<Son_Goku> and the postrm needs to be a prerm
<Son_Goku> the Debian packaging is quite hard to get right for file/folder tracking, though
<Son_Goku> as there's no concept of a file list in Debian source control packaging like there is in spec packaging
<Son_Goku> my snap-mgmt.sh is intended to be run by a package manager that actually can track files properly
<Son_Goku> as far as I know, the only files dpkg fully tracks are conffiles
<Son_Goku> mvo, unless I've missed something?
<mvo> Son_Goku: in a meeting right now so a bit slow. I think we can talk about details, dpkg does track files (not dirs which can be surprising) so things should work out, but lets look at the details in a little bit
<pstolowski> mvo, http://pastebin.ubuntu.com/24703100/
<pstolowski> mvo, it looks like we expect "unknown" keyword in the version, but for some reason I've this 1337... number
<pstolowski> mvo, I'm not sure what we're trying to test there
<mvo> pstolowski: hm, this is odd, could you add a bit more lines to the pastebin please?
<mvo> pstolowski: I see something like this   in tests/lib/prepare.sh  but the error does not match the pastebin so maybe it is something else?
<pstolowski> mvo, http://pastebin.ubuntu.com/24703148/
<pstolowski> mvo, i've this session opened for debugging.. and indeed I see snap    1337.2.26.3
<pstolowski> snapd   1337.2.26.3
<mvo> pstolowski: that should be ok, what does `snap changes` and especially the last change (the one about the refresh-schedule) show? that seems to be the root cause, we need to figure out why that fails
<mvo> pstolowski: aha!  snap set core refresh.schedule=Wed@12:00-14:00
<mvo> pstolowski: the "weekday@something" is not supported currently, only refresh schedules in a single day
<mvo> pstolowski: where does that come from?
<pstolowski> mvo, it's my branch, in sync with master; but I haven't added or touched that
<pstolowski> mvo, prepare has it:  snap set core refresh.schedule="$(date +%a --date=2days)@12:00-14:00"
<pstolowski> prepare.sh
<niemeyer> morphis_: snapd#3365 reviewed
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<morphis_> niemeyer: thanks
<pstolowski> mvo, what happens if you try this unsupported syntax? it ignores all that and refreshes during the test?
<mvo> pstolowski: is that maybe based on some older branch? could you merge master please?
<mvo> pstolowski: this syntax will lead to an error
<pstolowski> mvo, i'm up-to-date with master, and master has it too
<mvo> pstolowski: let me check, thats slightly odd
<mvo> pstolowski: I see it here as well
<mvo> pstolowski: interessting bug
<mvo> pstolowski: definitely something wrong with this test setup, the interessting question is of course why only you hit it
<pstolowski> mvo, indeed. i'm hitting it also with master
<fgimenez> pstolowski: are you executing from a clean (just cloned) master on a linode backend? to reproduce the exact conditions of a working environment you could also get the spread binary as travis does https://github.com/snapcore/snapd/blob/master/run-checks#L178
<pstolowski> thanks fgimenez, i will try that
<niemeyer> morphis_: 3394 reviewed as well
<morphis_> niemeyer: nice!
<mup> PR snapd#3408 opened: tests: add alsa interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3408>
<niemeyer> Week 22 report is out, and lunch is out too.. biab
<niemeyer> Erm.. week 21 I mean..
<niemeyer> Week 22 is the one we're in.. feel free to send topics in
<jdstrand> mvo: are you able to discuss now?
<ogra_> wohoo
 * ogra_ just had two different initrd.img files loaded in u-boot and they are merged!
<ogra_> firsdt step towards modules-only initrd
<ogra_> *first
<mvo> jdstrand: I updated the forum topic, I need to step out for 10min and soon dinner
<mvo> jdstrand: I put my thoughts into https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-revert-race-condition/722/6 - feedback welcome. also happy to hear if you or niemeyer have some more ideas what we can do short term
<jdstrand> mvo: I think we should remove the mknod calls in a 25 point release, then discuss how to handle 25 to 26
<jdstrand> mvo: I commented in the pr
<mvo> jdstrand: thank you!
<mvo> niemeyer: you mentioned you would like to talk about it some more, do you want a hangout or some more forum discussion? I'm happy either way, just today is inconvinient, I will have to run in some minutes to play hockey, tomorrow will be fine though
<niemeyer> mvo: SOunds good, let's do it
<niemeyer> mvo: tomorrow, that is
<mvo> niemeyer: thanks
<niemeyer> mvo: As mentioned there, the immediate solution is starting to sound a lot like the long term one, so we should at least brainstorm a bit to see how to these two play together
<mvo> niemeyer: yeah, it sounds like they converge nicely, i.e. our hash could simply be "seccomp-syntax: v2|hash" and thats all the inputs we do for now, we just need to tweak snap-confine so that it knows from what dir to read, i.e. something in snapd needs to tell snap-confine (it used to be hardcoded)
<mvo> (our initial hash I mean)
<mvo> niemeyer: actually given that this is the *only* input we have currently we could even cheat in snap-confine and hardcode the result of the hash (as we know its input already) - not sure if that is worth it though
<niemeyer> mvo: As I just stated in the forum thread, stating the version explicitly won't do a lot for solving this particular case
<niemeyer> It's a good practice and we should do regardless, but we know the profile is incompatible.. knowing it via a different field wouldn't really sort the problem out for us
<niemeyer> mvo: Sorry.. I mixed stuff up
<niemeyer> mvo: Precisely because I was talking in the forum about something else very close it it.. :/
<niemeyer> mvo: Yes, we might do something along those lines
<mvo> niemeyer: yeah, I think I did not express myself well :) I meant specially the profile/<digest>/ input
<niemeyer> mvo: It was really my brain that was hovering over a different part of the idea..
<mvo> niemeyer: excellent, I think we are on the same page, lets talk tomorrow, maybe jdstrand can join us too if he wants?
<niemeyer> mvo: Yeah, let's discuss this tomorrow
<mvo> niemeyer: thank you!
<niemeyer> mvo: I don't think it makes sense to ask snapd to tell snap-cofnine what to read..
<niemeyer> mvo: This is part of the problem we have today
<niemeyer> mvo: snap-confine can tell what it _can_ read
<mvo> niemeyer: I see, yes
<mvo> niemeyer: we will need two digest generators then, right? one in C and one in go? or we could use the go one and just popen() it (not really popen, but the concept)
<niemeyer> mvo: Anyway, enjoy hockey! Let's catch up tomorrow
<niemeyer> mvo: Yeah, not sure of the details..
<mvo> niemeyer: yeah, need to run, but an exciting problem to solve :) see you tomorrow
<mvo> jdstrand: I'm also quite excited about the bpf generator, I think this will be superfun
<mup> PR snapd#3409 opened: tests: fix snap confine from core test to check the restart was done <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3409>
<morphis_> niemeyer: 1.2G ok for you?
<niemeyer> morphis_: Let's try that out to see how much it looks like in practice when doing the block-level resize
<morphis_> ok
<morphis_> niemeyer: Spread-53 it is
<niemeyer> morphis_: On it
<morphis_> thanks!
<cachio> niemeyer, is there any way to monitor the connections queue in the store?
<niemeyer> cachio: Hmm.. which queue?
<niemeyer> morphis_: This is still 1.86GB
<cachio> niemeyer, is there any inbound connection request queue?
<morphis_> df shows me 1.2G
<cachio> niemeyer, that the store processes?
<niemeyer> That's the TCP queue I assume?
<cachio> yes
<niemeyer> morphis_: Right.. that's file-used data, vs. block-level usage
<morphis_> yes
<niemeyer> morphis_: The image is block-level
<cachio> niemeyer, I see some connection refuse comming from the store
<morphis_> could be that this is the whole btrfs snapshot thing suse uses to keep the system state around
<niemeyer> morphis_: Or perhaps some big dependency tree on something in the system?
<niemeyer> morphis_: Like a graphics stack or whatever
<morphis_> no
<morphis_> I removed all of that
<niemeyer> cachio: noise][ or nessita might be able to help
<morphis_> https://paste.ubuntu.com/24705005/
<cachio> niemeyer, ok, tx
<morphis_> a `$ rpm -qa --queryformat="%{NAME} %{SIZE}\n" | sort -k 2 -n` is pretty handy for that
<niemeyer> morphis_: What is du -sh showing?  Where' the bulk of the data?
<morphis_> niemeyer: the system is now powered off
<mup> Bug #1672740 opened: Netplan replug function is incompatible with ath9k_htc module <verification-done> <netplan:Fix Released by cyphermox> <Snappy:New> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1672740>
<niemeyer> morphis_: Turning it back on
<morphis_> thanks
<niemeyer> Argh
<niemeyer> morphis_: We've got run over by Spread :(
<morphis_> :-)
<niemeyer> Should have taken the machien out of rotation first
<niemeyer> This used to be safe, but not anymore
<niemeyer> morphis_: We'll need a new run, sorry about that
<morphis_> niemeyer: np, getting a routine in doing that :-)
<cachio> nessita, I saw some of these https://paste.ubuntu.com/24705022/ last week
<cachio> nessita, is there any way to monitor that and see what's going on?
<niemeyer> morphis_: Good thing it's automated
<morphis_> niemeyer: according to du -hs back to 1.2G
<morphis_> and just checked, it doesn't use any btrfs snapshots
<niemeyer> morphis_: So where is the size coming from?
<niemeyer> morphis_: I wonder if we could try defragmenting to at least push the size down
<morphis_> I am looking into that already
<niemeyer> morphis_: I expected that to happen automatically as a side effect of resizing, but I'm surprised at the amount of space lost
<niemeyer> morphis_: Is there a place with tons of small files?
<morphis_> no
<morphis_> niemeyer: let me remove a few more packages if I can as there is still a bit too mcuh in /usr/share
<morphis_> but there is no good separation into single packages that it's obvious what to remove in Suse (like in debian we have -docs etc.)
<niemeyer> morphis_: let me know
<morphis_> niemeyer: down to 1.1G on spread-42, can you check the size on your side without powering the node off?
<mup> PR snapcraft#1336 opened: HACKING: make running from virtualenv more obvious <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1336>
<morphis_> niemeyer: otherwise feel free to snapshot spread-42 now, that is the smallest (1.1G) I could get it
<captine1> hi all.  I am trying to find the snap refered to in this article
<captine1> https://insights.ubuntu.com/2017/02/22/an-ubuntu-snap-based-solution-for-enterprises-to-control-their-data/
<niemeyer> morphis_: Sorry.. missed your previous message
<captine1> anyone able to assist?
<niemeyer> morphis_: Running on it now
<morphis_> thanks
<niemeyer> morphis_: All done
<morphis_> niemeyer: awesome! thanks
<niemeyer> morphis_: Ended up at 1.5GB
<niemeyer> morphis_: Machine is back up
<morphis_> ok
<mup> PR snapd#3333 closed: vendor: refresh everything <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3333>
#snappy 2017-05-30
<daker> hello, build.snapcraft.io question: how can i tell the site to pull submodules too ?
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<daker> captine: i guess it's commercial
<Hilikus> is there a browser available in snappy? i am not sure how snappy works with GUIs. will it pull the whole X-server, window manager, etc??
<captine> daker, thanks.the liune "available as an image so anyone can download" is a little misleading if it is commercial only
<mup> PR snapd#3394 closed: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3394>
<NicolinoCuralli> hi guy, i'm tryng to run the command snapctl set device-service.url="https://device-service" from the login shell but i have the following error: *error running snapctl: cannot set without a context* - where is the problem?
<morphis_> NicolinoCuralli: you can only run snapctl from within a hook, like the prepare-device hook
<morphis_> manually invoking snapctl from outside of any context is not possible
<mvo> pstolowski: are you still having this autopkgtest problem?
<NicolinoCuralli> morphis_: can i run it on configure hook for a snap?
<morphis_> yes
<morphis_> NicolinoCuralli: however, "snapctl set device-service.url .." only makes sense as part of the prepare-device hook
<NicolinoCuralli> morphis: I undestand it but i can't setup a Serial Vault for problem that I wrote in a post on forum ( no response until now)  and i need to go in production in a few week with our brand store
<pstolowski> mvo, hi! no, I followed advice from fgimenez and started from a clean directory, it's actually a problem in my branch
<morphis_> NicolinoCuralli: you have a link to that thread?
<NicolinoCuralli> morphis_: https://forum.snapcraft.io/t/how-configure-serial-vault-for-signing-serial-assertion-with-a-key-registered-to-a-store/731/6
<fgimenez> hey pstolowski good to know! :)
<morphis_> NicolinoCuralli: ah I see, so the problem is just with the setup of the serial-vault, that is up to James
<fgimenez> good morning mvo! quick question, we didn't have new edge core snaps this morning, is that expected?
<morphis_> NicolinoCuralli: but it is essential that snapctl set device-service.url is called from within the prepare-device hook of the gadget snap
<morphis_> NicolinoCuralli: otherwise your device bootstrap process may be broken
<mvo> fgimenez: not expected, let me check
<fgimenez> mvo: ok thanks!
<mvo> pstolowski: aha, ok. thank you, still curious what could have caused this. when I have a free minute I will try to dig some more
<mvo> fgimenez: ha! "store upload failed: service unavailable" â¦
<pstolowski> mvo, the root cause i'm chasing is configure hook failure in my branch, and this is related to the renaming of SNAP_CONTEXT variable in my branch (which breaks all hooks in my branch atm)
<zyga> hey hey
<NicolinoCuralli> morphis_ : then I am blocked until  jamej fix the problem :(
<fgimenez> mvo: aha, ok, at least the dashboard seems to be fine now
<morphis_> NicolinoCuralli: you mean you're blocked because your device gets no serial-assertion?
<NicolinoCuralli> morphis_ : i need to use Serial-Vault to block device not mine then i'm blocked
<morphis_> NicolinoCuralli: you mean you want to block other devices from accessing your branded store?
<NicolinoCuralli> morphis_ :yes
<morphis_> ok
<morphis_> you could, as a workaround, turn device authentication off in the branded store and keep things in place until James fixes the problem
<zyga> mvo: I need some time to get my stuff together and catch up, do I understand that the key issue to fix is still seccomp format?
<NicolinoCuralli> morphis: prepare-device is very simple but without test it  I am sure taht it works: it is very dangerous
<NicolinoCuralli> morphis: prepare-device is very simple but without test it  I am not sure that it works: it is very dangerous for us
<mvo> zyga: no worries, the seccomp issue has multiple dimensions, the most pressing one is that we need to unblock 2.25, I will catchup with gustavo about this today in a hangout
<zyga> mvo: how can I help?
<morphis_> NicolinoCuralli: sure, but at least you can verify that snapd takes up the right URL but fails to contact it
<morphis_> NicolinoCuralli: that is visible in the logs
<mvo> zyga: then there is the bpf thing which will not help with the immediate issue but will help in the longer term (and is fun :)
<mvo> zyga: let me think for a sec, the immediate issue is kind-of-blocked on design, I made various suggestions we now just need to decide which one we use
<zyga> mvo: understood
<zyga> mvo: I'll try to look at that lock issue
<mvo> zyga: what was that again about?
<zyga> mvo: the errors that show up on the errtracker
<zyga> mvo: about /run/snapd/lock access
<zyga> mvo: and one working theory that has a hard time to explain the volume of reports
<mvo> zyga: aha, right, thank you
<ogra_> bah ... all core uploads tonight failed with LP OOPSes
<wgrant> ogra_: https://forum.snapcraft.io/t/store-upload-issue/819/1, fixed a few hours ago. I think Michael's retrying them.
<ogra_> mvo, are you ? (else i'll do it now)
<mvo> ogra_: I have not yet, so go ahead
 * ogra_ does so :)
<ogra_> oh, interesting ... at the same time i see that LP auto-retries the failed uploads now ...
<ogra_> so we'll get two sets :)
<wgrant> Oh?
<wgrant> Oh, you requested fresh builds?
<ogra_> https://launchpad.net/~snappy-dev/+snap/core/+build/41415
<wgrant> I retried that one myself a couple of minutes ago
<ogra_> i requested fresh builds ... right afterwards i got a mail for a successfull upload
<ogra_> (from the former build obviously)
<wgrant> If the upload fails, you can just hit the Retry button on the build page.
<ogra_> ah, then that was you, ok
<wgrant> It retries just the upload step
<ogra_> yep, i know
<ogra_> clicking on 6 buttons on 6 pages is more work than calling a script for a full rebuild though ... i'm lazy ;)
<wgrant> Heh, fair enough.
<wgrant> My poor buildds :'(
<ogra_> wgrant, FYI, all uploads worked fine for this build
<wgrant> ogra_: Excellent, thanks for confirming.
<zyga> pedronis: hey, could you please look at https://forum.snapcraft.io/t/the-gadget-snap/696/4
<mvo> zyga: he may not be around today
<zyga> Chipaca: hey
<Chipaca> zyga: hiya!
<JamieBennett> How was the weekend zyga?
<Chipaca> i've seen photos of zyga doing stuff on twitter
<zyga> JamieBennett: busy :)
<zyga> JamieBennett: it was great, just wish I didn't spend nearly two days traveling there
<zyga> JamieBennett: I sent you some quick thoughts yesterday
<JamieBennett> zyga: ouch, I didn't realise it was so long for you
<JamieBennett> zyga: saw the draft feedback, I look forward to the full report
<zyga> yes, connections
<ogra_> zyga, The route is the goal ;)
<zyga> I'm getting back to speed, catching up on stuff first (I was home past 23:00)
<JamieBennett> zyga: lets catch up in 45 mins :)
<zyga> sounds good
<zyga> mvo: I commented a little on https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-revert-race-condition/722/13
<zyga> mvo: I think the divest idea is sound, I think it may have to be runtime (at least partially) detected but we can work with that
<zyga> mvo: I'm somewhat on edge about the digest itself, it could be nice to just call this a feature string so that we can easily eyeball things and understand what's going on
<mvo> zyga: yeah, right now its not much of a digest, I also like the property that it is human readable, lets see what gustavo thinks when we have the catchup. one thing I am slightly worried about is that we need to be careful to make it not too ambitious (at least v1) because we are currently blocking on it
<mup> PR snapd#3350 closed: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3350>
<zyga> pedronis: thank you!
<zyga> pedronis: I'm sorry I didn't review that
<zyga> mvo: re
<zyga> mvo: let's finish here
<zyga> mvo: how would you feel about teaching cmd.go to use the current revision rather than "current"?
<zyga> Chipaca: hey
<mvo> zyga: you mean for InternalToolPath?
<zyga> Chipaca: maybe you can have a saner idea
<zyga> yes
<zyga> Chipaca: we have a problem where we use internal tool path that follows the current symlink
<zyga> Chipaca: and in the upgrade path of core itself, we rely on that _before_ we link the now snap
<zyga> Chipaca: so new snapd wishing to use its new internal tools uses the old internal tools
<zyga> Chipaca: and in this case the old internal tool reports "sorry, I'm not implemented" and fails
<Chipaca> zyga: is this master, or omg-how-on-earth released?
 * Chipaca wants to know whether to have a heart attack or not
<zyga> Chipaca: I think this is master and OMG people tracking channels but I think mvo knows better
<zyga> Chipaca: but it would explain lots of error reports
<Chipaca> zyga: master breaks Â¯\_(ã)_/Â¯ it's why it's edge, i'm less worried
<mvo> Chipaca: I think its also affecting beta
<zyga> Chipaca: right but the point is we cannot release and need to fix this
<Chipaca> mvo: augh
<mvo> Chipaca: I'm trying to verify this right now, sorry, we are still in the early stages of investigations
<Chipaca> np!
<pedronis> zyga: what tools are we calling before we set the symlinks ?
<mvo> Chipaca: the symptoms are snap refresh outputs: "setup snap "core" (2053) security profiles (cannot update mount namespace of snap "go-example-webserver": cannot update preserved namespace of snap "go-example-webserver": cannot update snap namespace: not implemented)" and fails
<pedronis> ah
<zyga> pedronis: update-ns
<zyga> pedronis: because we follow current symlink
<pedronis> so there was an assumption that we can call setup-profiles both in the old world and the new world
<zyga> a naive approach would be to just follow the revision matching core that is running
<pedronis> zyga: I'm a bit confused though, if the old core is still running why is it trying to call a new tool?
<Chipaca> zyga: is this actually related to current?
<zyga> pedronis: it's the new core already
<pedronis> how can it be
<Chipaca> runNamespaceTool calls mountNsPath calls mountNsPath which doesn't look at current
<pedronis> something is not maing sense to me
<zyga> I'm looking at
<zyga> https://errors.ubuntu.com/oops/ef5ad412-4519-11e7-ac3f-fa163ebeb28a
<zyga> look what happens there
<zyga> we never ran update-ns before it was implemented
<zyga> but here we run update ns on core (so new snapd is doing that)
<zyga> and it reaches the never-used, not-implemented version that just says it's not implemented and fails
<Chipaca> ah, current is used by InternalToolPath
<zyga> yes
<zyga> Chipaca: yes, that's exactly the issue
<Chipaca> zyga: thing is, it isn't current yet
<pedronis> we run setup-profiles firs time before we run link-snap
<pedronis> that's by definition the old core
<Chipaca> so setup-profiles neeeds to run in the new core
<zyga> pedronis: yes, but pre-restart snapd never touched update-ns
<Chipaca> so it shouldn't be calling InternalToolPath
<pedronis> zyga: you understand the question is not how to make it work, why at all is the new core involved at that point?
<Chipaca> zyga: question: do you know what core you're running for, from UpdateSnapNamespace?
<zyga> pedronis: aha, I see
<Chipaca> pedronis does have a good point there though
<zyga> Chipaca: maybe, we could look at argv[0] or /proc/self/exe
<Chipaca> zyga: does that get updated on execve? (i don't remember)
<pedronis> we split setup-profiles to avoid that sort of problem
<pedronis> if it's happenign a  lot of other assumptions are wrong
<zyga> maybe something else is at play
<zyga> I have a sync call now but I will look at the revisions used there
<zyga> and see if there was something wrong at that stage
 * zyga joins  sync call
<mvo> Chipaca, zyga: *maybe* it only affects people on 2.26.3+201705171658.git.78e21e6
<mvo> zyga, Chipaca: when going over the error reports from the last two days I found only 2.26.3+201705171658.git.78e21e6, 2.26.3+201705191509.git.f89261c, 2.26.3+git209.2f19233 to be affected, everything before and after appears to be fine
<Chipaca> _and after_?
<mvo> Chipaca: well, its a good question, things do not refresh so maybe it is something else and this is just where it started
<pedronis> mvo: maybe that error is from an undo path?Â not the forward path
<zyga> JamieBennett: is this me or you?
<kyrofa> davidcalle, "download ubuntu core" on https://www.ubuntu.com/core is a 404...
<davidcalle> kyrofa: thanks, the WIP dev.ubuntu.com has been mistakenly deployed when I was off on friday and I'm collecting the pieces...
<kyrofa> davidcalle, ah, okay. Sorry man, that's never fun
<davidcalle> kyrofa: I believe you are in Bluefin today?
<kyrofa> davidcalle, I am!
<kyrofa> davidcalle, why, are you around?
<davidcalle> kyrofa: then hug the webteam for me, I'm sending them a ton of bug reports about it ;-)
<kyrofa> Hahaha
<davidcalle> kyrofa: no, I'll be there next week for a couple days
<kyrofa> davidcalle, dangit, come on man, we need to coordinate. I'll be back end of June, come back then
<davidcalle> kyrofa: well, I could be there, we'll see :)
<kyrofa> ;)
<pedronis> Chipaca: btw maybe you can do a 2nd review for snapd#3373
<mup> PR snapd#3373: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/3373>
<Chipaca> I can
<Chipaca> these tests make my head hurt anyway
<zyga> re
 * zyga lunch
<ogra_> davidcalle, according to a post in https://forum.snapcraft.io/t/startx-as-a-regular-user/460 the mir-kiosk docs are also gone from dev.ubuntu.com ...
<davidcalle> ogra_: I know, see above
<davidcalle> Oh, sorry, missed the "also"
<ogra_> :)
<davidcalle> Saviq: by any chance, when you worked on it a couple weeks ago, did you kept a backup of the content? I may be able to poke around in #IS and get something (archive.org most recent is april 16th from last year), but if you have it in some form it would be way faster to get it back online
 * Chipaca ~> lunch
<ogra_> pedronis, hmm ... my snap changes on self-built images is full with re-occuring "Initialize Device" entries ... i cant remember having that before (Initialize Device used to run only once and never again when it failed) ... is there any reason that we run it in a loop even though we alredy know the brand id will not be signable ?
<ogra_> that makes the snap changes output really noisy and hard to read
<daker> davidcalle: https://webcache.googleusercontent.com/search?q=cache:K946WjTJyyoJ:https://developer.ubuntu.com/en/snappy/guides/mir-snaps/+&cd=1&hl=en&ct=clnk
<daker> (21 May 2017)
<davidcalle> daker: ah! *hug*
<daker> davidcalle: if you need more content, you can just paste the link on google, there is a little arrow to get the cached version https://imgur.com/a/hDK0D
<pedronis> ogra_: it's a long while it behaves like that, it has a back off though, at it end it tries 1 or 2 times per day
<ogra_> hmm, then i probably didnt see it because my images were old installs ...
<cachio> mvo, any idea what could be affecting that I run the spread tests in linode from my machine and everything works and when I run the tests from travis the snap-confine-from-core which I modified is failing?
<ogra_> pedronis, but i still think trying more than once (as long as we know we reach the store and all) is a waste ... or is there any expectation that all of a sudden my barnd id can sign it ?
<ogra_> *brand
<cachio> mvo, I mean, is there something different in the runs we do from travis?
<pedronis> ogra_: we expect all devices ideally to have a serial, we are erring on the side of trying by design, as I said after a while it tries 1 or 2 times per day
<mvo> cachio: a good question, do you have a link to the failure? what travis runs is in .travis.yml, its very little, ./run-check.sh --static, --unit, --spread - does it maybe fail in one of the earlier tests?
<ogra_> pedronis, right, but it is very unlikely that a brand id that can not sign suddenly changes its behaviour
<pedronis> ogra_: we don't interpret the errors
<ogra_> so trying it over and over doesnt feel like it makes any sense
<fgimenez> hi pedronis, new create-key timeout on i386 https://travis-ci.org/snapcore/spread-cron/builds/237349446#L1551
<cachio> mvo, this is the link https://travis-ci.org/snapcore/snapd/builds/237376386?utm_source=github_status&utm_medium=notification
<cachio> mvo, I have executed those tests in the same way and I don't see any error
<cachio> mvo, also I executed the failing tests from my machine using linode repeating 200 times and all tests passed
<cachio> mvo, I have modified the test snap-confine-from-core to add a missing check
<jdstrand> mvo: hey, do you have time to talk about the seccomp/snap-confine issue?
<jdstrand> mvo: I feel like people aren't hearing my concerns about determinism
<mvo> jdstrand: I have 8min, then meeting, then time again
<mvo> cachio: looking, one sec
<mvo> cachio: hm, that sounds strange indeed
<mvo> jdstrand: am I one of the people who fail to hear your concern bout determinsim? if so, I definitely want to understand them
<jdstrand> mvo: well, I don't know if you are-- I feel that way because I haven't heard anyone acknowledge my point :)
<jdstrand> mvo: my point is-- the actually problem is that the policy on disk is not reflective of the snapd/snap-confine version that is used
<jdstrand> actual*
<mvo> jdstrand: not sure how busy you are today, but I would love to talk about it after our standup (so in ~30min or 45min depending how long it runs)
<jdstrand> mvo: please ping me whenever you are free
<jdstrand> mvo: it shouldn't take terribly long, but likely more than 8 minutes
<zyga> jdstrand, mvo: I'd like to participate please
<zyga> jdstrand: I think I understand your concern
<zyga> (and what mvo is trying to do)
<mvo> jdstrand: great, I will. however I'm not sure if thats the actual problem, I think we have a various ones (startup race, profiles not forward compatible, not versionized) but I think we will fix them all :)
<mvo> zyga: sounds good
<mvo> zyga: super keen to hear yours and jdstrand ideas what we can do
<jdstrand> mvo: I don't mind any of the improvements, but my point is that it just pushes the problem around. we need to have policy that is generated by the running snapd/snap-confine version otherwise there will always be other issues. it just so happens, if that is fixed, all the improvements are less important
<zyga> mvo: I think your idea is OK but jdstrand wants to ensure snapd still starts before services / commands can run,
<zyga> standup!
<jdstrand> yes
<mvo> jdstrand, zyga: yes, I think we want the same, its just one of the steps
<jdstrand> but if it is the first step, things are nice :)
<jdstrand> anyway :)
<roadmr> jdstrand: tools r822 are now in prod \o/
<jdstrand> roadmr: woohoo! :)
<jdstrand> roadmr: thanks :)
<morphis_> zyga: I sadly don't have time for that today but it would be great if we could sync up about the suse stuff tomorrow
 * Chipaca kicks off spread tests and goes for a cuppa tea
<didrocks> sergiusens: hey! small question: is it possible in the dump plugin, or via a scriptlet to differ actions (files to install) through arch?
<didrocks> I can ofc run "arch" in the scriplets, and depending on the result do some magicâ¦
<didrocks> was wondering if there was something more "out of the box"
<mvo> zyga: ping me once you have build/downloaded a snapd with the right revision to reproduce the refresh hang
<zyga> mvo: sure
<kyrofa> didrocks, not right now, but it's on the roadmap
<zyga> mvo: I cannot find core at revision 1968, I no longer have access to core
<didrocks> kyrofa: ok, so you would advise relying on `arch` right now?
<kyrofa> didrocks, if that covers your use-case, go for it. It obviously won't solve everything
<kyrofa> We're trying to make a generic way to specify most things using a grammar similar to the stage-packages
<niemeyer> Lunch!
<mvo> zyga: you are still listed as a collaborator
<zyga> hmm
<zyga> sudo snap refresh --revision=1968 core
<zyga> this fails with: error: cannot refresh "core": snap not found
<mvo> zyga: oh, that will not work
<mvo> zyga: or maybe it should
<mvo> zyga: interessting
<zyga> I think it should work
<ogra_> it should
<zyga> Chipaca: ^^
<ogra_> i use that all the time
<zyga> anyway, I need that coffee
<zyga> brb
<ogra_> are you sure 1968 is the one you want ?
<zyga> maybe, mvo is that the one you are on?
<ogra_> (i.e. is it your arch)
<mvo> zyga: I'm on 1968
<mvo> zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=snapd&field.status_filter=&field.series_filter= might also be a place to look for the revno
<pedronis> --revision works only if you can push to the snap
<ogra_> oh
<ogra_> indeed ... and i can
<ogra_> (for core)
<zyga> and supposedly so can I
<ogra_> i dont think so
 * ogra_ checks
<ogra_> (if the dashboard ever loads ... tap ... tap ... tap)
<Chipaca> zyga: log in
<Chipaca> zyga: assuming you've got dev access to core, you can pull arbitrary revisions with --revision; otherwise no
<zyga> ah
<ogra_> yeah, zyga should be able to ...
<zyga> that was it
<zyga> sorryt
<zyga> I used sudo
<zyga> it works
<azubieta> Hello, I'm traing to build an snap of Konsole. I followed this tutorial https://apachelog.wordpress.com/2016/12/02/snapping-kde-applications/ but I'm getting the following error ""
<azubieta> You need to connect this snap to the kde-frameworks-5 snap.
<azubieta> You can do this with those commands:
<azubieta> snap install kde-frameworks-5
<azubieta> snap connect :kde-frameworks-5-plug kde-frameworks-5:kde-frameworks-5-slot
<azubieta> I already did what the instructions says without success
 * zyga looks at a 48GB 24CPU box
<zyga> but first, coffee
 * genii sips
<zyga> re
<zyga> ok, back with my coffee
<kyrofa> Chipaca, if a channel closes, is snapd not currently falling back today?
<zyga> mvo: I'm on the smae revision now
<Chipaca> kyrofa: yes, why?
<Chipaca> kyrofa: I mean yes it is falling back
<kyrofa> Chipaca, in a released version?
<Chipaca> kyrofa: I don't think it's ever not fallen back
<pedronis> also that behavior is fully on the store side
<Chipaca> kyrofa: you're making me nervous :-)
<kyrofa> Chipaca, sergio is claiming it doesn't.... made ME nervous
<mvo> zyga: does snap refresh --edge work for you?
<pedronis> fgimenez: https://travis-ci.org/snapcore/snapd/builds/237053889  seems to be failing with timeouts in lots of prepares
<Chipaca> kyrofa: psh. What does sergiusens know
<Chipaca> sergiusens: no seriously tell us
<zyga> mvo: trying
<fgimenez> pedronis: thx looking
<zyga> mvo: yes
<zyga> mvo: I'm now on 2053
<zyga> mvo: which version of the package are you on?
<zyga> mvo: I suspect it worked for me because I installed locally-built package earlier
<mvo> zyga: aha, you were on a non-rexec version?
<zyga> mvo: possibly
<mvo> zyga: snap version will know
<mvo> zyga: but not anymore :)
<zyga> mvo: anyway, I should reinstall snapd from the archive
<zyga> ok
<zyga> I'm on 2.25
<fgimenez> pedronis: on of the errors is super weird https://travis-ci.org/snapcore/snapd/builds/237053889#L1220 it previously checked for SNAP_REEXEC != 0 here https://travis-ci.org/snapcore/snapd/builds/237053889#L1187
<fgimenez> one of the errors
<zyga> mvo: now to switch back core
<zyga> and try
<pedronis> fgimenez: also one of the restore timed out, IÂ suppose one a restore fails then we can be in really weird stats
<pedronis> s/one a /once a/
<zyga> mvo: reproduced!
<zyga> mvo: thank you
<zyga> mvo: so, quick suspicion, there was one day when snapd from core would run snap-update-ns from distro
<fgimenez> pedronis: indeed, if they don't come alone the restore errors might be caused by something that failed before
<zyga> mvo: I fixed that on monday after landing update-ns on friday
<mvo> zyga: it might be that, yeah.
<zyga> mvo: if this is that version then there's no bug to look for (hopefully)
<mvo> zyga: this would explain the narrow set of versions we are seeing this
<mvo> zyga: plus it never left edge
<zyga> mvo: yes
<zyga> mvo: so the snap-update-ns in core is correct (does real stuff)
<zyga> mvo: but we are running the one I have in /usr/lib/snapd
<pedronis> from 2.25
<zyga> yes
<zyga> essentially
<mvo> zyga: now the question is what we do about all N people who are affected. we could simply ignore the problem
<zyga> mvo: aha, good question
<zyga> mvo: eventual exnial release will fix it
<mvo> zyga: good point
<zyga> mvo: we could do a point release
<zyga> mvo: and SRU it quickly
<zyga> mvo: to have update-ns just return 0
<zyga> while saying not implemented
<zyga> mvo: I can prepare a debdiff if you think this is worth doing
<ogra_> if it never left edge anyway ... why bother
<mvo> zyga: probably fine to ignore for now as long as the number is very small
<zyga> mvo: use repair assertion :D
<mvo> zyga: soon
 * zyga would love if we could try that :-)
<zyga> but still chicken-and-egg
<pedronis> we should tell the pople with it what to do though on the forum
<pedronis> *people
<zyga> pedronis: good point
<zyga> pedronis: I think refreshing to stable
<zyga> pedronis: and to edge should fix it
 * zyga tries
<zyga> mvo: actually, maybe universal recovery stragegy for broken edge?
<pedronis> no, because with patches or patch like stuff it might break as well
<fgimenez> pedronis: interfaces-cups-control got stuck too on apt-get install (18mb) https://travis-ci.org/snapcore/snapd/builds/237053889#L6883
<zyga> pedronis: in theory yes but we stopped doing that, right?
<pedronis> well we stopped using patches
<pedronis> but we do some stuff like that in ensure
<pedronis> so not completely broken
<pedronis> but you can get interesting effects
<zyga> pedronis: indeed though those are (for now) still safe
<pedronis> so really edge to beta or edge to candidate
<pedronis> might be better
<pedronis> than jumping all the way to stable
<zyga> mvo: anyway, I think for this case refresh to core does not work
<pedronis> if possible
<zyga> mvo: so we need to help people but we need something else
<zyga> mvo: I'd suggest replacing update-ns in the package with bin/true
<zyga> mvo: from there on it would work, if you want I can write a blog post
<zyga> mvo: I can even make a shell script that "recovers" the system
<pedronis> fgimenez: IÂ wonder, would increasing the timeout help, or do we get into stuck states somehow for which even waiting forever wouldn't help, also wonder whether we should do the reverse, see what are the usual times, and reduce the timeout, so we fail fast
<zyga> mvo: let me know if you want me to do that
<fgimenez> pedronis: yes, i don't think increasing the timeout further would help too much
<fgimenez> pedronis: i was wondering if keeping disabled ip6 here would help https://github.com/snapcore/snapd/blob/master/spread.yaml#L258, most of these timeouts happen during downloads for installations
<kyrofa> Chipaca, https://forum.snapcraft.io/t/channel-fallback-doesnt-change-tracked-channel/828
<Chipaca> kyrofa: but fallback != changing tracked
<kyrofa> It continues tracking the closed channel?
<Chipaca> kyrofa: the channel tracked does not change
<Chipaca> kyrofa: correct
<Chipaca> kyrofa: if you're tracking beta, and beta closes for a bit, you don't want to be dumped onto stable indefinitely
<kyrofa> Chipaca, huh... seems unintuitive for branches though
<kyrofa> Chipaca, I mean, that revision that I just refreshed to did _not_ come from stable/junk. I never released it there
<Chipaca> kyrofa: maybe snap info could say something like "tracking: foo/stable/hotfix (from foo/stable)? Although I don't know how we'd get that info
<Chipaca> s/\)\?/)"?/
<kyrofa> Yeah... it's just not stating the truth there :P
<Chipaca> kyrofa: it is stating the truth
<Chipaca> kyrofa: you're misunderstanding the truth that it's stating
<ogra_> alternative facts!
<ogra_> belive in them!
<Chipaca> kyrofa: if you were to reopen and push a snap into foo/stable/hotfix, and a different one into foo/stable, it would get the one from foo/stable/hotfix and not the other one
<kyrofa> Hahaha
<niemeyer> sergiusens: What's WW21?
<Chipaca> world war 21: madagascar is back for more
<nacc> What Would 2 1
<niemeyer> Chipaca: That's what I associated with as well :)
<jdstrand> mvo: approved https://github.com/snapcore/snapd/pull/3397
<mup> PR snapd#3397: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3397>
<Son_Goku> niemeyer, zyga, morphis_: can we adjust the man page generation code to mark it as section 8?
<jdstrand> mvo: if you put the digest one in PR form, I can comment on the approach (I don't seem to be able to comment on the link you gave)
<Son_Goku> I got a bug report about a file conflict: https://bugzilla.redhat.com/show_bug.cgi?id=1456847
<niemeyer> Son_Goku: I recall we discussed this before.. what was the agreement last time?
<jdstrand> mvo: actually, I see the forum topic now
<Son_Goku> niemeyer: you said it makes sense, but the code that generates it doesn't actually support selecting sections, and "it doesn't matter"
<Son_Goku> fwiw, for the longest time, the man page in Ubuntu was written out as snap.8 until I pointed out the mismatch
<niemeyer> Son_Goku: What I recall from the discussion is that section 1 was actually fine.. is it not?
<Son_Goku> it's not
<niemeyer> Why not?
<Son_Goku> there's already a snap(1)
<Son_Goku> from https://apps.fedoraproject.org/packages/snap
<Son_Goku> a backup utility
<Son_Goku> switching computers, will be Pharaoh_Atem
<zyga> morphis_: ^^ this is the bug I mentioned earlier today
<morphis_> zyga: interesting
<morphis_> niemeyer: ping, you have some time discussing `snapd --user`?
<niemeyer> Pharaoh_Atem: I see..
<niemeyer> Pharaoh_Atem: Should be very easy to hack the output of snap help --man so it reports .8 without us having to fix go-flags everywhere
<niemeyer> Pharaoh_Atem: To be clear, tough, that's a hack.. the .1 section is in fact fine for the tool
<niemeyer> Even systemctl is in there
<niemeyer> morphis_: Yeah
<morphis_> Pharaoh_Atem: just tested the latest snapd package in updates-testing, only seeing an empty /var/lib/snapd/ left after snapd is removed
<morphis_> Pharaoh_Atem: all other things are removed this time
<morphis_> niemeyer: sent you a PR with a HO link
<morphis_> s/PR/PM/
<Pharaoh_Atem> niemeyer: I guess I'll do that
<sergiusens_> niemeyer: work week 21 of the calendar year
<__chip__> Pharaoh_Atem: sorry, i missed the start of this; you're wanting it to be snap(8) and not snap(1)
<__chip__> ?
<Pharaoh_Atem> __chip__: yeah
<Pharaoh_Atem> but I think I might have just found another solution (for the moment)
<__chip__> Pharaoh_Atem: what's the driver of that change?
<Pharaoh_Atem> file conflict: https://bugzilla.redhat.com/show_bug.cgi?id=1456847
<Pharaoh_Atem> but that said, this might actually be solvable in a different way
<__chip__> Pharaoh_Atem: if you move the manpage out of the way, won't the binary be the thing reported as conflicting?
<Pharaoh_Atem> nope
<__chip__> how come?
<Pharaoh_Atem> it doesn't provide /usr/bin/snap
<Pharaoh_Atem> it provides /usr/bin/snaptool
<Pharaoh_Atem> apparently, it *used* to be snap, and now it's not
<__chip__> ah
<Pharaoh_Atem> the man page is symlinked to the old name as well
<Pharaoh_Atem> so I'm going to see if I can just get them to drop the old symlink
<Pharaoh_Atem> because otherwise, I guess I'm sedding to section 8
<__chip__> I can understand why they'd do that, but it would be very confusing for a user seeing 'snap' and 'snaptool' binaries, and the manpages not lining up
<Pharaoh_Atem> Yep
<__chip__> I mean, I'd probably notice (after the initial WTF) but it'd be surprising (and so derailing) to people
<__chip__> anyway, preaching to the choir, probably
 * __chip__ goes back to hacking
<niemeyer> sergiusens_: Can we agree on a summary that works for both snapd and snapcraft, and preferably one that doesn't remind us of world wars? :)
<ogra_> niemeyer, but then we'll miss the beautiful and funny comments from __chip__ ;)
<sergiusens_> niemeyer: sure, I don't mind changing the subject line/title
<zyga> mvo: https://github.com/snapcore/snapd/pull/3410
<mup> PR snapd#3410: cmd/hotfix: add hotfix tool <Created by zyga> <https://github.com/snapcore/snapd/pull/3410>
<mup> PR snapd#3410 opened: cmd/hotfix: add hotfix tool <Created by zyga> <https://github.com/snapcore/snapd/pull/3410>
<zyga> mvo: in case we want to help anyone particular that may be affected
<niemeyer> sergiusens_: "Week 21/2017 in snapcraft"?
 * zyga breaks
 * ogra_ looks for the glue to fix zyga 
<mup> PR snapd#3411 opened: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3411>
<mup> PR snapd#3412 opened: tests: fix for snapd-reexec test cheking for restart info on debug log <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3412>
<luk3yx> How do I specify a folder in a GitHub repo for build.snapcraft.io?
<kyrofa> luk3yx, cprov might be able to answer that
<luk3yx> cprov, can you?
<luk3yx> kyrofa, thanks.
<cprov> sorry, otp. I don't understand the folder question. do you mean a folder within the repo with snapcraft.yaml|.snapcraft.yaml ?
<luk3yx> A folder in the repo.
<luk3yx> *within
<cprov> that is not supported, IFAICT
<cprov> 1 repo per snap, basically
<thomi> This has also been suggested here: https://forum.snapcraft.io/t/one-folder-per-snap-in-build-snapcraft-io/792 but it's not clear to me how it'd work
<luk3yx> I keep different versions of the same snap in different directories.
<luk3yx> Does it do 32-bit builds?
<luk3yx> ...or do I still need to manually do i686 builds?
<nacc> luk3yx: wouldn't you just have them in different branches?
<luk3yx> I've simplified it now, commits can roll back if required.
<luk3yx> One question.
<luk3yx> It can't build my snap, as it's designed for the latest release (17.04).
<luk3yx> Can it build the non-LTS release?
<nacc> luk3yx: meaning you are using some packages from 17.04?
<luk3yx> Yes.
<luk3yx> ...that don't exist on 16.04.
<nacc> luk3yx: i've only used the LP builders, but there, you can tell it what release to build under
<luk3yx> Okay.
<nacc> luk3yx: i'm looking on b.s.io
<luk3yx> Okay.
<luk3yx> I've send feedback.
<luk3yx> *sent
<luk3yx> Hopefully they'll fix the issue.
<cachio> niemeyer, do you know why the tests usually don't uninstall the snaps used?
<daker> anyone to help with a store issue ? i can't install a snap that is published in the edge channel
<luk3yx> Did you use --edge?
<luk3yx> daker, did you?
<daker> luk3yx: yes sudo snap install --edge $snapname --revision=1
<luk3yx> What's the error?
<daker> it's says : snap not found
<nacc> daker: what's the snap's name?
<daker> nginx-rtmp
<nacc> daker: i'm not sure such a snap exists
<nacc> daker: where did you find a reference to it?
<daker> nacc: i used snapcraft build site to publish, i can see it in the store (dashboard.snapcraft.io) https://i.imgur.com/3vCeFJr.png
<nacc> daker: possiblyou also need to tell it y ou want devmod
<nacc> daker: by default it won't install such a thing, iirc
<daker> nacc: yes you are right, i need to add --devmode, it works now
<nacc> daker: great! :)
<daker> nacc: thanks
#snappy 2017-05-31
<mwhudson> yay spammers found the forum
<Pharaoh_Atem> murr
<mup> PR snapd#3413 opened: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3413>
<luk3yx> I'm having an issue with building a snap.
<luk3yx> snapcraft doesn't copy the '.desktop' files across with the 'dump' plugin like it used to.
<zyga> morphis_: hey
<zyga> morphis_: just running tumbleweed here, I noticed that none of the desktop launchers work
<morphis_> zyga: which desktop launchers do you mean?
<morphis_> the ones you get in the gnome shell dash?
<zyga> morphis_: any made by snaps
<zyga> morphis_: yes
<morphis_> hm, I tried this with krita and I could start
<zyga> morphis_: we just set PATH
<zyga> morphis_: in which DE and suse release?
<zyga> anyway, running gnome tumbleweed, it doesn't work
<zyga> looking at why now
<morphis_> I hope this didn't broke recently, let me check
<zyga> I don't see the extra variable that points to /var/lib/snapd/desktop
<morphis_> ah!
<morphis_> could have been that I fixed that locally but never pushed the fix
<morphis_> actually this works pretty well on Fedora
<morphis_> zyga: I wonder if the profile.d handling is different or has changed
<zyga> morphis_: what do you have in /etc/profile.d?
<zyga> I have snapd.sh that has one line (except comments): PATH=$PATH:/snap/bin
<morphis_> powering up my suse VM, on Fedora I have what should be there
<zyga> the 65snappy Xsession thing is not around
<luk3yx> Why doesn't snapcraft put .desktop files in correctly?
<zyga> luk3yx: no idea, sorry
<luk3yx> Okay.
<morphis_> zyga: the interesting thing is that the same file on Fedora has the proper XDG_DATA_DIRS vars set
<zyga> morphis_: separate file
<morphis_> nope
<zyga> morphis_: I think we don't have one thing across the trees
<morphis_> /etc/profile.d/snapd.sh sets XDG_DATA_DIRS on Fedora
<zyga> morphis_: look at etc/X11 in the source tree
<zyga> right
<zyga> because that's not the same file
<morphis_> on Suse it doesn't
<zyga> in the source tree we have two files
<zyga> and in Fedora we use entirely different one (because /snap I suspect)
<morphis_> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n421
<zyga> morphis_: exactly
<zyga> morphis_: and on ubuntu/debian/suse we take etc from the source package
<zyga> see?
<morphis_> that is nasty, we should't differentiate what is in these files across distros
<zyga> I think it is also somewhat incorrect, that's why we did it this way
<zyga> someone reported a bug on XDG_DATA_DIRS, let me try to find it
<morphis_>  /etc/x11/XSession.d isn't support on Suse as it seems
<zyga> I can only find https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1554563
<mup> Bug #1554563: Please support /var/lib/snappy/desktop as an additional desktop directory <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1554563>
<zyga> yeah, I see
<morphis_> ah it's /etc/X11/xinit/xinitrc.d/ instead
<zyga> heh
<zyga> shall I prepare a patch?
<morphis_> I am on it already
<zyga> this is what I made
<zyga> https://paste.opensuse.org/30238446
<abeato> zyga, hey, mind taking a look when possible at https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<zyga> abeato: yes, certainly
<zyga> well
<zyga> not mind :)
<morphis_> zyga: yeah, same here
<abeato> :)
<zyga> abeato: can you please ensure that every if / else uses braces fully
<abeato> zyga, also one-liners?
<zyga> yes
<abeato> ok
<zyga> thank you, sorry for the nitpick but this is the coding style we're using everywhere else
<abeato> zyga, done
<morphis_> zyga: btw. there will be a blog post later this week telling about working lxd/docker on Suse/Fedora
<abeato> zyga, sure, I had not noticed
<zyga> abeato: thank you, looking
<zyga> morphis_: nice, thank you :)
<zyga> abeato: looks nice, I'll comment in a sec
<abeato> zyga, great
<morphis_> zyga: btw. what do you think about doing an Ubuntu Testing day for snaps on Fedora/Suse?
<zyga> morphis_: I think this is a good idea
<zyga> morphis_: we could do a converged one for a few distributions
<morphis_> then let me organize that
<morphis_> yes!
<zyga> morphis_: but only those under CI today
<zyga> we can split responsibilities
<zyga> I can show suse (natively) and fedora (natively)
<morphis_> what means natively?
<morphis_> in a non-vm environment?
<zyga> running on metal
<zyga> yes
<zyga> I shun VMs recently
<zyga> because we're mot using them daily for real stuff
<zyga> just for fire&forget
<zyga> (e.g. the desktop issue)
<zyga> mvo: hey
<zyga> mvo: did you see  PR 3410
<mup> PR snapcraft#1320 closed: store: send X-Ubuntu-Series, not X-Ubuntu-Release <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1320>
<mup> PR snapcraft#1336 closed: HACKING: make running from virtualenv more obvious <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1336>
<mvo> zyga: yeah, I noticed it, need to look in detail, was a bit distracted with the other things going on
<mup> PR snapcraft#1300 closed: tools: add a script to install autopkgtest dependencies <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1300>
<zyga> morphis_: hmm,not sure what happened
<morphis_> yeah, not sure too
<zyga> oh man
<zyga> morphis_: can you hear me?
<zyga> morphis_: seems like google hangouts armageddon
 * zyga does code reviews 
<zyga> mvo: please pull me out of this if you need my help with release blockers
<NicolinoCuralli> hi all: i need to delete a snap  in  brand store : who can help me?
<kyrofa> Hey zyga, did you solve the snap-confine in lxc issue?
<zyga> kyrofa: nope, I didn't have time to explore that yet
<kyrofa> zyga, huh... you may not need to. I just updated a few different containers to 2.25 now (snap-confine also updated) and things seem to be working
<zyga> oh, that's good news :)
<morphis_> zyga: https://build.opensuse.org/request/show/500035
<zyga> sorry for being passive about that, I think it will only be fixed once I actively try LXD and we have CI
<zyga> morphis_: approved, thank you
<kyrofa> zyga, yeah we really need lxd in CI
<morphis_> zyga: had to use /etc/profile.d in the end but it works now
<zyga> morphis_: what happend when you tried xinitrd.d?
<zyga> morphis_: just wasn't picked up?
<zyga> or didn't export the environment back to other processes?
<morphis_> zyga: yes
<morphis_> it wasn't loaded for the DE nor for any shell
<morphis_> so not picked up at all
<NicolinoCuralli> hi all: i have some difficulties with review process in the brand store : can someone help me ?  I don't find on the store the place where paste the Snap declarations
<abeato> ogra_, hey, I had to do a small correction in https://github.com/snapcore/core-build/pull/13
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<abeato> (see last commit)
<ogra_> abeato, approved ... how could i miss that!
<abeato> :)
<abeato> ogra_, do we need some other approval or is it ready to be merged?
<ogra_> abeato, you need two people to approve
<NicolinoCuralli> hi guys : someone can help me to find the person tha can help me to solve my problem?
<abeato> ogra_, ok, who do I need to annoy? ;)
<ogra_> abeato, dunno ... someone from the snapd core team
<abeato> ogra_, maybe mvo? https://github.com/snapcore/core-build/pull/13 ? :)
<mup> PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<mvo> abeato: sure, I have a look
<abeato> mvo, thanks!
<mvo> zyga: re release> after a bit of thinking I will just revert the syntax change and the new symbols and go ahead with only that, then we are not under pressure for the profile-digest changes
<zyga> OK
<mvo> zyga: I also played a bit more with seccomp->bpf and ran into a strange apparmor/seccomp interation. when I load the bpf directly and run e.g. hello I get an EPERM when execve(snap-exec). however when I unload the apparmor profile of snpa-confine this is gone, syslog has something that looks like an oops from paparmor
<zyga> log?
<zyga> mvo: did you change the moment when you load the profile in snap-confine?
<zyga> note that seccomp applies instantly
<mvo> zyga: sure, here is the log http://paste.ubuntu.com/24724666/
<zyga> mvo: which kernel was this on?
<mvo> zyga: and the full branch (slightly long and unfinished) https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1 - the key is sc_apply_seccomp_bpf(security_tag);
<mvo> zyga: 4.4.0-78
<zyga> hmm
<mvo> zyga: do you think I should try a different one?
<zyga> no, the kernel looks fine
<mvo> zyga: the profile is loaded at the same point as the old sc_load_seccomp_context(seccomp_ctx);
<mvo> zyga: whats puzzling is that its apparmor, the execve from seccomp would get killed (SIGSYS) but I get a EPERM
<mvo> zyga: I guess I wait for jamie to see if he has some ideas
<zyga> mvo: just curious, the sc_prepare_seccomp_context no longer does anything, right?
<zyga> mvo: note that the code is structured in a specific way
<mvo> zyga: I still made it prepare everything so that I can dump the content and compare the diff between the new and the old code
<zyga> mvo: so when you load the profile you can still, afair, do more things, when we apply it it is too late to some things
<mvo> zyga: oh, interessting
<zyga> this is why those were split
<zyga> not sure if this would explain the WARN you saw
<zyga> jjohansen: ^^ you want to look at http://paste.ubuntu.com/24724666/
<mvo> zyga: interessting idea, I can play a bit and see if moving things around makes a difference
<zyga> mvo: honestly, I'd love to hack on this
<mvo> zyga: I will first try a newer kernel just to see if it makes a difference
<zyga> mvo: but if you want to do it then feel free :)
<mvo> zyga: go ahead
<zyga> mvo: I need to review PRs and apply feedback first
<mvo> zyga: the branch is https://github.com/snapcore/snapd/compare/master...mvo5:seccomp-bpf?expand=1
<zyga> mvo: but I can do some more hacking in the evening
<zyga> did you see the hotfix PR by any chance?
<mvo> zyga: yeah, its a fun and fascinating project. I need to also go and do the boring stuff now (cherry pick, release)
<mvo> zyga: yeah, its a good idea - did you already describe in the forum how the poor souls on r1968 can get out of it?
<zyga> mvo: no not yet, I wanted to get your feedback first
<zyga> mvo: one thing I was thinking of is make periodic releases of the hotfix tool (only for developers using edge)
<zyga> mvo: and to patch it a little more to be double-click-foolproof, just run it and it applies all hotfixes
<Chipaca> pedronis`: snapd#3400 is ready for your perusal if you have a bit
<mup> PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<mup> PR snapd#3414 opened: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414>
<Chipaca> NicolinoCuralli: what is your problem?
<NicolinoCuralli> chicapa: I need to upload the snap declaration for a snap under review on my brand store
<zyga> morphis_: two more issues on suse
<zyga> Failed to try-restart snapd.autoimport.service: Unit snapd.autoimport.service not found.
<zyga> Failed to try-restart snapd.system-shutdown.service: Unit snapd.system-shutdown.service not found.
<zyga> and earlier
<zyga> Failed to preset unit: File snapd.autoimport.service: No such file or directory
<zyga> Failed to preset unit: File snapd.system-shutdown.service: No such file or directory
<morphis_> zyga: we don't install these service units anymore
<morphis_> so what is starting it?
<zyga> yes but something presets them
<zyga> they are in systemd_services_list
<morphis_> ah I see
<zyga> in the spec file
<zyga> we should drop the two
<zyga> I can do that if you want, I already have it open
<zyga> building locally to test
<morphis_> zyga: please!
<zyga> we need snap install pastebinit :)
<zyga> there's no pastebinit on tumbleweed
<zyga> oh, but there is susepaste and susepaste-screenshot
<zyga> I'm especially intrerested in the screenshot paste :)
<zyga>    http://paste.opensuse.org/71458123
<zyga> morphis_: ^ looks ok?
<morphis_> yes
<pedronis> Chipaca: when I have processed the fact that all the spread runs I start fail for some random reason
<Chipaca> pedronis: spread's just envious of your awesomeness
 * zyga is drunk today, sorry for silly comment on 3400
 * Chipaca hugs zyga 
<mvo> zyga: btw, do you know more about "cannot create lock directory /run/snapd/lock: Permission denied" yet? we see this a lot in the error tracker
<Chipaca> zyga: i'm assuming you're not _actually_ drunk
<zyga> no, not actually
<zyga> mvo: no, still no idea what is going on there
<zyga> mvo: how can I get error tracker data?
<mvo> zyga: errors.ubuntu.com has a lot of it, .e.g https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069
<mvo> zyga: there might be a form to fill in to get access (if you have not done so already) to the details
 * zyga looks at http://susepaste.org/10525636 and sighs :/
<zyga> looking
<mvo> zyga: this one has 5k occurances last week
<zyga> mvo: how did you find this, I mean, how to "get started"?
<mvo> zyga: start from https://errors.ubuntu.com/ - it takes a bit to load the data, then in the top-5 you will see some "snap install" related ones
<zyga> aha, let me try that
<mvo> zyga: the top one is the one I just linked to
<zyga> classic confinement, hmm
<zyga> still, should not impact anything
<mup> PR snapd#3397 closed: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3397>
<zyga> mvo: question about this report, looking at https://errors.ubuntu.com/oops/2af7141c-45e8-11e7-9188-fa163e839e11 I see snapd version 2.25, is that the real version of the snapd being executed or the one installed via classic package?
<mvo> zyga: that is the one running, the host and core versions are available via the build-id
<joc> morphis_: would appreciate if you could look at getting that udisksctl auto alias setup soonish, we have test runs that would like it available
<mup> PR snapd#3415 opened: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <https://github.com/snapcore/snapd/pull/3415>
<pedronis> Chipaca: added some comments
 * Chipaca reads
<zyga> morphis_: so, the overlordSuite.TestEnsureLoopPrune test never passes for me
<zyga> morphis_: hmm, wonder if this related to multi-core build host vs single-core VM
<zyga> morphis_: I'll commit and let OBS do the build
<mvo> a review for #3415 would be great. it will unblock 2.26/2.27
<zyga> approved
<mvo> ta
 * mvo just needs tests now
 * mvo just needs to wait for tests now
<Chipaca> pedronis: "the store offered snap revision" sounds like it returns a revno. "the store offered snap revision snap info" sounds like chickenspeak. "the store offered snap"?
<Chipaca> currently best phrasing i have is â// LookupRefresh returns a snap's store-offered revision information given its refresh candidate.â
<pedronis> mvo: test are super flaky, IÂ had zero happy runs since yesterday, maybe is just me though
<mvo> pedronis: autsch, that does not sound encouraging
<mvo> pedronis: thank you, I will know in some minutes
<mup> PR snapd#3373 closed: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3373>
<pedronis> IÂ had one now after tentative N+
<pedronis> Chipaca: sounds ok
<pedronis> (all things considered)
<pedronis> mvo: could you push master into snapd#3385 again,  that's other one I'm trying to see pass, maybe pushing master helps
<mup> PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
<morphis_> zyga: in OBS?
<morphis_> zyga: didn't checked that yet but I have just a single core on my vm too, works well here
<pedronis> Chipaca: thx, did you see my question about the error?  also I pmed you
<Chipaca> i didn't see your question about the error
<Chipaca> pedronis: where was that question?
<morphis_> Pharaoh_Atem: ping
<pedronis> Chipaca: it was a comment attached to some other comments to some code that was changed
<mvo> pedronis: sure, pushed 3385
<Chipaca> pedronis: about the snap name and real name not aligning?
<Chipaca> local vs real i mean
<pedronis> yes
<Chipaca> pedronis: i replied to that, i think?
<Chipaca> pedronis: basically, yes it's used and shown to the user
<Chipaca> pedronis: (but that's not something this branch introduces?)
<pedronis> don't we have the local name around when we show it though?
<pedronis> Chipaca: yes, but moving around where it error is created changes which name we use
<pedronis> that's why I'm bothering you :)
<pedronis> you need to look at the diff IÂ suppose
<pedronis> I mean master vs your branch
<pedronis> mvo: thanks, let's how it goes
 * pedronis -> lunch
<Chipaca> so yes i move it from snapstate, using curInfo.Name() (which for from-the-store snaps is the RealName, ie the store name) to store using latest[0].Name, so the only case where they'd differ is if a snapid gets renamed
<pstolowski> zyga, hey. it seems that we always use /usr/bin/snapctl from the core snap no matter what. am I right / is it expected?
<zyga> re
<zyga> morphis_: yes, I think it just fails on multi-core systems
<zyga> pstolowski: snapctl is always used (except classic) after we pivot_root so yes
<morphis_> zyga: ah you think it fails on multi-core thought somehow you mean the other way round
<pstolowski> zyga, thanks.. ok, this explains my issues with renaming of SNAP_CONTEXT
<zyga> morphis_: and it failed in OBS now
<zyga> https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64
<zyga> pstolowski: ha, interesting
<zyga> pstolowski: just bind-mount it into core snap
<zyga> pstolowski: although we repack the core snap so not sure why you are seeing this
<morphis_> zyga: wait, you pushed to the system repository without testing?
<zyga> morphis_: I tested it but it took many builds to pass
<zyga> morphis_: since this is a trivial patch on top of existing working build I didn't expect it could be any worse
<morphis_> actually we should always go via an review request, that way we can verify it builds on all archs + systems
<zyga> morphis_: well, it is randomly failing because that test is racy
<Chipaca> pedronis: WRT the error, can I address it in a followup branch? doing it properly touches cmd/snap more than i'd like to in this one
<zyga> morphis_: and the failure has nothing to do with the change at hand
<zyga> morphis_: maybe we just get better build VMs now :/
<zyga> morphis_: I re-triggered the build
<morphis_> I see, was just looking at the log file
<zyga> morphis_: it's the same failure I mentioned before and the one we fixed in master some time ago
<zyga> morphis_: but apparently the fix was wrong as it also fails in travis very often
<pstolowski> zyga, hmm indeed I see this is done in prepare.sh. ok  let me verify if this is working
<zyga> pstolowski: maybe we just don't copy snapctl
<pstolowski> zyga, we do
<zyga> so there must be something else at play
<zyga> morphis_: it worked on retry
<pstolowski> zyga, ok. confirmed. whatever we think we do in prepare.sh is not working for snapctl when I run spread test with qemu ;)
<pstolowski> qemu:ubuntu-16.04-64 /root# md5sum /usr/bin/snapctl /snap/core/current/usr/bin/snapctl
<pstolowski> 67d600f14953d72a8440e0d90a93abc4  /usr/bin/snapctl
<pstolowski> 5ac1e109e0dd434d5141b9ad52b20f3f  /snap/core/current/usr/bin/snapctl
<zyga> pstolowski: let me look
<morphis_> zyga: good
<zyga> pstolowski: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L46
<pedronis> Chipaca: it's ok
<zyga> pstolowski: and also https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L74
<zyga> pstolowski: this gets called from https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L94
<zyga> pstolowski: hmm hmm hmm, no idea
<zyga> pstolowski: how are you running your test exactly?
<pstolowski> zyga, uh oh the tests I'm using do not call prepare.sh
<zyga> pstolowski: oh? why? where are your tests?
<zyga> pstolowski: this is typically done at suite level
<pstolowski> zyga, well, existing one - e.g. main/snap-set
<pstolowski> zyga, at least no explicit call to prepare.sh
<zyga> pstolowski:  https://github.com/snapcore/snapd/
<zyga> pstolowski: they do, or your spread is old/weird/broken
<morphis_> zyga: but what change we submit we should always go through a review request for suse
<morphis_> otherwise we may break existing installations
<zyga> morphis_: sure, I didn't do it because I didn't have a branch and I showed you the diff to ack
<morphis_> yeah
<pstolowski> zyga, ah, it's called from spread.yaml, that's ok then. i got confused by one of the other tests (extra-snap-assertions) which calls prepare.sh directly
<zyga> brb
<pstolowski> zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin
<zyga> morphis_: so....
<zyga> morphis_: on re-logout neither snapd.sh nor snapd-xdg.sh do stuff
<zyga> morphis_: /snap/bin is not in path
<morphis_> you have reboot
<zyga> ah, the X session holds this too?
<zyga> ok
 * zyga reboots then :)
<pstolowski> zyga, anyway... I run a single test like this: spread -debug qemu:ubuntu-16.04-64:tests/main/snap-set and clearly the snapctl in the core is different from the one from /usr/bin
<zyga> morphis_: indeed, now it works perfectly!
<morphis_> not sure how suse configures this but XDG_DATA_DIRS was filled with /var/lib/snapd/desktop and PATH with /snap/bin
<zyga> morphis_: the snapd-xdg.sh file is +x while all the other files there are not
<morphis_> hm
<morphis_> should be 644, I agree
<zyga> morphis_: but it doesn't hurt
<zyga> morphis_: I think snapd on suse is really good now
<morphis_> yeah, will fix that later when I can power up my suse vm again
<morphis_> zyga: one thing is missing
<zyga> yeah?
<zyga> xdg-open
<morphis_> cleanup of /var/lib/snapd on removal
<zyga> ah, interesting
<zyga> yep, we should use the management script and just make it better
<morphis_> naah, xdg-open is missing everywhere but Ubuntu :-)
<zyga> and use it on all the distributions
<morphis_> zyga: yes
 * zyga installs docker 
<morphis_> was ping'ing Pharaoh_Atem this morning as he wanted to generalize it but if he doesn't has time I can do that
<zyga> morphis_: sounds good
<Son_Goku> morphis_: moo?
<morphis_> Son_Goku: hey!
<morphis_> Son_Goku: just talked with zyga about snap-mgmt.sh, do you want to generalize it or should I?
<Son_Goku> I want it perfectly working first :)
<morphis_> Son_Goku: one thing missing before we reach that goal :-)
<Son_Goku> I'm still fine-tuning the script
<Son_Goku> I'm nearly there, and then we can work generalizing
<Son_Goku> err, work on generalizing it
<morphis_> Son_Goku: good
<Son_Goku> I expect that we can start generalizing next week
<Son_Goku> as I'll take care of the last wibbles in the script and packaging this weekend
<Son_Goku> at the latest :D
<morphis_> nice!
<zyga> morphis_: docker works but adduser/addgroup vs useradd groupadd is an issue, we should fix this eventually
<morphis_> zyga: who calls these?
<zyga> morphis_: the user is instructed to
<morphis_> for the docker snap?
<morphis_> you can but you also can simply run the docker command via sudo
<Son_Goku> the modern debian addfoo commands have never been ported outside of the distribution
<Son_Goku> interestingly, I think debian is the upstream for shadow-utils
<zyga> anyway, it will go away once snapd does user management
<Son_Goku> you scare me with phrases like that
<Son_Goku> "user management"?
<Son_Goku> snapd will replace shadow-utils too?
<zyga> no, it will just create service accounts like the one for docker
<zyga> better than asking users to follow instructions :)
<Son_Goku> oh, so there'll be a snappy user for this
<zyga> Son_Goku: yes, most likely a specific one
<zyga> there's a writeup about this ...
<Son_Goku> we'll probably want the uid + gid reserved in Fedora
<zyga> https://forum.snapcraft.io/t/snappy-and-users-and-groups/331
<Son_Goku> that way it's sane across the board
<zyga> but brace yourself
<zyga> that's a long read
<Son_Goku> holy crap
<Son_Goku> I'll need to bookmark this
<Son_Goku> jdstrand, damn, you wrote a lot...
<Saviq> kalikiana, https://code.launchpad.net/~saviq/snapcraft/+git/snapcraft/+merge/324856
<zyga> mvo: is did you see the lock directory issue on any of your machines?
<morphis_> zyga: btw. if you didn't saw it yet: https://en.opensuse.org/openSUSE:How_to_contribute_to_Factory#How_to_add_a_new_package_to_Factory
<zyga> morphis_: if system:snappy counts as a devel project then we're very close
<morphis_> zyga: right
<morphis_> zyga: I think for factory inclusion we should better have the snap-mgmt.sh script included
<morphis_> otherwise package removal is pretty dirty
<morphis_> so let me add that this evening
<zyga> morphis_: yes, I agree
<zyga> morphis_: sounds good
<zyga> hmm
<zyga> github died
<zyga> "major service outage"
<zyga> well
<morphis_> yeah
<Son_Goku> zyga: you need to request it to be added as a devel project
<Son_Goku> it must be specially marked for Factory
<Son_Goku> otherwise the bot will reject the SRs
<Son_Goku> talk to DimStar in #opensuse-factory about figuring out the process to that
<Son_Goku> though really, now that snapd is only one package, you can move it into system:packagemanager and avoid the mess entirely
<Son_Goku> err, one source package
<zyga> Son_Goku: what is system:packagemanager? some blessed devel repo?
<Son_Goku> yes
<zyga> Son_Goku: I think we could just get system:snapd tagged this way
<zyga> how can we check if it is tagged or not?
<Son_Goku> well, system:snappy
<zyga> (right)
<Son_Goku> there's a whitelist somewhere, lemme check
<zyga> Son_Goku: thanks, how do you know those things? :)
<Chipaca> spread from travis is really having a bad day today :-(
<zyga> Chipaca: github is down
<Chipaca> this might explain things
<Son_Goku> zyga, with the extremely notable exception of Debian and Ubuntu, I'm involved in all major Linux distributions
<Chipaca> quick, move everything back to launchpad while nobody is looking
 * Son_Goku stabs Chipaca with a fork
<kyrofa> Gaaaaah giiiithuuuub
 * Son_Goku runs and whistles
<Son_Goku> kyrofa: this is why you have a replica project on GitLab :)
<zyga> aaaand its back
<Son_Goku> fwiw, it was never down for me
<Son_Goku> apparently, only down in the European side
<zyga> Son_Goku: look at status.github.com
<kyrofa> Liar. It works every other refresh. Some presentation nodes
<zyga> well they sure lost their 5-9s
<kyrofa> Five? Hahaha
<zyga> soon they will have 9-5s
<kyrofa> Their API is 95%
<Chipaca> they totally have 9 9s
<zyga> yeah, I'm watching the same page
<Chipaca> 0.999999999
<zyga> LOL
<cjwatson> I once briefly worked on software that required six nines
<cjwatson> That was interesting
<zyga> cjwatson: was it changed (the software)?
<cjwatson> Very carefully :-)
<cjwatson> telco stuff
<Chipaca> I love that we can build stuff to that spec
<zyga> I wonder how that must work and be like
<cjwatson> hot failover EVERYWHERE
<Chipaca> I hate what we apparently have to do to get there
<zyga> how doyou learn by making mistakes?
<zyga> aha
<zyga> so you can still
<zyga> interesting
<Chipaca> zyga: you do that part on somebody *else's* telco
<cjwatson> you get 30 seconds a year of downtime so you don't have time to boot anything
<cjwatson> at least not much
<mvo> zyga: no, the lock directory issue I have not seen myself, just from errrors.u.c
<zyga> thanks
<zyga> I'm still exploring it
<elopio> mpt: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555569
<mup> Bug #1555569: [snaps] Show human-readable names for store apps <gnome-software> <sdoc> <Snappy:New> <Software Center Agent:Fix Released> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1555569>
<mup> PR snapcraft#1337 opened: autotools: don't force uniqueness on configflags <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1337>
<Saviq> kalikiana, or rather â
<mvo> pedronis: 3385 should be ready now btw
<pedronis> mvo: I saw that, will merge it in a bit
<mvo> pedronis: thanks
<zyga> I have an idea why the lock thing is exploding
<zyga> \o/
<zyga> mvo: I think this is another race
<zyga> mvo: running a scenario to confirm now
<Son_Goku> zyga, there's a few fixes I need to submit to the snapd package on openSUSE
<Son_Goku> so I'll prepare those tomorrow
<Son_Goku> I won't have any time today
<zyga> Son_Goku: sure, what kind of fixes?
<Son_Goku> conditional checks for BRs and stuff
<zyga> Son_Goku: no worries, we wanted to prepare to submit to factory
<zyga> BRs?
<Son_Goku> BuildRequires
<zyga> sure, thank you
<zyga> Son_Goku: but we can do that after your patches are merged
<Son_Goku> yes
<Son_Goku> wait what?
<Son_Goku> what patches?
<Son_Goku> to snap-mgmt.sh, you mean?
<zyga> Son_Goku: well the fixes you just mentioned
<Son_Goku> well, I think I already branched snapd from system:snappy
<mup> PR snapcraft#1328 closed: qmake plugin: set default qt version <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1328>
<pstolowski> zyga, ok, the problem with prepare.sh is that we first install new core from edge, and that already fails on configure hook (because of changes to snapd and changes to snapctl which are not in effect yet) and makes prepare.sh fail before we have a chance to re-pack core with new binaries. so it's not actually the test failing, but prepare.sh very early on.
<cachio> niemeyer, mvo, ziga, As I cant reproduce the openvswitch error from my machine, is it ok if I create a test PR to run it from travis to get more information about the error?
<cachio> niemeyer, mvo, ziga, afaik it is getting stuck trying to create the db
<Chipaca> kyrofa: are you at the sprint?
<zyga> pstolowski: interesting
<zyga> pstolowski: we should download core then, not install it
<zyga> cachio: fine with me
<pstolowski> zyga, indeed
<mup> PR snapd#3416 opened: DONT REVIEW - Adding debug information to test interfaces-openvswitch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3416>
<kyrofa> Chipaca, yessir, what's up?
<Chipaca> kyrofa: I hadn't realised you guys would be in london :-) was wondering if you were doing anything this eve
<kyrofa> Chipaca, nope
<kyrofa> Chipaca, want to?
<Chipaca> kyrofa: it doesn't sound like a bad idea
<kyrofa> Chipaca, it indeed sounds relatively acceptable
<Chipaca> all things considered etc
<kyrofa> Chipaca, how close do you live?
<Chipaca> kyrofa: an hour away, approx
<Saviq> kyrofa, https://travis-ci.org/snapcore/snapcraft/builds/237914554?utm_source=github_status&utm_medium=notification
<kyrofa> Chipaca, want do you want to do? Come in here, stay out there?
<Chipaca> kyrofa: i think i'll be going in, in a bit
<Chipaca> i'll have to find my bluefin pass! :-)
<kyrofa> Chipaca, awesome. That's a bit of a trip though, you're welcome to crash if you like
<ogra_> slangasek, why is the ubuntu-image deb trying to loop mount img files ? i thought it would not require any privieged actions anymore
<slangasek> ogra_: because you have a version of e2fsprogs that's too old to let it populate a filesystem at creation time
<ogra_> oh, thats still broken in 16.04 because e2fslibs wasnt fixed :/
<ogra_> slangasek, yeah :(
<ogra_> i thought that was supposed to have been SRUed long ago
<slangasek> ogra_: absolutely not, that's a new major upstream version of e2fsprogs with behavior changes
<ogra_> hmpf, k
<pstolowski> zyga, if I don't install core in prepare and only download & modify+repack, it needs to be installed with --dangerous; is this a problem for our testing?
<zyga> pstolowski: not sure, perhaps yes
<zyga> pstolowski: I assume that we check the signature right?
<ogra_> boo
<zyga> pstolowski: and you cannot just ack the assertion
<zyga> pstolowski: and install it?
<ogra_> root@11f68f46633c:/# /snap/bin/htop
<ogra_> cannot perform operation: pivot_root /tmp/snap.rootfs_CYPssc /tmp/snap.rootfs_CYPssc//var/lib/snapd/hostfs: Operation not permitted
<ogra_> (having snap and snapd running inside docker lets you install and remove snaps ... but you cant run them)
<zyga> ogra_: missing patches I think
<zyga> ogra_: can you show me the denial?
<ogra_> zyga, i dont think i can ... apparmor is off in that container
<pstolowski> zyga, what do you mean by acking the assertion? I think I need to ignore it and force dangerous, as checksum will not match anymore? we got away with it because prepare unmount and remounts it after installed
<kyrofa> Chipaca, think you'll be here around dinner time-ish?
<Chipaca> kyrofa: are you guys at bluefin?
<ogra_> zyga, i doubt it is apparmor related, ratther docker itself
<kyrofa> Chipaca, yes
<zyga> ogra_: and in the outside? apparmor is really a kernel-wide thing
<zyga> ogra_: I disagree, this looks like apparmor
<Chipaca> kyrofa: i could aim to be there at 6pm, or I could aim for later if you want to go back to the hotel and such
<zyga> pstolowski: snap akc
<zyga> darn :)
<zyga> snap *ack*
<fgimenez_> morphis_: it seems that during this test reexec was disabled on debian https://travis-ci.org/snapcore/snapd/builds/235819260#L2936 i've seen this in several executions, have you found this kind of error before?
<zyga> pstolowski: but without the assertion the samantics is not the same in some places
<mup> PR snapd#3415 closed: interfaces: revert "interfaces: re-add reverted ioctl and quotactl <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3415>
<ogra_> zyga, and indeed you are right ... http://paste.ubuntu.com/24727427/
<kyrofa> Chipaca, or we can do BOTH
<zyga> ogra_: oh very interesting
<kyrofa> Chipaca, no need to go back to the hotel, come whenever you think you'll be hungry
<mvo> fgimenez_: is it reasonable straightfroward for you to test if current master is fixed with regards for the snap revert test that caused the network-manager regression? if so, could you please trigger a test?
<pstolowski> zyga, I know... thus the question about affecting the tests.. anyway. i think I have a simple workaround (setting both new and old var in hookmgr) which is needed anyway for transition. no need to modify prepare then
<zyga> ogra_: can you just add "signal," to snap-confine's apparmor profile and reload it
<mvo> fgimenez_: I think master is fine and I prepared cherry-picks for 2.26, if your test is positive I will upload 2.26.4 to the PPA and make new beta images
<ogra_> zyga, in the container ?
<ogra_> not sure that will work
<fgimenez_> mvo: of couse on it, will let you know how it goes
<ogra_> (simply beacause i wont be able to relaod)
<ogra_> **reload
<zyga> ogra_: yes,
<zyga> ogra_: why not?
<mvo> fgimenez_: thank you!
<zyga> ogra_: that doesn't sound right, snapd does it all the time, apparmor is stacked
<ogra_> zyga, apparmor is completely disabled
<Chipaca> kyrofa: that's my secret: i'm always hungry
<mvo> fgimenez_: I have dinner now I think, I will read scollback, super happy that we can move foward with 2.26 now :)
<zyga> ogra_: it's not disabled, what makes you say so?
<zyga> ogra_: that denial is from apparmor
<ogra_> root@11f68f46633c:/# apparmor_parser
<ogra_> Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
<ogra_> Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
<ogra_> Use --subdomainfs to override.
<fgimenez_> mvo: np :) it would be great to have snapd#3348 so that we can trigger this test automatically as soon as new core snaps are published
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<kyrofa> Chipaca, haha, well then, just come now!
<zyga> ogra_: apparmor is not a container thing, it is loaded into your kernel
<kyrofa> You're tired of working today anyway
<zyga> ogra_: and it actually stopped snap-conifne in the container from doing something
<ogra_> zyga, but the container cant talk to it
<zyga> ogra_: so how can it be disabled?
<ogra_> zyga, on docker level
<zyga> ogra_: it can, because the container loaded the apparmor profile for snap-confine
<Chipaca> grah grah grah with spread and { Error preparing project on linode:ubuntu-14.04-64 }
<ogra_> zyga, --security-opt apparmor:unconfined
<zyga> ogra_: that's not the same as disabled
<mvo> fgimenez_: indeed! it has a +1 from me already
<ogra_> for docker run
<zyga> ogra_: can you do what I suggested
<zyga> ogra_: it will let you see what is really wrong
<ogra_> zyga, i can not run apparmor_parser
<zyga> ogra_: what happens when you do?
<ogra_> so i cant change the profile
<ogra_> see above
<zyga> you get a denial from snap-confine when you run apparmor_parser?
 * zyga must be missing a link to another error
<zyga> ah, I see now
<ogra_> zyga, i cant run appramor_parser to reload any profile since apparmor_parser can not run inside the container
<ogra_> due to the /proc fs there not having the needed bits
<mvo> jdstrand: some good news, we have a working seccomp->bpf thing in go and the seecomp code in snap-confine  can shrink by ~800 lines or so now (to be fair a lot of sc_add_map() calls in there). zyga will also work on this so I'm sure it will be nice
<zyga> ogra_: is proc and sys normal but the kernel on the outside is not?
<zyga> ogra_: is the kernel fully patched?
<jdstrand> interesting
<fgimenez_> mvo: aha thx, sorry didn't notice, zyga, morphis_ could you please take a look at snapd#3348?
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<ogra_> zyga, i have not really any idea how docker creates its virtual /roc in the containers ... it should not be shared with the host afaik
<ogra_> **proc
<zyga> ogra_: I think it must be, just different namespaces
<zyga> there's just one proc
<ogra_> with docker ?
<zyga> yes
<zyga> ogra_: anyway, my real questions this: is the kernel you are running on fully patched to support apparmor features from ubuntu?
<ogra_> afaik you get a dedicated /proc when starting a container
<zyga> ogra_: if not then don't touch docker
<zyga> ogra_: dedicated how? it's just a procfs mount
<zyga> ogra_: it's all the namespaces that make it different
<ogra_> root@11f68f46633c:/# ls /proc/|wc -l
<ogra_> 72
<zyga> ogra_: see above
<ogra_> ogra@anubis:~$ ls /proc/|wc -l
<ogra_> 429
<zyga> ogra_: it's the normal procs
<zyga> ogra_: with a PID namespace
<ogra_> inside vs outside the container
<jdstrand> ogra_: I'm late to the party. are you trying to run snaps in a docker container?
<zyga> ogra_: (it's different because you are looking from a namespace)
<zyga> but you are looking at the same thing as outside
<ogra_> jdstrand, well, first i only tried to get snapd to run and the core snap installed ... got that working ... now i got greedy and tried to run a snap :P
<jdstrand> ogra_: that isn't going to work unless you disable apparmor in snapd
<jdstrand> ogra_: it works in lxd because lxd was modified to understand apparmor stacking
<zyga> jdstrand: note that I think ogra also uses an "interesting" kernel where some things are missing
<ogra_> jdstrand, well, i disabled apparmor in docker ... probably i should cheat and hack lsb-release/os-release so snapd doesnt think it is on ubuntu
<zyga> jdstrand: what it looks like to me is that that version has no idea about stacking
<zyga> jdstrand: and what happens is that it uses the outside profile
<zyga> ogra_: we no longer care about os-release
<zyga> ogra_: we look at apparmor features in sysfs
<jdstrand> zyga: well, I think it is likely that in the container apaprmor is disabled because things aren't mounted, etc, but apparmor init notices that it isn't lxd and says apparmor isn't available
<ogra_> well, then only llsb_release
<ogra_> zyga, ouch
<ogra_> then i have no chance of hacking around this i guess
<zyga> jdstrand: yes but also note that snap-confine itself (in docker) gets killed by apparmor
<jdstrand> ogra_: you need to disable apparmor in the snapd in docker
<zyga> jdstrand: and uses a non-stacked profile path
<jdstrand> (and snap-confine)
<zyga> ogra_: I think this is a moot exercise, what are you trying to achieve?
<jdstrand> ogra_: is this a docker snap or a docker deb?
<ogra_> jdstrand, right ... and in the past i could have done that by hacking the distro info to pretend i'm not ubuntu
<ogra_> (disabling apparmor of snapd)
<ogra_> jdstrand, dockeer deb on 16.04
<ogra_> zyga, nothing really ...
<jdstrand> ok, so, in a docker deb, the docker daemon is not confined. if you used --security-opt apparmor:unconfined (or whatever the incantaion is), then that means the container is not confined either. if you can convince snapd in the container that it shouldn't use apparmor, then apparmor should not be in your way
<zyga> ogra_: to do that, I think, you must boot with apparmor disabled on command line
<zyga> ogra_: I think that may be sufficient
<jdstrand> but, docker has a seccomp list it puts on containers which could block pivot_root
<jdstrand> (or other things)
<ogra_> zyga, linaro uses docker for all image building ... essentially all i initially tried was to get "snap known --remote model series=16 model=pc-amd64 brand-id=canonical" to work ... to not have them use hacked up model assertions for the images they offer (since they end up non-upgradeable)
<ogra_> zyga, so i only tried to get snapd and the snap command to work (which i achieved) ... the "running a snap" was just something i tried then ... since i was in that env anyway
<fgimenez_> mm the store is returning 50x on some requests http://paste.ubuntu.com/24727574/
<zyga> I see
<ogra_> zyga, though i guess it would be nice to find a docker setup where you can actually use snaps :)
<zyga> all the goodies today make me want to go downstairs, take a shower and read a book outside
<ogra_> heh
<zyga> ogra_: I think that needs love
<zyga> jdstrand: is there any docker setup that would work today?
<zyga> ogra_: I think lxd is possible but docker is not
<ogra_> zyga, right ... well, at least snapd runs now, i have a setup here (will blog about it later in the week)
<ogra_> zyga, right ... but what do you do with third parties that dont use lxd
<ogra_> (lxd is fine btw, i tried that today)
<ogra_> (well ... lxc actually)
<zyga> ogra_: say it is not supported, it's not going to magically fix itself
<zyga> unless we make snapd and docker owrk
<zyga> *work
<ogra_> zyga, well, all i needed was the model assertion ...
<ogra_> so make the snap conmmand work enough to download it ... that works now
<ogra_> running a snap would just have been the cherry on top ... not a requirement
<ogra_> (it wouldnt have helped anyway since ubuntu-image is now --classic which makes unusable for 90% of my use cases as a snap ... i'll have to resort to the deb anyway)
<zyga> I see
<ogra_> (though i just found that the deb is unusable as well in 16.04 containers if you dont add PPAs ... (see my conversation with slangasek above)) ...
<jdstrand> zyga: that question is open ended. I have not tried to run snaps within a docker container. All I can say is that if you are using the docker deb and you run containers unconfined and you make sure snapd doesn't think it should use apparmor, it could maybe be made to work (if tweaking the docker syscall list and likely running a system container)
<mup> PR snapd#3417 opened: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417>
<jdstrand> zyga: if you use the docker snap, it will not work because docker doesn't know about apparmor stacking. if you use the deb but don't launch containers unconfined, you could *maybe* craft a profile for the container that would allow snaps to run *if* snapd in the container didn't think it should use apparmor
<pedronis> mvo: will snapd#3385 create an always failing timer on classic? is that a problem?
<mup> PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
<bdx> hows it going everyone? I'm wondering if there is a best practice for snapping projects where the codebase comes from github? i.e. should we be tagging builds and associating those with the snap, or a direct code clone when building the snap?
<ogra_> bdx, you should just use build.snapcraft.io ;)
<ogra_> (at least if you own the GH branches)
<bdx> ogra_: sick! is this newnew?
<ogra_> yeah, relatively new
<fgimenez_> mvo: i think we currently can't make sure that the core-revert passes with the code in master, we would need to use a core snap built from that code, if we could have a new edge core that would be enough, we can also wait until next edge core tomorrow
<bdx> this looks awesome! digging in now. thanks!
<ogra_> enjoy :)
<fgimenez_> mvo: assuming that the deb ppa has those changes, with the current flakyness maybe it wasn't updated (it syncs after merge + green build)
<aquarius_> yo, snappy types! I'm getting a weird error when I run the snap I've just built:
<aquarius_> Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.3234" is not allowed to own the service "org.kryogenix.pick-colour-picker" due to AppArmor policy
<aquarius_> so, what should my service be named?
<zyga> aquarius_: you want to look at the dbus interface but if this is a user session service I think that is currently unsupported
<zyga> (though in progress)
<aquarius_> zyga: er
<aquarius_> I don't know what that means :)
<zyga> aquarius_: is your snap using the dbus session bus?
<aquarius_> the issue I was having is this: my snapped python2/gtk app worked fine, but it did not use my desktop theme. It was suggested that I should use add the home, gsettings, and unity7 plugs, which I have done, and now the snap installs but the app will not launch, with the above error.
<zyga> aquarius_: none of those would make it match your desktop theme
<aquarius_> I have a section in the snapcraft.yaml which looks like this:
<zyga> aquarius_: did your snap previously work in devmode or in strict confinement?
<aquarius_> https://paste.gnome.org/paztxcuml
<aquarius_> but that section was there before and it worked.
<aquarius_> I installed with --dangerous, but not with --devmode.
<aquarius_> I don't really understand what that entails. :)
<aquarius_> (that is: does --dangerous imply --devmode?)
<zyga> no, it doesn't
<zyga> aquarius_: I'm sorry but I cannot help you now, I ned to leave now; either catch me tomorrow or perhaps ask jdstrand
<aquarius_> will do! cheers, pal
<aquarius_> jdstrand: ping (you're who didrocks suggested I should talk to, actually :))
<kyrofa> aquarius_, --devmode means "install without confinement (and warn when my app does something that WOULD be denied)"
<kyrofa> aquarius_, --dangerous, on the other hand, means "install without verifying that this snap comes from a trusted source"
<kyrofa> aquarius_, --devmode implies --dangerous, but not the other way around
<aquarius_> excellent
<bdx> ogra_: build.snapcraft.io is like CI/CD for snaps?
<aquarius_> thank you for that, kyrofa! So, I was not installing with --devmode, and I was installing with --dangerous: I need --dangerous because I'm installing the snap I've just built :) And I didn't need --devmode which means that my app was working under confinement.
<kyrofa> aquarius_, indeed
<kyrofa> bdx not quite. CI typically runs tests, etc., acting as a gateway for, say, accepting pull requests
<nacc> https://build.snapcraft.io/ has a nice picture
<nacc> about halfway down the page as to where it fits (it's after CI)
<bdx> ahh, the second graphic is what I was looking for
<bdx> lets take any web app for example
<bdx> rails, django, php .... something that is not a snap
<bdx> so, you have a repo for your django site, would that now contain a snapcraft.yaml?
<bdx> or would the application code be separate from the snap?
<nacc> bdx: aiui, yes, you need a snapcraft.yaml still (i'm not sure if it can live in a separte 'packaging' repository/branch)
<ogra_> you would likely have a django setup defined and configured inside your snapcraft.yaml, so your snap would ship it along to serve your site
<bdx> ogra_: a 'django' snap could be a generic snap that lets you set a key and a repo basically?
<ogra_> (or you have a webserver snap that shares content with your snap via the content interface ... that way you could update the site only ... but that would be a very personal/specific setup)
<nacc> bdx: a snap is an entire application, you wouldn't snap django itself (imo), but your use of django
<ogra_> bdx, no, i mean you would ship a full webserver environment including django inside your snap
<nacc> bdx: in snap parlance, django would be a 'part'
<ogra_> or alternatively make two snaps and have one share datas from the other
<ogra_> *data
<bdx> I see this, but how does the snap interface to the application code
<bdx> currently I use a git-layer in my charms to pull in application code
<ogra_> have a look at the content interface
<bdx> ok
<bdx> I'm trying to understand what about my charms should become snaps
<ogra_> your webserver would use shared code from $SNAP/wrbserver/shared and be configured for that ... and your app code would then provide stuff in that dir through the content-sharing interface
<bdx> ogra_: I see, so I could use the charm to handle the application code in that case
<ogra_> when you upgrade your app snap it will automatically ship the updated code in that dir
<bdx> I see ... so my application code is packaged with the snap then
<ogra_> well, it really depends what you want ... either bundle the server with the app or use an interface to hold both of them separated
<ogra_> everything is possible ;)
<bdx> totally ... thats what make it so difficult
<bdx> I feel like I need to be more educated on snaps to be making these decisions
<ogra_> (you could also have a deb based server that has a fixed config to look in /snap/$your-app/current/data/ for all its stuff
<ogra_> )
<bdx> I'll work on that
<bdx> yeah ... then have the charm deliver the application code
<ogra_> there are no limits to creativity with snaps ;)
<bdx> I think my problems moving forward will be knowing and understanding the framework here and what is available and how to use it
<ogra_> right ... i guess thats a matter of playing around with it and learning its capabilities ;)
<jdstrand> aquarius_: you need to slots the dbus interface so it may bind to that well-known name. do 'snap download corebird', unsquashfs it, then look at squashfs-root/meta/snap.yaml for an example
<jdstrand> basically:
<jdstrand> slots:
<jdstrand>  foo:
<jdstrand>   bus: session
<jdstrand>   interface: dbus
<jdstrand>   name: org.kryogenix.pick-colour-picker
<bdx> possibly I need to forget about what components the charm will handle, and just try to get something fully snapped then turn around and use the charm to fill in the lifecycle ops that are still needed following the app being fully snapped
<Saviq> kyrofa, https://github.com/snapcore/snapcraft/commit/d22880fdcee434a5e85c376e8f26c61a661231ce
<jdstrand> aquarius_: see https://github.com/snapcore/snapd/wiki/Interfaces#dbus
<mvo> pedronis: always failing timer> yeah, I can make it just exit(0) instead, that will probably be fine
<pedronis> mvo: ah, ok
<Saviq> kyrofa, bug #1694765
<mup> Bug #1694765: source-type: git uses --remote for submodules <Snapcraft:New> <https://launchpad.net/bugs/1694765>
<aquarius_> jdstrand: I've got that section you described above under plugs; is that wrong, or do I need to declare it under plugs *and* slots?
<aquarius_> jdstrand: that is: it's currently https://github.com/stuartlangridge/ColourPicker/blob/app/snap/snapcraft.yaml#L23
<aquarius_> do i need to duplicate that "plugs" section as "slots"?
<mvo> pedronis: unless I'm missing something this is already the case: http://paste.ubuntu.com/24728381/
<pedronis> mvo: yes, sorry, IÂ forgot:Â  if err != errOnClassic {
<kyrofa> pedronis, this looks like kyle but it's actually Chipaca. Github on mobile won't let me merge snapd#3400, could you give it a poke?
<mup> PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<pedronis> kyrofa: Chipaca, looking
<kyrofa> :) thanks
<mvo> pedronis: great, thanks for double checking
<pedronis> kyrofa: Chipaca, done
<aquarius_> heh, so, it can't be plugs, since I get "cannot have plug and slot with the same name", so I'll try just as a slot. Cargo cult programming ftw. :)
<mup> PR snapd#3400 closed: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3400>
<aquarius_> ok, I've now got it to install, at least, but it hasn't actually fixed the original issue of not having a theme. I'll talk to didrocks again :)
<aquarius_> jdstrand: my snapcraft.yaml looks like this: http://paste.ubuntu.com/24728481/ -- is that what you were suggesting?
<jdstrand> aquarius_: yes. and also yes, I don't have answers for the theme
<aquarius_> jdstrand: no problem (the theme is not your thnig :))
<aquarius_> jdstrand: just checking I was doing what you suggested
<seb128> aquarius_, hey, just in case it's interesting to you, colourpicker fails to start from snap here with that error
<seb128>   File "/snap/pick-colour-picker/x1/lib/python2.7/site-packages/pick/__main__.py", line 874, in start_everything_first_time
<seb128>     self.w.set_default_icon(image.get_pixbuf())
<seb128> TypeError: Argument 0 does not allow None as a value
<aquarius_> huh. really? it starts for me, it just doesn't have the right theme...
<aquarius_> I suspect this is about paths. Fabulous, etc :)
<seb128> aquarius_, could be, in any case it looks like the pixbuf might be None and your code doesn't handle that case
<aquarius_> indeed!
<aquarius_> although it shouldn't be :)
<aquarius_> I'll look into it (and try ti work out why it's none!)
<seb128> let me know if you need debug infos
<niemeyer> Forum going down/up for a quick configuration update..
<niemeyer> Almost there.. aaaaaaan
<niemeyer> d.. it's up!
<mup> PR snapd#3418 opened: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418>
<seb128> aquarius_, theme works here in devmode on xenial/unity
<niemeyer> SMTP is failing to relay properly.. reverting setup.. :(
<ogra_> jdstrand, FYI ... --security-opt seccomp:unconfined in the "docker run" command works around the blocker ... not that this gets me much further though ...
<ogra_> root@7c9bcf90f68b:/# /snap/bin/htop
<ogra_> cannot bind-mount the mount namespace file /proc/202/ns/mnt -> htop.mnt: Permission denied
<ogra_> support process for mount namespace capture exited abnormally
<ogra_> :P
<jdstrand> ogra_: I had a sneaking suspicion that mount, pivot_root and the like would be blocked by docker
<mup> PR snapd#3419 opened: interfaces: partly revert aace15ab53 to unbreak core reverts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3419>
<mvo> jdstrand: I have another partial revert for you -^
<mvo> jdstrand: for you to review, we have a reliable test now and it breaks on this symbol now
<jdstrand> oh sigh
<jdstrand> all my arg filtering work keeps getting reverted
<jdstrand> mvo: responded
<mvo> jdstrand: thank you!
<mvo> jdstrand: well, not for long hopefully, https://github.com/mvo5/snappy/commits/seccomp-bpf will fix it (when its polished enough to get merged)
<cachio> niemeyer, could you please update the https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz with the last version which has the repeat?
<niemeyer> cachio: Yeah, just not right now..
<niemeyer> cachio: Also, not sure how that helps?  I mean, -repeat is only useful locally I suppose?
<cachio> niemeyer, I need to check the test is working in ci
<cachio> niemeyer, because from my machine it always pass
<cachio> niemeyer, not sure if it is because my connection is slower or why
<cachio> niemeyer, so ,my idea is to repeat the execution 100 times in ci to check the fix works
<cachio> niemeyer, does it make sense?
<niemeyer> cachio: Ah, yep
<niemeyer> cachio: Can't do that now, but will do
<niemeyer> Need to step out for a while
<mup> PR snapd#3420 opened: many: slight improvement of some snap error messaging <Created by chipaca> <https://github.com/snapcore/snapd/pull/3420>
#snappy 2017-06-01
<zyga> o/
<pstolowski> morning zyga !
<zyga> mvo: hey, no luck with lock issue yet; what makes me mad is that it happens in real time, every minute there are several reports
<zyga> mvo: it might be one machine doing CI but we just don't know
<zyga> mvo: I will try to inject some possible failures to see if I can replicate the error (yesterday all my attempts failed to reproduce it)
<morphis__> zyga: I've seen the lock issue multiple times too on my system but lost that state already a while back, will tell you if I see it again
<zyga> morphis__: during development or just use of snapd?
<morphis__> use of snapd
<morphis__> but it was a mixture of me doing multiple things, don't really remember
<zyga> morphis: do you have it in snap changes?
<zyga> morphis: any theory would be very valueble today
<abeato> zyga, hey, anything left for https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<morphis> zyga: no, I've cleaned my system after that some time ago
<morphis> zyga: sorry
<zyga> abeato: no, let me approve it, sorry
<zyga> mvo: (let's chat here)
<zyga> mvo: interesting observation, the zesty kernel is now at 4.10.0-21 but we see errors with just -19
<zyga> mvo: but snapd is 2.25
<zyga> mvo: this feels like a fresh install but no reboot
<abeato> zyga, thanks... there is an issue with the tests but seems to be the CI infra
<zyga> abeato: done
<abeato> great!
<mvo> zyga: yeah
<zyga> mvo: question
<zyga> mvo: is there any way to update with apt/dpkg
<Chipaca> gah
<Chipaca> why do we turn a 504 into a 400 :-(
<Chipaca> 503*
<zyga> mvo: that would cause conffiles to be _not_ updated even though the user has not modified his local copy?
<Chipaca> (you don't need to answer that)
<mvo> zyga: I can't think of anything
<zyga> thanks
<mup> PR snapcraft#1338 opened: go plugin: Add support for cross-compilation <enhancement> <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1338>
<mup> PR snapd#3385 closed: cmd: add stub new snap-repair command and add timer <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3385>
<pedronis> mvo: ^ IÂ merged the basic snap-repair, I'll start working a bit on top of it today
<mvo> pedronis: great, thank you
<Chipaca> quick question, team: which of these is better? http://pastebin.ubuntu.com/24735919/
<mvo> Chipaca: I like the second
<ogra_> Chipaca, i'd take the last one but attach "(503 Service Unavailable)" after "network trouble"
<Chipaca> ogra_: was thinking something similar
<Chipaca> (in the two shorter ones, the big message is sent to the log)
<Chipaca> so maybe it's ok not to tell the user anything more than the shortest message
<Chipaca> as they can dig
<Chipaca> but dunno
<pedronis> Chipaca: well I would argue that a 500 is not a network trouble
<pedronis> network trouble would make me think that my local router need a kick
<Chipaca> pedronis: where does it stop being "network trouble"?
<pedronis> Chipaca: anything that gave you a http response is probably not network trouble
<Chipaca> pedronis: at the user's router? their isp's? our isp? our dc? ...?
<pedronis> it might be cloud trouble tough :)
<Chipaca> pedronis: i'm always open to suggestions :-D
<pedronis> Chipaca: "network trouble"Â is a completely unactionable message
<Chipaca> pedronis: so is the other two
<Chipaca> so are*
<pedronis> well, sorry, it's probably not just unactionable, it's ambgiously so
<pedronis> Chipaca: if you get a 50x you should probably say server somewhere, not network
<Chipaca> i can change it to 'server trouble' :-)
<Chipaca> 4xx are also server trouble, at this level
<pedronis> well usually they are
<pedronis> or we did something bad with snapd
<pedronis> but usually
<pedronis> not
<pedronis> anyway not something the user can fix
<ogra_> but he can report it
<Chipaca> 'server trouble' works
<Chipaca> 'server trouble (see logs for more info)'?
<Chipaca> see journal*
<pedronis> Chipaca: anyway  server trouble (something) seems still better to me
<ogra_> something like that ... if you dont want to show thee error code
<pedronis> it's either non relevant, but for people that can read it , it avoid an extra hop to the logs for nothing
<pedronis> Chipaca: related  to this we should also remember to fix in client or cmd when we call snapd issues, server issues
<morphis> zyga: https://build.opensuse.org/request/show/500355
<pedronis> Chipaca: you could also say  "store" troubles in most cases, IÂ think there's also one thing we do that is not quite store but something else (userinfo)
<Chipaca> pedronis: piano piano se va lontano
<mup> PR snapcraft#1339 opened: python plugin: install six before using setuptools <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1339>
<Chipaca> true! i like store troubles
<zyga> morphis: looking
<Chipaca> this is in store.go after all :-)
 * Chipaca looks at auth.go just in case
<pedronis> Chipaca: most stuff we do in auth.go are also to talk to the store in the end, as I said userinfo.go is the only ambiguous one
<pedronis> is ssh keys in LP "store"Â ?
<zyga> morphis: what is the ghost feature?
<pedronis> Chipaca: anyway we might also be about to conflict on this, IÂ have also a big change for store.go (extracting retry to httputil)
<Chipaca> pedronis: this is a really small and silly branch
<Chipaca> so i don't mind either way
<pedronis> Chipaca: ok, need to fix a conflict and one test issue about testing DNS when we have a proxy around then my branch is reviewabale, will give a pointer soon
<Chipaca> ok
<Chipaca> pedronis: i too have a pr up fwiw
<pedronis> saw it
<pedronis> will look in a bit
<Chipaca> ok
<Chipaca> mentioning it because it touches store
<Chipaca> although changes in store itself are minimal
<didrocks> zyga: hey, it seems you told that you told to aquarius_ that my recommendations wouldn't make them match the desktop theme
<didrocks> zyga: they do
<zyga> didrocks: not in general, not always
<didrocks> I'm happy to explain to you how the desktop is working, but don't mislead the users based on our launcher work :)
<didrocks> zyga: x11, any desktop, if you have the theme in the snap, it will
<didrocks> not with the dark gtksettings though
<didrocks> which is the issue aquarius_ had
<zyga> didrocks: maybe I misunderstand but can it universally mirror the theme of the classic distro?
<didrocks> (because they aren't in gsettings, but in another file)
<didrocks> zyga: if your snap embeeded them, yse
<didrocks> yes*
<didrocks> with matching version of the gtk one your are linked against
<didrocks> which is what the desktop-launcher does (with popular themes)
<didrocks> willcooke: FYI ^
<zyga> didrocks: right, but snaps cannot embed any and all themes
<didrocks> zyga: indeed
<zyga> didrocks: sure, I agree, I just replied about the fact that snaps cannot do it perfect universally, not that it is not good for practical use
<didrocks> zyga: but that wasn't the issue here, aquarius_ knew about that limitation
<didrocks> yeah
<didrocks> we will need to have theme snaps
<zyga> yes, I agree
<zyga> and I have some ideas on how to do them already
<zyga> but insufficient time to experiment and prototype
<didrocks> ensure you talk with the desktop teams who knows about the exact technics
<didrocks> because there isn't just one gsettings involved in the theme selction
<didrocks> selection*
<zyga> didrocks: thank you, I will
<zyga> didrocks: the idea is more general than any particular technology though,
<didrocks> meanwhile, I'll fix that gtksettings not share
<didrocks> zyga: you still need to work with existing toolkits :)
<zyga> didrocks: I'm sure there are details to explore but the general idea is to offer theme snaps that would work with any snap using a given base
<didrocks> so, you need to know what the toolkits are reading and basing their theming on
<pedronis> Chipaca: snapd#3417
<mup> PR snapd#3417: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417>
<didrocks> zyga: hum, where are the interfaces stored now? I apt-get source snapd and grep for "gsettings", but don't find any match
<zyga> mvo: https://github.com/snapcore/snapd/compare/master...zyga:feature/detect-partial-updates?expand=1
<zyga> mvo: can you pleae eyeball the paths to ensure that's the right thing (before we waste CI slot)
<seb128> didrocks, https://github.com/snapcore/snapd/blob/master/interfaces/builtin/gsettings.go ?
<zyga> didrocks: you mean snapd interfaces?
<didrocks> interesting, I just apt-get source snapdâ¦
<zyga> didrocks: in snapd, in interfaces/builtin
<didrocks> ah, I probably don't have source for -updates
<didrocks> so very old snapd apt-get sourced ::p
<didrocks> :p
<Chipaca> pedronis: is dropping context because YAGNI?
<seb128> zyga, theme snaps ... just need to be able to content-share mount more than 1 content basically
<seb128> zyga, and auto mount the available themes
<zyga> seb128: we also need a way to tie this to base snaps
<zyga> seb128: so those themes will apply to that base and not other bases
<seb128> why?
<zyga> seb128: as for sharing many things, yes, it's doable, just I would not do it via content, instead I'd make a new interface using the same internal logic, that handles N themes automatically
<zyga> seb128: because other bases will use differnet toolchains, libc's and so on (fedora/suse/debian)
<zyga> seb128: so each theme needs to associate itself with a bse
<zyga> seb128: as a indicator of ABI
<zyga> seb128: this will also let us have themes that need different ABIs for series-18
<zyga> seb128: this is very similar to how flatpack does it now, they tie this to runtimes which is exactly how our bases are
<seb128> zyga, themes are mostly css files and icons
<zyga> seb128: in general, they can be anything
<seb128> that's not specific to toolchains
<zyga> Chipaca, mvo: https://github.com/snapcore/snapd/pull/3421
<mup> PR snapd#3421: errtracker: include hints of partial dpkg update in error reports <Created by zyga> <https://github.com/snapcore/snapd/pull/3421>
<mup> PR snapd#3421 opened: errtracker: include hints of partial dpkg update in error reports <Created by zyga> <https://github.com/snapcore/snapd/pull/3421>
<zyga> JamieBennett: ^^ this will help us test the theory on failures, this will also be cherry-picked into the next stable release
<zyga> JamieBennett, mvo: I will skip standup today, I need to go somewhere and I used up 90% of my mobile traffic by having last few hangouts on them by accident :/
<zyga> mvo: if you are going to land that branch or any fixes, quash them for easier cherry pick please
<jjohansen> zyga: http://people.canonical.com/~jj/linux+jj/ the kernel there should have a fix for the trace back you were seeing the other day
<pedronis> Chipaca: well, we were passing to TODO mostly to satifsfy doRequest which uses it but only for download
<pedronis> Chipaca: so yes until we have something better to pass than TODO, I think this is saner
<pedronis> when we have we can decide what to do with it
<pedronis> Chipaca: having lunch, will look at your branch afterward
<zyga> jjohansen: is that fix also in stable kernels in ubuntu?
<zyga> jjohansen: hey :-)
<mup> PR snapcraft#1340 opened: state: save all the build packages as global <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1340>
<jdstrand> mvo: hey, when you are ready for it to be reviewed, can you make sure you ask for me to be a reviewer of the bpf changes? also, did I hear something about a kernel traceback or eperm when trying to load the bpf cache?
<jdstrand> mvo: I mention it cause of no new privs. you have to make sure you get that right
<jdstrand> I see that yesterday you added a commit surrounding that, so maybe you figured it out already :)
<mup> PR snapcraft#1339 closed: python plugin: install six before using setuptools <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1339>
<mup> PR snapcraft#1341 opened: Release changelog for 2.30.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1341>
<mup> PR snapcraft#1342 opened: nodejs: run install and commands in source-subdir <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1342>
<mup> PR snapcraft#1343 opened: go plugin: Cross compile with CGo <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1343>
<pedronis> pstolowski: we are not super consistent already about using http.Status* constants, we maybe should be but then IÂ don't know if to fix everything in this branch or do a follow up
<pedronis> Chipaca: pstolowski: this kind of code is interesting httpStatusCode/100 == 4
<Chipaca> pedronis: it makes me uncomfortable but that's not an objective objection
<Chipaca> so it went in
<pedronis> Chipaca: yes, but it cannot stand if we want to use http.Status* consistently
<pedronis> (I personally don't care too much either way)
<Chipaca> pedronis: sure it can: return httpStatusCode/http.StatusCodeContinue == 4
<pedronis> no
<Chipaca> :-D
<pedronis> the 4 cannot be there
<Chipaca> ah, rats
<Chipaca> pedronis: actually they aren't typed
<Chipaca> afaik
<pedronis> so
<pedronis> ?
<Chipaca> maybe i misunderstand what you mean then
<Chipaca> anyway, i also don't mind one way or the other tbh (consistency wins)
<pedronis> I mean that code wants you to know about 40x vs BadRequest
<pedronis> Chipaca: we are not consistent atm either way
<mup> PR snapcraft#1253 closed: go plugin: cross-compilation support <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1253>
<Chipaca> i know
<pedronis> I'm been asked to be a bit more, but is a rat nest
<Chipaca> so yes something needs to be done :-)
<Chipaca> well, s/needs to/should/
<pedronis> to be completely honest I think it is easier to be consistent about not using http.Status*
<pedronis> but oh well
<mvo> jdstrand: yeah, I need to polish that code but I think the building blocks are ther enow, the testsuite passes except for the bit where the input name changed
<mup> PR snapd#3419 closed: interfaces: partly revert aace15ab53 to unbreak core reverts <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3419>
<pedronis> Chipaca: pstolowski: so can do but probably it's a separate PR, IÂ spotted about ~20 places that would need to change and they are not already touched by the PR
<pedronis> (if we don't consider tests, I'm not sure it's worth the effort there)
<pedronis> s/they are not/they are not all/
<pstolowski> Chipaca, lol @ return httpStatusCode/http.StatusCodeContinue == 4
<zyga> pstolowski, pedronis, mvo: I need a 2nd review on https://github.com/snapcore/snapd/pull/3421
<mup> PR snapd#3421: errtracker: include hints of partial dpkg update in error reports <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3421>
<pstolowski> pedronis, ok, that's fine, I didn't know there are more places affected
<mvo> zyga: yeah, looking at it now
<zyga> mvo: thank oyu
<zyga> I have one more on top that detects re-exec
<zyga> once those two land I'll propose cherry-picks into release/2.26
<mvo> zyga: re-exec we can infere from the build-ids, but making it explicit is nicer
<jdstrand> mvo: cool, thanks
<zyga> mvo: I said as much in the commit message :D
<pedronis> pstolowski: Chipaca: I put back the context to retryRequestDecodeJSON
<pstolowski> pedronis, thank you
<mvo> zyga: haha, ok
<zyga> mvo: replied
<zyga> mvo: I'll gladly iterate if you can look at the response
<mvo> jdstrand: can we do something about the snap-confine apparmor file? could we get it out of /etc/apparmor.d and not make it a conffile?
<mvo> zyga: yeah, just looking and experimenting a bit
<mvo> zyga: curious about the idea that it might be a half-installed snapd
<zyga> mvo: aha, thank you
<mvo> zyga: and I'm trying to reproduce this
<mvo> zyga: I mean, break it intentionally and see what happens
<zyga> mvo: half-updated,
<mvo> zyga: yeah, I wonder if we should have a daemon in this case
<zyga> mvo: (pardon my ingorance of dpkg terms)
<mvo> zyga: no problem
<zyga> mvo: as the problem would be different if the profile was not loaded (at all) yet
<mvo> zyga: I mean, the daemon is started in postinst, so if the upgrade did not quite work it depends on where it breaks etc, this is what I want to check, its an interessting angle to the problem
<mvo> zyga: aha, indeed
<zyga> mvo: would the socket be disabled during update?
<pedronis> Chipaca: I reviewed your branch, but I have a question/wondering there
<zyga> mvo: because if not then snap install will just wake everything up
<mvo> zyga: plus I wonder if we can simply move the file to a different place, the more I think about it, the more I get the feeling no user should mess aorund with it, i.e. it should not be a conffile
<mvo> zyga: yeah, interessting
<zyga> mvo: yes, (except for special cases which could become core config later)
<zyga> mvo: but even moving it around is dangerous
<zyga> mvo: as the presence of any backups, .dpkg-{old,new} files will make apparmor load that on boot
<zyga> mvo: so depending on racing time we may load the wrong order and overwrite
<mvo> zyga: indeed, if we move it we need to pull out the big guns to get rid of it
<zyga> mvo: (hence my initial suggestion to use a classic manager to ensure it is sane)
<zyga> mvo: yes
<mvo> zyga: it seems like the apparmor init.d loads etc first and then the snaps dir
<zyga> mvo: oh, that would be nice, we could just stick it in our directory
<zyga> mvo: anyway, I would appreciate swiftness as release time runs out
<zyga> mvo: we can iterate on making this nicer next
<jdstrand> mvo: yes, it could not be a conffile. the trick would be to make sure it is loaded before snap-confine is run
<zyga> jdstrand: I think mvo's observation is sufficient, it will be loaded by the same mechanism as today
<zyga> jdstrand: and even presence of any old/stale files will not
<zyga> ... not affect this as it will be over-written shortly thereafter (in the kernel)
<jdstrand> mvo: not that there are complications associated with moving it-- if the old file is still around, it could be loaded, possibly after the one that is somewhere else, so it needs to be always removed. also, nfs /home and some other users are modifying the profile to workaround issues with the profile. we'd need to introduce a mechanism for people to apply workarounds. Thankfully, we can use the #include local/... ideas for that
<jdstrand> s/^not/note/
<mvo> jdstrand: yeah, I noticed the local/ idea
<mvo> jdstrand: plus it looks like I need to maually add the postinst/postrm snippets that dh-appamor would generate for me?
<jdstrand> zyga: I'm not 100% sure snapd will be happy with something not named snap.* in that dir
<jdstrand> mvo: yes
<zyga> jdstrand: aha, interesting,
<zyga> jdstrand: well, we can look for a way
<jdstrand> mvo: there is a question of upgrades for people who have modified the profile in /etc and what to do with their changes. do we throw them away and just comment in the bug? do we try to migrate? etc
<zyga> jdstrand: I like the local idea, where would that other file be?
<zyga> mvo: yes, I'm afraid so
<zyga> jdstrand: yes, that is thorny
<zyga> jdstrand: my gut says the benefit outweights the costs and I would just migrate it and do a debconf prompt instructing them to migrate to local mechanism if we detect a modified conffile on migratoin
<zyga> *migration
<jdstrand> zyga: what other file? the main profile is wherever you decide. then it uses '#include local/snap-confine' (or whatever). local/ is relative to /etc/apaprmor.d, so /etc/apparmor.d/local. The include file could be an absolute path. eg, #include "/path/to/thing/to/include"
<zyga> jdstrand: I must have misunderstood something, I thought we'd axe the /etc/apparmor.d file and place it in /var/lib/snapd/apparmor/profiles (or similar) and in that, immutable, new file we'd offer an include to somewhere writable
<zyga> jdstrand: and since the new profile would always update we'd have to agree on a fixed location where local configuration can still be made
<jdstrand> zyga: that is this idea. /etc/apparmor.d/local/snap-confine != /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> jdstrand: ah, I see
<zyga> jdstrand: makes sense
<jdstrand> zyga: if you don't like /etc/apparmor.d/local/snap-confine, then use an absolute path include
<zyga> no, I was just confused about the detail, it's fine
<jdstrand> but /etc/apparmor.d/local is an established mechanism, so it is perhaps the right location
 * zyga sighs at 2fa that he left at ome
<zyga> and about forgetting "h" due to spanish influence
<jdstrand> the nicest thing to do would be to detect additions to /etc/apparmor.d/usr.lib.snapd.snap-confine.real and plop them in /etc/apaprmor.d/local/snap-confine
<zyga> mvo: I cannot join the stand-up
<jdstrand> hehe regarding 'h'
<zyga> I don't have my token with me :/
<mvo> zyga: no worries
<zyga> mvo: maybe I could on m phone, one sec
<zyga> nope
<zyga> same 2fa
<zyga> well
<zyga> sorry
<zyga> mvo: my update for today: investigating the lock issue, testing and experimenting with those snaps in different environments
<mvo> zyga: thanks!
<zyga> mvo: confirmed with juju team that the snap works ok normally, doesn't run inside docker (runs alongside)
<zyga> mvo: drawfted two branches, the one for dpkg-new detection and a small one on top for did-re-exec detection
<zyga> mvo: I need to test a suse PR that fixes one last thing we wanted to do to enter factory (postrm/purge script)
<zyga> mvo: and that's pretty much it
<zyga> mvo: I looked at your branch from last night but I didn't push it forward yet
<mvo> zyga: I did some small tweaks to my seccomp-bpf branch but still plenty of room for improvements
<mvo> zyga: thanks for the update
<zyga> mvo: yes, I want to iterate on it but it has lower priority than this work for now
<zyga> mvo: please let me know how to proceed on the extra error report data
<zyga> mvo: I'm happy to do everything just let's agree on what
 * zyga takes a brief break
<mvo> zyga: md5sum I think we want
<mvo> zyga: i.e. if we have a dpkg-new file we want a md5sum
<mvo> zyga: otherwise I agree with you, nothing is really important and we can iterate later
<zyga> mvo: OK
<zyga> mvo: I'm on this
<zyga> mvo: thank you!
<mvo> zyga: thank you
<mvo> zyga: and then we need to explore what to do to stop making snap-confine.real a conffile
<mvo> zyga: or we just ref it everytime we change it ;) snap-confine.1
<mvo> .2
<mvo> etc
<zyga> mvo: haha, and endure the eternal conffile migrations in the maintscripts :)
<zyga> mvo: but I think this is the path forward to ensure sanity
<zyga> (not the maintscript, just moving away from /etc)
<zyga> plus
<zyga> mvo: one less file in /etc :D
<mvo> exactly
<pedronis> niemeyer: this is what we concluded IÂ think about status codes:  https://forum.snapcraft.io/t/numeric-http-status-codes-vs-http-status-constants/860
<NicolinoCuralli> hi all: classic-support interface is for ubuntu-core or classic?
<pedronis> NicolinoCuralli: it's for the "classic" snap  only, used to have a classic enviroment on Ubuntu Core
<jdstrand> NicolinoCuralli: 'classic' is unfortunately super overloaded. that is only for the 'classic' snap
<NicolinoCuralli> oki
<NicolinoCuralli> thanks a lot
<pedronis> it's not used on classic system or by classic confinement snaps
<NicolinoCuralli> ok: i understand it
<pedronis> and yes classic is quite the overloaded term these days
<jdstrand> :)
<pedronis> we should usually add a 2nd word there I suppose as I did here, unless the context is super clear
<jdstrand> all those terms try to communicate something in the same mental area ('old world usage patterns) but it gets a bit difficult to talk about the different technologies for all the different angles
<jdstrand> pedronis: indeed
<pedronis> jdstrand: niemeyer: maybe we should have a "The meanings of classic"Â forum post
<ogra_> lol
<niemeyer> pedronis: That's a good idea actually
<ogra_> that will end like a philosophical pamphlet :)
 * ogra_ thinks we should rename one of the "classics" ... 
<niemeyer> pedronis: Or perhaps "The meaning of classic"
<niemeyer> pedronis: It means just one thing really.. we just use it in several different places
<mup> PR snapd#3422 opened: tests: take into account staging snap-ids for snap-info <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3422>
<zyga> mvo: updated
<zyga> mvo: I simplified it a bit
<zyga> mvo: and the extra hashes will help in de-duplicating issues
<zyga> mvo: we'll know measure hashes of both the current and the .dpkg-new (if any) files
<zyga> mvo: so we can check which profile is really used, which will let us test my theory reliably
<zyga> mvo: I'll start the 2.26 based branches and PRs now
<mvo> zyga: thanks, if we squash the merge we can just cherry pick in 2.26 trivially
<mvo> zyga: lets use md5sum, thats the same that dpkg is using, this way we can easily compare with the dpkg metadata instead of having to unpack it
<mvo> zyga: for snapConfineProfileDigest()
<mvo> zyga: let me comment in the pR
<zyga> ahasure
<zyga> one sec
<zyga> smart idea btw :)
<mvo> zyga: thanks, one tiny bikesheed naming suggestion then its good to go
<zyga> mvo: sure, let me look
<zyga> haha, I called it like that
<zyga> but I reverted to not reflow the block
<zyga> but no worries :)
<mvo> zyga: hahaha
<zyga> I like it better this way
<zyga> mvo: tweaked
<zyga_> mvo: re, +1 if you like it, I'll work on other branches
<zyga_> mvo: when do you want to do 2.26.x today?
 * Chipaca has returned from the dentist expedition
<Chipaca> pedronis: "50 shades of classic"?
<mvo> zyga_: I'm still keen to do a 2.26.x today
<zyga_> excellent
<mvo> fgimenez: I think we have a new core in edge, could you please run the ntested test again?
<zyga_> so we do a .candidate today?
<zyga_> or beta?
<ogra_> hmm, can i force re-exec somehow to avoid ever ending up with the deb based setup ?
<zyga_> mvo: btw, you said you would cherry pick it
<ogra_> (like i can force no-reexec, just the other way around)
<zyga_> mvo: I can do that too (but feel free, just want to know if I should open brnaches)
<zyga_> ogra_: not today, no; we have a preference and we check for viability
<zyga_> ogra_: look at cmd/cmd.go
<ogra_> zyga_, i fear the docker stuff with snap-confine will only work if it is actually re-execed ...
<mvo> zyga_: probably only beta
<ogra_> which works by sheer luck because i force install the edge core now
<fgimenez> mvo: sure on it thx
<ogra_> (so i can be sure to be newer than the deb)
<mvo> zyga_: cherry pick should be fine once its in master
<ogra_> but if i wanted to use the stable core it might jump back and forth on container startup
<ogra_> (depending if the deb sanpd is newer than the one in core or not)
<pedronis> Chipaca: welcome back, we chatted in the standup about http status codes: https://forum.snapcraft.io/t/numeric-http-status-codes-vs-http-status-constants/860
<ogra_> ha!
 * ogra_ is using the snapcraft snap inside a docker container to build a snap 
<ogra_> awesome :D
<pedronis> pstolowski: btw when you have a bit of time could you finish the review/revote on snapd#3417 given what we discussed in the standup
<mup> PR snapd#3417: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <https://github.com/snapcore/snapd/pull/3417>
<pstolowski> pedronis, i approved already a few minutes ago
<mup> PR snapd#3422 closed: tests: take into account staging snap-ids for snap-info <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3422>
<pedronis> pstolowski: ah, thank you
<pedronis> IÂ missed the email
<pedronis> saw it now
<cwayne> ogra_: but was that docker container from the docker snap :p
<pedronis> pstolowski: btw, related to it, I noticed we use the defaultRetryStrategy also for download, shouldn't we use a slightly longer overall timeout there?
<ogra_> cwayne, hah, no, i dont think that will work
<ogra_> cwayne, only the docker.io deb
<cwayne> not with that attitude it won't!
<ogra_> heh
<ogra_> i need to break all confinement to make that work ... i doubt that can work with the docker snap wrapped around it
<pstolowski> pedronis, hmm, fair point, although I'd say if we timeout it's at the beginning when download is initiated usually
<ogra_> though i might .... in an insane moment ... try it :P
<pedronis> pstolowski: yes, I don't think we should make 30 mins because some snaps are big
<pedronis> just sayign it might need to be a bit more, some small multiple of the default one
<cwayne> ogra_: that's the spirit :D
<fgimenez> mvo: core-revert succeeded with latest edge core snap \o/
<mvo> fgimenez: excellent!
<fgimenez> mvo: http://paste.ubuntu.com/24738597/
<mup> PR snapd#3421 closed: errtracker: include bits of snap-confine apparmor profile <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3421>
<mvo> zyga_: looks like we need a backport of 3421 - it can not be cleany cherry picked, if you could do that, that would be great
<zyga_> mvo: absolutely, on it
<mup> PR snapcraft#1344 opened: git: don't use --remote for updating submodules <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/1344>
<zyga_> mvo: one for your consideration https://github.com/snapcore/snapd/pull/3423
<mup> PR snapd#3423: errtracker: report if snapd did re-execute itself <Created by zyga> <https://github.com/snapcore/snapd/pull/3423>
<mup> PR snapd#3423 opened: errtracker: report if snapd did re-execute itself <Created by zyga> <https://github.com/snapcore/snapd/pull/3423>
<zyga_> mvo: the backport https://github.com/snapcore/snapd/pull/3424
<mup> PR snapd#3424: errtracker: include bits of snap-confine apparmor profile (#3421) <Created by zyga> <https://github.com/snapcore/snapd/pull/3424>
<mvo> zyga_: \o/
<mup> PR snapd#3424 opened: errtracker: include bits of snap-confine apparmor profile (#3421) <Created by zyga> <https://github.com/snapcore/snapd/pull/3424>
<mup> PR snapd#3424 closed: errtracker: include bits of snap-confine apparmor profile (#3421) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3424>
<cachio> mvo, could you please retrigger the failed tests in the econnreset MP?
<zyga_> cachio: I can
<cachio> zyga_, tx
<zyga_> done
<cachio> zyga_, tx
<cachio> zyga_, could you trigger this one too?
<cachio> https://github.com/snapcore/snapd/pull/3405
<mup> PR snapd#3405: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3405>
<zyga_> done
<cachio> zyga_, tx
<zyga_> :)
<zyga_> we need a 2nd review on  https://github.com/snapcore/snapd/pull/3423
<mup> PR snapd#3423: errtracker: report if snapd did re-execute itself <Created by zyga> <https://github.com/snapcore/snapd/pull/3423>
<pedronis> Chipaca: thanks, IÂ was puzzled by the not-found change
<morphis> zyga_: btw. did you talk with anyone at suse about the global /snap dir?
<Chipaca> pedronis: blinkers on
<Saviq> kyrofa, elopio, https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=snapcraft
<cjwatson> sergiusens_: did you see the bit of my review about dropping the extra Conflicts: python3-click-cli?
<sergiusens_> cjwatson: I saw the one from around 10hs ago and pushed a revert of that, haven't seen newer comments, let me check now
<sergiusens_> cjwatson: yeah, I think I addressed your comment already, thanks for finding that slip
<cjwatson> sergiusens: you did the PkTransactionPast one but not the Conflicts
<mup> PR snapcraft#1345 opened: deltas: Improved message returned when delta is too big <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1345>
<cjwatson> I made two relevant comments :)
<sergiusens> oh, I didin't seem to notice that one
 * sergiusens goes and reads again
<zyga_> pedronis: replied to your comment
<pedronis> zyga_: ah,  I woudl return yes and no,  and rename the field , I find the "" one a bit confusing
<Facu> zyga_, you wrote the "Building the code locally" part in snapd's HACKING.md file... question: is there a way to compile it and run it *from the project dir*, not installing it in the system?
<Facu> zyga_, all I want to do is to hit staging environment with snapd for some tests
<Facu> (is there an easier way than re-building?)
<cjwatson> sergiusens: thanks, approved now.  it should be landable with bileto if you still remember how to use that :-)
<Chipaca> Facu: o/
<Chipaca> Facu: GOPATH=~/canonical/snappy go build -v -i -o /tmp/srv github.com/snapcore/snapd/cmd/snapd && sudo ~/bin/run-snapd-srv
<Chipaca> Facu: if all you're wanting to do is hit the store, that ^ does it
<sergiusens> cjwatson: I was lucky to escape it early, but I was going to ask slangasek if it was still functional and the preferred mechanism still
<sergiusens> thanks for looking
<sergiusens> I'll work on getting it in
<Chipaca> Facu: unless what you're tweaking is the client, in which case you can just go run it
<cjwatson> yeah, it's how the last version was landed at any rate
<cjwatson> I don't know if quadruple landings are a thing though, possibly not, you might need multiple MPs
<slangasek> bileto is in maintenance mode but still functional
<slangasek> quadruple landings should not be a thing, the multiple-series landings have always caused a bit of friction against the archive and I think we've done away with them post-zesty
<cjwatson> righto
<cachio> zyga_, do you know if it is possible to see the all the ci results for a specific branch?
<cachio> in travis
<zyga_> cachio: yes, always if it was tested
<zyga_> cachio: which branch are you thinking about?
<zyga_> pedronis: sure, I will make the changes, thank you for clarifying that
<cachio> zyga_, sergiocazzolato:tests-fix-upgrade-basic
<zyga_> Facu: yes, although there are many loopholes and complexity
<zyga_> Facu: which branch do you want to try?
<zyga_> Facu: depending on where the changes are you need to do more or less things
<Facu> zyga_, just master, but wait, Chipaca is currently helping me (and teaching me some go stuff)
<Chipaca> mbuahaha
<zyga_> Facu: you can just switch to edge :)
<zyga_> Facu: use the edge channel luke ;-)
<zyga_> Facu: sure I saw, I just reply in the backlog order
<Facu> zyga_, snapd from edge (snap install snapd --channel=edge) uses staging?
<zyga_> Facu: ah, staging store?
<pedronis> Facu: no
<zyga_> nope
<Facu> ok
<sergiusens> slangasek: cjwatson: there seems to be no series registered for click to land in older releases, should I get this in artful with bileto and go the traditional debsource route for the SRU?
<cjwatson> sergiusens: that's fine by me
<Facu> zyga_, for the record, all I needed to do to run snapd against staging (plus some debugging I wanted) is
<Facu> sudo systemctl stop snapd.service snapd.socket
<Facu> sudo SNAP_TESTING=1 SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 SNAPPY_USE_STAGING_STORE=1 /usr/lib/snapd/snapd
<zyga_> :-)
<zyga_> nice
<Facu> zyga_, ...which doesn't really work, because you can not cross assertions from prod and staging, I'm currently learning
<Facu> zyga_, so or you start a VM that never used prod before, or you clean up somehow what snapd has stored
<zyga_> Facu: ah, indeed
<zyga_> Facu: test builds use different key
<Facu> zyga_, I'm not using a test build, but the system's snapd
<zyga_> right
<zyga_> pedronis: updated
<zyga_> pedronis: I'll land it and cherry pick for 2.26 when it goes green
 * zyga_ works on snap-confine patches now
<zyga_> mvo: backport https://github.com/snapcore/snapd/pull/3425
<mup> PR snapd#3425: errtracker: report if snapd did re-execute itself <Created by zyga> <https://github.com/snapcore/snapd/pull/3425>
<mup> PR snapd#3425 opened: errtracker: report if snapd did re-execute itself <Created by zyga> <https://github.com/snapcore/snapd/pull/3425>
<mup> PR snapd#3425 closed: errtracker: report if snapd did re-execute itself <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3425>
<jjohansen> zyga_: no, that fix is not in any ubuntu kernel, it was done yesterday
<zyga_> jjohansen: aha, interesting!
<zyga_> jjohansen: thank you!
<zyga_> jjohansen: btw, not sure if you noticed but we ran into an apparmor oops, just trying to recall who saw this :/
<zyga_> ogra_: was that you/
<mvo> zyga_: me
<jjohansen> mvo: bug?, oops trace back? anything for me to look at?
<zyga_> mvo: ah, thank you :)
<niemeyer> Folks, I got a heads up from Linode that they've blocked our use of the API due to volume
<niemeyer> Expect broken tests until I sort that out
<zyga_> niemeyer: thanks for the heads up!
<mvo> jjohansen: let me search, I only have the bits that I gave to zyga_ the other day, it was actually me using seccomp inappropriately so it may well be not a real apparmor bug
<zyga_> niemeyer: volume of calls we make?
<zyga_> ah
<mvo> jjohansen: http://paste.ubuntu.com/24724666/ this is what I have, I think prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)  = 0 was actually the problem, i.e. I was incorrectly using that
<zyga_> jjohansen: I recall now
<niemeyer> zyga_: Yep, spread
<zyga_> jjohansen: aa change onexec would fail and we'd oops
<zyga_> jjohansen: but looks like a bug in the kernel
<jjohansen> mvo, zyga_: ah yep the kernel I built yesterday should fix that  http://people.canonical.com/~jj/linux+jj/
<mvo> jjohansen: great, thank you - that is all I have encountered
<niemeyer> I guess I'll need to write a new spread backend to a cloud where 80 machines isn't much.. :(
<cachio> niemeyer, are you gonna try with aws? or it is much expensive?
<niemeyer> It is more expensive and has other associated issues in terms of book keeping
<niemeyer> But everything may be workarounded
<cachio> rackspace is another good alternative
<niemeyer> On Linode we get a machine descent enough to run our tests for a whole month for 10 bucks
<cachio> not sure about the cost
<niemeyer> If I have to leave a non-mainstream provider, I'm not going anywhere else but AWS or GCE
<zyga_> niemeyer: heh, that's pretty depressing
<zyga_> niemeyer: did we abuse the API somehow?
<niemeyer> Where I'm sure we'll be small bees
<niemeyer> zyga_: We did in their opinion
<zyga_> niemeyer: by creating/destroing machines?
<niemeyer> zyga_: Yep
<niemeyer> zyga_: It's about volume
<niemeyer> zyga_: They're being dumb.. it was fine when we had 20 machines
<zyga_> niemeyer: interesting, I wonder if that has greater impact than just running a vm 24/7
<zyga_> niemeyer: one more option, standardize on qemu
<niemeyer> zyga_: Now that we have 80, it's 4 times as much
<niemeyer> From the same account
<zyga_> niemeyer: get a few huge VMs
<zyga_> niemeyer: and let them proxy our spread protocol
<zyga_> niemeyer: so instead of hitting linode
<zyga_> niemeyer: we'll hit any host with a qemu helper
<zyga_> niemeyer: you already have the backend written
<zyga_> niemeyer: and it's just the proxying that needs doing
<zyga_> +/- details ;-)
<niemeyer> zyga_: Heh.. it's just code that needs doing, yes.. like anything else
<niemeyer> zyga_: Part of the goal here is for the system to sustain itself without maintenance
<niemeyer> Almost entirely, at least
<zyga_> niemeyer: or do what I did, I bought a 24 thread workstation with 48 GB of ram for a few 100 on ebay (not for me)
<niemeyer> Nobody babysits our machines on a daily basis
<zyga_> niemeyer: there is no cloud, it's just someone's computer :D
<niemeyer> zyga_: This needs _maintenance_
<zyga_> niemeyer: yes that's true :/
<niemeyer> zyga_: I get news about broken hardware on those 80 machines all the time
<zyga_> broken hardware?!
<niemeyer> It's a non-issue for us
<niemeyer> Yep
<zyga_> as in virtually broken virtual hardware or really broken linode metal?
<niemeyer> zyga_: Hardware breaks surprisingly often when you get to high numbers
<zyga_> wow, linode needs to dust their cloud more often
<cachio> heheh
<zyga_> or use less soap and water :D
<niemeyer> zyga_: Again, this is *normal*
<zyga_> interesting, I never ran anything of this size
<zyga_> and actually this is tiny size by cloud standards
<niemeyer> zyga_: Think about percentages
<zyga_> I can recall one email I got from my provider when they just told me that they migrated my VM from data centre to data centre for maintenance, without stopping the VM
<zyga_> but since the performance was slower for that minute it took, they notified me
<zyga_> (and two months in advance AFAIR)
<zyga_> anyway
<zyga_> sad linode day :-(
 * zyga_ hugs niemeyer for the amazing spread that lets us do stuff we couldn't dream of before
<niemeyer> Yeah.. I'm not super optimistic]
<zyga_> remember when every test was written in go and mocking?
<niemeyer> Yeah, I predict a weekend lost here
<zyga_> and we had x50 fewer of those
<zyga_> mvo: ^^ you may need to merge manually for the release
<zyga_> niemeyer: what's the chance of using canoincal cloud for that?
<zyga_> niemeyer: could we get ~100 machines that just work?
<niemeyer> zyga_: Pretty low.. we want completely open firewalls
<zyga_> ah, indeed
<zyga_> well
<zyga_> maybe google or azure :)
<zyga_> I don't know their pricing though
<zyga_> but yeah, more coding on the glue
<zyga_> maybe write a blog post
<zyga_> about linode being terrible and ugly and unfair
<zyga_> and snapd needing a better cloud provider
<zyga_> maybe someone will notice
<zyga_> (we can help spread the news)
<cachio> I used to create up to 1000 machines for performance test in aws
<zyga_> niemeyer: out of curiosity, what is the limit (numeric) that we exceeded?
<cachio> and I never had an internet problem or any other kind of problem
<genii> performance test/botnet
 * genii ducks
<niemeyer> zyga_: None.. "you seem to be creating problems so we blocked you"
<niemeyer> cachio: To be fair, AWS doesn't even let us create 1000 machines in general..
<niemeyer> cachio: We had to get a special permit to do that when we needed that once
<Chipaca> niemeyer: have you looked at ovh at all?
<cachio> niemeyer, well, I asked for that
<Chipaca> they were slightly mean but i think we worked through it
<cachio> by defaul there is a limit abou 100 or something like that
<cachio> the main problem is that I was expensive
<cachio> it was expensive
<cachio> 80 instances 8 hours/day 2vcpu 4GB ram = $917 monthly
 * zyga_ dreams about those ~200 core workstations
<niemeyer> cachio: Yeah, so it's not quite fair to say it was painless :)
<niemeyer> Ban lifted..
<niemeyer> Still discussing details, but it should be unblocked righ tnow
<Chipaca> ogra_: http://biosrhythm.com/?page_id=1453
 * zyga_ has to break now
<mup> PR snapd#3423 closed: errtracker: report if snapd did re-execute itself <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3423>
<mup> PR snapd#3426 opened: release: 2.26.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3426>
<jdstrand> niemeyer: oh my! (blocked our use cause of volume). godspeed
<niemeyer> jdstrand: Yeah, apparently the API is not very used there..
<niemeyer> We'll sort it out..
<niemeyer> Found someone more accessible and happy to discuss the use case
<azubieta> hello, I'm having some issues on making an snap that uses kf5-frameworks as a part can someone help me?
<Hilikus> hello
<Hilikus> how can i enable a local terminal in my raspberry pi. i want to run an XServer in the hdmi port but by default all ubuntu core lets me do is ssh remotely, where i get permission problems trying to open the display
<nacc> Hilikus: not sure i understand what you mean by 'local' terminal? I'm guessing that by default there is no x server running, or it's confined possibly?
<Hilikus> nacc: I installed a chromium package that comes with an X server, but because ubuntu core only lets me connect via ssh, i have the extra problems of authenticating. if i can connect to a local tty instead of via ssh then maybe i'll have better luck
<Hilikus> basically, i don'
<nacc> Hilikus: 'extra problems of authenticating'? you mean you can't ssh in?
<Hilikus> 't want to deal with the remote XServer issues
<Hilikus> no, i can ssh just fine
<Hilikus> but i can't forward the raspberry X session to my desktop
<nacc> Hilikus: i assume you mean you did `ssh -X` ?
<Hilikus> yes
<Hilikus> but even if that worked, i need to be able to show the X session locally, via the HDMI of the raspberry + with a local keyboard and mouse, that's why i want to enable a local terminal. every other server i've used in my life has local terminals but ubuntu core only has this message (without prompt) saying to ssh
<nacc> Hilikus: i'm fairly sure by default core doesn't have any ttys (or gettys) running
<Hilikus> i think so too. but do you know how to enable one? is there something i could install?
<Hilikus> or do you have another idea how to get a local graphical session with a browser? it doesn't have to be XServer, mir o wayland would be ok. i just need a browser in a local session
<nacc> Hilikus: I don't know, sorry
<Hilikus> ok. thank you anyway
<nacc> Hilikus: once you ssh in, do you see any X server running? `ps aux | grep X`
<Hilikus> no
<nacc> Hilikus: what snap did you install (what name)?
<Hilikus> https://code.launchpad.net/~osomon/+snap/chromium-snap-beta
<nacc> Hilikus: it looks like there are a lot of interfaces it depends on, are they all connected?
<nacc> Hilikus: something like `snap interfaces`
<Hilikus> mm actually no
<nacc> Hilikus: this is a gray area for me -- i'm not sure running a full desktop is really the target, but it might be possible (I have no idea actually)
<Hilikus> i didn;'t think iof that
<nacc> Hilikus: you might need to connect the various plugs if they weren't connected, so that the snap can run
<Hilikus> i don't want a full desktop. this is for a kind of kiosk, i do still need a graphical interface
<nacc> Hilikus: something like `snap connect <snap>:<plug>`
<nacc> Hilikus: oh ok, based upon the marketing on the core page (digital signage), that certainly seems likeit should be possible, but I don't know any of the details :/
<nacc> Hilikus: actual snappy folks should be around at some point, though :) you can ask again -- or maybe post on the forum?
<Hilikus> ok, then for sure this won't work. your points made me realize this package wants to plug to unity7, not only X, so this package is for a hybrid system
<nacc> Hilikus: yeah, i would expect chromium to be for the full fledged browser (meaning desktop integrated)
<nacc> Hilikus: for kiosk, you want to basically write your own snap that is just your kiosk'd application (I think)
<nacc> Hilikus: or did you mean your kiosk'd appliation is on a website?
<Hilikus> yes, on a website
<nacc> Hilikus: ah ok -- I don't immediately see any standalone browsers via `snap find`, but it might be worth looking
<Hilikus> ive been looking for a week now with no luck :(
#snappy 2017-06-02
<morphis_> Pharaoh_Atem: ping
<zyga> good morning
<pstolowski> morning
<fgimenez> good morning mvo, i saw your post on the forum about 2.26.4 and have already started the beta validation, will let you know how it goes
<fgimenez> hey pstolowski
<mup> PR snapcraft#1327 closed: tests: small updates for manual kernel tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1327>
<mup> PR snapcraft#1341 closed: Release changelog for 2.30.1 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1341>
<mvo> fgimenez: great, thank you
<fgimenez> pstolowski: i had a chance yesterday to have a look at the snapctl test issue, fwiw it looks to me that we are disabling autorefresh before putting the outer binaries in the core snap, IMO this https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L139 shoulb be done after the update_core_snap_for_classic_reexec call, anyway that only explains the warning messages we get and not the actual error
<zyga> mwhudson: hey
<zyga> mwhudson: still around by any chance?
<pstolowski> fgimenez, hi! yes, i saw this and yes, it's jut the warning. it's ok
<zyga> mwhudson: https://forum.snapcraft.io/t/build-failure-for-2-26-4-on-artful-on-arm-arm64/866 does this error ring any bells?
<fgimenez> pstolowski: yep, if i change the order and reexecute the test i still get the same error, you are probably aware but putting in place some debug info it seems that it keeps failing after "snap set core refresh.schedule=Sun@12:00-14:00" but the actual failure happens in the daemon when it gets "get service.ssh.disable" (not sure why it gets this after trying to set another property), in that case the cookieID received is empty
<pstolowski> fgimenez, is this with all my changes from that branch, or did you comment the SNAP_CONTEXT compatibility line out?
<fgimenez> the context seems to be correctly set map[yltR4VFx0ryHTjNpvGVHmvHbpvsg47sv5M7S7JtmTtkm:core]
<fgimenez> pstolowski: with all the changes in your branch and removing the compatibility line
<mup> PR snapd#3427 opened: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427>
<fgimenez> pstolowski: probably that "get service.ssh.disable" comes from the core's configure hook itself https://github.com/snapcore/core/blob/master/hooks/configure#L111
<pstolowski> fgimenez, yes, this failure is expected then without that compatibility line; lack of this line causes all hooks to fail
<pstolowski> fgimenez, how can I test all possible scenarios (with re-exec disabled)? is setting this env var before running spread locally with qemu enough?
<fgimenez> pstolowski: yes, just export SPREAD_SNAP_REEXEC=0 before executing, there's also export SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0 if you want the core snap to be untouched, and also SPREAD_CORE_CHANNEL for selecting the channel from which core is going to be installed
<pstolowski> fgimenez, nice, thank you. do we have any tests that need to be run manually (e.g. expensive tests?) and are not normally executed on travis?
<fgimenez> pstolowski: anyway, executing from the branch will give you always an outer version higher than the inner one and the reexec is not going to happen, it would be better IMO to use the external backend and execute against a running machine
<fgimenez> pstolowski: yes, we are triggering manually tests executed on ubuntu-core systems (this will be done soon on jenkins for most of the archs)
<pstolowski> fgimenez, yes, i understand the re-exec will not be triggered becuase of that. what do you mean with 'external backend and execute against a running machine'?
<fgimenez> pstolowski: the external backend lets you connect to an external machine and excute the tests there https://github.com/snapcore/snapd/blob/master/tests/external-backend.md, but if you need your changes in places that wouldn't help (or putting your changes in places could be hard)... i think that just export SPREAD_SNAP_REEXEC=0 is enough
<mup> PR snapd#3417 closed: httputil,store: extract retry code to httputil, reorg usages <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3417>
<pstolowski> fgimenez, is there any semi-automatic way of creating a core image with my changes in it, and then simulatic a system with old binaries + this new core and re-exec disabled?
<pstolowski> s/simulatic/simulating/
<zyga> morphis_: you got reply on the factory ML
<zyga> morphis_: I spoke with jjohansen yesterday and upstreaming is his sole focus
<zyga> morphis_: but let's make it clear that snapd can work in development mode without strong security, and it is no worse than appimage so we'd like to pursue on all fronts (kernel and userspace)
<fgimenez> pstolowski: not that i know, you could begin with a image generated with ubuntu-image, copy the binaries built from your branch to it and bind mount them, run the tests and find a way to re bind mount them early enough if any of the tests you run involve a reboot :)
<morphis_> zyga: I've answered already
<morphis_> zyga: but feel free to reply as well
<fgimenez> pstolowski: not sure if just the binaries would include all your changes though
<zyga> morphis_: thank you!
<morphis_> zyga: you submitted all PRs we talked about yesterday?
<zyga> morphis_: no, working on them
<morphis_> ok
<zyga> morphis_: I've started with a regression test before I start to meddle there
<morphis_> zyga: can you note them on the forum topic once done?
<zyga> morphis_: then the refactor
<zyga> morphis_: and then comments
<zyga> morphis_: on https://forum.snapcraft.io/t/including-snapd-in-the-opensuse-factory-branch/863/5 ? yes sure!
<morphis_> yes!
<morphis_> thanks
<zyga> I commented briefly just now but I will refer to each PR as they show up
<pedronis> zyga: have you seen this   https://forum.snapcraft.io/t/problem-with-installing-canonical-livepatch-service/850 (it doesn't seem specific to livepatch)
<zyga> pedronis: looking
<zyga> pedronis: thanks, I'll handle that
<jjohansen> zyga: not only are we upstreaming, we have made the switch to an upstream first policy. So we won't get in this position again
<pstolowski> fgimenez, with SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0, it's expected some tests to fail (such as reexec-test), right?
<mup> PR snapcraft#1346 opened: Multi arch build deps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1346>
<fgimenez> pstolowski: if you don't combine it with SPREAD_SNAP_REEXEC=0 yes, we use it for instance in SRU validations https://github.com/snapcore/spread-cron/blob/snapd-xenial-sru/run-checks
<zyga> jjohansen: thank you for re-affirming that! :)
<pstolowski> fgimenez, i see, thanks
<mup> PR snapcraft#1347 opened: cli: do not duplicate errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1347>
<mup> PR snapcraft#1348 opened: Foreign arch src <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348>
<sil2100> Hello! I have some questions regarding classic confinement
<ogra_> it is awful, dont use it :P
<ogra_> sil2100, i guess caused by my bug ?
<sil2100> ogra_: yeah, I just don't seem to understand classic confinement at all
<ogra_> sil2100, it is like a deb just differently packaged in the end
<sil2100> ogra_: as per your bug, for instance, libparted is present in the snap but it's just not visible
<sil2100> ogra_: as everything seems to just look for the libraries in the standard directories, not in the snap ones
<ogra_> sil2100, righrt, you would need to hack up wrappers that make the shipped libs used in LD_LIBRARY_PATH
<sil2100> ...
<sil2100> This is just silly
<ogra_> (or just switch back to proper strict confinement ;) )
<sil2100> Yeah, I seriously don't think that doing wrapper hacks is what I would like to have, I guess barry wasn't aware of that
<ogra_> it is for special cases where snaps cant really achieve their goal with any of the existing interfaces
<ogra_> editors that need access to all of the system for example ...
<ogra_> or compilers
<ogra_> by default a classic snap will simply get executed like it was a deb ... using the whole rootfs as is ... if you want your libs found you need to specifically mangle LD_LIBRARY_PATH ... prehaps also the python path etc
<sil2100> That's a bit too simplistic for our usecase, I'll bring this up at our sprint next week
<ogra_> this is alsoo one of the reasons classic only works on ubuntu based distros atm ... else you cant be sure the paths are correct
<sil2100> I knew about having access to the whole system, yes, but I thought it's still working similarily to all other snaps by mangling the library paths to point at the snap as well
<ogra_> sil2100, http://paste.ubuntu.com/24746613/ is an example
<Chipaca> zyga: an apparmor DENIED from core's configure related to mounting etc/ssl is probably version skew, yes?
<zyga_> hmm
<zyga_> let me check but I think so
<zyga_> yes
<zyga_> apparmor mismatch vs binary
<Chipaca> ok
<zyga_> hacking or production?
<Chipaca> (i always run snapd with _TESTING so you won't see this in errors)
<Chipaca> well, always, always on this machine
<zyga> hmm
<zyga> dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere
<mup> PR snapcraft#1349 opened: Clarify wording of cross-compilation unsupported error <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1349>
 * zyga_ has some hectic stuff at home
<zyga_> we're moving TOMORROW
<pstolowski> zyga, back to Poland?
<Chipaca> zyga_: <gif of that guy waving his arms around in panic>
<zyga_> pstolowski: yes
<pstolowski> good :)
<zyga_> pstolowski: we just ordered the transport as it is in the town next to us and the price is very competetive
<zyga_> Chipaca: that'd be my wife
<Chipaca> :-)
<zyga_> we have to pack everything that won't fit into the car now
<zyga_> like ... now
<zyga_> well
<mvo> zyga_: woah, goooooood luck!
<pstolowski> fgimenez, i found out I need compatibility fix also in snap-confine (and in snapctl as discussed yesterday in standup), otherwise those other combinations we test are failing on my new spread test which checks the new feature
<kunal> Hello community
<ogra_> hey kunal
<kunal> I have a problem... I am trying to build a snap for python script / app
<kunal> I have read alot of documents but still unable to figure out the solution for some problems
<kunal> dear community, please help
<kunal> I need your help
<zyga_> pstolowski: apart from the fix, how will people upgrade or downgrade?
<zyga_> pstolowski: we learned the hard way that changing formats in snap-confine is not nice or easy
<kunal> I want to know how to add data folder in snap for my  python app because it requires data to run. And all the data is collected in a single folder
<zyga_> kunal: read-only data that is distributed with your snap?
<zyga_> kunal: just add a part that contains this data
<ogra_> have a look at the dump plugin
<kunal> how to add it in the snap folder
<kunal> I am sorry to disturb you by asking such kind of stupid questions, but I have already tried that dump plugin and unable to understand how to add the folder
<zyga_> kunal: no worries, look at the dump plugin and experiment
<pstolowski> zyga, for the new feature (snapctl usable not only in hooks) they need latest everything. the second change related to this feature is reanaming of SNAP_CONTEXT var to SNAP_COOKIE. I made compatibility fixes to basically set both and check of existience of either, so that hooks are not affected if re-exec is disabled. does that answer your question?
<zyga> pstolowski: can people revert from the new feature back to previous release?
<zyga> pstolowski: I'm mainly asking if this is a flag day change or not
<kunal> Folder name is dataFolder. So where should I place my dataFolder. Should it be there in src folder or in the top or parent folder
<zyga> kunal: in your source tree it can be anywhere
<zyga> kunal: but your snapcraft.yaml must say that it must be installed into the snap
<zyga> kunal: ogra_'s advice was correct, look at examples of dump plugin
<zyga> kunal: also if this is a python appication you should be able to install the data throuh python
<zyga> kunal: good luck
<kunal> Thanks. But how to point the folder in yaml file so that it can be included in snap
<zyga> kunal: using a part and the dump plugin, is one way, there are others that may be more straightforward, depending on other parts you use
<pstolowski> zyga, yes, with the compatibility workarounds I made it's ok to revert. of course a snap which uses the new functionality and calls snapctl from an app will fail and not be able to use the new featue
<zyga> pstolowski: that's fine
<zyga> pstolowski: we have some tests missing in revert
<zyga> pstolowski: when is this scheduled to land? 2.27?
<pstolowski> zyga, I think it would be pretty useful to have a matrix of all upgrade (and revert) paths that takes snapd + snapctl + snapconfine into account.. i find it difficult to think of these scenarios. and it seems that our recent issues show it's generally hard not to forget about something. perhaps we could have such a matrix as a template to fill in when a new feature is proposed
<pstolowski> zyga, not scheduled really, but soon once the rename of env var is addressed
<kunal> Dear Sir,  should I write plugin: dump source: .
<kunal> What should be the destination if I want to keep executable and data folder at the same place so that it can use it as per reference in python script
<zyga> kunal: https://snapcraft.io/docs/reference/plugins/dump
<zyga> kunal: but if you have a correctly written python app you don't need dump
<zyga> kunal: your python's setup.py should install data
<kunal> how to do it, dear Sir, in setup.py to instruct system to install data files properly at desired place. Please help sir
<zyga> kunal: this is widely documented on python setuptools project, please look there
<zyga> kunal: if you have a free software project or wish to share your setup.py that might help
<zyga> kunal: but I cannot help you in detail today (look above, I'm moving my life to another country)
<zyga> kunal: needles to say there are 100s of examples of python projects shipping data files around
<zyga> kunal: and accessing them irrespectively to how they are installed (which is a nice advantage)
<zyga> kunal: I recommend you to look that up
<kunal> Thank you so much dera Sir. Thanks alot for giving me your precious time to guide in right direction. Thanks alot dear sir!
<zyga> good luck :)
<zyga> and note that you may also try the forum (forum.snapcraft.io) as there are plenty of people snapping software that can help you out
<zyga> and it works somewhat better across timezones than IRC
<zyga> many of the snapcraft developers are in the US timezne
<kunal> Thank you so much sir. Thanks alot.....
<kunal> Sir, One last question, Please tell me the location where the python executable script or app be installed in snap so that I may take proper reference .
<zyga_> kunal: it's variable at runtime, the snap content is mounted in some place and you can look that up via the $SNAP environment variable
<kunal> so how will it look for the data folder. Will the data folder be also variable at runtime along with its executables
<zyga_> what is "the data folder?"
<kunal> Folder that contain data required by the python script at runtime
<Chipaca> kunal: for reading, or for reading and writing?
 * zyga_ hugs Chipaca
<Chipaca> zyga_: go pack :-)
<ogra_> geez, is he traveleing *again* ?
<kunal> Sir for both the purpose
<ogra_> :)
<Chipaca> kunal: is this your python code, or are you snapping somebody else's?
<kunal> My own code.
<Chipaca> kunal: and is it a daemon (a service), or is it a standalone executable?
<kunal> I wrote a piece of code used setup.py and made it work . Dear Sir, Its a standalone executable.
<Chipaca> kunal: and is this data needed across revisions? i.e. if you have revision 1, and refresh to revision 2, do you need to still have that data accessible from revision 2 as it was when last modified by revision 1?
<kunal> Yes sir
<zyga_> Chipaca: I'd not confuse this with data-common-across-revisions (remember that we copy data around so it's fine to just use $SNAP_DATA / $SNAP_USER_DATA for everything)
<Chipaca> true
<kunal> i need these data files at runtime.
<Chipaca> kunal: so, os.getenv("SNAP_USER_DATA") will give you a directory you can read and write to, which is intended for this sort of thing
<zyga_> kunal: snaps differentiate immutable "data" that is shipped with the snap and updated with the snap from the writable data (either global or per-user)
<zyga_> kunal: e.g. app icon is the former and just goes anywhere in $SNAP (into your snap image)
<zyga_> kunal: user preferences are writable and should go to $SNAP_USER_DATA
<zyga_> kunal: if you have a service it can keep its mutable state in $SNAP_DATA
<zyga_> kunal: and all of those can obviously access anything they want (immutable code and data) stored in $SNAP
<kunal> Dear sir, May I know , how to set it up to be used by script
<kunal> How should I add Data Files and Folder to this location while writing yaml file . How to point to these locations
<zyga_> kunal: if you struggle with this I'd suggest going through the snapcraft tutorial
<zyga_> kunal: as I mentioned the dump plugin is a very simple way of doing what you want
<zyga_> kunal: I also suggested that for python you may not need the dump plugin as python plugin can install both code and read-only data
<zyga_> kunal: as for writeable data your application must create it relative to the directory pointed by the $SNAP_DATA or $SNAP_USER_DATA environment variables
<zyga_> kunal: I suggest that you install hello-world
<zyga_> kunal: and play around in the shell, look at where those variables point
<zyga_> kunal: good luck :)
<kunal> Ok sir. Thanks. Now every doubt is clear. Thank you so much sir. and thanks community ... Open Source Community . Thanks alot
<mup> PR snapcraft#1334 closed: tests: use the fake apt cache in deb unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1334>
<mup> PR snapd#3428 opened: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428>
<zyga_> jdstrand: ^^
<zyga_> morphis_: ^ first PR
<morphis_> zyga_: nice!
<Son_Goku> zyga, morphis_, for snapd 2.27, I'm considering flattening the packaging some more in Fedora
<Son_Goku> the original reason I kept snap-confine and snapd separate was because there was a separation of C and golang code
<Son_Goku> but as zyga rewrites more bits from C to Go, it makes less sense
<morphis_> Son_Goku: you mean droping the snap-confine package?
<Son_Goku> yes
<morphis_> +1
<morphis_> Son_Goku: btw. if you submit those changes first upstream we can review them together
<morphis_> want to do the same with the suse bits in the future
<Son_Goku> SUSE already works this way
<morphis_> it doesn't
<Son_Goku> it doesn't generate a snap-confine subpackage
<morphis_> will still maintain the real .spec file on OBS and have no backported a few changes
<morphis_> ah, we're talking about different things :-)
<Son_Goku> also, the SUSE changes I will submit to OBS first
<Son_Goku> there's no value in doing it in snapd git
<Son_Goku> as it does no testing of packaging
<morphis_> there is, there we have the entire test suite running
<zyga_> Good idea, what do you have in mind specifically?
<Son_Goku> not helpful when the goal is to change the snapd packaging
<morphis_> Son_Goku: we have such upgrade tests for .deb
<Son_Goku> I'm not touching the debian crap
<morphis_> that is not what I mean
<Son_Goku> it's impossible to figure out what that stuff even does
<Son_Goku> look, my fixes for the SUSE spec are small things to enable some of the tests that are already enabled in the Fedora package
<morphis_> Son_Goku: I simply mean we have an entire spread test suite which verifies a lot of things and once the Fedora spread setup lands you can easily craft your own rpm upgrade tests
<morphis_> Son_Goku: great, IMHO it would make sense much easier if we keep the snapd git repo the central place for the suse, fedora, deb packaging bits
<Son_Goku> morphis_: I'm not worried about Fedora upgrade tests, and I'm not even sure I'm going to do it yet
<morphis_> we can then push from there to fedora/obs/..
<Son_Goku> hardly
<Son_Goku> first of all, for that to be possible, we need the first class packaging tests for fedora, suse, etc.
<Son_Goku> we don't yet
<Son_Goku> second, snapd git is BROKEN for all distributions except Ubuntu
<Son_Goku> and I don't foresee that getting fixed soon
<Son_Goku> maybe in 2.28
<Son_Goku> which is a couple of months out
<morphis_> Son_Goku: what is broken in master?
<Son_Goku> seccomp, for one
<Son_Goku> unless a proper fix was merged in recently
<morphis_> what exactly do you mean?
<Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd-2.26.1-interfaces-seccomp-allow-bind-for-Fedora.patch
<Son_Goku> that ^
<morphis_> Son_Goku: you saw https://github.com/snapcore/snapd/pull/3394 ?
<mup> PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3394>
<Son_Goku> well, no
<morphis_> so what else is broken? :-)
<pedronis> mvo: should snapd#3446 be merged?
<Son_Goku> I guess at that point nothing that isn't already broken
<Son_Goku> I'm also not doing the golang flags override in Fedora
<morphis_> which one do you mean?
<Son_Goku> https://github.com/snapcore/snapd/pull/3365/commits/4942a9f9e7c570a44b554d8cc924c9343331ca16
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<pedronis> mvo: sorry, should snapd#3426 be merged?
<mup> PR snapd#3426: release: 2.26.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3426>
<mvo> pedronis: yes
<morphis_> Son_Goku: then you can't drop that single patch, but you know this is a bug only on F25 which is coming from the rpm macros, right?
<Son_Goku> I'm aware
<morphis_> good
<Son_Goku> if you want, you can switch spread to fedora-26
<Son_Goku> then you can drop that
<morphis_> we will add a f26 instance too
<morphis_> Son_Goku: we could make this conditional for f25 too if you want
<Son_Goku> it'd be F25 and lower, actually
<Son_Goku> but yes
<morphis_> yes
<morphis_> Son_Goku: it's better than keeping this libtool patch
<Son_Goku> 0%{?fedora} && 0%{?fedora} < 26
<Son_Goku> meh, the libtool patch is easy to rebase
<pedronis> fgimenez: snapd#3414 has 2 +1 but the spread tests have failed
<mup> PR snapd#3414: tests: show available entropy on error <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3414>
<morphis_> it is, but it separates us from what happens in master
<morphis_> however if you want to keep it I am fine
<morphis_> we should just try to avoid that snapd git and fedora git get out of sync for the .spec file
<morphis_> as as soon all changes for the spread setup land developers will be required to touch the .spec file too
<Son_Goku> you think they will?
<morphis_> otherwise CI will break :-)
<Son_Goku> I'd be surprised to see mvo generating changelogs for the spec files in parallel to the debian/changelog file
<morphis_> Son_Goku: I am not talking about changelogs
<morphis_> but all the other packaging bits
<Son_Goku> I know
<Son_Goku> but it'd be surprising if that happened too ;)
<pedronis> mvo: also snapd#3413 could go in with a 2nd pass from you (if the tests pass)
<Son_Goku> I'd initialize the repository with tito if tito supported spec files in subdirs :/
<mup> PR snapd#3413: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3413>
<morphis_> zyga_: joining us?
<fgimenez> pedronis: thx, looking
<fgimenez> pedronis: yes, not related to this PR but we are getting quite a few errors related to reexec lately "re-exec disabled by user" https://travis-ci.org/snapcore/snapd/builds/237854333#L1281
<pedronis> some test not restoring something properly and order issues?
<pstolowski> fgimenez, I've pushed one more compatibility workaround to my branch (the one mentioned earlier).
<fgimenez> pedronis: no idea, we are getting those random errors, i've checked some reexec variants and they happen after reexec0 and reexec1, maybe there's another place where this is changed
<fgimenez> pstolowski: ok thanks, btw let me know how can i help with the testing matrix you mentioned, we have some scenarios for reexec currently being executed in spread-cron and maybe we could extend them with more checks, or create new ones from scratch
<fgimenez> pstolowski: tbh i still don't understand why the test prepare doesn't fail in your when SNAP_CONTEXT is set, the inner and outer binaries should understand SNAP_COOKIE and ignore SNAP_CONTEXT, not sure what is left behind that makes things go well when SNAP_CONTEXT is set
<fgimenez> doesn't fail in your branch
<pedronis> well edge has something that understand only SNAP_CONTEXT
<pedronis> atm
<fgimenez> pedronis: but in prepare we modify the core snap and put in place the outer binaries, maybe i'm missing something
<pstolowski> fgimenez, but we modify it too late
<pedronis> fgimenez: yes, but  as pstolowski explained before we do that we do snap install --"$CORE_CHANNEL" core
<pedronis> that ends up using the snapctl from edge core I think (because of the configure hook)
<fgimenez> pstolowski: i'm trying locally modifying it before calling "snap set core.." and the error is the same
<pstolowski> yes
<pedronis> install core will call the hook already
<pedronis> not need to do a set
<pedronis> to trigger that
<pstolowski> fgimenez, yes, as pedronis says
<pedronis> which thinking of it is all a bit weird
<pedronis> anyway
<fgimenez> pedronis: yes, but that doesn't trigger the error, the errors on install seem to be ignored
<pedronis> that doesn't make sense to me
<pedronis> we don't ignore configure errors
<pedronis> afaik
<pstolowski> fgimenez, about the upgrade path matrix.. one scenario that would be nice to test is: old versions in the system, newest versions shipped with core, but re-exec disabled. the new feature will not work but hooks shouldn't break
<fgimenez> pedronis: the error happens only after snap set from what i'm seeing here, let me paste a log
<pstolowski> fgimenez, I saw prepare failed
<abeato> hey, is it possible to specify a concrete core snap revision in "snap prepare-image"? or to use a local core snap?
<fgimenez> pedronis: i'm using a prepare.sh like this one http://paste.ubuntu.com/24748009/ to make sure that update_core_snap_for_classic_reexec is called before "snap set" (around line 140)
<pedronis> abeato: yes, to the 2nd just --extra-snaps core.snap  , to the first kind of , if you have it around already and it came from the store then you can again using --extra-snap core.snap  with a recent enough snap which IÂ don't know if it's the case or not with ubuntu-image
<abeato> pedronis, ok, 2nd option is good enough for me, thanks!
<pedronis> sorry what IÂ meant the version of snap (the binary) shipped with ubuntu-image needs to be recent enough
<fgimenez> pedronis: with that in place i get a log like this after the error http://paste.ubuntu.com/24748007/ (with some additional debug info added) the configure hooks errors on install doesn't make the test to stop, the final error at the end is after "snap set core refresh.schedule="$(date +%a --date=2days)@12:00-14:00""
<abeato> pedronis, but if I use a local fine, there will be any issue with assertions? as you get some of them when dowloading from the store
<abeato> *local file
<pedronis> abeato: well, it wil be unasserted so no updates
<abeato> pedronis, ok, I see
<pedronis> unelss as I said the .snap came from the store then ubuntu-image finds the assertions anyway
<abeato> ah, good
<pedronis> but this is implemented by snap prepare-image only recently
<pedronis> and IÂ lost a bit track what is shipped where
<abeato> ok, I will just try, thanks
<pedronis> fgimenez: something seems really weird, IÂ don't understand why we don't die on that first error
<pstolowski> fgimenez, can you share the log too?
<fgimenez> pstolowski: sure, this is spread's log http://paste.ubuntu.com/24748076/
<fgimenez> and the corresponding journalctl (the other one was from a previous execution) http://paste.ubuntu.com/24748082/
<pedronis> anyway a --debug run one test should show where we die
<fgimenez> pedronis: looks like the "ERROR ignoring failure in hook "configure"" comes from https://github.com/snapcore/snapd/blob/master/overlord/hookstate/hookmgr.go#L243
<pstolowski> fgimenez, right.. i see we set ignoreerror flag for configure hook depending on some state flags
<mup> PR snapd#3413 closed: tests: fix for econnreset test checking that the download already started <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3413>
<pedronis> ah, yes
<pedronis> only for core
<pedronis> because confgure hook of core gave us so much grief trying to update core
<mvo> thanks pedronis
<pstolowski> fgimenez, ok.. i don't understand why it's failing after you copied new binaries into core
<fgimenez> pstolowski: no idea, i've double checked that the only snapctl files in the testbed are the inner and outer ones, and that the md5sum is the same
<pstolowski> fgimenez, just to double-check, what's the latest commit id from my branch you're testing? can you push the changes you made to the scripts or send me a diff?
<fgimenez> pstolowski: sure 1sec
<pstolowski> fgimenez, after standup is ok ;)
<zyga_> Chipaca: standup?
<Chipaca> yeap
<mup> PR snapd#3392 closed: interfaces: add minimal seccomp resolver to avoid backward compatiblity issues <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3392>
<mup> PR snapd#3407 closed: interfaces: move seecomp profiles to /var/lib/snapd/seccomp/profiles-v2/ <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3407>
<zyga_> hmmm
<zyga_> hangouts froze for me
<pstolowski> zyga, for me tto
<pstolowski> zyga, i can't reconnect...
<Chipaca> oh nice
<Chipaca> now it kicked me
<Chipaca> is it sso o'clock
<pstolowski> no sso prompt, just spinning
<mup> PR snapd#3429 opened: interfaces/snapd-control: also allow use of /usr/bin/snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3429>
<pedronis> niemeyer: is this one snapd#3418
<mup> PR snapd#3418: tests: prefer ipv4 over ipv6 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3418>
<pedronis> needs 2nd review and now it's green finally, well or green enough at least
<mup> PR snapd#3430 opened: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
<fgimenez> pstolowski: this is the patch http://paste.ubuntu.com/24748672/, i've executed after pulling again your branch (and removing the compatibility changes)  and got the same error, somehow snapctl still doesn't understand SNAP_COOKIE
<niemeyer> pedronis: Cheers!
<pstolowski> fgimenez, thanks, i'll look into it
<niemeyer> fgimenez: Why the full block instead of just echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf?
<fgimenez> thank you pstolowski
<pedronis> niemeyer: because that's what "man gai.conf" tells to do
<pedronis> it doesn't add , it replaces the whole table
<niemeyer> pedronis: That doesn't sound like a good reason :)
<fgimenez> niemeyer: yep pedronis suggested it "the presence of a single precedence line in the configuration file causes the default table to not be used"
<pedronis> niemeyer: because the RFC also suggested the change in terms of an update table
<fgimenez> niemeyer: and we just want to change one of them?
<pedronis> and just putting in a single precedence doesn't produce that
<pedronis> s/update table/updated table/
<niemeyer> pedronis: I'm not reading that there
<niemeyer> pedronis: Specifically, "Complete absence of data of one kind causes the appropriate default information to be used."
<pstolowski> fgimenez, can you give me last commit id you're using? git log -n1 ?
<niemeyer> pedronis: Note the "of one kind"
<fgimenez> pstolowski: the last two are merges and conflic resolutions, the next is 5da6cd162745d96120fa2dadc2beba4e3dbeba93 "Further compatibilty changes to support SNAP_CONTEXT in transition period."
<pedronis> niemeyer:   Once again, the presence of a single precedence line in the configuration file causes the default table to not  be
<pedronis>               used.
<niemeyer> pedronis: You said this was in the manual.. I can't find it..
<pedronis> that line is in man of gai.conf
<niemeyer> pedronis: What I'm reading, also from the documentation, is what I pasted above, which means something else
<pedronis> niemeyer: are we reading different versions of the docs
<pedronis> ?
<pedronis> because IÂ don't see that "one kind" bit
<niemeyer> pedronis: Maybe.. can you paste what yours says?
<niemeyer> pedronis: THis is in the docs in the configuration file
<pedronis> niemeyer: ?
<niemeyer> pedronis: Sorry, I don't know what the question is
<pedronis> niemeyer: why you think your sentence help
<pedronis> if one present in there then the info is not missing
<Chipaca> mwhudson: BTW, the locks around clone/exec make the EAGAIN not happen, for me. If you (or anybody) can confirm this, and you backport this, you can probably un-backport the other
<pedronis> so the default table is not used
<Chipaca> mwhudson: (this confirms the original hypothesis about why those eagains were happening, fwiw)
<pedronis> niemeyer: also see  https://www.rfc-editor.org/rfc/rfc3484.txt   "10.3. Configuring Preference for IPv6 or IPv4"
<niemeyer> pedronis: Because so far I found nothing saying "the default is not used"
<pedronis> niemeyer: man gai.conf
<niemeyer> pedronis: The RFC is irrelevant.. this is a configuration file which modifies an implementation detail
<niemeyer> pedronis: There's a default table in glib proper
<niemeyer> glibc
<pedronis>        precedence netmask precedence
<pedronis>               This keyword is similar to label, but instead the value is added to the precedence table as specified in RFC 3484.
<pedronis>               Once again, the presence of a single precedence line in the configuration file causes the default table to not  be
<pedronis>               used.
<pedronis> this is compatible also with the the first lines in gai.conf which sort of refers to the reverse
<niemeyer> pedronis: Ok, thanks.. I missed that part..
<niemeyer> pedronis: I was basing my assumption on the documentatino provided in gai.conf itself
<niemeyer> and in my own experience doing the simple addition, which does work
<niemeyer> Perhaps for non-obvious reasons
<pedronis> it's all a bit unclear
<pedronis> it's a bit bad that there's no command to print the actual table
<pedronis> that will be used
<pedronis> afaict
<pedronis> but the full table should be good because is also what's listed in the RFC
<pedronis> to achieve this
<niemeyer> pedronis: It's probably safer as well considering we're dealing with mulitple images
<pedronis> yes
<niemeyer> (which might have different values)
<niemeyer> pedronis: Anyway, thanks, learned something
<pedronis> yes, it would best if you could do punctual changes, but the explanation for the docs sounds like is not possible, is either or the defaults or start from scratch
<pedronis> s/or the/the/
<mup> PR snapd#3418 closed: tests: prefer ipv4 over ipv6 <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3418>
<mvo> pedronis: if someone can ack 3426 we can merge that one too
<mup> PR snapcraft#1329 closed: tour: use https for source urls <Created by tim-sueberkrueb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1329>
<mup> PR snapcraft#1350 opened: Rust rust: Add support for cross-compilation <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1350>
<mup> PR snapd#3426 closed: release: 2.26.4 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3426>
<abeato> zyga, finally got a good test run for https://github.com/snapcore/snapd/pull/3353 , time for merging?
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<fgimenez> pedronis: mvo niemeyer snapd#3408 is only missing one review (green with some autopkgfailures)
<mup> PR snapd#3408: tests: add alsa interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3408>
<niemeyer> Looking
<fgimenez> and it would be great to have snapd#3348 landed too, so that we can put in place the spread-cron branches for executing it
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<mup> PR snapcraft#1344 closed: git: don't use --remote for updating submodules <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1344>
<daker> hey popey, can i PM you (snap testing)?
<popey> of course, anytime
<morphis_> niemeyer: do you have time for another look at https://github.com/snapcore/snapd/pull/3365 ?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<niemeyer> morphis_: Yep
<morphis_> niemeyer: awesome! I have a few more you had comments on but lets start with that one
<mup> PR snapd#3408 closed: tests: add alsa interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3408>
<aisrael> I could use a sanity check. I'm trying to get an Adafruit PiTFT touchscreen working with Ubuntu Core. It looks like I need to build a kernel snap to pull in Adafruit's PiTFT kernel. Does that sound right, or am I overlooking another solution?
<mup> PR snapcraft#1351 opened: cli: remove double congrats messaging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1351>
<niemeyer> morphis_: Are there tests enabled?
<niemeyer> morphis_: For fedora?
<morphis_> niemeyer: a single one
<morphis_> tests/main/help
<morphis_> enabling a lot more is another PR
<morphis_> https://github.com/snapcore/snapd/pull/3411
<mup> PR snapd#3411: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3411>
<niemeyer> morphis_: I'd prefer to invert the logic then: whitelist the one test
<niemeyer> morphis_: Instead of blacklisting every single one
<morphis_> niemeyer: how? when I tried to blacklist the suite none of the suite tests were considered no matter if whitelisted or not
<niemeyer> morphis_: That'd be a bug in spread.. let me try to reproduce
<fgimenez> pstolowski: fwiw the debs built from your branch (including the compatibility changes) work great on classic xenial (with a previous core from stable) http://paste.ubuntu.com/24749105/
<morphis_> niemeyer: https://github.com/snapcore/snapd/pull/3365/files#r119012848
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<pstolowski> fgimenez, great! thanks for checking that
<morphis_> niemeyer: that is what I get with the suite blacklisted and a single test below whitelisted
<pstolowski> fgimenez, btw, i've reproduced the failure with your diff and investigating it
<fgimenez> pstolowski: without the compatibility changes i get this error http://paste.ubuntu.com/24749114/ (even when it seems to not being reexec-ing, snap version seems to report the outer)
<fgimenez> pstolowski: great thanks!
<niemeyer> morphis_: Worked fine here
<morphis_> niemeyer: hm, you have a newer spread version?
<morphis_> hm, spread -v does not exist
<mvo> Chipaca: can you walk me through the process of contributing to go? https://github.com/golang/go/issues/20556 is what I need
<morphis_> niemeyer: 2017.01.30 is what I used
<niemeyer> https://www.irccloud.com/pastebin/dPGI43zd/
<morphis_> hm
<niemeyer> morphis_: That sounds super old
<niemeyer> morphis_: Most likely the issue
<morphis_> niemeyer: that is what is in the store .. :-)
<niemeyer> morphis_: Let me update that then
<niemeyer> Interesting that my snapcraft.yaml says 2017.04.25, which is up-to-date.. I probably screwed up by not uploading
<morphis_> niemeyer: time to use build.snapcraft.io :-)
<niemeyer> Yes!
<morphis_> then we have at least an up to date version in edge
<morphis_> niemeyer: btw. what about moving the spread snap to be a classic snap?
<morphis_> that way we could easily use it together with kvm
<morphis_> form the host
<niemeyer> morphis_: Might be a good idea
<morphis_> great
<niemeyer> morphis_: Ok, rev 28 is up
<niemeyer> morphis_: Please give it a shot and let me know
<morphis_> niemeyer: will do
<morphis_> niemeyer: ok, then you vote for changing that, fine for me
<morphis_> niemeyer: any other comments?
<niemeyer> morphis_: Yeah, it makes more sense for that status of the PR
<niemeyer> morphis_: Otherwise you'll immediately break every other spread PR that is up for review, for example
<pedronis> mvo: interesting  x/net, might take a while
<pstolowski> fgimenez, right. this is because without these compatibility fixes we don't have env variable set. i may need to think if this shouldn't lead to some ohter error
<niemeyer> morphis_: No, I think we're aligned about the rest
<morphis_> good, so can you approve based on that or do you want to review again on Monday?
<mvo> pedronis: yeah, need to sign the CLA there I guess, anyways, it took me a little bit to figure this one out, I though I just did  the byte packing wrong myself
<fgimenez> mvo: i just got this error on pi2 http://paste.ubuntu.com/24749264/ (test scenario beginning with stable, refreshing to beta and excuting the suite) if you could take a look that would be great
<mup> PR snapd#3431 opened: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<mvo> fgimenez: woah
<mvo> fgimenez: are you in the machine? if so, what does "ls -l /snap/core/current/usr/lib/snapd/snap-confine" show? maybe there is a refresh going on at the same time and current is not valid? that is a bit of a strange one
<fgimenez> mvo: the execution hasn't finished yet, let me check on another session
<mvo> fgimenez: thank you, strange that /snap/core/current/usr/lib/snapd/snap-confine is not there. the logs do not indicate a refresh so that is porbably not it
<fgimenez> mvo: http://paste.ubuntu.com/24749363/
<mvo> fgimenez: do you see an apparmor denial in syslog?
<mvo> fgimenez: what happens if you run on this shell su test -c 'sh -c "SNAP_NAME=test-snapd-tools /snap/core/current/usr/lib/snapd/snap-confine snap.test-snapd-tools.cmd /bin/true " ?
<fgimenez> mvo: seems to be empty now, the suite is still running...
<mvo> fgimenez: with correct quoting
<mvo> (sorry for that paste error)
<fgimenez> mvo: yep, i've tried, complains about elevated permissions, let me paste the output
<mvo> fgimenez: ok, strange, could you re-run this test once the suite finished?
<fgimenez> mvo: http://paste.ubuntu.com/24749391/ sure, will let you know how it goes, thx!
<mvo> fgimenez: this looks ok, odd
<mvo> jdstrand: I get a build failure of snap-confine on arm on artful, https://launchpadlibrarian.net/322177974/buildlog_ubuntu-artful-armhf.snapd_2.26.4+17.10_BUILDING.txt.gz - it looks like /lib/arm-linux-gnueabihf/libapparmor.a have changed and no longer allow static linking. do you happen to know anything about this?
<jdstrand> mvo: I do not. I saw the forum post. tyhicks or sbeattie might have an idea
<jdstrand> tyhicks, sbeattie: https://forum.snapcraft.io/t/build-failure-for-2-26-4-on-artful-on-arm-arm64/866
<jdstrand> otoh idk if new defaults are being used in artful that would trigger that
<pstolowski> fgimenez, that error you found is curious, still haven't found what's causing it
<jdstrand> tyhicks: if you need me to dig into that instead of you or Steve, let me know and I can take a look after appt/lunch
<tyhicks> sbeattie: your wiki page (https://wiki.ubuntu.com/SecurityTeam/PIE) suggests to me that apparmor simply needs a no-change rebuild now that PIE is enabled by default on armhf/arm64 - does that sound right to you?
<tyhicks> (specifically, the "Relocation Linking Failure" section)
<fgimenez> thank you pstolowski, don't spend too much time on it, maybe somehting is wrong with the tests, i'll take a look on monday
<pstolowski> fgimenez, no no, thank YOU! I want to understand why this is happening. maybe it's a sign of a bug. all binaries the same, should work
<tyhicks> sbeattie: I followed up in the forum - please post there if you have any corrections to make to my advice
<fgimenez> pstolowski: yep, it's super weird
<zyga> jdstrand: I commented on https://github.com/snapcore/snapd/pull/3428 and fixed it on Debian (secure path doesn't have /snap/bin, bummer)
<mup> PR snapd#3428: tests: add snap-confine privilege test <Created by zyga> <https://github.com/snapcore/snapd/pull/3428>
<mvo> tyhicks: thanks a bunch, if a rebuild would be enough, that sounds great. if sbeattie is of the same opinion I can do a no-change build1 upload if wanted (or let you guys handle it, either way works for me :)
<tyhicks> mvo: feel free to do a quick no-change yourself once sbeattie chimes in
 * Chipaca out
<Chipaca> o/ EOW \o/
<om26er> Hi! Is there a way for my code to check if its running inside a snap ?
<nacc> om26er: i'm not sure. Why do you want that? Sort of defeats the purpose/goal it seems :)
<om26er> nacc, our code reads /var/lib/dbus/machine-id on a normal linux system but inside a snap that path is not available, we have a fallback mechanism, but I want to do something better than just a try/except
<mup> PR snapd#3432 opened: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432>
<nacc> om26er: try/except seems totally reasonable (to handle an assumed path not existing). or do you mean the try/except is too broad and reflects only that path not existing, not whether you are in a snap or not?
<om26er> nacc, right, the former
<nacc> om26er: i don't know, sorry -- i'm not sure there is a way to detect 'in a snap' explicitly
<ogra_> om26er, chek your env ;)
<ogra_> *check
<ogra_> there is tons of things
<nacc> ogra_: that does make sense, even for things like SNAP_
<ogra_> yep
<nacc> ogra_: but is there a 'canonical' (little c) way?
<nacc> ogra_: checking the env seems ... iffy, only because the env can be manipulated (it's more of a hint than an assertion to me)
<ogra_> true ...
<ogra_> dunno if there is a more canonical way
<nacc> i guess om26er could do ... try / except, in the except check if SNAP_ is defined and then assuem it's a snap
<om26er> ogra_, its a production software so which the most reliable (not likely to change) env var, if you were to suggest ?
<ogra_> i'd just check if $SNAP is set
<ogra_> you can easily take a look by "snap install hello-world; hello-world|grep SNAP"
<ogra_> err
<ogra_> "snap install hello-world; hello-world.env|grep SNAP"
 * nacc wonders if one days we'll have a snap-ok command like kvm-ok to tell us we are in a snap
<nacc> or there was another one that told you you were in a VM
<ogra_> in-container ?
<ogra_> or some such
<om26er> on a different note, is there a way to read /var/lib/dbus/machine-id inside a confined snap ?
<nacc> ogra_: yeah that sounds familiar
<nacc> om26er: are you able to if you connect to the dbus interface?
<om26er> nacc, do you mean "you are able to if you connect dbus interface" ?
<nacc> om26er: i meant, (sorry for the bad typing) -- if you connect to the dbus interface, are you able to read /var/lib/dbus/machine-id ?
<nacc> om26er: it was a question, honestly -- i don't know (and can't tell immediately from reading the snapcraft docs)
<om26er> of the top of my head, I think that path should not be available to a confined snap, but maybe ogra_ can confirm.
<nacc> om26er: right it won't be, i agree -- but if you connect to an interface that allows it, maybe it would be
<om26er> *even with dbus interface connected. But that's just my limited understanding of Ubuntu Core.
<nacc> om26er: but i dont' know what the dbus interface exposes exactly :)
<ogra_> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/dbus.go doesnt give any file access it seems ... only actual bus access ...
<nacc> om26er: do you use this file to generate a unique key or something?
<nacc> ogra_: oh i see, it's for registering to be on/listen on dbus
<ogra_> yep
<om26er> nacc, that file is automatically generated with a unique ID, when the system starts for the first time, doesn't change during the lifetime of an install as I understand.
<ogra_> and no, a snap can not see /var/lib/dbus/machine-id
<nacc> om26er: right -- that still doesn't tell me why you need it? :)
<om26er> nacc, reason: http://0pointer.de/blog/projects/ids.html
<nacc> om26er: fwiw, on ubuntu that file is just a symlink to /etc/machine-id :)
<ogra_> also note that the /var/lib/dbus/machine-id gets explicitly removed from the core snap at build
<ogra_> ogra@styx:~$ LC_ALL=C ls -l /snap/core/current/var/lib/dbus/
<ogra_> total 0
<nacc> ogra_: ah interesting
<nacc> ogra_: why is that? (if you know)
<ogra_> (else all core snaps would have the same ID)
<nacc> ogra_: ah right
<nacc> ogra_: probably similar to containers issue
<om26er> apparently  /etc/machine-id comes from systemd, so maybe I could somehow ask it.
<ogra_> if the core snap is not used as rootfs, the file wont be there .... on an ubuntu core image it gets created on first dbus startup
<om26er> in a python/dbus way
<om26er> hmmm..
<nacc> ogra_: that makes sense
<ogra_> yeah, you can probably use the dbus to actually query for it
<nacc> yeah, i wonder if you can use the API (or do what the API does) to query dbus
<ogra_> if your snap is actually confined that would in any case be the better way ... the snap is executed on top of the core snap ... but the dbus you connect to is the actual hosts dbus ... and *that* has a mschine ID
<ogra_> (while the file would never be visible even if you run unconfined)
<nacc> ogra_: yep, that's the right abstraction to operate at, it seems
<nacc> om26er: with, based upon that post, maybe a fallback to the filesystem if that dbus query fails (for some reason)
<om26er> ogra_, making it a strict snap is the aim.
<ogra_> i was assuming so :)
<Flagada> Hello I'm Trying to install Ubuntu Core 16 with KVM.  I got a "Creating user failed" when I enter my SSO email adress
<om26er> ogra_, is the behaviour going to be the same on Ubuntu Core and classic ubuntu install with snapd ?
<Flagada> Someone can help me with that?
<om26er> nacc, I guess that's what I'd have to go for.
<ogra_> om26er, yep
<cachio> niemeyer, 2017-06-02 19:29:33 Error preparing linode:ubuntu-core-16-64:tests/main/ : kill-timeout reached, cannot reconnect to linode:ubuntu-core-16-64 (Spread-09) after reboot: dial tcp 50.116.46.101:22: i/o timeout
<cachio> niemeyer, it just happened
<cachio> the machine is lost
<cachio> no ping no ssh
<cachio> niemeyer, seem to be a problem of linode
<cachio> niemeyer, perhaps spread could allocate another machine when that happens or move the current task to another one
<mup> PR snapcraft#1338 closed: go plugin: Add support for cross-compilation <enhancement> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1338>
<pmatulis> how does one specify what "track" to install?
<om26er> assuming track == channel, use --track_name e.g. snap install hello-world --edge. If otherwise, please ignore my comment.
<om26er> pmatulis, ^
<nacc> pmatulis: track/channel, iirc
<nacc> https://snapcraft.io/docs/reference/channels
<nacc> pmatulis: down in the "installing a snap" section, first example
<nacc> om26er: tracks are new
<om26er> nacc, thanks, reading into it now.
<nacc> om26er: np, niemeyer's forum post (looking for it now to share) is pretty helpful too
<nacc>     GitUbuntuRepository: optimize treeishs_identical
<nacc>     
<nacc>     If we can peel() to treeishs, we can just compare the hashes.
<nacc> bah
<nacc> https://forum.snapcraft.io/t/channel-terminology-and-policy/551
<pmatulis> i thought *channels* and *tracks* were distinct
<pmatulis> where a channel was akin to a series (2.0, 2.1) and a track was the level of development (experimental, devel, stable)
<nacc> pmatulis: they are distinct
<nacc> track/risk/branch is what niemeyer's post says
<pmatulis> i still don't know how to specify the channel
<pmatulis> :(
<nacc> pmatulis: i told you above? (and it was in the link)
<pmatulis> not really
<nacc> snap install <snap> --channel=<track/channel>
<pmatulis> where is that in the page you linked to?
<nacc> pmatulis: as i said, "down in the "installing a snap" section, first example"
<nacc> pmatulis: on https://snapcraft.io/docs/reference/chan
<nacc> pmatulis: on https://snapcraft.io/docs/reference/channels, rather
<pmatulis> ohh
<pmatulis> i was looking at the other one
<pmatulis> forum whatever
<nacc> pmatulis: ah sorry, two different links
<pmatulis> it's odd. i think it depends how some snaps are actually made
<pmatulis> for instance, this doesn't work:
<pmatulis> sudo snap install maas --channel=latest/stable
<pmatulis> even though:
<pmatulis> snap info maas | grep latest/stable
<pmatulis>   latest/stable: 2.2.0+bzr6057-snap (91)  98MB -
<nacc> pmatulis: interesting, '--channel=stable' does work though
<pmatulis> yeah
<nacc> pmatulis: i *wonder* if the snap we are running isn't aware of tracks?
<pmatulis> that's the thing. it depends on how it's made
<pmatulis> which isn't great at all
<nacc> pmatulis: i think it (obviously) depends on `snap` support
<nacc> pmatulis: is that what you mean by 'it'?
<nacc> pmatulis: oddly, the changelog for snapd in 17.04 (what i'm on) only mentions:
<nacc> - many: show available "tracks" in `snap info`
<nacc> pmatulis: i also wonder, if (*big* if) that if there's only one track -- that it doesn't work
<nacc> pmatulis: to specify a track, i mean
<pmatulis> right, no idea
<nacc> pmatulis: i'd file a bug or forum post
<pmatulis> i would also like to know how to query for extra options. the maas snap, for instance, accepts '--devmode'. is that standard?
<pmatulis> this snap will not install without it
<nacc> pmatulis: well the snap doesn't accept that, `snap` does
<nacc> pmatulis: right, the default is `snap install` tries to install a confined snap
<nacc> pmatulis: with the name provided
<nacc> pmatulis: in the `snap info` output for maas, you can see that one mentions devmode
<nacc> pmatulis: that means it's a devmode snap (not confined)
<pmatulis> oh it mentions it?
<nacc> http://paste.ubuntu.com/24752362/ is what i get from `snap info maas`
<nacc> pmatulis: stable is not a devmode snap, but edge is
<pmatulis> no, i installed stable with devmode
<nacc> pmatulis: given the security implications (and trust implications) of not using confined snaps, you have to tell `snap` to install it in anything other confined mode (e.g., --classic, --devmode).
<nacc> pmatulis: hrm, let me let it complete here
<nacc> pmatulis: did you get this: http://paste.ubuntu.com/24752396/ ?
<pmatulis> nacc, yes, you need --devmode
<nacc> pmatulis: right, i think it's a bug in the snap
<nacc> pmatulis: they aren't declaring you need devmode for the stable snap
<nacc> pmatulis: you might file a bug with maas
<pmatulis> nacc, ah ok
<nacc> pmatulis: i think they 'fixed' this in edge (hence it asks for devmoe) and maybe just haven't updated stable yet -- i've asked them
<nacc> pmatulis: but EOD on a friday, so probably won't hear back :)
<pmatulis> nacc, you've asked them where?
<nacc> pmatulis: internal IRC :)
<nacc> pmatulis: you might ask in #maas, though, i guess
<pmatulis> nacc, right, but i'm in the maas channels. there must be one i'm not aware of
<nacc> pmatulis: apparently, this was done so that the snap could be published in stable at all (which doesn't allow devmode)
<nacc> pmatulis: but it still needs devmode ...
<nacc> pmatulis: not a great UX :)
<pmatulis> yeah
<Chipaca> niemeyer: (and for zyga, but he's not here): from HN: https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix
<niemeyer> Chipaca: Oh, handy
<Pharaoh_Atem> I'm really not surprised by that
<niemeyer> Chipaca: Ah, uh
<niemeyer> Chipaca: That sounds like the basic issue we're aware off
<Chipaca> Pharaoh_Atem: heh
<niemeyer> Chipaca: That's why we have the C hackery in e.g. snap-update-ns
<Pharaoh_Atem> wait, what
<niemeyer> Chipaca: Trick is to basically switch namespaces before Go has a chance to screw up
<Chipaca> yeap
<Pharaoh_Atem> grossness
 * Pharaoh_Atem smacks himself
<Pharaoh_Atem> of course I remember when that happened
<Chipaca> same for a bunch of things like setuid, drop privs, etc
<Pharaoh_Atem> it was switched from C to Go with Cgoop
<niemeyer> Chipaca: Note that this is not true of all namespaces
<Pharaoh_Atem> stuff like this makes me wonder if Go is really a good idea for a lot of this stuff...
<niemeyer> Which I think the article fails to point out
<niemeyer> Pharaoh_Atem: There's basically a cost benefit to be measured for sure
<niemeyer> Pharaoh_Atem: The amount of C in snap-update-ns is minimal, so worth it
<Chipaca> HN discussion is here: https://news.ycombinator.com/item?id=14470231 fwiw
<Chipaca> anyway, thought you'd enjoy / find it interesting
<niemeyer> "Personally I really wish people had just gone with Rust earlier on rather than implementing everything in Go. I've had nothing but pain from Go."
<niemeyer> Personally, I wish people wouldn't be so superficial and one-sided.. :P
<niemeyer> Chipaca: The hnews discussion is much more interesting than the article itself
<niemeyer> Still, even there, there's a lot of "editor wars" conversation
<Chipaca> rah rah c++ rah rah nim
<niemeyer> People get too passionate about the tools..
<Pharaoh_Atem> I like C++
<Pharaoh_Atem> at least modern C++ (C++11)
<niemeyer> Hah, they even managed to bring up Go generics into the conversation.. :)
<Chipaca> Pharaoh_Atem: the big c++ abi brouhaha a couple of years back makes me uneasy about supporting it for things meant to live a long time
<niemeyer> Me, I would definitely not choose Go for this stuff, but the point is that the whole project is in Go, which means all of our libraries are in Go, and our testing infra, and etc etc
<Pharaoh_Atem> Chipaca: I think it practice, it doesn't matter
<niemeyer> The cost of picking something else needs to account for that
<niemeyer> I wouldn't pick Rust either, though, most probably at least
<Pharaoh_Atem> Rust is a bit on the young side right now
<niemeyer> I think Rust is going the C++ route a bit too early
<Pharaoh_Atem> how so?
<Chipaca> Pharaoh_Atem: I agree it doesn't matter; in 40 years time all this will be dust
<Pharaoh_Atem> Chipaca: well, I mean that usually ABI changes are system wide, and c++stdlib supports both anyway
#snappy 2017-06-03
<Pharaoh_Atem> ABI changes are inevitable, the question is, is your infra prepared to deal with it
<niemeyer> Pharaoh_Atem: A bit of a "we do things differently and you don't understand because you're not in the cool kids group" sentiment, and the design ends up not paying enough respect to human factors which are relevant for reading and understanding written code over time
<Pharaoh_Atem> for a lot of people, the answer is no, because they don't think it's a thing that happens
<Pharaoh_Atem> niemeyer: ah, that
<Pharaoh_Atem> I guess my experience with C++ was different from yours, because I didn't get that feeling
<Pharaoh_Atem> that's the feeling I get from the golang people, actually
<niemeyer> Pharaoh_Atem: See the thread below this, for example: https://twitter.com/gniemeyer/status/857655335309500416
<niemeyer> Pharaoh_Atem: Sure, there's some of that in every knowledge group, true.. but the problem is when you stop considering some of the consequences of choices that will hurt even the people that are well aware of the language because you think people are just not used to it yet
<niemeyer> Pharaoh_Atem: There's a lot of that in Haskell too, for example
<Pharaoh_Atem> definitely in most of the functional language communities
<niemeyer> With Monads being the prime exmaple
<niemeyer> The case I mentioned above is pretty obviously a terrible decision, for instance..
<niemeyer> They're basically changing the ownership logic of a typical a+b statement
<niemeyer> Sure, you can get used to it.. but what misses from the analysis is that this will _remain_ a cost, forever, even to experienced developers
<niemeyer> It's brain space which is now occupied by a flag saying "Watch out for it!"
<Pharaoh_Atem> the inability to directly concatenate strings by adding them together is weird
<Pharaoh_Atem> it's not even hard syntatic sugar to support
<niemeyer> Yeah, and that's pretty representative of the design choices in Rust
<Pharaoh_Atem> syntactic sugar, even
<Pharaoh_Atem> there are things to like about Rust, but *shrugs*
<Chipaca> that a+b modifies a is surprising to me, even without the ownership thing
<Pharaoh_Atem> it implies =+
<Pharaoh_Atem> which is weird
<Pharaoh_Atem> C++ has a similar concept, but that's glossed over with how overloaded operators work
<Pharaoh_Atem> so you don't notice it (thankfully)
<niemeyer> Right, exactly.. but again, the excuse is that you get used to it, and they are right. The problem is that it will _remain_ a cognitive cost, forever..
<niemeyer> Because as children and for dozens of years we've learned that a+b does not modify a..
<Pharaoh_Atem> as humans for centuries, we've learned that
<Pharaoh_Atem> eons even
<Chipaca> your pharaohness is leaking
<Pharaoh_Atem> By the Hand of God
<Chipaca> o... k?
 * Chipaca backs away slowly
<Chipaca> srsly i should sleep :-)
<Chipaca> o/
<Pharaoh_Atem> but yeah, the ownership principle doesn't mean you can't have nice things
<Pharaoh_Atem> hey JamieBennett
<kunal> Hello Community
<kunal> I have a problem . I am using ubuntu core 16.04 . I want to copy some data from my pendrive to /home folder. Please help me... How to do it?
<kunal> hello everyone.... please help
<Hilikus> i'm using snap try to mount an exploded snap. that snap has a command in the snapcraft.yaml file but it's not working because it can't find the file i'm referencing. what is the relative path in a "command:" argument?
#snappy 2018-05-28
<mborzecki> morning
<mvo> hey mborzecki, good morning
<zyga> Good morning
<mvo> zyga: good morning to you as well
<mborzecki> zyga: mvo: hey
<zyga> I will be at my desk shortly
<zyga> and back
<zyga> man, it's such a hot day already
<zyga> it will easily be +30C
<zyga> Coffee and reviews
<zyga> mvo: interesting thing that may affect us soon: https://github.com/systemd/systemd/issues/8221
<mvo> zyga: thanks
<zyga> pstolowski|afk: ^ this is also related to your work closely
<zyga> I cannot believe how terrible udev scripting is
<zyga> it's the least sensible syntax
<zyga> used an virtually all the linux machiens
<zyga> *machines
<zyga> eh
<mborzecki> zyga: tried cmake? :)
<zyga> yes, I hate it too but at least it's a language with regular-ish syntax
<zyga> (except for that crazy upper-case madness)
<zyga> but udev is really the assembly
<zyga> line oriented
<zyga> obscure
<mborzecki> lowercase works too
<mborzecki> still the syntax garbage
<zyga> if udev rules were like pascal it would be a huge improvement
<zyga> and that says a lot
<mborzecki> heh
<zyga> so after growing up on Pascal someone made a crappy hand-crafted line "parser"
<zyga> because that's the best we can do?
<zyga> eh
<mborzecki> wish we made more use of tcl historically
<mborzecki> one of the nicer 'glue' languages i used
<zyga>  the other side of udev is also weird, why on earth is the "state" a zoo of files in /run
 * zyga stops ranting
<pstolowski> good morning!
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/5199 good for landing now?
<mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<mborzecki> zyga: got some comments from niemeyer, fixing them atm
<mborzecki> zyga: i think we can land #5203
<mup> PR #5203: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5203>
<zyga> mborzecki: jamie said he would write a test
<zyga> though it can probably land separately
<mvo> zyga: +1
<mvo> (for landing the joystick thing)
<zyga> done
<mup> PR snapd#5203 closed: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5203>
<mborzecki> #5091 can be merged when it's green
 * zyga -> breakfast
<mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<pedronis> mborzecki: where you talking about it before or #5199 ?
<mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<pedronis> s/where/were/
<mborzecki> pedronis: yeah, mistook it for 5091 (i was fixing it), 5199 should can be landed now
<mborzecki> (removed blocked tag)
<pedronis> mborzecki: was the new test snap transfered?
<pedronis> not a blocker for landing as such
<mborzecki> pedronis: yes
<pedronis> cool, thx
<mborzecki> pushed some fixes to #4700, still neds a re-review from jdstrand but at least it should be passing tests now
<mup> PR #4700: interfaces/builtin: add the dvb-video interface <Created by ThyMYthOS> <https://github.com/snapcore/snapd/pull/4700>
<mup> PR snapd#5215 opened: Improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<zyga> mborzecki: hey, question about arch packaging
<zyga> mborzecki: will #5198 make arch automatically get the service script?
<mup> PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
<zyga> and the corresponding service?
<zyga> mvo: is this expected? https://github.com/snapcore/snapd/pull/5198/files#r191143359
<zyga> you added the snapd.seeded.service unit
<mup> PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
<pstolowski> pedronis: hey! would you like to discussus conflict stuff & connect?
<newbee> I am trying to package an applications which uses a serial port as a Snap.  From the documentation I gathered that I should add the 'serial-port' plug and then connect it, But still in my snap it didn't list the serial-port. Help me to solve this.
<zyga> newbee: where are you running your application? on classic system or on a all-snap/core device?
<zyga> newbee: serial ports are only supported on the latter type for now
<newbee> I running it on a snap core..
<zyga> newbee: ok, what do you mean by "but still in my snap it didn't list the serial port"
<newbee> Ubuntu 16.04 LTS.
<zyga> ?
<zyga> ubuntu 16.04 LTS is a classic system, serial port is not useful there yet
<mvo> zyga: we have a new snapd.seeded which is used as a sync point. should be fine to have this on opensuse
<mvo> zyga: or am I missing something?
<zyga> mvo: I'm wondering why tests passed before, how is that unit installed?
<zyga> mvo: it appears as before that unit was not installed at all
<pedronis> it's fairly recent
<pstolowski> newbee: after installing your snap check `snap change --last=install`, any errors there re your plug?
<mborzecki> zyga: yes, on arch it's just make -C data install ...
<mborzecki> zyga: you probably need to rm -f it like you do for fedora
<zyga> mborzecki: thanks
<zyga> ideally I would connect that to the --without-apparmor
<zyga> but it's not easy
<mvo> zyga: I don't know why it is working right now, let me look at master
<mborzecki> yeah, you'd have to build data from the same setup as cmd is built, we've had 2 attempts already
<mup> PR snapd#5091 closed: many: hold refresh when on metered connections <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<newbee> @pstolowski  there is no error listed..
<zyga> newbee: can you tell me how your application is making use of the serial port? which port is it opening? how does it know? what's the expected use-case?
<mvo> zyga: we install snapd.seeded.service for opensuse in master
<mvo> zyga: maybe you need to merge master?
<mvo> zyga: (into your PR)
<zyga> mvo: hmm, AFAIK I did but I will re-check
<newbee> @zyga  I need to connect the one of the listed serial port for transmitting the data. In my program i use the gnu.io jar to list the serial-port in system.
<zyga> how does your program know which port to open?
<newbee> zyga: I need to choose that manually on my application. In net-beans it works clearly.
<zyga> newbee: ideally you would use interface hooks to get notified of connection and disconnection of the serial-port interface (or interfaces, you may have many) and do the right thing inside your application
<zyga> newbee: but anyhow that does not work on classic systems because they don't have any serial port slot definitions
<zyga> newbee: only core systems (those that only ship snap packages) use gadget snaps to define serial ports (e.g. raspberry pi)
<newbee> @Zyga thanks. is there any examples for that?
<zyga> newbee: of which part specifically?
<newbee> @zyga  gadget snaps to define serial ports? how to create that file?
<zyga> newbee: are you planning on making your own device? gadget snaps are a special type of snap that is only installed on a core device (all-snap system without classic packages) that is prepared by the device maker
<zyga> you can find examples on GitHub.com/snapcore/ e.g. the pi2 gadget
<newbee> @Zyga ok thank you..
<zyga> but you cannot make one and install it on your system, it must come pre-made with a device
<zyga> for classic systems (e.g. a laptop or desktop) that either have some built in serial ports (rare) or use usb-attached serial ports you need to wait for support for hot-plug that pstolowski is working on
<zyga> in the end it will work exactly the same (for apps) as it does on core
<zyga> you define one or more plugs of type "serial-port" on your snap
<zyga> (you can name each one to match the indented function for the user)
<zyga> you install that snap on some system
<zyga> and then connect each plug on your snap to one of the serial port slots defined by the system (either statically or via hot-plug devices)
<zyga> and using interface hooks your application is notified of each such operation and can store local state
<zyga> (or notify a running service)
<newbee> Ok I will try and let you know the result..
<zyga> once connected the application process that has those plug definitions will get permissions to open those specific serial ports that are connected
<zyga> it's not a simple set of things to happen but that's how it is designed to work
<zyga> but again, on a classic system you cannot do that yet
<zyga> you may try on a core device that defines a serial port statically for now
<pedronis> mvo:  hi, can we create the 2_34 tag on the forum, for example for https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
<mvo> pedronis: sure, let me try to do that
<mvo> pedronis: should be there now
<pedronis> mvo: thank you
 * zyga -> small break
 * zyga has some fuzzy sight today
<mvo> pedronis: quick question> for the prepare-image work with bases I will need a new test model that is signed with the developer1.account. I saw that you created developer1-pc.model and developer1-pc-w-base.model. I need one based on http://paste.ubuntu.com/p/V4HqpTCySv/  - whats the best way to do this?
<pedronis> mvo: they are signed with the key  in asserts/assertstest
<mvo> pedronis: thank you! that was the missing piece :)
<pedronis> I used a small go program to sign them
<mvo> pedronis: I was about to ask about this, do you think you could share the program or just sign http://paste.ubuntu.com/p/V4HqpTCySv/  got me?
<pedronis> mvo: one sec
<mvo> pedronis: sure, thank you!
<pedronis> mvo: I'll share a gist of what IÂ have, less spoffy
<mvo> pedronis: also lol@removing the "simple" label from 5213 (its true, it started simple and it got downhill from there)
<mvo> pedronis: yeah, gist is fine
<pedronis> mvo: something like this,  this how I signed the -w-config one,  https://gist.github.com/pedronis/256ac00d78c8f075614df3ff5c21e478
<mvo> pedronis: thank you
<pedronis> pstolowski: hi,  sorry, was already having a different discussion somewhere else
<pstolowski> pedronis: np, let me know whe you have some time
<mborzecki> anyone needs help gooming PRs?
<mborzecki> mvo: pedronis: metered connections are 2.34 material right?
<mvo> mborzecki: 2.33 is still early if it merges cleanly I'm fine pulling it in there
<mborzecki> ok, let me check
<mborzecki> mvo: looks like i'll need to cherry-pick individual commits
<mvo> mborzecki: how many are there?
<mborzecki> mvo: 12
<mborzecki> there were additional 2 merges in the original branch
<mup> PR snapd#5216 opened: many: backport holding refresh on metered connections to 2.33 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5216>
 * zyga tries to debug a test failire
<mborzecki> anyone wants to take one last look at #5199?
<mup> PR snapd#5217 opened: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
<mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<zyga> mborzecki: go for it
<zyga> ads20000: hey :)
<zyga> mvo: reviewed 5217
<mvo> zyga: woah, that was quick!
<zyga> I'm trying to debug autopkgtest-buildvm-ubuntu-cloud hanging
<zyga> it's very frustrating
<zyga> I needed a break
<mup> PR snapd#5199 closed: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<ads20000> zyga: hey zyga :) hope you're doing OK!
<mvo> zyga: yeah, I get some lunch now as well
<zyga> yes, although I miss air conditioning today :)
<ads20000> haha xD
<morphis_> mvo: do I have to do anything special with snapd 2.32.8 to get my own build base snap to work?
<zyga> morphis_: classic or core?
<morphis_> was building the snap with `type: base` but still get the core snap mounted as / when I install it
<morphis_> zyga: classic
<zyga> morphis_: hmm
<zyga> morphis_: if you have base B and app snap A then A's apps will use B iff you specify "base: B" in A
<morphis_> right, but I have my base foo and it has apps defined
<zyga> bases cannot have apps
<zyga> at least not yet
<morphis_> so I do a `snap run --shell foo.bar`
<zyga> mvo: ^
<morphis_> ah
<morphis_> I remember I experimented with that in the past
<zyga> unless we broke validation you may say in B, base: B
<zyga> and ... you know
<zyga> but this is not something we support yet
<morphis_> https://git.launchpad.net/~morphis/+git/canonical-iot-stack/tree/snap/snapcraft.yaml is something I did back in Sep last year
<morphis_> and it was working well at that time
<morphis_> but don't remember if that was with an experimental snapd from edge
<zyga> that's surprising, I don't recall any code that would make that work
<morphis_> so maybe this was never released
<pedronis> zyga: morphis_: there's a bug in the store such that bases get the wrong type, so that might be part of the issue
<morphis_> pedronis: its not base coming from the store, self-built and installed with --dangerous
<morphis_> s/base/a base/
<pedronis> mborzecki: mvo: do you we want to port to 2.33 also the common-id stuff?
<mborzecki> pedronis: i think so, doing some reviews atm, but i can open a 2.33 branch in a while
<mup> PR snapd#5218 opened: many: expose AppStream IDs (AKA common ID) (2.33) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5218>
<pedronis> mvo: btw: we will need to think what to do about overlord/ifacestate/implicit.go  which assumes the the system snaps is an os snap, also we discussed in the past that should be done when we load the snap info, or do yet something completely different
<pedronis> *system snap
<zyga> pedronis: interesting, yes
<zyga> which snap should hold those
 * cachio_ afk
<zyga> the bootable base snap?
<pedronis> I suppose so
<zyga> if that code can look at assertions we could check
<pedronis> ?
<zyga> I mean if implicit.go there could just check if a snap is a bootable base we'd be good
<pedronis> we haven't decided how one is marked as such
<pedronis> btw
<zyga> mmm, I assumed that we could check by looking at the model assertion
<zyga> but yeah
<zyga> maybe we could just use an attribute?
<zyga> but what if a snap is both a base and bootable but _not_ booting a system?
<pedronis> well that code has always been problematic
<pedronis> if you forget to call it
<pedronis> => bugs
<pedronis> so maybe time to rethink
<pedronis> but we need to do something
<pedronis> because otherwise core18  => no system interfaces atm
<zyga> perhaps we just want to attach them to something virtual
<zyga> it doesn't have to be a real snap after all
<zyga> could we use system for that?
<zyga> after all, we have system configuration
<zyga> it could be a system "snap" that provides implicit plugs/slots
<zyga> fg
<mup> PR snapd#5219 opened: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<mvo> pedronis: implicit> yeah, we need to think about it. its on the list in the forum post (I think, will double check) but I have not thought about it yet. the next step I want to tackle is to set snap_try_core= when the boot-base gets updated
<mvo> pedronis: and once we have that I think its time for the interfaces
<Son_Goku> zyga, your wish is my command (Cf snapd#5219)
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<zyga> Son_Goku: thank you :)
<mup> PR snapd#5209 closed: packaging: add packaging for openSUSE Tumbleweed <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5209>
<zyga> Son_Goku: are you still making changes?
<Son_Goku> should be done now
<Son_Goku> I had discovered a couple of logic bugs based on local scratch build runs
<Son_Goku> oh, one last thing
<Son_Goku> the stupid gopath thing
<mvo> mborzecki: thanks for your review for 5217
<Son_Goku> zyga, I added a control for the snap mount dir now
<zyga> one sec
<mup> PR snapd#5198 closed: data/systemd: add snapd.apparmor.service <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5198>
<zyga> Son_Goku: can you please merge master, I'm sorry for making a conflict there
<Son_Goku> moo
<Son_Goku> fine
<mup> PR snapd#5220 opened: tests: moving test helpers from sh to bash <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5220>
<Son_Goku> zyga, done: https://github.com/snapcore/snapd/pull/5219
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<zyga> thank you
<Son_Goku> also, adapted AppArmor changes accordingly
<zyga> we'll merge it when green
<zyga> I wonder if we could use this packaging for the system:snappy package as well, I need to see what's there
<zyga> but I suspect the current master packaging is slightly more correct than the one that is maintained on OBS
<Son_Goku> yes
<Son_Goku> actually to some extent, both are wrong
<zyga> yes, I agree
<zyga> I would love if some of the badness could go away
<zyga> but that's a rabbit hole to fill
<Son_Goku> aside from Ubuntu, I think only Fedora actually works correctly
<zyga> what do you mean?
<Son_Goku> I keep dist-git and upstream git in sync
<Son_Goku> so we're actually doing the correct evaluations and tests
<Son_Goku> and as things change, I adapt them
<Son_Goku> I've also taken great pains to make the Fedora spec multi-distro safe
<Son_Goku> so that it can be used to support more than Fedora
<zyga> I see what you mean, yes, the packaging in OBS doesn't benefit from spread
<zyga> I would like to get that fixed, I just said in the standup that I need to work with cachio_ on a tumbleweed image for testing
<Son_Goku> I think I'll actually pull in that new %snap_mount_dir macro I made for openSUSE packaging into Fedora
<Son_Goku> that would make it easy to trivially retarget for Amazon Linux or even openSUSE using the same spec
<zyga> yes, that's a good idea
<zyga> thank you!
<Son_Goku> since I have the day off today, I can finally catch up on so much crap
<mborzecki> Son_Goku: yay for amzn linux!
<mborzecki> what reminds me that i should probably revisit that pr
<Son_Goku> obviously, it'll default to the "good" path /var/lib/snapd/snap
<Son_Goku> but defining a different path on the command-line would be all that's necessary to build differently
 * zyga cooks some food for himself and the dog
<mborzecki> Son_Goku: nmap netcat is a 3rd one yet?
<Son_Goku> yes
<mborzecki> pfff
<Son_Goku> Ubuntu ships all three :)
<Son_Goku> Fedora only ships nmap-netcat
<mborzecki> i have just 2 :) bsd and gnu
<Son_Goku> we dropped the others
<mborzecki> i can reword that comment to something  in the lines of 'non-BSD netcat' :)
<Son_Goku> what is it that makes it so BSD netcat is required?
<mborzecki> nc -U basically
<Son_Goku> https://www.mankier.com/1/ncat#-U
<Son_Goku> that's in nmap-netcat
<mborzecki> Son_Goku: nope, -q
<mborzecki> Son_Goku: https://paste.ubuntu.com/p/vFh6dM6rBm/
<Son_Goku> odd, no -q here: http://man.openbsd.org/nc
<cachio_> zyga, so, we need a Tumbleweed image on google right?
<zyga> cachio_: yes, very much please :)
<zyga> cachio_: how does it work, can I help you somehow>
<mborzecki> Son_Goku: maybe some other *BSD
<zyga> cachio_: tumbleweed is like arch, one image that we need to refresh periodically
<cachio_> zyga, let me check if there is something already created
<Son_Goku> not yet
<Son_Goku> openSUES project is working on it now
<Son_Goku> *openSUSE
<cachio_> ah, ok
<cachio_> do you know when they are going to push that?
<Son_Goku> btw, zyga, have you considered asking Fedora Server folks about official GCE images?
<mborzecki> Son_Goku: hmm, checked both netbsd and freebsd, none have -q, wth? yet, it's there in my manpage (and ubuntu manpages for that matter too)
<zyga> Son_Goku: no, I'm trying to wrap my head around existing bugs, I'd rather get the work started on the image building machinery for base snap
<Son_Goku> cachio_, ~6 months or so from now
<Son_Goku> they're working through all the cloud providers one by one
<cachio_> ok
<Son_Goku> as it is, they don't build VM images at all for Tumbleweed
<cachio_> zyga, Son_Goku in that case it is better to create our own image
<cachio_> zyga, I'll make a try
<cachio_> zyga, I'll keep you updated
<zyga> cachio_: thank you
<Son_Goku> cachio_, I'm working on gce packages now for Fedora
<cachio_> Son_Goku, great!! thanks
<cachio_> Son_Goku, just ping me when I can test them
<mvo> pedronis: do you have an opinion on https://github.com/snapcore/snapd/pull/5217#discussion_r191175426 ? (not urgent, just curious)
<mup> PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
<pedronis> mvo: added a couple of comments and answered
<Son_Goku> cachio_, building now: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/759564/
<cachio_> Son_Goku, awesome
<Son_Goku> it needed patching to work correctly with fedora :/
<Son_Goku> it has hardwired definitions for specific distros :(
<Son_Goku> so hopefully this should work
<cachio_> Son_Goku, good, I'll make a try today
<Son_Goku> and yay, python3 :)
<mup> PR snapd#5221 opened: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
 * zyga -> grocery shopping and kid after-class drop-off, back to mount business in 2 hours
<pedronis> mvo: did you see my comment in #5217 about not allowing base:Â if classic: true
<mup> PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
<diddledan> so.. if you can assign plugs to individual app sections in the snapcraft.yaml why are those individual assignments not shown in `snap interfaces`?
<diddledan> e.g. with this yaml which plugs are going to be shown? and why are they not individualised to explain the command that each is assigned to? it would show afaict, in `snap interfaces` as `plug-example` having plugs `plug`, `plug2`, and `plug3` but not explaining the differences between `app1` and `app2` https://www.irccloud.com/pastebin/Fz2zdeyX/
<diddledan> .. and if the individual apps all get the superset of permissions then why allow individual assignments at all?!
<zyga> diddledan: hey, I can explain that
<zyga> I will be home soon where it is more comfortable to type
<zyga> If you ask this on the forum please send me a link
<zyga> It will be easier for others to understand as well, ok?
<cachio_> zyga, we have a instance
<cachio_> opensuse-tumbleweed-64-v20180528
<cachio_> zyga, I created it manually because I had to deal with some dependenciy issues
<cachio_> then I'll create a script to create/update it automaticalle
<zyga> Super nice, I will test it in half an hour
<zyga> Thank you!
<zyga> Iâm 2km from home now. Just stuck in traffic
<cachio_> zyga, great, np, just ping me in case something is not working
<b_b> hi
<b_b> i've read many thread about gtk theme support for snaps
<b_b> and i'm wondering if i can start to play with https://github.com/snapcrafters/gtk-common-themes
<b_b> anyone knows ?
<zyga> re
<zyga> b_b: hey,
<zyga> I think you can start playing with them but you need to look at what they "do"
<b_b> hey zyga
<zyga> if you look at https://github.com/snapcrafters/gtk-common-themes/blob/master/snap/snapcraft.yaml#L13
<b_b> thx for the info, since my snap is stil on edge channel i think i can take the risk :p
<zyga> you will see that the snap provides several content slots, each with a different name and content type (which is implicitly the same as slot name)
<b_b> 'k
<zyga> I would recommend that you ask about this on the forum
<zyga> and ask James who wrote this
<b_b> on the way to use this snap  ?
<CustosLimen> hi
<zyga> yes
<CustosLimen> I installed snapd on fedora
<zyga> I suspect desktop helpers will use it somehow
<CustosLimen> and installed vlc via snap
<b_b> 'k
<CustosLimen> but not sure where to get the vlc binary that was installed
<zyga> but I'm not in the loop as for the fine details
<zyga> CustosLimen: hey
<b_b> i've searched a lot about it but didn't find any revelant info
<zyga> I suspect it may still be in the head of the few people working on this
<zyga> asking is the greatest way to pull this knowledge out into the light
<b_b> claro que si
<zyga> vale!
<b_b> ;)
<CustosLimen> nvm found it /var/lib/snapd/snap/bin/vlc
<CustosLimen> somehow it cannot access my disks though
<zyga> CustosLimen: you want to "snap run vlc"
<zyga> CustosLimen: after you log out and back in it should be on PATH
<zyga> and should show up in your application list
<CustosLimen> okay
<CustosLimen> how do I run vlc in classic confinement ?
<zyga> vlc is not made to work with classic confinement
<CustosLimen> so how do I get everything under normal locations in vlc?
<zyga> which normal locations? it depends
<zyga> usually you need to connect (some are auto-connected) a few interfaces and you should be fine
<CustosLimen> zyga, file /a/b/c on my system shows up as /var/lib/snapd/hostfs/a/b/c under snap vlc
<CustosLimen> zyga, can I somehow get it to show up normally?
<zyga> CustosLimen: is /a/b/c the real path? I really meant for the real real path you want to use because it does matter
<zyga> CustosLimen: if by normally you mean exactly at /a/b/c then no
<zyga> but for certain paths they do show up normally
<zyga> hence my earlier question
<CustosLimen> zyga, if I just cksum /a/b/c without using snap I can see fine
<CustosLimen> zyga, if I run snap run vlc /a/b/c vlc cannot find file
<zyga> yes, because from vlc's point of view /a/b/c doesn't exist
<CustosLimen> zyga, this is mounted disk under /srv/filesystems/something
<zyga> I see
<zyga> The /srv tree is not supported in snaps
<zyga> you must mount (or bind mount) it somewhere where you'd typically see content (e.g. to your home somewhere)
<CustosLimen> zyga, it is actually bind mounted under /var/opt/ also - but also nothing there
<Son_Goku> CustosLimen, you can't use that tree either
<Son_Goku> you're restricted to FHS 2.3/3.0 /usr tree, basically
<CustosLimen> can I not configure it somehow ?
<Son_Goku> nope
<zyga> CustosLimen: /var/opt is not supported either
<CustosLimen> okay
<CustosLimen> thanks for info
<Son_Goku> eventually, there'll be layouts, but that's more intended to be used to define base FHS for various base snaps
<zyga> you _can_ you can bind mount /a/b/c or _whatever_ you want to your /home/user/
<zyga> layouts are snap internal feature, users don't care about them actually
<CustosLimen> zyga, yeah
<CustosLimen> I will maybe do that
<CustosLimen> this works fine btw /var/lib/snapd/hostfs/a/b/c
<cachio_> Son_Goku, No match for argument: google-compute-engine-oslogin
<CustosLimen> for stuff under /svr/ and /var/opt
<cachio_> do I need to import any repo?
<CustosLimen> but anyway the snap for vlc does not solve issue I have with rpmfusion vlc anyway
<CustosLimen> I just wanted to confirm it is wider issue
<Son_Goku> cachio_, did you do "dnf -y copr enable ngompa/gce-oslogin" first?
<cachio_> no
<cachio_> tx
<CustosLimen> is there some way I can list older versions ?
<CustosLimen> I would like to install vlc 2.x if it is available
<CustosLimen> but not sure what versions there are
<CustosLimen> info shows newer versions
<zyga> snap info vlc
<zyga> CustosLimen: note that the developers of vlc decide which versions are installable
<CustosLimen> zyga, okay
<CustosLimen> zyga, but older versions not listed there are not installable ?
<zyga> that's correct
<CustosLimen> ok thanks for info
<b_b> see u ++
<diddledan> zyga: https://forum.snapcraft.io/t/why-are-interfaces-shown-in-aggregate-not-per-app-in-the-yaml/5647
<cachio_> Son_Goku, fedora 28 image added
<cachio_> scripts added too
<cachio_> I'll make a PR to run the tests on fedora 28 now
<Son_Goku> cachio_: cool
#snappy 2018-05-29
<mup> PR snapd#5222 opened: tests: adding fedora-28 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5222>
<mborzecki> morning
<mup> PR snapd#5220 closed: tests: moving test helpers from sh to bash <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5220>
<mup> PR snapd#5218 closed: many: expose AppStream IDs (AKA common ID) (2.33) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5218>
<mvo> mwhudson: hey, how does console-conf configures the network? I tried to use it on the WIP core18 images and it seems to be unable to configure the network here
<mvo> mwhudson: I will try to get access to the debug logs now
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mvo> mwhudson: one problem might be that there is (currently) no ifconfig, just the new "ip" on core
<mvo> mwhudson: fwiw, netplan itself seems to work (if I add a config manually it generates/applies that)
<zyga> good morning
<zyga> diddledan: thank you, I will respond
<diddledan> :-)
<mborzecki> zyga: hey
<zyga> :-)
<mvo> hey zyga
<mvo> niemeyer: could you please also add github.com/snapcore/pc-{i386,amd64}-gadget to the repors that mup monitors and announces here in the channel?
<zyga> diddledan: replied now
<mup> PR snapd#5223 opened: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <https://github.com/snapcore/snapd/pull/5223>
<zyga> hmm
<zyga> udisks2 is not implicit on classic
<zyga> pstolowski|afk: is this intended? AFAIK it was implicit before
 * zyga checks logs
<pstolowski> morning
<pedronis> IÂ don't think we changed anything about that directly
<pstolowski> zyga: as pedronis says
<pedronis> are we missing some call to addImplicitSlots ?
<zyga> no, it's just not marked as implicit
<zyga> and the code is not ready for it yet
<zyga> I assumed it was implicit on classic because it's such an old interface
<zyga> but now I recall it came to be for IOT first
<pedronis> afaict we added it for core
<pedronis> not classic
<pedronis> *afaicr
<zyga> yes, that's correct
<mborzecki> zyga: that tar exclude pattern is wrong too
<mborzecki> pushed a fix to sergio's PR, we should be able to merge it when the build is green
<mborzecki> need to make a quick run to the tax office, bb in ~1h or so
 * zyga -> coffee
<zyga> mvo: can you do one thing for me, open a terminal and run this
<zyga> autopkgtest-buildvm-ubuntu-cloud --verbose -r bionic -a amd64
<zyga> and let me know if this ever finishes for you
<mvo> zyga: what version of autopkgtest do you have installed?
<zyga> 5.0.2
<mvo> zyga: I have 5.3 and the command works for me - but I'm on bionic. at what release are you?
<mborzecki> re
<Chipaca> mornin' all
<pstolowski> hey Chipaca !
<Chipaca> pstolowski!
<Chipaca> how's things
<pstolowski> it's too hot
<pstolowski> and it's only May
<Chipaca> pstolowski: "it's only May" seems to be what a lot of people in the UK think
<Chipaca> anyhoo
<pstolowski> haha
<Chipaca> pstolowski: it was really hot yesterday (with almost-proper thunderstorms and everything!) but today there's a nice cool breeze
<zyga> Chipaca: so after May comes thunder?
<zyga> ;-)
<zyga> hey, how are you doing?
<Chipaca> zyga: not bad, you?
<mborzecki> Thunder sounds like a fitting name for someone from EDL
<zyga> Chipaca: dizzy a bit
<Chipaca> zyga: you pregnant?
<zyga> that'd be new :)
<pstolowski> pedronis: updated #5215
<mup> PR #5215: ifacestate: improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<pedronis> pstolowski: I'll look in a bit
<mborzecki> mvo: will core18 ship systemd in the snap too?
<Chipaca> mborzecki: yes
<Chipaca> although â¦ we could ship two core18s
<Chipaca> one for classic, with no systemd nor ssh nor nothing
<Chipaca> one for classicn't
 * Chipaca hides from the wrath of both grammarians and mvoians
<mup> PR snapd#5224 opened: interfaces: remove Plug/Slot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/5224>
<mborzecki> Chipaca: fwiw that's ~9-12MB (uncompressed) for just systemd
<Chipaca> it's probably not worth it
<Chipaca> i mean, given it's classic, bandwidth saving is probably the bigger thing, and it doesn't look like much
<Chipaca> it's one photo
<zyga> Chipaca: it's interesting given the relative popularity of core18 for booting vs not booting
<mup> PR snapd#5214 closed: cmd/snap: check with snapd for unknown sections <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5214>
<Chipaca> we should add two new snap types: boot, and jigsaw
<mborzecki> jigsaw
<mborzecki> well, nobody complained so far so maybe it's not worth it indeed
<mvo> Chipaca: two cores is interessting, the one for classic would be ~28MB, the one for core18 is ~42mb or so currently
<Chipaca> mvo: why that much smaller?
<mborzecki> mvo: that's the *.snap size or du inside?
<pedronis> it's very confusing in terms of building, in theory you can build an app for both
<pedronis> would always build only against the one for classic?
<mvo> Chipaca: systemd+ssh+netplan+console-conf
<mvo> Chipaca: but mostly netplan/console-conf which pull in most of python3
<mvo> mborzecki: outside
<Chipaca> mvo: no, i mean, current core is 87MB
<zyga> mvo: also apparmor userspace
<pedronis> then you convert one into the other when consider base?
<zyga> mvo: that's also python3
<Chipaca> pedronis: if we want to explore this, having a boot type might make more sense, exactly for those reasons
<mvo> Chipaca: aggressive cleanup, not sure if we can keep it this way, no vi, no ifconfig (just ip) no "less" etc
<zyga> mvo: there's always classic for that
<zyga> we should also think what classic does on 18
<Chipaca> mvo: also no desktop helper afaics
<mvo> Chipaca: yeah, thats a bug we should fix soon, those are small
<Chipaca> :-)
 * mvo thinks
<zyga> ironically slim core18 would be a very nice addition to embedded systems running classic distros
<Chipaca> mvo: https://forum.snapcraft.io/t/using-xdg-open-with-core18/5620?u=chipaca fwiw
<zyga> as the size increase is really small
<ogra_> why do you care for uncompressed ? (after all it will never be used uncompressed on any disk)
<Chipaca> ogra_: i don't think we do :-)
<Chipaca> ogra_: but it's worth asking, just to make sure we're talking about the same thing
<ogra_> Chipaca, mborzecki mentioned uncompressed sizes above ...
<Chipaca> otherwise chinese whispers grows
<Chipaca> ogra_: ah, that's just mborzecki being lazy :-p
 * Chipaca continues hiding
<ogra_> haha
<pedronis> Chipaca: my fear it adds complexity and surprises, not sure we are ready to deal with them
<ogra_> also on the developer/user side
<Chipaca> pedronis: agreed
<zyga> pedronis: I agree about that, perhaps it's something to slowly prepare post 18-boot (
<Chipaca> still, it does seem like nearly double the size
<zyga> (if we slowly march towards that for 20 I would be more comfortable)
<Chipaca> so worth considering (as in, writing down the reasons so we can explain to others / our future selves)
<pedronis> yea, it seems better as a goal for 20
<pedronis> than to cram it in now
<pedronis> so many open questions already, and this double some of them
<ogra_> if 20 is out embedded systems might not care for an extra 10-20MB on disk anymore :)
<zyga> there's one more point of view, it doesn't need to be that more complex, it's just that on 18-boot we keep what we have and rely on it and on 18-non-boot we can start to remove it over time (again, for 20)
<pedronis> nothing to do, win ;)
<zyga> I mean that on more complex boot case we don't change anything at all
<zyga> so that's a win indeed :)
<mborzecki> ogra_: that's true
<zyga> that case is more complex
<ogra_> (finding MMCs below 2GB is already hard today ... ad will actually cost you extra)
<zyga> the non boot case is really something we could explore without much risk
<ogra_> *and
<zyga> ogra_: (note that this doesn't shrink the MMC embedded case at all)
<zyga> this is just for making desktop users happier
<pedronis> zyga: not quite because  it's also a base, if everbody builds against the full one
<pedronis> you cannot change it
<zyga> pedronis: mmmm, indeed
<pedronis> as in remove stuff
<zyga> I take that back then
<zyga> because people would have to absolutely build against the stripped down version
<zyga> for this to work
<pedronis> yea, that's the tricky bit
<zyga> we might explore a 19 base
<zyga> with this property
<pedronis> that makes it hard to pull off
<zyga> to cook it for 20
<pedronis> while everything is in flux
<Chipaca> I mean, we could always do magic and replace core18 with core18-classic on classic
<Chipaca> down the road
<zyga> a new base, 19, without any boot support
<Chipaca> if we needed to
<zyga> Chipaca: yes
<niemeyer> mvo: Ack, will do
<mvo> we would have to ensure that the ABI of core18 is also provided by core18-boot but I agree it should not be a 18 goal, its already quite some work ahead as it is
 * zyga likes the core19 as an experiment
<Chipaca> niemeyer: good morning!
<zyga> but needs to be supported as short as 19.x ubuntu
<ogra_> call it core20 from the start and just iterate ;)
<Chipaca> niemeyer: i could use a bit of bikeshed paint on 'refresh.keep-inactive'
<zyga> ogra_: I don't think that's good, it may not be compatible with 20
<ogra_> ten call it core-experimental ;)
<ogra_> +then
<Chipaca> so, even cores stable, odd cores devel
 * Chipaca should stop putting crazy ideas out lest they continue to be taken seriously
<niemeyer> Chipaca: Hey, good morning
 * ogra_ quickly writes a softpedia article about Chipaca's masterplan of odd/even cores
<niemeyer> Chipaca: Sure, happy to bring my paint :)
<niemeyer> Chipaca: Is there a PR up already?
<Chipaca> niemeyer: https://github.com/snapcore/snapd/pull/5207
<mup> PR #5207: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <https://github.com/snapcore/snapd/pull/5207>
<Chipaca> niemeyer: i have it deconflicted and with tests locally, hoping to have a definitive name to rename things and do a single push
<Chipaca> actually still missing some tests though
 * Chipaca gets back to work
<ogra_> mvo, is there a chance that with core18 the pi config options can be moved out of core ? its so displaced there :/
<pedronis> mvo: btw I plan to do a proper review of #5217 today
<mup> PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217>
<niemeyer> Chipaca: Thanks, looking
<mvo> pedronis: \o/
<pedronis> ogra_:   well    we support calling those config   "system" as well now
<mvo> ogra_: we have an alias for those now: system
<mvo> heh :) snap
<pedronis> because of the bases stuff, but still no final plan
<pedronis> about the internals
<mvo> ogra_: whats your concern? where the code lifes? or the config schema (core.pi2-foo)?
<ogra_> mvo, that you have them on *every* UbuntuCore ... they should live in the gadget... it just makes me itch inside every time i think about it
<ogra_> core should be generic IMHO ... i always thought of the "pi config options in core" as an interim solution
<ogra_> and the swith to 18 seems like a natural moment to move that around to the correct place
 * zyga needs to, perhaps, redesign a small fragment of snap-update-ns path handling
<zyga> pen & paper time
<niemeyer> Chipaca: Reviewed
<Chipaca> 'ppreciated
<pedronis> ogra_: the issue at the time was that we would have needed some mechanism for snapd to filter what can be set or not, just letting the gadget write the file was deemed too unsafe
<ogra_> pedronis, yeah, i reemember why we are where we are, it would just be nice to move out of that situation eventually and moving to a new core fells like the natural time to do so
<ogra_> *feels
<ogra_> (and i'm aware that it moved out of core into snapd at some point ... which i find even worse)
<jamesh> niemeyer: do you have any opinions on the the interface naming in this PR? https://github.com/snapcore/snapd/pull/5184#discussion_r190942503
<mup> PR #5184: interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184>
<zyga> jamesh: hey!
<jamesh> hi zyga
<zyga> jamesh: there was a user a while ago asking about how to use the snap with common themes
<zyga> is there anything I could relay him to?
<jamesh> zyga: there's a published gtk-common-themes snap now (hopefully with the store allowing autoconnect soon), but at the moment it relies on adding a bunch of boilerplate to application snaps in order to use it
<zyga> right, is there anything that explains that and how to use it
<jamesh> I don't think we've got any docs on what that boilerplate should look like yet
<niemeyer> jamesh: Looking
<jamesh> zyga: gtk3-demo-snapcraft.yaml in https://gist.github.com/jhenstridge/7c1518dfb264014e28558fd03a1ed68a is close to what's needed (it doesn't have the default-provider listed though)
<jamesh> niemeyer: thanks!
<zyga> jamesh: excellent, thank you!
<Chipaca> where are we documenting config options?
<Chipaca> things like refresh.hold etc
<mborzecki> Chipaca: https://forum.snapcraft.io/t/system-options/87
<cachio_> mvo, hey
<niemeyer> jamesh: np, and thanks for the PR.. commented there
<mup> PR snapd#5207 closed: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5207>
 * Chipaca -> lunch
<cachio_> mvo, about the test snap-core-symlinks, it just works on google, but on the boards or ubuntu-core the core snaps in /var/lib/snapd/snaps are not linked to seeds
<jamesh> niemeyer: thank you
<jamesh> niemeyer: the main issue here is that these interfaces might be what we'd consider "legacy" interfaces, and it isn't obvious that we'd want to extend them to cover more than just EDS
<niemeyer> jamesh: In which sense is it legacy?
<jamesh> niemeyer: that's why jdstrand was gave eds-contacts as a possibility
<niemeyer> jamesh: I mean, other than it being for old services
<jamesh> niemeyer: that EDS hasn't been designed for confinement, so these are basically "all or nothing" interfaces
<jamesh> we can't give an app access to one address book or one calendar
<jamesh> (or one contact within an address book)
<niemeyer> Hmm
<jamesh> niemeyer: so if we ever get such an API, it would have quite different semantics to these snapd interfaces
<jamesh> (e.g. it might be quite safe to auto-connect an interface giving an app access to an app specific calendar)
<niemeyer> jamesh: Would we have an interface at all if that takes place?
<cachio_> mvo, https://paste.ubuntu.com/p/MbHN3jTfS6/
<niemeyer> jamesh: I mean, how would we allow access to _one_ contact
<cachio_> mvo, this is starting the image, no spread tests involved
<niemeyer> jamesh: Other than having an interface that would prevent general access in either case
<niemeyer> jamesh: In other words, would we have a "contacts-service" interface at all when that happens?
<jamesh> niemeyer: it would have to rely on the service mediating access similar to portals.  I think we had something like that as a trusted helper on Ubuntu Phone?
<niemeyer> jamesh: Right, exactly
<niemeyer> jamesh: So I see two possibilities once that takes place:
<niemeyer> 1) We have no interface at all, and grant the access in the base profile
<jamesh> niemeyer: the other naming issue brought up was KDE: it has its own backend with its own IPC (Akonadi).  It isn't clear whether that could be added to these interfaces or not: IIRC it isn't D-Bus based, so it might be giving access to a lot more than "only contacts" or "only calendars"
<niemeyer> 2) We have an interface, and require that to be connected to ask for a contact even then
<niemeyer> jamesh: In (1), we might just obsolete "contacts-service" (or any other name we pick)
<niemeyer> jamesh: In (2), I see no harm in providing access to both services in the same interface..
<niemeyer> jamesh: We're still confining the best we can for the available means
<jamesh> niemeyer: right.  So I think the suggestion to use "eds-contacts" would be to avoid squatting on a name we might want to use for the possible non-legacy interface
<niemeyer> jamesh: That KDE case needs to be understood indeed..
<niemeyer> jamesh: I get it.. the rationale above provide some feedback on why I suspect that might not be an issue
<niemeyer> jamesh: That said, the KDE case needs to be better understood
<niemeyer> jamesh: To make sure it's not evidence of a larger problem
<niemeyer> jamesh: We might try to use similar logic there, though.. what are the potential choices we have?
<niemeyer> jamesh: If KDE cannot be split, no possible interface name will suit it
<niemeyer> jamesh: If it can, the actual interface names do not matter
<jamesh> niemeyer: https://techbase.kde.org/KDE_PIM/Akonadi/Architecture says it is an IMAP-like protocol over a unix domain socket, with the store covering contacts, calendars, email, and other types
<niemeyer> jamesh: That makes it sound like it'd need a custom interface name for it
<niemeyer> "akonadi" being the obvious candidate
<jamesh> so it doesn't sound like we could restrict based on data type
<jamesh> I'm kind of leaning towards eds-contacts and eds-calendar, but don't feel too strongly about it (I'm basically just waiting for a decision so I can update the PR)
<niemeyer> jamesh: I'm not strongly in favor of something either, but let's please not go with "eds"
<niemeyer> That makes no sense to pretty much anyone that is not a frequent user of the software
<jamesh> niemeyer: I'd agree that "eds" on its own doesn't mean much.  But combined with "contacts" or "calendar" it has meaning
<jamesh> "akonadi" as an interface name would be equally impenetrable
<niemeyer> jamesh: Sort of.. google for both
<zyga> we also have the interface names
<zyga> but how about gnome-contacts, gnome-calendar
<zyga> s/names/summaries/
<zyga> and kde-{contacts,calendar}
<zyga> better than both eds and akowhatever
<zyga> (is akonadi a word or an acronym or just random letters?)
<niemeyer> jamesh: Another perspective: are there any other calendar services?
<niemeyer> zyga: Doesn't matter much
<niemeyer> jamesh: .. and even if there aren't, what if a new one is created.. would we want individual interfaces for all of them?
<niemeyer> jamesh: If so, why did we choose to bundle "password-manager-service"?
<jamesh> niemeyer: well, ideally everyone would move towards a common confinement friendly API that satisfies your scenario (1).  So apps don't necessarily program to a single one
<niemeyer> jamesh: The ideal scenario doesn't help us right now
<cjwatson> akonadi> "named after the oracle goddess of justice in Ghana" says wikipedia
<niemeyer> jamesh: Per early points, in the ideal scenario we can just obsolete everything else and have a base profile
<jamesh> niemeyer: right, but it is relevant to "what if someone invents yet another data store?" question
<niemeyer> jamesh: Right.. the question was supposing that this is not an ideal scenario
<niemeyer> jamesh: Another piece in the puzzle: we have unity8-contacts and unity8-calendar, and unity8-pim-common already
<niemeyer> So the scenario of having multiple "legacy" calendars is not theory
<niemeyer> Do we have any snaps using these interfaces today?
<niemeyer> I'm tempted to obsolete these interfaces, or potentially remove them if we have a trivial number of snaps published that leverage them and we can communicate with publishers
<jamesh> niemeyer: I think the unity8-* ones are from the unsuccessful attempt to port Ubuntu Phone to snappy
<niemeyer> and then not do the same mistake again
<jamesh> I know there's other phone interfaces we wrote that my team wrote that are effectively unused (e.g. thumbnailer-service + storage-framework-service)
<niemeyer> Besides having an "akonadi" interface, we might also have a "pim-service" interface that aggregates both calendar-service and contacts-service
<niemeyer> Or, alternatively, we might go the opposite way and enable akonadi only if both interfaces are connected
<niemeyer> That's all somewhat magical, though
<niemeyer> Having it explicit still feels saner
<jamesh> niemeyer: at the moment, the primary use case for these interfaces was to be able to snap the gnome-contacts and gnome-calendar applications, and probably have the store allow these apps to autoconnect
<jamesh> niemeyer: I'm not sure how many other apps would actually use them, since we're talking about highly sensitive personal data
<niemeyer> jamesh: Given all the conversation so far, gut feeling is still that "calendar-service" and "contacts-service" gets us to a reasonable place
<niemeyer> Very clear what data is at stake.. reusable if we find more use cases
<niemeyer> Doesn't prevent other alternatives
<jamesh> okay
<niemeyer> Follows existing conventions that are in use
<jamesh> I'll update to use that then.
<niemeyer> Thanks for the discussion
<pedronis> pstolowski|lunch: reviewed #5215
<mup> PR #5215: ifacestate: improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215>
<jdstrand> jamesh (cc niemeyer): for some historical context-- Ubuntu Touch had the same problem and used the same technology (eds). there was no application isolation with eds. also, unity8-contacts and unit8-calendar happen to also use eds; the difference with those interfaces is that they are designed with a slot implementation in mind,not as an implicit calssic interface
<jdstrand> on touch there was an addressbook service and iirc something for calendar, but they didn't provide any isolation. it was always planned they would at some point
<mvo> cachio_: thanks, thats interessting. I hvae a look in a little bit
<jdstrand> jamesh: re akonadi and imap over unix> yuck :)
<niemeyer> jdstrand: Wouldn't the interface be the same, whether it's designed with a slot upfront or not?
<niemeyer> jdstrand: Over time we had multiple cases that migrated towards offering a slot
<Chipaca> popey: 'snap set system refresh.retain=N' now on master
<jdstrand> niemeyer: it is essentially the same, yes (in fact, I compared them as part of my review for these new ones). the only difference is that jamesh' new ones we slightly more specific in some cases (which was understandable since we had a specific snap's label on the slot side)
<jdstrand> I figured we would probably deprecate the unity8 ones too
<jdstrand> (since these new ones were targetting real world use cases)
<jdstrand> niemeyer: the way that things are going with portals and classic desktop, I'm not sure we'll every have a slot side implementation for these new services, but I wouldn't rule it out
<jdstrand> I should have said 'new services' :)
<Chipaca> mvo: what's #5213 waiting for?
<mup> PR #5213: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/5213>
<Chipaca> oh maybe the last +1 is really recent :-)
 * zyga -> walk
<jamesh> jdstrand: the unity8-* interfaces seem to be missing some rules to talk to the source registry.  I wonder if they were relying on the com.canonical.pim.* interfaces for discovery instead?
<pedronis> Chipaca: yes
<pstolowski|lunch> pedronis: thank you!
<mup> PR snapd#5213 closed: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5213>
<mup> PR snapd#5225 opened: selftest: add new selftest package that tests squashfs mounting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5225>
<jdstrand> jamesh: I wondered that myself. iirc the unity8 ones didn't use path= everywhere so perhaps it was covered by them be less specific. alternatively, those are buggy and we never saw the bugs cause no one used them
<mvo> cachio_: what ubuntu-image do you use to create the image that then does not have the symlinks? the ubuntu-image deb or the ubuntu-image snap? I wonder if the "wrong" snap prepare-image is used here (the snap embedds that)
<jdstrand> jamesh: (I'm recollecting from the other day's review since I'm pulled aside atm)
<cachio_> mvo, the deb
<mvo> cachio_: and the machine that build the image had snapd 2.33~rc1 installed?
<cachio_> mvo, 16-2.33~rc1+git758.0a96f21 (4764)
<cachio_> it is edge
<mvo> cachio_: ok, I will try to reproduce
<mvo> jdstrand: could the review tools be updated for the new snapd snap? its a bit unusal, but not that much
<mvo> jdstrand: it will be uploaded nightly as a snap now
<jdstrand> mvo: it is a normal app snap? what do you want updated in the tools. I see snap-confine (fine). is that external symlink valid?
<jdstrand> package contains external symlinks: lib/udev/snappy-app-dev
<mvo> jdstrand: its a normal app snap. the symlink should be fine, I can make it relative though if that helps
<mvo> jdstrand: maybe I can even remove it entirely, its just for backward compatiblity. I need to look carefully
<jdstrand> mvo: well, the idea behind the test is that a symlink to outside the snap isn't guaranteed to have the target present and so may be broken. in this case, it's unclear, I mean, the snap is providing the target...
<jdstrand> mvo: I've fixed the snap-confine issue in trunk. I need to add some code for the symlink. let me know if it is needed
<zyga> jdstrand: ping me for the review, I'm always curious about that
<mup> PR snapd#5208 closed: interface hooks: update old AutoConnect methods <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5208>
<zyga> niemeyer: my understanding of the problem of parallel installs and classic confinement https://forum.snapcraft.io/t/special-bind-mount-for-snap-instances-including-classic-confinement/5666
<Chipaca> mvo: is current master 2.35?
<mvo> Chipaca: 2.34
<Chipaca> mvo: ah! i thought we'd split that already
<Chipaca> ok
<Chipaca> mvo: (asking for the "available since" thing in the docs)
<pedronis> Chipaca: we split 2.33
<pedronis> and now that is in beta
<zyga> 2.36
<zyga> because we could to show we, on average, increment once a month ;D
<Chipaca> zyga: quick quiz for you: how many months are there in a year
<zyga> Chipaca: how many do you need?
<Chipaca> zyga: no that's the _russian's_ line
<Chipaca> you're getting your jokes mixed up
<mvo> Chipaca: about 5225> you asked about squashfs without xz compression - I assume you ask for this to present a better error message?
<Chipaca> mvo: yes
<mup> PR snapd#5216 closed: many: holding refresh on metered connections (2.33) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5216>
<Chipaca> mvo: ie do the check for the xz one, if that fails do the same check with the non-xz one
<Chipaca> mvo: OTOH i'm not too happy about having a 4k var, having two would be right out :-)
<mvo> Chipaca: I think I can compress it, let me see
<Chipaca> mvo: dude, it's a squashfs :-)
<Chipaca> mvo: but, depending on how smart you want to be, you could drop the trailing zeroes and pad it when testing
<Chipaca> mvo: I can show you what I mean if you want
<mvo> Chipaca: yeah, this is what I had in mind, the zeros
<Chipaca> mvo: also perhaps encoding/ascii85 instead of encoding/base64
<mvo> Chipaca: is there a good cmdline tool?
<Chipaca> $ ascii85
<Chipaca> The program 'ascii85' is currently not installed. You can install it by typing:
<Chipaca> sudo apt install ruby-ascii85
<mvo> Chipaca: http://paste.ubuntu.com/p/xXxNzZZ5Xr/
<mvo> Chipaca: hrm, I pass, I don't want to install ruby just for that :)
<Chipaca> mvo: me neither :-)
<Chipaca> mvo: https://pastebin.ubuntu.com/p/pmv3FYP5HB/
<Chipaca> mvo: but that's probably cheating
<Chipaca> (also not exactly the same file because i was lazy in creating the canary.txt so don't use it as is)
<mvo> Chipaca: with gzip its 309 byte
<mvo> Chipaca: hm, 237
<Chipaca> mvo: and without gzip, but instead dropping trailing \0's?
<mvo> Chipaca: no idea, I was too lazy to write code for this
<Chipaca> :-)
<mvo> Chipaca: thanks a lot for your suggestion(s) - much nicer (and smaller) now
<Chipaca> mvo: https://pastebin.ubuntu.com/p/xNTmd4vYbb/
<Chipaca> mvo: the first one is base64, the second ascii85, both trimming trailing \0's, no gzip
<mvo> Chipaca: 296 - nice
<Chipaca> mvo: code for it if needed: https://pastebin.ubuntu.com/p/sY67dKbb6J/
<mvo> Chipaca: thank you, I will ponder about it. my gut feeling is that I want to be able to construct the "squashfs.image" string using std unix tools, hence gzip. but maybe I'm overly lazy here. going from 309byte to 200ish is a nice feature
<Chipaca> mvo: either is fine tbh
<Chipaca> mvo: make it a const instead of a var and you're home
<Chipaca> (or make the var inside the function)
<mvo> Chipaca: *cough* good point, thanks again
<Chipaca> (same thing, as the const will still be there, unnamed)
<mup> PR snapd#5224 closed: interfaces: remove Plug/Slot types <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5224>
<mvo> cachio_: I tried to reproduce the issue with ubunut-image and the symlinks. I installed ubuntu-image from the deb and refreshed my core to beta. snap version shows 2.33~rc1 for the snap. when I build an image with that combination I get the symlinks.
<mvo> cachio_: I'm trying the reboot problem now
<cachio_> mvo, seemlink issue is happening with the regular beta image
<cachio_> if you install the beta image created with ubuntu image you get the symlinks issue
<cachio_> then when you reboot from stable to beta and run the auto-refresh test you get the reboot issue
<cachio_> you can reproduce both with pc-amd64 or pc-i386
<mvo> cachio_: ok, so symlink issue: I did "ubuntu-image --channel=beta pc-amd64.model" and booted the resulted image (with systemd.debug-shell=1) and in there I can see the symlinks. what steps do I need to do to trigger the issue?
<mvo> cachio_: for the unexpected reboot> what do I need to do here? "ubuntu-image --channel=stable pc-amd64.model" and then "snap refresh --beta core" and then run the autorefresh tests?
<cachio_> mvo, well start the vm
<cachio_> I do
<cachio_> kvm -snapshot -smp 2 -m 2000 -redir tcp:8022::22 -nographic -serial mon:stdio <PATH_TO_IMAGE>
<cachio_> mvo, to create the image
<cachio_> https://github.com/sergiocazzolato/validator/blob/master/create.sh
<cachio_> I use that script
<cachio_> with params: beta pc-amd64
<cachio_> mvo, for unexpecte reboot
<cachio_> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-amd64.img.xz
<cachio_> then reboot to beta
<cachio_> refresh
<cachio_> and after the reboot, you run auto-refresh test
<cachio_> mvo, I see there are new stable images
<cachio_> I was using the factory ones which are older
<cachio_> I am using
<cachio_> zyga, on fedora 28 the owner for /home/test/.snap is root instead of test
<cachio_> zyga, do you know if is it ok?
<jdstrand> niemeyer: hey, I noticed in https://forum.snapcraft.io/t/classic-confinement-for-postman/5625/6 I no longer have a way to mark something as 'done' (ie, the little checkbox item I use from time to time). is the removal of this ability intentional?
<noise][1> i seem to have lost that ability as well
<Chipaca> jdstrand: noise][1: we bumped versions friday, maybe it's a regression?
<jdstrand> that's what I was wondering
<jdstrand> I wonder if we need to have an additional acl or something
<jdstrand> I vaguely recall that was needed before... by only vaguely
<jdstrand> but*
<Chipaca> jdstrand: I can't find it on topics I've created myself either
<mup> PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170,
<mup> snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225
<Chipaca> jdstrand: noise][1: it's a plugin, maybe the plugin needs updating?
<mup> PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170,
<mup> snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225
<Chipaca> we used to have a _lot_ of plugins, now there's just one
<Chipaca> niemeyer: ^?
<mup> PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170,
<mup> snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225
<mup> PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170,
<mup> snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225
<zyga> cachio_: hmm, /.snap is used for store auth typically, I think that's not okay but I don't know the reason
<mup> PR snapd#5226 opened: data: add systemd user environment generator <Created by mvo5> <https://github.com/snapcore/snapd/pull/5226>
<cachio_> zyga, this is fedora 28, -rw-------. 1 root root   44 May 29 14:48 auth.json
<cachio_> and this 27, -rw-r--r--. 1 root root   44 May 29 15:04 auth.json
<cachio_> this is making fail some tests
<cachio_> same for .snap dir
<zyga> does it fail if you run just one test? I mean if you add restore-each and just check the ownership and mode, will this show the difference
<zyga> also before you said it's owned by test user not by root, so which one is it?
<cachio_> zyga, I just ran 1 test
<cachio_> and it failed
<cachio_> so it is ok if it is owned by root
<zyga> is umask different?
<cachio_> but test user should be able to read
<cachio_> zyga, yes
<cachio_> 0022 and 0077
<zyga> well that looks like it
 * zyga boots f27
<zyga> I need to install f28 now
<zyga> why does everything hurt today,  ouch
<cachio_> hehee
<cachio_> it it the weather
<zyga> it feels like a flu
<pstolowski> pedronis: ugh, that auto connect conflict logic needs to be even more complex than what you suggested in the comment to the PR (i think). i think we need that FindSnapsWaitingFor helper i had before
<zyga> the weather is perfect, it's close to 30C and very sunny all day (weeks) long
<cachio_> nice, 26C here
<cachio_> but winter is comming
<zyga> here's still spring, I wonder how summer will look like
<zyga> 30C during daytime, 17 at night
<cachio_> it will be hot
<zyga> I hope summer time will be more wet
<zyga> there are a lot of forest fires otherwise
<zyga> and when it is wet and hot there's an explosion of mushroom to pick
<cachio_> hehehe
<cachio_> be careful
<zyga> I will spend most of school holidays with my parents a bit north of here, with the kids
<cachio_> there are poisoned ones
<zyga> nowadays with LTE anywhere it's really not a problem
<zyga> and with the upgraded data cap (1TB) I won't have to think twice about data
<zyga> yes, you have to be careful
<zyga> I only pick those that I always picked as a child
<cachio_> well, here if you leave the city the LTE connection is pretty bad
<zyga> there are several very safe species
<zyga> outside of cities you usually get 3/4G
<sil2100> mvo: heh... it looks like the VM is not the problem - seems like by default is doesn't seem to be able to build the snap correctly on anything below bionic
<zyga> I've been to the same place in 2016 (when I still had a MacBook for work)
<sil2100> mvo: mismatch between libc in the part itself and the one on the system
<zyga> but this time I have a better modem so I think it will be ok
<sil2100> (or something similar)
<zyga> and they keep expanding the network to cover more roads connecting bigger cities so I may even get LTE now
<cachio_> you have a 1TB plan ?
<zyga> cachio_: yes
<cachio_> that's pretty good
<zyga> cachio_: it's a data plan, it costs about 20 euro a month
<zyga> no phone calls included
<sil2100> mvo: I was just able to snap core18 correctly on a bionic VM - too bad travis doesn't seem to support bionic, it tries to pull things from precise in that case
<zyga> cachio_: my phone plan is different but I don't know what it is really, it came with a free sim for a laptop that gives me extra 100GB
<cachio_> zyga, zyga, it is pretty chip
<zyga> cachio_: and I still use my Spanish SIM which has 12GB of roaming everywhere so I stick to it instead of switching
<cachio_> hehee
<cachio_> zyga, conectivity here is expensive and not good
<cachio_> 10GB is about 40 euroos
<zyga> ouch!
<zyga> I wonder if my roaming would work there
<zyga> (the one from Vodafone.es)
<mvo> sil2100: hm, hm, ok. thats really unfortunate. but also slightly strange because I can "snapcraft cleanbuild" core18 and that will use a xenial lxd container unless I'm confusing things
<zyga> Chipaca: lol, https://www.bleepingcomputer.com/news/technology/npm-fails-worldwide-with-err-418-im-a-teapot-error/
<Chipaca> zyga: Â¯\_(ã)_/Â¯
<cachio_> mvo, could you reproduce any of those errors?
<sil2100> mvo: I didn't know about cleanbuild!
<sil2100> Let me experiment with that one
<zyga> cachio_: fedora 28 installing now
<cachio_> zyga, great
<niemeyer> jdstrand: Not intentional, looking into it
<sil2100> mvo: how do you run snapcraft cleanbuild so that the snapcraft inside the container is run with root? Since I seem to be getting errors when it's attempting to mknod
<zyga> cachio_: booting now
<zyga> cachio_: f28 umask is 0002
<cachio_> mmm
<cachio_> zyga, you mean in desktop?
<zyga> yes
<cachio_> in my desktop too
<cachio_> but in the cloud image is different
<cachio_> and the umask for root?
<cachio_> 0022?
<zyga> ah, root is 0022
<niemeyer> jdstrand: We lost the plugin on the upgrade
<cachio_> so I should chnage deafult nmask in the google image and that's it?
<cachio_> umask
<zyga> cachio_: I think we should handle this in spread.yaml
<zyga> as otherwise we will get a "magic" image that is not representative of fedora
<cachio_> zyga, ok, I'll add that to the PR in that case
<zyga> cachio_: note that on f27 the same umask is used
<zyga> 0022 for root, 0002 for user
<niemeyer> jdstrand: deej will bring it back this afternoon
<jdstrand> niemeyer: cool, thanks! :)
<kyrofa> Hey Chipaca, give me some love: https://forum.snapcraft.io/t/snapd-rest-api-expose-bind-mount-root-in-tried-snaps/5608
<Chipaca> kyrofa: just looking into that
<kyrofa> Chipaca, ha!
<kyrofa> Hey niemeyer, mind if I schedule a quick chat about https://forum.snapcraft.io/t/fixing-the-snapcraft-cache-lp-1582469/4127 ?
<sil2100> mvo: btw. I'm constantly wondering, is the part name 'boostrap' a typo or is it intentional? ;)
<cachio_> zyga, so, in fedora 28 image the umask is ok
<cachio_> 0022
<zyga> cachio_: hold on, as root or as user?
<cachio_> but then I updated it to make the selimux permissive and the umask went to 0077
<cachio_> as root
<cachio_> I did dnf makecache and dnf upgrade -y
<zyga> that's ... weird
<zyga> what did you do to make selinux permissive?
<cachio_> and reboot
<cachio_> sed -i 's/SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config
 * zyga tries
<niemeyer> kyrofa: Not at all, thanks for that
<zyga> cachio_: rebooting
 * niemeyer => break
<zyga> cachio_: I changed SELINUX to permissive and rebooted, umask wasn't affected
<zyga> cachio_: there must be another modification at play
<cachio_> zyga, I'll regenerated the fedora image
<cachio_> same than yesterday but without reboot
<cachio_> checking how it was generated
<cachio_> zyga, it is the same
<zyga> meaning? it's the same as mine or the same as yours before the regexen?
<zyga> regeneration
<cachio_> 0077 after the regeneration
<zyga> hmm
<zyga> this was based on the cloud image?
<zyga> I will try that
<zyga> how do you make the image?
<cachio_> now I am running a regeneration which just changes the selinux config bht it is not updating
<cachio_> the base fedora 28 image it is already created
<zyga> how was it created?
<cachio_> with this script
<cachio_> https://github.com/snapcore/spread-images/blob/master/tasks/google/add-fedora-28-64/task.yaml
<zyga> thanks
<zyga> I'm pulling the same disk now
<cachio_> zyga, so, using the fedora 28 image
<cachio_> which has umask 0022 for root
<mvo> sil2100: *cough* typo but funny
<cachio_> zyga, wait
<cachio_> I think I know which is hte issue
<zyga> :-)
<zyga> I just booted the image
<mvo> cachio_: I had no luck with the missing symlinks, but I ran manually not from your script. I didn't manage to try the second one unfortunately
<cachio_> on the cleanup we are deleting /root/.bashrc
<mvo> sil2100: iirc it is run as root
<zyga> oh
<cachio_> mvo, ok, I'll try again with the latest changes
<cachio_> mvo, it is weird beause it failed in all the runs the symlink test
<mvo> cachio_: yeah, I can try from the script in the morning
<cachio_> zyga, I am regenerating the image without deleting the .bashrc
<pedronis> pstolowski|afk: mmh, we are probably talking past each other if there's a relevant link-snap there is probably also an auto-connect task
<pedronis> which would make us ignore the former
<pedronis> pstolowski|afk: we can talk again tomorrow morning, IÂ might be missing something
<jdstrand> roadmr: hi! would you mind pulling r1081 or the review tools? it isn't terribly urgent, but sooner is better than later (it isn't an emergency though)
<jdstrand> ogra_: fyi, you probably got these, but I saw that 'Store authorization failed for linux-generic-bbb'
<cachio_>  zyga, that was the problem
<cachio_> zyga, I regenerated the image and umask is 0022
<cachio_> the issue was that it was cleaning the /root/.bashrc
<cachio_> this cleanup is pretty old
<cachio_> it comes from linode
<cachio_> zyga, something changed on that file on fedora 28
<zyga> cachio_: yes, that file just sources /etc/bashrc which sets umask
<om26er> Chipaca: Hi! got a minute ?
<om26er> its about `http` snap, a feature request :)
<mup> PR snapd#5227 opened: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5227>
<mup> PR snapd#5228 opened: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors (2.33) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5228>
<jdstrand> niemeyer: hey, if you have a moment to look at https://github.com/snapcore/snapd/pull/4951, I implemented your changes last week
<jdstrand> your requested*
<mup> PR #4951: interfaces/screenshot: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
<cachio_> zyga, this change fixed all the failing tests on fedora 28 :)
<cachio_> zyga, thanks for the support
<zyga> Woot, Thank you :-)
<Pharaoh_Atem> wut?
<Pharaoh_Atem> wut the wut?
<Pharaoh_Atem> what happened?
<zyga> Bad rm nuked bashes
<zyga> Bashrc
<mup> PR snapd#5229 opened: interfaces: add juju-client-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5229>
<Pharaoh_Atem> zyga: ah
<Pharaoh_Atem> zyga: what's going on here? https://github.com/snapcore/snapd/pull/5219#issuecomment-392899258
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<mup> PR snapcraft#2144 closed: lifecycle: automatically stage dependencies <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2144>
<niemeyer> jdstrand: ouch.. I didn't realize the details of the interface
<Pharaoh_Atem> zyga: Flock 2018 has been announced
<Pharaoh_Atem> Dresden, Germany this time: https://flocktofedora.org/
<zyga> Oooh
<zyga> Count me in then
<zyga> I will plan the trip and come
<zyga> We need to present bases :-)
<niemeyer> jdstrand: This is such a bad API
<niemeyer> :(
<sergiusens> kyrofa: commented on https://github.com/snapcore/snapcraft/pull/2145/files
<mup> PR snapcraft#2145: lifecycle: automatically clean dirty steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2145>
<zyga> Pharaoh_Atem: https://github.com/snapcore/snapd/pull/5219/files#r191545658
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<sergiusens> kyrofa: I have a minor request and a non mandatory counter-proposal that brings an implicit behavior most people seem to expect (ordered yaml)
<sergiusens> that's for snapcraft#2146
<mup> PR snapcraft#2146: project_loader: process parts in consistent order <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2146>
<jdstrand> niemeyer: yeah. at least it is manually connected... :\
<Pharaoh_Atem> zyga: but openSUSE uses /run/media
<zyga> let's not change that now, we can tweak it (perhaps set it conditionally) and fix the test
<niemeyer> jdstrand: Yeah, but it feels too misleading
<niemeyer> jdstrand: It's an awkward precedent
<Pharaoh_Atem> zyga: so the test has always been wrong then?
<niemeyer> jdstrand: So the interface allows saving files *anywhere*?
<jdstrand> niemeyer: we can say "no, we won't support this. wait for portals"
<niemeyer> I mean, anywhere the uid calling the API has access to, I suppose
<zyga> Pharaoh_Atem: perhaps it was right before, are you sure opensuse used /run/media?
<Pharaoh_Atem> Yep
<Pharaoh_Atem> openSUSE Leap 42.x, 15.0, and Tumbleweed use /run/media
<jdstrand> niemeyer: yes. there is some default actions but the dbus api allows specifying the outpath. we can't mediate that in apparmor because it is member data. gnome-shell would have to mediate it with the libapparmor query api to mediate it properly
<zyga> in that case the test will need tweaking
<jdstrand> niemeyer: and yes, anywhere the unconfined gnome-shell is allowed to write to
<Pharaoh_Atem> the switch that changes this for debian (https://salsa.debian.org/utopia-team/udisks2/blob/master/debian/rules#L13), is not set in openSUSE: https://build.opensuse.org/package/view_file/Base:System/udisks2/udisks2.spec?expand=1
<Pharaoh_Atem> they switched to /run/media in 2012
<jdstrand> niemeyer: it is probably worth reiterating (this was mentioned in the forum) that this gnome-shell api is intended to be a temporary api unitl the pipewire (screencast) and a proper portals screenshot api was in place
<niemeyer> jdstrand: I feel pretty bad for saying this now, but I think you had it right the first time around, and I didn't realize because I missed those details
<jdstrand> niemeyer: that said, it has been a long time and screencasting doesn't work yet with pipewire
<niemeyer> jdstrand: To be clear, I feel bad not because I was wrong, but because you spent time on it
<jdstrand> niemeyer: well, the it's a weird access. I mean, desktop-legacy already has some terrible stuff, but desktop-legacy is auto-connected. I think the question is do we want this to be autoconnected or not
<niemeyer> jdstrand: Still, the open path writing is still something that raises eyebrows even in legacy desktop
<niemeyer> jdstrand: Do we have an equivalent access there?
<jdstrand> niemeyer: no. just full keyboard sniffing and injection. you know, nothing that bad :P
<jdstrand> (accessibility)
<niemeyer> Well, it's just about expectations.. X11 is what it is
<jdstrand> niemeyer: and don't feel bad. it doesn't take long to shuffle stuff around
<jdstrand> well yes
<jdstrand> x11 is one thing, but desktop-legacy doesn't have x11
<jdstrand> it is theoreticlly possible to plugs: [ desktop, desktop-legacy, wayland ]
<niemeyer> jdstrand: Are both APIs exposed in the same term (screencast and screenshot)?
<niemeyer> same terms
<jdstrand> niemeyer: we can differentiate between screenshot and screencast. both have the same issue with outpath
<niemeyer> Hmmm
<jdstrand> perhaps to confuse things further, X allows screen grabs (screenshot) via the X protocol. gnome-shell is exposing these mostly for the benefit of wayland, but you can use this dbus api under X if you want
<mup> PR snapcraft#2145 closed: lifecycle: automatically clean dirty steps <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2145>
<jdstrand> but you had it right the first time. it is a terrible api. I think the idea is that they added it to gnome-shell since it is no worse than X. since mutter isn't a complete X replacement yet, they probably figured they'd fix this in the fullness of time with portals
<jdstrand> I'm guessing, but I can easily imagine that is how the conversation went
<niemeyer> jdstrand: Indeed
<niemeyer> jdstrand: Okay, let's sleep on that one.. the brain isn't yielding any great ideas right now
<jdstrand> niemeyer: sure, np. I'm kinda leaning towards the manually connected separate interface atm, but we can continue thinking about it
<niemeyer> In fact, I'll probably do that literally.. woke up somewhat early and I need a nap to refresh a bit
<jdstrand> hehe
<jdstrand> have a nice rest :)
<niemeyer> Thanks :)
<jdstrand> it's super-annoying to wake up early and not be able to get back to sleep
<mup> Issue # closed: snapcraft#100, snapcraft#1438, snapcraft#1440, snapcraft#1441, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1455, snapcraft#1456, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1463, snapcraft#1465, snapcraft#1467, snapcraft#1468,
<mup> snapcraft#1469, snapcraft#1476, snapcraft#1477, snapcraft#1502, snapcraft#1658, snapcraft#1660, snapcraft#1665, snapcraft#1677, snapcraft#1678, snapcraft#1679, snapcraft#1696, snapcraft#1701, snapcraft#1705, snapcraft#1706, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794,
<mup> snapcraft#1882, snapcraft#1887, snapcraft#1921, snapcraft#1932, snapcraft#2001, snapcraft#2027, snapcraft#2032, snapcraft#2048, snapcraft#2118, snapcraft#2133, snapcraft#2134, snapcraft#2136, snapcraft#2137
<Chipaca> om26er: here now
<sergiusens> kyrofa et.al catch you later in the night
 * sergiusens is off to aikido practise
<mup> PR snapd#5230 opened: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230>
<om26er> Chipaca: I am making a form-data post request that uploads a file and it gives permission denied. So maybe if the http snap added `home` interface, things will get more usable.
<mup> PR snapd#5231 opened: interfaces/joystick: force use of the device cgroup with joystick interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5231>
<Chipaca> om26er: noted. Meanwhile you can use bash's process substitution
<Chipaca> om26er: e.g. foo=@<( cat the-file.json )
<om26er> Chipaca: Thanks, in this case its a png file, will see how that goes.
#snappy 2018-05-30
<zyga> good morning
<mborzecki> morning
<zyga> hey
<mborzecki> zyga: anything on fire today?
<zyga> nothing apart from my joints
<zyga> everything hurts as if I had a flu
<zyga> there's one bug about apparmor but it looks like partial removal of snapd
<mborzecki> your joints hmm? :)
<mborzecki> zyga: #177351 ?
<mup> Bug #177351: evince crashed with SIGSEGV in CairoOutputDev::setCairo() <apport-crash> <evince (Ubuntu):Invalid by desktop-bugs> <https://launchpad.net/bugs/177351>
<mborzecki> damn, not that one, this one #1773515?
<mup> Bug #1773515: apparmor fails after removal of snapd <snapd (Ubuntu):New> <https://launchpad.net/bugs/1773515>
<zyga> mborzecki: yeah, that one
<zyga> drat
<zyga> I made an appointment today to replace my phone battery at a service centre
<zyga> sigh
<zyga> what a day
<zyga> well, ok, it's at 10:00 AM, close by, I can just go and work from some place nearby
<zyga> I will just login home and work this way
<zyga> I updated to bionic yesterday to have more recent autopkgtest
<zyga> I find the whole image construction toolkit super fragile
<zyga> it times out, doesn't say what's going on, etc
<zyga> Iâm going to the service center now
<zyga> I will install myself there and just work
<zyga> ETA 30 minutes
<zyga> Iâm close now but man, committing at this time is not fun
<zyga> re :)
<zyga> I'm at a starbucks exactly in front of the service center, time to work
<zyga> mborzecki: mvo will be around later today
<mborzecki> ok
<zyga> mborzecki: can you please look at #5231
<mup> PR #5231: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5231>
<zyga> we need to cherry pick it into the release branch as well
<mborzecki> zyga: to recap, this is to have the device cgroup created always, using a device (/dev/full) that we're sure is present at all times, right?
<zyga> yes, almost,
<zyga> we don't make device cgroups unless there's a device tagged with an udev tag that matches the app we're running
<mborzecki> btw. reading systemd-environment-generators manpages, it's a nice feature of systemd
<zyga> and if you give broad apparmor permissions (like all of input devices here)
<zyga> and not tag any dveices
<mborzecki> yup
<zyga> then there's no cgroup and you can do anything you want
<zyga> mborzecki: I know, I talked to zbyszek about it about a year ago when I was trying to figure out how to inject /snap/bin into PATH in a nicer way than we did before
<zyga> he suggested environment generators but they were not merged back then :)
<mborzecki> zyga: any idea how far back in systemd versions this feature is available?
<zyga> it's very recent
<zyga> this is why I made a remark about it on the PR
<zyga> I don't know how we plan to use it across the released versions of systemd people are using
<mborzecki> zyga: why not just always create the device cgroup? i see in the code that we're adding a bunch of static devices iff there are any (other) devices tagged for particular snap
<zyga> that's my feedback as well
<mborzecki> oh and i see nvidia ...
<zyga> nvidia is a special snowflake because they cannot use GPL symbols and udev
<mborzecki> zyga: there's a chance that device group by default may break some snaps
<pstolowski> morning
<mborzecki> or at least that's my guess why jdstrand didn't go down this path
<mborzecki> pstolowski: hey
<zyga> hey pawel
<zyga> mborzecki: note that nvidia works with udev tagged devices today
<zyga> we have special code for taht
<zyga> in my review I gave a +1 but indicated that we should probably not make mistakes again by simply always doing a cgroup anyway
<mup> PR snapd#5227 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5227>
<mup> PR snapd#5228 closed: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors (2.33) <Simple> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5228>
<pedronis> pstolowski: hi, should we chat again?
<pedronis> zyga: tagging short udev related PRs with "simple" is a bit misleading I think
<zyga> because it's udev?
<pedronis> because  reviewing quickly to means IÂ should not need to be on alert for subtle issues
<pedronis> by definition a PR that solves a subtle issue cannot be quick to review
<mborzecki> zyga: maybe i'll play a bit with that change to snap-confine later today
<pedronis> zyga: same for the new interface PR
<zyga> but the issue is very clearly stated there
<zyga> pedronis: the ones about sensors?
<pedronis> any of them
<pedronis> again I don't think they can be simple
<pstolowski> pedronis: probably, but give me a few moments to collect thoughts
<pedronis> zyga: you invented the label, but if I need to read the description carefully
<pedronis> it is also not simple
<pedronis> zyga: simple is something that can be reviewed before coffee
<pedronis> otherwise is just a trap
<pedronis> of mindless +1
<zyga> mmm,
<pedronis> and we should remove the label
<zyga> I'll apply more restraint
<zyga> there's certainly the case that everyone is familiar with a specific part of the code more closely
<zyga> and indeed then the label can be deceptive
<pedronis> ok, then again it cannot be simple
<pedronis> (because everybody sees the label)
<zyga> pedronis: some quick feedback on #5221
<mup> PR #5221: [RFC] snap: parse connect instructions in gadget.yaml <Created by pedronis> <https://github.com/snapcore/snapd/pull/5221>
<Chipaca> pedronis: WDYT of adding a "mounted-from" key to snaps' json, and have that be the EvalSymlinks of the MountFile of all snaps?
<pedronis> Chipaca: seems ok to me
<Chipaca> k, i'll push a pr for that soonish
<pedronis> zyga: I'm sort of tempted to kill the label completely tbh, the fact we don't agree how it should be used it's probaly a sign is a nuisance
<zyga> pedronis: I'd like to keep the label because it's an encouragement to look at PRs
<zyga> we should just agree how to use it
<pstolowski> pedronis: ok, i'm ready when you're
<mup> PR snapd#5232 opened: interfaces/builltin/tpm: Allow access to the kernel resource manager <Created by yphus> <https://github.com/snapcore/snapd/pull/5232>
 * zyga notices a ~2K lines changed PR and wonders if 30 minutes is enough time to even look 
<pedronis> which one?
<pedronis> pstolowski: joining
<zyga> spineau: hey, do you have any links about what the TPM resource manager is for?
<spineau> zyga: I'm collecting them right now
<zyga> thanks
<zyga> please add them to the PR
<mup> PR snapd#5231 closed: interfaces/joystick: force use of the device cgroup with joystick interface <Critical> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5231>
<zyga> popey_: https://forum.snapcraft.io/t/is-the-author-of-a-package-verified/5671
<zyga> something that well deserves a good answer
<zyga> ok
<zyga> Son_Goku: hey
 * zyga needs to go to the service center
<zyga> Son_Goku: please review your PRs, there's feedback and patches but we cannot push to your branch
 * Son_Goku waves at zyga 
<Son_Goku> I pushed the patch requested
 * zyga goes to replace his phone battery now
<zyga> ttyl
<zyga> thanks! I'll check soon
<mborzecki> Son_Goku: hey, left you a link to a patch that fixes media-sharing in opensuse pr
<Son_Goku> mborzecki: done already
<Son_Goku> now we wait forever for spread :D
<mborzecki> hehe :)
<mborzecki> forever as in ~30 minutes
<mup> PR snapd#5233 opened: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <https://github.com/snapcore/snapd/pull/5233>
<zyga> re
<zyga> my phone should have a brand new battery by noon
<zyga> mvo: hey, welcome back
<mvo> zyga: hello
<Chipaca> mvo: you're not under water are you?
<mvo> Chipaca: no, all good
<Chipaca> mvo: throw one bubble for yes, two bubbles for no
 * Son_Goku throws three bubbles at Chipaca 
 * Chipaca starts selling a dragon-based arcade game remake reusing Son_Goku's bubbles
<Son_Goku> :D
<Son_Goku> ahh Spyro :)
<Chipaca> bubble bobble, you uncultured yob
 * Chipaca removes his monacle
<Chipaca> that thing's evil
 * zyga wonders what is going on 
<Chipaca> zyga: an area in the west of germany (but a few km from mvo) is under water
<zyga> spineau: feedback on your PR
<Chipaca> zyga: also bubble bobble is a game with dragons that throw bubbles and that makes no sense
<zyga> Chipaca: because dragons make sense ;-) ?
<Chipaca> zyga: about as much sense as unicorns
<Son_Goku> :D
 * zyga sings "narwhals"
<spineau> zyga: thx, I was wondering which one caused the error
<mvo> Chipaca: yeah, some heavy rain here in the area but where I am its mostly fine
 * zyga just moved further away from the window becase OMG SO HOT today 
<zyga> it's weird not to have one's phone around
<pstolowski> pedronis: ok, i think i nailed the conflict check.. at least the tests seem happy
<zyga> it's the most important thing to bring in many ways
<mborzecki> 29C in the shade here
<mborzecki> zyga: do you want one last look at #5219 ?
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<zyga> yep, looking
<pedronis> fun fact, the man page of mount uses both "file system" and "filesystem" at the same time
<Son_Goku> that's... annoying
<pedronis> well to be fair, the former only a few times
<zyga> mborzecki: one question on this https://github.com/snapcore/snapd/pull/5219#discussion_r191685550
<mup> PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219>
<zyga> mborzecki, Pharaoh_Atem do you know what's the tumbleweed version in the RPM macro?
<zyga> I'm AFK from my home machine to check
<mborzecki> Son_Goku: there's some fine print note about tumbleweed version right here: https://en.opensuse.org/openSUSE:Packaging_for_Leap#RPM_Distro_Version_Macros
<zyga> I mean, it's 1555
<mborzecki> zyga: ^^
<zyga> but what will happen later
<zyga> I know, I read that :)
<zyga> sorry, my question on the PR was worder better than my question here
<Son_Goku> you can't not rely on it in some fashion
<zyga> right but I'm trying to guess if the next leap will have all the features we target for tumbleweed today
<zyga> if so that's even better
<Son_Goku> but basically if you use it as a checkpoint (that is, don't do 0%{?suse_version} == 1550), you're fine
<Son_Goku> zyga, well, Leap is branched from Factory
<Son_Goku> err, SLE is branched from Factory
<Son_Goku> and Leap is cloned from SLE
<zyga> and tumble?
<Son_Goku> and Tumbleweed is regular snapshots of Factory
<mborzecki> we should be good with >= check then
<Son_Goku> yes
<Son_Goku> SUSE has made version checking harder than it should be :/
<zyga> +1 then, let's mere it
<mborzecki> aaand merge
<mborzecki> (d)
<Son_Goku> ugh
<Son_Goku> I hate touching openSUSE packaging sometimes
<jamesh> mvo: any chance you could approve the two new revisions of the test-snapd-eds snap? (this is just changing interface names based on the review)
<mborzecki> zyga: do you plan to sync the spec in obs?
<mup> PR snapd#5219 closed: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5219>
<zyga> mborzecki: yes but only for the next release
<mborzecki> zyga: ack
<mvo> jamesh: sure, let me do that right away
<jamesh> mvo: thank you!
<Son_Goku> zyga, don't forget to merge my changes entry into the OBS changes file
<zyga> .33 is branched, once we are good for release we should do it in OBS as well
<zyga> Son_Goku: ack
<mup> PR snapd#5234 opened: [RFC] snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<Son_Goku> I guess since I'm up already and looking at this
<Son_Goku> might as well add the %bcond to create the /snap symlink in the spec for amazon linux in the fedora spec
<Chipaca> May 30 08:17:56 arch snapd[10146]: 2018/05/30 08:17:56.829601 helpers.go:521: cannot retrieve info for snap "test-snapd-content-slot": cannot find installed snap "test-snapd-content-slot" at revision 2: missing file /var/lib/snapd/snap/test-snapd-content-slot/2/meta/snap.yaml
<Chipaca> who was looking into the disappearing meta/snap.yaml bug?
<Chipaca> zyga: was that you?
<zyga> Chipaca: that was perdronis and to a small extent me
<zyga> is that on your system or in spread?
<Chipaca> https://api.travis-ci.org/v3/job/385570236/log.txt
<Chipaca> was wondering whether I should keep that, or just blow it away and retry
<zyga> hmmm
<zyga> I'd be much happier from a user report, our tests do so much magic I don't trust some of those failures
<zyga> - Mount snap "test-snapd-content-slot" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount failed.
<zyga> mount failed
 * zyga looks for the journal error
<mborzecki> Son_Goku: why the dislike for opensuse packaging?
<zyga> it timed out https://www.irccloud.com/pastebin/5xyF1sNO/
<zyga> Chipaca: interesting, I wonder why it can ever do that
<Son_Goku> mborzecki, I don't generally have a problem with openSUSE packaging as a whole
 * zyga scans the log for more clues
<Son_Goku> I actually do quite a lot of it these days
<Son_Goku> but one thing that has annoyed me a lot is that figuring out how to detect what release I'm targeting for a build has become a ton more difficult
<zyga> woah
<zyga> protocol error again :) https://www.irccloud.com/pastebin/DNFrcteJ/
<Chipaca> zyga: whassat
<zyga> Chipaca: so, at this stage I'm tempted to get to the bottom of the stack to see what the hell is a protocol error
<zyga> is that kernel doing barf
<zyga> systemd doing barf
<zyga> or something else
<Chipaca> zyga: if it were the kernel wouldn't something in the journal say so?
<mborzecki> Son_Goku: heh, that version macros matrix is a bit confusing
<zyga> Chipaca: because the kernel is known for its impeccable error reporting
<zyga> ;-)
<zyga> Chipaca: I wonder if there's some logging going on that we don't show
<zyga> e.g. stuff in dmesg that doesn't end up in the journal
<zyga> May 30 08:18:01 arch snapd[10146]: May 30 08:17:59 arch kernel: print_req_error: I/O error, dev loop2, sector 0
<Chipaca> there shouldn't be, but Â¯\_(ã)_/Â¯
<zyga> ooh
<zyga> is our snap corrupt?
<zyga> that is building and installing the snap in devmode
<zyga> so we send the snap over a socket
<zyga> maybe there's a race and we get garbage
<zyga> Chipaca: how would you feel if we added CRC to side-loaded snaps
<zyga> for transfer
<zyga> client and server both compute on the fly
<zyga> and then the client sends at the end
<zyga> mm?
<zyga> more IO errors https://www.irccloud.com/pastebin/lx013vGf/
<Chipaca> zyga: if we were looking to do work in that area, I'd look instead at passing a file descriptor
<zyga> but look, loop1 and loop2
<zyga> I wonder what's going on there
<zyga> I wonder if this is "I cannot read the loop device"
<sil2100> mvo: hey! I have a hacky branch that fixes running travis CI on core18 (and non-bionic systems)
<zyga> or "I read the loop device but man this is not a valid squashfs"
<sil2100> mvo: (the CI is failing for it as there are actual failures in the tests now)
<Chipaca> zyga: what happens if you grab a squashfs, truncate it, and mount it
<sil2100> mvo: it's ugly, but besides being ugly currently it shouldn't have any real side-effects
<Chipaca> zyga: truncate it by a half or sth i mean, not empty
<zyga> hold on
<zyga> Chipaca: this is not a side-load
<zyga> it's from the store
<zyga> and we apply a delta
<zyga> it's a delta https://www.irccloud.com/pastebin/6kcddRIr/
<zyga> ah, no
<zyga> I'm blind sorry
<zyga> it's not a delta
<zyga> it's a store pull
<zyga> we check store assertions that they match the downloaded blob, right?
<Chipaca> zyga: yes
<zyga> hmm hmm hmm
<pedronis> yes, that's what validate-snap does
<zyga> so we have a valid snap
<zyga> yet the kernel chokes on mounting it
<zyga> but one out of 100s we tested
<zyga> and randomly
<Chipaca> zyga: and if it were a delta, we hashsum the chunks, and then hashsum the resulting squash after applying the delta
<zyga> because of the validate I don't think the snap is corrput
<zyga> more like a rare bug in loop devices
<pedronis> the store doesn't try to mount it though
<zyga> but this is just guessing
<pedronis> it should resquash it
<pedronis> and compare
<zyga> pedronis: yes but here it's one of the snaps we test dozens of time a day
<zyga> I bet if the blob arrived safely it is not the content that is at fault
<zyga> we don't change that snap often
<zyga> and it mounted and worked fine on all the other tests
<zyga> (in the same run)
<Chipaca> zyga: i'm about to hit restart on the test unless you shout
<mvo> zyga: it might be that the network data is fine but it got corrupted while writing to disk
<zyga> go
<zyga> restart
<zyga> mvo: mmmm, yes, perhaps
<zyga> mvo: that's interesting
<zyga> maybe google SSDs are just not what they used to be
<pedronis> mvo: well we check it again in validate-snap
<zyga> and once in blue moon we will hit this one bit flip
<pedronis> but the pastebin doesn't have that bit
<mborzecki> zyga: there's your failed with result protocol: https://github.com/systemd/systemd/blob/5300857701ff5e87169f3c90c6b570c750379dfb/src/core/mount.c#L1286
<mvo> pedronis: right if we read it again from disk, then my theory is bogus
<zyga> mborzecki: interesting, thank you
<zyga> mvo, pedronis: unless for whatever reason the kernel gives us some page cache but the loop device tries to read it from somewhere else
<zyga> I don't know how the caching is layered in the kernel
<zyga> that is, from userspace the file is ok
<mborzecki>         /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded
<zyga> but from the loop device's point of view the blocks don't use the same page cache that userspace reading the file is
<mborzecki>          * before we process the SIGCHLD for the mount command. */
<mborzecki> heh, nice comment ^^
<zyga> mborzecki: yes :)
<zyga> we also have our own code that goes and check _iff_ the mount was succcesful
<zyga> but here it would not have a chance to run
<zyga> if that systemd code is broken
<mborzecki> right
<zyga> and the mount really worked
<zyga> but systemd thinks it did not
<mborzecki> note that arch has a quite recent kernel
<zyga> we could add some code to check for that condition
<zyga> I wonder if we have enough data to see if this happens on a specific kernel more often
<zyga> or if it's just all over the place but infrequent
<zyga> I'll write down what I know so far on the forum
<mborzecki> zyga: was it seen on ubuntu and fedora?
<zyga> and let's keep watching this
<zyga> mborzecki: I don't remember
<pedronis> pstolowski: cool, let me know when I should re-review
<zyga> I think it was
<mborzecki> fedora should be running recent kernels too, so if it's related to recent(ish) kernels it should pop up there too
 * Chipaca toddles off to do physio
<Son_Goku> Fedora shipped 4.16.x to all stable releases a few weeks ago
<Son_Goku> mborzecki, btw, here's my proposed addition to the fedora spec for amazon linux 2: https://github.com/Conan-Kudo/snapd/commit/cb60c53c4c005de8f67dd3095faccde4daf2f518
<Son_Goku> I'd actually probably prefer not to support classic snaps for amazon linux 2, because then once I bring snapd into epel, the experience would be consistent across the board
<Son_Goku> and people can just install snapd from EPEL once I'm happy with the experience and we push it there
<zyga> mborzecki: https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682
<mborzecki> Son_Goku: thanks! i'll look into it, but have to figure out what's the current plan for amzn2 first
<zyga> that's what I know
<zyga> please extend that thread
<Son_Goku> mborzecki: that's why it's not proposed as a PR ;)
<Son_Goku> mborzecki, but that gives you an idea of how easy it is to extend for more distros
<zyga> Chipaca: ^
<mup> PR snapd#5223 closed: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223>
<pstolowski> pedronis: pushed
<pedronis> pstolowski: will look in a litte bit, finishing the forum topic I promised
 * zyga goes to pick up his phone
<popey_> zyga: thanks for the ping earlier
<zyga> popey: pleasure
 * zyga is picking up his phone and heads home
 * thresh just pushed a new stable vlc
<thresh> many thanks everyone involved in fixing bugs :-)
<mvo> thresh: thank you for the new vlc!
<pedronis> pstolowski: did another pass
<pstolowski> pedronis: thanks, looking
<mvo> pedronis: is the cumbersome/fragile bit in 5217 that it does not use the model assertion in SetNextBoot? or is there more to it?
<zyga> re
<zyga> phone with new battery, I can take a shower and get back to work
<pedronis> mvo: it should check if the snap is the device base (using some helper)
<mvo> pedronis: ok, this is what I read from your review. so snapstate will grow a way to get the model and pass it to the backend
<sil2100> mvo: I will be picking up making sure systemctl --failed is clean now if anything o/ I see there's one service failed there still so I'll get to it today
<mvo> sil2100: thank you
<mvo> sil2100: I will look at your UID pr after lunch
<sil2100> mvo: if you have a moment there are 3 PRs for review, but no haste with that ones
<sil2100> s/ones//
<sil2100> The travis one is ugly, but it does its job at least
<mup> PR snapd#5233 closed: client, daemon: add a "mounted-from" entry to local snaps' JSON <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5233>
<cachio_> mvo, hey
<mvo> cachio_: hey
<cachio_> mvo, about the reboot issue
<cachio_> I think it is ok the reboot
<cachio_> the test is forcing a auto refresh
<cachio_> and there is a new kernel snap in stable
<cachio_> so, the reboot happens after the kernel snap is installed
<cachio_> the same happens when the revert test is executed
<cachio_> mvo, I still don't understand why it was not happening before
<cachio_> mvo, any ideas?
<mvo> cachio_: maybe pure luck, if before the stable kernel in the image and the store was the same?
<cachio_> mvo, this is my guess too
<cachio_> I am not sure, but probably there was not any new kernel snap
<cachio_> in stable channel
 * mvo nods
<cachio_> mvo, I am testing a change to skip refreshing the kernel snap
<cachio_> mvo I'll create a PR soon
<jdstrand> zyga, mborzecki (cc mvo): I think we should add the device cgroup by default now. it *shouldn't* break snaps since we are applying it in many places, *but* I think that is too risky to jam into 2.33 right before release. the code change would be small, but I'd like a full cycle or so to make sure
<zyga> jdstrand: ack
<jdstrand> zyga, mborzecki (cc mvo): so I did it this way. I'll prepare another PR for master that does that after I do the PR for the spread test
<mborzecki> jdstrand: good idea, aiming for 2.34 then?
<jdstrand> mborzecki: yes
<mborzecki> ok
<jdstrand> I'll also comment in the PR
<jdstrand> I'll prepare the 2.33 PR for 'full' now
<pedronis> pstolowski: mvo:  would like if could do a first reading  of  https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685  , as first even before the merits, knowning whether the explanations are understable etc,  you have both written/touched code discussed there
<pstolowski> pedronis: thanks, will do!
<pedronis> thx
<niemeyer> o/
<pstolowski> pedronis: i've addressed your review comments; note, i made on check stricter than before
<pstolowski> hello niemeyer!
<niemeyer> Heya
<zyga> hey gustavo!
<mvo> pedronis: sure, reading
<mborzecki> off to pick up the kids
<cachio_> mvo, well, I know why it is happening, I changed the test code to restart the device once the core is installed
<cachio_> the core from beta
<cachio_> but in parallel there is an auto-refresh for the pc-kernel
<cachio_> so I should wait until this task is finished to reboot the device
<Jonas_> Hi, we are doing a proof-of-concept for a customer using ubuntu-core and snap. We have to mount and unmount cifs shares with our daemon. In strict mode mount works, but umount does not. What would be the best way to be able to do this? As I understood we cannot use the docker-support interface (which grants many permissions) as only the Docker project is allowed to do so.
<ogra_> $ snap refresh core --stable
<ogra_> 2018-05-30T14:23:27+02:00 INFO Waiting for restart...
<ogra_> core 16-2.32.8 from 'canonical' refreshed
<ogra_> pedronis, ^^^thats on a classic system, shoujld it really talk about "restart" there ?
<pedronis> ogra_: it's the restart of snapd itself
<ogra_> sure, still a confusing message IMHO
<ogra_> "Waiting for snapd restart..." would be a lot clearer
<pstolowski> niemeyer: can you take a look at https://github.com/snapcore/snapd/pull/5162 ? that would unblock another of my PRs
<mup> PR #5162: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
<sergiusens> good morning
<sergiusens> diddledan: hey, when you have time, a misdirected gimp support request https://bugs.launchpad.net/snapcraft/+bug/1773797
<mup> Bug #1773797: gimp snap app crashes <crashe> <gimp> <lubuntu> <Snapcraft:New> <https://launchpad.net/bugs/1773797>
<mborzecki> ogra_: can you check which package /etc/X11/Xsession.d/65snappy comes from? it's not listed here https://packages.ubuntu.com/bionic/amd64/snapd/filelist makes me wonder if this was perhaps shipped by older versions of snapd
<zyga> Jonas_: hey, can you please give me more details about the mount/umount issue
<zyga> Jonas_: the best way forward, in general, would be to open a forum thread with the basic requirements (we need to mount/umount cifs) and to indicate if this should be seen only inside your snap or also in the rest of the system
<Jonas_> I was thinking about adding an interface supporting only mount/umount cifs but if I understood correctly it is not possible to add interfaces to ubuntu-core easily. One has to fork snapd and open a pull request into the core, right?
<zyga> based on those requirement and the follow-up discussion we would probably design a new interface
<Jonas_> it should only be seen inside our snap
<Jonas_> ok I will open a forum post
<zyga> Jonas_: we could come up with the code ourselves once the requirements are known
<zyga> Jonas_: yes, to add a new interface you need to alter snapd source code
<Jonas_> ok great, I can also try to write a suggestion, as it is in go and the daemon we write is in go as well
<niemeyer> pstolowski: Will do!
<ogra_> mborzecki, added to the forum thread already
<ogra_> mborzecki, it might have been dropped when we switched to wayland in 17.04, not sure
<mborzecki> ogra_: missed that, thanks!
<niemeyer> I'll be late to the call today, or might not make it, as we have a conflicting meeting
<zyga> Chipaca, pedronis: how about you?
<niemeyer> Actually, three of us are here
<zyga> are you joining the main standup?
<zyga> ah
<zyga> ok
<niemeyer> I suggest skipping today
<zyga> ok
<niemeyer> Chipaca, cachio_ ^
<niemeyer> pstolowski: ^
<niemeyer> mborzecki: ^ :)
<Chipaca> niemeyer: we decided to have it anyway so we could talk behind your back
<niemeyer> Damn! I'm glad I wasn't there then :P
<Chipaca> yeah, doing a hangout with your back to the computer is awkward
<zyga> chipaca was even doing tricks with his camera so that I was on screen upside-down for a sec
<mup> PR snapd#5229 closed: interfaces: add juju-client-observe interface <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5229>
<mborzecki> zyga: now you know how you'd look like in australia
<mup> PR snapd#5235 opened: interfacces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5235>
<zyga> mborzecki: hehe, I just need to add snow ;)
<mup> PR snapd#5236 opened: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5236>
<zyga> eh, why is S_MAGIC_FUSEBLK just defined inside coreutils
<Jonas_> zyga: I opened this topic in the forum https://forum.snapcraft.io/t/interface-mount-umount-cifs-share-permission/5689
<zyga> Jonas_: thank you
<Jonas_> zyga: if my approach in general is legitimate I could also try to implement the interface myself and open a pull request. But maybe there is a better way to do what I want to achieve, so I will wait for feedback
<zyga> Thanks, I will review it in detail, I was surprised you could actually mount anything inside your snap,
<zyga> which kernel were you running?
<Jonas_> 4.4.0-127-generic #153-Ubuntu SMP Sat May 19 10:58:46 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<mup> PR #153: Add REST APIs for capabilities <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/153>
<zyga> hmm?
<zyga> ah, mup just being confused
<Jonas_> I thought maybe by the network-control or fuse-support interfaces I was able to mount
<zyga> Jonas_: fuse-support does allow you to mount fuse filesystems in a number of places, including $SNAP_COMMON
<zyga> (oddly it doesn't allow unmounting)
<zyga> is your filesystem a kernel one or a fuse one?
<Jonas_> it is the kernel cifs one (I think) installed via cifs-utils package (mount.cifs)
<zyga> that's interesting, it would look like a bug (or missing feature) in the 4.4 kernel that the rule allows mounting any filesystem because of mount fstype=fuse.* (perhaps fstype is not supported)
<zyga> jdstrand: ^
<zyga> Jonas_: in any case, we have enough information to investigate now
<Jonas_> zyga: Ok perfect, thx
 * zyga needs to finish some paperwork for a flight
<mborzecki> really warm now, https://i.imgur.com/XyqGRyN.jpg
<pstolowski> same here
<mup> PR snapcraft#2147 opened: recording: expose the version of snapcraft <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2147>
<mvo> pedronis: quick "taste" question - do you think boot.SetNextBoot() should grow "SetNextBoot(model)" or should we handle it on the backend level? or just move boot/ into backend?
<mvo> pedronis: context is that SetNextBoot should only be set for kernel/base as defined in the model
<pedronis> mvo: let me think a 2nd, we also have many packages
<mvo> pedronis: yeah, I'm a bit uncertain about the layering now that we need to know the model for the next boot seting
<pedronis> mvo: yea, I think boot could be merged into snapstate/backend
<mup> PR snapd#5236 closed: interfaces: add juju-client-observe for 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5236>
<pedronis> mvo: mmh
<pedronis> mvo: ah, it's separate because it' used also by image
<mup> PR snapd#5222 closed: tests: adding fedora-28 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5222>
<mup> PR snapd#5235 closed: interfaces/joystick: support modern evdev joysticks 2.33 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5235>
<pedronis> mvo: so, it's used exactly in one place, I think it could be refactored, no to do the check if the type is right on its own
<pedronis> mvo: and then indeed dealing with model would live backend
<mvo> pedronis: sounds good - and backend will get LinkSnap(info, model) (?)
<pedronis> mvo: yes, given that backend doesn't get state,  though looking more, the only piece of boot that is used outside of snapstate
<pedronis> is ExtractKernelAssets
<mvo> pedronis: yes
<pedronis> the question woild become a bit where to put that,  if we merge the rest of boot into snapstate/backend
<pedronis> a package to just hold one function i strange
<mvo> pedronis: indeed. we could also leave boot/ as is for now and just teach backend to get a model in LinkSnap
<pedronis> ?
<mvo> pedronis: I mean, we don't need to move boot.SetNextBoot() into backend just now, by passing the model from snapstate -> backend things should be ok. backend can check if its a relevant snap for booting and call boot.SetNextBoot. or am I misunderstanding something?
<pedronis> mvo: no, that's fine
<mvo> pedronis: thank you, I will work on this (will need some test tweaks I think)
<pedronis> mvo: my point wsa mostly if we start splitting responsability like this,  maybe backend should do the type checks too
<mvo> pedronis: oh, interessting
<mvo> pedronis: I like that
<pedronis> mvo: it's a bit strange how SetNextBoot work, doing nothing if it's the wrong
<pedronis> type
<mvo> pedronis: +1 lets make this an error
<pedronis> yea
<pedronis> and then backend should take care of this
<pedronis> I suppose similarly for the other helpers
<mvo> pedronis: I will make it so
<pedronis> I mean similar changes to split responsability
 * mvo nods
<sergiusens> jdstrand: did we have a bug report for adding the snapcraft version to manifest.yaml? I see I affected the wrong bug (LP: #1768820) which I will fix shortly
<mup> Bug #1768820:  manifest.yaml does not indicate the release the snap was built on <review-tools:Confirmed for jdstrand> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1768820>
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2040, snapcraft#2078, snapcraft#2105, snapcraft#2110, snapcraft#2121, snapcraft#2128, snapcraft#2135, snapcraft#2141, snapcraft#2143, snapcraft#2146, snapcraft#2147
<kyrofa> Huh... Travis seems a little off today
<kyrofa> I can't view any logs
<kyrofa> Anyone else having troubles?
<pedronis> mvo: you are off tomorrow and Fri ?
<mvo> pedronis: yes
<pedronis> pstolowski: are you off as well tomorrow?
<pstolowski> pedronis: yes
<pstolowski> pedronis: but i'll be working on Fri
<pedronis> pstolowski: mvo: IÂ owe you both re-reviews, I would do them tomorrow morning, unless you think you need them today
<sergiusens> kyrofa: no, I have been retriggering your PRs though, hit a couple of lxd and store timeouts
<sil2100> mvo: I updated https://github.com/snapcore/core18/pull/15 to only look at removals and now we have our first green travis CI run since a long long time \o/
<mup> PR core18#15: Update the dpkg list for the ABI test, switch to only tracking removals <Created by sil2100> <https://github.com/snapcore/core18/pull/15>
<sil2100> We probably need more tests in the nearest time
<mvo> sil2100: \o/
<sil2100> Sometimes travis seems to randomly fail on operations like apt install due to not being able to get the lock
<sil2100> Looks like an issue on travis
<sil2100> mvo: as for the task 'grub boot menu shows "Ubuntu Core 16" right now, must show "Core 18"' - this seems like something on the gadget side, or do you want to somehow hack the menu entry for core from the core18 snap?
<mvo> sil2100: this is pretty much done, sorry, let me show the PRs
<mvo> sil2100: https://github.com/snapcore/snapd/pull/5223 and the gadget updates linked in there should fix it. and a new model assertion
<mup> PR #5223: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5223>
<mvo> sil2100: would be nice to figure out why console-conf is not working, it seems like it cannot configure its network right now
<sil2100> mvo: ok!
<sil2100> mvo: yay, thanks o/
<sil2100> mvo: should I remove the updates I made to the package list for the removal script? As per my comment, I left them since I thought that it might be good to update it anyway, but maybe we want to have a smaller list there, with the essentials only
<sil2100> s/removal script/removal test/
<pstolowski> pedronis: i don't, it still needs 2nd review
<mvo> sil2100: my gut feeling is that we only should update this list when core18 go to stable
<mvo> sil2100: I mean, that is the promise, once its in stable we cannot remove it anymore
<mvo> sil2100: but before we have some freedom :)
<sil2100> mvo: I moved it to a cleaner PR
<sil2100> mvo: eh, ok, I just read that even though xenial is supported as a travis dist:, it seems that the dpkg lock errors are only happening there - looks like something isn't quite stable yet
<sil2100> So I'll just prep a PR to switch back to trusty for now...
<sil2100> Since on xenial we'd have to re-run the CI tests from time to time
<jdstrand> sergiusens: I thought so. let me check trello
<jdstrand> sergiusens: ok, so the *snapcraft* version, no, or at least it isn't something that I reported. the release where stage-packages came from, yes (1768820)
<jdstrand> sergiusens: thank you for picking that up. that will help us be more accurate
 * zyga fetches more water, 
<sergiusens> jdstrand: ok, I can kill the snapcraft version one if it is not useful, I had that on the back of my mind for easier mksquashfs detection
<sergiusens> I can kill it if it is not useful, it might even have been ev that requested this and I am just losing it :-P
<sergiusens> jdstrand: is ID and VERSION_ID enough?
<kyrofa> Hey niemeyer, you available to meet?
 * cachio_ afk
<jdstrand> sergiusens: from os-release? yes, that would be fine
<jdstrand> sergiusens: I wouldn't worry about the mksquashfs detection at this point wrt mainifest.yaml. not everything will have manifest.yaml so it wouldn't help everywhere; besides, we want everyone squashing the same atm. *maybe* it would be useful some day, but I'd like to understand the use case better, so, afaic, I don't need snapcraft version
<jdstrand> sergiusens: that said, it isn't a terrible thing to have in there, so if you just wanted it, I wouldn't complain
<jdstrand> I could imagine it might occassionally be helpful when debugging
<niemeyer> kyrofa: Ouch, sorry
<niemeyer> kyrofa: Missed our slot
<niemeyer> kyrofa: Just off a call with noise][, here if you are
<Chipaca> something's up with the lxd snap
<Chipaca> + lxd.lxc exec my-ubuntu dhclient eth0
<Chipaca> Cannot find device "eth0"
<kyrofa> Hey niemeyer, I'm available now, sergiusens are you around?
<sergiusens> sure
<niemeyer> Cool, let's go then
<kyrofa> Same room? Alright, hopping in
<Lin-Buo-Ren> Anyone knows why snapcraft replaces the prefix of pkg-config to $SNAPCRAFT_STAGE$originally_configured_prefix ?
<kyrofa> sergiusens, yikes, lxd issues in travis
<kyrofa> Finally got the log to load
<sergiusens> kyrofa: internet has been slow in general for me today
<sergiusens> kyrofa: google docs is also playing up
<kyrofa> can't get anything to pass anymore
<kyrofa> Time for vacation?
<kyrofa> Looks like we're using the lxd snap... any chance it just updated?
<kyrofa> I'll see if I can duplicate locally
<kyrofa> sergiusens, yep, I can duplicate locally
<kyrofa> Looks like 3.1 was released
<kyrofa> I'll chase it down
<kyrofa> Looks like we don't need to setup that iface
<mup> PR snapcraft#2148 opened: travis: stop setting up testbr0 for lxd <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148>
<sergiusens> kyrofa we can also stick to the 3.0 channel
<sergiusens> and gain the benefits of stability
 * sergiusens will brb
<kyrofa> Oh, that definitely seems like something we'd want in CI
<kyrofa> Forgot that was available
<mup> PR snapcraft#2148 closed: travis: stop setting up testbr0 for lxd <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2148>
<mup> PR snapcraft#2149 opened: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>
<kyrofa> Dang... looks like 3.0 track was updated to have the same issue :(
<sergiusens> kyrofa: so for snapcraft#2149 you set the lxd to the 3.0 track but still remove the bridge creation logic, is that desired?
<mup> PR snapcraft#2149: travis: use LXD from 3.0 track <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>
<mup> PR snapd#5237 opened: tests: fix lxd test - in current lxd we get eth1 instead of eth0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5237>
<kyrofa> sergiusens, it's required, I'm afraid
<kyrofa> 3.0 still busts the same way as 3.1
<kyrofa> But I still think it's worth using 3.0
<sergiusens> kyrofa: ok, no worries
<jdstrand> niemeyer: hi! would you mind commenting on https://forum.snapcraft.io/t/camera-raw-usb-plugs-auto-connect-for-qtchildid/2917/4? (especially since you know the roadmap for dynamic hotplug)
<niemeyer> jdstrand: Will look, thanks for the ping
<jdstrand> np
<kyrofa> sergiusens, bleech... so many concerns leakages between lifecycle and pluginhandler...
<kyrofa> They even share logging responsibilities :D
<sergiusens> kyrofa: the pluginhandler should have its cli roots stripped out
<sergiusens> but we talked about this already, right?
<kyrofa> sergiusens, I know we've talked about pluginhandler, but I don't recall a conversation about lifecycle
<sergiusens> kyrofa: we said we wanted to put all new logging in lifecycle and remove things from pluginhandler as time went by, given that anything in pluginhandler is (or should be) triggered by lifecycle
<kyrofa> Yeah that sounds right. I think I might do a little bit of that here
<sergiusens> \o/
<sergiusens> kyrofa: ok, going to stop for today and re-check on that lxd PR later in the evening/night to update and propose new PRs
<kyrofa> sergiusens, sounds good. LXD PR look good though? Can I merge if green?
<sergiusens> kyrofa: oh, let me approve
<mup> PR snapd#5238 opened: tests: skip appstream-id test for core systems 32 bits <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5238>
<kyrofa> Excellent
<mup> PR snapcraft#2141 closed: jhbuild plugin: allow running as 'root' <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2141>
<diddledan> \o/
<sergiusens> kyrofa: after merging, if I don't get to it, please update branch on the top 4 PRs on the list
<kyrofa> I'll update em all
<kyrofa> Well, the current ones anyway
<sergiusens> kyrofa: well, just those 4 please :-P
<sergiusens> yeah
<mup> PR snapcraft#2149 closed: travis: use LXD from 3.0 track <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2149>
#snappy 2018-05-31
<Chipaca> stgraber: are you around?
<mup> PR snapd#5239 opened: client,cmd/snap,daemon,tests: expose base of a snap over API, show it in snap info --verbose <Created by pedronis> <https://github.com/snapcore/snapd/pull/5239>
<Chipaca> stgraber: our "make sure we don't break lxd" integration test started failing yesterday, but it doesn't seem to be anything we changed; instead of eth0, the container now has eth1
<Chipaca> stgraber: OTOH it also happens with --channel=3.0 so I _imagine_ it's not something lxd changed :-)
<Chipaca> but i still don't know how to fix it
<pedronis> Chipaca: have you seen  https://github.com/snapcore/snapd/pull/5237
<mup> PR #5237: tests: fix lxd test - in current lxd we get eth1 instead of eth0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5237>
<pedronis> I don't know if it's correct, but it passes
<Chipaca> pedronis: what's testbr0 attached to there
<pedronis> Chipaca: the network/ vbridge IÂ suppose created some lines above
<pedronis> lxd.lxc network create testbr0
<Chipaca> pedronis: right, but it then connects that to eth0
<pedronis> Chipaca: I don't know
<pedronis> Chipaca: if I search for network attach , I see  a "default" between testbr0 and eth0 that here is not there
<pedronis> Chipaca: this seems relevant btw:  https://github.com/lxc/lxd/issues/2873
<pedronis> Chipaca: trying something
<Chipaca> pedronis: i saw that, but it's fixed, with eth0 being set by default
<Chipaca> pedronis: something seems to be overriding it
<Chipaca> pedronis: (and i tried with --channel=3.0 with the same result)
<Chipaca> anyway, i should go see about food
<pedronis> Chipaca: mmh
<mup> PR snapcraft#2147 closed: recording: expose the version of snapcraft <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2147>
<mup> PR snapcraft#2150 opened: Os release in manifest <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2150>
<jdstrand> zyga: hey, so I need to upload a test snap for the evdev tests. I think I need reminding on how to do that with the Canonical account. can you help me?
<jdstrand> zyga: I used to use the shared password, but that doesn't work any more. iiuc, there is the collaboration feature, but I don't see how to use it... maybe I am not a collaborator?
<jdstrand> zyga: maybe I shouldn't care?
<jdstrand> (about the collaboration feature)
<popey> jdstrand: thanks for the input on the xorg crasher bug. It's not easy to reproduce.
<zyga> Umm
<zyga> I think you have to just upload it
<zyga> Then you can share it with another person
<jdstrand> popey: my pauses are probably just because the keyboard and mouse are removed/added but the crashing seems like an nvidia issue, but I don't know
<zyga> Like mvo, cachio or me
<popey> jdstrand: I ran your for loop and it locked up my laptop for the period of the test.
<popey> but recovered after
<jdstrand> zyga: hmm. ok. well, there is that 'shared account' for 'Canonical-maintained snaps'
<popey> (my laptop always pauses when doing snap refreshes :( )
<popey> (which is surprising given it's an i7 with 2xSSD and 64GB RAM)
<zyga> I donât know anything about the shared account
<jdstrand> popey: yeah, that is probably the remove/add of input devices. I bet the second for loop wouldn't do that
<jdstrand> zyga: ok, I guess I'll ask mvo when he is back (is he off?)
<zyga> I donât know
<zyga> Iâm off :-)
<popey> jdstrand: will try later once I am not working :)
<pedronis> jdstrand: if you upload it then it will need to be transfered
<jdstrand> zyga: oh, sorry. you don't really act like you're off :)
<pedronis> I think now it should be possible for m-vo to register it and share it already before you upload
<zyga> hehe, the bliss/bane of phone irc
<pedronis> but m-vo is off today
<zyga> I was about to go on a bike somewhere but it's 31C in the shade and I'm somewhat not feeling like getting scorched by the sun today
<jdstrand> pedronis: it isn't a big deal. if I can do it after the fact, that's fine
<zyga> so I'm tuning my 3D printer instead
<jdstrand> popey: just do `seq 1 10`. it shouldn't crash but also shouldn't pause
<jdstrand> popey: while it won't fix your nvidia issue, it should make refreshes more pleasant
<jdstrand> popey: (if you give me confirmation of no pauses, I could submit something then)
<pedronis> Chipaca: my point was more that there are two settable values, so fwiw this also seems to make it pass again:  https://pastebin.ubuntu.com/p/yw7d6JjMkk/
<Chipaca> sigh
<Chipaca> pedronis: but _why did it stop working_?
<pedronis> for that you need stgraber
<Chipaca> pedronis: yes :-)
<pedronis> for all I know it worked by chance before
<Chipaca> bah, maybe, but probably yes
<Chipaca> yeah, likely that
<pedronis> because from what I can read the 2nd value is the relevant one here
<Chipaca> but i'd rather not +1 random changes that make it work by chance now :-D
<pedronis> Chipaca: anyway atm from my understand IÂ prefere this one over the one in the PR
<pedronis> as random changes go :)
<Chipaca> :-)
<jdstrand> popey: ok, I looked at the error reports. This is clearly a problem with Xorg, so I've added a little detail, added xorg-server and marked snapd as invalid. It is possible if I do the 'not input subsystem unless needed' patch for snapd it will reduce the frequency, but that is just a hunch
<jdstrand> popey: in other words, it is now in the desktop team's court
<popey> desktop, or foundations?
<niemeyer> Morning all
<jdstrand> popey: well, whoever handles xorg. I thought that was desktop, but maybe you know more than I
<popey> :)
<ackk> hi, I'm trying to debug a failure uploading the maas snap that's built from LP to the store. it fails with: https://pastebin.ubuntu.com/p/7MWwDTHDPP/
<ackk> when I build the snap locally those symlinks are not absolute
<jdstrand> ackk: what does 'unsquashfs -lls /path/to/your/snap | grep iab.txt' show?
<jdstrand> good morning niemeyer :)
<ackk> jdstrand, https://paste.ubuntu.com/p/GmGg3DZ78m/
<jdstrand> ackk: right it is pointing at /var/lib/ieee-data/iab.txt
<ackk> jdstrand, when the snap is built locally (either with latest snapcraft snap or the same deb as LP) they're relatiev
<ackk> jdstrand, https://paste.ubuntu.com/p/7n8bssHrKx/
<ackk> jdstrand, LP guys were suggesting a workaround might be adding python3-netaddr to build-packages (it currently is in stage-packages as we depend on it)
<niemeyer> jdstrand: Hey, morning!
<ackk> jdstrand, could it be related to that?
<jdstrand> ackk: you are using 'll', but you didn't show me the unsquashfs -lls output of both (your local and the one failing review)
<jdstrand> ackk: so, snapcraft tries to be smart about symlinks. if you are doing 'snapcraft' rather than 'snapcraft cleanbuild' and happen to have something in your local env that changes the result, yes, that could be the case (you'd need a snapcraft person to comment on that)
<ackk> jdstrand, the first one is from a mounted snap (with mount -t squashfs)
<ackk> jdstrand, the latter is from a prime/ dir of a locally built snap
<ackk> jdstrand, ah, I see, so this happens because LP doesn't install the package system-wide
<ackk> jdstrand, does LP use cleanbuild?
<jdstrand> ackk: it will use something equivalent iirc
<jdstrand> ie, a small chroot
<ackk> jdstrand, so how would a snap using a package like python3-netaddr that has external symlink would fix the issue?
<ackk> $ ll /usr/lib/python3/dist-packages/netaddr/eui/iab.txt
<ackk> lrwxrwxrwx 1 root root 26 Oct 23  2017 /usr/lib/python3/dist-packages/netaddr/eui/iab.txt -> /var/lib/ieee-data/iab.txt
<ackk> jdstrand, ^^ FTR
<jdstrand> I'm also not sure at what stage snapcraft tries to be smart. looking at the mounted snap is equivalent to -lls. I'm not 100% sure looking in prime is (but I think it might be)
<ackk> jdstrand, it's  the same in the locally built .snap
<jdstrand> ackk: iirc (again, I am not a snapcraft dev), if the file is not staged, it can't be smart so just keeps it. if it finds the file in your staged area, it fixes up the symlink
<ackk> jdstrand, maybe adding ieee-data (the package that contains the /var/lib/ieee-data files would fix the issue?
<jdstrand> possibly
<jdstrand> ackk: do you actually need those files? the other route if you don't is to use 'organize' and remove the symlinks
<ackk> jdstrand, although python3-netaddr has it as dependency
<ackk> jdstrand, I suspect we might (the lib probably does)
<ackk> jdstrand, this seems a more general problem though? what about packages that symlink to extenral files?
<jdstrand> ackk: packages aren't allowed to symlink outside the snap. there is no guarantee the file will be present. take your snap. if it actually needed that file, it would be broken on any system that didn't have ieee-data installed
<jdstrand> ackk: the answer is that your snap needs to supply the file and be adjusted to point to the right place. perhaps there is a bug in snapcraft (you might file it). I suspect you have ieee-data installed but LP does not
<ackk> jdstrand, I certainly have locally, as I build with "snacraft build"
<jdstrand> ackk: I strongly suggest using 'snapcraft cleanbuild' as a final step to most closely replicate LP
<ackk> jdstrand, sure, but that means the snap I build will be rejected as well :)
<jdstrand> ackk: that gives you the opportunity to debug locally though
<ackk> jdstrand, sure. yeah I'll try the route of removing those symlinks and linking to the right place in the snap
<jdstrand> ackk: perhaps try to stage ieee-data and see if that helps. if it doesn't, file a bug
<jdstrand> maybe it isn't pulling it in for some reason. maybe it isn't finding it. if there is a bug, yeah, remove and re-add them in the meantime
<ackk> jdstrand, ieee-data is a dependency of python3-netaddr so it must be pulled in as we have the latter in stage-packages
<jdstrand> ackk: unless there is a bug in dependencyy resolution in snapcraft. you can probably look in the LP build log and see if it was downloaded
<ackk> jdstrand, yes, is does get installed
<jdstrand> cachio_: hey, I'm developing aspread test that uses snapcraft.yaml. I see things in tests/lib/snaps that do the same (fine), but then I see bzr branches in LP that replicate what is in snapd's git to get LP builds of the snaps for all archs. is that the correct way to do things these days?
<cachio_> jdstrand, hey
<jdstrand> test-snapd-uhid is what I'm looking at for inspiration since it was closest to the type of thing I am testing
<cachio_> jdstrand, we have those branches to build the snapd and upload automatically to all the architectures
<jdstrand> cachio_: ok, right. that is what it looked like. just wanted to make sure I was doing it the modern way
<cachio_> jdstrand, which is the other way?
<cachio_> niemeyer, not connecting to hangouts
<jdstrand> cachio_: I've seen tests that just used snaps in the store, tests that build snaps in spread, etc
<jdstrand> just trying to do it the right way
<cachio_> jdstrand, so we try to create the snaps that snapd test suite uses
<jdstrand> yeah, that is why I asked about this :)
<cachio_> jdstrand, and we leave the code as part of the snapd code to have the code and see what the snap does
<cachio_> but sadly it requires to have the core replicated to make automatic builds for those snapd
<cachio_> jdstrand, just ping me once you have the code and I'll take a look
<jdstrand> cachio_: that's fine. I think I understand how it works; I just wanted to double check. you confirmed my understanding
<jdstrand> cachio_: all ask you to be a reviewer when I send up the PR
<jdstrand> I'll*
<ackk> jdstrand, can you specify the series to use to cleanbuild? it seems it's picking up xenial by default
<stgraber> Chipaca: actually, I think it's because of something we fixed
<stgraber> Chipaca: "lxd init --auto" was incorrectly not setting up a network interface, that's now been fixed in both branches
<Chipaca> stgraber: aha
<stgraber> Chipaca: so if your test code calls "lxd init --auto", then you do end up with an eth0 device defined in your default profile, making it so that any change you do will end up as eth1
<Chipaca> stgraber: so in https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml
<Chipaca> stgraber: line ~60 is where we fiddle with the network
<stgraber> Chipaca: 63 and 64 shouldn't be needed anymore since you call --auto
<Chipaca> stgraber: excellent
<stgraber> Chipaca: the --auto logic will create a lxdbrX device (starting with lxdbr0 and going up until it finds a free one)
<pedronis> Chipaca: trying that change (removing the lines) locally
<Chipaca> pedronis: ditto :-)
<stgraber> and yeah, we released a ton of bugfixes to our stable channels yesterday, this was one of them
<Chipaca> stgraber: good to know, happy that it'll mean less code on our side, and glad I asked
<Chipaca> pedronis: we can drop that whole chunk \o/
<Chipaca> pedronis: should I, or will you?
<pedronis> Chipaca: whole chunk?  two lines?
<Chipaca> pedronis: and the dhclient call and the comment
<pedronis> Chipaca: ah, we don't need to setup network at all
<pedronis> it is already setup?
<Chipaca> looks like it yes
<pedronis> Chipaca: please go ahead
<Chipaca> ok
<mup> PR snapd#5240 opened: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>
<jdstrand> cachio: hey, there you go ^. I only tested locally with qemu 18.04-64 so may have to tweak the tests a bit after a full run (I'll of course do that)
<cachio> jdstrand, perfect, I'll take a look after lunch
<pedronis> Chipaca: thanks
<Chipaca> pedronis: fedora acting up now, but hopefully just network
<mup> PR snapd#5241 opened: interfaces/udev: call 'udevadm settle --timeout=3' after triggering events <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5241>
<Chipaca> and now travis lost a chunk of the log, dunno what's going on
<niemeyer> Power outage.. home router down.. I will stop fighting the holiday gods now and step out
<Chipaca> cachio: fedora's failing to prepare for 3 times in a row now
<cachio> Chipaca, ok
<cachio> Chipaca, I'll check it
<Chipaca> cachio: https://travis-ci.org/snapcore/snapd/builds/386227367 fwiw
<cachio> tx
<Chipaca> cachio: run's finished now, if you need the logs
<cachio> checking
<Chipaca> soft EOD from me
<Chipaca> i'll check back to see if i can't coax it to pass
<mup> PR snapcraft#2150 closed: Os release in manifest <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2150>
<jdstrand> cachio: hey, note that PR 5240 isn't about testing that an interface allows access. it is testing that access is always denied which can only be done with strict mode. this is why I bail early
<mup> PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>
<jdstrand> cachio: I mean, I can put the connection of the joystick interface before strict, but I can't fake an evdev joystick in the test environment and the test isn't really about the joystick interface being connected and functioning. it is about a keyboard not being accessible if the joystick interface is connected
<cachio> jdstrand, ok, makes sense
<jdstrand> I initially tried to follow the pattern but then reworked it to what it is since it didn't really work. I am making the other adjustments now. thanks for the review!
<cachio> jdstrand, it is ok
<cachio> I get your point
<jdstrand> k, I'll comment in the PR and send up the changes
<cachio> jdstrand, is it possible to create fake devices and see if the test can read them?
<cachio> jdstrand, I mean, to validate this kind of rules
<cachio> --> /dev/input/js{[0-9],[12][0-9],3[01]} rw,
<jdstrand> cachio: not in a way that would make udev recognize them
<jdstrand> so the tagging wouldn't work
<jdstrand> well, I'm not aware of a way to do that beyond hotplugging virtualized hardware
<cachio> jdstrand, we often use a snap which makes sh
<cachio> so we create a fake file simulating a device
<cachio> and then chenck the snap is able to read it
<cachio> not sure if it is needed in this case
<cachio> we do it at least to validate the app armor rules are applied correctly
<jdstrand> for what this test is trying to test, it isn't-- we want to make sure the evdev keyboard is *not* available. that is already in the vm
<cachio> jdstrand, ok
<jdstrand> if I were going to write a test-snapd-joystick test, it would be. the problem in this case is that udev is adding a property to evdev devices if it detects they are joysticks
<cachio> jdstrand, I can do it
<cachio> jdstrand, I already created bunch of interfaces tests
<jdstrand> I could create something in /dev/input/eventN, but adding the myriad of udev properties I don't know how to do
<cachio> jdstrand, sure, let me research a bit on this
<cachio> I'll create a test for this interface
<jdstrand> ok, cool. if you want me to review, holler
<cachio> jdstrand, sure
<cachio> I already deleted the comment on the review
<jdstrand> I see, thanks
<cachio> np
<mup> PR snapd#5237 closed: tests: fix lxd test - --auto now sets up networking <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5237>
<cachio> jdstrand, could you please merge with master the #5240
<mup> PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>
<cachio> it has the lxd test fixed
<jdstrand> cachio: ok. fyi, I figured out a way to do the access test without evtest (ie, just bash) and am doing that in a separate PR. I think using evtest is kinda cool and might be useful for others later. thoughts on keeping it or using the new bash-only approach?
<cachio> jdstrand, great
<cachio> jdstrand, ping me, I'll review it
<cachio> thanks
<mup> PR snapcraft#2151 opened: Debian <Created by transdigiware> <https://github.com/snapcore/snapcraft/pull/2151>
<jdstrand> cachio: by 'separate PR' I mean, I am writing a new spread test for something else
<jdstrand> cachio: so curious if you'd prefer I change 5240 to use bash only, or leave it as is since it might be a handy example for others later
<cachio> jdstrand, something like interfaces-joystick
<cachio> ?
<jdstrand> no
<jdstrand> I'm doing a PR that should help refreshes be less painful wrt udev trigger and I wanted to test something with the mir slot and plug
<cachio> ah, ok
<jdstrand> popey: you might be interested in that ^
<jdstrand> cachio: and I'm conincidentally playing with /dev/input/event* again
<cachio> jdstrand, in a moment I'll create a snap pr to test the interface, mostly focused on apparmor rultes
<jdstrand> cachio: cool. do you have an opinion on 5240 moving to bash-only or keeping evtest?
<cachio> jdstrand, we try to move to bash when it is possible
<jdstrand> ok, then I'll update the pr for that
<cachio> jdstrand, because it is easier to understand reading the test
<jdstrand> it'll be a few minutes since I'm in the middle of that other pr
<cachio> jdstrand, sure, np
<jdstrand> roadmr: hi! got another review tools request. can you pull r1082?
<jdstrand> roadmr: also can you revoke test-snapd-event? I added it today and figured out how to do it without a published snap
<roadmr> hi jdstrand
<roadmr> jdstrand: yes to both
<jdstrand> roadmr: thanks!
<roadmr> jdstrand: are you sure you want a revocation? that blacklists the snap name for all eternity, nobody will ever ever be able to use it
<jdstrand> roadmr: well, really I want to pretend I didn't add the snap. if that isn't possible, I'd like to unpublish the revisions from any channels
<jdstrand> roadmr: I guess that would allow us to transfer the name to someone
<roadmr> jdstrand: you can unpublish them by snapcraft close test-snapd-event stable edge beta candidate
<roadmr> jdstrand: if you hold on to the name even with no snaps published, it can be transferred
<jdstrand> oh, I didn't know about close
 * jdstrand does that
<roadmr> jdstrand: if it's revoked, it can NOT be transferred, it becomes scorched earth and can never be used again by anyone
<jdstrand> that's fine then
<roadmr> jdstrand: yes, that's why the trashcan icon was removed, remember that? that's "revoke forever never to be seen again by anyone", and not "just delete all the uploads unpublish everything and start from scratch"
<roadmr> so since people wanted the 2nd and ended up in the middle of a desert, we decided to remove it :)
<jdstrand> oh yes, I do remember that
<jdstrand> ok, I closed it. just the pull then. thanks!
<roadmr> jdstrand: np, I prepared it but it'll likely not be deployed until Monday :/
<jdstrand> that's fine. this one isn't at all urgent
<roadmr> awesome :)
<mup> Bug #1774509 opened: system-user assertion should allow change-pw to be set <Snappy:New> <https://launchpad.net/bugs/1774509>
<jdstrand> cachio: ok, 5240 updated. the tests are running
<cachio> jdstrand, good
<cachio> I'll take a look
<mup> PR snapcraft#2152 opened: many: automatically redo step for specified part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2152>
#snappy 2018-06-01
<mup> PR snapd#5242 opened: tests: new test for joystick interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5242>
<jamesh> zyga: if you wanted to test out the portals code you've been reviewing for me over the last several months, I put together some test instructions here: https://forum.snapcraft.io/t/desktop-portal-testing-notes-for-app-developers/5711
<zyga> brilliant, thank you
<zyga> is mvo around today?
<pedronis> no, still off afaiu
<zyga> ah, ok
<pedronis> mmh, the help for snap info --verbose is not correct since a while IÂ suspect
<Chipaca> pedronis: how so?
<Chipaca> pedronis: incomplete perhaps
<pedronis> Chipaca: well, incomplete means a bit not correct
<Chipaca> pedronis: yes, incomplete is a flavour of incorrect
<zyga> hm
<mborzecki> travis jobs hitting timeouts again?
<pedronis> Chipaca: I'm landing my branch and then will do a follow up to fix that (and couple other silly things related to help)
<mup> PR snapd#5239 closed: client,cmd/snap,daemon,tests: expose base of a snap over API, show it in snap info --verbose <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5239>
<thresh> to whoever thought it's a good idea to have backups of snaps in /var/lib/snapd/snaps, thank you
<thresh> helps debugging a lot!
<zyga> thresh: they are not really backups
<zyga> they _are_ the snaps
<zyga> but as for backups, Chipaca here is working on first part of backups (snapshots)
<thresh> well yeah, but not removing the old ones
<zyga> ah, I see what you mean now
<thresh> I'm actually interested in a kinda timeline
<thresh> e.g. "at that date we had snap rev 100 in stable"
<thresh> it's partially doable looking at the metrics, though
<mup> PR snapd#5244 opened: tests: shellchecks part 3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5244>
<mup> PR snapd#5245 opened: cmd/snap-update-ns: add PathIterator <Created by zyga> <https://github.com/snapcore/snapd/pull/5245>
<zyga> mborzecki, Chipaca: ^ perhaps interesting :)
<zyga> mborzecki: review on shellcheck ready
<cachio> pedronis, you have a vm in google, are you using it?
<cachio> niemeyer, you too
<pedronis> cachio: no, some left over from a killed run or something
<cachio> pedronis, ok
<cachio> pedronis, deleted, thanks
<mborzecki> maybe we should consider switching fedora 28 to manual, at least for a week or so, their repos seem to be under some load right now
<zyga> mborzecki: +1
<mup> PR snapd#5246 opened: spread: switch fedora 28 to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5246>
<mborzecki> zyga: ^^
<cachio> mborzecki, yes
<cachio> it is giving timeout
<cachio> I'll make the change
<mborzecki> cachio: it's there already ^^
<cachio> mborzecki, awesome
<cachio> this is fast
<cachio> mborzecki, you should enable fedora-27
<mborzecki> cachio: but this would be the same infrastructure
<cachio> mborzecki, well, it was not giving any timeout when we were using f27
<cachio> we started with the timeout errors when we moved to f28
<cachio> right?
<mborzecki> cachio: pushed a commit enabling fedora 27
<cachio> mborzecki, tx
 * cachio afk
<mup> PR snapd#5247 opened: cmd/snap: small help tweaks and fixes <Created by pedronis> <https://github.com/snapcore/snapd/pull/5247>
<pedronis> Chipaca: ^
<Chipaca> pedronis: :-D awesome
<jdstrand> zyga: hey, before you spend a lot of time on it, I suggest you read https://github.com/snapcore/snapd/pull/5241#issuecomment-393859855
<mup> PR #5241: interfaces/udev: call 'udevadm settle --timeout=10' after triggering events <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5241>
<zyga> thanks, reading
<zyga> mmm,
<zyga> I'd love to see the work towards us being able to "commit" certain things only once in a larger  interface transaction
<zyga> I think it's simple on our end but terribly complex in snapd in general because of hooks and some, perhaps, implicit assumptions on when the state has settled
<jdstrand> zyga: yeah
<jdstrand> zyga: it would definitely help with apparmor loads and speed up refreshes a lot
<zyga> yes
<jdstrand> zyga: core refreshes where interfaces change, etc
<jdstrand> zyga: it would not be terribly helpful for udev with my upcoming PR
<zyga> it might be able to inspect the rules and see if we need to trigger all or just some subsystems
<jdstrand> zyga: that PR is pretty cool though-- I have a bunch of snaps installed and I udev monitor input events. I refresh and do things to cause snapd to call trigger and no input events are triggered, and no annoying pauses. then I install a snap that slots mir and the input subsystem is only triggered the one time. classic users aren't going to have mir, wayland or x11 slots snaps installed, and what I do for joystick doesn't cause a pause
<jdstrand> neat!
<jdstrand> zyga: ehh, we could do that but I think we would want to have the interfaces declare it. again, I don't think we should worry about '3' (only calling affected subsystems) until we see a need
<jdstrand> and I don't think we'll see it. if we do, it won't be hard to expand on my '2' techniques
<mborzecki> jdstrand: to add to udev triggered bugs, libinput and gsd seem to not play well with each other, and input settings are sometimes lost, and another one is pulse getting killed and no sound due to sound device changes
<jdstrand> zyga: note, I also answered your questions in PR 5240
<mup> PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>
<niemeyer> cachio: Thanks for the note.. I was using it, but probably won't come back to the problem in the next few hours.. so discarded it and will fire another one when I actually do
<jdstrand> mborzecki: libinput/gsd would be worked around be my existing PR
<jdstrand> mborzecki: I can submit that and then perhaps we could do a followup PR for sound
<jdstrand> me hasn't seen that bug
<mborzecki> i was able to trigger this by installing ohmygiraffe in a loop ;)
<jdstrand> I find pulseaudio terribly annoying in general. it forgets stuff all the time when snapd didn't do anything
<jdstrand> s/existing PR/upcoming PR/
<mborzecki> jdstrand: you can call spread shellcheck locally by issing `./spread-shellcheck <path-to-task.yaml>`
<jdstrand> ah, handy
 * jdstrand takes a note
<mborzecki> pedronis: what do you think about https://github.com/snapcore/snapd/pull/5243#discussion_r192378309 ?
<mup> PR #5243: spread-shellcheck: silly fix & pep8 <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5243>
<zyga> mborzecki: can you split that so that pep8/shellcheck is in one PR and the ongoing discussion can evolve separately
<jdstrand> zyga: another interesting idea for running apparmor or udev trigger only once is if we get to that point, we could run trigger first, then apparmor. this would avoid the race where apparmor opens up because it is relying on the device cgroup
<mborzecki> zyga: i hope to have this resolved soon and avoid opening another pr
<zyga> jdstrand: yeah, that could be easily done by arranging the backends in a specific order (or even making the two calls explicit so that backend order doesn't matter)
<jdstrand> zyga: really, I want either profile composition in apparmor or inode labelling, then we can drop the device cgroup and have a udev helper that calls out to apparmor in a performant manner (ie, not a full profile reload)
<zyga> what is profile composition?
<zyga> and inode labelling?
<zyga> note that udev backend is still very useful outside of ubuntu
<pedronis> mborzecki: answered
<jdstrand> zyga: profile composition is that idea that you parse your profile in different parts and stitch them togther. think of it as we have the entire profile that remains unchanged, we plugin a joystick and need to add a single rule. we compile that single rule, leaving all the rest of the policy alone and stitch it into a new profile to load
<mborzecki> pedronis: thanks, pushing in a minute
<zyga> ohh
<zyga> jdstrand: that makes sense, is that on the roadmap?
<jdstrand> zyga: the single rule parse is fast and the stitch is fast
<jdstrand> zyga: yes
<zyga> jdstrand: I hope we can mainline all of the current stuff first though, it's still a drag that we cannot use apparmor in debian and opensuse fully
<jdstrand> zyga: inode labelling is where you have a rule that is like: 'file label=foo rw,' then you have a udev helper that adds 'foo' to the inode of the device. no profile recompiles
<jdstrand> (that rule syntax is made up, but illustrates the point)
<zyga> jdstrand: that looks like selinux
<jdstrand> zyga: it does in that we are storing labeling information in the inode, yes. note that in kernel, this is all happening already with dynamic labeling
<jdstrand> ie, all files have security labels in the kernel (that's a bit of a simplification of course)
<zyga> my mind was blown a while ago when I read a bit more apparmor kernel code, the "label" is really a complex object, not just a string that I somehow implicitly expected
<jdstrand> zyga: dynamic labelling is usually way more flexible (it is how we can do what we do) but there are times when inode labeling is really handy
<jdstrand> zyga: yes
<jdstrand> this is also planned. both composition and labelling have had (upstream) work done on them
<jdstrand> zyga: you asked about upstream: this is all happening upstream and things are getting closer with each new upstream kernel
<jdstrand> popey: I don't know if you saw my comment from 25 minutes ago: 07:11 < jdstrand> zyga: that PR is pretty cool though-- I have a bunch of snaps...
<jdstrand> popey: I think you are going to like that :)
<popey> Tease
<popey> I didn't see it, no.
<popey> Yay
<jdstrand> popey: I have a hunch it will even avoid the xorg bug (since the error report indicated issues in the input event handling)
 * zyga -> hungry
<popey> Good. I have just had another one :|
<jdstrand> boo
<jdstrand> popey: do you have anything in the logs at the time of the crash?
<popey> which logs in particular?
<popey> I have an xorg crash file as always
<jdstrand> Xorg or syslog/journalctl
<Chipaca> pedronis: wrt snapshot conflicts, should i change it to check task kinds instead of changes'?
<mborzecki> cachio: fedora 27 looks bad too :/ i'll drop that last commit
<pedronis> Chipaca: that is more typical, but honestly I want to get away from checking kinds (task or change)
<Chipaca> pedronis: what would you rather do?
<pedronis> Chipaca: just have a thing that consider if there's an op on the snap and have at most one op
<pedronis> Chipaca: but it seems you want snapshot level granularity,  is there a deep reasons, or is just nice?
<Chipaca> pedronis: things get weird if you operate on a snapshot in conflicting ways
<Chipaca> although if it were snap-level it would still catch them
<pedronis> Chipaca: because snapshot and snaps are distinct concepts ?
<pedronis> IÂ mean snapshot has no corresponding snap? or does it?
<popey> jdstrand: http://paste.ubuntu.com/p/jYCVpr8Z3d/ around line 3687. System went pop at 13:18 or so
<Chipaca> pedronis: a 'snapshot-check' running at the same time as a 'forget' for example
<pedronis> I understand
<pedronis> I'm asking do this thing have always an associated  snap or not?
<pedronis> I haven't followed all the details
<Chipaca> pedronis: but if a snapshot operation on a set of snapshots of snaps that include X is an operation on snap X, and thus conflicts with other snapshot operations that include snapshots of snap X, it'll probably work out
<Chipaca> pedronis: a snapshot is of a snap
<pedronis> ok, that's what IÂ would like to go
<pedronis> trying to understand if snapshots are special
<Chipaca> pedronis: and some snapshot tasks that operate on a snap even add a snap-setup to help the snapstate side of conflicts
<Chipaca> pedronis: (bah, just save and restore, check and forget don't but could easily)
<pedronis> I mean we can have both snaps and snapshotes as high-level conflict sources
<pedronis> what I think is getting fragile
<pedronis> is looking at kinds
<Chipaca> pedronis: can we refactor the whole thing after snapshots are landed?
<pedronis> Chipaca: yes  but the change kind thing is not here nor there
<pedronis> doesn't mean is wrong but is yet another way to do things
<pedronis> Chipaca: it's also going to be problematic when we start taking snapshots as part of other snap ops
<Chipaca> pedronis: yeah
<pedronis> (that's why in general we don't look at change kinds,  they tend to be bag of things, except a few in devicestate)
<Chipaca> pedronis: so i should at least change it to check task kind, not change kind
<pedronis> yes
<Chipaca> fair
<jdstrand> popey: I'm seeing a lot of input devices being added and removed related to your nvidia hdmi/dp (and others). this makes me hopeful that the upcoming pr may help more than just the annoying input pauses during refresh
<popey> Awesome
<jdstrand> popey: how often do you see this?
<popey> Wait. Input devices on display port?
<popey> The crash or hangups?
 * zyga just noticed that irc cloud does some magic to show popey's face next to the nickname
<jdstrand> popey: all kinds of things show up as evdev devices (/dev/input/event*)
<popey> Ya. You can set it in your profile in the client zyga
<popey> jdstrand: ok. How fun
<jdstrand> popey: the crash. I know when the hangups will happen (and I can reproduce those, and have eliminated them in my poc)
<popey> Ok
<jdstrand> popey: I ask about the frequency of the crash cause I can give you a deb that can maybe alleviate some pain
<popey> Depends how often I install snaps :)
<popey> Happens at least once a week, twice this week
<jdstrand> ok, let me be more direct
<jdstrand> do you want a deb with my poc?
<popey> I only worked 2 days this week though
<popey> Sure
<jdstrand> ok
<popey> Thanks
<jdstrand> hey, I can wormhole you this time!
<niemeyer> cachio: Trouble connecting?
<jdstrand> popey: wormhole is neat. note, this is snapd 'master' as of last night. if you want something based on release/2.33, I can build you another deb
<cachio> niemeyer, trying
<jdstrand> popey: you probably want to 'snap refresh core --stable' so that you continue using the deb
<popey> Ok
<jdstrand> popey: I plan on sending up the PR today, so hopefully next week it'll be in edge, if not 2.33 (we'll see)
<popey> Awesome news. Much appreciated
<jdstrand> popey: please give negative or positive feedback-- I think you'll be pleased with refreshes and installs
<popey> Ok. Will beat it up a bit in a dark alley
<mup> PR snapd#5246 closed: spread: switch fedora 28 to manual <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5246>
<zyga> Power outage
<niemeyer> jdstrand: QUick ping on https://forum.snapcraft.io/t/classic-confinement-request-communitheme-set-default/5146/17
<pedronis> mborzecki: thx about the heads up about merging master into my PR
<jdstrand> niemeyer: a design for update alternatives is not going to be a quick call. I won't have time to prepare for said call by this afternoon. we could try for say, tuesday
<niemeyer> jdstrand: That works as well, thanks!
<zyga> Break for lunch
<mup> PR snapd#4767 closed: interfaces: disconnect hooks <Critical> <Squash-merge> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<jdstrand> cachio: fyi, PR 5240 should be ready for another review
<mup> PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5240>
<cachio> jdstrand, sure, I'll do, tx
<mup> PR snapd#5243 closed: spread-shellcheck: silly fix & pep8 <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5243>
<pedronis> pstolowski: #5162 is red, haven't looked, might need a master merge
<mup> PR #5162: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
<pstolowski> pedronis: The job exceeded the maximum time limit for jobs, and has been terminated - after starting fedora
<pedronis> pstolowski: yea, need master (where I think fedora has been put to manual temporarely)
<Chipaca> zyga: i just noticed opengl stopped working here
<Chipaca> _just_ missed maciej
<Chipaca> :-)
<pstolowski> pedronis: ah, ok, doing
<cachio> jdstrand, ready
<mup> PR snapd#5240 closed: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5240>
<jdstrand> cachio: thanks! :)
<zyga> Still lunching
<pedronis> mmh, didn't seem to help, still timeout
<King_InuYasha> :/
<pstolowski> yeah something is not quite tight
<pstolowski> *right
<popey> jdstrand: your snap breaks my package manager, because  ubuntu-core-launcher : Depends: snapd (= 2.32.8+18.04) but 2.33~rc1 is installed
<popey> I'll live...
<jdstrand> popey: remove ubuntu-core-launcher
<popey> not needed?
<jdstrand> popey: it is a transitional package and doesn't ship anything
<mup> PR snapd#5248 opened: tests: add test to ensure /dev/input/event* for non-joysticks is denied - 2.33 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5248>
<pedronis> pstolowski: yes,  all fedora is manual but things are still timing out
<zyga> 49 minutes :/
<pedronis> it's a bit hard to tell when it started
<pedronis> lots of red runs also yesterday for master
<cachio> niemeyer, the key name is kill_timeout_hs
<cachio> is it ok?
<cachio> do you prefer just timeout?
<cachio> default to 2
<pedronis> not super clear what is slow, but for example snapd-snap tests say "running late"
<cachio> zyga, we got a timeout now building 16.04
<cachio> it iw weird
<cachio> https://api.travis-ci.org/v3/job/386694389/log.txt
<pedronis> everything setupish seems to be running late
<cachio> pedronis, perhaps another dependency is working slow
<cachio> 8 build reds in a row
<cachio> 26 <kill-timeout reached> on https://api.travis-ci.org/v3/job/386691952/log.txt
<zyga> I will retry jobs at night
<Chipaca> brb, need to reboot
<niemeyer> cachio: This is "kill-timeout: 2h" in spread already.. we can just use the same syntax for both key and values
<cachio> niemeyer, sure, kill-timeout will be
<cachio> I already was testing the snap
<cachio> it works properly
<cachio> I'll make this change
<pstolowski> zyga: are you going to kick all failed jobs at night? i'd be interested in landing #5162 (in any case i'll take a look at it tomorrow and retry it if necessary)
<mup> PR #5162: overlord/hookstate: support undo for hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
<niemeyer> cachio: Oops, minor tweak: this is actually halt-timeout
<cachio> niemeyer, ok, np
<cachio> I'll update it
<niemeyer> cachio: kill-timeout is the time for individual tasks to be killed
<niemeyer> cachio: warn-timeout for warns, and halt-timeout for system halting
<cachio> niemeyer, we are gonna need an specific service account for this
<cachio> or you prefer to use yours?
<zyga> pstolowski|afk: yes, I will restart everything
<pstolowski|afk> zyga: k, thx
<cachio> niemeyer, I need to leave now, I'll update the gce-cleaner snap an leave an instance running in gce when I am back
<cachio> niemeyer, I'll monitor this one for a time to see if it works properly and then you can take it
<niemeyer> cachio: Nice, thanks!
 * cachio afk
<mup> PR snapd#5249 opened: interfaces/home: remove redundant common interface assignment <Simple> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5249>
<mup> PR snapd#5250 opened:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
<jdstrand> popey: that one's for you buddy ^
<jdstrand> it may need some iterating
<niemeyer> jdstrand: Replied on https://forum.snapcraft.io/t/auto-connection-of-gtk3-themes-icon-themes-and-sound-themes-interfaces/5118/17
<jdstrand> niemeyer: thanks, that sounds reasonable. when they respond, I'll issue it
<niemeyer> jdstrand: Thanks!
#snappy 2018-06-02
<rootinshell> quick question please, i've installed an app using snappy on my ubuntu LTS 16.04, now i'm tying to edit some files,
<rootinshell> the prompt shows Read-only file system, how can we edit files on a container ?
<newbee> Hi Guys,  I have the java application to list the serial ports in the system. itâs work fine in Ubuntu 16.04 System. Then I created the snap of the same project as per the snapcraft instruction, after install the snap in my Ubuntu 16.4 LTS system , its not list the serial ports. throwing the below error.  âcheck_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to crea
<newbee> Note : We are using RxTxcomm.jar and librxtxSerial.so file
<newbee> I have the java application to list the serial ports in the system. itâs work fine in Ubuntu 16.04 System. Then I created the snap of the same project as per the snapcraft instruction, after install the snap in my Ubuntu 16.4 LTS system , its not list the serial ports. throwing the below error.  âcheck_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi
<aladdin> I have a snap which has been plugged to raw-usb, joystick and hardware-observe but still I can't get the gamepad to be recognized
<aladdin> it should give access to  /dev/input/jsX and /dev/input/eventX
<aladdin> which the software is using
<aladdin> but still no control
<aladdin> hardware-observe plug is needed to avoid access denied to /run/udev/data
<aladdin> running in --dev-mode works
<mup> PR snapd#5247 closed: cmd/snap: small help tweaks and fixes <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5247>
<tgeek> quick question: how do I remove a snap when this happens? -- Remove data for snap "lxd" (7319) (remove /var/snap/lxd/common/lxd/storage-pools/default/containers: operation not permitted)
<tgeek> command used: sudo snap remove lxd
#snappy 2018-06-03
<mup> PR snapd#5251 opened: tests: reprioritise a few tests that are known to be slow <Created by chipaca> <https://github.com/snapcore/snapd/pull/5251>
<skomorokh> Heya, how do I add exceptions to the sandbox?
<skomorokh> Specifically, we share a computer and a stereo so pulse is running in daemon mode.
<skomorokh> And we want to use the spotify snap so we don't have to trust its .debs with root.
<skomorokh> But the confinement isn't taking daemon mode into account: apparmor="DENIED" operation="connect" profile="snap.spotify.spotify" name="/run/pulse/native"
<skomorokh> ...so I think I want to make a local-only patch to the pulseaudio interface? Is it even possible to do that? In a way that survives snap updates?
#snappy 2019-05-27
<mborzecki> morning
<zyga> Hi
<zyga> mborzecki: voting is over
<mborzecki> zyga: yeah, it is
<zyga> Could be better, could be worse
<mborzecki> zyga: though, we have domestic round in october right? :)
<zyga> Too bad 70% of young people did not vote
<mborzecki> zyga: tbh, wasn't much to choose from
<zyga> Yes, that will be critical
<mborzecki> zyga: same faces each time
<zyga> Eh
<zyga> Yes, that is true
<zyga> One more kid to send to school, ttyl
<mborzecki> zyga: at least konfederacja is outside, don't think they need more lunatics in brussels
<zyga> Iâm happy to see wiosna, it means we are not all crazy yet
<zyga> back in the office now
<zyga> ok, time to set everything else aside
<zyga> and look at initramfs
<zyga> mborzecki: ping me for reviews
<zyga> mborzecki: if you ever want a puzzle to solve https://github.com/snapcore/snapd/pull/6891 is critical for .1
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> and has exactly one apparmor denial in one test on one system!!!
<zyga> and I'm out of ideas why
<mborzecki> zyga: on 14.04?
<zyga> correct
<zyga> on 14.04 only
<zyga> 4.4 kernel
<mvo> hey mborzecki and zyga - good morning!
<zyga> and, to my looks, the denial is bogus because we have that rule
<zyga> mvo: good morning!
<zyga> mborzecki: I didn't look, at the time, about environmental differences, like /tmp tmpfs vs ext4
<zyga> mborzecki: I know that a bare "mount," rule fixes it
<zyga> and the denial was on flags
<zyga> perhaps there's a bug on 14.04 parser
<zyga> the bad thing is that apparmor blob format is opaque, I wrote some tools to disassemble it a while ago but I didn't manage to crack the essential part
<mborzecki> mvo: hey
<zyga> the encoding of the state engine transition tables
<zyga> those are highly compressed and optimized
<zyga> and I just didn't understand the kernel code that walks over them
<zyga> there's no documentation that helps that I could find
<zyga> mvo: hey
<zyga> mvo: some bad news
<zyga> mvo: the fix for the bug is blocked
<zyga> I'm happy to HO to discuss this quickly
<mborzecki> zyga: have you reached out to jdstrand_ or jjohansen maybe?
<zyga> mborzecki: jj no, jdstrand yes
<mborzecki> maybe it's like a known issue or sth :)
<zyga> we talked about this on friday, no effect
<zyga> nope
<mvo> zyga: hm, ok - is there a tl;dr summary?
<zyga> mvo: a single test fails, only on 14.04, it makes no sense: https://github.com/snapcore/snapd/pull/6891#issuecomment-495643768
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> mvo: we get a single apparmor denial for a rule we definitely hold
<zyga> mvo: requires jumps to kernel to debug
<mvo> zyga: given that 14.04 is EOL I'm not sure we should block things. how bad is the denial?
<zyga> mvo: snap-confine doesn't work
<zyga> all snaps fail
<zyga> it's not great
<mvo> zyga: :(
<zyga> see
<mvo> zyga: it does not work *at all* ?
<zyga> yes, it stops early on a mount permission and dies
<zyga> mvo: I added "mount," rule and that fixes it
<mup> PR snapd#6915 opened: spread: enable Fedora 30 (2.39) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6915>
<zyga> but as soon as I try to express the arguments used by the call it is failing again
<zyga> mvo: perhaps I missed something, it was late on friday
<zyga> mvo: fresh pair of eyes (or even one) appreciated
<mvo> zyga: what PR is it?
<zyga> the one linked above, 6891
<zyga> mvo: AFAIR we fail on line https://github.com/snapcore/snapd/pull/6891/files#diff-af477950316a096b57d91c74478bc4d2R252 which is handled by this rule https://github.com/snapcore/snapd/pull/6891/files#diff-798ce6f0668878eda67847b4ab492745R150
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> but again, perhaps I missed something
<zyga> but suspicious that it is only 14.04
<zyga> other systems pass this test
<mvo> zyga: looking
<zyga> thank you!
<zyga> mvo: note: failed flags match error says that apparmor found the rule for the mount path, but not for the flags
<mup> PR snapd#6914 closed: tests: change strace parameters on snap-run test to avoid the test gets stuck <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6914>
<zyga> that's very suspect IMO
<zyga> flags are "rw, rshared" in the denial
<zyga> anyway, back to initramfs
<zyga> please ping me if you find anything
<zyga> we should also look at "settle is not converging" bug
<zyga> it is 100% reproducible in packaging builds
<mup> PR snapd#6916 opened: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6916>
<zyga> something fishy
<mup> PR snapd#6895 closed: cmd/snap-confine, data/selinux: cherry pick Fedora 30 fixes to 2.39 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6895>
<mvo> mborzecki: do you have the comments in 6874 on your radar? the post-merge ones from jamie?
<mborzecki> mvo: yup, opened #6916
<mup> PR #6916: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6916>
<mvo> mborzecki: \o/ thank you
<zyga> it's even reviewed already :')
<zyga> gnome shell bug where background doesn't render drives me crazy
<zyga> quality of the linux desktop has never been thix mised
<zyga> *mixed
<mvo> woah
 * mvo hugs zyga for already reviewing it
<zyga> on one hand side it's really the golden age where hardware works great and there's lots of polish
<zyga> on the other hand we're building a desktop shell in javascript and running it ends with stream of crap javascript errors
<zyga> and this is cross dirstro: suse, ubuntu - all broken
<pstolowski> morning!
<zyga> I'm afraid to update fedora (
<zyga> hey pawel, good morning, welcome to our new right-wing world
<zyga> huh, suse update resulted in EFI mok enroll?
<zyga> (with an opensuse key)
<mborzecki> pstolowski: hey
<mborzecki> zyga: background doesn't render?
<zyga> yep
<mborzecki> zyga: how so?
<zyga> https://www.irccloud.com/pastebin/Sjl5oiPM/
<zyga> like this
<zyga> if you google for the "tweener" and some other messages it's a pretty widespread problem
<zyga> doesn't *for whatever reason* happen on wayland
<zyga> happens 100% on X11 on all my up-to-date distros
<zyga> must be the new shell
<zyga> 18.04 is ok
<zyga> the key is May 27 09:04:22 fyke gnome-shell[3767]: Object Meta.Background (0x5584c4024190), has been already deallocated â impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
<zyga> nothing like working on bright white background in the morning
<zyga> oh, suse update just fixed it
<mborzecki> zyga: hm, that's been fixed afaik
<zyga> right
<zyga> QA
<mborzecki> zyga: i think you also need to have some specific extensions to trigger that
<zyga> 100% vanilla
<zyga> but anyway, even if that is true
<zyga> do you recall something this silly in any old desktops?
<zyga> I mean, ever?
<mborzecki> hmmm, let me think, gnome panel going crazy was rather common
<mborzecki> kde crashed a lot too
<zyga> so now we traded crashes to javascript errors on mouse motion
<mup> PR snapd#6835 closed: snapstate: allow removal of non-model kernels <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6835>
<zyga> guess that's just inevitabale ;)
<mborzecki> zyga: it's called progress :P
<mborzecki> zyga: at least it's not an electron app
<mvo> yet!
<mborzecki> Download snap "snapd-hacker-toolbelt" (26) from channel "stable" (received an unexpected http response code (408) when trying to download https://api.snapcraft.io/api/v1/snaps/download/FMONi3pH7TfSv15FusziadAGCjQ6t4EG_26.snap)
<mvo> hm, do we retry on 408? it seems we should
<pedronis> mvo: hi, I made a comment after it was merged on #6835
<mup> PR #6835: snapstate: allow removal of non-model kernels <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6835>
<mvo> pedronis: thank you! I will do a followup with your comments and refactor this code a bit
<mvo> zyga: there is some funny stuff happening in the VM with the fix for 6891 - the test failed on 14.04, I ran it manually and it failed. I ran it again and now its not failing anymore
<zyga> !??!
<zyga> whaat
<mvo> zyga: yeah, quite puzzling
<zyga> can you discard and re-run
<zyga> does it fail?
<mvo> zyga: I'm looking at the profiles not etc
<zyga> I mean, it seems to fail on just construction
<mvo> zyga: sure, one sec
<zyga> so discarding and running that hello command should be enough
<mborzecki> got to go to school to pick up my son, he's not feeling too well, back in a bit
<mvo> zyga: just looking at the timestamp of the apparmor profile to double check nothing has changed
<zyga> mvo: remember about reexec, are you editing the right profile?
<zyga> mborzecki: o/
<mvo> zyga: I did not edit anything so far and tried "SNAP_REXEC=0|1" without any difference this is why I'm puzzled :)
<mvo> zyga: aha, now its consistently failing again, but I need to set "SNAP_REEXEC=1 ..."
<zyga> indeed, that's a good find though
<zyga> we repackage, right?
<zyga> so reexec vs not should not matter
<mvo> zyga: let me compare the profiles
<mvo> zyga: hm, so /var/lib/snapd/apparmor/snap-confine.snapd.x1 seems to miss bits, i.e. the rshared bits that got added
<mvo> zyga: it looks like the profile is outdated
<zyga> hmmmmm
<zyga> that's weird
<zyga> repackaging is broken?
<mvo> zyga: which of course raises the question - why on 14.04 only?
<zyga> exactly!
<mvo> zyga: oh, maybe because we have some strange if 14.04 in the prepare code :(
<mvo> zyga: let me look
<zyga> some tabs-vs-spaces in prepare-restore.sh
<zyga> mvo: I don't see any smoking guns, looking at delta in packaging/
<mvo> zyga: let me poke at this, I have an idea
<zyga> mvo: there's a difference wrt .real vs non profile
<zyga> maybe what we are hitting is a bug in snapd + packaging
<zyga> 14.04 doesn't have the .real suffix
<zyga> mvo: we should drop the .real suffix in 19.10
<zyga> mvo: I'll keep you to it, thank you for looking and for the insight
<zyga> I'll resume initramfs poking
<mvo> zyga: thank you!
 * zyga hugs mvo! :)
<mvo> zyga: yeah, let me poke for 5min and hopefully I get an idea
<mvo> zyga: no sense in duplicating the effort
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<mborzecki> re
<mup> PR snapd#6917 opened: Add endpoint for snap download in the daemon <Created by glower> <https://github.com/snapcore/snapd/pull/6917>
<mborzecki> zyga: i think i can split #6890
<mup> PR #6890: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>
<zyga> mborzecki: in a call
<zyga> re
<zyga> mborzecki: that's neat, thank you, I will be looking at gadget reviews all week; please let me know which one to start with
<zyga> * as long as it's not the 2K one
<mborzecki> zyga: haha :)
<mvo> zyga: I am running a final test now on 6891 now, if its green I push a 2 line fix in the test setup to it (if you don't mind)
<zyga> mvo: how could I mind :D
<zyga> mvo: thank you so much
<mvo> zyga: worked locally, pushed now
<zyga> \o/
<zyga> thank you!
<zyga> brb, need to run an errand at school, 30min
 * pstolowski needs to run an errand, bb in ~1h
<zyga> back now
<mup> PR snapd#6918 opened: snaptest: add helper for mocking snap with contents <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
<mborzecki> a really simple one ^^
<zyga> mborzecki: don't we have something like that already?
<zyga> mborzecki: +1 on the patch but perhaps look at the tree, I'm pretty sure we have ad-hoc implementations
<zyga> that could be reduced
<mborzecki> zyga: afaik no, we have something that packs a *.snap, but that's not what i'm looking for
<zyga> I mean there are bits that drop files on disk, along with a meta/snap.yaml
<zyga> then parse the yaml and return that
<zyga> we have way too many helpers like that
<zyga> it'd be great if all such helpers *had to* use snaptest
<pedronis> we did a pass of reducing that afaik, that's were the helper are coming in the first place, might still be some
<mborzecki> zyga: to be precise, i don't see anything similar in snaptest, there's bits in random tests that do ioutil.WriteFile
<pedronis> *where
<zyga> yeah
<zyga> that's what I mean
<mborzecki> zyga: tbh, this is pulled from #6750 which.. introduces such helper locally :)
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<pedronis> zyga: mborzecki: I don't think it should be a blocker either way, the test grew organically, also if all it's inolved is a couple WriteFile, it's unclear if the helper are a big win or not
<zyga> +1
<zyga> mvo: https://github.com/snapcore/snapd/pull/6891 is green!
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<mvo> zyga: yay! once its in we need to make sure we have a 2.39 PR too
<mvo> zyga: but we can discuss in the standup
<mvo> zyga: maybe we add this in .40 only
<zyga> mvo: yeah, let's review it first!
<mborzecki> pedronis: about https://github.com/snapcore/snapd/pull/6750/files/34e6a2ba202c127efa934e72d2cd6f57d429a8d1#r281945201 you're thinking some operation log for later auditing?
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<zyga> brr
<zyga> brb :)
<pstolowski> re
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6918/
<mup> PR #6918: snaptest: add helper for mocking snap with contents <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
<pstolowski> k
<mborzecki> pstolowski: thanks!
<pedronis> mborzecki: yes, and also to help debugging
<mup> PR snapd#6918 closed: snaptest: add helper for mocking snap with contents <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
<mborzecki> no space left on device keeps breaking the builds from time to time: https://paste.ubuntu.com/p/TjtdxMmKzB/
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/6899 needs de-conflicting
<mup> PR #6899: image: make prepare-image recovery-system aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/6899>
<pstolowski> pedronis: also, remodelling PRs have conflicts
<pstolowski> zyga: hey, what's the status of https://github.com/snapcore/snapd/pull/6347 ?
<mup> PR #6347: many: allow snap-update-ns to write user mount profile <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6347>
<pedronis> mvo: pstolowski: I applied some of the feedback to #6838
<mup> PR #6838: overlord/devicestate: introduce remodel kinds and contexts <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6838>
<pstolowski> thanks, i'll finish this review
<zyga> pstolowski: hey, a little bit on hold this week, I mergef fmaster into them on Friday but I need a moment to iterate towards something reviewable
<pstolowski> zyga: k
<pstolowski> pedronis: 2 small questions to the PR
<mup> PR snapd#6916 closed: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6916>
<pstolowski> mvo: what was the 19.10 low-hanging fruit you mentioned in the standup?
<roadmr> ð  ð  ð
<pedronis> pstolowski: --explain but it needs some design, so I don't think it's that low hanging
 * zyga goes for lunch
<pstolowski> pedronis: i see
<pedronis> pstolowski: what is the status of the slot-snap-type changes? and of fixing the content bug in a more general way?
<pstolowski> pedronis: still needs work, i need to return to that branch. as mentioned before some i found a few interfaces problematic
<pedronis> pstolowski: I probably need to understand the problem to help
<pstolowski> pedronis: i'll check that branch and summarize then issue(s), then get back to you
 * zyga finished lunch, thinking about either taking a short break and walk or getting coffeee
<zyga> after that, grub.cfg hacking :)
<zyga> and some more fun in initramfs
 * cachio afk
<pedronis> pstolowski: thx
<mvo> sil2100: do you think you can look at https://github.com/snapcore/pc-amd64-gadget/pull/14 ? note that it will only be in the new "20" branch (which is only used for experimental UC20 images) so very low risk
<mup> PR pc-amd64-gadget#14: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<sil2100> mvo: hey! Sure thing - I'll have a quick fix for core18 PR'ed soon, can I poke you for a review of that one in return? ;)
<mvo> sil2100: sure
<mup> PR core18#130 opened: gpg (dirmngr actually) panics when there's no random/urandom <Created by sil2100> <https://github.com/snapcore/core18/pull/130>
<sil2100> mvo: ^ that's the PR I was talking about, just pushed the latest version. Let me look at your PR now o/
<sil2100> (I'll have to look why it suddenly stopped working though, out of curiosity)
<mvo> sil2100: yeah, I would love to figure out why it stops working, maybe a snapcraft change?
<mvo> sil2100: so you have a link to the failure without the pr 130?
<mup> PR #130: Basic kernel/os handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/130>
<sil2100> mvo: you can reproduce it locally even, so I just checked and the reason is that now in our ubuntu-base tarballs our /dev directory is empty
<sil2100> mvo: previously we had all the /dev/random and /dev/urandom shipped in the tarball
<sil2100> Need to check if that's intentional that they're gone
<sil2100> mvo: (as for failures, you can see them on LP as well: https://launchpad.net/~ubuntu-core-service/+snap/core18)
<sil2100> But as said, it's just that the base tarball stopped shipping those - investigating why now
<mvo> sil2100: aha, nice. thanks for digging into the root cause
<sil2100> mvo: ok, I guess this is due to livecd-rootfs 2.525.23 ;/ Apparently this change was made for docker, will have to ask mwhudson a bit about this one then
<sil2100> "Backport two minimizations for the docker images: remove apt lists that are removed downstream anyway, and remove device nodes from the image. (LP: #1828118)"
<mup> Bug #1828118: docker tarballs contain /dev/null <verification-done> <verification-done-bionic> <verification-done-cosmic> <verification-done-disco> <livecd-rootfs (Ubuntu):Fix Released> <livecd-rootfs (Ubuntu Bionic):Fix Released> <livecd-rootfs (Ubuntu Cosmic):Fix Released> <livecd-rootfs (Ubuntu
<mup> Disco):Fix Released> <https://launchpad.net/bugs/1828118>
<sil2100> mvo: I guess this might be an architectual question what we should actually expect having in the ubuntu-base tarball
<sil2100> Maybe I should add some conditionals checking for the existance of these files and only then create/delete them
<sil2100> Actually, wonder what happening in the end snap
 * cachio lunch
<sil2100> Ok, images with the snap work - but still, let me bring that up with Steve
<mvo> sil2100: ta
<mvo> sil2100: yeah, the change itself looks fine but I'm a bit worried it might have unintended side-effects
<mup> PR core18#130 closed: gpg (dirmngr actually) panics when there's no random/urandom <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/130>
 * zyga was going through some core20 ideas during the walk
<zyga> now shower and more work :)
 * cachio afk
<mup> PR snapd#6915 closed: spread: enable Fedora 30 (2.39) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6915>
<mup> PR snapd#6838 closed: overlord/devicestate: introduce remodel kinds and contexts <Remodel :train:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6838>
<mup> PR snapd#6919 opened: cmd/okay: Remove err message when warning file not exist <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/6919>
<mwhudson> wait, ubuntu-base:minimized builds are used for core18??
#snappy 2019-05-28
<mborzecki> morning
<mborzecki> new kernel, brb
<mborzecki> re
<zyga> Hey hey
<zyga> mborzecki: yesterday was very productive
<zyga> I will have nice stuff to share today.
<mborzecki> zyga: hey
<zyga> I want to add some polish and shine still
<zyga> And maybe setup primitive ci
<zyga> Now taking a small detour to get kids to school on time
<mup> PR snapd#6896 closed: cmd/snap: tweak the output of snap debug timings --ensure= <Simple ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6896>
<pstolowski> morning
<zyga> hey pawel
<mborzecki> pstolowski: hey
<zyga> quick breakfast
<zyga> pok
<zyga> breakfast over, time to get stuff done :)
<zyga> anyone wants to look at https://github.com/snapcore/snapd/pull/6891
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> mborzecki: or perhaps 2nd review on https://github.com/snapcore/snapd/pull/6909
<mup> PR #6909: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
<mborzecki> zyga: 'll add it to my queue, looking at #6900 now
<mup> PR #6900: [RFC] snapstate: support base = "none" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6900>
<zyga> thank you!
<pstolowski> thanks mborzecki!
<mborzecki> pstolowski: if we go down the route of snap.Validate() in 6900 then the check_snap piece can probably be dropped
<mborzecki> btw. do we validate that base: <foo> looks like a valid snap name?
<pstolowski> let me check
<mborzecki> mvo: pedronis: hey
<pstolowski> mborzecki: heh, it seems we don't. not super critical afaict since we will simply fail on prerequsites, but i'll address it (in a separate PR as it's not strictly related to base:none PR)
<mborzecki> pstolowski: sgtm
<mup> PR snapd#6882 closed: cmd: add snap-verify stub binary (UC20) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6882>
<zyga> mvo: do you know how to get in touch with the canonical web team?
<pedronis> pstolowski: mborzecki: hi, I think we might even have a card about missing some sanity checks on base itself
<pedronis> pstolowski: we have this  (not about the name) but could fir in that new PR: https://trello.com/c/KNa3zFfQ/146-check-early-that-declared-bases-have-actually-type-base
<pstolowski> pedronis: ack
<pedronis> pstolowski: I assigned it to you and move the base none card to doning
<pedronis> *moved
<pstolowski> pedronis: ok, thanks
<zyga> snap download hangs for me, hmm
<zyga> error: received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_216.snap?token=1559048400_9a35b33e1aa3a9d811a4ee1c835fbdf663e027ed
<zyga> anyone seeing store woes?
<mborzecki> well, at least it's not 418 :)
<mborzecki> zyga: status.snapcraft.io seems fine
<zyga> odd, trying again
<zyga> well, this is fastly
<mborzecki> maybe something about fastly
<zyga> yeah
<zyga> fluke, it's working now
<Eighth_Doctor> zyga, mborzecki: so Flock 2019 CfP deadline is June 1
<mborzecki> Eighth_Doctor: you're reminding me of my univestity days :P
<Eighth_Doctor> do we have something we want to do for Flock?
<Eighth_Doctor> we've done quite a fair bit since last year... :)
<Eighth_Doctor> between the SELinux stuff and the prep work we did for bases...
<mborzecki> idk, selinux doesn't feel like much, zyga do you have anything?
<zyga> mborzecki: I think selinux is the thing, it'd be a nice way to meet people that know a lot about it
<zyga> I think you should go :)
<zyga> where is flock this year?
<zyga> mvo: do you know how to get in touch with the canonical web team?
<Eighth_Doctor> Budapest
<zyga> mborzecki: talk to mvo
<zyga> I think you should go
<Eighth_Doctor> zyga, mborzecki: do either of you think we could do something about getting fedora-based snaps something people could make by flock?
<Eighth_Doctor> if we could get there, we could also propose a workshop for making fedora-based snaps
<pedronis> mborzecki: #6750 has a conflict btw
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<mborzecki> wow, again? hmm
<zyga> Eighth_Doctor: I think that's unlikely, we're prepping a demo for something and even regular work is lower priority
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705,
<mup> snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6825, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899,
<mup> snapd#6900, snapd#6904, snapd#6905, snapd#6909, snapd#6913, snapd#6917, snapd#6919
<mvo> zyga: the web team? yeah, I can get you in touch with people, let me look, one sec
<zyga> thank!
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705,
<mup> snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6825, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899,
<mup> snapd#6900, snapd#6904, snapd#6905, snapd#6909, snapd#6913, snapd#6917, snapd#6919
<mborzecki> pedronis: ok #6750 and #6836 updated
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<mup> PR #6836: overlord/snapstate: add update-gadget task when needed, block other changes <Gadget update> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6836>
<pstolowski> pedronis: fyi, i figured out my issues with base decl and policy checks wrt to the WIP branch removing sanitizeReservedForOS/Gadget/... helpers
<pstolowski> pedronis: it all boiled down to the default "allow-installation: false" in base decl taking affect in my minimal install check
<mup> PR snapd#6904 closed: timings: always store ensure timings as long as they have an associated change <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6904>
<mvo> 6804 needs a second review
<Chipaca> pedronis: you got a minute?
<mup> PR snapd#6920 opened: timings: tweak the conditional for ensure timings <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6920>
<pstolowski> doh, that was wrong branch
<mup> PR snapd#6920 closed: timings: tweak the conditional for ensure timings <Simple ð> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6920>
<mup> PR snapd#6921 opened: timings: tweak the conditional for ensure timings <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6921>
<Saviq> zyga: hey, what's the status of "base: core16 â core18" migration these days? we're getting more and more headaches being stuck at core16 stillâ¦
<Saviq> like, how likely is it that things will break?
<zyga> Saviq: no change, deprioritized
<zyga> some bugs fixed, some remain
<zyga> Saviq: online updates still not supported
<mup> PR snapcraft#2571 opened: cli: refactor re-execution into legacy <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2571>
<zyga> small break
<Chipaca> pedronis: request for a minute cancelled
<mup> PR snapd#6917 closed: Add endpoint for snap download in the daemon <Created by glower> <Closed by glower> <https://github.com/snapcore/snapd/pull/6917>
<mup> PR snapd#6922 opened: gadget: mounted filesystem writer <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6922>
<mborzecki> zyga: split out the writer part ^^
<mup> PR snapd#6923 opened: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6923>
 * pstolowski lunch
<mup> PR snapd#6921 closed: timings: tweak the conditional for ensure timings <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6921>
<zyga> mborzecki: ack
<zyga> mborzecki: can you please document things like Deploy and DeployContent
<zyga> mborzecki: reviewed
<mborzecki> zyga: thanks, pushing the comments in a minute
<mborzecki> zyga: the 3rd point is actually something that is done by the updater with the anlysis/rollback-preparation pass
<zyga> hmm, but the code has hard-coded sync flag?
<zyga> did I misunderstand that?
<mborzecki> zyga: no, the updater actually directly calls deploy{File,Directory} when needed
<zyga> hmm, that wasn't my point
<zyga> if you deploy a tree with 3 files
<zyga> you sync on each one
<zyga> in practice that is expensive
<zyga> you could deploy all three and then sync once
<zyga> (even with old-fashioned sync as sync APIs are a bit limited)
<mborzecki> off to pick up the kids
<zyga> hmmm
<zyga> cmatsuoka: ping
<cmatsuoka> zyga: o/
<zyga> question, one sec
<zyga> ok
<zyga> so
<zyga> the pc-kernel snap
<zyga> in the 18 track
<zyga> if you unsquash that
<zyga> there's an initrd.img file
<zyga> it's 3MB more or less
<zyga> and contains a simple initrd with a bunch of stuff
<zyga> not sure why but I cannot seem to unpack it correclty
<diddledan> who's in charge of the forum? https://forum.snapcraft.io/t/code-block-syntax-highlighting-no-longer-works/11004/4
<zyga> if I do it only contains intel microcode, at 32KB
<zyga> diddledan: don't know, perhaps mvo_ does
<cmatsuoka> are you using unmkinitramfs?
<zyga> cmatsuoka: no, I was using cpio directly
<cmatsuoka> zyga: try with unmkinitramfs, it's easier than using binwalk and cpio
<zyga> there's no such binary on opensuse
<zyga> but do you know what's going on
<zyga> is this the appended cpio with some malformed stuff that causes this?
<zyga> if you cpio --list it will show you that the initrd contains the microcode
<zyga> what does unmkinitramfs do?
<cmatsuoka> so the initramfs can have multiple sections, the microcode is in the first one. if you run binwalk on the initramfs file you'll see the different sections
<cmatsuoka> but binwalk can get confused sometimes and list something that doesn't exist
<cmatsuoka> unmkinitramfs does the right thing and reads all sections
<zyga> I see now, that's odd
<zyga> thanks!
<cmatsuoka> I don't know the exact unmkinitramfs mechanism, but it works better than doing it by hand
<zyga> I was working with a custom initrd but I wanted to play with something derived from the original
<zyga> googling suggests that our official initrd has the wrong alignment
<cmatsuoka> it's a short script, perhaps you can replicate or just run it on suse as well?
<zyga> yeah, now I'm good
<cmatsuoka> the mechanism is: split all parts based on magic, uncompress/unarchive each part
<cmatsuoka> magic bytes, not real magic
<Eighth_Doctor> cmatsuoka: unmkinitramfs is a initramfs-tools specific tool
<Eighth_Doctor> for dracut based initramfs, you need to use skipcpio and then extract the compressed payload with the appropriate tool
<Eighth_Doctor> like so: https://www.thegeekdiary.com/centos-rhel-7-how-to-extract-initramfs-image-and-editview-it/
<Eighth_Doctor> or this: https://doc.rogerwhittaker.org.uk/extract-dracut-initrd/
<Eighth_Doctor> zyga: manipulating dracut-based initramfs is typically done by adjusting dracut configuration or passing in commandline options: https://www.mankier.com/8/dracut
<zyga> Eighth_Doctor: I don't want to use dracut,
<zyga> it's really not anything close to useful now
<zyga> (as in dracut)
<cmatsuoka> Eighth_Doctor: ah interesting. But is the actual file format different? I mean, if you split parts and uncompress/unarchive each of them on a dracut-built initramfs, shouldn't it work as well?
<Eighth_Doctor> cmatsuoka: I don't know, maybe?
<Eighth_Doctor> it'd be nice if someone had contributed those tools into dracut though
<cmatsuoka> my guess is that the final format is the same, but I didn't actually check it
<Eighth_Doctor> cmatsuoka: you can try this by generating a dracut-based initramfs on Ubuntu and seeing if the tool works
 * Chipaca adds a /v2/irc so people can chat with us from snapd
 * cachio afk
<mborzecki> heh -ldflags "-linkmode external -extldflags '-static'" does what we need
<Chipaca> mborzecki: --dammit
<Chipaca> --static-or-die
<mborzecki> hahah
<mborzecki> otherwise it's guesswork whether to CGO_ENABLED or not
<mborzecki> oh and -buildmode=pie triggers external linker
<mup> PR snapd#6924 opened: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6924>
<mborzecki> that should do it ^^
<mup> PR snapcraft#2567 closed: remote build: add warning before sending data <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2567>
<zyga> dinner
<diddledan> that sounds like a plan, zyga ! :-)
<webmind> hi, I've got a nextcloud service installed via snap, but it should only run after an encrypted partition has been unlocked and mounted
<webmind> how do I prevent the service to be run on boot?
<zyga> cmatsuoka, mvo_, pedronis: go works in initrd now
<zyga> I'll continue more tomorrow
<webmind> is there a neat way to run a nextcloud snap on an encrypted storage?
<mup> PR snapcraft#2572 opened: catkin spread tests: stop testing indigo <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2572>
<mup> PR snapd#6825 closed: cmd: rework `snap run --gdb` to work as user <â Blocked> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6825>
<mup> PR snapcraft#2573 opened: catkin spread tests: stop testing indigo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2573>
<mup> PR snapcraft#2574 opened: remote build: retrieve build log files <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2574>
<pedronis> reviews of #6855 would be appreciated
<mup> PR #6855: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6855>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<wmww_> sergiusens: It appears Snapcraft is stripping my build-ids, which is causing mesa to break (only when the snap is built with new versions of Snapcraft). Full details of the problem here: https://github.com/MirServer/egmde-snap/pull/3, It seems to have been fixed by add no-patchelf, but it was quite difficult to diagnose. I'm wondering if this should be reported as a bug in Snapcraft.
<mup> PR MirServer/egmde-snap#3: Resolve i965_dri.so crash by not stripping mesa build IDs <Created by wmww> <https://github.com/MirServer/egmde-snap/pull/3>
<mup> PR snapcraft#2575 opened: catkin spread tests: use kinetic instead of indigo <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2575>
<mup> PR snapd#6541 closed: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<mup> PR snapcraft#2572 closed: [legacy] catkin spread tests: stop testing indigo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2572>
<mup> PR snapcraft#2573 closed: catkin spread tests: restrict tests to Ubuntu 16.04 <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2573>
<jdstrand_> sergiusens[m], kyrofa: hey, I converted an older snap (the review-tools) to use 'base: core' and I'm finding that PYTHONPATH is not set like it was when I didn't specify a base. am I expected to set the PYTHONPATH myself?
<sergiusens> jdstrand_: no, it is all inferred from the path to python inside the snap
<sergiusens> jdstrand: I think we got rid of that even before moving to bases
<jdstrand> sergiusens: I have: #!/usr/bin/env python3
<jdstrand> sergiusens: should that be something else?
<sergiusens> jdstrand: that is fine, this is not classic, right?
<mup> PR snapcraft#2576 opened: [legacy] catkin plugin: remove default rosdistro <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2576>
<jdstrand> sergiusens: strivt
<jdstrand> strict
<jdstrand> sergiusens: well, that may be 'fine' but have to do something like:
<jdstrand> snap run --shell review-tools.snap-review
<jdstrand> $ PYTHONPATH=$SNAP/lib/python3.5/site-packages/:$SNAP/usr/lib/python3/dist-packages/ snap/command-chain/snapcraft-runner $SNAP/command-snap-review.wrapper ...
<sergiusens> jdstrand: can I see your snapcraft.yaml, you shouldn't need that python path, look at "black" in the store as a reference for something using bases
<jdstrand> sergiusens: https://paste.ubuntu.com/p/Z9g4sFX46b/
<jdstrand> sergiusens: maybe because PATH doesn't find python3 in the snap?
<jdstrand> from snap run: $ which python3
<jdstrand> /usr/bin/python3
<sergiusens> jdstrand: the environment is still set through the command wrapper
<sergiusens> jdstrand: so use of --shell will still have its quirks
<jdstrand> snap/command-chain/snapcraft-runner which python3 gives me /snap/review-tools/x1/usr/bin/python3
<jdstrand> sergiusens: sure. ok, so that isn't it
<sergiusens> jdstrand: so what is the error if you do not set PYTHONPATH? IIRC, we have not set PYTHONPATH for the past 2 years
<jdstrand> $ review-tools.snap-review
<jdstrand> Traceback (most recent call last):
<jdstrand>   File "/snap/review-tools/x1/bin/snap-review", line 3, in <module>
<jdstrand>     from reviewtools import modules
<jdstrand> ImportError: No module named 'reviewtools'
<sergiusens> jdstrand: whats the shebang in /snap/review-tools/x1/bin/snap-review ?
<jdstrand> $ head /snap/review-tools/x1/bin/snap-review
<jdstrand> #!/usr/bin/env python3
<sergiusens> jdstrand: can you wormhole me the resulting snap?
<sergiusens> thanks
<jdstrand> sergiusens: sent via privmsg
<sergiusens> meeting starting in 1', but will look right after
<jdstrand> sergiusens: so, fyi, I'm clenning up a lot with this, but review-tools.swift I didn't touch and it has the same problem (it is py2)
<jdstrand> sergiusens: I don't think it has anything to do with the internal renaming though since if I set PYTHONPATH, it works
<jdstrand> sergiusens: fyi, I pushed all my updates to: https://git.launchpad.net/review-tools?h=master, including PYTHONPATH, which I'm happy to update if you find anything. note, I searched the forum for PYTHONPATH and there are quite a few people using. I don't know if that is related
<jdstrand> roadmr: hey, can you pull 20190528-2014UTC? note, this is the big cleanup with internal renamings, etc. besides that there is one change to overrides.py
<roadmr> jdstrand: sure
<jdstrand> roadmr: please note that for the store, I preserved bin/click-review (it is a symlink to bin/snap-review now) and data/snapd-base-declaration.yaml, which is a symlink to reviewtools/data/snapd-base-declaration.yaml
<jdstrand> (I think snapstore may be using that 2nd one for the brand store decls)
<sergiusens> jdstrand: you wiped `$SNAP/usr/lib/python3.5` (https://git.launchpad.net/review-tools/tree/snapcraft.yaml#n79)
<sergiusens> jdstrand: which takes away our sitecustomize
<jdstrand> sergiusens: ah, ok. that probably wasn't wiped before because I combined two parts
<jdstrand> sergiusens: and I was removing clashing bits
 * jdstrand updates
<jdstrand> oh, swiftclient is py3 (it is swift itself that is py2)
<jdstrand> ok, this makes sense
<jdstrand> sergiusens: also, is your black snapcraft.yaml anywhere?
<jdstrand> sergiusens: and thanks for looking at this! :)
<sergiusens> jdstrand: let me make it so for the former and no problem for the latter
<jdstrand> sergiusens: yep, removing that line fixed it right up. thanks again for your keen eyes :)
<roadmr> jdstrand: sorry, was otp - I'll put this in the queue, our tests should catch any big-cleanup trouble
<jdstrand> roadmr: sounds good (I also tested this a lot). lemme know if you see anything weird and I'll jump right on it
<roadmr> +1
<zyga> jdstrand: hey
<zyga> jdstrand: that thing from Friday, that was test system setup bug specific to 14.04
<zyga> jdstrand: I've put further changes on hold until more people review it
<jdstrand> zyga: yes, jjohansen said he'd look at it and I hope to tomorrow as well
<jjohansen> zyga: yeah I am looking into it
<zyga> thanks!
#snappy 2019-05-29
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR # closed: snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2470, snapcraft#2514, snapcraft#2518, snapcraft#2527,
<mup> snapcraft#2539, snapcraft#2544, snapcraft#2560, snapcraft#2564, snapcraft#2569, snapcraft#2570, snapcraft#2571, snapcraft#2574, snapcraft#2575, snapcraft#2576
<mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
<mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905,
<mup> snapd#6909, snapd#6913, snapd#6919, snapd#6922, snapd#6923, snapd#6924
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mborzecki> morning
<mborzecki> zyga: when you're around, can you take a look at #6924?
<mup> PR #6924: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6924>
<zyga> Hey
<zyga> Sure
<mborzecki> zyga: thanks
<mborzecki> zyga: spent a while rebuilding go toolchain and sprinkling soem debug messages around the linker
<mborzecki> zyga: actually, quite an interesting exercise
<zyga> I'm sure :)
<zyga> I'm thinking about taking today off
<zyga> I'm not feeling very well
<zyga> my back is not happy today
<mborzecki> zyga: day off is always a good idea
<mborzecki> ok, got some comments to address in my PRs
<mup> PR snapd#6924 closed: packaging/fedora: force external linker to ensure static linking and -extldflags use <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6924>
<mborzecki> mvo: hi, and thanks!
<mvo> mborzecki: hey, good morning and thank *you* :)
<mvo> mborzecki: nice fix and it unblocks another pr iirc?
<mborzecki> mvo: yes, the one from jdstrand
<mborzecki> mvo: about user.LookupGroup()
<mvo> mborzecki: ha! two even, how nice is that :)
<mborzecki> mvo: other distros build with PIE enabled and that's enough to trigger the use of external linker
<zyga> hey mvo
<zyga> I'm not feeling good, my back is acting up
<zyga> I was thinking about taking that swap day  today if you don't mind
<mvo> zyga: sure
<mvo> zyga: get well!
<zyga> I'll exercise a bit more today, that usually helps
<pstolowski> heyas
<mborzecki> pstolowski: hey
<mup> PR snapd#6909 closed: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6909>
<mborzecki> zyga: so, are you off today? :)
<mborzecki> pstolowski: fwiw, i keep gofmt from 1.10 around for 'changes' like you had
<pstolowski> mborzecki: good idea, thanks
<zyga> mborzecki: yeah, though I may send a patch for ! bug now that no blockers remain
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
<mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,
<mup> snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697, snapd#6705, snapd#6708,
<mup> snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6836, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6871,
<mup> snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6890, snapd#6891, snapd#6892, snapd#6899, snapd#6900, snapd#6905, snapd#6913, snapd#6919, snapd#6922, snapd#6923
<mborzecki> https://paste.ubuntu.com/p/YhDjqdmxnK/ 'Catalog update is doing verbose http logging (it should not).' huh?
<mborzecki> a race of some sort?
<pstolowski> pedronis: hey, can you merge master in #6841?
<mup> PR #6841: overlord: make changes conflict with remodel <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6841>
<pedronis> pstolowski: it's now based on 6855, that needs to go in first
<pstolowski> ok, looking at it now
<mborzecki> pedronis: mvo: do you think we need an experimental flag for gadget update for a while?
<mvo> mborzecki: I don't think so, its up to the vendor to use it and they should know what they do (but pedronis may be of a different opinion)
<pedronis> mborzecki: is opt in anyway also in most cases there is no user to make that decision per machine
<mborzecki> pedronis: mvo: sounds fair
<pedronis> mborzecki: if you are worried though about bugs in the opt in logic, we can have a flag for a bit
<Chipaca> There was an unexpected problem serving your request // Please try again and contact us if the problem persists including EAC6:168A1:B024F2C:10BFCA12:5CEE42BE in your message
<Chipaca> ^^ github OOPSing
<Chipaca> fun fun
<Chipaca> mvo: I was trying to add a comment to #6804: in all new code we really should be calling Context() on the *http.Request instead of adding context.TODO()s
<mup> PR #6804: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>
<mvo> Chipaca: oh, thanks, let me fix this
<pedronis> yes, github is not having good days
<mup> PR snapd#6925 opened: devicestate: disallow removal of snaps used in booting early <Created by mvo5> <https://github.com/snapcore/snapd/pull/6925>
<mvo> Chipaca: should I still keep the todo as is or adjust?
<Chipaca> mvo: where?
<Chipaca> mvo: I meant: in searchStore, instead of ctx := store.WithClientUserAgent(context.TODO(), r.Header.Get("User-Agent")), do ctx := store.WithClientUserAgent(r.Context(), r.Header.Get("User-Agent"))
<mvo> Chipaca: yeah
<Chipaca> ah ok
<mvo> Chipaca: I did that :) mostly wondering about the "//TODO" above
<mvo> Chipaca: if that is still accurate (enough)?
<Chipaca> mvo: heh :)
<Chipaca> mvo: no, it's no longer accurate (if it ever was :) )
<mvo> Chipaca: glad that I asked :)
<mvo> Chipaca: suggestions? or shall I simply remove it
<Chipaca> mvo: what's 'the common layer that calls the handlers'?
<Chipaca> maybe i'm misunderstanding something
<pedronis> mvo: Chipaca: notice that my proposal was ctx := store.WithClientUserAgent(r.Context(), r)
<Chipaca> pedronis: where?
<pedronis> Chipaca: my signature is not what mvo implemented
<Chipaca> ah
<pedronis> Chipaca: mvo: it seems my missed that Request now has Context
<Chipaca> pedronis: mvo's is probably a lot easier to test :)
<mvo> pedronis: oh, did I misread, let me double check
<pedronis> Chipaca: marginally
<pedronis> Chipaca: notice that I'm not proposing to make that thing take only Request
<mvo> pedronis: indeed, silly me!
 * mvo needs more tea
<pedronis> Chipaca: mvo: as I was saying, I missed that Request now has Context, so the my other todo is not relevant anymore for now, until there is something we would like to stick everywhere, though UA might be almost that
<mvo> pedronis: cool, I will update the PR and also use your suggested signature
<pedronis> Chipaca: my todo was about doing something in Command.ServeHTTP
<pedronis> we might want to do that anyway
<Chipaca> pedronis: ah
<Chipaca> pedronis: I didn't know they were your TODOs :)
<mvo> pedronis: you mean something like http://paste.ubuntu.com/p/sDv8YcrNBc/ ?
<pedronis> mvo: yes, something like that
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6926
<mup> PR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
<mup> PR snapd#6926 opened: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
<pedronis> mvo: then the rest of the work would teach store to take more contexts, and use r.Context more
<mvo> pedronis: do you think its worth doing the above pastebin with the rest of the work? or do you think we should hold it? either way is fine for me
<pedronis> mvo: I don't think it's a blocker for this PR
<pedronis> I still think is not the best use of your time to work on this :)
<mvo> pedronis: yeah, I know :(
<mvo> pedronis: I stop and get to the other things
<pedronis> mvo: need to look quickly but this one can problably land and Chipaca can pick up ther others/from there
<mvo> pedronis: yeah, that would be cool
<mup> PR snapd#6759 closed: osutil: now that we require golang-1.10, use user.LookupGroup() <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6759>
<mborzecki> yay
<pedronis> pstolowski: Chipaca: mvo: thank for the reviews to my remodel PR, I'll try to clean it and land it today, worst case it will happen on Monday
<mvo> pedronis: yeah, its super close, its really nice to see how things fit together. given how complicated this topic is it was a joy to read
<Chipaca> pedronis: today is eow for you?
<pedronis> Chipaca: yes
<Chipaca> pedronis: nice
<mup> PR snapd#6804 closed: snap,store,daemon,client: send new "Snap-Client-User-Agent" header in Search() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6804>
<pedronis> Chipaca: so if you need something in particular to be unblocked let me know
<Chipaca> pedronis: you self-requested a review on #6848 so if you had the time to do that it'd be nice
<mup> PR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>
<Chipaca> that'd unblock its followup
<pedronis> Chipaca: it's on my list of trying to get to it today
<pedronis> Chipaca: worst case  there's the context/snap-client-user-agent stuff to pick up
<pedronis> Chipaca: mvo has a couple more PRs open about that, I think there is still a bit more todo
<Chipaca> pedronis: and cohort-in-info
<pedronis> Chipaca: yes, that too
<Chipaca> pedronis: and context-in-all-the-things
<Chipaca> :)
<Chipaca> pedronis: i'm not going to be bereft of things to do
<pedronis> for the latter, it would be best if my PR landed
<pedronis> given it has tests/signature changes in snapstate
<pedronis> pstolowski: do you have PR  about --startup for timings ?
<Chipaca> noted
<pedronis> *a PR
<mup> PR snapcraft#2577 opened: [cli] Add --destructive-mode to clean <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2577>
<pstolowski> pedronis: oh yes i have, forgot to propose it. probably needs some small deconflicting now, will do
<pstolowski> thanks for reminding
<pedronis> pstolowski: np
<pedronis> pstolowski: btw before 2.40 it would be good to have a forum topic with some explanation of snap debug timings and maybe example output from a pi or something
<pstolowski> pedronis: yes, i need to repeat my test, have some old samples
<pedronis> thank you
<zyga> mvo: https://github.com/snapcore/snapd/pull/6926
<mup> PR #6926: tests: stop using ! for naive negation in shell scripts <Created by zyga> <https://github.com/snapcore/snapd/pull/6926>
<zyga> and that's my contribution of the day
<zyga> I'm really swapping now
<mup> PR snapd#6927 opened: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
<mvo> zyga: thank you!
 * pstolowski lunch
<mborzecki> tests that look at journalctl seem to fail erratically on opensuse 15
<mwhudson> mvo: hey i should tell you about the things i had to do to make your "build empty package on powerpc" hack actually work :)
<mwhudson> mvo: (mostly this https://github.com/tianon/debian-runc/commit/22d7b5c648bcac9969d6d02067b0eddcc52af4af )
<mvo> mwhudson: oh, interessting
<mvo> mwhudson: you are using it (or something similar) in some other package ?
<mwhudson> mvo: yeah, runc
<mwhudson> mvo: i think you also need to fix the build deps
<mvo> mwhudson: yeah, just noticed the ftbfs in the ppa, slightly sad about this
<mvo> mwhudson: I have a look, should I apply your patches basicly?
<mwhudson> mvo: well the things i remember are: check for build-arch as well; fix build deps
<mwhudson> mvo: the other stuff i did was add a preinst that yelled at the user but well
<mwhudson> mvo: the whole change to build the empty package is https://github.com/tianon/debian-runc/compare/70957b315f82170dc2ab7085d39c23835c0fa996...xenial
<mvo> mwhudson: nice, thank you! I check it out and update the snapd packaging
<mwhudson> mvo: thanks for the basic idea :)
<mvo> mwhudson: my pleasure! hm, `golang-1.10-go [!powerpc]` does not work?
<mwhudson> mvo: i think it does actually, i forgot you can do that :)
<mvo> mwhudson: cool, thanks! I will give it a go
<mup> PR snapd#6928 opened: packaging: fix build-depends on powerpc <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6928>
<cachio> mvo, hi
<mvo> hey cachio
<mvo> cachio: finally, we have 2.39.1 in beta :)
<cachio> mvo, yes, finally
<cachio> mvo, :)
<cachio> about that, changes not generated on https://people.canonical.com/~mvo/core-changes/html/beta/
<mvo> cachio: aha, yeah, I think its just slow, let me give it a gentle kick
<cachio> mvo, ah, ok, tx
<popey_> Chipaca: want a fun bug? :)
<popey_> Chipaca: run (exactly as written) snap install go --classic --channel=12/stable
<popey_> (a typo, so it presents a list of channels that do actually exist)
<popey_> the list is sorted incorrectly, with 1.10 and 1.11 coming before 1.12
<popey_> Chipaca: https://paste.ubuntu.com/p/t3Z9kbpMny/
<mup> PR snapd#6929 opened: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>
<mborzecki> off to pick up the car and heading home
<mborzecki> back for standup
<zyga> mvo, pedronis: what can cause settle not to converge?
<pedronis> zyga: where? it depends, malformed changes, too little timeout and missing EnsureBefore, tasks that retry
<zyga> so, there's a test that reliably fails when I build a suse package
<zyga> I added some debugging to show tasks and changes,
<zyga> all changes and tasks are done:
<zyga> the test is managers_test.go:3511: mgrsSuite.TestHappyDeviceRegistrationWithPrepareDeviceHook
<zyga> I added this patch as otherwise debugging is pretty hard
<zyga> DEBUG patch https://www.irccloud.com/pastebin/hGnLDEOP/
<zyga> when the test fails the output is:
<zyga> failing test output https://www.irccloud.com/pastebin/PHXiVyeZ/
<pedronis> are they clean though?
<pedronis> settle wait for clean too
<pedronis> not that I remember it should matter here
<zyga> good hint, checking
<pedronis> also print if you hit the done clause at all
<pedronis> or not
<zyga> pedronis: curious
<zyga> none of the tasks or changes are clean
<zyga> so we must be running the cleanups, correct?
<zyga> looking at the debug log that contains errors from failed cleanup tasks...
<zyga> doh
<zyga> it's all a big fluke
<zyga> GOPATH messed up
<jdstrand> zyga: fyi, I'm not sure about jj's plans, but I got tasked on something with priority today (a USN publication) and will not be looking at the apparmor issue (or other PRs) until that is done (targetting eod today)
<zyga> jdstrand: that's okay
<zyga> jdstrand: note, thre's no apparmor issue
<zyga> jdstrand: it was a bug in our test setup
<jdstrand> zyga: oh, does jjohansen know that?
<zyga> I said so yesterday but based on what you just said I must have been vague
<zyga> jjohansen: ^ please don't look at the apparmor bug jdstrand mentioned, it's not a bug, test setup was wrong
<zyga> sorry for not communicating that clearly before
<jdstrand> zyga: maybe I was slow on the uptake but jjohansen wasn't. jjohansen, no apparmor issue ^
<jdstrand> pinged him just in case
<mup> PR snapd#6930 opened: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>
<zyga> hmmmmm
<zyga> something totally bogus is going on
<zyga> TestHappyDeviceRegistrationWithPrepareDeviceHook is not present in 2.39.1
<zyga> yet that test fails
<zyga> something along the way is getting snapd master?
<zyga> mvo: uh
<zyga> mvo: 2.39.1 tarballs are wrong?
<zyga> mvo: it's master, not a .1 branch
<zyga> mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in master
<zyga> mvo: grep for TestHappyDeviceRegistrationWithPrepareDeviceHook in the 2.39.1 branch
<zyga> mvo: and grep for it in the tarball!
<zyga> we need a .2
<mvo> zyga: I took the tarballs down and will investigate
<mvo> zyga: I have had a bit of a heart attack but it seems https://github.com/snapcore/snapd/blob/release/2.39/overlord/managers_test.go#L3511 shows that we have this TestHappyDeviceRegistrationWithPrepareDeviceHook - or are you saying things changed there?
<zyga> oh my god, I'm sorry, I was on 2.*29* not 39
<zyga> so the bugs I saw are real but the tarbralls are okay
<zyga> sorry for the red flag
<mvo> zyga: thanks
<zyga> pedronis: I debugged the issue now
<zyga> osc build sets a proxy and we choke on that
<zyga> better debug log https://www.irccloud.com/pastebin/Pws7SmMF/
<albertosottile> pedronis: I read your answer about the Syncplay classic confinement
<albertosottile> From a technical point of view, we would need access to the binary and to a TCP port on localhost from both VLC and Syncplay
<albertosottile> Your solution would rule out mpv and all users that do not use snap VLC, though
<zyga> pedronis: this is with this patch https://github.com/zyga/snapd/commit/b6e38391e35d1634375a0675e6050e8192aa2cf6
<zyga> mvo: whatever causes this I will adjust the unit tests to run in an offline network namespace
<zyga> mvo: so we will not hit this by surprise the next time
<mvo> zyga: thank you!
<mvo> 6926 is green and needs a second review
<pedronis> albertosottile: hi, I understand, but I'm very reluctant to give classic to this, so we are looking at options, there is also a mpv snap I think, but is didn't reach stable yet
<albertosottile> pedronis: we understand your concerns, and we also would like to address them
<albertosottile> however, we invested a lot of time in preparing a snap for Syncplay and we do not see a way to avoid the use of classic confinement in a short time and/or without noticeable drawbacks...
<pedronis> abeato: I understand, but even if we granted classic temporarily (which is not very common), it's definitely the case that a story how to get out of that as soon as possible is valuable. We are really relucant to give classic to anything that serves outside requests, that guideline hasn't really changed/varied
<pedronis> sorry, albertosottile ^
<pedronis> mvo: did you do something strange with 6899, I got a strange email about it, listing tons of commits
<mvo> pedronis: no idea why you got an email but I did update "20" to master and updated this PR to master as well
<mvo> pedronis: should be all normal in this PR again though
<pedronis> I see, seems github already the merge
<pedronis> for this case
<pedronis> at least in terms of email
<pedronis> s/already/unrolled/
<albertosottile> pedronis: to be honest, I did not find this guideline written somewhere in the documentation. The description of the classic confinement basically says that the app would be allowed to run as close as possible as unrestricted
<mvo> pedronis: so no harm except this stange email?
<albertosottile> I understand your concerns, but Syncplay is a seven years old software with a good user base on Linux
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<Chipaca> pedronis: would it be reasonable to expose snapstate.switchSummary (given it's dupe'd in daemon right now), and if so would that be a reasonable name for it?
<mup> PR snapcraft#2576 closed: [legacy] catkin plugin: remove default rosdistro <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2576>
<mup> PR snapd#6931 opened: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6931>
<pedronis> Chipaca: we could but it's a bit unclear where it should live
<Chipaca> pedronis: or I could grab it from the task :-)
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/6927 failed building the package on sid
<mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
<mup> PR snapd#6932 opened: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<pedronis> Chipaca: did a pass on 6848
<Chipaca> pedronis: thanks
<zyga> mvo: draft https://github.com/snapcore/snapd/pull/6932
<mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
<zyga> it fails, I'll see what to do about the failures
<mvo> zyga: woah
<mvo> zyga: nice
<mvo> cmatsuoka: re uc20> I pushed a hack that should avoid the stray reboot, with that you should be unblocked for the tmpfs work
<mvo> cmatsuoka: its a pr against your core-build git repo
<cmatsuoka> mvo: ack, thanks!
 * cachio lunc
 * cachio lunch
<pedronis> pstolowski: looked at #6923
<mup> PR #6923: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6923>
<zyga> pedronis: FYI, I opened a draft PR that reproduces two unit test failures when network is isolated
<pedronis> zyga: thanks, at this point I will look on monday morning
<zyga> thanks, hopefully by then it will be all fixed :)
<pstolowski> pedronis: thanks!
<pedronis> zyga: maybe, anyway please don't hack the tests to much to fix them. At least the one you shown before should have a couple line fix
<pedronis> just a matter of finding the right couple lines
<zyga> yeah, I'm sure that's true
<pedronis> actually not, the code is eager there
<pedronis> mmh
<mvo> cmatsuoka: mostly fyi - I started with launchpad.net/snap-core20
<pedronis> zyga: I commented in the PR about the 2nd
<zyga> thanks!
<Et0h> Pedronis/jdstrand: Hi, I've been a core Syncplay developer since 2013. We do our best to be responsive to user feedback, and so we've been trying to add Snapcraft support in line with the requests that we have received. It'd be great if you could help make this happen so that our shared userbase who want to use Syncplay via Snapcraft can do so and I am grateful for you exploring this with my
<Et0h> colleague albertosottile. As far as I can see the only way to accommodate this functionality would be for Syncplay to be granted Classic status or something equivalent. Anything you can do to progress this matter would be appreciated.
<jjohansen> jdstrand, zyga: thanks, I was down the rabbit ole on the other bug I was trying to finish first yesterday, so I didn't spend much time on this yet.
<mup> PR snapd#6933 opened: [RFC] snapd: ensure GOMAXPROCS is at least 2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6933>
<cachio> mvo, hey https://paste.ubuntu.com/p/t7ZwjJzW6F/
<cachio> at some point running beta validation for i386 it starts showing errors saying
<cachio> Cannot allocate memory
<mvo> cachio: woah, interessting
<mvo> cachio: reproducible?
<cachio> yes
<cachio> mvo, I ran twice the suite
<cachio> both times failed with same error
<mvo> cachio: woah, ok - who much mem does this vm have?
<cachio> but on different tests
<cachio> 2GB
<cachio> same as usuar
<cachio> usual
<mvo> cachio: should be plenty
<cachio> KiB Mem :  2012832 total,  1218820 free,   272520 used,   521492 buff/cache
<cachio> this is the mem after the test
<cachio> on debug session
<mvo> cachio: can you run something like "snap version" or does that also fail? in the debug shell?
<cachio> I'll add some debug info to see the memory when it fails
<cachio> it works well now
<cachio> the memory is not full anymore
<mvo> cachio: thanks. please keep poking, the diff looks innocent bug of course something external might have changed. if its persists, please mail maciej with instructions how to reproduce and ask him to look at this in his morning (cc me just in case)
<cachio> mvo, sure, thanks
<mvo> cachio: the diff between 2.39 and 2.39.1 looks super harmless so we need to check if something else (like go or gcc or whatnot) have changed
<mvo> cachio: thanks, I have dinner now but will read backlog, keep me posted! and thanks for digging into this
<cachio> mvo, np, please enjoy dinner
<mvo> thanks!
<cachio> mvo, https://paste.ubuntu.com/p/m2KsWxNpJ5/
<cachio> I can reproduce it even havng more than 1GB of memory free
<cachio> :(
<jdstrand> jjohansen: phew, glad to hear. I hadn't yet either (and I was planning to do a deep dive)
<jjohansen> jdstrand: then again maybe not, that rabbit hole involves no-expr-simplify
<jjohansen> :)
<mup> PR snapd#6926 closed: tests: stop using ! for naive negation in shell scripts <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6926>
<cachio> zyga, hey, about the PR #6930
<mup> PR #6930: tests: make more robust how we check the journal log is ready to start a test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6930>
<cachio> did you read my comment?
<jdstrand> jjohansen: uh oh :)
<mvo> cachio: what version of the kernel do you have?
<mvo> cachio: what kernel snap revision?
<cachio> mvo, hold on, I need to create the image
<mvo> cachio: is it always the apparmor profile where it fails? maybe the kernel changed, last kernel change is ~2 weeks
<mvo> cachio: old - in stable - this would match
<cachio> allways in apparmor profile
<mvo> cachio: the packaging changes also look harmless
<cachio> now I am running stable + beta core
<mvo> cachio: if you have the kernel revno of the 2.39 validation that might give us clues
<mvo> cachio: might also be interessting to test with the beta kernel just for the kicks
<mvo> cachio: also the output of cat /proc/meminfo is interessting
<cachio> mvo, https://paste.ubuntu.com/p/drGFsBDV2K/
<cachio> 0B kernel?
<pedronis> mvo: cachio: also reminder that now ubuntu-image stable has --snap support
<pedronis> for that kind of tweaking
<cachio> pedronis, yes, I am using that
<mvo> cachio: I suspect its not really "out-of-memory", I suspect its "out of a certain kind of memory", in the past we had something like "lowmem" in meminfo that we low, everything else was fine
<mvo> cachio: would be great to know if the error is kernel dependent
<cachio> mvo, ok, I'll continue working with this
<mvo> ta
<cachio> mvo, sure
<cachio> I'll test that
<mvo> ta
 * cachio afk
#snappy 2019-05-30
<zyga> good morning
<jamesh> zyga: I ran into a weird bug when mixing the content interface with layouts: https://bugs.launchpad.net/snapd/+bug/1831010
<mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to remap a content plug mount <snapd:New> <https://launchpad.net/bugs/1831010>
<jamesh> with the mount namespace in place, I can't upgrade the package
<zyga> Hey
<mborzecki> morning
<zyga> jamesh: can you please try with ...
<zyga> https://github.com/snapcore/snapd/pull/6891
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<jamesh> I'll give it a go.
<zyga> Thanks!
<zyga> Iâll be in the office soon
<zyga> back now
<zyga> jamesh: so, I'm not sure that branch will help
<zyga> jamesh: but surprisingly it did help with another test that documented a bug
<zyga> jamesh: I'm not 100% sure when the kenels returns EBUSY on mount ops, perhaps it was due to the fact than an app was running?
<jamesh> zyga: I haven't tested it yet, but it wasn't obvious it would
<zyga> jamesh: if this is a blocker for you I can take the bug report and jump into the kernel to see what is really going on
<jamesh> zyga: my guess is that it is trying to unmount the layout mount without first doing the submounts
<zyga> jamesh: but we almost always do that, it never complains
<zyga> jamesh: we always MS_DETACH (aka --lazy) so that should work
<zyga> jamesh: I think there is something else that must be at play
<zyga> jamesh: I know you are busy with lots of stuff and that we owe you a ton of reviews but if you could also review https://github.com/snapcore/snapd/pull/6891 I would love to get some feedback -- it's a tricky PR that involves user mount namespaces
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<mup> PR snapd#6934 opened: tests: fix repack_snapd_snap_with_deb_content <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6934>
<zyga> mborzecki: I cherry picked a bugfix from mvo so that it can land faster ^
<mborzecki> zyga: ah, that one
<mborzecki> zyga: any ideas about sid here? https://github.com/snapcore/snapd/pull/6927#partial-pull-merging if that's something in the distro, i'd expect master to fail too
<mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
<jamesh> zyga: I simplified things a bit to reduce the number of mounts (i.e. not using gtk-common-themes), and was able to reproduce the problem: https://bugs.launchpad.net/snapd/+bug/1831010/comments/2
<mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to remap a content plug mount <snapd:New> <https://launchpad.net/bugs/1831010>
<zyga> jamesh: thanks!
<jamesh> zyga: I think it is the last duplicated mount not present in the snapd fstab that is confusing things
<zyga> curious
<zyga> thanks!
<zyga> jamesh: it might be this bug https://bugs.launchpad.net/snapd/+bug/1828357
<mup> Bug #1828357: snap-update-ns incorrectly sorts mount profile entries <snapd:New for zyga> <https://launchpad.net/bugs/1828357>
<zyga> but then again, maybe not, I'll check
<zyga> mborzecki: looking
<zyga> mborzecki: do you mean:
<zyga> dpkg-source: error: can't build with source format '3.0 (quilt)': non-native package version does not contain a revision
<zyga> dpkg-source: info: using options from snapd/debian/source/options: --include-removal
<zyga> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255
<mborzecki> zyga: yup
<zyga> feels like new debian feature
<mborzecki> zyga: right, but why it doesn't fail on master
<zyga> ah, good question :)
<zyga> dunno
<mborzecki> zyga: btw. are you off today?
<zyga> mborzecki: no no :)
<zyga> today I will be busy
<mup> PR snapd#6934 closed: tests: fix repack_snapd_snap_with_deb_content <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6934>
<pstolowski> mornings
<marcustomlinson> morning :)
<mborzecki> pstolowski: hey
<pstolowski> hey marcustomlinson and mborzecki!
<mup> PR snapd#6935 opened: cmd/snap: support snap debug timings --startup=.. and measure loadState time <Created by stolowski> <https://github.com/snapcore/snapd/pull/6935>
<cjwatson> zyga: unlikely to be new - that error was first added in dpkg commit acc1f37933 in 2013 (with slightly different text at that point)
<cjwatson> zyga,mborzecki: It's a bug in the PR - top line of packaging/debian-sid/changelog should say 2.39.1-1 rather than 2.39.1 (compare with the following changelog stanza in that same file)
<mborzecki> cjwatson: thanks!
<cjwatson> np, took me a little while to spot it
<mborzecki> zyga: that means the changelog in release/2.39 branch is busted too
<mborzecki> zyga: the one for sid
<mborzecki> zyga: well, the travis job on the branch failed :P
<mup> PR snapd#6936 opened: packaging/debian-sid: fix changelog, add revision <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6936>
<mborzecki> zyga: pstolowski: ^^
<mup> PR snapd#6855 closed: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6855>
<zyga> re; sorry for missing half of today, I was baby-sitting upstairs due to unexpected errand for my wife; I'll handle paperwork for half day off
<zyga> back to work now
<zyga> cjwatson: thanks for the analysis, I totally missed that
<zyga> jamesh: hey, any luck with the extra patch?
<jamesh> zyga: sorry.  Got side tracked before setting up a test system.
<zyga> no worries
<zyga> I'll see if I can debug that today
<jamesh> zyga: I suspect it won't make a difference: https://paste.ubuntu.com/p/GV4bQW8XKy/
<jamesh> zyga: I did manage to simplify the test snap down to only using layouts, so it is self contained
<zyga> wow
<zyga> jamesh: what's the kernel version?
<jamesh> zyga: this was on an 18.10 box with 4.18.0-15-generic
<jamesh> I'll grab my other system to see if the same happens with 19.04
<zyga> pstolowski: hey
<zyga> pstolowski: do you have a moment for a quick HO?
<jamesh> zyga: same result on 5.0.0-11-generic
<pstolowski> zyga: hey, sure
<jamesh> (that system needs a reboot)
<jamesh> zyga: https://launchpadlibrarian.net/425983579/snapcraft.yaml <-  that's the simpler version exhibiting the bug
<zyga> pstolowski: pushed to https://github.com/snapcore/snapd/pull/6932
<mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
<mup> PR snapcraft#2575 closed: catkin spread tests: use kinetic instead of indigo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2575>
<pstolowski> zyga: thanks
<mborzecki> journald on opensuse is acting up, i've restarted a spread run that failed on opensuse again and again the log the test is looking for isn't there
<mborzecki> zyga: conflicts in #6932
<mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
<zyga> mborzecki: aha
 * Chipaca wanders off in search of sustenance
 * zyga hands Chipaca a copy of the GNU manifesto ;)
 * Chipaca is suspicious
<zyga> Chipaca: to start the fire ;D
 * Chipaca puts on his FSFLA tee and scowls
<zyga> mborzecki: resolved
<mup> PR snapd#6936 closed: packaging/debian-sid: fix changelog, add revision <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6936>
<mborzecki> pushed the changelog fix to #6927
<mup> PR #6927: release: 2.39.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6927>
<zyga> more unit test failures... https://www.irccloud.com/pastebin/uqQwKN1R/
<zyga> that is curious...
<zyga> pstolowski: heh, that test fails *again*
<zyga> debugging
<zyga> but apparently the unshare -n trick is not enough
<zyga> man, that's fum
<cachio> mborzecki, hey
<cachio> mborzecki, there is an issue on i386, it is going out of memory
<cachio> mborzecki, https://paste.ubuntu.com/p/xbqvTQSp6Y/
<pstolowski> zyga: fails again after your fix?
<cachio> yesterday I was researching about it wit mvo
<zyga> pstolowski: it passes in unshare -n tests, fails in "osc build"
<cachio> mborzecki, but then I spent time doing tests and could reproduce it on beta and candidate
<mborzecki> zyga: maybe loopback is down there after all?
<zyga> mborzecki: no, that causes lots of tests to fail
<zyga> mborzecki: I'd like to get "osc shell" or something like that to play
<zyga> let's see
<mborzecki> cachio: hm looks like something failed while loading apparmor profiles?
<cachio> mborzecki, yes
<cachio> apparmor_parser: Unable to replace "snap.test-snapd-tools.fail".  Out of memory
<cachio> mborzecki,  kernel: vmalloc: allocation failure: 68497 bytes
<cachio> I tested that with kernel on stable and works well
<cachio> but kernel on candidate and beta are failing at some point
<zyga> cachio: can you look at aa-status?
<cachio> zyga, https://paste.ubuntu.com/p/RBPTNpXz4Z/
<zyga> cachio: perhaps after running each test we should remove loaded apparmor profiles
<cachio> zyga, I could try that
<cachio> zyga, it is weird becuase it doesn't fail with pc-kernel=stable
<zyga> cachio: and this is with which kernel?
<cachio> this is with kernel on beta or candidate
<cachio> works well with kernel on stable
<zyga> cachio: do we know what is the difference between those?
<cachio> zyga, no
<cachio> I left tests running
<zyga> cachio: perhaps we can ask the kernel team for a summary?
<zyga> pstolowski: so ...
<cachio> and I just got the results
<zyga> failure in osc build, with extra debugging https://www.irccloud.com/pastebin/xy59XKOr/
<zyga> cachio: +1
<jdstrand> cachio: curious, have you seen https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830502? jjohansen is looking at that
<mup> Bug #1830502: apparmor uses excessive memory leading to oom kill <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1830502>
<cachio> jdstrand, nice
<cachio> jdstrand, that could explains that
<mborzecki> zyga: hmmm that error, looks like temporary/permanent/retryable mess again
<zyga> mborzecki: yeah, we just worked on that with pstolowski
<jdstrand> cachio: it may or it may not, but there are debugging details that jjohansen laid out that might be helpful
<zyga> !!! https://launchpadlibrarian.net/425906431/snapcraft.yaml
<zyga> jdstrand: that's one long layout
<zyga> mborzecki: this is supposed to run with this applied https://github.com/snapcore/snapd/pull/6932/commits/c3b1296f1124158fd7e0987e9bd0196b20b3634d
<mup> PR #6932: tests: run unit tests without networking <Created by zyga> <https://github.com/snapcore/snapd/pull/6932>
<jdstrand> zyga: heh, yes. I think I'm going to put something in the review-tools for an abusive use of layouts. I'm not sure what that number should be, but clearly it is less than what is in that yaml :)
<cachio> jdstrand, sure
<zyga> jdstrand: at most a dozen
<zyga> we can expand if we have to
<mborzecki> zyga: well, so now it connection refused? :)
<jdstrand> ack
<zyga> mborzecki: yeah
<zyga> different error
<pstolowski> uhm
<zyga> pstolowski: ah, I see what the bug is now
<zyga> https://www.irccloud.com/pastebin/62CfKEFd/
<pstolowski> zyga: uhmmm.. horror continues
<zyga> yeahj
<zyga> fixed locally, let's see
<zyga> I'll push that to the offline tests PR
<mborzecki> idk maybe our approach is wrong
<zyga> mborzecki: perhaps
<zyga> mborzecki: we'd have to get some data about how the errors look like
<zyga> put that into a table
<zyga> then train an AI against someone saying if this is good or bad
<zyga> and then if you have a CUDA card we'd retry correctly ;)
<zyga> pstolowski: tests passed!
<pstolowski> \o/
<mborzecki> cachio: did you get a chance to look into updating opensuse to 15.1?
<cachio> mborzecki, no, but I can do it today
<zyga> mborzecki: but in all seriousness, I think we could be better if we had a good data set and wrote proper algorithm
<mborzecki> cachio: 15.1 is out, hope they published the images too
<cachio> mborzecki, nice, I'll check that and create the image if it is available
<cachio> mborzecki, thanks for hte heads up
<zyga> https://build.opensuse.org/project/show/system:snappy
<zyga> darn OSC is *insanely quick*
<zyga> I wrote "osc commit"
<zyga> moved to another display
<zyga> reloaded a tab
<zyga> and it's building already
<zyga> mborzecki, cachio: FYI, I'm discontinuing builds for openSUSE Leap 42.2 and 42.3 as they don't provide golang-go >= 1.9
<cachio> zyga, ok, so I'll clean up them when I create the PR for opensuse 15.1
<zyga> thanks
<cachio> zyga, thanks to you
<zyga> build complete
<mborzecki> zyga: sounds fair
 * zyga looks at mount bug from jamesh now
<mup> PR snapd#6931 closed: tests: force removal to prevent restore fails when directory doesn't exist on lp-1801955 test <Simple ð> <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6931>
<jdstrand> cachio: hey, mvo is out and not sure if you need it, but I saw core20 float into the store queue and I've approved it, but it needs to be released to a channel
<jdstrand> zyga: perhaps you're interested in ^
<zyga> jdstrand: thanks
<zyga> jdstrand: I think we want it in edge only, we'll discuss that
<jdstrand> I figured and would've put it there, but didn't have the perms
<zyga> eh, btrfs corrputed
<roadmr> haha, rancid butter :)
<mborzecki> zyga: clearly production ready fs
<mborzecki> zyga: can you restore from a snapshot at least or sth?
<zyga> yeah, managed to mount a ro copy
<zyga> I'll just add a HDD, reformat and move over
<zyga> using ext4 was my best tumbleweed choice
<zyga> btrfs is cool but no thanks :/
<zyga> rsyncing...
<roadmr> jdstrand: 20190528-2014UTC click-reviewers-tools version  now in production ðª
<roadmr> (nothing broke after the big rename-refactor)
<jdstrand> TooLmaN: exciting! :)
<jdstrand> yikes
<jdstrand> TooLmaN: sorry, nm :)
<jdstrand> roadmr: exciting! :)
<jdstrand> (tab fail)
<roadmr> if you want to get rid of the click-review symlink, I can change the command we invoke
<roadmr> jdstrand: hehe yes tabs can be tricky
<jdstrand> roadmr: it helps if I type the first letter correctly :)
<roadmr> hehe a clear case of autocowreck
<jdstrand> roadmr: I would like to get rid of the click-review symlink, but it is far from urgent. maybe let's sit on 20190528-2014UTC for a little while and then revisit?
<roadmr> jdstrand: sure thing; yes, I think I can change the executable name on my side and if things look stable in a few weeks we can kill the symlink
<jdstrand> roadmr: sounds like a plan
<zyga> mborzecki: wanna see something curious
<mborzecki> zyga: hm?
<cachio> zyga, mborzecki opensuse-15.1 nor available on glcoud yes
<cachio> yet
<cachio> I'll see if I could upgrade from 15.0
<cachio> and start using that
<zyga> mborzecki: https://bugs.launchpad.net/snapd/+bug/1831010
<mup> Bug #1831010: Snapd fails to upgrade package that uses layouts to bind mount parent directory of another mount point <snapd:New for zyga> <https://launchpad.net/bugs/1831010>
<zyga> mborzecki: last two comments
<zyga> this seems to show that our assumptions that we can detach anything are wrong
<zyga> if we need to investigate detach algorithms that untangle mounts then it will be a fun thing to fix
<zyga> cachio: can you ask some suse people about this?
<zyga> cachio: I found this https://build.opensuse.org/package/show/Cloud:Images:Leap_15.1/openSUSE-Leap-15.1-GCE-Guest
<zyga> cachio: https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.1/images/
<zyga> there are images here
<zyga> can you please try those?
<mborzecki> zyga: at least it's reproducible here too
<zyga> mborzecki: some ideas here
<zyga> mborzecki: we can construct an in memory tree from mountinfo mount-id / parend-id pairs
<zyga> and then walk that
<zyga> to unmount leaves before inner nodes
<zyga> I'm still puzzled by propagation of detach mounts
<zyga> perhaps what is really breaking is the propagation of the unmount conflicting with itself?
<tim-jone_> nmcli critical error trying to enable wifi interface on ubuntu core (18.04.2) on raspberry pi
<tim-jone_> sudo network-manager.nmcli r wifi on gives error: (process:3062): nmcli-CRITICAL **: Error: Could not create NMClient object: Could not connect: Permission denied.
<tim-jone_> can anyone suggest what I might do to get wifi working with ubuntu core on a raspberry pi
<Chipaca> tim-jone_: i thought that was handled via netplan
<Chipaca> tim-jone_: but i'm not too certain
<Chipaca> ogra: help?
<tim-jone_> following instructions here: https://gist.github.com/cyan198/6ecdb86267498a51587b4337e47e10f6
<Chipaca> tim-jone_: one thing I see you do that I don't see in that gist is 'sudo'
<cyphermox> tim-jone_: maybe just skip that first part; it might not be disabled at all
<tim-jone_> have been using sudo
<cyphermox> Chipaca: his pasted command did include sudo
<Chipaca> cyphermox: exactly
<Chipaca> the gist does not use sudo
<tim-jone_> yes that error is with sudo
<Chipaca> tim-jone_: and what happens without sudo?
<tim-jone_> same error
<cyphermox> I think you just want to move on to 'network-manager.nmcli d wifi list'
<Chipaca> tim-jone_: what's the output of 'snap connections network-manager'?
<tim-jone_> Interface              Plug                                   Slot                     Notes
<tim-jone_> dbus                   network-manager:wpa                    -                        -
<tim-jone_> firewall-control       network-manager:firewall-control       :firewall-control        -
<tim-jone_> modem-manager          network-manager:modem-manager          :modem-manager           -
<tim-jone_> network                network-manager:network                :network                 -
<tim-jone_> network-manager        -                                      network-manager:service  -
<tim-jone_> network-manager        network-manager:nmcli                  -                        -
<tim-jone_> network-setup-observe  network-manager:network-setup-observe  :network-setup-observe   -
<tim-jone_> ppp                    network-manager:ppp                    :ppp                     -
<tim-jone_> (is there a better way to paste output or should I use a pastebin link or similar in IRC?)
<Chipaca> tim-jone_: paste.ubuntu.com ftw
<Chipaca> tim-jone_: do all nmcli commands end with the same error?
<tim-jone_> cyohermox network-manager.nmcli d wifi list gives the same error (with or without sudo)
<cyphermox> mmkay
<cyphermox> so some kind of real permission issue; Chipaca will def know more about it than me if it has to do with the connections
<Chipaca> tim-jone_: can you pastebin 'snap logs network-manager'?
<tim-jone_> sudo network-manager.nmcli gives version OK, but try any objects (radio etc) it fails
<Chipaca> yeah, there's something wrong permissions-wise, but the connections seem a'ight -- which, unless i'm missing something, means there's a bug in the snap
<tim-jone_> output of snap log network manager : https://paste.ubuntu.com/p/QPwwTx68gv/\
<Chipaca> but that's snap in rather prominent use so somehting's up
<Chipaca> tim-jone_: that seems ok
<Chipaca> tim-jone_: it seems ogra is away, could you open a topic in forum.snapcraft.io (in the 'devices' category)?
<Chipaca> sorry, 'device'
<tim-jone_> OK - will do - but reading the log I pasted I see that despite network manager not working the wlan0 interface is listed via ifconfig which it was not before
<tim-jone_> @Chipaca: have opened a topic in device category as you suggested :-)
<Chipaca> woo, my pr is green, time to take a break
<ogra> Chipaca, what makes you think i know how to use NM on core ? ... none of my images ever used it ;)
 * ogra just uses a proper netplan.yaml and the network-setup-control interface from a configuration snap
<tim-jone_> ogra: is this gist wrong then? : https://gist.github.com/cyan198/6ecdb86267498a51587b4337e47e10f6 (pity its the first hit on google if so)
<tim-jone_> BTW did configure /etc/netplan/50-cloud-init.yaml manually and the wifi interface is up and running
<tim-jone_> is there some other documentation I should be reading?
<jjohansen> cachio, jdstrand, zyga: that is a different bug
<cachio> jjohansen, thanks
<cachio> zyga, , I could reproduce the error using the core from stable and the kernel from beta
<cmatsuoka> what is a common cause for "Reported install problem for xxx" in handlers?
<mup> PR snapd#6927 closed: release: 2.39.1 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6927>
<zyga> jjohansen: thank you for confirming that
<cmatsuoka> May 30 12:39:53 localhost snapd[702]: handlers.go:414: Reported install problem for "snapd" as 05c989c0-82d8-11e9-9fdc-fa163e6cac46 OOPSID
<Chipaca> ogra: I just assume you know everything
 * Chipaca vanishes in a cloud of EOD
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR snapcraft#2578 opened: keyrings: update ROS signing key <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2578>
<Odd_Bloke> Hey folks, how can I remove a snap without wasting time on snapshots?
<Odd_Bloke> (I'm removing it because all the (ephemeral) data ended up corrupted; I really don't want a snapshot.)
<ijohnson> there either is or will be a --purge option to snap remove
<ijohnson> not sure if that has landed or not
<Odd_Bloke> There isn't where I am, unfortunately.
<Odd_Bloke> And it looks like because I've started the remove operation, I'm stuck with the snapshotting regardless.
<ijohnson> you might try refreshing to the edge channel of the core snap
<ijohnson> if you use `snap changes` you can see what id of the remove task is, and then abort that task with `snap abort $id`
<Odd_Bloke> Aha, that got me to the point where I could run `snap set system snapshots.automatic.retention=no` before removing again.
<Odd_Bloke> Thanks for the help, ijohnson!
<ijohnson> also fwiw the --purge option is at least in the edge channel too
<ijohnson> glad to help
<mup> PR snapd#6937 opened: cmd/snap-update-ns: detach unused mount points <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
<zyga> jdstrand: ^
<zyga> jamesh: ^
<zyga> running final spread locally before opening
 * zyga EODs
#snappy 2019-05-31
<mborzecki> morning
<zyga> Hey mborzecki
<zyga> https://github.com/snapcore/snapd/pull/6937
<zyga> From last evening
<mup> PR #6937: cmd/snap-update-ns: detach unused mount points <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
<mborzecki> hmhm what's that? :)
<zyga> Embarrassment
<zyga> jamesh: ^ if you can, can you have a look as well please?
<zyga> Iâm sleepy, will start late
<jamesh> zyga: will do.
<zyga> Thank you :-)
<mborzecki> zyga: reviewed, each time i look at this i actually have to go and take a look at the rest of the code around s-u-n
<mborzecki> zyga: can you take a look at #6929 ?
<mup> PR #6929: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>
<zyga> mborzecki: sure, back in 5 minutes
<zyga> man, my timing sucks
<zyga> back now
<zyga> going to review
<zyga> mborzecki: as for sun, do you have any ideas on how to make things clearer?
<zyga> mborzecki: +1
<zyga> I think you can merge that as is
<zyga> eh, retry branch is red
<mborzecki> zyga: retry the retry branch? :)
<zyga> no, it's really broken
<zyga> maybe pstolowski will have some ideas
<zyga> it feels like chasing a rabbit now
<pstolowski> zyga: it has always been whack-a-mole thing
<zyga> now it's whack some more or disable tests :/
<pstolowski> zyga: i can look at this later/monday (i'm going to take half-day off today)
<zyga> thanks!
<pstolowski> i don't expect this to be a quick fix, it's always painful
<zyga> hey Chipaca
<Chipaca> zyga: hiya :)
<zyga> Chipaca: wanna do a 2nd review https://github.com/snapcore/snapd/pull/6937 ?
<mup> PR #6937: cmd/snap-update-ns: detach unused mount points <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
<zyga> pretty short
<mborzecki> Chipaca: morning sir!
<Chipaca> switched over to firefox last night, looking good so far
<zyga> Chipaca: from chrome?
<Chipaca> yes
<zyga> Chipaca: I play with firefox once in a while, it's pretty speedy!
<Chipaca> only issue is with passwords that didn't auto-migrate
<zyga> it's always surprising when I open it
<zyga> ouch
<Chipaca> but passwords.google.com to the rescue :-)
<zyga> yeah, using safari on ios and macos makes me want to keep using them over other browsers
<zyga> I'd switch easier if firefox integrated with the system keyring
<zyga> and apparently it has a separate one :/
<Chipaca> and with that i discovered parts of aws leaking into amazon.com
<Chipaca> (if you go to amazon.co.uk (or .com)'s "your account" â "login & security", the MFA it asks for is your _AWS_ MFA, which is separate from your amazon.co{m,.uk} MFA
<Chipaca> )
<Chipaca> and, guess who still had their old phone and address in AWS (because I haven't used it since I moved)?
<Chipaca> fun night
<Chipaca> anyway, firefox is nice, and the whole "yeah we're breaking the good ad blockers, but hey at least we're dropping text adds altogether" google thing was too far
<Chipaca> ads*
<pstolowski> hey Chipaca
<pstolowski> Chipaca: also switched to firefox from chrome recently
<Chipaca> we should move our standup away from hangouts :-)
<zyga> I need reviews for bugfixes: https://github.com/snapcore/snapd/pull/6937 and https://github.com/snapcore/snapd/pull/6891
<mup> PR #6937: cmd/snap-update-ns: detach unused mount points <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<Chipaca> zyga: âTo counter that, the writable mimic
<Chipaca> construction code in snap-update-ns switched the stash mount point to
<Chipaca> recursively private, so that prior semantics is retained.â
<Chipaca> zyga: is that "switched" actually a "switches"?
<Chipaca> (i have not looked at the code -- i'm asking if i should expect to find that switch in this pr)
<Chipaca> ((and if not in this pr, where?))
<Chipaca> mborzecki: i wonder what "armound" comes from
<Chipaca> amount maybe?
<mborzecki> Chipaca: probably closest hamming distance
<Chipaca> mborzecki: want to change the suggestion to an actual suggestion so we can commit it? or should I :)
<mborzecki> Chipaca: go ahead :P
<Chipaca> would be nice to know which syscalls are the problematic ones
<Chipaca> so we can fix them in go itself =)
<Chipaca> huh, i don't have permission to commit my suggestions
<Chipaca> mborzecki: can you batch up the two suggestions and try to commit them?
<Chipaca> (the other one is a trivial it's â its)
<mborzecki> Chipaca: sure, let me see
<Chipaca> taw
<mborzecki> and pushed
<Chipaca> tawÂ²
<mborzecki> funny git push is ok, but commiting on review page is not, though supposedly it's the same user attempting the action
<Chipaca> ah, i was wondering :-)
<mborzecki> Chipaca: can you take a look at #6929 ?
<mup> PR #6929: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>
<Chipaca> mborzecki: yes
<mborzecki> Chipaca: thanks!
<Chipaca> editing distance is fun and i hate you for sending me down that fun rabbit hole
<Chipaca> amount is editing distance 3, and there are several words closer
<Chipaca> actually, just two: around and arround are distance 1. Nothing at distance 2.
<mborzecki> Chipaca: arround?
<Chipaca> using the british-english-insane wordlist, yes
<mborzecki> Chipaca: not aground?
<Chipaca> strangely no
<Chipaca> but my code might be buggy
<Chipaca> :)
<Chipaca> that should be there with edit distance 2 though
<Chipaca> hmm
 * Chipaca closs the file and walks away
<pstolowski> zyga: i'll be able to reproduce retry issue even without your PR when using unshared network ns?
<mup> PR snapd#6929 closed: gadget: record gadget root directory used during positioning <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6929>
<Chipaca> mborzecki: ineed i was stomping on distance n things with distance m>n things when they were the same but found later
<Chipaca> mborzecki: https://paste.ubuntu.com/p/bMZDf67zHy/
 * Chipaca now yes deletes the file
<mborzecki> Chipaca: haha :) feel genuinely sorry for triggering this
<Chipaca> :)
<zyga> pstolowski: re, partially, there are different failures with and without the patch
<zyga> pstolowski: but yeah, just look at what the spread test does
<pstolowski> zyga: ack, i've just reproduced httputil failure
<zyga> Chipaca: I meant that the code that does handle the mimic now uses private sharing
<Chipaca> zyga: where 'now' means 'as of this PR'?
<zyga> yes
<zyga> mborzecki: can you complete your review of https://github.com/snapcore/snapd/pull/6937 -- not sure if I need to change anything or just merge it
<mup> PR #6937: cmd/snap-update-ns: detach unused mount points <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6937>
<Chipaca> zyga: if a struct holds a pointer, copying the struct will copy the same pointer
<zyga> I know that,
<zyga> I was explaining why I change the options array
<Chipaca> zyga: wrt the commit message, if you change "the writable mimic construction code in snap-update-ns switched [...]" to "this change switches the writable mimic code [...]", it becomes clearer
<zyga> +1
<zyga> done
<mup> PR snapd#6937 closed: cmd/snap-update-ns: detach unused mount points <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6937>
<pstolowski> can we land https://github.com/snapcore/snapd/pull/6933 per my comment there? would be great to have it in edge after the weekend
<mup> PR #6933: [RFC] snapd: ensure GOMAXPROCS is at least 2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6933>
<mup> PR snapd#6933 closed: [RFC] snapd: ensure GOMAXPROCS is at least 2 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6933>
<zyga> +1
 * Chipaca takes a break
<pstolowski> i'm off for today, have a great weekend guys, see you!
<zyga> pstolowski: bye!
<cachio> pstolowski, enjoy your weekend
<Wimpress> Snapcraft Live starts is a few minutes - https://www.youtube.com/watch?v=oR3XLnhypts
<zyga>  /me lunch
 * cachio lunch
 * zyga had  a glass of wine and is very dizzy now
<Paddy_NI> Hello I wonder if it would be difficult to Snap "peerflix"?  I mean to try this now but was just curious if I might be biting off more than I can chew?
<Paddy_NI> I made a fork of "peerflix" here https://github.com/Paddy-NI/peerflix
<Paddy_NI> I also want to snap "mps-youtube"
<Paddy_NI> I have often found mps-youtube to only work if both it and youtube-dl are installed using "pip3".  If you have installed youtube-dl via apt then it tends to break mps-youtube.
<Chipaca> Paddy_NI: ooh, nice. If you're doing that, you could also patch libncurses to work with the mouse wheel :-)
<Chipaca> (the one in ubuntu still doesn't)
<Chipaca> anyway, EOW for me
<Chipaca> ð
 * cachio afk
<Paddy_NI> I am trying to snap "peerflix" which succeeds of course when using "devmode" however when I switched to "strict" and snap installed it with "dangerous" it poops itself.  Here is the output from "snappy-debug.security scanlog" https://paste.ubuntu.com/p/KhSdP2Bsp6/
<Paddy_NI> Hey popey it would be lovely if you shared your bashrc with us not locals sometime so we could all look at the precious things of the shop!
<cmatsuoka> \o/  writable on tmpfs runs up to console-conf!
<cmatsuoka> (of course console-conf won't do much without a real on-disk writable -- but that's the next step)
#snappy 2019-06-01
<Paddy_NI> I wonder if there is anyway to specify in the snapcraft yaml that I want to use "pip3 install youtube-dl" instead of "youtube-dl" being downloaded with and installed with apt?
<Paddy_NI> mps-youtube works perfectly providing youtube-dl has been installed from pip instead of apt
<Paddy_NI> I wish I could figure out why, I think mps-youtube expects youtube-dl to be somewhere it isn't
<Paddy_NI> hmm.. Unless I can "inject" youtube-dl into the snap the same way that pip would on a running system
<Paddy_NI> Perhaps I need to symlink it somewhere else
<Paddy_NI> hmm "adjust program to not access '@{PROC}/@{pid}/mounts'"
<Paddy_NI> Seems to be a common error with snaps, I'm guessing my issue is either with the version of mps-youtube I am trying to snap or that youtube-dl is either not matching the pafy version or that it is being installed in an odd location.
<Paddy_NI> taking a break
#snappy 2020-05-25
<mborzecki> morning
<mup> PR snapd#8712 opened: o/devicestate: typo fix <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8712>
<mup> PR snapd#8713 opened: update avahi-daemon labelling to allow simply "avahi-daemon" <Created by jetpackdanger> <https://github.com/snapcore/snapd/pull/8713>
<mborzecki> mvo: hey
<mborzecki> mvo: how was the long weekend?
<mvo> hey mborzecki - it was quite nice, thank you ! how are you? what did I miss?
<jamesh> hi mvo
<mvo> hey jamesh ! nice to see you
<mvo> mborzecki, jamesh looks like 8713 should get cherry-picked back into 2.45 (?)
<mborzecki> mvo: yes, i think so, from what i can tell by looking at aa versions, bionic is likely the last release that had /usr/bin/avahi-daemon as the label, but i haven't checked the actual profile content
<mvo> mborzecki: woah, so this went undetected for quite some time
<mborzecki> mvo: i did not check the actual profile content, maybe it was distro patched to use the old name
<jamesh> mvo: the profile is shipped separately in the apparmor-profiles package, which we don't install by default.
<mborzecki> jamesh: so without the profiles package we'd get unconfined, right? that'd explain why it went unnoticed
<jamesh> mborzecki: yes
<zyga> good morning
<zyga> hey jamesh
<zyga> hey mborzecki
<zyga> hey mvo :)
<mborzecki> hey zyga
<mvo> hey zyga ! good morning - how are you?
<mvo> zyga: had a good weekend?
<zyga> mvo: Friday was the best, yeah
<jamesh> hi zyga
<zyga> mvo: offtopic: there was a bunch of weird snaps added to the store over weekend
<zyga> I wonder if we have some sort of store response team to raise those to
<zyga> or if we have some guidelines on phony/phishy snaps
<mborzecki> zyga: some typosquatters?
<zyga> no, they were even kind enough to namespace them all
<zyga> one moment
<pstolowski> morning
<zyga> hey pawel
<zyga> mvo: snap find mobius
<zyga> looks like one large cryptoscam
<mvo> good morning pstolowski
<mvo> zyga: probably best to reach out to #snapstore
<zyga> mvo: right, my question was mostly about that, is IRC the go-to method?
<mborzecki> zyga: hm some forexa apps? that's what it says on their website: ÐÑÐ»ÑÑÐ¸Ð¿Ð»Ð°ÑÑÐ¾ÑÐ¼ÐµÐ½Ð½ÑÐ¹ ÑÐµÑÐ¼Ð¸Ð½Ð°Ð» Ð´Ð»Ñ ÑÐ¾ÑÐ³Ð¾Ð²Ð»Ð¸ Ð½Ð° ÑÑÐ½ÐºÐµ Forex
<mvo> zyga: there is a mailing list iirc
<zyga> mborzecki: dunno what those are, just looked weird
<zyga> they all appeared in one day
<mvo> zyga: but I would start with irc or a bugreport in LP against snapstore, if it looks serious maybe even tagged security
<zyga> ok
<mborzecki> there's even a windows app https://mtrader7.com/ru/terminals/windows
<zyga> thanks!
<zyga> my primary school days are coming to hount me with cyrlic
<zyga> terminal dla windows?
<mborzecki> hahah
<zyga> and offtopic, to close the weekend
<zyga> civ6 is free on epic games
<mborzecki> fwiw, it'd be nice to be able to list the snaps from a given publisher in the snapstore page
<zyga> if you like civ games that's the ultimate bragin
<zyga> mborzecki: oh yeah
<mvo> zyga: woah
<zyga> mvo: it plays wonderfully (though on windows)
<zyga> civ has grown quite a bit since my atari ST days
<zyga> but the mood is really the same
<mvo> zyga: cool, I have a windows partition somewhere :)
<mup> PR snapd#8712 closed: o/devicestate: typo fix <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8712>
<zyga> jamesh: hey, while I have you, do you think https://github.com/snapcore/snapd/pull/8708 is sensible?
<mup> PR #8708: tests: setup portals before starting user session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8708>
<zyga> mvo: travis is often stuck on yellow on PRs btw
<zyga> mvo: usually retriggering the test in travis (which is green on their side) fixes it
<pedronis> mborzecki: hi, did you want to vote need fixing on #8661 ?
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mborzecki> pedronis: hm?
<mborzecki> ah
<zyga> hey pedronis
<mborzecki> pedronis: right, wanted to check in with mvo about this
<zyga> pedronis: I didn't get to it last week but you can expect first wave of tool patches today
<zyga> pedronis: I made progress on https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> pedronis: it should be ready for tomorrow, perhaps we could discuss what needs to happen next
<zyga> hmm, I think cachio may have left the 16.04-32 bit image unupdated
<pedronis> mvo: hi, shouldn't debian-sid rules rm  snap-bootstrap like 14.04 ?
<mvo> pedronis: I think we don't even build it there, let me doulbe check
<mvo> pedronis: iirc during the build phase there is a "rm -rf cmd/snap-bootstrap"
<pedronis> ah, you are right, I'm reading the rm wrong
<mvo> pedronis: no worries, it would be nice to be more uniform but the dh-golang tool does not respect buildtags accross the board. I filed a debian bugreport a while ago (with patch) but that got no traction
<pedronis> mvo: unrelated, do you remember why we have a specific ubuntu-17.04 packaging symlink ?
<mvo> pedronis: historic reasons, we can kill all of that, actually let me do this
<mup> PR snapd#8714 opened: packaging: remove obsolete 16.10,17.04 symlinks <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8714>
<zyga> brb
<pedronis> pstolowski: mvo: hi, I tried to re-run #8697, there's a lot of weird errors, I don't understand if we broke something on master or if it's related to packaging changes in odd ways
<mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<pstolowski> pedronis: thanks, i will keep an eye on it; i pushed some changes last friday but only run them on a subset of systems & only with the new spread test, so it is possible it breaks something
<pedronis> pstolowski: we really need it unblock your config PRs
<mvo> pedronis: in a meeting but I can check later
<pedronis> pstolowski: are you working on the feedback to #8304 ?
<mup> PR #8304: usersession/userd: add zoommtg url support <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
<pedronis> sorry
<pedronis> pstolowski: I meant, #8704
<mup> PR #8704: cmd/snap-preseed: improve mountpoint checks of the preseeded chroot (1/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8704>
<pstolowski> pedronis: yes, i'm going to update it today
<pedronis> ok, thx
<zyga> small breakfast and back to work
<zyga> re
<zyga> mvo: can you please force merge https://github.com/snapcore/snapd/pull/8708
<mup> PR #8708: tests: setup portals before starting user session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8708>
<zyga> not sure how to unstuck travis there
<mvo> zyga: sure
<zyga> thanks!
<mup> PR snapd#8708 closed: tests: setup portals before starting user session <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8708>
<pedronis> mvo: some questions/comments in #8351
<mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<mvo> pedronis: cool, thank you
<pedronis> pstolowski: I reviewed #8709
<mup> PR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
<pstolowski> pedronis: thank you
<mup> PR snapd#8715 opened: tests: port interfaces-network-status-classic to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8715>
<pedronis> mborzecki: thanks for the review of the Pool stuff
<zyga> brb
<zyga> small coffee break
<zyga> hmmm
<zyga> 2020-05-25 10:24:19 Cannot allocate google-unstable:opensuse-15.1-64: cannot allocate new Google server for opensuse-15.1-64: invalid value for field 'resource.shieldedInstanceConfig': ''. Shielded VM Config can only be set when using a UEFI-compatible disk
<zyga> mvo: ^ FYI, this is the outdated image used after deploying the new spread binary
<zyga> we should discuss spread at the standup
<mvo> zyga: ok
<mup> PR snapd#8714 closed: packaging: remove obsolete 16.10,17.04 symlinks <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8714>
<mup> PR snapd#8716 opened: o/devicestate: refactor current system handling <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8716>
<mborzecki> pedronis: ^^
<mvo> zyga: I reworked 8508 and it uses outputs now, much nicer indeed
<zyga> wow :)
<mvo> zyga: please have another look, I think this is good to go now
<zyga> looking
<zyga> it was just a suggestion, I didn't know you'd go all the way :)
<mvo> zyga: it is much nicer this way
<zyga> mvo: https://github.com/snapcore/snapd/pull/8508#pullrequestreview-417632557
<mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<mvo> zyga: thanks! yeah, I think the root-owned one is fixed, I will do a followup one this one is in
 * mvo didn't want to cram too much into this tiny PR
<pedronis> mborzecki: are you (still) working on not accepting mode not to be set in modeenv?
<mborzecki> pedronis: yes, i'm back at that branch
<pedronis> mborzecki: thx
<zyga> mvo: thank you!
<zyga> pedronis: small step towards what we discussed https://github.com/snapcore/snapd/pull/8717
<mup> PR #8717: test: session-tool cli tweaks  <Created by zyga> <https://github.com/snapcore/snapd/pull/8717>
<mup> PR snapd#8717 opened: test: session-tool cli tweaks  <Created by zyga> <https://github.com/snapcore/snapd/pull/8717>
<zyga> I' afraid my dog just told me I should go for a walk :D
<zyga> brb
<mup> PR snapd#8718 opened: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
<pstolowski> pedronis: fyi, my packaging change fails because of  panic: user: Current not implemented on linux/amd64
<pedronis> pstolowski: ?
<pstolowski> pedronis: something isn't included in the build and snap cli panics in some use cases (login?). i'm unclear, investigating
<zyga> re
<zyga> pstolowski: re
<zyga> pstolowski: when I looked at godbus code there was some interesting difference between how godbus is built
<zyga> pstolowski: and the code handled variants with cgo, without cgo, on various systems
<zyga> pstolowski: perhaps we need somiething similar
<pstolowski> zyga: it was caused by passing CGO_ENABLED=0
<zyga> pstolowski: https://github.com/godbus/dbus/blob/master/homedir.go https://github.com/godbus/dbus/blob/master/homedir_dynamic.go and https://github.com/godbus/dbus/blob/master/homedir_static.go
<zyga> linux sound magic, after unplugging headphones there was no sound for like 30 seconds
<zyga> anyway
<zyga> back to work
<mup> PR snapd#8715 closed: tests: port interfaces-network-status-classic to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8715>
<mup> PR snapd#8719 opened: tests: remove dbus.sh <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8719>
<ijohnson> mvo zyga so if I just go to 8508 and try to restart one of the spread jobs there that passed it should be really quick and effectively a no-op right ?
<zyga> ijohnson: looking
<zyga> ah
 * ijohnson is excited to try this
<zyga> yes, I think so :)
<zyga> if not it'd be quite funny
<zyga> let's try?
 * ijohnson excitedly clicks buttons
<mvo> ijohnson: correct
<mvo> ijohnson: I guess there are a bunch of people starring at this now :)
<ijohnson> haha
<ijohnson> well now it seems the jobs are stuck waiting in the queue because multiple people tried it at once
<zyga> aka "insert coin"
<zyga> ijohnson: not as exciting but super simple https://github.com/snapcore/snapd/pull/8719
<mup> PR #8719: tests: remove dbus.sh <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8719>
<ijohnson> Nice I'll take a look after SU
<zyga> thanks :)
<zyga> it's just a rm -f
<ijohnson> indeed it is! In that case here's your +1
<zyga> standup :)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8720/files <- any ideas on better "gimme all processes" command?
<mup> PR #8720: spread.yaml: add ps aux to debug section <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8720>
<mup> PR snapd#8720 opened: spread.yaml: add ps aux to debug section <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8720>
<zyga> at this rate we will have beta and then some more releases till stable
<mborzecki> zyga: gamma?
<zyga> mborzecki: like adom version
<roadmr> hey folks any idea who's a good person to poke about snap-store (the gui client)? kenvandine maybe? (but he's off today)
<zyga> roadmr: no idea, but probably ken indeed
<roadmr> thanks zyga :)
<mup> PR snapd#8721 opened: devicestate, sysconfig: revert support for cloud.cfg.d/ in the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/8721>
<mvo> zyga: do you know if there is something funny going on with our gh action runners? I see that 8508 takes forever to be re-run, any idea?
<zyga> mvo: looking
<zyga> lots of busy runners
<zyga> mvo: queue size ~10
<zyga> mvo: it should clear in 30 minutes
<zyga> looks like we got a number of tests re triggered or started
<zyga> oddly one stuck at -discard for 2 hours 44 minutes
<zyga> and one 16.04-64 running for over 3 hours 40 minutes
<zyga> but most of the queue looks happy
<zyga> ah, sorry, those are zombies
<zyga> perhaps actions runnner bug / not collecting zombies
<zyga> note that https://github.com/snapcore/snapd/actions?query=is%3Ain_progress gives pretty good visibility
<zyga> remember that each really consumes a number of runners at once
<mvo> ijohnson: 8508 did successfully run the cached results, I triggered another run to see if restarting twice works too (I see no reason why it would not but I'm paranoid)
<mvo> ijohnson: but yeah, looks like this is ready
 * mvo hugs mborzecki for this 
<zyga> yeah, it will be the best of both worlds
<mborzecki> yay
<ijohnson> mvo: great news!
<ijohnson> thanks mborzecki and mvo this will be super amazing
<mborzecki> but we fixed the random issues in the tests :P
<zyga> mborzecki: haha
<zyga> mborzecki: only some
<zyga> mborzecki: invariant-tool is amazing because a simple few lines shows you what's left TODO
<mborzecki> hmm why on earth unsquashfs would read /var/run/systemd/userdb which obviously has systemd_userdbd_runtime_t context
<mborzecki> unless it's some another pam/nss/systemd thing
<mvo> I bet it's pam/nss/whatnot
<mborzecki> heh, man 8 nss-systemd, This module preferably utilizes systemd-userdbd.service(8) for resolving users and groups, but also works without the service running.
<mvo> squashfs is not getting that many commits these days, I don't think code for that would have made it (but I could be wrong of course)
<mborzecki> and we call unsquashfs -l during install to check the sanity of a snap
<mborzecki> it's still the same user tho
<mborzecki> ah ok, unsquashfs may be calling getpwent() or somesuch to translate uid -> name
<pedronis> mvo: mborzecki: I commented quickly on #8661
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mborzecki> that hits nss, and eventually may reach nss-systemd which probably reads the db directly for simple queries
<zyga> mborzecki: must be nss
<zyga> https://github.com/snapcore/snapd/pull/8717 is simple and needs a 2nd review
<mup> PR #8717: test: session-tool cli tweaks  <Created by zyga> <https://github.com/snapcore/snapd/pull/8717>
<zyga> gentle rain outside, what a lovely sound
<mborzecki> pedronis: thanks
<pedronis> mborzecki: tbc, the main comment was about no restarting things if nothing has changed
<pedronis> the other one is cosmetics
<Eighth_Doctor> zyga, mborzecki: hey all
<zyga> hey
<zyga> how are you?
<Eighth_Doctor> ehh, as well as I could be
<Eighth_Doctor> day one billion of the quarantine
<Eighth_Doctor> I talk to the napkins now :)
<zyga> Eighth_Doctor: really? I must go out more
<roadmr> haha it's been less than 3 months :P
<roadmr> Schools here closed on March 12th or so
<Eighth_Doctor> Datto closed on March 13, but I stopped one day early
<mup> PR snapd#8568 closed: asserts: rest of the Pool API <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8568>
<ijohnson> zyga: #8717 has 2 +1's and is almost entirely green
<zyga> thanks, merging!
<mup> PR #8717: test: session-tool cli tweaks  <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8717>
<mup> PR snapd#8717 closed: test: session-tool cli tweaks  <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8717>
<mborzecki> afk for some time
<mup> PR snapd#8722 opened: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
<mvo> cmatsuoka: I pushed a very simple spread test, could you please check that this is essentially what you did with hostname when you tested this manually?
 * zyga reboots for updates
<mup> PR snapd#8508 closed: github: run all spread systems in a single go with cached results <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<mup> PR snapd#8723 opened: github: remove workaround for bug 133 in actions/cache <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8723>
<pedronis> mvo: I made also this comment: https://github.com/snapcore/snapd/pull/8661#discussion_r429969902
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<cmatsuoka> mvo: checking
<cmatsuoka> mvo: btw uc18 is also slow, but it doesn't have the 14s delay before the ttyS0 initialization
<pedronis> pstolowski: mborzecki: thanks for the Pool reviews, I landed the bits, now there's the main branch using it, but probably can wait a little bit before reviews, I want to discuss something first
<pstolowski> pedronis: is it updated with master?
<pedronis> pstolowski: it is, but as I said can wait a little bit
<pstolowski> pedronis: ack
<pedronis> ijohnson: #8718 is probably something you can help reviewing
<mup> PR #8718: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
<ijohnson> pedronis: sure will take a look today
<pedronis> thx
<mup> PR snapd#8720 closed: spread.yaml: add ps aux to debug section <Simple ð> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8720>
<mup> PR snapd#8704 closed: cmd/snap-preseed: improve mountpoint checks of the preseeded chroot (1/3) <Preseeding ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8704>
<mup> PR snapd#8724 opened: interfaces/block_devices: add NVMe subsystem devices, support multipath paths <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8724>
<mvo> pstolowski: I merged 8704 to unblock you, still one suggestion inline that might be worth looking at in one of the followups
<pstolowski> mvo: thanks! right, will do
<zyga> thanks mvo!
<pedronis> mborzecki: I reviewed #8716
<mup> PR #8716: o/devicestate: refactor current system handling <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8716>
<pedronis> mvo: did you see my comment about missing newlines? you pushed many times to that PR but not a fix for that
<mvo> pedronis: aha, sorry, missed it
<ijohnson> I'm so confused right now
<ijohnson> somehow a change in github.com/snapcore/snapd/snap dir is making github.com/snapcore/snapd/wrappers/ fail by calling systemctl is-system-running seemingly out of thin air???
<pedronis> ijohnson: afaik only snap run is using is-system-running
<ijohnson> pedronis: yes I figured it out
<ijohnson> we mock systemctl, then we run shellcheck
<ijohnson> on my system shellcheck is a snap
<ijohnson> and it just so happened that I had a system key mismatch, so when `shellcheck` as a snap runs, it tries to check if the system is running using the mocked systemctl
<ijohnson> very very confusing bug
<pedronis> interesting combination
<pedronis> we should probably separate mocking of path vs running shellcheck
<ijohnson> my fix is just to set PATH _after_ we call shellcheck
<ijohnson> I had a similar problem with some other unit test a long time ago where some unit test got confused when run by specifically the go snap, which mad some old SNAP_CONFINE var get set and confused the unit test
<mup> PR snapd#8725 opened: testutil/exec.go: set PATH after running shellcheck <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8725>
<ijohnson> pedronis: so to fix 8711, I wanted to add an options struct to Install, but have that struct defined in github.com/snapcore/snapd/snap/container.go
<ijohnson> but then that leads to an import cycle for github.com/snapcore/snapd/snap/squashfs/squashfs.go to use the struct
<ijohnson> so I'm disentangling them so that container.go doesn't container a reference to squashfs and snapdir, then have a register format function like we did in dirs
<ijohnson> does that sound reasonable ?
<ijohnson> I will propose this in a separate PR from 8711
<pedronis> ijohnson: not sure, it changes how you have to import things
<ijohnson> now with my code snap/container.go doesn't import anything from github.com/snapcore/snapd
<ijohnson> pedronis: would it be easier if I just propose it so you can quick look at it?
<pedronis> ijohnson: I mean the issue is that now the other places need to import snapdir and squashfs manually
<ijohnson> pedronis: how so ?
<ijohnson> I ran all the unit tests and I didn't need to change anything else
<pedronis> ijohnson: mmh
<pedronis> I'm probably missing something but the tests probably have explicit imports for their reasons
<pedronis> in snaptest
<pedronis> etc
<mup> PR snapd#8726 opened: tests: silence stderr from dbus-monitor <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8726>
<ijohnson> mmm let me quick propose it maybe I'm missing something
<ijohnson> pedronis: https://github.com/snapcore/snapd/pull/8727
<mup> PR #8727: snap/container.go: don't import snapdir, squashfs; use register format w/ init() <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8727>
<mup> PR snapd#8727 opened: snap/container.go: don't import snapdir, squashfs; use register format w/ init() <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8727>
<mup> PR snapd#8719 closed: tests: remove dbus.sh <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8719>
<pedronis> ijohnson|lunch: yea, what I suspected happens, we either need to paper it over, or think more
<pedronis> ijohnson|lunch: https://paste.ubuntu.com/p/JVRZWBHFsm/
<ijohnson|lunch> Hmm
<ijohnson|lunch> I see your point now
<ijohnson|lunch> But how do we not catch this in any unit tests
<ijohnson|lunch> ð
<pedronis> ijohnson|lunch: because the unit tests import snapdir and squashfs explicitly in a couple of places
<pedronis> for their reasons
<ijohnson|lunch> Right but the snapd daemon level tests should surely check that something happened right?
<ijohnson|lunch> They should be using snapdir from the snaptest util package iirc
<ijohnson|lunch> Anyways I need to eat lunch
<ijohnson|lunch> I will look at this in a little bit
<pedronis> ijohnson|lunch: well, that's the problem snaptest imports snapdir
<ijohnson|lunch> Oh I see
<pedronis> anyway I don't think the paper it over approach is appropriate
<pedronis> because is fairly annoying for this case
<pedronis> real fixes are probably bit of a pain though
<mup> PR snapd#8727 closed: snap/container.go: don't import snapdir, squashfs; use register format w/ init() <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8727>
<mup> PR snapd#8728 opened: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
<pedronis> ijohnson|lunch: ping me on tg when you want to discuss this
<ijohnson|lunch> pedronis: sure probably 15 minutes
<ijohnson|lunch> *in 15 minutes
<pedronis> ijohnson: hi
<ijohnson> hey
<ijohnson> I'm back now if you want to discuss
<ijohnson> pedronis: ^
<pedronis> ijohnson: yes
 * zyga afk
<ijohnson> pedronis: SU hangout ?
<pedronis> ijohnson: ok
<mup> PR snapd#8729 opened: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
<pedronis> ijohnson: did a bit of reviewing, I think the not-symlinking PR is too aggressive, will not work well after seeding
<ijohnson> Hmm
<ijohnson> pedronis: So you want the if condition in snapstate to be more specific and only to be applied when seeding is unset?
<pedronis> ijohnson: I think it can defined differently and then it doesn't matter again
<pedronis> ijohnson: there's a bit of a question what to do about snapdir case, it's really for snap try
<pedronis> copying is never what you expect there
<ijohnson> pedronis ok I see your review
<ijohnson> pedronis we could make snapdir just ignore the flag?
<pedronis> ijohnson: either that with a TODO, possibly in uc20 we should check that dir(targetPath) and s.path are on the same device
<pedronis> but is not a blocker atm I think
<pedronis> ijohnson: also it adds some spread testing, I made a suggestion
<pedronis> s/adds/needs/
<ijohnson> pedronis axk
<pedronis> ijohnson: to be clear, at it is I think some try tests at least will fail, because they edit things in place
<pedronis> which witht the copy won't work
<pedronis> we might have also some spread testing about hardlinking, not sure
<pedronis> ah, also tests/core/seed-base-symlinks/task.yaml needs to be changed, it has a TODO:UC20 atm, but needs a comment about it never working on UC20 intentionally
<ijohnson> ok, I'll try to fix that as well, need to step out for a bit but I will try to fix before your AM
<pedronis> ijohnson: thank you (I got disconnected, so maybe you saw that already)
<ijohnson> Yes I saw it
<mup> PR core20#65 opened: Do not attempt signing changes during snap build <Created by xnox> <https://github.com/snapcore/core20/pull/65>
<mup> PR snapcraft#3144 opened: docker: setup a multiarch build for snapcraft docker images <Created by adferrand> <https://github.com/snapcore/snapcraft/pull/3144>
#snappy 2020-05-26
<mborzecki> morning
<zyga> o/
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8726
<zyga> it's a one liner and I have a follow-up it opens
<mup> PR #8726: tests: silence stderr from dbus-monitor <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8726>
<mborzecki> zyga: ack
<zyga> for some context, privately I've been using a version of https://github.com/snapcore/snapd/pull/8728
<mup> PR #8728: tests: detect stray dbus-daemon <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8728>
<zyga> and it essentially prints a TODO list of tests to improve
<zyga> mborzecki: I replied but let's chat here
<zyga> right now there's nothing more on stderr, if it goes to a file it'd be rather short-lived as that directory goes away when session-tool quits
<mborzecki> zyga: if something fails does is the directory removed too?
<zyga> yes
<zyga> I looked at the rest of the script and we log other things there
<zyga> but it's a remnant of development when I just would comment out the cleanup logic
<pedronis> fedora-32 is listed in the workflows but doesn't exist in spread.yaml, this is making it fail constantly
<zyga> pedronis: oh?
<zyga> perhaps mvo added that with the caching PR
<pedronis> seems so
<pedronis> zyga: see here:  https://github.com/snapcore/snapd/pull/8729
<mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
<zyga> yeah, indeed, it's there in the patch
<zyga> it's not marked as requires so it was masked by opensuse failing as well, I suspect
<zyga> if we cannot get a working image today I'll drop it from the matrix with a comment
<pedronis> it was marked as required
<pedronis> or maybe I'm confused
<pedronis> anyway
<pedronis> #8729 needs a 2nd review
<mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
<mborzecki> i'll fix the sanpd selinux policy today so we'll be able to merge cachio's fedora 32 pr
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8729#pullrequestreview-418005303
<mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8729>
<pedronis> mvo: mborzecki: hi, Pawel's #8697 needs reviews
<zyga> mborzecki: cool
<mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<mvo> pedronis: sure, looking
<mup> PR snapd#8723 closed: github: remove workaround for bug 133 in actions/cache <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8723>
<mup> PR snapd#8721 closed: devicestate, sysconfig: revert support for cloud.cfg.d/ in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8721>
<mup> PR snapd#8729 closed: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
<pstolowski> morning
<mup> PR snapd#8730 opened: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8730>
<mborzecki> quick drive by fix when testing package updates pushed by Eighth_Doctor ^^
<pstolowski> mborzecki: hi, can you take another look at https://github.com/snapcore/snapd/pull/8697 ?
<mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<mborzecki> sure
<zyga> pstolowski: small comment https://github.com/snapcore/snapd/pull/8697/files#r430205753
<mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<zyga> not incorrect, just spreading the awesomeness of make
<pstolowski> zyga: that's nice, thank you
<mvo> zyga: oh, nice!
<pedronis> mvo: the prereq has landed squash merged, now #8711 needs a 2nd review and hopefully to be (almost) green
<mup> PR #8711: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout <Needs Samuele review> <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8711>
<mvo> zyga: this should make some of the other stuff we do much more readable if we use this trick
<mvo> pedronis: \o/ I have a look
<zyga> mvo: cool :)
<zyga> mvo: it's annoying we need to repeat this across packaging
<zyga> I wish we'd use snaps.mk more
<zyga> brb
<mvo> zyga: unfortunately I don't think that's an option for debian/ because if we ever want someone to maintain this it has to be as clsoe as possible to a "standard"
<zyga> mvo: I don't think so, it's not unlike dh_auto* and using a makefile in the upstream project
<zyga> mvo: it's all about integrating dpkg-buildflags inside our native makefile
<mup> PR snapd#8731 opened: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8731>
<mvo> pedronis: I backported 8711 to 2.45, straight cherry-pick did unfortunately not work
<pedronis> mvo: it's because of the prereq? #8729 ?
<mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
<pedronis> or something in it itself?
<pedronis> mvo: ah, you backported the prereq actually https://github.com/snapcore/snapd/pull/8731 ?
<mup> PR #8731: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8731>
<pedronis> mvo: there's a bit of extra tests in boot, do they pass?
<pedronis> mvo: we should backport #8721
<mup> PR #8721: devicestate, sysconfig: revert support for cloud.cfg.d/ in the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8721>
<zyga> pstolowski: with this trick we could actually reduce quite a lot of clutter in the code building commands
<zyga> pstolowski: with this trick we could actually reduce quite a lot of clutter in the code building commands
<pstolowski> zyga: ok, but perhaps as followups
<zyga> yes, totally
<pstolowski> zyga: i'd really like to get this landed to unblock stuff
<zyga> let me do it after your bits land
<mvo> pedronis: 8721> yes, looking at this too
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8730 ?
<mup> PR #8730: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8730>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8656#discussion_r430233548
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<pstolowski> siure
<mborzecki> i'll force push to cachio's f32 pr and drop the last commit he made
<mup> PR snapd#8726 closed: tests: silence stderr from dbus-monitor <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8726>
<zyga> ta mvo
<zyga> and mborzecki :)
<mup> PR snapd#8725 closed: testutil/exec.go: set PATH after running shellcheck <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8725>
<mup> PR snapd#8730 closed: data/selinux: allow snapd to remove/create the its socket <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8730>
<mup> PR snapd#8604 closed: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Squash-merge> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8604>
<mvo> 8351 needs a second review
<mvo> pedronis: do you want to do a review of 8661? it has two +1 at this point (but none from you)
<mup> PR snapd#8732 opened: data/selinux: update policy to allow forked processes to call getpw*() <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8732>
<mborzecki> pstolowski: another one for you ^^
<pstolowski> mborzecki: siure
<pstolowski> grr
<pstolowski> *sure
<pstolowski> zyga: can you remind me where in the spread suite do we check for leftovers from namespaces etc?
<zyga> pstolowski: what do you mean by leftover from namespaces?
<pstolowski> zyga: sorry, probably mount changes; anything that lxd can leave behind
<zyga> I see
<zyga> I don't think we do that regularly
<zyga> we kind of do it in one spot in mount-ns test
<zyga> a branch that I have long open tried to but it picked up too many failures so it was unable to land
<zyga> we may get that, a bit, with invariant-tool
<pstolowski> zyga: aah, mount-ns test, i think that was it
<zyga> but it needs to be done still
<pstolowski> thanks
<zyga> brb
<pedronis> mvo: ? I don't see the 2nd review
<pedronis> mvo: as I remarked I think we should apply mborzecki idea of trying not to restart if nothing has changed
<pedronis> mvo: I think it needs a review from pstolowski
<pstolowski> pedronis, mvo i'll review it in a bit (and also the vitality PR)
<zyga> re
<mup> PR snapd#8711 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout <Needs Samuele review> <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8711>
<pedronis> mvo: ^ I squash-merged it
<mvo> pedronis: \o/
<mvo> pedronis: re 8661> sorry, ian did two +1 I misread that
<pedronis> ah, was confused for a sec
<pedronis> pstolowski: actualFsTypeAndMountOptions doesn't need to return an error anymore as well
<pstolowski> pedronis: missed that, thanks
<pedronis> pstolowski: np, but that's where I started thinking about this, because I had move the call to it and then wondered if it would change the failure modes but actually it can't error in itself
<pedronis> *I had you
<pedronis> pstolowski: mvo: do we need/want the preseed fixes in 2.45.1 ?
<mborzecki> quick errand, back in 30
<mup> PR core20#65 closed: Do not attempt signing changes during snap build <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/65>
<pedronis> mvo: this is the comment I was referring to in 8661: https://github.com/snapcore/snapd/pull/8661#discussion_r427920348
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<pstolowski> pedronis: that would be nice to have
<mup> Issue core20#63 closed: fix travis builds with new subiquity from git <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/issue/63>
<mup> Issue core20#66 opened: Use focal base in travis <Created by xnox> <https://github.com/snapcore/core20/issue/66>
<pstolowski> otherwise it will take long time before it's easily usable with lxd
<mvo> pedronis: preseed> it would be a good idea, yes
<mvo> pedronis: 8661> aha, sorry, I will look at this
<mup> PR core20#49 closed: fix broken symlinks in /etc/writable <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/49>
<zyga> mvo: I will most likely miss standup today
<zyga> mvo: I'll send notes to the standup doc
<zyga> I may join from a phone if I have the conditions to
<mvo> zyga: ok
<pedronis> pstolowski: mvo: #8697 failed on centos-8, seems unrelated but not sure
<mup> PR #8697: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<pstolowski> pedronis: yes, i've restarted it
 * zyga goes to look at 8697 restart not wasting money anymore
<mborzecki> re
<pedronis> mborzecki: Ian made a suggestion in #8718 then it should be good to go
<mup> PR #8718: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
<mborzecki> pedronis ijohnson  thanks for the reviews
 * zyga hugs mvo 
<zyga> mvo: the caching behavior is BRILLIANT
<zyga> 2 seconds
<mborzecki> need to address some commentrs in 8716 too
<zyga> 0.00 cost
<mborzecki> zyga: hah nice :P
<zyga> I wonder if this will show up in load charts on the spread runner
<zyga> as we're usually bound by memory
<ijohnson> morning folks
<mborzecki> ijohnson: heya
<ijohnson> zyga: re: your comment on 8729 about the header being one byte larger than magic, the magic bytes is just 4 bytes, so a header of 20 bytes already is 16 bytes larger ?
<ijohnson> hey mborzecki
<zyga> ijohnson: yeah but it's a constannt
<mup> PR snapd#8733 opened: tests: port document-portal-activation to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8733>
<zyga> it's okay but not for the right reasons :)
<ijohnson> zyga: so you think it should be only 5 bytes ?
<zyga> I think it should be exactly len(magic) + 1
<zyga> :D
<ijohnson> got it
<mup> PR snapd#8734 opened: tests: port interfaces-wayland to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8734>
<mup> PR snapd#8735 opened: snap/snapfile,squashfs: followups from 8729 <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8735>
<ijohnson> zyga: applied in a followup ^
<zyga> super
<zyga> thanks!
<zyga> I was going to do it myself but I was working on a streak of patches
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8736
<mup> PR #8736: tests: log stderr from dbus-monitor <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8736>
<pedronis> ijohnson: not a fan of len(magic)+1, it's not particularly better or worse than the existing especially now that its in squashfs itself
<mup> PR snapd#8736 opened: tests: log stderr from dbus-monitor <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8736>
 * zyga returns to https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pedronis> ijohnson: I'll push something else there
<ijohnson> pedronis: ok
<pedronis> ijohnson: I mean a 5 bytes file is never a valid squashfs anyway
<ijohnson> well that's not really for us to decide ?
<ijohnson> unsquashfs is the ultimate decider of if it's a valid squashfs ?
<pedronis> ijohnson: not but as a predictor this is worse than before
<pedronis> ijohnson: if we didn't care we could use len(magic) and Equal
<ijohnson> I mean for something that's called magic I wouldn't expect it to be perfect
<pedronis> why the +1
<pedronis> anyway I will do yet something else
<ijohnson> and I think we are splitting hairs over a tiny thing
<ijohnson> sure feel free
<ijohnson> I just took zyga's suggestion
<ijohnson> I have no strong feelings about this really
<ijohnson> just feels a bit pointless
<pedronis> ijohnson: I know, I disagree with the suggestion, doing nothing would have been fine
<pedronis> ijohnson: also fn to f is not an improvement either
<pedronis> ijohnson: anyway, it's not your problem anymore, I will push something there
<mup> PR snapd#8737 opened: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8737>
<pstolowski> Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server for opensuse-tumbleweed-64: invalid value for field 'resource.shieldedInstanceConfig': ''. Shielded VM Config can only be set when using a UEFI-compatible disk
<zyga> pstolowski: known
<zyga> sergio needs to fix the images
<pstolowski> ok
<mup> PR snapd#8731 closed: snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8731>
<mup> PR snapd#8737 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8737>
<mup> PR snapd#8738 opened:  snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8738>
<pedronis> ijohnson: once I was looking there, I added some tests to 8735 as well
<ijohnson> pedronis: ok, seems the scope of the PR has greatly increased though
<ijohnson> anyways approved it
 * ijohnson afk for bit
<pedronis> pstolowski: zyga: I tweaked/expanded a little bit #8729, it needs a re-review
<mup> PR #8729: snap,many: mv Open to snapfile pkg to support add'l options to Container methods <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8729>
<zyga> yeah, reviewing now
<pstolowski> okay
<pstolowski> pedronis: i've commented on the tooling proposal
<zyga> pedronis: reviewed
<pstolowski> pedronis: hmm but 8729 was merged?
<pedronis> heh sorry
<pedronis> pstolowski: I meant #8735, but another review is not stricly needed anymore
<pstolowski> ah 8735 i guess
<mup> PR #8735: snap/snapfile,squashfs: followups from 8729 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8735>
<pstolowski> yep
<pedronis> pstolowski: seems 8697 can be merged now
<pedronis> which should unblock 8533
<zyga> pstolowski: thanks for commenting there
<zyga> pedronis: I agree with pawel's comments
<zyga> pedronis: I don't think we need a distinction between suite/task in the name, a common prefix plus something relevant to the tool function is good for me
<mup> PR snapd#8697 closed: packaging: build cmd/snap and cmd/snap-bootstrap with nomanagers tag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<zyga> pedronis: if you pick a name for session tool I'll do a test mass patch to see how it looks like
<pedronis> zyga: I'm not against the prefix, my issue is that I really care about distinguishing things that affects state across tasks vs not
<zyga> hmmm
<mup> PR core20#67 opened: tests: use SNAPCRAFT_PRIME dir instead of hardcoding "prime" <Created by mvo5> <https://github.com/snapcore/core20/pull/67>
<zyga> so things like retry-tool vs things like lxd cleanup?
<zyga> pedronis: under this classification, session tool does not affect state across tasks, correct?
<pedronis> zyga: well session can survive if don't clean them up, no?
<zyga> pedronis: sure but the point is to pair session prepare and restore
<pedronis> so it affects state across task, unless you use it just right
<pedronis> the classification is based on ideal usage, it's about what gets touched
<zyga> I think virtually everything has this property
<zyga> mkdir does
<pedronis> zyga: mkdir is a tool
<pedronis> sorry
<pedronis> mkdir is not a tool
<zyga> so what is it?
<pedronis> zyga: for analogy, it's the difference between a helper function vs a methond on the suite struct in go
<zyga> ok
<pedronis> we have some stateless helpers attached to suite sometimes
<zyga> I think attaching this to suite is misleading as it reflects a particular way we use it, I look at it more like a context manager in python, it's an enter/exit pair with user code in between
<pedronis> zyga: we don't have a with statement
<mborzecki> pedronis: ijohnson: https://github.com/snapcore/snapd/pull/8716 is updated now
<zyga> as such it could be used with the same vailidity, at the level of a task or the level of a suite
<mup> PR #8716: o/devicestate: refactor current system handling <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8716>
<zyga> pedronis: sure but the pairing nature is similar to one, it's just an analogy
<pedronis> zyga: anyway it seems you are objecting to suite. , not to the dinstiction
<zyga> yes, and I understand your point better now
<zyga> so that glancing at the tool name gives some context as to what is the possible impact
<pedronis> yes
<zyga> I don't know if I have a better name suggestion but I see the goal
<pedronis> zyga: pstolowski: how much is short names a goal for you?
<zyga> pedronis: I'm okay with a non-short name
<mborzecki> time to revisit https://github.com/snapcore/snapd/pull/7414
<zyga> I prefer test- to tst- or similar
<mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<zyga> mborzecki: looking
<zyga> mborzecki: could that be framed in the terms of invariant-tool?
<zyga> I think we should be more about detecting issues than automatically fixing the issue as that is easy not to know about; while somewhat more verbose I'd prefer to see a test both install and remove a package rather than rely on another layer computing and removing everything
<zyga> just my 0.02
<zyga> ok, folks, I'm arriving at my mom's place, I will miss the standup but I'll write something in the document; remember it's mother's day :)
<ijohnson> zyga: interesting mother's day in the US was like 2 weekends ago
<zyga> oh really? :)
<ijohnson> I didn't realize it was different in different countries
<zyga> same here
<zyga> wonder why :)
<mborzecki> zyga: yeah, it's mother's day in pl and maybe some other countries
<ijohnson> yeah it's may 10th in US
<zyga> ok, ttyl
<zyga> I'll be back online when we leave
<mborzecki> wow, checked wikipedia, actually may 26 is mothers day only in PL
<pstolowski> pedronis: not super important
<pstolowski> mborzecki, ijohnson heh, interesting
<ijohnson> haha yeah that's interesting
<pedronis> mborzecki: 8716 looking good, couple small comments
<pstolowski> cachio: hi, i've addressed you comments to #8710
<mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<pedronis> mborzecki: ijohnson: seededSystem and System are internal vs external and have different content, in theory we can unify seededSystem and currentSystem by adding an optional omitempty actions to the former
<pedronis> ijohnson: would that help?
<pedronis> also those struct definitions should probably move to systems.go as well
<ijohnson> yes that sounds like it would help but I don't want to be a bother so if y'all are ok with it as is then it's fine for me too
<pstolowski> we're at the brink of having 4th page of PRs..
<cachio> pstolowski, thanks
<pstolowski> zyga: do you have a moment for https://github.com/snapcore/snapd/pull/8709 ?
<mup> PR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
<pedronis> ijohnson: mborzecki: let's land it as is for now, and I'll look into it
<mborzecki> ack
<ijohnson> fine with me thanks
<pstolowski> pedronis: does https://github.com/snapcore/snapd/pull/8608 still need to be blocked? was it blocked because of 2.45?
<mup> PR #8608: configcore: issue a warning on core16 when journal.persistent option is set <Squash-merge> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8608>
<pedronis> pstolowski: it's blocked becausse mvo made the good point that we should auto-remove the warning if there's a reboot
<pedronis> pstolowski: that needs a bit of infra work I fear
<pstolowski> pedronis: ah.. good point indeed. i think the comment was made elsewhere, i wasn't aware
<pedronis> anyway, it's a bit unclear if it's a good time to work on that
<pedronis> let me put this in it at least
<cachio> pstolowski, I left few comments
<cachio> it is almost ready
<pedronis> pstolowski: ah, you did
<cachio> just 1 thng to fix
<pedronis> pstolowski: thx
<pstolowski> pedronis: ok, i can pick it up when time permits and there is nothing more pressing
<pstolowski> cachio: thanks
<pedronis> pstolowski: exactly
<pedronis> pstolowski: I think early config stuff, services stuff, and probably after that snapshot stuff is higher priority
<pedronis> and making sure preseed works as well
<pstolowski> ack
<pstolowski> pedronis: what's the conclusion re preseed fixes for lxd & 2.45.1?
<pedronis> pstolowski: I think mvo said yes, but he can reconfirm
<mup> PR snapd#8736 closed: tests: log stderr from dbus-monitor <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8736>
<mvo> pstolowski: yes please unless it's a ton of work
<pstolowski> mvo: ok, will do once the remaining 2 PRs land i nmaster
<pstolowski> *in master
<mup> PR snapd#8732 closed: data/selinux: update policy to allow forked processes to call getpw*() <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8732>
<mup> PR snapcraft#3143 closed: cli: migrate close to use the new channel map <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3143>
<mup> PR snapd#8718 closed: boot, many: require mode in modeenv <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8718>
<ackk> sergiusens, jdstrand, hi, FTR it seems even the new review-tools still complain about the $SNAP/bin/python symlink which snapcraft creates. I workaround'd it by excluding it via "prime" as it's not really needed, but it seems something either snapcraft or review-tools should handle?
<mborzecki> afk for some time
<zyga> running out of battery, more work back home
<zyga> o/
<mup> Bug #1880698 opened:  /etc/writable is double mounted <uc20> <Snappy:New> <https://launchpad.net/bugs/1880698>
<mup> PR snapd#8739 opened: tests: port interfaces-desktop-* to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8739>
<mup> PR core20#67 closed: tests: use SNAPCRAFT_PRIME dir instead of hardcoding "prime" <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/67>
<mup> PR snapd#8740 opened: spread.yaml: apply yaml formatter/linter <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8740>
<mvo> cachio: 8693 has a conflict
<cachio> mvo, thanks
<cachio> I'll fix it
<mvo> cachio: thanks!
<jdstrand> ackk: hey, which snap was that again? I don't think the new review-tools is in prod yet
<roadmr> jdstrand: it is, went to prod yesterday
<mup> PR snapd#8735 closed: snap/snapfile,squashfs: followups from 8729 <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8735>
<mup> PR snapd#8656 closed: snap-mgmt: perform cleanup of user services <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8656>
<mup> PR snapd#8738 closed:  snap,many: mv Open to snapfile pkg to support add'l options to Container methods (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8738>
<pedronis> mvo: ^ great, now we can port the fix?
<pedronis> *backport
<mup> PR snapd#8741 opened: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8741>
<pedronis> ah :)
<pedronis> thx
<mvo> pedronis: you want 8656 for 2.45 ?
<pedronis> mvo: the feaure is experimental, but yes, it would make sense
<pedronis> if it's not too disruptive
<mvo> pedronis: sure, let me double check
<mup> PR snapd#8742 opened: snap-mgmt: perform cleanup of user services (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8742>
<mvo> 8351 needs a second review
<ijohnson> mvo is https://github.com/snapcore/snapd/pull/8661 ready out of curiosity ?
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<ijohnson> also mvo did you see my comment in the SU doc about needing to port https://github.com/snapcore/snapd/pull/8706 to 2.45 ?
<mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
<ijohnson> it was a few days ago
 * cachio lunch
<zyga> Iâm home eating lunch
<zyga> Back in some time
<mup> PR snapd#8743 opened: tests: cherry-pick test fixes from master <Created by mvo5> <https://github.com/snapcore/snapd/pull/8743>
<cmatsuoka> ijohnson: I created a model for the pi but my boot is failing because the assertion is signed with an expired key, I think it's caused by the system date being completely wrong there
<cmatsuoka> ijohnson: how do you fix the date in order to be able to boot?
<ijohnson> cmatsuoka: you mean that it's failing to do the first boot of install mode when the seed is verified during the initramfs?
<cmatsuoka> ijohnson: it's failing in install mode
<cmatsuoka> the-tool[285]: [ - assertion is signed with expired public key ...
<ijohnson> cmatsuoka: but to be clear the error is in the initramfs correct?
<cmatsuoka> yes, it's in the initramfs
<ijohnson> cmatsuoka: do you know how far back the time is in the initramfs? I.e. what time the pi thinks it is?
<cmatsuoka> ijohnson: I don't know, can I read that from uboot?
<ogra> its the birthday of the granny of the founder of broadcom ...
<ogra> you cant read it from u-boot
<pedronis> ijohnson: cmatsuoka: we should be able to apply fixes like the one we do from the real systems from snap-bootstrap I suppose
<ogra> (you could patch u-bot to read an RTC if there was a RTC ... but there isnt one on the pi)
<ogra> *u-boot
<cmatsuoka> ogra: how do you deal with this situation? I'm sure you went through this before
<ogra> i wrote the fixrtc script ð
<ijohnson> cmatsuoka: I can show you how to flash a new boot.scr when I'm back from lunch
<ogra> but i think thats been dropped for some new thing that xnox worked on
<ijohnson> That way you can add dangerous to kernel cmdline  and get an initramfs debug shell when the-tool fails
<cmatsuoka> ijohnson: ok, I'll have lunch too and will be back in 30 min or so
<ijohnson> Okay
<mup> PR snapd#8716 closed: o/devicestate: refactor current system handling <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8716>
<mup> PR core20#68 opened: static: make /etc/writable mode "transition" in writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/68>
<xnox> cmatsuoka:  why did you create a new model for the pi? we have all the models one may need avaiable. including dangerous ones.
<xnox> cmatsuoka:  or is it not good somehow?
<xnox> cmatsuoka:  can you share the model please?
<jdstrand> ackk: I found the snap
<ackk> jdstrand, ah sorry, missed your earlier message
<jdstrand> ackk: ok, I see the issue
<jdstrand> cc sergiusens ^
<ackk> jdstrand, it's canonical-rbac. https://dashboard.snapcraft.io/snaps/canonical-rbac/revisions/241/ is an example of one failure
<jdstrand> yep
<jdstrand> thanks
<ijohnson> mvo: approved #8741 to 2.45 for you
<mup> PR #8741: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8741>
<mvo> ijohnson: \o/
<ijohnson> mvo: also did you see my earlier ping re: the serial-port regex PR for 2.45 ?
<ijohnson> mvo: i.e. https://github.com/snapcore/snapd/pull/8706
<mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
<mvo> ijohnson: I did not see that, cherry-pick should be fine
<ijohnson> mvo: ack just an FYI that I requested jdstrand review it, but it was merged before he could review it, not sure if that affects your cherry-pick decision or not
<mvo> ijohnson: done
<mvo> ijohnson: well, now it would have - oh well
<ijohnson> sorry
<ijohnson> I should have made that more clear
<mvo> ijohnson: it's okay, it looks harmless enough
<ijohnson> agreed, I think in the future I will mark as blocked PR's that require jdstrand's review so that this doesn't happen again
<mvo> ijohnson: I added a needs-security label now
<ijohnson> mvo: ok, sounds good
<ijohnson> cmatsuoka: so when you're back, install u-boot-tools via apt, then take this script, https://pastebin.ubuntu.com/p/Nrd5N8n8BV/ and run:
<ijohnson> cmatsuoka: `mkimage -A arm64 -O linux -T script -C none -n "boot script" -d bootscript.rpi /media/your-sd-card/ubuntu-seed/boot.scr`
<ijohnson> cmatsuoka: that script should be named bootscript.rpi for example
<mup> PR snapd#8744 opened: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Created by andrewsomething> <https://github.com/snapcore/snapd/pull/8744>
<jdstrand> ijohnson, mvo: PR reviews start today. I'll do that one first
<ijohnson> thanks jdstrand
<mvo> ta
<sergiusens> jdstrand: thanks
<cmatsuoka> ijohnson: thanks! in this case it seems that the cause was a key that was new and not valid yet :(
<cmatsuoka> ijohnson: I'm rebuilding the image with the dangerous model and overriding channels, that should work
<cmatsuoka> ijohnson: but the store is incredibly slow right now
<ijohnson> :-(
<mup> PR snapcraft#3145 opened: cli: migrate upload and release to new channel-map <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3145>
<mup> PR snapcraft#3131 closed: plugin handler: debug build commands if developer debug enabled <enhancement> <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3131>
<mup> PR core20#68 closed: static: make /etc/writable mode "transition" in writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/68>
<mup> PR snapd#8741 closed: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8741>
<zyga> re
<zyga> cachio: hey
<cachio> zyga, hey
<zyga> cachio: hey, I missed the standup today
<zyga> I wanted to ask about opensuse images
<zyga> did you notice those are not working now?
<cachio> zyga, I am updating those
<cachio> but takes a bit of time
<zyga> ah, great, thank you :)
<cachio> it should be ready in 15 minutes
<cachio> both
<cachio> zyga, np
<zyga> sounds good
<zyga> and another question, is fedora 32 operational?
<zyga> if not perhaps we should disable it form the test matrix
<cachio> zyga, https://github.com/snapcore/snapd/pull/8693/checks?check_run_id=709950381
<cachio> last tests passed
<mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
<zyga> oh that's great
<cachio> I need to fix other images and then we can merge the pr
<zyga> ok, once those are rolled out we should be green
<zyga> ok
<cachio> today I applied the changes suggested in the pr and those worked
<mup> PR snapd#8734 closed: tests: port interfaces-wayland to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8734>
<mvo> a "review" for 8743 would be great, all just cherry picks from master to fix various test failures in 2.45 (probably more to come but this is a good start)
<mup> PR snapd#8740 closed: spread.yaml: apply yaml formatter/linter <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8740>
<jdstrand> sil2100: hey, fyi, you may have noticed that the core snap was blocked on manual review due to tzdata updates in xenial-updates shuffling around files. wondering if you feel like that was useful or if it would be better to skip checking usr/share/zoneinfo
 * jdstrand approved all of those btw
<zyga> jdstrand: o/
<mup> PR snapd#8521 closed: snap-bootstrap,secboot: clear tpm if provisioning fails <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8521>
<mup> PR snapcraft#3146 opened: build providers: snap sw to channels if injecting <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3146>
<zyga> cachio: o/ are the suse images out?
<cachio> zyga, yes
<zyga> thanks, I'll re-trigger a few of my tests
<zyga> this job caching makes running tests just magical
<cachio> zyga, indeed
<jdstrand> hey zyga :)
 * cachio afk
<mup> PR snapcraft#3147 opened: Use `pylxd` instead of `lxc exec` <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/3147>
<mup> PR snapd#8739 closed: tests: port interfaces-desktop-* to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8739>
<mup> PR snapd#8745 opened: tests: port xdg-open-compat to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8745>
<mup> PR snapd#8746 opened: tests: port xdg-open to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8746>
 * zyga wraps up for the night
<zyga> cachio: ^ if you have energy left :)
 * zyga really EODs
<zyga> (I had one more branch ready)
<mup> PR snapd#8747 opened: tests: port snap-routine-portal-info to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8747>
<cachio> zyga, I'll take a look
#snappy 2020-05-27
<mborzecki> morning
<zyga> Hey
<zyga> mborzecki: I will be around in about an hour
<mborzecki> zyga: hey
<mup> PR snapd#8745 closed: tests: port xdg-open-compat to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8745>
<mup> PR snapd#8746 closed: tests: port xdg-open to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8746>
<zyga> thanks!
<zyga> mborzecki: it would be good to review the f32 branch from sergio
<zyga> once merged we should have those green ticks again
<mborzecki> zyga: yeah, i'll be pushing some fixes there
<zyga> ok
<zyga> brb again
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mup> PR snapd#8743 closed: tests: cherry-pick test fixes from master (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8743>
<mvo> 8351 needs a second review
<mup> PR snapd#8661 closed: configcore: add "service.console-conf.disable" config option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<pstolowski> mornings!
<mup> PR snapd#8748 opened: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>
<pstolowski> #8533 has been unblocked and needs 2nd review
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<mup> PR snapd#8749 opened: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
<zyga> jamesh: https://github.com/snapcore/snapd/pull/8748#pullrequestreview-418929307
<mup> PR #8748: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>
<pstolowski> mvo: thank you for 8749!
<pedronis> pstolowski: hi, could you review #8351 ? also do poke Sergio about your #8533
<mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> pedronis: yes
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8709#pullrequestreview-418926302
<mup> PR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
<pstolowski> zyga: thanks!
<jamesh> zyga: thanks.  I guess one difference is that the systemd in CentOS 7 supports user units, but they just don't run the instance.
<zyga> jamesh: what do you mean by supports?
<jamesh> whereas 14.04's systemd doesn't support them at all
<zyga> ah
<zyga> centos 7 is compiled without that IIRC
<zyga> (explicitly disabled)
<zyga> but those are shades of gray I suppose
<jamesh> zyga: as in "systemctl --user --global enable some-user-unit.service" succeeds on Centos 7
<zyga> Ah, that's weird, perhaps not fully disabled
<zyga> but officially disabled per RH design
<jamesh> zyga: I guess in some ways it is similar to Ubuntu Core, where it is technically possible to set up a user session but it is rarely done
<jamesh> (granted that will probably change in future)
<zyga> brb, small breakfast
<ogra> hmm ... is there a snapctl command that can tell me if seeding is done ?
<zyga> ogra: snapctl?
<zyga> or snap?
<ogra> zyga, snapctl (or the rest API)
<ogra> a customer wants to check the state from inside a snap
<ogra> i know he could loop over the changes output via the API until "Initialize device" is marked "done" but wanted to know if there is a more integrated and less hackish way
<zyga> I don't think this is supported
<zyga> let me look
<zyga> nope
<zyga> not supported
<ogra> ok, then looping over changes it is ...
<jamesh> ogra: the snapd.seeded.service systemd service runs "snap wait system seed.loaded".  If you've got access to the REST API, you could presumably do the same
<ogra> jamesh, hmm, how would i get that info from the api beyond looping over the changes ?
<ogra> i dont see any rest endpoint that could give me that info beyond the chnages output
<jamesh> ogra: check what /usr/bin/snap does?
<jamesh> ogra: looks like it's effectively doing "snap get system seed.loaded" every 500 milliseconds until it returns true
<ogra> oh, its aconfig option !!!
<ogra> thanks ! i totally forgot about that bit
<ogra> so there *is* a snapctl way in the end :)
<jamesh> snapctl will only give you your own config though, right?
<jamesh> not the system snap's configuration
<ogra> it queries "system" in that case
<ogra> well, a gadget can do that
<ogra> iirc
<jamesh> you'd know more about that than me :-)
<zyga> ogra: snap and snapctl have different APIs
<ogra> zyga, well, he has the API ... so using "GET /v2/snaps/[name]/conf" should be able to get him "system" configs, no ?
<zyga> what do you mean by "he has the API"
<jamesh> presumably he has snapd-control level access
<zyga> ah
<zyga> in that case then yes
<ogra> teh question comes from a customer with brand store
<ogra> right
<ogra> geez, we need customer docs for this 1
<ogra> !
 * ogra makes note
<ogra> i know some that *actually* loop over the changes output to find out :)
 * zyga debugs with -seed= again
<zyga> hey, reproduced
<zyga> ha
<zyga> funny
<zyga> let's write an invariant to find the culprit
<zyga> some test nukes some packages but doesn't reload systemd
<zyga> so the invariant will find systemd that complains abou "some units changed on disk"
<zyga> and this will lead us to the test breaking stuff
<zyga> eureka
<zyga> tests/upgrade/basic user unit snapd.session-agent.socket changed on disk
<zyga> in fact
<zyga> it keeps getting changed
<zyga> hmmmm
<zyga> I wonder why
<zyga> maybe we should not be agressively rewriting it
<zyga> but that's just noise
<zyga> there's another test that breaks dbus.socket
<zyga> fortunately not that many tests need fixes
<zyga> about half a dozen one liners
<zyga> mvo: ^ another lesson learned
<zyga> systemd units have state in memory and on disk
<zyga> and in memory state is the one that counts
<zyga> units are modified by tests and left stale in memory after "restoring" the disk state
<mvo> zyga: oh, woah, nice catch
<zyga> yeah, it manifested as a random failure that I managed to reproduce with -seed
<zyga> and ended up being a dbus.socket that's only in memory because the disk file is gone
<zyga> and cannot be activated (because no .service because also gone)
<zyga> so some test removes dbus.socket/service but the bigger find is that the in-memory state matters
<zyga> writing and running tests is useful but I think we could write a boot about integration testing now
<zyga> *book :)
<mup> PR snapd#8747 closed: tests: port snap-routine-portal-info to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8747>
<mborzecki> reading bug reports, it's amazing how people quickly jump to reinstalling the system whenever even a smallest issue pops up
<zyga> mborzecki: do you know windows made that super easy?
<zyga> maybe it's something they learned and apply to other OSes
<mborzecki> zyga: seriously? my experience with windows reinstall was that it was a huge waste of time
<zyga> mborzecki: why?
<mborzecki> though it did fix issues there ;)
<zyga> mborzecki: btw, windows 10 reinstall is super easy
<zyga> it's literally 4 clicks from the start menu
<zyga> and the experience is quite nice
<mborzecki> haven't reinstalled 10 yet, maybe i'm not using it enough
<zyga> (can preserve apps or just data, entirely unattended)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8693/files has some spurious changes
<mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
<zyga> are they relevant or can we nuke them?
<mborzecki> zyga: yeah, noticed them after i pushed the changes, don't think it's worth another spread run though
<zyga> ok
<zyga> I resolved a conflict
<zyga> but didn't notice this until after
<mborzecki> hah ;)
<zyga> one thing that I miss on !windows is family management
<mborzecki> once it's green, we should land it
<zyga> yeah
<zyga> control over time, app access and even browser page access
<mborzecki> haha i talked with mvo about a killed linux app that could do that
<zyga> I really wish we had something comparable
<mborzecki> which would be great, and we probably have the right technology to do it already
<zyga> yeah but it's either really well done and useful or it's not useful at all :/
<zyga> loopholes => not useful, poor UX => not useful, not localized => not usefl
<zyga> though I bet it would be good to have something and work from there
<zyga> I think one major problem is that it requires central authority and accounts to be easy to use
<mborzecki> well, we don't have anything there yet, so ;)
<zyga> yeah
<mborzecki> pedronis: added some comments under https://github.com/snapcore/snapd/pull/8569
<mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<zyga> even limiting time is hard
<zyga> gdm would have to cooperate
<mborzecki> pedronis: is that the last PR in that series?
<pedronis> mborzecki: I saw, thx
 * zyga needs to manage browser tabs, brb
<pedronis> mborzecki: it's the main one, but no, as the description says there will be a couple more follow ups, one is almost ready, but is not proposed yet
<mborzecki> ok
<pstolowski> zyga: can you take another look at #8639?
<mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
<zyga> ha
<zyga> sure
<zyga> I just looked at another branch and though that was the same one :)
<mborzecki> heh, something weird about go compiler
<zyga> hmm?
<mborzecki> took #8749, dropped the default: case like so https://paste.ubuntu.com/p/NJSFCQkF8N/, then compiler complains about ./services.go:90:1: missing return at end of function
<mup> PR #8749: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
<mborzecki> by looking at the code i see that there always is a return in the switch cases there
<mup> PR core20#69 opened: hooks: remove redundancy from timezone settings <Created by mvo5> <https://github.com/snapcore/core20/pull/69>
<mborzecki> heh this is weird https://play.golang.org/p/-Bxl-hPNAeu
<mvo> mborzecki: heh, this looks familiar
<zyga> mborzecki: go doesn't do proper analysis
<mborzecki> mvo: yup, the pr you opened
<zyga> erring on the "compile quickly"
<mvo> mborzecki: I was surprised as well
<zyga> it sucks but it's a known issue
<mborzecki> mvo: wonder whether the compiler would even determine that panic code is unreachable
<mvo> mborzecki: if it can it should be easy to fix the bug :)
<mvo> mborzecki: I mean, the bug/issue that this requires a return still
<mborzecki> famous last words :P
<mvo> lol
<mvo> actually rofl
<mvo> yeah, I will not try or I get sucked into a black hole
<zyga> mborzecki: I wonder if: if false { println("DUPA") }
<zyga> mborzecki: compiles in a way where DUPA is gone from the binary
<mborzecki> haha if works https://play.golang.org/p/j2VSn1xex7K
<mvo> mborzecki: woah, that's "funny
<mvo> "
<zyga> it's weird especially considering that go's switch/case degenerates to if-then-else tree
<mup> PR snapd#8351 closed: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<mborzecki> funny that it's quite happy when there's a default case
<mborzecki> so bools in a switch are tri-state, true, false, something-in-between
<pstolowski> pedronis: is #8569 ready to be reviewed?
<mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<pstolowski> mborzecki: that's peculiar
<mup> PR core20#69 closed: hooks: remove redundancy from timezone settings <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/69>
<zyga> mvo: thank you for that test btw
<zyga> mvo: I wonder if we could integrate some other things there
<zyga> like timedatectl
<mborzecki> time to file a bug in go
<zyga> setting timezone
<zyga> setting NTP
<zyga> all super basic stuff
<zyga> but it was broken on more than one occasion
<mup> PR snapd#8750 opened: tests: improve oom-vitality tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8750>
<mvo> zyga: you mean 69?
<zyga> mvo: you proposed something relevant yesterday
<zyga> to snapd
<mvo> zyga: aha, yes - we can, it's strange, partly this is covered by interface tests
<mvo> zyga: but I suspect it's much cleaner to have a dedicated test
<zyga> yeah but I think there's a difference, those tools often use DBus APIs
<zyga> and perhaps there's some factor where a tool modifies something directly vs issues a call
<zyga> so good to have a dedicated basic-management test like that
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8351#discussion_r431028861
<mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<mvo> zyga: cool, thanks, I will work on the system-settings a bit more I guess
<zyga> I actually wonder
<zyga> in your core system deployments
<zyga> did you set things like hostname, timezone and ntp manually?
 * zyga breaks focus to finish some reviews
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8639#pullrequestreview-419079982
<mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
 * zyga found the broken test
<mup> PR core20#70 opened: Fix localtime <Created by xnox> <https://github.com/snapcore/core20/pull/70>
<mup> PR core20#71 opened: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <https://github.com/snapcore/core20/pull/71>
<zyga> brb, coffee
<zyga> it's hard to use the coffee machine
<zyga> when one kid is constantly remote-schooling in the kitchen :D
<pedronis> pstolowski: zyga: I asked a new question in #8691
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<pedronis> pstolowski:  #8569, yes
<mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<pedronis> there are some open questions and tweaks but in itself is good to go
<zyga> pedronis: looking
<zyga> replied
<zyga> gah, I wish spread used mosh instead of ssh
<zyga> mosh is so nice for roaming
<mup> PR core18#154 opened: Test timezone contents and symlink <Created by xnox> <https://github.com/snapcore/core18/pull/154>
<mup> PR core20#71 closed: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core20/pull/71>
<zyga> pedronis: testing.global.session testing.netgate testing.global.invariant
<zyga> pedronis: how do those sound to you?
<pedronis> zyga: I'm thinking, I'm actually starting to think that for most of them the problem is a bit self-inflicted
<zyga> pedronis: because they have before/after parts?
 * zyga probably doesn't follow
<pedronis> no, because it's not clear why we need most of them on PATH, they aren't used enough to justify that and the naming problem it creates
<zyga> pedronis: they are on PATH so that they do not require sourcing via $TESTSLIB
<zyga> in the past we had functions that were bad for other reasons
<pedronis> what it has to do with sourcing
<zyga> but required sourcing and this was tedious
<zyga> ah, because they were functions and not on path, you had to get them somehow
<pedronis> these are not functions
<zyga> right
<pedronis> also as I said, the tedious argument doesn't apply to many of them
<pedronis> they are not used enough to make it a good reason
<zyga> sure but some are super common, are you suggesting to drop them from path/
<pstolowski> i think part of the reason they are in PATH is to make them usable to debug tests easily when in spread shell
<zyga> oh, that's useful as well
 * zyga didn't think about that
<zyga> you can paste stuff from a test and it mostly works
<zyga> (depending on how much you paste)
<pedronis> pstolowski: again, I don't thinkt that argument applies equally
<pedronis> to all of them
<zyga> I don't see a problem with them being on path
<zyga> testing.foo is a good solution if we need to have unique prefix
<pstolowski> yes. i'm not even too concerned about testing.not tbh, it's just a prefix
<pedronis> at some we can't start to explain that we did something to avoid tedious, and then circle back there, testing.negate is fairly tedious
<pedronis> tbh
<zyga> pedronis: not is not tedious :)
<pedronis> exactly
<zyga> pedronis: but importing something or $TESTSLIB/tools/not is also a bit tedious
<zyga> but not might be a special case
<pedronis> my point is that I don't trying to find a solution that works for all of them
<pedronis> is a goal
<zyga> as it's super short and small and frankly not related to snapd
<zyga> I think handling session-tool and retry-tool should be the goal
<zyga> as those are used fairly often
<zyga> the rest can be another class that doesn't need the same solution
<pedronis> also shellcheck is not helping here
<zyga> in which sense?
<pedronis> that it forces quotes, I understand where it comes from
<pedronis> but sometimes you know what is in your env var
<zyga> one more idea is to multiplex everything through one tool that is on path
<zyga> snapd-testing ...
<zyga> snapd-test-helper ... or whatever we name it
<pedronis> that might be part of the solution
<zyga> then it's one item on path and pretty easy to even handle migrations
<pstolowski> yes that's an interesting idea
<zyga> (assuming we migrated to the tool in the first place)
<zyga> we could even call it
<zyga> "the-tool"
<zyga> except that's for core 20
<pedronis> no
<zyga> I was totally kidding :)
<zyga> testctl sounds like systemd thing
<zyga> though "testctl foo" could invoke "testctl-$foo" so we'd have a simple way to use various languages (like we do now)
<zyga> so I kind of like that more and more
<zyga> and the rest would not need to be on path eventually
 * zyga is surprised
<zyga> -.mount unit changed on disk https://www.irccloud.com/pastebin/oVaMhye7/
<zyga> how is this even possible?!?
<zyga> mborzecki: ^ any ideas?
<zyga> ah, we modify fstab
<zyga> fun
<zyga> fixed now
<mborzecki> zyga: yup, the test touches fstab
<mborzecki> and -.mount is autogenerated
<zyga> yeah
<zyga> another one from another test
<zyga> rtkit-daemon.service changed on disk https://www.irccloud.com/pastebin/JCg4YEkc/
<zyga> the test installs/removes that
<zyga> pedronis: do you have a feeling on what to do with test names then?
<zyga> pedronis: which way do we go
<pedronis> not yet
<zyga> s/test names/test tool names/
<zyga> ok
<zyga> I'm happy to apply the change, when you make up your mind
<zyga> I think we could also have a two-tier system, where some rarely used tools can have different properties
<zyga> as some are indeed used a few times in the entire project
<zyga> cachio: is the ubuntu 16.04-32 (note -32) image using EFI?
<cachio> zyga, it supports uefi, not really sure if it is using it, I suppose that yes
<zyga> ok
<zyga> I think it boots in legacy mode
<zyga> but that's fine
<zyga> I was just curious
<pedronis> zyga: when do you want to discuss refresh awareness, tomorrow morning after the desktop meeting?
<cachio> zyga, we are not enabling any security feature, so by default iirc the systems use the legacy mode
<zyga> pedronis: that sounds great
<zyga> pedronis: I will push all my changes by then
<zyga> pedronis: I took a small detour to fix various random issues I ran into but test coverage is close to being good now and I still have a few more patches to send
<cachio> zyga, but it is managed by the gce hypervisor and there is not details in the docs about  it
<zyga> cachio: ok, I guess it's uncommon to use 32 bit systems so maybe they don't boot them with uefi
<cachio> zyga, just few line explaining the high level
<zyga> cachio: I only noticed because boot/efi was missing
<pstolowski> cachio: hi! could you take a look at https://github.com/snapcore/snapd/pull/8533 ? also updated #8710
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<cachio> pstolowski, sure
<zyga> pstolowski: do you need any reviews for the preseeding changes?
<jdstrand> mvo: hey, fyi I approved PR 8706
<mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
<zyga> jdstrand: \o/
<jdstrand> mvo: I looked for another PR for it against 2.45.1 but didn't see it
<zyga> jdstrand: if you are doing reviews, could you look at the /usr/share/doc interface again? It has +2 and just needs your final ack
<zyga> nothing changed wrt permissions
<jdstrand> zyga: heh, yes. that was the next one
<zyga> super!
<zyga> fedora 32 PR is almost entirely there, just one test queued and it will be entirely green
<zyga> bringing average green levels up by a large margin
<cachio> pstolowski, I left few comments
<zyga> brb
<zyga> re
<cachio> mvo, hey, https://paste.ubuntu.com/p/hFFjC3Nwj3/
<cachio> I see this error to build
<cachio> mvo, is any dep missing?
<mup> PR core18#154 closed: Test timezone contents and symlink <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core18/pull/154>
<mup> PR core20#70 closed: Fix localtime <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core20/pull/70>
<mvo> cachio: hm, is sbuild installed ?
<cachio> mvo, yes
<pstolowski> cachio: ty
<cachio> pstolowski, reviewing the other one
<zyga> mvo: can you please force merge https://github.com/snapcore/snapd/pull/8693 - it failed on a snap run --strace timeout that's random and known
<mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
<zyga> and I'd like to avoid an hour of testing xenial again, it's not related to the PR
<mup> PR snapd#8693 closed: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8693>
<zyga> \o/
<cachio> yesss
<zyga> thanks!
<mup> PR snapd#8751 opened: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8751>
<mup> PR snapd#8752 opened: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8752>
<zyga> standup!
<mvo> cachio: please try installing "schroot"
<zyga> not sure how you work but using a pair of laptops to run tests in one checkout while another is busy editing works for me
<roadmr> I use a hand-cranked OLPC to ssh into an old mainframe in the basement I got from ebay
<ogra> only works if you have kids to operate the crank, no ?
 * cmatsuoka looks in ebay for a new basement
<zyga> haha
<mup> PR snapd#8753 opened: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8753>
<zyga> cmatsuoka: buy two
<zyga> ogra: do you have any music equipment?
<ogra> zyga, do you mean soundcards (a few) or instruments (none) ?
<zyga> midi synth
<roadmr> ogra: right, so I have the kid crank it for a while, then work a while, then cranking break... and so on
<ogra> nah ... but i guess one of the soundcards i have could do midi stuff
<cmatsuoka> zyga: I'm considering a korg wavestate, but it's not available here yet
<zyga> cmatsuoka: I'd like to find either an MT32 for some dos games or SC-D70 for some other dos games
<mup> PR snapd#8750 closed: tests: improve oom-vitality tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8750>
<cmatsuoka> zyga: the canvas sounds much better
<zyga> it's also a bit more modern, has pc style AC input and even usb port
<zyga> but only available in japan
<zyga> so.... bummer
<cmatsuoka> zyga: a friend of mine had both in the 90s, but I doubt they're still in working conditions
<zyga> there are some on ebay, they seem to be in great shape
<zyga> the only thing that may need replacement is a CR32 battery
<cmatsuoka> I mean, the canvas was the SC-55 I think
<pstolowski> cachio: updated #8533
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<zyga> cmatsuoka: ah, that's a good unit as well
<zyga> I guess anything after SC-55 is good for games that used general midi, not the preceeding mt32 de-facto standard
<ogra> my biggest soundcard i have is a Xonar DX virtuoso 100 ...
<mup> PR snapd#8742 closed: snap-mgmt: perform cleanup of user services (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8742>
<ogra> but my focus was more on high bitrate playback and surround for gaming
<ogra> less on producing music
<cmatsuoka> zyga: I specifically remember that Sierra's Dagger of Amon Ra sounded so much better in it compared to Adlib/Sound Blaster, except for the archeologist song which only played in the Sound Blaster
<zyga> huh? :)
<zyga> I find it fascinating that each game was composed for a particular hardware stack as all the midi synthesizers were not really backwards compatible
<cmatsuoka> zyga: https://en.wikipedia.org/wiki/The_Dagger_of_Amon_Ra
<zyga> so you may need a few to have the correct unit for each game
<zyga> I never played it, looks interesting (all sierra games are)
<zyga> https://www.gog.com/game/the_dagger_of_amon_ra :)
<cmatsuoka> it looks reasonably priced :)
<zyga> for me the price is ~3 euro
<cmatsuoka> listed as 3.39 euro here
<zyga> yep
<mup> PR snapd#8667 closed: interfaces/fwupd: allow bind mount to /boot on core <:secret: Needs security review> <Security-High> <Created by woodrow-shen> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8667>
<zyga> you can easily extract it with innoextract and play on any system
<ogra> there is also https://snapcraft.io/gog-galaxy-wine
<zyga> ogra: nah, too many layers: )
<ogra> heh
<zyga> I'm somewhat sceptical about snaps like that
<zyga> would be a totally different story if it was endorsed by gog
<ogra> well, make diddledan talk them into endorsing it ð
<zyga> I think that won't be easy
<zyga> gog is a huge company now
<zyga> I doublt they would +1 it
<zyga> *doubt
<ogra> why ? it is spreading their stuff
<zyga> quality and support
 * ogra taps foot ... why are LP builders so slow today ...
<ogra> i need an s390x or ppc64el ... they are always first while the other arches still "pending build"
<roadmr> mainframe in the basement ;)
<ogra> ð
<zyga> brb for lunch
<mup> PR snapd#8709 closed: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8709>
<jdstrand> mvo, pedronis, zyga: hey, so now that the security team is ramping up the people that can help (eg, amurray and emitorino, though currently things ultimately go through me still), I think it would be better to use the 'Needs security review' tag going forward. In this manner, a member of our team can go to
<jdstrand> https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%22
<zyga> +1
<zyga> sounds great to me
<pedronis> jdstrand: works for me
<jdstrand> mvo, pedronis: and see what is what. I'm not sure why that tag as a non-ascii symbol in it...
<jdstrand> mvo, pedronis: if people forget and just add me, I'll add that tag
<jdstrand> so we can all work together on it
 * jdstrand does that now
<jdstrand> ijohnson: you probably are interested in that too ^
 * mvo is in a meeting
<jdstrand> emitorino: fyi, https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%22 (though you don't need to do anything with that now)
<emitorino> ack jdstrand
<mvo> jdstrand: I can remove the strange non-ascii thing in there if you want
<pedronis> jdstrand: there are some PRs that are changes request by you, don't know if you want the tag on those, or you will track them yourself given you started the conversations
<jdstrand> mvo:
<jdstrand> mvo: please if you don't mind :)
<jdstrand> pedronis: I will continue to track those myself
<jdstrand> I think it is on the person to track things they requested changes on
<pedronis> jdstrand: ok
<jdstrand> I need to step away for a bit, but will read backscroll
<mvo> jdstrand: removed
<mvo> zyga: do you mind if I remove the per-user mount ns tag?
<zyga> not at all
<zyga> let's nuke it
<jdstrand> emitorino: here is a better link: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+security+review%22+ (cc amurray)
<jdstrand> (that will still show open ones where we've commented)
<emitorino> jdstrand, yeah figured out the label, thanks anyway!
<jdstrand> emitorino: you might want to peruse what I've commented on today for questions for tomorrow, but only if you have time
<emitorino> sure thing jdstrand, thanks!
<mup> PR snapd#8754 opened: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8754>
<pedronis> jdstrand: emitorino: we will also still use Security-High for things that have some urgence, we'll give things both tags I suppose (cc mvo)
<mvo> +1
<mvo> yeah
<mvo> mostly added the other one to avoid accidents
<mvo> where stuff gets merged too early
<mvo> (as hapend with the serial port fix)
<pedronis> jdstrand: emitorino: also as usual things that have a milestone are usually higher priorities than ones that don't
<zyga> mvo: we have green ticks on github now :)
<mvo> zyga: we do - it's magic!
<emitorino> ack pedronis
<niemeyer> issue #123
<mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
<niemeyer> mup_: You there?
<mup_> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
<niemeyer> mup_: issue #123
<mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
<mup_> niemeyer: PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
<niemeyer> It's not overhearing..
<niemeyer> Ah, I know why
<niemeyer> issue #123
<mup_> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
<mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
<niemeyer> issue #200
<mup_> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
<mup> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
<niemeyer> issue #8558
<mup_> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<niemeyer> Sorry, will stop now :)
<pedronis> :)
<mup> PR snapd#8578 closed: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
<mup_> PR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
<mup> PR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> niemeyer: while you are looking, mup had a bug where it would give a link to "issue" vs "issues" (or the other way around)
<akik> kernel/os snaps? weren't snaps for application containment?
<zyga> niemeyer: not sure if you noticed or if you fixed that now
<niemeyer> zyga: Should be fixed on the new instance
<zyga> ah, superb :)
<niemeyer> There are several other changes as well, big and small
<zyga> akik: kernel snaps are used on core devices where snapd manages the entire OS
<mvo> yeah, nice!
<mvo> thanks niemeyer !
<niemeyer> mvo: np, sorry it took a while
<akik> zyga: core devices?
<zyga> akik: there are other snap types used there, that are not seen on regular (non-iot) systems
<zyga> akik: ubuntu core is a full OS for IOT systems
<akik> zyga: is that only for ubuntu core then?
<zyga> akik: we use "core" to describe them, vs "classic" for all other systems with other package managers and typical behavior
<ogra> akik, snap is a fully fledged package format, you can package services (daemons), cli apps, kernels, bootloaders and desktop apps
<zyga> akik: kernel snaps? yes, they are only used for core devices
<zyga> akik: a core device has at minimum, a kernel snap, a base snap used for booting (e.g. core20) and a gadget snap
<zyga> akik: and any number of application snaps
<ogra> ubuntu core is completely built from snap packages, no apt, deb, dfn, rpm support on them
<zyga> jdstrand: will review-tools need changes to know about new interfaces? (like system-packages-doc) or is that automatic?
<zyga> akik: you can use it on a raspberry pi, for example
<zyga> akik: if you are not familiar that is a great way to learn
<akik> zyga: i'm a classic kinda guy
<ogra> you dont know what you'Re missing then :)
<akik> i don't want to see the linux landscape fragment any more
<ogra> fragment ?
<ogra> i doubt anything like core exists anywhere else, not sure what would be fragmented here
<akik> kernel/libs/desktop environments/application containers
<akik> that's what i meant with fragmentation
<akik> somebody might not want to run snaps if they are slower to start
 * zyga really goes for lunch
<zyga> akik: it's temporary, we'll get it fixed
<akik> heh
<akik> doubt it
<akik> oh that slow start?
<akik> sorry i understood wrong
<zyga> ?
<akik> i thought you meant fixing the fragmentation
<ogra> well, thats not up to us
<ogra> when we started doing snaps in 2014 nothing like this existed
<ogra> you cant blame us for innovating really
<zyga> I'm unsure what kind of fragmentation you are talking about
<zyga> that different people do different things?
<akik> kernel/libs/desktop environments/application containers
<akik> some company might package their application only to some certain format
<zyga> what about them
<akik> that's fragmentation
<zyga> I still don't get it
<ogra> akik, but thats not our fault !
<zyga> that desktop environments exists?
<zyga> *exist
<zyga> or that libraries exist?
<zyga> what is fragmented?
<ogra> probably kernels ð
 * zyga would like to know what akik meant
<akik> that some application might not run if the environment that is available does not match what the application needs
<zyga> akik: can you give me an example please?
<akik> vendor a packages the app in a snap only. the user is not able to run the snap
<ogra> then we need to fix that for the user
<ogra> and he should tell us ... file a bug etc
<ogra> i dont see what this has to do with fragmentation though
<akik> different distros have different kernels and library versions
<ogra> yes, and snapd takes that into account for most of them
<akik> yes this was just about fragmentation
<ogra> take a look at the distro list over therehttps://snapcraft.io/zoom-client
<ogra>  bah
<ogra> https://snapcraft.io/zoom-client
<akik> fragmentation regarding application containers means that there are snap, flatpak, appimage
<ogra> does allowing all of these different distros to use the same app really look like fragmentation ?
<akik> ogra: i didn't mean snap when talking about fragmentation
<ogra> note that these 55 different distros are not all of the,
<ogra> them
<akik> i meant these -> kernel/libs/desktop environments/application containers
<akik> the 3 first ones
<ogra> well, you wont use a kernel or gadget snap outside of an ubuntu core system
<ogra> snaps have a builtin self-test and roll-back mechanism, they guarantee you that your kernel automatically goes back to the former version if an upgrade fails, your new version causes an OOPS etc etc ... this is very unique but utterly needed in IoT, embedded and industrial
<ogra> if you'D use a deb you would have to send out a technician to your 3G tower in the woods to fix the device that hung with a kernel OOPS
<ogra> kernl snaps solve that elegantly
<ogra> there is no "fragmentation" here it is innovation ð
<ogra> and if you mean missing kernel security features that cause distros to not adopt snapd to have snap support ... well, thats on them ... there isnt much we can do about, if you look at the zoom-client link i gave you above, there are 55 different distros listed that *are* able to install and use it
<ogra> if there are any that can not people like zyga and his team will happily help the distro devs to make it work
<ogra> actually ... looking at that distro list makes me wonder ... what the heck is "windowsfx 10"
<pedronis> zyga: the new interface will need to be documented
<zyga> re
<zyga> pedronis: good point, I'll do it now
<zyga> ackk: note that snap isolates you from everything but kernel and services and their IPC api
<zyga> akik: ^
<zyga> sorry ack
<zyga> tab eager complete ;)
<ogra> use hexchat !
<zyga> akik: so no matter what libs you are using, you should be able to use the snap
<zyga> akik: if you think this is fragmentation, package an app for 4-5 distributions
<zyga> then after a month, do an update
<zyga> that's fragmentation
<akik> yes that's what i meant
<zyga> akik: I see now
<zyga> "akik> ogra: i didn't mean snap when talking about fragmentation"
<ogra> well, hard to avoid ...
<ogra> different distros (need to) stabilize on top of different releases of software ...
<mup> PR snapcraft#3145 closed: cli: migrate upload and release to new channel-map <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3145>
<ogra> often driven by the distros purpose (my distro only wants to use LTS upstream kernels because enterprises use it ... your distro being a desktop focused thing probably wants the very latest cool kernel graphics improvements so you pick the latest tip kernel)
<ogra> i remember that when we started in 2004 there were not even upstream release schedules for most things ... Xorg, kernel, gnome ... all released on their own schedules and things were massively varying across distros ... that has changed over the years
<ogra> so it got a lot better already ...
 * zyga ran back to the office
<zyga> my kids are behaving like crazy today
<zyga> degville: hi, I sketched a small document for the new interface: https://forum.snapcraft.io/t/the-system-packages-doc-interface/17788
<zyga> advise and comments are appreciated
<mup> PR snapd#8755 opened: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
 * cachio lunch
 * zyga cachio: https://github.com/snapcore/snapd/pull/8755#pullrequestreview-419410456 (first comment is the one I'm interested in)
<mup> PR #8755: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
<jdstrand> zyga: yes, the review-tools need a change (and snappy-debug). it is already on my todo
<jdstrand> cc emitorino ^
<zyga> jdstrand: ack
<jdstrand> pedronis: yep
<jdstrand> pedronis: (security high and milestone)
<pedronis> jdstrand: ack
<jdstrand> it would be nice if the milestone was more prominent, but easy to see once know what to look for
<jdstrand> fyi, there are no milestoned PRs waiting on us now
<jdstrand> I'm continuing to go through the list though
<mup> PR snapcraft#3146 closed: build providers: snap sw to channels if injecting <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3146>
<mup> PR snapd#8756 opened: tests: skip interfaces-openvswitch for centos 8 in nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8756>
<mup> PR snapd#8691 closed: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<mup> PR snapd#8691 opened: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
 * cachio afk
 * zyga EODs
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8691#pullrequestreview-419542230
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
 * zyga really EODs :)
<mup> PR snapd#8533 closed: image, tests: core18 early config <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<jdstrand> ijohnson (cc emitorino): fyi, https://forum.snapcraft.io/t/nvme-block-devices-support/17736/3
<jdstrand> ijohnson: I'm also reviewing the PR and will comment there as well
<ijohnson> Nice thanks jdstrand also FYI I'm off today/tomorrow
 * ijohnson will remember to silence IRC notifications next time :-) 
<jdstrand> ijohnson: enjoy your time off! you now have a short story to read :)
<jdstrand> ijohnson: not sure how much you like reading short stories on deep technical debugging :P
<jdstrand> ijohnson: sorry for the interuption
<diddledan> I think we should ping ijohnson, too ;-p
<mup> PR snapd#8751 closed: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8751>
<mup> PR snapd#8752 closed: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8752>
<mup> PR snapd#8754 closed: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8754>
#snappy 2020-05-28
<mborzecki> morning
<zyga> Hey
<mborzecki> zyga: mvo: hey
<mborzecki> zyga: how's your dog?
<mvo> good morning mborzecki and zyga
<mvo> zyga: oh? is your dog not well?
<mup> PR snapd#8753 closed: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
<mvo> zyga: 8744 has a potentially interessting log for you
<mvo> zyga: in the ubuntu-14.04 logs
<zyga> Hey
<zyga> Not sept much
<zyga> Dog hurt but alive
<zyga> Will go to vet soon
<mvo> zyga: uh, what happend
<mvo> ?
<zyga> Dog ran under bike, got hurt, ran way and got lost
<zyga> One of those bikers that must go super fast at all times
<zyga> We went out of an alley l, it was dark
<zyga> We looked for him for an hour or more
<zyga> Wound on leg, lost tooth, minor wounds on feet as well
<zyga> Internal state uncertain but likely no bleeding
<mvo> zyga: uh, ok - good luck!
<mup> PR snapd#8757 opened: tests: update statx test to run on all LTS releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8757>
<mup> PR snapd#8758 opened: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8758>
<zyga> in the office
<zyga> mvo: looking
<zyga> hmm!
<zyga> mvo: I downloaded logs and restarted
<zyga> I will look at in detail after the morning calls
<zyga> at first sight I don't know
<mvo> zyga: sure
<mvo> zyga: no problem
<mborzecki> hm maybe we should grow an `xdg` apckage with a desktop file parser inside
<mborzecki> zyga: do i remember correctly that https://github.com/snapcore/snapd/pull/8699 is just a start and eventually we'd like to launch non snap apps too?
<mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<mvo> mborzecki: +1 for xdg
<zyga> mborzecki: xdgutil probably
<pstolowski> i landed core18 early config yesterday, this unblocks #8567
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<pstolowski> mvo ^
<mup> PR snapd#8759 opened: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
<pedronis> zyga: hi, ^ , that's something you considered I think
<zyga> yep, I noticed
<zyga> my dream there would be so that that suite could be tested without building snapd but that's a longer piece of work
<zyga> I'll review it later today for sure
<zyga> I reviewed dbus activation https://github.com/snapcore/snapd/pull/6258#pullrequestreview-419847153
<mup> PR #6258: interfaces: support D-Bus activation <:birthday:> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6258>
<pstolowski> zyga: could you take another look at #8640, i've addressed your comment
<mup> PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
<zyga> pstolowski: after some calls, unles urgent
<pstolowski> zyga: it's not, np
<zyga> there's a new raspberry pi with 8GB ram now
<zyga> ogra: ^ do you have it?
<ogra> lol
<ogra> i'm not *that* fast
<zyga> $$$
<zyga> bought
<ogra> i'll have fabrica appliance images for it though !
<ogra> (https://snapcraft.io/fabrica build.snapcraft.io for your home ;) )
<zyga> ooooooh
<zyga> nice
<ogra> you nered to see it ... i only did a shappy prototype in pylxd ... then james jeudason came  ... now it beats build.s.io !
<ogra> *need
<ogra> its all go now
<ogra> (and it supports non GH trees as long as they are cloneable)
<zyga> man at 8GB that's pretty much the same as my thinkpad
<zyga> I wonder how it behaves as a desktop
<ogra> well, the SD card is stilla bottleneck
<ogra> but it is easy enough to just use the SD to jumpstart the boot and have writable on USB
<mborzecki> mvo: pushed a little patch to https://github.com/snapcore/snapd/pull/8749
<mup> PR #8749: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
<mvo> mborzecki: thank you!
<mborzecki> zyga: #8758 failed on 20.04 in a weird way, something you looked into before?
<mup> PR #8758: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8758>
<mborzecki> there;s this in the logs: `2020-05-28T07:29:05.7615493Z May 28 07:29:04 may280655-963480 snapd[91768]: May 28 07:28:58 may280655-963480 systemd[1308]: snapd.session-agent.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.`
<ogra> zyga, FYI ... ordered ... :)
<zyga> re
<zyga> small break to check on the dog and then reviews
<zyga> mborzecki: nice
<zyga> mborzecki: I think I have something that fixes that
<zyga> I think this is related
<zyga> https://github.com/snapcore/snapd/pull/8753
<mup> PR #8753: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
<zyga> but it landed already
<zyga> just not sure if it's present in the PRs where things failed
<zyga> and as I said yesterday
<zyga> I need to (or we need to) look at the code that writes snapd.session-agent.{socket,service}
<zyga> as I suspect it is buggy
<zyga> and rewrites the unit without real need to
<zyga> but fascinating that sockets can be broken this way
<zyga> brb
<mborzecki> abeato: hi, i've updated your hugepages-control PR, please take a look whether the changes are fine https://github.com/snapcore/snapd/pull/8271
<mup> PR #8271: interfaces: add hugepages-control <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
<pedronis> pstolowski: hi, I updated the proposal in #8691
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<zyga> re
<diddledan> morning
<zyga> hey diddledan
<zyga> nice wave of snaps all the time
<zyga> thanks for making that website :)
<diddledan> :-)
<diddledan> really happy people are finding it useful :-)
<pstolowski> pedronis: thanks, will take a look
<zyga> ogra: did yo notice that pi foundation also released a 64 bit raspbian OS?
<ogra> they did quite a while ago but only as developer preview
<ogra> stating explicitly that it isnt supported
<ogra> did they change that ?
<mup> PR snapd#8760 opened: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8760>
<mborzecki> zyga: is there already some code that launches user processes via systemd run --user ?
<mborzecki> (in the tree)
<zyga> In tests or not tests?
<mborzecki> non-tests
<zyga> I do use it in tests
<zyga> Otherwise no
<zyga> We cannot rely on that
<mborzecki> zyga: i'm asking in the context of https://github.com/snapcore/snapd/pull/8699 we start he child ourselves and need to let it go and be reparented to whatever is the right subreaper, but userd is long running
<mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<mborzecki> and it kinda sucks to have to do it through sh -c
<zyga> Iâll review it
<mborzecki> if we only had a common way to start whatever is in the desktop files instead of calling the gio/gtk/kio/random helper
<mup> PR snapd#8756 closed: tests: skip interfaces-openvswitch for centos 8 in nightly suite <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8756>
<Saviq> jdstrand: hey, when you have a while, Multipass 2105 needs a "lxd" interface installation assertion (not auto-connect at this time), thanks!
<cachio> zyga, hey
<cachio> zyga, I created a new pr to test spread https://github.com/sergiocazzolato/spread/pull/1
<mup> PR sergiocazzolato/spread#1: Use GitHub actions <Created by sergiocazzolato> <https://github.com/sergiocazzolato/spread/pull/1>
<cachio> do you think we can run it with the rest of the snapd tests?
<diddledan> zyga, have you done much work on opencl enablement? I'm looking at getting fakecam to support it but the opencv library complains that `Error on line 2205 (ocl.cpp): CL_DEVICE_SVM_CAPABILITIES via clGetDeviceInfo failed: -30`
<diddledan> there are no denials in the logs either. it's nicely silent.
<diddledan> I've got an strace if it will help
<diddledan> strace: https://cloud.bowlhat.net/index.php/s/pMYqG4RpFrQz7qt
<ogra> while we'Re fixing such stuff, intel fixing VAAPI support would be awesome too ð
<ogra> *fixing intel ...
 * diddledan cuddles ogra
<ogra> ð
<ogra> diddledan, did you see my ping from a few days ago in #snapcraft ?
<diddledan> about the desktop launcher and zoom?
<ogra> i tried to use your ld cache stuff in zoom ...
<ogra> yeah
<ogra> how do you make it not fail ??
<diddledan> yeah, donno what's up with that.. I don't really do anything particularly special, just having it in the chain
<ogra> the hooks run as root after all ... it falls flat on its face for me
<ogra> i use the old desktop launcher though ... not the gnome extension ... perhaps they behave different
<diddledan> maybe. although I use the gtk2 one with gimp so probably not that
<zyga> I will be around but I need about 40 minutes still
<diddledan> oh wait, no I don't use the gtk2 one, I hack the one from the extension
<pstolowski> cachio: hi, can you take another look at #8710?
<mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<cachio> pstolowski, sure
<diddledan> the patch I apply doesn't change anything particularly related to failing to run as root, though: https://github.com/diddlesnaps/gimp/blob/master/patches/desktop-launch.patch
<mup> PR snapcraft#3128 closed: extensions: pre/append_dir: support rpath tokens by not using eval <bug> <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3128>
<diddledan> aaah, maybe it's not compatible with the qt5 desktop helper. I'll do some checking
<diddledan> I know I've had success with the GTK ones
<diddledan> oh. I think it's an opensuse bug
<diddledan> related, at least.
<diddledan> On Ubuntu, snapd's root environment for the hooks has `$HOME` set to `/root`, but possibly on opensuse it doesn't set `$HOME` so all the paths using the variable expand to `/foo` instead of `/root/foo`.
<diddledan> maybe we need mborzecki(are they the right name? I get lost with all the people :-p) to have a poke?
<diddledan> I forget who is involved with suse
<diddledan> at least I think it's `/root` it might be `/root/snap/$SNAPNAME/current` which would make more sense
<cachio> pstolowski, minor comment
<cachio> the rest it ok
<diddledan> either that, or their `$XDG_CACHE_HOME` is not set when running the hooks
<diddledan> oh no, not XDG_CACHE_HOME, that's explicitly set to $SNAP_USER_COMMON/.cache by the launch script
<pedronis> pstolowski: there's something off with the dir in #8567, but maybe reorging the code a bit can solve that
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<pstolowski> pedronis: hmm, i must have misunderstood the flow
<pedronis> pstolowski: you should look at the cloud-init tests there and you'll see the rootdir involved is a bit different than what you picked
<pedronis> pstolowski: as I said we should do something with the code org that makes this more easy to get right
<pstolowski> i need to have a spread test, i think things are stable now to pick it up again
<pedronis> pstolowski: also look at go doc InstallHostWritableDir in boot , it would be good to know if it makes sense
<pedronis> pstolowski: tbh your PR is old enough that the code in install was buggy and it was fixed since
<pedronis> possibly
<pstolowski> i see
<pedronis> pstolowski: but yes, definitely +1 on the spread test
<mborzecki> diddledan: zyga does the opensuse packaging, but that sounds strange, why would the hook store anything un root's home?
<diddledan> the hook uses the desktop-helper script to set up the environment to be able to know where all the runtime libraries are located so it can create the ld.so.cache. the problem is that script _also_ does stuff like making symlinks and creating user-specific caches, so it accesses the $SNAP_USER_DATA or $HOME
<mborzecki> sounds like a problem with the script then
<pedronis> pstolowski: btw, I answered your comments in #8691
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<pstolowski> ty
<pstolowski> pedronis: right, i see InstallHostWritableDir is the relatively new addition, my PR was based on what was there before
<pstolowski> pedronis: thanks for spotting
<pedronis> the spread should have caught it
<pedronis> pstolowski: anyway let's chat how to organize the code, possibly in a follow up
<pstolowski> ijohnson: hi! can you take another look at #8639? are you ok with the reasoning about locking?
<mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
<pedronis> pstolowski: he's off today
<pstolowski> ah
<diddledan> interesting. I just ran radeontop while running my fakecam app - it looks like I am successfully running something against the card even though opencv says it couldn't initialise
<mup> Bug #1880698 changed:  /etc/writable is double mounted <uc20> <Snappy:Fix Released> <https://launchpad.net/bugs/1880698>
<mup> PR snapd#8761 opened: add msteams url support <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
 * zyga wonders what to focus on first
<mup> PR snapcraft#3148 opened: [wip] specifications: environment-manager datastore <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3148>
<zyga> maybe only after the calls
 * zyga quick coffee
<jdstrand> Saviq: hey, done
<Saviq> jdstrand: thanks!
<Saviq> jdstrand: can you confirm for us whether multipass is auto-connected on "home: read: all"? Not sure how to reliably check that :)
<axino> hi
<axino> I'm trying to install MAAS snaps in a cohort
<axino> but I'm getting different versions for the same tracks
<axino> ah I think I found the root cause
<axino> "snap info" lies
<roadmr> hi sergiusens
<jdstrand> Saviq: you have the snap declaration that should do that
<Saviq> jdstrand: ack, that's what I thought, thanks :)
<jdstrand> Saviq: but just installing on core would be the test
<Saviq> jdstrand: right, that :)
<Saviq> was thinking something on my host, but I've not found how to "forget" previous manual connections
<jdstrand> since that tests both the 'auto-connect on core' and the 'auto-connect with read'
<pstolowski> cachio: i've addressed your recent comments to preseed-lxd test
<cachio> pstolowski, looking
<cachio> thanks
<zyga> end of meetings
<roadmr> sergiusens: say I have revision 1 for amd64, and revision2 for armhf. If I do snapcraft release name 1 stable; snapcraft release 2 stable; will both be available, I just get the one that matches client architecture?
<mup> PR snapd#8762 opened: snap-bootstrap: remove key-file/recovery-key on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<pedronis> mvo: ^ a comment there
<mup> PR snapd#8763 opened: gadget: make ext4 filesystems with or without metadata checksum <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8763>
<sergiusens> roadmr: I don't understand the question itself, but your two statements is how snapcraft promote works today
<sergiusens> roadmr: that is, you cannot choose the architecture of the channel being released to, that's decided Snap Store side depending on the architecture the revision is tied TooLmaN
<roadmr> TooLMaN  :)
<sergiusens> oops on autocomplete
<sergiusens> tied too
<roadmr> heheh
<roadmr> sergiusens: interesting
<roadmr> sergiusens: so if I try that manually how would that work?
<roadmr> sergiusens: assuming I have two local .snap files, one for each arch
<diddledan> https://www.youtube.com/watch?v=CDvCCcFr1Vc
<roadmr> let's change the command, what if I snapcraft push --release 1_amd64.snap stable
<roadmr> then snapcraft push --release 2_armhf.snap stable
<roadmr> diddledan: I am NOT clicking on your rickrolling link. (/me does)
<sergiusens> roadmr: you will have stable with revision 1 for amd64 and revision 2 for armhf
<roadmr> sergiusens: aha, ok that's what the question was about really
<roadmr> and that's what I was expecting
<sergiusens> so snap install name on amd64 will give you rev 1 and for armhf will return rev 2
<roadmr> righto :) as expected
<sergiusens> assuming the store assigns rev1 to the first push and rev2 to the second
<roadmr> right
<sergiusens> as I just noticed I was biased by seeing the revision in the version part of the filename
<sergiusens> with no name!
<sergiusens> roadmr: also, "snapcraft upload" ftw :-)
<roadmr> \o/!!!
<roadmr> I'll try that next time!
<zyga> No systemd in WSL2
<zyga> And wsl repo is broken somehow?
 * cachio lunch
<diddledan> zyga, lies
<diddledan> just needs a bit of customisation, and systemd works
<ogra> pfft ... make them switch to upstart !
<roadmr> \o/
<diddledan> ogra, not SMF?
<diddledan> :-p
<diddledan> or, daemontools?
<diddledan> :-p
<ogra> busybox ...
<mvo> pedronis: thanks for your comment there
<cmatsuoka> mvo: the metadata_csum change should only affect snap-bootstrap, the rest should work without metadata_csum as it was before
<mvo> cmatsuoka: thanks, I looked at the code and it was not obvious to me that this mkfs handler is just used by the uc20 code, it looked like a generic gadget helper that would also be used by other gadget update stuff. if not that's great
<cmatsuoka> mvo: I admit the name choices can be confusing, but my idea was to use the default name to do the default thing (and the special name to pass extra options)
<cmatsuoka> mvo: that helper is used by, i think, image generation and maybe more things, but the new function that's there is actually calling the old mkfs contents
<cmatsuoka> mvo: the new contents, with the old function name, is called by snap-bootstrap only
<mvo> cmatsuoka: yeah, sorry, I think I get it now. I will comment in the PR, sorry again that I did not dig deeper
<cmatsuoka> mvo: it can be renamed if you think it's really misleading
<mvo> cmatsuoka: it's fine, I followed up with yet another question, maybe it's a sign I should actually call it a aday :)
<mvo> cmatsuoka: anyway, have a look, I get dinner now(ish)
<pedronis> mvo: cmatsuoka: we should double check with maciej but I don't think making filesystems is used at all by gadget updates
<pedronis> atm
<kyrofa> Anyone know of snap confinement issues on pop os?
<kyrofa> Got a bug report where the snap can't access /etc/os-release, which is contained in the core snap. Works for me on ubuntu
<cmatsuoka> pedronis: mvo raised an interesting point, is that code used only on the actual device? if so we can always use the defaults instead of having two functions using different parameters
<pedronis> cmatsuoka: as far I know it's used on anything but uc20
<cmatsuoka> pedronis: but does it run when, say, creating an uc image on a different host, or does it only run on the device itself?
<pedronis> cmatsuoka: we don't have code that make images
<pedronis> only ubuntu-image does
<zyga> kyrofa: /etc/os-release is taken from the host, if /etc/os-release is a symlink then it will most likely not work
<pedronis> and as I said, I'm 90% sure that that code is not used by gadget updates
<cmatsuoka> pedronis: so can we just drop -O -metadata_csum and always use the default paramters for mkfs?
<pedronis> cmatsuoka: in my opinion yes, probably living a comment about the code now working on xenial as is
<pedronis> *leaving
<pedronis> and we can deal with that when we have to
<pedronis> cmatsuoka: we had a long term plan to subsume some work of ubuntu-image, that's what maciej prototype was about
<cmatsuoka> ah ok
<pedronis> cmatsuoka: anyway as I said we probably need maciej to double check this
<kyrofa> zyga, it's taken from the host? Then how do you explain this? https://paste.ubuntu.com/p/j52StNjpxk/
<pedronis> but my perusing of the code and removing stuff seems to confirm that nothing but boostrap was actively using those bits
<zyga> kyrofa: /etc is
<zyga> kyrofa: ls -ld /etc/os-release?
<cmatsuoka> but even on xenial, the default parameters on xenial's mkfs should do the right thing
<zyga> kyrofa: if that points to /whatever/stuff then that certainly won't work
<pedronis> cmatsuoka: I don't understand,  we can make uc16 images on focal
<pedronis> if that's your question
<pedronis> but we don't have code to do that e2e
<kyrofa> zyga, but wait-- my pastebin shows that it's using the os-release out of the core snap, doesn't it?
<kyrofa> So how would the host having a symlink there matter?
<pedronis> cmatsuoka: ubuntu-image does
<pedronis> cmatsuoka: it mkfs that breaks? or is the kernel using the filesystem that will break?
<zyga> kyrofa: stop and think - /etc is *exactly* from the host, what is /etc/os-release on your pop-os host?
<cmatsuoka> pedronis: it's mkfs that breaks during the uc20 installation
<cmatsuoka> on the 600P
<pedronis> cmatsuoka: well, we are not xenial at point
<kyrofa> zyga, that's my point, let's back up: how can /etc be *exactly* from the host given my pastebin?
<pedronis> sorry it probably more confusing that it should be
<cmatsuoka> so there are two constraints: xenial forbids metadata_csum, 600P requires metadata_csum
<zyga> kyrofa: I'll let you run ls -ld and answer your question :)
<zyga> don't cat it
<kyrofa> Oh because it's a relative symlink
<zyga> :D
<zyga> tadam
<zyga> os-release may be a symlink that points anywhere
<pedronis> cmatsuoka: is mkfs that breaks on xenial on that param? or is the kernel also that can't use a filesystem built with that param?
<pedronis> I mean the kernel we shipped with xenial/UC16 ?
<cmatsuoka> pedronis: the comment says that the system doesn't boot afterwards
<pedronis> cmatsuoka: ?
<pedronis> cmatsuoka: I'm not talking uc20
<pedronis> cmatsuoka: I'm asking about xenial
<cmatsuoka> pedronis: yes, let me find the comment here
<cmatsuoka> pedronis: [using metadata_csum] were unsupported in Ubuntu 16.04 and Ubuntu Core 16 systems and would lead to a boot failure if enabled
 * cmatsuoka verifies if FilesystemImageWriter is actually used somewhere...
<pedronis> cmatsuoka: afaict is not, but please double check
 * cmatsuoka missed lunch time again
<roadmr> cmatsuoka: it's never too late :)
<cmatsuoka> yeah, I'll be back soon :)
<pedronis> mmh, the preseed tests have started failing on 19.10
<pedronis> cmatsuoka: thanks for the changes, made some suggestions about the comments in that function
<cmatsuoka> pedronis: thank you, will update
<mup> PR snapd#8764 opened: tests: adding ubuntu 20.10 to spread tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8764>
<kyrofa> zyga, apparently on pop os the os-release file is in /etc/pop-os/os-release. Is that not accessible from confinement?
<cmatsuoka> cachio: did you see tumbleweed degraded mode errors recently?
<cachio> cmatsuoka, no
<cachio> do you have any link?
<cachio> cmatsuoka, I could check that
<cmatsuoka> cachio: just a sec, let me find it
<cmatsuoka> cachio: also preseed errors
<cmatsuoka> cachio: https://github.com/snapcore/snapd/pull/8763/checks?check_run_id=717978228
<mup> PR #8763: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8763>
<cachio> cmatsuoka, thanks, I'll take a look
<cmatsuoka> cachio: also this one: https://github.com/snapcore/snapd/pull/8763/checks?check_run_id=717976666
<cachio> cmatsuoka, the last one please merge it to master
<cmatsuoka> ok
<cachio> for all the erros related to preseed
<cachio> checking the othe rone
<cmatsuoka> cachio: hmm, I can't merge master, this is against release/2.45, what is the fix to cherry pick?
<cachio> cmatsuoka, ah, need to check with pawel in this case
<cmatsuoka> ah ok, I'd also need mvo to actually cherry pick that into the release branch
<cachio> yes
<cachio> the other one I need to check it becuase the service which is failing is one that we fix while the image is update
<cachio> d
<cachio> so it shouldn't fail
<cachio> I'll take a look
<zyga> kyrofa: it might be accessible but not with any stock interface, perhaps except system files
<kyrofa> zyga, so /etc is mounted in from the host, but it's not all actually accessible, which I suppose makes sense. I didn't realize ubuntu derivatives did things like that. No confined snap will be able to read /etc/os-release on pop os by default
<kyrofa> We might want to consider ways to resolve that
<zyga> kyrofa: correct
<zyga> kyrofa: my way to resolve that is to stop sharing /etc altogether
<zyga> it was a mistake IMO
<kyrofa> Yeah that was a bit of a sledgehammer, but we can't really take it back now
<zyga> there is a path forward and a way out, we can add an empty /etc and populate it with curated content
<zyga> and not break apps
<zyga> if we understand what each interface provides
<zyga> it's a lot of work
<zyga> but it's not impossible
<kyrofa> It certainly effects the cross-distro story. Anyway, I told my reporter to report the bug against snapd, so keep an eye out for that
<zyga> ok
<kyrofa> Thanks for the help!
<zyga> pleasure :)
#snappy 2020-05-29
<mborzecki> morning
<mup> PR snapd#8763 closed: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
<mborzecki> quick errand
<mup> PR snapd#8758 closed: tests: run ubuntu-20.04-* tests on all ubuntu-2* releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8758>
<mvo> zyga: I see "2020-05-27T16:45:02.9982589Z invariant-tool: crashed-snap-confine not-ok" in some tests, most recently in https://github.com/snapcore/snapd/pull/8744/checks?check_run_id=713534659
<mup> PR #8744: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <https://github.com/snapcore/snapd/pull/8744>
<mup> PR snapd#8744 closed: interfaces-ssh-keys: Support reading /etc/ssh/ssh_config.d/ <Needs security review> <Created by andrewsomething> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8744>
<pedronis> mborzecki: mvo: hi, #8763 needs to be ported to master?  (I didn't notice it was target at 2.45 only)
<mup> PR #8763: gadget: make ext4 filesystems with or without metadata checksum <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8763>
<mvo> pedronis: I think there were two, let me quickly check (one for master, one for 2.45)
<mvo> pedronis: oh, you are right, let's fix this :(
<pedronis> mvo: does the test in #8762 works?
<mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<mvo> pedronis: yes, I'm reworking it now though to put the files into the right places, i.e. simulate more closely what we really do (/run/mnt/ubuntu-seed/keyfile, /run/mnt/ubuntu-data/system-data/var/lib/snapd/fde/... for the rest)
<pedronis> ah, good
<mup> PR snapd#8765 opened: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8765>
<pedronis> mvo: btw the comment in the description was wrong, given that the note mentions reboot, I don't think it's just a creation-time issue
<zyga> Good morning
<mborzecki> re
<mborzecki> mvo: pedronis: zyga: hey
<pedronis> mvo: and sorry for the many rounds of comments on #8762, I wasn't concetrating properly last night
<mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<mvo> pedronis: thank you for the comments, the opposite - my stuff was not coherent enough :( but I will push an updated version soon that is hopefully good
<pstolowski> morning
<mvo> good morning pstolowski
<zyga> mvo: I need to look, I think it's not really that but leftover from package upgrade, trying to reproduce now
<zyga> offtopic, I was thinking, that 8GB pi may be just able to run run spread with qemu backend
<mvo> zyga: finally a arm spread runner?
<zyga> mvo: we'll see, but I think given the low cost and 8GB of ram, might be possible
<mborzecki> zyga: do ou know what's the status of kvm and virtio-* on aarch64?
<mborzecki> i would guess it's a major factor for making the tests run smoothly
<pstolowski> i'd appreciate a second review for #8710, test only
<mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<mborzecki> pstolowski: i can take a look
<pstolowski> mborzecki: thanks!
<zyga> mborzecki: not really, I think 32 bit kvm was removed but 64 bit should be ok
<pstolowski> mvo: i was talking to Sergio yesterday about uc20 model assertions and the TODO you have in gadget-config-defaults-vitality spread test; apparently it's not possible yet to port this to uc20? i'd like a similiar test for nested uc20
<mvo> pstolowski: I need to look again, but iirc the simulation of firstboot is slightly diffreent on uc20
<pedronis> we need to think
<pedronis> pstolowski: can you explain what you mean with similar but for nested?
<pedronis> those tests are not nested
<pstolowski> pedronis: i'm repacking the gadget,  but not cheating about firstboot (booting for real)
<pstolowski> *i mean
<pedronis> pstolowski: I see, you need a dangerous model, you need to your unasserted snaps into the seed partition in /systems/SYSTEM/snaps and you need a /systesm/SEED/options.yaml which is a bit like seed.yaml but only for overrides
<pedronis> pstolowski: about options.yaml see seed/internal/options20.go
<mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/8271 ? the failure on 19.10 is unratelated to the change
<mup> PR #8271: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8271>
<mvo> mborzecki: sure
<pstolowski> pedronis: thanks for pointers, that helps!
<mvo> mborzecki: does it have two +1 ?
<mvo> mborzecki: nevermind, I have a look
<mborzecki> mvo: ah no ;) jdstrand_ gave +1, but i can't cause i pushed some changes there
<mup> PR snapd#8271 closed: interfaces: add hugepages-control <Needs security review> <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8271>
<pstolowski> pedronis: do you have a moment to talk about sysconfig changes?
<pedronis> pstolowski: yes
<pstolowski> pedronis: ok, coming to standup ho
<mborzecki> mup is asleep?
<mborzecki> fairly simple fix in daemon: https://github.com/snapcore/snapd/pull/8766
<mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
<mup> PR snapd#8766 opened: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
<abeato> mborzecki, hey, thanks for taking care of the hugepages PR - I should really have done those changes, but got trapped with other things
<zyga> mvo: I spent some time looking at the log you referenced and it does seem like something is randomly failing in that test
<mborzecki> abeato: hey, np, we're here to help land things too :)
<mvo> zyga: thanks, yeah, it looks like 19.10 and 20.04 are a bit more unhappy today than earlier this week :/
<zyga> I'll try to do something about that :)
<zyga> call in 5, let me prepare
<mup> PR snapd#8767 opened: snap: refactor download code for testing/extending <Created by mvo5> <https://github.com/snapcore/snapd/pull/8767>
<zyga> ah
 * zyga is dummy
<zyga> that's not today :0
<zyga> ok :)
<zyga> back to original task
<zyga> journal logs don't show failures from snapd-session-agent
<zyga> but
<zyga> mvo: this is the failure
<zyga> May 28 20:06:30 may281929-399859 snapd[27253]: May 28 19:59:05 may281929-399859 systemd[1273]: snapd.session-agent.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
<zyga> I suspect those are branches without https://github.com/snapcore/snapd/pull/8753 but let me verify
<mup> PR #8753: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8753>
<zyga> hmm, no, that patch is present
<zyga> curious
<zyga> let's dig deeper
<zyga> hmm
<zyga> actually
<zyga> just reading the error message
<zyga> it seems to suggest the problem is not daemon-reload
<zyga> but the fact that the socket needs restarting as wel
<zyga> *well
<zyga> that might be it
<zyga> we'll know soon
<mvo> zyga: thanks!
<mup> PR snapd#8749 closed: configcore: show better error when disabling services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8749>
<mup> PR snapd#8757 closed: tests: update statx test to run on all LTS releases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8757>
<pedronis> mvo: oops, there was confusion, my proposal was to replace the second line of the comment, not all of it
<pedronis> in #8782
<mvo> pedronis: oh, sorry. let me fix that
<pedronis> heh
<pedronis> #8762
<mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<mvo> pedronis: updated again
<pedronis> thanks
<zyga> pedronis: nitpick, can we call $TESTTOOLS $TESTTOOLS instead?
<zyga> er
<zyga> TESTSTOOLS -> TESTTOOLS
<zyga> the  env vra
<zyga> *var
<pedronis> we have TESTSLIB not TESTLIB
<zyga> the var mimicks path
<zyga> but the name sounds bad if you think about it
<zyga> both plural
<pedronis> I'm worried about TESTSLIB TESTTOOLS
<zyga> that they differ?
<zyga> test libs would be better for english var
<zyga> the path can stay as is
<zyga> TESTLIBS
<zyga> TESTTOOLS
<pedronis> plural in programming are always trouble
<pedronis> as I said I'm more worried about consistency than english here
<zyga> we can do both ;)
<zyga> I mean we can rename both while we are at it
<zyga> $TESTTOOLS/foo reads better than $TESTSTOOLS/foo
<pedronis> I don't  know, not a fan of TESTLIBS
<pedronis> zyga: I fear TESTSLIB and TESTSTOOLS, anyway my nature we shouldn't need to use the latter that much
<pedronis> s/my nature/by nature/
<zyga> not sure what you mean by feal
<zyga> fear *
<pedronis> I mean, that we go with those
<pedronis> mvo: I re-reviewed #8762
<mup> PR #8762: snap-bootstrap: remove sealed key file on reinstall <Skip spread> <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<pedronis> anyway on unrelated note the user service stuff seems still fragile, I think we could tweak the tests more, but probably the fragility is real and the code need some changes
<mvo> pedronis: thanks! so your suggestion is to run the same tests as for the install case in the reinstall case?
<pedronis> mvo: either that because it seems cheap (at least code wise), or to at least run a small subset related to the encrypted partition
<mvo> pedronis: yeah, it makes sense
<mvo> pedronis: do you prefer duplication of the code or should I move it into a helper like with "prepare.sh" ?
<pedronis> mvo: sorry, you don't need to duplicate code
<pedronis> you can just reduce the scope of the if, no?
<zyga> pedronis: it's a test bug, I fixed it just now
<zyga> pedronis: (user service stuff)
<mvo> pedronis: aha, nice
<mvo> pedronis: yeah, I think this will work
<pedronis> zyga: I doubt is just a test bug
<zyga> apart from the known TODO, I think it is
<zyga> the TODO being that removing snapd doesn't properly clean up user session services
<zyga> you'll see in a moment
<pedronis> zyga: there's a deeper issue, the existence of the snapd.session-agent.socket used by the code, doesn't really tell much about the state of the session
<zyga> what kind of state are you referring to?
<pedronis> we are going to ask to do it things with services in the session but the session, might be just starting up
<pedronis> we don't know if the session overall in in a steady state
<zyga> I think there's no such thing as a stady state, there are concurrently running processes that may stop or start as they please; I think it depends on what kind of ops we'd like the agent to perform
<pedronis> I understand that
<pedronis> but the existence of the socket is not here nor there
<mborzecki> mvo: can we land https://github.com/snapcore/snapd/pull/8520 ? the failure on 20.04 is the user service again
<pedronis> in terms of a barrier related to the state of other services
<mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Simple ð> <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
<zyga> pedronis: the problem we are seeing in tests right now is related to the particular handling of socket units by systemd; I think that's a separate issue from what you are describing
<zyga> our tests continously remove and reinstall snapd, making the socket definition in memory wrong, that was fixed (for tests) recently; what we are seeing now is that when a socket is removed from disk you must perform additional actions, more than just daemon-reload, for it to go away
<zyga> and oddly enough installing a new definition of the socket is not sufficient
<mup> PR snapd#7869 closed: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7869>
<zyga> I also wonder if this is not the same problem we had with pulseaudio, without realizing it
<zyga> it's just there are so few tests that touch it it may not be triggered often
<pedronis> zyga: btw, related question, does the refresh-awareness tracking for services also works for user services?
<zyga> yes
<zyga> fortunately :)
<mborzecki> anyone tried the liferea snap? the font cache from the host is not mounted inside the snap, but i still get boxes
<mborzecki> all i get is https://i.imgur.com/rNFMezE.png
<zyga> hmmm
<zyga> mborzecki: nsenter and poke around
<zyga> wonder if there's something more going on
<zyga> at some point fontconfig will figure out how to IPC the boxes around
<mborzecki> hm i mounted a tmpfs over /usr/share/fonts in the mount ns of a snap and there's no more boxes
<zyga> what's in /usr/share/fonts?
<zyga> maybe a read only cache?
<zyga> mborzecki, pedronis: please check this out https://github.com/snapcore/snapd/pull/8768
<mup> PR #8768: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
<mborzecki> what if the fontconfig from gnome runtime is jsut buggy?
<zyga> is there any configuration in /usr/share/fonts that is read by fontconfig?
<mborzecki> zyga: there shouldn't be, i have a tmpfs on /etc/fonts and /usr/share/fonts
<zyga> I mean
<zyga> before you do the tmpfs
<zyga> before you hide stuff there
<zyga> what do you see if you find /usr/share/fonts
<zyga> mborzecki: alternatively strace and explore
<mborzecki> just fonts in directories
<zyga> or ltrace
<zyga> so are you saying those fonts cannot be rendered?
<mborzecki> zyga: yeah, either boxes or segfaults again
<zyga> hmmm
<zyga> what kind of fonts do you have there
<mup> PR snapd#8768 opened: tests: fix broken snapd.session agent.socket <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
<zyga> maybe bisect
<zyga> and see which file triggers it
<zyga> I think there must be something more than that
<mborzecki> nothign special, looks like i need 18.04 desktop vm
<zyga> maybe some font has a special hint bytecode that is disabled in arch
<zyga> and then without a build option that crashes
<mborzecki> zyga: but fontconfig is from the snap, if it can't handle arbitrary fonts the all hope is lost ;P
<zyga> ahhh
<zyga> interesting
<zyga> yeah
<zyga> but I think bisecting is the way to go
<zyga> how many files do you have there?
<pedronis> zyga: is tests cleanup meant to be on the PATH?
<zyga> mborzecki: or maybe another idea: are there any duplicates?
<pedronis> zyga: sorry, tests.cleanup
<zyga> pedronis: I don't think so, it's only going to be used in prepare-restore in two places
<pedronis> zyga: then it shouldn't have the tests. prefix
<zyga> it's not something I expect to see in any task.yaml
<zyga> oh? I misread the readme then
<zyga> yeah, I see the fragment now
<zyga> "commands that expect to be on PATH should follow more speicfic naming conventions"
<zyga> I'll correct that, it's just a draft :)
<zyga> so just $TESTSTOOLS/clenaup?
<zyga> *cleanup
<pedronis> or state-cleanup
<zyga> ok
<zyga> we should think about session services more
<zyga> I think without handling the remove story we should be very careful
<zyga> mborzecki: what do you think about the agent socket
<zyga> I think this is actually a property of any unit
<zyga> it's just sockets seem worse as "hey, it's there, let me talk to it"
<zyga> and for non-session stuff we do stop services and sockets so it's not something we've seen before
<mvo> pedronis: I reworked 8762, test is much nicer now and shares a ton. silly me for not thinking about this earlier :)
<mborzecki> zyga: hmm making /usr/share/fonts/adobe-source-code-pro available inside the snap causes boxes and segfaults :P
<zyga> awesome
<zyga> now put that font on a 18.04 vm
<zyga> what's the base of the snap you tried?
<zyga> maybe strace/gdb the app
<zyga> and get fontconfig-dbg
<mborzecki> zyga: funny, i don't even use any of that fonts
<mup> PR snapd#8765 closed: gadget: make ext4 filesystems with or without metadata checksum (master) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8765>
<mborzecki> zyga: the backtrace is the same as before https://forum.snapcraft.io/t/gimp-and-glimpse-editor-snaps-segfault-on-arch/17100
<zyga> where's the backtrace?
<zyga> that's just some log
<zyga> time to take Bit out for a walk
<zyga> back in a bit
<mborzecki> zyga: SourceCodeVariable-Roman.otf this font is causing a problem
<mborzecki> wodner what's so special about it
<zyga> mborzecki: developers and their fancy pantsy fonts ;)
<zyga> mborzecki: yeah, it's curious
<zyga> if you can reporduce the crash outside of snaps
<zyga> we should report those
<mborzecki> zyga: but i'm not even using this font
<zyga> and even debug and fix them, if possible
<zyga> mborzecki: so what, it's there
<zyga> it gets scanned
<mborzecki> glimpse-editor and gimp segfault, probably because the load up all info about fonts
<zyga> yeah
<ogra> try inkscape
<mborzecki> apps that aren't so interested get boxes?
<ogra> from the edge channel
<zyga> mborzecki: maybe boxes are for another reason
<zyga> the cache is corrupted
<ogra> it has this new fancy font handling hack
<mborzecki> ogra: oh, right
<zyga> try generating the cache
<zyga> and see if that crashes
<ogra> try inkscape first to see if the hack works !
<zyga> mvo: please check this out
<zyga> https://github.com/snapcore/snapd/pull/8768
<mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
<zyga> now really afk
<mborzecki> yeah, inkscape edge works
<ogra> awesome
<ogra> it throws some font.conf errors on startup though ... (unknown options) ... but i see it working in zoom as well
<mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
<pstolowski> pedronis: i've updated #8567, let me know if this is what you had in mind. image_linux became slightly ugly
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8766 ?
<mup> PR #8766: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8766>
<mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
<ijohnson> morning folks
<mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
<mup> Bug #1881276 changed: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
<mup> Bug #1881276 opened: shutdown fails to unmount some loops because of udevd, mark them LazyUnmount <uc20> <Snappy:New> <https://launchpad.net/bugs/1881276>
<mborzecki> zyga: so the same font works in ubuntu, even in the same snap on ubuntu
<mborzecki> i've mounted tmpfs over the fonts cache and /etc/fonts
<mborzecki> and it still works, wtf??
<zyga> Hmmmmm
<zyga> Drop font cache
<zyga> Does it crash?
<mborzecki> no
<mborzecki> it's dropped already
<mborzecki> no /var/cache/fontconfig, no /etc/fonts
<ogra> and ~/.local/fonts ... etc ?
<ogra> (iirc the desktop launchers pick these up too)
<pedronis> pstolowski: I reviewed #8567
<mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
<pstolowski> pedronis: thanks
<pedronis> thank you
<mborzecki> heh, wiped ~/.cache/fontconfig/ and it's working now
<mborzecki> damn, i don't see how we can make it work if there's even a slightest bit of fontconfig cache being shared
<ijohnson> mborzecki: re 8766, if you do `snap restart lxd.daemon` now we don't pass in inst.Names though, we always pass in namesToSnapNames(...) so how could the names on the task get set to the inst.Names
<mup> PR snapd#8639 closed: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8639>
<mborzecki> ijohnson: i clarified in a comment there, what meant by `names` in the comment is inst.Names
<mborzecki> ijohnson: anyways, i rephrased the comment, please check if it makes sense now
<ijohnson> mborzecki: ahhhhh sorry I'm a bit slow this morning it seems
 * ijohnson looks now
<ijohnson> thank you makes sense now
<mborzecki> cool
<zyga> mborzecki: so which part of our code makes your ~/.cache/fontconfig available to the snap?
<zyga> mborzecki, mvo: please review https://github.com/snapcore/snapd/pull/8768 to unbreak master
<mup> PR #8768: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8768>
<mborzecki> zyga: desktop-launch copies over the cache from $HOME/.cache/fontconfig, it works because the snap uses `home`
<mborzecki> zyga: so outside of our control apaprently
<zyga> mborzecki: wait, cannot we block the cache somehow?
<zyga> we could also add a user mount namespace directory to mask ~/.cache/fontconfig
<zyga> make it empty
<zyga> right?
<mborzecki> zyga: sounds like slippery slope
<zyga> why?
<mborzecki> feels too fiddly
<mborzecki> it's probably ok as some temporar fix
<zyga> but that's not a good answer :) on one hand side we have crashes and boxes
<mborzecki> but it'd really prefer to have the right fix
<zyga> on the other "feels too fiddly"?
<zyga> sure, what's the right fix?
<zyga> (I'm with you on that)
<zyga> I would love to know if it's a specific font
<zyga> or just any cache
<mborzecki> zyga: didn't we discuss that? have snaps build their own cache during install, find a way to share that maybe witht the gnome content snap
<zyga> mborzecki: we did discuss that but I think we ought to fix the crashes without requiring all snaps to rebuild
<pedronis> mborzecki: we discusses something like that platform snaps taking care of this for snaps that use them, or possibly individual snaps
<pedronis> *discussed
<mborzecki> zyga: hmm, w8, we can't really expand $HOME in user mounts, can we?
<zyga> mborzecki: so, not yet but I kind of wrote a patch for that
<mborzecki> xD
<zyga> not sure if you noticed a QFG1 themed tweet a few weekends ago
<zyga> I added support for all the goodies required to have ~ available
<zyga> today is too late but I can post them next week with some cleanups
<mborzecki> i recall i had a patch for $HOME too at some point, but for some reason we didn't do it
<zyga> it was somewhat fiddly
<zyga> anyway, I will post it later
<mborzecki> perhaps it was aroudn the time of parallel installs and mapping $HOME/snap/foo_bar $HOME/snap/foo ?
<cachio> zyga, could you please take a look to https://github.com/snapcore/spread/pull/107
<mup> PR spread#107: Use GitHub actions to test spread <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/107>
<cachio> zyga, and hi
<cmatsuoka> zyga: I have snapd using 10% of CPU and constantly writing on disk for some time, any idea on what is happening there? https://pasteboard.co/JaC0JzY.png
<zyga> cachio: ah, right you asked me yesterday
<zyga> sure
<cachio> zyga, thanks a lot
<zyga> cachio: snap changes
<mborzecki> cmatsuoka: snap changes?
<zyga> I meant cmatsuoka :)
<mborzecki> maybe it'd downloading something and rewriting state.json all the time
<cmatsuoka> zyga, mborzecki: no changes, no logs
<mborzecki> what was that fs tool
<zyga> there are _no_ changes
<zyga> mborzecki: which one?
<zyga> forkstat?
<zyga> or iotop?
<mborzecki> zyga: fs<something>stat
<cmatsuoka> i used iotop and fatrace
<cmatsuoka> fatrace interestingly doesn't show anything
<mborzecki> fnotifystat
<zyga> ah
<pstolowski> ijohnson: hi! thanks for looking at services PRs
<mborzecki> cmatsuoka: maybe it's the same problem as https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1831629
<mup> Bug #1831629: snapd hammers SSD for long periods <amd64> <apport-bug> <disco> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1831629>
<cmatsuoka> let me see...
<zyga> cmatsuoka: run forkstat too
<zyga> I wonder if we fail on something
<mborzecki> heh almost standup time
<cmatsuoka> not much information there but it could be the same thing
<zyga> cmatsuoka: maybe join ho and screen share
<zyga> I can hop
<cmatsuoka> zyga: yeah, going there
<mborzecki> standup ho?
<mup> PR snapd#8643 closed: wrappers: add RestartServices function and ReloadOrRestart to systemd (3/N) <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8643>
<mup> PR snapd#8768 closed: tests: fix broken snapd.session agent.socket <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8768>
<mup> PR snapd#8769 opened: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
<mup> PR snapd#8710 closed: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<mup> PR snapd#8770 opened: snap/naming: add ParseSecurityTag and friends <Created by zyga> <https://github.com/snapcore/snapd/pull/8770>
<pstolowski> zyga: if you have a moment, that's the PR from yesterday: https://github.com/snapcore/snapd/pull/8640
<mup> PR #8640: wrappers: pass 'disable' flag to StopServices wrapper (2/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
<ackk> jdstrand_, hi, around?
<zyga> re
<zyga> back to reviews
<zyga> pstolowski: sure!
<zyga> pstolowski: looks good
<zyga> pstolowski: review sent
<pstolowski> dziÄki!
<zyga> proszÄ :)
<mvo> 8762 needs a second review
<zyga> can someone please look at https://github.com/snapcore/snapd/pull/8769/checks?check_run_id=720464127 and explain what failed in snap-repair?
<mup> PR #8769: dbusutil: move all D-Bus helpers and D-Bus test helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8769>
<zyga> cachio: that change is somewhat big, I will probably not finish reviewing it today
<zyga> cachio: my mild preference would be to split it up into separate cunks
<zyga> chunks
<zyga> I don't understand why some things are done; I have a few pending questoins
<zyga> *questions
<cachio> zyga, ok, let me check
<zyga> cachio: but please, if you can, open separate PR for the reorg
<zyga> as 37 changed files is a bit too much to follow coupled with actions
<cachio> zyga, well, most of the things are just moved
<cachio> I had to move a test suite
<cachio> so all the tests are moved
<cachio> not changed
<cachio> and it is the same for the prepare in the spread.yaml
<zyga> but the reason for that move is not clear from the diff or description alone
<cachio> zyga, I think the best is to split in 2
<cachio> fist github actions
<cachio> then in a second pr
<cachio> put all the migration
<cachio> zyga, does it make sense?
<cachio> I just need to revert a commit for that
<zyga> or the other way around, whatever is easier
<zyga> the reorg can probably land faster
<cachio> sure
<cachio> I'll make it
<zyga> thanks
<mup> PR snapd#8771 opened: bootloader/ubootenv: don't panic with an empty uboot env <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8771>
<jdstrand_> ackk: hey, yes
<ackk> jdstrand, hi, I have a quesion for you: given snap A and B with a container interaface slot/plug (from the same publisher, if that matters), is it possible to get them autoconected if they're both installed? can it be done through a store assertion?
<ackk> jdstrand, no default-provider though, as we don't want to get B automatically installed if A is installed
<jdstrand> ackk: by container interface, you mean content interface?
<ackk> jdstrand, yes, sorry, muscle memory :)
<jdstrand> ackk: the content interface should autoconnect from the same publisher
<jdstrand> without needing to create a snap decl
<pedronis> it should happen already, unless there's more than one slot with the same content label
<ackk> oh, really? I thougth that would only happen for default-provider
 * ackk tries
<pedronis> default-provider has zero effects on connections
<pedronis> it just pulls in the sanp
<pedronis> *snap
<ackk> I'm not seeing this with maas and maas-test-db
<ackk> snap install maas --edge + snap install --channel=2.8 maas-test-db
<zyga> ackk: could you paste the relevant plug and slot definitions from the snap.yaml's
<zyga> snap.yamls
<ackk> https://paste.ubuntu.com/p/s3R9GcqJRK/ are connections I see after installing as above
<ogra> wow ... looks like we have some racyness
<ogra> https://paste.ubuntu.com/p/jQZsVpQy67/
<ackk> zyga, sure, one sec
<ogra> (this board has not been booted since about 5 months)
<ogra> (later calls to the snap command seem to work again)
<ackk> zyga, https://paste.ubuntu.com/p/wX6C3ZVZfs/
<ackk> zyga, do names need to match?
<zyga> I don't think so
<zyga> btw, do you need write? I think read should suffice for sockets
<zyga> does it work if you connect manually?
<zyga> (can you connect at all, I guess, is the question)
<ackk> zyga, readonly doesn't work, no
<zyga> I'd be interested in denials later on
<ackk> zyga, yes, works fine if I connect it. reason I'm asking is purely to save one extra steps for users
<zyga> do you have other provides of "db-socket"?
<zyga> (installed)
<ackk> no
<zyga> do we log anything in snapd.service about tihs?
<ackk> zyga, I only see this when installing maas-test-db (with maas installed):
<ackk> May 29 15:31:22 maas snapd[368]: api.go:985: Installing snap "maas-test-db" revision unset
<zyga> I see
<zyga> oh well, someone needs to dig
<zyga> could you please ping me on Monday
<ackk> zyga, sure, thanks
<zyga> I'm wrapping up a branch and I'd like to EOD
<zyga> it's probably something silly
<zyga> I wonder if we can get better debugging of cases like that
<pedronis> ackk: I installed maas --edge and I don't see the slot
<pedronis> in the yaml
<pedronis> or the plug
<cachio> zyga, updated the pr
<ackk> weird, lemme see
<cachio> zyga, about the version of go used to build spread
<zyga> pedronis: I'm preparing the tools reorg pr
<pedronis> ackk: did mean 2.8/edge in your instructions?
<cachio> we already are builing with this version
<ackk> pedronis, I was just testing thatm it seems 2.8/edge does work
<cachio> so I just put that version on the actions
<ackk> pedronis, weird, we added that a long time ago and both revisions don't seem far off
<pedronis> ackk: yea, --edge is 2.7/edge and doesn't have any of that
<cachio> zyga, not sure which kind of comment you would add there
<zyga> cachio: about the significance of that particular version,
<ackk> pedronis, no, 2.7 doesn't, but --edge should be latest/edge which is based on CI. for some reason it must have been behind
<ackk> sorry for the noise, it seems it works then
<zyga> it's a fixed number, maybe we should test with latest instead?
<ackk> zyga, ^
<ackk> zyga, pedronis thanks
<zyga> ackk: woot :)
<pedronis> ackk: no you have a default track, so --edge is 2.7/edge
<pedronis> if you want latest you need install --channel=latest/edge
<mup> PR snapd#8766 closed: daemon: fix filtering of service-control changes for snap.app <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8766>
<ackk> pedronis, ah, right! that always tricks me :)
<pedronis> zyga: I would prefer that we land #8759 and #8691 with some final scaffolding in it first though
<mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<zyga> oh, I forgot about that entirely
 * zyga looks now
<pedronis> zyga: also we need to add TESTTOOLS to debian/tests/integrationtests
<pedronis> TESTSTOOLS
<pedronis> or autopkgtests might get broken
<zyga> pedronis: good point, I'll check that
<zyga> pedronis: any specific reason for [[ ]] over regular [ ] ?
<pedronis> it was used already for something
 * zyga Hmm, we only use it for the regexp matching behavior.
<pedronis> if not super consistent
<pedronis> we are not super consistent
<pedronis> if [[ -d ./mnt ]]
<zyga> pedronis: would you mind if I push a change to convert the additions to [ ] ?
<zyga> I really like [[ but I prefer to use it only when ther'es no simpler alternative, mainly to remove the "why is this used" question
<pedronis> zyga: yes, mostly because it has consumed already too many spread cycles
<pedronis> it can be changed later
<zyga> ok
<zyga> I'll bundle that in the next PR with tool changes
<pedronis> zyga: which changes are you doing in that new PR?
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8759/files#r432582187
<mup> PR #8759: tests: move *-tool tests to their own suite <Created by pedronis> <https://github.com/snapcore/snapd/pull/8759>
<zyga> pedronis: moving tools to tests/lib/tools, adding symlinks to tests/bin, renaming each tool one by one, removing compatibility hacks
<zyga> pedronis: that question I linked to above is the only thing I'd like to understand before approving
<pedronis> zyga: I answered
<pedronis> zyga: cleanup-state is a bit too new to know a final answer
<zyga> ok
<zyga> +1
<mup> PR snapd#8760 closed: systemd: rename actualFsTypeAndMountOptions to hostFsTypeAndMountOptions <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8760>
<zyga> let's merge when it's green
<pedronis> zyga: related to your wip PR, I'll try to do mimimal things then in #8691, just create the dirs, and change spead.yaml (and integration tests)
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<pedronis> I still would like for it to land first
<zyga> the readme PR?
<pedronis> yes
<zyga> yeah, LGTM!
<zyga> it's a draft
<zyga> please open it for review
<zyga> with the TODO merged we can chop parts off it in each commit
<zyga> maybe mvo can just merge it
<zyga> there's no point in testing it
<zyga> mvo: ^ could you please merge https://github.com/snapcore/snapd/pull/8691
<mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<mvo> zyga: sure
<zyga> super
<zyga> thanks!
<mvo> zyga: should it be promoted to "ready for review" at least?
<mvo> zyga: it's still draft
<zyga> yeah, I think pedronis should do that
<pedronis> mvo: please don't merge it
<zyga> oh?
<mvo> pedronis: set it to blocked
<pedronis> as I said I want to do some things in it
<zyga> ah, I missed that
<zyga> ok, in that case I'll review it again when it's open
 * zyga EODs and goes for a walk
<Saviq> humpf
<Saviq> https://travis-ci.com/github/MirServer/mir/jobs/341502620#L247
<Saviq> All snaps up to date.; try to update snapd and refresh the core snap
 * cachio lunch
<ijohnson> jdstrand: thanks for the review on #8724, so to be clear you are now requesting I add all of the accesses, changes, etc. requested by you there to block-devices? or should I still be adding a nvme-control interface ?
<mup> PR #8724: interfaces/block_devices: add NVMe subsystem devices, support multipath paths <Needs security review> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8724>
<jdstrand> ijohnson: the former
<ijohnson> jdstrand: sounds good thanks
<jdstrand> ijohnson: but a description change is in order to mention something about controller devices
<ijohnson> right
<jdstrand> ijohnson: well, maybe not 'description' like with 'snap interface block-devices', but definitely a code comment above the description and a policy comment
<ijohnson> sure
<jdstrand> ijohnson: the idea is that these controller devices allow manipulating the block devices that we want to expose, so grouping them together makes sense. we don't group partitions since we determined a separate interface (raw-volume) is a nice place to split the policy
<ijohnson> jdstrand: yes that all makes sense, I'll try to update that this afternoon I think
<jdstrand> (manipulating a raw device (and its controller) is a significantly different operation than manipulating an individual partition)
<jdstrand> ijohnson|lunch: cool thanks!
<jdstrand> ijohnson|lunch: sorry that it wasn't clear. I had a strong conviction and then convinced myself I was wrong
<jdstrand> :)
<ijohnson|lunch> jdstrand: haha yes I know the feeling quite well
<mup> PR snapd#8771 closed: bootloader/ubootenv: don't panic with an empty uboot env <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8771>
<mup> PR snapd#8762 closed: snap-bootstrap: remove sealed key file on reinstall <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8762>
<mvo> quick eyeball on 8772 would be great
<mup> PR snapd#8772 opened: snap-bootstrap: remove sealed key file on reinstall (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8772>
<pedronis> mvo: +1
<mvo> pedronis: thank you!
<pedronis> we are getting mountinfo differences again :/
<mvo> oh no
<pedronis> 2020-05-29T18:07:04.4844746Z -+0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw,nsdelegate
<pedronis> 2020-05-29T18:07:04.4845221Z ++0:+1 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime shared:+1 - cgroup2 cgroup rw
<pedronis> on 18.04
<mvo> meh, I hope zyga has time to have a look
<mup> PR snapd#8772 closed: snap-bootstrap: remove sealed key file on reinstall (2.45) <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8772>
 * cachio afk
<mup> PR snapd#8759 closed: tests: move *-tool tests to their own suite <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8759>
<cmatsuoka> cachio: got a new error in opensuse: https://github.com/snapcore/snapd/pull/8591/checks?check_run_id=721480264
<mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Needs Samuele review> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
<cachio> cmatsuoka, checking
<pedronis> cmatsuoka: I forgot to mention, I will get to review #8591 on Tuesday
<cachio> cmatsuoka, it is new
<cachio> I'll research it
<cachio> thanks for the info
<cmatsuoka> pedronis: ok, thanks
<mup> PR snapcraft#3149 opened: elf: search dynamic tags within sections, not segment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3149>
#snappy 2020-05-30
<imi> hi
<imi> I've just removed an app that was installed from a snap and it removed my user data from my home as well. I want the userdata back
<ogra> snapd should have taken a snapshot of your data before removing the app ... re-install it and you should be able to restore the snapshot (see "snap help")
<imi> ok, that particular snap isn't available anymore. can I restore the data by hand? (ubuntu 19.10)
<ogra> dunno, check with the commands the help gives you for managing snapshots
