#snappy 2015-11-30
<dholbach> good morning
<ogra_> mvo, Chipaca, do you guys know if we expose the package version somewhere in the environment of snap services/binaries (i.e. how would my app know it has just been upgraded)
<ogra_> i think we need some mechanism to make the package know when it needs to run any confi migration scripts
<ogra_> *config
<mvo> ogra_: it should be available via SNAP_VERSION
<ogra_> ah, thanks !
<mvo> ogra_: hm, there was discussion about providing a native hook for this from snappy itself
<JamesTait> Good morning all; happy Monday, and happy Computer Security Day! ð
<ogra_> yeah, that would be cool ... but for the moment i can use that var ... (just updating a stamp file and compare on service start)
<ogra_> geez, "snappy build" is amazingly slow o armhf :/
<ogra_> *on
<ogra_> 11min for a package that takes 2min to build on amd64
<longsleep> Is /writable/cache somehow used on boot again? I see some service duplication and the only location where the old service file exits is in /writable/cache/system
<ogra_> it should be readonly mounted after boot ... but nothing else
<ogra_> /writable/cache/system that is
<longsleep> ogra_: yes it is mounted ro there, but something seems to copy all the files in there on boot
<longsleep> ogra_: could that be?
<ogra_> i dont think so
<ogra_> it is your "other" readonly partition
<longsleep> right - this is very strange
<longsleep> i delete a file from /etc/systemd/service and disable the service with systemctl as well, reboot then it is there again
<ogra_> probably some generator ?
<ogra_> though even that should respect that you disabled it
<longsleep> the service comes from a snap - snap is still installed as newer version
<longsleep> the version the service gets generated for is not on the disk - at least i cannot find it
<longsleep> i see the issue for more than one snap though. It seems like when a builtin snap is updated, the systemd service of the version which is oem is recreated on boot for unknown reason
<ogra_> that sounds definitely like a bug
<longsleep> ogra_: yeah, though i was unable to figure out how that even happens yet
<longsleep> so, before reboot the service was only in /writable/cache/system/etc/systemd/system, after reboot it is in /etc/systemd/system - so something must copy it
<ogra_> longsleep, i guess the issue is that it is in /writable/cache/system/etc/systemd/system at all ...
<ogra_> thats a readonly system ... no snap should be able to put anything there ever
<longsleep> ogra_: true, but those are put there by u-d-f i think
<longsleep> ogra_: the snaps are preinstalled with the oem snap
<ogra_> hmm, sounds wrong to me to put them in the readonly partition
<longsleep> yeah, they will never go away
<longsleep> i would be fine with that, but how are they cloned on boot?
<longsleep> i mean that causes the problem after all
<longsleep> ogra_: i think it is synced in the initrd
<ogra_> longsleep, i wouldnt see how
<longsleep> ogra_: well, there is some code in the ubuntu-core-rootfs of the initrd which does some copying
<ogra_> yes
<longsleep> ogra_: maybe i use ancient version again
<ogra_> one sec
<ogra_> bah, i was hoping for a wrong setting in /etc/system-image/writable-paths ... but seems the cache path is actually hardcoded
<ogra_> hmm, k ...
<ogra_> the initrd doesnt mount it at all
<ogra_>         if [ -n "$other" ]; then
<ogra_>                 echo "$other /writable/cache/system auto defaults,ro 0 0" >> "$fstab"
<ogra_>         fi
<longsleep> right
<ogra_> thats all it does ... right before run-init
<ogra_> so if there is any syncing thats not happening in the initrd
<longsleep> maybe it runs into one of the other conditions which do cp -A
<longsleep> i mean the file ending up in /etc/systemd/system has the same timestamp as the one in /writable/cache/system/etc/systemd/system
<ogra_> well, there must be some systemd unit that copies it
<ogra_> when processing fstab
<longsleep> ok let me check if i can find something there
<longsleep> ogra_: well, i could not find it and now i even removed the file from /writable/cache/system/ and it still gets recreated magically in /etc/systemd/system
 * longsleep has no idea where it comes from
<fgimenez> hi Chipaca, have a minute?
<dholbach> mvo, can you (or somebody else) help with https://code.launchpad.net/~jdstrand/click-reviewers-tools/click-reviewers-tools.snappy1604/+merge/278218?
<ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Starting minidlna DLNA server...
<ogra_> Nov 30 13:44:32 aleph2 ubuntu-core-launcher[26252]: /apps/upnp-server-amd64.sideload/IGccOWeCMeET/minidlnad: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /apps/upnp-server-amd64.sideload/IGccOWeCMeET/usr/lib/x86_64-linux-gnu/libsnappy.so.1)
<ogra_> Nov 30 13:44:32 aleph2 systemd[1]: Reloading.
<ogra_> woah
<Chipaca> jdstrand_: tyhicks: ping about snapd and ACLs
<Chipaca> well, not ACLs, but permissions on the unix socket and SO_PEERCRED
<mvo> dholbach: I have a look after the meeting, thanks
<longsleep> Chipaca: Hey, maybe you can help me in finding the script which creates snappy systemd services in /etc/systemd/system/ on boot. I have the problem that a service keeps appearing there while that snap version is not installed
<mvo> longsleep: do you install something that has a service duing your u-d-f run?
<longsleep> mvo: yes
<longsleep> mvo: the oem snap has several snaps as built-in
<mvo> longsleep: I think there is a bug in u-d-f
<longsleep> mvo: when updating those, the old systemd service gets not removed and recreated on boot
<longsleep> mvo: yeah that makes sense, though where does u-d-f store the information so the service can actually be recreated
<dholbach> mvo, cool, thanks
<ogra_> jdstrand_, is the chwon blocking really necessary given we cant actually chown anything outside of the writable area of the snap anyway ? i have massive probs with it atm trying to package something that uses two services which both call fchown/fchown32
<tyhicks> Chipaca: hey - I need some more context as I don't know if I've heard anything about that yet
<Chipaca> tyhicks: you probably haven't :)
<Chipaca> tyhicks: you remember snapd, the snappy daemon that runs as root, that you connect to over a unix socket?
<tyhicks> Chipaca: yep
<Chipaca> tyhicks: that socket is 0600 root:root right now
<Chipaca> tyhicks: wanting to relax that so regular users can connect
<Chipaca> tyhicks: so, server uses SO_PEERCREDS on the socket to determine uid, deny access to privileged ops to non-privileged users
<tyhicks> ok
<Chipaca> tyhicks: would like you or jamie to go over what/how we're doing that before actually lowering the 0600
<tyhicks> Chipaca: is there a MP?
<Chipaca> tyhicks: the code that does SO_PEERCRED is already in master
<Chipaca> tyhicks: 1 sec and i'll point you at the relevant file itself
<Chipaca> tyhicks: https://github.com/ubuntu-core/snappy/blob/master/daemon/ucrednet.go
<tyhicks> Chipaca: ack, I should be able to have a look in a day or two
<Chipaca> tyhicks: that's the wrapper that knows about SO_PEERCRED and uses it to get the uid for unix connections
<tyhicks> (maybe today)
<Chipaca> tyhicks: and then https://github.com/ubuntu-core/snappy/blob/master/daemon/daemon.go#L67 checks things before allowing access
<tyhicks> ok
<Chipaca> tyhicks: it's a rather hackish first pass that stuffs the uid in the RemoteAddr of the transfer, but modulo that it seems sane to me
<Chipaca> transport*
<Chipaca> tyhicks: yeh, no hurry
<Chipaca> well, no hurry beyond the usual :-)
<rickspencer3> mvo, can you please give me a link to the correct rolling image for rpi2 if I want to install and test 16.04 rolling?
 * rickspencer3 notes the web site still points (correctly, I think) to 15.04
<mvo> rickspencer3: we don't have a pre-build xenial image right now (unless ogra_ did some for rpi2). you can use ubuntu-device-flash to build an image. maybe it would be a good idea to make a snapshot available for easier testing
<rickspencer3> ack
<longsleep> so, what other tool on a snappy system can create systemd services for snaps? I still have not found the reason why old services keep appearing on boot. They are not generated by /usr/bin/snappy :/
<Chipaca> longsleep: what are the files that won't die?
<ogra_> mvo, no, i didnt, i would like us to eventually produce whole images for xenial in an automated way though
<ogra_> s/for xenial//
<longsleep> Chipaca: i have snaps with services installed via oem built-in - when those get updated everything seems fine. But on reboot the service files reappear in /etc/systemd/system/
<longsleep> Chipaca: i have looked and looked but seem unable to find out how these files are generated / where they come from :/
<Chipaca> longsleep: you mean you have a snap that you include from oem, that in an update removes a service? or is it services for old versions that appear?
<longsleep> Chipaca: spreedbox-led_ledd_0.0.9-4.service is the new service, spreedbox-led_gnatsd_0.0.6-1.service the old. spreedbox-led_gnatsd_0.0.6-1.service is removed after update. Then reboot and spreedbox-led_gnatsd_0.0.6-1.service is there again
<longsleep> Chipaca: it is the same problem for all services installed via oem
<longsleep> Chipaca: on update, the old service gets removed fine. Then reboot and it is back (and fails to start)
<longsleep> Chipaca: what troubles me is that i seem to be unable to figure out where it comes from
<Chipaca> longsleep: could i see the output of 'sudo journalctl' on a reboot with these things happening?
<Chipaca> longsleep: firstboot is the thing that might be doing that, but it shouldn't be running
<longsleep> Chipaca: sure
<Chipaca> and ... yeah, it doesn't make sense
<longsleep> Chipaca: it says started firstboot setup every time
<longsleep> let me check when i remove the firstboot stamp and run it manually
<longsleep> Chipaca: no, removing the stamp and running snappy firstboot did not create the service file again
<Chipaca> phew
<longsleep> Chipaca: i have a patched version of snappy, which adds a custom X- header to the service file when snappy generates it, for the file which keeps reappearing it does not have that header
 * Chipaca looks up phone numbers of exorcists
<longsleep> Chipaca: it is either copied from some place or created from some other tool
<Chipaca> longsleep: ooh, nice
<Chipaca> ogra_: pingu
<ogra_> yo yo
<Chipaca> ogra_: is there anything in initrd/early boot that could be copying a service file?
<ogra_> no
<ogra_> hmm
<ogra_> well
<longsleep> It also needs to copy it from some place, i have removed all locations below /writable where that file could be found
 * ogra_ checks something
<Chipaca> longsleep: can you mount and see if it's in /etc *under* writable?
<longsleep> Chipaca: mount what exactly?
<Chipaca> longsleep: umm... system-a? partition #3 iirc
<Chipaca> longsleep: on a brand new image
<longsleep> Chipaca: sure - hold on
<Chipaca> longsleep: (or on a booted one, really)
<longsleep> Chipaca: brand new booted one - without upgrading?
<Chipaca> longsleep: yep
<longsleep> Chipaca: flashing now, takes 70 seconds
<Chipaca> longsleep: ok. just mounting the image locally would also work :-)
<longsleep> Chipaca: that would not be booted though
<Chipaca> ah, sorry i meant booting it or not shouldn't make a difference to that partition
<Chipaca> although, having said that, if it _did_ make a difference that'd be interesting in and of itself
<ogra_> Chipaca, so the entry for /etc/systemd/system in /etc/system-image/writable-paths is "synced none none" so yes, content from the readonly fs will be synced on boot
<longsleep> ah
<ogra_> and etc gets processed from initrd
<ogra_> (remember, we had to move it because of races)
<longsleep> finally the mystery solved!
<ogra_> well, the bug is that fragments from snaps are on the readonly partition
<ogra_> that shouldnt be
<longsleep> /media/longsleep/system-a/etc/systemd/system/spreedbox-led_gnatsd_0.0.6-1.service
<longsleep> that is the non booted image
<ogra_> right
<Chipaca> so the bug is that those are getting created by snappy during the u-d-f unpack/install thing
<ogra_> yeah
<ogra_> they would have to go into the writable space
<longsleep> i see - so this needs fixing in u-d-f
<ogra_> since they are from snaps :)
<Chipaca> longsleep: in snappy, actually
<ogra_> (all of the snaps shuld go into the writable space in fact)
<longsleep> Chipaca: right
<Chipaca> (u-d-f calls into snappy)
<longsleep> Chipaca: so add a flag or something, similar to the existing ones
<Chipaca> yep
<Chipaca> flag already exists
<Chipaca> InhibitHooks
<ogra_> Chipaca, but if udf doesnt set up the mounting in a way that the snap bits land in writable places you have lost
<ogra_> not necessarily a snappy bug imho
<Chipaca> ogra_: the service files should not be created at udf time; firstboot creates them
<longsleep> that would be easy to fix
<longsleep> so for testing, i could remove the snap services from system-a and then do a boot
<longsleep> right?
<Chipaca> longsleep: yep
 * longsleep gives it a try
<ogra_> Chipaca, aha ... nontheless, snap fragments should not live in the readonly rootfs
<ogra_> and i assume there is no "boot" happening when udf assembles the img ... whihc means if you do anything chrooted in the img you wont have the mountpoints set up
<ogra_> (i can be wrong indeed ... just guessing)
<longsleep> well, i removed the service files before firstboot, but firstboot did not create them
<longsleep> Chipaca: yeah not installing the services in u-d-f is bad as they are not created again and update fails as the service is not loaded
<Chipaca> :'-(
 * Chipaca forgot how to emoticon
<longsleep> Where do you want to have the bug for this? github snappy or udf on launchpad?
<Chipaca> sergiusens: mvo: ping
<Chipaca> longsleep: gimme a sec
<Chipaca> so the easy way would be to hack udf to set things up properly
<Chipaca> i think a better way would be to make snappy not activate anything from udf, and instead add that to firstboot (which i thought was one of the things oemconfig was doing anyway)
<Chipaca> but there might be a reason not to do it this way
<longsleep> Chipaca: yeah, i guess we can do that and somehow move the things to writable
<Chipaca> hence me pinging mvo and sergiusens :-)
<Chipaca> longsleep: writable is there at udf time, just needs bind-mounting properly (or things moved to the right place post hoc, which is tricky because of random cruft in /etc/systemd/system (that shouldn't be there anyway (but I digress)))
<ogra_> +1 for firstboot, that is where it belongs
<longsleep> Chipaca: so the other cruft in there should stay readonly ?
<longsleep> ogra_: yes, though that is unlikely to happen for 15.04 right?
<ogra_> yeah, for that the hack might be a better approach
<sergiusens> Chipaca, the plan is to move it to firstboot
<sergiusens> Chipaca, if you care to create the PR for it, great ;-)
<ogra_> the PR ?
<sergiusens> ogra_, pull request
<ogra_> event planning ? cheerleaders, free food and flyers ? as in public relations ?
<ogra_> aahh !
<sergiusens> Chipaca, in any case, I'd prefer if the image creator just dropped the snaps (except kernel and os) into a defined location and firstboot do its thing
<ogra_> +1
<ogra_> isnt that what we do on the phone ?
<ogra_> (for custom tarballs)
<ogra_> jdstrand, i assume you missed my ping from this morning ?
<sergiusens> ogra_, no; sadly no
<sergiusens> unless it changed recently
<ogra_> oh, i thought we did
<ogra_> we really should :)
<Chipaca> sergiusens: for 15.04 also?
<mvo> Chipaca: sorry, I was in a meeting - so I think the issue that longsleep is seeing is fixed with something like http://bazaar.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/revision/226
<mvo> Chipaca: but I think that your idea of installing them on first boot is better, however this won't work for the OS snap (as it needs to be ready for first-boot)
<Chipaca> no no
<mvo> no?
<Chipaca> my idea was *activating* them on first boot
<Chipaca> not installing them
<Chipaca> in squashfs world that might be the same thing tho :-)
<Chipaca> but in 15.04 having the unpack done at build time, and the activation at first boot, seems sane and should be easily doable
<Chipaca> but i don't know if we want to, and if there is going to be a release of this
<Chipaca> hence, calling you
<ogra_> well, we didnt stop doing monthlies for 15.04, did we ?
<ogra_> to have the images pick up -security and -updates
 * Chipaca waits for mvo to confirm that
<longsleep> Chipaca: to hack it, where exactly do the files need to go on the writable partition? i see a system-data folder there
<longsleep> Chipaca: create etc/systemd/system in there ?
<mvo> Chipaca: ups, sorry. indeed, this does make sense. I'm not sure if/when we do a 15.04 release though either, maybe worth bringing up at the next standup?
<mvo> longsleep, Chipaca: I need to run very soon to play hockey, however I'm happy to discuss this further tonight/tomorrow
<ogra_> mvo, we'll need to sit down tomorrow too to talk about allsnaps and the build system
<Chipaca> i'll look at getting a branch up with this
<Chipaca> also, we need to get edge working on arm again
<mvo> ogra_: sure
<Chipaca> and plan the next monthly 1504 (which i think we've slipped, unless time has done its usually stretchy snappy thing)
<mvo> Chipaca: yeah, no idea about the test failure right now :/ still need to investigate on a porter machine
<longsleep> mvo: sure, i think i understood the problem and might figure out a hack for now - but it would be awesome if there would be a fix for 15.04
<Chipaca> mvo: blame ogra_, then he'll fix it :-p
<longsleep> mvo: also this one would be nice on https://github.com/ubuntu-core/snappy/issues/189 - we have patched it locally but i guess others might have the issue as well
<ogra_> Chipaca, heh, ask davmor2 ... that only works sometimes
<Chipaca> longsleep: i can't be sure offhand. easiest way would be to see on upgraded machine what /writable looks like
<longsleep> Chipaca: good idea thanks
<mvo> longsleep: aa, nice
<davmor2> ogra_: no it works all the time, you just go blame the right person :D
<longsleep> sync
<longsleep> ups :)
<rickspencer3> ogra_, are there steps I can follow to make a rolling 16.04 rpi2 image today?
<Chipaca> rickspencer3: u-d-f doesn't work?
<rickspencer3> Chipaca, I did not say that, I was looking for documentation
<rickspencer3> :)
<ogra_> rickspencer3, once sec i can give you a cmdline (the rpi pÃ¼age needs updating for that)
<longsleep> Chipaca: ok i got scripting which fixes the problem: http://paste.ubuntu.com/13579233/
<longsleep> Chipaca: i think i can add that as a post process step to our image builder
<ogra_> rickspencer3, sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
<ogra_> (sorry, i had not forotten you :) )
<ogra_> (and ignore the moaning about azure :) )
<jdstrand> Chipaca: hey, fyi, going through old irc (I was on holiday last week). I updated /usr/share/apparmor/easyprof/policygroups/ubuntu-core/15.04/snapd to have /run/snapd.socket in 15.04.12~ppa12 on Nov 13. I looks like stable hasn't been updated since then
<Chipaca> jdstrand: a'yup
<Chipaca> jdstrand: welcome back to the world of the living, and all that
 * rickspencer3 tries
<Chipaca> ogra_: unless you've uploaded a pi2 since the channels work, that needs to be pi2.canonical/stable
<ogra_> Chipaca, really ? udf cares ?
<Chipaca> no, it doesn't care, which is why that works :-)
<ogra_> ah :)
<Chipaca> it's just passing that on to the CPI REST API
<ogra_> rickspencer3, ^^
<Chipaca> and CPI cares. In fact that's all it cares about ;-)
<Chipaca> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
<Chipaca> ^ seems to work
<rickspencer3> oh
<Chipaca> that /stable is a temporary workaround until we get things into the edge channel itself
 * rickspencer3 tries again ;)
 * rickspencer3 happily kicks off his "azure" image
<rickspencer3> ogra_, Chipaca seemed like it downloaded the parts and built the image quite quickly
 * rickspencer3 prepares to dd
<ogra_> good
<rickspencer3> ogra_, just dd it to sbx as per usual, right?
<ogra_> yeah
<ogra_> all the same for all images :)
 * rickspencer3 dds and waits
<Chipaca> http://people.canonical.com/~john/wow-so-peercred-much-access-levels.gif btw
<Chipaca> tyhicks: ^ might be relevant (or not)
<tyhicks> Chipaca: that's showing that the access checks aren't working as expected?
<Chipaca> tyhicks: no, it's showing that they are
<tyhicks> ah, right
<Chipaca> tyhicks: in retrospect i should have paused before hitting enter on 'sudo !!'
<Chipaca> assuming that is what tripped you up :)
<tyhicks> opening up the socket to be world read/write today means that root is still required
<tyhicks> yes, I think that is what tripped me up
<Chipaca> tyhicks: root is still required <- for privileged operations you mean?
<sandGorgon> hey guys... is there a snappy based ISO that I can try out and play with ? I'm looking at http://cdimage.ubuntu.com/daily-live/current/xenial-desktop-amd64.iso but dont know if it is intended with dpkg or snappy
<Chipaca> sandGorgon: not an ISO. What are you wanting to play _on_?
<tyhicks> Chipaca: yes - your gif is showing that root is required for privileged operations even though anyone can write to the socket - correct?
<Chipaca> tyhicks: correct
<tyhicks> got it
<sergiusens> elopio, do you feel good about releaseing current master as 0.6?
<Chipaca> tyhicks: didn't create the gif just for you, but thought it might be useful for you as well
<Chipaca> sandGorgon: the snaps you can download from https://developer.ubuntu.com/en/snappy/start/ work in kvm, or you can dd them onto a sd card or usb stick and boot off of that
<sandGorgon> Chipaca, this may sound stupid... but there were all these articles that mentioned that the next version of ubuntu will have a snappy-based flavor . so I was wondering if there were any builds of a desktop version with snappy.
<Chipaca> sandGorgon: no, it does not sound stupid
<tyhicks> Chipaca: it will be helpful - thanks!
<Chipaca> sandGorgon: but things might have been lost in translation / repetition, as as far as I know there isn't a plan to have a snappy desktop version, but to be able to use snappy on the desktop, which is not quite the same
<Chipaca> sandGorgon: i don't know how far along those plans are, though
<sandGorgon> Chipaca, "Ubuntu 16.04 LTS will be able to run Snappy packages
<sandGorgon> Will Cooke, the Ubuntu Desktop lead, announced during a Unity 7 discussion at the Ubuntu Online Summit that they are working to bring Snappy packages to the regular Ubuntu flavor, with Unity 7."
<sandGorgon> I was wondering if I could start playing with it on the desktop... but maybe I'm jumping in too early. my bad... I can wait ;)
<lotuspsychje> sandGorgon: install xenial development branch and apt-cache search snappy
<lotuspsychje> and start fool around
<Chipaca> sandGorgon: yes, snappy packages, but not a snappy system
<sandGorgon> lotuspsychje, will do ;)
<lotuspsychje> sandGorgon: ive also tested unity8 on xenial
<lotuspsychje> sandGorgon: also early stage now, so it looks pretty much like the phone version
<sandGorgon> lotuspsychje, oh.. is it usable ?
<lotuspsychje> sandGorgon: yes, mouse support, browsing
<sandGorgon> lotuspsychje, ah ok.. i'll survive probably (P.S. im more of a gnome guy)
<lotuspsychje> sandGorgon: then test the ubuntu-gnome xenial development branch
<sandGorgon> lotuspsychje, that's what's downloading right now
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/127
<jdstrand> sergiusens: catching up on irc backscroll from holiday
<jdstrand> < sergiusens> Chipaca, 2015/11/24 08:43:59.067839 security.go:205: [sc-filtergen --include-policy-dir=/var/lib/snappy/seccomp --policy-vendor=ubuntu-core --policy-version=15.04 --template=network-status --policy-groups=networking] failed
<jdstrand> sergiusens: you probably figured this out, but --template=network-status is wrong. the template is 'default' (ie, unspecified) and you should use caps: [ network-client, network-status ]
<sergiusens> jdstrand, I haven't looked too much into it, it is just related to https://bugs.launchpad.net/snapcraft/+bug/1519251
<ubottu> Launchpad bug 1519251 in Snapcraft "Step copying .snap during 'snapcraft run' fails" [Undecided,Incomplete]
<jdstrand> sergiusens: based on the sc-filtergen denial, the package yaml is using 'security-template: network-status'. It shouldn't do that
<jdstrand> s/denial/error/
<jdstrand> Chipaca: fyi, I see in backscroll you pinged me about snapd and ACLs and that tyhicks responded. I will leave that topic to the two of you them
<tyhicks> jdstrand: yes, I'm going to review the code
<tyhicks> (card already created)
<jdstrand> ogra_: re chown for services-- you mentioned massive problems. what are the problems? what are they chowning to? there is nothing they can legitimately chown to other than root, which is the user
<jdstrand> ogra_: but to more simply answer your question-- it is a valid point that you need write access to the file to chown it. therefore, it makes some sense to allow these syscalls since apparmor blocks the file access
<jdstrand> ogra_: however, we did not allow all of chown yet because we didn't understand the scope of issues at first and because, again, nothing valid to chown to
<jdstrand> ogra_: couple that with seccomp arg filtering that we will hopefully have for 16.04. with that we'll say you can chown to 'root' for example (probably fixing your issue but in a different way), but disallow chown to 'nobody' or 'www-data'. if we decide to allow per-app user ids, we'd allow chown to that too
<jdstrand> ogra_: but I didn't want to open the floodgates on that just yet, cause apps might hardcode things and do odd stuff, changing ownership to invalid things which might cause unexpected interactions
<jdstrand> so proceeding with caution there. but as mentioned, the seccomp arg filtering alone will likely fix the obstacle you are facing
<jdstrand> (with the accompanying policy updates)
<jdstrand> tyhicks: thanks
<ogra_> jdstrand, well, lighttpd and sqlite both only use fchown when they are run as root to chown files to the right UIDs ...
<ogra_> and as it happens i'm just assembling something that uses both :)
<jdstrand> ogra_: yeah, I talked about sqlite in snappy-app-devel-- I think we should probably patch it. lighthttpd is doing the exact same thing or chowning to some other user?
<ogra_> ("to the right UIDs" typically to the UIDs defined in the config file)
<jdstrand> what are you putting in that config file?
<jdstrand> we don't have per-app user ids yet (see mailing list)
<ogra_> well, i'm not really clear what lighttpd does, i cant find any trace of "chown" in the source
<ogra_> i indeed dont put a user into that config file ... interesting fact is that lighttpd doesnt complain about fchown on amd64
<jdstrand> ogra_: is this a xenial system?
<ogra_> amd64 is 15.04 edge ... armhf is xenial edge
<jdstrand> ogra_: on the xenial system, you can do the security-override method to unblock you while you investigate. eg:
<jdstrand> services:
<jdstrand>   - name: foo
<jdstrand>     security-override:
<ogra_> i use lighttpd's webdav module ... i guess that links in some sqlite stuff or so
<jdstrand>       syscalls: [ fchown32, chown, ... ]
<jdstrand> perhaps
<jdstrand> and sqlite is doing the chown to root unconditionally to root
<ogra_> yeah, i had that working at some point (and then threw everything away and started to patch the apps :P )
<ogra_> right
<ogra_> so it is just a pointless syscall
<ogra_> but it is as pointless that we block it imho
<jdstrand> well, I don't know about that
<ogra_> given you cant chown anything outside of your confinement
<jdstrand> I mentioned interactions
<ogra_> jdstrand, btw, one thing that struck me ... how do we protect maintainers/developers from spp vulnerabilities ... i mean ... my https runs as root ... since i need to mangle the config it lives in $SNAP_APP_DATA_PATH ... where also my webroot needs to live ... if there is an issue with the webserver someone can just later my config remotely
<ogra_> s/spp/app/
<ogra_> s/later/alter/
<ogra_> i was wondering if there is any way to protect us from such things
<jdstrand> ogra_: snappy doesn't help with that. if there is a vulnerability in the app itself and it can scribble out to files, it could overwrite its configuaration, db files, etc. I mentioned this in my email on user ids-- this is one reason to support them
<ogra_> oh, so you want to do some extrausers magic on a per-snap base ?
<jdstrand> the easiest thing we can do which everyone already understands is allow for opt-in app ids
<jdstrand> eg (and this is otoh, not designed or talked about beyond that thread and a couple of conversations):
<jdstrand> services:
<jdstrand> wait
<jdstrand> name: foo
<jdstrand> services:
<jdstrand>   - name: bar
<jdstrand>     app-user: true
<jdstrand> then on install, that create the foo_bar user
<jdstrand> creates
<ogra_> hmm
<jdstrand> that is a sort of 'system' user in that it is passwordless, etc
<jdstrand> then the seccomp policy allows chowning to that user, etc
<jdstrand> there are other ways to do that
<jdstrand> but the basic idea is come up with something that namespaces the users to the package name
<ogra_> i wonder if we couldnt teach libnss-extrausers to accept something like a passwd.d/ dir where snaps could drop their snippets
<jdstrand> s/snaps/snappy install/ :)
<ogra_> :)
<jdstrand> app-user: true might be artificially limiting. perhaps a single service wants more than one app user. perhaps the users shouldn't be tied to the service at all, etc
<jdstrand> anyway, those are the types of things to work out. I think there are some pretty good reasons for supporting them (see email thread) based on dev input
<ogra_> right
<jdstrand> maybe this is something we can discuss at the upcoming sprint if there is time
<ogra_> the feb. one you mean ? yeah
<jdstrand> no, the one I am going to next week :)
<ogra_> ah
<jdstrand> but sometime this cycle, sure
<jdstrand> beuno, pindonga: hey, when is the next scheduled store rollout? I have a big merge to the review tools for all snaps that I'd rather get in sooner this week or wait until after next (and continue with manual reviews until then)
<jdstrand> beuno, pindonga: basically, I don't want it hitting on the weekend or while I am sprinting in case I need to react quickly to something
<ogra_> jdstrand, oh, btw ... if i put the above into my snapcraft.yaml i get
<ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
<ogra_> seems security-override wants an apparmor line too
<jdstrand> ogra_: I think snapcraft needs to be updated for the new 16.04 yaml
<jdstrand> sergiusens: I mentioned this elsewhere, but fyi ^
<jdstrand> ogra_: oh, is that click review tools?
<jdstrand> ogra_: yes, there is an MP about to land for that
<ogra_> might be ... i get it on "snapcaft clean"
<jdstrand> ogra_: can you paste the output?
<ogra_> well, that was all output
<ogra_> root@localhost:/upnp-server# snapcraft clean
<ogra_> Issues while validating snapcraft.yaml: 'apparmor' is a required property
<ogra_> root@localhost:/upnp-server#
<jdstrand> sergiusens: fyi, not sure if snapcraft needs to be updated or not (just fyi)
<jdstrand> that sounds like it does
<ogra_> yeah
 * ogra_ still doesnt get why lighttpd behaves different on armhf vs amd64 ... there is no fchown32 call on amd64 it seems 
<jdstrand> yeah, there will be different syscalls between those
<ogra_> well, different, sure ... but having the call on one arch and not on the other ?
<jdstrand> fchown and fchown32 are maybe what you need
<jdstrand> yeah, that is common
<jdstrand> or at least, not uncommon
<ogra_> really ?
<ogra_> wow
<jdstrand> I didn't know that either til having to look at all these
<ogra_> oh man
 * ogra_ slaps forehead 
<ogra_> so i was seeing the syscall issue on armhf but not on amd64 ... because my snapcraft.yaml has a copy plugin that copies libsqlite to usr/lib/x86_64-linux-gnu ...
 * ogra_ blushes
#snappy 2015-12-01
<Chipaca> ogra_: noice
<dholbach> good morning
<fgimenez> good morning
<mvo> hey fgimenez, good morning!
<mvo> ogra_: this armhf build failure is quite annoying, it takes forever to run the tests on a porter box
<fgimenez> hi mvo!
<fgimenez> mvo, btw with the new cloud resources in place we should redirect the github webhook, let me know when you have a minute and i'll send you the new ip
<mvo> fgimenez: sure, I have a minute
<mvo> fgimenez: trying to figure out an armhf build failure right now
<fgimenez> mvo, once i finish fixing the snapd integration tests we should have green builds, i'll fire up builds every 15 minutes to check
<mvo> fgimenez: sweet. and then we can add a user that leaves comments too, right?
<fgimenez> mvo, yep, we should create a new github user and add it to the organization as collaborator, then add its credentials to jenkins, and that's it :)
<Chipaca> jdstrand: could we add 'less' to the list of things we can exec when confined?
<JamesTait> Good morning all! Happy Giving Tuesday, and happy Bifocals at the Monitor Liberation Day! ð
<Chipaca> JamesTait: monitors had a liberation day, and bifocals were present, and it was an event that needs commemorating?
<Chipaca> JamesTait: the mind is boggled
<JamesTait> Chipaca, it's a tribute to those poor souls who wear bifocals and use a monitor daily, and keep bobbing their heads up and down trying to figure out which lens to use.
<Chipaca> yeah. fear that day.
<Chipaca> i wouldn't be able to look at the monitor with my head tilted, letting ideas settle around the clot
<Chipaca> longsleep: ping
<longsleep> Chipaca: pong
<longsleep> Chipaca: i added a hack to u-d-f, moving the services to writable - i know it is crappy but works for now http://paste.ubuntu.com/13597040/
<Chipaca> longsleep: heh. i'm working on that right now (on the snappy side)
<Chipaca> broke all the tests of course
<longsleep> Chipaca: you are moving the stuff to first boot now?
<Chipaca> longsleep: the ping was to ask you for your oem package.yaml, if that was shareable
<Chipaca> longsleep: yes
<longsleep> Chipaca: ok good
<Chipaca> longsleep: making install not activate from u-d-f (u-d-f passes in a particular flag), then making firstboot activate them
<longsleep> Chipaca: uhm sure i can share the oem snap, though the snaps are not in the store
<Chipaca> yep, no worries about that
<Chipaca> and feel free to munge the names if they are sensitive
<longsleep> Chipaca: http://paste.ubuntu.com/13597081/
<Chipaca> just looking for a real-world example, as what i've got access to is either too bare, or theoretical
<Chipaca> perfect
<longsleep> Chipaca: yeah, this is what we currently use
<pindonga> jdstrand, hi there, there is no schedule... which revno do you want to release? I'll do my best to get it out asap
<fgimenez> hi Chipaca, ive got a question about http.chipaca
<Chipaca> fgimenez: shoot
<fgimenez> Chipaca, it doesn't let me send files http://paste.ubuntu.com/13597723/, am i doing it right?
<fgimenez> Chipaca, this is the response with debug enabled http://paste.ubuntu.com/13597757/
<Chipaca> fgimenez: it can't read /tmp/pp, because it'll have its own private /tmp
<Chipaca> fgimenez: two questions:
<Chipaca> fgimenez: first, what's in /tmp/pp?
<fgimenez> Chipaca, nothing, just touched it for trying, the real test tries to use a snap file from ADT_ARTIFACTS, under /tmp
<fgimenez> Chipaca, i can try to move it to wherever http needs
<Chipaca> fgimenez: would `cat /tmp/pp | sudo http.POST snapd:///1.0/packages` work?
<Chipaca> otherwise, put it under $SNAP_APP_DATA_PATH
<Chipaca> i.e., /var/lib/apps/http.chipaca/current/
<fgimenez> Chipaca, yep, works fine :) ok, i'll try putting it there, thanks!
<Chipaca> pipes are easy from the shell, but tricky in a test, so
<fgimenez> Chipaca, is it also possible to pass http a json string literal, as in http://paste.ubuntu.com/13600302/ ?
<Chipaca> fgimenez: yes, but
<Chipaca> fgimenez: https://github.com/jkbrzt/httpie#request-items
<Chipaca> fgimenez: so in particular for doing a multi-config PUT,
<Chipaca> gah. gimme a bit.
<jdstrand> Chipaca: re less, sure
<Chipaca> jdstrand: whee :-)
<jdstrand> Chipaca: when do you need it?
<Chipaca> jdstrand: less has exec-this-other-thing, but that'll just fail because confinement, right?
<Chipaca> jdstrand: no hurry, backburner project needs it (or me reimplementing a pager in python ;-) )
<jdstrand> Chipaca: it will fail to exec the other thing, yes
 * Chipaca will run it with that feature disable, because usability++, but still
<Chipaca> fgimenez: sudo http.PUT snapd:///1.0/packages 'ubuntu-core.ubuntu:="config: {ubuntu-core: {autoupdate: true}}"'
<Chipaca> fgimenez: note the quotes in the quotes
<dholbach> sergiusens, so you're landing 0.6 soon? :)
<Chipaca> fgimenez: the thing on the right of the := is a json string literal (hence the double quotes there). Of YAML.
<sergiusens> dholbach, yeah
<Chipaca> not the nicest of things, but Â¯\_(ã)_/Â¯
<sergiusens> jdstrand, is there a cap I can use for capname="net_admin" on 15.04?
<fgimenez> Chipaca, great, in my case 'ubuntu-core.ubuntu:="config: {basic-config.sideload: {key: value}}"' prevents the 400 and creates the operation, i'll put that into the test, thanks!
<Chipaca> ummm
<Chipaca> fgimenez: that should kinda not work
<Chipaca> that is, the operation should fail
<Chipaca> because ubuntu-core.ubuntu mismatch with basic-config.sideload
<dholbach> sergiusens, awesome :)
<Chipaca> fgimenez: (yes, config is redundant like that; needs revamp)
<fgimenez> Chipaca, yes i'm getting "invalid ubuntu-core configuration", ok, then 'basic-config.sideload:="config: {basic-config.sideload: {key: value}}"', right?
<elopio> plars: are you here?
<plars> elopio: sort of, feeling pretty sick today. What's up?
<fgimenez> Chipaca, yes, that works fine, thanks :)
<elopio> plars: I need your help to collect the SPI output. But I can wait, lets talk tomorrow, get some rest.
<elopio> plars: I hope you get better soon.
<Chipaca> fgimenez: \o/ :)
<jdstrand> sergiusens: yes. either network-admin or network-firewall
<sergiusens> jdstrand, thanks
<jdstrand> sergiusens: are you aware of 'sudo snappy-debug.security scanlog' :)
<jdstrand> ?
<plars> elopio: no, it's fine. was this from a job that just ran?
<sergiusens> jdstrand, I wasn't, no I am :-)
<elopio> plars: latest ran yesterday midnight. Want me to run another one?
<jdstrand> Chipaca: ok, you are getting less{,file,pipe} and more
<Chipaca> jdstrand: whee :-)
<elopio> mvo: do you have time to talk about the godd snap?
<plars> elopio: I think I found it, one sec
<sergiusens> jdstrand, are all three suggestions to be followed? http://paste.ubuntu.com/13600633/
<jdstrand> sergiusens: no. pick one
<sergiusens> jdstrand, I already put network-admin in there, which is why I ask
<jdstrand> sergiusens: is that a new denial or a previous denial?
<sergiusens> jdstrand, it is a fresh boot
<jdstrand> sergiusens: I'm guessing that /var/lib/snappy/seccomp/profiles/gopaste.sideload_... doesn't reflect the change
<mvo> elopio: yes
<plars> elopio: https://pastebin.canonical.com/145186/plain/
<jdstrand> sergiusens: or it didn't at the time it started
<Chipaca> mvo: Kalnischkiesfile
<jdstrand> sergiusens: check if setsockopt is in /var/lib/snappy/seccomp/profiles/gopaste.sideload_...
<Chipaca> mvo: in https://mvogt.wordpress.com/2015/11/30/apt-1-1-released/ in english
<sergiusens> jdstrand, it is not
<plars> elopio: that seems to be all that came through
<jdstrand> sergiusens: how did you install the snap?
<sergiusens> jdstrand, `snapcraft run` :-)
<elopio> plars: so it's running! but being killed.
<mvo> Chipaca: hm? did I misspell something somewhere?
<mvo> Chipaca: in that blog post?
<Chipaca> mvo: yes
<Chipaca> mvo: I don't know if it's misspelt; it's just not very englishy
<plars> elopio: kick off another one and I'll see if it does anything different
<jdstrand> sergiusens: what is in the generated meta/package.yaml on the device?
<elopio> mvo: I hw-assigned /dev/null to the snapp but I am still getting:
<elopio> godd.godd
<elopio> /apps/godd.sideload/current/godd_1.0_amd64.snap /dev/null
<elopio> failed to dd: open /proc/self/mountinfo: permission denied
<elopio> what else should I give to the snap to be able to run the bin?
<sergiusens> jdstrand, http://paste.ubuntu.com/13600718/ this file looks strange though
<mvo> Chipaca: haha now I see what you mean, this is actually kind of funny
<elopio> plars: triggered.
<jdstrand> sergiusens: what is the version of ubuntu-core-security-seccomp on the device?
<mvo> elopio: hm, can you he-assign /proc/self/mountinfo? just for fun and testing?
<mvo> elopio: it needs this to prevent you from shooting yourself in the food
<sergiusens> jdstrand, hah, hard to know given the dpkg cache is wiped
<sergiusens> mvo, do you know? ^
<mvo> elopio: I think for this to be a proper snap it needs a customized appamor profile, i.e. it needs to be able to write to /dev/** by default
<mvo> sergiusens: latest rolling? I can check on the builds. or what version of the image do you use?
<sergiusens> mvo, 15.04 stable
<mvo> sergiusens: we have the dpkg info on 15.04 :)
<jdstrand> sergiusens: acutally, that shouldn't matter. snappy-debug.security looks at what is installed on the device and if it is suggesting network-admin, then network-admin should have it
<sergiusens> mvo, oh right
<jdstrand> sergiusens: how does snapcraft run work? is it just doing a snappy install of a generated snap or is it doing something else?
<sergiusens> jdstrand, it scp's the snap and installs it
<jdstrand> sergiusens: can you give me the snap?
<sergiusens> jdstrand, with `snappy install`
<sergiusens> jdstrand, sure
<sergiusens> jdstrand, http://people.canonical.com/~sergiusens/snappy/gopaste_1.0_amd64.snap
<elopio> mvo: I can't hw-assign mountinfo. It says invalid hardware device.
<jdstrand> sergiusens: btw, you are almost certainly hitting https://bugs.launchpad.net/snappy/+bug/1465724 and don't actually need network-admin
<ubottu> Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed]
<mvo> elopio: aha, indeed, there is a check for this
<jdstrand> (snappy-debug.security should mention that, but you ran it after you added the cap I think)
<mvo> elopio: hm, then we need to update the security profile of this to make it work on snappy itself. whats you use-case (just curious)?
<elopio> mvo: there is a godd snap in the snapcraft examples. I want to run the binary and check the output.
<Chipaca> jdstrand: is /proc/self/mountinfo unreadable for a reason?
<sergiusens> jdstrand, for every snap I build I restart the vm though
 * Chipaca is not trying to ddos jdstrand 
<sergiusens> unless the log persists, which I think it doesn't, it shouldn't be the root cause
<sergiusens> mvo, we just want the examples in snapcraft to actually run and not just build ;-)
<jdstrand> Chipaca: yes, it is an information leak
<Chipaca> aww
<jdstrand> sergiusens: I can confirm this. it is a bug in snappy-debug.security
<Chipaca> mvo: so i guess godd needs fixing to not need that
<sergiusens> jdstrand, how so?
<jdstrand> sergiusens: it is suggesting network-admin and network-admin doesn't have setsockopt
<jdstrand> sergiusens: use network-service or network-client
<sergiusens> jdstrand, ah, thanks; will try and report back
<mvo> sergiusens, elopio: let me look at this
<jdstrand> oh heh
<jdstrand> silly bug
<jdstrand> fix is easy. here is the output:
<jdstrand> Syscall: setsockopt
<jdstrand> Suggestions:
<jdstrand> * add 'setsockopt' to seccomp policy
<jdstrand> * add one of 'network-client, network-firewall, network-service' to 'caps'
<jdstrand> * add 'setsockopt' to seccomp file in 'security-policy'
<elopio> thanks mvo
<jdstrand> sergiusens: ^
<sergiusens> jdstrand, yay, no I have a defunct process, let's see why :-)
<plars> elopio: my bbb tests on rolling seem to be failing since last week when I was away also. Looks like the last one that passed was 237
<plars> elopio: well, maybe... that one might be a fluke. Out of curiosity, do you have it saving your output to a location that you cleanup? or is it still a tmpdir?
<elopio> plars: I'm using the pwd to put the resulting files, and mktemp -d to get the code. I delete the temp dir on exit.
<mvo> elopio, sergiusens: sorry, looks like I can not easily fix it, snapcraft does not understand the new security-override syntax it seems
<sergiusens> jdstrand, oh goodie, I now ran into the sqlite fchown issue ;-)
<mvo> sergiusens: it appears that https://github.com/mvo5/godd/commit/38dfb37c34db7c1314ee1fe6a730c53565de9914 is making snapcraft unhappy
<sergiusens> jdstrand, is that going to be allowed soon or should I fix it in the snap
<jdstrand> how is it that everything is using sqlite all of a sudden...
<plars> elopio: well, there was no output from it that time, and the dir has already been cleaned up so I can't see anything useful from it
<elopio> mvo: oh, I was thinking this was a bad snapcraft example because it wasn't showing anything useful. But now with the security override it's interesting.
<jdstrand> sergiusens: it should be fixed in the snap or someone should fix it in the archive
<plars> elopio: all I can see is that it exited with rc=1
<sergiusens> mvo, notice that this version of snapcraft does not play nice at all with 16.04 syntax
<elopio> plars: but looking at this output you pasted, it seems that something is killing my script, right?
<plars> elopio: not unless you are, or it times out and spi is killing it or something
<plars> elopio: that last one exited with the same rc
<elopio> sergiusens: we need to support pinning, to keep the sources in a known good version.
<plars> elopio: it's possible that I just don't have *all* the output. Getting output from the script this way is not really the best. It's more intended for logging messages from provisioning rather than as a debugging tool for your scripts
<elopio> plars: hum, that's possible. There is a lot of output.
<sergiusens> elopio, you can pin with source-tag, source-branch to some extent
<sergiusens> mvo, you seem to be using 16.04 syntax
<jdstrand> sergiusens: fyi, snappy-debug 0.7 fixes the issue and is in the store
<plars> elopio: have you tried running this from a bbb locally to make sure it works?
<elopio> plars: yes.
<elopio> I have made many tiny changes trying to collect some output, so I will try again. But it's great news to see that the tests are starting.
<sergiusens> jdstrand, so for fchown it is not going to be allowed and I need to fix it with a security.override?
<sergiusens> s/./-/
<fgimenez> elopio, it seems that we don't have access to the store (or the internet for that matter) from the instances http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/10/consoleFull
<elopio> plars: the troubling situation is that this should be bullet proof now. It doesn't have -e, so it won't stop the execution on failure. And I do  > "$pwd"/output.txt 2>&1 which should collect any possible error.
<elopio> that's where I'm lost. I don't understand why I get no output at all.
<fgimenez> elopio, Get https://system-image.ubuntu.com//ubuntu-core/rolling/edge/generic_amd64/index.json: dial tcp 91.189.88.142:443: i/o timeout
<jdstrand> tyhicks: hey, so, chown seems to be coming up all the time now
<elopio> fgimenez: yes, I bet the scalingstack firewall is too strick. We need it open for a lot of things. Would they get mad if we just ask to remove it? :)
<mvo> sergiusens: is that bad :) ?
<tyhicks> jdstrand: chown to what?
<mvo> sergiusens: aha, ok. I see that it is bad, I will use a different syntax
<plars> elopio: let me take a look
<sergiusens> mvo, no, it just won't work
<ogra_> sergiusens, is that sqlite ?
<jdstrand> tyhicks: like, 4 times in a week. our stance has been that we won't allow it until we have per-app uids
<sergiusens> ogra_, yes
<ogra_> sergiusens, if so, i have a patch ;)
<tyhicks> jdstrand: right
<jdstrand> tyhicks: sqlite is doing a superfluous chown
<plars> elopio: what do you get on the spi side? do you get your results json uploaded there?
<jdstrand> tyhicks: chown root:root /path/to/db
<ogra_> jdstrand, it isnt actually superfluous
<jdstrand> tyhicks: and it is getting killed
<elopio> plars: no. empty result_payload
<jdstrand> ogra_: it is, cause the db is already root:root
<ogra_> jdstrand, it does that to make sure the db file matches the master file ... with the UID the master file was created with
<fgimenez> elopio, :) with 91.189.88.142:443 will do for now IMO, we are just accessing the store?
<ogra_> so it is valuable in non-snappy
<jdstrand> and the master file will be root:root
<elopio> fgimenez: aren't we accessing also docker servers?
<jdstrand> I understand the non-snappy case and why they are doing it
<ogra_> but since it tries to chown to a user thats not you usually it only does that when run as root
<jdstrand> I'm talking about the snappy case, it is superflous because it does the chown unconditionally whether it needs it or not
<ogra_> right
<jdstrand> anyway
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/130
<jdstrand> tyhicks: so all of a sudden everyone is hot on sqlite
<fgimenez> elopio, no, that's from canonistack, where the infra lives. the instances just need the store
<jdstrand> tyhicks: and I'm getting pings left and right on this
<elopio> fgimenez: great. Then yes, please make an RT to request opening the firewall to the store.
<jdstrand> tyhicks: I've suggested we fix sqlite in the archive so that it does the chown conditionally
<ogra_> sergiusens, http://paste.ubuntu.com/13601278/
<jdstrand> tyhicks: but that hasn't happened yet and that doesn't fix vivid and doesn't fix something else that might do the same
<ogra_> sergiusens, for the upstream sqlite tarball ...
<mvo> elopio: ok, can you try now? I updated the git tree to use the unconfined template
<ogra_> sergiusens, or just pull the binaries out of my upnp-server packages if you are lazy ;)
<sergiusens> ogra_, I am lazier, a lot lazier
<jdstrand> tyhicks: I've been thinking that when we have syscall arg filtering, we will allow 'chown 0' (or whatever the syntax) in addition to 'chown 12345' for per-app, if/when we do that
<elopio> mvo: trying.
<ogra_> (after all you only need the sqlite3 executable and the lib)
<ogra_> sergiusens, bah
<ogra_> hacking security ! so evil :P
<jdstrand> tyhicks: per-app aside, when we have syscall arg filtering, the 'chown 0' one would fix sqlite
<jdstrand> tyhicks: but that won't happen until after the new year
<plars> elopio: ok, there seem to be some garbage characters in the output. I wonder if that's why things are getting a bit messed up. It's definitely failing though
<plars> elopio: https://pastebin.canonical.com/145191/
<jdstrand> tyhicks: on rolling, there is the saying things can break at any time
<jdstrand> tyhicks: I've been reluctant to allow chown in the seccomp policy since that opens the floodgates to all uids, only to reign it in again later and potentially break stuff
<jdstrand> tyhicks: but maybe that is actually ok for 16.04
<jdstrand> tyhicks: and 15.04 is simply what it is
<elopio> mvo: still permission denied on mountinfo.
<elopio> now I didn't have to hw-assign /dev/null
<jdstrand> tyhicks: more clearly-- what do you think of me adding chown family to 16.04 policy now with a TODO to adjust when seccomp arg filtering exists?
<tyhicks> jdstrand: if an app can chown in its data directory, what does that mean for this policy:
<tyhicks>   # Writable home area for this version.
<tyhicks>   owner @{HOMEDIRS}/*/apps/@{APP_PKGNAME}/@{APP_VERSION}/   w,
<tyhicks>   owner @{HOMEDIRS}/*/apps/@{APP_PKGNAME}/@{APP_VERSION}/** wl,
<plars> elopio: here's the json it spits out for spi to get, which is not valid and would probably fail for several reasons: http://paste.ubuntu.com/13601335/
<tyhicks> jdstrand: do we drop owner?
<mvo> elopio: hm, thats confusing, let me dive deeper
<elopio> plars: right. Let me pastebinit.
<tyhicks> jdstrand: that's from the default template
<jdstrand> yes, I recognize the rule
 * tyhicks is trying to think through what it means to allow chown
<jdstrand> fyi, this is exactly the sort of thing I have been saying could cause unintended interactions
<jdstrand> and hence my reluctance
 * tyhicks agrees
<jdstrand> tyhicks: that rule is actually terribly problematic, but that is another story
<elopio> mvo: this is not urgent. I'm just trying to make sense of the examples.
<jdstrand> tyhicks: the launcher is really not smart about that directory and will create ~/apps/... as the root user
<mvo> elopio: hm, my latest git seems to work in my snappy now, what git revno is the one you have?
<jdstrand> and then running stuff as non-root is broken
<mvo> elopio: just did "snapcraft assemble --force" and copied it to a snappy system
<jdstrand> but that is another issue (there is a bug for that)
<elopio> mvo: 6901dc912162b05fa381ead0e6d344152a68bbe9
<jdstrand> I think we *must* keep the owner checks there
<elopio> I did snapcraft clean and snapcraft. Copied it to 15.04 stable #10.
<tyhicks> jdstrand: I guess sqlite is not chowning files in that directory?
<jdstrand> tyhicks: it is doing it in /var/lib/apps
<tyhicks> ah
<mvo> elopio: thanks, let me try that too. the version looks correct
<jdstrand> well, I'm assuming. everyone is talking about services
<jdstrand> and the services should be using SNAP_APP_DATA_PATH
<jdstrand> not SNAP_APP_USER_DATA_PATH
<sergiusens> jdstrand, correct
<sergiusens> mvo, elopio we use git upstream, but our example tree has its own snapcraft.yaml
<jdstrand> tyhicks: adding the chown now would mean that an app could perform a DoS on the SNAP_APP_USER_DATA_PATH
<jdstrand> tyhicks: but I think that will be true when we add 'chown 0'
<jdstrand> hrm
 * sergiusens will bbl
<tyhicks> jdstrand: but that DoS is only for itself
<tyhicks> jdstrand: it wouldn't affect other snaps
<jdstrand> for itself but for another user
<tyhicks> oh, right
<tyhicks> that's a problem
<ogra_> doesnt the launch wrapper prevent you from that ?
<jdstrand> that will be true of 'chown 0' and 'chown 12345' too though
<jdstrand> when we have syscall arg filtering
<ogra_> (how would you mangle SNAP_APP_USER_DATA_PATH to be for another user ? )
<ogra_> (given the launcher will set it after you touched it)
<tyhicks> ogra_: a malicious app doesn't have to use SNAP_APP_USER_DATA_PATH, it would be able to chown any path it chooses
<ogra_> ah
<jdstrand> ogra_: you wouldn't-- but you can read /etc/passwd (necessarily) to get the paths of other users
<ogra_> well, /var/lib/extrausers/passwd but yeah, i get what you mean :)
<ogra_> (/etc7passwd is rather useless)
<jdstrand> right. both are readable in the default policy (they must be)
<ogra_> yeah
<tyhicks> jdstrand: I think that I need some more time to think about this
<jdstrand> tyhicks: I think to properly support @{HOME} with chown we need fine-grained mediation of chown in apparmor and something more than 'owner', or a kernel side var to expand @{HOME} in some manner
<jdstrand> tyhicks: I agree. this is the sort of thing I have been saying is problematic with chown
<jdstrand> ogra_, sergiusens: I'm fairly certain we aren't going to just add chown to the policy any time soon. we may be able to fix it this cycle. I suggest someone update sqlite in the archive to make the check conditional
<jdstrand> tyhicks: fyi ^
<ogra_> well, i'm just using upstreams tarball now ...
<ogra_> would be nice if snapcraft had a concept of patching though ... so i dont need to build in two steps
<jdstrand> most people will surely opt to snapcraft the deb though, no?
<ogra_> yeah
<ogra_> well my hackish patch from above is definitely not suited for the package
<Chipaca> jdstrand: tyhicks: so we need to change things so that SNAP_APP_USER_DATA_PATH is under the home of the effective user, right?
<ogra_> (it blindly just rips out all chown calls)
<Chipaca> ogra_: using ld_preload?
<ogra_> Chipaca, for what ?
<Chipaca> ogra_: for ripping out the chown calls
<Chipaca> well, replacing them
<jdstrand> not for sqlite
<ogra_> well, sqlite consiste of two binary files ... i just drop them in the right place with the copy plugin
<tyhicks> Chipaca: he patched out the calls to chown(2)
<ogra_> usually i have some debs involved so i get the wrapper setup that gives me LD_PRELOAD anyway
<ogra_> but having to patch the code means i need to build it separately from the snapcraft run
<jdstrand> Chipaca: the problem with the launcher is that $HOME of the real user is being used for the euid of 0 under sudo
<Chipaca> jdstrand: yes
<jdstrand> Chipaca: which is why we get root owned dirs in $HOME
<Chipaca> yes
<jdstrand> this isn't about fixing all that, though that is an incredibly annoying bug
<Chipaca> http.chipaca comes up against this a bit
<Chipaca> do you know the bug number offhand?
<jdstrand> let me find the bug
<Chipaca> heh
<jdstrand> I'll find it
<jdstrand> https://bugs.launchpad.net/snappy/+bug/1466234
<ubottu> Launchpad bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged]
<jdstrand> Chipaca: ^
<jdstrand> tedg suggests in comment #2 that we shouldn't set SNAP_APP_USER_DATA_PATH for root
<Chipaca> yes, but agreed with setting it because there are valid reasons for using it
<tedg> Root isn't a user :-)
<jdstrand> Chipaca: that is one idea. someone told me to not include /root in the policy, which is why we don't now. another option is setting SNAP_APP_USER_DATA_PATH to SNAP_APP_DATA_PATH
<Chipaca> wrt stgraber, I suspect this was running as root, not with sudo
<jdstrand> when running as root
<jdstrand> Chipaca: I think the lxc command is a binary in the lxd package
 * jdstrand checks
<jdstrand> Chipaca: yes, it is. so he used 'sudo lxc' at the time
<jdstrand> plus, only the launcher does the mkdir, not the services (unless they wrote the service to do it)
<jdstrand> well, actually, scratch that
<jdstrand> I forgot for a moment the luancher is used by the systemd service
<jdstrand> so, from a traditional security perspective, it is probably wrong to have a process running under sudo to read files from the real user's home directory, so the current behavior of setting SNAP_APP_USER_DATA_PATH to the real user's home is wrong
<jdstrand> tyhicks: what do you think? ^ (different topic from chown-- looking at 1466234 now)
<tyhicks> just a minute - I'm in a meeting
<jdstrand> oh, I'm supposed to be in that meeting
<jdstrand> actually, I'm optional there
<tyhicks> jdstrand: it just ended
<tyhicks> jdstrand: yes, I dislike the idea of root mucking with files in the user's home dir
<jdstrand> me too
<jdstrand> Chipaca: ^
<tyhicks> jdstrand: with chmod being allowed now, there's nothing stopping services from dropping setuid root binaries in a user's home dir :/
<jdstrand> Chipaca: I think the choice is to either not set SNAP_APP_USER_DATA_PATH when running as root or set it to SNAP_APP_DATA_PATH
<Chipaca> jdstrand: not to /root/apps/yadda/yadda?
<jdstrand> well, that is another choice, yes. I was explictly told *not* to allow that, and I asked in the bug for why, and got no response
<jdstrand> asac: hey, do you recall why we didn't want to allow the launcher to create /root/apps/pkgname/version ?
<jdstrand> mvo: do you? ^
<ogra_> is /root writable ?
<jdstrand> it is these days
<ogra_> ah, i see
<jdstrand> it is in /etc/system-image/writable-paths
<jdstrand> it may not have always been
<ogra_> yeah, i think it hasnt in the past
<jdstrand> I don't know how this would fit into all snaps either
<elopio> plars: can you check once again, please?
<plars> elopio: http://paste.ubuntu.com/13602227/
<elopio> plars: nice!
<elopio> now I don't understand why the payload is still empty, but things are improving.
<elopio> plars: can you please install the subunit package?
<plars> elopio: done
<elopio> thanks
<sergiusens> elopio, can you check my last comment on https://github.com/ubuntu-core/snapcraft/pull/130
<elopio> sergiusens: how could it be running on 80 if you are calling it with 8080}
<elopio> ?
<elopio> I don't get a defunct service.
<sergiusens> elopio, just run `sudo netstat -putan` (as a spanish speaker it is hard to forget those netstat switches :-P)
<sergiusens> elopio, I might have messed up the flags, that is why I ask ;-)
<elopio> sergiusens: it's not in 80, nor in 8080. But snappy service status says it's active and running.
<sergiusens> elopio, snappy service is wrong; check `ps -ef|grep gopaste`
<kyrofa> sergiusens, pretty sure they're order independent :P
<elopio> sergiusens: yes, defunct.
<elopio> sergiusens: I agree that it's better than before, fwiw.
<jdstrand> Chipaca: ok, typos aside, I laid everything out in https://bugs.launchpad.net/snappy/+bug/1466234/comments/6
<ubottu> Launchpad bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged]
<sergiusens> elopio, let's merge this then and I'll think of how to get sqlite working
<sergiusens> kyrofa, they are; but you know how it goes :-)
<jdstrand> Chipaca: I requested an architect comment, so hopefully we can get a direction on the bug
<jdstrand> Chipaca: one problem with /root/apps is upgrades/roolbacks
<Chipaca> jdstrand: why?
<sergiusens> elopio, ok, I'm preparing the changelog again
<sergiusens> Chipaca, btw, if a service goes defunct, systemd/snappy still think it is in a good state
<sergiusens> we are probably missing a service toggle
<Chipaca> sergiusens: depends how it goes defunct
<Chipaca> sergiusens: as per the table in systemd.unit
<Chipaca> sorry, no, systemd.service
<sergiusens> Chipaca, oh, it sort of just gives up on living due to the jail apparmor and seccomp created for it
<Chipaca> sergiusens: man systemd.service, look for 'table 1'
<sergiusens> :-)
<elopio> our examples are depressed :(
<ogra_> elopio, no worries, we'll give them free psycotherapy vouchers
<elopio> we need an eliza snap :)
<ogra_> +1 !
 * ogra_ actually wants two and have them play nethack against each other ;)
<kgunn> hey sergiusens, getting an error with snapcraft
<kgunn> https://pastebin.canonical.com/145201/
<kgunn> what's strange, is...i'm pretty sure this worked and i got a snap with no errors...
<kgunn> so not really sure what happened..
<sergiusens> kgunn, oh, 0.6 fixes that and I am releasing right now
<ogra_> kgunn, i get that when i crate a file like "config.sh" with no content
<ogra_> (i.e. no shebang)
<sergiusens> kgunn, if in a hurry git clone https://github.com/ubuntu-core/snapcraft.git
<sergiusens> kgunn, then $PATH_TO_SNAPCRAFT_GIT/bin/snapcraft
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/127
<elopio> sergiusens: go for it. And hopefully no 0.7 branch anytime soon.
 * Chipaca suddenly realises there's a hole in the cloud, and strikes it rich by offering "service as a service"
<Chipaca> sergiusens: btw, snapcraft is still broken wrt things not in the first plane
<Chipaca> sergiusens: because pyyaml is broken that way
<sergiusens> Chipaca, you talking about encoding I guess
<Chipaca> sergiusens: yes
<Chipaca> sergiusens: just saw you close bug 1518150
<ubottu> bug 1518150 in Snapcraft "A Chinese character in the snapcraft.yaml crashes the snapcraft" [High,Fix committed] https://launchpad.net/bugs/1518150
<sergiusens> Chipaca, shouldn't that work?
<Chipaca> sergiusens: here, try: ð ¡
<sergiusens> Chipaca, hah, xchat is also broken :P
<Chipaca> sergiusens: hit ctrl+shift+u, then type 20021, then hit enter or space
<sergiusens> Chipaca, the particular bug report is fixed though
<sergiusens> Chipaca, I just downloaded the snapcraft.yaml from librarian and tried
<Chipaca> sergiusens: ok. But there's a lot of cjk codepoints, not all of them in the first plane
<sergiusens> Chipaca, yeah, that is broken
<Chipaca> sergiusens: and pyyaml incorrectly reports things in higher planes as "special characters"
<sergiusens> Chipaca, yeah, seems like it
<sergiusens> Chipaca, I'll add a task for pyyaml on l
<sergiusens> lp
<Chipaca> it's broken in some subtle way; the spec says some codepoints are not allowed, and these characters utf8 starts with the byte sequence that corresponds to those characters codepoints
<Chipaca> i.e. this character in utf8 is 0xF0 0xA0 0x80 0xA1
<Chipaca> *codepoint* 0xF0 is invalid
<Chipaca> no, wait, that's wrong also
<Chipaca> "The allowed character range explicitly excludes the surrogate block #xD800-#xDFFF, DEL #x7F, the C0 control block #x0-#x1F (except for #x9, #xA, and #xD), the C1 control block #x80-#x9F, #xFFFE, and #xFFFF."
<Chipaca> I have no idea why it thinks U+20021, 0xF0 0xA0 0x80 0xA1, is invalid
<sergiusens> Chipaca, care to add that to the bug?
<Chipaca> point me at the bug
<sergiusens> Chipaca, https://bugs.launchpad.net/ubuntu/+source/pyyaml/+bug/1518150
<ubottu> Launchpad bug 1518150 in pyyaml (Ubuntu) "A Chinese character in the snapcraft.yaml crashes the snapcraft" [Undecided,New]
<Chipaca> and i'll paste random facts at it until somebody fixes it :-p
<sergiusens> Chipaca, yeah, lets just bug barry ;-)
 * barry hides
<Chipaca> barry: sergiusens: there, https://bugs.launchpad.net/snapcraft/+bug/1518150/comments/9
<ubottu> Launchpad bug 1518150 in pyyaml (Ubuntu) "A Chinese character in the snapcraft.yaml crashes the snapcraft" [Undecided,New]
<barry> Chipaca: i'll look later.  i'm on a deep bug hunt right now
<Chipaca> barry: yeh, i don't think this is urgent, but it'll byte somebody at some point :-)
<sergiusens> barry, you took too long, the bugs now hunt and HAUNT you ;-)
<barry> sergiusens: bugception
<Chipaca> ok, stopping now. barry, if i write a patch for this thing, should it be against xenial, or upstream?
<barry> Chipaca: i don't know upstream too well, but if the xenial version is equiv to latest upstream, probably xenial will be fine (as quilt patch) and i'll submit it upstream
<jdstrand> Chipaca: re why> /home/$user/apps/... is (presumably) already handled by upgrades and rollbacks since it was always in the design. /root is not (currently) integrated into that, but would have to be if we supported /root/apps
<jdstrand> Chipaca: it isn't that it can't be done, it is whether or not it should be done
<elopio> look plars, we have output again! :) http://paste.ubuntu.com/13602944/
<elopio> thanks, without you I would have never noticed it was because of the subunit binary.
<plars> elopio: great! I'll add subunit to the list of dependencies to deploy
<jdstrand> Chipaca: fyi, I'll have the /root fix for apparmor in a little bits
<jdstrand> bit*
<mvo> jdstrand: I don't know why /root/apps/pkgname/version is not allowed, sorry
<jdstrand> mvo: that's fine. there are now actionable items in the bug report. I'm fixing the apparmor bits now. it sounds like Chipaca may be interested in the change to wrapper generation
<jdstrand> mvo: are we doing anything special with upgrades and rollbacks with $HOME?
<jdstrand> mvo: cause if so, will need to do it for /roots/apps too
<mvo> jdstrand: I need to look, I don't think so, but worth checking
<Chipaca> mvo: jdstrand: on upgrade we copy the home datadir over
<jdstrand> mvo: uh oh
<Chipaca> mvo: jdstrand but it's easy to fix to also copy the root datadir
<jdstrand> mvo: ImportError: No module named 'LibAppArmor'
<jdstrand> mvo: when did we drop python3-apparmor?
<mvo> jdstrand: where do you see that
<mvo> jdstrand: on the image? I don't think we did drop that intentionally
<jdstrand> mvo: sorry, python3-libapparmor
<jdstrand> mvo: snappy-debug.security scanlog
<mvo> jdstrand: hm, I can have a look tomorrow why but I'm pretty sure this did not happen on purpose
<jdstrand> mvo: this then gets into the question of how big do we want snappy-debug to be
<jdstrand> mvo: maybe I should just add it back to the seed and then we can discuss at a later date?
<mvo> jdstrand: +1
<sergiusens> elopio, kyrofa I've created https://github.com/ubuntu-core/snapcraft/tree/2.x
<kyrofa> sergiusens, why not create the stable 1.0 and use master for 2.0 development?
<sergiusens> kyrofa, I have thought about that; if we don't change documentation for the time being that could be good
<sergiusens> kyrofa, btw, 1.x or 1.0?
<kyrofa> sergiusens, ah, right, 1.x. But good point about the documentation
<sergiusens> kyrofa, they auto pull from master; I thought I'd work on 2.x for a bit and then do some swapping
<kyrofa> sergiusens, good call
 * sergiusens heads to aikido practice
<Chipaca> barry: so, i've got a fix for pyyaml, but i'm not sure how to add tests to it -- the test suite is rather intractable for driveby fixes
<Chipaca> barry: and 'tis tricky to give you a diff without this being in some kind of ... something :-)
<barry> Chipaca: i've never looked at the code.  maybe there's an upstream repo somewhere?
<Chipaca> barry: subversion
 * barry has a sad
<Chipaca> i guess i'll file a bug and do the patch upstream
<Chipaca> um, the trac seems to be readonly, or i've forgotten how to use it
<barry> Chipaca: yep.  we can always add the patch to quilt for ubuntu and/or debian
<barry> you might need to be logged in
<Chipaca> http://pyyaml.org/report
<Chipaca> sigh
<barry> yeah, it sucks that all these tracs are silos
<Chipaca> barry: are short unicode builds still a thing?
<barry> Chipaca: not in python3 anymore
<Chipaca> barry: and 2.7?
<barry> Chipaca: yes in 2.7
<barry> but who cares about 2.7? <wink>
<Chipaca> barry: do you remember what maxunicode was in a short unicode build?
<barry> Chipaca: i don't remember.  i could probably figure it out if needed
<Chipaca> barry: nm, got it
<barry> ah cool
<Chipaca> 65535
<barry> makes sense!
<Chipaca> and that's the max unicode as far as pyyaml is concerned
<Chipaca> anything higher than that and it barfs
<barry> even in a wide build?
<Chipaca> barry: yes, it explicitly checks
<Chipaca> barry: the spec says "the following are not allowed [list of codepoints]"
<Chipaca> barry: pyyaml negated that list against a non-wide build, and uses that regexp to check
<barry> Chipaca: ah
<Chipaca> anyway, got a quilt patch. now what :)
<barry> Chipaca: probably best to open a bug on the debian package and either attach the quilt patch to that, or attach a debdiff.  this is a DPMT maintained package, so i am happy to take a look and shepherd the patch through debian (which should autosync to xenial)
<Chipaca> barry: to use debdiff i'd have to add a changelog and get a fresh .dsc, right?
<barry> Chipaca: yep, but i'm happy to do that work if you have a bug # and a quilt patch
<Chipaca> ok, i'll go with that :)
<Chipaca> barry: bug 806826
<ubottu> bug 442941 in ubiquity (Ubuntu Oneiric) "duplicate for #806826 debconf failed to upgrade from 1.5.27ubuntu1 to 1.5.27ubuntu2: exit status 128 - Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66" [High,Fix released] https://launchpad.net/bugs/442941
<barry> Chipaca: got it
<Chipaca> ubottu: lulz
<barry> debian bug 806826
<ubottu> Debian bug 806826 in src:pyyaml "pyyaml does not support literals in unicode over codepoint 0xffff" [Normal,Open] http://bugs.debian.org/806826
<barry> :)
<Chipaca> barry: and I managed not to mention U+1F4A9 in the whole report!
<Chipaca> I must be growing up
<barry> :)
<barry> Chipaca: i see what you mean about the test suite.  the patch would be better with tests, but if none of the existing tests regress and you vouch that it fixes your problem, that'll have to be good enough.
<Chipaca> I tried adding to the tests, and something completely nonrelated failed, so i gave up
<Chipaca> the test is easy: yaml.load("\N{PILE OF POO}")
<Chipaca> does it explode? y/n :)
<barry> Chipaca: cool.  at the very least i can add a dep-8 test for that
<Chipaca> barry: dep-8?
<barry> Chipaca: autopkgtests
<Chipaca> cool
<Chipaca> barry: well, yaml.dump() of the same should also give the same, fwiw
<barry> Chipaca: hmm, that doesn't fail for me with the unpatched pyyaml (neither does the yaml.load() with py2.7)
<barry> Chipaca: this does though: python3 -c "import yaml; yaml.load('\N{PILE OF POO}')"
<Chipaca> barry: no, it doesn't fail, but it prints "\U0001F4A9"
<barry> Chipaca: what should it print?
<Chipaca> print(yaml.dump("\N{PILE OF POO}", allow_unicode="very yes"))
<Chipaca> barry: ^ try that in one and t'other
<barry> Chipaca: ok.  gotta run out for a bit.  i'll either finish this tonight or tomorrow
<jdstrand> Chipaca: lucky you-- you get 'less' in the next stable update :) (I wanted to do the apparmro change for /root/apps there too so fixed your less issue :)
<Chipaca> hehe
#snappy 2015-12-02
<dholbach> good morning
<fgimenez> good morning
<fgimenez> hi mvo good morning
<mvo> hey fgimenez, good morning!
<fgimenez> mvo, hi :) i'm reviewing the results of the latest integration suite executions and it seems that with image 270 we have a new error http://10.55.32.74:8080/job/github-snappy-integration-tests-cloud/25/console
<fgimenez> mvo, you can search for "FAIL:" to see the details
<fgimenez> mvo, it seems to fail while trying to write a file in $ADT_ARTIFACTS, i'll try to investigate further, are there any changes that might affect this?
<mvo> fgimenez: the error does not ring a bell :/
<mvo> ogra_: armhf build for rolling is back and worked, so classic mode for rpi2!
<fgimenez> mvo, np, i'll try to get more info about it and ping you back
<mvo> thanks
<sergiusens> dholbach, how hard would it be to pull documentation from a 1.x branch on github for snapcraft?
<fgimenez> mvo, it seems that ioutil.WriteFile is failing to create a file in /tmp/adt-run.pL7nNw/command1-artifacts/version, creating it in /tmp/version instead works
<fgimenez> mvo, but now i'm getting http://paste.ubuntu.com/13619923/
<fgimenez> mvo, "lstat /tmp/adt-run.59r10B/tree/integration-tests/data/snaps/basic-binaries: no such file or directory", but this directory exists for sure
<fgimenez> mvo, it reminds me the issue i hit yesterday with http confinement, in that case i wassn't able to read a file from /tmp, i had to move it to /var/lib/apps/{snap}/current
<mvo> fgimenez: interessting. is adt using some confinement that restricts tmp?
<fgimenez> mvo, not as far as i know, it just launches the executable
<fgimenez> mvo, it seems that the entire /tmp directory gets wiped after the first test is executed, i'll try to find out which of the steps provokes this
<JamesTait> Good morning all; happy Wednesday, and happy International Day for the Abolition of Slavery! ð
<ogra_> yay, armhf builds \o/
<ogra_> Chipaca, so i got an update on my RPi... and thought i'd check if all my services came up again .... so i either call something like "ps ax" or have to call "snappy service status" for each of them ... thats quite a task if you have multiple snaps to check against
<Chipaca> ogra_: sudo snappy service status
<ogra_> i was thinking ... how about making something like "snappy service status all" work
<ogra_> oh !
<ogra_> bah
 * Chipaca wins
<Chipaca> it's snappy service <operation> [package [service]]
<ogra_> right
<Chipaca> so start, stop, status, etc, all can operate on all
<ogra_> oh, the others too ?
<ogra_> wow
<Chipaca> the only one that isn't like that is logs
 * ogra_ <- impressed
 * Chipaca levels up
<ogra_> +1
<ogra_> :)
<Chipaca> actually logs might be like that also
<sergiusens> Chipaca, where is the developer.ubuntu.com information pulled from for snappy?
<Chipaca> sergiusens: dholbach knows
<Chipaca> sergiusens: it's manual for now
<sergiusens> Chipaca, heh; oh, good; then I don't need a 2.x branch, master can be my 2.x branch :-)
<ogra_> hmm
<Chipaca> sergiusens: check with dholbach, because somebody's working on automating it
<ogra_> 2015-12-02T10:03:58.171538Z ubuntu-core-launcher unable to bind private /tmp. errmsg: No such file or directory
 * mvo hands Chipaca a blessed +5 keyboard of awesomeness
<mvo> ogra_: what command is triggering this?
<ogra_> it would be nice if it said *which* file or directory it was looking for ... or at the very least which was its calling process
<ogra_> mvo, a boot
<mvo> ogra_: a boot? you see that on boot?
<ogra_> http://paste.ubuntu.com/13620872/
<ogra_> it auto-rebooted after ubuntu-core upgrade
 * ogra_ checks syslog directly
<ogra_> ah, in syslog it shows the PID at least
<ogra_> .... which doesnt help since the process is gone
<Chipaca> ogra_: so which service failed?
<ogra_> aha
<ogra_> webdm
<ogra_> it starts later on
<Chipaca> ogra_: sudo journalctl -x will probably help figure out what happened
<ogra_> http://paste.ubuntu.com/13620926/
<Chipaca> quoth the raven: WAT
<ogra_> Dec 02 10:03:58 localhost.localdomain audit[848]: AVC apparmor="DENIED" operation="mount" profile="/usr/bin/ubuntu-core-launcher" name="/tmp/" pid=848 comm="ubuntu-core-lau" flags="rw, bind"
<ogra_> http://paste.ubuntu.com/13620953/
<ogra_> the full journalctl output
<jjohansen> ogra_: somewhat an apparmor bug, in that it shouldn't be generating a log message for that
<ogra_> that seems to happen for two of my packages ... not webdm
<ogra_> the failing webdm seems to be a separate thing
<jjohansen> kern_path of the src path is being rejected, which will fail whether or not apparmor is there
<mvo> ogra_: hm, probably a issue with the latest ubuntu-core-launcher and its apparmor rules, I did some changes there
<jjohansen> mvo: it should fail even without apparmor
<jjohansen> the apparmor bug is that it is logging that particular message at all, the failure is real, just not apparmor
<mvo> aha, ok
<ogra_> i have never seen that message when manually starting it ...
<dholbach> sergiusens, yes, it's manual for now, but it'll be automatic soon
<ogra_> though my system as outdated
<dholbach> sergiusens, just let me know which branch to pull from
<ogra_> *was
<asac> jdstrand: no i dont, but let me think for a while and I might remember something
<fgimenez> mvo, mmm it seems that executing any binary from a snap wipes /tmp http://paste.ubuntu.com/13621036/
<mvo> fgimenez: ohhh, I think thats a issue with the ubuntu-core-launcher, I think its not wiping it just overlay mounting, hte same issue that ogra_ is seeing :/
<ogra_> wow
<ogra_> we could just sell it as a safety feature ;)
<ogra_> hmm
<ogra_> so while "snappy list" works now, webdm shows only installed snaps in the "snappy store" tab
<ogra_> does it need an update ?
<ogra_> ppisati, do you know if anything changed WRT v4l in vivid ? bug 1521710
<ubottu> bug 1521710 in Snappy "Webcam not working. /dev/video0 (No such file or directory)" [Undecided,New] https://launchpad.net/bugs/1521710
<ogra_> (in the kernel i mean indeed)
 * mvo will look after lunch
<ppisati> ogra_: no
<ppisati> [flag@luxor ~]$ ls -la /dev/video0
<ppisati> crw-rw----+ 1 root video 81, 0 Dec  2 09:34 /dev/video0
<ppisati> [flag@luxor ~]$ uname -a
<ppisati> Linux luxor 3.19.0-37-generic #42-Ubuntu SMP Fri Nov 20 18:22:05 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<ppisati> i don't see the kernel version there
<ogra_> yeah, i asked for the full syslog ...
<ppisati> this is my amd64 box + usb webcam
<ogra_> snappy ?
<ppisati> ogra_: nope, regular box
<ogra_> right
<ogra_> (amd64)ogra@aleph2:~$ uname -a
<ogra_> Linux aleph2 3.19.0-33-generic #38-Ubuntu SMP Fri Nov 6 18:18:12 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<ogra_> thats my snappy ...
<ogra_> (we havent done a build in a while in 15.04)
<dholbach> kyrofa, do you know if Sergio wanted to upload 0.6 to xenial as well? Right now it's only in the ppa.
<sergiusens> dholbach, https://github.com/ubuntu-core/snapcraft/tree/1.x for 1.0 and master for 2.x
<sergiusens> kyrofa, ok, master is no 2.x and 1.x is, well, 1.x :-)
<kyrofa> sergiusens, ah alright-- so do we need to stop updating documentation? Or can we switch the server pull?
<sergiusens> kyrofa, already discussed with dholbach ;-)
<kyrofa> sergiusens, great!
<sergiusens> dholbach, btw, can you create a calendar event for the clinic? I almost forgot about ti
<amp_> I have a quick stupid question: If I can reach my snappy from http://webdm.local:4200, on which URL should I look for xkcd-webserver?
<kyrofa> amp_, same url, just port 80 I believe
<amp_> kyrofa, thanks, I see it on 'http:wedm.local/' although the actual xkcd image doesn't load. What if I have multiple webservers? How would they be sorted?
<ogra_> then you should set a hostname via "snappy config ubuntu-core"
<dholbach> sergiusens, yep
<ogra_> this will change "webdm.local" to "$hostname.local"
<kyrofa> dholbach, sorry for not answering your question about 0.6 earlier-- I didn't get on until about 15 minutes ago. Did you get that question answered?
<dholbach> kyrofa, no worries
<dholbach> sergiusens, do you want to upload 0.6 to xenial as well? Right now it's only in the ppa.
<dholbach> kyrofa, it wasn't that urgent - but sergiusens was offline for a bit, so I thought I'd ask you :)
<sergiusens> dholbach, yeah, I don't mind
<dholbach> sergiusens, ok
<kyrofa> dholbach, yeah I haven't been on snapcraft that long-- I'm not up to speed on the release process just yet :)
<dholbach> sergiusens, done
<dholbach> kyrofa, no worries - I just thought you maybe had talked about it :)
<sergiusens> dholbach, but I do want a calendar event as I don't know when it starts and want to prep 30' before it starts ;-)
<dholbach> sergiusens, that's already done
<sergiusens> kyrofa, also, if you want to look at https://github.com/ubuntu-core/snapcraft/pull/134
<kyrofa> sergiusens, funny, I just finished
<sergiusens> dholbach, oh, great; thanks :-)
<kyrofa> sergiusens, after I've already built a .snap from snapcraft, if I change the code in a part being built, should I just be able to run `snapcraft build` again and expect it to build the new part but not pull down all the dependencies again?
<sergiusens> kyrofa, that's what I intend to fix with 2.x; it was just too complex in the current code base
<sergiusens> kyrofa, also, --force seems to not do what we want (at least what I want)
<kyrofa> sergiusens, ah, so there's no way to do that in 1.x?
<sergiusens> kyrofa, you can --force but it will go through `pull` again
<sergiusens> which is what I find backwards :-)
<kyrofa> Indeed
<kyrofa> Alright, yeah we should change that for 2.0. Makes developing plugins slow
<kyrofa> Most of my day is spent watching ROS download :P
<sergiusens> kyrofa, there is a trick you can play; edit parts/<part-name>/state to be 'pull' iirc and that should make it 'build'
<kyrofa> sergiusens, ooo, I'll test that out, thanks!
<sergiusens> kyrofa, I don't know the extact syntax, but check what it does after just running `snapcraft pull`
<kyrofa> sergiusens, alright
<kyrofa> sergiusens, is #135 ready for review?
<sergiusens> kyrofa, yeah; it might fail the tests since doctopt might not be there for trusty and I would need to backport and rerun; but code review can start
<kyrofa> sergiusens, oh that's not quite as long as I anticipated
<sergiusens> kyrofa, I split it up into many smaller reviews
<kyrofa> sergiusens, you're a good man
<sergiusens> kyrofa, the only problem this brings in is that the integration tests need to be redone in the last one
<kyrofa> sergiusens, hmm. So the tests will be broken between these? Perhaps we should merge (and review) into a temporary branch so we don't have broken commits?
<sergiusens> kyrofa, sounds good
 * sergiusens creates a `new-cli` branch
<sergiusens> kyrofa, unit tests all work though ;-) but point taken
<kyrofa> sergiusens, good to know, and I don't feel super strongly about it, just some git OCD you know
<sergiusens> kyrofa, ok, so 136 it is
<mvo> fgimenez, ogra_: I can reproduce the /tmp overmount issue, looking into it
<ogra_> thanks !
<dholbach> sergiusens, I'm not quite sure what you had planned for the clinic, how about this? "Sergio Schvezov will give us an overview of what's new in Snapcraft and how to take advantage of its new features. Of course we will also have time to answer questions." - or is there anything missing you'd rather talk about?
<sergiusens> dholbach, sure, I will show the new plugins and such as well
<dholbach> awesome
<dholbach> sergiusens, shall we direct people here or to #ubuntu-on-air?
<dholbach> here should be better, right - some might just stay here
<sergiusens> dholbach, yeah, here is fine
<sergiusens> kyrofa, you can join the snappy/snapcraft clinic if you want
<sergiusens> dholbach, also, why is only snapcraft doing clinics? ;-)
<dholbach> sergiusens, I pinged mvo and niemeyer about doing a snappy one in between UOS and this one today and I never got a reply :-(
<dholbach> maybe I should have brought this up in the standup
<dholbach> I know how many emails we all get
<kyrofa> sergiusens, I definitely plan on watching, at least. I'm not sure I know enough to have anything to add to the discussion itself just yet, unless you want me there
<sergiusens> kyrofa, ah, I can introduce you as the ros goto person ;-)
<sergiusens> then there is no escape! har har
<kyrofa> sergiusens, hahaha
<kyrofa> sergiusens, alright I'll be there. If for nothing else than moral support ;)
<ogra_> hmm, is there a way for me to find out my own IP from a snap ?
<sergiusens> ogra_, you can with go's net pkg
<ogra_> hmm, and without any extra SW ?
<sergiusens> ogra_, no software means no way of doing it ;-)
<longsleep> ogra_: if your snap has network admin it can call all the tools
<ogra_> (i only want to put it into the server name field of a config file so i can tell apart different machines with the same snap)
<ogra_> hmm, but does network-admin pass the store automatically ?
<longsleep> no idea
<sergiusens> ogra_, no, it doesn't
<ogra_> yeah, thats what i thought
<kyrofa> sergiusens, sorry I'm late, grabbing headphones
<ogra_> well, how does go do it ? i assume it needs to read some proc node
<longsleep> ogra_: https://golang.org/src/net/interface_linux.go
<longsleep> syscalls are your friend
<ogra_> yeah
<sergiusens> dholbach, hey, can you invite kyrofa to the clinic as well?
<dholbach> sure
<dholbach> one
<ogra_> dholbach, do we need a meeting today (/me just noticed the calendar)
<dholbach> ogra_, not for me...
<ogra_> then lets skip :)
<fgimenez> Chipaca, one quick question about the http client
<fgimenez> Chipaca, in one of the corner case tests i'm getting http://paste.ubuntu.com/13624161/, is that ok?
<asac> lool: can you make the tomcat webapp use upstream maven rather than from archvie?
<asac> that would be cool
<asac> i mean the maven plugin
<asac> not urgent, but i think that would save me from apt getting half of the world during snapcraft build?
<lool> asac: I am not sure it's good; we're getting java from Ubuntu anyway and that's the biggest thing
<asac> lool: hmm ... what about getting java not from ubuntu?
<lool> and typically developers iterating want to be able to run maven locally, and it's not clear how we'd install it for them
<asac> i think java from ubuntu is almost always what folks dont want
<lool> if you see what I mean
<asac> not sure... arent those packages installed in a chroot?
<asac> we could jsut put maven and java into such chroot instead of apt-get
<lool> asac: while I would consider this upstream java not from Ubuntu a nice thing to have, it's not something straightforward; it requires maintenance and I dont think this is available straightaway
<lool> consider finding an openjdk for ARM tarball with runtime deps, it's not that easy with some kind of security / QA commitmenet
<asac> sergiusens: same prob
<asac> http://paste.ubuntu.com/13624280/
<asac> even with working link
<lool> while we know the one from Ubuntu is up-to-date, tested, maintained; even if we generate an embedded copy, the embedded copy is up-to-date
<asac> lool: i think what folks want they want oracle java
<lool> asac: yes, and that's even harder to automate
<sergiusens> asac, I plan to move to using maven from upstream
<asac> sergiusens: what about java?
<asac> oracle
<asac> i think trick is the license accept
<asac> on instlal
<asac> but i think with Chipaca's feature thats avail too
<sergiusens> asac, oracle java is easy; I have a plan for the license
<asac> please!!!!!
<lool> I don't think Oracle is keen on people automating the download + license acceptance of their stuff
<asac> i need it
<lool> unless you spawn a browser and pickup the tarball from its Downloads
<asac> the license accept is on console for oracle
<asac> afaik
<asac> and i its supposely fine to remember
<sergiusens> asac, I think lool is mentioning the fact that the download link is hidden until the license is accepted on the webpage
<lool> right, and we specifically pulled off the oracle java installer from Ubuntu IIRC
<asac> i dont think thats the case
<lool> which was this .deb with a license prompt d/ling it from oracle
<asac> hmm. it is
<asac> guess they changed that from sun approach
<lool> this is how I see it's being done:
<lool> https://github.com/dockerfile/java/blob/master/oracle-java8/Dockerfile
<asac> nice they even prevent you from wget that link that you got on browser
<lool> installer is from PPA, you set the debconf option not to prompt
<lool> the installer connects to the site, saves the cookie, prompts for license, downloads with cookie
<asac> right
<asac> thats awful
<lool> and I don't think what this PPA does is legal
<asac> well, the user using it is doing something not legal
<asac> not sure if making such code avail is illegal in itself
<asac> but then the code facilitates
<asac> :)
<asac> a crime
<asac> theft of key IP
<lool> you're kind of an accomplice by suggesting we should do this!  :-)
<asac> so guess the plugin could support the ability to point to a local tar
<asac> lool: i dont think we should
<ogra_> lool, at least we have someone to blame then ...
<lool> asac: yes, local tar is what I had suggested in the past
<asac> we should just make it so that we hav a plugin that allows user to point to a URL that can be wget without cookie
<ogra_> is that the main job of managers anyway ? :)
<asac> local on disk
<asac> or on local desktop
<asac> and then have the openjdk option
<asac> preferably not from archive
<ogra_> why not ?
<asac> but if thats archive its probably also fine
<ogra_> yeah, i guess for openjdk the archive should be fine
<asac> because in archive you dont have control over what exactly you get
<asac> which veresion etc.
<asac> sure its fine for most, but then you are not in charge about what you get
<ogra_> but you can at least rely on the fact that it is well maintained ... and you can look up the version easily
<asac> and put in your sofrtware
<asac> doesnt matter
<asac> devs should have choice to upgrade when they want... if they can auto get latest that is great
<ogra_> but we should laso provide comfortable defaults :)
<asac> thats the whole point of bundling dependencies
<asac> thats fine, but we have no way to stay on the old version on respins
<ogra_> as a dev i perhaps only care about my jar
<ogra_> i dont want to have to care for what java i get etc to run it
<asac> so you might wake up witha  firedrill in your code, want to respin and then BOOM get the heap from doko with many bugs and changes you didnt want during that night too
<asac> so your night getse long and your firedrill delayed.
<asac> you always want both
<ogra_> well, you indeed dont want to get doko's experimental crap :)
<ogra_> but his well tested packages from the archive
<sergiusens> asac, there is no easy way to get openjdk from NOT the archive
<asac> if you cant have both than you want explicit control
<asac> sergiusens: lool found a place i think
<asac> nice tarball to unpack
<asac> he didnt like it because he is idealisitic :P
<ogra_> binary ?
<asac> yeah
<lool> it was like a random guy
<lool> probably building things on his fridge
<lool> over IPv6
<ogra_> yay, thats surely better than dokos packages
<asac> right. so thing is that in the past linux distros refused to really consume such binaries and offer that conveniently, but maybe we can talk tot hem
<ogra_> :P
<lool> and embedding a SPAM bot in openjdk
<asac> and tell them we would love to see official binaries
<lool> yes!
<asac> so if you look around python also has no official binaries i think
<asac> while those that target all platofrms usually have agood binaries
<asac> like golang etc.
<sergiusens> lool, asac as the snapcraft team I don't mind; I was planning on maintaining the go binaries for armhf as well
<asac> sergiusens: the prob is that openjdk is afaik super nasty to build
<lool> it is
<asac> more like building the toolchain
<sergiusens> asac, python is the worst thing to snap
<asac> imo deserves a redo
<asac> cant be that folks do something that cant be built with just make make install in 2015
<sergiusens> asac, no one cares for openjdk in any case, only distros
<asac> right
<lool> let's invest 2-3 months into making openjdk easier to build to provide static binaries, then another 2-3 months on Python and then we're good
<lool> :-P
<ogra_> thats only half a year !
<asac> but maybe having great binaries for windows and mac would boost how much folks care
<asac> fact ist hat most folks  deploy on linux
<asac> but dev on windows :P
<asac> so if you dont have openjdk for windows conveniently its like the dead before the start
<ogra_> C:\snappy.exe install myjavatool-0.1.snap
<nikna> what's the new ?
<rospppse> ?
<elopio> fgimenez: are you ok if we skip our meeting today?
<asac> lool: sergiusens: ok -ranting, can we make the current maven/java plugin have a flag that makes it consume the JVM from a path that user has to configure; otherwise it takes the archive one?
<fgimenez> elopio, sure, np
<asac> sergiusens: or what is the plan?
<asac> in any case think nothing speaks against using maven from upstream always?
<asac> (well, besides not having a current link on apache mirros for course)
<asac> sergiusens: going back... http://paste.ubuntu.com/13624629/ is really broken
<dholbach> if you have questions for the snappy clinic, make sure you prefix them with QUESTION: so we can more easily pick them up
<dholbach> (currently on on http://ubuntuonair.com)
<dholbach> any questions for Kyle and Sergio so far?
<shout-user> hello
<dholbach> kyrofa, elopio, sergiusens: great work guys! thanks a lot!
<nigel380> byeee
<kyrofa> Hey, maybe that netsplit is finally over
<dvdbot> Is Ubuntu Snappy only meant for web applications or are you able to show stuff on the screen the rpi for example is connected to? Like a website or something
<ogra_> dvdbot, there is no Mir framework yet (but planned)
<dvdbot> Ah okay, I'm starting with a Digital Signage project and came across Ubuntu Snappy and thought maybe that's it. Gonna have to look further
<dvdbot> Anyone got any suggestions?
<dasjoe> Just the normal Ubuntu Core, not snappy?
<dvdbot> I meant the Ubuntu Core, the thing is I need a UI or something to show stuff on the screen the RPI is connected to, tried the Windows IoT already but it can't handle video's yet
<kyrofa> sergiusens, that pull state hack has already saved me probably two hours
<sergiusens> kyrofa, awesome
<sergiusens> Chipaca, how do we purge snaps? seems `snappy purge` seems to not do anything
<sergiusens> too  many seems seems bad
<sergiusens> :-P
<jerryG> in snapcraft.yaml, how do i specify the version # of dependencies?
<plars> elopio_: I think I already know the answer to this, but just checking... the tests you have in snappy are pretty heavily dependent on the framework there, correct? That is, I couldn't compile them, take a bunch of binaries, and just run them as individual tests locally on a snappy instance?
<Chipaca> sergiusens: what do you mean, how do you purge them?
<Chipaca> sergiusens: tell me what you want 'purge' to do :-)
<sergiusens> Chipaca, to really purge, snappy list --verbose keeps listing inactive snaps
<Chipaca> sergiusens: purge is about removing the data
<sergiusens> Chipaca, ah
<Chipaca> sergiusens: sudo snappy remove app=version will do what you want
<sergiusens> pcoca, ^
<Chipaca> although you lose the ability to rollback when doing that :)
<sergiusens> Chipaca, no worries, no more disk space
<balloons> afternoon all. I'm curious who might be the best person for help with snapcraft atm?
<balloons> sergiusens perhaps?
 * balloons puts on his recruitment hat
<balloons> I'd like to ask someone to volunteer to be a mentor for some snapcraft tasks for GCI
<sergiusens> balloons, I would gladly say yes, but I have offered too much of my free time already; I can give it some thought on the 14th
<sergiusens> if it is too late I propose elopio_
<balloons> sergiusens, if it's ok with you I'll add the tasks and add you as mentor. I am happy to stand in as well ofc. It would just be useful to have someone closer to the core to tap for help
<balloons> sergiusens, also, do you have a list of packages that would make good targets for snaps? I know dholbach had a list at some point, but I don't have it atm
<sergiusens> balloons, some on that list are really hard, well at least not trivial
<balloons> I'd like to get as many as I can, as I think growing snaps would be quite useful
<balloons> sergiusens, ahh, yea, we're looking for things that in general would be a bit easier
<sergiusens> balloons, snaps of the parts wiki with useful parts
<balloons> if you don't have such a list, I'll use my own thoughts
<sergiusens> balloons, not really, no; but this is where elopio_ can be of help too ;-)
<sergiusens> balloons, in general, easy ones are nodejs or go based projects
<balloons> ok. I was also thinking of simple command line tools like pastebinit
<balloons> so something like your snap of shout irc (which is nodejs) was simple then eh?
<sergiusens> balloons, it took me an hour to write the plugin with 100% unit test code coverage, create the shout snap and publish to the store
<balloons> sergiusens, that sounds good. We're looking at 3-5 hour tasks for students
<balloons> right on the money. I'll pick some cool stuff I know of :-)
<sergiusens> balloons, right, at most, any nodejs source would need to be mangled a bit to use the writable parts of the filesystem instead of `./`
<sergiusens> not the case for shout
<balloons> sergiusens, so do I have a hesitant yes from you for later in the contest? It runs through Janurary, so we can hold this stuff until a bit later
<sergiusens> balloons, sure, just take into account that that is summer time here and I might take a couple of more days off ;-)
<balloons> :-) I don't want you to not enjoy summer!
<sergiusens> I'm also going to be at ubuconn
<balloons> right, me too
<elopio> plars: if you pass the build tag excludereboots, then they are standalone. Maybe you will have problems finding the errors in the output, because it won't generate the subunit this way.
<elopio> balloons: sergiusens: I can also give a hesitant yes.
<balloons> elopio, :-) I'll add you
<balloons> elopio, see my pm about your donations request. We should chat about it tomorrow
<elopio> balloons: pm as in email?
<sergiusens> elopio, another one for you to enjoy ;-)
<sergiusens> https://github.com/ubuntu-core/snapcraft/pull/141
<plars> elopio: I'm not sure what you are referring to
<sergiusens> balloons, I can't seem to accept your invitation; I get logged out
<elopio> plars: the framework is needed for handling reboots and merging results.
<elopio> if you don't run the reboots, then the binary with the tests will work nicely if run from inside the testbed.
<plars> elopio: I should elaborate on what I'm looking to do...
<plars> elopio: I'm looking into whether the tests can be used by something else, such as checkbox, so that the cert team can get results produced by checkbox for running the individual tests in your suite, without having to port them all over individually
<plars> elopio: of course that means that we would need to somehow build, then pull them out - because checkbox does not run remotely, it runs *on* the device under test
<elopio> plars: I talked a little with sylvain about that. Personally, I would just first run the autopkgtest suite and then the checkbox suite.
<plars> elopio: ah, good. we are probably looking at the same thing :)
<elopio> but if you get checkbox to handle the reboot flags, then you could even run the reboots from inside the testbed.
<elopio> plars: read the integration-tests/README. We explain in there the reboot details.
<balloons> sergiusens, ohh.. is there another google account I should invite?
<balloons> I invited your canonical one I believe
<balloons> feel free to pm
<plars> elopio: I'll take a look, but would you be interested in possibly having a sync up with us later in the week, or maybe even next week? I'd like to talk about this, but also other plans you guys have around testing snappy
<elopio> plars: of course. Just send me the invite.
<plars> elopio: great! I'll mention it to sylvain and others at tomorrow morning's standup and see who else might want to attend. thanks, and have a good evening :)
<sergiusens> balloons, no worries, remind me to click on the link tomorrow just in case ;-)
<balloons> ack
#snappy 2015-12-03
<dholbach> good morning
<mvo> asac: you mentioned that the webdm store is empty. with what version of snappy do you see this? 15.04? or rolling?
<mvo> hey dholbach, good morning
<dholbach> hey mvo
<mvo> asac: I have a rebuild of webdm ready now but want to reproduce the issue first before blindly uploading
<mvo> fgimenez: hi, I uploaded a fix for the /tmp issue from yesterday, buildig a new image now
<mvo> fgimenez: to verify the fix
<zyga> good morning!
<fgimenez> mvo, ok thanks a lot! let me know when i can give a try
<fgimenez> hey zyga :)
 * zyga prefers to stick to irc
<zyga> Chipaca: can we please land http://github.com/ubuntu-core/snappy/pull/212
<zyga> Chipaca: I think everything is addressed now
<mvo> zyga: I followed up with a question, I'm sorry if the question is dumb
<zyga> mvo: no questions are, thanks, I've replied
<Chipaca> zyga: something something inquisitive idiots?
<zyga> Chipaca: hehe :)
<zyga> Chipaca: do you know that mvo helped me out in my first days of ubuntu?
<zyga> Chipaca: mvo is awesome!
<Chipaca> zyga: i'd be more surprised if he hadn't, because yes
<Chipaca> also, a joy to work with
<Chipaca> even when he asks dumb questions :-p
<Chipaca> zyga: landed
 * mvo blushes
<fgimenez> mvo, test suite passing locally with 272 \o/
<Chipaca> zyga: do you have a link to that reflects-using monstrosity again?
<Chipaca> zyga: outside of a hangout i'd like to look at it to show you a more gothic way of doing it, even if you won't use that code because of the simplification
<Chipaca> zyga: got it
<zyga> Chipaca: sure
<zyga> Chipaca: oh, sorry, I was slow
<zyga> Chipaca: I went to remove some code from https://github.com/ubuntu-core/snappy/pull/205
<zyga> Chipaca: I think that fixes all of the comments now
<Chipaca> zyga: so, in this case https://github.com/zyga/snappy/blob/caps-api-assign/daemon/api.go#L1016
<Chipaca> zyga: because you're racing to have a vertical working, it's fine to use reflect.DeepEqual to save time
<Chipaca> zyga: but the "right" way would be to implement an Equals or whatever yourself
<zyga> Chipaca: on Assignment struct?
<zyga> Chipaca: will that make comparison on two slices work?
<zyga> Chipaca: (not that this code is staying but I'm curious how to do it in go in general)
<Chipaca> either on Assignment or on Caps, depending on the usage
<zyga> Chipaca: I mean I only used deep equals because AFAIR go's doesn't compare slices
<Chipaca> zyga: e.g., newCap.Assignments.Equals(oldCap.Assignments)
<Chipaca> zyga: fwiw, in the general case, DeepEquals will not do what you want
<Chipaca> zyga: it only works there because you're only letting Assignments have 0 or 1 elements
<zyga> Chipaca: oh?
<Chipaca> zyga: but given that it's more like a set, order shouldn't be important
<zyga> Chipaca: can you explain why it would not work?
<Chipaca> zyga: (unless i'm misunderstanding)
<zyga> Chipaca: ah,I see
<zyga> Chipaca: yes, I really miss basic collections here
<Chipaca> so [ass1, ass2] should be equal to [ass2, ass1]
<zyga> Chipaca: yep, you are correect
<zyga> Chipaca: this is a Set[Assignment] in python's 3.5 parlance
<Chipaca> zyga: even more reason to punt that work to after the demo
<Chipaca> zyga: is an assignment ever going to be more than a snap name and a slot name?
<zyga> Chipaca: I don't believe so
<zyga> Chipaca: it's sufficient for anything I was imagining much further down the linre
<zyga> mvo, Chipaca: it would really help me if you could re-check and land https://github.com/ubuntu-core/snappy/pull/205 that I didn't miss anything
<Chipaca> zyga: Assignments is a set, not a multiset?
<Chipaca> er
<zyga> this blocks https://github.com/ubuntu-core/snappy/pull/206
<Chipaca> zyga: i mean, if Assignment A == Assignment B only if A's snap and slot == B's snap and slot
<Chipaca> zyga: then, if A == B, A and B can't both be in Assignments?
<zyga> Chipaca: it is a set, not a multi-set
<zyga> Chipaca: Set[Tuple[str, sr]] in python's typing
<zyga> Chipaca: you are exactly right
<Chipaca> zyga: https://play.golang.org/p/YZm8ETL5gS
<Chipaca> zyga: actually, ignore that for a bit
 * Chipaca adds stuff
<Chipaca> zyga: https://play.golang.org/p/en_H4bVD7x
<zyga> Chipaca: looking
<zyga> Chipaca: why a map?
<zyga> Chipaca: and can a map use Assignment keys? I assume go somehow makes that struct comparable beause it has trivial fields
<Chipaca> zyga: because a set is a map without values
<zyga> Chipaca: ah, right, that makes sesnse
<zyga> Chipaca: thanks!
<zyga> Chipaca: I'm looking at https://github.com/ubuntu-core/snappy/pull/208#discussion_r46454533
<zyga> Chipaca: it seems the gustavo wants .err() on the deaemon.response (or was it resp) type
<Chipaca> zyga: https://golang.org/ref/spec#Comparison_operators
<zyga> Chipaca: not sure though
<Chipaca> zyga: best to ask gustavo what gustavo wants :)
<Chipaca> zyga: âStruct values are comparable if all their fields are comparable. Two struct values are equal if their corresponding non-blank fields are equal.â
<zyga> Chipaca: right, I remember reading that a few weeks ago, I was just double checking
<Chipaca> zyga: meaning that as long as the structs contain things that compare by value, it'll work as expected
<Chipaca> meaning: no pointers, no slices
<zyga> Chipaca: how would you feel if I added daemon.resp.err() method
<Chipaca> zyga: puzzled
<zyga> Chipaca: that conjures an error if the stuff is right
<Chipaca> zyga: puzzled because client doesn't use daemon, and shouldn't
<zyga> Chipaca: but gustavo pointed out a test case for api.go
<zyga> Chipaca: so this is pure server side stuff
<Chipaca> hrmm
<Chipaca> i guess i'm going to go *read*
<Chipaca> you meanie
<zyga> Chipaca: well, I can go ahead and just do it
<zyga> Chipaca: but it feels somewhat weird since it's just for testing
<zyga> Chipaca: and this structure never becomes an error otherwise, as far as I can see
<Chipaca> zyga: there was a different comment from gustavo about err(), but i can't see it now
<Chipaca> where was taht?
<Chipaca> that*
<zyga> Chipaca: it was about client side stuff and it's done now
<zyga> Chipaca: it was about processErrorResponse()
<Chipaca> right, i think that might be where my confusion comes from (and i suspect, his too)
<zyga> Chipaca: there are similar comments involving .err() in several branches AFAIR
 * zyga wonders what to do about pending requests as stuff is blocked
<zyga> Chipaca: I'll work on assign changes we've discussed
<zyga> Chipaca: even if it doesn't land before end of week, I'd like to have something that works to show
<Chipaca> zyga: there ya go
<Chipaca> zyga: i think that one's ready to land with this, yes?
<zyga> Chipaca: https://github.com/ubuntu-core/snappy/pull/208 ? I'd like to improve the test for client.AddCapability() to observe the POST being made
<zyga> Chipaca: I'm just reading how to mock that with SetDoer
<asac> mvo: 15.04
<asac> mvo: if you have a snap i can test it
<mvo> asac: what version of webdm is installed for you?
<Chipaca> zyga: so you want an integration-ish test
<asac> mvo: http://104.196.33.52:4200/
<ogra_> lol
<ogra_> yay security !
<Chipaca> ogra_: ?
 * ogra_ goes and installs transmission in asac'S machine 
<asac> thats great
<asac> do it :)
 * ogra_ does
<Chipaca> *gasp*
 * Chipaca installs windows 10 on ogra's machine
<asac> tell me if you can do anything with it
<ogra_> http://104.196.33.52:9091/ seems blocked by your firewall
<asac> see :P
<Chipaca> asac: i uninstalled http.chipaca
<Chipaca> asac: you can't trust that chipaca person
<mvo> asac: please run "sudo snappy install webdm/edge" and see if that installs version 0.11
 * ogra_ removes transmission again ... useless :P
<asac> seems hackers have some sense of clean room :)
<ogra_> do we have a bu for the "ubuntu-core is -1B big"
<ogra_> ?
<ogra_> *bug
<asac> mvo: sudo snappy install webdm/edge
<asac> Installing webdm/edge
<asac> webdm/edge failed to install: a package by that name is already installed
<mvo> asac: hm, sudo snappy update webdm/edge maybe ? if not you need to uninstall first and then reinstall webdm/edge
<mvo> (sorry for that)
<Chipaca> hah!
<Chipaca> the url for channels in webdm needs to be *triple* escaped
<Chipaca> e.g. http://104.196.33.52:4200/snap/http.chipaca%25252fstable/
<ogra_> third time is the charm :)
<ogra_> "Mode.fetch() failed"
<ogra_> heh, and reloading it works :P
<asac> mvo: update did nothing
<mvo> asac: ok, please remove install again
<asac> doing
<asac> looks good
<asac> see yourself
<ogra_> nethack installed !
<asac> just saw that :)
<mvo> asac: yay
<Chipaca> zyga: sorry, getting back to you now
<mvo> asac: ok, if you don't find anything bad I will promote to stable after lunch
<asac> mvo: so chnnels are now happy?
 * Chipaca was having too much fun breaking asac's stuff
<Chipaca> zyga: that test is supposed to check that the client made the right request, correct?
<zyga> Chipaca: yes
<Chipaca> zyga: in which case, grab cs.req and check it
<zyga> Chipaca: I just figured that out
<zyga> Chipaca: :D
<zyga> Chipaca: it's a bit convoluted at first when you're not familiar
<zyga> Chipaca: personally I would unabbreviate some of the variables
<mvo> asac: yes, it seems to be. if you don't see anything breaking I will promote to stable
<zyga> Chipaca: rsp,req,resp all look too similar
<Chipaca> but they line up so nicely when everything uses just three letters :-p
<mvo> nethack!
 * asac installs lxd curl and mosquitto
<ogra_> you have been eaten by a grue !
<asac> hmm. lxd failed to install it tells me
<zyga> Chipaca: I think it's because it's not my first language
<ogra_> asac, it does that for docker too but in fact the install works
<ogra_> asac, check on cmdline
<asac> ok seems it doesnt really like concurrent installs :)
<ogra_> i think the timeout is to sowrt or some such, bot do some setup
<asac> lxd really failed
<asac> but i think i just clicked too fast
<asac> now it workd
<Chipaca> zyga: i'm bad with names, everybody knows that
 * ogra_ installs moon-buggy too ... now you have a true snappy gamer system !
<asac> haha
<asac> moon buggy is buggy :P
<asac> nice game
<asac>  moon-buggy.moon-buggy
<asac> mkdir: cannot create directory â/home/ubuntu/apps/moon-buggy.dholbachâ: Permission denied
<ogra_> is it ?
<ogra_> wow
<asac> that feels like a bug
<asac> in snappy
<ogra_> yeah, it should use the version there
<asac> the version?
<asac> i have http.chipaca in that dir
<asac> that has a version indeed
<ogra_> /home/ubuntu/apps/moon-buggy.dholbach/$version/
<asac> maybe
<asac> who is creating that directory?
<asac> snappy?
<ogra_> the launcher i think
<Chipaca> um
<Chipaca> that'll happen
<Chipaca> if you run the app once as root, and then as the user
<asac> i didnt run it as root
<Chipaca> hmm
<zyga> Chipaca: /me wonders how to get the request body out of the "mock" doer code
<Chipaca> ah, cannot create, not cannot read
<asac> yes
<Chipaca> zyga: req.Body
<asac> we shouldnt have reomved http.chipaca i am sure
<Chipaca> zyga: cs.req.Body
<Chipaca> asac: I did that one
<zyga> ahhh
 * zyga is dumb
<Chipaca> asac: i mean, i removed that
<zyga> Chipaca: my code did cs.req.Body
<zyga> note the req :/
<zyga> wait
<zyga> no
<zyga> what's wrong?
 * zyga looks
<Chipaca> zyga: no, not dumb. inquisitive :-p
<Chipaca> zyga: um, that looks right
<asac> mosquitto seems to not register binaries
<Chipaca> do you want the response body, or the request body
<asac> e.g. there is nothing in PATH with mosq*
<ogra_> should there ?
<ogra_> (does it actually ship any binaries)
<zyga> Chipaca: it doesn't work, see:
<asac> curl works
<zyga>     c.Check(cs.req.Body, check.Equals, "foo")
<zyga> ... obtained ioutil.nopCloser = ioutil.nopCloser{Reader:(*bytes.Reader)(0xc820013650)}
<zyga> ... expected string = "foo"
<asac> ogra_: well, i think it does
<asac> /apps/mosquitto.kartben/current/magic-bin/
<asac> arm-linux-gnueabihf  mosquitto	x86_64-linux-gnu
<ogra_> i thought it has a web UI
<asac> nah its a mqtt CLI thingy
<ogra_> ah, k
<asac> at least i think
<ogra_> the package is from may
<asac> maybe i am wrong
<asac> syre
<asac> yes
<ogra_> might need an update
<asac> do we break old packages?
<ogra_> well, the yaml formats all changed a lot in the last months
<asac> so you are right
<asac> there is a daemon running
<asac> ok seems its really the broker
<asac> not the cli
<Chipaca> zyga: cs.req.Body is a ReadCloser
<Chipaca> zyga: you need to read it
<ogra_> ah, right
<asac> so false-warning\
<zyga> Chipaca: thanks
<asac> ok i opened port mosquitto-1883 so you can now use that as your mqtt message broker
<ogra_> asac, open 80 too ;)
<asac> whats on 80?
<ogra_> upnp-server
 * ogra_ wants to see if webdav works via internet 
<asac> ogra_: will this allow you to hack that tghing?
<asac> lighthttp is running on it
<ogra_> nah, it will only allow my nautilus to connect to dav://104.196.33.52/
<asac> okk 80 should be open soon
<ogra_> hmm
<ogra_> ha ! works :)
<ogra_> if you open vlc (or any other upnp/dlna capable player in your lan) you should see a snappy upnp server now
<ogra_> with one song
<asac> ogra_: this is not running in my lan
<ogra_> ah
<ogra_> well dav://104.196.33.52/ works at least :)
<asac> yeah
<asac> dont share illegal files there please :{
<ogra_> heh
 * ogra_ removes the file
<asac> wait
<asac> let me get it first :
<ogra_> lol
<ogra_> oh, bug !
<ogra_> i cant delete it
<asac> lol
<asac> its a honeypot
<asac> i called the police now
<asac> with clear evidence
<ogra_> haha
<asac> where do i find that stuff?
<asac> ok found it
<ogra_> /var/lib/apps/upnp-server-armhf.ogra/0.1.0/Media/
<asac> thats legal isnt it?
<asac> its gone :P
<ogra_> well, i paid for the mp3 ... spreding it isnt legal i think
<ogra_> *spreading
<asac> u can also pay for gpl software
<ogra_> christams is coming soon !
<ogra_> :)
<asac> odd i can publish to that mosquitto thing
<asac> but if i sub i dont see the message
 * zyga fixed tests with Chipaca's advice!
<zyga> Chipaca: https://github.com/ubuntu-core/snappy/commit/fe8ddc2c933db716ab9890f8c35b5315451786f6
<ogra_> hmm
<zyga> Chipaca: that's the new test, if you agree it's sufficient then let's land it
<Chipaca> dude
<Chipaca> duuuude
<ogra_> why does snappy list on the RPi show generic-i386 and generic-amd64 ?
<ogra_> webdm hides them i thnk
<Chipaca> zyga: if you were going to unmarshal it, just pass json.NewDecoder(req.Body) ftw
<Chipaca> snappy just spits out everything the store tells it
<Chipaca> webdm is more cautious
<Chipaca> maybe :-p
<ogra_> i thought webdm just uses snappy as backend ...
<ogra_> but apparently it adds extra filtering
<zyga> Chipaca: oh, nice, I can tweak that
<Chipaca> ogra_: it's also possible that one of the two is using the wrong store headers
<ogra_> yeah
<Chipaca> ogra_: webdm is linked against a version of snappy that might not be the system snappy
<ogra_> yup
<Chipaca> ogra_: (this is one of the things the rest api is trying to fix)
 * Chipaca expects to get there before EOY
<ogra_> +1
<zyga> Chipaca: simplified https://github.com/ubuntu-core/snappy/commit/db9343ccda229cc40a0c676a3b10469bab2a2541
<Chipaca> zyga: \o/
<Chipaca> zyga: except for the bit about all tests failing
<zyga> oh
<zyga> yes, bits landed in the meantime
<zyga> no worries, just merge
<Chipaca> zyga: meaning i should just merge, or meaning it's just a merge that you're doing?
<zyga> fixed
<zyga> Chipaca: no, merge removed the carpet from under this branch's feet
<zyga> Chipaca: I just pushed the fix for that, two trivial patches
<Chipaca> k
<zyga> Chipaca: https://github.com/zyga/snappy/commit/10fcafb771c5002bc9831714de0b6573fc4c45f1 and https://github.com/zyga/snappy/commit/3e458f3208f565ad327a1285912930d07326412c
<sergiusens> kyrofa, are you up? I have some PRs and thought of bugging you instead of Chipaca ;-)
<kyrofa> sergiusens, yeah man, hit me
<kyrofa> sergiusens, snapcraft? Heading there now
<sergiusens> kyrofa, yeah, one already reviewed by elopio but I left it there so you can go over it too; as soon as that is done, there are 3 more down the pipe
<sergiusens> kyrofa, I would create them already but the PR doesn't update with the commit id's that have been merged :-/
<kyrofa> sergiusens, looking at it now
<elopio> sergiusens: kyrofa: I have one too: https://github.com/ubuntu-core/snapcraft/pull/137
<elopio> sergiusens: this is the one you deleted before. Maybe it's still there because you hate it and want it to die.
<kyrofa> Wait a minute... elopio why are you up?
<elopio> I don't know. I can't sleep anymore.
<kyrofa> Poor guy
<mvo> asac: I updated webdm in the stable channel now to 0.11 too
<Chipaca> zyga: you're going to push a merge to caps-api-remove-capability ?
<kyrofa> sergiusens, now that we have two release branches, what is the process for getting a fix into both of them?
<kyrofa> sergiusens, we might want to consider a CONTRIBUTING.md so github will provide guidance before anyone creates a PR
<kyrofa> For instance, dholbach's PR would probably be useful to both branches, no?
<asac> mvo: great!
<zyga> Chipaca: yes
<zyga> Chipaca: just fixing tests to mean stuff
<Chipaca> k
 * zyga starts to feel better about how requests work
<sergiusens> elopio kyrofa, thanks
<sergiusens> elopio, kyrofa here's another one https://github.com/ubuntu-core/snapcraft/pull/144
<zyga> Chipaca: https://github.com/ubuntu-core/snappy/pull/211#commits-pushed-5d934ac
<sergiusens> kyrofa, that is a good idea, I saw it would be picked up by github; want to craft one or should I?
<zyga> Chipaca: I've added a TODO to document all the new REST calls
<Chipaca> zyga: good :) the one around attributes will change soon, right?
<Chipaca> meaning, dunno if it's worth documenting it until the whole thing is stable
<kyrofa> sergiusens, I'll take a crack at it
<zyga> Chipaca: attributes or assignments?
<Chipaca> assignments, sorry
<zyga> Chipaca: yes
<zyga> Chipaca: very much so :)
<Chipaca> and error handling overall
<Chipaca> so don't worry *too* much about it :)
<Chipaca> a little worry: ok. a lottle worry: very no
<Chipaca> :)
<kyrofa> sergiusens, but we still need to decide how we'll do it. Make a PR to both? Backport as needed from master to 1.x?
<zyga> Chipaca: yes, I want to fix all the error handling on both client and daemon side
<sergiusens> kyrofa, I'd say master first, and if it is supposed to go to 1.x make it as cherry pickable as possible (== less commits)
<kyrofa> sergiusens, what if we suggested that PRs be squashed?
<kyrofa> Too much?
<sergiusens> kyrofa, yeah, I'm +1 there
<kyrofa> sergiusens, alright I'll get on that as soon as I finish up this roslaunch thing
<sergiusens> kyrofa, elopio ok, feel free to entertain yourself with this one https://github.com/ubuntu-core/snapcraft/pull/145 ;-)
<filmee24> hello from germanmy
<filmee24> *germany
<elopio> filmee24: hello.
<filmee24> where are you from?
<elopio> filmee24: costa rica.
<filmee24> cool. are you an developer?
<davmor2> elopio: I still have my hat :)
<elopio> filmee24: a quality assurance developer.
<elopio> davmor2: I have mine too, but I can't wear it when I have long hair, it doesn't fit any more :(
<davmor2> elopio: Ha I don't have that issue :D
<dholbach> sergiusens, so 'vendor' for master should go away but for 1.x it can stay?
<elopio> davmor2: I know. Lucky you!
<davmor2> elopio: Yeah well you live in a country where you don't necessarily need a hat to keep warm either so fairs fair ;)
<elopio> davmor2: it's not to keep you warn, it's to block the sun. I live in a country with sun, so yes, I win ;)
<sergiusens> dholbach, yeah, for 1.x it needs to stay as 15.04 requires it
<davmor2> elopio: but if you spray it with gortex it becomes waterproof and is the ideal hat to keep you warm and dry :D
<sergiusens> kyrofa, sorry, I didn't wait for your review :-/
<sergiusens> kyrofa, it is a good point and I will add that as part of the test
<davmor2> elopio: although you still win you have sun
<kyrofa> sergiusens, haha, no problem
<dholbach> sergiusens, done
<kyrofa> Oh, sergiusens elopio I have another meeting clashing with standup today. Any chance we can push it back an hour?
<elopio> kyrofa: works for me. It will clash with my meeting with fgimenez, but we can just invite him today.
<kyrofa> Hey sounds good to me
<sergiusens> elopio, kyrofa hmm, I'll see how I can make it then
<kyrofa> sergiusens, if that's difficult, would pushing it back a half an hour be better?
<sergiusens> kyrofa, nah, an hour is easier, it just needs to last 15 minutes tops ;-)
<kyrofa> And worst case I just miss it today if you guys want to just hold it at 0930. I've finished the ROS install bits and am working on upping the catkin plugin test coverage... which isn't so good
<kyrofa> Okay we can do that!
<dholbach> sergiusens, are you going to be on vacation at 21st Dec already?
<sergiusens> dholbach, oh, I'll be avail on the 21st
<sergiusens> dholbach, forgot to mention; I'll be off all other days though ;-)
<dholbach> sergiusens, ok, cool - let me do some timezone math
<sergiusens> dholbach, sure, I can wiggle time around and about
<sergiusens> dholbach, just try to not make it 3AM my time :-) but I'm fine with 6AM or 10PM ;-)
<sergiusens> even midnight is fine if must be
<elopio> sergiusens: I'm playing with hard stuff now, cloud9 that's nodejs. It ends up with the modules in /apps/cloud9.sideload/current/lib/node_modules/ls
<elopio> sorry, hit enter too soon.
<elopio> It ends up with modules in /apps/cloud9.sideload/current/lib/node_modules/c9/node_modules, but it's not finding them.
<elopio> on require, it says that the module is not found.
<elopio> sergiusens: should I move the modules from node_modules/c9/node_modules to node_modules ?
<zyga> mvo: do you want some more action on https://github.com/ubuntu-core/snappy/pull/211
<sergiusens> elopio, show me the yaml
<elopio> sergiusens: https://github.com/elopio/core/blob/snapcraft/snapcraft.yaml
<dholbach> sergiusens, if I checked correctly your 8:00 should be 19:00 in Taipeh - that might be a compromise?
<mvo> zyga: I was mostly wondering if any name needs quoting, but if its only [a-zA-Z0-9] this is a non-issue of course
<sergiusens> dholbach, that's fne
<elopio> balloons: I've sent a google task. Can you please check if it's ok?
<balloons> sure thing elopio
<balloons> elopio, looks good, but you'll need to add some links in the description to where snappy lives, the code to check out, etc
<balloons> if you write a little blurb, you can probably include it in all the tasks you write
<elopio> ah, right. I hate this description box.
<balloons> elopio, yea, me too. very much. It's intended you use there API to bulk create tasks, but I've not trid it
<jdstrand> mvo: hey, when is the next stable supposed to be generated? it looks like it is behind on a security update for the kernel
<elopio> balloons: done.
<elopio> balloons: is the time to complete in full days? like 8 hours per day?
<balloons> elopio, the tasks are intended to be 3-5 hours each
<balloons> the time is how many days they have to do it. It's intended to release if someone says, 'i'll work on it', but then neve rdoes
<balloons> so the task frees for someone else
<balloons> you can probably just leave them all on the default
<elopio> balloons: So I might have to split this, one test per task. But it's going to be hard to organize that, because all the tests will depend on the first.
<balloons> elopio, you could split it into two. Do the first task (that has a dependency on the rest) as one task
<balloons> then do one more task with several instances (so you don't have to create it multiple times). Each person can take a test you've listed
<balloons> we can hold back the second task until the first is done
<pedronis> mvo: Chipaca: thanks for the reviews of the helper branches
<elopio> balloons: I've just increased the instance count to 7. After some thinking, it seems the merge it's not going to be so hard.
<zyga> Chipaca: I've finished the refactoring, I'll give it some tests and poke you for some reviews if you have the time
<zyga> mvo: can I merge https://github.com/ubuntu-core/snappy/pull/211
<mvo> zyga: merged, yes
<zyga> mvo: thanks
<sergiusens> attendee.Join() for attendee in [elopio, kyrofa]
<elopio> balloons: I'm done with the tasks. That's all I can think of for now.
<balloons> elopio, thank you very much for adding the tasks! I appreciate you volunteering and doing the rough bit of adding things to the tool
<Chipaca> zyga: pedronis: back from the school run, holler if there's anything i should look at first
<zyga> Chipaca: ack
<elopio> fgimenez: I'm done with today's snapcraft meeting. Do you want to hang out? (I have nothing to report about snappy, just playing with snapcrafting hard things)
<fgimenez> elopio, we can meet tomorrow then, i've been fixing some of the issues in the scalingstack instances, hopefully we'll have a green (and ultrafast) build when the last firewall rule will be added
<elopio> fgimenez: I saw your RTs. Thanks!
<fgimenez> elopio, np :) i'll continue with the cli purge and the update-rollback stress tests
 * zyga has a simple working capability demo!
<Chipaca> pedronis: origin, err = demoCheckSnapAssertions(snap)
<Chipaca> pedronis: <3
<pedronis> heh
<pedronis> or insanity, but yes
<Chipaca> although i suspect this'll make the automagic sideload version thing not pop up, which'll be a problem for some folks
<Chipaca> but still
<sergiusens> elopio, kyrofa I've """fixed""" the tests
<pedronis> Chipaca: well this is not planned to go to master indeed because IÂ  don't think we have decide what we want/what should be the rules
<pedronis> and because is hooked at the wrong place etc etc
<Chipaca> pedronis: yep yep, but i', still happy about it already doing things that were umpossible before :-)
<pedronis> Chipaca: yes, it's quite powerful, can express various things once the pieces are in place
<ogra_> pitti, did the handling of "allow-hotpulg" in /e/n/i change with the latest systemd ? we see some werid behavior where the interface comes up unconfigured recently
<pitti> ogra_: no, shouldn't have; we also didn't get a newer ifupdown
<ogra_> if i add "auto eth0" additionally it seems to come up fine
<ogra_> yeah
<pitti> ifupdown has changed a bit in Debian, but we haven't merged that yet
<pitti> ogra_: but NB that we never supported "allow-hotplug" in ubuntu
<ogra_> we have used it successfully since 15.04 i think
<ogra_> it started misbehaving today on the RPi ... which had no image builds for a week (so your systemd upload only landed today in images) ...
<pitti> (in meeting, will check more closely in a bit)
<ogra_> thx
<ogra_> pitti, we couldnt use "auto" because then the system would wait for network when the NIC isnt plugged in on boot ... "allow-hotplug" worked just fine in the past
<pitti> ogra_: right, with plain devices it ought to work
<pitti> ogra_: our ifenslave, bridge-utils etc. packages don't work with it though, but I guess that doesn't concern you much
<ogra_> (note that we still have predictable names disabled ...)
<ogra_> i dont think we have either installed
<pitti> ogra_: so the last change to ifup@.service happened before October, so I doubt that's it; is that reproducible? can you specify "weird behaviour"?
<ogra_> pitti, well, no IP :)
<pitti> ogra_: do you have a journal output?
<ogra_> i just collected http://paste.ubuntu.com/13647681/ for Chipaca
<Chipaca> there's no ifup in that log
<ogra_> yeah
<pitti> so I see "eth0: link becomes ready", but nothing further
<ogra_> right
<pitti> and that happend after networking.service (as that's only looking at "auto", so ok)
<ogra_> the system was installed about a month ago and worked til yesterday
<ogra_> (and is set to auto upgrading)
<pitti> you checked /e/n/i already, I suppose
<ogra_> yes
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /etc/network/interfaces.d/eth0
<ogra_> allow-hotplug eth0
<ogra_> iface eth0 inet dhcp
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> thats our default
<Chipaca> and it works some of the time :)
<ogra_> so somehow we do not get a plug event anymore ... one that we did get before
<ogra_> yeah
<ogra_> and rickspencer3 sees it too ...
<Chipaca> ogra_: could we see the journalctl of one time it *does* work?
<ogra_> i can try a few reboots and hope :)
<pitti> you can also add a "set -x; exec 2>>/run/networking.trace" to /lib/udev/net.agent
<ogra_> yeah, in 10min once my boot finished :P
<pitti> it indeed smells like there's no uevent when the device gets added
<ogra_> right
<ogra_> thats my suspicion
<ogra_> but the kernel didnt change
<pitti> ogra_: yeah, I can't really imagine that either
<pitti> ogra_: it's actually more likely that there's some race condition in /lib/udev/net.agent
<ogra_> yep
<pitti> perhaps /etc/network/interfaces gets mounted too late
<ogra_> it gets mounted from  initrd
<ogra_> we moved all /etc mounts there
<pitti> that's the bit that has broken stuff dozens of times already
<pitti> ah
<pitti> very good, thanks
<ogra_> ok, i managed a boot with IP
<ogra_> http://paste.ubuntu.com/13647897/
<ogra_> Chipaca, ^^
<Chipaca> and there's ifup
<pitti> that could be because at the time /etc/init.d/networking ran eth0 was already there
<ogra_> yep
<pitti> although, no, it shoudl have happened before the "Started" then, as ifup -a should wait for completion
<ogra_> well, i wonder why it worked ad-hoc after i added your set -x
<ogra_> i probably changed the race
 * ogra_ tries another reboot 
<ogra_> yeah ... IP again
<pitti> just leave the set -x :)
<ogra_> well, your package ... add it please :P
<pitti> ogra_: more seriously, could you just add an echo before/after the ifup call? that sohudl appear in the journal, but be faster than the set -x
<ogra_> well, i got /run/networking.trace now ... but i cant make it come up without IP anymore ...
<ogra_> let me try the echos
<Chipaca> sooo
<Chipaca> udev coldplug
<Chipaca> runs before mounting of interfaces.d
<Chipaca> :-(
<ogra_> ouch
<ogra_> yeah, the echo doesnt show up anywhere in the journalctl
<ogra_> so the /lib/udev/net.agent helper isnt run at all
<ogra_> Chipaca, but why did the order change (if it did)
<Chipaca> it looks like a race
<ogra_> right, but one we didnt have before
<Chipaca> pitti could advise
 * ogra_ would really like to know what triggers it 
<Chipaca> ogra_: it's possible the old file leftover underneath was hiding this issue
<ogra_> i can try to put it back
<ogra_> lets see
<ogra_> hmm ... i have an IP after reboot
 * ogra_ tries a few more
<ogra_> 5 out of 5 boots had an IP now
<ogra_> so i guess thats it
<Chipaca> pitti: so, what can we do?
<pitti> what is "the old file"?
<pitti> I would say "boot with debug" to see the events that are going on, but that changes the timing even more dramatically
<ogra_> OH !!!
<Chipaca> ogra_: ?
<pitti> so perhaps another echo to /lib/udev/net.agent at the top, to see if it's called at all?
<pitti> perhaps some check in the middle fails, like the ifquery
<pitti> OH! sounds good
<ogra_> heh
<Chipaca> unless it's followed by a â
<ogra_> soo ...
<ogra_> the handling of /etc in the initrd obviously only landed in 15.04 ...
<pitti> Chipaca: no, OHOO isn't a thing; CHâCOOH is, though
<Chipaca> pitti: OHâ is a thing tho
<pitti> true that
<Chipaca> granted CHâCOOH sound smore fun
<ogra_> thats missing in the initrd mount script in rolling http://paste.ubuntu.com/13648333/
<Chipaca> there you go :-D
<Chipaca> which reminds me, we should tell systemd to not mount all that stuff all over again
<pitti> oh, do you mount it in initrd *and* in fstab?
<pitti> but if it's already mounted, it shoudl be fine I guess
<Chipaca> pitti: it seems we aren't yet doing it like that in rolling, but we should, because of these races i guess
<ogra_> fix uploaded
<ogra_> pitti, it just adds a lot of moise to the boot
<ogra_> *noise
<pitti> ah, about "already mounted wahwahwah"?
<Chipaca> noise][: ogra_ says you slow him down
<ogra_> 4-5lines about "hey i tried to mount that ... y'know, it iis mounted already ... so i'll probably not mount it"
 * Chipaca tries to start a fight
 * pitti gets out the popcorn and the CHâCOOH
<ogra_> pitti, yeah
<ogra_> Chipaca, i didnt say slow-down ... just that noise][ is chatty :)
 * Chipaca wonders why pitti has acrylic acid with his popcorn
 * Chipaca blames systemd
<pitti> oh, crap! I guess I should rather get CHâCOOH :)
<ogra_> rickspencer3, so tomorrows image should be fine again ... til then you can keep the "auto"
<rickspencer3> ogra_, ack
<pitti> err no,
<pitti> CHâCHâOH
<pitti> it's been too long :)
 * ogra_ wonders if this channel is now NSA logged ... 
<ogra_> chemical formulas !
<Chipaca> I *suspected* that was what you were looking for
<pitti> Chipaca: you wanted to start a fight, now go :)
<Chipaca> :)
<Chipaca> :)
<sergiusens> Chipaca, another thing I don't like about irc, writing like a fool without knowing I was offline :-P
<sergiusens> elopio, updated the review
<Chipaca> sergiusens: granted
<Chipaca> sergiusens: I don't like it when you write like a fool either
 * Chipaca runs
<sergiusens> Chipaca, well at least we agree :-)
 * sergiusens already ran earlier today
<sergiusens> :-)
<sergiusens> Chipaca, btw, maybe you want to look at https://github.com/ubuntu-core/snapcraft/pull/145/files ;-)
<elopio> sergiusens: can you document the execute function? I think that will clear my questions.
<sergiusens> elopio, sure
<sergiusens> elopio, it is the former cmds.py `cmd` in some sense
<sergiusens> elopio, the only problem is, if I document it now, you will say it doesn't do what I say it should ;-)
<elopio> sergiusens: I would be happy with TODOs :)
<elopio> sergiusens: the 'stage' argument feels overloaded. Do we have a better name for that? 'step' maybe?
<sergiusens> elopio, `step` is good, I think it is how we document it
<Chipaca> longsleep: you around?
<sergiusens> elopio, is this good enough paste.ubuntu.com/13648814/ ?
<elopio> sergiusens: yes, thanks!
<elopio> as it is public, it deserves a docstring. But maybe... not yet?
<elopio> I'll leave you my +1.
<sergiusens> elopio, not yet, they will be confusing; they'll be there when I add `strip`
<elopio> ok
<sergiusens> elopio, there; there's a TODO for the docstring too
 * elopio <- happy
<sergiusens> elopio, kyrofa https://github.com/ubuntu-core/snapcraft/pull/148
<sergiusens> elopio, I have no idea how the code coverage dropped; well I do, I removed test code that probably made the percentage go up
<nessita> elopio, hi! perhaps you can help me. I would like to create a snap package, the dummiest but valid possible snap package
<nessita> elopio, any advice on how to do that?
<pedronis> nessita: looking for something in particular? you can start from hello-world and strip even the few bits it has out
<nessita> pedronis, nothing in particular, I just need to populate my account
<nessita> pedronis, have a link handy for hello-world?
<pedronis> nessita: it originally lived here lp:~snappy-dev/snappy-hub/snappy-examples/   and now that stuff is at https://github.com/ubuntu-core/snappy-testdata (don't thinkt here are meaningful differences for hello-world  atm)
<nessita> pedronis, thank you!
<elopio> nessita: pedronis: even dummier than that: https://github.com/ubuntu-core/snappy/tree/master/integration-tests/data/snaps
<elopio> nessita: and you can strip them even more removing the binaries from basic-binaries. Then it would be nothing useful, just metadata. I think nothing complaints about that.
<nessita> elopio, amazing, thanks!
<elopio> ah, yes, there is one there already, called basic.
<elopio> soon we will be able to even remove the icon from there.
<ogra_> just wait until we can even remove the code (and it still does what it is supposed to)
<nessita> ogra_, looking forward to that!
<ogra_> :)
<sergiusens> elopio, more of the same https://github.com/ubuntu-core/snapcraft/pull/149
<kyrofa> elopio, I'm noticing something weird, wondering if you can verify and perhaps explain
<kyrofa> elopio, as soon as ubuntu-core-launcher launches something (e.g. a snapcraft .wrapper sript), $TMPDIR seems to be reset to /tmp instead of the /tmp/snaps/blah path
<sergiusens> kyrofa, that is just a new namespace being setup
<ogra_> kyrofa, that only looks like :)
<ogra_> it is confusing at first :)
<sergiusens> kyrofa, from the apps point of view it is tmp, if you look at it from the outside, it will be /tmp/snaps/blah
<kyrofa> Gahh
<ogra_> touch a file in /tmp and you will see
 * kyrofa 's head explodes
<sergiusens> kyrofa, ns does that sometimes :-)
<kyrofa> Thanks guys :)
<kyrofa> sergiusens, so for file access, once u-c-l has launched it, file access needs to be relative to $SNAP_APP_PATH? i.e. does this explain why this script which is trying to open $SNAP_APP_PATH/blah actually fails?
<kyrofa> It should be trying to just open /blah ?
<sergiusens> kyrofa, no
<ogra_> kyrofa, writes should go to SNAP_APP_DATA_PATH
<sergiusens> kyrofa, $SNAP_APP_PATH/blah opening that should work
<sergiusens> as long as the envvar is correct ;-)
<ogra_> yeah
<kyrofa> sergiusens, hmm, okay something else is going on here then. I'll keep digging
<sergiusens> kyrofa, snappy install hello-world and run `hello-world.env`
<sergiusens> kyrofa, you do that while I add recursion to the lifecycle to properly handle 'after' requests :-)
<kyrofa> sergiusens, ooo recursion. Does that mean if I have enough 'after's I can blow the stack?
<sergiusens> kyrofa, no, it means that 'after' is just broken; or only solves the case for the 'all' case ;-)
<kyrofa> :P
<kyrofa> sergiusens, I found my issue. The shebang in a python script was pointing to the snapcraft install directory and not the installed snappy location. #!/usr/bin/env python seems to work as expected, but is that okay in a .snap?
<ogra_> as long as your interpreter is in $PATH ... and as long as it is called "python" and not something like "python3"
<ogra_> the wrapper usually puts SNAP_APP_PATH/bin and sbin in PATH
<sergiusens> kyrofa, totatlly
<kyrofa> ogra_, yup, okay good, moving on
<kyrofa> sergiusens, I'm trying to use self.run to run sed... and having all kinds of issues
<sergiusens> kyrofa, use subprocess.check_call
<sergiusens> kyrofa, if you need to run a system command
<sergiusens> kyrofa, path and libraries will be all reffing whatever is in your install and stage dir if not
<kyrofa> sergiusens, ah interesting, okay
<sergiusens> kyrofa, may I recommend a python regex ;-)
<kyrofa> sergiusens, I was thinking about that too
<sergiusens> kyrofa, if having issues, Chipaca always has the magic one liners ;-)
<kyrofa> sergiusens, heh, good to know!
<sergiusens> kyrofa, elopio btw, any opinion on this? https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42
<Chipaca> how can i help?
<sergiusens> it's not a PR yet, but I just finished battling the python  type system
<sergiusens> Chipaca, oh, eventually, some regexes with python (to not call sed)
<sergiusens> Chipaca, well, if you have time, want to see if that `execute` function makes sense to you https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42 ?
<Chipaca> sergiusens: makes sense
<Chipaca> by which i mean, nothing obviously wrong
<sergiusens> Chipaca, thanks
<sergiusens> elopio, I think getattr is more expensive than if/elif
 * sergiusens checks
#snappy 2015-12-04
<elopio> sergiusens: that would be a reason to ignore my comment.
<sergiusens> elopio, the orignal code was like that
<sergiusens> elopio, I'll switch to it; but you get the Chipaca into furiosa mode
<sergiusens> :)
<sergiusens> elopio, seems minimal http://paste.ubuntu.com/13655053/
<Chipaca> ummm
<Chipaca> is this about the if thing == 'foo': foo() elif thing == 'bar': bar() elif thing == 'potato': brotato()?
<Chipaca> ?
<sergiusens> Chipaca, yeah, like the paste above
<Chipaca> is there no 'none of the above' case?
<sergiusens> Chipaca, or the execute function I made you look at earlier
<sergiusens> Chipaca, hah :-)
<sergiusens> Chipaca, you can offer one :-)
<Chipaca> i mean, in execute, it was the 'step' variable, right?
<Chipaca> and you checked three things
<Chipaca> are those all the values step can take?
<sergiusens> Chipaca, yeah
<sergiusens> elopio, for ref https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42
<elopio> furiosa mode, lol
<Chipaca> I dislike spurious use of getattr(), but a forest of if/elif is what getattr avoids :)
<sergiusens> Chipaca, one more, strip
<Chipaca> sergiusens: so in your perf checking code, add a 'd' to the tests
<sergiusens> Chipaca, I have
<sergiusens> Chipaca, http://paste.ubuntu.com/13655167/
<sergiusens> just didn't share it
<elopio> also this is public, so we would need to catch the case where the step argument is not one of the allowed.
<sergiusens> it is neglible to the point of asking, which is more pleasant to read
<Chipaca> sergiusens: um, no, i mean
<Chipaca> sergiusens: in https://github.com/sergiusens/snapcraft/commit/f4c5430b17bc7860b0c976d6cbfbea2860db52df#diff-d5a0fb27fd41b8c98e53ca2b53bdb901R42
<Chipaca> sergiusens: step can take three values
<Chipaca> grah
 * Chipaca tired
<Chipaca> sergiusens: step can take *four* values
<Chipaca> sergiusens: but you only do stuff for *three* of them
<Chipaca> that is, it's not a direct getattr(self, step)()
<elopio> Chipaca: that's work in progress. He has the fourth case in another branch.
<Chipaca> ah. If that's the case, then it's a nobrainer getattr
<sergiusens> Chipaca, so 4 hits the mark?
<Chipaca> siiiiiiigh
<Chipaca> i'll try to explain it with short words
<Chipaca> because i'm tired and can't type long ones
<sergiusens> Chipaca, elopio oh wait, wait there is an hidden reason I did it like this
<sergiusens> well, I can do it differently, no worries
<Chipaca> sergiusens: shoot
<sergiusens> Chipaca, the 'force' logic in the current code is very dark sideish
<Chipaca> force?
<sergiusens> Chipaca, I was planning to make force, only force the desired step and not all the previous ones
<Chipaca> ah
<sergiusens> snapcraft build --force
<Chipaca> that sounds like an --only more than a --force, but --whatevs
<sergiusens> Chipaca, but I can make the 'force' param for each step smarter by not having it there and do it differently
<sergiusens> so no getattr until otherwise mentioned it is
<sergiusens> Chipaca, thanks for being the 3rd opinion on this :-)
<sergiusens> tie breaker ;-)
<Chipaca> is it bad if i understood nothing about where force comes in to play?
 * Chipaca looks at the code a bit more
<sergiusens> Chipaca, I removed all the 'force' mentions in this new code to reimplement it correctly
<sergiusens> Chipaca, current force does what follows...
<Chipaca> i'm writing a long thing about my opinion on this, because i was unable to write it short
<Chipaca> i have 45 minutes to do it in (after which the battery dies)
<Chipaca> hopefully it will be less than that :-)
<sergiusens> hah
<sergiusens> Chipaca, hmm, never mind me, --force is useless
 * elopio goes for cryptobeers
<elopio> I'll bbl, drunk and anonymous.
<Chipaca> sergiusens: https://gist.github.com/chipaca/a49c1f6888c2f6dd4184
<Chipaca> i hope it makes sense
<elopio> Chipaca: the dict solution is nice.
<Chipaca> it's often the hardest to read though
<Chipaca> :)
<Chipaca> ooh, forgot one
<sergiusens> Chipaca, it is indeed hard to read :)
<Chipaca> elopio: sergiusens: added one last one just for fun, and now yes g'night
<dragunov11> hi, wanted to know if its possible to create our own snappy store.
<dragunov11> hi, wanted to know if its possible to create our own snappy store.
<fgimenez> good morning
<dholbach> good morning
<zyga> good morning
<JamesTait> Good morning all; happy Friday, and happy World Wildlife Conservation Day! ð
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<liuxg> dholbach, in my python project, I need to install some extra packages like django for instance. How can I do it in the snapcraft.yaml file?
<liuxg> dholbach, I have seen that webcam example, it has a setup file, and it installs a package like pyyaml, does it only apply for config.py only?
<dholbach> liuxg, do you want to install them locally on your machine or do you want to install them in the resulting .snap package?
<liuxg> dholbach, in the snap package
<dholbach> you use stage-packages to include them in your .snap
<zyga> dholbach: I think he can also use pip plugin to use upstream releases directly
<zyga> liuxg: I haven't tried that in a while but give it a try
<zyga> liuxg: it has access to fresh software faster this way
<liuxg> dholbach, can I do the same like the one in the file https://github.com/ubuntu-core/snapcraft/blob/master/examples/webcam-webui/setup.py?
<liuxg> zyga, thanks. then what is the syntax for doing pip?
<liuxg> zyga, dholbach I have seen it is done in the setup.py in the webcam project
<dholbach> liuxg, as an exercise it's a good idea to separate all the individual bits into parts and find out where their source/binaries come from, how they are built/installed, if all of the files need to be installed
<dholbach> so if for example you have a couple of files you want to ship which don't make use of a build system (like cmake or setuptools or anything else), you could use the copy plugin
<dholbach> so it entirely depends on your setup
<zyga> liuxg: I don't really remember, let me try to find that
<liuxg> dholbach, for my specific example, django is already there for installation. I need it for my app. how can I install it. is it the same way like the fswebcam?
<dholbach> you could take django from the archive?
<liuxg> dholbach, either way, I think it has apt-get and pip
<dholbach> so add       stage-packages: [python-django]
<liuxg> zyga, thanks
<liuxg> dholbach, thanks, I will have a try on that. by the way, can a plugin support more than one stage-packages?
<dholbach> yes
<liuxg> dholbach, it is interesting. I will try to an exercise for it :)
<dholbach> cool :)
<zyga> liuxg: try this https://github.com/ubuntu-core/snapcraft/blob/f8176788e6a932998c9cac3f98c3eb78c40fcab3/snapcraft/plugins/python3.py#L32
<zyga> liuxg: it seems that it's merged with python2/3 plugin now
<zyga> liuxg: just pass a path to requirements.txt
<zyga> liuxg: and it will pip-install anyhting you need
<zyga> liuxg: let me know if that works, I'm curious myself
<dholbach> stage-packages should probably be easier in this case... unless you need a very specific django version
<dholbach> and want to maintain the version number yourself
<liuxg> zyga, what is the form of requirements.txt?
<dholbach> liuxg, something like this:
<dholbach> Framework==0.9.4
<dholbach> Library>=0.2
<dholbach> hi sergiusens
<zyga> liuxg: normal requirements file, you can make one like this:
<zyga> liuxg: create a virtualenv
<zyga> liuxg: setup.py install your stuff there (or pip install anything you need)
<zyga> liuxg: then run: pip freeze
<zyga> liuxg: that's your requirements file
<zyga> liuxg: so when it works for you in virtualenv you can pip freeze and put that into snappy
<zyga> sergiusens: o/
<dholbach> going with the archive is probably easier ;-)
<dholbach> sorry :)
<dholbach> but yeah.. it would probably be good to test that as well :)
<zyga> dholbach: if your stuff is in the archive
<zyga> dholbach: at the right version
<dholbach> django is
<liuxg> zyga, thanks for the info. it sounds like some info like the one here http://www.django-rest-framework.org/tutorial/quickstart/. just append pip freeze there?
<zyga> dholbach: requirements can also pull straight from git/hg/bzr at any revision/tag
<dholbach> yep, that's right
<zyga> liuxg: looks like it
<liuxg> zyga, is it like http://paste.ubuntu.com/13665491/?
<liuxg> zyga, I will have a try for that.
<sergiusens> o/
<zyga> liuxg: that's not requirements.txt
<zyga> liuxg: that's something you can run in your shell
<zyga> liuxg: then you can pip freeze
<zyga> liuxg: and redirect that to > requirements.txt
<liuxg> zyga, so what does a requirements.txt look like?
<zyga> liuxg: run that and see
<liuxg> zyga, do you have any example or document for this? it is hard for developers to figure out.
<sergiusens> liuxg, a requirements.txt is not hard for a developer already working on python
<sergiusens> dholbach, you can make the QA 6am my time I guess
<liuxg> sergiusens, how to integrate it into snapcraft may be a problem.
<liuxg> sergiusens, do you have any simple example for that? thanks
<sergiusens> liuxg, snapcraft help python3
<sergiusens> liuxg, look at the requirements keyword text, it says to point it to the path to your requirements.txt
<liuxg> sergiusens, in the python-packages, it installs all of the needed packages? right?
<liuxg> sergiusens, for my case, I need to run django on snappy, how does the requirement looks like. If I use virtualenv, how can I start the app/service in this case? I have seen a simple django tutorial at http://www.django-rest-framework.org/tutorial/quickstart/, thanks
<dholbach> sergiusens, are you sure that's not too early?
<liuxg> zyga, do you know how to run a python project in an virtualenv on snappy??
<zyga> liuxg: I don't think you need virtualenv on snappy per se
<zyga> liuxg: (you can in classic mode for testing)
<zyga> liuxg: you want to develop your project locally if you can, using virtualenv
<zyga> liuxg: and then package that with snapcraft
<liuxg> zyga, yes, that is what I think. we just install everything to the space of the snappy app.
<liuxg> zyga, the python3 plugin supports requirements and python-packages, what is the difference between them?
<liuxg> zyga, in the requirements.txt, we can install the packages, how about the python-packages? do they do the same thing?
<zyga> liuxg: I actually don't know - I'd have to read the source of the plugin
<zyga> liuxg: get started with requirements
<liuxg> zyga, we truly need more documents and examples for the tool. Even though for an experienced developer, he may get stuck without diving into it.
<sergiusens> dholbach, it is fine
<dholbach> sergiusens, ok... I'll tell Kay
 * zyga fiddles with GPIOs and LEDs for a demo
<olli> pers
<olli> +morning sna...
<ogra_> heh
<liuxg> sergiusens, would you please show me a simple example how to use the requirements.txt to install django for my python project? thanks. I did not figure it out. thanks!
<olli> mvo, how do I get all snap goodness on my Pi? rickspencer3 threw me off yday by saying he built an image... I would have expected to just download our pi reference image
 * rickspencer3 braces
<ogra_> olli, we dont have any downloadable images for rolling
<ogra_> the reference image is stable
<rickspencer3> olli, I did this:
<rickspencer3> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
<rickspencer3> I don't know if or how well the system is documented, but this created an image for me quite quickly, then I just dd'ed it over
<rickspencer3> hmmm, though I just noticed it says pi2.canonical/stable :/
<ogra_> thats correct
<ogra_> u-d-f doesnt know about channels yet
<rickspencer3> ack
<ogra_> so you need /stable
<rickspencer3> confusing, but "ack" ;)
<olli> ogra_, ah, remember
<olli> ogra_, which u-d-f do I want?
<olli> there was a specific branch iirc
<olli> sergiusens, ^
 * olli is gathering stuff for his 18h journey tomorrow
<zyga> olli: lucky you
<ogra_> olli, just the latest :)
<olli> zyga, lucky as I have time to check out your demo ;)
 * ogra_ is on 0.31-0ubuntu1 on trusty ... that works fine ... though i think there was a newer release
<sergiusens> olli, I thought you needed mvo's specific branches
<sergiusens> olli, for u-d-f
<sergiusens> olli, this is until we have time to implement ubuntu-image
<mvo> rickspencer3, ogra_, olli: let me check and fix the need to add rpi2/stable
<mvo> sergiusens: for non all-snap images the old u-d-f is still ok
<mvo> sergiusens: probably changes after the sprint
<sergiusens> oh, wrt channels, I haven't been involved in any preempt work
<rickspencer3> mvo, oh, so does that mean the version I have now is not all snaps?
<sergiusens> mvo, oh, and it works? Notice olli was specifically asking about "all snaps"
<mvo> sergiusens: ups, srry, I overlooked the all-snaps bit :/
<mvo> rickspencer3: yeah, you are still old-school, I only have a BBB all-snap image at this point
<rickspencer3> oh man
<rickspencer3> what a bummer
<mvo> olli: sorry, I missed the all-snap part, we have no rpi2 image right now ready, I need to build a kernel snap first, let me do this
<mvo> rickspencer3: sorry!
<rickspencer3> mvo, could someone document how to get a rolling 16.04 all snap image somewhere?
<rickspencer3> even just an email to the list would be nice
<mvo> rickspencer3: so here is the issue - I can not upload ubuntu-core for armhf to the store because I can only have one name for each architecture and I use ubuntu-core for amd64 already. should I wait for the store to fix this or call it ubuntu-core-armhf ?
<mvo> rickspencer3: there is on all-snap rpi2 image or bbb image because of the naming issue. but I may make this too complicated and just use ubuntu-core-armhf and ubuntu-kernel-rpi2 as names?
<mvo> in the store?
<rickspencer3> mvo, I don't think I have enough context to make that decision
<rickspencer3> but it seems like we want people using all snaps asap
<rickspencer3> I think we want the feedback asap wrt what is working perfectly and what is working not perfectly right now
<rickspencer3> is it reasonable to use your naming trick on a temporary basis?
<mvo> rickspencer3: I think so, people may need to manually switch later to a new anme but I guess thats ok
<rickspencer3> olli, thoughts? ^
<rickspencer3> I think olli is the right person to facilitate this decision
<rickspencer3> I worry that I am just impatient ;)
<olli> we stopped worrying about that and accepted it as a fact
<olli> years ago
<rickspencer3> haha
<mvo> let me make a image for you guys using a sideloaded kernel so that at least there is something
<olli> was hoping we can discuss in BRA next week
<olli> mvo, I can create an image myself if above u-d-f does the trick
<mvo> olli: for all-snaps you need the ubuntu-device flash from https://people.canonical.com/~mvo/all-snaps/ and I need to push a rpi2 kernel into the store. I guess pi2-kernel is a good name(?)
<mvo> ogra_: any preferences for the kernel name for the pi2?
<ogra_> mvo, we already have a name
<mvo> olli: I'm on it now and can make you a sideloaded image and we can talk about the store names via g+ if you want or I can send you a mail with the problem summary whatever you prefer. but maybe I make this too complicated and just upload ubuntu-core-armhf
<mvo> ogra_: we do?
<ogra_> just use the name we use for the channel and for the current kernel package
<ogra_> "raspi2"
<mvo> ogra_: works for me, thanks
<olli> mvo, ok, if you can make an image without being negatively impacted from your sprint prep then that's fine for today
<olli> everything else (naming) we can cover next week
<olli> if I don't get an image today I am ok too
<mvo> olli: thanks!
<BrianLinuxing> Hello
<BrianLinuxing> I've got a snappy related question
<BrianLinuxing> Is there any good reason why Snappy couldn't work on the new Pi Zero? (once an image was built)
<ogra_> BrianLinuxing, yes ...
<ogra_> BrianLinuxing, Pi zero uses a very old ARM arch (like the Pi1 ... ) there is no way to use that with ubuntu
<mvo> ogra_: where is the source for the pi2 oem snap? I would like to modify it for the all-snap os/kernel uboot environment
<ogra_> mvo, hmm, on my disk ... let me dig it up and push somewhere
<mvo> ogra_: thanks! I especially need the uboot.env.in file :)
<BrianLinuxing> Gotcha Orga, but if Debian can be built for Pi Zero, wondering why not Snappy?
<ogra_> mvo, http://paste.ubuntu.com/13669072/
<tbr> BrianLinuxing: debian does not exist for pizero, raspbian does, which is a full rebuild.
<ogra_> BrianLinuxing, debian cant be built for pi zero ... raspbian can
<ogra_> you could indeed do the same for ubuntu ... it is essential a completely new archive arch you need to create
<ogra_> (which is a whole lot of work)
<tbr> and then there would be no binary apps running, because they are all for armv7 or x86_64
<ogra_> right
<rickspencer3> mvo, I'm with olli, if it's not easy to get the all snaps image out today, just wait until the right time
<ogra_> mvo, the paste was u-boot.env.in FWIW
<rickspencer3> I can use the old school arch for the time being
<BrianLinuxing> Ok, finger trouble raspbian (and seemingly a version of Arch), assuming all of that, what's the issue blocking Snappy on an A6?
<ogra_> BrianLinuxing, there is no ubuntu for ARMv6
<ogra_> the ubuntu armhf arch is built for v7
<ogra_> like the debian one
<ogra_> or any other relevant distro nowadays
<ogra_> the raspbian people take the whole archive, change the compiler defaults and re-build the whole distro
<BrianLinuxing> got it
<mvo> ogra_: thanks, what is the size of the uboot env for the rpi2? i.e. what mkenvimage parameter do I have to use?
<ogra_> mvo, same as for bbb
<BrianLinuxing> so there is no technical reason why it couldn't be built, just its a lot of work?
<ogra_> should all be identical
<mvo> rickspencer3: I should be able to make a sideloaded one and will see what I can do about the store. maybe I'm just too cautious :/
<ogra_> BrianLinuxing, well, you could set up your own archive server, your own build infrastructure and rebuild ubuntu the same way as raspbian rebuilds debian, yes
<rickspencer3> mvo, I think it makes sense to be cautious about uploading to the store without thinking it through
<BrianLinuxing> is there a full build procedure for snappy for a7? so I can look at replicating on an a6
<BrianLinuxing> thank orga :)
<ogra_> BrianLinuxing, no ... you need the ubuntu build infrastructure set up for this ...
<ogra_> it is a million of steps that involves quite a lot of people
<tbr> BrianLinuxing: canonical doesn't really document their infrastructure, that helps them retain control over ubuntu </my_opinion>
<BrianLinuxing> ok, how would one replicate the ubuntu build infrastructure set up
<ogra_> first of all you would need the rebuilt archive (which will take you 6 months or more i guess)
<BrianLinuxing> I have a lot of kit
<tbr> BrianLinuxing: step one, hire 20-50 build engineers ;)
<ogra_> thenm you would need to replicate the cdimage and live-build infrastructure ubuntu uses
<ogra_> after that you would have tarballs
<ogra_> then you need to set up a system-image server that creates the deltas of these tarballs and tuns them into consumable system-image pieces that ubuntu-device-flash can build images from
<ogra_> i guess tbr's assumption of 20 devs isnt to far off
<tbr> BrianLinuxing: if you want targeted distributions, look at buildroot, yocto+openembedded+angstrom/poky
<BrianLinuxing> tbr, I am old but nimbled fingered :)
<ogra_> unless you have a year of time or more :)
<BrianLinuxing> OK
<ogra_> and once you are done, none of the snap packages from the snapstore would run
<BrianLinuxing> not wishing to state the obvious, but y'all know Pi Zero will take off like a rocket?
<ogra_> since they are built for armhf (v7)
<tbr> oh and you would also be left with the fact that you can't call it ubuntu
<ogra_> right
<tbr> and MUST remove the word ubuntu from all the source code and everywhere
<ogra_> nah
<ogra_> thats nonsense :)
<BrianLinuxing> of course
<tbr> well, the issue is contended and there are diverging opinions
<ogra_> you need to remove all copyright relevant bits ...
<BrianLinuxing> got that.
<ogra_> but surely not changelog entries that reference @ubuntu.com and such :) or readmes that refer to ubuntu etc
<tbr> ask a lawyer and they will side with me ;)
<ogra_> it is moot anyway
<BrianLinuxing> but back to my point, y'all know 30,000 Pi Zeros sold out in < a week
<ogra_> BrianLinuxing, yeah, not much different from Pi1
<ogra_> yet we cant support it
<BrianLinuxing> [let me cut to the chase, not interested in copyright nonsense, just wondered if there were any good technical reasons for not having it]
<tbr> BrianLinuxing: yes, and recently still huge numbers of VW Golf I and Beetle and Transporter were produced in south america
<ogra_> (at least not without making armhf unusable for most other ARM arches)
<tbr> the technical reasons were named in the beginning already
<BrianLinuxing> fair enough, remember that thought :)
<ogra_> BrianLinuxing, the techincal reasons are that a build for the v6 arch disables many/most v7 features
<tbr> it is an enormous overhead and cost to run two arches instead of one
<ogra_> which means ubuntu on phones would for example be really slow and have a lot larger binaries
<ogra_> or ubuntu for clouds where arm is also used a lot
<BrianLinuxing> if its part politics, resources, etc I get that
<ogra_> no
<BrianLinuxing> but Pi Zero will be big.
<ogra_> it is part of money and manhours that arent available
<BrianLinuxing> off to CoreOS, thanks for the chat :)
<tbr> BrianLinuxing: and keep in mind, every second more ARMv7 devices are sold, than RPi ARMv6 devices in a month or even a year.
<ogra_> sonamoe recently told me a new archi might cost between 10.20Mio
<ogra_> *10-20
 * ogra_ grins at olli 
<tbr> my personal opinion is that pizero will always remain a toy, a moderately popular toy.
<tbr> everyone wanting to get real work done has moved on from ARMv6 to ARMv7 or AArch64 long ago
<ogra_> i'd say its more like 5-10 Mio ... but it is definitely a lot of money
<ogra_> right, and the latter two are the arches ubuntu supports
<tbr> truth hurz
<ogra_> yeah
<mvo> ogra_: do you mind if I put the pi2 stuff into lp:~snappy-dev/snappy-hub/snappy-systems next to bbb and amd64?
<ogra_> mvo, not at all !
<ogra_> i was plannin to do that sice a while but it always moved to the bottom of my TODO with more important tasks on the list
<mvo> ogra_: tell me about TODO lists - just like memory in a C program, it keeps growing
<mvo> ogra_: but I can do it while waiting for me sd card to finish writing :)
<ogra_> yeah, ARM work gives you a lot of slack all the time :)
<Chopper> I'm sure this has been asked before. https://developer.ubuntu.com/en/snappy/start/#try-x86 - It appears as though you can't install Snappy onto a hard disk via an installer, you can only run it off a USB device?
<Chopper> If this is the case, is Snappy not really meant for bare metal installations?
<mvo> ogra_: your advice would be great, I have my pi2 snap but it seems like there is something wrong with the env, it tries to load /vmlinuz which does not make sense from the uboot.env.in file. uEnv.txt is empty fwiw
<mvo> ogra_: I send you an image
<mvo> ogra_: anything I can do to debug?
<ogra_> mvo, is that the existing uboot binary ?
<mvo> ogra_: I guess, I did not change anything on the pi2, its brand new
<ogra_> i dont see it loading uboot.env
<mvo> ogra_: how can I debug this? sorry, arm noob
<ogra_> well, you should see a "loading uboot.env"
<ogra_> are you sure the file is in the right place ?
<mvo> ogra_: it shows up on my sd card :) but maybe  I just download the pre-build rpi2 image and compare the two filesystem trees
<elopio> sergiusens: how were the prerequisites implemented before? also with recurssion?
<ogra_> mvo, looks to me like it isnt recognized at all
<mvo> ogra_: whats the boot sequence normally? which of the file is loaded/run in system-boot?
<ogra_> mvo, also screen -L helps a lot
<mvo> ogra_: hm, the card you mean?
<sergiusens> elopio, it was broken before
<ogra_> (to log all serial output to a logfile)
<mvo> ogra_: I have it on a norma monitor right now, no serial
<sergiusens> elopio, just hidden as pull, build, stage, strip was done for a complete part before moving to the next
<ogra_> mvo, it loads the binary blob (start.bin or how thats called) then uboot-bin ... then uboot loads the uboot.env *before* it loads uEnv-txt
<sergiusens> elopio, but if you did `snapcraft build` and one part depended on the other it would break
<elopio> sergiusens: so if now you do snapcraft build, the parts that are reqs will be staged.
<sergiusens> elopio, yes, it is a semantic requirement I want to introduce for `after`, it doesn't make sense otherwise
<elopio> maybe it would be worth printing something about that. Staging part bla because it's a requisite of this other part.
<sergiusens> elopio, that is a good point indeed
<elopio> sergiusens: I like your fancy recursion, but it scares me. The only thing that prevents this to go to infinite are the stamp files that say that a step for a part was already run, right?
<Chopper> Think I found my answer - https://developer.ubuntu.com/en/snappy/start/installation-tips/
<mvo> ogra_: hm, hm, anything I can type in the uboot commandline prompt to give me a clue ? I'm downloading the image now fwiw to see if I can find anything
<ogra_> mvo, printenv and see if the vars from the .in file show up there
<sergiusens> elopio, oh, you think we should add levels? I think python has a limit in itself
<sergiusens> elopio, also, circular dependency checks on load_config prevent a circular eternal loop
<elopio> sergiusens: that's a good thing to mention on this function, somewhere.
<elopio> sergiusens: I don't understand what you mean by levels.
<sergiusens> elopio, have execute take a recursion_level param and check it on entry
<ogra_> mvo, you can also check with fatls and fatload if the file is found and can be loaded
<mvo> ogra_: usb keyboard does not work *sigh* so I need to find a serial cable
<mvo> ogra_: I wonder if the one from the bbb will work
<ogra_> mvo, it will, only attach RX/TX/GND though
<zyga> sergiusens: what's the best way to have meta/stuff in snapcraft.yaml, I'd like a config hook
<ogra_> zyga, you just add "config: config.sh" and snapyp config will call that script
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml
<zyga> ogra_: perfect, thanks!
<rickspencer3> ogra_, any idea what this might mean?
<rickspencer3> http://pastebin.ubuntu.com/13670711/
<rickspencer3> or maybe that is Chipaca?
<ogra_> rickspencer3, looks liek a bug to me
<mvo> rickspencer3: happening on pi2 rolling I assume?
<ogra_> no idea when/where snappy update calls mkdir
<rickspencer3> mvo yes
<rickspencer3> I logged a bug, fwiw https://bugs.launchpad.net/snappy/+bug/1522889
<ubottu> Launchpad bug 1522889 in Snappy "error when running snappy update on rpi2 on rolling (mkdir : no such file or directory)" [Undecided,New]
<ogra_> rickspencer3, my update via autopilot worked tonight ... (i'm on 76 here)
<ogra_> rickspencer3, could your disk be full ?
<rickspencer3> ogra_, I guess so
<sergiusens> zyga, use config: <path to config>
<rickspencer3> ogra_, it doesn't look full: http://pastebin.ubuntu.com/13670818/
<ogra_> 533M free in /writable/cache/system, yeah that should be enough
<ogra_> oh
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy search
<ogra_> Name              Version Summary
<ogra_> classic.mvo       1.0-3   classic
<ogra_> generic-amd64.mvo 2.0     generic-amd64
<ogra_> (RaspberryPi2)ubuntu@localhost:~$
<ogra_> where are all the snaps gone !
<ogra_> did the store change again ?
<ogra_> beuno, ^^^ ?
<ogra_> this used to show a lot more packages with yesterdays image
<Guest55209> ogra_: beuno is on holiday
<ricmm> ogra_: why do you see generic-amd64 in the rpi2 results
<ricmm> :D
<Chipaca> ogra_: what snappy image is that?
<Chipaca> ricmm: because all-snaps
<ogra_> Chipaca, rpi, todays image
<Chipaca> ogra_: on an unrelated subject, what is rpi2 version 0.16?
<ogra_> Chipaca, the OEM snap
<Chipaca> ogra_: newish?
<ogra_> no, ancient
<ogra_> mvo just tries to update it
<mvo> ogra_: hm, once I get rolling to bootâ¦
<ogra_> mvo, hmm, which mkenvimage do you use to create the uboot.env ?
<ogra_> i think i used the one from ym local uboot build
<mvo> ogra_: hm, indeed my bbb uboot env code give me a bad checksum error
<mvo> ogra_: so different format it seems
<mvo> joy
<ogra_> but it tries to load it at lest
<ogra_> your screenshot didnt have any indication it tried to load it at all
<mvo> ogra_: indeed. i compared the system-boot and they look similar on my image
<mvo> ogra_: I play with the env now and see what I can find out
<ricmm> just need 1 bit to go ~ for it to not boot
<ogra_> worst case give me your .in file and i'll ive you the .env
<ogra_> i still have the tree here
<mvo> ogra_: its here http://bazaar.launchpad.net/~mvo/snappy-hub/snappy-systems-new-kernel-os-logic/view/head:/pi2/boot-assets/uboot.env.in - please mail me the bin file and the command you used I will document that in the readme
<mvo> ogra_: hmmmm, size is also very different from bbb
<ogra_> how can that be ?
<ogra_> you define the size in mkenvimg
<mvo> ogra_: ignore me, mixed up files, now it does print me the right output, lets see what my image prints
<ogra_> mvo, mail with uboot.env is out
<olli> ogra_, shiny!
<ogra_> see if that works any better
<mvo> ogra_: thanks I will try that
<ogra_> did ou use -r to mkenvimage ?
<mvo> ogra_: but maybe it was a red herring, I will let you know
<mvo> ogra_: yes
<ogra_> k, that should be good then
<mvo> ogra_: I used http://bazaar.launchpad.net/~mvo/snappy-hub/snappy-systems-new-kernel-os-logic/view/head:/pi2/boot-assets/README
<ogra_> right
<mvo> ogra_: but maybe something else funny is going on, I investigate
<ogra_> iven that fw_setenv needs to be able to read/write them they need to be kind of indentical :)
<ogra_> mvo, where do the values for snappy_good_os and snappy_good_kernel come from ?
<ogra_> (and snappy_os/snappy_kernel)
<mvo> ogra_: thats something that u-d-f will set
<mvo> ogra_: on image creation
<mvo> ogra_: hm, interessting clue
<ogra_> mvo, so i can replace my uboot.env on the running rpi with the one i mailed you and fw_printenv properly shows all values
<ogra_> so i guess it would boot fine too
<mvo> ogra_: let me try to investigate if that snappy_{os,kernel} setting does not work correctly, that looks like a candidate for the rootcause
<ogra_> mvo, well it should still load the env and tell you about that
<ogra_> does it do that now  ?
<mvo> ogra_: it does not tell me that it loads it, no :/
<ogra_> weird
<mvo> yeah, maybe its only showing that it loads the env on the serial console not on the main hdmi screen
<mvo> (?)
<mvo> just a guess
<kyrofa> So I'm trying to snap an app that determine's the user's homedir via getpwuid(geteuid()), and that's giving it /home/ubuntu. If the getpwuid call returns NULL then it'll check $HOME, which means I can work around this in two ways: either make getpwuid() fail or make getpwuid() return the confined HOME. Any suggestions?
<ogra_> mvo, oh, damn, i forgot that you dont use serial
<mvo> ogra_: it boots now and crashes, but progress!
<kyrofa> (note that I can't change the src)
<ogra_> mvo, with your or my uboot.env ?
<ogra_> (do you need my mkenvimage binary ?)
<mvo> ogra_: I think it crashes in kernel or initrd maybe in my uboot code, I need a sertial port now as it flashes too quickly away
<ogra_> yeah, hard to debug without
<kyrofa> Ooo wait, scratch my above problem, it checks another env variable first
<mvo> ogra_: http://paste.ubuntu.com/13672523/ is where I am now
<mvo> ogra_: but dinner first
<ogra_> mvo, looks like a typo somewhere ... or wrong quoting
<dholbach> elopio, thanks for the review - I lifted the content from the Dell doc
<dholbach> kyrofa, elopio: can you handhold me through a rebase?
<kyrofa> dholbach, definitely :)
<dholbach> I can't say I enjoy working with git
<kyrofa> dholbach, yeah it has a learning cliff
<elopio> I'm sorry daniel, I'm afraid I can't do that.
<kyrofa> dholbach, but once it "clicks" you'll get it!
 * ogra_ hugs dholbach 
<elopio> it's friday, it's time for me to delete all my repos and branches and start again.
<rickspencer3> did anyone else read elopio's response in HAL's voice?
<kyrofa> rickspencer3, yes, I'm curious if he was actually making a joke or not though
<ogra_> rickspencer3, how can you not read these words in that voice :)
<rickspencer3> me too
<davmor2> rickspencer3: elopio is HAL did they not warn you of that
<kyrofa> dholbach, ANY way... let me understand what you're doing here. Is this the branch that you targeted to master, and now you're trying to get them into 1.x as well?
<elopio> Dave, this conversation can serve no purpose anymore. Goodbye.
<davmor2> rickspencer3: it's really scary for me
<rickspencer3> lol
<davmor2> see
<davmor2> rickspencer3: rather Hal than skynet though right :)
<ogra_> whats wrong with skynet ?
<ogra_> :)
<dholbach> kyrofa, in https://github.com/ubuntu-core/snapcraft/pull/146 I pushed some changes, but was confused since the coverage percentage dropped (I added a doc to the branch), so I updated it to current tip again, pushed some more changes, and yes it's against 1.x
<kyrofa> davmor2, depends on who's voice you'd say skynet used
<davmor2> kyrofa: minions always the minions ;)
<dholbach> kyrofa, you are right, it contains other changes - sorry
<dholbach> maybe I'll just delete it and propose a new PR
<kyrofa> dholbach, nahh, this is a learning opportunity!
<elopio> dholbach: if you change only docs, feel free to ignore coveralls. It tends to get confused.
<kyrofa> dholbach, let me pull your branch down real quick, hold on
<dholbach> yeah, but I just realised that it's 18:45 on Friday, so maybe looking at it on Monday will make more sense? ;-)
<davmor2> ogra_: did you see the latest terminator???? And you still have the nerve to ask that ;)
<kyrofa> dholbach, haha, no problem!
<kyrofa> dholbach, feel free to scratch it and start over, but if you want to figure it out ping me on Monday, I'd be happy to help :)
<dholbach> I'd definitely come back for some more learning though because I need it - I feel like http://i.imgur.com/xVyoSl.jpg a lot when dealing with git
<dholbach> kyrofa, ^
<dholbach> thanks a lot for your offer of help! :)
<dholbach> all right my friends - I call it a day - have a great weekend and see you on Monday!
<kyrofa> dholbach, you'll get there! Actually there's a really good video you should watch if you have the time: https://www.youtube.com/watch?v=1ffBJ4sVUb4
<dholbach> cool, noting it down
<dholbach> hah, 4 year olds, that's reassuring
<dholbach> thanks kyrofa - have a good one! :)
<sergiusens> elopio, 151 is up
<mvip> mectors: I'm happy to announce that we've begun our Snappy porting ;)
<mvip> (Sorry if that was sent twice. Got reconnected)
<elopio> sergiusens: is it called strip because it will just remove unnecessary parts?
<mvip> mectors: let's just get those last other pieces sorted asap. :)
<mvip> mectors: Viktor from Screenly :)
<sergiusens> elopio, heh, it's in the spec :-P
<mvip> mectors: no worries ;)
<mvip> mectors: it's not as obvious as your ;)
<elopio> I know, but I don't like the name. Too late to say that?
<mvip> mectors: ah ok
<sergiusens> elopio, it doesn't stick well; it won't be a hard change
<elopio> mvip: \o/ welcome.
<mvip> mectors: deal!
<mvip> mectors: we should have something proper to show by then.
<mvip> elopio: thanks btw :)
<mvo> ogra_, Chipaca: ok, here is the issue - the sideloaded version number uses upper and lower-case. but vfat is only lower-case
<mvo> (or upper case)
<ogra_> yeah, upper
<mvip> mectors: you in London next week? Maybe drop by for a coffee?
<ogra_> mvo, your setnev issue is the quotes though i guess
<mvip> mectors: cool. I can swing by for a coffee in the afternoon or a beer in the evening. Whichever you prefer.
<ogra_> mvo, or rather the missing quotes for the bit where you added equal signs ... i.e. setenv mmcroot /dev/disk/by-label/writable ${snappy_cmdline} snappy_os=${snappy_os} snappy_kernel=${snappy_kernel}
<ogra_> setenv freaks out if you dont get this 100% right
<ogra_> i'd try something like: setenv mmcroot '/dev/disk/by-label/writable ${snappy_cmdline} snappy_os=${snappy_os} snappy_kernel=${snappy_kernel}'
<mvip> mectors: also, please meet renat. He's one of our devs working on Snappy.
<mvip> renat: welcome ;)
<renat> Hi all! My name is Renat. I'm working on Screenly and invited by Viktor (mvip).
<renat> mvip: Good evening!
<ogra_> welcome guys :)
<mvip> We had a bit of discussion internally for where to store content on disk that will be persistent through versions and can be shared across different Snaps
<mvip> Is there a best praxis for where to store these?
<mvip> *best practise
<renat> And will not require too complex AppArmor config.
<ogra_> well, currently there is no such space
<ogra_> snaps cant see anything outside their allowed dirs
<ogra_> you could share and mirror stuff via network ports i guess ... and store them in one snaps environment in $SNAP_APP_DATA_PATH
<mvip> ogra_: We're talking about gigabytes of data tho (potentially)
<ogra_> why do you have to use different snaps btw
<mvip> ogra_: to keep each snap as simple as possible.
<renat> ogra_, to limit access for each service.
<mvip> and that :)
<ogra_> well, but then you also limit their capabilities
<ogra_> (like shared files)
<ogra_> i'm not sure where content sharing inside snappy is on the TODO of the security team ... you might want to ask jdstrand
<zyga> jdstrand: ping
<zyga> jdstrand: I need some emergency help
<mvip> ogra_: the reasoning is also that the overhead for isolating each service in a snap is minimal, so it creates a nice isolation
<zyga> jdstrand: I have snappy hw-assign to /sys/class/gpio/gpio67/value
<zyga> jdstrand: it doesn't work at runtime (I get EPERM on open)
<ogra_> mvip, well, but it also limits the abilities to chare data between services
<zyga> jdstrand: from my reading of the default template (I'll pastebin the whole thing in a sec) it seems that all of /sys is off-limits (no /sys r, /sys/** r, rules like there are for /dev)
<ogra_> *share
<zyga> jdstrand: do I guess right or is something else at play?
<zyga> jdstrand: full apparmor profile: http://pastebin.ubuntu.com/13673818/
<kyrofa> elopio, when you have time: https://github.com/ubuntu-core/snapcraft/pull/152
<mvip> ogra_: we just need a socket and files on disk. Other than that, the services are fully independent.
<mvip> ogra_: also, they're using different frameworks. Some are Python, others QT
 * zyga is blind, there are /sys rules below dev rules
 * zyga has no theory anymore
<ogra_> well, you need to bundle that anyway
<mvip> ogra_: but this should all be doable with a custom AppArmour policy, no?
<kyrofa> zyga, I see this in your paste:
<kyrofa> # Do the same with /sys/devices and /sys/class to help people using hw-assign
<kyrofa>   /sys/devices/ r,
<kyrofa>   /sys/devices/**/ r,
<kyrofa>   /sys/class/ r,
<kyrofa>   /sys/class/**/ r,
<ogra_> mvip, depends ...
<zyga> kyrofa: yes, I saw that too (now)
<zyga> so now how to see what's the EPERM about
<zyga> ahh
<zyga> I see
<zyga> Dec  4 18:26:48 localhost kernel: [ 3321.964683] audit: type=1400 audit(1449253608.501:26): apparmor="DENIED" operation="open" profile="caps-demo.sideload_bool-file_IHGIDOLcSPKD" name="/sys/devices/platform/ocp/481ac000.gpio/gpio/gpio67/value" pid=2058 comm="python3" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=0
<zyga> that makes sense
<zyga> good, so I just have to provide realpath
<zyga> ufff
<kyrofa> zyga, wait, it looks like that profile will only allow read-only
<ogra_> mvip, changing apparmor rules means manual reviews ... unless you have a dedicated part of the store for your product, then you can freely do that
<mvip> ogra_ i spoke with ricmm in Madrid about this a few weeks back and that was my impression from the conversation
<mvip> ogra_: we'll have a dedicated store
<ogra_> right, it is a matter of context ;)
<ogra_> yeah, then you can indeed just adjust apparmor rules and even have dirs shared between snaps
<mvip> ogra_: :)
<ogra_> the normal store wouldnt allow that
<zyga> kyrofa: yes, I hw-assign (kind of) rwk (whatever "k" is)
<mvip> ogra_: fair enough.
<dstaley> Hi there! I just installed the Snappy Core image on my Raspberry Pi 2 and I seem to be running into issues upgrading ubuntu-core. It downloads fine and prompts me to reboot, but once I issue the reboot command it falls off the network. I'm unable to SSH back into it until I manually pull the power and turn it back on. However, after that ubuntu-core hasn't been updated. Any ideas?
<kyrofa> zyga, a lock
<mvip> ogra_: so there is no best practise of where to store this data then i preseume
<ogra_> dstaley, which channel do you use ?
<renat> mvip, I believe that it should be located in /var/
<ogra_> mvip, i would put it into one of the snaps into SNAP_APP_DATA_PATH ...
<mvip> renat: yeah, i have no strong opinion. I just wanted to make sure we follow best practice if there was one
<mvip> renat: yeah that's fine then. Go ahead and do it that way ;)
<renat> mvip, thanks.
<renat> ogra_, thanks for help.
<ogra_> dstaley, in xenial there was a bug that only got fixed with todays image (revision 76 in the rolling/edge channel)
<dstaley> ogra_: I'm unsure. How would I check that?
<ogra_> dstaley, well, how/where did you get that image ?
<ogra_> there are no downloadable xenial images so you would know if you created one yourself :)
<dstaley> Oh it looks like it's 15.04 stable
<ogra_> right
<zyga> it was a realpath issue
<zyga> apparmor and symlinks don't play well
<zyga> jdstrand: all is good, alarm off :)
<sergiusens> elopio, kyrofa simple pimple https://github.com/ubuntu-core/snapcraft/pull/153/files
<dstaley> Well, this is strange! I just pulled the power and SSH'd back into it. Got "snappy autopilot triggered a reboot to boot into an up to date system"
<mvo> ogra_: one more step http://paste.ubuntu.com/13674418/ - "data abort" - wonder what that means
<ogra_> mvo, to big for the reserved ram space ?
<ogra_> (just guessing, never seen "data abort")
<ogra_> unless your kernel is corrupt somehow
<jdstrand> zyga: sorry I didn't respond sooner. apparmor plays fine with symlinks, it (necessarily for security) resolves them. there is a bug report I think that a community member filed on having snappy resolve them
<jdstrand> zyga: but I think it was deprioritized because hw-assign is the old way (not sure about that)
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/154
<sergiusens> elopio, last but not least https://github.com/ubuntu-core/snapcraft/pull/155
<sergiusens> elopio, and that is all I have, anything newer needs work (the `snap` command ;-) )
<sergiusens> and updating the integration tests
<plars> elopio: when I try to run run-tests locally, I get "go tool: no such tool "vet""
<mvo> ogra_: hm, where can I find the options you use for the initrd pi2 compression?
<elopio> plars: checkout the main README
<elopio> you could also go run ./integration-tests/main.go, which will skip the style checks.
<plars> elopio: that's what I was following, I got some other strange errors when I tried running it directly yesterday, but it seems to be running better now
<ogra_> mvo, livecd-rootfs
<ogra_> echo "COMPRESS=lzma" >chroot/etc/initramfs-tools/conf.d/snappy-device-tarball.conf
<ogra_> mvo, line 392 in live-build/auto/build
<ogra_> mvo, data abort seems to be a typpical error if your dtb isnt loaded (or the wrong one was loaded)
<ogra_> mvo, did yu make sure to use the dtb and overlays from the kernel ?
<mvo> ogra_: I compared the uboot.env.in from snappy_ab and snappy_{kernel,os} and they look similar enough, how can I verify the dtb loading? what should I look for?
<ogra_> you would have to interrupt the boot for that and call each command by hand
<ogra_> where does the dtb in your snap come from ?
<mvo> ogra_: from the cdimage device.raspi2 tarball
<ogra_> (did that kernel and dtb boot before in this combo)
<ogra_> that should be fine then
<ogra_> hmm
<mvo> ogra_: yeah, all quite strange. is the bootz call that triggers the crash fwiw
<ogra_> do you still have ${ftdaddr} at the end ?
<mvo> ogra_: yes
<ogra_> and i guess you didnt drop "run loadfiles" from your line
<mvo> ogra_: still there
<mvo> ogra_: here is the diff http://paste.ubuntu.com/13676901/
<ogra_> there is nothing that strikes me as wrong :/
<ogra_> oh !
<kyrofa> Okay so I understand how snappy binaries are launched with a given environment (e.g. with a $SNAP_APP_PATH etc.). But do services not get that environment?
<ogra_> mvo, try replacing ${ftdaddr} with 0x100
<mvo> kyrofa: service get that too
<mvo> ogra_: I noticed this too, but its defined in the file. I will try it anyway
<mvo> ogra_: if its that I really want to know why
<mvo> ogra_: holly cow
<ogra_> and for a test i would also try to drop the whole initrd stuff for one boot
<mvo> ogra_: HOLLY COW
<kyrofa> mvo oh I'm stupid-- it's probably in the systemd config file huh
<ogra_> mvo, ha !
<mvo> ogra_: but but but â¦ WHY?
<ogra_> good question
<mvo> wuuut? "echo ${ftdaddr}
<mvo> "
<mvo> empty?
<mvo> printenv|grep fdt
<ogra_> yeah, thats weird
<mvo> fdtaddr=0x100
<ogra_> something overwrites it at runtime
<mvo> ogra_: *quoting* it seems
<mvo> echo "${fdtaddr}"
<mvo> 0x100
<mvo> I don't understand uboot
<ogra_> the shell is awful
<ogra_> and quoting is a pain ...
<ogra_> crap !
<ogra_> my Rpi has no IP again after boot
<ogra_> despite the fix having landed :(
<ogra_> http://people.canonical.com/~ogra/core-image-stats/20151204.changes
<mvo> ogra_: ok, I don't understand why, I will put 0x100 there and be happy for now but I don't want to touch uboot again, everytime I do it its a rathole (cf the uboot env go code)
<ogra_> mvo, next time just give it to me :)
<mvo> ogra_: I have no idea why I did not 3h ago :/ anyway, let me do an end-to-end test
<kyrofa> mvo so in the systemd conf, I see `SNAP_APP_USER_DATA_PATH=%h/apps/ros-example.sideload/1.0` . Not being familiar with systemd I'll assume %h is the home directory of the running user. However, I'm getting a "ubuntu-core-launcher[2767]: OSError: [Errno 13] Permission denied: '/root/apps'"
<mvo> kyrofa: yeah, there is a open bug about this iirc, jdstrand discussed that some days ago, the apparmor rules deny /root iirc
<kyrofa> mvo, ah, okay makes sense. I suppose I'll wait for a fix, then :)
<kyrofa> Thank you!
<jdstrand> mvo: fyi, the apparmor fix is in. what is needed now is a stable update (for kyrofa's specific issue with services) and a snappy update to adjust the wrapper
<kyrofa> Awesome, thanks for the update jdstrand :)
<jdstrand> np
<kyrofa> jdstrand, can I get a bug number for that, btw?
<jdstrand> mvo: fyi, the snappy task is currently unassigned. I imagine this might be something to backport to 15.04, but I'll let you decide
<jdstrand> sure
<jdstrand> kyrofa: bug #1466234
<ubottu> bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] https://launchpad.net/bugs/1466234
<mvo> jdstrand: thanks, I put on my today for monday morning
<jdstrand> cool, thanks
<kyrofa> elopio, sergiusens #152 has been cleaned up
<sergiusens> kyrofa, nice, was just reading the comments
<kyrofa> Alright, EOD here. Have a great weekend everyone!
<sergiusens> kyrofa, great, I'll probably have this merged as soon as the tests finish running
<sergiusens> kyrofa, enjoy the weekend!
<kyrofa> sergiusens, awesome :) . Safe flight!
<sergiusens> thanks
<sergiusens> kyrofa, oh great, the ros example failed to build...
<sergiusens> catkin one built fine, I'll look into it in a bit
<tedg> kyrofa: I think the removals were needed if there were two catkin parts they conflicted.
<tedg> Ah, reading backlog. Have a good EOW.
<johest> good $localtime, is there any way how I can run python pip based apps on core? I am missing a compiler
#snappy 2015-12-05
<liuxg> if I use the copy plugin in snapcraft.yaml, how can I copy a whole directory?
<Chipaca> greetings from lisbon airport!
<Chipaca> pitti: would you happen to be around?
<mixmax> !list
<ubottu> mixmax: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<Bluefoxicy> does snappy use something other than docker to run containers?
#snappy 2015-12-06
<snappynoob> noob here. installed snappy on rpi2. did update of ubunut-core to v3, hangs on boot. can't get "rollback" to stick, keeps rebooting to update to new version. ideas?
<snappynoob> ZZZzzzz.....
<jp__> hello?
<mds> hi all i need some help with snappy on ubuntu
<mds> sorry i mean on raspberry pi 2
<mds> i need to install a deb package
<mds> but dpg gives an error (unable to access dpkg status area: read only file system)
#snappy 2016-12-05
<mup> Bug #1647256 opened: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:New> <https://launchpad.net/bugs/1647256>
<mup> PR snapd#2400 closed: snap: support for parsing and exposing on snap.Info aliases <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2400>
<sangorrin> hi, I am interested in knowing how the seccomp profiles for each snap package are generated. Is it done by brute force? or is there a binary analysis tool?
<sangorrin> From the docs here it looks like brute force https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<sangorrin> but in that case, one would need tests that achieve 100% path coverage for each package
<dholbach> hey hey
<mup> PR snapd#2386 closed: interfaces/builtin: fix incorrect udev rule in i2c <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2386>
<mup> PR snapd#2405 opened: fix unhandled error from io.Copy() in download() for 2.18.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2405>
<mvo> ogra_: hey, good morning! just a quick question - are all our kernels up-to-date and ready for candidate? I would love to create a candidate image for qa for testing today and was wondering if there is anything that needs to be done for the kernels
<vigo> mvo, morning! please let me know when the images are ready for qa :)
<mvo> vigo: thank you! will do, but I expect this afternoon
<foxmask> bonjello
<vigo> mvo, ack
<mup> PR snapd#2406 opened: many: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2406>
<mrrpc> hi
<mrrpc> i have some questions
<mrrpc> anybody is there?
<davmor2> mrrpc: just ask if people can answer they will
<mrrpc> i work qt in ubuntu
<mrrpc> i dont know how make package
<mrrpc> i try to read some guild but i didnt get it
<mrrpc> guide*
<mrrpc> how can i turn my qt project to snap package
<mrrpc> ty for your help
<mrrpc> such useful channel
<mup> PR snapd#2407 opened: wrappers: add support for the X-Ayatana-Desktop-Shortcuts= extension <Created by mvo5> <https://github.com/snapcore/snapd/pull/2407>
<ogra_> mvo, i think they are
<mvo> ogra_: excellent, thank you
<mup> PR snapd#2252 closed: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2252>
<mup> PR snapd#2408 opened: daemon: fix crash when `snap refresh` contains a single update <Created by mvo5> <https://github.com/snapcore/snapd/pull/2408>
<mup> PR snapd#2409 opened: daemon: fix crash when `snap refresh` is called and there is a single update <Created by mvo5> <https://github.com/snapcore/snapd/pull/2409>
<mup> Bug #1647333 opened: adduser misses extrausers support for group management <Snappy:New> <adduser (Ubuntu):New> <https://launchpad.net/bugs/1647333>
<mup> PR snapd#2405 closed: fix unhandled error from io.Copy() in download() for 2.18.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2405>
<mup> Bug #1646968 opened: There's something weird about /tmp <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1646968>
<julio__> how do i set a static ip address on ubuntu core 16?
<mup> PR snapd#2408 closed: daemon: fix crash when `snap refresh` contains a single update <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2408>
<ogra_> via console-conf
<ogra_> either during the first boot setup wizard or later via "sudo console-conf"
<julio__> let me try that
<zyga> daker: hey
<zyga> er
<daker> zyga: hey :D
<zyga> daker: sorry, I didn't mean to target you, bad tab-complete
<zyga> but hey :)
 * zyga needs to talk to jdstrand about classic confinement 
<daker> zyga: lol yeah i just wanted to say hey too :D
<zyga> jdstrand: tl;dr; snap-confine seems to work, one branch on snapd (the older apparmor branch will land as soon as tests go green), snap-confine will land via snapd after the merge; I'll work on snapd merge now
<zyga> jdstrand: there's a call with sergiusens today to talk about the snapcraft story
<jdstrand> hey zyga
<zyga> jdstrand: hi :)
<jdstrand> zyga: note that the store bits are in the process of landing
<zyga> jdstrand: I'm never sure at which time you're around :)
<zyga> jdstrand: great, I only tested side loading for now
<zyga> jdstrand: but both that and store side shoud be OK from the code POV
<jdstrand> zyga: 1400 UTC in standard time
<zyga> jdstrand: offtopic, I've merged the errors branch in anticipation of the merge into snapd, I wanted to see how new files show up
<zyga> jdstrand: if you want to make changes to that still, feel free to comment and I'll address that
<zyga> jdstrand: but I got two other +1's and it's not used in anything yet
<jdstrand> zyga: actually I should clarify. the review tools part is done and a store pull is being done. there is a store side change for the review tools form and sending classic to the review tools for subsequent uploads that needs to be implemented (the store team is doing that)
<jdstrand> zyga: you mentioned things in the store needing review. I don't see them. did you request a manual review?
<zyga> jdstrand: no, I didn't upload my snap yet actualy
<zyga> jdstrand: I'll do that later today
<jdstrand> roadmr: hi! fyi, can you pull r809. that's the last one from me for the moment
<roadmr> jdstrand: sure thing
<renato__> mvo, hey, could you publish this package on store under canonical ownership? https://code.launchpad.net/~phablet-team/+snap/ubuntu-notes-app/+build/12605
<jdstrand> roadmr: thanks!
<mvo> renato__: sure
<boriseto-work> Hi, I've noticed that some snaps use a different cursor or theme whatsoever (my guess would be because of sandboxing).
<boriseto-work> Is there a way to change the cursor theme at least for some apps (like the VLC snap)?
<mup> PR snapd#2384 closed: snap: add snap size to `snap info` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2384>
<mup> PR snapd#2393 closed: interfaces/apparmor: use distinct apparmor template for classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2393>
<Elleo> mterry: any idea why the unity8 snap seems to have access to /etc, I can't seen general /etc access in any snapd interfaces (only to specific files/directories)?
<Elleo> mterry: see*
<zyga> jdstrand: do you want to be at the call in 30 minutes concerning snapcraft and classic?
<jdstrand> zyga: I don't think I need to be there unless someone else does. I gave my update regarding the review tools to you
<elopio> cjwatson: I'm still fighting with my armhf branch, but that particular problem seems fixed.
<elopio> I'll reply to the rt.
<mterry> Elleo: it's an unconfined snap
<Elleo> mterry: I didn't think unconfined snaps could access the filesystem unconfined though? because it doesn't seem to be able to access /usr
<mterry> Elleo: there may be mount points getting in its way with parts of /usr
<cjwatson> elopio: thanks
<Elleo> mterry: ah, okay
<mterry> Elleo: on Classic, it mounts the Core snap on top of system
 * zyga nods
<zyga> thanks jdstrand :)
<Elleo> mterry: the problem I was running into was that with the keyboard in the unity8 snap it reads the presage config from /etc/presage.xml on the host if it exists and so then tries to use the paths in there to access its file in /usr/share/presage instead of the snap paths that we fallback to when /etc/presage.xml isn't there
<mterry> Elleo: interesting...  Sounds like we need to fix the path so that it doesn't read fro /etc/presage.xml
<mterry> Elleo: do you know what reads that?  (i'm not familiar with presage)
<mup> PR snapd#2403 closed: store: fix unhandled error from io.Copy() in download() <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2403>
<Elleo> mterry: currently we have presage patched so that it'll use an environment variable to fill in its paths if it can't read /etc/presage.xml which works fine on properly confined snaps and systems without presage installed on the host
<Elleo> mterry: presumably the goal is to fully confine unity8 in the future, so this problem would go away then
<Elleo> mterry: otherwise I could patch presage further to read its config from a modified path in snaps
<mterry> Elleo: maybe...  But still. Seems like the patch should unconditionally use $SNAP if it is defined, instead of assuming the read will fail
<mterry> Elleo: in future, anytime somebody wants to test some new feature for a bit in u8 and installs with --devmode, they'll hit this bug agian
<Elleo> mterry: true
<Elleo> mterry: okay, I'll prepare a new patch for presage do handle things differently
<balloons> zyga, is there a bug / issue / place I can follow "classic confinement" work? This is the implementation of utility snaps right.
<didrocks> noise][: hey, it seems that the tokens for the 2 snaps you posted expired for me as well
<didrocks> noise][: any hint on getting a new token so that I can report behaviors here?
<didrocks> it seems that niemeyer just paste the url without checking the token, so that didn't help
<noise][> didrocks: i'm not quite following - if you start with a store download URL, e.g.   "https://public.apps.ubuntu.com/anon/download-snap/asXOGCreK66DIAdyXmucwspTMgqA4rne_1.snap", that should always work
<noise][> it will redirect to CDN url w/a fresh token in the query-string
<didrocks> noise][: if I curl -v your download URL, I'm getting the 302
<didrocks> noise][: ah got it, thanks
<noise][> right, and that 302 should come with a Location: header telling you where to redirect to
<didrocks> but then 403 Forbidden
<didrocks> let me try with another one
<noise][> shouldn't - can you paste the full req w/headers there?
<didrocks> noise][: curl -v https://068ed04f23.site.internapcdn.net/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?t=2016-12-06T15:21:25Z returns: http://pastebin.ubuntu.com/23583779/
<noise][> your URL is incomplete - did you miss quoting it?
<noise][> and it helps when paste-binning to include the full cmd-line, not just the output
<noise][> there should be t=â¦&h=...
<elopio> attente: hello! If your integration test is passing locally, and failing just on the launchpad runners, it must be a proxy issue. It's the only thing that I can think of.
<didrocks> noise][: oh yeah, my middle paste stripped it, here we go: http://pastebin.ubuntu.com/23583790/
<didrocks> noise][: but -L works
<noise][> didrocks: if you don't quote that URL it will fail
<noise][> because of the &
<didrocks> noise][: yeah, I went a little bit too fast :)
<attente> elopio: thanks, do you know what i should do to fix that? it's an issue on the github side right?
<zyga> balloons, cwayne: https://github.com/zyga/hello-classic
<cwayne> spineau: ^
<spineau> :)
<vigo> mvo, any news about the candidate images?
<mvo> vigo: unfortuantely there are some issues with the store currently, we are working on it, might get delayed until later tonight/tomorrow morning, depends on if I can find a workaround or not
<vigo> mvo, ack thanks for the update :)
<zyga> jdstrand: https://github.com/zyga/hello-classic (if I forgot and pasted this already sorry :)
<jdstrand> cool
<mup> PR snapcraft#917 closed: Fix unittests in armhf <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/917>
<mup> PR snapcraft#945 opened: Fix unittests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/945>
<Chipaca> didrocks, ping
<Chipaca> didrocks, ng
<Chipaca> hrm, something is wrong with my irc client
<Chipaca> bbiab
<Chipaca> (it's truncating my lines)
<Chipaca> didrocks: ping
<Chipaca> (much better!)
<didrocks> Chipaca: I fully see the difference :)
<didrocks> yes? ;)
<Chipaca> didrocks, first time it looked to me like i'd just said "pi"
<Chipaca> happens every so often; haven't had time to hunt it down yet
<Chipaca> didrocks, i was wondering if you'd care to test something for this flaky download thing
<Chipaca> didrocks, test something as in run a binary i gave you
<didrocks> Chipaca: sure, no worry
<Chipaca> ok, i'll write it up and give you a shout then
<didrocks> Chipaca: I'm going to leave in ~30 minutes, send me an email if I'm not around and I'll test it before you start your day
<elopio> attente: no, the proxy is handled by IS. So an RT.
<attente> elopio: ok, thanks
<elopio> it's weird however, because those runners should be open to everything. I don't have a way to try it.
<Chipaca> didrocks, are you on amd64?
<didrocks> Chipaca: I am, but the binary will be for the Pi, no?
<Chipaca> didrocks, ah, your problem is on the pi? i hadn't noticed
<Chipaca> didrocks, give me a sec
<didrocks> Chipaca: oh, I got your 'I'd just said "pi"' wrong then :)
<Chipaca> didrocks, https://people.canonical.com/~john/schmurl_arm
<Chipaca> didrocks, https://people.canonical.com/~john/schmurl if you're wanting to run it on amd64
<Chipaca> this just downloads a thing, discarding it, and computes the sha3-384
<didrocks> Chipaca: ok, I guess standard go lib?
<Chipaca> didrocks, sha3 isn't in the stdlib, and i added a funky progress bar, but otherwise yes
<didrocks> oki
<didrocks> (Pi rebooting, one sec)
<Chipaca> it *should* look like:
<Chipaca> $ schmurl https://public.apps.ubuntu.com/anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap e83c241ece25cbc43f625b37546e2c4f6320d4c58492fa7a1ddb8045d847a8bfc051a4c616cda5ca07a3c272a33e4e61
<Chipaca>  * Wrote  23 MB in 4.22s (5.4 MB/s)
<Chipaca> got sha: e83c241ece25cbc43f625b37546e2c4f6320d4c58492fa7a1ddb8045d847a8bfc051a4c616cda5ca07a3c272a33e4e61
<Chipaca> OK
<Chipaca> but, you tell me
<didrocks>  * Wrote 1.1 MB in 1.06s (1.0 MB/s)read tcp 10.42.0.14:56162->77.242.195.171:443: read: connection reset by peer
<didrocks> Chipaca: ^
<Chipaca> didrocks, and if you try again?
<didrocks> same, (well after 1.3MB)
<didrocks> some a few hundreds of kB
<Chipaca> didrocks, interesting
<didrocks> yeah, matching at least snapd behavior
<Chipaca> didrocks, and on this same box wget doesn't tell you it's resuming stuff?
<didrocks> Chipaca: no, neither curl
<didrocks> maybe they are resuming under the cover, or have some longer timeout than the go lib
<didrocks> (for micro-interruption)
<Chipaca> didrocks, ok, thank you
<Chipaca> didrocks, i won't have time to get you something that retries before you go off (and i should get back to other stuff anyways)
<Chipaca> but maybe later this evening i can cook something up for you to try tomorrow
<didrocks> Chipaca: sure, thanks for looking at it!
<Chipaca> niemeyer, not sure how relevant the above is to your thoughts on this issue (the 'connection reset by peer' i mean)
<niemeyer> Chipaca: Readling
<niemeyer> Chipaca: Yeah, definitely useful
<mvo> Chipaca: woah, thanks for chasing this
<Chipaca> it itched so i scratched :shrug:
<niemeyer> Chipaca:  I was planning on handing didrocks actual snap/snapd, but that might be enough
<niemeyer> Chipaca: That might be lack of keep alives
<Chipaca> or excess of them, reading some bugs on github
<niemeyer> Chipaca: Can you enable them and hand didrocks an update?
<Chipaca> niemeyer, he's leaving right about now
<Chipaca> niemeyer, i think the default transport has them enabled anyway; let me confirm
<didrocks> well, if it's just a flag and for 5 minutes, I can wait
<didrocks> but yeah, if the issue was a keep alive TLS flag missing, that would make sense
 * niemeyer Chipaca: ```
<niemeyer>         // KeepAlive specifies the keep-alive period for an active
<niemeyer>         // network connection.
<niemeyer>         // If zero, keep-alives are not enabled. Network protocols
<niemeyer>         // that do not support keep-alives ignore this field.
<niemeyer>         KeepAlive time.Duration
<niemeyer> Chipaca: From net.Dialer
<Chipaca> niemeyer, yes, and DefaultTrasport has it set to 30 seconds
<Chipaca> niemeyer, and http.Transport has a DisableKeepAlives that defaults to false
<niemeyer> Chipaca: Which DefaultTransport?
<Chipaca> niemeyer, http.DefaultTransport
<didrocks> FTR, the failure happens suddently (there is no like hangs for multiple seconds before failure)
<Chipaca> niemeyer, the one http.DefaultClient uses
<didrocks> suddenly*
<Chipaca> didrocks, yeah, it's like you're getting a tcp reset
<niemeyer> didrocks: How long does the download last, usually?
<niemeyer> didrocks: The failing one, that is
<Chipaca> niemeyer, above, ~1s
<didrocks> niemeyer: I would say ~1s/2s
<niemeyer> Ok, that would be an EXTREMELY short timeout :)
<didrocks> yep :)
<niemeyer> Even then, Chipaca can we try a super short keep alive, just in case?
 * didrocks has to go now, just send me an email with links to the binaries to try out and I'll do before you start your day
<niemeyer> didrocks: Thanks for your help, let's restart the debug session when you're back
<didrocks> niemeyer: sounds good! Thanks for looking at it
<mup> PR snapd#2410 opened: store: retry resumed downloads on sha3 <Created by stolowski> <https://github.com/snapcore/snapd/pull/2410>
<niemeyer> Chipaca: So yeah, you're right about our keep alives, and I can't see anything obvious
<Chipaca> niemeyer, you want to try with a tiny keepalive?
<Chipaca> was just about to send the mail with that
<niemeyer> Chipaca: It sounds worth, at least to rule that one bit out.. but I think it'd be more productive for us to reunite with didrocks here again instead of over email
<niemeyer> Chipaca: One thing I'm wondering is this: we override the transport with our LoggedTransport
<Chipaca> yep
<niemeyer> Chipaca: But we don't actually use the original one as an embedded field
<Chipaca> yes, we do
<niemeyer> Chipaca: I'm wondering if http is internally looking at some property of the original http.Transport to make decisions
<niemeyer> Chipaca: We do?
<niemeyer> Chipaca: I'm looking at the code right now.. I don't think we do
<Chipaca> niemeyer, https://github.com/snapcore/snapd/blob/master/store/logger.go#L104
<niemeyer> Chipaca: Exactly.. look at line 56 where this type is defined
<Chipaca> ah, *embedded*, no
<niemeyer> Right
<Chipaca> niemeyer, but my test doesn't use this, fwiw
<niemeyer> I've seen the http package doing such dirty decisions before.. looking at the interface of the thing beyond what it claims to expect
<Chipaca> it's  just http://pastebin.ubuntu.com/23584257/
<Chipaca> (well, that's with the teeny keepalive)
<niemeyer> Chipaca: Ah, even better! Thanks!
<niemeyer> Chipaca: That last timeout feels pretty short at 1 second
<niemeyer> I wonder why it's so short
<niemeyer> I guess we're not using that anyway
<Chipaca> niemeyer, because the client is stuck waiting for a response, i guess?
<Chipaca> expect: 100-continue is rather funky
<Chipaca> basically if you don't get a reply fast enough it's recommended that you try again without that header
<Chipaca> as the only purpose of that header is to make things faster
<Chipaca> but anyway, we're not using it, as you say
<mup> PR snapcraft#946 opened: meta: support classic confinment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/946>
<niemeyer> Chipaca: Wonder if we can reproduce that issue using the pi2 image Federico made work under qemu
<Chipaca> niemeyer, i missed that! where is it?
<niemeyer> Chipaca: I think he's been doing that on the fly only, actually..
<niemeyer> Chipaca: That is, getting the image prepared and run under Linode
<kissiel> hey folks, snapcraft master is broken for me - cannot snap anything from playpen - exits happlity after two lines https://paste.ubuntu.com/23584339/
<kissiel> my git bisect suggest 9212dac broke it
<kyrofa> kissiel, what specifically are you trying to build?
<kissiel> kyrofa: my bisect was running snapcraft clean && snapcraft snap in hellogl
<kissiel> from playpen
<kyrofa> kissiel, I'll take a look this morning, thanks for the heads up!
<kissiel> kyrofa: http://paste.ubuntu.com/23584353/
<kissiel> that's how I tested
<kissiel> \o/ happy to help
<kyrofa> kissiel, hmm... I can't duplicate
<kyrofa> kissiel, any chance you could try the version in proposed instead of from a venv?
<kissiel> kyrofa: sure, I'll try it out in a bit
<kyrofa> kissiel, I appreciate the help-- definitely would rather not break the next release
<kissiel> :>
<kissiel> kyrofa: which proposed? ppa for tools-proposed?
<kyrofa> kissiel, ah, no, just xenial-proposed
<kyrofa> kissiel, are you familiar with that?
<kissiel> kyrofa: general xenial-proposed (like an archive)?
<kyrofa> kissiel, yeah, but you want to be careful. The proposed archive contains all the brand new packages that are pending a migration to Updates-- not something you want to enable for everything
<kyrofa> kissiel, read this real quick: https://wiki.ubuntu.com/Testing/EnableProposed
<kissiel> kyrofa: yeah, running in a vm
<kyrofa> Basically, enable it, and then do the "Selective upgrading from -proposed" step
<kissiel> well snapshoted
<kyrofa> Ah, handy
<kissiel> kyrofa: I'm asking, b/c the commit that broke it for me was from last friday
<kyrofa> Once you make that file in /etc/apt/preferences.d, you can `sudo apt install snapcraft/xenial-proposed`
<kissiel> unless you push every landing to proposed...
<kyrofa> kissiel, we don't, but we rolled a new release on Friday that includes that commit
<kissiel> kyrofa: ok, gimme a few minutes
<kyrofa> kissiel, make sure snapcraft isn't installed by any other means (it's okay if the deb is installed, though)
<kissiel> roger that
<mup> PR snapd#2409 closed: daemon: fix crash when `snap refresh` is called and there is a single update <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2409>
<kissiel> kyrofa: 2.23 from proposed works
<kyrofa> kissiel, huh, odd
<kyrofa> kissiel, but good, because that's what would be released
<kissiel> kyrofa: am I doing something wrong with my venving?
<kyrofa> kissiel, no, but honestly we don't run from a venv very often-- it's not a well-tested way of running snapcraft
<kyrofa> kissiel, admittedly it should be, and we're trying to make it better
<kissiel> kyrofa: :[ hacking.md mentions it, and btw. how do you develop?
<kyrofa> kissiel, I just add <snapcraft root>/bin to my PATH
<kyrofa> kissiel, it takes care of the imports
<kissiel> kyrofa: right... I've also noticed while working from venv that my changes are ignored unless I rerun ./setup.py
<kyrofa> kissiel, one of the reasons we don't use it
<kissiel> kyrofa: well, that explains a lot
<kissiel> kyrofa: zyga just told me that what I was debugging is not a bug, and my whole experience today was a total nightmare because of venv
<kissiel> that's very Monday
<kyrofa> kissiel, haha, no kidding!
<kyrofa> kissiel, it's potty training day around here, so my Monday isn't so hot either ;)
<kissiel> kyrofa: TYVM for the explanation; at least my machine nor I are going mad
<zyga> kissiel: are you going to hack on snapcraft more?
<kissiel> zyga: my crystal ball says it's inevitable
<kyrofa> kissiel, any time!
<mup> PR snapd#2411 opened: History <Created by renatofilho> <https://github.com/snapcore/snapd/pull/2411>
<kyrofa> Hey jdstrand if you have a minute, could you take a look at https://askubuntu.com/questions/857386/snap-cant-handle-app-using-libappindicator-and-ends-up-with-error ?
<mup> PR snapd#2399 closed: Add /dev/uhid to bluetooth-control interface <Created by bergotorino> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2399>
<kyrofa> Hey ogra_, you around?
<jdstrand> kyrofa: I think Trevinho would be a better person to answer that question (https://askubuntu.com/questions/857386/snap-cant-handle-app-using-libappindicator-and-ends-up-with-error). He gave an update on the list and knows all the corner cases, etc
<kyrofa> jdstrand, alright, thanks for the redirect :)
<mup> PR snapcraft#945 closed: Fix unittests in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/945>
 * Chipakeitor waves
<cholcombe> sergiusens, do you have the power to land this?  https://github.com/snapcore/snapcraft/pull/908 I'd like to fork it but it's much easier if it lands before I built a change on top of it
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<cholcombe> actually anyone with merge powers :) ^^
<kyrofa> icey, speaking of that ^^ would you mind somehow tying the email address you used in those commits back to your LP account? Either commit with @canonical or put your GH email in LP?
<icey> kyrofa: the last commit on https://github.com/snapcore/snapcraft/pull/908 should now have my @canonical email on it
<mup> PR snapcraft#908: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/908>
<kyrofa> icey, you know you have two LP accounts, right?
<icey> oh?
<icey> https://launchpad.net/~chris.macnaughton is probably the one you want
<kyrofa> icey, indeed, but your gmail address is registered to chmacnaughton
<kyrofa> icey, if you're going to work with the gmail address, you might consider consolidating, it makes it hard to verify who you are exactly ;)
<icey> done kyrofa
<kyrofa> icey, perfect. cholcombe that PR will be merged as soon as the updated tests pass. Thanks icey :)
<cholcombe> kyrofa, awesome!
<mup> PR snapcraft#947 opened: Add 'aliases' support to 'apps' <Created by josepht> <https://github.com/snapcore/snapcraft/pull/947>
<mup> PR snapd#2398 closed: cmd/snap: change terms accept URL following UX review <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2398>
<ahoneybun> sitter: has anyone looked to snap peruse or minuet?
<ahoneybun> I'm trying to find your blog post about the shared snap
<ahoneybun> snap content
<mup> PR snapd#2404 closed: interfaces/builtin: updates to dcdbas-control interface <Created by tonyespy> <Closed by tonyespy> <https://github.com/snapcore/snapd/pull/2404>
#snappy 2016-12-06
<mup> PR snapcraft#948 opened: Use testtools as the base of all unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/948>
<mac_nibblet> Can someone please explain the workflow when developing stuff with snapcraft ?
<mac_nibblet> I find it rather tedious to run a clean, download everything again and then install just to test changes to our application
<mac_nibblet> Anybody up for some paid support
<mac_nibblet> ?
<Omou> ?
<Omou> is here somebody
<mup> PR snapd#2401 closed: snap: abort install with ctrl+c <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2401>
<ogra_> mvo, hmm, there was just a new set of kernels released
<zyga> ogra_: hey :)
<ogra_> yo
<mvo> ogra_: cool, did the new lp script tell you? or some other way?
<ogra_> mvo, my mail client did :P
<mvo> ogra_: new -update? if so, I think we want that in beta and then candidate
<mvo> ogra_: heh
<ogra_> ok, i'll take care
<mvo> ta
<mup> PR snapd#2412 opened: snap: add description to `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2412>
<mup> PR snapd#2413 opened: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413>
<ogra_> mvo, all kernels in beta, do we have any specific criteria before releasing to candidate atm ?
<ogra_> (the store is so sloooow)
<mvo> ogra_: a smoke test for now, I think we want something better long term but for now booting all supported boards with the new kernel is the sufficient
<ogra_> ok
<mup> PR snapd#2414 opened: store: switch default delta format from xdelta to xdelta3 <Created by wgrant> <https://github.com/snapcore/snapd/pull/2414>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2413
<mup> PR snapd#2413: interfaces/apparmor: allow access to core snap <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2413>
<mup> PR snapd#2415 opened: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <https://github.com/snapcore/snapd/pull/2415>
<zyga> jdstrand: ^^
<mup> PR snapd#2406 closed: many: add support for classic confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2406>
<mup> PR snapd#2416 opened: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<liuxg> ogra_, ping
<ogra_> yo
<liuxg> ogra_, I just followed your suggestion to extract the arm64 file at http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/, I unziped the file, and now when I use "sudo chroot rootfsarm64". it gives me an error like http://paste.ubuntu.com/23588275/
<liuxg> ogra_, what could be the problem for it? thanks
<ogra_> liuxg, did you copy the qemu-$arch-static binary in place ?
<liuxg> ogra_, yeah, I just realized that. thanks for your reminding :)
<ogra_> this isnt different from using debootstrap ;)
<ogra_> (just that you save all the deb unpacking and configuring time)
<liuxg> ogra_, yes, it works now. thanks. I will try to explore it and see how it works :)
<ogra_> :)
<mup> PR snapd#2417 opened: Add uhid interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2417>
<liuxg> ogra_, after I enter the chroot, some things are not there. for example, vi is not in the package. I need to install more things
<mup> PR snapcraft#931 closed: parser: add support for origin-{branch,commit,tag} <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/931>
<mup> PR snapcraft#946 closed: meta: support classic confinment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/946>
<ogra_> liuxg, hmm, vi should definitely be in there, thats weird
<ogra_> oh, no, it shouldnt, since thats a buildd tarball
<liuxg> ogra_, http://paste.ubuntu.com/23588349/, this is what looks like here.
<ogra_> yeah
<ogra_> it is what you would get using debootstrap --minbase
<ogra_> a typical build chroot
<Chipaca> didrocks, could you strace the 'plain' schmurl?
<Chipaca> didrocks, (hello! etc :-/)
<liuxg> ogra_, also I got some installation issues like http://paste.ubuntu.com/23588353/. it looks not so predicable :)
<didrocks> Chipaca: hey! sure, do we have a snap ready with it? I think I will just copy the armhf binary there if not
<Chipaca> didrocks, i've always just copied the binary
<didrocks> ok!
<didrocks> you want a full strace, no option?
<ogra_> liuxg, did you "apt update" first (thats not different to how you should do debootstrap)
<liuxg> ogra_, yes, I did that in the first place
<Chipaca> didrocks, -f -s 4096, i think
<ogra_> weird
<mup> PR snapd#2418 opened: snapstate/backend: add backend methods to manage aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2418>
<didrocks> Chipaca: will give it to you in a few minutes
<ogra_> (given that all our build machines use these tarballs ...)
<Chipaca> didrocks, perfect
<liuxg> ogra_, yeah, it looks like it is not so doable in this method. :)
<ogra_> well, looks like not all components are switched on in sources.list (perhaps only main ?)
<ogra_> it is definitely the cleaner way ... but if it starts getting to complex to explain in the howto better go with debootstrap
<liuxg> ogra_, if I try to use apt-get -f install, I get http://paste.ubuntu.com/23588370/. yeah, I think you have a point. A lot of things are commented out there.
<liuxg> ogra_, in fact, the installation is very straightforward, just extract it, and that's it. could it be that it is not daily build?
<ogra_> oh, you need to mount /sys and /proc (and if you feel like also devpts), but thats not different with the debootstrap chroot
<ogra_> without these dirs mounted any chroot will have issues
<ogra_> (regarding package installs at least)
<ogra_> the "current" tarballs are definitely from tonight
<didrocks> Chipaca: here we go: http://paste.ubuntu.com/23588377/
<Chipaca> ah
<popey> sergiusens: bug 1612818 - Is there any plan to up the priority of this from wishlist?
<mup> Bug #1612818: Ruby breaks when snapped <isv> <new-plugin> <Snapcraft:Triaged> <https://launchpad.net/bugs/1612818>
<Chipaca> didrocks, could you do it again, but this time redirecting stdout?
<didrocks> Chipaca: sure
<Chipaca> didrocks, so i don't need to wade through the pretty progress bar thing :-)
<popey> sergiusens: we have software we've rejected snapping because of the lack of ruby plugin)
 * Chipaca lazy
<liuxg> ogra_,  yeah, I think it is better go with the debootstrap solution :)
<ogra_> liuxg, wqell, 80% of the above needs to be solved there too ... you always need to mount /proc and /sys if you enter a chroot (and unmount it when you leave) etc ... but yeah, missing bits in sources.list is indeed bad
<didrocks> Chipaca: wait, I didn't take it in the first place to the logs so that you are not bothered with it
<didrocks> Chipaca: so, you meant, you want me to redirect stdout to /dev/null so that you don't have the write()/ioctl?
<Chipaca> didrocks, the progress bar addds ioctl()s and weird prints to the log
<Chipaca> exactly
<didrocks> yeah, you detect the output type and disable it
<didrocks> got it :)
<Chipaca> as all progress bars should :-D
<didrocks> Chipaca: don't force me to give some examples of python modules I know of :)
<Chipaca> didrocks, there's a reason i wrote this progress bar myself :-)
<didrocks> Chipaca: btw, what's the name of the go progressbar project you are using? I'm interesting for some personal projects :)
<didrocks> ah, it's yours ;)
<Chipaca> didrocks, i think next weekend i'll be publishing it
<Chipaca> it's not "there" yet
<didrocks> great! keep me posted
<didrocks> Chipaca: http://paste.ubuntu.com/23588390/
<didrocks> (file is a little bit bigger as the download went further down)
<liuxg> ogra_, anyway, thanks for your tips :)
<Chipaca> didrocks, and i have a bug in progress where it's still doing ioctls :-) darnit
<ogra_> np, sad it doesnt work out for you
<Chipaca> didrocks, anyway, thank you; this is what i needed
<liuxg> ogra_, anyway, I still learn a lot out of it :)
<didrocks> Chipaca: yeah, I noticed it ;) at least, you don't have the write()
 * Chipaca nods
<ogra_> :)
<Chipaca> didrocks, it's just checking whether the fd suddenly became a terminal, by magic
<Chipaca> didrocks, it should do that check once at the start methinks -- unless file descriptors can suddenly become terminals :-)
<didrocks> "suddenly" :-)
<didrocks> yeah, only once will make sense :)
<ogra_> everything is a file !
<Chipaca> didrocks, could you also strace curl?
<didrocks> yep, doing
<didrocks> Chipaca: hum, logs are 50M
<Chipaca> hehe
<Chipaca> didrocks, gzip it and put it on p.c.c?
<didrocks> Chipaca: yep, ofc, you have the 30M snap in it :)
<didrocks> with the write() ops
<sergiusens> popey well we need someone who knows ruby, lately all the plugins have been externally contributed except for the python a go ones which I've catered for; also wishlist is the status only because it is not a bug, it is a feature request
<Chipaca> didrocks, ah, you can drop the -s option there if you want
<Chipaca> didrocks, :-/
<popey> sergiusens: so we basically need someone who knows python + ruby?
<didrocks> Chipaca: ok, doing, will be easier for you to read
<sergiusens> popey if we can get someone that knows ruby I can work on the plugin code itself
<popey> ok
<didrocks> Chipaca: less than 2 Megs: http://paste.ubuntu.com/23588441/
<mup> PR snapcraft#949 opened: project: support building classic snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/949>
<renato__> mvo, hey, could you review the pending reviews for package: 6453
<kalikiana_> snapd master seems to be aborting instantly on startup for me - could there be a regression? Or something changed that'd require updating something else?
<zyga> kalikiana_: can you share any error messages or logs please?
<kalikiana_> zyga: None, except for "Terminated" as far as I can see
<zyga> kalikiana_: anything in journalctl -u snapd
<kalikiana_> -- No entries --
<kalikiana_> Non-snapd entries are there for failing to connect to snapd
<kalikiana_> (Because it's not running, obviously)
<kalikiana_> zyga: ^^
<zyga> interesting and odd
<kalikiana_> I tried going back some revisions but even a half month makes no difference
<kalikiana_> So I suspect something in the system other than snapd changed
<kalikiana_> zyga: There was a dependency change that required "go get" at one point, any idea if that might be related?
<kalikiana_> It's the only change I'm aware of
<kalikiana_> Other than whatever might've changed in an update of the base system
<Chipaca> didrocks, in the curl strace with the big -s, could you grep for HTTP/ (including the /) please?
<didrocks> Chipaca: no result
<jdstrand> zyga: I don't really understand the motivation for 2413
<Chipaca> didrocks, are you sure that's in the big trace?
<Chipaca> didrocks, ah, case-insensitively please
<jdstrand> zyga: basically, we have the default template that allows certain reads, and this rule that allows reading everything
<didrocks> Chipaca: ah, case-insensitivity returns 2 results:
<didrocks> send(4,
<didrocks> "\26\3\1\1\21\1\0\1\r\3\3XF\277\341\302\237M\257\205\355\207\344\36\372i\307\21\250\350d\246\257\357\307\17oxUl\303\324m\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\30
<didrocks> 0\236\300\237\0\26\1\0\0x\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0\33\0\31\0\0\26public.apps.ubuntu.com\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 278, MSG_NOSIGNAL) = 278
<didrocks> send(5, "\26\3\1\1\32\1\0\1\26\3\3XF\277\260\330B\204g\307@\n(\271\22\31\257I\n\312\335\21\7
<didrocks> \n\256\341L\264\f\347\17\222\0\0l\300+\300,\300\206\300\207\300\t\300#\300\n\300$\300r\300s\300\254\300\255\300\10\300/\3000\300\212\300\213\300\23\300'\300\24\300(\300v\300w\300\22\0\234\0\235\300z\300{\0/\0<\0005\0=\0A\0\272\0\204\0\300\300\234\300\235\0\n\0\236\0\237\300|\300}\0003\0g\0009\0k\0E\0\276\0\210\0\304\300\236\300\237\0\26\1\0\0\201\0\27\0\0\0\26\0\0\0\5\0\5\1\0\0\0\0\0\0\0$\0\"\0\0\037068ed04f2
<didrocks> 3.site.internapcdn.net\377\1\0\1\0\0#\0\0\0\n\0\f\0\n\0\27\0\30\0\31\0\25\0\23\0\v\0\2\1\0\0\r\0\26\0\24\4\1\4\3\5\1\5\3\6\1\6\3\3\1\3\3\2\1\2\3\0\20\0\v\0\t\10http/1.1", 287, MSG_NOSIGNAL) = 287
<Chipaca> thx
<didrocks> I guess it's the first request + redirect?
<jdstrand> zyga: and why do classic snaps care about about this? if they do care, can't we add this rule conditionally on jailmode (plus, I thought that we didn't support jailmode with --classic)
<Chipaca> didrocks, yep
<mup> PR snapd#2419 opened: store: retry downloads on io.Copy errors <Created by stolowski> <https://github.com/snapcore/snapd/pull/2419>
<Chipaca> didrocks, are you in a position to wireshark the pi's connection?
<Chipaca> didrocks, forget it, https. Let me think some more.
<ahasenack> is there a way to prevent snaps from auto-upgrading?
<zyga> jdstrand: because gustavo argued to have --jailmode that turns classic snaps into regular confined snaps
<Chipaca> didrocks, could you run it again, the very first schmurl, pointing at http://lenticularis.chipaca.com/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap please?
<alex-abreu> Chipaca, quick question, ... the List & Find snapd client results dont contains the list of plugs & slots requested & defined by the snap, I was thinking about creating a PR to add them to the snapinfo as strings, wdyt?
<mup> PR snapd#2268 closed: many: merge snap-confine into snapd <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2268>
<Chipaca> alex-abreu, what for?
<didrocks> Chipaca: 3 downloads in a row, they all completed with success. So clearly a store <-> client interaction
<Chipaca> didrocks, not so quick, little one :-p
<alex-abreu> Chipaca, they are required in snapweb, as snap met ainfo
<didrocks> ;)
<Chipaca> didrocks, and now https://people.canonical.com/~john/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap
<didrocks> Chipaca: success as well
<Chipaca> alex-abreu, how would you get the ones from the store?
<Chipaca> didrocks, and https://068ed04f23.site.internapcdn.net/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?t=2016-12-07T13:58:28Z&h=35c698e528ac75d574ed395ecc3144ebff6a238b ? (don't forget to quote it)
<alex-abreu> Chipaca, the store lists the plugs & slots
<Chipaca> alex-abreu, but you don't talk to the store
<alex-abreu> Chipaca, maybe I am missing your point, but snapd/client/packages.go Find does in the backend ...
<didrocks> Chipaca: dropping after few Kb or Mb downloaded
<didrocks> with the same reset by peer
<Chipaca> didrocks, and https://public.apps.ubuntu.com/anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap?cdn=local
<zyga> jdstrand: snap-confine is in snapd now :)
<zyga> :)
<didrocks> Chipaca: works with the local cdn parameter (so internapcdn.net is behaving in some unexpected fashion?)
<didrocks> let me try to curl that one (in case curl is redirected to another one)
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2416
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<didrocks> (curl worked)
<Chipaca> alex-abreu, sorry, my point is that it's going to be a big branch, because not only client doesn't know it, neither does daemon, nor store, nor state
<Chipaca> alex-abreu, and I don't understand the design that would benefit from including this information, but I'm not inherently opposed to the idea
<alex-abreu> Chipaca, yes I had a quick look at it and yes, ... the overlord needs to be updated etc.
<Chipaca> noise][1, ping
<alex-abreu> Chipaca, it is not a super high prio, but having it seems like a strong requirement for them
<noise][1> Chipaca: so we have curl->internap OK, snapd->internap not, snapd->elsewhere OK ?
<Chipaca> noise][1, go http client, not snapd, but yes
<Chipaca> i took snapd out of the equation to make it simpler
<Chipaca> just a regular `http.Get(...)`
<noise][1> yeah, have you tweaked any tcp options yet?
<Chipaca> noise][1, not usefully, why?
<noise][1> mostly thinking timeouts, keepalives
<Chipaca> noise][1, keepalives are to keep the connection alive, aren't they?
<Chipaca> anyway gustavo had me set keep alives to a very small time and nothing changed
<noise][1> in that strace - is getting a read timeout?
<Chipaca> no, a ECONNRESET
<noise][1> ah, missed that, yeah
<Chipaca> I'll write something to dump the whole request we make
<Chipaca> let's see what gives
<renato__> mvo, could you upload the first version of this package to store? https://code.launchpad.net/~phablet-team/+snap/mediaplayer-app
<noise][1> Chipaca: trying to think what curl might be doing differently than go here
<noise][1> any consistency on the timing from start to conn reset?
<noise][1> didrocks: ^^
<didrocks> noise][1: no, can be 1s or up to 4s of download
<didrocks> (mostly between 1 & 2s though)
<noise][1> didrocks: and this is mainly happening on your pi2? routed/nat'd through your desktop?
<didrocks> noise][1: indeed, I never have any issue on my desktop
<kgunn> morphis hey wanted to catch you before your eod, i cloned the master of pulseaudio snap, built local, installed on a series16 Core running as a kvm/qemu vm....and i'm having trouble getting it to work, when i call
<kgunn> pulseaudio.paplay somfile.ogg
<kgunn> it acts like there's no server up to connect to so
<kgunn> i didn't know if i need to start a server ?
<ogra_> ps ax ?
<mvo> renato__: sure
<mvo> renato__: btw, nice to see that the snaps are quite small now
<renato__> mvo, yes, thanks to ubuntu-app-platform
<mvo> indeed
 * zyga solicits code reviews for https://github.com/snapcore/snapd/pull/2416
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<zyga> tvoss, lool: ^^ maybe interested
<zyga> this is for the release tomorrow
<jdstrand> zyga: it sounds like jailmode for classic is strict plus read of all of the core snap. is that accurate?
<renato__> mvo, please review the notes app too if possible
<zyga> jdstrand: yes
<Chipaca> didrocks, can you get https://people.canonical.com/~john/schmurl_arm_verbose and try again?
<zyga> jdstrand: that's exactly right
<Chipaca> didrocks, (no strace, just the regular output)
<didrocks> Chipaca: http://paste.ubuntu.com/23588841/
<Chipaca> didrocks, and you had the verbose curl output with all headers somewhere, yes?
<didrocks> I can redo one anyway
<didrocks> Chipaca: http://paste.ubuntu.com/23588854/
<kgunn> morphis sorry, browser crashed bad...had to get it back up...here's the pastebin
<kgunn> http://pastebin.ubuntu.com/23588855/
<kgunn> of the issue i'm experiencing
<Chipaca> didrocks, and if you add -H "Accept-Encoding: gzip" -H "Accept;" ?
<didrocks> Chipaca: download still succeeded
<Chipaca> didrocks, I suddenly understand people that drink during work hours
<Chipaca> I think a cup of tea would work
 * Chipaca goes
<didrocks> Chipaca: ahah, sounds sane! ;)
<kalikiana_> zyga: FYI it seems using "kill" is a bad idea. After using "sudo systemctl stop snapd.service snapd.socket" I got a go stacktrace - turns out there was an extra space in basedeclarations.go
<mup> PR snapcraft#950 opened: tests: Use a more stable ftp source <Created by elopio> <https://github.com/snapcore/snapcraft/pull/950>
<Chipaca> jdstrand, ping
<jdstrand> Chipaca: hey
<Chipaca> jdstrand, i'm told you're the person to talk with about http being non-installable
<jdstrand> Chipaca: I need more context, but maybe?
<Chipaca> jdstrand, - Mount snap "http" (19) (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
<jdstrand> Chipaca: what is 'http'?
<Chipaca> jdstrand, httpie, in a snap
<jdstrand> Chipaca: it sounds like a webserver. why does it need snapd-control?
<Chipaca> jdstrand, so you can do http snapd:///v2/etc
<jdstrand> Chipaca: ok I think you may be missing some context of my questions
<Chipaca> jdstrand, sorry :-)
<Chipaca> it's a web client, not a server
<jdstrand> Chipaca: currently, http would need a snap declaration to be able to use the privileged snapd socket
<Chipaca> like curl but written in python
<Chipaca> pretty-prints and colorizes json and other neat things
<jdstrand> Chipaca: I'm trying to understand if that access is legitimate
<jdstrand> Chipaca: is this a Canonical snap? is it used by snappy developers for debugging, etc?
<Chipaca> jdstrand, it's a chipaca snap, not a canonical snap
<Chipaca> it is used by me to talk to snapd directly, yes
<Chipaca> but it's also just regular httpie, so you can http google.com and such
<jdstrand> it seems reasonable that a snappy developer would be able to use a snappy tool to talk to the snapd socket, so I'll say as much in a comment in the snap and grant the snap declaration
<Chipaca> hmm. I'll take it. I'd like to think somebody not working on snappy could still do this if they cared about it enough, though.
<jdstrand> jeez, why is the store taking so long
<Chipaca> jdstrand, that's noise][1's middle name these days, i hear
<jdstrand> hmm, searching for 'http' in the store doesn't yield great results...
<ogra_> try google then :P
<jdstrand> lol
<jdstrand> Chipaca: this https://myapps.developer.ubuntu.com/dev/click-apps/3675/ ?
<Chipaca> jdstrand, sorry for the delay (2fa...)
<Chipaca> jdstrand, yes
<jdstrand> Chipaca: ok done
<Chipaca> woo, it works again :-D
<lutostag> I can't seem to get lxd to work on core-16, due to https://bugs.launchpad.net/snappy/+bug/1606510, is that truly the case or am I missing something?
<mup> Bug #1606510: Mechanism to create system groups <lxd> <Snappy:New> <https://launchpad.net/bugs/1606510>
<lutostag> any help would be appreciated
<ogra_> lutostag, seen my last comment on that bug ?
<lutostag> ogra_: sweet, I did not, I will see if that works, thanks!
<ogra_> sadlyx there is still manual work required, but we'll fix that
<mup> PR snapd#2420 opened: overlord/snapstate: setup/remove aliases as we link/unlink snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/2420>
<lutostag> ogra_: ok, I no longer see that error in syslog (but after a reboot the error reappears). And I can never seem to get the lxd daemon to start properly
<ogra_> hmm
<lutostag> (started with clean kvm image & rpi2)
<ogra_> stgraber, any idea why using extrausers might confuse lxd ? even thjough it works before reboot ?
<ogra_> do we need any extra pam or nss magic here ?
<stgraber> ogra_: lxd just calls getgrnam which should go through the usual NSS stack
<ogra_> hmm
<stgraber> does "getent group lxd" succeed on such a system?
<lutostag> errorcode 2
<lutostag> (no output)
<ogra_> ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/*
<ogra_> ogra@pi3:~$ getent group lxd; echo $?
<ogra_> 2
<ogra_> ogra@pi3:~$
<ogra_> grr
<stgraber> good, so not my fault :)
<ogra_> ogra@pi3:~$ sudo grep lxd /var/lib/extrausers/*
<ogra_> /var/lib/extrausers/group:lxd:x:112:
<ogra_> /var/lib/extrausers/group-:lxd:x:112:
<ogra_> /var/lib/extrausers/gshadow:lxd:!::
<ogra_> /var/lib/extrausers/gshadow-:lxd:!::
<ogra_> ogra@pi3:~$ getent group lxd; echo $?
<ogra_> 2
<ogra_> ogra@pi3:~$
<ogra_> so the getent lies ...
<stgraber> something must be busted with your nss setup somehow
<stgraber> what do you have in nsswitch.conf?
<ogra_> passwd:         compat extrausers
<ogra_> group:          compat extrausers
<ogra_> shadow:         compat extrausers
<ogra_> gshadow:        files
<ogra_> hmm
<ogra_> gshadow doesnt look right
<stgraber> yeah, not sure that it'd cause that problem, but maybe
<stgraber> should be easy enough to try, just bind-mount a fixed file onto it and try again :)
<ogra_> ogra@pi3:~$ sudo getent group lxd; echo $?
<ogra_> 2
<ogra_> nope, no change
<mup> PR snapd#2421 opened: tests: add basic test for docker <Created by mvo5> <https://github.com/snapcore/snapd/pull/2421>
<qamar> hi all
<zyga> jdstrand: hey
<zyga> jdstrand: will you have the time to review https://github.com/snapcore/snapd/pull/2416 today?
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<kyrofa> Hey ogra_, do you know where our kernel snapcraft.yaml is maintained?
<zyga> kyrofa: hehe
<zyga> kyrofa: I do
<zyga> kyrofa: I asked the kernel team if we can move it
<zyga> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/snapcraft.yaml?h=pc
<zyga> (in a galaxy far far away)
<kyrofa> zyga, ah, thanks!
<zyga> kyrofa: reviews welcome ^ (for snapd)
<ogra_> kyrofa, note that the actual building happens with the Makefile that is in the tree under source: ... it has nothing at all in common with a snapcraft kernel plugin created kernel snap
<kyrofa> ogra_, indeed, I noticed that
<kyrofa> ogra_, is that overcoming a shortcoming, or just using something that was already there?
<ogra_> (it is a chroot that grabs a bunch of binaries from the archive and pulls the binaries out of there)
<ogra_> it is a necessity
<ogra_> we need a bunch of userspace bits and these bits need to come from stable packages
<kyrofa> ogra_, ah, it's not "just" the kernel, huh?
<ogra_> and we need the kernel binaries signed with the ubuntu archive key for secure boot
<ogra_> no, rthe official kernel snap has not much in common with a plain kernel snap from a snapcraft plugin build
<ogra_> we do not build anything from source
<ogra_> due to the key requirement that wouldnt work outside of the archive
<ogra_> we need to use the same secure-boot key for UEFI secure boot as the desktop kernel
<ogra_> kyrofa, also, ppisati owns all this now
<kyrofa> ogra_, ah, very interesting, okay
<kyrofa> ogra_, yeah I just curious what it looked like, no problems with it or anything
<kyrofa> Thanks for the info!
<ogra_> np
<jdstrand> zyga: I wasn't planning on it. this looks like the code churn stuff I thought we were not going to make a high prioirty (with tyhicks)
<zyga> ogra_: AFAIK all kernel snaps are owned wholly by the kernel team
<zyga> jdstrand: we have today and part of tomorrow still
<zyga> jdstrand: I can still prepare alt branches but I wrote this super carefully and I'd love to land if it we can review it on time
<jdstrand> zyga: why is this important? it is code churn? snap-confine works fine without it
<jdstrand> tyhicks: do you want me to continue to put off my work for this ^
<zyga> jdstrand: churn in some way, it's making something that was kind of ad-hoc more reliable
<zyga> jdstrand: if you don't have the time to review this it's fine but at some point we may need to just land stuff without being reviwed by security
<zyga> jdstrand: if you collectively agree that's okay
<jdstrand> zyga: that sounds like a threat :)
<zyga> jdstrand: no no, I didn't mean it to sound like that
<zyga> jdstrand: I mean we may need to reorg stuff as we have conflicting requirements
<zyga> jdstrand: and not enough time to do everything
<zyga> jdstrand: e.g. I'll likely work on the live namespace changes code soon and that will involve lots of new stuff
<jdstrand> I don't know what you are referring to with reorg, but I'm still on snappy full time. anyway, resourcing is something for ratliff, et al. let's see what tyhicks says
<zyga> jdstrand: with reorg I meant that perhaps we could land some pull requests without a security review
<zyga> jdstrand: and really put your time where it matters most
<jdstrand> zyga: sure, and I'd like to finish dbus-app, network-namespace, get seccomp arg policy in place, and like 20 other snappy cards :)
<zyga> jdstrand: I don't think the parser code is particilarly security sensitive
<zyga> jdstrand: and I write stuff as defensively as I can now
<zyga> jdstrand: right, I undertand, and from my perspective you have to ack almost everything I write :)
<jdstrand> zyga: it is sensitive. it is running before privileges are dropped. if something bad happens there, priv escalation
<zyga> jdstrand: yep, you are right
<tyhicks> yes, it is sensitive
<jdstrand> zyga: this is nothing against your coding btw
<zyga> jdstrand: (and thus I prefer my super defensive and tested code to the stuff that's in main now :)
<jdstrand> there is very little in main that is setuid root
<jdstrand> this launcher is ridiculously complex for a setuid executable. I understand it has to be so, but...
<zyga> jdstrand: I think parsing was
<zyga> jdstrand: I agree but I think we made it as simple as it can
<zyga> jdstrand: (be)
<jdstrand> sure, hence the 'but'
<jdstrand> err
<jdstrand> hence the 'understand'
 * zyga nods
<zyga> jdstrand: could emily review some of my branches?
<jdstrand> that would be for ratliff and tyhicks to decide
<tyhicks> zyga: why is this PR critical?
<jdstrand> honestly, I'd love to get to a point where the launcher is constantly changing
<jdstrand> isn't*
<tyhicks> me too
<tyhicks> closely reviewing PRs to a setuid-root executable takes considerable time
<jdstrand> Tyler gave the +1 on the error handling one (which is fine), but I'm starting to feel like I'm losing context with each review
<tyhicks> I'd like us to not make changes just for the sake of rewriting existing code
<zyga> tyhicks: it's on the critical path for classic confinement, there's just two branches after that (short ones)
<tyhicks> that PR only adds new code so I can't see what it is simplifying/hardening/improving
<jdstrand> again, changing arg parsing isn't critical to that
<jdstrand> I gave an easy path for classic
<zyga> tyhicks: the code that changes main is in a separate branch
<jdstrand> just modify the current parsing
<jdstrand> I'm not saying this should not ever be merged. I'm just saying it isn't critical to classic
<jdstrand> and therefore maybe we can land small changes fast as opposed to big changes fast
<zyga> ok, I'll adjust after feedback from gutavo and propose a small branch that just adds another strcmp for --classic
 * jdstrand notes that tyhicks did not weigh in on if one of us should move away from what we are doing to this
<tyhicks> my preference is to not preempt all of our current work with this PR
<tyhicks> zyga seems to have agreed with a way forward that doesn't need us to do that
<zyga> jdstrand, tyhicks: I think at the root of the problem is the fact that I implicitly assume I can get a review from one of you at any time
<zyga> and that's not the case
<jdstrand> ok. unless told otherwise, I will postpone reviewing this PR
<zyga> tyhicks: well, still but to a smaller degree :)
<tyhicks> zyga: yeah, that's probably a bad assumption
<zyga> tyhicks: so what do you think we should do?
<tyhicks> zyga: I thought you said that you'd go the strcmp() route for --classic?
<zyga> tyhicks: yes, I mean in general
<zyga> tyhicks: what do we do the next time?
<tyhicks> zyga: we have to prioritize all of the work that we have on our plates - critical snappy PRs rank extremely high
<jdstrand> zyga: I think that the stakeholder process is not being observed
<tyhicks> zyga: we'll make time for those
<zyga> jdstrand: what process wasthat?
<tyhicks> zyga: PRs that move code around fall below ubuntu security updates, some feature development, etc., and that's the situation that we're facing now
<jdstrand> it's assumed that I can do anything asked of me for snappy at any time. this results in the security team's snappy lane not getting enough attention
<jdstrand> cause everything gets preempted all the time
<zyga> tyhicks: should I be allowed to land such PRs with regular reviews?
<zyga> jdstrand: right, I see the bad side effects, I'm looking at what to do in general
<tyhicks> zyga: I would hope not. Like we discussed, this code will end up being used in the most critical sections.
<jdstrand> zyga: I think what tyhicks is saying is that critical PRs will always be treated with critical priority. a PR that just moves stuff around as part of a critical feature isn't really the same thing. We can get to that PR too, but it needs to be prioritized alongside other items
<tyhicks> yes, that's what I'm saynig
 * zyga nods
<tyhicks> please have a good reason to make a code reorgnization PR as a prereq of a critical feature
<jdstrand> for example, people are being driven crazy because setpriority isn't using arg filtering
<zyga> one thing I'd like to figure out is how we can do refactorings like this one over time, perhaps we should not do it at random time but I would argue that we should have time and space for refactoring code in s-c
<jdstrand> and having that and 20 other seccomp arg filtering bugs should be higher priority than an arg parsing pr
<zyga> I see
<jdstrand> zyga: we can, it just needs to be prioritized alongside the other stuff
<zyga> ack
<jdstrand> to date, the other stuff is constantly deprioritized
<zyga> I'll just keep proposing them and when you have time just review them
<zyga> and I'll try minimalistic branches for everything ele
 * jdstrand nods
<zyga> else
<tyhicks> I think that would work out well
<jdstrand> zyga: if something is blocking you, it is totally fine to raise that with tyhicks and ratliff
<jdstrand> that is the stakeholder process
<zyga> ack
<tyhicks> thanks zyga
<zyga> tyhicks, jdstrand: FYI, after the merge into snapd I'll spend time on adjusting spread tess to work with and feel more like the snapd tests
<zyga> and I'll do some small reorg to have a static library shared by snap-confine, snap-discard-ns, snap-system-shutdown and the upcoming snap-modify-ns (working name)
<jdstrand> zyga: for you arg parsing pr... since the code will be more involved, perhaps temporarily drop privs before and raise after like we do a little later
<zyga> hopefully just autotools changes though
<zyga> jdstrand: sure, I can do that easily
<tyhicks> heh, I was going to suggest the same thing that jdstrand just suggested
<jdstrand> zyga: it isn't bulletproof to be sure, but adds a hurdle
<zyga> yes
<tyhicks> I'd like to see a temporary drop of privs
<zyga> I can even switch hats
<jdstrand> switching hats is an interesting concept
<zyga> so I'm all up to do all of that in a nice and tested fashion :) (you know I love to code)
<jdstrand> yes! :)
<jdstrand> I'd say start with priv dropping for that-- it is super easy
<zyga> +1
<tyhicks> if you change hats, I wouldn't suggest doing it the way that aa_change_hat() is already used
<zyga> tyhicks: what would you suggest?
<jdstrand> changing hats, using privilege separation in another process, using a crazy restrictive seccomp sandbox for that process are all things that could possibly be done, but would need to be designed to make sure the benefit outweighs the complexity
<tyhicks> zyga: well we currently fork and then change hats and never return back
<mup> PR snapd#2422 opened: tests: re-enable snap-confine unit tests via spread <Created by zyga> <https://github.com/snapcore/snapd/pull/2422>
<zyga> tyhicks: ah
<zyga> tyhicks: I thought you meant that we should use something other than aa_change_hat
<tyhicks> zyga: you wouldn't want to fork - you'd just change to a hat and then change back
<tyhicks> cool, sounds like we're on the same page
<zyga> yes, I think so
<tyhicks> ok, I'm off to hack on seccomp some more
 * jdstrand goes off to reviews and dbus
<zyga> thanks guys!
<zyga> and if I can review something for you, ask any time!
 * jdstrand hugs zyga :)
<zyga> I'd like to help :)
<jdstrand> thanks!
 * zyga hugs jdstrand and tyhicks :)
 * tyhicks hugs zyga and jdstrand :)
<mup> PR snapd#2423 opened: overlord,overlord/snapstate: implement snapstate.Alias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2423>
<mup> PR snapcraft#948 closed: Use testtools as the base of all unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/948>
<mup> PR snapcraft#950 closed: tests: Use a more stable ftp source <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/950>
<mup> PR # opened: snapd#1613, snapd#2083, snapd#2128, snapd#2129, snapd#2209, snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2274, snapd#2277, snapd#2302, snapd#2328, snapd#2345, snapd#2347, snapd#2359, snapd#2360, snapd#2365, snapd#2368, snapd#2370, snapd#2374, snapd#2377,
<mup> snapd#2378, snapd#2380, snapd#2391, snapd#2392, snapd#2394, snapd#2395, snapd#2397, snapd#2407, snapd#2410, snapd#2411, snapd#2412, snapd#2413, snapd#2414, snapd#2415, snapd#2416, snapd#2417, snapd#2418, snapd#2419, snapd#2420, snapd#2421, snapd#2422, snapd#2423
<qengho> dang.
<kyrofa> jdstrand, the apparmor needed by snappy isn't available upstream, correct?
<tyhicks> kyrofa: the userspace bits are all available upstream
<tyhicks> kyrofa: not all of the kernel bits are available upstream
<kyrofa> tyhicks, right sorry, should have specified the kernel
<kyrofa> tyhicks, alright just wanted to double check. Thanks!
<tyhicks> kyrofa: upstreaming those bits is something that we'll have someone working on very soon
<kyrofa> tyhicks, makes sense for the long haul, but I'm sure there are higher priorities at the moment
<tyhicks> yes :/
<kyrofa> zyga, do we still have a classic dimension in the new Ubuntu Core images?
<kyrofa> ogra_, I seem to remember you demoing the classic stuff, but don't remember how to do it
<mup> PR snapcraft#908 closed: Let Rust plugin fetch dependencies in pull <Created by ChrisMacNaughton> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/908>
<ogra_> kyrofa, sudo snap install classic --devmode --edge; sudo classic
<kyrofa> ogra_, thank you :)
<mup> Bug #1647849 opened: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849>
<zyga> kyrofa: yes, but it's called clasisc snap
<zyga> classic*
<kyrofa> zyga, difficult to discover. Do we plan on documenting that further, or integrate further with snapd itself?
<zyga> kyrofa: maybe via motd?
<zyga> kyrofa: I think we should document it on the snapd wiki
<zyga> kyrofa: in "first steps" perhaps, (a find-your-way-around tutorial)
<kyrofa> Indeed
<kyrofa> motd is also a good idea
<mup> Bug #1609322 changed: snap firstboot can run before /sys/class/net/ is populated <Snappy:Fix Released> <https://launchpad.net/bugs/1609322>
<mup> PR snapd#2424 opened: interfaces/builtin: add physical-memory-* and io-ports-control <Created by tonyespy> <https://github.com/snapcore/snapd/pull/2424>
<mup> Bug #1647849 changed: Ubuntu Snappy Core on Raspberry Pi 3 Wi-Fi fails on first boot <Snappy:New> <https://launchpad.net/bugs/1647849>
#snappy 2016-12-07
<liuxg> I have configured my netplan to make the wifi working in my home on my dragon board. However, now I connect my board to an network cable in the office, the network is not working any more. Does it mean that we cannot make wifi and cable working at the same time?
<mup> Bug #1647936 opened: Raspberry Pi 3: a small rainbow square on the top right of screen <Snappy:New> <https://launchpad.net/bugs/1647936>
<liuxg> ogra_, ping
<mup> Bug #1647950 opened: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware <Snappy:New> <https://launchpad.net/bugs/1647950>
<vigo> morning snappy
<vigo> mvo, Could you please share the candidate images link for testing? :)
<mvo> vigo: http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/.pending/
<vigo> mvo, yay!! thank you =)
<dholbach> hey hey
<seb128> hey dholbach!
<dholbach> hi seb128
<mup> Bug #1647992 opened: r620 core snap candidate change /etc/modprobe.d to "synced", and blacklist-watchdog.conf now cause rebooting every 7 min without iTCO_wdt module loaded <Snappy:New> <https://launchpad.net/bugs/1647992>
<longsleep> Quick snap question, if a snap provides a binary to classic ubuntu, can the snap access files on the classic file system tree? I am only seeing apparmor DENIED whenever that binary tries it
<Chipaca> didrocks, heya. Me again. Do you think you could get wireshark onto the pi to capture the whole thing? (or somewhere along the route to the pi)
<Chipaca> longsleep, some but not all files
<Chipaca> longsleep, what are you trying to access?
<Chipaca> longsleep, no 'hidden' files, for example
<longsleep> Chipaca: well i am trying out https://uappexplorer.com/app/hugo.hugo-authors - and the binary needs to access the files and folders from the static site, so you run it in the cwd of your site
<longsleep> Chipaca: eg. it fails to read the config.toml file which is cwd/config.toml - it gets the absolute path right but then apparmor prevents read access
<Chipaca> let's see...
<longsleep> Chipaca: Snap support was added here https://github.com/spf13/hugo/pull/2443/files - and i wonder if i am just the first one to try or if i made a mistake
<mup> PR spf13/hugo#2443: add snapcraft.yaml file <kind/enhancement> <Created by dholbach> <Closed by anthonyfok> <https://github.com/spf13/hugo/pull/2443>
<Chipaca> ralsina, see? hugo uses snappy. Hint hint.
<longsleep> Chipaca: yeah would be pretty awesome if it would work too :)
<Chipaca> longsleep, details!
<longsleep> hehe
<longsleep> right
<Chipaca> longsleep, is there an easy way to run it?
<Chipaca> i mean, i just installed it, have no config.toml :-)
<longsleep> sure, i think it can create one
<longsleep> hold on a sec
<tsdgeos> any idea what i may be doing wrong when trying to use the ubuntu-app-platform content interface?
<tsdgeos> http://paste.ubuntu.com/23592699/
<tsdgeos> t1mp: â
<longsleep> Chipaca: hugo new site lala
<longsleep> lala is the folder it would create, but it fails misterably :)
<Chipaca> yeah, that worked
<longsleep> oh really
<longsleep> not for me
<longsleep> ah
<Chipaca> longsleep, you're holding it wrong
<Chipaca> longsleep, hugo uses the 'home' interface
<longsleep> Chipaca: i am on a fuse mount. Maybe thats the reason?
<Chipaca> longsleep, which means it gets access to your home, except for dotfiles
<longsleep> oh ok
<longsleep> Chipaca: so when its not in home it fails
 * longsleep tries in home
<Chipaca> longsleep, fuse mounts are probably either /media (different interface) or something like ~/.gvfs/yadda (dotfile)
<longsleep> Chipaca: you are right
<longsleep> Chipaca: yes its in /media
<longsleep> Chipaca: it works in $HOME
<longsleep> Chipaca: anything i can do about it? I do not have enough storage in $HOME
<Chipaca> longsleep, you could suggest to them to add whatever the interface was that gives you /media
 * Chipaca doesn't remember
<Chipaca> longsleep, or, you could bind-mount it into your home
<longsleep> Chipaca: ok i see - thanks !
<Chipaca> longsleep, the bind mount thing will not tolerate the fuse mount going away easily
<Chipaca> but it should work
<Chipaca> longsleep, if the fuse mount is a long-lived thing you could configure it to mount in your home directly
<longsleep> Chipaca: yeah i understand
<longsleep> Chipaca: no, encrypted USB device :P
<Chipaca> LUKS-encrypted?
<longsleep> yes
<Chipaca> you can make that mount on boot, but yeah, a lot of work
<longsleep> well its not connected all the time
<tsdgeos> t1mp: ok, got it to work
<Chipaca> longsleep, ah
<Chipaca> longsleep, in any case, you don't need fuse for that, if you want to do the work you need to set up crypttab and fstab appropriately
<longsleep> Chipaca: but i understand the problem now, and the snap basically works as long as the stuff is below $HOME
<Chipaca> yep
<longsleep> Chipaca: without fuse, how does one enter the passphrase for the key?
<longsleep> Chipaca: i mean i have crypttab and all for the rootfs and there it prompts on bootup, but where would it prompt for optional devices on hotplug?
<Chipaca> you get prompted for it, but I haven't tried doing it in a graphical environment
<Chipaca> so, i don't know
<Chipaca> sorry :-/
<longsleep> Chipaca: fair enough - this is the snappy channel after all :)
<didrocks> Chipaca: hum, that's going to be complex due to my current schedule, would be great if we have a prepared snap for that
<ogra_> cjwatson, hmm, seems all core and ubuntu-core snaps failed to build due to what looks like a network error ...
<ogra_> OSError: Tunnel connection failed: 403 Forbidden
<ogra_> cjwatson, https://launchpadlibrarian.net/296915208/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz is an example build log
<ogra_> Chipaca, i think bug 1647950 was something you were working on, right ? (is there a bug i can duplicate to  ?)
<mup> Bug #1647950: Raspberry Pi 2/3: failed to umount /lib/modules and /lib/firmware <Snappy:New> <https://launchpad.net/bugs/1647950>
<Chipaca> yes, a mo'
<t1mp> tsdgeos: yes, I know what it wrong: https://bugs.launchpad.net/ubuntu-app-platform/+bug/1645731
<mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
<Chipaca> zyga, do you remember the bug # for the system-shutdown thing?
<t1mp> tsdgeos: snappy bug. See https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ what is the correct order to install/connect to work around that for now.
<t1mp> or Jamie's solution in his bug comment
<Chipaca> ogra_, I'm pretty sure we have a bug for it; we certainly have a card and a few branches for it
<Chipaca> ogra_, but as usual i can't find it; let's hope zyga or mvo can
<tsdgeos> is this https://github.com/snapcore/snapcraft/pull/951 how one is supposed to do pull requests for snapcraft?
<mup> PR snapcraft#951: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
<mup> PR snapcraft#951 opened: snapcraft plugins -> snapcraft list-plugins <Created by tsdgeos> <https://github.com/snapcore/snapcraft/pull/951>
<liuxg> ogra_, ping
<liuxg> I used netplan to configure my wifi at home, then I went to my office. Since the wifi AP name is not right, I started to use a cable to connect my ubuntu coree device. However, I cannot find any IP address for the ubuntu core device even though I had a cable connected to it. is this a bug?
<ogra_> liuxg, yo
<liuxg> ogra_, I described my question above. is that a bug or a designed feature? thanks
<ogra_> liuxg, well, if you disabled wired network it wont run
<ogra_> if you did set a password you could do a local console login and run sudo console-conf to reconfigure it ...
<liuxg> ogra_, do you mean I need to turn it on? I configured the netplan during the console-conf. How can I configure it again?
<ogra_> but beyond this i dont see how you could get wired networking to work
<ogra_> and during console-conf you configured wired network as dhcp client ?
<liuxg> ogra_, during the console-conf, I just leave the default setting for the wired connection.
<ogra_> well, not sure if thats enough ... thats a mwhudson question i guess
<liuxg> ogra_, maybe not. I did not touch the default setting there. If that is the casse, would it be good to have the default setting for wired network as that?
<ogra_> no, because you probably dont want wired to wsork for security reasons as a manufacturer ... defaulting to always have wired obtain an IP would be a bad idea here
<liuxg> ogra_, ok. I see your point. but normally if I have a wired connection, in fact during the console-conf, I do not do anything there, and it starts to work directly.
<liuxg> ogra_, so, I thought wired network connection came automatically without any manipulation.
<ogra_> liuxg, iirc the firstboot code brings it up, but i'm not sure the config is applied to netplan if you dont take any action to do that in console-conf ... but as i said, thats an mwhudson question
<liuxg> ogra_, thanks for your answering. mwhudson, what do you think of the issue? thanks
<ralsina> Chipaca: Nikola has been snapped for MONTHS
<mup> PR snapd#2425 opened: store: decode response.Body json inside retry loops <Created by stolowski> <https://github.com/snapcore/snapd/pull/2425>
<renato__> mvo, sorry to disturb you again ;). Could you approve media-player-app and ubuntu-notes-app
<mardy> pstolowski: hi! With snapctl, will it be possible to know the apparmor profile of the peer, when running inside an interface hook?
<Chipaca> ralsina, d'oh :-)
<Chipaca> ralsina, i typo'd my original `snap find`, i guess
<ralsina> Chipaca: we also have a snap for coil, a nikola-based CMS
<ralsina> that one is more experimental, tho
<Chipaca> snap info tells me it's only in beta and edge :-)
<Chipaca> is it really a CMS *for* Nikola, as its description says?
<Chipaca> anyway. i've got a standup coming up
<pstolowski> mardy, i'm not aware of such capability, sounds like something concerning apparmor more than snapd; perhaps jdstrand knows?
<mvo> renato__: sure, soon
<mardy> pstolowski: or, leaving apparmor aside, is it possible to somehow identify who's the snap which is connecting into your interface's slot?
<pstolowski> mardy, that should be easily doable if required from interface hook, but syntax/semantics need to be defined
<jdstrand> mardy: I know of no functionality in snapd for wrapping the libapparmor api. I don't know otoh if the rest api has anything about connected plugs to a snaps slot. maybe that is what interface hooks are for? kyrofa (or Chipaca) may know
<mardy> jdstrand: yes, actually my original question was about interface hooks: I'll need a way from inside the unity8 snap to know what's the apparmor profile of the snaps connecting to the Online Accounts interface, so that I can add them to the ACL when the user enables them
<pstolowski> mardy, so i think interface hooks will be able to expose this info during the execution of hooks, technically there is no challenge. it just needs to be defined in terms of how this is exposed
<pstolowski> something we need to discuss with niemeyer, along other details of hooks currently in the review
<jdstrand> mardy: you may want to read this: https://docs.google.com/document/d/1mwLfShu3K8LNa1cYySqhM0fp06TZoKygG0bs2KB9Z4I/edit# . That is something that tvoss and I came up with but it has not undergone review by niemeyer
<mardy> pstolowski, jdstrand: thanks, reading...
<jdstrand> niemeyer: hi! that document ^ is something we talked about me writing up ages ago but I never followed up with you after my meeting with tvoss since this is mostly about Personal and at the time Personal was far out
<jdstrand> niemeyer: now Personal is here, so probably need to work through that. I'll let you decide on if before the end of year or not
<jdstrand> zyga: that is probably something you would be interested in ^
<zyga> jdstrand: looking
<mardy> jdstrand: mmm... I'm not sure I like the proposal in that document... why does snapd need to be modified at all?
<zyga> jdstrand: thank you
<mardy> jdstrand: trust-store (and Online accounts) have their own storage for the ACLs
<mardy> jdstrand: it can be maintained by whatever snap is providing the slot (unity8, in our case)
<zyga> jdstrand: hey, are yon on rocket chat? https://rocket.ubuntu.com/
<jdstrand> mardy: note the invariants
<zyga> jdstrand: it's easy to join (just sso), it's browser based and has persistent ping history and other good ies
<zyga> and it's public :)
<jdstrand> zyga: and its browser based
 * jdstrand joins
<mardy> jdstrand: noted, and I don't see any conflict with what I'm suggesting
<jdstrand> mardy: I added you, zyga, niemeyer, and pstolowski for comment (and edit) rights
<mardy> jdstrand: thanks, will jump in right away :-)
<jdstrand> mardy: feel free to comment. the design is based on direction from niemeyer
<jdstrand> mardy: though again, he has not reviewed it yet, so still lots of time to comment, etc
<jdstrand> mardy: also, this is specifically for *trust-store* and not online accounts which I understand is similar but different
<jdstrand> but sufficiently similar in my mind that they should be considered in the same conversation
<mardy> jdstrand: true, they are different in that location service connects the client to a system resource (the GPS), while OA connects the client to the user data (which in our case is stored by another snap (unity8) and not by the system
<mardy> jdstrand: but I do believe that the solution for OA could be applied for the trust-store services too. Let's see...
<jdstrand> mardy: this is meant to address multi-user. in fact it was written with pulseaudio microphone recording in mind
<jdstrand> I think you might have been trying to express a different point there...
<jdstrand> anyway, yeah-- let's get all the info in there
<mardy> jdstrand: do I understand it correctly, that at the current stage, if user A manually connects a snap to the camera and user B launches that snap, the process started by user B will have access to the camera?
<jdstrand> mardy (cc niemeyer): currently, yes. interface connections are at the system level. this document is about allowing a slot implementation to tie into snapd for mediating per-user connections
<mardy> jdstrand: I'm starting to see the picture now
<stgraber> mvo: hey there, why was https://bugs.launchpad.net/snappy/+bug/1628289 marked fix released?
<mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<jdstrand> mardy (cc niemeyer): the gist of the document is: slot implementation 'foo' wants to provide a may to allow its services to some users but not others (via prompting or not, that doesn't matter). foo uses the trust-store library. the trust-store library under the hood talks to snapd. a user talks to foo, foo asks trust-store if this user is allowed, trust-store asks snapd, etc
<mardy> jdstrand: all clear, I just don't see the reason for the latter point: trust store could have its own storage, just like it has on UT
<jdstrand> mardy: that gets back to the invariant
<mardy> jdstrand: mmm... which one?
<jdstrand> mardy: 'Snapd should be the central authority for anything interface-connection related'. that came from guidance from niemeyer.
<mardy> jdstrand: sure, that would still be the case: the interface between the client and the "service" snap (the one using trust store) would be autoconnected, and the interface between the service and the resource (e.g., GPS) would be manually connected via snapd
<jdstrand> mardy: a nice feature of this approach is that a tool can be written to talk to snapd to manipulate all trust-store connections. ie, the trust-stores aren't siloed. they are in snapd. this makes it easy to see with one command all the user connections. it would help ubuntu-system-settings, etc
<mardy> jdstrand: mmm... I think you are trying to solve two different issues with a single solution
<jdstrand> mardy: I understand what you are saying. the storage doesn't have to be in snapd, but it is a feature that it is
<jdstrand> mardy: please comment in the PR. this has not been approved and was following particular guidance
<mardy> jdstrand: OK
<mvo> stgraber: sorry, that was incorrect
<mup> Bug #1628289 opened: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Fix Released by stgraber> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<jdstrand> zyga: can you send me a message on rocket?
<zyga> jdstrand: yes
<zyga> jdstrand: PM or @-mention?
<mup> PR snapd#2426 opened: spread.yaml: run dmesg -c with sudo and log the id before running it <Created by plars> <https://github.com/snapcore/snapd/pull/2426>
<jdstrand> zyga: I don't know. I closed my window to see what offline notifications look like. both?
<zyga> OK
<zyga> jdstrand: done
<mardy> jdstrand: thanks for the replies! I think all what you wrote makes a lot of sense if interface connections continue to be per-system, but I hope that there are plans to change that, eventually?
<jdstrand> mardy: there isn't a way to make them per user for the foreseeable future. apparmor policy is for the system, not per-user
<jdstrand> mardy: therefore the trusted helpers continue to mediate their APIs like always
<jdstrand> mardy: and this merely provides a way to move the storage to a central place
<jdstrand> (for those trusted helpers that use trust-store)
 * mardy thinks
<jdstrand> mardy: I added a couple more comments to hopefully clarify. this isn't a radical change. this is adjusting the trust-store library to use snapd as its storage. that's it. with that, we can do cool things with tooling, etc
<jdstrand> niemeyer: cc ^
<jdstrand> niemeyer: also, sorry for all the pings, just want you to have all the context for whenever that spec is reviewed (again, doesn't have to be today)
<jdstrand> zyga: if you sent anything, I didn't get them
<jdstrand> zyga: via email. I logged in and see them
<mup> Bug #1646479 opened: Unity8 applications require access to name=com.ubuntu.MenuRegistrar <snapd-interface> <Snappy:Triaged by jdstrand> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1646479>
<cking> i'm getting 504 gateway timeouts whenever I attempt to upload updates to the snap store
<ogra_> not only you
<ogra_> but if you check via the store UI you will find your package got uploaded fine
<cking> ogra_, i'm just trying to navigate on that website to check other snaps I've done and all I get is 504s
<ogra_> go to the toplevel of the snap in the store (cut off rev/#### from the url)
<ogra_> and you will see the revision landed fine
<ogra_> at least thats the case for my LP builds
<cking> heh, even that 504s on me
<ogra_> wow, i can usually reach the toplevel
<cking> oh, nth attempt and it worked
<ogra_> heh
<ogra_> its a game of patience :)
<cking> doesn't feel that snappy to me
<cking> no pun intended
<ogra_> that is because the store still runs on classic :P
<cking> ogra_, on a raspi2 I guess
<ogra_> haha
<ogra_> probably a pi1 with raspbian
<cking> and the CPU clocked at 50% to make sure it don't get too toasty
<ogra_> heh, yeah
<alex-abreu> jdstrand, I was wondering abut the snapd-control / local snap install/connection issue we talked about a week ago, will the fix (if any) be in 2.19?
<jdstrand> alex-abreu: I don't know. we talked about it extensively and Gustavo was going to work through a few things. I have a todo to talk to him today about it
<alex-abreu> jdstrand, ok thx
<seb128> sergiusens, hey, is snapcraft doing some magic to bring in libraries used by a binary you try to include?
<mup> PR snapd#2422 closed: tests: re-enable snap-confine unit tests via spread <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2422>
<lof_mt> Hi there. I am working through the snap tour and have little problems with "20-PARTS-PLUGINS/01-reusable-part/". Error: No CMAKE_CXX_COMPILER could be found.
<lof_mt> Looks like the is a build dependency missing.
<lof_mt> had to install build-essentials because of missing g++.
<mup> PR snapd#2427 opened: cmd/snap-confine: add support for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2427>
<lof_mt> Please fix this. It is an easy problem to fix for me. But with a bit less experience i wouldn't be able to solve it.
<zyga> jdstrand: poke on rocket :)
<lof_mt> Is there a issue tracker for the tour?
<zyga> jamiebennett: ^^
<cwayne> zyga: is that pr what will allow us to call snaps from other snaps?
<jamiebennett> lof_mt: Here please - https://github.com/ubuntudesign/snapcraft.io/issues
<zyga> cwayne: no, that's classic confinement
<zyga> cwayne: (super close, release is tonight)
<jamiebennett> lof_mt: sorry, just looking at the backlog, the github page is correct for the tour working
<zyga> cwayne: the other PR will be merged next cycle, I tried it and I think there are some bits missing still
<jamiebennett> lof_mt: i.e. the page
<jamiebennett> lof_mt: for the code itself, that is snapcraft - https://bugs.launchpad.net/snapcraft
<cwayne> zyga: ah ok
<zyga> cwayne: but I'll try to merge it anyway, we can see how far that gets us :)
<lof_mt> What snap path belongs into a users $PATH?
<nacc> lof_mt: there should be /snap/bin, added by /etc/profile.d/apps-bin-path.sh
<lof_mt> nacc that only works if the user was create after snapd was installed right? (As the bash profile is already written)
<nacc> lof_mt: no, /etc/profile (which is used at runtime) sources all .sh in /etc/profile.d (on ubuntu)
<lof_mt> On debian too. But in both my users bash and zsh there is no snap path.
<lof_mt> Must be a user not distro issue.
<lof_mt> Thanks nacc
<nacc> lof_mt: that seemds odd ... almost like profile isn't being read, then
<nacc> lof_mt: but that'swhere i'd start; maybe try setting some other variable in /etc/profile (or a new.sh in /etc/profile.d) and see if your user sees it on re-login?
<lof_mt> Works for my root user. Definitly messed the users bash profile up at some point. Haven't noticed because of zsh.
<nacc> lof_mt: ok :)
<stormchaser3000_> hello. i am trying to update my ubuntu gnome system and snapd wont set up during the installation or is takng a very very long time. is there any way i can fix this? and is this the right place to ask?
<lof_mt> stormchaser3000_: The Ubuntu upgrade is finished?
<stormchaser3000_> lof_mt: no. it just sits there saying Setting up snapd (2.16ubuntu3) ...
<stormchaser3000_> no error message or anything
<lof_mt> Is there a way to deploy gsettings schemas? Does the gtk3 "cloud part" anything of that for me? Or do i need to write a script that deploys the schemas?
<lof_mt> stormchaser3000_: Graphical or cli update?
<stormchaser3000_> cli
<stormchaser3000_> ugh i will be back later have to go
<lof_mt> Looks like it: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/1bff18219659caa849950858c6021eaa2289f1d0/common/desktop-exports#L102
<lof_mt> But where do i put them?
<lof_mt> Or is that only for making the plug work?
<didrocks> lof_mt: you should just use the desktop parts, like destkop-gt3
<didrocks> gtk3*
<didrocks> it will build this script, then you only need to use command: desktop-launch <your-app>
<didrocks> (and it will build the schemas as needed and such)
<didrocks> + brings the deps
<didrocks> lof_mt: some example and content: https://developer.ubuntu.com/en/blog/2016/07/06/announcing-new-snap-desktop-launchers/
<didrocks> (note that desktop/gtk3 and others have been renamed desktop-gtk3 since this post)
<lof_mt> Can i specify an ubuntu version with cleanbuild?
<lof_mt> Or an existing lxd container
<mup> PR snapd#2418 closed: snapstate/backend: add backend methods to manage aliases <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2418>
<mhall119> is there a generic fix for relocating shared memory file creation location?
<mhall119> snappy-debug says "adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*"
<mhall119> but I'm hoing there's a workaround without patching or re-building the program
<zyga> mhall119: no
<mhall119> :(
<zyga> mhall119: I looked at it multiple times
<zyga> mhall119: maybe if we teach glibc about snappy
<zyga> mhall119: but that changes semantics and exsitng software will break
<stormchaser3000_> lof_mt: ok i am back
<lof_mt> Did it ran through?
<stormchaser3000_> ?
<stormchaser3000_> no
<lof_mt> Can you look in /var/log/dpkg.log ?
<lof_mt>  tail /var/log/dpkg.log
<stormchaser3000_> lof_mt: http://paste.ubuntu.com/23594390/
<lof_mt> kill all apt and dpkg processes. We try to install it manually with dpkg, look for the error then continue with the rest.
<lof_mt> This might be a better fit for #ubuntu
<stormchaser3000_> ok
<stormchaser3000_> lof_mt: that seems to have worked
<stormchaser3000_> but i am not sure yet
<stormchaser3000_> yep it worked
<stormchaser3000_> thanks
<sergiusens> seb128 yes
<stormchaser3000_> (installing manually with dpkg -i)
<lof_mt> stormchaser3000_:  What does that mean? Is snapd fully configured anyway?
<stormchaser3000_> i think so. i downloaded the package and then installed it using dpkg -i
<stormchaser3000_> and then it configured
<stormchaser3000_> i think
<stormchaser3000_> and then i run apt-get upgrade and then it tries to install snapd
<stormchaser3000_> and it fails to configure
<stormchaser3000_> i think. i am still waiting
<stormchaser3000_> and sorry for spamming
<stormchaser3000_> nope it isn't configuring
<stormchaser3000_> and then it works when i manually install the package
<stormchaser3000_> oh well. at least it works XD
<lof_mt> Can you run md5sum on both files and compare if you get the same package? Or does the package name indicate a different version number?
<lof_mt> about schemas again. They are installed in the right location. (/usr/share/glib-2.0/schemas/) on my local system. And on the build server they are in (prime/usr/share/glib-2.0/schemas/). But the application segfaults " GLib-GIO-ERROR **: Settings schema 'org.gnome.feedreader' is not installed"
<lof_mt> i don't have any idea where else it has to be installed. :(
<lof_mt> (non snap version from same git revision works.
<lof_mt> )
<zyga> lof_mt: it is because of chroot
<zyga> lof_mt: http://www.zygoon.pl/2016/08/snap-execution-environment.html
<niemeyer> alex-abreu, jdstrand: Yes, it should be in 2.19.. John has been on it
<alex-abreu> niemeyer, ah awesome ! is there a PR for this?
<niemeyer> alex-abreu: Yeah
<niemeyer> alex-abreu: snapd#2415
<niemeyer> snapd#2415
<mup> PR snapd#2415: overlord/ifacestate: no interface checks if no snap id <Created by chipaca> <https://github.com/snapcore/snapd/pull/2415>
<alex-abreu> thank you
<lof_mt> zyga: i don't see how that is a problem. It should be the same path externally and internally. And both have the needed files.
<zyga> lof_mt: prime/usr/share/whatever will end up as /snap/$SNAP_NAME/$SNAP_REVISION/usr/share/whatever
<zyga> lof_mt: at runtime that is
<lof_mt> zyga so the code can't open  /usr/â¦ but needs to open $SNAP/usr/â¦ ?
<kyrofa> ogra_, ping
<zyga> lof_mt: correct
<lof_mt> Wasn't there an organise instruction for moving files around with snapcraft.yaml?
<zyga> lof_mt: snapcraft organize can only organize files within $SNAP
<zyga> lof_mt: you cannot currently put any contant at another location
<zyga> lof_mt: and $SNAP expands to /snap/$SNAP_NAME/$SNAP_REVISION
<zyga> *content
<mup> PR snapcraft#952 opened: Add Features for Conditional Compilation <Created by cholcombe973> <https://github.com/snapcore/snapcraft/pull/952>
<renato__> jdstrand, what do you think about all telephony services. Should we have a telepathy exclusive for telepathy and another for telephony-service and history-service?
<renato__> jdstrand, or should we include the telepathy permissions in each interface?
<jdstrand> niemeyer: oh, John has been on it? I missed the decision. you were going to think about it over the weekend. what did you land on?
<niemeyer> jdstrand: We're working on allowing dangerous to allow such connections
<niemeyer> Will be on 2.20 though
<zyga> jdstrand: can you +1 https://github.com/snapcore/snapd/pull/2427
<mup> PR snapd#2427: cmd/snap-confine: add support for classic confinement <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2427>
<alex-abreu> niemeyer, ah not 2.19?
<jdstrand> niemeyer: ack, thanks!
<jdstrand> zyga: I was reviewing it while you pinged me
<jdstrand> zyga: I gave my feedback
<jdstrand> +1 with an extremely minor request)
<mup> PR snapcraft#921 closed: Add support for hooks <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/921>
<mup> PR snapcraft#941 closed: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
<MikeB_> Hi, can someone tell me how snaps are signed?  I can't find it in the documentation.  Long time snapcrafter, first time publisher.
<jdstrand> niemeyer: also, just fyi, I think I responded to all your feedback in the dbus PR. it got a bit lengthy on the why and to detail an investigation as to if we could do something different, but I did at least distill it down to a few options. feel free to ask if you have any questions. fyi, I'm here all this and next week so it isn't critical for today or anything
<wililupy> question: I'm getting the following error: cannot find signatures with metadata for snap when I try to install a snap, even in devmode? Any ideas?
<wililupy> I'm also getting an error logging into the store: error: cannot get snap access permission from store: Post https://myapps.developer.ubuntu.com/dev/api/acl/: dial tcp: lookup myapps.developer.ubuntu.com on [::1]:53: read udp [::1]:42500->[::1]:53: read: connection refused
<moritz_> How do i delete old versions of a snap?
<wililupy> disregard. It was a DNS issue. I manually added 8.8.8.8 to /etc/resolv.conf and I can login to the store.
<moritz_> snap remove --recision x7 it is
<wililupy> I'm still getting the first error though.
<cholcombe> sergiusens, how does the get_build_properties override work?
<jdstrand> renato__: so, I haven't really thought this through. I don't really know the relationship between telepathy and telephony-service. iirc, history-service just needs to listen to one or both of them
<jdstrand> renato__: are telepathy and telephony-service completed separate or do they interact with each other? is telephony-service a Canonical/unity8-only thing? iirc, history-service is a Canonical/unity8 thing
<jdstrand> s/completed/completely/
<renato__> jdstrand, from what I understand the telephony-service uses telepathy internally but the apps (messaging/dialer) talks with telepathy direct too
<jdstrand> renato__: to me that suggests that they should be together, espcially if 'uses telepathy' is more than just some ipc calls (eg, plugin or something)
<renato__> salem_, hey, could you give us some more information about telephony;/telepathy/history
<salem_> renato__, sure
<renato__> salem_, just pasted to you the backlog
<wililupy> This is the only error in the syslog when I try to install the snap: Dec  7 20:23:10 localhost /usr/lib/snapd/snapd[2416]: daemon.go:170: DEBUG: uid=0;@ POST /v2/snaps 4.295801232s 400
<renato__> jdstrand, I kind of agree to keep telepathy internally on the interfaces. But will niemeyer agree with that ;)
<renato__> I remember that we have a similar discussion about the contact/calendar interface
<salem_> renato__, both telephony-service, history-service and the apps talk to telepathy directly
<jdstrand> renato__: well, he is a reasonable person. we'll come up with what we think is best, present and then have a chat
<jdstrand> renato__: we did and I was thinking this maybe should be unity8-... too. let's see what the architecture is
<jdstrand> salem_: how is that communication done? via some ipc mechanism (eg, dbus)?
<salem_> jdstrand, dbus
<salem_> jdstrand, apps also talk to telephony-service and history over dbus.
<jdstrand> salem_: are telephony-service and history-service freestanding? ie, they don't plug into telepathy in some way do they?
<cholcombe> anyone know how the plugin get_build_properties is supposed to work?
<jdstrand> salem_: or put another way, are they three independent processes with independent dbus apis that happen to talk to each other?
 * jdstrand thought he remembered telepathy being extendable but doesn't know the mechanism for that
<salem_> jdstrand, exactly. they are independent processes. actually. telephony-service provides 3 binaries: handler, indicator and approver.
<jdstrand> ok, so this does suggest three difference interfaces
<jdstrand> (to me)
<salem_> jdstrand, so, mission-control (which is the telepathy main process) does support plugins, which are shared objects.
<jdstrand> salem_: do you know if telepathy on unity8 is a standard full-blown telepathy or are we only using a small subset of it?
<jdstrand> salem_: that's it, I remember now. but telephony-service and history-service aren't using shared object plugins, correct?
<salem_> jdstrand, no, they only talk to each other over dbus.
<jdstrand> great
<salem_> jdstrand, there is one open issue that telephony-service provides some protocol files that are read by the apps, but we are in a process of moving this to dbus as well
<jdstrand> salem_: that would probably be best for working with snappy unless you were going to share them via the content interface
<salem_> jdstrand, yes, that's why we are moving them to dbus.
<jdstrand> salem_: what about my question regarding our use of telepathy (mission-control) on unity8?
<salem_> jdstrand, sorry. I missed that question.. so unity8 imports a qml plugin from telephony-service that turns it into a telepathy-client to be able to display the call activity. But as it becomes a telepathy-observer, mission control will talk to unity8 over dbus as well.
<salem_> jdstrand, unity8 is a telepathy client just like any other app (messaging-app or dialer-app)
<jdstrand> salem_: ok, thanks
<salem_> (and media-hub IIRC)
<jdstrand> renato__: I suggest this: http://paste.ubuntu.com/23595117/
<jdstrand> renato__: 3 services. telepathy stands alone. telephony-service and history-service can talk to telepathy and offer services to connecting clients
<jdstrand> renato__: the names of these things may change as part of the PR process, but prepending unity8- for now
<renato__> jdstrand, then apps will request access to telepathy + any other interface [history, telephony]
<jdstrand> renato__: yes
<renato__> salem_, will be possible to use history-service without telepathy?
<salem_> renato__, not currently, it's telepathy based.
<mup> PR snapd#2427 closed: cmd/snap-confine: add support for classic confinement <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2427>
<renato__> jdstrand, we kind of agree to use communication-history (history-service), communication (telephony-service).  what do you think? (unity8-communcation, unity8-communication-history)
<jdstrand> renato__: there might be some attibutes in there. eg, by default an app can get safe telepathy apis but say, telephony-service might specify an attribute to get 'unsafe' apis. we'll know more in the PR
<jdstrand> renato__: that seems fine
<renato__> jdstrand, ok I will prepare the necessary changes on history and telephony service
<renato__> salem_, thanks
<renato__> jdstrand, thanks
<jdstrand> renato__: the question then becomes, do we want to have telepathy be 'telepathy' or 'unity8-telepathy'. I think it depends on if we use telepathy like we do eds in Personal, or will we support the full-on mission-control5 for the world
<moritz_> Do i need a plug for accessing ~/.config/my-app ~/.local/share/my-app?
<jdstrand> renato__: I'll let you ponder that
<renato__> jdstrand, ok telepathy interface is the next in the queue
<jdstrand> moritz_: HOME is set to /home/user/snap/$SNAP_NAME/$SNAP_REVISION so in that sense, no. ~/.config/my-app is /home/user/snap/$SNAP_NAME/$SNAP_REVISION/.config
<jdstrand>  /my-app
<moritz_> So the user loses all configs when uninstalling the app?
<renato__> moritz_, why do you want to keep the config after uninstall the app?
<jdstrand> moritz_: yes. by design all files in the snap's area are removed on uninstall. you can use 'disable' instead of remove to make it unavailable to users on the system without removing data
<renato__> this is something that I always complain on current debian dist. The config for olds apps are never removed
<moritz_> renato__: i agree and disagree (the vim config argument). but this is not the place to discuss.
<moritz_> thanks jdstrand
<jdstrand> moritz_: I believe there is a bug on it if you want to weigh in
<jdstrand> personally, I don't like the data loss part of it, but I understand the motivation
<moritz_> If the app uses webkit do i need "browser-support"?  How much webbrowser is a webview? :)
<jdstrand> moritz_: it depends on the webkit. qtwebkit needs something out of browser-support iirc. a simple renderer wouldn't. that interface is about supporting chromium content api (google chrome, chromium, oxide, electron, etc) and firefox
<moritz_> Asking because of this error: Unable to fork a new WebProcess: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess" (No such file or directory)
<moritz_> (yes i noticed the no such file, just though about potential issue still to come)
<jdstrand> moritz_: it sounds like it isn't finding WebKitNetworkProcess where it wants to. that file is likely in /snap/$SNAP_NAME/$SNAP_REVISION/usr/lib/...
<jdstrand> moritz_: I suggest using the desktop part. beyond that, I'm going to hand off to others with more experience working with GNOME libraries, etc on snappy
<moritz_> Already using the desktop part. â https://github.com/lightonflux/feedreader-snap/blob/master/snapcraft.yaml
<jdstrand> moritz_: you might ask didrocks when he comes back online if no one else answers
<moritz_> I think i might need to add something in staging. The file is just not included in the snap (at all). But it is locally and in the gnome runtimes of flatpak.
<sergiusens> cholcombe like https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/tar_content.py#L29
<sergiusens> cholcombe it replaces the `pull|build-properties` from `shema`
<cholcombe> sergiusens, ok.  So do I do the normal schema part in there as well to get access to the rust-feature yaml info?
<sergiusens> cholcombe yeah, the schema part is fine and stays
<sergiusens> cholcombe in retrospect, that method could of been an attribute but we'd have had precedent for adding logic in there
<cholcombe> ok cool so i leave schema['properties']['rust-features'] and then later in get_build_properties i just return super().schema['properties']['rust-features'] ?
<sergiusens> cholcombe yup
<cholcombe> ok nice
<cholcombe> should i move that code block out of the schema function also?
<cholcombe> or does it need to be set in there also?
<sergiusens> cholcombe you can move it out (the `pull-properties` and `build-properties` keys into `get_pull_properties` and `get_build_properties` plugin methods)
<cholcombe> sergiusens, ok
<moritz_> Can confirm that i forgot it libwebkit2gtk-4.0 as a staging package.
<wililupy> Question: if the file exists, how can I use organize to overwrite the existing file?
<kyrofa> wililupy, you can't, it'll conflict
<kyrofa> wililupy, but you can filter the one that's there out of the part that's providing it
<wililupy> kyrofa: I noticed that. How do I filter it out?
<kyrofa> wililupy, if we're talking the `stage` step, use the `stage` keyword. If the `prime` step, use the `snap` keyword
<wililupy> kyrofa: My source is a deb file. What I am doing now is running snapcraft build, then going into parts/part/install/opt/file/file.py and replacing it with a file.py that allows the snap to work.
<wililupy> Then I run snapcraft snap to complete the snap.
<kyrofa> wililupy, easy
<kyrofa> wililupy, you're use the dump plugin I assume?
<wililupy> kyrofa yes
<kyrofa> wililupy, try this: http://pastebin.ubuntu.com/23595408/
<kyrofa> wililupy, now that part will still have opt/file/file.py in its installdir, but it won't be included when that part is migrated to stage or prime
<kyrofa> wililupy, so another part can provide it
<wililupy> kyrofa, so remove the file from stage and snap and then use orgnaize to put the file in?
<kyrofa> wililupy, use another part to put that file in. That may or may not involve the organize keyword
<wililupy> kyrofa: http://pastebin.ubuntu.com/23595436/ Does this look right?
<kyrofa> wililupy, no, `snap` is a list just like `stage` is
<kyrofa> Not an object (like organize or filesets)
<wililupy> kyrofa: Gotcha. So then I will use organize to put the file in under snap: ?
<kyrofa> wililupy, we're missing each other a little, I think
<kyrofa> wililupy, snapcraft isn't really going to help you if you want to replace a part's file _within the same part_
<kyrofa> You'll need to do that as part of the build system
<kyrofa> wililupy, you need to split this into two parts. One part with the file filtered out, and another that supplies the new file
<wililupy> kyrofa: Ok. I see what your saying.
<kyrofa> Does that make more sense?
<wililupy> kyrofa create a new part and source the old part and use orgnaize to put the corrected python script in place.
<kyrofa> wililupy, that's sounding right, but can you define "source the old part"?
<wililupy> kyrofa: can I put in a feature request to have dump delete files? ;)
<kyrofa> wililupy, that's exactly what the stage/snap keywords are for
<kyrofa> wililupy, and they can be used by all plugins, not just dump
<wililupy> kyrofa: I guess I'm not sure how I would source the previous part.
<kyrofa> wililupy, I don't actually know what you mean by that :P
<kyrofa> wililupy, so let me ask: you have a deb that includes opt/flexswitch/flexswitch
<wililupy> I was thinking of creating another part in my snapcraft.yaml and under source, point to the parts/flexswitch and use the dump plugin.
<kyrofa> wililupy, you don't want that one, though, you want another one
<wililupy> But I don't think they will work.
<kyrofa> wililupy, no, don't do that
<kyrofa> wililupy, parts are supposed to be independent
<kyrofa> wililupy, that "other one," from what I see in this YAML, is actually also contained within the deb. Is that correct?
<wililupy> krofa: yes. the deb package includes opt/flexswitch/flexswitch, however, in a snap environment, it fails, so we have a python script with $SNAP and we want to put that one in place
<kyrofa> wililupy, where is the "python script with $SNAP" ?
<wililupy> its in the same directory as my snapcraft.yaml
<kyrofa> wililupy, perfect-- completely independent of the other part
<kyrofa> wililupy, make another part using the dump plugin and `source: .`
<kyrofa> wililupy, then use organize to put it in the right place, and voila
<wililupy> perfect
<wililupy> I'll try that.
<wililupy> kyrofa: http://pastebin.ubuntu.com/23595491/ Is this correct?
<kyrofa> wililupy, yes, that looks perfect!
<wililupy> kyrofa: Ok, time to test it out.
<wililupy> kyrofa, so it built, but when I try to install it on my device, I get the following error: error: cannot find signatures with metadata for snap "flexswitch_1.0.0.174.6_amd64.snap"
<kyrofa> wililupy, https://askubuntu.com/questions/822765/snap-install-failure-error-cannot-find-signatures-with-metadata-for-snap
<wililupy> kyrofa, that did the trick.
<mup> PR snapd#2428 opened: debian: add dependencies and build rules for snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2428>
<moritz_> How do i tell my snap app (primary binary) to start a daemon from within the snap? At the moment it starts the binary from my system because the local copy is first in my PATH.
<wililupy> Do we have an example of setting the LD_LIBRARY_PATH to a specific library directory in the snap? IE $SNAP/opt/file/lib/ ?
<jdstrand> zyga: hey, fyi, I was looking at snap-confine in xenial-proposed and noticed that there are several files in debian/patches that are not applied in debian/patches/series and can therefore be removed
#snappy 2016-12-08
<wililupy> how do I delete a user from a device?
<wililupy> Figured it out. I had to remove them from the files located in /writable/system-data/var/lib/extrausers and then delete their home directory and then I could re-add them with the snap create-user account.
<mup> PR snapd#2429 opened: snap-confine,debian: disable XDG_RUNTIME_DIR support, package snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2429>
<mup> PR snapd#2380 closed: debian: add missing ca-certificates dependency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2380>
<mup> PR snapd#2365 closed: interfaces: fix system-observe interface to work with ps_mem <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2365>
<mup> PR snapd#2430 opened: cmd/snap-confine: disable support for XDG_RUNTIME_DIR <Created by zyga> <https://github.com/snapcore/snapd/pull/2430>
<mup> PR snapd#2431 opened: cmd/snap-confine: don't use __attribute__((nonull)) <Created by zyga> <https://github.com/snapcore/snapd/pull/2431>
<mup> PR snapd#2414 closed: store: switch default delta format from xdelta to xdelta3 <Created by wgrant> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2414>
<mup> PR snapd#2394 closed: snap: show last refresh time <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2394>
<mup> PR snapd#2412 closed: snap: add description to `snap info` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2412>
<mup> PR snapd#2432 opened: cmd/snap-confine/tests: fix stale path after move to snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/2432>
<dholbach> hey hey
<mvo> ogra_: good morning. I noticed pc-kernel has new stable versions, do you know how those got promoted? is the kernel team taking care of this?
<seb128> hey dholbach mvo
<mup> PR snapd#2431 closed: cmd/snap-confine: don't use __attribute__((nonull)) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2431>
<seb128> sergiusens, hey, sorry you reply when I was already away yesterday ... is there any way to snapcraft to not try to be clever? I don't include the librairies because I want to use them over content sharing
<dholbach> hey seb128
<mup> PR snapd#2432 closed: cmd/snap-confine/tests: fix stale path after move to snapd <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2432>
<seb128> sergiusens, is that behaviour also documented somewhere? I can see how it can be useful but also it's not obvious which means confusing (especially if you know what you are doing and don't expect the tool to try to outsmart you)
<mup> PR snapd#2433 opened: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<didrocks> cjwatson: hey! It seems that launchpad builders for snapcraft can't download from people.canonical.com. Do you think this could be easily fixed or should I host the tarball somewhere else? https://launchpadlibrarian.net/297163330/buildlog_snap_ubuntu_xenial_amd64_christmas-music-carousel_BUILDING.txt.gz
<ogra_> mvo, yeah, bjf and ppisati do that now
<bzoltan> ogra_:  may I ask what kernel the latest Core has?
<ogra_> bzoltan, always the latest from updates/security
<mvo> ogra_: ok, so we can remove the trello card that we need to sync kernels snap updates, thats good news
<ogra_> mvo, yeah, there are still some bits open with QA i think, but they own the main branches .... we can go on using the old bzr branches for edge builds though, so that we can develop initrd stuff etc
<ogra_> (and i guess we'll move these too to github eventually)
<mup> PR snapd#2430 closed: cmd/snap-confine: disable support for XDG_RUNTIME_DIR <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2430>
<mup> PR snapd#2429 closed: snap-confine,debian: disable XDG_RUNTIME_DIR support, package snap-confine <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2429>
<cjwatson> didrocks: fixable, but might take a little while because we have a complicatedly-broken CI job in the way of making changes to that
<cjwatson> didrocks: could you file a bug against the "rutabaga" project (don't ask ...) requesting that?
<kalikiana_> ogra_: Do you know if anyone is investigating bug 1647333?
<mup> Bug #1647333: adduser misses extrausers support for group management <Snappy:New> <adduser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1647333>
<mup> Bug #1648427 opened: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:New> <https://launchpad.net/bugs/1648427>
<ogra_> kalikiana_, are you volunteering ? :)
<mup> PR snapd#2434 opened: tests: cherry-pick spread test fixes for 2.18.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2434>
<mup> Bug #1648431 opened: Allow snaps to shadow mounts from core <Snappy:In Progress by kalikiana> <https://launchpad.net/bugs/1648431>
<kalikiana_> ogra_: Depends... I seem to be touching lots of "random" bits and pieces these days without knowing what I'm getting into :-D
<kalikiana_> It's blocking snappy lxd so I am kinda interested in getting it fixed
<didrocks> cjwatson: sure, doing!
<mup> PR snapd#2435 opened: store: retry assertions <Created by stolowski> <https://github.com/snapcore/snapd/pull/2435>
<moritz_> I have a little problem with dbus activation. The app feedreader starts feedreader-daemon via dbus calls. Problem is dbus runs the daemon installed on my system not the daemon packaged in my snap. Any ideas?
<cjwatson> didrocks: ...?  (preparing a commit to fix it, would like to have a bug number)
<didrocks> cjwatson: oh sorry, was in some HO, doing it now, one sec
<didrocks> cjwatson: bug #1648451
<mup> Bug #1648451: people.canonical.com not accessible from builders <Rutabaga:New> <https://launchpad.net/bugs/1648451>
<cjwatson> ta
<jdstrand> mvo: I see you marked 1648427 as 'high'. what is a simple reproducer? I'd like to investigate a simple fix
<jdstrand> bug 1648427
<mup> Bug #1648427: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
<didrocks> it's a duplicate btw
<didrocks> I did write about it on my feedback emails a week ago
<didrocks> (I see they were read :/)
<didrocks> mvo: ^
<didrocks> bug #1644573
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
<mup> Bug #1644573 changed: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
<jdstrand> mvo, zyga: I'd like to look at bug #1644573 (bug #1648427) for a simple fix. what is a simple reproducer? snapctl ...what... within a shell without networking?
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
<mup> Bug #1648427: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
<didrocks> jdstrand: just create a configure hook calling snapctl
<didrocks> the configure hook with no plug
<didrocks> I have one snap for you if you want
<jdstrand> that'll work too
<mup> Bug #1648427 changed: Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket <Snappy:Triaged> <https://launchpad.net/bugs/1648427>
<mup> Bug #1644573 opened: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:New for zyga> <https://launchpad.net/bugs/1644573>
<zyga> jdstrand: hey, anything using the client package (e.g. snapctl) that doesn't have the right to talk to snapd over the full socket AFAIK
<jdstrand> zyga: I know. just snapctl without args? assume for just a moment I don't know how to use snapctl :)
<didrocks> jdstrand: you can install snow-on-me snap
<didrocks> in stable channel
<jdstrand> ok, that'll be good enough
<didrocks> jdstrand: remember that on 16.04, snapd is too old to work well with configure hooks
<didrocks> (desktop)
<jdstrand> didrocks: I'm running 2.17 from proposed. is that new enough?
<didrocks> jdstrand: I think, do you run as well a newer ubuntu-core with snapctl inside?
<jdstrand> I can
<didrocks> (as the core snap)
<didrocks> otherwise, you will see quickly, you will miss snapctl inside core
 * jdstrand runs sudo snap refresh core --edge
<mup> PR snapd#2436 opened: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2436>
<jdstrand> oh, that's neat
<moritz_> was the snap.second-command syntax changed? I got an error yesterday and it worked when i changed to snap-second-command. (v2.16)
<jdstrand> snap run --shell snap.hello-world.env
<jdstrand> error: cannot find current revision for snap snap: readlink /snap/snap/current: no such file or directory
 * jdstrand drops snap.
<mvo> didrocks: sorry, but look at it from the bright side, your bug gets attention :)
<didrocks> mvo: for once, yeah :p
<didrocks> mvo: still frustrating TBH
<mvo> didrocks: :(
<mvo> didrocks: sorry
<mvo> didrocks: on the bright side, snap info will be able to look into edge now too, not quite snap search but still.
<didrocks> great
<jdstrand> ah, just 'snapctl' is enough
<mup> Bug #1648478 opened: 'snap run --shell snap.hello-world.env' tries to read /snap/snap/current <Snappy:New> <https://launchpad.net/bugs/1648478>
<kalikiana_> zyga: I wonder if you could have a look at https://github.com/snapcore/snapd/pull/2436/files and see what I might be doing wrong - it doesn't create the .fstab file that the "content" interface creates. Also I half-hard-coded the path since I wasn't sure how to get a map from the yaml
<mup> PR snapd#2436: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2436>
<moritz_> Has nobody an idea about my dbus problem?
<jdstrand> zyga: where did README.md from snap-confine go?
<jdstrand> zyga: I don't see it in the wiki
<mup> PR snapd#2437 opened: misc: fix crash when $v is not set (set -u) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2437>
<renato__> jdstrand, hey, is this a valid policy? http://paste.ubuntu.com/23598590/
<elopio> ping kgunn. When is a good time for you tomorrow, for the ubuntu testing day?
<kgunn> 10:30? elopio
<kgunn> elopio: atm i'm thinkingn to walk through the setup instructions, have another hangout stream showing the current state of unity8 snap
<kgunn> on another machine
<kgunn> maybe highlight some bugs/hurdles we have...then take questions
<kgunn> does that sound reasonable
<elopio> kgunn: that sounds perfect. Do you think it will take you around 30 minutes to go over all that? I need to see if I should talk less or more.
<elopio> kgunn: 10:30, of which time zone?
<kgunn> eh...i would think prolly 15-20 min to maybe get through that
<kgunn> but...maybe i'm too optimistic on being quick :)
<kgunn> elopio: i'm in US central timezone
<kgunn> it's 8:40 am now
<elopio> kgunn: ok, I'll set up the calendar. Thank you!
<jdstrand> mvo, zyga: the quick fix I was thinking of won't work. I commented in the bug
<jdstrand> renato__: no
<jdstrand> renato__: 'name' is use in two places, with 'bind' and with 'send/receive' as part of peer=(name=...)
<jdstrand> renato__: you can do: peer=(name=org.gnome.evolution.dataserver.Subprocess.Backend.Calendar*, label=###PLUG_SECURITY_TAGS###)
<renato__> jdstrand, ok nice, thanks
<renato__> jdstrand, we can say that in most of the cases *ConnectedSlotAppArmor and *ConnectedPlugAppArmor will be the same value?
<jdstrand> renato__: no. send and receive are flipped, peer label is flipped and you won't specify name= on the plugs side since it is not a well-known name
<jdstrand> renato__: I recommend you profile each side separately to understand how they interact
<pmcgowan> renato__, can you reference bzr or git revno inside the snapcraft.yaml
<nacc> pmcgowan: git certainly -- let me look it ups
<mup> PR snapd#2437 closed: misc: fix crash when $v is not set (set -u) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2437>
<renato__> pmcgowan, looks like you can only specify a tag: http://snapcraft.io/docs/reference/plugins/source
<nacc> hrm, snapcraft on my system says there is also source-commit
<nacc> renato__: pmcgowan --^
<cjwatson> yeah, it's just not in the web docs for some reason
<nacc> http://paste.ubuntu.com/23598751/
<pitti> tvoss: do you have an opinion about whether we should release the systemd trusty SRU now, or wait longer?
<pitti> it's otherwise ready by policy)
<tvoss> pitti: I think we are good to releasing now, no point in waiting. if we encounter issues, we will have to SRU again anyway
<pitti> true
<mup> PR snapd#2438 opened: release: 2.18.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2438>
<pmcgowan> renato__, nacc what I want to do is use @BZR_REVNO@ in the version
<nacc> pmcgowan: how would that work? you mean your maintaining your snapcraft.yaml in a bzr repo?
<renato__> pmcgowan, I do not think this is possible since cmake will run after
<pmcgowan> nacc, no sorry I want to dymanically set the version string
<pmcgowan> like we were doing for clicks
 * nacc doesn't know anything about clicks :)
<renato__> pmcgowan, to get this the cmake will need to run before the snapcraft command.
<pmcgowan> ah
<renato__> pmcgowan, or maybe you can pass arguments to snapcraft command. But I do not think this is supported
<pmcgowan> renato__, seems a limitation to need to hard code the version
<mhall119> zyga: what's the status of snapd on fedora? I haven't heard anything in a while
<mup> PR snapd#2439 opened: vendor: update tomb package fixing context support <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2439>
<kalikiana_> pmcgowan: You need to modify the yaml before running snapcraft atm
<pmcgowan> kalikiana_, ack
<mup> PR snapd#2439 closed: vendor: update tomb package fixing context support <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2439>
<SamYaple> /win/win 22
<t1mp> Trevinho: hello
<t1mp> Trevinho: I merged your MR that removes the deprecated plugins from the ubuntu-app-platform snap
<t1mp> Trevinho: now I'm looking at https://code.launchpad.net/~3v1n0/ubuntu-app-platform/+git/ubuntu-app-platform/+merge/311953
<t1mp> Trevinho: would adding after: -indicator-qt have the same effect in the platform snap as when adding it to each app snap individually?
<t1mp> I'm also wondering for the apps that use the app platform snap, why do we still need after: [desktop-ubuntu-app-platform]. Couldn't we simply include that in the ubuntu-app-platform snap?
<t1mp> Trevinho: I added a comment on https://code.launchpad.net/~3v1n0/ubuntu-app-platform/+git/ubuntu-app-platform/+merge/311953
<t1mp> maybe I am not understanding how it works yet
<t1mp> kalikiana_: ^do you have an opinion/answer on my question on that MR?
<kalikiana_> t1mp: The "after" seems odd. Is that part part of the platform snap yet?
<t1mp> kalikiana_: no, there is no after: in the platform snap yet. It was proposed in the MR.
<t1mp> so that made me wonder why to add it, and if we add the indicator-qt5 there then why not add desktop-ubuntu-app-platform
<t1mp> I don't know if there is a good/bad approach here, or it is a matter of policy, or I just don't understand it yet ;)
<kalikiana_> t1mp: Ah, stupid question, the after pulls it in because it's a remote part
<kalikiana_> Indicators certainly make sense as part of the platform snap to me
<t1mp> and what do you think about desktop-ubuntu-app-platform? Do I get it right that when I just add that to the ubuntu-app-platform, we don't need to pull it in for the app snaps any more?
<kalikiana_> You can use them separately, but really, when you're using the platform snap you kind of expect the "usual suspects" to be in there
<kalikiana_> t1mp: That's the launcher, right? Is there any use case that conflicts with that?
<kalikiana_> At some point we had this pile of half a dozen different ones
<t1mp> yes, it is the launcher.
<t1mp> ah, I see now, https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml there are a bunch of launchers
<t1mp> it pulls in the build packages for qt5.
<t1mp> perhaps leaving those out can break building of some snaps
<t1mp> maybe this is being used a some kind of replacement for the "build tarball" that we discussed a while ago
<kalikiana_> What makes you think so? All I see is qtbase5-dev
<mup> PR snapd#2434 closed: tests: cherry-pick spread test fixes for 2.18.1 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2434>
<Trevinho> t1mp: yeah, it's the same of adding it to each app
<t1mp> kalikiana_: oops. What I meant is maybe we can use a construction like this as a replacement for the build tarball.
<t1mp> but then obviously we'd have to include a lot more than just qtbase5-dev
<kalikiana_> t1mp: The tarball could just sit in a remote part, no? We just need to make sure the libs won't be automatically staged as well
<t1mp> right
<pmcgowan> popey, mhall119 do you have a snap store account for core app developers or some such
<mup> PR snapd#2440 opened: release: 2.19 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2440>
<popey> pmcgowan: depends what you want to upload, things are a bit all over the place
<ogra_> you should do the same we are doing with the canonical account ...
<ogra_> sharing maintenance with snaps is so much easier than with clicks
<ogra_> (same -> set up a central core-apps account and then share the snap ownership with individuals as needed from that)
<popey> yes
<mup> PR snapd#2436 closed: Implement 'shadow' interface for mounting snap folders <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2436>
<mup> PR snapcraft#949 closed: project: support building classic snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/949>
<cholcombe> i've uploaded a new version of my snap that resolves an issue but it seems that the store is stuck waiting on my old version to pass or fail review
<cholcombe> can anyone help with that?
<mup> PR snapd#2441 opened: debian: add split ubuntu-core-launcher and snap-confine packages <Created by zyga> <https://github.com/snapcore/snapd/pull/2441>
<mup> PR snapd#2426 closed: spread.yaml: run dmesg -c with sudo and log the id before running it <Created by plars> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2426>
<mup> Bug #1648615 opened: Apps hit apparmor denial trying to connect to unity8's mir_socket <Canonical System Image:New> <Snappy:New for ted> <https://launchpad.net/bugs/1648615>
<iliv> how do you guys handle applicaiton configuration files? as in, how should (can?) I install /etc/application.cfg that also has some settings that reference filesystem paths like log and pid file, etc. location under /var/log /var/run etc.
<JaBaZ> Can anyone help me with problem installing webdm Ubuntu snappy core on Rpi 2?
<JaBaZ> I got error Mount snap "webdm" (24) (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
<JaBaZ> Anyone
<kyrofa> JaBaZ, how are you installing it?
<kyrofa> JaBaZ, as "webdm" was renamed to "snapweb" long ago
<kyrofa> alex-abreu, do we intend to unpublish webdm?
<kyrofa> JaBaZ, try `snap install snapweb` instead
<JaBaZ> Okay, i tried it
<JaBaZ> try it
<JaBaZ> That installed succesfully
<JaBaZ> Thanks!
#snappy 2016-12-09
<liuxg> does anyone know how to select a different mirror server in ubuntu core using command. The reason for this is that some of the servers are far away from my region, and the build process is very long. thanks
<liuxg> I am now using a ubuntu core device to build a snap.
<mup> Bug #1648702 opened: We don't have a network interface that allows only local communication <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1648702>
<mup> Bug #1648712 opened: Whole /etc content from host accessible to the snap <Snappy:New> <https://launchpad.net/bugs/1648712>
<FJKong> liuxg: you can edit config file directly
<liuxg> FJKong, but it is too much work. do you mean the sources.list file?
<liuxg> FJKong, for some of the channels, there could be no correspondence.
<FJKong> just %s/a/b/cgi with vim, you can skip some of it, this should be very fast
<FJKong> backup before editing, by the way
<mup> PR snapd#2442 opened: snap/snapenv: don't obscure HOME if snap uses classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/2442>
<mup> PR snapd#2443 opened: removing circular dependency between snapstate and hookstate <Created by cyberb> <https://github.com/snapcore/snapd/pull/2443>
<mup> PR snapd#2444 opened: debian: depend on snap-confine at least 2.19 <Created by zyga> <https://github.com/snapcore/snapd/pull/2444>
<mup> PR snapd#2445 opened: cmd/snap,tests: alias support in snap run <Created by pedronis> <https://github.com/snapcore/snapd/pull/2445>
<mup> PR snapd#2446 opened: cmd/snap-confine: fix compilation on platforms with gcc < 4.9.0 <Created by zyga> <https://github.com/snapcore/snapd/pull/2446>
<mup> PR snapd#2447 opened: many: fixes cherry-picked for the 2.19.1 release <Created by zyga> <https://github.com/snapcore/snapd/pull/2447>
<mup> PR snapd#2428 closed: debian: add dependencies and build rules for snap-confine <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2428>
<mup> PR snapd#2446 closed: cmd/snap-confine: fix compilation on platforms with gcc < 4.9.0 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2446>
<palasso> Hello, I noticed from times to times spam gets through into the snapcraft mailing list. Shall spams be removed from the archive?
<palasso> Some include links which I haven't clicked
<mup> PR snapd#2435 closed: store: retry assertions <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2435>
<mup> Bug #1648777 opened: writing a (3GB sized) x86 image to a 3GB SD card makes the filesystem resizing being skipped <Snappy:New> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1648777>
 * ogra_ loves how filing a bug brings an IRC highlight as freebie every time :P
<palasso> Those are some spams I found on the snapcraft mailing list (some of which include links to files) http://pastebin.com/eeXLTfT4
<dslul> hello
<dslul> has anyone managed to get this tutorial work https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ ?
<dslul> in particular mir kiosk
<dslul> on a virtual machine
<dslul> it gives Mir fatal error: Failed to get frontbuffer
<dslul> where can I file this bug?
<didrocks> dslul: hey, I think kgunn will be interested in your feedback
<didrocks> he should show up a little bit later on on this channel
<blunden> is there a way to pass environment variables to snap packages? ie. I want to pass PORT and ROOT_URL to a rocket.chat server installed via snap
<blunden> but they don't get picked up properly when exported
<blunden> I also think the use of PORT is kind of stupid as there is bound to be another application reading that generic variable as well
<didrocks> blunden: yeah, environment is stripped. You need to use configure hook for this
<blunden> didrocks: is that documented somewhere?
<blunden> I'm clearly missing the correct search term when googling :P
<didrocks> blunden: well, TBH, the documentation isn't there yet
<didrocks> but
<didrocks> I have an example!
<blunden> that works too :D
<didrocks> https://github.com/ubuntu/snow-on-me-snap
<didrocks> I've created a very generic configure hook: https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
<didrocks> it enables to set and remove variables that are stored in a file
<didrocks> that your app can pick up
<didrocks> snap set <snap_name> key=value
<didrocks> (/!\ you need to do it on ubuntu core, doesn't work well yet with snapd version on desktop)
<didrocks> and a simple nodejs example on watching for a change and picking it up: https://github.com/ubuntu/snow-on-me-snap/blob/master/main.js#L71
<blunden> this is on a normal ubuntu server 16.04.1 instance
<blunden> so this is something that needs to get upstreamed to the rocket.chat project?
<didrocks> yeah, I would suggest that
<didrocks> supporting dynamic configuration and such
<didrocks> (would be a nice contribution I think :))
<blunden> I was hoping for something that I could do right now :)
<blunden> I really don't want to bloat up this server with all the cruft their project depends on
<didrocks> I don't think there is other way, you can modify their snap as well and build it yourself if you have the source
<didrocks> then, a small wrapper watching for the config file
<didrocks> once the config file is there, reading it and exporting PORT before exec their service
<blunden> ideally they should just read the values from the config file instead of using a bunch of very generically named env variables in my opinion
<blunden> thanks for the examples though :)
<didrocks> yw! :)
<blunden> didrocks: that "snap set" part where you set the port... is that using your hook too?
<blunden> ah, it said so above :)
<didrocks> blunden: yes :)
<blunden> and by "you can only set on of those" you mean that they need to be set one at a time?
<didrocks> blunden: no, just setting one from the supported keys in the configure hook
<didrocks> so, in that case port and title
<didrocks> you can either do:
<didrocks> snap set <snap_name> port=4242 title="blablabla"
<didrocks> or just
<didrocks> snap set <snap_name> port=4242
<didrocks> or even snap set <snap_name> port=""
<didrocks> which will remove the key from the configuration
<blunden> that's not how I read "Of course, you can set only one of those parameters."
<blunden> ooh
<blunden> nvm
<blunden> I misread it
<blunden> I basically read it as "Of course, it's only possible to set one of those parameters"
<blunden> the sentence is ambiguous
<blunden> now that I look at it more, your example looks very nice and generic
<blunden> thanks again
<didrocks> yw :)
<didrocks> blunden: do not hesitate to rephase it (PR accepted), as not being a native speaker hereâ¦ :)
<blunden> ok
<blunden> I'm home from work sick so I might just do that
<didrocks> oh, hope you're feeling better soon!
<didrocks> hoping*
<blunden> thanks
<blunden> pull request sent :)
<didrocks> and merged, thanks!
<blunden> np
<morphis_> kyrofa: ping
<dslul> kgunn, I had problems running mir kiosk, I wrote in private the details
<didrocks> ogra_: oh, grub! that starts to all make sense then
<ogra_> didrocks, yeah ... but we should still stay in sync with the content ... more worrying is that nobody noticed fuse support missing on all non x86 arches
<didrocks> ogra_: well, nobody noticed the libpng which could be popularâ¦
<didrocks> ogra_: yeah, that was the point of the bug, to stay in sync :)
<ogra_> didrocks, well, for libpng i'D expect most snaps to just ship it inside
<didrocks> ogra_: what I did, until snapcraft strips it :p
<ogra_> bah
<ogra_> evil :)
<ogra_> anyway, we got it now :)
<kgunn> dslul: just not getting on for the morning, lemme catch up
<renato__> popey, hey could you review this, please? https://code.launchpad.net/~renatofilho/ubuntu-docviewer-app/ubunut-app-platform/+merge/312913
<jdstrand> ogra_: fyi, I don't know this, but suspect libfuse2 has something to do with lxd
<jdstrand> perhaps historically. I don't know
<ogra_> jdstrand, you mean thats the reason why grub-common depends on it ?
<jdstrand> ogra_: oh, I idn't read your email that way. I didn't realize grub depended on it. ignore me then
<ogra_> heh, i didnt either, i just found out before you pinged :)
<ogra_> in any case we have core providing the fuse interface by default ... so not having the lib seeded will most likely cause issues on non x86
<jdstrand> indeed
<mup> PR snapd#2448 opened: Account for trusty-specifics in interfaces <Created by vosst> <https://github.com/snapcore/snapd/pull/2448>
<didrocks> ogra_: while you are in those image rebuilding, will it be easy to have i2c enabled in rpi* images gadget snaps?
<mup> Bug #1639981 opened: request canceled (Client.Timeout exceeded while awaiting headers) <Click Package Index:Confirmed> <Snappy:Confirmed> <https://launchpad.net/bugs/1639981>
<ogra_> didrocks, i2c is enabled in the gadgets (in config.txt) ...
<ogra_> does it not work ?
<kyrofa> morphis_, good morning! What's up?
<morphis_> ogra_: we need actual i2c slot definitions in the gadget snap.yaml
<morphis_> kyrofa: morning!
<morphis_> kyrofa: just wanted to find out what the outcome of the snapcraft/hooks meeting was :-)
<kyrofa> morphis_, a redesign :P
<kyrofa> morphis_, and it was placed behind another feature, which likely bumps it to the next cycle
<didrocks> ogra_: snap interfaces didn't show up on my core
<didrocks> ogra_: I didn't try since last week though
<didrocks> is that recent?
<didrocks> or should I reflash?
<kyrofa> morphis_, now instead of specifying them in the YAML, you'll place them in the snap/hooks directory, and snapcraft will then generate the actual hooks via wrappers
<morphis_> kyrofa: I see, so what would this mean in terms of actual dates
<morphis_> next year I guess, right?
<kyrofa> morphis_, yeah I'm afraid so
<morphis_> hm
<ogra_> diddledan, ah, well, it is enabled but there is no iterface, now i get it ... the gadgets didnt change in a while and will only for next stable release
 * diddledan laughs maniacally about hijacking messages meant for didrocks
<bregma> hey folks I', tryin to evaluate Ubuntu Core on a RasPi2... I can get it to boot but I never get the "Press enter to confiugure" prompt at the end of the boot sequence.  I'm using only the serial port on the Pi, is this supported or is a USB keyboard and HDMI monitor required for first boot?
<kyrofa> bregma, probably a question for ogra_ if he's around
<ogra_> bregma, serial should work, we enable both consoles by default
<ogra_> (and both should show the press enter ... did you wait long enough ?
<ogra_> )
<mup> PR snapd#2425 closed: store: decode response.Body json inside retry loops <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2425>
<mup> PR snapd#2449 opened: overlord/patch: patch to flag in the state required snaps from model <Created by pedronis> <https://github.com/snapcore/snapd/pull/2449>
<kgunn> morphis: if you're still about...tried pa from the beta channel
<kgunn> getting this
<kgunn> http://pastebin.ubuntu.com/23604916/
<bregma> ogra_, I've waited for 150 minutes now, still no prompt; I see the serial console enabled in the kernel command line and I see the boot messages, so I suspect the problem is whatever it that's does the first-time setup just can't cope
<bregma> it's OK, other distros just let me get work done, so first impression of Ubuntu Core on the Pi2 is "doesn't work, don't bother" and I'll just move on
<kyrofa> kgunn, pa doesn't like ACDC-- you didn't know that?
<kyrofa> kgunn, do you see any denials from snappy-debug?
<kgunn> lemme check
<kgunn> kyrofa: ah...that's it...i shoulda checked...
<kgunn> reinstalling with --demode
<kgunn> well..it seems it's playing someplace but i don't hear it
<kgunn> maybe a prob with my vm?
<kyrofa> kgunn, still seeing something like this? http://pastebin.ubuntu.com/23604968/
<kgunn> kyrofa: after devmode...now looks like this
<kgunn> http://pastebin.ubuntu.com/23604974/
<kyrofa> Huh, even in devmode?
<kyrofa> Oh wait, allowed, nevermind
<kyrofa> kgunn, I assume the previous denial was from the lack of a home interface?
<kgunn> that's right, it could access it's home
<kgunn> kyrofa: i'm wondering if it's the sound device selected by this vm
<kyrofa> kgunn, yeah I wouldn't be surprised. Honestly I'm not sure I've ever tried playing audio in a VM before. KVM?
<Guest78889> what basic thing am I missing. I have ubuntu core up and running on a pi3. How do I install nano or samba?
<kyrofa> Guest78889, remember that ubuntu core uses snaps, not debs
<kyrofa> Guest78889, `snap find nano` shows nano-editor as an option. Have you tried that?
<kyrofa> (I have not)
<Guest78889> yes I have
<Guest78889> it doesn't find it
<kyrofa> Guest78889, nano-editor.nano ?
<kyrofa> Works for me
<Guest78889> when I look at the web page version of the store I can find nano-editor but then download is only amd64
<kyrofa> (just tried it)
<kyrofa> Oh, I see
<kyrofa> Perhaps rws only published an amd64 version, then
<Guest78889> seems that way for everything I could think of searching for
<Guest78889> so I thought I must be missing something
<Guest78889> or is this all just that new
<kyrofa> Guest78889, most snaps are provided by developers. Looks like rws build nano on their own amd64 machine instead of multiple architectures
<mup> PR snapd#2391 closed: Discard mount namespace on a content i/f plug connect/disconnect <Created by albaguirre> <Closed by albaguirre> <https://github.com/snapcore/snapd/pull/2391>
#snappy 2016-12-10
<mup> PR snapd#2450 opened: interfaces: add network-namespace-control (LP: #1624675) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2450>
<mup> PR snapcraft#953 opened: sources: refactor base sources into new package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/953>
<tommyt> hi to everybody
<tommyt> some info?
<tommyt> about snappy
<tommyt> to use the new package manager that create a kind of jail for the application
<tommyt> the CPU need the virtualization support?
<mup> PR snapd#2442 closed: snap/snapenv: don't obscure HOME if snap uses classic confinement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2442>
<thibran> hello, I have a question about snapping a simple go app. anyone willing to help?
<mup> Bug #1648988 opened: Unable to fork a new WebProcess: Failed to execute child process "/usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess" (No such file or directory). <Snappy:New> <https://launchpad.net/bugs/1648988>
<mup> Bug #1648990 opened: Support DBus-activatable apps <Snappy:New> <https://launchpad.net/bugs/1648990>
<alvarolb> hi, is there any way to run snapcraft to build a different path rather than the current folder?
<qengho> (cd other; snapcraft;)  ?
<toml> hi there
<toml> I'm new to snap and I struggle finding the website where you can browse available snaps.. any advice ?
<DanChapman> toml, you can either install the "snapweb" snap and browse the store on localhost:4200 or you can use https://uappexplorer.com/apps?type=snappy
<toml> DanChapman: thx it does not seem to have a lot of app there :( and also I'm trying snap on Ubuntu core which seems to add additional barriers
<Garsam_> I've install snappy core on a pi3. I've created a ssh key and imported it. Put the sd in and followed the steps. I'm now at the login page. What's the default user and password
<jmart2> So, for a newbie programmer how hard is it to make a snap
#snappy 2016-12-11
<changezkhan> is there any resources on learning how to create snaps?
<OerHeks> http://snapcraft.io/docs/build-snaps/
<mup> PR snapd#2443 closed: removing circular dependency between snapstate and hookstate <Created by cyberb> <Closed by cyberb> <https://github.com/snapcore/snapd/pull/2443>
#snappy 2017-12-04
<mup> PR snapcraft#1783 closed: tests: run codespell as part of static tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1783>
<mcphail> In my snapcraft.yaml, I have a part which depends on a library and header files I build in a previous part. How do I reference those files in the build? Passing "-I/usr/include" as a CFLAG doesn't automagically resolve, so what path should I pass instead?
<mcphail> http://termbin.com/icbu is the work in progress
<diddledan> mcphail: you need to point to their location using $SNAPCRAFT_STAGE
<mcphail> diddledan: aah. cool. I'll experiment with that. Cheers
<diddledan> so if they're installing into `/usr/include` then you'd use `-I$SNAPCRAFT_STAGE/usr/include` - but you don't seem to be telling the autotools build where you want the files installed
<diddledan> which usually means autotools will use `/usr/local` pathjs
<diddledan> paths*
<mcphail> yeah - i'll need to work out how to pass a --prefix as well
<mcphail> Ta. I'll get back to work! :)
<diddledan> you can pass arguments to ./configure command with `configflags:` in your snapcraft.yaml
<mcphail> Ta. I think it sets a blank --prefix by deafult, doesn't it?
<diddledan> `configflags` expects a yaml list, so either new lines with `- ` indicating each item, or `[--flag1, --flag2, ...]`
<diddledan> difficult to do multiline pastes in IRC :-p
<mcphail> :) - that's brilliant. Cheers diddledan
<diddledan> here's an example of the two types of list https://www.irccloud.com/pastebin/8HsmUyMD/snapcraft.yaml
<mcphail> ta
<diddledan> I had a hard time grokking yaml when I first came across it because the rules weren't clear to me, but I'm learning
<mcphail> yay - builds!
<diddledan> \o/
<mcphail> That's super. Thanks for your help
<diddledan> no probs :-)
<pattern> hey anyone have a second to help me with ubuntu core for raspberry pi?
<mup> PR snapcraft#1785 opened: Add type hinting to file_utils.py <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1785>
<Pharaoh_Atem> I'm very annoyed
<Pharaoh_Atem> I think I'm going to have to go back to vendoring snap-mgmt in Fedora Dist-Git if it breaks like this again
<Pharaoh_Atem> I'm incredibly disappointed that my feedback was not solicited as the author of snap-mgmt before merging the PR
<Pharaoh_Atem> whatever, good night everyone
<bujeremy> would bytemark be an SSL or an email-provider with LibreSSL ?
<mborzecki> morning
<zyga-ubuntu> good morning!
<mborzecki> hey
<mvo> hey zyga-ubuntu and mborzecki
<zyga-ubuntu> mvo: hey :)
<zyga-ubuntu> mvo: how was last friday?
<zyga-ubuntu> mvo: any fires?
<mvo> zyga-ubuntu: all pretty quiet, no worries
<mborzecki> zyga-ubuntu: quick question, Son_Goku raised an issue https://github.com/snapcore/snapd/pull/4316#discussion_r154561886 and I don't really have enough info to act on it, I see that this is an extra profile that's set up for snap-confine in the core snap, any idea where's the code that installs it?
<mup> PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316>
<zyga-ubuntu> mborzecki: the interfaces/apparmor backend does this
<zyga-ubuntu> mborzecki: setupSnapConfineReexec
<mborzecki> looking
<mborzecki> zyga-ubuntu: so the 'extra' profile is always '${snap-mount-dir}/core/<rev>/usr/lib/snapd/snap-confine'?
<zyga-ubuntu> mborzecki: yes
<mborzecki> zyga-ubuntu: hmm, do you understand what Son_Goku was talking about here then? https://github.com/snapcore/snapd/pull/4316#discussion_r154561886
<mup> PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316>
<zyga-ubuntu> I think he was just confused about this aspect
<zyga-ubuntu> base snaps, even once we have them, can have any layout but this particular one is specific to the ubuntu-based core snap
<mborzecki> that's my understading as well, just wanted to make sure i didn't miss anything
<zyga-ubuntu> as long as snap-confine is in the core snap this code is correct
<mborzecki> zyga-ubuntu: another quick question, any idea why it's sleeping here? https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/snapd.postrm#L7 i assumed that it's a woraround for some weirdness in older systemd, but then tracked it back to https://github.com/snapcore/snapd/commit/67902f1ef14dd29ff809fabfcb9f7b2cbcd5fb7f and there does not seem to be any reason given for adding this
<zyga-ubuntu> mborzecki: looking
<zyga-ubuntu> mborzecki: not 100% sure but isn't it the case that "stop" can return before the thing is really stopped?
 * zyga-ubuntu observes fresh snow falling outside 
<mborzecki> yeah, this would happen if you hit a timeout in systemctl stop
<mborzecki> hmm the opensuse package has not been updated for quite some time, and the tumbleweed build fails https://build.opensuse.org/package/show/system:snappy/snapd
<zyga-ubuntu> ah
<zyga-ubuntu> mborzecki: those failures are from new golang
<zyga-ubuntu> mborzecki: they are fixed in master, we should just find some time to update the package
<mborzecki> iirc there was some magic that you could do with obs to have it look/update package automatically
<zyga-ubuntu> mborzecki: yes but I'm afraid packaging needs real hand care each time
<zyga-ubuntu> mborzecki: and we need to test it before unleashing it onto our users
<zyga-ubuntu> mborzecki: I'd like to see mvo's face if we had automatic releases to xenial, that just get made without testing :)
<mborzecki> well, ideally all the testing you need should be part of the CI right?
<zyga-ubuntu> mborzecki: just like we do in ubuntu
<zyga-ubuntu> mborzecki: I think we're not ready for that, there's a class of tests disabled for opensuse
<zyga-ubuntu> mborzecki: and nobody on the team is using it 24/7
<mvo> zyga-ubuntu: my face is nothing compared to the users faces ;)
<ogra_> it might make us find regressions in no time though :P
<mborzecki> crowsouring QA
<mborzecki> s/crowsouring/crowdsourcing/
<zyga-ubuntu> mborzecki: s/crowdsourcing/crowdangering/
<mup> PR snapd#4344 opened: cmd/snap-mgmt: fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4344>
<mup> PR snapd#4345 opened: packaging/opensuse-42.2: package and use snap-mgmt <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4345>
<mvo> zyga-ubuntu: 4325 looks ready, if you could re-review we have one less PR :)
<zyga-ubuntu> mvo: looking
<kalikiana> o/
<zyga-ubuntu> done
<zyga-ubuntu> hey kalikiana
<mup> PR snapd#4325 closed: Adding test for netlink-connector interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4325>
<mup> PR snapd#4346 opened: Make snapd.autoimport configurable <Created by ogra1> <https://github.com/snapcore/snapd/pull/4346>
<ogra_> mvo, ^^^
<mvo> ogra_: thanks, looking
<mvo> ogra_: heh, thats a small patch
<ogra_> yeah, thanks to having a function like that :)
<mvo> ogra_: yeah, I was thinking that too: "looks like this was done right"
<ogra_> we should look at the other bits too one day, i'm sure there is more that could be generalized in such a way
<mvo> ogra_: how urgent is it? it looks trivial enough so that we call pull it into .30 even
<ogra_> not super urgent
<mvo> ok, thanks
<ogra_> (like ... could wait for a 30.1 if one happens anyway or even for .31)
<zyga-ubuntu> 2.30.1.1
<mvo> ogra_: ok, I tagged it 2.30, there will be at least one more 2.30~rc2
<mvo> ogra_: so we can pull it in there
<ogra_> cool
<m4sk1n_> 21:08:33 <m4sk1n_> I'm trying to add i18n support for snapcraft
<m4sk1n_> 21:18:48 <m4sk1n_> marked strings, added build_i18n to setup.py, but can't get to make it using .mo files
<mup> PR snapd#4347 opened: tests: increase warn-timeout to 15m <Created by mvo5> <https://github.com/snapcore/snapd/pull/4347>
<mup> PR snapd#4348 opened: tests: increase workers for ubuntu-{14,16}.04-64 by one <Created by mvo5> <https://github.com/snapcore/snapd/pull/4348>
<zyga-ubuntu> hmm
<zyga-ubuntu> so
<zyga-ubuntu> on core the / inside the core snap doesn't match /snap/core/current
<zyga-ubuntu> s/inside the core snap/inside the executiong environment/
<mvo> mborzecki: I'm looking at 4340 right now, expect a review in some minutes
<mborzecki> mvo: thanks
<zyga-ubuntu> hmmmm
<kalikiana> zyga-ubuntu: that's surely expected?
 * zyga-ubuntu thinks about http://pastebin.ubuntu.com/26111465/
<zyga-ubuntu> kalikiana: no, it's not
<zyga-ubuntu> kalikiana: I think this is a bug
<kalikiana> zyga-ubuntu: what do you see there that's wrong?
<kalikiana> I'd expect mounts to only show up on /
<zyga-ubuntu> kalikiana: well, for once, / should really be the core snap (outside the execution environment)
<zyga-ubuntu> kalikiana: then looking at that list I find it ... too long
<zyga-ubuntu> anyway, I just need to focus and analyze that
 * kalikiana needs coffee
 * ikey needs an army of testers -_-
<mborzecki> mvo: thanks for suggestions, it looks quite nice
<mvo> mborzecki: great, happy that you like them
<ikey> 27 downloads and 8 of them are me lol
<mvo> mborzecki: one thing I forgot, I wonder if we should also ensure that "daemon" is != "" when before/after is used
<mvo> ikey: for what snap?
<ikey> the lsi snap
<ikey> once snapd 2.30 drops ima go enlist an army of testers :p
<zyga-ubuntu> hey ikey
<ikey> rawr
<mvo> ikey: heh, sounds great. I am a bit scared of installing it, once I have steam I will not stop playing it ;)
<mborzecki> mvo: i think after/before is applied regardless of what's in [Service], eg you can have a oneshot service that starts after some target
<ikey> mvo, well just install broken games and you'll be saved :p
<mvo> haha
<zyga-ubuntu> mvo: make sure to play the games you like the least
<zyga-ubuntu> ;-)
<mborzecki> mvo: otoh, we cannot really express such relation in snap yaml atm
<mvo> mborzecki: yeah, sorry, I was not precise. an app can be any sort of daemon or a standalone binary. so we might want to check to ensure it is really != a standalone applicaton
 * ikey goes off in search of copious amounts of caffeine
<mborzecki> mvo: ok, what you suggest is to raise an error when !app.IsService() ?
<ikey> an IV drip will do..
<zyga-ubuntu> ikey: try geen tea
<ikey> oh you mean monster? ok
<ikey> >_>
<mvo> mborzecki: yeah, I think so
<mborzecki> ok
<mvo> mborzecki: or do you think thats inappropriate?
<mvo> zyga-ubuntu, ikey: green tea++
<mborzecki> i think it's ok, once we'll probably learn more about use cases once this is introduced into the wild
<mvo> mborzecki: *nod*
<mborzecki> mvo: btw, https://gist.github.com/mvo5/6e0ac963aacce9d0c78f1c7cf829f9c4#file-validate-go-L15 this will exhaust stack calling a.String() in a loop :)
<mvo> mborzecki: oh, silly me
<mvo> mborzecki: indeed, tests ftw :)
<zyga-ubuntu> aha, I think I found the bug now
<zyga-ubuntu> I think I need that coffee and then I can fix it :)
<mup> PR snapd#4349 opened: Make snapd.autoimport configurable <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
<ikey> so i dont know how much use this is to anyone but i ported the remainder of the 4.13 apparmor stuff into the solus 4.14 kernel last night
<ikey> and its working fine for snapd
<zyga-ubuntu> ikey: thank you for doing that!
<zyga-ubuntu> ikey: is there a lot of delta left? (vanilla vs apparmor)
<ikey>  19 files changed, 1882 insertions(+), 28 deletions(-)
<ikey> https://dev.solus-project.com/source/linux-current/browse/master/files/security/0001-apparmor-Merge-items-still-missing-from-upstream.patch
<zyga-ubuntu> interesting, thank you
<ikey> majority of it is because of af_unix/dbus
<ikey> well lets generalise that as "socket"
<ikey> because net.c is a big component of it too
<mup> PR snapd#4346 closed: Make snapd.autoimport configurable <Created by ogra1> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4346>
<ikey> honestly i think some of that stuff could probably belong to securityfs and lsm APIs by now
<ikey> reduce duplication, same as for the secureexec bits
<pedronis> mvo: I added Gustavo to ogra PR, not sure we want to surface in the config the implementation detail that this is a separate service
<pedronis> I'm also a b it worried that people will not understand the implications of turning it off
<ogra_> it isnt like it is publically exposed anywhere or so
<mvo> pedronis: ok
<pedronis> mvo: alsos why does it make boot slow? do we wait on it?
<mup> PR snapd#4345 closed: packaging/opensuse-42.2: package and use snap-mgmt <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4345>
<ogra_> pedronis, the particular customer has a bunch of other disk devices on the HW (that are used for other stuff but some contain vfat, are attached via the usb bus and are slow in responding)
<mvo> pedronis: we don't wait for it afaict
<ogra_> (and they will never use the feature)
<pedronis> an option to list devices it should use might make more sense
<mvo> review for 4338 looks like an easy win
<pedronis> I don't know
<pedronis> either way I suspect Gustavo might have opinions how this is spelled
<ogra_> well, if we cant use the services function it will become a lot more complex i suspect
<ogra_> but yeah, understood
<mvo> mborzecki: does 4308 needs a master merge?
<mup> PR snapd#4304 closed: debian: demote gnupg from dependencies to recommends <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4304>
<mborzecki> mvo: i'd like to have #4344 resolved first
<mup> PR #4344: cmd/snap-mgmt: fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4344>
<mborzecki> mvo: shall i add blocked tag 4308?
<mvo> mborzecki: sounds good
<mvo> mborzecki: and a note ideally
<mvo> mborzecki: why its blocked
<mborzecki> Son_Goku: thanks for looking at 4344
 * Son_Goku mumbles something about reviewed...
<mup> PR snapcraft#1784 closed: cli: show helpful message for 'snapcraft list-keys' with no keys <Created by BayMinimum> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1784>
<mup> PR snapd#4350 opened: debian: make "gnupg" a recommends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4350>
<mup> PR snapd#4344 closed: cmd/snap-mgmt: fixes <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4344>
<zyga-ubuntu> mvo: do you have a second?
<sergiusens> hey mpt, can you please take a look at the UX side of snapcraft#1780 ? I've added some comments you can agree or disagree on and pasted some output for it to be easier to review
<mup> PR snapcraft#1780: cli: add export-login command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1780>
<cachio> mvo, I'll be 5 minutes late today
<cachio> mvo, still 2 weeks of kinesiology missing
<mup> PR snapd#4341 closed: tests: new test to validate location control interface <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4341>
<mup> PR snapd#4351 opened: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4351>
<sborovkov> Hi!
<sborovkov> How can I find what those changes are "error: cannot refresh "core": snap "core" has changes in progress"?
<sborovkov> I get the same when trying to update my own snap
<sborovkov> And it does not seem to really have any changes
<mpt> looking
<jdstrand> ikey: hey, cool. fyi, you might be interested in https://gitlab.com/apparmor/apparmor-kernel. I don't know how jjohansen is going to have separate branches for different kernels, but you might want to talk to him about that
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: I'm still on that stale core issue, it misbehaves on core systems; I'm looking at it
<jdstrand> zyga-ubuntu: is the misbehavior the needing of the additional rule?
<jdstrand> '/'?
<zyga-ubuntu> jdstrand: no, it's a bug where the namespace is always stale
<jdstrand> oh, ok
<zyga-ubuntu> jdstrand: trying to check if this is bad logic or bad test setup
<jdstrand> zyga-ubuntu: and hi :)
<jdstrand> zyga-ubuntu: fyi, mvo said that this is not a 2.30 item, but I have a number of 2.30 items to work on this week, so I plan to focus on those and be responsive to your layouts work as have time and hopefully swing back into it next week
<zyga-ubuntu> jdstrand: sure
<zyga-ubuntu> jdstrand: I think we are close, I need one review on https://github.com/snapcore/snapd/pull/4315 -- I plan to remove the panic but other than that I'd like your eyes whenver you can
<mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga-ubuntu> jdstrand: I'll focus on bugfixes and finishing this this week
<jdstrand> zyga-ubuntu: cool. 4315 is already on the list for background this and planned focus next week
<zyga-ubuntu> jdstrand: thank you! good hunting :)
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: do you have a moment?
<mup> PR snapd#4324 closed: cmd/snap-confine: discard stale mount namespaces <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4324>
<mvo> zyga-ubuntu: sure
<zyga-ubuntu> mvo: hey, let's talk in the standup
<mvo> cachio: 5min late> no problme
<mvo> zyga-ubuntu: ok
<mup> PR snapcraft#1786 opened: lxd: always install squashfuse <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1786>
<mup> PR snapd#4078 closed: tests: new test to check interfaces after reboot the system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4078>
<mup> PR snapcraft#1787 opened: tests: move refresh to unit folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1787>
<mborzecki> mvo: https://travis-ci.org/snapcore/snapd/builds/311190657?utm_source=github_status&utm_medium=notification this is a build related to arch CI that timed out
<kalikiana> sergiusens: Hey! I'd like to highlight snapcraft#1787 - the refresh test isn't currently run at all and at least one PR erroneously passed because of it, although master seems fine
<mup> PR snapcraft#1787: tests: move refresh to unit folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1787>
<kalikiana> Also elopio, when you get online, you may want to have a look. I'm wondering how this happened, and if maybe we can have some checks to catch "lost" test cases ^^
<om26er> elopio: Hello, are you back from your holidays ?
<mvo> mborzecki: thank you!
 * pstolowski heading to the dentist, bb in ~1,5h
<pedronis> mvo: btw in 2.30 on edge there's no nice transition with tasks from configure-snapd to back to configure, afaict the refresh/task stays stuck
<mup> PR snapd#4347 closed: tests: increase warn-timeout to 15m <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4347>
<mup> PR snapd#4348 closed: tests: increase workers for ubuntu-{14,16}.04-64 by one <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4348>
<cachio> niemeyer, sorry, I lost internet connection
<niemeyer> cachio: It's okay, we're done.. if issue is entroy we agreed to create /dev/random with the same device as /dev/urandom
<niemeyer> cachio: We really don't care about having proper entropy for tests
<cachio> niemeyer, sure
<niemeyer> cachio: This should solve the issue for all cases
<cachio> niemeyer, perfect
<cachio> niemeyer, is it going to be part of that PR?
<kalikiana> sergiusens: when you have some time, can you have a look at snapcraft#1746 ? to see what's the right way of dealing with the mypy error
<mup> PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
<sergiusens> kalikiana ok, but have you noticed you have an assigned milestone task https://github.com/snapcore/snapcraft/milestone/12 ?
<mup> PR snapcraft#1785 closed: Add type hinting to file_utils.py <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1785>
<zyga-ubuntu> I'll get something to eat
<kalikiana> sergiusens: Yeah, I'm just going through the queue atm
<sergiusens> kalikiana well that issue is due for tomorrow, so I suggest you give it priority
<sergiusens> kyrofa this is something for you https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/snapcraft/20171204_024823_8b570@/log.gz (blocking 2.35 from entering xenial)
<kalikiana> Aye
<cachio> zyga-ubuntu, when you have some time could you take a look to #4218
<mup> PR #4218: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4218>
<elopio> Good morning!
<zyga-ubuntu> cachio: sure
<popey> sergiusens: do you think you or your team might come up with a simple dotnet app I can use for docs?
<popey> morning elopio
<sergiusens> popey I can, I have been playing with it
<popey> ooh
<popey> I tried building something I randomly found - openra, and it all fall apart looking for some .net components
<popey> so looking for a simpler example
<sergiusens> elopio also note you have tasks due tomorrow https://github.com/snapcore/snapcraft/milestone/12 ... ideally merged today to catch issues for tomorrow
<elopio> On it...
<sergiusens> popey I have a simple forum parser; before New York I had been automating our reports
<sergiusens> I can polish that up a bit and share
<sergiusens> or write something similar to wethr
 * sergiusens commutes back home
<popey> sergiusens: something small and simple would be fine
<mvo> mborzecki: I added some more code for the log analyzing and ran it through your timed out PR: http://paste.ubuntu.com/26112553/ - so it looks like we were short on machines when this PR ran and core had just 2 instead of 4 workers allocated (cc niemeyer). lets keep an eye on PRs that time out and see if we find a pattern
<mborzecki> mvo: thanks for investigating this
<mvo> cachio, zyga-ubuntu, pedronis if you ran accross prs that time out, please let me know, I want to get to the bottom of those :)
<mvo> mborzecki: sure, its a bit annoying so we need to fix it
<niemeyer> mvo: We'll indeed need to increase a bit the number of machines to accommodate the extra distributions being tested
<cachio> mvo, https://travis-ci.org/snapcore/snapd/builds/311266636?utm_source=github_status&utm_medium=notification
<mvo> thanks cachio
<mvo> niemeyer: thanks
<cachio> mvo, this is being caused by Cannot allocate linode:debian-9-64: no powered off servers in Linode account exceed halt-timeout
<niemeyer> mvo: Getting to the bottom of it sounds quite correct here :P
<mvo> niemeyer: lol
<cachio> mvo, I think most of the issues that we see is because lack of linode servers
<cachio> mvo, we are in the limit
<niemeyer> cachio, mborzecki: either way works for me.. either mborzecki tries to fix his PR, and then we generalize it.. or mborzecki already generalizes upfront.. whatever sounds easier
<mvo> cachio: yeah, looks like your PR was particularly "bad": http://paste.ubuntu.com/26112570/
<cachio> mvo, do you have other travis logs to take a look?
<mvo> cachio: I was looking at the one from mborzecki for arch but that was about it
<mborzecki> hmm set up a bot, monitor travis results for jobs started on snapd repo, send email to mvo's inbox :)
<mvo> cachio: I wrote two scripts, one looks for allocation times (which are around 1min-2min) for spread machines, except when it can't find any
<mvo> cachio: and the other that looks at the individual tests to see how long those take, to see if we waste time somewhere
<mvo> mborzecki: heh :)
<cachio> mvo, I saw many problems to allocate linode servers the last weeks
<mvo> cachio: but it looks like the alloc script is silly, spread already tells us when it cannot allocate things, I was wondering if sometimes linode is slow providing machines but that seems to be not the case
<mvo> cachio: yeah, exactly
<mup> PR snapd#4218 closed: tests: adding tests for time*-control interfaces <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4218>
<mpt> sergiusens, done
<sergiusens> mpt thanks!
<mup> PR snapd#4352 opened: tests: increase amount of workers for ubuntu-16.04-64 by one <Created by mvo5> <https://github.com/snapcore/snapd/pull/4352>
<pedronis> mvo: did you see my question about 2.30 ?
<kyrofa> sergiusens, yikes, this is xenial armhf? That means packages have different contents on different archs, that's sad
<kyrofa> Although usr/share/doc/python-minimal/changelog.Debian.gz really shouldn't conflict unless a new version was released
<kyrofa> That seems odd
<kyrofa> sergiusens, that failure is consistent?
<sergiusens> kyrofa you can check all the runs here: http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/armhf
<sergiusens> kyrofa look for triggers "snapcraft/2.35"
<sergiusens> kyrofa would appreciate a follow up on snapcraft#1781
<mup> PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<mvo> pedronis: sorry, I have not seen your question
<mvo> pedronis: here?
<pedronis> mvo: yes,   what should we do/tell people that had 2.30 edge with configure-snapd,  our change/fix doesn't unstuck them afaict (I'm in that situation)
<mvo> pedronis: snap abort chg-id should get them out of misery
<mvo> pedronis: if too many people are affected we may need to do something automatically
<pedronis> mvo: it doesn't  ,  the next try will still make a change with configure-snapd
<pedronis> and then we don't understand it anymore, so we get stuck again
<mvo> pedronis: hm, ok. thats annoying, so we need a dummy configure-snapd task for edge/2.30 ?
<pedronis> I fear so, dummy or does the same as configure
<mvo> pedronis: ok, I start a PR, thanks for the heads up
<pedronis> given that it affected onyl edge for a little bit
<pedronis> we can probably drop it after a while
<mvo> +1
<pedronis> or we wait to have epochs and do it with the big cleanup those should allow us
<mvo> pedronis: yeah, do you have a recommendation for a place to put it? I would say configstate but that has no runner anymore :)
<pstolowski> can we use repair instead?
<pedronis> let me look
<pedronis> mvo: I would put it in snapmgr with  a comment
<pedronis> or hookstate
<mvo> pedronis: yeah, was thinking hookstate too, but no strong opinion
<mup> PR snapcraft#1787 closed: tests: move refresh to unit folder <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1787>
<mvo> pedronis: thanks, I am on it, not sure if I can finish before hockey but I will try :)
<mvo> cachio: looks like CE has finished automatic validation, good to promote to candidate
<cachio> mvo, I just received an email
<cachio> :)
<mvo> cachio: yay
<cachio> mvo, promotin
<cachio> g
<cachio> mvo, promotion done
<mvo> cachio: thank you!
<cachio> niemeyer, I can't use fedora-rawhide-64 image
<niemeyer> Hm?
<cachio> niemeyer, I am getting "cannot connect: cannot connect to linode:fedora-rawhide-64 (Spread-72): dial tcp 74.207.250.224:22: i/o timeout
<cachio> "
<niemeyer> cachio: Ok, that probably means the image is boosted somehow
<niemeyer> busted even
<niemeyer> Would be nice for it to be boosted, though
<niemeyer> cachio: I don't have any better clues on my end
<cachio> I am using kernel: GRUB 2
<cachio> niemeyer, could be that affecting?
<niemeyer> cachio: If you didn't set up grub and a kernel on the image, definitely
<cachio> niemeyer, I already set up grub2 in that image
<cachio> and the kernel
<niemeyer> cachio: Sorry, I really have absolutely no clue.. I've never looked into that image at all
<cachio> niemeyer, in that case I'll try with the linode kernel to see if the grub setup has a problem
<niemeyer> Thanks
<mup> PR snapd#4353 opened: hookstate: add compat "configure-snapd" task <Created by mvo5> <https://github.com/snapcore/snapd/pull/4353>
<cachio> niemeyer, could you please create fedora-rawhide-64 image based on spread-32?
<cachio> niemeyer, I updated the kernel and installed the las rc
<niemeyer> cachio: Creating image
<cachio> niemeyer, tx
<niemeyer> cachio: Wait
<niemeyer> cachio: Damn
<niemeyer> cachio: I'm sorry, I've made a mistake.. forgot to take it out of the pool and was overrun by spread itself :(
<cachio> niemeyer, :), np
<cachio> niemeyer, I'll do t again
<niemeyer> cachio: Sorry
<cachio> no problem
<mup> PR snapcraft#1788 opened: repo: error for packages with broken dependencies <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1788>
<sergiusens> kyrofa https://www.amazon.com/photos/share/7kcMwZif1Ap8HlPrWRwH7vaUz3mubXEwbzBVlmCxWyD
<kyrofa> sergiusens, oh crap
<kyrofa> What is that nested list?
<sergiusens> kyrofa you were there!
<kyrofa> sergiusens, are you saying you remember? ;)
<sergiusens> kyrofa yes
<kyrofa> Then why didn't you correct the proposal I made without the picture to reference?
<sergiusens> kyrofa elopio ad-hoc meeting, now-ish(?)
<sergiusens> kyrofa which one where?
<kyrofa> In the breakdown doc
<kyrofa> I'm good with a meeting
<sergiusens> kyrofa oh, during the meeting I said it was incomplete, don't you recall?
<sergiusens> tbh, I don't like what was decided but you guys were totally onboard with it during the rally
<kyrofa> No, I don't recall. I recall you agreeing and then you used my time estimate for the Project, so...
<kyrofa> Regardless, let's chat about what this is
<sergiusens> kyrofa oh, the estimate is fine
<sergiusens> sure
<kyrofa> No it's not, I already spent a day on a format that doesn't support that picture
<cachio> niemeyer, spread-14
<cachio> fedora-rawhide-64
<cjwatson> Hmm.  I originally installed a snap (which I'm helping to develop) from the store.  Then I installed a local version with --dangerous to try to debug something.  Now I'd quite like to get back to the store version without losing the existing data.  Is there any way to do that?  "snap refresh --edge" won't let me
<niemeyer> cachio: On it
<cjwatson> ('error: snap "foo" is local')
<cachio> niemeyer, tx
<elopio> om26er: hello. I'm back
<niemeyer> cjwatson: Does "install" work? We've discussed this a few times, and I remember we agreed we'd like to fix that, but I don't recall where we stand to be honest
<cjwatson> niemeyer: It doesn't, and tells me to use refresh - but ah, I just found https://forum.snapcraft.io/t/cannot-refresh-from-store-over-local-install/2542
<cjwatson> (which is further amusing because "snap download" doesn't support private snaps, I think, but I can work around that)
<niemeyer> cjwatson: Ah, it's the opposite.. install allows the going out of store step
<elopio> sergiusens: meeting where?
<cjwatson> Yeah - it let me go out of store but didn't tell me that it would be hard to go back.  I probably should've known :)
<sergiusens> kyrofa elopio our weekly hngout
<kyrofa> Alright, on my way
<elopio> omw
<cachio> niemeyer, I'll be afk, I'll try the new image once I am back
<niemeyer> cjwatson: I think we should allow the transition towards the store more smoothly.. we may need that flag as we're going from something completely unsigned and unknown to something from the store, but other than than don't see many issues
<niemeyer> cachio: Image is back at 2GB
<cjwatson> niemeyer: OK, and yeah, I don't either - mind if I quote you on that forum thread?
<niemeyer> cjwatson: Let me write something there
<cjwatson> Cheers, appreciate it
<cachio> niemeyer, could yoy plarse start the machine, I'll take a look
<niemeyer> cachio: Coming up.. still out of the pool
<niemeyer> cjwatson: np
<cachio> niemeyer, tx
<elopio> sergiusens: waiting for you
<m4sk1n_> can anyone help me with making snapcraft i18n-able?
<niemeyer> cjwatson: Please have a look
<niemeyer> m4sk1n_: Many of us can, but this is really a topic better held in the forum
<niemeyer> m4sk1n_: as there are many angles to it, and feature design involved
<m4sk1n_> niemeyer: ok, I have problems with applying .mo files, I don't know how to use gettext with python in this case
<m4sk1n_> I guess that python-related channel is better place for this, but I thought that people here would like to help me in this case
<cjwatson> niemeyer: yep, LGTM, thanks - replied
<mup> PR snapcraft#1782 closed: project_loader: support grammar on architectures <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1782>
<jjohansen> ikey: the plan is to move the backport kernels to gitlab, but I just haven't had time to do the work yet
<jjohansen> I am planning on doing some backport kernel work this week, so hopefully it will happen
<jjohansen> submissions to upstream will still go through the kernel.org tree, but I will be relying on kernel.ubuntu.com a lot less
<jjohansen> it will be for only ubuntu specific patches, and hopefully that diff will disappear soon
<sergiusens> m4sk1n_ is there a task to add translations to snapcraft itself?
<sergiusens> elopio ? ^
<m4sk1n_> no
<m4sk1n_> in fact I completed task to fix snapcraft bug
<elopio> sergiusens: adding translations to the snapcraft cli? That's a huge task.
<mup> PR snapcraft#1776 closed: ci: name the travis jobs <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1776>
<m4sk1n_> I don't know how to make it use .mo files
<m4sk1n_> I have snapcraft repo in ~/snapcraft/
<m4sk1n_> here I have po/ folder with .pot template, pl.po and pl.mo (incomplete, for testing purposes)
<m4sk1n_> all strings are marked as translatable (these which should be translatable) and I generated .pot without any issues
<jdstrand> popey: hey, fyi, 3 more revisions of vlc came in with the same desktop file issue
<mup> PR snapcraft#1789 opened: cli: improve the help command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789>
<sergiusens> kyrofa elopio ^
<cachio> niemeyer, spread-14 ready again
<cachio> niemeyer, I was uninstalling more stuff to reduce the size
<sergiusens> elopio kyrofa the rpath one is updated, please review
<om26er> elopio: who shall I ping to promote snapcraft 2.35 from xenial-proposed to -updates ?
<om26er> ...or do we have a SRU bug for it ?
<om26er> at least 2 Apps that I snapped depend on a fix in snapcraft 2.35. AndroidStudio and SublimeText.
<om26er> popey: is there a way you can grant me permissions to close issues on https://github.com/snapcrafters/android-studio (Not asking for write access to repository).
<mup> PR snapcraft#1790 opened: cli: include consistent commands to fix error conditions <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1790>
<elopio> sergiusens: before leaving, I +1'ed the SRU. Is there something else you want to verify there, or should I update the tags to get it released?
<om26er> please do it ;-)
<kyrofa> elopio, om26er we have that arm test failing that I'm investigating right now
<kyrofa> Building a ROS snap on an rpi is not blazingly fast I'm afraid
<elopio> om26er: for the record, this is the bug: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1729417
<mup> Bug #1729417:  [SRU] New stable micro release 2.35 <verification-done-xenial> <verification-done-zesty> <verification-needed> <verification-needed-artful> <snapcraft (Ubuntu):Fix Committed> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Zesty):Fix Committed> <snapcraft (Ubuntu
<mup> Artful):Fix Committed> <snapcraft (Ubuntu Bionic):Fix Committed> <https://launchpad.net/bugs/1729417>
<elopio> sergiusens: kyrofa: okay, my 4 PRs ready for review/landing. I'm going for lunch now and get back to review rpath.
<om26er> elopio: thanks, due to some reason I was looking for the SRU bug on github.
<kyrofa> noise][, nessita the dashboard is giving me a 504
<noise][> kyrofa: looks ok for me - any particular page?
<kyrofa> noise][, just https://dashboard.snapcraft.io/dev/snaps/ . Came up now though
<kyrofa> Just seemed to be weird for about two minutes or so
<kyrofa> Oh for heaven's sake. The core snap just updated and rebooted the pi while it was running my test
<om26er> don't give up, we are counting on you :P
<mup> PR snapcraft#1758 closed: tests: move the ppa test trigger to lxd <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1758>
<kyrofa> Haha, it's going, just had to start over
<niemeyer> cachio: Image baked
<kyrofa> sergiusens, elopio I'm afraid I can't duplicate these results on my rpi2: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/snapcraft/20171204_024823_8b570@/log.gz everything works fine
<kyrofa> The changelog has the same md5, etc.
 * kyrofa goes to shoot some footage, back soon
<sergiusens> kyrofa ok, going to retrigger then
<sergiusens> elopio kyrofa but don't forget to review! I would like to fix and have you guys ack the fixes before EOD so we have a smooth release day tomorrow
<diddledan> RELEASE DAY TOMORROW?! \o/ YEY \o/
<diddledan> what we unleashing, the dogs of war?
<diddledan> cry havoc and let slip the dogs of war!
<lundmar> I'm looking for a +1 on this https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 :)
<cachio> niemeyer, thanks
<cachio> niemeyer, fedora-rawhide-64 not working with grub in linode
<cachio> niemeyer, not sure why
<cachio> if yuou could take a look to the console perhaps there is more info
#snappy 2017-12-05
<sergiusens> diddledan every Tuesday, the snap; every 3 weeks the deb
<diddledan> :-p
<kyrofa> Ugh, man it gets dark early
<kyrofa> Canonical needs to buy me a few soft boxes
<bdx> hey, whats up all
<bdx> beating this nginx logging horse to death here
<bdx> I had great success with getting my logs to syslog via the snap logging proxy
<bdx> not sure the technical name for that mechanism
<bdx> a req came down the line that this application log to a separate file(s) and the logs end up in s3
<bdx> so I had to log to $SNAP_COMMON
<bdx> which works great until I try to setup logrotate
<bdx> I hit my head on a few things, but ended up getting logrotate in this working/broken state
<bdx> in short, the issue I seem to be having is that when logrotate goes to swap out the logfile, nginx needs a kick (reload) to start writing to the new logfile
<bdx> which brings me to the (logrotate) postrotate sripts
<bdx> which can be used to send signal or run a bin when your gets rotated and swapped out
<bdx> so my idea here was to create a wrapper command in my snap to facilitate running the `nginx -s reload` command
<bdx> here's whats in my wrapper http://paste.ubuntu.com/26115750/
<bdx> the output I'm getting ^
<bdx> seems like the snap is preventing the process from being restarted
<bdx> nginx: [alert] kill(17878, 1) failed (1: Operation not permitted)
<bdx> I should probably write another forum post pertaining to this
<bdx> possibly my last one on logging wasn't specific enough
<bdx> is this making sense?
<bdx> do I need to add more context somehow in a more proper write up?
<bdx> let me know
<bdx> thx thx
<sergiusens> elopio would be great if you could run through snapcraft#1789 and also maybe try and apply your changes, I don't see how they look good when running
<mup> PR snapcraft#1789: cli: improve the help command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789>
<mup> PR snapcraft#1791 opened: tests: move the python plugin integration tests to a separate suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1791>
<mborzecki> morning
<mup> PR snapcraft#1792 opened: tests: do not hit the network in python unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1792>
<m4sk1n_> https://github.com/m4sk1n/snapcraft/tree/i18n-wip I don't know how should I config ./bin/snapcraft to apply translationsâ¦
<mborzecki> mvo: hey
<mvo> hey mborzecki - good monring
<mvo> morning even
<mborzecki> :)
<mborzecki> mvo: got a quick question, https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification any idea why this has failed?
<mvo> mborzecki: yes, I looked at it earlier and restarted because iirc it could not allocate machines, it looked very transient, I don't have the log in front of me unfortunately anymore
<mborzecki> i'll restart the build then
<mborzecki> traving is also having hiccups today, couldn't restart the build
<mvo> mborzecki: it is restarted already, at least when I looked at it ~1min ago :)
<mborzecki> i clicked 3-4 times, got 'Oh no! .. blah blah'
<mborzecki> mvo: that arch test that fails, got this from sysctl: kernel.random.entropy_avail = 32, not a good sign
<mvo> mborzecki: heh, yeah
<mborzecki> i kind of lik the idead that was circled yesterday, just mknod /dev/random c 1 9 and we're done for the tests at least
<mvo> mborzecki: yeah, I think we should just do it, for clarity I would use a symlink (if gpg is happy with that)
<mvo> mborzecki: will you do a PR with that? or shall I do one :) ?
<mborzecki> oh and `dd=/dev/random of=/dev/null` chokes obvioulsy on that machine
<mborzecki> i can do it
<mvo> if anyone has a fedora system at hand, what is the package that contains aa-enforce in fedora?
<mvo> and apparmor_parser ?
<mborzecki> mvo: there's no aa in fedora
<mup> PR snapd#4354 opened: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
<mborzecki> mvo: ^^
<zyga-ubu1tu> hey hey
<mborzecki> zyga-ubu1tu: hey
<zyga-ubu1tu> sorry for being absent-ish yesterday, I'll try to make up for that
<mborzecki> zyga-ubu1tu: need a 2nd review on #4338 if you would be so kind :)
<mup> PR #4338: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4338>
<zyga-ubu1tu> mborzecki: yep, looking
<mborzecki> zyga-ubu1tu: thanks
<mup> PR snapd#4338 closed: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4338>
<mborzecki> mvo: this build timed out https://travis-ci.org/snapcore/snapd/builds/311243551?utm_source=github_status&utm_medium=notification
<mborzecki> zyga-ubu1tu: while you're doing reviews, would you mind taking a look at #4340 as well?
<mup> PR #4340: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340>
<pstolowski> zyga-ubu1tu, hey! can you take another look at #4303 (addressed your previous feedback, and got +1 from Gustavo)
<mup> PR #4303: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4303>
<zyga-ubu1tu> pstolowski: sure, looking now
<pstolowski> zyga-ubu1tu, thanks!
<zyga-ubu1tu> pstolowski: that's a biggie :)
<pstolowski> zyga-ubu1tu, look at the followup... it's fairly mechanical though
<zyga-ubu1tu> brb, reboot
<apw> i have two differnt python based snaps which are not working if they are rebuilt in a bionic userspace; both exploding when installed and run with:
<apw> /snap/so-trello/x1/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /snap/so-trello/x1/usr/bin/python3)
<zyga-ubuntu> apw: hey
<zyga-ubuntu> apw: yo uneed to build them on xenial userspace
<zyga-ubuntu> apw: I believe kalikiana is aware of the issue
<zyga-ubuntu> mvo: crazy idea: include newer libc in core/
<zyga-ubuntu> ^
<apw> huh, since when did that change
<apw> i thought the point was that core contained everything you might need
<zyga-ubuntu> apw: bionic uses newer libc, core ships older libc
<apw> and if it didn't your snap got all fat
<zyga-ubuntu> apw: yes, but it doesn't contain your latest libc
<apw> right, so it should be using the one in the core snap
<zyga-ubuntu> apw: if by "it" you mean snapcraft then yes
<zyga-ubuntu> apw: but this is hard to do, use cleanbuild to build in a container
<apw> zyga-ubuntu, i'll try that then, though it should do that by defualt probabally ...
<ikey> hey zyga-ubuntu wanna see somethin' cool? :)
<ikey> ("cool" being at your own interpretation obv.)
<zyga-ubuntu> ikey: sure :)
<ikey> https://ibin.co/3jcgpSR7n4Tu.png
 * zyga-ubuntu was making kitchen tidy enough to make tea
<ikey> :D
<zyga-ubuntu> oooh
<zyga-ubuntu> snap store
<zyga-ubuntu> thank you :)
<zyga-ubuntu> is that released? can I play?
<ikey> its not yet :P
<ikey> this is as far as i got yesterday
<ikey> today i shall add more stuff
<zyga-ubuntu> ikey: how is the integration, any pain points? anything missing
<mvo> zyga-ubuntu: why a newer libc?
<ikey> zyga-ubuntu, same as before
<ikey> no caching of offline usable metadata, meaning many, many roundtrips
<zyga-ubuntu> mvo: because it would be compatible with existing software and it would let people use bionic and artful libs with greater ease
<ikey> no cached indexes or proper categories
<ikey> no integration with appstream so having to support two visual standards
<zyga-ubuntu> ikey: the api is that you talk to snapd and then snapd talks to the store, right?
<ikey> right
<ikey> and the list installed stuff is wonky
<zyga-ubuntu> ikey: I thought we started to do appstream now
<ikey> as it only has like half the meta
<ikey> so even for an installed snap you need to go to the store to get the real data on it
<ikey> (which seems an odd choice)
<zyga-ubuntu> yes, that's true
<zyga-ubuntu> Chipaca: ^
<ikey> for now im just gonna have to supplement the hand-picked snaps with some extra meta-data
<ikey> due to aforementioned lack of organisation/appstream
<zyga-ubuntu> ikey: hmmm
<zyga-ubuntu> ikey: you should talk about this with chipaca, robert ancell and store people
<ikey> this is nothing new btw, same issues as back in september
<zyga-ubuntu> aha, I see
<Chipaca> zyga-ubuntu: i'm aware
<zyga-ubuntu> great
<zyga-ubuntu> as long as we all know it will get fixed over time
<ikey> the other issue is snapd startup time
<ikey> its.. painful
<Chipaca> my plate is full of things -- and in particular spread misbehaving in weird ways
<ikey> on Solus snapd is socket activated to prevent massive boot time regressions
<ikey> unfortunately it also means slowing down the startup of the SC the first time it runs
<ikey> until snapd is "ready"
<ikey> the same thing can be emulated just issuing "snap list" after boot
<zyga-ubuntu> ikey: right
<ikey> takes around 5+ seconds
<zyga-ubuntu> ikey: thank you for the honest feedback!
<ikey> no worries :]
<Chipaca> ikey: ouch. We moved away from socket activating it -- why not start it automatically now?
<zyga-ubuntu> ikey: does systemd have an "idle" schedule to run stuff when everything has settled?
<Chipaca> i mean, don't make things block on it
 * apw now finds snapcraft cleanbuild fails with no root device found from lxc
<Chipaca> yes, systemd does have that
<ikey> because we actually care about stuff like this Chipaca
<ikey> https://www.phoronix.com/scan.php?page=article&item=11-linux-boot&num=1
<ikey> spoiler: we came in just after clear linux (where I used to work)
<ikey> snapd presents a huge boot time regression
<Chipaca> ikey: what happpens if you set snapd's type to 'idle'?
<ikey> honestly, not tried
<ikey> but it has no need to be switched on during boot anyway
<ikey> it should only be turned on when spoken to
<Chipaca> ikey: if it's socket activated, refreshes might never happen, and retries might never happen
<Chipaca> ikey: unless you've set things up for that
<ikey> well. tbh i dont think automatic refreshes should be mandatory anyway
<ikey> so theres another design decision im not in agreement with
<ikey> for our users they risk excessive bandwidth consumption as they have no direct control over updates
<Chipaca> ikey: have you been paying no attention to the quagmire of awfulness that is security in the face of no automatic updates?
<ikey> i think you forget who you're talking to, Chipaca.
<ikey> if you don't give users a way to at least delay an update until an appropriate time, you're pulling a Windows
<mvo> ikey: 5+ seconds :/ I wonder why, that is really slow. I think we (snapd team) need to dig into this
<ikey> many people are still reliant on HSDPA+/3G
<ikey> and have bandwidth limitations
<ikey> being able to defer the update until it is *affordable* is a must for the most basic UX requirements
<Chipaca> ikey: i'm on a short fuse for personal reasons this week, please read things as if i were being 2 points more polite
<ikey> throwing "security" as a blanket for piss-poor engineering in IoT isn't going to cut it
<ikey> fair do.
<zyga-ubuntu> as an argument here
<zyga-ubuntu> I think the core should update automatically
<zyga-ubuntu> services should update if started
<zyga-ubuntu> and apps should be blocked from running (by default) when out-of-date
<mup> PR snapd#4353 closed: hookstate: add compat "configure-snapd" task <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4353>
<ikey> zyga-ubuntu, so you're gonna pull a PS4? :)
<zyga-ubuntu> (especially desktop apps can have nicer notification)
 * mvo hugs Chipaca 
<Chipaca> ikey: you can already set updates to happen at whatever time bandwidth is cheap
<ikey> "Time" ?
<zyga-ubuntu> ikey: well, it's a gradient; I don't care if my apps are as up-to-date as my system
<zyga-ubuntu> ikey: if I know and can act on it
<ikey> Launch-blocking is one approach
<zyga-ubuntu> ikey: there are ways this can change over time
<ikey> And allows having deferred updates
<ikey> Mandatory core updates, again I would disagree with, depending on context
<ikey> If a user has LSI installed they don't need core
<zyga-ubuntu> ikey: for snapd
<ikey> Unless they're on Ubuntu with snapd reexec
<ikey> Anywhere else, core is unnecessary
<Chipaca> mvo: the police asked for a summary of all the bullying since it started, and writing all that out has been rough
<ikey> zyga-ubuntu, is there any other instance core is used by snapd outside of the reexec case?
<mvo> Chipaca: *meh* I can imagine :( sorry to hear that
<Chipaca> reminds me i need to take thursday off to go look at a new school
<zyga-ubuntu> ikey: I think core will shrink to "just snapd" over tiem
<ikey> gotcha
<zyga-ubuntu> ikey: as bases mature and there is a distinct 16 and 18 ubuntu base
<ikey> basically, current ux:
<ikey> sudo snap install --edge solus-runtime-gaming
<ikey> installs core
<ikey> then installs the runtime
<zyga-ubuntu> Chipaca: man, that sucks. I hope it can get resolved quickly
<mvo> zyga-ubuntu: do you happen to known in what fedora package "apparmor_parser" and "aa-enforce" are? same question for opensuse
<ikey> runtime gets updates, linux-steam-integration does not
<zyga-ubuntu> mvo: none
<ikey> neither can be found in searches
<zyga-ubuntu> mvo: it's not packaged
<zyga-ubuntu> mvo: for suse it is just "apparmor" (in tumblweed, I believe)
<ikey> in solus we give users choice over which updates are applied and when
<mvo> zyga-ubuntu: ta
<ikey> because, believe it or not, not ALL updates are security.
<Chipaca> mvo: am i wrong in thinking 2.29 should be getting default-provider snaps automatically?
<ikey> in Solus we differentiate updates at 3 levels: Mandatory, Security, Other
<zyga-ubuntu> ikey: I think most users don't care; I would focus on making it less annoying and getting bandwidth under control
<ikey> With all due respect, they do.
<ikey> Solus users care about it a lot
<ikey> Having things update beyond their control is frustrating and a kickback to the Windows world they left
<ikey> And if you decide to block the launch of an app because of an update, you will have outrage unless there is a good *reason* to block it
<ikey> Blocking the launch because someone decided to reshade the theme? Gonna get people vexed
<ikey> Stop their laptop shutting down before a meeting because of updates? or kill their bandwidth before heading out to NZ on tethered phone for a week? Gonna piss em off :P
<zyga-ubuntu> ikey: yeah, there are things to polish in the experience
<Chipaca> ikey: ok, so how do you programatically tell a good reason from a bad one?
<zyga-ubuntu> ikey: perhaps blocking on startup is excessive (for vast majority of updates)
<zyga-ubuntu> Chipaca: they have the evil bit set
<zyga-ubuntu> oh man
<Chipaca> of _course_ users want their shit to just work
<ikey> Chipaca, by describing an update
<zyga-ubuntu> not set :)
<Chipaca> :-(
<ikey> so in solus we auto-describe security updates through reference to some CVE or other
<ikey> and its flagged as zyga-ubuntu says
<ikey> so thats security, sorta more important than "user is finicky about updates"
<ikey> mandatory in snapd terms is core
<ikey> i.e. required for architecture to work
<ikey> (in solus thats actually libc, bash, etc)
 * Chipaca goes back to hating spread because he's unfit for human interaction right now
<ikey> so you have this core set of things that will always update regardless of any other update/install/refresh, because "mandatory" ^^
<apw> zyga-ubuntu, ok this cleanbuild option is using an lxc command line which doens't work ... i needs a --storage option
<ikey> compromises++
<zyga-ubuntu> apw: ask kalikiana about that please
<apw> kalikiana, ^
<Chipaca> apw: you want to talk with kalikiana
<Chipaca> heh
<apw> talk isn't the word i want to use right now :/
<mvo> Chipaca: hi, sorry, laptop went crazy
<mvo> Chipaca: so default providers, the PR is not merged yet, some complications in it
<Chipaca> aw
<mwhudson> apw: i don't quite know what you are doing but
<apw> mwhudson, trying to make snap work again, as apparently that is impossible, i will just stop trying i think
<mwhudson> apw: if you create a lxd container called "snapcraft-$project", you can use SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft build and it will use the container you created
<apw> mwhudson, project as in the snap name ?
<mvo> Chipaca: https://github.com/snapcore/snapd/pull/4103
<mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<mwhudson> apw: yes
<mwhudson> apw: it's a slimy hack, but it does work
<apw> mwhudson, i'd try random hack three then,. thanks
<Chipaca> mvo: yikes
<Chipaca> apw: nice attitude there
<apw> Chipaca, heh its never a good start to your day when your snaps won't work and you can't rebuild them anymore
<zyga-ubuntu> sorry about the distraction, my son hasn't arrived for classes, trying to sort this out
<Chipaca> apw: I'm surprised you've not had to switch to cleanbuild ages ago; the libc change is a couple of months old already
<apw> Chipaca, well apparently i can't switch to cleanbuild cause that don't work either :/
<Chipaca> apw: it does for other people, so why doesn't it for you?
<ikey> hm, zyga-ubuntu, thought, what if we went in completely the opposite direction..?
<Chipaca> apw: it's not a random hack; if it's not working it's a bug
<ikey> instead of trying to jimmy snaps to fit distro "ways", instead use the software center to *educate* users about snaps..
<apw> Chipaca, it isn't supplying a required option to lxc on my system to start the container
<apw> Chipaca, and i was refering to mwhudson's description of the next thing to try as a slimy hack
<zyga-ubuntu> ikey: hmm? sorry can you please re-state your question
<apw> Chipaca, not my choice of epithet for the thing i was trying
<ikey> zyga-ubuntu, ok so instead of trying to force snaps to fit the old fashioned method of distro updates, instead educate users about snaps being self-updating
<ikey> and why they differ
<ikey> before they ever go to install one
<ikey> i.e. promote the difference instead of trying to stifle it
<jamesh> mvo: hi.  In https://github.com/snapcore/snapd/pull/4140#issuecomment-347159305 you said you uploaded the test snap to the store.  I was looking at writing a spread test using it, but can't seem to see it there.  Is there anything more needed?
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<Chipaca> apw: ah i missed him saying that -- sorry for calling you on it then
<apw> Chipaca, heh i don't mind, i _am_ feeling grumpy about it all today :)
<Chipaca> apw: my main concern is that calling them hacks doesn't put the focus on getting things fixed, whereas calling them bugs does
<mwhudson> Chipaca: fwiw my use case for my hack is fixed by https://github.com/snapcore/snapcraft/pull/1769
<mup> PR snapcraft#1769: lxd: add an --image argument to cleanbuild <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1769>
<mwhudson> although having control over the container that gets created when you use SNAPCRAFT_CONTAINER_BUILDS would also be good
<apw> mwhudson, and only installing it once with build-deps etc sounds good
 * mwhudson grumbles at pylint
<mwhudson> apw: yeah
<zyga-ubuntu> eh
<zyga-ubuntu> mystery resolved
<zyga-ubuntu> my son turned off his phone in school
<zyga-ubuntu> went inside the class and waited for the teacher
<zyga-ubuntu> the teacher waited outside of the class and tried to call him and then me
<zyga-ubuntu> ^_^
<zyga-ubuntu> stress--
<zyga-ubuntu> back to work
<zyga-ubuntu> pstolowski: branch looks good so far, I'll try to finish it quickly
<zyga-ubuntu> pstolowski: sorry for the lag
 * ikey passes metaphorical handkerchief to zyga-ubuntu 
<pstolowski> zyga-ubuntu, np, thanks for looking at this monster
<Chipaca> pstolowski: hey
<Chipaca> pstolowski: what's the status of snapctl restart et al?
<apw> mwhudson, that fails with: PermissionError: [Errno 13] Permission denied: 'snap/.snapcraft'
<mwhudson> apw: congrats
<mwhudson> ?
<mwhudson> sorry that's probably not very helpful but i've not seen anything like that before
<apw> i think i have to accept that snapcraft and bionic is just not a thing
<apw> and create a VM to do this in
<pstolowski> ?
<pstolowski> ups, ignore me
<Chipaca> pstolowski: did you see my question about snapctl service control?
<pstolowski> Chipaca, yes, will reply
<Chipaca> k
<Chipaca> pstolowski: i ask because of the forum thing, you can reply there if you'd rather
<pstolowski> Chipaca, yes, will reply there, I didn't respond right away cause I'm not sure if it made it in 2.30 or not at the end, need to check
<pstolowski> Chipaca, replied
<pstolowski> Chipaca, nb, nothing stops anyone from using systemctl + a long hard to remember name directly, right?
<Chipaca> pstolowski: confinement sure does
<pedronis> not inside a snap
<pstolowski> right
<mup> PR snapcraft#1779 closed: catkin-tools plugin: use stage-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1779>
<pedronis> pstolowski: Chipaca: anyway afaik and skimming the code snapctl start/stop etc made it to 2.30
<pstolowski> yes
<ShibaInu> error: cannot refresh "core": snap "core" has changes in progress
<ShibaInu> what does this mean
<zyga-ubuntu> ShibaInu: that "snap changes" will show that some other operation on core snap is already in progress
<ShibaInu> zyga-ubuntu: not sure what is going on though, I seemingly dont have any snap running?
<zyga-ubuntu> ShibaInu: run "snap changes"
<ShibaInu> 27   Do      2017-11-30T10:13:40Z  -      Auto-refresh snap "core"
<zyga-ubuntu> ShibaInu: so the message should be probably beter
<zyga-ubuntu> better*
<zyga-ubuntu> "refreshing of snap core is already in progress"
<zyga-ubuntu> or something alike
<ShibaInu> zyga-ubuntu: do you know by the way whether vulkan now works on snappy?
<zyga-ubuntu> ShibaInu: I don't know, sorry
<ShibaInu> ok, no problem
<ShibaInu> thanks by the way
<pedronis> ShibaInu: are you using core from edge?
<ShibaInu> pedronis: yes
<zyga-ubuntu> ShibaInu: we should have some vulkan test snap but I'm not aware of any
<pedronis> ShibaInu: there was an issue that will get an update in that state,  you need to abort the change ,  snap abort 27,  the next edge build from today then should work
<pedronis> or so we think
<ShibaInu> pedronis: so if i do snap abort 27 i will have to wait for the next edge? or will vulkan work
<pedronis> this is not about vulkan
<pedronis> just the update getting stuck
<ShibaInu> oh
<ShibaInu> i see
<ogra_> i guess you'd have to include mesa-vulkan-drivers and libvulkan1 inside your snap
<ogra_> and allow/connect the opengl interface to give it HW access
<ogra_> (just a guess though)
<cachio> mvo, test on candidate completed, we are ready to go to stable
<mvo> cachio: brilliant news
<mvo> cachio: lets target after the meeting, then we can briefly discuss and we need to warn the store people as well
<cachio> mvo, agree
<mvo> thanks cachio
<zyga-ubuntu> pstolowski: almost done
<pstolowski> \o/
<zyga-ubuntu> pstolowski: oh damn, those "load diff" parts of the PR
<zyga-ubuntu> pstolowski: it's even longer :")
<pstolowski> :}
 * Chipaca -> physio while spread runs
 * zyga-ubuntu misread that as "past"
<zyga-ubuntu> "pasta"
<zyga-ubuntu> uuuuhhh
<zyga-ubuntu> HOW MANY ARE THERE
<zyga-ubuntu> pstolowski: I wanted to say I'm near the end
<zyga-ubuntu> but the end is full of "load more" buttons
<zyga-ubuntu> pstolowski: I'm at lxd_support_test.go
<pstolowski> zyga-ubuntu, sorry...
 * zyga-ubuntu hugs pstolowski who had to _write_ all that
<pstolowski> zyga-ubuntu, https://www.youtube.com/watch?v=jHPOzQzk9Qo
<zyga-ubuntu> pstolowski: when the camera pans and shows more people on crosses this is how scrolling down feel
<zyga-ubuntu> *feels
<zyga-ubuntu> there's more interfaces :D
<pstolowski> yes, that video seems very appropriate ;)
<Laney> hi
<zyga-ubuntu> o/
<Laney> I'm looking for some documentation on seed.yaml
<Laney> can anyone point me in the right direction?
<zyga-ubuntu> mmm maybe pedronis ca
<mup> PR snapd#4355 opened: release: 2.30~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4355>
<cachio> mvo, 30 rc2 ready for beta validation?
<mvo> cachio: yes
<mvo> cachio: should be a piece of cake almost no change
<cachio> mvo, ok, I'll start with it
<mvo> cachio: except arm/arm64, LP is busted right now and can't build those
<mvo> cachio: I'm talking on #launchpad about this right now
<zyga-ubuntu> mvo: uh
<zyga-ubuntu> shutdown_test
<cachio> mvo, ok, np
<mup> PR snapcraft#1793 opened: Refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793>
<mup> PR snapd#4356 opened: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
<zyga-ubuntu> amend?
<jamesh> mvo: did you see my message earlier?  I couldn't find the test-snapd-gnome-online-accounts snap on the store
<mvo> jamesh: I did not, sorry.let me check for this snap
<jamesh> mvo: I was asking in relation to https://github.com/snapcore/snapd/pull/4140#issuecomment-347159305
<mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<jamesh> thanks
<mvo> jamesh: what is your primary SSO account? if you could /msg that to me I will add access for you
<mvo> jamesh: I also just published the snap
<jamesh> mvo: I want to use this snap in a spread test.  So doesn't that require it to be accessible to everyone?
<mvo> jamesh: the snap was just not published before, I published it now
<mup> PR snapcraft#1793 closed: Refactor storeapi <Created by daniellim2000> <Closed by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793>
<mvo> jamesh: so tests should work now
<jamesh> mvo: okay.  Thanks
<mvo> jamesh: I can also give you access to this snap if you need to update it or anything like this
<mvo> jamesh: if not, thats fine too of course
<jamesh> mvo: okay.  What identifier do you need for that?  My email?
<mvo> jamesh: yes, your primary sso email
<jamesh> mvo: okay.  That's james.henstridge@canonical.com
<mvo> jamesh: just mail or /msg it to me and I add you as the snap collaborator
<mvo> jamesh: ta
<mvo> jamesh: the store should have send you mail
<jamesh> got it.  Thanks
<brunosfer> Hi guys, does anyone knows what's the difference between  stage-packages: and  build-packages: on the .yaml identation file to create a snap?
<zyga-ubuntu> yes
<zyga-ubuntu> stage are unpacked into your snap
<zyga-ubuntu> build aren installed on your machine to help
<brunosfer> but how can they be installed on my machine if the whole core is squashfs?
<brunosfer> they're built in the snap sandbox?
<zyga-ubuntu> on your build machine
<brunosfer> got it. thanks for the help :)
<zyga-ubuntu> :)
<mup> PR snapcraft#1793 opened: project: refactor storeapi <Created by daniellim2000> <https://github.com/snapcore/snapcraft/pull/1793>
<niemeyer> o/
<niemeyer> cachio: Do you want to try the image out to see what we get?
<cachio> niemeyer, ok
<brunosfer> Does anyone knows what's wrong here? doing on the shell "hciconfig" I get the hci0 interface, however when I do "bluez.hciconfig" it show's me the error "Can't open HCI socket.: Permission denied"
<brunosfer> In all the above I use sudo
<zyga-ubuntu> is the interfce connected?
<zyga-ubuntu> snap interfaces
<cachio> niemeyer, let's do it after the standup
<brunosfer> zyga-ubuntu: I think today I forgot my brain... Thanks ;)
<zyga-ubuntu> pstolowski: commented
<zyga-ubuntu> brunosfer: :-)
<brunosfer> zyga-ubuntu: I totally forgot to check that.
<zyga-ubuntu> pstolowski: update the SPI interface next time
<zyga-ubuntu> pstolowski: I'm merging it to save others from reviewing :)
<mup> PR snapd#4303 closed: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4303>
<pstolowski> zyga-ubuntu, thanks, will do
<mup> PR snapd#4357 opened: wrappers: autogenearte After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357>
<mborzecki> niemeyer: pushed the fixes to #4313, appreciate if you could take another look
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<niemeyer> mborzecki: Thanks, will do
<mup> PR snapd#4358 opened: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<mborzecki> if anyone has got a spare moment #4340 needs reviewing
<mup> PR #4340: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340>
<niemeyer> mvo: Sent some notes on #4356.. general idea looks good
<mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
<niemeyer> mvo: Only real open point is how to report this to the server in the right way
<niemeyer> mvo: Lying about the revision is dangerous since the server may end up inferring bogus information out of it (e.g. epochs)..
<niemeyer> mvo: Will leave that with pedronis if you need to sort out over the next few days
<pstolowski> niemeyer, hello! will you manage to take a quick look at #4358 before you start holidays? Just a quick early review will be very valuable (you can focus on just the repo/handlers/policy for 1st pass), so I can address any comments and start working on autoconnect changes
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<niemeyer> pstolowski: Will do!
<mvo> niemeyer: thanks, sounds great. I will polish it a bit and then we need to brainstorm about the lying part :)
<mvo> niemeyer: (we == pedronis and I)
<niemeyer> mvo: My ideal scenario is we just don't send it
<niemeyer> mvo: As anything there would be bug prone
<mvo> niemeyer: :+1:
 * pstolowski lunch
<niemeyer> mvo: We need an ack from server team on that
<niemeyer> mvo: and less urgently, we need to send the epoch too, for those specific cases, so the server can better tell what to return
<mvo> niemeyer: *nod*
<niemeyer> mvo: If there's a strong reason not to send anything in terms of epochs (can't think of one right now), I'd suggest just assuming the latest epoch on the server end, and hoping for the best
<niemeyer> mvo: Clearly more error prone
<mvo> niemeyer: yeah, makes sense.
<mvo> niemeyer: there will be a bit of risk in any case, snapd knows (potentially) very little about the snap. but my gut-feeling is that 99% of the users/use-case will be developers of their own snaps
<mvo> niemeyer: in any case, thanks for your thoughts on this!
<niemeyer> mvo: Right, exactly.. my main concern is misbehavior on the sweet spot of the use cases precisely
 * mvo nods
<niemeyer> mvo: Someone trying to cook an epoch upgrade will have trouble if the store doesn't know what epoch to assume
<niemeyer> mvo: Noting here that our spec for epochs allows a posteriori uploads for any epoch
<pedronis> epoch will only happen with the new apis,  and there we have places to do the right thing
<pedronis> IÂ need to double what the store does with revisions in the current api
<pedronis> *double check
<Chipaca> mvo: ikey: about startup time, note that if, as some people have asked, we need to checksum snaps on boot, startup time is going to go to heck (i'd propose making that fsck manual on classic fwiw)
<niemeyer> pedronis: Right, this is definitely about the upcoming API, not the current one.. it's mainly about being aware of this need, as I recall it being written off as unnecessary in one of our conversations
<zyga-ubuntu> mborzecki: can you please have look at 4315 again?
<mborzecki> ok
<mborzecki> looking
<zyga-ubuntu> thank you
<zyga-ubuntu> I could use a review on 4329
<zyga-ubuntu> niemeyer: ^ not sure if you want to take that one today
<pedronis> Laney: what's the question about seed.yaml ?
<mup> PR snapd#4355 closed: release: 2.30~rc2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4355>
<brunosfer> zyga-ubuntu: Could you help me out with the plug connection from bluez service in snap? I can't figure out how to connect the bluez slot with the bluetooth-controller so that I can have access to the hci0 from shell.
<zyga-ubuntu> brunosfer: so what did you try?
<brunosfer> zyga-ubuntu: The documentation here: https://github.com/snapcore/snapd/wiki/Interfaces  is too evasive, just refer to a snap that you already have to consume the bluetooth service.
<zyga-ubuntu> brunosfer: I'm curiouto know what you tried
<brunosfer> zyga-ubuntu: sudo snap connect bluez:bluetooth-control core:blue
<brunosfer> zyga-ubuntu: sudo snap connect bluez:bluetooth-control core:bluez
<morphis> brunosfer: you can't intermix plugs/slots with different interfaces
<zyga-ubuntu> brunosfer: what is the name of the snap you are trying to use? bluez?
<brunosfer> zyga-ubuntu: yes
<morphis> brunosfer: the bluez interface only gives you access to the bluez DBus API
<morphis> if you want raw access to hci0 you need bluetooth-control
<morphis> define a plug in your snap for it
<morphis> plugs:
<morphis>   bluetooth-control:
<brunosfer> I want to connect bluez to the controller so I can replicate the same behaviour I have in classic mode when I do hciconfig anf the hci0 interface pops up
<morphis>     interface: bluetooth-control
<morphis> or event shorter with just plugs: [bluetooth-control]
<brunosfer> I don't have a snap built yet... I'm trying to access the interface using the console
<morphis> brunosfer: btw. if you can you shouldn't use hciconfig anymore
<morphis> the easiest and best is to go through the bluez dbus API to power up the interface
<brunosfer> thanks for the advice, but for testing purposes I would like to know how can I attach the interface of bluez with the console...
<ogra_> you dont need interfaces on the console
<morphis> not sure what you mean by that
<ogra_> interfaces are for interaction between snaps ...
<ogra_> on the console you can do everything you want ... interfaces wont apply there
<brunosfer> if I want to refer to a specific interface such as hci5
<ogra_> thats a device :)
<brunosfer> how can I specify that if I only have a interface...
<ogra_> i was referring to snap interfaces
<ogra_> how would you access that device on any other linux ?
<morphis> brunosfer: where do you want to specify that?
<ogra_> it isnt different ...
<brunosfer> I'm struggling here with all the changes in the OS, I was so used with the classic mode...
<morphis> brunosfer: what exactly are you trying to do?
<brunosfer> I want to replicate the same behaviour in classic mode when you type "hciconfig" on the shell and you see the devices you have
<sergiusens> mpt_ hello again, I keep pinging you because your insight is really good! I have another PR which could use your input snapcraft#1789
<mup> PR snapcraft#1789: cli: improve the help command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789>
<zyga-ubuntu> hmmm
<zyga-ubuntu> ogra_:
<zyga-ubuntu> ogra_: do you have a moment:
<ogra_> zyga-ubuntu, sure
<zyga-ubuntu> ogra_: can you grab any core device you have around you and run losetup --all
<morphis> brunosfer: so you want to put hciconfig into a snap?
<brunosfer> I have an application that uses bluez API and I want to port it to a snap.
<brunosfer> But first, I want to make sure I understand well how plugs and slots, work, so I can move on with the snap.
<zyga-ubuntu> ogra_: how many times is core attached?
<zyga-ubuntu> brunosfer: plugs and slots are endpoints on snaps
<brunosfer> my idea is to connect the bluetoothctl and try out, in classical mode it works, in ubuntu core using the bluez.hciconfig it says I have permissions for hci0
<ogra_> zyga-ubuntu, http://paste.ubuntu.com/26118700/
<zyga-ubuntu> brunosfer: as long as the interfaces of each side are compatible you can connect them together
<zyga-ubuntu> brunosfer: snapd changes the confinement system affecting each snap
<ogra_> zyga-ubuntu, on some i had run snap abort for a hanging core already (pi3 and joule)
<zyga-ubuntu> /dev/loop0: []: (/writable/system-data/var/lib/snapd/snaps/core_3587.snap)
<zyga-ubuntu> /dev/loop3: []: (/var/lib/snapd/snaps/core_3587.snap)
<zyga-ubuntu> why is this happening?
<brunosfer> zyga-ubuntu: you mean that I just need to run my sdp server as in classic mode and building the snap it magically connects to the correct interface hci0 in this case?
<zyga-ubuntu> ogra_: something is not detaching those
<ogra_> zyga-ubuntu, you tell me :)
<zyga-ubuntu> brunosfer: no
<zyga-ubuntu> brunosfer: I just told you what interfaces are in general,
<mpt_> looking
<zyga-ubuntu> brunosfer: specific interfaces (e.g. the bluez interface) have particular behavior that may or may not fit your use case
<ogra_> zyga-ubuntu, they are double mounted ... thats the design of assembling the rootfs i think
<zyga-ubuntu> ogra_: they are not only double mounted, the same core is loop-attached twice to separate loop devices
<ogra_> zyga-ubuntu, i.e. we mount /writable from initrd, then mount the snap ... then do all the bind mounting back into /writable for rw stuff and then use run-init to switch the rootfs
<ogra_> the original snap mount will stay
<zyga-ubuntu> ogra_: mmmm
<ogra_> zyga-ubuntu, and then i guess systemd mounts them again due to having a .mount unit
<zyga-ubuntu> ogra_: aha
<zyga-ubuntu> ogra_: I see
<zyga-ubuntu> ogra_: thanks!
 * zyga-ubuntu knows more but needs to see why his test is still failing
<ogra_> we could perhaps make these mount usingts skipped ... based on /proc/cmdline or so
<ogra_> since we dont really need them mounted twice
<ogra_> (but can not "not mount" them when assembling the rootfs)
<zyga-ubuntu> ogra_: right
<ogra_> i'm not sure if "mount --move" would work here to move the existing mount to a new place ...
<zyga-ubuntu> ogra_: ideally we'd mount them but reuse the loopback device
<ogra_> sounds risky in any case though
<ogra_> yeah or that
<ogra_> will need a *lot* of testing though ... after all you suffle stuff around unterneath your rootfs /
<ogra_> *shuffle
 * zyga-ubuntu analyzes http://pastebin.ubuntu.com/26118742/
<pstolowski> niemeyer, i've just addressed the last tiny bit in #4301, would be great if you had another look at it, it's a prerequisite for everything else re interface hooks
<mup> PR #4301: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>
<zyga-ubuntu> ha
<zyga-ubuntu> ok
<zyga-ubuntu> niemeyer: that issue I talked about in the call, it's actually trickier
<zyga-ubuntu> niemeyer: but I now have a full(er) picture
<zyga-ubuntu> niemeyer: it relates to those loop devices I spoke with ogra above
<zyga-ubuntu> niemeyer: I think I just need to adjust logic to check that the / inside matches / outside (when snap name == "core")
<zyga-ubuntu> niemeyer: because on core / is mounted in initrd and it is a spearate mount of the same snap (but has different loopback device)
<zyga-ubuntu> niemeyer: alternatively we could not perform this detection when running on core and when the base snap is "core"
<zyga-ubuntu> niemeyer: as any change would warrant a reboot
<ogra_> cant you just match the mountpint and ignore it if there is /writable involved ? or will that use the wrong loop device ?
<om26er> kyrofa: ping
<zyga-ubuntu> ogra_: what do you mean by match the mountpoint?
<ogra_> zyga-ubuntu, well, if you check the loop device you surely also check where it is mounted, no ? if the mountpoint contains /writable it is the one mounted from the initrd
<zyga-ubuntu> ogra_: no, we don't do that
<ogra_> ah ,k
<zyga-ubuntu> ogra_: we don't look at loop devices at all
<zyga-ubuntu> ogra_: we look at what the current base device is outside
<zyga-ubuntu> ogra_: and what / is inside
<zyga-ubuntu> ogra_: and compare device numbers
<ogra_> ah, k
<zyga-ubuntu> ogra_: I think it's not far but I need to tweak that somehow
<ogra_> zyga-ubuntu, technically your rootfs core snap is always on loop0 ... since it is the very first thing we mount
<ogra_> in case that helps ...
<zyga-ubuntu> ogra_: I don't look at just core, I'm checking the designated base snap
<zyga-ubuntu> ogra_: it could be core but doens't need to be
<ogra_> well,  there i dont know how michael plans to assemble the rootfs
 * zyga-ubuntu thinks what to do
<ogra_> but i imagine even there core would be 0 or 1
<zyga-ubuntu> ogra_: I think I just want to adjust this to work with what we do today
<joc> does anyone know if the snapd 2.30 has any REST API changes in it?
<zyga-ubuntu> ogra_: regardless if it is core (we can have bootable bases too)
<ogra_> depending if you first mount base or first mount core
<zyga-ubuntu> joc: hey, probably, what are you seeing?
<ogra_> we have to :)
<ogra_> (i understand core+base is just todays core cut in half ... )
<joc> zyga-ubuntu: we use /v2/snaps to get list of installed snaps - when running on beta channel that's failing
<ogra_> (at least in the bootable case)
<joc> zyga-ubuntu: think maybe the devmode field got removed?
<pedronis> joc: it's omitted when false
<pedronis> now
<pedronis> mmh
<pedronis> if it's a problem we have stuff to revert
<pedronis> mvo: ^
<joc> pedronis: well we like to record details of the system we are testing and if snaps are in devmode it is useful to know
<cwayne> joc: is that what's making our snap list test fail?
<joc> cwayne: yes i believe so
<pedronis> mvo: we might have to undo more of robert change
<pedronis> or all of it
<pedronis> joc: you are hitting this:   https://github.com/snapcore/snapd/pull/4260
<mup> PR #4260: Stop various JSON field from being sent with null values <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4260>
<pedronis> it seems it does for bools as well which is a bit questionable
<Laney> pedronis: sorry for the late reply, I'm working on seeding snaps for Ubuntu images and c_jwatson said that classic snaps need to be specified differently in seed.yaml, so I was looking for docs to show me how to do that
<pedronis> Laney: they need classic: true  in the snap entry
<pedronis> otherwise they are like the reset
<pedronis> s/reset/rest/
<joc> pedronis: whatever your decision we would like to know soon as this breaks our test runs when that version of snapd is present, we would have to release new versions of checkbox snaps
<Chipaca> niemeyer: where should the snap.yaml me documented?
<Chipaca> i'm a bit lost
<niemeyer> Chipaca: The #doc category.. not sure if we have that already, or if it's still in the old wiki
<pedronis> joc: best to wait for mvo to have an opinion on this,  I would be keen to revert myself but I also don't know what was robert motivation for the change, just tidiness or what
<Laney> pedronis: ok, so just name/channel/classic: true then?
<Laney> got an example of one in your head that I can test with? :-)
<pedronis> Laney: and file and snap-id
<pedronis> Laney: no
<Laney> oh yes we have file too
<Laney> not snap-id though
<pedronis> Laney: is this code in ubuntu-image for classic images?
<Laney> https://bazaar.launchpad.net/~laney/livecd-rootfs/snap-seeding/view/head:/live-build/auto/build#L35
<pedronis> live-build?
<Laney> ish
<pedronis> not ubuntu-image though?
<Chipaca> niemeyer: here https://forum.snapcraft.io/t/the-snap-format/698 ?
<pedronis> Chipaca: yes
<pedronis> I was about to give you that link
 * pedronis needs to take a break
<Laney> pedronis: no, deb based images with some snaps added
<mup> PR snapcraft#1791 closed: tests: python plugin integration tests moved to a separate suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1791>
<mvo> joc: sorry for the delay, my suggestion is to open a forum topic, invite robert to it so that he can weight in, I am fine with reverting fwiw
<joc> ok
<pedronis> mvo: the PR just mentioned debugging and size of payload,  OTOH the fix for Tracks is needed
<mvo> pedronis: right, I can prepare a partial revert PR
<elopio> hey zyga-ubuntu, would you like to review some polish subtitles for a short snapcraft video?
<zyga-ubuntu> elopio: sure
<zyga-ubuntu> elopio: I'm going to pick my son from school but I can review it soon, just give me a link
<elopio> zyga-ubuntu: https://www.youtube.com/timedtext_editor?action_mde_edit_form=1&v=ZsUV9xnrkTA&lang=pl&bl=csq&ui=cr
<elopio> thank you!
 * kalikiana waves at elopio 
 * kalikiana coffee break
<sergiusens> elopio help PR updated
<sergiusens> kyrofa you might want to look at my help PR as there's something there you can use ;-)
<Chipaca> niemeyer: pedronis: should we still be documenting the 'aliases' entry in snap.yaml?
<niemeyer> mborzecki: Almost finished
<niemeyer> mborzecki: Will you be around for a bit still? Would like to discuss any open points
<niemeyer> Chipaca: It's dead, so probably not :)
<Chipaca> at some point we're going to want to split the snap.yaml bit out of that doc
<Chipaca> not today tho
 * Chipaca gets back to hating tests
<zyga-ubuntu> elopio: sure
<Chipaca> also not in that doc: assumes
<zyga-ubuntu> elopio: done
<zyga-ubuntu> elopio: I re-wrote it mostly
<zyga-ubuntu> elopio: not very bad but very machine-translated IMO (too direct)
<zyga-ubuntu> elopio: you can get (plenty) of 2nd reviews from pstolowski or mborzecki :)
 * zyga-ubuntu prints something and goes to figure out a solution on paper
<pstolowski> elopio, hey, yeah polish are majority in snapd team now, you can take advantage of that :)
<mborzecki> niemeyer: yeah, i can be around
<zyga-ubuntu> elopio: resistance is futile :)
<elopio> zyga-ubuntu: pstolowski: great! :) Thanks.
<zyga-ubuntu> elopio: how did you get the initial translation
<zyga-ubuntu> elopio: was that google translate?
<zyga-ubuntu> jdstrand: hey, are you around?
<elopio> zyga-ubuntu: google code-in.
<zyga-ubuntu> elopio: aha
<elopio> zyga-ubuntu: maybe, they didn't do the work :/
<zyga-ubuntu> elopio: no, I doubt they would do that; it is exactly like how I translated things when I was younger
<zyga-ubuntu> elopio: (I started as a translator)
<elopio> zyga-ubuntu: did you check the title and description too?
 * kalikiana feeling lonely at the snapcraft weekly HO
<Chipaca> niemeyer: why is spread's order with -shell different from without it, for a given seed? is that on purpose?
<Chipaca> niemeyer: wait, ignore me, typo on the commandline
<mup> PR snapcraft#1774 closed: storeapi: support for pushing binary metadata <Created by matiasb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1774>
<pstolowski> zyga-ubuntu, are you updating these subtitles or shall I?
<pedronis> Chipaca: IÂ think snapcraft started deprecating it in 2.35
<pedronis> sergiusens: hi, is snapcraft still SRUed, or snap only for new stuff?
<niemeyer> Chipaca: Phew!
<niemeyer> mborzecki: Sent!
<niemeyer> mborzecki: Please let me know if you want to have a call on this
<jdstrand> zyga-ubuntu: yes
<cachio_> niemeyer, any news on the rawhide image?
<niemeyer> cachio_: No, it's still quietly awaiting
<niemeyer> ;)
<niemeyer> cachio_: Let me confirm mborzecki is good to go, and I'll look into it
<Chipaca> aw, for a moment I read "it's still quietly amazing", and was happy
<cachio_> niemeyer, sure
<om26er> Hi! Now that snapcraft 2.35 is in xenial-updates, will build.snapcraft use that for the next build that kicks in ?
<om26er> nessita: ^
<nessita> om26er, I have no idea! could you please ask someone from the web team? they maintain build.
<nessita> om26er, but I'm interested in teh answer if you find out :-)
<mup> Issue snapcraft#1794 opened: Apply patchelf work to non classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1794>
<om26er> popey: are you around ?
<popey> om26er: sup
<om26er> popey: need you to merge a few PRs on android-studio snap project.
<om26er> https://github.com/snapcrafters/android-studio/pull/4
<mup> PR snapcrafters/android-studio#4: Revert "explicitly make studio.sh executable" <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/4>
<popey> will take a look in a bit
<om26er> and https://github.com/snapcrafters/android-studio/pull/5
<mup> PR snapcrafters/android-studio#5: new version <Created by rajabiy> <https://github.com/snapcrafters/android-studio/pull/5>
<om26er> Alright, thanks popey
<kalikiana> kyrofa: can we have a HO tomorrow your morning to talk about bug 1686481 ? as in, whether/ how we want to try and work-around packaging problems
<mup> Bug #1686481: stage-packages does not handle unmet dependencies <kubernetes> <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1686481>
 * kalikiana will add another comment on the bug before eod'ing
<kyrofa> kalikiana, sure thing
<kyrofa> kalikiana, you can schedule one, or ping me, my morning is open
 * Chipaca brb, other laptop is growing a bulge and needs help
<kyrofa> Chipaca, oh no
<Chipaca> kyrofa: "why is the trackpad no longer working!!!" grumbled the kids
<Chipaca> tell you why: the laptop was a pillo
<Chipaca> pillow*
<kyrofa> Yikes, I somehow doubt "help" is what it needs
<popey> kyrofa: who 'owns' the "snapcraft enable-ci travis" command?
<kyrofa> popey, well, we do I suppose
<kyrofa> What's up?
<popey> if I run it, it spits out a wall of text then says [y/N]. What exactly is it asking me there?
<popey> There are no questions.
<om26er> who shall I talk to for a quick query about build.snapcraft ?
<popey> om26er: just ask away
<om26er> I did, above :)
<om26er> "Now that snapcraft 2.35 is in xenial-updates, will build.snapcraft use that for the next build that kicks in ?"
<kyrofa> popey, hmm, I think that should be more of a "continue? [y/N]" type thing
<kyrofa> popey, not the best experience, agreed
<kyrofa> popey, I don't remember the justification, but I suspect it was wanting to point out that this is experimental
<popey> ok
<popey> ta
<popey> om26er: yes, should do, I see xenial-updates in the build log
<om26er> super! that unblocks both AndroidStudio and SublimeText.
<kyrofa> om26er, sorry, missed that question. Indeed, it should be working now
<popey> om26er: merged those two, keep an eye on the build log :)
<om26er> popey: great. will keep looking.
<mup> PR snapcraft#1795 opened: Don't include source tarballs from previous runs <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1795>
<kalikiana> kyrofa: awesome, will do. thanks!
 * kalikiana sent out meeting minutes as well
<kalikiana> now time for dinner
<sergiusens> kalikiana enjoy
<kalikiana> thanks!
<mup> Bug #1736541 opened: core rest api docs out of date <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1736541>
<om26er> popey: Need you to setup sublime text for auto build in build.snapcraft, the packaging is already there.
<om26er> ...whenever you can.
<jdstrand> mvo: is this known when running ./run-checks: http://paste.ubuntu.com/26119892/
<jdstrand> mvo: this is running the tests on an artful host in a xenial lxd container
<mup> PR snapd#4359 opened: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4359>
<sergiusens> elopio any update on the help PR?
<popey> om26er: ok, doing now
<elopio> sergiusens: +1.
<popey> om26er: building now
<om26er> great stuff
<om26er> seems amd64 builders are quite busy today
<kyrofa> sergiusens, snapcraft#1780 is ready for another look
<mup> PR snapcraft#1780: cli: add export-login command <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1780>
<jdstrand> mvo: fyi, that happens in both master and release/2.30
<mvo> jdstrand: not known, let me try to reproduce
<mvo> jdstrand: I assume 4359 targets 2.30 ?
<sergiusens> kyrofa just looking
<sergiusens> kyrofa also `patchelf --print-needed`
<kyrofa> sergiusens, oooo!
<sergiusens> kyrofa and I followed up on the rpath one
<mup> PR snapd#4360 opened: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4360>
<mvo> jdstrand: :) and \o/
<jdstrand> mvo: oh heh, I was trying to be good then I saw you milestoned 4359 :)
<jdstrand> mvo: so both are milestoned. I guess I should remove the 4359 one?
 * jdstrand removes
<jdstrand> if you want it back, holler
<mvo> jdstrand: yes
<mvo> jdstrand: I mean, what you did (remove) if fine
<jdstrand> thanks :)
<mvo> sergiusens, kyrofa, stgraber - hey, just a quick heads up, we have a new snapd in the candidate channel it should fix issues with lxd. if you guys could just run it a little bit to make sure there is nothing wrong with it, that would be great
<stgraber> mvo: what issue?
<kyrofa> mvo, does that include https://forum.snapcraft.io/t/lxc-snaps-dont-update/786 ?
<kyrofa> Or the one reported in the release thread?
<mvo> kyrofa: the one from the release thread. afaik zyga-ubuntu is working on the other issue still
<kyrofa> mvo, alright, thank you
<mvo> stgraber: the fix for snap-confine to work correctly under lxd, its finally in candidate
<om26er> is there a way to check the size of delta between two revisions of a snap in store ?
<mvo> stgraber: i.e. this one https://github.com/snapcore/snapd/pull/4246 is the most important change
<mup> PR #4246: snap-confine: fix snap-confine under lxd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4246>
<mup> PR snapd#4339 closed: userd: generalize dbusInterface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4339>
<mup> PR snapd#4317 closed: tests: make interfaces-snapd-control-with-manage more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4317>
<Chipaca> nearly there! got a strace
<Chipaca> but now i need to stop
<Chipaca> fun thing: the strace only succeeds in repro'ing the issue if it's not writing to stdout
<Chipaca> so there's a timing issue the size of a bus, i reckon
<Chipaca> yikes, 30 minutes past get-stinky-boys-in-the-water
 * Chipaca runs
<zyga-ubuntu> re
<zyga-ubuntu> jdstrand: o/ :)
<zyga-ubuntu> how are things?
<zyga-ubuntu> kyrofa: no updates still, it's all non trivial I'm afraid
<jdstrand> mvo: fyi, I ran run-checks with release/2.29 and it doesn't fail
<zyga-ubuntu> kyrofa: so I'm still working on a related but not quite the same issue
<jdstrand> zyga-ubuntu: hey :)
<zyga-ubuntu> jdstrand: the more I look at mount stuff
<zyga-ubuntu> jdstrand: the more it is like that abyss quote
<jdstrand> heh and :\
<zyga-ubuntu> jdstrand: today I realized that / is not the core snap (separate loopback device)
<zyga-ubuntu> jdstrand: and that / is mounted twice from the same device
<zyga-ubuntu> jdstrand: and that the mount table is ~400 element-strong which is a bit crazy
<jdstrand> yeah. haven't been thrilled with how big that table is
 * zyga-ubuntu printed http://pastebin.ubuntu.com/26118789/
<jdstrand> a lot of that is the writable-path stuff
<mvo> fwiw, I want to kill writable-path for base-18
<mvo> but it will be quite a bit of work
<lundmar> I only need just one more +1 here https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 . Please :)
<mvo> niemeyer: I guess you are super busy with a gazilion of things, if there is a free spot a high level opinion on 4342 would be great (the abstrace UI PR)
<zyga-ubuntu> lundmar: LXI as in that test equipment protocol?
<zyga-ubuntu> lundmar: I'll vote
<zyga-ubuntu> done
<jdstrand> well, it needs someone from the reviewers team
<jdstrand> kyrofa: hey, perhaps you would like to weigh in on https://forum.snapcraft.io/t/request-autoconnect-avahi-observe-plug-for-lxi-tools/2976 for lundmar?
<kyrofa> jdstrand, happily, let me do some quick research as well
<jdstrand> thanks
<lundmar> zyga-ubuntu: exactly, the LXI standard that most modern T&M instruments supports. lxi-tools is an open source effort to support this open standard.
<lundmar> zyga-ubuntu: If you test lxi-tools with an instrument which is not in the list of tested instruments (see https://github.com/lxi-tools/lxi-tools) please let me know and I will add it to the list. That is, if it works ;)
<zyga-ubuntu> lundmar: looking at the lsit
<zyga-ubuntu> lundmar: nowadays I just have my power supply left
<kyrofa> jdstrand, that slot isn't supplied by the core snap on ubuntu core, right?
<zyga-ubuntu> lundmar: I have rigol DP832 which is on the list
<mborzecki> /quit/quit
<zyga-ubuntu> lundmar: thank you :)
<lundmar> hehe, your welcome ;)
<lundmar> DP832 is awesome
<lundmar> except for the fan noise ofc haha
<zyga-ubuntu> haha, my thoughts exactly
<zyga-ubuntu> it's a very sturdy and reliable unit
<zyga-ubuntu> just noisy :)
<zyga-ubuntu> and the feature set is very good for the price
<lundmar> yes, heavy = quality :)
<cachio_> niemeyer, https://travis-ci.org/snapcore/snapd/builds/311803585#L1078
<cachio_> when we run the tests from travis fedora-27 is not starting neither
<cachio_> niemeyer, it is weird because from my machine I can run on fedora-27
<cachio_> niemeyer, using the API is it pÃ³ssible to see the console output?
<zyga-ubuntu> lundmar: I used to have an agilent DSOX A2004 but without the lan interface
<zyga-ubuntu> lundmar: is the usb protocol very different from LXI?
<zyga-ubuntu> (the protocol wrapped in USB)
<lundmar> zyga-ubuntu: not in the sense they both supports sending SCPI commands
<lundmar> but compared, USB is basically just a raw connection, no protocol.
<zyga-ubuntu> so that rigol power supply, the USB interface to control is is totally distinct to the network interface?
<zyga-ubuntu> or are you saying that both wrap SCPI
<lundmar> both wrap SCPI
<lundmar> LXI can use three protocols: RAW/TCP, VXI11/TCP, and HISLIP/TCP. The latter is next gen and I'm currently implementing the protocol so we can have a first class open source offering for it.
<lundmar> the need for avahi/zeroconf is also next gen
<niemeyer> cachio_: I'm not sure to be honest.. I haven't
<lundmar> zyga-ubuntu: let me know if you run into issues with the lxi-tools snap. If you can confirm that the screenshot feature works with your DP832 that would be helpful.
<zyga-ubuntu> lundmar: trying
<cachio_> mvo, the install cache test is failing in all the snap cores
<cachio_> mvo, basically the logs don't contain any information about the cache
<zyga-ubuntu> lundmar: "Broadcasting on interface lo
<zyga-ubuntu> lundmar: I think that's silly ;)
<cachio_> mvo, should I create a forum topic or you want to take a look first
<zyga-ubuntu> lamont: woot, works like a charm
<zyga-ubuntu> sorry lundmar ^
<lundmar> zyga-ubuntu: there is nothing wrong in talking to yourself through lo :D
<cachio_> mvo, catalog update failing too
<zyga-ubuntu> lundmar: my suggestion would be to make it clear the format is always BMP or enrich the tool to support other formats
<cachio_> mvo, it is similat to the prevous one
<zyga-ubuntu> where can I post those images?
<lundmar> zyga-ubuntu: great. Well, unfortunately the screenshot format is dictated by the instruments so to keep the interface simple we simply let the screenshot plugins manage which format is used.
<lundmar> zyga-ubuntu: also, we don't want to support any conversion etc. but only provide the source material.
<zyga-ubuntu> lundmar: https://imgur.com/3KKb5oF
<lundmar> nice
<zyga-ubuntu> lundmar: right but some smarts could be useful for first time users :)
<lundmar> zyga-ubuntu: in other words, some instruments gives you a .bmp or .png . In your case .bmp is about 3x as fast as .png
<lundmar> the poor chipset is too slow to do .png compression haha
<zyga-ubuntu> lundmar: right but the client side can fingerprint and convert
<lundmar> either way - the tool provides a lossless image. It's up to to user to convert it to whatever format they want.
<lundmar> zyga-ubuntu: fyi - this is kind of the unoffical discussion thread for lxi-tools in case you feel like chiming in: https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/?all
<zyga-ubuntu> lundmar: yes but the user _cannot know_ what the format is :)
<zyga-ubuntu> lundmar: apart from looking
<zyga-ubuntu> lundmar: in either case, it works :")
<lundmar> true
<lundmar> I had a guy using the lxi-tools snap in a NFS mounted directory - of course the confinement gave him permission denied.
<lundmar> his only solution was to use --classic install
<zyga-ubuntu> lundmar: this is now fixed
<zyga-ubuntu> lundmar: as long as that is in /home
<zyga-ubuntu> lundmar: I implemented support for NFS
<zyga-ubuntu> lundmar: he should have actually used --devmode as classic has lower chance of working
<lundmar> good. I'm not sure but I think maybe his case was outside home.
<lundmar> from the doc description  --classic and --devmode seems to be the same except the added debug messaging
<zyga-ubuntu> lundmar: where?
<zyga-ubuntu> lundmar: devmode is "same as strict but with advisory confinement"
<zyga-ubuntu> lundmar: classic is "it runs on top of your system, no magic", usually this will fail with shared libraries missing
<lundmar> zyga-ubuntu: https://docs.snapcraft.io/reference/snap-command
<zyga-ubuntu> lundmar: indeed, that doesn't capture it
<lundmar> zyga-ubuntu: that is, both "disable security confinement"
<zyga-ubuntu> Chipaca: do you know where that docs came from ^
<zyga-ubuntu> lundmar: yes but the important aspect is not there
<lundmar> ok
<zyga-ubuntu> lundmar: "disable the use of root filesystem redirection"
<zyga-ubuntu> that's classic
<jdstrand> popey: hey, not sure if you saw yesterday, but vlc snaps keep coming in with broken symlinks
<lundmar> so classic disable confinement while devmode is advisory confinement
<jdstrand> popey: for the desktop file
<lundmar> ?
<lundmar> zyga-ubuntu: a little elaboration on the difference in the docs would be nice :)
<zyga-ubuntu> lundmar: classic == like curl | sh
<zyga-ubuntu> lundmar: devmode == like curl | sh in a very fancy chroot
<zyga-ubuntu> lundmar: yes, I'm not sure who wrote those docs though
<lundmar> snaps are using cgroups and apparmor for confinement right?
<lundmar> no lxc right?
<zyga-ubuntu> lundmar: apparmor, seccomp, some cgroups (devices and freezer) and dbus bus rules/permission
<zyga-ubuntu> lundmar: and chroot on steroids
<Chipaca> zyga-ubuntu: those docs are via davidcalle afaik
<lundmar> ok, so no use of linux containers (lxc)
<zyga-ubuntu> lundmar: we rely on mount namespace heavily
<zyga-ubuntu> lundmar: no but lxc uses many of the same things
<zyga-ubuntu> lundmar: we just don't use all the namespaces, just the mount namespace
<zyga-ubuntu> Chipaca: thanks!
<Chipaca> zyga-ubuntu: which bit is causing confusion?
<lundmar> yeah, I haven't looked into the details of snap yet but it is difficult to find any description anywhere of the techs involved
<zyga-ubuntu> davidcalle: do you know if we could fix the description of --devmode and --classic there
<zyga-ubuntu> Chipaca: ^
<zyga-ubuntu> lundmar: I could write some
<Chipaca> lundmar: have you seen the messages describing the flags?
<lundmar> zyga-ubuntu: it would be nice at this stage to have a writeup describing the techs involved but maybe it would be something for a blog post
<Chipaca> lundmar: e.g. âThe publisher of snap %q has indicated that they do not consider this revision to be of production quality and that it is only meant for development or testing at this point. As a consequence this snap will not refresh automatically and may perform arbitrary system changes outside of the security sandbox snaps are generally confined to, which may put your system at risk.â
<Chipaca> lundmar: that's --devmode
<Chipaca> lundmar: whereas --classic says âThis revision of snap %q was published using classic confinement and thus may perform arbitrary system changes outside of the security sandbox that snaps are usually confined to, which may put your system at risk.â
<Chipaca> lundmar: so there's a technical difference (as described by zyga above), but there's also the expectations about what you're trying to do (and the tooling encourages you along these lines)
<lundmar> Chipaca: you guys should put some of those details in the snap man page :)
<jdstrand> lundmar: in terms of the security sandbox: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554. it has references to other information at the bottom
<Chipaca> lundmar: so much to do, tho
<lundmar> jdstrand: thanks - good stuff!
<lundmar> Chipaca: yeah, btw. did you see my response on the autocompletion function suggestion?
<lundmar> the addition of e.g. a completer-function key etc.
<Chipaca> lundmar: I did. I didn't like it, but haven't gotten back to explaining why :-/
<Odd_Bloke> kyrofa: sergiusens: ISTR that the snapcraft snap had some problems in the past; can it now be used safely?
<lundmar> Chipaca: You can't possible not like such a simple elegant solution ;)
<kyrofa> Odd_Bloke, yes, today it should be good to go
<Chipaca> lundmar: restricting completers to only use -F is the opposite of having things just work
<Chipaca> lundmar: not everything is -F
<kyrofa> Odd_Bloke, that's why we held off on a stable release for so long
<kyrofa> But now that it's in stable, you should be good
<Odd_Bloke> OK, great!
<lundmar> Chipaca: hmm, I have yet to see a script that does not use -F . But if thats the case then yes its a problem.
<Chipaca> anyway why am i on work irc at 8pm
 * Chipaca goes to see if the apple crumble is done
<Chipaca> oh now i remember why: the kitchen is full of dirty dishes
<zyga-ubuntu> Chipaca: greatest peril in modern history
<zyga-ubuntu> Chipaca: take your flying cars vision-of-the-future, give me automatic kitchen
<Chipaca> yeah
<Chipaca> and now i've got 10 minutes while spread does it thing
<Chipaca> so, dishes Â¯\_(ã)_/Â¯
<jdstrand> mvo: would you like me to create a forum topic on http://paste.ubuntu.com/26119892/?
<kyrofa> Oh come on github
<kyrofa> sergiusens, elopio needs one more review on each PR
<sergiusens> kyrofa which one?
<kyrofa> Both milestone PRs
<kyrofa> The "what why and how" is the big one
<jdstrand> mvo: I'll just create one
<sergiusens> kyrofa oh, those
<kyrofa> The other is actually quite small if you factor it out
<sergiusens> yeah
<kyrofa> sergiusens, would be nice to see an integration test for snapcraft#1781
<mup> PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<sergiusens> kyrofa talked to elopio actually, going to use the opencv demo as a validation
<kyrofa> Ah, alright
<sergiusens> kyrofa it has dependencies, so it is a good candidate to make sure $ORIGIN is setup correctly
<sergiusens> kyrofa I do have to tend to other matters now, so this will not happen until later in the evening/night though
<sergiusens> tests are taking long to run anyways...
 * sergiusens will bbl
<mup> Issue snapcraft#1698 closed: âsnapcraft helpâ parity with --help <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1698>
<mup> PR snapcraft#1789 closed: cli: improve the help command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1789>
<kyrofa> Yes they sure are
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: are you going to be around this week?
<zyga-ubuntu> ogra_: did you see the new arm microsoft laptops?
 * zyga-ubuntu looks forward to arm laptops with 8GB ram 
<zyga-ubuntu> I hope it won't be bootloader-locked into windows
<mup> Issue snapcraft#1711 closed: Develop enable-ci circle-ci <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1711>
<mup> PR snapcraft#1780 closed: cli: add export-login command <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1780>
<mup> PR snapcraft#1792 closed: tests: do not hit the network in python unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1792>
<gsilvapt> howdy all
<gsilvapt> kyrofa, you around?
<kyrofa> gsilvapt, hey there!
<gsilvapt> how's it going?
<gsilvapt> kyrofa, I need your help to solve this issue again: https://github.com/snapcore/snapcraft/pull/1746#event-1370522583
<mup> PR snapcraft#1746: cli: add version command <Created by gsilvapt> <https://github.com/snapcore/snapcraft/pull/1746>
<gsilvapt> I'm not 100% how can I achieve this
<kyrofa> gsilvapt, did we never get past that static failure?
<gsilvapt> Not in my end no, kyrofa
<kyrofa> I got some more experience that since I last looked, let me take a peek here in a sec as soon as I clean all this sanded cardboard off of me
<gsilvapt> Haha, thank you kyrofa :)
<kyrofa> gsilvapt, I can't seem to duplicate that issue locally. I've updated the branch to the latest master, which also runs the tests again. Let's see what happens. However, sergiusens also reviewed it, make sure you respond to his review
<gsilvapt> My question is how to create the constant he asked so I can answer with this done
<gsilvapt> If you could be kind to provide another example of this concept implemented elsewhere, I might be able to understand and do it again for this one
<gsilvapt> kyrofa ^
<kyrofa> gsilvapt, what I believe he's asking for is to create a single variable holding the format string, and then use that variable twice, one in the version command and one in __init__
<kyrofa> gsilvapt, basically taking your goal of making sure they stay in sync by hard-coding the string in both places one step further by using the same variable to hard-code them
<kyrofa> (both)
<kennyloggins> kyrofa: peek is a snap for sharing endlessOS pics on slack though gif manipulation, not a flatpack.
<gsilvapt> kyrofa, ok but is there a specific place to set that global variable? I mean, I don't want to set it in the wrong place and not be able to use it
<sergiusens> gsilvapt the clarification from kyrofa is exactly what I asked for
 * sergiusens is still on the move
<kyrofa> gsilvapt, put it in the version module. That's already imported by __init__ in order to create the version command
<kyrofa> gsilvapt, don't be afraid to take a crack at it and propose the change, we're happy to help you through it
<kyrofa> (all we ask is that you make sure it works before proposing, heh)
<kennyloggins> tea is the answer to anything.
<gsilvapt> kyrofa, this may seem a dumb thing but I'm not following where I should define this variable
<gsilvapt> Do you know if the click docs mention that?
<kyrofa> gsilvapt, you should never feel dumb!
<kyrofa> gsilvapt, nah, this has nothing to do with click, just talking python here
<kyrofa> gsilvapt, let me find you an example
<gsilvapt> kyrofa, often I do. I mean, this code base is a bit complex for me so I'm still getting use to it :P
<gsilvapt> kyrofa, lets do this the other way around if that's okay. Let me try to go over each step and you'll stop me when I'm wrong
<gsilvapt> is that ok?
<kyrofa> gsilvapt, feeling dumb is different than simply not understanding a massive codebase :P
<kyrofa> gsilvapt, sure thing
<gsilvapt> Maybe. But then outsiders come and feel ok with just doing stuff :P
<kyrofa> Hit me
#snappy 2017-12-06
<gsilvapt> Anyway, here's my understanding:
<gsilvapt> The @click.version_option() command should be like @click.version_option(message.format(snapcraft.__version__))
<gsilvapt> This get the version number and plugs it in the variable string
<gsilvapt> The same goes in the version module. click.echo(message.format(snapcraft.__version__))
<gsilvapt> kyrofa, is this correct so far?
<kyrofa> Essentially. The question is: where does `message` come from?
<gsilvapt> Yes
<kennyloggins> how do you ensure that the Mp3 or whatever you are sending is seen in servicesID ?
<kyrofa> Hmm. Anyone run into this before? https://forum.snapcraft.io/t/raspberry-pi-2-edge-core-snap-seems-broken/3061/2
<gsilvapt> Yes, that is essentially the question, kyrofa
<kyrofa> gsilvapt, you've been right so far, can you continue?
<gsilvapt> I tried adding in version module, before click statement and didn't work. Tried adding to group section, not worked either
<gsilvapt> kyrofa, not really. The question is where should I define that variable
<kyrofa> gsilvapt, take a look at snapcraft/cli/store.py
<kyrofa> gsilvapt, notice the `_MESSAGE_REGISTER_PRIVATE` definition
<gsilvapt> kyrofa, yes, I'm trying to follow the example
<kyrofa> gsilvapt, the module-level definitions (like the variable) are accessible from __init__ because we have an "import versioncli" there, right?
<kyrofa> Which means you can access stuff via `versioncli.<variable>`
<kyrofa> Uh, no sorry
<kyrofa> Haha
<kyrofa> Rather, the module-level definitions are available in the `.version` import
<kyrofa> Note how in __init__.py we're using `from .version import versioncli`
<kyrofa> All we need to do is also import the variable you define in there
<kyrofa> It works the same way
<gsilvapt> kyrofa, so I added from .version import _MESSAGE_SNAPCRAFT_VERSION and I am able to use the command again without any errors
<gsilvapt> now I have to properly define the string to get prog name and version number
<gsilvapt> Right now the version command is always retrieving ($prog) and ($version)
<kyrofa> There you go. Although since you've created it for use for other modules I wouldn't use an underscore at the beginning (that indicates that it's mean to be private)
<gsilvapt> Oh right, this is different in Python. A global variable does not take any underscore, right?
<kyrofa> Well, it can, it depends on its usage
<gsilvapt> kyrofa, how about this case?
<kyrofa> Python has very little rules, but lots of conventions
<kyrofa> I would call it `SNAPCRAFT_VERSION_TEMPLATE`
<gsilvapt> I'm more used to work in Java and this stuff is specific anyway :P
<gsilvapt> Well, it's late again and I need to sleep. I hope we can work on this together some time soon. I think it is working now but the string is poorly defined. I need to tell Python where to get the variable values ($prog) and ($version)
<gsilvapt> %(prog) and %(version) instead of what I wrote before, lol
<kyrofa> Yeah that's not too hard, happy to work on it later with ya
<gsilvapt> Thank you! Have a good night folks o/
<kennyloggins> o/
<kyrofa> Night gsilvapt
<mup> PR snapcraft#1728 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1728>
<sergiusens> elopio kyrofa snapcraft#1781 is updated
<mup> PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<mborzecki> morning
<mborzecki> sorry i'm later than usual, had to drive the kids to school & kindergarten
<mvo> hey mborzecki, good morning!
<mvo> mborzecki: no worries
<mborzecki> mvo: thanks for the review & suggestions btw
<mvo> mborzecki: your welcome, but I may have been to simplistic, I think there are more cyclic case
<mvo> mborzecki: something like "a: after-b, b: after-c, c: before-a
<mvo> mborzecki: which I guess (I need to look again) your code addressed but mine did not
<mborzecki> zyga suggested trying to do topo sorting on a graph, so i tried to play with this yesterday, but the naiive approach that i did over the weekend beat the 'smart' in all the cases i tried
<mvo> mborzecki: heh :) yeah, our inputs are pretty small
<mvo> mborzecki: I will look at this again with a fresh mind today
<mborzecki> the benchmarks would suggest that we're loosing on doing extra allocations when creating the 'extra' data structures either dfs or khan may need
<mborzecki> mvo: one thing that bugs me, is that if you add 'after' does that imply 'Requires=' in the service file?
<mvo> mborzecki: I think it does not imply this, one is about ordering, the other about dependencies, they are often used together but orthogonal. i.e. you can express "if this thing.service is installed I want to start before. without the requires it also says: but I don't care if it is there or not"
<mborzecki> this post mentions 'with' https://forum.snapcraft.io/t/snap-service-start-ordering/1470/13 this might map to Requires
<mvo> mborzecki: yeah, I think there is language in there (as a next step) to express these dependeices as well
<mborzecki> let's land this one first and we'll know if there's need for more ways to express dependencies
<kalikiana> good morning folks
<mborzecki> kalikiana: morning
<mup> PR snapd#4361 opened: devicestate: fix misbehaving test when using systemd-resolved <Created by mvo5> <https://github.com/snapcore/snapd/pull/4361>
<jamesh> mvo: I uploaded a new version of the test-snapd-gnome-online-accounts snap (the original wouldn't run due to library incompatibility), which seems to have been held up by the automatic review process.  Are you able to do anything about that?
<mvo> jamesh: probably, let me check
<mvo> jamesh: did you request a manual review?
<mvo> jamesh: if not, please do
<jamesh> mvo: I've done that now
<mvo> jamesh: approved
<jamesh> thanks
<mvo> jamesh: yw, shall I pushlish it as well?
<jamesh> mvo: I think I've got it published right now
<jamesh> thanks for the help
<mvo> great, your welcome
<pedronis> mvo: is edge building still broken?  afaict  current edge doesn't contain yet the configure-snapd fix
<mvo> pedronis: let me check, I though I triggered a manual build the other day. auto-building is broken
<mvo> pedronis: let me trigger it now
<zyga-ubuntu> o/
<zyga-ubuntu> man, I overslept
<Chipaca> I ended up poking at spread in qemu until way too late :-)
<Chipaca> but, now i'm off to physio gym thing, so it evens out
<zyga-ubuntu> Chipaca: what did you find?
<Chipaca> o/
<zyga-ubuntu> ah, ttyl
<Chipaca> zyga-ubuntu: i found that it's weird :-)
<zyga-ubuntu> pfff, we all knew that
<zyga-ubuntu> ;-)
<zyga-ubuntu> enjoy; let's talk soon
<Chipaca> zyga-ubuntu: i've got two straces, one that dies and one that doesn't
<Chipaca> zyga-ubuntu: I don't see the difference
<zyga-ubuntu> pastebin thenm
<zyga-ubuntu> them*
<mvo> +1
<zyga-ubuntu> o/ mvo
<zyga-ubuntu> I have a pastebin I'm chewing through since yesterday, today I need to do some practical experiments on non-test machines
<mvo> cachio_: fwiw, trying to reproduce the install-cache test failure you mentioned on ubuntu-core-16-64 seems to be ok for
<zyga-ubuntu> well, on non-spread test machines running core
<mvo> cachio_: I try harder
<mvo> hey zyga-ubuntu
<zyga-ubuntu> we are doing some very weird things on core
<zyga-ubuntu> (lots of red lights in my mind)
<zyga-ubuntu> the failure of those tests I mentioned yesterday, with the stale core detection, is deeper
<zyga-ubuntu> even if we reboot the system is really broken IMO
<mvo> zyga-ubuntu: oh
<Chipaca> http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/
<mvo> zyga-ubuntu: tell me more?
<mvo> zyga-ubuntu: please
<zyga-ubuntu> mvo: the pastebin I sent you pics of yesterday was from the console of a core system
<zyga-ubuntu> mvo: it seems that we mount / twice
<zyga-ubuntu> mvo: with a load of things in between
<zyga-ubuntu> mvo: my understanding of how this works means that _all_ of the things we mounted before 2nd / are just wasted memory and hidden entries
<zyga-ubuntu> mvo: I don't yet know why we do that
<mvo> zyga-ubuntu: could it be a pivot root thing going on?
<zyga-ubuntu> mvo: it might be but pivot root would leave / mounted elsewhere
<zyga-ubuntu> you cannot pivot root / /
<zyga-ubuntu> (no op)
<mvo> zyga-ubuntu: well, we need to work on this for base-18 anyway, so a good time to cleanup
<zyga-ubuntu> http://pastebin.ubuntu.com/26118789/
<zyga-ubuntu> mvo: good to hear
<zyga-ubuntu> mvo: I'll poke at a real pi3 device and see if this is consistent
<mvo> zyga-ubuntu: have you looked at the initramfs code? the writable path things makes it messy, I'm all for a cleanup
<mvo> (and historic baggage)
<Chipaca> ok, i'm off for real now. I'll leave you guys to ponder which one of those two traces is the one that kills the whole session.
<Chipaca> to me they look identical
<zyga-ubuntu> Chipaca: ha, good plan :)
<Chipaca> (but yes, i know which is which)
<Chipaca> it's as if one of them closed stdout, or stderr, or stdin, or whatever it is
<Chipaca> hmm
 * zyga-ubuntu hates pastebein with moronic need to auth
<zyga-ubuntu> no wget
<mvo> zyga-ubuntu: I'm looking at the pictures you pasted, I see core_ mounted twice on / is that what you are concerend about?
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: IMO that is wrong
<Chipaca> zyga-ubuntu: blame spammers
<mup> PR snapd#4362 opened: interfaces: update fixme comments <Created by stolowski> <https://github.com/snapcore/snapd/pull/4362>
 * Chipaca runs off before he gets sucked in again
<pstolowski> zyga-ubuntu, ^ hey, one of the changes you requested - just an update of comments, no code change
<mvo> zyga-ubuntu: yeah, let me wander into initramfs land again /me puts on asbestos cloth
<zyga-ubuntu> mvo: yeah
<mwhudson> zyga-ubuntu: did i ever tell you about debugging docker on arm64 where cloneflags was ignored so pivot_root was called in the default namespace
<zyga-ubuntu> mvo: I'll gladly work on fixing this
<mwhudson> zyga-ubuntu: that was quite confusing :)
<zyga-ubuntu> mwhudson: haha, that must have been quite the alice in wonderland moment
<mwhudson> especially as the host system didn't have an awful lot on it to distinguish it from the docker image i was testing with
<mvo> zyga-ubuntu: we need to be careful this sh code is undertested
<mvo> mwhudson: woah :)
<mwhudson> i run docker run foo ... and docker itself disappears?
<zyga-ubuntu> mvo: I'm acutely aware of that :/
<mvo> zyga-ubuntu: I know :)
<mvo> zyga-ubuntu: I may have found the bug already and its amazingly stupid
<mvo> zyga-ubuntu: my conservative self is not wanting me to say this, but: I really want to write the initramfs stuff in something sane that is not sh
<zyga-ubuntu> !!!
<zyga-ubuntu> that was quick
<zyga-ubuntu> mvo: skunkworks project to rewrite that +1
<zyga-ubuntu> mvo: just not in go (we cannot)
<mvo> zyga-ubuntu: no go because of the setns issues?
<zyga-ubuntu> mvo: so, this is interesting: on bare metal I don't see that problem: http://pastebin.ubuntu.com/26123995/
<mvo> with threading and all that
<zyga-ubuntu> mvo: not only setns but yes
<zyga-ubuntu> mvo: 1thread requirement
<zyga-ubuntu> mvo: the fact that / is mounted from initramfs and then core is mounted again from userspace is also a bit annoying but I don't know if it's worth fixing
<zyga-ubuntu> http://pastebin.ubuntu.com/26123999/ <- core snap mounted twice
<mvo> zyga-ubuntu: yes
<mvo> pedronis: new core snap in edge should have the configure-snapd fix now, I did a bit of manual handholding
<zyga-ubuntu> mvo: also interesting: http://pastebin.ubuntu.com/26124012/ the two snaps we mount from initramfs are mounted as _writable_ and not as auto-clear
<zyga-ubuntu> mvo: the auto clear is probably irrelevant but the writable bit should have never been set
<zyga-ubuntu> mvo: this allows an attacker to write to loop0 and change the squashfs bits
<mvo> zyga-ubuntu: aha, that should be an easy fix, one minute
<mvo> zyga-ubuntu: http://paste.ubuntu.com/26124029/
<zyga-ubuntu> mvo: +1
<zyga-ubuntu> mvo: every time I look at that pile if shell I feel bad
<mvo> zyga-ubuntu: yeah, makes me want to scrub myself
<zyga-ubuntu> mvo: can you fix inconsistent tabs/spaces
<mvo> zyga-ubuntu: anyway, lets see what we can do to fix things
<zyga-ubuntu> mvo: if you are going to make changes there
<pedronis> mvo: thank you, refresh to it now worked
<zyga-ubuntu> mvo: I'll check other systems, I don't understand if the brokenness I saw is specific to spread
<mvo> pedronis: yay
<mup> Issue snapcraft#1702 closed: Apply guidelines from design to error messages with reasons for errors <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1702>
<mup> PR snapcraft#1640 closed: cli: add what, why, and how to fix to the common errors <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1640>
<pstolowski> pedronis, hey, can you take a look and weight on #4301? I've addressed the last bit from Gustavo (AttrGetter -> Attrer renaming), but aparently he didn't manage to re-review yesterday, would be good to land it as it's a prerequisite for others
<mup> PR #4301: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <https://github.com/snapcore/snapd/pull/4301>
<zyga-ubuntu> mvo: and btw, I don't see any use of pivot_root
<zyga-ubuntu> mvo: is it hidden somewhere or are we just missing it?
<mvo> zyga-ubuntu: I think I may misrember actually
<mvo> zyga-ubuntu: now that I look at the code its less clear to me what is going on
<pedronis> pstolowski: will look in  a bit
<zyga-ubuntu> mvo: I'll check dragon and I'll get an amd64 image for qemu
<mup> PR core-build#24 opened: ubuntu-core-rootfs: mount os/kernel snaps RO <Created by mvo5> <https://github.com/snapcore/core-build/pull/24>
<mup> Issue snapcraft#1663 closed: patchelf with common rpath (not runpath) <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1663>
<mup> PR snapcraft#1781 closed: many: set rpath for elf files for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781>
<zyga-ubuntu> mvo: can you test your PR in practice and see that losetup --json shows it's correct then?
<zyga-ubuntu> mvo: a manual test if you can do that
<zyga-ubuntu> mvo: I approved the PR already
<zyga-ubuntu> mvo: we really have to rewrite mount units
<zyga-ubuntu> mvo: on dragon I see three generation of mount files we write
<zyga-ubuntu> mvo: a simple rewrite that fixes things for next boot would be good
<zyga-ubuntu> mvo: uh, my mistake, I was blinded by odd double-sided print
<zyga-ubuntu> mvo: stop looking for double / :)
<zyga-ubuntu> mvo: so now I'm back to square one, what is wrong there :/
<mvo> zyga-ubuntu: rewrite fix is still needed? or should I also scratch that?
<mup> PR snapd#4363 opened: cmd/snap-mgmt: add more directories for cleanup and refactor purge() code <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4363>
<mvo> zyga-ubuntu: rewriting with the before=snapd.servie?
<zyga-ubuntu> mvo: no, that is still needed
<zyga-ubuntu> mvo: that should have been there forever
<mvo> zyga-ubuntu: ok, but "just" that - or do we need more rewrite?
<zyga-ubuntu> mvo: not sure I understand the difference; we need to be able to rewrite mount units and and we ought to rewrite mount units in the field to correct for past mistakes
<mvo> zyga-ubuntu: we are in agreement, I was wondering if there is a new bug that requires us to rewrite them
<zyga-ubuntu> aha, sorry for being confusing then
<mvo> zyga-ubuntu: I will have a look. no worries, communication is hard :)
<mvo> (it always is!)
<zyga-ubuntu> mvo: the pastebin I sent you, I was holding it wrong, litteraly :)
<zyga-ubuntu> I looked at head of both inside and outside parts
<mvo> zyga-ubuntu: heh
<mvo> zyga-ubuntu: we have 256 files in etc and var in my base-18 WIP snap :/ there is quite some work to get rid of those if we want to get rid of the writable-path magic
 * mvo gets to work
<zyga-ubuntu> mvo: where do you do this work?
<zyga-ubuntu> mvo: I'd love a new repo for base-18
<mvo> zyga-ubuntu: lp:snap-base-18
<mvo> zyga-ubuntu: so far very minimal/experimental/WIP but its a start
<zyga-ubuntu> bzr or git?
<mvo> zyga-ubuntu: git
<mvo> zyga-ubuntu: what is bzr?
<zyga-ubuntu> hhaha
 * zyga-ubuntu checks how to clone from launchpad
<mvo> zyga-ubuntu: https://github.com/snapcore/base-18 :P
 * mvo is afk for some minutes
<zyga-ubuntu> mvo: so is it on launchpad or github?
<zyga-ubuntu> mvo: I've started sending PRs
<brunosfer> Hi guys, does anyone know how can I enable the driver from bluetooth on the Raspberry Pi with Ubuntu snappy core?
<zyga-ubuntu> brunosfer: it should already be enabled,
<mvo> zyga-ubuntu: github
<zyga-ubuntu> ok
<zyga-ubuntu> mvo: I send one trivial PR
<zyga-ubuntu> mvo: how do you test/use this?
<zyga-ubuntu> mvo: one more
<mvo> zyga-ubuntu: well, I build a snap :) thats all there is for tests so far
<mvo> zyga-ubuntu: good stuff, thank you!
<zyga-ubuntu> mvo: ha, well, I didn't think of that :)
<mvo> zyga-ubuntu: but yeah, its a good question, we need more automation and travis and all that here
<zyga-ubuntu> mvo: snapcraft fails, did you run it via fakeroot?
<mvo> zyga-ubuntu: yes, it needs to run as root currently, I think fakeroot will work
<mvo> zyga-ubuntu: the LP builder runs it as real root
 * zyga-ubuntu tries fakeroot snapcraft
<mvo> zyga-ubuntu: what is annoying is that in order to get to an empty /etc we need to undo the alternatives system i.e. awk which is provided via an alternative
<mvo> (and more, w, pager)
<zyga-ubuntu> hmm, we need real real root
<mvo> zyga-ubuntu: ok, I need to look into why, iirc because of chroot, right?
<mvo> zyga-ubuntu: *maybe* fakechroot works
<zyga-ubuntu> mvo: no, because of chroot
<zyga-ubuntu> mvo: anyway, that's fine,
<mvo> zyga-ubuntu: fakechroot may work
<zyga-ubuntu> mvo: just trying to see where this is going and what's in the snap
<mvo> zyga-ubuntu: I hope it goes into a minimal base that can boot and that works with an empty /etc/ /var so that we can do factory reset easily and don't need the writable-path hacks
<ogra_> why dont you just grab an ubuntu-base tarball from cdimage and modify it as needed ...
<mvo> ogra_: that would also be an option, right now it is using debootstrap to get that
<ogra_> (with a bit of fiddling oyu can even do that completely without chroot calls)
<ogra_> mvo, yeah i was guessing that ...
<ogra_> ubuntu-base is pretty much a minbase debootstrap though
<zyga-ubuntu> mvo: there's some things that should be easy to kill
<mvo> ogra_: indeed, interessting
<zyga-ubuntu> mvo: etc/selinux
<mvo> zyga-ubuntu: yeah /etc/{apt,dpkg}
<zyga-ubuntu> mvo: /etc/apt
<zyga-ubuntu> yeah
<zyga-ubuntu> mvo: /etc/kernel/install.d
<mvo> zyga-ubuntu: and some stuff we need to look at and upstream, i.e. if adduser.conf has different defaults than adduser itself we should ensure that gets fixed
<ogra_> just dont kill /usr/share/doc/<pkg>/copyrights.gz ...
<zyga-ubuntu> ogra_: make that a fuse https FS
<zyga-ubuntu> ;-)
<mvo> ogra_: yeah, no worries :)
<ogra_> :)
<mvo> ogra_: its mostly based on the current livecd-rootfs scripts
<mvo> ogra_: the new skeleton
<mvo> ogra_: but using a different "base"
<ogra_> yeah .. many of these scripts can also be dropped
<ogra_> we (I) didnt do a good job of throwing away old stuff thats not needed anymore
<ogra_> and some bits that live in ubuntu-core-config should rather move to the build scripts ... and vice versa ... someone should do an audit of all this
<mvo> ogra_: yeah, the work on this is (slowly) starting with base-18. unfortuantely quite a bit of work but at the same time exciting because of the cleanup potential
<ogra_> yep
<mvo>  /etc/bindresvport.blacklist <- why do i have this file in /etc :(
<ogra_> i'm still curious how it will work out ... but looking massively forward to have bases for commercial projects ... they will massively solve issues i'm running into since i started in the new team
<mvo> anyway,
<mvo> ogra_: fingers crossed, but I'm excited aboutt the opportunities, all sorts of crazy bases
<ogra_> yeah
<zyga-ubuntu> mvo: some more stuff in 3
<zyga-ubuntu> https://github.com/snapcore/base-18/pull/3
<mup> PR base-18#3: Document how to build the project locally, trim /etc, ignore build artefacts <Created by zyga> <https://github.com/snapcore/base-18/pull/3>
<zyga-ubuntu> mvo: do we need /etc/init.d?
<zyga-ubuntu> mvo: /etc/ld.so.conf.d/libc.conf also looks like something to remove
<zyga-ubuntu> mvo: /etc/logrotate.d/{alternatives,dpkg}
<zyga-ubuntu> mvo: /etc/profile.d
<zyga-ubuntu> mvo: /etc/rc[0-6S].d
<zyga-ubuntu> mvo: anyway, I think it would be fantastic if we had a way to kvm-boot this for testing
<zyga-ubuntu> mvo: take a kernel snap, base-18 and gadget and boot it some way for very fast iteration
 * kalikiana coffee break
<kalikiana> okay, that was a lie, I ended up making tea
 * zyga-ubuntu wonders when we will see snaps on windows 3.11 http://assets.metacade.com/emulators/win311vr.html
<cachio_> mvo, hey
<cachio_> mvo, The changelog for 2.30 rc2 doesn't contain the 2.29.4.2 changes
<cachio_> mvo, is it ok? are those changes included?
<mvo> cachio_: thanks for catching that, I will double check
<cachio_> mvo, apart of that I have seen some issues during the execution
<mvo> zyga-ubuntu: thanks! yeah, I think that must be the goal, right now the initramfs stuff cannot boot bases - just core
<mvo> cachio_: tell me more, you mentioned yesterday that the install-cache test fails ?
<cachio_> mvo, yes
<cachio_> and the error seems to be genuine
<cachio_> mvo, similar issue for catalog-update
<cachio_> mvo, https://paste.ubuntu.com/26120827/
<cachio_> this is a reexec in pi3 for all the errors that I saw
<cachio_> some of them are test errors, I am working on fixing them
<mvo> cachio_: for the cache-install failure, does that happen just on arm or on any core device?
<cachio_> mvo, it was in any core device
<cachio_> both tests failed in any core device
<cachio_> the install-cache and the catalog-update
<cachio_> mvo, I have to go to the doc now
<cachio_> I'll be back for the standup
<mvo> cachio_: thanks, I need to dig into this then, I was not able to reproduce it from a release/2.30 git checkout and running spread from there, sounds like I need to create an image first
<mvo> cachio_: sure, see you. and thanks for the update
<cachio_> mvo, np
<sergiusens> hello everyone
<zyga-ubuntu> hey sergiusens
<zyga-ubuntu> sergiusens: what's the weather like where you live?
<mborzecki> i bet it's better than here
<mvo> zyga-ubuntu: why do you ask?
<zyga-ubuntu> mvo: ?
<zyga-ubuntu> just curious
<mvo> zyga-ubuntu: I was wondering if you want to fly there ;)
<sergiusens> zyga-ubuntu non deterministic
<ogra_> zyga-ubuntu, definitely better than yours :)
<sergiusens> zyga-ubuntu https://www.facebook.com/photo.php?fbid=10159702028205367&set=a.10154038137770367.1073741826.844960366&type=3&theater
<sergiusens> it might rain, it might not; it might get cooler (like 18), it is 25 now, and it might also go up to 39
<ogra_> what did you do to your knee ?
<sergiusens> depends on if i decides to rain
<sergiusens> ogra_  https://en.wikipedia.org/wiki/Chondromalacia_patellae
<ogra_> ouch
<Chipaca> sergiusens: nene, eso no se hace! :-(
<mborzecki> hmm tarvis jobs mostly timing out today?
<zyga-ubuntu> mborzecki: sad travis day
<zyga-ubuntu> I'm working entirely locally
<kalikiana> btw sergiusens I tried out the slot feature in the calendar. Can you see any difference on your end? I'm not sure if it handles regular appointments correctly. You should see at least one 'unavailable' slot tomorrow.
<mup> PR snapd#4362 closed: interfaces: update fixme comments <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4362>
<mup> PR snapd#4301 closed: interfaces: PlugInfo/SlotInfo/ConnectedPlug/ConnectedSlot attribute helpers <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4301>
<mborzecki> #4354 needs a 2nd review
<mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
<mcphail> hi. does the automated github build service only build from the master branch, or do all branches get built?
<zyga-ubuntu> mcphail: hey, do you mean on build.snapcraft.io?
<mcphail> yes, zyga-ubuntu
<kalikiana> lunch time
<zyga-ubuntu> mcphail: ah, I don't know what's the state of that, sorry
<mcphail> zyga-ubuntu: ok, thanks
<sergiusens> ogra_ is there an amd64 Ubuntu Core image for download?
<ogra_> sure
<zyga-ubuntu> sergiusens: yes
<ogra_> sergiusens, http://cdimage.ubuntu.com/ubuntu-core/16/
<ogra_> pick your channel
<zyga-ubuntu> sergiusens: http://paste.ubuntu.com/26125012/
<sergiusens> kalikiana slots are interesting new concept in the calendar, but I think it is more of a thing for another person to click to get a slice of your time
<ogra_> note that this is zero padded for better use with kvm though (unlike the other arches)
<zyga-ubuntu> sergiusens: make boot; make login
<sergiusens> kind of like a doctor's appointment thing
<sergiusens> ogra_ zyga-ubuntu thanks, I won't be needing any of the automation, it is for a potential demo at the IoT meetup I am presenting at today
<zyga-ubuntu> sergiusens: this is not much automation, just remembers the URL and the long command
<zyga-ubuntu> mvo: btw, why are you using >100 hook numbers?
<zyga-ubuntu> mvo: sad
<zyga-ubuntu> zyga@kaedwen:~/snap-base-18$ grep -R bindresvport.blacklist .
<zyga-ubuntu> Binary file ./prime/lib/x86_64-linux-gnu/libc-2.26.so matches
<zyga-ubuntu> Binary file ./prime/lib/x86_64-linux-gnu/libc.so.6 matches
<mvo> zyga-ubuntu: well, we can patch that
<zyga-ubuntu> mvo: yes but I find it just sad
<mvo> zyga-ubuntu: +100
<zyga-ubuntu> mvo: /etc/letmecallthisfilethatIreallylikeanduseitfromlibc
<sergiusens> zyga-ubuntu I just noticed it is a makefile, it does look useful!
<zyga-ubuntu> :)
<sergiusens> ogra_ zyga-ubuntu does stable have subiquitty and all that or should I go and get something like candidate or edge?
<zyga-ubuntu> sergiusens: it has all that stsuff
<zyga-ubuntu> *stuff
<ogra_> all of them have subiquity
<Chipaca> mvo: http://paste.ubuntu.com/26123959/ and http://paste.ubuntu.com/26123957/
<zyga-ubuntu> mvo: https://github.com/snapcore/base-18/pull/5
<mup> PR base-18#5: More etc cleanups and reporting <Created by zyga> <https://github.com/snapcore/base-18/pull/5>
<zyga-ubuntu> ls
<zyga-ubuntu> mvo: do we need to keep empty things for later bind mounts or can this be added at a later stage
<zyga-ubuntu> mvo: I'd like to make it so that we know we're done with /etc cleanups
<zyga-ubuntu> mvo: and that the rest is actually desired
<mvo> zyga-ubuntu: lets kill the empty ones too
<mvo> zyga-ubuntu: if we are successful there will be no bind mounts
<zyga-ubuntu> mvo: I'll tweak things so that we can boot-test this
<mup> PR snapd#4359 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4359>
<mup> PR snapd#4350 closed: debian: make "gnupg" a recommends <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4350>
<mvo> zyga-ubuntu: sounds good, maybe its enough to make it "type: os" to be able to test install it
<mvo> zyga-ubuntu: it will not properly run because it lacks snapd but its might be enough to get to the console
<mvo> zyga-ubuntu: but probably some initrd hacking is required, hopefully not much
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: fingers crossed
<zyga-ubuntu> mvo: actually may be even easier
<sergiusens> elopio already around?
<zyga-ubuntu> mvo: some progress, getting over last initrd hurdle
<kalikiana> sergiusens: Yeah, I might just go back to using regular events. It looked like slots would help with scheduling meetings, but it doesn't seem to be meant for that
 * kalikiana back from lunch
<cachio_> jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3
<cachio_> jdstrand, I am researching a bit to understand why
<cachio_> jdstrand, hey, the test security-device-cgroups-serial-port is failing in the pi2 and 3
<cachio_> jdstrand, https://paste.ubuntu.com/26125367/
<cachio_> jdstrand, any idea what I can't get info from  /dev/ttyS4?
<mup> PR core#66 opened: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <https://github.com/snapcore/core/pull/66>
<mup> PR snapd#4364 opened: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <https://github.com/snapcore/snapd/pull/4364>
<mborzecki> cachio_: maybe there is no device behind /dev/ttyS4, even though the node is there
<pstolowski> zyga-ubuntu, ^ this is the other follow-up that addresses your comment from previous PR
<zyga-ubuntu> pstolowski: thanks; looking
<zyga-ubuntu> pstolowski: why not pass the slot directly?
<zyga-ubuntu> pstolowski: not a big deal, just curiou
<pstolowski> zyga-ubuntu, because the function is used for both SlotInfo and ConnectedSlot
<zyga-ubuntu> ahh
<zyga-ubuntu> ok
<zyga-ubuntu> +1
<pstolowski> thx
<Chipaca> grmbl!
<mborzecki> cachio_: there seem to be only 2 serial ports listed in rpi3 dts files, these should map to /dev/ttyS0 and S1 and udev should list those, 2 and above have no real devices so even if the node is there it won't work and udev will now know about it
<mborzecki> s/now/not/
<zyga-ubuntu> Chipaca: hmm?
 * zyga-ubuntu moves an inch foward
<Chipaca> zyga-ubuntu: I just lost the output of half an hour of debugging this because for some reason the fiddling around that spread does results in the thing not letting you ssh in
<Chipaca> nor log in at all actually
<zyga-ubuntu> Chipaca: is that locally or over linode?
<Chipaca> locally
<Chipaca> qemu
<zyga-ubuntu> hmm
<zyga-ubuntu> on core?
<Chipaca> zyga-ubuntu: classic
<zyga-ubuntu> and you don't have qemu console, do you?
<Chipaca> zyga-ubuntu: yes i do
<Chipaca> you can telnet to it
<Chipaca> e.g. 2017-12-06 14:38:43 Serial and monitor for qemu:ubuntu-14.04-64 available at ports 59479 and 59579.
 * mvo added those
<Chipaca> (the serial has a getty, but that didn't let me log in once spread had started)
<Chipaca> i need to ssh in before the 'preparing' phase is done
<zyga-ubuntu> Chipaca: hmm
<zyga-ubuntu> sorry :/
<zyga-ubuntu> I was thinking about saving a snapshot
<zyga-ubuntu> and extracting stuff from that image
<Chipaca> zyga-ubuntu: tried that, but apparently snapshot_blkdev doesn't work well together with -snapshot
<Chipaca> Could not open '/var/tmp/vl.MGVYHB': No such file or directory
<zyga-ubuntu> Chipaca: you can save that snapshot
<zyga-ubuntu> Chipaca: it is documented in the qemu manual somewhere
<zyga-ubuntu> Chipaca: it talks about running qemu with -snapshot and then giving it a real name in the monitor
<Chipaca> ah, buh
<Chipaca> i'll try that if i get stuck like this again
<cachio_> mborzecki, well the test is creating this device in case there is not one
<cachio_> mborzecki, perhaps for the pi3 we shuould create it in a different way
<mborzecki> cachio_: it's creating a node, that does not mean yet there's a device, and udev knows about devices only
<mborzecki> can you try ttyS1 on rpi?
<mvo> Chipaca: did you try to login via test:ubuntu?
<Chipaca> mvo: ubuntu:ubuntu
<cachio_> mborzecki, in my pi3 there is not a /dev/ttyS1
<mvo> Chipaca: you said the getty wouldn't let you login after spread has started, iirc we change the setup and add test:ubuntu as a user. I was wondering if that might work to login in the getty
<cachio_> I created a node for /dev/ttyS1
<Chipaca> mvo: i'll try
<cachio_> mborzecki,  and I have the same problem when I do "udevadm info --path=/dev/ttyS1"
<cachio_> I get syspath not found
<Chipaca> mvo: ubuntu:ubuntu logs in and is immediately logged out again
<Chipaca> mvo: test:ubuntu gets login incorrect
<mvo> Chipaca: :( ok
<Chipaca> but thanks to zyga mentioning auditd, i now have logs that are different \o/
<Chipaca> http://pastebin.ubuntu.com/26125591/
<zyga-ubuntu> woot!
<Chipaca> jdstrand: hiya. I have some rather messed up shenanigans going on in 14.04 that i'd like to understand if possible
<cachio_> mborzecki, which pi do you have?
<mborzecki> cachio_: you can try dumping udev db and checking if there's anything suitable
<cachio_> mborzecki, sure
<mborzecki> cachio_: i fried the last one i had :)
<Chipaca> jdstrand: i now have an audit log :-) in both the "everything dies" case, and the less interesting "everything abstains from dying"; the difference is the existence of a file, and the thing that triggers the dying is doing ls on the directory that contains the file, as a user that shouldn't be able to list that directory
<cachio_> mborzecki, https://paste.ubuntu.com/26125620/
<mborzecki> cachio_: where can i find the dtb that you use?
<cachio_> mborzecki, dtb?
<mborzecki> cachio_: what image do you have installed there and can i get it somewhere?
<cachio_> device tree?
<cachio_> mborzecki, you need to build it
<cachio_> mborzecki, download https://github.com/sergiocazzolato/validator
<cachio_> and then you do "./create.sh beta pi3"
<cachio_> it is gonna create the beta image
<cachio_> if you have pi2, "./create.sh beta pi2"
<cachio_> mborzecki, then you can use that image that is the same we use for beta validation
<mborzecki> cachio_: it is pi2 or pi3 you're using now?
<cachio_> pi3
<cachio_> mborzecki, I am gonna lunch now, I'll be back
<cachio_> mborzecki, export SPREAD_EXTERNAL_ADDRESS=<device ip>
<cachio_> spread -v -debug external:ubuntu-core-16-arm-32:tests/main/security-device-cgroups-serial-port
<cachio_> this is to reproduce the issue
<mup> Issue snapcraft#1733 closed: Apply guidelines from design to error messages with commands that fix <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1733>
<mup> PR snapcraft#1790 closed: cli: include consistent commands to fix error conditions <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1790>
<mvo> zyga-ubuntu: review for https://github.com/snapcore/core/pull/66 would be great
<mup> PR core#66: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <https://github.com/snapcore/core/pull/66>
<zyga-ubuntu> mvo: sure
<zyga-ubuntu> done
<zyga-ubuntu> also restarted tests
<mvo> zyga-ubuntu: ta
<jdstrand> cachio_: so, you are do a mknod, but that isn't sufficient to make the device show up to udev and be exposed in sysfs
<ikey> jdstrand, sorry for not replying to your apparmor comments there the other day - just letting you know i saw em, cheers :]
<jdstrand> cachio_: there is no hardware behind that device file, so the kernel didn't do a uevent for udev to do its thing
<jdstrand> ikey: cool! I also mentioned it to jj, so if he didn't followup, feel free to ping him directly
<ikey> aye :]
<ikey> had a mild rebase to do today with 4.14.4 due to some audit.h changes
<ikey> nothing too difficult tho
<jdstrand> cachio_: and therefore nothing works
<jdstrand> ikey: cool
<mup> PR snapcraft#1796 opened: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
<jdstrand> Chipaca: hey. I understood what you communicated, but don't feel like I have enough context to effectually respond
<jdstrand> Chipaca: do you have a snap and instructions that demonstrates the issue?
<zyga-ubuntu> mvo: what is going on here: https://travis-ci.org/snapcore/core/builds/312446771?utm_source=github_status
<mborzecki> cachio_: iirc both 2 and 3 have 2 uarts, i tried to download the kernel you might use (4.4.0-1009-raspi2?), then dtb for rpi2 lists the 2nd uart as disabled, the one for rpi3 lists both uarts as ok, IMO it's best if you check dmesg and look in /sys/devices/platform to see if the devices are there
<Chipaca> jdstrand: I haven't been able to reproduce it outside of a in-progress branch (it's up as a PR, but fails)
<mvo> zyga-ubuntu: I don't know :/
<zyga-ubuntu> what is /var/lib/snapd/environment?
<Chipaca> zyga-ubuntu: a directory (?)
<zyga-ubuntu> sure but what is it for?
<Chipaca> zyga-ubuntu: I hope it's something we no longer use, as opposed to a random directory
<Chipaca> i'm seeing it in the packaging but have no idea
<zyga-ubuntu> yeah
<zyga-ubuntu> I'm seeing it in booted images
<mup> PR snapcraft#1797 opened: tests: update the snap name already registered for store tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1797>
<mup> PR snapd#4365 opened: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
<cachio_> jdstrand, ok, so we should skeep the test execution in that case
<cachio_> I mean, in case "udevadm info /dev/ttyS4" failes
<cachio_> jdstrand, then we exit
<cachio_> jdstrand, is it ok if I make that change?
<geekgonecrazy> Hey guys, Is anyone aware of any issues with the node part? Have our rocketchat-server snap setup to build on launchpad, but keeps failing after downloading node part.  Only thing that has changed between last version and this the location we download our rocket.chat bundle - https://launchpadlibrarian.net/347779291/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz  Any ideas?
<geekgonecrazy> Looks like its failing right as it finishes downloading the part
<geekgonecrazy> ```
<geekgonecrazy> Downloading ''   0%                                                             Traceback (most recent call last):   File "/usr/bin/snapcraft", line 9, in <module>
<Chipaca> geekgonecrazy: the error is âIsADirectoryError: [Errno 21] Is a directory: '/build/stable/parts/rocketchat-server/src/'â
<Chipaca> geekgonecrazy: looks like it expects a file but it's a directory
<geekgonecrazy> Chipaca: yeah I see that, but seems to happen after the initial exception.
<geekgonecrazy> Has something changed in snapcraft?  Here is my changeset between versions.  Why would this start now? https://git.launchpad.net/rocket.chat/commit/?h=stable&id=6682e7d79762d4cd1f0957845f35932fea563a92
<Chipaca> geekgonecrazy: that's the last line of the initial exception, ie the bit that triggered it (the rest is the stack)
<Chipaca> it goes up, not down
<geekgonecrazy> i'm used to js stacks hehe.  My python experience is probably enough to be dangerous :D
<Chipaca> if that's the diff between your thing not working and your thing working, i think you're right to suspect snapcraft itself
<Chipaca> sergiusens, ^
<geekgonecrazy> Chipaca: Yeah that's why I wondered if the part was messed up mainly because it stops right there. But if the workers are using newer versions of snapcraft that change could be the fault as well
<mup> PR snapd#4366 opened: interfaces/removable-media: also allow 'k' (lock) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4366>
<mup> PR snapd#4367 opened: interfaces/removable-media: also allow 'k' (lock) for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4367>
<geekgonecrazy> spinning up a clean VM, i'll see if I can hack past it locally.  We cut release a few days back and hadn't had time to debug it.  Hoped it was a launchpad issue that would resolve its self :P
<kalikiana> kyrofa: would you be up for a hangout? to talk about the unmet dependencies
<kyrofa> kalikiana, yep, perfect timing
<jdstrand> cachio_: sounds reasonable to me
<kyrofa> geekgonecrazy, to be clear, you only see that in LP? Not locally?
<cachio_> jdstrand, ok, I'll create a PR for that
<kyrofa> kalikiana, want to just use the weekly?
<kalikiana> kyrofa: sure
<geekgonecrazy> kyrofa: i'm double checking to see if that's the case now.  Gotten spoiled by launchpad and our ci just working.  :)
<geekgonecrazy> kyrofa: ok I suppose good news is it happens locally. :)
<mup> PR snapd#4368 opened: tests: fix security-device-cgroups-serial-port test for rpi and db <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4368>
<geekgonecrazy> kyrofa: might it have something to do with there being a redirect involved in the file download?
<zyga-ubuntu> woot
<zyga-ubuntu> fafasafafsaj
<zyga-ubuntu> my keyboard has gone crazy
<zyga-ubuntu> mvo: we ccccccccccccc
<zyga-ubuntu> anc now test ocre rsnaps
<zyga-ubuntu> faak
 * zyga-ubuntu reboots
<mup> PR snapd#4369 opened: add write permission to optical-drive interface <Created by diddledan> <https://github.com/snapcore/snapd/pull/4369>
<diddledan> aww, and here I was thinking someone wanted me :-p
<zyga-ubuntu> diddledan: +1
<diddledan> thankyou :-)
 * diddledan feels clever now that I've looked at snapd code
<kyrofa> geekgonecrazy, sorry, was in a meeting there for a few minutes
<kyrofa> Yes, the fact that you get it locally is good indeed! Troubleshooting on LP is no fun :D
<diddledan> and then I feel less clever now I spot I wrote BluRay differently each time I said it
<zyga-ubuntu> mvo: I can now boot our base-18 snaps
<zyga-ubuntu> mvo: it says "welcome to ubuntu core 18" :-)
<kyrofa> geekgonecrazy, being due to a redirect seems odd
<zyga-ubuntu> mvo: I think we need to drop a rule that gives us a getty on tty2
<kyrofa> That would surprise me
<zyga-ubuntu> mvo: anyway, let me clean this up and send a PR
<kyrofa> geekgonecrazy, I suspect now that you're able to reproduce locally you'll be able to figure out the cause, but do let me know if you want some help
<kalikiana> diddledan: clearly you need to open lots more snapd PRs and feel the love of snapd's attention :-D
<diddledan> :-)
<geekgonecrazy> kyrofa yup seems due to redirect.  :( wonder if it only follows certain redirects? I now have a very ugly looking prepare statement
<kyrofa> geekgonecrazy, any chance you could share the URL?
<geekgonecrazy> `prepare: curl -SLf "https://releases.rocket.chat/0.59.6/download/" -o rocket.chat.tgz; tar xvf rocket.chat.tgz --strip 1; cd programs/server; npm install; cd npm/node_modules/meteor/rocketchat_google-vision; npm install grpc` is what my prepare now looks like o.O
<kyrofa> geekgonecrazy, also, I assume this is something that's changed recently?
<kyrofa> Yikes
 * kalikiana preparing to wrap up for the day
<kyrofa> geekgonecrazy, so to be clear: you're saying using source: https://releases.rocket.chat/0.59.6/download is what breaks?
<geekgonecrazy> kyrofa: we've had a redirect of some sort in place for a good while I think... i'll have to look back and verify
<geekgonecrazy> kyrofa: yes fails fast and hard with that as source and source-type: tar
<kyrofa> geekgonecrazy, huh. This works for me: http://paste.ubuntu.com/26126334/
<kyrofa> Although I'm on snapcraft master. What are you using locally?
<geekgonecrazy> kyrofa: snapcraft, version 2.35
<cachio_> mvo, the snapd.refresh.timer does not exist on pi3, https://paste.ubuntu.com/26126388/
<kyrofa> geekgonecrazy, and does that YAML I pasted break for you?
<cachio_> it is making the test ubuntu-core-services fail
<geekgonecrazy> kyrofa: it downloads, throws exception at the end i'm guessing because it doesn't know source type is a tar
<geekgonecrazy> here is what our snapcraft yaml looked like before my hack around: https://git.launchpad.net/rocket.chat/tree/snapcraft.yaml?h=stable&id=945e4f912f0d5d9dc7416e2998f710da46f1755c
<geekgonecrazy> might be related to the prepare there?
<kyrofa> geekgonecrazy, huh, interesting. No exception for me. I'll try 2.35
<kyrofa> geekgonecrazy, prepare effects the build step, not pull
<kyrofa> I still get no issues with 2.35
<geekgonecrazy> kyrofa: thats what I thought.  :D
<zyga-ubuntu> mvo: https://github.com/snapcore/base-18/pull/8
<mup> PR base-18#8: Add rudimentary testing infrastructure <Created by zyga> <https://github.com/snapcore/base-18/pull/8>
<diddledan> zyga-ubuntu: base-18 sounds like weird counting to me.. base-16 works well with computers :-p
<zyga-ubuntu> diddledan: wait till base-20
<diddledan> :-o
<geekgonecrazy> kyrofa: interesting.. Some how I get same error as launchpad and launchpad I assume is building in lxd for clean builds
<diddledan> so with base-16 we count 0 thru F. what are we gonna do with base-20?!
<Chipaca> diddledan: base-85 is a thing
<Chipaca> jus' sayin'
<diddledan> drak me
<diddledan> frak*
<diddledan> that's crazy numbers
<Chipaca> diddledan: also called Ascii85, it's in python and go's stdlibs
<diddledan> ee gads
<diddledan> avoid it like the plague!
<diddledan> I'm guessing it's used for crypto symbolism
<diddledan> similarly to base64
<Chipaca> diddledan: PDFs use it
<Chipaca> diddledan: as does Postscript
<diddledan> oh, well when Adobe are involved all bets are off :-p
<Chipaca> diddledan: also ZeroMQ and ZMODEM
<Chipaca> there's also an ascii85 representation of ipv6 addresses
<Chipaca> (just, what, no)
<diddledan> if 0mq uses it then I guess htey've ported it to many programming languages
<zyga-ubuntu> so
<Chipaca> when you see â4)+k&C#VzJ4br>0wv%Yâ on your terminal your first thought is "oh crap something bought it", not "ah, good old 1080:0:0:0:8:800:200C:417A"
<zyga-ubuntu> I need a hand
<zyga-ubuntu> how do add a simple root shell systemd unit?
<zyga-ubuntu> no login, just #
<zyga-ubuntu> on tty2 ideally
<Chipaca> zyga-ubuntu: don't you want the emergency shell?
<zyga-ubuntu> Chipaca: I want _a_ shell
<diddledan> zyga-ubuntu: get it to run getty?
<zyga-ubuntu> whatever you do :)
<Chipaca> zyga-ubuntu: that gives you a root shell on tty9 (iirc), from early boot
<zyga-ubuntu> I need an answer in terms on systemd units
<Chipaca> zyga-ubuntu: systemd.debug-shell=1 on the kernel commandline
<zyga-ubuntu> ahh
<zyga-ubuntu> perfect
<Chipaca> zyga-ubuntu: or systemctl enable debug-shell.service if you'd rather that
<zyga-ubuntu> now
<zyga-ubuntu> how do I move ttys in qemu?
<Chipaca> zyga-ubuntu: ctrl-alt-left or -right
<Chipaca> is the easiest way imo
<zyga-ubuntu> nope
<zyga-ubuntu> doesn't work
<zyga-ubuntu> do I need some fancy option for GUI?
<zyga-ubuntu> Chipaca: I clicked on the qemu window
<Chipaca> zyga-ubuntu: you're in the gui, yes?
<zyga-ubuntu> (so that it woud catch my input)
<zyga-ubuntu> then tried the combo
<zyga-ubuntu> maybe it uses it to release
<Chipaca> zyga-ubuntu: does it say your keyboard is captured?
<zyga-ubuntu> the title changes
<Chipaca> ah
<zyga-ubuntu> says use alt-ctrl to escape
<Chipaca> 1 sec
<zyga-ubuntu> (ctrl-alt)
<Chipaca> zyga-ubuntu: i had to bring a qemu up to remember
<Chipaca> it's in muscle memory
<Chipaca> zyga-ubuntu: just alt-left or -right
<Chipaca> no ctrl
<diddledan> if you do need to build one yourself, the exec= line would be `getty -n tty2`
<zyga-ubuntu> Chipaca: no change
<zyga-ubuntu> Chipaca: I don't get anything
<Chipaca> zyga-ubuntu: lies
<Chipaca> :-)
<zyga-ubuntu> Chipaca: wanna see?
<Chipaca> zyga-ubuntu: yes
<zyga-ubuntu> I'll gladly hangout it
<zyga-ubuntu> one sec
<zyga-ubuntu> Chipaca: in standup
<Chipaca> omw
<Chipaca> reasons wayland is not "there" yet #(++n)
<Chipaca> zyga-ubuntu: that's from https://freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell FWIW
<zyga-ubuntu> Chipaca: thanks
<zyga-ubuntu> if anyone wonders what was wrong, wayland and qemu still don't work well
<Chipaca> zyga-ubuntu: <Chipaca> reasons wayland is not "there" yet #(++n)
<Chipaca> (from just before you logged back on)
<Chipaca> n--
<Chipaca> :-)
<zyga-ubuntu> hehe
<zyga-ubuntu> mvo: teaser https://twitter.com/zygoon/status/938464408610754562
<sergiusens> geekgonecrazy are you behind a proxy? kyrofa I assume you are not
<kyrofa> Indeed I am not
<kyrofa> But LP is, of course
<sergiusens> kyrofa yeah, that might be the commonality
<kyrofa> Yeah interesting idea
<zyga-ubuntu> kyrofa: when does a make plugin detect that it is out of date
<zyga-ubuntu> kyrofa: I have a make-based project
<zyga-ubuntu> kyrofa: I keep changing things and snapcraft thinks it's all up-to-date
<kyrofa> zyga-ubuntu, only when something in the yaml changes
<zyga-ubuntu> kyrofa: and then re-squahses stuff
<zyga-ubuntu> kyrofa: why? you can ask make
<zyga-ubuntu> kyrofa: you have all the part lifecycle stuff
<zyga-ubuntu> kyrofa: make -n
<zyga-ubuntu> or perhaps -q
<zyga-ubuntu> (yes -q)
<zyga-ubuntu> given that this is a network-heavy part I just keep wasting time because it's too silly to make again
<kyrofa> zyga-ubuntu, a few different reasons. First of all, snapcraft doesn't build the source you hand it directly. During the pull step it copies it into the area it controls. So make doesn't see any changes
<cachio_> pedronis, we have a test failing in rpi
<cachio_> pedronis, it fails doing > snap ack "$TESTSLIB/assertions/testrootorg-store.account-key"
<cachio_> error: cannot assert: assert failed: cannot find account (testrootorg)
<pedronis> it's probably missing a skip
<pedronis> we cannot run some tests if it's a real snapd
<cachio_> any idea why it could fail just on rpi and dragonboards?
<pedronis> (no test keys)
<pedronis> it's telling you this a real snapd, not a test build one
<sergiusens> kyrofa elopio I haven't seen any comment on https://github.com/snapcore/snapcraft/pull/1796
<mup> PR snapcraft#1796: Changelog for release 2.37 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
<pedronis> s/real/prod/
<kyrofa> zyga-ubuntu, also, while make supports discovering changes, not all build systems are as nice, as we haven't developed a generic method that works for all plugins
<cachio_> pedronis, ah, ok
<cachio_> what should I check to skip it?
<kyrofa> zyga-ubuntu, that's not to say we don't want to get there, but it's a good chunk of work
<pedronis> cachio_: well we have TRUST_TEST_KEYS or something like that?
<pedronis> maybe you are not setting it properly?
<kyrofa> Also, snapcraft is a packaging tool. It isn't best-suited to being so tightly in the development loop
<pedronis> or the test doesn't have the check yet
<cachio_> TRUST_TEST_KEYS are true
<pedronis> cachio_: you cannot set it to true if you are using a prod snapd
<pedronis> it doesn't have the keys
<zyga-ubuntu> kyrofa: this makes sense, thank you for explaining
<cachio_> pedronis, mmm, well something else is setting that var to true
<cachio_> pedronis, I am not setting it
<kyrofa> Of course
<kyrofa> sergiusens, oh man, I missed it go up!
<pedronis> cachio_: true is the default
<pedronis> you need to set to false yourself
<pedronis> if I understand
<zyga-ubuntu> kyrofa: is there some way to ask snapcraft to use fast compression?
<pedronis> SPREAD_TRUST_TEST_KEYS=false
<zyga-ubuntu> kyrofa: especially for test snaps
<zyga-ubuntu> kyrofa: that are not sent anywhere
<cachio_> pedronis, ok, I'll take a look to that
<kyrofa> zyga-ubuntu, honestly I'm not sure what that means :P
<kyrofa> zyga-ubuntu, you mean for the squashfs image?
<zyga-ubuntu> kyrofa: call mksquashfs without compression
<cachio_> pedronis, in the spread.yaml it is using TRUST_TEST_KEYS: "false"
<kyrofa> zyga-ubuntu, no, it's hard-coded to xz etc. to make the store happy
<cachio_> but just for ubuntu-core-16-64 and ubuntu-core-16-32
<kyrofa> zyga-ubuntu, but you could hack it pretty easily if you wan
<cachio_> pedronis, in this case, for pi3 we use system: ubuntu-core-16-arm-32
<pedronis> cachio_: ah
<cachio_> pedronis, so, should I change it?
<pedronis> they all need to be the same
<kyrofa> zyga-ubuntu, snapcraft/internal/lifecycle/_packer.py for your reference
<geekgonecrazy> sergiusens: nope not behind proxy (though I know launchpad is)
<pedronis> cachio_: this is the external backends ?
<zyga-ubuntu> kyrofa: thank you!
<cachio_> pedronis, yes
<cachio_> pedronis, external
<pedronis> cachio_: yes, they all need the same config
<pedronis> not sure why some have the false and some not
<cachio_> pedronis, ok, makes sense
<cachio_> thanks, I'll check that
<pedronis> I wasn't really paying attention to that part of spread.yaml
<geekgonecrazy> kyrofa: https://launchpadlibrarian.net/348314093/buildlog_snap_ubuntu_xenial_amd64_stable_BUILDING.txt.gz got one successful doing the curl in the prepare step.  o.O Not pretty but gets the release where I can push it out to the impatient users :D
<cachio_> pedronis, I do :)
<cachio_> pedronis, I use it a lot
<kyrofa> Hey jdstrand, I'm playing with another joystick lib, and finding our joystick interface lacking a bit. I'd like to be able to access /dev/input/event* for the joystick... but it's entirely unclear to me how we can determine which events are tied to the joystick
<kyrofa> jdstrand, https://pastebin.ubuntu.com/26126996/
<kyrofa> jdstrand, note how js0 and event17 are pretty clearly provided by the same device
<kyrofa> jdstrand, think that's possible?
<jdstrand> kyrofa: can you paste 'udevadm info /dev/input/event17'?
<kyrofa> jdstrand, here's both event17 as well as js0: https://pastebin.ubuntu.com/26127016/
<kyrofa> I don't know much about this-- they both seem to be an interface to the same data. Is one just a newer/different API?
<jdstrand> I think so, yes
<jdstrand> kyrofa: so, I do think this is possible. what you would need to do is interrogate udev to map the thing you know (/dev/input/js0) to the thing you don't (/dev/input/event17) then add the device access for event17
<kyrofa> Quick research leads me to believe js is old, event is newer
<kyrofa> jdstrand, can we do things like that in an interface?
<jdstrand> kyrofa: that is accurate
<kyrofa> So far I've just been adding static ones
<jdstrand> kyrofa: well, it is something I always hoped we could do for all sysfs entries. Ie, we assign js0 and then allow the precise sysfs entries for that device
<jdstrand> kyrofa: this isn't that different
<jdstrand> kyrofa: the problem is this is related to hotplug
<kyrofa> Say no more...
<kyrofa> jdstrand, would I be correct to assume that whitelisting /dev/input/event* in joystick is a bad idea?
<jdstrand> kyrofa: so we could come up with a way to look at udev (or possibly more simply, various symlinks), but interfacec connections happen at specific points in time, but reboots, plug/unplug, etc would change the paths
<jdstrand> kyrofa: oh gosh yes. that would grant anything that plugged the interface the ability to spy and spoof input events
<jdstrand> *all* input events
<kyrofa> Heh
<kyrofa> Yeah and profile generation only happens at install/upgrade time, right?
<jdstrand> connect/disconnect (obviously)
<kyrofa> Right, that's more specific. And THAT is what causes them to happen at install/upgrade time I suppose
<jdstrand> interestingly, also on reboot if the policy is different on disk from what snapd generates
<kyrofa> Oh, hmm
<jdstrand> I mention that last point cause you could get there crudely on reboot if snapd did its interrogating to come up with different policy
<kyrofa> Exactly my thought
<jdstrand> so js0 -> event17 might be js0 -> event16
<jdstrand> snapd would detect that
<jdstrand> but snapd would have to tie into the uevent kernel framework to get notifications on hotplug/unplug
<kyrofa> Right, and then in order to get new devices into the profile, one would need to reboot, or disconnect/connect the interface
<kyrofa> Meh
<jdstrand> there is another way to deal with this: static file labels with apparmor. the idea is that you create a udev rule that statically labels the device based on the snap's label
<jdstrand> but apparmor doesn't support that yet
<jdstrand> (that incidentally would get rid of the need for device cgroups, which would be great)
<jdstrand> kyrofa: exactly (hence the 'crudely' and why this is tied to hotplug)
<jdstrand> all of this is doable, but as you know, hotplug is on the roadmap but not prioritized for the short term
<kyrofa> Indeed. Okay, I'll hold off further investigation into this, and look for a python lib that uses the older interface. Very educational, thank you!
<kyrofa> Indeed
<jdstrand> np
<mup> PR snapcraft#1796 closed: Changelog for release 2.37 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1796>
<sergiusens> kyrofa elopio don't merge anything until further notice please
<kyrofa> ack
<elopio> ok
<mup> PR snapd#4370 opened: tests: set TRUST_TEST_KEYS=false for all the external backends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4370>
<kyrofa> Hey cjwatson, I'm curious: why, if LP supports all these architectures in the builders, does build.snapcraft.io only support a few of them?
<cjwatson> kyrofa: mainly because we want to have the facility to select specific architectures in snapcraft.yaml or similar (as we talked about at the rally, if you remember) before we enable more architectures by default that many developers won't care about without offering them a way to shut up the build failures
<cjwatson> kyrofa: also, s390x needs to have the new scalingstack region finished off before we can offer it in BSI
<mup> PR snapd#4364 closed: interfaces: added Ref() helpers, restored more detailed error message on spi iface <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4364>
<kyrofa> Ah, makes sense thank you :)
<sergiusens> cjwatson seems something hit kyrofa on the head, we were just discussing this on Monday ;-)
<kyrofa> sergiusens, we didn't discuss that it was preventing more arch support in build.snapcraft.io
<sergiusens> kyrofa oh, I am talking about the flashback to the rally conversation :-)
#snappy 2017-12-07
<mup> PR snapd#4371 opened: tests: add support on tests for cm3 gadget <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4371>
<mborzecki> morning
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> mborzecki: good mornin
<zyga-ubuntu> :)
<zyga-ubuntu> mborzecki: my last day this year
<mborzecki> taking the rest of the year off?
<zyga-ubuntu> yes
<zyga-ubuntu> though I need to check again, but that's the plan
<mborzecki> that's so nice, wish i had that many days of vacation left :)
<zyga-ubuntu> haha, I wish I hadn't
<zyga-ubuntu> the weather was better in the summer
<zyga-ubuntu> mborzecki: and I have three carry-over days
<zyga-ubuntu> mvo is not around yet
<zyga-ubuntu> yesterday I took a detour to play with base-18
<zyga-ubuntu> it was really fun, especially now that we can test boot it
<mborzecki> that'll be based on 18.04?
<zyga-ubuntu> yep
<zyga-ubuntu> try it
<zyga-ubuntu> it should work for you :)
<mborzecki> zyga-ubuntu: do you have any prs in need of review that you'd like to close before you go?
<zyga-ubuntu> mborzecki: yes, the two that are open
<mborzecki> #4315 #4329?
<mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<zyga-ubuntu> yes
<mup> PR snapd#4361 closed: devicestate: fix misbehaving test when using systemd-resolved <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4361>
<mup> PR snapd#4360 closed: interfaces/many: misc updates for default, browser-support, opengl, desktop, unity7, x11 for 2.30 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4360>
<zyga-ubuntu> hmm
<zyga-ubuntu> the github merge conflict resolution tool is weird
<zyga-ubuntu> it always has to run twice
<zyga-ubuntu> WT?
<zyga-ubuntu> look at 4343
<zyga-ubuntu> last two commits
<zyga-ubuntu> one is empty, one is the real merge
<mborzecki> zyga-ubuntu: posted some comments to 4329
<zyga-ubuntu> thanks, replied; I'll add the enum
<mborzecki> ok, thanks
<mborzecki> zyga-ubuntu: btw. what did you mean here: https://github.com/snapcore/snapd/pull/4354#discussion_r155448107 ?
<mup> PR #4354: tests/lib: introduce helpers for setting up /dev/random using /dev/urandom in project prepare <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4354>
<kalikiana> morning o/
<zyga-ubuntu> o/
<zyga-ubuntu> pstolowski: hey
<zyga-ubuntu> pstolowski: some small conflicts on your PRs
<zyga-ubuntu> pstolowski: good morning :)
<pstolowski> zyga-ubuntu, morning! ok, looking
<zyga-ubuntu> drat my seageate disks
<zyga-ubuntu> I will never buy from that vendor again
<kalikiana> zyga-ubuntu: did they break for good?
<zyga-ubuntu> no, just definitely started to fail
<mup> PR snapd#4343 closed: interfaces: rename sanitize methods <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4343>
<mup> PR snapcraft#1797 closed: tests: update the snap name already registered for store tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1797>
<mup> PR snapcraft#1757 closed: Saving snap-build assertion as '.build' <Created by cprov> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1757>
<zyga-ubuntu> a little bit more
<zyga-ubuntu> and I should have spread support for base 18
<zyga-ubuntu> man, iteration is painful
<zyga-ubuntu> snapcraft clean, snapcraft takes a good chunk of time
<zyga-ubuntu> whee, another boot attempt
<ogra_> ogra@pi3:~$ snap set core service.rsyslog.disable=false
<ogra_> error: cannot perform the following tasks:
<ogra_> - Run configure hook of "core" snap (run hook "configure": [--root / enable rsyslog.service] failed with exit status 1: Synchronizing state of rsyslog.service with SysV init with /lib/systemd/systemd-sysv-install...
<ogra_> Executing /lib/systemd/systemd-sysv-install enable rsyslog
<ogra_> insserv: warning: current start runlevel(s) (empty) of script `rsyslog' overrides LSB defaults (2 3 4 5).
<ogra_> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `rsyslog' overrides LSB defaults (0 1 6).
<ogra_> Failed to execute operation: Unit file is masked
<ogra_> )
<ogra_> hmm
<ogra_> (this is on edge, latest core)
<ogra_> i guess mvo's new config handling broke ..
<ogra_> (looks like it tries to call "enable" before "unmask")
<pedronis> ogra_: look at the code it doesn't seem like that,  Unmask is called before Enable
<pedronis> *looking
<ogra_> pedronis, yeah, i had a week old hanging core iwith a Doing task
<ogra_> aborting and manually refreshing fixed it
<ogra_> (see bug 1736922 (already closed again))
<mup> Bug #1736922: new config handling breaks re-enabling of rsyslog <snapd:Invalid> <https://launchpad.net/bugs/1736922>
 * kalikiana considers fixedly-postmenopausal-tamesha as a runner up for most ridiculous pet name of the week
<zyga-ubuntu> hmmm
<zyga-ubuntu> so why are services not starting
<zyga-ubuntu> I systemctl enable stuff
<zyga-ubuntu> and yet it's not up
<zyga-ubuntu> brr
<zyga-ubuntu> need warm tea
<mborzeck1> it's 5C outside, that's warmer than on Monday :)
<mup> PR snapd#4314 closed: interfaces: use ConnectedPlug/ConnectedSlot types (step 2) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4314>
<zyga-ubuntu> mborzecki: mwhudson recently complained about how warm it is in new zaeland
<zyga-ubuntu> *ea
<pstolowski> yay, all interface hooks prerequisites landed :)
<zyga-ubuntu> sigh
<zyga-ubuntu> little by little
<mup> PR snapd#4366 closed: interfaces/removable-media: also allow 'k' (lock) <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4366>
<mup> PR snapd#4367 closed: interfaces/removable-media: also allow 'k' (lock) for 2.30 <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4367>
<zyga-ubuntu> does anyone have any idea why a certain unit is not started?
<zyga-ubuntu> when systemd says "vendor preset: enabled"
<ogra_> nothing in syslog ?
<zyga-ubuntu> well
<zyga-ubuntu> not sure what to look for
<zyga-ubuntu> this is very barren still
<ogra_> typically stdout from units goes there
<zyga-ubuntu> I have a minimal 18 base
<zyga-ubuntu> ogra_: I doubt it is started
<zyga-ubuntu> it works when started manually
<zyga-ubuntu> I'll read it the hard way
<cachio> zyga-ubuntu, hey, I'll be 5 minutes late today
<zyga-ubuntu> cachio: that's ok
<zyga-ubuntu> cachio: we're still starting in one hour
<zyga-ubuntu> right?
<mup> PR snapd#4372 opened: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
<mborzecki> trivial PR ^^
<zyga-ubuntu> done
<cachio> zyga-ubuntu, yea
<mborzecki> cachio: did you manage to figure something out with the rpi test that was failing?
<zyga-ubuntu> aha
<zyga-ubuntu> so it seems (maybe) that it is snapcraft
<zyga-ubuntu> gah
<zyga-ubuntu> no,
<zyga-ubuntu> WTF
<zyga-ubuntu> so, /etc/systemd/system is empty after booting
<zyga-ubuntu> but it's not empty in the core snap
<zyga-ubuntu> WTF
<zyga-ubuntu> ah
<zyga-ubuntu> all is clear now
<zyga-ubuntu> thats system-data
<zyga-ubuntu> sooooo
<ogra_> /etc/systemd/system should be handled via writaable-paths
<ogra_> (in synced mode FWIW)
<bloodearnest> Hey folks. snap set core proxy.https=https://my.proxy:3128 does seem to have any affect, on 2.29 or 2.30, on classic. Is this a Known Issue?
<bloodearnest> gah s/affect/effect
<pedronis> bloodearnest: yes,   except proxy.store all the other core config are core only,  now that handling has been moved we need to decide which one make sense/are sane on classic too
<bloodearnest> ok
<pedronis> bloodearnest: it's not a regression, always been like this so far
<bloodearnest> thx
<bloodearnest> pedronis: ok. Related question, assuming some future where proxy.https can be set on classic, is there a way for another snap to access core config, via snapctl inside the snap, or similar?
<ogra_> bloodearnest, snapd's systemd unit sources /etc/environment ... if you have your proxy settings in there and restart snapd it should just pick that up
<ogra_> (that indeed assumes a system wide proxy)
<pedronis> bloodearnest: not at the moment,  a snap would need snapd-control  and go through the REST api directly or use snap (I don't remember if we make available there)
<ogra_> pedronis, i suspect even then you would miss access to core-support (which the config hook uses) ... or would that be just internally used when calling set/get ?
<pedronis> ?
<pedronis> you can do snap get core
<pedronis> or the equivalent with the RESTÂ api
<pedronis> not sure how core-support (which is not needed anymore) relates
<ogra_> ah, wh is it not needed anymore ?
<ogra_> *why
<pedronis> because the hook is going away
<ogra_> oh, indeed, silly me
<pedronis> as far as IÂ know we have core-support just for the configure hook inside core
<ogra_> it is snapd itself now
<ogra_> right
<ogra_> for allowing the shelling out to particular system binaries
<ogra_> but indeed ... not needed when snapd manages it ... thanks !
<pedronis> yea, that's why I said not sure, but if you have snapd-control you can use the REST api
<pedronis> but there's no other way to peek at other snap configs atm
<pedronis> nor any special exception around core config
<pedronis> bloodearnest: there is some idea that snapctl should give access to some safe system information (not specifically config keys) but nothing has happened yet of that
<zyga-ubuntu> cachio: standup
<zyga-ubuntu> pstolowski: standup
 * ogra_ wonders when this "snap list" on his non-networked kvm will return ... it is sitting there since several minutes now 
<ogra_> dont we have a timeout ?
<popey> ogra_: i saw that recently on a machine which had selinux blocking. it didnt timeout, ever
<popey> just sits there, and journalctl shows selinux blocking errors
<ogra_> well, its a kvm core image nad my host has somehow messed up the forwarding ...
<ogra_> so the kvm machine thinks it has network but i cant ping anything outside
<ogra_> it still sits there btw ...
<popey> worth a look in the journal/syslog anyway
<ogra_> seems to never time out
<mup> PR snapd#4371 closed: tests: add support on tests for cm3 gadget <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4371>
<ogra_> wow
<ogra_> http://paste.ubuntu.com/26132566/
<ogra_> so snapd crashes (it then restarts though and seems to run proper)
<ogra_> oh, it finally returned the list ... only took really long
<popey> :)
<ogra_> over 10 min
<ogra_> but that above was only on boot ... the actual "snap list" call doesnt produce any log output
<ogra_> sadly even snap changes hangs
<ogra_> hmpf
<sergiusens> ann: if anyone pinged me in the past 2 hours I lost it
<zyga-ubuntu> mvo: some more progress, spread now starts the vm but fails to log in because /home is synced and that kills my test-only /home/ubuntu directory; I removed most of writable paths (including home), let's see what this looks like
<ogra_> zyga-ubuntu, dnot forget writable-paths has individual settings (two way, three way merge or completely persistent) the single dirs behave differently usually
<zyga-ubuntu> ogra_: right, I have a custom conifg
<zyga-ubuntu> *config
<zyga-ubuntu> this is just a temporary step
<zyga-ubuntu> towards something I can spread test and test boot rapidly
<zyga-ubuntu> and in the end get a working environment for interation
<zyga-ubuntu> I think we want to remove writable-paths entirely
<ogra_> yeah, i get that
<zyga-ubuntu> (eventually)
<ogra_> just pointing out a synced dir thats now not synced might break the world :)
<zyga-ubuntu> yep, that's all "fine" - we're far away from base-18 working
<ogra_> heh
<ogra_> what about doing base-16 first ?
<zyga-ubuntu> I need to move the initramfs help
<zyga-ubuntu> ogra_: I think that's less interesting as that can stay as a copy of current core forever
<ogra_> since you will need the split for upgrades
<ogra_> well, using the base-16 and then shrinking it would be my way forward
<ogra_> (towards -18)
<zyga-ubuntu> not sure
<zyga-ubuntu> I think there are lots of challenges in 18 that need to be tackled
<zyga-ubuntu> and this is also involving migration
<zyga-ubuntu> I want to just do 18 as a clean slate first
<bloodearnest> pedronis: zyga: ok, thanks for the info
<ogra_> sigh ... this snapd in kvm really misbehaves
<ogra_> error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF
<ogra_> for a snap remove ...
<zyga-ubuntu> snapd crashed?
<ogra_> it is running ... the network forwarding outside the VM is broken ...
<ogra_> so it thinks it is online but i cant ping the outside world (i can ping my lkvm gateway though)
<ogra_> that makes snapd really misbehave
<zyga-ubuntu> ping is broken in user networking
<zyga-ubuntu> just don't ping
<ogra_> $ ps ax|grep snapd
<ogra_>   965 ?        Ssl    0:00 /usr/lib/snapd/snapd
<ogra_> $ snap remove firstboot-setup
<ogra_> error: cannot communicate with server: Post http://localhost/v2/snaps/firstboot-setup: EOF
<ogra_> thats what i get
<ogra_> oh ? ping is broken ? since where
<zyga-ubuntu> any snapd logs?
<zyga-ubuntu> ogra_: since forever in user networking, check that if you want to know why
<zyga-ubuntu> ogra_: but that's irrelevant for snapd
<ogra_>  2017/12/07 13:40:14.783948 daemon.go:306: started snapd/2.30~rc1+git467.c2f9631~ubuntu16.04.1 (series 16) ubuntu-core/16 (amd64) linux/4.4.0-102-generic.
<sergiusens> zyga-ubuntu what version of go are you using for snapd?
<ogra_> looks like it started just fine (thats the last line in the journal)
<zyga-ubuntu> sergiusens: 1.6
<zyga-ubuntu> sergiusens: on core
<sergiusens> across the board?
<zyga-ubuntu> sergiusens: and reexec
<zyga-ubuntu> sergiusens: whatever-is-there on various distros
<sergiusens> ah, the client on whatever the distro is I guess
<zyga-ubuntu> sergiusens: kind of, the client on your distro execs the reexec 1.6 binary most of the time
<cachio> ogra_, hey
<ogra_> hey cachio
<cachio> ogra_, I was discussing with plars about if we could have ubuntu core images bot beta
<ogra_> cachio, sure. why not
<cachio> ogra_, it could be manually/automatically triggered when a new core snap is in beta
<cachio> ogra_, so then we can use those images in testflinger
<ogra_> cachio, you would need to talk to foundations to get a beta build at http://cdimage.ubuntu.com/ubuntu-core/16/
<ogra_> sil2100 does them i think
<cachio> ogra_, good
<ogra_> (unless you will roll them yourself indeed)
<ogra_> (its always just an ubuntu-image call away anyway ;) )
<cachio> ogra_, where is the code that we use to create the stable / edge images?
<ogra_> cachio, also a question for foundations ... i only do the images at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for which the build scripts are local
<ogra_> (local meaning on my PC)
<cachio> ogra_, ah, ok
<zyga-ubuntu> ha
<zyga-ubuntu> I now know a little bit more about how spread starts up
<cachio> ogra_, great, I'll talk to sil2100 in that case
<ogra_> yeah
<cachio> ogra_, tx
<ogra_> or slangasek ... either of them should be able to point you to the official scripts
 * kalikiana off for lunch in 10min
 * kalikiana getting hungry
<mvo> zyga-ubuntu: sorry, in a meeting, nice progress. looking at your open PRs now
<zyga-ubuntu> mvo: ok, just need to add sudo right
<zyga-ubuntu> mvo: I'll open a 2nd pr for spread
<zyga-ubuntu> (for this project, spread is ok)
<mborzecki> mvo: if that's ok with you, i'd like to rebase #4357 on top of #4372 and skip all 'validation' pathes in this PR
<mup> PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357>
<mup> PR #4372: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
<zyga-ubuntu> mvo: it works now :)
<zyga-ubuntu> mvo: shall I expand the existing PR
<zyga-ubuntu> mvo: or do you want to see a 2nd one
<mup> PR snapd#4340 closed: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4340>
<mup> PR snapd#4373 opened: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373>
<mvo> mborzecki: +1
<mvo> zyga-ubuntu: either way is fine
<mvo> zyga-ubuntu: whatever is easier for you
<zyga-ubuntu> k
<mup> PR core#66 closed: 500-create-xdg.binary: use "set -o pipefail"  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/66>
<mborzecki> mvo: the PRs are split now, would appreciate another review :)
<zyga-ubuntu> mvo: done
<zyga-ubuntu> mvo: please try it :)
<zyga-ubuntu> mvo: same PR
<zyga-ubuntu> mvo: just look at my master
<zyga-ubuntu> mvo: commit history (especially last one) has usage instructions
<zyga-ubuntu> mvo: I'll polish this now, slightly, enough to start fixing the issues we see (and add tests)
<mvo> mborzecki: great, will look
<mvo> zyga-ubuntu: same here
<mborzecki> mvo: thanks
<mvo> zyga-ubuntu: \o/
<mborzecki> i'm off to pick up the kids, afk for now
<greyback> jdstrand: hey, I've pushed my WIP to https://github.com/snapcore/snapd/pull/4365/files, can I ask you a couple of things? (1) Am I going too far, enabling proper Wayland compositors, which allows hardware access like Mir has? (2) I've duplicated much of what Mir slot has. is that kosher, or would a shared subclass interface be do-able?
<mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
<greyback> zyga-ubuntu: ^^ your opinion also welcome
<zyga-ubuntu> greyback: ack
<zyga-ubuntu> mvo: ok, I think base-18#8 is ready for review
<zyga-ubuntu> mvo: once it lands we can really iterate and propose tests
<mvo> zyga-ubuntu: \o/
<zyga-ubuntu> mvo: I'll try to enable travis now
<zyga-ubuntu> actually
<zyga-ubuntu> hmmm
<zyga-ubuntu> I think this will be harder than I anticipated
<zyga-ubuntu> unless travis can just run things on top of xenial (maybe)
<ogra_> why wouldnt it ?
<ogra_> all y teste run on top of a xenail chroot in travis
<ogra_> *all my tests
<zyga-ubuntu> I need qemu
<zyga-ubuntu> and spread
<zyga-ubuntu> and kpartx and other maic
<ogra_> ouch
<zyga-ubuntu> may be too much
<ogra_> yeah
<zyga-ubuntu> well, let me grab a coffee and try
<zyga-ubuntu> or maybe
<zyga-ubuntu> break for lunch and then come back fresh
<zyga-ubuntu> ogra_: btw, feedback on base-18 appreciated
<ogra_> zyga-ubuntu, where do you hide it ?
<zyga-ubuntu> ogra_: snapcore/base-18
<zyga-ubuntu> ogra_: see PR #8
<ogra_> i wonder why i didnt get PR mail for that
<zyga-ubuntu> ogra_: it's brand new
<ogra_> zyga-ubuntu, you dont install ubuntu-core-config ?
<ogra_> hwo do you get writable-paths right then ?
<zyga-ubuntu> ogra_: I don't even know what is there
<zyga-ubuntu> ogra_: note that for testing I steal core-16 intird
<ogra_> well, it only does a debootstrap minbase and one hook installs systemd and nssswitch
<ogra_> zyga-ubuntu, right, that will be broken since it wont fint /etc/system-image/writable-paths in the target rootfs
<ogra_> the initrd needs that
<zyga-ubuntu> I think this is a _very_ early core :)
<ogra_> interesting that you get it to boot at all
<ogra_> zyga-ubuntu, well, it should badly error before mounting the rootfs when it doesnt find the writable-paths file ... if it doesnt you found actually a bug in the initrd :)
<zyga-ubuntu> ogra_: ogra_ I add one
<zyga-ubuntu> ogra_: I added that file
<zyga-ubuntu> ogra_: anyway, this is really held-with-strings for now
<ogra_> yeah, understood
<zyga-ubuntu> ogra_: I plan to integrate inird code here so that base-18 is separate from base-16
<zyga-ubuntu> ogra_: and then let us iterate with confidence (tests)
<ogra_> i dont see where you add the file though
<zyga-ubuntu> ogra_: hooks
<zyga-ubuntu> ogra_: btw, this also includes a small, hand coded ubuntu-image
<mup> PR snapd#4308 closed: packaging/arch: install snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4308>
<zyga-ubuntu> ogra_: again, all optimized for getting started and getting results quickly
<zyga-ubuntu> ogra_: I expect everything to change
<ogra_> zyga-ubuntu, oh, i was looking ast the tree, not the last PR
<zyga-ubuntu> ahh
<ogra_> wow
<kalikiana> re
<zyga-ubuntu> what?
 * ogra_ shades his eyes from "create-image" 
<kalikiana> is it shiny?
<ogra_> well ...
<ogra_> :)
<zyga-ubuntu> ogra_: I'd say it's simple
<zyga-ubuntu> ogra_: simplest one yet :)
<zyga-ubuntu> mvo: updated the comment
<zyga-ubuntu> mvo: shall I remove the dist-upgrade too?
<zyga-ubuntu> mvo: and note that you have to merge it as I don't have permissions
<zyga-ubuntu> mvo: does it work for you :) ?
<zyga-ubuntu> (that's most interesting)
<mvo> a review for 4372 would be great, should be an easy win :)
<zyga-ubuntu> darn, I already did
<mvo> zyga-ubuntu: so far I just reviewed :) thanks, I will try it in a little bit, but I also promised maj some reviews (what is the short form of his name)?
<mvo> zyga-ubuntu: oh, sorry
<mvo> zyga-ubuntu: you did indeed, silly me
<zyga-ubuntu> mvo: maciej or maciek are both shorth-ish;
<zyga-ubuntu> I don't think there's a shorter way
<greyback> jdstrand: thanks for the review. I'll bring up a Weston snap to proof the interface and remove any Mir specifics (I'd not vetted those bits carefully yet)
<jdstrand> greyback: I gave some feedback. imo it would be ok to strip out the things we know are mir-specifc and just make this work for the mir snap. if someone provides an alternate slot implementation (eg, weston), we could add anything else (though, bonus points if you snap weston)
 * jdstrand is partially kidding
<jdstrand> oh heh
<jdstrand> :)
<jdstrand> gold start for greyback :)
<jdstrand> star*
<jdstrand> greyback: thanks! :)
<greyback> np
<mvo> zyga-ubuntu: sad, "mac" would be a great name :P
 * mvo hugs mborzecki 
<mborzecki> mc borzecki
<zyga-ubuntu> mvo: mac sounds good to me :)
<ogra_> M.C. ... rock da house !
<zyga-ubuntu> mborzecki: do you like it
<mvo> lol@mc
<zyga-ubuntu> greyback, jdstrand: sorry I wasn't looking at that PR yet
<zyga-ubuntu> I got lost in base-18
<mvo> mborzecki: next sprint you need to give a performance on stage as the MC
<greyback> zyga-ubuntu: no worries, I've plenty to work with :)
 * ogra_ adds a PR to base-18 ... "find . -name zyga-ubuntu"
<greyback> base 18 arithmetic? yikes!
<zyga-ubuntu> heh
<mborzecki> hahah, not gonna happen :)
<zyga-ubuntu> :D
<mvo> cachio_lunch: is 4370 also for 2.30? to make your validations easier?
<mborzecki> mvo: thanks for pushing the gofmt fix to #4372, i had it in both PRs but missed it when rebasing :/
<mup> PR #4372: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4372>
<mup> PR snapd#4370 closed: tests: set TRUST_TEST_KEYS=false for all the external backends <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4370>
<mvo> mborzecki: no problem, feel free to rebase that commit from me away if you dislike it
<zyga-ubuntu> mvo: 4329 should be mergable now
<zyga-ubuntu> mvo: as I said in my last comment just now I constrained the fix to classic systems
<zyga-ubuntu> mvo: this lets us land the important fix and use it while the 2nd half is implemented
<zyga-ubuntu> mvo: so, that's one up for review :)
<zyga-ubuntu> mvo: trivial base-18#21
<mup> PR base-18#21: tests: check that hostname is not set <Created by zyga> <https://github.com/snapcore/base-18/pull/21>
<zyga-ubuntu> mvo: how can I make the base-18 build aware of a local apt proxy?
<zyga-ubuntu> mvo: it'd be good for just the basic bootstrap to do this
<mvo> zyga-ubuntu: hm, http_proxy should be fine
<mvo> zyga-ubuntu: the env
<mvo> zyga-ubuntu: I also added support for squid-deb-proxy-client at some point
<mvo> zyga-ubuntu: i.e. iirc it ran the apt config Acquire::http::ProxyAutoDetect  at some point. not sure if this is still the case though
<cachio> mvo, please tell me if you need some help to reproduce any other the errors that I saw during beta validation
<zyga-ubuntu> mvo: base-18#22
<mup> PR base-18#22: hooks,tests: mask motd timer/services <Created by zyga> <https://github.com/snapcore/base-18/pull/22>
<mborzecki> it looks to me we need a separate service that monitors how many spread nodes are avalable and then starts the CI job
<zyga-ubuntu> mborzecki: aka spread batch system
<zyga-ubuntu> yes, I agree
<zyga-ubuntu> it's silly that we do things interactively
 * zyga-ubuntu slowly EOYs
<zyga-ubuntu> just turned my desktop off
<brunosfer> Hey guys, I'm trying to run some services in bluetooth using my snap with sdptool, however I get the error "Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory" do you know how can I solve this problem in ubuntu snappy core?
<zyga-ubuntu> brunosfer: please ask this question on the forum (forum.snapcraft.io) - more people can see and react and learn from responses there
<brunosfer> zyga-ubuntu: Good idea. Thanks for the advice ;)
<kalikiana> zyga-ubuntu: xmas is coming early for you, so to speak? :-D
<zyga-ubuntu> kalikiana: I hope real snow will follow
<kalikiana> fingers crossed
<kalikiana> although where I'm at it's most likely just going to be a slushy brown mess
<zyga-ubuntu> "ding ding ding, ding ding ding, what's this murky goo, how I hate when it wheels get stuck and shoes get white-salt stains"
<pstolowski> zyga-ubuntu, missing Spain already? ;)
<zyga-ubuntu> pstolowski: since I left
<roadmr> zyga-ubuntu: haha murky goo rofl
 * kalikiana also wrapping up for today (not for the year just yet)
<kennyloggins> realy wanted to go to asturias , but cant afford eet.
<mvo> cachio: still haven't managed to try it yet with a real image
<mvo> cachio: after dinner I will try
<mvo> cachio: else in my morning
<kennyloggins> zyga-ubuntu they're waiting to cross, still in Seville :) https://redd.it/5ihe60
<zyga-ubuntu> kennyloggins: hmm?
<zyga-ubuntu> kennyloggins: I'd like to live in spain again
<zyga-ubuntu> not sure how this is related (apart from seville)
<kennyloggins> zyga-ubuntu: Oh, thought you were one of those bots - just a random pic. post I guess.
<zyga-ubuntu> WHAT
<zyga-ubuntu> :D
<kennyloggins> zyga-ubuntu: I need better books to read though.
<zyga-ubuntu> I can recommend some
<zyga-ubuntu> but I need to read them first :)
<kennyloggins> for myself, how lovely.
<kennyloggins> oh, that's abit ridge-wing then.
<mcphail> I'm getting build errors from build.snapcraft.io - "svn: E670002: Unknown hostname 'svn.code.sf.net'" - is there are problem with DNS resolution?
 * mcphail has no idea why he didn't write that in English...
<cjwatson> mcphail: https://bugs.launchpad.net/launchpad-buildd/+bug/1668358
<mup> Bug #1668358: Snap Builds using SVN Unable to Access Internet <launchpad-buildd:Confirmed> <https://launchpad.net/bugs/1668358>
<cjwatson> i.e. svn proxying isn't implemented yet
<mcphail> cjwatson: aah. Thanks. That's a shame
<cjwatson> mcphail: if you can use http/https URLs with svn, that should work though
<cjwatson> hm, maybe not, that bug does give an http:// example
<cjwatson> feel free to work out how to fix this ... :-/
<mcphail> heh :)
<mcphail> I think you overestimate my talents
<cjwatson> we probably just need to implement the stuff from https://subversion.apache.org/faq.html#proxy
<kennyloggins> used gscan2pdf for the first time in 2 years today - would be nice as a snap.
<cjwatson> I don't know whether svn honours the usual proxy environment variables; if not we'll need to hack /etc/subversion/servers or similar.  And we probably also need to change the proxy config to allow those extra HTTP methods.
<mcphail> it would be nice if people stopped using svn
<sergiusens> cjwatson subversion only allows global setting in its file, no env vars or alternate config files are allowed from what we saw
<sergiusens> which is why we did not implement it
<cjwatson> sergiusens: right, but launchpad-buildd could
<sergiusens> true, we could also implement it in snapcraft if the build environment is discardable
<mcphail> popey: any suggestions as to what i need to tweak in https://github.com/mcphail/quakesnap to get sound working?
<popey> the one in the store?
<mcphail> no - this one doesn't build
<mcphail> (well, it builds locally but not on the build server due to the svn issues above)
<popey> do you need libpulse0 staged?
<popey> and the environment variable so it gets found
<mcphail> I tries that but it didn't seem to make a difference. Let me try again
<popey> do you get apparmor issues?
<mcphail> where do I check for those? dmesg?
<popey> snappy-debug.security scanlog
<popey> leave that running in a terminal
<popey> snap install snappy-debug, if you don't have it first
<mcphail> popey: http://paste.ubuntu.com/26133867/
<popey> sounds like one for jdstrand ^ :)
<mcphail> heh. I'm sure I'm just missing something daft
<popey> the alsa plug maybe?
<popey> but you also need to bundle a load of alsa gumpf
<popey> lemme find an example (assuming it's alsa)
<mcphail> certainly the app thinks it is using pulse
<kennyloggins> where is the place to create an issue for that problem ?
<popey> depends where the issue is
<popey> i dont think alsa plug would do it. https://github.com/snapcore/snapd/blob/master/interfaces/builtin/alsa.go
<kennyloggins> probably a 'enta' library or something.
<popey> https://github.com/snapcore/snapd/search?utf8=%E2%9C%93&q=%2Fsys%2Fdevices&type=
<popey> can't see a plug that covers it.
<popey> so yeah, one for when jdstrand is about, or a forum thread
<kennyloggins> libasound2 ? I think that is shared libraries in debian. but again - I'm a random today.
<mcphail> OK. Cheers popey
<jdstrand> mcphail (cc popey): the wgetrc you can ignore or adjust your wget invocation to use a wgetrc in your snap
<jdstrand> mcphail (cc popey): plugs screen-inhibit-control
<jdstrand> mcphail (cc popey): the /sys/devices issue was actually just fixed in the upcoming 2.30
<popey> woohoo!
<jdstrand> mcphail (cc popey): as part of the joystick interface
<jdstrand> mcphail: I suspect tomorrow's edge snap will have the fix
<jdstrand> edge core* snap
<popey> Great to hear, thanks jdstrand
<jdstrand> np
<jdstrand> popey, mcphail: see https://forum.snapcraft.io/t/joysick-access-for-sdl2-apps/3027 for details
<mcphail> jdstrand: ooh. thanks
<sergiusens> elopio mind checking my update on LP: #1736861 ?
<mup> Bug #1736861: classic snap fails to build with "cannot find section" <regression> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1736861>
<mup> PR snapd#4374 opened: interfaces: interfaces: also an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4374>
<elopio> sergiusens: I get "OSError: libarchive.so: cannot open shared object file: No such file or directory"
<sergiusens> oh, I built it on a dirty system
<sergiusens> elopio let me just push the branch
<sergiusens> elopio snapcraft#1798
<mup> PR snapcraft#1798: go plugin: strip sections that patchelf does not handle <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<mup> PR snapcraft#1798 opened: go plugin: strip sections that patchelf does not handle <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
<mup> PR snapd#4375 opened: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4375>
<gsilvapt> hello all
<gsilvapt> kyrofa, you around=
<gsilvapt> s/=/?
<kyrofa> gsilvapt, I am, although knee deep in something at the moment
<gsilvapt> kyrofa, I see. If you have some free time, let me know so we can finish the version feature if that's okay to you
<kyrofa> gsilvapt, where did we leave off? Trying to add the variable in?
<gsilvapt> kyrofa, the string was working but I was not able to pass in the %(prog) and %(version) variables correctly
<kyrofa> gsilvapt, that's an old-style format string. Hints here: https://pyformat.info/
<kyrofa> gsilvapt, however, I remember that we ran into testing issues with %(prog), which is why we hard-coded "snapcraft"
<kyrofa> Might want to continue doing that
<gsilvapt> kyrofa, thank you. I'll take a look right after I finish prepping the information to apply my LoCo to revalidation.
<kyrofa> Sure thing
<gsilvapt> kyrofa, now I read your first message. So are we not using %(prog) variable then?
<gsilvapt> Or for now we'll stick with that and see how it behaves?
<kyrofa> Either way, but I suspect you'll run into troubles using it
#snappy 2017-12-08
<cholcombe> any word on installing snappy in centos7?
<cholcombe> i saw a few bug report notes but nothing to indicate i could use it
<mwhudson> soo
<mwhudson> i have a snap with a plugin
<mwhudson> the plugin depends on pyelftools
<mwhudson> i have python3-pyelftools in my snap's build-packages
<mwhudson> if i build with the dpkg snapcraft, this works fine
<mwhudson> but if i build with a snapped snapcraft, the plugin can't import the dependency
<mwhudson> any ideas?
<sergiusens> mwhudson yeah, does it use ctypes? If that is the case, we have a patched up library finder
<mwhudson> sergiusens: no
<mwhudson> sergiusens: the games this plugin is up to will stop being relevant when classic snap creation gets fixed properly though :)
<sergiusens> mwhudson oh, this is like a venv ignoring system packages
<mwhudson> sergiusens: yes, i guess so, i think the PYTHONPATH for the snapcraft process only includes things from the snapcraft snap, and the plugin runs in the same process so...
<sergiusens> mwhudson yeah, we don't set any PYTHONPATH though, we just rely on the default sys.prefix setup by python itself
<mwhudson> sergiusens: well ok
<mwhudson> i guess the general case is "how do i write a plugin that has an external (python) dependency"
<mwhudson> maybe the answer is "don't do that"
<gsilvapt> kyrofa, I was taking a look at the issue and now my problem is something else. Is there a variable with the value Snapcraft I can get to pass in to %(prog)?
<mborzecki> morning
<mup> PR snapd#4372 closed: snap: YAML and data structures for app before/after ordering <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4372>
<mup> PR snapd#4352 closed: tests: increase amount of workers for ubuntu-16.04-64 by one <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4352>
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mborzecki> mvo: have you seen #4326 maybe?
<mup> PR #4326: interfaces/builtin: blacklist zigbee dongle <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4326>
<mborzecki> i wonder if there's a way to ship extra udev rules with such quirks as separate files read at runtime rather than embedding them in snapd code
<mvo> mborzecki: I have seen it but didn't pay close attention (yet)
<mvo> mborzecki: right, thats a gustavo topic, we discussed this a long time ago and then the conclusion was that we want it centralized for now
<mvo> mborzecki: but "now" maybe well be past now, especially when there is a compelling use-case
<mborzecki> the thing fixed in the pr seems to be a workaround for a very specific hardware
<mborzecki> wouldn't be surprised if that's even some engineering unit that reports bad vid/pid (not like i haven't seen things like such things in the past)
<kalikiana> morning
 * kalikiana coffee
<mup> PR snapd#4376 opened: tests: fix external backend for tests that need DEBUG output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4376>
<mvo> mborzecki: *nod* no disagreement, we need to discuss with gustavo
<mborzecki> mvo: https://forum.snapcraft.io/t/refresh-time-should-next-conform-to-core-api-schedule/3088 weekday schedule is not supported right?
<mvo> mborzecki: correct, the current snapd only supports settings inside the 24h window
<mvo> mborzecki: your work will fix this :)
<mvo> mborzecki: feel free to reply and pitch your branch
<mvo> mborzecki: the fact that this it not rejected outright is a bug that I think we fixed in 2.30
<mborzecki> thanks :)
<mborzecki> pstolowski: morning
<pstolowski> mborzecki, hey!
<mvo> hey pstolowski !
<mborzecki> hm we really should be doing `set -e` in all scripts
<mborzecki> /home/gopath/src/github.com/snapcore/snapd/tests/lib/mkpinentry.sh: 3: /home/gopath/src/github.com/snapcore/snapd/tests/lib/mkpinentry.sh: MATCH: not found
<mborzecki> this script is ran instead of being sourced in the tests
<pstolowski> mborzecki, sounds sensible to me
<mvo> mborzecki: +1
<mborzecki> or we could tweak spread to write MATCH to ~/.bashrc even if not runnig with -shell or -debug
<mup> PR snapd#4377 opened: tests/main: source mkpinentry.sh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4377>
<mup> PR snapd#4378 opened: tests: do not disable refresh timer on external backend <Created by mvo5> <https://github.com/snapcore/snapd/pull/4378>
 * mvo runs the full pi3 validation after fixing the known issues
<mup> PR snapd#4379 opened: client: send all snap related bool json fields <Created by mvo5> <https://github.com/snapcore/snapd/pull/4379>
<Chipaca> pstolowski: ping
<pstolowski> Chipaca, hey
<Chipaca> pstolowski: hiya
<Chipaca> pstolowski: what's required of a hook in order for a user to run it? unix permissions wise
<Chipaca> pstolowski: are hooks run as root, or as the user?
<pstolowski> Chipaca, they are run by snapd, so root
<Chipaca> pstolowski: pedronis: if you think of anything further we should do on https://forum.snapcraft.io/t/incorrect-permissions-in-meta-snap-yaml/1161/7 please raise it there
<mvo> mborzecki: hey, mind if I write a tiny snap-mgmt test? its the perfect task while waiting for a pi3 execution of tests. or have you started already?
<mborzecki> mvo: go ahead, i haven't started working on it yet
<mvo> mborzecki: great, will push a PR in some minutes
<pedronis> Chipaca: we should ping jdstrand to have checks like that in review-tools
<pedronis> snapd is useful but very late here
<pstolowski> mborzecki, #4357 looks very nice, but one question
<mup> PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357>
<mborzecki> pstolowski: thanks for the review
<mup> PR snapd#4380 opened: tests: add simple snap-mgmt test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4380>
<mborzecki> i'm adding those workarounds for /dev/random running out of entropy, but gpg called in snap create-key is smart, looks like it's using the real random device anyway
<mvo> mborzecki: woah, annoying
<Chipaca> pedronis: the whole stack should check, yes
<mborzecki> mvo: right, so there's a gpg agent, and it seems that it's started while proper /dev/random is still around
<pedronis> mborzecki: yes, if the distro is usigng gpg 2.x
<pedronis> it can be restarted though (don't know the exact incantation)
<mborzecki> pushed a fix with `pkill -e gpg-agent`, i tried `gpgconf --kill gpg-agent` but that wasn't reliable at all
<popey> kyrofa: seen https://bugs.launchpad.net/snapcraft/+bug/1736963 ?
<mup> Bug #1736963: "snapcraft enable-ci travis" won't accept my password <Snapcraft:New> <https://launchpad.net/bugs/1736963>
<popey> kyrofa: i was writing some simple travis docs but fail because that command is broken
<mvo> mborzecki: nice find!
 * kalikiana need to take a short break
<jdstrand> pedronis: as it happens, the review-tools have a check for the config hook, but not the other hooks
 * jdstrand adds a note to update them for the others
 * sergiusens waves from a holiday
<mup> Bug #1732555 changed: Installing bad snap has snapd crashing <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1732555>
<sergiusens> elopio the register thing is broken now on the fakes
<mup> PR snapd#4363 closed: cmd/snap-mgmt: add more directories for cleanup and refactor purge() code <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4363>
<kalikiana> sergiusens: what are you doing here then, you should enjoy your day off :-P
<mup> Bug #1723974 changed: snap client doesn't work with Croatian language/characters <Snappy:Fix Released> <https://launchpad.net/bugs/1723974>
<pedronis> mvo: I was looking at this code:  https://github.com/snapcore/snapd/blob/master/tests/main/auto-refresh/task.yaml#L21   the if doesn't make sense anymore, right?  also refresh.disabled is not used either?
<mup> Bug #1722882 changed: Ubuntu Core 16: Error: cannot refresh "pi2-kernel": snap "pi2-kernel" has changes in progress <Snappy:Fix Released> <https://launchpad.net/bugs/1722882>
<pedronis> Chipaca: is architectures mandatory in snap.yaml?
<mvo> pedronis: correct, the "if" can be killed and the disabled=false can also be killed. will you do that or shall I push a PR?
<pedronis> mvo: I can do in my upcoming PR, I'm creating a auto-refresh-private test
<pedronis> that will be similar
<mvo> pedronis: thank you
<mup> PR snapd#4368 closed: tests: fix security-device-cgroups-serial-port test for rpi and db <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4368>
<mvo> jdstrand: re 4100> I'm inclined to merge it, gustavo is not around for a re-review but it looks like you addressed his comment. what is your feeling about it? good to go in Ã
<mvo> ?
<mup> Bug #1717857 changed: UDisks2 interface restricts sending DBus.Properties.Get message from the client to udisksd service <Snappy:Fix Released by zyga> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1717857>
<mup> Bug #1717900 changed: Confined snap fail for user with homedir in /var/lib <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1717900>
<mup> Bug #1718026 changed: Applications from installed snaps don't appear in activities overview <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1718026>
<kennyloggins> How do I see the last changes on a snap (ie. paintsupreme-3d ) ?
<mup> Bug #1717375 changed: snap find behaviour? <Snappy:Opinion> <https://launchpad.net/bugs/1717375>
<mup> PR snapd#4377 closed: tests/main: source mkpinentry.sh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4377>
 * kalikiana lunch time
<mup> PR snapd#4381 opened: interfaces: add /proc/partitions to system-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/4381>
<pedronis> jdstrand: have you seen this discussion:  https://forum.snapcraft.io/t/snap-rejected-because-of-use-of-browser-support/3089/8 ?
<mvo> jdstrand: fwiw, I work on fixing the failures in 4374 now
<popey> elopio: is this still a bug, if so, can it please be made into a bug report? https://forum.snapcraft.io/t/go-homedir-reads-etc-passwd-not-home/2727
<elopio> segiusens: I'll update the fake
<kennyloggins> popey, I need to find the log changes in this snap : https://uappexplorer.com/snap/ubuntu/paintsupreme-3d how do i do that ?
<popey> Log changes?
<kennyloggins> right - to see if its been updated.
<elopio> popey: it depends very much on how to define a bug. I will report one
<popey> elopio: lemme have the bug number pls
<kennyloggins> all I see is this & I've forgotten how to see that yaml changes :( http://paste.ubuntu.com/26139743/
<popey> what changes are you expecting to see?
<kennyloggins> well I asked the developer by email last month that it didn't work on xubuntu 17.10 & debian - just wondering if they'd worked on it since ?
<popey> doesn't look like it. "snap info <snapname>"
<popey> only two revisions in the store
<kennyloggins> popey, thankyou for helping me track changes, popey :)
<popey> np
<mup> Bug #1707474 changed: FTBFS on i386: incompatibility with new xfsprogs <Snappy:Fix Released by zyga> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1707474>
<mup> Bug #1701510 changed: Unbind brcmfmac_sdio crashes netplan <Snappy:Fix Released> <https://launchpad.net/bugs/1701510>
 * diddledan ninja-cuddles people as they walk by
<kalikiana> re
<kalikiana> diddledan: :-o
<mvo> some of the 2.30 targeted PRs need a second review, if someone could have a look, that would be great
<mup> Bug #1705486 changed: SPI not working on Raspberry Pi with ubuntu core <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1705486>
<mup> PR snapcraft#1799 opened: tests: update the registered snap fake <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1799>
<mvo> ogra_: 1689037 is assigned to you, are you still happy that this is assigned to you?
<mup> Bug #1686852 changed: Can only run hello snap as root <Snappy:New> <https://launchpad.net/bugs/1686852>
<mcphail> Hi. I'm struggling to see why a git repo isn't being cloned by snapcraft. My snapcraft.yaml is at http://paste.ubuntu.com/26139967/ and the output is at http://paste.ubuntu.com/26139961/. What have I done wrong?
<mup> Bug #1684525 changed: panic: assignment to entry in nil map <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1684525>
<mcphail> I don't know if it is anything to do with the "nil" plugin type but the same error happens if I change it to "make"
<jdstrand> mvo: oh, I'm already doing that
<jdstrand> mvo: shoot. did you do it already?
<jdstrand> (that is why I didn't respond immediately)
<kyrofa> popey, thanks for the ping, I'll take a look
<mvo> jdstrand: meh, yes, all fixed already, sorry for the ocd, I still hope to push a new 2.30~rc3 tonight thats why I pushed hard on this
<jdstrand> mvo: right, well, I was pushing hard to get all the stuff in too
<mvo> :(
<mvo> sorry
<jdstrand> ok, well, let me sync and see what happens
<jdstrand> mvo: no, thank you. sorry I didn't see the ping
<mborzecki> mvo: restarted release/2.30 travis build, snap store returned 418 in tests/main/interfaces-snapd-control-with-manage
<mvo> mborzecki: thank you
<mborzecki> mvo: i'm also looing at #4100, https://github.com/snapcore/snapd/pull/4100/files#diff-67fc5f3eff966220ca21940106198de5R96 this is just for future reference, right?
<mup> PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4100>
<elopio> popey: https://bugs.launchpad.net/snapd/+bug/1737197
<mup> Bug #1737197: Go HomeDir reads /etc/passwd, not $HOME <snapd:New> <https://launchpad.net/bugs/1737197>
<popey> thanks
<kyrofa> popey, I can't duplicate :(
<mvo> mborzecki: I was not following this, not sure what the status of s.iface.AutoConnec() is currently
<mvo> mborzecki: I think zyga knows
<popey> kyrofa: wat, and you're logging in with your ubuntu one sso user/pass and 2fa?
<kyrofa> Yeah
<kyrofa> popey, can you try export-login instead?
<kyrofa> It should use the same code path
<popey> what's export-login? Is it documented?
<kyrofa> `snapcraft export-login --snaps <snap you're enabling> --channels edge`
<kyrofa> Not yet, it's how we're going to support circle CI
<kyrofa> I mean, you can run --help of course
<kyrofa> I'll be writing a tutorial on it
<popey> so for travis I should use that too, instead of the enable-ci travis?
<kyrofa> You can, but no, this is just a test
<kyrofa> I'm curious if it fails the same way
<popey> uh
<kyrofa> Wow, I didn't even give you the right command :P . You need a file
<popey> it fails asking for a file
<ogra_> mvo, i'm fine to keep it, doesnt look like there is any hurry to fix ...
<kyrofa> Yeah, you're exporting the login to a file that you can then use to login with `snapcraft login --with <file>`
<ogra_> mvo, though if you have a quick fix, feel free to grab it
<popey> kyrofa: whats the right command?
<kyrofa> `snapcraft export-login --snaps <snap you're enabling> --channels edge foo`
<kyrofa> Then your login will be in foo
<ogra_> mvo, oh, wait ... silly me ... we re-added lsb-release to the core snap tarball a while ago (together with locales) ... it can actually be closed ... /me does so
<kyrofa> (which you can just delete. It's just the macaroons)
<popey> kyrofa: fails
<kyrofa> Same way?
<popey> https://www.irccloud.com/pastebin/Sl1kCNFt/
<mup> Bug #1689037 changed: apt-add-repository in classic snap on core always adds artful repos <Snappy:Fix Released by ogra> <https://launchpad.net/bugs/1689037>
<kyrofa> popey, can you try running that with debug enabled? `snapcraft -d export-login [...]`
<kyrofa> You'll see a few API hits, maybe we can get some insight from that
<popey> hahahahahahahaahahahahahaha
<popey> I know what it is
<popey> this is ace
<popey> https://www.irccloud.com/pastebin/WRpBeKif/
<popey> I bet you a pound that api has moved
<popey> bet it's not /dev anymore
<kyrofa> 404...
<kyrofa> Oh com eon
<kyrofa> I JUST added support for that
<kyrofa> But why did it work for me?!
<pedronis> afaik it's where it always was
<popey> if I had a shrug emoji, I'd likely use it here
<kyrofa> Also, the fact that a 404 is turned into "invalid creds" is annoying
<popey> I agree :)
<popey> would you like a separate bug for that? :)
<kyrofa> I had the same problem when I was posting with the wrong package format
<kyrofa> Made it take forever to figure out what was happening. I've never typed my password so many times
<kyrofa> popey, no, just put a royal whine in the bug
<popey> ok
<kyrofa> Hey cprov, any idea why this is a 404? https://www.irccloud.com/pastebin/WRpBeKif/
<Chipaca> popey: here, Â¯\_(ã)_/Â¯
<kalikiana> +1
<ogra_> mvo, i linked all PRs to bug 1701018
<mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:In Progress> <https://launchpad.net/bugs/1701018>
<kyrofa> popey, can you run enable-ci with -d as well?
<ogra_> (it is largely done ... just missing a dragonboard PR)
<kyrofa> I'm not 100% sure it hits the acl API
<popey> sure
<kyrofa> I wonder if your login actually fails and then we malform the acl URL or something
<popey> "POST /dev/api/acl/ HTTP/1.1" 404 None
<diddledan> can I get someone who knows python combined with gtk/wayland to have a look at this person's snapcraft problem? https://forum.snapcraft.io/t/snap-to-test-gtk3-glibc-2-25-not-found/3073
<kyrofa> Ah okay good
<diddledan> I can't figure out why it's segfaulting but I can replicate it locally
<popey> kenvandine: might be up your street ^
<kyrofa> popey, I have to run for just a bit, but I'll look into this a bit more when I return
<diddledan> thanks popey
<kenvandine> diddledan, can you try building it with the gnome-3-26 ppa enabled?
<diddledan> I'll give it a go
<kenvandine> i'm not sure if libwayland in xenial works right
<kenvandine> diddledan, i'd be very interested in the results :)
<kenvandine> please let me know
<kenvandine> diddledan, i've hit a separate issue today that made me worry about libwayland/gtk in xenial
<mvo> ogra_: thanks
<mup> Bug #1705486 opened: SPI not working on Raspberry Pi with ubuntu core <snapd:Fix Released> <Snappy:Fix Committed> <https://launchpad.net/bugs/1705486>
<sparkiegeek> popey: you bet a pound you say? :)
<sparkiegeek> popey: curl -d '{"permissions": ["package_access"]}' https://dashboard.snapcraft.io/dev/api/acl/ -H 'Content-Type: application/json'
<sparkiegeek> works fine here
 * popey blows the dust off his wallet
<sparkiegeek> popey: none of them round pounds either! ;)
<diddledan> kenvandine: good instincts! using the ppa fixes it right up
<kenvandine> diddledan, good to know
<diddledan> I guess the xenial archive has a buggy libwayland or a buggy libgtk3
<kenvandine> diddledan, i think it might not be protocol compatible with artful
<kenvandine> or really anything newer than xenial
<kenvandine> but i fear updating libwayland might require more than just a rebuild of gtk
<kenvandine> so hard to sru
<diddledan> gah
<kenvandine> nothing wrong with using the gnome-3-26 ppa though :)
<kenvandine> it's just not obvious to developers to do that
<kenvandine> i'd like snaps built against gtk3/wayland from xenial to actually work in wayland :/
<diddledan> yeah
<mup> PR snapd#4382 opened: snap: show header/footer when `snap find` is used without arguments <Created by mvo5> <https://github.com/snapcore/snapd/pull/4382>
<mvo> jdstrand: how do you feel about 4100? it looks good to me but gustavo is not around for a re-review for a couple of days. so we either need to merge without him or push it out into 2.31. wdyt?
<jdstrand> mvo: I answered his questions and adjusted for the lock files. we have an ack on the the naming. the only thing technically outstanding is the 'w' random_seed, but it is needed by gpg for encryt/sign
<jdstrand> mvo: I think it is safe to land. if Gustavo doesn't like the random_seed, we can do a followup PR
<mvo> jdstrand: ok
<jdstrand> mvo: I will prepare a PR for 2.30 for that then
<jdstrand> mvo: I've also got extra tests for 4374
<jdstrand> mvo: I'll be updated pr 4375 too
<mup> PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4375>
<jdstrand> mvo: (the 2.30 PR)
<mvo> jdstrand: aha, nice. thank you
<mvo> jdstrand: its in
<mup> PR snapd#4100 closed: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4100>
<jdstrand> mvo: thanks fthanks!
<mvo> jdstrand: :) thank you, looking forward to the 2.30 PR
<mvo> jdstrand: do you have more pending for 2.30? just asking so that I can plan the 2.30~rc3 accordingly
<mvo> (i.e. no pressure or anything)
<jdstrand> mvo: fyi, this was the change for 4374: https://github.com/snapcore/snapd/pull/4374/commits/29c3619b2c217d0003013733c7d1c91328b2b341
<mup> PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4374>
<jdstrand> mvo: let me double check
<jdstrand> biometrics is blocked but can be 2.31. screen-lock I was planning on doing today, but could be 2.31 if needed. layouts and xdg-settings were post 2.30. 4375 is 2.30, ssh/gpg upcoming PR is 2.30
<jdstrand> the policy update xxxiii was committed already
<jdstrand> ah, jhenstridge's gnome-online-accounts would be nice to have in 2.30, but I don't think it is ready (I reviewed it hoping it would get in)
<jdstrand> mvo: so, bottom line, from me, 4375 and new ssh/gpg
<jdstrand> mvo: I'm going to work on screen-lock and if you respin/whatever and want to pull it in, cool, if not, fine
<kalikiana> kyrofa: hey
<mvo> jdstrand: thank you. screen-lock is probably fine for 2.30, I can do 2.30~rc3 monday morning, not much will happen over the weekend anyway (sergio is on vac so no QA today) :)
<jdstrand> mvo: 4375 is messed up. let me get you the ssh/gpg for 2.30 and circle back
<mvo> jdstrand: its ok, its targeted for master
<mvo> jdstrand: to get travis results
<mvo> jdstrand: but we need to re-target to 2.30
<jdstrand> I don't see where to do that in the ui
<mvo> jdstrand: [edit] next to the title
<mvo> jdstrand: its a bit confusing :)
<mvo> jdstrand: just target to 2.30 and ignore the warning
<jdstrand> ok
<kalikiana> kyrofa: I'm about to eod soon... but wondering if I can ask you to have a look at snapcraft#1800 (perhaps easier to see just the changes: https://github.com/kalikiana/snapcraft/compare/to_statement...kalikiana:on_to) when you have some time, this would be the second piece of the spec, basically looking for some feedback on the approach before finishing this with tests etc.
<mup> PR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
<jdstrand> that was not particularly discoverable
<mvo> jdstrand: no disagreement :)
<jdstrand> ok, back to no conflicts
<mvo> jdstrand: yay
<mvo> thanks jdstrand
<mup> PR snapcraft#1800 opened: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
<jdstrand> mvo: so travis doesn't run on non-master?
<mborzecki> mvo: hmm, looks like we have no luck running the tests today
<elopio> I'm relocating... afk for a while
<mvo> mborzecki: all? or a particular PR?
<mvo> mborzecki: I had some successes. but it sad that tests are unreliable
<mvo> jdstrand: it should run on non-master, it did in the past, I'm not sure what changed
<kalikiana> Now to call it a day/ week
<kyrofa> kalikiana, I'll take a look in a bit
<kalikiana> kyrofa: Grand, thanks. No particular rush. FYI also shared the notes of our brainstorming for  the record
<kyrofa> kalikiana, sounds good. Have a wonderful weekend!
<mborzecki> mvo: had to restart release/2.30 job again, it failed with some dns resolution issues this time
<kalikiana> Thanks! Have a nice last day of the week yourself!
<mvo> mborzecki: thanks! and annoying
<mvo> mborzecki: annoying that its so unreliable currently
<jdstrand> mvo: fyi, ssh/gpg for 2.30 will be submitted in a few minutes. had to unravel the testsuite changes which took a little longer than expected
<mup> PR snapd#4383 opened: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4383>
<om26er> Hey! can someone point me to an example that extends the dump plugin.
<om26er> kyrofa: ^
<kyrofa> om26er, hmm... let me see
<kyrofa> om26er, none that I know of off the top of my head, but there are several examples of local plugins if that's all you're looking for
<kyrofa> (I have one that inherits from make, for example)
<om26er> kyrofa:  I am trying to do what you suggested here https://forum.snapcraft.io/t/dump-source-per-architecture/3069/2
<kyrofa> I thought that might be it
<om26er> kyrofa: any example that inherits a plugin will help
<kyrofa> om26er, here's one: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-redis.py
<kyrofa> There are a few in that repo
<kyrofa> om26er, that particular example isn't necessary anymore with some new features the make plugin grew a while back, but it's still used
<om26er> kyrofa: do you know which variable contains the 'source' ?
<kyrofa> om26er, you see how I overwrote the `build` method there? You'll want to overwrite the `pull` method
<kyrofa> om26er, you can refer to other plugins in the snapcraft tree for details of how they download stuff
<om26er> kyrofa: alright looking
<kyrofa> om26er, you can also look at the php plugin in nextcloud, which pulls extensions: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-php.py
<om26er> kyrofa: only in my case, I want to alter the `source` url based on arch.
<om26er> that example seems to call the super() method, so its not exactly doing what I want to. But I'll try to figure that out
<kyrofa> om26er, you won't be able to just set a variable and call it good, I'm afraid. You'll need to do the download
<jdstrand> mvo: ok, PR 4374 passed. PR 4374 is in CI now. PR 4383 is in CI now.
<mup> PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4374>
<mup> PR #4383: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4383>
<jdstrand> PR 4375 is in CI I meant to say
<mup> PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4375>
<ikey> hm, promising.
<ikey> https://twitter.com/techieg33k/status/938840281646026753
<ikey> codeweavers retweeted it
<mvo> jdstrand: great
<jdstrand> ikey: nice :)
<ikey> here's hoping :]
<mup> PR snapcraft#1799 closed: tests: update the registered snap fake <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1799>
<mborzecki> mvo: 5 restarts later, the release/2.30 branch travis job finally completed successfuly
<kyrofa> Agghhhh /me throws all raspberry pis out of his window
<kyrofa> We have awesome moonshot ARM servers. I want a VM on one
<mvo> mborzecki: yay!
<mup> PR snapd#4383 closed: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4383>
<jdstrand> mvo: thanks!
<mvo> jdstrand: thank *you*
<jdstrand> mvo: fyi, I keep restarting PR 4375 since it is failing in unrelated ways
<mup> PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4375>
<jdstrand> mvo: but PR 4374 passed
<mup> PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4374>
<mup> PR snapd#4384 opened: interfaces/desktop,unity7: allow status/activate/lock of screensavers <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4384>
<mup> PR snapd#4385 opened: interfaces/desktop,unity7: allow status/activate/lock of screensavers for 2.30 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4385>
<jdstrand> mvo: fyi screenlock ^ for master and 2.30
<jdstrand> mvo: that's it for things I'm driving for 2.30
<mvo> jdstrand: cool, I have a look
<gsilvapt> kyrofa, you around tonight?
<kyrofa> gsilvapt, I am
<gsilvapt> kyrofa, could we wrap up the string? I've tried a few combos but I'm still unable to get it right
<kyrofa> gsilvapt, sure, where did you leave off?
<gsilvapt> I understood I need to pass in the arguments to %(prog) and %(version). So I tried adding .format when the variable we defined is called and pass in "snapcraft", snapcraft.__version__
<gsilvapt> None of those works and the string literal is still printed to the console
<kyrofa> gsilvapt, .format is the new format string method, you need to use the old one
<kyrofa> I sent you a link yesterday, I think?
<gsilvapt> You did. Lets see if I can try that
<gsilvapt> kyrofa, but do I need to define a name placeholder too? Or that is not necessary for this?
<kyrofa> gsilvapt, I'm not sure I understand what you're asking
<gsilvapt> In the link: https://pyformat.info/ There's a section called Named Placeholders.
<gsilvapt> I'm trying to figure out if I need to define a 'data' placeholder to pass into the string variable
<kyrofa> gsilvapt, yeah you need to create a dict corresponding to the named placeholders you have in the string
<gsilvapt> Hum, let's try that
<kyrofa> print('test is a %(test)s' % {'test': 'foo'})
<kyrofa> >>> test is a foo
<gsilvapt> Finally it worked, yey.
<gsilvapt> kyrofa, yea, I tried that to avoid creating another variable. My issue now will be formatting. You guys will kill me :D
<gsilvapt> Actually, now snapcraft --version is outputting something different. Weird, I'll have to review the command
<gsilvapt> kyrofa, I might need to re-do the decorator. snapcraft --version is printing snapcraft, version snapcraft, version 2.34
<gsilvapt> It seems it is adding my message to a previous one defined somewhere else?
<kyrofa> gsilvapt, I'll have to see code to know what's happening
<gsilvapt> snapcraft version is printing the desired output though
<gsilvapt> Perhaps I can push this to my fork and sent the link to you, kyrofa ?
<kyrofa> gsilvapt, of course
<gsilvapt> kyrofa, here's version.py https://github.com/gsilvapt/snapcraft/blob/update_version_command/snapcraft/cli/version.py
<gsilvapt> and init: https://github.com/gsilvapt/snapcraft/blob/update_version_command/snapcraft/cli/__init__.py
<kyrofa> gsilvapt, the variable needs to hold the template string, not the completed template
<kyrofa> gsilvapt, click will complete it, and your command also needs to complete it
<kyrofa> So instead of doing the % thing in the global, do it in the command
<kyrofa> And just hand the template string to click
<gsilvapt> kyrofa, I'm still unable to have snapcraft --version working right
<kyrofa> gsilvapt, push again
<gsilvapt> So I have the variable and pass in the % part in the click.echo command (in version.py). This is still working as expected
<gsilvapt> The cli/__init__.py is still repeating itself
<kyrofa> gsilvapt, I think that's a kwarg, it needs to be message=MESSAGE_SNAPCRAFT_VERSION
<gsilvapt> this works: @click.version_option(message = MESSAGE_SNAPCRAFT_VERSION,
<gsilvapt>                       version = snapcraft.__version__)
<gsilvapt> Sorry for the weird formatting.
<kyrofa> Yeah that looks more like it
<gsilvapt> Ok, I'll try prepping this up before updating the PR. Thanks for your help!
<kyrofa> Sure thing
<gsilvapt> Hum, I'm not sure if I can squash the commit right now though. There has been so many pushes now. Is that okay?
<gsilvapt> kyrofa, ^
<kyrofa> Yeah that's fine
<gsilvapt> I really hope I'm not messing up the PR with this thing.
<gsilvapt> kyrofa, Now we have another issue. The unit test is not passing again. The cli command outputs run, version 2.34 and the other prints snapcraft, version 2.34
<kyrofa> gsilvapt, which is why I suggested not using %(prog)s
<gsilvapt> hardcoding snapcraft works, yes
<cprov> kyrofa: dashboard.s.io/dev/api/acl seems to behave fine on empty payloads, https://pastebin.canonical.com/205119/
<cprov> let me check if it would 404 on bad payload, unknown snap name, for instance
#snappy 2017-12-09
<kyrofa> cprov, indeed, I haven't been able to get a failure myself, it's popey that's breaking everything
<kyrofa> cprov, thank you for your help :)
<popey> Hah
<cprov> kyrofa: right, unknown snap name/series or snap_id would result in a 404, also the body of the 404 response is a json error
<popey> Oh god. I bet I know what it is
<cprov> would point what is wrong
 * popey gets out of bed to test a theory
<cprov> popey: you working on this time ?
<cprov> ah
<kyrofa> popey, not registered?
<popey> lemme just test as is first
<popey> to confirm it still happens
<popey> wait, not registered, the snap has to be registered first?
<kyrofa> popey, yeah, otherwise it's unknown by the store
<popey> ok, well that't it then
<popey> this snap isn't registered
<kyrofa> Yep, I just tested that out and got the same
<popey> (nothing in the docs says it should be)
<popey> I mean, I may be being dumb here, but neither the current docs nor the wall of text snapcraft prints, says it has to be registered first
<popey> Sorry :(
<cprov> popey: agreed, can you please file a bug in LP, we will update the doc. Just checking, the 404 response body was clear about why it failed, right ?
<popey> (404 isn't the kind of error message I'd expect given this circumstance)
<cprov> correct, it's a 400
<popey> well, snapcraft doesn't give a good error
<popey> "Snap name not registered" is preferable (or similar)
<popey> and running snapcraft -d gives me a 404, which also isn't "snap name not registered"
<kyrofa> cprov, we're somehow printing "invalid creds" instead
<popey> ya
<popey> cprov: what project should I file the bug in?
<cprov> lp:snapstore
<cprov> kyrofa: the 404 body contains the resource-not-found identifier and `Snap not found for the given snap name: '{}' and series: '{}'` description, the code from enable-ci might need a patch to treat it correctly
<kyrofa> cprov, ah very good
<popey> https://bugs.launchpad.net/snapstore/+bug/1737276
<mup> Bug #1737276: Store returns 404 for unregistered snap <Snap Store:New> <https://launchpad.net/bugs/1737276>
<satoshi> Hello!
<satioshy> clear
<RyoshiKayo> What's the significance of a version number that has '+git' after it? Do you use that  when the package is from a git repo?
<Nafallo> hi. I'm using a desktop app, but compose doesn't seem to be picked up. any hints regarding where to start looking for a solution?
<mcphail> ikey: would it be a silly idea to have the lsi functionality in the solus core snap rather than a separate snap? the reason i'm asking is it would be useful to have a core snap with sane sdl versions etc for packaging non-steam games
<mcphail> a generic core gaming snap would be brilliant
<ikey> so turn LSI snap into steam stub?
<ikey> and runtime-gaming as the support environment
<mcphail> yes
<ikey> sure - the only part of LSI in the lsi snap btw is the linux-steam-integration binaries and glxgears/glxinfo/steam
<ikey> we *could* expose lsi-exec within the main runtime snap itself
<ikey> to support proprietary games and redirect them
<ikey> but it'd need apparmor help
<mcphail> so your solus sdl etc are in the core snap?
<ikey> yeah
<mcphail> aah. that's probably enough in itself then
<ikey> linux-steam-integration snap is a tiny 3mb
<ikey> whereas solus-runtime-gaming is like 280mb or so
<mcphail> ok. will need to check it out
<ikey> its still in edge and will likely stay that way until such point as i can get full parity in apparmor for steam
<mcphail> this is brilliant, btw. thanks for making this
<ikey> lots of stuff is wonky and its hopeless with full confinement
<ikey> ah no worries
<ikey> if you wanna work towards making this a generic runtime then im happy to do so with input from other snapcrafters and we'll work out a plan for keeping it stable
<mcphail> cool. i'm going to make a few game snaps against the ubuntu core and see ehat problems i hit
<ikey> ok
<mcphail> i've already hit a few snags, but those seem apparmor related rather than linker related, and are already being fixed
<ikey> ah ok
<mcphail> but snaps seem a really great way to package games
<ikey> they are - but there is a gotcha
<ikey> lets not recreate the mistake of 10,000 indie steam devs
<ikey> and release&forget
<ikey> they're the primary reason lsi exists lol
<mcphail> indeed. but release and forget would cause fewer problems with lsi :)
<ikey> to an extent, it still derives from a rolling distro ^^
<mcphail> most of the breakage i've seen over the past 5 years has been the c++ abi break. hopefully lsi would tarmac over that
<ikey> as long as libstdc++ isn't vendored you'll be fine there
<ikey> the lsi-exec environment just prevents libstdc++ vendoring
<thresh> hello.  I've just booted into live ubuntu 17.10 via usb stick.  I've installed my .snap using sudo install --dangerous ./vlc.snap
<thresh> now when I try to launch it, I get cannot create lock directory /run/snapd/lock: Permission denied
<thresh> apparently an apparmor policy or something prevents me from running it
<thresh> what can I do about it?
<thresh> I wonder if that's something I missed in my snapcraft.yaml or?
<ogra_> thresh, snaps do not yet run on top of live sessions ... (due to apparmor not getting along with the livefs'es overlayfs)
<thresh> bah!
<thresh> there goes my attempt at actually checking things :-)
<diddledan> LSI should totally be renamed Linux Steam Detox so that you can play with LSD
<ikey> linux in the sky with diddledan
<kennyloggins> diddledan: I guess its how you look at the world, dan.
<thresh> [  627.189105] audit: type=1400 audit(1512832800.481:36): apparmor="DENIED" operation="open" profile="snap.vlc.vlc" name="/etc/vdpau_wrapper.cfg" pid=2957 comm="vlc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<thresh> I think this prevents my vlc snap from using the hw decoding
<thresh> how would I go about extending this policy?
<thresh> can I do it in the snap?
<Chipaca> thresh: not sure why you're seeing that denied; afaik the vlc snap uses the opengl interface and that's included there
 * Chipaca downloads the snap to see
<thresh> Chipaca, grab a http://nightlies.videolan.org/build/snap/vlc_3.0.0-git-153-g0af7adb_amd64.snap
<thresh> this is the one I'm testing
<thresh> the one on the store is very old
<Chipaca> ah
<Chipaca> thresh: "snap interfaces vlc" should prove illuminating then
<thresh> here's a snapcraft.yaml : http://git.videolan.org/?p=vlc/vlc-3.0.git;a=blob;f=extras/package/snap/snapcraft.yaml;h=e441b11cbd5672f02f3a37764fb701a5256ef9cf;hb=0af7adbca81a88218720851b803a5f9b1fcc8937
<thresh> well opengl is there indeed, but I dont find anything similar to "vdpau" on `snap interfaces`
<Chipaca> access to read /etc/vdpau_wrapper.cfg is part of the opengl interface
<Chipaca> thresh: is the opengl interface connected?
<thresh> yes
<thresh> thresh@blackbox:~$ snap interfaces vlc | grep -i opengl
<thresh> :opengl                  vlc
<thresh> I'm on a fully updated 17.10 if that matters
<Chipaca> thresh: running out of ideas. If you can wait for zyga to be around (monday?), or post to the forum for ditto, that'd probably be best
<thresh> thank you Chipaca!
<ikey> i was under the impression that the vdpau rule was only added very recently to opengl
<Chipaca> ah!that might be it
<Chipaca> thresh: what snapd are you on?
<thresh> that'd be 2.28.5+17.10
<ikey> yeah you won't have that rule
<ikey> it happened in the last couple weeks iirc
<Chipaca> thresh: are you on ubuntu?
<Chipaca> ah yes you said 17.10
<thresh> yeah 17.10
<Chipaca> thresh: snap refresh core --beta
<thresh> any eta this hits regular users?
<ikey> it was added in 4b996f4024
<ikey> which was tuesday lol
<thresh> cause sure it's fine if I can test this, but I'd like my users to have hw decoding too :-)
<Chipaca> thresh: wait, that 2.28.5 version, where did you get it from?
<Chipaca> thresh: 'cause i want the one from 'snap version', not dpkg
<thresh> ah I used dpkg -l | grep -i snapd
<Chipaca> thresh: (on ubuntu snapd et al will run from the core you have installed, if it's newer than the distro one)
<thresh> $ snap version
<thresh> snap    2.30~rc2
<Chipaca> thresh: so you're _probably_ on 2.29, which still doesn't help you, but hey
<thresh> ditto snapd
<ikey> o shiny
<Chipaca> thresh: a'ight
<thresh> do I need to reboot or something
<thresh> it's still the same error afaict
<Chipaca> thresh: nope; although if it was added tuesday you might need to be on edge to see it
<thresh> right :-)
 * ikey is suddenly curious exactly what vdpau_wrapper.cfg is even coming from
 * thresh runs --edge
<thresh> probably some evil nvidia package
<ikey> no i mean in terms of the snap not seeing / the same way
 * ikey is suddenly kerfuffled
<Chipaca> ikey: /etc/ is a kerfuffle wrapped in a mess wrapped in a lost brexit document
 * ikey sticks his fingers in his ears about brexit
<ikey> bad enough they're trying to force a hard border back on me atm :P
<Chipaca> ikey: gibraltar must be super happy about everything, also
<thresh> thanks a bunch sirs
<Chipaca> thresh: did that do it?
<thresh> --edge didnt solve it too, but I guess it's too old too
<thresh> 2.30~rc2+git469.69b980d~ubuntu16.04.1 is the "snap version" I get
<thresh> but it's still good to know it was worked on
<Chipaca> thresh: just in case (and it shouldn't need it, but it might be a on-boot thing? zyga knows more), did you reinstall the vlc snap with the new snapd?
<ikey> it could be stale mount namespace
<thresh> I havent, but will do
<Chipaca> yeah, might be
<ikey> ive had that happen when changing nvidia driver stuff
<thresh> which reminds me I'll need to test this with neauveueueueu too
<thresh> (add o somewhere)
<ikey> lol
 * ikey still can't say that word
<Chipaca> ikey: it's easy: start with nu as in "nude", and then hit the floor with your front teeth
<ikey> XD
<Chipaca> thresh: awesome that you're testing this! we try to cover all the opengl variations but there's just too many
 * ikey just choked..
<Chipaca> ikey: no, no, that's how you say "joaquÃ­n"
<ikey> and like a phoenix i rise again..
<thresh> Chipaca, yeah we're getting real close to 3.0 release;  so feedback from Linux users would be very valuable => we need snaps
<Chipaca> thresh: i can test it on intel Â¯\_(ã)_/Â¯
<Chipaca> i can also test it on an nvidia, but after the weekend
<Chipaca> if i get too close to the steam machine on the weekend i get hissed at
<thresh> no need for now - the hw is in a "known broken" state atm due to problems in ffmpeg
<thresh> I'm just checking if we have any weird crashes when setting the hw decoding up
<thresh> (we do)
<ikey> btw is this a new vlc snap?
<ikey> or is this the one thats been rotting on the store since 1942?
<thresh> it's a new one yes
<ikey> phew xD
<thresh> It's my fault
<ikey> even surprised vdpau wrapper is needed these days
 * Chipaca 's go for the shame bells but likes vlc too much
<thresh> hopefully in a week or so I'll push a recent one
<ikey> i remember years back you had to edit it to stop the smurf effect on flash and vlc
<Chipaca> thresh: the cool kids have edge published from CI :-p
<thresh> Chipaca, we do
<thresh> the 153 should be there
<Chipaca> thresh: not in the store it ain't
<thresh> unfortunately we also broke the snapcraft website
<ikey> xD
<thresh> so it's Server Error all over for me
 * ikey did that a couple weeks ago
<ikey> high five :p
<thresh> haha
 * ikey could do with some automation on the LSI snaps..
<ikey> over 1.5hrs to build them atm
<thresh> I do a snapcraft push vlc_4.0.0-dev-235-g001b765_amd64.snap
<thresh> anything else I should do to publish it on the edge?
<ikey> snapcraft release vlc $revisionID edge ?
<ikey> assuming vlc is the snap name
<thresh> should be.. thanks
<ikey> and revision ID being whatever push said was the new id
<Chipaca> thresh: ikey: or, snapcraft push --release edge thesnap.snap
<ikey> ooo
<ikey> toys
 * ikey jots that down
<Chipaca> ikey: snapcraft push --help
<ikey> but
<ikey> but then i have to read
<ikey> as a linux user i take offence to that notion
<Chipaca> ikey: remind me what do you do with the thing you jot down
<ikey> uhm
<ikey> *trapped*
<Chipaca> ikey: and no border!
<Chipaca> \o/
<ikey> onoes lol
<ikey> fwiw i forget how to use my own tools too
<ikey> every friday when i sync the solus repos, i check "ferryctl help pull" because every week i forget the order of the parameters
<ikey> every friday without fail.
<ikey> well. barring my own fail ofc
<thresh> many thanks
 * ikey gets back to rebuilding everything that ever depended on gfortran
<Chipaca> ikey: wait until you find out about cron
<ikey> lol i won't even do systemd timers
<ikey> noped my way out of them paper bags sharpish
<Chipaca> ooh, ooh, use a systemd timer to run an 'at' job
<ikey> ..oh thats evil
<ikey> yet somehow tempting..
<thresh> --release candidate,beta for 3.0 then
<thresh> and edge for 4.0
<thresh> in your store tomorrow morning eu time
#snappy 2017-12-10
<iawesome404> Hello. I am trying to install Ubuntu Core on my raspberry pi 2. When i tried to login to my ubuntu sso account it says that i can't connect to localhost
<ikey> how do i make old snap versions go away..?
<ikey> i have like 3 versions of solus-runtime-gaming mounted
<ikey> and they're not small
<mcphail> ikey: sudo snap remove packagename --revision=revnumber
<ikey> right but shouldn't GC be automatic..?
<ikey> im updating - i dont want what will become dozens of backversions
<ogra_> ikey, you always have three versions of the snap for rollback support
<ogra_> typically the original first-installed one (to go back to factory state) and the two latest ones to go back and forth between them
<ogra_> admittedly the factory bit should be discussed ... but as long as we have roolback support the last two installed revisions will always be needed
<ogra_> *rollback
<ikey> ah so 3 backversions?
<ikey> ok well as long as there is a cut off point thats fine :D
<ikey> well. 2 back and current
<ogra_> yeah
<ikey> alright thats fine then thanks :D
<ikey> panic over
<ikey> xD
<ogra_> :D
<Chipaca> ogra_: ikey: it being 3 isn't about factory state, it's about what's the minimum you need to ensure that if you go forwards and get into trouble, you're left somewhere from which you can still go backwards
<ikey> yea
<Chipaca> dropping it to two leaves some corner cases from which, if you get into trouble, you're left at a revision with no rollback
<Chipaca> dropping it to 1 is embracing chaos
<Chipaca> :-)
<mup> Bug #1737427 opened: snapd: Missing Unlock before return in package daemon, func sysInfo <release> <resource> <semaphore> <snapd> <unlock> <Snappy:New> <https://launchpad.net/bugs/1737427>
<phoe_> Hey - I'm trying to install lxd on debian via snap as documented on https://stgraber.org/2017/01/18/lxd-on-debian/
<phoe_> on `snap install lxd` I get: cannot bind-mount the mount namespace file /proc/2230/ns/mnt -> lxd.mnt: Permission denied / support process for mount namespace capture exited abnormally
<phoe_> How can I start debugging this?
<phoe_> Are there any snapd logs that I can inspect or any -v flag that I could pass anywhere?
<phoe_> Oh wait a second... This might be this apparmor bug. Let me try to disable it and reboot.
<Chipaca> phoe_: that sounds like fun
<phoe_> Chipaca: yes, it sounds like fun
<Chipaca> phoe_: it might be snapd thinking you don't have apparmor when you do (or viceversa)
<phoe_> https://i.imgur.com/PlhMiZz.jpg
<phoe_> I just saw logs in journalctl stating that apparmor denied something.
<Chipaca> phoe_: but the person to ask about this is zyga; he'll be around in the morning (CET)
<phoe_> So let's see if `systemctl disable apparmor.service && reboot` helps
<phoe_> Chipaca: thanks, I will.
<Chipaca> phoe_: apparmor is awesome, but the transition into using it finds bugs Â¯\_(ã)_/Â¯
<phoe_> also debian does not natively support snapd yet.
<Chipaca> (same is true of any security module)
<Chipaca> phoe_: i thought that had changed recently
<Chipaca> but, i'm not an expert on that side of things
<phoe_> Chipaca: not that I know of.
 * Chipaca isn't sure what he _is_ an expert of
<phoe_> ...wait a second
<phoe_> wait, wrong
<phoe_> I am wrong
<phoe_> snapd is supported, *lxd* is not
<Chipaca> ah
<phoe_> hence my confusion
<phoe_> oh look, `snapd install lxd` works. awesome.
<Chipaca> stgraber: can you shed light on this?
<mwhudson> certainly snapd on debian *was* a bit broken thanks to apparmor being on by default in sid now
<phoe_> yes, I am on sid.
<phoe_> I had to disable apparmor.
<Chipaca> mwhudson: o/
<Chipaca> i should run away before i start working by accident
<mwhudson> ok
<mwhudson> i guess it's good news that that helped :)
 * Chipaca is off today
<Chipaca> er, tomorrow
<mwhudson> Chipaca: what with it being sunday for you?
<mwhudson> ah heh
<Chipaca> mwhudson: the ol "it's december and i have too many unspent holidays"
<mwhudson> i do not have that problem this year :)
<mwhudson> or any other year now that my child is at school i suspect
<Chipaca> i blame growing up in the south, where holidays go from july to june
<Chipaca> mwhudson: heh
<Chipaca> yeah, that'd do it
<Chipaca> anyway, byes
<mwhudson> ttfn
<stgraber> lxd is supported on pretty much all distros that ship snapd
<stgraber> we have automatic testing for the stable releases of most (if not all) of those
<stgraber> which doesn't include debian sid since that's obviously not stable
<stgraber> so it may well be that apparmor now being enabled in sid is causing some problems
#snappy 2018-12-03
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: a lower priority thing I sent last week: https://github.com/snapcore/snapd/pull/6251 - the refactoring you asked for
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<zyga> mborzecki: I'd like to mainly land the 2.36 branches: https://github.com/snapcore/snapd/pull/6245 and https://github.com/snapcore/snapd/pull/6235
<mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> I will focus on https://github.com/snapcore/snapd/pull/6190, sorting out my travel
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> I can assist in any reviews
<pstolowski> mornings
<zyga> hey pawel
<zyga> I guess this morning is just us three, no?
<pstolowski> i think so, yes
<mborzecki> zyga: pstolowski: morning guys
<zyga> :-)
<mborzecki> the week of short standups
<pstolowski> hey mborzecki
<mborzecki> zyga: https://github.com/systemd/systemd/issues/10872#issuecomment-443504757 i'm building it right now
<zyga> looking :)
<pstolowski> yeah, i'll likely skip today's, my daughter has a dentist apointment at 15:20
<zyga> hmmm
<zyga> pstolowski: ok
<zyga> pstolowski: I'll bug you for some reviews
<zyga> since it's just the three of us
<pstolowski> sure
<dot-tobias> good morning everyone
<zyga> hey dot-tobias
<pstolowski> zyga: thanks for the review of #6180 ; i'm not sure what to do about public SnapGlobal/Explicit tbh
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<zyga> pstolowski: I tried myself
<zyga> and I found two ways out
<zyga> maybe three if we rewrite tests :)
<zyga> number one is to write a new DeepEquals that ignores private fields
<zyga> I think it is interesting in principle
<zyga> the second idea is to keep this as is
<zyga> I think that's what we should do
<zyga> I would change the name of the variables a little, I wasn't sure what to call them
<zyga> ideas welcome
<pstolowski> zyga: i don't think DeepEquals should ever ignore private feels, it feels like it's no longer deep equals ;)
<pstolowski> *private fields
<zyga> it would be some new comparator, sure
<zyga> but it would help in cases like that
<zyga> PublicEquals
<zyga> or something ish
<zyga> degville: another thing I found valuable today https://www.youtube.com/watch?v=vtIzMaLkCaM :-)
<pstolowski> zyga: i'd keep it as is and continue in a followup
<zyga> ^ recommend watching that
<zyga> pstolowski: yes but please before landing, let's rename the new variables
<zyga> they don't feel good (sorry for being vague)
<pstolowski> zyga: i mean yes, sure, changing names is fine
<zyga> maybe a 3 minute brainstorm with mborzecki could help
<mborzecki> hm?
<zyga> mborzecki: we need two variable names
<zyga> mborzecki: one will tell you that a hook was explicitly defined in yaml, rather than being found in a specific directory on disk
<zyga> mborzecki: another will tell you that a specific plug or slot affects all apps and hooks in a snap, rather than being associated with just a subset of them
<zyga> mborzecki: how would you name those two?
<dot-tobias> Is it possible to detect within my snap if a required interface is already connected? A service in my snap errors out right after the snap is installed, because I have to manually connect the interface.
<mborzecki> zyga: is that in 6180?
<pstolowski> mborzecki: yes
<zyga> aha
<zyga> dot-tobias: I beileve so
<zyga> dot-tobias: but only in a hook
<zyga> dot-tobias: I don't believe this is possible from a snap in general, that is, go and ask if something is connected yet
<dot-tobias> zyga: Ok, I'll test the hook route. Thought about parsing snapctl interfaces -i <required-interface> my-snap-name from inside the service, but that seemed overkill.
<zyga> dot-tobias: please ask pstolowski as well
<zyga> I think this is useful to have
<mborzecki> pstolowski: what exactly SnapGlobal means there?
<pstolowski> mborzecki: it means that given plug/slot is defined at the top-level in the snap yaml
<pstolowski> hmm perhaps TopLevel would be a better name?
<zyga> I was thinking about scope but that doesn't work as well, I like TopLevel
<mborzecki> TopLevel sounds ok, but I'm looking at the original code and it looks a bit confusing
<mborzecki> pstolowski: do i read it right, if you have top level slots in the snap, and say have, one of the slots listed under an app too, then it's no longer automatically bound to all other apps/hooks?
<zyga> mborzecki: yes, that's the semantics
<zyga> mborzecki: plugs and slots are defined implictly by mentioning them in the abbreviated format
<pstolowski> yep
<zyga> mborzecki: such plugs and slots are bound to the apps and hooks that mention them
<zyga> mborzecki: interfaces may be also defined or expanded in the top level
<zyga> unless they are associated with a specific app or plug they become global/toplevel and apply to everything
<zyga> maybe we should call it what it is
<zyga> privilege spearation
<zyga> privilege separation: true, applies to subset
<zyga> no, applies to all executable code
<pstolowski> zyga: what do you think about TopLevel name?
<zyga> yeah, let's go with top level for now
<zyga> Ideally we'd find a name that makes it useful and not just an implementation detail
<zyga> but let's not make perfect the enemy of the good
<mborzecki> enough to move forward
<zyga> https://github.com/snapcore/snapd/pull/6253 needs a 2nd review
<mup> PR #6253: Members of canonical LP group should pass CLA check <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6253>
<pstolowski> zyga: thanks
<zyga>  guys, quick question
<zyga> I'm working on https://github.com/snapcore/snapd/pull/6190/files
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> there are some low hanging fruit inside
<zyga> for instance stuff like https://github.com/snapcore/snapd/pull/6190/commits/f8f2f3b389b920f299f8994a7e4fb96a02c14a19
<zyga> shall I pop that out to a new branch?
<mborzecki> zyga: yeah, looks useful
<zyga> mborzecki: in that case -> https://github.com/snapcore/snapd/pull/6255
<mup> PR #6255: testutil: add File{Present,Absent} checkers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6255>
<mup> PR snapd#6255 opened: testutil: add File{Present,Absent} checkers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6255>
<mborzecki> zyga: i think the fontconfig fix is insufficient for fedora
<zyga> oh?
<zyga> tell more please
<zyga> it made positive effect on all suse versions I tried
<mborzecki> zyga: they use --with-cache-dir=/usr/lib/fontconfig/cache
<zyga> (42.3, 15 and tw)
<zyga> heh
<zyga> is that when we tell mvo on monday ;)
<zyga> why /usr/lib?!?
<mborzecki> zyga: beats me
<zyga> file a bug please
<zyga> not on fedora
<zyga> on snapd for now
<mborzecki> i was chasing down that denial, and couldn't trigger it on f29 cloud image, so went on digging and found this :/  arch uses /var/cache/fontconfig fwik
<zyga> brb, let me make coffee
<zyga> mborzecki: desktop is such a fractured thing
<zyga> so wait
<zyga> on fedora /usr/lib/fonconfig/cache
<zyga> are files there written at runtime
<zyga> or shipped via packages?
<zyga> brb
<mborzecki> written when fc-cache is invoked
<mborzecki> also, fc-cache appears to be tricky for i686 and x86_64, on fedora fc-cache is a script that calls fc-cache-32 and fc-cache-64
<mborzecki> i recall someone mentioning that the cache files are actually a memory dump of a struct or somesuch
<mborzecki> yeah, fontconfig.i686 ships fc-cache-32
<mborzecki> maybe we need a helper to run these tools after all
<zyga> yes, they are
<zyga> I think
<zyga> instead of shipping our own builds of fc-cache
<zyga> we should instead run the cache from the distro
<zyga> and only do this for classic confined snap
<zyga> for strictly confined snaps we should do what we did now
<zyga> that is, provide our own cache
<zyga> but the approach for strict and classic must differ
<mborzecki> zyga: i think the trouble is that the distro may not ship fc-cache for particular fontconfig version in the core snap
<zyga> mborzecki: but that version is rarely used in practice
<zyga> otherwise you would see an improvement
<zyga> right?
<zyga> you are really seeing a snap using your fontconfig
<zyga> straight from the distro
<mborzecki> zyga: my cache, but not my lib version (unless someone tweaked how the snap is built)
<zyga> so wait
<zyga> how can both be true
<zyga> if a program uses fontconfig
<zyga> it is either from core
<zyga> from the snap itself (equivalent)
<zyga> or from the native host libs
<mborzecki> zyga: yeah, so unless tweaked, the snap ends up with whatever libfontconfig was in 16.04, right? that's for both confined and classic
<zyga> of 18.04
<zyga> yeah
<zyga> but classic snaps can be hand made
<zyga> can have any layout inside
<mborzecki> yes, that's what i mean by tweaking the build
<zyga> including vanilla linker
<zyga> so
<zyga> my point is that there's either libs from the host used
<zyga> which imply *cache* from the host
<zyga> or libs from the snap/core
<zyga> which imply cache compatible with that
<zyga> there's no third cache
<mborzecki> aah, i see what you mean, the core lib was rebuilt with cache in /var/cache/fontconfig
<zyga> mborzecki, pstolowski: could you please review https://github.com/snapcore/snapd/pull/6255
<mup> PR #6255: testutil: add File{Present,Absent} checkers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6255>
<pstolowski> zyga: nice! that will be pretty useful, looking
<zyga> pstolowski: and if you can, I need 2nd review on https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<dot-tobias> pstolowski: Is it possible to detect within my snap's application code if a required interface is already connected? snapctl only supports config and service related commands
<pstolowski> dot-tobias: hmm, not really, you could store this fact somewhere in interface hooks as connections happen (but then you also need to do the opposite on disconnect)
<pstolowski> degville: can you remind me where was the doc for interface hooks?
<degville> pstolowski: https://forum.snapcraft.io/t/interface-hooks/8214
<pstolowski> dot-tobias: ^
<dot-tobias> pstolowski: Thanks! Sounds like a good solution for now. I just want to prevent log bloat since my snap's services try to run various interface-dependent commands on app start, but adding exception handling just for this one moment where the snap's plugs are not yet connected is a bit much.
<pstolowski> degville: thanks! is this going to be merged with the main docs?
<pstolowski> dot-tobias: obviously, if you could simply probe and it's cheap, than it's an option too
<degville> pstolowski: it's currently linked to from the general hooks page (https://docs.snapcraft.io/supported-snap-hooks/3795)
<pstolowski> ack, thanks
<zyga> re
<zyga> back to coding
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6246 ?
<mup> PR #6246: spread: show AVC audits when debugging, start auditd on Fedora <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6246>
<mborzecki> off to pick up the kids
<zyga> mborzecki, pstolowski: can you please review the 2.36 PRs https://github.com/snapcore/snapd/milestone/21
<mup> PR snapd#6253 closed: Members of canonical LP group should pass CLA check <Created by kenvandine> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6253>
<zyga> brb
<pstolowski> zyga, mborzecki i'm gonna miss the standup
<mborzecki> ack
<mborzecki> zyga: about cgroups v1 https://github.com/systemd/systemd/issues/10969#issuecomment-442357207 ;)
<zyga> see ;-)
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6185 has 2 +1s, i'm thinking squash merge?
<mup> PR #6185: snap: add new `snap run --trace-exec` call <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6185>
<zyga> looking now
<zyga> yes
<zyga> + on squashing it
<mup> PR snapd#6185 closed: snap: add new `snap run --trace-exec` call <Performance ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6185>
<mborzecki> zyga: i'll open a 2.36 PR
<zyga> wait
<zyga> please merge my two PRs
<zyga> otherwise 2.36 is red
<mup> PR snapd#6256 opened: snap: add new `snap run --trace-exec` call (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6256>
<mborzecki> aah ok, looking
<mborzecki> zyga: #6235 has conflicts now
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<mup> PR snapd#6245 closed: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6245>
<zyga> grumpy about random failures
<zyga> https://github.com/snapcore/snapd/pull/6255 red for 3rd time in a row
<mup> PR #6255: testutil: add File{Present,Absent} checkers <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6255>
<mborzecki> ok, left a note under https://github.com/systemd/systemd/issues/10872
<zyga> mmm
<zyga> hmm
<zyga> so does it work?
<zyga> mborzecki: btw, I need to show you that part in libmount where I think the bug is as well, there's a lock missing
<zyga> maybe we are seeing a pair of bugs
<zyga> mborzecki: will you be around today or are you wrapping up now?
<mborzecki> zyga: you think bugs are like sith?
<zyga> mborzecki: like binary star systems ;)
<zyga> they always come in piarr
<zyga> *pairs
<zyga> mborzecki: I need to break for lunch now
<zyga> mborzecki: will you be here in an hour/
<mborzecki> i'll probably be around later too, need to take kids to the scouts ~5pm
<zyga> ok, ttyl
<kenvandine> zyga: now that my cla check PR was merged the other PR failed cla-check with a KeyError
<kenvandine> but the cla_check PR passed CI... is the LP API just flaky?
<zyga> kenvandine: dunno
<zyga> kenvandine: can you run the check locally?
<zyga> or handle the api key
<zyga> er
<zyga> or handle the key error
<zyga> or maybe there's a cache a
<kenvandine> zyga: it works locally :/
 * cachio lunch
<zyga> hmm
<zyga> eh
<zyga> more failures
<zyga> need coffee
<zyga> going to make coffee :)
<Son_Goku> mborzecki: https://twitter.com/Arrfab/status/1069623805520355329
<cachio> mborzecki, zyga should I create a new gce image for centos?
<cachio> or we are ok
<mborzecki> Son_Goku: yay!
<mborzecki> cachio: yes, please
<cachio> mborzecki, ok
<mborzecki> cachio: i think it's best if you create a new image under a separate name and only switch if the whole suite passes
<mborzecki> cachio: if there are issues with the spread run, i can take a look tomorrow and fix stuff :)
<zyga> re
<zyga> sorry, had to do homework with kids
<zyga> back now
<zyga> cachio: I think a new image will save us time on upgrades so yeah
<zyga> I agrew with what mborzecki said :)
<zyga> FUUUK
<zyga> why does 6255 fail all the time
<cachio> zyga, mborzecki ok, I'll create the new image and make some runs to validate it
<zyga> thanks
<roadmr> zyga: because... if you decompose the 2 as 1 + 1, and do 6(5+1)(5+1) you get 666!!!!!!! evil!
<roadmr> that made no sense at all, sorry
<zyga> roadmr: ha, I wound not be suprirsed by now :)
<zyga> I hate that our test suite has some flaky components
<zyga> and as we add tests and distributions to run against
<zyga> the chance of landing a trivial branch is very low
<zyga> and any attempt takes an hour
<zyga> cannot have velocity with roadblocks like that :/
<zyga> https://people.neilon.software/ :D
<roadmr> zyga: can you find yourself there? I did find myself :/
<zyga> I'd be the extreme underestimator
<roadmr> hehe :) the icons are fantastic btw
<sergiusens> zyga: you should have written better tests! :-P
<zyga> sergiusens: our tests are notoriously flaky :/
<zyga> many are racy
<zyga> some leak stuff but we have no way to tell yet
<zyga> but at this scale
<zyga> it's not even that
<sergiusens> we bit the bullet and stopped development for a while to get all that sorted
<zyga> simple things like archive issues
<sergiusens> yes, leaking and test cross contamination is hard
<zyga> sergiusens: we wanted to do that for a few months but it is unreasonable to do
<sergiusens> at least, if you want speed
<zyga> sergiusens: I want speed, I get asked to focus on a feature I need to do
<zyga> so I do what I'm told
<zyga> and restart those nasty tests
<zyga> sergiusens: I don't disagree
<zyga> I just don't get that choice
<sergiusens> we added it as a roadmap item, "migrate to spread", so it was accounted for, we still have a list of things that did not make it, but we are in a better place now
<zyga> sergiusens: I hope next cycle we can do that
<zyga> spread doesn't work if it must be 100% green across ~5K tests that can almsot each fail on network
<zyga> we either need a smarter UI / runner that can retrigger a single test
<zyga> or change how we land things
<sergiusens> zyga: you should do it during the year crossing cycle, it is shorter and it is nicer to to these sort of things as the end of year holidays come closer
<zyga> last two weeks was "red in 2.36" mode
<zyga> where nothing in a release branch could land
<zyga> sergiusens: this cycle is packed
<zyga> won't queeze more
<zyga> we can do some perf work on snapd though
<zyga> that's valuable
<zyga> but equally frustrating to land :)
<sergiusens> zyga: next year...
<zyga> unless I hack on spread and snapd during weekends and holidays
<zyga> next year, yeah
<zyga> I mean, we always fix the test suite
<zyga> but it's not really done with the effort required
<zyga> mainly about making the failure causes fixed
<zyga> (leaking tests)
<zyga> and racy tests
<zyga> we have so many racy tests that it's not fun
<zyga> this with the requirement to get two reviews means that stuff lingers
<zyga> first until green
<zyga> then on iteration
<zyga> then on making that green
<zyga> then on more reviews
<jdstrand> roadmr: hi! when convenient, can you pull in r1165? (not urgent)
<zyga> mborzecki: if still around, could you review https://github.com/snapcore/snapd/pull/6251
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<roadmr> jdstrand: sure thing! because $REASONS we're on a merging moratorium until tomorrow but I'll merge that tomorrow
<jdstrand> roadmr: np, thanks again
<roadmr> happy to help :)
<zyga> pstolowski: if still around, can you please review https://github.com/snapcore/snapd/pull/6235
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<pstolowski> zyga: looking
<zyga> thank you!
<zyga> pstolowski: FYI: the master version in https://github.com/snapcore/snapd/pull/6233 has more tests
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
<zyga> jdstrand: hey, do you have time to review https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<zyga> we're very short on reviewers this week
<jdstrand> seb128: fyi, I think you might find this helpful: https://forum.snapcraft.io/t/notifications-for-out-of-date-stage-packages/5161/7
<pstolowski> zyga: i'm slightly confused by the delta between #6233 and #6235 - e.g. writeSystemKey vs shouldWriteSystemKey, an extensive comment missing in 6235>
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<mup> PR snapd#6255 closed: testutil: add File{Present,Absent} checkers <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6255>
<zyga> pstolowski: yeah, some things changed as I enabled testing
<zyga> I can backport the whole lot, just the 2.36 branch is the raw essence of the thing
<zyga> and the master branch has more stuff to run unit and spread tests
<pstolowski> zyga: i see, ok
<pstolowski> i thought you forgot to cherry pick something
<zyga> since it is just tests I could cherry pick more
<zyga> but I didn't get reviews :)
<zyga> pstolowski: not sure if you want to but https://github.com/snapcore/snapd/pull/6257 is technically simple
<mup> PR #6257: testutils: split checkers, tweak tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6257>
<zyga> but I didn't mark it as such snice it's a +1332,-994 change
<mup> PR snapd#6257 opened: testutils: split checkers, tweak tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6257>
<pstolowski> zyga: will check it tomorrow; 1 question to the earlier PR
<zyga> looking
<zyga> thanks, replied
<zyga> pstolowski: running interfaces-many test on my laptop makes me want to optimize security setup
<zyga> all that fan noise :)
 * cachio afk
<mup> PR snapcraft#2397 closed: cmake plugin: use native primitives <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2397>
<seb128> jdstrand, thx
<kyrofa> popey, jdstrand: can someone remind me why we require desktop files if using the x11 interface?
<kyrofa> None of the ROS GUI tools have desktop files, or even icons of which I'm aware, and essentially never make sense to run standalone
<kyrofa> They're typically brought up from the CLI
<kyrofa> I'm getting emails from people saying "Dude, I don't even know what a desktop file is, how am I supposed to include one?"
<jdstrand> kyrofa: there is a mechanism to whitelist that, but the reason why we don't by default is because with (at least) unity7, not shipping a desktop file means the user looks in the dash for the application, then launches it from the dash. now it is in the launcher and the application pins to the launcher and unity7 rewrites the desktop file without running through snap run, therefore unconfined
<jdstrand> s/and the application/and the user/
<jdstrand> kyrofa: https://bugs.launchpad.net/snappy/+bug/1643910
<mup> Bug #1643910: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:Triaged> <bamf (Ubuntu):Triaged by 3v1n0> <https://launchpad.net/bugs/1643910>
<kyrofa> jdstrand, wait... if one doesn't ship a desktop file, it _doesn't_ show up in the dash, right?
<jdstrand> kyrofa: actually, I think I referred to the wrong issue as to why we do it (though I'm glad I remembered that one so I could ping in the bug)
<jdstrand> gimme a sec
<kyrofa> Alright
<jdstrand> kyrofa: ok, right, this *is* the bug, but there are two issues in that bug but I only remembered the one, which wasn't the one for the having the check
<jdstrand> kyrofa: so, forget the dash, cause, yes, you need a desktop file for that
<jdstrand> kyrofa: *but* if you launch a program that uses X that doesn't ship a desktop file, BMAF (BAMF Application Matching Framework) tries to be smart and find the application that is running
<jdstrand> kyrofa: that allows it to have something in the launcher, which can then be pinned
<jdstrand> kyrofa: which then ends up with the wrong entry
<kyrofa> jdstrand, that seems like it warrants a warning, not an error, no?
<jdstrand> kyrofa: eg, xmessage does not have a desktop file. if you launch it under unity7, it shows up in the launcher. if you pin that, the desktop file gets written out to .local/...
<kyrofa> I doubt just pinning what I assume is a direct path to the binary is going to work given the required environment
<jdstrand> kyrofa: if this thing is a snap, it gets writeen out to .local/... with the wrong Exec= line that makes it run unconfined
<jdstrand> kyrofa: it is a warning
<kyrofa> jdstrand, it isn't an error popping it into manual review?
<jdstrand> kyrofa: but in practice, in makes no difference because warnings block manual reviews
<kyrofa> Ah
<jdstrand> err
<jdstrand> cause manual review
<kyrofa> Is that intended?
<jdstrand> the warning bit? well, yes, it is intended but it is long known things could be better. the problem is, if it doesn't block at all, no one will see it
<jdstrand> there is a mechanism to whitelist things
<kyrofa> jdstrand, well, the way it is today I have someone who has given up on snaps because it was too hard to even get something into the store
<kyrofa> There must be some middle ground
<jdstrand> they stopped using snaps because of *this* issue?
<jdstrand> there is an easy workaround. provide a desktop file. there is an easy way to get whitelisted-- respond via the store emails or bring it up in the forum
<kyrofa> This one and a similar issue with using usb-raw making it impossible to get to stable
<jdstrand> kyrofa: alternatively, unity7 could be fixed, then the check can go away
<jdstrand> kyrofa: no one communicated to me that someone was flailing due to this issue. I guess I can update the review text to mention bringing it up in the forum
<jdstrand> kyrofa: as for usb-raw, well, that is a hotplug question and done on a case by case basis, but pstolowski|afk is actively working on that
<jdstrand> kyrofa: I suggest commenting in https://bugs.launchpad.net/snappy/+bug/1643910 that this needs to be fixed and escalating through the desktop team
<mup> Bug #1643910: BAMF_DESKTOP_FILE_HINT not set in correct place for unity7 <Snappy:Triaged> <bamf (Ubuntu):Triaged by 3v1n0> <https://launchpad.net/bugs/1643910>
<kyrofa> Can you explain why usb-raw isn't just not autoconnected?
<jdstrand> kyrofa: because it gives access to all usb devices on the system. that is rarely what an application requires
<kyrofa> Well, sure, but that seems like a reason just to deny autoconnection, no?
<jdstrand> it need a ttyUSB, or a mouse, or something. not everything
<jdstrand> kyrofa: ok, we are talking about different things
<jdstrand> kyrofa: $ snap debug get-base-declaration very clearly shows it is only denying auto-connection
<jdstrand>   raw-usb:
<jdstrand>     allow-installation:
<jdstrand>       slot-snap-type:
<jdstrand>         - core
<jdstrand>     deny-auto-connection: true
<jdstrand> kyrofa: ie, that ^ does what you are asking and has been that way for since forever
<kyrofa> jdstrand, interesting, my apologies, indeed, that does indeed do what I'm asking. This email says he couldn't move it to a stable channel, which I just tested is not the case. Sounds like a grade issue instead
<jdstrand> kyrofa: I'll adjust the message for the desktop file, but if this is a stumbling block or you feel it should be escalated, please comment in the bug
<jdstrand> I'd loave to see this fixed in bamf
<kyrofa> jdstrand, that would be great, thanks. Any idea if we have docs for how to properly write/integrate a desktop file that we could also link to? People who hit this may have no idea what a desktop file is, how to write one, or how to get it properly in a snap
<jdstrand> kyrofa: it is in the description that is part of the review message: If using snapcraft, please see https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335#fixed-assets. Otherwise, please provide a desktop file in meta/gui/*.desktop (it should reference one of the 'apps' from your snapcraft/snap.yaml).
<kyrofa> Ah, okay
<kyrofa> jdstrand, speaking of links, there was something else I wanted to talk to you about
<kyrofa> jdstrand, have you ever used shellcheck before?
<jdstrand> kyrofa: yes
<kyrofa> jdstrand, you know how it provides an error code for every issue which has a wiki entry associated with it?
<kyrofa> jdstrand, think it would be useful for snappy-debug to do something similar?
<jdstrand> yeah. snappy-debug needs a lot of resources put on it
<kyrofa> Oh don't get me wrong, it's super useful
<jdstrand> as it stands, it has had no formal design or resources put on it
<kyrofa> Yeah fair enough
<jdstrand> I have cards and work items for it, but it is all way down the list after approved stuff and things for the snapd, et all
<jdstrand> al*
<kyrofa> Makes sense
<jdstrand> kyrofa: no, I know what you mean. it's handy. I just want you to know that I know it needs love :)
<jdstrand> I try to make sure it continues to be handy
<kyrofa> That's appreciated. Do the review tools have design docs and time assigned to them?
<jdstrand> hopefully I can get more time to look at it. patches welcome if you or anyone else wants to work on it (though, you can see how many resources are put on it-- it was pretty hastily thrown together)
<kyrofa> Yeah my next suggestion was going to be: do they have their own issue trackers? We all benefit from these tools, I see no reason we shouldn't all be contributing to them
<jdstrand> kyrofa: the review-tools do not have design docs. there is understood maintenance time on them
<jdstrand> kyrofa: they have the ability to trump other work though since the world can burn if they don't get updated :)
<kyrofa> Ha! Yes indeed
<jdstrand> kyrofa: they are both proper rojects in LP
<jdstrand> projects even
<jdstrand> https://launchpad.net/review-tools
<jdstrand> https://launchpad.net/~snappy-dev/snappy-hub/snappy-debug
<jdstrand> I guess snappy-debug doesn't have a bug tracker (I thought the parent project did)
<kyrofa> jdstrand, yeah I was just about to ask about that. What is snappy-hub? Historical?
<jdstrand> if I can ever get time to update it, I would do a rewrite
<jdstrand> kyrofa: it comes from the 15.04 days
<diddledan> who do I have to kick to get /dev/shm to be allowed as a layouts target (I want to mount my own tmpfs because the strict naming requirements are impossible to work around for some things)
<jdstrand> diddledan: zyga, but note that it would be /dev/shm or /run/shm depending on the system
<zyga> hmm
<jdstrand> diddledan: I also have a todo to look at LD_PRELOAD for that
<zyga> layouts cannot work with /dev
<zyga> layouts create a read-only snapshot
<zyga> well
<zyga> I should check some things
<zyga> but unless we mount /dev ourselves (I don't think we do)
<zyga> and we actually share /dev/ from host
<jdstrand> zyga: recall /dev/shm is a directory (just for your investigation)
<zyga> this will not be easy (or doable using layoutts)
<zyga> aha
<zyga> sorry, that's important (it's late)
<zyga> it does simplifiy things significantly
 * jdstrand nods
<zyga> but does making /dev/shm private via layouts break IPC with host services?
<zyga> in any case
<zyga> diddledan: let's find a bug about this
<kyrofa> Depends on how the IPC is implemented, but that would be the snap's fault anyway, no?
<zyga> and ping me with a number
<zyga> kyrofa: ish, it depends if we can practically do it or not
<jdstrand> I think for some things it would work and others not
<zyga> indeed
<zyga> but that is something that requires investigation
<zyga> since it's past 10PM I will ack the issue, happily work on it but defer till morning :)
<diddledan> :-)
<diddledan> I'll see if I can find a bug
<diddledan> it's a known issue affecting python-multiprocessing for what it's worth
<diddledan> specifically the python multiprocessing module hasn't been tamed as yet by the snapcraft-preload so anything that needs the module can't run as a snap
<diddledan> as a strictly confined snap*
<jdstrand> diddledan: that was what I was going to look at
<jdstrand> it's python2 only, iirc (ie, there is some way to make python3 work)
<diddledan> oh? if there's a way to get python3 working that might unblock mycroft
<jdstrand> there's the forum topic. let me find it
<jdstrand> this is the topic: https://forum.snapcraft.io/t/python-multiprocessing-sem-open-blocked-in-strict-mode/962
<diddledan> yeah, there's a reply that says the workaround didn't work
 * jdstrand notes this is an issue with other app stores
<jdstrand> https://bugs.python.org/issue19478
<jdstrand> diddledan: see that ^
 * diddledan clicky
<jdstrand> "Although it is undocumented, in python 3.4 you can control the prefix used by doing
<jdstrand>     multiprocessing.current_process()._config['semprefix'] = 'myprefix'"
<jdstrand> I'll take a note to add that to snappy-debug
<diddledan> ok, I've set a mycroft build going to see if that can fix me up
<jdstrand> kyrofa: actually, I looked into this and bamf received an update via a different bug
<jdstrand> kyrofa: I can now make the test an info
<jdstrand> roadmr: hey, can you make that r1167 instead?
<roadmr> jdstrand: sure thing!
<jdstrand> thanks :)
#snappy 2018-12-04
<mborzecki> morning
<zyga> good morning :)
<zyga> mborzecki: I pushed missing patches from master into https://github.com/snapcore/snapd/pull/6235
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> the reference is https://github.com/snapcore/snapd/pull/6233
<mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
<mborzecki> oh, and it's green now
<zyga> there are a few extra lines of diff
<zyga> because that branch combines another small patch from master
<zyga> namely https://github.com/snapcore/snapd/pull/6235/commits/cbc6e3e029e36e2d120a3dbb2edad39f689da479
<mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> I think it's good to go :)
<zyga> mborzecki: I think we can merge https://github.com/snapcore/snapd/pull/6248
<mup> PR #6248: tests/lib/reset: restore context of removed snapd directories <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6248>
<mup> PR snapd#6248 closed: tests/lib/reset: restore context of removed snapd directories <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6248>
<zyga> a pair of simple looking conflicts on https://github.com/snapcore/snapd/pull/6238
<mup> PR #6238: [RFC] many: add minimal SELinux support, refactor the policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
<zyga> mborzecki: did you pick that keyboard? :)
<mborzecki> zyga: no, not yet
<zyga> mborzecki: pawel has apparently moved his work onto the new machine
<zyga> expectedly, because it's the quietest and fastest machine he has now
<zyga> I'm curious if you will experiment with vmware as well :)
<mup> PR snapd#6256 closed: snap: add new `snap run --trace-exec` call (2.36) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6256>
<zyga> mborzecki: I resolved conflicts on https://github.com/snapcore/snapd/pull/6193/files
<mup> PR #6193: spread: drop Fedora 27, add Fedora 29 <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6193>
<zyga> though I made F29 manual so this can land
<zyga> it should pass with just F28
<zyga> Quick school run
<zyga> Re
<mup> PR snapd#6258 opened: WIP: interfaces: support D-Bus activation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6258>
<zyga> and back now
<zyga> jamesh: hey :)
<jamesh> hi zyga
<zyga> I will try to review all branches this week
<zyga> but we have a backlog and limited capacity
<jamesh> zyga: no problem.  I'm still working on the dbus activation one: the PR is more for CI feedback
<jamesh> (that's why I marked it WIP)
 * zyga loves to see :: targets used in makefiles
<pstolowski> mornings
<mborzecki> pstolowski: hey
<zyga> hey pawel :)
<zyga> https://github.com/snapcore/snapd/pull/6257 is green
<mup> PR #6257: testutils: split checkers, tweak tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6257>
<zyga> and very long :-)
<zyga> nvidia physix is BSD now
<zyga> that's impressive
<zyga> wonder if nvidia will have a change of strategy for their other software
<zyga> mborzecki: hey
<zyga> mborzecki: I think we should do something about that snapd.mk PR
<mborzecki> did that land?
<zyga> I would like to resurrect it, make minimal modifications as discussed (move variable generation back to .spec file and have snapd.mk include vars.mk)
<zyga> and land it
<zyga> looking at the PR from james, there will be new files, new things to look at
<zyga> uh oh
<zyga> The job exceeded the maximum log length, and has been terminated.
<zyga> travis now kills jobs that log too much
<zyga> perhaps we should tweak spread to log less stuff
<zyga> and definitely make rpm builds quieter
<mborzecki> zyga: yeah, 2.36 branch is failing atm because of this i think
<zyga> one other thing I would silence is the package name selection
<zyga> that is, mapping from ubuntu names to other names
<mborzecki> zyga: or sort of, something else fails, but travis terminates the job :)
<zyga> that's extremely verbose
<mborzecki> set +too-much-gibberish-x
<zyga> trying some simple changes to reduce the log size now
<zyga> mborzecki: do you know if it is possible to query the state of "set" settings?
<mborzecki> zyga: snap get ?
<mborzecki> snap get -d
<zyga> no no
<zyga> I mean in shell
<zyga> set -x vs set +x
<mborzecki> aah
<zyga> there's nothing I can find quickly
<mborzecki> zyga: set -o should do the trick
<zyga> ah, neat, thanks!
<mborzecki> zyga: xtrace is apparently the option
<zyga> yes
<mborzecki> and even supported by zsh :)
<zyga> quick patch for reduced verbosity https://www.irccloud.com/pastebin/o15U1EqK/
<mup> PR snapd#6259 opened: tests: reduce verbosity around package installation <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6259>
<zyga> mborzecki, pstolowski: ^
<pstolowski> ok
<zyga> mborzecki: do you want to discuss the connections API?
<zyga> just looking at some random part of trace log
<zyga> I would love to have
<zyga> snap debug is-connected
<zyga> snap debug connected-slots SNAP:PLUG
<zyga> snap debug connected-plugs SNAP:SLOT
<zyga> snap debug connecte-snaps SNAP:<PLUG-OR-SLOT>
<zyga> (typos aside, you get the idea)
<mborzecki> mhm
<zyga> ideally all fuelled by a new API call
<zyga> perhaps those could also be visible via snapctl
<zyga> pstolowski: ^ do we have something like that for snapctl today?
<pstolowski> zyga: no, unfortunately not
<zyga> we might expose it in both places eventually
<zyga> feels like something useful to snap developers
<zyga> mborzecki: the general idea feels like
<zyga> mborzecki: connections <snap:plug> <snap:slot> <interface> <string> <flags>
<zyga> interface optionally limits to interface type
<zyga> string optionally filters by name of plug/slot
<zyga> snap:plug and snap:slot can be empty or partially empty
<zyga> (perhaps string is useless actually)
<zyga> flags can alter the set of returned data (e.g. attributes) or visible things (e.g. show disconnected things as well as connected, for hotplug)
<zyga> it seems it could power all the commands mentioned above
<zyga> all of the options would probably be packed into a query structure
<zyga> we might also have a flag for controling core/gadget connections
<zyga> (e.g. skip them or include them)
<zyga> so that the client code can stop having to special case "system/snapd/core/ubuntu-core"
<mborzecki> zyga: let's have a chat ~11, 1115?
<zyga> sure
<mborzecki> #6193 is green
<mup> PR #6193: spread: drop Fedora 27, add Fedora 29 <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6193>
<zyga> merge it
<zyga> we will solve the 29 blocked aspect separately
<pstolowski> zyga: looking at 6257
<mborzecki> zyga: about fontconfig again, desktop interface mount of /var/cache/fontconfig is probably a problem
<zyga> mmm
<zyga> but that only applies to strictly confined apps
<zyga> isn't the problem you experienced only affecting classic confined apps?
<mborzecki> zyga: i'm still bit worried that we're generating that cache in a location that does not match distro choice, with the way things are set up now it should work, we're going to make /var/cache/fontconfig ourselves after all
<zyga> mborzecki: yes
<zyga> maybe we should really build a cache in /var/cache/snapd/fontconfig
<mborzecki> zyga: righ, but the the classic snaps that use libfontconfig from core will end up poking /var/cache/fontconfig ;)
<zyga> yes
<mborzecki> tradeoffs everywhere
<zyga> but for those we have no way out
<zyga> until we can attack  mount namespaces for classic confined software
<mborzecki> mhm
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6251
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<pstolowski> #6180 is green and needs (re)reviews
<mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
<mborzecki> zyga: pstolowski: can you take a look https://github.com/snapcore/snapd/pull/6193 and +1 ?
<mup> PR #6193: spread: drop Fedora 27, add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6193>
<pstolowski> k
<zyga> mborzecki: aha
<mborzecki> pstolowski: and this one needs a 2nd review too: https://github.com/snapcore/snapd/pull/6246 super simple :)
<mup> PR #6246: spread: show AVC audits when debugging, start auditd on Fedora <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6246>
<mup> PR snapd#6193 closed: spread: drop Fedora 27, add Fedora 29 <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6193>
<zyga> mborzecki: replied on https://github.com/snapcore/snapd/pull/6251
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<mup> PR snapd#6246 closed: spread: show AVC audits when debugging, start auditd on Fedora <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6246>
<mborzecki> anyone knowledgeable of assertions left around? https://forum.snapcraft.io/t/cant-install-or-refresh-snaps-on-arch-linux/8690 the device is seeded, however there is no model assertion even though data.auth.model is already set to generic-classic
<zyga> hmmm
<zyga> I guess we just have to man up and read that code
<zyga> pstolowski: on https://github.com/snapcore/snapd/pull/6257, shall I update all headers to 2018?
<mup> PR #6257: testutils: split checkers, tweak tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6257>
<pstolowski> zyga: i'd use this opportunity
<zyga> sure
<zyga> pstolowski: done :)
<pstolowski> ty !
<mborzecki> suprising how travis jobs are succeeding now
<zyga> pstolowski: this is not super urgent but it needs a 2nd review https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<zyga> a much simpler variant of this went into 2.36
<zyga> this one is just tidier and less noisy
<mup> PR snapd#6090 closed: Granted 'account_control' access to /home/** <Created by stefannilsson> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6090>
<zyga> pstolowski, mborzecki: what do you guys think about https://github.com/snapcore/snapd/pull/6250
<mup> PR #6250: data: set KillMode=process for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6250>
<mup> PR snapd#6200 closed: tests: fix for tests test-*-cgroup <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6200>
<zyga> perhaps cherry pick the detector I suggested and LGTM?
<zyga> I'm sure mvo can iterate on top
<zyga> but feels like the right thing to do
<pstolowski> zyga: do apparmor_parser and snap-seccomp lock profiles? any risk of having profiles messed up if new instances start writing profiles while old ones are still running?
<pstolowski> (but in general yes, i think that's the right step what this PR proposes)
<zyga> they don't lock profiles because they don't have to AFAIK:
<zyga> snap-seccomp writes a new file with atomic move
<zyga> snapd writes source profiles with atomic move
<pstolowski> ah, good then
<zyga> apparmor_parser loads profiles into the kernel, kernel is the point of mutual exclusion
<zyga> snap-confine loads profiles from disk only at startup
<zyga> that holds the lock but that's not really a factor
<zyga> seccomp profiles persist until process death
<zyga> apparmor profiles are changed dynamically
<mborzecki> uhh reached asserts db trying to find out what's going on
<zyga> and?
<mborzecki> got lost :)
<mborzecki> back to devicemgr
<mborzecki> i bet that device serial is set on that guy's machine, but it's unclear why that'd be the case and the model assertion would not be present
<zyga> feels like we could use some commands to show stuff
<zyga> more than "snap known"
<zyga> which feels like a debug command, not an end-user thing
<mborzecki> super unpleasant user command if anything :)
<zyga> https://www.irccloud.com/pastebin/xNFfHNva/
<zyga> hmmm
<zyga> something really broken there :)
<zyga> looking
<mborzecki> nice
<zyga> note that it uses dpkg on centos
<mborzecki> heh right
<mborzecki> snapd-xdg-open? i don't recall this in rpm
<zyga> tests/upgrade/snapd-xdg-open/task.yaml
<zyga> it runs on centos
<zyga> but is clearly specific to ubuntu
<mborzecki> is that a new task?
<zyga> nope
<zyga> look at it
<zyga> wonder why the error never surfaced?
<mborzecki> haha so how did it not fail before?
<zyga> exactly
<zyga> set -e is easy to lose
<zyga> well
<zyga> it failed now
<zyga> I really wonder what I changed
<zyga> I don't quite understand some of the logic in the pkgdb.sh
<zyga> mborzecki: removed cloexec handling in https://github.com/snapcore/snapd/pull/6251
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<mborzecki> zyga: what was it?
<zyga> mborzecki: will to fix that centos issue or shall I?
<zyga> mborzecki: with cloexec?
<zyga> mborzecki: just my debug wrappers
<mborzecki> mhm
<mborzecki> aah
<mborzecki> shell scripts?
<zyga> I didn't realise this is needed for scripts but not for programs
<zyga> yep
<mborzecki> yup, they mention that in the manpage
<zyga> I test this way locally
<zyga> yeah, in the BUGS section below :)
<zyga> I missed that
<mup> PR snapd#6235 closed: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors (2.36) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6235>
<zyga> mborzecki, pstolowski: my main feature branch that can land https://github.com/snapcore/snapd/pull/6149
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> I will have follow ups and tests once the feature snapd side is ready
<pstolowski> zyga: k, will take a look
<zyga> thank you!
<zyga> mborzecki: I have a debug shell on centos 7 with that dpkg-query script
<zyga> no idea why it would ever pass before
<mborzecki> heh
<zyga> disabled it, pushed
<zyga> magic
<mborzecki> btw. i'm playing with spread on fedora 29
<mborzecki> DEBUG: running snap-device-helper add snap_test-snapd-udev-input-subsystem_slot /sys/class/mem/null 1:3
<mborzecki> execl failed: No such file or directory
<zyga> do you know my main issues with spread on fedora 29
<zyga> right
<mborzecki> snap-device-helper is a script, wtf?
<zyga> I know about htis
<zyga> *this
<zyga> yes
<zyga> but that's not the main problem
<zyga> the problem is that we must never repackage core or snapd snaps
<zyga> with stuff we've built on a random distro
<zyga> that's a bad test
<zyga> bad logic
<zyga> and not representative of what ever happens in production
<zyga> locally built snapd package gets injected into core snap
<mborzecki> yes, wanted to reach that point and inspect what happens exactly
<zyga> so libc from 2019 will be in a 2016 system
<zyga> I mean, progs linked to 2019 will be in a 2016 system
<zyga> what is wrong is that rpm helpers change the #!/ line
<zyga> look at the shebang line in the source and in that system that is broken
<zyga> the short term resolution:
<zyga> stop repackaging core / snapd anywhere outside of 16.04
<zyga> we can perhaps repackage snap-exec
<zyga> but nothing more
<mborzecki> woot, rpm learned some new tricks
<zyga> mborzecki: mkosi got a huge static typing boost
<zyga> https://github.com/systemd/mkosi/pull/300
<mup> PR systemd/mkosi#300: Modify so that `flake8` and `mypy` are happy <enhancement> <Created by LukeShu> <https://github.com/systemd/mkosi/pull/300>
<mborzecki> hm still got mixed feelings about python and type hints
<zyga> really? that's like 99% of the error checking there :)
<mup> PR snapd#6260 opened: spread, tests: use audit checkpoints when dumping audit log <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6260>
<mborzecki> simple one ^^
<mborzecki> zyga: it's just the type enforce part is missing
<zyga> mborzecki: no need
<zyga> mypy checks that it is true :)
<zyga> if mypy says it's ok, the types match
<zyga> reality is somewhat different as sometimes there are bugs in mypy and sometimes there are cases that are valid but the type system cannot express it
<zyga> but really, apart from changing python in py4
<zyga> this is the best way to write python now
<zyga> eh
<zyga> untangling the mess in config manager
<zyga> sucks
<zyga> cyclic import mess, that is
<mborzecki> hah :)
<zyga> I will never finish user mounts this way
<zyga> I think I got it
<zyga> I will propose a small branch with just the tweak to config
<mup> PR snapd#6261 opened: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6261>
<mborzecki> another simple PR ^^
<mborzecki> this time not dropping xattrs
<zyga> eh
<zyga> more cyclic shit
<zyga> I hate this part of golang
<zyga> LGTM with capitalisation of sentences
<zyga> mborzecki: hmm
<zyga> does set -o
<zyga> does that set something in practice
<zyga> because i have a feeling that that patch actually uncovered real bugs
<cachio> zyga, hey
<cachio> error: Failed build dependencies:
<cachio> 	compiler(go-compiler) is needed by snapd-1337.2.36.2-0.el7.x86_64
<cachio> I get this error on centos 7.6
<mborzecki>        âo    Write the current settings of the options to standard  output  in
<mborzecki>              an unspecified format.
<zyga> cachio: ehey
<mborzecki> cachio: hmm interesting
<cachio> zyga, I made sure go is instlaled
<zyga> mborzecki:  https://www.irccloud.com/pastebin/3I0NnCO5/
<cachio> mborzecki, yes
<zyga> cachio: I don't follow EPEL work so no idea
<cachio> mborzecki, do you?
<cachio> right
<cachio> ?
<mborzecki> cachio: any chance i could use the image?
<cachio> I have a debug session already openned
<cachio> mborzecki, do you want to use it?
<zyga> mborzecki: my guess is that sourcing some of our packages nukes set -e
<zyga> and this is now changed _somehow_
<cachio> mborzecki, otherwise the image name is test-centos-1
<zyga> sourcing vs executing
<zyga> sourcing is evil
<mborzecki> cachio: yes, i'll try to build snapd there, i recall chasing down something similar
<mborzecki> zyga: hence, 'evil sourcerer' :)
<zyga> haha
<zyga> we should really stop doing that
<zyga> or add sanity checks on 1st/last line of each file
<zyga> this really sucks
<zyga> I wonder what else is hidden by this
<mborzecki> shell sucks
<cachio> mborzecki, great, thanks
<cachio> zyga, are you working with this error on snap-run right?
<zyga> which error?
<cachio> zyga, I have seen many times the error :
<cachio> snap run --trace-exec test-snapd-tools.echo hello
<zyga> I haven't touched that code
<zyga> nor seen the error
<zyga> that's mvo's new thing, if it fails perhaps we should revert for now
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6190 should now pass and has the configuration untangled
<cachio> zyga, ok, I'll collect the logs since yesterday to check it is failing on the same place
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> how is it failing?
<cachio> zyga, well, it is failing on arm devices
<zyga> _how_
<cachio> zyga, https://paste.ubuntu.com/p/4RGQB3VmCv/
<zyga> error: unknown flag `trace-exec'
<mborzecki> that's the new thing
<zyga> looks like combination of old binaries and new tests
<zyga> so?
<ackk> hi, I opened https://bugs.launchpad.net/snapcraft/+bug/1802345 a while ago. now, with snapcraft building by default in VMs, is there a way to export that env var?
<mup> Bug #1802345: can't build python part with C modules <Snapcraft:New> <https://launchpad.net/bugs/1802345>
<zyga> ackk: that's a question for sergiusens
<cachio> zyga, ahh, ok, in that case the core on edge did't get the last updates
<cachio> zyga, sorry, I'll check what happended there
<zyga> mborzecki: I added some sanity detectors to sourcing pkgdb
<xnox> hi! can anybody please verify https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 ?
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936>
<xnox> otherwise, i guess i will need to drop the writable-etc patch to get systemd to be released =/
<zyga> xnox: what's the timeline?
<xnox> zyga, well, mvo has been chasing me about this for a long time, and as far as i understand it affects/blocks usablity of core18 by default.....
<zyga> yes, I mean, how soon do you need this verified
<zyga> mvo is away this week
<xnox> zyga, i have a new SRU ready to upload with severe regression fixes.
<xnox> zyga, thus i do need to release this update soon.
<ackk> sergiusens, hi, do you have any insight on #1802345
<mup> Bug #1802345: can't build python part with C modules <Snapcraft:New> <https://launchpad.net/bugs/1802345>
<xnox> zyga, i'm away from thursday.... today/tomorrow would be really nice
<zyga> xnox: I see, I will get back to you shortly
<xnox> zyga, mostly i have no idea how to build and boot core18 with systemd from bionic-proposed.
<xnox> otherwise i can validate this issue myself....
<xnox> zyga, are there core18 images built with bionic-propsoed somewhere?
<zyga> sadly, I don't know this
<zyga> I'm trying to find out
<zyga> the pipeline around this is a bit of a black magic
<sergiusens> ackk: might just be a python plugin bug; the xenial issue feels tricky as snapcraft wouldn't be able to build as we use yaml, macaroons and other things so I will have to look into it
<ackk> sergiusens, wdym "snapcraft wouldn't be able to build" ? you mean build itself?
<sergiusens> yes, build itself
<xnox> zyga, also the systemd update, triggered snapd autopkgtests with regressions on all arches.
<diddledan> sergiusens, ackk, try adding libc6-dev if you want the headers for libc
<ackk> sergiusens, why is that relevant? the bug is about building a python snap
<ackk> diddledan, the problem is not that headers are not there, it's that they are not found without that export
<xnox> zyga, is 2018-11-20 16:29:44 Failed tasks: 1
<xnox>     - autopkgtest:ubuntu-18.04-i386:tests/main/dirs-not-shared-with-host:alternatives
<xnox> known?
<sergiusens> ackk: snapcraft is a python snap, what do you mean it is not relevant?
<xnox> in that case i can ask release team to add a hint to ignore that.
<ackk> sergiusens, does it specify that env var in override-build?
<diddledan> oh, ackk, you're building with python2 but supplying the python3-dev package
<diddledan> add `python-version: python3` to your part yaml
<ackk> diddledan, oh lemme try that
<zyga> xnox: hmmm, probably tests out of sync with code
<zyga> xnox: we no longer have /etc/alternatives management in snapd
<zyga> and core was changed to not use such symlinks
<zyga> xnox: it's a bit unfortunate because I don't participate in that part of snapd (release) and this is really something mvo should answer
<zyga> but he's unlikely to this week
<sergiusens> ackk: envvars do not make it to plugin logic, if you are doing something complex, script the whole thing or write a custom plugin
<ackk> diddledan, same error
<diddledan> sergiusens: we should make available a bare-bones template/example for people to base their custom plugins on
<diddledan> i.e. a template that does nothing without adding code but shows all the standard functions
<diddledan> stubs all the standard functions**
<sergiusens> diddledan: we had that in the old docs, I cannot for the life in me find anything in the new ones...
<ackk> diddledan, fwiw it'd be nice if you could specify the actual python version, like python3.7  as both 3.6 and 3.7 are available on bionic
<mborzecki> off to pick up the kids
<ackk> sergiusens, why am I doing something complex? it's just building a pyhton app, with C modules
<ackk> sergiusens, seems something that the python plugin should support, which it could by just exporting C_INCLUDE_PATH to /usr/include/<python-version>
<sergiusens> well, I said I would look at the bug later, all you will get from me now are shallow replies
<diddledan> https://media2.giphy.com/media/JMoyE48gJqivS/giphy.gif?cid=3640f6095c06792f566577304103b645
<cachio> mborzecki, hey, could you please take a look to #6217
<cachio> it is close
<cachio> thanks
<mup> PR #6217: tests: reset snapd state on tests restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6217>
 * pstolowski lunch
 * zyga -> cofee
<zyga> *coffee
<diddledan> ackk: move `python3-dev` from `build-packages` to `stage-packages`.
<ackk> diddledan, ah, that worked! out of curiosity, why is that needed?
<zyga> cachio: hey, can you please work with xnox to run regression tests on https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936>
<zyga> cachio: it needs a core18 snap with systemd from proposed
<zyga> (back from coffee and extra dog walk that he demanded)
<zyga> mborzecki: I added set -o traces in various points
<zyga> running a test now, let's see
<cachio> zyga, sure
<zyga> thank you
<zyga> xnox: ^ cachio will help with testing that
<ackk> diddledan, thanks for the tip btw
<zyga> mborzecki: set -e is set when the test executes, as expected
<zyga> mborzecki: comparing that to what happens in master
<zyga> this is really puzzling
<mborzecki> 2018-12-04 14:54:52 Failed tasks: 3 <-- that's with fedora 29
<zyga> mborzecki: which tasks failed?
<mborzecki> zyga: tests/main/document-portal-activation tests/main/prepare-image-uboot and tests/main/snap-run
<zyga> interesting
<zyga> what did you change?
<mborzecki> added a workaround for snap-device-helper
<zyga> mborzecki: heh
<zyga> man
<zyga> it passes on master
<zyga> so yes
<zyga> something is broken in our spread test suite
<zyga> running with --shell-after now
<mborzecki> hahah
<zyga> I will shortly know what's the cause
<mborzecki> we should write go scripts
<zyga> with the tracing added, all I need is to diff the right spot
<zyga> :/
<mborzecki> #!/usr/bin/go run
<zyga> we should not source stuff
<zyga> write tools
<zyga> not shell functions
<zyga> and migrate away from that
<zyga> then tools can become non-shell
<mborzecki> damn, standup
<zyga> joining
<zyga> pstolowski: standup
<zyga> mborzecki: can you ack/merge https://github.com/snapcore/snapd/pull/6257
<mup> PR #6257: testutils: split checkers, tweak tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6257>
<mup> PR snapd#6257 closed: testutils: split checkers, tweak tests <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6257>
<pedronis> zyga: mborzecki: hi, I don't the situation of the arch user that lost the model assertion, afaict the code sets the state only after having added the assertion
<pedronis> * I don'tunderstand
<ppisati> ogra: where can i find the ubuntu core arm64 image for the raspberrypi3?
<pedronis> mborzecki: if you can spend some thinking what could delete it,  I don't have brain cycle for it atm
<zyga> pedronis: note that i have a core device in similar state, I have the state of that if someone wants to attack that at some point
<ogra> ppisati, somewhere in mvo's people account
<ogra> IIRC
<ogra> ppisati, https://forum.snapcraft.io/t/pi3-64-unofficial-image/8317
<pedronis> zyga: that sound bad, I don't know any code that would remove a model assertion that was set
<pedronis> sounds a serious bug
<ppisati> ogra: ack, thank you
<ogra> ppisati, did you get anywhere with A+ and vc4 ?
<ppisati> ogra: oh yeah, it already spawned 2/3 lp bugs
<ppisati> ogra: cma=256M is the problem
<ogra> well, thats builtin
<ppisati> ogra: this is the oops - https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1805117
<mup> Bug #1805117: Xenial/raspi2 and RaspberryPi3a+: OOPS during boot <patch> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1805117>
<ogra> the driver has it hardcoded somewhere ... IIRC
<ppisati> ogra: and this is the cma / deadlock: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1805174
<mup> Bug #1805174: Xenial/raspi2 and RaspberryPi3A+: video not working <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1805174>
<ppisati> ogra: yeah. but you can specify cma=a on the dtparam
<ppisati> ogra: wait, let me find
<ogra> btw, the closed driver works really fine
<ogra> yeah, i know
<ppisati> ogra: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/arch/arm/boot/dts/overlays/README?h=raspi2
<ppisati> ogra: search for "vc4-kms-v3d"
<ppisati> ogra: Params: cma-256                 CMA is 256MB, 256MB-aligned (needs 1GB)
<ppisati> ogra: while the rpi3a+ has 512MB
<ppisati> ogra: pass cma-128 and it will work
<ogra> yeah, i got that ... my prob is that i have no conditional i could use in config.txt to actually set it dynamically
<ogra> and i dont want an A+ sepcific image
<pedronis> mborzecki: zyga: notice that those systems could be in that state since long, is just that 2.36 is surfacing now the bad state
<zyga> pedronis: in my case I updated a device after fresh install
<ogra> the alternative would be to simply default to cma-128, but that degrades the actual pi3 i guess
<zyga> this was circa ~ 3  weeks ago
<zyga> the device is off since then
<mborzecki> pedronis: right, that's my hunch as well, added a note in the forum
<pedronis> zyga: as I said the update would be make the bad state appear
<pedronis> I don't think it removed the model
<ppisati> ogra: the problem is that the fw set cma=256 even on that board, and the drivers locks up with that much memory
<pedronis> zyga: I might be missing something
<pedronis> tough
<ppisati> ogra: i can fix the oops, but then ther's another problem after that
<ogra> yeah
<ogra> right
<zyga> pedronis: I will look at that device tomorrow
<zyga> working with maciek on mount error now
<ogra> i understand ... that why i would like to simply do it via a conditional in config.txt and have it pick the right value ... https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md
<ogra> *that's
<ogra> but i can neither filter on pi3 vs A+ nor on available RAM
<ogra> (would be all easier if we could apply the overlays from u-boot ... then i could just check what board i'm on easily)
<mup> PR snapd#6262 opened: apparmor: allow snap-update-ns access to common devices <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6262>
<sergiusens> having a .snapcraft as an alternate to snap is going to be a bigger code change than I wanted
<zyga> sudo umount /tmp/dupa-* &&  sh -c 'for i in $(seq 1000); do mkdir -p /tmp/dupa-$i && umount /tmp/dupa-$i 2>/dev/null; cp foo.snap foo-$i.snap && LIBMOUNT_DEBUG=all mount foo-$i.snap /tmp/dupa-$i >mount.$i.log 2>&1 & done'
<zyga> er
<zyga> sudo sh -c 'umount /tmp/dupa-* 2>/dev/null; for i in $(seq 1000); do mkdir -p /tmp/dupa-$i && cp foo.snap foo-$i.snap && LIBMOUNT_DEBUG=all mount foo-$i.snap /tmp/dupa-$i >mount.$i.log 2>&1 & done'
<zyga> with waiting: sudo sh -c 'umount /tmp/dupa-* 2>/dev/null; for i in $(seq 1000); do mkdir -p /tmp/dupa-$i && cp foo.snap foo-$i.snap && LIBMOUNT_DEBUG=all mount foo-$i.snap /tmp/dupa-$i >mount.$i.log 2>&1 & done; wait'
<zyga> mborzecki: ^ those take a lot of CPU from systemd and various mount-observing tools
<zyga> ha
<zyga> when running many mount in parallel
<zyga> I got:
<zyga> systemd[PID]: Failed to get udev event
<zyga> sudo sh -c 'umount /tmp/dupa-* 2>/dev/null; for i in $(seq 1000); do mkdir -p /tmp/dupa-$i && cp foo.snap foo-$i.snap; done; for i in $(seq 1000); do LIBMOUNT_DEBUG=all mount foo-$i.snap /tmp/dupa-$i >mount.$i.log 2>&1 & done; wait'; grep 'final srcpath'  mount.*.log | cut -f 6 -d ':' | sort | uniq -c | cut -c 7-  | cut -d ' ' -f 1 | sort | uniq -c
<zyga> mborzecki: can you copy any snap you have on hand to foo.snap
<zyga> mborzecki: and run that
 * zyga -> dinner
<cjwatson> sergiusens: please tell me this isn't another place where snapcraft.yaml can live?  we already have three :(
 * cachio lunch
<zyga> re
<zyga> jdstrand_: thank you for the review
<zyga> I will jump to that shortly
<sergiusens> cjwatson: the snapd team does not want to rename their in code "snap" directory
<sergiusens> so it came as a requirement to change it
<cjwatson> Well, just remember that adding more locations for snapcraft.yaml requires changing at least LP and BSI too
<zyga> BSI?
<cjwatson> And may cause operational problems since it will increase the number of queries BSI is making to GitHub (although hopefully not by very much)
<cjwatson> build.snapcraft.io
<zyga> ah
<sergiusens> cjwatson: yeah, it sucks
<sergiusens> just to avoid a big sed in the code, we get to add logic all over the place
<cjwatson> sergiusens: can you file bugs on LP and BSI once the snapcraft change lands, if it's unavoidable?
<sergiusens> sure thing
<cjwatson> thanks
<mup> PR snapcraft#2399 closed: cmake plugin: use build snaps to search paths <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2399>
<zyga> mborzecki: still there?
<zyga> no luck on 16.04 either
<zyga> mborzecki: but interestingly I can easily trigger this:
<zyga> https://www.irccloud.com/pastebin/UFMlCwov/
<zyga> so that part is working as intended
<zyga> gru 04 08:44:10 ubuntu snapd[897]: 2018/12/04 08:44:10 Unsolicited response received on idle HTTP channel starting with "HTTP/1.0 408 Request Time-out\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n<html><body><h1>408 Request Time-out</h1>\nYour browser didn't send a complete request in time.\n</body></html>\n"; err=<nil>
<zyga> hmm?
<katamo> aloha, I need to change ownership of a snap, specifically https://snapcraft.io/scout-plane/listing, from myself to a colleague. Can I get help with that here?
<mborzecki> zyga: nice
<zyga> katamo: yep, but probably requires a forum topic too,
<popey> katamo: best to ask in the store category on the forum
<zyga> mborzecki: yep
<zyga> mborzecki: so, ...
<katamo> popey ack, ty
<zyga> mborzecki: I'm running this in parallel with systemd restarts now
<zyga> no luck
<mborzecki> restarts?
<zyga> daemon-reload
<mborzecki> ah ok
<mborzecki> zyga: have you tried the reproducer script yet?
<mborzecki> zyga: https://gist.github.com/bboozzoo/d4b142229b1915ef7cc0cf8593599ad9
<zyga> yeah but I want to find a deeper angle on this :), the erorr was, clearly, from libmount, not from systemd itself
<zyga> system caught and reported it
<zyga> that's fine
<mborzecki> zyga: maybe a problem is with loading mountinfo in systemd?
<zyga> hmmm
<zyga> interesting idea
<mborzecki> zyga: iirc that's done separately in io loop
<zyga> worth looking
<mborzecki> zyga: and there's that super ineresting comment:
<mborzecki>         /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded
<mborzecki>          * before we process the SIGCHLD for the mount command. */
<zyga>  yeah, I read that
<zyga> it looks correct though
<zyga> one more thing to do
<zyga> is to breakpoint there
<zyga> when it cannot find it
<zyga> and rewind enough state to look around
<mup> PR snapcraft#2419 opened: project: state file path change <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2419>
<mup> PR snapd#6263 opened: Retrieving all pages for 'find' command, not only one <Created by WiseRaccoon> <https://github.com/snapcore/snapd/pull/6263>
<zyga> jdstrand: hey, updated https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<zyga> I'd like to land it as-is, I'm still doing one aspect
<zyga> when we have a object (kernel or parser) and some features
<zyga> there are features we want to have to be fully operational
<zyga> features we want to have to be partially operational
<zyga> and features we must have to be in any way operational
<zyga> you are right this is not captured
<zyga> I'd like to do that properly with a follow-up
<zyga> I added a few missing tests, got coverage to 100%
 * jdstrand responded in the pr
<zyga> jdstrand: thanks, lookin g
<zyga> jdstrand: replied there
<zyga> jdstrand: totally offtopic
<zyga> do you know what's the status of the upstreaming effort
<zyga> I'm running tumblweed instead of ubuntu recently and I keep taking notice that we're not fully supported yet
<jdstrand> zyga: af_unix is still missing. it is the last thing. I know jjohansen was working to get things into the latest merge window and af_unix was on the table, but not sure if he got it in
<zyga> cool, fingers crossed :)
<zyga> using TW is like being on debian sid
<zyga> but without any debian specific things I may assume are true universally
<jdstrand> zyga: note that once af_unix is in, will need apparmor 3 userspace for (at least) the networking bits
<zyga> it's been a fun journey
<zyga> is apparmor userspace 3 released?
<jdstrand> not yet
<jdstrand> it is also planned, but behind the af_unix mediation and a few other things. it, those things and af_unix are all for this cycle
<jdstrand> and by cycle, I mean our dev cycle, not the upstream kernel or anything else
<zyga> do you know if the eventual release will affect ubuntu that has carried the earlier patches in any way?
<zyga> aha
<jdstrand> zyga: I don't hve the details on that, but we'll definitely make sure we have things working everywhere in Ubuntu
<zyga> jdstrand: I'm about to EOD but I'd love a one last look at https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<zyga> ah, I see you replied
<zyga> again, stale page :/
<zyga> jdstrand: I'll tweak this tomorrow, thank you :)
<jdstrand> zyga: np. happy to review again tomorrow. take it easy :)
<roadmr> jdstrand: the tools r1167 are now merged in the store's trunk and should be deployed some time this week, ideally tomorrowish
<jdstrand> roadmr: thanks! :)
#snappy 2018-12-05
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> zyga: do you know who controls strace-static snap?
<mborzecki> is it only mvo?
<zyga> I believe so
<zyga> What do you need?
<mborzecki> well, it doesn't work on fedora, something about unexpected wait status value, i believe it's the recent kernel that's causing this
<mborzecki> the edge version is 4.23 and stil not good enough
<mborzecki> fedora ships strace 4.24 and that one works
<mborzecki> i've worked around it in the spread suite, but we'll need to update the snap at some point
<zyga> Mmm
<zyga> Is 4.24 compatible with other distributions?
<mborzecki> zyga: we'll see when we end up using it in the spread suite
<mborzecki> zyga: fwiw i have 4.25 in arch
<mborzecki> one last spread run and i'll be opening a PR with Fedora 29
<zyga> Ok
<zyga> I will be around in 30 minutes
<zyga> As usual, worked late last night
<pstolowski> heyas
<mborzecki> pstolowski: hey
<zyga> back now
<zyga> good morning pawel
<zyga> how are you guys?
<zyga> sorry for being sleepy, I was pushing some things last night
<zyga> are we still affected by the issue where our logs are too long for travis?
<mup> PR snapd#6264 opened: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<zyga> mborzecki: what is your stance on the repackaging issue?
<zyga> I have not read the PR yet so if it is stated there please refer me instead
<mborzecki> zyga: imo it's benign as long as we don't reexec on those system, i think we could easily not repack the core snap on such systems
<zyga> why is it related to reexec?
<zyga> like it happened with snap-device-helper, some things are always used from core
<mborzecki> zyga: oh, w8, it's not, right reexec would still pull the libs from host so that's fine
<zyga> or am I mistaken, that the issue was that repackaged, incompatible script was used
<pstolowski> zyga: the spread test for dns error (#6222) is driving me crazy.. been trying a couple of tweaks yesterday evening. sounds crazy, but it looks like iptables-save+restore on debian doesn't actually restore the rules sometimes - some other test fails and when poking around in the system after failure i see the rule is active..
<mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<mborzecki> zyga: so it's probably only snapctl at this point
<mborzecki> which we could easily build statically
<zyga> mborzecki: would the issue also surface on future ubuntu 20.04 distribution testing a core16 snaps?
<zyga> pstolowski: can you dump the rules to compare them in text form?
<zyga> mborzecki: when snap-confine, reexecuting, is linked to libc not present in core16
<mborzecki> zyga: afaict only tools that are executed inside snap mount ns would be affected, those are snapctl and snap-device-helper, snap-update-ns (but that's already linked statically)
<zyga> indeed
<zyga> that's a good observation
<mborzecki> snapctl can be linked statically, it's go :)
<zyga> as other tools will still execute on the outside
<zyga> thanks
<mborzecki> zyga: that shebang being rewritten from #!/bin/sh to #!/usr/bin/sh is probably some usr-merge thing again
<zyga> yes
<pstolowski> zyga: iptables-save dumps them in txt form; let me actually inspect that when some other test fails
<zyga> pstolowski: yeah, just dump them in prepare and restore
<zyga> and compare what we get
<zyga> guys, I'm almost convinced there's something seriously broken
<zyga> so consider, when inspecting magic failures, that set -e is indeed not working
<zyga> so perhaps something failed earlier on and the script nonetheless advanced
<zyga> though I still don't grasp the details
<mborzecki> pstolowski: silly thought, maybe we should start our own dns server for that test
<pstolowski> mborzecki: hmm but we would need to modify the test environment anyway, so potentially effect something else?
<pstolowski> mborzecki: it seems like a primitive approach with just iptables -I .., followed by iptables -D ... works. or maybe i'm just lucky.
<mborzecki> hehe :) if it works then it's fine
<pstolowski> mborzecki, zyga: ha, reproduced. run all spread tests. a radom test failed (not the one that messes up with iptables). the rules dump file created by iptables-save is empty, but iptables has the dns reject rule
<zyga> intriguing, how do you save and observe the tables?
<zyga> and where do you store the dump?
<pstolowski> mborzecki, zyga grr, ignore me. the rules should be empty :D
<zyga> ah
<pstolowski> mborzecki, zyga apparently iptables-restore didn't work or wasn't invoked
<pstolowski> hmm, ok, not even that. rules dump is empty (as completely empty), but it should actually have some iptables-save noise
<pstolowski> weird...
<zyga> how do you dump the rules?
<mborzecki> pstolowski: were there any rules in place when iptables-save was called?
<pstolowski> mborzecki: no (and in such case iptables-save creates a kind empty file with empty chains)
<zyga> is the file overwritten somewhere?
<mborzecki> pstolowski: hm empty? shouldn't there be a timestamp and a list of all chanins (all empty)
<pstolowski> mborzecki: yes
<pstolowski> zyga: interesting theory
<pstolowski> trying without iptables save/restore now, if it works i'm gonna leave it like that
<mborzecki> #6264 is green :)
<mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<mborzecki> damn, hitting unrelated errors in the PRs
<mborzecki> appstream-id, refresh-all :/
<mborzecki> and mount thing obviously too
<zyga> yes
<zyga> bane of random failures
<zyga> eh :/
<zyga> I really encourage everyone to attack them
<zyga> they are crippling our ability to make progress
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6261 ?
<mup> PR #6261: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6261>
<mborzecki> it's finally green
<pstolowski> k
<mborzecki> zyga: about that xdg-desktop-portal: https://paste.ubuntu.com/p/nkFc5FJ3Qc/
<zyga> mmm
<mborzecki> but i don't see what requires that really
<zyga> we require it
<mborzecki> zyga: well, it's not listed anywhere in the spec
<zyga> hmm
<zyga> perhaps I was mistaken
<pstolowski> #6222 green as well; kicking it again to double check
<zyga> but I recall something like that
<mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<zyga> pstolowski: ack
<mborzecki> zyga: https://paste.ubuntu.com/p/Yf3bRmcjBr/
<zyga> pstolowski: is it safe to merge or do you anticipate tests breaking in the future?
<zyga> hm
<zyga> mborzecki: then I have no idea
 * zyga -> tea
<pstolowski> zyga: the test is dead simple and doesn't shouldn't have any side-effects, but you never know. i'll give it one more run to see. if it causes problem in the future i'll disable it
<zyga> ok
<mborzecki> zyga: heh i can actually remove xdg-desktop-portal and none of snapd components are removed
<mup> PR snapd#6261 closed: tests/lib/prepare: make sure that SELinux context of repacked core snap is controlled <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6261>
<mborzecki> pstolowski: if you could do this one too: https://github.com/snapcore/snapd/pull/6260
<mup> PR #6260: spread, tests: use checkpoints when dumping audit log <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6260>
<mborzecki> zyga: no clue what's happening with dependencies there, left a note in the PR for now
<zyga> sounds good
<pstolowski> random mount failure on 6222 -  Mount snap "test-snapd-tools_instance" (7) ([start snap-test\x2dsnapd\x2dtools_instance-7.mount] failed with exit status 1: Job for snap-test\x2dsnapd\x2dtools_instance-7.mount failed.
<mborzecki> heh
<zyga> on whihc system?
<zyga> *which system
<zyga> moved downstairs to the office
<zyga> sorry, I don't feel well today
<pstolowski> zyga:  google:ubuntu-18.04-64:tests/main/refresh-all
<zyga> 18.04
<zyga> mmm
<zyga> has anyone seen this on 18.10?
<mup> PR snapd#6265 opened: cmd/snap: attempt to restore SELinux context of snap user directories <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6265>
<mup> PR snapd#6260 closed: spread, tests: use checkpoints when dumping audit log <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6260>
<mborzecki> pstolowski: thanks!
<cachio> zyga, hey, I tested the systemd fix but still failing
<pstolowski> yw
<cachio> there is a test interfaces-hostname-control
<cachio> which found that error
<cachio> which still fail
<zyga> cachio: can you report on the SRU bug please
<zyga> cachio: and talk to xnox about the details
<cachio> sure
<zyga> thank you
<cachio> zyga, np
<cachio> I have a branch with the change I did to check that
<ackk> hi, is there a "hook" to do stuff like push files/configs to the multipass VM snapcraft uses?
<cachio> if you want to take a look just tell me
<zyga> cachio: that's fine, unless you want me to
<cachio> ok, I'll explain more during the standup
<pstolowski> #6222 is green again, merging
<mup> PR #6222: cmd/snap: handle DNS error gracefully <Created by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<mup> PR snapd#6222 closed: cmd/snap: handle DNS error gracefully <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6222>
<zyga> jdstrand: 6244 is read
<zyga> *ready
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6251 needs a 2nd review
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6149 needs a partially second review
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<mborzecki> k, looking
<zyga> thank you :)
<zyga> mborzecki: any action needed on F29 PR in light of the weak dependency fact?
<mborzecki> zyga: i'm running the fix under spread right now
<zyga> ok
<mborzecki> that umask thing keeps popping up
<zyga> hmmm
<zyga> tests leaking
<zyga> or something else?
<mborzecki> zyga: the test that passed on travis and locally before failed right now
 * cachio afk
<zyga> I'm back to debugging set -e bug
<zyga> waaat?!!?
<jamesh> zyga: would it be possible to get this change merged? https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/360118 -- this test package isn't currently used in snapd master, and I needed to update it a bit for the new version of the dbus activation changes
<zyga> looking
<zyga> if this is merged and published to the store, would snapd tests be affected straight away?
<zyga> I mean, would any tests that used to pass start to fail?
<jamesh> zyga: there is no reference test-snapd-dbus-service in the tests/ directory of snapd master
<zyga> ok
<jamesh> it originates from mvo's old abandoned PR
<zyga> jdstrand: is there a merge service running against that BZR branch?
<zyga> er
<zyga> jamesh: ^
<zyga> sorry, bad tab completion
<jamesh> zyga: I don't think so.
<zyga> ok, I'll merge it manually then
<jamesh> thank you.  I think I'm getting close to being able to remove that "WIP" tag from my PR
<jamesh> (and I understand it might take a while to get reviewed)
<zyga> hopefully more reviews will resume next week
<jamesh> I'm sure there's still problems to discover once my spread tests run on all distros
<zyga> hmm
 * zyga doesn't recall bzr specific weirdness
<zyga> jamesh: I _think_ it is merged
<zyga> yep
<zyga> mborzecki: can you re-review https://github.com/snapcore/snapd/pull/6259/files
<zyga> the set -e mystery is solved
<mup> PR #6259: tests: reduce verbosity around package installation <Simple ð> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6259>
<zyga> I was so stuck looking at why dpkg-query failure was ignored
<zyga> it was not
<zyga> it was never executed
<zyga> the exit above made sure of that
<zyga> so the test would fail but it was returning early
<mborzecki> zyga: something fishy about tests, i have no idea how that fedora 29 pr is green
<zyga> haha
<zyga> in which sense
<zyga> maybe it is manual?
<mborzecki> omg, damn, it is
<mup> PR snapd#6250 closed: data: set KillMode=process for snapd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6250>
<zyga> advice welcome on https://github.com/snapcore/snapd/pull/6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> is that good as is
<zyga> or should I iterate on some aspect
<zyga> should I split some parts out to land quicky
<mup> PR snapd#6259 closed: tests: reduce verbosity around package installation <Simple ð> <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6259>
<mup> PR snapd#6266 opened: tests: make security-device-cgroups-{devmode,jailmode} work on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6266>
<zyga> updated https://github.com/snapcore/snapd/pull/6149#discussion_r239058308
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> mborzecki: do you mean to make F29 non-manual in https://github.com/snapcore/snapd/pull/6264
<mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<mborzecki> zyga: yes, running with the latest batch of fixes, i'll label the PR as blocked for now
<zyga> thank you
<mup> PR snapd#6267 opened: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
<zyga> mborzecki, pstolowski:  I pushed a very simple PR to shrink my other feature PR, could you guys please look ^
<zyga> pstolowski: need a 2nd review on https://github.com/snapcore/snapd/pull/6149  :)
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> feel that this is finally moving forward :)
<pstolowski> zyga: ok, will do
<mborzecki> zyga: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ba8845b83b
<zyga> xnox: hey, what going to happen now that the SRU verification of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1778936 is failed?
<mup> Bug #1778936: please re-add Support-system-image-read-only-etc.patch <patch> <verification-needed> <verification-needed-bionic> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Bionic):Fix Committed> <systemd (Ubuntu Cosmic):Fix Released> <https://launchpad.net/bugs/1778936>
<cachio> zyga, https://github.com/sergiocazzolato/snapd/tree/tests-validate-lp-1778936
<zyga> cachio: can you add a note to that bug please, that explains how to reproduce the results of that test
<zyga> cachio: specifically how to build a system image with core18 which contains systemd from proposed
<cachio> ok
<zyga> thank you :)
<zyga> cachio: I'm not sure how what you changed there tests systemd form proposed
<zyga> since our testing process doesn't involve unpacking systemd into the repackaged core18 snap
<zyga> cachio: so you would still get the vanilla core18 from the store
<zyga> which has systemd from stable
<zyga> (well, from the archive)
<zyga> cachio: may I ask how you checked the version of systemd that you observed?
<zyga> cachio: in the effective image built with ubuntu-image?
<cachio> when the test fails
<cachio> zyga, it is possible to check systemd version in a debug session
<zyga> mhm
<zyga> and what is the version you saw?
<cachio>  237-3ubuntu10.10
<zyga> and how does that relate to the version in main and in proposed?
<cachio> in main is 237-3ubuntu10.7
<cachio> irrc
<zyga> the version that is mentioned in the bug report as containing the fix is different
<zyga> it is 239-7ubuntu7
<cachio> basically, what I do it to enable proposed and refresh systemd during the project preparation
<zyga> or 237-3ubuntu10.8 in bionic
<cachio> Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.10
<zyga> cachio: but that changes the starting throwaway image
<zyga> not the core18 image you build
<zyga> I don't see how the changes you did affect the core18 _snap_ that is used to build the image where tests execute
<zyga> it may be that this is correct
<zyga> but I don't understand it yet
<zyga> and I want to since the verification failed and this is an urgent issue
<cachio> let me create a debug session
<cachio> zyga, perhaps it works
<cachio> to understand better
<zyga> you can create one but can you argument how this is expected to  work
<zyga> I want to see how the proposed package ends up in the core18 snap
<cachio> so, we build core18 snap we use the deb snapd.deb we already created
<zyga> how do we build the core18 snap? can you show me please?
<cachio> zyga, sure, 1 sec
<zyga> thanks
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6244 is ready, if you have some time to look at the last patch I would love to land that and have that bug fixed :)
<cachio> https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L339
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<cachio> zyga, ~
<zyga> cachio: looking
<zyga> so
<zyga> we unpack the _snapd_ snap
<zyga> right?
<cachio> yes
<zyga> does the snapd snap contain systemd?
<zyga> AFAIK systemd is inside the core18 snap
<zyga> unless we are repackaing that one elsewhere, and based on the package from the host
<zyga> I don't see how this was testing proposed
<cachio> zyga, what I did is to enable proposed on this instance
<cachio> and add a dependency on snapd.deb to the package on proposed
<zyga> Sorry, in which instance?
<cachio> so then if we build the image based on out .deb
<cachio> instance is the ubuntu-18.04-64 that we use to create the image
<zyga> The test was checking snapd on core18 or on Ubuntu 18.04?
<cachio> zyga, the test checks on core 18 instance
<cachio> which is build on the fly using a ubuntu bionic image
<zyga> So explain how the choice of the host instance affects the system image built with Ubuntu image that is eventually tested?
<zyga> My understanding is that the core18 snap is coming from the store
<zyga> And that it contains systemd
<jlorenzo> kenvandine: oSoMoN: hi guys! a mozilla employee found an odd behavior regarding assertions (even though he installed the snap with `--dangerous`). He left more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1297531. Would you know who would be suited to help him out?
<zyga> And because we do not alter it in the test, that is the core18 snap is as-is from the store then the changes ran against the same systemd version as before
<cachio> mmm, I see in the code that we modify the snapd snap to use what we have in the snapd.deb
<zyga> Yes
<zyga> But snapd snap does not contain systemd
<kenvandine> hey jlorenzo
<oSoMoN> hey jlorenzo
<oSoMoN> reading that bug
<cachio> I though that by setting a dependency for the snapd.deb to use the systemd from proposed is enough to force the image gets this systemd
<cachio> but based on the code I am not 10% sure
<cachio> 100%
<zyga> It would if this was using apt
<zyga> But we unpack just snapd.deb
<zyga> Still
<zyga> I believe you saw the right version of systemd
<zyga> Can you tell me which channel of core18 was used in the test
<zyga> Was it edge?
<zyga> And is core18 edge using main or proposed?
<cachio> we use edge
<zyga> Perhaps you tested the SRU despite making changes that have no effect on the produced image
<kenvandine> oSoMoN: thanks
<zyga> Can you please check the core18 edge snap recipe
<zyga> It should have this information
<cachio> sure
<zyga> Thank you :-)
<oSoMoN> jlorenzo, no need for an assertion, for local tests the browser-support interface can be manually connected, I'll comment on the bug to explain
<diddledan> who can kick the store review thingy for me? gog-galaxy-wine revision 62 is stuck
<cachio> zyga, at least core is not built from proposed
<cachio> zyga, I can't see the recipy for core18
<jlorenzo> oSoMoN: got it! thank you very much for the help :)
<oSoMoN> jlorenzo, you're welcome
<cachio> zyga, so, I'll try to build a snapd.snap with systemd from proposed
<cachio> zyga, that should work right?
<zyga> re
<zyga> cachio: no, build core18 with systemd from proposed
<zyga> cachio: snapd.snap version is irrelevant
<zyga> cachio: can  you ask foundations for help, they should be able to point you to the recipe
<cachio> zyga, great, thanks
<cachio> I'll try that
<zyga> sure, let me know if you cannot find the recipe, I can look as well
<zyga> cachio: and please add a comment to the bug report that testing is still ongoing
<zyga> so that xnox doesn't take action on incomplete information
<cachio> zyga, sure, comment left
<zyga> super, thank you
<cachio> zyga, thanks for the help
<xnox> cachio, if you give me something i can boot in a VM, i'm happy to validate things =)
<xnox> w.r.t. etc-writable stuff.
<zyga> xnox: who builds the core18 images now, is that foundations?
<zyga> sorry, I was imprecise, I meant core18.snap
<zyga> xnox: looking at the core18 snap in edge, it ships with systemd 237
<zyga> but it doesn't have a manifest that I can look at
<cachio> xnox, still trying to build the correct image, I'll let you know when the image is ready for validation
<cachio> zyga, I searched on launchpad and couldn't find it
<cachio> at least in our projects
<cachio> so, foundations should be creating it, or mvo in same place
<cachio> zyga, the last core18 images which I tested were share by mvo
<cachio> zyga, I see this in the store -> core18 â Shared by canonical (snaps@canonical.com)
<cachio> so foundations should be creating them
<zyga> I found this repository: https://launchpad.net/snap-core18
<zyga> but not sure if that's used
<zyga> sil2100: hey
<zyga> sil2100: can you shed some light on core18 snap
<cachio> https://code.launchpad.net/~ubuntu-core-service/+snap/core18
<zyga> do you know where the source repository is and where the build recipe is (if it is built with a snap recipe)?
<zyga> cachio: nice, looking
<zyga> https://code.launchpad.net/~ubuntu-core-service/+snap/core18 says it is using primary archive for ubuntu
<zyga> so that doesn't look like it uses proposed
<zyga> and the publised snap goes to beta and edge
<zyga> this is using the updates pocket
<zyga> so not proposed
<zyga> so we need to repeat the test
<zyga> cloning that recipe
<cachio> zyga, is it possible to unpack core18 and manually replace systemd?
<zyga> cachio: yes but for correctness we should just rebuild it with different archive
<zyga> that's supposedly easy
<zyga> cjwatson: hey, could you please help us with one thing, we'd like to build https://code.launchpad.net/~ubuntu-core-service/+snap/core18 but switch the archive to proposed
<zyga> what's the easiest way to do that?
<zyga> we don't need to upload it to the store (though uploading to edge is ok)
<zyga> ideally edge could be out of proposed for real but we are after one-off test
<cjwatson> zyga: I'm on holiday today and tomorrow.  You should be able to work that one out from the apidoc though, I think
<zyga> thanks, looking!
<zyga> enjoy the holidays and don't worry :)
<xnox> zyga, cachio - even if foundations build it, it's not built with proposed on..... i don't think.....
<xnox> but it is not I =/
<zyga> xnox: yeah, I checked, it's built with updates
<zyga> xnox: trying to build it now
<cachio> zyga, do you have a way to build it?
<zyga> yes, I think so
<zyga> building now
<zyga> I will share what I did if this works
<cachio> zyga, great, thanks
<zyga> cachio: ok, I have a core18 now
<zyga> cachio: can you try this locally please:
<mup> PR snapd#6268 opened: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
<zyga> git clone -b master https://git.launchpad.net/snap-core18
<zyga> sed -i -e 's/current/pending/g' Makefile
<zyga> use snapcraft from the debian pacakge
<zyga> not from the snap:
<zyga> sudo snapcraft
<zyga> once built you can use that core18 snap to build an image
<zyga> after building you inspect the file dpkg.list found in /usr/share/snappy/dpkg.list
<zyga> for me it contains:
<zyga> ii  systemd                    237-3ubuntu10.10        amd64        system and service manager
<zyga> this corresponds to the proposed update that xnox wanted tested
<zyga> xnox: ^ can you please confirm that systemd 237-3ubuntu10.10 is the version that is under SRU?
<zyga> cachio: using that snap just build and boot a KVM image
<zyga> cachio: then you can run a test against that
<cachio> nice
<cachio> on that
<zyga> excellent, thank you!
<zyga> sergiusens: question about snapcraft the deb vs the snap
<zyga> I got a failure where snapcraftctl was not on PATH and the build failed
<zyga> is that expected with 3.x?
<zyga> should I file that as a bug
<zyga> the snap in question is core18 from the repository mentioned above
<cachio> zyga, in the building logs I see systemd is downloading from proposed
<cachio> so far no errors
<cachio> it is still building
<zyga> cachio: you can verify the manifest to be sure as well
<cachio> zyga, yes,
<zyga> pstolowski: some failures on that  hotplug PR
<zyga> https://www.irccloud.com/pastebin/vcIZiRRm/
<zyga> https://github.com/snapcore/snapd/pull/6268
<mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
<pstolowski> zyga: ok, interesting, looking
<zyga> pstolowski: if you can please review https://github.com/snapcore/snapd/pull/6267
<mup> PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
<pstolowski> zyga: will do; just finishing 6251
<zyga> thanks :)
<cachio> zyga, ii  systemd                    237-3ubuntu10.10        amd64        system and service manager
<zyga> cachio: great
<zyga> that's the new version
<zyga> right?
<cachio> yes
<cachio> thanks
<cachio> I am running the test now
<cachio> using the core18 snap just built
<cachio> zyga, it is gonna take time because it needs to upload 47 MB
<zyga> let me know if you have issues
<zyga> I can probably build a kvm image and test locally
<zyga> pstolowski: can you explain what you meant on https://github.com/snapcore/snapd/pull/6251#discussion_r239132132 ?
<zyga> ah
<mup> PR #6251: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
<zyga> I see it on the 3rd comment :)
<zyga> thanks, I'll add an explanation of SNAPD_DEBUG=x :)
<pstolowski> zyga: sorry :)
<zyga> nothing to be sorry about :)
<zyga> thank you
<zyga> pstolowski: more errors
<pstolowski> zyga: uhm, thanks, checking
<zyga> https://www.irccloud.com/pastebin/Bg0hqSL4/
<zyga> pstolowski: if you can review https://github.com/snapcore/snapd/pull/6149 before EOD it would make my day,
<zyga> more progress on user mounts than all of last week :)
<mup> PR #6149: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6149>
<zyga> jdstrand: hey
<zyga> jdstrand: not sure if you are sprinting this week, I just need a quick look at https://github.com/snapcore/snapd/pull/6244/commits/29301fca5a7a465305421e4633b9488b64942adc which I believe implements spirit of what you asked for in https://github.com/snapcore/snapd/pull/6244#discussion_r238677532
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<pstolowski> interesting it doesn't panic locally, yet clearly its missing locking
<zyga> huh
<zyga> that's odd
<zyga> that lock panic should be deterministic?
<zyga> are you missing anything from master?
<pstolowski> yes, if this code was not hit then the asserts around order would fail at the end of the test
<pstolowski> anyway, pushed a fix
<zyga> thanks
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6262 needs a 2nd review
<zyga> small trivial branch from jamie
<mup> PR #6262: apparmor: allow snap-update-ns access to common devices <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6262>
<zyga> and I'd love a review on this one https://github.com/snapcore/snapd/pull/6267
<mup> PR #6267: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6267>
<zyga> +9,-5 :)
<pstolowski> 6149 +1
<zyga> woot, thanks
<pstolowski> reviewed it yesterday and forgot to conclude
<mup> PR snapd#6149 closed: cmd/snap-confine: capture initialized per-user mount ns <Per-user mount ns  ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6149>
<mup> PR snapd#6262 closed: apparmor: allow snap-update-ns access to common devices <Simple ð> <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6262>
<zyga> we'll  be at 39 PRs soon
 * cachio lunch
<xnox> zyga, yes.
<zyga> xnox: great
<zyga> xnox: cachio is confirming this, we should get the result today
<xnox> zyga, whoop whoop
<zyga> :-)
<ackk> hi, I'm hitting an issue with the python plugin. I have a dependency in the requirements.txt which is pulled from a git repo. so pip complains about finding stuff in the src/ dir, which I so far had workarounded with "rm -rf $SNAPCRAFT_STAGE/../src/*" in override-pull. This doesn't seem to work anymore when building in multipass as the srcdir is in a different location. is there a way to handle both cases?
<kyrofa> Content interface question: can the default provider include a specific track?
<kyrofa> (zyga I suppose that's a question for you)
<zyga> kyrofa: I don't think so, it's not as unified yet
<zyga> I'm afk now (grocery) but I can check for sure later
<kyrofa> Thanks zyga
<zyga> kyrofa: seems sensible to say default-provider: foo=edge
<zyga> or something like that
<zyga> we have that syntax (new syntax) in one place and will probably grow it
<kyrofa> Or foo/edge ;)
<kyrofa> Yeah... I know
<zyga> no, the syntax is really foo=edge
<zyga> not foo/edge
<kyrofa> Haha, I know
<zyga> ok :)
<cachio> zyga, works
<cachio> :)
<cachio> https://paste.ubuntu.com/p/z4Vjz2jYYG/
<cachio> xnox, hey, I confirm that the fix works
<cachio> I'll add steps to reproduce the test in the lp
<xnox> cachio, cool, state so / comment on the bug report, including the version number of systemd that is included in your self-built core18 snap.
<xnox> cachio, sru team want that there.
<cachio> xnox, good, already adding that info
<cachio> thanks
<cachio> xnox, please tell me if it is ok the validation steps which I added
<cachio> xnox, now I am gonna run the whole test suite to check there are no regressions
<pitfd> join /galliumos
<zyga> Thank you cachio!
<cachio> zyga, np
<sergiusens> zyga we do not support the Deb anymore. Maintenance mode only, do not expect new features there. I was off today and will be off tomorrow too so light weight answers is what you get ð
<katamo> ha, so I'm feeling defeated today trying to move from the dump plugin to the proper python plugin. Error complains the executable in the bin/ directory does not exist
<zyga> sergiusens: cool, thank you for sharing that
<mup> PR snapd#6251 closed: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6251>
<zyga> jdstrand: hello
<zyga> jdstrand: I saw the feedback, thank you :)
<zyga> jdstrand: I left some ideas for discussion
<zyga> jdstrand: hey, pushed again, I think this time is it :)
<zyga> it is it :)
<zyga> now we clarly differentiate things with 0 features from not having things
#snappy 2018-12-06
<mborzecki> morning
<mborzecki> zyga: pushed some fixes to #6264
<mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<mborzecki> that was one annoying distro upgrade, hopefully the changes make the whole test suite better
<pstolowski> mornings
<zyga> Hey ho
<zyga> Just woke up
<zyga> Iâll be around shortly
<mborzecki> pstolowski: zyga: hey
<zyga> Hi :-)
<zyga> Feels like winter
<jamesh> zyga: thanks for the help with that test snap yesterday.  It build successfully, but I'm guessing it got trapped by automated review.  I'm not sure who other than mvo has access to that snap.
<zyga> I think jdstrand can check the status
<zyga> I will ping mvo about the snap too just in case he has some time
<jamesh> Running review-tools manually, it seems to be complaining about the new attribute on the dbus interface, and the fact I used "daemon: dbus" for one of the apps
<jamesh> something snapd supports but snapcraft and review-tools don't seem to like
<zyga> Hmmmm
<vidal72[m]> mborzecki: this may affect snapd in arch: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/filesystem&id=6fa932aa685da87e78e0f845bd890645607d302e , https://bugs.archlinux.org/task/58499
<zyga> Maybe that is something for roadmr as well
<zyga> Can you write a forum post about it please? It will be easier to as for help this way
<mborzecki> vidal72[m]: thanks, i'm subscribed already, they actually changed it to ID=archlinux https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/filesystem&id=6fa932aa685da87e78e0f845bd890645607d302e
<mborzecki> wonder if snapd is the only project that checks that at all
<vidal72[m]> breaking something is the best way to know is someone used it :)
<mborzecki> updated golang got pushed to EPEL stable, hopefully we'll be able to switch centos image to 7.6 tomorrow
<zyga> :-)
<mborzecki> hm hm actually switched the image temporarily and was able to build snapd package
<mborzecki> a unit test failed failed in fedora 29 pr https://paste.ubuntu.com/p/r8WGW9DHNW/ a race of sorts?
<pstolowski> looking
<pstolowski> mborzecki: hmm close to the area of system key computation that was touched recently
<pstolowski> zyga: ^
<pstolowski> running this test in a loop locally, works fine, i suspect it's because system key is in place (do we miss mocking in the test?)
<zyga> mmm
<zyga> looking
<zyga> feels unrelated
<zyga> like missing mocking
<zyga> "foo failed" was expectef
<zyga> but logs had something else
<mup> PR snapd#6232 closed: overlord/snapstate: support for pre-remove hook <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/6232>
<pstolowski> zyga, mborzecki #6268 is green now and needs reviews
<mup> PR #6268: overlord/ifacestate: helpers for serializing hotplug changes <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6268>
<zyga> looking
<pstolowski> zyga, mborzecki do you have anything that needs a review?
<zyga> I mainly have https://github.com/snapcore/snapd/pull/6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<mborzecki> pstolowski: #6264
<mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<pstolowski> ok
<pstolowski> mborzecki: oh wow... that looks like whack-a-mole (not your fault)
<mborzecki> pstolowski: yeah, loads of fun
<zyga> mborzecki: did you get to the bottom of why those tests with swapped su username passed before?
<mborzecki> zyga: yes, the project path created by spread is subject to default umask, that has changed in fedora 29, but was 022 before, so the directories along the path got 755, then the snapd source tree is owned by test:test, even though /home/gopath/src/github.com/snapcore/snapd is owned by root:root
<pstolowski> mborzecki: would it be possible to set umask anywhere in prepare.sh to have sane defaults for all tests (if not already there)?
<pstolowski> (i suppose it's not that easy, but curious)
<mborzecki> pstolowski: idk whether spread makes a single huge script of each prepare, prepare-each, execute block, but it'd probably need to be set by spread to be effective
<mborzecki> maybe it makes sense to extend spread to support umask: 022 in spread.yaml
<pstolowski> mborzecki: uhm, right, i see
<mborzecki> zyga: oh, and some of the tests that i fixed never executed on fedora (because of systems: [..]), or only ran for strict confinement
<zyga> mborzecki: spread uses shell, cat to write files and execute them
<zyga> mborzecki: I spent some time looking at it
<mborzecki> zyga: hm so spread level thing probably makes most sense
<zyga> mborzecki: I have some patches to use sftp to send files back and forth
<zyga> but probably unlikely to land them
<mborzecki> anyways, the fixes are imo useful either way :)
<mborzecki> damn, hate travis ui
<mborzecki> open travis job, 'raw log' button appears only once the log was downloaded a chopped into folds by js
<zyga> maybe we should kill the folds
<zyga> they are -1 useful
<zyga> travis is slow like hell anyway
<zyga> I only ever use the raw log
<zyga> and often it is too long
<zyga> folds don't help in the raw log
<mup> PR snapd#6269 opened: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6269>
<mborzecki> zyga: pstolowski: ^^ simple one
<zyga> I will probably do only reviews in the morning
<pstolowski> k
<zyga> thanks maciek!
<mborzecki> we'll need to cherry-pick that to 2.36
<mborzecki> and in the meantime, i'll ship a patch with the package
<zyga> mborzecki: commented inline but +1
<mborzecki> thx
<zyga> I think we should do 2.37 next week
<zyga> backporting sucks
<mborzecki> zyga: btw. i think there was a subtle bug in the code you pointed
<zyga> oh? where?
<mborzecki> defers are executed LIFO, so the defer dirs.SetRootDir() would execute before restore of mocking os release
<zyga> mmm
<pstolowski> mborzecki: there is one more defer setrootdir in this test
<pstolowski> (in the old code)
<Xceed> is there a way to do the following with getting a validation error...
<Xceed> text=$(cat <<EOF
<Xceed> branch = master
<Xceed> EOF
<Xceed> )
<Xceed> within override-prime:
<Xceed> as a scriptlet
<Xceed> s/with/without
 * zyga is not well
<pstolowski> Xceed: you may want to ask on the forum where more snapcrafters can help
<zyga> mborzecki, pstolowski: it's funny how we use go
<zyga> but our task/change system is really a bunch of python-like key=value store
<zyga> pstolowski: sorry for the lag, I feel really so-so
<zyga> reviewed
<pstolowski> true. i think that's common for task-based solutions like ours.. i saw that in other projects
<pstolowski> you end up with flexible datatypes, such as variant to stuff metadata on tasks
<pstolowski> zyga: no worries, get some rest
<zyga> I'm happy to do more reviews
<zyga> anyone?
<Xceed> i used separate lines of echos instead, crude, but it works and ive spent too much time on this
<zyga> xnox: is the problem with yaml?
<zyga> er
<zyga> Xceed: ^
<zyga> (sorry xnox, bad tab completion again)
<pstolowski> zyga: https://github.com/snapcore/snapd/pull/6114 is the closes hotplug PR to land, but i think we want mvo's review anyway
<mup> PR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>
<Xceed> yes, i copied pasted a multiline cat file <<EOF type that works in the script to the yaml and it failed
<pstolowski> zyga: otherwise nothing immediate from me, thanks for the review of hotplug seq
<zyga> Xceed: can you show me the yaml please?
<Xceed> i did, see above
<zyga> I mean a larger fragment
<zyga> that shows the key-value in yaml
<zyga> unless I missed that, sorry
<zyga> my daughter has cold and is sick this week, I guess I'm becoming affected
<zyga> mborzecki: do you feel we could review and land the snapd.mk branch?
<Xceed> zyga, https://vgy.me/OT7tii.png
<zyga> aba
<zyga> that's not valid yaml
<zyga> not the way you expect at least
<zyga> parse that with any yaml parser to see what the structure is
<zyga> indent lines 69-71
<zyga> to be flush with the indent of cat
<mborzecki> Xceed: indent to match `cat`
<zyga> and re-parse
<zyga> yep
<Xceed> its a scriptlet, i expect all inside EOT to be taken as a raw output though
<Xceed> otherise any identation will be added to the output file
<zyga> it's yaml
<zyga> not shell script
<zyga> all the stuff in this document is yaml
<mborzecki> Xceed: but it must be a valid yaml in the first place, this one is not
<zyga> the values may be strings
<zyga> the strings may have any content
<zyga> but you must make it valid yaml first
<Xceed> k, thanks guys
<mup> PR snapd#6267 closed: overlord: move Conf interface to configstate/config to avoid cyclic imports <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6267>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6264 is green
<mup> PR #6264: spread, tests: add Fedora 29 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<mborzecki> yay
<mup> PR snapd#6264 closed: spread, tests: add Fedora 29 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6264>
<zyga> jamesh: relayed to mvo
<zyga> I'll also chase with jdstrand later today
<zyga> mborzecki: looking at https://github.com/kubernetes-sigs/kind
<zyga> I like the pkg/ tree
<zyga> I mean, putting various source code under pkg/
<zyga> and not in random spots in the top level
<mborzecki> hm can we replace the nice 'crushing failure and despair' or the pony with a useful piece of text?
<mborzecki> ./run-checks --short-unit output is ok locally, but quite useless on travis
<mborzecki> can't figure out why unit tests (the separate job) fail: https://api.travis-ci.org/v3/job/464278797/log.txt
<mborzecki> the log ends with:
<mborzecki> The command "./run-checks --short-unit" exited with 0
<mborzecki> Done. Your build exited with 1.
<mborzecki> wtf?
<jamesh> zyga: thanks.  I've written up the question over using "daemon: dbus" here: https://forum.snapcraft.io/t/support-for-daemon-dbus/8855
<zyga> jamesh: thank you, I will use this for talking with jdstrand later todat
<zyga> *today
<zyga> mborzecki: yes
<zyga> mborzecki: it sucks
<zyga> mborzecki: I had a PR for this, one sec
<zyga> https://github.com/snapcore/snapd/pull/6209
<mup> PR #6209: run-checks: discard test good/bad banner <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6209>
<mup> PR snapd#6209 opened: run-checks: discard test good/bad banner <Created by zyga> <https://github.com/snapcore/snapd/pull/6209>
<mborzecki> nice
<mborzecki> wonder if mvo prefers to see the banner on his terminal or on travis
<zyga> one thing to fix
<mborzecki> the html log shows the banner correctly iirc
<zyga> is to fail fastt
<mborzecki> yup
<zyga> not go on doing useless extra tests if something failed
<zyga> mborzecki: I would honestly prefer a short summary
<zyga> saying stuff like:
<zyga> unit tests: pass
<zyga> format: fail
<zyga> vet: pass
<zyga> etc
<zyga> the banner is childlish
<zyga> and I haven't seen it displayed properly in the last year
<mborzecki> heh
<mborzecki> idk maybe some isatty check in the shell would do
<zyga> IMO the banner is pointless but that's just me
<pstolowski> +1
<pstolowski> we could easily find a single utf emoji to replace it ;)
<Xceed> ${SNAP_COMMON} used in the scope of the apps.name.command: contains <apps.name> i.e. /var/snap/<apps.name>/common but in the scope of override-prime does not i.e. /var/snap/snapcraft/common (so 'snapcraft' instead). So, I append '/../../<apps.name>/common' in order to make ${SNAP_COMMON} path in the scope of prime to be consistent with that at the command runtime - a little kludgy but it worked.
<pstolowski> zyga: some comments to #6190
<mup> PR #6190: overlord/configstate,features: expose features to snapd tools <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6190>
<zyga> thank you
<pstolowski> zyga: sorry if they are naive
<pstolowski> i'm likely missing a detail or some agreement
<zyga> pstolowski: thank you, replied to most
<zyga> ask questions about anything you want, I realise some of the choices may be more obscure than usual
<pstolowski> zyga: thanks
<zyga> thank you for looking :)
<jdstrand> jamesh, zyga: there is some history with 'daemon: dbus'. I'll have to research but will comment in the forum
 * zyga nods
<pstolowski> mborzecki: i'm still puzzled about multiple dirs.SetRootDir("/") in TestPathsArch in https://github.com/snapcore/snapd/pull/6269
<mup> PR #6269: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6269>
<pstolowski> if you can address that then i'm happy to approve
<mborzecki> pstolowski: we update the paths only when dirs.SetRootDir() is called, that's why it has to be called again after changing the mocked os-reelase info
<mborzecki> pstolowski: does that answer your question?
<pstolowski> mborzecki: ah, i see, yes, thanks!
<cachio> zyga, hey
<cachio> about this spread: detect "signal: terminated" in journal logs
<cachio> it is breaking all the tests on borads
<cachio> :(
<zyga> can you show some example please?
<cachio> I see lines like this one
<cachio> Dec 06 05:12:04 localhost.localdomain snapd[1998]: udevmon.go:119: udev enumeration error: cannot read udevadm output: signal: terminated
<cachio> which make the test suite fail
<zyga> cachio: can you please show systemctl cat snapd.service
<cachio> zyga, https://paste.ubuntu.com/p/64hkcch6FT/
<zyga> cachio: can you tell me how those tests are being used
<zyga> it seems like tests are out of sync with the running code
<zyga> https://github.com/snapcore/snapd/pull/6250
<mup> PR #6250: data: set KillMode=process for snapd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6250>
<zyga> this PR introduced the check for "signal: terminated"
<zyga> as well as a change to the systemd unit for snapd service
<cachio> the ones on edge: I flash stable image, then I refresh to edge
<cachio> and run the tests using external backend
<zyga> the only way tests would pass is you always tested (whichever channel) with a matching test tree
<zyga> so we need to either update snapd/core to match tetsts
<zyga> or downgrade tests to match snapd/core
<cachio> zyga, on edge tests I am doing that
<cachio> using core from edge and using the last commit pushed to snapd-vender and used to build the core snap
<zyga> and the failure you saw, was that following the process?
<zyga> that you just outlined?
<mborzecki> pstolowski: can i have your +1 on https://github.com/snapcore/snapd/pull/6269 ? :)
<mup> PR #6269: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6269>
<zyga> cachio: ?
<cachio> zyga, I ran the lxd test
<pstolowski> mborzecki: absolutely
<zyga> cachio: not sure how that answers my question
<zyga> cachio: were the tests and the code in sync when that failure was reported?
<cachio> zyga, yes
<mborzecki> pstolowski: ta
<cachio> core from edge
<zyga> cachio: can you look at the PR I referenced above please
<zyga> it adds the new check
<zyga> and adds a KillMode=process entry to the systemd service
<zyga> right?
<zyga> how can we explain that the test was present but the service was not changed?
<cachio> zyga, checking logs to see traceability
<zyga> cachio: my explanation is that the service is not changed because the test system was out of date with tests
<zyga> would be great to figure out if that's true and if so, what needs changing
<cachio> zyga, yes, got it, I am trying to see the traceability between the tests we are using and the changes included in edge
<cachio> to determine if those are really on sync
<zyga> mborzecki, pstolowski: I'm in bed, will skip standup
<mborzecki> zyga: ack
<zyga> my update: not feeling well, doing some simpler tasks,
<pstolowski> ack, shall we skipp standup then and do quick one on irc?
<mborzecki> pstolowski: we can do the regular one
<pstolowski> ok
<mup> PR snapd#6269 closed: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6269>
<mup> PR snapd#6270 opened: data/selinux, tests: refactor SELinux policy, add minimal tests <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6270>
<mborzecki> off to pick up the kids
<kravietz> hi all, my snapcraft has just upgraded to 3 and it tries to build snaps with multipass, but multipass won't work on a build server that is a VM itself - any ideas?
<roadmr> kravietz: if the VM is throwaway, you can use --destructive-mode
<roadmr> but it is destructive :)
<kravietz> in what sense?
<kravietz> is is the same as in snapcraft 2?
<kravietz> for now I have just reverted to the latest 2.x
<zyga> jdstrand: gentle ping about https://github.com/snapcore/snapd/pull/6244
<mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
<niemeyer> sergiusens: Was just running snapcraft now and got surprised by how slow it is to even start
<niemeyer> sergiusens: Looks like a regression
 * cachio lunch
<kjackal> hi snappy people, I have this LP builder that was supposed to push a snap to the store an hour ago, but I do not see it https://launchpad.net/~microk8s-dev/+snap/microk8s-1.13
<kjackal> We have already builders for 1.12, 1.11, 1.10 and latest snap tracks and they work with no issues
 * cachio afk
<zyga> jdstrand: thank you!
<zyga> jdstrand: I pushed the fixes too btw
<zyga> woot, that was one spicy branch to land :-)
<jdstrand> zyga: thanks!
<jdstrand> hehe, yes
<zyga> I'm happy 2.36 got the "short" version of that branch
<zyga> with 0 changes to release/apparmor.go
<zyga> but I'm also happy this made it into master, it's much nicer now
#snappy 2018-12-07
<zyga> Hello
<mborzecki> morning
<zyga> hey maciek
<zyga> I must ask you, are your kids already in school?
<zyga> how are you doing it so that you start so early :)
<mborzecki> zyga: my wife drives them to school ~7am
<zyga> mmmm
<mborzecki> zyga: btw. desktop-portal-activation strikes again on fedora 29
<mup> PR snapd#6254 closed: tests: improve how the log is checked to see if the system is waiting for a reboot <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6254>
<zyga> mborzecki: I saw it fail a bunch of times yesterday
<zyga> any ideas?
<mborzecki> zyga: running the suite now, i suppose xdg-desktop-portal is installed for some reason and gets activated instead of the helper used by test
<zyga> mmm
<zyga> ok
<mborzecki> zyga: btw. we've had weak dependencies in dnf disabled earlier for installation from fedora repos
<zyga> yeah, I remember
<mborzecki> zyga: have you repened snapd.mk pr?
<zyga> mborzecki: no, I bailed from most work yesterday
<zyga> my daughter is going to school today
<zyga> I feel like going to bed instead
<mborzecki> zyga: ah, how are you feeling today?
<zyga> I can reopen it quickly
<zyga> same as yesterday, let's see how the day unfolds
<mup> PR snapd#6111 opened: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mborzecki: ^ reopened
<zyga> mborzecki: since tests are hit and miss
<zyga> I would land as-is
<zyga> and try to iterate on top
<mup> PR core18#94 opened: hooks: add cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/94>
<zyga> mborzecki: I've prepared the extra changes on top of the vanilla snapd.mk
<mborzecki> ack
<zyga> I'll verify that nothing is missing and push them as well
<pstolowski> morning
<zyga> o/
<mborzecki> pstolowski: hey
<ackk> hi, are there plans to SRU snapcraft 3 to bionic, or is snap the way to go?
<pstolowski> ackk: sergiusens may be able to answer this, but he will probably show up in a few hours
<ackk> pstolowski, thanks
<zyga> mborzecki: much nicer now, I also added the with_... variables so the spec is shorter and nicer as well
<zyga> mborzecki: pushed now
<zyga> please look :)
<zyga> messed up some history, pushed again
<zyga> the new thing is https://github.com/snapcore/snapd/pull/6111/commits/e3f89e4e9ca3b9081375291daf9e6ee45ab9b1cc
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> but this is still broken, man
<zyga> my built tree :)
<zyga> sorry
<zyga> and pushed again
<zyga> https://github.com/snapcore/snapd/pull/6111/commits/da6ddecb72b9b0a8abf775b96938c1cc80456a94
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<mborzecki> zyga: https://www.youtube.com/watch?v=d2E_iiTd9hQ
<zyga> mborzecki: evil in me wants to call spread with a fixed seed so that tests are less insanely annoying
<zyga> mborzecki: I see and I raise https://www.youtube.com/watch?v=Pmd3UiNfNkA ;D
<mborzecki> hahah
<zyga> this doesn't look like a happy day
<zyga> mborzecki: shall we disable that test until it is sorted out?
<mborzecki> zyga: yeah, on fedora at least
<zyga> mborzecki: can you please?
<mborzecki> there's something fishy about the fedora image we use under spread
<mborzecki> zyga: take a look at this https://paste.ubuntu.com/p/W3yxdGYTxW/
<zyga> mmm
<zyga> so
<zyga> those are different images,
<zyga> the /etc/os-release will confirm as much
<zyga> I bet those pull in different defaults
<zyga> IMO our spread image looks like a workstation image
<mborzecki> dnf version is different, spread has 4.0.4, cloud has 4.0.9
<zyga> and the cloud image is a genuine cloud image
<mborzecki> yup
<zyga> what does /etc/os-release say?
<mborzecki> sec, it's blocked installing upgrades
<mborzecki> zyga: package lists diff https://paste.ubuntu.com/p/MGRxmnZ9cB/ pkgs-there is the spread image, pkgs-here is the cloud image i'm using
<mborzecki> idk why there's a bunch of desktop related package
<zyga> Looking
<zyga> Haskell?
<mborzecki> shellcheck probably or sth
<mborzecki> gnome-online-accounts?
<mborzecki> aahhh
<mborzecki> damn, those are the images that have dependencies installed
<mborzecki> zyga: iirc that was something about reducing how long it takes to run a test
<mborzecki> s/a test/test suite/
<zyga> Yeah, probably exactly that
<mborzecki> damn, those are the images that have dependencies installed ents xdg-desktop-portal-gtk gives
<mborzecki> (gtk3 and (flatpak or snapd))
<mborzecki> so yeah, gtk3 is installed, and it's installing snapd
<mborzecki> though pulling in flatpak feels like a bug
<mborzecki> but hey, xdg-desktop-portal has flatpak >= 0.11.1 in requires
<mborzecki> so this feels like a bug in xdg-desktop-portal packaging
<mborzecki> zyga: wow, it really does require flatpak to build even
<zyga> For real?
<zyga> It partially makes sense since it was split out only recently
<mborzecki> yeah
<mborzecki> zyga: maybe we should just disable weak deps on fedora
<mborzecki> zyga: i'm writing an elaborate workaround, but the simplest solution to jsut disable it feels most appealing
<zyga> Iâm eager to see both
<zyga> now
<zyga> Iâm afk for some time no
<mup> PR snapd#6271 opened: tests/lib/pkgdb: disable weak deps on Fedora <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6271>
<mborzecki> zyga: ^^
<mborzecki> zyga: elaborate was (if fedora && installing snapd) -> disable weak deps
<zyga> Brb
<mup> PR core18#95 opened: hooks: add foreign libc6 on amd64/arm64 to enable bi-arch support <Created by mvo5> <https://github.com/snapcore/core18/pull/95>
<mup> PR snapd#6272 opened: overlord/snapstate: run 'remove' hook before 'auto-disconnect' <Created by stolowski> <https://github.com/snapcore/snapd/pull/6272>
<zyga> Approved the
<zyga> Approved the pr mborzecki
<mborzecki> thx, we'll see if it works in practice or not
<mborzecki> zyga: damn, that upgrade to f29 was tricky, lots of little things falling apart
<mborzecki> zyga: left some comments under snapd.mk pr
<zyga> mborzecki: wow, https://github.com/snapcore/snapd/pull/6111 got green :)
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> thanks, looking now
<mup> PR snapd#6273 opened: centos: enable SELinux support on CentOS 7 <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6273>
<mup> PR core18#95 closed: hooks: add foreign libc6 on amd64/arm64 to enable bi-arch support <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/95>
<zyga> mborzecki: pushed to https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mborzecki: I'd like to land that now and tweak various with settings, unless you disagree
<mborzecki> zyga: sounds good to me, but maybe ping Son_Goku about that %bcond_with thing
<zyga> sure
<zyga> Son_Goku: hey
<zyga> Son_Goku: I've resurrected https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> it now implements the split makefile with definitions idea
<zyga> I think you understand various with/bcond semantics in rpm better than I do
<zyga> I'd like to merge that branch as soon as it is green (a luxury lately)
<zyga> but I'm happy to improve things on top
<zyga> namely the set of variables used
<zyga> for easier fedora comparison
<zyga> as well as the bcond/with use
<zyga> for that second one I'm happy to take suggestions as I struggled with it and got nowhere
<zyga> Iâm afk again
 * pstolowski lunch
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6271 ?
<mup> PR #6271: tests/lib/pkgdb: disable weak deps on Fedora <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6271>
<zyga> It should also be critical
<zyga> Anything that fixes master to some degree
<mborzecki> zyga: let's start with green :)
<mborzecki> anyways, it's green
<cachio> mborzecki, hey
<cachio> we had some issues to update fedora 29
<cachio> mborzecki, have you seen this before https://paste.ubuntu.com/p/nMhRYJPwRc/ ?
<mborzecki> cachio: nope
<cachio> ok, mborzecki I am gonna debug it
<cachio> I need to create a test image first
<mup> PR snapd#6244 closed: release: detect too old apparmor_parser <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6244>
<cachio> zyga, mborzecki I have the end of year event in my daughter's school
<cachio> zyga, mborzecki not sure if I'll be back for the standup
<cachio> currently I am working on making the snapd test suite work on rigado
<cachio> and 2 issues
<cachio> 1 fedora 29 is failing to update
<cachio> and 2 failover test still fails to install the dangerous snap
<mborzecki> cachio: fedora 29 as in dnf upgrade -y ?
<zyga> Ack
<cachio> mborzecki, yes
<mborzecki> cachio: what's the problem then? i've run it today in spread shell, worked just fine
<cachio> mborzecki, not sure yet, it failed during the nightly execution
<cachio> I am creating a test image right now to debug it
<cachio> mborzecki, I have to go now, I'll continue with this when I am back
<mborzecki> ok
<cachio> mborzecki, the problem is with autoremove
<cachio> + dnf -q -y autoremove
<cachio> Error:
<cachio>  Problem: The operation would result in removing the following protected packages: kernel-core
<cachio> mborzecki, that's what I saw
 * cachio afk
<mup> PR snapd#6274 opened: cmd, dirs, interfaces/apparmor: update distro identification to support ID="archlinux" (2.36) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6274>
<mborzecki> zyga: pstolowski: ^^ simple cherry pick
<pstolowski> k
<zyga> Mhmm
<popey> no chipaca or mvo today?
<zyga> popey: thatâs correct
<zyga> All week in fact
<popey> ah okay, thanks!
<zyga> Do you need something?
<popey> we have a regular catch up with them, but if they're not around that's okay.
<popey> We onlyt had one thing to discuss :)
<popey> You may know the answer.
<popey> What's the support status for 14.04?
<zyga> Shoot :-)
<zyga> Still supported, Extended support status unclear
<zyga> We need clear indication if snapd is part of the extended support package
<popey> https://forum.snapcraft.io/t/cannot-perform-operation-no-such-file-or-directory/8870
<popey> ^ for example.
<popey> I think Wimpress also had an issue with a core18 snap on 14.04
<zyga> Iâll check after lunch
<zyga> Thanks for bringing this up
<Wimpress> zyga: Do you know the status of the font cache fixes?
<Wimpress> I know the binaries we're in the core image in edge. But what about the PR for snapd?
<zyga> Yes, they are in 2.36.2
<Wimpress> Everything? All done?
<zyga> As soon as that hits stable we are good
<zyga> I believe so
<zyga> However
<zyga> We know more work is needed
<Wimpress> Yeh, I know this is a first pass.
<zyga> mborzecki found issues on Fedora
<Wimpress> But, my tests are very positive
<Wimpress> And this could unblock the release of a popular editor.
<zyga> Yes
<zyga> Wink wink :-)
<Wimpress> ;-)
<Wimpress> OK, thanks. That is enough to be going on with.
<Wimpress> The 14.04 thing keeps coming up.
<Wimpress> We need clear guidance on that.
<zyga> Agreed
<zyga> Who can decide?
<mborzecki> emacs as a snap? :)
<Wimpress> zyga: Perhaps JamieBennett can?
<jdstrand> diddledan: hi! glad to hear you're picking pushing the sem_open to snapcraft-preload. note there is a TODO in there I'd like to implement. I'll ping you when I do it (I'll do it this morning)
<diddledan> ok, thanks :-)
<jdstrand> diddledan: were you able to test it with your application?
 * jdstrand was thinking about diddledan while doing the investigation
<diddledan> I'm just finishing the compile now and will test soon
<jdstrand> neat :)
<diddledan> I've actually got two apps I want to try it with - makemkv and mycroft
<diddledan> although I think mycroft is actually shm that's wonky, not semaphores
<diddledan> err. I mean makemkv with the shm
<diddledan> mycroft is python multiprocessing, so that should work now, hopefully
<mborzecki> zyga: pushed more tweaks to #6273
<mup> PR #6273: centos: enable SELinux support on CentOS 7 <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6273>
<mborzecki> off to pick up the kids
<Son_Goku> zyga, I wonder if we're going to get to a point where the openSUSE conditionals are absorbed into the Fedora spec as well
<Son_Goku> at this point, there isn't that much else left to make that happen
<zyga> Looking
<zyga> Son_Goku: maaaaybe
<mup> PR snapd#6271 closed: tests/lib/pkgdb: disable weak deps on Fedora <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6271>
<zyga> Iâll skip standup today
<pstolowski> zyga: ack
<pstolowski> cachio: standup?
<pstolowski> cachio: ah, you skipping as well, sorry, missed that
 * diddledan sits down
<mup> PR snapcraft#2420 opened: static: update to the latest flake8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2420>
 * cachio lunch
<mup> PR snapcraft#2421 opened: tests: remove obsolete snap and external tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2421>
<jdstrand> diddledan: fyi, https://forum.snapcraft.io/t/python-multiprocessing-sem-open-blocked-in-strict-mode/962/15
<diddledan> thanks jdstrand
<jdstrand> now if github would actually show me the branch I pushed, I could submit the PR
<jdstrand> (to snapd)
<diddledan> :-)
<jdstrand> is github behaving weird for anyone else?
<jdstrand> I go to me https://github.com/jdstrand/snapd/ and it just spins on 'Fetching last commit'
<jdstrand> and I can look at my branchs
<jdstrand> huh, hmaybe it is firefox. chromium is acting differently
<mup> PR snapd#6275 opened: apparmor: allow hard link to snap-specific semaphore files <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6275>
<sergiusens> jdstrand: browser restart to pick up updates maybe?
<jdstrand> sergiusens: I did that. it seems that github added something that noscript was blocking. allowed that and it works again
<mup> PR snapd#6276 opened: apparmor: allow hard link to snap-specific semaphore files - 2.36 <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6276>
<mup> PR snapd#6275 closed: apparmor: allow hard link to snap-specific semaphore files <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6275>
<mup> PR snapd#6276 closed: apparmor: allow hard link to snap-specific semaphore files - 2.36 <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6276>
<mup> PR snapd#6273 closed: centos: enable SELinux support on CentOS 7 <SELinux> <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6273>
<mup> PR snapcraft#2420 closed: static: update to the latest flake8 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2420>
<zyga> Pharaoh_Atem: hello
<zyga> do you have a moment?
<Pharaoh_Atem> zyga: hm?
<zyga> hey!
<zyga> I'd like to ask about https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> I would like to merge it but I'd rather not do it without your approval
<zyga> could we come up with some plan to move forward
<Pharaoh_Atem> let me look over it this weekend, and let me see if I can give you actionable feedback to move forward
<zyga> thank you
<mup> PR snapcraft#2422 opened: clean: user friendly message when cleaning <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2422>
#snappy 2018-12-08
<brlin> The snaps in --jailmode are using the user's real home directory, is that expected behavior?
<zyga> brlin: no, it is not
<zyga> brlin: can you please report a bug
<zyga> brlin: on launchpad.net/snapd/
<zyga> reported as https://bugs.launchpad.net/snapd/+bug/1807512
<mup> Bug #1807512: Classic snaps used in --jailmode still use real home directory <snapd:Triaged> <https://launchpad.net/bugs/1807512>
#snappy 2018-12-09
<brlin> https://forum.snapcraft.io/t/reliable-way-of-detecting-snap-confinement-mode/8896
<brlin> zyga: ack
<brlin> BTW, I'm referring to --classic snaps, but installed with with --jailmode switch
<brlin> s/with with/with the/
<brlin> https://bugs.launchpad.net/snapcraft/+bug/1807553
<mup> Bug #1807553: Snapcraft crashes after changing `dump` part's source content <Snapcraft:New> <https://launchpad.net/bugs/1807553>
<brlin> https://bugs.launchpad.net/snapcraft/+bug/1807555
<mup> Bug #1807555: Snapcraft forgot adopt-info is provided by `snapcraft set-version` in some circumstances <Snapcraft:New> <https://launchpad.net/bugs/1807555>
<xieta> Hello, I am new to snapcraft and while working to make a snap for an altcoin, ran into this issue: https://forum.snapcraft.io/t/access-to-specific-hidden-file-path-in-users-home/6948 Is there still no interface to read and write to specified hidden directories?
<brlin> xieta: I posted a workaround, refer to the forum post
<xieta> brlin, okay thanks. Am I reading this right that the user will need to make a hard link for each revision?
<xieta> or will that hard link just get copied into the next revision?
<brlin> xieta: Unless you can redirect the config file to SNAP_DATA_COMMON, you have to prompt user to hardlink it on every refresh
<xieta> Thanks for the work around and response.
<brlin> s/SNAP_DATA_COMMON/SNAP_USER_COMMON/
<xieta> In this case it is more of a whole data directory rather than just a config file.
<brlin> My assumption is the hardlink trick works with directories as well, but not tested
<brlin> ln: .config: hard link not allowed for directory
<brlin> nevermind...
<xieta> I'm not sure if you're familiar with how Bitcoin or other altcoins store their data directory and wallet file, but that's exactly the use case I'm looking at snap for and it seems like snap would be perfect for making just another node to add to the network backbone connectivity -- (because then I don't have to worry about the original hidden directory)
<brlin> For directories you have to use bind mount instead
<xieta>  - you know how there are choices to make with any implementation. Basically in this case its a toss-up between changing the default data directory to not be a hidden directory - or not using snap for financial data applications.
 * xieta is still mulling it over.
<xieta> The guy who asked me to look into snapcraft probably just wants a snap made to grow the network and not necessarily to hold a wallet. So if that's what he tells me as a stakeholder (waiting for his response) then this should be a nifty snap and I won't have to do any tricks with the hidden files or directories.
#snappy 2019-12-02
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga:  hey
<zyga> :-)
<zyga> any crazy purchases?
 * zyga starts the day with reviews
<mborzecki> zyga: nope, not falling for the black friday bs with fake discounts around here
<zyga> mborzecki: I got a real discount, I think
<zyga> mborzecki: got a monitor at 2/3 the price (and I did check regular price as well as manufacturer recommended retail price0
<mborzecki> zyga: what display did you buy?
<zyga> samsung space 27" 144Hz VA 2K panel
<mborzecki> zyga: nice
<pstolowski> morning
<zyga> hey pstolowski
<zyga> pstolowski: do you have that dock already?
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7824#pullrequestreview-324890688
<mup> PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
<pstolowski> zyga: no, should arrive around Wed
<mborzecki> zyga: thanks for the review
<mborzecki> pstolowski: hey
<zyga> Modeenv
<zyga> why not ModeEnv
<zyga> brb
<sdhd-sascha> hi, good morning
 * zyga turned up heating
<zyga> I have 15C in the office now
<mborzecki> zyga: it's late atumn after all
<zyga> and
<zyga> the office has poor insulation :)
<zyga> thinner walls, cold garage below
<zyga> I would love to make it better one day, even if I have to insulate the celling downstairs
<mborzecki> zyga: heh walk() does not follow symlinks, filepath.Walk("/snap/core/current"..), works differently that filepath.Walk("/snap/core/current/")
<zyga> yeah :)
<zyga> but it's just the outer initial symlink that matters to us
<zyga> we don't want to follow symlinks inside, right?
<tomwardill> hi, store team here. Store is currently down, it's being looked at.
 * zyga hugs tomwardill 
<zyga> thank you and good luck
 * tomwardill is mostly drinking coffee and watching people far more competent than I am, but I'll pass the sentiments on :)
<mborzecki> zyga: anyways, refactored to use walk now, before i readdin'ing manually in order to faccessat, since that doesn't work bc of osx, might as well just use walk
<zyga> mborzecki: macos has some innovation in the case of fstat-like functions
<zyga> mborzecki: as well as in the case of "readdir" like functions
<zyga> so the old syscalls are gone now
<zyga> mborzecki: fstat has been replaced by something that is like statx but x10 more complex with lots of extra features and things one can ask about
<zyga> mborzecki: and readdir is more like "search" now
<Chipaca> tomwardill: from here it looked like a lot more than just the store was down :)
<zyga> mborzecki: I think there's still the old readdir but it's deprecated and returns a subset of data now
<tomwardill> Chipaca: PS4.5 is out
<zyga> oouch!
<Chipaca> tomwardill: is the internal irc on that?
<tomwardill> yes
<Chipaca> ah, nice
<tomwardill> or at least, behind the same switch
<Chipaca> ah
<tomwardill> irc has just come back for me btw
<zyga> will PS5 run on a xmas-lot of playstation 5 boxes? :)
<Chipaca> i thought it ran on a 486 unde elmo's desk :-p
<zyga> now powering AI/ML workloads ;)
<zyga> haha
<mborzecki> updated #7824
<mup> PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
<Chipaca> mborzecki: why not do those checks from snap/pack's loadAndValidate?
<Chipaca> mborzecki: as part of ValidateContainer for ex
<Chipaca> mborzecki: that way you still get the error in 'snap pack', but snapcraft gets to warn about it early
<mborzecki> Chipaca: because it may be intentional to have the path set to 0000 or otherwise unreadable by the user
<mborzecki> Chipaca: iirc that code checks that snap own meta and files are accessible
<mborzecki> s/accessible/present/
<zyga> mborzecki: do you want to check the return value of Walk itself?
<mborzecki> zyga: heh, clearly need another coffee
<mborzecki> Chipaca: what i mean is that, current uid being unable to pack the snap doesn't mean it's invalid
<zyga> mborzecki: one more question https://github.com/snapcore/snapd/pull/7824/files#r352494084
<mup> PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
<Chipaca> mborzecki: right
<zyga> Chipaca: that's true but it also means the current uid won't be able to pack it :)
<zyga> and that's worth checking
<zyga> mborzecki: added two comments and resuming other reviews
<zyga> brb
<mborzecki> zyga: i'm all for using a smarted syscall than access, but the only alternative is trying to open that location, checking permission bits is too simple
<zyga> mborzecki: but access is doing just permission check
<zyga> it doesn't do anything else, does it?
<zyga> I guess we could just open and try, that's portable and reliable
<mborzecki> heh, so maybe we should just open
<abeato> morning! we are noticing that some times it takes a lot of time to get a snap installed due to snapd wanting random numbers and the rng not being initialized yet
<abeato> which is the rationale for snapd needing random numbers when installing a snapÂ¿
<abeato> ?
<zyga> abeato: good morning, is this on a vm?
<zyga> abeato: that's unclear, I cannot think of any
<abeato> no, on real HW
<zyga> abeato: we generate some random numbers for snap cookies
<zyga> perhaps that's that
<abeato> on the Jetson Xavier, and on other devices on other prokects
<zyga> is there a hardware random number generator on the xavier?
<zyga> I wonder if it's just snaps that are affected
<zyga> or generally software waiting and waiting
<abeato> there is a trng, yes, but I think that due to a kernel bug the rng gets ~5 minutes to get initialized
<abeato> so, on one hand this is a kernel problem, but on the other hand I do not think it makes much sense that snapd has to block on urandom to be initialized
<abeato> the main issue is that we are seeing this on many deviced, not just one
<zyga> abeato: right, I understand that
<zyga> I think we investigated that once before
<zyga> but it's lots of other parts of the stack that want entrop
<zyga> *entropy
<zyga> and us being super careful won't fix the general "it's stuck" feel
<zyga> I think systemd is in the same boat
<zyga> we don't depend on randomness in an unreasonable way, I think, we could do another analysis to check if anything new was added by accident
<abeato> hm, well, systemd starts, not sure if there is much delay there
<abeato> for FDE you would get things blocked too, sure
<tomwardill> store update: most of the store should be back, SSO is still down
<sdhd-sascha> What is the best way to strace/ltrace or debug an application inside a snap? Sway starts, Xwayland and Xwayland runs xkbcomp... And/Or does a wayland snap need X support ?
<zyga> sdhd-sascha: there's snap run --strace
<zyga> but it's sometimes a little broken
<zyga> and AFAIK we also have snap run --gdb
<zyga> as for Xwayland -- I don't know
<sdhd-sascha> zyga: yes, i saw a file in the source with the name strace. But didn't have the time to inspect ... So it just ask
<sdhd-sascha> Well, sway depends on dmenu for launching application. It's X11.
<sdhd-sascha> Then the most GDK/GTK applications are not compiled with wayland or prefer X11.
<sdhd-sascha> I read on a debian changelog, that there are problems with the clipboard between X11 and wayland. So they prefer to start the application as X, if available.
<sdhd-sascha> Now i wonder, what the usecase of wayland inside a snap is. If kiosk with custom application, then no X11 is needed. But if it's a full desktop, then we need Xwayland support.
<sdhd-sascha> Weston is very nice here. It does not depend on external Xwayland but has similar problems with xkbcomp currently
<zyga> I'm sorry I just don't know enough about the desktop stack to give useful advice
<zyga> https://github.com/snapcore/snapd/pull/7129 needs a second review
<sdhd-sascha> zyga: it's ok. my opinion is, i will make it run. After that i need help to implement some plugs for common GUI-Frameworks
<zyga> it's very old by now
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> more reviews :)
<zyga> r-e-v-i-e-w-s :)
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/7743 ?
<mup> PR #7743: snap-bootstrap: force partition table operations <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
<zyga> sure, just a moment
<zyga> brb
<zyga> reading a longer test
<zyga> I should take a swap day
<zyga> need to burn it
<zyga> before xmas
<zyga> mborzecki: looking now
<zyga> mborzecki: hmm
<zyga> mborzecki: somewhat worried
<zyga> mborzecki: so the thing that we're operating on is mounted, right?
<zyga> because we've booted
<zyga> and now we're changing partitions b
<zyga> are all partitions that we are changing unmounted?
<mborzecki> zyga: afaiu this ties into the uc20 setup process, i'm slightly concerned about it but i suppose it has been thought through
<zyga> I'm concerned and not equally optimistic
<mborzecki> zyga: heh, did you look through the spec?
<zyga> rapidly
<zyga> I should read it again
<zyga> re
<zyga> hey cmatsuoka
<cmatsuoka> zyga: hi
<cmatsuoka> zyga: I'm also reading sfdisk.c
<cmatsuoka> zyga: it seems that we could use --no-reread instead of --force, and read the PT afterwards (which we already do)
<cmatsuoka> zyga: but if we could trigger the partition device node creation in a different way, then this second PT update wouldn't be necessary anymore
<cmatsuoka> zyga: I'm completely for understanding exactly what's happening there because I feel things are a bit out of control there
<zyga> we are in agreement
<cmatsuoka> so one unknown here is: why partx is necessary to trigger node creation for newly created partitions? sfdisk itself and blockdev --rereadpt won't do that
<zyga> cmatsuoka: I'm checking what --force does in practice
<zyga> one thing is is doing is fdisk_device_is_used check gets ignored
<zyga> let's see what that does
<cmatsuoka> zyga: yeah, I'm exactly there now
<zyga> hmm
<zyga> one ioctl :)
<zyga> let's see what that is
<cmatsuoka> zyga: it's a bit disturbing that all those utilities seem to use a certain amount of guesswork ("it seems that the kernel...", "I think this...", "I don't know why, but...")
<zyga> yeah
<zyga> linux plumbing layer is full of traps
<zyga> it's not nice in many ways
<zyga> (not that others are)
<zyga> heh
<zyga> manual pages are silent
<zyga> looking at the kernel
<zyga> that's the only relief
<zyga> at the end of the day
<zyga> you just read and know
<zyga> I'm curious to know what is ABBA deadlock now
<cmatsuoka> humm, I'll verify this, but I'm suspecting the node creation trigger happens with BLKPG but not with BLKRRPART
<zyga> in initramfs what is mounted on /dev?
<cmatsuoka> devtmpfs I guess? not sure
<zyga> do you know what populates it?
<zyga> is it kernel itself or kernel + udev or udev from kernel events?
<cmatsuoka> I don't know. I can check there but I'm not in bootable state right now
<cmatsuoka> But I think we must see that in the new initramfs xnox just built
<cmatsuoka> which may be different compared to the old ones
<cmatsuoka> xnox: you there?
<zyga> reading the kernel
<zyga> I start to see what happens
<cmatsuoka> zyga: the ABBA deadlock happens when two threads get two locks and then they try to get each other's locks
<cmatsuoka> if I remember correctly
<zyga> ah
<zyga> I see
<zyga> I thought it's a weird abba reference
<zyga> it's just A B B A, as in thread names
<zyga> :D
<cmatsuoka> ah yes, threads A and B :D
<cmatsuoka> zyga: hey wait wait, you said --force will skip the BLKRRPART ioctl?
<cmatsuoka> (and then the partition table won't be updated anyway?)
<cmatsuoka> hm, not exactly, but it seems to me that the ioctl() call is always failing and --force is just masking that
<cmatsuoka> that would explain everything except why the ioctl call fails
<zyga> yes
<zyga> force is igoring that
<zyga> the ioctl always runs
<zyga> I'm reading the kernel side to see when it fails
<zyga> (I also have a cold, sorry for the frequent interrupts when I'm away)
<cmatsuoka> so I think it's failing because seed is mounted, and --force just makes it ignore the fact that the ioctl failed
<cmatsuoka> so --no-reread is more appropriate here, it seems
<zyga> what is the error we are getting in sfdisk again
<zyga> oh boy
<cmatsuoka> zyga: this one: https://github.com/karelzak/util-linux/blob/master/disk-utils/sfdisk.c#L1696
<zyga> it's only logged
<zyga> yeah but are we getting EINVAL, E...what?
<cmatsuoka> zyga: I don't know, I'll have to run it again to be sure
<zyga> there's a way to get more output
<zyga> there's a DBG macro
<zyga> just need to figure out how to enable it
<mborzecki> zyga: LIBFDISK_DEBUG=all ?
<zyga> thank you!
<cmatsuoka> ok, building an instrumented image
<zyga> cmatsuoka: this is an interesting page https://unix.stackexchange.com/questions/141476/forced-reread-of-partition-table-difference-between-blkrrpart-and-blkpg-ioctl
<cmatsuoka> zyga: we can check this in the kernel, but maybe BLKRRPART fails when partitions are mounted and BLKPG doesn't?
<zyga> yeah
<zyga> I think so
<cmatsuoka> so partx and possibly partprobe would work while sfdisk and blockdev fail
<cmatsuoka> that would explain everything
<cmatsuoka> zyga: https://pasteboard.co/IJonVQV.png
<zyga> thanks!
<zyga> EBUSY
<cmatsuoka> yep
<zyga> just three places where that is returned
<zyga> looking
<zyga> or just a few
<zyga> cmatsuoka: when we partition the disk, what's the state of the existing partitions
<zyga> cmatsuoka: is the disk largely unpartitioned
<zyga> cmatsuoka: and we append?
<zyga> I read the code and I think the change is "safe"
<cmatsuoka> zyga: we have the system-seed partition there, which is also our boot partition
<zyga> in this sense
<zyga> brb, see you at the standup
<sdhd-sascha> hey, sorry for this "noob" question. But where is the XDG_RUNTIME_DIR set on login ? I grep'ed the whole /etc. Took a look at /etc/pam.d/.
<sdhd-sascha> I wonder why it was set on "ssh" and "ttyX", but not on "sudo su"
<Chipaca> cmatsuoka: https://www.youtube.com/watch?v=ytWz0qVvBZ0
<sdhd-sascha> oh, i think it's inside systemd
<zyga> sdhd-sascha: it's complex
<zyga> sdhd-sascha: it's set by pam AFAIK but I don't know enough to tell you and point to a file where this happens
<cmatsuoka> Chipaca: :D
<sdhd-sascha> zyga: currently i only need to trigger the environment, so i can call "weston-launch" as root
<sdhd-sascha> i could also set it manually..
<sdhd-sascha> zyga: maybe i should look, howto increase the logging level of systemd ;-)
<mborzecki> zyga: cmatsuoka: imo that delay is needed because partitions would show up/go away asynchronously
<zyga> yeah
<zyga> it's an event
<zyga> we could instead look for them on disk
<zyga> that would be less racy
<zyga> if we know we expect /dev/xxx2
<mborzecki> zyga: cmatsuoka: and then udev is another async bit that should get some extra delay if you want to use /dev/disk/by-{name,label,uuid}..
<zyga> Chipaca: https://www.youtube.com/watch?v=dHoCeqlU2g8 (though it's mostly in Polish)
<zyga> but it's fun ;)
<cmatsuoka> mborzecki, zyga: yeah, I remember this node creation race that crashed the kernel back in the spike days
<zyga> Chipaca: skip to 1;30
<zyga> cmatsuoka: https://github.com/snapcore/snapd/pull/7743#issuecomment-560420462
<mup> PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
<cmatsuoka> Chipaca: bah, no Diggy Diggy Hole t-shirts for me
<cmatsuoka> Chipaca: hmm, maybe the 12-14 years size could fit?
<Chipaca> cmatsuoka: the t-shirt link is a 404 from here so count yourself lucky (?)
<cmatsuoka> Chipaca: if you go to the store main page and search from there you'll find a kids size t-shirt
<Chipaca> cmatsuoka: i'm so sorry
 * cmatsuoka sings Down and down into the deep, who knows what we'll find beneath?
 * Chipaca updates cmatsuoka's race card to 'dwarf'
<cmatsuoka> actually there's one in the video that looks a lot like our friend zygmunt
<zyga> cmatsuoka: is my comment sensible?
<zyga> cmatsuoka: note, alternatively --no-reread is okay as well, as it has the equivalent effect
<mborzecki> off to pick up the kids
<cmatsuoka> zyga: I think --no-reread would be a more conservative approach because it has a well-defined meaning and maybe what --force does could change in future versions of the utility. In practice, now, both would have the same effect
<zyga> I agree
<cmatsuoka> Ok, I'll prepare a patch with --no-reread and update the comments
<zyga> Thanks!
<cmatsuoka> thank you zyga for digging into this
<zyga> mborzecki: thanks for looking at --explain,
<zyga> mborzecki: the marker, did you mean to use some kind prefix for each line
<zyga> mborzecki: or something else?
<cmatsuoka> Chipaca: https://www.youtube.com/watch?v=34CZjsEI1yU
 * zyga switches gears to https://github.com/snapcore/snapd/pull/7815
<mup> PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
<zyga> cachio: I pushed a small tweak there
<cachio> zyga, thanks
<cachio> I'll take a look to that PR
<sdhd-sascha> Chipaca: :-D
 * cachio lunch
<Chipaca> cmatsuoka: mucho bettero
<cachio> pstolowski, the hotplug test is failing here https://paste.ubuntu.com/p/VbRsMH3Sjx/
<cachio> pstolowski, not sure it is related to any change
<cachio> done recently
<cachio> but if fails twice and I can reproduce it
 * ijohnson is all caught up on emails/backlog
<pstolowski> cachio: weird, we haven't touched anything there. full log?
<ijohnson> zyga: shall I review https://github.com/snapcore/snapd/pull/7825 ? looks like it's ready for review?
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<cachio> pstolowski, https://paste.ubuntu.com/p/fwm2MhW6bs/
<cachio> pstolowski, the log is huge
<cachio> pstolowski, it appears /dev/ttyUSB0 rwk,
<zyga> dinner is coming up, everyone's home now
<cachio> and we are trying to match "/dev/ttyUSB0 rw,"
<zyga> cachio: I need to read only a small chunk of the diff before finishing my review but it's the most important one
<zyga> I'll finish today for sure
<cachio> zyga, thanks
<pstolowski> cachio: aah, maybe we landed "+k" change, that would explain it
<pstolowski> cachio: we planned to change serial port permissions
<cachio> pstolowski, ahh
<cachio> so  we should update the test in that case right?
<cachio> pstolowski, I can do it after lunch
<cachio> pstolowski, does it make sense?
 * cachio lunch again
<jdstrand> ijohnson: hey, you asked about '... (i.e. seccomp) and non-root owned "/"'
<ijohnson> good morning jdstrand :-)
<ijohnson> yes I did ask about that
<ijohnson> do you want me to re-ask?
<jdstrand> ijohnson: I see the question. you asked if I had time to chat. I didn't then but can now. what is up?>
<ijohnson> ah right sorry I have forgotten what I sent
<ijohnson> let me find the forum page for the full context
<ijohnson> so here someone is trying to use snaps on azure pipelines: https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258
<jdstrand> ijohnson: ok, I am going through irc backscroll first and not caaught up on email yet
<ijohnson> jdstrand: what's weird is that on azure pipelines, "/" is not root-owned, and so snap-confine refuses to run
<ijohnson> jdstrand: and looking through git history it seems that the reason snap-confine does the check for "/" and all elements of the path down to where we have seccomp compiled programs being root owned is to protect against someone putting bad bpf programs there and doing an escalation attack
<ijohnson> jdstrand: so my question is if we can do anything about this case to loosen that requirement or enable some kind of flag to allow running snaps on azure pipelines like this
<jdstrand> ijohnson: I've read the topic and you are right in why we are doing that. we are doing that for security reasons. I can't think of a legitimate reason why / is not owned by root.
<ijohnson> yeah it's weird, but it does seem like a deliberate action, it doesn't seem like something someone would do on accident
<jdstrand> ijohnson: I would like to understand why that is a legitimate use case. usually, there is a coding error somewhere in a maintainer script type thing that accidentally chowns /
<jdstrand> ijohnson: chown vsts $TPYO/
<jdstrand> ijohnson: there have been USNs to fix CVEs in deb packaging for this type of thing
<ijohnson> ah yes I could see that happening
<ijohnson> let me see if I can find a place we could file an issue to get more context from azure
<zyga> jdstrand: it would be so funny if that was the case
<zyga> jdstrand: "Q: can you fix your software not to check / owner"
<zyga> jdstrand: "A: can you apply this patch not to chown / from maintainer script"
<zyga> ;)
<pstolowski> cachio: yes, thank you
<jdstrand> zyga: yeah. well, ufw I think was the first thing to do this checking in Ubuntu anyway, and it found a CVE in hplip :)
<zyga> jdstrand: haha
<zyga> jdstrand: so it *is* good that we ask for root password to install that printer ;)
<pstolowski> cachio: i've just verified, we now have "rwk" on serial port
<jdstrand> zyga: people said: "jdstrand> your check is too strict. please fix". I was like, uhm, why does hplip own /? You realize it can now change anything underneath it, right?
<mborzecki> zyga: i think something like `<< snap explain start >>\n`, `<< snap explain end >>\n` would be enough
<jdstrand> zyga: heh
<zyga> mborzecki: that was not part of the initial design but I'll play with it
<zyga> it's an experiment after all :)
<mborzecki> zyga: iirc kernel has some ------[ cut here ] ------------- markers for backtraces
<zyga> mborzecki: ah, I se
<zyga> it would be just printed twice
<zyga> that's nice
<zyga> I'm semi-afk
<mborzecki> zyga: otherwise my feeling is that the output of the actual app and the one from explain could be easily confused
<zyga> Lucy is roaming around the office
<ijohnson> jdstrand: zyga: well I tried looking and without an azure account the best they can do to talk to us is to ask on the stack exchange :-/
<jdstrand> ijohnson: https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258/13
<jdstrand> ijohnson: I suspect one of the people asking for the change can use that when filing a bug with their azure account
<ijohnson> jdstrand: ack yes that sounds fine, I did also ask on their stack exchange about it fwiw
<jdstrand> cool, thanks
<ijohnson> thanks jdstrand!
 * Chipaca afk
<jdstrand> ogra: thanks for the response re usb drive. I don't mind an sd card and am happy to do that, but it feels more correct to be able to boot off the usb directly. if that requires a blob from someone I don't know though, I prefer the approach you outlined :)
<zyga> re
<cachio> git push
<zyga> git-clippy: where do you want to push today
<pstolowski> :)
<mup> PR snapd#7827 opened: tests: apply change on permissions to serial port on hotplug test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7827>
<pstolowski> +1
<cachio> thanks
<pstolowski> zyga: ^ can you look at it as well, trivial test update
<cachio> I am going to the dentist now
<zyga> yeah
<cachio> I'll be back in 40 minutes
<sergiusens> jdstrand: hey,maybe consider escaping the _ on https://forum.snapcraft.io/t/mpris-name-for-media-player-snap/14371/7
<cachio> pstolowski, I'll try to merge it today
<pstolowski> ijohnson was faster :)
<ijohnson> :-)
<cachio> ijohnson, pstolowski thanks guys
<zyga> pstolowski: what happened that the permissions changed?
<ijohnson> zyga: folks want to lock the serial-port, there are various forum topics about this
<pstolowski> zyga: apparmor (kernel?) change at some point, jdstrand updated serial-port to grant locking permission as it was missing know, was implicit before
 * ijohnson goes to look
<zyga> aha
<pstolowski> s/know/now/
<zyga> kernel side changed or our side changed?
<zyga> the patch looks good , I'm just wondering why it wasn't checked earlier and caused something to fail
<pstolowski> zyga: afair it was an apparmor or kernel bug
<pstolowski> zyga: but not ours
<zyga> pstolowski: but do you know if "our" side has changed?
<zyga> because it is clearly measuring snapd files
<zyga> so it must have come from snapd patch
<zyga> so ... why didn't this change happen in sync then?
<pstolowski> zyga: yes, we added +k to serial.port.go
<ijohnson> see https://forum.snapcraft.io/t/hotplug-doesnt-allow-access-like-a-gadget-slot-does/14090
<zyga> was the test not executed?
<pstolowski> zyga: because this spread test is run only on demand (nested execution)
<zyga> ah
<zyga> that was the thing I was after
<ijohnson> zyga: the PR jdstrand submitted changing the policy is https://github.com/snapcore/snapd/pull/7779
<mup> PR #7779: interfaces: misc updates for u2f-devices, browser-support, hardware-observe, et al <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7779>
<zyga> approved
<zyga> thanks!
<ijohnson> hey zyga, I'm reviewing 7825, and am I right in thinking we have a race condition between when we unlock the lock in genericRefreshCheck() and when we check `if PIDs := knownPids[app.SecurityTag()]; len(PIDs) > 0 {` ?
 * zyga looks
<ijohnson> i.e. a snap process could launch in between those two things and knownPids would miss it
<ijohnson> err s/miss/not contain/
<zyga> https://github.com/snapcore/snapd/pull/7825/files#diff-6eeb1fdef37cbd9f8f731642102858e1R59
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> if I understand your question correctly the answer is "yes" and also "but that's by design"
<mup> PR snapcraft#2823 closed: xattrs: switch to python's os package for reading/writing xattrs <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2823>
<zyga> we don't want to have precise information about which pid is or is not in that group
<zyga> it's not that interesting really
<zyga> we're only interested in the fact that a given security tag had a non-empty list
<ijohnson> zyga: right, I understand we don't really care about individual pids, we just want to know if the set of pids is empty or not. what I'm concerned about is if we unlock that lock after computing the set, a new snap process could launch while we are doing other things in that genericRefreshCheck() function that we wouldn't have allowed to launch if we held the lock longer
<ijohnson> perhaps I'm being confused about which lock is being held there
<zyga> yes, that's entirely possible and correct
<zyga> it's unprotected at this time
<ijohnson> but don't we not want that to happen?
<zyga> there's going to be a new lock that is not a part of this PR
<zyga> it will prevent that from happening
<zyga> but it's not the current lock
<zyga> where the "current" lock can only be held very very briefly
<zyga> the new inhibit lock will actively stall startup and can be held during long operations (e.g. snap refresh downloads)
<ijohnson> okay, if this is a known limitation we plan to resolve later and is effectively not worse than the current behavior then that's fine
<zyga> that's correct, the current behavior is identically weak
<zyga> it's making a point-in-time decision
<ijohnson> it just seemed to me like we are releasing the lock sooner so we are introducing more race conditions
<zyga> but before unlinking
<zyga> so it's effectively still racy
<ijohnson> got it, thanks for clarifying
<ijohnson> and for working on all this, it _feels_ really close this time :-)
<zyga> that's why I included that comment, it's a specific guarantee that we are providing only
<zyga> ha, it's still somewhat distant but definitely better than before
<zyga> the new inhibit lock is in another PR
<zyga> but I need to rebase it on top of this thing as it's still using one of the earlier iterations
<pstolowski> eod, cu
<ijohnson> zyga: ack sounds good
 * zyga needs to reboot
 * zyga-laptop EODs
<zyga-laptop> degville hey
<zyga-laptop> post EOD question
<zyga-laptop> do you happen to know what happened to ubuntu core downloads?
<zyga-laptop> https://ubuntu.com/download/raspberry-pi has just server images
<zyga-laptop> I found https://ubuntu.com/download/raspberry-pi-2-3-core but it's not linked from the download page
<degville> zyga-laptop: hello! no, I don't know what's happened there.
<zyga-laptop> it seems we are advertising classic
<zyga-laptop> and core is on a distinct page that is in a void somewhere
<zyga-laptop> I'm good for now but I just wanted to raise this
<zyga-laptop> I'll make a video about how to install ubuntu core on a pi
<zyga-laptop> and the first step is ... harder than I expected
<degville> mmm... yeah, we're doing a poor comms job. Not sure why, or the motivation behind it.
<degville> The compute docs are Core focused.
<degville> https://ubuntu.com/download/raspberry-pi-compute-module-3
<zyga-laptop> oh well
<zyga-laptop> I'll try to include this in the video
<zyga-laptop> doing a quick note/screenplay thing now
<zyga-laptop> it's pretty weird
<zyga-laptop> if you go to ubuntu.com/download/iot
<zyga-laptop> there's a big green install button
<zyga-laptop> for pi 2 3 or 4
<zyga-laptop> but that's the classic page
<degville> zyga-laptop: yeah, totally agree.
<zyga-laptop> if you scroll below
<degville> Just tried the same.
<zyga-laptop> there's install ubuntu core
<zyga-laptop> but it's a separate set of platforms
<zyga-laptop> I guess I "get it" but it is messy
<degville> zyga-laptop: my guess is not wanting to confuse the majority who may be looking for the Ubuntu-equivalent to Raspbian. But Core images are totally lost along the way.
<zyga-laptop> yeah
<zyga-laptop> I have the same feeling about both
<zyga-laptop> I think we need more of a ...
<zyga-laptop> https://www.opensuse.org
<zyga-laptop> like chooser
<zyga-laptop> it's a really clean page
<degville> yes, you're right.
<zyga-laptop> ijohnson|lunch thank you
<zyga-laptop> I'll iterate tomorrow though, trying to record something tonight
<ijohnson> k, np
<ijohnson> good work on the branch!
<mup> PR snapd#7828 opened: tests: demand silence from check_journalctl_log <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7828>
<mup> PR snapd#7829 opened: tests: fix the channels checks done on nested tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7829>
#snappy 2019-12-03
<mup> PR snapcraft#2828 opened: Appstream <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>
<mup> PR snapd#7827 closed: tests: apply change on permissions to serial port on hotplug test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7827>
<mborzecki> morning
<sdhd-sascha> good morning
<pstolowski> morning
<mborzecki> pstolowski: mvo: morning guys
<mvo> hey mborzecki and pstolowski ! good morning
<mvo> mborzecki: how are you? and what did I miss :) ?
<mborzecki> mvo: nothing special, fri/mon were rather slow
<mvo> mborzecki: *nod* are tests ok ? or do they need investigation?
<mborzecki> mvo: got 2 prs green this morning, so things seem ok
<mvo> mborzecki: \o/
<mvo> mborzecki: great! anything I can help with right away? otherwise I will just do the usual mail+check prs
<mborzecki> mvo: yday there were some concerns about https://github.com/snapcore/snapd/pull/7743 regarding having a partition from the block device mounted at the time of bootstrapping
<mup> PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
 * mvo looks
<mvo> mborzecki: woah, nice find in 7824
<mvo> mborzecki: do you happen to know if there is an upstream bugreport for mksquashfs? it sounds like worth asking for a "-strict" (or whatever) switch that would actually error in situations like this (it's hard for me to imagine when it's useful to *not* error by default)
<zyga> good morning
<mvo> mborzecki: anyway not super important, just an idle thought
<mvo> zyga: good morning!
<zyga> :)
<zyga> mvo: yeah, thinks seem calm, just reviews and iteration
<mborzecki> zyga: hey
<mvo> zyga: how are you? jetlag better?
<mborzecki> mvo: didn't check
 * mvo was super tired this morning but otherwise feeling good
<zyga> mvo: yeah :-) It's all over finally :)
 * mvo just gets more tea and everything will be back to normal :)
<mvo> zyga: yay!
<zyga> mvo: I tried to record my first ubuntu core video
<mvo> zyga: I read somewhere it take ~1day per hour timezone difference
<zyga> mvo: more attempts today, it's a lot of work :D
<mvo> zyga: that's so cool!
<mvo> mborzecki: also - holly cow - 7821!
<mvo> mborzecki: pretty impressive numbers
<mup> PR snapd#7822 closed: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7822>
 * mvo hugs mborzecki 
<mup> PR snapd#7820 closed: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820>
<pedronis> mvo: hi, a post-merge remark on #7820
<mup> PR #7820: boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7820>
<mvo> pedronis: thank you, on it
<mvo> pedronis: uh, sorry, indeed, will fix right away
<mvo> pedronis: I added a comment to 7823 (which is also shorter now that bits from master are merged)
<pedronis> mvo: ok,  what should I review next?
<pedronis> I mean for UC20
<mvo> pedronis: 7823 would be nice, then I want to ponder about 7762, my gut feeling is that some of the partition finding could/should move to snap-bootstrap
<mvo> pedronis: and then I want to update 7817 based on your feedback
<mvo> pedronis: I hope this sounds sensible
<pedronis> mvo: fwiw I had the same wondering at some point, about the partition finding
<mvo> pedronis: in 7762 ?
<pedronis> yes
 * mvo nods and will have a look
<mborzecki> hm master unit tests broken?
<zyga> mborzecki: oh?
<mborzecki> must be the devicemgr PR that landed
<mborzecki> https://paste.ubuntu.com/p/sdjF7VJbfC/
<zyga> indeed
<zyga> mborzecki: are you pushing or shall I?
<zyga> or better yet
<zyga> mvo:  can you push a trivial directly to master/
<zyga> https://www.irccloud.com/pastebin/PZj3DJ9C/
<zyga> mvo: will save us an hour
<mborzecki> hahah
<zyga> I'll open a PR just in case
<zyga> all this CI
<zyga> ...
<mvo> zyga: can do
<zyga> mvo: thanks
<mvo> zyga: should be fine now
 * zyga thanks :)
<mborzecki> pedronis: hi, i've updated #7821
<mup> PR #7821: [RFC] interfaces/seccomp: parallelize seccomp backend setup <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<pedronis> mborzecki: thanks, queued
 * zyga has some food poisoning this morning
<mborzecki> pedronis: cool, thanks
<zyga> if I'm not responsive, that's why :/
<mup> PR snapd#7824 closed: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
<mup> PR snapd#7830 opened: Include hooks in plug/slot apparmor label <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<niemeyer> Hellos
<niemeyer> mvo: ping
<mvo> hey niemeyer
<niemeyer> mvo: Heya
<niemeyer> mvo: Do you have a moment for a call?
<niemeyer> mvo: I'm setting up mup and was going to ask about it, but actually it would be nice to have a quick sync call if you have a few spare minutes
<mvo> niemeyer: yes, sure!
<niemeyer> mvo: Nice, let me grab a cup of coffee quickly and will drop you a link
<pstolowski> mborzecki: i think Sergio addressed your comments to https://github.com/snapcore/snapd/pull/7815 ; can we land it?
<mup> PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
<mup> PR snapd#7815 closed: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7815>
<pstolowski> ty!
<zyga> mborzecki: hey
<zyga> mborzecki: I moved the code we talked about to sandbox/cgroup
<zyga> mborzecki: shall I push that to https://github.com/snapcore/snapd/pull/7825 ?
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pstolowski> Chipaca: hey, question to you on https://bugs.launchpad.net/snapd/+bug/1838786
<mup> Bug #1838786: Categories not returned in /v2/find results <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1838786>
<Chipaca> pstolowski: yep, tks
<pstolowski> Chipaca: i might have asked about it during my last triage duty ;)
<pstolowski> if you update it, i'll stop asking ;)
<Chipaca> pstolowski: i mean, there isn't a status for "started, will be completed, but not being worked on right now"
<pstolowski> true, np, just comment on it
<zyga> mborzecki: updated
 * zyga returns to garden next branch in a moment
<zyga> re
<zyga> 15C in the office
<zyga> no wonder I have a cold
<mborzecki> zyga: you should really get a heater or sth
<mborzecki> quick errand, back in 20
<xnox> zyga:  i was off on monday. Reading backscross with cmatsuoka, in the initrd /dev is populated by multiple things: a) devtmpfs (ie. kernel itself) b) processing /lib/modules/{kver}/modules.devname by systemd-tmpfiles c) anything else statically created
<zyga> xnox: aha
<zyga> xnox: do you know what's the relationship between devtmpfs and in-kerenl kobj events
<zyga> xnox: I can point you to specific lines in the kerenl
<zyga> xnox: for instance when the block device layer drops and re-creates partitions
<zyga> xnox: is that automatically reflected in devtmpfs?
<zyga> mborzecki: the heater is on now
<xnox> zyga:  no, and why should it be?
<zyga> pstolowski: small suggestion for the label expr branch
<zyga> xnox: I'm not yet sure about "should" vs "not should" - just trying to piece together my undersstanding
<zyga> xnox: when the ioctl to rescan partition table is issued
<xnox> kernel needs to be told to reload the partitions...... i.e. using kpartx, blockdev, etc.
<zyga> xnox: the kernel removes and re-creates partition nodes
<zyga> xnox: when this happens the kernel side is updated
<zyga> xnox: but what about the filesystem?
<zyga> xnox: I'm trying to understand what updates /dev/ itself
<zyga> xnox: is that some minimal udev running in initrd or is that directly done by the kernel
<xnox> kernel udev events are emitted, which udev processes, and does changes to.
<xnox> not minimal, but full-fat udevd.
<zyga> ah, so there is real udev there?
<zyga> ah
<xnox> in all of our initrds.....
<zyga> ok, that explains everything I was wondering about
<zyga> cool, thank you
<xnox> but it may have different set of udev rules & helpers (i.e. raid/lvm/cryptsetup/dm-setup might be missing)
<zyga> xnox: if you are interested in the backstory
<xnox> or even versions
<zyga> xnox: there was some discussion about this specific part:
<xnox> for example, old initrd may have older systemd, and thus initrd symlinks/names might be different to the "booted" system.
<zyga> https://github.com/snapcore/snapd/pull/7743
<mup> PR #7743: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7743>
<zyga> xnox: that's interesting
<zyga> xnox: (when I say interesting, I mean, how are we going to handle that)
<zyga> pstolowski: your patch looks good, I suspect the failure shows something that is broken but was dormant before
<pstolowski> zyga: i don't know, it's super weird.. opening { is missing, closing } is there. i don't see how this is possible
<zyga> pstolowski: can you paste the line please
<mborzecki> re
<zyga> mborzecki: 18C now
<zyga> mborzecki: +4 outside
<mborzecki> zyga: showing 2C outside here, though it's sunny yay
<ppd1990> Hi. Is there anyone here I can poke for a transfer request? My forum request is getting a little stale ;-) (https://forum.snapcraft.io/t/please-transfer-solvespace-to-solvespace-account/14342)
<pstolowski> zyga: peer=(label="snap.core.}"),
<zyga> ha
<zyga> I ... know
<zyga> pstolowski: do you see it?
<zyga> https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR66
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<zyga> it must only truncate if len(names) > 0
<zyga> pstolowski: add a test for that please
<zyga> pstolowski: in addition https://github.com/snapcore/snapd/pull/7830/files#diff-939866a2238749d2c6989a8a757f430fR45 may need to be dropped
<zyga> and instead the name collection may have to move earlier
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<zyga> pstolowski: so that the same if one {  } else if zero else { } flow can remain
<pstolowski> zyga: ha, thanks for spotting
<pstolowski> ok, i think i got it simplified, running the tests.. short break, going to collect my usb hub from post office
<zyga> pstolowski: cool, good luck!
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7825 again
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> mborzecki: I'll find those tests I wrote for some of the TODOs there
<mborzecki> ok
<zyga> mborzecki: but I did some structural changes you asked for
<pedronis> mvo: #7823 looks fine afaict
<mup> PR #7823: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823>
<pstolowski> zyga: is label="snap.core." same as label="snap.core.*" ?
<zyga> pstolowski: no, it is not
<pstolowski> zyga: is "snap.core." matching anything?
<zyga> only the label "snap.core."
<zyga> which nothing in our system will have
<pstolowski> zyga: good
<pstolowski> zyga: one more twist in that PR
<pstolowski> (not pushed yet)
<mup> PR snapd#7829 closed: tests: fix the channels checks done on nested tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7829>
<jdstrand> pedronis: hey, amurray asked you to respond to https://forum.snapcraft.io/t/system-files-under-mozilla-native-messaging-hosts
<jdstrand> pedronis: but per our conversation in Vancouver, I will
<pedronis> jdstrand: thx
<pedronis> jdstrand: #7768 needs a unit test fix
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<jdstrand> pedronis: yep, hoping to get to that today. thanks
<pedronis> zyga: jdstrand asked you to (re)review #7228
<zyga> ack, will do
<mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
<mborzecki> cmatsuoka: you broke github ;) just got an email with '@cmatsuoka pushed 0 commits.'
<roadmr> hmm... push --overwrite with an unchanged branch?
<roadmr> er --force (sorry, too much bzr)
<pedronis> pstolowski: let me know if we should have a chat about services tomorrow or later in the week
<cmatsuoka> I'm pushing 0 commits all the time
<zyga> brb, lunch
<cmatsuoka> But yeah, I don't know what happened there, I'll check
<mup> PR snapd#7831 opened: [RFC] gadget: extract and export new DiskFromPartition() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/7831>
<pstolowski> pedronis: ok, thanks, will think a bit more and maybe tomorrow
<mup> PR snapd#7832 opened: [RFC] snap-bootstrap: support auto-detect device in create-partitions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
<pedronis> mvo: what's the relation of 7831 and 7832, does one need the other or are they exclusive?
<mvo> pedronis: I think we want something like 7831 in any case, i.e. have just a single way to find a parent-disk from a partition
<pedronis> ok
<mvo> pedronis: with 7832 it goes one step further and move the business of finding that disk from devicemanager into the low-level of snap-boostrrap
<mvo> pedronis: my feeling is that devceimanager is too high level for dealing with the low-level bits that are currently done there in 7762. but I could be wrong and this is why I want a second opinion :) and code seems to be the easiest way to express the question
<mborzecki> cmatsuoka: mvo: for uc20, is the ubuntu-seed partition encrypted?
<pedronis> mborzecki: no
<pedronis> only -data and -save will be
<mborzecki> pedronis: thx
<mup> PR snapcraft#2817 closed: snapcraft/plugins: Add gomod plugin <Created by mhilton> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2817>
<mup> PR snapd#7833 opened: HACKING.md: add nvidia options to configure example <Documentation> <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7833>
<ijohnson> degville: when you get a chance could you quick take a look at ^
<ijohnson> also I created a new tag for PR's in snapd called "Documentation", I don't think we'll have many such PR's but seems nice to have
<degville> ijohnson: will do - thank you!
<cachio> mborzecki, hey, when you have few minutes could you please give a second round to #7826
<mup> PR #7826: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>
 * cachio lunch
<pedronis> mvo: the approach in #7832 looks reasonable
<mup> PR #7832: [RFC] snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
<mvo> pedronis: \o/
<mvo> pedronis: thanks for the feedback
<pedronis> Chipaca: #7771 will need a re-review
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<pedronis> but I asked for some changes
<Chipaca> yep yep
<pedronis> still
<Chipaca> this thing might be interesting for a few of us: http://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-of-software.html
<zyga> back from lunch
<zyga> but need to take a break now
<zyga> back in 2 hours to wrap up the day
<zyga> Chipaca: I looked at that
<zyga> Chipaca: it's really true in many ways
<zyga> changes what needs to be done as a kernel patch
 * Chipaca afk
<mup> PR snapd#7834 opened: tests: move the watchdog timeout to 2s to make the tests work in rpi <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7834>
<zyga> re
 * zyga was sleeping 
<zyga> back to work
<zyga> with some tea to help
 * Chipaca soft-EODs 
<cmatsuoka> signal(SIGEOD, SIG_IGN)
 * Chipaca feels ignored, now
 * Chipaca might get used to this
 * zyga hugs Chipaca 
<zyga> I just discovered mold behind a whiteboard
<zyga> "yay"
<mup> PR snapcraft#2829 opened: store cli: push title and license on push-metadata <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829>
<jdstrand> noise][: hey, who would I talk to these days about the snap-store-proxy?
<jdstrand> noise][: I see bloodearnest uploaded it last
<jdstrand> bloodearnest: hey, curious why the snap-store-proxy is only available on amd64. I was going to try to configure it locally for an armhf device but can't...
<roadmr> jdstrand: we just haven't built for other arches because who would want to host a store-proxy on a raspberry pi :)
<roadmr> jdstrand: (I think - there may be a real reason behind it but the truth is the main audience would be enterprises which are more likely to host a beefy org-wide proxy on a big amd64 box)
<jdstrand> roadmr: well, I was literally trying to do that. I wanted to use uc18 on an rpi3 on an hd. I figured the the proxy itself would not be resource intensive and just needs disk, which is easy enough to do
<noise][> jdstrand: i think there was a reason â¦ maybe one of the components we are using wasn't readily available on arm, but we'd have to have someone go poke at it again
<roadmr> jdstrand: well it does need a postgres database
<jdstrand> roadmr: personally, I do quite a bit of dev with quite a few devices and was getting tired of always reaching out to the store with refreshes, etc, etc
<jdstrand> roadmr: it is already installed :)
<roadmr> jdstrand: the rpi is probably 10x more powerful than the first server I set up a pg database on, so that should be covered, but it does sound odd to have that on a pi :)
<jdstrand> roadmr: snap install postgresql10
<roadmr> \o/
<jdstrand> roadmr: it is literally begging to be used right now :)
<roadmr> hehe
 * cachio afk
<jdstrand> I guess I am begging for it to be used too...
<jdstrand> :)
<jdstrand> roadmr: fyi, loadavg is nearly all 0s with 444M of ram free with pg running... figured this would actually be a nice use of the pi...
<jdstrand> anyhoo, curious on the outcome of that
<roadmr> jdstrand: I'll check with twom and bloodearnest tomorrow to see what the reason was
<jdstrand> roadmr: thanks!
<mup> PR snapd#7828 closed: tests: demand silence from check_journalctl_log <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7828>
<bloodearnest> jdstrand: o/ it's just a matter of doing the work to support it - we have go services built, so if that can build for armhf, we should be able to. There's also a horrible LD_PRELOAD shim (due to https://forum.snapcraft.io/t/seccomp-filtering-for-setgroups/2109/10) that we'd need to build for armhf too, but it should be doable.
<bloodearnest> everything else is python and archive packages
<jdstrand> bloodearnest: well, we build a lot with go on arm, so that is hopefully not a problem. there is https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c that should work with setgroups
<jdstrand> bloodearnest: as documented in https://forum.snapcraft.io/t/system-usernames/13386
<jdstrand> bloodearnest: so, if this is something that you're interested in, you have a tester and a user :)
<bloodearnest> jdstrand: thanks. I don't have an armhf device handy, but I'll add a trello card for it
<jdstrand> bloodearnest: while I have you, I was a little surprised that snap-store-proxy didn't ship its own pg. I mean, I understand that snap-store-proxy might want to use an external pg, but also seemed like it might be nice to not be required to
<jdstrand> bloodearnest: I think that is what the maas snap is doing (though I'm not sure)
<jdstrand> bloodearnest: anyhoo, thanks!
<bloodearnest> jdstrand: we want'd do, but postgresql has a hard coded if (uid != 0) { error() } type check. So we'd have to patch it and build our own to run it.
<bloodearnest> Unless running as non-uid-zero users in a service are now a thing, and I missed that?
<jdstrand> bloodearnest: it is now a thing: https://forum.snapcraft.io/t/system-usernames/13386
<bloodearnest> jdstrand: well, hello there, that is nice. Ok, we might add that now :)
<jdstrand> bloodearnest: you don't have the nicety of User=/Group= in the systemd unit yet, but you can solve that with a wrapper
<bloodearnest> jdstrand: so the wrapper needs to su?
<jdstrand> bloodearnest: I was actually wondering if maybe you wanted to run the proxy as snap_daemon, but didn't want to push my luck since you were so nice with the armhf question :)
<bloodearnest> jdstrand: I totally would prefer to run all the services as snap_daemon, including a bundled pg. Does setgroups for snap_daemons gid work?
<bloodearnest> I'll add some bugs to track these I think.
<jdstrand> bloodearnest: I was thinking a C wrapper. su is allowed in the policy currently. runuser might work. let me try real quick
<bloodearnest> we already wrap our servcies in a bash exec launcher, for various reasons, so su would be simpler
<jdstrand> bloodearnest: setgroups still needs to use '0, NULL' as mentioned in the forum, but setgid and setuid and the whole family (setreuid, setresuid, etc) all work
<jdstrand> err, su isn't* allowed in the policy currently. that won't work come to think of it cause of pam
<bloodearnest> ah, yeah
<bloodearnest> hmm
<jdstrand> but let me try something with runuser
 * jdstrand plays for a minute
<jdstrand> bloodearnest: ok, so like su, runuser needs pam so no go. however, start-stop-daemon from dpkg can be used with an LD_PRELOAD. so I updated https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/lib.c to also handle initgroups and then can do: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./start-stop-daemon --pidfile /dev/null --start --chuid snap_daemon --group snap_daemon --startas /bin/sh -- -c "sleep 300"
<jdstrand> bloodearnest: that was within 'sudo snap run --shell test-snapd-daemon-user.drop' and cd'd into SNAP_COMMON and copied the wraplib.so and start-stop-daemon there
<bloodearnest> jdstrand: thanks. That is more complex than I'd like - is User=/Group= support in systemd unit file on the roadmap?
<jdstrand> bloodearnest: it isn't 'pretty', but if you are already compiling an LD_PRELOAD (which it sounds like you are), you need only stage-packages dpkg. that said, if you are already compiling an LD_PRELOAD, you could modify drop.c from that same branch
<bloodearnest> jdstrand: right, we're just using the LD_PRELOAD for nginx, we run about 6 python services and a golang one too.
<jdstrand> bloodearnest: isn't on the 'committed to do it for 20.04' roadmap, but it is queued in trello for whenever I can squeeze it in
<bloodearnest> jdstrand: ack, thanks
<jdstrand> bloodearnest: since you are doing it for nginx, you could set 'environment' in the snapcraft.yaml for anything that uses initgroups
<jdstrand> I could write a 'runas' binary in that tree
<ijohnson> bloodearnest, I made a postgres snap with snap_daemon
<jdstrand> ijohnson: what did you do to drop?
<jdstrand> ijohnson: and what is the name of that snap? I'd like to use yours instead of the one I have
<jdstrand> :)
<ijohnson> bloodearnest: jdstrand: https://github.com/anonymouse64/postgres-snap
<bloodearnest>  jdstrand: re environment in snapcraft.yaml, can they now expand $SNAP{_DATA,_COMMON} and such in their value?
<ijohnson> I used https://github.com/tianon/gosu.git to drop privileges
<ijohnson> jdstrand: ^
<bloodearnest> ijohnson: oh, nice, will take a look
<ijohnson> jdstrand: although I don't remember I put it in the store or not, I didn't want to mess with the pre-existing postgres snaps and didn't have the time to engage with upstream
<ijohnson> bloodearnest: the other tricky thing I ran into is auto-setting up a db that the other service used, cause you need to run various commands on install, but you want them to be run as snap_damon user
<jdstrand> oh, setpriv
 * jdstrand looks at that
<ijohnson> a full example of using postgres as a service with something else that actually uses postgres is my kong snap: https://github.com/anonymouse64/kong-snap
<bloodearnest> ijohnson: this is all useful info, looks like you've solved some tough problems there, which we can reuse - thanks!
<ijohnson> bloodearnest: happy to see my work used :-)
<bloodearnest> ijohnson:  what are your thoughts around SNAP_DATA vs SNAP_COMMON for the db files?  Having it in SNAP_DATA makes refresh a) slow and b) potentially irreversable w/o dataloss (if data was written to the new revisions $SNAP_DATA)
<ijohnson> bloodearnest: hmm I guess I typically like to keep data in $SNAP_DATA so you can revert safely, I guess I'm not usually concerned with losing data on a revert, since almost all the times I've seen reverts is when something fails right after upgrading and so there's either no data or almost no data
<ijohnson> if keeping all the data all the time is important then you probably need to use $SNAP_COMMON, and make sure you use epochs carefully to ensure that if the version of postgres changes or otherwise your db is incompatible with a future revision that you will step through snap revisions that can migrate back and forth safely
 * ijohnson steps out for a minute
<jdstrand> bloodearnest: ok, setpriv from util-linux works almost perfectly for this: LD_PRELOAD=$SNAP_COMMON/wraplib.so ./setpriv --clear-groups --reuid snap_daemon --regid snap_daemon -- sleep 300
<bloodearnest> ijohnson: yep, it's tricky. I'd probably lean towards using tracks and an explicit copy/migrate step, rather than epochs. Firstly, because that's closer to typical production DB upgrades, and b) epochs are really quite hard to reason about.
<bloodearnest> jdstrand: oh, that's much nicer
<jdstrand> bloodearnest: --clear-groups uses setgroups in the portable manner, not the snapd required manner, hence the preload
<jdstrand> bloodearnest: you can use --keep-groups and forego the preload, but, well, you have 0 in your list
 * jdstrand documents setpriv in the forum
<jdstrand> bloodearnest: ok, maybe between snap_daemon I did last cycle and the exploration, that is enough to consider the armhf build ;)
<jdstrand> bloodearnest: seriously though, lemme know if you have issues with snap_daemon. I'd really like to add User=/Group= this cycle, but it won't be til late in the cycle
<ijohnson> jdstrand: any thoughts on putting that wraplib.so inside snapcraft-preload?
<bloodearnest> sjdstrand: right. FTR, the reason we still need LD_PRELOAD, AIUI, is that glib's initgroups (which is called by nginx) will *always* call setgroups with n>0 and a non-NULL pointer, and thus trip SECOMP up.
<bloodearnest> jdstrand: I'll try see if we can schedule this,  but snap-proxy work is fairly low in the the list for next cycle
<jdstrand> bloodearnest: sure, I understand
<jdstrand> ijohnson: have had thoughts on that
<jdstrand> :)
<jdstrand> ijohnson: https://git.launchpad.net/~jdstrand/+git/test-setgroups/tree/snapcraft.yaml does show how to do this rather easily as well
<jdstrand> (which is documented in https://forum.snapcraft.io/t/system-usernames/13386, but not a reason for it not to be in snapcraft-preload)
<bloodearnest> jdstrand: FYI https://bugs.launchpad.net/snapstore-snap/+bug/1855005, https://bugs.launchpad.net/snapstore-snap/+bug/1855007, https://bugs.launchpad.net/snapstore-snap/+bug/1855008
<ijohnson> jdstrand: yes that's simple enough, but we already end up needing to use snapcraft-preload for postgres anyways so having this in snapcraft-preload is one less thing to track and build
<jdstrand> bloodearnest: thanks!
<jdstrand> ijohnson: yeah. I think serguisens mentioned he was going to make it easier to contribute to
<jdstrand> (snapcraft-preload)
<ijohnson> great, that would be cool :-)
<jdstrand> ijohnson: oh, I meant to say, really nice caching forum topic
#snappy 2019-12-04
<ijohnson> jdstrand: thanks!
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> and back, 5.4.1
<mup> PR snapd#7834 closed: tests: move the watchdog timeout to 2s to make the tests work in rpi <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7834>
<mup> PR snapd#7833 closed: HACKING.md: add nvidia options to configure example <Documentation> <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7833>
<mborzecki> not sure what the purpose of tests/main/install-store-laaaarge is
<mup> PR snapd#7743 closed: snap-bootstrap: force partition table operations <UC20> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7743>
<zyga> mborzecki: that we donât buffer snaps in memory perhaps?
<zyga> Good morning
<zyga> Still sleepy
<zyga> Fought mould in the office late las night
<mborzecki> zyga: ayy, not good, make sure to remove all of it
<zyga> good morning mvo
<mvo> hey zyga
<mborzecki> mvo: hey
<mvo> mborzecki: good morning!
<mborzecki> ok, off to the bank, back ~12 hopefully
 * zyga jumps into https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pstolowski> morning
<sdhd-sascha> Hello,
<zyga> hey
<sdhd-sascha> :-)
<sdhd-sascha> on 19.04, when i run the test-suit, i get:
<zyga> so, snap run --explain, there's a small twist in I/O sync across all the interacting programs
<sdhd-sascha> -               {"", time.Time{}},                           // zero time default
<sdhd-sascha> +               {"", time.Time{}}, // zero time default
<zyga> need to think how to make that all work cleanly
<sdhd-sascha> in the formattting test
<zyga> sdhd-sascha: ignore it, it's busted
<zyga> sdhd-sascha: we format with a fixed gofmt version
<zyga> sdhd-sascha: unless you happen to have that it will always differ
<sdhd-sascha> well, on 18.04 it works and go's on...
<sdhd-sascha> is there a workaround
<zyga> format with that version
<sdhd-sascha> On 18.04, it ./run-checks stops, with  "Crushing failure and despair."
<zyga> you can install it as a snap :)
<zyga> yeah, it's silly
<zyga> mvo: ^
<sdhd-sascha> i installed go as snap
<Chipaca> sdhd-sascha: just run the unit tests? ./run-checks --unit
<sdhd-sascha> :-) i will
<sdhd-sascha> What gofmt version i should install ?
<zyga> brb, I'm starving
<Chipaca> sdhd-sascha: try SKIP_GOFMT=1 ./run-checks
<Chipaca> sdhd-sascha: i think it's the gofmt from go 1.10 but i might be wrong on this
<Chipaca> sdhd-sascha: if you're running go from a snap, snap refresh --channel=1.10 go
<sdhd-sascha> Chipaca: SKIP_GOFMT works. I need this, because in the night i have to shutdown my noisy server ;-) thanks
<Chipaca> noisy stuff in the home needs to die
<sdhd-sascha> Chipaca: right
<pedronis> mvo: what UC20 bits need reviewing?
<sdhd-sascha> What is best pratice? Build and install master branch? Is master mostly compatible with snapcraft store, or test this seperatly ?
<zyga> sdhd-sascha: master is compatible with the store
<zyga> sdhd-sascha: we take backwards compatibility seriously
 * zyga breaks branch iteration to review stuff for 2.34
<zyga> 43 even
<mvo> pedronis: 7831 should be ready, 7832 too, I'm just adding a spread test
<pedronis> mvo: 7831 has two +1
<mup> PR snapd#7831 closed: gadget: extract and export new DiskFromPartition() helper <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7831>
<mvo> pedronis: thanks, merged and I updated 7832 against master plus it has a spread test now
<mvo> pedronis: that should unblock 7762 :)
<zyga> pedronis: reviewed https://github.com/snapcore/snapd/pull/7228#pullrequestreview-326719099
<mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
<zyga> pstolowski: about your work on the label bug
<zyga> pstolowski: do you think we can chop it into parts so that the several bugs this uncovered can be addressed in isolation
<pedronis> mvo: it's Ubuntu Core not Ubuntucore, so UC not Uc
<pstolowski> zyga: i think so yes, nb i think i see the issue, just trying a tentative fix
<zyga> oh, while are are at naming, why do we have Grubenv and not GrubEnv
<zyga> it's rubbing salt into my eyes
<mvo> pedronis: thank you, I keep this in mind
<zyga> pstolowski: super, thank you for taking this
<pedronis> mvo: thanks, not the most important thing in the world but well
<mvo> pedronis: yeah, we should be consistent!
<pedronis> mvo: is that right that cmd/snap-bootstrap/bootstrap is mostly tested via spread?
<zyga> they are shooting an episode next door again
<zyga> mvo: https://github.com/snapcore/snapd/pull/7832#pullrequestreview-326757177
<mup> PR #7832: snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7832>
<mvo> zyga: thank you, looking
<mvo> (was in a meeting)
<zyga> no worries
<pstolowski> zyga: ok, wrt to the label issue.. another problem confirmed and fix works, it's implicit stuff biting again
<pstolowski> zyga: we bind implicit hooks when reading the yaml, but implicit slots arrive later to the picture :/
<pstolowski> we should probably tear all that apart and redo at some point, but this needs a good plan
<zyga> pstolowski: as expected the, no disagreement there
<zyga> short coffee break
<zyga> it's not so cold today somehow
<zyga> back
<mup> PR snapd#7835 opened: gadget: add missing test for duplicate detection of roles <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7835>
<cachio> mvo, hey
<mvo> hey cachio
<cachio> did you fix the test uc20-snap-recovery ?
<cachio> in the last PR merged?
<cachio> mvo, I see the tests passed during last execution on travis
<cachio> but I see it is failing on master when I execute it
<mup> PR snapd#7836 opened: o/ifacestate: fix binding of implicit hooks to implicit slots on core snap <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7836>
<pstolowski> zyga: ^
<zyga> nnn
<mvo> cachio: it seems racy
<mvo> cachio: it's strange, I wonder what broke it
<mvo> cachio: do you know when it started failing?
<cachio> mvo, yesterday the bionic image was updated
<cachio> perhaps something new is breaking it
<cachio> I ran the tests yesterday for the new image and that test passed
<mvo> cachio: there are also changes in the sfdisk code
<mvo> cachio: 7743 landed
<mvo> cachio: and after that I see an error on master and I also seen an error in my own stuff - but not in qemu so far (but only ran twice). runing on google now
<cachio> mvo, nice
<mvo> looks like we also need to improve the error, i.e. what exactly is not compatible
<cachio> mvo, hehe, I'll try to reproduce the error using the previous image
<cachio> so if I'm able to do it the problem should be in the code
 * Chipaca needs to lie down for a while
<zyga> pstolowski: reviewed
<pstolowski> zyga: thank you; please also see my comment under 1st PR
<zyga> ack
<mvo> cachio: thanks!
<pstolowski> zyga: as touched briefly yesterday, remaining 3rd issue is peer=snap.core.configure now generated for e.g. modem-manager plug on classic
<sdhd-sascha> hey, can i ask a off-topic question? i want to forward a unix-domain socket via ssh & netcat. With "ssh <host> -- nc -q0 -U </path/to/socket>" i got a connection.
<sdhd-sascha> But now my application needs a socket-filename
<sdhd-sascha> i want with emacsclient securly connect to server (tramp plugin didn't work like expected...)
<sdhd-sascha> :-)
<pedronis> pstolowski: do we really need to bind hooks fore core, given that the only hook there is hijacked anyway?
<mvo> cmatsuoka: hey, good morning
<pedronis> pstolowski: I'm basically wondering whether we can cut/simplify somehow differently this area
<cachio> mvo, the test fails with the old image as well
<mvo> cmatsuoka: "fun" - right now master is unhappy, it looks like 7743 sometimes works and sometimes does not.
<mvo> cmatsuoka: it looks like adding "blockdev --rereadpt" fixes it
<mvo> cmatsuoka: well, "fixes"
<mvo> cmatsuoka: I wonder if we need our own code afterall :/
<pstolowski> pedronis: if we don't then label generation would need some other logic / special casing for core i think (for the reference - #7830)
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<cmatsuoka> mvo: is it failing on the gadget vs device  consistency checking?
<pedronis> pstolowski: I would like us to explore that
<pedronis> pstolowski: it's a bit silly to generate profiles for something we never run
<pedronis> core is anyway special cases in various ways
<pedronis> but I might be missing something
<mup> PR snapd#7837 opened: devicestate: implement creating partitions in "install" mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7837>
<mvo> cmatsuoka: yeah
<mvo> cmatsuoka: exactly the issue you describe in the gdoc
<mvo> cmatsuoka: seems to break master right now :(
<mvo> cmatsuoka: do you think you could try just adding "blockdev --rereadpt" as a workaround?
<mvo> cmatsuoka: need to get lunch in a wee bit but would love to have someone look at this while I'm away :)
<cmatsuoka> mvo: yes, at which point you tried this rereadpt?
<cmatsuoka> mvo: the error pattern is very odd, last night I couldn't reproduce it anymore after ~10PM UTC
<pstolowski> pedronis: okay, i need to take a step back, and clear my mind. but lunch first
<mvo> cmatsuoka: fun! I can reproduce it in gce
<pedronis> pstolowski: ok, we ignored the silly work because it didn't have consequences so far, but if it starts to give trouble we need to consider
<mvo> cmatsuoka: but not in qemu
<mvo> cmatsuoka: I see it in my PR everytime in gce and also when running manually I hit it right away
<mvo> cmatsuoka: I did run "blockdev --rereadpt" after the failure manually i nthe shell and suddently things went away
<mvo> cmatsuoka: thanks for looking into this, if you have further question please use tg, I will go to lunch now
<mvo> cmatsuoka: but happy to help as good as I can
<cmatsuoka> mvo: where did you insert the blockdev that fixes the problem? (I'm afraid it's more like it's disturbing the system enough to make a racy situation work again)
<mvo> cmatsuoka: after the test failed I just ran it manually in a shelll
<mvo> cmatsuoka: which is obviously not that great of an answer
 * mvo really is away now
 * cmatsuoka earns the "breaking master" badge ð±
<mup> PR snapcraft#2829 closed: store cli: push title and license on push-metadata <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2829>
<mup> PR snapd#7838 opened: cmd/snap-bootstrap: stub out snap.SanitizePlugsSlots for real <Bug> <Simple ð> <UC20> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7838>
 * Chipaca _really_ needs to lie down for a while, now
<mup> PR snapd#7839 opened: tests: prevent partitioning test errors <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7839>
<cmatsuoka> mvo: issued a quick workaround atempt, but also working on a more definitive solution that drops lsblk entirely and uses blkid instead
<pedronis> mvo: I removed the 2.43 milestone from snap run --explain, seems a bit unlikely to make it
<zyga> pedronis: I just pushed an update there
<zyga> with spread tests and more things that it does
<zyga> but it can be added in later if you feel like it's not ready
<pedronis> zyga: for one it needs a jdstrand review, 2nd it needs careful review of each output line
<zyga> pedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-771e057220c48a44a34166289f5339f4R1 is the starting point
<mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
<zyga> we can tweak it all the way we want but I think, since it's not meant to be parsed by machines, it should go in after jdstrand's review
<pedronis> zyga: ?
<zyga> I'm saying we should not go over the output with a fine comb and not ship it
<pedronis> zyga: machine parsing is not my worry here
<zyga> we should ship it and improve it after people use it
<pedronis> zyga: we should start from a good place, atm the are open questions and the output formatting not very consistent
<zyga> pedronis: open questions?
<zyga> pedronis: what is not consistent?
<pedronis> zyga: the usage of colons for once
<zyga> pedronis: what about it?
<zyga> honestly, that's the last thing anyone using this for real will care about
<zyga> but I don't think it's inconsistent now, maybe you are looking at the older version
<pedronis> zyga: maybe, it needs review either way
<zyga> that's true
<pedronis> from me
<zyga> I'd just hate to blow it out of proportion as to what it  needs to be - it's a tool, not a designer hat; it's good to ship it if it's 80% there and can benefit someone
<pedronis> not more than any other snapd output
<pedronis> anyway jdstrand review is still the main blocker atm
<pedronis> zyga: the open questions is the remark Maciej made about separator, and also how that matches or not the original sketch plan
<zyga> pedronis: the separator probably cannot be used if we want wrappers and other layer to handle explain-like output
<zyga> pedronis: because while there's a clear start, there is no clear end
<pedronis> zyga: I agree but the last output had still missing bits vs the original sketch
<pedronis> not sure if your last pass fixed this or not
<zyga> pedronis: I didn't check it against the sketch but I think the sketch is just that, there are TODOs to add more things based on what snap run really does
<zyga> pedronis: I'll double check what's going on in the code and if there's something to add based on the original sketch
<pedronis> zyga: yes, but the sketch has a separator just before the start of the app command itself
<zyga> pedronis: but my point is that it's meant to be realistic, not idealistic
<pedronis> which partly addressed Maciej worry
<pedronis> addresses
<pedronis> anyway my point stand that still need a proper review after jdstrand one
<zyga> s/after// but yeah
<zyga> I think we don't need to wait for jamie
<jdstrand> you touch snap-confine
<jdstrand> I'd like to review at least those bits
<pedronis> zyga: well I plan to wait, given I have also other things
<zyga> not wait for the other review
<pedronis> zyga: I suppose I could to a quick pass over the output in the spread test when I have a moment
<zyga> thanks!
<zyga> I can quickly adjust it after initial output review
<pedronis> is the output up-to-date ATM in tha test?
<zyga> yes
<pedronis> ok, thx
<zyga> cannot join standup
<zyga> sorry
<zyga> I'll join when I xan
<zyga> oh my
<zyga> sorry guys
<zyga> chrome love
<pedronis> mvo: there is, snap find mumble
<pstolowski> heh
<pstolowski> jdstrand: hey, question about modem-manager interface
<jdstrand> ok
<pedronis> mvo: ijohnson: can we do it 30 mins before standup tomorrow?
<jdstrand> that interface is pretty ancient
<ijohnson> pedronis: mvo: yes that's fine for me
<pstolowski> jdstrand: is this intended that AppArmorConnectedPlug always adds modemManagerConnectedPlugAppArmor snippet, and on classic in addition appends modemManagerConnectedPlugAppArmorClassic ? should there be if classic - else core?
<jdstrand> pstolowski: I'm looking at it
<pstolowski> jdstrand: that extra snippet gets label=snap.core.* on classic in the generated profile
<jdstrand> pstolowski: so, like I said, this interface is ancient and doesn't benefit from the moderm thinking around app snaps, classic, etc. looking at it, if you install the snap on a classic system, you get a weird peer=(label="snap.core.*") rule
<jdstrand> pstolowski: iirc, on or the other was tacked on later with the understanding that "you're not expected to install the modem-manager snap on a core system"
<jdstrand> but, we've handled this better lately
<jdstrand> pstolowski: eg, in avahi-control
<jdstrand> pstolowski: PermanentSlot and ConnectedSlot could also be updated
<jdstrand> pstolowski: basically, it and most likely bluez and network-manager would likely benefit from being updated to model after avahi-control. though, still, "you're not expected to install the * snap on a core system" with all of these :)
<ijohnson> jdstrand: but you are definitely expected to install the network-manager and bluez snap on UC?
<jdstrand> erf
<mvo> pedronis, ijohnson sure, let me schedule something
<ijohnson> and modem-manager snap too actually
<jdstrand> s/core/slassic/
<jdstrand> classic*
<ijohnson> ahhh yes that makes much more sense +1
<jdstrand> ijohnson: I totally typoed that :)
<jdstrand> pstolowski: ^
<ijohnson> it's still early :-)
<jdstrand> pstolowski: is this something you are thinking of fixing or should I add it to the list for the next batch of updates?
<jdstrand> ijohnson: not sure you saw, but nice job on the lib caching forum topic :)
<ijohnson> I think I did see, but thanks again :-)
<jdstrand> :)
<pstolowski> jdstrand: no, at least not now; it just popped because of this weird label (in one of the spread tests), which becomes even more weird with my #7830
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<jdstrand> pstolowski: ack, I'll add it to my list then
<pstolowski> jdstrand: i though a simple if-classic-else-core in modem manager would do it, but sounds like you envison to streamline it more
<pstolowski> *thought
<pstolowski> jdstrand: thanks, and thanks for explaining
<jdstrand> np
<jdstrand> yeah, they just need updating. they're a bit crufty
<pedronis> mvo: thx, I see it in your cal but not mine
<mvo> pedronis: yeah, sorry, was wondering if we should just use the 4:30 slot I have with ian tomorrow anyway - this would mean that ian does not have to get quite so early
<mvo> pedronis: or the 5pm slot
<mup> PR snapd#7733 closed: tests: disable nova from install-snaps test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7733>
<mvo> pedronis: after the certbot meeting
<pedronis> mvo: well the first slot overlaps with the certbot one, after the cerbot is fine with me if it works for you
<mvo> pedronis: I would have to skip/move one meeting
<ijohnson> mvo: it's ok, it's not too early
<pedronis> mvo: no strong preference, except I think I need to be at the certbot meeting
<zyga> brb, lunch
<zyga> (late)
<mvo> ijohnson: it could either be 30min before the meeting or 2h later
<ijohnson> mvo: whatever is most convenient for you, I don't have any other meetings except our 1:1 and the SU and it's only 7:30 so that's doable for me
<zyga> Lunch over but Iâm looking after Lucy now
<zyga> I will return in about an hour
 * cachio lunch
<zyga> re
<mup> PR snapd#7838 closed: cmd/snap-bootstrap: stub out snap.SanitizePlugsSlots for real <Bug> <Simple ð> <UC20> <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7838>
<Chipaca> xnox: ^
<pedronis> ijohnson: thanks for the review
<jdstrand> mvo, pedronis: hey, fyi, zyga gave his approval on PR 7228 and I incorporated his feedback. He said to feel free to merge, but I wasn't sure if that meant after another +1 or right away. I think there is a question in my mind since this PRs only adds spread tests and doesn't touch code, and not sure if 2 approvals is required for that
<ijohnson> pedronis: np
<mup> PR #7228: interfaces: add audio-playback/record and pulseaudio spread tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7228>
<pedronis> ijohnson: about the confusing code, it copied and just slightly modified from some code where the error can happen or not
<jdstrand> (in any case, obviously I'll what for the tests to pass)
<pedronis> but I agree is confusing if the error is expected
<pedronis> jdstrand: let me look
<ijohnson> pedronis: yeah that's kinda what I thought but still seems like either a comment explaining that or not doing it that way would be good, because I could see myself needing to write a similar test and taking this one as a template and then being very confused about why it was written this way
<pedronis> jdstrand: you probably want a 2nd review from some of the people that looked at it already, doesn't need to be me tough
<jdstrand> pedronis: ok
<pedronis> I actually didn't look at it, just did a meta-comment at some point
<zyga> jdstrand: I meant "from my pov it is ok" but I don't think I have the power to merge with one review
<jdstrand> that's fine
 * zyga fights snap security tag hydra
<jdstrand> I didn't want to assign anyone to review it, so I asked in a comment if Ian or Maciej wants to do it
<ijohnson> jdstrand: I can take a look today probably
<jdstrand> ijohnson: thanks. it is only as urgent as cleaning out old PRs is
<ijohnson> ack
<zyga> jdstrand: merge master into it if you haven't done that recently please
<cmatsuoka> mvo: the empty filesystem bug seems to be a race involving node creation and the udev event queue, I'll test a queue flush after partitioning and before creating the filesystems
<jdstrand> zyga: yep, already done
<jdstrand> I learned from last time
<zyga> super, just wanted to double check after recent old-branch-post-merge-fixups
<zyga> :)
<zyga> I think we all learned, it's a shame CI is too costly to run on each master change
<mup> PR snapd#7826 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 1 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>
<mup> PR snapd#7840 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7840>
<mvo> cmatsuoka: cool, thanks for digging into this
<jdstrand> ijohnson and bloodearnest: fyi, https://github.com/sergiusens/snapcraft-preload/pull/39
<mup> PR sergiusens/snapcraft-preload#39: preload.cpp: use setgroups()/initgroups() in sandbox-compliant manner <Created by jdstrand> <https://github.com/sergiusens/snapcraft-preload/pull/39>
<ijohnson> \o/ yay thanks jdstrand
<zyga> I feel cold getting me
<zyga> Need a break
<zyga> Sleepy
<mup> PR snapcraft#2830 opened: elf: properly handle corrupted ELF files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2830>
<mup> PR snapcraft#2828 closed: Appstream <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2828>
<mup> PR snapcraft#2831 opened: appstream extractor: add support for code <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2831>
<zyga> cold meds are working so I'm back
<zyga> wondering how to proceed with snap security tag validation
<zyga> security tag are super diverse
<zyga> and it feels like something to make tidy now
<mup> PR snapd#7839 closed: tests: prevent partitioning test errors <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7839>
<mup> PR snapd#7841 opened: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>
<cmatsuoka> cachio: PR #7841 fixes a silly shell error in the previous PR
<mup> PR #7841: tests: fix partitioning test debug message <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>
<cachio> cmatsuoka, taking a look
<cmatsuoka> cachio: when the udev fstype error happens, grep fails and the test was aborted
<cachio> cmatsuoka, ah, ok
<cachio> thanks for the explanation
<cachio> +1
<cmatsuoka> cachio: I was expecting ID_FS_TYPE to be there with an empty value when it fails, but in fact the key is not listed
<cachio> cmatsuoka, nice, thanks for the fix
<ackk> mvo, hi around?
<cmatsuoka> cachio: sorry for the basic error in the first attempt
<mup> PR snapd#7842 opened: tests: cache snaps also for ubuntu core and add new snaps to cache <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7842>
<cachio> cmatsuoka, no problem, this happens often
<mvo> ackk: a bit, it's rather late already - what can I do for you :) ?
<ackk> mvo, sorry, just checking if https://bugs.launchpad.net/snapd/+bug/1817276 is supposed to be fixed in 2.42.1+18.04 (deb package in bionic)
<mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
<mvo> ackk: that's correct, it should be much better with this version
<mvo> ackk: I think I got one positive report already
<ackk> mvo, I still see it use 100% cpu at times
<mvo> ackk: is it not helping for you :/ ?
<ackk> mvo, well it's better for sure
<ackk> but I guess under heavy I/O cpu usage is expected?
<mvo> ackk: yes - ish - I mean, if it's still not good enough we need to talk again. the performance should be in the order of 10x better than before
<ackk> mvo, yeah it's definitely much better. I wasn't sure if it was supposed to be entirely gone
<ackk> mvo, anyway, thanks for the info, don't let me keep you :)
<mvo> ackk: aha, right. it's still fuse currently so a certain degree of slowness is expected unfortunately
<mvo> ackk: but again - if it's a problem we could talk about options (which would be hackish at this point :(
<mvo> ackk: but let's do this tomorrow :)
<ackk> mvo, I haven't tested it extensively, yet
<ackk> mvo, yeah, good night, thanks again :)
<mup> PR snapd#7843 opened: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7843>
<mvo> ackk: my pleasure - good night to you too!
<mup> PR snapd#7841 closed: tests: fix partitioning test debug message <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7841>
#snappy 2019-12-05
<mup> PR snapd#7832 closed: snap-bootstrap: support auto-detect device in create-partitions <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7832>
<mborzecki> morning
<mborzecki> nfs-support failed on 19.10 https://paste.ubuntu.com/p/JvGPJxMxZx/
<sdhd-sascha> good morning
<sdhd-sascha> morzecki: how can i run this single test ? go test -check.f ... ?
<sdhd-sascha> mborzecki:
<mborzecki> sdhd-sascha: go test -check.f <testname> in the corresponding package or jsut passing the pacakge name eg. github.com/snapcore/snapd/cmd/snap
<mborzecki> sdhd-sascha: writing import paths is tedious, so i just cd into the directory of the package
<sdhd-sascha> i tried:
<sdhd-sascha> $ go test -check.f github.com/osutil/nfs_linux_test.go
<mborzecki> sdhd-sascha: when in snapd tree, cd osutil ; go test -check.f nfsSuite
<mborzecki> sdhd-sascha: nfsSuite because it's the test suite defined in nfs_linux_test.go file
<sdhd-sascha> mborzecki: thank you - it works
<sdhd-sascha> but on my 19.10 it works
<sdhd-sascha>  go test -check.f nfsSuite
<sdhd-sascha> OK: 1 passed
<sdhd-sascha> PASS
<sdhd-sascha> ok      github.com/snapcore/snapd/osutil        0.005s
<sdhd-sascha> I have there a nfs-mount.
<sdhd-sascha> mborzecki: Or, is this a different nfs test in the paste from you? Error executing google:ubuntu-19.10-64:tests/main/nfs-support :
<sdhd-sascha> mborzecki: you mean the "spread" tests. sorry
<zyga> good morning
<zyga> mborzecki: I have a question
<zyga> mborzecki: I was fighting snap security tag mess spread around the code and I think that's a separate cleanup
<mborzecki> zyga:  hey
<zyga> mborzecki: do you think it would be ok to do just a regexp based validation on the supposed security tag
<zyga> mborzecki: and do nothing more in the sandbox/cgroup package for now?
<mborzecki> zyga:  let me take a look at the pr
<zyga> mborzecki: I didn't push anything since yesterday
<zyga> mborzecki: because trying to make sense of how security tags are used and validated brings one headache
<mborzecki> zyga: heh, indeed it does
<zyga> mborzecki: the best I can think of
<zyga> mborzecki: for now
<zyga> mborzecki: is that security tag becomes an interface that is implemented by a number of things
<zyga> mborzecki: pluse a few special cases that wrap a string
<mborzecki> zyga: hm looks like the only code validating security tags is in s-c now
<zyga> yeah
<mborzecki> zyga: and it's a regex, so i guess it's fine
<zyga> yeag
<zyga> yeah
<zyga> it's a regex that says snap.$(snap name regex)(.hook)?.$(app name regex)
<zyga> and one more weird variant, IIRC
<zyga> on top of this I'd like to craft something that unifies all knowledge of security tags, documents it and puts validation functions that everything uses
<zyga> we mostly always generate tags, not read them
<zyga> so we didn't need much validation before
<zyga> (in go, at least)
<sdhd-sascha> good morning
<mborzecki> zyga: sandbox/tags? or stuff that in snap/naming?
<zyga> hey, good morning sdhd-sascha
<zyga> mborzecki: I started snap/naming/sectag.go but not married to it
<zyga> I think it's silly because of how we must be careful not to get import cycles
<zyga> so eventual placement is really more related to where it compiles
<zyga> hey mvo
<mvo> hey zyga
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> what did I miss this morning so far :) ?
<mvo> how are tests looking?
<zyga> I don't think you've missed much
<zyga> tests are green
<zyga> some red but probably branch related
<zyga> mvo: schedule question, when do you cut
<zyga> mvo: and if you cut now, do you anticipate another cut before release or is that it?
<mvo> zyga: probably today
<mvo> zyga: and no worries, we can always cherry pick
<zyga> ok
<mvo> zyga: but once branched there will be no merge from master anymore
<mvo> zyga: like a full-one
<zyga> that's fine
<zyga> just wondering if everything you wanted in 2.43 is in master now
<zyga> or is it likely we'll add more because there's known missing bits
<sdhd-sascha> zyga: didn't found the time these days to get thing working. Is difficult to explain, if you do it for free
<sdhd-sascha> zyga: Now i had another question
<sdhd-sascha> i just modified and build snap & snapd
<sdhd-sascha> And i don't want to replace the original
<sdhd-sascha> How do you test the new installation on the same machine ?
<sdhd-sascha> Or, do you use a vm ? I think about a user-systemd-service
<zyga> sdhd-sascha: it varies
<zyga> sdhd-sascha: it depends on what I changed
<sdhd-sascha> zyga: wait, i build a .deb package.
<zyga> sdhd-sascha: snapd vs snap-confine or other programs
<sdhd-sascha> i have enougt machines. and can replace it
<zyga> sdhd-sascha: I never build a distro package for that
<zyga> sdhd-sascha: most often than not I use "make hack" or I build snapd and run it manually
<sdhd-sascha> I want to replace the snap cmdline and snapd
<zyga> sdhd-sascha: (just stop snapd.socket and snapd.service before)
<zyga> sdhd-sascha: for snap command you can just run it from the tree (go build ./cmd/snap and run it)
<pstolowski> morning
<sdhd-sascha> zyga: until now i never wrote "go" before. So i just copied "strace", remove the timings and add "ltrace" into osutils/ltrace
<zyga> sdhd-sascha: that's fine, go is easy to get into
<zyga> sdhd-sascha: there are remarkably few quirks
<sdhd-sascha> zyga: the unittests runs.
<zyga> sdhd-sascha: perhaps open a draft PR, it will be easier to give advice this way
<sdhd-sascha> zyga: if go had "tail-call optimization, then i would have started learning it earlier.
<zyga> sdhd-sascha: if it mattered, it would be there ;)
<sdhd-sascha> zyga: yes, i read about it. the solved anything by iteration. But the parser's api looks good at the first look ;-)
<mup> PR snapd#7842 closed: tests: cache snaps also for ubuntu core and add new snaps to cache <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7842>
<zyga> hmm
<zyga> can a snap have an app that is just called "hook"?
<pedronis> zyga: I don't think we have anything that would block that atm
<zyga> right
<zyga> just writing unit tests and got surprised
<zyga> good morning pedronis :-)
<zyga> wow
<zyga> found a bug already
<zyga> ValidateApp allows uppercase apps
<zyga> but we don't allow that, do we?
<zyga> at least, it was not allowed in the specs
 * zyga checks other implementations
<mup> PR snapd#7775 closed: seed: support extra snaps on top of Core 20 dangerous models <UC20> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7775>
<zyga> mm
<zyga> can app names have upper-cache characters?
<mvo> \o/ another uc20 merged!
<zyga> regexps say they do
 * mvo hugs mborzecki 
<zyga> my memory says they don't
<pedronis> zyga: no
<zyga> pedronis: we don't allow them?
<pedronis> we don't
<zyga> pedronis: then we need to fix a bunch of things first
<zyga> pedronis: I'll part my branch and address that first
<mborzecki> we have ValidApp = regexp.MustCompile("^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$")
<pedronis> zyga: you can look at snap/naming/validate.go
<zyga> yeah, I was there just now
<zyga> writing tests and noticed one didn't fail as expected
<pedronis> ah, sorry, we do
<pedronis> I was confused
<pedronis> I read snap name
<pedronis> no, we allow them
<pedronis> what we don't allow is .
<zyga> pedronis: so name like package.FOO is okay?
<zyga> (for an snap+app name)?
<pedronis> seems so
<zyga> ok then
<zyga> back to my branch
<zyga> :)
<pedronis> mborzecki: hi, what's the status of #7570 ?
<mup> PR #7570: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
<mborzecki> pedronis: i need to figure out the selinux errors that popped up there
<mborzecki> #7840 is long but simple and could land easily
<mup> PR #7840: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 2 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7840>
<pedronis> mborzecki: could you push your suggestions to #7555 when you have a slice of time
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<mborzecki> pedronis: sure, can do
<pedronis> mborzecki: thx
<zyga> mborzecki: pushed updates to https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> mborzecki: have a look when you can, most of your comments can be resolved now, I think
<zyga> I need to break for 30 minutes
<ackk> mvo, hi, so I've  been testing a bit more with the maas snap, I do still see snapfuse using 100%cpu
<ackk> mvo, I see maas-related processes keep being restarted, and I'm not sure if this is because they're responding too slowly because of the snapfuse issue or if it's unrelated
<pedronis> ackk: do you know if data in the snap is getting accessed all the time? naively I would expect the snapfuse cpu usage to match access, and I would expect less access once things are running. maybe it's really a bug in snapfuse not just a perf issue
<pedronis> though
<ackk> pedronis, yeah there's a lot of I/O
<pedronis> that sounds strange in itself
<ackk> pedronis, I'm going to compare with the same snap unpacked and installed with try
<mborzecki> pedronis: left a note under 7555, the snippet i proposed doesn't work on arch after all, guess it's the socket mediation that's still missing from the mainline
<mborzecki> quick errand, back in 30
<pedronis> mborzecki: sounds like we should merge it as is then
<pedronis> mvo: is #7817 ready for re-review?
<mup> PR #7817: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7817>
<ackk> pedronis, yeah so same snap downloaded and unpacked works fine
<zyga> ackk: when you say there is lots of IO, can you explain what kind of data is maas reading after startup?
<zyga> (from $SNAP)
<ackk> zyga, there's a lot happening at maas startup, including reading a lot python files. I'm not sure if that's the cause, but what I see is that supervisord spawns the different processes (named dhcpd squid ...), no error in logs, then after a few seconds they get killed and respawned
<ackk> that doesn't happen if I unpack the snap
<mup> PR snapd#7844 opened: ignore visual studio code directory <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7844>
<zyga> ackk: ah
<zyga> so it's essentially perpetual startup
<ackk> zyga, correct
<zyga> I was trying to understand if there's, normally, lots of IO after startup
<ackk> zyga, no
<zyga> why do they crash?
<ackk> zyga, I mean, there is if  your're synching imagaes
<ackk> zyga, no idea, nothing in logs
<zyga> can you see them via systemctl status
<mup> PR snapd#7845 opened: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845>
<zyga> I guess no, because supervisord
<ackk> zyga, correct
<zyga> well, that's something to debug then
<ackk> I'm going to try in a fresh container
<mup> PR snapd#7837 closed: devicestate: implement creating partitions in "install" mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7837>
<mvo> pedronis: yes, I updated it this morning
<mvo> pedronis: once that is in I have a simple followup that adds this call to the install handler in devicestate
<ackk> pedronis, zyga not sure if my message got through before the split
<mup> PR snapd#7846 opened: devicestate: add missing test for failing task setup-run-system <Simple ð> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7846>
<zyga> ackk: I didn't see it
<pstolowski> Chipaca: ping
<Chipaca> pstolowski: pong
<pstolowski> Chipaca: i've updated/tweaked your check-skeleton PR but for some reason coudn't push to your PR; mind merging my changes from https://github.com/stolowski/snapd/tree/check-skeleton-check-interfaces if you're ok with them?
<Chipaca> sure
<Chipaca> you should be able to just push tho
<Chipaca> pstolowski: what error does it give you?
<pstolowski> Chipaca: nvm! i had your remote with https:// ; worked with ssh://
<Chipaca> pstolowski: :-D yeah happens
<pedronis> pstolowski: thanks, I put it in my queue for re-review
<pstolowski> pedronis: there is one remaining remark from you about moving ParseMountEntry to shared. no strong opinion about that, can do
<pedronis> pstolowski: I'll look again, is not a blocker either way
<mborzecki> re
<pedronis> pstolowski: btw, I'm doing a pass again on some of your pre-seeding PRs
<pstolowski> pedronis: ty, just saw your comments
<pstolowski> mborzecki: do you have a moment to finish the review of https://github.com/snapcore/snapd/pull/7697 ?
<mup> PR #7697: interfaces/apparmor: handle pre-seeding mode <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7697>
<mborzecki> pstolowski: sure, will do
<mup> PR snapd#7697 closed: interfaces/apparmor: handle pre-seeding mode <Preseeding ð> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7697>
<mborzecki> pretty annoying how github doesn't let you know the PR you're commenting on has been updated
<pedronis> pstolowski: question in #7320
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<pedronis> pstolowski: thx
<mup> PR snapd#7847 opened: Parse seed if either kernel or base are not mounted <Created by xnox> <https://github.com/snapcore/snapd/pull/7847>
<mborzecki> snap run --strace hanging on 16.04 too: https://paste.ubuntu.com/p/FGK8JysymF/
<mup> PR snapd#7848 opened: Mount ubuntu-data tmpfs, in one go with kernel & base <Created by xnox> <https://github.com/snapcore/snapd/pull/7848>
 * Chipaca gets coffee
<mborzecki> has anyone noticed that when there's a change in progress, and it's currently downlaoding a snap, runnig snap change in a separate terminal takes really long to show anything?
<zyga> yeah
<zyga> lock contention
<zyga> we update the status a lot
<mborzecki> wonder if that's beacuse of re-refresh taking state lock too often
<zyga> perhaps that's that, though I didn't debug it that deep
<zyga> re-refresh?
<mborzecki> since it basically tries to run all the time
<zyga> oh
<zyga> perhaps
<zyga> we could use read locks
<zyga> and write locks
<zyga> perhaps that would help reading the status
<zyga> (or, you know, a real database)
<mborzecki> or use the tracing endpoints and find out whihc lock is hit most often :P
<pedronis> it runs every 100ms, I wouldn't call it all the time
<pedronis> but could be
<pedronis> mborzecki: if there's a download going, there is the progress updates and polling as well
<mborzecki> iirc there were also some patches from mvo to make download updates more coarse
<pedronis> mborzecki: anyway my point is that before fixing we need to know what is happening exactly, I wouldn't make changes based on speculation
<mborzecki> yup
<zyga> 100ms is a bit excessive
<mvo> zyga: do you think you could check 7823 again? I fixed the bits you raised there
<zyga> yup
<mvo> mborzecki: yeah, it was really crazy in the past, it would update the progress for every packet basicly but that got fixed
<zyga> mvo: done
<mvo> thank you zyga !
<mup> PR snapd#7823 closed: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7823>
<mup> PR snapd#7844 closed: gitignore: ignore visual studio code directory <Created by sd-hd> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7844>
<mborzecki> pedronis: thanks for the feedback in #7821, applied it
<mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<mborzecki> oh and it needs a 2nd review
<pedronis> mvo: did you see my question whether 7817 can be re-reviewed ?
<Chipaca> zyga: why is cmd/snaplock a thing? why isn't it in osutil?
<Chipaca> we've put some random stuff in cmd but only when it was used from daemon and client and there wasn't a clear place for it
<zyga> Chipaca: it was placed there after code review
<Chipaca> and the imports were wrong for *util
<pedronis> Chipaca: it uses dirs,  it not a util
<Chipaca> here the imports are simple, and it's used from cmd/foo but also from overlord/snapstate
<pedronis> it's very specific
<Chipaca> pedronis: we already use dirs from osutil
<pedronis> we don't
<Chipaca> do so
<Chipaca> osutil/strace/
<pedronis> strace then is also wrongly placed
<Chipaca> putting libraries under cmd/ is not a nice thing
<pedronis> Chipaca: putting things in util that are very snap layout specific is worse
<Chipaca> maybe we should set aside an afternoon at a sprint or something and do an on-paper reorg
<pedronis> anyway strace is misplaced as is
<pedronis> Chipaca: snaplock is also there because the lock is also implemented in C similary for snap-confine
<pedronis> Chipaca: notice that we have C libraries in cmd
<Chipaca> myeah
<pedronis> Chipaca: so basically as I see your point but it's more complicated, bleeding non utility things into *util is still worse in my book
<pedronis> it means you cannot expect them to be isolated
<pedronis> which as util they should
<zyga> pedronis: for the record
<zyga> pedronis: they are in cmd because there was aversion to a makefile in top level
<zyga> pedronis: otherwise they could be anywhere
<pedronis> well we could have a different directory and some more Makefile fun
<pedronis> I'm personally not very offended either way
<pedronis> I mean by libraries under cmd vs not
<zyga> I think we could use a top-level makefile that cleans up various per-directory makefile things
<zyga> (separate of the library discussion)
<zyga> it would allow us to reuse bits and not define the same things over inconsistently (e.g. libexecdir)
<zyga> brb
<mup> PR snapd#7849 opened: osutil: cmd: add ltrace <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7849>
<zyga> 15 minute break, kids home
<sdhd-sascha> zyga: just created PR for "ltrace"
<zyga> sdhd-sascha: cool, I'll check it out in a while
<sdhd-sascha> zyga: hope, i didn't make mistakes ... i really need to learn go first ;-)
<pedronis> mborzecki: thansk for the changes, they were not blockers, I made a follow up nitpick remark though
<pedronis> Chipaca: but yes I agree we need to reorg our code, there is too much things at top-level and some less than clean bits. OTOH can only be done when the open PRs are under control given the churn
<mborzecki> hm we still have fwupd-refresh.service starting in debian-sid images
<mborzecki> cachio: ^^ wasn't that explicitly disabled/removed at somep oint?
<cachio> mborzecki, yes, the script has been updated
<cachio> but the image is autogenerated on monday
<cachio> I can manuallly trigger the update now if it makes sense
<cachio> I just tested the script is it is disabling correctly the service
<cachio> on debian 9 and sid
<mborzecki> cachio: please do, the tests/main/degraded test keeps failing on sid
<mborzecki> randomly
<cachio> mborzecki, ok, I'll do it
<mborzecki> cachio: thanks!
<cachio> mborzecki, np
<cachio> running
<mup> PR snapcraft#2831 closed: appstream extractor: add support for code <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2831>
<zyga> re
<zyga> back with hot tea
<zyga> sdhd-sascha: is sudo required there?
<sdhd-sascha> not sure, on my test machine i runs without sudo
<zyga> sdhd-sascha: ok, I _suspect_ it may not be required, unlike strace
<sdhd-sascha> zyga: you mean "sudo snap run --ltrace ..." ?
<zyga> no, I mean, internally can it not use sudo and still work
<sdhd-sascha> zyga: most of the code is adapted from strace . And the commands are very similar
<zyga> yeah but the reason is different
<zyga> strace uses ptrace
<sdhd-sascha> but there is no static ltrace and no timings
<zyga> ltrace seems to only use it in a debug code
<zyga> it would be good to check if it's really required
<zyga> one more thing
<zyga> can you look at tests/main/snap-run
<zyga> and there at task.yaml
<zyga> it exercises snap run --strace
<zyga> it would be good to extend that to ltrace
<zyga> I can tell you how to run those tests
<sdhd-sascha> zyga:  HACKING.md: "### Running spread tests" ??
<zyga> yes
<zyga> not sure how correct that is
<zyga> I guess you will find out
<sdhd-sascha> zyga: sure -- it's little bit cold here ... good time to start some vm's on the server ;-) :-D
<pedronis> zyga: where does snap-update-ns output finishes here:  https://github.com/snapcore/snapd/pull/7728/files#diff-e4c8d0c72c7b412376e0a04e6ad4db41 ?
<mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
<zyga> pedronis: because that example doesn't use a mount profile
<zyga> pedronis: there should be a [snap-confine (returning)] section or something like that
<zyga> I'm looking at that no
<zyga> just adding headers via << >> first
<pedronis> well I wanted to play with << >> first
<pedronis> not sure they are better
<zyga> pedronis: yeah, I added Header() so it's easy to change :)
<pedronis> I wanted to give you a changed .in
<zyga> ok
<zyga> go ahead, I'll integrate it
<zyga> I think we need to expand the test though, it doesn't handle enough of explain cases yet
<zyga> but it's a good first start for  now
 * Chipaca wonders what the area under a patch is, to integrate it
<zyga> Chipaca: it's just len(bytes)  :D
<sdhd-sascha> zyga: this line in HACKING.md is scary: "curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz | tar -xz -C $GOPATH/bin"
<sdhd-sascha> i will build this from repo.
<zyga> you can build it
<Chipaca> sdhd-sascha: or snap install spread
<Chipaca> although that one's a little old
 * Chipaca promised to update it and has only found 1h to work on it so far
<sdhd-sascha> Chipaca: +1
<mborzecki> ijohnson: quite puzzled that SNAP_CONTEXT is not triggered when running run-checks
<pedronis> zyga: my question was where would that snap-confine returning be placed ? After the whole Configuring mount namespace according to mount profile section?
<mborzecki> ijohnson: can you bash -x run-check --unit maybe?
<ijohnson> mborzecki: sure after I finish breakfast :-)
<mborzecki> ijohnson: hah sure ;) enjoy your breakfast
<sdhd-sascha> Chipaca: What's need to be updated there ?
<cmatsuoka> mvo: with #7837 landed, can #7762 be closed?
<mup> PR #7837: devicestate: implement creating partitions in "install" mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7837>
<mup> PR #7762: devicestate: core 20 install mode handling <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762>
<Chipaca> sdhd-sascha: the snap package has a few issues, that i'm wanting to fix
<Chipaca> sdhd-sascha: like not being able to access ~/.spread for example :)
<Chipaca> sdhd-sascha: and not having a runnable kvm in it either
<sdhd-sascha> Chipaca: ah, ok - i will try it ;-)
<zyga> pedronis: the returning message is in snap-confine
<zyga> pedronis: I added Header now but I'll wait for your call to change it to << >> or whatever else
<mvo> cmatsuoka: can be useful for reference, but it's fine to close it
<pedronis> zyga: I'm trying with <<, not super happy though, mostly because they don't take up vertical space
<pedronis> also pastebin doesn't like my paste atm
<cmatsuoka> mvo: ok. I'll add a comment listing the split PRs
<zyga> oh?
<zyga> ah, pastebin doesn't like <>
<zyga> evil html javascript hackers
<Chipaca> use kannada
<mvo> cmatsuoka: thank you
<pedronis> zyga: not sure, seems to have problems
<pedronis> zyga: anyway I tried this:  https://gist.github.com/pedronis/93703067a720d6ddce49cf6351f44ca5
<zyga> looking
<pedronis> notice that << is one change, the others are indentation  and I reformulated one thing
<zyga> ok
<zyga> let me compare
<Chipaca> fwiw i meant á¸á³ instead of <> but was mostly joking (as is https://github.com/vasilevp/aboriginal )
<pedronis> zyga: btw, do you remember why you picked [ ] initially ? they make me think of .ini files tbh
<zyga> pedronis: we just tried things until it looked good enough
<mup> PR snapd#7762 closed: devicestate: core 20 install mode handling <UC20> <â Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762>
<pedronis> zyga: anyway as I said, not super happy with << either
<pedronis> need to think a bit
<pstolowski> pedronis:, Chipaca #7320 is green, ok to land?
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> pstolowski: thank you
<pedronis> mborzecki: another comment in 7821, sorry
<mborzecki> pedronis: haha i should get another coffee
<mup> PR snapd#7320 closed: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<zyga> pedronis: applied, double checking if it passes and if I missed anything
<zyga> pedronis: I'll push when ready
<zyga> pedronis: as for headers, perhaps for explain we could use terminal features (colors, bold, etc)?
<pedronis> zyga: possibly yes, maybe Chipaca has input on that
<Chipaca> maybe :)
<Chipaca> zyga: what headers?
<zyga> Chipaca: please look at https://gist.github.com/pedronis/93703067a720d6ddce49cf6351f44ca5
<zyga> Chipaca: headers are << foo >> lines
<Chipaca> ah
<Chipaca> nice
<Chipaca> hm
<Chipaca> do we want this to be parseable in any way?
<Chipaca> i don't know if the first line is a message to the user or a feature or a complaint :-)
<pedronis> no, I don't think parseable is a requirement
<pedronis> we likely would do something very different if it was meant for machine consumption
<Chipaca> ok
<sdhd-sascha> Should we remove *.deb packages ? because on master it isn't buildable
<Chipaca> sdhd-sascha: ?
<Chipaca> sdhd-sascha: master should be buildable to a .deb (and an .rpm)
<Chipaca> sdhd-sascha: in fact we build it to a deb every spread run
<Chipaca> and i think we also build an rpm every test run but am not 100% sure
<sdhd-sascha> Chipaca: on thought it was on my local machine, but then i tested it on https://launchpad.net/~sdhd/+archive/ubuntu/snapcore/+build/18206983
<sdhd-sascha> it's master plus my small patches
<sdhd-sascha> Chipaca: i will look later, maybe something wrong with the recipe ?...
<ijohnson> mborzecki: so when I run with run-checks, it seems that all of the packages are listed in the cmdline to `go test ...` but if I just do `go test ./...` in the root of the git repo I hit that test failure every time
<mvo> pedronis: a (maybe high-level?) review of 7817 would be great
<jdstrand> mborzecki: hey, fyi https://github.com/snapcore/snapd/pull/7555#discussion_r354323376
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<mborzecki> jdstrand: thanks for the comment, let me check that again, but there was no denial related to the session agent socket
<jdstrand> mborzecki: there would not be if you went to forced devmode. check the profile
<mborzecki> jdstrand: there was one related to dac override when i executed part of the test that runs curl as root
<mborzecki> jdstrand: ok, let me start the test again
<ijohnson> mborzecki: actually it's that run-checks will sneakily find go 1.10 to run my tests with, even though I have go 1.13 installed and that specific test fails on go 1.13 but works on go 1.10
<jdstrand> mborzecki: you may also want: sudo sysctl -w kernel.printk_ratelimit=0
<pedronis> mvo: ok
<jdstrand> mborzecki: to avoid kernel rate limiting. also, if you are ever thinking that the kernel is rate limiting, reload the profile and try again (even with the above sysctl, this is still needed with, for example, capability denials)
<niemeyer> > i will build this from repo.
<niemeyer> sdhd-sascha: Make sure you read the source.. :)
<sdhd-sascha> niemeyer: :-D
<jdstrand> mborzecki: not sure what your local test was, but keep in mind, test -S won't trigger the denial.
<mborzecki> jdstrand: the test is what's done in 7555
<jdstrand> mborzecki: ok, so if you ran spread, then look at test-snapd-curl.curl's profile to see if it is the classic template. if not, see if there are any matching rules
<mup> Bug #1617302 changed: Specifying a nonexistent plug does cause any errors <Snapcraft:Triaged> <snapd:Fix Committed by chipaca> <https://launchpad.net/bugs/1617302>
<mborzecki> ijohnson: your go 1.13 is from a snap right? so SNAP_CONTEXT would be set when you run `go test ./...`
<ijohnson> mborzecki: yes
<ijohnson> mborzecki: it fails with go 1.10 as a snap too, so that's all it is
<mborzecki> ijohnson: ok, easy to check, https://play.golang.org/p/_MvNzO2qf3i should print the actual context
<mborzecki> ijohnson: if you go run it with 1.13
<jdstrand> mborzecki: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/lsm_hooks.h#n763
<jdstrand> "Whereas binding and connecting to sockets in the file name space is mediated by the typical file permissions (and caught by the mknod and permission hooks in inode_security_ops), ..."
<ijohnson> mborzecki: yes you're right it's just any go version from a snap will fail that test, I left a comment in the PR
<mborzecki> jdstrand: nice, thanks for the link!
<jdstrand> np
<Wouter0100> Hey guys! I've spend my time today figuring out Ubuntu Core a bit, and seems awesome. Although, I have another question (the first one I asked on the forums, which got answered quickly, thanks for that! <3): how is the update from Ubuntu Core 16 to 18 planned for devices in the wild, and maybe later from 18 to 20? Will this also in a transactional
<Wouter0100> manner? Or is this something that isn't going to be automated?
<Wouter0100> I've seen a core16 and a core18 snap, and someone nearly succeeded in just upgrading this snap - but will there be some official procedure?
<ogra> 16 to 18 is kind of -> send someone out with USB key :)
<ogra> core20 will have a new cool feature called re-modeling that will exactly cover switching to a new version ... but at the same time core20 will also come with a completely new partitioning scheme out of the box ... not sure if that will be covered ...
<ogra> pedronis, ^^^ do you know ?
<Wouter0100> Oeh, that's fancy! Any release schema for core20? Because we are also still developing the Ubuntu Core setup, and when it'll be released in beginning of 2020, we should be able to wait for that just fine :).
<pedronis> ogra: remodeling is not core20 only
<Wouter0100> And I think that the migration to Ubuntu Core will happen with sending someone out with a USB stick :P
<ogra> sure, but if you can keep the frequency low i bet thats better :)
<ogra> pedronis, ah, so core18 will get it too ?
<pedronis> yes
<ogra> then i take back the USB statement :)
<ogra> the beauty of rolling releases :)
<Wouter0100> Indeed, the company I'm developing this software for does not really like the fact that they've to send an engineer throughout NL :-P. Luckily it's a small country, but still
<Wouter0100> Oh, thats awesome! So then I'm just able to continue with core18 and when remodeling is released I will be able to upgrade to core20?! ð
<ogra> technically yes ... practically there is that new partitioning scheme .... not sure how that will be handled during re-model
<Wouter0100> I see
<ogra> i know mborzecki did an awesome job doing gadget upgrades (which holds the partitioning info) but i dont know if that will be integrateable with re-modeling
<mborzecki> ogra: we do upgrade gadget during remodel, but the scheme must be compatible (the same to be exact)
<ogra> yeah, thats what i feared
<ogra> so 18 to 20 might be tricky
<ogra> unless we start soon with providing core18 images with the same partitioning scheme that core20 will have
<ogra> (or at least example gadgets for customers to base on)
<mvo> Wouter0100: we plan to support 16->18 via the network, there shouldn't be any need for a usb stick here. it's a special case of the "remodel" feature that got recently added
<mvo> 18->20 is a bit more fuzzy at this point but I'm pretty sure we will support it, it may just be that you won't get some of the advanced features like recovery/encryption because the partition layout of 16/18 is not flexible enough for this
<pedronis> ogra: we are recommending/considering that for some of the recent core 18 projects, to start with a more compartible layout, at least to have the space
<ogra> pedronis, yeah, we should start pointing people to the example gadget.yaml so they know what partitions are needed
<pedronis> don't think we have plans to do that for the references images though
<ogra> yep, understood
 * zyga is in a car now
<zyga> pedronis: please have a look at https://github.com/snapcore/snapd/pull/7728 again,
<mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
<zyga> I think the expected.in file is now what you specified
<mup> PR snapd#7850 opened: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7850>
<Wouter0100> I see, awesome. Then i'll have a look if I'm able to use the new partition layout for 18. And encryption? Is that something coming in 20? As I've discussed that with my customer that I'm developing this for, and at first said it wasn't possible - but if that would be possible in 20 - some additional leverage to get Ubuntu Core through :)
<mvo> Wouter0100: it will come with UC20 (encryption)
<Chipaca> but later in 20, right?
<mup> PR snapd#7851 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7851>
<Wouter0100> mvo that's awesome
<mvo> Chipaca: well, potentially later, we aim still to release with it but it will be a challenge :/
<Wouter0100> When will UC20 release then? :O
<Wouter0100> Or no ETA planned?
 * cachio lunch
<zyga> Wouter0100: 20.04 AFAIR
<mvo> Wouter0100: roughly at the same time as 20.04 is what we aim for. no exact date set yet though. and we want to have the encryption ready by that date but it's a complex feature that we need to get right so this part *might* slip
<mvo> but we *really* want to have it as part of the first uc20 release and work very hard to make this happen
<pedronis> 20.04 is for amd64
<mvo> pedronis: indeed
<mvo> sorry, did I miss some context and this was about non amd64? the non-amd64 will come a bit later, not april 2020
<mborzecki> jdstrand: this is weird https://paste.ubuntu.com/p/8FWf5S8rcv/
<pedronis> mvo: I'm not sure, just making clear that 20.04 is not for all archs
<mvo> +1
<jdstrand> mborzecki: is the curl command actually talking to the right thing? you can snap run --shell and try the head and the curl
<jdstrand> mborzecki: fyi, for hpage_pmd_size: https://github.com/snapcore/snapd/pull/7850
<mup> PR #7850: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7850>
<mborzecki> jdstrand: this is even more interesting https://paste.ubuntu.com/p/Wk4GHjfQKJ/
<mborzecki> jdstrand: and it's using the same path
<jdstrand> mborzecki: hmm. so, seems like there is something fishy going on in the snap run/snap-confine areas
<jdstrand> I think an strace is in order to see how snaap-confine is being invoked
<mborzecki> jdstrand: but the last paste is without s-c, just system curl vs head under the same profile, curl works, but head is blocked
<Wouter0100> mvo i see, thanks!
<jdstrand> mborzecki: oh, I misread that. need to strace that first one
<mborzecki> jdstrand: it's doing connect https://paste.ubuntu.com/p/nZvBJjJtW3/ maybe that isn't mediated as per file hooks?
<pedronis> pstolowski: it's not hookstate importing ifacestate, it's hookstate/ctlcmd right?
<Wouter0100> Is there any way for a snap to postpone a refresh by a couple of minutes or houes? The snap I develop sometimes requires to be not interrupted. I could schedule
<Wouter0100> I could schedule the refreshes for in the night, but can't guarantee that it'll be possible then. I've also seen a feature for network manager to postpone a refresh when on metered connection, but no hook or other ability to integrate this in my snap
<pedronis> Wouter0100: not yet, but is a planned feature
<ijohnson> hmm is there not a "AsDesigned" status for lp bugs? I seem to remember there was but perhaps that was another old bug tracker
<ijohnson> WontFix seems the closest to this
<Chipaca> ijohnson: nope, no asdesigned on launchpad
<pedronis> yea, it needs to be WontFix
<ijohnson> yeah must have been another bug tracker I'm thinking of
<Chipaca> ijohnson: no LolNo either :-(
<ijohnson> Chipaca: what about OMFGYASSS ?
<Wouter0100> pedronis awesome! Do you know the issue for that? Can't seem to find it. I might try to contribute such thing myself - if that's allowed.
<mborzecki> jdstrand: ok, using the same code for both scenarios and path is used explicitly, https://paste.ubuntu.com/p/GKTxkfH2GY/
<ogra> Wouter0100, just work with the various channels ... leave your install on stable (or beta) and do all your work in edge ... only push it up to the next channel when you think it is ready
<Chipaca> ijohnson: is that a Status, or an Importance?
<ijohnson> both imho
<Chipaca> :)
 * ijohnson stops distracting people
 * ijohnson for now
<pedronis> Wouter0100: no issue yet, it needs to interact with permissioning because we dont want to allow arbitrary delays. Also usually a snap needs to stop refreshes of more than itself
<Wouter0100> Yeah, that's correct.. also for some networking snaps possibly. And I see, a more complicated matter.
<pstolowski> pedronis: yes yes
<pedronis> pstolowski: that's totally fine
<pedronis> ctclmd is slightly oddly placed itself but that's different matter
<pedronis> pstolowski: ifacestate imports hookstate so that import would not have worked
<mup> PR snapd#7852 opened: devicestate: call boot.MakeRunnable() in devicestate <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7852>
<pstolowski> pedronis: right
<zyga> jdstrand, mborzecki: what's going on?
<pedronis> pstolowski: +1  with two comments, one is really for a follow up at this point
<mborzecki> zyga: see my last paste, there's a /run/user/12345/snapd-session-agent.socket, the test in #7555 checks that the snap cannot access it, the check fails on arch
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<zyga> mborzecki: do you have denials?
<zyga> what's the permission on the socket?
<zyga> mborzecki: did we rule out DAC?
<jdstrand> zyga: it is failing open
<zyga> mborzecki: ah, wait, so the test fails because you *can* access it?
<zyga> jdstrand: right
<mborzecki> zyga: connecting using python (no s-c or snaps involved), while running with the profile, can access it as the user (unexpected), but not as root (expected)
<zyga> mborzecki: can you pastebin the apparmor profile for the snap please
<zyga> I'm in a car but I can look
<zyga> (not driving)
<jdstrand> mborzecki: I'm in two different conversations and will circle back to this in a few minutes
<mborzecki> jdstrand: sure
<zyga> jdstrand: hey, can you try to review snap-explain patches, just the snap-confine C changes
<zyga> jdstrand: there are two printing functions there, some getenv
<zyga> jdstrand: but you need to look if we hope of having it for 2.43
<mborzecki> zyga: https://paste.ubuntu.com/p/N2r2n5T26b/
<mborzecki> zyga: oh, and it's on arch
<jdstrand> zyga: it is on the list. there are a pile of store reviews I need to tend to though first
<zyga> thx
<zyga> jdstrand: ack, no rush, it's not a priority item, just a nice-to-have
<jdstrand> zyga: I'll try later today/tomorrow
<zyga> thanks
<zyga> mborzecki: what's the owner of the socket?
<mborzecki> zyga: the test user, it's a session service
<pstolowski> pedronis: thanks
<zyga> mborzecki: owned by 12345?
<mborzecki> zyga: yup
<zyga> mborzecki: can you try to run apparmor parser
<zyga> mborzecki: and get a pre-processed profile
<zyga> mborzecki: with all includes resolved
<zyga> mborzecki: it could be an arch bug in the include statements
<zyga> mborzecki: (in the things that get included)
<zyga> I'd tell you the command but I'm on fedora now
<zyga> mborzecki: if you get that please pastebin the result
<mborzecki> zyga: this shoudl be it https://paste.ubuntu.com/p/yNTxCKq5Wh/
<zyga> k
<zyga> mborzecki: nothing, it's good :/
<zyga> well
<zyga> magic
<mborzecki> it's 5.4.1 kernel, in case that matters
<pedronis> mvo: I did a pass on 7817
<zyga> mborzecki: is this a regression?
<mborzecki> hmmm, good question, there's isn't much of an older kernel in arch to try out ;)
<mvo> pedronis: THANK YOU
<mvo> pedronis: :)
<mvo> pedronis: in a meeting now, but will jump to it right after
<zyga> mborzecki: is this a new test?
<mborzecki> zyga: yes, #7555
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<zyga> Aha
<zyga> Does it pass on tumbleweed?
<mborzecki> zyga: it's supposed to run on ssytems with strict confinement, i recommended looking at specific features, jdstrand pointed me to relevant part of kernel where unix socket connect should be mediated as file operations, but it's failing (?)
<mborzecki> zyga: i think we degrade the apparmor profile on TW
<zyga> We do not
<pedronis> mvo: I don't understand why we need MakeRunnable now that we pass options to MakeBootable
<pedronis> well, we don't but we could/should
<ijohnson> pstolowski: mborzecki: does this PR description look ok now? https://github.com/snapcore/snapd/pull/7843#issue-349074423
<mup> PR #7843: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7843>
<pstolowski> ijohnson: yes
<mborzecki> ijohnson: yeah, land it
<pedronis> zyga: what is the purpose of decode-mounts-opts ? I don't see it invoked anywhere
<ijohnson> done
<mup> PR snapd#7843 closed: tests/cmd/snapctl: unset SNAP_CONTEXT for the suite <Simple ð> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7843>
<mborzecki> pedronis: iirc the pr using that is still on review
<mvo> pedronis: I'm happy to change it so that we can use MakeBootable() for that we need a way to say if it's from PrepareImageTime or from install time. I could add something to "BootsWith" or I could add "opts *bootloader.Options" to MakeBootable (but then we would import bootloader in higher level code :/
<mvo> pedronis: anyway, open for suggestions
<mvo> pedronis: also I should probably reply in the PR instead of here - let me do that - sorry
<mborzecki> zyga: jdstrand: behaves the same on tumbleweed with 5.3 kernel
<jdstrand> mborzecki: ack, I'm looking at this now. I'm going to distill this down and then talk to jj about it when he comes online
<pedronis> mvo: I'm confused because the other PRs has TODOs like:  I don't understand why we need MakeRunnable now that we pass options to MakeBootable
<pedronis> mvo: oops
<pedronis> mvo: TODOs like: // XXX: allow to override this
<jdstrand> mborzecki: I suggest moving on for the time being until I circle back
<mborzecki> jdstrand: ack, need to take my son to the swimming pool, so eod'ing anyway
<mvo> pedronis: my original idea was to (re)use MakeBootable but I'm not sure it's the best fit anymore. But happy to chnage the PR accordingly. we just need to decide how the options are passed
<mborzecki> jdstrand: the preprocessed apparmor profile from arch https://paste.ubuntu.com/p/yNTxCKq5Wh/
<pedronis> mvo: I'm also not sure I understand why we need to pass RecoverySystem
<pedronis> mvo: yes, we need to agree on what we want
<mvo> pedronis: I can leave this out for now, it will become clearer late, we will need to write the "modeenv" file on the real run
<mvo> pedronis: the modeenv will contain the recovery_system because when the "run" system boots it will also seed itself and it needs to know what to seed (or am I missing something?)
<pedronis> mvo: ok
<mvo> pedronis: sorry, maybe I'm slicing it too much :/ I can make a bigger PR that includes more maybe?
<pedronis> mvo: I think I'm confused because we have two many half done things in this area
<pedronis> and they start not to match
<mvo> pedronis: yeah, maybe it's better to create a big(ger) PR?
<pedronis> mvo: or try to go step by step
<mvo> pedronis: that implements most of the MakeBootable/MakeRunnable
<pedronis> instead of rush ahead
<pedronis> we haven't even set up the install system full correctly or not?
<mvo> pedronis: you mean, wait until e.g. 7817 is merged before opening the next one?
<pedronis> mvo: do we have the boot until install fully working?
<pedronis> there is quite a few XXX in 7817
<pedronis> mvo: how do we find the kernel?
<mvo> pedronis: I think with 7817 we should have a working boot into install mode
<pedronis> there
<mvo> pedronis: kernel is found via grub.cfg from the recovery
<mvo> pedronis: it will scan the disk and pick the kernel it finds
<pedronis> maybe the issue is also that the grub cfg are still in the gadget
<pedronis> and I haven't looked at them in a bit
<pedronis> mvo: anyway meeting time
<mvo> pedronis: indeed
<pstolowski> hmmm travis is taking ages..
<pedronis> 7768 needs a 2nd review
<pstolowski> travis is spinning on 'job received', and not progressing
<ijohnson> pstolowski: I've seen that before it for some reason always seems to happen after EOD for EU timezones :-/ my working guess is that the nightly jobs are configured to run after EOD for someone in EU and so PR's submitted during that time have to wait for those nightly jobs
<ijohnson> cachio: do you know when the nightly spread-cron tasks are configured to run ?
<ijohnson> pedronis: I can do a review of #7768 in my PM I think
<cachio> which task ?
<pedronis> ijohnson: great
<mup> PR #7768: interfaces: add raw-volume interface for access to partitions <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7768>
<pstolowski> cachio: https://github.com/snapcore/snapd/pull/7771
<ijohnson> cachio: any of them?
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<cachio> ijohnson, this is the main project
<cachio> https://github.com/snapcore/spread-cron
<cachio> then in any branch there is a task
<ijohnson> cachio: right but when do the tasks run?
<cachio> ijohnson, it is defined in a file, this is an ecxample https://github.com/snapcore/spread-cron/blob/gce-update-centos-7/options
<pstolowski> ijohnson, cachio may i ask either of you to retry https://github.com/snapcore/snapd/pull/7771 some time later and land if it's green?
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<cachio> ijohnson, this is another example https://github.com/snapcore/spread-cron/blob/snapd-trusty-sru/options
<ijohnson> pstolowski: sure
<pstolowski> ijohnson: thanks. i'm eod'ing\
<cachio> pstolowski, sure
<pstolowski> ty
<pstolowski> cu
<ijohnson> cachio: so that first one you posted has `$(date +%H%M) \< "1100"` is that evaluated on travis ?
<cachio> ijohnson, no
<cachio> this is evaluated in a vm in an internal env
<cachio> ijohnson, it evaluates every 10 minutes aprox any branch
<cachio> and executes the run-checks fiel
<cachio> file
<ijohnson> cachio: any idea what TZ that internal VM is on?
<cachio> ijohnson, no
<cachio> I can check
<cachio> give me 2 minutes
<ogra> a virtual one perhaps
<cachio> ijohnson, https://paste.ubuntu.com/p/NVSdkZJyk8/
<ijohnson> cachio: thanks, so it seems that if some of the tests are generally written to run after EOD on that machine they will run right around now
<cachio> ijohnson, nightly suite is configured like pattern_extractor="if [ $(date +%H%M) \< "0200" ]; then echo ""; else date +%Y%m%d; fi"
<cachio> the rest of the branches which run tests are configured based on other triggers
<cachio> for example
<cachio> the core snap was promoted to candidate
<cachio> so tests run using the new core snap
<ijohnson> cachio: sorry was at lunch, but so does that pattern mean that the job only runs when it is later than 0200 UTC? or it only runs when it is before 0200 UTC?
<cachio> ijohnson, it prints the date and it is executed when [ $(date +%H%M) \< "0200" ] is not true
<cachio> so it runs after 2am
<cachio> after 2am it prints the date
<ijohnson> so anytime later than 0200 is when the test gets executed?
<cachio> and it is compared with the previous date non empry
<cachio> and if it is different then the job is executed
<cachio> first try after 2am it will be executed
<ijohnson> but what controls when this check is performed then?
<cachio> ijohnson, the code where this is controlled is https://github.com/snapcore/spread-cron/blob/master/cron.sh
<cachio> we have a snap which runs this constantly
<ijohnson> I see, so it's not really deterministic when these jobs actually run, the pattern there really just defines when this agent shouldn't run the job
<cachio> ijohnson, it runs at some poing after 2am
<cachio> usually before 0230
<cachio> when the scirpt processs that branch
<ijohnson> cachio: ok thanks for explaining
<ijohnson> is that the only job that has a time of the day trigger? all other jobs are event based?
<cachio> ijohnson, why?
<cachio> do you need any change?
<ijohnson> cachio: I'm wondering because it seems somewhat frequently that we have the issue Pawel has this morning where Travis is stuck in the "job received" state sometimes for a couple hours
<ijohnson> I was thinking this was causing that somehow
<roadmr> jdstrand: hi there! is there any way to constrain kernel-module-control to only be able to load one specific module?
<cachio> all the jobs we use for update images are time base
<cachio> base are triggered on monday
<cachio> ijohnson, you can see here when the jobs ran https://travis-ci.org/snapcore/spread-cron/branches
<cachio> ijohnson, I jsut retrigger debian 9
<ijohnson> thanks for that cachio, it seems a bit like that isn't the cause of the "job received" issue
<cachio> ijohnson, perhaps it is caused because too many jobs running for the same project
<cachio> perhaps there is a limit
<cachio> not sure
<jdstrand> roadmr: no. but we have the kmod backend that is meant to load modules on behalf of the snap. what module?
<ijohnson> cachio: could be, anyways it seems Pawel's PR failed on Ubuntu due to mount ns changes, the cgroup mount now seems to be ro instead of rw as expected? was there recently an ubuntu 16.04 image change recently?
<roadmr> jdstrand: I don't know, but I can ask. The snap in question is domotzpro-agent-publicstore. I can point them to examples of using kmod to load the module they need, if you point me to some, in turn :)
<jdstrand> roadmr: well, it doesn't work quite like that. if we know the module, we can consider adding it to a new or existing interface
<jdstrand> roadmr: but it would be hardcoded in snapd, not something that they declare
<roadmr> right... I see
<jdstrand> roadmr: typically a brand store will do this via their kernel. there may be a way to do it via the gadget, but idk otoh
<roadmr> jdstrand: right, this is intended to be in the public store :/ so that's the boggle here
<roadmr> they said they'd look at options on their side including making do without the module loading capability, but were asking if we had something else to use
<pedronis> roadmr: we really need to understand a bit more what they are trying to do if they want to target the public store
<roadmr> jdstrand: fwiw this is a customer (domotz/fingbox) and they do have a brand store, but because reasons, they want this particular snap to be on the global store
<jdstrand> roadmr: it is hard to recommend something without knowing the module in question
<pedronis> just saying we need to load modules is too vague for that space
<roadmr> jdstrand, pedronis : ok, let me ask them for more details and get back to you
<jdstrand> pedronis: it is possible for use to have a generic interface that lists the modules to load as attributes and shove that into the kmod backend. not suggesting that, but this conversation made me think of that
<jdstrand> us*
<jdstrand> we protect those attributes via snap decl like with personal-files/system-files
<jdstrand> s/those attributes/that attribute/
<pedronis> jdstrand: yes, that's an approach, but we would still like to know whether a more specific or an addition to an existing interface would make more sense I think
<jdstrand> anyway, putting it out there for background thought
<pedronis> anyway even for that case we know the list of modules
<pedronis> *we need to know
<jdstrand> for sure. need to know the modules :)
<roadmr> I've asked, will wait for a reply from them folks :)
<jdstrand> roadmr: you might not suggest my otoh comment there at the end. I don't know if we want to go there
<jdstrand> I was more just mentioning that to pedronis as food for thought
<roadmr> jdstrand: I haven't offered anything concrete until I know more, just told them to get us more info so we can give them options that suit their use case
<ijohnson> jdstrand: quick question, do you think layouts should be allowed for new top-level directories in "/" ? I tried creating one and it failed because snap-update-ns isn't allowed to create a mimic on top of "/" and I'm not sure if this is intentional or a bug
<ijohnson> jdstrand: denial looks like type=1400 audit(1575575534.977:339): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.my-snap-name" name="/tmp/.snap/" pid=39112 comm="7" srcname="/" flags="rw, rbind"
<pedronis> ijohnson: it's a limitation of the current implementation
<ijohnson> pedronis: ah ok
<pedronis> in principle we could allow some subsets of layout at that level carefully
<pedronis> but needs implementation changes
<ijohnson> so it could work someday and is kind of a bug that it doesn't work today
<pedronis> it's kind of a bug, but given is top-level and doesn't work we haven't decided the exact policy
<pedronis> I mean in general is a limitation, specific instances might still not work
<ijohnson> oh actually if I had read the docs the doc does say that you can't do that
<pedronis> because of security/policy reasons once implemented
<ijohnson> perhaps what we should do is add a warning or fail during install/validation of a snap.yaml declaring those
<ijohnson> until the implementation could support it
<pedronis> ijohnson: yes, it is known not to work, so not surprised it is documented as such
<ijohnson> yes my fault for not reading docs closely enough :-)
<pedronis> ijohnson: saw your comment, did we hit another instance of the baseline of the mountspace checks changing behind our backs?
<ijohnson> pedronis: yes I think so
<pedronis> this is getting a bit tedious
<pedronis> maybe we should rethink how we compute the baseline
<ijohnson> pedronis: unless somehow snapctl is remounting cgroups /o\
<pedronis> I hope not
<pedronis> ijohnson: it's the kernel again
<pedronis> we decide to stick with the old one
<pedronis> but didn't
<pedronis> or something like that
<pedronis> cachio: did we re-build new images with the wrong kernel ^ ?
<cachio> pedronis, in bionic?
<cachio> pedronis, we should be using 4.15
<pedronis> cachio: seems xenial now
<cachio> pedronis, ah, I just updated bionic
<cachio> pedronis, I can update xenial as well
<pedronis> cachio: let me point to the failing PR
<cachio> I'll make the change
<pedronis> cachio: the issue is here:  https://github.com/snapcore/snapd/pull/7771#issuecomment-562283907
<mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
<cachio> pedronis, thanks
<cachio> I'll take a look to the image and I'll make the change to see if that fixes the issue
<cachio> pedronis, it is pretty similar to the issue we saw in bionib
<cachio> bionic
<pedronis> cachio: yes, that's why I asked about the kernel, it seems similar
<cachio> pedronis, xenial has 4.15.0
<cachio> the problem could be something else
<cachio> ijohnson, the problem in bionic was caused by the kernel v5.0
<cachio> in this case in xenial the kernel is 4.15
<cachio> so I am not sure if the problem could be different
<cachio> both mount-ns tests failed? or just 1?
<mup> PR snapcraft#2832 opened: appstream extractor: take xml comments into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2832>
<NickZ> Is there a way to get a snapcraft package to stage packages from a third-party repo?
<ijohnson> cachio: sorry multiple tests failed I don't remember all of the test names
<cachio> ijohnson, np, lets wait for the results again
<ijohnson> k
<cachio> ijohnson, 2019-12-05 20:28:10 Aborted tasks: 0
<cachio> 2019-12-05 20:28:10 Failed tasks: 1
<cachio>     - google:ubuntu-16.04-64:tests/main/mount-ns:inherit
<cachio> just one failed
<cachio> the other passed
<cachio> I think this is something new
<cachio> ijohnson, the images was updated  4 days ago
<cachio> so this is some new package or a change in the code
<ijohnson> hmm this does seem different from the bionic issue
<cachio> ijohnson, my PR also failed on that test
<ijohnson> well something updated it just seems a question of what updated
<mup> PR snapd#7853 opened: [RFC] boot,bootlaoder: setup the snapd_recovery_kernel grubenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7853>
<ijohnson> well after looking into it some more it seems like /sys/fs/cgroup _should_ be mounted ro, I'm not sure why our tests have it as being mounted rw
<ijohnson> I can submit a PR in a little bit updating the tests I think to unbreak master at least
<ijohnson> would be good to understand why it was measured as being mounted rw however
<cachio> ijohnson, perhaps we could review it with zyga tomorrow
<cachio> it is weird
<zyga> o/
<zyga> I'm back but too sleepy to work
<zyga> see you tomorrow
<zyga> ijohnson: I saw the failure
<stgraber> so recent core (snapd) now prevents installing lxd inside a lxd container, breaking our daily CI and probably a bunch of systems out there
<stgraber> jdstrand: as the only snap person who may still be awake, any idea of what changed in that last core (and snapd) update that could cause issues?
<roadmr> inception ð¤¯
<stgraber> as far as I can tell, it only affects the LXD snap and it may be apparmor related though I'm not getting any record denials
<stgraber> the culprit is snap-confine getting spawned and being told no by the kernel (looks like)
<stgraber> 2686  execve("/snap/core/8213/usr/lib/snapd/snap-confine", ["/snap/core/8213/usr/lib/snapd/sn"..., "snap.lxd.activate", "/usr/lib/snapd/snap-exec", "lxd.activate"], 0xc4203272c0 /* 19 vars */ <unfinished ...>
<stgraber> 2676  pselect6(0, NULL, NULL, NULL, {tv_sec=0, tv_nsec=20000}, NULL <unfinished ...>
<ijohnson> stgraber: I'm afk for a little bit but I'll be around a little later to discuss more
<stgraber> 2686  <... execve resumed> )            = -1 EACCES (Permission denied)
<ijohnson> stgraber: man page says that could also be due to the filesystem being mounted noexec, is that possible?
<stgraber> no
<ijohnson> stgraber: Could you post a full strace log?
<stgraber> pastebin rejects it, too large
<ijohnson> How large is the log? Could you email it?
<roadmr> aiee folks use one of the shared servers!
<roadmr> you both have access :)
<stgraber> ijohnson: http://paste.ubuntu.com/p/rDRxqrdXn9/
<stgraber> ijohnson: un-b64 and un-gz to get the original
<roadmr> clever solution :)
<stgraber> roadmr: pretty used to having to extract crap from random user systems behind a bunch of firewalls and such :)
<roadmr> haha
<ijohnson> stgraber: thanks I'll let you know if I figure anything else out, and make sure that the rest of the Snapd folks take a look in their morning
<stgraber> ijohnson: do you know what version of snapd used to be in core?
<stgraber> would make a local bisect a bit faster :)
<ijohnson> stgraber: when?
<stgraber> latest core updated snapd to 2.42.4, I'd like to know what the snapd version was prior to that in core, if it was 2.42.3 that'd make the diff pretty short
<mup> PR snapd#7854 opened: snap-confine: raise egid before calling setup_private_mount() <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7854>
<stgraber> looks like it was 2.42.1 looking at the previous version of the core snap on disk
<stgraber> that's unfortunate
<mup> PR snapd#7835 closed: gadget: add missing test for duplicate detection of roles <Simple ð> <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7835>
<roadmr> stgraber: confirmed, 16-2.42.1 was the previous on stable (e.g. revision 8039 for amd64)
<roadmr> stgraber: I looked at my release history for stable
<roadmr> current rev is 8213
<ijohnson> Sorry looks like roadmr beat me to it
<roadmr> ijohnson: stgraber beat us both to it :)
<stgraber> snap-confine apparmor change introduces a "deny unix," which may cause silent denials, not sure why it would trip on an execve though
<stgraber> but that's the main suspicious thing I'm seeing, so lets try reverting that first
<stgraber> root@c1:~# snap install lxd
<stgraber> lxd 3.18 from Canonicalâ installed
<stgraber> bingo
<ijohnson> Hmm that's odd
<ijohnson> Also odd that our tests didn't catch this we have lxd inside lxd tests
<ijohnson> (that supposedly work)
<stgraber> going to re-introduce that line to confirm that it fails again if I do so, just to make sure I didn't disable too much of apparmor by accident
<stgraber> nope, that's clearly the issue, re-introducing that line keeping everything the same causes the failure
<stgraber> it could be an apparmor parser bug, a kernel bug, ... but "deny unix," is clearly denying too much somehow
<jdstrand> stgraber: that explicit deny rule in snap-confine was always denied. that shouldn't change anything
<stgraber> jdstrand: it sure does somehow, and only in containers, so likely causing something interesting to happen in the kernel
<jdstrand> ie, it isn't a new thing being denied. it is just a new thing not being logged
<jdstrand> that is very surprising
<jdstrand> snap-confine had no unix rules to begin with
<jdstrand> apparmor_parser -p /var/lib/snapd/apparmor/profiles/snap-confine.core.8213 |grep unix
<jdstrand>     deny unix,
<jdstrand> stgraber: can you change that to an 'audit deny unix,'? or 'audit unix,'?
<stgraber> jdstrand: "lxc launch ubuntu:18.04 c1 -c security.nesting=true" and then "lxc exec c1 -- snap install lxd" will reproduce it
<stgraber> jdstrand: sure, I was actually looking for the syntax for that
<stgraber> jdstrand: really smells like a kernel bug, "audit deny unix," doesn't log anything but things now behave
<stgraber> I only see profile_load STATUS messages, no sign of anything else in there
<stgraber> removing the audit prefix and back to it failing
<NickZ> for the record, to stage packages from a third-party repository, do this: https://gist.github.com/NickZ/828be7ad23cd9d9c88b9ab0b3624bf44
<ijohnson> stgraber: so interesting thing I don't think our tests test snaps inside lxd inside lxd, we only test lxd inside lxd. I will make sure we have a regression test for this
<ijohnson> (well also snaps inside lxd directly)
<jdstrand> stgraber: where are you adjusting the rule, int he container?
<NickZ> i've heard that snaps have been broken on bionic lxd for a while now
<jdstrand> stgraber: basically, I can see things are broken, but can't fix it cause when I snap install in the container, the snap-confine profile is overritten and my changes are undone
<jdstrand> stgraber: fixing it on the host has no effect. what did you do?
<stgraber> ijohnson: the problem is installing lxd inside a lxd container, so in theory your test is already doing that
<stgraber> jdstrand: it's the profile in the container you need to fix
<jdstrand> right, and as soon as I do snap install, the fix is reverted
<ijohnson> stgraber: this is the test https://github.com/snapcore/snapd/blob/master/tests/main/lxd/task.yaml
<stgraber> jdstrand: I did: "cp /snap/core/8213/etc/apparmor.d/usr.lib.snapd.snap-confine.real ." then "vim" and finally "mount -o bind usr.lib.snapd.snap-confine.real /snap/core/8213/etc/apparmor.d/usr.lib.snapd.snap-confine.real", followed by a teardown to force a reload of the profiles
<stgraber> ijohnson: the problem I suspect is that you're testing the new snapd on the host
<stgraber> ijohnson: the issue happens when you run the new snapd in the container
<stgraber> hmm, no, you're installing the new snapd in there
<jdstrand> that's... weird. I wouldn't expect .real to have anything to do with it, but you gave me an idea. I can just copy /var/lib/snapd/apparmor/profiles/snap-confine... aside, modify it and load it
<stgraber> ijohnson: ah, the problem is that you're never actually installing lxd in lxd
<stgraber> ijohnson: your test creates a lxd container, updates snapd inside it and then installs test-snapd-sh
<stgraber> ijohnson: if you were to snap install lxd instead of test-snapd-sh on line 100, you'd have gotten the failure
<stgraber> jdstrand: I went with a naive "grep -r deny.*unix /snap/core", found the file that has the offending string and over-mounted it with a version which doesn't :)
<jdstrand> stgraber: what host are you on?
<stgraber> 18.04 LXD VM
<jdstrand> on an eoan host, it isn't working at all
<stgraber> Oh? As in broken on the host too?
<jdstrand> stgraber: no, it is fine on the host, but I can't get the nesting to work
<jdstrand> I'm trying in a vm
 * jdstrand tried with his lxd that was already configured
<NickZ> just curious, has anyone here ever successfully got mono to run in containment?
<jdstrand> stgraber: what is the output of aa-status in the container?
<jdstrand> ok, finally
<jdstrand> ijohnson: I downgrading to 8159 (2.42.2) and it does not have the unix rule. I then added to /var/lib/snapd/apparmor/snap-confine/foo 'deny unix,', the did apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap-confine* then tried to install lxd and it failed
<jdstrand> ijohnson: we should revert that rule. I'll need to investigate to see why it is failing
<jdstrand> ijohnson: this indeed is a kernel bug
<stgraber> jdstrand: how fast can we get a that line reverted in the stable snap?
<jdstrand> stgraber: that's an mvo question
<stgraber> Ok, I'll email mvo to make sure he's aware when he starts the day
<jdstrand> stgraber: please cc me and feel free to paste my comments above about downgrading and that I confirmed this is a kernel bug
<jdstrand> stgraber: you might cc jj as well
<stgraber> Will do, thanks
<jdstrand> it could be a parser bug too...
<jdstrand> anyhoo, thanks
<ijohnson> stgraber: jdstrand: I'll make sure mvo is aware
<jdstrand> stgraber: fyi, this is a more specific rule (ie, to  address the thing that prompted the PR in the first place): deny unix (receive, send) type=stream addr=none peer=(addr=none), and it also causes lxd to fail
<jdstrand> stgraber: I can pass that to jj if you already sent the email or don't want to integrate that detail
<stgraber> Having dinner will send email after and include that in
#snappy 2019-12-06
<mup> PR snapd#7855 opened: snap-confine: revert suppress noisy classic snap file_inherit denials <Simple ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7855>
<mup> PR snapcraft#2833 opened: Arnatious/remove rospack workaround <Created by Arnatious> <https://github.com/snapcore/snapcraft/pull/2833>
<mup> PR snapd#7856 opened: snap-confine: revert, with comment, explicit unix deny for nested lxd <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7856>
<mup> PR snapd#7857 opened: tests: update google ubuntu 16.04-64 expected host mount ns <Simple ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7857>
<mup> PR snapd#7858 opened: tests: add nested-lxd test to confirm lxd inside lxd works <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7858>
<mup> PR snapd#7855 closed: snap-confine: revert suppress noisy classic snap file_inherit denials <Simple ð> <â  Critical> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7855>
<mborzecki> morning
<mup> PR snapd#7846 closed: devicestate: add missing test for failing task setup-run-system <Simple ð> <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7846>
<mborzecki> mount-ns test failing on google?
<zyga> Gooos morning
<zyga> I saw that. Suspicious. Could be a test merged recently. Could be a package upgrade (though I doubt that)
<zyga> Oho
<zyga> Yesterday evening was eventful
<zyga> I need to scan the backlog
<zyga> But first... dog
<mborzecki> zyga: my best bet is the lxd test, but who knows, tryig main/tests/lxd right now
<sdhd-sascha> Good morning
<zyga> Do you have backlog to read?
<mborzecki> zyga: so on vanilla system it's 31 22 0:26 / /sys/fs/cgroup rw shared:9 - tmpfs tmpfs rw,mode=755
<mborzecki> zyga: in -shell-before of tests/main/lxd it's already 1 22 0:26 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:9 - tmpfs tmpfs ro,mode=755
<zyga> mborzecki: on which kernel
<zyga> mborzecki: systemd / kernel change  if /sys/fs/cgroup is ro or rw
<zyga> it used to be rw
<mborzecki> zyga: heh, the gcp one
<zyga> nowadays it is always ro
<zyga> perhaps that's  why
<zyga> are we consistently getting "new" behavior?
<zyga> if so let's just change the test and carry on
<mborzecki> zyga: but it's not consistent, a clean node has rw
<zyga> I'd only worry if half of the machines got one kernel and other half another
<mborzecki> zyga: also, the reboot variant assumes rw and observes rw on the host
<zyga> mborzecki: note, we do prepare.sh changes
<zyga> oh
<zyga> I'll dig in a moment
<zyga> need to get that dog out first
<zyga> there's some drama about apparmor bug last night
<mborzecki> zyga: yeah, saw the PRs
<mborzecki> zyga: also, don't know if you saw this comment from jdstrand https://github.com/snapcore/snapd/pull/7555#discussion_r354452340
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<sdhd-sascha> zyga: is there a summary (bug report) of the conversion. A year ago, i also had trouble to install kubernetes-suite with conjure-up. I also need to reparse apparmor at some installation step to make it work. But i didn't know if it was my fault, because i deployed everthing on zfs and kubernetes at this time the most kubernetes containers has missing zfs-utils
<mborzecki> zyga: it's systemd version
<pstolowski> mornings
<mborzecki> zyga: on a clean host it's 229-4ubuntu21.22, then it gets update dto 229-4ubuntu21.23
<mborzecki> pstolowski: hey
<pstolowski> mounts ns fun again
<mborzecki> zyga: still, it's a bit of a myster why the mount-ns:reboot works
<mborzecki> pstolowski: yeah
<mborzecki> pstolowski: it's friday, some critical fix in a PR, and mount-ns failing, i.e. business as usual
<mborzecki> zyga: hahah, soo, after a reboot it's back to rw
<mborzecki> zyga: and only gets switched to ro after systemctl daemon-reexec, wtf
<pstolowski> can we disable this test until a fix is ready to unblock landings?
<zyga> re
<zyga> mborzecki: maybe compund bug
<zyga> compound*
<zyga> perhaps the fixes we do ought to be each-boot and are first-boot
<mborzecki> zyga: what fixes?
<zyga> mborzecki: we do, or did some project wide changes, let me find that part
<mborzecki> mvo: hey
<mvo> hey mborzecki
<zyga> hey mvo
<mvo> hey zyga
<mvo> how are you guys?
<zyga> winter is here
<mvo> I'm tired, tried to explore some ideas
<pstolowski> hey mvo o/
<mvo> last night
<mvo> but only medium successful :/
<mvo> hey pstolowski !
<zyga> other than that I wanted to swap off today
<zyga> what did you try mvo?
<mvo> zyga: ok
<zyga> (but no swap because omg master red)
<mvo> zyga: oh?
<zyga> mborzecki: tests/lib/prepare-restore.sh
<mvo> pstolowski: is 7771 ready?
<mvo> I still want to branch 2.43 :)
<zyga> mborzecki: look at line 215
<zyga> we undo lxd changes
<zyga> that's only once on 1st boot
<zyga> maybe that has consequences?
<pstolowski> mvo: thanks for asking.. it is, but master is broken
<zyga> mborzecki: we do -o remount
<zyga> mborzecki: we don't do -o remount,ro -- maybe that makes it rw?
<mborzecki> zyga: i don't think so, i have a clean host, after reboot i have rw, issue systemctl daemon-reexec and i have ro now
<mvo> pstolowski: ok
<zyga> ooooooooh
<zyga> mborzecki: so
<zyga> mborzecki: maybe that's just new systemd
<zyga> it does do ro on /sys/fs/cgroup on modern systemd
<mvo> zyga: anything we can do quickly to unbreak master? any test to skip for now until we have a solution?
<mborzecki> zyga: it's triggered in the test, because we install/upgrade systemd as a build ependency, and postinst runs daemon-reexec
<zyga> mvo: yes, we can disable mount-ns test
<mborzecki> zyga: also why the :reboot variant works
<zyga> it picked up something weird
<zyga> mborzecki: that's curious, no explanation there
<pstolowski> can we disable the mount-ns test until a fix is ready to unblock landings? or is there more?
<pstolowski> zyga: ^
<mborzecki> pstolowski: yeah, i think so
<zyga> pstolowski: that's one way, yeah
<zyga> mvo: did you see last night chat between jdstrand and stgraber?
<mvo> zyga: I did not
<zyga> there's some kernel bug drama and broken lxd
<zyga> mvo: please scan that - I bet it affects the releaase
<pstolowski> zyga, mvo, mborzecki  ok, i'll prep a PR
<zyga> pstolowski: thanksI
<mvo> pstolowski: thank you
<zyga> I will read the backlog now
<mborzecki> zyga:  this is the changelog https://paste.ubuntu.com/p/zMvnwTHrDH/
<zyga> nothing scary there
<mvo> hm, looks harmless
<mborzecki> meh, there's no log or anythin that systemd remounts /sys/fs/cgroup
<zyga> ijohnson: we don't have nested lxd tests AFAIK
<mup> PR snapd#7859 opened: tests: disable mount-ns test on 16.04 for now <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7859>
<mborzecki> so we should probably be seeing ro after the reboot, but it's rw
<mborzecki> btw. did you gus notice that the lxd test is not run on ubuntu-19.* ?
<pstolowski> mborzecki: oh
<zyga> mvo: you have mail
<zyga> mvo: look for a message from stgraber please
<mborzecki> pstolowski: it lists only this [ubuntu-16*, ubuntu-18.04*, ubuntu-2*, ubuntu-core-*]
<pstolowski> yeah
<zyga> mvo: we need to revert one line for the next release to unbreak lxd
<zyga> mvo: and to check it we need to install lxd inside lxd
<zyga> mvo: and then run snaps in the 2nd nested lxd to confirm
<zyga> mborzecki: can you expand that to more systems please, it's likely related to the bug
<mvo> zyga: ok
 * mvo looks
<zyga> mvo: e7afbc34b1d630aeae4a7d20c34da75f4cb67546
<zyga> mvo: there we need to  remove the "deny unix," rule
<zyga> that's all
<zyga> the regression test is nested lxd
<zyga> I'll be back in 20 minutes, need to handle something at home
<pedronis> hi
<pstolowski> hi pedronis
<mvo> zyga: uh, yeah, just reading
<mvo> zyga: sucks :(
<mvo> zyga: shows once more that dot releases can't be conservative enough :(
<mborzecki> pedronis: hey
<pedronis> mvo: seems we need a .5, also master is broken, see #7857 #7859
<mup> PR #7857: tests: update google ubuntu 16.04-64 expected host mount ns <Simple ð> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7857>
<mup> PR #7859: tests: disable mount-ns test on 16.04 for now <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7859>
<zyga> mvo: kernel bugs are just bugs but yeah
<mvo> pedronis: yes on both counts
<mvo> pedronis: I will take care of this this morning
<pedronis> mborzecki: if I understand correctly we are not sure about 7857 and your are looking into that?
<pedronis> so we should go for 7859 for now?
<mvo> I am in favour of 7859 for now to unblock things while it's investigated
<pedronis> mvo: it's fine, trying to understand where we are, this mount-ns failures are starting to get a bit annoying
<mborzecki> pedronis: yes
<pedronis> mvo: not the most high prio right now, but I did leave comments late last night on your late PR(s)
<mvo> pedronis: thank you so much
<mvo> pedronis: will try to get to it as soon as I can. sorry that it's not easy :/
<pedronis> np, let's try to get master green and .5 ready
 * pedronis is also not feeling 100% today, not sure why/what
<mvo> pedronis: just read your comment, makes a lot of sense
<pstolowski> pedronis: yep (about mount-ns test). it's fine to have a test like this but it seems to be picking platform changes which are more frequent than expected, rather than our bugs. this area is unit-tested, so perhaps this test should be run nightly
<zyga> re
<zyga> pstolowski: we can also tweak the test to skip certain areas
<pstolowski> zyga: that's an option too. it should probably be less picky about flags on the filesystems that are not controlled by us
<zyga> pstolowski: it's all a learning exercise, we figure out as we go what is broken
<zyga> mborzecki: do you need a hand on that flag mystery or can I focus on something else?
<mup> PR snapd#7261 closed: interfaces/serial-port: support pci bus serial-port with HotplugKey() <â Blocked> <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7261>
<sdhd-sascha> Chipaca: would it be ok, to build spread snap on core18 ?
<Chipaca> sdhd-sascha: why do i get the impression you're breadth-first digging all the rabbit holes?
<sdhd-sascha> Chipaca: just for learning. You mention yesterday, that the snap needs a update.
<zyga> brb, rebooting
<Chipaca> sdhd-sascha: the updated snapcraft.yaml I have here is base:core18
<pedronis> mborzecki: we are getting failures on selinux-clean
<pedronis> https://api.travis-ci.org/v3/job/621494044/log.txt
<pedronis> that are failing on the disable mount-ns PR
<pedronis> pstolowski: ^
<sdhd-sascha> Chipaca: does your snapcraft.yaml has kvm inside ? then i could took this and experiment.
<Chipaca> sdhd-sascha: it does not, no :)
<Chipaca> sdhd-sascha: i can push what i have here so you start from it
<sdhd-sascha> Chipaca: ok. Yesterday, i only added git and gcc for core18 on multipass/qemu.
<pstolowski> pedronis, mborzecki mhm.. looking
<mborzecki> pstolowski: i think the policy needs to beupdated
<pstolowski> mborzecki: yes, i'm just wondering what changed that triggered it\
<mborzecki> pstolowski: i think it's the interfaces-kvm test that ran before, the kvm inteface writes out a modprobe conf file that loads the relevant kvm driver
<zyga> mborzecki: I'm doing other things, assuming you are good
<mborzecki> pstolowski: i guess you can restart the travis job, and open a fix in a separate PR (or i'll do it after the meeting)
<zyga> mborzecki: please drag me back if you need assistance on anything
<zyga> trying to cut the number of my open branches
<pstolowski> mborzecki: ok, let me try
<pstolowski> mborzecki: ok, i've the policy update, will give it a try and wait for #7859 (in case it needs to go together)
<mup> PR #7859: tests: disable mount-ns test on 16.04 for now <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7859>
<zyga> pstolowski: thank you for a targeted patch!
<pedronis> zyga: are you going to force push again against --explain? I might get to do an actual review pass today
<zyga> pedronis: not anymore, I just changed where the spread test runs to limit it to ubuntu classic 64
<pedronis> ok
<mborzecki> pstolowski: ok, thanks!
<mborzecki> zyga: btw. another data point, clean cloud image from cloud-images.u.c has ro mode after booting
<mborzecki> quick errand, back in 30
<zyga> that's good, that's what I would expect
<mborzecki> zyga: makes me wonder, why our spread images have rw, obviously the kernel is different, but i would expect systemd to apply very specific mount options when setting up /sys/fs/cgroup
<zyga> mborzecki: yeah, it does
<zyga> I read that part of systemd source code
<zyga> mborzecki: two ideas: cloud agent
<zyga> mborzecki: or custom kernel playing a factor
<mborzecki> zyga: you mean some gcp cloud agent? bc i'm using cloud-init under qemu too
<mborzecki> brb
<zyga> yes
<mup> PR snapd#7859 closed: tests: disable mount-ns test on 16.04 for now <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7859>
<mup> PR snapd#7860 opened: selinux: update policy to allow modifications related to kmod backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7860>
<pedronis> mborzecki: you can try to run the tests with an error in the early prepares and see how the world looks there
<mborzecki> re
<mborzecki> pedronis: i'm using https://github.com/bboozzoo/spread-mini to spin up the node without any of our test setup
<pedronis> ah
<mvo> mborzecki: which test was it again that caused the selinux denial that was just fixed?
<mborzecki> mvo: interfaces-kvm
<mvo> mborzecki: ta
<pstolowski> mvo: i think it's a good idea to have selinux check in kvm-interfaces
<mvo> pstolowski: thank you
<sdhd-sascha> Chipaca: if you have pushed, maybe in a feature-branch. you could inform me. I just cleanup git-history and build a current sway version
<Chipaca> sdhd-sascha: https://github.com/chipaca/spread/tree/update-snapcraft-yaml
<zyga> I'll be right back, I'll make something warm to drink
<mup> PR snapd#7771 closed: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7771>
<mup> PR snapd#7860 closed: selinux: update policy to allow modifications related to kmod backend <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7860>
<mup> PR snapd#7861 opened: tests: check for SELinux denials in interfaces-kvm spread test <Simple ð> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7861>
<mup> PR snapcraft#2824 closed: Support for go.mod <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2824>
<mup> PR snapcraft#2832 closed: appstream extractor: take xml comments into account <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2832>
<mup> PR snapcraft#2822 closed: xattrs: ignore errors if SNAPCRAFT_BUILD_INFO is unset <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2822>
<mup> PR snapcraft#2830 closed: elf: properly handle corrupted ELF files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2830>
<mup> PR snapd#7856 closed: snap-confine: revert, with comment, explicit unix deny for nested lxd <Simple ð> <â  Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7856>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7856#issuecomment-562517492
<mup> PR #7856: snap-confine: revert, with comment, explicit unix deny for nested lxd <Simple ð> <â  Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7856>
<zyga> mvo: do we plan to add this?
<mvo> zyga: add what exactly?
<zyga> mvo: a spread test verifying that this is fixed,
<zyga> mvo: a lxd inside lxd
<Tuor> Hi, I just install vlc with snap on a kubuntu 19.10. My mouseppointer changes when it hovers over the vlc window. Can I keep my normal mousepointer somehow?
<mvo> zyga: it's running in master
<zyga> mvo: I don't follow, sorry
<zyga> mvo: are you saying we have that test already?
<zyga> mvo: a test running nested lxd
<zyga> Tuor: hey, this is a known bug
<zyga> Tuor: I can refer you to kenvandine
<Tuor> Shall I upvote a bugrequest or something?
<Tuor> *bugreport
<mvo> zyga: sorry in a meeting
<zyga> mvo: I think we don't have that test, please double check that we add one before doing a .5
<zyga> mvo: or we may realize more is broken and .6 is required
<zyga> Tuor: I don't know where it is tracked, please ask kenvandine for details
<Tuor> kenvandine: I encountered a known bug, that my mouse pointer changes when I use the vlc snap. Where can I report a bug or where should I upvote?
<mborzecki> anyone up for a 2nd review of https://github.com/snapcore/snapd/pull/7821 ?
<mup> PR #7821: interfaces/seccomp: parallelize seccomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
<pstolowski> mborzecki: yeah, i'll, was meaning to
<pedronis> zyga: Ian wrote one I think
<pedronis> zyga: https://github.com/snapcore/snapd/pull/7858
<mup> PR #7858: tests: add nested-lxd test to confirm lxd inside lxd works <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7858>
<pedronis> it needs reviews
<zyga> pedronis: that's good, we should ensure it passes with updated master
<zyga> yep
<pedronis> zyga: does #7830 need jdstrand review? I would say no but open otherwise... or just your re-review
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<mborzecki> pstolowski: cool, thnanks!
<mvo> zyga: sorry, was in a meeting - 7858 is the one I had in mind
<zyga> pedronis: checking
<mvo> zyga: i.e. we have a test for this
<mvo> zyga: in a PR
<mvo> zyga: but it's incomplete, see PR
<mup> PR snapd#7862 opened: release: 2.42.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7862>
<Chipaca> woo! got an appointment with the orthopedician! woo
<Chipaca> with xmas coming up i was sure i was going to get punted into the new year
<mborzecki> heh, our test cleanup, or lack thereof, keeps on giving
<mvo> mborzecki: hm?
<mvo> mborzecki: more catastrophies?
<mborzecki> mvo: yeah, though suprised this one didn't happen earlier, the failure in selinux-context in 7570 is install-socket-activation test leaking socket units apparently
<mborzecki> and we're probably missing cleanup for sockt files too, meh
<mup> PR snapd#7767 closed: tests: run snap-set-core-config on all core devices <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7767>
<mup> PR snapd#7863 opened: interfaces/builtin: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>
<Chipaca> huh, firefox crashed trying to get to the meet
<mup> PR snapd#7864 opened: cmd/snap-mgmt, packaging/postrm: stop and remove socket units when purging <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7864>
<pstolowski> https://github.com/snapcore/snapd/pull/7861 needs 2nd review (trivial)
<mup> PR #7861: tests: check for SELinux denials in interfaces-kvm spread test <Simple ð> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7861>
 * zyga breaks for food
<pstolowski> thanks ijohnson !
<mup> PR snapd#7861 closed: tests: check for SELinux denials in interfaces-kvm spread test <Simple ð> <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7861>
<mborzecki> off to pick up the kids
 * cachio lunch
<pedronis> pstolowski: thx for the card
<pedronis> ijohnson: will you get to 7768 today?
<ijohnson> pedronis: yes I will look at it now; sorry I didn't have time yesterday with the k8s stuff and then this lxd issue
<pedronis> np, thx
<mup> PR snapd#7858 closed: tests: add nested-lxd test to confirm lxd inside lxd works <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7858>
<mup> PR snapd#7857 closed: tests: update google ubuntu 16.04-64 expected host mount ns <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7857>
 * Chipaca goes for tea
<ogra> is there an api call that would trigger a restart of snapd ? i.e. like https://github.com/snapcore/snapd/wiki/REST-API#request-2 but with snapd as the snap ? or is that blocked
<zyga> re
<zyga> what should I review?
<ogra> (this is obviously a core18 and beyond question where snapd is its own snap)
<ogra> hmm, k ... i think this answers it ...
<ogra> $ snap restart snapd
<ogra> error: snap "snapd" has no services
<zyga> jdstrand: fyi https://github.com/snapcore/snapd/pull/7850/files#r354888954
<mup> PR #7850: apparmor: allow 'r' /sys/kernel/mm/transparent_hugepage/hpage_pmd_size <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7850>
<pedronis> zyga: #7830 needs your re-review
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<zyga> I'm  doing that now :)
<zyga> pstolowski, pedronis: https://github.com/snapcore/snapd/pull/7830/files#r354891136
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<pstolowski> zyga: ty
<pstolowski> btw i'm looking at your uio iface
<zyga> cool :)
<zyga> pstolowski: one thing to keep in mind is that it must grant mmap access to /dev/uioN
<zyga> I fixed that but missed it in the initial testing because the test tool didn't require that
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7830#pullrequestreview-328280697 +1
<mup> PR #7830: interfaces: include hooks in plug/slot apparmor label <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7830>
<zyga> pstolowski: let me know if you want to work on the test device remotely
<jdstrand> zyga: responded, thanks
<zyga> jdstrand: cool :-)
<jdstrand> zyga: it was even in the commit missage for snaap-update-ns... not surre why I put it there :)
<jdstrand> message*
<zyga> haha, no worries
<zyga> I'm happy I asked a meaningful question :)
 * ijohnson needs to go downtown for an hour or so, probably will miss tgif
<zyga> take care ijohnson
<ijohnson> zyga: I'll be back! And I realize in retrospect that phrase is a bit loaded, it's just some paperwork things :-)
<zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/7863 -- thank you for the quick review!
<mup> PR #7863: interfaces/builtin: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7825#issuecomment-562645242
<mup> PR #7825: many: use transient scope for tracking apps and hooks <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mvo> zyga: oh, it is? sorry, then let's remove it
<zyga> yeah
<mvo> zyga: sorry, too much going on at the same time
<zyga> it's a nop without it
<zyga> no worries
<zyga> I +1 the idea initially because it feels safe
<pedronis> it's still not merge ready
<pedronis> though
<zyga> but I think it's not unsafe in principle
<zyga> that's true :)
<pedronis> it's unlikely to get merge ready by Mon or Tue
<pedronis> tbh
<zyga> pedronis: what is missing there?
 * zyga EODs and goes for a walk
<mup> PR snapd#7858 opened: tests: also check nested lxd container <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7858>
<ijohnson> mvo / pedronis: should I open a PR for the lxd snap regression test against release/2.42 ?
<mup> PR snapd#7847 closed: snap-bootstrap: parse seed if either kernel or base are not mounted <UC20> <Created by xnox> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7847>
<cmatsuoka> cachio: did you notice random test failures on debian recently?
<cachio> cmatsuoka, do you have a link?
<cachio> cmatsuoka, didn't see that
<cmatsuoka> cachio: I just restarted it but if it fails again I'll let you know
<cachio> cmatsuoka, nice, thanks
<ijohnson> hey jdstrand you around for a couple minutes to discuss the kubernetes-worker snap ?
<sdhd-sascha> zyga: yesterday, i tried to build a *.deb package for snapd on launchpad.net with a receipe. Is the release-deb also build on launchpad, or ... ?
<sdhd-sascha> zyga: oh, wait... maybe it was build with snapcraft... i looking for it
<sdhd-sascha> niemeyer: hello, sorry for mention you. Just try to build a *.deb package of snapd for testing. https://code.launchpad.net/~sdhd/+snap/snapd-daily
<sdhd-sascha> But there was no place to configure the target ppa ...
<sdhd-sascha> Inside of the snap-build process, there i found: dpkg-buildpackage: source package snapd
<sdhd-sascha> niemeyer:
<sdhd-sascha> zyga: My fault. I think i found it
<jdstrand> ijohnson: I am here. what's up?
<jdstrand> ijohnson: (sorry I missed the initial question)
<ijohnson> no it's okay I don't think I asked the actual question here
<ijohnson> so I have this kubernetes-worker snap here and I was trying to figure out why the containers launched by containerd can't create their own top level directories because AppArmor denies it
<ijohnson> it was odd because docker containers are allowed to do this, and after a while it occured to me that docker will perform a profile transition to the docker-default profile which doesn't constrain the container by AppArmor for top level directories, etc.
<ijohnson> after looking some more, it appears that containerd doesn't by default transition the containers to an apparmor profile, but I was wondering what your thoughts are if we somehow got the kubernetes-worker snap to do that?
<ijohnson> do you think it's okay to have containers launched by the kubernetes-worker snap be confined by the docker-default profile
<ijohnson> ?
<jdstrand> ijohnson: the profile was designed with this in mind. it is supposed to do this: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/docker_support.go#L160
<jdstrand> ijohnson: when I did the interface initially with microk8s, I made it microk8s load the profile in one of the wrappers so it was able to transition
<ijohnson> nice
<jdstrand> ijohnson: I thought we did that with kubernetes-worker as well. I distinctly recall pointing out this should be done. and, iirc, containerd would use the profile if it was loaded
<jdstrand> ijohnson: but wouldn't load it itself. I might be misremembering, but I thought that was the case
<ijohnson> jdstrand: that might be the case, I'm not sure
<jdstrand> ijohnson: regardless, yes, it is expected that the containerd app can load the profile and transition containers to it
<jdstrand> how to make it do that is another thing... :)
<ijohnson> I'm not running the full setup, I'm just trying to drive containerd manually and noticed it doesn't do this by default
<ijohnson> ok, well my question for you was if this is okay, I assumed it was because it's in the policy but wanted to be sure :-)
<ijohnson> thanks
<jdstrand> ijohnson: let me see if that code is in microk8s...
<jdstrand> ijohnson: it is not only ok, it is recommended and best practice :)
<ijohnson> :-)
<jdstrand> ijohnson: it does mean that containerd is more privilged, but the containers are less, and the container attack surface so what's most important
<ijohnson> right
<jdstrand> s/so/is/
<ijohnson> jdstrand: I don't see anything in the kubernetes-worker snap to load that profile
<ijohnson> joedborg: any idea on where that bit of code might have went in the kubernetes-worker snap?
<jdstrand> which is why I clal the docker (and containerd) policy 'advisory', since they can load prolicy
<jdstrand> policy
<jdstrand> and transition to it
<ijohnson> brb
<joedborg> ijohnson: do you mean this bit? https://github.com/charmed-kubernetes/snap-kubernetes-worker/blob/master/wrappers/containerd.wrapper#L13
<jdstrand> ijohnson: https://github.com/ubuntu/microk8s/blob/feature/strict-v2/microk8s-resources/containerd-profile and https://github.com/ubuntu/microk8s/blob/feature/strict-v2/microk8s-resources/wrappers/run-containerd-with-args#L11
<jdstrand> joedborg: if you run 'sudo aa-status', you see cri-containerd.apparmor.d listed?
<joedborg> no, i don't seem to
<joedborg> https://www.irccloud.com/pastebin/IVv1DKT0/
<joedborg> jdstrand: ^
<ijohnson> joedborg: ah yes I didn't see that for some reason
<jdstrand> joedborg: I think there is something wrong then with the startup. that profile needs to be loaded every time containerd starts
<joedborg> ijohnson: it is missing from the eks branch since yesterday because i was getting errors
<jdstrand> also, fyi I found https://kubernetes.io/docs/tutorials/clusters/apparmor/
<ijohnson> jdstrand: with the eks branch that joedborg showed me yesterday I see that profile being loaded into the kernel
<jdstrand> that hints at defaults and things and might provide some insight if the pods still aren't running in cri-containerd.apparmor.d once it is confirmed that it is loaded in the kernel
<ijohnson> so I think that parts fine, it seems now that the issue is just in configuring $CONTAINER_TECHNOLOGY to actually run under that profile
<ijohnson> https://www.irccloud.com/pastebin/fTe1mJiV/
<jdstrand> ijohnson: ok, then if it is loaded, you might be able to use the above link to make k8s put it in that profile. there is probably something somewhere for defining  the default profile to use
<jdstrand> ijohnson: ok, cool, and yes
<jdstrand> https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/security/hello-apparmor.yaml
<ijohnson> joedborg: have you looked at https://aws.amazon.com/blogs/opensource/using-pod-security-policies-amazon-eks-clusters/ ?
<jdstrand> (from the above link)
<ijohnson> that seems to imply that the pods metadata stuff from the generic kubernetes stuff can be configured in EKS
<ijohnson> thanks jdstrand I saw that link earlier today too
<jdstrand> ijohnson: nice find
<ijohnson> BTW word of caution: don't go looking for containerd's CLI tool "ctr" docs or examples because they don't exist haha
<ijohnson> (I was trying to be sneaky and just skip the k8s part and just reproduce the issue with ctr, but that doesn't seem to be the way to go)
<jdstrand> oh yeah, I had some trouble with that in the past
<joedborg> ijohnson: i did briefly, but saw that `Read Only Root Filesystem:              false` so moved on
<joedborg> ijohnson: jdstrand: ctr is also a massive trap because it behaves completely differently to anything else that drives containerd (all over CRI)
<ijohnson> oh hmm so does the psp stuff work by some aws agent running on the pod to enable these things? if so that's really unfortunate
<jdstrand> ijohnson: I have this in my notes when I did a seccomp security update: https://paste.ubuntu.com/p/P6M4hhkphw/
<jdstrand> ijohnson: but based on what joedborg just said, you may want to ignore that :)
<ijohnson> jdstrand: yes `runc spec` is a good trick until you realize how much other config settings $OTHER_CONTAINER_TECHNOLOGIES set when they drive CRI like joedborg just said
 * jdstrand nods
<jdstrand> this was just for the deb
<jdstrand> ijohnson: I like when you say $CONTAINER_TECHNOLOGY and $OTHER_CONTAINER_TECHNOLOGIES
<jdstrand> it is just right ;)
<ijohnson> :-) there's just so so so many of them
<jdstrand> indeed :)
<joedborg> ijohnson:
<joedborg> jdstrand:
<joedborg> `apparmor_parser -r $SNAP/containerd-profile` i took this out because i started getting `permission denied` when it runs the wrapper
<joedborg> even if i put sudo in front of it
<joedborg> so i think an apparmor rule (to allow to run this) has gone missing
<joedborg> that's using the custom snapd
<jdstrand> joedborg: you can't put sudo in front of it
<jdstrand> joedborg: can you: sudo snap run --shell snap.kubernetes-worker.conttainerd
<jdstrand> joedborg: then apparmor_parser -r $SNAP/containerd-profile
<jdstrand> joedborg: and ive me the denials?
<jdstrand> joedborg: (from journalctl)
<jdstrand> ijohnson, joedborg: not, I have a very hard stop in 15 minutes, but could circle back
<jdstrand> note*
<joedborg> jdstrand: okay, i've got that now
<joedborg> https://www.irccloud.com/pastebin/2q7ch6D4/
<jdstrand> jo
<jdstrand> joedborg: I'm confused. I thought you said from within the snap it didn't work?
<joedborg> jdstrand: it wasn't, then i ran it manually like you suggested and it did
<jdstrand> joedborg: I was wanting you to run apparmor_parser -r $SNAP/containerd-profile from under sudo snap run --shell
<jdstrand> jo
<jdstrand> dang it
<joedborg> but `Dec 06 20:54:31 ip-192-168-35-165 kubernetes-worker.containerd[18362]: /snap/kubernetes-worker/x1/bin/containerd.wrapper: line 13: /sbin/apparmor_parser: Permission denied`
<jdstrand> joedborg: you ran it from under snap run --shell?
<joedborg> yeah
<jdstrand> joedborg: ok, between that and that ijohnson said it loaded for him, I'm going to chalk that up to the docker-support interface wasn't connected at the time of that denial
<jdstrand> /sbin/apparmor_parser ixr,
<jdstrand> that is in the docker-support policy ^
<joedborg> jdstrand: ah yes, quite possibly
<joedborg> either way, i'm still getting the RO filesystem errors
<jdstrand> joedborg: I didn't look at the code for the kubernetes-worker, but be sure that this apparmor_parser invocation is not in a configure hook or under some conditional where it only sometimes loads the policy
<jdstrand> joedborg: for the rofs issues, this is where ijohnson can come in
<joedborg> jdstrand: it's with the containerd wrapper, so run everytiime containerd is (re)started
<jdstrand> joedborg: perfect
<ijohnson> (in meeting)
<joedborg> https://www.irccloud.com/pastebin/50YgamaD/
<joedborg> jdstrand: is that still looking sane? ^
<jdstrand> joedborg, ijohnson: ok, I need to head out for my appt, but I'll circle back and see if there is anything for me to do
<joedborg> jdstrand: +1 thanks!
<jdstrand> joedborg: it looks like a containerd default profile, yes
<jdstrand> sane is in the eye of the beholder :)
<jdstrand> but jokes aside, yes
<joedborg> jdstrand: perfect :)
<jdstrand> joedborg: so, if there are apparmor denials, ijohnson can help you add them to the right places for working around stuff and moving forward. if that happens, I can collect them  and give you a new demo deb. I can do that tonight/over the weekend/etc
<jdstrand> joedborg: I'll keep an eye on irc
<joedborg> jdstrand: sadly, there aren't any.  i think that's the main issue now
<jdstrand> joedborg: yes, I just wanted to reiterate that I'll update the demo deb as needed
<jdstrand> I'm also on tg
<joedborg> ahhh :)
<ijohnson> joedborg: ok I'm back
<ijohnson> joedborg: so we're still at the issue with the filesystem being ro?
<joedborg> ijohnson: yeah
<joedborg> ijohnson: sadly
<ijohnson> joedborg: I'm wondering if you could do something like `watch -n 0.05 bash -c 'sudo aa-status | grep $(pgrep install-aws.sh)'` on the node to see if it shows up under an apparmor profile
<ijohnson> err maybe make that snippet bit smarter so it actually filters properly
<ijohnson> one second
<joedborg> ijohnson: +1
<ijohnson> joedborg: try `until pgrep install-aws.sh; do true; done; pid=$(pgrep install-aws.sh); sudo aa-status | grep "$pid"`
<ijohnson> watch is a bit difficult to get to work there
<joedborg> ijohnson: i don't appear to be getting any results as the pod starts and fails
<ijohnson> joedborg: what about if you did: `until pgrep install-aws.sh; do true; done; pgrep install-aws.sh`
<ijohnson> that should eventually print off some pid
<joedborg> ijohnson: i still have the same node running if you wanted to watch the byobu
<joedborg> ijohnson: ill try it
<ijohnson> unless the name of this script is not install-aws.h
<ijohnson> err install-aws.sh
<joedborg> ijohnson: that latter one works
<ijohnson> cool, one sec let me give you something else to run
<ijohnson> joedborg: can you run `until pgrep install-aws.sh; do true; done; sudo nsenter -t $(pgrep install-aws.sh) --all /bin/bash -c "cat /proc/self/mountinfo"`
<ijohnson> that should show us the mount namespace of the process when its running
<ijohnson> joedborg: actually I think I will join that byobu if that's alright
<ijohnson> might make this quicker
<joedborg> ijohnson: of course :)
<joedborg> ijohnson: fyi i have 2 tabs inside it open
 * ijohnson googles how to switch tabs in byobu
<joedborg> F3 and F4
<mup> PR snapcraft#2834 opened: dirs: support --user install on Linux <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2834>
<diddledan> --user?
<mup> PR snapcraft#2835 opened: colcon plugin: support ROS 2 Eloquent <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2835>
#snappy 2019-12-07
<mup> PR snapcraft#2836 opened: meta: fix command-chain handling when Application adapter == "none" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2836>
<mup> PR snapcraft#2837 opened: remote-build: gpg-signing and usability fixes <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2837>
<sdhd-sascha> oh, building snapd on travis: "The job exceeded the maximum log length, and has been terminated."
<mup> PR snapd#7865 opened: travis-ci: add go import path <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7865>
<mup> PR snapd#7866 opened: travis-ci: split integration tests into parts (>4MB log limit) <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7866>
<mup> PR snapd#7867 opened: tests: allow dashes in fwupd version <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7867>
#snappy 2019-12-08
<mup> Bug #1647517 changed: Segmentation fault on core snap refresh from candidate channel <Snappy:Expired> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1647517>
<mup> Bug #1824607 changed: connection reset by peer <Snappy:Expired> <https://launchpad.net/bugs/1824607>
