#snappy 2015-06-29
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Morning all o/
<ogra_> https://www.kickstarter.com/projects/beaglecore/beaglecore-100-open-source-iot-device
<zyga> ogra_: hey
<ogra_> hey
<vmayoral|pc> ppisati: ping
<Chipaca> mo'in!
<Chipaca> ogra_: finally, a secure computer! because it's not plugged in to anything at all
<ogra_> heh, yeah :)
 * ogra_ is off to the dentist ... back in a few hours (i hope)
<ljose> Hi, is there a cross toolchain availalble for snappy arm? I trying to build some libraries for beaggle board in my dev machine.
<Chipaca> ljose: what is your dev machine?
<Chipaca> ljose: if on ubuntu, often installing gcc-arm-linux-gnueabihf is enough
<ljose> Chipaca: thanks, I using Ubuntu 15.04
<ljose> So I want to distribute a static library to be used with snappy, what is the recommened way to do that?
<Chipaca> ljose: not sure I understand, how would people use the library?
<ljose> They will use it to build new applications,  static linking with the library
<ljose> for Ubuntu we distribute it as a collection .deb packages i386/amd64
<Chipaca> ljose: applications are not build on snappy, so you continue to distribute it as .debs which people use to build the snaps
<Chipaca> ljose: static linking is resolved at build time
<Chipaca> ljose: so, distribute debs, people build with those, done
<ljose> Chipaca: cool
<JamesTait> Good morning all; happy Monday, and happy Camera Day! ð
<vmayoral|pc> ogra_: just to make sure, ppisati is the one that takes care of kernel aspects, right? I'd love to request access for the vivid BBB kernel sources for v4+ kernels
<ogra_> vmayoral|pc, yes he is
<vmayoral|pc> ogra_: thanks
<longsleep> hey folks - if i want to implement a snappy framework for a secure web server/virtual host server/tls proxy - would that make sense?
<ogra_> longsleep, as a snap, yes, i dont think that is what frameworks are for though
<Chipaca> longsleep: why'd you figure it was a framework?
<Chipaca> ogra_: the arale only looks at the first core for load? wut?
<ogra_> Chipaca, nope ... it looks at *some* core for the load avg.
<Chipaca> ogra_: ah! much better then
<ogra_> i dont think it is the first one
<ogra_> (assuming the first one would at least give constant values ... 90% of the time my top output shows fixed values)
<balloons> elopio, here's the bug from friday about snappy update failing. It seems it's not an issue in newer versions, but is repeatable for me from the original edge image. https://bugs.launchpad.net/snappy/+bug/1469716
<ubottu> Ubuntu bug 1469716 in Snappy "Snappy update fails to update core" [Undecided,New]
<mvo> balloons: thanks, thats interessting - this looks a bit like it might be a server side issue (or network releated).
<balloons> one other question / bug that has come up: https://bugs.launchpad.net/snappy/+bug/1466674. For the legacy packages with namespaces in the store, should they still be supported for installation? If the app developer doesn't updating the package name, but they are still in the store, it's confusing trying to install
<ubottu> Ubuntu bug 1466674 in Snappy "Snappy store contains packages with namespace" [Undecided,New]
<ogra_> no, they shouldnt
<ogra_> all my apps were kicked out and i had to re-upload them
<balloons> so is this something for beuno then? Should all those legacy packages be unpublished from the store
<ogra_> i'm not sure how that one could slip thrugh
<ogra_> they are unpublished (not removed but hidden for users)
<balloons> ahh. Yea, i point it out because the tutorial has you search for web servers, and this is one of the ones that pops up. So it's fairly visible. it's how I got the error
<ogra_> yep
<balloons> ogra_, right. That makes sense and is my expectation. Just unpublish and as dev to fix naming
<ogra_> but yeah, thats a beuno thing
<balloons> *ask
<ogra_> (who is on vac. this week i think)
<ogra_> seems that package somehow slipped through
<balloons> I guess for this instance I can ask Victor directly to fix it :-)
<ogra_> ;)
<elopio> good morning
<fgimenez> hi elopio
<fgimenez> pitti, thank you so much for such a quick fix! =)
<pitti> fgimenez: you're welcome :)
<elopio> hello fgimenez. Want to hang out?
<fgimenez> elopio, ok, omw
<Chipaca> jdstrand: you around?
<Chipaca> jdstrand: in case i forget, it's about nuking click-apparmor :)
<tyhicks> jdstrand: he's not around this week
<tyhicks> jdstrand: I may be able to help you out in his place (although I'm about to join a meeting)
<tyhicks> bah
<tyhicks> Chipaca: ^
<elopio> mvo: this regressed: https://bugs.launchpad.net/snappy/+bug/1464502
<ubottu> Ubuntu bug 1464502 in Snappy "PartitionTestSuite.TestHandleAssetsNoHardwareYaml fails: "open /writable/cache/hardware.yaml: permission denied" [Undecided,In progress]
<elopio> I made a small patch, please take a look when you have some time.
<balloons> is raspberry pi 2 unofficially supported?
<svij> balloons: nope
<balloons> I suppose my question is a bit backwards. I want to know if / when ras pi 2 will have official snappy support
<svij> there was a discussion about rpi2 support on the ML
<balloons> svij, ahh I see it, thank you. I'll read
<svij> balloons: great, I just try to find the mail. :)
<olli> while we are on the topic of rpi2, if I dd the prebuild image, do I still need to worry about the device* and pi* parts?
<olli> guess is, I don't, just want to confirm
<olli> https://developer.ubuntu.com/en/snappy/start/ - is a bit confusing
<sergiusens> olli: you shouldn't, no; that's all bundled in the img
<olli> thx sergiusens
 * Chipaca sorta-EODs a little early today
<olli> sergiusens, is it right that we don't supply updated snappy images for the rpi2 and I can't update from commandline either?
<plars> sergiusens: any idea how https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 can be made to finally land?
<sergiusens> plars: yes, it just needs to be done
<plars> sergiusens: by who? any idea who can do it?
<plars> or when we could expect it to land?
<sergiusens> plars: either myself or mvo; I just forgot about it on Friday, so today seems reasonable
<plars> sergiusens: awesome, thanks!
<balloons> ping elopio
<elopio> balloons: pong.
<balloons> elopio, so I wanted to touch base with you on setting up the system for capturing test results. Have you started anything on it yet?
<elopio> balloons: nothing yet.
<ljose> Hi, is there a list of system libraries included in Snappy armhf?
<tedg> ljose, Not really, generally the answer is "none" other than libc.
<tedg> ljose, They should get bundled with the app snaps.
<ljose> so no OpenSSL bzip2 or suck?
<ljose> Do I really need to build this  libraries for my application?
<balloons> elopio, ok good :-) I'll start working on it later today and share
<elopio> balloons: thanks. Are we still talking about a wiki page with links to extra notes?
<balloons> elopio, yes. I'll do that, and some variations with spreadsheets and forms
<elopio> balloons: cool. We were also looking at ways to record input and output from the terminal. If we can find some time for that, maybe we can turn one of the recorders into a snap :)
<tedg> ljose, We're working on ways to make it easier to include the version from the Ubuntu archive, so you wouldn't have to build them. But they would still be included in your application.
<ljose> So meanwhile what are my options, build my own copy of OpenSSL bzip2 for my device?
<tedg> ljose, I'd just grab the copies from the Ubuntu archive by hand, and copy them into my project.
<tedg> ljose, dpkg --unpack foo.deb ./
<ljose> tedg:  Where can I found the packages for armhf?, in vivid repositories there is just i386 amd64 http://packages.ubuntu.com/vivid/openssl
<tedg> ljose, http://ports.ubuntu.com/dists/vivid/main/
<balloons> elopio, you wanted manually executed 'automatic' test scripts or just to have a log of what you did?
<tedg> ljose, http://ports.ubuntu.com/pool/main/o/openssl/
<elopio> balloons: a log of the manual commands and replies.
<elopio> not something we must have, I just thought it could be nice.
<Saviq> ogra_, hey, I'm trying to put your new rpi2 images into my orange matchbox, but all I'm getting is garbage on boot, any ideas?
<Saviq> tried both the stable and wily image, same happens :/
<Chipaca> apptove ALL the branches \o/
<Chipaca> Saviq: you're holding it wrong :-p
<Saviq> Chipaca, that's my current thinking indeed
<Saviq> ok that's dumb... the emonpi attachment makes it do that...
<Saviq> that I didn't expect
#snappy 2015-06-30
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Good morning o/
<JamesTait> Good morning all; happy Meteor Watch Day! ð
<JohnClare> Hello brethren
<blr> JamesTait: you can't fool me, it's Ice cream soda day.
<JamesTait> blr, really? Works for me!
<Chipaca> mo'in ppls
<Chipaca> blr: no, that's june 20
<Chipaca> blr: although according to the same source, today is "turkey lovers' month"
<Chipaca> blr: so i'm not sure they understand the concept of "day"
<Chipaca> to be fair, it's a tricky one for chefs to grasp
<blr> Chipaca: my secretary will hear about this... this is an outrage.
<blr> (my secretary is a black smoke persian, she's not very good at scheduling. Suppose I'll have to return the crate of ice cream soda)
 * Chipaca hopes that's a cat, as opposed to being incredibly racist
<blr> yes, a cat...
<Chipaca> blr: no returns on food though
<JamesTait> blr, if you need a hand disposing of that ice cream soda, I know someone.... ð
<Chipaca> mvo: i didn't realize gettext2 was merging into gettext, not sure what gives now
<mvo> Chipaca: i resubmit, no problem
<Chipaca> mvo: okie doke
<rsalveti> morning
<Chipaca> sergiusens: wrt https://code.launchpad.net/~sergiusens/snappy-hub/grubcfg/+merge/262701 do you want that landed?
<Chipaca> rsalveti: mo'in!
<rsalveti> ogra_: this beaglecore is quite interesting, but a bit expensive it seems
<rsalveti> at the same time there are the other guys doing the $9 board
<ogra_> rsalveti, the $9 board is a fake ... it will cost $49 after the kickstarter
<rsalveti> right lol
<ogra_> ah, sorry, $39 is what thy said
<mvo> Chipaca: hm, is it just me or is snappy trunk unhappy right now (and if so, how is this possible?): http://paste.ubuntu.com/11798388/ - gtg to get lunch so no hurry :)
<Chipaca> mvo: it's just you
<Chipaca> oh, wait
<Chipaca> i don't have adt-run :)
<Chipaca> mvo: maybe tarmac doesn't have adt-run either
<fgimenez> mvo, Chipaca it is failing here too, this branch should fix it https://code.launchpad.net/~fgimenez/snappy/fix-installsnap-call/+merge/263336
<sergiusens> Chipaca: I think I want to apply the pastebin first
<sergiusens> Chipaca: if someone approves it, it can land ;-)
<sergiusens> Chipaca: mvo did the go tests land? And no, no adt-run on tarmac, not sure it would work well (merges would take a tad longer, tad == couple of hours with no prior measurement)
<Chipaca> sergiusens: where does tarmac run?
<sergiusens> Chipaca: we had this conversation already :-P
<sergiusens> Chipaca: on a DO instance
<Chipaca> sergiusens: this was a tarmac in a puny cloud thing?
<Chipaca> right
<Chipaca> sergiusens: you're expensing that, right?
<sergiusens> Chipaca: nope
<Chipaca> sergiusens: aww, but i want to throw hardware at the problem :)
 * ogra_ hands Chipaca a spare RPi 
<Chipaca> ogra_: let's go grab the ubuntu build farm of rpi's that whatsisname croudfunded
<ogra_> heh
<Chipaca> this one: https://www.indiegogo.com/projects/a-raspberry-pi-build-cluster-for-ubuntu
<ogra_> yeah, alan
<Chipaca> ye, wossisname
<Chipaca> anyway :)
<Chipaca> sergiusens: if the integration tests are too slow, we split them and farm them out so they're only as slow as the slowest individual test (+overhead)
<ogra_> alan bell :)
<Chipaca> as opposed to the other alan, wossisname-with-a-face
<Chipaca> and then there's wossisname-welsh-guy-plays-with-n-scale-trains
<sergiusens> Chipaca: building is not the problem, i's running
<Chipaca> sergiusens: that's what i'm talking about
<Chipaca> in other news, run-checks now asks me for my password
<sergiusens> Chipaca: ok, so first solve the provisioning issue on rpi's and then we do that ;-)
<Chipaca> what could possibly go wrong :-)
<Chipaca> ugh, does adt-run really leave schroots lying around? :(
 * Chipaca makes some guacamole to mask his pain
<ogra_> get two cucumber slices too ...
<Chipaca> no cucumber, no tomato, no peppers. so it's my ex-mother-in-law's recipe: palta, lemon, salt, ground pepper
<ogra_> and some garlic bread ?
<Chipaca> yep
<Chipaca> fgimenez: with that patch the tests build but don't pass, right?
<fgimenez> Chipaca, no, i have them passing too, are they failing?
<Chipaca> fgimenez: ver es
<Chipaca> fgimenez: ver yes
<Chipaca> fgimenez: http://pastebin.ubuntu.com/11798701/
<fgimenez> Chipaca, this is the adt-run error because of the missing dpkg-query, with adt-run 3.15.1 should be ok
<Chipaca> fgimenez: ahhhh
<fgimenez> Chipaca, however i think 3.15.1 is only available in wily atm...
<Chipaca> fgimenez: i'm on wily, but haven't updated this week
 * Chipaca apologizes
 * sergiusens is back
<fgimenez> Chipaca, ah ok then :)
<fgimenez> Chipaca, np :)
<sergiusens> Chipaca: does this work for you https://code.launchpad.net/~sergiusens/snappy/splitDown/+merge/263294 ?
 * Chipaca looks
<Chipaca> sergiusens: sure
<sergiusens> Chipaca: that solves the nit in https://code.launchpad.net/~sergiusens/snappy/downloadIcon/+merge/263296 , right?
<Chipaca> sergiusens: you probably want to merge trunk
<sergiusens> Chipaca: I have
<Chipaca> sergiusens: it solves it for the common "download failed" error, but not sure whether the more pathologic errors (the copy failing for example)
<Chipaca> sergiusens: why do you have conflicts then?
<Chipaca> maybe i'm looking at the wrong diff :)
<sergiusens> Chipaca: maybe my syc-pipeline failed, let me check
<Chipaca> yeah, there are for real conflicts in there
<sergiusens> Chipaca: ok, one more sec; sync-pipeline is doing its thing now
<sergiusens> Chipaca: there
<sergiusens> Chipaca: the obscure error from w.Sync() you mean?
<sergiusens> Chipaca: we have a bug for clearer download errors fwiw
<sergiusens> maybe we should tackle that there?
<Chipaca> sergiusens: maybe? what's the bug?
<sergiusens> Chipaca: not sure, I asked someone to log it
<sergiusens> Chipaca: so maybe we don't...
<kgunn> seb128: so where do you get the udf/goget-ubuntun-touch that has personal channel support from ?
<sergiusens> kgunn: for now you can just grab the u-d-f deb from https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1 ... I'll take it to tools-proposed in a bit
<elopio> hello.
<kgunn> sergiusens: thanks...
<sergiusens> kgunn: clickable linke https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.25-0ubuntu1/+build/7569188/+files/ubuntu-device-flash_0.25-0ubuntu1_amd64.deb
<sergiusens> if you are on an amd64 system
<kgunn> sergiusens: uh....do you have one for vivid ?
<ogra_> its go
<sergiusens> kgunn: it really really doesn't matter
<kgunn> k
<ogra_> just install ti
<ogra_> *it
<kgunn> and yes amd64
<seb128> kgunn, what sergiusens said
<sergiusens> kgunn: just make sure add-apt-repository ppa:snappy-dev/tools to make sure all aux deps are up to date
<seb128> bah, I don't get why but cloud-init fails to start on snappy personal for a week
<ogra_> i dont get why you still havent unseeded it :P
<ogra_> (we talked about it last week iirc)
<seb128> ogra_, because we don't want to diverge from core
<elopio> fgimenez: sorry I'm late. I'm joining the hangout.
<ogra_> seb128, you definitely do want to diverge from core
<fgimenez> elopio, ok np
<seb128> ogra_, why?
<ogra_> seb128, you want to actually have a merged system between core and touch
<ogra_> because core isnt a desktop system
<seb128> right, but we want the base snappy zest to work
<ogra_> and cloud-init isnt really designed for desktops
 * ogra_ would use the user creation from touch for now ... as i suggested last week 
<ogra_> and drop cloud-init
<seb128> kgunn, ^ what do you think?
<ogra_> you will most likely get a lot of issues with session startup and permissions etc
<ogra_> (not sure how clous-init exactly works, but it likely is focused on cloud user creation :) )
<sergiusens> seb128: ogra_ I can fix this from the u-d-f side, just give me a sec
<ogra_> sergiusens, cloud-init ?
<sergiusens> ogra_: yeah, just like we do for our 'devices'
<sergiusens> I just didn't think personal would have cloud-init seeded ;-)
<ogra_> yeah
<sergiusens> I think seb128 has  a point, it will be easier to migrate into core if the base has additions only and not removals
<seb128> sergiusens, oh, it's an u-d-f issue?
<sergiusens> seb128: yes and no
<ogra_> seb128, teg phablet user creation for touch is in livecd-rootfs in a hook btw ... (if you port it you want to take a look at the groups though, you likely dont want the android groups in personal desktop)
<ogra_> *the phablet
<sergiusens> seb128: what is in u-d-f today I consider a hack and we have a task to remove that hack
<seb128> ogra_, yeah, I'm looking at http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early
<ogra_> seb128, no, not that one
<seb128> ogra_, sergiusens, I'm unsure what to do there, I wanted to get the image working without diverging too much from core, then start to discuss things like not using cloud-init
<seb128> ogra_, sorry
<ogra_> seb128, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot
<seb128> ogra_, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot
<seb128> I mean
<seb128> yeah, clicked the wrong one :p
<ogra_> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot and http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/45-add-sudo-group-nm.chroot are the ones you want to take a look at too
<seb128> ogra_, thanks
<ogra_> though for the first one you probably only want the audio group (if at all)
<ogra_> sergiusens, hmm, that reminds me ... did you take a look at usermod too wrt extrausers ?
<ogra_> it might also need love
<vmayoral|pc> ppisati: ping
<sergiusens> ogra_: I haven't, and yes it needs love, but one step at a time; deluser also needs some love fwiw
<ogra_> sergiusens, yeah, just struck me that we didnt have it on the list yet
<ogra_> but apparently you do already :)
<seb128> sergiusens, ok, I think I'm going to follow ogra_'s suggestion for the user creation, it's likely going to make easier to have the user in the right groups as well
<ogra_> seb128, indeed thats not a long term solution (but neither is cloud-init i guess)
<ogra_> seb128, we also have a bunch of lightdm changes (in either lxc-android-config or ubuntu-tuch-session, i forgot where they landed ... that are needed to make u-s-c start etc ... ) mterry implemented that back then
<sergiusens> seb128: so you are unseeding cloud-init?
<seb128> sergiusens, going to have a look at doing that, I hope it doesn't carry us at doing too many changes
<sergiusens> seb128: when it's safe to seed it again once the proper snappy firstboot logic is in place you can add it back
<seb128> ogra_, is the uid 32011 for android compat purpose? or asked differently, is that needed or desktop or should it be 1000?
<seb128> sergiusens, right
<sergiusens> seb128: you can subscribe to https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init
<sergiusens> if you want
<ogra_> seb128, 1000 is hardcoded in android for the "system" user
<seb128> sergiusens, thanks
<ogra_> seb128, the 32011 is just to be sure we dont clash with any of these hardcoded andrpid groups
<seb128> ogra_, k, so 1000 should do for desktop I guess :-)
<ogra_> for multi user phones and convergence we will need to fix that in the adduser config so that the default user gets a high enough UID
<ogra_> for an initial desktop image 1000 should do indeed ... but you will have to follow the above later too ... since convergence will use the android container most likely
<Chipaca> people, i'm going out over mobile right now, and it's acting up, not giving me 3g (although it fluctuates)
<seb128> right, let's see
<Chipaca> my point being, not sure ho will work
<ogra_> Chipaca, use a proper phone :P
<sergiusens> Chipaca: we are splitting work
<sergiusens> Chipaca: if you are not there...
<sergiusens> :-P
<Chipaca> i'll try! ill try.
<ogra_> yeah, you just got all the crap stuff assined
<ogra_> *assined
<ogra_> bah
<ogra_> i need a new g !
<elopio> fgimenez: the upgrade test works for me http://paste.ubuntu.com/11799617/
<fgimenez> elopio, ok, i'll try it again
<elopio> fgimenez: I pushed a merge with trunk.
<fgimenez> elopio, thanks, running now
<fgimenez> elopio, http://paste.ubuntu.com/11799655/
<elopio> fgimenez: it's running the upgrade test as part of the command1.
<fgimenez> elopio, command1 should be latest right?
<elopio> test command1: debian/integration-tests/snappy-test update.test
<elopio> fgimenez: yes. What do you have in your debian/integration-tests/control ?
<fgimenez> elopio, yes that must be it http://paste.ubuntu.com/11799670/
<fgimenez> elopio, rerunning with clean control
<seb128> ogra_, do you know why http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/01-setup_user.chroot create the user with --disable-login?
<slangasek> seb128: hey, not sure whether cyphermox filled you in, but we do have a grub now in wily whose --removable option will work for snappy personal.  Unfortunately when booting under qemu, the kernel then crashes in a loop... that's most likely unrelated though
<elopio> fgimenez: right, this is +1 to your control templates, then the index is something we control on main, not something we have to keep in sync.
<fgimenez> elopio, yes, having it unified may prevent errors in the long term
<seb128> slangasek, cyphermox, oh, nice ... the kernel loop, what grub entry do you try? the snappy/system-a does that but the "ubuntu" one works
<slangasek> seb128: ah - we don't get a boot menu, so we're just booting whatever the default is, which I would expect to be snappy/system-a
<seb128> slangasek, k, that doesn't work
<ogra_> seb128, no idea, that script originally comes from the OEM team (when it was still called that)
<seb128> unsure how it's created/why we have several entries
<ogra_> seb128, oh, wait, thats for system and radio users
<seb128> ogra_, no, l7
<seb128> adduser --gecos $USER --disabled-login $USER --uid $UGID
<ogra_> we dont want any hacker to abuse these accounts indeed :)
<seb128> echo "I: creating default user $USER"
<ogra_> ah, right, no idea about that one ... i guess for the actual user it is nonsense
<ogra_> for radio and system thats surely valid
<seb128> right
<seb128> ogra_, "With the --disabled-login option, the
<seb128>        account will be created but will be disabled until a password  is  set.
<seb128> "
<seb128> which is done further in the file
<seb128> so I guess it's ok
<ogra_> yeah, as i said, nonsense
<elopio> mvo: are you using go benchmark for the squash report?
<ogra_> someone being over-cautious or something
<slangasek> seb128: I would assume that snappy personal should have a/b partitions just like snappy core... what are the differences between this 'ubuntu' boot entry and the snappy one?
<fgimenez> elopio, all fine now http://paste.ubuntu.com/11799711/ :)
<seb128> slangasek, I don't know, we didn't tweak anything from grub, just copied the hooks from core
<slangasek> hmm
<elopio> fgimenez: phew. Please top approve when you are happy with it. Or leave a needs fixing if you are unhappy, I'll fix it after breakfast.
<elopio> fgimenez: so now we have to think about how to declare tests and their requirements, so main.go can parse that.
<elopio> doesn't sound too easy if we have to declare channel, release and version, and maybe secondary test bed inside a container.
<fgimenez> elopio, yes, we can begin with the simplest cases
<seb128> slangasek, the pastebin I did the other time is still there on http://paste.ubuntu.com/11757708/ if you want to see the configs
<fgimenez> elopio, main.go is becoming a little hairy, maybe we can do this and other related stuff in a separate adtrun library
<seb128> slangasek, seems like the snappy one is trying to boot the .efi.signed and the ubuntu one not
<slangasek> seb128: oh interesting!
<seb128> linux /boot/vmlinuz-3.19.0-22-generic.efi.signed root=LABEL=system-a ro init=/lib/systemd/systemd
<seb128> vs
<seb128> linux	/boot/vmlinuz-3.19.0-22-generic root=UUID=c019e487-1263-4559-90d8-af732fa72ef1 ro init=/lib/systemd/systemd
<seb128>  
<seb128> also one uysing disk label
<seb128> disk->partition
<seb128> but I guess that's not the issue
<ogra_> uh
<ogra_> you definitely dont want a UUID in there
<ppisati> vmayoral|pc: pong
<vmayoral|pc> ppisati: hi
<ppisati> vmayoral|pc: hi
<vmayoral|pc> ppisati: I'm trying to update our images on the BeagleBone Black with the newer kernels (our images still rely on http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_beagle_3.8)
<elopio> fgimenez: +1 to that too. If we make main.go an adt-run setup script, then it will be a lot easier for the CI machinery, if we ever get that.
<vmayoral|pc> ppisati: do you think I could have access to the kernel sources from the newer kernels (e.g. 3.19)
<vmayoral|pc> ppisati: or maybe even better, 4.+
<ppisati> vmayoral|pc: http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/
<ppisati> vmayoral|pc: that's the src code for the 3.19 kernel
<ppisati> vmayoral|pc: we don't support 4.x yet
<vmayoral|pc> ppisati: ok, is there a specific branch for the BeagleBone Black?
<ppisati> vmayoral|pc: nope, it's the master branch
<ppisati> vmayoral|pc: just compile it for armhf
<ppisati> vmayoral|pc: here is an howto for cross compilation
<ppisati> vmayoral|pc: https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
<ppisati> vmayoral|pc: branch master
<vmayoral|pc> ppisati: thanks, unfortunately, I believe that won't do because we make use of the patches from BeagleBoard.
<elopio> fgimenez: we have a lot of lint errors, mainly for missing comments. I'll fix that.
<vmayoral|pc> ppisati: do you believe it's possible to rebase Ubuntu's patches on top of https://github.com/beagleboard/linux?
<mvo> elopio: I'm not using go-benchmark, its currently not very reproducable, but go benchmark is a nice idea
<vmayoral|pc> ppisati: i tried doing so with the apparmor ones you did before at http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_beagle_3.8
<vmayoral|pc> ppisati: but I failed miserably
<ppisati> vmayoral|pc: isn't that the 3.8 kernel you are talking about?
<vmayoral|pc> ppisati: mmm maybe i didn't express myself appropriately, 3.8 kernel is working great after your help last time, however we'd like to move to 3.19 (and make use of the latest Snappy image release by you guys)
<ppisati> vmayoral|pc: so you don't want the ubuntu patches on top of the beagleboard kernel
<ppisati> vmayoral|pc: you want the beaglebone patches on top of the ubuntu vivid kernel
<ppisati> vmayoral|pc: and sorry, but it's too much work
<vmayoral|pc> ppisati: i'm fine having the ubuntu patches on top of beagleboard's if that's possible
<vmayoral|pc> i tried that myself
<vmayoral|pc> but failed
<ppisati> vmayoral|pc: but that's your situation now
<ppisati> vmayoral|pc: isn'it?
<vmayoral|pc> ppisati: for the 3.8 yes, but not for newer kernels
<ogra_> is that still the old capemgr issue ?
<ogra_> or what are these BBB patches ?
<vmayoral|pc> ogra_: yes, it's that
 * ogra_ thought there would be a proper replacement by now
<vmayoral|pc> i believe capemgr has been integrated in 4+ kernels which is why I started that way the conversation
<fgimenez> elopio, ok thanks flycheck can catch these too http://i.imgur.com/uKG1pll.png
<elopio> fgimenez: my goal for today is to have a pretty emacs like you :)
<sergiusens> ogra_: mvo builds are broken -> cp: cannot stat 'debian/tmp/share': No such file or directory
<sergiusens> any idea what caused that?
<sergiusens> alos, what's up with all the 'ar: `u' modifier ignored since `D' is the default (see `U')'
<ogra_> sergiusens, ?
<ogra_> got a log or something ?
<sergiusens> ogra_: https://launchpadlibrarian.net/210353958/buildlog_ubuntu-wily-powerpc.ubuntu-snappy_1.2-1%2B538~ubuntu15.10.1_BUILDING.txt.gz
<sergiusens> ogra_: or here https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily-wily
<sergiusens> ogra_: that ar thing only shows up on powerpc, but the cannot stat on all
<fgimenez> elopio, didn't know of this nicety before! :)
<ogra_> sergiusens, that looks to me like there is a wrong path in a .install or .dirs file
<sergiusens> ogra_: yeah, I'm not aware of approving anything like this from the queue though
<sergiusens> ogra_: I'll check after lunch
 * sergiusens is starving
<ogra_> i guess the ar message can be ignored (not sure though) since you newly create the archive ... so "u" = update ... wouldnt update anything
<fgimenez> nice evening everyone o/
<vmayoral|pc> ppisati: I quickly tried grabbing the latest image provided by you guys and replaced the kernel with the 3.8
<vmayoral|pc> ppisati: seems promising, so i think we can go that way
<vmayoral|pc> ppisati: long term, i'd like to put some of my time supporting newer kernels
<vmayoral|pc> ppisati: If you don't mind, i'd like to run my thoughts through you regarding "the beaglebone patches on top of the ubuntu vivid kernel". You already shared that it'll be a substancial amount of work. My approach will be to find a common commit and start analyzing commits from that point
<vmayoral|pc> ppisati: is there a better way to approach it?
<ogra_> sergiusens, looking at debian/rules i dont even see why it would do this extra dh_install call at all ... i wonder if the golang debhelper bits changed
<ogra_> sergiusens, it definitely finishes fine in the "override_dh_auto_install" part ...
<ogra_> sergiusens, hmm though i see the dh_install in a successfull build too... very weird
<ogra_> sergiusens, http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/revision/527 ... that has changes to debian/rules ... blame mvo :P
<mvo> ogra_: oh, I broke it? let me see
<ogra_> mvo, https://launchpadlibrarian.net/210353958/buildlog_ubuntu-wily-powerpc.ubuntu-snappy_1.2-1%2B538~ubuntu15.10.1_BUILDING.txt.gz
<ogra_> make[1]: Leaving directory '/Â«PKGBUILDDIRÂ»'
<ogra_>    dh_install -a -O--buildsystem=golang -O--fail-missing
<ogra_> cp: cannot stat 'debian/tmp/share': No such file or directory
<ogra_> dh_install: cp --reflink=auto -a debian/tmp/share debian/ubuntu-snappy-cli//usr/ returned exit code 1
 * mvo looks
<mvo> thanks ogra_
<vmayoral|pc> webdm seems to be failing with the new BBB image https://gist.github.com/vmayoral/371b1c10fdaed445353d
<vmayoral|pc> tried restarting the service but keeps failing
<vmayoral|pc> (the BBB doesn't have access to Internet but i'd be surprised if this is the cause)
<ogra_> well, if there is no network interface up it cant start avahi
<ogra_> so i think thats kind fo expected ... (how would you access webdm without network anyway)
<vmayoral|pc> ogra_: there're network interfaces up but none with access to the Internet. Previous Snappy images didn't fail when launching webdm in this scenario
<vmayoral|pc> good to know though, thanks
<ogra_> well, does the interface have an IP ?
<ogra_> or is it just up
<elopio> launchpad is angry today.
<ogra_> yeah, i had various 503's here tha last hour
<vmayoral|pc> ogra_: they've got IP addresses (e.g. I'm using usb0 in an ethernet-over-usb configuration for debugging)
<sergiusens> vmayoral|pc: pastebin the output of sudo journalctl -u webdm_snappyd_0.9.service (or the corresponding version number)
<vmayoral|pc> sergiusens: https://gist.github.com/vmayoral/a6995881699d05a6d3ea
<vmayoral|pc> systemd-analyze plot has been fixed in the new image :)!
<sergiusens> vmayoral|pc: yeah, as ogra_ says, it's avahi, I might need to do something for this not to happen, do you mind sharing your network config? (with ifconfig or ip)
<vmayoral|pc> sergiusens: https://gist.github.com/vmayoral/d24efe6b378e0d959237
<vmayoral|pc> any chance someone can have a look at this svg https://gist.github.com/vmayoral/61f880c0663ac6187316?
<vmayoral|pc> Snappy takes 73s to finish booting, i'd to love to reduce this
<ogra_> because you have no eth0 i bet
<ogra_> bah, that svg cant be easily opened from the browser
<vmayoral|pc> we've had a few demos with Snappy and people always ask why it takes so long to boot :(
<vmayoral|pc> ogra_: let me export to it png and upload it somewhere
<ogra_> no, its fine ...
<longsleep> my snappy boots in 3 seconds
<ogra_> dropping the RAW url into eog works
<vmayoral|pc> longsleep: 3 seconds! that'll be sweet
<ogra_> yeah, looks like cloud-init starts really late there ...
<ogra_> most likely due to waiting for some network timeout
<vmayoral|pc> i still haven't tinkered much into the image so i presume most BBBs should have a similar booting time
<vmayoral|pc> s/tinkered/hacked
<vmayoral|pc> cloud-init-local.service takes about 18 seconds
<ogra_> vmayoral|pc, try removing /etc/network/interfaces.d/eth0 and reboot ... see if that changes anything
<longsleep> Is this the first boot?
<longsleep> cloud init creates all the keys and stuff on first boot
<longsleep> that takes a while
<ogra_> longsleep, no, but it behaves like the first boot ...
<longsleep> ah
<longsleep> well - then i do not know why cloud init ever should be blocking
<longsleep> even if it takes 18 seconds
<ogra_> becaue its slow ... python on arm etc etc :P
<longsleep> depends on the arm i guess - quad core 1.5GHz is fast
<vmayoral|pc> this is a 1 GHz single core cortex-A8
<ogra_> well, you are spoiled :P
<longsleep> hehe - true i guess
<ogra_> vmayoral|pc, single ?
<ogra_> i thought it is dual
<vmayoral|pc> ogra_: the BBB has a single ARM core
<ogra_> oh
 * ogra_ always thought it was a dual core
<vmayoral|pc> but it includes 2 additional PRUs (programmable real time units)
<longsleep> well then - you will not get 3 seconds boot with that :)
<vmayoral|pc> quite useful but not in this particular case i'm afraid
<ogra_> no, but 30+ should be achievable
<ogra_> if everything behaves
<vmayoral|pc> that's sort of like what i was aiming for, I got those booting times with previous Ubuntu images
<vmayoral|pc> (Trusty images)
<longsleep> mhm ok - if half of it is cloud init with 18s ..
<longsleep> still feels way to long
<ogra_> i wonder if cloud-init can even handle usb0 interfaces
<ogra_> might be that that is confusing it and making it generate new ssh keys every boot or some such
<vmayoral|pc> ogra_: i've debugged the boot of the BBB with a serial cable and i don't see the keys being generated every time
<longsleep> yeah that sounds plausible - the webdm error indicates that the system is busy and fails to start webdm in time
<ogra_> well, then it is something else in cloud-init
<sergiusens> mvo: native?
<longsleep> thats one thing i wanted to ask - why is cloud-init even in there?
<sergiusens> well, at least that avoids future quilting...
<vmayoral|pc> here's the booting process https://gist.github.com/vmayoral/1c6831bbbb2444ba8fe6
<longsleep> it seems half of cloud-init is disabled anyway - i was investigating how i can resize the app space to use full card on boot
<longsleep> well it takes 8 seconds to load and unpack the initramfs already
<longsleep> so it essentially booted up after 10 seconds which is fine. All the rest is systemd doing startup.
<longsleep> i would uninstall webdm first as this seems broken and then disable cloud-init to start on boot and see how this goes
<vmayoral|pc> longsleep: let me try that
<vmayoral|pc> improved to 51 seconds
<longsleep> no cloud-init ?
<vmayoral|pc> sorry, 59, not 51.
<vmayoral|pc> I did "systemctl disable cloud-init"
<vmayoral|pc> but didn't seem to disable it, am i missing something
<vmayoral|pc> ?
<longsleep> i guess it is with some .service suffix
<longsleep> try systemctl status to get the names
<longsleep> it has even 4 services
<sergiusens> elopio: is lp still behaving badly for you?
<longsleep> cloud-init-local.service, cloud-init.service, cloud-config.target, cloud-config.service, cloud-final.service
<longsleep> i am travelling right now, and do not have a snappy at hand to check the exact way to disable it
<vmayoral|pc> ok, all disabled, retrying
<vmayoral|pc> mmm odd, still something's going on
<vmayoral|pc> https://gist.github.com/vmayoral/eac1c483fc97547281d2
<longsleep> vmayoral|pc: check if cloud-init is really disabled. I have to leave now - if this does not help then start to disable even more to figure out where it is loosing time
<vmayoral|pc> longsleep: sure, thanks for your help!
<kgunn> hey so if i use this u-d-f for downloading personal image....what happens ? does it simply download it into ~/.cache? or does it actually try to install ?
<longsleep> it still runs cloud-init
<sergiusens> kgunn: it creates an img you can put anywhere that you see fit
<kgunn> sergiusens: ah...really, creates it on the fly ?
<sergiusens> kgunn: yes
<kgunn> sergiusens: too curious...so is it just using the latest packaging from wily ?
<sergiusens> kgunn: ok, now I'm lost
<sergiusens> kgunn: but I think I want to say yes
<kgunn> sergiusens: yeah, just wondering how it knows what packages to use....
<kgunn> like conceivbly i could make a vivid img
<sergiusens> kgunn: system-image -> cdimage -> livecd-rootfs -> ubuntu wily + ~snappy-dev/image
<kgunn> even tho i'm creating a wily one
<sergiusens> kgunn: to make a vivid image you would need to target 15.04 instead of rolling and then be confined to ubuntu vivid + ~snappy-dev/image(for vivid)
<kgunn> sergiusens: got it, i was just surprised that it's creating an image....rather than downloading some prebuilt thing
<sergiusens> kgunn: prebuilts for releases only; personal has not been released
<kgunn> shnikes....this is gonna be a while
<kgunn> sergiusens: does the img just end up in the directory i'm sitting in? (e.g. not in .cache/system-images....
<sergiusens> kgunn: ends up wherever --output tells it to
<ogra_> sergiusens, kgunn, i *think* personal uses vivid+overlay, i might be wrong though, seb128 could help
<kgunn> don't think so...at least in his instructions, output file is named "wily.img"
<ogra_> ah, k
<kgunn> seb128: how do i know i
<kgunn> 'm hitting the cloud init prob ?
<ogra_> that has just been removed, not sure the removal already landed in an image
<seb128> kgunn, you wait for a while and it boots
<seb128> kgunn, or you edit the grub line, add systemd.debug-shell, boot, when it hangs ctrl-alt-f9 and systemctl stop cloud-init
<kgunn> at grub menu, do i choose "ubuntu" or "ubuntu core blah blah blah"
<seb128> "ubuntu"
<kgunn> cool
<seb128> need to go, bbl
<kgunn> ohp...there it is...
<kgunn> seb128: o/
<kgunn> i'm just impatient
<davmor2> sergiusens: I'm confused why is generic-i386 tagline AMD64 generic package that makes no sense ;)
<sergiusens> davmor2: because...
<sergiusens> davmor2: you are just opening a can of worms here :-)
<davmor2> sergiusens: we if you will put the can of worms next to the can opener what is person to do :P
<ogra_> davmor2, no worries, you can only install it on armhf anyway ...
<ogra_> and only if you log in via a ppc64el machine
<sergiusens> ogra_: no, we changed the requirement to MIPS
<ogra_> ah, cool, finally !
<davmor2> \o/ universe implodes
<kgunn> seb128: iirc, you said you see phone greeter, i
<kgunn> 'm seeing desktop
<elopio> sergiusens: yes, I still have to retry the lp commands.
<elopio> https://bugs.launchpad.net/snappy/+bug/1470210
<ubottu> Ubuntu bug 1470210 in Snappy "integration tests fail with: error while loading shared libraries: libgcc_s.so.1" [Undecided,New]
<elopio> this breaks often, right?
<elopio> rsalveti: ^
<sergiusens> elopio: are you building with gcc-go instead of gc-go?
<elopio> sergiusens: for that bug, I'm not building anything.
<elopio> just installing from the store and running.
<kgunn> (nice i typed this and didn't hit enter) seb128: so how do i get past the greeter ?
<sergiusens> elopio: oh, haven't checked the content, just the title
<sergiusens> elopio: it's strange but the ubuntu-core-launcher is broken and it shouldn't be, Chipaca ideas?
<Chipaca> sergiusens: nesting roaches shorted out the ether cable
 * Chipaca hugs http://pages.cs.wisc.edu/~ballard/bofh/bofhserver.pl
<Chipaca> sergiusens: broken how?
<sergiusens> Chipaca: as in https://bugs.launchpad.net/snappy/+bug/1470210
<ubottu> Ubuntu bug 1470210 in Snappy "integration tests fail with: error while loading shared libraries: libgcc_s.so.1" [Undecided,New]
<Chipaca> ok, let me take a look
<Chipaca> i'm going to have to engage the brain, please stand by
<sergiusens> Chipaca: it's strange that the debian packaging system didn't pickup on the shared libs
<sergiusens> maybe it's missing that stanz
<sergiusens> maybe it's missing that stanza
<Chipaca> but only on the bbb
<Chipaca> sergiusens: is that still: sudo ubuntu-device-flash --verbose core rolling -o bbb_rolling_`date -I`.img --channel edge --oem beagleblack --developer-mode ?
<Chipaca> sergiusens: do you have the serial pinout for the bbb handy? i remember i plugged in five cables, but can't find which ones where :) internet says to only plug in three from what i can find today
<sergiusens> Chipaca: http://elinux.org/Beagleboard:BeagleBone_Black_Serial
<Chipaca> yep, that's what i was finding
<sergiusens> Chipaca: I connect all except the red one
<Chipaca> just three cables
<sergiusens> Chipaca: 5vcc
<sergiusens> that I avoid
<Chipaca> yep; on mine, 5vcc is not connected at the other end
<Chipaca> but i've got tx/rx, rts/cts, and dtr
<Chipaca> um
 * Chipaca looks again
<Chipaca> dtr, rxd, txd, (5v), cts, gnd
<Chipaca> and the doc tells me where to plug in gnd, rxd and txd
<Chipaca> so no hardware flow control?
<Chipaca> i seem to remember i had that, but ok i guess
<sergiusens> Chipaca: I have them connected, but it's not needed
<Chipaca> sergiusens: where do you have them connected?
 * Chipaca goes with the three-cable version
<Chipaca> sd is nearly finished flashing :)
<sergiusens> Chipaca: they are useless
<sergiusens> Chipaca: https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
<sergiusens> Chipaca: section 7.5
<Chipaca> âSignals supported are TX and RX. None of the handshake signals are supported.â :-(
<Chipaca> (from the equivalent datasheet for my particular one)
<sergiusens> Chipaca: right, useless but I have them connected
<Chipaca> the bbb still has eth0! \o/
<Chipaca> sergiusens: are you on wily?
 * Chipaca reboots just in case
<Chipaca> why doesn't network manager want to share my ethernet any more :-(
<Chipaca> [Tue Jun 30 22:10:21 2015] audit: type=1400 audit(1435702222.070:14): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/lib/arm-linux-gnueabihf/libgcc_s.so.1" pid=1240 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<Chipaca> sergiusens: ^^^
 * Chipaca votes compiling everything statically with musl
<Chipaca> sergiusens: the fix is easy, but i want to figure out why arm uses that library and intel doesn't. in the morning tho
#snappy 2015-07-01
<h00sier> I can't seem to set up a bridge for my snappy img running in qemu-kvm
<h00sier> any ideas?
<mvo_> sergiusens: hmmmm, right, native is not ideal indeed, sorry for overlookng this
<dholbach> good morning
<seb128> hey dholbach & snappy world
<dholbach> salut seb128
<dholbach> how are things in snappy land
<dholbach> ?
<seb128> good, still working on getting personal to work ;-)
<dholbach> yeah, I saw some uploads of yours - looks like it's a bit more work enabling everything
<seb128> yeah, let's see how things look like today
<fgimenez> good morning
<vmayoral> morning!
<seb128> mvo_, bah, you broke ubuntu-core/desktop-next builds :p
 * seb128 fixes
<seb128> or not
<seb128> mvo_, let me know when you are around to discuss the issue :-)
<mvo_> seb128: whats the issue? clickpkg -> snappypkg  ?
<seb128> yes
<seb128> https://launchpadlibrarian.net/210397648/buildlog_ubuntu_wily_i386_ubuntu-core-system-image_BUILDING.txt.gz
<mvo_> seb128: sure, let me look
<mvo_> seb128: sorry, but that the only way to know if it works, upload and hope for the best. no local testing :(
<seb128> mvo_, btw you had your changes commited as if they were uploaded, but they were not
<seb128> so I changed back to unreleased, batched some desktop-next tweaks and uploaded
<seb128> hope that was ok ;-)
<seb128> mvo_, you can do a local build, it just takes a while
<mvo_> seb128: sure, I though I did upload, I guess may I should go to bed
<seb128> mvo_, https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html has "howto build locally"
<seb128> need to adapt the PROJECT/SUBPROJECT env variables
<seb128> but that works (or at least enough to check the groups thingy)
<mvo_> seb128: I'm not sure that works in the age of LP builders
<mvo_> seb128: oh, you checked it works? nice
<seb128> yeah, I did the user/group config for desktop-next using that
<seb128> mvo_,
<seb128> "Setting up ubuntu-snappy-cli (1.2-1+524~ubuntu15.10.1) ...
<seb128> Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory
<seb128> Adding system user `clickpkg' (UID 109) ..."
<mvo_> seb128: the build failure is due to a out-of-sync issue of snappy and livefs rootfs
<seb128> seems like ubuntu-snappy-cli creates this group
<mvo_> if Chipaca can review https://code.launchpad.net/~mvo/snappy/snappy-gettext-fix and https://code.launchpad.net/~mvo/snappy/snappy-gettext-fix2 we should have a working image again
<mvo_> seb128: yeah, it does create the snappypkg user in trunk but trunk failed to build for unreleated reasons so they got out of sync
<mvo_> seb128: but all my faul, once the fixes above land we should be good again
<seb128> mvo_, any estimate of when you can land those fixes?
<seb128> I'm sort of waiting on a new image build to continue my personal work
<mvo_> seb128: once someone reviews them, you can do that too if you want, should all be pretty small/obvious, I just need a ACK on the MP :)
 * seb128 looks
 * conyoo error parsing serv.dat
<seb128> mvo_, those look good to me, I comment approved but can't approve the mp, not in the right team
<mvo_> seb128: sure, thats fine
<mvo_> seb128: thanks
<seb128> yw!
<mvo_> seb128: great, I top-approved, once they are merged (every 10min) I will trigger a build and once that is available we can do new images
<seb128> mvo_, do you plan to upload to wily as well?
<mvo_> seb128: oh, you don't use our ppa, sure, I will do a upload
<seb128> mvo_, thanks
<seb128> and no, we don't use the ppa
<seb128> we are good citizens ;-)
<seb128> mvo_, tarmac doesn't like my +1
<seb128> "Voting does not meet specified criteria. Required: Approve >= 1, Disapprove == 0. Got: 1 Pending."
<mvo_> seb128: silly thing, I approved now as well to make it happy. we can't block oyu
<mvo_> you
<JamesTait> Good morning all; happy Mailman^WPostal Worker Day! ð
<seb128> mvo_, thanks for the snappy upload ;-)
<Chipaca> mvo_: aw, for a moment i thought you were fixing the apparmor thing for arm :)
<Chipaca> mvo_: (ubuntu-core-launcher seems to need an additional .so on arm than on intel, at least last night)
<ogra_> seb128, mvo_, i dont think the fix that was uploaded will work
<ogra_> you only fixed the fallout ... the reason for the failure is the switch from clickpkg to snappypkg
<seb128> ogra_, ?
<seb128> ogra_, snappy changed its group from clickpkg to snappypkg
<seb128> ogra_, mvo updated the groups in livecd-rootfs to reflect the change
<seb128> but that was uploaded before ubuntu-snappy
<seb128> with the new version there is no clickpkg user anymore
<seb128> why would it fail?
<ogra_> because there is a snappypkg user now
<ogra_> or snappkg
<ogra_> (not sure how exactly it is called)
<ogra_> the user was just renamed ... but your livecd-rootfs change doesnt have that rename
<seb128> ?
<ogra_> http://launchpadlibrarian.net/210413322/livecd-rootfs_2.320_2.322.diff.gz
<seb128> ogra_, https://launchpadlibrarian.net/210356511/livecd-rootfs_2.319_2.320.diff.gz
<ogra_> oh, i missed that
<ogra_> ignore me then
<seb128> ogra_, my upload from today was to fix the ":ubuntu" missing after I tweaked the groups yesterday
<seb128> :-)
<mvo_> Chipaca: uh, arm failing? meh, no I did not look at this
<Chipaca> mvo_: ok, i'm looking :)
<Chipaca> ooh, maybe it's the 32bit-ness, not the arm-ness
 * Chipaca tries with x86
<Chipaca> tyhicks: do you know of any reason we shouldn't include libgcc_s.so in the apparmor profile for ubuntu-core-launcher even on amd64 where it's not needed? it's needed on 32bit platforms and i'd rather not have a different profile for different bittiness
 * Chipaca makes a branch prediction
<mvo_> lol
<Chipaca> tyhicks: added you to https://code.launchpad.net/~chipaca/ubuntu-core-launcher/libgcc_s/+merge/263489 but probably should've added your team instead (which team should that be?)
<Chipaca> sergiusens: elopio: fixes https://bugs.launchpad.net/snappy/+bug/1470210 for you
<ubottu> Ubuntu bug 1470210 in Snappy "integration tests fail with: error while loading shared libraries: libgcc_s.so.1" [Undecided,New]
<Chipaca> i should move that to the launcher, shouldn't i
<Chipaca> there
<fgimenez> mvo_, Chipaca hi, i'm getting this http://paste.ubuntu.com/11803910/ on bbb, is it a known bug?
<ogra_> the dates look weird
<ogra_> how can 87 be newer than 88 ?
<rsalveti> haha, indeed
<fgimenez> ogra_, yep :, i got
<fgimenez> ogra_, the image with:
<fgimenez> sudo ubuntu-device-flash --revision -2 --verbose core rolling --output bbb-edge-2.img --channel edge --developer-mode --oem beagleblack
<ogra_> hmm, so is that timestamp created by u-d-f ?
<ogra_> i thought it comes from the server
<sergiusens> morning
<sergiusens> Chipaca: I'll defer on that one
<Chipaca> sergiusens: sure, wasn't asking you to review C code :) was just heads-up'ing you wrt it being fixed there
<ogra_> seems seb128 cant have his system-a/b partitions mounted by label on amd64
<ogra_> dont we use labels on grub installs ?
<sergiusens> Chipaca: it's a one liner :-P
<Chipaca> sergiusens: cee coooode
<Chipaca> sergiusens: scaaary
<ogra_> looks like neither root=/dev/disk/by-label/system-a nor root=LABEL=system-a works
<Chipaca> sergiusens: * not even code, let alone C :)
<Chipaca> ogra_: yes, we use labels
<ogra_> do we act special in any way on grub based installs ?
<ogra_> wird
<ogra_> *weird
<Chipaca> ogra_: and that works as far as i've been able to test it
<ogra_> k
<seb128> does it require some initramfs support we might be missing?
<Chipaca> seb128: efi?
<seb128> the partitions have label according to blkid
<Chipaca> ooohhh
<seb128> no, that's in virt-manager, I think standard grub
<ogra_> well, and udev should at least create the /dev/disk/by-label/ symlinks
<Chipaca> ah, no, then it should work
<ogra_> but seems they are not there either
<Chipaca> seb128: can you go to the grub console?
<seb128> Chipaca, http://people.canonical.com/~seb128/shot0001.png
<ogra_> Chipaca, how would the grub console help ?
<Chipaca> seb128: plz to grub console
<seb128> Chipaca, I need to go for lunch, people are waiting, but I'm going to have a look to that once back
<seb128> Chipaca, please give hints and I can read the backlog then ;-)
<Chipaca> ogra_: i'll do a search from there
<Chipaca> ogra_: as i know what i expect there
<ogra_> Chipaca, but the mounting happens from initrd, way later when the kernel took over already ...
 * ogra_ <- confused
<Chipaca> ogra_: but it's not finding root
<Chipaca> ogra_: which is specified by grub
<Chipaca> ogra_: so that's wrong, somehow
<ogra_> its not finding the labeled partition ... even with manually specifying root=/dev/disk/by-label/system-a or root=LABEL=system-a
<seb128> Chipaca, echo $root gives hd0,gpt2
<seb128> Chipaca, unsure what info you want/need
<seb128> shouldn't the LABEL thing be independant of that? it wouldn't boot at all if the boot was not correct
<ogra_> yes
<ogra_> thats what i mean
<ogra_> grub should only find the boot partition, load kernel and initrd and switch over
<ogra_> mounting happens from the initrd
<Chipaca> seb128: search --no-floppy --label system-a
<seb128> hd0,gpt3
<seb128> system-b on gpt4
<seb128> (which is the one I want/which has the /)
<Chipaca> seb128: echo $snappy_ab
<seb128> a
<Chipaca> ok, so now
<Chipaca> why is root gpt2?
<seb128> no idea, it's the snappy personal image
<seb128> Chipaca, the grub config is http://paste.ubuntu.com/11757708/
<Chipaca> ah, i don't know how that's partitioned
<ogra_> shouldnt differ from core
<Chipaca> augh. when is the new grub.cfg going to land already :)
<seb128> same as core
<Chipaca> seb128: ok, so your root should be system-a or system-b, not some other partition
<Chipaca> seb128: do this:
<Chipaca> set label="system-$snappy_ab"
<Chipaca> set cmdline="root=LABEL=$label ro init=/lib/systemd/systemd console=tty1 console=ttyS0 panic=-1"
<Chipaca> search --no-floppy --set --label "$label"
<Chipaca> linux /vmlinuz $cmdline
<Chipaca> initrd /initrd.img
<Chipaca> boot
<seb128> is that going to teach us anything?
<ogra_> (you probably dont want console=ttyS0 on a desktop system :) so you can see the messages on screen)
<seb128> I can boot fine using root=/dev/vda4
<seb128> gpt2 is a "system-boot" vfat partition
<Chipaca> seb128: vda4?
<seb128> k, really need to go for lunch
<Chipaca> what's vda4?
<seb128> sda4
<seb128> in a virt-manager vm
<ogra_> seb128, do you get a busybox after the mount error ?
<seb128> no, back to grub
<seb128> bbiab
<ogra_> i dont see a prompt in your pic
<ogra_> ah
<Chipaca> ogra_: console=tty1 console=ttyS0 puts it on both, afaik
<ogra_> no
<ogra_> the first one applies to kernel messages
<ogra_> the second one to userspace
<ogra_> so as soon as the kernel hands over to initrd the messages go to serial
<Chipaca> oh, that's not what we want
<ogra_> if you only set console= once it will apply to both
<ogra_> so you just want to drop console=ttyS0
<Chipaca> You can specify multiple console= options on the kernel command line.
<Chipaca> Output will appear on all of them. The last device will be used when
<Chipaca> you open /dev/console.
<ogra_> right
<ogra_> the last sentence is key :)
<ogra_> (having /dev imples userspace ;) )
<seb128> Chipaca, in any case u-d-f makes a system-boot vfat partition on personal, unsure why the $root points to that
<seb128> cyphermox or slangasek might know
<ogra_> well, the commandline is created durin livecd-rootfs if i'm not wrong
<Chipaca> system-boot is where grub lives, system-a or system-b is where the kernels and initrds live
<Chipaca> (in the current scheme, that is going to change rsn)
<ogra_> ah, no, livecd-rootfs doesnt set any root= arg ... it only sed's /etc/default/grub for systemd stuff etc
<Chipaca> seb128: you asked me whether we'd learn anything from entering all the above; the answer is that we'd learn whether the future grub.cfg would be able to boot this, whatever it is :)
<Chipaca> ogra_: so, console=ttyS0 console=tty1 is what we'd want, right? to have serial for kernel/early boot but everything else on tty1 as expected?
<ogra_> yeah, sounds right
<ogra_> i still dont get where grub is involved with the rootfs mounting (beyond handing the cmdline over to the kernel)
<ogra_> the actual work happens inside the initrd ... and the initrd doesnt seem to have any knowledge of the labels
<Chipaca> ogra_: this might be the old grub config confusing me; reading the grub manual, there's nothing special about the root env var
<Chipaca> ogra_: afaict, just setting âroot=$rootâ in the linux commandline is what's expected
<ogra_> well, it works if seb128 sets root=/dev/vda1
<Chipaca> ogra_: the variable, or the commandline?
<ogra_> whatever is in /proc/cmdline
<ogra_> the initrd parses that
<ogra_> and then calls:
<ogra_>                 # convert UUID/LABEL to a device name
<ogra_>                 path=$(findfs "$root" 2>/dev/null || :)
<ogra_> so findfs doesnt return any usable thing
<Chipaca> seb128: is this reproducible? how?
<ogra_> parsing the cmdline happens very early in /usr/share/initramfs-tools/init ... mounting in /usr/share/initramfs-tools/scripts/ubuntu-core-rootfs
 * Chipaca -> grubby lunch
<sergiusens> Chipaca: mvo_ https://code.launchpad.net/~sergiusens/snappy/returnErrIfErr/+merge/263510
<Chipaca> sergiusens: ETOOMUCHERR
<sergiusens> Chipaca: we probably want to backport this one too
<Chipaca> sergiusens: i've got a couple of changes to that grub.cfg, when you're looking at that again
<Chipaca> sergiusens: can we have a test case?
<Chipaca> because i thought i'd fixed this before now :)
<sergiusens> Chipaca: sure
<Chipaca> sergiusens: if you're in the middle of somehting
<Chipaca> sergiusens: i can do the test case :)
<sergiusens> Chipaca: I am, but I can do it ;-)
<zyga> how can I ignore certain files for snappy build
<zyga> I don't want it to zip up verything in .
 * ogra_ hasnt found a way beyond moving the files out of the way
<zyga> sigh
<zyga> is there a bug on this?
 * zyga goes to file one
<ogra_> yeah
<zyga> https://bugs.launchpad.net/snappy/+bug/1470491
<ubottu> Ubuntu bug 1470491 in Snappy "snappy build should not zip everything in ., add an option to ignore certain paths" [Undecided,New]
<zyga> ogra_: have you seen snappy-device-agents?
<zyga> ogra_: https://code.launchpad.net/snappy-device-agents
<ogra_> do they wear black suits and sunglasses ?
 * ogra_ thinks he saw one on the street
<ogra_> :P
<ogra_> (no, havent heard if it yet :) )
<zyga> ogra_: it's a set of tools for deploying snappy images to devices automatically for the CI stuff we're working on
<zyga> ogra_: currently just BBB and _very_ hacky/underdocumented
<zyga> ogra_: but it's something you may want to look at
<zyga> ogra_: it's basically one day old now ;-)
<zyga> ogra_: merge requests and bug are much welcome
<zyga> https://code.launchpad.net/~zyga/snappy-device-agents/+git/snappy-device-agents/+ref/pex
<zyga> this branch as a way to create a snap out of that
<zyga> snappy deploying snappy
<ogra_> so thats the equivalent to phablet-tools ?
<zyga> ogra_: apart from deployment it can run adt tests
<zyga> ogra_: maybe, maybe not, it will be tailored to each device we have to support
<zyga> ogra_: p-t is far more consistent because it can rely on adb
<zyga> ogra_: here we may need magic voodoo :-(
<zyga> ogra_: depending real devices
<ogra_> well, you can kind of rely on serial for arm boards
<zyga> ogra_: we try to encourage the a/b/c method
<zyga> ogra_: yes, I know, I'm trying to convince plars to use it :)
<zyga> ogra_: we'll support many methods
<zyga> ogra_: exposing one interface/api/tools
<zyga> ogra_: depending on what kind of stuff you have you may pick
<Chipaca> zyga: we don't zip everything, fwiw
 * ogra_ isnt so thrilled by python though ... 
<zyga> ogra_: but in the end you can deploy any image to a bard
<zyga> Chipaca: oh? so what does snappy build do, --help is not saying anything useful and there is no manual page
<ogra_> but thats just personal preference
<zyga> ogra_: would you write this in go?
<ogra_> shell ;)
<zyga> ogra_: oh, shell is terrible ;-)
<zyga> ogra_: error handling
<ogra_> shell is lovely if done right ;)
<zyga> ogra_: I love shell but...
<zyga> ogra_: right, show me one script that handles errors and cleanup right
<Chipaca> zyga: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/snappy/build.go#L54
<ogra_> zyga, you know about the trap function, right ?
<zyga> Chipaca: wow CVS and darcs
<zyga> ogra_: sure
<zyga> ogra_: it's possible
<zyga> ogra_: just _hard_
<ogra_> nah
<ogra_> not hard :)
<Chipaca> zyga: it's like a list of past mistakes
<ogra_> anyway, you picked py ... i'll get along
<zyga> Chipaca: I think the bug stands, it's not possible to tweak this and the defaults are not optimal (or can be in general)
<zyga> ogra_: we picked CLI for now, the implementation may be totally different for each tool
<Chipaca> zyga: i wasn't disagreeing with the bug :)
<zyga> Chipaca: ah, thanks, I misunderstood
<zyga> ogra_: we just want to get started, deploy this and let it be used via the CI message queue
<ogra_> right
<zyga> ogra_: we'll see what kind of API we can provide at this level
<zyga> ogra_: but the external api for this will be the message queue
<zyga> ogra_: later on I'll probably build something more like lava where you have a http API for sending test jobs
<zyga> Chipaca: what is DEADJOE?
<zyga> Chipaca: that list is pretty full of magic
<ogra_> lol
<Chipaca> zyga: as the comment says, it's inherited from other places
<zyga> or ,,
<Chipaca> DEADJOE i believe is no longer used, but used to be joe's tmpfiles
<ogra_> anyone here using the joe editor ?
<zyga> ogra_: ahh
 * ogra_ thought that was dead since a decade or so :P 
<zyga> ogra_: it seems this list predates that :)
<ogra_> i wonder if people using joe for editing also use elm for mail :)
<zyga> ogra_: yeah, both of them do ;-)
<Chipaca> hah! it still creates 'em
<Chipaca> and ,, is from baz, apparently
<ogra_> ah, i thought it was cunieform
<zyga> wow
<ogra_> sine we seem to want backwards compatibility to the beginnings of mankind
<zyga> but no tla support
<zyga> I'm dissapointed ;-)
 * ogra_ is off to the dentist
<rsalveti> ogra_: good luck :-)
<mvo_> fgimenez: you did not get a reply to your question about http://paste.ubuntu.com/11803910/, did you? if not, I look now
<fgimenez> mvo_, ok thanks :)
<mvo_> seb128: is this  failure something new? the boot issue? iirc you mentioned that it was working before(?)
<Chipaca> seb128: i just built a personal image and it boots fine, so please fill us in on what you're doing :)
<Chipaca> it doesn't do much *more* than booting, but that's probably not snappy :)
<seb128> Chipaca, what grub entry do you boot? and on uefi?
<seb128> mvo_, which issue?
<Chipaca> seb128: you boot uefi using virt manager?
<seb128> Chipaca, no, but maybe you use uefi and that works? ;-)
<seb128> just checking
<Chipaca> seb128: no, kvm, i don't touch grub and it just works
<seb128> shrug
<mvo_> seb128: that it does not boot
<seb128> how did you build the image?
<seb128> Chipaca, "u-d-f personal rolling --channel edge --output img.img"?
<seb128> mvo_, the cloud-init hang or the invalid grub config?
<Chipaca> seb128: no --oem? i'll try without an oem and see
<mvo_> seb128: invalid grub config
<seb128> Chipaca, no oem no
<seb128> mvo_, since ever, but there is an "ubuntu" entry in the grub menu which does work
<mvo_> ok
<Chipaca> ok, gotta fly, but will continue with this after
<seb128> Chipaca, thanks, I'm going to try with a new image in a bit, but nothing changed this week so I doubt that got magically resolved
<seb128> mvo_, you didn't do the seed update needed for the ubuntu-snappy migration?
<mvo_> seb128: I did, not uploaded yet though, sorry
<mvo_> seb128: I do that now
<sergiusens> mvo_: on s-i updates I get system-image-cli: error: unrecognized arguments: --progress json
<seb128> mvo_, thanks
<sergiusens> mvo_: almost therewith update grub
<mvo_> sergiusens: hrm, is system-image-cli installed on the system? or is it still using system-image-snappy-cli ?
<sergiusens> mvo_: in what image was it removed?
<sergiusens> or swapped
<mvo_> sergiusens: in the same that switched to the new way of calling it - at least in theory
<sergiusens> mvo_: which one is the new way? --machine-readable or --progress json ?
<mvo_> sergiusens: the new one is progress json
<mvo_> sergiusens: so if that arg is used the image should have s-i-cli instead of s-i-snappy-cli
<sergiusens> mvo_: hard to tell with no dpkg info ;-)
<mvo_> sergiusens: :-D
<mvo_> fgimenez: thanks again for the crashreport, there will be a branch shortly
<fgimenez> mvo_, np, thank you, elopio found it yesterday running the integration tests on the bbb (he is really brave :)
<fgimenez> mvo_, at first we thought it may be related to the tests
<tyhicks> Chipaca: ubuntu-security would be the team
<seb128> tedg, hey, nitpick but can you look at https://bugs.launchpad.net/ubuntu/+source/url-dispatcher/+bug/1470531 ?
<ubottu> Ubuntu bug 1470531 in url-dispatcher (Ubuntu) "update-directory errors out on missing directory" [Undecided,New]
<tyhicks> Chipaca: approved - thanks :)
<sergiusens> mvo_: fgimenez oh, I fixed that bug in the update-grub work just now, was driving me nuts
<tedg> seb128, Sure, do you have a session systemd running?
<seb128> tedg, probably not since I don't have a session open
<seb128> it's a boot to the greeter and a systemctl --failed on vt9 from systemd.debug-shell
<tedg> seb128, ? Then how did that get run? It should be a session job.
<sergiusens> mvo_: fwiw, it crashes for grub as well ;-)
<seb128> tedg, hum, let me check, I might have logged into a vt on that boot
<sergiusens> mvo_: I think my fix is a lot simpler even if a bit more hacky
<seb128> tedg, but no desktop session for sure, just vt login
<tedg> seb128, To be clear, I think it can still be fixed, more curious.
<mvo_> sergiusens: :) I tried to make it less ugly but I don't mind as long as we fix it soon
<sergiusens> mvo_: I don't want to delay update-grub work more though
<elopio> hello.
<elopio> fgimenez: I followed your advice and moved the meeting 30 minutes.
<elopio> starting from tomorrow :)
<tedg> seb128, Looking through the code it seems that it should handle that case. Do you have a log file?
<fgimenez> elopio, ok :) i'm already there
<fgimenez> elopio, i've pushed the fixes you suggested to the build-test branch
<sergiusens> mvo_: so, latest image still has machine readable and latest snappy has --format json ...
<seb128> tedg, http://paste.ubuntu.com/11804973/
<sergiusens> mvo_: and client.ini looks really weird now
<mvo_> sergiusens: it does?
<sergiusens> mvo_: there's a client.inie now as well
<mvo_> sergiusens: *ick*
<mvo_> sergiusens: let me try to find out why we got the old one
<ogra_`> hmpf
<ogra_`> <ogra_> seb128, can you boot with break=premount (and also make sure to have no serial console on the cmdline) ?
<ogra_`> <ogra_> so we can take a look why findfs doesnt find a label or why udev doesnt set the links
<ogra_`> <ogra_> the break= should give a you shell in the initrd ... (if we didnt hack that out for snappy)
<seb128> ogra_`, let me try
<seb128> ogra_, "no serial console on the cmdline"?
<ogra_> yeah ... no "console=ttyS0"
<seb128> why not? (just curious)
<ogra_> because that would spawn the shell on serial
<ogra_> (and also print all output there)
<ogra_> at least in the constellation Chipaca showed before
<sergiusens> mvo_: http://bazaar.launchpad.net/~sergiusens/snappy/noUpdateGrub/revision/492
<sergiusens> mvo_: just missing some tests if the approach is good
<sergiusens> mvo_: so far the files get sync'ed, but I'm stuck on other broken things (and the fact about bootlader dir being nil took away most of my morning)
<seb128> ogra_, that reboots back to grub ...
<sergiusens> mvo_: lesson learned should be to panic instead of returning nil if you are going to panic anyways ;-)
<ogra_> damn
<ogra_> mvo_, sergiusens, is there a way to switch off the auto-reboot ?
<ogra_> in grub based systems
<sergiusens> ogra_: yeah, snappy config ubuntu-core
<sergiusens> autopilot: off
<ogra_> sergiusens, well, from outside the image
<ogra_> we need to debug the initrd
<sergiusens> ogra_: yes, create an oem package with autopilot off in the config
<ogra_> oh man
<ogra_> we need a cmdline option for such stuff :)
<sergiusens> ogra_: but the reboot on panic, you need to edit manually yourself
<sergiusens> ogra_: like, mount .img/system-boot, edit grub.cfg, boot
<ogra_> ah, itrs in the grub.cfg ...
<ogra_> seb128, can you turn it off there ?
<ogra_> sergiusens, does that generally prevent the shell (does it replace the std. panic() finction of initramfs ? )
<ogra_> *function
<tedg> seb128, I'm not sure what to do with that error, we're making directories and opening the database all before it happens. Normally I'd say we can access it, but it would seem that we already did.
<sergiusens> ogra_: we don't do any customization wrt panic
<ogra_> ok
<tedg> seb128, Here's the function, perhaps a second set of eyes will see something: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.15.10/view/head:/service/url-db.c#L26
<sergiusens> ogra_: it's just a cmdline -> panic=-1
<ogra_> right
<ogra_> seb128, drop that too, i think that disables the shell (so even if it wouldnt reboot it wouldnt spawn a shell with that option set)
<seb128> ogra_, "that"?
<ogra_> panic=-1
<ogra_> from the kernel cmdline
<dholbach> fgimenez, elopio: sorry for the mail spam - balloons and I just ended up in another meeting tomorrow, so we thought we'd shrink our open house meeting to just 30 mins - I think that should be fine
<seb128> ogra_, without that it boots to a kernel error
<ogra_> what does the error say ?
<seb128> let me try again in a vb
<seb128> bit
<seb128> I booted the vm to change the grub config
<ogra_> og, you do all that in a vm ?
<ogra_> then i could do it myself i suppose
<elopio> dholbach: sounds good.
<dholbach> thanks a bunch!
<fgimenez> dholbach, ok np for me
<dholbach> <3
<seb128> tedg, it's snappy and /root is ro it seems
<seb128> tedg, you don't handle mkdir failing
<tedg> seb128, ? I think we do: http://bazaar.launchpad.net/~indicator-applet-developers/url-dispatcher/trunk.15.10/view/head:/service/url-db.c#L39
<tedg> Though it probably doesn't make sense to run the click hooks for root
<seb128> ups, rather the sqlite3_open()
<seb128> tedg, I think ^ fails
<seb128> right
<seb128> I was going to say
<seb128> tedg, I think the "Unable to create tables" is from sqlite3_open(), that function creates the filename if it doesn't exists
<seb128> also I'm unsure why is /root should be ro of it that's another snappy issue to be resolved
<tedg> seb128, I guess what is confusing is that mkdir() in theory isn't failing, but making the file is?
<seb128> tedg, it's possible that the directory got created when I had a rw mount I guess
<seb128> so maybe local issue...
<seb128> or it's part of the image for some reason
<seb128> need to check
<tedg> Well, we'd still return an error if we couldn't make the directory.
<tedg> :-) It would just be an error that made more sense.
<seb128> right
<seb128> ogra_, unsure how to edit grub.cfg ... wouldn't it be easier if you/whoever wants to debug build a personal issue and kvm boot it? ;-)
<Chipaca> yeah, got it here
<seb128> Chipaca, you did? what did you change?
<Chipaca>  sudo ubuntu-device-flash --revision=-1 personal rolling --channel edge -o personal_x86.img --developer-mode
<seb128> compared to what?
<seb128> e.g what option did you use that gave a working grub earlier?
<seb128> it was the oem one?
<ogra_> seb128, yeah, is that possible with the std u-d-f yet ?
<seb128> ogra_, yes, using the wily version
<ogra_> ok
<seb128> ogra_, see the command Chipaca just gave
<Saviq> ogra_, hey, mzanetti mentioned there's a problem with the Pi GPIO on snappy, anywhere I can read more on that?
<ogra_> yep
<Chipaca> seb128: previously i'd used --oem generic-i386
<Chipaca> seb128: and that works
<ogra_> Saviq, no, the issue is with using custom or overlay dtbs to actually enable GPIO on the Pi
<Chipaca> seb128: at least as much as the ubuntu grub entry works without it
<seb128> Chipaca, hum, k
<seb128> unsure what's the difference
<ogra_> Saviq, we simply dont have proper support for that yet ... and specifically for the Pi it is tricky since the binary blob owns the actual dtb
 * Saviq looks suspicious at the choice of the Pi for the Matchbox then...
<ogra_> well, thats one of the reasons the Pi isnt officially supported
<Saviq> ogra_, one issue I have with an add-on 433MHz transceiver board from openenergymonitor is that the bootloader goes apeshit when it's connected, might that be related?
<ogra_> yes
<ogra_> you likely need the right dtb overlay to enable it
<Saviq> ogra_, so I'd need a custom device tarball?
<Saviq> == a custom image
<ogra_> you need a custom oem snap ...
<Saviq> right
<ogra_> but even then, no guarantees that the kernel works with that dtb
<ogra_> (i.e your dtb might define the right device but the module/driver might be missing)
<Saviq> and in that case I'd need to build a custom kernel
<ogra_> yes
<Saviq> ohkay, /me has his work cut out for him (/hethinks)
<Saviq> now who can tell me how to fix security_yaml_click_ security_yaml_ errors :/
<ogra_> Saviq, i'm working with ppisati to get that to work, it just isnt there yet
<Saviq> ogra_, maybe I can help?
 * Saviq hopes he could, instead of !helping
<ogra_> Saviq, sure, if i got something to try i'll let you know
<Saviq> thanks
<ogra_> seb128, Chipaca, found the issue i think ... /dev/vd* devices are indeed handled specially in the shipped udev rule in the initrd
<ogra_> KERNEL=="vd*[!0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}"
<ogra_> KERNEL=="vd*[0-9]", ATTRS{serial}=="?*", ENV{ID_SERIAL}="$attr{serial}", SYMLINK+="disk/by-id/virtio-$env{ID_SERIAL}-part%n"
<seb128> ogra_, oh, nice, where did he say that?
<ogra_> seb128, i pulled the device tarball and unpacked the initrd
<ogra_> lib/udev/rules.d/60-persistent-storage.rules in there
<seb128> k
<seb128> but that's only adding symlinks
<seb128> is that supposed to create issues?
<ogra_> no, but i think it makes it skip creating the by-label symlinks
<seb128> or is that taking over the normal by-label
<seb128> k
<ogra_> not 100% sure yet ... i'll have to dig a bit
<seb128> thanks for investigating this one
<ogra_> the set of rules we ship by default is definitely limeted though
<seb128> but make sure to not dup work with Chipaca there
<ogra_> might be a fallout from -touch
<Chipaca> waaait
<Chipaca> there is no initrd line
<ogra_> he is looking at the grub side of things :)
<Chipaca> in grub
<ogra_> oh !
<Chipaca> that might explain things
<ogra_> well, not why it boots with UUID ...
<Chipaca> the UUID entry does specify initrd
<seb128> or with root=/dev/vda3
<ogra_> at least then there wouldnt be a readonly and writable mount etc
<ogra_> it would boot rw directly into the root without initrd
<seb128> Chipaca, no, take the system-a entry, do "e", change the LABEL=... by /dev/vda3 and ctrl-X
<seb128> that boots without issue
<Chipaca> seb128: can you confirm there isn't an initrd entry in that entry?
<seb128> Chipaca, yes, I can
<Chipaca> seb128: pleasae do :)
<seb128> I just did
<seb128> you can probably on your image as well
<seb128> no?
<Chipaca> seb128: i saw it on mine, wanted you to confirm whether it was the same over there
<Chipaca> and yes, specifying root=/dev/sda3 for me makes it boot too
<seb128> my system-a boot option has no initrd
<Chipaca> but i'm assumign this just sidesteps the initrd entirely
<seb128> and changing the LABEL to a /dev makes it boot
<Chipaca> seb128: can you also check whether the system-a entry asks for a efi kernel and the otehr one doesn't?
<seb128> yes, I noticed that some days ago as well
<Chipaca> ok
<Chipaca> i'm now out of my depth wrt where the grub.cfg is coming form, but i'm going to blame sergiusens because he'll be able to blame the right person
<seb128> likely cyphermox / slangasek
<Chipaca> seb, if you specified an initrd it'd probably work
<seb128> cyphermox was looking at some of the grub issues
<seb128> k
<seb128> well unsure why we have those different entries
<seb128> and why the system-a/b ones don't have a initrd
<seb128> let's see in any of the grub knowing people can help though ;-)
<sergiusens> seb128: Chipaca maybe something is missing from our "overlay"
<Chipaca> seb128: the whole thing is changing for the better anyway :)
<ogra_> by throwing away 80% of it :=)
<Chipaca> YEAH!
 * Chipaca wipes the spittle off his screen
<mvo_> sergiusens: I just remember -it seems like go-flags makes description translations impossible, because its in the ` ` style struct options. maybe we need something else :/
<sergiusens> mvo_: oh fancy that
<sergiusens> mvo_: we will need a struct based thing then type Opt struct { Name, longDescription, shortDescription string, target [type] }
<Chipaca> mvo_: is that another bullet in go-flags' utility?
<Chipaca> feels like we're fighting it more than it's helping us
<sergiusens> Chipaca: we will drop it
<mvo_> Chipaca: yeah, I have the same feeling right now
<slangasek> seb128, Chipaca: the grub.cfg system-a/b entries come from a snappy-specific grub config file; I don't remember offhand which package it's from or the name of it, but it's in /etc/grub.d and should be obvious
<sergiusens> slangasek: ubuntu-core-config
<slangasek> right, that thing :)
<Chipaca> slangasek: i'm still blaming sergiusens for it
<slangasek> ok ;)
<sergiusens> Chipaca: did you look at the branch I gave you already?
<mvo_> its 09_snappy from ubuntu-snappy in grub.d
<mvo_> oh, yeah, that too
 * sergiusens points out that he hasn't been breaking the image these past days ;-)
<ogra_> just because nobody filed bugs et doesnt mean it isnt broken
<ogra_> *yet
<ogra_> :P
<sergiusens> ogra_: oh, we know it's broken ;-)
<Chipaca> sergiusens: noUpdateGrub?
<sergiusens> Chipaca: yes
<Chipaca> sergiusens: yes
<sergiusens> Chipaca: need to get n ack on the approach to get tests for that approach
<sergiusens> ogra_: btw, why is livecd-rootfs arch any?
<ogra_> sergiusens, is it ?
 * ogra_ never noticed
<sergiusens> ogra_: yeah, I noticed as I'm waiting on an arm64 builder :P
<sergiusens> ogra_: but it doesn't make sense, does it?
 * sergiusens wonders if slangasek has the answer
<slangasek> I don't know; it may be legacy
<slangasek> there used to not be a live-build, only livecd-rootfs - at that point a lot more of the logic was in the livecd-rootfs package
<sergiusens> slangasek: any idea how to make this go faster https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7596423 ?
<slangasek> sergiusens: well apparently I have access to bump build scores, which is interesting
<ogra_> for images  ?
<slangasek> for packages
<ogra_> thats likely controlled via ubuntu-cdimage membership
<ogra_> ah
<slangasek> sergiusens: I don't know what the arm64 builders are doing right now, but every time I bump the build score the time goes up :P
<mvo_> lol@slangasek
<slangasek> and I'm not going to bump it higher than -security, because it's not higher than -security ;)
<sergiusens> slangasek: wow, it was 5 first, then 25 and now 1hour :-/
<slangasek> yep!
<slangasek> you're welcome
<sergiusens> ogra_: I'm in ubuntu-cdimage and I don't see that...
<ogra_> sergiusens, yeah, me neither
<ogra_> was just wishful thinking :)
<sergiusens> I don't like that there's no queueing system based on payloads either
<ogra_> (it woudl make a lot of sense for cdimage members to be able to bump image build scores for sure)
<seb128> mvo_, shrug, that ubuntu-snappy grub config generator is 440 lines of code!
<ogra_> tiny
<sergiusens> seb128: we got rid of that though ;-)
<seb128> sergiusens, where? I'm looking at today's wily update
<sergiusens> seb128: but the image needs sorting for e2e testing
<ogra_> the kernel has 20mio lines ... whats 440 in that light :P
<sergiusens> seb128: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381
<sergiusens> seb128: those two
<seb128> sergiusens, ah, s/got ride/are getting ride ;-)
<seb128> rid
<sergiusens> seb128: it's all relative to where :P
<seb128> sergiusens, k, I guess we should better wait for that work to land to look at/debug grub config issues...
<seb128> Chipaca, ogra_, slangasek, mvo_, ^
<ogra_> seb128, yeah
<ogra_> sergiusens, but you really want to drop that serial console for personal ... is there a way we can make it conditional ?
<Chipaca> ogra_: we want to switch the order for non-personal too, no?
<Chipaca> for intel at least
<sergiusens> ogra_: just propose a branch for it
<ogra_> well, not sure ... will you always have an actual tty on intel ?
<sergiusens> ogra_: hurry before it moves to git
<sergiusens> :-P
<ogra_> yeah
<seb128> ogra_, is that creating issues? the image boots fine on an usb stick or in a vm with that config
<ogra_> seb128, it will be an issue for plymouth and if you acxtually want to see userspace boot messages on screen
<ogra_> (not sure we'll go on using plymouth on snappy or with Mir though)
 * Chipaca 'll propose a branch with these changes
<ogra_> well, do we have a way to conditionally decide what to put there ?
<ogra_> (do we know if it will be a vm vs real HW image)
<sergiusens> Chipaca: ogra_ the console stuff can go into a separate oem package too and personal can default to it
<ogra_> i think serial console is actualy only interesting for VM images
<ogra_> and perhaps for some exotic HW
<ogra_> but yeah, oem makes sense
<Chipaca> ogra_: sergiusens: https://code.launchpad.net/~chipaca/snappy-hub/grub-tweaks/+merge/263544
<ogra_> Chipaca, but then all kernel messages will go to serial (black screen on PC til the initrd kicks in) is that what we want ?
<ogra_> ( i definitely agree it is better than the former though :) )
<ogra_> i think we should resort to one console= entry to not hop around ... but that would need to be conditional based on the image type (in a VM you might want a getty on ttyS0 and all ... while on PC you wont)
<elopio> sergiusens: we can enable now launchpad translations, right?
<sergiusens> elopio: I think so
<sergiusens> mvo_: any update on system-image-cli?
<sergiusens> Chipaca: agreed ping about https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.25
<sergiusens> meh, arm64 blocks image builds too...
<Saviq> ogra_, ah, it looks like it's the serial port (ttyAMA0) that's the culprit in my case, is the console enabled on it on purpose?
<Saviq> or could it be dropped from the rpi snap?
<sergiusens> Chipaca: CopyFile doesn't overwrite though
<sergiusens> Chipaca: and I thought of it too, just forgot, now I see it failing :-P
<Chipaca> sergiusens: sigh
<Chipaca> sergiusens: if you can hold off half an hour, i'll ad a copyflag :)
<sergiusens> Chipaca: I can os.Remove or Rename, or what you say :-)
<sergiusens> Chipaca: I'll wait
<sergiusens> well, I'll walk the dogs and it would be 30' or so ;-)
<Chipaca> sergiusens: sounds fair to me :)
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/snappy/overwrite/+merge/263584
<Chipaca> darn, 10 minutes instead of 30
<Chipaca> now i need to go have a beer or something to spend the excess
<Chipaca> life is pain
<sergiusens> Chipaca: how about a test where it fails the copy if the flag is not set?
<Chipaca> sergiusens: sounds fair to me
<Chipaca> sergiusens: pushed
<sergiusens> Chipaca: branch updated
<sergiusens> Chipaca: no we need the correct system-image-cli
<Nissyen> Why does "sudo aa-clickhook -f" have to be run on a core update sometimes?
<Chipaca> Nissyen: wha?
<Chipaca> Nissyen: manually, you mean?
<Nissyen> yeah.
<Nissyen> I had to run it to fix permissions on an update from 15.04/stable core-2 to core-3 update.
<Chipaca> Nissyen: shouldn't happen; it's a bug
<Chipaca> Nissyen: sorry :(
<Nissyen> OK, I filed a bug report on it: bug #1466682 .
<nothal> Bug #1466682: Docker unix socket permission issue on ubuntu-core update <Snappy:New> <apparmor (Ubuntu):New> <docker (Ubuntu):New> <http://launchpad.net/bugs/1466682>
<ubottu> bug 1466682 in docker (Ubuntu) "Docker unix socket permission issue on ubuntu-core update" [Undecided,New] https://launchpad.net/bugs/1466682
<Chipaca> Nissyen: thanks
<Chipaca> Nissyen: i removed docker and apparmor because this one is all ours :-/
<Chipaca> Nissyen: i'll take a poke at it in the morning
<Nissyen> Thank you very much. I have been experimenting with running containers on AWS and provisioning machines using cloudformation and the stable snappy AMI.
<Nissyen> Although I have used ubuntu for some time, snappy is a different learning curve, and I am not always familiar with what is going on.
<Chipaca> Nissyen: good on you for figuring out aa-clickhook fixed it, then :)
<Saviq> jdstrand, hey, can you see why http://pastebin.ubuntu.com/11807012/ would cause review errors for security_yaml_click_emonhub and security_yaml_services?
<Saviq> do I need to write the .snappy-systemd file myself?
<Saviq> oh... or do I not have the snappy-dev ppa enabled...
<Saviq> hmm I do :|
<Chipaca> Saviq: jdstrand is on vacation
<Saviq> *gasp* slacker
<Chipaca> inorite
<Chipaca> Saviq: what are the errors?
<Saviq> Chipaca, originally "ERROR: Could not find 'emonhub.snappy-systemd'"
<Chipaca> Saviq: where?
<Chipaca> i mean, doing what?
<Saviq> Chipaca, in the store auto-review (or using click-review locally)
<Chipaca> Saviq: which ppa do you have?
<Saviq> ppa:snappy-dev/tools
<Chipaca> correct
<Saviq> ubuntu-snappy-cli 1.1.1-0ubuntu1
<Saviq> not sure why it even mentions click... it's a snap
<Saviq> grr ^W
<Chipaca> heh
<Chipaca> Saviq: i don't know this part as much as i'd need to help you easily, but i fyou could share the whole snap i could take a poke at it
<Saviq> Chipaca, sure, https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d/download?path=%2F&files=emonhub-pi_1.0-2_multi.snap
 * Saviq wonders where to file a bug about ~ being allowed in version numbers but then breaking the systemd unit
<Saviq> i.e. systemd hates ~
<Chipaca> sergiusens: you around?
 * Saviq files in snappy
<Chipaca> Saviq: in snappy
<Saviq> bug #1470661
<nothal> Bug #1470661: Tilde allowed in version but systemd hates it <Snappy:New> <http://launchpad.net/bugs/1470661>
<ubottu> bug 1470661 in Snappy "Tilde allowed in version but systemd hates it" [Undecided,New] https://launchpad.net/bugs/1470661
<Saviq> oh yay, two bots :)
#snappy 2015-07-02
<sergiusens> Chipaca: I am now
<elopio> Hey mvo, I enabled the translations for snappy in launchpad.
<mvo> elopio: excellent, thanks a bunch!
<elopio> mvo: I wasn't quite sure about the configs to set, so maybe you'll like to take a look.
<elopio> I set autoimport and autoexport in trunk.
<mvo> elopio: nice, I have a look. we need to change the image seed too, right now iirc we don't have all the packages needed to get translations :)
<elopio> mvo: do you mean, to start snappy in a different language?
<mvo> elopio: yes, on a snappy system, I think we lack some of the required libraries/packages
<elopio> I see. I was wondering how to do that.
<elopio> but for now I'm happy. It will be good for the open house to encourage people to contribute translations.
<mvo> elopio: absolutely!
<dholbach> good morning
<seb128> hey dholbach & snappy crew
<dholbach> salut
<mvo> hey good morning seb128 and dholbach and fgimenez
<dholbach> hey mvo
<fgimenez> good morning mvo and all
<seb128> hey mvo
<Saviq> mo'ing
<seb128> hey Saviq
<Saviq> oi
 * ogra_ sihs about the size of personal 
<ogra_> *sighs
<ogra_> one day we'll produce desktop images that dont take a lifetime to download :P
<Saviq> it's not the size of the image that's the problem, it's your crappy internets, ogra_! ;)
<ogra_> yeah+
<ogra_> still, it would be good if ubuntu-device-flash and the system-image server could talk rsync
<Saviq> or delta, at least
<ogra_> re-downloading the whole thing every time is just so wasteful
<Saviq> ogra_, is console=ttyACM0  on Pi meant to stay? that seems to actually be my problem as the emon add-on uses serial to communicate
<Saviq> so the bootloader gets scared by all that happens on ttyACM0
<ogra_> yes, i think it is meant to stay for the default image
<ogra_> embedded boards = serial console
<Saviq> ok then, /me rolls a custom snap then, ogra_ do you guys have a branch for your main pi snap?
<ogra_> we might have a "gui oem snap" for it or some such though
<ogra_> in that i would drop it
<ogra_> no branch yet, you can just unpack it and modify as needed
<Saviq> kk
 * ogra_ puts "make branch" on his TODO
<ogra_> i have a half baked one for the overlay dtb support (needs also a spoecific device tarball with the last kernel), i'll upload that if this personal download ever finishes
<dholbach> hey rsalveti, did you get my open house mail?
<JamesTait> Good morning all; happy "I Forgot" Day! ð
<Chipaca> JamesTait: i don't even remember what i forgot!
<JamesTait> Chipaca, have you been drinking again?
<Chipaca> JamesTait: not today (yet), and only twice ever enough to forget
<JamesTait> Chipaca, so, success?
<mvo> Chipaca: hey, goooood morning! do you happen to know if there is anything blocking the noUpdateGrub branch from landing? if everything is ready I can land it today
<Chipaca> mvo: god morning!
<mvo> sergiusens: hi, for later - could you pass me the links for the passwd and adduser diff so that I can upload your fix?
<mvo> Chipaca: I hope that was a typo ;)
<Chipaca> ooh, my beuno script has a bug!
<Chipaca> mvo: god morning!
<Chipaca> indeed
<Chipaca>  /exec -o beuno mvo
<Chipaca> ^^ failing
<mvo> lol
<Chipaca> mvo: goooooooooooooooooooooooooooooooooooooooooooooood morning!
<mvo> loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool
<Chipaca> it's âecho -n "${1:-beuno}: g";eval printf "o%.0s" {2..$((RANDOM/512))}; echo 'd morning!'â
<ogra_> mvo, i think this was the final one for shadow http://paste.ubuntu.com/11778897/ ... the adduser stuff should be in an MP
<Chipaca> but /bin/sh doesn't have a RANDOM? guess i havne't used it in a while
<ogra_> Chipaca, shuf -i 1-100 -n 1
<ogra_> Chipaca, also ... https://wiki.ubuntu.com/DashAsBinSh the page every ubuntu dev should know by heart :)
<ogra_> (there is a more complex example for $RANDOM in a POSIX compliant way)
<Chipaca> ogra_: i was using dash (or ash?) as sh before the official switch
<Chipaca> ogra_: but i guess i never tested this thing after the last time i tweaked it? dunno
<ogra_> :)
<Chipaca> i was using some small sh back in debian, which was before warty
<mvo> ogra_: nice, thanks. I wasn't sure if there was a real branch for passwd or just the pastebin
<Chipaca> anyway
<Chipaca> mvo: in answer to your question
<Chipaca> mvo: i don't know what's missing, but sergio should be around soon
<ogra_> mvo, just the pastebin i think, but sergiusens might have made changes since so better have him confirm that paste as final
<mvo> ok
<mvo> thanks Chipaca and ogra_
<Chipaca> there's still some question around console
<ogra_> more than one ... see Saviq above about the RPi :)
<Chipaca> ogra_: where?
<ogra_> i think console shoul dprehaps become an option to u-d-f or some such
<ogra_> Chipaca, in the backlog ... his RPi runs sime peripherial HW attached to the serial console ... our default image uses that device as console device and crashes his HW ...
<ogra_> we need to find a more flexible way to set console altogether i think
<ogra_> on all images
<ogra_> and grub shouldnt use two console entries, IMHO all output from the boot should go to the same console device
<ogra_> (preferably the one where also your getty will start once finished)
<Chipaca> the default image also runs a getty on serial afaik
<Chipaca> or is that a freebie from it being console?
<rsalveti> morning snapers
<ogra_> snaaapers :)
<rsalveti> ogra_: I think we'd just need another oem for rpi2 that would not use the serial port by default
<rsalveti> since unless hardcoded in the kernel, that's just a cmdline option, right?
<ogra_> rsalveti, i think we need a gerneral solution for console=
<ogra_> rsalveti, grub has similar probs
<rsalveti> ogra_: what are the problems with grub?
<ogra_> (not actually killing hardware ... but cloud definitely wants serial while desktop will definitely want tty)
<ogra_> we need a more flexible way to define it at image creation time IMHO
<rsalveti> problem with options at the image creation time can make the same image behave differently
<rsalveti> which is why having another oem is so cheap
<ogra_> i dont want "options" i want one option ;)
<rsalveti> oem/gadget
<rsalveti> for now, yeah :P
<ogra_> --console=serial|native
<ogra_> something like that
<rsalveti> right
<rsalveti> sergiusens: ^^
<ogra_> nothing you can freely define ...
<ogra_> just a switch
<ogra_> (it is ugly to mangle the cmdline during build, i know that, but i dont see a better way)
<ogra_> (unless we want to have a ton of duplicate oem snaps for each device just for one option changed)
<Chipaca> --console=serial|network|native ;)
<ogra_> hah, even a third option :)
 * ogra_ didnt think about network :) 
 * ogra_ laughs about balloons' open house mail ... switching folders in my mailer is like zapping on TV and always seeing the same ad on all channels
<Chipaca> asac: rsalveti: mvo: sergiusens: should i re-enable click-review on build?
<Chipaca> asac: rsalveti: mvo: sergiusens: i ask because bug #1470265
<nothal> Bug #1470265: Binary with an underscore fails to produce an apparmor profile <Snappy:New> <http://launchpad.net/bugs/1470265>
<ubottu> bug 1470265 in Snappy "Binary with an underscore fails to produce an apparmor profile" [Undecided,New] https://launchpad.net/bugs/1470265
<asac> Chipaca: did the error messages get cleaned up yet?
<Chipaca> asac: if by that you mean has it caught up with current snappy, yes
<Chipaca> asac: there might be things still improperly reported as broken, because not enough testing, because we're not using it :)
<asac> Chipaca: no, i mean are the errors it spits out now readable and complains only about things that are really issues?
<Chipaca> in particular there's at least something about systemd units that seems off
<Chipaca> asac: the majority of things it complains about are actual issues; the (mostly hypothetical) remaining things are bugs we need to address
<Chipaca> asac: but either we start using it, or we start reimplementing it in 'snappy build'
<Chipaca> asac: snappy assumes you've used it, and does not do deep checks
<Chipaca> asac: so things break in strange ways
<Chipaca> asac: (as in the linked bug)
<asac> Chipaca: so is the bug that a snap install fails ?
<Chipaca> asac: also in the linked bug: the full output from the review tool for a modified 'hello-world' that reproduces the issue
<asac> e.g. bails out ...?
<asac> e.g. you build and you install, and then a) it does not install or b) does not work right?
<Chipaca> asac: no, the bug is that snap install does not bail, but fails to do all the things it should, afaik
<Chipaca> (b)
<Chipaca> mostly (b)
<Chipaca> things we catch and fail on, we mostly catch at build time too
<Chipaca> (mostly!)
<asac> so i think there are two times of checks. all checks that ensure that a nsap can be installed and work shoudl be in snappy build
<asac> all things we dobnt want by policy should be in review tools
<Chipaca> asac: that's pretty much all of the review tools
<asac> right, then parts need to be moved
<asac> whatever needs checking for runtime reasons isnt review tools
<asac> review tools is really abotu not allowing certain options that otherwise dont cause issues
<asac> e.g. you add custom profile groups to your snap is technically working
<asac> just not allowed
<Chipaca> asac: want to say as much in that bug?
<ogra_> asac, well, it is checking the options in the .yaml files ... i dont think it helps the above bug to re-enable the review tools though, binaires with underscores simply need to be supported ... (there are surely plenty)
<ogra_> (and the check needs to go once snappy got fixed to support them)
<Chipaca> ogra_: it's not snappy but apparmor
<ogra_> well, apparmor then
<asac> Chipaca: think did that now
<asac> also included ogra's input
<Chipaca> yup
<Chipaca> thanks
<ogra_> hah
<ogra_> *snap*
<ogra_> 10 seconds apart :)
<Chipaca> sabdfl: note bug 1470265 is about _s in binaries (ls /usr/bin | grep _), not in package names
<ubottu> bug 1470265 in Snappy "Binary with an underscore fails to produce an apparmor profile" [High,Confirmed] https://launchpad.net/bugs/1470265
<Chipaca> possibly the same argument applies, but it does mean renaming things like "document_viewer" (the core app document viewer that originated the bug report)
<ogra_> yeah, we cant really anforce that
<ogra_> *enforce
<Chipaca> ogra_: well, we are right now, in the "neener neener no apparmor for you" sense
<ogra_> yeah
<sergiusens> morning
<sergiusens> mvo: https://trello.com/c/BnuEpCft/134-support-extrausers-for-adduser-useradd-and-groupadd
<sergiusens> asac: rsalveti ogra_ as I mentioned in the document for gadgets, we can use grubenv for specific options as well
<ogra_> sergiusens, on arm ? :P
<sergiusens> ogra_: trollolololol
<ogra_> :P
<ogra_> sergiusens, i think we need some global way to set console=
<ogra_> arch and device independent
<sergiusens> ogra_: we can support this, but not right away
<ogra_> yeah, i didnt expect it today :)
<sergiusens> ogra_: on arm we can just have the default boot line in snappy-system.txt read from an additional variable in uEnv.txt
<ogra_> sergiusens, no
<sergiusens> to support the default case and would be similar to grubenv
<ogra_> sergiusens, i want a way that doesnt require touching the oem snap
<sergiusens> ogra_: oh, snappy config
<ogra_> being able to use the same image on serial and non serial setups
<sergiusens> ogra_: then you get to right yaml ;-)
<ogra_> so the first boot goes to the right console device
<ogra_> i think it needs to be a udf option
<sergiusens> *write
<sergiusens> ogra_: no thanks, no more u-d-f options
<ogra_> well, thats the only way
<sergiusens> I get slaughtered by adding them from people looking at crisp syntax ;-)
<ogra_> unless you can show me something else without me modifying any parts of the image
<sergiusens> ogra_: live feed a snappy config is the best thing I can think of (as in "preactivate")
<ogra_> so writing a one liner yaml file that gets parsed by udf ?
<sergiusens> ogra_: or pass it a file path
<ogra_> and you prefer that over a cmdline option ?
<ogra_> (its not really different, just more work for the user)
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-fix-bbb-crash/+merge/263530 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/filter-tests/+merge/263222 | Approve: 1 (2 days old)
<nothal> https://code.launchpad.net/~mterry/snappy/selftest-reboot-notice/+merge/262265 | Approve: 1 (14 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-console/+merge/262061 | Approve: 1, Needs Fixing: 1 (15 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-verify/+merge/261718 | Needs Fixing: 1 (20 days old)
<dholbach> thanks rsalveti
<Chipaca> sergiusens: hola! what's missing for noGrubUpdate?
<sergiusens> Chipaca: I rebuilt the image last night, what is missing is a proper e2e test
<ogra_> mvo, seb128 desktop-next is still unhappy about the clickpkg user ?
<seb128> ogra_, yes, I'm looking at that
<seb128> it's because it inherits from touch-core
<mvo> oh, it worked fine  in core
<ogra_> cool (just got the mail from nusakan)
<seb128> which includes packagekit-plugin-click
<seb128> which brings click
<seb128> which creates clickpkg user
<seb128> which fails the build because that got cleaned out from the prebuild list
<seb128> mvo, ogra_ ^
<ogra_> seb128, so re-add it
<ogra_> assuming you want to support click packages on dekstop-next
<mvo> seb128: just give it a different uid/gid, we will hardcode that in snappy
<seb128> is that going to work on snappy?
<ogra_> (or is that mutually exclusive vs snap)
<ogra_> seb128, heh, no idea :)
<seb128> I was going to hack livecd-rootfs to uninstall packagekit-plugin-click on desktop-next
<seb128> mvo, do you think we want click on snappy personal?
 * ogra_ would keep it for the start to have more apps available ... if snap and click can actually coexist 
<ogra_> once the click packages were migrated thats indeed pointless
<seb128> yeah, unsure if click works on snappy, probably needs some dirs to be made rw, unsure if they are
<seb128> also currently the click scope is installed, but unsure if the snap one is going to be co-installable or replace it
<ogra_> (having a terminal would surely be helpful ;) )
<ogra_> so if clicks dont work, it might make sense to have a terminal snap ahead of time :)
<sergiusens> mvo: did you see my reply wrt clickpkg/snappypkg?
<seb128> mvo, sergiusens, do you have opinion on including click on not or personal?
<seb128> or->on
<sergiusens> seb128: wouldn't that be confusing in the end?
<mvo> sergiusens: yes, I think you are spot on, I like the config idea
<sergiusens> mvo: oh goodie /usr/share/snappy/ or similar?
<seb128> sergiusens, having click?
<sergiusens> seb128: yeah, click and the click scope and then snappy and the snappy scope
<mvo> sergiusens: yeah, I think so, part of ubuntu-core-config I guess so that its easy to split between 15.04 and 16.04
<seb128> sergiusens, unsure, but atm we don't have snappy scope yet
<ogra_> Chipaca, WRT the network interface naming, did we actually do anything about it ? (seems it all works atm and i wonder why, did pitti revert anything ? )
<seb128> mvo, ^ opinion?
<Chipaca> ogra_: no, it's still broken (on intel)
<ogra_> oh
<pitti> ogra_, Chipaca: no, I didn't revert anything, but awe was talking to me about ofono
<ogra_> i'll start a ML thread about it then ...
<pitti> we discussed it in bug 1467640 and PM, and I gave some suggestion
<ogra_> just wanted to know the status quo, since i had not heard anything about it anymore
<ubottu> bug 1467640 in ofono (Ubuntu) "No mobile data connection for mako on wily" [High,Confirmed] https://launchpad.net/bugs/1467640
<sergiusens> seb128: it's just my personal opinion that if you add it, it will be hard to remove in the future
<mvo> seb128: hmmm, I'm not if mixing the two is a good idea, I think they might get confused, especially click as there will be files in /apps that do not have the meta-data that click expects
<sergiusens> seb128: and maybe kyrofa can share is scope preview with you
<sergiusens> seb128: but it would be mostly unpopulated
<ogra_> pitti, ah net.ifnames=0 sounds good
<seb128> mvo, so should I just remove click and package-plugin-click from a livecd-rootfs hook?
<ogra_> (though i guess we will eventually need to support that stuff)
<pitti> ogra_: if that's just about ofono, I suggested that we disable the ifnames just for the rmnet* devices, isn't that easier? (doesn't require changing kernel params or other image changes0
<ogra_> pitti, well, i dont really care specifically about rmnet
<ogra_> this is more about eth0 which is hardcoded in half the world
<pitti> ogra_: did that break anything else?
<sergiusens> mvo: do you want to do the config or should I? And should we use numbers or names/strings?
<ogra_> yes, snappy VM images
<pitti> ogra_: oh right, sorry -- I thought I was talking on #u-touch :)
<ogra_> we ship /e/n/i.d/etc9 by default pre-built
<ogra_> *eth0
<sergiusens> mvo given the stricktness of uid/gid, matching with numbers is fine in my opinion if it is in a config (not in code ala android ;-) )
<ogra_> well, rmnet will affect snappy phones at some point :)
<mvo> sergiusens: I can do it, unless you really want to, I won't stand in the way of course
<ogra_> so it isnt totally offtopic
<kyrofa> seb128, I do indeed have a snappy scope
<sergiusens> mvo: go ahead ;-)
<ogra_> but for the moment we have no networking on kvm images ... that needs immediate action
<mvo> sergiusens: I was thinking that uid/gid by number will not work on desktop installs of ubuntu-device-flash as its generated dynamically there :/
<mvo> sergiusens: I switch networks now, trying to find a place that is less hot :)
 * mvo is back in 2minutes
<ogra_> seb128, heh, i just booted my first kvm personal ... how did you even manage to take that picture yesterday ... the reboot is so fast i cant read what it prints
<kyrofa> seb128, is this for the personal image?
<sergiusens> mvo: we can read from the snappy sysroot though
<seb128> kyrofa, yes
<seb128> ogra_, I filmed the boot with my bq and went frame by frame on the movie with mplayer
<ogra_> LOL !
<seb128> :-)
<ogra_> wowo
<ogra_> -o
<kyrofa> seb128, awesome! Right now, the snappy scope runs by utilizing the webdm API. It'll move to using the snappy service when its API is finished
<seb128> kyrofa, great
<kyrofa> seb128, lp:unity-scope-snappy
<seb128> kyrofa, thanks
 * ogra_ guesses popey should work on a terminal-app snap then ;)
<seb128> kyrofa, I'm not looking at that yet, trying to get an image to boot and start unity8 first, but then it's next
<kyrofa> seb128, very cool. I've got an orange matchbox here if you get to the point where I can help with anything
<seb128> kyrofa, ok, noted, thanks :-)
<kyrofa> seb128, of course! :)
<dholbach> rsalveti, asac: newest incarnation: https://i.imgur.com/pF720DL.png - deployment will take a bit longer
<dholbach> kudos to davidcalle for his great styling work :)
<ogra_> seb128, so with modifying grub.cfg i get it to boot here ...
<ogra_> (the boot takes nearly 10min in kvm though, but i see a greeter with guest session)
<seb128> yeah, that's expected
<seb128> if we ever get a image to build without cloud-init you should see the ubuntu user and be able to log in :p
<ogra_> oh. it is still in there ?
<ogra_> k
<kyrofa> seb128, if you let me know when you've got an image with unity8, I can actually package the scope as a snap for you
<ogra_> heh, yeah, clicking on the passwd field gets me a black screen now
<seb128> right
<seb128> ogra_, bug #1307618
<nothal> Bug #1307618: Unity 8 Desktop Preview does not work in the guest session <unity8-desktop-session (Ubuntu):Confirmed> <http://launchpad.net/bugs/1307618>
<ubottu> bug 1307618 in unity8-desktop-session (Ubuntu) "Unity 8 Desktop Preview does not work in the guest session" [Medium,Confirmed] https://launchpad.net/bugs/1307618
<ogra_> yup
<seb128> kyrofa, we have an image that works if you manually hack around a bit
<seb128> hopefully less manually hacking by tomorrow
<kyrofa> seb128, are you planning to do unity8 as a framework?
<seb128> kyrofa, is that doable with what framework can do?
<kyrofa> seb128, I actually have no idea :P
<seb128> kyrofa, but currently no, I think framework are too limited
<seb128> eventually we are getting there
<seb128> but not in the first iteration
<kyrofa> seb128, that makes sense
<kyrofa> seb128, okay, so the snappy scope won't have any framework dependencies other than webdm
<seb128> k
<kyrofa> seb128, and we just hope that no one tries to install it on Ubuntu Core :P
<seb128> hehe
<mterry> mvo, I just saw your comment on the clean-up card
<mterry> mvo, but unfortunately, I've been doing a lot of disruptive cleanup on the demo branch
<ogra_> seb128, so now when i boot with all console= args dropped i actually see the errors :)
<ogra_> clould init actually tries to pull some remote file via http and fails ... thats why it takes so long
<mterry> mvo, and your branches don't merge well at all anymore.  I've also done some pep8/pylint cleanup myself -- will try to see what your run-checks does vs mine
<mvo> mterry: sure, no problem. let me know if I can help in any way here
<mterry> mvo, what's the story with pyflakes vs pylint?  Is one better/more-maintained than the other?
<seb128> ogra_, right, and worth, that results in not having an "ubuntu" user working, which is why we remove cloud-init
<mvo> mterry: I have not investigated pylint in a while, when I used it last some years ago I got quite a few false positivies, pyflakes fit my needs better, but that might have changed by now
<ogra_> seb128, yeah
<mterry> mvo, will try -- pylint3 crashes on one of my files...
<mvo> heh
<ogra_> seb128, just saying, there is no way to even see the errors with the console= args we set by default
<seb128> ogra_, well, "try to remove", still fighting issues due to mvo's clickpkg->snappypkg :p
<ogra_> evil mvo !
<seb128> ogra_, without those it boot loop to grub anyway no?
 * ogra_ tries to manually add a user in the mounted partition :)
<mterry> mvo, pyflakes is nicer indeed  :)
<ogra_> seb128, nope, i only needed an initrd line and drop the panic and console= args
<ogra_> which gets me a proper boot
<seb128> k
<seb128> do you know why the config is not having an initrd?
<seb128> well, we should wait for the grub cfg refactoring work to land to look at that more
<seb128> issues might just be outdated
<ogra_> seb128, no, but Chipaca does i think
<ogra_> right, the next build might be fine
<ogra_> not sure what landed yet
<ogra_> hmm
<ogra_> ogra@anubis:~/datengrab/personal$ cat mnt/var/lib/extrausers/passwd
<ogra_> ubuntu:x:1000:1000:ubuntu,,,:/home/ubuntu:/bin/bash
<ogra_> seems the ubuntu user actually exists
<seb128> ogra_, yeah, but it has no passwd or that is screwed in some way
<seb128> I set the passwd from a systemd.debug-shell shell and then I can log in
<ogra_> it doesnt look like mouse or kbd work for me
<ogra_> on the greeter
<seb128> weird
<seb128> wfm
<ogra_> (doubleclick does, but nothing else)
<ogra_> and there is no pointer
<elopio> fgimenez: lets skip the hangout today, unless you have something to talk about.
<fgimenez> elopio, ok, nothing special, i've put in review filter-test again and was able to reproduce the udf issue
<elopio> fgimenez: cool, I'll will look at the branch.
<elopio> anybody has an idea about what's going on here? https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1470727
<ubottu> Ubuntu bug 1470727 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed]
<fgimenez> elopio, ok thanks, the idf issue seems to be related to something else different from the image version or even udf, which hasn't been updated lately
<fgimenez> *udf
<sergiusens> elopio: fgimenez heh, mvo is taking care of that; it's related to the latest landing of changing clickpkg to snappypkg as the user to install under
<sergiusens> mvo: I have a hackier solution; just create clickpkg in /etc/passwd with the same uid/gid as snappypkg and list it after the snappypkg :-P
<mvo> sergiusens: woah, thats â¦ scary
<sergiusens> mvo: supported and works though ;-)
<elopio> ok, I see. Thanks.
<sergiusens> mvo: http://docstore.mik.ua/orelly/networking/puis/ch04_01.htm 4.1.2 :-P
<elopio> balloons, dholbach: did you avoid on purpose mentioning this IRC channel on the wiki page? or should I add it?
<dholbach> elopio, I thought I had added it - please add it if I forgot
<balloons> ty elopio .. feel free to edit that wiki page(S)
<elopio> on it...
<mvo> elopio: yeah, my fault, but I think I have a plan for a fix (unless sergiusens keeps confusing me ;)
<sergiusens> mvo: the uid/gid alias is magic and 2 lines of livecdrootfs ;-)
<ogra_> sergiusens, and one spare build to collect the new md5
<elopio> :)
<Chipaca> mvo: how goes squashfs?
<ogra_> totally squashed
<Chipaca> so much so, now it's called sqlfs
<Chipaca> wait, no
<mvo> Chipaca: did I send you the spreadsheet already with my results so far?
<Chipaca> mvo: well, i didn't see it
<Chipaca> mvo: ta
<mvo> Chipaca: the percentages are pretty terrible, but the absolute time is not too bad
<sergiusens> mvo: percentages of?
<mvo> Chipaca: there is a additional sheet with the memory consumption
<mvo> sergiusens: startup time overhead with squashfs
<elopio> beuno: did you see the invitation about the open house on tuesday? sergiusens pointed out correctly that we haven't invited anybody from the store.
<elopio> could you (or somebody from your team) join us?
<elopio> mvo: is this a bug in gettext? http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/po/snappy.pot#L89
<elopio> or should we just not comment things before the G line ?
<mvo> elopio: let me look at the code
<mvo> elopio: I think thats a gettext problem, at least partialy. the alternative xgettext-go uses a slightly different heurisitic to find the comments, if there is a blank line, it will not consider the comment
<elopio> mvo: cool. So with your proposed branch we get a lot of nicer things.
<elopio> rsalveti: can we publish the rc we will be testing in cdimage.ubuntu.com ?
<elopio> mterry: you like translations, right?
<elopio> https://code.launchpad.net/~elopio/snappy/translator-comment/+merge/263673
<mterry> elopio, heh I suppose I do  :)
<mterry> elopio, but mvo has been the architect of snappy's gettext support
<rsalveti> elopio: sure, once we get the rc I can build the pre-built images and publish them there
<mterry> elopio, looks good though
<elopio> balloons: ^ so no need to document ubuntu-device-flash, for now.
<elopio> thanks mterry. I think mvo is super busy trying to get his holidays :)
<mterry> :)
<elopio> ogra_: will you publish a raspberry pi for the RC?
<elopio> *a raspberry pi image.
<sergiusens> rsalveti: do you mind doing what the comment in https://code.launchpad.net/~mvo/snappy/snappy-clickpkg-snappypkg-meh/+merge/263681 mentions?
<rsalveti> sergiusens: so pushing to wily, rebuilding udf and copying over to tools-proposed?
<rsalveti> guess the usual dance
<rsalveti> sergiusens: will wait the auto-merge to kick-in
<elopio> it's missing the commit message.
<rsalveti> elopio: keep forgetting about that
<rsalveti> should be good to release now
<rsalveti> Chipaca: sergiusens: elopio: do we have the rollback work for apps already, in case it fails when updating
<rsalveti> guess that would be connected with health checks and hooks, which is not yet done
<rsalveti> just thinking how we can roll back the app in case the app can be successfully installed but not properly working
<rsalveti> manik_: ^
<rsalveti> haha, mvo forgot to update the changelog this time
<elopio> rsalveti: we can copy many of the tests we have to the hello world snap. But I have tons of questions. First, the format of course.
<elopio> then more interesting things, like
<elopio> we had this error on hello-world.evil that wasn't printing the error. That wasn't caused by the app.
<elopio> so we can install the app, get green on its health checks. Then update the system, and we want to update the app we will get red on its health checks.
<elopio> so I suppose a ubuntu-core update should run the health checks of all the installed snaps.
<ogra_> uh
<ogra_> that will make it long and slow
<rsalveti> right
<manik_> this has nothing to do with ubuntu core
<ogra_> (depending on the amount of apps indeed)
<manik_> well, could be
<elopio> indeed. Long and slow, and we no longer control de updates. They will be affected by third parties.
<rsalveti> guess first step would have the health checks and testing hooks for the app itself
<manik_> but my question was that can we offer the system (snappy core + app such as network OS) uptime guarantee
<rsalveti> how that mix with the system image, it's still unclear
<ogra_> i guess we also need a switch to turn off the auto-rollback ... i.e. if you want to develop and debug your snap you should be able to force-install a broken one via sideloading
<manik_> such that core/app updates guarantee a functioning box
<rsalveti> the goal is to have update/rollback for every snap type
<rsalveti> just not sure what was discussed about that yet
<elopio> ogra_: that's right too.
<manik_> auto rollback is the key here
<manik_> and sure, the requirement for debugging also makes sense
<manik_> in line with ogra_
<elopio> would it help if we make a binary hello-world.test to start playing with it?
<rsalveti> elopio: I think so, but I'm sure sergiusens and Chipaca probably know more about this as well
<rsalveti> the missing pieces and such
<rsalveti> but definitely something we need to do soon
<rsalveti> and backport to 15.04 as well
<manik_> i guess, we can expose a declarative in package.yaml to give the snap developers the capability to auto-rollback or not
<manik_> unless, there's a better option
<manik_> this would take care of both debugging/production use cases
<elopio> what if we make this just an extra command?
<elopio> snappy selfcheck will run all the snappy tests, and all the tests of the snapps installed.
<elopio> if we do it after an update, we are still able to do a rollback if an update breaks an app.
<manik_> who will invoke this cmd?
<elopio> the person who invoked the update.
<manik_>  see, that's the problem... cause no one will
<manik_> at least in enterprises
<manik_> at scale, we need to define what should happen automaticallyu
<rsalveti> right, it needs to be something automatically done for the app that gets updated
<manik_> agreed
<ogra_> well, it could be a separate command that gets auto-invoked after snappy update
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.4ubuntu1
<ogra_> in case anyone sees benefit in having it separate :)
<manik_> why only snappy updates? what about app updates only?
<elopio> an it could be removed.
<ogra_> i meant the command :)
<elopio> *and.
<ogra_> "snappy update foo"
<ogra_> (foo being the app)
<rsalveti> mterry: guess we can make the demo branch trunk at some point, and start having code review for it as well (snapcraft)
<rsalveti> when you get comfortable with the cleanup
<manik_> and how will we take care of the cases where it shouldn't be auto-invoked after an update?
<mterry> rsalveti, yeah fair
<ogra_> manik_, by having an option you can hand to snappy ... "snappy update --no-check foo"
<ogra_> or some such
<kyrofa> rsalveti, is there an equivalent to reviews.ubuntu.com/click/api/1.0/reviews for snaps?
<manik_> ogra_: again, i think my concern is that for small scale of devices, this is all good.. but at massive scale, when an orchestration tool drives app installation/updates and we need to guarantee system uptime regardless of app update failure, this is not very clean
<ogra_> manik_, in such setups you wouldnt manually call snappy update ... that --no-check is really only for developers to be able to debug a broken snap (or to develop it)
<kyrofa> rsalveti, I'm not sure who's running the store stuff, so feel free to redirect me
<ogra_> manik_, i dont see any use case for it in actual production envs :)
<manik_> ogra_: right, so by default every app will be auto-rollback'ed
<ogra_> yeah
<manik_> we don't want that
<manik_> i'll give you examples
<ogra_> you rather want to have a broken app installed that runs amok ?
<manik_> let me explain
<manik_> network OS running on snappy, stores persistent information in format 1 in v1.0, and an update for v2.0 changes the persistent object storage to format 2 which only v2.0 can read
<manik_> in this situation, even though the app update failed, you don't want to rollback
<Chipaca> the data directories are different
<ogra_> you want to roll back to the complete old stack ... including your data
<Chipaca> the data directory of a snap gets copied on install of a new version
<Chipaca> that is, the current data dir is copied to the new data dir after stopping the current snap's services
<Chipaca> if you roll back, you use the old data dir
<manik_> hmmm..
<Chipaca> now, if it's the os snap, then it's more complicated :)
<Chipaca> but any installed snap is like above
<manik_> Chipaca: are you referring to snappy itself when you refer to the OS snap? or a Network OS running on top of snappy
 * ogra_ guesses snappy itself
<ogra_> an network OS is just like any other app snap
<Chipaca> manik_: the core operating system that includes snappy itself
<manik_> ok
<manik_> i have 1 other scenario, but this is highly unlikely if not entirely implausible
<ogra_> these are the best ;)
<Chipaca> shoot :)
<Chipaca> yeah
<manik_> the app depends on interaction with a 3rd party such as a server for its own continuous operation
<Chipaca> is the server local to the device, or remote?
<manik_> some changes at the server necessitate updates from v1 --> v2
<manik_> remote
<ogra_> thats actually a good one ...
<manik_> in this case, the v1 apps cease to exist because server can't handle connections from v1 apps
<ogra_> can an app request to update itself ?
<Chipaca> no, an app can't request to update itself
<ogra_> well, should we support it ?
<Chipaca> ogra_: i'm not sure how that helps :)
<Chipaca> autopilot would find and install new versions of the app
<ogra_> indeed v2 would have to be in the store already
<Chipaca> so, what you would do
<ogra_> right it would also have to be able to suppress the update
<Chipaca> is get your v2 ready in a beta channel or something
<Chipaca> and when you throw the switch to make v2 the current version of the server
<Chipaca> you move v2 to the stable channel
<ogra_> phew
<ogra_> thats a lot of coordination work
<Chipaca> yes
<Chipaca> and not recommended
<Chipaca> but that's how you'd do it if you needed to make a hard cutoff
<rsalveti> kyrofa: guess beuno is your friend for that
<Chipaca> ideally you'd have a window
<Chipaca> where v1 and v2 are both ok
<rsalveti> sergiusens might know as well, since he is working on the rest api
<ogra_> updating the server and sending a push/update command to the nodes sounds easier
<Chipaca> and you'd move people over inside that window
<kyrofa> rsalveti, thanks!
<Chipaca> ogra_: hm, not sure we're wanting to address that kind of hard client-server sync
<ogra_> unless you have a hard ABI break onn the server or so
<ogra_> where its either/or
<Chipaca> yeah
<Chipaca> so, hard cut-offs could happen
<ogra_> well, the case is definitely very corner :)
<Chipaca> i've had to orchestrate a couple myself :)
<manik_> in this case, if the v2 of the snap can explicitly request not to roll-back as part of its package.yaml and than later in the future v3 can renew that guarantee
<kyrofa> beuno, does the store support reviews for snaps yet? i.e. the snap equivalent of reviews.ubuntu.com/click/api/1.0/reviews
<Chipaca> manik_: hmm, disagree
<elopio> hum, and we might want some types of health-checks that contact an external service.
<ogra_> elopio, careful what you wish for :)
<Chipaca> manik_: if v2 is getting rolled back automatically it's because it's broken
 * ogra_ sees the privacy trolls standing on the side already 
<Chipaca> manik_: so, ok, v1 won't be much better
<manik_> right, but we want to let the app developer decide if they can support rollback with their architecture or not
<Chipaca> manik_: but it's not worse. note you already tested that it should work by having it in a different channel.
<rsalveti> right, why would we rollback v2
<ogra_> rsalveti, because it fails to start for some reason
<ogra_> typo in the config ... bad testing etc
<rsalveti> exactly, so it's known to be broken
<rsalveti> and as Chipaca said, as useful as v1
<ogra_> rsalveti, right, but the server it talks to can only handle requests from v2 now
<Chipaca> now, *manual* rollback, i could see disallowing or, better / easier, alerting the user as to it being a bad idea
<ogra_> its a client/server scenario
<Chipaca> manual rollback is advanced user territory anyway
<ogra_> with a hard dep between them
<Chipaca> ogra_: yes, i get it, v1 is useless
<Chipaca> ogra_: but v2 is broken
<ogra_> right
<rsalveti> I think it's fine to have a flag or such that could set the auto rollback or not
<rsalveti> if you want to force that
<Chipaca> oh, ok :)
<manik_> i just want the developer to control whether he wishes to have rollback or not
<manik_> this way we are not imposing this as a hard requirement
<manik_> and also get out of the way of these corner case discussions
<manik_> we just tell the end customer, if you want rollback, we can provide it
<rsalveti> right, I think that's fair
<ogra_> well, rather "if you want to suppress it"
<ogra_> it should be the default
<manik_> ogra_: i think the challenge with that is that most systems do not guarantee app rollbacks and i am not sure if many developers take care of all corner cases in terms of rollback
<ogra_> its one of our key features
<rsalveti> ogra_: right
<manik_> what we are proposing with snappy is an entirely new way of updates/rollbacks
<rsalveti> have a way to suppress it
 * ogra_ imagines something like: snappy config ubuntu-core set no-rollbacks
<ogra_> but by default rollbacks happen
<manik_> what's the advantage to doing default rollbacks?
<ogra_> that you can never end up with a broken libreoffice on your desktop ;)
<ogra_> and that your firewall route still works after a failed update
<ogra_> *router
<ogra_> or that your delivery drone has no outage due to an upgrade failure
<rsalveti> forcing a default for rollbacks is to make sure the system is always in a usable state
<ogra_> (so you can immediately use it again even after failed upgrades)
<manik_> if a declarative flag in package.yaml is mandatory and defaults to yes, this can still achieve the same goal of rollback but forces the developer to think about all corner cases for rollbacks
<ogra_> yeah, but it bloats the package.yaml for everyone
<rsalveti> don't need to put in package.yaml if that is already the default
<ogra_> for a small percentage of apps that dont want rollback
<manik_> ok, my idea was just to make the developers explicitly aware that we will do this..  in case for whatever reason that are not thinking straight
<ogra_> well, we advertise that pretty badly :)
<ogra_> hard to not be aware of it
<manik_> ok, so we have an agreement on this
<manik_> now, the real question is, is this capability already there?
<ogra_> haha
<manik_> or parts of it
<ogra_> thats the trick question in this conversation :)
<ogra_> (see the beginning of the discussion, it isnt ... )
<rsalveti> sergiusens: will you backport https://bugs.launchpad.net/snappy/+bug/1459749 as well?
<ubottu> Ubuntu bug 1459749 in Snappy 15.04 "Origins for frameworks and oem packages are lost after install" [High,Triaged]
<rsalveti> going to put it under the 15.04.2 milestone
<manik_> is this being tracked at the trello boards?
<mvo> meh, what changelog did I forget?
<rsalveti> mvo: 1.3ubuntu1 for ubuntu-snappy
<rsalveti> mvo: but no worries, already pushed the packaging changes
<mvo> rsalveti: uh, thanks, sorry for forgetting the bzr push
<rsalveti> mvo: np, I always forget that as well
<ogra_> yeah, it is awful
<manik_> rsalveti: where can i review the 15.04.2 milestones?
<ogra_> using debian/changelog works though ;)
<rsalveti> manik_: https://trello.com/c/KaabaSIw/160-application-rollback-on-updates
<rsalveti> will discuss this with the team again next wekk
<rsalveti> week
<rsalveti> half of the team is off tomorrow
<rsalveti> manik_: https://launchpad.net/snappy/+milestone/15.04.2
<rsalveti> I'm still reviewing the bugs
<manik_> great
<manik_> what about the option of granular system resource control
<manik_> for example an app requesting 2CPUs, 5G RAM, 10G storage and 1G bandwidth
<manik_> basically, exposing the system cgroup mapping to the app developer to let them decide
<ogra_> sounds pretty dangerous
 * ogra_ guesses that needs some security team input
<rsalveti> that's a big topic
<ogra_> yeah
<manik_> yes, i did send an email on this to the alias during the IoM sprint
<manik_> but i guess everyone was too caught up at that time
<mvo> sergiusens: thanks again for the adduser/useradd patches, I uploaded them now. I added a task to push the patches to debian, feel free to do that otherwise I will send them early next week (if they merge the diff we have less delta to maintain :)
<ogra_> mvo, a compelling argument for them might be that we got the extrausers idea from their server setups :)
<ogra_> (i'm still surprised debian hasnt patched the tools themselves yet)
<beuno> kyrofa, it does, there's no material difference between snaps and clicks
<kyrofa> beuno, so I can use the same API, but use snap package IDs?
<beuno> kyrofa, indeed you can
<kyrofa> beuno, how about screenshots?
<beuno> kyrofa, yes, no differences between clicks and snaps
<sergiusens> rsalveti: no need to rebuild u-d-f
<rsalveti> then just copying to tools-proposed
<kyrofa> beuno, very good, thank you :)
<sergiusens> rsalveti: yes, I will backport that origins bug, I created the 15.04 task for it, but forgot to add a milestone for it
<rsalveti> sergiusens: cool
<sergiusens> rsalveti: ultimately, we don't need to copy u-d-f for it to work, but it would be good to get personal there anyways.
<rsalveti> yeah
#snappy 2015-07-03
<dholbach> good morning
<fgimenez> good morning
<seb128> shrug
<seb128> u-d-f on personal fails with a "failed to find user uid/gid" :-/
<seb128> sergiusens, ^ do you have any idea about that one?
<ogra_> i guess half the world is off today
<seb128> why?
 * ogra_ cant remember if sergio was among them
<seb128> is today some religious holidays most country have or something?
<ogra_> independence day in the US ... and there was something in south america i cant remember
<seb128> hum
<seb128> isn't independance day the 4th of july?
<seb128> e.g tomorrow
<ogra_> yep
<ogra_> so to make it worth it they get today off ... funny US law
<seb128> that's cheating!
<ogra_> (because of weekend ... but having the right for a free day)
<seb128> is mvo celebrating US independance as well? ;-)
<ogra_> yeah, totally !
<ogra_> haha, for sure
<seb128> slacker!
<ogra_> yeah
<ogra_> seb128, are you seeing that error when building the image or when booting it ?
<davmor2> seb128: yet you don't think it's cheating when we get friday and Monday off for xmas that fell on the saturday or sunday right ;)
<seb128> davmor2, "we"?
<seb128> so
<seb128> 1- France doesn't have that rule (nor does most european countries I think)
<seb128> 2- yes, I find it cheating when the u.k do that
<seb128> ogra_, u-d-f
<ogra_> bah
<seb128> I guess it's some of the image processing
<ogra_> seb128, well, thats like being in the EU but not having the euro, so what do you expect :)
<seb128> dunno if that has to do with the cloud-init cleanout
<seb128> that string isn't in goget-u-t though
 * ogra_ waits for the 44min download to finish :P
<Rlyeh> Hello everybody
<Rlyeh> I have a BBB I don't know how to drive a pwm, using snappy. I could do this before, using angstrom distribution.
<Rlyeh> I know the device tree overlay is different with angstrom, but i don't know how can I configure the hardware in snappy.
<Rlyeh> Can anyone help me?
<seb128> ogra_, http://paste.ubuntu.com/11814398/
<seb128> bah
<ogra_> Rlyeh, we dont really have a standard way for overlay dtb files yet ...
<ogra_> there was a long thread about it on the mailin list (snappy-devel i think)
<ogra_> *mailing
<Rlyeh> You mean I can't use all hardware resources?
<ogra_> we have no standard way, you need to hack in the overlay currently (i think it is described in the thread)
<Rlyeh> I asked there, but no one didn't answered me
<Rlyeh> It's just about BBB or it's same for RPi2 too?
<seb128> bah
<seb128> ogra_, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1470727
<ubottu> Ubuntu bug 1470727 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash touch fails with: failed to find user uid/gid" [Undecided,Confirmed]
<seb128> so not only personal
<seb128> likely one of the ubuntu-snappy changes from this week I guess
<ogra_> Rpi is a little worse since it uses the binary blob to initially set the dtb's ... which is the reason we dont have a standard way yet ... that standard way needs to cover both implementations
<seb128> since on my box I didn't upgrade anything
<seb128> so it's not udf/the host system versions
<ogra_> might be ... lets see if i can verify here
<seb128> thanks
<ogra_> (in about 40min )
<Rlyeh> OK, thank you anyway ogra
<ogra_> Rlyeh, i'm partially working on the RPi implementation, once there is a proper way i'll send a mail to the list (and put up documentation)
<Rlyeh> Thank you, wish you be success in that
<seb128> ogra_, you can try on core if you want, less to download and it gives the same error
<seb128> grrr
<seb128> wtf snappy team, wrecking stuff on a virtual-friday
<seb128> that string is part of /usr/bin/snappy
<seb128> I guess it's due to rsalveti changes yesterday
<seb128> http://launchpadlibrarian.net/210553123/ubuntu-snappy_1.3ubuntu1_1.4ubuntu1.diff.gz
<seb128> lot of uid things in there
<seb128> or...
<seb128> I might need to update ubuntu-snappy on my system
<ogra_> oh, snappy vs clickpkg again
<seb128> ogra_, it works after installing the new ubuntu-snappy on my laptop
<seb128> so yeah, mismatch between the tools and the image
<ogra_> yeah
<ogra_> because it only finds the snappypkg user
<ogra_> (or rather doesnt find it)
<Chipaca> seb128: the uid/gid thing might be because we renamed a user
<Chipaca> seb128: might :)
<seb128> Chipaca, seems to be yeah
<seb128> ok, works
<seb128> today personal has a working ubuntu user without cloud-init, things are improving ;-)
<ogra_> well, still rebootloop by default here
<seb128> right, the grub issues are not resolved
<seb128> you need to pick the "ubuntu" entry
<seb128> but it's not a surprise since those changes didn't land
<ogra_> hmpf, why do i land in emergency mode now
<JamesTait> Good morning all; happy Friday, and happy International Plastic Bag Free Day! ð
<ogra_> seb128, so any idea why the ubuntu user doesnt show up in lightdm ?
<seb128> ogra_, no, it seems random/transient, I got it showing up after systemctl restart lightdm and it was there on next boot as well
<seb128> ogra_, I think I'm going to change the image to autologin
<ogra_> yeah
<ogra_> we ship a snippet for that in livecd-rootfs for the phone
<ogra_> live-build/ubuntu-touch/includes.chroot/etc/lightdm/lightdm.conf.d/90-phablet.conf
<seb128> ogra_, any reason that's not in /usr/share/lightdm/lightdm.conf.d?
<seb128> I guess location changed and that one didn't get migrated
<ogra_> yeah, there was one, ask mterry
 * ogra_ doesnt get it ... i always end up in emergency mode now 
<seb128> what mode is that?
<ogra_> systemd drops you into a rootshell
<dholbach> rsalveti (and everyone else): I filed https://bugs.launchpad.net/snappy/+bug/1471160 to track the work we talked about - most of it is on developer.u.c obviously, but there's the thing about converting the .rst file in the docs to .md
<ubottu> Ubuntu bug 1471160 in Snappy "Import Snappy docs automatically into developer site" [Undecided,New]
<dholbach> davidcalle, ^
<ogra_> hmm, so just dropping the autologin snippet from touch in place doesnt help
<ogra_> (indeed with s/phablet/ubuntu/)
<davidcalle> dholbach, thanks, I've just found out how we can support markdown tables in an importer (md doesn't have tables by default, this was the reason for the rst)
<dholbach> oooh nice!
<davidcalle> dholbach, I'm starting the rst->md conversion, I've tried a few automated things and they seem to fail on it
<dholbach> maybe it doesn't necessarily need to be a table? :)
<davidcalle> dholbach, hmm, it uses them quite a lot : https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
<dholbach> I see, mh
<dholbach> davidcalle, shall we have a quick chat now or would you prefer later?
<davidcalle> dholbach, now is fine :)
<dholbach> perfect
<dholbach> let me set up the hangout
<seb128> ogra_, did you mean earlier than systemd was booting in state "maintenance"?
<sergiusens> ogra seb128: you need the latest snappy installed on your host for that to go away (in wily, I think rsalveti copy-package'ed it to snappy-dev/tools-proposed)
<sergiusens> Chipaca: ^
<seb128> sergiusens, yeah, I figured that out/resolved it
<seb128> thanks
<Chipaca> sergiusens: which "that"?
 * Chipaca out of the loop?
<ogra_> sergiusens, yep, we found already
<sergiusens> seb128: from my point of view the image was broken all week and I spent most of it chasing that
<sergiusens> ;-)
<seb128> sergiusens, same here...
<ogra_> seb128, well, not sure how it is actually called (it boots normal now) but it talked about systemctl reboot and systemctl default in the text it printed before giving me a shell
<seb128> k, well for me system doesn't boot
<ogra_> (note that i dropped all console= options so i can actually see error messages)
<ogra_> (and panic= as well)
<Chipaca> ogra_: what does console default to without console=, in different arches?
<ogra_> tty0
<ogra_> on all arches afaik
<ogra_> i would only set console= if i actually want serial ... (and only set it once)
<ogra_> for all other variants i'd just drop it
<sergiusens> davidcalle: dholbach can you switch to github flavored markdown? https://help.github.com/articles/github-flavored-markdown/
<dholbach> sergiusens, I don't know - with which tool can we convert it to html?
<sergiusens> dholbach: that python one I forget the name of... Chipaca helpz :-P
<ogra_> yeah, ask sergiusens he once told me :P
<ogra_> ah, pandoc ...
<davidcalle> sergiusens, do you need specific features we can't have for now?
<sergiusens> Chipaca: btw, the find label was doing something useful
<sergiusens> davidcalle: the tables ;-)
<davidcalle> sergiusens, ah, then in that regard, yes, you will be able to use anything github md do for tables
<davidcalle> s/will be/are
<sergiusens> Chipaca: now I can't find the alternate kernel path because / is (hd0,2) and there is no kernel in /vmlinuz only in (hd0,3) and (hd0,4) which correspont to the searched for labels
<sergiusens> Chipaca: I added back the search and it all works again :-/
<Chipaca> was afk (lunch etc)
 * Chipaca reads
<sergiusens> Chipaca: summary --set with no var set $prefix to the found $label
<Chipaca> sergiusens: wait what?
<Chipaca> sergiusens: ooooooh! but that's not what the docs say :)
<Chipaca> ok
<sergiusens> Chipaca: it does :-)
<Chipaca> docs say it sets root
<Chipaca> and that $prefix is calculated before all user-provided stuff? or something like that
<sergiusens> Chipaca: hmm, I read that prefix defaults to the bootloader partition, in any case /vmlinuz alone points to nowhere :-P
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy-hub/searchForMe/+merge/263772
<Chipaca> sergiusens: changing subjects, what do you think of .snapignore?
<sergiusens> Chipaca: sorry, not prefix but root
<Chipaca> ah, yes, that yes
<Chipaca> but we don't use root
<sergiusens> Chipaca: that is inherited from click, which I know because I proposed adding a couple of files there and cjwatson said no, and had this huge list :-P
<sergiusens> Chipaca: yes we do
<Chipaca> anyway,
<Chipaca> if you tell me it works like this and does not without, screw the docs, this stays :)
<sergiusens> Chipaca: it works
<sergiusens> example from the docs: set root=(hd0,1); linux /vmlinuz
<Chipaca> sergiusens: where do we use $root?
<sergiusens> Chipaca: http://www.gnu.org/software/grub/manual/grub.html#root
<sergiusens> Chipaca: when you use '/' without specifing the partition
<sergiusens> Chipaca: as in vmlinuz and /initrd.img
<Chipaca> sigh. ok.
<sergiusens> */vmlinuz
<Chipaca> yep yep
<Chipaca> i blame ogra :)
<Chipaca> he wants to confuse us, so we'll switch to uboot on intel
<sergiusens> it's fine, he should of catched this
<sergiusens> heh
<sergiusens> we can I guess :P
<Chipaca> it's because he has shares in the uboot corporation
<Chipaca> sergiusens: wrt .snapignore
<Chipaca> ~chipaca/snappy/dynamicExclusion
<Chipaca> lp:^
<Chipaca> sergiusens: would something like that be potable?
<Chipaca> sergiusens: http://bazaar.launchpad.net/~chipaca/snappy/dynamicExclusion/revision/555 i guess
<sergiusens> Chipaca: do you reread the file for every file there? it looks good in any case
<Chipaca> sergiusens: wanted to have it not break if somehow two builds are called in the same run (not something that can happen easily)
<Chipaca> sergiusens: it rereads the file for every build directory
<sergiusens> Chipaca: idea, how about we read /proc/net/dev as part of the first boot task and set the appropriate network interface up correctly?
<ogra_> +1
<ogra_> and indeed, uboot would fix everything !
<Chipaca> sergiusens: i'll write tests for this, and add that to first boot
<Chipaca> or i could do it the other way around
<sergiusens> \o/
 * Chipaca shelves this
<Chipaca> well, wait
<Chipaca> pitti had said something about something changing?
<sergiusens> wow, really? :-P
<ogra_> did he ?
<sergiusens> we don't like change!
<Chipaca> i might have misunderstood
<ogra_> yeah, we're no obama !
 * sergiusens mentions that he is being sarcastic in case people don't notice
<Chipaca> pitti: this is wrt network device names
<ogra_> sergiusens, its friday ... everything is sarcastic
 * ogra_ melts 
<Chipaca> pitti: is the current situation "it"? or are we expecting more changes soon?
<Chipaca> pitti: because if it's "it", we know how to work with it :)
<ogra_> well, even if it changes ... /proc/net/dev should give us the right info
<Chipaca> fair enough
<Chipaca> ogra_: btw, do you know why we don't "see" the bbb usb net device?
<ogra_> missing module ?
<Chipaca> tried usbnet, not it
<ogra_> no
<ogra_> its an smc1234something
<sergiusens> o, that would be a great thing to work on as well
<ogra_> oh
<ogra_> you mean gadget support !
<ogra_> now i get it
<Chipaca> do we want to bring up the first ether device, or the first anything-but-wireless device?
 * ogra_ needs some cooling heard ... brain only operates at 20% or so 
<ogra_> *head
<Chipaca> ogra_: massagran
<Chipaca> no, not massagran
<Chipaca> 'old on
<ogra_> Chipaca, we'd need to ship the cdc_composite module and configure it accordingly
<Chipaca> ogra_: mazagran
<Chipaca> ogra_: cold coffee + lemon ftw
<ogra_> hmm, sounds like an odd combo
<Chipaca> 's good
<Chipaca> but don't do the version with rum just yet
<Chipaca> https://en.wikipedia.org/wiki/Mazagran_(coffee_beverage)
<Chipaca> ogra_: how was it you asked to be dropped into initrd?
<ogra_> i just had a longish discussion with asac about that :)
<ogra_> (modules handling etc)
<ogra_> my idea is to have a modules.img in /boot ... (or multiple if one is to big) ... so you can loop mount that from initrd ... and later move mount it to the rootfs (no duplication, no modules inside the initrd)
<ogra_> i discussed that with rtg earlier already and will work on a prototype soon as proof of concept
<ogra_> WOW ...
<ogra_> susie just brought me a bowl of raspberries ... fresh from the bush
<ogra_> they are like cooked ... totally hot
<pitti> Chipaca: I don't plan on changing the current situation myself, unless we have to because of bugs
<pitti> Chipaca: we might get some exclusion rules for rmnet* devices for ofono; but that wouldn't affect eth or wlan
<pitti> Chipaca: OOI, are you using networkd now, or just a more dynamic ifupdown snippet?
<ogra_> yeah, that would also only affect personal
<ogra_> where we wont have a hard configured eth0 or wlan0 anywa
<ogra_> y
<ogra_> pitti, no networkd yet
<ogra_> (afaik)
<Chipaca> not on core, no
<ogra_> might be interesting to know how that works with ubuntu-fan
<ogra_> or if at all
<Chipaca> sergiusens: how can i tell from first boot if i'm in personal or not?
<Chipaca> or would networkd running mean no ifup
<Chipaca> because if so we're good to go :)
<ogra_> Chipaca, i guess that can only be answered once personal exists :)
<pitti> Chipaca, ogra_: right, I was just intersted (it's easier to configure that with networkd than with ifupdown, but I guess you already have a solution that writes interfaces on first boot or so?
<ogra_> pitti, not really
<Chipaca> pitti: that's what i'd be doing, at least for core
<ogra_> livecd-rootfs currently creates a file
<Chipaca> write the equivalent of the current static eth0 file on first boot
<pitti> Chipaca: yeah, you shouldn't configure it in multiple places; pick one of ifupdown, NetworkManager, or networkd
<pitti> Chipaca: ack
<Chipaca> pitti: do usb network interfaces also start with /en/?
<pitti> Chipaca: depends -- a tethered phone yes, but I figure an USB wifi stick would start with wl*
<Chipaca> pitti: yeah, i meant something like a tethered phone, or a usb ethernet device, not a wifi nor wlan
<Chipaca> things that would be expected to 'just work' for an iot device :)
<ogra_> Chipaca, usually usb0 etc
<ogra_> depends on the gadget driver you use
<Chipaca> ogra_: before yes, but now?
<ogra_> heh
<ogra_> i guess we'll see
 * ogra_ will tinker a bit with gadget stuff on the weekend 
<Chipaca> ogra_: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20
<ogra_> hmm
<Chipaca> so ens3 is the ethernet device plugged into the hotplug slot number 3
<ogra_> that has no usb at all
<Chipaca> ogra_: nor should it
<Chipaca> ogra_: i mean, unless you expect ethernet devices to mention they're pcie
<ogra_> well, you want to name them somehow
<Chipaca>                                       -- PCI geographical location
<Chipaca>  *   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
<Chipaca>  *                                         -- USB port number chain
<Chipaca> so usb would be enPsomethingpsomethingssomethingfsomethingusomethingcsomething
<ogra_> ah, i was reading the comment at the top
<Chipaca> supereasy
<ogra_> which kind of indicates it will never even find a device on something like the BBB
 * Chipaca is now very curious as to how this looks in actual practice :)
<Chipaca> ogra_: why?
<Chipaca> ogra_: it'll start with en
<ogra_>  * Predictable network interface device names based on:
<ogra_>  *  - firmware/bios-provided index numbers for on-board devices
<ogra_>  *  - firmware-provided pci-express hotplug slot index number
<ogra_>  *  - physical/geographical location of the hardware
<Chipaca> just then have a bunch of stuff
<ogra_>  *  - the interface's MAC address
<ogra_> the only thing that might apply is the MAC in that list
<Chipaca> 's fine
<Chipaca> as long as it starts with /en/, i'll bring it up :)
<ogra_> that code is so awfully intel centric ... sigh
<ogra_> bios ... pci ...
<Chipaca> ogra_: it's written by people who were rather late to the arm bandwagon
<Chipaca> not particularly surprising
<ogra_> it is written by people who tend to ignore everything but intel
<ogra_> which was/is one of my biggest concerns switching to systemd
<ogra_> init=/bin/sh ... really ... :P
<Chipaca> ogra_: as i say, super interested in bringing up that bbb thingie, now :)
<ogra_> now ...
<Chipaca> ogra_: init=/bin/snappy \o/
<ogra_> or that, yeah !
<Chipaca> anyway, need to go for the school run. will bbl :)
<ogra_> check if the cdc_composite module exists
 * Chipaca checks
<ogra_> or cdc_ether
<ogra_> (but that would limit you to only ethernet over USB)
<ogra_> hmm, the RPi kernel doesnt have it enabled :(
 * Chipaca wonders what ttyO0 is
<damjan> Chipaca: the O is from OMAP
<ogra_> https://www.kernel.org/doc/Documentation/usb/gadget_multi.txt
<damjan> I guess
<ogra_> yeah
<Chipaca> damjan: ta :)
<ogra_> which is weird since the BBB has no OMAP
<ogra_> but TI stuck to the O
<Chipaca> ogra_: i don't have cdc_composite
<ogra_> Chipaca, the above text should help
<Chipaca> ogra_: i do have cdc_ether
<ogra_> yeah, thats just therenet over usb ... not host mode though
<ogra_> *ethernet
<Chipaca> yeah, no workie
<ogra_> you want actually g_ether
<ogra_> or g_multi ...
<ogra_> ir cdc_composite
<ogra_> *or
<ogra_> i dont think it is enabled in our kernel package
<Chipaca> ok, i need to run
<ogra_> needs some config changes
<Chipaca> will read that on my return
<ogra_> run lola run ...
<ogra_> :)
<Chipaca> modprobe g_multi did find usb0
<ogra_> oh
<Chipaca> but then something about LUN0
<Chipaca> and bailed
<ogra_> well, there you go
<ogra_> yeah, likely needs modoptions
<Chipaca> ogra_: http://pastebin.ubuntu.com/11815545/
 * Chipaca run s
<ogra_> (it can also be serial and fileservice)
<Chipaca> yeah, figures
<Chipaca> anyway! run! me! go! now!
<ogra_> :)
<sergiusens> Chipaca: did you figure out that firstboot thing?
<ogra_> sergiusens, oh, regarding sabdfl's comment on the ML i guess we should seed fan again (still feels like bloating the image to me ... :) )
<sergiusens> ogra_: right, we should
<ogra_> i'll try to get to it before EOD
<sergiusens> ogra_: I feel ashamed for conflating dhcp and dnsmasq though :-P
<ogra_> why
<ogra_> it acts as dhcp server in that setup
<sergiusens> ogra_: because I could of nailed it down to a package
<ogra_> was just a glitch in terminology ... still matched the function ;)
<sergiusens> elopio: are you here already?
<ogra_> is he working today ?
 * ogra_ totally lost overview who is working and who isnt today :) 
<sergiusens> ogra_: hmm, Costa Rica isn't part of the US yet, right? :-P
<ogra_> wasnt there some religious day in SA today too ?
<sergiusens> ogra_: not in the lower cone
<sergiusens> ogra_: not according to http://www.timeanddate.com/holidays/costa-rica/
<ogra_> ah, well :)
<sergiusens> ogra_: I think most of the people not in the US are just taking swap days
<ogra_> yeah
<ogra_> lots of them though :)
<sergiusens> Chipaca: noupdategrub can land (did the 4 phased update test)
<sergiusens> Chipaca: care to top approve https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381 ?
<elopio> good morning.
<elopio> I'm having some internet problems today.
<elopio> sergiusens: I'm here.
<elopio> celebrating my independence by working from the office :)
<elopio> sergiusens: how can I help you?
<sergiusens> elopio: heh :-)
<sergiusens> elopio: just wanted to have a quick talk on what the no update grub update implies wrt testing; also planned to invite fgimenez (and Chipaca)
<sergiusens> makes for a pure spanish meeting
<sergiusens> if not for ogra_ our standup today would of been in Spanish ;-)
<elopio> lets not invite ogra_ to the standup either :)
<sergiusens> well, it might need to happen after standup as I can't get a hold of Chipaca or fgimenez :-P
<fgimenez> sergiusens, no, sorry :) i'm ok with having it now, looking forward to practice my spanish, i'm mostly forgetting it :)
<Chipaca> sergiusens: back
<sergiusens> Chipaca: pretty please approvez the branchez
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~fgimenez/snappy/fix-failover-versions/+merge/263765 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-fix-bbb-crash/+merge/263530 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/build-test/+merge/263327 | No reviews (2 days old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/filter-tests/+merge/263222 | Approve: 2 (3 days old)
<nothal> https://code.launchpad.net/~mterry/snappy/selftest-reboot-notice/+merge/262265 | Approve: 1 (15 days old)
<Chipaca> sergiusens: i suspect nothal is being a wuss
<sergiusens> Chipaca: nothal got a flood warning I hope as this is missing: https://code.launchpad.net/~sergiusens/snappy/noUpdateGrub/+merge/261381
<Chipaca> sergiusens: yeah, i've got that one, but you used the plural
<sergiusens> Chipaca: and all of these https://code.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/+activereviews which have the +1 but not the top +1
<Chipaca> sergiusens: so i was wondering what the other ones are :)
<Chipaca> hah!
<Chipaca> ok
<Chipaca> @help reviewlist
<nothal> Show the list of merge proposals with status = 'Needs review'.
<nothal>         usage: @reviewlist [project:<project name>] [user:<lp username>]
<Chipaca> @reviewlist user:sergiusens
<nothal> https://code.launchpad.net/~fgimenez/snappy/fix-failover-versions/+merge/263765 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-fix-bbb-crash/+merge/263530 | No reviews (1 day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/build-test/+merge/263327 | No reviews (2 days old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/filter-tests/+merge/263222 | Approve: 2 (3 days old)
<nothal> https://code.launchpad.net/~mterry/snappy/selftest-reboot-notice/+merge/262265 | Approve: 1 (15 days old)
<Chipaca> nothal: you are weird.
<Chipaca> nothal: i'm not sure i like that in a bot.
<Chipaca> ogra_: i'm going to revisit this g_multi thing later. it's got way too many options, and the document you linked describes none of 'em :)
<ogra_> lol, yeah
<ogra_> i implemented such stuff ages ago on the pandaboard ... i'll dig on the weekend if i can find some of it
<sergiusens> Chipaca: it's not hal at least, hal or sal wouldn't have made this mistake
<Chipaca> like, file:names of backing files or devices
<sergiusens> ergo the nothal I guess
<Chipaca> ogra_: the onboard debian also uses g_multi, so i'd probably poke at /sys/module/g_multi/parameters/
<Chipaca> ogra_: but it's not going to be fun :)
<ogra_> yeah, i was about to suggest that :)
<ogra_> you will probably find some info in /etc7modprobe.d
<Chipaca> ogra_: great minds often think alike
<ogra_> so you dont need to reverse-engineer and can just copy some config over
<ogra_> also #beagel might be able to help ;)
<Chipaca> no, i grepped all of /etc for g_multi to no avail
<ogra_> err
<ogra_> *#beagle
<Chipaca> oooh
<ogra_> ah, sad
<Chipaca> boot/uboot/scripts/setup-ubuntu-armhf-3.8.13-bone30.sh:modprobe g_multi file=/dev/mmcblk0p1 cdrom=0 stall=0 removable=1 nofua=1 iSerialNumber=${SERIAL_NUMBER} iManufacturer=Circuitco iProduct=BeagleBone${BLACK} host_addr=${DEV_ADDR}
<ogra_> ha !
<Chipaca> that script is interesting
<Chipaca> anyway! back to the network thing
<ogra_> likely some rcn-ee product :)
<ogra_> he does all the interesting beagle scripts
<ogra_> anyway ... taking care of the madam ...
 * ogra_ &
<elopio> @help
<nothal> "list" To see the available commands ; "help cmd" for specific command help
<elopio> @list
<nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
<fgimenez> nice weekend everyone o/
<sergiusens> ogra_: how do we prevent the system from doing that video mode switch?
<damjan> video mode switch??
<damjan> doesn't the kms kernel driver do that?
<sergiusens> ogra_: for when you get back https://code.launchpad.net/~sergiusens/livecd-rootfs/eth0Not/+merge/263812
<h00sier> how can i adduser a new user in snappy image on kvm
<h00sier> I've got snappy connected to the internet with the hardwired ubuntu/ubuntu login and I want to add a user and password for security reasons... adduser can't unlock the /etc/group file
<h00sier> groupadd: cannot lock /etc/group;
<h00sier> how can i adduser a new user in snappy image on kvm
<h00sier> I've got snappy connected to the internet with the hardwired ubuntu/ubuntu login and I want to add a user and password for security reasons... adduser can't unlock the /etc/group file
<h00sier> I've got snappy connected to the internet with the hardwired ubuntu/ubuntu login and I want to add a user and password for security reasons... adduser can't unlock the /etc/group file
<sergiusens> h00sier: you will need to wait a bit to be able to add users, I have branches that are in the pipeline.
<sergiusens> you can for now however change the password
#snappy 2015-07-04
<vmayoral|home> morning
<vmayoral> ubuntu servers seem to be down (tested from Germany). Anyone experiencing the same?
#snappy 2015-07-05
<unicorn_blue> hey guys! Please who can help me out to find snappy's source code?
<unicorn_blue> can't find info on in doco. Is it actually published?
<bregma> unicorn_blue, if I had to guess, I would say the source code is at https://code.launchpad.net/~snappy-dev/snappy/snappy
#snappy 2016-07-04
<mup> Bug #1598656 opened: snapd doesn't close connection on 400 bad request response <Snappy:New> <https://launchpad.net/bugs/1598656>
<mup> Bug #1598657 opened: No error id for username/password error returned from snapd <Snappy:New> <https://launchpad.net/bugs/1598657>
<mup> Bug #1598667 opened: No snapd API for account registration / password reset <Snappy:New> <https://launchpad.net/bugs/1598667>
<dholbach> hiya
<didrocks> good morning dholbach!
<dholbach> slaut didrocks
<didrocks> how was your week-end? :)
<dholbach> very nice - we were at a wedding in South Tyrol and I'm working from Bavaria today
<dholbach> how was yours?
<didrocks> dholbach: oh, sounds great! :)
<didrocks> mine was nice as well, didn't really do a lot due to Saturday's weather, but brough Julie's painting to prepare for her expo this week in city center
<dholbach> oh wow
<timothy> 'morning
<ogra_> popey, yo ... do you have any contact to brian douglass ? could we get him to rename "snappy app" to just be "snap" in uappexplorer ?
<popey> he's on telegram
<popey> you in the apps group? he's @bhdouglas I think
<ogra_> nope, only ubuntu device outsiders
<popey> also, the code is on github, do a pull request and he'll love you more, he's US so on holiday, busy throwing tea into the harbour
<ogra_> ah, post brexit work ... k
<ogra_> i'll take a look at the code and  do a pull request
<ogra_> geez ... thats irritating
 * ogra_ has lots of bugmail fom someone calling himself "Your Mom 
<ogra_> "
<ogra_> and itr is all serious stuff
<ogra_> tsk
<iliv> didrocks, thanks for you replies on AskUbuntu. Much appreciated. Although, I have to admit I found them frustrating :)
<didrocks> iliv: sorry for this! But things are in progress and it will come down in due time. At least, you have ways to handle your services with those advice meanwhile :)
<didrocks> (I still think the layer config approach though is the best)
<iliv> I'm still not sure how one can put a configuration file into say $SNAP_DATA, which I understand is a system-wide area where applications (snaps) can store their data? I tried the copy: plugin but it doesn't expand $SNAP_DATA and treats it literally as a string. Is creating a wrapper script that ...
<iliv> ... checks if a file exists in $SNAP_DATA, and if it doesn't, copies it over from say $SNAP/configs directory every time when a snap package is mounted/maid available to a system?
<didrocks> you won't be able to ship anything at build/install time to $SNAP_DATA. So yeah, creating a wrapper script is one way, having your daemon supporting a layer approach is even better IMHO, but that's up to you :)
<iliv> sorry if I'm being too dense, but what is this layer approach exactly that you referred multiple times already?
<didrocks> ah, it's the idea that you have this configuration file at multiple level
<didrocks> so:
<didrocks> - user
<didrocks> - system (global)
<didrocks> - default
<didrocks> you can find the same config file at any level
<didrocks> user is $SNAP_USER_DATA, system is $SNAP_DATA and default is $SNAP
<didrocks> then, if you find common keys, you always prefer the layer "up" (closer to personal configuration) than the default one
<didrocks> for the same key = value pair
<iliv> okay, I see. it is something that the application itself should be capable of. however, I do not understand how this is going to help with creating a system-wide configuration file upon install of the package? It's still either creating a wrapper script or putting the burden of creating the ...
<iliv> ... configuration file on the end user. Or ... ?
<iliv> Having read-only configuration files that reside in $SNAP makes almost no sense. I figure few applications and users wouldn't want to modify a program's configuration file.
<didrocks> yeah, if you application isn't capable of that, the wrapper script doing what you told is totally makes sense
<didrocks> iliv: it does, it's the default
<didrocks> better to have them exported in the same flat file than hardcoded in the app :)
<didrocks> but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this
<iliv> well, yes, better than hardcoded but if it is read-only it's essentially hardcoded. in a sense that a user/administrator cannot modify any seetings and thus the end result is essentially the same.
<iliv> > but again, if you aren't in controlled of this app code, the wrapper is a good way to handle this // here's the thing. there's a ton of software out there that if attempted to be packaged will face this basic problem of wanting to install configuration and other files outside of $SNAP into at ...
<iliv> ... least $SNAP_DATA.
<iliv> modifying all that massive array of software is pretty much impossible
<didrocks> on hardcoded -> yeah, it's in RO, but you have the config format to be readable by the admin to know what options are supported and so on
<didrocks> and as a developer, you know that there is no discrepancy between default options and options that are overrideable in the config
<didrocks> on the wrapper -> yeah, that's what we have this wrapper approach in quite some snaps, to cope with real world, as you say
<didrocks> however, if upstream starts to adopt snaps, they will maybe then reconsider and follow best practices like this layered approach to manage config :)
<didrocks> (but as an intermediate step, wrapper script it is! :))
<iliv> I see
<iliv> well, guess I will have to figure out how to do this with a wrapper script
<iliv> :)
<didrocks> iliv: if you need any help or need review, do not hesitate! :)
<didrocks> it's basically a if [ ! -f $SNAP_DATA/config ]; then cp $SNAP/config; fi
<zyga> o/
<didrocks> hey zyga
<ogra_> didrocks, geez, so much overhead ... [ -e "$SNAP_DATA/config" ] || cp $SNAP/config $SNAP_DATA/config
<ogra_> (lots faster than invoking the "if" )
<didrocks> ogra_: I wouldn't say "faster", but shorter yeah
<ogra_> didrocks, debian did researches of that ... if is always the slowest ...
<didrocks> ogra_: interesting
<ogra_> case is faster ... just using a condition with "test" is slower than case but faster than if
<didrocks> but TBH, when you need a wrapper script, I doubt the fact to have a if vs [] is the real issue :p
<ogra_> well, depends how big your wrapper is ... after all it is your apps startup time
<ogra_> especially for some test that is run on every startup ...
<didrocks> ogra_: when you need to spaw a process for this and then exec, yeah, I bet this is the impact
<ogra_> (but yeah, we talk about milliseconds indeed)
<didrocks> (knowing that you had 3 wrappers chained up before already :p)
 * ogra_ ponders if he should push his latest two snaps to snappy-playpen
<niemeyer> Hello snapcrafters
<sergiusens> good morning
<zyga> hey sergiusens, how are you
<sergiusens> zyga doing fine, risked it and came to a coffee shop with just my tablet
<sergiusens> zyga so no #snappy-devel telegram avail to me :-P
<sergiusens> zyga how was your weekend?
 * sergiusens has been handcrafting around the house instead of snapcrafting ;-)
<popey> didrocks: that reviewable is painful to use.
<zyga> sergiusens: busy, my son turned crazy on making plane models
<zyga> sergiusens: we bought lots of small pieces of wood and various tools
<zyga> sergiusens: he's remaking the plane model from "porco rosso"
<morphis> if I've put a snap into the edge channel of the store should I see it with `snap find`?
<didrocks> popey: do you find it so? dholbach and I really liked it for tracking feedback and not losing any remark while doing a second or third review
<zyga> morphis: I'm not sure
<popey> didrocks: i fail to see how I submit comments
<morphis> zyga: but a snap install --channel=edge tpm` should work, right?
<didrocks> popey: you are in the reviewable interface?
<didrocks> in it you add all your comments, answer to what you want
<didrocks> and then hit "publish"
<didrocks> to publish all them at the same time
<popey> hm
<popey> maybe that worked?
<zyga> morphis: I think that shoud work, yes
<morphis> hm
<didrocks> let me look
<didrocks> popey: yes, it did! :)
<morphis> zyga: who can I ask about the edge channel thing?
<ogra_> which "thing" ?
<ogra_> morphis, ah, --channel only works with the snapd in proposed
<morphis> ogra_: ah :-)
<morphis> good to know
<morphis> ogra_: do you know when that will land?
<zyga> morphis: perhaps Chipaca
<zyga> ah :)
<ogra_> morphis, well, bug 1592696 indocates it might need additional work, not sure if zyga or mvo saw that
<mup> Bug #1592696: snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied <amd64> <apport-bug> <xenial> <snapd (Ubuntu):Invalid> <ubuntu-core-launcher (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu Xenial):New> <ubuntu-core-launcher (Ubuntu
<mup> Xenial):Incomplete> <https://launchpad.net/bugs/1592696>
<zyga> ogra_: you mean 2.0.10
<ogra_> zyga, whatever is in -proposed atm
<morphis> ogra_: sure you linked the correct bug?
<ogra_> yes
<ogra_> snapd takes over ubuntu-core-launcher ... see pitti's last comment
<ogra_> or rather snap-confine does
<ogra_> not sure whats needed there ... probably bribing with icecream is enough ;)
<morphis> :-)
<zyga> ogra_: hmm?
<ogra_> zyga, see the bug above
<ogra_> last comments
<zyga> ah
 * zyga looks
<zyga> sorry I didn't see that
<ogra_> seems he wants some extra paperwork and tests
<morphis> ogra_: so snap 2.0.10 didn't help with installing snaps which are just in the edge channel
<ogra_> hmm, it definitely helped here
<ogra_> ogra@styx:~$ dpkg -l snapd|grep ii
<ogra_> ii  snapd          2.0.10       amd64        Tool to interact with Ubuntu Core Snappy.
<ogra_> ogra@styx:~$ sudo snap install gitter --channel=edge --devmode
<ogra_> 89.16 MB / 89.16 MB [===========================================================================] 100.00 % 4.86 MB/s
<ogra_> Name    Version  Rev  Developer  Notes
<ogra_> gitter  3.0.3-1  1    ogra       devmode
<ogra_> works fine for me
<morphis> ogra_: try snap install tpm --devmode=edge
<morphis> --channel=edge I mean :-)
<ogra_> ogra@styx:~$ sudo snap install tpm --channel=edge --devmode
<ogra_> 1.14 MB / 1.14 MB [===========================================================================] 100.00 % 295.36 KB/s
<ogra_> Name  Version  Rev  Developer  Notes
<ogra_> tpm   1.2-1    1    canonical  devmode
<morphis> ogra_: ah
<morphis> --devmode seems to be the key
<ogra_> i think i also did a reboot after upgrading snapd
<morphis> but "snap not found" is a misleading error message in that case
<morphis> ogra_: worked now with --channel=edge --devmode
<ogra_> good
<ogra_> yeah, the error sounds liek a bug
<morphis> ogra_: let me file one
<ogra_> +1
<morphis> ogra_: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598886
<mup> Bug #1598886: Misleading error message when trying to install unconfined snaps from the edge channel <snapd (Ubuntu):New> <https://launchpad.net/bugs/1598886>
<ogra_> confirmed
<gouchi_> hi
<gouchi_> is it plan to add this interfaces .
<gouchi_> ?
<gouchi_> http://www.hastebin.com/ixuyuduxaz.vhdl
<gouchi_>  /dev/dri/card0 and /dev/dri/renderD128
<sergiusens> elopio mind looking at https://github.com/snapcore/snapcraft/pull/623 ?
<mup> PR snapcraft#623: Proper message when registering an already registered snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>
<ogra_> gouchi_, i would have thought it is part of the opengl interface ... though perhaps /dev/dri/renderD128 is to specific, i guess zyga could tell you if he was around
<gouchi_> ogra_: thank you
<elopio> sergiusens: I am not totally happy with that error URL.
<sergiusens> elopio I am thinking of removing it fwiw
<sergiusens> elopio it is not the right one
<sergiusens> elopio or the url itself?
<elopio> sergiusens: we could change the error message, or the store could change the url it returns. I would prefer the URL change.
<sergiusens> elopio well that won't happen soon
<elopio> sergiusens: so the message could be: go to this url for more instructions.
<sergiusens> elopio oh, the message is spec'ed, can't change the text
<elopio> sergiusens: and replacing the url wouldn't be good. So I'm ok with the message not being totally accurate until the store fixes the bug.
<sergiusens> joc_ mind clicking on update branch for https://github.com/snapcore/snapcraft/pull/614 (there's an example's test error and I cannot see it as it seems it got round robinned out)
<mup> PR snapcraft#614: python3: use --root instead of --target <Created by jocave> <https://github.com/snapcore/snapcraft/pull/614>
<mup> PR # changed: snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495, snapcraft#495
<mup> PR # created: snapcraft#596, snapcraft#593, snapcraft#589, snapcraft#579, snapcraft#571, snapcraft#570, snapcraft#568, snapcraft#550, snapcraft#510, snapcraft#495
<ehbello> hello, somebody can tell me how to define the 'uboot.env.in' file to build a 'uboot.env' file suitable to snapcraft to build a gadget snap?
<ehbello> I can see some examples at lp:~snappy-hub/snappy-systems but I can't guess what I need for my gadget
<niemeyer> ehbello: These details are not quite finalized yet.. it'll take a few more weeks before we have a proper specification for it
<ehbello> niemeyer: I don't understand that... I mean, if there is not a proper specification for it, why are there devices as beagleblack or pi2 with this file in its snap? are not uboot.env related with uboot directly?
<ehbello> niemeyer: I know that uboot.env is built with mkenvimage tool but I don't know what to put in uboot.env.in
<niemeyer> ehbello: My apologies for that as I know it is a bit confusing indeed.. the whole tooling around snaps (snapd, snapcraft, etc) changed in a major way in the last few months, for the better.. for most of that time we focused on getting tools right without direct in-device development.
<niemeyer> ehbello: So the images you will find around are either 15.04 images, or half-baked 16.04 ones that were never actually released as they're not yet ready
<niemeyer> ehbello: If you're using 15.04, I'm sure other people in the channel will be able to give you a hand, but keep it mind that a lot of what we talk about here won't apply there
<ehbello> niemeyer: I'm working on ubuntu 16.04 edge images generated with latest branch of ubuntu-device-flash from 'mvo' in LP and I have a partial gagdet snap... I think the only thing missing is the uboot.env file for an armhf gadget to get everything working properly :)
<niemeyer> ehbello: That's great, glad to see the in-development code being put to test and actually working :)
<niemeyer> ehbello: Just note it may actually break due to incompatible changes (IOW, good to play with, not good for real devices yet)
<sergiusens> elopio help! https://travis-ci.org/snapcore/snapcraft/jobs/142285265
<ehbello> niemeyer: I know, but I prefer to develop on an edge platform rather than a version that will becomes obsolete soon :P
<ehbello> (sorry if I write bad english. I'm spanish :)
<niemeyer> ehbello: Yeah, that's a good plan
<elopio> sergiusens: my branch added -d, so when checking errors in integration, between that "Registering ..." message and "The name \'test-already-registered-snap-name\' is already taken", there is a trace
<niemeyer> ehbello: Your English seems prefect.. I'm not a native speaker either
<sergiusens> elopio but the register failed does a subprocess checkcall all on its own
<elopio> sergiusens: there is no need to check the first part in the message, IMO. So I would do: assertThat(output, EndsWith(The name \'test-already-registered-snap-name\' is already ...))
<sergiusens> elopio oh, nvm
<sergiusens> elopio now I guess my branch will fail in integration ;-)
<elopio> sergiusens: nop. I've just registered that name in staging. Actually, there's no need for anything we discussed in the standup.
<elopio> with the hardcoded name and the right values in the database, it works and it's simple.
<sergiusens> elopio don't I need to use the sleeper command though?
<sergiusens> just switched to it just in case
<elopio> sergiusens: yes, the sleep might be missing there. I'm not sure if the store blocks also when the registration failed, but it's likely.
<mup> PR snapd#1475 changed: integration-tests: drop already covered refresh app test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1475>
<mup> PR snapd#1479 changed: change API of snapstate.Get() to return a snapstate.SnapState <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1479>
<sergiusens> elopio in any case this will fail integration tests; the expected message's claim url will be wrong
<mup> PR snapcraft#629 opened: Bugfix/1598932/reserved name <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/629>
<sergiusens> there, fixed
<sergiusens> elopio for snapcraft#630 I would like to use MatchesRegex for an integration test and failing badly
<mup> PR snapcraft#630: Report a nice error when registering too fast <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
<mup> PR snapcraft#630 opened: Report a nice error when registering too fast <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
<elopio> sergiusens: we have an example of matchesregex in snaps_tests/__init__.py
<elopio> what's failing for you?
<sergiusens> elopio ah, the testtool docs did not mention I could pass re flags
<sergiusens> elopio care to look at 623 one more time, same for 629; btw I cannot login to staging to see if that last int test would work
<mup> Bug #1574586 opened: Not able to review snaps <Snappy:New> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1574586>
<mup> PR snapcraft#623 changed: Proper message when registering an already registered snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>
#snappy 2016-07-05
<sergiusens> elopio I've updated 629
<sergiusens> elopio 629 is the interesting one to be tested against the staging store
<MichaelTunnell> if a non-official snap is added to the snapstore and an official team wants to take it over is it possible to transfer ownership to become official and if so can the suffix be removed from the snap name?
<MichaelTunnell> niemeyer: ogra_: ?
<niemeyer> MichaelTunnell: Yes to both
<elopio> sergiusens: you can register your own user on staging, and pass the TEST_USER_NAME and TEST_USER_PASSWORD. Just make sure to accept the agreement first.
<elopio> or I can send you the test user password.
<MichaelTunnell> niemeyer: nice thanks for clarification
<mup> Bug #1598984 opened: snap list reports no snaps installed when invalid name passed <Snappy:New> <https://launchpad.net/bugs/1598984>
<TheMuso> Is the latest version of snapd going into yakkety any time soon? I know we are targetting snaps for xenial right now, but it would be nice to be able to work with and test snaps in yakkety as well.
<mup> PR snapcraft#629 changed: Proper message when registering an already registered snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/629>
<sergiusens> elopio about lp: #1572399 ... I talked to cprov and he asked me to create a bug, mind just linking this to the store tracker?
<mup> Bug #1572399: [upload] Catch name registration issue and explain how <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1572399>
<dholbach> hey hey
<mup> PR snapd#1485 opened: snap: add `snap run --debug-shell` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1485>
<niemeyer> o/
<mup> PR snapd#1394 changed: debian: add snapd.postrm that purges <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1394>
<mup> PR snapd#1486 opened: interfaces: add wireless-control <Created by lpotter> <https://github.com/snapcore/snapd/pull/1486>
<mup> PR snapd#1481 changed: overlord: make patch1_test more robust <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1481>
<mup> PR snapd#1487 opened: tests: set yaml indentation to 4 spaces <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1487>
<mup> PR snapd#1462 closed: snapstate: cleanup downloaded temp snap files <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1462>
<mup> PR snapd#1487 closed: tests: set yaml indentation to 4 spaces <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1487>
<mwhudson> zyga, mvo: hey, i was looking at the snap-confine package in the yakkety queue
<mwhudson> where did the tarball come from? it doesn't seem to match the release on https://github.com/snapcore/snap-confine/releases
<mwhudson> (i think maybe the one in the upload queue is a straight git export and the one on github is the output of some 'make dist' type thing?)
<mwhudson> also i'm probably going to upload it to debian as 1.0.34-1 tomorrow so maybe you should use a version that won't be overwritten by that? (or maybe being overwritten is fine?)
<mwhudson> also also i'm going to bed
<mwhudson> (package for debian in http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/log/?h=debian fwiw)
<zyga> mwhudson: hey
<zyga> mwhudson: I'm not sure, I didn't' do the yakkety release, please definitely use the make dist one
<mwhudson> zyga: the snap-confine-1.0.34.tar.gz is a make dist one?
<mwhudson> (it looks like it to me)
<zyga> mwhudson: yes
<mwhudson> zyga: on https://github.com/snapcore/snap-confine/releases
<zyga> mwhudson: libexecdir should stay as /usr/lib/snapd
<zyga> mwhudson: (for various interesting reasons)
<willcooke> didrocks, btw - did that issues detecting gtk3 vs gtk2 on 64bit get fixed?
<zyga> mwhudson: if you want I can make those changes and send you patches
<mwhudson> zyga: i took that change
<mwhudson> http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/tree/debian/rules?h=debian#n22
<mwhudson> zyga: but thanks for confirming :-)
<zyga> mwhudson: in .34 the config option changed to --disable-seccomp and --disable-apparmor
<zyga> mwhudson: nice, thank you
<mwhudson> zyga: ah ok, please send a patch for that :)
<zyga> mwhudson: gladly
<gouchi> hi
<zyga> gouchi: hey
<mwhudson> it still built with --disable-confinement though, unless i goofed my build testing
<gouchi> I was wondering if those device will be part of opengl interface ?
<gouchi> http://www.hastebin.com/ixuyuduxaz.vhdl
<zyga> mwhudson: that's odd, it definitely should not
<zyga> mwhudson: cloning to test now
<mwhudson> cool
 * mwhudson really really going to bed now
<mwhudson> ttyl
<zyga> gouchi: let me check
<zyga> mwhudson: bye!
<mup> PR snapd#1478 closed: many: Add device authentication skeleton <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1478>
<mup> PR snapd#1488 opened: store: switch search to new snap-specific endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/1488>
<zyga> gouchi: /dev/dri/dri0 is not in the opengl interface
<zyga> gouchi: can you tell me more about the application you are trying to run as well as the GPU and driver you are using
<gouchi> zyga: using intel gpu I tried to run retroarch in drm/kms with egl
<gouchi> zyga: https://github.com/libretro/RetroArch/wiki/KMS-mode
<gouchi> zyga: As I couldn't make it work with x11 interface, I tried with opengl interface
<zyga> gouchi: this looks closer to the mir interface
<zyga> gouchi: and it seems it would require a new interface to work, can you please look at snapd pull requests on github.com/snapcore/snapd, look at the mir interface there and use it as a starting point
<gouchi> zyga: I will try thank you
<zyga> gouchi: then the application using the new interface
<zyga> gouchi: note that application can  gain permissins just by having a slot of a given type, it doesn't have to be connected
<zyga> gouchi: in thise sense, you could use the new interface slot to grant that application to run with direct gpu access
<gouchi> zyga: this one https://github.com/snapcore/snapd/pull/1299 ?
<mup> PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299>
<zyga> yes
<mup> PR snapd#1485 closed: snap: add `snap run --shell` <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1485>
<didrocks> willcooke: yeah, it's fixed now
<willcooke> didrocks, thanks!
<didrocks> willcooke: just rebuild your snap if you didn't since Friday :)
<willcooke> running it now
<didrocks> willcooke: ensure you snapcraft update (I don't know how much it caches)
<didrocks> run*
<willcooke> ack
<mup> PR snapd#1473 closed: tests, integration-tests: port refresh all test to spread <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1473>
<gouchi_> zyga: better http://www.hastebin.com/dubevesula.coffee but I got fatal error
<zyga> gouchi_: is that with mir or with a new interface?
<gouchi_> zyga: mir interface
<gouchi_> zyga:   plugs: [network, network-bind, mir, opengl, home]
<zyga> gouchi_: try slots: [mir]
<zyga> gouchi_: mir slot let mir "be mir" and talk to GPUs and such
<willcooke> didrocks, yay! works.  thank you!!
<zyga> gouchi_: though you will probably need bleeding edge code from that branch
<zyga> gouchi_: do you know how to rebuild snapd?
<gouchi_> zyga: I followed https://github.com/snapcore/snapd/blob/master/README.md and build it
<zyga> gouchi_: you can use github.com/zyga/devtools to use the new version easily
<zyga> gouchi_: look at the refresh-bits script there
<zyga> gouchi_: I wrote that for working on interfaces
<gouchi_> zyga: I will try thank you very much
<zyga> gouchi_: refresh-bits snap snapd setup run-snapd restore
<zyga> gouchi_: (read the code to see what happens)
<zyga> gouchi_: it also has useful --help
<gouchi_> zyga: same error with  slots: [mir]
<didrocks> willcooke: excellent! yw ;)
<mup> PR snapd#1458 closed: many: add `snap enable/disable` commands <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1458>
<mup> PR snapd#1489 opened: snap: ensure unknown arguments to `snap run` are ignored <Created by mvo5> <https://github.com/snapcore/snapd/pull/1489>
<sborovkov> Hi. What is log-observe interface doing? I am using python's systemd API to get journal contents and poll for it's changes but I still get some APPARMOR warnings
<sborovkov> operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/a82c9efe141649b3983327aa20a8ed23/system@5b2dfcfdd13348ce82cbcf01123e4caa-000000000000064e-000536e30cc89344.journal"
<sborovkov> And this one: operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/a82c9efe141649b3983327aa20a8ed23/system.journal" pid=1368 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<seb128> sborovkov, whare snapd version do you use?
<sborovkov> seb128: snapcraft should be from last week I think. I did build the image before that I think though
<seb128> sborovkov, snapd, not snapcraft
<seb128> the snappy system service
<seb128> not the build tools
<sborovkov> Understood, how do I make it ouput the version?
<seb128> on ubuntu "dpkg -l | grep snapd"
<mvo> apt list snapd
<mvo> :)
<mvo> (so much nicer IMNSHO)
<josepht> good to know
<sborovkov> wait, I am on RPI
<sborovkov> no dpkg
<seb128> k
<seb128> well anyway the journal interface got some fixes in 2.0.10 which is less than a week old
<seb128> make sure you have this version
<sborovkov> Understood
<seb128> unsure about your RPI image
<seb128> maybe mvo can help
<sborovkov> My image is more recent, so might be that.
<seb128> (snapd really needs a -v argument)
<mhall119> sergiusens: what's the easiest way for me to try your snapcraft pkg-config lookup patches when doing a cleanbuild?
<ogra_> grmpf .. packaging a java GUI app i can get everything to work fine with the default GTK theme (win95 style) ... but as soon as i ship light-themes and set a theme no icons are found :(
<jdstrand_> sborovkov: re log-observe and systemd journal> there is a fix in 2.0.10 for that (https://launchpad.net/ubuntu/+source/snapd/2.0.10). If you are using Ubuntu, 2.0.10 hasn't landed yet in 16.04, but is on its way
<seb128> ogra_, unsure what toolkit they use but you might lack a svg loader
 * didrocks wonders why seb128 is talking about svg loader :p
<didrocks> hem hem ;)
<seb128> lalala ;-)
<didrocks> heh
<didrocks> ogra_: yeah, ensure that you have this svg loader, icons are in svg and we experienced that some theme engine won't even look at them until they have a svg loader/decoder
<ogra_> seb128, well, i see it in the gdk loaders dir
<ogra_> and i regenerate the loader cache on app startup
<didrocks> is it that one doing the decoding?
<didrocks> despite using the gtk theme engine in qt, it's qt itself doing the svg decoding
<didrocks> for instance
<ogra_> well, it is a java awt app
<didrocks> unsure if awt can decode svg
<didrocks> try shipping a corresponding .png image
<seb128> well those work on normal desktop I guess
<didrocks> in the same directory than one icon it's using
<seb128> that would be a known problem otherwise?
<didrocks> and see if it can open it
<didrocks> yeah, what about without devmode?
<ogra_> i only run without devmode ;)
<didrocks> and if you run your app directly?
<didrocks> like without the u-c-l wrapper?
<ogra_> if i run it as java -jar $path_to_jar i get icons
<ogra_> so thereis still some env var missing or so
<didrocks> did you try with the gtk launcher?
<didrocks> to see if it's something that you might miss
<ogra_> way to much overhead
<didrocks> well, try it at lest
<didrocks> least*
<ogra_> but i'll tyr to grab bits from there
<didrocks> and you know, you can override some stage-packages
<didrocks> at least, try it and see
<didrocks> that will give you some hints
<didrocks> you are then welcome bringing a smaller one and contribute :)
<didrocks> rather than duplicating
 * ogra_ is looking for the most minimal setup here 
<didrocks> this is what I did with the new desktop launchers
<didrocks> the minimal required things for gtk/qt apps
<didrocks> but it seems it's been a couple of days you are stuck on this without even trying another one
<didrocks> just to ensure that the issue is larger than just missing dependencies
<didrocks> intellij IDEA is using java awt
<didrocks> and have working theme here
<didrocks> (since I switched it to my gtk launcher)
<ogra_> didrocks, btw, it would be good if you stopped using a bash shebang in these launchers ... on actual snappy images we might not have bash access
<ogra_> (while /bin/sh is always guaranteed to be there)
<didrocks> ogra_: yeah, patch welcome, otherwise, it's on my list, but for later :)
<ogra_> yeah
<didrocks> ogra_: I think it would be better to be compiled anyway, so rewriting in go or such (but then, there is the issue for uncompiled snaps like python and soâ¦)
<zyga> jdstrand: https://bugzilla.suse.com/show_bug.cgi?id=986050#c1
<zyga> jdstrand: and https://bugzilla.suse.com/show_bug.cgi?id=986050#c2
<kyrofa> ogra_, didrocks doesn't like to be limited by dash
<ogra_> heh
<didrocks> I'm used to dash, did a big part of porting years ago of our scripts to dash :)
<didrocks> but here, I just wanted something which works quickly :p
<ogra_> you could just put bash into stage packages by default ... whats another 5MB if your hello-world already needs 100MB of deps :P
<didrocks> ogra_: better to do just use dash, it's not user visible anyway
<ogra_> i was joking ;)
<oSoMoN> dpm, hey, Iâm experimenting with snapcraft and webbrowser-app, and https://github.com/dplanella/qt5conf/blob/master/qt5-launch#L45 appears to be preventing the app from starting, making XDG_DATA_HOME a non-writable location sounds wrong
<ogra_> oSoMoN, try didrocks' launcher instead
<oSoMoN> ogra_, is that the desktop/qt5 one?
<ogra_> yep
<oSoMoN> cool, will try that one
<sergiusens> kyrofa mind quickly fixing https://github.com/snapcore/snapcraft/pull/622 ?
<mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
<kyrofa> sergiusens, yeah I'm working on it as we speak
<sergiusens> kyrofa oh, nice :-)
<mup> PR snapcraft#630 closed: Report a nice error when registering too fast <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
<kyrofa> sergiusens, super annoying... can't get it to happen locally :P
<gouchi_> using x11, opengl, unity interfaces shouldn't make XOpenIM to failed ?
<kyrofa> elopio, are you around?
<gouchi_> ftp://www.x.org/pub/X11R7.7/doc/man/man3/XOpenIM.3.xhtml
<kyrofa> sergiusens, look at this trace: http://pastebin.ubuntu.com/18546556/
<kyrofa> sergiusens, makedirs(..., exist_ok=True) -> "bam, that already exists!" -> death
<kyrofa> sergiusens, this test isn't failing locally and I can't duplicate that behavior. Do you see anything I'm missing? Ensure failure is here: https://travis-ci.org/snapcore/snapcraft/jobs/142467621
<sergiusens> kyrofa sure, give me a sec
<kyrofa> It's a symlink, not a dir, but that still works fine locally. I even tried messing with the permissions in case that threw it off, but it works locally anyway. Do we know which python3 version is on the job machines?
<kyrofa> Oh... wait...
<kyrofa> sergiusens, nevermind, I'm stupid
<kyrofa> sergiusens, that was way too hard
<sergiusens> kyrofa what was it
<sergiusens> ?
 * didrocks is interested, I looked at the os code, and I see 2 protections against what you saw :)
<elopio> kyrofa: hello
<elopio> how can I help you?
<kyrofa> sergiusens, didrocks it's a test artifact. The integration test runs on a partially build snap, to test that the change works on an old tree. But the parts/foo/src symlink is absolute, not relative, so it's a broken one in jenkins (doh!)
<kyrofa> elopio, nevermind, sorry!
<gouchi_> I will be glad if somebody can test my snap package to see if I am doing something wrong
<gouchi_> here is the source : https://framadrop.org/r/vEimxEXgr2#SHwKK3R8qJ12soOacXboC+PbzNPvb/xPoijFaq7+e5s=
<didrocks> kyrofa: ahah, that explains! :)
<kyrofa> didrocks, super confusing :P
<gouchi_> for now it failed here https://github.com/libretro/RetroArch/blob/master/gfx/common/x11_common.c#L338 using x11, opengl, unity7 interface
<zyga> gouchi_: I can look but not tonight, I have plenty of things to finish
<sergiusens> kyrofa heh, that's what you get for mocking ;-)
<kyrofa> sergiusens, nothing is mocked!
<kyrofa> sergiusens, it's just a bit of an odd test is all. I made the mistake of committing exactly what snapcraft gave me (an absolute symlink) without thinking about it
<gouchi_> zyga: thank you no problem I can't find why it stops
<sergiusens> kyrofa preparing the testbed/fixture would require you to make it absolute again though, right?
<kyrofa> sergiusens, nah, it just copies the entire snap directory that contains the symlink already made
<didrocks> kyrofa: indeed :)
<bpeak> Man, I really want chromium on snappy
<ogra_> you can ... but only in devmode
<jdstrand> roadmr: hey, at some time whenever it is convenient, can you pull r692. this is for puritine click and not urgent (next roll out is fine)
<roadmr> jdstrand: sure thing, I'll put it in the pipeline!
<seb128> gouchi_,  ogra_ was having the same XOpenIM issue, unsure if he solved it
<ogra_> well, i dont remember anymore
<ogra_> :)
<jdstrand> roadmr: thanks!
<ogra_> (i remember i had it ...)
<ogra_> ah, no, i didnt .... that was when i tried to package servo
<gouchi> ogra_: I checked snappy playpen packages and only mpv is using XOpenIM
<gouchi> ogra_: but I doubt it using x11 code as mpv snap package is using only opengl interface
<seb128> gouchi, does it work in devmode?
<kyrofa> zyga, how do you test snap-confine, since it conflicts with u-c-l?
<gouchi> seb128: nope
<roadmr> hey folks, what's a good/recommended way to get or build a snappy-only image for a rpi2? i.e. not xenial-with-snapd but an "all-snap" image?
<zyga> kyrofa: you install ubuntu-core-launcher too :)
<zyga> kyrofa: snap-confine has two binary packages
<zyga> kyrofa: one of them is snap-confine, the other is ubuntu-core-laucher
<kyrofa> zyga, argh, missed that
<kyrofa> Thanks :)
<seb128> gouchi, I can try having a look if you want
<gouchi> seb128: I will be glad to, thank you very much
<seb128> yw
<sergiusens> elopio the current interface we have for pushing files makes me sad
<roadmr> zyga: I'm sure you'll know how to get an all-snap image for rpi2 :)
<zyga> roadmr: yes, get a delorean and come back later ;) in all honesty I didn't work with all snap images for a while, I bet you can still get an image somewhere but I wasn't in the loop around that lately
<roadmr> zyga: thanks! hehe no problem, I'll walk to the future (also known as : waiting) X-)
<zyga> roadmr: I think ogra_ might know more
<zyga> roadmr: note that slangasek works on ubuntu-image so he might also know some useful thigns I dont
<roadmr> cool! yay, fwiw I'm happy to assemble my own image if pointed to tools/docs
<ogra_> well, the current images ... even if you buuild them newly .... are months outdated
<ogra_> i doubt any recent snaps would even work
<roadmr> ogra_: oh bummer, and there's no way to build one with recent components I reckon?
<ogra_> afaik mvo has a hacked u-d-f that might get you something working that would persist for a few days until you need to break it again
<roadmr> haha :)
<ogra_> roadmr, the recent components are not in the store, ubuntu-core is ages old
<roadmr> ogra_: so for all real purposes I'm better off just using xenial with snapd?
<ogra_> we would need to update it first, but there are some blockers
<ogra_> yeah
<ogra_> just use a classic install
<roadmr> ok... I can do that, no problem :)
<roadmr> thanks ogra_ :)
<elopio> sergiusens: do you mean, the store clients?
<sergiusens> elopio _upload.py specifically
<elopio> sergiusens: I agree. It doesn't match the others, and passing the client as an argument is a little spaghetti
<elopio> sadly, I ended up with no good refactoring in mind for it. Do you have one?
<sergiusens> elopio I think I am going to spend the rest of the week on a little refactor
<elopio> \o/
<ogra_> seb128, didrocks, soo ... it seems icons are only broken if i put any icon themes beyond hicolor into stage-packages (i had light-themes in there when it broke) ... ii guess snapcraft omitting all maintainer scripts breaks the icon stuff somehow
<seb128> that's on possibility
<seb128> one other is that the other themes use svg files
<seb128> which you don't have proper support for loading
<didrocks> yeah
<ogra_> i do
<didrocks> did you get the same behavior with the desktop launcher?
<ogra_> i have all pixbuf loaders and the loader cache is updated
<seb128> is your snap available somewhere so I can have a look?
<seb128> right
<seb128> but java maybe doesn't use gdkpixbuf
<seb128> like we tried with a qt app and were missing libqsvg or something
<ogra_> seb128, it works if i launch th jar directly
<seb128> from outside the snap?
<ogra_> yes
<seb128> right
<ogra_> just using the java  on my desktop i get proper icons
<seb128> anyway, is your snapcraft.yaml public?
<seb128> so I can have a look
<ogra_> not the current version.. but it has only:
<ogra_>     stage-packages:
<ogra_>       - libglib2.0-0
<ogra_>       - hicolor-icon-theme
<ogra_>       - openjdk-8-jdk
<ogra_> (i dont want *any* integration with the host here .... the app should ship and run everything standalone
<ogra_> )
<ogra_> seb128, https://github.com/ogra1/jtiledownloader ... thats the one not usin any themeing
<seb128> ogra_, k
<seb128> ogra_, you should try the desktop/gtk3 part launcher, it's a big hammer but if it works it would tell you there is some magic from the wrapper you can borrow
<seb128> would easily rule out a class of issues
<ogra_> i borrowed most of it already ... but i'm now pretty sure it is the postinst files breaking the stock icons since as soon as i drop the ubuntu themes and all theme hackery it all works just fine
<ogra_> also the XDG_DATA_HOME setting the launcher uses breaks awt/swing
<MichaelTunnell> niemeyer: here is why I've been asked so many random questions lately, https://youtu.be/0ApRUndiXKU
<ogra_> the app cant start
<joc_> sergiusens: hi, have you thought any more about the python3 PR? are you still nervous about test coverage?
<kyrofa> sergiusens, I think snapcraft#622 should be good now
<mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
<oSoMoN> when creating a snap of webbrowser-app (which contains oxide), Iâm seeing this:
<oSoMoN> Removing suid/guid from /build/webbrowser-app/snap/parts/webbrowser-app/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox
<oSoMoN> this prevents oxide from functioning correctly
<oSoMoN> how can I prevent snapcraft from tempering with the suid/guid of the chrome sandbox?
<sergiusens> joc_ I think it is ok
<sergiusens> elopio mind taking a look at the python --root pr?
<elopio> sergiusens: I'm out for swimming lessons. I'll do that on the way back.
<sergiusens> elopio thanks
<sergiusens> oSoMoN suid and guid would be blocked by apparmor and the review tools
<sergiusens> jdstrand any alternatives there ^?
<oSoMoN> sergiusens, why remove the suid and guid then, if apparmor would block them anyway?
<sergiusens> oSoMoN it was the nice thing to do before --devmode ever existed
<oSoMoN> sergiusens, ah ok, it predated --devmode, that makes sense
<sergiusens> oSoMoN by a year almost
<oSoMoN> sergiusens, shouldnât it be deprecated now? sounds like --devmode is much better suited
<sergiusens> oSoMoN we still need to be able to auto remove the suidness somehow for people with confinement strict
<sergiusens> oSoMoN I suppose we can tie this up to the `confinement` flag; mind logging a bug?
<oSoMoN> sergiusens, doing right away, against which project?
<sergiusens> oSoMoN snapcraft
<oSoMoN> sergiusens, against the project itself, or against the source package? it seems there are existing bug reports targetting both
<sergiusens> oSoMoN project, we always ask people to log against the project in the release ANN :-)
<oSoMoN> ok
<oSoMoN> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1599234
<mup> Bug #1599234: should not remove suid/guid from binaries when confinement is devmode <Snapcraft:New> <https://launchpad.net/bugs/1599234>
 * zyga -> supper, then more suse hacking
<tsimonq2> sergiusens: when's the next planned Snapcraft release?
<mup> Bug #1586581 changed: CAP_SYS_ADMIN interface for unconfined snaps <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1586581>
<sergiusens> tsimonq2 today
<niemeyer> MichaelTunnell: Nice!
<tsimonq2> sergiusens: oh ok
<sergiusens> tsimonq2 why?
<tsimonq2> sergiusens: it really would have been great to land my latest PR before 2.12 but it's no big deal :)
<sergiusens> tsimonq2 2.12 has been out for a while though ;-)
<sergiusens> we are releasing 2.13 ;-)
<tsimonq2> wait
<tsimonq2> lol
<tsimonq2> I meant 2.13
<tsimonq2> sergiusens: is it already released?
<tsimonq2> sergiusens: I mean technically, are the git tags set and everything?
<tsimonq2> sergiusens: if not, any chance you have a minute to help me finish my PR?
<tsimonq2> PR #619
<tsimonq2> snapcraft#619
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> there we are
<jdstrand> oSoMoN, sergiusens: I commented in the bug
<sergiusens> tsimonq2 I am in the process of reviewing the last PRs right now though
<sergiusens> tsimonq2 take your time to finish it, nothing wrong with going into the next release ;-)
<sergiusens> jdstrand thanks
<tsimonq2> alright sergiusens, the only things left are some annoying test failures, test failures that could be easily solved today
<sergiusens> tsimonq2 test failures are the hardest part of the problem; just look at kyrofa, he spent all morning looking into why his PR failed
<oSoMoN> jdstrand, Iâve seen that, thanks!
<kyrofa> tsimonq2, indeed, look at me
 * kyrofa gives his best blue steel look
<tsimonq2> \o/ kyrofa
<tsimonq2> sergiusens: how close are you from making 2.13 final? basically, how much time do I have left to fix things if I really want my PR landed in 2.13? :)
<kyrofa> tsimonq2, don't stress about that. If it gets in, it gets in. We try to do weekly releases
<tsimonq2> kyrofa: alright :)
<pachulo> sergiusens: one question, when do you plan to update the telegram-snap in the store? I've tried to create the snap with telegram-desktop 0.9.56 and it worked ok
<kyrofa> tsimonq2, just focus on quality. Make sure those tests look good
<sergiusens> pachulo I should just do it I guess, I wanted to fix some input method problems first though
<tsimonq2> kyrofa: I'm working hard :)
<tsimonq2> kyrofa: I'm not in a rush, I won't do it halfway, like I said, it would just be *nice* for source-checksum to land in 2.13, so I'm going to work towards that goal :)
<kyrofa> tsimonq2, excellent
<pachulo> sergiusens: i noticed problems when trying to write letters with accents, but thought it was a problem with the application, not the snap versio of it: https://github.com/telegramdesktop/tdesktop/issues/1360
<sergiusens> oh, look at that, niemeyer too ^
<sergiusens> pachulo thanks, I will see if this is indeed the problem I see
<niemeyer> I don't have the problem out of a snap, FWIW
<niemeyer> sergiusens: Also, those particular accents work.. probably something else
<sergiusens> niemeyer yeah, most likely missing something input method related.
<mup> PR snapcraft#614 closed: python3: use --root instead of --target <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/614>
<pachulo> maybe is a silly question, but after checking the documentation could not find an answer: Was trying to create a MAME snap using the "make" plugin, but as it seems that there is no "install" target in the MAME Makefile it fails to build because the snapcraft make plugin tries to install it; how should I proceed?
<jrwren> pachulo: thanks for re-asking. I'm watching to see the answer.
<kyrofa> sergiusens, snapcraft's python2 plugin can't seem to install this from pip: https://pypi.python.org/pypi/pymacaroons-pynacl/ . Is it because wheels are disabled? Think the --root PR will fix that?
<kyrofa> sergiusens, oh... that was only python3
<sergiusens> kyrofa it won't
<sergiusens> kyrofa global-options disable wheeling
<kyrofa> sergiusens, hmm... how might one get around this, then?
<kyrofa> pachulo, do you know off the top of your head what needs to be placed into the snap after the part is made?
<kyrofa> pachulo, i.e. can you safely separate the compiled binaries from the sources?
<kyrofa> pachulo, that's typically what an install rule does-- the upstream project knows what it needs to run and where things need to go
<kyrofa> pachulo, if your upstream project didn't supply that, then you'll need to create a local plugin that simply calls "make" and then copies stuff in explicitly rather than relying on an install rule
<sergiusens> kyrofa elopio sup
<kyrofa> sergiusens, on my way
<pachulo> kyrofa: not really, but I was planning on looking at the files installed by the repostory package to see what I need to copy
<mup> Bug #1598304 changed: systemd services created by snappy breaks etckeeper <etckeeper:New> <Snappy:Invalid> <https://launchpad.net/bugs/1598304>
<pachulo> kyrofa: I will try the local plugin approach, thanks for your suggestion!
<kyrofa> pachulo, sure!
<tsimonq2> *sigh* I have been racking my brain on this for too long, it's time to seek help, I've tweaked a lot of different things to no avail...
<tsimonq2> (in snapcraft#619 )
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> I'll push my changes now, but I'm getting thrown this error in the unit tests:
<tsimonq2> TypeError: __init__() missing 1 required positional argument: 'source_checksum'
<tsimonq2> if anybody is around to give me a hand and just point me in the right direction, that would be awesome, I know kyrofa was helping me the other day so I don't know if he wishes to help again :)
<kyrofa> Sure tsimonq2, give me a minute
<tsimonq2> thanks kyrofa :)
<kyrofa> Alright tsimonq2 I'm taking a look at the branch now
<mup> PR snapcraft#631 opened: Fix the store integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/631>
<tsimonq2> cool thanks kyrofa
<netphreak> hi, guys!
<kyrofa> tsimonq2, alrighty
<kyrofa> tsimonq2, take a look at the Base class
<kyrofa> tsimonq2, specifically its __init__
<kyrofa> tsimonq2, do you know which parameters are required, and which are optional?
<kyrofa> Hey netphreak :)
<netphreak> Just uploaded my first snap to the store in the Edge channel, and get the following error from automated review: "package contains external symlinks: usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/cacerts lint-snap-v2_external_symlinks"
 * tsimonq2 pops open the source
<netphreak> The snap uses the java/jdk plugin.
<tsimonq2> kyrofa: in snapcraft/internal/sources.py ?
<kyrofa> tsimonq2, indeed
<tsimonq2> kyrofa: alright
<kyrofa> netphreak, can you pastebin the output of ls -l prime/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/
<tsimonq2> kyrofa: what's required is source
<tsimonq2> the rest are optional depending on what you are trying to do
<netphreak> : No such file or directory
<kyrofa> tsimonq2, how can you tell? What about source_dir?
<kyrofa> netphreak, I made the assumption you still had the built tree there. Do you still have your prime directory lying around?
<tsimonq2> kyrofa: I just guessed from what I know about snapcraft.yaml files, there's not much in the Base class that would tell me a lot about that
<tsimonq2> except that source_dir kind of stands out
<kyrofa> tsimonq2, sure there is. Note that source and source_dir aren't immediately followed by =
<tsimonq2> (in the init)
<tsimonq2> well yes
<kyrofa> tsimonq2, the other parameters all have default values
<kyrofa> tsimonq2, which means they aren't required
<tsimonq2> kyrofa: well source-checksum isn't required either
<kyrofa> tsimonq2, indeed. And it shouldn't
<kyrofa> tsimonq2, check out Zip's __init__ or Tar's __init__
<netphreak> i still have the snap build lying around.. but can't see no prime dir
<tsimonq2> kyrofa: oh, so it seems to be required?
<kyrofa> netphreak, ah, your snapcraft is a little old then, but no matter: run `ls -l snap/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/`
<netphreak> ahh.. sorry.. I do have a prime dir.. moment.
<kyrofa> tsimonq2, indeed
<kyrofa> tsimonq2, but the tests don't pass it in
<kyrofa> tsimonq2, so you get an error saying a param is missing
<tsimonq2> ahhh
<kyrofa> tsimonq2, so: is it required or not? If so, the tests need to be updated. If not, the __init__s need to be updated
<tsimonq2> let me fix and do a test build locally
<tsimonq2> kyrofa: it's optional, I'll update
<kyrofa> tsimonq2, very good
<netphreak> http://paste.ubuntu.com/18577482/
<kyrofa> netphreak, yikes, yeah. Hmm... it's too bad I'm so unfamiliar with java, I'm not sure what's causing that
<tsimonq2> kyrofa: I leanred something new today, I've never worked with *that* complex of Python :)
<kyrofa> tsimonq2, the day is a waste without learning something new!
<netphreak> Well, i guess everyone using this plugin will have the same problem as i have run into..
<kyrofa> netphreak, does /etc/ssl/certs/java/cacerts actually exist?
<tsimonq2> kyrofa: yep! :D
<tsimonq2> kyrofa: http://paste.ubuntu.com/18577713/ - I'll start looking around for something obvious
<tsimonq2> oh hm
<kyrofa> tsimonq2, self.source_checksum
<netphreak> nope.. seems the folder "/etc/ssl/certs/java/" is empty
<kyrofa> tsimonq2, you might consider running ./runtests.sh static
<tsimonq2> kyrofa: aha, that's right, because it's not called in the constructor
<kyrofa> netphreak, default-jdk might include that
<netphreak> Hmm.. I think the plugin includes a default java in the final snap...
<netphreak> why this references a file that does not exist is a bit weird..
<kyrofa> netphreak, because it's pulled in by openjdk-8-jre-headless
<kyrofa> netphreak, which apparently contains an absolute symlink
<tsimonq2> kyrofa: I think it would be good to ensure integration test coverage with source-checksum, right?
<kyrofa> But these are stage-packages, so they don't go where they think they're going
<kyrofa> tsimonq2, agreed
<tsimonq2> kyrofa: the unit tests all passed (\o/) so I'll make sure integration tests pass, I'll whip that up, then I should be done
<kyrofa> tsimonq2, nice job :)
<tsimonq2> kyrofa: \o/ thanks :)
<tsimonq2> kyrofa: and thank you so much for your help
<kyrofa> tsimonq2, of course
<tsimonq2> kyrofa: build is failing? huh? https://github.com/snapcore/snapcraft
<kyrofa> tsimonq2, I don't see it failing...
<kyrofa> elopio, wait... was this actually successful then? http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1083/console
<tsimonq2> http://storage2.static.itmages.com/i/16/0705/h_1467749818_7705696_1b78d50c7a.png
<tsimonq2> kyrofa: that ^
<mup> PR snapd#1490 opened: overlord: implement &Retry{After: duration} support for handlers <Created by pedronis> <https://github.com/snapcore/snapd/pull/1490>
<netphreak> kyrofa: I just created the following bugreport: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1599281
<mup> Bug #1599281: Snap upload automated review error <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1599281>
<kyrofa> tsimonq2, ah, looks like test ran into a timing issue
<kyrofa> tsimonq2, I requested a new run
<tsimonq2> kyrofa: oh alright, I just thought that I should mention it
<kyrofa> netphreak, very good, thank you!
<tsimonq2> kyrofa: \o/ yes! finally! build passed!
<elopio> kyrofa: http://paste.ubuntu.com/18579746/ did you touch something on the parser?
<kyrofa> elopio, no
<kyrofa> elopio, that's totally external to the snapcraft lifecycle, right?
<elopio> kyrofa: yes. Maybe a timeout there, but not related to your change, so the execution is ok.
<kyrofa> elopio, alright. I guess I need to update the branch anyway, so running again! Stop landing stuff, sheesh
<tsimonq2> kyrofa: you think md5, sha256, and sha512 are good enough to support for checksumming or is there another format that people use that comes to mind?
<kyrofa> tsimonq2, did you see sabdfl's comment on bug #1585913 ?
<mup> Bug #1585913: Snapcraft should allow the user to verify downloaded files with a checksum <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1585913>
<tsimonq2> kyrofa: no, I didn't catch that
<tsimonq2> kyrofa: hmm, so is he saying to only support SHA3-384?
<kyrofa> tsimonq2, honestly I'm not sure. Most often I see md5
<kyrofa> tsimonq2, we probably want to support a range of things there
<tsimonq2> kyrofa: yeah, which is why I'm asking
<kyrofa> tsimonq2, so make sure 384 is supported
<kyrofa> But I'd include the others as well
<tsimonq2> kyrofa: alright
<kyrofa> tsimonq2, make sure you have tests for each
<tsimonq2> kyrofa: yeah currently, if my code works, we have md5, sha256, and sha512
<tsimonq2> yep
<kyrofa> tsimonq2, excellent
<tsimonq2> kyrofa: I'm running my integration tests for those now, so I'm not entirely sure if it even works yet, lol
<tsimonq2> kyrofa: would you suggest I respond to Mark in the bug report asking for clarification?
<kyrofa> tsimonq2, sure, he won't bite.
<tsimonq2> great :)
<ogra_> tsimonq2, dont wear a tasty tempura crust though ...
<tsimonq2> ogra_: huh?
<ogra_> then he might bite ;)
<tsimonq2> oh hahahaha
<Croepha> so when I use stage-packages, is it actually downloading each time I run it? it looks like it is, is there a way to tell it to cache the downloads?
<kyrofa> Croepha, they're pulled along with everything else in the pull step. Once the pull step has completed just don't run it again unless you need to add something to it
<kyrofa> Croepha, for example, you can clean only back to the build step (snapcraft clean -s build) which will leave pull alone
<kyrofa> Dangit ogra_ I'm hungry
<Croepha> kyrofa: ok, got it, thanks :)
<sergiusens> elopio so far https://github.com/snapcore/snapcraft/compare/master...sergiusens:refactor/push
<sergiusens> still ways to go
<sergiusens> i will bbl
<tsimonq2> bug 1585913
<mup> Bug #1585913: Snapcraft should allow the user to verify downloaded files with a checksum <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1585913>
<tsimonq2> kyrofa: whoever is hacking on that bot should know that https://pad.lv/1585913 = https://launchpad.net/bugs/1585913
<robert_ancell> ev, who's in charge of lp:rnrserver now?
<thomi> sergiusens: did the way we load & run snapcraft plugins change between 2.11 and 2.12? I'm sure I used to be able to set a breakpoint in my plugin and have it work in 2.11. In 2.12 they seem to be ignored somehow?
<tsimonq2> kyrofa: what does snapcraft/internal/sources.py:141:1: C901 'FileBase.check_checksum' is too complex (10) mean and how do I fix it?
<tsimonq2> kyrofa: I'm assuming it means I have to dumb down my code?
<thomi> tsimonq2: I believe it's the cyclomatic complexity check built into flake8  - https://en.wikipedia.org/wiki/Cyclomatic_complexity might help
<thomi> tsimonq2: it's not really about 'dumbing down' your code, but rather limiting the complexity of any one function.
<tsimonq2> thomi: I see
<tsimonq2> there's a way I can make it simpler
<tsimonq2> so I'll do that :)
<Kamilion> yeah, if you're seeing that; you need to reorganize slightly; Ran into that while I was working on Customizer.
<Kamilion> good to see you on changelogs though, tsimonq2. :)
<tsimonq2> hey it's Kamilion! \o/
<Kamilion> funnily enough, while I was doing work on checksumming files too.
<tsimonq2> Kamilion: how'd you find me? lol
<tsimonq2> hah yeah
<Kamilion> w'dya mean? I've been here.
<tsimonq2> Kamilion: I haven't seen you in ages :)
<Kamilion> no longer in a release crunch
<tsimonq2> oh?
<Kamilion> well, 16.04's out now XD
<tsimonq2> XD
<Kamilion> i don't have to do another LTS job till 2018
<Kamilion> and most of my papercuts were fixed between 15.04 and 16.04 WRT xen, openvswitch, and ceph.
<Kamilion> Still can't get snapd to work from a livecd though
<tsimonq2> Kamilion: so you here to submit code to Snapcraft, snap some things, support, what? just curious :)
<tsimonq2> oh :(
<Kamilion> as you know, I build appliance images
<Kamilion> so everything was already running from the iso squashfs
<tsimonq2> yeah
<Kamilion> not sure if it's just unhappy about the rootfs being squash too or something else casper is tweaking when it boots the system.
<Kamilion> that reminds me, i should say hi to walter when I get a chance
<tsimonq2> Kamilion: *shrug* I don't know anything about that sort of thing :)
<tsimonq2> I thought he's online?
<Kamilion> probably is; I'm just in like 180 channels
<tsimonq2> oh lol
<Kamilion> and busy with several other projects as well
<Kamilion> but i saw you talking when I was scrolling through the list and thought I'd say hi
<tsimonq2> well I hope things are going well :)
<Kamilion> if they weren't, I wouldn't be around ;)
<tsimonq2> ;)
<mwhudson> slangasek: hey, just pushed a patch from zyga to http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/log/?h=debian
<mwhudson> slangasek: otherwise i think that package is ready to go, what do you think?
<ev> robert_ancell: OLS owns rnr as a team - whatâs up?
<robert_ancell> ev, was wondering if there's a plan regarding snap reviews. I thought that that would use the click API, but looking into it I'm not sure that's the case
<robert_ancell> but 1574586 for reference
<robert_ancell> bug 1574586
<mup> Bug #1574586: Not able to rate/review snaps <Snappy:New> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1574586>
<ev> robert_ancell: I donât recall snap reviews coming up in vancouver or santa cruz. Has this found its way onto the roadmap?
<robert_ancell> ev, no, I don't think it's on the roadmap either so was wondering if there's been any decisions either way.
<robert_ancell> or if it should 'just work' with the click API.
<ev> I donât think itâd just work, but we can do a back of the envelope calculation if you need one
<robert_ancell> ev, that would be handy, thanks
<ev> sure thing
#snappy 2016-07-06
<sergiusens> thomi I just did a run through the commit logs, nothing stands out that would prevent this, plugin loading code has stayed unchanged
<TheMuso> If I want to file a bug against snapd, what project do I file the bug under in lp? Is it snappy?
<TheMuso> nvm think I have my answer.
<dholbach> good morning
<netphreak> morning :)
<mup> PR snapd#1491 opened: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1491>
<dholbach> kyrofa, sergiusens: does https://github.com/ubuntu/snappy-playpen/issues/145 look like a snapcraft bug to you?
<mup> PR snapd#1437 closed: snapstate: use snapstate.Type in backend.RemoveSnapFiles <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1437>
<mup> PR snapd#1480 closed: many: rename SideInfo.OfficialName to SideInfo.RealName <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1480>
<mup> PR snapd#1492 opened: overlord/auth: add Device/SetDevice to persist device identity in state <Created by wgrant> <https://github.com/snapcore/snapd/pull/1492>
<mup> PR snapd#1493 opened: store/auth: add SnapUbuntuStoreAuthService with device identity methods <Created by wgrant> <https://github.com/snapcore/snapd/pull/1493>
<mup> PR snapd#1494 opened: tests: add content sharing interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1494>
<mup> PR snapd#1495 opened: snapstate: rename OfficialName to RealName in the new tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1495>
<didrocks> josepht: hey! it seems that the cronjob imported my new part definition. However, it didn't refresh with the new description, any idea what's happening?
<mup> PR snapd#1496 opened: tests: add spread test for tried snaps removal <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1496>
<mup> PR snapd#1495 closed: snapstate: rename OfficialName to RealName in the new tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1495>
<pachulo>  /buffer 7
<mup> PR snapd#1497 opened: tests, integration-tests: port auth errors test to spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1497>
<lool> ogra_: hey, how goes?
<lool> ogra_: would you know if our future rpi3 image will be armhf or arm64 based?
<lool> ogra_: if armhf, how hard would it be to do an arm64 one for a third-party?
<ogra_> lool, we'll have both i think
<lool> ogra_: both officially supported?
<ogra_> (at least i plan to have snaps for both in the store, not sure which we'll make official
<ogra_> )
<ogra_> i'll bring that up at the sprint
<ogra_> we'll be most likely missing firmware blobs for BT and wifi for arm64
<ogra_> i havent played with that yet
<jamiebennett> ogra_: How much work will it be to have both?
<ogra_> not much i guess, once i have a snapcraft.yaml for the unofficial side it is just a snapcraft run away to build a kernel snap ... and gadgets change really rarely
<jamiebennett> ogra_: and on the testing and support side?
<ogra_> you mean when both are official ? well, twice as much :)
<ogra_> (manual smoke testing etc)
 * jamiebennett nods
<ogra_> i think it is fine to have the arm64 build unsupported
<jamiebennett> ack
<ogra_> for official arm64 we have the dragonboard
<oSoMoN> is there anything special to do to enable a snapped app to run translated (translations are correctly shipped with the package under /usr/share/locale/)?
<oSoMoN> is bug #1576282 relevant here?
<mup> Bug #1576282: Snaps built from deb can't be gettext translated <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
<ogra_> oSoMoN, yeah, you need to hack something up ... if your app uses gettext you should preload something that allows the bindtextdomain function to use a custom path
<oSoMoN> hugh, thatâs ugly!
<oSoMoN> ogra_, looking at your suggestion in the bug report
<ogra_> for plain libc translations LOCPATH should help
<ogra_> afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier
<oSoMoN> ogra_, Iâm working on webbrowser-app, which uses the i18n.tr() mechanism from the UITK, which I believe uses bindtextdomain under the hood
<ogra_> yeah, most likely
<joc_> morphis: i notice the tpm part on the wiki page has a source-type field which i think shouldnt be there
<morphis> joc_: it should be origin-type
<morphis> didrocks added that
<morphis> joc_: fixed that
<joc_> morphis: yep just added a part myself, maybe should remove it so it doesnt get copied by others
<joc_> good :)
<morphis> I talked with didrocks yesterday and thought he added origin-type and not source-type
<morphis> didrocks: was there any reason to use source-type instead?
<didrocks> morphis: hum, sorry, I'm lost context?
<didrocks> I didn't touch the tpm part
<didrocks> or not intentionally :p
<morphis> didrocks: or was it dholbach? :-)
<morphis> don't remember
<ogra_> the "d" guys :)
<didrocks> this is the only changed I did: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=16&rev1=15
<didrocks> seems it's dholbach, indeed: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=15&rev1=11
<oSoMoN> ogra_, actually, it seems the UITK exposes a i18n.bindtextdomain(domainName, dirName) method to QML
<ogra_> oSoMoN, oh ! thats neat ...
<oSoMoN> Iâll test it
<ogra_> if it works, you should perhaps mention it in the bug
<oSoMoN> will definitely doo
<oSoMoN> -o
<morphis> didrocks: yeah
<oSoMoN> didrocks, hey, Iâm looking at https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L29 , is this known to work correctly?
<oSoMoN> didrocks, I made a snap of webbrowser-app, the packages includes the mo files under $SNAP/share/locale/, but the app is not getting translated
<oSoMoN> looking at UbuntuI18n::setDomain(â¦), this should work, as it calls bindtextdomain with $APP_DIR/share/locale/
<didrocks> oSoMoN: are you sure bindtextdomain works? I remember that seb128 looked at this closer than I did
<didrocks> IIRC, there was an issue if you don't set it to prefix
<seb128> didrocks, well, if the uitk look into $APP_DIR whatever that is...
<oSoMoN> didrocks, what do you mean by set it to prefix?
<seb128> doesn't work for non-UbuntuUITK code
<seb128> since most upstream dp $datadir/locales
<seb128> which is set from the prefix at buildtime
<oSoMoN> seb128, but for QML apps using the UITK, that should work, right? see my comment at https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282/comments/3
<mup> Bug #1576282: Snaps built from deb can't be gettext translated <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
<ogra_> oSoMoN, i guess it depends ... if they use the same bindtextdomain in the backend you will have the exact same problem
<ogra_> sadly the issue is in the lowest level of the stack
<oSoMoN> ogra_, Iâm not sure I understand, I thought the issue was that apps normally had calls to bindtextdomain with a hardcoded path set at build time
 * oSoMoN is not very familiar with the inners of libintl
<seb128> oSoMoN, yeah, which is what I wrote no?
<seb128> oSoMoN, non-UbuntuUITK C code use $datadir/locales which is set according to prefix at buildtime
<oSoMoN> seb128, yes, thatâs why Iâm confused by ogra_âs comments, are there two separate issues maybe?
<seb128> oSoMoN, dunno about uitk, I guess it they handle it it's handled
<seb128> no idea
<ogra_> if UITK just uses the bindtextdomain fromm gettext any setting of a path will be ignored ... thats what i mean
<ogra_> wrapping the UITK around the funbction wont change its behaviour
<seb128> expect if the uitk read the env and do something like bindtextdomain(getenv($somevar))+"usr/share/locale")
<ogra_> try stracing it :)
<ogra_> seb128, with its own bindtextdomain ?
<ogra_> that would indeed work
<ogra_> if it just hooks into gettext there wont be a getenv ...
<kyrofa> dholbach, man... I have no idea what's going on with that qmake thing
<kyrofa> dholbach, I wonder if it means qmake's support for out-of-source builds is not that great
<seb128> oSoMoN, you might want to open a new bug rather than commenting on this one btw
<seb128> oSoMoN, that bug is specifically about code hardcoding a path to bindtextdomain() at buildttime
<seb128> oSoMoN, your issue is different and with the uitk, that should work
<oSoMoN> seb128, agreed, will do
<seb128> oSoMoN, thanks
<oSoMoN> seb128, could the first statement of your bug report (Â«the core image doesn't have locales definitionÂ») be the actual issue Iâm facing?
<seb128> oSoMoN, I guess it's possible yes
<oSoMoN> seb128, how would I go about shipping the locale definitions in my snap?
<seb128> not sure there is a standard way, fwded you an email discussing the freecad example which had some hacks for that
<mup> PR snapd#1497 closed: tests, integration-tests: port auth errors test to spread <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1497>
<mup> PR snapd#1496 closed: tests: add spread test for tried snaps removal <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1496>
<ogra_> oSoMoN, see  http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh and http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml for plain locale stuff
<ogra_> (or install freecad and take a look at thw wraper in /snap/freecad/current/ )
<mup> PR snapd#1484 closed: tests, integration-tests: port unity test to spread <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1484>
<mhall119> sergiusens: are your pkg-config changes in snapcraft 2.12?
<mup> PR snapcraft#631 closed: Fix the store integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/631>
<mup> PR snapd#1498 opened: tests, integration-tests: port systemd service check test to spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1498>
<sergiusens> mhall119 no, 2.12 was released before I fixed it
<josepht> didrocks: which part?
<kyrofa> sergiusens, elopio is jenkins having problems today? I can't reach results, and now they don't seem to be triggering
<sergiusens> kyrofa we might need to telegram elopio
<kyrofa> sergiusens, you're seeing that too then, eh?
<mhall119> sergiusens: how can I try your patch in a cleanbuild then?
<sergiusens> kyrofa not really
<kyrofa> sergiusens, ah, I triggered them manually... we'll see what happens
<kyrofa> Whoa, and failed
<kyrofa> Immediately
<sergiusens> kyrofa I've been working on all this red https://github.com/snapcore/snapcraft/compare/master...sergiusens:refactor/push
<kyrofa> sergiusens, looooovely!
<kyrofa> I love that kind of red
<sergiusens> kyrofa and it is now sort of readable too ;-) less spaghettiesh
<kyrofa> Yeah, very nice
<josepht> sergiusens: nice!
<didrocks> josepht: desktop/*
<josepht> didrocks: they look the same to me on the wiki[1] and in the parsed output[2]   [1] https://wiki.ubuntu.com/snapcraft/parts [2] https://parts.snapcraft.io/v1/parts.yaml
<josepht> didrocks: did you do a 'snapcraft update' to the get the latest parsed output locally?
<didrocks> josepht: oh, I thought that was fetched from the description in the git repo
<didrocks> ok, it's copied there as well
<didrocks> josepht: any chance to have a different one per "parts" from the same namespace?
<didrocks> (like desktop/qt5 have a different description from desktop/gtk3)
<josepht> didrocks: it might be possible if we allow a 'description' field for a part in snapcraft.yaml.  Can you file a bug please and we'll see if we can add that?
<josepht> didrocks: for the time being you could have the general description include a list of specific descriptions (it would be a lot of description for each part)
<didrocks> josepht: yeah, that's what I did with the new one :)
<didrocks> I'll file a bug
<josepht> didrocks: thank you
<didrocks> yw, thanks to you :)
<josepht> yw as well :)
<sergiusens> kyrofa maybe fgimenez can help out
<sergiusens> kyrofa I see on that "other" channel that elopio redeployed da jenks
<kyrofa> fgimenez, snapcraft's jenkins is super broken (not sure about snapd's)
<kyrofa> fgimenez, e.g. http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1094/
<fgimenez> kyrofa, sergiusens yep, the redeploy has just finished, all should be working now
<fgimenez> kyrofa, let me check...
<kyrofa> fgimenez, ah, okay I just retriggered them, see if things are working
<kyrofa> Nope, immediate failures
<kyrofa> fgimenez, the one just ran: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1095/
<fgimenez> kyrofa, it seems to complain about the available images, let me see what is it looking for...
<kyrofa> fgimenez, alright, thanks for checking it out :)
<fgimenez> kyrofa, np :) i'll let you know how it goes
<sergiusens> kyrofa my refactor only has 6 unit test errors!
<sergiusens> kyrofa and only because it wants to mock stuff that I made dissappear :-)
<kyrofa> sergiusens, nice!
<fgimenez> kyrofa, this one seems to be fine http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1098/console, there was a problem with a variable expansion
<kyrofa> fgimenez, yeah that one looks like it's running okay. Still seeing image errors here: http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1191/console
<kyrofa> fgimenez, yeah, autopkgtests seem to be running now
<kyrofa> fgimenez, just example tests now
<fgimenez> kyrofa, ok on it
<fgimenez> kyrofa, examples was pointing to the wrong region, should be fixed now http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1192/console
<ogra_> hmm
<ogra_> do we have any snapcraft.yaml example for SW that uses sourceforge ?
<ogra_> especially for downloading the source
<fgimenez> kyrofa, this PR will make the fixes permanent https://github.com/ubuntu-core/snappy-jenkins/pull/186, when landed these errors won't raise again in the next redeploys
<mup> PR ubuntu-core/snappy-jenkins#186: fixed regions and variable expansion <Created by fgimenez> <https://github.com/ubuntu-core/snappy-jenkins/pull/186>
<fgimenez> let me know if anything else is missing
<kyrofa> fgimenez, thank you! Looks great :)
<fgimenez> kyrofa, yw :)
<sergiusens> kyrofa before I move on, I would really like an initial review on https://github.com/snapcore/snapcraft/pull/632
<mup> PR snapcraft#632: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
<mup> PR snapcraft#632 opened: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
<kyrofa> sergiusens, alrighty
<kyrofa> sergiusens, yeah the direction looks good. Missing some good error handling, but I assume that stuff is coming
<sergiusens> kyrofa except KeyError?
<sergiusens> kyrofa yeah, that is missing ;-)
<kyrofa> Yeah, that :P
<sergiusens> kyrofa going to go the exception route and create a StoreReviewError or something like that
<sergiusens> getting rid of so many if/else on keywords really made me happy
<kyrofa> Yeah I bet
<sergiusens> kyrofa so happy I lost track of time last night and went to bed really late :-P
<sergiusens> S4ruman
<niemeyer> ogra_: Regarding "afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier"
<niemeyer> ogra_: I actually have it pretty much ready
<niemeyer> ogra_: It's not inside snapd though, but a library on its own
<niemeyer> ogra_: Worked on that over the weekend while fighting an app
<mup> PR snapd#1482 closed: store, many: start using the new details endpoint <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1482>
<mup> PR snapd#1488 closed: store: switch search to new snap-specific endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1488>
<ogra_> niemeyer, cool
<ogra_> thanks for cllearifyin
<ogra_> g
<mup> PR snapd#1499 opened: tests: use systemd-run for starting and stopping the unity app <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1499>
 * kyrofa bashes head on desk and goes to make more coffee
<ogra_> nessita, help ... i'm trying to upload a new nethack snap ... the old one was for 15.04 and it seems the store thinks the old one is a click ... when i upload a new revision i'm told click and snap can't be mixed ... trying to register a new package tells me the name is taken
<ogra_> and unpublishing doesnt clean that up
<nessita> ogra_, let me check!
<nessita> ogra_, I see 3 nethacks: nethack-amd64 nethack-armhf and nethack -- is the last one?
<ogra_> (and renaming obviously only renames the representation in the store, not the packagename)
<ogra_> yeah
<nessita> looks like is busted somehow, let me check
<ogra_> i dont mind if you remove it completely
<ogra_> in case thats needed
<nessita> ogra_, I may do that, but let me fully check
<nessita> ogra_, let me delete the package and you can register the name right after
<ogra_> nessita, btw, ircproxy, upnp-server and packageproxy will have the same issue (and i plan fesh uploads for them)
<kyrofa> elopio, this is successful, right? http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console
<kyrofa> elopio, looks like it just didn't clean up right?
<ogra_> so it might make sense to remove them too
<nessita> ogra_, nethack deleted, feel free to re-register
<ogra_> great
<kyrofa> sergiusens, short of the (incorrectly failing) tests, does #622 look good?
<nessita> ogra_, let me check details for ircproxy, upnp-server and packageproxy
<ogra_> they can all go as well
<ogra_> nope ... "new snap" still tells me the namespace is taken
<ogra_> ah, because i wown it already :P
<ogra_> direct upload works
<sergiusens> kyrofa what test is failing? care to record that in a comment with the traceback?
<kyrofa> sergiusens, I'm actually not sure what's happening on autopkg
<kyrofa> sergiusens, http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console
<kyrofa> It looks like a testbed issue, but I'm not certain
<sergiusens> kyrofa good thing I told elopio to keep an eye on jenkins :-P
<tsimonq2> key kyrofa, Jenkins passes in snapcraft#619 - what's next? I think I need a unit test, how would I go about doing that? (I mean, in the Zip and Tar sources or in a separate class?)
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> oh great, my FAVORITE spam bot just commented on my PR twice again.... :P
<tsimonq2> (jk)
<mup> PR snapd#1498 closed: tests, integration-tests: port systemd service check test to spread <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1498>
<mup> PR snapd#1499 closed: tests: use systemd-run for starting and stopping the unity app <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1499>
<mup> PR snapcraft#633 opened: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>
<jdstrand> zyga_: hey, so, snap-confine has a 1.0.34 tag but the debian/changelog still says UNRELEASED for 1.0.34
<kyrofa> sergiusens, any idea what's happening here? https://travis-ci.org/snapcore/snapcraft/jobs/142820726
<kyrofa> Not the most descriptive failure I've seen
<ssweeny> jdstrand, I'm trying to snap a python app (checkbox/plainbox if that's important) and I keep getting errors where python is trying to run /sbin/ldconfig. I think it's some internal python thing that's doing it. Any advice on how to proceed?
<sergiusens> kyrofa I asked josepht to look at it, the wiki is probably broken and our tests rely on it
<kyrofa> sergiusens, ah
<sergiusens> kyrofa I think work is already in progress to move to fake servers
<kyrofa> Good deal
<josepht> sergiusens, kyrofa: yes, the desktop entry is broken
<kyrofa> I love it-- an errant wiki entry takes down our CI
<sergiusens> josepht do you know how to fix it?
<josepht> sergiusens: yeah, I think so
<jdstrand> ssweeny: for now install in devmode. you can also file a bug stracing the process and seeing what it is doing. You can add '/sbin/ldconfig ixr,' to /var/lib/snapd/apparmor/profiles/snap.your.snap then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.snap' and see if that work for you (please mention that in the bug)
<jdstrand> ssweeny: when filing a bug, please add the 'snapd-interface' tag
<ssweeny> jdstrand, will try, thanks! (it works perfectly in dev mode and I'm working through confinement issues)
<ssweeny> jdstrand, also it's trying to write to $HOME/snap/${SNAP}/${REV}/.cache and it's being denied. Are hidden files in the user writable area blocked by default?
<ssweeny> i think that's what's being resolved for $XDG_CACHE_DIR
<ssweeny> or $XDG_CACHE_HOME rather
<josepht> sergiusens: the parser seems to be getting a stale/cached version of the wiki
<kyrofa> jdstrand, you remember that overlayfs script you had a while back? Just for ease of use I decided to throw it in a snap, but it seems the private mount space won't let me actually use it, even in devmode
<kyrofa> jdstrand, is there any way around that?
<jdstrand> ssweeny: hmm,  $HOME/snap/${SNAP}/${REV}/.cache should be allowed. can you paste the denial?
<kyrofa> jdstrand, oh nevermind... it's denying access to mount, haha
<kyrofa> Wait no... that's allowed
<kyrofa> I stand by the mount space theory
<ssweeny> jdstrand, it turns out I installed the snap as root and it created the rev directory with root ownership
<ssweeny> even under /home/ubuntu/snap/...
<jdstrand> kyrofa: I can't so for sure why it would not work, but the plethora of bind mounts that we have, it wouldn't surprise me. it might need a different invocation from within a snap (haven't tried)
<jdstrand> ssweeny: yes that is an annoying bug
<jdstrand> installing as root shouldn't be the issue. running as root before running as yourself would
<jdstrand> or running another program (eg, snappy-debug) as root on a system that doesn't have ~/snap already will do it
<jdstrand> (since ~/snap is root owned then)
<ssweeny> interesting
<ssweeny> I think I did run as root first
<niemeyer> jdstrand: Would you mind to have a quick look on snapd#1405 when you have a moment?  Should be an easy walk
<mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Blocked> <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
<slo_> Hi, is there any HW matrix support available for Snappy? So which CPUs are supported or which HW platforms (rpi, artik, etc...) ?
<kyrofa> jdstrand, indeed, if you install hello-world in --devmode and bindmount $HOME/foo to $HOME/bar in hello-world.sh, only hello-world.sh can see is. If you open another session it's not mounted at all
<kyrofa> s/see is/see it/
<jdstrand> niemeyer: I'll add it to my list (though note I'm working on a semi-urgent issue and may not get to it today, but should be able to tomorrow if not today)
<jdstrand> zyga_, tyhicks: fyi, https://github.com/snapcore/snap-confine/pull/72. I think this should be part of the /ubuntu-core-launcher/snap-confine SRU that is being worked on
<mup> PR snap-confine#72: use execle() with empty environment when calling snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/72>
<kyrofa> jdstrand, I figure it's the slave mount namespace
<kyrofa> jdstrand, is there any nifty mount instantiations that will allow me to hop out of that in devmode?
<jdstrand> kyrofa: that wouldn't surprise me. that said, you can deliver it as snap and execute it from /snap/name/current/script (yucky, but... ;)
<kyrofa> jdstrand, haha, that's exactly what I'm doing but... yuck :P
<jdstrand> kyrofa: otoh, idk. atm I'm working on said semi-urgent issue and don't have time to look right now
<kyrofa> jdstrand, that's alright, no problem
<niemeyer> jdstrand: Thanks!
<jdstrand> niemeyer: sure thing
<zyga> jdstrand: ack, looking now
<zyga> jdstrand: ack, I'll merge this soon but please add a spread test
<jdstrand> yikes
<zyga> jdstrand: ?
<jdstrand> I'll have to think about that. this is a pretty convulated attack
<jdstrand> convoluted
<zyga> jdstrand: after this lands I'll release .35
<niemeyer> joc_: That PR is yours isn't it?
<zyga> jdstrand: is there something we could do to just show that PATH is reset?
<zyga> jdstrand: what is NULL environment in practice? empty
<jdstrand> zyga: yes, empty
<zyga> jdstrand: or inherited from some safe default
<zyga> hmmm
<zyga> so PATH won't resolve at all, is that what we want?
<niemeyer> joc_: snapd#1405 that is
<mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Blocked> <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
<jdstrand> zyga: the problem is that only snappy-app-dev will see that environment
<zyga> jdstrand: that's right, so as long as it can cope, it is okay
<zyga> right?
<jdstrand> zyga: will spread allow me to replace /lib/udev/snappy-app-dev? I guess not since it is in read only part?
<zyga> it will
<zyga> you build the package, install it and run anything as root
<zyga> (as long as you clean up in restore you are good)
<jdstrand> ok, then I can come up with a test
<jdstrand> zyga: we want an empty environment, coping in a shell script is difficult. the next thing I'm going to do is to rewrite the shell script, but that doesn't need to be part of 1.0.35
<jdstrand> zyga: let me add a comment like tyhicks suggested and then work on spread. it will take me a bit-- this is my first spread test and I haven't set up the spread env yet
<jdstrand> I may have some questions
<zyga> ok
<zyga> jdstrand: I'll be here
<zyga> jdstrand: hint: spread -list
<zyga> jdstrand: then spread $idofthetest
<zyga> jdstrand: that will get you started faster
<jdstrand> zyga: oh, by cope maybe you meant if snappy-app-dev can handled not having PATH set, for example. yes-- anything the shell needs, if it isn't there, the shell will provide (PATH, HOME, PWD, etc), but passing a NULL environment means the user can't control those things
<kyrofa> nessita, why do automated review warnings result in a manual review being required?
<kyrofa> nessita, like this one: "Could not find compiled binaries for architecture 'arm64' lint-snap-v2_architecture_specified_needed (arm64)" at worst it's simply a mistake, at best (like my case) on purpose
<jdstrand> that is an ongoing conversation
<jdstrand> bottom line is, each check needs to be re-reviewed for what should block and what shouldn't
<jdstrand> and we need to think about how to present to the user and the uploader
<jdstrand> we probably need to do that, have errors block and warnings display but not block
<jdstrand> feel free to file a bug against the review tools
<jdstrand> kyrofa (cc nessita): ^
<kyrofa> jdstrand, alright, thank you
<kyrofa> jdstrand, any chance you could approve that snap?
<jdstrand> kyrofa: done
 * jdstrand leaves sergiusens' nil-snap alone
<sergiusens> jdstrand please do :-)
<kyrofa> jdstrand, thank you!
<nessita> jdstrand, thanks for answering
<nessita> kyrofa, we want good packages in the store, so why would your package not have a binary? (besides what jamie said)
<kyrofa> nessita, because snappy doesn't support it being a binary
<kyrofa> nessita, so one must run the script straight out of the snap
<kyrofa> nessita, but the snap is still a useful deployment mechanism
<kyrofa>  /sharing mechanism
<kyrofa> jdstrand, ah, an armhf arrived late if you could push the button on that one as well
<jdstrand> done
<kyrofa> Thank you!
<kgunn> ogra_: yo, for stitching a core 16 edge image....should i still be using the u-d-f on mvo's file share?
<kgunn> he has one there listed "experimental"
<kgunn> i think i'm on cirica may 2nd
<zyga> re
<zyga> jdstrand: about the exec bug, I'll do something with suse but then release .35 with tests or without tests before I EOD
<jdstrand> zyga: I've almost got a test verifying cgroups work correctly. then the next test for regressing execle should be fast
<zyga> jdstrand: fantastic!
<zyga> jdstrand: I'll work on running spread tests on sid this week
<jdstrand> zyga (cc niemeyer): gotta say, spread was really easy to get started with
<zyga> jdstrand: and suse/fedora/arch - depending on what is the easiest one
<zyga> jdstrand: not sure if you already know about it, -reuse and -keep accelerate iteratio cycle
<zyga> you just re-run on the same host all the time, no allocation required
<jdstrand> oh yes
<jdstrand> using -reuse a lot
<jdstrand> zyga: ok, added preliminary cgroup test
<jdstrand> zyga: so, debian/changelog still has 1.0.34 UNRELEASED
<jdstrand> zyga: can you fix that up? I can then add an entry for this
<sawdog> Hi folks, I was redirected here via the Ubuntu channel; Iâm asking:  so Iâm running on a Gigabyte IOT gateway box, have Core installed on a USB stick and am trying to get it installed on the internal MMC. I installed curl via snappy so I can grab the image and download it so that I can dd the image to the internal MMC; but using curl to redirect the output to a file, I get a permission denied. Iâm assuming this is because curl
<sawdog> doesnât have the appropriate access granted to write to my disk?
<zyga> jdstrand: hmm, that's complicated, this is release to debian with separate packaging now
<zyga> jdstrand: (non-native)
<sawdog> I did do a snappy hw-assign curl.tetor /dev/sda5
<zyga> jdstrand: the packaging here is just used for spread testing
<sawdog> which granted access to the device, but same behavior; â> 0Warning: Failed to create the file ubuntu-core-15.04-intel-nuc.img.xz: Warning: Permission denied curl: (23) Failed writing body (0 != 9922)
<zyga> jdstrand: add the changelog entry anywhere you want, it is not essential
<zyga> (for packaging)
<jdstrand> zyga: ok, then I'll let you handle the debian/changelog entry?
<zyga> jdstrand: yep
<jdstrand> zyga: I tell you waht, I'll add it here so you know what to add later
<zyga> ok
<zyga> jdstrand: I will do the rest and coordinate releases
<sawdog> Iâm assuming that the curl app doesnât have proper accessâ¦
<zyga> sawdog: I'm not sure what you are doing is what you really want
<zyga> sawdog: snappy has a few bits that need to understand boot and this will likely break
<zyga> sawdog: I'd recommend asking on the mailing list, it will probably require a longer and more comprehensive answer
<sawdog> zyga: Ah, it seemed like from the docs I could download an .img.xz - xzcat that pipped to dd and write it to the internal MMC
<sawdog> e.g this is from the docs online:
<sawdog> Decompress the image and write to the disk downloaded:
<sawdog> Using the NUC eMMC board:
<sawdog> xzcat ubuntu-core-15.04-intel-nuc.img.xz | sudo dd of=/dev/mmcblk0 bs=32M; sync
<zyga> sawdog: it depends on finer details
<sawdog> but I need to download the compressed image - which is where Iâm at; writing it to my usb drive (e.g. /dev/sda5)
<zyga> sawdog: anyway, I need to work on something, I', sorry but I cannot help you now
<sawdog> looks like Iâm facing an AppArmor violation with curl
<thomi> Hi all, while building a snap with more than one python-based part, I'm getting this error when trying to build the snap: https://pastebin.canonical.com/160364/ Does anyone know how to fix this?
<zyga> thomi: using a public pastebin would be easier for others to read
<thomi> zyga: good point
<thomi> zyga: http://pastebin.ubuntu.com/18656156/
<zyga> jdstrand: ready?
<zyga> thomi: just add all the python bits to one shared part
<zyga> thomi: that's what I did before
<zyga> thomi: I mean all the stage-packages
<jdstrand> zyga: I pushed a couple more commits. almost have a regression test
<thomi> zyga: unfortunately that's not do-able here. One of the parts isn't using the python build plugin, as it's a custom build system
<thomi> zyga: also, I'll want to share one of the parts for others to re-use
<zyga> jdstrand: k, I'll wait
 * zyga packages $Nth go package for suse
<zyga> thomi: that's okay, my point is that you can move *all* stage-packages to a dedicated part
<zyga> thomi: then use after to build when those are ready
<zyga> thomi: as for sharing, not sure, just a snapcraft design or bug
<thomi> zyga: I don't understand, sorry - my WIP snapcraft.yaml is http://paste.ubuntu.com/18656658/ - what are you suggesting?
<zyga> thomi: I don't know what wxpython plugin is doing
<zyga> thomi: ask sergiusens perhaps, sorry
<thomi> ok, thanks
<thomi> sergiusens: any ideas on how to resolve http://paste.ubuntu.com/18656658/ ?
<thomi> zyga: hey - do you have any objection if I take your excellent pmr tool and turn it into a proper lp project and work on it? We're using it in onlineservices, and want to make a few modifications
<zyga> thomi: woot, not at all
<zyga> thomi: I'm very glad someone found it interesting! :)
<thomi> zyga: awesome, thanks
<zyga> thomi: I guess it spread through roadmr :D
<zyga> thomi: I may send some pull requests your way :)
<roadmr> zyga: yes, I am the virus :)
<zyga> haha, that's fantastic roadmr :)
<zyga> how are you doing? :)
<zyga> it'd be really cool if pmr was a snap
<roadmr> great! how about you? having snap-fun?
<zyga> so it can use confinement to protect user data from malicious pull requests
<zyga> and would be available everywhere
<roadmr> ahh, great :) though that may interfere with e.g. test scripts that use fancy stuff, lxc and so on, right?
<zyga> roadmr: yes, though all will work in good time :)
<roadmr> awesome \o/
<zyga> I'm deep in various distributions, not running ubuntu much anymore :)
<zyga> I'm in suse world now :)
<roadmr> haha :)
<roadmr> cross-distro snap support is awesome, thanks for that \o/
<slo_> anyone runs eclipse kura on snappy?
<mup> PR snapd#1500 opened: many: remove snapstate.Candidate <Created by mvo5> <https://github.com/snapcore/snapd/pull/1500>
<zyga> slangasek: hey, can you please release snap-confine to debian
<zyga> slangasek: if you are around, I just published the upstream tarabll
<zyga> slangasek: I sent a patch to mwhudson, not sure if it got applied yet (I didn't check)
<mwhudson> zyga: i've done both of those things
<zyga> mwhudson: oh, fantastic
<zyga> mwhudson: can you do 1.0.35-1 please?
<mwhudson> haha
<mwhudson> you guys don't stop do you
<zyga> mwhudson: btw, glad to see you around :) how have you been?
<zyga> mwhudson: if you add me to comitters/uploaders I can co-maintain the package
<zyga> mwhudson: we don't stop to fix security issues :)
 * zyga goes to push gentoo and fedora bis
<mwhudson> zyga: oh are you a DM?
<mwhudson> i've been OK, had my head in go toolchain land for most of the last year
<zyga> mwhudson: no :-(
<zyga> mwhudson: well, not sure actually, but I haven't been updating my debian packages lately
<slangasek> zyga: you don't appear to be a DM, and I imagine you would know if you were :)
<zyga> slangasek: yeah, I got lost in the paperwork
<zyga> slangasek: I think I should apply, it's super annoying sometimes
<mwhudson> yeah, it's not overly hard
<mwhudson> if you have a key signed by a DD anyway
<mwhudson> the waiting is the hardest part
<zyga> mwhudson: hmm, I don't know if I do, I had that many years ago but I lost that key with a laptop hdd years ago
<mwhudson> zyga: so, step 1) ;-)
<mwhudson> zyga: for reference https://wiki.debian.org/DebianMaintainer
 * mwhudson hits gbp with a stick
<zyga> mwhudson: hehe, I might just do it now :)
<mwhudson> slangasek: can you just say pristine-tar = True in gbp.conf?
<slangasek> mwhudson: should be possible, yes
<mwhudson> zyga: you should fix that VENDOR_ARGS=--disable-confinement thing in master :-)
 * zyga checks if hrw is a DD
<zyga> mwhudson: in upstream master?
<mwhudson> yeah
<zyga> mwhudson: yes, I plan to change that entirely
<zyga> mwhudson: by dropping packaging upstream
<mwhudson> ah ha, yes that would solve that problem
<zyga> mwhudson: and adjusting spread tests to fetch debian packaging, generate a new tarball, building *that* package and then merry-carrying-on
<zyga> mwhudson: just bigger than what I wanted to tackle now
<mwhudson> fair enough
<zyga> (I'm discovering suse packaging the hard/practical way)
<mwhudson> ah nope, screwed up gbp again :-)
<mwhudson> differently this time
<zyga> packaging tools are so diverse and different
<mwhudson> once more around ...
<zyga> sigh, not signed :/
<zyga> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2894E93A28C67B47
<zyga> ok, time to call it a day
<zyga> just fedora bump and time to sleep
<mwhudson> zyga: 1.0.35-1 will be in debian soon
<mwhudson> zyga: are there release notes i can crib for debian/changelog?
<mwhudson> or i can just say "New upstream release" and leave it at that
<zyga> mwhudson: there are, let me show you
<zyga> https://github.com/snapcore/snap-confine/blob/master/debian/changelog#L13
<zyga> mwhudson: btw, how did you end up packaging snap-confine? :-)
<mwhudson> zyga: um well i ended up on the foundations team and helping with snapd packaging made sense cause it's in go
<mwhudson> and then snap-confine is related to snapd?
<mwhudson> :)
<zyga> btw, do you think golang shared libraries will hit yakkety?
<mwhudson> they have!
<zyga> and if so, how does that work in practice
<zyga> ohh!
<zyga> is that used in any other distro?
<mwhudson> not sure, fedora might have something?
<mwhudson> it's still very much in its infancy, i got about halfway to getting lxd to use them and then hit a grotty upstream circular dependency problem
<zyga> how can I check that shared libraries are in use?
<mwhudson> zyga: https://docs.google.com/document/d/1IOlBWWgcDeB9PfRORENESYj8iJt4W2EwsbYcpg4akBE/edit#heading=h.j590j9v4qbxg
<zyga> ldd will say something?
<mwhudson> yeah
<zyga> added to my reading list, I bet this will end up all over all the distros soon
<zyga> I need to spend some time tomorrow to build my VM host :/
<zyga> so many distros
<mwhudson> heh
<mwhudson> ok, uploaded to debian
<mwhudson> oh and i'm patch pilot today
<zyga> mwhudson: good night, talk to you soon I bet ;)
<zyga> :-)
<mwhudson> very probably
<mwhudson> good night
<mhall119> sergiusens: did you ever try to build pantheon-mail snap with your changes? If so, how far did you get?
<mcphail> If my snapcraft.yaml has 2 parts containing the same build-packages, can I safely remove the duplicates?
<mup> PR snapd#1439 closed: daemon, overlord: add buy endpoint to REST API <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1439>
<jdstrand> zyga: hrmm
<jdstrand> zyga: the apparmor profile for snap-confine is wrong. you moved the binary to /usr/lib/snapd/snap-confine but /etc/apparmor.d/usr.bin.snap-confine doesn't reflect that
<zyga> jdstrand: running spread tests with the change locally
<zyga> jdstrand: let's see what fails in practice
<thomi> Can anyone point me at some docs that explain how snapcraft decides what should get copied from 'stage/' to 'prime/' ? I have files in 'stage' that aren't getting copied into the snap, and they're required for the snap to run correctly
<thomi> ev: any idea on the above? ^^
<ev> thomi: have you tried including these missing files in a "snap:â stanza?
<ev> thomi: if you havenât seen it yet, https://github.com/ubuntu/snappy-playpen/wiki/Examples is handy
<thomi> ev: I haven't - I assumed there'd be something like that, but was looking for docs https://github.com/ubuntu/snappy-playpen/wiki/Examples looks perfect, thanks
<thomi> ev: is there a way we can link to that from snapcraft.io/create?
<thomi> actually, it looks like I want something in organize: awesome
<thomi> so many things I didn't know existed :D
<mup> PR snapcraft#634 opened: Run the parser integration tests with debug flag <Created by elopio> <https://github.com/snapcore/snapcraft/pull/634>
#snappy 2016-07-07
<mhall119> kyrofa: sergiusens: is there anything that sets $TMPDIR when a snap is run?
<kyrofa> mhall119, yeah, each app gets its own
<mhall119> kyrofa: what might such a value look like?
<mhall119> I ask because in pantheon-mail sqlite is trying to create temp files in /var/tmp/ and failing
<kyrofa> mhall119, /tmp/snap.foo_bar_baz
<kyrofa> mhall119, but it shows up to the snap as /tmp
<kyrofa> mhall119, now that you mention it, I'm not sure anything is explicitly setting the TMPDIR var
<kyrofa> We just make /tmp work correctly
<kyrofa> So if sqlite defaults to /var/tmp is TMPDIR isn't set, that may be it
<mhall119> it does
<mhall119> according to https://www.sqlite.org/tempfiles.html#tempstore
<mhall119> can I do something like: TMPDIR=/tmp /snap/bin/pantheon-mail
<mhall119> or will the envvars be stripped out when the snap is run?
<kyrofa> mhall119, you can do that, but it'll need to be in a wrapper somewhere
<kyrofa> mhall119, soon that'll get easier, you'll be able to specify environments in the yaml, but not just yet
<mhall119> do you think it's worth putting in common gtk/qt desktop launcher parts?
<kyrofa> (sorry for the delay, packing up my office for a cross-country move)
<kyrofa> mhall119, if this problem is encountered enough, sure
<mhall119> presumably it will be encountered anywhere sqlite3 is used
<kyrofa> Indeed
<kyrofa> I just wonder if it'll cause problems for others
<kyrofa> e.g. /var/tmp is different than /tmp, it's not cleared each boot
<kyrofa> So some users might want TMPDIR to be, say, in $SNAP_DATA/tp
<kyrofa> $SNAP_DATA/tmp rather
<mhall119> how about setting SQLITE_TMPDIR? I don't think sqlite expects them to persist  between boots
<kyrofa> SQLITE_TMPDIR seems a little specific to go in a generic part, but that's just me
<kyrofa> Such an approach won't scale
<mhall119> well, you said there was an easier method on the way :)
<kyrofa> Indeed
<kyrofa> In the next snapd release, actually
<kyrofa> Just waiting for it to get through SRU
<kyrofa> Though snapcraft needs to support it too... not sure if sergiusens has done that yet or not
<kyrofa> But to get up and running, a simple wrapper script is pretty easy
<mhall119> yup, and I've just verified that it fixes all my apparmor warnings
<kyrofa> Very good
<mhall119> it isn't copying my sqlite database forward for new install revisions of the snap though :(
<kyrofa> mhall119, and the DB is in $SNAP_DATA?
<mhall119> it's /home/mhall/snap/pantheon-mail/x2/.local/share/pantheon-mail/
<kyrofa> Ah interesting! A hidden dir
<mhall119> does /home/mhall/snap/pantheon-mail/x2/ map to an envvar?
<kyrofa> Out of curiosity, can you force it to _not_ be hidden?
<mhall119> because it looks like something might be trying for $HOME/.local/share/
<kyrofa> Indeed, that's $SNAP_USER_DATA, but snapd also sets $HOME to that
<kyrofa> You got it
<mhall119> and $SNAP_USER_DATA isn't copied? Or it this not being copied because it's a dotfile?
<kyrofa> It is copied. The fact that the DB isn't makes me wonder if it's the dotfile, which would be a bug I'd say
<kyrofa> Can you verify? Even if you just renamed the dir and installed a new rev
<mhall119> I'll give it a try and see, but might wait until tomorrow
<kyrofa> Yeah it's a bit late for you
<dholbach> hiya
<didrocks> hey dholbach
<dholbach> salut didrocks
<dholbach> does anyone know what to respond to http://askubuntu.com/questions/795139/ntp-synchronisation-in-ubuntu-core-10?
<zyga_> ara: o/
<ara> zyga_, hey!
<popey> morning all
<mup> PR snapd#1501 opened: client: existing JSON fixtures uses tabs for indentation <Created by stevenwilkin> <https://github.com/snapcore/snapd/pull/1501>
<mwhudson> has anyone looked at the snapd autopkgtest failures in yakkety?
<zyga_> mwhudson: hey
<zyga_> mwhudson: I did but didn't find anything, in fact I cannot reproduce them
<zyga_> mwhudson: I used a yakkety vm, got the package from proposed and ran kvm based autopkgtest
<zyga_> zyga: where is this damn session
<mwhudson> zyga_: hm, i tried the same and the failed just a few seconds ago in fact
<mwhudson> let's see if the failures looked similar
<zyga_> mwhudson: how did you run the test?
<mwhudson> adt-run --unbuilt-tree . --- qemu ~/adt-yakkety-amd64-cloud.img
<mwhudson> from a git tree checked out to the release tag
<zyga_> I ran something different
<zyga_> give me a sec
<mwhudson>  ~/adt-yakkety-amd64-cloud.img  is what adt-buildvm-ubuntu-cloud -r yakkety spat out
<mwhudson> (or whatever that command is called :-)
<zyga_> I haven't used adt in a while, just booting yakkety to paste the command I ran
<mwhudson> heh
<mwhudson> hmm i think i see fewer failures than on autopkgtest.u.c
<mwhudson> "yay"
<zyga> let me find my irc session
<zyga_> fg
<zyga> woot
<zyga> mwhudson: autopkgtest-buildvm-ubuntu-cloud -v -a amd64 -r yakket
<zyga> y
<mwhudson> oh well, that's not significantly different
<zyga> autopkgtest snapd_2.0.10+16.10.dsc  -- qemu
 * zyga tries again
<mwhudson> oh no, i did get the same errors
<mwhudson> as https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160707_052336@/log.gz
<mwhudson> i got less output spam though, whatever that means
<mwhudson> sigh failures in teardown
<mwhudson> always a good smell
<mwhudson> messages like "Unit snap-basic\x2dbinaries-x1.mount not found." make my have unicode paranoia
<mwhudson> bug 1571721
<mup> Bug #1571721: Removing when an app is running results in a half removal <verification-done> <Snappy:Fix Committed> <snapd (Ubuntu):Fix Committed> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1571721>
<zyga> trying again
<zyga> mwhudson: most interestingly, tests don't fail if you just run them
<zyga> mwhudson: I mean from the tree
<mwhudson> zyga: and they don't fail on xenial, right?
<zyga> mwhudson: yep
<zyga> mwhudson: one thing I didn't test, fully proposed update
<zyga> mwhudson: I only ran this with yakkety + snapd from proposed
<mwhudson> what's significantly different in yakkety? systemd, kernel i guess
<mwhudson> ahhh hm
<zyga> mwhudson: yep, just note that arch has the same version and it is all good there :/
<zyga> so ... hmm?
<mwhudson> i think this is the key failure:
<mwhudson> error: cannot perform the following tasks:
<mwhudson> - Mount snap "basic-service" ([start snap-basic\x2dservice-x1.mount] failed with exit status 1: Warning: snap-basic\x2dservice-x1.mount changed on disk. Run 'systemctl daemon-reload' to reload units.
<mwhudson> A dependency job for snap-basic\x2dservice-x1.mount failed. See 'journalctl -xe' for details.
<zyga> hmm
<mwhudson> i *think* all the rest is fallout from that
<mwhudson> but i hardly know what is going on :)
<zyga> what is the dependency job?
<zyga> the fact that systemd says the unit changed on disk is not new in 230
<zyga> perhaps the dependency will tell us more
<mwhudson> i should run it again in that mode that lets me ssh in afterwards
<zyga> how do you do that?
<mwhudson> --shell-fail
<zyga> I'll replicate here and see what we get
<zyga> thanks
<zyga> running zyga@yakkety:~$ autopkgtest --shell-fail snapd_2.0.10+16.10.dsc  --- qemu ~/autopkgtest-yakkety-amd64.img
<mwhudson> zyga: i'm not completely sure what's happening now but i have this feeling my run is going to pass
<zyga> do you know how regression tests are ran? is it with everything from proposed or just the one package?
<zyga> and if it is the former, how can we replicate that?
<mwhudson> i don't
<mwhudson> and by editing the sources.list in the image, i assume
<zyga> well, I can just upgrade to proposed and run tests locally
<mwhudson> bah it failed but the --shell-fail magic did too somehow
<zyga> my run is still in progress
<mwhudson> zyga: <pitti> mwhudson: it tries to limit -proposed packages to just the trigger and its dependencies
<mwhudson> <pitti> sometimes that doesn't work (stuff is uninstallable), then it falls back to enabling all of -proposed
<mwhudson> zyga: i pasted your question in #ubuntu-quality btw
<zyga> mwhudson: thanks!
<zyga> hmm
<zyga> well, we can try the full proposed one I guess
<zyga> my tests are still ongoing
<mup> PR snapd#1459 closed: daemon,overlord/auth,store: update macaroon authentication to use the new endpoints <Created by matiasb> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1459>
<mwhudson> zyga: apparently a known intermittent thing, i'm running again
<zyga> mwhudson: my run is still in progress, no failure yet
<zyga> mwhudson: I really wonder if there's a difference between how we run tests
<mwhudson> zyga: aaah the build failed this time!
<mwhudson> FAIL: policy_test.go:103: policySuite.TestIterOpBadTargetdir
<zyga> mwhudson: what's the rest of the error?
<zyga> mwhudson: and can you reproduce that with the .dsc?
<zyga> hmmmmm
<zyga> mwhudson: I see it run ./get-deps
<mwhudson> zyga: http://paste.ubuntu.com/18692046/
<zyga> mwhudson: I don't think that should ever be done in autopkgtests
<zyga> isn't the whole idea to run tests from packaged bits
<zyga> + ./get-deps.sh
<zyga> Obtaining dependencies
<zyga> reading...
<mwhudson> hmmm
<zyga> mwhudson: what is $HOME like?
<mwhudson> don't know
<zyga> so far it still hasn't failed for me
<mwhudson> probably just /home/ubuntu
<zyga> still not failed
<zyga> (my computer is slower :-)
<zyga> ah, it failed now!
<zyga> same way
<zyga> error: cannot perform the following tasks:
<zyga> - Mount snap "basic-binaries" ([start snap-basic\x2dbinaries-x1.mount] failed with exit status 5: Failed to start snap-basic\x2dbinaries-x1.mount: Unit snap-basic\x2dbinaries-x1.mount not found.
<zyga> )
<mwhudson> hooray
<mwhudson> i think
<mwhudson> ok package build worked this time
<zyga> hmm, the failshell instructions don't work for me
<zyga> ok
<zyga> let's try to fail this on native yakkety without adt so that tinkering is easier
<zyga> eh, we should really replace the one dependency that needs bzr
<zyga> pulling all of python2
<mwhudson> :)
<mwhudson> zyga: yeah i think the get-deps.sh invocation would  be better as cp -r /usr/share/gocode/src $tmp or something like that
<mwhudson> to use the packaged version of the dependencies
<zyga> yep
<mwhudson> grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
<zyga> ?
<mwhudson> the --shell-fail failed again
<mwhudson> i guess i should figure out how adt-virt-qemu runs the vm and do it by hand
<mwhudson> but maybe not today
<mup> PR snapd#1502 opened: Add an interface for tpm 1.2 <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502>
<dholbach> attente, do you know what to reply to http://askubuntu.com/questions/780670/i-cant-install-snap-packages-with-ubuntu-software-but-ok-with-terminal?
<netphreak> Do i need to set anything special in my snapcraft.yml, if my snap requires network access?
<qengho> netphreak: yes
<netphreak> anywhere i can see an example of that?
<qengho> $ snap interfaces   # list of plugs
<gouchi> netphreak: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<qengho> In the app definition, "plug: [ network ]"
<netphreak> thx
<qengho> Hrm, I have a snap installed. I "snap install ./develomentsnap". I want to remove the devel version and return to the previous. How can I do that?
<mup> PR snapcraft#635 opened: Fix parts cache handling <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/635>
<mup> PR snapd#1503 opened: Set the snap price when listing available snaps <Created by stevenwilkin> <https://github.com/snapcore/snapd/pull/1503>
<mup> PR snapd#1504 opened: debian: chmod created config files to 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/1504>
<mup> PR snapd#1505 opened: store: introduce a search grammar (baby step #1) <Created by chipaca> <https://github.com/snapcore/snapd/pull/1505>
<sergiusens> kyrofa hey, is this only failing due to ros and friends? https://github.com/snapcore/snapcraft/pull/633
<mup> PR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>
<mhall119> kyrofa: zyga: is there a solution to the "clicking a URL in a snap doesn't open it in the browser" bug?
<mup> PR snapd#1506 opened: store/auth: add helper for the macaroon refresh endpoint <Created by matiasb> <https://github.com/snapcore/snapd/pull/1506>
<sergiusens> mhall119 there's a bug and attente was working on that
<sergiusens> mhall119 I also raised the inverse, going from host to snap doesn't work as the mime handler doesn't seem to get registered. Hm, let me log a bug for that
<seb128> sergiusens, bug #1597417
<mup> Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1597417>
<mhall119> sergiusens: how can we re-use the url-dispatcher that does this on the phone?
<seb128> you can maybe confirm it
<mup> PR snapd#1507 opened: cmd: add buy command <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1507>
<seb128> mhall119, I don't think we need url dispatcher there, we have snapd-xdg-open in yakkety which is supposed to do that
<seb128> unsure if it works out of the box though
<seb128> that's also something that needs to be backported to xenial
<mup> PR snapcraft#635 closed: Fix parts cache handling <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/635>
<sergiusens> seb128 thanks
<mhall119> seb128: and that works based on the MimeType field in the .desktop files?
<mup> Bug #1597417 opened: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1597417>
<attente> seb128: besides backporting snapd-xdg-open, the fake xdg-open script needs to be inserted into the os snap
<seb128> mhall119, urls are special cases of mimetypes so I guess in some ways
<seb128> attente, that was done in yakkety?
<kyrofa> sergiusens, I just merged with master, so I'll let you know
<attente> seb128: i don't recall, i thought mvo took care of that part though
<seb128> k
<seb128> mvo, ^ do you know what's the status there? ;-)
<seb128> attente, thanks
<mvo> attente: its in the os snap already (maybe not yet in stable? definitely in edge)
<mvo> seb128: -^
<attente> mvo: ok, thanks. so i guess the only thing missing is backporting to x
<seb128> mvo, do we have an os snap installed on classic?
<kgunn> yo, just updated y'day and i'm seeing an error on snap list
<kgunn> known?
<didrocks> seb128: yeah, we do
<kgunn> error is "error: cannot list snaps: cannot unmarshal: json: cannot unmarshal string into Go value of type int"
<mvo> seb128: yes
<mvo> attente: people get it from the os snap, we don't need to backport it (unless I miss something)
<didrocks> mvo: I don't find it r122: /snap/ubuntu-core/current$ sudo find . -name 'xdg-open'
<attente> mvo: backporting snapd-xdg-open to xenial for the other half of that interaction
<mvo> attente: if its not in stable yet (can check in a bit) it will be soon, we will get a new stable in the next few days
<seb128> didrocks, mvo, how do I see what it's in my os snap? snap list only includes ubuntu-core
<didrocks> seb128: this is the os snap
<mvo> seb128: 122 is stable, right?
<attente> mvo: and also pulling it as a depends
<seb128> mvo, 122 of what?
<seb128> mvo, sorry i'm not familiar with your new world ;-) my knowledge goes as far as the snapd version installed my xenial and snap list/install and the ubuntu-core snaps
<mvo> seb128: I will double check, I think r122 of ubuntu-core is the stable version that has n been updated in a while
<kyrofa> sergiusens, nope, example tests are still busted
<seb128> mvo, ubuntu-core is the os snap?
<mvo> seb128: yes, correct
<seb128> or are they different things
<seb128> ah ok
<mvo> seb128: sorry for the confusion
<seb128> no worry
<mup> PR snapd#1508 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1508>
<attente> Chipaca: hey, for some reason, snapd still doesn't be returning an icon uri despite the snaps dpm uploaded being series 16
<dpm> Chipaca, https://launchpad.net/bugs/1588266
<mup> Bug #1588266: Almost no info about Krita snap in Ubuntu Software <amd64> <apport-bug> <xenial> <gnome-software (Ubuntu):Confirmed for attente> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1588266>
<mup> PR snapd#1504 closed: debian: chmod created config files to 0644 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/1504>
<sergiusens> kyrofa which ones?
<mup> PR snapd#1509 opened: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <https://github.com/snapcore/snapd/pull/1509>
<kyrofa> sergiusens, http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1216/console, image creation failure seems like
<kyrofa> fgimenez, any idea on that one? ^^
<fgimenez> kyrofa, looking
<kyrofa> sergiusens, I think my last successful run was a few days ago at this point :P
<gQuigs> hi there, I get an error message when I try running any snap:
<gQuigs> $ snap run vlc
<gQuigs> execv failed: No such file or directory
<fgimenez> kyrofa, seems like a quota problem, there are two danglling instances, i'll try to identify and delete them, will ping you when done
<kyrofa> Thanks fgimenez
<gQuigs> $ snap run hello
<gQuigs> 2016/07/07 09:59:44.531420 cmd_run.go:175: WARNING: cannot create user data directory: cannot create "/home/bryan/snap/hello/common": mkdir /home/bryan/snap/hello/common: permission denied
<gQuigs> execv failed: No such file or directory
<gQuigs> slightly better error with hello I guess..
<kyrofa> gQuigs, that's not typically how one runs apps
<kyrofa> gQuigs, run stuff out of /snap/bin
<kyrofa> (which should be in your PATH)
<gQuigs> kyrofa: hmm.. then it's not obvious how to run some...
<gQuigs> kyrofa: for example, run hello and it says not installed
<gQuigs> and what if I have both vlc snap and vlc deb installed?  how to pick?
<kyrofa> gQuigs, is hello installed?
<gQuigs> $ /snap/bin/hello
<gQuigs> Hello, world!
<gQuigs> $ hello
<gQuigs> The program 'hello' can be found in the following packages:
<kyrofa> gQuigs, is /snap/bin in your PATH?
<fgimenez> kyrofa, should be fixed now
<kyrofa> Thanks fgimenez, re-running now
<gQuigs> kyrofa: nope, it's not.. swear it was.. hmm
<kyrofa> gQuigs, hmm indeed
<gQuigs> with path set, hello works
<gQuigs> but snap run still doesn't.. should that work?
<netphreak> How can i see what version of snapcraft and snap i installed?
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Do you need any state currently in Spread-B?
<gQuigs> netphreak: does --version not work for you?
<niemeyer> jdstrand: We're having some connectivity issues between the freemont DC and Google services, so I'm moving it out to a different DC
<seb128> mvo, sergiusens, what would the way to get the attention of the snappy team on bug #1597417? it's probably an easy one but I don't know if it needs team discussion on possible security impact or something
<mup> Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1597417>
<seb128> it's important to make desktop applications useful
<seb128> like I've evince in a snap but it's not very useful if you can't get it to be used when clicking on a pdf in nautilus
<gQuigs> kyrofa: so for VLC the deb takes precedent (based on how I did path).  Should snap run work is that deprecated?
<kyrofa> gQuigs, snap run will be how snaps are run behind the scenes, but you should never have to run it. You should be running things out of /snap/bin
<kyrofa> gQuigs, it's an implementation detail
<kyrofa> gQuigs, and I'm not sure that it actually works in the version of snapd released currently-- it's finished in the one being released now
<kyrofa> gQuigs, so for a consistent experience, use /snap/bin/
<netphreak> How do i upgrade to the latest snapd 2.0.10? I'm on apt-get
<sergiusens> seb128 I have the same problem when clicking on telegram.me links ;-)
<mvo> seb128: what needs to happen? does snapd needs to just run update-desktop-database after new desktop files got created?
<gQuigs> kyrofa: so I should eventually work ?
<kyrofa> gQuigs, yes, but again, you should never need to use it directly
<jdstrand> niemeyer: no-- I can -discard now if that makes things easier for you
<niemeyer> jdstrand: Ah, yes please, thanks!
<seb128> mvo, yes
<jdstrand> niemeyer: but when can I start up a new one with -keep?
<niemeyer> jdstrand: Feel free to pick another one when you need
<niemeyer> jdstrand: Immediately
<gQuigs> kyrofa: thanks!
<niemeyer> jdstrand: Hopefully I'll be faster and nuke the machine before you grab it again :)
<niemeyer> jdstrand: There are other machines available on the new DC already
<jdstrand> niemeyer: discarded
<seb128> mvo, the mimetype handlers look into indexes and that dir doesn't have one so its entries are not registered
<seb128> mvo, just doing the update command makes it work
<niemeyer> jdstrand: Thanks, removed.. will re-allocate new ones with the same names on the new DC
<jdstrand> niemeyer: I'm not sure you saw, but between README.md and a really nice cli, spread is literally the easiest testing infrastructure I've ever used
<niemeyer> jdstrand: Wooo, that's great to hear! Thanks!
<jdstrand> really nice. I was writing spread tests in just a few minutes
<jdstrand> granted, I was using an existing project with spread.yaml, but still. good stuff :)
<attente> seb128: mvo: how should we backport snapd-xdg-open to xenial? should i reuse this sru? https://bugs.launchpad.net/snappy/+bug/1580740 or file a new one against the package?
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <Snappy:Triaged> <https://launchpad.net/bugs/1580740>
<jdstrand> niemeyer: oh and -debug is fantastic
<seb128> attente, that SRU bug should do the trick
<niemeyer> jdstrand: Yeah, I was very pleased with that one as well. So convenient to be able to jump in at the exact breakage
<jdstrand> totally
<attente> seb128: thanks!
<seb128> attente, yw!
<jdstrand> niemeyer: at some point I want to try it with lxd. oh, that reminds me-- I guess it is possible to have two different backends and then spread -list would just prefix them accordingly? what happens if say a project has linode and lxd, and you have lxd and I don't?
<attente> seb128: could you please sponsor it for xenial? or should i subscribe ubuntu-sponsors?
<jdstrand> niemeyer: fyi, I have Spread-E now
<niemeyer> jdstrand: Right.. it'll try to run all backends by default, but you can easily tell what to run at the CLI.. e.g. linode:
<niemeyer> jdstrand: Ack
<niemeyer> jdstrand: That is, $ spread <options> linode:
<niemeyer> jdstrand: Then it'll run only things in Linode
<jdstrand> niemeyer: if a project has both linode and lxd, but I don't have lxd, do that cause a usability issue for me or will spread just skip those?
<jdstrand> eg, if I just call 'spread'
<niemeyer> jdstrand: It'll try to run lxd, error out because it can't, mark the specific jobs that should run under lxd as aborted, but otherwise continue with all the rest
<jdstrand> I see. ok, thanks
<niemeyer> jdstrand: That's the main distinction between aborted and failed, btw.. aborted means "didn't even try"
<jdstrand> ah, yes. that makes sense
<jdstrand> I was trying to wrap my head around how useful it would be to add lxd backends to things and how that might affect people
<jdstrand> I'm not actively working on that-- just was curious
<mvo> seb128: thanks, that sounds pretty straightforward
<niemeyer> jdstrand: I have a background idea that I haven't quite designed yet, but which might fit with what you describe
<niemeyer> jdstrand: I'd like a way to mark certain tests as "manual"..
<niemeyer> jdstrand: IOW, should only fire when explicitly requested
<jdstrand> right
<niemeyer> jdstrand: Need to find a way to blend that into the default job matching behavior in a non-awkward way
<jdstrand> yeah, that would definitely work for this use case so long as it could be applied to backends as well as tests and suites
<jdstrand> which in saying that, I see what you mean be it needing some design :)
<niemeyer> jdstrand: Yeah, it'd need to work in a similar way to everything else.. cascading through the matrix
<jdstrand> cool
<niemeyer> Might be just a test in a suite, or a suite, or whole backend
<jdstrand> anyway, I'm not using lxd just yet here for that, but I was excited to see it as a backend
<niemeyer> I want to support kvm soon as well. There was some difficulties in finding the ip the machine fired with, but ogra_ gave some ideas.
<seb128> mvo, thanks
<mup> PR snapd#1431 closed: cmd,interfaces,snap: implement hook whitelist <Reviewed> <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1431>
<seb128> attente, sorry, day is a bit crazy and i'm off tomorrow ... please subscribe sponsors and maybe see if mvo wants to sponsor the SRU, I think he did the yakkety upload? otherwise I have a look on monday
<mup> PR snapd#1510 opened: integration-tests: remove login tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1510>
<mvo> attente, seb128: sure I can sponsor, just ping me
<seb128> mvo, great, thanks!
<zyga> jdstrand: I wrote a spread test for the apparmor profile
<zyga> jdstrand: just testing it and I'll add it to the pull request
<zyga> jdstrand: you said you want to have another thing in .36?
<zyga> jdstrand: can you be more specific please?
<jdstrand> zyga: I want only that in .36
<jdstrand> I mean, other things can be there, but we need to make sure we don't lose confinement for the next ubuntu upload
<zyga> jdstrand: .35 was released, .36 is today
<jdstrand> zyga: right. what I mean is that .35 is where I noticed the profile attachment bug you are working on. afaic, we need to only fix that bug for .36. then .36 can go to ubuntu
<attente> mvo: thanks! is there anything you need from me for the sru?
<zyga> ah, ok
<zyga> so there's nothing else you want to fix?
<zyga> what about the nodev thing that was also mentioned by SUSE folks?
<jdstrand> zyga: I do have something I was working on but it doesn't have to be for .36
<zyga> ok
<zyga> sounds good then
<jdstrand> zyga: for the nodev, that was actually a question for /tmp being user-owned, but that got me thinking snap-confine probably should think about nodev and nosuid for some of those mounts, but that is a hardening measure since the things being mounted are not user-controlled, correct? Does this have the content interface changes? If so, those mounts should absolutely by nodev and nosuid
<jdstrand> zyga: ok, phew, I see in sc_setup_mount_profiles that MS_NODEV and MS_NOSUID are used
<ogra_> hmm
<ogra_> sergiusens, wouldnt it make sense if the make plugin would install a compiler by default (and put the cc and gcc links in place automatically) ?
<zyga> yes, the user mounts are safe
<zyga> those that are controlled by the user
<zyga> but remember that all you need to do is to ship a snap with /dev/sda node
 * ogra_ notes that he has to put 	([ -e /usr/bin/cc ] || ln -s /usr/bin/gcc-5 /usr/bin/cc) and ([ -e /usr/bin/gcc ] || ln -s /usr/bin/gcc-5 /usr/bin/gcc) into his makefiles ... 
<zyga> and you're good :-(
<ogra_> and i have to put gcc-5 into build-files
<ogra_> err build-packages
<sergiusens> ogra_ not make, but autotools and cmake yes
<ogra_> why not make ?
<jdstrand> niemeyer: I have a potentially dumb question re environment and spread. I'm try to do:
<sergiusens> ogra_ there are a bunch of examples where people use make as they would use the copy plugin
<jdstrand> environment:
<jdstrand>     CORESNAP: $(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ')
<jdstrand> execute: |
<jdstrand>     ...
<ogra_> sergiusens, yeah, i have done that too ... but still, gcc is broken if you depend on it
<jdstrand>     echo "CORESNAP=$CORESNAP"
<jdstrand>     ...
<sergiusens> ogra_ as a build-packages?
<ogra_> sergiusens, the needed symlinks are alternatives ...
<ogra_> yeah
<jdstrand> niemeyer: but $CORESNAP is empty
<jdstrand> niemeyer: the is in task.yaml
<ogra_> sanpcraft doesnt run postinsts ... so the symlinks are missing
<sergiusens> ogra_ build-packages do run postinsts
<sergiusens> what are you talking about?
<ogra_> well, not here
<sergiusens> there are a bunch of tests for this
<jdstrand> niemeyer: if I do under execute: echo "CORESNAP=$(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ')" I see what I want
<sergiusens> ogra_ use build-packages, not stage-packages
<ogra_> i tried to make all my packages "cleanbuild" safe today
<ogra_> and all of them are missing these links
<jdstrand> niemeyer: I can sprinkle that command around and am not blocked, but it seems like environment should be able to handle this
<ogra_> sergiusens, https://github.com/ogra1/nethack/blob/master/snapcraft.yaml ...
<ogra_> sergiusens, same for https://github.com/ogra1/upnp-server/blob/master/snapcraft.yaml
<ogra_> (and a few others i havent public yet)
<sergiusens> ogra_ ah you are explicitly installing gcc-5, that won't create the gcc link you want
<ogra_> if i use gcc-5 in build-packages there are definitely no alternative links set
<ogra_> it does if i install gcc-5 on a normal desktop
<sergiusens> ogra_ because you have gcc installed as well
<ogra_> hmm, let me try to move to plain "gcc"
<ogra_> mvo, in case you do manual image builds. please note the new EXTRA_PPAS entry in crontab
<ogra_> ( i changed that yesterday ,,, forgot to tell you about it)
<ogra_> sergiusens, bah, and indeed you are right :P
 * ogra_ goes and fixes all branches again ... mental note: ask first next time before writing a workaround
<sergiusens> ogra_ iirc gcc has the alternative stuff and didrocks told me we install it by default on desktop now too
<ogra_> we always did
<ogra_> it is a requirement of dkms
<ogra_> (and before it was a req. for nvidia drivers and the like ... when they still got compiled at install time)
<ogra_> but tthat doesnt help with cleanbuild :)
<mup> PR snapcraft#622 closed: Hard-link local sources instead of symlinking them <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/622>
<kyrofa> Yay!
<mup> Bug #1599919 opened: SnapOpSuite unit tests interfere with the user's $HOME/.snap directory <Snappy:New> <https://launchpad.net/bugs/1599919>
<niemeyer> jdstrand: One particularity of environment is that $()  executions run locally rather than remotely.. I might move that behavior out into a separate field as it's probably unexpected
<niemeyer> jdstrand: Right now that's how we can provide secrets and local info in general to the tests
<jdstrand> I see
<jdstrand> ok, well, like I said, I'm not blocked
<jdstrand> thanks for the explanation
<niemeyer> np
<mup> PR snapcraft#636 opened: parser - Handle malformed wiki entries <Created by josepht> <https://github.com/snapcore/snapcraft/pull/636>
<mvo> ogra_: thanks for the heads up
<mup> PR snapd#1511 opened: overlord: actually run hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1511>
<mvo> attente: if you could prepare it so that I just need to dput the sru that would rock of course, if not just let me know
<attente> mvo: sure
<attente> mvo: i literally just changed the release to xenial and the date in the changelog: https://launchpad.net/~attente/+archive/ubuntu/snapd-xdg-open/+packages
<attente> (from the yakkety one)
<zyga> mvo, attente: can we please do an upstream release of snapd-xdg-open
<zyga> we really want it everywhere, not just ubuntu
<zyga> if you want I can look at this
<mup> PR snapd#1512 opened: overlord: initial work on renaming core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/1512>
<sergiusens> kyrofa this is good to go https://github.com/snapcore/snapcraft/pull/632
<mup> PR snapcraft#632: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
<attente> zyga: sure, but i don't have push access to that repo. i think mvo does however?
<kyrofa> sergiusens, looks like it needs to be merged with master
<sergiusens> kyrofa really, again?
<sergiusens> kyrofa there you go
<kyrofa> sergiusens, thank you! Also consider changing the title
<sergiusens> kyrofa so pushy, I was going to change it while merging :-P
<sergiusens> kyrofa there you go
<kyrofa> sergiusens, I know you. You'll forget, and then our history will be hilarious
<zyga> jdstrand: I've updated snap-confine#73
<mup> PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>
<zyga> jdstrand: I didn't rename policy file because I think this simply belongs in downstream packaging and it is more and more evident
<tsimonq2> what sort of unit test coverage should I seek for my PR? ( snapcraft#619 )
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> integrated in the Tar and Zip classes or in it's own class?
<tsimonq2> kyrofa: ^
<kyrofa> tsimonq2, taking a look now
<jdstrand> zyga: re rename> well, it depends-- where does make install put it? if the default is to /usr/lib/snapd/snap-confine then the name should reflect that
<tsimonq2> thanks kyrofa
<jdstrand> zyga: alternatively, skip all that and just rename to 'snap-confine'
<jdstrand> zyga: the only thing apparmor cares about is what's inside
<zyga> jdstrand: I'd simply put it in src/apparmor-profile.in
<zyga> jdstrand: and have the makefile generate the real one
<jdstrand> that works too, but then update the debian/ packaging
<zyga> jdstrand: downstream packaging will be doing the rename
<zyga> jdstrand: yep, I will have to do it for debian and ubuntu then
<zyga> jdstrand: just a reminder, I will try to remove debian entirely from the tree so that we can do real tests against real packaging in debian/ubuntu
<zyga> jdstrand: right now debian/ is not used anywhere for real
<kyrofa> tsimonq2, actually I think your units look pretty good. I'd check the coverage, though (do you know how to do that?)
<kyrofa> tsimonq2, however, while you have an integration test snap, you don't have an integration test. Are you working on that?
<kyrofa> Because that will be important
<tsimonq2> kyrofa: so do you think my integration tests need to be added to the tar and zip tests or it's own test?
<kyrofa> tsimonq2, oh I see what you're asking
<kyrofa> tsimonq2, I say add them to tar and zip
<tsimonq2> kyrofa: okay, so it's in the snap, I need to add to the python?
<kyrofa> tsimonq2, so add some more to the simple-zip snap, then add checks to the integration tests that use simple-tar and simple-zip
<kyrofa> tsimonq2, exactly
<kyrofa> tsimonq2, I'm not sure it's worth adding new archives though-- just take the checksums for the archives already in the snaps
<tsimonq2> kyrofa: alright
<tsimonq2> kyrofa: all of them? which ones would you suggest?
<kyrofa> tsimonq2, oh, scratch that. Forgot there were multiple. Go ahead and add a new one :)
<tsimonq2> alright :()
<tsimonq2> *:)
<kyrofa> tsimonq2, do you know how to check the coverage?
<tsimonq2> kyrofa: yeah there's a report
<tsimonq2> kyrofa: that's talking about unit tests right?
<tsimonq2> kyrofa: or is that integration?
<kyrofa> tsimonq2, yup, units, you got it
<tsimonq2> kyrofa: if it's unit, do I add my tests to the Tar and Zip classes or do I make my own class?
<kyrofa> tsimonq2, wait... now I'm not sure what we're talking about
<tsimonq2> kyrofa: in snapcraft/tests/test_sources.py (or whatever the name of the file is)
<kyrofa> tsimonq2, the unit tests you have so far look good (though I've not given them a complete review). The integration tests will be good for actually verifying checksums
<tsimonq2> kyrofa: there's class TestTar(tests.TestCase): and class TestZip(tests.TestCase):
<kyrofa> But the integration tests go in integration_tests, not snapcraft/tests (those are units). Am I answering your question? :P
<tsimonq2> kyrofa: no
<tsimonq2> so here's what I'm asking
<kyrofa> Heh, sorry
<tsimonq2> I added unit tests for incompatibility, right?
<tsimonq2> what about for testing that it works?
<tsimonq2> or that it successfully checks the checksum?
<sergiusens> kyrofa might be good to go, but I don't want to update branch again ;-) https://github.com/snapcore/snapcraft/pull/633
<mup> PR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>
<kyrofa> Well, in order to test that it works, you need to make something to take a checksum OF
<kyrofa> That is an integration test
<kyrofa> sergiusens, you're so mean :P
<tsimonq2> kyrofa: so then what's the difference between integration and unit?
<mup> PR snapcraft#633 closed: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/633>
<kyrofa> sergiusens, oh ha! I see what you're saying now ;)
<sergiusens> tsimonq2 kyrofa difference between unit and integration changes depending on who you ask
<sergiusens> tsimonq2 kyrofa we've settled for integration meaning talking to external servers and using real code to run snapcraft agains using the real snapcraft command
<sergiusens> and for unit, we use some other module
<sergiusens> to call as under test
<kyrofa> tsimonq2, you have the right idea-- you should definitely verify the checksums work correctly. However, in this case the data you need to setup to test the checksums work correctly is beyond what a unit test should do. In order to test this at the unit level you could do some mocking though
<sergiusens> and we consider it totatlly fine to generate artifacts on disk these days
<tsimonq2> kyrofa: so do I need a unit test or not for the coverage?
<kyrofa> tsimonq2, indeed, integration doesn't count toward coverage
<zyga> jdstrand: arch now ships snap-confine 1.0.35
<sergiusens> kyrofa I personally don't see this as a problem with open('file', 'w') as f:\n    f.write('something that will produce a known checksum')
<zyga> arch is FAST :)
<sergiusens> kyrofa aside from an integration test
<sergiusens> zyga how fast?
<zyga> sergiusens: I mean, fast to update
<jdstrand> neat
<kyrofa> sergiusens, it needs to be a tar or zip source though
<zyga> sergiusens: that's not me updating the package
<zyga> sergiusens: that's arch maintainer
<kyrofa> sergiusens, but yeah, you're right, not a big deal
<zyga> sergiusens: it was released a day ago
<sergiusens> kyrofa you could use the tar or zip modules for that, with tar.open...
<zyga> on another note, I just got most spread tests to work on debian sid
<kyrofa> tsimonq2, sergiusens's idea is probably better than mocking
<kyrofa> tsimonq2, use that to make sure your code is covered, and then use the integration tests to cover end-to-end
<tsimonq2> kyrofa: so wait, when he said, "kyrofa I personally don't see this as a problem with open('file', 'w') as f:\n f.write('something that will produce a known checksum')" ?
<kyrofa> tsimonq2, hold on, my son is asking me to tuck him in for his nap, be right back
<tsimonq2> alright kyrofa :)
<mcphail> Can someone point me to details of how to get launchpad to build ARM snaps?
<kyrofa> mcphail, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<mcphail> kyrofa: thanks!
<kyrofa> sergiusens, how would you like him to determine the checksum in a known manner that still tests his code?
<sergiusens> kyrofa I don't follow
<tsimonq2> sergiusens: I need unit test coverage, how would I go about doing that for snapcraft#619 ?
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619>
<kyrofa> sergiusens, he has code that grabs the checksum of the archive. If he generates the archive on the fly he can't know the checksum until it's been generated. How should he get it while still being able to test the checksum-grabbing code?
<sergiusens> tsimonq2 by creating known files on the fly as part of the test fixture setup and passing those to your source (Zip, Tar) calls
<kyrofa> sergiusens, i.e. saying "use my code to get checksum" -> "test that my code that gets checksum matches that checksum" isn't really a valid test
<kyrofa> sergiusens, unless you're saying there's a way to create tars and zips in a completely deterministic manner across archs?
<kyrofa> (not sure what metadata gets packed in there)
<kyrofa> zyga, good for arch, they're ahead of ubuntu!
<kyrofa> zyga, how is that SRU coming? :P
<zyga> kyrofa: I don't know
<zyga> kyrofa: I'm not doing the SRU work really :/
<zyga> kyrofa: I'm working on .36 for more SRU :P
<mvo> attente: hm, what was the sru tracking bug again? I think that should also be in the changelog :) I can add it
<kyrofa> zyga, hahaha
<mvo> attente: aha, found it
<mcphail> Can someone check my snapcraft.yaml at http://bazaar.launchpad.net/~njmcphail/+junk/ag-mcphail/view/head:/snapcraft.yaml ? It isn't building on launchpad as per https://launchpadlibrarian.net/271553088/buildlog_snap_ubuntu_xenial_arm64_ag-mcphail_BUILDING.txt.gz due to grumbles about the "confinement" line, but builds OK on my machine
<kyrofa> mcphail, huh... looks like their snapcraft might be out of date... ?
<mcphail> kyrofa: hmm. Should I poke someone about that?
<mvo> zyga: for xnapd-xdg-open - you just need a git tag? or more?
<kyrofa> mcphail, hop in #launchpad. I just asked
<zyga> mvo: what's the buildystem there? I don't recall
<zyga> mvo: ideally a make dist tarball and a release on github
<zyga> (or launchpad)
<zyga> mvo: and some simple packaging instructions
<mvo> zyga: autotools
<zyga> mvo: is that something that goes into the snap in any way or is it just the host distro
<mvo> zyga: ok, can do in a bit
<zyga> mvo: thanks
<zyga> (I guess arch will be first again :)
<mvo> zyga: we need it alongside snapd
<zyga> understood
<zyga> jdstrand: FYI, https://github.com/snapcore/snap-confine/pull/74
<mup> PR snap-confine#74: Debian spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/74>
<zyga> jdstrand: sid support in spread
<jdstrand> nice!
<kyrofa> mcphail, to be fair I didn't document that very well in the post, so I'm adding a blurb now
<zyga> jdstrand: I'd like to know what to do about the apparmor issue, we have the fact that .34 and .35 shipped without confinement, I'd like to get a resolution you agree on quickly so that .36 can be released that fixes the bigger issue, perhaps without adding a smaller one
<jdstrand> zyga: I think I've been pretty clear :)
<jdstrand> zyga: you can release 1.0.36 if you want without the fix, but we can't release that to Ubuntu because it regresses an important security feature
<mcphail> kyrofa: getting different build errors now, but making progress. Thanks!
<kyrofa> mcphail, good deal! Let me know if you need any help
<mcphail> kyrofa: when building on lp, I assume installing libpcre3-dev doesn't automatically install libpcre3 as well?
<zyga> jdstrand: but ubuntu 16.10 will get .35 through debian so isn't the cat out of the bag already?
<kyrofa> mcphail, I assume it does, isn't it a dependency?
<zyga> jdstrand: let me re-read your comments, I'm not sure what the next step is there
<kyrofa> (I've not actually looked at the cache)
<jdstrand> zyga: 16.10 is the dev release. 16.04 is stable. we can't regress this security feature in 16.04
<jdstrand> we shouldn't in 16.10, but if we do we just fix it
<mcphail> kyrofa: if you look at https://launchpadlibrarian.net/271556609/buildlog_snap_ubuntu_xenial_i386_ag-mcphail_BUILDING.txt.gz , for some reason libpcre3 shows up in the "Skipping blacklisted from manifest packages:"...
<kyrofa> mcphail, ah, must be already installed then
<jdstrand> zyga (cc tyhicks): the next step is to give examples of mount profiles that snapd currently implements
<zyga> jdstrand: only the content interface uses them
<attente> mvo: ah, sorry, thanks for catching that
<zyga> jdstrand: and the read/write paths are decided by plug/slot attributes
<jdstrand> zyga (cc tyhicks): and then understand precisely what mount rules are needed
<zyga> jdstrand: any value is allowed right now
<zyga> jdstrand: that fact implies that any mount rules might be allowed
<jdstrand> zyga: yes, but the source mount point is inside a snap, not /**
<jdstrand> zyga: and the target mount point is inside a snap, not /**
<zyga> jdstrand: one useful use case is /var/lib/snapd/hostfs/usr/share/fonts
<zyga> jdstrand: as for the target directory, let me check
<arges> Hi, I'm playing with the snappy client code. Does it make sense that 'Find' returns a Status of 'available' for each snap even if it is installed on the machine? Do I need to do a separate call to 'List' to determine if a package is actually installed?
<mcphail> kyrofa: perhaps I need to add pkg-config as a build dependency? I'd assumed that would be default?
<jdstrand> zyga: but the fonts directory is an implicit slot, not the content interface
<tyhicks> zyga: sorry to distract from the discussion but does the snap itself define the plug/slot attributes?
<zyga> jdstrand: it would be a slot on the core snap (it doesn't exist yet)
<zyga> tyhicks: yes
<zyga> small clarification, currently both source and destination are rooted at $SNAP
<jdstrand> zyga: right, so we add a rules for /usr/share/fonts like we do for /etc/alternatives
<kyrofa> mcphail, indeed, try adding that
<zyga> so I guess we can constrain those profiles to /snap/*/**
<jdstrand> zyga: and then a different glob rule for content
<jdstrand> yes! :)
<kyrofa> mcphail, it's not a default-- not everything needs it
<zyga> I missed those two lines, I just read the content interface
<mcphail> kyrofa: ok, thanks
<kyrofa> mcphail, not even gcc/g++ is a default
<mcphail> kyrofa: so we need to add build-essential?
<kyrofa> mcphail, you can, but that's a bit of a shotgun
<jdstrand> unfortunately, /snap/bin is in there and shouldn't be mounted, so we'll need several rules to express /snap/*/**.
<tyhicks> zyga: when reviewing the bind mount PR, I thought we were in full control of the source and destination paths
<jdstrand> tyhicks: we are
<kyrofa> mcphail, the only things plugins will add implicitly are the tools required to run them (e.g. the make plugin will install make, autotools will install autotools, etc.)
<kyrofa> mcphail, everything else you have absolute control over
<jdstrand> tyhicks: for content it is relative to the providing snap's and consuming snap's directories
<zyga> yes
<jdstrand> which is why I kept saying let's constrain this to what we actually allow
<mcphail> kyrofa: OK, that's interesting. Is there any way to get a "naked" build environment on a local machine to simulate this? Presumably run it in lxc?
<tyhicks> do we have protections against "../" components in the path?
<zyga> that's a bit unfortunate for font sharing though, there's no way to describe that
<kyrofa> mcphail, indeed, cleanbuild
<jdstrand> zyga: font sharing?
<zyga> tyhicks: we ensure that filepath.Clean(path) == path
<jdstrand> zyga: regardless, we can have a separate rule for the fonts dir, just like we do for all the others
<mcphail> kyrofa: nice. Thanks
<zyga> that is, no ../ bits are present
<zyga> jdstrand: (this is actually inside snapd that we'd have to allow this)
<zyga> jdstrand: to make the source *not* relative to the core snap
<zyga> but I think we are good actually
<jdstrand> zyga: I'm confused about what you are talking about there
<zyga> not for fonts but for this
<zyga> jdstrand: sorry, I'm just observing that content sharing interfae cannot be used to share fonts from the host today
<zyga> but that's not a problem at hand, sorry for adding this to the mix
<jdstrand> ok
<jdstrand> well, in the future we can add whatever mount rule is needed for fonts too
<jdstrand> so, I think some sort of /snap/*/** mount rule with a comment that it is to enable the content interface is fine
<mcphail> kyrofa: actually, looks as if gcc is in the base launchpad build instance already
<zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/73/commits/24bbd4338d24e97330ccd20e3cb01cb714b5f08c
<mup> PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>
<jdstrand> importantly, you are going to have to do the crappy /snap/[^b]*/**, /snap/b[^i]*/**, /snap/bi[^n]*/**, /snap/bin?*/**, /snap/b/**, /snap/bi/** shenanigans
<jdstrand> zyga: see ^. let me add a comment
<zyga> ohhh
<zyga> hmmm
<zyga> is that really needed?
<zyga> I see why but what's the attack there?
<jdstrand> yes
<zyga> you cannot run any of those things
<jdstrand> you don't want to mount /snpa/bin
<zyga> and the mount is happening after unshare
<zyga> why not?
<zyga> will any other process see that mount?
<jdstrand> because like you say it is pointless and we are being fanatical to guard against attacks
<zyga> ah
<zyga> that's a good answer
<jdstrand> give me a minute
<jdstrand> we are being as defensive as possible
<zyga> I mean, if there's any way this is exploitable already I'd like to know (this is why I ask those questions), I undestand general "to be more safe" answers
<jdstrand> I can't think of an attack otoh
<zyga> ok, let me do the exclusive rules then
<jdstrand> zyga: hold on
<zyga> btw, would a deny rule be easier and would work too?
<zyga> ok
<jdstrand> no deny rules
<jdstrand> I mean we can
<jdstrand> well
<jdstrand> actually in this case that would be good
<jdstrand> audit deny mount /snap/bin/**,
<zyga> is the single argument form matching both source and destination?
<jdstrand> that is a good question
<jdstrand> mount rule syntax is annoying
<jdstrand> how about: audit deny mount /snap/bin/** -> /**,
<zyga> yep
<jdstrand> that is clear
<zyga> jdstrand: wait, isn't that reverse
<zyga> jdstrand: source -> destination
<zyga> we don't want to let people bind mount over that
<zyga> or bind mount that somewhere?
<zyga> actually, probably both
<zyga> jdstrand: like this? http://paste.ubuntu.com/18724566/
<zyga> (not tested)
<mup> PR snapd#1510 closed: integration-tests: remove login tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1510>
<zyga> I'll add a few spread tests for this but I need to go now
<jdstrand> yes
<jdstrand> I like that
<jdstrand> I just read the man page and the single argument form is the source mount, but this is very clear
<mup> PR snapd#1509 closed: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1509>
<jdstrand> fyi, without those rules there would be an info leak on the installed snaps
<sergiusens> kyrofa mind looking at https://github.com/snapcore/snapcraft/pull/627
<mup> PR snapcraft#627: Added new maven-targets option to maven plugin <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/627>
<sergiusens> ?
<jdstrand> we don't protect against that perfectly today, but there are longer term work items that will address that
<zyga> jdstrand: good point about the info leak!
<zyga> jdstrand: I'll make the spread tests happen
<zyga> jdstrand: but now -> time to take a walk, it's 21:00 already
<jdstrand> zyga: where'd the time go?!
<jdstrand> zyga: thank you for working on this :)
<tsimonq2> kyrofa: so what am I doing for the integration tests again?
<mup> PR snapcraft#637 opened: Do not clean before running the snaps tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/637>
<kyrofa> tsimonq2, you're adding stuff to integration_tests/test_tar_plugin.py and integration_tests/test_zip_source.py
<tsimonq2> kyrofa: oh okay
<sergiusens> slangasek hey, how's that umbrella bug for SRUing supposed to be created?
<tsimonq2> kyrofa: so what exactly should I test for, should I ensure that it can check the checksum (if so, I don't know if I can do that), should I check the checksum in the test, I mean, what am I trying to do here?
<slangasek> sergiusens: file bug against the package; include pointer to the wiki page describing the exception; document what testing has been done; include this bug in the changelog of the upload
<tsimonq2> slangasek: would https://pad.lv/1599125 , https://pad.lv/1567524 , and https://pad.lv/1590807 be able to be linked to 2.14 please?
<tsimonq2> whoops sergiusens ^
<tsimonq2> sergiusens: or do you think they shouldn't? thoughts?
<sergiusens> tsimonq2 I can link them once a PR is up, seems like a lot for a weeks work though
<tsimonq2> thanks sergiusens for clarifying
<kyrofa> tsimonq2, well, you added some good stuff to simple-tar. An archive along with several known checksums. Make sure the test runs them all, and make sure you do similar things for zip
<tsimonq2> kyrofa: but doesn't it already all run because it's in the snapcraft.yaml?
<kyrofa> tsimonq2, it might, I haven't looked. You may not need to change the tar test at all. But you're missing the zip test snap, right?
 * tsimonq2 does that
<elopio> slangasek: ping. Can you please reply here please? https://bugs.launchpad.net/snapcraft/+bug/1596068/comments/4
<mup> Bug #1596068: The unittests in autopkgtest are run twice <verification-done> <Snapcraft:Fix Released by elopio> <https://launchpad.net/bugs/1596068>
<slangasek> elopio: so the argument is that the unit tests only test the snapd code, and would not pick up a regression caused by a dependency?
<elopio> slangasek: they would catch regressions on dependencies, we don't fake everything. But those regressions should be caught too by the integration tests.
<slangasek> ok
<elopio> and on the integration tests we don't fake any of the dependencies.
<slangasek> elopio: in that case I'm comfortable with your position; I just want to make sure we continue to have strong archive-level CI for this package, which it sounds like you're covering
<sergiusens> slangasek so about the SRU bug now :-)
<elopio> slangasek: great, thanks.
<sergiusens> slangasek can I create a bug with a xenial/yakkety task title "New upstream version X.X.X" with a link to our milestone with all the fixed bugs and features in the summary?
<sergiusens> and maybe a link to the wiki with the exception
<elopio> ah, that's the umbrella you were talking about.
<sergiusens> elopio yes
<slangasek> sergiusens: yes
<sergiusens> slangasek works for me, thanks!
<elopio> sergiusens: please call it the same as mvo is doing for snappy. It's like [SRU] New stable micro release X.X.X
<mup> PR snapcraft#632 closed: Refactor and update the logic that deals with the snap-push store endpoint <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
<tsimonq2> sergiusens: when you have a minute, how do I do that unit test coverage? how do I test checksumming in the unit test? :)
<sergiusens> tsimonq2 run ./runtests.sh unit && python3-coverage html
<sergiusens> tsimonq2 apt install python3-coverage if not there
<tsimonq2> sergiusens: I know how to test, how do I code the unit tests? basically, the clarifying question kyrofa asked
<tsimonq2> (for my PR)
<sergiusens> tsimonq2 either create some zips or tars on the fly which you would know what they compute to or mock some things out. Final judgement should come from our QA master elopio though ;-)
<sergiusens> ohh, I need to leave!
<tsimonq2> elopio? do you agree? we're talking about how to do the coverage for snapcraft#619
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619>
<elopio> tsimonq2: yes, I agree. Ideally, check the sum in a real file, not mocking.
<tsimonq2> thanks elopio :)
<elopio> thanks to you.
<zyga> time to hack
<zyga> jdstrand: does this look like the right approach? http://paste.ubuntu.com/18729680/
<mup> PR snapd#1490 closed: overlord: implement &Retry{After: duration} support for handlers <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1490>
<zyga> jdstrand: I wonder how to do that to see the deny in syslog somehow
<jdstrand> zyga: deny in syslog is difficult. you can dmesg|tail -1|grep 'DEN...' but it has the potential to be racy
<jdstrand> zyga: but yeah, that looks like a fine test
<zyga> jdstrand: I'll try to include some sort of audit trail there
<zyga> jdstrand: I could fork a journalctl -f and kill it later
<zyga> jdstrand: thanks, I'm reading your test
<zyga> jdstrand: one personal preference, quote arguments to echo
<DT01> anyone around that can help with snapcraft 1.x - trying to get lsusb to work on snappy
<jdstrand> zyga: you can probably make that pretty good by adding 10 entries with logger that don't match and then tail -10
<DT01> I have a snapcraft file ready if someone could take a look
<jdstrand> zyga: I normally like that myself, but wasn't sure how well that played with yaml
<zyga> DT01: hey, on 1.0 and 15.04 that could be tricky, not sure if possible
<jdstrand> zyga: that test was pretty annoying to write btw :P
<zyga> jdstrand: I think it works because the whole part there is "free form text" - or so it seems
<DT01> zyga: it builds and installs but when it runs it says that it cannot find libusb-1.0.so.0. Even though it is in the stage\build section
<zyga> DT01: after that you'd be hit by confinement
<zyga> jdstrand: can each test have restore and setup? I think it would be nicer for readability if we start to move long setup code to per-test prepare section
<DT01> zyga: so I need to run in unconfined mode?
<DT01> btw this is for a personal system not to be published
<zyga> DT01: yes and I don't remember how much of that existed in 15.04
<jdstrand> zyga: idk
<DT01> hmmm, I will take a quick stab at that
<jdstrand> zyga: I was treating each dir as per-test and therefore the setup is per-test, but maybe there are other ways of doing it
<zyga> jdstrand: what do you mean by remote environment variables?
<zyga> jdstrand: AFAIR spread supports them
<jdstrand> zyga: I found out the 'environment' runs the $(...) code locally and injects it to the remote end
<jdstrand> zyga: see backscroll in this channel. I wanted to do environement: OSNAP=$(ls ...), but that ls is run on my laptop, not on the remote end
<zyga> jdstrand: there's also []
<zyga> jdstrand: [SOMETHING]
 * zyga looks at spread docs
<jdstrand> zyga: I tried that, but it didn't work
<jdstrand> zyga: I talked to Gustavo and he said that environment is currently there to support SPREAD_LINODE_KEY and not what I was doing
<zyga> jdstrand: I think I see what this does, it runs locally
<zyga> jdstrand: and sends the interpolated value already
<jdstrand> yes
<jdstrand> based on what he said and I observed
<zyga> jdstrand: FYI I just checked that you can have a prepare/restore per task
<zyga> "owner died" geez
<mwhudson> zyga: https://launchpad.net/ubuntu/+source/snap-confine has 1.0.35 now \o/
<mup> PR snapcraft#627 closed: Added new maven-targets option to maven plugin <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/627>
<tsimonq2> elopio: with my PR, to check the checksum, do I use hashlib or the function defined in snapcraft/internal/sources.py and if it's the latter, how would I go about calling it?
<mup> PR snapcraft#638 opened: Re-create feature/maven-targets branch for snapcraft <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/638>
<zyga> mwhudson: that's good, making .36 today :)
<mwhudson> zyga: no rest for the wicked!
<zyga> mwhudson: not in this world
<mwhudson> hopefully i won't screw up the gbp interactions so many times today
<zyga> mwhudson: I didn't manage to fix yakkety snapd tests
<zyga> mwhudson: no idea why that fails, I did a chmod on the two environment files that debian/tests scripts create
<zyga> mwhudson: but no difference
<mwhudson> zyga: i have a vm which i'm going to run the tests in by hand
<mwhudson> zyga: but my qemu-fu is pretty weak
<zyga> mwhudson: I have a vm with yakkety but I don't know how to run those tests without any abstractions in the way
<zyga> mwhudson: but I'm almost sure this is the testbed, not snapd that is at fault
<mwhudson> zyga: i guess staring at the diff between 2.0.2 and 2.0.3 might also be interesting
<zyga> mwhudson: I dind't think of that
<zyga> mwhudson: but it could be substantial :/
<zyga> mwhudson: maybe the diff between debian/tests is smaller
<mwhudson> 15k lines, haha
<mwhudson> zyga: i wonder if it just adds the test that fails or something...
<zyga> mwhudson: you mean debian/tests or snapd in general?
<mwhudson> snapd in general
<mwhudson> but i'm just guessing here
<mwhudson> debian/tests/integrationtests looks fairly different to what's in 2.0.10
<zyga> mwhudson: can we patch it somehow to run just the failing test
<zyga> mwhudson: to make iteration faster
<zyga> mwhudson: in general it takes ~30 minutes for me to run it to failure
<mwhudson> must be possible somehow yeah
<zyga> jdstrand: my spread tests are improving
<zyga> jdstrand: I should be able to see the exact failure soon
<jdstrand> cool :)
<zyga> jdstrand: I've uploaded snapd-hacker-toolbelt 0.2 that adds $SNAP/mnt as a mount point for testing
<mwhudson> zyga: feels like this "resume test after reboot" stuff must be related
<zyga> mwhudson: hmmm
<zyga> mwhudson: maybe snappy updates itself
<tsimonq2> *raises big red flag* elopio, sergiusens: I didn't touch snapcraft/storeapi/__init__.py , did a local merge that involved that file, and my static tests are failing with the following error: snapcraft/storeapi/__init__.py:405:15: F821 undefined name 'e' and I just confirmed that in my clean master branch I'm getting the same eorrr
<tsimonq2> *error
<zyga> mwhudson: and something something reexec happens
<tsimonq2> elopio, sergiusens: so this is on master and the static tests are failing
<zyga> tsimonq2: git diff? :)
<tsimonq2> zyga: I checked that
<tsimonq2> zyga: all clean
<zyga> tsimonq2: git log -p on that file?
 * tsimonq2 checks it out in /tmp and confirms again
<mwhudson> zyga: heh heh when we worked on pypy there were internal jokes about "stuff occuring" whenever we didn't know what was going on
<zyga> mwhudson: the local quantum fluctuation added 'e' there
<tsimonq2> elopio, sergiusens: also confirmed in a clean checkout
<zyga> tsimonq2: locally installed package with a typo?
<tsimonq2> zyga: huh?
<tsimonq2> zyga: clone master locally, git pull origin master, then ./runtests static throws a failure
<zyga> tsimonq2: do you have the same python package installed locally?
<jdstrand> zyga: I'll need to play with snapd-hacker-toolbelt sometime
<zyga> tsimonq2: I had plenty of cases where my /usr/lib/python3/site-packages/ would have something
<zyga> jdstrand: it's just busybox :>
<zyga> jdstrand: I will publish that somewhere
<tsimonq2> zyga: I don't know what you are saying
<zyga> jdstrand: should this say anything? I don't see any denial     dmesg | grep DENIED
<tsimonq2> weird
<tsimonq2> really weird
<tsimonq2> it passes on Travis...
<zyga> tsimonq2: what is the code, snapcraft?
<tsimonq2> zyga: yeah
<zyga> tsimonq2: is python3-snapcraft installed?
<tsimonq2> zyga: E: Unable to locate package python3-snapcraft
<zyga> hmmm
<zyga> how about snapcraft itself
<tsimonq2> yep installed
<tsimonq2> 2.12
<zyga> tsimonq2: just sanity,remove it and try again
<tsimonq2> zyga: snapcraft is uninstalled and it still
<tsimonq2> *still fails
<jdstrand> if you are using 'audit deny' and it tries to mount, it should, yes. you might want to: sysctl -w kernel.printk_ratelimit=0
<zyga> tsimonq2: hmmmm
<zyga> ah, thanks
<zyga> jdstrand: how to undo that
<zyga> what's the default?
<zyga> jdstrand: audit deny or deny audit?
<jdstrand> zyga: to undo, grab 'sysctl kernel.printk_ratelimit' then feed back in later: sysctl -w kernel.printk_ratelimit=$prev
<zyga> jdstrand: it deoesn't work
<zyga> jdstrand: digging deeper
<zyga> spread is fantastic
<zyga> I don't like only one thing about it
<zyga> I prefer --options
<zyga> but everything else is just amazingly useful
<jdstrand> the default is to deny and log. when you add a rule it allows it with no logging. to deny it without logging, specify only deny. to explicitly deny and log, use audit deny. I always use audit first. I never thought it mattered but looking at apparmor.d, audit might need to be first
<zyga> ha
<zyga> trying that
<zyga> because the thing does "work" (busybox true fails)
<zyga> nice
<jdstrand> zyga: it is possible that kern messages aren't going to syslog
<jdstrand> zyga: they should if it is Ubuntu, but perhaps the syslogger is setup different
<zyga> jdstrand: this is 16.04 so ... they should
<jdstrand> zyga: I saw denials with 'dmesg'-- do you see anything there?
<niemeyer> Anyone seen this before: findfs: unable to resolve 'LABEL=writable'
<zyga> niemeyer: looks like the partition doesn't have the filesystem label
<zyga> niemeyer: then we don't boot far
<zyga> niemeyer: I saw it while fiddling with images
<zyga> niemeyer: are you trying to get an all-snap image into linode?
<niemeyer> zyga: The label is properly set
<niemeyer> Yeah
<zyga> jdstrand: successs :)
<zyga> cannot mount /snap/bin at /snap/snapd-hacker-toolbelt/current/mnt with options bind,ro. errmsg: Permission denied
<zyga> woot
<zyga> niemeyer: hmm
<zyga> jdstrand: a few more tweaks and I'll use this test as a base
<zyga> jdstrand: I'm using SNAP_CONFINE_DEBUG
<zyga> jdstrand: then it just puts errors on stderr and I can check that easily
<zyga> [ 4389.271507] audit: type=1400 audit(1467926268.960:29): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/snapd-hacker-toolbelt/2/mnt/" pid=4382 comm="ubuntu-core-lau" srcname="/snap/bin/" flags="rw, bind"
<zyga> jdstrand: so the order DOES matter
<zyga> jdstrand: we can grep for "deny audit" vs "audit deny" perhaps
<elopio> tsimonq2: are you on xenial or yakkety?
<tsimonq2> elopio: yakkety
<jdstrand> zyga: snapd and snap-confine don't otherwise use 'deny audit' (just checked)
<elopio> tsimonq2: yes, it happens only with yakkety's flake8. Please report a bug.
<tsimonq2> elopio: alright thanks
<tsimonq2> elopio: I think I'm almost done too!
<zyga> jdstrand: thanks!
<niemeyer> Someone else reported the same thing in April, with no feedback: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001729.html
<zyga> hohoho
<zyga> niemeyer: fedora 25 can find snaps in the store :>
<zyga> niemeyer: in gnome-software
<zyga> so so cute :>
<niemeyer> Sweet :)
<zyga> just watched this on G+
<zyga> :D
<zyga> that's fantastic to see
<zyga> I suspect this will land in Arch soon :)
<zyga> I'm just going to watch that again
<zyga> to let it sink in :
<zyga> :>
<zyga> niemeyer: btw, did I say how much I love spread?
<niemeyer> zyga: :D
<zyga> niemeyer: I talked about exactly having something like spread at the sprint to fgimenez and elopio and you made it :-)
<tsimonq2> elopio: another thing while you are around. https://github.com/snapcore/snapcraft/pull/619/files#diff-3ce6f0422479e72d9db0860efb0e7b42R132 should cuase the test to fail, I did that intentionally for debugging perposes. It doesn't. https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR177 is what should cause it to fail but it isn't
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> elopio: I can't figure out what the problem is
<tsimonq2> elopio: otherwise, my PR is ready for a full review
<zyga> jdstrand: look at this test please: https://github.com/snapcore/snap-confine/pull/73/commits/9b09f3a2e574bb7782b5be5beaefa4e6cc74ddd6
<mup> PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>
<tsimonq2> elopio: /o\ scratch that, still thinks I have no unit test coverage... ahh
<elopio> tsimonq2: run it locally.
<elopio> sergiusens: latest test of master and staging fails because the snap we are uploading needs a manual review.
<elopio> https://travis-ci.org/snapcore/snapcraft/jobs/143148743
<tsimonq2> elopio: I did
<elopio> tsimonq2: and it fails locally?
<tsimonq2> elopio: the problem is, because the test doesn't fail, it isn't verbose
<tsimonq2> elopio: it's supposed to fail but it doesn't
<tsimonq2> elopio: (unit tests)
<elopio> tsimonq2: have you used pdb?
<tsimonq2> elopio: never heard of it
<elopio> tsimonq2: add this line before https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR177 : import pdb; pdb.set_trace()
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<elopio> that's a debugger. Enter n to jump to the next line. You can print a variable with p var_name.
<tsimonq2> wow that's awesome! :D
<zyga> heh :)
<elopio> https://docs.python.org/3/library/pdb.html
<zyga> you should try gdb some day
<elopio> tsimonq2: read that ^.
<zyga> like pdb but also down to the metal
<tsimonq2> elopio: how do I run coveralls locally?
<elopio> tsimonq2: install python3-coverage. Coveralls is just a way to display the report, not something you run locally.
<tsimonq2> elopio: oh I see
 * tsimonq2 remembers now :D
<mwhudson> zyga: I hacked it to only run the failing test, it passes of course
<zyga> mwhudson: since it failed on some service still running I suspect it's bleeding the previous ttest that is causing the next one now
<mwhudson> zyga: certainly plausible
<tsimonq2> elopio: so when I run the unit tests, am I supposed to get a debugger? because I'm not
<zyga> I forked the test to cover both cases
<zyga> I'll also have to patch the earlier tests that now fail because mount profiles got more constrained
<tsimonq2> elopio: and the coverage statement tells me that all three of my if/elif statements never returned to true
<zyga> but we're looking good :)
<elopio> tsimonq2: then put the breakpoint earlier, you are not hitting that statement.
<tsimonq2> alright elopio
<mwhudson> zyga: ah --shell-fail finally worked for me
<zyga> mwhudson: did you change anything?
<mwhudson> zyga: when i log in, systemctl status snap-basic\\x2dbinaries-100001.mount is bad
<zyga> mwhudson: for me it printed commands, none of which worked
<mwhudson> Jul 08 09:49:37 autopkgtest mount[2148]: mount: special device /var/lib/snapd/snaps/basic-binaries_100001.snap does not exist
<zyga> mwhudson: explore, why is it bad
<zyga> oh
<zyga> is that snap gone?
<mwhudson> zyga: oh hm, no the ssh command worked for me
<mwhudson> zyga: no, its there
<mwhudson> zyga: and in fact i can run sudo systemctl start snap-basic\\x2dbinaries-100001.mount and it starts
<mwhudson> zyga: could be a race? /me guesses wildly
<zyga> hmmmm :<
<zyga> I doubt it, we put the unit in place after we've looked at the squashfs file
<zyga> mwhudson: anything in snapd log?
<mwhudson> zyga: journalctl -u snapd?
<mwhudson> or something else?
<zyga> that should be it
<zyga> Day changed to 08 lip 2016
<zyga> geee, thanks irssi
<zyga> I wonder if any other irc client says that
<mwhudson> quassel does
<mwhudson> zyga: some stuff, yeah http://paste.ubuntu.com/18738038/
<zyga> hmmm
<zyga> one thing is very wrong
<zyga> Jul 08 09:49:38 autopkgtest /usr/lib/snapd/snapd[2060]: taskrunner.go:234: DEBUG: Running task 33 on Do: Mount snap "basic-service"
<zyga> Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: task.go:250: DEBUG: 2016-07-08T09:51:08+12:00 ERROR [start snap-basic\x2dservice-100001.mount] failed with exit status 1: Warning: snap-basic\x2dservice-100001.mount changed on disk. Run 'systemctl daemon-reload' to reload units.
<zyga>                                                         A dependency job for snap-basic\x2dservice-100001.mount failed. See 'journalctl -xe' for details.
<zyga> Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: taskrunner.go:234: DEBUG: Running task 32 on Undo: Prepare snap "/tmp/snapd-sideload-pkg-316559037"
<zyga> (sorry for pasting like that)
<zyga> ah, no sorry
<zyga> I though it's ignoring the error and carrying on but it is in fact undoing the thing
<zyga> mwhudson: can you reproduce this if you run this in a loop?
<zyga> I mean the whole testbed
<zyga> and if so, how fast can you run it?
<mwhudson> zyga: it seems pretty reproducible yeah
<mwhudson> and it takes, uh, 10mins to run?
<zyga> mwhudson: I was wondering if we can patch snapd to run deeper syslog dump when that fails
<mwhudson> zyga: can certainly try that
<zyga> mwhudson: or can you see that manually after logging in?
<mwhudson> zyga: i don't know, am happy to try things :)
<zyga> mwhudson: I have no idea why this might fail, I'm just trying to see beyond:
<zyga> Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: task.go:250: DEBUG: 2016-07-08T09:51:08+12:00 ERROR [start snap-basic\x2dservice-100001.mount] failed with exit status 1: Warning: snap-basic\x2dservice-100001.mount changed on disk. Run 'systemctl daemon-reload' to reload units.
<zyga>                                                         A dependency job for snap-basic\x2dservice-100001.mount failed. See 'journalctl -xe' for details.
<mwhudson> zyga: oh hm, maybe http://paste.ubuntu.com/18738572/ ?
<mwhudson> zyga: btw did you see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 ?
<mup> Bug #1599799: snapd > 2.0.2 fails on yakkety <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1599799>
<mwhudson> that latest paste does look a little more informative
<zyga> mwhudson: I saw it, I've added a comment to it
<zyga> mwhudson: Jul 08 09:51:08 autopkgtest systemd[1]: dev-loop2.device: Job dev-loop2.device/start timed out.
<zyga> Jul 08 09:51:08 autopkgtest systemd[1]: Timed out waiting for device /dev/loop2.
<zyga> this looks wrong :/
<mwhudson> oh yes, so you ddid
<zyga> https://bbs.archlinux.org/viewtopic.php?id=196083 suggest this is when the source doesn't exist but I find that hard to believe
<mwhudson> does seem unlikely
 * zyga iterates on mount tests
<zyga> ro test done, rw test almost done
<zyga> I changed the testing approach but the test is still valid
<zyga> jdstrand: around?
<zyga> jdstrand: I realized that there's no reason for allowing rw mounts
<zyga> jdstrand: since we constrain to $SNAP anyway
<zyga> jdstrand: ... they are always read only now
<thomi> sergiusens: I'm once again hitting the issue where #! lines in python scripts point to my stage directory, rather than to the bundled python within the snap. I've tried making 'command' both reative within the snap, and just the command name, with no l uck
<thomi> sergiusens: at what point is the #! line supposed to get rewritten?
<zyga> jdstrand: I've updated https://github.com/snapcore/snap-confine/pull/73
<mup> PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>
<zyga> jdstrand: if you feel that is sufficient now please merge it
 * zyga EODs
<chasinglogic> Hey does anyone know if there will be 16.04 images of snappy available? I noticed that there weren't any for 15.10
<zyga> chasinglogic: there will be, we're working on the fine details
<zyga> chasinglogic: when is more complicated but I'm already EOD and tired today
<chasinglogic> zyga: if I grab the 15.04 image will I be able to upgrade
<zyga> chasinglogic: no
<chasinglogic> zyga: cool thanks for the info!
#snappy 2016-07-08
<qengho> chasinglogic: Enough of snappy was in 16.04 kernel and apparmor that it can run there. We're not backporting to something like the soon-to-expire-anyway 2015 releases.
<chasinglogic> qengho: I didn't expect it to be backported, I was just looking for the newest version. But I also don't want to start playing with 15.04 if I can't upgrade it when 16.04 comes out
<qengho> chasinglogic: Let's make sure we're talking about the same thing. Ubuntu 16.04 LTS was released in 2016-04. It had snappy functionality, but no official release of Snappy. I think(!) Ubuntu is releasing Snappy images for the first time, based off of Ubuntu 16.04 soon.
<chasinglogic> I'm talking about Ubuntu Snappy Core the distribution
<qengho> Okay. That doesn't exist yet. It's in progress.
<chasinglogic> qengho: correct, that's the info that zyga gave me so I'm just waiting
<chasinglogic> :D
<qengho> chasinglogic: Though, installing "snapd" on a Ubuntu 16.04 gets you what it will look like, inside. You don't have to wait to get started. You have to wait to get an image to put on a embedded device.
<qengho> ^embedded^small
<chasinglogic> qengho: Yeah I've been playing with snaps and snapcraft on my desktop and laptop, I'm looking for something coreos-esque to make clusters out of. (and I'd like to convert my pi to snappy core)
<qengho> Ah, right. Soon.
<liuxg> elopio, ping
<thomi> if a snapped command dumps it's core, any ideas where it ends up on disk?
<liuxg>  in the tutorial at http://snapcraft.io/create/, it teaches us  to use "hello" to run the example, however, in the second example, it askes us to run it by using "hello-debug.hello" (package_name.<name under apps>.  Previously, the second one was the way for ubuntu core. what is the correct way to run an app?
<mup> PR snapcraft#639 opened: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/639>
<elopio> liuxg: hello
<liuxg> elopio, I found a very strange problem. at the link http://snapcraft.io/create/, for the first tutorial, I can run the app using "hello", however, I cannot run it using "hello.hello"
<liuxg> elopio, if I change the package name to "hello1" like http://paste.ubuntu.com/18752046/, then I can run it using "hello1.hello". However, hello does not run any more. is this a bug?
<elopio> liuxg: if your command has the same name as the snap, then the command will not have the .
<elopio> in the tutorial example, the snap should be only hello. Not hello.hello.
<elopio> in your case when you renamed the snap, then hello1.hello is the right name for the command. So unless I misunderstood your comments, thats by design.
<liuxg> elopio, is this a special case? the package name and name under "apps" are the same. we cannot use "."ãto run it?
<elopio> thomi: what do you mean with "dumps it's core"?
<elopio> liuxg: yes. The no foo.foo, just foo.
<liuxg> elopio, would you please point me to the design doc for it? thanks
<liuxg> elopio, I want to have a better understanding about the design. As a tutorial, it is not inconsistent for the tutorials there, and it causes confusion to developers.
<elopio> liuxg: no, sorry, that was too long ago.
<elopio> I have no idea if there ever was a document.
<liuxg> elopio, I think it is good to point out to developers. it is truly a little confusing. Anyway, I know it from you :) In fact, I tried to figure it out by playing it.
<qengho> liuxg: When the app name is the same as the package name, only the package name is used to construct the executable name. When they're different, you prefix the app name with the package name and ".".
<elopio> liuxg: oh, look, I found the PR: https://github.com/snapcore/snapd/pull/688
<mup> PR snapd#688: snappy: support generation of short binary names  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/688>
<liuxg> qengho, thanks. I know it now
<liuxg> elopio, thanks for the help. we just need to document it somewhere.
<elopio> sure. File a bug please.
<liuxg> elopio, which project should I file against? would you please give me a link for it? thanks
<elopio> liuxg: the link is at the bottom of the snapcraft.io page.
<liuxg> elopio, ok. I got it. thanks
<thomi> elopio: as in after a segfault
<thomi> elopio: but I think I figured it out anyway
<liuxg> when i am trying to install a snap, the very first installation seems to have errors. However, the second installation is successful http://paste.ubuntu.com/18754704/, what is the reason for it? thanks
<mup> Bug #1600083 opened: 'snap' tool bash completion does not complete local file names <Snappy:New> <https://launchpad.net/bugs/1600083>
<mup> Bug #1600085 opened: interface for making bpf syscalls <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1600085>
<mup> Bug #1566604 changed: the snap command has no autocompletion <Snappy:Fix Released> <https://launchpad.net/bugs/1566604>
<mup> PR snapcraft#639 closed: Use a snap that doesn't require a manual review for the upload test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/639>
<liuxg> does anyone know how to stop a running snap service?
<ljp> liuxg: sudo systemctl stop snapd.service snapd.socket
<stevebiscuit> arges: client.Find() *only* returns the snaps available on the store, I've had to merge the result from that and client.List() to simulate the *old* behaviour for snapweb: https://github.com/snapcore/snapweb/pull/31 . We could maybe introduce something similar to the client lib if there's demand for apps other than snapweb
<mup> PR snapweb#31: Show installed snaps in store listing <Created by stevenwilkin> <https://github.com/snapcore/snapweb/pull/31>
<liuxg> lpotter, thanks. I have a webserver service like "hello-world-service". it has the port number 8000. how to stop it?
<liuxg> lpotter, on ubuntu core, it used to have "snap services status",  and we can use "stop" or "start" command to manage it.
<lpotter> might try something like systemctl stop snap.<snap_name>.<command>.service
<17SAAMNLJ> lpotter, thanks, it works.
<RyanTG> If I have vlc-2.2.2-5 via apt and vlc-daily via snap, why does the apt version take precedence when I go to launch it?
<RyanTG> Is it a path ordering problem?
<tsimonq2> RyanTG: try uninstalling vlc from apt
<qengho> RyanTG: Yeah, you have two programs with the same name. If you want one, use its full path.  /snap/bin/vlcsomething or /usr/bin/vlcsomething
<mup> PR snapd#1513 opened: tests: readd the fake store tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1513>
<liuxg> when I am trying to build the example at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui on 16.04 desktop, my snapcraft version is 2.12. I get the error like :Error downloading stage packages for part 'cam': no such package'fswebcam' . what could be the problem for it? thanks
<RyanTG> tsimonq2: I did uninstall vlc using apt-get purge, but i'm concerned about the day trying to remove an apt package wants to remove a lot of other stuff with it, or gets reinstalled if it's part of a meta-package like *-desktop
<tsimonq2> RyanTG: I think it's fine :)
<mup> PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514>
<dholbach> hey hey
<mup> PR snapd#1491 closed: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1491>
<mup> PR snapd#1442 closed: many: allow removal of broken snaps, add spread test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1442>
<qengho> RyanTG: Suggest something. You have two packages installed that provide the same program. What do you propose should happen?
<qengho> Many service programs are rightly programmed to disallow running as root. What should we do for their snaps?
<RyanTG> qengho: I'm not sure what should happen. When I first installed it, I knew I already had vlc from apt. I wanted to see what would happen.  I thought there would be a good chance of vlc showing up twice in my menu (maybe that happens in dash, but I don't use dash).
<RyanTG> I use classicmenu-indicator
<mup> PR snapd#1513 closed: tests: readd the fake store tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1513>
<mup> Bug #1600136 opened: App indicator does not show icon for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600136>
<mup> Bug #1600138 opened: App indicator does not show menu entries for Qt apps <desktop> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600138>
<mup> PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1514>
<Dubstar_04> Good Morning, I'm having issues with Nvidia drivers and snaps. If i use the Nouveau drivers it works fine. Is there anything I can do?
<mup> Bug #1600140 opened: App indicator adds an entry for each snap launch <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600140>
<mup> PR snapd#1514 opened: client: improve error from client.do() on json decode failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/1514>
<mup> PR snapd#1515 opened: asserts,daemon: cross checks for account and account-key assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1515>
<mcphail> Dubstar_04: gl errors? I get that too
<mup> Bug #1600154 opened: Reading gsettings key don't work locally (writing does) <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600154>
<zyga> Dubstar_04: hey
<zyga> Dubstar_04: we're are aware of the issue, can you tell me which distribution you are using
<zyga> Dubstar_04: on ubuntu the fix is not fully released yet
<liuxg> didrocks, I just removed my snapcraft which was verion 2.12. Now, i want to try to install it again. do i need to add any ppa?
<didrocks> liuxg: xenial?
<liuxg> didrocks, yes
<didrocks> liuxg: no, the version in the distro (2.12) should be the one you would use
<liuxg> didrocks, I used the command "sudo apt-get install snapcraft",  but it complains "Unable to locate package snapcraft"
<liuxg> didrocks, I am trying to isolate the problem, so I removed my previsous snapcraft
<didrocks> it's in universe
<didrocks> same than my answer on the ML
<didrocks> you did remove universe, from your system
<liuxg> didrocks, how can I add it back?
<didrocks> liuxg: how did you remove it, you have two ways, command line (changing the sources.list file or UI)
<liuxg> didrocks, i just did it by "apt remove snapcraft"
<didrocks> no, you removed universe explicitely on your system I would say
<didrocks> (that was before)
<didrocks> in "update" (or whatever it is in english -> ensure that universe is ticked
<liuxg> didrocks, I do not remember it clearly when I did that.
<Dubstar_04> syga: i'm on ubuntu 16.04.
<didrocks> liuxg: "software-properties-gtk"
<didrocks> that's what you need to run
<didrocks> ensure universe is checked
<Dubstar_04> zyga: ^^
<liuxg> didrocks, yes, it is on, then ...
<didrocks> tick it off
<didrocks> and then on
<didrocks> but it can't be on from your output on the ML
<didrocks> and the fact you are telling me you can't install snapcraft
<liuxg> didrocks, is it the one "Community-maintained free and open-source software"?
<didrocks> liuxg: exactly "(universe)" next to it
<liuxg> didrocks, thanks. it is true. it was ticked off.
<zyga> Dubstar_04: then this will be fixed with the next SRU
<didrocks> ah, see! :)
<Dubstar_04> zyga: superb. thanks.
<liuxg> didrocks, is there any way to have an example for packaging a ubuntu phone app into snap?
<liuxg> didrocks, I think this will be very useful to developers to show the convergence story.
<liuxg> didrocks, one app runs on all platforms.
<didrocks> liuxg: not yet, you can be the one creating it! :)
<didrocks> liuxg: I think adding the right package deps + desktop/qt5 launcher should be enough
<liuxg> didrocks, I have a little problem in building the ubuntu-clock example.
<didrocks> from playpen?
<liuxg> didrocks, yes
<didrocks> that's the issue you mentioned on the ML, right?
<didrocks> did you retry since you added universe?
<didrocks> (as I told you, this was your problem there as well)
<liuxg> didrocks, yes, I am now building it again to see what happens.
<didrocks> keep me posted!
<liuxg> didrocks, this time, I have a different issue http://paste.ubuntu.com/18772870/
<didrocks> liuxg: this is a temporary failure from launchpad
<didrocks> you need to apt get update
<didrocks> and rerun
<didrocks> (this can get 30 min to get sorted out)
<liuxg> didrocks, OK. then I will wait and see. so, you are having the same problem with it?
<didrocks> cjwatson: FYI, seems we can still have some hash sum mismatch (I thought they were all fixed) ^
<didrocks> liuxg: no, it depends on your mirror
<didrocks> liuxg: if you catch it at the wrong time
<didrocks> so, try to sudo apt update
<didrocks> and rerun a build
<liuxg> didrocks, OK. I might need to change another one to see it. thanks
<didrocks> if still failing the same way
<didrocks> wait a little bit
<didrocks> and redo :)
<didrocks> keep us posted!
<liuxg> didrocks, in fact, I did apt update before building the project.
<liuxg> didrocks, I changed a mirror site, and it seemed better :)
<liuxg> didrocks, thanks for your help
<didrocks> liuxg: yw! :)
<liuxg> didrocks, I am getting the .snap file :) it used to work for me. I think it was broken somehow.
<cjwatson> didrocks: you can still have hash sum mismatches if sites have actual wrong content, yes.  that one isn't a problem with mirror structure
<cjwatson> didrocks: (because files in pool/ have always had a unique mapping from URL->content - my recent fixes were about indexes because pool/ didn't need fundamental fixes)
<cjwatson> didrocks: so no, that's *not* a temporary failure, and it's *not* a failure from Launchpad, it's just that one mirror being busted
<cjwatson> didrocks: or possibly data corrupted in transit
<mup> Bug #1600166 opened: Snap rely on dns-masq running on 127.0.0.1 instead of /etc/resolv.conf <Snappy:New> <https://launchpad.net/bugs/1600166>
<mup> PR snapd#1516 opened: daemon: drop auther() <Created by chipaca> <https://github.com/snapcore/snapd/pull/1516>
<didrocks> cjwatson: oh ok, I'm not expert enough to ensure those were valid corruptions or the races on the indexes we had. Ok, so now, we can only have valid mismatch, thanks for looking at it! :)
<cjwatson> didrocks: right, you can tell it's not an index race just by seeing that the mismatch is on a file in pool
<cjwatson> the previous hard case was always on something in dists
<didrocks> ah ok, gotcha!
<didrocks> TBH, I never looked closely than the error message, getting it now. (my bad)
<Chipaca> dpm, good job on the notes snap work!
<Chipaca> just saw the bugs and read all the pain :-)
<dpm> Chipaca, thanks, kudos to didrocks to help me figuring them out! :)
<Chipaca> ah, but we already know didrocks rocks. Oxymoronic, really.
<didrocks> :-)
<mup> PR snapd#1514 closed: client: improve error from client.do() on json decode failures <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1514>
<szszsz> Hi! Is there any difference between installing snappy package with sudo and without it?
<mup> PR snapd#1516 closed: daemon: drop auther() <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1516>
<jdstrand> zyga: I see you merged 73 (good-- I was hoping you saw my comment that it was fine to merge :)
<zyga> jdstrand: yep
<zyga> jdstrand: I'm going to cut the release shortly, I just feel sleepy and I'm rading some suse manuals
<zyga> jdstrand: I'll just do it now
<jdstrand> I imagine that would do that to you :)
<zyga> no, that's not related ;>
<zyga> suse is pretty interesting, many new concepts
<zyga> I should just sleep more ;)
<Odd_Bloke> szszsz: I believe there is a difference, but I'm not a snappy person so I don't know exactly. :)
<zyga> szszsz: no,
<zyga> szszsz: it allows you to install the package if you are signed in
<szszsz> Odd_Bloke: zyga: OK, thanks!
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/76
<mup> PR snap-confine#76: Drop the alternative to ROOTFS_IS_CORE_SNAP <Created by zyga> <https://github.com/snapcore/snap-confine/pull/76>
<zyga> jdstrand: not critical, I'll cut the release now without this patch landing
<jdstrand> zyga: commented
<jdstrand> zyga: a welcome change :)
<sborovkov> Hello, are there any news about ubuntu-image
<zyga> sborovkov: not sure, try to ask slangasek
<zyga> jdstrand: 1.0.36 is out
<zyga> jdstrand: I'll do the packaging honors :)
<sborovkov> slangasek: Hi, what's the status of ubuntu-image?
<sborovkov> Also are there any news about gadget snap spec being finalized? I remember that was blocking for /dev/vchiq on RPI
<jdstrand> zyga: cool, thanks!
<zyga> jdstrand: BTW, your regression tests have some if ! something; then exit 1; fi lines
<zyga> jdstrand: all of the script runs under set -e
<zyga> jdstrand: so that is redundant, each failing line fails the test
<jdstrand> zyga: I saw your review, I'll be going through that and all the interface PRs after I get through emails
<zyga> jdstrand: thanks!
<jdstrand> fyi, I'll be on holiday until Jul 20th starting Sat
<zyga> jdstrand: I'll try to help with interfaces but I'm super slow lately
<zyga> must be summer :/
<zyga> ah, nice
<zyga> I plan to have holiday early August
<jdstrand> but tyhicks can do policy reviews in my absence. I'll send a Where's Jamie later today
<jdstrand> zyga: nice! :)
<ysionneau> is it possible when declaring systemd services in the snap, to setup dependencies between services?
<didrocks> ysionneau: no, I think that goes with the bigger bug "enable setting up your own entries in the .service file"
<didrocks> ysionneau: you aren't stuck and can hack it though :p
<didrocks> (as the .service file is rw, you can change it after installing your snap)
<didrocks> even from another service
<didrocks> (yeah, it's a hack)
<kyrofa> didrocks, dpm-bbiab thanks for tracking down the app indicator bug, it's been bothering me
<didrocks> kyrofa: yw! I'm going to fix the apparmor policy, at least, we will have the menu appearing
<didrocks> (and won't block process anymore)
<didrocks> the icon oneâ¦ I'm puzzled and unsure how we can fix it
<kyrofa> didrocks, ah right, I meant the icon one. The other one should be a bit easier... the icon is tough
<didrocks> because this file is generated just before sending the dbus call
<didrocks> not at install time, not at startup timeâ¦
<kyrofa> Indeed
<kyrofa> And we definitely don't want to patch unity
<didrocks> right, because, what about other shells?
<didrocks> and other distros?
<kyrofa> Exactly
<kyrofa> Curious to hear jdstrand's thoughts on that one
<didrocks> yep
<mvo> mwhudson: hi, I heard rumors you have some clues about the yakkety autopkgtest failures? I'm super curious to learn more :)
<jdstrand> I just responded to the bug actually. perhaps my comments might provide inspiration for a solution
<ysionneau> didrocks: ok :)
<kyrofa> Thanks for the thoughts jdstrand. So snaps can write to the system /run/shm/ ?
<ysionneau> didrocks: another thing, it seems you can to daemon: oneshot, but then it fails because Restart=on-failure in the unit file
<ysionneau> systemd wants Restart=no
<ysionneau> but you cannot say restart-condition: no in the yaml, it is refused :x
<jdstrand> kyrofa: they can write to: /{dev,run}/shm/snap.@{SNAP_NAME}.**
<kyrofa> ysionneau, indeed, I made a bug for that a week or two ago
<ysionneau> you can say restart-condition: never, but this is not accepted by systemd
<ysionneau> so 1Â°) oneshot is basically un usable, and 2Â°) Restart=no/never does not work
<kyrofa> jdstrand, ah okay, but it's not namespaced like /tmp?
<ysionneau> kyrofa: do you have the bug id please?
<jdstrand> kyrofa: it doesn't matter if it is a file or a directory or a directory tree
<kyrofa> jdstrand, the snap and system see the same /run/shm?
<kyrofa> Nice, okay
<jdstrand> kyrofa: it is namespaced (noticed SNAP_NAME) but it isn't mount namespaced. ie, it is in the global namespace
<kyrofa> ysionneau, bug #1595661
<mup> Bug #1595661: snapd uses "never" in systemd unit files when it should be using "no" <snapd (Ubuntu):New> <https://launchpad.net/bugs/1595661>
<mup> PR snapd#1517 opened: wrappers: run update-desktop-database after add/remove of desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1517>
<kyrofa> jdstrand, right, very good
 * jdstrand notes that he always warned about a private /tmp would cause problems, but the /tmp problem is a difficult one
<ysionneau> thanks kyrofa
<kyrofa> jdstrand, the private tmp complicates things, but still makes sense I think
<didrocks> jdstrand: interesting idea, I think that worth a shot
<kyrofa> didrocks, is that icon stuff upstream Qt, or do we have ubuntu patches on top?
<didrocks> kyrofa: it's upstream Qt in Qt5, we have sni-qt for qt4
<kyrofa> Right, I remember that now
<didrocks> (the indicator spec is based on KDE one)
<didrocks> I worked on this years ago (not the main contributor), I have blurry memories of it, so, I don't know how much this is going to be easy
<didrocks> it worthes a try at least
<didrocks> jdstrand: oh btw, debugging the notes indicator, I'm going to add the apparmor profile needed updates for that, but debugging, I had another instance of messages that are in /var/log/syslog but not shown in scanlogs
<mup> PR snapd#1518 opened: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1518>
<kyrofa> didrocks, you've been doing amazing parts work, by the way
<kyrofa> didrocks, very much appreciated
<niemeyer> Hellos
<niemeyer> ogra_: ping
<ogra_> niemeyer, yo
<niemeyer> ogra_: Heya
<niemeyer> ogra_: Yesterday I went over a long trip on core images and initramfses
<niemeyer> ogra_: One thing I learned is that our canonical-pc-linux doesn't currently support SCSI virtio.. we should fix that so we can support partvirtualization on those images
<didrocks> kyrofa: thanks a lot :-)
<ogra_> niemeyer, can you file a bug, i'll add it then
<niemeyer> ogra_: Will do, and I have a question out of curiosity too
<niemeyer> ogra_: our cmdline has init=/lib/systemd/systemd
<ogra_> niemeyer, long term there is still the plan to have "two half initrds" ... but we first need images for this
<ogra_> i assume that init= thing can go nowadays
<ogra_> thats 15.04 legacy
<niemeyer> ogra_: But that's inside partition 3, and under system-data
<ogra_> well, it is on / after the initrd assmbled the rootfs
<niemeyer> ogra_: Where do we tell the initramfs where to chroot to before running that
<ogra_> we dont ... we assemble the rootfs first ... then we call run-init (which is another "pivot_root")
<niemeyer> ogra_: Yeah, I understand there must be something pivoting into it.. the question is just where is that set
<ogra_> assembly happens based on partition names
<ogra_> not sure what you mean by "where is tha set" ... we assemble the rootfs under ... say /rootfs ... thats done by scripts in the initrd that look up the partiition names, mount teh right bits in the right places etc ... once that /rootfs is complete we pivot into it
<jdstrand> didrocks: scanlog does not show dbus denials atm. there is a card for that
<niemeyer> ogra_: Well, yeah, that's basically what an initrd is, isn't it :)
<ogra_> (essentially it looks for the writable partiton, mounts the core snap in the target dir and then processes $target/etc/system-image/wriitable-paths to get the rw bind mounts in place ... relative to $target)
<niemeyer> ogra_: The question is how that's expressed..
<niemeyer> ogra_: How do we assemble that initrd so it does what we want.. there are a bunch of code there which is standard for every initrd, so I'm guessing this is not hand-coded every time, but rather has some proper configuration and conventions around it
<ogra_> niemeyer, aah ...
<ogra_> we use initramfs-tools from the distro ... and on top of that we use initramfs-tools-ubuntu-core ...
<didrocks> jdstrand: ah, making sense. https://github.com/snapcore/snapd/pull/1519 btw
<mup> PR snapd#1519: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519>
<mup> PR snapd#1519 opened: Add Qt5 indicator support in unity7 interface <Created by didrocks> <https://github.com/snapcore/snapd/pull/1519>
<niemeyer> Aha
<ogra_> initramfs-tools itself has a hooks and scripts ability to override scripts and hooks with your own stuff
<niemeyer> ogra_: Wheres the source of initramfs-tools-ubuntu-core?  I bet the answer to my questions are all there
<ogra_> so initramfs-tools-ubuntu-core ships our assembly script that is run by the infra of initramfs-toools
<ogra_> apt-get source ... there is no tree or anything
<niemeyer> No repository?  Are we back at the 90s? :)
<ogra_> you want scripts/ubuntu-core-rootfs http://paste.ubuntu.com/18789757/ ...
<ogra_> nah, we're stuck in the 80s with that one ... 90s ... way to modern :P
<ogra_> note that this script still carries 15.04 bits ... we need to drop them
<niemeyer> Gotcha
<ogra_> we were also discussing to drop all the bind mount bits from ubuntu-core and do everything in the initrd
<ogra_> currently this is split in two ... i'd love to have the initrd give us an already properly set up rootfs instead (thats phone legacy we dont reall need anymore)
<ogra_> and a third thing that we should talk about at the sprint is to perhaps split the core snap in two as well ...
<ogra_> i know zyga is eager to actually only have the snap exec env in core ... we dont really need bits like systemd on classic ...
<ogra_> so we might be able to have core and core-bootable ...
<ogra_> oon classic you would onyl install core
<ogra_> images would use core+core-bootable ... which would ship the bits to actually run it as rootfs
<ogra_> (but thats sprint stuff that i'd like to discuss there)
<niemeyer> Sounds good
<niemeyer> I also recall seeing the idea flying that we might not need an initrd at all, but that's been a while ago and I have no context
<ogra_> well, thet wouldnt work ... we need the rw bind mounts to appear somehow ... before init runs
<ogra_> *that
<ogra_> at least some of them
<niemeyer> Yeah, I wouldn't worry at this point
<ogra_> (no initrd would *massively* speed up our boot ... but i dont see a way to get along without one)
<niemeyer> ogra_: There's nothing inside the initrd that cannot be on the image itself
<ogra_> niemeyer, well, a) you need the modules to find your disk ... b) you need the bits that init expects
<mup> Bug #1600260 opened: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260>
<didrocks> niemeyer: I guess you are already aware of it, but the PR is failing in spread (can't access one of the test snap package), unsure it needs a rekick
<mvo> didrocks: just rekick
<mvo> didrocks: that got fixed ages ago (~7min or so)
<didrocks> ahah :)
<didrocks> sorry to not be on the edge!
<mvo> didrocks: ;)
<niemeyer> ogra_: There are straightforward solutions for those, I believe
<didrocks> "This build can't be restarted
<niemeyer> ogra_: But again, let's not worry for now
<didrocks> mvo: mind doing it? ^
<ogra_> i dont, but lets talk at the sprint
<niemeyer> Yeah
<didrocks> (I don't remember if "retest this please" rekicks travis CI as well)
<niemeyer> ogra_: #1600260 filed
<mup> Bug #1600260: Support paravirtualization <Snappy:New> <https://launchpad.net/bugs/1600260>
<ogra_> thx
<niemeyer> didrocks: It doesn't
<mvo> didrocks: sure, done
<didrocks> yeah, that's what I thought, I don't have permissions to restart the build, that's weird, IIRC, travis CI don't show up the button in that case (but I got it)
<niemeyer> ogra_: Thank you for looking into it
<didrocks> anyway, thanks!
<ogra_> np, should be an easy fix
<dak__> hello. i have a question - i made a snap for angband and installed it, but when i run the command, it looks for /share/angband directory instead of $SNAP/share/angband, thus failing.  any additional step needed to make the snap point to the right location?
<didrocks> dak__: hey! it really depends on the upstream build system, you can for some set --datadir= and point to something or having them relocatable
<didrocks> the best is for the apps to see there is no /share and then, look to a relative path
<jdstrand> niemeyer: fyi, finally responded to https://github.com/snapcore/snapd/pull/1405. going through other PRs now
<mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
<niemeyer> jdstrand: jd
<niemeyer> jdstrand: Thanks!
<mup> Bug #1600271 opened: snap install/remove multiple package names <Snappy:New> <https://launchpad.net/bugs/1600271>
<joc_> jdstrand: thanks for response on zigbee-dongle, can i just check one point
<joc_> jdstrand: if /dev/zigbee/ only contains symbolic links will the apparmor glob /dev/zigbee/* work
<joc_> jdstrand: i was under the impression it wouldn't, and was the reason why some of the other interfaces I looked at dereference paths that include symbolic links (e.g. bool-file)
<mup> PR snapd#1483 closed: many: migrate SnapSetup and SideInfo to use RealName <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1483>
<jdstrand> joc_: no, it won't. apparmor resolves symlinks. as such, snappy will need to resolve those and add them like you said
<jdstrand> joc_: for the no attributes case. for the with attributes case, that wouldn't be needed (since it is the device cgroup that does the enforcement)
<joc_> jdstrand: thanks for confirmation
<joc_> niemeyer: does that mean it's ok to land that PR as is? and work on jdstrand's suggestion for a version that uses attributes later
<mhall119> is there a snap command to show info about a snap?
<mhall119> something like "snap show foo"?
<jdstrand> joc_: note, for 'as-is' it won't work til you resolve those symlinks
<jdstrand> based on my understanding of what you said is in that dir anyway
<joc_> jdstrand: the zigbeeDevPaths function evaluates the symlinks found in that dir and adds the resolved paths to the apparmor snippet
<jdstrand> ah, cool
<mup> PR snapd#1520 opened: tests: add locale-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1520>
<mhall119> sergiusens: BTW, I'm still waiting on that snapcraft fix to be available for me to try in a cleanbuild, any update on that?
<didrocks> mvo: interesting trick (about the reexec)
<mhall119> "that snapcraft fix" being the pkg-config lookup changes for pantheon-mail
<kyrofa> mhall119, not yet... ran into some CI issues that really delayed our release
<joc_> mvo: so under the new update process, the "snap" exe would still be provided by the deb install but snapd would be updated with ubuntu-core snap?
<cjwatson> dholbach: https://bugs.launchpad.net/bugs/1599786 - do you agree with the position in my follow-up comment at the end?
<mup> Bug #1599786: Run snapcraft update before attempting a snap build <launchpad-buildd:In Progress by cjwatson> <https://launchpad.net/bugs/1599786>
<dholbach> sergiusens, ^
<kyrofa> dholbach, cjwatson agreed
<cjwatson> right, will revert when I get a minute, thanks
<mup> PR snapcraft#640 opened: Setup the FakeParts store for all unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/640>
<kyrofa> cjwatson, worth pointing out that it's not quite released in snapcraft yet though
<kyrofa> cjwatson, any chance you could delay the reversion for a few days? :P
<cjwatson> kyrofa: well, I haven't rolled out the launchpad-buildd change either
<cjwatson> kyrofa: and it would take a few days to do that ...
<kyrofa> cjwatson, ah, scratch that then. We'll be SRUing very soon
<kyrofa> cjwatson, go ahead and toast it
<tsimonq2> hey kyrofa
<cjwatson> right.  I mean, we can do virtual-builder-only rollouts just by getting IS to copy to a PPA, so it's not *that* hard, but I wouldn't want to do it late on a Friday
<kyrofa> Indeed
<kyrofa> Hey tsimonq2 :)
<zyga> joc_: both snap and snapd would come from snaps
<zyga> joc_: they both check and reexec the more up-to-date version
<joc_> zyga: ok just checking, only snapd was mentioned :)
<tsimonq2> kyrofa: I'm working hard on getting that coverage good to go :)
<tsimonq2> kyrofa: I have everything but a checksum from a file and from a remote URL: https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L129
<kyrofa> zyga, speaking of that, do you have any thoughts on bug #1599620?
<mup> Bug #1599620: SNAP_REEXEC doesn't cover snap-exec <snapd (Ubuntu):New> <https://launchpad.net/bugs/1599620>
<mup> PR snapcraft#641 opened: yield the correct exception when retries are out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/641>
<kyrofa> tsimonq2, make sure you have an invalid checksum as well
<tsimonq2> kyrofa: yep, covered
<tsimonq2> kyrofa: I'm getting close ;)
<kyrofa> tsimonq2, the format, I mean
<kyrofa> tsimonq2, https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L154
<kyrofa> tsimonq2, nice work!
<tsimonq2> kyrofa: that's weird because I have https://github.com/snapcore/snapcraft/pull/619/files#diff-3ce6f0422479e72d9db0860efb0e7b42R238
<mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<kyrofa> tsimonq2, that's not testing the format, that's just an incorrect checksum. Also a good test, but not the same
<zyga> kyrofa: looking
<kyrofa> tsimonq2, you need to have a checksum that doesn't match the _format_ of any others
<mup> PR snapcraft#640 closed: Setup the FakeParts store for all unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/640>
<tsimonq2> kyrofa: ohhh okay
<ogra_> mvo, http://paste.ubuntu.com/18797420/ ... classic delta ;) ... (adds 5MB to the core snap)
<tsimonq2> kyrofa: yeah I added that as sort of a "just in case" but I see
<zyga> kyrofa: ah, I recall this issue now
<zyga> kyrofa: so I think we should have a way to test snap-exec for sure
<zyga> kyrofa: not sure if the environment variable is the way to go here
<kyrofa> tsimonq2, if it's behavior you want to preserve (i.e. if it SHOULD work that way) you should cover it in a test so it can't regress
<kyrofa> zyga, indeed. I had to use overlayfs just to test my dev version :P
<zyga> kyrofa: I'd have to get more familiar with the current flow of events there
<zyga> kyrofa: yeah, it's annoying, we had do to something similarly odd to test snap-confine
<kyrofa> Yeah... really rough
<zyga> kyrofa: I think that snap-exec is something we'd run from snap-confine, correct?
<tsimonq2> kyrofa: it would be good for that not to regress... :)
<zyga> kyrofa: if so, perhaps we could allow snap-confine to be built in test mode where this is divertable
<zyga> kyrofa: otherwise I bet it would be a security risk
<kyrofa> zyga, well, snap run invokes snap-confine requesting it to run snap-exec.... so not really
<kyrofa> zyga, but kinda :P
<zyga> kyrofa: the way I understand the flow is that we planned to skip the request so that snap-confine *always* ran snap-exec
<kyrofa> zyga, that may be the final intention. mvo would need to clarify that. It's not the way it works currently
<zyga> so that when you ask snap confine to do something it will never let you do that but run code under user's control
<zyga> kyrofa: that's right
<zyga> kyrofa: this was a phased upgrade process, we didn't implement it all the way
<kyrofa> zyga, sounds about right
<zyga> kyrofa: as long as there's an agreed plan and we all know it I'm sure we can figure out how to safely test snap-exec
<kyrofa> zyga, very good. I guess I wanted to make sure someone knew about that bug so we could keep it in the back of our minds
<zyga> kyrofa: I remember you mentioning this already; I was actually preparing for the switch more or less
<zyga> kyrofa: with the change to snap-confine testing so that we can drop the old tests/ and use new unit tests and spread tests
<kyrofa> zyga, indeed, I tried to mention it a few times but got no love :P
<zyga> kyrofa: because I knew we won't be able to run arbitrary payload with arbitrary confinement soon
<kyrofa> Nice
<tsimonq2> hey kyrofa, can I please get a bit of help?
<kyrofa> tsimonq2, sure, what's up?
<tsimonq2> kyrofa: I'll push my code in like 30 secs, then I'll explain
<tsimonq2> pushed
<tsimonq2> okay, I'm expecting it to fail Travis BTW
<tsimonq2> kyrofa: in my code I want to call the source_checksum function within the source_checksum_determine_type function
<tsimonq2> kyrofa: the problem is, when I use self, it complains about not being in the TestTar and TestZip classes
<tsimonq2> kyrofa: but I need a variable from source_checksum_determine type to pass to source_checksum
<tsimonq2> kyrofa: (this is all in snapcraft/internal/sources.py )
<tsimonq2> kyrofa: been working at this for an hour, trying different things, but it seems obvious
<mup> PR snapcraft#641 closed: yield the correct exception when retries are out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/641>
<mvo> ogra_: oh, nice
<mvo> ogra_: is that available in edge now? thats cool
<mvo> kyrofa: not sure I have all the context - snap run runs snap-confine and that runs snap-exec currently, in the future probably snap-confine will run snap-exec automatically but not yet because we need to transition to this first
<kyrofa> mvo, very good, that's what we thought
<mvo> kyrofa: cool
<tsimonq2> kyrofa: so I don't know if you have any thoughts on my PR? :)
<mvo> ogra_: really cool! and just 5mb because we skip on the man-pages I assuem (which is fine, just curious)
<mvo> ogra_: is that in the latest  images? if so, I will be excited to bring back classic on monday :)
<kyrofa> tsimonq2, sorry, on the phone... my move is suddenly going up in flames
<tsimonq2> kyrofa: oh okay :)
<ogra_> mvo, yeah, i still need to quieten the script a bit, but essentially it is done now
<ogra_> mvo, it is in the latest cdimage snaps, we'll need to push them to the store eventually
<ogra_> (there might also be more cleanup needed, i think the dpkg status file lists stuff we removed binaries from, but it is good enough for a start)
<kyrofa> tsimonq2, okay, I'm back now. uhaul will be the death of me
<mvo> ogra_: very nice, I will play with it monday and start with re-adding classic, this is huge, thank you!
<ogra_> awesome ... :)
<ogra_> and sorry it took so long (after all it was not really much code, but so much inspection work)
<mvo> ogra_: no worries, if we can manage to make it work before the sprint (and I think we can) thats is good enough for me
<ogra_> we definitely can
<mvo> cool
<mvo> ogra_: I call it a day, lets talk more later
 * mvo waves
<tsimonq2> kyrofa: heh, good luck with that :)
<kyrofa> tsimonq2, my units pass...
<kyrofa> tsimonq2, (for your branch)
<kyrofa> tsimonq2, how do I reproduce the issue you're seeing?
<tsimonq2> oh really?
<tsimonq2> wait yeah
<tsimonq2> weird, it should have failed lol
<tsimonq2> but I guess it didn't
<tsimonq2> which means it's my machine! \o/
<tsimonq2> kyrofa: so, can you confirm my next steps?
<tsimonq2>  - Remote URL checksum
<tsimonq2>  - Invalid checksum
<tsimonq2> kyrofa: that's it maybe?
<tsimonq2> wait this is weird... https://coveralls.io/builds/6919217/source?filename=snapcraft%2Finternal%2Fsources.py#L134
<tsimonq2> so it never does the file thing?
<mup> PR snapcraft#642 opened: Make maven plugin honour https_proxy and proxy authentication <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/642>
 * tsimonq2 facepalms
<tsimonq2> I NEVER COMMITED!
<tsimonq2> kyrofa: *now* everything should break and it should be as described
<niemeyer> joc_: It should at least do what I suggested in terms of using apparmor rather than globbing the FS at connection time
<niemeyer> joc_: But it doesn't look like implementing what jdstrand suggested would be hard either
<kyrofa> tsimonq2, heh
<niemeyer> Why not just doing it quickly rather than postponing and risking having it like that for a long time?
<tsimonq2> kyrofa: but does my checklist look good then?
<kyrofa> tsimonq2, for units yeah that sounds about right
<tsimonq2> kyrofa: anything else I might have to do?
<kyrofa> tsimonq2, I've not reviewed it completely, so not that I know of but that doesn't mean "no" ;)
<tsimonq2> kyrofa: alright :)
<mcphail> When can we expect updating snaps to use binary deltas instead of downloading full packages? Is it on the horizon?
<kyrofa> tsimonq2, do you know the difference between instance and class methods?
<tsimonq2> kyrofa: vaguely, please refresh
<kyrofa> tsimonq2, an instance method operates upon a specific method, mutates it in some way or at least utilizes information specific to that instance
<kyrofa> tsimonq2, whereas class methods are not specific to instances-- they're available on the class itself without requiring an instantiation
<tsimonq2> kyrofa: oh okay
<kyrofa> tsimonq2, note that the functions you've written for checking the format etc. are not specific to the class upon which it's implemented at all
<kyrofa> tsimonq2, does that make sense?
<tsimonq2> kyrofa: I see, so do I need to call the specific class along with the function?
<kyrofa> tsimonq2, with what you've written, a fix for test_non_matching_checksum is this: http://pastebin.ubuntu.com/18803040/
<kyrofa> tsimonq2, however, notice how I have to instantiate a zip class just to check the checksum
<kyrofa> tsimonq2, well, that's not specific to zip. It's not specific to any source
<kyrofa> tsimonq2, so I suggest a small refactor-- pull those functions out of any class and implement them standalone
<tsimonq2> kyrofa: what functions, in the tests or in the code for it?
<kyrofa> tsimonq2, the code for them
<kyrofa> tsimonq2, they shouldn't be in FileBase
<tsimonq2> kyrofa: so I need to pull out of FileBase and not put it in any other class, you're saying?
<kyrofa> tsimonq2, exactly
<kyrofa> tsimonq2, then you can test them directly without needing to instantiate any classes
<tsimonq2> kyrofa: cool, thanks, I can work with that :)
<mup> PR snapcraft#643 opened: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643>
<kyrofa> tsimonq2, typically when designing an API like this, you go through a decision-making process. You have four-ish options: do you make this function a public instance method, a private instance method, a class method, or standalone?
<kyrofa> tsimonq2, you have to ask yourself a number of questions when determining the answer to that question
<tsimonq2> kyrofa: welp, snapcraft#643 seems to say that my PR's not getting in
<mup> PR snapcraft#643: Release debian/changelog for 2.12.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/643>
<kyrofa> tsimonq2, first you decide instance/non-instance. You ask "Is my function really specific to this class? Does it require access to its member variables?"
<kyrofa> tsimonq2, not into this release anyway. You can hit the next one :)
<tsimonq2> kyrofa: oh okay :)
<tsimonq2> kyrofa: I'm reading what you're saying ;)
<kyrofa> tsimonq2, if the answer is no, then you have to decide class method versus standalone. You'd ask "is this method still do something specific to this class? To subclasses need to be able to override it?"
<kyrofa> tsimonq2, if the answer is no, then you prefer standalone functions. They're easy to test and easy to reuse
<tsimonq2> kyrofa: I see, makes sense
<kyrofa> tsimonq2, so typically, prefer standalone functions if it makes sense to implement things that way. It leads to a more modular and testable design
<kyrofa> tsimonq2, applying that logic to your checksum functions, let's ask: "are they really specific to that given source? Does it require access to member variables?"
<tsimonq2> kyrofa: I see, and with something like this, it's probably good to be a standalone :)
<tsimonq2> yeah
<tsimonq2> they aren't source-specific
<kyrofa> tsimonq2, right. They don't meet the test for class methods either
<tsimonq2> yeah
<kyrofa> Anyway, that's my software spew for today :)
<kyrofa> tsimonq2, one more thing: if you have a class instance and you want to call a method on it, even a method inherited from a parent class, just call self.method(), not MyParentClass.method(self)
<tsimonq2> kyrofa: it's useful, I learned something new :)
<tsimonq2> kyrofa: oh okay
<tsimonq2> hey kyrofa
<tsimonq2> kyrofa: one more thing
<tsimonq2> wait hm
<kyrofa> tsimonq2, hmm?
<tsimonq2> kyrofa: yeah, so I have the teo classes, right? I still can't call one from another and I still can't get the variable from one to another
<kyrofa> tsimonq2, I'm missing context here. Two classes-- zip and tar? One variable are you trying to get from one to the other?
<kyrofa> s/One/What/
<tsimonq2> kyrofa: check_checksum_determine_format and check_checksum
<kyrofa> tsimonq2, those are what you're making standalone now, right?
<tsimonq2> kyrofa: I need source_checksum and checkfile to hop from one to the other
<tsimonq2> kyrofa: yes, pushed
<kyrofa> tsimonq2, standalone functions have no "self," that's for instance methods
<tsimonq2> kyrofa: so how do I call it then
<tsimonq2> s/then/then?/
<kyrofa> tsimonq2, just... directly. Like `check_checksum()`
<kyrofa> No self at all
<tsimonq2> oh!
<tsimonq2> ok
<tsimonq2> let me see
<tsimonq2> kyrofa: well I think that fixed it, I don't know, because I have the following: def check_checksum_determine_format(self, source_checksum, checkfile): and I only pass source_checksum and checkfile, do I really need to pass self as well? what could that do?
<tsimonq2> (I only pass those two variables in my tests)
<kyrofa> tsimonq2, no, no self
<kyrofa> tsimonq2, remove that as a param
<kyrofa> tsimonq2, again, just for instance methods
<kyrofa> tsimonq2, which these are no longer
<tsimonq2> oh that's right! sorry, that was obvious :P
<mup> PR snapd#1518 closed: tests: add -y flag to apt autoremove command in unity task restore <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1518>
<mhall119> is there a list of available interfaces for a snap to use?
<niemeyer> mhall119: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<mup> PR snapd#1476 closed: overlord: make SyncBoot work again <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1476>
<mhall119> thanks niemeyer
<mhall119> is is necessary to include the gsettings plug in order for an app to access just it's own settings?
<mup> PR snapd#1521 opened: many: removed authenticator, store gets a user instead <Created by matiasb> <https://github.com/snapcore/snapd/pull/1521>
<tsimonq2> mhall119: or you could just do snap interfaces
<mhall119> tsimonq2: I did, but I wasn't sure if that showed all of the ones in snapd, or just the ones with a slot or plug installed
<tsimonq2> mhall119: mine has ones with no snaps in them
<mhall119> thanks tsimonq2
<tsimonq2> no problem mhall119 :)
<mup> Bug #1592714 changed: snapd-interface application problem with systry icon <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592714>
<cyphermox> where can I get the files I need to do porting; for instance the gadget and os snaps?
<kyrofa> mhall119, I believe `snap interfaces` will show all interfaces that have slots on the system
<kyrofa> mhall119, e.g. snapd may support more interfaces than are available on the given system
<tsimonq2> kyrofa: that's what I said :)
<tsimonq2> kyrofa: hello btw :)
<kyrofa> tsimonq2, well, you said you see ones with no _plugs_ in them, no?
<tsimonq2> kyrofa: yes
<tsimonq2> $ snap interfaces | pastebinit
<tsimonq2> http://paste.ubuntu.com/18823922/
<kyrofa> tsimonq2, I'm saying `snap interfaces` will not show all interfaces
<kyrofa> tsimonq2, just the ones with slots
<tsimonq2> kyrofa: no it won't, see my pastebin
<tsimonq2> :cups-control        -
<tsimonq2> :firewall-control    -
<tsimonq2> :gsettings           -
<tsimonq2> (for example)
<kyrofa> tsimonq2, those are slots
<kyrofa> tsimonq2, with no corresponding plug
<kyrofa> tsimonq2, I'm saying there's no way to see interfaces with no slots available
<tsimonq2> kyrofa: oh
<kyrofa> tsimonq2, i.e. snapd can support X interface, but if the system has no snaps installed providing the X slot, `snap interfaces` won't show it
<tsimonq2> kyrofa: oh ok
<tsimonq2> kyrofa: huh, for some reason only sha512 checksums work...while I hack on it, is there anything obvious you can point out?
<tsimonq2> oh I'm stupid
<tsimonq2> kyrofa: sorry for all the pings
<mcphail> Is there a way to install snapd on a first-generation raspberry pi running raspian?
<tsimonq2> kyrofa: I think my PR's ready, I'm pretty proud of my first comment :D https://github.com/snapcore/snapcraft/pull/619
<mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
#snappy 2016-07-09
<mup> PR snapcraft#644 opened: Feature/ant plugin test <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/644>
<mup> PR snapcraft#645 opened: If "source: .." do not copy the current directory into itself <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/645>
<mup> Bug #1600271 changed: snap install/remove multiple package names <Snappy:New> <https://launchpad.net/bugs/1600271>
<ogra_> mcphail, that would be quite some effort (getting a snapd for armv5 first ... then have a proper kernel with all security love it needs etc)
<mcphail> ogra_: shame. Have a couple of devices which would benefit from the goodness
<ogra_> well, with zyga pushing snapd into debian you might eventually get an armv5 build there
<mcphail> ogra_: cool. Looking to install nextcloud, and would be great to use the snap
<ogra_> well, ask zyga if he knows if debian provides armel packages
<mcphail> ogra_: isn't the 1st gen armhf?
<ogra_> nope
<mcphail> hmm. I hare ARM
<ogra_> the first get is ARMv6 ... armhf is v7
<ogra_> complain to broadcom for picking an outdated architecture :P
<mcphail> ogra_: ha! I can see them crying into their millions of dollars ;)
<ogra_> yeah, the Pi was a clever move to get rid of stock chips they couldnt sell anymore
<ogra_> (the chip was originally developed for TV settop boxes that got never built)
<mcphail> to be fair, they do make nice media players. But looking to retire my sheevaplug, and a snappy solution would be great
<dz0ny_> ogra_: since you here :) aware of any go based snapcraft package which uses cgo and media subsystem?
<ogra_> nope ... i'm not a big go guy
<dz0ny_> I'am trying to package https://github.com/dz0ny/champ
<dz0ny_> first i treid quemu way on arch, well they disabled quemu :)
<dz0ny_> gg
<dz0ny_> k research then :)
<mup> Bug #1600489 opened: freecad after being installed with snap doesn't exists <Snappy:New> <https://launchpad.net/bugs/1600489>
<mup> PR snapcraft#646 opened: Feature/gradle plugin <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/646>
<bpeak> What is the purpose of the snap folder that is created on $HOME? It follows the format $HOME/snap/package_name/a_number/, but for me those folders are always empty. This is on arch. Does that folder in Ubuntu actually contain files?
<tgm4883> popey: ping
<popey> hm?
<tgm4883> popey: I'm starting to get more free time. I wanted to check in with you on the mythfrontend snap
<popey> not worked much on it, will do next week at snappy sprint
<popey> vacation this week
<tgm4883> ah ok
<tgm4883> I'm looking through the snapcraft.io/create documentation now
<popey> awesome
<teej> Hello.
<popey> look also at snappy playpen on github
<popey> lots of examples
<tgm4883> will do
<teej> I have some questions about what Snap is intended to do. Will Snap replace apt/aptitude?
<popey> feel free to pingnme on telegram if you use it. easier for me when afk
<popey> am popeydc there
<popey> if you have any questions
<teej> popey: For me? Or for tgm4883?
<tgm4883> I'd assume me
<popey> for tgm4883  :) but feel free :)
<tgm4883> teej: IIRC, there is a good discussion about snaps and apt on the latest ubuntu podcast
<popey> also the snappy playpen gitter is good
<tgm4883> and unlike popey, I can be unbiased when I recommend it :)
<popey> heg
<popey> heh*
 * popey goes back to beer, i mean bed
<popey> o/
<tgm4883> where do I alert issues regarding the snapcraft.io website
<tgm4883> since SSL seems to be currently broken, but the 'snapcraft tour' provides an https link
<teej> tgm4883: I'm not sure what that is. Do you mean http://ubuntupodcast.org ?
<tgm4883> teej: yep, that's the one
<teej> tgm4883: Thanks. I'll check it out.
<teej> tgm4883: So I've listened to the podcast but I was unable to find anything on whether Snaps will take over apt/aptitude in the future.
<tgm4883> teej: hmm, I thought they had talked about it. Maybe it was a prior episode. IIRC, snaps don't make sense for all things. For instance, you're not going to put systemd in a snap
<tgm4883> so they should coincide
<Guest_84734> allah is doing
<Guest_84734> sun is not doing Allah is doing
<Guest_84734> moon is not doing Allah is doing
<Guest_84734> stars are not doing Allah is doing
<Guest_84734> planets are not doing Allah is doing
<Guest_84734> galaxies are not doing Allah is doing
<Guest_84734> oceans are not doing Allah is doing
<Guest_84734> mountains are not doing Allah is doing
<Guest_84734> trees are not doing Allah is doing
<Guest_84734> mom is not doing Allah is doing
<Guest_84734> dad is not doing Allah is doing
<Guest_84734> boss is not doing Allah is doing
<Guest_84734> job is not doing Allah is doing
<Guest_84734> dollar is not doing Allah is doing
<Guest_84734> degree is not doing Allah is doing
<Guest_84734> medicine is not doing Allah is doing
<Guest_84734> customers are not doing Allah is doing
<Guest_84734> you can not get a job without the permission of allah
<Guest_84734> you can not get married without the permission of allah
<Guest_84734> nobody can get angry at you without the permission of allah
<Guest_84734> light is not doing Allah is doing
<tgm4883> Working on my first snap of an application, moving from deb packaging (which I didn't do most of the work on). Running into an issue during the "snapcraft" portion of the build, logs indicating that it's trying to install some stuff to /usr/lib (previously it was /usr/local/lib until I specified /usr/lib as a prefix as we do for debian packaging)
<tgm4883> Looking for some pointers on how to resolve that
<tgm4883> I'm going through the snapcraft documentation and started with will cooke's first attempt at this http://paste.ubuntu.com/18923022/
<tgm4883> Some progress, I told it just "usr" and it builds now, however the snap doesn't work and looking in the state directory, it's completely empty. If I dig deep enough into the build directory I can find the binary and launch it and it semi works
<tgm4883> Ok, I think I need to specify INSTALL_ROOT during the make install, but I don't see a way to specify that. What are the "Common plugin keywords"?
#snappy 2016-07-10
<mup> Bug #1600545 opened: cannot pivot_root to the new root filesystem. errmsg: Permision denied <Snappy:New> <https://launchpad.net/bugs/1600545>
<tsimonq2> sergiusens: didn't have a chance to say something earlier, but https://pad.lv/1600504 should be looked at, it's blocking 2.12.1+16.10 from getting out of proposed
<tsimonq2> sergiusens: (I'm pinging you because your name is on the debian/changelog file)
<boghison> Hi! Is it possible to run a shell script to build a snap (i.e. no plugin)?
<mup> PR # closed: snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244,
<mup> snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244
<mup> PR # opened: snapd#1244, snapd#1254, snapd#1299, snapd#1322, snapd#1340, snapd#1391, snapd#1405, snapd#1409, snapd#1432, snapd#1444, snapd#1446, snapd#1450, snapd#1457, snapd#1460, snapd#1486, snapd#1489, snapd#1492, snapd#1493, snapd#1494, snapd#1500, snapd#1501, snapd#1502, snapd#1505,
<mup> snapd#1506, snapd#1507, snapd#1508, snapd#1511, snapd#1512, snapd#1515, snapd#1517, snapd#1519, snapd#1520, snapd#1521
<mup> PR # closed: snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244,
<mup> snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244, snapd#1244
<mup> PR # opened: snapd#1244, snapd#1254, snapd#1299, snapd#1322, snapd#1340, snapd#1391, snapd#1405, snapd#1409, snapd#1432, snapd#1444, snapd#1446, snapd#1450, snapd#1457, snapd#1460, snapd#1486, snapd#1489, snapd#1492, snapd#1493, snapd#1494, snapd#1500, snapd#1501, snapd#1502, snapd#1505,
<mup> snapd#1506, snapd#1507, snapd#1508, snapd#1511, snapd#1512, snapd#1515, snapd#1517, snapd#1519, snapd#1520, snapd#1521
<mup> PR # opened: snapd#1244, snapd#1254, snapd#1299, snapd#1322, snapd#1340, snapd#1391, snapd#1405, snapd#1409, snapd#1432, snapd#1444, snapd#1446, snapd#1450, snapd#1457, snapd#1460, snapd#1486, snapd#1489, snapd#1492, snapd#1493, snapd#1494, snapd#1500, snapd#1501, snapd#1502, snapd#1505,
<mup> snapd#1506, snapd#1507, snapd#1508, snapd#1511, snapd#1512, snapd#1515, snapd#1517, snapd#1519, snapd#1520, snapd#1521
#snappy 2017-07-03
<aaaa_> hello
<aaaa_> what's purpurse this forum?
<aaaa_> are there any live guys?
<mup> PR snapd#3547 closed: snap-seccomp: skip socket() tests on systems that use socketcall() instead of socket() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3547>
<mup> PR snapd#3533 closed: tests: extend find-private test to cover more cases <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3533>
<ogra_> hmpf ...
<ogra_> mouse battery died .. with no warning, nothing ... takes me ten minutes to find new batteries ... when i return to my desktop a warning about my mouse battery being low pops up ... tsk ...
<ogra_> (would really help to have warnings *before* the events happen :P )
<ogra_> popey, what they call "ubuntu-core" is actually some self-bootstrapped classic install... i think the friendlyarm wiki should actually have an image linked for the air ...
<ogra_> looks like http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Air should have something
<ogra_> popey, and here we go ... "NanoPi NEO AIR has an Ampak AP6212 chip, which needs special firmware files" ... http://linux-sunxi.org/FriendlyARM_NanoPi_NEO_%26_AIR
<ogra_> (it is a broadcom device as i suspected (ampak builds chips around broadcom stuff usually)
<mup> PR snapd#3530 closed: cmd/snap: include snap type in notes <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3530>
<mup> PR snapd#3540 closed: overlord/state: Abort() only visits each task once <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3540>
<cjwatson> Could somebody please retry https://travis-ci.org/snapcore/snapd/builds/248376205 ?  I don't think the timeout is the fault of my PR.
<niemeyer> Morning all
<niemeyer> cjwatson: Looking
<cjwatson> ta
<niemeyer> cjwatson: Restarted.. there are MBR errors in the log.. Linode seems to have broken their image feature in the last 10 days or so
<niemeyer> They're investigating
<niemeyer> We'll give them one more week or so, and if they can't get it together we'll move elsewhere
<Chipaca> niemeyer: does that mean we'll have a new backend for spread in about a week? :-)
<Chipaca> niemeyer: how was your trip back, btw?
<niemeyer> Chipaca: Well, it means I'll start working on one in a week :)
<niemeyer> Chipaca: It was as good as it gets :)
<niemeyer> Chipaca: Thanks for asking.. I'd guess yours was even better? :P
<Chipaca> niemeyer: I can't comment
<mup> PR snapcraft#1389 opened: Use newer distro module with no tuple <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1389>
<mvo> niemeyer: hey, i see some lines in linode like "Cannot allocate linode:ubuntu-16.04-64: cannot create Linode disk with ubuntu-16.04-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)" (https://travis-ci.org/snapcore/snapd/builds/249550256#L712). anything we can do about this?
<mvo> niemeyer: also in the same run in line 816: Cannot allocate linode:ubuntu-core-16-64: cannot boot linode:ubuntu-core-16-64 (Spread-64): cannot Direct Disk boot a disk with no MBR: - do we need to update a config there maybe?
<niemeyer> mvo: What machines are you seeing this in? I'll have a look
<niemeyer> mvo: The second issue is known and has been reported late last week
<mvo> niemeyer: spread-33, spread-70, spread-52 seems to be candidates
<niemeyer> mvo: Thanks, I'll do a complete pass
<niemeyer> mvo: These are likely follow ups from the primary issue of thawing images being broken
<mvo> niemeyer: thank you!
<niemeyer> mvo: np, I could find a single machine where there was space issues, Spread-14
<mvo> niemeyer: that matches the log its right before the error message
<mvo> niemeyer: shall I restart?
<niemeyer> mvo: Ok, we're good then, thanks for the note
<niemeyer> mvo: Yeah.. although note that I think Linode is still broken in terms of image thawing, so it may be a bit frustrating still
<niemeyer> mvo: Please let me know if you see other/unknown issues
<mvo> niemeyer: thank you, will do
<mup> Bug #1702095 opened: snap enable removes complain for daemons <Snappy:New> <https://launchpad.net/bugs/1702095>
 * pedronis break
<mup> PR snapcraft#1369 closed: Handle I/O errors in os.link (LP: #1689956) <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1369>
<mup> PR snapd#3549 opened: many: epose services commands for snap services <Created by chipaca> <https://github.com/snapcore/snapd/pull/3549>
<Chipaca> anybody looking to review that ^ please let me know if you'd rather I split it into individual PRs (or maybe 1 for osutil&systemd changes, one for daemon&cleint&cmd/snap changes)
<Chipaca> each commit stands on its own (and on those coming before it)
<pedronis> it is bigly
<mup> PR snapd#3550 opened: update firewall-control to allow {arp,ip,ip6}tables to control bridged vlan/ppoe-tagged traffic <Created by coreycb> <https://github.com/snapcore/snapd/pull/3550>
<Chipaca> pedronis: ok, adding an intermediate PR with osutil&systemd, let's see how that split works
<mup> PR snapd#3551 opened: systemd, osutil: rework systemd logs in preparation for services commands <Created by chipaca> <https://github.com/snapcore/snapd/pull/3551>
<Chipaca> pedronis: ^ there
<Chipaca> not sure it helped much :-)
<pedronis> Chipaca: it didn't :)
<pedronis> so maybe up to daemon and client and cmd/snap ?
<pedronis> (IÂ don't know how big each checkin is)
<Chipaca> pedronis: the commits are separate, and would be the PRs
<pedronis> anyway, maybe ignore me, not sure I'm going to look at it today
<Chipaca> pedronis: daemon: +625 â7
<Chipaca> pedronis: client: +335 â0
<Chipaca> pedronis: cmd/snap: +218 â0
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> ok, so 3 PRs would be reasonable
<pedronis> or 2 PRS
<Chipaca> pedronis: osutil+systemd, daemon, cmd+client?
<pedronis> yes
<Chipaca> on my way
<mup> PR snapd#3552 opened: daemon: implement service commands <Created by chipaca> <https://github.com/snapcore/snapd/pull/3552>
<mvo> ogra_: are the uboot version for the pi2/pi3 snaps similar/the-same or different? the timestamps indicate similar versions, is that the case?
<ogra_> yeah, similar (same tag/branch) but different builds
<mvo> ogra_: cool, thank you - same tag/branch is all the info I need
<ogra_> i'm planning to move them all to "build directly from upstream source" soon ... then you can just check the branch version in snapcraft.yaml in the future
<mvo> ta
<ogra_> (should both be v2017.01)
<Chipaca> niemeyer: http://i.imgur.com/gPbCUdF.png
<mvo> Chipaca: hahaha
<Chipaca> mvo: i take it i wasn't too subtle then :-D
<Chipaca> (this is via https://dev.to/rly fwiw)
<mvo> Chipaca: great stuff
<niemeyer> Chipaca: We may be about to write the last chapter :)
<mup> PR snapcraft#1377 closed: kernel plugin: add default targets per powerpc, ppc64el and s390x <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1377>
<mup> PR snapcraft#1390 opened: meta: bash completion support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1390>
 * Chipaca hugs sergiusens 
<Chipaca> sergiusens: we were talking about that the other day while I was walking across London, and I don't know if we finished that conversation
<sergiusens> Chipaca: I was walking as well ;-)
<sergiusens> fwiw, I think this needs to be automatic, also, I searched for complete.sh in the defined locations from your blog post and could not find it
<Chipaca> sergiusens: the release of snapd that has that has not reached ubuntu yet
<Chipaca> sergiusens: which is why i haven't worked on making it more automatic
<sergiusens> Chipaca: hmm, I was told it had.. :-(
<sergiusens> stgraber: fyi ^
<Chipaca> sergiusens: but you'll probably have it in /snap/core/current/usr/lib/snapd/complete.sh
<sergiusens> ls: cannot access '/snap/core/current/usr/lib/snapd/complete.sh': No such file or directory
<sergiusens> installed:          16-2 (1689) 83MB - (latest/stable)
<Chipaca> sergiusens: ah well, at least the world is consistent
<Chipaca> sergiusens: (i assumed you were tracking something newer than stable, but it makes sense for you)
<Chipaca> sergiusens: in any case, we're working on the next release (yes it's delayed for a number of good reasons), should be in stable soon and then i can move on to the next step of the evil^Wmaster plan
<stgraber> Chipaca: oh, I was told 2.26 had it, it's even in the announcement
<Chipaca> stgraber: I do believe 2.26 does have it
<Chipaca> stgraber: yep, confirmed 2.26 (at least as in artful) does have it
<Chipaca> sergiusens: ^ fwiw
<sergiusens> Chipaca: hmm, I am on zesty, maybe I should move...
<bdx> hello all
<bdx> I'm working on a snap for a rails app
<bdx> I'm hitting two issues, 1) I need to symlink a yml file into the app config dir
<bdx> 2) I can't seem to access $SNAP_COMMON, $SNAP_USER_COMMON from with the install srcipt for some reason
<bdx> is there a recommended way of linking files into the versioned snap dir?
<bdx> I'm working with this http://paste.ubuntu.com/25012754/
<bdx> lines 43-47 depict where I'm having the issue
<bdx> the application.yml needs to exist so that assets:precompile can run
<bdx> so I keep an empty string filled application.yml with the application code
<bdx> that the snap uses to run assets:precompile
<bdx> in the install step
<bdx> following that, I need to remove that application.yml and point the app to an application.yml that can be configured by the user
<bdx> on a per deploy basis
<bdx> one that lives outside of the versioned snap dir
<bdx> I cant seem to access the $SNAP_COMMON and $SNAP_USER_COMMON (where I feel like this file should go) from the install scriptlet
<bdx> so I decided to try moving it to /srv/ and symlink from there to the versioned application dir
<bdx> this worked to some degree
<bdx> the symlink exists from the versioned snap dir to /srv/prm/config
<bdx> but the rails app it self doesnt seem to be able to access it ... even though the symlink exists  where the application.yml shoudl be in the config/
<bdx> one more thing
<bdx> how can I make a configurable value for RAILS_ENV
<bdx> such that the rails env could be set on a per install basis?
<mup> PR snapd#3553 opened: interfaces: enable access to bridge settings <Created by coreycb> <https://github.com/snapcore/snapd/pull/3553>
<ogra_> bdx, your chances to catch some snapcraft devs are higher on https://rocket.ubuntu.com in the #snapcraft channel
<bdx> ogra_: thx
<mup> PR snapcraft#1372 closed: cli: Containerbuild clean <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1372>
<mup> PR snapcraft#1385 closed: lxd: Don't assume user ID to 1000 for raw.idmap <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1385>
<mup> PR snapd#3554 opened: client: wrap services calls <Created by chipaca> <https://github.com/snapcore/snapd/pull/3554>
#snappy 2017-07-04
<zyga> o/
 * zyga looks outside at the rainy day
 * zyga spends the morning on email and PRs
<mvo> zyga: I updated 3512 - iirc you asked about this last week
<zyga> mvo: looking
<zyga> mvo: I read that, thanks for updating it, I'm worried that tests failed
<zyga> mvo: (not related to branch, linode/travis timeouts)
<mvo> zyga: yes, all tests are currently broken due to linode issues
<mvo> zyga: have you seen the last few posts in https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/28 ? it looks like for thomi the apparmor profile was not correctly loaded for snap-confine. I wonder if this is related to the issues we saw during the sprint when there also was a profile that was supposedly loaded except it was not during one of the spread tests. do you remember the issue?
<zyga> mvo: yes, I do, looking at the forum
<zyga> looks like apparmor regression to me
<zyga> mvo: but let me look at the data that fgimenez collected to be sure
<mvo> zyga: yeah, I was thinking the same
<zyga> mvo: we collected data before and after a profile load
<mvo> zyga: do you remember what test it was that failed?
<zyga> mvo: home writer one
<fgimenez> zyga: mvo hey, all the info from the issue last week is in bug #1701494
<mup> Bug #1701494: apparmor profiles are eventually not properly generated <snapd:New> <https://launchpad.net/bugs/1701494>
<zyga> https://bugs.launchpad.net/snapd/+bug/1701494
<zyga> ah :D
 * zyga just found the reference
<mvo> fgimenez: nice, thank you
<zyga> mvo: ha
<zyga> very interesting!!!
<mvo> fgimenez: I changed the title, it was correctly generated iirc, it was valid on disk but not the right one was loaded(?)
<zyga> mvo: the profiles have identical hashes
<mvo> zyga: tell me more
<zyga> and everything else
<mvo> zyga: wuut?
<zyga> *except* for raw_data
<mvo> ohh
<zyga> so it's not the same but only in one of the files
<zyga> so very buggy on 1st look
<zyga> hashes the same
<zyga> but not the same raw_data
<mvo> zyga: yeah, I understood, was just puzzled :)
<zyga> oh no :(
<zyga> sorry, premature happiness
<zyga> tar didn't copy data out of those files
<zyga> they are size 0
<zyga> bummer
<zyga> we only have raw data because that one was (for whatever reason) copied
<zyga> fgimenez: can you run that loop on pi again please
<zyga> but this time collect the data with cp and then tar it
<zyga> sysfs can be wonky for tar
<fgimenez> zyga: sure on it
<zyga> mvo: but one interesting observation
<zyga> mvo: this happened on pi2 with a unchanging kernel
<zyga> mvo: so the only (likely) reason is userspace changes
<mvo> zyga: oh, good point.
<zyga> the files have largely different content
<mvo> zyga: the last apparmor update is ages old though
<zyga> there are some blobs here and there that are the same (out of 50KB maybe)
<zyga> but it's just something else
<zyga> mvo: another possibility is caching issue or cache corrpution
<mvo> zyga: yeah, I was wondering about this, but thomi got this on a classic system
<mvo> zyga: but then, maybe its unreleated
<zyga> mvo: maybe it's an old, existing bug that just (for whatever random reason) happened now more often
<zyga> mvo: I could add a patch to snapd that looks at that data and perhaps records the compiled binary somehow
<zyga> mvo: we could even load it >1 and ensure it is stable
<zyga> mvo: not sure if you think this is worth pursuing
<mvo> zyga: not sure either, maybe we talk first with jj if he has a theory
<zyga> mvo: yeah, good idea
<zyga> mvo: I'll also check the kernel sources and docs to understand why there are two hash files and what they represent
 * zyga wonders why apparmor has its own /dev/null file
 * zyga reboots and will be back shortly
<mup> PR snapd#3555 opened: assserts,overlord/assertstate: test we don't accept chains of assertions founded on a self-signed key coming externally <Created by pedronis> <https://github.com/snapcore/snapd/pull/3555>
<zyga> re
<ogra_> mvo, urgh ... i fired up my pi3 after the sprint yesterday and it got a core update ... now i just installed a new snap and get this:
<ogra_> ogra@pi3:~$ sudo psplash.psplash-write hello
<ogra_> /var/lib/snapd not root-owned 1000:1000
<ogra_> ogra@pi3:~$ snap list core
<ogra_> Name  Version    Rev   Developer  Notes
<ogra_> core  16-2.26.7  2321  canonical  -
<ogra_> ogra@pi3:~$
<ogra_> mvo, i'm relatively sure this image used to work before without issues
<ogra_> oh,. wait, the code had changed ... but shouldnt i have the fixed core ?
<ogra_> ah, wait, could be that i messed around with it
<ogra_> ignore that
<mvo> ogra_: this is edge, thats "ok"
<mvo> ogra_: ish
<mvo> ogra_: please refresh to beta
<mvo> ogra_: actually, wait a sec
<mvo> ogra_: please try "sudo snap refresh --beta core" and reboot, then things should be ok again
<mvo> ogra_: edge is broken right now, fix is scheduled for tomorrow morning
<Chipaca> spread and travis and linode all hate me
<Chipaca> i think i'm going to go shopping
<mvo> Chipaca: !!!
<mvo> Chipaca: yeah, its in deep hate mode, looks like today is the day for mail and forum (and code reviews :)
<mvo> Chipaca: I think its actually linode that is deep in unhappy land, the rest appears to be fine
<mvo> (not that this helps in any way)
<Chipaca> I'm an equal-hate complainer
<pstolowski> damn you json
 * pstolowski grumbles about json decoding gotchas
<zyga> pstolowski: hmm?
<zyga> Chipaca: don't worry, could be worse
<pstolowski> zyga, by default json.Unmarshall treats numbers as float64, which gives this https://forum.snapcraft.io/t/snap-set-digits-as-string/1099/3
<pstolowski> zyga, to workaround this, you create a Decoder and do UseNumber() on it
<pstolowski> zyga, it works nicely for number then. except it breaks on ip addresses :/
<Chipaca> zyga: Â¬p â Â¬q, or something
<zyga> pstolowski: aha, indeed
 * zyga hugs Chipaca and looks at the pouring rain outside
<pstolowski> zyga, it wants to treat "1.2.3.4" as a float, and fails
<zyga> pstolowski: but json *is* typed, so just set this as string
<zyga> pstolowski: I think that lacking a schema we should treat everything as a string
<pstolowski> zyga, well, yeah, problem is we have very little control over that in snapctl arg parsing, you can basically pass arbitrary json to it via commandline and if it parses, it's opaque to us
<pedronis> pstolowski: well,  I don't think it's a JSONÂ problem,   either we just tell people snapctl/snap set take json or we do something more DWIM but then we need to explain the details
<pedronis> JSONÂ is not yaml, it doesn't have logic to guess if something is a string or not
<pstolowski> pedronis, thank you!!!
<pstolowski> pedronis, you made me realize where the problem leis
<pstolowski> *lies
<pstolowski> pedronis, ip address needs to be quoted, that's it
<pstolowski> pedronis, all tests passing now
<pstolowski> including the new ones I added for integers
<pstolowski> all good it seems
<zyga> fgimenez: hey, any luck reproducing that issue?
<fgimenez> zyga: nothing after 22 executions, i'll keep trying, last week it appeared after 17 and 15 runs, let's see
<zyga> fgimenez: thank you!
<zyga> I'm working on a tool that would help us understand what is going on if we have the data
 * ogra_ hugs sergiusens for updating telegram ... finally no more update notifications :)
<sergiusens> ogra_: you are welcome
<sergiusens> niemeyer or mvo can you take a quick look at https://github.com/snapcore/snapcraft/pull/1373 which uses an undocumented attr on https://forum.snapcraft.io/t/the-snap-format/698/2?u=sergiusens or https://snapcraft.io/docs/snaps/metadata
<mup> PR snapcraft#1373: snapcraft.yaml: add support for reload-command and completer directives <Created by bloodearnest> <https://github.com/snapcore/snapcraft/pull/1373>
<Son_Goku> zyga, is this the pull with all the stuff? http://lkml.iu.edu/hypermail/linux/kernel/1707.0/01380.html
<Son_Goku> it doesn't sound like it...
<ogra_> Son_Goku, what are you doing here, shouldnt you celebrate your brexit today ?
<Son_Goku> haha
<ogra_> :)
<zyga> Son_Goku: it's not everything but this is most of it
<zyga> ogra_: brexit in US?
<ogra_> zyga, *of* the US ;)
 * zyga still doesn't get it
<Son_Goku> July 4 is Independence Day
<zyga> Son_Goku: I'm in the kernel land all day today, I saw some things are not around yet
<zyga> Son_Goku: like signal mediation
<zyga> Son_Goku: ah, I get the brexit now :)
<Son_Goku> it was when the Declaration of Independence was signed in 1776
 * zyga does high-five on Son_Goku 
<zyga> Son_Goku: imagine the horrors if US was about to exit the EU if it were still a part of the british empire ;D
<Son_Goku> heh
<Son_Goku> well, the US has the benefit of potentially being somewhat self sufficient
<zyga> Son_Goku: and texas would be all pro-independence to stay in EU ;-)
<Son_Goku> not many countries can do that anymore
<Son_Goku> the UK is a federation of countries
<Son_Goku> so it's already weird
<ogra_> zyga, nah, texs would form their own coalition with bavaria
<zyga> Son_Goku: except north korea :-)
<ogra_> *texas
 * zyga thinks this is the perfect time for a cup of coffee and another dive into DFA land of apparmor
<ogra_> lederhosen with gun pockets and stetson ...
 * zyga goes for lunch
<pedronis> mvo: what's the state of snapd#3512  , do we need it for the release? or it's 2.27 related?
<mup> PR snapd#3512: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <https://github.com/snapcore/snapd/pull/3512>
<mvo> pedronis: its fine for 2.27
<mvo> pedronis: the snap-seccomp code has its own version of this, this is a generalization
<ogra_> niemeyer, whee ! our frist spam on the forum (do we have a badge for that ? :P )
<ogra_> (laste entry in https://forum.snapcraft.io/t/snapd-in-docker/177/14 )
<pedronis> mvo: I marked it for 2.27 for clarity
<zyga> pedronis: I think we want it ASAP
<zyga> mvo: without that we use wrong tools
<pedronis> heh
<pedronis> me is confused
<pedronis> but will let you sort if out
<zyga> mvo: I'd add it to 2.26
<mvo> zyga: hm, will it cleanly apply to 2.26? if not we need to backport it
<mvo> zyga: hm, hm, what will be the consequence if 3512 is missing from 2.26? slightly worried that it may not make it until tomorrow given how unhappy linode is
<niemeyer> ogra_: Thanks, it's actually not the first one
<ogra_> well, the first one i see :)
<niemeyer> ogra_: You can flag such posts, so they quickly get sorted
<niemeyer> If enough people flag it, it gets away by itself
<ogra_> ah, k ... i wasnt sure if the flagging does anything apart from notifying me about changes
<ogra_> the tooltop isnt so clear
<ogra_> *tooltip
<ogra_> ( "privately ... private" -> should perhaps instead talk about "notifying ... admin" or some such to be more clear)
<zyga> mvo: I think it will cause wrong tools to be used during core migration
<zyga> mvo: if you want I can do that (backport)
<mvo> zyga: if you can, that would be lovely
<Chipaca> niemeyer: you around?
<Chipaca> niemeyer: the MBR issue, as far as I can tell, is always on ubuntu-core-16-64. I thought it was spread amongst different ones but at least right now (and since yesterday) it doesn't seem to be
<Chipaca> niemeyer: this does point to a corrupt image; can you regenerate it?
 * Chipaca ~> cuppa tea
<niemeyer> Chipaca: I think it's always on it, actually
<niemeyer> Chipaca: It happens on the "Direct Disk" Linodes, and we only use that to handle core since we need to reboot into the disk without using grub
<Chipaca> niemeyer: ah. I guess http://pastebin.ubuntu.com/25019305/ isn't that interesting then :-)
<niemeyer> Chipaca: Probably not :)
<niemeyer> Let me ping Linode again to see what those guys are up to
<Chipaca> niemeyer: https://giphy.com/embed/11BbGyhVmk4iLS
<niemeyer> Yeah, pretty much
<Chipaca> brb, reboot
<zyga> mvo: I have that backport, running spread locally now
<zyga> mvo: not sure if it will pass yet
<zyga> mvo: I'll push when it is green locally
<mvo> zyga: thank you very much
<zyga> mvo: so far so good
<mvo> zyga: keep me posted (tomorrow :)
<jjohansen> zyga: did you ever file a bug for the issue around entering and exiting namespaces?
<Son_Goku> jjohansen: hey
<Son_Goku> I saw the news about the apparmor stuff making its way into 4.13
<Son_Goku> what's left in re snappy apparmor?
<jjohansen> Son_Goku: I split out any mediation that did exist up stream already. The update was already huge, and I decided if it wasn't all going to make it in it was best to get the base in, and update the existing upstream mediation
<Son_Goku> could we see the remaining bits make it in for 4.14?
<jjohansen> upstream is missing mount controls, network controls
<jjohansen> Son_Goku: that is the goal
<Son_Goku> that's the kernel that we're targeting for Mageia
<Son_Goku> err, Mageia 7
<jjohansen> yeah, I think everyone is targeting 4.14 as its going to be the next stable kernel
<zyga-suse> jjohansen: hey
<zyga-suse> jjohansen: not yet, I was researching another bug today
<zyga-suse> jjohansen: I have a question about raw_data in sysfs, is there a tool to load and display that?
<sergiusens> niemeyer: reping about https://github.com/snapcore/snapcraft/pull/1373
<mup> PR snapcraft#1373: snapcraft.yaml: add support for reload-command and completer directives <Created by bloodearnest> <https://github.com/snapcore/snapcraft/pull/1373>
<jjohansen> zyga-suse: what do you mean by load and display? Do you mean to reverse the policy compile and show it as text?
<jjohansen> there is the start of a tool, and I can do some of it, but the really interesting bits will just come out as a dfa state machine, still better than nothing
<jjohansen> I'll fiddle with it and see if I can't get it pushed some where
<zyga-suse> jjohansen: show the internal format
<zyga-suse> jjohansen: not really decompile, just dump it in readable form
<zyga-suse> jjohansen: can you point me to that?
<jjohansen> zyga-suse: it isn't any where visible yet. I'll need to do a little cleanup (make sure it even builds atm I haven't touched it for at least a year), and push it up to an apparmor branch, I'll point you at it when I get that done
<mup> PR snapcraft#1391 opened: tests: reduce the amount of test code in test_meta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1391>
#snappy 2017-07-05
<mup> PR snapd#3556 opened: Support snap license field (SPDX expression) <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3556>
<mup> Bug #1563358 changed: snappy can only handle one bootloader (if grub is installed, uboot is completely ignored) <Snappy:Expired> <https://launchpad.net/bugs/1563358>
<mup> PR snapcraft#1386 closed: tests: workaround issue that causes failures to download core <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1386>
<mup> PR snapd#3557 opened: systemd: add snapd.core-fixup.service unit <Created by mvo5> <https://github.com/snapcore/snapd/pull/3557>
<zyga> oh linode why do you hate me
<zyga> and qemu, why do you need all the network to run tests :/
<mvo> hey zyga, good morning
<mvo> zyga: could you please push your branch that backports the internaltool use for 2.26?
<zyga> yes
<zyga> pushed
<zyga> there are three commits
<zyga> one is the squash of your branch
<zyga> and there are two more that are small backports to make things work
<zyga> backport/2.26/fix-internal-tool-path
<zyga> I didn't manage to run tests yesterday
<zyga> my network at home is super unreliable
<zyga> and capping makes things fail all the time
<zyga> if you have better connectivity please pull and run locally
<zyga> I think one test failure was genuine, it is just measuring a stale reexec message
<zyga> mvo: please ack, I'm not even sure IRC works (I always see lag: $LOTS) in irssi
<mvo> zyga: ack
<mvo> zyga: great, I can run tests here
<zyga> thanks!
<mvo> zyga: do I need detect-re-exec as well?
 * mvo needs to take a short break, doorbell
<zyga> mvo: which branch is that?
<zyga> mvo: as for https://github.com/snapcore/snapd/pull/3557/files -- how about naming those as fixup-1-ownership-change.after so that we can just have a namespace for the files
<mup> PR snapd#3557: systemd: add snapd.core-fixup.service unit <Created by mvo5> <https://github.com/snapcore/snapd/pull/3557>
<mvo> zyga: I like the idea, however its out already so kind of difficult to change now
<mvo> zyga: nevermind about https://github.com/zyga/snapd/tree/backport/2.26/detect-re-exec - I think we merged this already
<zyga> mvo: +1 to keep as-is
<mvo> zyga: ta
<zyga> brb
<pstolowski> hey guys, any improvement on linode side, or no change?
<zyga> pstolowski: I tried an hour ago, all failed
<pstolowski> zyga, ack, thanks
<mvo> zyga: I pushed a fix for the failing test, I think we are good now
<mup> PR snapd#3558 opened: cmd: backport fix for internal tool path <Created by mvo5> <https://github.com/snapcore/snapd/pull/3558>
<zyga> mvo: thank you! let's see
<zyga> mvo: which test was failingt?
<mvo> zyga: I run the tests now against the full 2.26
<mvo> zyga: it was re-exec and the string of the log messgae that it did not restart has changed
<zyga> ah, great
<zyga> mvo: ok, so that's all good for 2.26
<mvo> zyga: yeah, I run tests locally right now and if things are good will release
<zyga> sounds good, thank you!
<mvo> zyga: yes
<pstolowski> oh noes, 3 pages of PRs.. 56
<mvo> pstolowski: well, linode broken
<mvo> zyga: hrm, hrm, for some reason I cannot push to your branch zyga:backport/2.26/fix-internal-tool-path
<pstolowski> yeah i know
<mup> PR snapd#3559 opened: Backport/2.26/fix internal tool path <Created by mvo5> <https://github.com/snapcore/snapd/pull/3559>
<zyga> mvo: why two PRS?
<mup> PR snapd#3558 closed: cmd: backport fix for internal tool path <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3558>
<mvo> zyga: couldn't push to your branch, I used my own now
<zyga> mvo: ah, odd
 * Chipaca suddenly finds himself recompiling ncurses, and takes a step back
<pstolowski> Chipaca, I'll start to get worried when you fork ncurses
 * Chipaca puts away his cutlery
<pstolowski> just don't curse and you'll be fine
<Chipaca> ncurses on debian has been waiting for a soname change to add support for mouse wheel events for 12 years now
<Chipaca> I wonder if at any point it becomes "enough's enough"
<pstolowski> Chipaca, is it important for us?
<Chipaca> pstolowski: no :-)
<Chipaca> that's why i stopped
<pstolowski> :)
<Chipaca> pstolowski: also, dangit, the 2*len(args)+4 was correct before i split -ojson -nn into -o json -n n
<Chipaca> needs to be +6 now :-(
<Chipaca> i shall fix it, and add a comment, at some point before landing this
<zyga> re :-(
 * zyga break
<mvo> pstolowski, Chipaca: I just got a 504 from the store - we do not retry those currently, should we? if so, I can prepare a PR
<pstolowski> mvo, are you sure? looking at retry.go we do retry everything >= 500
<pstolowski> perhaps we exhausted all retries?
<zyga> re
<zyga> this is a very unproductive and annoying day :/
<mvo> pstolowski: aha, maybe thisis just in the 2.26 branch (which I'm testing right now)
<pstolowski> mvo, ah, could be, the >= 500 condition was introduced recently. before that we only retried select codes
<pstolowski> zyga, don't tell me. I feel stupid still fighting json issue :}
<pstolowski> maybe I need to take a step back and look at ncurses too ;)
<zyga> pstolowski: I'm fighting weather and network while making no progress on apparmor profile load
<zyga> fgimenez: any luck in that home test?
<Chipaca> pstolowski: step away from ncurses tho
<zyga> mvo: anything I can help with to have a change of focus?
<pstolowski> Chipaca, ah, ok, I misunderstood then
<mvo> zyga: not right now, running the tests, then I push a new release
<zyga> ok
<mvo> sorry
<mvo> zyga: I guess the work for base-snaps on core (in snap-confine) is already done, right? that might be a nice project
<niemeyer> Good morning
<niemeyer> News from Linode:
<niemeyer> Actually, I won't quote him directly as he was using language for a private conversation
<niemeyer> But the point is, apparently their backend corrupted one of our images
<niemeyer> Restore underway.. we can try it in a moment
<zyga> niemeyer: do you know which one?
<pstolowski> hey niemeyer!
<pstolowski> great they found out finally
<niemeyer> zyga: At least ubuntu-16.04-64 I suppose, which is the one presenting issues all the time
<niemeyer> pstolowski: Fingers crossed for now
<niemeyer> I don't know what I'll do when this one guy leaves Linode :)
<zyga> hehe, I was about to say, murhpy picked the "best" image to corrupt
<mvo> niemeyer: \o/
<fgimenez> zyga: nope, i've kept retrying but no trace of it, i start from the stable image, sudo snap refresh, reboot and then run the tests, last week the same actions led to the error after about 15 runs, now i can't reproduce it
<fgimenez> hey niemeyer, great!
<zyga> fgimenez: ok, thank you!
<niemeyer> Looks promising: https://travis-ci.org/snapcore/snapd/builds/250270516
 * mvo crosses fingers
<niemeyer> Still going strong
<mup> PR snapcraft#1391 closed: tests: reduce the amount of test code in test_meta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1391>
<mup> PR snapcraft#1389 closed: Use newer distro module with no tuple <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1389>
<Chipaca> niemeyer: mvo: i'm skipping the standup today -- i need to go to the boys' school
<Chipaca> the only thing different on my front is that i had some fun snapping things and then realising the bugs i was seeing was because of a bug in the distro itself, not in the snap :-)
<mup> PR snapd#3560 opened: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
 * zyga has network issues, trying to reconnect
<zyga> mvo: can you see my messages now?
<zyga> ok, back
<fgimenez> mvo: i have the beta images already built, just to confirm release/2.26 is up to date for running the tests from it, correct?
<zyga> pedronis: can you repeat what you said on the call?
<pedronis> zyga: do we know if there was a self-built snapd involved?
<pedronis> I know he had a very old one on his path at some point by mistake
<pedronis> anyway not sure snapd itself would affect this unless it was a full deb
<pedronis> and not just the daemon
<zyga> pedronis: good question, I'll ask the reporter
<mvo> fgimenez: almost, one sec
<mvo> fgimenez: now it is up-to-date
<fgimenez> mvo: cool thx!
<niemeyer> Chipaca: Thanks for the note
<niemeyer> Our Linode pool is clean and seems to be churning at an appropriate pace now
<fgimenez> mvo: i see 2.26.8 in snap version's output, that is fine right? iirc we omited the last digit in previous releases
<mvo> fgimenez: the output is correct, we skipped 2.26.7 because it was ready before the core-fixup script came up
<fgimenez> mvo: ok thanks, but did we always include the 3 digits in the version? we have a 2.24.1 entry in the changelog but the current stable shows 2.24 in snap version
<pstolowski> niemeyer, did you mean this topic https://forum.snapcraft.io/t/how-to-snap-get-root-document/522 ?
<niemeyer> pstolowski: yes, that looks like the one
<fgimenez> mvo: i'm in validation mode now, pls forgive my pickiness :)
<mvo> fgimenez: we included the digests before, at least in theory, I need to figure out why changelog/core disagree
<mvo> fgimenez: it might be that 2.24.1 was never uploaded as a core snap becasue it contained something that was only relevant on classic (adt fix or something)
<fgimenez> mvo: ok great, don't spend too much time on it, just curious
<niemeyer> pstolowski: I've added another note there as well on a closely related need
<niemeyer> pstolowski: and tagged it for you
<pstolowski> niemeyer, cool, thanks
<niemeyer> pstolowski: Thanks for looking into this
<pstolowski> niemeyer, btw did you get the calendar invitiaion for interfaces stuff?
<niemeyer> Yep, looks good, thanks
<coreycb> hi all, what's the next step for getting auto-aliases setup?  i have a security ack on the request: https://forum.snapcraft.io/t/auto-aliases-for-openstack-base-snaps/1146
<niemeyer> coreycb: It's just waiting for a second +1 I think.. will look
<coreycb> niemeyer: ok thanks!
 * zyga dinner
<mup> PR snapd#3539 closed: tests: fix timeout issue for test refresh core with hanging â¦ <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3539>
<jdstrand> coreycb: I'll circle back around in a bit. there is a voting process. I'll gide it
<jdstrand> guide*
<coreycb> jdstrand: ok thanks
<flexiondotorg> icey A while back you mentioned that you a cholcombe were working on a rustup snap. Any progress on that?
<zyga> jdstrand: o/
<icey> No time flexiondotorg
<flexiondotorg> OK :-(
<mvo> fgimenez: I just double checked, 2.24.1 was a autopkgtest fix so not relevant for core
<fgimenez> mvo: great thanks a lot, btw i just had an error on amd64 in the refresh from stable scenario http://paste.ubuntu.com/25025482/ i have the session open in case you want to have a look
<fgimenez> mvo: core went from 1441 (this comes from the stable image) -> 2312 (after the first refresh, still stable) -> 2329 (beta)
<mvo> fgimenez: yes, would love to have a look, do you have a ssh session for me?
<mvo> fgimenez: if so, please /msg or tg
<mvo> fgimenez: looks like snap list --all is affected
<fgimenez> mvo: sure 1sec, fwiw the same scenario just finished successfully on i386
<mvo> fgimenez: the mount unit for 1441 would be interessting
<mvo> fgimenez: I suspect the snap is there but for some reason it is not mounted
<fgimenez> mvo: indeed, it shows up in /var/lib/snapd/snaps
<kyrofa> niemeyer, any chance you have some time available today to discuss the two snapcraft items from the sprint agenda?
<niemeyer> kyrofa: Yeah, feel free to pick any open slot in the agenda
<kyrofa> niemeyer, agenda = your calendar? :P
<ogra_> heh
<cholcombe> flexiondotorg: no i haven't made progress on that
<flexiondotorg> cholcombe Thanks for the feedback.
<niemeyer> kyrofa: Sorry, yeah
<pstolowski> bah, got the json numbers working
<pstolowski> now, i have so many changes in the tree... need to find out which ones are irrelevant to these fixes ;)
<mup> PR snapd#3561 opened: tests: store /etc/systemd/system/snap-*core*.mount in snapd-state.tar.gz <Created by mvo5> <https://github.com/snapcore/snapd/pull/3561>
<mvo> fgimenez: this is the PR we just talked about -^
<fgimenez> mvo: great, thanks!
<Chipaca> is ubuntu-16.04-32:tests/main/create-key being a problem, or have i been unlucky?
<mup> PR snapd#3512 closed: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3512>
<mup> PR snapd#3559 closed:  cmd: backport fix for internal tool path #3558  <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3559>
<mvo> if someone could review 3557 that would be great
<mvo> zyga: maybe -^
<mvo> then we can restart edge builds today
<zyga> mvo: looking
<Chipaca> mvo: 3557, or 8?
<mvo> Chipaca: the systemd unit fix thing, 3557 I think
<mvo> Chipaca: 3558 already got cherry picked when tests were still unhappy
<Chipaca> ok
<zyga> mvo: done
<Chipaca> all the lgtms!
<Chipaca> :-)
<mup> PR snapd#3557 closed: systemd: add snapd.core-fixup.service unit <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3557>
<mup> PR snapd#3562 opened: systemd: add explicit sync to snapd.core-fixup.sh <Created by mvo5> <https://github.com/snapcore/snapd/pull/3562>
<mup> PR snapd#3563 opened: release: merge release/2.26 branch back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3563>
<mup> PR snapd#3546 closed: tests: fix for rng-tools service not restarting <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3546>
<mup> PR snapd#3541 closed: snapd: fix for snapctl get panic on null config values <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3541>
<mvo> cachio_afk: if you could address the feedback in 3409, that would be appreciated, then this branch can go in
<pstolowski> mvo, shall I propose a cherry-picked PR 3451 for 2.26?
<mup> PR snapd#3510 closed: tests: shellcheck improvements for nightly upgrade and regressions tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3510>
<mvo> pstolowski: 3451 is dir abstractions - is this the one you have in mind?
<pstolowski> mvo, sorry, 3541
<mvo> pstolowski: unfortunately too late, 2.26.8 is out, so unless this is critical it will go into 2.27
<pstolowski> mvo, i see. i don't think it's critical
<coreycb> jdstrand: any chance you can publish this for me? https://dashboard.snapcraft.io/dev/snaps/6421/rev/78/   it looks to be blocked by a previous upload that used  kernel-module-control, but has since been dropped.
<jdstrand> coreycb: sure thing (fyi, was off yesterday and monday so queue is a little behind (though it was caught up on friday)
<jdstrand> )
<coreycb> jdstrand: thanks, and no problem at all
<jdstrand> coreycb: oh, that's done now. the newer ones are approved but you need to release them. did you want me to release the latest (r78) to edge for you?
<coreycb> jdstrand: i've just released that. thanks!
<jdstrand> cool np
<mup> PR snapd#3538 closed: tests: create ramdisk if it's not present <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3538>
<mup> PR snapd#3508 closed: tests: shellcheck improvements for tests/lib scripts <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3508>
<mup> PR snapd#3492 closed: cmd/snap: `--last` for abort and watch, and aliases (searchâfind, changeâtasks) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3492>
<mup> PR snapd#3534 closed: tests: shellcheck improvements for tests/main tasks - first set of tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3534>
<mvo> zyga: #3518 needs a test update, the failure look real
 * zyga nods
<mup> PR snapd#3518 closed: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3518>
<mup> PR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
<zyga> jdstrand: can you please have a 2nd look at ^
<jdstrand> zyga: ack
<zyga> jdstrand: thank you
<jdstrand> zyga: yw
<mup> PR snapd#3550 closed: update firewall-control to allow {arp,ip,ip6}tables to control bridged vlan/ppoe-tagged traffic <Created by coreycb> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3550>
<mup> PR snapcraft#1392 opened: catkin plugin: extract rosdep into new package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1392>
#snappy 2017-07-06
<mup> PR snapcraft#1393 opened: python plugin: output json in pip list <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1393>
<mup> PR snapd#3564 opened: tests: speedup prepare statement part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3564>
<mup> PR snapd#3561 closed: tests: store /etc/systemd/system/snap-*core*.mount in snapd-state.tar.gz <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3561>
<mup> PR snapd#3563 closed: release: merge release/2.26 branch back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3563>
<mup> PR snapcraft#1394 opened: tests: document the test suites in the snapcraft repo <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1394>
<zyga> re
<mup> PR snapd#3551 closed: systemd, osutil: rework systemd logs in preparation for services commands <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3551>
<mup> PR snapd#3504 closed: interfaces: bring back seccomp argument filtering <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3504>
<mvo> a second review for 3501 would be great, looks very straightforward
<mvo> zyga: maybe 3491 is sometihng that you could review? just needs a second review
<morphis> morning!
<zyga> mvo: certainly, with pleasure
<mvo> hey morphis
<mvo> zyga: thank you!
<morphis> zyga, mvo: how was the sprint last week?
<zyga> morphis: very productive
<zyga> morphis: but also some bugs interfered
<morphis> oh bad
<morphis> zyga: still for the 2.26 release?
<zyga> morphis: indeed
<morphis> I guess you had a lot fun last week :-)
<mvo> morphis: *cough*
<mvo> fgimenez: snapd 2.26.8 is now also -proposed everywhere and ready for SRU testing
<fgimenez> mvo: great thanks, on it, we should have proper detection now on spread-cron, could you please check the date the tests were triggered? https://travis-ci.org/snapcore/spread-cron/builds/250440323
<mvo> fgimenez: 14h ago sounds about right
<zyga> mvo, pstolowski: reviewed https://github.com/snapcore/snapd/pull/3491#pullrequestreview-48258965
<mup> PR snapd#3491: snapd: generate snap cookies on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/3491>
<pstolowski> zyga, thanks!
<fgimenez> mvo: cool thx
<mup> PR snapd#3565 opened: cmd/snap-repair: skeleton code around actually running a repair <Created by pedronis> <https://github.com/snapcore/snapd/pull/3565>
<pedronis> mvo: hi,  this ^  is the last of a chain,  it has some skeleton code (similar to what you had in one of your branches) about where actually running the repair could happen
<mvo> pedronis: nice, thank you!
<pedronis> mvo: IÂ have a wip branch with code to actually verify the signature of the repair, anyway that plugs in one of the previous pieces in the chain where there's a todo
<mvo> pedronis: ok,  I need to tie up some loose ends and then I can jump on it
<pedronis> mvo: it's quite a bit of code in those PRs :/   the fetching is a bit complicated
<mvo> pedronis: yeah, I noticed, I peeked over them already (but not review carefully yet)
<pedronis> mvo: anyway mostly saying, getting those pieces into shape for landing or changing as needed, running and small TODOs in those branches should be all things that can be worked on while I'm of,   verification is probably something that IÂ can pick up again when I'm back, anyway the server bits still needs a bit more work too
<pedronis> mvo: so as I said in the standup, depending on timings, 2.28 or 2.29 are probably more realistic goals to get this all pieced together
<pedronis> mvo: btw about file names etc, I'm following the current stuff in "transparent" section of the forum topic
<pedronis> if we change those we should change the topic as well
<mvo> pedronis: ok, sounds good
<pedronis> mvo: sorry for the info dump, but I'm off a bit this afternoon as I said, and you are taking tomorrow off?
<mvo> pedronis: correct
<mvo> pedronis: no need to be sorry, I appreciate the update :)
<pedronis> mvo: IÂ migtht also get a PR up, today or tomorrow about reading brand/model out of the seed/assertions data, haven't started yet though and want to work also on something else
<pedronis> unrelated to repairs
<mvo> ta
<pedronis> I'll put a link  in the forum if I get to it
<pedronis> (the other PRs are also already linked from there)
<zyga> mvo, pstolowski: trivial and long overdue https://github.com/snapcore/snapd/pull/3566
<mup> PR snapd#3566: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <https://github.com/snapcore/snapd/pull/3566>
<mup> PR snapd#3566 opened: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <https://github.com/snapcore/snapd/pull/3566>
<pstolowski> zyga, looks good, but I think the test file has the same issue? s/iio/io there too?
<zyga> pstolowski: which one?
<zyga> pstolowski: I only see iio_* files having iio identifiers
<pstolowski> zyga, io_ports_control_test.go has Iio*
<zyga> ah, I didn't look for Iio :)
<zyga> thanks
<zyga> fixed
<zyga> pushed
<pstolowski> thanks
<pstolowski> +1
<mup> PR snapd#3518 closed: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3518>
<fgimenez> mvo: zyga i'm getting an error on trusty when trying to install core from beta http://paste.ubuntu.com/25031042/
<zyga> fgimenez: looking
<mvo> fgimenez: what version of libseccomp do you have installed in that machine? is it the latest from -updates?
<Chipaca> pedronis: is there a sorting requirement for a series?
<zyga> interesting
<zyga> mvo: missing dep on snapd?
<Chipaca> pedronis: that is, in âseries, err := stringList(headers, "series")â, can series be assumed sorted?
<zyga> mvo: thread synchronization is a feature that was not originally in the distro
<pedronis> Chipaca: not atm
<fgimenez> mvo: let me check
<Chipaca> pedronis: aw
<pedronis> Chipaca: I think it's also fair to assume there's not bazillion of them
<Chipaca> pedronis: was hoping we could drop one of the implementations of inStringList
<Chipaca> :-)
<pedronis> Chipaca: I suppose we have copies of two ?  (sorted and unsorted)
<pedronis> time to put those into strutil?
<Chipaca> yeah
<Chipaca> pedronis: and there's testutils's Contains, just for extra fun
<Chipaca> testutil's*
<pedronis> test and prod should not meet :)
<pedronis> or something
<fgimenez> mvo: http://paste.ubuntu.com/25031072/, libseccomp2 is at 2.1.1-1ubuntu1~trusty3
 * zyga hugs contains
<Chipaca> pedronis: yeah, testutil's is all about reflect :-)
<mvo> fgimenez: this looks good, how strange
<mvo> fgimenez: how strange - those tests passed in linode/spread
<mvo> fgimenez: aha, what kernel is running?
<fgimenez> mvo: for the sru validation we install the package from the archive, it's the only difference afaict
<fgimenez> mvo: 4.4.0-85-generic from snap version
<mvo> fgimenez: what does uname -r tell you?
<fgimenez> mvo: same, 4.4.0-85-generic
<mvo> fgimenez: confusing, I have a look
<fgimenez> mvo: i can prepare a tunnel if you want to log in the machine
<mvo> fgimenez: I start with my local vm
<mvo> fgimenez: but thank you
<fgimenez> mvo: great thanks
<zyga> mvo: it does look good "on paper"
<pedronis> Chipaca: I see for 4 "contains" around, so maybe indeed worth a look
<mvo> zyga: what exactly :) the kernel version? or the code? or sometihng-else?
<pedronis> Chipaca: seems a its own branch thing though
<Chipaca> totz
 * pedronis lunch
<Chipaca> pedronis: which are the four? I see this new "inStringList", overlord/snapstate's contains, and one contains in interfaces/policy/basedeclaration_test
<Chipaca> this is studiously ignoring the one in testutil ;-)
<Chipaca> and vendor obvs
<pedronis> there are some that are even declared locally
<pedronis> ./partition/grubenv/grubenv.go:	var contains = func(needle string, haystack []string) bool
<pedronis> ./daemon/api.go:	contains := func(needle string, haystack []string) bool {
<pedronis> as well
<Chipaca> ah
<pedronis> and haven't looked to hard with things name like my in*
<pedronis> *too hard for things*
<Chipaca> my grep was looking for ^func :-)
 * Chipaca tries harder
 * pedronis really lunch
<pedronis> Chipaca: that's not the full story(tm) :)
<fgimenez> mvo: zyga for reference these are all the steps taken during sru validation for putting the snapd package in place https://github.com/snapcore/snapd/blob/release/2.26/tests/lib/apt.sh#L15 we begin from the package in updates, then add the proposed pocket and upgrade snapd from it
<Chipaca> 3Ã unsorted, 1Ã sorted
<Chipaca> I'll add strutil.ListContains and strutil.SortedListContains
<zyga> re!
<zyga> ha
<zyga> stupid orange modem
<mvo> fgimenez: I can reproduce the issue on 14.04
 * zyga tries one more thing with his network
<Chipaca> zyga: Wat heb je tegen het Huis van Oranje?
<Chipaca> zyga: (or something)
<zyga> maybe this will hold, for now
<pstolowski> mvo, do you know from top of your head where do we set refresh.schedule to 0 in our tests? (it's also possible we don't actually do this and I've a bug in my branch)
<pstolowski> i couldn't find any explicit assignment, so perhaps it's set automagically somewhere
 * pstolowski lunch
<mup> PR snapd#3566 closed: interfaces: fix copy-pasted iio vs io in io-ports-control <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3566>
<mvo> pstolowski: iirc this is just the default value
<mup> PR snapd#3553 closed: interfaces: enable access to bridge settings <Created by coreycb> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3553>
<mup> PR snapd#3555 closed: assserts,overlord/assertstate: test we don't accept chains of assertions founded on a self-signed key coming externally <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3555>
<zyga> mvo: any idea about 14.04 error?
<zyga> mvo: is that on 3.13 or on the LTS kernel?
<mvo> zyga: I can reproduce it on the lts kernel - but only with snap install --beta core - not with the stable core
<zyga> mvo: hum hum hum
<zyga> mvo: so does it indicate we are using a new version/feature/code branch in libseccomp?
<zyga> mvo: when I was diffing libseccomp at the sprint I did see tsync patches
<pedronis> pstolowski: there are lines doing             snap set core refresh.* = ...  in prepare.sh ?  do you mean something else?
<pedronis> pstolowski: ah, you meant unit tests?
<mvo> zyga: I'm not sure what it means yet unfortunately. maybe a missing patch in the libseccomp backport for trusty
<ogra_> WTF!
<ogra_> ppisati, something does always release the unusable newer kernel to stable, only you, me, the kernel team and mvo have access
<ogra_> i dont get how that happens, is the kernel team running any scripts ?
<ogra_> (this is the third time i had to roll back the snap)
 * ogra_ talks about pi2-kernel here 
<ppisati> ogra_: yep, you me and my team
<ppisati> ogra_: i guess someone inside my team is doing it, though it shouldn't go to -stable
<ppisati> ogra_: but unusable why?
<ppisati> ogra_: for the dtb relocation?
<ogra_> ppisati, because the dtb we ship in the gadget doesnt boot with anything newer than rev 22 of the pi2-kernel snap
<ogra_> only the gadget updates implementation will fix that ... but thats still far out
<ppisati> ogra_: ok, let me work it out
<ogra_> (we cant update the dtb on disk of users yet .... so we're stuck with the kernel revision the first stable image had)
<ogra_> ppisati, thanks
<ogra_> i hope it at least rolls back properly ... :)
 * ogra_ never runs stable ... 
<ppisati> ogra_: so, the kernel snap creation script automatically pushes the kernel to "candidate, beta"
<ppisati> https://code.launchpad.net/~ubuntu-kernel/+snap/pi2-kernel
<ogra_> thats fine
<ppisati> so, someone else is moving it to -stable
<ogra_> could also push to edge if you feel like
<ppisati> let me find my whip and this guy
<ogra_> :)
<ogra_> ppisati, since we're just talking ... i'll likely need a fix in the vc4 setup ... seems loading the overlay dtb for it breaks the kernels "simple framebuffer" ... using something that writes to /dev/fb0 directly with that overlay loaded makes the board hang hard (see my last comment on bug 1701018 )
<mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:New> <https://launchpad.net/bugs/1701018>
<ogra_> might be that https://github.com/raspberrypi/firmware/issues/597 is related ... there seems to be a dtb fix
<ppisati> ogra_: "psplash only works with a working simple framebuffer driver, so this option needs to be disabled"
<ppisati> ogra_: FB_SIMPLE (the simple-framebuffer kernel driver) is already off, because if i turn it on, it'll attach (and screw actually) to the simple-framebuffer DT node, injected by u-boot
<ogra_> ppisati, well, somehow vc4 breaks fb0 ... and i see a patch (added a link to the bug)
<ogra_> there seems to be a corresponding u-boot dt change too though
<ppisati> ogra_: what does vc4-kms-v3d do?
<ogra_> turn on vc4 acceleration
<ogra_> it is needed for GLES and mir-kiosk
<ppisati> ogra_: ok, is there a way for me to test if this acceleration is on?
<ogra_> ppisati, use an ubuntu core image, we have it on by default there
<ogra_> beyond that, just set the option in your config.txt on a classic install ... should do the same
<ppisati> ogra_: but if we already have this acceleration on, why do we need this vc4-kms-v3d overlay?
<ogra_> no
<ogra_> we have the overlay loaded by default
<ogra_> (which turns it on)
<ogra_> without the dtbo you dont have any acceleration
<ppisati> ogra_: uhm, ok
<ogra_> i havent seen any prrobs with it yet until i tried to use psplash on it ... (psplash works fine on all other boards)
<pedronis> Chipaca: thanks for the reviews btw, bit surprised the Next one didn't get any extra comments :)
<pedronis> Chipaca: mvo: as IÂ mentioned yesterday, going to be off for some hours from now, so no standup for me today
<mvo> pedronis, Chipaca: thanks for the notification. I may also not make it today, a repairman is scheduled for this afternoon and the time is a bit uncertain
<Chipaca> pedronis: hrm, maybe i missed something? :-)
<jdstrand> mvo: I'm not familiar with the 'tsync bit' error. It seems to be a libseccomp-golang thing though: https://github.com/seccomp/libseccomp-golang/blob/master/seccomp.go#L497
<jdstrand> mvo: strike that. I see libseccomp-golang give that error string, but libseccomp does reference tsync
<jdstrand> mvo: I did see this: https://github.com/seccomp/libseccomp/issues/20
<jdstrand> mvo: which may me wonder if libseccomp on trusty is built with a 3.13 kernel (as opposed to lts kernel), perhaps it isn't being built with tsync support
<jdstrand> mvo: (guess)
<jdstrand> mvo: I then saw https://github.com/seccomp/libseccomp/commit/a1f144a9a28aa1b831f7d3f481fb3e0e5e3de3aa
<jdstrand> "The seccomp() syscall was first added in Linux 3.17 so most systems
<jdstrand> should now support this syscall.  Most importantly, the use of the
<jdstrand> seccomp() syscall enabled the thread sync functionality which isn't
<jdstrand> possible with prctl(); although callers still need to enable the flag
<jdstrand> per-filter as the thread sync default is disabled."
<jdstrand> mvo: with snap-seccomp, we moved to prctl
<pstolowski> pedronis, mvo thanks, it was about spread tests and refresh schedule
<jdstrand> mvo: maybe if we appropriately used the seccomp syscall, this would resolve itself?
<mvo_> jdstrand: sorry, disconnected, you mean use seccomp() instead of prctl() ?
<jdstrand> mvo_: yes. let me give you full context
<pstolowski> mvo, pedronis with my changes wrt json decoding it now requires " to be escaped around timestamp, otherwise it treats it as number taking leading 0 ang ignoring the rest :(
<pstolowski> mvo_, pedronis has to do with shell eating quotes I suppose
<pstolowski> mvo_, pedronis so snap set core refresh.schedule="0:00-23:59" needs to be snap set core refresh.schedule=\"0:00-23:59\"
<jdstrand> mvo_: http://paste.ubuntu.com/25031898/
<pstolowski> bummer
<mvo_> jdstrand: aha, thank you - yes, I have a look
<jdstrand> mvo_: fingers crossed :)
<mvo_> pstolowski: oh, nice find
<pstolowski> mvo_, well, it's *after* my changes
<jdstrand> mvo_: I'm not sure if this will be needed for libseccomp on trusty: https://github.com/seccomp/libseccomp/commit/08a682a9f895b8f622499df5ee69fcabe1e3cbab
<jdstrand> (but not sure if naively applying that would cause problems for libseccomp with non-lts kernel)
<mvo_> jdstrand: hm, indeed, it sounds slightly dangerous
<jdstrand> mvo_: actually, if you are calling the seccomp syscall directly, you aren't using libseccomp, so that should be needed
<mvo_> jdstrand: shouldor should not?
<jdstrand> I guess we'll need to see what libseccomp-golang ends up doing if you use seccomp syscall instead of prctl
<pstolowski> mvo_, this is bad, becase it means it may break for people on their variables if they start with a number (one such case is also in our tests - an IP address)
<jdstrand> mvo_: heh, shoud *not*
<jdstrand> sould*
<jdstrand> argh
<mvo_> jdstrand: :) no worries
<jdstrand> s h o u l d   n o t
<jdstrand> :)
<mvo_> jdstrand: lol
<jdstrand> I'm not using my external keyboard atm. I'll blame that
<jdstrand> my laptop keyboard likes to occasionally drop entire words
<jdstrand> :)
<zyga> jdstrand: o/
<zyga> jdstrand: interesting observation on prctl vs seccomp syscall (darn flags)
 * zyga thinks about skipping standup and having lunch instead
<zyga> jdstrand: is it possible that cat /sys/kernel/security/apparmor/policy/*/raw_data truncates stuff?
<zyga-suse> mvo_: is this sensbile? pastebin.ubuntu.com/25031983/
<mvo_> zyga-suse: hm, with the latest master this shoudl be fixed
<mvo_> zyga-suse: is our branch current?
<zyga> mvo_: this is from https://github.com/snapcore/snapd/pull/3531 (10 days ago)
<mup> PR snapd#3531: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3531>
<mvo_> zyga: it just needs master
<mvo_> niemeyer: sorry, I miss standup, there is a repairman at the door
<niemeyer> mvo_: np, thanks for the note
<jdstrand> zyga: I am not familiar with those interfaces. curious why you a playing with them, but jjohansen would be the person to ask
<ogra_> ppisati, did you see bug 1691729 ... seems a few classic users have actual probs with it
<mup> Bug #1691729: linux-firmware-raspi2 conflicts with linux-firmware over brcmfmac43430-sdio.bin <linux-firmware-raspi2 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1691729>
<zyga> jdstrand: I can give you some advice but I already spoke with jj about that
<jdstrand> zyga: is this for a pending PR?
<ppisati> ogra_: added to my list - i think that is the bluetooth fw
<ogra_> ah
<zyga> jdstrand: more like bug hunting
<jdstrand> I see
<zyga> jdstrand: trying to figure out why people bump into the issue with snap-confine using old profile
<jdstrand> zyga: talked to jj about truncating possiblility. I would think 'no' but that is based on nothing :)
<zyga> jdstrand: and one case where it seems profiles are in wonky state and only work after re-loading by hand
<jdstrand> ah that
 * zyga learned x10 more about how apparmor works in the last week
<ogra_> volunteering for the security team ?
<ogra_> :)
<jdstrand> zyga: I'm not saying this is it, but keep in mind when the cache file is used and when it isn't
<jdstrand> zyga: it is possible to get into situations where an old cache file is loaded into the kernel, then the thing runs with it, then it is loaded/updated later
<jdstrand> so at debug time, everything looks ok, but at the moment of the access, the old cache was in place
<jdstrand> this is just general advice not anything specific to what you are doing
<jdstrand> also, with snapd deciding which snap-confine and which profile to use, that could get even more interesting
<mup> PR snapd#3567 opened: many: introduce and use strutil.ListContains <Created by chipaca> <https://github.com/snapcore/snapd/pull/3567>
<zyga> jdstrand: yes, that's a good point, cache is bypassed when we upgrade packages
<zyga> jdstrand: but we write to the cache in that case
<jdstrand> if I were debugging this, I would try to trace the whole process from boot to denial to debug time. tracing for when apparmor unit loads the profile, when snap-confine runs at all, what profile it is running under, the cache mtimes vs profile mtimes at time you run apparmor_parser, etc
<zyga> jdstrand: I'd love to see this reproduced first
<jdstrand> oh still no reproducer. that is unfortunate to say the least
<zyga> yes
<zyga> so working "dry"
<zyga> and reading binary profiles
<zyga> (very interesting btw)
<jdstrand> but if your tracing is in place, maybe you can see a potential race
<jdstrand> zyga: (also what options are being used with apparmor_parser whenever it is called)
<niemeyer> pstolowski, zyga: This is the issue: https://play.golang.org/p/qyx_D3F-DO
<zyga> jdstrand: -T -W
<niemeyer> pstolowski: When you use a decoder, it handles the input as a stream
<pstolowski> niemeyer, aaah!
<zyga> niemeyer: WAT?
<zyga> niemeyer: ah
<niemeyer> pstolowski: It's decoding the first integer, and waiting for instructions
<pstolowski> niemeyer, indeed...
<zyga> so all we have to do is to ensure we reached end of the input
<jdstrand> zyga: I meant as part of the tracing exercise (if you are going to do that). seeing the arguments that are actually being used rather than what you expect them to use
<Chipaca> pedronis: i couldn't resist and threw together snapd#3567
<mup> PR snapd#3567: many: introduce and use strutil.ListContains <Created by chipaca> <https://github.com/snapcore/snapd/pull/3567>
<zyga> jdstrand: interesting, I'll patch my system to log apparmor_parser invocations
<zyga-suse> travis seems to have network hicckups
<zyga-suse> spread times out on snapd downloads with speeds of 50KB/s
<zyga-suse> that's pretty slow
 * zyga-suse dinner
<ppisati> ogra_: that linux-raspi2-firmware package wasn't the one in the archive, but one from a PPA
<ppisati> lp1691729
<ppisati> bug1691729
<ogra_> ppisati, oh sigh ...again ?
<ppisati> ogra_: yes
<ogra_> iirc the last big issue was also some PPA stuff
<ogra_> oh my
<ogra_> JamieBennett, ^^^
<ppisati> well, we deserve the blame because we never generated an ubuntu classic img so far
<fginther> What is required to update the 'current' link for the ubuntu-core images? The 'stable' image for pi3 is still using an image from 2017-03-14, but much newer stable pi3 images exist
<fginther> this link: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<ogra_> ppisati, huh ? we do have http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/
<ogra_> oh, you are talking about pi3 i guess
<ogra_> fginther, "ubuntu-core" ?!?
<fginther> ogasawara, this is what https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 links to
<ogra_> fginther, thats dead and gone since ages ... your board should have migrated from "ubuntu-core" to "core" quite a while ago
<fginther> so, this is just crufty websites?
<ogra_> fginther, right, i'm talking about the snap on your system :)
<ogra_> nah
<ogra_> the images are fine, they should all auto-migrate to core
<fginther> oh, snap list shows it as "core"
<fginther> core        16-2.26.8      2331  canonical  -
<ppisati> ogra_: yes, pi3
<ogra_> that sounds recent
<davidcalle> fginther: what? No it links to http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz
<davidcalle> Oh sorry, misread the thread :)
<ogra_> davidcalle, yeah, naming issues (snap vs image name) :
<ogra_> :)
 * davidcalle got scared for a second
<davidcalle> (the chain of notifications made it look like http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/ was the link on developer.ubuntu.com)
<fginther> hhe
<fginther> heh
<fginther> The pi3 image at http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz does have a bug (https://bugs.launchpad.net/snappy/+bug/1678076), but newer 'stable' images don't. I was curious if the fix for the bug is to just update the current link.
<mup> Bug #1678076: console-conf crashes with eth0 and wlan0 on Pi 3 <Snappy:New> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1678076>
<ogra_> fginther, i dont know what conditions need to be fulfilled to have the ones in pending/ move to current/ ... there are definitely newer ones in pending
<ogra_> i guess the QA for them isnt done yet (they are only a day old)
<ogra_> fginther, fgimenez and slangasek might be able to tell you though :)
<jjohansen> zyga: it shouldn't truncate, and you should be able to use multiple reads/search etc
<ogra_> iirc federico is the gatekeeper and slangasek owns the setting of the links
<jjohansen> that being said the lxd guys reported occasionally getting a truncated file, but I could never reproduce
<fginther> ogra_, thanks for the info. I'll follow up with fgimenez
<fginther> once I test this again and have better info
<pedronis> Chipaca: lgtm but the tests aren't happy on that branch
<Chipaca> ah, i didn't run the full unit tests
<ogra_> fginther, note that wlan-only installs do not work yet though ... only the python traceback issue of that bug will be fixed
<Chipaca> literally just threw the branch together
<Chipaca> i'll take a look in a bit
<mup> PR snapd#3568 opened: snapctl: add new `snapctl internal configure-core`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3568>
<fginther> ogra_, thanks
<zyga-suse> jjohansen: interesting
<zyga-suse> jjohansen: thank you
<ogra_> (there is another bug i cant find right now)
<fginther> https://bugs.launchpad.net/snappy/+bug/1632387 looks promising
<mup> Bug #1632387: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:Confirmed> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632387>
<ogra_> fginther, yeah, thats the one
<ogra_> fginther, it works fine after the first reboot ... you can just run "sudo console-conf", turn of eth0 and configure wlan just fine
<ogra_> only the very first boot breaks ...
<fginther> ogra_, right, that worked for me (wlan only works if you restart during console-conf)
<ogra_> well
<mvo_> Chipaca: I love that listContians branch, fix for the unit test looks trivial (just a misisng import), I can push for you if you are busy. fun how many contains we had in that code :)
<ogra_> not during
<ogra_> i usually just confgure the board wired, then reboot ... ssh in via wired and run console-conf again
<Chipaca> mvo_: there's another one in the pipeline, which is what triggered the branch
<fginther> I never had mine wired.
<Chipaca> i'm on it
<ogra_> ah
<ogra_> well, then you were lucky to have it working at all
<fginther> I'm updating the bug with the workaround
<ogra_> there is some race i cant put my finger on :/
<fginther> ah, maybe it was just luck then
<zyga-suse> ogra_: did we get to the bottom of that bug?
<ogra_> zyga-suse, no
<ogra_> zyga-suse, we do know the symptoms and workarounds but not the reason ... and it is only the very first boot
<zyga-suse> well, there will be a lot of people hitting that
<zyga-suse> so the "only" part is not so happy
<ogra_> i'll try to allocate some time to it again but i'm not very hopeful
<ogra_> the prob is that you cant access the system at this point and as soon as you start with a debug systemd shell it works
<ogra_> so nailing it down is really hard
<pedronis> Chipaca: thx for that branch btw
<pstolowski> zyga, you mentioned earlier you'd be working on some big interface changes, what is that?
<zyga-suse> pstolowski: hmm? I think none anymore, all the things I wanted are "in"
<pstolowski> zyga, ok, maybe I misunderstood something in the standup, nvm then
<zyga-suse> ah
<zyga-suse> sorry
<zyga-suse> that was the "interface" command
<zyga-suse> and indeed that is in the pipeline, but it should not interfere with any API changes
<pstolowski> zyga, ah, good, thanks :)
<zyga-suse> pstolowski: please ensure that we have deprecated API detection in all_test.go
<pstolowski> zyga, sure... but that's faaar away ;)
<pstolowski> niemeyer, hey, there?
<niemeyer> pstolowski: Sort of here :)
<niemeyer> pstolowski: What's up?
<pstolowski> niemeyer, about that json decode problem; in my tests it looks like Decode always decoded as much as it can (i.e. entire object where it makes sense) and stops (with More()==true); but that doesn't seem to be backed up by the docs; do you know if More() is a good indicator to know we have invalid json (because there is more data)?
<niemeyer> pstolowski: What's the behavior that is taking place there which seems unexpected in comparison to docs?
<pstolowski> niemeyer, I feed it with very large array, followed by some random stuff, and I always receive entire array object. so it never "stops" at the middle of an object, it reads it completely
<pstolowski> niemeyer, the doc says "// More reports whether there is another element in the
<pstolowski>   // current array or object being parsed.
<pstolowski>   "
<pstolowski> I find the observed behavior natural and exepected, receiving partial object would be terrible
<niemeyer> pstolowski: I don't understand what that means.. the json decoder outputs objects.. it doesn't output byte arrays
<niemeyer> pstolowski: When you create a decoder and initialize it with a reader, that decoder will use the reader as a stream, and will decode objects on it sequentially
<niemeyer> pstolowski: I don't even mean what a "partial object" would be in this context.. there are no half-values in Go
<niemeyer> pstolowski: Byte stream comes in, Go values get decoded..
<ogra_> 50 shades of objects ...
<niemeyer> pstolowski: One a time..
<ogra_> :)
<niemeyer> pstolowski: When you decode "0:", you get to the zero only, because that's as far as the json decoder can reasonably go, and then you have More
<niemeyer> pstolowski: This is the behavior I'd expect, and also what I think is documented
<niemeyer> pstolowski: What in this picture disagrees with your expectation, or with what's happening in your observations?
<pstolowski> niemeyer, yes, I get that, and it works as I expected it to work. it's just that docstring for More that confuses me ("whether there is another element in the current array...")
<niemeyer> pstolowski: That seems to describe what I just said above
<niemeyer> Have a call now, we can continue in a bit
<Chipaca> pstolowski: More() says whether there is more stuff in the thing _being parsed_, not in the result of the parse
<pstolowski> Chipaca, aha, great, that confirms my understanding than and clears the confusion, thank you
<pstolowski> thanks niemeyer, I'm good
<Chipaca> funnily enough the implementation of More seems a bit bogus
<Chipaca> like, `[1,2,3]]` would give you an array and no More, i think?
<Chipaca> bah. never mind.
 * Chipaca goes for some tea
<niemeyer> kyrofa: Looking through the notes in that topic, it may be a good idea to enable building on multiple bases..
<niemeyer> kyrofa: Specifically so that people on multiple distributions can collaborate on the same snaps..
<niemeyer> kyrofa: I'll cover more in the topic itself.. but just wanted to point out the disagreement from what I just said in the sprint so it doesn't feel awkward
<niemeyer> s/sprint/call/
<kyrofa> niemeyer, indeed, that makes sense. Fits into the stage-package grammar as well, where you can provide separate ones depending on distribution
<kyrofa> If you use that, you probably want a different base as well
<mup> PR snapd#3569 opened: snapd, snapctl: use json Decoder instead of Unmarshall <Created by stolowski> <https://github.com/snapcore/snapd/pull/3569>
<sergiusens> niemeyer: yes, we want multiple bases in that grammar
<mup> PR core-build#15 opened: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mvo_> jdstrand: I ported snap-seccomp to use the seccomp() syscall but no change, I dig some more
<mup> PR snapd#3567 closed: many: introduce and use strutil.ListContains <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3567>
<jdstrand> mvo_: did you also set the flag? the PR said to have to set tsync since seccomp syscall won't do it by default
<jdstrand> mvo_: I haven't done this myself; just going by that commit I referenced earlier
<jdstrand> but I did read tsync isn't set by default
<zyga> mvo_: jdstrand is right, the seccomp syscall just _lets_ you use the flag
<mvo_> jdstrand: yeah, tried that
<jdstrand> hmm, bummer
<mvo_> I dig some more
<jdstrand> mvo_: does libseccomp-golang use C to libseccomp?
<mvo_> jdstrand: yes
<jdstrand> mvo_: cause it might get back to the builtime checks for the kernel and tsync, where the 14.04 kernel doesn't have tsync
<mvo_> jdstrand: AIUI
<mvo_> jdstrand: indeed, I'm checking rightnow
<jdstrand> so libseccomp is built without it
<jdstrand> cool
<mvo_> jdstrand: well, I don't know yet, all I know is that porting to syscall seccomp did not help
<jdstrand> mvo_: yeah, the 'cool' wasn't 'cool' that it worked but that it was your next step :)
<mup> PR snapd#3542 closed: cmd,client,daemon: expose "force devmode" in sysinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3542>
<mvo_> jdstrand, zyga: I think I know what the tsync problem is - we run snap-seccomp from the core snap which was build with a libseccomp > 2.2 - in this case libseccomp-golang tries to enable the tsync bits. however this does not work on trusty and the libseccomp version we have there (2.1.1). I need to think a bit how to fix this
<mvo_> jdstrand, zyga: more tomorrow, need to go offline, thunderstorm is heading my way
 * zyga-suse thinks about what mvo said
<cachio> niemeyer, again, cannot Direct Disk boot a disk with no MBR
<niemeyer> cachio: Uh oh
<niemeyer> cachio: Which machine?
<cachio> niemeyer, sorry, different error
<cachio> cannot connect to linode:debian-unstable-64 (Spread-25): dial tcp 45.79.191.246:22: i/o timeout
<niemeyer> cachio: Ahh, okay
<niemeyer> cachio: Phew
<cachio> it is more sporadic, but I saw it twice
<niemeyer> cachio: That's one of those that we need to reproduce while keeping the system alive so we can have a look
<cachio> niemeyer, yes, continuosly monitoring the builds
<niemeyer> cachio: That alone won't help.. spread will kill the system once the test fails
<niemeyer> cachio: We need to reproduce with -reuse so we can dig in
<kyrofa> Hey cprov, I'm trying to upload a snap to a branded store via the web interface and I'm getting an Oops (Sentry id: 9b78868ed9a4429b8d600cec207974bc)
<kyrofa> Can't seem to get it to succeed
<kyrofa> noise][, nessita this ^^ is blocking me, can I get anyone to help?
<nessita> kyrofa, one sec, replying to the forum topic about this (brand store and pushes) :-)
<nessita> kyrofa, what snap, what store?
<kyrofa> nessita, kyrofa-store, snap name was just registered kyrofa-branded-test-snap
<nessita> kyrofa, do you have any special role in that store?
<kyrofa> nessita, I'm the owner
<kyrofa> Or admin, whatever
<nessita> kyrofa, you mean admin?
<nessita> right
<nessita> let's continue privately since this store is unlisted
<nessita> roadmr, hey, I have to EOD now, is there any chance you could follow up the issue that kyrofa is having? he is having a sentry issue on the uploader https://sentry.ols.canonical.com/canonical/snapcraft-dashboard/issues/1798/
<nessita> the sentry report is absolutely unhelpful
<roadmr> let's see
<roadmr> kyrofa: so..
<kyrofa> roadmr, all broken?
<roadmr> kyrofa: no idea :)
<kyrofa> Hahaha
<roadmr> kyrofa: what were you doing? just uploading a snap to that store?
<kyrofa> Yeah, that's it. Get an Oops every time
<roadmr> kyrofa: as nessita said, the sentry report is quite unhelpful, not sure if that's because the js client is outdated. So I'd need to repro it myself to get a peek at the js console
<roadmr> and then my inexperience with js will really show haha
<roadmr> kyrofa: but you can usually upload fine (e.g. to the ubuntu store)?
<kyrofa> roadmr, I typically use snapcraft to be honest
<kyrofa> roadmr, but I can't with brand stores, at least for the first
<roadmr> ok, let me see what I can find out
<roadmr> kyrofa: can you invite or add me (roadmr) to that store?
<kyrofa> roadmr, hmm.... I'm not sure how. When I hit "manage" I just see a bunch of interface checkboxes
<kyrofa> Err, review checkboxes
<roadmr> interesting.
<roadmr> kyrofa: let me see, maybe I can add myself
<roadmr> kyrofa: I'm building a snap to upload
<roadmr> kyrofa: hm... it works for me...
<roadmr> let me try something
<roadmr> kyrofa: which snap was this for?
<kyrofa> roadmr, I just registered it, kyrofa-branded-test-snap
<roadmr> ok... anything particular about the snap itself? (I was able to build/upload a dummy strict/stable test snap, no problem)
<kyrofa> roadmr, it's literally the output of `snapcraft init`
<kyrofa> With a changed name
<kyrofa> I tried with and without an app, just in case, no change
<roadmr> aha :) so close to mine
<roadmr> but mine is not published. Let me try that
<roadmr> kyrofa: :/ I hate problems I can't repro... ugh
<kyrofa> roadmr, yeah I feel ya
<roadmr> kyrofa: you say you get an actual oops? as in a 50x response and the ugly "oooops" page?
<kyrofa> roadmr, no, sorry, just the message "Oops! I'm broken. Here's the sentry ID"
<roadmr> oh, I see
<roadmr> kyrofa: so let's flip this around. You get this reliably? could you open your browser's dev console, retry the upload, then show me (pastebin for instance) any output in that window?
<kyrofa> roadmr, definitely, one sec. Do I need to be on the VPN?
<kyrofa> Or have we established that it isn't helpful?
<roadmr> kyrofa: no, not needed
<kyrofa> Okay, one sec
<roadmr> kyrofa: the thing is - if you're in the vpn then sentry.js can send its report to our sentry server. But the report has proven useless :) so it's not needed
<roadmr> raven.js actually... but anyway
<kyrofa> roadmr, http://pastebin.ubuntu.com/25034621/ ... that looks terrible though
<roadmr> it's javascript, how could it look any other way?
<roadmr> "Empty string passed to getElementById(). upload" seems to be it. The others I also get but they seem harmless
<kyrofa> Yeah that looked questionable to me as well
<roadmr> kyrofa: firefox? any chance you could try with the other browser?
<roadmr> (or chrome?)
<kyrofa> roadmr, indeed, firefox. I'll try chrome now
<roadmr> kyrofa: it's a shot in the dark and fwiw I also have firefox and WFM, but let's give it a try.
<kyrofa> roadmr, yeah that worked fine
<kyrofa> What the heck...
<roadmr> kyrofa: tell me about your plugins on firefox
 * kyrofa closes firefox and opens it again...
<kyrofa> roadmr, these: https://pasteboard.co/GzJy240.png
<roadmr> I opened that blindly, you could have rickrolled me :D
<kyrofa> Ha! /me makes a note for the future...
<roadmr> kyrofa: I'd suspect adblock or Ubuntu Modifications, if a restarted firefox still misbehaves I'd look at those two (and/or bisect which plugin may be giving trouble)
<roadmr> ok, not Ubuntu Modifications - I also have that and it's oK
<kyrofa> Not adblock either...
<kyrofa> I'll just through through disabling each one
<roadmr> kyrofa: ah also, the most basic check: Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
<roadmr> is what I have
<roadmr> (on 16.04)
<roadmr> kyrofa: if you do find a plugin is messing with uploads, please ping me so I can file a bug and we look into it
 * roadmr unpublishes his crappy snap from kyrofa's store
<kyrofa> roadmr, privacy badger!
<roadmr> ahh!
<kyrofa> Veerrrry interesting
<roadmr> that makes sense... let me install it and try to repro
<kyrofa> Looks like it's blocking google tag manager
<roadmr> aha.. and we added that somewhat recently (a few weeks ago IIRC)
<kyrofa> Hahaha, no, when I actually upload, it blocks apps.ubuntu.com!
<kyrofa> Err, upload.apps.ubuntu.com
<kyrofa> Tag manager has nothing to do with it
<kyrofa> If I allow upload.apps.ubuntu.com, it succeeds
<kyrofa> Wonder why that's on the blacklist
<roadmr> wow...
<roadmr> kyrofa: interesting, it works for me even with privacybadger installed...
<kyrofa> roadmr, once you upload, do you see upload.apps.ubuntu.com in the dropdown there?
<kyrofa> It completely blocked it for me
<kyrofa> But it sounds like it's letting it through for you
<roadmr> yep... kyrofa no, I don't see it in the badger dropdown
<kyrofa> Huh, interesting
<roadmr> kyrofa: I click where it says "upload", choose the file, then it uploads and enables the "Submit to store" button
<kyrofa> Once it uploads, check the dropdown again
<kyrofa> It didn't show up for me once I did that
<kyrofa> until once I did that*
<roadmr> I clicked "submit to store", the upload is complete and badger is still green
<roadmr> it shows stats.g.doubleclick.net 066-eov-335.mktoresp.com as potential trackers
<kyrofa> Huh. Weird. It's not blocking google tag manager either?
<roadmr> and three more which "don't appear to be tracking" (analytics, tagmanager, marketo)
<kyrofa> What the heck...
<kyrofa> It's working totally differently for me
<kyrofa> Wait, do you have do not track enabled?
<roadmr> kyrofa: no.. heh
<roadmr> kyrofa: version 2017.6.13.1
<kyrofa> Maybe that's it
<kyrofa> (I do)
<roadmr> how do I enable DNT?
<roadmr> oh that's a browser setting, right?
<kyrofa> Firefox preferences > Privacy > manage your Do No Track settings
<kyrofa> Yeah
<roadmr> ok, let's try nwo
<roadmr> now
<roadmr> wtf. No, it's still letting my upload through
<kyrofa> Man... no idea what's different, then
<roadmr> kyrofa: the badger's introduction suggests it has some sort of learning behavior. You've been using it for a while, while I just installed it
<roadmr> that may explain it...
<kyrofa> Hmm, good point
<kyrofa> Makes it tough to reproduce issues, huh?
<kyrofa> Regardless, I submitted a complaint via the addon, and now I know
<kyrofa> I wonder why it thinks upload.apps.ubuntu.com is tracking me
<roadmr> yeah... well if they think we need to change anything on our side, do let us know
<kyrofa> Will do
<roadmr> we absolutely need analytics, tag manager and marketo though :(
<roadmr> but upload.apps should not have any of that, it's just the bucket where snaps are uploaded/downloaded
<kyrofa> Blocking those things shouldn't break uploads though. And they're separate!
<kyrofa> Yeah
<kyrofa> Makes no sense
<roadmr> I'll probably keep the badger anyway - it's cute
<kyrofa> Yeah I kinda love it
<kyrofa> roadmr, thanks for all the troubleshooting :)
<roadmr> kyrofa: no probl, glad to be of help
<kyrofa> roadmr, can you verify something for me? The kyrofa-store should be inheriting snaps from the ubuntu store, right?
<roadmr> kyrofa: let me see
<roadmr> kyrofa: I don't see it inheriting anything, but I could be misreading the screen
<kyrofa> roadmr, hmm... can you change that for me? That's an option, right?
<roadmr> kyrofa: sure!
<kyrofa> roadmr, to be clear, that means stuff I add to the store is hidden from the ubuntu store, but not the other way around. Right?
<roadmr> kyrofa: right, AIUI
<kyrofa> Perfect, yeah that's what I want
<roadmr> inheritance works only in the direction of the arrow :)
<roadmr> kyrofa: done, can you check it's as you expect now?
<kyrofa> roadmr, by the way, I thought it was inheriting because I saw all the snaps I had in the ubuntu store there
<roadmr> hm. intereesting
<kyrofa> This could use some UX love
<roadmr> for sure :( yes, we need to revamp the stores ui and all
<roadmr> I think there's a bug for that down here, between this old trunk and this set of hockey sticks...
<kyrofa> roadmr, still not working the way I expect. I've created a model assertion that uses my store slug, but it can't find the "pc" gadget snap
<roadmr> no, seriously, I'm sure we have that in our backlog but priorities can get crazy and it keeps getting punted to the bottom
<kyrofa> Yeah I know how that goes
<roadmr> kyrofa: there should be a place where you can cherrypick which snaps are available, I don't think you inherit them all for free
<kyrofa> Ah, interesting
<kyrofa> Maybe "add packages to this store"
<kyrofa> Heeey, there we go
<roadmr> kyrofa: try it, if it still doesn't show I think I need to reindex your store
<kyrofa> roadmr, "Select a valid choice. u'pc' is not one of the available choices."
<roadmr> aha...
<roadmr> kyrofa: there's a crapload of snaps on the rightside of that thing, so I guess pc is not a valid choice because you're already inheriting it..
<roadmr> same with e.g. beagleblack, I can clearly see it's there so I can't readd it
<kyrofa> Hmm.... then why can't ubuntu-image find it...
<roadmr> kyrofa: probably the reindex thing, hang on
<roadmr> kyrofa: ugh, my docs are obsolete and I don't know how to trigger a reindex now
<kyrofa> Hahaha
<roadmr> snaps have individual "reindex" controls
<roadmr> I'm not about to go reindexing all the Ubuntu store packages :) but maybe we can index the ones you need right now
<kyrofa> Huh, interesting, okay. I just need pc and pc-kernel
<kyrofa> And core, I suppose
<roadmr> kyrofa: I've just set pc to be reindexed
<roadmr> kyrofa: can you check if it's installable now?
<kyrofa> Yes! Core is working as well
<roadmr> it is? WOW I didn't touch core!
<kyrofa> pc-kernel failed
<kyrofa> core is special, perhaps
<roadmr> ok, let me index that one explicitly
<roadmr> I'm pretty sure "core" is marked as essential and is there for all stores
<kyrofa> Yeah that makes sense
<kyrofa> roadmr, to clarify, would this reindex happen automatically if I was patient enough?
<roadmr> kyrofa: I don't think it would
<kyrofa> roadmr, is that just because you changed the inheritance type for me?
<roadmr> kyrofa: this changed recently; up until a few days ago there was a "reindex everything" admin action, but it's now gone
<roadmr> kyrofa: the instructions clearly say a reindex is needed when adding an inherited store, so I guess they are two separate actions...
<kyrofa> Interesting
<roadmr> where the instructions fail is where they don't account the fact that the "reindex the world" action was removed (or at least changed to a place where I was unable to find it)
<roadmr> kyrofa: the package index has just moved to a new set of services, so it may just be that it's somewhere I didn't know to look
<roadmr> kyrofa: meanwhile - try pc-kernel, I reindexed it 2 mins ago
<kyrofa> roadmr, yep, working now :)
<roadmr> kyrofa: awesome!
<roadmr> kyrofa: I'll find out how this indexing can be done in bulk
<roadmr> but tomorrow, as right now, the park awaits.
<roadmr> EOD, good night!
<kyrofa> roadmr, I'm unblocked, again, I appreciate your help! Enjoy the park
<roadmr> thanks kyrofa ! (btw I *just* found the new reindexing page :) I'll try it tomorrow. Cheers!
<mup> PR snapcraft#1390 closed: meta: bash completion support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1390>
<noise][> kyrofa - fwiw, roadmr was pretty much correct on everything. Changing store inheritance does require re-indexing, it's usually a set once and leave it kind of thing
<noise][> and yes, core is special and is always "cherry picked" even if you don't inherit any stores entirely
#snappy 2017-07-07
<mup> PR snapcraft#1395 opened: [WIP] python plugin: track the python packages installed during build <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1395>
<mup> PR snapd#3491 closed: snapd: generate snap cookies on startup <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3491>
<mup> PR snapd#3562 closed: systemd: add explicit sync to snapd.core-fixup.sh <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3562>
<mup> PR snapd#3570 opened: asserts: fix error handling in snap-developer consistency check <Created by atomatt> <https://github.com/snapcore/snapd/pull/3570>
<mup> PR snapcraft#1396 opened: rust plugin: unset http_proxy for test_cross_compile <Created by chihchun> <https://github.com/snapcore/snapcraft/pull/1396>
<mup> PR snapd#3571 opened: cmd/snap-repair: recover brand/model from /var/lib/snapd/seed/assertions checking signatures and brand account <Created by pedronis> <https://github.com/snapcore/snapd/pull/3571>
<mup> PR snapd#3572 opened: store: do not send empty refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3572>
<pedronis> pstolowski: hi, do you know who else is around today?
<pstolowski> pedronis, hi! probably just us
<pedronis> pstolowski: when you have a 2nd could you look at snapd#3572, it's tiny, and related to the first point here:  https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/44
<mup> PR snapd#3572: store: do not send empty refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3572>
<pstolowski> pedronis, sure will do. i'm in the perfect mood for reviews today ;)
<pedronis> thx
<pstolowski> pedronis, I think we will skip the standup?
<pedronis> if it's really just the two of us, yes
<pstolowski> pedronis, btw I asked for your ack on https://github.com/snapcore/snapd/pull/3501
<mup> PR snapd#3501: store: orders API now checks if customer is ready <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3501>
<pedronis> pstolowski: yes, if IÂ can look at it later
<pedronis> pstolowski: trying to finish a bunch of things IÂ promised to have PRs for before leaving on holidays
<mup> PR snapd#3570 closed: asserts: fix error handling in snap-developer consistency check <Created by atomatt> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3570>
<cachio> morphis, hey
<morphis> cachio: hey
<pstolowski> looks like there is one more working today, hey cachio !
<pstolowski> pedronis, ^
<cachio> morphis, yesterday gustavo asked to me to continue with the work you have done porting the tests to fedora
<cachio> hey pstolowski
<morphis> cachio: ah nice!
<morphis> cachio: it's for Fedora and openSUSE
<cachio> morphis, ok, did you push everything?
<morphis> cachio: a first set is at https://github.com/snapcore/snapd/pull/3505
<mup> PR snapd#3505: PLEASE IGNORE: Enable more tests for suse and fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
<cachio> morphis, good, I'll take this if you agree
<morphis> cachio: that would be awesome!
<cachio> morphis, ok, after this pr, did you have any plans?
<morphis> cachio: this PR only enables the first chunk of tests and only tests/main
<morphis> it leaves out the other test suites
<morphis> a lot of preparation for that landed already but it's now a step-by-step-process
<pstolowski> pedronis, hey, three of us today, wanna join HO?
<jdstrand> pstolowski, pedronis: hey, do you have any idea why with latest spread and unmodified upstream/master for snapd, why I would have this for spread tests: http://paste.ubuntu.com/25039266/. I ran get-deps.sh. It seems a problem with the debian packaging, but the tests pass in travis...
 * jdstrand is puzzled
<jdstrand> pstolowski, pedronis: if you don't know otoh, I can ask mvo or zyga on monday
<pstolowski> jdstrand, no idea, i haven't experienced it.. any leftovers in your git tree maybe? git clean .. ?
<jdstrand> pstolowski: it is a checkout of upstream/master... let me try
<pstolowski> jdstrand, i need to run a quick errand, bb in ~40. let me know how it goes, i'll also try it when i'm back
<jdstrand> pstolowski: I seemed to have some snap-confine tests lingering that were gitignored. hopefully that was it. thanks for the pointer! :)
<jdstrand> hmm, that wasn't it, but will try some other things
<morphis> cachio: do you need anything more from me?
<cachio> morphis, just to know if there is a step already planned after this PR
<morphis> cachio: you got my last messages before you left?
<cachio> no
<cachio> this is the last one morphis> cachio: that would be awesome!
<morphis> ah
<morphis> <morphis> cachio: this PR only enables the first chunk of tests and only tests/main
<morphis>  it leaves out the other test suites
<morphis>  a lot of preparation for that landed already but it's now a step-by-step-process
<pedronis> jdstrand: sorry, no idea, sounds a mvo question for next week
<cachio> morphis, nice
<jdstrand> pstolowski: fyi, it seems to be something in that tree. if I do a git clone anew, it works. so I'll do some diffing
<jdstrand> pedronis: thanks
<morphis> cachio: ping me if you have any further questions
<cachio> morphis, sure, thanks
<morphis> cachio: thanks for taking this further!
<cachio> morphis, yaw
<pstolowski> jdstrand, cool, so all good?
<mup> PR snapd#3572 closed: store: do not send empty refresh requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3572>
<pstolowski> pedronis, easy one if you have a speare moment today - https://github.com/snapcore/snapd/pull/3564
<mup> PR snapd#3564: tests: speedup prepare statement part 1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3564>
<jdstrand> pstolowski: not yet. I think it might be something down in vendor/
<pstolowski> jdstrand, ah! now I remember
<jdstrand> pstolowski: I'll get there. the only thing left in the diff is stuff in vendor/. I'll just blow it away and run govendor
<pstolowski> jdstrand, I hit this exact issue a month ago
<jdstrand> pstolowski: oh, do tell :)
<pstolowski> jdstrand, remove vendor alltogether, get-deps again. that's what mvo suggested to me
<pstolowski> it helped
<jdstrand> ah right, that was what I was going to try
<jdstrand> cool
<pstolowski> jdstrand, there was a change in on of these packages
<pstolowski> jdstrand, sorry it didn't occur to me earlier
<jdstrand> pstolowski: no worries at all. I actually improved how I do cleanups as a result, so that is good :)
<SylvieLorxu> Is there any way to just run snapcraft on Debian without the whole LXD container stuff? Debian Testing here
<jdstrand> pstolowski: fyi:
<jdstrand> 2017/07/07 15:18:27 Successful tasks: 1
<jdstrand> 2017/07/07 15:18:27 Aborted tasks: 0
<jdstrand> pstolowski: thanks for your help :)
<pstolowski> \o/
<mup> PR snapd#3573 opened: overlord: always try to get a serial, be lazy on classic with no special store, nor any snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573>
<mup> PR snapd#3564 closed: tests: speedup prepare statement part 1 <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3564>
<mup> PR snapcraft#1397 opened: waf: Enable cross-compilation support  <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1397>
<kyrofa> Hey jdstrand, pci[0-9]* matches like file globbing, not regex, right? pci, followed by a single number, followed by anything else?
<kyrofa> (talking apparmor here, sorry)
<jdstrand> kyrofa: yep
<kyrofa> Okay good
<kyrofa> jdstrand, thanks for the ping :)
<jdstrand> np :)
<jdstrand> kyrofa: also, /* matches any files in '/', /*/ matches any directories in '/' and /** matches all files, directories and any files and subdirectories under '/'
<jdstrand> kyrofa: I suspect that will come in handy with what you'll be looking at (there are plenty of examples of this in interfaces/builtin
<kyrofa> jdstrand, I actually understand those, because it LOOKS like globbing
<kyrofa> jdstrand, the other patterns look like regex, and fool me almost every time
<kyrofa> jdstrand, I spent a few minutes thinking the profile was totally broken because it wasn't accounting for colons :P
<jdstrand> kyrofa: man apparmor.d discusses AARE, but yeah, it looks like regex. if you don't do it all the time, it is easy to forget
<mup> PR snapcraft#1398 opened: tests: fix issues with python 3.6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1398>
<mup> PR snapcraft#1365 closed: Add Ruby Plugin <Created by jamesbeedy> <Closed by jamesbeedy> <https://github.com/snapcore/snapcraft/pull/1365>
<mup> PR snapcraft#1399 opened: plugins: add ruby plugin <Created by jamesbeedy> <https://github.com/snapcore/snapcraft/pull/1399>
#snappy 2017-07-08
<mup> PR snapd#3574 opened: snap find only searches stable <Created by stuartlangridge> <https://github.com/snapcore/snapd/pull/3574>
#snappy 2017-07-09
<mup> PR snapd#3575 opened: Show labels for built-in interfaces <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3575>
#snappy 2018-07-02
<mborzecki> morning
<mup> PR core#89 closed: hooks: fix 30-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/89>
<pstolowski> mornings
<zyga> good morning
<pstolowski> hey mborzecki
<mvo> hey pstolowski
<zyga> I'm just settling in
<zyga> what a terrible morning :|
<zyga> it's cold and wet and raining
<mborzecki> pstolowski: mvo: zyga: hey
<zyga> but that's just today, it will get better soon :)
<mborzecki> cold here, no rain though
<zyga> I'm _outside_
<mborzecki> zyga: haha :P
<zyga> not enough space to work indoors :D
<zyga> I will run make in a loop to keep me warm
<mborzecki> zyga: wear some kalosze :P
<mborzecki> wellington boots is the english name?
<mvo> zyga, mborzecki: good morning
<mcphail> mborzecki: i wonder if "galoshes" has the same etymology as kalosze?
<mborzecki> mcphail: where did you hear it?
<mcphail> galoshes are rubber overshoes/boots
<zyga> ok, breakfast and then work
<mborzecki> mcphail: hah, quite possible, probably sharing the same roots, my dictionary says polish kalosze came from italian caloscia, while for english galoshe i'd probably look for french roots (?)
<mborzecki> heh italian wiki mentions caloscia coming from french galoche
<mcphail> ah! good find :)
<zyga> mvo: back to remapping
 * zyga unchecks "use transparency from system theme" to make white gnome-terminal actually white and not dim gray :P
<mborzecki> guys, have you already enabled 2fa in github?
<mvo> zyga: yay, for some reason     - google:ubuntu-core-18-64:tests/main/snap-disconnect
<mvo>  
<mvo> zyga: its all in core18-all-fixes-all-tests
<zyga> mborzecki: I did some time in the past but disabled it later
<zyga> why, do we have to use it by policy now?
<zyga> mvo: what about it?
<mvo> zyga: it failed, I have not looked into the why yet
<mvo> zyga: I merged your latest bits (I think at least)
<zyga> I will finish with this PR
<zyga> oh
<zyga> merged where? master
<zyga> or into the helper branch
<mvo> zyga: into the core18-all-fixes-all-tests branch
<zyga> ok
<mvo> zyga: looking into a timezone control failure now first though
<zyga> mvo: I'd like to land the remapping through master
<mvo> zyga: oh, absolutely
<zyga> the helper branch has so much stuff it's hard to reason about sometimes
<mvo> zyga: this is just a test ground
<zyga> yep
<mvo> zyga: I cherry picked only
<mvo> zyga: so maybe that was the problme
<mborzecki> mvo: would you mind if i pushed a fix to #5436?
<mup> PR #5436: tests: add basic integration test for spread hold <Created by mvo5> <https://github.com/snapcore/snapd/pull/5436>
<mvo> mborzecki: not at all, please go ahead
<mvo> mborzecki: uh, silly me, thanks for spotting the typo
<mborzecki> snap snap :)
<zyga> we need another review on https://github.com/snapcore/snapd/pull/5432
<mup> PR #5432: cmd/snap-confine: fix snaps running on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5432>
<zyga> mborzecki: ^ perhaps you?
<zyga> mvo: I opnened the remapping PR, I will now focus on unit testing while spread is running
<mup> PR snapd#5439 opened: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
<zyga> mvo: it's the even more simple version of what you saw last week
<zyga> mvo: have you seen the mail from neal?
<zyga> sent yesterday at 16:22
<mvo> zyga: yeah, but have not really read it yet
<mwhudson> zyga: i keep thinking i should update snapd in debian and then finding something else to do
<zyga> mwhudson: yeah, I feel I should do it too
<mwhudson> i think some new deps need ITPing, sigh
<zyga> that's likely, we haven't been paying the ITP tax for a while
<mwhudson> it's not hard, just boring
<mwhudson> maybe i can dedicate some time to it after 18.04.1 is done
<zyga> brb
<zyga> somewhat less rain now
<mup> PR snapd#5440 opened: snapstate: allow setting "refresh.timer=managed" <Created by mvo5> <https://github.com/snapcore/snapd/pull/5440>
<mvo> zyga: replied to the question from neal, the only thing we do with nsswitch.conf is a bind mount into the snap client
<zyga> yeah, I replied as well, not on bugzilla as I cannot log in for some reason, I will reset my account later to fix that
<zyga> I think since there is no confinement some snaps may be fiddling with stuff
<zyga> but really why would they re-label something is unknown to me
<mvo> zyga: I suspect the re-label is a side-effect of e.g. editing the file maybe?
<zyga> maybe
<zyga> I don't know how labeling in selinux is expected to work
<zyga> is everything selinux aware or things break
<zyga> or is there some magic that makes vim just work without selinux specifc code in it
<zyga> I suspect the label is some default inherited from a parent directory
<zyga> maybe the fact that squashfs doesn't ship extended attributes and get some default labels is a factor
<Chipaca> hmm, bunch of refresh deltas spread tests failing
<zyga> travis log display is utter garbage
<zyga> it is so slow I cannot imagine we're the only one complaining about it
<Chipaca> zyga: we probably abuse it a bit too much
<Chipaca> i just click on raw as soon as it lets me
<zyga> yeah, probably optimized for 20 lines of output
<zyga> yeah, but even _that_ is slow to render
<zyga> (I mean, the raw button)
<mborzecki> anyone wants to take a look at #5435? simple but lengthy review
<mup> PR #5435: overlord/snapstate: introduce path to fake backend ops <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5435>
<mborzecki> btw. got 2 travis jobs that failed becase of 'no input received in 10 minutes'
<mborzecki> restated both already
<zyga> same
<zyga> though not restarted becaue working on more tests to push
<Chipaca> augh
<zyga> what's up Chipaca ?
<Chipaca> things that don't work as expected in Go because reasons
<Chipaca> in this case, umask :-)
<Chipaca> anyway, i'm off to the gym
<Chipaca> bbiab
<zyga> enjoy
 * zyga enjoys 13C 
<Chipaca> i won't, but i am enjoying my back not complaining all the time
<Chipaca> so, Â¯\_(ã)_/Â¯
<zyga> yeah
<zyga> that's creepy
<Chipaca> zyga: what's creepy?
<mborzecki> Chipaca: what's the issue with umask?
<zyga> one sec
<mborzecki> Chipaca: per thread/process again?
<Chipaca> mborzecki: only affects current thread
<Chipaca> yes
<mborzecki> omg
 * zyga looks for pastebin of pictures
<mborzecki> we need a separate goroutine for creating files/dirs :)
<zyga> Chipaca: https://imgur.com/a/MPXcDyj
<Chipaca> zyga: you don't have fonts-takao-pgothic?
<zyga> apparently :D
<mup> PR core#90 opened: hooks: fix silly copy/paste error from PR#89 <Created by mvo5> <https://github.com/snapcore/core/pull/90>
<zyga> this is in irccloud so maybe font issue?
<zyga> there is a thread about some apparently broken font sharing
<mborzecki> another stalled job
<mborzecki> https://travis-ci.org/snapcore/snapd/builds/399031115?utm_source=github_status&utm_medium=notification
 * zyga tries to understand the interface manager test setup code, lots of stuff there 
<mborzecki> Error executing google:arch-linux-64:tests/main/refresh-delta-from-core
<mup> PR core#90 closed: hooks: fix silly copy/paste error from PR#89 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/90>
 * zyga is slowly warming up thanks to hot coffee and loads of blankets
<mvo> hm, tests broken? all recent runs are "!"
<zyga> mvo: we noticed, timeouts for !known reason
<mvo> zyga: :(
<mvo> zyga: ok
<mborzecki> pstolowski: pushed a fix to #5434
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<pstolowski> mborzecki: thanks
<zyga> oh, I see the mail now
 * zyga goes to enable 2fa on gh
<pstolowski> yeah i just did
<pstolowski> although i wonder if i'm actually part of canoni org on gh
<pstolowski> i'm definately in snapcore org
<pstolowski> anyway... probably a good idea anyway
<zyga> ok,ddone
<Chipaca> another failed run wrt deltas
<mborzecki> 2018-07-02 10:24:42 Cannot allocate google:ubuntu-core-16-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
<zyga> mvo: I'm slowly making progress on testing the new ifacestate code
 * Chipaca hugs mvo 
<zyga> also more normal conditions now, with no rain and slowly raising temp
<Chipaca> gah, phone call. Need to step out for an hour more or less.
 * Chipaca should really have a shower before meeting people irl
 * Chipaca compromises
<zyga> Chipaca: I wonder if the compromise is on time or on people
<zyga> or does it involve showering a fraction of some kind
<mborzecki> i should probably add a label for parallel installs PR, there's quite a few of them
<zyga> what happens when a snap becomes inactive wrt snapstate
<zyga> is Active= false set
<zyga> or do we also change Revision/Channel when that happens?
<mvo> Chipaca: I appreciate the hug! any particular reason? or just sympathy for the broken tests?
<zyga> brb
<Chipaca> mvo: https://www.youtube.com/watch?v=OawrlVoQqSs
<Chipaca> mvo: in particular for pointing out that MATCH only reads its input once
<Chipaca> mvo: but in general, because why not
 * mvo hugs Chipaca 
<mvo> Chipaca: haha :)
<Chipaca> zyga: a compromise in that i'd be a little bit later than was expected of me, but i'd also be a little less smelly
<Chipaca> zyga: IOW a quick wash rather than a shower or nothing
<pedronis> zyga: in which context?
<pstolowski|denti> dentist apointment, will probably miss the standup
<Chipaca> pstolowski|denti: godspeed
<zyga> pedronis: I was looking at "representative" test cases for mocking state in my tests
<zyga> pedronis: I will show you soon in a PR diff
<pedronis> zyga: during a refresh we just  set Active = false and  remove the current link  (see doUnlinkCurrentSnap )
<pedronis> zyga: disable does that plus remove-profiles
<zyga> ah, that's good then
<zyga> thank you!
<pedronis> zyga: only discard and link-snap move/change Current
<mup> PR snapd#5441 opened: many: expose publisher's validation throughout the API <Created by pedronis> <https://github.com/snapcore/snapd/pull/5441>
<zyga> mvo, pedronis: initial PR with snapd/core connection re-mapping
<zyga> https://github.com/snapcore/snapd/pull/5439
<mup> PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
<zyga> I will now get some food and then focus on adding higher-level tests
<Chipaca> hmm, somehting's taking forever to reboot
 * Chipaca kills it and starts over
<niemeyer> Moins
<Chipaca> niemeyer: moin moin. How's things?
<niemeyer> Chipaca: Yo.. pretty good.. weekend was nice.. raining like crazy outside but I don't have to be there.. can't complain.. :)
<Chipaca> rain is nice when you don't need to be in it, yes :-)
<Chipaca> here we've been having ~30C sunny days, which is awesome
<Chipaca> (the locals are melting though)
<joc> niemeyer: hi, i tried making a case for not changing the name on the socketcan PR, if it doesnt convince you I can make the change though - also available for a call for next few hours if you want
<niemeyer> joc: Thanks, yeah, a call would be nice to figure out the other details
<niemeyer> joc: What's your tz?
<niemeyer> joc: My next couple of hours are meetings
<joc> niemeyer: if the details are around exactly what permissions to grant i think having jdstrand would be useful
<joc> niemeyer: i'm in London
<Chipaca> cachio: how long does the intial reboot of google:ubuntu-core-16-64 usually take, do you know offhand?
<cachio> Chipaca, no
<cachio> didn't measure it
<joc> i'm one of the locals who is melting
<niemeyer> joc: How's 17:30 your time?
<joc> niemeyer: yep, fine
<niemeyer> joc: Thanks, I'll put something in the calendar
<zyga> joc: melting? in UK?
 * zyga joined the standup early
<zyga> mborzecki: can you come, I want to see if my connection is OK
<joc> yep! but my liquefaction point is quite low ;)
<mborzecki> zyga: joining
<zyga> thx
<zyga> Chipaca: interesting
<zyga> function foo() { cat; }; function bar() { a=$(cat); echo "$a"; };  foo < /etc/passwd | wc -l ; bar < /etc/passwd | wc -l ; a=$(cat /etc/passwd); echo "$a" | wc -l; a=(cat /etc/passwd); echo $a | wc -l
<zyga> Chipaca: ^ so newlines are ok
<zyga> but you must do quoting correctly
<Chipaca> zyga: we might (although I checked and it seemd ok)
<Chipaca> zyga: we're doing: local stdin="$(cat)"; echo "$stdin" | grep -q -E "$@" || { echo "error..." }
<mborzecki> Chipaca: what if we did `grep --color=never '^test' /etc/passwd > ...`
<mborzecki> Chipaca: it's probably already doing iastty() but who knows :/
<mborzecki> s/iastty/isatty/
<Chipaca> mborzecki: even if that shell were using an alias (i don't think noninteractive shells are), --color=auto means it's not doing it on stdout that isn't a tty
<Chipaca> yeah
<Chipaca> but, we could
<Chipaca> we could also say \grep instead of grep
<Chipaca> mborzecki: lots of things to try, if only it weren't stuck :-)
<mborzecki> and then it's magically fixed and we don't know why
<mvo> Chipaca, cachio I have reproduced it locally, it reboots, no spread about and no network in the VM (I logged in via the virtual serial interface)
<pedronis> Chipaca: could you look at #5441 when you have a moment
<mup> PR #5441: many: expose publisher's validation throughout the API <Created by pedronis> <https://github.com/snapcore/snapd/pull/5441>
<Chipaca> pedronis: need to go to the boys' school, but will look on my return
<pedronis> thx
<mvo> Chipaca, cachio fwiw, it looks like netplan is misisng in edge right now
<cachio> mvo, so seems to besame issue we already saw for core 18, right?
<mvo> cachio: yeah, I saw that with core18 when I was developing on it and had no working network config yet
<mvo> cachio: I think I know what is going on, I'm rebuilding the core snap now, lets see if that fixes things, I tell you more once the build ran
<cachio> ok
<Chipaca> pedronis: actually had a few minutes and, well, +1 :-)
<mup> PR snapcraft#2167 closed: many: detect local source changes <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2167>
 * zyga -> taking the dog out 
<cachio> mvo, could be affecting some dependencies that we are installing to those imafes?
<cachio> images
<mvo> cachio: yes, I think thats exactly the problem
<mvo> cachio: if the rebuilds does it I will add code to the image build to ensure it fails if the dependencies do not work
<cachio> mvo, so, we need netplan as an estra dependency?
<cachio> mvo, tell me if I need to revert the last image
<mvo> cachio: give me 5 more minutes, running a test now
<mvo> cachio: maybe it was just core that was busted, if so I will push a PR with a test in the core build script to ensure this won't happen again
<cachio> mvo, nice
<mup> PR core#91 opened: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image <Created by mvo5> <https://github.com/snapcore/core/pull/91>
<mborzecki> mvo: that ppa is all that was needed?
<mvo> mborzecki: yeah, I think so, I'm looking at spread now to see if I can create a test case for the no-output issue
<mborzecki> magic :)
<mvo> mborzecki: heh, for some people thats their first name ;)
<ogra_>  hippie kids though ...
<ogra_> :)
 * zyga testing
 * Chipaca tea
 * cachio lunch
<Chipaca> pedronis: #5441 gtg
<mup> PR #5441: many: expose publisher's validation throughout the API <Created by pedronis> <https://github.com/snapcore/snapd/pull/5441>
<pedronis> thx
<mup> PR snapd#5441 closed: many: expose publisher's validation throughout the API <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5441>
<mup> PR snapd#5442 opened: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5442>
<pedronis> mvo:  I created the backported cherry-pick for it ^
<mvo> pedronis: thank you
<zyga> mvo: question, should I aggregate all snapd-interfaces patches in one PR where they can be realistically tested or shall we land smaller PRs and wait till enough are present to write bigger tests
<mvo> zyga: what is pending? I mean beside the work on 5439?
<mvo> zyga: ideally smaller ones and we test via the core18-all-tests pr
<zyga> mvo: I'd like to write unit tests but now I think I need more from the PR with "snapd-makes interfaces show up"
<zyga> specifically, to write more useful tests for PR 5439
<mup> PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
<mvo> zyga: ok, I think also we need more, I merged 5439 and it fails on core18, but maybe I can whitelist the snap-connect test on core18
<mvo> zyga: let me try this
<mvo> cachio, niemeyer : I think the spread reboot hang issue is found https://github.com/snapcore/spread/pull/61
<mup> PR spread#61: client: fix dialOnReboot() if the remote does not reply <Created by mvo5> <https://github.com/snapcore/spread/pull/61>
<mvo> cachio: I tested using a spread qemu test that "rm -f /etc/interfaces.d/*; REBOOT"
<niemeyer> mvo: Wow, nice debugging there, thank you!
<mvo> niemeyer: thank you, it was fun to debug. I am looking into a unit test now
<zyga> mvo: I'm cherry-picking patches from the WIP branch to improve
<mvo> zyga: \o/
<mvo> niemeyer, cachio I pushed PR#62 to spread with a simple unit test, let me know if I you prefer to clean it up a bit more, this was the smallest diff I could come up with for the test
<niemeyer> joc: https://meet.google.com/muo-bdbu-fgo?authuser=0
<niemeyer> mvo: Thank you
<mvo> niemeyer: and no rush, I know you are super busy
<Son_Goku> zyga: https://pagure.io/flock/issue/24
<zyga> interesting, we should attent
<zyga> attend*
<niemeyer> mvo: No problem, and thanks for the test.. curious to see how you've put that in.. I thought it'd be trickier to have the ssh reboot semantics tested
<ElDiabolo> Hi. I have installed a service using snap and then found it runs as root. Is this expected behavior? I understand snap uses apparmor for security, so this _might_ be OK.
<zyga> ElDiabolo: hey, this is expected, yes
<zyga> ElDiabolo: the service runs with seccomp profile limiting the system calls it can use, it runs in a device cgroup which limits the system devices that it can access and (on many systems) it also runs with an apparmor profile which limits many things including files that can be read or written, network operations that can be performed, ipc operations that can be performed and more
<mup> PR snapd#5443 opened: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5443>
<ElDiabolo> zyga, Ah, OK. It does however break with several decades of unix tradition. My first reaction to this was "we won't use that".
<ElDiabolo> zyga, I don't want to start a discussion on that, just wanted to point out that people with a certain experience will ract the same.
<zyga> mvo, pedronis: I think this is ready to review and could land quickly (5443)
<ElDiabolo> s/ract/react/
<ElDiabolo> zyga, thx for the info.
<zyga> ElDiabolo: instead of using unix users for privilege separation we use way more things that actually separate apps from the system and from each other; The reaction is understood, eventually we should teach ps and friends to display various confinement labels to make this clearer
<Chipaca> zyga: ElDiabolo: ftr we will be adding run-this-service-as-a-user support at some point (but it's not on the roadmap yet)
<zyga> ElDiabolo: right, this will create non-root users for certain snap services but really, it's just for compatibility (some software checks for this) than actual sandboxing because it's an opt-in from a snap developer
<ElDiabolo> Thx. Train arrives, I'm out.
<Chipaca> also some open questions as support for high uids is iffy
<Chipaca> :-)
<Chipaca> speaking of trains, I need to go make dinner
<Chipaca> ttfn
<zyga> one of my laptops used to be called iffy
<Chipaca> zyga: was it super reliable
<zyga> yes but was very ugly
<zyga> it was a CE test laptop
<zyga> still have it in a box somewhere
<Chipaca> zyga: CE as in Windows CE? or as in Customer Engineering?
<zyga> as custeng
<zyga> it's pink
<mvo> zyga: aha, I think this might be the missing piece
<mvo> zyga: feel free to merge into core18-all-tests and push
<zyga> mvo: I'm chopping the WIP branch, one more and I'll close it
<zyga> each of the new pieces should be mergably by itself
<zyga> and then you can drop all my patches from the integration branch and just merge (rebase) master
<zyga> ok
 * zyga -> quick supper
<zyga> back,
<zyga> not used to doing dishes by hand sans a dishwasher but what can I do ;-)
<cachio> mvo, hey
<cachio> Irunning sru I see a weird error just on artful
<cachio> using ubuntu software
<cachio> I see segfault when I search "snapd" in ubuntu software
<cachio> and it closes
<cachio> mvo, still researching it
<cachio> the rest of the validation is done and it is ok
<mvo> cachio: thanks! thats strange
<cachio> mvo, https://docs.google.com/document/d/1WZqYRPNeXIsjgB68GyhMTHY3F5Jema2zEp850wbP9OQ/edit?usp=sharing
<cachio> mvo, these are the results
<mvo> cachio: thanks, I have a look in a bit or in my morning
<cachio> sure, I'll try to reproduce it with a new vm
 * zyga still works on unit tests and refactoring to make it easier
<zyga> cachio: see if journald says anything about where gnome-software crashes if you can
<cachio> zyga, dame info
<cachio> than syslog
<niemeyer> jdstrand: Do you have a moment for us to catch up today?
<mup> PR snapd#5438 closed: many: run all of main against core18  <Core18> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5438>
<jdstrand> niemeyer: yeah. note I responded to the 'can' PR
<jdstrand> niemeyer: I think we'd want joc too since I not particularly familiar with 'can'
<jdstrand> niemeyer: we kinda came up with the approach together
<niemeyer> jdstrand: I had a good call with him today already
<niemeyer> jdstrand: We can do a quick sync and follow up with him later
<niemeyer> jdstrand: https://meet.google.com/tos-ipox-piw
<jdstrand> ok, just a sec
<jdstrand> dang it. darn webcam
<cachio> zyga, well
<cachio> I can reproduce the seg fault on a clean machine
<cachio> but not need to update snapd
<cachio> I installed artfull desktop
<cachio> search for snapd
<cachio> and that0s it
<cachio> mvo, core snap 2.33.1 in stable channel
<mup> PR snapd#5444 opened: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5444>
<mvo> cachio: yay, thank you
<cachio> mvo, sru completed
<cachio> the issue I found is not related to 2.33.1
<cachio> it is present in old snapd versions as well
<mup> PR snapd#5445 opened: tests: add artful for sru validation on google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5445>
<mup> PR snapd#5444 closed: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5444>
<mup> PR snapd#5446 opened: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5446>
<mup> PR snapd#5447 opened: snap,interfaces: move interface name validation to snap <Core18> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5447>
<mup> PR snapd#5432 closed: cmd/snap-confine: fix snaps running on core18 <Core18> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5432>
<mup> PR snapd#5435 closed: overlord/snapstate: introduce path to fake backend ops <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5435>
<mup> PR snapd#5437 closed: tests/lib: sync the file before checking its contents <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5437>
 * zyga hugs chipaca
<zyga> sorry :)
<zyga> jdstrand: could you please enqueue https://github.com/snapcore/snapd/pull/5443
<mup> PR #5443: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5443>
<zyga> it's a simple change but I wanted you to ack it just in case
<jdstrand> zyga: ok
<zyga> thank you
 * zyga EODs
#snappy 2018-07-03
<mup> PR snapd#5448 opened: tests: start using the new opensuse image with test dependencies <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5448>
<mborzecki> morning
<pstolowski> mornings
<mborzecki> pstolowski: hey
<zyga> Hey ho
<zyga> A bit late today,
<zyga> mvo: I went on a small detour to simplify some code and add tests
<zyga> I have some misc branches and then more meat
<zyga> (Rice, soy, ...)
<mvo> zyga: hey, thanks
<zyga> I was working towards testing all of the patches properly
<zyga> Out of the interface WIP one
<mvo> zyga: neat
<mborzecki> mvo: zyga: hey guys
<mvo> hey mborzecki
<mborzecki> mvo: i'm looking at sysctl manpage, have you checked that sysctl -p <file> with <file> as separate arg, not -p<file> works?
<mvo> mborzecki: the test will check, I have not, let me try that now
<mborzecki> i have a vague recollection of something being iffy there, but that's from a few years back and with busybox
<mvo> mborzecki: I did a quick test and it seems to be fine
<mborzecki> mvo: ok :)
<mvo> mborzecki: but the test will also fail if it is not
<Gargoyle> Can you check the confinement of a snap before you install it? I can't see anything in "snap info x" or another obvious snap command.
<mborzecki> Gargoyle: try snap info --verbose
<Gargoyle> Cool. Ta. :-)
<mup> PR snapd#5447 closed: snap,interfaces: move interface name validation to snap <Core18> <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5447>
<mborzecki> mvo: could you take a look at #5434?
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<mvo> mborzecki: sure
<mborzecki> mvo: ta
<zyga> mvo: thanks for that!
<mup> PR snapd#5449 opened: snap: add helper for renaming slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5449>
<zyga> mvo: that's one of the helpers ^
<zyga> pedronis: could you please look at https://github.com/snapcore/snapd/pull/5443 - it has two reviews already but I wanted to ensure you ack it
<mup> PR #5443: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5443>
<zyga> mvo: quick review on https://github.com/snapcore/snapd/pull/5446
<mup> PR #5446: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5446>
<mup> PR snapd#5445 closed: tests: add artful for sru validation on google backend <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5445>
<mvo> zyga: aha, nice. yeah, initially I wanted to do ipv4/ipv6 but then a) YAGNI b) ipv4 is not as straightforward
 * Chipaca waves
<mborzecki> Chipaca: hey, now that you're here, would you mind taking a look at #5426? :)
<mup> PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<Chipaca> mborzecki: no
<zyga> mvo: it's fine not to do ipv4
<Gargoyle> Discord have both beta and "bleeding edge" versions available, is it possible to get these wired up into the snap?
<Chipaca> Gargoyle: depending on who's doing the snapping, those can be tracks or just the pre-existing risks
<Gargoyle> Not sure what that means! :/
<zyga> Gargoyle: if the people making the snap want to, they can do that with snaps
<zyga> Gargoyle: they can offer a beta channel/track
<zyga> Gargoyle: and an "edge" channel/track
<zyga> Gargoyle: alongside stable, that is
<zyga> and people installing the snap can choose which one to get
<Chipaca> Gargoyle: you can look at the 'go' snap for (a rather extreme) example
<Chipaca> Gargoyle: you can get anything from 1.6 to devel, in a snap
<zyga> Chipaca: and by look we mean "snap info go"
<Chipaca> zyga: or gnome software, or https://snapcraft.io/go (and click on 'all versions')
<Gargoyle> That's a lot of options! :D
<zyga> Chipaca: I wonder if we will ever need to do paging on "snap info" ;-)
<zyga> Chipaca: hum
<zyga> Chipaca: why is 1.10 above 1.11?
<pedronis> mborzecki: I did a pass over #5434
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<zyga> Chipaca: do we need number sorting there?
<mborzecki> pedronis: thanks!
<zyga> (actually the ordering of tracks is a bit weird in general)
<Chipaca> zyga: there is no order to tracks yet
<pedronis> zyga: we don't know how to sort them,  last time we had a discussion with Chipaca and other store people, we need a sort order defined in the store
<Chipaca> zyga: there probably will be at some point, but that point is still in the future :-) AFAIK at least
<zyga> Chipaca: should we version sort them "just in case"
<pedronis> the result we get from the store are sorted
<zyga> aha
<zyga> I see
<Chipaca> well
<pedronis> except they are lexically sorted atm
<Chipaca> they are _ordered_, which is more important
<zyga> re-sorted by us or by the store?
<Chipaca> :)
<pedronis> no, that's the point
<Chipaca> if snapd is sorting them, it shouldn't be
<zyga> ok
<Chipaca> snapd gets them with a defined order and should leave it alone
<pedronis> there's a store order (is just not a good one)
<pedronis> but we should't try to fix that
<pedronis> it's up to the store
<Chipaca> (to answer whether snapd sorts them i'd need to look at the code)
<zyga> agreed
<Chipaca> OTOH, snapcraft.io and 'snap info' show a different order
<Chipaca> so that's a separate issue i'm chasing down
<Chipaca> (it just so happens to be a nicer order! grrr)
<Chipaca> (for go, on snapcraft.io)
<mborzecki> pedronis: yeah, the non-test code setting InstanceKey in either snapsup or snapst lives here atm https://github.com/bboozzoo/snapd/commits/bboozzoo/parallel-install-overlord
<Chipaca> pedronis: ETOOMANYCHANNELS
<Chipaca> er
<Chipaca> mborzecki: ^
<Chipaca> :)
<mborzecki> heh
<zyga> pretty please https://github.com/snapcore/snapd/pull/5449 :)
<mup> PR #5449: snap: add helper for renaming slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5449>
<zyga> it's short and test code
<zyga> mvo: thank you for the update, two more comments on 5446
 * zyga coffee
<mup> PR snapd#5450 opened: store: keep all files with link-count > 1 in the cache <Created by mvo5> <https://github.com/snapcore/snapd/pull/5450>
<mborzecki> pedronis: pushed a fix to #5434, i've tweaked the error message a little, added some tests
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<zyga> mvo: one last comment on 5446,
<pstolowski> dog emergency, need to go to vet
<mvo> zyga: thanks for your comment. this is a bit tricky, if things get removed sysctl -p won't work. on removal the system default is used. we can make this explicit but it has the side-effect that there will always be a sysctl file created even with an empty config
<mup> PR snapd#5451 opened: interfaces: honor static attributes when reloading conns <Created by stolowski> <https://github.com/snapcore/snapd/pull/5451>
<zyga> pstolowski|vet: interesting, reading
<mvo> zyga: I commented, I can rework the code accordingly
<mvo> zyga: I think it makes sense, will do so in a wee bit
<zyga> thank you, looking
<zyga> mvo: I commented as well, let me know where you want to take this
<zyga> mborzecki: replied on your comment on RenameSlot
<ogra_> mvo, not sure you have noticed, ppc64el and s390x daily core snap builds failed (looks like a gpg error)
<mvo> zyga: thanks, I updated the code now, I think we are fine with EnsureDirState and a bit of extra smarts, I pushed a new revision, please let me know if I overlooked anything but I think we should be fine now
<mvo> ogra_: you mean the builds in https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=snapd&field.status_filter=&field.series_filter= ?
<ogra_> mvo, https://launchpad.net/~snappy-dev/+snap/core/+build/267041 and https://launchpad.net/~snappy-dev/+snap/core/+build/267042
<mvo> ogra_: they are flaky on these arches but not consistently  failing? or am I looking at the wrong place maybe?
<mvo> ogra_: aha, the core snap, let me check
<ogra_> it is the first build error i have seen in a while
 * mvo looks
<ogra_> noit flaky usually ...
<cjwatson> ogra_,mvo: Those are transient failures due to known keyserver network chaos
<ogra_> *not
<cjwatson> just retry
<ogra_> ah, great
<mvo> thanks cjwatson
<ogra_> yeah, i noticed a ton of livefs mails too
<cjwatson> AIUI somebody discovered that you could upload a gigabyte key to the keyserver network and have it kill stuff
<cjwatson> or something along those lines
<ogra_> lol
<mvo> *cough*
<cjwatson> the livefs stuff is different and I'm investigating
<ogra_> ah, k
<mup> PR snapd#5428 closed: devicestate: fix panic in firstboot code when no snaps are seeded <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5428>
<zyga> mvo: looking
<zyga> mvo: it is good
<zyga> mvo: I suggested one more tweak to make it more clear why this happens
<zyga> but logic wise it is correct
<zyga> smart way of doing that btw :)
<zyga> cjwatson: so gpg network is the new bittorrent?
<cjwatson> hopefully not ...
<mvo> zyga: sure thing, thank you
<popey> niemeyer: any chance we can bump the largest post size from 32000 to ~40000 on discourse. I'm trying to migrate a large doc to the site, but it's ~35K
<niemeyer> Heya
<niemeyer> Which doc is that?
<popey> https://github.com/snapcore/snapd/wiki/REST-API
<popey> it's the last one still on the wiki
<popey> well, last one linked on the front page of the wiki
<niemeyer> popey: I think we should break it down a bit on the way in, even so we can read it reasonably
<niemeyer> popey: IIRC I provided an outline of how to break it down in the thread where we discuss the doc site
<popey> that seems reasonable.
<niemeyer> popey: We don't need to break it down every single section, but rather by area of interest or something similar
<popey> Robert seems to "own" that doc. I'd rather he broke it up and kept owning it
<niemeyer> popey: Thanks for the work on that, btw
<popey> I'll drop Robert a mail as he's in another TZ
<popey> thanks
<niemeyer> popey: np, and if you want I'd be happy to work with you on that migration.. it's been pending for too long
<zyga> mborzecki, mvo: can you please look at https://github.com/snapcore/snapd/pull/5449
<mup> PR #5449: snap: add helper for renaming slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5449>
<zyga> I have a pair of follow ups on top
<zyga> hmm
<zyga> journalctl fails to restart https://www.irccloud.com/pastebin/w7dISItk/
<zyga> have you guys seen that before ^
<zyga> journalctl failing to _restart_ ?
 * zyga -> walk
<mborzecki> zyga: yes, seen it before
<niemeyer> mvo: Heya
<niemeyer> mvo: One question on spread#61
<mup> PR spread#61: client: fix dialOnReboot() if the remote does not reply <Created by mvo5> <https://github.com/snapcore/spread/pull/61>
<mborzecki> parallel installs will be fun to merge/resolve conflicts :/
<mup> PR snapd#5452 opened: store, overlord/snapstate: introduce instance name in store APIs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5452>
<mborzecki> pedronis: Chipaca: probably something for you guys ^^
<mborzecki> it's very likely this will conflict with changes i wanted to open for review after landing #5434
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<mborzecki> pedronis: you've seen part of the store changes 2-3 weeks ago, most of it is the same patches just updated to account for downloads + some extra adjustments
<zyga> re
<zyga> MATCH mystery again https://www.irccloud.com/pastebin/p8HCgyXK/
<pedronis> mborzecki: well, IÂ should probably land my other PR and then it will likely conflict
<mborzecki> pedronis: no worries, i'll keep resolving the conflicts as they come
<zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/5449 quickly
<mup> PR #5449: snap: add helper for renaming slots <Created by zyga> <https://github.com/snapcore/snapd/pull/5449>
<mborzecki> Chipaca: did you manage to come up with anything regading 'the mystery of MATCH' yesterday?
<Chipaca> mborzecki: no, i didn't carry on digging
<Chipaca> falling too far behind with warnings
<mborzecki> ack
<zyga> thank you mborzecki  :)
 * zyga looks at the diff from the upcoming branch and is very happy
<mup> PR snapcraft#2175 opened: ci: disable osx tests until a new pyyaml is released <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2175>
<mvo> zyga: sure, I have a look
<mvo> zyga: match mystery> I think your idea to hexdump the output we got is interessting, maybe there is some whitespace mangling going on
<mborzecki> mvo: travis hides certain characters in the output log, though i'm not sure if the same applies to the raw log
<Chipaca> mborzecki: mvo: I did 'od -a' the file fwiw
<Chipaca> and it was fine
<Chipaca> (i thought i'd told you this yesterday0
<Chipaca> )
<Chipaca> why haven't i had lunch yet?
<Chipaca> also, where has my morning gone
 * Chipaca scrambles to get lunch
<zyga> mvo: I honestly don't believe my theory anymore
<zyga> mvo: I bet I will be surprised by the _actual_ issue
<mup> PR snapd#5449 closed: snap: add helper for renaming slots <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5449>
<zyga> joining
<mup> PR snapd#5453 opened: interfaces: tweak tests to have less repetition of "core" and "ubuntuâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5453>
<zyga> mvo: ^ the small refactor for the disconnect/connect resolve with snapd awareness
<zyga> the patch on top of this one is the main part of the WIP branch that was still pending
<zyga> so very close with getting all of that out
<zyga> I will prepare a branch that is derived from your integration branch where I have the new patch set (from master) and see how things are going
<zyga> I didn't manage that last night, sorry
<Chipaca> cachio: the Software crash, is that in 18.04?
<mvo> Chipaca: artful iirc
<mborzecki> zyga: hmm https://paste.ubuntu.com/p/CNqt2p6gj8/
<zyga> oh
<zyga> weird
<zyga> ah, sorry
<zyga> I didn't read this righ
<zyga> *right
<zyga> this is a bug
<zyga> caused by >1 instance of "change to this directory and then back"
<zyga> without handling the error by going to the void
<mborzecki> heh lucky me
<zyga> is this new?
<Chipaca> zyga: why is this a bug?
<Chipaca> it's in /tmp
<mborzecki> zyga: dk, tried to figure out why shellcheck in tests/unit/go does not work
<zyga> Chipaca: because the correct behavior was (and it worked before) to go to /var/lib/snapd/void
<Chipaca> zyga: ahhh
<Chipaca> zyga: maybe /var/lib/snapd/void doesn't exist?
<zyga> Chipaca: yes but the /tmp inside the snap is different and cannot contain what is on the host (it's a private tmp)
<zyga> Chipaca: oh, that's interesting
<zyga> does it mborzecki /
<mborzecki> zyga: it does drwxr-xr-x 2 root root  4096 Jul  3 12:36 void
<mborzecki> try it locally
<zyga> the permissions are wrong
<zyga> anyway, that's something to add to the queue
<zyga> probably a fallout of something that happened recently
<mborzecki> running it outside of tmp at least once makes the problem go away
<zyga> this implies the problem is in the first part of the setup code
<zyga> mvo: https://github.com/snapcore/snapd/pull/5446#issuecomment-402155147
<mup> PR #5446: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5446>
<mvo> zyga: yeah, just noticed and looking
<mvo> zyga: fixed, it was just that the output of sysctl has some extra whitespace
<mvo> zyga: did you tag all PRs that help with the iface renames as core18?
<mvo> zyga: if so, I will merge and run them now against core18
<zyga> no, not yet, hold on
<zyga> I didn't open all of them due to stacking
<mborzecki> zyga: https://paste.fedoraproject.org/paste/4hQSsupdzQNcvvbwpZlhUA makes it go away
<cachio> Chipaca, it is on 17.10
<Chipaca> just finished installing it
<Chipaca> (because why not)
<mborzecki> zyga: or https://paste.ubuntu.com/p/yWyRj3Pqqj/ no clue why fpaste is so slow today
<Chipaca> cachio: and you start 'ubuntu software', and search for 'snapd', and the UI crashes?
<mborzecki> zyga: why does it even bother chdir()ing in setup_private_mount() while it done so in sc_populate_mount_ns() already
<mvo> zyga: no worries, I think I found the relevant ones
<zyga> I haven't opened all of them
<zyga> I actually wanted to ask you
<zyga> well, tell you
<mvo> zyga: aha ok
<zyga> I'll create a branch from your working one but replace the older versions of the patches as I said in the standup
<zyga> it's fine to test what you made, let's where it gets
<zyga> but I want to have a clean picture of the patches that are not in master
<zyga> (a list that shrinks rather than grows0
<mvo> zyga: ok, it might be easier to use core18-all-fixes-all-tests-2
<mvo> zyga: which is a clean master with just all the core18 PRs
<zyga> sure, I'll use that
<pstolowski> cachio: can #5391 land?
<zyga> nice
<mvo> zyga: and it also enables all core18 tests
<mup> PR #5391: tests: simplify econnreset test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5391>
<cachio> pstolowski, yes
<pstolowski> thanks
<mup> PR snapd#5391 closed: tests: simplify econnreset test <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5391>
<zyga> pedronis: thank you for the comments! I'm on that now
<zyga> mborzecki: we need to rework more code I'm afraid, to get the right "way" of handling that error
<mborzecki> zyga: i can open a PR with http://paste.ubuntu.com/p/XvBhhFSMk8/ which resolves the issue, the question is why it tries to chdir into the old cwd while doing that, since it's already being restored at the end
<mvo> pedronis: zyga: core18 meeting
<zyga> mborzecki: later
<zyga> ack
<mup> PR snapd#5369 closed: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5369>
<mup> PR snapd#5453 closed: interfaces: tweak tests to have less repetition of "core" and "ubuntuâ¦ <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5453>
<zyga> mvo: thank you for the review, one more for implicit operations this time ^
<zyga> well v
<zyga> 5454
<mup> PR snapd#5454 opened: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5454>
<Chipaca> cachio: how do I reproduce the crash?
<cachio> just open ubuntu software
<Chipaca> cachio: done
<cachio> and search "snapd"
<Chipaca> cachio: done
<Chipaca> cachio: â¦ and the crash?
<mvo> zyga: thanks, looking
<cachio> Chipaca, did it return results?
<cachio> for me, it closed the app
<mvo> zyga: also, please share the run results if you run the full tests with your PRs against core18, maybe there is some stuff that I need to tweak
<Chipaca> cachio: yes
<Chipaca> cachio: with what version of snapd?
<cachio> try again
<cachio> I try with the 2.38.*
<cachio> and with 2.33.1
<cachio> 2.28 sorry
<Chipaca> cachio: this is snapd from the package, yes?
<cachio> yes
<Chipaca> cachio: I get 2.32.9+17.10 from the archive
<Chipaca> cachio: where do i get 2.28 from?
<zyga> mvo: yes, I will share the results, I need to spend some time to prepare the branch
<cachio> 1 sec
<Chipaca> cachio: ah, i can get 2.28.5 from artful/main (as opposed to artful-updates/main)
<cachio> I have 2.28.5+17.10
<Chipaca> cachio: yes, taht's the one in artful/main (you've not updated)
<ogra_> mvo, zyga i recently see this (not sure if it was there before) when starting a core 16 edge image on my pi's https://paste.ubuntu.com/p/gGKBBSG4nB/ ... the system seems to behave normally but it prints in red during boot so it is pretty noticeable
<Chipaca> cachio: apt update && apt upgrade should get you 2.32.9
<Chipaca> cachio: in any case, it worked ok with both
<Chipaca> cachio: also with core from edge
<Chipaca> so I don't know what I'm looking for
<cachio> Chipaca, it is failing here
<cachio> perheps it is a different version of ubuntu software
<cachio> did you search for something else and then "snapd"
<cachio> ?
<cachio> Chipaca, I just got distro_install_package google-compute-engine
<cachio> sorry, seg fault
<zyga> ogra_: that's very interesting
<zyga> can you provide journal data from that service?
<cachio> Chipaca, [  173.948719] pool[1815]: segfault at 0 ip 00007fdea83ec1f0 sp 00007fde6effc7e8 error 4 in libglib-2.0.so.0.5400.1[7fdea83b2000+111000]
<cachio> Chipaca, gnome-software 3.26.1
<zyga> ogra_: thank you for reporting this
<mup> PR snapd#5455 opened: many: assorted shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5455>
<Chipaca> cachio: how much memory in your vm?
<cachio> 2GB
<Chipaca> cachio: can you try with 4?
<cachio> sure
<Chipaca> cachio: gnome-software is that same version here
<Chipaca> cachio: it doesn't crash here with 2 either though
<cachio> Chipaca, weird, I'll update snapd and retry
<cachio> Chipaca, perhaps we are using different artfull images
<Chipaca> cachio: I'm just running it with kvm after installing it from the artful desktop iso, so yeah
<Chipaca> cachio: how are you running yours?
<cachio> same, but using virtual machine manager
<zyga> "options matteR"
<Chipaca> zyga: -march=broken
<cachio> Chipaca, after upgrade all the packages the ubuntu software does not crash anymore
<Chipaca> cachio: i'm not sure if that's a win or a lose
<cachio> did you upgrade before trying to reproduce it?
<zyga> Chipaca: virtio/accel all kinds of visual magic nobody knows how to run by hand
<mup> PR snapd#5411 closed: many: remove core-support interface <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5411>
<Chipaca> cachio: I think I checked the "download ugprades while installing" checkbox
<Chipaca> cachio: should I try again without that?
<Chipaca> (i then also upgraded, and then tried with snapd from edge)
<Chipaca> (i didn't understand exactly what you're trying to do so i covered most things)
<Chipaca> i can easily re-install it without the upgrades checkbox
<cachio> Chipaca, I don't know which is the error, if we need to fix something og it is already fixed :(
<Chipaca> cachio: when you installed, did you check the 'download upgrades' button?
<cachio> no
<Chipaca> i'll try without that
<cachio> basically, I installed as clean as possible
<cachio> then I reproduced the error
<Chipaca> cachio: and what is the error blocking us from doing?
<cachio> Chipaca, well, for sru we have a test which searches "snapd"
<cachio> and then install test-snapd-tools
<cachio> and it was failing
<Chipaca> cachio: but for the sru test you've upgraded snapd to the sru version, right?
<cachio> yes
<cachio> it is also happening for 2.33.1
<cachio> I just upgraded snapd
<cachio> not all the packages
<Chipaca> cachio: so it's not happening for you with 2.28.5?
<ogra_> pedronis, hmm, should the connections: keyword in gadget.yaml work with the snapd in beta ? ubuntu-image gets me:
<ogra_> gadget.yaml parse error: Invalid gadget.yaml @ connections
<cachio> Chipaca, yes
<Chipaca> cachio: yes it isn't?
<cachio> it happes
<cachio> happens
<Chipaca> â¦
<Chipaca> cachio: so again, i ask, what are we testing
<cachio> with 28.5 and 33.1
<cachio> Chipaca, we test the integration between ubuntu software and snapd
<Chipaca> cachio: but you're not testing the SRU package
<cachio> yes
<cachio> Chipaca, let me explain
<Chipaca> please because I'm losing it
<pedronis> ogra_: yes,   should work, are you sure ubuntu-image is using the right snapd?
<Chipaca> (fresh reinstall, this time no updates selected, no crashes here)
<cachio> what I did is: I installed the snapd from proposed in a vm
<cachio> I searched snapd in ubuntu software and I saw the crash
<pedronis> ogra_: or   ubuntu-image does its own strict parsing? in which case it needs fixing
<ogra_> pedronis, no idea, which one should it use ? the image itself is built with --channel edge, the machine executing ubuntu-image runs 16-2.34~pre1 from beta
<cachio> then in another vm which was totally clean
<ogra_> ah, i didnt think u-image does parsing at all and relies on snap prepare-image
<cachio> Chipaca, I did the same with without the sru package to check if it was a regression
<pedronis> ogra_: well it needs to parse volumes
<ogra_> oh, indeed
<cachio> Chipaca, and I reproduced the error with 28.5
<pedronis> but indeed IÂ didn't think it would do strict parsing
<ogra_> yeah, that m,ight be it then
<cachio> Chipaca, so, it wasn't a regressions
<cachio> Chipaca, that's it
<Chipaca> cachio: ok
<pedronis> ogra_: in which case, can you open a u-i bug?
<Chipaca> cachio: so, I have again not been able to reproduce the issue
<Chipaca> just in case, I'll grab the snapd from proposed
<ogra_> pedronis, yeah, i'll look into it and file a bug
<cachio> Chipaca, it is ok, it is the same I did
<cachio> Chipaca, I suppose there is something else causing this
<cachio> another package
<cachio> and perhaps you are using an new iso
<cachio> and I am using an old one
<Chipaca> cachio: 17.10 doesn't have more than one iso
<Chipaca> afaik
<Chipaca> cachio: just tried with snapd from proposed, also no crash
<cachio> Chipaca, in the clean image, with no upgrades?
<Chipaca> cachio: yes
<Chipaca> cachio: can you strace the process?
<Chipaca> cachio: that is: start it, then check its pid and use strace -f -p <that pid>
<Chipaca> (just stracing ubuntu-software doesn't work)
<cachio> Chipaca, sure
<mup> PR core#92 opened: Remove core-support plug <Created by zyga> <https://github.com/snapcore/core/pull/92>
<zyga> mvo: I created https://github.com/snapcore/core/pull/92 and I'm testing a corresponding change to snapd master
<mup> PR core#92: Remove core-support plug <Created by zyga> <https://github.com/snapcore/core/pull/92>
<zyga> I will just drop the plug from the core snap
<zyga> CC jdstrand, pedronis  ^
<cachio> Chipaca, https://paste.ubuntu.com/p/HzzcTp3cWz/
<cachio> 404
<Chipaca> [pid  1931] sendto(20, "GET /v2/snaps/(null) HTTP/1.1\r\nH"..., 177, MSG_NOSIGNAL, NULL, 0) = 177
<Chipaca> that looks a lot like a bug in gnome software or libsnapd-glib1
<cachio> yes
<cachio> because if I search another string it works
<Chipaca> cachio: but if you upgrade everything (not to proposed, just regular artful-updates) the bug goes away?
<cachio> Chipaca, yes
<cachio> Chipaca, I just realized that when you could not reproduce the error
<Chipaca> cachio: so, I'd drop robert ancell an email about this, but it's probably known and fixed already
<Chipaca> cachio: I suggest we update the SRU testing to say we upgrade to whatever's in -updates before trying snapd from -proposed
<Chipaca> but I don't know if that's kosher
<Chipaca> mvo: would that be ok?
<mvo> Chipaca: yes, absolutely fine
<mvo> Chipaca: and sensible
<mvo> zyga: I'm dying of curiosity, how is the core18 main test run going?
<zyga> mvo: I haven't started everything-at-once yet, I'm still running partial checks for the things I'm changing
<Chipaca> zyga: running like the little lambs in https://www.youtube.com/watch?v=WQO-aOdJLiw
<zyga> mvo: ~3 hours from now realistically (I want to break now to take a walk before it's dark)
<mvo> zyga: ok, thanks for the update .)
 * mvo hugs zyga
<mvo> zyga: sorry for being so impatient
<zyga> no worries, it's good to check :)
<zyga> mvo: I'm running a full main run with snapd modified to kill core support
<zyga> clarification: with snapd modified to remove the core-support-plug from the core snap
<mup> PR snapd#5456 opened: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456>
 * cachio lunch
<zyga> mvo: https://github.com/snapcore/snapd/pull/5456/files#r199860433
<mup> PR #5456: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456>
<zyga> mvo: mainly to put the logic about "I need this" in one clear spot
<zyga> and not all over the place
<zyga> the first one is giving you simple hints (all the snaps with those names are related to myself)
<zyga> this would return the base snap
<zyga> but also, perhaps, default content provider or even the one that is connected right now
<zyga> the second would look at a real snap info and say if this is ok to remove
<zyga> I suspect they may need snap state at that time
<zyga> (I didn't include that in my comment on the PR)
<zyga> so that we can check connections and what not
<zyga> just a though, I'll go for a walk now because it will be getting dark soon and woods are not like a park
<zyga> mvo: still testing, got one error that spewed megabytes of journal that didn't say much, re-testing that one to see if it is something real
<zyga> mvo: please review https://github.com/snapcore/core/pull/92 if you can
<mup> PR core#92: Remove core-support plug <Created by zyga> <https://github.com/snapcore/core/pull/92>
<zyga> mvo: I will really really go in ~30 minutes because $life tasks
<mvo> zyga: thanks for the upate
<zyga> mvo: I added a patch that does the removal snapd-side, if it works I will open another PR
<zyga> mvo: can we land https://github.com/snapcore/snapd/pull/5443
<zyga> I think we can now
<mup> PR #5443: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5443>
<zyga> mvo: and we need a review on https://github.com/snapcore/snapd/pull/5454
<mup> PR #5454: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5454>
<mvo> zyga: ok
<Son_Goku> :/
<Son_Goku> this bug is really bothering me
<Son_Goku> I really don't know what causes this
<Son_Goku> and the worst part is, it's pretty easily reproducible
<zyga> Son_Goku: I have no idea, I have a F28 system to play with but I'm deep in core18 work that actually  a prerequisite for fedora snap that works without pulling in ubuntu
<Son_Goku> yeah
<zyga> Son_Goku: the work is also time boxed as we are running towards a commercial deadline
<Son_Goku> oh?
<zyga> Son_Goku: I will devote way more time to fedora after this
<zyga> Son_Goku: just making core18 available
<mvo> Son_Goku: how is it reproducible?
<zyga> for customers that want that
<zyga> Son_Goku: is it _any_ snap that triggers this?
<Son_Goku> zyga, the launching of a snap seems to do it
<Son_Goku> I triggered it with ohmygiraffe
<zyga> Son_Goku: thanks
<zyga> well
<zyga> can you check if hello-world does that too?
<zyga> it's shorter to strace to eventually find out what the problem is
<Son_Goku> I'll check later in the day
<Son_Goku> I'm unfortunately busy at the moment
<zyga> no worries, thank you for the information
<cachio> zyga, the documentation for spread images is described on this PR
<cachio> https://github.com/snapcore/spread-images/pull/13
<mup> PR spread-images#13: Adding base images and test dependencies including new documentation <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/13>
 * zyga hugs cachio :-)
<cachio> zyga, it is first version
<cachio> zyga, open to rewrite it if needed :)
<zyga> I will read it
<cachio> thanks
<ahoneybun> I'm seeing an issue with snapd.service that it has issues starting. So it is holding the boot process.
<ahoneybun> I can provide log files.
<zyga> ahoneybun: please report all you know in a forum thread on forum.snapcraft.io
<zyga> and coordinate here for more feedback as we review
<zyga> mvo: I tested master with this extra patch https://github.com/zyga/snapd/commit/366ca43e3149db942207e6e81a0b17fe61f80f0c
<zyga> mvo: and this test change https://github.com/snapcore/snapd/compare/master...zyga:feature/lessen-use-of-core-support?expand=1
<zyga> I will propose the test change in a moment,
<zyga> this will let us land the core change with confidence (dropping core-support-plug from core{,16}
<zyga> mvo: I haven't done that yet but we can also drop it from core18 if it is there, I haven't checked yet
<zyga> I'm running one more test on this upcoming branch in isolation (without the suppor patch that removes core-support-plug programmatically)
<zyga> jdstrand: briefly, my mind thought about having compiler.apparmor.net that exposes ultra-fast, cached apparmor_parser
<zyga> especially since it would have a small (<<~1M) set of profiles
<zyga> that could be cached efficiently
<zyga> and it would probably scream from RAM on a modest server
<zyga> it could reply with some status code if overloaded (fallback to local)
<zyga> but on slow machines it would meaningfully speed things up
<mup> PR snapcraft#2175 closed: ci: disable osx tests until a new pyyaml is released <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2175>
<mvo> zyga: core18 does not have this plug
<zyga> mvo: that's great
<zyga> tests passed, opening PR
<zyga> mvo: one more, I hope it passes
<mup> PR snapd#5457 opened: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
 * cachio afk
<twobitsprite> I'm trying to boot up the KVM/Qemu image and it stalls booting right after "Started network service" and ssh is just reseting connection... it's been sitting there like that for about 10 minutes...
<twobitsprite> Err... sorry, I thought this channel was dedicated to Ubuntu Snappy Core, not the whole snappy project :P
<twobitsprite> Is there a better place to ask about Ubuntu Snappy?
<mup> PR snapcraft#2174 closed: build_providers: inject snaps when running from a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2174>
<mup> PR snapd#5458 opened: tests: check catalog refresh before and after restart snapd <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5458>
#snappy 2018-07-04
<mborzecki> morning
<mup> PR snapd#5459 opened: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
<zyga> good morning
<mborzecki> zyga: hey
<pstolowski> mornigns
<mborzecki> pstolowski: heya
<mvo> hey pstolowski and mborzecki
<mborzecki> mvo: hey, have you seen https://forum.snapcraft.io/t/need-help-snapd-services-in-ubuntu-18-04/6205/4?
<mvo> mborzecki: good morning - not yet, let me look
 * zyga settles in for work
<zyga> today looks, finally, like an emerging summer day
<zyga> it's not expected to rain and temperatures will be a little above 20
<mvo> mborzecki: hm, hm
<mborzecki> mvo: wouldn't that be caused by stuff running with 5minute iteration times?
<zyga> mvo: that's not great :/
<zyga> mvo: is seeding blocking 1st boot?
<zyga> mvo: or perhaps registration blocking 1st boot
<mvo> mborzecki: can you elaborate a bit, not sure I get what you mean. I think we have two problems: a) its so slow - why is that? we don't seed on classic, so the snapd startup is slow. I saw earlier reports about missing entropy in VMs so that might be a clue then we need to figure out why we need random data b) why we block login, i.e. we should not have wantedby=multi-user.target
<mvo> zyga: aiui this happens on every boot not just first boot
<mvo> zyga: in any case, I think we need to check what target we can use that is not blocking login
<zyga> mvo: if this is on every boot then something is very wrong
<zyga> unless it fails and keeps retrying
<mvo> zyga: yeah, it *might* be entropy but it might also be something else, definitely not reproducible on my (real HW) box but I try a VM next
<zyga> mvo: I'm all-day-vm and I haven't seen that
<zyga> mvo: but I'm in vmware
<mvo> ok
<mborzecki> mvo: tought that it's some ensure thingy, but i see that doMarkSeeded calls EnsureBefore(0) so it's probably good
<pedronis> mborzecki: yes, I added it so that registration starts immediately but nothing waits on registration afaiu
<pedronis> (IÂ mean refresh does but shouldn't be visible outside)
<mborzecki> hm if release.OnClassic && !osutil.FileExists(seedYamlFile) {, is there a seed.yaml in the desktop images?
<pedronis> they do seeding in 18.04, no?
<pedronis> IÂ mean desktop
<mborzecki> hmm maybe that gnome-calculator snap
<mborzecki> still doesn't explain why this happens on each boot :(
<pedronis> each is weird
<pedronis> apparmor stuff ?
<pedronis> do we reload profiles for some strange reasons at each boot?
<mvo> mborzecki: do you know if there is a default systemd target that runs after multi-user?
<zyga> pedronis: on a new kernel we would but otherwise no
<mborzecki> mvo: iirc graphical requires multi-user
<zyga> mborzecki: graphical.target
<mborzecki> yup systemctl cat graphical.target
<mborzecki> Requires=multi-user.target
 * zyga learned this while installing RHEL 7 
<mborzecki> haha ;)
<zyga> any objections for merging https://github.com/snapcore/snapd/pull/5443
<mup> PR #5443: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5443>
<zyga> mborzecki: I was thinking if we should build a script that collects some information for debugging
<zyga> for people that come and say "foo is broken"
<zyga> we ask snap version, os-release, a few others
<mborzecki> zyga: a combination of all debug commands probably
<Chipaca> zyga: 'snap debug lies'
<zyga> Chipaca: snap debug report
<zyga> I already like it
<zyga> but I think it should be a shell script in case "snap debug" is broken
<mvo> hm, askubuntu is interessting
<zyga> mvo: ?
<mvo> one guy reports the problem *and* he did not upgrade snapd but the kernel and a bunch of unrelated packages
<mup> PR snapd#5443 closed: interfaces: treat "snapd" snap as type:os <Core18> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5443>
<mborzecki> Chipaca: and you don't know if it's a verb or a noun ;)
 * zyga debugs interfaces-many
<zyga> public service announcement
<zyga> using MATCH for if ... MATCH; then ... else .... fi is not good, it spams the log with garbage that you don't want to see
<zyga> also running this test makes me want to run and optimize
<mvo> so askubuntu indicates that using the older kernel makes the problem go away and the kernel was released two days ago
<mvo> so that matches - *but* its not clear why I can't reproduce it :(
<Chipaca> zyga: make 'snap foo' try to run snap-foo if foo isn't an internal command, and ship snap-debug-report?
<zyga> ooooh
<zyga> that's sweet
<zyga> actually /usr/lib/snapd/snap-foo maybe
<Chipaca> ye
<zyga> that would be nice, too bad golang cannot do small executables
 * zyga applied one simple apparmor optimization and goes to look for breakfast
<Chipaca> zyga: i thought you said it'd be a script?
<zyga> yes
<zyga> but in general
<zyga> this one would be a script, yes
<Chipaca> zyga: second breakfast i hope
<zyga> um
<zyga> nope
<zyga> I tend to shift my hours late
<zyga> And I wake up later as well
<zyga> Well apart from today at 5AM because $SUNSHINE
 * Chipaca off to take one of the boys to the doc
<Chipaca> bbiab
<mborzecki> simple review https://github.com/snapcore/snapd/pull/5459 anyone?
<mup> PR #5459: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
<zyga> ohh, nice
<pedronis> Job for systemd-journald.service failed. See "systemctl status systemd-journald.service" and "journalctl -xe" for details.
<zyga> pedronis: I saw that on travis yesterday
<pedronis> fun
<zyga> weird-ish but I think not new
<zyga> very unlikely combination of jurnal ops
<zyga> (racy)
<zyga> we probably don't wait for it to stop and sync
<zyga> and restart fails because it's running
<zyga> or something
<mvo> xnox: hey, good morning! a recent kernel update caused some issues with random numbers and that caused snapd to start super slow (because it now waits for entropy). what is the best way to a) ensure snapd starts b) but is not in the way of the login screen? do we need a different target (wantedby) than multi-user.target?
<zyga> tests are taking longer, I suspect they will pass now
<zyga> which is good :)
<niemeyer> Mornings
<zyga> hey
<niemeyer> mvo: I've merged the spread PR, with a small tweak so closing the old session is done right before assigning the new one, similar to what we have before.. that avoids multi-closing and leaving a closed session assigned.. please let me know if the old behavior was intended somehow
<niemeyer> mvo: Travis is also updated with the new logic
<mvo> niemeyer: sounds correct, thank you
<niemeyer> mvo: Replied on https://forum.snapcraft.io/t/how-to-specific-the-kernel-snap-on-core18/5947/5 .. please let me know if we need anything else about this
<pedronis> mborzecki: mvo: this is happening quite a lot:  Job for systemd-journald.service failed. See "systemctl status systemd-journald.service" and "journalctl -xe" for details.
<pedronis> I got two test runs in a row hitting that
<mvo> niemeyer: thanks, I think this is perfect
<mborzecki> pedronis: and on ubuntu-core only iirc
<pedronis> seems so, but on random tests
<pedronis> anyway is part of prepare
<mvo> pedronis, mborzecki thanks, sounds like we need add debug code there. side-note: tests seems to be more unstable lately again, kind of annoying
<mborzecki> pedronis: i saw one more with `find ..../state-lib/*`, seemd like a glob gone wrong
 * mvo meanwhile goes into a systemd fistfight
<mborzecki> https://paste.ubuntu.com/p/Cp3SdyRyxj/
<mborzecki> pedronis: ^^
<pstolowski> uh, google:ubuntu-16.04-64:tests/main/interfaces-contacts-service failure again
<mborzecki> pstolowski: same as before?
<pstolowski> mborzecki: i don't remember the previous failure. relevant bit is https://pastebin.ubuntu.com/p/p6vTVH5nxx/
<mborzecki> pstolowski: nope, this one occurred randomly before (rarely though) and iirc i tracked it back to libevolution-blahblah
<pstolowski> mborzecki: ack, not good.. thanks
<zyga> Chipaca: hey
<zyga> question about the warnings
<Chipaca> zyga: 'sup
<Chipaca> zyga: sure
<zyga> should we seek integration with desktop notification systems?
<zyga> (where appropriate)
<zyga> imagine we never open the CLI
<zyga> and never see any warnings there
<Chipaca> zyga: I'd expect each client to keep track of warnings in its own way
<zyga> aha
<zyga> so gnome-software
<zyga> interesting
<zyga> that's sane, yes
<Chipaca> zyga: e.g. gnome-software would keep a 'last warning seen' timestamp around, separate from snapd's
<Chipaca> zyga: even the acking mechanism could be different
<Chipaca> zyga: for example, gnome software might take 'ownership' of the warnings itself
<zyga> could a waning be generated asynchronously by snapd itself
<Chipaca> zyga: whereas snap does not
<Chipaca> zyga: did not follow
<Chipaca> zyga: all warnings are generated by snapd itself
<zyga> you are on an idle desktop, snapd fires a warning, a desktop notification shows up, you click on it and go to gnome-software showing the details there
<zyga> Chipaca: (without user action triggering it)
<Chipaca> zyga: that'd be gnome-software's integration work if so
<Chipaca> also that'd probably only happen after we got notifications working from snapd
<Chipaca> that is
<Chipaca> gnome-software have asked for a no-polling way of getting stuff
<Chipaca> (so if you install something from snap, and gnome software has a listing, it can update the listing for example)
<Chipaca> or if it's showing a listing and a snap refreshes, it can update it
<Chipaca> anyway, i need to step away again
<Chipaca> zyga: but, this thing should support all that (modulo the no-poll thing)
<xnox> mvo, it sounds like you want to fix the kernel, no?
<xnox> mvo, do you have the entropy bug? is snapd consuming entropy? (e.g. we had a bug were generating a few uuids could stall things)
<xnox> mvo, if a hardware number generator is available.... is it in use?
<xnox> mvo, and we do need to ensure that snapd starts when it does =/ because of cloud-init, etc.
<xnox> mvo, also, there were some kernels rolled back.
<mvo> xnox: well, I follow #stable-kernel and have no seen anything rolled back yet. as for fixing> yes. however I wonder if we can mitigate this somehow by ensuring that snapd is not blocking login
<mvo> xnox: I think its an entropy problem, we use random numbers for various things, I need to dig where this exactly hangs though
<xnox> mvo, that's conflicting goals. as then you will break all the public clouds that preseed snaps and expect that sdk/agents are there, and working upon login.
<mvo> xnox: hm, hm. fair point
<zyga> honestly I think that is a special case
<zyga> and it should not be default
<pedronis> well, we cannot really change it
<pedronis> we have the relationship setup that way since a while
<zyga> I need 2nd review on https://github.com/snapcore/snapd/pull/5457
<mup> PR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
<pedronis> mvo: also I'm not quite sure what we need entropy for after the first boot
<mvo> pedronis: yeah, I'm checking if I can find anything
<mvo> pedronis: catalogRefresh needs quite a bit of getrandom() data - that one is easy to delay. however we also have something that uses 4 bytes of getrandom() before main() which I'm looking at right now. aiui the problem is that the urandom entropy now only becomes non-blocking once a certain amount of real entropy is available to seed the prng (but I might be wrong here). so even those 4 bytes are problem blocking the boot
<zyga> mvo: are all our timer randomization things using real randomness?
<mvo> zyga: getrandom is pseudo random unless a flag is specified. but it looks like the bug is that urandom now is blocking until its initialzed with real entropy (my working theory so far)
<zyga> hmmm, I strongly doubt that is the case
<zyga> (urandom blocking ever)
<mup> PR snapd#5460 opened: tests: use grep to avoid non-matching messages from MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/5460>
<mup> PR snapd#5461 opened: tests: "snap connect" is idempotent so just connect <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5461>
<mvo> zyga: well
<mvo> zyga: " If  the  urandom  source has not yet been initialized, then getrandom()
<mvo>        will block, unless GRND_NONBLOCK is specified in flags.
<mvo> "
<mvo> zyga: from the man-page
<zyga> !
<zyga> that's very interesting then
<zyga> so urandom is not really that reliable after all
<mvo> zyga: it looks like it, I'm digging. we are not the only ones affected I'm trying to figure out a fix for the common case
<mvo> zyga: seeding will be hard though, here we need urandom
<zyga> mvo: can we polinate from snapd?
<mvo> zyga: but at least we should not block in the already-seeded case
<zyga> mvo: if urandom blocks then we do what polinate does
<mvo> zyga: an interessting idea! the kernel team did investigate polinate and they suspect it might be buggy though
<zyga> fun :)
<zyga> I'll go to core18 topics for now
<mvo> zyga: I did not follow that
<zyga> good luck
<mvo> ta
<mup> PR snapd#5403 closed: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5403>
<mborzecki> hmmpf, woring on some changes in snapstate, broke aliases not even touching that code :/
<pedronis> mborzecki: aliases are delicate
<pedronis> mborzecki: let me know if I cand help
 * Chipaca ~> lunch
 * zyga tests a switch over to internal LTE
<pedronis> mvo: why does catalogUpdate delays  start up? it's a goroutine, no?
<mvo> pedronis: because it accesses getrandom
<pedronis> and it blocks everything?
<pedronis> sorry, I'm dense but still not understanding
<mvo> pedronis: sorry, let me give a bit more context
<mvo> pedronis: the latest kernel update make reading from urandom block at early boot
<mvo> pedronis: until it has a certain amount of entropy
<mvo> pedronis: that seems to be a regression and a bug but its not totally clear yet, the kernel team is researching this, it might be a valid security fix
<pedronis> I understand
<mvo> pedronis: I looked into why we need urandom at startup of snapd
<pedronis> but IÂ understand why getrandom from some init code whould block stuff
<pedronis> I don't understand why getrandom from a gorotuine not in the main daemon start path
<pedronis> does
<pedronis> we do systemdSdNotify READY  from  daemon.Start
<mvo> pedronis: I need to look, maybe the catalog-update is not the problem. there is another reader of getrandom() (bson.go) which happens during "func init()" time
<mvo> pedronis: I just wrote it in the forum, its two places right now
<pedronis> yes, I understand
<pedronis> I see the problem with init
<pedronis> not sure I understand the other one
<pedronis> unless go is starved somehow of threads for os calls
<ogra_> hmm, wasnt the purpose of urandom (vs random) to be non-blocking ?
<ogra_> (sounds like a kernel bug all over, why would someone change that)
<mvo> pedronis: if the theory is correct it does not even enter main() because the init code in bson.go reads urandom - or am I misunderstanding you maybe :) ?
<pedronis> mvo: yea, then why would catalog-update matter?
<mvo> ogra_: yeah, I'm simplifying here a bit but the getrandom syscall man page explains that it may block if the prng is not initialized yet
<mvo> pedronis: maybe/probably it does not
<mvo> pedronis: sorry, I was just hunting for the sources of what reads getrandom
<mvo> pedronis: I don't run into the bug myself so I can't test my theory :/ but I will add code that does
<mvo> (that does test my theory)
<ogra_> mvo, well, but thats new behaviour and getrandom can be switched back to the old one if GRND_NONBLOCK is set as i understand
<mvo> pedronis: you are correct, catalog-update does not matter -
<mvo> pedronis: sorry for that
<mvo> ogra_: correct, GRND_NONBLOCK is not used by the golang runtime though and we can not control that
<ogra_> ah
<ogra_> evil ...
<mvo> ogra_: yes
<mvo> pedronis: I updated the forum message - its just bson.go it seems that we would have to fix to workaround the issue
<mvo> pedronis: anyway lets talk in the standup
 * Chipaca on his way
<Chipaca> mvo: is #1779948 the same issue again?
<mup> Bug #1779948: Snapd gets stuck when starting Ubuntu. <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1779948>
<mvo> Chipaca: probably, let me look
<zyga> ha, this is fun
<zyga>  while systemctl restart systemd-journald; do :; done
<zyga> this fails nearly instantly
 * zyga investigates
<Chipaca> pstolowski: you reminded me of https://www.facebook.com/jesse.newton.37/posts/776177951574 (viewable in incognito if you don't use the book of faces)
<mborzecki> pstolowski: hahah https://github.com/snapcore/snapd/pull/5416/files#diff-9c91792e9bb71d29a3ae728fc544152fR48
 * zyga goes to make some coffee
<mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<zyga> Chipaca: I know that story, it's terrible
<pstolowski> Chipaca: lovely, rotfl :). and btw, ircloud kindly gave me entire content inline, the dod that apparently for facebook too
<zyga> pstolowski: irc cloud is nice, eh?
<zyga> are you using the snap or the web browser to use it?
<pstolowski> mborzecki: yeah i do that when i run out of foo & bar vocabulary ;)
<zyga> my only issue with it is lack (apparent) of any way to set the font I want
<pstolowski> zyga: i didn't know of a snap; i just use it in the browser. yes it's nice, i haven't looked back since i started my subscription a few months back
<mborzecki> Chipaca: found the problem with aliases :( magic name handling in fakeSnappyBackend.ReadInfo
<pedronis> mborzecki: that's used for everything though, is not just aliases
<pedronis> we fake various snaps there
<Chipaca> mborzecki: I'm still grinning evilly, here
<mborzecki> pedronis: yeah, i just missed a little `if strings.Contains(snapName, "alias-snap") {` which changes the name :(
<mborzecki> funny that it worked until it hit reenabling of manual aliases which looks in info.Apps[], which was obviously an empty map
<mborzecki> anyone up for a simple review of #5459?
<mup> PR #5459: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
<mup> PR snapd#5462 opened: many: use extra "releases" information on store "revision-not-found" errors to produce better errors (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5462>
<mborzecki> pedronis: i've resolved the conflicts in #5452 and force pushed
<mup> PR #5452: store, overlord/snapstate: introduce instance name in store APIs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5452>
<pedronis> mborzecki: thx,  I will look tomorrow morning IÂ think
<mborzecki> pedronis: great, thanks!
<mup> PR snapd#5463 opened: Optimize snap install time 1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5463>
<mup> PR snapd#5464 opened: vendor: switch to latest bson <Created by mvo5> <https://github.com/snapcore/snapd/pull/5464>
<Chipaca> *ahem*
 * Chipaca grins
<mup> PR snapd#5465 opened: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5465>
 * cachio lunch
 * ogra_ hugs popey 
<popey> \o/
<ogra_> (for also doing an armhf build of xonotic !)
<popey> lulz
<popey> bet that doesn't work
<popey> we're dumping their pre-built binaries, not building from source
<ogra_> dont lauch, my next objective is kiosk systems so after i have a proper chromium kiosk image for the pi (which might still take a lot of work, it is definitely not accelerated atm) i'll move on to kodi and xonotic ;)
<ogra_> *laugh
<ogra_> i dont see why it wouldnt work ...
<ogra_> anyway ... as a xonotic junkie i'm happy to see we ha a snap now
<ogra_> *have
<popey> i see threads suggesting it could work
<popey> the snap is smaller than the upstream zip too :)
<ogra_> ha !
<popey> (and stays compressed of course, double bonus)
<ogra_> yeah
<ogra_> the littel ram might be an issue while gaming
<ogra_> *little
<ogra_> though if it fully utilizes the GPU it should work
<cachio> zyga, do you have a dragonboard with you?
<cachio> I can reproduce the error of MATCH
<cachio> mvo, do you have one?
<zyga> cachio: no, I don't :-(
<zyga> cachio: well, I do back in my offie
<zyga> office
<zyga> I could get it online shortly but not instantly
<zyga> cachio: can you tell me more about the match issue?
<cachio> zyga, the test interfaces-bluetooth-control is failing on dragonboard
<cachio> it fails when it does MATCH "Permission denied" < btusb.error
<cachio> but when I debug it, the file contains the string
<cachio> then, if I change the match by a grep it works
<cachio> zyga, it is supper weird
<cachio> I'll run with -vv to see the deatuls
<cachio> details
<zyga> cachio: that's the same as the "^test:" string we've seen elsewhere
<zyga> I don't think it's specific to any hardware
<pedronis> do we get the wrong MATCH definition in some context?
<cachio> zyga, the test just works on dragonboard
<pedronis> it's starting to be too strange
<zyga> cachio: can we add a trace to what MATCH does
<zyga> cachio: yes but the user check is universal
<zyga> pedronis: I doubt that, it is defined by spread
<zyga> pedronis: definitely we don't have one that's nearly the same but inverts one bit of logic while keeping everything else
<pedronis> zyga: well,  I see tests/lib/spread-funcs
<pedronis> .sh
<zyga> look inside
<pedronis> that is used sometimes
<zyga> the only definition is that from spread
<pedronis> are we getting coonfused by that
<zyga> and this is not new, we had that for months
<pedronis> maybe somthing changed
<zyga> it'd be interesting to see if we can run tests from last month and hit this
<cachio> in the debug session I defined MATCH as spread does
<cachio> and I run the same line which is failing during the test and it works
<cachio> zyga, pedronis, I'll make a change to spread to add some debug info
<zyga> cachio: maybe just set -x
<pedronis> we can also try to do declare -pf MATCH somewhere close to where we get those errors
<zyga> hm
<zyga> or redirect to a file
<zyga> pedronis: good idea
<zyga> maybe in that prepare logic
<zyga> that seems to be hit very often
<zyga> we can also re-define MATCH just ahead of that
<zyga> though I think it must be something that is racing in the system
<zyga> in a way that we don't understand
<zyga> that impacts MATCH
<zyga> but I cannot put my finger on anything that could do something like this
<zyga> one thing to, perhaps, think about
<zyga> is a very obscure mechanism in bash (and maybe dash)
<zyga> that "inherits" function definitions
<zyga> from one shell to another
<zyga> but this still doesn't explain why it is racy
<zyga> especially when invoked with a file
<zyga> we could also try to copy /etc/passwd to /tmp/INSANE
<zyga> and MATCH that to isolate from anything writing to passwd
<zyga> some ideas to explore
<cachio> zyga, ok, working on that
<cachio> let's see what's going on
<zyga> thank you!
<mup> PR snapd#5466 opened: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5466>
<zyga> sigh
<mvo> cachio: sorry, I don't have a dragonboard
<cachio> mvo, np
<zyga> Chipaca: are we there yet ;-) https://twitter.com/c___f___b/status/1014529179742810112
 * zyga break
<mup> PR snapd#5467 opened: tests: stop restarting journald service on prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5467>
<mup> PR snapd#5461 closed: tests: "snap connect" is idempotent so just connect <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5461>
<mup> PR core#92 closed: Remove core-support plug <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core/pull/92>
 * cachio afk
<mup> PR snapd#5279 closed: interfaces/builtin: create can-bus interface <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5279>
#snappy 2018-07-05
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<DarrenRStarr> Hello good people. I was wondering. Is there an example/boilerplate for making a kernel module snap?
<mborzecki> morning
<mup> PR snapd#5468 opened: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>
<mup> PR snapd#5463 closed: Optimize snap install time 1 <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5463>
<mup> PR snapd#5469 opened: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<mup> PR snapd#5464 closed: vendor: switch to latest bson <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5464>
<mvo> mborzecki: thanks for the merge
<mborzecki> mvo: hi, would it be possible to pick #5468 for 2.34?
<mup> PR #5468: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>
<mvo> sil2100: you are in the SRU team, right? if you could look at my bionic snapd upload with a tiny fix for the boot dealy workaround, that would be great. the xenial version of this can be rejected, I think xenial is not affected by this bad kernel update
<mvo> mborzecki: sure thing
<mborzecki> that os-release thing is a bit messy unfortunately
<mvo> mborzecki: make sure to tag for 2.32
<mvo> 2.34
<mborzecki> it's tagged (labeled) for 2.34 already
<mvo> mborzecki: great
<sil2100> mvo: sure! I'm having my SRU shift today so I'll look at it for sure
<mvo> sil2100: thank you
<pstolowski> heyas
<abeato> hm, systemd-activate is not in bionic anymore
<abeato> which is the alternative for it?
<abeato> ha, systemd-socket-activate must be
<mup> PR snapd#5468 closed: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5468>
<pstolowski> zyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/5416 ?
<mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<zyga> pstolowski: yes, sorry for not reviewing that last evening
<mvo> mborzecki: quick question on 5458 - cachio says "grep -c" exits 1 when no result is found - so is your change (to use it) safe?
<mborzecki> mvo: looking
<mvo> mborzecki: I mean, with "wc -l" last we never have the last command in the pipeline failing, with grep -c it *might* happen
<mvo> mborzecki: and since we check before restarting snapd we will be back at the same bug we are fixing, no?
<mborzecki> mvo: if grep -c fails, then the output is empty, so -gt tests will fail
<mvo> mborzecki: also in the "refreshes_before=" assignment ?
<mborzecki> mvo: yes, test "" -gt "" fails in such case
<zyga> pstolowski: have a look
<mborzecki> mvo: haha it fails in zsh
<mborzecki> test "" -gt ""
<mborzecki> bash: test: : integer expression expected
<mvo> mborzecki: grep -c will print "0", no?
<mvo> mborzecki: I mean, refrehes_before will be zero with the new and the old code
<mvo> mborzecki: the risk is that if grep -c returns an exit 1 then the last command in the pipe failed and that causes set -e to kick in and abort (unless I'm reading this wrong)
<mborzecki> mvo: but it's in a subshell
<mborzecki> mvo: see it now, pff let me fix it
<mborzecki> mvo: simple || true should do the trick
<mvo> mborzecki: http://paste.ubuntu.com/p/6DbZ8m5xZN/ if you want to play. thanks !
<mvo> mborzecki: yeah, that will also work
<mvo> mborzecki: feel free to merge once the grep -c is fixed, the PR looks fine
<mvo> 5460 is an easy win
<mborzecki> mvo: pushed, will wait for it to get green and merge
<mup> PR snapd#5460 closed: tests: use grep to avoid non-matching messages from MATCH <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5460>
<mvo> mborzecki: ta
<zyga> pstolowski: is that sensible?
<zyga> sorry, waking up much too late here
<mup> PR snapd#5470 opened: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5470>
<pstolowski> zyga: re Object and DevPath - happy to drop Object, just not 100% sure they're alyways the same, that's the only reason i've both, not to close any doors (although, it's easy to add it back if needed)
<zyga> pstolowski: ok, let's drop it for now under the assumption that they are indeed the same; if we find this is wrong we need to re-think some stuff
<pstolowski> zyga: ok, np, thanks for the review
<Chipaca> mwhudson has all the fun
<Chipaca> I too want to skip the office and go whalewatching
<zyga> Chipaca: whales of fun
<Chipaca> only whalewatching i could do is at the mall though, so maybe i'll pass
<zyga> Chipaca: I was doing hornethunting instead of whalewhatching
<Chipaca> zyga: hornets, or F/A-18 hornets?
<Chipaca> zyga: or even hawker hornets
<Chipaca> those are cool
<zyga> Chipaca: my odds would be poor with those :)
<mborzecki> zyga: probably the same as against japanese hornets :P
<Chipaca> did we have a testutil for 'this looks like a timestamp'?
<zyga> mmmm, not that I recall
<Chipaca> nm, fixed it by not having the timestamp in the first place
<Chipaca> in fact i'm questioning the whole 'send the timestamp' idea
<sil2100> mvo: accepted the snapd bionic upload o/ As for xenial, in theory we do have the -hwe kernels in xenial that are 4.15 based, will those not cause problems?
<mvo> sil2100: oh, good point, let me quickly check if the bad kernel hit xenial as well
<mvo> sil2100: yes it did, so probably a good idea to have the fix in xenial too
<sil2100> I think the same bits were in the -hwe kernel I published on Monday
<sil2100> Ok then!
<mvo> sil2100: nice catch!
<ogra_> mvo, i "accidentially" created a universal pi gadget that boots all pi's from one gadget ... and was wondering, i assume we are changing names for core18 images, so we could probably use that unified approach in 18 by default ? https://github.com/ogra1/pi-kiosk-gadget/commit/24ce020e094447abbad4d37a2856e23483b281dd
<zyga> ogra_: oh, nice, how does it work?
<ogra_> zyga, config.txt allows filters per-device since a while
<ogra_> nobody ever tried them ...
<ogra_> ... i'm actually working on a universal browser-kiosk image atm and got tired to always have to build two gadgets, so i tried it out ;)
<ogra_> (thats what i meant by "accidentially" ;) )
<zyga> neat
<ogra_> zyga, http://people.canonical.com/~ogra/snappy/kiosk/pi-kiosk.img.xz in case you want to try (sadly seeding the giant chromium-mir-kiosk snap on firstboot takes 15-20min so one needs to be patient)
<mvo> ogra_: interessting.
<mvo> ogra_: one complication is upgrades, on an upgrade the current thinking is that you get a new core18 model assertion
<ogra_> mvo, right, but i was assuming we change gadget names anyway and need an upgrade path for the naming
<mvo> ogra_: but as part of the upgrade logic we could put in the new config.txt - I assume this is backward compatible too? i.e. the old uboot.bin from the current gadget understands this too?
<ogra_> so we could as well turn everyone to a universal pi gadget in that step
<mvo> ogra_: so far we had no need to change the gadget names for 18
<mvo> ogra_: we can/could, its definitely a compelling option
<ogra_> i'm using the same source tag of the upstream tree that all core16 image use for the blobs, so yeah, fully compatible to todays gadgets
<ogra_> the feature actually got added a few commits before the tag we use in core 16 so that should be safe
<mvo> ogra_: great
<mup> PR snapd#5462 closed: many: use extra "releases" information on store "revision-not-found" errors to produce better errors (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5462>
<mup> PR snapd#5471 opened: dirs: fix antergos typo <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5471>
<mborzecki> silly typo fix ^^
<mborzecki> had to stare at the screen for a while to spot the difference
<ogra_> pedronis, (and probably sil2100 ) https://bugs.launchpad.net/ubuntu-image/+bug/1780217
<mup> Bug #1780217: new connections: stanza causes validation error in ubuntu-image <Ubuntu Image:New> <https://launchpad.net/bugs/1780217>
<sil2100> ogra_: yeah, indeed, the connections: part wasn't around when we had the parser prepared
<ogra_> yeah
<ogra_> it's pretty new (i think i'm actually the first one to try using it)
<mvo> sil2100: maybe add a switch --ignore-unknow or something to make the parser more accepting stuff that is unknown so that people can easier experiment
<mvo> sil2100: or even just warn about unknown options by default instead of hard failing
<ogra_> doesnt snapd have a parser that u-image could call out to ?
<ogra_> seems awkward that validation needs to be maintained in two places
<mvo> ogra_: there is separation of concern here, snapd ignore most of the partitioning bits but u-i needs to parse that. conversely u-i can ignore stuff like connections or snaps because snapd will handle that
<ogra_> oh, right ... gadget.yaml is special
<sil2100> mvo: good idea, we didn't really think about future changes to the gadget.yaml spec it seems ;)
<sil2100> Anyway, let me get these things fixed today-ish
<ogra_> sil2100, i'm not in a hurry (i have hacks for my test images that help with the issue) so no need to drop something else for it or some such
<zyga> jdstrand: please enqueue https://github.com/snapcore/snapd/pull/5469
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<mwhudson> Chipaca: turns out the midwinter fireworks might get canceled because of this whale
<mwhudson> so i don't get _all_ the fun
<ogra_> neither does the whale (who knows probably he'd appreciate fireworks :) )
<Chipaca> mwhudson: I am unconvinced
<Chipaca> mvo: i just got the MATCH bug on core18 :-)
<zyga> mwhudson: is the whale something special where you live?
<zyga> Chipaca: did you bring any MATCHes
<zyga> Chipaca: do you have a debug shell?
<Chipaca> zyga: this was from travis so no
<zyga> in the end working on software is fun because of MATCH like bugs
<zyga> where we look at a 3 liner
<Chipaca> zyga: but am now trying to repro it with debug
<zyga> and then look at the error
<zyga> and then say WAT
<zyga> and are awed by the eventual understanding
<pedronis> mvo: hi, thanks for merging that backport, there is also #5442
<mup> PR #5442: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5442>
<mvo> pedronis: aha, looking
<mup> PR snapd#5442 closed: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5442>
<mwhudson> zyga: yeah, it's pretty unusual
<mwhudson> zyga: dolphins, seals, even orca are somewhat normal, but a baleen whale?
<pedronis> mvo: thanks
 * zyga wrote pretty lengthy review for a one liner: https://github.com/snapcore/snapd/pull/5466 
<mup> PR #5466: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5466>
<zyga> mwhudson: nice, I never saw a whale
<mwhudson> zyga: me neither until today!
<zyga> mwhudson: I think I saw a dolphin as a child when one was (rarely) spotted near to where I was at the seaside here
<mwhudson> i've never been around when the orca are in the harbour
<zyga> mwhudson: imagine how it must feel to dive next to such a creature!
<mwhudson> zyga: i thought the paddle boarders were being quite brave enough
<mwhudson> zyga: have you seen the bbc series 'the blue planet'?
<zyga> is the whale stuck there or just passing by?
<zyga> mwhudson: yes, I have it on BD
<mwhudson> one of the making of segments has a diver getting a bit too close to a whale + calf
<zyga> watching that makes me think I made some bad life decisions by working on computers all day long
<zyga> too close? maybe I missed that part
<mwhudson> as far as anyone can tell the whale is just hanging out
<mwhudson> it's been here for three days now?
<zyga> did you take that photo with your phone?
<mwhudson> i can't imagine there's a lot of krill in the harbour but what do i know
<zyga> or with a telelens?
<mwhudson> yeah
<mwhudson> doesn't the terrible unsharp mask give it away? :)
<zyga> haha, well, maybe this is a smoker whale who likes the smell of oil and gasoline ;-)
<zyga> haha, kind of :D
<zyga> if you have a camera now would be a great time to take some time off and photograph it
<zyga> maybe that could go to the community showcase
 * mvo seconds that
<mwhudson> i guess it was ~300 metres away when i saw it
<zyga> ubuntu wacky whale anyone :D
<mwhudson> well unsurprisingly there are billions of much better photos on twitter & fb etc
<zyga> yeah, that is how the times are
<mwhudson> https://www.facebook.com/photo.php?fbid=10155927798194830&set=a.383547374829.165096.535824829&type=3&theater
<zyga> I kept saying that someone should make an app for finding photos made at the time / place where one was with juts their phone
<mwhudson> for example
<zyga> but then I learned one of the heavyweights did just that
<zyga> (forgot which now)
<zyga> woah
<niemeyer> Mornings
<zyga> fantastic photo
<zyga> hey Gustavo :)
<niemeyer> mborzecki: Some comments in #5459
<mup> PR #5459: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
<mborzecki> niemeyer: hey, thanks for the review!
<niemeyer> mborzecki: Heya, np
<mup> PR snapd#5471 closed: dirs: fix antergos typo <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5471>
<mborzecki> niemeyer: given your comemnt, that would be SNAP_MOUNT,  SNAP_BIN, SNAPD_LIBEXEC
<zyga> fatal: unable to access 'https://github.com/kardianos/govendor/': Failed to connect to github.com port 443: Connection timed out
<zyga> I wonder if there's something simple we can pass to govendor to retry those
<mborzecki> zyga: that's go get
<zyga> aha
<zyga> seems not
<zyga> we could grep
<zyga> but :/
<zyga> mvo: do you think we should grep for "Failed to connect" and retry?
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/5457
<mup> PR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
<niemeyer> mborzecki: Not sure I get the question
<mup> PR snapd#5466 closed: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5466>
<zyga> mborzecki: now that https://github.com/snapcore/core/pull/92 has landed we need this
<mup> PR core#92: Remove core-support plug <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core/pull/92>
<zyga> CC mvo
<niemeyer> mborzecki: ... there's no SNAP_BIN there, only SNAPD_BIN, and the suggested entries match exactly the ones in the PR in the same order and with almost the same names
<mborzecki> niemeyer: yeah, so i'm wondering if we should use SNAP_MOUNT instead, since we refer to the path as snap mount dir elsewhere (and SNAP_BIN for that matter)
<mvo> zyga: I looked at this one, no?
<zyga> mvo: yes just letting you know we need to merge it :)
<niemeyer> mborzecki: The review provides the exact background for $SNAP_ vs. $SNAPD_.. did you read it? :)
<zyga> mvo: or tests will complain about missing core-support-plug
<zyga> mvo: looking at core PRs I'd suggest to look at and close https://github.com/snapcore/core/pull/38
<mup> PR core#38: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<pstolowski> zyga: addressed your feedback to https://github.com/snapcore/snapd/pull/5416
<mup> PR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<zyga> pstolowski: perfect, looking
<niemeyer> mborzecki: It's of course okay to disagree.. but it sounds like you didn't read it.. what do you think of these points?
<mup> PR core#91 closed: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/91>
<zyga> pstolowski: reviewed
<niemeyer> mborzecki: I'm usually much more careful when I need to expose such names to the external world via an API than when it just sits inside our code which can easily change
<niemeyer> mborzecki: The mount dir of a snap is actually at /snap/<snap name>/<revision>
<niemeyer> Which we call $SNAP for the snap
<niemeyer> mborzecki: snap.Info.MountDir also returns /snap/<snap>/<rev>, not /snap
<zyga> drat, I don't have my opensuse account password here
<zyga> I'll ask my wife later today
<mborzecki> niemeyer: sry, kids are around, what i meant is that the tests and configure flags and the `dirs` package variable name is some premuation of snap mount dir,, that's why i found SNAPD_(MOUNT|BIN) a bit confusing
<niemeyer> mborzecki: Sure, and that's what the comment in the review addresses.. in other cases we generally try to leave SNAP_* for snap-specific namespaces
<niemeyer> mborzecki: $SNAP_COMMON, $SNAP, $SNAP_DATA, ...
<niemeyer> mborzecki: While SNAPD_* is for snapd.. $SNAPD_DEBUG, ...
<mborzecki> ack
<niemeyer> mborzecki: Inside the code we have both.. dirs.SnapMountDir, and snap.Info.MountDir.. the first maps to SNAPD_MOUNT, while the latter is snap-specific and exposed as $SNAP
<niemeyer> zyga: COmment on #5457
<mup> PR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>
<zyga> looking
<zyga> niemeyer: replied
<niemeyer> zyga: Replied the reply...
<niemeyer> I wish GH would notify instead of us using IRC that way :)
<zyga> haha, yes
<zyga> niemeyer: replied again
<zyga> I wonder why github shows me someone is typing but then doesn't show me the actual post. I need to refresh the page... wierd
<niemeyer> zyga: You say it's not removing the testing of the interface, which is a bit ironic given that the comment is under a line removed that tested the existence of the interface :)
<zyga> no, you misunderstand
<zyga> that is not what is tested
<niemeyer> Man.. do I need to copy & paste the test? :)
<niemeyer>  details: |
<niemeyer>      The "snap interface" command displays a listing of used interfaces
<niemeyer>  execute: |
<niemeyer> -    snap interface | MATCH 'core-support\s+ special permissions for the core snap'
<zyga> snap interface lists interfaces that are _present_ in the system as plugs or slots
<zyga> it doens't list interfaces that are known but not present as plugs or slots
<niemeyer> Ah.. okay, that's what I missed
<zyga> I could change that to say "snap interface --all | MATCH" but that was not the point of the test so I changed it slightly
<niemeyer> zyga: And what about this:
<niemeyer> -    snap interface core-support > out.yaml
<niemeyer> +    snap interface network > out.yaml
<niemeyer> -    diff -u out.yaml snap-interface-core-support.yaml
<zyga> and hence used the network interface instead
<zyga> this just shows how plugs and slots are reported by "snap interface IFACENAME"
<niemeyer> zyga: Do we have other tests for it?
<zyga> this is why I also added the test snap to have a connection
<zyga> for the core-support test, no I don't believe we do
<zyga> it used to be tested by various core configuration test
<zyga> *tests
<zyga> but those stopped exercising that code
<zyga> from my POV that interface is stuck as-is until we can understand why some snaps are abusing it
<zyga> and shift them away from it
<niemeyer> So we're back to the same point
<niemeyer> We should either remove the interface, or tes it
<niemeyer> test it
<zyga> well, I disagree, I didn't remove an existing test for the functionality of this interface since we didn't have one
<zyga> we cannot remove the interface, I can add a test for the interface but this is orthogonal to the change I made here
<zyga> I hope you agree about this point specifically
<zyga> FYI, I clarified my last comment
<zyga> (on GH)
<niemeyer> zyga: I see.. the test goal was just checking "snap interface" itself, not the core one specifically
<zyga> yes
<zyga> exactly so
<pstolowski> mborzecki: google:arch-linux-64:tests/main/interfaces-content-default-provider failure on arch  - https://api.travis-ci.org/v3/job/400340808/log.txt
<mborzecki> pstolowski: mount isuse?
<niemeyer> zyga: We probably have tests for that interface originally, but they were about the hook which don't need the interface anymore
<pstolowski> mborzecki: yes
<zyga> niemeyer: yes, I think so as well
<niemeyer> zyga: So why do we need the interface again?
<pstolowski> mborzecki: can i restart or do you want to take a look at the log?
<mborzecki> pstolowski: go ahead and restat
<pstolowski> k
<zyga> niemeyer: we found that one of our customers has a snap declaration for using it on some of their snaps
<zyga> niemeyer: they are probably using it for the unconfined systemctl access
<zyga> niemeyer: I believe we are trying to get in touch with them to discuss this
<pstolowski> mborzecki: is this test flakiness or something deeper?
<zyga> niemeyer: I would have removed it a few days ago but jdstrand suggested we do a store-side search to ensure it is really unused
<mborzecki> pstolowski:  no clue yet, there's a forum topic tracking this problem
<mborzecki> pstolowski: it's usually associated with I/O errors on loop devices
<niemeyer> zyga: Well, that's definitely not what this is supposed to do
<zyga> niemeyer: interesting observation, no? I think this is something to learn from
<zyga> niemeyer: yeah but I don't think we should pull the rug from under their feet without asking first
<niemeyer> zyga: How's that not blocked with the declaration?
<niemeyer> zyga: Pretty sure jdstrand wouldn't hand that off
<mvo> jdstrand: hey, I created a core16 base snap, it is essentially core without snapd, exactly the same build etc. could you please whitelist that in the store so that people can start using it? sergio was keen to use it for his latest snapcraft work
<zyga> niemeyer: they have their store, they just signed a declaration that grants this
<niemeyer> zyga: Okay, let's just drop this then
<zyga> mm?
<zyga> drop the interface you mean?
<niemeyer> zyga: Drop the permissions granted by the interface
<zyga> keep the interface but make it empty or remove it entirely?
<niemeyer> zyga: Keep the interface, drop permissions
<zyga> ok
<zyga> can we land this PR then, I will open a new one that drops the actual permissions
<zyga> we need this PR because we removed core-support-plug from core
<niemeyer> zyga: Yeah, the PR is fine
<niemeyer> zyga: Who's the contact on our end?
<zyga> thanks! sorry for not including more context in the PR itself
<zyga> niemeyer: I think lool
<niemeyer> lool: ping
<niemeyer> zyga: I'll also revive the conversation about the fact people granting arbitrary permissions like that for their devices is completely bogus
<zyga> niemeyer: but I need to re-check, pedronis noticed this as he helped to find this
<zyga> niemeyer: thank you
<zyga> niemeyer: we may have some extra constraint on interface policy
<niemeyer> zyga: np, thanks for the info
<pedronis> niemeyer: we didn't ping anybody so far,  IÂ wanted to mention it in the standup yesterday
<zyga> niemeyer: that really limits it to specific snaps in a way that cannot be forced from the store
<zyga> niemeyer: so that in the future things like that don't happen
<niemeyer> zyga: No, the bug here is people being able to sign snap-declarations blindly
<zyga> niemeyer: snice this ties our hands as to what we can do for internal bits
<zyga> niemeyer: I see, ok
<pedronis> niemeyer: about the blocking of this self-granting, we will have more control as part  of the work planned in this cycle
<zyga> niemeyer: without counter signature and review?
<niemeyer> zyga: Exactly
<zyga> yeah, this makes sense
<niemeyer> pedronis: Okay, I'll try to put something on the agenda for the sprint
<zyga> ok, I'll prepare another PR now
<pedronis> niemeyer: I need to resync with jdstrand on that
<niemeyer> pedronis: We need to act on this.. we discuss it as high-priority a few times, but we didn't really get any work items on the schedule yet
<niemeyer> *discussed
<pedronis> niemeyer: we do
<niemeyer> pedronis: Oh?
<pedronis> one sec
<pstolowski> zyga: hmmm. gnome-calculator stopped working on 18.04, it wants me to connect gnome interface (which somehow got disconnected at some point); I reconnected it and it is connected per 'snap interfaces', but apparmor says: audit: type=1400 audit(1530788803.989:110): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.gnome-calculator.gnome-calculator"
<pstolowski> pid=22099 comm="apparmor_parser
<zyga> the STATUS is just spam, it doesn't say anything bad
<zyga> pstolowski: can you tell me how this happened
<zyga> I know of one other case but we didn't manage to either reproduce it or figure out how it came to be
<zyga> pstolowski: please tell me all you know
<pstolowski> zyga: i've no idea. i'm running stable. i've just made a copy of state.json before reconnecting, so i can try to find something there. there were no 'snap changes' reported
<zyga> was this in a VM with random tests running or on your machine?
<zyga> can you look at logs from snapd (all of them)
<pstolowski> zyga: so this must have happened some time ago, i just didn't notice until i tried to use gnome-calculator today
<zyga> aha
<zyga> what is your uptime?
<pstolowski> zyga: 3 days
<pstolowski> zyga: and it's not VM, it's my main box
<zyga> hmmm hmm
<zyga> can you please collect fstab files for that snap
<Chipaca> grr grr MATCH grr
<zyga> the two, one in /var/lib/snapd/mount and the other in /run/snapd/ns
<zyga> pstolowski: also, since you have a mount namespace, can you please collect the mountinfo from that namespace (ping if you need aid)
<zyga> pstolowski: my only theory is as follows
<zyga> pstolowski: oh one more detail please, collect timestamps from all the files, including the .mnt file
<zyga> pstolowski: content connections are non-fatal, if you conncet but we fail to mount, we just carry on
<zyga> pstolowski: we do mark the thing as not mounted though
<zyga> pstolowski: something is either causing that to unmount
<zyga> pstolowski: or the logic is wrong and we thing we mounted (I need to ensure this is strictly tested)
<zyga> pstolowski: I wonder if refreshing content snap is doing the right thinh
<zyga> *thing
<zyga> I will look into this soon
<zyga> pstolowski: please collect this in the forum, I suspect there's one thread about this but if no, make one
<pstolowski> zyga: re namespaces, you need mount output after sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt ?
<zyga> cat /proc/self/mountinfo
<pstolowski> ok
<zyga> but yes
<diddledan> ergh. SNAPCRAFT_BUILD_ENVIRONMENT=lxd has always been a pain for me when running `snapcraft clean ...` the pull step seems to pull the parts' sources as uid 1000 which doesn't seem to be mapped properly to my host userid and thus clean cannot delete the files
<mup> PR snapd#5470 closed: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5470>
<zyga> niemeyer: can you please approve 5457
<niemeyer> zyga: Sorry, just working on the side effects of this mess
<zyga> niemeyer: sure, no worries :)
<diddledan> paste of an affected source tree on my host: http://paste.ubuntu.com/p/XPW37s4gTq/ and within the build container: http://paste.ubuntu.com/p/hvPFZQqGMz/
<zyga> niemeyer: this is the follow up https://github.com/snapcore/snapd/pull/5472
<mup> PR #5472: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>
<mup> PR snapd#5472 opened: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>
<niemeyer> zyga: Too late, but this was abusing "many:"
<zyga> Thank you!
<zyga> :-)
<niemeyer> zyga: This was actually a single directory
<zyga> ah, sorry, I probably kept the name from earlier branch
<zyga> yep
<mup> PR snapd#5457 closed: many: lessen the use of core-support <Core18> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5457>
<zyga> ok little by little :) core 18 here we come
 * Chipaca ~> lunch
<niemeyer> zyga: Follow up LGTM except for summary (comments there)
<zyga> thanks!
<pstolowski> zyga: https://forum.snapcraft.io/t/gnome-calculator-suddenly-disconnected-from-gnome-platform-snap-reconnecting-doesnt-help/6256
<zyga> pstolowski: looking
<pstolowski> zyga: let me know if there is anything else to capture; i'll look into state in a moment
<zyga> pstolowski: please add fstab files
<zyga> they are essential
<zyga> and timestamps on all the three files
<zyga> and snap changes for the content snap (if any)
 * diddledan twiddles his thumbs
<zyga> pstolowski: also snap list --all would help, for the inactive revisions
<zyga> diddledan: hey, sorry for not being able to help you
<zyga> I saw your question but I don't know enough about snapcraft to help
<diddledan> :-)
<pstolowski> zyga: sure, doing
<zyga> thanks
<pstolowski> zyga: updated
<zyga> pstolowski: you missed /run/snapd/ns/
<zyga> that has more fstab files :)
<zyga> (and the important one is there)
<pstolowski> aha. ok
<pstolowski> zyga: how about now?
<pstolowski> pedronis: disconnect-hooks PR is ready for re-review.. it grew a bit unfortunately. changes worth nothing are: individual disconnects, a "automatic-disconnect" flag on disconnect tasks, handling of undo (connect-* hooks run if disconnect hooks are undone).
<niemeyer> zyga: #5454 also +1d with a trivial
<mup> PR #5454: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5454>
<niemeyer> zyga: Thanks for the nice breakdown of those issues, btw
<Chipaca> niemeyer: reminder to take a look at #1779859 when you can
<mup> Bug #1779859: tracks should be ordered <Snap Store:Confirmed> <https://launchpad.net/bugs/1779859>
<zyga> niemeyer: thank you!
<zyga> pstolowski|lunch: ah, you've gone for lunch
<zyga> after you are back, please run snap-update-ns on that snap
<zyga> I'm super curious what the result will be
<zyga> guys, I need to run, my dog makes it crystal clear what I should be doing now (not hacking)
<PLA1> Hi. I have two 18.04 machines both up-to-date. One has snap version 2.32.9+18.04 and the other snap version 2.33.1. How can I get the other machine up to 2.33.1? I've tried `apt install snap`. Having a boot issue with the other machine and wonder if it is affected by this https://forum.snapcraft.io/t/snapd-service-delays-startup-in-ubuntu-18-04-with-4-15-0-24/6205 Thanks.
<Chipaca> PLA1: how are you checking the versions of snapd?
<PLA1> snap version
<niemeyer> Chipaca: Done!
<Chipaca> niemeyer: taw
<Chipaca> PLA1: do you have snaps installed in the one that says 2.32.9+18.04?
<PLA1> I don't think there are any snaps installed on either machines. What is that command to list?
<Chipaca> PLA1: try 'snap list core'
<PLA1> The 2.33.1 has core installed the other does not.
<Chipaca> PLA1: that's your answer: install core (snap install core) to get 2.33.1 in the other one as well
<PLA1> OK. Thanks.
<PLA1> Both at 2.33.1 now. Lets see if that fixes his boot problem. Thanks!
<zyga> re
<zyga> wow, I can work from here :)
<zyga> pstolowski|lunch: one more idea to explore once you are back
<Chipaca> zyga: where's 'here'?
<zyga> Chipaca: hop into standup
<zyga> hhh
<zyga> darn
<zyga> I didn't take my token :P
<zyga> let me ask my son for help
<Chipaca> most boring standup EVAR
<Chipaca> featuring me having lunch like a caveman
<zyga> hahah
<zyga> pstolowski|lunch: run journalctl | grep 'Unmounted Mount unit for gnome-*'
<zyga> pstolowski|lunch: this will show us some history of the mount units
<zyga> this can eliminate any chance that event propagation caused this
<zyga> thanks, I'll tend to other tasks until you are back
<lool> niemeyer: pong
 * zyga tunes in 
<zyga> Chipaca: I'll ping you once my kids arrive with the token :P
<mup> PR snapd#5473 opened: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
<jdstrand> zyga: re https://github.com/snapcore/snapd/pull/5469> ok
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<Chipaca> zyga: the byzantine generals needed kids, clearly
<mup> PR snapd#5474 opened: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>
<zyga> Chipaca: how many do I need for the minimal algorithm to wokr?
<zyga> *work
<Chipaca> zyga: 3, but uniformly 3 levels deep
<zyga> Chipaca: drat
<zyga> Chipaca: well, I can perhaps say that now :)
<zyga> Chipaca: 3rd is on the way now
<zyga> Chipaca: I'm in the standup if you want to chat
<Chipaca> zyga: congrats!
<mup> PR snapd#5416 closed: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5416>
<mup> PR snapd#5475 opened: Remove unneeded calls to daemon-reload <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5475>
<Chipaca> zyga: you're not in the standup
<PLA1> Snap had nothing to do with the problem. Not sure what it is but I moved the other box from LightDM to GDM. Good to go. Thanks again.
<mup> PR snapd#5476 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5476>
<zyga> thanks John
<Chipaca> zyga: np
<zyga> niemeyer: this is not urgent but could you please append https://github.com/snapcore/snapd/pull/5307 to your review list
<mup> PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<zyga> pstolowski|lunch: were those messages from pre-reboot? we only need the one from _this_ boot
<pstolowski|lunch> zyga: added journalctl output, looks totally fine
<niemeyer> zyga: The comment I made there earlier still seems relevant.. this PR is unused and untested.
<niemeyer> zyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?
<lool> zyga: what's the PR we're considering? lots of PR discussed  :-)
<zyga> niemeyer: I specifically explained why that is, those are tested in the two follow-up PRs, that code doesn't have any more tests and adding them here would be non trivial
<zyga> niemeyer: there is a spread test at the end, I believe
<zyga> pstolowski|lunch: yes, but was it from all the boots or just from the current one?
<niemeyer> zyga: No, no tests
<zyga> niemeyer: I can put the remaining patches into this PR, sure
<zyga> niemeyer: I missed this when reading: zyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?
<zyga> thanks!
<niemeyer> zyga: Breaking down independent PRs is nice, but it feels a bit over the limit to be pushing logic that is completely untouched by anything
<jdstrand> mvo: re core16> ack. I manually approved r1. for r2-r6, please request a manual review and I'll approve
<ogra_> jdstrand, the process-control interface allows me to send signals to processes, but doesnt allow me to exec kill or pkill from the core snap, couldnt we allow these two commands so one doesnt need to ship them in the snap ?
<jdstrand> niemeyer (cc pedronis): fyi, the brand store declaration work is on the spreadsheet for this cycle already
<pedronis> jdstrand: yes, pointed that out on a different channel
<jdstrand> ah yes, I see that now
<zyga> mvo: I'm re-working the last patch of the set, I think this will correctly handle all the edge cases, transitions and what not
<mvo> zyga: \o/
<zyga> mvo: I will share a little while after the standup as I'm making some more changes based on experiments and some thinking
<mvo> zyga: can't wait to see/try it
<mvo> zyga: sure
<zyga> mvo: let's HO then to discuss if this is sane
<mvo> ok
<mup> PR snapd#5454 closed: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5454>
<niemeyer> zyga, mvo, all: Won't attend the standup.. have a conflict today
<mup> PR snapd#5472 closed: interfaces: make core-support a no-op interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5472>
<mvo> niemeyer: ta
<mvo> 708947
<mvo> niemeyer: thanks for the heads up
<ogra_> hmm, how can snap and snapd be at different versions in "snap version" output .. thats weird https://forum.snapcraft.io/t/creating-a-python-daemon-to-interact-with-gpio/6177/10
<ahoneybun> wow :     1min 38.255s snapd.seeded.service
<jdstrand> ogra_: added to the list for the next batch of updates
<ogra_> ahoneybun, pfft ... try on an arm board
<ogra_> jdstrand, thanks, thats really helpful i think
<ogra_> ahoneybun, i have an image seeding 2 snaps (mir-kiosk and chromium-mir-kiosk) that takes 20+ minutes for the first boot (15 of that just seeding chromium)
<ogra_> i'd *love* to have an 1:38 firstboot :)
<Chipaca> ogra_: they can get out of sync if somebody has cobbled together the system out of random bits they found on the internet
<ogra_> Chipaca, well, this seems to be a dell customer with an edge gateway (the caracalla gadget seems to be in use, there are interfaces called caracalla)
<Chipaca> ogra_: this is a core system, so no re-exec
<ogra_> right
<Chipaca> ogra_: because you're supposed to already be booting from core
<ogra_> no re-exec but also snap and snapd come from the same core snap usually
<Chipaca> ogra_: so I'd first inquire how they built or otherwise obtained the system
<Chipaca> ogra_: e.g. if they copied it in some weird way
<Chipaca> ogra_: i mean: if all were ok, it's impossible
<Chipaca> ogra_: so something is not ok
<Chipaca> ogra_: i'd start with #0: users lie
<Chipaca> ogra_: and go from there :-)
<ogra_> yeah, i asked if he tinkered with the install in some form
<jdstrand> roadmr: hi! can you pull r1093 of the review tools?
<jdstrand> mvo: that has the core16 override adjustments ^
<roadmr> jdstrand: hello! certainly, I'll start the usual paperwork
<roadmr> jdstrand: when time permits, could you help reply to this folk: https://forum.snapcraft.io/t/my-snap-lbe-device-management-was-rejected-on-the-store/6242/2 Also we were wondering if there's like a boilerplate text (perhaps more detailed than what the review tools say) we could use for people requesting snapd-control. If what the tools reply is enough in your opinion, that works as well
<jdstrand> roadmr: I thought your answer was great. there is boilerplate in the wiki: "The snapd-control interface is reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system and is not usually needed for typical snaps. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the 'store' category if this can be discussed in public or the 'sensitive
<jdstrand> roadmr: I can adjust the review-tools too. let me try to do something for r1094 real quick
<roadmr> jdstrand: yes, that's pretty much what the tools say, which I thought was clear
<roadmr> in that respect, what this person did was correct, he came to the forum, and in there we can explain in more detail and discuss with them
<jdstrand> roadmr: it isn't clear who should respond. really, this is a brand store question
<jdstrand> roadmr: I'll ping kyleN in the topic
<roadmr> jdstrand: right... well in a sense it's not a brand store question since his snap exists in the global store. So if he doesn't make a good case for that, a simple "denied but you can register a snap name to your brand store and do it there - don't have one? talk to Kyle!" might be good.
<jdstrand> roadmr: Ok, I'll adjust the wiki then
<roadmr> thanks jdstrand
<mvo> jdstrand: \o/
<pstolowski> zyga: what was the command you wanted me to try?
<pstolowski> Trevinho: ping
<zyga> pstolowski: sudo /usr/lib/snapd/snap-update-ns gnome-calculator
<zyga> mvo: re, I'm back home now, it was too hot in the sun
<zyga> mvo: I'm mid-way through lunch (which doubles as bfast)
<zyga> mvo: I'll give you an update soon
<roadmr> brunch. What even is brunch?
<jdstrand> roadmr: how is this: https://paste.ubuntu.com/p/DbWDvmQGyG/ ?
<niemeyer> mvo: Do you have sec for a quick call?
<niemeyer> pedronis: You too if you have a moment
<roadmr> jdstrand: great, looks good! more informative about the prospect of brand stores
<mvo> niemeyer: sure
<niemeyer> mvo, pedronis: https://meet.google.com/dob-pjfr-rkz
<pstolowski> zyga: this didn't help
<pstolowski> willcooke: ping
<zyga> pstolowski: that's consistent with what I suspected then
<zyga> pstolowski: thank you
<mborzecki> https://www.reddit.com/r/linux/comments/8waf37/ubuntu_1804_linux_kernel_update_causes_boot/
<pstolowski> zyga: np
<willcooke> pstolowski, hey
<pstolowski> willcooke: hey, who is the best person to talk about gnome-calculator snap (and other gnome- snaps)?
<willcooke> pstolowski, kenvandine
<pstolowski> willcooke: great, thanks
<willcooke> pstolowski, he's travelling this week to GUADEC, so he might not be active on IRC - if you get stuck drop an email our way
<kenvandine> pstolowski, i'm arround, but in a meeting
<kenvandine> pstolowski, and email would be best
<pstolowski> kenvandine: sure
<roadmr> jdstrand: pardon the silliness, where's the wiki with the text you pastebinned earlier?
<jdstrand> roadmr: https://wiki.canonical.com/AppStore/Reviews
<roadmr> jdstrand: thanks! We'll keep it as reference for the future
<jdstrand> roadmr: I suggest also subscribing to the page
<roadmr> Done! good idea jdstrand, thanks
<pedronis> niemeyer: was afak having a break
<niemeyer> pedronis: No worries, all good, we can sync tomorrow in the standup if we don't have an earlier opportunity
<zyga> mvo: still iterating over this
<zyga> mvo: I think the idea is sound but maybe not the direct implementation I went for
<zyga> mvo: (large and boring change)
<mvo> zyga: ok
<zyga> mvo: tests are not failing anymore, let me see if spread works
 * zyga -> coffee and more shade
<zyga> my laptop is super hot from the sun
 * genii slides zyga a fashionable parasol
<roadmr> genii: it's for the laptop, I bet zyga is happy to get some sunshine after the long polish winter :)
<mvo> pedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly?
<mvo> niemeyer: your opinion on 5440 would be great, no need for an in-depth code review (also that is welcome as well of course), more the question in the PR description. in a nutshell the question is: right now if refresh.timer is set we ignore refresh.schedule. should we do the same if "reresh.schedule=managed" is set? because in the old code we look at this special "managed" propoerty first before looking at refresh.timer/sc
<mvo> hedule. it means we *might* break people with refresh.schedule=managed but refresh.timer=some-thing-else (hope the question make sense, the PR also explain it slightly more verbosely)
<niemeyer> The question makes sense, but it's not clear what "should we do the same" means in this context
<niemeyer> It could mean two different things: 1) Respect refresh.schedule=managed; 2) Respect refresh.timer=managed
<mup> PR snapd#5458 closed: tests: check catalog refresh before and after restart snapd <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5458>
<mup> PR snapd#5467 closed: tests: stop restarting journald service on prepare <Blocked> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5467>
<niemeyer> mvo: I think we should keep the invariant: if we set refresh.timer, the value of the old setting doesn't matter anymore, whatever its value
<zyga> roadmr: yes, this year the summer has really arrived early, with the exception of last week it's a record-breaking year in many cases
<roadmr> zyga: like my neighbor says, "the weather is all f**d up"
<niemeyer> mvo: Then, we should respect "managed" in the new setting, in a way equivalent to how we respected it in "refresh.schedule" before
<roadmr> record heat, then record cold... ti's all insane
<Chipaca> roadmr: add more energy to a system and you're going to see more extremes to any oscillations you saw before (as long as you don't break it)
 * Chipaca crosses fingers
<roadmr> Chipaca: oh we're well on our way to break it :(
<Chipaca> roadmr: eh, probably not
<Chipaca> roadmr: i mean, we might all die, but it looks like earth'll be just fine
<Chipaca> we should start burying stuff for non-human archeologists of the future just to mess with them though
<mvo> niemeyer: the PR implements the behavior that if refresh.timer is set the setting of refresh.schedule is ignored, so it seems the PR is fine and my questions is answered
<roadmr> Chipaca: https://wiki.canonical.com/Quotes#A_matter_of_rates
<pstolowski> zyga: as expected, nothing interesting in my state.json wrt gnome-calc issue
<niemeyer> mvo: Cool, I can review this afternoon it if you want, or LGTM if you think that's good enough info
<mup> PR snapd#5430 closed: tests: enable new fedora image with test dependencies installed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5430>
<mup> PR snapd#5448 closed: tests: start using the new opensuse image with test dependencies <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5448>
<zyga> pstolowski: can you corelate the mount/unmount logs you gave from journalctl with your reboot to check if _any_ of those happened since your last boot
<mup> PR snapd#5399 closed: tests: moving install of dependencies to pkgdb helper <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5399>
<zyga> pstolowski: I believe you can do this with journalctl -b -1
 * zyga checks
<zyga> hmm
<zyga> run journalctl --list-boots
<zyga> actually it's just journalctl -b 0
<zyga> pstolowski: ^
<pstolowski> zyga: here you go, not sure if it's interesting:
<pstolowski> https://www.irccloud.com/pastebin/aUJvZDwq/
<mup> PR snapd#5242 closed: tests: new test for joystick interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5242>
<pstolowski> zyga: and my system was started on Jul 1, 20:48
<mvo> pedronis: 5197 looks good, I would love a test tweak but I'm inclinded to merge just to get it into 2.34 - or is there a reason not to have it there?
<pedronis> mvo: afaik  the text  hasn't been finalized
<pedronis> mvo: sparkiegeek should know more
<mvo> pedronis: aha, I see he added a coment ~1h ago
<mvo> pedronis: there is an updated text, I can update/push if you want. I readded blocked for now to ensure it does not get in prematurely
<pedronis> mvo: ah, IÂ missed that, yes we have a message, yes please update
<zyga> pstolowski: so according to this your system has booted on the 1st, started the two units and never stopped them
<zyga> pstolowski: that is useful, thank you
<mvo> pedronis: will do, thank you
<zyga> pstolowski: I will do some experiments, this is all I needed now
 * zyga forgot about the coffee and left it on the fire for too long
 * Chipaca ~> cuppa tea
<mvo> pedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly? (not sure if you saw this or if I missed the reply)
<pstolowski> zyga: np. i'll keep it in the state it is now for some time in case we want to check something else
<pedronis> mvo: yes
<mvo> pedronis: thanks
<pedronis> mvo: are you going to cut a new 2.34 tomorrow?
<mvo> pedronis: yes, thats my plan, do final 2.34 tomorrow to ensure it can be tested over my vacation in beta/candidate
<mvo> pedronis: anything from your side that should be in it?
<pedronis> mvo: I'm discussing with Chipaca about:  https://forum.snapcraft.io/t/showing-edge-and-beta-in-search-results/4004/9
<AuroraAvenue> Is there a list of games that are snaps on ubuntu on the net sommewhere ?
<mvo> reviews for 5440, 5422 would be great
<mvo> pedronis: thanks, let me look
<pedronis> mvo: we don't have a PR yet,  it would be small, once we know what exactly needs to go in it
<mvo> pedronis: ok
<mvo> pedronis: it should be fine if its done until tomorrow evening
<mvo> pedronis: 5197 is updated
<cachio> mborzecki, to use amazon linux image
<cachio> https://paste.ubuntu.com/p/Jt3fhhgYgP/
<cachio> you can build spread based on the PR
<cachio> until it is merged
<zyga> mvo: there?
<mvo> zyga: yes
<zyga> sorry, my reverse-i-search foo is rusty
<zyga> what is the suite to run core18 tests against?
<zyga> I want to run the suite that shows core18 with snapd.snap and try interfaces and see what is broken now
<mvo> zyga: spread -v google:ubuntu-core-18-64 but you need to enable it in spread.yaml first, one sec
<mvo> zyga: http://paste.ubuntu.com/p/pz2ksT63jw/
<zyga> thanks
<Chipaca> what's a snap that's not devmode, but not in stable? if you know of one offhand
<zyga> mmm
<mvo> zyga: I get dinner but please keep me updated, I will read backlog
<mvo> Chipaca: test-snapd-eds
<mvo> Chipaca: only available for i386/amd64 though if that matters
<zyga> mvo: ack
<Chipaca> mvo: cheers
<mvo> yw
<zyga> [m]vo: tests are running now
<mvo> zyga: woooooooooooooo
<mvo> zyga: can't wait for results
<zyga> haha, the point of [m]vo is so that you _dont_ read now, enjoy your dinner :)
<mvo> zyga: once the interfaces tests work and are pushed I will push a new core18-all-tests-all-fixes PR so that we can run this in gce
<mvo> zyga: ;)
<zyga> ack
 * mvo really goes now
<mvo> zyga: or you can do that (push that PR), I don't mind :)
<zyga> [m]vo: made some tweaks and re-started, I think it's a bit or a rabbit hole though, I stashed some changes that were going too deep
<mup> PR snapd#5311 closed: tests: start active system units on reset <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>
<zyga> my network is not happy today
<zyga> I ran out of my LTE plan
<zyga> well, maybe not too bad
<ogra_> use buckets
<zyga> this ISP has unlimited LTE that's just capped
<zyga> but capping at 5Mbit is not that terrible actually
<zyga> I will buy a new connection tomorrow as the contract is running out already
<zyga> and the new one has an outdoor all-year antenna
<zyga> and much better plan
<zyga> with enough steel rod I can go above the treeline
<zyga> (though not super sure about that as trees are up to 30m tall
<zyga> (a bit tall)
<zyga> 30-40 meters according to wikipedia
<zyga> maybe not above treeline then
<zyga> ran core18 tests and didn't notice I stashed the change with main re-enabling
<zyga> running with those now
<mup> PR snapd#5477 opened: tests: change the poll interval used by the network-bind-consumer snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5477>
<zyga> mvo: hmm
<zyga> https://www.irccloud.com/pastebin/63my3N4t/
<zyga> any ideas?
<zyga> snap changes 11 (install basic snap) https://www.irccloud.com/pastebin/zcHdhpuE/
<zyga> mvo: other tests are running, I'll let you know once they finish
<mvo> zyga: yes, snap install basic needs some of my core18 PRs, the problem is that the fake store does not have core and that is not installed by defalt on core18
<mvo> zyga: don't worry aobut this one, its understood and under control
 * mvo would love reviews for 5197 5440 5422
<zyga> mvo: with my patches I got this far
<zyga> hmm
<zyga> some pastebin failures
<mvo> zyga: how far?
<mvo> zyga: awsome, push it
 * cachio afk
<mup> PR snapd#5478 opened: many: run core18 tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5478>
<mup> PR snapcraft#2176 opened: [WIP] tests: use pytest as test runner <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2176>
<mup> PR snapd#5479 opened: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <https://github.com/snapcore/snapd/pull/5479>
#snappy 2018-07-06
<mborzecki> morning
<mvo> mborzecki: I see two failures in your PR and in one of my PRs related to arch: snap-run (that tests strace) and interfaces-timezone-control start failing it seems, did anything in arch change?
<mvo> mborzecki: this is very recent, probably started ~during the night
<mborzecki> mvo: systemd got updated recently, that may affect timedatectl
<mborzecki> mvo: systemctl --version
<mborzecki> systemd 239
<mvo> mborzecki: chipacas pr fails in the same two tests, so does mine
<mborzecki> mvo: i can look into it
<mborzecki> timedatectl is probably something silly
<mborzecki> run --strace may be more interesting
<mborzecki> (although i used it yday and saw no issues)
<mvo> mborzecki: ok I just started snap-run with --debug to get an idea
<mvo> mborzecki: I bet with the next master merge we will see master failing as well
<mborzecki> mvo: yup, most likely
<mvo> /var/lib/snapd/snap/strace-static/current/bin/strace: Unexpected wait status 0x8b
<mvo> error: exit status 1
<mborzecki> aah it's using strace from snap
<mvo> mborzecki: how can I install the system strace?
<mborzecki> mvo: pacman -S strace
<mvo> mborzecki: its using the snap as a fallback
<mvo> mborzecki: aha! that worked
<mvo> mborzecki: so I will add strace to the default packages for arch
<mvo> mborzecki: one problem down .)
<mborzecki> mvo: yes, please do
<mborzecki> mvo: do we need to rebuild strace-static snap maybe?
<mvo> mborzecki: thanks for your help with this one?
<mvo> mborzecki: s/?/!/
<mvo> mborzecki: good idea, let me have a look at strace-static
<mborzecki> mvo: i'm looking into timedatectl
<mvo> mborzecki: it should be pretty recent but probably not enough so
<mvo> mborzecki: \o/
<pstolowski> mornings
<mvo> pstolowski: good morning
<mborzecki> mvo: the package one is 4.23
<mborzecki> pstolowski: hey
<mvo> mborzecki: hm, arch seems to have the same version
<mborzecki> mvo: i meant the arch package one is 4.23, the one from strace-static is 4.20
<mvo> mborzecki: aha, ok
<mup> PR snapd#5480 opened: tests: add strace to default arch packages <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5480>
<mborzecki> mvo: that timedatectl problem seems to be some sort of race
<mvo> mborzecki: interessting, maybe they changed the dbus communication or something and now it returns before all changes are made
<mborzecki> hm
<mborzecki> mvo: https://paste.ubuntu.com/p/jpts966WWh/
<mborzecki> mvo: set-ntp behaves the same
<mvo> mborzecki: hm, so racy and we just need to loop over the output for a bit?
<mborzecki> mvo: yes, adding it now
<mvo> ta
<zyga> good morning
<zyga> I think yesterday was the sweet spot of sleep/work cycle, I feel rested and not sleepy
<zyga> mvo: I woke up earlier but I was busy with housework
<zyga> mvo: we can have a call shortly
<mvo> zyga: sounds good, I will make a cup of tea and then I'm ready
<mvo> zyga: I had to add https://github.com/snapcore/snapd/pull/5478/commits/304e27a5b3735f34ebd6ac85fdb0be431c3a50a4 to fix unit tests
<mup> PR #5478: many: run core18 tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5478>
<zyga> aha!
<mvo> zyga: without that firstboot test fails, but my PR now only fails in two arch tests that are unrelated (and are in the process of being fixed)
<newbee> hi, i want to know is the ubuntu core 16 is 32 bit or 64 bit architecture. please help me
<zyga> I removed it because pedronis asked if we could use the production id instead
<zyga> newbee: we support 4 architectures
<mvo> zyga: yeah, we can do that too, just needs some reworks in the firstboot test
<zyga> newbee: x86, x86_64, armv7 and aarch64
<zyga> newbee: two of thoes are 32bit and the other two 64bit
<zyga> mvo: ok, let's add that to the todo list
<zyga> mvo: can snap-ids be forged easily?
<mvo> zyga: yeah
<mvo> zyga: in tests
<mvo> zyga: in the real world I think not
<newbee> ok, so when i install the ubuntu core on Raspberry pi 3 model B(ARMv8), getting the error for serial communication.
<mvo> zyga: very exciting! the integration PR has only 3 failures all in non-core18
 * mvo goes and makes a cup of tea to celebrate
<newbee> is there any version for ARMv8 ubuntu core for raspberry pi 3 Model B. I have downloaded the ubuntu core from https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 and installed on Raspberry pi 3 model B
<zyga> newbee: no because that board doesn't support ARMv8 in practice,
<zyga> newbee: that is, the hardware is there but last time I checked the required early-boot code that toggles to aarch64 is not publicly available
<zyga> newbee: all raspberry pi boards are (still) running in ARMv7 (except for those with older CPUs that use even older v6 instruction set)
<newbee> Ok thanks, i have checked in the ubuntu release, found that ubuntu core version is 16, is there any other version available ?
<zyga> newbee: we are working on the 18 release
<zyga> newbee: it should be available a little bit before ubuntu classic 18.10
<newbee> so we have to wait to work on 64 bit (ARMv8 - Raspberry pi), am i right please correct me.
<zyga> newbee: raspberry pi aarch64 mode is entirely up to the pi foundation, we have no influence over any release dates
<zyga> newbee: I suspect it is more of a design decision to keep the ecosystem simple and unified around a pair of architectures (armv6+armv7) rather than three
<zyga> newbee: you can get other devices today that run in aarch64 mode
<zyga> mvo: ready when you are
<newbee> :-).. actullay we have installed and ran our app in Intel NUC as per you guys guidlines, now we are trying for raspberry pi, please suggest me can i try in raspberry pi 2
<mup> PR snapd#5481 opened: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5481>
<mborzecki> mvo: ^^
<mborzecki> mvo: one quirk, both PRs (yours and mine) will fail on their own :P
<mborzecki> mvo: can you merge yours? it failed on google:arch-linux-64:tests/main/interfaces-timeserver-control as expected
<mvo> mborzecki: sure, I can merge yours or you merge mine
<ogra_> newbee, you really dont want to run armv8 on a 1GB RAM board ... v8 binaries allocate twice the amount of RAM by default when running
<mborzecki> mvo: merge yours, it alreay ran, i'll restart the build on mine then
<mup> PR snapd#5482 opened: tests: fix tests on arch  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5482>
<ogra_> newbee, what are the benefits you expect of running v8 on a Pi ? will you do a lot of number-crunching and heavy math operations on it ?
<mvo> mborzecki: snap :)
<mborzecki> mvo: ta
<mup> PR snapd#5481 closed: tests/main/interfaces-timeserver-control: account for non-immediate changes with systemd >= 239 <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5481>
<jamesh> mvo: I can't push branches to ~snappy-dev, but the source code to test-snapd-eds is in the snapd tree
<mborzecki> pedronis: hi, could you do a quick sanity check on https://github.com/snapcore/snapd/pull/5426 in case something non-obvious is missing?
<mup> PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<Chipaca> pedronis: o/
<pedronis> mborzecki: yes, IÂ plan to do reviews today
<pedronis> Chipaca: hi
<mborzecki> pedronis: great, thanks!
<mup> PR snapd#5482 closed: tests: fix tests on arch  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5482>
<Chipaca> pedronis: #5479 is the scope pr
<mup> PR #5479: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <https://github.com/snapcore/snapd/pull/5479>
<pedronis> Chipaca: ah, thanks, IÂ missed it (somehow)
<mup> PR snapd#5480 closed: tests: add strace to default arch packages <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5480>
<Chipaca> pedronis: I should've gone with a more clickbaity title maybe
<pedronis> Chipaca: I think is more of a case of too many PRs
<mvo> Chipaca: I labeled that 2.34 - is that correct?
<Chipaca> mvo: I believe so
<mvo> excellent
<mvo> jamesh: thank you, I will take care of it then
<mborzecki> mvo: we need to pick the test fixes for 2.34
<mvo> mborzecki: indeed, let me do that
<pedronis> Chipaca: afaict   scope=wide  is only about risk, not finding other archs?  am IÂ missing something
<Chipaca> pedronis: ah i might've misunderstood
<Chipaca> let me test
<Chipaca> pedronis: you are correct
<Chipaca> pedronis: i'll fix that
<pedronis> Chipaca: +1 with a couple of wonderings, also related to that
<Chipaca> pedronis: I thought the argument was about risks and architecture (ie have it be a driving force towards stable + multi-arch), but I misunderstand things a lot
<pedronis> Chipaca: I always saw  it called "find edge and beta in search"
<Chipaca> k
<pedronis> maybe there's a general misunderstanding, not sure
<phako> hi - I'm currently struggeling to get software running that loads plugins from /usr/lib/x86_64/ - it claims that it cannot find the libraries - what exactly am I missing there?
<Chipaca> architectures was about info i guess
<pedronis> Chipaca: worth poking roadmr when is around
<pedronis> Chipaca: yes, indeed  some errors cannot refert to info because info doesn't do multi-arch
<Chipaca> phako: try 'snap run --shell your.app' and look in *that* /usr/lib
<phako> well they are in the squashfs
<phako> but let me check
<Chipaca> phako: maybe your LD_LIBRARY_PATH is wrong then
<phako> hm, they are indeed missing from the shell
<phako> odd
<mup> PR snapd#5483 opened: tests: fix arch tests (2.34) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5483>
<Chipaca> phako: the squashfs isn't at /
<phako> ah!
<Chipaca> phako: so if they're in the squashfs they'll be under $SNAP
<Chipaca> phako: so your library path should have something like $SNAP/usr/lib/yadda
<phako> not sure that works, might be that gphoto is looking for hardcoded paths
<phako> sec
<Chipaca> phako: might be that you need to build it from source to look at the other paths then :-)
<phako> bah. :)
<Chipaca> phako: if it's regular dynamic libs, setting LD_LIBRARY_PATH should work
<Chipaca> phako: if it's doing plugins and dlopening stuff, it might be looking in more than one place (maybe via XDG_* env vars)
<Chipaca> figuring out the latter is a lot of fun
<phako> well for shotwell I'm pretty sure it looks in the hardcoded libdir (fixable) for gphoto I'd actually have to check the code
<Chipaca> (in the early days we even submitted patches to, iirc, xkb so you could override where it looked for stuff)
<Chipaca> anyhoo, good luck :)
<phako> thx
<pedronis> mborzecki: #5426 looks fine, the questions are more what we will do in api.go.  just left a small comment
<mup> PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<pedronis> mvo: what's blocking #5422 ?
<mup> PR #5422: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/5422>
<mvo> pedronis: aha, I think this one is good now, iirc yesterdays tests were unhappy, let me squash-nmerge it (and cherry-pick)
<phako> Chipaca: hah - gphoto2 actually has an environment variable for that. cool
<mup> PR snapd#5422 closed: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5422>
<Chipaca> phako: winning
<pedronis> Chipaca: probably worth linking to the PR from the topic
<mvo> 5476 needs a second review, maybe Chipaca has some cycles for this?
<Chipaca> hmm, google:arch-linux-64:tests/main/interfaces-timeserver-control and google:arch-linux-64:tests/main/snap-run have failed twice in a row
<mvo> very few 2.34 milestoned PRs left :)
<Chipaca> mborzecki: do you know anything about that ^?
<mvo> Chipaca: yeah, we fixed it this morning
<Chipaca> mvo: i'll take a look
<mvo> Chipaca: just merge msater
<Chipaca> mvo: w00t
<mvo> master even
<Chipaca> no, no, now i'm going to merge msater
<Chipaca> too late to change it
<mvo> lol
 * mvo hugs Chipaca 
 * Chipaca hugs mvo back
<phako> btw, is udev workin inside a snap?
<Chipaca> pstolowski: ^ one for you i think
<pstolowski> phako: no
<mvo> zyga: we have a green run on 5478!
<zyga> mvo: looking
<zyga> mvo: wait, so holidays now? :D
<mvo> zyga: :-D
<Chipaca> mvo: so I need to squash things for 2.34?
<phako> pstolowski: k, thanks
<mvo> Chipaca: just if they have a gazillion of commits
<pedronis> Chipaca: if they are not a single commit anyway, yes, easier to back-port
<mvo> Chipaca: if you do the cherry-picking and proposing I don't mind
<mvo> Chipaca: I mean, its just convenient
<mup> PR snapd#5476 closed: snapstate: make sure all *link-*snap tasks carry a snap type and further hints <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5476>
<Chipaca> bbiab
<mup> PR snapd#5484 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5484>
<zyga> mvo: ok, I have it
<zyga> mvo: I will push in a moment
<pedronis> mvo: anoteher backport ^
<mvo> pedronis: yay
<mvo> pedronis: thank you
<pedronis> still waiting for 5197 to get green
<zyga> mvo: ok, ready now
<zyga> pushing to two PRs
<zyga> man, something is wrong with my network in ubuntu :/
<zyga> mvo: I pushed https://github.com/snapcore/snapd/pull/5439/commits/ca539763589fc20536dea6180cb25292ec55431c
<mup> PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
<zyga> mvo: I also pushed https://github.com/zyga/snapd/commits/feature/core18-snapd-implicit
<zyga> mvo: out of that the essence of what I told you about is: https://github.com/zyga/snapd/commit/09bf3fb17fbad8db32e2b3e2bcca2af74c451733
<zyga> mvo: the part that I said was missing in the test branch is now done as https://github.com/zyga/snapd/commit/5deb5e89be201f07b80d7d3d8e953156beaaa958
<mvo> zyga: cool, I check in a sec
<zyga> and there are some follow up clenaups there
<zyga> mvo: my suggestion is to take your integration branch, yank all my prior patches that are not in master and add just https://github.com/snapcore/snapd/pull/5485
<mup> PR #5485: testing: support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5485>
<mup> PR snapd#5485 opened: testing: support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5485>
<zyga> mvo: the only remaining thing I strongly know about is remaping of outgoing API responses
<zyga> mvo: so what's next, what should I focus on?
<zyga> mvo: I have some branches I can work on for interfaces
<zyga> mvo: we could also talk to pedronis to explain the approach we took
<mvo> zyga: yeah, I think the next step is to sync with gustavo and samuele to get advice
<mvo> zyga: I merge/run your PRs now in the integration branch
<zyga> thank you
<zyga> mvo: you can keep the one patch I didn't include here, the one that does simple remapping in the client
<zyga> mvo: or one of the tests will fail, but this is not that important
<mvo> zyga: $ snap interfaces -i network now shows: "snapd:network  network-consumer" before it was showing ":network"
<zyga> this is what I meant above ^
<zyga> it was client-side remapping that was -1 by pedronis
<mvo> zyga: aha, ok
<zyga> the code there is a bit weird IMO as it does cliend side remapping anyway (for system)
<ogra_> when will the urandom fix land in edge (or did it already) ?
<ogra_> (working on my kiosk images firstboot on a pi3 takes around 8min til mir-kiosk and chromium are seeded ... i just noticed wiggling the mouse cuts that down to 5min so there is some chance the fix will help with slow arm firstboot too)
<ogra_> (talking about the snapd workaround obviously ... )
<zyga> mvo: you can try this:
<zyga> use "nick" to perhaps understand parts of snapd snap https://www.irccloud.com/pastebin/qHO4nsvj/
<mvo> ogra_: our fix does unfortunately not help with the real seeding issue
<pstolowski> zyga: can https://github.com/snapcore/snapd/pull/5433 be turned into +1? ;) i'm happy to discuss why it's needed
<mup> PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
<zyga> pstolowski: let me look
<mvo> ogra_: when seeding happens for real we need real randomness and that will block until the kernel is fixed - what version of the kernel do you use?
<mvo> zyga: that was the part that was NACKed ?
<zyga> mvo: no, I did an explicit abbreviation of both "core" and "snapd" in cmd_interface*
<ogra_> mvo, whatever is in edge, one sec ...
<pedronis> mvo: to be clear I didn't nack, I'm just generally confused why we do that in the client and not the api
<zyga> mvo: the nick idea is IMO broken
<zyga> mvo: if we want system we had a PR for that
<ogra_> mvo, pi2-kernel 4.4.0-1092.100 (56)
<zyga> if we don't want system, what do we want? core or snapd?
<zyga> mvo: this is related to the question about for how long we should re map the outgoing state
<zyga> (not related to rollbacks)
<pedronis> mvo: it seems a hack that started with core vs ubuntu-core
<zyga> that is when we should show users that it is really snapd that holds the slots
<mvo> ogra_: did that kernel get the crng change? I thought that was 4.8+ only
<pedronis> and then it kept growing
<pedronis> but is  a bit unclear it's the right place for it
<pedronis> it just keeps growing
<zyga> pedronis: the iteration of remapping is going to re-map the outgoing API as well
<mvo> pedronis, zyga yeah, I will update the test and we can think about a better way
<zyga> pedronis: that's hte only remaining part
<zyga> pedronis: I agree, I would rather remove the nick concept altogether but I'm not sure why we introduced it
<mborzecki> pedronis: i'm gonna land #5426
<mup> PR #5426: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<pedronis> zyga: maybe we are not talking about the same thing
<pedronis> (me is a bit confused)
<zyga> pedronis: I think you are referring to an earlier RFC patch where I was abbreviating "snapd" like we abbreviate "core"
<zyga> pedronis: on the client side
<ogra_> mvo, i dont think the 4.4 kernel had any issue, my hope was the dropping of getrandom() in some places in snapd might help in general here... but if the actual seeding isnt involved in that thats indeed moot
<zyga> pedronis: is that correct?
<pedronis> well, we want to do that
<pedronis> the question is where to achieve it
<mup> PR snapd#5459 closed: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>
<zyga> abbreviation was always client side
<mborzecki> mvo: #5455 can be landed too?
<zyga> I think to answer the how part we need to decide what to do long term
<mup> PR #5455: many: assorted shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5455>
<zyga> will we pretend core has the slots?
<zyga> (not in the state but in the user-visible places)
<pedronis> zyga: I think the hack as it was existed because of core vs ubuntu-core
<zyga> the hack being the nick concept?
<mup> PR snapd#5426 closed: client, cmd/snap: pass snap instance name when installing from file <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5426>
<pedronis> zyga: no the fact that in the client we check  for core,  then it became ubuntu-core, then system (not even sure why) and now snapd
<pedronis> this is getting out of hand
<zyga> pedronis: I think this grew out of the desire to have explicit and non-magic API and a bit of magic in the CLI to make users life easier
<zyga> if we abbreviate on the server then this is an API break
<pedronis> but the api now is kind of magic anyway
<pedronis> because you can use core even if it doesn't exist
<pedronis> no?
<pedronis> it's magic on the way in, but not out?
<zyga> yes, but that is backwards compatible
<zyga> I plan to make it magic on the way out, yes
<zyga> my only real issue now is how long we keep the magic
<zyga> and if we can kill the nick concept once we decide
<zyga> for state we can keep the magic indefinitely really
<zyga> I'm not sure if there is real value in keeping the magic in the API for too long
<zyga> (and the state should drop the magic once we have epochs and a single snapd that doesn't roll back)
<pedronis> zyga: to be fair I'm also not sure why we have:    || slot.Snap == snap.UseNick("core")  ?
<pedronis> when does the api return system there?
<zyga> I don't think we ever do that
<zyga> it feels like dead code IMO
<zyga> let me check
<zyga> pedronis: the interface repo which answers that query never talks about "system"
<zyga> so perhaps just symmetric but unused code
<pedronis> yes, something is off there
<zyga> yes, agreed
<zyga> I'm happy to clean it up once there is agreement on what to do exactly
<zyga> my gut feeling is:
<zyga> remap both sides completely for now
<mup> PR snapd#5197 closed: cmd/snap: display a link to data privacy notice for interactive snap login <Simple> <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5197>
<zyga> drop system nick idea (why do we have it if this is the only instance of the "system" term in the whole interfaces and we explicitly chose not to do a "system" snap that holds slots)
<zyga> once epochs land migrate the state
<zyga> once we feel like it stop talking about core as host in the API and start to refuse "connect foo:network core:network"
<zyga> that's my rough idea that is least disruptive and most consistent
<mup> PR snapd#5440 closed: snapstate: allow setting "refresh.timer=managed" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5440>
<pedronis> zyga: well,  we have it for symmetry with the use in gadget defaults
<pedronis> also now connections accepts it too
<zyga> interesting
<zyga> hmm
<zyga> well, maybe that should say snapd instead?
<zyga> I mean, it's half half now
<pedronis> it's even the only spelling
<zyga> not all the way in
<pedronis> well,  we decided not to use snapd
<pedronis> for defaults
<pedronis> it was an explicit decision
<mborzecki> system was to be used there (among other things iirc)
<pedronis> zyga: the issue is essentially   core, snapd  in the end  are implemetnation details
<pedronis> if we keep exposing them,  we keep needing to migrate people away
<zyga> pedronis: this feels like a one way mapping though, people ask for system, get snapd
<zyga> pedronis: it is also odd that you see system as a snap name
<zyga> but it's not installed, has no info, etc
<zyga> it feels okay if this is an "alias" of some sort
<pedronis> well, it's odd that system plugs are on a snap or another
<pedronis> lots of things are odd
<zyga> perhaps but at least it is a real snap you can see
<zyga> it really doesn't matter which as long as we are clear about the semantics, my point is that right now we are not clear because it's sometimes system, sometimes core
<zyga> and with the introduction of snapd it's a growing complexity problem
<zyga> the api talks about "core"
<zyga> the users see "system"
<pedronis> remember as well that we planned to deprecate that api/comamnd
<pedronis> wasn't pawel working on something else called connections?
<zyga> this is not just here, it's also visible in the new api
<zyga> snap interface is the new api and it is visible (core) there
<pedronis> but that work isn't finished
<zyga> the connections api is not written down anywhere so I cannot comment
<zyga> the interface work is finished, the connection is not
<zyga> (singular interface)
<pedronis> zyga: correct, see what it says for  "snap interface network"Â under slots
<zyga> in the client it says system (client side remapping)
<zyga> in the api it says core
<mup> PR snapd#5478 closed: many: run core18 tests <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5478>
<pedronis> zyga: we need a bit to decide if it should keep saysing core or snapd or system
<zyga> I agree
<pedronis> we are changing something either way
<zyga> what was the rationale to use system in the gadget configuration language?
<pedronis> (I'm also not entirely sure we anything is using those apis programatically atm)
<zyga> pedronis: at the very least gnome software is using them
<zyga> I believe this is where it gets the interface summary from, at least
<mup> PR snapd#5484 closed: snapstate: make sure all *link-*snap tasks carry a snap type and further hints (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5484>
<mborzecki> zyga: iirc not all api pieces could do remapping of system/core due to the risk of breaking the api
<zyga> mborzecki: can you give me an example?
<mup> PR snapd#5483 closed: tests: fix arch tests (2.34) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5483>
<mborzecki> zyga: i think that snap interface foo is remapped at the client side
<zyga> but foo is the interface name, not plug or slot name
<zyga> interface talks about interfaces, not plugs and slots, as the primary concept
<zyga> connections will have this issue
<mborzecki> zyga: well whatever was coming down in snap interface(s) queries was being remapped at the client side
<zyga> mborzecki: currently only the "system" <=> "core" is remapped
<mborzecki> zyga: yes
<zyga> but again partially, you cannot see "system" slots via snap interface*s*
<zyga> we just have to decide what we want
<pedronis> mvo: are you doing the cherry-pick for the snap login change?
<mvo> pedronis: yes
<pedronis> thx
<mvo> pedronis: its in 2.34 now, waiting for the full branch test run right now, tests are very unhappy today it seems
<pedronis> yes, I see a lot of red there
<mup> PR snapd#5486 opened: tests: run all spread tests on core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486>
<mvo> pedronis: I am checking right now for patterns but nothing emerging currently
 * mvo considers lunch
<zyga> ok, I have functional response remapping now
<zyga> mvo: I'll push them to 5485
<mvo> zyga: oh, neat
<zyga> pushed now
<mvo> zyga: this means the interface-cli test does not need any change anymoreÃ
<mvo> ?
<zyga> yes
<zyga> settle is not converging https://www.irccloud.com/pastebin/dW6uZhJt/
<mvo> zyga: right - one sc
<zyga> I need to re-map legacy responses as well
<mvo> zyga: thats the patch I told you about
<zyga> aha
<zyga> I will do legacy remapping now
<zyga> (legacy "snap interfaces" response)
<mvo> zyga: https://github.com/snapcore/snapd/pull/5486/commits/3be7a6ac8c4ee462ed53b5ff2fa8a5ec18f43aa6
<mup> PR #5486: tests: run all spread tests on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486>
<mvo> zyga: either this or tweaking the firstboot_test to include the snap-id of the production snapd
<zyga> thanks, I'll cherry-pick that
<zyga> odd, I don't have the base patch in my working branch
<zyga> but the helpers landed, no?
<zyga> I mean the policy work
<zyga> well, that's fine anyway
<zyga> mvo: once you cherry pick those patches and run the tests let me know, ok?
<mvo> sure
<zyga> thanks!
<zyga> I need to do a housework errand before my wife gets here :)
<mvo> zyga: https://github.com/snapcore/snapd/pull/5486 - green
<mup> PR #5486: tests: run all spread tests on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5486>
<zyga> ok :)
<mvo> Chipaca: 5479 is green and has two +1, can I merge and cherry-pick?
<Chipaca> mvo: woo! yes :-)
<Chipaca> mvo: squash also if you wish
<mup> PR snapd#5479 closed: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5479>
<Chipaca> mvo: :-D thank you
<Chipaca> landing code makes me happy
<pedronis> pstolowski: I did a pass again over disconnect-hooks, I'm a bit confused by the new code in checkConnectConflicts, something seems off
<mvo> Chipaca: what makes me happy is that all targeted PRs are in
<mvo> wooot
<pstolowski> pedronis: thanks, let me think
<Chipaca> mvo: that's because you've leveled up
<mvo> Chipaca: level three tea drinker, yay!
<Chipaca> mvo: we should have a sprint in london just to go have posh tea sometime
<mvo> Chipaca: oh yes!
<mborzecki> Chipaca: could you take a look at https://github.com/snapcore/snapd/pull/5455 ? some shellcheck cleanups
<mup> PR #5455: many: assorted shellcheck fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5455>
<Chipaca> mborzecki: first, tea
<Chipaca> post-lunch tea is best tea
<mborzecki> Chipaca: thanks, and enjoy your tea!
<mup> PR snapd#5487 opened: overlord/snapstate: improve PlugsOnly comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/5487>
<vidal72[m]> FYI apparmor is now build-in in one of Archlinux kernels: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux-hardened&id=14eccc6c604d37fa3001146f5bd4ca32ffa15c4f
<zyga> vidal72[m]: that is very interesting. Is it enabled by default as well?
<vidal72[m]> zyga: no
<vidal72[m]> zyga: probably never will be but at least it's something :)
<zyga> mvo: I'll look after some apparmor work now
<mup> PR snapd#5455 closed: many: assorted shellcheck fixes <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5455>
<mborzecki> vidal72[m]: wow, surprising, do you know what was the motivation? i don't recall this being announced on the dev/general mailing lists
<vidal72[m]> mborzecki: the motivation was user requests, that's tiny change in general and mantainers don't have to explain their choices in ML
<mborzecki> vidal72[m]: well that's the backstory about linux-hardnend :P
<mborzecki> vidal72[m]: any clue if the userland bits will come to the main repos?
<vidal72[m]> mborzecki: it depens on some TU/dev wanted to mantain it. For now there is no interest
<mup> PR snapd#5488 opened: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488>
<vidal72[m]> mborzecki: but compiling userspace isn't a big deal after all
<mborzecki> vidal72[m]: but it touches quite a bit of core packages
<mborzecki> vidal72[m]: and it's still some building you have to do
<vidal72[m]> mborzecki: ah, do you mean enabling apparmor support in system tools like systemd? That's out of question for now but I think it's not necessary for using apparmor. Apparmor userspace tools are enough
<jdstrand> vidal72[m]: that's good news :) and yes, I agree that userspace tooling should be enough. not all that much really needs libapparmor and adding it over time (eg, like systemd) seems a fine way to go
<zyga> mvo: I'm very happy with the outcome now, I will drive towards system being the first class slot holder across the API
<vidal72[m]> how long till core18 will replace core16?
<Chipaca> mborzecki: google:arch-linux-64:tests/main/interfaces-timeserver-control moaning again: https://api.travis-ci.org/v3/job/400865901/log.txt
<Chipaca> mborzecki: :-)
<Chipaca> vidal72[m]: <----- this much time ----->
<mborzecki> Chipaca: hm the log is awfully short
<Chipaca> mborzecki: gah! somebody restarted it :-(
<Chipaca> i shoulda saved it
<Chipaca> vidal72[m]: more seriously, AFAIK (but mvo might know more) we're aiming to 18.10 timeframe but not promising it
<mborzecki> Chipaca: which pr is this?
<Chipaca> mborzecki: #5487
<mup> PR #5487: overlord/snapstate: improve PlugsOnly comment <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5487>
<vidal72[m]> Chipaca: thx
<Pharaoh_Atem> vidal72[m]: fourth of never ;)
<Chipaca> niemeyer: https://github.com/snapcore/snapd/pull/4792
<mup> PR #4792: overlord/snapstate: block install of "system" <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4792>
<Chipaca> niemeyer: the error on 'info' is for fun, but the error on install is alright i think
<Chipaca> anyway, school run time
<niemeyer> Chipaca: Yeah, definitey ok on both ends
<niemeyer> Chipaca: The one on info we can fix when we do the alias handling properly.. the other can stay as you point out
<sparkiegeek> hmm, can't seem to get 'snap run --strace' to work (snapd 2.33.1) - I'm suspecting due to running it in a LXD container, is this "known"?
<mvo> sparkiegeek: not known, what error do you get?
<sparkiegeek> mvo: the very helpful "error: exit status 1"
<mvo> sparkiegeek: *cough* quality error message
<mvo> sparkiegeek: let me see
<sparkiegeek> mvo: note installing the same snap on my host and trying it there worked just fine
 * zyga hugs mvo who runs to debug issues just prior to starting holidays
<sparkiegeek> mvo: I tried to strace -ff the 'snap run --strace' but that got me into a hung process which resisted Ctrl-C and Ctrl-\
<mvo> sparkiegeek: do you get more with snap run --strace="--raw"
<zyga> sparkiegeek: any denials?
<mvo> zyga: aha, excellent idea
<sparkiegeek> Jul  6 15:02:49 firestorm kernel: [62403.985473] audit: type=1400 audit(1530885769.599:1727): apparmor="DENIED" operation="open" profile="snap.snap-store-proxy.snap-store-proxy" name="/proc/14257/mounts" pid=14257 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<sparkiegeek>  
<zyga> mmm, that's probably not the issue
<zyga> not with hanging
 * zyga needs to break now and tidy the house a little
<zyga> I will propose the remapping PR (without the remapping condition)
<zyga> and the remapping condition (without the remapping)
<zyga> to discuss next week
<sparkiegeek> zyga: yeah, not that bothered by the hanging, strace of snapd doing strace inside an LXD is almost guaranteed to hit some weird corner cases :)
<mvo> sparkiegeek: anything from snap run --strace="--raw"
<Chipaca> sparkiegeek: did you see jd.strand's "how to strace"? might still be relevant for your use case
<Chipaca> sparkiegeek: https://forum.snapcraft.io/t/stracing-snap-commands/1433
<sparkiegeek> mvo: https://paste.ubuntu.com/p/sCxNJ7Hdz3/
<mvo> sparkiegeek: interessting, out of curiosity, can you snap install strace-static --edge and see if that makes any difference? I doubt but worth a shot
<sparkiegeek> mvo, zyga: https://paste.ubuntu.com/p/CxMYGH326c/ some denials
<sparkiegeek> truomg strace-static now
<zyga> there you go
<sparkiegeek> eugh, off-by-one error on home-row :)
<mvo> sparkiegeek: thats interessting
<pedronis> mborzecki: does #5434 need a merge with master,  IÂ don't see the s/name/path/ change in there
<mup> PR #5434: overlord: introduce InstanceKey to SnapState and SnapSetup, renames <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5434>
<mvo> zyga: maybe its a jamie question but can we get strace work inside lxd inside snapd?
<pedronis> mborzecki: there's been quite a bit of churn with the 2.34 push, probably worth merging master in it either way
<zyga> mvo: I think so
<zyga> mvo: it looks like interplay of both profiles
<pedronis> mborzecki:  I looked a bit at #5452,  seems some tests are missing, error code handling doesn't seem right for install and instance keys.  also the code seems to assume sometimes but not always that download is not used with instance keys (which is fair, but need to be made more explicit)
<mup> PR #5452: store, overlord/snapstate: introduce instance name in store APIs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5452>
<pedronis> mborzecki: I mostly looked at store.go itself, before looking at the higher levels
<pedronis> red, random red
 * pedronis calls it a week
<pedronis> mvo: mborzecki: enjoy the vacations
<mvo> pedronis: have a great weekend
<mup> PR snapd#5489 opened: release: snapd 2.34 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5489>
<cachio> mvo, hey, 2.34 is ready right?
<mvo> cachio: yes, beta validation would be great if we are lucky it can make it to candidate today
<mvo> cachio: and welcome back - I guess you had internet issues?
<cachio> My machne is dead, I am using the backup
<mvo> cachio: uh :( sorry to hear
<cachio> mvo, I had to buy a new charger for it
<mvo> cachio: if possible the sru validation for 2.33 (1773118) would be great, then I can prepare the 2.34 sru
<cachio> sure
<mvo> thanks cachio
<cachio> mvo, is there any diff with the snapd 2.33.1 which I already validated last week?
<cachio> mvo, is it a new one?
<mvo> cachio: diff is absolutely trival http://launchpadlibrarian.net/377239984/snapd_2.33.1ubuntu1_2.33.1ubuntu2.diff.gz
<mvo> cachio: so a smoke test is fine
<mvo> cachio: I think the tags in the sru bug may need updating though but maybe I just misremember
<mvo> (iirc some were still at validation-needed)
<cachio> mvo, great
 * zyga stopped mopping the floor for a sec
<zyga> it's not easy to maintain relative cleanness in the middle of the forest
<cachio> mvo, is there a list of changes for 2.34 in http://people.canonical.com/~mvo/core-changes/html/beta/ ?
<mvo> cachio: should be, let me check, its a cron job
<Naan> hello it seems my spotify was installed automatically through snap and now I don't know how to force it to add "--force-device-scale-factor=1.5" as a command line option
<Naan> by default i mean
<Naan> uh never mind I just used an alias
<Naan> bye!
<mborzecki> pedronis: thanks for the review and enojoy your weekend!
<Chipaca> mvo: late in the game, but what's the easiest way to get a directory made writable across the cores at this stage of the game?
<niemeyer> kyrofa: Heya.. have a few minutes for a call now?
<zyga> Chipaca: goat and a long knife
<zyga> Chipaca: we could expand the core fixup script
<zyga> Chipaca: what is the directory that you need to change?
<Chipaca> zyga: mumble mumble mumble
<zyga> Chipaca: also what do you mean by "across all the cores"
<zyga> do you mean writable-paths writable
<Chipaca> zyga: /usr/share/bash-completion/completions
<zyga> or chmod +w writable
<zyga> aha
<zyga> and you want to drop files there?
<Chipaca> I'm not sure how it slipped through the cracks, but, yeah
<Chipaca> zyga: we try to drop files there, currently
<Chipaca> well, symlink
<zyga> oh
<zyga> that's fun
<zyga> so completions don't work on core?
<Chipaca> oh hold on
<Chipaca> a ghost of a memory is coming back to me
<Chipaca> let me test something
<mvo> Chipaca: what directory is that?
<zyga> Chipaca: ghost of past releases
<zyga> (chains rattling) you will pay your tech debt
<Chipaca> sorry, mis-click
<mvo> zyga: /usr/share/bash-completion/completions ? is that the dir?
<Chipaca> mvo: yes
<zyga> mvo: I think I know as much as chipaca just told me
<Chipaca> but it might not be needed
<zyga> Chipaca: do we really drop files there?
<Chipaca> on classic, we drop snippets in there
<mvo> Chipaca: right
<Chipaca> well, we symlink
<Chipaca> but in core
<Chipaca> i think the expectation is that you'll source complete.sh
<Chipaca> via profile.d or sth
<Chipaca> but, let me check with ondra-san
<Chipaca> unless one of you still have quick access to core
<mvo> Chipaca: sourcing complete.sh would be much easier, making a /usr... dir writable is not ideal on core
<Chipaca> mvo: especially one that has all sorts of junk in it already
<mvo> Chipaca: exactly
<zyga> Chipaca: nope, my wife is driving here with one extra device (pi3-1) from home
<mvo> Chipaca: we are in sync-dir territory then, I don't like this
<mvo> Chipaca: I have access to core, what do you need?
<mvo> Chipaca: fwiw, we control /etc/profile on core, its RO so we can easily append sourcing anything we need there
<zyga> Chipaca: yes
<zyga> and perhaps there's some /etc/profile.d/
<Chipaca> mvo: working with ondra
<zyga> btw, what happens if we do nothing, is something broken now?
<mvo> Chipaca: ok
<Chipaca> zyga: not broken, just not working
<zyga> "honey the car is not broke, it's just not working"
<Chipaca> i mean, the snap still is installable and everything (the completion bits fail but don't block)
<zyga> Chipaca: what is not working?
<zyga> aha
<zyga> I see
<zyga> how did we miss that, we have spread tests for this
<Chipaca> zyga: systems:
<Chipaca>     - -ubuntu-core-*
<Chipaca> mvo: we'll debug it with ondra next week
<Chipaca> mvo: you go away already
 * Chipaca asks JamieBennett to kickban mvo until his holiday is over
<mvo> Chipaca: ok
 * mvo vanishes and hugs Chipaca on the way out
<ogra_> Chipaca, note that mvo is wrong, /etc/environment is rw
<ogra_> 8on core)
 * zyga looks at re-flashing his LTE modem with unbranded firmware by following a Russian forum
<ogra_> what could possibly go wrong :)
<zyga> ogra_: holidays
<ogra_> heh
#snappy 2018-07-08
<mup> PR snapd#5487 closed: overlord/snapstate: improve PlugsOnly comment <Simple> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5487>
#snappy 2019-07-01
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> mborzecki: how are you today?
<zyga> mborzecki: we are moving again but this time relatively very little
<mborzecki> zyga: changing places?
<mborzecki> zyga: it's damn hot today again
<zyga> mborzecki: yeah, we didn't rent a single place for the whole duration of our stay
<zyga> (which is uncertain anyway)
<zyga> mborzecki: here we have finally some clouds
<zyga> mborzecki: it is just 23C and very very pleasant
<zyga> I'll check my PRs, some are close to landing
<zyga> mborzecki: do you think this will pass?
<zyga> https://www.irccloud.com/pastebin/bVNC8zuG/
<mborzecki> zyga: mhm, looks good to me
<zyga> I've replicated the case for generic ubuntu that matches apparmor, starting spread
<zyga> let's see
<zyga> I just noticed the grass is still wet, wow it is really cold and cloudy today
<mborzecki> zyga: isn't that /usr/bin/sh vs /bin/sh ?
<zyga> mborzecki: yeah, I am pretty sure that is is
<mborzecki> zyga: at laest on fedora/centos/amzn
<zyga> mborzecki: we have a magic thing in our spec that disables the rewrite that normally happens
<zyga> mborzecki: which makes me think that:
<mborzecki> zyga: oh, right
<zyga> 1) it was always broken for hotplug
<zyga> 2) device cgroup was not tested on those systems effectively
<zyga> 3) after fixing this we will kill two birds with one stone
<zyga> mborzecki: I'll check that shortly
<zyga> but it sounds plausible to me
<mborzecki> mvo: morning, not taking a day off?
<zyga> mvo: hello
<mvo> hey zyga and mborzecki !
<zyga> how are you doing?
<zyga> good to be home?
<mvo> mborzecki, zyga I will be here today, want to be part of the standup, talk about the sprint and also welcome ian today
<mborzecki> mvo: yay, ijohnson is starting today?
<mvo> zyga: yes, very good to be home, we had a network outage over the weekend, no phone or internet, so even a forced holiday from all digital things :)
<mvo> mborzecki: yes
<mvo> mborzecki: I think so at least, will double check for any last minute changes :)
<mborzecki> mvo: great to have the team grow in size :)
<mvo> mborzecki: yeah, I'm excited too
<mvo> mborzecki, zyga how are you ? what did I miss? sorry for not joining the standup once, it was very busy
<zyga> mvo: relatively quiet week; some excessive iteration on the lxd fix
<zyga> mvo: but it now has two approvals and just a few comments to tweak
<mvo> zyga: \o/ thanks for jumping on this one
<mvo> zyga: and you made the trip and are "settled" now?
<zyga> mvo: haha
<zyga> mvo: we are moving today
<zyga> but not far
<zyga> so ...
<mborzecki> mvo: landed some gadget updates bits, more on reviews still, but we're closing in
<zyga> it's not the most stable work environment ;)
<mvo> mborzecki: yay, thanks for this
<zyga> mvo: I have some feedback from manjaro, one small fix to a shell script to send
<mvo> zyga: cool!
<zyga> mborzecki: I know why that trivial udev change didn't work, fixed, let's see if it passes now
<mborzecki> got an errand to run, bbiab
<ackk> hi, I'm having an issue building a python C extension in a snap (actually a dependency of what I'm snapping). I have a reproducer with a minimal snap that just builds the library: http://paste.ubuntu.com/p/qmxp7rBh6Z/. the error is http://paste.ubuntu.com/p/kgwcB673qf/ am I missing something in the build configuration?
<zyga> mborzecki: it passed, pushed now
<zyga> ackk: looks like lack of header
<ackk> zyga, those headers are in the library itself
<ackk> zyga, -Iast27/Include
<ackk> zyga, needless to say that if I create a virtualenv and pip install typed-ast --no-binary=typed-ast it works
<zyga> ackk: but is that path OK when in snapcraft?
<zyga> it is a relative path, not sure if that is good here
<ackk> mhm
<ackk> zyga right but I think it's assumed to build from the base of the package
<zyga> I don't know, just guessing based on what the errors said
<ackk> not sure if snapcraft does something different, but it should just call pip ?
<zyga> mvo: https://github.com/snapcore/snapd/pull/7048 needs a 2nd review and is super simple
<zyga> mborzecki: final remark on https://github.com/snapcore/snapd/pull/7026 -- I would like not to enforce \n on the final line. I think it is too pedantic and doesn't win us anything while actively closing the utility of the parser down the line.
<zyga> mborzecki: I pushed remaining tweaks and intend to merge when green
<zyga> mborzecki: if you feel strongly about the newline please indicate so
<zyga> mborzecki: since you are on an errand now I'll wait until you return
<mvo> zyga: thanks, checking now
<pstolowski> mornings!
<pstolowski> welcome back mvo!
<mvo> pstolowski: good morning! and thank you :)
<mvo> pstolowski: feels good to be back :)
<zyga> mvo: thank you :)
<zyga> hello Pawel!
<ackk> zyga, I wonder if it has to do with the fact that snapcraft calls "pip wheel" not "pip install", or because of environ
<zyga> I really don't know, it would be good to see if you can reproduce the failure without snapcraft involved
 * zyga jumps at https://github.com/snapcore/snapd/pull/6891 again
<zyga> mvo: 1-2-1 in 15 minutes, right?
<mvo> zyga: yes
<diddledan> ackk: seemingly works when you remove `--no-binary=typed-ast` <-- I've never seen parameters passed this way and have no idea if that is even likely to work
<ackk> diddledan, yes, because on amd64/i386 that library is available as binary. on other arches it fails because it tries to build it. to test it I'm passing --no-binary to reproduce the issue on amd64
<ackk> diddledan, the original issue is that if you have no binary package for that library, it fails to build. I've seen similar issues with other libraries
<mborzecki> re
<mborzecki> zyga: for the sake of landing this fast and since we agreed on it on friday, let's maybe stick to \n for now
<mborzecki> zyga: interestingly the PR with udev helper still fails on opensuse https://github.com/snapcore/snapd/pull/7049#issuecomment-507173763
<zyga> I didn't change opensuse yet
<mborzecki> zyga: take a look at the log, it's like a lib is missing
<pedronis> mborzecki: hi, after the fact comment,  gadget.Partition probably merits a doc comment
<mborzecki> pedronis: ok, will add
<pedronis> thx
<zyga> hello pedronis
<zyga> welcome back!
<pstolowski> oh well, snap config stuff is fun
<Chipaca> pstolowski: orly
<diddledan> ackk: it looks like the failure is induced by setting `CFLAGS="-I/usr/include/python3.6"`
<ackk> diddledan, which is set by snapcraft?
<diddledan> yes
<mborzecki> microk8s uses a vm to start the node?
<diddledan> no, it runs directly
 * zyga could use a coffee
<pedronis> mvo: hi, we still need to publish 2.39.3 to snapd, right?
<mvo> pedronis: checking
<pedronis> mvo: is not even in beta afaict
<mvo> pedronis: it only affects devices so I think we don't need to SRU it, we should make it available on GH but no need for packaging updates either
<mvo> pedronis: let me check that
<mvo> pedronis: oh, the snapd snap - yes, need to check with sergio but yes, that needs to go out
 * mvo prepares beta
<pedronis> yes, the snapd snap
<pedronis> sorry
 * Chipaca takes a break
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049
<mborzecki> zyga: heh, so AA blocked that
<zyga> yeah, I'm so happy we have that distro
<zyga> brb, taking out the garbage
<abeato> pedronis, hey, did you see latest comment from Jamie in https://github.com/snapcore/snapd/pull/5915 ? is that a thumbs up for implementing 'snapctl netplan-apply'?
<zyga> re
<Chipaca> mvo, pedronis, re some of the less serious things we talked about last week I finally heard back from my archiver :-p   http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/presentacion/
<Chipaca> check out those super high resolution photos taken with an actual digital camera omgz
<Chipaca> hmmmm
<Chipaca> pstolowski: for automatic snapshots I suspect having 'expires=YYYY-mm-dd' instead of 'auto' might be more useful
<Chipaca> pedronis: WDYT?
<mvo> Chipaca: woah, when were these pics taken?
<pstolowski> Chipaca: oh wow, who is this guy on 3rd photo? :)
<Chipaca> mvo: '00 iirc
<mvo> Chipaca: amazing :)
<Chipaca> mvo: we were very proud of our server at the time: http://dionecanali.hd.free.fr/~mdione/nikola-gallery/galleries/GrULiC/machines/pv-1/
<Chipaca> proud mostly in that we were able to afford it, and it actually booted and ran fine as long as you held down a certain capacitor on the main hdd during boot
<Chipaca> :-)
<Chipaca> (also that rickety shelf was actually a controlled atmosphere because it was in the atmo lab at the uni)
 * Chipaca still puzzled about 'snap install --verbose'
<ogra> you should make it read the output through speakers very loudly when --verbose is set ;)
<pedronis> Chipaca: what's the question?
<Chipaca> https://forum.snapcraft.io/t/how-to-run-a-snap-install-verbose-in-terminal/12100?u=chipaca
<Chipaca> ogra: xsublim, but for pulseaudio
<pedronis> abeato: we discussed that a bit more last week, I think there is some idea to do that but let "netplan apply" call it if inside a snap
<ogra> Chipaca, lol
<abeato> pedronis, you mean change netplan to call the snapd API to re-start daemons if it detects it is being run inside a snap?
<pedronis> abeato: no, to call an api that does the full apply
<pedronis> not just restart daemons
<pedronis> well really call snapctl, not an api
<pedronis> as low-tech as possible, basically
<abeato> pedronis, ah, I thought that was what 'snapctl netpla-apply' was going to do
<abeato> so no changes there
<pedronis> abeato: yes, but saying the snap will just call netplan
<abeato> pedronis, so the snap will call netplan and netplan will run snapctl netplan-apply?
<pstolowski> Chipaca: expiration instead of auto sounds fine, it would reduce the need to read expiration time again on execution of the task. a side-effect of such change is obviously the effective expiration (calculated when the task is created vs when it's executed)
<ogra> the snap will call snapctl and netplan itself will work aotomonously is what i understand from jamies comments
<ogra> *autonomously
<pstolowski> Chipaca: i'm not sure if it's an issue or not, probably is fine
<pedronis> abeato: yes, something like that
<abeato> ok, I guess that can work too
<abeato> ogra, the wording is slightly confusing tbh, I think he wants to make all this transparent to the netplan caller
<ogra> yeah, true
 * pstolowski lunch
<Chipaca> debian 9 is buster, yes?
<Chipaca> hm, 9 is stretch
<zyga> Chipaca: stretch
<Chipaca> debian has re-exec?
<zyga> https://en.wikipedia.org/wiki/Debian#Code_names
<zyga> Chipaca: yes it does
<mvo> pedronis: snapd 2.39.3 is now in beta, now sergio and cert need to jump on it :)
<ogra> streched re-exec
<pedronis> mvo: ok
<Chipaca> zyga, degville: fwiw https://forum.snapcraft.io/t/cannot-install-snap-store-on-debian-9/12077?u=chipaca
<degville> Chipaca: thanks for the heads-up, looking now.
<mvo> pedronis: also did some investigation about a higher errors.u.c failure rate with the 2.39.3 release for sil2100  but it looks mostly under control (one unknown)
<zyga> Chipaca: aha
<Chipaca> zyga: oho
<Chipaca> zyga: a â¦ gruffalo?
<zyga> whaat? :)
<zyga> mborzecki: pushed to https://github.com/snapcore/snapd/pull/7026
<zyga> I think it's 100% what all the reviewers wanted now
<Chipaca> zyga: "Aha! Oho! A trail on the snow! // Whose is this trail and where does it go?"
<Chipaca> note you need to pronounce 'snow' to rhyme with 'oho!' or you failed
<Chipaca> (also with 'go!' :) )
<Chipaca> zyga: https://en.calameo.com/read/000612803e258cbf5d447
<sil2100> mvo: phew, thanks for the investigation!
<zyga> mvo: replied on that shell script question
<Chipaca> man the snapd package in debian 9 is old and bad and nasty :-(
<mvo> zyga: thx
<Chipaca> doesn't debian have SRUs?
<cjwatson> it's certainly possible to update packages in stable releases.  I have no idea whether it would be possible to convince the stable RMs to take a wholesale update here
<cjwatson> like Ubuntu, somebody would have to make the case for it.  unlike Ubuntu, you wouldn't have management leverage to apply :P
<zyga> cjwatson: FYI, flatpack updates go to backports regularly
<zyga> I think we could consider the same path
<cjwatson> no harm in trying though
<zyga> though our dependency chain may be problematic
<mvo> backports is pretty open in general for updates (iirc)
<Chipaca> almost had a heart attack because debian's snapd doesn't include the fix for the ucrednet vuln
<Chipaca> â¦ then realised it's so old, it doesn't even have the vulnerability
<cjwatson> for backports it generally just needs to be in testing
<cjwatson> and obviously be buildable etc.
<Chipaca> aw man, we have management leverage to apply? somebody should've told us
<Chipaca> maybe we were missing management fulcrum
<mvo> cachio: hey, good morning. snapd 2.39.3 snap is in beta now, please give it a go :)
<mvo> Chipaca: did you see the comment in 7025? should be an easy win and then this one can go in
 * Chipaca looks
<Chipaca> mvo: that i should add a spread test?
 * zyga is hungry, brb
<mvo> Chipaca: yeah, we can do it in a followup as well
<mvo> Chipaca: its actually so simple its probably quicker if I do it instead of writing it here :/ but oh well :)
<Chipaca> mvo: doing it now
<mvo> Chipaca: \o/
<Chipaca> hoping to get feedback from sergio also
 * Chipaca has poked
<Chipaca> zyga: how's your things-i-need-to-review plate? #6695 has a half review and i was wondering if you'd be able to finish it or if i should do it
<zyga> Chipaca: go for it!
<zyga> I'm debugging mount propagation
<zyga> and feeling hungry while the folks go for lunch
 * Chipaca is having lunch
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7049 is green!
<zyga> mvo: ^ this will allow to have bash snaps that don't ship /bin/sh anymore
<zyga> base snaps, not bash snaps
<zyga> mvo: consider it for 2.40 if you want to
 * Chipaca implements type:bash snaps
<ogra> Chipaca, nooo ... make it type:POSIX !!!
<Chipaca> ogra: name:posix, type:msdos
<ogra> lol
 * zyga waits for amiga people to chime in
<zyga> and for spread to spawn
<Chipaca> ships two apps
<Chipaca> vms
<Chipaca> and pcm
<Chipaca> as in pc/m, not as in /dev/pcm
<Chipaca> pedronis: 'cp'?
<Chipaca> > cp, ln use --target-directory in full
<Chipaca> ah
<Chipaca> d'oh
<Chipaca> pedronis: until I pasted it here I thought that said In, not ln
<pedronis> Chipaca: I'm asking whether cutting it down to just dir is good style or not
<Chipaca> pedronis: probably not
<pedronis> not sure myself
<Chipaca> target-directory all over coreutils
<pedronis> to be fair, they let you use just '-t'
<pedronis> otoh this thing will probably be used mostly by scripts/snapcraft
<Chipaca> yeap
<pedronis> so not sure it needs to be short vs clean
<Chipaca> bah
<Chipaca> --basename, for sure
<Chipaca> --target-dir[ectory] was just free :-)
<Chipaca> (and neatly avoids the awkwardness of having something called 'basename' including a directory)
<pedronis> Chipaca: otoh ubuntu-image has -w DIRECTORY, --workdir DIRECTORY
<cachio> mvo, hey, just arrived
<cachio> I'll start with it
<pedronis> and -O DIRECTORY, --output-dir DIRECTORY
<sergiusens> pedronis: Chipaca I would argue that the descriptive long option is better in scripts/code as much as using descriptive non one letter variable names :-)
<Chipaca> --directory-dir=ectory
<Chipaca> sergiusens: agreed
<Chipaca> sergiusens: I don't think you're arguing against the thing :-)
<Chipaca> --target-directory is happening
<sergiusens> coming in late, I guess the discussion is about the best long-option to use?
<Chipaca> sergiusens: yeah, target-dir vs target-directory mostly
<sergiusens> Chipaca: if it helps, the positional argument you have for `pack` is `[<target-dir>]`, so if you are looking for consistency, there is your answer
<Chipaca> dammit :-)
<pedronis> Chipaca: our helps tend to do <*-dir>
 * Chipaca defenestrates a rabbit
<pedronis> those are not option names, they are placeholders really
<pedronis> though
<Chipaca> pedronis: I think --target-directory is the right call
<Chipaca> pedronis: it does jump out in the options though, it's very long, but that might be ok
<pedronis> Chipaca: we do have --ignore-validation
<Chipaca> pedronis: <target-dir> is probably fine as a placeholder but I wouldn't mind if we went full ectory there as well
<pedronis> as far as I can tell the only option that abbreviates (not counting --devmode which is called like that everywhere) is --abs-time
<Chipaca> psh, the longest options are --unicode=[auto|never|always] :)
<Chipaca> download doesn't have that one yet though
<Chipaca> (but i expect to make --unicode and --color global at _some_ point)
 * Chipaca stands up
<Chipaca> pedronis: i'm about to merge the 'snap download' pr, shout if i should hold off
 * cachio lunch
<Chipaca> this chipaca will spontaneously EOD in T-19 minutes
<ackk> is it ok to start services in a post-refresh hook?
<zyga> re
 * zyga resumes PRs
<Chipaca> ackk: yes
<ardaguclu> hello, what is the usage purpose of snapctl?. It is an executable and as I understand some other executable starts it. Am I right?, or I miss something.
<ackk> Chipaca, great, thanks. it did seem to work fine, but wanted to be sure it's really intended to be used
<ackk> ardaguclu, snapctl is used inside snap hooks to interact with the snap system (like, get configs, manage services, ...) for the snap itself
<ardaguclu> thanks.
#snappy 2019-07-02
<zyga> Good morning
<mborzecki> morning
<zyga> Hey :-)
<zyga> Coffee
<mborzecki> zyga: hey
<zyga> Hello mvo
<zyga> Iâll start around 9
<zyga> Need to take a walk and get kids up
<mvo> hey zyga
<mvo> zyga: sure thing
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> added a topic about the tool for building images: https://forum.snapcraft.io/t/snapd-tool-for-building-ubuntu-core-images/12118/1
<mvo> mborzecki: nice
<mvo> mborzecki: looks interessting, we will need to adjust it a bit and then it seems like we can use it for core20 in the recovery to do the initial disk setup
<mborzecki> mvo: sure, it'd be intersting to see it used :)
<pstolowski> morning
<mvo> hey pstolowski ! good morning
<zyga> and I'm working now
<zyga> proper hellos :)
<mborzecki> pstolowski: hey
<zyga> mborzecki: question, do you think jamie's comments on https://github.com/snapcore/snapd/pull/7026 warrant removal of the wrappers?
<zyga> mvo: ^ perhaps you can decide
 * mvo is looking
<mvo> zyga: what wrappers exactly? sc_error_simple?
<zyga> yep
<zyga> mainly for https://github.com/snapcore/snapd/pull/7026/commits/b72ff86fb6712f1dc7bb6dca5152120f8f2ed03b
<zyga> but also because the case of error without a code is common
<zyga> and given that jamie was positive on the error handling I want to keep using this pattern for new code
<zyga> so I though to make it shorter
<zyga> 2nd one is https://github.com/snapcore/snapd/pull/7026/commits/aad7810aff69dc5427825dc8cb59fc103ff725c4
<mvo> zyga: I have not looked at what jamie said, I can do that a bit later. but from what I read so far it seems he simply wants to have the new error handling in a subsequent pr and not distract this "main" pr with it which seems sensible, no?
<mvo> zyga: eh, sorry, I did look at what jamie said but I have not looked into the broader context or the things disucssed earlier, thats what I mean, I have limited context so take it with a grain of salt
<zyga> mvo: it seems sensible but it is also wasteful since I added it in the same batch along with new error check for newlines
<zyga> mvo: shall I remove it and re-propose it?
<mvo> zyga: I can look at the bigger picture in a few minutes (need to finish my current task) and we can have a HO if you want. with my limited understand so far my suggestion would be to simply create a new branch with the new error wrappers and change this one to use the current code which is hopefully not too much work
<zyga> mvo: I don't want HO, just a path forward
<zyga> ok
<pedronis> Chipaca: jamesh forced pushed to 7036 and now I am unclear what you actually reviewd
<jamesh> pedronis: It was a simple rebase to see if it fixed the CI failure.  I don't think the failure has anything to do with the changes in the branch
<pedronis> jamesh: that's not the problem, we do not force push to reviewed PRs
<pedronis> it's entirely a process issue
<pedronis> degville: hi, have you have some time, could you give a look at all the help text in https://github.com/snapcore/snapd/pull/6848 , it needs another pass from me too
<pedronis> s/have you have/when you have/
<degville> pedronis: hallo! Yes, of course. I'd been waiting for the pushes to settle down.
<pedronis> thx
<mborzecki> jq is so nice, too bad when one tries anything other than simple value printing it gets super weird super fast :/
<zyga> re
<zyga> sorry, big interrupt
<zyga> mvo: done now
<zyga> mvo: sorry, had some funny situation over here that required a bit of my attention
<zyga> a car broke down, the driver was polish but didn't speak english, there's a local guy that speaks english and tries to help him with a car mechanic, but they have no common language to use, so I translated from catalan to english to polish along with the help of the guy who knew catalan and english
<zyga> we live opposite to a car shop
<zyga> there must be a movie plot with similar situation somewhere but it just happened for real :)
<mborzecki> https://github.com/snapcore/snapd/pull/7041 is quite simple, bulk of the diff is tests
<zyga> looking
<mvo> zyga: ack, in a meeting right now
<zyga> mvo: no worries, all good
<mborzecki> got to run an errand, back in 1.5h or so
<mborzecki> btw. https://github.com/snapcore/snapd/pull/7044 is a very simple review, pstolowski maybe you could take a look?
<pstolowski> mborzecki: sure
<mborzecki> pstolowski: thanks!
<pedronis> mborzecki: I did a first pass over 6890, I honestly struggled a bit to follow what goes on
<mborzecki> pedronis: maybe we could do a HO once i get back?
<pedronis> mborzecki: not immediately, you should probably read the comment and see if you can make the code clearer
<pedronis> without hand holding the reader
<mborzecki> pedronis: ok, will do
<mborzecki> got to go
<zyga> hmm
<zyga> some odd thing on travis
<zyga> I get tests that time out after .... 6 mintes
<zyga> not run into the log length limit
<zyga> just time out
<zyga> now the logs are 404
<zyga> hmmm
<Chipaca> zyga: 6 minutesish might be the timeout for no output
<zyga> Chipaca: it was some kind of travis fluke, I force-pushed and we can see what happens now
<Chipaca> mborzecki: jq does seem write-only for anything more complicated than a query
<zyga> Chipaca: I agree
<zyga> it's haskell-level interesting -- as in "what does this syntax do?"
<pedronis> Chipaca: +1ed 6848 with some final small comments,  as I said degville should go over the help texts
<degville> pedronis: Chipaca: just looking through it now.. I won't be long :)
<pedronis> pstolowski: hi, there's a typo blocking spread tests in #6977
<mvo> pstolowski: quick question - do we have a forum topic about base: none that I can link to in from the 2.40 release notes?
<pstolowski> pedronis: ah, thanks, fixed
<pedronis> mvo: we still have a couple of things marked for 2.40 ?
<pedronis> 7016 would have also been a candidate for 2.40
<pstolowski> mvo: none that i know of
<mvo> pedronis: yes, some we can cherry pick, let me mark those
<mvo> pedronis: 7016 is marked so that should be fine
<mvo> pstolowski: ta
<zyga> oooh
<zyga> github has a new feature
<zyga> allows reviewers to mark files as viewed so future look at a PR is shorter!
<pstolowski> very nice!
<Chipaca> woo, i now have an actual debian system for poking at
<zyga> Chipaca: debian 9?
<Chipaca> yes
<Chipaca> 386
<Chipaca> an old inspiron 8600
 * pstolowski lunch
<Chipaca> degville: out of curiosity what's the typo in the quotes around 'check-health'?
<degville> Chipaca: different quote marks, unless my sight is getting even worse (which could be the case).
<Chipaca> degville: ah, we've ben using single quote marks for commands and filenames, and double quote marks for â¦ concepts? quotes? other namey things
<Chipaca> e.g. Â«see 'snap help login'Â»
<degville> Chipaca: ah, ok. thanks - that makes complete sense.
<Chipaca> thus Â«"unhealthy"Â» vs Â«'check-health'Â»
<zyga> mvo: you requested  that https://github.com/snapcore/snapd/pull/7026 to be squash merged
<zyga> mvo: I would rather preserve the history there, would that be a problem
<zyga> mvo: note that you can "cherry-pick" this into the release branch as well, using slightly different git command
<zyga> (not patch by patch)
<zyga> alternatively I can propose a 2.40 backport if that helps
<zyga> mvo: would that be okay?
<mvo> zyga: yeah, sure, the issue is only that historically the cherry pick of large amount of patches was cumbersome
<mvo> zyga: please share the git magic
<zyga> I just google for that and end up at...https://stackoverflow.com/questions/34133628/cherry-pick-a-pull-request-into-a-branch
<zyga> I can  open a  cherry-picked PR for 2.40
 * zyga does that
<jamesh> zyga: from your review comments on https://github.com/snapcore/snapd/pull/6954, I think the only think remaining were your comments about the response.go file.  It is mostly a trimmed copy of daemon's Response type, and I'm not sure how much will be needed by whatever APIs we add.
<zyga> jamesh: thank you, I will  look at that shortly
<mborzecki> re
<jamesh> zyga: on another subject, I was working on a new snapd interface that introduces new mount entries, and initially got failures because I forgot to add equivalent  AddUpdateNS rules on the AppArmor side.  As I was adding this, it got me thinking that we could probably generate those rules if presented with a MountEntry struct
<jamesh> it'd reduce the boilerplate, and make sure things like the rules needed for writable mimics were in place
<zyga> jamesh: interesting, that would be doable for sure
<zyga> jamesh: only question if this is any hard with regards to imports and cycles or what not
<jamesh> zyga: I'm not necessarily suggesting that it be done automatically
<Chipaca> pedronis: are there any good & pithy examples of what 'blocked' would be used for?
<zyga> jamesh: I'll try to review your  branches tomorrow  morning my time
<Chipaca> pedronis: I've got Â«e.g. a service needs to be configuredÂ»
<zyga> jamesh: or  today  evening perhaps
<jamesh> zyga: even with an "AddUpdateNSFromMountEntry" function, I could split out the code that generates the osutil.MountEntry structs into a helper shared by the AppArmor and Mount methods
<zyga> jamesh: yeah, that sounds good to me, thank you!
<pedronis> Chipaca: that's a typical example, yes
<zyga> mvo: https://github.com/snapcore/snapd/pull/7056
<zyga> mvo: with this, can I keep the merge commit on the original?
<zyga> mvo: could you do a 2nd look on  https://github.com/snapcore/snapd/pull/7053
<mvo> zyga: will check after lunch
<zyga> thank you
<mborzecki> pstolowski: pushed a little tweak to https://github.com/snapcore/snapd/pull/7044 should be much cleaner now
<mborzecki> on to the filesystem updater
<Chipaca> oh my
<Chipaca> somebody is asking me for help to make Â« curl some-url | bash Â» work better when the script uses snap
<Chipaca> I need to find words with other than four letters to respond
<zyga> Chipaca: WAT\0
<mborzecki> zyga: looking at the kernel for some hints which namespace modprobe gets executed in
<Chipaca> zyga: https://forum.snapcraft.io/t/how-to-run-a-snap-install-verbose-in-terminal/12100/3?u=chipaca
<cmatsuoka> route restablished in my backup link \o/
<zyga> mborzecki: thanks,  I'm looking at something else, task switched  away from that for a sec
<mvo> cmatsuoka: welcome back
<cmatsuoka> main link still hitting route dead ends
<pstolowski> mhmmmm undoConnect only restores conns and doesn't update repo
<mvo> zyga: 7053 needs either squashed or a PR for 2.40 then, whatever you prefer
<zyga> mvo: thanks, I made a 2.40 PR  now
<zyga> oh
<zyga> standup!
<zyga> 2fa
<mborzecki> zyga: hm https://paste.ubuntu.com/p/qRFHzvkqG8/ looks like it's calling mopdprobe from root ns (?)
<zyga> mborzecki: looking
<ogra> Chipaca, you should convince jdstrand to have the security team implement a check in bash if stdin comes from curl and just have it refuse to exec ;)
<zyga> mborzecki: modprobe, yeah
<zyga> I'm not sure how some of the automatic module loading logic works though
<zyga> e.g. when you create a socket
<zyga> is that systemd doing it
<zyga> or kernel doing it
<zyga> or what?
<Chipaca> ogra: these idiots^Wpeople^Windividuals will find a way to circunvent it
<ogra> yeah, sadly
<Chipaca> circumvent*
<Chipaca> silly Spanish spelling rules overrides
<Chipaca> can I change snap so that if it's being run in a pipe from curl, it installs slackware and reboots?
<ogra> have it make a screenshot, mirrror that upside down and force-overlay the screen with it
<zyga> mborzecki: based on what you linked and what I looked starting from that  it does look  like  it is using the mount namsepace of the current process
<ogra> thats immediately visible ... slackware will only kick in on next reboot when the user already forgot he had run that script
<zyga> I will run a test to confirm
<zyga> but first
<zyga> FOOD
<zyga> I'm starving
<Chipaca> ogra: I could install that http proxy that inverted all images
<mborzecki> zyga: i started with the assumption, but the experiment did not behave that way :/
<ogra> +1 !!!
<mborzecki> zyga: probably some magic inside the vfs handlers
<zyga> mborzecki: what did you do in the experiment?
<mborzecki> zyga: mounted a shell script over /sbin/modprobe (which is hardcoded path in the kernel), triggered PF_CAN socket
<mborzecki> zyga: check the pastebin i linked
<zyga> mmm, I see e
<zyga> I'll double check
<zyga> feels like something that's worth knowing :)
<mborzecki> zyga: yeah, i'd like to poinpoint the exact place where we know which ns is that
<zyga> yeah
<zyga> there's some work queue
<zyga> anyway, I'll check after lunch :)
<mborzecki> zyga: this is where it ends up: https://elixir.bootlin.com/linux/latest/source/kernel/umh.c#L67
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7041 ? the actual code is quite short, the diff is inflated by tests
<pstolowski> ok
<mborzecki> pstolowski: thanks!
<zyga> mborzecki: looking
<zyga> following the rabbit  hole
<mvo> mborzecki: could you please remind me where the gadget.yaml spec is recorded?
<mborzecki> mvo: recorded as in documented?
<mvo> mborzecki: yes
<zyga> mborzecki: still falling
<mvo> mborzecki: the authoritative place what the valid fields are etc
<mborzecki> mvo: https://docs.snapcraft.io/gadget-snap that's the only place i know of
<mvo> mborzecki: thank you
<zyga> mborzecki: maybe this is the key? https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L2183
<mborzecki> zyga: try going through the whole path from do_execve, nameidata should be initialized at some point there
<Chipaca> pedronis: meeting?
<mborzecki> zyga: https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L513 set_nameidata() is called in do_filp_open(), along the path from do_execve()
<mborzecki> zyga: maybe we could trace that :)
<ackk> jdstrand, hi, is there a snapd release already which contains fixes for #1831473 and #1831457 ?
<ackk> mvo, hi is the fix for https://bugs.launchpad.net/snapd/+bug/1819318 in snapd itself or core18? I have snapd 2.39.2+18.04 here but still see the issue
<mvo> ackk: if you have an updated deb this should work, if you could provide a quick reproducer I will look into it
<mvo> ackk: (reproducer in the sense, what snap did you install on a fresh 18.04 system with updated snapd deb?)
<ijohnson> hey zyga I have a wording suggestion on https://github.com/snapcore/snapd/pull/7053 I want to suggest, how do you do a "github suggestion" where you can commit the change directly?
<ackk> mvo, ah, I haven't updated the deb, saw that mileston was 2.39 and thought that 2.39.2 would have it
<ackk> mvo, I have 2.39.2+18.04 deb
<ackk> (from bionic)
<mvo> ackk: that sounds right - what snap do you install?
<ackk> mvo, just core18
<ackk> mvo, but I also tried htop, as per the bug
<mvo> ackk: let me look
<mvo> ackk: thanks for the report!
<ackk> I'll try adding -proposed
<ackk> mvo, ty for looking into it
<ackk> mhm, no snapd update in proposed
<ackk> mvo, fwiw I tried core18 --edge too
<mvo> ackk: hm, so here is what I did: booted a fresh ubuntu 18.04 vm, apt install snapd which installed 2.39.2. sudo snap install htop. this installed htop,core18,snapd snaps. snap interfaces then shows me the system interfaces. what am I missing (if anything)?
<ackk> I don't have the snapd snap
<mvo> cmatsuoka: just FYI, I'm working on making the spike use the core20/edge snap, some issues with that though
<ackk> did you install it explicitly?
<ogra> note that i did my initial test on a UC18 system ... if you use a VM anyway thats probably easier and faster
<mvo> ackk: it got pulled in automatically (this is the fix in 2.39). if this did not work for you, could you please pastebin "snap list" and "snap changes" for me?
<mvo> ackk: oh, are you on a UC18 system?
<ackk> mvo, no, it's a bionic lxc container
<ackk> mvo, lemme start fresh
<ogra> (but later others reported the same issue for classic systems with only core18 installed)
<mvo> ackk: please pastebin the bits
<mvo> ackk: maybe there are some clues there
<ackk> mvo, https://paste.ubuntu.com/p/Vshs7827wh/
<mvo> ackk: maybe our starting points where different and the fix is incomplete in some way
<ackk> mvo, ah so I think I installed core18 *before* upgrading to the fixed version of snapd
<mvo> ackk: cool, let me try this
<ackk> mvo, mhm, same
<mvo> ackk: please pastebin also "snap interfaces" just so that I can get the full picture
<ackk> mvo, it's empty
<ackk> mvo, so this: is with a brand new container, after running apt update && apt install snapd: https://paste.ubuntu.com/p/WKYJkkcxym/
<mvo> ackk: thanks!
<ackk> mvo, ty
<ackk> mvo, (from an ubuntu-daily:u lxc image)
<mvo> ackk: I can reproduce that with core18 no snapd snap gets pulled in so "snap interfaces" is empty. however "snap install htop" pulls in snapd and after that snap interfaces looks sane
<ackk> err ubuntu-daily:b
<mvo> ackk: I need to look why core18 alone does not pull in snapd
<ackk> mvo, confirmed, installing htop pulls in snapd for me as well. in the first run I had htop installed before upgrading snapd
<mvo> ackk: aha, yes - I think that makes sense, it will not work this way around
<ackk> mvo, would it install it on a refresh?
<mvo> ackk: yes
<ackk> cool
<mvo> ackk: let me double check but pretty sure it will
<mvo> cmatsuoka: iirc you had a missing bind mount in build-image.sh during the sprint, how did you fix that? I think I have the same right now :/
<ackk> mvo, thanks for looking into it
<mvo> ackk: will take some second, needs to find a buggy snapd first
<ackk> np
<mvo> ackk: just double checked, a refresh of htop pulls in snapd as expected
<mvo> (one the snapd deb is updated of course)
<ackk> mvo, awesome, so "2.39.2+18.04" is the version  with the fix. right?
<mvo> ackk: correct
<ackk> mvo thanks!
<mvo> pedronis: any suggestions for a common branch name for the spike/uc20 in the various git repos we have? I was thinking simply "20" or do you think it should be spike20 or something more like this?
<pedronis> mvo: the problem with 20 is that we might need those for the real code at some point, no?
<zyga> ijohnson: hey
<zyga> ijohnson: either is fine, suggestions are  usually easier while you review
<zyga> ijohnson: if  you want to push directly, by all means do
<ijohnson> hey, yeah I tried to figure out how to use suggestions on your PR but couldn't find it in the github ui :-/
<mvo> pedronis: yes, that may be a problem, so spike20? I guess we can discuss in the call tomorrow
<mvo> cmatsuoka: I have some PRs for you :) this switches our spike to the "real" core20 snap
<ijohnson> zyga: also I've been reading through all the mount setup that happens with strict confinement for snap-confine, and some of the comments are out-dated or confusing so I will file a PR to fix some of those comments as best I can
<zyga> excellent
<ijohnson> zyga: I've also been collecting notes on the mount setup so we at the least you and others can correct my misunderstandings, and possibly also make an updated documentation post on the mount setup for snaps
<ijohnson> err that was poorly worded
<ijohnson> <ijohnson> zyga: I've also been collecting notes on the mount setup so at the least you and others can correct my misunderstandings, and possibly also make an updated documentation post on the mount setup for snaps
<cmatsuoka> mvo: ack, let's do it!
<mvo> cmatsuoka: please double check but for me this change was sufficient
 * cachio afk
<mvo> cmatsuoka: silly question - do we still need initramfs/scripts/local-premount/install now that we have the recovery.go and the ability to do this from the writable ramdisk?
<zyga> ijohnson: when do  you think we should document stuff
<zyga> ijohnson: perhaps on the forum?
<zyga> ijohnson: perhaps in the code (I mean, in addition to current micro comments)
<mvo> cmatsuoka: nevermind, I'm silly and reading it wrong
<ijohnson> zyga: yeah that's what I was going to do is post on the forum a cleaned up version of my notes, then after review of that either clean up the same post or make a more concise version on the forum to serve as a wiki
<ijohnson> zyga: but note my PR with comment cleanup will be separate from that
<ijohnson> so hopefully the code comments will continue to be all up to date, and then we will have another place (forum) with updated info
<cmatsuoka> mvo: ah I was re-reading the scripts here to see if we were able to create the writable tmpfs from somewhere else
<cmatsuoka> mvo: I'll test the whole thing with core20 now
<zyga> ijohnson: ok
<zyga> ijohnson: you can perhaps look at the 2.26 walkthrough and fix that
<zyga> ijohnson: I can make it  a wiki
<ijohnson> did you mean 2.36 here? https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843
<zyga> yes
<ijohnson> I would be fine just updated that as well instead
<mvo> cmatsuoka: I'm just silly, I pushed a tiny pr to help silly people like me
<ijohnson> zyga: I've been trying to just focus on the code to understand it myself first in case things have changed or are slightly inaccurate, etc.
<zyga> ijohnson: though I don't mind a new thread if that helps you organize it
<mvo> cmatsuoka: thanks! I think with that in place we can now attack the items in the trello board for uc20
<zyga> ijohnson: I'm happy that you do, +1
<ijohnson> cool, I'm hoping to have that by my EOD, so probably your morning tomorrow it will be ready
<mvo> cmatsuoka: I have dinner now, keep me updated please what you are up to :)
<cmatsuoka> mvo: ah haha, the names are really confusing
<cmatsuoka> mvo: ok!
<mvo> ijohnson: thanks for jumping into this :)
<ijohnson> :)
<zyga> ijohnson: I started 2nd batch of work now, I'll be around for some time stll
<mvo> cmatsuoka: I think it just shows I need more tea but well :)
<ijohnson> zyga: ack, I'll ping you here if I have any questions
<zyga> ijohnson: my pleasure, happy to have you on board  :)
<cmatsuoka> mvo: a fresh install using core20 is working well
 * zyga  walk
<mvo> cmatsuoka: nice, thank you!
<cmatsuoka> mvo: now testing luks device creation
<zyga> ijohnson: hey, almost over (my walk)
<zyga> Do you have something I can look at
<zyga> Or shall we try after eod
<ijohnson> zyga: hey sorry I'm at lunch, might be a while before I'm back
<ijohnson> zyga: how much longer will you be around?
<mvo> cmatsuoka: cool
<zyga> ijohnson: probably an hour
<ijohnson> k I'll ping you if you're around if not you can take a look when you get time tomorrow
<zyga> sure!
#snappy 2019-07-03
<mborzecki> morning
<mborzecki> super trivial PR https://github.com/snapcore/snapd/pull/7057
<zyga> good morning
<mborzecki> zyga: hey
<mborzecki> zyga: super simple PR to start your day ^^
<zyga> already +1
<mborzecki> zyga: thanks!
<zyga> mborzecki: I merged the master version of https://github.com/snapcore/snapd/pull/7056 a second ago
<mborzecki> zyga: yay ;)
<zyga> should I just merge the 2.40 backport?
<mborzecki> zyga: did mvo look at it yet?
<zyga> at the original yes +1
<zyga> the backport is the same for 2.40 branch
<zyga> nobody looked at the backport
<zyga> but it's just cherry-pick of a range
<mborzecki> zyga: looks like nothing was missed there
<mborzecki_> mvo: hey
<zyga> mvo: hey, 2.40 backport of base migration is merged
<zyga> mvo: as is the master version
<zyga> brb
<mvo> hey mborzecki  and zyga
<mvo> zyga: excellent
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<zyga> re
<mvo> zyga: re 7053> I updated the description, feel free to update as you want, just wanted to do a draft to give an idea what I had in mind with my comment
<zyga> mvo: sure, I'll look shortly, just making a commit message
<mvo> zyga: no rush
<zyga> mvo: this is what we discussed on Monday https://github.com/snapcore/snapd/pull/7058
<zyga> mvo: not sure if you want it in 2.40 - but at least now it is up and we can discuss it
<pedronis> sounds it needs a jdstrand review anyway
<pedronis> also I heard the motivation but not the details of what it entails
<zyga> pedronis: this is based on the discussions in lyon and montreal, jamie was +1 on this
<zyga> pedronis: how should I proceed on that?
<pedronis> may recollection of lyon wasn't so clear that jamie was +1
<pedronis> my
<pedronis> we need a meeting with him next to go over the consequences of this again
<pedronis> *next week
<zyga> pedronis: we discussed this more in montreal
<zyga> ah, right, he's off this week
<pedronis> I was not there
<pedronis> so, I fear, you'll have to bear with me
<zyga> sure no worries :)
<mvo> I can setup a meeting, early next week?
<pedronis> yes
<mvo> gustavo as well?
<pedronis> mvo: not in the first meeting, he was mostly +1 in lyon
<mvo> cool
<mvo> zyga, pedronis meeting setup
<zyga> thank you!
<mvo> (and now even added conferencing - oh I wish there was a way to make this default)
<diddledan> that one caught me out in Montreal - I'm using a mainline kernel for Microsoft Surface out of tree patches
<diddledan> I've filed a PR on the linux-surface repo to hopefully add the required bits for their kernel to support snaps out of the box on Ubuntu
<diddledan> I think the bit missing was the apparmor patch for "legacy network" stuff (apparmor uses the feature flag "network" as opposed to their new "network_v8")
<zyga> diddledan: thanks, that's interesting
<diddledan> specifically apparmor in mainline exposes network_v8 not network. the patch re-adds network so Apparmor exposes both feature flags
<diddledan> this is the patch that Apparmor carries out of tree: https://gitlab.com/apparmor/apparmor/commit/aa42e338600ab6b5a1368dc5c4920974192adfd1
<zyga> diddledan: I'll discuss this with jdstrand when he is back
<diddledan> cool
<diddledan> https://forum.snapcraft.io/t/proposal-to-change-the-channels-display-of-snap-info/12134
<Chipaca> no wonder you all were quiet :-)
<mvo> Chipaca: how do you mean?
<Chipaca> mvo: irc client had quietly disconnected
<Chipaca> or quietly never connected?
<mvo> Chipaca: haha - now it makes sense :)
<diddledan> "accident" my foot!
<Chipaca> diddledan: I'll have you know I have no IRC clients in my foot.
<Chipaca> diddledan: I'll have you know I have no *IRC* clients in my foot.
<Chipaca> diddledan: I'll have you know I have no IRC *clients* in my foot.
<Chipaca> diddledan: I'll have you know I have no IRC clients *in* my foot.
<Chipaca> diddledan: I'll have you know I have no IRC clients in *my* foot.
<Chipaca> diddledan: I'll have you know I have no IRC clients in my *foot*.
 * Chipaca stops before doing combinations
<diddledan> you have other clients in your foot?
<Chipaca> I can't comment
 * zyga is sleepy
<Chipaca> zyga: amen
<Chipaca> my watch reckons i got 5h of sleep
<Chipaca> i think it's about right
<pedronis> you merged some things fairly late, I saw
<Chipaca> and then rebased the followup
<Chipaca> which was fun
<Chipaca> and then did the bi-weekly supermarket shop while waiting for spread
<Chipaca> amazon linux is sad :-(
<Chipaca> # github.com/snapcore/snapd/cmd/snap
<Chipaca> src/github.com/snapcore/snapd/cmd/snap/cmd_info.go:93:13: undefined: strings.Builder
<Chipaca> error: Bad exit status from /var/tmp/rpm-tmp.wKuf9u (%build)
<Chipaca> hmmmmm
<zyga> Chipaca: too old go
<zyga> cannot use strings.Builder yet
 * zyga takes a 15  minute break
<Chipaca> why aren't the unit tests catching this :-(
<Chipaca> â¦ because they're run on 1.10
<Chipaca> why are we running the unit tests on 1.10?
<mvo> I thought all our downstreams now are on go-1.10 is this not the case? if so we need to go back to 1.9 there :/
<Chipaca> I thought so as well
<zyga> Chipaca: which os was this on?
<zyga> amazon?
<zyga> zOMGon
<Chipaca> https://api.travis-ci.org/v3/job/553521524/log.txt
<Chipaca> it's on 1.9.4 apparently
<pedronis> we run on 1.10 because fmt changed I think
<pedronis> mborzecki might remember the exact reason
<mborzecki> hm hm?
<Chipaca> BuildRequires:  %{?go_compiler:compiler(go-compiler)}%{!?go_compiler:golang >= 1.9}
<Chipaca> we're just asking for 1.9 in amazon
<Chipaca> wait that's fedora spec
<Chipaca> :-|
<pedronis> we can run the static tests on 1.10
<pedronis> and the unit on 1.9 ?
<Chipaca> mborzecki: it seems #6799 was premature
<zyga> ancient linux
<mborzecki> hm let me check something
<Chipaca> pedronis: mborzecki: I'll push a pr to bump it down to 1.9 unless mborzecki finds something interesting :-)
<pedronis> Chipaca: I remember we had a reason
<pedronis> but I don't think it applied to all tests
<mborzecki> pedronis: yeah, there's a pr from jdstrand mentioning 1.10
<Chipaca> but it's ok
<Chipaca> it uses something that's there from 1.7
<Chipaca> user.LookupGroup
<pedronis> anyway my vague recollection is that go fmt output changed at some point
<Chipaca> i can easily split static and unit tests
<mborzecki> pedronis: gofmt too, though it's 1.11 i belive that broke it
<mborzecki> heh so centos gets a newer golang than amazon linux 2 now?
<mborzecki> centos 7 via epel - 1.11, amzn2 via amazon core repo 1.9 :/
<mborzecki> Chipaca: so, switching back to 1.9?
<Chipaca> ye
<zyga> mborzecki: https://bugzilla.redhat.com/show_bug.cgi?id=1726382 do you understand what this is about?
<mborzecki> zyga: doesn't make any sense
<pstolowski> preliminary results of optimization of connects wrt setup-profiles, with lxd snap that connects 4 interface: old snapd - https://paste.ubuntu.com/p/5ZVNkBxVqQ/ ; new snapd - https://paste.ubuntu.com/p/F69TGbWWtg/ ; almost 3x faster (sum of connect+final setup profiles timings)
<diddledan> \o/
<Chipaca> pstolowski: try something beefier, like vlc
<mborzecki> zyga: i'll check what's going on there
<Chipaca> pstolowski: just to show off :-)
<pstolowski> :D
<pstolowski> good idea
<mvo> pstolowski: woah, thats sooo nice
<pstolowski> yeah, install of lxd snap feels much faster now
<pstolowski> and this is what we had in the past before, cough cough, interface hooks
<mvo> heh
<pedronis> pstolowski: are you moving setting up profiles to one call to setup-profiles after the connects ?
<pstolowski> pedronis: yes, final setup-profiles after connects (but before connect-plug|slot hooks). existing setup-profiles after link-snap remains untouched.
<Chipaca> pedronis: have you seen https://forum.snapcraft.io/t/bug-1809708-allow-snaps-to-query-interface-connection-status-directly-from-snapd/9147?u=chipaca ?
<pedronis> pstolowski: ok, it's important to know because the plan was to drop setup-profiles
<pedronis> when is merged with link-snap
<pedronis> we need that anyway
<pstolowski> pedronis: hmm wrt what Chipaca was about to do?
<pedronis> but it's orthogonal issue
<pedronis> but we need to know if we need to merge the logic into the other as well
<pedronis> but keep it around otherwise
<pedronis> pstolowski: yes, Chipaca's work
<pstolowski> right
<pedronis> Chipaca: we have had similar requests already, I think it's in our backlog but not scheduled, needs also a final design
<pstolowski> vlc installation: 4300ms vs 1600ms (connects+setup profiles only)
<pstolowski> that's on a vm
<mborzecki> zyga: added needinfo from the reporter, things seem to work fine on my end
<zyga> thanks
<zyga> mvo: I created https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7060 is failing unit tests due to build ID
<mborzecki> Chipaca: so the details are coming back a bit, iirc 1.10+ adds Go BuildID by default
<mborzecki> earlier versions would only get it iff built with external linker that was configured to add it (didn't we have question about that regarding gentoo in the forums?)
 * zyga spawns a pair of spread runs and goes to make coffee
<zyga> mborzecki: another fedora fun https://bugzilla.redhat.com/show_bug.cgi?id=1675023
<mborzecki> zyga: golang-github-gosexy-gettext? haha
<mborzecki> zyga: i'd like to see people behind corporate filters trying to access github page of that package
<zyga> yeah
<zyga> https://www.tomshardware.com/news/india-shakti-cpu-processors-sdk-risc-v,39781.html <- maybe more risc v boards soon?
<Chipaca> mborzecki: an easy & lazy fix would be to tag the build id checking tests as not-short
<mvo> zyga: we don't use gosexy-gettext anymore, do we?
<zyga> mvo: but I am the package maintainer
<zyga> need to do something about it
<mvo> zyga: oh, ok
<diddledan> RISC-V is intriguing. I'm curious how soon we'll see someone try to make a workstation with one
<diddledan> I kinda think though that x86(64) is too entrenched for consumer migration in any meaningful numbers
<diddledan> in terms of IoT though I can see it breaking through
<mborzecki> Chipaca: i think the problem is actually osutil dropping the need for import C more than go version switch, that's just a side effect
<Chipaca> diddledan: what is the talos workstation
<diddledan> that's powerpc IIRC
<diddledan> power9?
<Chipaca> ah, yes
<Chipaca> sorry
<Chipaca> power8
<diddledan> it's suffering an off-by-one ;-p
<Chipaca> same
<Chipaca> hmm, i'm going to go lie down for a bit
 * Chipaca not improving with time
 * zyga has coffee now
<zyga> mvo: let me know when you have a chance to look at https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139
<pedronis> zyga: I'll have to look at it too
<zyga> thank you
<zyga> pedronis: any more ideas are welcome, this captures what we discussed during the call on monday
<pedronis> interesting
<zyga> perhaps there is an easier way to fix it that we did not think about
<pstolowski> mvo, pedronis: long overdue - https://forum.snapcraft.io/t/snap-debug-timings/12141
<zyga> I made some small typos/formatting changes
<zyga> mainly commas
<pstolowski> will ask Graham for proof-reading as well when he is back
<pstolowski> zyga: thanks, re-reading myself again
<pstolowski>  56455ms            -  Save data of snap "lxd" in automatic snapshot set #1
<pstolowski> yuk
<mvo> zyga: yes, I have a look once I am finished with my current uc20 part
<mborzecki> https://forum.snapcraft.io/t/segmentation-fault-running-snapcraft-on-arch-linux/12142/2 hm python3 segfaulting on arch
<zyga> mvo: super, thank yuo
<zyga> *you
 * pstolowski lunch
<pedronis> Chipaca: there is something strange in the diff of 6878, it seems to be adding back (again)  maybePrintType etc ?
<pedronis> some merge artifact?
<Chipaca> pedronis: merge artifact indeed
<Chipaca> pedronis: I'll clean it up, and address your other points
<Chipaca> pedronis: indeed at some point i forgot we meant health to be multi-line in info
<pedronis> Chipaca: I don't have a strong opinion about not-verbose, but for verbose it should be
<Chipaca> for some reason i thought git would do a proper job of merging things given I started from the thing that then caused conflicts everywhere
<mvo> cmatsuoka: I hope I will have the updated recovery dir layout ready by the standup, mostly fyi, fighting with the last small issues
<ogra> Chipaca, just switch to bzr
<cmatsuoka> mvo: great, I'm running some tests to check the stability issues with the updated core20 snap
<mvo> cmatsuoka: thank you
<mvo> cmatsuoka: is it updated already? iirc I just proposed a pr. anyway we can talk after my lunch :)
<cmatsuoka> mvo: not updated, I'm building it locally
<Chipaca> ogra: alias git='bzr --rotated-90-degrees --extra-complicated --zippy'
<ogra> haha
<ogra> (so true)
<mborzecki> is glibc locale archive a memory dump of structures?
<cmatsuoka> mvo: but my build just failed, this snap seems to be a bit tricky to build
 * zyga goes for lunch
<Chipaca> pedronis: wrt health's position in the struct, it seemed like the sensible place to put it, looking at the types of the things
<pedronis> Chipaca: I shall look at the full struct then
<Chipaca> pedronis: txs
<ijohnson> hey mvo, could you add me to the SU meeting invite? I don't have it on my calendar yet
<zyga> I'm online but having lunch with family at the seaside
<zyga> and sending updates to spread.zygoon.pl
<zyga> over that uncapped LTE
<ijohnson> morning zyga
<zyga> hey ijohnson :)
<zyga> ijohnson: I'm semi afk but I can read updates once in a while
<mvo> ijohnson: sure, done
<zyga> mvo: and perhaps the github team, if not done already
<ijohnson> zyga: ok, np. did you see my post at https://forum.snapcraft.io/t/mount-namespace-walkthrough-wip/12127 ? it's still a wip but I've gotten most of the way through snap-confine at least
<zyga> ijohnson: I did not, queued
<mvo> zyga: I think I did that, hope added to all the right places :)
<ijohnson> the only thing I'm still missing I think is spread access
<zyga> looks good
<zyga> I will read the details and comment
<ijohnson> great, thanks
<ijohnson> mvo: got it thanks!
<zyga> ijohnson: I'm trying to build a new flow, with snap-boostrap-ns, reusing snap-update-ns, where C does less stuff and snap-update-ns has only one entry point that is stricter than now (from snapd)
<mvo> yay
<ijohnson> zyga: I need to dig in a bit more, but the whole preinit_array thing with cgo I've seen done in pure go with a docker package called re-exec
<ijohnson> (for bootstrap.c in snap-update-ns)
<zyga> ijohnson: one motivation is to remove C from snap-update-ns as well
<zyga> ijohnson: anyway, that's for later, I'm just sharing thoughts
<zyga> ijohnson: the goal is to streamline snap-update-ns and remove C as much as we can
<zyga> ijohnson: the new binaries would be easier to understand than the multi-purpose one we currently have
 * zyga focuses on the food now
<ogra> ogra@pi4:~ $ grep ^NAME /etc/os-release
<ogra> NAME="Raspbian GNU/Linux"
<ogra> ogra@pi4:~ $ snapcraft --version
<ogra> snapcraft, version 3.6
<ogra> :D
<ogra> oh ... something is broken !
<ogra> ogra@pi4:~ $ sudo snap install lxd
<ogra> [sudo] Passwort fÃ¼r ogra:
<ogra> Warning: /snap/bin was not found in your $PATH. If you've not restarted your session since you
<ogra> ...
<ogra> ogra@pi4:~ $ echo $PATH
<ogra> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/snap/bin
<ogra> ...
<ogra> thast definitely a flashe positive
<ogra> *false
<zyga> ogra: nice
<zyga> ogra: sudo
<zyga> ogra: sudo changes PATH
<ogra> is debian different here ?
<ogra> i have never seen that on ubuntu
<ogra> ogra@pi4:~ $ sudo echo $PATH
<ogra> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/snap/bin
<zyga> yes
<zyga> sudo -s
<zyga> echo $PATH
<zyga> otherwise PATH is expanded by the non-root shell
<ogra> ah, right
<ogra> yeah
<ogra> now i wish i had a u-boot tree :( i want core !
<zyga> how does it boot?
<ogra> rpi firmware boots a kernel.img directly
<ogra> (and nop initrd at all as far as i can see)
<ogra> *no
<ogra> (like all other pi's essentially ... )
<zyga> ogra: that's interesting
<ogra> whats interesting about it ? it is the same bootprocess they use since day one
<ogra> and as usual we have to wait for a u-boot port before we can move on with core
<ogra> i'm sure something will show up within the next weeks
<zyga> ogra: but you can have an initrd, right?
<ogra> you can hack one into config.txt yeah
<ogra> there is an option for defining one
<zyga> and that firmware is still closed-source, right?
<ogra> yup ... it the graphics driver
<ogra> *it's
<ogra> the pi boots by first firing up the GPU ... the GPU then turns on the arm SoC
<ogra> thats why you for example dont really need an extra graphics driver at all ... just some userspace libs
<ogra> they interface dircetly with the GPU driver/bootloader blob
<ogra> *directly
<ogra> ogra@pi4:~ $ free -m|grep ^Mem
<ogra> Mem:           3906         105        3299           8         500        3668
<mborzecki_> ogra: sudo -i should work too
<ogra> i like that one :)
<ogra> mborzecki_, yeah, i was just not aware that debians sudo is different to ours ... i'm used to sudo not making a mess out of my env :)
<mborzecki> ogra: fedora's sudo does the same
<ogra> yep ... i bet suse's too
<ogra> (or upstream FWIW ... but if you are used to userfriendlyness it is confusing :) )
<mborzecki> Chipaca: maybe we could just skip a test in osutil for go < 1.10 and mock buildid in api and system-key tests?
<mborzecki> Chipaca: unless there's a way to pass build flags to go test via //go:<somethingsomething>, though I'm no aware of anything like that
<Chipaca> mborzecki: go test -tags=yadda  and then //+build yadda
<mborzecki> Chipaca: right, we'd need to update run-checks for that hmm
<mborzecki> Chipaca: move the test to separate file with //+build go1.10 so that we don't need to guess the format of runtime.Version()? :)
<Chipaca> mborzecki: I closed the PR, instead. That also worked.
 * Chipaca takes practicality to a new level
<mborzecki> Chipaca: haha ;) ok, i can look into that
<Chipaca> mborzecki: oh, i can too
<Chipaca> but it needed more work and i didn't have the bandwidth to look so i closed it before wasting people's time
<Chipaca> mborzecki: how full is your plate?
<mborzecki> Chipaca: gadget updates & random ramblings, but I can look into working around that 1.9 quirk
<mborzecki> pulseaudio -k a day keeps the insanity at bay
<ogra> geez ... this snapshot default feature is very annoying
<mborzecki> maybe we should ask the user the first time?
<ogra> either that or make it opt in
<ogra> snap remove --keep-data ... or whatnot
<pedronis> it really depends on the size of the data, but yes the current UX is not great in some cases
<Chipaca> ^C should still stop the removal and let you try again with --purge
<ogra> i just installed snapcraft on this pi4 raspbian install ... forgot about the fact that this now needs multipass ... so the forst snapcraft run downloads multipass ... this then fails after creating a VM image for 10-20min ...
<ogra> i then uninstall multipass (and snapcraft since it is uselass in that setup) ... and snapd keeps the rotten multipass VM image around
<pedronis> Chipaca: does it work atm?
<pedronis> I mean ^C
<ogra> i could ^C out of it and it complained with an error
<ogra> ogra@pi4:~/linux-generic-allwinner $ sudo snap remove multipass
<ogra> Save data of snap "multipass" in automatic snapshot set #1                                                    |error: cannot perform the following tasks:
<ogra> - Save data of snap "multipass" in automatic snapshot set #1 (tar failed: context canceled)
<ogra> ogra@pi4:~/linux-generic-allwinner $
<ogra> thats what i got with ^C ...
<ogra> still, the experience is quite a mess
<ogra> and indeed multipass is still around ...
<ogra> snap help doesnt really talk about how to not have a snapshot taken on remove ... it only tells about how to manage snapshots
<ogra> (i guess the info i'd be looking for is in the details of snap remove's help)
<Chipaca> pedronis: it should
<Chipaca> and yes abort is never pretty to see
<mborzecki> mvo: got a lead on python3 segfaulting on arch
<ogra> hrm ...
<ogra> and snap remove help doesnt mention --purge at all
<Chipaca> ogra: then you don't have a new enough snapd
<Chipaca> ogra: disable it globally, instead
<Chipaca> ogra: https://docs.snapcraft.io/system-options#heading--snapshots-automatic-retention
<mborzecki> mvo: when i drop mymachines from /etc/nsswitch.conf it does not segfault anymore
<zyga> mborzecki: time to top sharing /etc/
<zyga> and provide crafted view
<zyga> but then classic snaps are ... complex to say the least
<ogra> Chipaca, i'm finding my way around (and wont keep that raspbian anyway) ... but i'm trying to take this experimant like a snap-illiterate user ... and now i'm already sitting here with a mess :P
<ogra> btw ... i have 2.39.3 according to snap version
<ogra> $ sudo snap remove --purge multipass
<ogra> error: unknown flag `purge'
<ogra> $ snap version|grep snapd
<ogra> snapd     2.39.3
<ogra> should that not have --purge already ?
<Chipaca> that's an mvo question, i always get lost
<ogra> heh
<Chipaca> my snapd here has purge, but it also has set-health and 'snap info' shows health information
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> zyga: mvo: left a note https://forum.snapcraft.io/t/segmentation-fault-running-snapcraft-on-arch-linux/12142/6
<zyga> mmm
<mvo> mborzecki: thank you
<ogra> stgraber, https://paste.ubuntu.com/p/XGmFsskzHK/ ... lxd on raspbian ... do you think we could quieten the errors ? they look scary
<ogra> (it seems to run find otherwise ... but if the errors ate "ignored" we could as well not show them at all)
<ogra> *fine
<stgraber> those messages come from the linker, not much we can do about it
<ogra> hmm, k
<stgraber> also we're not seeing those on other arm platforms, so that suggests there's something odd with raspbian
<ogra> thats buster fwiw ... perhaps too new ?
<ijohnson> ogra, stgraber: I see the same linker messages on stretch raspbian for a long time (since at least last year) so I don't think it's buster specific
<ogra> ah ... its my first direct debian contact in years
<ogra> (well, not true, i used armbian for 1h or so a while ago ... but not significant enough to notice issues)
<pedronis> cachio: so I tried again, I'm not getting it to fail where I would expect, I'm getting this, notice the PAM errors
<pedronis> cachio: https://paste.ubuntu.com/p/FX25MJhHWz/
<pedronis> cachio: I can push my test changes to the PR if it helps, or somewhere else
<pedronis> Chipaca: I looked at the struct
<Chipaca> pedronis: wdyt?
<Chipaca> pedronis: ah ok
<Chipaca> pedronis: and type?
<Chipaca> asked there
<Chipaca> going afk now for a bit
<zyga> ijohnson: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/2
<pedronis> Chipaca: type can stay first field
<pedronis> answered also in the PR
<pedronis> cachio: I pushed my debugging tweaks (on top of my PR) here: https://github.com/pedronis/snappy/commit/9ef3d3b6cd8cd775110472346e5a00e9ecb729da
<mvo> pedronis: (for later) - I played a bit in image.go, I wonder if something along the lines of http://paste.ubuntu.com/p/TFtXTX9FPz/ makes sense?
<mvo>  http://paste.ubuntu.com/p/TFtXTX9FP
<mvo> pedronis: no rush, I have dinner now and we can talk later/tomorrow
<cachio> pedronis, nice, taking a look now
<cachio> pedronis, the tweaks seem to be well
<cachio> are you creating a PR with those?
<pedronis> cachio: they might be good, but if I try your repeat it doesn't die on the exit 1
<pedronis> but at other places
<pedronis> which confuses me
<cachio> pedronis, it is branking on snap pack?
<pedronis> mvo: what about seed.yaml in that code?
<pedronis> it doesn't exist in the new world
<pedronis> cachio: it seems to be breaking at random points, sometimes
<pedronis> but maybe is just spread not getting the full log back
<pedronis> but I would expect to not break before the install
<pedronis> but it seems to
<cachio> pedronis, ok, I am testing the this
<cachio> also there is a spread issue on reboots which I already fixed and I am using to check the failover test
<cachio> are you merging that change in failover test with the #7020?
<mvo> pedronis: yeah, its a first step, I did not touch seed.yaml just yet. its mostly about how to make this less messy, i.e. having a central place that defines where the snaps/assertions/... go into without springling if/else
<mvo> pedronis: definitely more work here :) will poke more tomorrow
<pedronis> mvo: are you planning to merge this to master? or is just spike stuff'
<pedronis> ?
<pedronis> cachio: I can merge if it helps or can open another PR, given that is not failing usefully, I'm not sure
<mvo> pedronis: I was hoping to work on something that is master material
<pedronis> mvo: that's ok, my feeling is that we have reached a point where master material should try to fix the FIXME
<pedronis> there
<pedronis> also I fear because of seed.yaml etc, that this too low granularity as the final solution for master
<pedronis> also we don't have yet the new model syntax
<mvo> pedronis: yeah
<mvo> pedronis: its a first step only but I think its the right direction (or something like it)
<mvo> pedronis: the seed.yaml will come next, some of seed.yaml will just go away, some will the options.yaml but we can cross that bridge when we reach it
<mvo> pedronis: I can work further and remove the "dirs.SetRootDir" in bootloader config writing, I think that will be straightfoward. anyway, happy to talk more friday, I don't want to burden you in the evening with this stuff :)
<mvo> (as its not really urgent)
<pedronis> mvo: it's fine, I just feel it might be slightly premature
<pedronis> still
<zyga> re
<pedronis> mvo: my worry is to write something targeting master, think to land it in 2 days and it takes 1week+
<pedronis> mvo: there's a lot of logic about unasserted/local snaps as well
<pedronis> there
<mvo> pedronis: right, happy to ignore it for now
<pedronis> mvo: unclear why to target master though
<pedronis> then
<pedronis> sorry, I'm probably misunderstanding something here
<mvo> pedronis: well, I was mostly thinking that we need to refactor this code anyway so I was thinking of doing it now because I was already working in this area for uc20 (so have some context in my head). its a bit fugly right now because of history messiness and now it got more if/else. I was hoping that with some small refactoring it would get a bit better. but if you feel its premature thats fine, I can ignore for now
<pedronis> mvo: let me put this way, I'm not conviced yet that targetDirs is the right level of abstractions for what we need in the end
<pedronis> it seems we have lots of details that are not just which dirs to use
<pedronis> can we refactor 2 or 3 times, yes
<pedronis> just not sure it's wise to setup to have to do that
<mvo> ok
<pedronis> mvo: sorry, I'm not trying to be negative, but so far we discussed not to try to hit master, and now we are considering it, and I have to raise my concerns
<mvo> pedronis: its okay, no worries. fine to learn more first and then try to find the right level of abstraction. its true that there will be more changes needed regarding seed.yaml/options.yaml and the new model assertion so thats fine
<cachio> pedronis, after 1 hour ef tests with your fix the error is not reproduced anymore
<cachio> pedronis, that's relly promosing
<pedronis> mvo: for example, I'm not sure the current assertion writing code is using case-insentive names
<pedronis> for the files
<pedronis> cachio: you mean my PR + the test change ?
<mvo> pedronis: indeed, the coming abstraction will need to take this into account for uc20 it will write a stream in a reasonable filename for example. so yes, it seems to be fine to postpone until this is ready too
<cachio> pedronis, sorry, didn't see your comment, yes that PR
<cachio> pedronis, or the idea is to have 2 different PRs?
#snappy 2019-07-04
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> zyga: have you seen https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c3 ? my best bet is that he's running oracle linux :)
<mborzecki> zyga: btw. this one can probably be closed https://bugzilla.redhat.com/show_bug.cgi?id=1706020 but I have no clue whether we need to do anything special to have the whole BZ/notification machinery do its thing (Pharaoh_Atem maybe?)
<zyga> Checking
<zyga> ha
<zyga> that's some automaton catching up with CVEs
<zyga> but that's all fixed for a while now
<zyga> https://bugzilla.redhat.com/show_bug.cgi?id=1706013 is closed already so probably nothing more needed
<zyga> but I don't know for sure
<zyga> mborzecki: I made spread.zygoon.pl refresh yesterday
<zyga> mborzecki: no longer backed by my server, this time backed by CDN
<zyga> mborzecki: I tried to make debian images by my cloud init foo was insufficient and I only recalled jdstrand's post late in the evening
<mborzecki> zyga: nice
<zyga> mborzecki: I learned that qemu can use qcow images that are not real images but instead contain an embedded https reference
<zyga> mborzecki: perhaps spread could keep "embeded" images that point to spread.zygoon.pl :)
<zyga> mborzecki: I don't know the caching story though, would depend on being usable this way
<mborzecki> zyga: qcow can reference http? interesting
<zyga> yeah
<zyga> stuff we learn
<zyga> probably full of CVEs pending ;D
<zyga> ok, quick pass through PRs
<pstolowski> heya
<zyga> hejka
<mborzecki> pstolowski: hey
<mborzecki> only 2 pages of reviews
<pstolowski> yay
<mborzecki> pstolowski: added a comment https://github.com/snapcore/snapd/pull/7052#discussion_r300276495
<mborzecki> pstolowski: in Commit() you could probably do `purgeNulls(t.pristine)` too, but maybe doing it per snap is less work in the end
<mborzecki> heh, 17C, while last week it works 30C this time of day
<mborzecki> heh s/works/was/
<zyga> is mvo off today?
<zyga> mborzecki: woow
<zyga> envy
<zyga> it's so hot here already
<zyga> 28 in the morning
<Chipaca> zyga: iirc mvo is off yes
<Chipaca> and ijohnson
<zyga> I dismissed his needs changes review on https://github.com/snapcore/snapd/pull/7053
<zyga> I would love to get a 2nd review to be sure it's ok
<zyga> the only thing I'm not sure about is the modprobe mechanism
<zyga> where I suspect the comment is incorrect but ... we're not sure
<Chipaca> zyga: no, you need two reviews
<zyga> Chipaca: I said this already but https://spread.zygoon.pl/
<zyga> Chipaca: I know, I dismissed mvo's -1 review after addressing the requests
<Chipaca> zyga: i mean, you dismissed one of mvo's reviews, you should dismiss the other one too?
<zyga> Chipaca: why? jamie was ok with the review :)
<zyga> Chipaca: and mvo only commented on the commit message
<mborzecki> is https://elixir.bootlin.com flaky for you too?
<Chipaca> hm, fair
<zyga> Chipaca: review it if you can, it's relatively short
<zyga> it's just comments and two new lines
<zyga> home and tmp
<Chipaca> i'll try
<zyga> mborzecki: yes
<zyga> mborzecki: still negotiating ssl stuff
<zyga> it's loading a little now
<mborzecki> hmm
<zyga> loaded
<zyga> hey pedronis
<zyga> pedronis: just sharing https://spread.zygoon.pl/
<zyga> (now backed by proper CDN and stuff, not my pico-server)
<pedronis> did I mention, did people see, this? https://forum.snapcraft.io/t/remodeling-devicectx-refactoring-and-new-test-helpers/12114
<pedronis> Chipaca: hi, is 6878 ready for re-review?
<Chipaca> pedronis: I didn't change the struct yet, but other than that yes
<Chipaca> pedronis: the struct order i mean
<pedronis> understood
<Chipaca> that shouldn't break anything else :-)
<Chipaca> pedronis: found another merge issue, fixing that
<Chipaca> :-/
<pedronis> Chipaca: ok, anyway need to look at some other PRs and forum topics first, but wanted to know if to look at it after
<Chipaca> pedronis: ah ok
<Chipaca> pedronis: it's no biggie, i'll have it fixed and push it and the struct reorg in no time
<pedronis> zyga: not urgent, but I was looking at spread tests set to manual, and wondering if the test here can be reenabled now:  https://github.com/snapcore/snapd/pull/3076/files
<zyga> oh, good catch
<zyga> I think so
<zyga> let's see
<zyga> breakfast
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7063
<Chipaca> the interface-calendar-service test is rather flaky
<Chipaca> or rather its restore
<zyga> brb
<Chipaca> zyga: note #7061 has two +1's
<Chipaca> niemeyer: can you add anonymouse64 to snapd-committers?
<zyga> mmm
<zyga> oh indeed
<zyga> thank you
<zyga> I asked about this and mvo said he did add him
<zyga> but perhaps my question was misunderstood
<Chipaca> zyga: there's a maze of groups, all different
<zyga> aha
<zyga> sucky
 * Chipaca notes it is Time For A Break, and complies
<Eighth_Doctor> zyga: are we going to be dead in the water for Fedora 31?
<Eighth_Doctor> with the cgroupsv2 switch
<zyga> hopefully not, we want to support it but it's not on the roadmap as an item for us
<zyga> perhaps pedronis can advise since he's running the  schedule with mvo
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/7062#issuecomment-508434440  http://i.imgur.com/eTic1wS.jpg
<zyga> interesting
<zyga> it _feel_ more like a different bug though
<zyga> about the fact we build snapd incorrectly in testing
<zyga> because we build it on the host
<zyga> and  then happily stick it into 16.04 world
<zyga> 18.04+ has some incompatibility it seems
<zyga> the error is  /usr/lib/snapd/snap-confine: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.27' not found (required by /usr/lib/snapd/snap-confine)
<zyga> so...
<zyga> it's not the test
<zyga> it's all the tests
<zyga> we discussed  this in the past
 * Chipaca adds more http://i.imgur.com/eTic1wS.jpg
<mborzecki> fedora repos are down?
<zyga> mborzecki: dunno
<zyga> mborzecki: small update to mountinfo-tool
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7064
<zyga> mborzecki: I have a  few more patches after this one
<Chipaca> mborzecki: #7063 GTG
<mborzecki> yay
<Chipaca> zyga: what's the status of all the per-user mount ns work?
<zyga> Chipaca: it's paused after MS_SHARED bug which will also include extra  new tests, this is coming off that pipeline
<zyga> Chipaca: mountinfo-tool needs to grow a few more patches to be useful here
<zyga> Chipaca: one of them is interesting
<zyga> Chipaca: rest are pretty boring and obvious
<zyga> Chipaca: (renumbering that keeps peer group IDs in sync across more than one file, so that we can test parent/slave relationship between per snap and per-user nses)
<Chipaca> zyga: is there a reason #6341 isn't labelled with the per-user ns thing?
<zyga> no, not really
<zyga> perhaps it pre-dates that?
<zyga> not sure
<zyga> some changes are bound to come that way
<zyga> based on the feedback I have already
<Chipaca> mborzecki: what's blocking #6708 ?
<zyga> but I want to properly test properties of each ns before proceeding
<zyga> Chipaca: nobody fixed https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824384
<Chipaca> zyga: ISTM that a lot of that work is too early to actually be reviewed
<mborzecki> Chipaca: let me check
<mborzecki> Chipaca: apparmor packages in ubuntu are built without -fPIE  https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1824384
<Chipaca> so much stuff is blocked or whatnot, it seems like we'd all make lousy gardeners
<mborzecki> Chipaca: -fPIC
<Chipaca> mborzecki: -fCAKE
<mborzecki> Chipaca: -fLONGFLAG, as a result we can't build s-c as a (sweet-cherry)PIE binary
<zyga> ISTM?
<zyga> ah
<zyga> it  seems to me
<zyga> Chipaca: 6341?
<Chipaca> zyga: and the rest of per-user-ns
<mborzecki> hm mvo is off today, maybe someone else can take a look at https://github.com/snapcore/snapd/pull/7041 ?
<zyga> I it's not early, it was ready to  be  reviewed for a long time before we realized sharing was broken, but was very slow to  review or got stuck on prerequisites. e.g. https://github.com/snapcore/snapd/pull/6347 is a chunk of  the bigger WIP  branch and the bigger WIP branch was reduced tenfold since it was first opened
<zyga> I wish there was a "parked" label that would let us keep a PR open and not lose state but not worry reviewrs
<zyga> *reviewers
<Chipaca> zyga: closing it doesn't lose state though
<zyga> yeah, except finding  it is harder
<zyga> I can consider that if you want to run the numbers down
<zyga> but then again https://github.com/snapcore/snapd/pull/5644 is close to its first anniversary :)
<pedronis> mborzecki: I will look at 6939 today (have to read some things first though)
<mborzecki> pedronis: thank you!
<mborzecki> zyga: hm oracle linux is missing from your os-release-zoo
<zyga> mborzecki: do we need special casing in snapd?
<zyga> I don't recall running it ever
<Eighth_Doctor> pedronis: https://fedoraproject.org/wiki/Changes/CGroupsV2
<mborzecki> zyga: i'm trying to come up with possible reasons for https://bugzilla.redhat.com/show_bug.cgi?id=1726382
<zyga> we reexec
<zyga> and then all stuff breaks?
<mborzecki> zyga: other than oracle linux or some old centos, or rexec (but that's off by default on non ubuntu?)
<mborzecki> zyga: but it's snapd trying to call snap-seccomp from /usr/lib/snapd, even with reexec that path isn't baked into snapd
<Eighth_Doctor> mborzecki: we should _never_ be attempting re-exec
<Eighth_Doctor> unless someone broke the override
<pedronis> Eighth_Doctor: thanks, we'll have to reevalute this, as zyga said is not in our immediate plans atm
<mborzecki> Eighth_Doctor: i'm wondering what could possibly be the system that guy has, he's clearly getting the package from epel
<Eighth_Doctor> pedronis: well, at least we had two years heads up...
<Eighth_Doctor> mborzecki: right, I'm confused too because I don't have that problem on my rhel or centos systems
<pedronis> Eighth_Doctor: is there somewhere where I can see the timeline, like when is beta freeze etc
<Eighth_Doctor> there are a lot of CentOS derivatives though
<Eighth_Doctor> pedronis: https://fedoraproject.org/wiki/Releases/31/Schedule
<Eighth_Doctor> pedronis: the discussion in devel@ makes me think that there will be almost no chance it'll get reverted
<Eighth_Doctor> all the container tools in Fedora are cgroupsv2 ready
<mborzecki> i suppose once fedora does the switch, arch will follow
<mborzecki> bc bleeding edge and such ;)
<Eighth_Doctor> Yep
<Eighth_Doctor> openSUSE will switch at the same time as well
<Eighth_Doctor> Richard is trying to beat Fedora to "breaking everything" with a cgroups v2 switchover
<mborzecki> hahah
<Eighth_Doctor> my estimation is that basically all major upstream distros except Debian (well, because Debian :( ) will be switched to cgroups v2
<zyga> Break
<ogra> Continue
<mborzecki> zyga: hm that --self-test makes me uneasy, but so does `mv mountinfo-tool mountinfotool.py && ln -s mountinfotool.py mountinfo-tool && python -m unittest ./mountinfotool.py`
<zyga> Why does it make you uneasy?
<zyga> I like it because you can copy it around as a single file
<zyga> And it works pretty much anywhere
<mborzecki> zyga: feels a bit off, otoh it's nice to have some tests there, so maybe if there's no other way we'll do it like you prooposed
<pedronis> mborzecki: which PR is that ?
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/7064/
<pedronis> made a couple of comments about this there
<pedronis> I'm not particurly against given the nature of the tool
<zyga> Replied, will tweak after lunch
<pedronis> zyga: read bzr help selftest, I stand that is not a great name for that, indeed the help is confusing, it never clarifies what these tests are
<zyga> pedronis: Iâll gladly rename it
<cachio> pstolowski, hey
<pstolowski> cachio: hi, what's up?
<cachio> pstolowski, I am debugging the test auto-refresh-retry which is failing on beta validation
<cachio> and I see this
<cachio> https://paste.ubuntu.com/p/g58SRvmZhZ/
<cachio> pstolowski, it never shows "state ensure error: persistent network error"
<pstolowski> cachio: where are you seeing this?
<cachio> in jenkins logs
<cachio> pstolowski, I am using a vm inside real hardware
<cachio> to validate the image
<cachio> beta image
<pstolowski> cachio: and it's core 16?
<cachio> pstolowski, yes
<pedronis> mborzecki: sorry for noticing this late, where is the verb "position" coming from in the gadget work? is it a ubuntu-image term?
<mborzecki> pedronis: positiona as in gadget.PositionVolume()? this one is from reviews, iirc the first version was LayoutVolume()
<pedronis> mborzecki: because we have already layouts ?
<pstolowski> cachio: ok, it seems that it fails much earlier at device registration (because of no network), before even reaching the logic of auto refresh that we're trying to test there
<mborzecki> pedronis: yeah, not to confuse people
<pedronis> mborzecki: but the new verb create messages that are to relate to
<mborzecki> pedronis: also, the structures are named PositionedSomething, as in positioned within the volume
<pedronis> that's what I'm noticing reading the last PRs
<pedronis> there is no general sense of what "positiong a volume" means
<pstolowski> cachio: is this run with no network at all?
<pedronis> mborzecki: "cannot position volume" is a fairly obscure message
<cachio> pstolowski, it has network
<mborzecki> pedronis: we can go back to LayoutVolume(), then `cannot layout volume contents` or something similar
<cachio> pstolowski, the test is executed in a vm indice a machine (real hardware)
<cachio> like the nested suite
<pstolowski> cachio: okay; maybe we need to wait for registration before entering network namespace in the test. i'll see. is it possible for me to run tests from my local branch there?
<pstolowski> cachio: or can i give you a diff to try out?
<cachio> pstolowski, sure
<pstolowski> okay, i'll try to tweak the test a little bit
<mborzecki> pedronis: hmm https://www.thesaurus.com/browse/lay%20out verb synonyms are even more confusing
<pedronis> mborzecki: yes, I think  the expected verb here is "lay out"
<pedronis> and we just have to live with the double use
<pedronis> the context is fairly different anyway
<mborzecki> pedronis: LayOutVolume() then? caps are different since it really stands for 'lay out'
<pedronis> yes, or VolumeLayout (more functional)
<pedronis> and then  s/Positioned/LayedOut/  and s/Positioning/Layout/
<pedronis> sorry LaidOut
<mborzecki> mhm
<pedronis> I mean for Positioned
<pedronis> mborzecki: anyway I commented on this also in 6939, don't know if you prefer to fix everything in master and update that one
<pedronis> or do it after
<pedronis> 6939 needs a 2nd review anyway ATM tough
<mborzecki> pedronis: probably after mounted updater lands, there's fewer conflicts with each PR that lands
<pedronis> mborzecki: anyway I have some other comments about external message terminology in 6939 (and probably previous code)
<pedronis> that I put there
<mborzecki> pedronis: ok, will check that, thanks!
<pedronis> Chipaca: standup?
<Chipaca> trying to :)
<Chipaca> mborzecki: question, why partx instead of losetup?
<Chipaca> mborzecki: (for after the standup)
<Chipaca> um
<Chipaca> mborzecki: not you
<mborzecki> cmatsuoka: ^^
<Chipaca> cmatsuoka: you ^ :)
<Chipaca> silly people having same-length nicks
<zyga> in the past losetup could not do partitions
<zyga> perhaps kpartx just because
<Chipaca> yes, but it can now, since 16.04 at least
<zyga> mkcoffee ---no-sugar
<Chipaca> oh wait, partx and kpartx are different animals
<zyga> Chipaca: muscle memory
<Chipaca> I don't know partx
<Chipaca> kpartx was poison
<cmatsuoka> Chipaca: partx was available inside the image and I used it because it was there. I don't know if losetup uses the same call or not, but we can test it
<zyga> Chipaca: can you look at python bit
<zyga> pretty please
<zyga> https://github.com/snapcore/snapd/pull/7064
<zyga> I will push two more but they depend on this test setup
<cmatsuoka> anyway, the bio race in kernel seems to be a real bug
<Chipaca> can somebody with an 18.04 server do an uname -r just to confirm something for me please?
<cmatsuoka> Chipaca: 4.15.0-54-generic
<Chipaca> cmatsuoka: thanks
<cmatsuoka> (and my 18.04 desktop says 4.15.0-52-generic)
<Chipaca> cmatsuoka: thanksÂ²
<cmatsuoka> yaw
<pstolowski> cachio: can you grab 'snap changes' of that failing autorefresh retry test?
<cachio> pstolowski, sure
<pstolowski> thanks
<cachio> pstolowski, it will take a time to run
<pstolowski> ok
<mborzecki> zyga: we got our answer https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c5
<zyga> Interesting
<zyga> Oh well
<zyga> Needs a well made answer
<zyga> Iâm AFK with dog now
<zyga> mborzecki: do you think the question warrants a FAQ response from us
<zyga> mborzecki: like "we want to have one codebase, we want to support reexec, etc'
<cachio> pstolowski, I think it is related to the model issue
<cachio> pstolowski, because I cannot reproduce it when I run console conf and register the user
<pstolowski> cachio: right, i thought so as you discussed that on standup
<pstolowski> cachio: snap changes would help confirm it
<cachio> pstolowski,  yes, I'll add that to the test
<cachio> thanks
<pstolowski> cachio: good idea
<pedronis> cachio: I created the card I discussed
<cachio> pedronis, nice, thanks
<zyga> mborzecki: one more small review perhaps?
<zyga> https://github.com/snapcore/snapd/commit/cbf0afae9c43716f2c9ef73b849947163769091d
<zyga> I'll open it in a sec, just waiting for travis
<zyga> eh portal test..
 * cachio lunch
<zyga> https://github.com/snapcore/snapd/pull/7065 is ready now :)
<zyga> and now I can work on the rest, because base has landed
<zyga> whee
<icey> sergiusens: I don't mind you making that change in the rust PR, or I can get to it tomorrow
<sergiusens> icey: thanks, i might do it late tonight
<icey> I'll look before I start on it then :-)
<zyga> https://github.com/snapcore/snapd/pull/7065 anyone?
<zyga> sergiusens: ^ python, wanna see?
<ogra> geez, was the store just down ??
<ogra> (i'm just hacking on a new architecture and spent the last hour debugging because i got "error: unable to contact snap store" ... now it started working out of the blue)
<ogra> bad timing i guess
<ogra> ogra@pi4:~$ sudo hdparm -tT /dev/sda1
<ogra>  Timing cached reads:   1508 MB in  2.00 seconds = 754.22 MB/sec
<ogra>  Timing buffered disk reads: 1106 MB in  3.00 seconds = 368.64 MB/sec
<ogra> hmm, not to bad for a pi ...
<zyga> Wow
<zyga> Will you have models soon?
<ogra> you wish ... no u-boot port yet
<ogra> i'm running classic on a USB3.1 SSD with the raspbian kernel currently
<ogra> still ... makes a nice build machine ;)
<bulldog68> hi am running into a problem with my application when it is snap packaged :(  , the issue is with reading the data from fifo file
<bulldog68> https://forum.snapcraft.io/t/no-read-from-fifo-device-in-snap-packaged-app/12150/4
<bulldog68> am getting apparmor denials when i try to read from fifo file
<bulldog68> Uploaded file: https://uploads.kiwiirc.com/files/fd0e794c69323a8d5976f6d3a6a544c3/pasted.txt
#snappy 2019-07-05
<mithrison> hi
<mithrison> I'm having problem running snap and snapcraft on ubuntu 18 server on raspberry pi.. details and logs --> https://forum.snapcraft.io/t/multipass-on-raspberry-pi-3b/12162/2
<amurray> mithrison: looks like this is a known issue https://github.com/CanonicalLtd/multipass/issues/770
<mithrison> amurray Is it an issue with Ubuntu 18 specifically?
<amurray> mithrison: the ubuntu 18.04 raspberry pi kernel does not support kvm - see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961 for more info
<mithrison> So use 16? amurray
<mithrison> the proper way to enable KVM support on any pi is to set:dtoverlay=vc4-kms-v3din the config.txt file of the bootloader, the kernel is specifically set up for this via the included raspberry pi foundation patches.
<mithrison> That's exactly what I did BTW
<amurray> mithrison: hmm ok - sorry I am not sure (am not a rpi expert) ogra ^^^ ?
<mborzecki> morning
<zyga> Hey
<mborzecki> zyga: hey hey
<zyga> mborzecki: I have an errand in the morning
<zyga> I sent a small python PR
<zyga> I have more on GH but after this one
<zyga> I will be online in about an hour
<mborzecki> zyga: i reviewed 2 python prs from you, is that something new?
<mvo> hey hey, what did I miss yesterday?
<mborzecki> mvo: hey, probably not much, thursday felt a bit slow
<mvo> mborzecki: 'k
<mvo> mborzecki: I think I owe you a review, what was the PR again?
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7041 :)
<mvo> aha, yes
<mvo> doing that now before anything else gets in the way
<mborzecki> mvo: thank you!
<pstolowski> mornings!
<mvo> hey pstolowski, good morning
<mborzecki> pstolowski: hey
<mborzecki> mvo: about post staging callback, for instance i'm using it to copy bootenv files generated by snap prepare-image to the structure that contains system-boot data
<zyga> re
<zyga> mborzecki: looking now, sorry, some stuff took longer than we expected
<zyga> mborzecki: replied to both https://github.com/snapcore/snapd/pull/7065 and https://github.com/snapcore/snapd/pull/7068
<zyga> hey mvo
<mvo> hey zyga - in a meeting right now
<zyga> mvo: hey, nothing urgent, just wanted to say hi :)
<zyga> pstolowski, mborzecki: if you guys +1 https://github.com/snapcore/snapd/pull/7068 I will open a small follow-up and then we have the path towards those namespace tests :)
<zyga> there are two more python changes needed but they are much simpler than even this simple pr :)
<mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip
<mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip/c
<mborzecki> mvo: 3rd time's the charm: https://github.com/bboozzoo/snapd/tree/bboozzoo/gadget-update-wip
<zyga> pstolowski: https://bugs.launchpad.net/snappy/+bug/1835342
<zyga> what do you think?
<pstolowski> zyga: woah, let me take a look
<zyga> pstolowski: I guess that now with snap connections we  just show something we  always had and did
<pstolowski> hmm, our parsing errors aren't very nice: error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-failing-interface-hooks": cannot parse snap.yaml: yaml: unmarshal errors:
<pstolowski>   line 3: cannot unmarshal !!seq into map[string]interface {}
<zyga> yeah
<zyga> what is !!seq?
<zyga> https://github.com/snapcore/snapd/pull/7065 is green, just needs reviews
<zyga> +52,-1, all python test code
<pstolowski> zyga: probably the array: "plugs: [home,network]"
<pstolowski> zyga: re that bug, i suspect on refresh we don't remove obsolete plugs from conn state (only from the repo), and 'snap connections' shows conns from state; reloadConnections bites again
<zyga> pstolowski: that's correct
<zyga> pstolowski: on rollback we'd not restore connections otherwise
<zyga> pstolowski: perhaps we should allow snap disconnect to remove stale connections that are not represented in the repo?
<pstolowski> zyga: +1. also, i wonder if restart cures it (stray connections cleanup logic)
<zyga> pstolowski: hmm, indeed
<pstolowski> zyga: and maybe that's the explanation of entire stray connections issue that this cleanup was made for
<pstolowski> we blamed some unknown bug in old snapd
<zyga> I think we always knew this  part
<zyga> that snaps can change interfaces over revisions
<zyga> and  we don't do anything about the connections
<zyga> we chose not to remove them early on
<zyga> and  later on did
<pstolowski> zyga: ah, we simply never shown them
<zyga> until we grew snap connections
<pstolowski> yes
<zyga> brb, moving
<pstolowski> zyga: i can take this bug after i finish current work on connects
<zyga> yeah, no rush
<pstolowski> zyga: updated the bug report
<zyga> thanks
<zyga> re
<zyga> ondra: thanks for the call, I learned useful things
<ondra> zyga and thank you for looking into this :)
<mborzecki> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c6
<zyga> looking
<zyga> mborzecki: it is helpful to the  reporter but I think we will eventually entirely do runtime detection or static declaration that must be provided by the distribution
<zyga> mborzecki: in either case it is useful to the reporter, thank you
<zyga> I need a 2nd review (thanks mborzecki) for simple python function https://github.com/snapcore/snapd/pull/7065
<pstolowski> looking
<zyga> pstolowski: thank you!
<zyga> eh, travis has stale state
<zyga> pstolowski: thank you!
<zyga> pstolowski: would you mind doing another one in the same file: https://github.com/snapcore/snapd/pull/7068
<pstolowski> zyga: sure. has conflicts though
<zyga> aww, one sec
<zyga> pstolowski: resolved
<zyga> mborzecki: wow https://github.com/rswier/c4
<pstolowski> zyga: 1-1 in a moment, will take a look afterwards
<zyga> thank you
<mborzecki> zyga: reads like an entry to ioccc
<pstolowski> zyga: i'm working on a spread test with a failing connect- hook (just exit 1); what's the reason i see multiple debug messages like this in the failing task log: https://paste.ubuntu.com/p/M3J7gVrDjX/
<pstolowski> ?
<zyga> you must have SNAPD_DEBUG=1 or SNAP_CONFINE_DEBUG=yes  set
<zyga> brb
<pstolowski> zyga: got it; i think it would make sense to give more context in that message, and if possible show it just once
<zyga> pstolowski: it cannot be shown once
<zyga> pstolowski: each one is a real mount happening
<zyga> pstolowski: it's spread all over the code
<pstolowski> zyga: ah, got it
<zyga> pstolowski: I lament that we cannot show you what is going on
<zyga> pstolowski: but i fought that battle and lost
<zyga> pstolowski: and we only show what is mounted when we die :/
<zyga> pstolowski: or when we run debug build
<mborzecki> zyga: hm mountsnoop maybe? it's from bcc
<mborzecki> zyga: uh, nvm, thought you wanted to track all the mounts ;)
<zyga> Nah, just print a debug message
<zyga> pstolowski: replied, thanks for looking
<pstolowski> zyga: one more comment
<zyga> looking
<zyga> pstolowski: fixed! thank you
<pstolowski> zyga: should we have a simple test for that?
<zyga> pstolowski: main is untested but now we can add actual tests easily, yeah
<zyga> pstolowski: pushed  :)
<pstolowski> ty
<pstolowski> +1
<zyga> pstolowski: thanks, I'll add more tests in a separate PR
 * zyga goes for lunch
<vidal72[m]> is this being worked on? https://bugzilla.redhat.com/show_bug.cgi?id=1438079
<sergiusens> zyga: hye, do you still want review? got your notification as I was taking off flying over to my parents with my eldest for the winter break
<zyga> re
<zyga> sergiusens: thank you, it's all good
<zyga> vidal72[m]: checking
<zyga> vidal72[m]: no, not at present
<zyga> vidal72[m]: we don't have anyone idle that can jump into it, we have other commitments first
<zyga> pstolowski: more tests https://github.com/snapcore/snapd/pull/7069
<zyga> vidal72[m]: I will likely work on it but I don't control my work queue directly
<zyga> mborzecki, pstolowski: essential but simple https://github.com/snapcore/snapd/pull/7070
<zyga> just use what we've built
<zyga> I tried to explain why this is useful for the upcoming namespace tests
<zyga> I only have one more branch to propose for mountinfo-tool (that I know of) for the test branch to be useful
<zyga> but we are super close now
<ogra> mvo, i seem to remember you had a patch to timedated that prevented the symlink issues we had with it ... couold it be that this patch got lost ? (seems abeato is running into the issues we had before that again)
<mvo> ogra: possible, I resurrected two patches around this area but maybe I missed one
<ogra> yeah, they are quite old (from pitti originally i think ... around 15.04)
<zyga> mvo: second review for https://github.com/snapcore/snapd/pull/7069 pretty please?
<zyga> just unit tests for python
<mvo> zyga: in a meeting right now
<zyga> mvo: no worries, thanks
<zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7071 one more python renumbering pR
<zyga> this time with tests up front :)
<zyga> oh, sergio is off?
<zyga> ah right I remember now
<zyga> actually
<zyga> ijohnson: can you look at https://github.com/snapcore/snapd/pull/7071 and https://github.com/snapcore/snapd/pull/7069
<zyga> I think you will use this tool a lot
<ijohnson> zyga: sure
<zyga> mountinfo-tool is a bit like findmnt, but more tailored to what we do
<zyga> the context is that I'm extending it to propose a new spread test that measures the configuration of the mount namespace
<zyga> and the extensions are mainly to build a deterministic view of the mount table
<zyga> with things like memory size or boot ordering of cgroup mount units neutered
<zyga> the tool started without any tests so I'm also adding some small unit tests as I go
<ijohnson> zyga: interesting yes that sounds very useful I will look into mountinfo-tool today
<zyga> in spread debug shell it is on path
<zyga> and works on each os
<zyga> well, each distro
<Laney> hi
<Laney> using snapcraft, is it possible to natively build for i386 on my amd64 machine?
<Laney> launching an i386 multipass VM or lxd container should work, but I don't see an option for it, only --target-arch which says it's going to cross compile
<zyga> Laney: I don't know of any option, perhaps sergiusens can help?
<zyga> wow, I just did something cool
<zyga> I don't know which key I hit
<zyga> but I got a cool tab completion I never saw before:
<zyga> zyga@yantra:~/snapd/tests/lib/bin> {.m{ountinfo-tool.swp,ypy_cache},M{ATCH,akefile},REBOOT,any-python,cleanup{,-frames},host,mountinfo-tool,not,snap-tool,unshared{,-slave}} ^C
<zyga> how do I do that?
<mvo> cmatsuoka: just fyi, I created a "uc20" branch for snapd and added a PR with your changes. I will do the same for our other git repos and update spike-tools. this way we should have a bit more consistency :)
<zyga> https://github.com/snapcore/snapd/pull/7071 is green
<cmatsuoka> mvo: excellent, this should make things easier
<cmatsuoka> mvo: uc20 meaning the uc20 spike, right? we'll probably have to start over for the "real" uc20
<mvo> cmatsuoka: yeah, for the real uc20 we need a new name :) maybe just 20?
<cmatsuoka> mvo: could be, did we use just 18 for core 18?
<mvo> cmatsuoka: yes
<cmatsuoka> mvo: 20 for the real thing then :D
<ogra> ppisati, have you seen https://forum.snapcraft.io/t/how-do-i-add-support-for-a-custom-touch-screen-on-my-raspberry-pi/12148 ?
<ogra> (i'm a bit out of ideas here)
<Laney> I ended up making an i386 VM myself with multipass (passing it the URL to a cloud image!) and then using --destructive-mode or whatever it is, since we apparently don't produce minimal cloud images for anything other than amd64 & snapcraft uses cloud-images.u.c rather than the ubuntu: remote built into lxd
<zyga> https://github.com/snapcore/snapd/pull/7071 anyone?
<zyga> Laney: I have https://spread.zygoon.pl
<zyga> not sure if that helps you with an image
<zyga> it's a qemu vm with ubuntu/ubuntu credentials
<Laney> zyga: thx, what I needed in this case was the ability to tell multipass and snapcraft to launch i386 images, guess I should be a good citizen and file bugs really
<zyga> yeah
<zyga> I *think* it should be supported
<zyga> Saviq: ^ ?
 * zyga fires another round of spread
<Saviq> zyga, Laney: yeah we could certainly launch CPU-compatible images, what we've so far said we did not want to do was emulation (i.e. arm on x86)
<Saviq> but we may have to revisit that, especially if that would mean you could run/build arm on x86 Windows/macOS
<Saviq> I was worried about the state of qemu's emulation support, remembering our phone times and virt Launchpad builders
<Laney> Saviq: hey there
<Laney> my bug's not going to be about emulation or anything, but by all means feel free to do that too :D
<cjwatson> zyga: that's complete-into-braces, M-{
<zyga> cjwatson: thank you!
<zyga> mvo: schema anyone https://github.com/cuelang/cue
<mvo> zyga: nice
<zyga> niemeyer: ^^ cue for schema
<zyga> and maybe for data too
<ogra> Laney, simply dont use VMs at all ... create a conventioanl i386 lxd container, install snapcraft in it and "export SNAPCRAFT_BUILD_ENVIRONMENT=host" ... then just build (no --target-arch or any other options)
<Laney> ogra: sure, that seems to be more or less what --destructive-mode does too
<ogra> thats how i (have to ) use snapcraft for arm and arm64 too ... multipass is just getting in the way if you are not always using amd64
<ogra> yeah, --destructive-mode is similar to that
<Laney> but I think the situation could be improved a bit, that's what my requests are about :)
<ogra> by making multipass optional ;)
<Laney> no way, the multipass exprience is great
<ogra> or rather have it detect if its on non amd64/non-windows/non-macos
<ogra> and fall back to lxd
<ogra> as someone who 90% of the time builds for non x86 i find the multipass experience most awful
<Laney> there's no reason it couldn't launch an i386 vm for me (in fact it can if you go find the .img yourself)
<Laney> dunno if there's any big blockers on arm tho
<ogra> no kvm/qemu would be the first one ;)
<Laney> hmm
<Laney> how do the clouds work?
<ogra> aarch64 ...
<ogra> (that has kvm and spins up armhf VMs i think)
<Laney> oh right, yes, I meant arm64
<Laney> we make armhf containers indeed
<ogra> but most our arm devs dont have fancy arm64 machines at home
<ogra> they want to quickly build snaps for/on their Rpi
<ogra> (many of our customers too sadly)
<Laney> nod
<Laney> I think they and you would appreciate a slick experience there too, either great cross compilation support or emulation
 * Laney simply hasn't used that himself
<ogra> we had that with snapcraft 2.0
<ogra> even fancy cross building in lxd
<zyga> mvo: any chance for a review today?
<sergiusens> Laney: your request seems doable, but perhaps not this cycle as we are really underpowered for any extra load now
<Laney> hey sergiusens!
<Laney> it's ok, no particular priority from me
<sergiusens> great, there are plans in the air, but nothing that can be done short term and wouldn't be a hack
<mvo> zyga: not looking great, already relatively late - which one is the most important one you need?
<zyga> mvo: this one  https://github.com/snapcore/snapd/pull/7071
<zyga> just test tool tweaks (with tests)
<zyga> mvo: I have some more state on top but it will be in separate PRs, sorting for determinism and small tweak to renumbering that shrinks delta between unrelated options
 * ijohnson relocates to coffee shop
 * zyga fights non-reproducible output
<Eickmeyer> With Chromium moving to snap-only in Ubuntu, I'd like to get this issue moved along as quickly as possible for users of Ubuntu Studio: https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/13
<Eickmeyer> How can I get this going? I don't know much about how to work with snaps.
<ardaguclu_> Could you please review?, https://github.com/snapcore/snapd/pull/7050. I made a dummy mistake by sending this PR from master branch and now I can not continue other issues.
<zyga> ardaguclu_: hey
<zyga> ardaguclu_: you can always close it and reopen  anew one
<ardaguclu_> zyga: hey
<zyga> ardaguclu_: I think this is something for pstolowski|afk to review next week
<zyga> I'm not familiar with that part to review it
<ardaguclu_> zyga: thanks, that would be better closing and opening again
<zyga> it's really tricky and I tried recently and spectacularly failed to fix that
<ardaguclu_> after looking at issues at launchpad, is it ok directly solving or asking here before that
<zyga> ardaguclu_: it's best to talk but trying does not hurt
<zyga> some issues are harder than others
<zyga> this one is particularly complex as behavior differs across host system and go version
<ardaguclu_> ok, thanks
<zyga> it requires careful analysis of behavior to  come up with reasonable patches
<zyga> I failed at that btw
<ardaguclu_> I tried it 18.04 and 16.04
<zyga> thank you for contributing though, perhaps  there is something  else you want to look at?
<zyga> ardaguclu_: our spread suite runs on centos, amazon linux, fedora and many others
<ardaguclu_> but you are right, there are lots of different versions
<zyga> yeah
<zyga> some build with gccgo
<zyga> some with go
<zyga> 1.9, 1.10, 1.12
<zyga> etc etc
<ardaguclu_> yeah definitely
<zyga> then depedning on what is happening on the host network, the errors are somehow conveyed to go
<zyga> so (go-version, glibc-version, go-resover-vs-libc-resolver, network behavior) => (error object)
<ardaguclu_> what is the approaches such problems in our case
<zyga> the trick is to map the error object to a should-we-rertry flag
<ardaguclu_> trying at whole versions
<zyga> we don't have the  set of tuples that  describe possiblities
<zyga> so changes are kind of ad-hoc
<zyga> we need data first
<ardaguclu_> ok, thank you very much
 * zyga makes the final coffee of the day to work on another bug
<zyga> ardaguclu_: thank you! :)
<ardaguclu_> I really like snap, that's why, I will continue contribution :)
<zyga> ardaguclu_: do stick around, it's great to have contributions
<zyga> jjohansen: hey, do you have a second for a quick question
<jjohansen> zyga: uhmmm, never :)
<jjohansen> what is it?
<zyga> jjohansen: what is the difference beween network and  network_v8/
<jjohansen> zyga: may I ask why you are messing around in the packed protocol?
<jjohansen> :)
<zyga> jjohansen: I'm not but we look for both and some kernels have v8 but not the other one
<zyga> jjohansen: (what I mean by "look  for both" is snapd checks advertised kernel features)
<zyga> jjohansen: is v8 enough if present?
<jjohansen> zyga: v8 requires the yet to be released apparmor 3
<zyga> I see
<zyga> should we look for v8 then?
<jjohansen> its a clean abi break that came about from Linus's revert it 4.15
<zyga> mmm
<zyga> I recall that, yes
<jjohansen> yes, upstream and debian will only ever have v8
<jjohansen> we will carry a compat patch in ubuntu/suse for several years to support old userspaces
<zyga> jjohansen: aha,  I understand now
<zyga> jjohansen: and is the  apparmor_parser in ubuntu today using  network or networkv8?
<zyga> 2.13* AFAIR
<jjohansen> it is using network
<zyga> ok
<jjohansen> you will require abi rules in policy to get network_v8
<zyga> so perhaps we don't need to check for network_v8
<zyga> until we do
<jjohansen> sure, looking for it atm won't get you anything
<zyga> thank you, that was what I was curious about
<zyga> I'll adjust snapd next week when jdstrand can review it
<zyga> jjohansen: speaking of which, is the  packing protocol documented? I tried to "reverse" it at one point by going through the kernel sources and  compiling various crafted profiles but I failed to decompile the packed state machine
<jjohansen> zyga: I have some documentation started but its certainly not any even close to reasonable shape
<jjohansen> zyga: there are some tools coming that will help with the whole thing
<zyga> jjohansen: would you be interested if I tried to help in that  in small capacity?
<jjohansen> They can handle the unpacking and output in clean text the state machine
<zyga> interesting, that's what I was looking for at the time
<jjohansen> zyga: I am always interested in help, as long as the help doesn't take more effort than I get back out
<jjohansen> zyga: ping me in a couple of weeks, next week is bad for me
<zyga> jjohansen: gladly
<zyga> jjohansen: if you send me any git places to look, I can try to  familiarize myself with what is being made
<jjohansen> zyga: I have to dig for it, the work is pre our move to git
<zyga> jjohansen: no rush, I mainly follow apparmor from linus tree
<zyga> (though that's usually "late")
<jjohansen> ah, yeah this is userspace stuff so it will be landing in the gitlab side of things
<jjohansen> I'll see if I can't get a branch up as a WIP pull request
<zyga> jjohansen: which repo holds the userspace stuff?
<jjohansen> https://gitlab.com/apparmor/apparmor/
<jjohansen> zyga: and if you want to go a little broader https://gitlab.com/apparmor/
<jjohansen> we are going to start moving to doing kernel dev in gitlab side of things and the sync it to the kernel.org tree instead of directly commiting
<zyga> jjohansen: thanks, understood
 * zyga found a bug in the ref code, finally
 * zyga EOWs
#snappy 2019-07-07
<luk3yx> Is there a way to demote (my own) snaps in searches?
#snappy 2020-06-29
<mborzecki> morning
<pstolowski> morning
<zyga> Good morning
<mborzecki> pstolowski: zyga: hey guys
<zyga> I had a terrible night and Iâm barely awake, I will not be around for some more time
<zyga> Most likely I will take half a day or all day off
<zyga> I managed to finally start sleeping only around 6
<mup> PR snapd#8934 closed: overlord: mock timings.DurationThreshold in TestNewWithGoodState <Simple ð> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8934>
<pedronis> mborzecki: hi, could you review #8683 ?
<mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<mborzecki> pedronis: sure
<pedronis> thx
<zyga> o/
<zyga> I feel somewhat better and I will work in 30 minutes, just need to handle some remote doctor stuff
<zyga> thank you for the review pedronis, I think we will get the backend branch merged this week
<pedronis> pstolowski: hi, I reviewed #8923
<mup> PR #8923: wrappers: helper for enabling services (8/9) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8923>
<pstolowski> pedronis: hey, thank you
<pstolowski> hmm something has changed (for worse) on https://ubuntu.com/core wrt downloading core images. it's super confusing and more difficult now
<pedronis> pstolowski: probably something to talk with mvo when he's back
<pstolowski> download link is buried at the bottom under Download Ubuntu Core. Download section at the top > Ubuntu for IoT > Raspberry.. redirects to server images. very confusing. I spent 10 minutes looking for core image
<zyga> uh, github 500s
<zyga> yeah, it's down
<ogra> yeah ð
<ogra> well, only the UI ... seems cloning still works as expected
<zyga> ogra: seems to be somewhat more than that
<zyga> eh, I need to stretch my leg and back anyway
 * zyga is not in a good shape today
<mborzecki> brb, quick errand
<mborzecki> re
<pedronis> so github is not collaborating atm in terms of leaving reviews
<zyga> https://github.com/snapcore/snapd/pull/8910 is in a funny state
<mup> PR #8910: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910>
<zyga> it's not merged
<zyga> but conflicts with nothing?
<zyga> maybe got partially merged
<zyga> as in merged in the tree but not in some database
<zyga> eh, fun
<zyga> pedronis: https://www.githubstatus.com indicates the issue is being fixed now
<zyga> brb
<mup> PR snapd#8936 opened: osutil: detect autofs mounted in /home <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8936>
<zyga> eh, github is still malfunctioning
<ogra> GRRR ... it also affects build.snapcraft.io
<ogra> (which is really funny because you can pull/push just fine ... but i guess websockets sit on top of the web service)
<zyga> it seems everything is read only now
 * zyga phone + doctor
<zyga> re from doctor e-visit
<zyga> weird but works
<ogra> jdstrand, hmm, seems the raw-usb change to allow access to /dev/usb/lp[0-9] doesnt fully work ... a simple open call with (O_RDWR|O_NONBLOCK) : O_WRONLY) returns "Operation not permitted" ... but no errors are to be found anywhere (neither journal nor dmesg have anything)
<ogra> do you have any idea what i should look for (and where) ?
<zyga> ogra: look at the apparmor profile and check if there are any deny rules that could explain that
<zyga> ogra: also look if the device is udev-tagged
<zyga> ogra: a practical way is to check if major:minor and device/char code is present in the device cgroup of the snap that attempts access
<ogra> well, but if there was anything with apparmor shouldnt i see denials ?
<zyga> ogra: not if there are deny rules
<zyga> there are two things that don't log
<zyga> device cgroup not allowing things
<zyga> and apparmor with a deny rule
<zyga> is the /dev/usb/lp* thing a device node?
<ogra> would the latter log in devmode ?
<zyga> none of those log
<ogra> yeah
<zyga> in any mode
<ogra> ah, k
<ogra> ogra@localhost:~$ ls -lh /dev/usb/
<ogra> total 0
<ogra> crw-rw---- 1 root lp 180, 0 Jun 29 10:32 lp0
<zyga> ok
<ogra> just a char device
<zyga> it's a char device
<zyga> so check if that's listed in the device cgroup
<zyga> in /sys/fs/cgroup/devices/snap.$SNAP_NAME
<zyga> then cat the devices.list file
<zyga> if it's not there then that's why
<ogra> 180 is not in there
<zyga> and we can check why it's not there
<zyga> ok, look at the udev rules
<ogra> well, most likely because my PR is incomplete ð
<ogra> (i only added the entry for apparmor )
<zyga> please check /etc/udev/rules.d/70-snap.$SNAP_NAME.rules
<zyga> ah
<zyga> I see
<zyga> let me know if you need help with the udev side
<zyga> you need to figure out what kind of udev attributes to match against
<ogra> that was https://github.com/snapcore/snapd/pull/8329 btw
<mup> PR #8329: interfaces: allow raw access to USB printers <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8329>
<zyga> udevadm info --export-db is useful to know
<zyga> heh
<zyga> I reviewed it
<zyga> can you export udev data and paste the relevant fragment please?
<ogra> well, jamie made a comment already suspecting it is not enough
<zyga> the one that describes that /dev/usb/lp0
<zyga> :)
<zyga> yeah
<zyga> FWIW I'm happy it got merged
<zyga> even if it's not complete
<zyga> makes us move forward
<ogra> https://paste.ubuntu.com/p/3jshrXD4zj/
<zyga> huh
<zyga> what kind of printer is that?
<ogra> HP laserjet 1018
<ogra> on UC18
<zyga> maybe we need subsystem=USBMISC
<zyga> or maybe core is missing something
<zyga> can you plug it to a classic system
<zyga> and check if udev says more?
 * zyga is running system backup and that's long and makes fans go wrrrr
<mborzecki> zyga: the fans go brrr? :)
<ogra> thats tricky ... the one i have has the hplib stuff installed, that mangles udev afaik
<zyga> mborzecki: I go grrr while the fans go wrrr
<zyga> ogra: let's try it anyway
<zyga> maybe we need more udev rules
<zyga> as the core device does not seem to think this is a printer yet
<pedronis> mborzecki: I reviewed #8924
<mup> PR #8924: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8924>
<ogra> https://paste.ubuntu.com/p/46fDj5mzcf/ ... still usbmisc
<mborzecki> pedronis: thanks
<ogra> zyga, oh ... i only noticed now tht there is another (higher level) entry (i grepped for "usb/lp" ... ) that actually lists the snap ... it is just not the /dev/usb/lp0 itself that has any tags
<zyga> ahh
<zyga> interesting
<zyga> what's the other entry?
<ogra> https://paste.ubuntu.com/p/x7dW98cYFS/
<zyga> hmmm, interesting that there's a precise entry for this
<zyga> but not for lp0
 * zyga doesn't understand usb and udev well enough
<ogra> i wonder if i could DEVPATH from that entry ad the "printer device" in the app
<ogra> heh
<ogra> Connection from 192.168.2.48 port 32908 accepted
<ogra> /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0: Is a directory
<ogra> ð
<zyga> ogra: hmm?
<zyga> does it work
<zyga> btw maybe ask til for advice
<ogra> nah
<zyga> I would love to know more what to do with the permission stack
<zyga> and why that character device was not annotated
<ogra> well, i guess i need the tags for the actual device node
<zyga> but there's nothing to match against, you saw the data
<ogra> DEVNAME ?
<ogra> after all it is a fixed path ... "/dev/usb/lp*"
<zyga> hmm
<zyga> maybe
<zyga> can udev match against that?
<ogra> i guess so ... iirc that is how HP creates the symlinks into /dev
<zyga> try it
<zyga> https://github.com/snapcore/snapd/pull/8936 is a low hanging fruit
<mup> PR #8936: osutil: detect autofs mounted in /home <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8936>
<pedronis> mborzecki: reviewed #8930
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<mborzecki> pedronis: thanks again
<mup> PR snapd#8910 closed: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8910>
<zyga> backup complete, back to work
<zyga> github actions are still down
<zyga> but some pages work better now
<zyga> all systems operational now
<ogra> zyga, well, re-reading jdstrand's comment on the PR i guess just adding usbmisc might be the best
<ogra> var rawusbConnectedPlugUDev = []string{
<ogra>         `SUBSYSTEM=="usb"`,
<ogra>         `SUBSYSTEM=="tty", ENV{ID_BUS}=="usb"`,
<ogra> }
<ogra> here ...
<ogra> (no idea where that snippet comes from though)
<ogra> probably something like:   `SUBSYSTEM=="usbmisc", ENV{DEVNAME}=="/dev/usb/lp*"` (now i dont know if globbing wrks here though)
<pedronis> mborzecki: also #8925
<mup> PR #8925: bootloader: allow managed bootloader to update its boot config <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8925>
<mup> PR snapd#8936 closed: osutil: detect autofs mounted in /home <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8936>
<mup> PR snapd#8910 opened: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8910>
<mborzecki> pedronis: thank you
<mup> PR snapd#8910 closed: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8910>
<mup> PR snapd#8936 opened: osutil: detect autofs mounted in /home <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8936>
<mup> PR snapd#8935 closed: spread.yaml: allow amazon-linux-2-64 qemu with ec2-user/ec2-user <Simple ð> <Created by jdstrand> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8935>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8932#pullrequestreview-439084856
<mup> PR #8932: o/ifacestate: update security profiles in connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8932>
 * zyga -> meds
<zyga> re
<pstolowski> zyga: great catch! and i got the test wrong, because with this is should be 0 security backend calls
<zyga> happy to help :-)
<pstolowski> thanks!
<zyga> mborzecki: could you please do a 2nd review on https://github.com/snapcore/snapd/pull/8863
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> with this the backend branch is super close to landing
<zyga> (and has reduced from 2K+ to sub 1K now)
<mup> PR snapd#8937 opened: o/devicestate: set mark-seeded to done in the task itself <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8937>
<ijohnson> morning folks
<zyga> hey
<zyga> ijohnson: hey, since you are here and expressed interested in https://github.com/snapcore/snapd/pull/8863
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> could you please look, I think it is close
<ijohnson> zyga: yes I will take a look today, sorry it was on my queue for Friday but got lost with other things that came up
<zyga> no worries
<zyga> I asked maciek as well
<zyga> but I think this is very close and I would love to make progress on it :)
<pstolowski> zyga: updated #8932
<mup> PR #8932: o/ifacestate: update security profiles in connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8932>
<zyga> ack
<zyga> pstolowski: did you push?
<zyga> maybe gh is broken again
<pstolowski> zyga: yes, but wrong branch ;)
<pstolowski> now
 * pstolowski needs to cleanup his local git repo from old stale branches
<zyga> pstolowski: +1
<pstolowski> ty
<mup> PR snapd#8938 opened: sandbox/cgroup: extend SnapNameFromPid with tracking cgroup data <Created by zyga> <https://github.com/snapcore/snapd/pull/8938>
<zyga> ^ that's still a draft, I want to wait for the prerequisite to land and work on the TODO there
<zyga> pstolowski: let me know if you want to work on snap-confine and udev or if I should pick it up please
<mup> PR snapd#7168 closed: tests: measure testbed for leaking mountinfo entries <Test Robustness> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7168>
<mup> PR snapd#8570 closed: many: allow using ~/.snapdata instead of ~/snap <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8570>
<ijohnson> cachio: can you re-review / re-test #8933 ? I think I fixed the issue you found on Friday
<mup> PR #8933: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8933>
<pstolowski> zyga: i'll do it
<zyga> pstolowski: ok
 * zyga -> lunch!
<cachio> ijohnson, checking
<ijohnson> thanks cachio
<zyga> back
 * zyga migrates away from irccloud
<zyga> yay
<cachio> ijohnson, done
 * zyga closed his IRCcloud account
<ijohnson> thanks cachio
<cachio> yaw
<pstolowski> #8928 needs a 2nd review, test only and uncontroversial
<mup> PR #8928: tests: add spread test for disconnect undo caused by failing disconnect hook <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8928>
<mborzecki> pedronis_: do you mean first boot here? https://github.com/snapcore/snapd/pull/8924/files/567604a5eece95698088a21de1e36a9310a2ee77#r446889258
<mup> PR #8924: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8924>
<pedronis> mborzecki: no, I really mean more the combination of gadget/install and make bootable for run for handling install
<pedronis> mborzecki: which doesn't use this code?  it's a different path?
<mborzecki> pedronis: run mode install is https://github.com/snapcore/snapd/pull/8930
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<pedronis> mborzecki: yes, but that will overwrite things put there by gadget/install?
<pedronis> I'm just slightly wondering if we should avoid the double write
<pedronis> or if I'm confused there's not double write
<mborzecki> pedronis: ah, i see, so you mean the scenario when system-boot is popuated by gadget install, and then InstallBootConfig coes in an overwrites grub.cfg
<pedronis> yes
<pedronis> maybe is not worth worrying about it because we will remove things from gadget at some point?
<pedronis> but it feels a bit asymmetric to filter out things on update but not on write
<mborzecki> pedronis: yeah, i would assume it's not a problem, provided we keep installing boot config last
<mborzecki> with a note perhaps
<mborzecki> pedronis: just to make the assumptions about the order of operations clear
<pedronis> yea, it sounds like a low-prio todo, so a note here
<pedronis> and maybe a todo in the write code
<mborzecki> ok
 * cachio lunch
<mup> PR snapd#8936 closed: osutil: detect autofs mounted in /home <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8936>
<mup> PR snapd#8939 opened: [RFC] snap-confine: don't die if a device from sysfs path cannot be found by udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8863 has +2 and I'll merge it when green, if you want to review it I will hold but I'd love to push forward
<zyga> let me know please
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<ijohnson> zyga: nah go for it, I wouldn't get to it for at least a couple of hours
<ijohnson> sorry about that, but happy you're make progress, irrespective of my slow (and sometimes absent) reviews :-)
<zyga> ijohnson ack, thank you :)
<zyga> it was refined so I really think it's ready
<mup> PR snapd#8683 closed: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<mup> PR snapd#8940 opened: tests: fix "restart.service" <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8940>
<mup> PR snapd#8863 closed: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8863>
<mup> PR snapd#8941 opened: sandbox/cgroup: avoid parsing security tags twice <Created by zyga> <https://github.com/snapcore/snapd/pull/8941>
<mup> PR snapd#8928 closed: tests: add spread test for disconnect undo caused by failing disconnect hook <Simple ð> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8928>
<mup> PR snapd#8937 closed: o/devicestate: set mark-seeded to done in the task itself <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8937>
<mup> PR snapcraft#3192 opened: Flutter <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3192>
<mup> PR snapcraft#3191 closed: plugins: introduce v1.FlutterPlugin <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3191>
<mup> PR snapd#8942 opened: tests: to support different images on nested execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
#snappy 2020-06-30
<mup> PR snapd#8943 opened: wrappers: generate D-Bus service activation files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8943>
<mborzecki> morning
<mborzecki> hmm ubuntu-core-20 prepare sometimes fails right at the start, before we transtion from 20.04 host to actual uc20 https://paste.ubuntu.com/p/XrZQbS6mFf/
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#8912 closed: tests: Remove unity test from nightly test suite <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8912>
<mborzecki> mvo: there was an interesting failur in prepare of uc20: https://paste.ubuntu.com/p/XrZQbS6mFf/
<mborzecki> mvo: happens right at the beginning when we purge snapd on the host
<mborzecki> surprisingly, haven't seen it in regular 20.04 tests
<mvo> mborzecki: looking
<mvo> mborzecki: so purge did not actually work and we have leftover data?
<mvo> mborzecki: my theory is that we need to stop snapd earlier in postrm
<mborzecki> mvo: that's your pr right?
<mvo> mborzecki: still does not explain everything, but something like 8883
<mvo> mborzecki: I was thinking about it
<mvo> mborzecki: maybe we need to do the cleanup in two phases
<mvo> mborzecki: or N phases, cleanup, stop snapd, cleanup again if anything is left
<mvo> mborzecki: to ensure we catch stuff in flight - just a theory right now
<mborzecki> mhm
<mvo> mborzecki: would be cool to get the state.json content
<mvo> mborzecki: maybe that's the next debug output and/or snapd journal output, then we can see if e.g. snapd is restarting whle we purge it
<mborzecki> also, debug section is apparently not executed  when prepare fails
<mvo> mborzecki: oh no
<mvo> mborzecki: meh, ok
<mup> PR snapd#8944 opened: tests/lib/prepare-restore: collect debug info when prepare purge fails <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8944>
<mborzecki> mvo: ^^ ok, let's see if anythign comes up
<mvo> mborzecki: \o/ thank you so much
<pstolowski> morning
<mvo> mborzecki: the state.json maybe a bit unwieldy but pushing it through python3 -m json.tool will just make it incredible long :/ and jq seems overkill (plus we may important info) so let's do it
<mvo> (do it this way)
<mvo> hey pstolowski good morning!
<mborzecki> pstolowski: hey
<mborzecki> mvo: hmm it should be failry empty at this point, it's a clean system
<mborzecki> (or at least should be)
<mborzecki> mvo: i don't want to interrupt this run, so let's wait to see what happens and i can push the python bit next
<mvo> mborzecki: aha, indeed, it will just have the seeding for lxd/core18 - good point
<mvo> mborzecki: yeah, no python bits needed I think, was mostly thinking alound/wanted to talk it over. I think we can paste locally and run through jq or similar
<zyga> hello
<zyga> sorry for being offline, I was working on the other laptop and I haven't set IRC up there yet
<zyga> updated refresh backend branch and fixed two failing tests
<zyga> how are things?
<mvo> hey zyga
<zyga> hey mvo, welcome back
<mborzecki> zyga: hey
<mborzecki> mvo: haha https://github.com/snapcore/snapd/pull/8944 passed on uc20
<mup> PR #8944: tests/lib/prepare-restore: collect debug info when prepare purge fails <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8944>
<mup> PR snapd#8925 closed: bootloader: allow managed bootloader to update its boot config <Needs Samuele review> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8925>
<mvo> mborzecki: of course it did ;)
<mvo> mborzecki: fun with races
<mvo> mborzecki: I guess the rule is "if there is a race you always loose - even when you win!"
<mvo> mborzecki: let's just merge it and we will get good debug in one of the subsequent failures, wdyt?
<mborzecki> yup
<pedronis> mvo: mborzecki: hi, #8817 needs 2nd reviews
<mup> PR #8817: tests: new test to validate refresh and revert of kernel and gadget on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8817>
<mborzecki> zyga: pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8944 ?
<mup> PR #8944: tests/lib/prepare-restore: collect debug info when prepare purge fails <Precious Logs> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8944>
<zyga> sure
<pstolowski> yep
<zyga> mborzecki merge it!
<pstolowski> i made a syggestion... to late
<pstolowski> *too
<mborzecki> pstolowski: hah, do we have a wrapper for -m json.tool?
<pstolowski> hmm nope, also very few test use json.tool; no tests use json_pp
<mup> PR snapd#8944 closed: tests/lib/prepare-restore: collect debug info when prepare purge fails <Precious Logs> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8944>
 * zyga pushed to https://github.com/snapcore/snapd/pull/7825 - only ~ 600 lines change now
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> pstolowski I added one more comment to https://github.com/snapcore/snapd/pull/8939/files#r447500153
<mup> PR #8939: [RFC] snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<zyga> mborzecki I made one more, super small this time, branch carved out of the big backend branch: https://github.com/snapcore/snapd/pull/8938
<mup> PR #8938: sandbox/cgroup: extend SnapNameFromPid with tracking cgroup data <Created by zyga> <https://github.com/snapcore/snapd/pull/8938>
<mvo> pedronis: reviewing something else right now but will put it on my list
<mup> PR snapd#8817 closed: tests: new test to validate refresh and revert of kernel and gadget on uc20 <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8817>
<mup> PR snapd#8923 closed: wrappers: helper for enabling services (8/9) <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8923>
<mborzecki> need to run an errand, i'll probably work from some cafe or sth for a while, bbl
<zyga> brb
<mup> PR snapd#8940 closed: tests: fix "restart.service" <Simple ð> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8940>
<mup> PR snapd#8945 opened: tests: fix leaked dbus-daemon in selinux-clean <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8945>
<mborzecki> and re, at least for some time
<mup> PR snapd#8946 opened: client: move all error kinds into errors.go and add doc strings <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8946>
<mborzecki> pedronis: added a comment under https://github.com/snapcore/snapd/pull/8930#discussion_r446897486
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<mborzecki> it should probably be both flags tbh (if we ever have a script that's not aware of kernel.efi at some point)
<pedronis> mborzecki: answered, still we should add the TODO
<mborzecki> ok
<zyga> re
<mup> PR snapd#8947 opened: many: update managd boot config when refreshing snapd <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8947>
<pstolowski> zyga: two independent reports for a namespace error when refreshing gimp: https://bugs.launchpad.net/snapd/+bug/1884849
<mup> Bug #1884849: Error message trying to refresh or uninstalling a snap ( gimp ) <snapd:Triaged by zyga> <https://launchpad.net/bugs/1884849>
<mup> Bug #1873452 changed: 'snap install' | "INFO Waiting for restart..." <Snappy:Fix Released> <https://launchpad.net/bugs/1873452>
<mup> Bug #1835342 changed: disconnect fails if plug is gone from snap meta <Snappy:Fix Released by stolowski> <https://launchpad.net/bugs/1835342>
<mup> PR snapd#8899 closed: tests: add servicestate.Control tests (7/9) <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8899>
<mup> Bug #1835342 opened: disconnect fails if plug is gone from snap meta <Snappy:Fix Released by stolowski> <https://launchpad.net/bugs/1835342>
<mup> Bug #1835342 changed: disconnect fails if plug is gone from snap meta <Snappy:Fix Released by stolowski> <https://launchpad.net/bugs/1835342>
<mborzecki> ijohnson: there's some little tweaks in https://github.com/snapcore/snapd/pull/8918 and it could land, i can push a patch there if you haven't started with the fixes yet
<mup> PR #8918: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8918>
<ijohnson> mborzecki: no unfortunately I haven't had time to apply those yet, so feel free to do so, thanks!
<mborzecki> ijohnson: cool, will do
<cachio> zyga, hey, about the rename of the functions on the core-config helper, do you have something in mind?
<cachio> zyga, I though prepare_model -> prepare_core_model
<cachio> zyga, does it make sense?
<mup> PR snapd#8948 opened: cmd/snap-update-ns: detect unmounted mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/8948>
<cachio> zyga, I already updated the names,. perhaps this is better
<mborzecki> https://github.com/snapcore/snapd/pull/8918 needs a 2nd review
<mup> PR #8918: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8918>
 * cachio lunch
<mup> PR snapd#8945 closed: tests: fix leaked dbus-daemon in selinux-clean <Simple ð> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8945>
<dingus9> hey recently I had an issue where after a dist upgrade all my snaps lost there connections... e.g. plugs and slots all disconnected
<dingus9> so I ran into some interesting things while poking around... 1.  I can't find a snap command to list the default connections from meta/snap.yaml
<dingus9> 2. I was thinking that somewhere in connections it might list the default/installed state but I can't seem to see from the output where that might be indicated
<ogra> it just connects them at install time ... so snap connections will just show the default ones as connected
<dingus9> 3. is there a command that can restore a snap to it's default connections, might be helpful for users that want to reset a snap if they've manually connected or disconnect things
<dingus9> ogra: so defaults as connected currently right?
<ogra> anything you connected later will be tagged as "manual"
<ogra> (in the most right column of the connections output)
<dingus9> it's interesting, my output shows - for notes on all of them with all of them disconnected
<dingus9> naturally the app crashes
<ogra> ogra@pi4:~$ snap connections fabrica
<ogra> Interface       Plug                    Slot             Notes
<ogra> lxd             fabrica:lxd             lxd:lxd          manual
<ogra> mount-observe   fabrica:mount-observe   :mount-observe   manual
<ogra> network         fabrica:network         :network         -
<ogra> network-bind    fabrica:network-bind    :network-bind    -
<ogra> ssh-keys        fabrica:ssh-keys        :ssh-keys        manual
<ogra> system-observe  fabrica:system-observe  :system-observe  manual
<ogra> bah ...
<ogra> so here (even though the formatting is totally screwed) you can see that network and network-bind were connected by default
<dingus9> in my case if the default output lists a plug with no slot... is it listed because it was defaulted?
<dingus9> Interface        Plug                                              Slot                                           Notes
<dingus9> alsa             google-play-music-desktop-player:alsa             -                                              -
<dingus9> audio-playback   google-play-music-desktop-player:audio-playback   -                                              -
<dingus9> ...
<dingus9> desktop          google-play-music-desktop-player:desktop          :desktop                                       manual
<ogra> hmm, audio-playback should definitely autoconnect ... as should desktop
<dingus9> I manually started reconnecting but I thought it an odd thing to have to do
<ogra> it is
<dingus9> the obvious thing here is to just re-install
<dingus9> the snap
<ogra> either open a topic in the forum (see channel topic) or open a bug on launchpad
<dingus9> but I thought it an interesting thing to have happened
<ogra> this should definitely not happen
<dingus9> ogra, thanks just wanted a sanity check
<ogra> FSVO "interesting" ... ð
<dingus9> I thought maybe I was missing something
<ogra> nah, thats surely a bug
<dingus9> interesting thing here is I've not idea how to reproduce the issue as this happened after a dist upgrade of popos
<dingus9> who the hell knows what happened during that process
<dingus9> LOL
<ogra> "popos" ... /me grins
<ogra> (popo is a nickly term for "butt" in german ... )
<dingus9> haha
<dingus9> I'll have to avoid that with my sister in law
<dingus9> our family likes to use mushy for things that are squishy and she gets a kick out of that too
<ogra> haha
<mup> PR snapd#8949 opened: tests: new fs-tool which replaces the files.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
<mup> PR snapd#8950 opened: tests: new str-tool which replaces the strings.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
<mup> PR snapd#8924 closed: gadget, bootloader: preserve managed boot assets during gadget updates <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8924>
<mup> PR snapd#8951 opened: gadget/install: move udev trigger to gadget/install <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8951>
<mup> PR snapcraft#3192 closed: Flutter <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3192>
<mup> PR snapcraft#3193 opened: extensions: plug the opengl interface for GNOME <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3193>
<mup> PR snapd#8952 opened: tests: enable tests on uc20 which now work with the real model assertion <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8952>
<mup> PR snapd#8953 opened: tests: enable system-snap-refresh test on uc20 <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8953>
#snappy 2020-07-01
<bdx> hello, can we get some love on the auto-aliasing for the slurm snap?
<mborzecki> morning
<mborzecki> hmm the gadget update test isn't really enabled for uc20
<mborzecki> mvo: hey
<mborzecki> mvo: do you remember why we kept the gadget update spread test disabled for uc20?
<mvo> mborzecki: good morning
<mvo> mborzecki: no idea, let's enable it
<mborzecki> mvo: preserving boot config landed yday, so i'm trying to enable it now
<mvo> mborzecki: nice
<mborzecki> mvo: there's a bunch of times we do some snap install which is expected to trigger a reboot, and then hope that REBOOT issued by spread will be faster, i'm thinking that maybe we should intercept calls to shutdown like we do in the core20 recovery test
<mvo> mborzecki: I think so too
<mvo> mborzecki: it's probably the reason why sometimes the core die with connection lost
<mup> PR snapd#8953 closed: tests: enable system-snap-refresh test on uc20 <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8953>
<mvo> mborzecki: I think we have a smoking gun in the 8952 logs
<mborzecki> let me see
<mvo> mborzecki: the core20 prepare failed there
<mvo> mborzecki: and with your extra debug we now have state.json and the journal :)
<mborzecki> wow, didn't expect state to be soo full
<pstolowski> morning
<mvo> mborzecki: yeah, same here, it's quite huge
<mborzecki> mvo: hah emacs choked on font-lock-mode when i pasted the contents
<mvo> lol
<mvo> mborzecki: get moar RAM!
<mborzecki> and thanks to pstolowski's snap debug state we have nice info
<mvo> mborzecki: yeah, it's cool
<mborzecki> mvo: https://paste.ubuntu.com/p/KCmBJVjHZH/
<mvo> mborzecki: a nice smoking gun
<mborzecki> mvo: so there's a purge during autorefresh i take
<mborzecki> mvo: but it's a cloud image, so shouldn't there be a refresh.hold set?
<mvo> mborzecki: I think I saw in the logs the previous refresh was 2020-04-28
<mborzecki> mvo: it clearly isn't https://paste.ubuntu.com/p/vxJ2sYZfkN/
<mvo> mborzecki: so maybe we just need to ask cachio to refresh the image
<mvo> mborzecki: indeed
<mborzecki> oh right, it's been more than 60 days?
<mup> PR snapd#8952 closed: tests: enable tests on uc20 which now work with the real model assertion <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8952>
<mvo> mborzecki: yeah, it looks like it (I was looking at the raw json) :/
<mvo> mborzecki: anyway, I think we should also make purge more robust
<mvo> mborzecki: it's a bit of an open question how, not sure my (naive) approach that I proposed works for all cases
<mborzecki> mvo: python tells me 60 days was 27.06
<mvo> oh fun
<mvo> mborzecki: 8951 fails the same way, it really affects our tests
<mborzecki> mvo: hm i guess only cachio can bump the image?
<mvo> mborzecki: yeah, unfortunately
<mborzecki> ok, maybe we can fix purge in the meantime
<mborzecki> mvo: fwiw, the gadget update test failed on uc20
<pstolowski> are you talking about state.Purge()?
<mvo> mborzecki: meh, how so?
<mvo> pstolowski: apt purge snapd
<pstolowski> aaah
<pstolowski> ok
<mvo> pstolowski: that's what we were discussuing :)
<pstolowski> got scared for a moment ;)
<mborzecki> mvo: idk yet, looks like the new files that were suppsoed to be we added by the update are not present, so either the script that modifies gadget.yaml is doing something incorrect or the test needs tweaking
<mvo> mborzecki: ok, keep me updated on this :)
<mvo> mborzecki: I'm inclinded to merge 8933 and just do a followup? wdyt?
<mvo> mborzecki: especially since ian is not around for the rest of the week
<mborzecki> mvo: yeah, i think it's ok, we can open a PR with tweaks separately
<mvo> mborzecki: cool, will do that then
<mup> PR snapd#8933 closed: tests/core/uc20-recovery: apply hack to get gopath in recover mode w/ external backend <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8933>
<mup> PR snapd#8954 opened: tests: tweak comments/output in uc20-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8954>
<pedronis> mvo: there's a new typo in https://github.com/snapcore/snapd/pull/8954
<mup> PR #8954: tests: tweak comments/output in uc20-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8954>
<mvo> pedronis: oh no, silly me, fixing now
<mup> PR snapd#8918 closed: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8918>
<mvo> mborzecki: I just checked the removal hook of lxd, I don't think it needs a working snapd
<mvo> mborzecki: so on purge we could stop snapd first
<mvo> mborzecki: and then do all the stopping/removing of snaps
<mborzecki> mvo: heh, so all structures the 20/pc gadget have edition set to 1 or 2, and the test jsut blindly generates structures with edition 1, so nothing gets updated
<mvo> mborzecki: given that lxd is installed on the 20.04 image we can even test this for real easily :)
<mvo> mborzecki: haha - nice find
<mborzecki> mvo: lxd used to have a stop command that poked lxd to check the reason for stopping
<mvo> mborzecki: indeed, I remember onw
<mvo> mborzecki: hm, so we need to either abort all refreshes before purging or put snapd in some sort of maintenance mode where it does not install/refreshes anything
<mvo> (which we don't have right now)
<mborzecki> mvo: hm in postrm we already do rm -rf /var/lib/snapd, so maybe a problem with with running the postrm from the distro package only?
<mborzecki> mvo: i mean the version that's currently installed in the image
<zyga> re
<zyga> sorry, polari is a terrible terrible IRC client
<zyga> can you guys see my messages now?
<mborzecki> zyga: hahahah, i feel you
<zyga> I was talking all morning
<ogra> hexchat FTW !!
<zyga> but apparently polari didn't care to tell me I was not getting my messages across
<zyga> I even asked you guys what IRC clients you use
<zyga> anyway
<zyga> mvo, mborzecki please just remember that stopping services must be done before unmounting snapd/core
<zyga> (I wrote this a moment ago)
<pstolowski> zyga: works now
<mborzecki> zyga: i've tried polari so many times, disappointment each time
<zyga> thank you Pawel
<mborzecki> zyga: fwiw, try to find the directory where the channel logs are kept :P
<zyga> hot garbage, let me get hexchat
<zyga> in other news, most programs suck at error handling
<mborzecki> mvo: ok, so we ahve prerm which stops all snap.* services, followed by snapd (via dh), then purge runs which removes everything incl /var/lib/snapd followed by dh purge
<mborzecki> mvo: so if purge runs and /var/lib/snapd is removed as the last step, how come it's still there?
<zyga> mborzecki: is stopping lxd really stopping it?
<mborzecki> mvo: maybe purge fails but since we wrap it with quiet there's no logs
<ogra> did you guys see this ? https://forum.snapcraft.io/t/auto-connected-interfaces-disappeared-after-dist-upgrade/18566
<zyga> ogra: I did
<zyga> oh right
<ogra> he was around on the weekend here on IRC
<zyga> pstolowski: I wrote about this but it never got through
<zyga> pstolowski: we should not auto-remove connections from the state
<zyga> pstolowski: if those refer to implicit slots
<zyga> pstolowski: as those are just masking a bug
<zyga> mborzecki: how do I ask hexchat to talk to nickserv
<mborzecki> zyga: idk, isn't that automatic?
<zyga> I cannot even find the setting
<zyga> I don't want to manually authenticate each time I disconncet
<mup> PR snapd#8955 opened: tests/lib/pkgdb: do not use quiet when purging debs <Precious Logs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8955>
<mborzecki> zyga: https://freenode.net/kb/answer/hexchat ?
<zyga> thanks!
<mborzecki> mvo: ^^ 8955
<zyga> hmm
<pstolowski> zyga: oh, hmm
<zyga> test
<zyga> maybe now?
<zyga> pstolowski, can you see this?
<pstolowski> zyga: i can see your messages
<zyga> \o/
<zyga> thanks, and sorry for not being talkative :P
<zyga> how can polari not to any error handing :P
<jamesh> Polari felt kind of half finished when I last tried it
<jamesh> that, plus it used a lot of memory for what it did
<zyga> removing it I noticed it pulled in the whole telepathy/empathy stack
<jamesh> it uses the Telepathy IRC backend, yes.
<mborzecki> jamesh: maybe it's because it relied on gjs
<pstolowski> zyga: what auto-remove of connections do you mean? sorry i'm slow this morning and also fighting conflicts in my branch
<zyga> pstolowski, we have a piece of code that runs on startup
<zyga> pstolowski, if you have a connection in the state
<zyga> pstolowski, but the corresponding plug and slot is gone, we remove the connection from the state
<jamesh> mborzecki: that's probably part of it, but probably not all of it.
<zyga> pstolowski, now let's assume that there's another bug that makes core not have any interfaces on startup
<zyga> pstolowski, (i have an idea what that bug is)
<zyga> pstolowski, when that bug happens, you permanently drop connections
<zyga> pstolowski, like we saw twice now
<zyga> pstolowski, on next boot you will get properly slotted core but the connections will be gone
<mborzecki> jamesh: otoh, it's a nice demo showing how you can actually build an app in javascript for gnome desktop
<pstolowski> zyga: removeStaleConnections ? we only remove if snap is not installed
<zyga> exactly
<zyga> pstolowski, and when core is broken
<zyga> it's bye bye
<zyga> I bet what is going on is that on startup snapd runs before core is mounted
<zyga> I saw that in spread tests a few times
<pstolowski> zyga: right, that could explain it
<zyga> and I don't think there's explicit synchronization anywhere to force that
<zyga> I'll check what happens when a snap is broken
<zyga> we know about it from the state
<zyga> but it's not mounted
<zyga> if we drop connections there then that's a good indicator of what occured
<pstolowski> zyga: thank you, i can help later, need to finish services PR
<zyga> sure
 * zyga returns to gimp for now
<mvo> mborzecki: looking in a bit, in a meeting right now
 * zyga is in love with vscode
<jamesh> zyga: I had a go at porting my dbus-activation-session-legacy test to use a systemd unit to manage the private session bus.  It seems to be hitting the invariant-tool checks though.  Can you think of anything obviously wrong with this? https://github.com/jhenstridge/snapd/blob/dbus-activation-wrappers/tests/main/dbus-activation-session-legacy/task.yaml
<zyga> jamesh: looking
<zyga> hmmm
<jamesh> My understanding is that the unit should have been killed when "systemctl stop" completes, but it looks like the process is live enough for invariant-tool to notice
<zyga> do I read it right that you set up two buses?
<zyga>     eval "$(dbus-launch --sh-syntax)"
<zyga> and     systemd-run --unit=private-session-bus.service \ ...
<zyga> the systemd managed one is surely killed
<zyga> but the dbus-launch one seems to be unmanaged
<zyga> does this make sense?
<jamesh> You are completely correct.  I forgot to delete the code I was converting
<zyga> :D
<jamesh> You happy with managing a private dbus instance through systemd-run otherwise?
<jamesh> I can't really use tests.session for this, since I explicitly don't want a systemd managed dbus-daemon
<zyga> yes, totally
<zyga> I understand, I was wondering about that test myself in a review and then it clicked
<zyga> I'm happy we have the detector
<zyga> as it's one thing to easily leak
<jamesh> As I understand it, this should also make sure any services spawned by the private session bus are reaped too
<zyga> indeed
<jamesh> since they will be considered part of the same systemd level service
<zyga> that's right
<zyga> Just be careful with     eval "$(cat dbus-launch.env)"
<zyga> as it sets the address for the test process as well
<zyga> so you may unexpectedly start using it instead of the normal session bus
<zyga> it's usually not a problem
<jamesh> I want the test processes in that test to use that bus
<zyga> yeah, I know - you could move that eval so that it only affects
<zyga>     test-snapd-dbus-service-client.session | MATCH hello
<zyga> ( eval / source ; run test cmd )
<jamesh> there shouldn't be any other session buses available in that test anyway
<zyga> jamesh: you will get a session bus that's socket activated from PAM of root logging in
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8930 ?
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<mborzecki> mvo: in other news, i think i got the spread test working now, there's been a bit more changes to the gadget.yaml that needed accounting fore in the test :/
 * zyga also got the test right
<zyga> brb, small break
<zyga> re
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/8956 the last commit there
<mup> PR #8956: tests/core/gadget-update-pc: port to UC20 <Precious Logs> <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8956>
<mup> PR snapd#8956 opened: tests/core/gadget-update-pc: port to UC20 <Precious Logs> <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8956>
<ogra> xnox, hey ... seems we have a timedatectl issue on core18 ...
<ogra> ogra@pi4:~$ timedatectl |grep service
<ogra> systemd-timesyncd.service active: no
<ogra> ogra@pi4:~$ systemctl status systemd-timesyncd.service | grep Active
<ogra>    Active: active (running) since Tue 2020-06-30 18:06:18 UTC; 16h ago
<ogra> ogra@pi4:~$
<ogra> not sure why timedatectl reports the service status at all there (it doesnt on any of my non core machines)
<ogra> but it definitely reports it worng ...
<ogra> xnox, want a bug ?
<ogra> xnox, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1885901 is for you
<mup> Bug #1885901: timedatectl reports wrong status for timesyncd in core18 <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <systemd (Ubuntu Focal):New> <systemd (Ubuntu Groovy):New> <https://launchpad.net/bugs/1885901>
<zyga> mvo: thank you for the review
<zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/8938
<mup> PR #8938: sandbox/cgroup: extend SnapNameFromPid with tracking cgroup data <Created by zyga> <https://github.com/snapcore/snapd/pull/8938>
<zyga> just a little bit of help to move the backend branch forward
 * zyga did some improvements to snap-update-ns
<zyga> need some trivial but boring test adjustment
<zyga> but first need some food
<mup> PR snapd#8957 opened: tests: improve nested tests flexibility <Created by mvo5> <https://github.com/snapcore/snapd/pull/8957>
<mup> PR snapd#8958 opened: tests: nested test improvements from master (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8958>
<mvo> zyga 8955 has a log about dbus from the invariant tool
<pedronis> mvo: did the test pass in #8591, it seemed to consistently fail setting up core 20 ?
<mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <Needs Samuele review> <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
<pedronis> mvo: sorry, I meant #8951
<mup> PR #8951: gadget/install: move udev trigger to gadget/install <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8951>
<mup> PR snapd#8951 closed: gadget/install: move udev trigger to gadget/install <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8951>
<mup> PR snapd#8959 opened: gadget,gadget/install: refactor partition table update <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8959>
<mborzecki> zyga-mbp: i've restated the spread jobs in https://github.com/snapcore/snapd/pull/8909 does it need a review from pedronis/mvo?
<mup> PR #8909: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8909>
<pedronis> mborzecki: afaiu it was nacked by security, no?
<pedronis> has that changed?
<mborzecki> pedronis: jdstrand gave +1
<pedronis> mborzecki: ok, I see, I should give it a quick look though
<mborzecki> pedronis: afaiu concerns were raised in a related PR #8926
<mup> PR #8926: Add microstack-support interface <Needs security review> <Created by dshcherb> <https://github.com/snapcore/snapd/pull/8926>
<pedronis> mborzecki: I labeled it
<pedronis> mborzecki: I'll probably merge it myself if it's green and I have double checked it
<mborzecki> pedronis: ok, cool
<pedronis> mborzecki: it's failing on arch atm though?
<mborzecki> pedronis: it's unrelated to the PR, store threw some 400s at some point in mount protocol spread test
<pedronis> ok
<mup> PR snapd#8892 closed: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8892>
<mup> Issue core18#157 opened: timedatectl reports wrong status for timesyncd in core18  <Created by ogra1> <https://github.com/snapcore/core18/issues/157>
<vejmarie> Hi, I am trying to update FreeCAD snap and get an error during the push operation at the end of the uploard. Anybody experiencing the same issue ?
<vejmarie> The error is Bad Gateway 502 after 99% of uploading
<mup> PR snapd#8960 opened: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
<vejmarie> the snap is huge about 570269696
<vejmarie> bytes
<vejmarie> What is the process to report an issue associated with that dashboard ? https://status.snapcraft.io/
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8938 this one?
<mup> PR #8938: sandbox/cgroup: extend SnapNameFromPid with tracking cgroup data <Created by zyga> <https://github.com/snapcore/snapd/pull/8938>
<mvo> pedronis: do you want to review 8946 yourself or do you think a peek at it is sufficient?
<mup> PR snapcraft#3193 closed: extensions: plug the opengl interface for GNOME <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3193>
<zyga> re
<zyga> sorry, had to break to rest
<zyga> mborzecki: yes, that one, it has +2 now
<mborzecki> ah ok
 * zyga hates the moment when the drugs wear out and not kick back in again
<mup> PR snapd#8938 closed: sandbox/cgroup: extend SnapNameFromPid with tracking cgroup data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8938>
 * zyga starts to feel okay
<pstolowski> zyga: great to hear!
<pstolowski> zyga: can you take a look at #8932 again?
<mup> PR #8932: o/ifacestate: update security profiles in connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8932>
<zyga> sure
<zyga> +1
<pstolowski> ty
<mup> PR snapd#8948 closed: cmd/snap-update-ns: detect unmounted mounts <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8948>
<pedronis> jdstrand: when you have a moment, asked a question to unblock: https://github.com/snapcore/snapd/pull/8870#discussion_r448431814
<mup> PR #8870: interfaces: add gconf interface <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8870>
<pedronis> mborzecki: re-reviewed #8930, small comment
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<pedronis> this needs 2nd reviews ^
 * cachio -> doctor app
<pedronis> #8909 just needs to get green
<mup> PR #8909: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs Samuele review> <Needs security review> <Reviewed> <Created by zyga> <https://github.com/snapcore/snapd/pull/8909>
<zyga> woot :)
<pedronis> pstolowski: I updatted #8853
<mup> PR #8853: asserts: introduce the concept of sequence-forming assertion types <Simple ð> <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8853>
<pstolowski> ty, +1
<mup> PR snapd#8961 opened: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8961>
<alvesadrian> is Jamie Strandboge in this channel
<alvesadrian> or Alex Murray
<zyga> adrian-gluu: jdstrand and amurray
<adrian-gluu> @zyga thanks as usuall
<adrian-gluu> @zyga also can you help me with this one https://dashboard.snapcraft.io/snaps/gluu-server/revisions/1/feedback/
<zyga> I don't have permissions for that, sorry
 * zyga reviews assertion sequences 
<jdstrand> zyga: fyi, I answered in the forum. their latest revision passed automated review and they just need to push to a channel
<zyga> jdstrand: thank you for the note
<jdstrand> np
<jdstrand> adrian-gluu: hey
<adrian-gluu> hey
<adrian-gluu> The Snap Store encountered an error while processing your request: bad gateway (code 502).============== ]  99%
<adrian-gluu> The operational status of the Snap Store can be checked at https://status.snapcraft.io/
<jdstrand> noise][, nessita: hey, adrian-gluu is having trouble publishing his revision 3 of https://dashboard.snapcraft.io/snaps/gluu-server to stable ^
<jdstrand> noise][, nessita: https://status.snapcraft.io/ is all green
<adrian-gluu> i will rebuld the snap just in case
<adrian-gluu> because the first erorr that it get was this one
<adrian-gluu> Error while processing...
<adrian-gluu> The store was unable to accept this snap.
<adrian-gluu>   - binary_sha3_384: A file with this exact same content has already been uploaded
<jdstrand> that will happen if you try to snapcraft push the same snap, but it won't affect the snap that is already there
<jdstrand> adrian-gluu: are you using 'snapcraft release' or the web interface?
<adrian-gluu> so / i sorted?
<adrian-gluu> web interface?
<jdstrand> adrian-gluu: the 502 seems like a store side issue, not something you did
<adrian-gluu> i know
<jdstrand> adrian-gluu: I'm sorry are you saying you used 'snapcraft release' or the web inteface (eg, https://snapcraft.io/gluu-server/releases)
<adrian-gluu> am using the cli snapcrat --release
<adrian-gluu> https://snapcraft.io/docs/releasing-your-app
<adrian-gluu> snapcraft upload --release=stable
<adrian-gluu> @jdstrand ^^^^
<jdstrand> adrian-gluu: ah, ok, well, you already uploaded it so you can't again. what you want to do is: snapcraft release gluu-server 3 stable
<jdstrand> degville: there might be a documentation improvement opportunity on https://snapcraft.io/docs/releasing-your-app. that page doesn't mention 'snapcraft release', which might be needed in certain circumstances
<adrian-gluu> @jdstrand from cli? "snapcraft release gluu-server 3 stable"
<degville> jdstrand: thanks! I'll look into it.
<jdstrand> adrian-gluu: yes, eg, wherever you ran your snapcraft upload command, run that one instead
<adrian-gluu> ok
<adrian-gluu> thanks
<adrian-gluu> i'll try that
<jdstrand> degville: in this case, what happened was the first upload failed automated review, a manual review was requested, then other revisions were uploaded, but they were queued behind the manual review. when the revision that ultimately passed automated review went through review, it didn't get published to a channel (that might be a bug that it lost track of the --stable in upload --stable)
<jdstrand> degville: so the only way out would be snapcraft release (or upload a new revision). not that you have to go into all that in the docs, but that is the context
<jdstrand> hence 'certain circumstances' :)
<jdstrand> adrian-gluu: I see now that it is published. yay!
<adrian-gluu> YAY!
<adrian-gluu> is in the store now?
<jdstrand> noise][, nessita: your help is not needed for this, but you may want to investigate on your end the 502
<jdstrand> adrian-gluu: yes
<jdstrand> $ snap find gluu-server
<jdstrand> Name         Version  Publisher  Notes  Summary
<jdstrand> gluu-server  4.1.1    mike-gluu  -      Gluu Server 4.1.1
<degville> jdstrand: that makes complete sense, thanks for the explanation. I'll add a similar example because I think pushing a revision rather than waiting for a manual review is common.
<jdstrand> degville: cool, thanks! :)
<degville> np!
<adrian-gluu> thanks guys
<jdstrand> you're welcome
<jdstrand> pedronis: thanks for the PR feedback in my PRs. I'm going through all of it now
<zyga-mbp> FYI, something fork-bombed our spread runner
<zyga-mbp> I'm recovering it now
<zyga-mbp> we should look, I think that is our fault actually
<zyga-mbp> I will send logs
 * cachio -> kinesiologist
<mup> PR snapd#8962 opened: tests: allow to add a new label to run nested tests as part of PR validation <Run nested> <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8962>
<zyga-x240> everything is operational now and we are burning through the backlog, early analysis seems to indicate that we just ran over capacity, with individual worker nodes using too much memory all in one go
<zyga-x240> I've established memory limits on each container now
<zyga-x240> we may also consider reducing the number of workers a little so we never run over maximum per container * number of containers
<zyga-x240> I will also try to set a global limit on all containers together, so they never eat all the memory
 * zyga-x240 EODs
<zyga-x240> I will check back from time to time to see if anything breaks
<zyga-x240> I also enabled backup capacity to drain the queue faster
<zyga-x240> so we are now at 64 workers
<mup> PR snapcraft#3195 opened: extensions: introduce flutter-master <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3195>
<ijohnson|pto> zyga-mbp: hey o/
<ijohnson|pto> zyga-mbp: you recommended a rpi case / cooling solution a while back that worked really well, do you have a link to that ?
<ijohnson|pto> istr it was passive cooling
#snappy 2020-07-02
<mborzecki> morning
<mup> PR snapd#8868 closed: interfaces: add system-source-code for access to /usr/src <Needs Samuele review> <Reviewed> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8868>
<mup> PR snapd#8909 closed: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs Samuele review> <Needs security review> <Reviewed> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8909>
<zyga> hello
<mborzecki> mvo: zyga: hey
<mvo> mborzecki: good morning
<zyga> FYI we ran out of memory yesterday at 14:00
<zyga> I've set memory caps on each node now
<zyga> we are a bit over-comitted still though
<zyga> gp + node + c# can peak at 500MB for processing text
<zyga> go*
<mborzecki> zyga: gh action runner uses go and node too?
<mup> PR snapd#8955 closed: tests/lib/pkgdb: do not use quiet when purging debs <Precious Logs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8955>
<zyga> mborzecki: it's worse
<zyga> mborzecki: it uses node to "supervise" a c# app
<zyga> which embeds a js intepreter for actions
<zyga> it's like the worst of the ideas together as far as memory goes
<zyga> each container is now running with a hard limit of 512M
<zyga> I will also enable swap as the memory usage is bursty, peak is <500 but average is just 250
<zyga> at the time when it happened we had pretty much the worst case scenario, all workers woke up to process things
<zyga> and at the time they all use the most memory
 * zyga will start in 30
<zyga> meds still kicking in
<mborzecki> zyga: 'enterprise grade'
<zyga> don't give them ideas to add java for logigng
<mborzecki> hahah log4j ftw
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8961#pullrequestreview-441396255
<mup> PR #8961: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8961>
<mborzecki> oh, if you have open PRs, try merging master, some changes that could  help debugging the purge problem landed in the morning
<pstolowski> morning
<mvo> good morning pstolowski
<zyga> mborzecki: ok
<zyga> mborzecki: thank you for the review
<mup> PR snapd#8954 closed: tests: tweak comments/output in uc20-recovery test <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8954>
<zyga> brb, reboot
<zyga> re, had to reboot because touchpad went crazy
<mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/8569 is still blocked on the store side?
<mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<pedronis> mborzecki: yes, still blocked
<mborzecki> ack
<mborzecki> time to read about validation sets
<mborzecki> mvo: quiet swallowed up purge errors? https://paste.ubuntu.com/p/49jNNMjb4P/
<mvo> mborzecki: in a meeting still but will look in a sec
<mvo> mborzecki: wuut, why is this not a real error?
<mup> PR snapd#8963 opened: tests: rename invariant-tool to tests.invariant <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8963>
<zyga> maybe quiet bug
<zyga> or bug in our packaging helper functions
<mborzecki> i mean a trvial `quiet sh -c 'echo foobar; false'` works as expected, prints the error output
<zyga> mborzecki: maint script -e ?
<mborzecki> heh, so more than one prepare failed: https://paste.ubuntu.com/p/j9wsRWHxJw/
<mborzecki> one purge succeeded in the snse that apt did not return an error but /var/lib/snapd was still there
<mup> PR snapd#8964 opened: tests: rename version-tool to version-compare <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8964>
<mborzecki> this is nice: dpkg: warning: while removing snapd, directory '/var/lib/snapd/apparmor' not empty so not removed
<mborzecki> and that's right after purge
<zyga> mborzecki: rm -f
<zyga> I cannot do that Dave
<mup> PR snapd#8965 opened: tests: rename memory-tool to memory-observe-do <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8965>
<zyga> popey: o/
<mup> PR snapd#8966 opened: tests: rename mountinfo-tool to mountinfo.query <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
<zyga> popey: do you know who should I talk to so to get browser snaps to adopt a new interface?
<zyga> popey: they context is this bug https://bugs.launchpad.net/snapd/+bug/1875860/comments/3
<mup> Bug #1875860: local documentation is not accessible from the chromium snap <regression> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1875860>
<mup> PR snapd#8967 opened: tests: rename apt-tool to apt-state <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8967>
 * zyga found a bug in apt-state (nee apt-tool)
<zyga> drat, I'm out of disk space
<zyga> sight
<zyga> sigh even :)
<mborzecki> mvo: merged master and pushed a little tweak to #8883
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mvo> mborzecki: thank you
<zyga> pedronis: since README was added we grew one more helper, cleanup-state, I'm inclined to keep it off of PATH and just keep the current name, WDYT?
<pedronis> zyga: seems fine at least for now
<zyga> ok
<zyga> it's used in one file in three places IIRC
<popey> zyga oSoMoN maintains chromium, kenvandine can help with firefox.
<zyga> popey: superb, thank you!
<popey> np
<zyga> do you know anyone from brave?
<zyga> oSoMoN, kenvandine: can you please look at https://bugs.launchpad.net/snapd/+bug/1875860/comments/3 or point me to the sources, I'm happy to send PRs that edit the snapcraft.yaml
<mup> Bug #1875860: local documentation is not accessible from the chromium snap <regression> <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1875860>
<oSoMoN> zyga, cool, I'll add the plug to chromium, thanks! how will this work for earlier versions of snapd, are unknown plugs silently ignored?
<zyga> oSoMoN: unknown interfaces are sliently ignored
<zyga> *silently
<zyga> but please ask jdstrand to ensure that the interface is recognized by review-tools
<zyga> mvo: that's something for you, just one line, https://github.com/snapcore/snapd/pull/8968
<mup> PR #8968: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8968>
<mup> PR snapd#8968 opened: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8968>
<mvo> zyga: thanks, in a meeting
<zyga> sure
 * zyga will return to reviews and push forward on branches after a small break
<mup> PR snapd#8853 closed: asserts: introduce the concept of sequence-forming assertion types <Simple ð> <validation-sets :white_check_mark:> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8853>
<mborzecki> pedronis: since 8853 landed, i've merged master to #8906
<mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<zyga-x240> mborzecki: do you think we can do something about the centos8 failing test
<zyga-x240> maybe mark it as xfail
<zyga-x240> and only fail if it passes, so that we know
<mborzecki> zyga-x240: let me look at that test today, wanted to tweak it to make the calls to ausearch smarter
<zyga-x240> thanks!
<ogra> xnox, here is another one forwarded from my custmer https://github.com/snapcore/core18/issues/158 (i'd pay your beer/drinks for the whole next sprint we meet if you'd have an idea how we get rid of all that timedatectl hackery once and for all btw)
<mup> Issue core18#158 opened: quoting fix for timedatectl wrapper got lost between core16 and core18 <Created by ogra1> <https://github.com/snapcore/core18/issues/158>
<mup> PR core18#159 opened: 030-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <https://github.com/snapcore/core18/pull/159>
<mup> Bug #1886033 opened: end.psplash.service results in failed state on UC18 devices <Snappy:New> <https://launchpad.net/bugs/1886033>
<xnox> ogra:  customers must use salesforce, and escalate to foundations using that.
<xnox> ogra:  pinging me directly is not the right process.
<xnox> ogra:  plus i don't maintain systemd =/ and most of srus are handled by sts anyway.
<xnox> ogra:  what is the correct process for escalations?
<ogra> well, sorry ... deadline is near and customer works directly with me on a daily basis
<ogra> this is a general bug though, affecting all core18 users, ignore that i'm saying "customer" all the time
<xnox> ogra:  ok, so there is no SLA for it, right?
<ogra> well, they are probably the first user we have not using the network at all, so this went unnoticed until someone needs to set the time manually ... there are SLAs but i'm helping them to work around the issues ... but along the way i capture them in bugs
<ogra> ... so we get general fixes ...
<xnox> ogra:  also i don't even have commit access to core18
<xnox> ogra:  so really i'm not the droid you are looking for
<xnox> =(
<ogra> wow
<ogra> i thought you're da man for core18 onwards
<ogra> sorry then ð
 * xnox only did core20 & ubuntu-core-initramfs => but even that I can't really release much, as it's kernel team that vendorize my initrds.
<ogra> while i get why we do this it would really be halpful to have one master person owning it ...
<ogra> someone who supervises the whole of UC
<pedronis> mborzecki: thanks
<zyga-x240> rere
<mborzecki> damn, can't seem to be able merge any of my PRs today, random tests failing
<zyga-x240> thank you for the reviews everyone!
<zyga-x240> mborzecki: use the force, ask mvo
<zyga-x240> but yeah, I have some failures in each PR
<mborzecki> duh, last one: rror restoring google:ubuntu-core-20-64:tests/lib/tools/suite/tests.session:root (jul021038-575770) : read tcp 10.113.57.72:47444->34.73.187.217:22: use of closed network connection
<mborzecki> mvo: can you merge https://github.com/snapcore/snapd/pull/8930 ?
<mup> PR #8930: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8930>
<zyga-x240> hmmm
<zyga-x240> mborzecki: nothing in logs, maybe just bad day wrt traffic?
<mborzecki> zyga-x240: idk, maybe the host just died (?)
<zyga-x240> mborzecki: maybe we did run out of memory but this time i a more reliable way
<zyga-x240> mborzecki: let's see how it behaves, I can tweak things later today
<zyga-x240> mborzecki: I'm still thinking if I should add swap
<mborzecki> zyga-x240: oom again?
<zyga-x240> mborzecki: well, it's a heavy stack
<mborzecki> heh
<zyga-x240> mborzecki: but I have no proof of that, no oom in logs
<zyga-x240> mborzecki: we're at 4.35/8GB now
<zyga-x240> so hardly oom
<zyga-x240> mborzecki: can you do a pass over the green rename PRs pleaes
<zyga-x240> I'd love to merge them and they have mostly one review
<zyga-x240> er, only one green tick
<zyga-x240> woah, core20 tests took 104 minutes
<zyga-x240> https://github.com/snapcore/snapd/pull/8965
<mup> PR #8965: tests: rename memory-tool to memory-observe-do <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8965>
<zyga-x240> I'm sure glad we're not with the enforced 60 minute limit anymore
<mup> PR snapd#8930 closed: many: managed boot config during run mode setup <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8930>
<mborzecki> mvo: thank you!
<mvo> mborzecki: my pleasure
<mup> PR snapd#8967 closed: tests: rename apt-tool to apt-state <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8967>
<mborzecki> https://github.com/snapcore/snapd/pull/8956 is no longer blocked and needs reviews yay
<mup> PR #8956: tests/core/gadget-update-pc: port to UC20 <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8956>
<pstolowski> cachio: hi, is nested/preseed test happy these days?
<cachio> pstolowski, hi
<cachio> let me check
<cachio> pstolowski, yes, at lest last night passed
<cachio> 19.10 and 20.04
<pstolowski> ok, ty
 * zyga-x240 is dizzy after meds
<mborzecki> cmatsuoka: hi, is https://github.com/snapcore/snapd/pull/8919 ready for reviews?
<mup> PR #8919: gadget/install,secboot: test if the tpm can be provisioned <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8919>
<cmatsuoka> mborzecki: I'm verifying if the status flags are correct, the results on the real tpm are a bit strange
<cmatsuoka> mborzecki: I would expect the EK bit to be set, but I get the DA bit instead after clearing the tpm
<cmatsuoka> mborzecki: also chris is considering to change the way the status is reported
<mup> Issue core18#160 opened: end.psplash.service results in failed state on UC18 devices <Created by jocave> <https://github.com/snapcore/core18/issues/160>
<zyga-x240> random test panic on master: https://paste.ubuntu.com/p/jQVhDFFnjm/
<zyga-x240> ... Panic: cannot add test assertions: model assertion timestamp outside of signing key validity (key valid since "2020-07-02 12:20:44 +0000 UTC") (PC=0x42F2F4)
<zyga-x240> Thu, 02 Jul 2020 12:25:16 GMT PANIC: api_users_test.go:734: userSuite.TestPostCreateUserFromAssertionNoModel
<zyga-x240> (note that the first timestamp is from github and uses GMT while the second one uses UTC)
<zyga-x240> are those the same?
<zyga-x240> the failure comes from https://github.com/snapcore/snapd/pull/8964/checks?check_run_id=830484471 which is entirely unrelated
<mup> PR #8964: tests: rename version-tool to version-compare <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8964>
<zyga-x240> pedronis: ^ perhaps something you are interested in
<Psil0Cybin> hey folks, quick question i have an app i want to install, seems like the app creators do not have atar.gz file or anything similar they require people to install the software via snapd, does it make sense to install snapd just for one piece of software?
<oerheks> Psil0Cybin, yes, if you want this software
<Psil0Cybin> ok since im new to this concept of snap is it just a repo, or if its running a daemon is it communicating with the web 24/7?
<oerheks> snapd just checks one a day for updates, in the background when you start a snap.
<oerheks> nothing funny about that.
<mborzecki> mvo: the failures in prepare are in https://github.com/snapcore/snapd/pull/8883/
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<Psil0Cybin> oerheks, okay thanks
<Psil0Cybin> Just wanted to learn, I mostly like to keep my linux box's as minimal as possible , thats why I just got confused what "snapd" is technically since we already have repos, or the software center in terms of Ubuntu.
<mvo> mborzecki: thank you, looking in a bit. fwiw quiet.sh looks a bit suspicous, I would not be surprised if it mishandles exit
<oerheks> see snapd as the new PPA, but for all distros that support snapd
<oerheks> easier distribution, maor control.
<mborzecki> mvo: othing obviously wrong there though
<mvo> mborzecki: uh, it looks all wrong actually
<mup> PR snapd#8963 closed: tests: rename invariant-tool to tests.invariant <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8963>
<zyga-x240> I've reproduced the connection dropping issue now
<zyga-x240> the only mystery is why we have broken core
<mvo> mborzecki: it's not all wrong, I misread
<zyga-x240> I will look at how that works next
<zyga-x240> opensuse 15.2 is released
<zyga-x240> mborzecki, mvo: so is quiet.sh buggy?
<zyga-x240> can we rewrite it in python yet?
<mborzecki> zyga-x240: i'm not quite sure it's buggy, doesn't look like it
<mborzecki> but hey, it's shell, so who knows ;)
<zyga-x240> haha, right :)
<zyga-x240> I'm just curious to learn what it was in the end
<zyga-x240> I'm digging another issue
<mborzecki> zyga-x240: from what i can tell, is that we do systemctl stop  ... snapd.service .. in prerm (with a batch of services in one go), but later when postrm runs, snapd appears to be still running
<zyga-x240> hmmm
<luisp> :sp
<luisp> (sorry, wrong window)
<mup> PR snapd#8965 closed: tests: rename memory-tool to memory-observe-do <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8965>
<mborzecki> time to run some errands
<jdstrand> pstolowski: hey, just checking that my comment on PR 8939 made sense
<mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<jdstrand> (about static devices)
<zyga-x240> jdstrand: thanks for that, I missed this
<zyga-x240> jdstrand: the rewrite I did handled that case differently and I didn't remember how it worked here before
<zyga-x240> jdstrand: I will spend some time to polish the rewrite so that we can merge it
<pstolowski> jdstrand: yes, thank you! i looked at systemd/udevd code with hope of finding something special about these devices but couldn't find anything. your suggestion sounds very sensible, i'll change this
<jdstrand> cool :)
<jdstrand> pstolowski: fyi, I made a teensy update to the initialization suggestion (see https://github.com/snapcore/snapd/pull/8939#pullrequestreview-441127367)
<mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<pstolowski> jdstrand: ack, thanks for that
<jdstrand> pstolowski: their not special in the sense of the system, but they are special in how snapd handles them, since we expect every snap to have them, we don't need to tag them
<jdstrand> their? they're*
<jdstrand> pstolowski: and since we aren't tagging them, we don't need the udev lookup up either and https://www.kernel.org/doc/Documentation/admin-guide/devices.txt defines these for everyone, so we can just hard code
<jdstrand> anyhoo, thanks! :)
<pstolowski> jdstrand: yes, your suggestion makes sense regardless of the race problem
<jdstrand> pstolowski: I got bonus points! :)
<jdstrand> I mean, if the sys path udev lookup was not racy (like we thought it was), it's fine, but yeah, I like not having to hit the library for those 8 devices
<zyga-x240> https://github.com/snapcore/snapd/pull/8966 needs a second review
<mup> PR #8966: tests: rename mountinfo-tool to mountinfo.query <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
<jdstrand> oh, I can now say I contributed to performance speedups :)
<zyga-x240> jdstrand: about this, do you think you will have time to spend with me next week on this?
 * jdstrand shaved 0.0037 seconds off of startup
<jdstrand> zyga-x240: I'm sorry, what is 'this'?
<jdstrand> zyga-x240: the snap-device-helper rewrite?
<zyga-x240> jdstrand: ah, sorry, I mean the rewrite of snap-confine that changes how we use snap-device-helper:
<zyga-x240> https://github.com/snapcore/snapd/pull/7614
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga-x240> I kind of left it there but I think it's close and should be resurrected
<jdstrand> zyga-x240: next week? doubtful due to the sprint. I also need to help joedborg, et al (eg, maybe Ian) on figuring out why microk8s isn't working right in devmode and to help the openstack team with microstack interfaces
<zyga-x240> jdstrand: ok, in that case I'll just polish it and refresh a bit and try to grab you after the sprint
<jdstrand> zyga-x240: iirc, PR 7614 is not roadmapped so it is going to have to fall behind these other two... unless you can convince amurray to work with you on it (amurray, if so, recall that I'd like to do a final review before committing)
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<jdstrand> zyga-x240: note, I'm off Mon and Tue the week after the sprint and will be focusing on microk8s and microstack at least into the next week. if the snap-device-helper stuff is roadmapped and/or this is blocking other stuff, please talk to mvo and we can all discuss with joeubuntu and amurray the next steps
<pstolowski> zyga-x240: what version of clang-format do you use for snap-confine? v10 isn't happy about our .clang-format
<zyga-x240> pstolowski: hmmm, good question
<zyga-x240> pstolowski: try make fmt
<zyga-x240> it's not one formatter
<zyga-x240> some files use indent, others use clang-format
<zyga-x240> pstolowski: it's not perfect so I gave up on it somewhat
<zyga-x240> pstolowski: I think using clang-format would be good but I don't want to force re-format everything
<pstolowski> zyga-x240: that's fine. i was worried about tests failing on format, but it seems we don't do that for C code
<zyga-x240> no, it's disabled now
<zyga-x240> https://github.com/snapcore/snapd/pull/8966 needs a second review
<mup> PR #8966: tests: rename mountinfo-tool to mountinfo.query <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8966>
 * cachio lunch
<oSoMoN> jdstrand, does the system-packages-doc plug need to be added to review-tools for snaps using it to pass review?
<pstolowski> zyga: i've requested your re-review of #8939 due to ths change
<mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<zyga-x240> re
 * zyga-x240 put his thinkpad into the freezer 
<pstolowski> zyga-x240: it seems #8961 can land
<mup> PR #8961: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8961>
<mup> PR snapd#8961 closed: cmd/snap-update-ns: handle anomalies better <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8961>
<mup> PR snapd#8966 closed: tests: rename mountinfo-tool to mountinfo.query <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8966>
<mup> PR snapd#8968 closed: tests: fix call to apt.Package.mark_install(auto_inst=True) <Bug> <Simple ð> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8968>
<cachio> pedronis, hey, I already updated the #8949, could you please take a quick look to see if we can unblock it? thanks
<mup> PR #8949: tests: new fs-tool which replaces the files.sh helper <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
<pedronis> cachio: I don't have time to do a full review but the name is good, so unblocking it
<pedronis> cachio: I made a comment also in #8950
<mup> PR #8950: tests: new str-tool which replaces the strings.sh helper <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
<cachio> pedronis, thanks
<mup> PR snapd#8969 opened: tests: fix argument handling of apt-state <Created by zyga> <https://github.com/snapcore/snapd/pull/8969>
<mup> PR snapd#8970 opened: tests: rename user-tool to user-state, fix --help <Created by zyga> <https://github.com/snapcore/snapd/pull/8970>
<mup> PR snapd#8971 opened: tests: rename lxd-tool to lxd-state <Created by zyga> <https://github.com/snapcore/snapd/pull/8971>
<zyga-x240> all the tools are converted now, we just need to land this
<zyga-x240> then we can drop tests/lib/tools from PATH
 * zyga-x240 will EOD soon
<jdstrand> oSoMoN: it does, yes. I can add it (note, system-packages-doc will be 2.46 (ie, it isn't in stable yet)
<oSoMoN> jdstrand, I know, zy_ga pinged me earlier about it, and I'm preemptively adding the plug to the chromium snap, under the assumption that it will be silently ignored with older versions of snapd
<jdstrand> oSoMoN: we can do maunual approvals in the meantime, but if it is for something with a lot of revisions, we might want to wait
<jdstrand> oSoMoN: I can add it today and request a store pull, but that likely won't happen until late next week
<oSoMoN> jdstrand, I'm happy to revert the change until review tools are ready for it
<jdstrand> 'that' meaning, it won't be in prod until late next week at the earliest, with it being a sprint, that is probably actually the week after
<jdstrand> oSoMoN: I'll add it and get the ball rolling
<oSoMoN> jdstrand, cheers!
 * zyga-x240 adds a highlighter for zy_ga -- just in case ;-)
<oSoMoN> jdstrand, I reverted the change in the chromium snap, please ping me when I can revert the revert (when the updated review tools are in prod), thanks!
<mup> PR snapd#8964 closed: tests: rename version-tool to version-compare <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8964>
<jdstrand> oSoMoN: ok, thanks :)
 * cachio afk
<zyga-x240> mvo: I will EOD now but
<zyga-x240> https://github.com/snapcore/snapd/pull/7825 is ready for another review
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga-x240> I think we could land it and I will iterate, there are some TODOs for more spread tests
<zyga-x240> but having it in master will let us get closer to what we wanted
<zyga-x240> plus would look nice next week
<zyga-x240> https://github.com/snapcore/snapd/pull/7700 and https://github.com/snapcore/snapd/pull/8573 also need reviews
<mup> PR #7700: cmd/snap: wait while inhibition file is present <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
<zyga-x240> mvo: lastly from refresh app awareness pipe, https://github.com/snapcore/snapd/pull/8941 is simple and needs a 2nd review
<mup> PR #8941: sandbox/cgroup: avoid parsing security tags twice <Created by zyga> <https://github.com/snapcore/snapd/pull/8941>
<zyga-x240> with that, I'll EOD now
<pedronis> zyga-x240: not sure I will get to review #7825 this week
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Needs security review> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga-x240> take care everyone!
<zyga-x240> pedronis: I understand
<zyga-x240> pedronis: I have things to do so after you're back in a week there will be lots of snapctl PRs for the missing bits
<zyga-x240> pedronis: and I'll complete spread tests for hooks and services as ewll
<zyga-x240> *well
<zyga-x240> have a good evening everyone!
<zyga-x240> pedronis: it would help more if you give me guidance on the other two PRs
<zyga-x240> pedronis: as those are more of an open direction still
<zyga-x240> pedronis: but again, I understand if that needs to wait until after next week
<mup> PR snapd#8941 closed: sandbox/cgroup: avoid parsing security tags twice <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8941>
<mup> Issue core18#161 opened: mknod: /home/ubuntu/core18/parts/boostrap/install/dev/null: Operation not permitted <Created by WillNilges> <https://github.com/snapcore/core18/issues/161>
<mup> PR snapcraft#3186 closed: Riscv64 support <enhancement> <Created by xnox> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3186>
<mup> PR snapcraft#3196 opened: cli: unset false boolean flags in environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3196>
<mup> PR snapcraft#3197 opened: experimental extension support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3197>
<mup> PR snapd#8972 opened: gadget/install,secboot: use snapcore/secboot luks2 api <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8972>
<mwhudson> hm why are all the snapd developers in europe :)
<oerheks> mwhudson, how do you tell ? https://snapstats.org/
<mwhudson> oerheks: i mean *snapd* developers specifically, not people who develop snaps
#snappy 2020-07-03
<mup> PR snapcraft#3196 closed: cli: unset false boolean flags in environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3196>
<mup> PR snapd#8973 opened: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8973>
<mborzecki> morning
<mup> PR snapd#8870 closed: interfaces: add gconf interface <Needs Samuele review> <Reviewed> <Created by jdstrand> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8870>
<mup> PR snapd#8970 closed: tests: rename user-tool to user-state, fix --help <Simple ð> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8970>
<pstolowski> mor ning
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<pstolowski> o/
<mborzecki> mvo: good morning to you too
<mup> PR snapd#8971 closed: tests: rename lxd-tool to lxd-state <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8971>
<mvo> mborzecki: and to you :)
<mborzecki> mvo: can you reopen https://github.com/snapcore/snapd/pull/8883 ? wanted to restart the spread jobs, but i can't reopen after closing it
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8883>
<mborzecki> mvo: oh w8, nvm, i can ;P
<mborzecki> mvo: fwiw, the spread job was suprisingly green (?), wanted to double check if that's a fluke or that last commit actually changed the net effect of prerm
<zyga-x240> good morning
<pstolowski> hey zyga-x240 ! online already?
<zyga-x240> hey
<zyga-x240> yeah, I'm waiting
<pstolowski> got it
<zyga-x240> I'll be back again after 14-15 probably
<zyga-x240> I may be at the standup
<pstolowski> zyga-x240: can you re-ack #8939? it got +1 from Jamie
<mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<zyga-x240> yeah, let me look
<mvo> mborzecki: oh, nice
<mvo> mborzecki: keep me updated :)
<zyga-x240> pstolowski: +1
<pstolowski> ty
<mup> PR snapd#8969 closed: tests: fix argument handling of apt-state <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8969>
<pstolowski> mvo: i suppose we may want #8839 for a point release, in which case it's best to squash-merge?
<mup> PR #8839: tests: add debug for 20.04 prepare failure <Test Robustness> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8839>
<jamesh> alan_g: https://github.com/snapcore/snapd/pull/8699#issuecomment-653401466
<mup> PR #8699: interfaces/desktop-launch: support confined snaps launching other snaps <Needs Samuele review> <Needs security review> <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<jamesh> ^^ I put together a simple spread test to get you started
<mvo> pstolowski: 8839 the debug stuff? I don't think we need it for the point release I htink we know wha tis wrong
<pstolowski> mvo: grr i meant #8939, sorry
<mup> PR #8939: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<mvo> pstolowski: oh, yeah, that for sure
<mup> PR snapd#8939 closed: snap-confine: don't die if a device from sysfs path cannot be found by udev <Bug> <Needs security review> <Security-High> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8939>
<mup> PR snapd#8974 opened: spread.yaml: remove tests/lib/tools from PATH <Created by zyga> <https://github.com/snapcore/snapd/pull/8974>
<alan_g> jamesh, thanks. I'll try to get to it next week. (Depending how busy the sprint gets.)
<mup> PR snapd#8975 opened: tests: shorten lxd-state undo-mount-changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8975>
<mup> PR snapd#8976 opened: snap-confine: don't die if a device from sysfs path cannot be found by udev (2.45) <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8976>
<pstolowski> hmmm, ^ this fails against 2.45 with 'packaging/debian-sid/changelog:6:18: "miscellanious" is a misspelling of "miscellaneous
<zyga-x240> pstolowski: fix the typo :)
<zyga-x240> pstolowski: it's okay
<pstolowski> zyga-x240: yeah, but same change just landed in master (and the typo is not in my PR)
<zyga-x240> yeah but if it's landing to a release branch it should be fixed there
<zyga-x240> not sure why it wasn't picked up before
<pstolowski> ok
<zyga-x240> fixing masteri s also good
<pstolowski> ok, master is good, the typo is only in 2.45
<pstolowski> pushed a fix to my PR
<zyga-x240> super, thank you :)
<zyga-x240> I've broken out another chunk of refresh-app-awareness https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mup> PR snapd#8977 opened: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/8883 did not fail in prepare for the 2nd time in a row
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mborzecki> errand, back in 1h
<zyga-x240> https://github.com/snapcore/snapd/pull/8975 needs a second review, +/- 13 lines
<mup> PR #8975: tests: shorten lxd-state undo-mount-changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8975>
<zyga-x240> and the super short https://github.com/snapcore/snapd/pull/8974 completes the tools transition
<mup> PR #8974: spread.yaml: remove tests/lib/tools from PATH <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8974>
<zyga-x240> pedronis: after ^ the README file needs changing, let me know if you want to do that yourself
 * zyga-x240 goes to the doctor now
<zyga-x240> see you later, if I make it back in time for the standup
<mvo> mborzecki: nice
<mborzecki> re
<mborzecki> mvo: so https://github.com/snapcore/snapd/pull/8883 passed for the 3rd time, maybe it's the righ fix after all
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mvo> mborzecki: nice!
<mvo> mborzecki: yeah, let's go with it, we should probably squash it
<mborzecki> mvo:  will do
<mvo> mborzecki: thank you!
<mup> PR snapd#8975 closed: tests: shorten lxd-state undo-mount-changes <Simple ð> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8975>
<ogra> regarding https://bugs.launchpad.net/snapd/+bug/1881588 ...
<mup> Bug #1881588: pre-seeding lxd on Core appliances breaks console-conf user creation <id-5ef638e8ed708765e909cfe8> <snapd:Invalid by anonymouse67> <subiquity:In Progress
<mup> by mwhudson> <subiquity (Ubuntu):Invalid> <subiquity (Ubuntu Xenial):Confirmed> <subiquity (Ubuntu Bionic):Confirmed> <https://launchpad.net/bugs/1881588>
<ogra> what exactly makes snapd decide that a system is managed ?
<ogra> i thought this only happens if "snap create-user" was used ?
<ogra> (seems lxd simply calls useradd chrooted into /var/lib/snapd/hostfs at runtime ... which as i understand should not mark the system as managed)
<pedronis> snap managed true means we have users in auth (over time it will mean other things), that's all there is to it
<pedronis> as discussed in the bug there's just some confusion around it and what the console-conf logic does
<pedronis> afaiu
<ogra> ah, i always thought there is an extra setting
<ogra> i.e. a flag the create-user sets
<pedronis> no there's a flag for the reverse to let you create users even there are already some
<ogra> well, the managed check should ignore users below UID 1000 i think
<pedronis> there's no bug in snapd
<pedronis> we don't check users on the system
<pedronis> we check users only inside snapd
<pedronis> there's just confusion
<ogra> (the first non-system user definitely gets 1000)
<ogra> hmm, k
<pedronis> it's all based on len(auth.Users(state)), that code doesn't consider anything on disk, but the state in snapd
<ogra> ok
<mborzecki> mvo: with some commits dropped and others squashed it's passing again https://github.com/snapcore/snapd/pull/8883 (and needs reviews)
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mvo> mborzecki: nice
<zyga-x240> re
<zyga-x240> back just in time
<mup> PR snapcraft#3198 opened: snap: drop legacy, switch to core20 for bootstrap <Created by xnox> <https://github.com/snapcore/snapcraft/pull/3198>
<zyga-x240> cachio: https://github.com/snapcore/snapd/pull/8973#pullrequestreview-442392657
<mup> PR #8973: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8973>
<zyga-x240> nice work!
<mup> PR snapcraft#3195 closed: extensions: introduce flutter-master <enhancement> <specification> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3195>
<zyga-x240> https://github.com/snapcore/snapd/pull/8974 is green, it's super short and completes the tool transition
<mup> PR #8974: spread.yaml: remove tests/lib/tools from PATH <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8974>
<zyga-x240> mborzecki: https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md
<zyga-x240> mborzecki: pi bootloader has support for gpio directly
<zyga-x240> mborzecki: perhaps we could use that as well
<mborzecki> zyga-x240: yeah, dave pointed me to that doc too
<zyga-x240> specifically, you can make decisions on those
<mborzecki> zyga-x240: need to do some reding, but we still may need to go through uboot for the extra integration we do with snapd
<pedronis> mvo: sorry, battery got empty (though it was telling me I had a few more minutes)
<mvo> pedronis: no worries
<mvo> pedronis: we just finished anyway, I was just rambling
 * zyga-x240 is sorry for shaking the laptop so much, 90C is really hot
 * zyga-x240 reboots to fix touchpad
<zyga-x240> re
<zyga-x240> again, fridge helps :)
<zyga-x240> pstolowski: https://github.com/snapcore/snapd/pull/8960 nice commit message
<mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
<pstolowski> zyga-x240: thanks, trying to help as much as possible with reviews ;)
<zyga-x240> :)
<mup> PR snapcraft#3199 opened: extensions: introduce flutter-dev <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3199>
 * zyga-x240 needs a coffee 
<cachio>  /me lunch
<mup> PR snapcraft#3200 opened: flutter v1 plugin: pull from source-subdir if set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3200>
<mvo> sil2100: sorry for bothering you with snapd SRU topics, but AIUI the validations is fully done and I wonder if we can release snapd to -updates? maybe monday (I understand friday is a bad time)
<mup> PR snapcraft#3199 closed: extensions: introduce flutter-dev <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3199>
<mup> PR snapd#8978 opened: secboot: update tpm connection error handling <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8978>
#snappy 2020-07-04
<mup> PR snapcraft#3200 closed: flutter v1 plugin: pull from source-subdir if set <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3200>
<mup> PR snapcraft#3201 opened: pyinstaller: workaround pkg_resources issue <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3201>
<mup> PR snapcraft#3201 closed: pyinstaller: workaround pkg_resources issue <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3201>
<mup> PR snapd#8860 closed: overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/8860>
<dariball> heyall, can someone guide me where to find the sources for the ubuntu appliances, like https://ubuntu.com/appliance/plex
<ogra> dariball, the appliances are simply ubuntu core with one snap preinstalled ... ubuntu core consists of three snap packages (kernel, gadget, core18 (the rootfs)) plus ... in the case you linked .. the plex-media-server snap
<ogra> (here is a blogpost about that https://snapcraft.io/blog/split-personality-snaps )
<dariball> ogra: ah ok thank you also just saw ubuntu-image, this is likely what was used to actually create the image, right?
<ogra> the only actual source you need to have is a model assertion defining the default snaps: https://docs.ubuntu.com/core/en/guides/build-device/image-building
<ogra> if you want it a little more complex : https://ograblog.wordpress.com/2019/01/07/291/ :)
<dariball> ahh great, awesome, many thanks!
