#snappy 2015-05-18
<dholbach> good morning
<Chipaca> mo'in
<Chipaca> are we there yet?
<D_Cent> hi - can someone please tell me what happens to the app data in /var/lib/apps/<package name>/<version> if i update the package with snappy to a newer version? will the directory be renamed from e.g. 0.1 to 0.2 or will all app data get lost?
<JamesTait> Good morning all; happy Monday, and happy No Dirty Dishes Day! ð
<vmayoral|pc> Good morning everyone
<vmayoral|pc> any chance someone can review snap 2662?
<Chipaca> D_Cent: hi
<Chipaca> D_Cent: the services in the snap are stopped, the data is copied to the new version, the new version is made current, and its services started
<Chipaca> JamesTait: http://i.imgur.com/E1trXyD.gif
<Chipaca> JamesTait: and good morning :)
<JamesTait> Chipaca, that's mesmerising.
<JamesTait> Chipaca, and good morning, too. âº
<Chipaca> JamesTait: i too could watch people work for hours
<JamesTait> Chipaca, I see now that I've been washing the dishes all wrong.
 * ogra_ would like to see the other end of the machine ... and the guy who juggles them til they are dry
<Chipaca> ogra_: here you go: http://www.awardsdaily.com/wp-content/uploads/2012/10/cloud.jpg
<ogra_> lol
<Chipaca> âthe UI for Ubuntu Core is provided via web apps written for webdmâ
<Chipaca> that's interesting
<Chipaca> not connected to any reality i'm aware of, but interesting nonetheless
<ogra_> well, if snappy config is hooked into webdm thats not completely untrue
<Chipaca> darn, and i just sent an email saying it was
<Chipaca> untrue, that is
<ogra_> well, it isnt like he imagines ... so thats fine
<Chipaca> feel free to expand on my rather curt email :)
 * ogra_ glares at http://127.0.0.1:4200/snap/8nzc1x4iim2xj1g2ul64.chipaca/ in his webdm 
<ogra_> creative naming :)
<Chipaca> yeah, let's call it that
<Chipaca> ogra_: hopefully the description makes it all clear
<ogra_> hmm, seems my webdm instance doesnt show any descriptions at all ... now that you mention it ...
<ogra_> the details page just has the icon
<Chipaca> ogra_: ah, i guess it's the title, not the description
<Chipaca> ogra_: but: https://uappexplorer.com/app/8nzc1x4iim2xj1g2ul64.chipaca
<Chipaca> ogra_: the description is also enlightening
<ogra_> heh
<D_Cent> Chipaca: thanks for your answer previously :)
<Chipaca> D_Cent: that's what we do. ogra_ with his good looks, me with my on-point answers.
 * Chipaca goes find lunch
<lool> lunch? are you in Europe?
<Chipaca> lool: that depends on who you ask
<Chipaca> lool: i'm in the uk
<lool> oh ok
<Chipaca> lool: have been for >4 years now
<lool> Chipaca: for some reason I associate you with a later timezone  :-)
<Chipaca> lool: for my first 3+ years in canonical, i was :)
<rickspencer3> does anyone know how I can use a wifi dongle with snappy? i.e. connected to a usb port on a board?
<asac> rickspencer3: there is a hacky way documented here: http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html
<asac> we dont have a neat net management framework yet
<lool> actually wpasupplicant should be in the rootfs now
<asac> it is
<lool> so you just need to bottom part
<asac> yeah so you dont need to install anything :)
<lool> we need to snap network-manager and/or connman etc.
<rickspencer3> lool, how hard would it be for someone to add a configuration page to webdm for wpasupplicant?
<rickspencer3> seems like it could go into the store
<rickspencer3> the user plugs their board into the local wired network
<rickspencer3> navigates to ubuntu@webdm.local:nnnn
<rickspencer3> sets up wifi
<rickspencer3> oops
<beuno> rickspencer3, it probably couldn't easily go into the store, as it would require special access (to change the wifi config)
<lool> it's not the target user experience
<rickspencer3> forgot the step of granting permissions
<lool> but that would work for now
<rickspencer3> beuno, could it not go into the store, but the user has to grant permissions to the usb?
<beuno> so I think it would be rolled into webdm, that already has special access
<lool> this seems to be a fine ubuntu-core config
<rickspencer3> lool, agreed, but I was thinking shorter term
<lool> and then we'd miss a generic way to change configs in webdm
<beuno> rickspencer3, that's an interesting question. I'm not sure where the boundaries are there
<lool> as an ubuntu-core config, it would be suitable from command-line as well
<rickspencer3> on the phone, we fulfilled many use cases by adding apps to the store while in parallel working on the core functionality
 * beuno nods
<beuno> we could likely just allow an exception for that app until we do
<lool> BTW edison and other boards just connect to the nearest open wifi on boot
<lool> arguably insane, but convenient
<rickspencer3> lool, that is insane :)
<rickspencer3> lol
<rickspencer3> lool, I think it would be great if you could do all of these:
<rickspencer3> 1. drop a configuration file somewhere ... gadget snap?
<rickspencer3> 2. use the snappy cli to define the ap and password
<rickspencer3> 3. use a configuration gui via webdm (or standalone in the short term)
<asac> rickspencer3: you can make a snap that has a config handler that takes a nice yaml with ap and password and then goes off, creates the wpasupplicant.conf, starts it and uses dhclient
<asac> wedm will later surface those config yamls
<lool> well this could be in ubuntu-core for now
<asac> first raw, later with generic input form by yaml scheme, even later through making webdm UI extensible
<alecu> what about iot devices that have only wifi? You need them to start in access point mode if they can't connect to a known network. (like the chromecast does)
<asac> lool: it could, but i kind off feel hesistant to drop a super quick hack into core
<asac> we dont know what we want to do on network management in core, so starting with a framework/app is a good idea for such quick things imo
<asac> alecu: yes, thats a pretty standard first boot/setup practice we would love to see :)
<lool> alecu: it's been on our TODO for ages; just never getting a change to implement this
<rickspencer3> we had good luck in the phone making certain functions apps first
<rickspencer3> and them bringing them into the core of the system as they were ready
<rickspencer3> for example, the app updater was an app for a while while we were perfecting system settings
<rickspencer3> then we moved that code into system settings when both were ready
<beowulf> asac: hi, what do you mean when you say make the webdm UI extensible?
<Chipaca> beowulf: webdm exposing config of installed apps
<Chipaca> afaict :)
<asac> right
<asac> just vague ideas
<beowulf> Chipaca: aye, i understand that part, and i understand (i think) the next part which is making yaml into form controls (right?), i'm just not sure what the extensible part was about?
<asac> that it woudl be cool if something could extend the webdm ui with its own config forms
<Chipaca> beowulf: i read that as management handwaving
<beowulf> fwiw, that's kind of in reverse order of difficulty :)
<asac> but how that could be done is not really understood... we know how forms with schema would work for sure
<Chipaca> beowulf: i.e. [ engineering magic happens here ]
<beowulf> Chipaca: i have a branch with a code editor embedded in the settings tab, so for a very basic first step if you wanted to send me yaml i could send it back edited...
<beowulf> *waves hands*
 * Chipaca stuffs yaml in a box and sends it off to beowulf
<beowulf> hehe
<alecu> Chipaca: what is the app config format or database that webdm will be touching, and how will apps find out about changes in those configs? dconf or something like that?
<ogra_> alecu, https://developer.ubuntu.com/en/snappy/guides/config-command/
<asac> alecu: snappy config
<Chipaca> alecu: ebdic-encoded hdf files
<alecu> Chipaca: lol
<alecu> ogra_: asac: thanks!
<Chipaca> boo :)
<sergiusens> good morning
<Chipaca> sergiusens: good morning!
<Chipaca> sergiusens: long time no see :)
<sergiusens> I vanished to deal with a full week of bureaucracy
<sergiusens> Chipaca: it's been a while ;-)
<Chipaca> sergiusens: wat? paperwork on your holidays?!?
<Chipaca> sergiusens: that's probably against geneva, or something
 * Chipaca does not like paperwork
<sergiusens> Chipaca: yeah, well, it had to be done at some point
 * sergiusens dislikes paperwork too
<rsalveti> morning
<rsalveti> sergiusens: spent the week paying taxes?
<sergiusens> rsalveti: yeah, delightful
<rsalveti> haha, yeah, had to do that a few weeks ago
<ogra_> hmm, trying to re-build one of my old snaps fails :/
<ogra_> http://paste.ubuntu.com/11206759/
<ogra_>  - snappy-systemd_hook_unknown_key_snap-inspector-term.snappy-systemd
<ogra_> 	Unknown field 'ports'
<lool> ogra_: I think the ports moved around https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<lool> but old location ought to work I guess
<ogra_> lool, well, my package.yaml looks pretty much the same
<ogra_> http://paste.ubuntu.com/11206839/
<ogra_> i dont have any internal port defined though
 * ogra_ doesnt see any difference beyond this vs the example package.yaml there 
<sergiusens> lool: ogra_ ports in that page is outdated, I logged a bug weeks ago
<sergiusens> lool: ogra_ oh, ports in there is fine now :-)
<ogra_> err, wut ?
<ogra_> is it outdated or is it fine ? :)
<ogra_> jdstrand, any idea why i would get "Unknown field 'ports'" with http://paste.ubuntu.com/11207212/ ?
<jdstrand> ogra_: the tools need to be updated for ports
<ogra_> jdstrand, yay ...
<jdstrand> ogra_: feel free to submit it and ping me
 * ogra_ wasted the last hour on searching the issue in his own stuff :)
<jdstrand> ogra_: :(
<ogra_> no, i'm fine ... i could have pinged you earlier :)
<jdstrand> ogra_: so long as it follows docs/meta.md, you should be fine
<ogra_> where is that ? in the reviewers tools ?
<jdstrand> ogra_: in lp:snappy
<ogra_> k
<sergiusens> Chipaca: can I have regrets?
<Chipaca> sergiusens: NO RUGRATS
<sergiusens> Chipaca: I have a future of that coming soon.. rugrats :-P
<Chipaca> sergiusens: :D
<Chipaca> sergiusens: regrets for what?
<Chipaca> sergiusens: were these regrets wrt the branches? logger? working for snappy? :-p
<sergiusens> Chipaca: logger, let's stay on the standup if you wnt for 3 minutes
<Chipaca> sergiusens: sure
<alecu> sergiusens: hi! with kyrofa we started building an experimental "snappy scope", based on webdm, as you suggested
<sergiusens> alecu: and... :-)
<alecu> sergiusens: there are a few questions we'd like to ask you
<sergiusens> alecu: shoot
<alecu> sergiusens: hmm... would you have some time for a hangout?
<sergiusens> alecu: sure, 14hr ART?
<alecu> sergiusens: sounds good, I'll set up a calendar event.
<alecu> thanks!
<Chipaca> jdstrand: is there a "apparmor linter"?
<sergiusens> there is
<jdstrand> Chipaca: you mean to see if the resulting profile is ok? there are two things that can pe used: apparmor_parser -p /path/to/profile and appamror_parser -QTK /path/to/profile
<jdstrand> Chipaca: the first is just a preprocessor and won't do things like verify apparmor variables are correct, etc. the 2nd is a full compile and the equivalent of apparmor_parser -r /path/to/profile except without loading into the kernel
<jdstrand> both can be run as non-root
<Chipaca> jdstrand: i ask because i'd like to be able to do something when apparmor fails, to better inform the developer of what exactly failed
<jdstrand> however, before one gets too excited, the way we are using templates and caps means that we can't naively run the parser on the files in the snap, because a transformation happens on what is in the snap to what is on disk in /var/lib/apparmor/profiles
<Chipaca> jdstrand: right now we're not being too helpful, making the thing more opaque than it needs
<jdstrand> Chipaca: if apparmor fails, you can run apparmor_parser -QTK /path/to/each/profile/from/the/snap and report back
<Chipaca> jdstrand: excellent
 * Chipaca adds a card
<jdstrand> because if apparmor is failing, the files should have underwent said transformation and be in /var/lib/apparmor/profiles
<Chipaca> jdstrand: https://trello.com/c/pK0vSzNZ/380-improve-information-provided-when-apparmor-fails
<jdstrand> if they aren't, then you happen to know that click-apparmor failed to do the transform (which should only happen when using security-override). however, I wouldn't worry to much about that since click-apparmor will be going away
<jdstrand> cool
<Chipaca> hah! i love it
<Chipaca> we have ErrInvalidPackageYaml
<Chipaca> ... we don't use it :)
<svij> hmâ¦ how do I find out which beaglebone black revision I have?
<Chipaca> waaaiiit
<Chipaca> https://code.launchpad.net/snappy/+activereviews
<Chipaca> git branches started showing up there
<sergiusens> Chipaca: let's move to git
<Chipaca> sergiusens: i believe we have a couple of blockers still?
<Chipaca> otherwise, +0 from me :)
<sergiusens> Chipaca: just auto merge and the recipe, the recipe we can run on our end in a new tarmac implementation so we have one dput per commit
<sergiusens> Chipaca: and for the merge we can use launchpadlib to poll, until we have webhooks, and git merge
<Chipaca> sergiusens: my +0 stands. With it I mean "don't let me stop you". And by *that* I mean I'm not going to help you do it :)
<ogra_> sergiusens, rsalveti, webdm is completely unusable on the released kvm image (works fine after snappy update webdm), do we want to keep it like that ?
<ogra_> or do we plan to make point releases
<ogra_> sergiusens, any idea why webdm on a kvm instance shows me all the arm kernel snaps ? i see beagle, overo, panda etc (merked as "not installable" but imho we should just hide uninstallable stuff)
<ogra_> *marked
<ogra_> (or is that a beuno question)
<beuno> the store does what its told
<sergiusens> ogra_: we decided to do that with beuno
<sergiusens> beowulf:
<beuno> so if its showing armhf, you are telling it you are armhf (or not telling it your arch at all)
<ogra_> i'm not telling anything, i just started a kvm instance with the released image :)
<ogra_> (and up to date webdm)
<beowulf> ogra_: somewhere along the way *cough* sergiusens *cough* i was told to show but not allow to install oem packages
<beowulf> if that's wrong it can be changed easily
<alecu> sergiusens: hangout?
<sergiusens> alecu: in abit
<sergiusens> alecu: running late in prev meet
<ogra_> beowulf, well, not sure who can make such a decision ... seems useless to show stuff to the user that he cant install
<alecu> sergiusens: no prob
<sergiusens> beowulf: ogra_ oh, right sabfdl said we should see them ;-)
<ogra_> do you knwo why ?
<beowulf> ogra_: i agree that the current ui is a bit awkward in this repect
<ogra_> well, if it is a sabdflified thing ...
<sergiusens> ogra_: we need another point release/pre built image
<ogra_> yeah
<rickspencer3> lool, I installed the new raspberry pi 2 image, but ssh ubuntu@webdm.local is not responding?
<rickspencer3> does this imply that I screwed up makng the sd card?
<ogra_> did you try the IP instead ?
<rickspencer3> ogra_, I did not
<rickspencer3> webdm.local worked on the last image and on my beaglebone over the weekend
<rickspencer3> ogra_, does it matter that I did not format the sd card first or anything?
<rickspencer3> I  assumed dd would just blast over everything
<ogra_> no, since you write to it with dd partitioning doesnt matter
<rickspencer3> I'll try again after lunch
<ogra_> but if you run multiple devices with avahi service an the same name (webdm.local) on the same network, i'm not sure what happens
<rickspencer3> make sure my bbb still works ;)
<rickspencer3> ogra_, I only run one at a time
<ogra_> k
<ogra_> well,  then it should theoretically work :)
 * rickspencer3 looks forward to his bbb case coming today
<ogra_> cases ... so overrated
<ogra_> :)
<rickspencer3> bbb worked just fine :(
<rickspencer3> I will try reflashing the new pi2 image later
<sergiusens> nothal_: help
<lool> rickspencer3: I think I dont have webdm installed in the image
<lool> it was broken back then, but now that it's fixed I should totally include it
<rickspencer3> lool, ok, so I have to just find the ip and install it?
<beuno> rickspencer3, yes
<beuno> make sure the date is correct
<beuno> then just sudo snappy install webdm
<rickspencer3> beuno, will nmap find it on my lan?
<sergiusens> rickspencer3: is avahi failing for you?
<rickspencer3> sergiusens, it looks like webdm is not installed on the pi2 image default
<rickspencer3> and I don't know how to find the pi2 on my network
<rickspencer3> and I lost the admin/password for my router :/
<beuno> rickspencer3, sure it will, otherwise just peak at your rou...  ah  :)
<sergiusens> rickspencer3: oh, bummer; nmap should find por 22 on the host and mostly nothing else
<sergiusens> rickspencer3: nmap can also enumerate OS (forgot the switch for that), but maybe the arch is part of that enumeration and it should be easy to find with that
<beuno> rickspencer3, otherwise, .ssh/known_hosts likely rememebers the last IP it accessed
<beuno> and that likely won't have changed
<rickspencer3> beuno, oh, I have to blow that away all the time because of switching between the bbb and the pi2
<rickspencer3> they don't play nicely together :)
<beuno> ah
<beuno> so there's an interesting to think about
<beuno> more than one snappy on the network!
<rickspencer3> \o/ found it
<rickspencer3> beuno, indeed :)
<rickspencer3> right now, it's good for Internet of Thing
<noise][> Cooperative Multitasking
<noise][> it's the floppy-swapping of the new millenium
<rickspencer3> sergiusens, that sounds smart, I just tried ssh ubuntu@ipaddresses starting at the highest and working my way down until I found it
<lool> rickspencer3: the trick I sometimes use (outside of checking DHCP logs) is to ping broadcast then look at the arp table
<lool> arp -an
<lool> ping -b 192.168.0.255
<rickspencer3> well, I just installed webdm, so this should work now :)
<rickspencer3> oops
<rickspencer3> this should work now, right/
<rickspencer3> ssh ubuntu@webdm.local
<sergiusens> yes it should
<rickspencer3> rats
<rickspencer3> is there a difference betwee webdm and webDM ?
<rickspencer3> do I need to start webdm?
<rickspencer3> ug
<rickspencer3> I ran snappy update and it looks like it is updating webdm, even though I just installed webdm :(
<ogra_> rickspencer3, there is a network scanner app in the phone store ;)
<beuno> that is... hard to pull off
<beuno> as in, the store only knows about one version of an app
<ogra_> (to find your RPi2 IP)
<beuno> so you couldn't really install an older version even if you wanted
<beuno> unless sergiusens uploaded a new one as you were typing!
<rickspencer3> ogra_, nice idea :)
<rickspencer3> beuno, no, it updated to the same version
<beuno> ew
<rickspencer3> I was on 0.6.1, it updated me to 0.6.1
<rickspencer3> I don't know why it would update me, though
 * rickspencer3 tries a restart
<sergiusens> beuno: rickspencer3 no I didn't update and it shouldn't update... :-/
<rickspencer3> it also doesn't seem to be working
<rickspencer3> maybe webdm is busted on the pi2 image?
<rickspencer3> yeah, every time I run sudo snappy update, it reinstalled webdm, which then does  not seem to work
<rickspencer3> the pi2 image is a bit busted, I guess :)
<sergiusens> rickspencer3: where did you get your pi2 image from?
<sergiusens> rickspencer3: maybe give me the output of journalctl -u webdm_snappyd_0.6.1.service
<sergiusens> rickspencer3: and also, snappy info, snappy list and snappy list --updates
<sergiusens> rickspencer3: try this, snappy remove webdm & snappy install webdm (sudo)
<sergiusens> rickspencer3: I think I know what this is and it is quite unfortunate
<rickspencer3> sergiusens, anything I can do to fix it?
<rickspencer3> I have a bbb so I am not dead in the water
<rickspencer3> just wanted to try out the pi2
<rickspencer3> also, I don't have a case for my bbb yet :)
<rickspencer3> should come today
<sergiusens> rickspencer3: snappy remove webdm snappy install webdm may do the trick
<rickspencer3> oh
<rickspencer3> sergiusens, can I get you any debug info or anything?
<sergiusens> rickspencer3: I'm not sure this went through as I was swapping networks so I'll copy paste just in case
<rickspencer3> k
<sergiusens> 16:49 < sergiusens> rickspencer3: where did you get your pi2 image from?
<sergiusens> 16:50 < sergiusens> rickspencer3: maybe give me the output of journalctl -u webdm_snappyd_0.6.1.service
<sergiusens> 16:50 < sergiusens> rickspencer3: and also, snappy info, snappy list and snappy list --updates
<sergiusens> and also please pastebin the result of find /apps
<sergiusens> snappy install pastebinit.mvo ;-)
<rickspencer3> sergiusens, I got the pi2 image from the where ubuntu.com/snappy/start said to go
<sergiusens> rickspencer3: I'll get the image and try after I get back from my excersise routine then
<rickspencer3> kk
<rickspencer3> sorry,  I got distracted with something else
<sergiusens> rickspencer3: no worries, so did I
<sergiusens> :-)
<rickspencer3> hehe
<rickspencer3> \o/ my bbb case came in the mail
<Chipaca> rickspencer3: welcome to the prestigious club of the non-naked bbbs!
<Chipaca> rickspencer3: your membership invoice is in the mail
<Chipaca> mterry: https://bitbucket.org/fzzbt/go-gedit-plugin/ is the "official" gedit plugin (in the sense that it's linked from https://code.google.com/p/go-wiki/wiki/IDEsAndTextEditorPlugins )
<mterry> Chipaca, ah interesting
<Chipaca> sergiusens: i lied about committing something for you to look at wrt refactor tonight, i fear
#snappy 2015-05-19
<noodles775> Hey people. I'm trying to follow the ec2 getting started guide, but ran into a bunch of problems. I've tried to document them at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390 , but any help appreciated.
<ubottu> Ubuntu bug 1456390 in Ubuntu App Developer site "Snappy ec2 getting started - various issues" [Undecided,New]
<sergiusens> Chipaca: no worries
<dholbach> good morning
<mvo> hey dholbach, good morning!
<dholbach> hey mvo
<davidcalle> Morning all o/
<davidcalle> rcj, hello, do you mind having a look at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390 ?
<ubottu> Ubuntu bug 1456390 in Ubuntu App Developer site "Snappy ec2 getting started - various issues" [Undecided,New]
<mvo> hey sergiusens and Chipaca - good morning! reading https://code.launchpad.net/~stephen-stewart/snappy/docs-tidy-up-package-metadata/+merge/259050 I wonder if we should simply standardize on django markdown and put that in the docs? its seems like a good idea to standardize and we love django :) WDYT?
<Chipaca> mvo: gooood morning!
 * Chipaca remembers he has a "beuno" script just for this
<Chipaca> mvo: goooooooooooooooooooooooooooooooooooooooooooooood morning
<Chipaca> see?
<mvo> Chipaca: hahaha
<JamesTait> Good morning all; happy May Ray Day! ð
<beowulf> morning
<JamesTait> o/ beowulf
<beowulf> dholbach: hey, bugs in the docs, should they be put into snappy rather than developer-ubuntu-com, or does it not matter? (see noodles775 comment ^^)
<dholbach> beowulf, I can't see noodles775's comment - I guess I was not online at the time.
<dholbach> beowulf, if the bug is in lp:snappy ./docs/ better fix it there
<dholbach> we still have to figure out how to keep both in sync - we didn't quite come to a conclusion during UOS
<beowulf> dholbach: ah, it was a bug report (https://bugs.launchpad.net/developer-ubuntu-com/+bug/1456390) and i was curious about the best place for same, as the doc src is in lp:snappy
<ubottu> Ubuntu bug 1456390 in Ubuntu App Developer site "Snappy ec2 getting started - various issues" [Undecided,New]
<dholbach> there are two sets of docs
<dholbach> there are the snappy internal docs (in the branch)
<beowulf> i did not know this
<dholbach> on developer.u.c we have most of the internal docs plus other stuff (like installation instructions, etc.)
<dholbach> as I said above: things grew quickly so we haven't quite figured out how to go about things
<mvo> Chipaca, sergiusens: just fyi, I look at the recent fbtfs, I can reproduce it here in a sbuild environment
<davidcalle> dholbach, rcj should be able to help, he provided the ec2 images info for duc, I've pinged him about that
<dholbach> thanks davidcalle
<Chipaca> mvo: do we want the syslog logger to ignore errors?
<mvo> Chipaca: how do you mean? I think its ok if syslog can not be initialized, i.e. I don't think snappy should fail entirely in this case. or was the question about something else?
<Chipaca> mvo: sergiusens: I can't find a unit test for the "application" -> "app" type serialization, so am writing it. Holler if it does exist and I missed it somehow.
<Chipaca> mvo: yeah, that's what i meant
<Chipaca> mvo: that is: i too believe that not being able to connect to syslog should continue, perhaps trying to log to stdout instead? or just not logging
<mvo> Chipaca: I think its ok unless I miss a strong reason why its not
<mvo> and +1 for the test, I don't know that this is tested yet
<Chipaca> mvo: on the *other* hand, if snappy is a long-lived daemon, i think it should not start without a working syslog connection (but maybe make it an option because tests?)
<ogra_> did you consider to swithc off logging by default ?
<mvo> Chipaca: daemon> that is a good reason, we *might* consider just writing to a logfile in this case and yes, for the tests we should be able to disable it syslog or write a mock
<mvo> ogra_: whats the use-case?
<mvo> ogra_: to avoid spaming the log?
<ogra_> appliuances usually have limited diskspace
<ogra_> i would turn off loging completely by default and only log if the user supplies a certain flag somehow
<mvo> a good point, however I would be suprised if we are the worst offender when it comes to writing logs
<ogra_> really depends ...
<Chipaca> ogra_: well...
<Chipaca> ogra_: that's an argument to turn off logging to syslog by default
<ogra_> some BSP kernels throw out 50msgs per second
<mvo> Chipaca: actually mocking syslog is probably the best idea
<Chipaca> no need, really
<Chipaca> well
<ogra_> Chipaca, well, all logging preferably ... probably leaving auth.log in place
<Chipaca> depends what you mean
<Chipaca> :)
<Chipaca> ogra_: oh, you're not talking just snappy here
<mvo> ogra_: there was a discussion about syslog vs journald (which uses a fixed log space AIUI) a while ago
<ogra_> i'm talking "snappy defaults"
<ogra_> in general that is ... not just the daemon
<ogra_> android actually only uses ringbuffers for logging to get around this ... but ringbuffers are limited (and gone when you reboot) ...
<Chipaca> ogra_: so, currently (as of last night (!)) we have a logger that logs things to syslog, and to the user's face (e.g. stderr if they're on console, or something tbd browser-appropriate for web), the in-users-face does not take up disk space
<ogra_> no, indeed not ... but the users face also means a console
<mvo> ogra_: right, I think we can get the ringbuffer behavior by just removing rsyslog from the image, then journald takes over and we have the behavior you suggest
<Chipaca> ogra_: my expectation is that webdm will provide a logger there that'll show the messages to the user
<ogra_> ah
<ogra_> that makes sensew
<ogra_> -w
<Chipaca> ogra_: Notices to a popup, Debugs to the console log
<Chipaca> sergiusens: ^ :)
<Chipaca> anyway, bottom line, we need to disable syslog because it's FTBFMFS
<Chipaca> :)
<mvo> well, we need to disable it in the tests at least :)
<Chipaca> mvo: would journald pretend it's syslog?
<mvo> Chipaca: I think so, I haven't looked into the details though, but I think journald just provides /dev/log and forwards to the rsyslog rightnow
<mvo> right now
<Chipaca> mvo: sergiusens: is it intentional that we write out "app" as the json of something we read in as "application"? beowulf: does webdm expect "app"?
<beowulf> Chipaca: not sure i understand, do you mean the type attr?
<Chipaca> beowulf: yep
<beowulf> Chipaca: webdm would need to know type oem, app, framework to do filtering, that's all
<Chipaca> hmm
<beowulf> oh, and to prevent installation of types
<Chipaca> beowulf: right. the click store knows "application", not "app"
<Chipaca> beowulf: so we're translating in snappy
<Chipaca> but that translation is currently one-way
<Chipaca> and i was wondering if that was design or accident :)
<beowulf> Chipaca: fewer words to describe the same things sounds good to me
<sergiusens> Chipaca: it's because they didn't want to add type app on the store side
<Chipaca> we *do* have unit tests for serialization!
<Chipaca> found them fixing up the code after the move :)
<Chipaca> sergiusens: i know why it's there
<sergiusens> Chipaca: we will need to add the new names anyways
<Chipaca> sergiusens: my question is, is it intentional that we deserialize "application" to "app", but serialize "app" to "app"
<ogra_> sergiusens, so after staring at http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/server/view/head:/lib/systemimage/generators.py#L525 for half my morning, i'm actually wondering why we dont create the respective files, dirs and links in the respecive initrds, what do you think ?
<sergiusens> Chipaca: the store marks anything it doesn't know as application
<ogra_> there doesnt seem to be a single dir file or link we would actually need to pre-exist for the initrd ...
<ogra_> (and additionally system/userdata could just be a link to system/writable on the phone ...)
<ogra_> (or bind-mount)
<ogra_> that way you wouldnt run into probs once the rootfs is a snap either
<Chipaca> sergiusens: and hydrogen is light, but that doesn't answer my question either
<Chipaca> sergiusens: :D
<sergiusens> mvo: good morning! Welcome back. And I welcome django
<ogra_> unchained ?
<sergiusens> ogra_: it's too early or I lack context to understand what you want to tell me :-P
<ogra_> sergiusens, this is about not re-packing the rootfs tarball on system-image.u.c
<mvo> sergiusens: hey, good morning! ok, I will look into md and lint in a bit
 * sergiusens understood the unchained joke
<ogra_> so you are at least a bit awake :)
<sergiusens> ogra_: so, what files, dirs and links are you talking about?
<ogra_> sergiusens, line 525 to 565 in the above link
<ogra_> (and later also 488 to 523 for the phone)
<ogra_> sergiusens, it alters the rootfs ... rsalveti was suggesting to move these bits to the live-build config instead
<ogra_> but i think it might make more sense to do it from the respective initrds
<sergiusens> ogra_: we already do a bunch of dir creating in initrd, I don't see a problem aside from the "do the least you can in initrd" mantra
<ogra_> (talking to you about it because you spoke up when we discussed it yesterday)
<Chipaca> i've got a silly question about initrd
<ogra_> there are no silly questions about initrds ...
<Chipaca> are the contents of the initrd left mounted so we can use them once booted?
<ogra_> no
<Chipaca> if not, would that not be a good idea?
<ogra_> it never gets mounted
<Chipaca> explicitly you mean?
<ogra_> the kernel unzips it and unpacks it ... once it is done with using it the memory region it lived in gets flushed
<Chipaca> the kernel mounts it directly, and then pivots?
<Chipaca> ahh, ok
<ogra_> it pivots but to /dev/root (which is a ram device)
<sergiusens> ogra_: you could create a kernel that wastes memory and keeps it somewhere accessible inside proc maybe :P
<ogra_> yeah
<Chipaca> but we still have things in initrd duplicated? but gzipped, so binding probably not doable i guess
<ogra_> or just mount --move / /myinitrd at the end before calling run-init
<ogra_> (or some such)
<Chipaca> i may or may not have abused initrd back when kernel+initrd fitted on a single floppy
<ogra_> Chipaca, what is duplicated ?
<Chipaca> ogra_: sh? some modules?
<ogra_> oh, that
<ogra_> yeah
<Chipaca> nearly all of initrd i guess
<ogra_> we could do the same as andrroid and use initrd as / :)
<ogra_> it would grow quite a bit then though
<ogra_> (android never pivots ... they just use it as / with a minimal install and then mount nearly everything else in subdirs)
<Chipaca> i think this ties in with what we tossed around with i think mvo, about having multiple /bins, so we could have kernel snap have its bin and an oem snap have its own, without having to merge things
<Chipaca> (or was it kernel and os)
 * ogra_ actually likes that initrd as root approach .... but the press would rip us into pieces :P "Ubuntu goes android OMG !!!11one1"
<sergiusens> ogra_: but it is rather clever
<Chipaca> dude, we were doing that way before android even existed
<ogra_> yeah
<Chipaca> it's not invented by them :)
<ogra_> Chipaca, using the initrd as default / ?
<Chipaca> yeah
<Chipaca> well
<Chipaca> we == the real open source community
<Chipaca> not we == ubuntu :)
<ogra_> we only use it as jumpstart and pivot out of it
<Chipaca> real as opposed to android, which is openish
<ogra_> as a buffer for HW compatibility in fact ... if it comes to ubuntu
<ogra_> nothing more ...
<Chipaca> i'm pretty sure knoppix did it, for a start
<ogra_> i know there is a terminal server project where they do it ...
<ogra_> TCOS ...
<Chipaca> and it was the only way to do rescue diskettes, and single-diskette distros
<ogra_> http://www.tcosproject.org/
<Chipaca> mhmm
<Chipaca> no need for nfs with that
<Chipaca> ie just blat the initrd over tftp
<ogra_> heh, last commit 8 months ago ... so not completely dead
<ogra_> lol, the page offers packages for dapper ... nice :)
<Chipaca> anyway, i guess we're not as constrained for disk space as we were back then, when even a 6$ computer comes with zomg space
<Chipaca> can i say "6$ computer" again?
 * Chipaca shakes his nostalgia off, like a rain-drenched overcoat
<dholbach> davidcalle, let me know when you're there - maybe we can have a quick chat to discuss docs :)
<davidcalle> dholbach, in ~15 min?
<dholbach> sure, wfm
<davidcalle> dholbach, ok
<Chipaca> sergiusens: you around?
<sergiusens> Chipaca: I need to walk the dogs before meeting marathon starts, so in 10' maybe  ;-)
<dholbach> davidcalle, so I thought that it might make sense if we would create google docs (or something) for the articles we want to import as tutorials, test them and bring them up for review for the snappy team, so we can see what's missing, what's broken and what needs to be updated
<dholbach> davidcalle, we could also open them up for comments by the wider community
<dholbach> and maybe do the same for a "tools overview" kind of article
<davidcalle> dholbach, I very much agree, except the Google Docs part, GDocs -> d.u.c is quite painful. On the other hand, I don't have a better idea :)
<dholbach> right
<ogra_> mvo, do you have any idea why we still build vivid images for core ?
<dholbach> davidcalle, maybe we just copy in everything and don't do any markup
 * ogra_ notices he gets arm64 failure mails for vivid builds
<dholbach> davidcalle, and copy in the same from the gdoc into the html view , so we don't get broken/unnecessary injected markup?
<davidcalle> dholbach, sure, that works
<dholbach> davidcalle, ok... shall I create placeholder docs in a google folder which we can freely share and we then take it from there?
<davidcalle> dholbach, yes, I'll probably be head down in scopes tutorials until thursday, but that sounds like a plan
<mvo> ogra_: hi, we need to get a updated image at some point, but I guess we don't really need to have a cron job for that currently
<mvo> ogra_: there are a number of pending bugfixes
<sergiusens> davidcalle: dholbach git branches and people creating MPs which act as comments
<ogra_> mvo, yeah, thats what i thought ... we should build them on demand
<dholbach> davidcalle, cool
<ogra_> wow ...  http://tracker.geops.ch ... thats like the real world in sim city
<ogra_> (shows all buses, trains and trams in realtime for nearly the whole world)
<dholbach> sergiusens, ... right
<davidcalle> sergiusens, maaaaybe, if you take care of merge conflicts
<Chipaca> raaaah, raaaah, i am the shredder of go files, fear me
<rickspencer3> hi all ... what is the best way for me to start with a snap in Go?
<rickspencer3> ideally, I'd love a QtCreator project, but barring that, any suggestions?
<sergiusens> rickspencer3: you can look at webdm or the go example server maybe
<rickspencer3> sergiusens, webdm sounds rather complext
<sergiusens> I don't think we have qtcreator integration at all with snaps
<sergiusens> rickspencer3: right, the go example server is a better start
<rickspencer3> I need something where it is obvious where to write the code, and where the snap build command just work
<Chipaca> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/go-example-webserver/
<Chipaca> rickspencer3: even includes a friendly README
<Chipaca> we're getting soft in our old age
<rickspencer3> Chipaca, sergiusens thanks gents, I'll give it a try
<rickspencer3> next stop: QtCreator integration
<rickspencer3> :)
<Chipaca> sergiusens: we should probably make that GOARCH=arm GOARM=7
<ogra_> whats GOARM ?
<ogra_> and why do you need to specify it
<Chipaca> ogra_: 5, 6, or 7
<Chipaca> ogra_: because it defaults to 6
<Chipaca> ogra_: and we don't really support 6 :)
<ogra_> it shouldnt :)
<ogra_> (on ubuntu that is) ...
<sergiusens> Chipaca: for webdm you mean?
<ogra_> sounds like a bug to me
<Chipaca> GOARCH=arm GOARM=7 GO7=path GOPATH=....
<Chipaca> sergiusens: in the README. But everywhere.
<Chipaca> if you're setting GOARCH=arm without also setting GOARM=7, it's a bug
<Chipaca> support for ARMv8 is in progress, also, fwiw
<Chipaca> sergiusens: i fixed it in webdm way back, btw
<Chipaca> @reviewlist
<nothal_> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (12 days old)
<nothal_> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (10 days old)
<nothal_> https://code.launchpad.net/~mvo/snappy/snappy-docs-mdlint/+merge/259490 | No reviews (less than a day old)
<nothal_> https://code.launchpad.net/~chipaca/snappy/pkg-types/+merge/259485 | No reviews (less than a day old)
<nothal_> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | No reviews (less than a day old)
<Chipaca> verterok: nothal seems to not find git MPs, btw
<Chipaca> verterok: compare with code.launchpad.net/snappy/+activereviews
<verterok> Chipaca: probably becase those git MPs are against a new branch which isn't configured? :)
<Chipaca> orly? ah ok then :)
<verterok> Chipaca: what's git master/trunk branch you want to keep track of?
<Chipaca> verterok: i dunno :)
<Chipaca> verterok: but there is a high chance of us moving to git in the near future, was just checking whether it'd work
<verterok> ah, ok
<Chipaca> me, refactoring: http://i.imgur.com/t0XHtgJ.gif
<Chipaca> mvo: question about iterHooks: is there a reason this is hung onto the click manifest, instead of the package yaml?
<beuno> Chipaca, and then mvo is all like: https://31.media.tumblr.com/28c234e45e157b55f923e109bbb9aa75/tumblr_inline_no7omriCW31raprkq_500.gif
<ogra_> LOL
 * Chipaca reaches for the mind bleach
<verterok> Chipaca: FYI just checked launchpadlib/launchpad API, git branches aren't yet supported there (at least I couldn't find a way to get the MPs for a git repo/branch)
<Chipaca> verterok: boo, etc
<verterok> indeed
<Chipaca> verterok: if only we knew somebody who could ask the launchpad guys what's up with that
<verterok> Chipaca: indeed...oh wait! beuno might know
 * verterok slowly steps back
 * Chipaca grins and gets back to work
<mvo> Chipaca: I don't think so really, probably a good cleanup opportunity too
<mvo> beuno: *ugh* that was a scary gif, NSFW
<Chipaca> mvo: that's where these little branches are all popping out of; start reworking things to be the way i think, get stuck because something seems wrong, back everything out and change that, and start over
<Chipaca> it gets easier every iteration \o/
<beuno> Chipaca, verterok, http://38.media.tumblr.com/d0d80832b4eb32e06deb46d1d1d774f0/tumblr_inline_nmpwjlVg201raprkq_500.gif
<Chipaca> beuno: http://i.imgur.com/eTic1wS.jpg
<mvo> verterok: have you asked on #launchpad or #launchpad-dev about this?  cjwatson will certainly know I would be suprised if there is really no way to get that info
<sergiusens> Chipaca: did you raise those refactor MPs already or are you still changing the light bulb?
 * Chipaca checks his pipeline
<ogra_> he is cleaning his face from mvo's kisses still :)
<Chipaca> sergiusens: debsig-verify-to-clickdeb and pkg-types
<Chipaca> sergiusens: now working on reducing click manifest's reach
<verterok> mvo: the devel version of the apidocs shows there is a way to get it...just not yet available in edge/production
<sergiusens> @reviewlist
<nothal_> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (12 days old)
<nothal_> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (10 days old)
<nothal_> https://code.launchpad.net/~mvo/snappy/snappy-docs-mdlint/+merge/259490 | No reviews (less than a day old)
<nothal_> https://code.launchpad.net/~chipaca/snappy/pkg-types/+merge/259485 | No reviews (less than a day old)
<nothal_> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | No reviews (less than a day old)
<Chipaca> sergiusens: the end game is pkg/snap/ (and not sure whether e.g. pkg/snap/oem or pkg/oem)
<Chipaca> that's what i'm incrementally getting at at least
<Chipaca> then it's just a move/rename if i've chosen bad names :)
<Chipaca> s/if/because/
<sergiusens> beowulf: ey, you never reviewed the package queries branch ;-) ^
<kyrofa> sergiusens, ping
<beowulf> sergiusens: oops, sorry, will do this afternoon
<sergiusens> kyrofa: pong
<elopio> hey team. This cable works to connect to the beagle serial port, right? http://www.amazon.com/Ftdi-TTL-232r-3v3-Serial-Converter-Cable/dp/B00M41OUYA/ref=sr_1_1?ie=UTF8&qid=1432041571&sr=8-1&keywords=FTDI+to+TTL+3.3
<kyrofa> sergiusens, as discussed yesterday (with alecu), webdm does indeed handle broken icons, by using http://webdm.local:4200/public/images/default-package-icon.svg . However, that image is completely blank on my install. Can you confirm?
<ogra_> elopio, hard to tell if the order in the plug is correct
<kyrofa> sergiusens, does this relate to the svg-png weirdness?
<ogra_> elopio, i usually buy cables with "flying ends" so i can more easily re-order them for specific boards
<ogra_> elopio, like http://www.amazon.de/gp/product/B00KVUSI30?psc=1&redirect=true&ref_=oh_aui_detailpage_o02_s00
<tbr> ogra_: if it's the "standard" FTDI order, then it will work
<sergiusens> kyrofa: you want beowulf to assist there; but it is for missing icons, not really broken ones
<ogra_> tbr, but not all boards use that order
<kyrofa> sergiusens, ah indeed missing, not broken-- sorry
 * ogra_ has at least two in the most recent batch of boards on his desk that dont 
<tbr> ogra_: BBB and MinnowboardMax do. I have two of those FTDI things
<noise][> i have http://www.amazon.com/gp/product/B00IJXNE1W/ and works with BBB, but DONT connect the red power line
<ogra_> yeah, you usually dont need the power line at all
<sergiusens> elopio: it should, you might be better off with one that has all the pins loose so you can plug them in any order (e.g.; banana pro)
<noise][> since it doesn't convert down to 3.3v
<elopio> ok, makes sense.
<sergiusens> I cut the power line just in case (I bought the bad batch 5vcc 3.3v ttl one that they decided to sell anyways)
 * tbr has a bucket of jumper wires for cases where he needs to have random layouts
<ogra_> well, you never know if you need it some day ... my power line us tape wrapped :)
<ogra_> *is
<sergiusens> ogra_: you can always reconnect what you cut ;-)
<kyrofa> beowulf, any idea why http://webdm.local:4200/public/images/default-package-icon.svg is blank?
<ogra_> sure ... but ripping of tape is easier than soldering :)
<ogra_> i havent needed it yet anyway ... could as well have cut it i guess :)
<ogra_> RX/TX/GND are usually enough
<alecu> kyrofa: is it a blank svg, or is it an empty file?
<beowulf> kyrofa: it's not blank, it's a white svg on a transparent background on a white body :)
<alecu> ah, that.
<kyrofa> beowulf, Ah! That would do it!
<beowulf> kyrofa: the default body background is a shade of grey :)
<kyrofa> Ah, so it paints through on the "home" page, but appears blank in the store
<alecu> kyrofa: to be useful on the scope, perhaps we can ask for the shade of gray to be part of the svg
<kyrofa> alecu, good idea. beowulf how would you feel about that?
<ogra_> make it 50 though ... thats modern :)
<beowulf> kyrofa: what are you trying to do?
<alecu> kyrofa: beowulf: I think there should not be icons with transparency in the store (at least that was a requirement for click apps)
<alecu> beowulf: we are building a unity8 scope to install snappy apps
<kyrofa> beowulf, and we're using the webdm API as a starting point
<beowulf> alecu: kyrofa: yeah, i can change this to be an actual icon and not a placeholder (the background is the ubuntu.com background which has all sorts of noise and gradients so picking 'grey' will likely look strange)
<beowulf> if you see what i mean
<alecu> right
<beowulf> so what you want is a proper 'missing icon' icon image
<kyrofa> beowulf, that makes sense
<kyrofa> beowulf, correct, and using the same one between webdm and the scope makes sense
<beowulf> kyrofa: does the scope overlay to make a "squircle"?
<beowulf> or do you simply take the icon as you find it?
<kyrofa> beowulf, it does make a squircle
<beowulf> kyrofa: ack
<elopio> dholbach: ping. The two first tables in here are almost the same: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/#partitions
<elopio> why do we need the first table?
<dholbach> elopio, I don't know... davidcalle: do you know where we inherited these tables from ^?
<kyrofa> beowulf, want me to make an issue for it?
<davidcalle> dholbach, imported doc from trunk
<dholbach> hum, do you know where it's from?
<dholbach> I can't find it in the branch
<davidcalle> dholbach, https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst
<dholbach> oh ok
<beowulf> kyrofa: yes please, thanks
<dholbach> elopio, ^
<elopio> jodh: ^ Do we need the first table in there?
<kyrofa> beowulf, done: https://bugs.launchpad.net/webdm/+bug/1456654
<ubottu> Ubuntu bug 1456654 in webdm "Default package icon can't be seen in Store page" [Undecided,New]
<elopio> dholbach or davidcalle: where is the source code for https://developer.ubuntu.com/en/snappy/start/#try-beaglebone ?
<dholbach> elopio, there is none
<beowulf> kyrofa: thank you
<davidcalle> elopio, it's not an imported doc, it's only here
<elopio> davidcalle, dholbach: I think this:
<elopio> unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | dd of=/dev/sdX bs=32M
<elopio> should be:
<elopio> unxz -c ubuntu-15.04-snappy-armhf-bbb.img.xz | sudo dd of=/dev/sdX bs=32M
<dholbach> yes
<dholbach> I'll fix it
<dholbach> done
<dholbach> thanks elopio
<jodh> elopio: just the first, or tables in general? I think the information is best presented in tabular form, hence rst (since md has poor support for tables)
<elopio> dholbach: thanks!
<mterry> Do you folks tend to use one GOPATH for all your branches, and just switch which one is the current "src/launchpad.net/snappy"?  Or do you have a new GOPATH for each branch, which you put at "src/launchpad.net/snappy"?
<elopio> jodh: I like tables. It's just that the first table is almost the same as the second table.
<sergiusens> Chipaca: the pkg branch looks fine, but what is the next step? Just wondering about the layout there
<elopio> jodh: I think we can remove the first table, and just leave the uboot and grub ones.
<jodh> elopio: yes, we could drop table 1 and add the FS type and description to tables 2+3, but that would make them a lot wider and duplicate the information.
<mvo> mterry: I use a single GOPATH and symlink my snappy branch
<jodh> elopio: they contain different information if you look carefully.
 * elopio looks carefully.
<mvo> mterry: git checkout will fix that nicely its really a non-ideal soluation
<elopio> jodh: ahh, I see. You are right.
<mterry> mvo, hmm makes sense -- the deps in GOPATH aren't going to need to change between branches
<mvo> mterry: yep
<elopio> might not fit anymore.
<mvo> elopio: this makes me wonder if we could make it more obvious why the tables are obvious, just a random thought while reading your conversation
<sergiusens> mterry: I use te same GOPATH
<sergiusens> mvo: what might fix it better is to use cheney's go get replacement and just vendor
<mvo> sergiusens: I still haven't looked at this yet :/
<mvo> I was hoping for git :)
<sergiusens> mvo: http://getgb.io/ solves a bunch of problems though ;-)
<elopio> I hate this network :@ It disconnects my quassel every two minutes.
<elopio> mvo: well, there's a note that says: The boot partition must be formatted as a vfat. We could keep that and add another note saying that the rest of the partitions are ext4.
<elopio> not sure if that's better than the table.
<elopio> I think I would prefer to duplicate the FS column than to have an extra table.
<sergiusens> mvo: did you see anything about zfs making it into the linux kernel btw?
<mvo> elopio: i have no strong opinion either way, but it seems like a good opportunity to make the doc better because you look at it with fresh eyes now :)
<mvo> sergiusens: I have not, that would be exciting, was there anything new about this recently? I thought there were license issues
<sergiusens> mvo: I think I heard some lawyers saying that it's not technically a gpl violation to include it, but I can't find any citation about that when googling; but if it becomes so, we will be in an awesome position :-)
<sergiusens> mvo: maybe I read too much into this https://lists.debian.org/debian-devel-announce/2015/04/msg00006.html
<elopio> I tried to reinstall my beagle with the stable image, and now I get:
<elopio> ssh: Could not resolve hostname webdm.local: Name or service not known
<mvo> sergiusens: oh, I think thats about shipping it as a dkms module or something
<elopio> is there anything I can check while my serial cable arrives?
<sergiusens> elopio: you need to install webdm for that avahi name to be exposed
<sergiusens> elopio: maybe u-d-f core 15.04 --output bbb.img --install webdm
<elopio> downloading...
<mvo> sergiusens: fwiw, https://code.launchpad.net/~mvo/ubuntu-cdimage/mvo/+merge/228214 was my attempt to make the image building indepentant of launchpad
<mvo> sergiusens: just fyi, we talked about it during the call
<sergiusens> mvo: let's see if ogra_ is bold enough to land that ;-)
 * sergiusens reads
<mvo> sergiusens: heh, I guess it needs some polish first, but thats the direction
<sergiusens> mvo: procmail is a requirement? wow
<mvo> sergiusens: thats what I mean with "polish", I think we could do something with python here to avoid this dependency
<ogra_> haha "HACKING"
<mvo> ogra_: I would like to resurrect something like this, wdyt?
<ogra_> mvo, looks fine at a first glance, but if you dont add the necessary changes tpo the selftest too i think cjwatson might hunt me down
<sergiusens> mvo: it's not even that invasive
<mvo> sergiusens, ogra_: thanks, I will try to spend a bit of time on it this week then
<elopio> sergiusens: no luck with the --install
<sergiusens> elopio: what kind of no luck?
<sergiusens> as in what errors
<elopio> same: ssh: Could not resolve hostname webdm.local: Name or service not known
<sergiusens> elopio: how is the bbb connected to the network?
<mvo> elopio: so "bash" in the selftest and the "why"? it was basicly a quick way for me to not have to run these tests manually, but I much agreee, shell is a bad language for this and sergiusens suggested replacing that with something besser. I wonder if we should go with gocheck for the sake of consistency or python-unittest
<sergiusens> mvo: elopio I used to just use pythons default unittest module and have it run all when calling it with the if __main__ gimmick
<kyrofa> sergiusens, the icon in the snappy webcam-demo does actually seem to be invalid. Is this known?
<sergiusens> kyrofa: yeah, we need lool or asac to setup a proper icon in there
<kyrofa> sergiusens, okay, as long as it's a known issue :)
<sergiusens> kyrofa: it is ;-) and we expose it loud and clear on webdm :-)
<sergiusens> Chipaca: can we discuss 'pkg' now?
<kyrofa> sergiusens, Ha! I'm doing the same on the scope :)
<Chipaca> sergiusens: sure
<sergiusens> Chipaca: ho r irc?
<Chipaca> sergiusens: irc would be better right now
<Chipaca> sergiusens: or ho in 30'
<sergiusens> Chipaca: ho in 30'
<Chipaca> sergiusens: k
<sergiusens> Chipaca: I wrote something down on the review itself, but the direction would be nice
<sergiusens> Chipaca: maybe mvo wants in as well
<asac> sergiusens: you can make one :)
<asac> i think we have svgs
<asac> for the snappy log
<asac> you can put a nice camera overlayed over it
<sergiusens> asac: I don't have the package sources though
<Chipaca> sergiusens: responded in the mp also
<Chipaca> sergiusens: question for you: how much do we care about returning "invalid part" when it doesn't have a namespace, in places that don't really care about it?
<Chipaca> e.g. in partsForGlobExpr
<sergiusens> Chipaca: I need to figure out the ripple effect for that
<Chipaca> sergiusens: i ask because i'm trying to move all these "if it's a framework or an oem" thing to one or two places at most :)
<Chipaca> that's at the top of the stack, previously at the top of the stack was "make things not use the click manifest", which ended up with more namespace checks everywhere
<Chipaca> so, new pipe, clean up namespace whatsits
<Chipaca> then back to that one
<Chipaca> and then not using the click manifest means one step closer to packageYaml being separable
<Chipaca> still a ways off though
<Chipaca> man, if i were still in cÃ³rdoba people would be running around like crazy hiding their cars
<Chipaca> the sky is that weird green you get before a big hailstorm
<Chipaca> zomg, hail :)
<Chipaca> hah!
<sergiusens> Chipaca: hah, true :-)
<sergiusens> Chipaca: let's move that meet a bit, going to run some lunch errands
<elopio> sergiusens: mvo: sorry, had a meeting here, and now lunch. I like the idea of writting the tests in the same language you are using, so go sounds nice. But then we would have to build the tests, or tell adt-run to build them on the board.
<elopio> I know python better, and that's easy to write.
<Chipaca> elopio: OTOH if you do it in python, then you'd have to get python onto the device
<Chipaca> elopio: (we hope to remove python entirely at some point)
<beowulf> sergiusens: Chipaca: mind you helping me with this, output of webdm ./build.sh http://pastebin.ubuntu.com/11227865/
 * Chipaca looks
<Chipaca> beowulf: you're building with the system go, and you don't have the arm system go
<Chipaca> beowulf: install golang-go-linux-arm
<Chipaca> beowulf: and you should be set
<beowulf> Chipaca: thanks
<Chipaca> beowulf: option b is you're building with your own go, and haven't done an "all" build with GOARCH=arm
 * beowulf makes note to fill out readme 
<Chipaca> beowulf: if option b sounded like something almost but not quite entirely dissimilar to gibberish, then it's probably the first one
<Chipaca> wait, i
<Chipaca> 'm missing a negation in there
 * Chipaca adds more negations
<Chipaca> beowulf: if option b failed to sound like something almost but not quite entirely dissimilar to gibberish, then it's probably the first one
<Chipaca> there, now you can go
<beowulf> Chipaca: I...
<beowulf> Chipaca: Part II of your test http://pastebin.ubuntu.com/11228018/
<Chipaca> beowulf: rm -rfv --wtf --bbq /home/sstewart/go/pkg
<Chipaca> beowulf: or set it aside if you'd rather be cautious
<Chipaca> also maybe without --wtf and --bbq
<beowulf> :)
<Chipaca> beowulf: but basically you've got compiled pacakges for go 1.2.x and it's looking for 1.3.x
 * beowulf regrets the things he did to end up here
<beowulf> Chipaca: thanks, works now
<Chipaca> beowulf: i'm sorry
<beowulf> Chipaca: whyfore?
<beowulf> s/e//
<Chipaca> beowulf: i accidentally got you unblocked
<beowulf> :)
<mterry> sergiusens, I see you added python to the ubuntu-core seed.  It never got released as part of the meta package in the archive though.  Should that still be there/be a part of the meta package?
 * mterry wants to release a new meta package removing gawk and original-awk
<sergiusens> mterry: I think I proposed it against the wrong seed originally
<mterry> sergiusens, you did, but it got put in the right seed.  But still, a new meta package was never spun up
<mterry> sergiusens, do we want it in the image?
<sergiusens> and either slangasek or mvo (gone) took care of it
<mterry> sergiusens, oh
<mterry> sergiusens, so we don't want it in the ubuntu-core seed at all?
<sergiusens> mterry: I hope I described in the MP why it was suppposed to be there
<beowulf> sergiusens: when i build lp:~sergiusens/webdm/queryPackageNames and query /api/v2/packages/?q=8nzc1x4iim2xj1g2ul64 i get too many results
<mterry> sergiusens, yeah for "Adding python to system-image seeds to support walinuxagent"
<sergiusens> beowulf: to be fair, that just uses the search api from the store, what if you search for something more specific?
<mterry> sergiusens, it just never got released as far as I can see, so I wanted to make sure it should still be there before I released a new meta
<sergiusens> mterry: great, utlemming did the port to python3 ever get done?
<utlemming> sergiusens: yeah, I think we're just waiting on some final bits
<utlemming> sergiusens: and an sru for cloud-init
<sergiusens> utlemming: great
<sergiusens> utlemming: but it's in wily already, right?
<sergiusens> mterry: if that port is done, we can get rid of the python dep (which I think was also manually setup in livecd-rootfs as well)
<beowulf> sergiusens: actually, results are the same every time... (minor lol that you're asking me to search for somethign more specific than '8nzc1x4iim2xj1g2ul64')
<sergiusens> beowulf: :-)
<sergiusens> beowulf: weird, it was working fine for me when I tried it...
<beowulf> sergiusens: i'll check my install again in a bit, going for food now
<sergiusens> ack
<sergiusens> beowulf: I'll give it a spin
<mterry> sergiusens, well the python dep was never a part of the meta package, and if it will go away for wily, I won't add it now.  I'll drop it from the seed
<sergiusens> Chipaca: talk talk?
<Chipaca> sergiusens: natter natter
<sergiusens> mterry: sounds good
<Chipaca> sergiusens: https://plus.google.com/hangouts/_/canonical.com/natter-natter?authuser=1
<Chipaca> allright, tests pass, ftw, bbq, & etc
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/snappy/reduce-manifest/+merge/259539 for when you're able and willing
 * sergiusens doesn't mind a bbq sprint
<sergiusens> Chipaca: you have conflicts
<Chipaca> yeah, noticed that
<sergiusens> Chipaca: the lp preview really makes it hard to see why, but I guess it's obvious to you so I'll wait before doing a local pull
<sergiusens> ;-)
<Chipaca> sergiusens: i removed files that have changes in them on trunk
<Chipaca> sergiusens: there ya go
<Chipaca> tyhicks: nudge nudge
<tyhicks> Chipaca: ah! sorry! will do it before my eod
<Chipaca> tyhicks: wink wink
<Chipaca> tyhicks: say no more
<sergiusens> rickspencer3: I reproduced your webdm always wants to upgrade problem on the rpi2 with lool's image; I'm guessing this is a framework problem
<sergiusens> I'll research this
<rickspencer3> hi sergiusens
<rickspencer3> so, if someone builds robots and is interested in snappy, which is the best mailing list to recommend they join?
<rickspencer3> sergiusens, did webdm actually work for you on the pi2?
<sergiusens> rickspencer3: and it's because the img is bad
<sergiusens> rickspencer3: it needs to be regenerated
<rickspencer3> seems like we need some kind of CI that a community image developer could run
<rickspencer3> sergiusens, ah, lool is on holiday until next week
<sergiusens> rickspencer3: no, the oem package is bad; it has a namespace which means it probably was created even before the release
<rickspencer3> sergiusens, oh
<sergiusens> rickspencer3: he is back on thursday; I can generate one with u-d-f, it should work
<elopio> Chipaca: right, but adt-run can install the python deps just for the tests in a tmp dir, and then remove them.
<rickspencer3> sergiusens, ok, if you are done soonish I can test it
<elopio> I think, I haven't tried installing everything, just some packages.
<elopio> it will be slower, while it downloads and installs everything.
<sergiusens> elopio: Chipaca our tests could very well be written in go then
<sergiusens> no need for dep baby sitting there
<Chipaca> elopio: go has very good cross-compilation support, meaning that building it for arm on intel is a no-brainer most of the time
<sergiusens> rickspencer3: wrt to the skynet creators, snappy-app-devel I think would be the best
<elopio> go it is then :)
<sergiusens> elopio: you will love go, like it or not(?) :-P
<elopio> I'll try to re-write one, to improve my go.
<rickspencer3> thanks sergiusens
<elopio> sergiusens: I like go. I just need to learn more.
<elopio> so if you see on my branches something stupid, please don't be shy...
<sergiusens> elopio: I'm never shy with reviews as I hope people are never shy to say I did something wrong ;-)
<Chipaca> sergiusens: we should all go have a sprint at elopio's, to help him get up to speed
<Chipaca> sergiusens: he just happens to live a stone throw's away from a rather nice bit of beach
<elopio> I pay for the first round of beers!
<Chipaca> I can see no holes in this plan
<sergiusens> Chipaca: sounds like a plan, rsalveti should set it up ;-)
<sergiusens> good team building
<sergiusens> and... winter is coming (here)
<elopio> well, we don't have winter. But we are in the middle of the rainy season.
<elopio> you should bring a poncho, or wait a couple of months.
<Chipaca> i've got to wait a couple of months for a passport anyways
<Chipaca> verterok: https://github.com/wyc/armbot
<Chipaca> verterok: just sayin'
<Chipaca> verterok: now all you need to do is rewrite launchpadlib in arm assembly, and you're set
<verterok> Chipaca: "motivation: lol"
<Chipaca> verterok: :)
<rsalveti> yeah, wouldn't mind going there either, raining like hell here lately
<rsalveti> and, winder is coming
<rsalveti> *winter
<sergiusens> ricmm: sudo ubuntu-device-flash core rolling --channel edge --oem generic-i386 --output i386.img
<tyhicks> Chipaca: I got started on the review but need some more time to finish up - it'll be my top prio tomorrow morning
<Chipaca> tyhicks: ok, thanks!
<tyhicks> Chipaca: check out the MP - I found an issue
<Chipaca> yeah, just reading it
<tyhicks> Chipaca: I haven't had time to think of the proper fix yet and still have more review to do
<tyhicks> I gotta run
<Chipaca> easiest fix is to not make tmpdir predictable
<Chipaca> which was a feature maybe, but maybe not
<Chipaca> will chat with mvo tomorrow
<ricmm> sergiusens: thanks
#snappy 2015-05-20
<dholbach> good morning
<davidcalle> Good morning!
<seb128> hey there, not sure who has topic edit right, but you might want to "snappy-ubuntu" -> "snappy" in the Bugs launchpad url
<beowulf> morning
<JamesTait> Good morning all; happy Weights and Measures Day! ð
<Chipaca> mo'in!
<Chipaca> mvo: hi there
<mvo> hey Chipaca
<ogra_> yo
<Chipaca> mvo: I called it packageYaml.dirname because there's already Dirname(part)
<Chipaca> mvo: also because no other word described what it did
<Chipaca> was tempted by fqdn too
<Chipaca> mvo: i mean: "no other word described what it did" applied more to when i worte Dirname(part)
<Chipaca> mvo: fullname comes close, but isn't descriptive
<mvo> Chipaca: I kind of like fqdn better, dirname pops images of directory structures into my brain, but like I said, maybe thats just me :)
<Chipaca> mvo: otoh i know dirname is not immediately obvious
<mvo> I guess namespacedName is too long :/
<Chipaca> mvo: also, wrong
<Chipaca> mvo: because it's not namespaced if it's a framework or a gadget
<mvo> aha, because for frameworks its not
<mvo> meh
<Chipaca> quite :)
<mvo> fqn() :) ?
<mvo> fqsn() - full-qualified-snap-name?
<mvo> but I can life with dirname(), I just wish we had a better name
<Chipaca> nameMaybeNamespaced
<Chipaca> although Maybe makes me think it's either the namespaced name, or nil
 * mvo nods and scratches head
<dholbach> mvo, in the package.yaml - am I supposed to use "name: appname" or "name: appname.username"?
<Chipaca> dholbach: name: appname
<dholbach> it looks like the former (else I get "package name with namespace not supported")
<dholbach> ok
<dholbach> thanks Chipaca
<Chipaca> dholbach: the origin does not go in the yamel
<dholbach> ok cool
<dholbach> ogra_, can you pull from lp:~dholbach/+junk/chatroom?
<dholbach> ogra_, ... and have a look at https://code.launchpad.net/~dholbach/node-snapper/update/+merge/259584?
<ogra_> dholbach, oh, nice, but i dont think that will work for non wily ... the cdimage url is completely different for released tarballs
<dholbach> ogra_, distro-info will always give you the current release
<dholbach> err, current development release
<ogra_> dholbach, right
<ogra_> ogra@anubis:~/datengrab/holbi$ wget http://cdimage.ubuntu.com/ubuntu-core/daily/current/trusty-core-armhf.tar.gz
<ogra_> 2015-05-20 11:10:07 FEHLER 404: Not Found.
<dholbach> mh?
<ogra_> the REM_ vars need to be adjusted too ...
<ogra_> daily/current/$DIST...tar.gz only works for the durrent devel release
<ogra_> *current
<dholbach> right... I though that the current dev release is what we want?
<ogra_> if you ran node-snapper on a trusty system DIST would be set to trusty
<ogra_> but that url only works for wily :)
<seb128> does anyone has topic edit right/saw my comment earlier?
<ogra_> dholbach, for trusty the url would have to be http://cdimage.ubuntu.com/ubuntu-core/releases/trusty/release/ubuntu-core-14.04-core-armhf.tar.gz
<ogra_> (note the different tarball name (along with the different path)
<dholbach> ogra_, ok... I thought distro-info-data was backported for trusty, etc
<dholbach> then we probably just update the string to 'wily' and be done with it :/
<dholbach> seb128, sorry, no op privileges here :/
<ogra_> oh
<ogra_> ogra@anubis:~/datengrab/holbi$ distro-info -d
<ogra_> ubuntu-distro-info: Distribution data outdated.
<ogra_> Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
<ogra_> heh
<ogra_> i guess thats the problem here
<dholbach> right
<seb128> dholbach, ok, no worry, hey btw :-)
<dholbach> hey seb128
<ogra_> hrm
<ogra_> apt doesnt think it is outdated ... weird
<dholbach> ogra_, I'll leave it up to you to either update your trusty vm or just use 'wily' as string in the script - 'vivid' doesn't work :)
<ogra_> yeah, i have the wily change local, just not merged yet
<dholbach> ok ok
<ogra_> yours appears better though
<ogra_> (saving me from updating every cycle)
<ogra_> yeah, works after update ...
<dholbach> <3
<dholbach> ogra_, I'm turning your blog entry into a tutorial, that's why I was verifying all the steps
<ogra_> merged and pushed
<dholbach> both? :)
<ogra_> no, looking at the chatroom one now
<dholbach> thanks ogra_
<ogra_> i cant buiuld snaps here due to a bug in the verification for "ports" :/
<dholbach> really?
<ogra_> yeah
<dholbach> which version of snappy do you have installed?
<dholbach> is this vivid?
<ogra_> trusty
<ogra_> latest from the PPA
<ogra_> snappy-tools is 10
<ogra_> click-reviewers-tools is 0.26~snappy0.14.04.1
<dholbach> and ubuntu-snappy-cli?
<ogra_> 0.1.2-1+419~ubuntu15.04.1
<ogra_> aha
<dholbach> 1.0.1-1+439~ubuntu15.04.1
<ogra_> yeah, just noticed
<dholbach> from https://launchpad.net/~snappy-dev/+archive/ubuntu/beta
<dholbach> man... you're years behind!
<ogra_> ogra@anubis:~/datengrab/snaps$ snappy build snap-inspector-term/
<ogra_> Generated 'snap-inspector-term_0.1-1_multi.snap' snap
<ogra_> YAY !!!!
<dholbach> yeeeeeeeehaw
<ogra_> dholbach, did you try rolling a chatroom snap with that change ?
<ogra_> (i'm surprised there is not more to change)
<ogra_> doesnt complain though ...
 * ogra_ merges
<ogra_> and pushed
<dholbach> hanks!
<dholbach> thanks!
<dholbach> ogra_, if you create the snap like that and sideload it using snappy-remote... does the chatroom app work for you?
<ogra_> dholbach, no, if i create it like that the whole of node-snapper is missing :)
<ogra_> cant work
<ogra_> you need to follow the steps ;)
<dholbach> I think I did
<dholbach> http://pastebin.ubuntu.com/11241760/
<ogra_> right, i didnt :)
<dholbach> ahhhhhh ok :)
<ogra_> i dont think you can start a snap service like that
<dholbach> I was just trying to debug why it didn't start up
<ogra_> use systemctl ... and watch syslog
<ogra_> well, the PATH isnt right ... and you will mis all the env vars when just calling it with sh
<dholbach> what would the systemctrl invocation be?
<ogra_> not sure if we still redirect stdout to syslog, but you could switch to "set -ex"
<ogra_> systemctl | grep chatroom
<ogra_> that gives you the service  name
<dholbach> sorry, I meant... how do I use systemctl to start the chatroom?
<ogra_> systemctl start <name of service from teh grep command>
<ogra_> probably sudo too :)
<dholbach> I don't see it listed there
<ogra_> yeah, just noticing the same with my snap-inspector-term
<ogra_> seems the systemd handling changed
<ogra_> (my snappy knowledhge is about as outdated as that package above was :) )
<Chipaca> mvo: pushed with 'qualifiedName'
<ogra_> does anyone know how systemd for snaps changed ... is that documented anywhere ?
<ogra_> (i dont see a unit for my snap ... )
<Chipaca> ogra_: changed when?
<Chipaca> ogra_: hasn't changed :)
<Chipaca> in ages. two weeks at least.
<ogra_> Chipaca, well, i'm using a snap that works fine on my really old (several months) snappy install
<ogra_> i re-built with a new snappy (fixed all complaints) and installed it ...
<ogra_> systemctl doesnt list it ...
<ogra_> (and it obviously doesnt autostart as it used to)
 * ogra_ sees /apps/snap-inspector-term.sideload/0.1-1/meta/snap-inspector-term.snappy-systemd but nothing installed anywhere else
<Chipaca> ogra_: interesting
<ogra_> i see it attempted to start in syslog
<ogra_> (amd64)ubuntu@localhost:~$ systemctl list-units| grep inspector
<ogra_> (amd64)ubuntu@localhost:~$
<ogra_> (amd64)ubuntu@localhost:~$ sudo grep Inspect /var/log/syslog
<ogra_> May 20 09:43:27 localhost systemd[1]: Started Inspect the environment of a snap package in a browser.
<ogra_> May 20 09:43:27 localhost systemd[1]: Starting Inspect the environment of a snap package in a browser...
<Chipaca> ogra_: sudo systemctl | grep -i inspector
<ogra_> no change ...
<Chipaca> hrmph
<Chipaca> ogra_: note the sudo there
<ogra_> yeah, i tried with and without
<Chipaca> ogra_: what's your package.yaml like?
<ogra_> http://paste.ubuntu.com/11242104/
<Chipaca> systemd usually prints *something* if it tried to start it. and you say there isn't a file in /etc/systemd/system for your service?
<ogra_> there is
<Chipaca> ah! what's it called?
<ogra_> but systmctl doesnt seem to know about it
<ogra_> snap-inspector-term_snap-inspector-term_0.1-1.service
<Chipaca> ogra_: and âsystemctl status snap-inspector-term_snap-inspector-term_0.1-1â isn't helpful?
<ogra_> ok, calling it gets me a start event
<ogra_> but it doesnt start and there is no stdout debug output in any log :/
<ogra_> do we exclude snaps from list-units for security reasons ?
<ogra_> also how do i get the old verbosity back ?
<Chipaca> ogra_: no, they're always there
<ogra_> we used to redirect stdout of the started script to journald ... seems that is suppressed now
<ogra_> which makes debugging really hard ...
<Chipaca> ogra_: i'm not aware of that having changed
<ogra_> May 20 10:07:12 localhost.localdomain sudo[3133]: ubuntu : TTY=pts/1 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/bin/systemctl start snap-inspector-term_snap-inspector-term_0.1-1.service
<ogra_> May 20 10:07:12 localhost.localdomain sudo[3133]: pam_unix(sudo:session): session opened for user root by ubuntu(uid=0)
<ogra_> May 20 10:07:12 localhost.localdomain systemd[1]: Started Inspect the environment of a snap package in a browser.
<ogra_> May 20 10:07:12 localhost.localdomain systemd[1]: Starting Inspect the environment of a snap package in a browser...
<ogra_> that is all i get
<Chipaca> ogra_: let me start with a fresh image here, as i'm not seeing what you're seeing
<Chipaca> ogra_: what image are you on?
<ogra_> even with the start-service.sh script set to "set -x"
<ogra_> the kvm image currently ...
<ogra_> the released one
<Chipaca> ogra_: rollin'?
<ogra_> no, whatever is in the default docs for kvm
<ogra_> 15.04 image ....
<Chipaca> ogra_: can you give me the command you used to create the image?
<ogra_> i didt
<ogra_> *didnt
<ogra_> wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<ogra_> :)
 * Chipaca wgets
<ogra_> the script is surely still having issues (using SNAPP in the var names etc) ... but i kind of would expect that i can get some more verbose output from the failed start
<Chipaca> you should
<Chipaca> and it also should be in list-units
<Chipaca> (which is the default command, btw; you don't need to say it)
<ogra_> right
<ogra_> well. it definitely isnt ...
<ogra_> but this time rount it at least seems to respect the set -x ... i see a bit more output
<Chipaca> ogra_: can you try whether the xkcd one works?
<dholbach> installing it through webdm this at least works:
<dholbach> (amd64)ubuntu@localhost:~$ sudo systemctl | grep -i xkcd
<dholbach>   xkcd-webserver_xkcd-webserver_0.5.service                                                loaded active running   A fun webserver
<dholbach> (amd64)ubuntu@localhost:~$
<dholbach> and ps shows:
<dholbach> /usr/bin/python3 /apps/xkcd-webserver.canonical/0.5/bin/xkcd-webserver
<zyga> asac: hey
<Chipaca> dholbach: and systemctl status xkcd-webserver_xkcd-webserver_0.5.service should be nice too
<Chipaca> http://excellent.mezgr.de/snappy
<ogra_> yeah, all fine with that
<Chipaca> ogra_: can you put your snap somewhere so i can give it a poke?
<ogra_> sure
<ogra_> i would prefer to get proper output from the startup though .,... to be able to fix it myself
<ogra_> using set -x doesnt give me any error output
<ogra_> oh, and i see why
<ogra_> there is an "ubuntu-core-launcher" that seems to swallow it
<ogra_> thats not on my old snappy installs
<Chipaca> the launcher shouldn't affect stdout/stderr
<ogra_> http://paste.ubuntu.com/11242416/
<ogra_> well, i seem to get stdout ...
<asac> zyga: hello
<ogra_> but since the start fails i would also expect something on stderr
<ogra_> the paths look all ok
<Chipaca> this reminds me, mvo: when you've got a sec, we should discuss the launcher private tmp branch thing
<zyga> asac: I'd like to schedule a call with you, it's not urgent, I'd like to talk about snappy certification
<ogra_> Chipaca, hmm, i suspect there is something wrong with the node binary actually ... setting all the vars manually and trying to run it it just silently returns
<mvo> Chipaca: right after lunch maybe? so in about 1h? or now but then I don't know how much time I have until lunch is ready :)
<Chipaca> mvo: basically, making the tmpdir predictable opens us up to nasty attacks
<Chipaca> mvo: so we either need to be very careful, or we use mkdtemp
<Chipaca> mvo: leaning towards the latter myself. think about it and tell me after lunch maybe :)
<ogra_> yay, now i get roper ouutput
<ogra_> *proper output
<mvo> Chipaca: my gut feeling is mkdtemp too, being careful is not my strength and its also hard to get right IME (i.e. hard to be careful enough :/
<mvo> Chipaca: I have not looked at this branch yet, I need to do that
<Chipaca> ogra_: yay
<Chipaca> mvo: tyhicks is looking :)
<ogra_> bah, and now apparmor gets in my way
<Chipaca> ogra_: these security modules, coming over here, stealing our jobs
<ogra_> heh
<ogra_> "stealing our jooobs"
<ogra_> well, the package is a mess ... (apparently) ...
<Chipaca> mvo: also about the launcher, what do you think of changing it so we pass in all the bits and it creates the environ 'from scratch'?
<ogra_> what dholbach tried above seems to be very typical when debugging (just running the start script with "sh -x" ) ... is there a way to manually run the launcher instead ... heanding the path to the script to it to be able to debug ?
<ogra_> if so we need to put it in the docs ... if not, it would be nice to have such a feature :)
 * ogra_ just tries using /usr/bin/ubuntu-core-launcher ... seems it doesnt set a single var ...
<ogra_> \o/
<ogra_> finally got it working
<ogra_> hmm, semi-working it seems
<dholbach> ogra_, did you update the branch already? :)
<sergiusens> Chipaca: I see mvo was not as lazy as me and commented on the review :)
<ogra_> dholbach, yes
<sergiusens> good morning btw!
<ogra_> all your changes should be pushed
<Chipaca> sergiusens: yeah, i'm thinking of firing you as a reviewer and getting another mvo instead
<sergiusens> mvo: btw, I discussed this with Chipaca yesterday http://snappy.asac.ws:9001/p/dot.store can I get your thoughts?
<Chipaca> sergiusens: he's not as mean
<sergiusens> Chipaca: :(
<sergiusens> Chipaca: you are mean!
<sergiusens> :-P
<Chipaca> sergiusens: only because you like it!
<dholbach> ogra_, what's still missing?
<sergiusens> Chipaca: in any case, I didn't find anything that bothered me, and planned to look at again today, so there
<ogra_> dholbach, dunno, i have to run through the whole howto again ...
<Chipaca> sergiusens: neener neener
<ogra_> (just trying to debug the other snap now, i'll move over to chatroom after that)
<dholbach> ogra_, ok, I'll try as well
<sergiusens> Chipaca: should I base my origin change on top of this one or are there more coming?
<asac> sergiusens: that one is very cryptic
<asac> not clear what it is proposing
<ogra_> asac, can you fix the bug link in the topic to not use snappy-ubuntu ?
<ogra_> (seems it is readonly)
<Chipaca> sergiusens: there's going to be "more coming" all week :)
<Chipaca> sergiusens: this one is probably a good place for it as any
<Chipaca> sergiusens: next one *should* be the move to make a lot of things methods on SnapPart, but i've had branches pop up in the middle of this before now :)
* asac changed the topic of #snappy to: Our 4 Forces: Snappy for Things: http://www.ubuntu.com/things || Snappy for Cloud: http://www.ubuntu.com/cloud/tools/snappy || Snappy for App Devs and Porters: https://developer.ubuntu.com/en/snappy/ || Snappy for Bugs: https://bugs.launchpad.net/snappy :P
<asac> ogra_: i have no idea how to change anything wrt access settings etc... so just changed it. if we want to change acls etc. or you need op powers talk to lool :P
<asac> or i think it was beuno
<ogra_> i'm not eager to get op powers ... usually if there is a troll i'm still searching for the right commands to gain OP when someone else already kicks him :)
<rickspencer3> is this really the right way to set up wifi on my bbb?
<rickspencer3> http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html
<rickspencer3> seems like making the partition rw is sub-optimal
<Chipaca> rickspencer3: if it needs you to set the partition rw, it is not the right way
 * Chipaca reads
<Chipaca> rickspencer3: we're shipping wpa_supplicant already
<Chipaca> rickspencer3: so the post is wrong, but also outdated
<rickspencer3> Chipaca, so I just need to drop a config file somewhere?
<ogra_> looks like
<Chipaca> rickspencer3: beats me :) but either drop it or edit it
<Chipaca> (i can find out, certainly, but i don't know offhand)
<mvo> Chipaca: launcher> if you mean that instead of generating all this env madness in the wrapper script it should go into the launcher, thats a plus one from me, we just need to make sure that we do as little as possilbe in the part that runs as root, but thats obvious anyway :)
<Chipaca> mvo: it would mean changing the way we call the launcher (we need to give it the version and origin and some other stuff)
<mvo> sergiusens: reading the etherpad now
<mvo> Chipaca: yeah, I'm fine with that as long as its not too ugly :)
<Chipaca> mvo: the alternative being to parse yaml in C
<Chipaca> *shudder*
<mvo> LOL
<mvo> as root!
 * mvo drops dead in shock
<mvo> sergiusens: dot.store looks good, I'm a bit unhappy that /frameworks and /apps have a different dir layout now, i.e. one with /$origin/ in there and the otherwithout, but its not a big deal and probably unavoidable, I guess I just like symmetry :) I will add some inline comments
<beuno> ogra_, I haz the power
<beuno> (so does the ubuntu IRC council)
<ogra_> yeah, thats usually my last resort :)
<beuno> ogra_, happy to give you access
<ogra_> nah, i'm find pinging someone with power ... we usually dont lock the topic iin ubuntu channnels though
<dholbach> ogra_, does it work for you now?
<ogra_> dholbach, havent gootten to chatoom yet ... i'll let you know then
<dholbach> <3
<rickspencer3> does this look to anyone like i have my wifi configured properly?
<rickspencer3> http://pastebin.ubuntu.com/11244005/
<dholbach> mvo, I'm looking at a tutorial which seems partly to depend on python being in the Ubuntu Core image - do you have plans to change that? :)
<beuno> rickspencer3, depends what properly means. No IP address, not connected to anything
<rickspencer3> beuno, right
<rickspencer3> so, that's a "no" :)
<mvo> dholbach: sort of, for 16.04 it will most likely change, for 15.04 it will stay (unless asac decides otherwise :)
<dholbach> ok... do you have a bug open for it?
<rickspencer3> beuno, does this look right? http://pastebin.ubuntu.com/11244055/
<ogra_> rickspencer3, no, remove the EOF
<rickspencer3> dang it
<ogra_> the rest looks fine
<rickspencer3> I assumed the EOF would be ignored
<beuno> also, now we can all park in front of rickspencer3's house and leach off the wifi
<ogra_> it is the second half of the "echo" in the blogpost :)
<rickspencer3> oh fudge
<rickspencer3> lol
<ogra_> if you remove the echo line you also need to remove the EOF
<rickspencer3> ogra_, I think I am looking at the wrong thing, can you give me the link again?
<ogra_> dholbach, there are more issues with node-snapper (just starting to inspect them)
<ogra_> rickspencer3, which link ?
<ogra_> http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html ?
<rickspencer3> ogra_, oh, I thought you were referring me to a blog post with instructions
<rickspencer3> let me look
<rickspencer3> right, that's the one I used
<rickspencer3> but since Chipaca told me that wpa supplicant was already installed, I skipped installing the debs
<ogra_> well, you need the config
<rickspencer3> so I need to make it ro afterall?
<rickspencer3> that seems pretty horrible
<ogra_> and you need:
<ogra_> sudo chmod go-r /etc/network/interfaces.d/*
<rickspencer3> yeah, I did that
<ogra_> no, you shouldnt need to make it ro
<ogra_> err
<ogra_> rw
<ogra_> that dir should be rw
<rickspencer3> right, rw, worry
<rickspencer3> ogra_, so I don't need to install the debs, right?
<ogra_> so that you can create /etc/network/interfaces.d/wlan0
<ogra_> no, you dont need to
<rickspencer3> right, so I made the config file
<rickspencer3> I chmoded the file
<ogra_> right
<ogra_> so you should be able to bring up the interface now
<ogra_> sudo ifup wlan0
<rickspencer3> oh
<rickspencer3> I can't just plug it in?
<rickspencer3> seems suboptimal that I have to connect to ethernet to turn on wifi ;)
<ogra_> not sure that triggers a connect
<ogra_> it should come up on boot ...
<rickspencer3> oh, ifup said the interface was already configured
<ogra_> but i dont know if anything would call "ifup wlan0" if you plug it in
<ogra_> so ifdown it first
<rickspencer3> ogra_, I assumed that the  allow-hotplug wlan0  line meant I could just plug int eh dongle when I want
<ogra_> might be configured with old settings
<rickspencer3> still no ip address :/
<ogra_> iirc it just means the interface can vanish and appear
<rickspencer3> ok
<ogra_> but i might be wrong
<rickspencer3> well, ifconfig sees the dongle, just doesn't have an ip address
 * rickspencer3 tries different dongle
<rickspencer3> oops, the Belkin dongle categorically does not work :/
<ogra_> dholbach, seems the armhf build of the node modules completely fails in wily ... (i get a proper amd64 tarball though)
<ogra_> that will need some more love
<rickspencer3> so Netgear one is recognized, but still does not get an IP address
<ogra_> rickspencer3, hmm ... i think the underscores there are wrong
<rickspencer3> interesting
<rickspencer3> ogra_, just delete those?
<ogra_> try wpa-ssid and wpa-psk
<rickspencer3> i got some interesting messages that time :)
<rickspencer3> ogra_, http://pastebin.ubuntu.com/11244254/  ?
<ogra_> so it tried to get the ip vis dhcp but wasnt connected to the AP i would say
<ogra_> does ifconfig list the wlan0 interface ?
<dholbach> mvo, do you have a bug open for moving off of python?
<rickspencer3> ogra_, yes, iconfig lists it
<rickspencer3> ogra_, ima try a reboot
<ogra_> and iwconfig ?
<rickspencer3> command not found
<ogra_> aha
 * rickspencer3 braces
<ogra_> well, i'm not sure if wpa_supplicant actually needs it installed
<ogra_> (it is just helpful for debugging to see if there is an AP connection)
<ogra_> rickspencer3, check the dmesg output when connecting the thing ...
<ogra_> dmesg | tail -50 ... or so
<rickspencer3> k
<ogra_> (or -100 for more lines)
<tbr> also checking the packet counters for the interface might give an indication if there is anything working
<ogra_> yeah
<ogra_> in ifconfig that is
<rickspencer3> let me do ifdown/ifup and get dmesg first
 * ogra_ needs to move for a meeting ... brb
<rickspencer3> ogra_, kk
<rickspencer3> http://pastebin.ubuntu.com/11244363/
<rickspencer3> ^for when you get back
<asac> rickspencer3: you have your interfaces files in a paste?
<rickspencer3> asac, yes, let me get you the latest
<rickspencer3> asac, http://pastebin.ubuntu.com/11244393/
<rickspencer3> this time I removed my password ;)
<ogra_> hmm
<asac> heh
<ogra_> [ 1894.677595] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_host (91, <VBusValid), retry #1, port1 00000507
<ogra_> missing firmware ?
<asac> rickspencer3: does that dongle work on your desktop?
<asac> good to check there first before trying to go embedded :P
<rickspencer3> asac, yes, but ... for all I know I had some non-free drivers installed
<asac> ahh
<rickspencer3> I don't recall installing non-free drivers, though, tbh
<rickspencer3> I haven't used the thing in quite some time
 * rickspencer3 tries on laptop
<ogra_> well, might be that it needs a realtek driver or firmware
<rickspencer3> I plugged it into this laptop and it started blinking instantly
<rickspencer3> and network manager sees all the networks with it
<ogra_> check if you have /lib/firmware/rtlwifi/
<rickspencer3> ogra_, on my laptop, yes, there are a bunch of files in there
<ogra_> might be needed by that card
<rickspencer3> ogra_, it looks like I have the exact same files on this laptop as on snappy
<rickspencer3> let me confirm that I use the card
<rickspencer3> brb
<rickspencer3> works perfectly on the laptop
<rickspencer3> ogra_, rtlwifi looks exactly the same
<rickspencer3> http://pastebin.ubuntu.com/11244579/
<elopio> mvo: I was going to ask why the selftests were in a separate branch.
<elopio> nice work there.
<mvo> elopio: thanks! I am in a meeting right now, but I would love to get your input in how we can make the tests better and what needs to be changed on the CI side once we move the tests into snappy itself
<elopio> mvo: ok, lets talk. I think today we are full of meetings on the sprint. Maybe better tomorrow.
<mvo> elopio: ok
<rickspencer3> Chipaca, sorry, I forget, you told me to look at go-example-webserver for a template for a new go snap, right?
<sergiusens> mvo: I preferred having $origin in there as well, but what apparmorish thing will we break?
<sergiusens> mvo: the security tools have no concept of origin/namespace, so maybe we can teach it through _$version.yaml?
<beowulf> lool: hey, sorry, was it you who pinged me about webdm icon size on an xps screen?
 * beowulf wants to know if it's a 4k screen, and if the pixel density is 141 or 282
<Chipaca> rickspencer3: yes, want the url again?
<rickspencer3> Chipaca, no thanks, I branch snappy-examples, just wanted to make sure I was using the right project in there
<Chipaca> rickspencer3: it's the one that seems closed to what you said you wanted
<rickspencer3> thanks Chipaca
<Chipaca> rickspencer3: or rather, to what i understood you said you wanted
<Chipaca> closest*
<noise][> rickspencer3: fwiw, i got a wifi dongle working on my bbb with just the config file
<rickspencer3> :(
<rickspencer3> noise][, what kind of dongle?
<rickspencer3> brand, I mean?
<noise][> cheap? :) lemme check
<rickspencer3> it just seems weird that it works instantly with the laptop and not with snappy
<noise][> "LB-Link" , Manufacturer: Realtek
<noise][> interface came up on 1st try but wasn't pinging - i had to disconnect the ethernet and reboot for it to actually work
<rickspencer3> hmmm
<rickspencer3> noise][, can you paste-bin your config for me?
<noise][> http://pastebin.ubuntu.com/11246101/
<noise][> added that, did the chmod as in the blog post and was good to go
<beowulf> Chipaca: hi, where did you get/create the icon for 8nzc1x4iim2xj1g2ul64 43
<Chipaca> beowulf: isn't it the hello world one?
<beowulf> Chipaca: so you copied it from little jimmy?
<Chipaca> beowulf: revision 42's description was "hello world"
<Chipaca> beowulf: I did not invest significant amounts of time in that package
<beowulf> Chipaca: understood, i'm just curious as to where the broken svgs came from
<Chipaca> beowulf: ehlo wurld
<beowulf> they're missing xmlns and xmlns:xlink attrs, so browsers turn their nose up in disgust
<Chipaca> beowulf: i blame ... barry!
<barry> sure, why not? :)
<Chipaca> always breaking svgs
<Chipaca> it's what he does between gigs
<barry> :)
<mterry> jdstrand, is a confined app allowed to run inotify_init1()?
<jdstrand> mterry: not atm. that is one of the things that is queued up for the ubuntu-core-security SRU
<mterry> jdstrand, interesting.  Right now my app halts on that call.  Is that expected?
<jdstrand> yes
<mterry> :(
<mterry> jdstrand, that's an intense version of failure
<jdstrand> mterry: to unblock yourself, modify /var/lib/snappy/seccomp/profiles/<profile for your app> to include inotify_init1
<jdstrand> mterry: that is a limitation of seccomp
<mterry> jdstrand, ah really?  ok
<jdstrand> you can log or kill
<jdstrand> you can't log and silently fail
<jdstrand> sorry, you can log and kill, you can't log and not kill
<mterry> jdstrand, is there an example of some package.yaml that allows this call?  Or do I have to really manually modify this thing as a temporary hack?
<jdstrand> meh, I am really not explainging myself
<mterry> jdstrand, I think I get ya
<jdstrand> you can log and allow. you can log and kill. you cannot silently fail
<jdstrand> anyway
<jdstrand> yeah-- add that to your profile and you'll be fine
<mterry> jdstrand, would i have to do all the inotify_* api then I guess?
<mterry> jdstrand, you mentioned being queued up for an SRU, but I'm on wily/rolling
<mterry> jdstrand, will wait for end of meeting, sorry
<jdstrand> mterry: maybe, maybe not. this is what we will be adding: http://paste.ubuntu.com/11246583/
<jdstrand> mterry: oh, if you are on wily, I can get this uploaded soonish
<mterry> jdstrand, this inotify thing blocks any app using the sdk.  that's how I hit it  :)
<mterry> jdstrand, because QFileSystemWatcher uses inotify
<ogra_> dholbach, just FYI, chatroom works for me now ... i'll diff the changes i did on the snappy system to get it to work and push that to the branch
 * dholbach hugs ogra_
 * ogra_ finds it weird to watch himself from two different angles while working :)
<dholbach> I'm going to be off the grid for a few days starting in just a few minutes, but I'll test the instructions again as soon as I'm back and publish the tutorial :)
<ogra_> dholbach, cool
<ogra_> i'll probably do a series of blog posts packaging other nodejs stuff
<dholbach> <3
<ogra_> since i need to update all of my packages anyway
<ogra_> (and most of them use node)
<dholbach> right
 * ogra_ wants os.js in the store ... thats really awesome :)
<ogra_> full desktop in a browser :)
<Chipaca> we should make sure snappy runs on the in-browser linux emulator thing
<Chipaca> then use that to run os.js
<jdstrand> mterry: yes, it was an omission in part because no one until now has tried to use it. we decided to add it, but cause no one hit it, it wasn't top priority
<jdstrand> mterry: I'll get that uploaded to wily today/tomorrow
<mterry> jdstrand, understood.  Not pushing ya, just saying how I hit it  :)
<jdstrand> yep
<jdstrand> thank you for bringing it to my attention
<tgm4883> Is there some documented process to go from making regular deb packages to snappy packages? We've got an automated process for making deb packages, but it seems from my reading we need to build binaries then put those in a snappy package before uploading it
<rickspencer3> tgm4883, I think mterry might have made a script to help with that
<tgm4883> rickspencer3: that would be handy. I'd like to get that figured out, then figure out how many dependencies I'm supposed to package as well (eg. mysql-server)
<tgm4883> I mean, for a semi-complicated application that uses apache, mysql and listens for traffic on a non-restricted port, do I put all of that into the same snappy package?
<sergiusens> tgm4883: yes if you intend to run them on the same server
<tgm4883> sergiusens: can snappy packages depend on other snappy packages?
<tgm4883> because installing a separate mysql snappy package and just referencing it over the network would work in theory
<tgm4883> there a bit of this that I'm not sure how it will work. For instance, a mysql snappy package upgrade and rollback. What happens to the database in that scenario?
<tgm4883> I think our mythtv and snappy work really well together in theory, and I'd like to have a mythbuntu snappy release for 16.04, but I'm just having trouble finding what I need for all this
<sergiusens> tgm4883: I'm not sure how the rollback is going to evolve in the future, but right now your data from version 1 get copied over to a data location for version 2; if you rollback to version 1 you essentially rollback to binary and the data
<tgm4883> sergiusens: so the old data then? that actually sounds perfect
<sergiusens> tgm4883: yes, it solve not needed to solve inconsistencies a possible updated version might have caused to your data
<sergiusens> data is essentially versioned in this sense
<tgm4883> awesome, I really like that. With MythTV, if you upgrade from 0.27.X to 0.28.X (which is a major version upgrade) and don't like it. Rolling back means doing a mysql db restore (hopefully a backup was made). This would solve that I think
<tgm4883> sergiusens: so our mythtv snap would need apache, mythtv, and mysql. How far down the dependency hole do I need to go? I'm sure apache and mysql have their own libraries and such they pull in as well
<sergiusens> tgm4883: maybe this will solve it for you https://github.com/mikix/deb2snap
<tgm4883> sergiusens: yep, I think that will help a bunch, thanks
<Chipaca> mterry: just for the record
<Chipaca> mterry: and so you don't feel i've just butted in over what you were saying with sergio
<Chipaca> mterry: i was of the same opinion as you initially, but then we talked with sergio about it (part of his reasoning is in the mp)
<Chipaca> mterry: and, yeah, we want to test what we control
<Chipaca> mterry: in the fullness of time the test would be "the error fits this type: <very specific error type>"
<Chipaca> mterry: we'll have to do that when we ourselves internationalize our strings
<Chipaca> mterry: but meanwhile... this
<sergiusens> Chipaca: what was mterry telling me though?
 * sergiusens is lost
<Chipaca> sergiusens: C.UTF-8
<sergiusens> Chipaca: oic, that comment was from mterry not you :-P
<Chipaca> heh
<Chipaca> yeah
<Chipaca> great minds etc etc
<mterry> sergiusens, Chipaca: well OK, I get testing what we control
<mterry> sergiusens, Chipaca: so for this MP, fine.  But *also* when we do test our own strings, we should probably run as C.UTF-8
<Chipaca> mterry: hmmm... but then catching the ones we're testing wrong is harder :)
<sergiusens> mterry: yeah, we should add that to the suites
<sergiusens> mterry: as well ;-)
<Chipaca> agreed
<mterry> group hug!
<Chipaca> woo!
<sergiusens> Chipaca: this brings the need to bring in that go code we have for gettext
 * sergiusens joins the hug
<rickspencer3> sooo, if I just want to have an app that uploads a certain image in a certain directory every n minutes ... it just occurs to me that I could make a snap out of shell script?
<rickspencer3> would it be that easy
<Chipaca> rickspencer3: ssh, we're hugging, come back later
<rickspencer3> uh
<Chipaca> rickspencer3: that sounds suspicioulsy like the camera snap
<Chipaca> suspiciously*
<Chipaca> rickspencer3: i think asac wrote that one
<rickspencer3> Chipaca, you mean lool's web cam snap?
<Chipaca> based on a look snap
<Chipaca> lool*
<sergiusens> lool wrote it iirc
<rickspencer3> I don't think it uploads, though
<Chipaca> rickspencer3: yeah
<Chipaca> rickspencer3: ok, expand on "uploads" :)
<rickspencer3> sorry to be dense, but a light bulb just cam on over my head
<sergiusens> correct, doesn't upload
<rickspencer3> Chipaca, I want to upload the image to the cloud
<sergiusens> rickspencer3: should be doable
<rickspencer3> and it just occurs to me I can stop with this go code and use curl in a loop with sleep in shell script
 * rickspencer3 checks if curl is available
<sergiusens> rickspencer3: doing the loop in go is relatively easy
<Chipaca> rickspencer3: you'd need to bundle something that POSTs
<Chipaca> rickspencer3: no curl
<rickspencer3> sergiusens, yeah, but CreateFormField looks hard
<Chipaca> rickspencer3: no wget
<rickspencer3> oh
<rickspencer3> so there goes that
<Chipaca> rickspencer3: what are you writing it in?
 * rickspencer3 goes puts tail between legs and returns to go docks
<rickspencer3> Chipaca, this is my first Go program
<Chipaca> rickspencer3: i've got to go put boys to bed, but when i return i can point you at code you can copy-paste for the POSTing
<Chipaca> that is if sergiusens doesn't beat me to it
<rickspencer3> that would be nice
<rickspencer3> I was going to use imgur to start, since I already have an API key
<rickspencer3> but need a nicer cloud service for it
<Chipaca> rickspencer3: you'd do oauth2?
<Chipaca> rickspencer3: that's probably rather tricky for a first go program :)
<rickspencer3> Chipaca, doesn't look that way
<rickspencer3> I just need to supply the api key in the form data
<rickspencer3> what I really need is a place that I can upload to and have a known url, but, ironically, I *just* canceled my shared hosting account
<Chipaca> rickspencer3: from the imgur api i'm reading, it's oauth2
<Chipaca> rickspencer3: e.g. https://github.com/Imgur/imgurpython/blob/master/examples/auth.py
<Chipaca> rickspencer3: that's imported by the other example, upload.py
<Chipaca> rickspencer3: maybe you're using an old api? or maybe i'm missing something
<rickspencer3> hmmm
<rickspencer3> perhaps they changed it
<Chipaca> rickspencer3: if you show me how you would've used curl (edit out the key if you will), i'll implement that in go
<rickspencer3> in the past I just included my api key in the post data
<rickspencer3> Chipaca, too much yack shaving with imgur
<rickspencer3> let me find a better place to host it
<rickspencer3> maybe I'll make a little web server on canonistack or something
<rickspencer3> Chipaca, thanks for the offer, I will probably take you up on it later
<sergiusens> rickspencer3: it can also be snappy/canonistack
<rickspencer3> sergiusens, inception!
<rickspencer3> but, yeah
<Chipaca> rickspencer3: sure, i'll be around for a few hours still
<rickspencer3> so I would make a snap that accepts the form post
<rickspencer3> for that matter, I could make my pi2 the server and my bbb the hub
<rickspencer3> oops, I *could* do that, I mean to say :)
<Chipaca> rickspencer3: if you're doing that, you could blat it using netcat :)
<rickspencer3> http://i.imgur.com/DWrI2JY.gif
<sergiusens> rickspencer3: pseudo code http://paste.ubuntu.com/11250452/
<sergiusens> well, the post is there but the what and where's are open
<sergiusens> Chipaca: ^ not sure that satisfies you
<Chipaca> wfm
<sergiusens> Chipaca: I forgot if there is a way to not need an http.Client{} instance and have a Post with headers and a body
<lool> beowulf: yes, well I raised the issue actually; with webdm from store from 10 days ago or so, there's a fixed amount of icons whatever the screen size and browser zoom levels; it would seem like it should be adapted
<sergiusens> Chipaca: I pushed updates to TheOrigins MP; the security.md was just a bad merge
<Chipaca> sergiusens: hah
<sergiusens> Chipaca: I merged trunk as there were conflicts and those were the conflicting lines, but the nice coloring failed to show :-P
<sergiusens> oh, jdstrand I forgot to ask, if I change frameworks to live in /frameworks/$package_name/$origin/$version what are the apparmor implications?
<sergiusens> same for /apps btw
<sergiusens> I guess it means we move away from APP_ID == $package_name[.$origin]_$binary_$version
<sergiusens> I guess my question is, can the templates learn about $origin to know how to expand all the dirs?
<sergiusens> And remove it from the APP_ID itself
<mterry> jdstrand, can default-confined apps bind abstract sockets?
<mterry> jdstrand, looks like no?  But I'm not an expert on this syntax
<Chipaca> tyhicks: you around?
<tyhicks> Chipaca: hello!
<Chipaca> tyhicks: thanks for the review(s)!
<tyhicks> Chipaca: no problem - thanks for all the quick fixes :)
<Chipaca> tyhicks: was wondering one thing
<Chipaca> tyhicks: wouldn't it be better/simpler if we mounted our own tmp, at this point
<Chipaca> tyhicks: it'd get unmounted (and nuked) on process exit, right?
<tyhicks> Chipaca: what you have now is getting unmounted on process exit (but the source dir isn't being removed)
<tyhicks> Chipaca: if we mounted our own tmp, where would it come from?
<Chipaca> oh, drat
<Chipaca> tyhicks: i was thinking tmpfs /tmp. and that's not a given
<Chipaca> bummer
<tyhicks> I thought about that
<tyhicks> but I think we're really close to landing these changes and I think what you have now is a good solution
<Chipaca> about cleanup, it'll have to be done by cron or something similar i guess
<Chipaca> tmpreaper or whatever it's called
<Chipaca> not sure if there's a better way
<Chipaca> unless we can rmdir something that's the source of a bind mount
<tyhicks> I don't think we can rmdir that
 * Chipaca grins eveily and goes off to try
<Chipaca> well, you can rm an open file. i don't think it'll work either, but :)
<tyhicks> what we can do is chdir to the directory that mkdtemp() creates, then rmdir(".)
<jdstrand> mterry: no. we will have a mechanism for that when the 'sockets' yaml is implemented (see docs/security.md for details)
<jdstrand> mterry: what is it that you are trying to do?
<tyhicks> Chipaca: but changing back to the previous working directory is dangerous to attempt from the privileged section of the cod
<mterry> jdstrand, trying to run a session dbus-daemon inside a snap
<tyhicks> code*
<mterry> jdstrand, by default it tries to use an abstract socket
<jdstrand> mterry: yeah, you can't do that
<mterry> jdstrand, but I can ask it to use a path socket
<Chipaca> well, that's weird
<jdstrand> yes, you can
<Chipaca> tyhicks: i could rmdir the source just fine
<tyhicks> oh
<Chipaca> tyhicks: but then i couldn't create things in the target
<mterry> jdstrand, I assume no access to system bus by default either
<Chipaca> let me try that again
<jdstrand> but only apps shipped in your snap will be able to access the file based one
<mterry> jdstrand, yeah
<jdstrand> mterry: that is correct
<mterry> jdstrand, I'm just trying to get a kiosk-style run of an sdk app (ubuntu-clock-app)
<mterry> jdstrand, it's been interesting so far  :)
<jdstrand> mterry: now, frameworks may ship a dbus service, and then ship framework-policy for clients to connect to it
<tyhicks> Chipaca: I see the same behavior you described
<mterry> jdstrand, seems like that's what we'll need for this sort of use case
<Chipaca> tyhicks: yep, mounting foo -> bar, rmdir foo works, but then touch bar/blah fails with no such file or directory
<jdstrand> mterry: see hello-dbus in snappy-examples
<jdstrand> mterry: (and install hello-dbus-fwk and hello-dbus-app to see it in action)
<jdstrand> mterry: this is part of the whole app isolation story. they really are isolated :)
<jdstrand> mterry: but, like I said, there will be more flexibility for non-framework people when 'sockets' is implemented in the yaml
<jdstrand> mterry: with that a 'server' will be able to specify the abstract socket path it will serve on, then the server snap can specify which client snaps can connect to it
<mterry> jdstrand, I get it and the isolation is thumbs up for me.  I've just been trying to work around it for demo purposes
<Chipaca> tyhicks: the only problem i see with leaving the tmpdir lying around is if something misbehaves and respawns a bunch of times and you run out of inodes on tmp
<jdstrand> mterry: if you were able to work around it, then we would have found a hole. if you do find a hole, please report it :)
<tyhicks> Chipaca: yeah - I expect you'll run out of possible tmp dirs (from mkdtemp()) first
<jdstrand> that way I can close it for you :)
<mterry> jdstrand, not like *WORK AROUND IT*, but just run a local dbus daemon for my snap
<Chipaca> tyhicks: ah, good point :)
<Chipaca> tyhicks: and i catch and abort on those, so \o/
<tyhicks> Chipaca: ah, there you go
<jdstrand> mterry: I can't think of anything that would stop you from shipping multiple binaries/services within a single snap that would block you from using a file based path
<tyhicks> Chipaca: I think about this some more
<Chipaca> tyhicks: ok, i'll fix the issues you found already :)
<tyhicks> Chipaca: thanks! (note that I screwed up the white space in the patch I pasted for the apparmor profile)
<jdstrand> mterry: but as soon as you are talking about running a service for other snaps to use, you are in framework (or the aforementioned future coordinated snap socket) territory
<mterry> jdstrand, yeah no -- my problems are just discovering where a simple SDK app pokes out and fill in what it needs (now it's trying to connect to system bus and I have to figure out why and what to do about it)
<mterry> jdstrand, right, I don't care about that use case right now
<mterry> just an internal-snap thing
<Chipaca> tyhicks: ah, i thought it was launchpad, or gmail, doing it for you
<jdstrand> I see
<jdstrand> ok, well, good luck! :)
<mterry> jdstrand, but it's hard enough that I may just throw up my hands and say "we need to get a proper sdk framework for this demo"
<tyhicks> Chipaca: that's always possible, too :)
<Chipaca> tyhicks: ooh! i should chmod 01777 it, too
<Chipaca> bah
<Chipaca> dunno
<jdstrand> tyhicks: curious, in our dbus testing, did you ever setup a name-based socket non-system bus service?
<Chipaca> i guess just for completeness :)
<tyhicks> Chipaca: I was going to suggest that but then when I noticed that it was 700, I kept quite
<tyhicks> Chipaca: if it needs to be world-writeable, please do set the sticky bit
<Chipaca> tyhicks: yeah, might as well leave it like that
<tyhicks> jdstrand: I'm not following - do you have an example?
<tyhicks> oh
<jdstrand> tyhicks: start a local non-system, non-session dbus server that listens on say, /tmp/foo.sock
<jdstrand> rather than @foo
<tyhicks> jdstrand: I probably did not test the scenario
<jdstrand> s/ server/-daemon/
<jdstrand> tyhicks: that's ok. just wondering if you then we could point mterry out the apparmor tree
<jdstrand> at*
<mterry> jdstrand, in my case it would be a session bus (you said non-session)
<jdstrand> well, isn't it just a private bus?
<mterry> jdstrand, oh I suppose.  Like just for my snap.  But I guess I meant, it's a user bus
<tyhicks> I know that people have used dbus mediation on private busses
<tyhicks> I think mardy used one for online accounts
<jdstrand> I guess it would use --session
<jdstrand> but you override --address
<tyhicks> I can test this pretty quickly by modifying tests/regression/apparmor/dbus.conf (in the apparmor tree) and running the regression tests
<jdstrand> --session --address=$SNAP_APP_DATA_PATH/foo.sock ...
<mterry> jdstrand, exactly
<tyhicks> jdstrand, mterry: I was able to run through the AppArmor D-Bus mediation regression tests after applying this diff: http://paste.ubuntu.com/11251491/
<tyhicks> jdstrand, mterry: They all passed
<jdstrand> mterry: you might need the network-service cap
<tyhicks> (ran on Wily, against apparmor 2.9.1-0ubuntu9 and dbus 1.8.12-1ubuntu5)
<jdstrand> mterry: do you have seccomp denials?
<jdstrand> tyhicks: thanks! :)
<tyhicks> np
<asac> Chipaca: rickspencer3: right the webcam-demo snap takes snapshots and puts that in a directory that you can then look at with webrowser...
<asac> you could certainly improve it... make configurable the timeout etc.
<rickspencer3> asac, I want to upload those images to a cloud
<rickspencer3> that's the only enhancement
<mterry> jdstrand, I'm not entirely sure what my current blocker is... I'm seeing failure to connect to /run/dbus/system_bus_socket.  I'm seeing capability denials for dac_read_search and dac_override
<mterry> jdstrand, plus some other failures
<mterry> everything is dying
<mterry> jdstrand, also.. a denial for a read on /home/ubuntu/apps/clockit.sideload/3/.local/share/com.ubuntu.clock/user-preferences ?  I would have expected that to be allowed
<mterry> jdstrand, ignore tht
<mterry> jdstrand, that's because I was mixing sudo and user files
<mterry> So just the system bus access...  I'll figure it out
#snappy 2015-05-21
<tgm4883> So if I'm suppose to put binaries inside this snappy package, does that mean I need multiple packages to be able to support multiple arches?
<davidcalle> Good morning
<ogra_> tgm4883, you can put all arches into one (in subdirs) at the cost of size ... and have a wrapper script select the right binaries
<willcooke> Thinking out loud here; on Desktop with Snappy, once all the apps are moved out of the image and in to Snaps, lets assume that there is a security update required in a particular "thing" in the image.
<ogra_> you will get an image upgrade
<willcooke> At the moment we can update individual libraries, within reason
<willcooke> and so we could be pushing out an update a week on U7/.deb
<willcooke> and that might be a few hundred K
<willcooke> In the Snappy world, does this mean we would push out a whole new image?
<ogra_> on snappy it will be less
<willcooke> And if so, it's likely to be large
<ogra_> since we provide deltas ...
<willcooke> ahh, nice
<willcooke> yes
<willcooke> deltas FTW
<willcooke> thanks ogra_
<ogra_> so you only recieve the changes, not a full new package
<ogra_> they will be bundled in an image upgarde though, that is indeed right
<willcooke> but that upgrade could be tiny
<ogra_> it is likely big because we'll collect a bunch of issues in an upgrade ... but the single fix is smaller overall
<ogra_> (and for security issues there might be hotfix images with only that one change perhaps)
<willcooke> So are you saying it would be upgraded less frequently?
<ogra_> on the phone we currently manage 4-6 week cycles
<willcooke> oki
<willcooke> that's impressive :)
<ogra_> but that is with all QA resources used already
<ogra_> i suspect we need to get better here as we spread the spectrum of images
<willcooke> +1
 * willcooke speaks to QA
<willcooke> seb128, fyi (but I expect you already knew all this) ^^
 * willcooke -> meeting
<willcooke> cheers ogra_
<willcooke> always a pleasure
<ogra_> :)
<seb128> willcooke, yeah, but thanks for the ping anyway ;-)
<JamesTait> Good morning all; happy I Need A Patch For That Day! ð
<Chipaca> mvo: you around?
<Chipaca> mvo: ullo?
<mvo> Chipaca: hey
<Chipaca> mvo: hiya
<Chipaca> mvo: was looking at https://code.launchpad.net/~mvo/snappy/selftest-docker-robustness/+merge/259734 and wondering why you don't use systemctl's pattern instead of passing it through grep?
<mvo> Chipaca: I don't know, I guess using systemctl makes way more sense :)
<Chipaca> mvo: it's a glob, not a regex, but other than that
<mvo> Chipaca: cool, I will update, thanks a bunch
<Chipaca> mvo: on the other hand
<Chipaca> mvo: systemctl does not fail on no matches
<Chipaca> mvo: so you either still need to grep (in which case, meh), or do something like
<Chipaca> systemctl show whatever*.service --property 'Id'
<Chipaca> and check for empty string
<Chipaca> mvo: and at this point i think i'm bikeshedding :)
<Chipaca> mvo: sorry. will +1 as is.
<Chipaca> there
<mvo> Chipaca: :)
<mvo> Chipaca: all good, thank you very much
<Chipaca> mvo: sergiusens: did you guys see my email wrt tmpreaper?
<mvo> Chipaca: yes, I think its a good idea I need to reply properly
<Chipaca> ah, ok
<mvo> Chipaca: had a bit of a single-minded-hacking morning with the upgrade tests
<Chipaca> i'm not impatient about the response, it's that i so rarely shoot off emails like that i wondered if it was still an effective means of communication :)
<sergiusens> Chipaca: it is effective at getting to people, not sure about getting back a proper response :P
<Chipaca> :)
<asac> anyone understands the "Can we make renames work?
<asac> "
<asac> thread?
<asac> is that an issue at all for snappy?
<asac> or just phone?
<asac> mvo: ?
<ogra_> asac, it is an issue with processes trying to create a backup file or some such when you have no writable dir (but only made the file writable via a bind mount)
<ogra_> i suppose it affects snappy too if bind mounts are used for wriability
<ogra_> *writability
<mvo> well, we generally know what wants to write
<ogra_> well, for creating a new file we have no concepts with the bind mounts
<ogra_> imagine my daemon creates /etc/foo.conf-bak every time it writes to /etc/foo ... if /etc/foo.conf-bak doesnt exist as a bind mounted empty file and /etc isnt writable the daemon will fail to make the backup file
 * Laney was summoned
<ogra_> so you either need to know in advance how that backup file (or worse, temp file) is called and have an existing bind mount ... or /etc is writable
<Laney> renaming a mount point doesn't work
<ogra_> right
<Laney> that's why we have to have the directory
<Chipaca> I think xnox'es âconig-lessâ efforts line up with this quite nicely, me
<ogra_> the directory Laney refers to is /etc/writable ...
<Chipaca> config-less*
<ogra_> so the hack we currently use is to put /etc files into that dir and add an additional bind mount on top
<Laney> kind of, but you still want to have atomic renaming work
<ogra_> that way the process finds a writable dir to do its atomic changes and temp file creation etc
<sergiusens> ogra_: mvo asac it shouldn't affect snappy core, we have mostly nothing in there
<ogra_> asac, effectively it boils down to "we should use overlayfs, but if we cant it would be nice to find something more elegant than bind mounts to allow atomic writes"
<ogra_> sergiusens, my mount command disagrees
<ogra_> (and my fstab too)
<sergiusens> ogra_: your daemon can't create /etc/foo.conf-bak though, that would never be accepted
<ogra_> heh, someone tries IRC on his phone :)
<mvo> well, I think the end goal is what pitti wrote, move stuff out of etc. and like sergiusens said, not a biggie for us on core yet
<ogra_> sergiusens, it can ... if we use the /etc/writable hack
<ogra_> that is why we have it :)
<ogra_> (amd64)ubuntu@localhost:~$ ls /etc/writable/
<ogra_> hostname  localtime  timezone
<ogra_> and we even use it on snappy
<sergiusens> ogra_: I don't like /etc/writable though
<ogra_> sergiusens, nobody does, that is what the discussion is about :)
<sergiusens> ogra_: I thought it was more general though, random libraries wanting to do things on read only locations
<ogra_> i'd keep /etc writable and put an apparmor profile on top making everything readonly with a whitelist of exceptions ... done
<sergiusens> ogra_: the problem of making global locations writable is that you would need to maintain compat, we also need to be able to rollback (for the a/b model)
<ogra_> sergiusens, it surely is a wider thing long term ... currently the only big wart we have is /etc/writable ... in the future we would probably end up with /usr/lib/writable, /var/writable and so on
<ogra_> before we have to do the latter we should have found a better mechanism ;)
<asac> Laney: thanks. i was confused what this rename thing means for snappy
<asac> but i think others understand it so i will have them explain it to my small brain :)
<Laney> oh yes I think it's a well known problem
<Laney> just came up once again so I thought we better think about it systematically :)
<jgdx> question, why the xz format for snappy images?
<ogra_> size
<mvo> jgdx: my guess is best compression ratio, do you see a issue with that or are you just curious?
<ogra_> (it comes originally from the size limitation the /cache partition puts upon us on phones)
<jgdx> mvo, just curious, but a friend of a friend has an issue with image downloads not being consistent in format
<jgdx> device tarballs, ubuntu desktop isos, snappy xz :p
<mvo> heh :) fair point
<sergiusens> jgdx: well snappy is a deb though ;-)
<seb128> sergiusens, mvo, hey, is there any documentation somewhere on installing snappy on a amd64 laptop config (if that's even possible, or if it's not is anyone working on that)?
<mvo> seb128: you can just dd the image to a usb stick or hdd and boot from that
<sergiusens> seb128: we have nothing yet that can lay it out on your internal disk in an easy way and no docs specifically mentioning laptops but running from a usb drive is possible
<seb128> mvo, does that support secure boot/uefi?
<sergiusens> it should support uefi (the published images don't yet)
<seb128> my test laptop doesn't boot from unsigned device I think
<mvo> aha, nice, so u-d-f images can now do uefi? thats cool
<seb128> I once tried to boot a i386 desktop iso and the system was not even seeing the key as a boot device
<seb128> sergiusens, so I need to use an "unpublished image"? where do I find those?
<sergiusens> mvo: yes, slangasek added support for uefi to u-d-f
<sergiusens> seb128: you need to create one
<elopio> good morning.
<seb128> sergiusens, any documentation on how to do that? ;-)
<elopio> mvo: want to talk about the tests now? Should we just chat here?
<ogra_> sergiusens, i think there is currently a bug with UEFI ... i saw slangasek and tbr discuss it recently
<sergiusens> oh
<ogra_> bug 1425370
<ubottu> bug 1425370 in goget-ubuntu-touch (Ubuntu) ""ubuntu-device-flash core" images can't boot with UEFI" [Undecided,Fix released] https://launchpad.net/bugs/1425370
<sergiusens> seb128: in theory just running 'u-d-f core 15.04 --output amd64.img' should do the trick
<seb128> sergiusens, thanks (let's see if practice matches theory ;-)
<sergiusens> seb128: there is documentation but I don't recall where it is, but the bug ogra_ mentions might impact you
<seb128> ogra_, that's fix released
<mvo> elopio: yes please! we can use whatever medium works best for you, irc, hangouts, mumble
<sergiusens> ogra_: yeah, slangasek wrote code to fix that bug ;-)
<ogra_> seb128, yeah, 13h ago ... i'm a little behind :P
<seb128> ogra_, :-)
<ogra_> sergiusens, it was re-opened after that ... but turned out to be the qemu UEFI firmware
<sergiusens> ogra_: I wonder who marked it as u-d-f fails to build (snappy changed)
<elopio> lets just start here, because I might have to leave for a meeting. Not sure what's the schedule for the sprint today.
<ogra_> so it was closed last night again
 * sergiusens needs to catch up on the snappy changes for webdm and u-d-f
<elopio> I'll just list some things I would like to see. We should probably choose only the ones that allow us to go faster and safer.
<rickspencer3> sergiusens, lool, I just set up my rpi2 with sergiusens's latest image, seems to be working perfectly
<elopio> the tests should be independent. You should be able to run them in any order, or select only one and get a good result.
<lool> rickspencer3: cool
<lool> sergiusens: what had you changed? you just included webdm? did you also add fixrtc?
<rickspencer3> sadly, it does not respond to ssh ubuntu@webdb.local, but perhaps that is a user error ;)
<sergiusens> lool: your image was created a day before release, that same day, mvo made oem package types non forkable removing the .origin from them
<elopio> we need a better framework for setups, assertions, and test case definition. Moving to go would solve this, of course. There are also some bash frameworks, but (...)
<lool> sergiusens: ah yes, I have to push the renamed oem snap too
<sergiusens> lool: webdm was built out of the latest snappy so it rejected that package completely (if the layout is wrong I call it a broken system)
<elopio> we need a better report of the results. subunit would be awesome, but junit or anything like that would do.
<elopio> the tests should define their own environment as much as possible. Asserting for regular expressions because we don't fully control the versions we are installing or the messages we are getting back is not so good.
<elopio> and I would like the tests to be more readable, at least the ones that are end-to-end from the point of view to the user.
<elopio> like have every statement in the test be an action, and that would make the test look more like what you get with behaviour-dd.
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 2 (14 days old)
<elopio> finally (for now), we need to start thinking about tests that need actions both from the host and the testbed, like making sure that you can open webdm from your PC.
<nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (12 days old)
<nothal> https://code.launchpad.net/~sergiusens/snappy/ubootNoUnnecessaryRewrites/+merge/259739 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-fix-ftbfs-sbuild/+merge/259479 | Approve: 1 (1 day old)
<sergiusens> rsalveti: ^
<sergiusens> nothal: help me help you
<rsalveti> yeah, that's cool
 * Chipaca hugs nothal 
 * nothal hugs Chipaca 
<Chipaca> was it @help, or was it @list?
<Chipaca> @help
<nothal> "list" To see the available commands ; "help cmd" for specific command help
<Chipaca> @list
<nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
<elopio> maybe it's enough to make sure that it works in localhost, and that you can access the board's ip from outside. Or maybe we need an end-to-end test also for that.
<Chipaca> @help critical
<nothal> show the crtical bugs for self.project (could be a meta project)
<Chipaca> @critical
<Chipaca> @seen mvo
<nothal> Chipaca: [05/21/15 13:17:29] elopio: yes please! we can use whatever medium works best for you, irc, hangouts, mumble
<elopio> mvo: do you have any items you would like to see in the tests?
<Chipaca> @help last
<nothal> Muestra que fue lo Ãºltimo que dijo un usuario.
<sergiusens> lol
<Chipaca> @last sergiusens
<nothal> Chipaca: [05/21/15 13:28:02] lol
<sergiusens> translations :-)
<Chipaca> hal, dance for us
<Chipaca> nothal, dance for us
<Chipaca> duurn
<Chipaca> not all plugins are there :)
<Chipaca> anyway, things like bug #1449032 work
<nothal> Bug #1449032: delay when upgrading <Snappy:Triaged> <http://launchpad.net/bugs/1449032>
<ubottu> bug 1449032 in Snappy "delay when upgrading" [High,Triaged] https://launchpad.net/bugs/1449032
<Chipaca> now now bots, no fighting
<elopio> mvo: http://paste.ubuntu.com/11264293/ so you don't have to dig on the backlog.
<rsalveti> mvo: do we have any sort of brain dump somewhere that describes our goal for self-tests and so on?
<rsalveti> but it seems you're working with elopio already, which is great
<rsalveti> just trying to understand the missing pieces :-)
<mvo> elopio: thanks a lot, that helps indeed :)
<mvo> elopio: and sorry for the delay, was just reading some exciting code from sergiusens and forgot the world around me
<mvo> rsalveti: >< thats my brain right now :P but seriously, I don't think we do have something written down, let me add that to the README and I point you it once thats done(?)
<elopio> mvo: :) no problem. And feel free to disagree.
 * elopio goes to find the exciting code.
<mvo> elopio: http://snappy.asac.ws:9001/p/snappy-better-test and I do not disagree at all
<sergiusens> mvo: thanks for the review, will fix when i get back
<mvo> sergiusens: yeah, no worries, nice to see this branch really
<rsalveti> mvo: yeah, nothing formal, most important now would be the stuff we don't yet have for it, so we keep track while elopio gets up to speed
<rsalveti> but love what you got already
<mvo> has anyone seen "May 21 13:42:07 localhost.localdomain kernel: FAT-fs (mmcblk0p1): IO charset iso8859-1 not found  " before?
<mvo> looks like my BBB is broken
<ogra_> thats a vfat complaint
<ogra_> ppisati, ^^^ do we have the right nls codepages builtin ?
<mvo> ogra_, ppisati: I created https://bugs.launchpad.net/snappy/+bug/1457491 to track this
<ubottu> Ubuntu bug 1457491 in Snappy "Upgrade from r41 to r55 on BBB failed to boot and also to failover" [Undecided,New]
<ogra_> mvo, well, your bootloader partition seems to be unreadable now ... how would it recover from that ?
<ogra_> (givcen the logic for the roll back is actually inside the file it cant read)
<mvo> ogra_: it did recover, i.e. it booted back into r41 after I power-cycled
<ogra_> well, one vfat is corrupt here
<ogra_> i thought jodh added fsck's all over the place for this in initrd
<mvo> right, it seems like it fixed it correctly though
<mvo> it == fsck
<mvo> I can access /boot/uboot/snappy-system.txt and it looks valid
<mvo> and it booted
<ogra_> yeah, but that it cant rollback seems pretty normal to me if it cant read the file ... we perhaps need to add hardcoded logic that forces a reboot when that happens
<mvo> elopio, rsalveti: http://snappy.asac.ws:9001/p/snappy-better-test is a draft to get some background for why and what for the selftest. I (of course) agree that its not ideal and we want to make it better
<mvo> if that looks good I will move it into the snappy-selftest branch
<ppisati> mvo: do you hve the modules installed?
<mvo> ppisati: I don't know, let me look. this is on snappy
<elopio> mvo: what you wrote about running on each MP is gooood.
<mvo> elopio: its partly done in https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests but probably a bit clumsy, I need to wrap my head around adt harder :)
<mvo> elopio: but yeah, I absolutely want this, we had regression before the release that the selftest would have caught if it was run more often (daily is not enough for us, we are a quick bunch :)
<mvo> ppisati: eh, I think I have not because the modules are on /boot/uboot and that is the vfat partition that it tries to mount to find the modules â¦
<elopio> I think I would split the suite in two. One for cli conformance, just making sure that the commands can be called and return a sensible message. (now I understand why the regexes are there)
<elopio> and one that's end-to-end testing stories, or journeys, or however you want to call them.
<elopio> making a note of this.
<elopio> mvo: I saw your branch, and loved it.
<elopio> Still trying to find some time here to focus and give it a try.
<mvo> elopio: I like the idea of splitting this up, thats cool
<ppisati> mvo: ???
<ppisati> mvo: how can the kernel modules be located on the vfat partition?
<ppisati> mvo: they are in /lib/modules/$(uname -m)/kernel/...
<mvo> ppisati: meh, nervermind, I am talking nosense
<ogra_> no, they should be in the initrd
<ogra_> but i think this is rather filesystem corruption, the codepage complaint is just fallout
<mvo> ppisati: its availalbe on both partitions AFAICT (the nls_iso8859-1.ko module), let me dig deeper
<OerHeks> Is there a snappy core build for this? http://www.nasa.gov/image-feature/ten-engine-electric-plane-prototype-takes-off
<ogra_> OerHeks, just send the hardware over to me, i'll port it :)
<OerHeks> just asking before i buy one ogra_
<OerHeks> But it looks like doable
<ogra_> it doesnt really talk about what kind of HW is inside
<rickspencer3> is there an easy way I can ssh into two snappy images running at the same time on my laptop?
<rickspencer3> I want to develop the client and server bits simultaneously, and test them interacting, etc...
<asac> rickspencer3: sure
<rickspencer3> hi asac
<asac> rickspencer3: you start kvm?
<asac> how?
<rickspencer3> yes it is running
<rickspencer3> I used the command on the web site
<asac> right
<asac> so
<rickspencer3>  kvm -m 512 -redir :8090::80 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
<asac> start the second one
<rickspencer3> I built the go web server example and snappy remoted to it
<asac> with -redir :8091::80 -redir :8023::22
<rickspencer3> but I don't know how to find it
<asac> then they will listen on different ports
<rickspencer3> in my browser, I mean
<asac> so your ssh on the second one will be on 8023
<rickspencer3> ok, that's cool
<asac> and the webser of the second one on 8091
<asac> rickspencer3: see how you map those ports to the ports in the VM :)
<asac> to :80
<asac> and :22
<asac> :P
<asac> 80 is http
<asac> and 22 ssh
<rickspencer3> right
<rickspencer3> but I don't understand what hte url would be
<asac> rickspencer3: what is your current url?
<rickspencer3> I woudl have expected that I get the ip address and then just go there
<rickspencer3> the ip address of the instance, I mean
<asac> ohhhh
<asac> you want the client to call the server?
<asac> thats trickier
<asac> let me check something
<rickspencer3> asac, first, I want to call the server from a browser on my desktop so I can confirm my web server is working in teh snappy instance
<rickspencer3> then I want to write a program in the second instance that uploads data to the web server in the first instance
<rickspencer3> so I can write the code for the device and cloud at the same time :)
<asac> should still work
<asac> on the first instance you can just then access the second instance through the IP of your host
<asac> with the port of the second instance
<rickspencer3> ok, for the browser part to confirm the web server is working, I call local host at the mapped port?
<rickspencer3> localhost:8090?
<asac> yep[... just http://localhost:8091/
<asac> right
<asac> or your local ip
<asac> try witjh your local ip too ... in case the kvm only maps to localhost
<asac> then you would have a problem calling from first to second instance like above
<rickspencer3> hmmm
<rickspencer3> asac, according to snappy list, the web server is installed, do I need to do somehting to start it running?
<rickspencer3> I assumed snappy install started it
<asac> it should
<asac> which one did you install?
<asac> the go-example one?
<rickspencer3> yes
<rickspencer3> I just built it and installed it
<asac> rickspencer3: that thing is not listening on :80
<asac> let me check
<rickspencer3> oh fudge
<rickspencer3> it says 8081
<asac> rickspencer3: yeah just change the kvm cli
<asac> and it will work
<asac> so :80 -> :8081
<rickspencer3> ok
<rickspencer3> asac, sorry, do you mean I should just delete the -redir stanza?
<rickspencer3> i.e. not redirect it
<asac> rickspencer3: you need to redirect... just to a different port
<asac> currently you redirecting to port 80
<asac> e.g. :8091::80 -> :8091::8081
<rickspencer3> but why redirect at all
<asac> rickspencer3: because kvm doesnt export ports at all
<rickspencer3> couldn't I just delete it and do localhost:8081 ?
<asac> to your host
<rickspencer3> ok
<rickspencer3> good reason
<asac> rickspencer3: you would need to setup bridge networking
<asac> then your kvm would get its own ip etc.
<asac> dont ask me how :)
<rickspencer3> so this should make localhost:8091 work if the web server is working?
<rickspencer3> kvm -m 512 -redir :8091::8081 -redir :8022::22 ubuntu-15.04-snappy-amd64-generic.img
<asac> rickspencer3: if the webserver listens on port 8081 then yes
 * asac installs
<asac> rickspencer3: for me it listens to 8081
<rickspencer3> asac, not sure what you mean
<rickspencer3> are you saying that it jsut works for you?
<asac> kvm -m 768 -redir :8080::8081 -redir :8022::22 snappy-amd64.img
<asac> browser: http://localhost:8080
<asac> -> "Hello World"
<rickspencer3> you installed it from the store?
<asac> yeah
<asac> sudo snappy install go-example-webserver
<asac> let me start with a fresh image :)
<rickspencer3> ok, I built it and installed it with snappy-remote
<asac> rickspencer3: ok lets first check that your system is sane
<asac> rickspencer3: stop all KVMs
<rickspencer3> done
<asac> rickspencer3: netstat -an | grep 8090
<asac> should give you zero hits
<asac> same for
<asac> rickspencer3: netstat -an | grep 8091
<asac> then start KVM
<asac> and check that
<rickspencer3> wqhoops
<rickspencer3> rick@rick-dell-11:~/snappy-images$ netstat -an | grep 8091
<rickspencer3> unix  2      [ ]         DGRAM                    18091    /var/run/wpa_supplicant/wlan0
<asac> right
<asac> hmm
<asac> thats fine
<asac> thats a bad hit :)
<asac> but doesnt hurt
<rickspencer3> right
<asac> so start kvm
<asac> the one with 8090
<rickspencer3> ima start it with kvm -m 768 -redir :8080::8081 -redir :8022::22
<asac> after up check that you see  netstat -an | grep 8090
<asac> having a LISTEN
<asac> rickspencer3: ok then you should check that 8080 isnt used
<asac> before starting
<asac> like above
<asac> could be something on it and kvm wont complain
<asac> netstat -an | grep 8080
<rickspencer3> shucks
<rickspencer3> ok, I'll start with with kvm -m 768 -redir :8090::8081 -redir :8022::22
<asac> :)
<asac> ok
<asac> check that its listening after its up
<asac> netstat -an | grep 8090
<rickspencer3> looks right
<rickspencer3> rick@rick-dell-11:~/Projects/snappy-examples/go-example-webserver$ netstat -an | grep 8090
<rickspencer3> tcp        0      0 0.0.0.0:8090            0.0.0.0:*               LISTEN
<asac> good
<asac> now ssh into it
<asac> check that webserver is running at all :)
<asac> or first check that its listening same way there
<asac> just with 8081
<asac> but pretty sure its not running :/
<rickspencer3> k, in
<rickspencer3> oh, I did shh -p8022 ubuntu@localhost
<asac> yeah thats fine
<asac> if you started with :8022::22
<asac> netstat -an | grep 8081
<asac> if you are in
<rickspencer3> nada
<asac> yeah
<rickspencer3> so, something went wrong somewhere between when I built it and when I snappy-remote installed it, I guess
<asac> not sure
<asac> rickspencer3: ps -eaf | grep go-ex
<rickspencer3> let me uninstall it, install ist from the store, and see what happens
<asac> no hit?
<asac> yeah you can try that first
<rickspencer3> just grep ;)
<asac> i think i know what is the problem for ou though
<asac> but lets finish
<asac> i guess from store it will work
<rickspencer3> asac, nope
<rickspencer3> http://localhost:8080/ should work?
<asac> rickspencer3: how did you start kvm?
<rickspencer3> oh fudge
<asac> :8090::8081 ? then its :8090 :)
<rickspencer3> right, forgot
<rickspencer3> works now
<asac> right
<asac> ok lets check quickly if i am righht :)
<rickspencer3> cool
<rickspencer3> I am ready
<asac> rickspencer3: on yhour host you ahve the go-example-... binary
<asac> right?
<rickspencer3> I do because I built it, yes
<asac> right
<asac> run ldd go-exampl*
<asac> on it
<rickspencer3> I did not bother building the arm one, though
<asac> and post
<asac> yeah thats fine
<rickspencer3> rick@rick-dell-11:~/Projects/snappy-examples/go-example-webserver$  ldd go-exampl*
<rickspencer3> go-example-webserver:
<rickspencer3> 	linux-vdso.so.1 =>  (0x00007ffdbd3dc000)
<rickspencer3> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3265651000)
<rickspencer3> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3265287000)
<rickspencer3> 	/lib64/ld-linux-x86-64.so.2 (0x00007f326589c000)
<rickspencer3> go-example-webserver_1.0.7_multi.snap:
<rickspencer3> 	not a dynamic executable
<asac> hmm
<asac> rickspencer3: did you put it into the magic-bin/... directory?
<rickspencer3> nope
<asac>  # change to the x86_64 directory and build the binary...
<asac>  1. cd magic-bin/x86_64-linux-gnu
<asac>  2. go build ../../
<asac> thats in README :)
<rickspencer3> I followed the readme
<rickspencer3> let me delete the executable and try again
<asac> rickspencer3: check that its in that magic-bin directory
<rickspencer3> I am going to folow the directions again
<rickspencer3> hmm, I think I didnt quite follow the directions
<asac> ack
<asac> magic-bin/go-example-webserver
<asac> magic-bin/x86_64-linux-gnu
<asac> magic-bin/x86_64-linux-gnu/go-example-webserver
<asac> thats what you need
<asac> the first one is a script
<asac> the second one is the real binary
<rickspencer3> asac, I do snappy build in the go-example-web-server dir, right?
<asac> the first one is just figuring what architecture you are on and starts the right one
<asac> rickspencer3: yeah... thats step 3 in the README
<rickspencer3> oh
<asac> last step is at top level dir
<rickspencer3> let me rebranch and start from scratch :)
<asac> rickspencer3: the last step is wrong i think ... cd ../.. it should be
<rickspencer3> right
<rickspencer3> I'm just rereading, trying to grock
<rickspencer3> asac, I don't get what go build ../../ does
<rickspencer3> how does that put the binary into magic-bin/x86_64-linux-gnu/go-example-webserver
<rickspencer3> ?
<asac> it puts the binary in the current directory
<rickspencer3> oh
<asac> and it uses the name of the directory of the main.go file
<asac> its kind of magic :)
<rickspencer3> so it's just a feature of go build
<asac> but its also very basic
<asac> yeah
<asac> i think so :)
<rickspencer3> ok, let me try snappy-remote again
<asac> for anything more complex you would do it different
<asac> we need to makea  goo dtutorial for that
<rickspencer3> asac, this should work?
<rickspencer3> well, there are multiple new concepts that I need to learn
<rickspencer3> some are well known to linux engineers
<rickspencer3> some are go
<rickspencer3> and a few are snappy
<rickspencer3> :)
<rickspencer3> asac, like this?
<rickspencer3> snappy-remote --url:ubuntu@localhost:8022 go-example-webserver_1.0.7_multi.snap
<asac> no
<rickspencer3> d'oh, forgot a command
<asac> --url ssh://localhost:8022
<asac> truy that
<asac> $ snappy-remote --url=ssh://localhost:8022 install ./hello-world_1.0.5_all.snap
<asac> is the one the main tutorial
<rickspencer3> snappy-remote --url=ssh://localhost:8022 install go-example-webserver_1.0.7_multi.snap
<asac> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<rickspencer3> yeah, I get it
<asac> right
<asac> if you are lucky it starts afterwards
<rickspencer3> was just a bunch of cruft I built up :)
<asac> :)
<rickspencer3> it says it is installing
<asac> right
<asac> you can be brave and just try the browser
<asac> or first check that on the KVM you see now something listening on 8081
<rickspencer3> I'll wait until it is done
<asac> with the well known netstat grep from above :)
<rickspencer3> well, I didn't take down the image
<asac> thats fine
<rickspencer3> I just uninstalled and then sideloaded
<asac> right
<asac> should work
<asac> but you can check INSIDE the VM
<rickspencer3> taking a while to install, thoguh
<asac> if  something is listening on 8081
<rickspencer3> well, it worked before :)
<asac> hehe
<asac> yeah
<asac> so if you want to do a bit more sophisticaed stuff then just having a main.go (like including external go dependencies)
<asac> i highly recommend to read https://golang.org/doc/code.html
<rickspencer3> yeah, it's not running :,(
<rickspencer3> I'll have to try following the instructions again, though I can't think what I did wrong
<asac> :(((
<asac> rickspencer3: are you on the system?
<rickspencer3> yeah
<rickspencer3> I checked netstat, and it's nothing is on port 8081
<rickspencer3> snappy list shows it is there, though
<asac> rickspencer3: can you directly run:
<asac> /apps/go-exampl*/current/magic-bin/x86*/go-example-webserver ?
<rickspencer3> sure
<asac> what happens?
<rickspencer3> works!
<rickspencer3> asac, hmmm, I see that there is still a dir for the store version that I installed
<rickspencer3> even though I removed it
<asac> thats ok
<asac> rickspencer3: is your sideloadewd one there?
<asac> too?
<rickspencer3> yes, and that is what I ran
<asac> and what happens?
<rickspencer3> it worked
<asac> oha
<asac> rickspencer3: please see what you get with sudo systemctl status go-example-webserver_webserver_1.0.7.service
<rickspencer3> asac, while the server is running?
<rickspencer3> this looks not promising
<rickspencer3>   Process: 1080 ExecStart=/usr/bin/ubuntu-core-launcher go-example-webserver.sideload go-example-webserver.sideload_webserver_1.0.7 /apps/go-example-webserver.sideload/1.0.7/magic-bin/go-example-webserver (code=exited, status=1/FAILURE)
<rickspencer3>  Main PID: 1080 (code=exited, status=1/FAILURE)
<rickspencer3> here's the whole thing
<rickspencer3> http://pastebin.ubuntu.com/11269852/
<asac> rickspencer3: can you make your terminal wider? the last lines are super short
<rickspencer3> here ya go
<rickspencer3> http://pastebin.ubuntu.com/11269898/
<asac> rickspencer3: please add the -l after status
<asac> then we get the full lines
<asac> i tjhink
<rickspencer3> http://pastebin.ubuntu.com/11269916/
<rickspencer3> looks the same, but *shrug*
 * asac tries himself
<Chipaca> /apps/go-example-webserver.sideload/1.0.7/magic-bin/go-example-webserver: line 47: cannot create temp file for here-document: Permission denied
<Chipaca> rickspencer3: asac ^
<asac> yeah i see that
<asac> whast that?
<Chipaca> let me look at the code
<asac> ok
<asac> i have it
<Chipaca> is this the regular go-example-wbserver?
<asac> mvo broke our example :(
<asac> rickspencer3: bzr pull please
<rickspencer3> leave it to me make every mistake, hit every bug
<asac> and then sanppy build
<asac> and then its done
<rickspencer3> I really need to be in QA
<rickspencer3> kk
<rickspencer3> asac, do I need to snappy remove it first?
<rickspencer3> on the target, I mean?
 * rickspencer3 removes to be sage
<rickspencer3> saf
<rickspencer3> e
<rickspencer3> lol
<Chipaca> why is that here document being done at all?
<rickspencer3> I removed it, but it is still running
 * rickspencer3 reboots
<Chipaca> rickspencer3: still running? it wasn't running before
<Chipaca> or was it?
<rickspencer3> Chipaca, it was running because asac had me start it by running hte binary directly
 * Chipaca might be misunderstanding the nature of the problem
<Chipaca> ahhh
<rickspencer3> it did not start on install
<Chipaca> right
<asac> Chipaca: look at latest commit i did in examples
<Chipaca> asac: how "directly"?
<Chipaca> asac: i mean, running it without confinement would not have hit that issue
<asac> Chipaca: mvo added code that tells users not to start the magic-bin script through CLI directly
<asac> that code just exploded
<asac> in real case
<Chipaca> right
<asac> guess testing code before committing is good :)
<asac> hehe
<Chipaca> that makes no sense though
<asac> guess EOF isnt working that nicely with confinement
<Chipaca> if it's directly, it's not confined, tho
<asac> Chipaca: EOF seems to create a tmp doc
<Chipaca> if it's confined, it should have that env var
<rickspencer3> asac, whatever you did fixed it
<asac> yeah
<rickspencer3> and now I have been through the dev work flow like 10 times :)
<asac> the code was wrong also
<rickspencer3> and got a lesson in port forwarding
<rickspencer3> with kvm at least
<asac> rickspencer3: good to see the good side of this. sorry and thanks
<rickspencer3> so, now I am too tired to figure out how to communicate from one running kvm instance to another
<rickspencer3> will chip at it this weekend
<asac> i can imagine
 * asac too
<asac> cu around
<rickspencer3> thanks a lot asac
<rickspencer3> it's all good, it takes dopes like me trying this stuff out to make it bullet proof :)
 * asac should have tried himself earlier
<rickspencer3> I appreciate your patience
<asac> i guess you hopefully remember now how to use netstat :)
<asac> hehe
<asac> Chipaca: so to wrap up ... mvo commited code that wanted to prevent it from running directly, but it was buggy in that it prevented it from running in confinement
<asac> and that hit the bail bug
<asac> so guess we could bring it back with -n
<asac> but not today
<rickspencer3> netstat ftw :)
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/webdm/m1777/+merge/259864
<Chipaca> because it's truly a single line
<Chipaca> and now yes, to bed for me
#snappy 2015-05-22
<tgm4883> Just tried packaging my first app for snappy (well second if you count the hello world app) and when I run it in my snappy vm I'm getting a permission denied error on /tmp/snaps. I didn't see where I'm suppose to declare this permission, is this something I can do or do I need to try to tell the app to use some fake tmp in /var/apps/myapp/?
<tgm4883> just found this, which I think might be what I need https://developer.ubuntu.com/en/snappy/guides/security-policy/
<JamesTait> Good morning all; happy Friday and happy Donât Fry Day! ð
<asac> mvo: fyi, i did a hard backout of the  convenience change you landed in go-example-webserver
<asac> not sure if you want to bring it back, but if so, please test that the package still works afterwards :P
<mvo> asac: oh, sorry for that and thanks for fixing
<asac> mvo: i think it should have been a -n ?
<asac> mvo: it failed to start with this :)
<asac> because EOF tries to write a temp file it seems
<mvo> thats confusing, once I finished my branch here I will checks whats going on, looks ok from a first glace but certainly is not :/
<Chipaca> mo'in
<Chipaca> mvo: we have many bugs around tempdirs
<mvo> hey Chipaca
<mvo> Chipaca: meh, more?
<mvo> Chipaca: or more of the same and we need to land your fix urgently?
<Chipaca> mvo: well, that "can't create here document" or whatever the error message was is one
<Chipaca> mvo: my fix is not necessary; merely sufficient (?)
<Chipaca> (i kid; it's not even that, there's more work to be done to fix it still)
<Chipaca> mvo: bash creates its tempfiles in TMPDIR
<mvo> oh, meh
<Chipaca> mvo: our systemd units are not creating their tempdirs
<mvo> right, lets land your fix urgently
<Chipaca> mvo: my fix needs work on other fronts
<Chipaca> mvo: to be more exact:
<Chipaca> mvo: a snappy branch to change TE?MPDIR
<Chipaca> mvo: and a branch to ... apparmor? simpleprof something, to let things write to /tmp/
<mvo> hm, if thats the case, is there anything else we can do? something cheap that just creates the dir in the unit?
<Chipaca> as currently it's only able to write to /tmp/snaps/yadda
<mvo> right
<Chipaca> mvo: webdm creates it itself, from its init script
<Chipaca> mvo: it had a bug, where it wasn't setting it 01777
<Chipaca> so other things failed after
<mvo> yeah, I noticed that, I wonder if we could generalize that until the proper fix is in place
<Chipaca> mvo: i'm not really sure that'll work for things that aren't as privileged as webdm though
<Chipaca> i mean, by the time that runs it's already contained, right?
<Chipaca> even the easy fixes involve either regenerating the unit files, or telling people to do so (by de/reinstalling)
<mvo> Chipaca: I think we can run pre-start unconfied
<mvo> re-generating> good point
<Chipaca> ah, that would work
<mvo> so proper fix sounds like the right plan of attack
<Chipaca> so 'tis a bit of a mess
<Chipaca> the only problem is that, because the "right" fix touches so many packages => lots of SRUs
<Chipaca> (yay)
<mvo> well, its not *too* terrible, we could also just create /tmp/snappy/snapname in your branch
<mvo> I think we actually have to :/
<mvo> because we would have to re-generate unit files/exec files otherwise that already set TMPDIR
<Chipaca> hah, inside the private tmp?
<mvo> yeah
<mvo> then its just one SRU (for now) and the other can follow as needed
<Chipaca> mvo: also the apparmor profiles
<mvo> well, we still want apparmor of course
<mvo> to unblock the /tmp hardcorers^Whardcoders
<Chipaca> so that's the three packages
<Chipaca> oh, we'd avoid snappy
<mvo> Chipaca: so plan of attack: add even more private /tmp/snaps/foo to private /tmp
<mvo> do new image with that and all TMPDIR honoring people are good
<mvo> then do apparmor to help the hardcoders
<mvo> sensible? or am I missing something and need more tea?
<Chipaca> TEMPDIR is not set for systemd
<Chipaca> only TMPDIR
<Chipaca> probably a bug in and of itself
<mvo> aha, meh, ok. indeed
<Chipaca> hmmmmm
<mvo> I'm in favor of landing the launcher with the dir creation right away and then tackle the rest, that should already be a huge win
<Chipaca> so, we'd look at TEMPDIR and create it, from the unprivileged section of the launcher
<mvo> yep
<Chipaca> land that, and TEMPDIR people are good, as you say
<Chipaca> TMPDIR*
<mvo> unless you have a different opinion, you looked into this way deeper than I did, I may miss something here
<Chipaca> well, we need to look at either TMPDIR or SNAP_somethingsomehting
 * mvo nods
<Chipaca> i'd say TMPDIR
<mvo> we just create all of them :) hopefully its just one
<Chipaca> so we can nuke the SNAP_TEMPDIR or whatever later on
<mvo> aha, good point
<mvo> yeah, lets do that and just use TMPDIR
<mvo> it will be set to SNAP_TEMPDIR anyway IIRC
<Chipaca> yes
<Chipaca> and TEMPDIR is set to TMPDIR also, when it's set
<Chipaca> mvo: if we land https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 does anything break automatically?
<Chipaca> i mean, is that put onto images directly?
<mvo> Chipaca: if we upoad it to the PPA it can land directly, or we do the full SRU dance which will take longer
<Chipaca> mvo: i asked because we don't want it to land automatically until we do the "create /tmp/snaps" thing
<Chipaca> mvo: which i'd rather was a follow-up branch
<Chipaca> this one is already starting to mature
<mvo> Chipaca: ok, we can simply wait with the top-approve
<Chipaca> good point
<Chipaca> i've got a recursive mkdir in bzr history, will fish it out and propose the mp in a bit
<mvo> \o/
<Chipaca> i lied, i have _half_ a recursive mkdir of the sort we want
<Chipaca> anyway, doing it
<Chipaca> mvo: like so: https://code.launchpad.net/~chipaca/ubuntu-core-launcher/mktmpdir/+merge/259908
<mvo> Chipaca: yeah
<mvo> Chipaca: I reviewed/merged/uploaded now, once that hits the PPA I will create a test image to verify that it all works
<mvo> works for real
<Chipaca> +1
 * mvo gets lunch while waiting for the image
 * Chipaca -> coffee
<mvo> Chipaca: hm, do you happen to have the bugnumber for the tmp issue ? if not I can try to find it
<Chipaca> mvo: i don't
 * mvo will find it
<Chipaca> mvo: there is one?
<mvo> Chipaca: *cough* now there is https://bugs.launchpad.net/snappy/+bug/1457839
<ubottu> Ubuntu bug 1457839 in Snappy "TMPDIR not availalble for snappy services" [Undecided,New]
<Chipaca> mvo: \o/
<Chipaca> mvo: cmp-test needing a commit message
 * Chipaca curses at dirs.go
 * Chipaca is stuck
 * Chipaca stops for lunch
<Chipaca> mvo: you around?
<mvo> Chipaca: yes
<Chipaca> mvo: hiya. have you an opinion around the âPartâ interface? AIUI the name wasn't well-loved
<mvo> Chipaca: no strong opinion either way, I don't mind the name but if there is a suggestion for a better one I'm all ears :)
<Chipaca> mvo: well, it's moving to its own package
<Chipaca> or to the "pkg" pacakge
<mvo> aha
<Chipaca> and am wondering whether to leave it as pkg.Part, pkg.Interface, or something else
<mvo> both is fine with me
<mvo> maybe interface is indeed cleaner
<sergiusens> morning
<Chipaca> mo'in!
<sergiusens> mvo: did you get to the bttom of this? "[   18.214558] FAT-fs (mmcblk0p1): IO charset iso8859-1 not found
<sergiusens> Chipaca: are we making the interface smaller?
<mvo> sergiusens: no, not yet :/
<Chipaca> sergiusens: the Part interface?
<sergiusens> mvo: I'm seeing it myself now too, after upgrading
<Chipaca> sergiusens: wasn't in my plans, no
<sergiusens> Chipaca: yeah
<Chipaca> trying to focus on making snappy/* smaller
<mvo> sergiusens: oh, nice. and you fall into a recovery shell?
<sergiusens> Chipaca: just move first is all?
<Chipaca> i get distracted too easily as it is :)
<Chipaca> sergiusens: yeah
<sergiusens> Chipaca: should I hold off on moving frameworks to /frameworks?
<Chipaca> sergiusens: but if you think we should split it, that might make naming it easier
<Chipaca> sergiusens: how would you split it?
<sergiusens> Chipaca: let me check the interface
<Chipaca> sergiusens: having tried again to split click/snappy out and failed (too big a branch), i'm working backwards and moving the interfaces out. that is, repository and part
<Chipaca> i can just move them without renaming them too :) but where's the fun in that
<sergiusens> Chipaca: heh, I can't think of any better way
<sergiusens> Chipaca: except the minor thing of calling Uninstall Remove to match the leangua franca
<Chipaca> sergiusens: heh
<sergiusens> Chipaca: I would move out Frameworks though as only apps depend on frameworks
<sergiusens> so it's too specific
<Chipaca> ok, so i'll do snappy.Part  -> pkg.Part, and snappy.Repository -> repo.Repository
<sergiusens> Chipaca: and I'd rename SetActive to Activate (used for rollback/kick and switch)
<Chipaca> let's see how that goes
<Chipaca> easier to rename after move anyways
<Chipaca> sergiusens: ack
<sergiusens> Chipaca: how about s/Part/Package/ ?
<Chipaca> sergiusens: and then it'd be pkg.Package ?
<sergiusens> Chipaca: pkg.Interface ? :-P
<Chipaca> mhmm
<Chipaca> that was my original question, more or less :)
<sergiusens> Chipaca: then pkg.Snap
<Chipaca> on the other hand, pkg.Package would make the docs fun to write
<Chipaca> sergiusens: there's already *two* other things we're calling snap
<sergiusens> Chipaca: bummer
<sergiusens> Chipaca: maybe pkg is the wrong name as well ;-)
<Chipaca> fo sure
<Chipaca> i chose it myself; it's got a p=.78 of being wrong
<sergiusens> Chipaca: and maybe we need to remove other things from snappy and keep this stuff in there
<Chipaca> sergiusens: yeah, i'm reating this and that as symmetrical
<Chipaca> ie moving things out of snappy as the same as moving the complement out
<Chipaca> at some point
<Chipaca> maybe
<sergiusens> Chipaca: I'd remove the complement out and use snappy.[Part|Package]
<sergiusens> Chipaca: and complicate your life with the go pkg names you need to come up with :-P
<Chipaca> sergiusens: at some point, webdm would be talking to a thing that just knew about interfaces (Part, Repository) and the toplevel install/remove/etc methods
<sergiusens> Chipaca: even less; the restful api
<Chipaca> and the nitty gritty would be tucked under pkg/ (or whatever that gets renamed to)
<Chipaca> sergiusens: ok, so the restful api would be built on *
<Chipaca> :)
<sergiusens> Chipaca: hangout to design?
<Chipaca> this chumminess is mind-splitting
<Chipaca> sergiusens: https://plus.google.com/hangouts/_/canonical.com/de-sign?authuser=1
<sergiusens> Chipaca: http://dave.cheney.net/2015/05/12/introducing-gb https://walledcity.com/supermighty/building-go-projects-with-gb http://getgb.io/
<Chipaca> sergiusens: ta muchly
<mvo> sergiusens: heh :) you keep seeling gb ;)
<Chipaca> mvo: i'm sold already :)
<Chipaca> mvo: but i'd lost that last link
<Chipaca> turns out, living in the uk, searching for "gb" isn't too helpful
<sergiusens> mvo: have you read about it yet?
<Chipaca> and wouldn't you know, "go gb" isn't much helpfuler
<sergiusens> Chipaca: I search for gb cheney ;-)
<Chipaca> oooh, look at him, with his fancy search terms
<mvo> sergiusens: yes, well, sort of - if I understand it correctly it means our repo grows by the size of our dependencies? or is there a shorthand way, i.e. gb.txt with link-to-repo,revno pairs?
<sergiusens> mvo: it all goes in there, yeah
<sergiusens> mvo: advantage is, you bzr branch lp:snappy; cd snappy; gb build
<jdstrand> Chipaca, mvo: fyi, I had filed these before: bug #1449625 and bug #1448225
<nothal> Bug #1449625: systemd and bin-path exported variables are not in sync <Snappy:Triaged> <http://launchpad.net/bugs/1449625>
<nothal> Bug #1448225: webdm apparmor denials <Snappy:New> <http://launchpad.net/bugs/1448225>
<ubottu> bug 1449625 in Snappy "systemd and bin-path exported variables are not in sync" [High,Triaged] https://launchpad.net/bugs/1449625
<ubottu> bug 1448225 in Snappy "webdm apparmor denials" [Undecided,New] https://launchpad.net/bugs/1448225
<jdstrand> Chipaca, mvo: the second is your services don't have a TMPDIR bug
<Chipaca> jdstrand: those rules aren't in the policy yet?
<Chipaca> i missed that
<jdstrand> so, I discussed this yesterday
<Chipaca> ruh roh
<jdstrand> I long time ago when setting up TMPDIR, I said that apparmor will only allow the create of the version part of the TMPDIR
<jdstrand> everything above it must be created by something else
<Chipaca> ah, ok
<Chipaca> that's fine
<Chipaca> that's in the pipeline :)
<jdstrand> now, I happened to not agree with having a versioned TMPDIR, but that is beside the point-- that was the decision taken
<Chipaca> jdstrand: the unshare thing does away with the version, does a mkdtemp and uses that
<jdstrand> yes
<Chipaca> jdstrand: although we're creating the versioned one short-term for compat
<Chipaca> so we don't have to change everything in stable
<Chipaca> jdstrand: creating it in the unprivileged part of the launcher, that is
<Chipaca> just before apparmor
<Chipaca> (so whether it's *actually* unprivileged is arguable; it depends on whether it's called as root or not)
<jdstrand> fyi, (some of) the discussion of the current implementation happened here: https://bugs.launchpad.net/snappy/+bug/1400320
<ubottu> Error: ubuntu bug 1400320 not found
<Chipaca> jdstrand: 404 for me too :)
 * jdstrand makes said bug public
<mvo> jdstrand: oh, thanks, I knew there was a open one but I didn't find it :/
<jdstrand> yeah, it was lumped in with another (that was fixed) and kinda hidden
<Chipaca> ok
<Chipaca> i'm assuming the bind sidesteps overlayfs
<jdstrand> it does
<jdstrand> so, what is the relationship being 'rolling' and 'devel', if any?
<jdstrand> https://developer.ubuntu.com/en/snappy/guides/channels/ only discusses 15.04 and rolling
<jdstrand> $ ubuntu-device-flash query --list-channels --device=generic_amd64 | grep core
<jdstrand> ubuntu-core/devel
<jdstrand> ubuntu-core/devel-proposed
<jdstrand> ubuntu-core/rolling/edge
<jdstrand> ubuntu-core/15.04/stable
<jdstrand> ubuntu-core/15.04/edge
<jdstrand> ubuntu-core/rolling/alpha
<jdstrand> are devel and devel-proposed just historical and we shouldn't use them?
<jdstrand> slangasek, mvo: ^
<mvo> jdstrand: I think they are historic, but slangasek will confirm
<jdstrand> ok, yeah, it doesn't have tha edge, alpha, etc bits in there. that makes sense if they are historical
<jdstrand> mvo: thanks-- I'm trying to put together some docs for the security team for testing and update procedures
<sergiusens> jdstrand: devel (not what you see in the channel listing) is what may become the name for rolling
<jdstrand> mvo: fyi, https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#system-image_updates_.28DRAFT.29
<jdstrand> sergiusens: can you clarify?
<jdstrand> rolling is not set in stone yet?
<ogra_> in rolling stone :)
<jdstrand> hehe
<sergiusens> jdstrand: I think mark wanted to go with devel instead of rolling and we went with rolling as it was already like that in the store
<mvo> sergiusens: oh? so rolling may get renamed - I knew why I said "maybe" :)
<jdstrand> hehe
<sergiusens> jdstrand: btw, did you have a chance to look into my question about $origin?
<Chipaca> we should rename it to trolling
<jdstrand> ok, so ubuntu-core/devel and ubuntu-core/devel-proposed may leave, then rolling may be changed to ubuntu-core/devel/edge, ubuntu-core/devel/alpha, etc
<jdstrand> I'll just keep an eye on it and adjust as necessary
<sergiusens> jdstrand: as in using the layout of "$pkgtype"s/$pkgname/$origin/$version (where package type is framework, app or oem?
<sergiusens> jdstrand: correct
<jdstrand> sergiusens: I didn't-- where was this question?
 * jdstrand hasn't gotten to his inbox yet)
<sergiusens> jdstrand: it was over irc, so maybe no inbox to check :)
<sergiusens> jdstrand: the question in itself is getting the policies to know about $origin to map the paths in the template I guess
<jdstrand> I was having connection issues yesterday. I don't see it...
<jdstrand> sergiusens: can you state the whole question?
<sergiusens> jdstrand: it was two days ago, but no worries
<jdstrand> sorry, I missed it
<jdstrand> I think I see it
<jdstrand> not the question, but can infer from backscroll
<jdstrand> (here)
<jdstrand> so the basic idea is you'd like to split up apps, oem snaps and frameworks
<sergiusens> jdstrand: I'm going to start storing the origin of packages locally, initially we went with pkgname.origin for everything and slowly close to release we dropped it for frameworks and oem packages
<jdstrand> ok, so there are two parts
<sergiusens> jdstrand: the splitting is tangential and I guess it doesn't impact apparmor in any way
<jdstrand> there is storing stuff in pkgtype
<jdstrand> and also storing origin in the path
<jdstrand> the splitting is not tangential and does affect apparmor
<jdstrand> well, it may be tangential
<jdstrand> but it does affect apparmor
<sergiusens> jdstrand: right, there are two problems is what I wanted to say :-)
<jdstrand> so we'd have to coordinate that change as well
<jdstrand> that one is not particularly difficult or contentious
<jdstrand> why are we adding origin back for frameworks? a quality of frameworks is they can't be forked and adding the origin to the path complicates/muddies apparmor policy and makes it difficult for apps depending on the framework to use the right path
<sergiusens> jdstrand: we don't need it in the path
<jdstrand> ie, /frameworks/docker.sideload vs /frameworks/docker.canonical
<sergiusens> jdstrand: but it becomes hard to snappy switch the sideloaded version and the store one
<jdstrand> what is owncloud supposed to use?
<jdstrand> I'm confused. you said before you want "$pkgtype"s/$pkgname/$origin/$version" but just now said "we don't need it in the path"
<sergiusens> jdstrand: sorry I meant the package name
<sergiusens> jdstrand: the package name would still be docker, the path to the stored data would be different
<jdstrand> sure
<ogra_> hmm
<jdstrand> but then owncloud still doesn't know
<jdstrand> /frameworks/docker/sideload vs /frameworks/docker/canonical
<ogra_> looking at https://developer.ubuntu.com/en/snappy/guides/config-command/ ... is there no way to do something like: "snappy config ubuntu-core hostname=foo" ?
<sergiusens> jdstrand: so we need some mechanism like 'current' but for the package path
<jdstrand> we could fix owncloud easy enough with a symlink
<jdstrand> right
<jdstrand> then that means that only framework policy is muddied
<jdstrand> so, the policy itself could have:
<jdstrand>   /frameworks/docker/*/*/foo r,
<jdstrand> but then there is still the issue of the framework policy filenames themselves (which are what reverse depends snaps use)
<jdstrand> ie
<sergiusens> jdstrand: two *, one for origin and the other for version?
<jdstrand> ls /var/lib/snappy/apparmor/policygroups
<jdstrand> docker_client
<jdstrand> owncloud uses caps: [ docker_client ]
<jdstrand> sergiusens: re '*', yes
<jdstrand> sergiusens: we have to do that for testing-- ie, if kick inz1 sideloads the docker snap to test, if if has /frameworks/docker/canonical/ the sideload scenario breaks
<jdstrand> I guess we could do:
<jdstrand>   /frameworks/docker/{canonical,sideload}/*/foo r,
<jdstrand> that would be somewhat better
<jdstrand> but you can see what I mean by things being muddied
<jdstrand> assuming that was acceptable
<jdstrand> there is still the filename in /var/lib/snappy/apparmor/policygroups
<sergiusens> jdstrand: yeah, so the question is which is cleaner, doing this or treating sideloads as coming from the same origin (and if so, we may need to block freely sideloading for frameworks)
<jdstrand> currently it technically isn't a problem because we aren't allowing multiple forks to be installed
<jdstrand> but as soon as we have origin in the name, it is super slippery to say why don't we allow forks of frameworks?
<jdstrand> I don't think we need to block freely sideloading frameworks
<jdstrand> we are we protecting the user from his/herself?
<sergiusens> jdstrand: I see your points; I'll give sideloading some more thought, but it's the only reason I see it usable for frameworks
<jdstrand> s/his/him/
<sergiusens> jdstrand: that and something pointed out to me about symmetry directory, but that is not relevant :-)
<jdstrand> sergiusens: so I'm not saying we *cannot* have origin in the path; I'm saying it's complicated
<jdstrand> and it would need to be very carefully implemented and coordinated
<jdstrand> but I've not been able to think of something that is wholly satisfying
<jdstrand> eg, say we say the path is ok, and we assume that the policy content can be dealt with well enough, then it comes down to the path of the cap
<sergiusens> jdstrand: sure, but if there is no use for it, I would rather not do it; we need to be able to cleanly update from 15.04 to $next in some way (won't be automatic) and have an upgrader that can translate all the changes that happened during rolling
<jdstrand> we could install /var/lib/snappy/apparmor/policygroups/docker.canonical_client
<jdstrand> and then tooling could be smart to know that 'caps: [docker_client]' actually means /var/lib/snappy/apparmor/policygroups/docker.canonical_client
<jdstrand> but, then there is a disparity between what the user declares and sees on disk, and things get more complicated implementation wise
<om26er> is there a snap for vim ?
<ogra_> om26er, no
<ogra_> om26er, i tried to make one once, but the restrictions back then made it rather impossible to use
<om26er> ogra_, is it doable now ?
<sergiusens> jdstrand: right, I'll table this for now
<jdstrand> one thing we *cannot* do (based on all conversations up until now) is have apps say: "caps: [docker.canonical_client]"
<ogra_> we might be closer but i think you would setill need to break out of confinement
<sergiusens> jdstrand: and see if I can play aroun a bit; and I agree, no docker.canonical_client is a hard req
<jdstrand> that would solve almost everything (except sideloading, cause docker.sideload_client...)
<sergiusens> *, it is a hard req
<ogra_> om26er, http://people.canonical.com/~ogra/snappy/snaps/ ... (not sure it still works though, thats rather old ... )
<jdstrand> but it is ugly, bad dev experience, etc, etc)
<ogra_> om26er, with that you can only edit files inside the /var/apps/vim.ogra/ dir though
<jdstrand> sergiusens: ok, that's fine
<ogra_> (or /var/lib/apps ...)
<sergiusens> jdstrand: I do have another topic...
<jdstrand> sergiusens: I'm here to discuss more if you come up with something
<sergiusens> jdstrand: do you know why we removed the origin from oem snaps?
<om26er> ogra_, aah, heh thats pretty useful :p
<ogra_> heh
<jdstrand> sergiusens: otoh, no-- I don't think that came from me. I do remember someone coming to the conclusion that "apps themselves are actually the exception, because they are the only thing that supports forks"
<ogra_> om26er, i guess you could add ~/bin to your PATH and just dump a vim into /home/ubuntu/bin for the moment
<jdstrand> sergiusens: maybe something with config? (wild guess)
<jdstrand> or hw-assign?
<jdstrand> I can't recall
<jdstrand> I think I only had one ear listening at the time cause I was working on 'bus-name'
<jdstrand> om26er: fyi, there is supposed to be a 'comfy' snap at somepoint that will have all these types of tools
<ogra_> at some point :)
<jdstrand> yes
<sergiusens> jdstrand: ok, beuno was the one asking why, I'm fine with no switch/forks for oem snaps as they are special as well
<om26er> jdstrand, that will be a help!
<jdstrand> sergiusens: /me nods
<jdstrand> sergiusens: I just don't remember
<sergiusens> jdstrand: in the end, only "snappy apps" can be forked
<jdstrand> yeah
<sergiusens> and we need to figure out some clean way to sideload
<om26er> ogra_, I'll try that. I am getting started so that eventually I could achieve some type of automation, including home brewed IoT ;)
<jdstrand> simplest is to not allow a snap to be sideloaded at the same time as the one with the store
<jdstrand> then do a symlink from pkgname -> pkgname.sideload
<jdstrand> now, that is simple, but I've not thought it all through of course
<jdstrand> or maybe the other way
<jdstrand> yes, the other way is simpler
<jdstrand> oem and frameworks don't have origin in their name
<jdstrand> so you sideload, it still doesn't have it in the name, but then you have pkgname.sideload -> pkgname
<jdstrand> but then, I don't know what we are trying to solve here
<jdstrand> so best I not try to suggest an implementation :)
<sergiusens> jdstrand: I have was to store the origin in the works that does not depend on mangling with the path
<sergiusens> jdstrand: the only change that would affect apparmor in motion is the move of frameworks to their own dir /frameworks
<jdstrand> sergiusens: perhaps dropping .sideload into the install directory?
<jdstrand> or somewhere else that you could check
<sergiusens> jdstrand: I don't want to mangle the install directory as that is the packagers area
<jdstrand> /var/lib/snappy/sideloads/docker
<jdstrand> that could even be a symlink to /frameworks/docker
<jdstrand> these are obviously just otoh
<sergiusens> jdstrand: jdstrand http://snappy.asac.ws:9001/p/dot.store
<jdstrand> and yes, I agree not adding to install path
<sergiusens> om26er: do you still have issues with snappy config?
<om26er> sergiusens, no? might be someone else.
<ogra_> sergiusens, you mean me ?
<sergiusens> ogra_: yes
<ogra_> sergiusens, well, is there any commandline way to use snappy config to set a value for a key ?
<ogra_> the doc doesnt show any
<sergiusens> ogra_: you need to pipe/redirect in
<ogra_> bah, really ?
<elopio> are you sure that I only have to insert the sd card on the beagle and boot to ubuntu?
<elopio> now I have the serial cable, and it shows me that the board is booting in debian.
<sergiusens> ogra_: or like this https://gist.github.com/sergiusens/8d4d2b99b2e5d87c7a50
<ogra_> elopio, depends on the board (there are many beaglebones )
<ogra_> elopio, some require you to hold down the S2 button to boot from SD
<elopio> ogra_: beaglebone black rev C
<sergiusens> elopio: sometimes you have to press and hold a micro switch (I had to on that model)
<ogra_> sergiusens, ugh, why did we make it so ugly
<sergiusens> ogra_: I didn't design it ;-)
<sergiusens> ogra_: I do want to improve it and want to talk to mvo about it eventually
 * ogra_ would have expected something llike "snappy config <package> key=foo" or "snappy config <package> section:key=foo"
<ogra_> or some such
<sergiusens> ogra_: that's what set is for, but for other things
<sergiusens> ogra_: everything is a yaml is the mantra
<ogra_> yeah, thats awful for plain cmdline use
<ogra_> piping and sed'ing HERE docs around ... omg :)
<sergiusens> ogra_: HERE?
<ogra_> http://tldp.org/LDP/abs/html/here-docs.html
<ogra_> (it isnt exactlyy one ... since you use a var there)
<sergiusens> ogra_: you can put that in the oem snap in the config section as well
<elopio> sergiusens: do you have to press the boot button, and use the 5V power? Pressing the button and inserting the usb cable doesn't light the leds here.
<ogra_> sergiusens, yeah, i dont care about the snap ... i care about the admin who wants to change a config setting
<ogra_> the yaml makes all sens inside the snap
<ogra_> just not as a tool for config adjustments
<slangasek> jdstrand, mvo_: yes, historical; I can set those up to auto-migrate users to the rolling/edge and rolling/alpha channels but it hasn't been a priority
<slangasek> jdstrand, mvo_: maybe we should just drop them to avoid confusion, but I'm not sure all the public references to them have gone away yet
<jdstrand> slangasek: cool, thanks for the confirmation. don't auto-migrate on my account. I'm just trying to document what the security team should use to generate VMs
<sergiusens> elopio: no 5V, don't do that!
<elopio> sergiusens: "You should use a 5V external power source, USB power may not work"
<elopio> not the red cable.
<ogra_> yeah
<ogra_> either use the micro USB port or a 5V barrel connector
<tbr> you can remove the need for the boot button by nuking mlo on the emmc
<ogra_> does that work eh same on all versions/revisions/bulds of the board ?
<ogra_> *the ...
<tbr> yes
<tbr> if you want to go alien on it, just dd if=/dev/null of=$emmc bs=1M count=1
<tbr> mounting the right partition (IIRC it's FAT16 or FAT32) and removing 'mlo' is somehow more elegant, but if someone decided to put mlo on the emmc in one of the other locations checked by ROMBL...
<ogra_> yeah
<tbr> I'm going to boot this board. see what it has on the emmc (probably an ancient angst-rom)
<ogra_> heh, yeah
<ogra_> elopio it trying to improve the install doc btw
<tbr> another option is to reconfigure uboot on the emmc, but then you need to be sure it's recent enough
<ogra_> so if you have hits for him that are generic, they are surely welcome
<ogra_> yeah, i dont think we are always sure of that
<tbr> I think nuking mlo is the option where you will at least be reasonably sure you found the right thing and nuked it. the others might be a bit voodoo
<ogra_> yeah
<elopio> now it's booting snappy, without pressing any buttons.
<elopio> my board is haunted.
<ogra_> thats the beagle inside :)
<elopio> Ubuntu 15.04 localhost.localdomain ttyO0
<ogra_> nice !
<ogra_> congrats
<elopio> shouldn't that say webdm.local ?
<ogra_> no
<ogra_> .local is a avahi name ... only usable via the avahi7bonjour protocol
<ogra_> *avahi/bonjour
<tbr> might still be using the emmc uboot though
<ogra_> then you wouldnt end up in snappy
<elopio> ogra_: what I can't do is to ssh ubuntu@webdm.local, as the guide says.
<ogra_> the emmc uboot is lacking features
<ogra_> elopio, right, because your PC resolves avahi
<tbr> k
<ogra_> elopio, if you try that from your ubuntu phone which doesnt ship an avahi client it wont work (but ssh ubuntu@IP will work)
<ogra_> webdm.local is simply something provided by a snap ... not actually something provided by the system itself ... so localhos.localdomain is correct (until you set a hostname) for the system layer
<tbr> jftr, on this angstrom emmc image it's in /dev/mmcblk0p1 (as seen when booted from emmc!)
<kyrofa> sergiusens, ping
<jdstrand> sergiusens: hey, I'm looking at https://developer.ubuntu.com/en/snappy/guides/channels/
<jdstrand> sergiusens: I want to create a kvm image with ubuntu-core/15.04/alpha
<jdstrand> sergiusens: but I can't get the udf invocation right
<jdstrand> I thought this would do it from reading: sudo ubuntu-device-flash core --channel=ubuntu-core/15.04/alpha --size=8 --enable-ssh --output=15.04-alpha.img
<jdstrand> but it doesn't (says I need a release)
<jdstrand> so I try other things and it doesn't work
<jdstrand> I'm on vivid
<jdstrand> I thought this might:
<jdstrand> sudo ubuntu-device-flash core --channel=alpha --size=8 --enable-ssh --output=15.04-alpha.img 15.04
<jdstrand> but then got:
<jdstrand> Channel ubuntu-core/15.04/alpha not found on server https://system-image.ubuntu.com
 * jdstrand tries other things
<jdstrand> maybe I should try edge for now
<jdstrand> sudo ubuntu-device-flash core --channel=edge --size=8 --enable-ssh --output=15.04-alpha.img 15.04 worked
<jdstrand> sergiusens: it's weird that I can use --channel=ubuntu-touch/rc-proposed/ubuntu with ubuntu-emulator but not with udf
<jdstrand> sergiusens: and I appear to be able to use --channel=ubuntu-touch/rc-proposed/ubuntu with udf for touch, but not that style when specifying 'core'
 * jdstrand files a bug
<jdstrand> sergiusens: fyi, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1458006
<ubottu> Ubuntu bug 1458006 in goget-ubuntu-touch (Ubuntu) "inconsistent invocation between touch and core" [Undecided,New]
<tgm4883> so snappy apps only let me write to two specific directories. Is there any functionality to allow writing to USB drives and/or a way to mount network storage?
<tgm4883> I would prefer the network storage route
<D_Cent> hi - i'm looking for an avahi server on snappy ubuntu core (on a raspberry pi 2). can anyone tell me how to get that running?
<D_Cent> well, basically i just need some service which makes the raspberry pi discoverable over the network without knowing its IP
<noise][> anyone here hacking on GPIO stuff on the beagleboard?
<noise][> apparently i need device-tree-compiler to setup 1wire support (for a temp sensor)
<ash_charles> D_Cent: IIRC, webdm publishes the device name using avahi---that might be a good place to start looking.
<elopio> D_Cent: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/files/head:/avahi/
<D_Cent> thank you, ash_charles and elopio!
<sergiusens> jdstrand: it's because for core we introduced the new concept of channel and for touch and the emulator we are using the system-image concept of a channel
#snappy 2015-05-23
<harmw> hi guys, is anyone aware of a working cubietruck image of snappy?
#snappy 2015-05-24
<marques> i want to make a snappy app for octoprint -- it would need access to the serial devices /dev/ttyACM* and would need to start at boot, so some sort of service.
<marques> how do i get access to the serial - apparmor and/or seccomp files - do i need that? anything else?
<marques> what user does it run as if it starts at boot - does that account need to be in the dialout group/
#snappy 2016-05-23
<zyga> good morning
<davidcalle> Morning zyga
<zyga> davidcalle: hey :-)
<OsakaFoo> can I access the snappy store from the web?
<ogra_> there is an API
<ogra_> but no official webpage .... there is also a community webpage that uses the API at http://uappexplorer.com
<ogra_> there you can filter for snaps too
<OsakaFoo> oh yeah
<OsakaFoo> thanks
<OsakaFoo> is it possible to run snaps on ubuntu-touch?
<ogra_> not yet, no
<OsakaFoo> will that be the future?
<ogra_> yes
<ogra_> but that reqquires the phones tofirst switch to 16.04 and a systemd base
<OsakaFoo> nice
<bencc> can I do hot-code upgrade of a package?
<bencc> I want to package an erlang release
<bencc> erlang let you upgrade the code in a running system
<zyga> bencc: how would that work in practice?
<zyga> bencc: ship a new snap but not restart services?
<zyga> bencc: but instead do *something* (not sure what yet)
<bencc> zyga: in erlang you upload the new version of the code and tell the VM to 'replace' the old code with the new code
<bencc> erlang is smart to not stop running processes (Erlang processes) but use the new version in the next run
<bencc> zyga: nginx let's you update the deb package without restarting the daeomn
<bencc> how does a normal snap update work?
<zyga> bencc: interesting
<zyga> bencc: seems like lisp image in many ways
<zyga> bencc: currently snapd would restart the servies
<zyga> bencc: but we could think of how to support that
<zyga> bencc: can you please open a bug on launchpad.net/snappy and describe this
<sergiusens> good morning everyone!
<bencc> zyga: sure
<bencc> zyga: are there docs on refreshing/upgrading a daemon?
<bencc> I can't find it on google
<kyrofa> Morning sergiusens!
<zyga> bencc: I think it might be possible but it would be interested to know all the edge cases
<bencc> how do you upgrade a running webserver like nginx?
<bencc> if hot upgrade is not supported now I'll have to wait for ubuntu 16.10 or later?
<zyga> bencc: right now, we just install a new snap, activate it (make all the systemd units and security bits) and then we stop/start services
<zyga> bencc: but I do see that it would be great if we could, in certain cases, optimize the restart to "reload" that perhaps doesn't kill the processes or induces downtime
<zyga> bencc: perhaps once we have hook support we could do that
<zyga> bencc: a specific hook could be called on upgrade to tell us if services need to be restarted the hard way
<bencc> ok
<zyga> bencc: and if not, the hook could do whatever is needed to do a "soft" restart
<zyga> bencc: would that be sensible in this case?
<bencc> I think so
<zyga> great, let's please include this conversation in the bug report
<zyga> Thanks!
<bencc> in a deb package I'm using the postinst script
<bencc> If the erlang server is running, I'm asking it to do hot-code upgrade from the command line
<bencc> if it's not running I'm doing normal installation
<niemeyer_> jdstrand, tyhicks: Any news on the environ setting issue?
<bencc> zyga: do I need to explain about erlang in the bug report?
<bencc> it seems that it's a general use case. nginx will need the same as erlang app right?
<zyga> bencc: it'd be best
<bencc> ok
<zyga> bencc: less assumptions about what the readers will understand about erlang
<zyga> bencc: yes, I think the generic no-downtime support would be an amazing thing to have
<jdstrand> niemeyer_: tyhicks is looking into it. He'll be online in a bit
<zyga> jdstrand: hey, you may want to start looking at https://code.launchpad.net/~zyga/ubuntu-core-launcher/snap-run
<zyga> jdstrand: right now nothing interesting but I plan to change how snap-run looks on command line
<zyga> (more than so far)
<bencc> I can use snaps on ubuntu server 16.04. no need for ubuntu core, right?
<kyrofa> bencc, indeed
<kyrofa> (or desktop)
<zyga> bencc: yes, on any ubuntu really :)
<bencc> nice
<niemeyer_> zyga: It's a bit tricky to be effective at "start looking" :)
<niemeyer_> zyga: If you have changes for it, please push them for review as usual and ask jdstrand for a review before landing
<niemeyer_> zyga: We can do that after moving to GH
<niemeyer_> zyga: But let's move the pristine code, unchanged
<niemeyer_> zyga: and have reviews just as usual
<bencc> zyga: https://bugs.launchpad.net/snappy/+bug/1584779
<ubottu> Launchpad bug 1584779 in Snappy "Upgrade a running snap without restarting it" [Undecided,New]
<bencc> thanks
<niemeyer_> jdstrand: Thanks.. this is rolling for a while, and I'm wondering if we have an ETA
<jdstrand> I can't say exactly-- I've not been involved in that. I can say there is an apparmor patch and iirc it was 'almost ready'. tyhicks will be online in 30 minutes or so
<zyga> jdstrand: https://github.com/ubuntu-core/snap-run/pull/1/files
<zyga> niemeyer_: ack, done right now
<niemeyer_> jdstrand: Thanks, will catch up with Tyler
<niemeyer_> jdstrand: When you have a moment, can you have a look at https://github.com/ubuntu-core/snappy/pull/1201
<zyga> slangasek: hey, did you propose a pull request to snappy, for os-release support?
<tyhicks> niemeyer_: I'm getting very close to having the patchset done to disable env scrubbing
<tyhicks> niemeyer_: should be done in the first half of this week (and then we'll need an SRU)
<niemeyer_> tyhicks: Sweet!
<zyga> jdstrand: hey, what does reload/load the profile for ubuntu-core-launcher itself
<zyga> jdstrand: I just realized that is is apparently nothing in the package
<zyga> jdstrand: ah, /etc/apparmor.d/usr.bin.ubuntu-core-launcher is a conffile
<zyga> jdstrand: bummer :)
<zyga> mvo: how do I remove a conffile from a maintainer script with as little pain as I can?
<mvo> zyga: dpkg-maintscript-helper rm_conffile /path/ last-version
<zyga> mvo: thank you
<abeato> hey, is there any equivalent to the old "snapcraft shell" these days?
<ogra_> nope
<ogra_> (you mean "snappy shell" i guess)
<ogra_> use a classic ubuntu install for now (it will come back)
<zyga> abeato: if you want I can give you a quick "gimme classic" shell script that works fairly well
<zyga> abeato: I'm sure we'll get proper classic support later on but this is just something that keeps people going
<abeato> zyga, that would be great to have :)
<zyga> abeato: in a moment, just in a meeting
<abeato> (the script)
<abeato> sure, thanks
<ogra_> mvo, so you want the delta shipped *inside* t3eh os snap ? not as a separate tarball ?
<mvo> ogra_: yeah, that was the idea, if its too huge it does not make sense, but lets try it, the nice property of this is that "classic.enable" will work everytime without network
<ogra_> yeah, neat ! never thought of it that way
<slangasek> zyga: yes I did, why?
<mvo> ogra_: its also super nice because we don't need to keep the two parts in sync (base-os and delta), its natually in sync. but yeah, if its too huge we need to rethink it but I am keen to try it
<ogra_> yeah, cant realyl be much
<Trevinho> jdstrand: hey, can I use strace when not in --dev-mode to check what's wrong?
<Trevinho> jdstrand: currently I'm getting a bad system call error
<zyga> slangasek: ah, we were just checking if that's you or someone else
<zyga> slangasek: thanks for confirming that
<zyga> abeato: soon :)
<zyga> abeato: testing now
<Trevinho> ype=1326 audit(1464016887.003:654): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16474 comm="strace" exe="/snap/electron-quick-start/100001/usr/bin/strace" sig=31 arch=c000003e syscall=101 compat=0 ip=0x7fec3323356e code=0x0
<zyga> jdstrand: how does the ubuntu-core-launcher apparmor profile get compiled and applied on install?
<slangasek> zyga: ah, heh :)
<ogra_> Trevinho, run "scmp_sys_resolver 101"
<ogra_> (on your snappy install)
<ogra_> that will tell you which syscal was blocked
<Trevinho> ogra_: that needs devmode though
<ogra_> scmp_sys_resolver doesnt need dev mode
<ogra_> and the blocking should be listed in syslog
<abeato> zyga, ack, nw ;)
<Trevinho> ogra_:  scmp_sys_resolver 101
<Trevinho> bash: /usr/bin/scmp_sys_resolver: Permission denied
<Trevinho> this is in a bash launched from a script inside snappy
<ogra_> oh
<ogra_> i was talking about a bare ssh shell
<ogra_> (but i assume yiou are on a desktop machine, sorry, that didnt strike me)
<Trevinho> yeah, this is runing ain a VM, but yeah
<jdstrand> Trevinho: you can't run strace from within a snap cause it needs ptrace. you can also install 'snappy-debug' then run 'sudo snappy-debug.security scanlog' and it will resolve the syscall for you
<jdstrand> or just use scmp_sys_resolver from outside the snap on a device of the same architecture
<Trevinho> jdstrand: it's ptrace yeah
<Trevinho> ouch... I'm getting the error snap has changes in progress... And I can't remove it :o
<Trevinho> what's happening
<Trevinho> ogra_: do you happen to know how to fix that? ^
<Trevinho> (it's in yakkety)
<Trevinho> I can't either use gdb... As syscall 135 (personality) get blocked
<sergiusens> zyga mind if I create a storeapi project on gh?
<sergiusens> zyga should I take over https://github.com/ubuntu-core/snapcraft/pull/503 ?
<zyga> sergiusens: not at all, let's do it
<zyga> sergiusens: looking
<zyga> sergiusens: yes, please, I didn't notice that feedback at all, I have a backlog of email to read
<zyga> sergiusens: and thank you!
<sergiusens> zyga sure thing, ping me if you have any questions
<zyga> sergiusens: thanks
<sergiusens> zyga well thanks for contributing to snapcraft ;-)
<zyga> jdstrand: quick question: canbus, should we allow it in the network/network-bind interface or should we have a canbus=yes attribute or a dedicated canbus-network canbus-network-bind interfaces or something entirely different?
<zyga> jdstrand: canbus is just a socket FYI
<Trevinho> mh, jdstrand you remember that electron hang (when unconfined), right... Not sure I'm debugging it well, but here's where it hangs http://paste.ubuntu.com/16635698/ To my eyes it doesn't say much though... As probably it's just stracing the sh launcher
<zyga> jdstrand: though I may have a partial picture: there seem to be two ways to talk to the driver (network iface and character device)
<ogra_> Trevinho, that broken lib path looks suspicious
<ogra_> (misses the arch in the triplet)
<Trevinho> ah mhm
 * Trevinho launching the core-laucnher gives me another issue instead http://pastebin.ubuntu.com/16636006/
<kyrofa> Trevinho, is the launcher suid root?
<jdstrand> zyga: I'm not familiar with canbus. I see that apparmor supports it as a domain type. (eg, 'network can,'). we only have coarse-grained mediation at this time (ie, the level I just mentioned)
<Trevinho> kyrofa: not sure... I've just launched what's inside the generated launcher script
<zyga> jdstrand: thanks
<Trevinho> ah... I'm getting something new now
<Trevinho> type=1326 audit(1464020595.183:187): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=30771 comm="electron" exe="/snap/electron-quick-start/100001/lib/node_modules/electron-prebuilt/dist/electron" sig=31 arch=c000003e syscall=141 compat=0 ip=0x7f23a44194a7 code=0x0
<Trevinho> 141 = setpriority
<jdstrand> zyga: reading only so briefly, this feels like a separate interface. 'network' doesn't convey to me 'Controller Area Network', but maybe others disagree. tyhicks, you may have an opinion
<sergiusens> Trevinho that should be fixed in whatever is supposed to be released soon I've been told
<Trevinho> sergiusens: ah, nice
<jdstrand> Trevinho: yes, I was able to get things running. I thought I mentioned that in a bug/card...
<Trevinho> jdstrand: mh, maybe I'm not in that card/bug :)
<sergiusens> jdstrand so what do I need to get the chromium/electron bits?
 * sergiusens is just back from holidays and trying to catch up with this fast paced world
<zyga> sergiusens: I'm back from not having a weekend and I feel the same :)
<ogra_> but you had vampires at least !
 * zyga enjoys tasty vampires
<zyga> raw, not well-made
<zyga> ;)
<ogra_> but with fresh garlic :)
<Trevinho> sergiusens: ah, I pinged you couple of times too :), as I'd like to discuss how to integrate quilt (or any other tool that might handle the sources before building) in snapcraft...
<zyga> jdstrand: how can I unload an apparmor profile reliably?
<jdstrand> sergiusens: 4 things are needed: the ldpreload library as detailed in bug #1577514 for shm, seccomp arg filtering in the launcher which is pending review, once that lands, updates to the policy for setpriority and seeing if we can allow @{PROC}/@{pid}/oom_score_adj in the default policy
<ubottu> bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514
<jdstrand> zyga: apparmor_parser -R /path/to/profile
<zyga> jdstrand: ahh, path to profile
<zyga> I assumed it was the profile name only
<zyga> is it possible to remove a profile by name?
<sergiusens> Trevinho we actually don't want something that manages patches. It is essentially a forked code base so it is no different
<jdstrand> there is another way via the /sys interface that I always forget
<zyga> jdstrand: I'm trying to remove ubuntu-core-launcher profile
<sergiusens> quilt is really tied to the packaging world
<zyga> jdstrand: after the upgrade to snap-run
<Trevinho> sergiusens: it's not the same... Sometimes patch stays there forever, while you don't want to upgrade your fork everytime upstream changes things.
<zyga> jdstrand: (and in general, how is the profile updated on package update?)
<Trevinho> sergiusens: we had some discussion in https://bugs.launchpad.net/snapcraft/+bug/1551716 and there seems to be general consensus to that
<ubottu> Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New]
<beowulf> sergiusens: i don't python so forgive me, but i think this would be nice for the nodejs plugin https://github.com/ubuntu-core/snapcraft/pull/509
<jdstrand> zyga: fyi, I have quite a few open PRs for policy updates related to sdoc. you said to ping you, so I'm pinging you
<jdstrand> https://github.com/ubuntu-core/snappy/pull/1193
<Trevinho> sergiusens: I come up with an hackish quilt build plugin, but it requires some yaml code which is not really so nice.
<jdstrand> actually, maybe it is just that one
<jdstrand> meh, I thought I fixed my procmail...
<sergiusens> beowulf I get a 404 there
<sergiusens> but happy to look
<beowulf> sergiusens: github is having service hiccups, it's a pr to add node-engine to yaml, allowing the dev to set which node version the package uses
<Trevinho> sergiusens: what I expect is also to be able to run some kind of tools to refactor the code before building in a dynamic way... sometimes you need to replace strings or names... and Well, having to keep a fork for that is not really the best thing. When you only want the $latest_upstream_code + $local_customization
<jdstrand> zyga: yeah, nm. I mean, feel free to look at that gsettings one but unping-- the others all made it and just didn't hit my inbox
<zyga> jdstrand: looking at 1193
<sergiusens> Trevinho a patchset you need to maintain is exactly a fork though
<sergiusens> Trevinho every time you need to update your upstream you need to reapply the patch on top, it is no different that always doing `git rebase master`
<Trevinho> sergiusens: it is, but it's different we way we manage it... And this would allow to use the same patcheset for both debian-based distro and for snappy pkgs
<sergiusens> Trevinho running a tool now is completely different than a patchset, right?
<sergiusens> Trevinho well, then check my comment on the bug ;-) I am not against adding a debian source package as a valid `source` entry, totally for that fwiw
<Trevinho> sergiusens: well, the thing is that in the current method, we can just launch snapcraft and get the latest source and the current patchest... If that doesn't apply we can redo it
<sergiusens> Trevinho I really think you are thinking of this from a packager's point of view; we want our snapcraft.yaml's to essentially live upstream somewhere too
<sergiusens> beowulf sounds good, we had that in the pipes; one thing we also need to add is choosing to npm in production mode or dev mode (prod being the default).
<Trevinho> sergiusens: I know it has to be upstream too... Indeed. But I'd love it to be flexible and thus it to adapt to both scencarios, since we can.
<beowulf> sergiusens: yes, but you can set that via env so i didn't think it was such an issue
<beowulf> sergiusens: or does that not work with the plugin?
<jdstrand> zyga: so, with the change to snap-run, all pending MPs need to be migrated?
<zyga> jdstrand: yep
<jdstrand> tyhicks: actually, I guess this is changing more-- https://github.com/ubuntu-core/snap-run/pull/1/files should ctually reference snapcore and not ubuntu-core
<zyga> jdstrand: I can help if anyone gets stuck
<niemeyer_> jdstrand: One more for your review requeue: https://github.com/ubuntu-core/snappy/pull/1202/files
<sergiusens> beowulf it does. I am thinking more of something like using builders. I am now sort of wanting to introduce the `environment` keyword for parts as we are doing for `apps`
<beowulf> sergiusens: right, makes sense
<josepht> sergiusens: have you considered having a part plugin which could pull parts from repos similar to apps sources?
<niemeyer_> Is Claudio Andre around here?
<niemeyer_> jdstrand: ping
<sergiusens> josepht apps sources?
<jdstrand> niemeyer_: hey
<niemeyer_> jdstrand: Heya
<niemeyer_> jdstrand: Any further points on the pulseaudio interface or do you think we can merge it now without any bad consequences?
<niemeyer_> jdstrand: Other than the recording issue we debated already
<jdstrand> I think it is ok so long as we are pursuing that SRU. lemme double check
<jdstrand> niemeyer_: ok, policy-wise, it's fine as-is. Note that this is still only for 'classic' which I'm not sure is what you intended for it (perhaps that was another PR...)
<jdstrand> (snap/implicit.go)
<jdstrand> I think since this is simple file rules, the policy would work for core too
<jdstrand> and I know the devices guys have a pulseaudio snap towards the bottom of their list (though, that list is getting shorter and shorter)
<jdstrand> anyway, I'm not saying we should block on that, just adding some context
<niemeyer_> jdstrand: Yeah, not ideal, but we shouldn't block on being classic only.. that's the only env we have users ATM, so okay for the time being
<niemeyer_> jdstrand: The opposite is more of a problem (an interface that does _not_ work on classic)
<josepht> sergiusens: sorry parts sources.  What I'm referring to is for shared parts (i.e. those on the wiki currently)
<niemeyer_> jdstrand: About that opencl interface, do you know what usually lands on that /etc directory?
<niemeyer_> jdstrand: Is that hardware specific, or just app config?
<niemeyer_> jdstrand: I assumed it was hardware-specific, but I was jumping to conclusions too soon
<jdstrand> niemeyer_: I'm not familiar with opencl. I two may have jumped to comclusions. Looking at the rules, I assumed that debs provided /etc/OpenCL/... and those files configured how binaries worked and that they were in /etc because it is something an admin would normally do
<jdstrand> too*
<jdstrand> for example, my laptop doesn't have that directory
<zyga> niemeyer_: opencl has a stream of packages, some belong in the os snap (or app snap), some in the kernel snap, some of that manifests itself as /etc/OpenCL
<zyga> niemeyer_: we should really get someone that knows opencl inside out to assist on that one
<niemeyer_> zyga: Well, we just need some basic info to get unblocked
<niemeyer_> zyga: As long as we don't do anything silly, it's okay to have a seed interface in
<zyga> niemeyer_: I agree
<zyga> niemeyer_: I can ask, I know a canonicaler that knows more
<niemeyer_> zyga: Sweet, thanks
<Saviq> sergiusens, ah, just realized - if launched from the dash, I'm getting multiple instances of Tg, but that's probably a unity7 bug (that's why I had more of them running)
<niemeyer_> jdstrand: Simon responded on #1202, can you please have a look to see if it looks sane now, or if we should unblock it on something else?
<niemeyer_> jdstrand: Sorry for bothering more than usual today.. we're trying to clean up the long-standing queue
<jdstrand> done
<jdstrand> np
<beowulf> zyga: hi! do you know any reason why ubuntu-image.sh shouldn't work right now? https://pastebin.canonical.com/157054/
<pmp> I followed the two threads on the ML regarding kernel builds for raspi2/3 - however I didn't find the answer I'm looking for:
<pmp> Where can I find the snap.yaml + the instruction to snap my own kernel/modules for a raspi2 - using the current method?
<pmp> I know you guys are changing things for the better, but I'd like to get along on my project - too impatient
<kyrofa> pmp have you seen http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ ?
<pmp> kyrofa: great. Do you also know where I can find the snapcraft.yaml for raspi2;s kernel currently in use ?
<kyrofa> pmp that I don't know. ogra_ might
<pmp> how does snapcraft find the right cross-compiler?
<kyrofa> fg
<thomi> sergiusens: Are you back from your holiday? I wonder if you could comment on https://bugs.launchpad.net/click-reviewers-tools/+bug/1582513 please?
<ubottu> Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New]
<kyrofa> pmp it has a list of supported architectures
<kyrofa> pmp, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/_options.py#L27 for example
<pmp> kyrofa: great article, answers a lot of questions
<kyrofa> pmp, thank sergiusens :)
<pmp> sergiusens: thanks ;-0
<pmp> It'll be nice to have an overview somewhere of all the blog-articles done by you guys.
<pmp> Or announce everyone of them on the mailing list in addition
<zyga> beowulf: hey
<zyga> beowulf: looking
<zyga> beowulf: not really.. is that most up-to-date version?
<zyga> beowulf: maybe store changed on us in some way
<beowulf> zyga: should be, let me check ...
<zyga> beowulf: (in any case, you will be happy to know the real ubuntu-image is being written, should be usable in around a week)
<beowulf> zyga: great :)
<beowulf> zyga: yes, it's the latest with the 5s sleep
<zyga> beowulf: no root, faster implementation, etc etc
<zyga> beowulf: but still depends on working store ;)
<zyga> beowulf: though it will have an offline more
<zyga> beowulf: lots of goodies
<zyga> beowulf: building one myself for 'pc'
<zyga> beowulf: so far builds fine
<zyga> beowulf: can you check syslog
<zyga> beowulf: I bet your kernel oops'ed
<zyga> beowulf: reboot and re-run
<zyga> beowulf: new ubuntu-image won't rely on any kernel feaatures so it should never crash like that
<beowulf> zyga: sorry, i have wasted your time, i keep forgetting this doesn't work in a container :(
<beowulf> zyga: i'm in a xenial container, it works when i'm on the host (i already knew this, sorry!)
<zyga> beowulf: no worries, if this can be detected somehow can you please open a pull request with a quick test and a message saying something appropriate?
<sergiusens> pmp you are welcome I guess :-)
<sergiusens> thomi looked and I am thinking of taking the hit right now to solve this
<thomi> sergiusens: thanks! It'd be great to be able to upload my snap
<beowulf> zyga: stackoverflow and online-services suggest `sudo grep -qa container=lxc /proc/1/environ`... will have a go at a pr later
<mhall119> hey guys, where does the "unity7" interface come from, and how would one go about creating something similar but for another desktop environment?
<kyrofa> mhall119, you probably want this series of blog posts: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<kyrofa> mhall119, but to quickly answer your question, that interface is part of snapd itself
<kyrofa> mhall119, so making new ones involves writing some go
<jdstrand> kgunn: I saw your response on qt webengine and was curious why oxide wasn't mentioned?
<kyrofa> mhall119, the blog posts will have a bit more information
<kgunn> jdstrand: just didn't think of it ;)
 * jdstrand nods
<kgunn> jdstrand: i guess i was trying to get mir out there....
<jdstrand> I wasn't sure if there was some reason why it couldn't be used
<kgunn> jdstrand: it could certainly be a potential stack configuration for the fellow's  use case
<kgunn> would be even better if we had native chrome-mir ;)
<kgunn> better=one less thing to pull into the snap
<mhall119> kyrofa: is that the long-term design, or a temporary measure to get the unity7 interface?
<zyga> beowulf: fantastic, thank you
<zyga> mhall119: hey, it comes from snapd itself, it's added to the core snap when running on classic
<zyga> mhall119: that's long term design for *classic*
<zyga> mhall119: tell me what you want and I can tell you what you need to get there
<mhall119> zyga: ok, so what's the long term design for non-unity7 classic desktops?
<mhall119> zyga: my specific use case is kubuntu, where they will likely need a kframeworks5 interface
<zyga> mhall119: that depends on what they need, many will work with unity7
<zyga> mhall119: unity7 is really granting you right to use various unit7 specific APIs
<mhall119> so as not to include every KDE dependency in their packages
<zyga> mhall119: for packaging apps for KDE I'd start with x11 for the desktop part
<zyga> mhall119: and with the (not implemented yet) content sharing interface for kde runtime
<zyga> mhall119: though for that, I'd like to first start with one fat test snap (fat as in having everything, not being multi-arch)
<zyga> mhall119: that we can then split into two while keeping it functioning as before
<zyga> mhall119: though perhaps another approach is required for proper kde support
<zyga> mhall119: (as in real access to classic KDE services and libraries)
<zyga> mhall119: for that we need some features that are under development by the security team and by snappy core team (bind mounts)
<zyga> mhall119: then we could do interesting new things
<zyga> mhall119: sadly I can only offer you one approach today: pick a simple kde app, make a very fat snap and run it in devmode, add x11 and see if it runs, then let's get started on the delta
<zyga> mhall119: then as those new generic features show up in the stack (content sharing and bind mounts) we can design a better interface that would make it possible to have a simple kde app just be a single snap with very little extra stuff bundled
<zyga> mhall119: note that unity7 doesn't give you any runtime libraries, just dbus permission and some basic "talk to x11" bits
<mhall119> zyga: you lost me, how would the content-sharing interface be used for the runtime?
<zyga> mhall119: sorry, there's a lot of context I assume you have, let me do it with more explanations
<zyga> mhall119: the content sharing interface grants you access to files from another snap as if they were your own
<mhall119> is content-sharing like content-hub on the phone,or something totally different?
<zyga> mhall119: so you can take one big snap and split it into arbitrary chunks and have the result work just as the original
<zyga> mhall119: it's not lile the content hub
<mhall119> ok, that's where the confusion hit me :)
<zyga> mhall119: tink of runtime sharing for instance (java, kde, qt, etc etc etc)
<mhall119> yes, that's what I want
<mhall119> a platform in a snap, basically
<zyga> mhall119: yep
<zyga> mhall119: there are a few things we need to implement before that is possible
<zyga> mhall119: permission side is simple, but we need to inform the consumers of where to find the shared parts
<zyga> mhall119: and we need to re-construct some magic to make it seem seamless (shared libraries, executables, etc)
<mhall119> zyga: ack, ok, this is all making sense now
<zyga> mhall119: those are just generic new features of snapd and snap-run (nee ubuntu-core-launcher) that need to happen first
<zyga> mhall119: I bet we'll get some kde specific interface over time but that's the first approach I would have
<zyga> mhall119: something to let us understand kde better
<mhall119> zyga: ack, I'm working on kcalc right now, will be back once I have it working
<zyga> mhall119: cool, cheersr, I'll ping you each time something new lands towards that goal
<mhall119> thanks zyga
<sergiusens> elopio reproduced on x86: bug #1551570
<ubottu> bug 1551570 in Snapcraft "autopkgtests fail in armhf with sudo: no tty present and no askpass program specified" [Medium,Triaged] https://launchpad.net/bugs/1551570
<beowulf> hi, i want my package 'start' command to be executed in the package folder (where package.json lives, it's an node package), how do i tell snapcraft to do that? add in a wrapper script and `cd /path/to/package && npm start`? how do i get the path?
<qengho> beowulf: Yes, you need a wrapper. $SNAP is the snap/ when you packaged with snapcraft. I'd "cd $SNAP; exec foo/start". You can be sure $SNAP exists.
<qengho> beowulf: beowulf perhaps with doublequote $@ doublequote at the end, in your wrapper.
<sergiusens> kyrofa and elopio what do you think about this https://github.com/ubuntu-core/snapcraft/pull/510 (just getting started, but I am liking how it is working out)
<sergiusens> thomi may I ask you to play with https://bugs.launchpad.net/snapcraft/+bug/1582513/comments/8 ?
<ubottu> Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New]
<sergiusens> zyga also want to look at that ^ ?
<thomi> sergiusens: sure thing
<beowulf> qengho: thanks!
<thomi> sergiusens: Any chance you could build a .deb and stick it somewhere? It seems snapcraft doesn't install easily into a virtualenv?
<sergiusens> thomi yeah, I inherited this like it is, I need to work on a requirements.txt to make this work well
<sergiusens> thomi scp from people.canonical.com:/home/sergiusens/snapcraft_2.8.8_all.deb
<sergiusens> thomi btw, I made some changes to your yaml http://paste.ubuntu.com/16644344/ (using the public git and relative `command`)
<thomi> huh, cool. I don't know about 'command'
<sergiusens> thomi so instead of using a relative command (`usr/bin/gmailfilter`) using the one in $PATH ($SNAP/bin in this case) as gmailfilter is in $PATH
<sergiusens> that last one is just personal preference fwiw
<thomi> huh, Interesting, thanks
<zyga> sergiusens: looking
<zyga> sergiusens: use the ... what in ubuntu core?
<zyga> python?
<thomi> sergiusens: wow - 55MB to 144KB
<zyga> thomi: same will be possible with a (say) python3.canonical snap and content sharing
<thomi> sergiusens: however, the snaps now consistently fail review because the checksums do not match
<thomi> sergiusens: security-snap-v2_squashfs_repack_checksum is the failing check
<sergiusens> thomi heh, that I think is a mksquashfs bug jdstrand was looking into
<thomi> :(
<sergiusens> zyga the python, yes
<sergiusens> thomi yeah, not sure what triggers even
<sergiusens> zyga do you know the bug number for the checksum thing?
<zyga> sergiusens: I cannot wait to do that :)
<zyga> sergiusens: no, sorry
<sergiusens> zyga do what?
<zyga> sergiusens: write the content sharing iface
<sergiusens> zyga you have been saying that for a year already it feels like :-)
 * sergiusens heads off to aikido practice, will bbl
<zyga> sergiusens: it's a loong way ;-)
<zyga> in reality it requires a few features that are in the pipe
<sergiusens> jdstrand when you are around, do we have a bug for that mksquashfs thing?
<elopio> sergiusens: cool, you simplifyied the code a lot.
<elopio> just the "pass" in the tests makes me feel uneasy ;)
<zyga> elopio: yes, it should have been a docstring, then pass is optional ;)
<elopio> zyga: no me simpatizas.
<wililupy> question: how do I purge a snap from 16.04?
<zyga> wililupy: snap remove $snap_name
<zyga> wililupy: that's all you need
<wililupy> zyga: I did that, but when I try to install an updated one that I am working on it says it can't mount revision 100001
<wililupy> zyga and it still shows it in /writable/system-data/snap but not in snap list
<wililupy> also in /var/lib/snapd/snaps and /var/lib/snapd/state.json
<zyga> wililupy: hmm
<zyga> wililupy: is that an all-snap image or a snappy-on-classic
<zyga> wililupy: if all-snap can you refresh ubuntu-core?
<wililupy> zyga: I just ran snap refresh ubuntu-core
<wililupy> zyga: still get the same error.
<mhall119> zyga: I got it running in --devmode at least
<mhall119> zyga: see https://github.com/ubuntu/snappy-playpen/tree/kcalc/kcalc
<mhall119> specifically the apparmor complaints, I have no idea what it's doing or why, but it seems strange for a calculator
<wililupy> zyga: when I tried to remove the snap, I did get an error: https://pastebin.canonical.com/157073/
#snappy 2016-05-24
<sergiusens> elopio the tests I will work on now, not that the previous test was covering much either :-P
<zyga> wililupy: catch me tomororw please
<zyga> mhall119: cool!
<wililupy> np zyga. Thank you.
<ePierre> Hi!
<ePierre> I'm having troubles with a snap I installed and I want to remove.
<ePierre> (I'm on Xenial)
<ePierre> So I installed the Telegram snap by running "sudo snap install telegram-sergiusens"
<ePierre> And then after using it a little I decided I wanted to remove it
<ePierre> so I ran
<ePierre> sudo snap remove telegram-sergiusens
<ePierre> but then it complained about some stuff, and now I'm in limbo: the Telegram app is not available anymore, but I keep receiving notifications, and it still appears when doing `snap list`
<ePierre> if I try to remove it again it says
<ePierre> error: cannot remove "telegram-sergiusens": snap "telegram-sergiusens" has changes in progress
<ePierre> and in systemctl, I see this error: "Failed unmounting Squashfs mount unit for telegram-sergiusens."
<ePierre> what can I do?
<olympionex> I'm trying to build a snap for 16.04 desktop that contains a driver library for a 3d camera.  Typically this library installs some udev rules for usb devices connected to the system.  Is there anyway to achieve the equivalent for my snap?
<mvo> jdstrand, tyhicks if you could do a review of https://github.com/ubuntu-core/snap-run/pull/3/files that would be much appreciated
<mvo> jdstrand, tyhicks and do you happen to have any idea about the apparmor env scrubbing?
<pmp> ysionneau: regarding your ptmx-problem, could it be apparmor-profile-name problem?
<pmp> ysionneau: I found this commit which has been integrated into 3.12: https://goo.gl/xcvOmU
<pmp> ysionneau: in it they are doing profile-name mangling - slashes become dots
<pmp> ysionneau: maybe it is not a mount-problem but a profile-name-problem
<pmp> ogra_`: ayt?
<ogra_`> pmp, hey
<ysionneau> pmp: hmmmmm maybe, I'm not sure about this
<pmp> ogra_`: hi, I think you are the one building the kernel snaps for rpi2?
<ogra_`> yeah, note that i use the debs from the archive though, if you want the contents of the deb changed ppisati is your man
<ogra_`> (i.e. actual kernel changes)
<ogra_`> (deb's i shoudl say, it is more than one :) )
<pmp> ogra_`: so if I need the .config and the snapcraft.yaml/snap.yaml ppisati is my man, as you say ;-) ?
<ogra_`> http://paste.ubuntu.com/16630580/ funnily i just pasted a snippet from the build script yesterday ...
<ogra_`> this is how we assemble the snap.yaml
<ogra_`> if you grab the xenial-preinstalled-core-armhf.raspi2.kernel.snap from http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ you can use unsquashfs to extract the file to see the result
<pmp> ogra_`: I build my kernel locally, I could just install it so that the snap.yaml will find all the bits and pieces?
<ogra_`> for building locally i'd rather recommend using snapcraft
<ogra_`> it has a kernel plugin that should do everything you need
<pmp> yes, I saw the sergiusens article
<pmp> then I only need a .config-file
<pmp> bcm2709_defconfig does not activate apparmor - it seems
<pmp> ogra_`: is xenial-preinstalled-core-armhf.raspi2.kernel.snap the snap which is downloaded by u-d-f?
<ogra_`> the config is generated from different snippets at build time
<pmp> yes, but on a standard kernel build the .config is stored along with the kernel-image - that would be sufficient
<ogra_`> you can grab  https://launchpad.net/~canonical-kernel-security-team/+archive/ubuntu/ppa/+build/9738878/+files/linux-image-4.4.0-1010-raspi2_4.4.0-1010.13_armhf.deb (the last kernel in xenial as https://launchpad.net/ubuntu/+source/linux-raspi2 shows)
<ogra_`> in there you find a /boot/config-$version usually
<ogra_`> http://paste.ubuntu.com/16652276/
<ogra_`> (i had it locally :) )
<pmp> yes, thanks for all these pointers - quite hard to find my way through this jungle
<ogra_`> yeah
<ogra_`> we once had /proc/config.gz enabled in the arm kernels ... but somehow that got dropped
<ogra_`> and the kernel snap doesnt allow copying the config into /boot
<ogra_`> so it is kind of hard to get the default config from the official kernels ... we'll fix that while re-working the kernel snap :)
<ogra_`> i also know that there is some work on a script going on that snapcraft should ship .... to parse the config and require all needed defaults
<ogra_`> (but i think thats still in its early stages)
<pmp> ogra_`: fyi, I need to update my kernel because of IIO-drivers only present in 4.6.0
<ogra_`> pmp, hmm, you shoudl perhaps ask ppisati, he might be having a 4.6 work-branch somewhere already
<pmp> ogra_`: my goal is to see what's missing in the standard snappy-interface to make it work
<pmp> ogra_`: what timezone is ppisati?
<ogra_`> europe
<pmp> ysionneau: the problem is definitely in the kernel - this is the only difference between raspi2 and your device
<pmp> ysionneau: our device ;-)
<pmp> ysionneau: when you look at the code of apparmor in 3.10 you'll see a function adding slashes to paths-strings - maybe it is that.
<ysionneau> ok let's try the patch you pasted :)
<pmp> ysionneau: not sure it applies
<zyga> o/
<pmp> ysionneau: maybe try updating to 3.18 as a kind of brutal bisect for this issue - if you can
<ysionneau> oh btw it seems we got an update we now have 3.10.96 kernel
<pmp> ysionneau: That's what I saw yesterday
<dholbach> salut didrocks - can you merge https://github.com/ubuntu-core/snappy-dev-website/pull/3?
<mvo> jdstrand, tyhicks: nevermind, I found #1584069 so my questions about apparmor and AT_SECURE are answered
<didrocks> dholbach: I didn't do it right away because of the "Looks good, just have a question
<didrocks> "
<dholbach> oh
<didrocks> but it seems it's fixed now
<didrocks> merging :)
<dholbach> that was something... yes, it's fixed
<dholbach> thanks!
<didrocks> (merged)
<jdstrand> sergiusens: we have 4 different mksquashfs bugs for resquash test. I've disabled the test until I have time to get back to it
<noizer> Hi
<noizer> stupid question where can I find the latest image of snappy
<noizer> I want to try my snap on a clean new image
<kyrofa> noizer, not a stupid question-- we're in a bit of a weird spot where we don't actually have images for snappy 16 right now (we will soon). You know you can use them on the desktop (or server), right?
<noizer> kyrofa yes I know that but its for my raspberry pi 2
<ogra_> you can still use ubuntu-device-flash from mvo's all-snaps dir
<noizer> kyrofa: a bit ago i downloaded a snappy 16 image
<ogra_> note that you will likley have to re-flash once we switched to new kernel and gadget definitions though
<noizer> I know but is there a link where I can download the image ogra_
<jdstrand> mvo: hey, I had a PR against ubuntu-core. do I need to re-request it against snapcore or is some other magic happening?
<ogra_> didnt change sice i last gave it to you ;)
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<ogra_> but really, better grab ubuntu-device-flash and roll an image yourself ... the ready-made ones are likely outdated
<mvo> jdstrand: yeah @zyga has the details
<sergiusens> good morning!
<sergiusens> kyrofa how did the python3 plugin branch look like? (tests aside
<kyrofa> sergiusens, hey there! I think it looks pretty good-- I need to look it over a little more carefully
<sergiusens> kyrofa yeah. It is though a lot better than what was there before
<noizer> ogra_:  Ok is that very difficult?
<ogra_> noizer, sudo ./ubuntu-device-flash core 16 --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o my-shiny-image.img
<noizer> okay thx xD
<noizer> ogra_: pfff systemctl not found :s
<ogra_> ?
<noizer> need '/bin/systemctl to work
<noizer> thats the error :s
<ogra_> not sure what you mean
<noizer> when I'm running you command i got that
<noizer> thats on my virtual machine ubuntu
<ogra_> noizer, http://paste.ubuntu.com/16654988/
<ogra_> well, no idea what that is then
<josepht> what is the proper plug for creating local sockets?  Is running the snap command as root via sudo going to cause a problem?
<sergiusens> Chipaca` mind reviewing https://bugs.launchpad.net/snapcraft/+bug/1579931 ?
<ubottu> Launchpad bug 1579931 in Canonical Click Reviewers tools "snapcraft builds snaps which fail checksum verification on upload" [Undecided,New]
<sergiusens> err
<sergiusens> Chipaca` https://github.com/ubuntu-core/snapcraft/pull/510 this
<noizer> ogra_: will try it on other system
<ogra_> well, worst case just pull a pre-built one ...
<kyrofa> josepht, no, running snap as sudo should be fine
<kyrofa> josepht, without testing, you probably need network-bind
<jdstrand> zyga: hi! mvo said there is some procedure to follow for moving existing PRs against ubuntu-core to snapcore?
<noizer> ogra_: On what system are you trying to make it?
<ogra_> thats a standard xenial install
<noizer> but I try to build it on a ubuntu ( not snappy OS )
<Chipaca`> sergiusens: hi
<noizer> ogra_: on my snappy of my raspberry pi 2 i got a syntax error :s
<ogra_> for what ?
<noizer> ./ubuntu-device-flash.1: Syntax error: "(" unexpected ogra_
<ogra_> dont run it on snappy :)
<ogra_> you need a 15.10 (or newer) desktop or server install
<noizer> ok but on my ubuntu desktop i got the /bin/systemctl that he doesn't find how can I install it?
<noizer> owkey now i got 14.04 LTS
<ypwong> beuno,  hi, my upload to the store is rejected, I wonder if this is actually a bug in the store? I have the details in https://bugs.launchpad.net/snappy/+bug/1584346
<ubottu> Launchpad bug 1584346 in Snappy "Store reports "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"" [Undecided,New]
<zyga> jdstrand: hey
<zyga> jdstrand: well it involves git init
<zyga> jdstrand: bzr fast-export --quiet --plain --git-branch snap-run . | git fast-import --quiet
<zyga> jdstrand: (with some unpackaged code, last time I checked)
<jdstrand> zyga: I wasn't talking about snap-run (but thanks!), I was talking about my gsettings PR
<zyga> jdstrand: followed by rabase -i origin/master (the origin from github) to remove the patches that are upstream but were converted locally anyway
<zyga> jdstrand: oh
 * zyga re-reads
<zyga> jdstrand: hmm, didn't those move automatically?
<zyga> jdstrand: if no then I don't know anything about that
<jdstrand> zyga: I don't know-- were the supposed to? if so, I'll just poke around
<zyga> jdstrand: did yours move?
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/1160
<zyga> jdstrand: this moved for me
<zyga> jdstrand: just edit your .git/config
<zyga> jdstrand: sed the repo name
<zyga> jdstrand: and you're good
<jdstrand> it looks like it did
<jdstrand> ok, that's fine. thanks!
<jdstrand> mvo: can you remind how, when and where to use Closes: LP:NNNNNN. I wrote it down but I think I got it wrong based on PR changes from others
<jdstrand> I think an SRU comment on one of my bugs might have been because I did it wrong
<josepht> kyrofa: I've got both 'network' and 'network-bind'.  Specifically I'm referring to the nmap snap in the store
<kyrofa> jdstrand, gbp dch uses `LP: #<bug>` by default
<beuno> jdstrand, hi!  can you queue this up?  https://bugs.launchpad.net/snappy/+bug/1584346
<ubottu> Launchpad bug 1584346 in Snappy "Store reports "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"" [Undecided,New]
<kyrofa> Not sure what incantation mvo is using though
<beuno> jdstrand, looking at it, that is  :)
<jdstrand> beuno: that's a dupe of another bug
<jdstrand> sergiusens: I'm still not clear on what to do on that ^ (libmvec.so)
<sergiusens> jdstrand oh, it is a snapcraft bug from what I believe. In any case, I don't think it to be bad to allow those symlinks, they just point to libc versioned libs
<sergiusens> and libc6 we support
<jdstrand> sergiusens: you closed the review tools task on the python one, but that one may not be python...
<jdstrand> sergiusens: ok, that is what I wanted to know. thanks!
<jdstrand> roadmr (cc beuno): can you sync r666 for bug 1584346?
<ubottu> bug 1584346 in Canonical Click Reviewers tools "Store reports "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"" [High,Fix committed] https://launchpad.net/bugs/1584346
<roadmr> jdstrand: sure thing
<jdstrand> roadmr: thanks. curious, did the previously requested sync make it past staging?
<roadmr> jdstrand: nope, I was planning on doing a deploy starting this week but I was off yesterday
<jdstrand> Ok, thanks
<roadmr> jdstrand: wait, r666? are you sure? ð
<jdstrand> hehe, I know, right?
<roadmr> hehe yes :) no prob though
<sergiusens> kyrofa btw, have you seen my comment here https://github.com/ubuntu-core/snapcraft/pull/502
<sergiusens> ?
<sergiusens> kyrofa you also have conflicts there ;-)
<kyrofa> sergiusens, yeah I did, and it got me thinking. Since it's just copied through I don't actually care how it's parsed, but I care how it's validated, so now I'm thinking I'll make it a custom type and write a custom validator for it
<kyrofa> Because yeah, this whole numeric/string thing is killing me
<kyrofa> sergiusens, how do you feel about that solution?
<sergiusens> kyrofa custom validator using the format checker? that seems fine
<kyrofa> sergiusens, alright. Then we don't need to care about how yaml wants to parse it
<mvo> jdstrand: the format for the changelog got discussed with niemeyer  a while ago, I wrote a custom snappy-dch to parse this stuff
<kyrofa> mvo, have you guys considered writing a CONTRIBUTING.md covering that stuff?
<mvo> kyrofa: I think we have a file like this, I don't think it has this in it though, the idea is really good
<kyrofa> mvo, yeah you have one, but it doesn't discuss this stuff
<jdstrand> mvo: yeah, I recall you telling me that and what to do, but I seem to have gotten it wrong. if I want snappy-dch to correctly parse for autoclosing, what do I need to do and where?
<jdstrand> I'll take better notes this time
<mvo> jdstrand: let me try to find the original conversation
<sergiusens> zyga in order for you to be a more relaxed person, I will be snatching this from you https://bugs.launchpad.net/snapcraft/+bug/1581166
<ubottu> Launchpad bug 1581166 in Snapcraft "unused and potentially confusing support for plugs/slots at a part level in the snapcraft.yaml schema" [Medium,In progress]
<zyga> sergiusens: thank you :)
<sergiusens> kyrofa so is that epoch stuff a future thing or are you going to update the branch?
<kyrofa> sergiusens, just about done
<seb128> qengho, hey there, you fontconfig issue ... is it https://bugs.launchpad.net/snapcraft/+bug/1576303 ?
<ubottu> Launchpad bug 1576303 in snapcraft (Ubuntu) "Needs fontconfig integration" [Undecided,Confirmed]
<kyrofa> Sorry sergiusens, epoch stuff is updated
<kyrofa> sergiusens, jsonschema updates always take me a little while :P
<sergiusens> kyrofa hope it doesn't conflict with https://github.com/ubuntu-core/snapcraft/pull/514
<jdstrand> zyga: hey, so what is the plan for snap-run and series 16? I've got my seccomp arg filtering branch and need to know if I need to do it against both ubuntu-core/snap-run (shouldn't this be snapcore/snap-run?) and something else for xenial or just ubuntu-core/snap-run
<kyrofa> sergiusens, I don't think it will, but it'll be easy to resolve if it does
<jdstrand> mvo: perhaps you know? ^
<sergiusens> kyrofa reviewed, looks good, I wonder why the 1.0 thing was tested before though
<kyrofa> sergiusens, it probably shouldn't have. I think I was experimenting with how the multipleOf thing worked and never took it out
<josepht> kyrofa: it looks like I needed 'network-control' as well
<kyrofa> josepht, that's odd... you must be doing something other than just sockets
<sergiusens> kyrofa btw, mind taking a look at 514?
<kyrofa> sergiusens, but anyway, do you like that better than the previous validations?
<kyrofa> sergiusens, yeah I'm actually looking at it now
<sergiusens> kyrofa yes, this is much better
<sergiusens> simpler
<kyrofa> sergiusens, I finally feel like I've figured jsonschema out a little more
<kyrofa> My previous attempts were working against it a bit
<sergiusens> kyrofa yeah, this schema thing is kind of strange
<sergiusens> kyrofa it would be nicer to get better raw data to construct nicer error messages
<sergiusens> kyrofa btw, does this look weird to you https://github.com/ubuntu-core/snapcraft/pull/505 ?
<kyrofa> sergiusens, we can do that with more formats over time if you like that approach
<kyrofa> Oh right, I never actually commented on that one huh
<kyrofa> sergiusens, wait... yeah
<kyrofa> sergiusens, what happened here?
<kyrofa> sergiusens, oh, old diff?
<kyrofa> sergiusens, it just needs to be merged with master I think
<sergiusens> kyrofa it looks like not only an old diff, but the only diff is about strict
<sergiusens> going to try and ping elopio and see if he can click on "update branch"
<kyrofa> Yeah it's due to my changing that commit
<sergiusens> kyrofa darn, it has only been 1 hour since he said 2 hours :-)
<kyrofa> Hahaha
<sergiusens> kyrofa you should re create the PR ;-)
<kyrofa> sergiusens, sure thing ;)
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/515
<zyga> jdstrand: I'm not sure, I think we want to use it as soon as it is viable
<zyga> jdstrand: we need the migration command on snapd
<zyga> jdstrand: though we can actually land the package as-is as it has backwards compatible wrapper (ubuntu-core-launcher) that calls snap-run
<zyga> jdstrand: (though it may not be possible to do that soon if we remove the binary command as an argument)
<zyga> jdstrand: I would rather transition everything ASAP
<jdstrand> that's fine
<jdstrand> that makes it easier on me
<jdstrand> I just have to do the one PR then
<jdstrand> note, tyhicks said he'd do the arg filtering review this week
<jdstrand> ah geez
<jdstrand> it is now s/snapcore/CanonicalLtd/ ?
<jdstrand> zyga: ^ ?
<jdstrand> ok, apparently not yet
 * jdstrand continues with ubuntu-core/snap-run
<zyga> jdstrand: it will be soon
<zyga> jdstrand: I cannot change htat
<sergiusens> jdstrand is the fix for chromium content provider in -proposed already? or can you ping me when it is? Out of curiousity was it solved with a mount dance or with interface changes?
<sergiusens> Saviq btw, did you snap refresh telegram-sergiusens already?
<jdstrand> sergiusens: I mentioned the other day there are 4 things to address it. none have landed. one depends on zyga (shm preload), the seccomp arg filtering branch to land (in progress, hopefully will land this week), then seccomp arg filtering profile updates (dependent on other landing) and then another denial
<Saviq> sergiusens, did not
<jdstrand> I think that last one is non-fatal, but I'll be looking at that today
<Saviq> sergiusens, thanks :)
<sergiusens> jdstrand so 4 things for this and 4 for squashfs :-P
<jdstrand> sergiusens: there is no shortage of things to do
<jdstrand> I suspect one of those 4 things for squashfs is a dupe, but I need the snap to be sure
<jdstrand> but as mentioned, the squashfs issue will not be painful for people-- the test is being disabled
<sergiusens> jdstrand I can get you the yaml used to generate it
<sergiusens> jdstrand use this branch of snapcraft https://github.com/ubuntu-core/snapcraft/pull/510 with http://paste.ubuntu.com/16644344/
<sergiusens> or grab my deb from people.canonical.com:/home/sergiusens/snapcraft_2.8.8_all.deb
<netphreak> Hi, guys ;)
<sergiusens> jdstrand and here it is https://bugs.launchpad.net/click-reviewers-tools/+bug/1579931/comments/2
<ubottu> Launchpad bug 1579931 in Canonical Click Reviewers tools "snapcraft builds snaps which fail checksum verification on upload" [Undecided,New]
<sergiusens> netphreak hey
<netphreak> has classic shell returned to snappy?
<kyrofa> netphreak, not yet, but we're working on it
<netphreak> Any indication on, when?
<kyrofa> netphreak, I'm not sure, maybe ogra_ knows
<ogra_> i want to have the build side ready by end of this week
<ogra_> then there are some bits on the snappy side needed i think
<netphreak> ok cool.
<netphreak> Are there any release dates for snappy?
<sergiusens> he left, but the answer was, it is already released ;-)
<jdstrand> sergiusens: thanks
<jdstrand> sergiusens: I also added you to the card tracking the electron stuff
#snappy 2016-05-25
<zyga> o/
<noizer> ogra_: Hi I installed yesterday my new build of snappy
<noizer> but when I'm trying to use snappy as command then i got : command not found
<zyga> noizer: snappy is now "snap"
<zyga> noizer: (the command)
<noizer> ow dam
<noizer> zyga excuse me
<noizer> zyga when I'm starting up my ssh tunnel then it comes : It's a brave new world here in snappy Ubuntu Core! This machine
<noizer> does not use apt-get or deb packages. Please see 'snappy --help'
<noizer> for app installation and transactional updates.
<noizer> maybe change that?
<zyga> noizer: yes, stale motd most likely
<noizer> zyga :p shell classic does that changed too?
<zyga> noizer: ?
<zyga> currently there's no classic shell
<noizer> ok
<noizer> so the builds needs to be developed from somewhere else?
<zyga> noizer: you can get a chroot and use that
<zyga> noizer: I have a simple script, not tested really
<zyga> http://paste.ubuntu.com/16675069/
<zyga> noizer: if you take that and test it you could help me out
<zyga> this is poor man's classic
<noizer> ok I'l try it out for you
<zyga> noizer: that dpkg --print-architecture was suppoed to be 'uname -m'
<zyga> noizer: anyway, you get the idea
<noizer> zyga So when its not working I need to change somethings?
<zyga> noizer: yeah, there's no dpkg on the image
<mwhudson> mvo: good morning, did i talk to you about go shared libraries and snappy recently?
<zyga> noizer: change it to use uname -m instead of dpkg --print-architecture
<zyga> mwhudson: o/
<noizer> ok
<mwhudson> zyga: hi
<noizer> zyga little mistake wget isn't available on newest xenial build
<noizer> I'l will download it myself xd
<noizer> zyga hyperlink doesn't work ether
<zyga> noizer: hmm :)
<zyga> noizer: the link was okay when I checked it, perhaps the arch is wrong,
<zyga> noizer: in any case, please use that as a starting point
<noizer> ok thx
<zyga> noizer: note, perhaps, ironically, the easiest way for this is to create a snap
<zyga> noizer: that has minimal tooling (wget) to setup classic
<zyga> this is just a stop gap before classic returns as a built-in thing though
<noizer> zyga lol xD
<noizer> Ok i try to make the snap and send you the snap for other developers
<zyga> noizer: well, whatever helps you move your snaps around :)
<noizer> zyga heheh it's a pleasure to help ubuntu snappy :D
<noizer> with such good support
<zyga> noizer: did you get luck with that armel snap you were working earlier?
<noizer> zyga didn't get it snapped but my TTS of nuance works now
<noizer> on a ubuntu LTS
<noizer> and on the classic shell of an older snappy
<noizer> so when i got it snapped I'll let you know about this
<noizer> zyga thx for all the help of that it is a very good cost changer for us
<nimoov> Hello everybody. I was wondering how to properly package LLVM/Clang with Snapcraft. LLVM & Clang are separated in two different git repositories, and Clang needs to be git cloned into a subdirectory of LLVM. I couldn't find any doc about parts with multiple git sources. Is it necessary to write a snapcraft plugin?
<zyga> nimoov: you can create a snapcraft plugin that understands this
<zyga> nimoov: you can use makefiles to create symlinks
<zyga> nimoov: you can build everything with a script on the side and just copy bits with snapcraft
<zyga> nimoov: anything that rocks your boat :)
<nimoov> Well that is great. Loads of options. I like that. Thank you for the help ;)
<zyga> nimoov: good luck, I was exploring with a rust-in-a-snap package
<zyga> nimoov: and I just started with prebuilt rust as a starting point
<noizer> zyga snap install noizersnap.snap --allow-unauthenticated               what is wrong about this?
<zyga> noizer: is that 16 or 15.04?
<noizer> 16
<zyga> noizer: on 16 that's snap install --devmode ...
<zyga> noizer: --allow-una.adsasdads (terrible word) is gone :)
<noizer> zyga niceee
<zyga> noizer: :-)
<noizer> zyga I tried to make the snap on my Virtual Machine Ubuntu 16.04 LTS and install it on my rpi 2 but thin its incompatible is there some way to cross snap it?
<zyga> noizer: no, not in general yet
<zyga> noizer: I would recommend to get two PIs
<zyga> noizer: one with something like ubuntu mate
<zyga> noizer: and one with an all-snap image
<zyga> noizer: or just an all-snap image and that classic script
<zyga> noizer: (I did that last weekend)
<noizer> hehe got 4 rpi so no problem
<noizer> maybe i build it on a prev version of snappy it will work too
<zyga> noizer: cool, ping me if you get stuck, I was through that experience :)
<zyga> noizer: you cannot quite run snaps on mate yet, we're working on fixing some things that prevent that today
<noizer> zyga ok nicee. maybe an other question about the release date of snappy. It is for my bosses. when will there be a LTS of snappy?
<noizer> is that Ocotober?
<noizer> *October
<zyga> noizer: I don't know, we keep trying to release periodically (weekly)
<zyga> noizer: we just need to get better at it
<noizer> ok
<noizer> snap install wget should working just now finding the correct hyperlink
<noizer> zyga it works I will snap it and sent it too you
<zyga> noizer: woot, great
<noizer> just did some changes on you shell script
<noizer> maybe not the best ones but is worked on my ubuntu :D
<mvo> mwhudson: no, you did not talk about shared libraries with me recently
<mvo> JamesTait: do you happen to know if the new /api/v1/metadata branch made it to staging yet? mbordese was working on this and I would love to run curl against it to validate
<mvo> JamesTait: validate my mock data I put in my tests if they actually match what the store is sending
<JamesTait> mvo, it's there, yes.
<JamesTait> mvo, it's even in Production.
<mvo> JamesTait: there is a new-new version of it that takes a dict instead of the previous version that just took ids, is that also available?
<mvo> JamesTait: it complains in production that I did not send ids, do you know what staging server I should use?
<JamesTait> mvo, not yet, no, but I believe the work is scheduled.
<mvo> JamesTait: search.stagging.apps.ubuntu.com ?
<JamesTait> search.apps.staging.ubuntu.com
<mvo> JamesTait: aha, ok. I will just wait for it to happen then. thank you!
<JamesTait> mvo, in somewhat-related news: I've noted your bug report about searching for "_" behaving oddly.
<JamesTait> mvo, I can explain that: we recently switched to a different type of query on the back-end, and also took a more aggressive approach to cleansing queries.
<JamesTait> mvo, this was to reduce the several thousand OOPS reports we were getting daily, mostly from what looks like people accidentally pasting code snippets into the search bar, or leaning on their keyboards.
<JamesTait> mvo, because, frankly, since we enabled snaps on the desktop, the daily OOPS report has been useless.
<JamesTait> mvo, now we've got that under control and can see if there's an *actual* problem, I'm working on re-enabling "special" characters, or at least as many of them as I can.
<mvo> JamesTait: ok, thats fine, I think we will add some client side filtering to that as well then
<mvo> JamesTait: just wanted to double check that this is intended bevhaior
 * mvo can't type and gets lunch :)
<noizer> zyga: how does i need to send you the snap and even the script?
<zyga> noizer: email to zygmunt.krynicki@... at canonical.com
<noizer> zyga: sended
<zyga> noizer: btw, I have something new
<zyga> noizer: if you want to give it a quick spin before I publish it
<noizer> sure
<noizer> zyga what is the new thing xD
<zyga> noizer: https://github.com/zyga/devtools/blob/classic/refresh-bits
<zyga> noizer: refresh-bits 2.0
<zyga> noizer: I would appreciate any testing you can do
<noizer> zyga I want to do that but honestly I didn't used refresh-bits 1.0 but I'l give it a shot
<noizer> zyga is that the thing that you explained a while ago?
<zyga> noizer: ah, if you don't hack on snapd itself then this is of no use
<zyga> noizer: thanks
<noizer> is that for the REST api? snapd?
<noizer> zyga
<noizer> zyga: I will do that later but then it should be intresting to test it right now
<zyga> noizer: that's okay, I will also test this :)
<zyga> noizer: and after all, there's always 2.0.1 ;)
<noizer> zyga yes sure xD thats development
<noizer> zyga does ubuntu searches people for snappy xD
<noizer> snappy is so intresting for me xD
<zyga> noizer: I think snappy is interesting to many people :)
<noizer> zyga sure xD
<noizer> zyga Does ubuntu recruit many people for snappy?
<zyga> noizer: what do you mean by that?
 * zyga has improved classic.sh to just be a script, no deps required
<noizer> If ubuntu searches people to work on snappy
<zyga> noizer: canonical or ubuntu?
<zyga> noizer: anyone can work on snappy
<noizer> canonical xD
<zyga> noizer: build snaps, send pull requests
<zyga> noizer: for working for canonical, check out http://www.canonical.com/careers
<noizer> zyga ok thx I will have alook tonight xD
<noizer> zyga after my dayjob xD
<noizer> zyga what does i need to test of the refresh bits?
<noizer> zyga because i saw i used 1.0.* before
<zyga> noizer: well, it's just useful if you are patching snapd locally
<zyga> noizer: you have to first have the full source tree
<zyga> noizer: don't worry about that if you're not interested in hacking on go
<noizer> zyga ooh ok
<noizer> if you have other stuff where you need some help you can contact me and we see then if i can do that
<zyga> noizer: thanks
<josepht> on ubuntu core images (i.e. u-d-f core ...) /snap/bin is in root's PATH but not on ubuntu classic images (snapd 2.0.3)  Is that expected?  Will that change?
<zyga> josepht: probably a bug
<zyga> josepht: can you please report it
<zyga> https://github.com/zyga/devtools/blob/master/classic.sh
<zyga> ogra_: ^^
<zyga> ogra_: fire away and tell me if that is sane
<zyga> this gives you classic on any snappy device
<josepht> zyga: there's already bug 1576716 if that's not sufficient let me know and I'll file a separate bug.
<ubottu> bug 1576716 in snap (Ubuntu) "Snap application requires root privileges " [Undecided,Confirmed] https://launchpad.net/bugs/1576716
<zyga> hmmm
<zyga> josepht: that's not it I think
<zyga> although
<zyga> yes it might be the same
<ogra_> zyga, hehm your use of TRAP is interesting
<zyga> ogra_: oh, did I make a mistake?
<ogra_> doesn6t that EXIT after the first unmount ?
<zyga> no
<zyga> it really work
<zyga> it will EXIT when the shell quits
<zyga> I don't exec
<ogra_> you should call some kind of cleanup function that loops over the mounts and only have one trap
<ogra_> are you sure it unmounts them all ?
<zyga> ogra_: ohhh, maybe not !
<zyga> ogra_: I see what you mean now
 * zyga checks
<ogra_> i would guiess it stops after proc
<ogra_> leaving 7dev and sys behind
<zyga> ogra_: thanks, it is broken indeed
<ogra_> jzst create a cleanup() function you call from the trap ...
<zyga> yep, thanks
<noizer> sergiusens: Hi is that normal when I'm downloading snapcraft from github and install it that there many dependencies missing?
<ogra_> the rest looks sane
<zyga> ogra_: better?
<kyrofa> noizer, you probably shouldn't install from github, just run out of its bin/
<noizer> kyrofa: Ok
<ogra_> zyga, probably unmount -l ... then it doesnt fall apart iof it cant unmount cleanly
<kyrofa> noizer, to make sure you have the right dependencies, you can use apt-get build-dep snapcraft
<zyga> ogra_: thanks
<zyga> done
<ogra_> cool
<ogra_> zyga, oh, you might want a sudo check
<ogra_> ahm there is one, sorry
<ogra_> scrolled off screen
<ogra_> zyga, http://paste.ubuntu.com/16680321/
<ogra_> zyga, you want a mkdir xenial/dev/pts between line 50 and 51
<ogra_> or better mkdir -p
<zyga> ogra_: maybe you want to send me a patch? you seem to know this better than I do
<ogra_> (the subdir isnt there by default)
 * zyga isn't sure what /dev/pts does really
<zyga> ah
<ogra_> just add: mkdir -p xenial/dev/pts
<ogra_> between these two lines ... thats all
<ogra_> oh
<ogra_> and you probably want to umount xenial/dev/pts before unmounting xenial/dev :P
<zyga> ogra_: oh, man I'm glad I showed you the code :)
<zyga> looking at fixing this
<ogra_> zyga, http://paste.ubuntu.com/16680569/ take that one :)
<ogra_> the umount order matters a bit :)
<ogra_> (proc should be last since it has /proc/mounts)
<zyga> ogra_: trying
<zyga> ogra_: yeah
<ogra_> awesome
<zyga> ogra_: I also improved earlier bits to make more sense
<zyga> ogra_: tested on aarch64 and armhf
<zyga> I wonder if this could be snap install classic :)
<ogra_> i'm runing it in a 6 weeks old pi3 install :)
<ogra_> well, mvo wants to ship the delta of the os inside the snap
<zyga> ogra_: aarch64 chroot on pi3?
<ogra_> nah armhf
<zyga> ogra_: ah, I remember that
<zyga> ogra_: yeah, small download
<ogra_> to save the downloading
<ogra_> no download at all
<mvo> zyga: we had this (we still have it in the store, its just unpublished)
<mvo> zyga: a snap that includes this script (well, not this script, a similar one :)
<ogra_> we just ship a tar,xz somewhere inside the rootfs ...
<mvo> zyga: but the current agreement on this is to have the delta and generate classic from that
<ogra_> i'm fiddling with the build scripts currently to make that work by friday ...
<zyga> mvo: I see, thanks for clarifying that
<zyga> ogra_: well the snap would still contain the delta, right?
<mvo> zyga: the dellta is part of the OS snap itself
<zyga> actually it might be useful to say ./classic --precise :)
<zyga> aaah
<zyga> so all pre-shipped
<zyga> Thanks
<mvo> zyga: yeah
<zyga> anyway, devtools are not end-user tools, they are for hackers to hack :)
<mvo> zyga: having a different approach is actually nice, we could still have this as a normal snap
<zyga> so I look forward to proper classic
<mvo> zyga: like zygas-classic or something
<ogra_> right, we'll just ship the delta as compressed tarall in ... say /usr/lib/snapd/classic
<mvo> zyga: i.e. feel free to just snap it and put it into the store
<mvo> ogra_: \o/
<ogra_> and if you enable classic it unpacks it
<mvo> ogra_: plus something like removed_files (if we need that) - not sure if we have files we create in the livecd-rootfs and that we need to remove when building classic
<ogra_> mvo, though hwo do you plan to run that ?
<ogra_> that will be a ton of additional bindmounts, no ?
<ogra_> to create a proper chroot dir
<zyga> kgunn: hey, I wanted to ask about mir
<jdstrand> roadmr: fyi if you're more comfortable with pushing r667 as a revision, feel free to pull that (it is not at all time-sensitive so feel free to skip if you've already pushed r666)
<zyga> kgunn: I made some improvements to tooling, you should be able to run ./run-devel-vm --visual now to test your mir snap
<zyga> kgunn: (and mir interface)
<roadmr> jdstrand: I have but it's not deployed yet, I can somewhat easily update to 667.
<roadmr> jdstrand: (we've been having some molasses issues in the pipeline - working on it!)
<kgunn> zyga: awesome! i will give it a try
<jdstrand> roadmr: ack, thanks :)
<mvo> ogra_: how do you mean? how do I plan to "run that"? create classic from the delta? remove the extra files? not sure I follow
<mvo> ogra_: my plan is to actually unpack the squashfs not take the running image
<ogra_> mvo, well, we will have a tarball that has the missing files ...
<mvo> ogra_: because the running image is full of bind mounts that are confusing
<ogra_> ah, so you unsquash and then untar on top oif that ?
<mvo> ogra_: yeah and maybe (if we need to) apply something like removed_files
<mvo> ogra_: i.e. remove stuff we create in the squashfs but don't actually want on classic classic
<mvo> ogra_: does this sound sensible? or am I overlooking something?
<ogra_> no, sounds fine
<ogra_> i was just ont understanding the approach to get a chroot dir
<ogra_> didnt think about unpacking :)
<mvo> ogra_: great, thanks for double checking!
<noizer> sergiusens: Hi I tried now with bin/snapcraft (download from github) and go the error no module named yaml. but I installed pyyaml already what now?
<kyrofa> noizer, you need the python3-yaml package
<qengho> noizer: did you get the rest of the snapcraft files? I think one of them is called "yaml.py", e.g.
<kyrofa> noizer, did you install build-deps as I suggested?
<kyrofa> noizer, or you can just look in the debian/control file and you'll see a list of dependencies
<kyrofa> noizer, by the way, I didn't ask: why are you wanting to run from source?
<noizer> kyrofa: I made a new image of xenial xerus for my rpi 2  and made a chroot with zyga his script and when i'm trying to install snapcraft with apt-get it won't work
<noizer> kyrofa: so I tought maybe from source
<kyrofa> noizer, can you define "won't work" ?
<noizer> kyrofa: when I did apt-get install snapcraft. he won't find the snapcraft package
<kyrofa> noizer, did you run `apt-get update` first?
<noizer> kyrofa: yes i will do it again
<kyrofa> noizer, make sure you have universe enabled
<noizer> kyrofa: OK and how will i do that
<noizer> kyrofa: sudo add-apt-repository universe
<kyrofa> noizer, pastebin your /etc/apt/sources.list
<noizer> tried this but he won't find the add-apt-repository command
<noizer> kyrofa: http://paste.ubuntu.com/16683077/
<kyrofa> noizer, uncomment lines 17-20
<kyrofa> noizer, run `apt update` again and then try `apt install snapcraft` again
<beowulf> kyrofa: hi! in relation to node-engine pr, would you know what's causing this? https://pastebin.canonical.com/157244/
<plars> elopio: fgimenez: have anything to discuss today? or are you too busy?
<kyrofa> beowulf, well that's not a helpful error. Try running snapcraft -d snap
<kyrofa> Does it give you any more information?
<fgimenez> plars, nothing from my side, elopio?
<beowulf> kyrofa: oh, that's more helpful, thanks
<kyrofa> beowulf, yeah I don't see anything obviously wrong with the yaml
<beowulf> kyrofa: oops, found it https://github.com/earnubs/snapcraft/commit/c21679fe34fee068fedf8c80d8488ad518b4905e
<kyrofa> beowulf, ahh, ah ha. Note you could just use `extend` there if you like having them both
<noizer> kyrofa: that worked for now but got an other error when I'm trying to use snapcraft http://paste.ubuntu.com/16683077/
<noizer> ow wrong pastebin
<noizer> kyrofa: http://paste.ubuntu.com/16684897/
<kyrofa> noizer, snapcraft 2.9 hasn't made it to release yet, which means you're still running out of source (at least partially)
<kyrofa> noizer, not sure exactly what happened there, so I'm not sure how to fix it I'm afraid
<noizer> kyrofa: ok dammed
<kyrofa> noizer, might be easiest to toast the chroot and try again
<jdstrand> sergiusens: hey, so I saw you take a bug from zyga recently and thought I'd offer up bug #1577514. zyga has a poc for an ld preload lib that I think could just fit in snapcraft (at least, I think that is what zyga was envisioning-- he could give more details)
<ubottu> bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514
<jdstrand> sergiusens: see comment #2 and #3 in particular
<jdstrand> sergiusens: note, I'm only offering that info as 'fyi'
<zyga> ogra_: hey
<zyga> ogra_: I need to hug you
<zyga> ogra_: before I do what I need to do :)
<wililupy> Hello zyga.
<ogra_> zyga, that bad ?
<ogra_> zyga, lol ... just saw my bugmail ... its all fine
<qengho> When is next snapd landing? Ideas?
<zyga> ogra_: yes
<zyga> ogra_: :)
<zyga> ogra_: great, any help you can render is appreciated
<zyga> ogra_: I'm not super faimilar with how this works
<elopio> kyrofa: http://paste.ubuntu.com/16694248/
<kyrofa> elopio, that's typically what I see when I forget to specify --target-arch
<kyrofa> (or it's an arch that isn't supported)
<kyrofa> elopio, that's what you should see when you specify armhf, but arm64 should work
<elopio> kyrofa: oh wait, that might be the output I got after running amd64
<kyrofa> elopio, ah, yeah that would be expected
<elopio> I tried many commands :)  Let me rerun it.
<kyrofa> Hahaha
<elopio> kyrofa: http://paste.ubuntu.com/16694497/
<kyrofa> elopio, hmm, we may be missing a build-package there
<kyrofa> libopenssl-dev maybe
<kyrofa> elopio, libssl-dev rather
<kyrofa> elopio, new bug though
<elopio> let me try that
<kyrofa> elopio, dinner time here, ping me on telegram if you hit more issues there
<elopio> kyrofa: it's building, but it will take a long time in this vm. I think we are done here, enjoy the night.
#snappy 2016-05-26
<shuduo> morning, i'm trying to stitch a customized image with my own kenrel snap. i modified 96boards-kernel of snapcraft-examples then i use latest u-d-f and specify --kernel=./96boards-kernel.snap. Now u-d-f reports "Installing ./96boards-kernel.snap
<shuduo> failed to install "./96boards-kernel.snap" from "edge": ./96boards-kernel.snap failed to install: invalid snap name: "96boards-kernel"
<shuduo> anything wrong?
<shuduo> ogra_, zyga : ^^
<zyga> shuduo: cannot start with digits
<zyga> shuduo: kernel-96boards
<zyga> shuduo: try that instead
<zyga> shuduo: :-)
 * zyga is off today, going to the airport soon
<zyga> shuduo: if the name bugs you please report a bug on snappy, we could perhaps lift the restriction, no promises though
<morphis> zyga: ping
<zyga> hey hey
<zyga> how are you morphis
<morphis> zyga: fine :-)
<shuduo> zyga: thanks. will try it. so snapcraft-examples/examples/96boards-kernel should going to change acccordingly, right?
<morphis> and you?
<morphis> getting forward with ubuntu-image?
<zyga> shuduo: hmmmm, if it worked before then I'm puzzled
<zyga> morphis: yep, slowly, I was still working on other tasks, I talked to slangasek and barry last night
<zyga> morphis: gave them my shell prototype, I will try to make it less of a prototype now (less magic blobs, more things that can be built)
<zyga> morphis: 09:22 < zyga> morphis: yep, slowly, I was still working on other tasks, I talked to slangasek and barry last night
 * zyga wonder how that got pasted...
<morphis> :-)
<morphis> zyga: you remember what we said about i2c interface in the meeting about interfaces for RTM?
<zyga> yes
<zyga> do you have a patch for that? :-)
<morphis> zyga: not yet, but someone who needs it for a sensor snap on the pi
<morphis> zyga: we dropped it from the list, right?
<pmp> morphis: sorry for the instrusion: "sensor snap on the pi" .. via iio?
<pmp> morphis: hi - first of all
<morphis> pmp: hey! :-)
<morphis> lpotter is working on that
<zyga> morphis: yes we did
<morphis> not sure what it actually uses to talk with the hardware I just go i2c from lpotter so far :-)
<morphis> pmp: you're working on something similar?
<pmp> morphis: I will need to make a snap which will access sensors via iio - at one point in time
<morphis> zyga: from what I saw so far the way would be to just put a generic i2c interface into snapd allowing access to /dev/i2c*
<pmp> morphis: prototyping on the pi and then make it work on the real target
<morphis> pmp: afaik lpotter as a working prototype already which runs mostly fine in devmode
<pmp> morphis: hmm, not sure what you mean, I'm not using RTM (don't even know what it is, related to ROS?), I just have a simple user-app which will access sensors via IIO
<morphis> pmp: RTM is just a version of snap* stuff
<zyga> morphis: https://github.com/snapcore/snapd/pull/1231
<zyga> morphis: just wrote one quickly, didn't test it
<morphis> pmp: the snap lpotter is working on is exactly doing this but will be an example of how you can do such things on a device
<zyga> morphis: no, I'd imagine a specific interface instance for each controller
<zyga> morphis: and all controllers would be described by the gadget snap
 * zyga -> afk (15 min)
<morphis> zyga: I see
<zyga> morphis: we could have a i2c-control (global) and i2c (per controller device node)
<zyga> morphis: and later on we could grow a slot level attribute that says if the controller actually speaks smbus or i2c or whatnot
<zyga> morphis: but this should be good as a starting point
<zyga> afk for real
<shuduo> zyga: ping
<shuduo> zyga: seems digital name issue is gone after name changed. now new error msg is "failed to install kernel can not extract kernel assets: cannot determine bootloader"
<shuduo> zyga_: seems digital name issue is gone after name changed. now new error msg is "failed to install kernel can not extract kernel assets: cannot determine bootloader"
<pmp> morphis: how to not lose track of the changes made by lpotter? (I'm not working on snappy everyday) Do you have a link?
<morphis> pmp: not yet, need to wait for lpotter to be back
<pmp> lpotter == Lorn Potter?
 * zyga -> away
<zyga> see you in the evening
<flexiondotorg> I'm trying to create a source build snap package of Pluma.
<flexiondotorg> I need to pass some configure options to autotools.
<flexiondotorg> The documentation says I should ConfigFlags: but that snapcraft throws an error when I use that.
<flexiondotorg> Issue while loading plugin: properties failed to load for pluma: Additional properties are not allowed ('configFlags' was unexpected)
<flexiondotorg> Documentation is wrong, the snapcraft source shows it should be configflags:
<sergiusens> flexiondotorg mind logging a bug or a quick PR to fix that?
<flexiondotorg> sergiusens, What is the source repo for the documentation? I'll submit a PR
<sergiusens> flexiondotorg in most cases just https://github.com/ubuntu-core/snapcraft
<flexiondotorg> sergiusens, Thanks.
<sergiusens> flexiondotorg the sources have a docstring (which is used for `snapcraft help <plugin-name>`
<sergiusens> flexiondotorg and if you saw it on the website, look at the docs dir
<flexiondotorg> sergiusens, Here's your PR :-) https://github.com/ubuntu-core/snapcraft/pull/521
<sergiusens> flexiondotorg thank you!
<flexiondotorg> sergiusens, You're welcome.
<kyrofa> sergiusens, I'm babysitting didrock's branches while he's off, so let me know if something needs to be changed and I'll repropose
<sergiusens> kyrofa oh, he's off? Well, there is one thing in 506 then
<kyrofa> sergiusens, the package is still called snapcraft-examples... what transition are you referring to?
<sergiusens> kyrofa arf, my mind was thinking everything was getting renamed :-P
<kyrofa> sergiusens, heh-- yeah seems he was pretty careful about breakage
<kyrofa> sergiusens, he even left the examples tests, but redirected them to demos
<sergiusens> kyrofa yeah, I saw that part
<sergiusens> kyrofa I'll build a deb from this and see how it goes
<kyrofa> sergiusens, ah, yeah that's probably a good call
<sergiusens> kyrofa any idea why this diff looks weird https://github.com/ubuntu-core/snapcraft/pull/509/files ?
<kyrofa> sergiusens, it needs a real rebase I'm afraid. Looks like he merged with master right before I fixed that bad commit
<kyrofa> That's what it looks like anyway
<josepht> reviewers: could some give my pi2 nmap snap a quick review (needs network-control for running with sudo) https://myapps.developer.ubuntu.com/dev/click-apps/4710/rev/27/
<josepht> *someone
<sergiusens> kyrofa check 506 again ;-)
<davidcalle> jdstrand: I've left a comment on the sec doc, p31
<kyrofa> sergiusens, on it
<sergiusens> jdstrand about taking over, does that really fall into snapcraft? I would think the launcher would be the right project
<sergiusens> kyrofa one more comment added
<jdstrand> sergiusens: I'm not sure what zyga had in mind. I'll let you two battle it out
<kyrofa> sergiusens, interesting... in debian/rules he has dh_compress -Xusr/share/doc/snapcraft-examples/demos . You're saying that directory isn't actually valid?
<sergiusens> kyrofa it is valid, but debian/snapcraft-examples.examples magles; build and see
<sergiusens> kyrofa build, install and see
<kyrofa> sergiusens, do you want them in /usr/share/doc/snapcraft-examples/demos instead of examples?
<kyrofa> sergiusens, yeah I see that they're in the same spot as they used to be
<sergiusens> kyrofa yeah, and the documentation gets weird, because if you git clone you cd into demos if you apt install you cd into examples
<sergiusens> kyrofa maybe we should just kill the examples/demos as a package; do you know if that was the idea?
<sergiusens> and then move to providing the real "examples"
<sergiusens> and tell everyone to grab the demos from the demos page
<elopio> sergiusens, kyrofa: https://github.com/ubuntu-core/snapcraft/pull/511 all green. Do you like it?
<kyrofa> sergiusens, the goal of his work is to just have that `snapcraft-examples` command that generates the basic examples. But that command actually needs to be shipped in snapcraft, not snapcraft-examples
<kyrofa> So this branch's purpose was really to just make room for the "examples" that will be copied into cwd by that command
<sergiusens> elopio I am reading that code now
<sergiusens> kyrofa yeah, but if you "copy" you will also copy the "demos"
<kyrofa> I don't think his goal was/is to kill the snapcraft-examples package. Though it might get a little confusing if the command mark wants is "snapcraft-examples"
<sergiusens> kyrofa my suggestion is to change debian/snapcraft-examples.examples to debian/snapcraft-examples.install and tell it to install demos/* to /usr/share/doc/snapcraft-examples/demos
<sergiusens> kyrofa do you feel up to that?
<kyrofa> sergiusens, yeah, easy
<Dinkz> Hello !
<Dinkz> I was trying to install snappy into my Raspberry Pi-2
<Dinkz> and got it installed.
<Dinkz> NOw, I want to install adb into it.
<kyrofa> sergiusens, have you seen this by the way? It might answer some questions: https://github.com/ubuntu-core/snapcraft/pull/513
<kyrofa> I've not actually reviewed it yet
<sergiusens> kyrofa or when is didrocks back? We can land this as is, but needs to have some resolution next week
<kyrofa> sergiusens, monday I believe
<elopio> Dinkz: hello
<Dinkz> Hello Elopio
<kyrofa> sergiusens, up to you. I've fixed the ros example test already, happy to fix the deb issue as well, and I can remake the PR
<elopio> Dinkz: you would have to make a snap package for adb. We don't have it yet. And there's also the concept of "classic dimension", that will come back soon.
<Dinkz> Thank you very much, Elopio ! What is classic dimension ?
<sergiusens> elopio looks good, just added a minor TODO comment
<kyrofa> elopio, chroots can be used for now, for what it's worth
<elopio> Dinkz: it's like a container that will let you run "apt install adb"
<sergiusens> kyrofa let me look at the follow up PR
<elopio> sergiusens: I'll report a bug for the missing test.
<Dinkz> Thanks a lot Elopio !
<sergiusens> kyrofa ok I saw it, execute as agreed upon but...
<sergiusens> kyrofa look at https://github.com/ubuntu-core/snapcraft/pull/513/commits/f57d1203dfa1dc136338a99b9dcdf7bc9fa3300c
<sergiusens> kyrofa I always disliked the fact our examples landed in docs, maybe make the rule install in /usr/share/snapcraft/demos
<kyrofa> sergiusens, indeed, they need to be in snapcraft itself (not the demos though)
<kyrofa> Okay, can do
<sergiusens> kyrofa I'll approved elopio's PR, looks like a dream, maybe rebase in a bit too ;-)
<kyrofa> sergiusens, heh, sounds good
<elopio> fgimenez: https://plus.google.com/hangouts/_/canonical.com/qa I miss you
<elopio> sergiusens: hum, one thing about the TODO. My idea is that devs run against the fake in their machines, but jenkins runs against staging in PRs. The jenkins run will hit the status page more than once, for sure.
<elopio> do you still want a test on the fake that hits the status more than one
<elopio> *once
<sergiusens> elopio ok, I am just thinking about unit test coverage :-P
<sergiusens> kyrofa I am divided :-/
<sergiusens> kyrofa don't change yet
<sergiusens> just push the fix for the lone ros wolf
<kyrofa> sergiusens, haha, I was just about to push!
<kyrofa> sergiusens, alright will do
<sergiusens> kyrofa I will solve this with didrocks when he gets back
<kyrofa> sergiusens, alright: https://github.com/ubuntu-core/snapcraft/pull/522
<elopio> sergiusens: this branch doesn't deal with unit test coverage yet. We'll get there in the others.
<elopio> fgimenez: all check conflicts solved.
<fgimenez> elopio, great dropping a comment in the next one..
<kyrofa> sergiusens, I think https://github.com/ubuntu-core/snapcraft/pull/509 is ready to go, and should probably land before the examples so he doesn't need to update again
<kyrofa> (assuming you want it in 2.10 of course)
<sergiusens> kyrofa yeah, too bad I didn't notice the missing bug for this though
<sergiusens> kyrofa we should create one and add it into the "merge and squash" comment
<kyrofa> sergiusens, argh, I missed it as well. We can
<kyrofa> Yeah exactly
<kyrofa> I was about to say just that
<sergiusens> kyrofa if you want to, go ahead, if not I'll do it in a bit
 * sergiusens is working through some lunch
 * elopio afk, swimming lessons.
<balloons> sergiusens, apparently we need to migrate shoutirc to lounge; https://github.com/thelounge/lounge
<sergiusens> balloons we don't need to, it is a nice alternative to snap
<sergiusens> balloons lounge is a free for all shout fork. It also means it could be buggier ;-)
<sergiusens> and or lack a clear roadmap. Feel free to get it snapped though!
<balloons> sergiusens, yea, indeed. But I'm migrating over since it solves all the longstanding bugs and has all the contributors minus the original author :-)
<balloons> So I would like a snap.. It will more or less be a clone of yours, so that's fun
<balloons> *fine
<sergiusens> balloons what bugs, the offline one?
<balloons> yea, I just hit it again today. Super annoying
<sergiusens> balloons I was going to look into it, but I just have no time :-P
<sergiusens> balloons I haven't hit it ever, yet
 * sergiusens crosses fingers now
<balloons> LOL
<balloons> it's silent, but deadly. It's been a good long while since it happened to me
<sergiusens> kyrofa so now the ros demo fails http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/746/console
<sergiusens> balloons ok, might get to it during the weekend ;-)
<mhall119> hey everyone, how do I connect a snap's "home" plug ?
<mhall119> bah, nevermind, I had my arguments backwards
<kyrofa> mhall119, some of those bits were covered here by the way: http://summit.ubuntu.com/uos-1605/meeting/22682/anatomy-of-a-snap/
<mhall119> thanks kyrofa
<mhall119> ok, I've got two KDE apps now that both throw the same udev apparmor complaint when running in --devmode
<kyrofa> mhall119, can I see the pastebin?
<mhall119> kyrofa: http://paste.ubuntu.com/16713644/ first line specifically
<tyhicks> mhall119: the important part is apparmor="ALLOWED"
<mhall119> kyrofa: FWIW, an upstream KDE developer tries building and running the kcalc snap, but he doesn't get the udev access error
<tyhicks> mhall119: that message is telling you that AppArmor would have blocked the action if you weren't running in devmode
<jdstrand> mhall119: add the 'opengl' interface
<mhall119> tyhicks: right
<jdstrand> I'm guessing the person seeing that access is using an nvidia system
<tyhicks> mhall119: sorry, thought you were thinking that AppArmor was blocking something
<mhall119> but why is krita or kcalc (or any KDE app I assume now) accessing udev anyway? And why isn't the upstream dev seeing it
<mhall119> tyhicks: it works in --devmode, but dies on launch otherwise with "Bad system call"
<jdstrand> mhall119: ^
<kyrofa> mhall119, different hardware I'd assume
<mhall119> if I can get rid of that, I think these might run without --devmode
<mhall119> jdstrand: all intel
<jdstrand> mhall119: you have all intel?
<mhall119> I'm all intel and see the rror
<jdstrand> hmm
<mhall119> the upstream, I don't know
<jdstrand> perhaps the intel drivers also trigger it
<kyrofa> mhall119, what is the syscall that causes it to barf?
<jdstrand> mhall119: add the opengl interface
<mhall119> kyrofa: no idea, and I don't know how to find out
<mhall119> jdstrand: already have it
<kyrofa> jdstrand, snappy-debug is back... right?
<jdstrand> it is
<mhall119> jdstrand: plugs: [X11, unity7, home, opengl, network
<kyrofa> mhall119, are you familiar with snappy-debug?
<mhall119> nope, tell me more :)
<jdstrand> that should be x11
<kyrofa> mhall119, oh, it will become your best friend
<kyrofa> mhall119, snap install snappy-debug
<mhall119> are there docs on how to use it on developer.ubuntu.com? (if not, hint hint)
<kyrofa> mhall119, not that I know of-- snappy-debug was pulled for a while so we removed docs so as to not confuse people
<kyrofa> mhall119, we'll get it back in there
<mhall119> ok, snappy-debug installed
<jdstrand> opengl gave a different access
<jdstrand> we don't currently allow /run/udev/data/**
<kyrofa> mhall119, now run `sudo snappy-debug.security scanlog` in one terminal and exercise the snap in the other
<kyrofa> When it dies due to seccomp, snappy-debug's output should help
 * jdstrand notes that snappy-debug doesn't yet handle dbus denials
<jdstrand> but it'll of course handle seccomp just fine
<kyrofa> jdstrand, good to know, thank you
<jdstrand> I also suspect that the /run/udev access is noise
<mhall119> heh, snappy-debug is giving apparmor notifications now
<kyrofa> mhall119, indeed, it does that too
<kyrofa> mhall119, like I said: best friend
<jdstrand> mhall119: if it is working in devmode, I suggest filing a bug against snapd with the snapd-interface tag
<kyrofa> thank jdstrand
<mhall119> kyrofa: you didn't tell me to connect stuff :-P
<kyrofa> mhall119, eh?
<mhall119> sudo snap connect snappy-debug:log-observe ubuntu-core:log-observe
<kyrofa> mhall119, haha, ah sorry!
<kyrofa> mhall119, I've not actually used it in snappy 16
<jdstrand> he didn't have too-- snappy-debug told you to :)
<mhall119> jdstrand: this is true, and quite helpful
<mhall119> kyrofa: output from snappy-debug scanlog: http://paste.ubuntu.com/16713961/
<mhall119> kyrofa: was I supposed to install snappy-debug with --devmode?
<jdstrand> no
<kyrofa> mhall119, did you try sudo?
<jdstrand> it works fine without --devmode
<mhall119> kyrofa: mhall@mhall-thinkpad:~/projects/Ubuntu/snaps$ sudo /snap/bin/snappy-debug.security scanlog 2>&1 | pastebinit
<mhall119> ^^ is what I ran
<kyrofa> mhall119, congratulations, you're surpassed my snappy-debug knowledge :P
 * mhall119 doesn't *feel* like a winner
<kyrofa> jdstrand should know more though
<jdstrand> there is a bug
<jdstrand> I'll fix it now
<jdstrand> mhall119: can you email me your syslog?
<jdstrand> mhall119: feel free to truncate it to today
<jdstrand> mhall119: grep audit /var/log/syslog > /tmp/audits
<jdstrand> gzip /tmp/audits
<jdstrand> send me /tmp/audits.gz
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/522 is green
<jdstrand> mhall119: are you sending me that?
<mhall119> jdstrand: sorry, was distracted by shiny new gadgets in the mail, working on the log now
<sergiusens> kyrofa commented
<sergiusens> kyrofa but yeah, +1 ;-)
<mhall119> jdstrand: send, it wasn't very big so I didn't gzip it
<jdstrand> thanks
<jdstrand> mhall119: ok, can you do 'grep 1326 /var/log/syslog'
<jdstrand> mhall119: I'll show you how to figure out the seccomp denial yourself
<mhall119> that sounds like work :)
<jdstrand> well, you can give me a sec
<jdstrand> mhall119: is your system amd64? i386?
<kyrofa> sergiusens, man, I've been slacking on actually looking at commits for bugs lately. You and elopio have been spoiling me
<mhall119> i386 (don't laugh)
<jdstrand> mhall119: this is the log entry:
<jdstrand> May 26 13:14:23 mhall-thinkpad kernel: [181943.002409] audit: type=1326 audit(1464286463.789:7470): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=23870 comm="krita" exe="/snap/krita/100003/usr/bin/krita" sig=31 arch=40000003 syscall=102 compat=0 ip=0xb7700c31 code=0x0
<lpotter> pmp: morphis the sensors snap for rpi is not using iio. RTIMULib talks firectly to i2c_x
<jdstrand> mhall119: see where it sayd 'syscall=102'? do 'scmp_sys_resolver 102'
<jdstrand> mhall119: that will give you the syscall (snappy-debug does that for you)
<mhall119> socketcall?
<jdstrand> ah yes, that is bug #1576066
<ubottu> bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066
<mhall119> well, at least it's not a new bug :)
<jdstrand> no, and it has a card, just haven't gotten to it yet
<mhall119> it would also explain why I hit it and the KDE guy didn't, he's likely on amd64
<jdstrand> yep
<kyrofa> sergiusens, would you say this PR and didrock's next one relate to the same issue? In which case maybe the second one should reference it?
<jdstrand> mhall119: you can workaround it by adding 'socketcall' to /var/lib/snapd/seccomp/profiles/snap.your.app
<mhall119> jdstrand: who do I need to ply with alcohol to get it prioritized?
<jdstrand> mhall119: it's high priority, it is just at the point where there are too many high priority things for too few people
<kyrofa> jdstrand, that sounds like snappy in general :P
<mhall119> jdstrand: just add 'socketcall' to the bottom of the profile?
<jdstrand> mhall119: yes
<jdstrand> that's it
<jdstrand> do that, then start the app
<mhall119> do I need to restart or trigger a re-parse or anything?
<jdstrand> nope
<jdstrand> mhall119: with apparmor you do cause there is something to load into the kernel. with seccomp, the launcher does all that for you
<jdstrand> tyhicks: thoughts on the socketcall card? it seems correctly prioritized but people are still hitting it. we could just allow it until the card is complete, but it should also be noted this isn't blocking people using devmode
<tyhicks> jdstrand: is the fix blocked on seccomp arg filtering?
<mhall119> jdstrand: awesome, that did it!
<mhall119> I can now run krita.snap without --devmode
<jdstrand> tyhicks: no
<mhall119> I still get a udev warning, but otherwise it seems to all work
<jdstrand> tyhicks: once we backport seccomp to xenial, i386 systems with >= 4.3 kernels just start working (aiui)
<jdstrand> mhall119: yeah, those udev denials are usually just noise
<mhall119> scary looking noise though
<tyhicks> jdstrand: backport seccomp? you mean seccomp arg filtering?
 * tyhicks is looking at the card now
<jdstrand> tyhicks: in other words, when all the conditions are right (glibc is updated, seccomp is updated, kernel is updated), i386 acts like other archs and doesn't need socketcall
<tyhicks> jdstrand: I thought we decided to take care of this with seccomp arg filtering instead of touching glibc
<jdstrand> tyhicks: no. libseccomp needs some patches for i386 to not need socketcall. that needs to go with glibc changes (already in xenial) and >=4.3 kernels
<jdstrand> we don't need to touch glibc
<jdstrand> it is already touched
<tyhicks> oh
<jdstrand> xenial has that change
<jdstrand> the kernel has the change
<jdstrand> it is just that seccomp needs a change
<jdstrand> granted, I've not proved all that, but that is what people in the bug have said
<jdstrand> cause for me to prove it would be to do the work, which is prioritized under other stuff :)
<sergiusens> kyrofa yeah, I think both should so we know it's the same line of work
<sergiusens> kyrofa same bug for both PRs
<kyrofa> sergiusens, so it's okay to have two changelog entries for the same bug?
<tyhicks> jdstrand: since devmode unblocks people, I think the socketcall fix is still prioritized appropriately
<sergiusens> kyrofa yeah
<kyrofa> sergiusens, sounds good
<jdstrand> tyhicks: aiui, arg filtering could help a little, but then we'd still want this change to differentiate between AF_* types which we can't do with socketcall (one of the reasons for arg filtering)
<jdstrand> tyhicks: ok, that was my thought as well. mhall119 ^
<mhall119> I don't like using --devmode to work around bugs that aren't in the apps themselves, but I understand why other things are higher priority
<tyhicks> jdstrand: you're right - we wouldn't be able to differentiate between different socket types
<jdstrand> mhall119: it isn't deprioritized, it is just prioritized below a few other things. don't worry, we'll get there
<jdstrand> mhall119: I see the issue with snappy-debug. you do need to install it with --devmode for the moment. I'll fix the log-\observe interface
<mhall119> jdstrand: I understand, thanks
<morphis> lpotter: good to know!
<morphis> jdstrand: can you have a look at the modem-manger interface proposal?
<jdstrand> morphis: I have it on my todo, yes
<mhall119> are there any more snappy-clinics scheduled?
<morphis> jdstrand: awesome!
<sergiusens> elopio any idea how this could happen http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/750/console ?
<sergiusens> balloons I think that until recently I was disconnected
<nimoov> Are there 'plugs' that enable access to '/tmp' and/or a custom defined path?
<sergiusens> nimoov /tmp is really private to a snap, you get /tmp in a private mount namespace
<nimoov> Is it possible to get system /tmp?
<kyrofa> nimoov, can you explain what you're trying to accomplish?
<nimoov> I have build LLVM/Clang in snap, and I want to use it in an IDE(CLion). The problem is that the cmake binary, from my LLVM/Clang snap, doesn't have access to the same /tmp as the user. This is needed by CLion to test cmake.
<elopio> sergiusens: to leave the record here, the mosquitto publisher failed to deliver the message to the subscriber. Could be a fluke, because the example has nothing of high-reliability. Or there could be a problem in classic blocking it, I'll take a look to discard this one.
<beowulf> if i wanted a writeable area for a snap, where would i find one? :)
<sergiusens> beowulf $SNAP_USER_DATA and $SNAP_DATA for user and system respectively (the latter being a service)
<beowulf> sergiusens: ta
<jdstrand> mhall119: fyi, https://github.com/snapcore/snapd/pull/1236
<jdstrand> sergiusens: fyi: https://bugs.launchpad.net/snapcraft/+bug/1586162
<ubottu> Launchpad bug 1586162 in Snapcraft "snapcraft truncates trailing 0's from version" [Undecided,New]
<nimoov> q
<jdstrand> beuno: fyi, I'm getting 504s going to https://myapps.developer.ubuntu.com/dev/click-apps/
<sergiusens> jdstrand well, according to yaml syntax that is a number, not a string. It needs " for it to be interpreted as a string
<sergiusens> jdstrand that said, we can ignore yaml parsing and try and force it to string
<beuno> jdstrand, hm
<beuno> noise][, nessita, roadmr, ^
<beuno> (it's looking like I will as well, I guess a timeout?)
<nessita> jdstrand, are you with the canonical share account?
<nessita> beuno, this is a known issue for admins or accounts with too many packages, fix will be done soon, workaround is to visit other URL not /
<nessita> beuno, can you access https://myapps.developer.ubuntu.com/dev/click-apps/search/ ?
<beuno> nessita, so jdstrand has too many packages?
<sergiusens> elopio on retesting I got a spurious error http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/850/testReport/junit/tests/TestSnapcraftExamples/test_demo_godd_/
<jdstrand> nessita: I was just hitting the site. I was logged in with shared, logged out, then was going back to login with personal
<noise][> beuno: there's just a recent and nasty performance bug on the main page
<jdstrand> sergiusens: the joys of yaml. I went to 0.21 to avoid it
<nessita> beuno, the canonical shared account has
<nessita> jdstrand, can you browse / with your personal account?
<jdstrand> nessita: no. I logged out and getting a 504 trying to login
<jdstrand> I don't see anything
<nessita> hum
<jdstrand> it spins then after a while shows the 504 page
<nessita> jdstrand, how many packages do you own?
<jdstrand> (and by 'it', I mean firefox's page load indicator)
<nessita> jdstrand, can you open https://myapps.developer.ubuntu.com/dev/click-apps/53/ ?
<jdstrand> less than 10
<jdstrand> but I'm not logged in
<jdstrand> it shouldn't be thinking about that yet
<nessita> jdstrand, can you browse https://myapps.developer.ubuntu.com/logout/
<jdstrand> I see that
<jdstrand> that was the page I saw after I logged out
<jdstrand> then I went to Sign in or register
<jdstrand> shall I do that now?
<nessita> jdstrand, I'm lost, were you able to login?
<jdstrand> no
<nessita> perhaps you did login but / can not be sown
<jdstrand> hehe
<nessita> shown*
<jdstrand> I *was* logged in from earlier today
<nessita> jdstrand, how do you know you are not logged in? :-D
<jdstrand> I logged out
<jdstrand> then I wen to login
<jdstrand> 504
<nessita> jdstrand, what do you see if you hit https://myapps.developer.ubuntu.com/dev/click-apps/53/ ?
<jdstrand> I went to do signin/register and finally I saw the openid page and am logged in
<jdstrand> weird
<jdstrand> I tried for several minutes
<jdstrand> to answer your specific question, I can see that page (now)
<jdstrand> (permy)
<nessita> jdstrand, so we have a bug for the / (which is really /dev/click-apps/) that we will fix soon, a bad set of queries
<nessita> jdstrand, so I can give you the direct links to your apps
<nessita> to unblock you
<jdstrand> nessita: ok, now when I login with the shared account, I see the issue you are describing
<jdstrand> nessita: can you give me the direct link to snappy-debug?
<jdstrand> nessita: from the shared account?
<nessita> sure
<nessita> jdstrand, https://myapps.developer.ubuntu.com/dev/click-apps/3644/
<jdstrand> thanks!
<nessita> o/
<nessita> jdstrand, sorry for this, will are working on making this better
<jdstrand> no worries-- thanks for working on the issue
<jdstrand> mhall119: fyi, I added something to snappy-debug for socketcall to help make it more discoverable. you still need -devmode for snappy-debug until that PR I pointed you at lands
<sergiusens> kyrofa want to rebase https://github.com/ubuntu-core/snapcraft/pull/513 ?
<mhall119> jdstrand: what do you mean make it more discoverable?
<jdstrand> mhall119: if someone is using snappy debug and they hit socketcall, it points them at the bug
<jdstrand> mhall119: and the bug has a workaround it in
<mhall119> oh, ok
<vejmarie> hi
<vejmarie> not sure to be at the right place, but I am trying to build up a snap using snapcraft on xenial
<vejmarie> and I am stuck with an error from ubuntu-core-launcher
<vejmarie> which doesn't find properly python :(
<vejmarie> my wrapper into the snap works properly
<vejmarie> I am trying to snap FreeCAD a complex piece of code
<vejmarie> does somebody can explain me what ubuntu-core-launcher does ?
<qengho> vejmarie: the launcher sets up the security contexts and closes file descriptors and such.
<vejmarie> yes this is what I am slowly discovering
<vejmarie> FreeCAD is a complex piece of code written in C++, which is wrapping python interpreter and dlopen a huge amount of sharelibs
<vejmarie> currently if I am launching the wrapper generated by hand it works
<vejmarie> if I am launching the snap (which is launching the wrapper through ubuntu-core-launcher) I am having python init issue like if the standard way python discover it's environment doesn't work
#snappy 2016-05-27
<vejmarie> it looks like FreeCAD is opening a socket into /tmp/FreeCAD
<vejmarie> and that when used through the launcher it god an ENOENT when trying to open it
<vejmarie> which is an issue
<sergiusens> vejmarie it is weird that /tmp/FeeCAD opening would block you. Can you run `snappy-debug`? (Install with `snap install snappy-debug`)
<vejmarie> I will try
<vejmarie> just re-assembling my snap currently (it is a big one about 300MB)
<sergiusens> elopio sorry to bother, but that PR https://github.com/ubuntu-core/snapcraft/pull/518 could use some (update me clicking) ;-)
<vejmarie> I also have an issue for an unknown reason my snap do not want to connect to :home
<vejmarie> it does have the plug defined
<vejmarie> and connect to unity7
<vejmarie> ok I found the solution for that
<vejmarie> now, new issue. FreeCAD is storing parameters in ~/.FreeCAD
<vejmarie> I am connected to ubuntu-core:home, but no ways to have free cad creating the directory into ~
<vejmarie> any ideas ?
<zyga> o/
<zyga> ogra_: hey
<brunch875> Hello! Could someone point to me on why sandboxing applications inside snaps? Wouldn't linux group+read permissions be ideal for this?
 * brunch875 returned from crashing IRC client
<ogra_> how would you do that ? one user/group per package ?
<brunch875> that's more or less what I have in mind
<ogra_> that would likely result in an unmanageable bit set of groups in the end
<ogra_> also what do you do with system services that need root access ?
<ogra_> (note that currently all snappy services run as root by default, the confinement happens on a way lower level)
<ogra_> (read: even root processes are restricted in what they can execute or what they can access)
<ogra_> using a groups based system would mean that you need to patch the software to actually operate under such a user and the like
<brunch875> That makes a lot of sense. Could this new permission system be used to replace the current user/group system?
<ogra_> well, you still want userss to run user specific stuff, to store user specific config etc
<ogra_> they are accompanying each other
<ogra_> it depends on the context ... on a headless IoT system that you manage via a web UI you can definitely get along without having a user
<brunch875> would it make sense to ship a text editor like vim as a snap package?
<ogra_> on a multi user desktop you definitely still want them (same on a server)
<brunch875> will apt get eventually deprecated?
<ogra_> kind of ... we dont have all interfaces in place yet (i.e. content sharing) ... so you would have to install the snap in --devmode
<ogra_> to have enough system access to read and write everywhere (which you want with en editor)
<ogra_> no
<ogra_> apt-get wont be deprecated
<ogra_> and the classic ubuntu wont go away
<ogra_> snappy is built from debs :)
<brunch875> what I meant by that is if new programs will be all preferred to use snappy
<daker> hey ogra_ do we have a new rpi image yet ?
<ogra_> thats really up to the maintainers ... canonical will definitely focus on snaps over other stuff when it comes to applications (i.e. you might be able to get the latest version of an app for your desktop installl rather via a snap than via a PPA)
<ogra_> daker, nope ... build one yourself is the suggestion ... as always :)
<ogra_> (within the next two-three weeks we should have something in alpha/betat status though)
<ogra_> -t
<daker> if i build one myself it will contain this fix bug 1577393 ?
<ubottu> bug 1577393 in linux-raspi2 (Ubuntu) "Linux-raspi2 is missing several driver modules when compared against generic" [Undecided,Fix released] https://launchpad.net/bugs/1577393
<ogra_> daker, if you use the kernel snap from cdimage ... i'm not sure the change was uploaded to the store yet
<daker> ogra_: ok
<willcooke> Can I tell snapcraft to pull a specific branch from a github repo?
<willcooke> I have a build dep on a particular version of a library in git, master is too new
<svij> willcooke: source-tag or source-branch should do it
<willcooke> svij, ah ha! Perfect, thanks
<willcooke> had to use source-branch because I /think/ source-tag is actually trying to do source-branch
<zyga> morphis: hey
<zyga> morphis: was the i2c example I've sent of any use?
<morphis> zyga: hey!
<morphis> zyga: not yet, and it would be lpotter who will use it
<morphis> zyga: you had time to look into the modem-manager interface already?
<sergiusens> morning
<morphis> sergiusens: morning!
<sergiusens> kyrofa are you around?
<kyrofa> sergiusens, I am, I'll get that branch fixed up
<zyga> morphis: no, I promise to do it today
<sergiusens> kyrofa oh, right :-P
<morphis> zyga: sounds good!
<zyga> morphis: if I slack please ping me because I just forgot that m-m needed revieweing
<morphis> abeato: ^^
<morphis> ok
<morphis> zyga: it has some interesting things in it we need to cover
<abeato> ack
<kyrofa> sergiusens, haha, I thought that was what you were going to ask, no? :P
<morphis> zyga: btw. how far is the auto-connect-from-gadget-snap story?
<sergiusens> kyrofa btw, this landed https://github.com/ubuntu-core/snapcraft/pull/523 but now that I see, I think I only had verbal consent from elopio so I would like for you tot ake a look
<zyga> morphis: not touched, nobody is exploring that
<morphis> zyga: meant to be done for RTM?
<abeato> zyga, that would be interesting for the nm-mm connection
<jdstrand> ev: hi! there are a number of ev-gadget snaps in the store. do you need any approved?
<morphis> abeato: yes, but for all other plug/slot connection we have to establish for our snaps too
<kyrofa> sergiusens, will do, after standup here in a few minutes
<zyga> abeato: yes, and many other cases
<abeato> ineed
<abeato> indeed
<ev> jdstrand: you can reject all. It's causing an oops when I try to delete them
<zyga> abeato: can you please draft a message to snapcraft@ and we can take it from there
<jdstrand> ev: ack, thanks :)
<zyga> jdstrand: hey!
<abeato> zyga, sure, I'll do
<jdstrand> zyga: hi!
<jdstrand> niemeyer4: what's your opinion on if the 'home' interface should be auto-approved in the store?
<jdstrand> jamiebennett, niemeyer4: hi! mvo uploaded an os snap with the name 'base'. should it be approved or rejected? (not sure where we stand on the naming of things-- I thought I read 'base' was rejected
<ogra_> jdstrand, throw it away
<ogra_> jdstrand, we'll do a proper "core" snap on monday
<jdstrand> ack, thanks!
<jdstrand> jamiebennett, niemeyer4: nm re os snap
<jamiebennett> :)
<beowulf> what's the process for snaps that set interfaces like 'system-reserve'? the CRT error in the store is: "reserved cap 'system-observe' for vetted applications only security-snap-v2_app_plug_safe (vtop, system-observe)"
<beowulf> s/reserve/observe
<beowulf> in https://myapps.developer.ubuntu.com/dev/click-apps/5100/rev/1/
<morphis> abeato: btw. the second part "due to apparmor denials when trying to register for
<morphis> tracking DBus name for partner before connection is established" can't we do that better in network-manager and use a dbus name watch?
<abeato> morphis, that is what fails
<abeato> trying to register for the wathc
<morphis> oh really?
<abeato> yep
<morphis> apparmor denial?
<abeato> yep
<jdstrand> beowulf: can you elaborate on "what's the process for"?
<jdstrand> beowulf: you mean the review process?
<jdstrand> beowulf: or something else?
<beowulf> jdstrand: so it's just the normal review process?
<morphis> abeato: we should extend the permanent slot then for the network-manager interface to allow that
<morphis> as network-manager should be allowed to listen for modem-manager even without the plug being connected
<beowulf> jdstrand: https://developer.ubuntu.com/en/snappy/guides/interfaces/ made me think it might be more involved
<abeato> sure, that can be done
<morphis> abeato: can you add that to your m-m interface PR?
<jdstrand> beowulf: it's the normal review process. it will be flagged for manual review atm, but then a reviewer will look at it
<jdstrand> this stuff is still being worked through though with store changes and assertions changes coming
<abeato> morphis, better in another PR
<jdstrand> and trying to understand how autoconnect and manual connect fit into store auto-approvals
<morphis> abeato: then lets push another one on top
<beowulf> jdstrand: right  ... i was wondering if ideally in the store UI that should be less of "there was a problem!" and more "package is fine, we just need to be sure about X" ... "manual review state" is treated like a failure, which it isn't really?
<jdstrand> morphis: oh, if you are pushing another nm change... I started looking at the ConnectedSlot changes for it to bring it in line with what we were doing with location service
<morphis> jdstrand: we need to add a bit to allow dbus name watches to allow interconnections between n-m and modem-manager
<jdstrand> beowulf: it is a failure in auto-approval. I think we need to understand where we are going before we change the ui though
<beowulf> jdstrand: absolutely, just thinking out loud
<jdstrand> morphis: I wonder if you would want to take: https://github.com/jdstrand/snapd/tree/nm-fixes (totally untested) as part of that work?
<jdstrand> well, it is 'run-tests' tested
<jdstrand> morphis: if not, I can keep plugging away at it. at some point I would need one of you to run it through your test plan though (unless you have a test plan I step through that you can point me at)
<morphis> jdstrand: sounds good, abeato can you include those changes?
<jdstrand> ok, cool
<abeato> morphis, will do later
<sergiusens> kyrofa one more https://github.com/ubuntu-core/snapcraft/pull/524
<mhall119> hi all, what's the best way to specify an icon in a .desktop file to make sure it will find the proper image in the app's install directory
<morphis> abeato: thanks
<kyrofa> mhall119, I remember zyga talking about that... I don't remember where though (maybe a blog post) so he'll probably be able to help
<sergiusens> mhall119 something like this https://github.com/sergiusens/vscode/tree/release/1.0.0/setup/gui
<mhall119> thanks sergiusens
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: So, home interface..
<niemeyer> jdstrand: Tricky one
<niemeyer> jdstrand: I don't think we should stop auto-connecting it until we have a better experience for connecting it in the first place
<niemeyer> jdstrand: But that's an initial gut feeling.. we can explore options
<jdstrand> niemeyer: I agree with that. I wonder about auto-approving in the store then. there is some overlap with manual reviews and auto-connecting, but it isn't at all clear to me. I know things will get clearer with the assertions work, but perhaps 'home' should be autoapproved but manually connected, but say network-manager is both manual approve and manual connected. it's a little weird atm with the transition
<jdstrand> davidcalle: thanks for the whitepaper updates. does the process we came up with work for you?
<davidcalle> jdstrand: yes, works for me :)
<jdstrand> great
<jdstrand> seems lightweight and flexible :)
<davidcalle> jdstrand: indeed, I'm running an importer that does 90% of the work, the I diff the text with what's published and apply (quicker than publishing the new import and doing the remaining 10%)
<jdstrand> nice :)
<niemeyer> jdstrand: Not clear to me.. what are we looking for?
<niemeyer> jdstrand: snaps need to be useful in the first place, otherwise there's no point in even doing the work
<jdstrand> niemeyer: I think maybe if we/I knew where we were going with the future assertions and UI work, it might be clearer. for example, we know that snaps providing a slot will need an assertion saying it is ok
<jdstrand> (aiui)
<jdstrand> and if we know that the ui requires users to make an active decision to connect, then things like system-observe can be approved
<jdstrand> I'd hate for people to copy/paste code though (install my snap, run this snap connect command and everything is great!)
<jdstrand> I'm not sure what we want either
<jdstrand> I can say that gut feeling is some things seem to need manual store approval, but some things don't
<niemeyer> jdstrand: For specific interfaces.. both slots and plugs will need a declaration
<jdstrand> but I'd like it to be less about our guts and more about defining why things are the way they are
<niemeyer> jdstrand: Right, exactly
<jdstrand> and it can be case by case, but I'd like to know the criteria for deciding :)
<niemeyer> jdstrand: One criteria is that it must be useful..
<jdstrand> like, nm slot needs a lot of privilege (manual approve?), nm plug gives a lot of priv (manual approve??), system-observe gives some priv but manual connect (auto-approve?)
<elopio> fgimenez: I forgot we now have a meeting on fridays too. I'm sorry.
<jdstrand> niemeyer: can you expand on that? must be useful seems like a criteria for implementing the interface at all
<niemeyer> jdstrand: Yes, the idea that manual connect == auto approve seems good
<jdstrand> niemeyer: yes, I've been leaning towards manual connect == autoapprove as the baseline, then perhaps with exceptions as we see fit?
<jdstrand> 'as we see fit' is obviously still a gut thing atm, but at least manual-connect == auto-approve as a default stance is helpful
<jdstrand> niemeyer: I don't want to try to solve this all today-- just trying to keep the conversation going
<niemeyer> jdstrand: Yeah, the decision making in those cases requires some deep thinking.. let's see..
<jdstrand> niemeyer: how about this: home and *-observe are all manual connect, so we auto-approve
<jdstrand> niemeyer: then we punt on nm, *-control, etc for now and leave them as manual connect and manual approve while we continue to think about it?
<jdstrand> niemeyer: I think that will help real folks. I see system-observe and log-observe along with home periodically
<fgimenez> elopio, np, we'll be repeating it during next week
<seb128> where do I report bugs about https://github.com/ubuntu-core/snapcraft/blob/master/docs/your-first-snap.md ?
<seb128> that has an example with an icon key
<seb128> which is deprecated
<kyrofa> sergiusens, now that mark wants the snapcraft-examples thing to be different, I think I'll leave that branch for didrocks. Sound okay?
<seb128> jdstrand, hey, is there any easy way to make strace work in a snap without devmode? I tried to enable ptrace in the profile but get
<seb128> some permission denied error still
<elopio> fgimenez: I made some comments on the check branch. I'm again pushing for fixing them after we can free a reporter interface.
<elopio> we can discuss it in the meeting.
<jdstrand> seb128: depends on what you define as easy. you can modify /var/lib/snapd/apparmor/profiles/snap.your.app to have 'ptrace,' then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.you.app'. then add 'ptrace' to /var/lib/snapd/seccomp/profiles/snap.your.app
<jdstrand> seb128: note, you need the comma in the apparmor rule, you don't in the seccomp
<fgimenez> elopio, ok, sounds good
<vejmarie> ok, I made another progress
<vejmarie> so it looks like that snappy do not authorized listen and bind
<vejmarie> syscall
<vejmarie> is there any specific reason for that ?
<vejmarie> FreeCAD is using sockets
<vejmarie> if I had the sys call into /var/lib/snapd/seccomp/profiles/snap.freecad.FreeCAD
<vejmarie> I can go further
<vejmarie> I now have GL crash (but this is probably because I am missing some libraries into the snap and test system)
<seb128> shrug
<seb128> error: cannot remove "gnome-calculator": snap "gnome-calculator" has changes in progress
<seb128> the squash unmount failed due to process still actives
<seb128> which I killed now
<seb128> restarting snapd didn't fix it
<seb128> how do I get out of there?
<davidcalle> seb128: I use https://github.com/zyga/devtools/blob/master/reset-state
<davidcalle> It's a radical option, though
<seb128> that's still needed?
<seb128> I did that in Prague but I hoped snapd was more solid nowadays :-/
<seb128> davidcalle, thanks
<ogra_> seb128, i think it is fixed already, just not landed via SRU
<seb128> k
 * seb128 wipes snap away
<ogra_> seb128, bug 1583085
<ubottu> bug 1583085 in snapd (Ubuntu) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085
<ogra_> i think 2.0.5 has the related fix
<seb128> I've 2.0.3
<seb128> needs to upgrade
<seb128> I installed snapcraft from proposed but not snapd it seems
<seb128> back to my canonical-tech message, need an easier way to get those updates that to cherry pick from proposed ;-)
<seb128> jdstrand, thanks for the help, fcitx works with "#include <abstractions/fcitx>" added the apparmor profile, I updated the im bug with details
<jdstrand> seb128: interesting. I don't have abstractions/fcitx... I'll need to look into this. thanks so much!
<seb128> jdstrand, yw!
<seb128> jdstrand, it's part of fcitx-data
<seb128> jdstrand, btw robert_ancell might need your input on a similar issue on https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1581187
<ubottu> Launchpad bug 1581187 in lightdm (Ubuntu) "AppArmor parser error for /etc/apparmor.d/lightdm-guest-session in /etc/apparmor.d/lightdm-guest-session at line 14: Could not open 'abstractions/fcitx'" [Undecided,New]
<jdstrand> seb128: yes, I thought of that bug when you mentioned that abstraction
<seb128> lightdm included the abstraction but it might not be installed
<jdstrand> I need to see what it going on
<seb128> we maybe need to move the abstraction to a package which is always installed if includes can't be optional
<jdstrand> seb128: includes can't be optional. another option is to have lightdm depends on the package that is providing the abstraction. let me look into it before I make a recommendation
<jdstrand> well, they can be options if you #include a directory and drop files into the directory. that isn't the case here
<jdstrand> optional*
<sergiusens> kyrofa not super hard to change though ;-) But I know where this is headed ;-)
<kyrofa> sergiusens, hahaha
<sergiusens> seb128 2.0.3 was the one that supposedly fixed that problem you see
<sergiusens> seb128 2.0.3 was the one that supposedly fixed that problem you see
<seb128> sergiusens, needs to be fixed harder then
<ogra_> ouch
<sergiusens> vejmarie for bind you need the network-bind interface
 * ogra_ is sure seb128 is just holding it wrong
<seb128> lol
<vejmarie> @sergiusens: Thanks a lot ! I am new to the tool and didn't figure out all the interfaces ;)
<nothal> vejmarie: No such command!
<mhall119> how can I re-do the staged packages in a part without re-compiling the source in that part?
 * mhall119 thinks he figured it out
<sergiusens> mhall119 in the same part? not likely supportable as a stage-package has the potential to change the build result
<mhall119> oh? I thought only build-packages would affect the build result
<kyrofa> mhall119, no, stage packages can also be used for the build
<kyrofa> mhall119, they're pulled down and unpacked as part of the pull step
<kyrofa> mhall119, in fact, the python plugins use stage packages IN the pull step
<vejmarie> ok: I still have some issues with the software raster dry driver
<vejmarie> I have this libGL error: unable to load driver: swrast_dri.so
<vejmarie> my snap is connected to OpenGL (not yet x11, and unity7)
<vejmarie> and GTk do not find modules which are into the snap either like overlay-controller
<sergiusens> vejmarie I'll have to address you to zyga for that
<sergiusens> kyrofa is 525 good to go?
<vejmarie> sergiusens: no problem, is he on the channel ?
<sergiusens> vejmarie yeah
<vejmarie> ok, I did connect free cad to x11
<vejmarie> no changes
<vejmarie> libGL can't find swrast_dri
<vejmarie> and Gtk complains about modules
<vejmarie> any ideas welcome ! This is the last issues I have and then after FreeCAD will be fully snapped (except the build of the app which is performed though a single script, as it is coming with the whole dependencies)
<kyrofa> sergiusens, yessir
<vejmarie> zyga: r u there ?
<zyga> vejmarie: yes
<zyga> vejmarie: what's up?
<vejmarie> I have some issue to snap freecad
<vejmarie> I am mostly done but this piece of code is huge
<vejmarie> and requires access to some dry drivers for 3D rendering like swrast_dri.so
<vejmarie> I put them into my snap
<vejmarie> and run on ubuntu
<vejmarie> I setup the various interfaces to x11 OpenGL and unity7
<vejmarie> but still no way to load properly the driver through libGL
<vejmarie> same thing for some VTK module like overlay-scrollbar
<zyga> vejmarie: I have no idea how to help you right now, I'd need to jump into that snap and figure out how the stack looks like, I only planned to do that after some infrastructure code is done (bind mounts and environment via interfaces)
<zyga> vejmarie: then the goal will be to *remove* all wrapper-ser variables
<zyga> vejmarie: but now I cannot do much, I can only help to guide you and I'll gladly take patches that don't depend on those two features
<vejmarie> zyga: ok I will continue to digg and keep you posted. Hopefully I will find from where the issue come
<morphis> niemeyer: just commented back on the udev rules in gadget/kernel snap thing
<morphis> niemeyer: that is a very critical thing and we simply can't rely on releasing a new snapd version for each new supported device
<morphis> niemeyer: though we could abstract the rule generation with a specific interface
<morphis> which then just makes things quite more complex
<morphis> jdstrand: ^^
<morphis> zyga: ^^
<niemeyer> morphis: If it was "simply can't" we probably wouldn't be talking about it :)
<niemeyer> morphis: At the very least it's not simple, and perhaps not even can't :)
<jdstrand> I don't have context
<niemeyer> morphis: We won't allow security overruling like that..
<niemeyer> jdstrand: This is about kernel/gadget snaps shipping arbitrary security snippets
<morphis> jdstrand: udev rules for modem detection to be concrete
<morphis> niemeyer: the thing is that we can't even expose certain vendor IDs until a device is published
<morphis> so we basically sit on a factory image with a customized snapd as we can't release the used IDs in the public interface definition
<jdstrand> ok. I'm a bit out of date possibly, but I thought that is one of the reasons why the gadget snaps exists-- to create devices that snapd can reliably consume?
<morphis> jdstrand: yes
<morphis> that was my understanding too
<niemeyer> morphis: Well, hmm
<jdstrand> but I don't think any of that is designed. perhaps I'm wrong. I think zyga had some ideas
<jdstrand> so
<jdstrand> just otoh
<jdstrand> the gadget snap doesn't have to ship udev rules
<morphis> jdstrand: actually that is something really important if we're talking about what we need pretty soon in snapd for customer devices
<jdstrand> it could ship yaml that tells how to match
<zyga> we were thinking about an slot that the gadget could have, that would be plugged to various special snaps (like n-m) that would grant permissions to the plug side and the permissions were encoded in the slot side
<niemeyer> morphis: The udev rules are not much of a concern, actually
<morphis> jdstrand, niemeyer: basically that is what I got from zyga that we would put the udev rules into the gadget or kernel snap
<jdstrand> then snapd takes that and creates udev tags or something that can be used for hw mapping
<niemeyer> morphis: Because simply detecting won't give implicit access
<niemeyer> morphis: What happens next after detection for this particular case?
<morphis> niemeyer: you mean what ModemManager does with detected devices?
 * jdstrand notes I think we are talking about two different things-- reliably detecting and then connecting what was detected
<morphis> guys, can we maybe do a meeting about this next week to solve this?
<zyga> yes
<niemeyer> morphis: Sounds good
<morphis> maybe the best thing
<jdstrand> wfm
<niemeyer> morphis: It'll probably be a very short one
<niemeyer> morphis: I think we're all pretty much in agreement
<morphis> niemeyer: possible, lets see
<niemeyer> morphis: I jumped the gun with my comment, misunderstanding what you were actually asking for
<morphis> we just need to get to a common understand and what the way forward is to get this implemented
<niemeyer> morphis: Sorry about that
<morphis> niemeyer: np
<morphis> niemeyer: lets move this discussion to the meeting
<niemeyer> +1
<morphis> we can explain what ModemManager does and you apply to that what snapd should do with that
<morphis> then we will come out with something
 * jdstrand notes he is off Monday (US holiday)
<morphis> jdstrand: ah, forgot that
<morphis> jdstrand: moved it to tuesday then
<jdstrand> thanks
<zyga> jdstrand: https://github.com/ubuntu-core/snap-confine/pull/7 reviewed
<zyga> :D
<willcooke> I'm trying to build a snap from a git repo.  When it downloads from git the thing I want to build is in a subdir.
<willcooke> Specifically...
<willcooke> I'm trying to build Mythtv
<willcooke> if you clone the git repo, then the main bulk of the app lives in a subdir "mythtv" which has the configure file in it
<willcooke> so when I run snapcraft on it it can't find configure in builddir and so it tries to run autoreconf -i
<willcooke> the configure file does exist, just in builddir/mythtv/
<willcooke> can I tell snapcraft to look in that dir instead of "build"?
<willcooke> *root of build
<zyga> hmm
<zyga> stuff works :")
<qengho> willcooke: I think you either need to make your own plugin, or put a dir in your root and in another section with source: yourdir\nplugin: make  and make the Makefile boot up your own configure, etc.
<qengho> willcooke: your plugin will just extend the normal autoconf.
<willcooke> cool, I'll try a new plugin, thanks qengho
<vejmarie> ok, some progress on my side, if I run as root the snap bin command no libGL issue. If I run as a standard user, I got error loading the GL driver
<qengho> vejmarie: oh man the driver stuff is going to be ugly. I encountered that recently.
<vejmarie> how did you fix it ?
<vejmarie> it is really really strange
<vejmarie> as root
<vejmarie> ls -lt /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
<vejmarie> -rw-r--r-- 8 root root 9734592 Apr 14 19:08 /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
<vejmarie> as user
<vejmarie> ls -lt /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so
<vejmarie> ls: cannot access '/usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so': No such file or directory
<qengho> vejmarie: what stage-packages do you have? At least [ libgl1-mesa-glx, libgl1-mesa-dri ]  ?
<vejmarie> wrong copy you have to remove the tls
<vejmarie> yep
<vejmarie> this issue is really really strange to me
<willcooke> qengho, it only bleedin' worked!
<qengho> :D
<kyrofa> willcooke, there's a `source-subdir` param you can use
<willcooke> kyrofa, ah, that sounds exactly what I needed - does that work for autotools too?
<kyrofa> willcooke, indeed-- any plugin that supports the `source*` keywords
<willcooke> I'll give that a go, thanks
<kyrofa> willcooke, you can learn more about those keywords with `snapcraft help sources`
<willcooke> kyrofa, that was exactly what I needed, thanksÂ¬
<willcooke> !
<kyrofa> willcooke, any time! Sorry for the delay :)
<willcooke> kyrofa, ain't no thing.  I copied the autotools plugin and added another option, which then did:
<willcooke>         if self.options.build_subdir is not None:
<willcooke>             self.builddir = os.path.join(self.builddir, self.options.build_subdir)
<willcooke> which I expect is pretty much the same as source-subdir
<willcooke> so I can drop that now
<kyrofa> Pretty close, yeah
<willcooke> it does mean I don't get to make a PR against snapcraft though
<willcooke> :)
<willcooke> better luck next time I guess
<sergiusens> willcooke you can still get around to the gnome builder one ;-)
<willcooke> sergiusens, desrt is working on that one
<beowulf> hi, is there an example of a snap with fontconfig as a dependency, or handles fontconfig configs?
<qengho> beowulf: https://bugs.launchpad.net/snapcraft/+bug/1576303
<ubottu> Launchpad bug 1576303 in snapcraft (Ubuntu) "Needs fontconfig integration" [Undecided,Confirmed]
<beowulf> qengho: aha! thanks
<qengho> Ain't no thang.
<qengho> Have any of you encountered "python2" plugin complaints that .pth files are not supported, stemming (I think) from the part install dir not being the stage dir (which is in PYTHONPATH)?
#snappy 2016-05-28
<vejmarie> Hi folks
<vejmarie> I am progressing really well
<vejmarie> I just have an issue with the locale
<vejmarie> free cad is using GTK and I got Locale not supported by C library :(
<vejmarie> any idea on how to get ride of it
<vejmarie> seems to be related https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357
<ubottu> Launchpad bug 1584357 in snapcraft (Ubuntu) "Snappy GTK applications" [Undecided,New]
<vejmarie> ubottu you are right
<ubottu> vejmarie: I am only a bot, please don't think I'm intelligent :)
<vejmarie> anyway I made half the way as I have gdk working ;)
<vejmarie> Hi guys, I got this error while trying to upload a snap
<vejmarie> Developer profile is missing short namespace
<vejmarie> how can I address it
<sgclark> hi all, I have kdevelop so very close to done, but a few straggling issues, it would be lovely to go through the build logs.. but I cannot seem to find them, where does snapcraft hide these?
<zyga> vejmarie: I didin't see that bug before, can you open bug on snapcraft please (it will get moved to the right projcet)
<zyga> sgclark: I don't think it does
<vejmarie> zyga: I fix it, this was coming from the fact that I never logged on http://myapps.developper.ubuntu.com
<vejmarie> but the error message is far from easy to understand
<sgclark> zyga: don't think it does produce build logs or hides them?
<zyga> sgclark: I think logs just scroll past you
<zyga> sgclark: I doubt there's anything saved
<sgclark> ick
<sgclark> ok
<sgclark> piping them to a log then lol
#snappy 2016-05-29
<hathor008> hmm
<netphreak> hi, guys!
<hathor008> hm does anyone have any examples for MonoGame deployment?
<sethj> "version" is the version of the snap itself, right? Not the app?
<hathor008> hrm i'm confused about how to deploy my app the samples aren't really showing me what to do
<hathor008> I have a folder with a bunch of files in it, one of which is an executable shell script, just want it to dump the files into a folder and use the shell script as the command
<sethj>     ERROR: Python module dbus not found
<sethj>     ERROR: Python module dbus.service not found
<sethj> how would I ensure these modules are avaible for my snap?
#snappy 2017-05-22
<Chipaca> niemeyer: http://imgur.com/RmoleVs
<Chipaca> not ready yet, but, shellcheck for prepare/execute/etc \o/ :-)
<niemeyer> Chipaca: Sweet!
<Son_Goku> meep
<mup> PR core#45 closed: allow rsyslog disabling <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core/pull/45>
<abeato> ogra_, hey. I'm following the discussion on androidboot here: https://forum.snapcraft.io/t/android-support-in-snapd/327/34
<zyga> good morning :)
<morphis> Pharaoh_Atem: ping
<morphis> zyga: morning!
<morphis> zyga: I've found a "fix" for our ld problem for snap-confine on fedora as it seems: http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5
<morphis> zyga: sadly that is only in >= F26
<morphis> Pharaoh_Atem: ^^
<morphis> mvo: morning!
<morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3360 ?
<mup> PR snapd#3360: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360>
<mvo> morphis: sure
<mup> PR snapd#3356 closed: tests/lib: allow SRU validation only on ubuntu type systems <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3356>
<morphis> mvo: thanks!
<mvo> morphis: was mostly waiting for something that uses it, but its fine
<morphis> mvo: yeah that will come next
<morphis> mvo: any comments from your side on https://github.com/snapcore/snapd/pull/3274 ?
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<mvo> morphis: I have a look in a tiny bit
<morphis> mvo: thanks!
<mup> PR snapd#3360 closed: tests/libs: add distro_auto_remove_packages function <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3360>
<zyga> morphis: good morning
<zyga> morphis: can you document what that does?
<zyga> morphis: what is 'r' there?
<morphis> zyga: morning!
<morphis> zyga: what do you mean?
<zyga> morphis: that macro, what does it technically do?
<zyga> morphis: e.g. I can imagine what static and shared are
<zyga> morphis: but a good comment block there would help
<morphis> zyga: not sure what the 'r' does but it prevents -pie from being added to LDFLAGS when -static is used
<morphis> a comment block where?
<morphis> http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5 is nothing I can change
<zyga> morphis: just above that macro, to explain what is going on
<zyga> ahh
<zyga> I thought that was something we have to add to our spec
<morphis> no
<zyga> sorry, it makes sense now :)
<morphis> that is one of the scripts automatically pulled in for all builds via LDFLAGS
<morphis> but I agree, pretty hard to understand if you don't know anything about these macros :-)
<morphis> zyga: but https://github.com/snapcore/snapd/pull/3365/commits/67673a2c86263a401d078d7c82d2e1a43abfa389 should fix this problem for us
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<zyga> nice! :)
<morphis> zyga: waiting for what Neal says :-)
<morphis> zyga: when you have time today, a review on https://github.com/snapcore/snapd/pull/3365 would be great (but ignore the packaging bits, Neal is landing them separately)
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<elfgoh> Just checking, is delta snap upgrades a current feature?
<Chipaca> elfgoh: yep
<ogra_> abeato, thats a beautiful idea!
 * ogra_ will answer in the tread .. 
<abeato> ogra_, I knew you would like it ;)
<ogra_> :D
<morphis> zyga: thanks!
<zyga> morphis: thank you :-)
<morphis> zyga: hopefully have a PR for suse build support in spread tomorrow too
<zyga> I need to mute some of the commit message email notification from fedora, my inbox is full of htem
<zyga> morphis: fanstatic!
<zyga> morphis: I'm going in four days, that will be some nice news I can share
<elfgoh> @Chipaca
<nothal> elfgoh: No such command!
<morphis> at least able to run tests/main/null :-)
<elfgoh> Chipaca: I did remember reading it but didnt seem to find it mentioned at https://snapcraft.io/docs/ any idea which page  mentions it?
<davidcalle> elfgoh: not mentioned in docs yes AFAICT, if it has landed in stable, it should be, otherwise, you should search in forum.snapcraft.io, there was an env var to set to test it iirc
<davidcalle> elfgoh: just checked, it's enabled by default
<davidcalle> snapcraft 2.28
<Chipaca> elfgoh: no, sorry
<elfgoh> davidcalle: are you referring to "Delta uploads are now enabled for every snapcraft push done, a welcome bandwith saving addition."?
<davidcalle> Indeed
<Chipaca> that's uploads, that came after downloads
<davidcalle> Oh, I misread upgrades in your question, so yes, it's enabled
<elfgoh> davidcalle: Chipaca : seems like delta downloads are currently disabled by default. Guess it is not stable yet? https://github.com/snapcore/snapd/blob/0e53b0aac99d112b3e2669701b5540f286e5a713/tests/main/refresh-delta-from-core/task.yaml#L3
<zyga> elfgoh: odd, I saw delta updates for core all the time and I didn't enable anything
<Chipaca> zyga: disabled by default _on core_
<Chipaca> is what that comment says
<zyga> ah, on all-snap
<zyga> sorry
<Chipaca> I'm not sure that comment is current, though
<elfgoh> So it is enabled on all snaps but disabled on core?
 * ogra_ is pretty sure you guys held that back 
<ogra_> (for ubuntu-core images that is)
<Chipaca> 	deltasDefault := release.OnClassic
<Chipaca> 	return osutil.GetenvBool("SNAPD_USE_DELTAS_EXPERIMENTAL", deltasDefault)
<ogra_> yeah
<Chipaca> so, it defaults to false on core
<elfgoh> So false on core snap, but is it true on other snaps?
<Chipaca> no, false on core systems, true everywhere else
<ogra_> no, false on core images
<ogra_> (for all snaps there)
<Chipaca> core as in non-classic
<Chipaca> i.e. devices
<Chipaca> i.e. probably memory and/or cpu constrained
<elfgoh> Ah i see
<pedronis> Chipaca: we should revisit this, IÂ suppose nobody did yet the benchmarks though ?
<ogra_> +1
<Chipaca> pedronis: i nominate ogra_ for the benchmarkingening
<ogra_> should just setting the env var in /etc/environment be enough ?
<ogra_> or will anything unset it internally if it finds i'm on core
<Chipaca> nothing will unset it, no
<ogra_> good
<Chipaca> it just defaults to false on core
<ogra_> i'll do some testing during the day (though am a little swamped by the humminboard gadget currently)
<Chipaca> ogra_: maybe we can write something simple that does the heavy lifting of a delta refresh, so we can get some numbers
<Chipaca> not that i'm volunteering for that :-)
<elfgoh> Got it with regards to delta upgrades. Is there a roadmap for that?
<elfgoh> A rough one that I wont be holding anyone to :)
<pedronis> ?
<ogra_> elfgoh, well, see above, they should just work ... we just havent tried what the impact on the system is
<ogra_> which is why the variable is currently unset
<ogra_> you can just edit /etc/environment if you want to try it out on a test system
<elfgoh> Ok fair enough. Would it be helpful if I file an issue somewhere, or post on the forum?
<pedronis> mvo: so 2.25 is blocked ?
<ogra_> SNAPD_USE_DELTAS_EXPERIMENTAL=true
<elfgoh> Just so that it wont be forgotten in the long run :)
<mvo> pedronis: yeah, currently due to the potential regression on revert
<mvo> pedronis: CE QA is not passing
<pedronis> mvo: revert of core ?
<pedronis> 2.25 -> 2.24 ?
<mvo> pedronis: correct,
<mvo> pedronis: yes, the fact that seccomp profiles are now richer than in 2.24 and when 2.24 sees them it will explode
<pedronis> mvo: there's a small issue also related to aliases like that, but we can fix it only with 2.24.1 if we care
<pedronis> (IÂ mean it's not something we can fix with 2.25)
<mvo> pedronis: is my forum post understandable on what the issue is? if not I will redo it to make it clearer
<pedronis> mvo: now IÂ understand it, it also seams something that would need a 2.24.1 though
<mvo> pedronis: how bad is the effect when the aliases are reverted?
<mvo> pedronis: if its mostly small glitches I think that is not too terrible, however the seccomp thing prevents daemons from starting which is pretty major
<zyga> hey guys
<zyga> how can I help
<zyga> mvo: I didn't want to mention this before cause it's not helping much
<pedronis> mvo: you get a error on each refresh (but given that refreshes use lanes it doesn't affect any real update afaik), it gets unstuck when the affected snap gets a real refresh
<mvo> pedronis: doing a 2.24.1 is doable but the problem is that some devices may have a factory image of e.g. 2.21 or similar, so retro fitting a fix is troublesome
<zyga> mvo: but I wrote a patch that lets snapd resolve the constants in appamror profiles (think AF_UNIX)
<zyga> mvo: so we could eliminate the issue when starting up
<mvo> pedronis: ok, thank yo. that sounds annoying but not catastrophic
<zyga> mvo: i didn't want to mention it because I wasn't sure we'd want to merge that (I did it for a totally different reason)
<zyga> mvo: but in light of the issue perhaps we might
<zyga> mvo: it is in this branch: https://github.com/zyga/snapd/tree/feature/typed-syscalls
<mvo> zyga: hm, interessting. sounds good, unfortunately will not help with this particular issue
<zyga> mvo: no?
<zyga> mvo: I think it does
<zyga> mvo: because old snap-confine can read seccomp filters with numeric constants just fine
<mvo> zyga: oh, that is nice
<zyga> mvo: it chokes on new symbols and new syntax
<pedronis> mvo: 2.25 drops the 2.24 state about aliases, so 2.24 on refresh tries to create them but they are already there,  if you do a full real refresh of a snap , all its aliases are deleted so this gets unstuck
<zyga> mvo: this eliminates new symbols
<mvo> zyga: sorry, I misunderstood what it is doing then, that is nice
<zyga> mvo: does not eliminate new syntax, I believe we have added one but I'd have to check when (the |foo syntax for bitwise masking)
<zyga> mvo: as I said, it started as something else entirely
<mvo> zyga: could you check that?
<pedronis> mvo: anyway a bit unclear how to fix these kind of problems, we would need anti-patches to applay when we know we are about to revert core
<mvo> zyga: if we relly only added new constants it may get us out of this for now
<zyga> mvo: yes, checking
<zyga> mvo: the "meat" is this feature: https://github.com/zyga/snapd/commit/4c2d556335401a73fb536f17a9f7568ae59656d2#diff-3b6970e27a8fba15de5e737fa725d7f5R87
<mvo> pedronis: yeah, the general case for this is hard
<mvo> zyga: did jamie had a chance to look at this yet?
<mvo> zyga: this being your new code?
<zyga> mvo: last new syntax was added on the 30th january
<zyga> mvo: yes
<zyga> mvo: it's not new, I wrote it over two weeks ago
<zyga> mvo: we talked about the way the seccomp profiles look like, I wanted to make them more readable
<zyga> afk, package
<zyga> ...
<mup> PR core#46 opened: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <https://github.com/snapcore/core/pull/46>
<mvo> morphis: 3357 has a conflict now, otherwise ready to go in
<morphis> mvo: let me check
<morphis> mvo: fixed
<zyga> re
<zyga> mvo: though thinking about it more, this can land and it will still not fix the issue because it will only take effect next time
<zyga> mvo: so it will fix the issue but only with the future update
<zyga> mvo: here we're really at a place where revert is impossible
<zyga> mvo: as any new mechanism we add won't take effect until we reboot
<zyga> mvo: hmm
<zyga> mvo: maybe I'm too pesimistic
<zyga> mvo: if you update to edge with this patch you could go back actually
<zyga> mvo: if you want me to explore this I can clean that up, remove the parts that don't matter
<zyga> mvo: and just focus on resolving the constants
<fgimenez> hi mvo, not sure if this is known but tests/main/listing is failing with the latest core in edge (amd64 1999) https://travis-ci.org/snapcore/spread-cron/builds/234734542#L1022
<mvo> fgimenez: yeah, I noticed, the version number is now in line with mkvresions.sh (almost) and that breaks the regexp
<mvo> ogra_, zyga: if someone could check https://github.com/snapcore/core/pull/46 that would be great, then I will update hte listing test next
<mup> PR core#46: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <https://github.com/snapcore/core/pull/46>
<zyga> ok
<ogra_> heh, so much "cut" ...
<mvo> zyga: \o/
<zyga> paper-cut
<ogra_> looks ok, though i would have gone with a single sed command for all three cuts
<mup> PR core#46 closed: cut the trailing ~ubuntu16.04 from the version that the PPA auto-generates <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/46>
<elfgoh> Quick check: is there some kind of cgroups functionality for snaps?
<zyga> yes
<mup> PR snapd#3368 opened: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368>
<ogra_> mvo, what does git202 mean in the new version number ? (why not just git)
<mvo> ogra_: it will increase and give us correctly sorted versions, its the commit count since the last taged version (since 2.26.3 in this case)
<ogra_> ah, k
<zyga> mvo: niiiice
<zyga> mvo: how did you come up with that?
<zyga> mvo: do we comit that per build?
<ogra_> mvo, you forgot the manifest
<zyga> mvo: or does it come from launchpad?
<elfgoh> zyga: where is it documented, or rather, what is the name of the functionality I should search?
<zyga> elfgoh: re
<mvo> ogra_: aha, indeed
<zyga> elfgoh: sorry, it's not documented much
<mvo> zyga: comes from LP
<zyga> elfgoh: but I can tell you about it quickly
<mvo> zyga: have you seen https://errors.ubuntu.com/problem/19272ebc18709d4407dba0438a536d56bb143069 ?
<zyga> elfgoh: each process may optionally get a device cgroup that has just a subset of system devices available
<zyga> elfgoh: that's it
<mvo> zyga: looks like we get quite a lot of those: "Error ERROR run hook "configure" â cannot create lock directory /run/snapd/lock â Permission denied"
<zyga> elfgoh: the optional part depends on how interfaces are implemented
<zyga> mvo: where?
<mvo> zyga: on the error tracker
<mvo> zyga:  ERROR run hook "configure": cannot create lock directory /run/snapd/lock: Permission denied
<zyga> mvo: I helped someone on IRC yesterday, this happens before dpkg --configure -a is done
<zyga> mvo: because we get an apparmor profile with .dpkg-new
<ogra_> mvo, we had someone here last week with the very same error
<zyga> mvo: and the update is otherwise paritally applied
<mvo> zyga: aha, that explains why this is only happening for some snaps then
<zyga> mvo: not sure if that's the same reason as what the errors you saw are but this is a very likely explanation
<zyga> mvo: s/snaps/people/
<elfgoh> zyga: thanks for the nutshell. Which repo and what search string should I be using to search to take a deeper look?
<zyga> elfgoh: snapd itself, in cmd/snap-confine/udev-support.c
<zyga> elfgoh: and in snapd itself in interfaces/builtin/*.go
<zyga> elfgoh: an interface can tag devices in udev
<zyga> elfgoh: and if any tagged devices are found a cgroup is made
<mvo> zyga: was this in this channel? then I will read the logs for the details
<ogra_> yep
<zyga> mvo: yes it was
<zyga> mvo: let me find it
<zyga> ah
<zyga> where are the public logs again?
<elfgoh> zyga: thanks for the info!
<mvo> zyga: https://irclogs.ubuntu.com/2017/05/21/%23snappy.html
<ogra_> mvo, https://paste.ubuntu.com/24605885/ it was davhou around the 19th 18:0 UTC
<zyga> ah, thanks ogra_ :)
<ogra_> *18:30
<mvo> zyga: well, https://irclogs.ubuntu.com/2017/05/19/%23snappy.html#t17:43
<mvo> ogra_: thank you
<elfgoh> zyga:  is there a repo for https://snapcraft.io/docs/? I am happy to send PRs for whatever little nuggets of gold I find in here
<zyga> elfgoh: yes, let me find it
<davidcalle> @elfgoh, zyga: https://github.com/CanonicalLtd/snappy-docs
<nothal> davidcalle: No such command!
<davidcalle> Heh
<zyga> elfgoh: https://github.com/CanonicalLtd/snappy-docs
<elfgoh> heh slack user?
<ogra_> zyga, or Chipaca ... a second ack at https://github.com/snapcore/core/pull/43 would be nice
<mup> PR core#43: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43>
<elfgoh> Ok another question, is the GPIO interface supposed to be working on pi3?
<ogra_> elfgoh, it surely is
<zyga> ogra_: done, though you will not like it
<ogra_> zyga, lsb_release is gone since about a year and i wont add it back
<elfgoh> ogra_: good to know. I will make a post on the forum for my use case then
<ogra_> zyga, this just removes it in a clenaer way, check the code ;)
<ogra_> zyga, (also you commented on the code that adds it to the classic snap :) not teh code that removes the left over dpkg fragments)
 * elfgoh discovers the new channel topic https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38
<mup> PR core#47 opened: keep version Makefile in sync with version-script <Created by mvo5> <https://github.com/snapcore/core/pull/47>
<mup> PR core#43 closed: remove generated logs, cleaner lsb-release removal <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/43>
<Chipaca> huh
<ogra_> elfgoh, the interfaces follow the naming scheme from https://pinout.xyz/#
<ogra_> Chipaca, ?
<Chipaca> I always forget how export FOO="$(yadda)" is very different from FOO="$(yadda)"; export FOO
<morphis> fgimenez, zyga: can you check https://github.com/snapcore/spread-images/pull/2 again?
<mup> PR spread-images#2: Add fedora-25-64 image <Created by morphis> <https://github.com/snapcore/spread-images/pull/2>
<zyga> morphis: done
<morphis> thanks
<elfgoh> ogra_: for starters I believe BCM 27 may be missing https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml
<elfgoh> But seems like an easy fix
<ogra_> elfgoh, hmm, indeed it does
<ogra_> yeah
<elfgoh> I can send the PR if you are too busy lol
<fgimenez> morphis: done, LGTM
<morphis> thanks!
<ogra_> elfgoh, https://github.com/snapcore/pi3-gadget/pull/8
<mup> PR pi3-gadget#8: add gpio 27 <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/8>
<ogra_> :)
<Chipaca> ok, going to wrap this shellcheck branch here before it gets out of hand
 * Chipaca is so tempted to take it to the next level
<pedronis> Chipaca: spellcheck can be annoying, is the next level even more annoyance ?
<pedronis> heh, shellcheck
<Chipaca> pedronis: http://i.imgur.com/RmoleVs.png
<Chipaca> that's what kept me up to 1am last night :-)
<Chipaca> but i'm not running that yet; that would be the next level i alluded to
<ogra_> Chipaca, PATH=$PATH sudo -E ...
<ogra_> (and add quoting indeed)
<Chipaca> that one is the other way around I think?
<Chipaca> ie sudo PATH=$PATH â¦
<ogra_> -E will preserve the PATH you set before the sudo command ...
<Chipaca> no
<ogra_> it should
<Chipaca> -E preserves everything except the path
<pedronis> Chipaca: so you have a massive branch of tests/ fixes ? (IÂ expect them to be very shellcheck unagreeable atm)
<ogra_> Chipaca, wow ... why does the manpage not tell that!
<mup> PR snapd#3369 opened: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369>
<Chipaca> pedronis: ^ not that massive
<Chipaca> ogra_: Â¯\_(ã)_/Â¯
<Chipaca> ogra_: actually, it does
<Chipaca> ogra_: under "SECURITY NOTES"
<pedronis> Chipaca: those are the .sh though ?Â not the .yaml fragments, no?
<ogra_> yeah, but not under the explanation of -E ... there is no hint at all to even look at SECURITY_NOTES
<Chipaca> ogra_: â¦ although I'll admit that reading that section would make me think it does the opposite
<Chipaca> pedronis: correct, that's what i meant by _not_ doing the .yaml fragments yet
<Chipaca> um
<Chipaca> pedronis: I mean, this is what I meant about not taking it to the next level
<Chipaca> the output of shellcheck from the yaml fragments is long :-)
<pedronis> Chipaca: IÂ have complicated feelings about this
<Chipaca> pedronis: you can share your feelings with us
<Chipaca> pedronis: we're only writing it down all for posterity
<ogra_> Chipaca, btw, see the find in line 24 at https://github.com/snapcore/core-build/blob/master/.travis.yml ...
<pedronis> Chipaca: do you think the confusion avoidance down the line is worth this?
<elfgoh> ogra_: https://forum.snapcraft.io/t/gpio-on-raspberry-pi-3-not-working-for-blink-program/723
<pedronis> (these are not the prod script if IÂ understand)
<elfgoh> That's the details of the Pi 3 GPIO issue
<ogra_> Chipaca, to find all shell scripts ... easier than hardcoding all .sh names
<Chipaca> ogra_: thing is, different rules
<Chipaca> OTOH by not doing it that way I am missing some things
<ogra_> elfgoh, and you did use  https://pinout.xyz/# as translation table for pin to gpio ?
<pedronis> mvo:  listing tests seems to be still failing:  https://travis-ci.org/snapcore/snapd/builds/234747297 snapd#3368
<mup> PR snapd#3368: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368>
<elfgoh> Yup. The same source , when compiled using gcc. Runs fine
<elfgoh> ie outside of a snap
<elfgoh> So presumably, that means the source and the hardware connections are finwe
<elfgoh> *fine
<ogra_> just wanting to make sure ... since pin 22 isnt gpio 22 etc
<ogra_> elfgoh, also checking for DENIED in journalctl output and actual error output for your program call might be helpful in the tread
<mvo> pedronis: yeah, just noticed, regexps are hard (except for Chipaca who eats them for breakfast)
<Chipaca> mvo: let me know if you need help (i haven't looked)
<mvo> Chipaca: its fine I think
<mvo> Chipaca: just a silly typo (hopefully)
 * pedronis has lunch (no eating of regexpes involved though)
<mvo> lol@pedronis
<fgimenez> mvo: superlow priority, we have an issue with a test snap in staging, its name is too long and there's a restriction that prevents us from updating it, after catching up with nessita the better solution is to use a different snap with a shorter name and update the test to use it, we need it too in prod https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-kernel-module-consumer if you could register when you have a minute it that would be
<fgimenez> great
<fgimenez> mvo: wrong link sorry https://code.launchpad.net/~snappy-dev/+snap/test-snapd-kernel-module-consumer
<fgimenez> mvo: it seems also that the hello-world test snap used by tests/main/xauth-migration is not available in staging, i can't get the error now because staging seems to have problems  http://paste.ubuntu.com/24623008/
<Chipaca> zyga: ping
<mvo> fgimenez: I uploaded the new snap and shared it with you
<fgimenez> mvo: thank you!!
<zyga> Chipaca: yes?
<Chipaca> zyga: ok with you if i drop shellcheck from the cmd checks?
<Chipaca> zyga: (moving it up into run-checks)
<zyga> Chipaca: yes
<Chipaca> k
<zyga> Chipaca: feel free :)
 * zyga churns through some interface changes
<mvo> Chipaca: your branch about the shellcheck explodes in quite spectacular ways in travis, I have not looked into the details yet
<Chipaca> mbuahaha
<Chipaca> mvo: thanks for the heads up; i'll take a look
<ogra_> elfgoh, that looks like an actual bug in snapd's gpio interface ... i dont see any write permission to /sys/class/gpio/export in tteh interface
<elfgoh> ogra_: Output from journalctl https://forum.snapcraft.io/t/gpio-on-raspberry-pi-3-not-working-for-blink-program/723/2?u=elfgoh
<elfgoh> ogra_: indeed
<elfgoh> So another easy fix? :D
<ogra_> elfgoh, not sure, we'll need a security person for that ...
<elfgoh> Ok
<ogra_> i pinged in the thread ...
<Chipaca> ++ go get -u github.com/kardianos/govendor
<elfgoh> Thanks!
<Chipaca> opath/src/github.com/snapcore/snapd/tests/lib/prepare-project.sh: line 141: go: command not found
<ogra_> it wants you to stay, not go :)
<Chipaca> hrmph
<Chipaca> morphis: about pkgdb.sh
<morphis> Chipaca: yes
<Chipaca> morphis: seems to be a step back in speed and over-verbose output
<Chipaca> including progress bars in the build log
<Chipaca> morphis: is that something you'll be looking at, or should i meddle?
<morphis> Chipaca: I have a few quiet's coming
<Chipaca> morphis: wrt speed, a single apt-get of a bunch of packages is a lot faster than multiple apt-gets
<morphis> Chipaca: if you have any improvements for the pkgdb, I am all ears
<Chipaca> OTOH i assume it's a WIP, given one distro_install_package is followed by an apt-get :-)
<morphis> Chipaca: we could do some fancy concatenation by determining all correct package names first and then supplying that to a single distro install command
<morphis> let me tune that
<Chipaca> morphis: or use an array instead of concatenation
<Chipaca> the iteration will be a little gnarly, but otherwise cleaner in general
<morphis> is that easy enough to fold back into a string I can pass to apt-get?
<zyga> morphis: hey
<zyga> morphis: shall we land https://github.com/snapcore/snapd/pull/3366 and iterate?
<mup> PR snapd#3366: packaging: Add Fedora packaging files <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3366>
<morphis> I am fine with that
<mup> PR snapd#3366 closed: packaging: Add Fedora packaging files <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3366>
<pedronis> mvo: should we close snapd#3226 , IÂ think we should start more from a minimal skeleton and then maybe work separately on download, verification and execution (though we might need some kind of state on disk shared between download and execution)
<mup> PR snapd#3226:  snap-repair: add `snap-repair run`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226>
<mup> PR snapd#3364 closed: interfaces: allow snaps to use the timedatectl utility <Created by tyhicks> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3364>
 * ogra_ hugs zyga 
 * zyga hugs ogra back!
<ogra_> :)
<pedronis> fgimenez: didn't we increase workers and cut down execution time, are we still getting global timeouts, sometimes?  https://travis-ci.org/snapcore/snapd/builds/234764184
<mup> PR snapd#3370 opened: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
<zyga> Chipaca: another monster, smaller though https://github.com/snapcore/snapd/pull/3370/files
<mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
<zyga> Chipaca: and 2nd-to-last of this kind
<zyga> Chipaca: the only centralized part of interface that remains is the base declaration
 * zyga looks at all the PRs next
<fgimenez> pedronis: yes, looks like it, that execution had allocation problems and spent about 8min before starting actual tests, also we have moved unit tests from a spread task to a regular travis script step, this impose an upfront penalty to all jobs of about 5min (in that build 286s)
<fgimenez> pedronis: it also got stuck oon an apt-get update https://travis-ci.org/snapcore/snapd/builds/234764184#L1660
<fgimenez> we are close to 30min now on average https://travis-ci.org/snapcore/snapd/builds
<pedronis> thx
<morphis> zyga: thanks for merging!
<morphis> zyga: let me send a similar one for suse
 * zyga breaks for lunc
<zyga> pstolowski: some feedback on your snapctl-outside-of-hooks-PR
<pstolowski> zyga, great, looking! nb, any idea about 'listing' test failures? got this in my branch but also in master
<mup> PR snapd#3371 opened: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>
<morphis> zyga: ^^
<pedronis> pstolowski: there's a PR from mvo fixing that, taking a bit of time to get it landed
<pstolowski> pedronis, great, thanks
<fgimenez> mvo: this is the error we are getting in staging for tests/main/xauth-migration http://paste.ubuntu.com/24623205/ could make staging's hello-world be the same as prod's? let me know if i can help with that
<mvo> fgimenez: hm, this feels like we should use tes-tsnapd-tools there  anyway
<ogra_> echo 'foo bar' ?
<ogra_> whats that for
<Chipaca> mvo: does snapd#3368 mean the listing test is broken in master right now?
<mup> PR snapd#3368: tests: update listing test to the core version number schema <Created by mvo5> <https://github.com/snapcore/snapd/pull/3368>
<mvo> Chipaca: correct
<pedronis> it failed again :/
<pedronis> flaky++
<mvo> pedronis: yeah, for silly reasons
<mvo> pedronis: that it cannot connect to ubuntu-core
<niemeyer> o/
<fgimenez> mvo: ok thanks, i'm preparing a branch for fixing all the issues in staging, i'll include updating xauth-migration to use test-snapd-tools
<fgimenez> hey niemeyer
<mvo> fgimenez: thanks, sounds good
<zyga> re
 * zyga looks at spread
<zyga> we got a 504 from the store on delta test
<zyga>        for updates: got unexpected HTTP status code 504 via POST to
<zyga>        "https://search.apps.ubuntu.com/api/v1/snaps/metadata"
<pedronis> zyga: we don't retry on those it seems
<pedronis> also interesting
<zyga> pstolowski: ^ the gift that keeps on giving
<zyga> travis for the ciritcal PR (fix master) is running bug log is gone, I wonder if that will wokr
<zyga> *work
<pstolowski> zyga, indeed we don't...
<cprov> zyga, let me trace it on the (new) store
<mpt> Hi, where should I report a bug about forum.snapcraft.io itself?
<zyga> mpt: hey, I think the best way is to start a forum topic first
<zyga> mpt: we can then report a bug (though I don't know if the forum has a bug tracker yet)
<mup> PR snapd#3372 opened: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
<mpt> zyga, thanks, will do
<mup> PR snapd#3368 closed: tests: update listing test to the core version number schema <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3368>
<Son_Goku> mvo: we're going to need something like series for base snaps
<Chipaca> Son_Goku: like, tracks?
<Son_Goku> well, tracks don't work in this sense
<Son_Goku> because tracks are essentially channels
<Son_Goku> whereas a fedora 25 base, a fedora 26 base, and so on would be available in parallel in the same channel
<Son_Goku> with the ubuntu-core/core snap, you have the series property to give you guardrails
<Son_Goku> snaps can be bound to a particular series
<ogra_> mvo, hmm ... i got this worn out SD card wheer every n'th core update results in a corrupt uboot.env ... i noticed that if i do a manual refresh and call sudo sync before reboot, i never get the corruption ... looking at https://github.com/mvo5/uboot-go/blob/master/uenv/env.go#L234 i see we are actually calling f.Sync(), should that actually be the same as me calling sync manually ?
<ogra_> (i have the feeling it isnt)
<ogra_> (also ... shouldnt that eventually move into the snapd tree ?)
<ogra_> hmm, actually f.Sync() might only apply to the file, not acrtually flush the os buffers ...
<Son_Goku> Chipaca, basically, since it's not possible to version snaps, there's no easy way to constrain things properly
<Chipaca> ogra_: sync manually would also call sync on the directory, which we should be doing as well
<Chipaca> Son_Goku: how is this series different from having a snap called 'fedora-25', say?
<ogra_> Chipaca, well, sudo sync should actually flush all buffers to disk ... i think f.Sync() in that code above only cares that the file content gets written to the buffer
<ogra_> (but not necessarily that the kernel writes to disk)
<Chipaca> ogra_: no, f.Sync calls fsync on the file descriptor
<Chipaca> it's not python's flush
<Chipaca> but
<ogra_> right
<Chipaca> that code as it stands would lead to corruption
<Chipaca> because it changes the size of the file
<Chipaca> and doesn't sync the directory
<ogra_> the size of the file is fixed
<Son_Goku> Chipaca: *shrugs*
<ogra_> cant change
<ogra_> it shoudl only switch bytes
<Chipaca> oh?
<Son_Goku> Chipaca: why is there a "series" attribute if that would have worked before?
<ogra_> its a binary blob file ... uboot would fall over if the size changed
<Chipaca> Son_Goku: snappy with a series != 16 was a completely different beast to what it is today
<Chipaca> Son_Goku: "series" as it stands is a property of the system, not of a particular snap
<Son_Goku> so it's an assumption for an ubuntu core system
<Chipaca> Son_Goku: i'm not saying you're wrong, mind you! I don't know if you are. I'm saying it's not what series is today.
<Son_Goku> hm
<Son_Goku> Chipaca: one of my goals is to figure out a path to a Snappy Fedora system
<Son_Goku> otherwise, what's the point? :P
<Chipaca> :-)
<Chipaca> Son_Goku: I understand. My question about smashing it into the name is because it often unblocks us to do the simplest thing possible, even if it's slightly ugly, and especially when otherwise we'd need a BDUF
<Son_Goku> there was some interest from Matthew Miller (the Fedora Project Leader) on officially providing Fedora runtimes for Snappy among other things
<Son_Goku> especially as part of the Modularity initiative going on right now: https://docs.pagure.org/modularity/
<Son_Goku> so runtimes, application snaps, etc.
<Son_Goku> there's several blockers in the way of that, but hopefully we can chip away at them
<ogra_> Chipaca, aha ... unix.Syscall(unix.SYS_SYNCFS, ... ) from https://godoc.org/golang.org/x/sys/unix seems to implement syncfs, i guess thats what we are missing there
<cachio> niemeyer, I have 3 real machines to use to run spread tests if you want
<cachio> niemeyer, I mean, instead of using linode
<ogra_> adfad666, zyga, in case you didnt find that yet, u-boot build instructions for the pi u-boots are in the REAME.md of the gadget tree
 * ogra_ just noticed that missed friday night ping ... 
<mup> PR snapd#3373 opened: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/3373>
<zyga> ogra_: thanks!
<zyga> Son_Goku: woot :)"
<zyga> Son_Goku: I think that's well on our path and already started by mvo (and soon followed by myself)
<zyga> Son_Goku: I think by the time we hit the sprint we may have a good chunk of the basics in place to try a !default runtime
<zyga> Son_Goku: as we can make runtimes by hand really
<zyga> speaking of which
<zyga> I need to pick up kids from school
<niemeyer> cachio: These will certainly be useful when working through issues, but using Linode means you get the exact same environment that runs every other test in our automated CI, so we should use that as our litmus test
<niemeyer> cachio: Let me get you a key
<mvo> ogra_: just reading backlog
<fgimenez> hi morphis, do you know how to use the network-manager snap to control eth0 on an amd64 ubuntu-core system? "network-manager.nmcli d status" says eth0 is unmanaged
<ogra_> niemeyer, regarding your comment on https://github.com/snapcore/snapd/pull/3316 ... where do i find anything about the convention regarding summaries of PRs ? neither HACKING.md nor CONTRIBUTING.md speak about the format of a summary anywhere
<mup> PR snapd#3316: make /etc/localtime writable in timezone_control <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3316>
<niemeyer> ogra_: The full detailing is in the mailing list history.. need to bring that into the forum. Just looking through the PR list should give a hint, though.
<ogra_> ok
<Chipaca> ogra_: https://chris.beams.io/posts/git-commit/
<mvo> ogra_: I have a branch ready that adds dirsync, if you can reliable reproduce the issue I would love to get feedback if the dirsync one fixes it, let me know if a branch is enough
<ogra_> Chipaca, you mean i should just write "haaands" ?
<Chipaca> ogra_: of course, what else
<mup> PR snapd#3374 opened: partition: add directory sync to the save uboot.env file code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3374>
 * ogra_ grins
<ogra_> mvo, well, as i understand it, go apps should always call syncfs on exit automatically ... but the upgrade always ends with an endless "[\] Setup snap "core" (2008) security profiles (phase 2)" ... for the manual sync i need to ctrl-c that first ... i wonder if the non-exiting state of the process simply prevents the syncing
<pstolowski> zyga, re your comment about sc_context_cookie - are you suggesting to pass this around as a return value from the function etc. instead of char*? (makse sense if that's what you mean)
<ogra_> i.e. when there is an auto-reboot, the process will go on until the os reboots
<mvo> ogra_: interessting, even then it should be gracefully shut down, but if the above branch (3374) could be tested, that would be great. let me know if you need anything from me, i.e. if I should build you a snapd binary or anything
<mup> PR snapd#3375 opened: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>
<ogra_> mvo, hmm, that might be a bit tricky ... i could indeed re-pack the core snap with a new snapd but then i cant easily test auto-upgrades, perhaps we could try to just land the PR tomorrow morning with the option to roll back immediately
<ogra_> (snap refresh manually or a sideload will likely not expose the issue, i usually only see it with auto-upgrade)
<adfad666> ogra_: I found the instructions in pi3-gadget, but they're _not_ in the pi2-gadget readme :)
<ogra_> adfad666, ahm, thanks for the hint, i'll add them there too (the u-boot binaries are actually identical in booth)
<ogra_> *both
<mvo> ogra_: sounds good, it should definitely not hurt (the extra code)
<ogra_> mvo, yeah
<ogra_> i'll ping you tomorrow and we can coordinate some testing (nothing for this evening IMHO)
<mup> PR snapd#3376 opened: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376>
<pedronis> pstolowski: does snapd#3376 look right ?   (doesn't seem we test the single codes)
<mup> PR snapd#3376: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376>
<mvo> ogra_: thanks, sounds good
<pstolowski> pedronis, yes, looks fine, that's the central place that drives all retry loops
<pedronis> mvo: all my main 2.27 PRs are up
 * Chipaca leaves spread running and goes to scrounge up some tea
 * Chipaca fails, tries again
<niemeyer> Lunches
<pedronis> fgimenez: linode:ubuntu-16.04-32:tests/main/create-key timeout :  https://travis-ci.org/snapcore/snapd/builds/234847301
<fgimenez> pedronis: thanks! looking
<Chipaca> just got another 504
<pedronis> Chipaca: there's a PR now
<Chipaca> :-(
<pedronis> Chipaca:  if it helps:  snapd#3376
<mup> PR snapd#3376: store: retry on 504 too <Created by pedronis> <https://github.com/snapcore/snapd/pull/3376>
<Chipaca> each of these retries hurts responsiveness
<Chipaca> a retry on a 504, more so
<Chipaca> :-(
<Pharaoh_Atem> morphis: in re http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/commit/redhat-hardened-ld?id=b1a45b244ea644b78b0f626643758a05c0f049b5
<Pharaoh_Atem> keep in mind that you're going to have a hard time static linking pre-F26 anyway
<Pharaoh_Atem> and even in F26 itself, since we don't have a lot of static link libraries to begin with
<fgimenez> pedronis: i've already copied the build log, feel free to retrigger if needed
<pedronis> thx
<zyga> re
<zyga> pstolowski: the outside part can be anything, I just meant the 45/44 hardcoded things vs a struct with that hardcoded thing
<pstolowski> zyga, hmm i see. why struct?
<zyga> pstolowski: just a type, could be a typedef as well
<cachio> niemeyer, I am running on this linode:ubuntu-14.04-64:tests/ , is that ok?
<niemeyer> cachio: Yeah, it's okay
<niemeyer> cachio: Only thing to watch out for is that once the process started, you'll have machines allocated
<niemeyer> cachio: Make sure to discard them once the test is over
<niemeyer> cachio: Otherwise spread elsewhere will need to collect them, and it'll only do that after 2h
<niemeyer> cachio: spread -reuse allows you to keep the same machines for longer, useful if you're running one or a few tests over and over
<cachio> niemeyer, should I discard them manually?
<niemeyer> cachio: Yes, if you've allocated them and don't need them anymore, please do discard them
<cachio> niemeyer, ok
<niemeyer> cachio: If you haven't used -reuse, spread will keep a list of the used machines even then, and print out the command you need to run for discarding them
<cachio> niemeyer, ok, thanks for the heads up
<niemeyer> cachio: np
<niemeyer> cachio: The spread docs in the GH project is also pretty comprehensive if you need more insight into a particular feature
<niemeyer> s/is/are/
<zyga> cachio: also feel free to ask any one of us for help :)
<cachio> niemeyer, zyga great, thanks
<niemeyer> Yeah, sorry, that wasn't a tentative to drop further questions :P
<mup> PR snapd#3377 opened: asserts: simplify and adjust repair assertion definition <Created by pedronis> <https://github.com/snapcore/snapd/pull/3377>
<mup> PR snapd#3378 opened: tests: fixes for executions using the staging store <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3378>
<mup> PR snapd#3367 closed: many: cleanup MockCommands and don't leave a process around after hookstate tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3367>
<morphis> Pharaoh_Atem: true, but we can't change our snap-confine build setup easily right now so best is the keep it this way if there are no objections from your side
<Pharaoh_Atem> I'm probably not going to drop the patch we use in Fedora, as I'd rather not maintain the flags locally
<Chipaca> ogra_: https://github.com/snapcore/snapd/pull/3369/files#diff-1c49786329169770afff179a078fd8f1L114
<mup> PR snapd#3369: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369>
<Chipaca> and now i need an aspirin
<morphis> Pharaoh_Atem: we can't ship it upstream either as it breaks the static build we have for other platforms
<morphis> Pharaoh_Atem: however this is a bug in the linker script provided by Fedora as it break static builds (even if there are not many static libs we can link with)
<Pharaoh_Atem> well, the build fails even if we attempted static link
<ralsina> Hi! Question: I am snapping a largish python app, and it brings a ton of uneeded files, which make the snap almost 80MB. I know I can delete a bunch of them and bring it down to half size. Is there any support in snapcraft for removing files before snapping?
<Pharaoh_Atem> since libcap-static doesn't exist
<morphis> Pharaoh_Atem: the build succeeds but it links libcap dynamically with the change I did above
<ralsina> Specifically, just removing useless .a files from static libraries cuts down 35MB in the final snap
<ogra_> Chipaca, elegant!
<morphis> Pharaoh_Atem: https://paste.fedoraproject.org/paste/5v-vkBtY0mnerN~IgVOphF5M1UNdIGYhyRLivL9gydE= -> that is with snapd master from minutes ago
<zyga> Chipaca: do you know why the latest core snap is from 18th?
<niemeyer> zyga: Do you have a moment for a quick call?
<zyga> niemeyer: yes
<Chipaca> zyga: npi
<niemeyer> Cool, let's go to the standup please
<Chipaca> niemeyer: wrote something for the report, but nothing is particularly newsworthy imho
<Chipaca> (so if you decide to ignore my contribution I'd be relieved :-) )
<niemeyer> Chipaca: :D
<niemeyer> Chipaca: Thanks!
<mup> PR snapd#3355 closed: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3355>
<morphis> zyga: ok to merge https://github.com/snapcore/snapd/pull/3274 ?
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<lutostag> launchpad builders failing for others with 'cannot run ssh: No such file or directory'? http://pastebin.ubuntu.com/24625153/ full build log @ https://launchpadlibrarian.net/320734938/buildlog_snap_ubuntu_xenial_amd64_weebl-tools_BUILDING.txt.gz
<lutostag> (from a launchpad hosted git repo)
<mup> PR snapd#3376 closed: store: retry on 504 too <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3376>
<cjwatson> lutostag: You can't use git+ssh - the builders don't have SSH keys
<cjwatson> lutostag: I'm afraid snap builds from private repositories aren't currently supported
<lutostag> cjwatson: https://code.launchpad.net/~lutostag/+snap/weebl-tools/+edit (how do I create a snap package for an already existing git repo from lp then)? should the protocol default to https rather than git+ssh for them?
<lutostag> https://code.launchpad.net/~weebl-maintainers/weebl-tools/+git/weebl-tools/+ref/master I don't think is private...
<cjwatson> It would if https were supported for private repositories yet
<cjwatson> lutostag: But that's not the repository you're trying to build from here
<Chipaca> and *another* 504
<Chipaca> grr grr grr
<cjwatson> Or at least, the part in question
<cjwatson> The problem is https://git.launchpad.net/weebl-tools/tree/snap/snapcraft.yaml#n19
<pedronis> Chipaca: IÂ merged the retry branch now (if it helps)
<lutostag> cjwatson: indeed, that would be it. Thanks! (also congrats on the spotlight)
<cjwatson> lutostag: thanks :)  sorry this isn't supported yet; it's possible but would probably be a month or so of work.
<cjwatson> maybe a bit less given some of the work on git-to-git imports which picked off some of the infrastructure dependencies.
<lutostag> cjwatson: yeah, private ppas never had building either, so at least its not missing functionality compared to ppas, just the error message threw me off
<cjwatson> lutostag: Private PPAs have builds, but maybe you mean recipes
<lutostag> yeah that one :)
<cjwatson> lutostag: In which case that's indeed true, and for similar reasons
<cjwatson> Basically need a way to dispatch scoped auth tokens to builders; in the snap case we also need to sort out a privacy model for snaps
<lutostag> cjwatson: no worries, easy enough to snapcraft locally. Forgot about our 'private' dep. appreciate it
<zyga> morphis: looking
<zyga> morphis: if niemeyer looked at that and approved, sure, let me see
<morphis> zyga: he did but before the rework but said he is fine if I do what he suggested
<zyga> done :)
<morphis> great!
<morphis> another bit merge :-)
<mup> PR snapd#3274 closed: cmd/snap,tests/main: add confinement switch instead of spread system blacklisting <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3274>
<kyrofa> Chipaca, from the store
<kyrofa> ?
<Chipaca> kyrofa: yeap
<Chipaca> have been hitting a bunch of them todya
<Chipaca> hence the growling and groaning
<kyrofa> I hit soo many last week
<mup> PR snapd#3379 opened: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/3379>
<mup> PR snapd#3380 opened: cmd/snap,tests: show the sha3-384 of the snap for snap info --verbose SNAP-FILE <Created by pedronis> <https://github.com/snapcore/snapd/pull/3380>
<cachio> niemeyer, do you use -reuse to run the tests in ci?
<cachio> I see that $GOPATH is not being cleaned and it is making a test failed when -reuse is used
<niemeyer> cachio: Depends on what I'm working on.. if I'm trying something several times, yeah, definitely as it saves quite some time
<mup> PR snapd#3381 opened: logger (& many more, to accommodate): drop explicit syslog <Created by chipaca> <https://github.com/snapcore/snapd/pull/3381>
<ogra_> abeato, on what HW do you test all this androidboot stuff ? dragonboard ?
<mup> PR snapd#3382 opened: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <https://github.com/snapcore/snapd/pull/3382>
<abeato> ogra_, it is a qualcomm device, 4 years old iirc
<abeato> ogra_, Qualcomm SnapdragonTM 600 (APQ8064) 1.7 GHz quad KraitTM CPU
<zyga> re
<ryebot> I'm running into this issue on 2.25, even though it was supposed to be fixed in 2.25: https://bugs.launchpad.net/snappy/+bug/1687079
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<ryebot> Here's my logs: http://paste.ubuntu.com/24625861/
<ryebot> Any suggestions for debugging/working around?
<ryebot> Ah, before I forget to mention - this is in an lxc.
<zyga> ryebot: looking
<ryebot> ty
<zyga> ryebot: can you tell me what does snap version say?
<zyga> ryebot: specifically about your kernel
<ryebot> yes one moment
<ryebot> zyga: http://paste.ubuntu.com/24626012/
<zyga> ryebot: aha, so this is on a stock ubuntu kernel, hmm hmm
<zyga> ryebot: container support requires an interplay of both lxd, snapd and kernel features
<zyga> ryebot: but it seems this combination should work
<ryebot> zyga: I think it works if I restart the container
<ryebot> at least, that's what has been reported to me, haven't tried it myself
<zyga> ryebot: are you the reporter of bug https://bugs.launchpad.net/snappy/+bug/1687079 ?
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<ryebot> I am not
<zyga> ryebot: can you try one more thing
<zyga> export SNAP_CONFINE_DEBUG=yes
<zyga> and run the command you wanted to run just a moment ago
<ryebot> hmm
<ryebot> this is a service
<zyga> aha
 * ryebot thinks
<zyga> but
<zyga> try hello-world snap
<ryebot> okay
<zyga> if the service fails this should fail the same way
<ryebot> I'll try without export first?
<zyga> sure
<zyga> though with export you'll get more data
<ryebot> hello world worked fine
<zyga> hmm hmm
<zyga> interesting
<zyga> what was the service?
<zyga> and can you look at journalctl and look for something obviously wrong?
<ryebot> sure, it was the etcd snap
<zyga> ah
<ryebot> here's the logs: http://paste.ubuntu.com/24625861/
<zyga> is that a classic snap?
<zyga> classic confinement snap
<ryebot> let me double check
<zyga> when you installed it, did you use --classic switch?
<ryebot> it's not classically confined
<ryebot> stric confinement
<ryebot> strict*
<zyga> ryebot: is that what snap list / snap info say as well?
<zyga> stgraber: ^^ any ideas? (snapd fails in lxd)
<ryebot> zyga: hmm, maybe not? http://paste.ubuntu.com/24626094/
<ryebot> ^ not sure how to interpret that
<zyga>   ingest/stable: ingest-0.5 (12) 4kB  classic
<ryebot> yeah
<zyga> can you show me "snap changes"
<ryebot> sure one sec
<ryebot> http://paste.ubuntu.com/24626099/
<zyga> ryebot: how about "snap change 2"
<ryebot> learning all kinds of tricks! http://paste.ubuntu.com/24626116/
<zyga> hmm hmm
 * zyga thinks
<Chipaca> zyga: those 'cannot connect core' messages are my most favourite feature
<ryebot> zyga: ah dang, it may very well be being installed as classic
<zyga> Chipaca: I'm glad we removed those
<ryebot> zyga: https://github.com/juju-solutions/layer-etcd/blob/master/reactive/etcd.py#L257
<Chipaca> zyga: yeah
<ryebot> ^ from our charm code
<Chipaca> zyga: (also: "snap tasks" :-) )
<ryebot> let me find out why :\
<zyga> aha
<zyga> interesting
<zyga> ryebot: can you pastebin /var/lib/snapd/seccomp/profiles/snap.etcd.etcd
<zyga> that's an easy way to check if it is classic or not
<ryebot> zyga: http://paste.ubuntu.com/24626160/
<zyga> yes
<zyga> that is classic!
<zyga> but
<zyga> Chipaca: ^^
<zyga> the thing that puzzles me
<zyga> is that this snap probably doesn't want classic
<zyga> ryebot: at which revision are you now?
<zyga> ryebot: (snap list says this)
<ryebot> 55
<zyga> ok
<zyga> so
<zyga> to fix this
<zyga> drop the classic=True
<zyga> Chipaca: ^^ we install things as classic even though they don't want that!
<Chipaca> zyga: pardon?
<zyga> Chipaca: one sec
<zyga> sudo snap install --classic hello-world
<zyga> why is that even working!?
<zyga> Chipaca: this then gets installed as classic
<Chipaca> well, you did just tell it to
<zyga> Chipaca: but snap list doesn't say this
<ryebot> zyga: Okay awesome, I'll give it a shot, thanks :)
<zyga> Chipaca: but the snap is not compatible with this at all (hello-world works by accident)
<zyga> Chipaca: it must fail
<Chipaca> zyga: I suspect you have more restrictions on the mode flags in your mind than we have in the code
<Chipaca> zyga: torum fopic!
<zyga> Chipaca: yes
<zyga> Chipaca: that's a good idea :)
<Chipaca> zyga: spoonerisms always are
<pedronis> so --classic is its own --jailmode? otoh classic snaps are very special so there is some logic to zyga's worry
<Chipaca> yeaup
<Chipaca> anyway. Why am I on IRC and not having beer and tinkering with stuff.
<cachio> zyga, do you have any flaky which I could take a look
<cachio> zyga,  I just found 2 after many executions
<zyga> cachio: hey
<zyga> cachio: yes, many
<zyga> cachio: look at ...
<cachio> zyga, good
<zyga> well
<zyga> first of all, look at https://github.com/snapcore/snapd/pulls
<zyga> all the red PRs are good candidates
<zyga> open first batch (say, first three)
<zyga> then look at the one with failing tests there
<zyga> (each PR has autopackage tests as well as travis run that uses spread to test various distributions on x86 and x86_64)
<zyga> e.g. looking at https://github.com/snapcore/snapd/pull/3382 I can see that some tests failed
<mup> PR snapd#3382: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <https://github.com/snapcore/snapd/pull/3382>
<zyga> then looking there I can see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170522_200637_17c34@/log.gz
<zyga> scroll to the bottom
<zyga> this tells me that autopkgtest:ubuntu-17.10-amd64:tests/main/refresh-core-with-hanging-configure-hook failed
<zyga> look at the various branches and see if something fails frequently
<zyga> sometimes master is broken and all the tests fail the same way
<zyga> e.g. today this broke https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170522_172242_a32b2@/log.gz
<zyga> the format of the version string printed by "snap --version" has changed
<zyga> and it failed universally everywhere
<zyga> when that happens it is good to get the fix merged ASAP (it's done for this case)
<zyga> and then merge master into all the open PRs
<zyga> we can push changes to PRs that are open, even if someone else made them
<zyga> our spread setup does not use a queue so we must not overload the pool of available machines
<zyga> you'll see when that happens, machine allocations will time out and fail
<zyga> anyway
<zyga> it is good to do when most of europe is away already as spread is very idle then
<zyga> and we can have fresh results in the morning
<zyga> let me know if you have questions about anything
<zyga> I'll let you know if I see something that ought to work
<zyga> but it's also good to be proactive and chase things
<cachio> zyga, ok I'am taking a look to that list
<zyga> cachio: I opened this forum thread a while ago https://forum.snapcraft.io/t/chasing-unreliable-tests/158
<cachio> zyga, nice
<cachio> zyga, is it better either to create a thread with errors to discuss or to raise issues in lp?
<cachio> zyga, how do you usually do that
<cachio> ?
<zyga> cachio: I think forum works better, lp lacks text formatting
<zyga> cachio: I virtually stopped using bugs
<cachio> zyga, good
<mup> Bug #1676928 changed: snap shell can't reach $SNAP_USER_DATA: Permission denied <cdo-qa> <Snapcraft:Invalid> <Snappy:Confirmed> <https://launchpad.net/bugs/1676928>
<mup> Bug #1607710 changed: Home directories listed in /etc/passwd should be honoured <cpc> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<nacc> is there any guidance on LP: #1575593 for a classic snap? I really don't want to add a configure hook for the manpage in my snap until uninstall hooks are present. And cjwatson's c#4 only sort of works in that (afaict), I don't control where in $SNAP my files get placed. Specifically, if the command is invoked as /snap/bin/git-ubuntu, I don't think I can put whatever I want in /snap/ ... my snap's file are
<mup> Bug #1575593: Snappy installed manpages aren't accessible through man <snapd:Triaged> <https://launchpad.net/bugs/1575593>
<nacc> elsewhere in /snap and bin is just symlinks
<zyga> nacc: sorry, too tired to think and respond tonight
<zyga> nacc: I'm working on something that _may_ enable man pages
<zyga> nacc: but not soon (think 2 releases at least)
<nacc> zyga: ok, np -- even workarounds that are reasonable for a bit is what i'm looking for
<nacc> zyga: as, by default, `git ubuntu --help` runs `man git ubuntu`
<nacc> hrm, also, can a snapd developer subscribe and help resolve degraded services in containers in LP: #1576341? Not sure who is best to subscribe to the bug myself
<mup> Bug #1576341: systemd in degraded state on startup in LXD containers <amd64> <apport-bug> <patch> <uec-images> <xenial> <lvm2 (Ubuntu):Fix Released by nacc> <lxd (Ubuntu):Invalid> <open-iscsi (Ubuntu):Fix Committed by nacc> <systemd (Ubuntu):Fix Released by xnox> <https://launchpad.net/bugs/1576341>
<kyrofa> cjwatson, can I publish snaps to branches in LP?
<nacc> kyrofa: do you mean the other way around?
<nacc> kyrofa: publish a snap off a branch specifically (rather than master, say)?
<kyrofa> nacc, no snaps have a relatively new feature called branches
<kyrofa> nacc, https://forum.snapcraft.io/t/channel-terminology-and-policy
#snappy 2017-05-23
<nacc> kyrofa: of course they do :)
<kyrofa> nacc, they're essentially dynamically-created channels. Perfect for creating a snap of "this" pull request
<kyrofa> nacc, they're ephemeral, though, and expire after a month
<nacc> kyrofa: ah i see
<kyrofa> (unless published to again)
<nacc> kyrofa: interesting, will read up on it tmrw
<nacc> kyrofa: snaps feel like such a moving target  sometimes :)
<kyrofa> nacc, yeah I feel ya
<Chipaca> oooh, i think i know how to make the keygen tests quicker
<kyrofa> Chipaca, what the heck man, were you asleep and awoke with a genius idea?
<Chipaca> â¦ don't we all?
<kyrofa> Yes :P
<Chipaca> kyrofa: also, manchester explosion has me woke
 * kyrofa googles manchester explosion
<kyrofa> Dang
<kyrofa> Chipaca, you're not close, I hope
<Chipaca> nor is any of my family as far as i know
<kyrofa> Good
<Chipaca> need to check with samuele wrt sanity, but this makes the key generation step of the tests ~20Ã faster
<mup> PR snapd#3383 opened: Fix spread flaky tests linode <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3383>
<mup> PR snapcraft#1327 opened: tests: small updates for manual kernel tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1327>
<elfgoh> I had a question regarding sanitisation of snap interfaces: https://forum.snapcraft.io/t/sanitisation-of-snaps-requested-interfaces/739
<mup> PR snapd#3382 closed: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3382>
<mup> PR snapd#3379 closed: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3379>
<mup> PR snapd#3226 closed:  snap-repair: add `snap-repair run`  <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3226>
<zyga> good morning
<zyga> mvo: hey
<zyga> mvo: just to give you some more context for my message yesterday
<zyga> mvo: gustavo reviewed the way we convey meta-data for interfaces and wanted to make some changes
<zyga> mvo: we had a quick brainstorm session and the bottom line is that the current rest API has to be reverted to what it was before meta-data layer was merged
<zyga> mvo: and the meta-data must move to a new endpoint "interface" (vs "interfaces" currently)
<zyga> mvo: I will work on this and the CE blocker today
<zyga> mvo: when do you plan to release?
<morphis> zyga: morning!
<zyga> morphis: good morning
<pstolowski> morning
<palasso> Hello, I'm not following snap development closely. I'm wondering on why the OS snap ubuntu-core was renamed to core?
<morphis> mvo, zyga, pedronis, Pharaoh_Atem, niemeyer: can you guys look into https://github.com/snapcore/snapd/pull/3222 again today? Would like to get that merged soon
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<pstolowski> hello palasso! this was mainly to avoid confusion about cross-distro support
<palasso> ty pstolowski for the answer
<morphis> can it be that Linode/spread is pretty unreliable these days? Trying to get a green light on a PR which touches nothing which is tested anywhere but running into a lot of timeout issues: https://github.com/snapcore/snapd/pull/3371
<mup> PR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>
<mvo> morphis: yeah, looks like it, maybe worth poking the store people about: "DEBUG: The retry loop for https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2 finished after 4 retries, elapsed time=40.008154662s, status: Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: net/http: request canceled while waiting for connection (Client
<mvo> .Timeout exceeded while awaiting headers)"
<mvo> morphis: 40s and 4 retries is a pretty long wait
<fgimenez> hi morphis in that build you had a lot of connectivity problems, seems that between linode instances and the store, at least two "dial tcp 162.213.33.92:443: getsockopt: no route to host" (162.213.33.92 is public.apps.ubuntu.com), "dial tcp 162.213.33.92:443: i/o timeout", timeouts awaiting for headers from assertions.ubuntu.com, the tests/main/completion error seems to be related to connectivity too, maybe the store was down or all the instances
<fgimenez> involved (more than one had errors) lose connection
<morphis> yeah
<morphis> is pretty nasty and it looks like I am getting similar problems with all my PRs
<morphis> mvo: what is a good place to poke on the store people?
<cjwatson> kyrofa: not yet; at the time when we were adding publish-to-track support to LP, branches were only defined for stable, and automatic jobs shouldn't be publishing directly to stable.  Some of the assumptions here may have changed since though
<zyga> re
<zyga> geez, firefox ate 3GB of ram on 4 tabs open
<pedronis> my 2.27 PRs need reviews
<Chipaca> pedronis: hiya
<mup> PR snapd#3384 opened: tests: use pollinate to seed the rng <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3384>
<fgimenez> hi Chipaca, could you please take a look at ^^^? never use pollinate before, seems to be working fine with a plain call
<Chipaca> fgimenez: yup
<Chipaca> fgimenez: i also want to check with samuele about what happens if we use a gpg in testing that clamps keys to 1024 bits
<fgimenez> Chipaca: great thanks!
<pedronis> Chipaca: where? we check that the keys we get have the expected length
<Chipaca> pedronis: we do? where?
<Chipaca> snap create-key seemed to be happy with them
<Chipaca> pedronis: good morning!
<pedronis> Chipaca: well, when you try to sign with it, it won't (maybe that test doesn't use the key it makes, but as a general strategy across all tests doesn't work)
<pedronis> Chipaca: here,  https://github.com/snapcore/snapd/blob/master/asserts/crypto.go#L367
 * Chipaca pokes at his internet
<Chipaca> pedronis: sadface
<Chipaca> pedronis: maybe i should override gpg and then un-override it when tests break :-)
<pedronis> Chipaca: override it with what anyway ?
<Chipaca> pedronis: sed and more gpg :-)
<pedronis> Chipaca: anyway we do have  a snap-sign test
<morphis> zyga: step 1, CI passes on https://github.com/snapcore/snapd/pull/3365 :-)
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<Chipaca> pedronis: yeah, that's the one i was poking around in last night
<pedronis> Chipaca: which funnily IÂ never seen fail
<Chipaca> pedronis: oh, i did
<Chipaca> pedronis: I'd point you at https://s3.amazonaws.com/archive.travis-ci.org/jobs/234990914/log.txt?X-Amz-Expires=30&X-Amz-Date=20170523T012508Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170523/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=2f9a55bec2d1b61a8c23f3b46d7c955155fc8e2f719cb66e788743bc7181c36a but travis has already been "helpful"
<pedronis> Chipaca: anyway what you could do is merge create-key into snap-sign
<pedronis> so you need less overall entropy
<Chipaca> pedronis: the entropy doesn't seem to be the problem afaict
<pedronis> Chipaca: what is the problem then?
<Chipaca> pedronis: at least, every time i've looked we've had ~3k of entropy
<pedronis> doesn't compute
<pedronis> why would create-key take forever if not that
<Chipaca> pedronis: I'm guessing here but we might be getting penalized
<Chipaca> for heavy cpu use
<pedronis> anyway my point stand
<Chipaca> yep
<pedronis> we would use less CPU if we create less keys :)
<Chipaca> don't get me wrong, we might also be running out of entropy
<Chipaca> and i think we need to add that to the debug output
<Chipaca> so we can see
<Chipaca> (also to the regular output! but that's going to be harder)
<pedronis> Chipaca: so mergeing  snap-sign create-key  and the key completion test into one
<ogra_> [   12.818573] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock
<ogra_> [   12.829425] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock
<ogra_> hmpf
<ogra_> i wonder if we cant quieten f2fs on a kernel level
<Chipaca> augh
<Chipaca> who writes that code :-(
<Chipaca> who writes "%dth" and thinks that's a good idea
<ogra_> someone who doesnt know about english numbering ?
<Chipaca> but then there's like 5 other people that looked at that code and thought "fine whatever" and let it pass :-/
<ogra_> yeah
<Chipaca> anyway
<Chipaca> always too easy to criticise other projects
 * Chipaca shuts up
<ogra_> well, i'm sure whatever code there is probes all possible filesystems ... but only f2fs prints that stuff
<ogra_> apw, do you think we could quieten such f2fs messages ?
<apw> ogra_, why do you care about two lines in your dmesg ?
<Chipaca> apw: users (actually, device developers) see them and freak out
<apw> ogra_, and indeed what is triggering them from userspace
<ogra_> apw, dunno, i'm german :P
<apw> Chipaca, i think device developers need to develop thicker skin :)
<ogra_> apw, snapd checks all attached non rootfs devices for possible snap assertions on boot ... so it mounts them once ...
 * apw sticks several fingers in each of his ears ...
<ogra_> apw, we used to include ramdisks in that... when we did that i have about 30 of these messages ... now i get them for the one atttached usb device only ... but still only f2fs (which we never used) prints that stuff
 * Chipaca wonders how apw types with several fingers in several ears
<ogra_> s/i have/i had/
<apw> Chipaca, with my feet, the only way
<Chipaca> pedal keyboards ftw
<apw> ogra_, surely we do not try all the possible filesystem types though
<apw> ogra_, that way lies _vast_ attack surface
<ogra_> apw, well, we just call mount i guess ... the rest is kernel
<ogra_> (or internal logic of mount)
<apw> ogra_, they kernel does not guess you filesystem type, that would be mount
<Chipaca> ogra_: do we explicitly load f2fs?
<ogra_> Chipaca, nope
<apw> ogra_, so what is on that stick which triggers that error
<ogra_> Chipaca, i think it is compiled in
<Chipaca> ogra_: at least here it's a module
<ogra_> apw, a vfat fs
<Chipaca> dunno on other arches etc
<apw> ogra_, ie what does blkid say on it
<ogra_> Chnot in xenial
<ogra_> Chipaca, ^
<apw> as one would expect mount to ask what it is and then mount that specific type
<Chipaca> ogra_: chtotally in xenial
<ogra_> ogra@pi3:~$ lsmod|grep f2fs
<ogra_> ogra@pi3:~$ grep f2fs /proc/filesystems
<ogra_> 	f2fs
<ogra_> ogra@pi3:~$
<ogra_> ogra@pi3:~$ sudo blkid /dev/sda1
<ogra_> ogra@pi3:~$
<ogra_> bah
<ogra_> /dev/sda1: UUID="72AD-5403" TYPE="vfat" PARTUUID="7524a7a6-01"
<ogra_> silly IRC
<Chipaca> ogra_: try: modinfo f2fs
<apw> heh, so why the heck is f2fs being used against it
<ogra_> apw, dunno, why was it being used on all the ramdisks before
<apw> ogra_, can you manually try mounting it with mount /dev/sda2 /mnt
<ogra_> this isnt new or anything ...
<apw> and with mount -t vfat /dev/sda2 /mnt
<apw> sort of thing
<apw> and see if the latter is quieter
 * apw would suggest we should be using blkid and only attempting to mount if it is one of a very very limited set of formats, ones we are willing to work hard to keep security good on
<apw> else i could format it as some utterly nasty format and you will mount it, w
<apw> which is just asking to be attacked
<apw> i would vote for one format if i was involved, perhaps vfat
<ogra_> apw, neirther mount nr mount -t vfat print anything
<apw> ogra_, nothing in dmesg you mean ?
<ogra_> right
<apw> then you have a new mystery, who the heck is triggering that
<apw> are you using some magical go helper
<ogra_> pedronis, mvo, ^^^ does snapd rotate over filesystems when mounting a device to lok for assertions ?
<ogra_> *look
<pedronis> no clue, that's really for mvo
<zyga> re
<zyga> morphis: that's great :)
<zyga> I need to catch up with PRs but first I need to prepare two important things for 2.27 for mvo
<ogra_> looks like this is the mount code https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_auto_import.go
<morphis> zyga: do that
<ogra_> cmd := exec.Command("mount", "-o", "ro", "--make-private", deviceName, tmpMountTarget)
<ogra_> nothing fancy regarding filesystems
<zyga> hmm hmm
<zyga> those are two distinct mount syscalls AFAIK
<ogra_> because of the --make-private ??
<zyga> yes
<zyga> first you do mount -o ro deviceName tmpMountTarget
<zyga> then mount --make-private
<zyga> it's not atomic
<zyga> (mount-the-command does that internally)
<ogra_>  mount(8)  does  not  read  fstab(5)  when a --make-* operation is requested.  All necessary information has to be specified on the command
<ogra_>               line.
<ogra_> hmm
<Chipaca> how do you un-duplicate a bug?
<ogra_> Chipaca, iirc somewhere in the target bug
<Chipaca> ah
<mvo> ogra_: I'm not sure what rotate over filesystems means, but it does look at block devices for assertions, yes
<mvo> apw: aha, just finished reading backlog - sure, we can make this smarter to only mount ext{2,3,4} and vfat or maybe even only vfat
<zyga> mvo: we may even do more, register a GUID
<zyga> mvo: that is unique to snapd
<mup> PR snapd#3385 opened: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
<zyga> mvo: (not partition ID, but partition *type* ID)
<zyga> mvo: then you can make a stick, with any filesystem, and snapd will recognize it
<apw> zyga, you don't want it to support "any" anything, if any device will mount and consume it on b
<apw> zyga, boot.  that is just asking for people to exploit every possible filesystme bug
<zyga> (you can still add extra requirements, but the guid makes it distinct even before we mount it)
<mvo> zyga: maybe, but OTOH anything that makes it harder for people to use this feature is not ideal IMO, I like the simplicify of the current: grab random-usb-stick, copy file, done
<zyga> apw: I agree
<zyga> mvo: it all depends on tooling
<apw> easy is the antithisys of secure
<mvo> zyga: well, yes, but its still at least one extra step: find the right tool for your $OS, download, run
<zyga> mvo: more like "make disk image" website
<mvo> apw: you think even limiting to vfat would be an issue?
<zyga> mvo: but I agree
<apw> mvo, i would cirtainly recommend limititing it to something vfat might be that thing
<mvo> apw, zyga: once I finished with my current branch I will do that then
<apw> mvo, though i would ask the security team for a recomendation if anything
<mvo> apw: good point
<mup> PR snapd#3386 opened: interfaces, osutil: move flock code from interfaces/mount to osutil <Created by mvo5> <https://github.com/snapcore/snapd/pull/3386>
<mup> PR snapd#3387 opened: cmd: auto import assertions only from vfat file systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/3387>
<zyga> mvo: thank you for moving the flock code
<mvo> zyga: thanks for writing it :)
<zyga> mvo: what is the `wrong prefix` test from?
<zyga> ah
<zyga> I misread
<zyga> that's just a comment
<ogra_> mvo, s/rotate/loop/ :)
<ogra_> apw, still though, why do the fs drivers print such stuff at all ... this is similar to the ext2/3 messages you get when mounting an ext4 fs, that also spills a lot scary messages
<ogra_> i.e.
<ogra_> [    6.720679] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
<ogra_> [    6.729695] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
<ogra_> [    6.755923] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: errors=remount-ro
<pstolowski> guys, i've a longer power outage today. i'm using my cellphone as a hotspot, but going for a lunch now and will be offline for ~1h
<apw> ogra_, so that you can diagnose why a mount fails, as all you get in user space is EINVAL
<ogra_> hmm
<apw> they are not scarey they are informative and useful if a mount you intended to make fails
<ogra_> they are scary for someone not understanding them
<apw> someone not understanding them is unlikely to be able to find them
 * ogra_ had enough bugs from users that got confused by these messages over the years
<apw> that is why they are not on the screen, but in a hidden kernel buffer
<apw> yes users will always find somethign to be confused about, but in this context it is unlikely a user can even see this buffer
<ogra_> dmesg shows it prominently as does syslog and the kern.log file
<ogra_> so if an illiterate user has a prob he looks at it and reacts with "OMG filesystem errors" ...
<apw> few illiterate users know about any of those logs, or how to find them
<ogra_> well
<apw> and a semi-literate user will always be scared by everything
<apw> and if you don't record them, their literate friend they go and ask
<apw> will have literally nothing to work with
<ogra_> heh, k
<apw> computer equipement should have "no user servicable parts" on the front :)
<ogra_> lol
<apw> we log a lot more of that kind of thing than necessary because we are lazy in usersapce and
<apw> try things because we know the kernel will fail to do things which are silly
<apw> instead of only asking it to do things we want to do
 * apw goes back to punching docker repeatedly wishing it _would_ log something useful
<Chipaca> apw: punch harder?
<apw> if only i could punch it hard enough
<Chipaca> maybe a hydraulic punch
<mup> PR snapcraft#1328 opened: qmake plugin: set default qt version <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1328>
<pedronis> mvo: made a comment about snap-reapir branch, my explanation yesterday might have been confused, I still owe to update the forum entry
<pedronis> s/confused/confusing/
<Chipaca> pedronis: I requested changes on one of your PRs, so it all evens out
<pedronis> Chipaca: seems we have not tests for snap info directory fwiw
<Chipaca> pedronis: there are
<Chipaca> pedronis: just not with --verbose
<pedronis> so we have no ---verbose tests?
<Chipaca> certainly none for ---verbose :-p  and only a rather bare local check for --verbose
<Chipaca> wait
<Chipaca> taht might be yours
<Chipaca> :-)
<Chipaca> so, no, no tests for --verbose
<pedronis> Chipaca: I added it
<Chipaca> pedronis: yeah
<Chipaca> pedronis: any reason not to also show the sha3 for remote snaps in info?
<pedronis> Chipaca: we don't have that info around
<pedronis> ah remote ones
<Chipaca> pedronis: it's in DownloadInfo
<pedronis> but not locals?
<Chipaca> pedronis: Â¯\_(ã)_/Â¯
<pedronis> because that needs thinking, if we want local too
<Chipaca> it's strange that we don't store it in state
<Chipaca> i guess it's somewhere in the asserts db?
<pedronis> it's in the assert db
<Chipaca> thinking is hard
<Chipaca> let's have lunch
<Chipaca> pedronis: to be clear, i'm not saying this is in any way a blocker to the pr you have up
<Chipaca> but every time i look at snap info i want to make it better :)
<Chipaca> and then i remember making it better starts by looking at goyaml
<pedronis> Chipaca: anyway that's not a snap info problem, we need to think how to put the ash back into api.go
<pedronis> then info is easy
<Chipaca> yup
<pedronis> there's remote, local unasserted, and local asserted
<pedronis> to consider
<_28Kb> why there's no php7 server snap?
<Chipaca> _28Kb: what's a php7 server?
<_28Kb> like one in XAMPP
<Chipaca> _28Kb: I don't think there's a reason
<mup> PR snapcraft#1329 opened: tour: use https for source urls <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1329>
<Chipaca> mvo: have you seen the travis error on snapd#3374?
<mup> PR snapd#3374: partition: add directory sync to the save uboot.env file code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3374>
<_28Kb> i need apache, php and mysql for my ubuntu core..
<Chipaca> mvo: (hint: it goes âcan't load package: package github.com/mvo5/uboot-go/uenv: [...]â)
<_28Kb> i got only this nextcloud option offered
<Chipaca> _28Kb: out of curiosity, why do you need a snap with these things?
<_28Kb> i got snappy core, so i need snaps i guess
<Chipaca> _28Kb: _for what_?
<Chipaca> _28Kb: that is, you don't need a server, nobody needs a server. Servers are for building services with. What service are you building?
<_28Kb> service which i could access from outside the box
<Chipaca> _28Kb: and this is for a single box, your box, not for building a bunch of boxes that use this?
<_28Kb> through websocket for example
<_28Kb> i can't build one.. bunch is for distant future :)
<mup> PR snapd#3377 closed: asserts: simplify and adjust repair assertion definition <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3377>
<pstolowski> Chipaca, pedronis, zyga, mvo is any of you working on retry for deltas? if not, I'll do it today
<Chipaca> _28Kb: it should be fairly straightforward to build a snap like that; nobody's done it because they haven't felt the need i guess? all the needed bits are there
<pedronis> pstolowski: retry in which sense?
<pedronis> but no
<_28Kb> ok, i see
<Chipaca> pstolowski: i can confirm that I am not working on retry for deltas
<Chipaca> in fact, I'm going to start working on lunch.
<pstolowski> pedronis, ah, nvm... I thought we don't retry deltas after a quick look yesterday when we failed in the tests on travis, but looking again now and we actually do retry
<mup> PR snapd#3380 closed: cmd/snap,tests: show the sha3-384 of the snap for snap info --verbose SNAP-FILE <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3380>
<pedronis> Chipaca: about info and sha3-384, proably leaving it out for unasserted local snaps would be ok or desired, so that would make it relatively doable
<Chipaca> pedronis: well, snap info _could_ cheat and go look at the .snap in that case :-)
<pedronis> Chipaca: yes, it could but not as I said it could be argued that it doesn't make sense
<pedronis> s/but not/but/
<mup> PR snapd#3388 opened: osutil: add non-blocking flock <Created by mvo5> <https://github.com/snapcore/snapd/pull/3388>
<mup> PR snapd#3384 closed: tests: use pollinate to seed the rng <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3384>
<mup> PR snapd#3378 closed: tests: fixes for executions using the staging store <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3378>
<ogra_> mvo, hmm, your uboot change failed all tests ... something still looks for github.com/mvo5/uboot-go/uenv somewhere
<mvo> ogra_: checking
<mup> PR snapd#3389 opened: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediatey refresh try <Created by pedronis> <https://github.com/snapcore/snapd/pull/3389>
<pedronis> mvo: small PR of something IÂ mentioned/we discussed ^  (also forum https://forum.snapcraft.io/t/refresh-schedule-via-core-config/434/9 )
<mvo> zyga: any progress on the work for seccomp constants resolving (the things we talked about yesterday) btw?
<mup> PR core#47 closed: keep version Makefile in sync with version-script <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/47>
<mvo> pedronis: very nice, thanks a lot
<morphis> niemeyer: can you snapshot spread-61 as opensuse-42.2-64 when you have a minute? :-)
<dragly> Is there anything apart from the "camera" plug I need to request for camera access? I'm currently running a Qt app on a computer without a camera and get the following error:
<dragly> defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.camera"
<Chipaca> fgimenez: how much were you giggling while adding "pollinate"
 * Chipaca just realised it might be funny in Spain
<fgimenez> Chipaca: :D yes something you wouldn't hear from your grandmother
<pedronis> niemeyer: this is the PR Â I mentioned:  https://github.com/snapcore/snapd/pull/3375  (also IÂ pointed to it from aliases topic)
<mup> PR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>
<niemeyer> pedronis: Thanks for the pointer
<Chipaca> one more review wanted for snapd#3342 please
<mup> PR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>
<niemeyer> Chipaca: Will look into it too
<Chipaca> niemeyer: taw
<niemeyer> It's sad we're still blocked from using our neat state patching mechanism...
<niemeyer> It'd be nice to be able to drag comments to different lines before the review has been delivered
<Chipaca> niemeyer: as opposed to cut, delete, recomment?
<niemeyer> Chipaca: Yeah
<Chipaca> (like a caveman)
<niemeyer> Exactly :)
<Chipaca> niemeyer: drop wossisname a tweet
<niemeyer> Chipaca: Who's that?
<Chipaca> niemeyer: back when pyconar and pyconbr worked together one of the guests we brought was this github guy
<Chipaca> (i don't even know if he's still at github :-) )
<niemeyer> Chipaca: The account on Twitter seems dead
<Chipaca> ah well
<mup> PR snapd#3389 closed: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediately refresh try <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3389>
<pedronis> mvo: thanks for merging ^   it also cuts down snapstate tests to <1s (go test displayed time) here
<niemeyer> Chipaca: Reviewed
<niemeyer> pedronis: Too
<pedronis> niemeyer: thanks, saw that, trying to add the tests John asked for
<mvo> pedronis: neat
<Chipaca> niemeyer: thanks!
<mup> PR snapd#3342 closed: many: refactor in preparation for 'snap start' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3342>
<Chipaca> mvo: âsnap log -pâ ftw
<Chipaca> mvo: also https://github.com/golang/go/issues/6123
<Chipaca> (which didn't get anywhere, but that's neither here nor there)
<mvo> Chipaca: ok, if everyone is happy with TryLock I will rename it
<Chipaca> having said all this, remember: don't trust me with names :-)
<Chipaca> niemeyer: defunkt!
<mvo> niemeyer: are you ok with FLock.{Lock,TryLock} for a blocking and non-blocking file lock ?
<fgimenez> mvo: before i forget this is the error on the docker test execution https://travis-ci.org/snapcore/spread-cron/builds/235061721#L452 (only failed on amd64)
<niemeyer> mvo: As in, introducing such a type with those methods?  Didn't we have flocking somewhere already?
<mvo> niemeyer: yeah, we had blocking flock so far, we are brainstorming names for the non-blocking variant of this
<mup> PR snapcraft#1330 opened: storeapi: log download retries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1330>
<mvo> fgimenez: interessting and strange, especially if it only failed on a single arch
<niemeyer> mvo: TryLock sounds nice
<fgimenez> mvo: i'm trying to reproduce locally, will let you know how it goes
<niemeyer> mvo: perhaps FileLock rather than FLock
<mvo> niemeyer: great, I will make this happen, thanks for your input!
<niemeyer> mvo: Thanks for working on it.. are we flocking something new?
<mvo> niemeyer: yes, snap-repair
<mvo> niemeyer: we want only a single snap-repair running, this is the prereq for this
<niemeyer> mvo: Cool.. should be safe enough, assuming the snap-repair process itself doesn't get frozen for whatever reason :)
<mvo> niemeyer: yeah, that would be bad(tm)
<kyrofa> cjwatson, indeed, I only just discovered that branches only exist on stable
<Chipaca> mvo: should probably grow into something lockfileish if it's a concern
<Chipaca> as in, write the pid when locking, and then other lockers get to kill you if you take too long
<mvo> Chipaca: yeah
 * Chipaca gives reviews in bites
<pedronis> Chipaca: pushed some more tests to snapd#3375
<mup> PR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>
<Chipaca> pedronis: yep, looking now
<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#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<Chipaca> mvo: boooo to returning errno :-)
<Chipaca> (yes sure it knows its an errno so .Error() gives you "resource temporarily unavailable", but it's still 0xb)
<mup> PR snapd#3390 opened: tests: remove additional setup for docker on core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3390>
 * ogra_ is dizzy ... u-boot all around me ... 
 * zyga has food poisoning; sorry guys, will be back some other time today
<Chipaca> zyga: I ate tomato sauce that was out all night, and _you_get food poisoning?
<Chipaca> zyga: something is wrong
<morphis> niemeyer: you saw my message about labeling a spread node for opensuse?
<morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3357 now that CI passes?
<mup> PR snapd#3357: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357>
<Chipaca> niemeyer, pedronis: bug #1692866 might be something you guys can follow and have useful input on (i don't feel i can given it's juju which i know next to nothing about)
<mup> Bug #1692866: /snap/bin not in path for juju run/juju ssh <juju:Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1692866>
<niemeyer> morphis: I haven't seen it
<morphis> niemeyer: ok, here it comes again: need spread-61 tagged as opensuse-42.2-64
<niemeyer> morphis: You mean a new image snapshot out of it, right?
<morphis> niemeyer: yes
<morphis> PR for spread-images is coming now
<niemeyer> morphis: Cool, thanks. Will do that first thing after lunch.
<morphis> niemeyer: thanks!
<ogra_> Chipaca, you ate tomato sauce that went clubbing ? doesnt all that dancing turn it into "salsa" anyway ?
<Chipaca> ogra_: you're saying this as if it were a bad thing?
<ogra_> nah, not a bad thing at all
<ogra_> In file included from include/common.h:22:0,
<ogra_>                  from lib/asm-offsets.c:15:
<ogra_> include/errno.h:12:1: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âexternâ
<ogra_>  extern int errno;
<ogra_> *that* is a bad thing :(
<Chipaca> ogra_: I agree. Get your cat off your keyboard.
<ryebot> zyga: are you available to discuss that "cannot change profile for the next exec call: No such file or directory" bug from yesterday?
<ryebot> I attempted the suggested fix (no classic installation), but it's still happening
<ryebot> I also checked /var/lib/snapd/seccomp/profiles/snap.etcd.etcd (http://paste.ubuntu.com/24634459/) to see if it was indeed not being installed classically, and it seems to check out. (I assume I'm looking for the absence of @unrestricted at the top?)
<ryebot> ah, I see he's out sick
<ryebot> ^ Anyone else want to take a swing at it? :)
<Chipaca> no, but i'll take a swing at a cuppa tea
<ogra_> such a "danceish" day ...
<ogra_> swing and salsa ...
<ralsina> I have two snaps in my account I really don't care about anymore (gatertest and gatedtest) since they were used for OLS development. However, neither one has the trashcan icon to delete it. Can any of you people delete them?
<ralsina> They are https://dashboard.snapcraft.io/dev/snaps/6115/ and https://dashboard.snapcraft.io/dev/snaps/6114/
<ogra_> GRRRRR
 * ogra_ curses u-boot ... 
<ogra_> finally got 2017.01 building for the hummingborat ... now the SPL doesnt init it ... :(
<Facu> ralsina, I don't know if that's possible after they got releases...
<ralsina> Facu: hmmm ok, that's very annoying
<roadmr> make them private, then nobody will be able to see them at least
<Facu> ralsina, mmm... I have this package, with a release to edge, and I can delete it! https://dashboard.snapcraft.io/dev/snaps/7466/
<niemeyer> morphis: The image is way too large at the moment, at 2.8GB
<Facu> this one I can not delete: https://dashboard.snapcraft.io/dev/snaps/7544/
<ralsina> Facu: can't unpublish it either, or can't see how to, even when the help says I can "unpublish at any time"
<sergiusens> ralsina: have you tried `snapcraft close <snap-name> <channel>`?
<Facu> ralsina, that what sergiusens says
<ralsina> sergiusens: nevwer thought I needed to use the command line to make something go away on a website
<Facu> ralsina, I unpublished everything in https://dashboard.snapcraft.io/dev/snaps/7544/ and still can not delete it
<Facu> nessita, may you know what makes a package "undeleteable"?
<ralsina> "Your account lacks permission to close channels for this snap."
<Chipaca> Facu: somebody installing it, is what i was told way back
<Facu> Chipaca, "in the process of installing it"? mmm
<ralsina> oh, well, who cares
<Chipaca> ralsina: but since you're here
<Chipaca> ralsina: (hola!)
<morphis> niemeyer: hm
<ralsina> I'll rename them zzzzzfoo and zzzzzbar since they are in the middle of two snaps I actually care about :-P
<ralsina> hola Chipaca!
<Chipaca> ralsina: what was that about you not being able to publish to edge from travis?
<morphis> niemeyer: you killed the instance?
<morphis> ah no you didn't
<ralsina> Chipaca: not travis, build.snapcraft.io
<niemeyer> morphis: Yeah, still there
<ralsina>  Chipaca: it builds every commit, and then doesn't actually have a knob to make it release to edge
<Facu> ralsina, build.snapcraft.io pushes to edge every 'fades' release
<morphis> niemeyer: hm, looks like I forgot to do the cleanup on the new install I spawned up this afternoon after my previous one got removed
<ralsina> Facu: how?
<Facu> ralsina, don't remember doing anything special
<ralsina> Facu: the only things the UI lets you configure is the repo and the package name
<ryebot> I updated the relevant bug; if anyone could assist me with finding a fix or workaround, that would be awesome. https://bugs.launchpad.net/snappy/+bug/1687079
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<Facu> ralsina, I had something in edge before setting up build.s.io
<Facu> ralsina, does your package? maybe that's a detail?
<mup> PR snapd#3387 closed: cmd: auto import assertions only from ext4,vfat file systems <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3387>
<mup> PR snapd#3391 opened: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391>
<morphis> niemeyer: running out of time, will ping you tomorrow again
<niemeyer> morphis: Sounds good, thanks!
<ralsina> Facu: yeah, had stuff in all channels, really
<pedronis> seems timeouts are really trying to stop me from landing snapd#3375 :(
<mup> PR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>
<mup> PR snapd#3386 closed: interfaces, osutil: move flock code from interfaces/mount to osutil <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3386>
<mup> PR snapd#3357 closed: tests/lib: abstract build dependency installation a bit more <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3357>
<cachio> niemeyer, after review many errors in travis, I think basd on the errors that are causing the fails perhaps we could adopt a different strategy to deal with flaky tests
<niemeyer> cachio: That's a bit too general to correlate.. what's the issue, what's the first approach, what's the different approach, etc? :)
<niemeyer> cachio: Sounds like a forum topic.. it'll quickly go out of hand here
<cachio> niemeyer, have you ever read this post https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html ?
<cachio> niemeyer, agree with that, I'll move out to the forum
<niemeyer> cachio: We need data about what's going on.. not a blog post :)
<cachio> niemeyer, of course, i am caollecting data
<niemeyer> cachio: I suggest starting small.. take one single test that you'd like to fix and explain what is happening and how you'd like to fix it
<niemeyer> cachio: Rather than trying to solve the world at once
<cachio> niemeyer, i am doing that, but i see that some tests are failing because of external dependencies such as internet connection
<cachio> niemeyer, just to clarify, I am not saying that we dont have to fix tests
<cachio> niemeyer, I'll start a forum thread, better :)
<niemeyer> cachio: Yeah, I get it.. I'm just suggesting to start with small but solid incremental steps
<nacc> sigh, anyone else getting proxy errors for LP to the store?
<nacc> i'll wait a bit and retry, but just wondering if it's a known issue
<niemeyer> cachio: Thanks!
 * zyga feels terrible but returned to the office for his laptop
<mup> PR snapcraft#1331 opened: integrations: use the snapcore/snapcraft docker image in travis <Created by filibtester> <https://github.com/snapcore/snapcraft/pull/1331>
<pedronis> well for sure we have now a category of tests where prepare usually takes less than the timeout but sometimes more
<mup> PR snapd#3375 closed: snapstate,many: implement snap install --unaliased <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3375>
<niemeyer> pedronis: fgimenez has a branch bumping the timeout.. did we merge this?
<pedronis> niemeyer: it was bumped to 20mins, but I still saw prepare kill-timeout failures
<pedronis> today
<pedronis> anyway now that IÂ have green run IÂ don't see anythin taking more than 1000s,  so it's either load or network when they take that really long time
<niemeyer> pedronis: 20 minutes preparing?  That ought to be something frozen
<cachio> niemeyer, do you know the configuration needed to run tests in fedore?
<cachio> fedora?
<niemeyer> cachio: I wouldn't worry too much about anything that is not already enabled in Linode on master
<cachio> niemeyer, ok
<mup> PR snapd#3392 opened: interfaces: add minimal seccomp resolver to avoid backward compatiblity issues <Created by mvo5> <https://github.com/snapcore/snapd/pull/3392>
<mup> Bug #1693016 opened: snap install conjure-up fails if juju snap installed <Snappy:New> <https://launchpad.net/bugs/1693016>
<kyrofa> store... proxy errors....
<mup> PR snapcraft#1332 opened: cli: provide a whoami command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1332>
<kyrofa> noise][, I'm having trouble installing the snap I just released into a branch. `snapcraft status` shows it's there. Is this a cache issue?
<kyrofa> It's been about ten minutes now
<noise][> kyrofa: not a cache issue, but let me see if someone can help investigate
<kyrofa> noise][, alright, thanks. Snapcraft show me http://pastebin.ubuntu.com/24637022/ , but when I install I get http://pastebin.ubuntu.com/24637027/
<kyrofa> Note that pr-283 works fine, however
<Facu> hola kyrofa
<kyrofa> Hey Facu :)
<noise][> kyrofa: refresh into the branch works
<kyrofa> noise][, weird... how can that be?
<kyrofa> noise][, but install fails?
<noise][> different endpoints, might be a bug in details (used for install), but if so clearly we are missing a big test!
<Facu> noise][, you say that a refresh from the branch worked, while installing from that branch didn't?
<noise][> yes: https://pastebin.ubuntu.com/
<noise][> and although the output doesn't show it, it did change to the proper revision
<kyrofa> noise][, wrong link, I think :P
<noise][> woops
<noise][> https://pastebin.ubuntu.com/24637178/
<Facu> kyrofa, would you please tell me the snap_id of that package?
<kyrofa> Facu, njObIbGQEaVx1H4nyWxchk1i8opy4h54
<Facu> kyrofa, thanks!
<mup> Bug #1693037 opened: Canât start a snap app <Snappy:New> <https://launchpad.net/bugs/1693037>
<Facu> kyrofa, it's strange, indeed
<kyrofa> Facu, yeah, weird. Any ideas?
<Facu> kyrofa, not yet, and I need to run now :(, but I'll grab this until I figure it out, can I get to you tomorrow about this?
<Facu> (if somebody didn't get to you with this before)
<thomi> kyrofa: I'll take a look after I'm out of this call
<kyrofa> thomi, alright I appreciate it, thank you.
<thomi> np
<thomi> kyrofa: OK, I'm out of the call. Just to make sure I understand the problem, you have some branches that you can refresh into, but you can't install from?
<kyrofa> thomi, one, yes. The other branches work fine
<thomi> it's the 283 branch that you can't install from?
<kyrofa> 284
<kyrofa> 283 works
<thomi> ahh ok. Thanks.
<thomi> I'll investigate. When's your EOD, and how should I let you know what I find if it's late?
<thomi> wgrant: So the branch kyrofa is looking for doesn't exist in snaprevs: https://pastebin.canonical.com/188993/ I guess this may be an SCA integration issue?
<kyrofa> thomi, in about an hour or so, but this is standing in the way of some stuff so I'll be checking back periodically-- feel free to just ping me here
<thomi> kyrofa: ok, thanks
<wgrant> thomi: Yeah, I think it's a combination of SCA and snapd bugs.
<wgrant> thomi: Bret's refresh worked because snapd doesn't always parse out the branch
<thomi> but you think it's not actually getting a revision from that branch?
<thomi> I cna't see hwo it could, if we don't have that branch in our db
<thomi> ugh. typoing
<thomi> wow...
<wgrant> Well, there could easily be a bug in snapdevicegw that caused this
<wgrant> But the code in this case is pretty clear, and looking at snapd HTTP requests the client is doing some weird stuff.
<wgrant> Trying to work out exactly what
<wgrant> Hm. I just told it to refresh to "lalala", it made a query for "lalala/stable" which is correct, got an empty response as expected, but then said it upgraded
<wgrant> And before I told it to refresh to "stable/1234" and it asked for edge.
<kyrofa> Yikes
<wgrant> Oh, no, that latter one was a typo.
<wgrant> But it still says the snap was refreshed even if the server returns nothing at all for the channel.
<wgrant> So Bret's test doesn't reveal anything, really. The only real issue here is that the branch never got pushed for some reason.
<thomi> wgrant: want me to file a snapd bug for the poor UX around refreshing, while you investigate the push issue?
<wgrant> thomi: Sounds reasonable.
<wgrant> The really confusing thing is that it prints the version and says it was refreshed, even if nothing changed.
<wgrant> And also even if the server doesn't give anything to suggest that the requested channel actually exists.
<kyrofa> wgrant although note that snapcraft thinks it does: http://pastebin.ubuntu.com/24637022/ .
<Chipaca> what's the ux around refreshing that's bad?
<Chipaca> and what is the weird stuff you see snapd doing?
<wgrant> kyrofa: Right, somehow it didn't make it from dashboard to the services that serve devices.
<wgrant> Chipaca: wgrant@lamuella:~$ sudo snap refresh core --channel=totally/bogus
<wgrant> core (totally/bogus) 16-2.26.3+git204.1bc8375 from 'canonical' refreshed
<kyrofa> wgrant, ah, right
<Chipaca> huh
<thomi> wgrant: what's worrying is what snapd shows if you do 'snap info core' after that
<Chipaca> yeap, that's a bug
<thomi> I'm filing the bug now...
<wgrant> May 24 08:22:27 lamuella /usr/lib/snapd/snapd[12917]: logger.go:75: DEBUG: < "HTTP/1.1 200 OK\r\nContent-Length: 40\r\nContent-Type: application/json\r\nDate: Tue, 23 May 2017 22:22:27 GMT\r\nServer: gunicorn/19.7.1\r\nStrict-Transport-Security: max-age=2592000\r\nX-Request-Id: e8ab92e3-449f-4531-9cf1-60933ff2f0b1\r\nX-Vcs-Revision: 51cfdf0\r\n\r\n{\"_embedded\":{\"clickindex:package\":[]}}\n"
<wgrant> So the server correctly returned nothing.
<Chipaca> thomi: so it changes the tracking channel, indeed
<Chipaca> :-(
<Chipaca> thomi: wgrant: nice catch
<Chipaca> hmmmm
<Chipaca> wait
<wgrant> I don't think this can be a server-side change.
<Chipaca> why is the store not saying something like "404"?
<wgrant> But let me check.
<wgrant> Chipaca: It's a metadata request.
<wgrant> It takes multiple snaps, so can't 404.
<Chipaca> right
<wgrant> Unless it's meant to, that'd be weird and a bug in the new services.
<wgrant> Well, a bug in the API
<wgrant> And a bug in the new services for not emulating that API bug
<Chipaca> :-)
<Chipaca> I didn't remember metadata requests started with the _embedded/clickindex:package thing, thought that was just search
<thomi> https://bugs.launchpad.net/snapd/+bug/1693042 filed
<mup> Bug #1693042: snapd will refresh to a channel that does not exist <snapd:New> <https://launchpad.net/bugs/1693042>
<thomi> sadly it's everything that CPI used to return.
<Chipaca> so, about the message, that's the correct message for when you switch to a channel that has the same snap revision as you already have
<Chipaca> ie if you then do "snap refresh --channel=<whatever you were in before>" it'll say refreshed
<thomi> Chipaca: but you agree that it's the wrong message for the case where the channel you're switching to doesn't exist?
<thomi> yeah, that makes sense to me
<Chipaca> thomi: the bug is that it switches successfully to a channel that doesn't exist, indeed
<thomi> I must remember to refresh my core back to a channel that exists :D
<wgrant> Chipaca, thomi: Confirmed that the same thing happens on CPI, so it's not a regression.
<thomi> Good.
<wgrant> There is a slight behaviour change in that CPI didn't include _embedded/clickindex:package at all if it was empty, but snapd doesn't care about that.
<thomi> oh, are you sure? I could imagine perhaps snapd would fail to parse the json of that was missing, resulting in a different error path
<wgrant> I just tested.
<thomi> ahh ok
<wgrant> Overriding SNAPPY_FORCE_CPI_URL=http://cpisnap.ols.internal/api/v1/
<Chipaca> so, here's one thing i don't understand
<thomi> wgrant: ahh
<Chipaca> the metadata response is supposed to be
<Chipaca> a json document with 'snaps' and 'fields'
<Chipaca> e.g. something that starts {\"snaps\":[{\"snap_id\":\"....
<Chipaca> and that's what you get when you refresh to 'beta'
<Chipaca> actually, give me a bit
<wgrant> You might think that
 * Chipaca 's not too bright right now
<wgrant> snapd probably strips the extra wrapping pretty early.
<wgrant> But checking.
<thomi> it's parsed in store.go
<wgrant> type searchResults struct {
<wgrant>         Payload struct {
<wgrant>                 Packages []snapDetails `json:"clickindex:package"`
<Chipaca> the log is from the wire, directly
<wgrant>         } `json:"_embedded"`
<wgrant> }
<Chipaca> which is what i'm looking at
<wgrant> That's used for metadata as well
<wgrant> Chipaca: The *request* looks like what you pasted
<wgrant> The response is not.
<Chipaca> ah, sorry then
<Chipaca> i should redo this without the macaroon; it makes it very hard to read the logs
<Chipaca> does the same thing happen when refreshing more than one snap i wonder?
<Chipaca> (yes it's a different codepath)
<Chipaca> (shut up)
<wgrant> Chipaca: It's not possible to override the channel for a multi-snap refresh, but I imagine so.
<Chipaca> ah, of course it won't happen
<Chipaca> because you can't set channel in the other codepath
<Chipaca> (that's why the single snap codepath exists and is different)
<wgrant> If they were already on an invalid channel they'd erroneously think they were up to date, though.
<Chipaca> wgrant: they'd think that because we told them so, you mean? :-)
<wgrant> Chipaca: Well, ish.
<wgrant> Chipaca: Long term we probably want the server to be able to report "hey, this channel doesn't exist any more, you should probably warn your user"
<wgrant> Which makes the distinction between "there is no update" and "there is nothing at all" important.
<wgrant> Even on non-switching refresh
<Chipaca> ah that reminds me
<wgrant> And bulk refresh
<Chipaca> niemeyer: is there anywhere i can read about the reasoning behind not having snapd boot a system of a branch when the branch closes?
<niemeyer> Chipaca: Probably not in the depth you'd like to hear about, but I'm happy to provide the proper rationale here or in the forum
<Chipaca> niemeyer: and perhaps more importantly, a branch that closes can't ever be re-used, right?
<niemeyer> Chipaca: It can, and that's one side of the argument.. we have existing behavior in that regard
<niemeyer> Chipaca: Think beta closing
<Chipaca> well.. beta has a defined meaning around risk
<Chipaca> hotfix, a lot less so
<Chipaca> and my hotfix could well be my neighbour's nightmare
<niemeyer> Chipaca: Interestingly and neatly, the behavior is exactly the same in both cases as far as channels are concerned
<niemeyer> Chipaca: beta falls back to candidate once closed.. the branch falls back to its underlying risk level
<Chipaca> niemeyer: I can see the mechanics at our end being the same and that being nice and consistent, but I fear the two things are going to be used very differently and that's going to get users into trouble
<niemeyer> Chipaca: In my mind it's quite the opposite.. It sounds terrible to fiddle with configuration behind the administrator's back
<Chipaca> basically the scenario where today there's a stable/hotfix for problem A, that's incorporated into stable and hotfix is closed, and then that makes problem B happen, so a hotfix for that is put out that reverts
<Chipaca> i'm _just_ talking about letting branches be reused
<kyrofa> thomi, wgrant so the refresh versus install test wasn't real. The real issue with my branch not showing up is a communications breakdown between the dashboard and the backend?
<niemeyer> Chipaca: Okay, I don't understand the case you just described
<Chipaca> (it's bad in both cases, the reverting-to-underlying and the non-reverting-to-underlying)
<Chipaca> (for different but similar reasons)
<Chipaca> aww
<thomi> kyrofa: that's a reasonable summary, yes
<niemeyer> Chipaca: If stable/fix-terrible-problem is closed because stable has the fix, it will fallback to stable.. end of story?
<Chipaca> niemeyer: i need a way to just dump my brain state somewhere for you to look at
<Chipaca> writing is too much work
<niemeyer> Chipaca: :D
<Chipaca> niemeyer: the way i imagine branches being used is to address urgent problems with particular users (or classes of users)
<niemeyer> Chipaca: Yeah, that's one reasonable use case
<kyrofa> thomi, if I release to another branch, will that interfere with your debugging?
<Chipaca> e.g. you put out a stable, a week later it's discovered it's quietly corrupting rpi3s that have a particular wifi card
<Chipaca> you can't bump roll back the release for x reason
<Chipaca> you can't tell them to jump to beta for some other reason
<Chipaca> so you put out a hotfix for them
<thomi> kyrofa: should be fine
<Chipaca> niemeyer: then you fix the underlying problem (or you think you do!) and close the hotfix branch after the next release to stable
<niemeyer> Okay, so far with you
<Chipaca> niemeyer: so now the users that are on hotfix are tracking stable again
<niemeyer> Yeah, woohay
<niemeyer> Bug fixed, people are back into the normal line
<Chipaca> niemeyer: but now you find out that what you thought was a fix from the above problem is now making printers on people that have a particular bluetooth card on rpi 2s print nasty messages
<Chipaca> niemeyer: so, you put out a hotfix for those users
<Chipaca> the hotfix is basically undoing what you thought was a fix (but not quite, because of other unrelated changes)
<Chipaca> niemeyer: with me so far?
<niemeyer> Okay.. the problem there is that the branch name was reused, which is a very bad idea if you are convey two opposite meanings to the same content
<niemeyer> Even snapd aside, people might end up installing the wrong thing because they've read someone's blog post abou tit
<niemeyer> So, IMO a case of "doctor, it hurts!"
<Chipaca> niemeyer: so how would this play out, in your view? what's the bit that went wrong?
<niemeyer> Chipaca: Reusing the branch name for something that is not intended to be a real sequence..
<Chipaca> niemeyer: right, how is that being explained/communicated/enforced?
<kyrofa> thomi, alright, done. I'm now unblocked
<niemeyer> Chipaca: This is just like any other channel.. when we put two sequential things into a channel, we need to have in mind that people might install the first, the second, or both in succession..
<thomi> kyrofa: \o/
<Chipaca> thomi, wgrant, spotted where we mess up i think (still digging though)
<niemeyer> Chipaca: and again, this is not specific to branches.. every channel behaves like that
<wgrant> kyrofa: Releasing to another branch would have actually run into the same problem, but we've fixed both now.
<wgrant> kyrofa: Your missing branches are no longer missing.
<wgrant> kyrofa: We're investigating how this happened.
<kyrofa> wgrant, thanks for that
<Chipaca> niemeyer: ok, i need to think about this some more. you're probably right, but something has me uneasy
<niemeyer> Chipaca: Thanks for trying to find out what it is.. sometimes we do find curious edge cases with those conversations
<noise][> fwiw, i'm in total agreement with niemeyer here on the branch behavior
<noise][> publishers can absolutely screw their users if they repurpose a branch name for different cases, so they shouldn't do that, and we should make it clear in the docs
<noise][> but there's absolutely cases where you'd want to re-open a closed branch
<wgrant> kyrofa: We're still investigating how nextcloud got into that bad state, but it looks like it might be a race in dashboard.snapcraft.io's automatic review process. The new store infrastructure noticed the data inconsistency and refused to accept the channel updates. We'll get alerted if it happens again, and we have a button to fix it immediately.
#snappy 2017-05-24
<Chipaca> wgrant: should http://cpisnap.ols.internal/api/v1/ still work?
<Chipaca> ah
<Chipaca> d'oh
<Chipaca> .internal
<jorian> hello, I'm trying to make a snap for openmw (re-implementation of the morrowind game engine) and when trying to launch my snap, I'm getting the error "libGL error: unable to load driver: i965_dri.so"  I think I might be missing a plug.  Does anyone happen to know which plug would make that driver available?  I've tried adding x11, opengl, home, and pulseaudio.
<qengho> jorian: This may be a red herring, but my question is, is there such a file inside your snap?
<jorian> qengho: it seems to be in 3 places inside the snap directory
<jorian> ./parts/openmw/install/usr/lib/x86_64-linux-gnu/dri/i965_dri.so
<jorian> plus in stage and prime
<olympionex> I'm looking at the guide for creating a snappy interface on zygoon.pl.  The method involves editing the snapd source and the recompiling the whole project.  Is there currently a way to add interfaces externally / by installing a snap similar to how the core snap works?
<olympionex> I need to create an interface to allow writes to /var/run but I don't really want to have to manage a custom version of snapd
<kyrofa> Thank you wgrant, I appreciate the help!
<kyrofa> olympionex, the only reason the core snap can make any interface available is because the interfaces it supports are supported by snapd
<kyrofa> It's not doing anything special
<olympionex> kyrofa: thanks -- I see that now looking at the source
<olympionex> kyrofa: all the interfaces are in snapd itself
<kyrofa> qengho, if jorian comes back, the gl libs are required in stage-packages. Specifically libgl1-mesa-dri
<kyrofa> olympionex, indeed: interface SUPPORT is in snapd, but then the producer (slot) side of interfaces must be supplied by a snap, and the consumer (plug) side must be consumed by a snap
<kyrofa> The interface being USED by the plug/slot, however, must still be one that's supported by snapd
<kyrofa> Oh wait... qengho nevermind, looks like that lib made it into prime. Just missing the right LD_LIBRARY_PATH then, it seems
<olympionex> I see - so the content plugin lets a snap provide access to some internal path, but if I want to access some other system path, I will have to add it to snapd
<kyrofa> olympionex, yes. Although I'm curious about your use-case, do you mind sharing?
<olympionex> kyrofa: yeah, I just have a binary that I don't have the source to and it creates some socket files in /var/run
<kyrofa> olympionex, yep that would do it :P . However, have you investigated using LD_PRELOAD to get around it?
<olympionex> kyrofa: i was using classic mode, and probably still can, but it looks like it changed a bit in 2.22 maybe
<olympionex> hmm, I'm have a look at that
<kyrofa> 2.22 is a bit behind, 2.25 is out now
<kyrofa> olympionex, there's a preload part out there already if you want to check it out. Here's an example of how to use it: https://github.com/nextcloud/client_theming/blob/master/linux/snap/snapcraft.yaml#L50
<kyrofa> Check out line 34 as well for where it's pulled in
<olympionex> I actually meant snapcraft 2.22.  The new version doesn't add the library paths to the command wrappers it generates.   I can of course just make my own script that gets called by the wrapper, but I need to research all the consequences.  I was just checking again about running it in strict mode
<kyrofa> olympionex, in that case it's even older: 2.29 is out :P
<kyrofa> olympionex, yeah, strict is _always_ best if you can swing it
<kyrofa> olympionex, classic snaps have trouble running on other distros, and they don't run on ubuntu core either
<kyrofa> olympionex, definitely worth investigating that preload part, especially considering it's an extra line and a half
<wgrant> kyrofa: We've identified the two bugs in dashboard.snapcraft.io that combined to cause this issue. It's possible you'll run into similar issues again with that particular snap until we fix the root cause properly, but we know what's going on now so that should be quick.
<kyrofa> wgrant, it's something particular to the snap?!
<kyrofa> What did I break?
<wgrant> kyrofa: A review race caused one of the revisions to get stuck in a bad state, and that will possibly confuse further automatic refuses until we fix that old revision.
<wgrant> ...
<wgrant> s/refuses/reviews/
<wgrant> Hopefully not refusals :)
<kyrofa> wgrant, ah ha, I wondered about that weird rev :P
<wgrant> They shouldn't fail, just get stuck
<kyrofa> wgrant, if I reject it, would that fix things?
<wgrant> kyrofa: Quite possibly. We already know we need to manually fix that revision, so rejecting it can't really make it worse.
<wgrant> So might be worth a try.
 * kyrofa tries
<olympionex> kyrofa: fortunately i have a limited set of systems I have to run on.  I use snapcraft to simply our internal deployment of some software.  Still, i prefer to get things working in the most supported way to avoid suprises later.
<kyrofa> olympionex, understood
<wgrant> kyrofa: Looks like that's worked.
<wgrant> So we just need to manually fix up 1418 later.
<kyrofa> wgrant, no need to worry about that one
<olympionex> kyrofa: thanks for the preload info, i was  looking at some ELF hacking but this may be cleaner
<kyrofa> olympionex, yeah that would not be fun
<kyrofa> And of course, any time :)
<mup> PR snapd#3393 opened: Add retry mechanism for snap install command to fix test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3393>
<abeato> pedronis, mvo mind unblocking re-reviewing https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Blocked> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<zyga> good morning
<mup> PR snapcraft#1333 opened: state: search for the dependencies in the archive <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1333>
<pstolowski> morning zyga!
<zyga> o/
<morphis> zyga: hey!
<morphis> zyga: time for a review on https://github.com/snapcore/snapd/pull/3371 ?
<mup> PR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>
<zyga> morphis: looking
<morphis> zyga: CI hates me, another store timeout
<morphis> zyga: but thanks for approving
<morphis> zyga: and a review on https://github.com/snapcore/snapd/pull/3365 would be nice too
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<zyga> morphis: what does it mean https://github.com/snapcore/snapd/pull/3365/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R268 ?
<mup> PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<zyga> didn't the pkgdb helper land already
<zyga> ah
<zyga> sorry, I see
<morphis> zyga: you can't use it at this place
<morphis> ok :-)
<Chipaca> ooh, listen to the wind!
<Chipaca> it sounds like "reeeeviewwsss"
<Chipaca> good morning peeps
<zyga> morphis: done
<zyga> hey Chipaca
 * zyga feels miserable
<Chipaca> zyga: :-(
<Chipaca> zyga: did you see the issues ryebot was having yesterday?
<zyga> Chipaca: yes but I didn't manage to reply
<Chipaca> zyga: 's ok; i just don't want to have to remember it myself
<Chipaca> if you're aware, i can forget
<zyga> thanks :-)
<pedronis> Chipaca: IÂ nitpicked a bit on one of your PRs
<Chipaca> pedronis: good morning to you too :-)
<morphis> zyga: ok, updated the PR
<Chipaca> pedronis: good points you make
<zyga> http://paste.ubuntu.com/24642129/
<Chipaca> pedronis: i'm currently working on a bug where we don't distinguish "already at the latest revision on that channel" from "that channel does not exist"
<zyga> any wording suggestions before I do the full set?
<Chipaca> pedronis: (you can try it! snap refresh core --channel potato)
<Chipaca> pedronis: (then check 'snap info')
<zyga> (ideally the output would be more consistent)
<zyga> and not sure what to do with "allows"
<zyga> maybe just skip it
<Chipaca> 's fun
<zyga> fun fact: we have 91 interfaces
<zyga> I'll add a 100th anniversary interface ;-)
<pedronis> Chipaca: can we do it without store help?
<Chipaca> pedronis: the store is telling us
<Chipaca> (more or less)
<Chipaca> pedronis: i'm fixing it alreayd
<mvo> zyga: I don't want to be a party pooper but https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-possible-revert-race-condition/722 is currently higher on the priority list than anniversaries ;)
<Chipaca> pedronis: basically ListRefresh is fine for multi-updates, but we need a special one for single updates that doesn't throw away this info
<Chipaca> pedronis: pretty much exactly the same except if the store returns nothing, raise an error
<pedronis> Chipaca: just telling me why you won't fixing my nitpicks straight away :)
<Chipaca> pedronis: yes, that's exactly what i'm doing
<Chipaca> you're very perceptive today
<pedronis> but inpolite because IÂ didn't say good morning yet
<Chipaca> pedronis: what's a good name for something that does what store.ListRefresh does, but for a single refresh candidate?
<zyga> mvo: you are completely right
<zyga> mvo: I'll finish this PR and send it for review in a moment
<zyga> mvo: but before I do that, let's chat here briefly
<zyga> mvo: if the new syntax is a blocker (I mean |N) then the plan falls apart
<mvo> zyga: yeah, its rather annoying
<zyga> mvo: your plan to compile seccomp profiles in snapd is possible
<zyga> mvo: but, well, needs discussion
<zyga> mvo: we could make a new internal helper
<mvo> zyga: we would have to generate old-style files for a while for backward compatiblity
<zyga> mvo: why? I don't think so
<mvo> zyga: old style with a frozen format so that also is slightly complicated
<mvo> zyga: no?
<zyga> mvo: (just whatever matches snap-confine)
<mvo> zyga: aha, just leave the old ones around :) ?
<zyga> mvo: yes
<zyga> mvo: so we'd stop writing the old files entirely (but not remove them yet)
<zyga> mvo: for revert specifically
<mvo> zyga: hm, that would break in the case of "snap refresh core; snap install hello; snap revert core", then hello would no  longer work. maybe not too terrible
<zyga> mvo: aha
<zyga> mvo: interesting, yes, it would work if snapd would start before "hello" but I see your point
<mvo> zyga: aha, good point
<zyga> mvo: but the bigger issue is that we'd have two seccomp profiles per security tag
<zyga> mvo: one old and one new, with different semantics (because no |N)
<mvo> zyga: yeah, that is the part that worries me, it feels fragile
<zyga> mvo: but if we do that we can use the old text format
<zyga> mvo: because we'd just write two files
<zyga> mvo: one with |N and one without
<mvo> heh
<mvo> good point
 * zyga greps for |N syntax
<mvo> well, the seccomp bpf would make us future proof forever(tm)
<zyga> weird
<zyga> mvo: I agree on that
<mvo> (needs some research but it looks like bpf is pretty stable as a binary format)
<zyga> yes
<mvo> zyga: what is weird?
<zyga> mvo: I don't see any |N syntax with quick grep
<pedronis> Chipaca: LookupRefresh ?
<zyga> are we even using this?
<zyga> mvo: (also it would be faster for startup, which is nice)
<mvo> zyga: let me double check the debdiff
<zyga> mvo: can you grep for anything that uses this
<zyga> thanks!
<mvo> zyga: if we are not using it, that would be splendid
 * zyga feels sick again 
<zyga> yes :)
<zyga> (perfect timing, just before a conference)
<mvo> zyga: uh, get some rest if you feel sick, I can work on this
<mvo> zyga: seriously, get well, especially if you need to travel soon
<zyga> mvo: no, I cannot do anything about it :/
<mvo> zyga: meh, ok
<zyga> mvo: I'd rather finish the interface meta-data changes and feel better by doing that
<zyga> mvo: sick as in food-sick, not flu-sick
<mvo> zyga: autsch, ok. all right, I do the investigation on |N while you finish your interface work :)
<zyga> OK
<abeato> zyga,  mind unblocking/re-reviewing https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Blocked> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<mvo> zyga: we use the |S_IFREG in our default template now https://github.com/snapcore/snapd/blob/master/interfaces/seccomp/template.go
<mvo> zyga: I will write a forum topic with some ideas, looks like it is not going to be super simple, but maybe not to hard either
<pedronis> mvo: zyga: one of you should probably review snapd#3350 if we want it in 2.27
<mup> PR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>
<pedronis> anyway I suppose 2.27 is delayed by a fair bit because of 2.25 issues?
<pedronis> *fair bit now
<mvo> pedronis: yeah, there is a slight crisis right now :/
<pedronis> mvo: can't we just change the names of the seccomp profiles ? or start putting them into profiles/something
<pedronis> s/something/somehash/
<pedronis> and teach 2.26.x snap-confine about new new place
<pedronis> s/new new/the new/
<mvo> pedronis: probably, there is still this problem that "snap refresh core; snap install daemon; snap revert core" may lead to the same issue we currently having. i.e. the new snapd does only write a new seccomp file but on reboot daemon starts so early that the old snapd does not generate a new seccomp file early enough. but still doing this would probably get us a long way forward
<pedronis> reverting core after installing new stuff is bound to create troubles anyway in some scenarios
 * mvo nods
<pedronis> IÂ mean can see some non security profiles one
<zyga> mvo: do we use |S_IFREG or just S_IFREG?
<zyga> pedronis: ack
<olympionex> has anyone used the snapcraft-preload project?  I'm thinking there is a bug in the preload for the bind method, or possibly there is something i'm not doing.  When creating an AF_UNIX socket, it would seem that it should redirect to a writeable path, but that doesn't seem to be the default behavior, at least for my case.  I have manually patched it on my side and it seems to work, but just wanting to verify.
<zyga> olympionex: guys who wrote that are in americas so I'd suggest opening a forum topic
<mvo> zyga: the former |S_IFREG
<zyga> mvo: aww, drat
<zyga> mvo: well
<zyga> mvo: plan B
<zyga> mvo: revert that change
<zyga> mvo: like we did before
<zyga> mvo: if it is just one spot it is easier
<zyga> ah, there are a few
<zyga> all the mknod
<zyga> hmm hmm hmm
<mvo> zyga: yeah
<zyga> mvo: so what is your plan?
<morphis> zyga: can you merge https://github.com/snapcore/snapd/pull/3371 ?
<mup> PR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>
<mvo> zyga: I'm still pondering, its tricky. worst case would be to revert the new syntax again, i.e. revert all mknod and keep quotactl via the secompSymbolTable branch. we need jdstrand input here
<zyga> morphis: done
<mup> PR snapd#3371 closed: packaging: import packaging bits for opensuse <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3371>
<zyga> mvo: the question is, what do we lose if we do that
<zyga> mvo: was this released in 2.25?
<zyga> abeato: some feedback
<abeato> zyga, ok, thanks
<abeato> zyga, I've answered one of the comments
<mvo> zyga: yeah, the mknod was released in 2.25, I think we need jamies input. but I will also try to find out more
<zyga> mvo: can we replace |foo with a list of rules?
<ogra_> hmm, so using delta updates on the pi3, the delay is noticeable but not super awful
<ogra_> i fear that wont be usable on a bbb
<mup> PR snapd#3388 closed: osutil: add non-blocking flock <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3388>
<pedronis> sorry I did this merge ^ but messed up a bit the commit message, because GH seems very partial on what it remembers or not when you move away and back to a merge in progress
<mup> PR core#35 closed: move xdg-open to proper paths <Created by ogra1> <https://github.com/snapcore/core/pull/35>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#35 opened: move xdg-open to proper paths <Created by ogra1> <https://github.com/snapcore/core/pull/35>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<Chipaca> mvo: fgimenez: do you guys have dev access to etcd?
<Chipaca> actually, i just want to know a revision of etcd that isn't published
<Chipaca> bah
<Chipaca> never mind
<fgimenez> Chipaca: i don't sorry
 * Chipaca noticed the store's response
<Chipaca> $ /tmp/snp install potato --revision 2 --channel whaat
<Chipaca> error: snap "potato" not found (at least in channel "whaat/stable" at revision 2)
<Chipaca> incredible how much work i had to do to get that (at least) there
<mup> PR snapd#3394 opened: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394>
<ogra_> mvo, what is linux-armhf ? is that leftover cruft ? https://forum.snapcraft.io/t/issues-while-porting-ubuntu-core-16-image-for-olimex-lime2-platform-board/761 (snap info says its yours)
<Chipaca> that's an old kernel
<ogra_> yes
<Chipaca> from before we could have multiple architectures in the same snap
<ogra_> i just wonder why it is available
<ogra_> we did a big cleanup run a while ago
<morphis> zyga: thanks!
<zyga> gaah
<Chipaca> ogra_: fwiw i can confirm it's in the store
<Chipaca> at revision 9
<ogra_> Chsure, i wouldnt have pinged if i had not checked it before ;)
<ogra_> yeah, in all channels
<Chipaca> zyga: gah?
<zyga> so, interface summary is very confusing to write
<zyga> as plugs and slots have totally different purpose
<zyga> what is a good summary of the "pulseaudio" interface?
<zyga> it's both to be pulseaudio service and to talk to it as a clinent
<Chipaca> zyga: "this interface lets you pulse your audio"
<zyga> should we have two summary lines per interface? (up to)
<Chipaca> zyga: are both those things available to you when you use it as a slot?
<zyga> Chipaca: no, but this is not about plugs or slots
<Chipaca> zyga: maybe it should be
<zyga> Chipaca: this is about the new "interface" command and interface meta-data
<zyga> Chipaca: what interfaces do you have? (not instances, types)
<zyga> http://paste.ubuntu.com/24642921/
<zyga> Chipaca: my misery so far
<zyga> Chipaca: maybe "allows operating as or using the pulseaudio service"
<Chipaca> zyga: is the "allows" there something you've agreed to standardize on?
<Chipaca> looks nasty af
<zyga> no, this is still a prototype
<Chipaca> :-)
<zyga> af?
<Chipaca> zyga: how about you drop the allows and verb the thing you have after it?
<Chipaca> zyga: as fireworks
<Chipaca> :-p
<zyga> Chipaca: yeah, I'm open to suggestions, I'll finish this pass to just have something consistent for each and then propose the bits and pieces
<Chipaca> zyga: i mean: "allows frobbing the plumus" -> "frob the plumbus"
<zyga> this is just one patch among many and one that I suspect we'll bikeshed the most
<zyga> Chipaca: try this on 5 different real interfaces or it doesn't count
<Chipaca> zyga: i did :-)
<zyga> Chipaca: how about network?
<mvo> ogra_: hm, a very old kernel that I put there for experiments I think, I will unpublish it
<Chipaca> zyga: "access the network"
<Chipaca> zyga: pulsaudio would be, for example, "host or communicate with a pulsaudio server"
<ogra_> mvo, thanks
<mvo> ogra_: done
<Chipaca> zyga: unity8 would be "aw, bless"
<zyga> Chipaca: kind of like the pulseaudio thing but this is still very confusing IMO, from users POV (no deep insight into plug-vs-slot semantics) there's a lot of difference here
<Chipaca> zyga: remember these are more for orientation and not explanation
<Chipaca> that is, details at the url
<zyga> yes, that is true
<zyga> the URL is already in the meta-data
<Chipaca> zyga: a user looking at this list is either refreshing their memory, or wanting to know what to read to learn more
<Chipaca> zyga: so you give them enough information to pare down the list
<Chipaca> anything networkish, they're probably going to have to look at all the network* things the first time to figure out what they need
<Chipaca> the second time it'll be enough as is
<mup> PR snapd#3381 closed: logger (& many more, to accommodate): drop explicit syslog <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3381>
<Chipaca> zyga: hmmm
<zyga> yes?
<Chipaca> $ snap remove http
<Chipaca> error: cannot perform the following tasks:
<Chipaca> - Remove security profile for snap "http" (x1) (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented)
<zyga> Chipaca: you are using snapd from master but the rest from package
<zyga> Chipaca: just buind and install snap-update-ns
<Chipaca> ah ok
<zyga> also
<zyga> our error stacking sucks
<Chipaca> i'll get there eventually
<zyga> Chipaca: you want discard-ns too
<zyga> FYI
<zyga> and snap-confine
<Chipaca> zyga: so, make hack
<zyga> or you may hit weird issues
<zyga> Chipaca: yes, and I need to teach it to build the go parts maybe :)
<Chipaca> nah, those are easy :-)
<zyga> just 4 left
<Chipaca> ok, i've got to run
<Chipaca> got physio
<zyga> take care!
<Chipaca> I probably won't be back in time for standup
<pedronis> morphis: is this https://forum.snapcraft.io/t/run-configure-hook-of-core-snap-if-present-runs-seemingly-forever/674/2 the snapctl/bind issue likely, or something else?
<Chipaca> so: i'm working on "snap refresh core --channel bogus" (which currently, erroneously, works)
<Chipaca> got a fix already, fixing tests and cleaning it up, should have pr before eod
<Chipaca> also, got some work to do on go patch
<morphis> pedronis: it looks different here as from the log output it hangs at "Mount snap"
<pedronis> so the topic is wrong?
<morphis> pedronis: and the bind() issue shouldn't occur for the core snap as the core snap now plugs network-bind
<pedronis> it's not about configure
<morphis> pedronis: the first post in that topic is
<morphis> "[-] Run configure hook of "core" snap if present"
<pedronis> ok, confusion
<morphis> zyga: https://github.com/snapcore/snapd/pull/3394 is ready for a merge unless you want someone else to have a look
<mup> PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394>
<zyga> morphis: can mvo ack it please?
<morphis> mvo: ^^
 * zyga prepares the three banches 
<morphis> zyga: btw. when you try lxd on suse just don't forget to disable AppArmor for the containers
<morphis> niemeyer: Spread-32 is now down to 1.3G, ok for you?
<zyga> morphis: aha
<zyga> morphis: how do I do that?
<Chipaca> zyga: --with-less-security
<Chipaca> zyga: --make-hackable
<Chipaca> zyga: --wanton-insecurity
<Chipaca> zyga: --make-chipaca-stop
<zyga> Chipaca: sudo make me a sandwitch
<mup> PR snapd#3395 opened: many: remove interface meta-data from list of connections <Created by zyga> <https://github.com/snapcore/snapd/pull/3395>
 * zyga didn't eat anything but breakfast today
<cachio> fgimenez, how do you usually retriger a ci check when there is a failure which doesn't need any change in the code?
<zyga> Chipaca: ^^ please land that
<cachio> fgimenez, I got this https://travis-ci.org/snapcore/snapd/builds/235333896?utm_source=github_status&utm_medium=notification
<Chipaca> zyga: you're going off?
<morphis> zyga: https://github.com/lxc/lxd/issues/3096
<fgimenez> cachio: i can't retrigger on travis sorry, i think only people in the snapd-commiters team can retrigger
<fgimenez> cachio: usually, if your PR needs to wait, merging master is a good idea in general, that push retriggers the build
<morphis> zyga: https://github.com/lxc/lxd/issues/3345
<cachio> fgimenez, nice, tx
<niemeyer> morphis: Any chance we can take it a bit further down?  This will likely be something like ~2G for imaging purposes
 * zyga -> car & kids
<mup> PR snapd#3396 opened: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>
<mup> PR snapd#3397 opened: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3397>
<zyga> niemeyer: ^^
<niemeyer> morphis: Also sent a review on the no-apparmor bind issue.. we should probably have forum conversation about that one.. given the comment is not entirely clear that we're in agreement about what's going on in that case
<zyga> cachio: hey
<zyga> cachio: some failing tests https://travis-ci.org/snapcore/snapd/builds/235657720?utm_source=github_status&utm_medium=notification
<zyga> cachio: please collect the log if you want to keep inspecting it, as I want to restart the test
<mup> PR snapd#3393 closed: tests: add retry mechanism for snap install command <Created by sergiocazzolato> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3393>
<ryebot> zyga: I found a workaround for my issue, so I'm no longer blocked, but I added what useful information I could to this bug: https://bugs.launchpad.net/snappy/+bug/1687079
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<ryebot> good luck!
<zyga> ryebot: thank you!
<ryebot> np!
<niemeyer> cachio: This one might be easy to address: http://paste.ubuntu.com/24644624/
<mvo> Chipaca: silly systemd question, we have this problem currently that when a new snapd boots it will rewrite the apparmor/seccomp profiles. however snap services start in parallel so there is a race condition here and they could start before snapd finished updating the profiles. I wonder if we could use systemd to sync this, i.e. have a way to say for all snap service that they may only start after snapd-regenerate-profiles was run. wdyt?
<Chipaca> mvo: is snapd-regenerate-profiles a systemd service, or is it a task?
<Chipaca> (the answer is yes either way)
<mvo> Chipaca: it is something that happens in the daemon at startup, so no proper task just a part of the init of snapd
<mvo> Chipaca: I like the "yes" here
<Chipaca> mvo: ok, so it's going to be a little bit of work
<Chipaca> mvo: we need to make systemd be a "notify" daemon
<Chipaca> (btw, I don't know if this'll work in 14.04)
<Chipaca> um
<Chipaca> i mean we need to make *snapd* be a notify thing
<pedronis> ah
<mvo> Chipaca: aha, there is a branch for that
<Chipaca> there is? nice
<mvo> Chipaca: but of course that branch can not do much currently except for telling systemd that it is still alive in a crude way
<mvo> 3111
<pedronis> I think the idea is that snapd wouldn't notify until it has rewritten the profiles
<pedronis> that it's started
<mvo> yes!
<pedronis> IÂ don't know how that vs the watchdog stuff interact though
<mvo> pedronis: aha, maybe I misunderstand, I thought the notify thing was the same socket, let me double check
<Chipaca> so
<mvo> pedronis: i.e. that we can reuse code, but I will double check :)
<Chipaca> they both do sd_notify
<Chipaca> one with WATCHDOG=1
<Chipaca> one with WHATUPDOG=1
<Chipaca> i mean READY=1
<Chipaca> so, the watchdog code needs rewriting to support this
<Chipaca> or at least refactoring
<mvo> yep
<Chipaca> but relatively easy i think
<zyga> mvo: that thing can be a snap internal command
<zyga> mvo: it would be easier to get this right
<zyga> mvo: essentially a snapd ping of any kind is sufficient
<zyga> mvo: then no need to make snapd notify anything
<zyga> mvo: it's just a "snap ensure-soon" or whatever
<zyga> mvo: and we're done
<zyga> another call-for-feedback on https://github.com/snapcore/snapd/pull/3396
<mup> PR snapd#3396: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>
<zyga> I'd like to land it once green, I'm happy to iterate on the summary lines
<zyga> once it lands I can propose the command that uses this and needed plubming
<ryebot> Is there a way to prevent automatic refreshes occurring?
<zyga> ryebot: no
<zyga> ryebot: you can set a refresh schedule
<zyga> ryebot: but refreshes are mandatory
<ryebot> alright, where can I find docs on the refresh schedule?
<ryebot> nvm, I found a forum post
<mvo> zyga: I'm not sure I understand. all snaps that have services will need to have an After=snapd-regenerated-service in their auto-generated systemd service and we need to emit that when we are finished with the generation. how is this related to an internal command?
<mvo> Chipaca: thanks a bunch for your input, I will start a forum thread about it
<Chipaca> zyga: what do you mean 'no need to make snapd notify anything'?
<Chipaca> right
<zyga> mvo: my point is that that After= can refer to a new unit that just says "snap ping" to wake up snapd
<Chipaca> mvo: AIUI it'd be just After=snapd, with snapd not considered "up" until it's sd_notified of READY=1
<zyga> mvo: no need to involve more complex tooling
<Chipaca> ahh
<zyga> Chipaca: that the more complex solution is probably fine but this feels easier
<zyga> Chipaca: it could just be after=snapd really
<ryebot> So, this is a little problematic for my use case. I'm helping the LF build multiple k8s clusters into an image for use in their k8s certification exam. During image build, the k8s bin versions might be something like 1.6.2. During testing (which could be any time, afaict), bam! 1.6.4 comes out and disrupts services etc.
<zyga> Chipaca: I do agree that snapd needs to say "I'm up" to systemd for an "after=snapd" approach
<Chipaca> agreed about the ping, now that i got you, but it's more hackish, and we want to have the sd_notify thing already
<Chipaca> (for the watchdog)
<Chipaca> so might as well do it
<Chipaca> imho
<zyga> Chipaca: yes, that's fine
<Chipaca> fwiw
<ryebot> So the refresh schedule doesn't actually aid me in this case.
<Chipaca> ryebot: hold on
<ryebot> kk
<zyga> ryebot: can you re-phrase that, are you testing an image with snapd on it or is k8s just a snap of some kind
 * zyga is unsure what it is
<ryebot> We
<ryebot> We are building an ami running a bunch of k8s clusters under lxd
<ryebot> the k8s clusters use CDK, which use snaps to install the k8s bins/services
 * zyga sees techno-babble
<zyga> ami's I grok
<zyga> k8s is that kubernetes?
<ryebot> kubernetes*
<ryebot> yes sorry
<Chipaca> ryebot: what's the problem with the refresh schedule?
 * zyga reverses shield polarity and re-reads
<ryebot> Just that (afaik) people could be taking the test at any time of day, so we can't really pick a time to refresh that we can be sure won't interrupt them.
<zyga> ryebot: can you tell me what is the test?
<ryebot> kubernetes certification exam
<zyga> ryebot: when would you want them to test old lxd/kubernetes?
<zyga> aha
<zyga> I see
<ryebot> still in development
<ryebot> zyga: the version probably won't matter most of the time, so long as it's compatible with the test constraints
<zyga> ryebot: so here's an idea
<zyga> ryebot: just track the stable channel
<zyga> ryebot: and a specific version therein
<zyga> ryebot: sure, you may get updates
<zyga> ryebot: but only within that channel
<zyga> and the channel can track, say, version 2.x or 2.3.x (numbers are just examples)
<ryebot> Yes, we currently have them track 1.6.x, the problem is that some of these snaps are services, and so the update can interrupt them
<matiasb> kyrofa, o/ hey, fyi, I'm looking at the r1418 issue with nextcloud, trying to leave it in a consistent/coherent state (just in case you get some emails about state changes); automated review passed, so it should get approved (and then, it will be available through the branch it is released)
<zyga> aha
<kyrofa> matiasb, oh thanks, I saw that it got put into the manual review queue, so I rejected it again and was gonna ping someone asking about that :P
<kyrofa> matiasb, makes sense if you're poking at it
<matiasb> kyrofa, oops, sorry! give me a min and it should get fixed (and run the review for the newer upload automatically)
<kyrofa> matiasb, oh no problem
<kyrofa> matiasb, is this one of the higher rev-count snaps?
<matiasb> kyrofa, there, r1418 back in track, everything should be ok there
<matiasb> kyrofa, it is one of the highest, for sure
 * mcphail notes kyrofa's nextcloud snap is at revision 1337 :)
<zyga> leet :)
<kyrofa> mcphail, yes I was convinced that rev was bug-free. Unfortunately I was wrong :(
<kyrofa> matiasb, thank you!
<Chipaca> ryebot: how urgent is this concern of yours btw?
<Chipaca> ryebot: because there is the idea of being able to tell snapd to not refresh things for a bit, i think (but i'd need to check)
<Chipaca> but it's not even scheduled afaik
<ryebot> Chipaca: Honestly not sure. I mean, it may never happen, or we could really screw up some candidate's tests. The risk appears high enough that the LF devs brought it up.
<ryebot> Chipaca zyga: crazy idea - would disabling the snapd daemon work? :|
<zyga> Chipaca: yes
<zyga> er
<zyga> ryebot: yes
<zyga> ryebot: we also have refresh timer that fires very infrequently
<zyga> ryebot: so you'd have to disable both
<ryebot> also a service?
<Chipaca> ryebot: yep, you can even say 'systemctl disable --now snapd.*' and it'd TTRT
<Chipaca> DDRT even
<ryebot> perfect
<zyga> DTET
<ryebot> thanks guys!!
<zyga> do the evil thing
<ryebot> hahaha
<Chipaca> note that * is for systemctl itself, so you might need to protect it from your shell
<ryebot> gotcha +1
<Chipaca> alternatively systemctl's tab completer is good enough that you can do snapd.<alt *> and it'll complete it for you
<ryebot> alright great I'm going to try this out :)
<zyga> Chipaca: fancy looking at https://github.com/snapcore/snapd/pull/3396
<mup> PR snapd#3396: interfaces: add summary to each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3396>
<zyga> Chipaca: I'd like to do at most one bikeshed iteration, land it, propose more, than iterate ad-infinitum on the language
<zyga> Chipaca: I essentially want to land the first two patches there
<morphis> niemeyer: I've already drop most things I could, trying to remove anything further leads to removal of base system components
<niemeyer> morphis: Can you please paste "rpm -qa" somwhere?
<zyga> scaleway non-compliant "ubuntu" kernel: https://github.com/RocketChat/Rocket.Chat/issues/7000#issuecomment-303668983
<mup> PR snapd#3395 closed: many: remove interface meta-data from list of connections <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3395>
<zyga> Chipaca: I'll land the branch and change the things as suggested after opening another PR, thus completing the set
<zyga> mvo: what is the state of the CE blocker?
<ogra_> pedronis, hmm, did the timing of the device initialization on firstboot change recently ? my hummingboard image shows some weird behaviour
<ogra_> after console-conf:
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ogra@localhost:~$ sudo reboot
<ogra_> and after the reboot:
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name                 Version                   Rev   Developer  Notes
<ogra_> core                 16-2.26.3+git209.2f19233  2020  canonical  -
<ogra_> hummingboard-gadget  16.04-1                   x1               -
<ogra_> hummingboard-kernel  4.1rc                     x1               -
<pedronis> ogra_: nothing that IÂ know of
<ogra_> weird
<ogra_> i have never seen something like that ... either snap list is broken and stays that way all the time ... or it works right after console-conf
<ogra_> having it only work after a reboot is very weird
<pedronis> ogra_: snap changes should tell when things happend
<ogra_> yeah, i just dont know when exactly the reboot happened :P
<ogra_> ogra@localhost:~$ snap changes
<ogra_> ID   Status  Spawn                 Ready                 Summary
<ogra_> 1    Done    2017-05-24T16:16:11Z  2017-05-24T16:16:26Z  Initialize system state
<ogra_> 2    Error   2017-05-24T16:16:24Z  2017-05-24T16:16:49Z  Initialize device
<ogra_> (the error is indeed the serial ... i'm working with --extra-snaps atm)
<pedronis> well, it never finished
<pedronis> if it's in error
<pedronis> so it probably just retrying again and again
<pedronis> so sometimes there's no snap
<pedronis> and sometimes there are some
<ogra_> yeah, i see change 3 now ... same error
<ogra_> seems to loop
<ogra_> interesting
<pedronis> well, it errors
<pedronis> also erroring there might also explode
<pedronis> (which is something IÂ managed to reproduce but need to look into)
<ogra_> http://paste.ubuntu.com/24645391/
<ogra_> well, the stuff doesnt look unusual
<pedronis> ah, no
<pedronis> sorry
<pedronis> yes, that's expected
<pedronis> nothing to do with list
<pedronis> we are interesting in change 1
<pedronis> not change 2
<ogra_> i'm not canonical and kernel/gadget are sideloaded
<pedronis> when the bits of change 1 happened
<pedronis> whether something was unusually slow there
<ogra_> OOOH !
<ogra_> interesting
<pedronis> s/interesting/interested/
<ogra_> http://paste.ubuntu.com/24645393/
<ogra_> the config hook
 * ogra_ seens "namespace" in the error and blames zyga 
<ogra_> :P
<morphis> niemeyer: hm, lost the instance somehow, do you still see it?
<pedronis> ogra_: anyway the times there look immediate
<pedronis> bit confused about snap list
<niemeyer> morphis: If it's around for more than two hours and there's contention for machines, spread will kill it
<pedronis> ogra_: I suppose you to look at those times vs reboots times
<ogra_> yeah
<pedronis> s/to look/have to look/
<ogra_> i guess i need to start over for that and actually capture timestamps
<zyga> ogra_: which kernel are you on?
<ogra_> indeed i didnt at the first run
<ogra_> zyga, "some" kernel ... :P
<zyga> ogra_: 3.x or 4.x?
<ogra_> zyga, could well be missing some bits
<ogra_> 4.1
<zyga> I see
<zyga> let me know if you need help next week
<ogra_> will do
 * ogra_ is happy to finally have a working gadget ... sanitizing the kernel is next
<ogra_> getting uboot to DTRT was rally painful this time
<ogra_> ogra@localhost:~$ htop
<ogra_> cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<ogra_> yeah, definitely kernel bits missing
<zyga> ogra_: can you look for dmesg | grep DENIED
<ogra_> May 24 16:16:25 localhost kernel: [   58.405309] audit: type=1400 audit(1495642585.323:10): apparmor="DENIED" operation="ptrace" profile="/usr/lib/snapd/snap-confine" pid=1563 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined"
<ogra_> zyga, dont bother yet ... i havent touched the kernel at all yet and only went with what was there for this board ... i'm actually surprised it works so well
<zyga> ogra_: you can help yourself out by editing /etc/apparmor.d/usr.lib.snapd.snap-confine.real (just copy it)
<zyga> ogra_: you can switch snap-confine to complain mode
<zyga> ogra_: and load it into the kernel with apparmor_parser -r
<zyga> ogra_: let me know if you need the exact syntax of the file
<ogra_> why does it have that .rela suffix ?
<ogra_> *real
<pedronis> war scars
<ogra_> hahaha
<zyga> yes
<zyga> because dpkg bugs
<pedronis> some backward incompatibility, dependency issue
<zyga> looong story
<zyga> ogra_: just add ",complain" after "attach_disconnected
<zyga> ogra_: that should fix it
<ogra_> zyga, so it does
<ogra_> htop starts
<niemeyer> morphis: We seem to have machines available, and Spread-32 is still running with opensuse
<niemeyer> morphis: Created 8h44 ago
<morphis> niemeyer: it was 61, need to shift that to next monday, running out of time here
<Saviq> is it known that cleanbuild is somewhat incompatible with version-script? http://pastebin.ubuntu.com/24645640/
<niemeyer> morphis: Sorry, I'm getting a bit lost.. you said 32 above, and 32 indeed has opensuse on it..
<niemeyer> 11:01:35Â <morphis>Â niemeyer: Spread-32 is now down to 1.3G, ok for you?
<mvo> zyga: hi, sorry for the slow reply. state of the blocker is that there are two branches up for review, I summarized the short term fix in https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-possible-revert-race-condition/722 - ideally we would have the input from jdstrand on this too. alternatively we could just revert both mknod |N and quotactl and then we just need to merge a single branch not the seccomp-resolver one (hope this explaina
<mvo> tion makes sense?)
<jdstrand> mvo: as it happens, I'm here today after all
<mvo> jdstrand: aha, were you supposed to be off?
<mvo> jdstrand: please let me know if the above forum post makes sense, there is a bit of a problem with the snap-confine syntax/symbols, its summarzied there
<jdstrand> mvo: ok, so I can ignore backscroll and only look at the forum?
<zyga> mvo: no worries :)
<zyga> mvo: yes, I'll follow the post shortly
<mvo> jdstrand: thats probably enough
<mvo> jdstrand: unless the post summarizes the problem not well enough :)
<jdstrand> ok, let me read it
<jdstrand> mvo: oh, I thought there was something in place to say that snapd always needed to start before services. when did that change?
<zyga> jdstrand: we only had that in 15.04 for services AFAIR
<mvo> jdstrand: it got lost along the way, but even if we had it it would still be racy, because snapd needs some (small amount of) time to write the new profiles
<jdstrand> commands shouldn't start before snapd if the login session is supposed to start after snapd
<mvo> jdstrand: so we really need something that is ready only after snapd has completed that profile generation
<zyga> mvo: one more idea
<zyga> mvo: is to have snap run ask snapd to do this
<zyga> mvo: if services start after snapd
<zyga> mvo: then there's no need to have snap run not wake snapd up
<zyga> mvo: it's a bit ... well, but it has some good things as well
<zyga> mvo: like we could refresh on demand this way
<zyga> mvo: or warn about CVEs that snapd synced
<zyga> mvo: lots of ideas are possible
<mvo> zyga: yeah, I think we discussed this but we don't want snapd in the critical path for snap run all the time
<zyga> mvo: but we are adding it back now
<zyga> mvo: after=snapd does that already
<pedronis> mvo: but the ordering solution does that anyway
<zyga> mvo: unless I'm mistaken and after=snapd won't start snapd if it doesn't run already
<zyga> mvo: then we have the problem again
<zyga> mvo: (which is interesting in fedora land for instance, where we don't start on boot)
<mvo> zyga, pedronis: yes, for daemons we would add this dependency. true. it would be better to avoid it IMO but I don't see a way currently
<mvo> (well, seccomp bpf would solve it for seccomp profiles only but that is not a general solution)
<pedronis> well, isn't that the plan of having a profiles/current
<zyga> mvo: one more idea is to laizly mount snaps if snap run talks to snapd
<pedronis> then the dep is just changing that symlink early
<pedronis> that IÂ though was what we discussed the other day
<jdstrand> ok, that was annoying. the power went out
<mvo> pedronis: we did, to me its not fully clear yet if it solves the various cases. but I probably just have not thought enough about it. TBH I like the suggestion of snapd backup-of-state-and-profiles and restore that backup on revert more, at least its clearer in my mind how that would work and what the constrains are
<mvo> zyga: if we put snapd into the snap run path, then yes, it is an interessing idea
<mvo> zyga, pedronis: lets continue in the forum, I need to step out for some minutes and can only reply async
<zyga> ok
 * zyga is preparing for the event
<mup> PR snapd#3398 opened: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398>
<jdstrand> mvo: ok, I responded in the forum. ping me when you want to discuss more
<mup> PR snapd#3396 closed: interfaces: add summary to each interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3396>
<mvo> jdstrand: thank you!
<mup> PR snapd#3399 opened: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399>
<zyga> Chipaca: ^^
<kyrofa> ogra_, are you still around?
<Chipaca> zyga: could you review snapd#3369?
<mup_> PR snapd#3369: many: make shell scripts shellcheck-clean <Created by chipaca> <https://github.com/snapcore/snapd/pull/3369>
<zyga> Chipaca: yes
<zyga> Chipaca: what's going on with GOPATH vs GOHOME?
<cachio> zyga, do you know how long does it take to retry when it is downloading a snap?
<Chipaca> zyga: GOHOME I made up
<Chipaca> zyga: GOPATH is a PATH, ie a list
<zyga> ah
<Chipaca> zyga: we were using it wrong
<zyga> right
<Chipaca> zyga: so I either had to change all the $GOPATH to ${GOPATH%%:*}
<Chipaca> or, what i did
<Chipaca> (%% and not ## because in go the first element in the list is where new stuff goes)
<zyga> Chipaca: done
<zyga> Chipaca: thank you for the review, I tried to make it work well in all cases
<zyga> Chipaca: question about tab completion, where can I test the tab completer returning not only the item but also the description?
<cachio> Chipaca, do you know how long does it take to retry when it is downloading a snap?
<zyga> cachio: we time out after some reasonable time (<< minute)
<Chipaca> cachio: exponential, starting at 200ms
<Chipaca> delay
<Chipaca> no sorry starting at 100ms
<Chipaca> and then 2.5Ã every time
<Chipaca> cachio: it's in store/retry.go
<cachio> Chipaca, ah, ok, thanks
<Chipaca> zyga: anything you'd like changed, wrt your comments in the pr?
<Chipaca> I need to repush anyway because of conflicts, so i can tweak something :-)
<zyga> Chipaca: no, it is fine
<zyga> thanks :-)
<Chipaca> ok
<Chipaca> zyga: the 32k limit on commandlines is rather dated, but it was bytes not lines of input
<Chipaca> by-the-way :-p
<zyga> Chipaca: yes, I know
<zyga> Chipaca: but I think it's not dated, is it changed?
<Chipaca> zyga: it's about 2M
<pedronis> I think it's around 2M
<pedronis> nowadays
<Chipaca> zyga: unless you have a _lot_ of stuff in your environment
<zyga> Chipaca: aha, I didn't know
 * zyga works on slides 
 * Chipaca works on riffs
<mup> PR snapd#3390 closed: tests: remove additional setup for docker on core <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3390>
<morphis> niemeyer: problem on my end is that I lost the connection the spread-32, looks like I removed a bit too much
<morphis> niemeyer: best is if I redo the cleanup on monday and give you a fresh instance to snapshot
<morphis> niemeyer: lost the connection = it got dropped from .spread-reuse.yaml so I don't have the connection information anymore
<mup> PR snapd#3369 closed: many: make shell scripts shellcheck-clean <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3369>
<Chipaca> niemeyer: ping
<Chipaca> https://travis-ci.org/snapcore/snapd/builds/235777521?utm_source=github_status&utm_medium=notification
<Chipaca> ^^ something is or was awry with spread/linode
<niemeyer> Chipaca: Yo
<Chipaca> niemeyer: just travis weirdness i hope
 * zyga -> food
<cachio> niemeyer, is it any way to run many times the same test with spread?
<cachio> niemeyer, I mean, using the same node
<niemeyer> Chipaca: Thanks, pretty strange indeed
<Chipaca> zyga: thank you for pointing out the "git log --oneline" thing
<Chipaca> zyga: it's looking better already (far from perfect still)
<Chipaca> niemeyer: ok to restart that run?
<mup> PR snapd#3400 opened: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<niemeyer> cachio: Other than -reuse, there's no way to retry in a loop right now
<niemeyer> Chipaca: Yeah, no much to do there
<niemeyer> Chipaca: Something awkward seems to have happened.. hard to believe all allocations would fail at the same time silently
<Chipaca> niemeyer: network hiccup?
<niemeyer> Perhaps.. or something else made the process stop
<niemeyer> cachio: Btw, we can easily extend spread to repeat the same test over and over until it fails
<cachio> niemeyer, yes, I'll need that because otherwise I spend to much time retrying manually
<cachio> niemeyer, I'll make the change here
<cachio> niemeyer, most of the failures are very difficult to reproduce
<niemeyer> cachio: Thanks, let me know if you need a hand on that
<cachio> niemeyer, sure
<mup> PR snapd#3400 closed: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<cachio> niemeyer, the change worked verywell
<cachio> niemeyer, I am rexecuting 100 or until the test fails
<cachio> niemeyer, i could reproduce an error by doing that
<cachio> niemeyer, I am not sure if you are interested on add that change to the master, are you?
#snappy 2017-05-25
<niemeyer> cachio_afk: Yeah, definitely.. if it's properly designed I'd be happy to include it
<cachio_afk> niemeyer, ok, I'll push it on friday, tomorrow is national holidays in argentina
<mup> PR snapcraft#1334 opened: tests: use the fake apt cache in deb unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1334>
<mup> Bug #1693423 opened: initramfs error while loading Custom ubuntu core Image on X86 but it works fine in KVM <Snappy:New> <https://launchpad.net/bugs/1693423>
<pstolowski> good morning!
<zyga> hello :)
 * zyga is on his way to the airport
<Chipaca> morning peeps
<mup> PR core-build#13 opened: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
<zyga> Chipaca: hey, good morning
<zyga> I was wondering if anyone is working today, lots of folks have a day off
 * zyga goes offline to conserve battery, ttyl
<pedronis> zyga: hi, I woild be off, but I'm swapping with Monday
<pedronis> instead, so I'm working today
<pedronis> Chipaca: hi, IÂ re-nitpicked a tiny bit, otoh I maybe confused
<Chipaca> pedronis: nicht genitpicken!
<Chipaca> pedronis: better now?
<mup> PR snapd#3401 opened: tests: move static and unit tests to spread task <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3401>
<nottrobin> is there any way to list all available architectures & versions from the CLI? https://forum.snapcraft.io/t/list-available-architectures-versions-through-the-cli/782
<Chipaca> nottrobin: from snapcraft?
<Chipaca> ah, forum post
<Chipaca> answering there
<pedronis> Chipaca: thank you, +1ed
<Chipaca> nottrobin: there you go
<pedronis> so sometimes some prepare project takes 300+ s , sometimes it timeouts taking 20mins
<Chipaca> yeap
<Chipaca> I'd say we bump that timeout, but given that travis itself times out at ~50, it'd be making things worse
<pedronis> do we know which bit goes into taking 20+Â minutes ?
<pedronis> it seems we don't have inner timestamps
<pedronis> so hard to tell
<Chipaca> I myself do not
<Chipaca> I wish spread split the project prepare out
<Chipaca> somehow (*handwaves*)
<Chipaca> so it can be done async ahead of time
<Chipaca> like, have a pool of these things pre-prepared
<Chipaca> but that's probably very hard :-)
<niemeyer> Hello!
<niemeyer> Just spent the last 1.5h reviewing the general snapctl PR.. but will try to get some more sleep while I can! :)
<niemeyer> See you soon.
<Chipaca> ouch
<abeato> pedronis, hey, mind removing the "Blocked" label from https://github.com/snapcore/snapd/pull/3353 ?
<mup> PR snapd#3353: Add support for reboot parameter <Blocked> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<pedronis> abeato: done
<abeato> pedronis, thanks
<abeato> it looks like CI is failing btw, it gives me those ssh timeouts error all the time
<Chipaca> ogra_: i think you're off cavorting today, but if you happen to not be, https://askubuntu.com/questions/867121/snappy-ubuntu-core-64-bit could use a more authoritative answer i think
<Chipaca> heh, should've linked https://askubuntu.com/q/867121/711 to get brownie points
<Chipaca> Â¯\_(ã)_/Â¯
<mup> PR snapd#3363 closed: cmd: test everything (100% coverage \o/) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3363>
<pedronis> cool
<pedronis> Chipaca: have you seen an error about   linode:debian-unstable-64:tests/main/snapd-reexec ?
<Chipaca> I don't think I have
<pedronis> ah
<pedronis> it seems you changed in your branch
<pedronis> let's see if merging master helps
<mup> PR snapd#3400 opened: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<ondra> ogra_ ping
<Chipaca> ondra: holiday in the germanies
<ondra> Chipaca aha, ,makes sense as I can't see any of them online :)
<Chipaca> slowly we might be learning to take time off, at least in small chunks
 * Chipaca curses at spread tests in the abstract
<mup> PR snapd#3374 closed: partition: add directory sync to the save uboot.env file code <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3374>
<pedronis> Chipaca: because they fail with abandon? or something else
<Chipaca> pedronis: because I can't just write a handwavy thing and have them dtrt :-)
<pedronis> ah
<zyga> o/
<zyga> Chipaca: how's the day?
<Chipaca> zyga: not bad! how's yours?
<zyga> Chipaca: the joys of travel from A to B
<zyga> Chipaca: I have an hour till boarding, time to do some work for a change
<Chipaca> speaking of work
<Chipaca> i'm going to go make myself some lunch
<zyga> enjoy :)
 * zyga boards the plane
<Chipaca> fgimenez: if you look at https://codecov.io/bash
<pedronis> niemeyer: snapd#3385
<mup> PR snapd#3385: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>
<Chipaca> fgimenez: there's a check that looks like if [ "$CI" = "true" ] && [ "$TRAVIS" = "true" ] && [ "$SHIPPABLE" != "true" ]
<fgimenez> Chipaca: yeap and on it right now, searching for "TRAVIS_" :)
<niemeyer> pedronis: Cheers
<Chipaca> fgimenez: and inside that it uses a bunch of TRAVIS_ vars
<Chipaca> yeah
<fgimenez> Chipaca: yep, thx
<pedronis> pstolowski: btw we can already see the problem weÂ mentioned:  func (iface *serialPortInterface) AppArmorConnectedPlug, it gets a slotAttrs but inside is using slot.Attrs
<pedronis> for example
<pstolowski> pedronis, every interface has this problem right now, because we only added placeholders in the API
<pedronis> :(
<pedronis> that's a bit of a bad idea
<pedronis> when do we plan to fix these ?
<pstolowski> pedronis, these plug/slotAttrs are not even filled in right now
<pedronis> yea, anyway we really to rethink when we pass Plug/Slot to interfaces
<pedronis> or maybe rename Plug/Slot.Attrs to StaticAttrs and go from there or something
<pstolowski> pedronis, I intended to re-factor all interfaces to use plugAttrs and slotAttrs after the current branch lands, but if we agree on changing all these methods to drop plug and slot, then I will do it first as a prerequisite for current PR
<pedronis> well before dropping we need to understand how they use those,  best would be to drop them and pass something else, second best is to at least rename Attrs on Plug and Slot
<pedronis> pstolowski: I'm also not sure how we use the *Permant* variants, are those called once?
<niemeyer> pedronis: Reviewed
<Chipaca> pedronis: spread tests passed on snapd#3400 fwiw
<mup> PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working <Created by chipaca> <https://github.com/snapcore/snapd/pull/3400>
<pstolowski> pedronis, what do you mean with 'are those called once' ?
<pedronis> pstolowski: I mean they can also use the static attributes it seems
<pedronis> given they take only Plug and Slot
<pedronis> or maybe they should use no attributes at all?
<pstolowski> pedronis, I think it's ok for them to use static attributes from the yaml
<pedronis> but now we say that we can overwrite them
<pedronis> what does that even mean then
<pedronis> the pieces still don't feel like they are clicking together right
<pedronis> pstolowski: anyway some permanent stuff is indeed using attrs, so IÂ wonder what that means to the idea that hooks can override everything
<pstolowski> pedronis, the Permanent* methods see whatever Sanitize* set. but on Connect hooks will be free to overwrite attributes and this will be visible to "connected" snippets.
<pedronis> pstolowski: yes, but that doesn't make a lot of sense for stuff that the Permanent* bits used/assumed
<pstolowski> pedronis, indeed, i hear you
<pedronis> unless we use validate somehow to check per interfaces that stuff that was used by permanent is overriden
<pedronis> s/is/is not/
<pstolowski> sounds complex
<pedronis> well something is off here
<ogra_> jdstrand, i'd appreciate a manual approval of https://dashboard.snapcraft.io/dev/snaps/7691/rev/2/
<pedronis> pstolowski: maybe getting back to no overriding but solving the defaults problem differently might be better
<jdstrand> heh, I was just going through store reviews now :)
<pstolowski> pedronis, i was going to say that.. perhaps the idea of protecting attributes coming from yaml made sense
<ogra_> hah, snap* :)
<pedronis> pstolowski: at least for a first iteration, we can relax later, but right now it feels a bit like boiling too much ocean in one go
<pedronis> otherwise
<pstolowski> pedronis, why don't we leave the problem of defaults to interfaces code? I mean, what's stopping interface code from having a "default-foo" attribute, and then using it as 'foo' if foo wasn't set at runtime?
<jdstrand> ogra_: done
 * ogra_ hugs jdstrand 
 * ogra_ goes back on vacation :)
 * jdstrand hugs ogra_ back
<jdstrand> ogra_: enjoy your holiday :)
<pedronis> pstolowski: we need the defaults in the attributes before we run the policy checks
<pedronis> that's what's about mainly
<pstolowski> i see
<pedronis> pstolowski: the simplest thing IÂ could think of, is we don't let override in general, but the interface can have an optional method to return a list of attrs that can be overridden (usually they will be ones with defaults that is ok to change later)
<pedronis> as far as IÂ know right now we have one interface with this need
<pedronis> content
 * pedronis break
<ryebot> If I install a snap from a file, do they ever subsequently get updated from the store?
<ryebot> or are they stuck at what I installed with?
<pedronis> ryebot: just the .snap without accompanying  assertions (as one can get with snap download) will be stuck
<ryebot> pedronis: that's perfect
<pedronis> ryebot: I fear that sort of reaction, it also completely unchecked
<ryebot> haha ;)
<Chipaca> ryebot: it's also how you build next year's botnet
 * ryebot learns how to mine btc
<pstolowski> niemeyer, +1 for SNAP_COOKIE and cookie;
<pstolowski> niemeyer, then /var/lib/snapd/cookie/ in the fs? (singular 'cookie', not plural)
<niemeyer> pstolowski: Yeah, that sounds good I think
<pstolowski> niemeyer, ok, will change, thanks!
<pedronis> Chipaca: is it possible that I have a version too old of shellcheck?
<Chipaca> pedronis: maybe? why?
<pedronis> I'm getting
<pedronis> # shellcheck source=tests/lib/dirs.sh
<pedronis> ^-- SC1073: Couldn't parse this shellcheck annotation.
<Chipaca> pedronis: it's also possible it's too new :-)
<Chipaca> hrmm
<Chipaca> hadn't seen that one
<Chipaca> pedronis: in travis, or locally?
<pedronis> locally
<Chipaca> and if you're getting this, does this mean travis doesn't actually _have_ shellcheck :-)
<pedronis> possibly
<Chipaca> pedronis: what version of shellcheck do you have?
<pedronis> 0.3.7
<Chipaca> ah, i bumped mine to 0.4.4-2 to check some things mvo spotted
<Chipaca> pedronis: http://mirrors.kernel.org/ubuntu/pool/universe/s/shellcheck/shellcheck_0.4.4-2_amd64.deb
<Chipaca> pedronis: that one should work just fine
<pedronis> I suppoe travis / spread is not running it at all
<Chipaca> 0.4.4-4 uses a newer ghc and needs a rebuild to work properly though, so avoid it (or rebuild it â¦ but that needs a newer ghc â¦ fun all around
<Chipaca> spread almost certainly not, given this
<Chipaca> sadface
<pedronis> well, it's optional, not sure why you though it should be there ?
<Chipaca> pedronis: you assume i thought
<mup> PR snapd#3402 opened: many: error types should be called FooError, not ErrFoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/3402>
<pedronis> Chipaca: yes, that one from kernel.org works
<Chipaca> pedronis: it's from yakkety
<Chipaca> https://packages.ubuntu.com/yakkety/amd64/shellcheck/download
<Chipaca> just thought i'd save you a click
<pedronis> Chipaca: I'll look at your refresh branch tomorrow at this point
<Chipaca> pedronis: fair enough
<zyga> Chipaca: hey
<zyga> Chipaca: do you have a moment?
<zyga> Chipaca: can you please refresh my memory on channels and tracks,
<zyga> Chipaca: is it a tuple like (2.x/stable) or am I missing something?
<zyga> Chipaca: and what are the precise terms (stability levels, risk levels, etc)
<Chipaca> zyga: every channel has four risk levels
<Chipaca> zyga: the default channel is called latest
<Chipaca> wait
<Chipaca> no, tracks
<Chipaca> gah
<Chipaca> man it's a bad day for this
<zyga> haha
<Chipaca> zyga: s/channel/track/ in the above :-)
<zyga> should I use the word channel or track to describe the concept?
<Chipaca> zyga: channels come in four risk levels
<Chipaca> ah, you mean in an intro to somebody who's never seen it before sense?
<zyga> yes
<Chipaca> start with channels as risk levels
 * zyga makes some slides
<zyga> Chipaca: are those tuples?
<zyga> Chipaca: can I say (risk-level, channel) ?
<Chipaca> no, just stable/candidate/potato/edge
<Chipaca> I mean, growing the concept didactically in the same way it grew historically works
<Chipaca> talk about channel and risk, and then take a step back and introduce tracks
<zyga> ok, can you give me four examples in growing measure of complexity?
<Chipaca> zyga: hypothetical, or actual?
<zyga> Chipaca: educational :)
<zyga> I bet I will learn as much as my audience now
<Chipaca> zyga: as a first step, you could have a snap that is very low maintenance, that's not seeing active development
<Chipaca> zyga: so all you have is the snap in stable; everybody gets that
<Chipaca> zyga: a good example might be "hello-world", if we can convince mvo to close the spurious channels
<Chipaca> (we've got the same revno in everything)
<zyga> haha :)
<Chipaca> zyga: as a next step, you have something in active development, where there is a snap pushed into 'edge' for testing, and it moves through the channels
<Chipaca> fgimenez: are you a collaborator in hello-world?
<Chipaca> zyga: an example of this would be the core snap, for example
<Chipaca> zyga: 'snap info' shows you the progression nicely (when we haven't messed up)
<fgimenez> Chipaca: nope sorry
<Chipaca> zyga: there you can stop and wave your hands and introduce the idea of people doing this kind of qa for stable at the same time as working on the upcoming release
<Chipaca> zyga: or people having LTS as well as current releases
<Chipaca> zyga: and ask how they'd address this
 * zyga hears everyone chanting "PPAs"
<Chipaca> zyga: so you then show them the mysql snap
<Chipaca> (snap info mysql)
<zyga> ooooh
 * zyga loves that
<zyga> including the funky unicode arrow :)
<zyga> thanks!
<Chipaca> zyga: and then you talk about doing CI/CD
<Chipaca> zyga: and show them snap info etcd
<Chipaca> zyga: (note the 'ingest' track)
<zyga> what is ingest?
<Chipaca> the burningest of burning edges
 * zyga is so glad he asked
<zyga> sounds like a title of a garbage album :)
<zyga> "the burinest of the burn, the edgiest of the edge" (to queer music theme)
<zyga> thanks
<Chipaca> zyga: actually i think the ingest track there is old (note the revno)
 * zyga wonders why in 2017 dragging a slide to another position freezes the office suite for 30 seconds
<zyga> Chipaca: yes, looks like "gimme tasty but as safe as it gets"
<zyga> anyway, I get the concept
<zyga> it's whatever people want
<Chipaca> every project gets to define what they mean, yes
<Chipaca> although, AIUI, tracks are manual, and I think we ask for semantic versioning or sth like that? noise][ might know more
<zyga> aha
<zyga> noise][: ^^ do we have semantic versioning in track names?
<noise][> zyga: https://forum.snapcraft.io/t/channel-terminology-and-policy/551
<zyga> oh, great
<noise][> you have some leeway, but that's the general guidance on policy
<zyga> libreoffice, why is it hard to remove a slide... why do you suck watts doing so...
<zyga> Chipaca: suggestion, snap known <tab><tab> should complete on assertion types
<zyga> would help in discoverability
<zyga> we don't have a forum topic that discusses assertion types (an overview of each) do we?
<Chipaca> zyga: ooh, look at that, nicely documented instead of asking me :-)
<pedronis> zyga:Â IÂ do plan to move over and improve the assertion bits from the wiki to the forum in the next weeks
<Chipaca> pedronis: he's dead jim
<pedronis> ah
<Chipaca> reached out on telegram but he might not be there either :-)
<Chipaca> anyway. EOD for me.
<jdstrand> roadmr: hey, at your convenience can you pull r881 of the review tools?
<roadmr> jdstrand: sure! as it happens it's super convenient right now, should have that rolled out early next week
<jdstrand> roadmr: awesome, thanks!
<jdstrand> roadmr: actually, gimme a sec. since we're doing this, let me update for the new interfaces
<roadmr> jdstrand: hehe I have a script now which prepares the merge request for me and pushes the changes ready to merge-request. It even runs the tools against a small snap to ensure they are sane
<roadmr> jdstrand: (remember that time a file was missing and they didn't even run?)
<roadmr> jdstrand: and oh sure, let me know and I'll send another merge
<jdstrand> roadmr: I do remember that time, and I have my own battery of test snaps
<jdstrand> roadmr: nice!
<roadmr> jdstrand: heh :) yes, mine is just a thin layer of protection. e.g. you could make the tools just return PASS all the time and I'd never notice ;)
<roadmr> jdstrand: 882 or should I wait for more?
<jdstrand> roadmr: that is the one, but I wanted to check the review-tools snap with that. just waiting for it to publish
<roadmr> jdstrand: oh ok no rush :)
 * jdstrand kicks off the test
<jdstrand> zyhey, fyi, https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/3
<jdstrand> meh
<jdstrand> roadmr: ok, yes, r882
<roadmr> jdstrand: here I go
<mup> PR snapcraft#1335 opened: errors: Descriptive error message for bad parts named with uppercase â¦ <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1335>
#snappy 2017-05-26
<mup> PR snapd#3403 opened: Sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3403>
<mup> Bug #1693664 opened: Snapd won't install anbox, Character error <Snappy:New> <https://launchpad.net/bugs/1693664>
<Chipaca> mo'in peeps
<Chipaca> I've got a meeting at the boys' school today so I'll be gone for a chunk of the morning, starting in about 15 minutes
<Chipaca> shout if you need me for something before i'm gone
<pedronis> Chipaca: hi, I'll look at your branches
<Chipaca> pedronis: appreciated as always
<Chipaca> pedronis: one of them went up in the middle of a store outage yesterday, so everything was red. I redid travis, but the others i'd have to repush if needed
<Chipaca> ok, i'm off, will bbl (nominally in 2h)
<fgimenez> hi pedronis, we are still getting crete-key timeouts on ubuntu-16.04-32 (haven't seen it failing on other systems) https://travis-ci.org/snapcore/spread-cron/builds/236217996#L1960
<fgimenez> in the same run https://travis-ci.org/snapcore/spread-cron/builds/236217996#L1960, also -32
<pedronis> fgimenez: not sure why, otoh it would be ok to run those test only on classic amd64
<fgimenez> pedronis: ok, should we wait for more errors to make sure it only timeouts on i386? if not i can propose a PR for disabling them now
<pedronis> fgimenez: let's wait a bit more
<fgimenez> pedronis: ok thx
<pstolowski> hmm i'm getting '- Run configure hook of "core" snap (run hook "configure": 2017/05/26 11:13:09.680326 cmd.go:93: DEBUG: core snap (at "/snap/core/current") is older ("2.26.3+git212.34125a5~ubuntu16.04.1") than distribution package ("1337.2.26.3"))' locally with one of the spread tests; is this something to be worried about or a problem with my local env?
<pedronis> pstolowski: it means what you have outside is older than what you have inside, but I cannot read that message, is it failing or just a debug message
<pstolowski> pedronis, failing
<pedronis> pstolowski: anyway it's failign for other reasons that you don't see
<pedronis> that bit is just debugging
<pedronis> afaict
<pstolowski> something weird with versions - i think this starts failing at:
<pstolowski> Setting up snapd (1337.2.26.3) ...
<pstolowski> + MATCH unknown
<pstolowski> + snap --version
<pstolowski> error: pattern not found, got:
<pstolowski> snap    1337.2.26.3
<pstolowski> snapd   1337.2.26.3
<pstolowski> series  16
<pstolowski> ubuntu  16.04
<pstolowski> kernel  4.4.0-78-generic
<pstolowski> + MATCH unknown
<pstolowski> + /usr/lib/snapd/snap-confine --version
<pstolowski> error: pattern not found, got:
<pstolowski> snap-confine 1337.2.26.3
<pedronis> pstolowski: were is match unknown coming from
<pedronis> IÂ see only one very early in prepare.sh
<pedronis> that should kill the whole run
<pstolowski> pedronis, the spread test i'm running is not doing that explicitely, so must be part of some general preparations
<pedronis> maybe building is failing
<fgimenez> pstolowski: pedronis i've seen that "MATCH unknown -> pattern not found" previously, it is expected to fail if i read correctly https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L96, probably the error is somewhere else
<pedronis> yes, it should day saying that something is weird
<pedronis> with the built snapd
<pedronis> s/day/die/
 * pedronis lunch
<pstolowski> i'm trying on linode now
<pstolowski> but not sure if that's relevant at all
<pstolowski> hmm same error on linode
<fgimenez> pstolowski: do you have a complete error log?
<pstolowski> fgimenez, http://pastebin.ubuntu.com/24665653/
<fgimenez> pstolowski: if the problem is not related to yur branch it should be easy to reproduce, trying that now
<pstolowski> fgimenez, this is failing on a new spread test I added in my branch. but I see no direct relation to my test yet, it's just installing a test snap as any other test, and modifies its config
<fgimenez> pstolowski: something seems to be making the prepare step to fail, i can't reproduce locally, also fwiw the automated execution after the new core was published to edge this morning was good, i've retriggered it and has already passed successfully the prepare stage https://travis-ci.org/snapcore/spread-cron/builds/236247437 (this executes from master)
 * Chipaca returns from the dead
<Chipaca> see, even when i pad these things out i fail to account for the time it takes :-(
<Chipaca> pedronis: thank you for the reviews! I'll get on them in a bit
<ogra_> abeato, oh ... one other thing about the androidboot support, why /writable/androidboot ... i thought we agreed to have an actual /boot/androidboot/  partition available ?
<ogra_> abeato, you could use that directgly
<fgimenez> pstolowski: mmm i'm getting a different error locally from master http://paste.ubuntu.com/24665927/
<abeato> ogra_, using the current userdata partition makes our life easier, and I do not see any advantage in using a separate partition that might not be always available
<abeato> ogra_, we can be flexible though and contemplate both cases
<ogra_> abeato, well, it will require changes to snapd i guess ... since it looks at /boot/<bootloader> (i think ... perhaps i'm wrong though)
<ogra_> to decide what way of mangling it needs to use for the cdmline on updates
<abeato> ogra_, no, no need for changes to snapd, it is transparent for it, so in fact the decision depends on system specific parts
<ogra_> i'm really not sure this is still the case ... but in the past it looked for the mounted /boot partition to detect the right bootloader path
<ogra_> ok, then we're fine i guess
<abeato> ogra_, it just searches for files in /boot/xxx
<ogra_> ok
<fgimenez> pstolowski: looks like i had some leftover files that were making the build to fail, this is from a clean master http://paste.ubuntu.com/24666236/ all seems to be fine
<pstolowski> fgimenez, thanks for checking
<niemeyer> Hellos
<niemeyer> Chipaca, fgimenez, pstolowski: Stand up?
<fgimenez> niemeyer: omw
<Chipaca> niemeyer: omw indeed
<mup> PR snapd#3402 closed: many: error types should be called FooError, not ErrFoo <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3402>
<abeato> ogra_, something else that I'd like to do is to add a modified klicb package in snappy PPA with https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+attachment/4881283/+files/add-reboot-argument-support.patch
<mup> Bug #1692494: klibc does not support reboot arguments <patch> <klibc (Ubuntu):New> <https://launchpad.net/bugs/1692494>
<abeato> ogra_, even if we land in arty we still need that
<ogra_> abeato, did you talk to upstream yet
<ogra_> (infinity ... )
<abeato> ogra_, nope, where does he hang around?
 * abeato tries ubuntu-desktop
<ogra_> abeato, #ubunru-devel
<ogra_> *ubuntu
<abeato> ok
<ogra_> (he's foundations ... really not a desktop guy :) )
<ogra_> if we could SRU it right away we'd not need the PPA ... i woudl prefer that
<pedronis> niemeyer: snapd#3350 , not blocking my current work but would be good to have some feedback, it was planned for the next release
<mup> PR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>
<niemeyer> pedronis: +1
<Son_Goku> anyone able to merge snapd#3403?
<mup> PR snapd#3403: packaging/fedora: sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3403>
<Son_Goku> the stupid failure is just Linode being awful
<niemeyer> Son_Goku: I've restarted the integration tests
<Son_Goku> niemeyer: I'd hope they pass, since it's all dead code to Travis
<Son_Goku> we don't have any Fedora CI yet
<niemeyer> Son_Goku: I always hope they pass as well
<niemeyer> fgimenez: Small comment in #3401
<niemeyer> snapd#3401
<mup> PR snapd#3401: tests: move static and unit tests to spread task <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3401>
<fgimenez> niemeyer: thx on it
<niemeyer> fgimenez: Let's please fix on a follow up.. this is taking 6 minutes out of everything else
<mup> PR snapd#3401 closed: tests: move static and unit tests to spread task <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3401>
<fgimenez> niemeyer: sure, i'll prepare it
<ogra_> kalikiana, you are currently working on the cross stuff iirc ... do you know if there is already a way to use arch specific tags in "build-packages:" in snapcraft.yaml ? (i.e. i want to make gadgets build uboot from source, if i build it on an amd64 system i need gcc-arm-linux-gnueabi installed, on native builds i dont)
<ogra_> (i cant find anything in the docs about that)
<niemeyer> fgimenez: Thank you!
<sergiusens> ogra_: that should iirc work, but for it to work automatically in launchpad there's this https://github.com/snapcore/snapcraft/pull/1253
<mup> PR snapcraft#1253: go plugin: cross-compilation support <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1253>
<sergiusens> specifically https://github.com/snapcore/snapcraft/pull/1253/files#diff-e405f18ae8c707ccb3d5ea4e828718c9R202
 * ogra_ checks (we can move to rocket, i just asked there btw)
<sergiusens> ogra_: don't multi post :-P
<ogra_> :P
<sergiusens> niemeyer: can I have uour thoughts on https://forum.snapcraft.io/t/version-script-helpers/648?u=sergiusens ?
<ogra_> sergiusens, hmm, not really what i want ... that only reacts to --target-arch
<niemeyer> sergiusens: Sure, just let me finish a review and will be there
<sergiusens> thanks, shouldn't take much of your time, but mostly to make sure I captured your suggestion correctly
<mup> PR snapd#3403 closed: packaging/fedora: sync packaging from Fedora Dist-Git <Created by Conan-Kudo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3403>
<niemeyer> cachio_: Reviewed the spread PR.. it's looking pretty good, thanks. Just a few details and should be mergeable.
<cachio_> niemeyer, sure
<niemeyer> sergiusens: Replied, thanks for poking
<Chipaca> pedronis: is there any case where a snap can have a local revision but also a snapid?
<ogra_> snap download ... then you sideload ?
<Chipaca> ogra_: you get the revision from the assert
<ogra_> ah
<pedronis> Chipaca: well, a snap can have a revision (as in SideInfo) with a snap id and some without,  a revision with both would be an incosistent state though
<ogra_> Chipaca, well, do i get the assert if i sideload (and dont snap ack it)
<Chipaca> ogra_: if you don't have the assert, you don't get the snap id
<ogra_> ok
<pedronis> Chipaca: just pointing out it's a per revision/SideInfo property, is not global
<Chipaca> but i don't know what happens if you mix n match; going to try that now
<Chipaca> pedronis: right, but they're at the same level
<Chipaca> they're both in the sequence, not in the snap
<pedronis> yes
<pedronis> each one should be consistent, if you manage to have both it's a bug
<Chipaca> pedronis: basically i'm wondering about this bit of code that sets revision to 0 before checking snapid
<pedronis> Chipaca: where?
<Chipaca> pedronis: in master i think this is store.ListRefresh
<pedronis> store?
<pedronis> or snapstate?
<Chipaca> pedronis: store/store.go
<Chipaca> that's where ListRefresh lives
<pedronis> well, the we check SnapID a line below
<pedronis> IÂ think that code is a bit non-sense
<pedronis> it's not there like that to deal with a real case
<Chipaca> pedronis: maybe i should change it to do the same thing in both cases
<Chipaca> while i'm here
<pedronis> just continue
<pedronis> works for me
<Chipaca> that is, if !revision.Store() || snapID == ""
<pedronis> you could log in one
<pedronis> of the two
<pedronis> anyway
<Chipaca> âfound a snap with rev<0 and snapID != ""! get out the champagne!â
<Chipaca> :-p
<Chipaca> pedronis: thank you
<pedronis> Chipaca: fwiw I think it's from before we fully understood things
<Chipaca> yeah... before...
<Chipaca> because now we totally understand things, yes?
<pedronis> Chipaca: we have a way to install a local unasserted revison on top of a store one, I don't think we have a way to do the reverse though
<pedronis> snap refresh foo will hit that code
<pedronis> Chipaca: I didn't tell you what "things" are
<pedronis> :)
<Chipaca> pedronis: right, but it doesn't matter if a previous revision had a revision and a snapid; it's only current that matters
<pedronis> exactly
<pedronis> that's why we don't have a way to do that
<pedronis> you need to snap remove --revision yourself out of that corner
<pedronis> I think right now
<pedronis> assuming revision there works with local ones
<pedronis> (IÂ don't know if we test for that)
<Chipaca> pedronis: would panicing be appropriate in those cases?
<pedronis> no
<pedronis> panicing is if the non-sense is so big that we cannot really go forward
<pedronis> here we can ignore it
<pedronis> not great
<pedronis> but also no dead snapd trying to refresh either
<pedronis> Chipaca: there's no panic in store atm, except in init()
<pedronis> Chipaca: I think most our panics are either lock related, some early initialisation or early order of ops, or related to marshaling/unmarshaling from state
<pedronis> or wrong types being passed around
<pedronis> (the latter is something our tests should catch)
<Chipaca> hah! just realised
<Chipaca> this test class is still called "UbuntuStoreRepository" :-D
<pedronis> Chipaca: yes, the tests are still using old names sometimes, IÂ would do a separate PR to fix that though
<Chipaca> aww
<Chipaca> alright
<pedronis> Chipaca: search and replace together with real change don't mix well
<Chipaca> pedronis: you are absolutely correct
<pedronis> reworking the retry code I noticed that indeed we don't retry DNS errors
<niemeyer> cachio_: Another pass on the spread PR, and then it GLTM
<niemeyer> LGTM even
<niemeyer> pedronis: Nice, glad that one is simple to fix.. I was afraid it might be something more involved
<kyrofa> Good-lookin?
<niemeyer> kyrofa: GLTM! ;)
<pedronis> niemeyer: well, it might be complicated, for now IÂ find the point where to log them, we might need to look at some examples from spread test run to decide what to do
<pedronis> s/IÂ find/I found/
<kyrofa> Anyone here know anything about squashfuse?
<niemeyer> pedronis: That sounds very close to what cachio_ is working on already.. one of the errors there was precisely a DNS error
<kyrofa> Maybe I should go to the lxc channel
<pedronis> niemeyer: IÂ mean examples once we have the log with the exact internal error
<pedronis> niemeyer: there's a bit of a russian dolls of errors going on (like for connreset)
<niemeyer> pedronis: Yeah, DNS should be easy to reproduce locally
<niemeyer> cachio_: ^
<niemeyer> cachio_: Spread PR is in
<niemeyer> (second point unrelated to first point, sorry for confusing points :))
<niemeyer> I'm taking a break
<Chipaca> i'm taking a beer
<Chipaca> Â¯\_(ã)_/Â¯ðº
<niemeyer> Chipaca: Sounds like a much better idea
<Chipaca> niemeyer: it's 1930 here so it's allowed
<niemeyer> Chipaca: I should try.. the reviews might become much more colorful
<niemeyer> Anyway, biab
<Chipaca> niemeyer: no reviews after beer
<Chipaca> or during, for that matter
<cachio_> niemeyer, how do you usually connect to linode to see tho nodes that are running and their info?
<cachio_> niemeyer, do you use user/pass in the web page?
<niemeyer> cachio_: Yes, to maintain the provide maintenance when necessary I use the administration panel.. when using spread, I don't do that though
<cachio_> niemeyer, because I need a way to monitor nodes, I am trying to reproduce the reboot timeout issue
<cachio_> niemeyer, do you have credentials to share with me?
<niemeyer> cachio_: You can just try to connect to them/ping as usual.. is this not working?
<niemeyer> cachio_: I don't at this time
<niemeyer> cachio_: What happens when you connect to the machine?
<cachio_> niemeyer, I couldn't repproduce the issue yet
<cachio_> niemeyer, I created a specific test for that and I am gonna run it now
<niemeyer> cachio_: Okay, so to get started I suggest opening a  terminal to the machine
<niemeyer> cachio_: The web interface won't be doing much better than that
<cachio_> niemeyer,
<cachio_> ok
<niemeyer> cachio_: Then monitor if the machine is rebooting at all, or if it's stuck
<niemeyer> cachio_: If it gets stuck at a point where there's no network, then please ping me and I'll try to see via the console
<cachio_> ok
<cachio_> niemeyer, apart of this one, I want to raise an issue for the econnreset test
<cachio_> niemeyer, should I create a forum topic? or go to launchpad?
<niemeyer> cachio_: Depends a bit on the content/context.. you already have two topics on the forum for "chasing unreliable tests" and "dealing with flaky tests".. perhaps one of these is a good starting point?
<cachio_> niemeyer, ok
<cyphermox> niemeyer: is there a way I can bring up a bug (fixed by SRU in ubuntu classic) to attention for ubuntu-core? it would require an update of the core snap
<cyphermox> https://bugs.launchpad.net/netplan/+bug/1672740
<mup> Bug #1672740: Netplan replug function is incompatible with ath9k_htc module <verification-needed> <netplan:Fix Released by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1672740>
<niemeyer> cyphermox: Device category in the forum might be a good place
<cyphermox> there's already a bug in launchpad, isn't there a real bug tracker?
<niemeyer> cyphermox: Sorry, I'm not sure of what you're actually looking for.. Launchpad is a real bug tracker.. the forum is a good place to talk. What are you looking for?
<cyphermox> reporting the bug to you.
<cyphermox> there is a bug in launchpad already, that affects ubuntu classic; it also needs an update of the core snap
<kyrofa> also-effects snappy?
<cyphermox> it's the snappy project? I wasn't sure as there's also "ubuntu-core".
<kyrofa> cyphermox, haha, I'm not familiar with that one. I typically use snapd for snapd-specific things (interfaces, etc.), and snappy for larger system things (e.g. core snap, image issues)
<kyrofa> (but just because that's what I do doesn't mean it's the right thing, either)
<kyrofa> cyphermox, note that the core snap is also used on classic, so another vote for snappy over ubuntu-core
<daker> hello, does anyone know if there is an nginx snap available ?
<kyrofa> daker, not standalone that I know of, no. Typically it's bundled
<daker> kyrofa: do you have a .snapcraft of it ?
<kyrofa> daker, all I've got myself is apache
<daker> kyrofa: hmm, ok thanks
<zyga> o/
<zyga> any news on the error spike?
#snappy 2017-05-27
<Hilikus> hello
<Hilikus> are there any instructions on how to install snappy core on a pre-made partition? i want to dualboot my raspberry pi but the installation instructions on the docs talk about dd'ing the disk image which will probably overwrite my partition table
<liuxg> tvoss, ping
<donofrio> o.0
<donofrio> opps wrong channel
 * ogra_ knows that zyga will like https://github.com/ogra1/hummingboard-gadget and https://github.com/ogra1/beaglebone-gadget
<zyga> ooooh
<zyga> nice :)
<zyga> thanks for doing that!
<ogra_> :)
<zyga> ogra_: https://media.ccc.de/v/1302-snaps-on-opensuse
<ogra_> wheee!
 * ogra_ G+es
<zyga> thanks
 * ogra_ goes back to the lawnmower
<zyga> enojy :)
<zyga> hey ogra_, what should I see here?
<zyga> ogra_: and can you recommend some good beer?
<Hilikus> is it possible to install ubuntu core on an SSD card that already has raspbian in it? i want to dual boot my raspberry pi
<zyga> Hilikus: hey
<Hilikus> zyga: hello
<zyga> Hilikus: if SSD card you mean SD card then I'm afraid that's not possible, snapd does some magic and resiliency integration around kernel upgrades and to integrate with dual boot we'd have to change a significant number of things
<zyga> Hilikus: I think it's just easier to swap SD cards
<zyga> Hilikus: snapd controls the bootloader and expects specific behavior from it
<Hilikus> sorry yes, i meant sd card
<zyga> Hilikus: so, sorry but not (yet) at least
<Hilikus> ok
<Hilikus> another question, are there any tutorials or examples on using snap for java applications?
<Hilikus> i'm just starting with snap
<zyga> Hilikus: I think so but I'm not sure if there's a java-specifc topic
<zyga> Hilikus: two recommendations, look at forum.snapcraft.io
<zyga> Hilikus: and just look at what's showing up on snapcraft.io today, there's a lot of things that I just don't track
<zyga> Hilikus: I can help you out with snapd internals and bugs
<Hilikus> perfect. will do
<Hilikus> thank you zyga
<zyga> Good luck :)
#snappy 2017-05-28
<mup> PR snapcraft#1330 closed: storeapi: resume snap downloads <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1330>
#snappy 2018-05-21
<mborzecki> morning
<pstolowski|afk> Hey mborzecki
<pstolowski|afk> zyga: hey, noted, i'll investigate reconnect issue in a bit
<mborzecki> pstolowski|afk: hey
<mborzecki> pstolowski|afk: something happened? you're earlier than usual :)
<pstolowski|afk> mborzecki: im not working yet, need to go to school etc and will start as usual. just responded to zyga's issue from the weekend
<zyga> Hey
<zyga> pstolowski|afk: I can still reproduce it. I can get a coffee and try to help
<mborzecki> zyga: hey
<pstolowski|afk> zyga: thanks, ill be on it in ~1h. my early suspicion is something with conflict checking and retry
<zyga> Ok
<zyga> Ping me please
<pstolowski|afk> zyga: in the meantime can you send me your stat.json?
<zyga> Sure, I saved a copy
<zyga> woah
<zyga> that state file is 34MB long
<zyga> no wonder it takes forever to do anything
<zyga> how big are your state.json files?
<pstolowski|afk> Not at my PC right now.. but a few MBs at most afair
<mborzecki> weren't we supposed to garbage collect entries in the state file?
<zyga> mborzecki: I think we do but not frequently enough for this
<kjackal> Hi everyone. I would like a manual review for this: https://dashboard.snapcraft.io/snaps/microk8s/revisions/45/
<kjackal> Hi, is there anyone from the snapstore online ?
<kjackal> jdstrand , anyone the review is urgent, we need it for ODS
<mup> PR snapd#5179 opened: daemon: fix unit tests on arch <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5179>
<mborzecki> trivial PR ^^
<pstolowski> re
<Jack_> Is there any way to snap a jar file. I searched lot, but I don't get anything to create snapcraft.yaml. please give me some examples.
<mborzecki> zyga: are you back from vacation?
<zyga> Jack_: https://forum.snapcraft.io/t/how-can-i-snap-a-jar/3306
<zyga> mborzecki: nope
<zyga> mborzecki: just not feeling very well today, it's pretty cold in spain
<zyga> mborzecki: my son is no longer sick but now I feel affected :/
<mborzecki> zyga: well, nice & sunny here :) if my phone was less of a potato i'd snap a nice picture
<zyga> mborzecki: 14C so far
<pstolowski> oh, my, i think this huge state file is going to kill my emacs :>
<mborzecki> pstolowski: disable font-lock-mode or use fundamental-mode
<pstolowski> mborzecki: thanks i'll try if I regain control ;)
<mborzecki> pstolowski: ^G^G^G
<zyga> try sublime :)
<zyga> that file has 36M of bytes on one line
<zyga> most editors die on that
<zyga> (become unusably inefficient)
<pstolowski> even json_pp is struggling ;)
<Jack_> @Zyga : I already tried this, but did not work for me, it shows unable to read jarfile. I also checked my path.
<zyga> can you respond on the thread there?
<zyga> many more people participate on the forum than are present on IRC
<Jack_> I will do that...
<pstolowski> allright, emacs survived and loded the file, although gave up on formatting, so i've a big blob
<mborzecki> pstolowski: have you tried passing it through jq first?
<pstolowski> mborzecki: great idea! it actually works
<pstolowski> and I was too optimistic about emacs. it's unusable ;/
<mborzecki> pstolowski: well, hard to admit but there's always vim
<pstolowski> :D
<pstolowski> mborzecki: jq to a txt file, then emacs worked
<kjackal> popey: hello are you there?
<pstolowski> zyga: how many snaps do you have?
<zyga> about a dozen
<pstolowski> zyga: on the problematic box
<zyga> 39
<zyga> woops :)
<zyga> more than a dozen
<zyga> I keep snapd off because otherwise it would drain my battery
<pstolowski> zyga: right
<pstolowski> zyga: so, first observations base on the state file
 * zyga is curious
<pstolowski> zyga: there was a core refresh, and this triggered reconnect for all existing connections. the state is full of hook tasks - 77608 of them - and the core  "reconnect" task is in "Doing" state (but it's not obvious if they are all related to this refresh; lots (all?) of them are still in default state = not started)
<zyga> woooah
<zyga> 77K hook tasks
<pstolowski> the number 77608 looks insane
<pstolowski> not sure what happened, trying to make sense out of it
<zyga> this is my normal development box
<zyga> I just noticed it burns battery very quickly and fan is crazy
<zyga> pstolowski: one thing to consider is if this is in the stable release
<zyga> or just in edge
<zyga> to asses how servere this is
<pstolowski> zyga: reconnect changes landed a few days ago
<zyga> pstolowski: refresh to edge and see if you are affected
<zyga> hey Chipaca
<Chipaca> zyga: hi
<pstolowski> zyga: yep, i'll, just trying to draw some more conclusions from your state
<zyga> anyone else running edge that is affected?
<Chipaca> zyga: affected by what?
<zyga> Chipaca: 77608 hook tasks when refreshing core
<Chipaca> zyga: that's more than 3
<zyga> yes, must be inflation
 * zyga is ill today, sucks to spend a week off in bed :/
<pstolowski> zyga: ok, i think i found a bug, not sure if it fully explains the issue but is definately a problem; the hooks on reconnect (and autoconnect) has change=nil
<pstolowski> *have
 * zyga wonders how to fix affected systems
<pstolowski> zyga: I just refreshed to edge and this didn't happen. 2.32.9+git733.7f74160~ubuntu16.04.1
<pstolowski> i've 19 snaps
<pstolowski> zyga: when you first noticed it did you stop/start snapd multiple times?
<zyga> pstolowski: I stop it every time it starts
<zyga> pstolowski: I aborted the change
<zyga> but subsequent refresh does the same thing
<pstolowski> zyga: ok. i wonder if this explains the inflation of hook tasks
<zyga> pstolowski: how many tasks would you expect?
<zyga> I didn't restart snapd 70K time
<pstolowski> zyga: sure. 4 hooks for every connection
<pstolowski> so yeah, still doesn't add up i suppose
<pstolowski> would probably be a few hundreds total
<pstolowski> damn, i cannot trigger it.. edge -> stable -> edge worked
<zyga> pstolowski: my core is at 4706
<zyga> maybe start from there
<pstolowski> hmm. how do i do that? --revision is reject for core apparently
<pstolowski> *rejected
<zyga> is it?
<zyga> why?
<pstolowski> $ sudo snap refresh core --edge --revision=4706
<pstolowski> error: cannot refresh "core": Access by specifying a revision is not allowed for this Snap.
<zyga> you need to be a developer
<zyga> of core :/
<pstolowski> uh oh
<pstolowski> zyga: is this a big no-no or can I get added to a list somewhere?
<zyga> I think mvo can add you
<Chipaca> he's off today
<Chipaca> supposedly
<pstolowski> aha
<mborzecki> interesting: https://paste.ubuntu.com/p/8HQHfqQ9SW/
<Chipaca> wat
<eraserpencil> what happens if i accidentally remove /snap/current? how could I get it back?
<pstolowski> eraserpencil: you could carefully recreate it i suppose, it's a symlink
<Chipaca> eraserpencil: or you can disable/enable the snap
<eraserpencil> thanks, symlink works
<eraserpencil> Could I ask about instructions kyrofa posted in his blog? I always miss kyrofa because of timezones
<BlueShark> I installed Slack using snap, but it does not auto-start on startup. How to make this happen?
<mup> PR snapd#5180 opened: tests/main/snap-service-timer: account for service timer being in the 'running' state <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5180>
<mborzecki> trivial PR ^^
<mborzecki> any suggestions where to start looking into erorrs in #5134?
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mup> PR snapd#4600 closed: configstate: validate known core.* options <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4600>
<mborzecki> review board needs a refresh
<mup> PR snapcraft#2142 closed: Release changelog for 2.42.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2142>
<mup> PR snapd#4369 closed: interfaces/bulitin: add write permission to optical-drive <Created by diddledan> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4369>
<mborzecki> cachio: hi, #4416 fails in spread shellchecks
<mup> PR #4416: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
<mborzecki> cachio: i can fix those and push the changes
<cachio> mborzecki, ok
<cachio> np
<mborzecki> cachio: pushed shellchecks & merged master there
<cachio> mborzecki, great, thanks a  lot
 * cachio afk
<mborzecki> off to pick up the kids, bb for standup
<kjackal> popey: jdstrand: or anyone from the store, I need help!
<popey> sup?
<kjackal> popey: there is a review request which is  urgent on microk8s
 * jdstrand is looking
<jdstrand> kjackal: I'm going to approve it, but you need to use 'organize' or similar to remove the symlink
<jdstrand> package contains external symlinks: bin/iptables-xml lint-snap-v2_external_symlinks
<kjackal> thank you jdstrand, I am not sure if this can be removed. We need to use the file from the host for now.
<kjackal> We have to do a proper packaging of docker. I do not know what else are we going to find in the fiture if we do not
<jdstrand> kjackal: r45 is approved. there are a bunch after that are not. r45 still needs to be published to a channel
<kjackal> jdstrand: will we go through this review process on every build that has external links?
<jdstrand> kjackal: if you want a later version to be approved, please request a manual remove
<kjackal> thank you
<jdstrand> kjackal: re each time> yes. but your snap is classic, just use /usr/bin/iptables-xml and don't ship the symlink
<jdstrand> remember, with classic snap there is no mount namespace
<jdstrand> kjackal: re docker> that shouldn't be too difficult> just grab the existing packaging, merge into yours and adjust as necessary
<jdstrand> kjackal: please ping me if you need another revision reviewed
<kjackal> I will thanks jdstrand
<mborzecki> re
<diddledan> error: cannot refresh "snapcraft": cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
<diddledan> just this moment
<diddledan> did someone trip over the power cable? :-p
<pstolowski> https://status.snapcraft.io/
<pstolowski> looks good in theory
<pstolowski> could be momentary hiccup
<diddledan> still broken for me
<mborzecki> cachio: standup?
<kjackal> jdstrand: hopefully last favour https://dashboard.snapcraft.io/snaps/microk8s/revisions/55/
<jdstrand> kjackal: done
<jdstrand> kjackal: you still need to publish it
<kjackal> thank you jdstrand, marcoceppi will appreciate your help. Testing this now
<mup> PR snapd#5174 closed: interfaces/default,process-control: miscellaneous signal policy fixes <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5174>
<diddledan> \
<eraserpencil> without using Launchpad, what are some ways I could build snaps for other architectures?
<popey> eraserpencil: build.snapcraft.io ?
<popey> (which uses launchpad under the covers)
<popey> Or maybe travis or circleci?
<eraserpencil> I didnt go with launchpad cause it's not opensource nor do i want it distributed
<popey> ah okay
<Pharaoh_Atem> at this time, there are no options
<Pharaoh_Atem> you can build with snapcraft on a box somewhere, though
<Pharaoh_Atem> that's basically what b.sc.io does
<popey> well, you can host private repos on launchpad.
<Pharaoh_Atem> popey: eraserpencil said "without using Launchpad"
<popey> yeah, he said why
<popey> I'm saying he may be wrong about his reasons why
<Pharaoh_Atem> ah
<Pharaoh_Atem> but he may not have the privilege to upload code to LP at all
<popey> https://launchpad.net/+tour/join-launchpad#commercial
<Pharaoh_Atem> even in a "private repo"
<popey> Yeah, just offering optinos
<eraserpencil> Pharaoh_Atem, what box are you talking about
<popey> also *options
<Pharaoh_Atem> eraserpencil: a computer you set up somewhere
<Pharaoh_Atem> if you use internally something like Jenkins, you can just set up runners that can run snapcraft
<eraserpencil> oh
<popey> the other option is to use lxd locally
<Pharaoh_Atem> lxd doesn't give foreign arches easily, does it?
<popey> you can build i386 from amd64
<popey> eraserpencil: which architectures do you need?
<eraserpencil> I was looking at lxd.. but the guys at #lxcontainers says lxd uses the host's arch
<eraserpencil> arm64
<popey> yeah, arm64 is tricky
<eraserpencil> is qemu + kvm a solution?
<popey> that could work, albeit slow
<eraserpencil> unless arm64 vps...
<popey> yeah, i think we had some success with an arm64 vps.
<popey> kyle has played with that, but he's not here right now.
<eraserpencil> btw, when i run snapcraft, i often notice it runs on one core only, how could I make it run across all cores?
<eraserpencil> what do you mean some success? isnt it no success or possible?
<popey> snapcraft itself runs on one core, but if it spawns make, it usually uses the number of processors/cores
<popey> i don't know what level of success Kyle had, he'll be online soon.
<popey> we can ask him
<eraserpencil> is kyle kyrofa?
<popey> ya
<eraserpencil> ahh, i need a chat with him. I always miss him because of timezones
<eraserpencil> could you elaborate on spawning make
<popey> so if your application uses "make" to build, then snapcraft will spawn it with multiple cores
<eraserpencil> like plugin: make?
<popey> ya
<eraserpencil> okay. Thanks alot
<popey> np
 * ogra_ wonders what eraserpencil means by "not opensource" ... LP surely is opensource since 9 years ... http://blog.launchpad.net/general/launchpad-is-now-open-source
<eraserpencil> ogra_: to use launchpad non-private, the code has to be open-source..which mine isnt
<ogra_> ah *your* code is not opensource ... now i get it
<zyga> re
<zyga> pstolowski: hey, any updates?
<pstolowski> zyga: i've found one unrelated non-critical bug. all the problematic tasks have nil change id, i looked at the changes in this code  from last few days but couldn't find the cause. with current edge I couldn't reproduce it (and I've expected number of hooks and they have correct change ids). i hope to be able to repro when mvo adds me to the core devs
<pstolowski> zyga: in the meantime i'm still looking at the code
<zyga> pstolowski: ack, thank you
<zyga> I will keep my snapd offline then, I will be back on Thursday to debug in case we don't find the smoking gun
<kyrofa> eraserpencil, any chance you're around?
<eraserpencil> kyrofa: hey!
<kyrofa> eraserpencil, we seem to have very little i.e. zero timezone overlap :D
<eraserpencil> if you see a post about ROS on the snapcraft forum by me, please ignore it. I think I JUST figure out the mistake
<kyrofa> eraserpencil, the gstreamer one, or another one?
<eraserpencil> aye, GMT+8 does not agree with you.
<kyrofa> eraserpencil, yeah glad you know about the forum, that works very well for this type of thing
<eraserpencil> how's your experience on arm64 VPS?
<kyrofa> eraserpencil, packet.net works well
<niemeyer> zyga: ping
<zyga> niemeyer: yes?
<kyrofa> eraserpencil, I'm curious though: how do you host your code? Private github? Gitlab?
<niemeyer> zyga: Heya.. do you know anything about this message:
<niemeyer> - Setup snap "core" (4571) security profiles (cannot setup apparmor for snap "core": cannot load apparmor profile "snap-update-ns.core": cannot load apparmor profile: exit status 1
<niemeyer> zyga: That's on opensuse 42.3.. are we missing some dep there?
<zyga> hmmm, it looks like we cannot either compile the profile or load it into the kernel
<zyga> is this on your machine?
<zyga> can you save the profile somewhere
<niemeyer> zyga: Also, are you on holiday still? Haven't seen any notes in the forum or list
<zyga> yes, I'm still off, will be back on Thursday
<niemeyer> zyga: That's opensuse, not my machine
<niemeyer> zyga: This is a plain installation from the ground up
<niemeyer> zyga: Brand new machine
<zyga> on 42.3
 * zyga thinks
<zyga> on opensuse apparmor is still disabled
<zyga> so if we try to compile this it is surprising
<zyga> and we definitely don't have the deps
<zyga> (apparmor-profiles, apparmor-parser)
<zyga> I was working on enabling those but there are still some issues (those with init scripts)
<niemeyer> Yeah, surprising indeed
<zyga> which kernel was that running on
<zyga> is this a VM or something else?
<niemeyer> 4.4.104-39-default
<niemeyer> zyga: It's a vm on gce
<zyga> well, this checks out: https://en.opensuse.org/Features_42.3#Linux_kernel -- 42.3 is on long-term 4.4 kernel
<niemeyer> zyga: I've installed it by hand, but we probably have something to fix on the packaging there
<zyga> oh? did you not use our packages?
<niemeyer> zyga: I did exactly what our instructions say
<niemeyer> zyga: Anyway, thanks for the info
<zyga> I see, that's odd, I haven't seen that before
<niemeyer> zyga: Go enjoy your holidays.. we can talk more when you're back and relaxed :)
<zyga> :-)
<zyga> thanks
<zyga> btw, did you hear about the issue that affected my sytem?
<eraserpencil> private github
<eraserpencil> kyrofa: ^^
<kyrofa> eraserpencil, have you experimented with build.snapcraft.io? If it worked with private github (as a commercial offering), would it solve your problem?
<mup> PR snapd#5179 closed: daemon: fix unit tests on arch <Simple> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5179>
<pstolowski> zyga: yes, i explained to issue in the standup
<eraserpencil> kyrofa, I have not, but if it worked then yes
<kyrofa> eraserpencil, we've been mulling that idea over, I'll pass your interest up the chain
<mup> PR snapd#5181 opened: userd: add the "snap" scheme to the whitelist <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/5181>
<cachio> mborzecki, hey
<cachio> kyrofa, hey, do you know if snapcraft already supports the timer for the daemons?
<cachio> kyrofa, I am using version 2.42
<kyrofa> cachio, the timer? What is the keyword?
<kyrofa> cachio, worst case you can use passthrough if it's new
<cachio> Issues while validating None: The 'apps/runner' property does not match the required schema: Additional properties are not allowed ('timer' was unexpected)
<cachio> kyrofa, I see this error
<kyrofa> cachio, indeed, I'm unfamiliar with a "timer" property. Was this discussed in the forum somewhere?
<cachio> kyrofa, https://forum.snapcraft.io/t/add-support-for-service-timers/1068/10
<kyrofa> cachio, indeed, we weren't part of that discussion. You'll need to use passthrough
<cachio> kyrofa, ok, thanks
<mborzecki> cachio: what's up?
<cachio> mborzecki, nothing, problem solved
<cachio> mborzecki, it was about how to use the timer from snapcraft.yaml
<mborzecki> aah ok
<sm0rux> I use Swedish in my Xubuntu 18.04. As soon as I install a snap package I get directories in English. I have ~/Dokument (in Swedish) but when installing a snap package I also get ~/Documents (in English). How can I avoid this?
 * cachio afk
<mcphail> sm0rux: I think it is a known bug, sadly
<sm0rux> mcphail: Thanks for coming back. Sad news, I thought it was a config issue.
<mcphail> https://forum.snapcraft.io/t/snap-does-not-respect-directory-settings/3274 - looks as if a fix is emerging...
<yee_> hi guys, Should be very easy question for you guys. What are the main differences between Ubuntu server 18.04 âliveâ and âalternativeâ? Do they have different purposes?
<sm0rux> mcphail: Thanks a zillion for the link! I thought I was stupid who couldn't fix the locale...
<yee_> what is the cloud-init?
#snappy 2018-05-22
<mborzecki> morning
<mup> PR snapd#5177 closed: interfaces/builtin: allow access to libGLESv* too for opengl interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5177>
<mup> PR snapd#5180 closed: tests/main/snap-service-timer: account for service timer being in the 'running' state <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5180>
<mup> PR snapd#4497 closed: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4497>
<mvo> 5181 looks like an easy win if someone wants to do a quick review
<mup> PR snapd#5181 closed: userd: add the "snap" scheme to the whitelist <Simple> <Created by oSoMoN> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5181>
<mvo> yay, down to 25 PRs
 * mvo hugs mborzecki 
<mborzecki> yup
<mborzecki> wonder if we should have a `snap timers` command, or include some information in the output of `snap services` that some services are timer activated
<jamesh> mvo: hi.  I was wondering if you could help me in registering another snap package for use in some snapd spread tests
<jamesh> mvo: this is to test some interfaces for evolution-data-server's contacts and calendar APIs: so it needs a binary client.
<mvo> jamesh: sure, I just need a (possible empty) snap and I can do this
<jamesh> mvo: I've got a 13 MB test-snapd-eds_0.1_amd64.snap.  Let me see if I can upload it somewhere
<jamesh> mvo: or can you just register the name and add me as a collaborator?
<mvo> jamesh: I can register the name but canont add people before there is a snap. its a store thing
<wgrant> mvo: That changed a couple of weeks back. You can add collaborators from registration now.
<mvo> wgrant: oh, cool
<mvo> jamesh: I can add you without a snap now, thanks to wgrant for this tip
<jamesh> okay.  Well the snap is currently "test-snapd-eds" -- I used a single test snap for both calendar and contacts, since they share much of the client code
<mvo> jamesh: you should have access now
<jamesh> just as I finish uploading it to https://people.canonical.com/~jamesh/test-snapd-eds_0.1_amd64.snap :)
<mvo> jamesh: heh, sorry
<mborzecki> mvo: is there a need to have all *.deb and all *.a files in the all snap image for tests?
<jamesh> no problem.  Blame my slow ADSL :)
<jamesh> I might actually get something faster this year, assuming the NBN rollout doesn't get delayed again
<mvo> mborzecki: probably not, this is the integraton test?
<mborzecki> mvo: yes in ubuntu-core prepare in  #5134
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mvo> jamesh: nice, how much do you have now and how much will you get (if I may ask)?
<mvo> mborzecki: hm, hm, lets kill it. is that triggering the space problem?
<mborzecki> mvo: yeah, the built image is running out of space, and we seem to take 60-80MB of space just with the archives and debs
<jamesh> mvo: On ADSL currently, I've got about 7.6 Mb/s down, 0.9 up.  NBN could potentially go as high as 100/40 (but probably won't hit that in practice)
<mvo> jamesh: nice improvement!
<mborzecki> jamesh: that's nice! is it expensive?
<mborzecki> mvo: so the image is ~400MB, data partition is 346MB, once it's built we have 80MB left, /home/gopath (all of it is copied in prepare) is ~125MB
<jamesh> mborzecki: haven't actually looked at the pricing, since it has seemed so far off.  There are a number of speed tiers for the NBN ranging from 12/1 up to 100/40.  So I'll probably be constrained by price rather than technology
<jamesh> mborzecki: looks like my current ISP is offering AU$70/month for the 12 Mb/s plan, going up to AU$100 for 100 Mb/s
<mborzecki> jamesh: i have some shitty adsl here, it's a bit outside of the city and i'm bit far from the concentrator, paying for 20mbps, actually getting ~12-13mbps, upside is it really costs pennies, ~9eur/month
<mborzecki> jamesh: for comparison, if i were in the city, fiber 100/50 is ~10eur
<jamesh> mborzecki: my current ADSL is $80/month for unlimited data (roughly what the 50MB/s NBN plan costs).  That's a "naked DSL" plan, so there is no line rental on top of that (which would usually be ~ $25/month)
<jamesh> actually, looks like I'm on a grandfathered plan at $70/month
<jamesh> anyway: a lot more than what you're paying :)
<mborzecki> jamesh: yeah
<pstolowski> morning
<jamesh> mvo: Okay, I've an amd64 version of the snap uploaded and requested manual review.  Thank you for your help.
<pstolowski> zyga, i understood the problem you have on your box, i'm starting working on a fix
<mvo> jamesh: it is in but you should talk to jamie to ensure the review-tools gets updated
<pstolowski> mvo: hey, i needed to try to reproduce an issue with an older revision of edge yesterday, but apparently i'm not allowed to specify --revision for core unless i'm in the core snap dev group. i think i don't need older edge anymore (the bug is present in current one as well), but perhaps it may be useful in the future
<pstolowski> mvo: can you add me to the core devs?
<mvo> pstolowski: if you need it to reproduce I'm happy to add you, otherwise I prefer to keep the list as small as possible
<pstolowski> mvo: i see, fair enough
<pstolowski> mvo: i don't think reproducing this particular problem is important anymore, i understand it now
<pstolowski> mvo: it's more about future cases like this
<pstolowski> mvo: so i guess i'm fine if it's on case-by-case basis as need arises in the future, and can be temporary membership
<mvo> pstolowski: thank you
<mvo> pstolowski: that sounds reasonable
<pstolowski> great
<mup> PR snapd#5182 opened: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5182>
<mborzecki> mvo: heh, ok, so the amount of free space is probably some factor of the amount of data in the system partition, with ondra's change, that size has shrunk, so there is less free space and the whole image is ~60% of the old size, https://paste.ubuntu.com/p/ghdFfrT9yJ/
<jamesh> mvo: I think I just have to live with the manual review until the new interfaces get merged to snapd: the review tools are driven off the current snapd version
<mvo> jamesh: ok
<mvo> mborzecki: oh, woah
<mborzecki> mvo: well, it'd be nice if there was a way to pass desired amount of free space in the image
<mvo> mborzecki: don't we calc the image size during the tests? or does our code have no control over that? (pardon my ignorance, I don't remember without looking to the test scripts)
<mborzecki> mvo: we don't
<mborzecki> mvo: well, for sure we don't need go *.a files and *.debs, this will save enough space, then we can think of hardcoding the image size or asking ubuntu-image guys how to force some amount of free space
<mvo> mborzecki: hrm, hrm, I'm sure I miss something. the writable partition should be big. or are using something else here?
<mvo> mborzecki: yeah, this all sounds dubious, iirc ubuntu-image has some code that calculates some free space area but there is iirc an option to override (and again, I think I miss something)
<mborzecki> mvo: afaiu ondra's change, we no longer have 2 copies of the snaps, but instead /var/lib/snapd/snaps files are symlinked to ones from /var/lib/snapd/seed/snaps/
<ondra> mborzecki I don't think this has landed yet, there seem to be some mysterious lock down in tests
<mborzecki> ondra: Could not get lock /var/lib/apt/lists/lock thing? iirc it was resolved by cachio or sth
<ondra> mborzecki yeah that one
<ondra> mborzecki what was the problem? and can somebody then restart test so we can re-check pull request
<mborzecki> ondra: i'm looking in the no space left thing
<mborzecki> ondra: your change seems to have triggered a problem elsewhere
<mborzecki> ondra: i can keep looking into it and push a fix if you don't mind
<mvo> mborzecki: isn't it "just" a matter of tweaking tests/lib/prepare.sh:348 (the ubuntu-image call)
<ondra> mvo yeah that would great
<mvo> mborzecki: and adding --image-size=1G or something?
<mvo> mborzecki: or whatever we need (not sure if the file is sparse so we may need to ensure its not crazy :)
<mborzecki> mvo: yes
<mvo> mborzecki: cool, thank you!
<mvo> mborzecki: and thanks for diving into it :)
 * Son_Goku groans to life
<Chipaca> moin moin
<mvo> hey Chipaca ! good morning
<Chipaca> mvo: welcome back! how're things?
<mvo> Chipaca: good, good. how are you?
<mborzecki> mvo: hm --image-size 700M, the file is 700MB, partition is still 360MB :/
<mvo> mborzecki: :( booo
<Chipaca> i'm without context, but resize was done from initramfs wasn't it?
<mborzecki> mvo: sil2100 says we'd have to list the partition in gadget.yaml to set the desired size
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/5134#issuecomment-390898663
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mvo> mborzecki: don't we use writable?
<Chipaca> i suspected it was related to that :-)
<mborzecki> mvo: writable?
<Chipaca> i'm getting a Â«Running task 3777 on Doing: Reconnect interfaces for snap "core"Â» every 5 seconds
<mborzecki> Chipaca: talk to pstolowski
<Chipaca> pstolowski: OHAI
<mvo> mborzecki: we have two partitons (well, three) on core, system-boot and writable - I'm pretty sure that --image-size used to work to make writable bigger (but not system-boot which should be irrelevant for this test or so I hope)
<mborzecki> mvo: hm maybe it does not work if the partition is not listed in gadget.yaml
<pstolowski> Chipaca: yes, there is at least one critical bug around there that I'm fixing right now. can your try abort it
<pstolowski> ?
<mvo> Chipaca: i started looking into the snapd snap and hit bug #1772584 - I think I might have an idea for a workaround but its all a bit messy
<mup> Bug #1772584: Having a "snap" directory with actual content causes build failures <Snapcraft:New> <https://launchpad.net/bugs/1772584>
<mborzecki> mvo: this is what we have now https://paste.ubuntu.com/p/qStWjg56NV/
<Chipaca> pstolowski: done
<mvo> mborzecki: yeah, thats the default and this should work
<mvo> mborzecki: I can look in a wee bit if that blocks you
<Chipaca> mborzecki: got an error (not reported because I've got SNAPPY_TESTING=1)
<Chipaca> um
<Chipaca> pstolowski: ^ that one was for you
<Chipaca> pstolowski: should I pastebin the report for you instead?
<pstolowski> Chipaca: yes please, not sure what's the context
<Chipaca> by error i mean an oops
<Chipaca> pstolowski: I did "sudo snap abort --last=auto-refresh"
<Chipaca> pstolowski: that succeeded
<Chipaca> pstolowski: or more or less succeeded :-)
<Chipaca> pstolowski: and that ended up in an error i think
<Chipaca> pstolowski: I'll pastebin the whole thing, then you tell me
<mborzecki> mvo: not really blocki, just wanted to push that PR a bit further
<Chipaca> pstolowski: this is the log,  including the oops at the end: https://pastebin.ubuntu.com/p/75RZSmVGmm/
<mvo> mborzecki: yeah, I think this is great (pusing it further)
<Chipaca> pstolowski: let me know if you need anything further to figure it out
<pstolowski> Chipaca: can you send me your state.json?
<Chipaca> pstolowski: people.canonical.com:/home/john/state.json.bz2
<mup> PR snapd#5183 opened: snapcraft.yaml: add minimal snapcraft.yaml with custom build <Created by mvo5> <https://github.com/snapcore/snapd/pull/5183>
<Chipaca> pstolowski: if you can't ssh to p.c.c i can put it elsewhere
<pstolowski> Chipaca: indeed i can't
<Chipaca> pstolowski: you need the vpn up, fwiw
<pstolowski> i haven't used it for years
<pstolowski> Chipaca: right. can you email it?
<Chipaca> pstolowski: sent
<Chipaca> it's 12MB uncompressed, so I bzipped
<Chipaca> pstolowski: also i formatted it and removed secrets from it (i think :-) )
<pstolowski> Chipaca: good, thanks
<pstolowski> mvo: core in edge is very broken because of reconnect bug, can we prevent people from using it (in fact last few revisions are broken)?
<mvo> pstolowski: I think so, I can revert edge to a previous revision, if you tell me which one
<pstolowski> mvo: problem is the PR landed 10 days aog
<pstolowski> *ago
<pstolowski> so you can hit the bug with any revision since then
<mvo> pstolowski: ok
<mvo> Chipaca: if at some point later you have time to talk about the snapd snap that would be great, it feels like we have a lot of work ahead of us :/ I will try to write up something about what we need to do to get there
<mvo> Chipaca: i.e. what is missing etc
<Chipaca> mvo: ok
<Chipaca> mvo: right now i'm working on the conn check branch, beating tests into submission
<mvo> Chipaca: sounds good
<eraserpencil> what is the interface to choose if i wish to expose the Ethernet port?
<popey> eraserpencil: https://docs.snapcraft.io/reference/interfaces
<popey> that's the full list. we don't have one for the ethernet device/port, it's "network"
<popey> (and network-bind if you want to run a server/service)
<pstolowski> Chipaca: the bug you hit is same as zyga's
<Chipaca> pstolowski: huzzah
<zyga> High five
<zyga> All 70000 of them
<pstolowski> so that's what I'm fixing. there may also be a related problem with conflict checking but i haven't looked into that yet
<pstolowski> basically the issue is that i iterate over all potential connections and create tasks as I go. however, if an error is detected during the iteration (such as conflict with another snap op) i error out (with Retry in some cases), and that leaves already created tasks and they are not assigned to a change. so the main task is retried and it all repeats
<mvo> pstolowski: does 4646    2018-05-11T04:29:24Z  arm64    16-2.32.6+git716.83cec93          edge looks reasonable to go back to? the next one we have is 2018-05-14T04:30:30Z
<pstolowski> mvo: 1 moment
<pstolowski> mvo: that wouldn't include https://github.com/snapcore/snapd/pull/5120 that landed on 05/11 right?
<mup> PR #5120: interfaces: interface hooks for refresh <Critical> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5120>
<mvo> pstolowski: it seems it does not, the r4646 was build 2018-05-11 at 04:29 in the morning
<pstolowski> mvo: good, that solves it for edge
<pstolowski> mvo: i fear we have a potential to hit similar issue with autoconnect logic, and that's in stable already right?
<mvo> pstolowski: autoconnect is in stable, yes
<mvo> pstolowski: hm, at least iirc, let me double check
<mvo> pstolowski: that is "Done    2018-05-22T09:02:31Z  2018-05-22T09:02:33Z  Automatically connect eligible plugs and slots of snap "test-snapd-tools"
<mvo> " ?
<pstolowski> mvo: yes
<mvo> pstolowski: thats in stable
<pstolowski> right, that's what i remembered
<Chipaca> mvo: feedback on my changes to your conncheck pr appreciated
 * Chipaca off to physio
<pedronis> pstolowski: I was reading the logs a bit, what's the issue?  never ending retry cycles?
<pstolowski> pedronis: yes, and continuous adding of hook tasks because of that, and they have no change associated if error out on Retry
<pedronis> pstolowski: the latter is expected, we prune them but probably could be more aggressive, see state.go
<pstolowski> pedronis: hmm that's interesting, i wasn't aware of that
<pstolowski> pedronis: also while working on a fix i think i found another general flaw in reconnect logic
<pedronis> pstolowski: do we know why the we retry forever? some kind of recursive case we didn't consider?
<pstolowski> but that's probably not directly involved in the issue
<pstolowski> pedronis: i haven't actually got the retry logic yet, you found general problem with error handling and focues on that first
<pstolowski> d/you/
<pedronis> ok
<pedronis> let me know if I can help
<pstolowski> thanks
 * Chipaca really off to physio now
<pstolowski> pedronis: would you like to take a look at John's state.json to see if you can spot the cause of retries?
<pstolowski> nb, i think my remark about general flaw in reconnect logic may be premature
<pedronis> pstolowski: the issue might be related to the ordering of refreshes we do now
<pstolowski> pedronis: you mean ordering of refresh vs autoconnect?
<pedronis> pstolowski: the fact that we  refresh core first  and then other snaps in a multi-refresh, I suppose auto-connect/or reconnect of core will never finish now
<mvo> Chipaca: looks great, I will do a formal review now
<pedronis> pstolowski: I think we didn't notice with auto-connect because we don't do anything if the connection is already there which is the common case with core and another snap
<pedronis> pstolowski: you should try to write a test, have core and another snap that has a connected interface to core,  then do a refresh (UpdateMany) that needs to refresh both core and this other one, I think you get the bug
<pstolowski> pedronis: thanks, this sounds plausible
<pstolowski> pedronis: btw, i also proposed https://github.com/snapcore/snapd/pull/5182
<mup> PR #5182: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5182>
<eraserpencil> popey: I was checking the documentation on that, and erm just double checking if there was an "ethernet" option. Thanks anyway, I'll try out network.
<mup> PR snapd#5184 opened: [WIP] interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184>
<mup> PR snapd#5185 opened: tests: shellchecks part 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5185>
<pstolowski> pedronis: thanks for the review
<mborzecki> fwiw #5134 is green now
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<ondra> mborzecki that helped :)
<ondra> mborzecki tests do pass now
<ondra> mborzecki I added you there also comment how to actually change writable size, in case this ever comes back
<mborzecki> ondra: i tried something like this and ubuntu-image seems to ignore any edits to gadget.yaml :/ is there anyhing else i'd need to do beside dropping a new partition entry?
<ondra> mborzecki not really, that there is bug in u-i
<ondra> mborzecki it should not ignore that section
<mborzecki> ondra: maybe what i added made no sense (but then there was no error or whatever)
<ondra> mborzecki you can paste  it to me, and I will see if I can spot some problem
<mborzecki> ondra: let me try your snippet
<pedronis> pstolowski: btw, are you working on writing the test I described?
<pstolowski> not yet, but getting to it, addressed your feedback re reorder PR and finished part of the fix related to error handling. onto test now.
<mwhudson> Chipaca: what was your terrible snap called again?
<mwhudson> ah interdenominational-counterintelligences
<Chipaca> mwhudson: yup
<mwhudson> Chipaca: ah heh another non-maximal field!
<mwhudson> Chipaca: publiser
<mwhudson> *publisher
<mwhudson> (or did you say that already)
<Chipaca> mwhudson: I did not
<Chipaca> mwhudson: good point. Want to register a maximal lp user?
<mwhudson> i'm not sure what the upper limit is there
<Chipaca> mwhudson: probably less than an exabyte
<mwhudson> probably
<mwhudson> https://staging.launchpad.net/~m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789
<mwhudson> Chipaca: ^
 * Chipaca hugs mwhudson 
<mwhudson> https://staging.launchpad.net/~
<mwhudson> m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123
<mwhudson> 456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1234567
<mwhudson> 89m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1
<mwhudson> 23456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m12345
<mwhudson> 6789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789
<mwhudson> m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123
<mwhudson> 456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m1234567
<mwhudson> 89m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789m123456789
<mwhudson> yeah ok so maybe not much less than an exabyte
<mwhudson> (sorry!)
<Chipaca> mwhudson: if it's just  a text field, it might not be much less
<mborzecki> ondra: looks like gadget.yaml comes from gadget snap which is downloaded on every build
<mwhudson> Chipaca: that user has a 3600 char name so...
<Chipaca> mwhudson: I would argue that it's a bug if it's longer than ~20 chars, myself
<niemeyer> Good mornings!
<Chipaca> although I might be convinced to thinking 32 isn't too bad either
<pedronis> Chipaca:   should we s/url/host/  in a bunch of docs, variables  in the connectivity check PR ?
<Chipaca> pedronis: no
<Chipaca> pedronis: accurate documentation is for the feeble-minded
<pedronis> ok :)
 * Chipaca fixes
<mup> PR snapd#5080 closed: many: support 'system' nickname in interfaces <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5080>
<Chipaca> pedronis: fixed
<pedronis> Chipaca: I'm removing your +1 because it has changed so much by you since
<Chipaca> pedronis: that seems fair to me :-)
<Chipaca> I +1'ed it, and then rewrote it
<Chipaca> :-D
<Chipaca> "yeah that's fine, let's do something COMPLETELY DIFFERENT"
<Chipaca> *merge*
<Chipaca> I've been taking lessons from the US congress
<pedronis> let's add a random thing at the last minute before the vote? fix conflicts, non-sense laters?
<pedronis> seems it's a style there
<Chipaca> > @niemeyer approved this pull request.
 * Chipaca dances
<Chipaca> i feel like i should bring out the champagne and the cigars
<mborzecki> Chipaca: (snap)shots for everyone?
<Chipaca> mborzecki: let me sneakily rename them to schnappshots before the merge
 * niemeyer grabs the domain name
<mup> PR snapd#5066 closed: overlord/snapshotstate/backend: introducing the snapshot backend <Complex> <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5066>
<mborzecki> off to school, back for standup
<ondra> mwhudson ah if you are using gadget snap from store, then you are out of luck
<ondra> mwhudson ups sorry wrong nick
<ondra> mborzecki ah if you are using gadget snap from store, then you are out of luck
<ondra> mwhudson you can always change u-i command and pass it own gadget snap instead, but that will make test a bit more static
<mwhudson> ondra: you did it again!
<ondra> mwhudson damn irc client, sorry for that
<mwhudson> heh heh it's funny
<mwhudson> no worries :)
 * mwhudson goes to bed
<ondra> mborzecki you can always change u-i command and pass it own gadget snap instead, but that will make test a bit more static
<ondra> good night :)
<cachio> Son_Goku, hey
<Son_Goku> yo
<cachio> Son_Goku, I am working again with the fedora 28 for google
<cachio> I just see the oslogin package
<Son_Goku> which ones do you need?
<cachio> Son_Goku, https://paste.ubuntu.com/p/g9HByWRgbg/
<cachio> those
<Son_Goku> okay, so you need all three
<Son_Goku> I'll try to work on that today
<cachio> Son_Goku, great, thanks a lot
<mborzecki> re
<mborzecki> master unit tests are broken, i'll be opening a pr in a while
<mborzecki> there should be a github feature that triggers a build on a PR whenever it's about to be merged into master
<mup> PR snapd#5186 opened: daemon: update unit tests to match current master <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5186>
<mborzecki> should fix master builds ^^
<sergiusens> joc, thresh, diddledan, popey, Wimpress https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-42-1/5540 has the snapcraft you want or need (a quick validation, if time permits, would be nice)
<popey> hah
<popey> you always have the snapcraft I need
<joc> sergiusens: thanks, how quick were you hoping for?
<popey> sergiusens: looks like I'm already on edge, so have been using that for at least the last 24 hours
<sergiusens> joc: the test can be quick, but it is not urgent ;-)
<sergiusens> popey: thanks
<mvo> sergiusens: do you want me to write a forum post about the "snap" directory isssue outlined in 1772584?
<sergiusens> mvo: this bug plays nicely with the fact that we also want to make `parts` relocatable for build environments
<sergiusens> but this one is a bit more special even
<mvo> sergiusens: being able to put it all under .snapcraft might also be an option
<sergiusens> because it is our main entry point into the source of truth to build
<mvo> sergiusens: I don't really mind, but the hack I had to do to make it work makes my cry
<sergiusens> mvo: yeah, let's start with a post to brainstomr
<mvo> sergiusens: cool, will do
<sergiusens> hacks always make us want to cry until they stand the test of time, from then on, we are proud of them :-P
<diddledan> sergiusens: I used it yesterday from edge (purposefully) to build gimp 2.10.2 - works great - fixes the argument length issue gimp build was encountering
<popey> yay
<popey> https://usercontent.irccloud-cdn.com/file/11QDTn3O/Good%20news%21
<thresh> sergiusens, hey I've tried the edge multiple times and it worked fine for me - no time to test the actual release atm, sorry
<diddledan> speaking of gimp - I've been building the world because glib needed to be newer than that of xenial, but because I'm now not using the themes and such from the ubuntu repo I'm missing icons that I can't work out how to get back - I'm building gnome-themes-extra and gnome-icon-theme and gnome-icon-theme-extra and adwaita-icon-theme but still there are missing icons :-(
<diddledan> oh, and hicolor-icon-theme, too
<popey> diddledan: is it possible to build using some of the magic kenvandine does to get newer gnome in desktop snaps? (or use 18 core)
<diddledan> using 18 core would probably fix it
<diddledan> how do I do that?
<popey> I installed a snap the other day that pulled in core 18, surprised people are using it already
<popey> https://forum.snapcraft.io/t/the-road-to-core18/5547
<diddledan> it's not official yet is it?
<popey> oh, that's not what you want
<diddledan> "Sorry, you don't have access to that topic!" :-p
<diddledan> that's a secrit topic
<popey> ignore that then
<popey> sorry.
 * diddledan haxx0rs it
<thresh> mmm fresh warez
<popey> i think there's some work still to do in the store and snapcraft before core18 is commonplace
<sergiusens> thresh: having used edge is good enough, thanks!
 * diddledan surmises that popey has insider information from a secrit topic that he can't tell me about that makes popey "think there's some work still to do". 'the road to core18' is long and winding? :-p
<mup> PR snapd#5187 opened: overlord: introduce snapshotstate <Created by chipaca> <https://github.com/snapcore/snapd/pull/5187>
<mup> PR snapd#5186 closed: daemon: update unit tests to match current master <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5186>
<mborzecki> cachio: can you post the *.timer file somewhere?
<jdstrand> roadmr: hi! can you pull r1074 of the review tools? note that most of the changes are around snap usn support, but there are a few things for regular reviews
<roadmr> jdstrand: sure!
<jdstrand> thanks!
<roadmr> jdstrand: we still haven't re-enabled resquash enforcement, right?
<cachio> mborzecki, well, it fails to install and it doers not leave the .timer
<jdstrand> note to channel: ^ that includes support for the new 'timer' yaml
<cachio> mborzecki, is it any way to see the .timer in that case?
<jdstrand> roadmr: that is correct. plan to do it the week of June 4th. electron upstream is the last thing and they are working on it (several commits already pushed)
<mborzecki> cachio: no i think not, what's your snapd version?
<cachio> 2.32.8
<mborzecki> cachio: w8, timers are in 2.33, any timer entry you have there will be ignored
<jdstrand> cachio: note, I'm approving your gce-cleaner snap now
<cachio> jdstrand, ok, thanks
<cachio> mborzecki, weird, I tried with edge and I had same problem
<jdstrand> cachio: all approved. you'll need to publish to a channel
<cachio> mborzecki, let me check it again
<cachio> jdstrand, perfect, tx
<mborzecki> cachio: can you double check that there are no snap.*.timer files before you attempt to install that snap?
<cachio> mborzecki, yes
<cachio> mborzecki, I am refreshing core now, let me try once it is finished
<cachio> mborzecki, I have snapd.snap-repair.timer
<cachio> for example
<mborzecki> cachio: this one is ok, it's part of snapd package iirc
<cachio> mborzecki, https://paste.ubuntu.com/p/ztXv9HSRhw/
<cachio> mborzecki, it is weird becase it works in a xenial machine on google
<mborzecki> cachio: tried 2.32.9, the timers are ignored as expected
<mborzecki> and -git version creates the timer files as needed
<cachio> which systemd do you have?
<cachio> mborzecki, I have systemd 229
<mborzecki> cachio: 238, but that shouldn't matter, the error you had suggests that the timer was incorrectly generated
<cachio> mborzecki, and the core is 16-2.32.9+git734.7763a07 (4718) 91MB core
<mborzecki> cachio: can you post the snap.yaml somewhere?
<cachio> mborzecki, sure
<zyga> jdstrand: Hi
<cachio> mborzecki, https://paste.ubuntu.com/p/DMncjbGVMJ/
<zyga> From redhat docs about the new security issues related to speculative access to the store buffer
<zyga> Since it will take time to enable explicit mitigations in all impacted third-party software, steps have been taken to automatically enable mitigation for some classes of applications. The Linux kernel âseccompâ (âsecure computingâ) framework allows an application to request that limits be placed upon itself, for example, to prevent further use of certain system calls and other system interfaces after its initial startup phase. Seccomp is often
<zyga> used by sandboxes and managed code frameworks to limit the ability for sandbox escape once potentially malicious untrusted code begins to execute. The seccomp framework has been modified in the latest Linux kernel updates such that its use will automatically have the side-effect of disabling Speculative Store Buffer Bypass, equivalent to applications making an explicitly programmed âprctlâ request
<zyga> This implies that all snap software automatically runs slower
<zyga> mvo: ^ FYI
<zyga> Which imo sucks
<jdstrand> zyga: put another way, it means that all snap software is protected
<zyga> From itself? This is infra-process attack
<jdstrand> but yes. speculative execution continues to be a pain
<zyga> Not applicable to snapd mounting a sandbox around an otherwise single-security-level process
<mborzecki> cachio: hm the spec is even the same as our test snap
<cachio> mborzecki, do you want to try it https://github.com/sergiocazzolato/gce-cleaner.git
<mborzecki> cachio: ok, let me fire xenial vm
<zyga> jdstrand: imo, we should prctl this off in snap-confine, software that actually needs this (like browsers) should re-enable it
<zyga> jdstrand: otherwise all software inside a snap seccomp profile becomes slower
<jdstrand> zyga: I have not studied the issue to the extent to say that is ok. tyhicks, do you have an opinion?
<zyga> I havenât studied this in depth either but the article makes a connection between the use of seccomp and implicates that the process must use multiple security contexts inside so should automatically be protected from using the store buffer speculation attack
<mborzecki> cachio: your snap builds and installs just fine
<zyga> That is, doesnât take into account the massive use of seccomp for software that doesnât have multiple security contexts but is under general sandboxing like snapd
<cachio> mborzecki, well, it works for me in a vm on gce
<cachio> on xenial
<cachio> but fails on my machine
<mborzecki> cachio: ok, let me try with edge (that's what you're using right?) in xenial vm
<tyhicks> zyga: this was known and documented in the Ubuntu KnowledgeBase (3rd paragraph of Mitigations): https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Variant4
<cachio> mborzecki, I used edge and stabl
<cachio> e
<tyhicks> zyga: the idea is being secure by default
<jdstrand> zyga (cc tyhicks): snaps can contain anything. I don't think we can assume that a snap doesn't use an affected pattern. also, it sounds like if we disable via the prctrl then an application would have to reenable with the prctl, where as app developers may assume that "since I'm using seccomp, I don't have to do that"
<mborzecki> cachio: well stable does not have timers, so there's that
<jdstrand> zyga: so, for your browser example, turning it off would likely turn it off for all the snapped browsers
<tyhicks> zyga: while the impact of this issue doesn't seem to be very high, it hasn't received a lot of attention yet because it has been embargoed
<zyga> tyhicks, jdstrand: I agree but I find this suboptimal, high-performance software (or games) now runs slower because they just happen to be sandboxed;
<zyga> I'm off for most of this week but I will definitely get back to this issue in snapd context
<jdstrand> zyga: do you know that? have you measured it?
<mborzecki> cachio: xenial vm also working fine :/
<zyga> jdstrand: no, but it is purely a preformance feature (speculative store) so it must have some impact, how grave it is I don't yet know
<jdstrand> zyga: btw, you can't measure yet cause the microcode isn't available yet
<tyhicks> zyga, jdstrand: I've measured about a 3.2% percent performance hit for CPU bound workloads (compiling the kernel using the default kernel configuration)
<jdstrand> tyhicks: I thought we meeded microcode to be able to measure... granted, I am not up on the issue
<tyhicks> jdstrand: yes, you need to have updated microcode to test
<jdstrand> ok
<jdstrand> we don't have that :)
<jdstrand> tyhicks: curious, is it possible (and perhaps desirable) for snaps to opt out of the protection? Ie, it is on be default now, but yaml is introduced that tells snap-confine to use the prctl to turn it off?
<tyhicks> zyga: I'm not saying that you shouldn't make use of the prctl to disable it but you may want to wait a little bit to see how the discussion around this flaw turns
<zyga> tyhicks: ack, I didn't mean to imply ugrency, I'm just reading about this as it is becoming public
<jdstrand> zyga (cc tyhicks): suse said: "A common pattern where this happens would be leaks out of zeroed cryptographic material storage"
<zyga> jdstrand: since we have speciifc interfaces that allow to construct a seccomp sandbox we could tie it to that, perhaps
<jdstrand> zyga (cc tyhicks): there are all kinds of snaps that take sensitive info
<tyhicks> jdstrand: yes, the launcher would need to use the prctl to disable the mitigation and then load the seccomp filter with a newly added (and backported) seccomp filter flag that allows the mitigation to be disabled for applications using seccomp
<jdstrand> it still sounds like by default is the correct choice. *perhaps* a mechanism to opt out would be ok
<zyga> jdstrand: senstive info yes but isn't the whole attack only mountable from within a process? that is a process running untrusted code?
<tyhicks> zyga, jdstrand: this is not a user friendly solution but, for completeness, a user could use the spec_store_bypass_disable=prctl kernel boot option to turn off mitigations for seccomp processes (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown/MitigationControls#CVE-2018-3639)
<jdstrand> zyga: we don't know what snaps are running. maybe it is a lamp stack that is reachable over the internet and processes sensitive info and tries to dtrt with it
<tyhicks> (the default is spec_store_bypass_disable=seccomp)
<jdstrand> tyhicks: yes, I was just going to say that sounds like what people were thinking. set it to something lower then opt into more rather then setting to high and opting out
<zyga> jdstrand: yes, I'm just trying to consider if, among snaps, the only scope of attack is a process attacking itself (by, for example, running untrusted code)
<zyga> jdstrand: or if the scope is larger
<jdstrand> zyga: I can't comment on that. it sounds like due to embargo it hasn't been studied. my point is it is enough of a reason to leave it on (at least by default)
 * zyga nods
<tyhicks> a browser process crunching of arbitrary javascript is an example of a process that isn't attacking itself but is potentially being attacked by an external attacker
<jdstrand> zyga: but opting out sounds difficult since we'd need new kernel support that everyone would need to pick up since all distros are choosing spec_store_bypass_disable=seccomp
<zyga> jdstrand: yes, I agree, it may be a while before an opt-out is even something me way offer
<tyhicks> jdstrand: if distros are supporting spec_store_bypass_disable=seccomp then they're definitely supporting the prctl
<jdstrand> tyhicks: right, but you said we need a new flag backported when =seccomp from kernel command line and we want to opt out
<jdstrand> tyhicks: or did I misunderstand?
<tyhicks> jdstrand: I think you misunderstood
<tyhicks> jdstrand: if the kernel is opting seccomp'ed processes into SSBD, then it very likely supports the prctl and seccomp filter flag to allow those processes to opt out of SSBD
<zyga> is the prctl code public now?
<tyhicks> (the prctl comes before the seccomp patches in the patch set and the seccomp patches rely on the prctl patches)
<tyhicks> zyga: yes
 * zyga pulls his linux tree
<tyhicks> zyga: there's not much need for that - the prctl is simple
 * jdstrand notes that the act of having a seccomp sandbox at all is a performance impact
<jdstrand> regardless of this
<jdstrand> ie, snaps were already a little slower
<zyga> jdstrand: that's true
<jdstrand> an ideally complied seccomp filter will have the most used call first with the least last
 * zyga tries to return to his holidays but this is too interesting
<jdstrand> we can, today, do some instrumenting and reorder our template to add some performance
<jdstrand> the template is in alphabetical order now. we could put open, write, read, etc first
<zyga> jdstrand: that's intereting, I didn't think that the template would be compiled top-to-bottom
<jdstrand> (it is alphabetical because at the time it was not known that the ordering mattered)
<zyga> jdstrand: for instance, today we order it alphabetically
<zyga> (I think we sort it internally)
<jdstrand> zyga: I've thought that we could strace several applications and then see how much each call was hit, and do some ordering in (at least) the template
<zyga> jdstrand: that's a good idea, I agree
<jdstrand> it wouldn't have to be perfect to have an improvement. it would all have to be measured of course
<mborzecki> cachio: not sure what's happening in your system, given the log, the template that's generated seems to have some incorrect characters inside, the 'n' may come from '\n' but we don't use that explicitly when generating the file, so maybe it's some printing problem in systemd/journalctl? to make things even more awkward the snap seems to work elsewhere
<zyga> jdstrand: since seccomp profiles are per-app we might even do some eventual automatic tuning
<cachio> mborzecki, good
<jdstrand> zyga: you mean, like, "if browser-support is plugged, then assume we should tune as a browser" type things?
<cachio> mborzecki, I'll try to update systemd and test with a new version
<zyga> jdstrand: if one-of-set-of-interfaces is plugged then the app has an ability to construct a sandbox so enable the security hardening
<jdstrand> zyga: if so, that shouldn't be out of the realm of possibility. I suspect (but again, just a gut feeling) that we are going to see a top 20 (or whatever) list of syscalls and that putting them ordered first we'd see the biggest benefit, with everything else falling off fast
<zyga> yeah
<jdstrand> who knows, maybe we can just do that and negate tyhicks' 3.2% impact :)
<tyhicks> jdstrand: don't strace! set SECCOMP_RET_LOG as the default seccomp action
 * tyhicks does all this work on seccomp logging and jdstrand just forgets about it...
<tyhicks> ;)
<tyhicks> oh, not the default action but used in place of SECCOMP_RET_ALLOW
<roadmr> :~(
<jdstrand> heh, well, I *had* actually thought of it be then was worried about kernel rate limiting and using a special snap-seccomp
<jdstrand> but sure
<zyga> it'd be nice if we could do SECCOMP_RET_HISTOGRAM or something similar, so that we don't need to log all of them, just increment a per-process counter somewhere
<zyga> maybe with some perf way to get it out
<tyhicks> if you disable rate limiting, you'll probably get much better performance than with strace
<tyhicks> s/if you disable/even if you disable/
<jdstrand> well, I wasn't suggesting measuring under strace, just gathering data, then adjusting the order, then measuring. rinse and repeat
<tyhicks> zyga: definitely an interesting idea but I think that's probably adding too much complexity to seccomp for something that can be done easily in userspace
<tyhicks> SECCOMP_RET_TRACE is probably the best option because the tracer, in userspace, could easily keep a tally
<jdstrand> there are probably system-tap like things that could be done
<jdstrand> ah yes, SECCOMP_RET_TRACE
<pstolowski> pedronis: fyi, still fighting with the test but close, had to move it to managers_test and now its seems to be missing snap declaration only..
<pedronis> pstolowski: that's probably the best place yes
 * cachio lunch
<mvo> sergiusens: I wrote the forum post about the "snap" directory in the source tree now btw
<pstolowski> i'm calling it day, feeling really under the weather. the test for reconnect hasn't been succesfull so far, it's not failing as expected.. i might be missing something still in the setup/mocking
<jdstrand> niemeyer: hi! when you get a chance would you mind reviewing https://github.com/snapcore/snapd/pull/5016? Specifically https://github.com/snapcore/snapd/pull/5016#issuecomment-390186013
<mup> PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<niemeyer> jdstrand: Will do, and thanks!
<jdstrand> np
<mup> PR snapd#5188 opened: tests: ubuntu core abstraction <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5188>
<niemeyer> jdstrand: Perhaps instead of "own" or "owner" we should go with "user"
<niemeyer> jdstrand: Rationale being that this vaguely resembles the u/g/o permission set, except the "o" has the opposite meaning
<jdstrand> niemeyer: I actually like 'owner' because it matches apparmor terminalogy (eg, it is not uncommon to say 'we allow access to this file with owner match'. but, I'm not married to it. your point for 'u'ser is as valid as that
<jdstrand> terminology*
<niemeyer> jdstrand: Ouch.. so many standards :)
<jdstrand> I know
<jdstrand> I guess a regular person might under 'user' better, but 'owner' is pretty clear too since it is very typical to talk about file ownership
<jdstrand> understand*
<jdstrand> I don't have a strong opinion. I'm probably too close to 'owner' to be objective :)
<niemeyer> jdstrand: We might also solve the dilemma by forbidding either, and just assuming the default to be that
<niemeyer> jdstrand: This has the advantage of no ambiguity
<niemeyer> (two syntaxes with same meaning)
<jdstrand> well, user and owner really are communicating the same thing ime
<jdstrand> they could really be interchangable at a high level. I liked 'owner' because 'all' removes 'owner' match and 'owner' (the default) adds it
<jdstrand> at the lower level
<jdstrand> if we take apparmor out of it, it might make sense to use user
<jdstrand> we could use uid
<jdstrand> owner means uid match with apparmor. user with u/g/o corresponds to the uid
<jdstrand> and people understand what a uid is
<niemeyer> jdstrand: I mean we might forbid both of them
<niemeyer> jdstrand: And allow only "read: all"
<jdstrand> oh I see what you mean
<niemeyer> The other syntax is everything we already have today
<jdstrand> I thought you meant find a 3rd alternative
<niemeyer> So we don't need to express it
<jdstrand> that's true
<jdstrand> we could turn it into a boolean then... did we have that conversation already?
 * jdstrand looks in the forum
<niemeyer> Finding "read: own/owner" will make people wonder what it matters
<niemeyer> and the answer is it doesn't
 * jdstrand nods
<niemeyer> jdstrand: I think "read: all" is nice and clear
<niemeyer> jdstrand: We might just omit the other option for now, and keep it as the default
<jdstrand> ok, wfm
<niemeyer> jdstrand: That does not prevent us from having a third option later
<niemeyer> jdstrand: LGTM too
 * jdstrand will summarize and drop 'owner' and leave only all
<niemeyer> jdstrand: Will comment on the PR
<jdstrand> ok
<jdstrand> :)
<niemeyer> jdstrand: Sent the review, with another minor detail
<jdstrand> niemeyer: thanks!
<niemeyer> jdstrand: Sorry, my point about the mishandling of incorrect type was incorrect. The simplifcation note remains, though.
<jdstrand> ack
<JHOSMAN> Hello, how to I can make conecction of Hamachi in Ubuntu Core?
<mup> PR snapd#5189 opened: interfaces/many: miscellaneous updates for default, desktop, desktop-legacy, system-observe, hardware-observe, opengl and gpg-keys <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5189>
#snappy 2018-05-23
<mup> PR snapcraft#2143 opened: lifecycle: don't clean priming area if the snap is being tried <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2143>
<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>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR snapd#5190 opened: tests: new parameter for the journalctl rate limit <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5190>
<mborzecki> morning
<mup> PR snapd#5182 closed: snapstate/hooks: reorder autoconnect and reconnect hooks <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5182>
<mvo> mborzecki: hey, if you don't mind I look at the spread test for the symlink PR
<mvo> 5189 looks like an easy win btw
<mborzecki> mvo: hey, go ahead, had that in my queue but i'm ok looking at something else
<mvo> mborzecki: thanks, it pretty trivial, I will push something in a sec. got a bit of ocd sometimes, sorry
<mup> PR snapd#5189 closed: interfaces/many: miscellaneous updates for default, desktop, desktop-legacy, system-observe, hardware-observe, opengl and gpg-keys <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5189>
<mvo> mborzecki: \o/
<mvo> pstolowski|afk: when you are around, can you please remind me what the problematic PR on master is that we need to look into reverting (for now). I would love to spend some time on 2.33 today
<mborzecki> mvo: i can try to look into exposing appstreamid (or common-id as it was named in the forum)
<mvo> mborzecki: yeah, that sounds great
<mvo> mborzecki: I think we also need to ensure the roadmap is up-to-date after the last sprint, this was not updated yet, was it?
<mborzecki> mvo: no, i don't think so
<mvo> mborzecki: ok, I will do that in a bit then
<jamesh> mvo: could you approve rev 2 of test-snapd-eds?  It's the same as rev 1 but built for i386
<mvo> jamesh: sure, let me do this now
<jamesh> thank you
<mborzecki> mvo: echo tests/main/snap-core-symlinks/task.yaml >> tests/unit/spread-shellcheck/must
<mborzecki> 'error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-hooks": unable to copy /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-hooks/meta/hooks/install to /tmp/snappy-build-416974275/meta/hooks/install: no space left on device'
<mborzecki> https://api.travis-ci.org/v3/job/382511824/log.txt current master build
<mvo> mborzecki: shellcheck> aha, right, let me add this
<mvo> mborzecki: oh? master broken?
<mborzecki> mvo: some tests failed in prepare or eexcute due to no space left, looks weird, restarted it for now and we'll see if it repeats
<mborzecki> mvo: we seem to clean up snappy-build though
<mborzecki> is there anything we keep in /tmp during the tests?
<mvo> mborzecki: I can't think what could fill up /tmp - long shoot - maybe we hit the bug that we discussed yesteday where the state grows?
<pstolowski> mornings
<pstolowski> mvo: i'll prepare it for you in a moment
<mvo> hey pstolowski
<mvo> pstolowski: thank you!
<pstolowski> mvo: we want to target master with this revert right?
<mvo> pstolowski: yes
<pstolowski> ack
<mvo> pstolowski: and once that is in I will branch 2.33
<pstolowski> yep
<mborzecki> pstolowski: hey
<pstolowski> o/
<mborzecki> mvo: there's a conflict in #5134 i can push a quick fix if you're busy
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mborzecki> mvo: pushed :)
<mvo> mborzecki: heh, thank you
<mup> PR snapd#5191 opened: snapstate: revert the addition of "reconnect" task <Created by stolowski> <https://github.com/snapcore/snapd/pull/5191>
<pstolowski> mvo: ^
<mvo> pstolowski: nice
<pstolowski> mvo: no, it's depressing :(. but good we found it early enough
<mvo> pstolowski: indeed, this won't affect anything that was using stable, right? so its fine, we push it back one release :) and it removes the pressure to fix it ASAP we can step back and look at it carefully
<pstolowski> mvo: right
 * mvo hugs mborzecki for finding another real bugs with the spread-shellcheck
<Chipaca> bug #1772844 is interesting
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:New for swem> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<Chipaca> pstolowski: might this be related to the issue you're working on?
<Chipaca> in this one there aren't a bunch of tasks, but snapd gets stuck in 'Automatically connect eligible plugs and slots of snap "gnome-calculator"'
<pstolowski> Chipaca: yes.. but it's on stable on autoconnect. so far we assumed it's only reconnect in edge
<Chipaca> pstolowski: that's the most 'no' yes I've seen in a while
<pstolowski> Chipaca: in other words, yes, most likely same problem. we thought it wouldn't happen on autoconnect
<Chipaca> pstolowski: dangit
<Chipaca> pstolowski: this is Bad
<pstolowski> pedronis: ^
<Chipaca> pstolowski: I leave you to update that bug appropriately then
<pedronis> I didn't  say, it couldn't happen
<pedronis> just that is more rare
<pedronis> but maybe it's actually a different bug that what I think
 * Chipaca puts the bug down and slowly backs away
<pedronis> that's seeding?
<pedronis> then it's related but a different bug
<pedronis> Chipaca: pstolowski: seeding it's always serial
<Chipaca> pedronis: even when one snap has content interfaces and such?
<pedronis> Chipaca: we don't support that
<pedronis> but you should do the right thing
<pedronis> otherwise you are on your own
<Chipaca> pedronis: what's 'that' in this context?
<Chipaca> snapd's performance with a lot of tasks is very very bad :-(
<pedronis> Chipaca: prepare-image doesn't do the right thing atm
<pedronis> but this is not prepare image
<pstolowski> our to-be-fixed conflict logic will fix seeding case i think with no special case for seeding?
<pedronis> pstolowski: no, seeding is special
<pedronis> if you mess up the order of the snaps
<pedronis> you are on your own
<pedronis> unless we teach seeding to sort them for you
<mvo> the seed.yaml is available in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1772844/comments/6 ordering looks vaguely sane
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:New for swem> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<pedronis> except themes
<pedronis> if it's a default provider
<pedronis> no idea about that
<mvo> aha, good point, let me look
<pedronis> as I said, serializing is not really a win here
<pedronis> it makes thing harder not simpler
<pedronis> but seeding is serial since forever
<Chipaca> pedronis: fwiw if it's serialised wouldn't there be no Done tasks after the Do tasks?
<pedronis> Chipaca: ?
<mvo> pedronis: ha! you are right, its a content interface
<pedronis> well, the question is what are the default providers listed in gnome-calculator
<Chipaca> pedronis: https://pastebin.ubuntu.com/p/wfqwkFn7WC/
<Chipaca> ^ plugs from gnome-calculator
<pedronis> ok, so themes
<pedronis> themes
<pedronis> need to come before
<pedronis> the apps
<pedronis> or it will never work
<mvo> nice one
<Chipaca> I'll tell them about it in the bug
<mvo> I mean, nice that we can suggest a workaround so easily
<Chipaca> pedronis: could we detect and warn about this?
<pedronis> we can but in general we need to think what we want to do about this
<pedronis> the fact they don't use prepare-image is also an issue
<pedronis> we could teach prepare-image to do the right thing
<pedronis> (as I said it doesn't)
<mvo> Chipaca: what else is missing for snapshots? I wonder when to branch 2.33
<mup> PR snapd#5191 closed: snapstate: revert the addition of "reconnect" task <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5191>
<Chipaca> mvo: daemon and cmd
<mvo> Chipaca: ok
<pedronis> prepare-image doesn't know about default-providers or bases atm
<pedronis> IÂ think
<pedronis> mvo:  is that ^ right ?
<Chipaca> mvo:  3 files changed, 462 insertions(+), 3 deletions(-)
<mvo> pedronis: I will soon need to teach it at least about bases for the core18 image work
<Chipaca> mvo: (without tests)
<mvo> pedronis: I think so too
<mvo> Chipaca: thats not too bad, I'm sitting on the fence a bit right now if I branch now and merge these bits into release/2.33 or wait until they arrive
<Chipaca> mvo: I don't think snapshots, as they stand, are useful to users
<Chipaca> mvo: there's a ways to go still
<mvo> Chipaca: the upside of branching now is that a) ocd b) more time to test if 2.33 builds everywhere etc
<Chipaca> mvo: this is the very very basic functionality
<Chipaca> mvo: but a user could easily mess up their snaps with it as it stands
<mvo> Chipaca: ok, cool, I think I will branch in this case and start with getting things test-clean in cosmic etc
<Chipaca> mvo: (also the most user-friendly aspect of snapshots is when they're automagic)
<mvo> Chipaca: if they are actively dangerous should we hide them behind a feature flag? like we do for layouts?
<Chipaca> mvo: I think hiding the commands is good enough
<mvo> Chipaca: even better, less work. thank you!
<Chipaca> if we want to talk about them I'd present them as a 'feature preview'
<Chipaca> there's a list of caveats written down somewhere :-)
<Chipaca> mvo: did you see my comment about symlinking snapd in core18?
<mvo> Chipaca: no, let me look
<mvo> Chipaca: in the forum?
<Chipaca> pstolowski: is there a way to unstick my snapd from the megatasks bug?
<pedronis> Chipaca: I  think for seeding we need a stable sort that sorts bases +Â then default providers + then the rest,  and finds and errors on cycles with the default providers
<pstolowski> Chipaca: you need to get onto new edge somehow (which is in fact an older edge image that mvo reverted to yesterday)
<Chipaca> my state.json is 25MB and each task takes 5 seconds to do :-(
<Chipaca> when are we moving to an actual database
<Chipaca> (this is not a puny machine)
<pedronis> well given our todos, not this cycle
<pedronis> sounds a goal for 2020
<mvo> pstolowski, Chipaca I triggered a new core sync so soon there should be a core with the reverted PR
<mvo> pstolowski: each night we get a new edge so I think this is the best option (fast-track the edge with the reverted pr)
<pedronis> Chipaca: also probably easier with split out snapd and epochs
<Chipaca> pedronis: buaah
<pstolowski> mvo: right. but i wonder how hard is it to get out of the 'broken' state and regain control
<pedronis> Chipaca: btw what snaps were involved in your broken change?
<Chipaca> pedronis: core, vlc
<pedronis> ok
<Chipaca> pedronis: if i manually update them one by one should it fix itself?
<pedronis> it will stop you to do that, no?
<pedronis> pending change and stuff
<eraserpencil> join #ubuntu
<Chipaca> pedronis: i abort the auto-refresh one every time it starts
<pedronis> Chipaca: snap refresh vlc then could help
<Chipaca> because all my cores get all hot and bothered
<pedronis> if you sneak it in with the abort
<pedronis> pstolowski: the fact that the refresh exploding  is "core vlc"   still makes me think my theory seems reasonable about what is the bug
<Chipaca> all these prepare-hook-blah tasks are killing it :-(
<pedronis> ?
<pstolowski> pedronis: i'm still unlucky in reproducing it in unit test. it's probably a problem with setup/mock somewhere
<pedronis> pstolowski: your 2nd snap need an interface that autoconnects
<pedronis> to be clear
<pstolowski> hmm
<pedronis> with core
<pedronis> like network I suppose
<Chipaca> pedronis: i mean https://pastebin.ubuntu.com/p/8Yg5jq5wGk/
<Chipaca> pedronis: this is me trying to manually update core on its own
<pedronis> Chipaca: it dies even on its own?
<Chipaca> pedronis: well, it doesn't finish, and seems to be in a loop
<pedronis> or just take forever?
<pedronis> that is stranger
<Chipaca> pedronis: note how e.g. Â«Run hook prepare-slot-home of snap "core"Â» is repeated many times
<Chipaca> pedronis: with different task numbers
<pedronis> that is expected
<pedronis> one for each plug
<pedronis> of home
<Chipaca> I just got tired and aborted it, but even abort is taking ages
<pedronis> I mean, it might be that even the correct behavior
<pedronis> is too heavy
<Chipaca> (and the fans are spinning away like mad)
<Chipaca> load average is > 2 of just snapd
<pedronis> Chipaca: it's going to create connect and hook tasks for each plug to core into the system
<Chipaca> at >2s per task, that's insane
<pedronis> because your db is big ?
<pedronis> because of the previous error
<pedronis> ?
<Chipaca> pedronis: it might be
<pedronis> or in general
<Chipaca> well, they're never quick
<Chipaca> but the >2s is because my state is too big
<Chipaca> (i'm not going to call it a db :-) )
<pedronis> Chipaca: compile a snapd with lower prune times and run it?
<Chipaca> i have 22 installed snaps of different complexity
<pstolowski> we shouldn't create hook tasks at all if not needed, they will be no-op for 99% of snaps i suppose
<Chipaca> 22 installed snaps -> 92 entries in /data/conns
<Chipaca> -> 184 tasks
<Chipaca> at 2s per task, that's 5 minutes on just this
<pedronis> even more
<Chipaca> 6
<pedronis> Chipaca: you need to prune your state
<pedronis> see suggestion above
<Chipaca> but, even at 200ms per task, that's 30 seconds on just this
<Chipaca> that's _still_ too much
<pedronis> this is reverted
<pedronis> but yes, it might be that we need to think
<pedronis> what reconnect really needs to do
<pedronis> to be sane
<Chipaca> there are also some O(NÂ²) that could be pared down, but that's for later
<Chipaca> at least reading the code :-)
<pedronis> pstolowski: reconnect could do the connect only if the snap being installed has hooks on that connection
<pedronis> but we should probably fix the bigger issue first (infinite retries)
<pstolowski> pedronis: yes, we shouldn't create hook tasks if not needed
<Chipaca> ok, with the pruned state it got through the changes ok
<Chipaca> pstolowski: pedronis: note there's also the thing of regenerating apparmor every time instead of just once at the end, which zyga was going to look at at some point
<Chipaca> (this one is visible in the long time the interfaces-many test takes)
<pstolowski> pedronis: another improvement would be to run reconnect/autoconnect only once if two connected snaps are refreshed in one operation
<zyga> That thing may be a but larger but yeah.
<Chipaca> zyga: ohai
<Chipaca> zyga: i thought you were basking in the sun somewhere
<zyga> Hi
<zyga> Iâm going home already
<zyga> Also no longer ill
<zyga> Long way home
<Chipaca> zyga: https://www.youtube.com/watch?v=qmWC5dGVvH4
<mup> PR snapd#5192 opened: testutil: import check.v1 differently to workaround gccgo error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5192>
<pstolowski> pedronis: can you think of anything i could have missed in this managers test - https://pastebin.ubuntu.com/p/fDZMGN8Wmt/ ? all tasks done, 2 connections exist as expected at the end, no conflict/retry reported; only unexpected think is the very last check of 'Done' status on entire change (it's still Doing)
<mvo> Chipaca: a new core in edge with the reverted reconnect is available now
<Chipaca> installing it
<Chipaca> pedronis: pstolowski: about the tasks taking too long: note that i pruned the state back very aggressively to get unstuck, and the first refresh after that was reasonably fast, but the second one after that is already too slow (taking >30s for the 'connecting stuff' phase)
<pedronis> pstolowski: well, if it is still doing, then is not done
<pedronis> pstolowski: do you have a branch I can play with , with this and still the reconnect code ?
<pedronis> pstolowski: lunch here, let me know
<pstolowski> pedronis: i've pushed it to https://github.com/stolowski/snapd/tree/fix-reconnect-conflictcheck
<pstolowski> pedronis: yes, the change is not done, but all tasks in the state are done (including auto-connect and reconnect)
<pstolowski> 2018-05-23T10:38:28Z INFO no handler for task "reconnect", task ignored
<pstolowski> i think that may be the first time i see it in action
<pstolowski> turned out to be useful
<pedronis> pstolowski: is there already a different change in that branch?
<pstolowski> pedronis: yes i changed the logic to check all conflicts upfront
<pstolowski> shouldn't make a difference, but if you want just the test, it's managers_test.go
<pedronis> pstolowski: it doesn't pass if run together with other tests
<pedronis> afaict
<pstolowski> ok, that's possible, i was mostly running it alone, let me check
<pedronis> it gets stuck
<pstolowski> ineed i see it
<pedronis> it doesn't print anything either though :/
<pedronis> pstolowski: I know why it doesn't fail btw
<pedronis> which is probably unrelated to the other issue
<pedronis> with all the tests
<pedronis> pstolowski: the mocking of the response from the server for core has the wrong snap type
<pedronis> so the ordering doesn't happen
<pstolowski> ahh
<pedronis> without the forced order the current code is fine
<pstolowski> where is that exactly?
<pedronis> what?
<pedronis> that=?
<pstolowski> the mocking; what makes it correct/incorrect?
<pedronis> that we default to app
<pedronis> it needs to grow some smarts about type
<pstolowski> uhm, not familiar with that, do we havy any example in any other test?
<pedronis> no
<pedronis> by definition
<pedronis> if we had it would do the right thing
<pedronis> I'm talking about fillHit to be clear
<pedronis> let me see
<pedronis> it's probably easyish
<pedronis> pstolowski: something like this:  https://pastebin.ubuntu.com/p/3HRNvjZMg7/   (haven't checked if it creates other problems with the other tests though)
<pedronis> it also makes the other test fail
<pstolowski> pedronis: thanks a lot! i'll play with it
<pedronis> there is still some other problem with that the test and the others though
<mborzecki> mvo: rewrote spread-shellcheck in python in pyyaml, on my desktop the old shell version needed 3:18 to run through 'spread.yaml tests', the new one does the same in 29s, checking the same number of files
<pedronis> pstolowski: I skipped the new one with that change (@TYPE@), seems it doesn't break other tests
<pstolowski> pedronis: and the new test now behaves completely different (and fails on connections check). now many tests are still not started
<pedronis> pstolowski: it should print RETRY
<pedronis> I suppose
<pedronis> at least once
<pstolowski> pedronis: it didn't. and the tasks are waiting for restart
<pstolowski> and i see we mock restarting in tests.. trying
<pedronis> ah
<pedronis> yea, because core
<kjackal> Hi everyone, what is the proper way to "simulate" a snap refresh? I would like to test the snap refreshing/upgrading before releasing new revisions.
<pstolowski> yes!!
<pstolowski> pedronis: getting RETRY now
<pedronis> good
<pstolowski> pedronis: thank you very much!
<popeycore> Wimpress: yup, my session just died when i snap installed something (again)
<mvo> mborzecki: nice!
<pedronis> pstolowski: let me know if you want to discuss a fix
<pstolowski> pedronis: thanks. i need to figure out what makes the test hang when running entire suite, then will work on the fix
<pedronis> ok
 * cachio afk
<mup> PR snapd#5193 opened: spread-shellcheck: port to python <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5193>
<mup> PR snapd#5185 closed: tests: shellchecks part 2 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5185>
<pedronis> mvo: do you remember why we  used a task adding more tasks and didn't compute bases/default-providers  when constructing the change?
<mvo> pedronis: I don't remember exactly, I think it was related to the fact that when there are multiple changes that needed the same baseit was difficult to ensure the right ordering and also what to do if one of the changes gets aborted/fails but other changes need the base in question
<pedronis> mvo:  I see but in practice  those changes need to conflict (the bit we are missing) so we lose that
<pedronis> there can be at most one change doing things with one of the bases
<pedronis> mvo: the context , is me thinking what we can simplify about conflicts etc
<mvo> pedronis: right, this is certainly an interessting area to simplify things
<pedronis> mvo: I'm also thinking this because we need this kind of static detection for prepare-image
<pedronis> "static"
 * mvo nods
<mup> PR snapd#5192 closed: testutil: import check.v1 differently to workaround gccgo error <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5192>
<mborzecki> mvo: shall we land #5134 ?
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mvo> mborzecki: yes
<mup> PR snapd#5134 closed: Shrink image generated with snap prepare <Created by kubiko> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5134>
<anarcat> so remember how i came here the other day trying to fix the "devmode" off of firefox?
<anarcat> i did
<anarcat> and now it's running 60.0-2
<anarcat> but the fonts exploded somewhat
<anarcat> http://paste.anarc.at/snaps/snap-2018.05.23-08.32.25.png
<anarcat> anyone has a clue wf is going on there?
<anarcat> no problem in chromium, terminals or emacs
<diddledan> anarcat: try closing firefox, `rm ~/snap/firefox/current/.last_revision`, then start firefox again (it should take a few moments to launch because it recaches everything)
<anarcat> diddledan: no go
<diddledan> hmm
 * ogra_ wonders what you mean by "fix the "devmode" off of firefox"
<anarcat> ogra_: for some reason, snap wouldn't update firefox recently - it was stuck on 59... there was a "devmode" flag on the "snap info" output... uninstall firefox and reinstall fixed that problem
<anarcat> but now fonts are all fubar'd
<ogra_> ah
<popey> thats why
<popey> don't use --devmode
<ogra_> well you must have installed it with --devmode at some point
<ogra_> then it wont update ... since thats "developer mode" ...
<anarcat> well thanks
<anarcat> i don't remember using devmode
<anarcat> but that'S not the point here now
<ogra_> right ...
<ogra_> what does "snap version" print ?
<popey> well, it kinda is. if you install in devmode, you break confinement for that application. It might start writing outside the container, where it normally can't.
<popey> which may adversely affect it when you make it confined again
<anarcat> well i totally uninstalled it
<ogra_> well, uninstall/reinstall should theoretically clean that up
<ogra_> but anyway ... "snap version" ?
<anarcat> snap version: http://paste.debian.net/1026157/
<ogra_> hmm, debian
<popey> hm, should work.
<popey> lemme try here. I have a debian vm
<anarcat> i suspect the problem may not be with snappy too
<popey> whats your default locale on the desktop?
<diddledan> my default locale is my computer chair
<anarcat> damn - even "--ProfileManager --new-instance" has screwed up fonts on the first dialog
<anarcat> popey: fr_CA.UTF-8
<popey> hmmm
<popey> ok, testing
<anarcat> actually no, that's the locale i picked on login, the default is "none" (dpkg-reconfigure locales)
<anarcat> damn it
<diddledan> yeah, that's your problem. you should only ever use "C" or "en-US" because languages other than murrican are wrong </troll>
<anarcat> that kind of stuff is so weird
<ogra_> diddledan, wait, what ?!? ...
<diddledan> :-p
<ogra_> diddledan, you should always use C.UTF-8 or en-US.UTF-8 ... !
<ogra_> not just C or en-US
<ogra_> think of the emojis !!!
<anarcat> so how would i clean my firefox profile in the snap universe?
<diddledan> good point
<ogra_> :)
<anarcat> normally, i would just mv .mozilla{,.orig} and try again - would that work here?
<ogra_> anarcat, well, snaps store stuff under ~/snap/firefox/
<popey> if you remove the snap it should go away
<ogra_> right
<diddledan> ð»
<anarcat> well that's one way of fixing the problem :p
<ogra_> uninstalling still removes all user data too
<anarcat> i have a hard time figuring out how the stuff under ~/snap relates to the normal stuff in ~
<anarcat> okay
<ogra_> inore ~
<anarcat> so how can i make a non-destructive test?
<ogra_> ignore ~
<anarcat> tarball ~/snap/firefox/ and rm -rf?
<ogra_> the only really interesting bit is ~/snap/<packagename>
<anarcat> i'd sure like to keep that profile
<ogra_> mv ?
<anarcat> well whatever
<mborzecki> ogra_: C.UTF-8 is not in vanilla glibc, but is patched in debian & rhel
<ogra_> like you'd do with the mozilla dir
<ogra_> mborzecki, so in all relevant distros then :P
<mborzecki> haha !
<diddledan> wait, rhel is "relevant" now?
<ogra_> at NYSE it surely is somehow :)
<ogra_> ... a little ...
<anarcat> okay, so mv ~/snap/firefox{,.orig} && firefox still has garbled fonts
<diddledan> I thought rhel was purely for accountants and lawyers to mark their little tickboxes of compliance
<anarcat> sigh
<anarcat> can i rollback to a previous version or something?
<popey> still updating my debian vm
<popey> lemme confirm first
<anarcat> okay
<diddledan> popey: https://imgs.xkcd.com/comics/update.png
<popey> dammit, ran out of space
<anarcat> FWIW, firefox-esr 52 from the stable debian packages doesn't exhibit the same behavior
<diddledan> well no, it wouldn't, because that's not a snap
<anarcat> well the problem is not necessarily with the snap
<anarcat> s/is/was/, now that i made that experiment i guess
<anarcat> or it's with some quantum shit
<anarcat> although i'm running the same version on my desktop (although with the upstream tarballs) without problems
<anarcat> well, 60.0.1 on the desktop, not 60.0-2
<anarcat> whatever -2 means in that snap
<ogra_> you have both installed at the same time on the same session ?
<ogra_> (perhaps thats an issue)
<diddledan> both _running_ at the same time will be an issue
<diddledan> firefox reuses an already running instance so if you have it running twice from different places that will lead to weirdness
<anarcat> i have both installed at the same time on the same machine
<anarcat> but i do not have both running at once
<anarcat> i would have expected snap isolation to keep such mixups from happening
<diddledan> with X11 you can't isolate to that degree
<anarcat> who said i was running x11? ;)
<anarcat> (i am, but i don't see how it relates, really)
<anarcat> firefox doesn't use x11 to talk to existing processes, as far as i know
<diddledan> X11 is a shared memory system, so if firefox is running externally and inside a snap then they can talk to each other through X11
<anarcat> sure, i know that
<anarcat> but does firefox talk to other ff process over X11?
<anarcat> i would very much doubt that
<anarcat> but whatever, that's besides the point
<anarcat> i started firefox-esr just to confirm the problem didn't happen there
<anarcat> i stopped it
<anarcat> so now we can go back to pretending it doesn't exist
<anarcat> i can remove the files on disk if that makes you feel any better too :p
 * diddledan wonders how deep the rabbit hole is for popey's debian vm
<popey> just rebooted
<popey> installing firefox rev 85 from stable
<diddledan> reboot: https://www.youtube.com/watch?v=l8B5dqjsZUs
<cjwatson> It used to work via X properties, though I can't find any current documentation on how the remote commands stuff works today
<anarcat> cjwatson: really!
<anarcat> cjwatson: i would assume it's just a socket or something simple
<cjwatson> You used to be able to run firefox and have it do stuff to a browser running on another system via X forwarding
<cjwatson> Whether you still can I have no idea - haven't X-forwarded firefox in many years
<anarcat> yuck
<cjwatson> https://hg.mozilla.org/mozilla-central/file/tip/widget/xremoteclient/XRemoteClient.cpp
<anarcat> sounds nasty :)
<anarcat> does FF work in wayland at all?
<cjwatson> There's a d-bus implementation as well
<cjwatson> Dunno how it chooses which to use
<cjwatson> I'm running Wayland and Firefox, but I don't know how to tell whether Firefox is using Xwayland
<anarcat> that's surprisingly hard
<anarcat> even figuring out if your whole session is wayland is non-intuitive
<popey> env | grep SESS
<cjwatson> Ah, you can use xeyes to tell you
<cjwatson> (It can't follow mouse movements over a native Wayland window)
<popey> firefox snap works fine here.
<popey> on debian 9
<cjwatson> So Firefox uses Xwayland AFAICS
<anarcat> cjwatson: yeah, that's the trick i heard
<anarcat> popey: and that too
<anarcat> popey: i'm not surprised
<anarcat> (that it works for you)
<anarcat> i tell you i'm doomed
<popey> sorry :(
<anarcat> i don't even know where to begin to fix those fonts
<anarcat> i haven't touched that machine in days, it's my travel laptop
<anarcat> all of a sudden, boom
<anarcat> and right after i upgrade to 60
<anarcat> so back to that question: how do i downgrade?
<anarcat> or maybe i can try chasing the candidate?
 * Chipaca ~> school run (slow)
<popey> you can switch to any other channel in snap info firefox
<anarcat> last i changed channels i was told it was bad
<anarcat> or is devmode a different thing
<popey> other channels aren't "bad", but if you chose != stable, then you're opting into the risk level that inferrs
<anarcat> maybe i can try "candidate" - 60.0.1
<anarcat> how do i switch channels?
<cjwatson> snap install --candidate firefox
<anarcat> snap "firefox" is already installed, see "snap refresh --help"
<anarcat> i guess i need refresh
<cjwatson> er sorry yes
<anarcat> sudo snap refresh --candidate firefox # seems to work
<anarcat> well
<anarcat> it downloads anyways, i doubt it will actually fix the issue
<anarcat> the weird thing is that *some* website can show fonts correctly
<anarcat> i wonder if i might have a font cache corruption issue somewhere that gets triggered only by firefox
<anarcat> i had that before, i just don't remember wtf happened
<anarcat> 60.0.1 no go
 * anarcat tries sudo dpkg-reconfigure fontconfig fontconfig-config
<anarcat> nope
<anarcat> i can't even imagine how to begin fixing that friggin issue
<anarcat> any other suggestions?
<anarcat> maybe i could clear out everything in snap? like uninstall snap and clear out ~/snap?
<anarcat> er uninstall firefox?
<anarcat> would that help?
<anarcat> well well well
<anarcat> sudo snap remove firefox && sudo snap install firefox # works
<diddledan> you said you'd done that
<anarcat> i did that a few days ago yes
<popey> ahhh
<popey> awesome
<popey> good to hear it's fixed
<anarcat> popey: isn't it? :p
<popey> :D
<anarcat> i have still no frigging clue what happened and that was scary as hell but yaaaay
<anarcat> can't wait for quantum to hit debian packages so i can go back to normal packaging and have someone else to blame, to be honest :p
<anarcat> i guess i could upgrade to buster already
<anarcat> anyways
<anarcat> thanks for the help, popey!
<popey> :)
<diddledan> wow, that'll speed up some builds: https://github.com/snapcore/snapcraft/pull/2111
<mup> PR snapcraft#2111: repo: rollback to using dpkg-deb for deb extraction <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2111>
<diddledan> bet that was the problem with the desktop-helpers
<sergiusens> diddledan: it was
<diddledan> yey for fixing it :-)
<willcooke> hi all, my snapd process has been pegged at 100% for about 30 mins now.  How can I tell what it's doing?  journalctl and syslog dont really tell me anything
<pedronis> willcooke: are you on edge?
<willcooke> pedronis, no
<pedronis> then not sure
<willcooke> ah
<diddledan> that sounds wonky
<willcooke> snap changes tells me it's trying to do something to remmina which I have loaded
<willcooke> maybe if I quit remmina
<willcooke> hm, nope
<willcooke> $ snap changes
<willcooke> ID   Status  Spawn               Ready  Summary
<willcooke> 309  Doing   today at 11:02 BST  -      Auto-refresh snaps "core", "remmina"
<diddledan> would be an interesting test to try quitting remmina to see if that clears the blockage - if so then sounds like a bug in snapd for updating snaps that are active
<popey> This has been brought up on the forum before now.
<diddledan> aah, it's refreshing core, too..
<popey> I think mcpha il brought it up
<diddledan> mcphail did too
<diddledan> I don't worry about people getting pings :-p
<pedronis> willcooke: snap tasks 309 will tell you excatly what is doing
 * mcphail scrolls back
<willcooke> oh, maybe I was running core from edge.
<pedronis> ah
<pedronis> we had a bug that we just reverted there
<mcphail> willcooke: the problem i've had with snap refreshes is the older iteration cannot save state or information after the snap refresh. it may not be relevant to your situation
<pedronis> willcooke: can you confirm if you had edge? snap list or snap info core
<willcooke> pedronis, $ snap info core
<willcooke> name:      core
<willcooke> summary:   snapd runtime environment
<willcooke> publisher: canonical
<willcooke> contact:   snappy-canonical-storeaccount@canonical.com
<willcooke> license:   unknown
<willcooke> description: |
<willcooke>   The core runtime environment for snapd
<willcooke> type:         core
<willcooke> snap-id:      99T7MUlRhtI3U0QFgl5mXXESAiSwt776
<willcooke> tracking:     edge
<willcooke> refresh-date: today at 15:26 BST
<willcooke> channels:
<willcooke>   stable:    16-2.32.8                (4650) 90MB -
<pedronis> yea, tracking edge
<willcooke>   candidate: 16-2.32.8                (4650) 90MB -
<willcooke>   beta:      16-2.32.8                (4650) 90MB -
<pedronis> so you have edge
<willcooke>   edge:      16-2.32.9+git739.16d2434 (4725) 91MB -
<willcooke> installed:   16-2.32.9+git739.16d2434 (4725) 91MB core
<willcooke> I stopped the task and ran it again "manually"
<willcooke> and now it's happy :)
<diddledan> pastebinit
<pedronis> willcooke: ok,  yes it was a bug in edge, we reverted the code and are working on a fix
<willcooke> pedronis, nice one, thanks!
<willcooke> also I learned something today :)
<diddledan> say it isn't so?! learning should be outlawed
<cachio> mvo, hey, it should be great if we could include #5143 as part of 2.33
<mup> PR #5143: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143>
<cachio> mvo, if you could take a look that would be great, thanks
<niemeyer> mvo: Reviewed everything pending for 2.33.. unfortunately all of them have pending issues
<mvo> cachio: sure, lets add 2.33
 * cachio lunch
<cachio> mvo, great, thanks
<mvo> niemeyer: no worries, I can wait until tomorrow and/or cherry-pick the missing PRs
<mvo> niemeyer: thanks for the review!
<mvo> cachio: I commented
<pedronis> pstolowski: have you found the issue with the test?
<pstolowski> pedronis: nope. i only found out that it hangs in snapmgr.Wait() when looping over tombs and waiting on one of them
<pstolowski> this is very weird
<pstolowski> pedronis: and also, it's happening when run in a combination with some tests, but some other do not trigger this.
<pstolowski> for example, running $ go test -check.v -check.f "mgrsSuite.TestHappyStop|TestUpdateManyW"  -> hangs
<pedronis> it's the download
<pedronis> that hangs
<pstolowski> but $ go test -check.v -check.f "mgrsSuite.TestHappyR|TestUpdateManyW" -> doesn't
<pstolowski> hmm don't we hijack/mock it centrally in these tests?
<pedronis> I'm looking
<pedronis> pstolowski: something is not cleaning up IÂ think
<pstolowski> pedronis: the TestHappyStop* tests (there are 2) are enough to trigger this
<pedronis> I think I understand what happens
<pedronis> bit mysterious we didn't hit it before
<pstolowski> what is that?
<pedronis> we set a function to override something
<pedronis> but don't clean it
<pedronis> I'm just surprised we weren't bitten before
<pedronis> pstolowski: this fixes it for me:  https://pastebin.ubuntu.com/p/9jZRjRh6pc/
<pstolowski> \o/
<pstolowski> indeed, it does!
<pstolowski> pedronis: thanks again!
<pstolowski> pedronis: are you about to eod or can we have a HO to talk about the fix?
<pedronis> pstolowski: this is the debugging I added btw to find that:  https://pastebin.ubuntu.com/p/5P8zrGFjxh/,  once you told me it was stuck in wait, first the bit in snapmgr, then taskrunner  and when I saw it was dowload, then the bits in managers_test.go itself
<pedronis> pstolowski: we can have a HO now
<pstolowski> ok, joining in a sec
<pstolowski> pedronis: in the standup HO
<om26er> Which interface shall I use for those errors https://paste.ubuntu.com/p/nFDXWbpgqS/
<om26er> jdstrand: ^
<om26er> maybe I should try network-bind, lets see.
<om26er> nvm, that worked :)
<om26er> popey: Hey! So whenever build.snapcraft.io is fixed, I have two tools snap packaging ready. gradle and axel.
<popey> om26er: awesome
<Chipaca> I'm so glad I decided to start with the spread tests for the last chunk of snapshots work
<Chipaca> already found two integration-y issues :-D
<Chipaca> (comes from all the little changes done to the PRs â¦)
<jkridner> hi ogra.
<jkridner> er, ogra_.
<jkridner> ogra_: anything newer than http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz to start with?
<jkridner> ogra_: should we get an updated kernel/bootloader from rcn-ee.
<jkridner> ogra_: fyi, we've been looking into Ubuntu more seriously due to ROS.
<jkridner> ogra_: the sales guys have all changed, so no one is calling on me anymore. :-)
<kyrofa> jkridner, you're using a beaglebone black?
<jkridner> and Blue and PocketBeagle.
<jkridner> all supported by the same image.
<jkridner> Blue is Black+RoboticsCape
<jkridner> so, ROS is huge. We need an out-of-box experience for ROS. Debian is still a challenge in that regard.
<kyrofa> Ah, okay. None are officially supported, I don't think. Ubuntu Core 15.04 is very old, and not recommended. ogra_ will know if there's a community port for it
 * jkridner won't be around long and will check back in later.
<jkridner> unfortunately, I'm not on this channel via Resin.io.
<kyrofa> jkridner, oh yes, I'm very familiar with ROS :)
<jkridner> should we just go with Bionic and not Snappy Ubuntu Core?
<kyrofa> When you say "out of the box" you mean the experience you provide to end users?
<jkridner> just do a minimal Bionic to run snaps and ROS?
<jkridner> kyrofa: exactly.
<jkridner> where the community how-tos "just work".
<ogra_> jkridner, i have unofficial images at http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/
<jkridner> vs. a bunch of semi-maintained repos of our own (because we don't use ROS everyday).
<kyrofa> There we go, that's the port of ubuntu core 16.04 ^
<jkridner> ogra_: thanks!
<ogra_> jkridner, and kyrofa is our ROS specialist ;)
<jkridner> ah!
<jkridner> kyrofa: does moving to Bionic for ROS support make the best sense?
<kyrofa> jkridner, what ROS version are you using?
<jkridner> then, I just need a sales guy to talk to me about what the impact of shipping Ubuntu on our boards would be.
<jkridner> kyrofa: I want the "latest".
<jkridner> kyrofa: this is mostly in support of universities.
<kyrofa> Yeah, you mentioned you were talking to sales, but the communication has been less than stellar. Can you PM me your contact details so I can fix that?
 * ogra_ would rather go with the "most widely used" ;)
<kyrofa> jkridner, indeed, I agree with ogra, you probably want the LTS
<jkridner> kyrofa: you can find it on bbb.io/about, but I'll PM a direct phone #
<jdstrand> om26er: network-bind, yes. I suggest you take a look at 'sudo snap install snappy-debug ; sudo snappy-debug security'
<jdstrand> :)
<jkridner> ogra_: i think we'd rather be close to the development tip for fixing issues.
<jkridner> ogra_: stable is nice, but a bit against our methodology.
<ogra_> well, there is hope that a ROS-LTS version wont need too many of them :)
<kyrofa> jkridner, alright, kinetic is the current LTS, with Lunar being the most recent release
<kyrofa> Both of which run on 16.04
<jkridner> is that really where we should be?
<jkridner> :-(
<kyrofa> The next release will only be 18.04
<kyrofa> It's due any day
<kyrofa> But there is no ubuntu core based on 18.04 just yet
<ogra_> regarding core i'd clearly go with core 16 which in turn means when you build your ROS snaps you'll also do it on top of 16.04
<ogra_> core 18 might/will/should be around by fall ... but even then it will be young (core is rolling ... but on top of a picked base ... 16 ... 18 etc ... )
<ogra_> and the majority of snaps in the store will still be based on 16 for a while ...
<ogra_> (18 will allow you to run core16 snaps but that comes indeed with a cost ... since you need the base installed alongside)
 * ogra_ -> afk for a while
<jkridner> :-|
 * jkridner has to think
<mup> PR snapd#5194 opened: interfaces/apparmor: add 'mediate_deleted' profile flag for all snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5194>
<panter_> Are snaps basically 'devices' that get mounted to the filesystem?
<kyrofa> panter_, essentially. They're squashfs images
<panter_> kyrofa: Is there any way to change files in this squashfs image?
<kyrofa> panter_, squashfs is by definition read-only. You can always unsquash and re-squash an image after modifations, but whether or not that works for you depends on your goal
<kyrofa> If you're wanting to modify a snap, you're out of luck if you also want updates from the store etc
<panter_> kyrofa: but how would you be able to unsquash it. I only find a directory with files not a .squashfs file? btw it is no problem that it gets overwritten after updates
<panter_> Sorry, I found it in /var/lib/snapd/snaps
<mup> PR snapcraft#2144 opened: lifecycle: automatically stage dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2144>
<panter_> I have created a snap without any .desktop files in it. However I still see an icon on between my applications. Where does it come from?
<bashfulrobot> panter_: Do you by chance have a deb version of the app installed?
<panter_> bashfulrobot: no
<bashfulrobot> Or a straggler desktop file in say `/usr/share/applications`?
<panter_> no
<bashfulrobot> In the past - that is how I have had this issue
<bashfulrobot> I'm not sure otherwise
<panter_> find is running currently so I guess I will know the issue after the command has finished
<panter_> Yeah, there is another .desktop file in /var/lib/snapd/desktop/applications. So I guess when you install/update a snap it gets unsquashfs'ed and then the .desktop file gets placed in another directory, so the file in the read-only mounted part isn't really important
<panter_> Thanks for all the help!
<mup> PR snapd#5102 closed: tests: new utility to save and restore the snap state <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5102>
<mup> PR snapd#5016 closed: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<jdstrand> niemeyer: hey, I've been keeping https://github.com/snapcore/snapd/wiki/Interfaces up to date, but the wiki is obsoleted. Seems like the page should be moved to 'doc' category in the forum?
<jdstrand> niemeyer: shall I do that?
<niemeyer> jdstrand: There's some discussion in the forum on that, in that thread under the new doc site
<niemeyer> jdstrand: I'd like to migrate, but would like to make it look nicer at the same time
<jdstrand> niemeyer: if you have an idea on how to make it nicer, I could do that. I do like the information it conveys so hopefully the new format will not be lossy
<jdstrand> niemeyer: I can also wait and keep updating the old one for now
<jdstrand> I don't feel strongly about migrating *right now*. just thought I'd touch base
<bashfulrobot> panter_ glad I  could help!
<AuroraAvenue> not sure how to build this from source in solus ? & is it on github ? https://launchpad.net/audio-recorder
<AuroraAvenue> https://imgur.com/5c1JwVX
<bashfulrobot> in Solus?
<bashfulrobot> Suspect might need to build in a LXD container or something. I mean snapcraft is a snap, but have no experience using it htere.
<bashfulrobot> (on Solus)
<bashfulrobot> If I was going to try, would snap install LXD.
<bashfulrobot> Then build in a 16.04 container
<AuroraAvenue> right, but apart fromn creating a snap.... how do I build from source ?
<bashfulrobot> ohhh - I would say that is out of scope in the snap package channel. ha ha. But if I hazard to guess? You would need the required build tools installed and then have to satisfy the dependencies on the system. Either through the package manager, or if not available there, build those forst.
<bashfulrobot> You might have vmore luck in the Solus IRC channels
<bashfulrobot> #Solus on freenode I beleive
<bashfulrobot> Sorry - originally thought you meant how to build a snap on Solus
<AuroraAvenue> but I don't want to give them my ip address , though - they are hackers, lest I forget. ...
<bashfulrobot> huh?
<bashfulrobot> Why do you sy that???
<AuroraAvenue> I trust this channel for basic info links though :)
<AuroraAvenue> snappy is cool
<bashfulrobot> I mean if you didnlt trust them - I mean why are you running Solus? They already could own the system through the pakaging, etc.
<bashfulrobot> I mean - they write the software.
<AuroraAvenue> Well - that's lost in the system - IRC ip address have more eyes on them.
<AuroraAvenue> 'cos there's more than 1 user in da room.
<bashfulrobot> I mean you could also ask on the #solus-dev channel. Or on their forums. All official.
<AuroraAvenue> Basically I know that snappy channel cannot afford a basic response (& I shall go now). But it would have been nice to build a linux app from source. Not relaying simple info. like that seems stupid to me. It's like there are wiki's for this stuff or something !!!!?
<AuroraAvenue> & where's the bot, even, for such a response - no-where !
<AuroraAvenue> https://answers.launchpad.net/audio-recorder/+question/269584
<bashfulrobot> Well it would be the upstream author who should provide those instructions.
<bashfulrobot> welp - he is gone.
<kyrofa> bashfulrobot, my usual go-to is to start pretending I'm a windows dev and don't know anything
<bashfulrobot> kyrofa: ha ha ha. Does that happen in here often?
<kyrofa> bashfulrobot, nah
<bashfulrobot> kyrofa: that person was gold. from the "hackers" to the linked ancient single question on the app.
<kyrofa> I'm kinda sad that I'm not a hacker now
<bashfulrobot> kyrofa: Join Solus (apparently)? Hacker status restored!
<niemeyer> jdstrand: I have some vague plans about how to split it at least.. I did write some notes in that thread I think.. but for actually making it look nice, I was planning on just experimenting
<niemeyer> jdstrand: If you'd like to push that forward, I'd love your help on that
<mwhudson> how can i tell if a snap depends on a content provider?
<mwhudson> i don't see anything in /v2/find?name= about it
<mwhudson> does it have to be fished out of meta/snap.yaml?
<mup> PR snapcraft#2145 opened: lifecycle: automatically clean dirty steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2145>
<jdstrand> niemeyer: can you give me a pointer to the topic you are referring to? I'm having trouble finding it. perhaps I can carve out some time for that
<jdstrand> heading off to dinner now-- I'll read backscroll (like always)
<niemeyer> jdstrand: I was thinking of https://forum.snapcraft.io/t/experimental-documentation-site/3806/5
<niemeyer> jdstrand: But maybe I'm misremembering.. the detailing there is for the daemon api
<niemeyer> mwhudson: No, we have interface details in the API too
<niemeyer> mwhudson: We want to improve those a bit, but if you look at the implementation of the "interface" (singular) command, for example, you might get some ideas
<mwhudson> niemeyer: ok, i'll have a look
<mwhudson> thanks
<niemeyer> jdstrand: Let's meet tomorrow.. I'm sure we can quickly brainstorm some ideas for how we want the page to look
<mwhudson> niemeyer: i mean for a snap not yet installed btw
<mwhudson> niemeyer: i'll make a forum post with more details i think
<niemeyer> mwhudson: Oh
<niemeyer> mwhudson: That might be trickier
 * mwhudson afk for a few
<mwhudson> niemeyer: https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579
#snappy 2018-05-24
<mwhudson> $ snap download --channel=wibble hello
<mwhudson> Fetching snap "hello"
<mwhudson> error: cannot find snap "hello": snap not found
<mwhudson> accurate but possibly not maximally helpful
<niemeyer> mwhudson: Thanks, will have a look tomorrow
 * niemeyer => bed
<mwhudson> niemeyer: good night
<niemeyer> Night!
<niemeyer> Or rather, have a good day :)
<mup> Bug #1773044 opened: Can't get snap gui apps (notepadqq and firefox) to run in LXD/LXC container <Snappy:New> <https://launchpad.net/bugs/1773044>
<mborzecki> morning
<zyga> o/
<mborzecki> zyga: back from vacation?
<zyga> yes
<zyga> hey mvo :-)
<mborzecki> mvo: morning
<zyga> we arrived late, plane switching and endless waiting
<zyga> a bit sleepy
<zyga> but I managed to fix my machine's snapd by aborting existing changes and refreshing core in isolation
<mvo> hey zyga and mborzecki
<mborzecki> zyga: but otherwise the stay in spain was enjoyable?
<zyga> mborzecki: yes but also very emotional
<zyga> mborzecki: we have way more close friends there than here
<zyga> mborzecki: and given the size of the city we met all but one of them, mostly just by bumping into each other, ahead of planned events :)
<zyga> mborzecki: it's likely we will return there if stars align
<mborzecki> zyga: haha nice
<mborzecki> zyga: 2nd thoughts about moving back there? :)
<zyga> how was the week?
<zyga> any fires
<zyga> mborzecki: yes, definitely
<mup> PR snapd#5193 closed: spread-shellcheck: port to python <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5193>
<mup> PR snapd#5190 closed: tests: new parameter for the journalctl rate limit <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5190>
<zyga> Dog time
<mvo> zyga: when you have a moment (and you are back) a review of 5143 would be great
<mvo> zyga: you reviewed this already so hopefully simple
<mvo> we are back to 25 open PRs, yay
<mvo> a review for 5194 would also be nice (should be pretty trivial)
 * zyga reviews 5143
<zyga> sorry for the lag, I didn't bring shaving gear with me and I looked like robinson stranded on some island
<mvo> no worries
<mborzecki> gdpr emails, getting many of those now that the deadline is tomorrow (?)
<zyga> mborzecki: yeah, quite a swarm
<zyga> mborzecki: if I'm a self-emloyed company and I have you in my address book, do I need to send you one too?
<mborzecki> hahaha
<mborzecki> well, you'll probably need to keep the business cards in a safe too :)
<zyga> mvo: done, looking at 5194
<mup> PR snapd#5194 closed: interfaces/apparmor: add 'mediate_deleted' profile flag for all snaps <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5194>
<pstolowski> good morning
<mvo> zyga: thank you
<mborzecki> pstolowski: hey
<zyga> hey pawel!
<mvo> hey pstolowski good morning!
<BlueShark> How to set an app that was installed using Snap to auto-start on boot?
<zyga> BlueShark: hey, if the application supports this by itself use internal application settings
<zyga> BlueShark: otherwise your desktop environment may have something for starting apps on login
<zyga> BlueShark: if this is a service it will automatically start on boot
<BlueShark> zyga, It's slack. I enabled auto-start inside Slack settings, but that does not work. It does not start automatically.
<BlueShark> When I used to install it using the deb file from the wbesite, it used to work perfectly. Now, with Snap though, it's not working.
<zyga> BlueShark: slack may need a tweak to enable this feature in the snap, it is a new addition
<BlueShark> (I can't install using the .deb fiile because of some dependency conflict with libcurl4)
<BlueShark> zyga, no work around possible?
<zyga> BlueShark: (and I may be wrong that it is still only avialable in the development version of snapd)
<BlueShark> like something I can add in rc.local or some startup script so that it's executed?
<zyga> BlueShark: well, as I said, it's a recent addition, once deployed the checkbox you used to use will work again
<BlueShark> yup, until then, I can use some work around.
<BlueShark> (if possible.)
<zyga> not really, those are not compatible with desktop apps
<zyga> mborzecki: is auto-start for desktop apps released to stable?
<mborzecki> zyga: yes
<zyga> ah nice
 * zyga looks at slack
<BlueShark> thanks!
<zyga> slack is not using this
<BlueShark> ok, what are they using?
<zyga> popey: hey, nitpick suggestion about slack, it could ot into the auto-start feature supprt
<zyga> *support
<zyga> it should be a one line diff to their snap.yaml now
<zyga> ahmm
<zyga> actually
<BlueShark> File -> Preferences -> Launch app on login - I check this box every time, but when I restart the system, not only does it not start, the checkbox becomes unticked.
<zyga> slack is using classic confinement
<zyga> so whatever it is doing should be uninhibited
<mborzecki> zyga: is it still?
<mborzecki> i thought they moved to strict
<zyga> no, they haven't
<mborzecki> hmmpfff
<BlueShark> launching /snap/bin/slack from command line seems to work.
<BlueShark> adding it to a startup script, wouldn't work, zyga?
<zyga> BlueShark: it looks like auto-start does nothing inside slack
<zyga> not sure why
<zyga> BlueShark: define startup script
<zyga> BlueShark: it would only work if started from your session manager
<zyga> it would not work from typical system startup
<mborzecki> zyga: it should drop a desktop file in ~/.config/autostart
<BlueShark> I was thinking @reboot in crontab
<zyga> mborzecki: it doesn't
<zyga> BlueShark: what?
<zyga> in any case, it would not work :)
<BlueShark> ok.
<BlueShark> >  it would only work if started from your session manager - is there any way to accomplish this?
<zyga> popey: I take that back, it would be nice to poke slack about auto-start for their app, it seems to be disabled and it ought to work now
<zyga> BlueShark: it depends on the session manager but as mborzecki said many of them support reading ~/.config/autostart and looking for desktop files to run there
<zyga> this book cover: https://twitter.com/mononcqc/status/999471339474968576 :^)
<BlueShark> zyga, I'm using Ubuntu mATE.
<zyga> it should work then
<zyga> but again, it is a bug in slack
<zyga> so perhaps slack can fix it to just work as it should
<mborzecki> BlueShark: a workaround, but you could try and symlink /var/lib/snapd/desktop/applications/<slack-desktop-file>.desktop to ~/.config/autostart
<Chipaca> mood gorning all!
<zyga> good morning John
<Chipaca> who is this 'John' person
<Chipaca> i see only chipacas
<mvo> Chipaca: hey, good morning!
<Chipaca> zyga: mvo: good morning :) how's things?
<zyga> I'm slowly getting back into business
<zyga> doing reviews now
<zyga> enjoying the warmth of Poland over the coldness of Spain
<pstolowski> :)
<mborzecki> well, it's a nice weather for biking for sure, not too hot, not too cold, bit too windy, but otherwise evening rides are fun :)
<Chipaca> huh, so my snapd is again stuck in a loop
<Chipaca> ah... probably need to stop it and rebuild
<zyga> Chipaca: or abort it and refresh snapd alone
<zyga> it fixed it for me
<Chipaca> zyga: it's a dev snapd, no reexec
<BlueShark> mborzecki, ln -s?
<mvo> niemeyer: could you please add github.com/snapcore/core18 to mup so that it announces new PRs here?
<mborzecki> BlueShark: ln -s /var/lib/snapd/desktop/applications/slack_slack.desktop ~/.config/autostart/
<Chipaca> pedronis: I just set ensureInterval, pruneInterval, pruneWait and abortWait to time.Second (to force prune my 68MB state.json), and snapd paniced
<pedronis> Chipaca: that was a bit aggressive
<Chipaca> pedronis: ikr
<Chipaca> pedronis: i expected it to be a bit unhappy :-) but a panic seems wrong
<pedronis> well
<pedronis> I'm not sure what the invariants are but there are for sure some
<Chipaca> https://pastebin.ubuntu.com/p/xGTBSswsDD/ if it's of interest to you
 * Chipaca can't delve into that right now
<pedronis> Chipaca: well we are deleting a task that is being run
<pedronis> or something like that
<pedronis> not sure
<pedronis> Chipaca: I see, I think the issue is that   changes become ready before they  are cleaned up
<pedronis> Chipaca: I suppose it's a real bug in the sense that the pruning code should wait for the change to be clean, not just ready
<pedronis> Chipaca: otoh IÂ suppose cleaning might fail and that never happen
<pedronis> Chipaca: so we would need a cleanWait time
<pedronis> and a way to stop cleaning itself
<pedronis> Chipaca: is cleaning on shot? do you remember?
<Chipaca> pedronis: I don't even remember what cleaning involved :-)
<Chipaca> pedronis: was that what we hung cleanup from?
<pedronis> Chipaca: yes, anyway your panic seems related to that
<Chipaca> k
<pedronis> and the fact that ready and clean are distinct concept
<pedronis> but I don't remember how we handle clean errors
<pedronis> Chipaca: afaict it seems we would try forever
<pedronis> otoh the only clean we have doesn't return errors (except for state issues)
<Chipaca> pedronis: there's a cleanup in snapshotmgr
<Chipaca> pedronis: but it also doesn't error
<Chipaca> i thought not erroring was cleanups thing
<pedronis> yea
<pedronis> Chipaca: though there is still something weird about that panic
<mborzecki> pedronis: Chipaca: i undestand client.Snap should also carry the list of appstream IDs as top level common-ids?
<pedronis> think so
<Chipaca> mborzecki: yah
<pedronis> Chipaca: so I think the panic as such is an actual bug,   the place that does Task(id)  should probably not assume that the return will not be nil
<pedronis> it kinds always not nil, except when it is
<zyga> https://github.com/snapcore/snapd/pull/5184 is long but interesting if anyone wants to look
<mup> PR #5184: interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184>
<pedronis> Chipaca: there's two bugs probably, though one is really relevant only if you set a very low pruneWait
<pstolowski> pedronis: hey, i've a helper and tentative fix per yesterdays discussion
<pstolowski> and test is happy
<pstolowski> preparing PRs
<pedronis> pstolowski: cool
<zyga> pstolowski: hey, is the hookapocalypse solved now?
<pstolowski> not running hooks twice isn't addressed yet, but i'll do that as well i think
<pstolowski> zyga: it should be yes
<pedronis> Chipaca: anyway basically pruneWait and abortWait need to be some healthy multiple of ensureInterval
 * zyga reached his first PR while doing reviews, yay
<pedronis> Chipaca: I'll do a small PR about the panic itself
<Chipaca> pedronis: thanks
 * zyga small break
<Chipaca> waaaait
<Chipaca> there are only 24 PRs up
<Chipaca> that's less than a page
<Chipaca> quick, more PRs!
<pstolowski> they're coming ;)
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/5195
<mup> PR snapd#5195 opened: overlord/snapstate:Â don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <https://github.com/snapcore/snapd/pull/5195>
<mup> PR #5195: overlord/snapstate:Â don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <https://github.com/snapcore/snapd/pull/5195>
<mup> PR snapd#5196 opened: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5196>
<Chipaca> pedronis: +1 :-)
 * Chipaca -> physio, probably
<upgreydd> hello. Can someone help me with `snap` please? I have problem with access to ports - still getting `access denied`. Ports are unused in hosts machine :(
<zyga> upgreydd: hey, which ports are you referring to?
<upgreydd> zyga: 8080, 27017 - they are unused at host -i'm trying to use rocketchat
<zyga> IP ports?
<mvo> mborzecki: do we have a forum post about the new watchdog support you added recently? if so, could you please paste hte link? I am updating the 2.33 roadmap page right now. anything else I should mention there that you remember from your side?
<zyga> upgreydd: well, if you are after network, is your snap using network-bind interface? you need a plug (connected) of that interface to create network services
<mvo> zyga: same question, anything I should mention (high level) for 2.33 from you?
<mvo> pstolowski: for 2.33 - interface hooks are in, right?
<upgreydd> zyga: what are you talking about? :|
<zyga> upgreydd: can you please give us an overview of your problem?
<pedronis> mvo: they are not fully usable
<pstolowski> mvo: we don't have complete feature without now reverted reconnect
<pedronis> given what we reverted
<zyga> upgreydd: are you writing some software that binds to network sockets?
<pstolowski> and without disconnect hooks (PR up, but needs some more work)
<mborzecki> mvo: i'm afraid there's no separate post about software watchdog, what reminds me i should probably update snap.yaml doc page
<upgreydd> zyga I've installed package `rocketchat-server` <- it was working before
<zyga> mvo: I need to check, I think I was only doing bug fixes lately,
<upgreydd> zyga: when i run `snap start rocketchat-server` only one service is starting, two is not: they are showing errors in journalctl: listen tcp :8090: socket: permission denied
<zyga> upgreydd: can you run "snap interfaces | grep rocket chat-server"
<zyga> (skip the space in rocketchat above)
<upgreydd> zyga: :desktop, :network, :network-bind
<upgreydd> zyga: there are subservices
<upgreydd> snap services rocketchat-server Service                              Startup  Current rocketchat-server.rocketchat-caddy   enabled  inactive rocketchat-server.rocketchat-mongo   enabled  inactive rocketchat-server.rocketchat-server  enabled  active
<zyga> can you now run "dmesg | grep DENIED"
<upgreydd> zyga: lot of: [ 1055.222607] audit: type=1400 audit(1527156637.606:9658): apparmor="DENIED" operation="ptrace" profile="snap.rocketchat-server.rocketchat-server" pid=7152 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined"
<zyga> can you run
<zyga> dmesg -c >/dev/null
<zyga> systemctl restart rocketchat-server # + other services
<zyga> dmesg | grep DENIED
<zyga> and pastebin the result
<upgreydd> zyga: https://pastebin.com/FY9MWcNe
<popey> cjwatson: https://launchpad.net/~build.snapcraft.io/+snap/20905f58c528ef301b741b624b79dc28-xenial/+build/223942  this build looks wedged, can it be cleaned please?
<popey> ref: https://forum.snapcraft.io/t/tizonia-store-build-stuck-for-more-than-4-days/5583
<zyga> upgreydd: can you pastebin /snap/rocketchat-server/current/meta/snap.yaml please
<upgreydd> zyga: https://pastebin.com/itCDhgLM
<zyga> can you pastebin /var/lib/snapd/apparmor/profiles/rocketchat-server.rocketchat-caddy
<zyga> (er, snap.rocketchart-server.rocketchat-caddy)
<mborzecki> mvo: i've updated https://forum.snapcraft.io/t/the-snap-format/698
<upgreydd> zyga: https://pastebin.com/96GzLgnU
<upgreydd> zyga: is there a way to disable apparmor for whole snap?
<cjwatson> popey: Yes, I also saw Evan's bug about that, only need one notification
<zyga> upgreydd: hmm, this is curious
<popey> I wasn't aware Ev had filed a bug, sorry.
<zyga> upgreydd: can you run "snap interfaces" and pastebin that again please
<cjwatson> cancelling, but in general we do cancel stuck builds in bulk every so often
<upgreydd> zyga: https://pastebin.com/E91MpW5w
<zyga> hmm hmm hmm
<zyga> this looks curious
<zyga> and "snap version"?
<upgreydd> snap    2.32.8 snapd   2.32.8 series  16 ubuntu  14.04 kernel  4.4.0-127-generic
<zyga> so
<upgreydd> as I understand theres a problem with apparmor? Can we just simply override apparmor for this app somehow?
<zyga> for whatever reason, while snapd claims that the network-bind plug is connected
<zyga> it is not present in the profile of that app
<zyga> upgreydd: can you "snap disable rocketchat-server"; snap enable rocketchat-server
<zyga> that ought to fix it
<zyga> upgreydd: not per app
<mborzecki> mvo: and left a note here https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268/45 in case you want to link to it
<zyga> upgreydd: there's a way to switch apparmor to non-enforcing mode but I think this will fix itself after that last command
<zyga> I'm worried that it has happened in the first place
<upgreydd> zyga: your'e right
<upgreydd> fixed
<zyga> upgreydd: can you tell me when this started to happen exactly (assuming the disable/enable commands fix it)
<upgreydd> zyga: after rocketchat autorefresh
<zyga> can you pastebin snap changes
<zyga> and then
<zyga> snap tasks NNN # where NNN is the number of the change you get from the previous command
<upgreydd> https://pastebin.com/8zdqm1Yj
<zyga> thanks
<zyga> nothing that seems to indicate something went wrong :/
<zyga> did you reboot your machine?
<zyga> when this happened
<zyga> as in <reboot> <stuff is broken>
<zyga> upgreydd: also in case it has some useful clues as to what went wrong, please pastebin: jounalctl -u snapd
<upgreydd> zyga: rebooted lot of times
<mup> PR snapd#5195 closed: overlord/snapstate:Â don't panic in a corner case interaction of cleanup tasks and pruning <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5195>
<mvo> mborzecki: thank you! I will link to it
<upgreydd> zyga: there was some other before me and I don't know what did he did
<mvo> pstolowski: I move the interface hooks to 2.34 then for now
<mvo> pstolowski: thank you
<zyga> mvo: do we have that debian version compare somewhere in the tree?
<mvo> zyga: we used to, let me see if we still do
<zyga> I need a function that's similar
<zyga> thinking about just reusing it
<mvo> zyga: try strutil.VersionCompare
<zyga> perfect!
<zyga> thanks
<mvo> zyga: if the version numbering is vaguely sane it should work
<mvo> zyga: what do you need to compare?
<zyga> mvo: kernel versions
<zyga> I think this will work perfectly
<mvo> zyga: yes
<zyga> mborzecki: hey
<zyga>     - google:ubuntu-14.04-64:tests/main/snapd-notify fails, is that expected?
<mborzecki> zyga: hmhm?
<mborzecki> which pr is it?
<zyga> https://travis-ci.org/snapcore/snapd/builds/383121772
<zyga> https://github.com/snapcore/snapd/pull/5196
<mup> PR #5196: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5196>
 * zyga hates packagekit
<mborzecki> zyga: not expected, saw it a couple of times, restarting the build helps, intersting bit was journal being empty between cursors
<zyga> I restarted it already
<zyga> but maybe bad luck
<mup> PR snapd#5119 closed: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5119>
<pedronis> pstolowski: the PR is red
<mup> PR snapd#5119 opened: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <https://github.com/snapcore/snapd/pull/5119>
<pstolowski> pedronis: indeed, tests/main/snapd-notify failure, cursor on journal failed
<pedronis> ah, 14.04
<pedronis> mmh
<jdstrand> pstolowski: hi! it seems https://forum.snapcraft.io/t/supported-snap-hooks/3795 is out of date. it doesn't list connect-{plug,slot}-* and prepare-(plug,slot}-*. are there any others that are missing? I ask because a snap is using a 'refresh' hook (not post-refresh or pre-refresh)
<jdstrand> pstolowski: I haven't look in the snapd sources yet, but is 'refresh' supported? are there others?
<jdstrand> looked*
<pstolowski> pedronis: i'm going to kick the test again and see, but these cursor- based tests seem flaky, we need to revisit them
<jdstrand> pstolowski: if you don't know otoh, I can read the sources myself
<pstolowski> jdstrand: hey. i'll take a look at the list; we don't have refresh , only post- and pre- refresh. i'm surprised we see refresh hook somewhere, there was a very brief moment we had this hook (and i think only in edge) and we split/renamed it into pre- and post- very quickly
<jdstrand> pstolowski: ok, cool, then the tools did their job :)
<pstolowski> jdstrand: the list looks complete to me in a sense that interface hooks are not fully landed and usable yet, so we shouldn't probably document  onnect- and prepare-plug/slot- yet
<jdstrand> pstolowski: ah, ok. thanks!
<zyga> jdstrand: hey
<zyga> jdstrand: question
<zyga> jdstrand: I'm writing a service that loads snapd-specific apparmor profiles
<zyga> what kind of guarantees should I put in place, do I need to replicate all the things done by various distro specific helpers
<zyga> like mounting securityfs and such
<jdstrand> zyga: if you're unit file does After=apparmor or similar, no. if your unit is meant to be independent, yes.
<zyga> can I do After=apparmor?
<zyga> that would definitely simplify it, yes
<jdstrand> sure, why not?
<zyga> well, as long as that's portable :)
<zyga> I'll do it, thanks
<jdstrand> ./libvirt-bin.service:After=apparmor.service
<jdstrand> zyga: it is as portable as apparmor.service existing
<Chipaca> zyga: remember After= isn't Requires=
<Chipaca> zyga: you can put After=DziewiÄÄsetdziewiÄÄdziesiÄciodziewiÄcionarodowoÅciowego and it'd probably work
<jdstrand> in this case, After=apparmor.service is probably correct. on distros without apparmor.service, you probably don't have apparmor_parser or the apparmor abstractions. snapd can then proceed in devmode
<jdstrand> zyga, Chipaca: ^
<mup> PR snapd#5197 opened: [WIP] cmd/snap: display a link to the TOS for interactive snap login <Created by pedronis> <https://github.com/snapcore/snapd/pull/5197>
<mup> PR snapd#5198 opened: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
<zyga> jdstrand: ^ a quick idea
<zyga> jdstrand: I would subsequently install this on openSUSE
<cachio> zyga, mvo, #5143 updated
<mup> PR #5143: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143>
<cachio> mborzecki, #5143 updated
<cachio> thanks for reviewing!!
<zyga> cachio: ack, looking again
<mvo> cachio: thank you
<mvo> cachio: looking
<cachio> mvo, I am re executing this in the boards to validate everything is ok
<mvo> cachio: cool, thank you. once this is good I will cherry-pick it into 2.33
<mvo> cachio: we just need to remember to squash merge it
<cachio> mvo, perfect
<zyga> cachio: in 5143, can you please react to existing feedback, I'm not sure if you saw something but chose to ignore it or if an older feedback was acted upon but the lines have changed so the comment is hidden
 * zyga -> school see you at the standup
<mvo> zyga, sil2100 feedback on 10,11 for https://github.com/snapcore/core18/pulls woudl be great (no rush though)
<cachio> zyga, sure
<sil2100> mvo: sure o/
<popey> diddledan: I'm told by sergiusens  that the new snapcraft should be available in build now, so maybe we can land your gimp 2.10 work?
<diddledan> \o/
<diddledan> click the butten!
<diddledan> button*
<diddledan> I'm working on 2.10.2 atm
<diddledan> this is a problem I'm encountering, which appears to be something with my build rather than snapd? (gimp:17871): GLib-ERROR **: 13:36:13.404: gmem.c:333: overflow allocating 18446744073709551615*18446744073709551615 bytes
<Chipaca> diddledan: here's a nickle, etc
 * zyga actually doesn't do school run now, eh
<mup> PR snapd#5199 opened: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<om26er> Chipaca: that https://github.com/torvalds/linux/blob/master/include/math-emu/double.h#L29 ?
<Chipaca> om26er: which is a reference to http://dilbert.com/strip/1995-06-24
<om26er> epic
<zyga> mborzecki: question on appstream integration
<zyga> posted on github
<Chipaca> zyga: search responses don't include app info
<zyga> ah
<zyga> I see
<Chipaca> zyga: but search consumers need to know the ids of the results
<Chipaca> zyga: so the easiest way is to have it in both places
<zyga> so this is the client side
<Chipaca> zyga: all sides
<zyga> is the store side (that is snapd->store) part ready?
<Chipaca> zyga: yes, has been for a while now
<Chipaca> we were lagging
<Chipaca> i mean
<Chipaca> the _store_ has been responding with common ids for a while, if asked
<Chipaca> snapd hasn't been asking
<zyga> how do we ask?
<zyga> I see deserialisation things but I don't see something like "gimme common-id"
<Chipaca> zyga: include it in the 'fields' query
<Chipaca> zyga: store.Config.DetailFields
<mborzecki> zyga: that part is magical :)
<zyga> oh?
<Chipaca> zyga: ï¼­ï¼¡ï¼§ï¼©ï¼£
<zyga> it gets computed from the structs somehow>
<zyga> ?
<mborzecki> Chipaca: did you write it?
<mborzecki> zyga: yes
<Chipaca> yes
<zyga> ah, ok
<zyga> +1 then
<zyga> this is a major thing, thank you mborzecki
<Chipaca> no, it's a common thing
<Chipaca> otherwise it would be major-id
 * Chipaca runs
<mborzecki> haha
<zyga> Chipaca: is a general-id better than major-id
<zyga> and is there a private-id
 * zyga gets back to coding
<cachio> zyga, #5143 ready again
<mup> PR #5143: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143>
<zyga> mvo: thanks for the question on 5198, replied and removed the code there
<zyga> cachio: ack,
<zyga> cachio: thanks, I think only https://github.com/snapcore/snapd/pull/5143#discussion_r190480661 remains
<mup> PR #5143: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143>
<zyga> after that +1
<zyga> jdstrand: thanks for the quick review, replied and will make the changes
<mup> PR snapd#5188 closed: tests: ubuntu core abstraction <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5188>
<jdstrand> zyga: interesting: kernel: [624468.239774] audit: type=1400 audit(1527171830.098:109395): apparmor="DENIED" operation="file_inherit" profile="snap-update-ns.firefox" name="/dev/null" pid=15584 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<kjackal> What is the process for changing the publisher of a snap?
<popey> kjackal: The store team can initiate a transfer, Start a thread on the forum in the store category
<kjackal> thanks
<cachio> zyga, hey
<jdstrand> zyga: we should add '/dev/null rw,' to the sun profile
<zyga> ack
<cachio> I can add a function to systems.sh like it_is_ubuntu_14
<cachio> is_ubuntu_14
<cachio> so we can use that in state.sh and leave it as bash
<cachio> sh
<cachio> does it make sense?
<zyga> yes,
<cachio> I'll just used that method in the state, then I'll update the rest of the code in a new PR
<cachio> because otherwise it will be huge change
<cachio> zyga, does it make sense?
 * zyga needs to take the dog for a walk
<jdstrand> roadmr: fyi, https://dashboard.snapcraft.io/snaps/huggle/revisions/1227/ was stuck for what looked like 16 hours. I pressed the 'run the automated review again' button
<jdstrand> roadmr: hi btw :)
<roadmr> jdstrand: oh! so is it unstuck now?
<jdstrand> roadmr: yes
<roadmr> yes it is!
<roadmr> ok, I'll check logs to see what may have happened.
<jdstrand> roadmr: also, can you queue up r1078? not urgent at all. can come after the last request for pull
<mvo> sil2100, zyga trivial PR https://github.com/snapcore/core18/pull/12
<mup> PR core18#12: hooks: trivial rename to make them consistently XXX-name.chroot <Created by mvo5> <https://github.com/snapcore/core18/pull/12>
<roadmr> jdstrand: sure!
<zyga> Looking
<zyga> +1
<sil2100> Yeah, I guess it's much cleaner now
<jdstrand> roadmr: thanks!
<mvo> zyga, sil2100 ta
<pedronis> Chipaca: we usually spell id ID
<Chipaca> we do
<Chipaca> oops
<pedronis> except when we don't, but it's usually ID  around snap stuff
<pedronis> major offender seems some code in state.go
<pedronis> user.LookupId seems an offender in the stdlib
 * zyga -> food
<mup> PR snapd#5200 opened: interfaces: reconnect, fix for autoconnect/reconnect conflict check <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5200>
<pedronis> niemeyer: I asked a clarification about  common-id here:  https://forum.snapcraft.io/t/support-for-appstream-id/2327/24
<niemeyer> Looking
<niemeyer> pedronis: Replied
<pedronis> niemeyer: does it mean we need validation about repeated common-ids in snapcraft, snapd?
<pedronis> or it's benign enough, just not expected
<mborzecki> re
<pedronis> niemeyer: sorry, I asked here, but the answer to what to do probably should go in the forum
<niemeyer> pedronis: I think we should enforce it in snapd/snapcraft
<niemeyer> pedronis: Hmm.. well
<niemeyer> pedronis: Or maybe it's not a big deal after all
<niemeyer> pedronis: What'd be the consequences of that?
<niemeyer> The point is mapping id => snap
<pedronis> not big
<niemeyer> If multiple apps have the same, that's still just one id => snap arrow
<pedronis> but IÂ see snapcraft does thing with common-id and desktop files
<pedronis> which I'm not sure IÂ understand
<pedronis> how is impacted
<mborzecki> fwiw checking for unique common-id within a snap in snap pack --check-skeleton could be easily added
<pedronis> mborzecki: we are discussing in the forum post as well
<niemeyer> pedronis: See note
<cachio> zyga, does it make sense what I proposed for the bash/sh discussion?
<zyga> cachio: looking now
<cachio> zyga, tx
<zyga> cachio: not really :)
<zyga> cachio: the point was that including is confusing because there are two languages
<zyga> cachio: if you include systems.sh from bash it works ok
<zyga> cachio: if you include it from sh it will not work because [[ is not in dash
<zyga> cachio: the solution is to either use bash everywhere (I made a point that we dont) or use sh compatible code
<zyga> cachio: (like the one maciej suggested)
<zyga> does that make sense?
<cachio> yes, but what is we use bash for everything?
<cachio> what if
<zyga> that is fine too
<zyga> I personally prefer to avoid the need for bash but that's beyond the point
<cachio> but, all the tests run on bash
<cachio> so the helpers could too
<cachio_> zyga, I got disconnected
<zyga> cachio_: I didn't write more than before, my point is that we need to be consistent as we are not writing separate files that get executed but instead have a swarm of include files
<cachio_> zyga, agree with this
<cachio_> that's why I propose to move everything to bash
<cachio_> as the tests are on bash
<cachio_> and those are sourcing most of the scripts
<cachio_> I prefer to have just 1 language
<cachio_> so we reduce the complexity and it is more robust as well
<zyga> cachio_: ok, go ahead
<cachio_> mvo, mborzecki guys do you agree with that?
<cachio_> zyga, should I do it in this PR or create a new one?
<zyga> cachio_: maybe a small separate PR, although TBH your current PR just needs a tweak to be sh safe in one line and it could land as well
<cachio_> zyga, awesome, thanks
<cachio_> zyga, shellchecks fixed and pushed
<zyga> ack
<cachio_> now running here on ubuntu core to make extra validation
<zyga> thanks
<zyga> approving
<cachio_> zyga, thanks!!!!
<zyga> done
<zyga> boy, my dog is crazy today
<zyga> he is so all over me today
<zyga> after being away for a week he got super lonely
<zyga> he's literally walking overy my laptop in front of my face for attention
<cachio_> hehehe
<cachio_> zyga, he needs another walk
<zyga> jdstrand: can you please have another look at https://github.com/snapcore/snapd/pull/5198
<mup> PR #5198: data/systemd: add snapd.apparmor.service <Created by zyga> <https://github.com/snapcore/snapd/pull/5198>
<mvo> zyga, cachio_ I just read backlog - fwiw, we are using bashisms already in our scripts left and right, just "git grep \[\[", including in prepare-restore reset, snaps
<zyga> mvo: I know, that's fine
<mvo> zyga, cachio_ so moving "formally" to bash seems to make sense
<zyga> mvo: I think this just makes sense to do all the way
<mvo> zyga: aha, ok. maybe I missed parts of the discussion then
<mvo> zyga: +1
<mvo> zyga: yeah, we are (de-facto) already doing it :)
<zyga> mvo: no, just saying that the point I was after was addressed and I already approved that
<mvo> I mean, everywhere lib/pkgdb.sh, lib/dbus.sh
<mvo> zyga: cool, so we are all in agreement
<cachio_> mvo, zyga agreed :)
<cachio_> mvo, I'll create a PR for tha tchange
<zyga> sigh
<mvo> zyga: hm?
<zyga> The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
<zyga> yet we log src/github.com/snapcore/snapd/interfaces/backend.go and all the other files
<mvo> cachio_: I think its fine to keep as is and make this a separate PR, the mixing of bash/dash is not a new issue with the PR we already do it, I think it should not block this pr from landing (as long as we fix it properly in a followup). *if* its trivial, then I don't mind if its the same PR of course
<mup> PR snapd#5201 opened: interfaces/apparmor: use helper to load stray profile <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5201>
<mvo> zyga: just finished reading the bash/dash comments, sorry that I lacked some context earlier and thank you for raising this (and now it gets fixed :)
<zyga> mvo: no worries at all :)
<Pharaoh_Atem> zyga, fwiw, I'm totally okay with explicitly using bash
<Pharaoh_Atem> I'm not a fan of pure-posix shellscript anyway
<mup> PR snapd#5202 opened: packaging: filter out verbose flags from "dh-golang" <Created by zyga> <https://github.com/snapcore/snapd/pull/5202>
<zyga> jdstrand: I pathched my system not to load profiles from /var/lib/snapd/apparmor/profiles
<zyga> jdstrand: and installed the improved snapd.apparmor.service
<zyga> jdstrand: no issues
<jdstrand> nice! :)
<zyga>            173ms snapd.apparmor.service
<zyga> that's according to systemd-analyze
<zyga> it is surprisingly fast
<zyga> I assume that cached hot path (after reboot) must be in effect
<zyga> or ... my code is a nop ;-)
<jdstrand> yes. loading from cache is going to be fast
<zyga> reading the code carefuly I found some things to ask you
<zyga> 1) skipping in containers and 2) cache invalidation
<zyga> do I need to concern myself with 2?
<jdstrand> zyga: 2> no. the parser will do that
<jdstrand> zyga: since you are using --write-cache
<zyga> jdstrand: and 1) ?
<jdstrand> zyga: you need to do that
<zyga> ack
<zyga> jdstrand: hmmm
<zyga> jdstrand: will this break snapd in lxd?
<zyga> ^ https://www.irccloud.com/pastebin/qV2tRkpA/
<jdstrand> zyga: not if you do it right. see /lib/apparmor/profile-load and functions
<zyga> jdstrand: this is what start does as a check, is that's essentially what we need as well?
<zyga> the reason I ask is because this check runs first
<jdstrand> zyga: yes. udevadm info -an /dev/input/js0 is defined in /lib/apparmor/functions on ubuntu. you'd need to steal it
<zyga> so the more sophisticated check ... wont run
<jdstrand> wow
<jdstrand> that was not what I expected in my clipboard
<jdstrand> zyga: yes. is_container_with_internal_policy is defined in /lib/apparmor/functions on ubuntu. you'd need to steal it
<zyga> hmm, but how does that code run if apparmor.service exits quickly because the code I pasted returns early?
<zyga> ah
<zyga> I'm blind
<zyga> I didn't see the &&
<zyga> jdstrand: do you think I can source /lib/apparmor/functions
<zyga> I;d rather not copy that
<jdstrand> zyga: no. that won't exist every where
<zyga> ok
<zyga> thanks!
<jdstrand> is_container_with_internal_policy is an Ubuntu-ism since no one else had stacking until more recent kernels
<zyga> done
<zyga> it's shellcheck clean too
<zyga> I will reboot to give it one more test
<jdstrand> ohh!
<jdstrand> popey:
<jdstrand> # evdev joystick
<jdstrand> KERNEL=="event[0-9]*", SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="1", TAG+="snap_mame_mame"
<popey> is that good or bad?
<jdstrand> popey: that is good. that is just a change to joystick.go
<popey> I agree then, good :)
<jdstrand> popey: I'm still investigating, but that is super promising
 * zyga imagines jdstrand playing zelda while explaining "I'm working" at his surprised family members :)
<zyga> jdstrand: all good after reboot
<jdstrand> zyga: it literally already happened
<jdstrand> I think the quote was: You're doing God's work, aren't you?"
<jdstrand> it wasn't sarcastic at all! ;)
<zyga> jdstrand: can you have a look at 5201, it's a tiny cleanup
<zyga> jdstrand: is adb-support something that is still blocked, maybe I don't understand your prior feedback?
<mup> PR snapd#5119 closed: dirs: on opensuse store apparmor profiles in /etc/apparmor.d <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5119>
<jdstrand> zyga: approved
<jdstrand> zyga: I haven't gotten back to re-reviewing it. I've added it to my list for tomorrow
<zyga> thanks :)
<zyga> I will EOD today
<zyga> see you tomorrow
<jdstrand> zyga: take it easy
<jdstrand> kyrofa: hey, am I remembering right that you wanted evdev joystick support?
<mup> PR snapcraft#2146 opened: project_loader: process parts in consistent order <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2146>
<kyrofa> jdstrand, indeed, did you figure it out?
<jdstrand> kyrofa: yes. PR on its way
<kyrofa> Lovely!
<sergiusens> kyrofa: you should add a test using `after` too
<mup> PR snapd#5203 opened: interfaces/joystick: also support modern evdev joysticks and gamepads <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5203>
<jdstrand> kyrofa: ^ there you go (surprisingly simple)
#snappy 2018-05-25
<mborzecki> morning
<zyga> good morning
<mvo> hey zyga
<zyga> wow, I had a good sleep today
<zyga> I woke up, looked outside and noticed it's not dark anymore
<zyga> and it was about 4AM
<zyga> mvo: I have a small proposal in 5202
<zyga> might make reviewing logs a little bit less frustrating
<mvo> zyga: yeah, I saw that
<mvo> zyga: was just about to comment
<mup> PR snapd#5201 closed: interfaces/apparmor: use helper to load stray profile <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5201>
<mborzecki> mvo: zyga: hey
<mborzecki> zyga: thanks for doing the renames in 5199
<zyga> :-)
<zyga> ooooh!
<zyga> finally!!!
 * zyga got an email that his 3d printer has shipped
<zyga> after months of waiting
<zyga> I suspect this means that weekend will be spent on "some assembly required"
<zyga> mborzecki: can you please have a 2nd look on 5155
<mborzecki> looking
<zyga>  I bought a USB-C power bank at the airport
<zyga> it works with laptops and phones alike so I was looking forward to use it with my thinkpad
<zyga> but obviously, there's a bug and the kernel doesn't say "hey, I'm a type-c power sink, gimme power" and it doesn't charge in linux
<mvo> hey mborzecki good morning
<zyga> the power bank has fantastic reviews all around and works everywhere else
<zyga> a bit of a sigh :)
<zyga> so I will go on a type-c bug hunt to see why
<zyga> I just found this interesting that in the future, even charging needs a non-trivial stack of software that must work just right
<mborzecki> pedronis: added tests for setup-profiles undo in #4996
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<mup> PR snapd#5143 closed: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5143>
<zyga> mvo: do you happen to remember if LTS to LTS update kicks in at the first point release? that is 16.04 will update but only to 18.04.1?
<zyga> tests are rather red today
<zyga> and often end with
<zyga> The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
<mvo> zyga: yes, first point release
<zyga> ah, thanks for confirming that
<mvo> zyga: testsuite> anything in particular you noticed? when I looked earlier it was some repo that could not be cloned
<zyga> the thing is, I don't know, it's just red and overflowing logs
<zyga> I've yet to find an efficient way to find what broke
<zyga> eh
 * zyga filed the bug on dh-golang only to notice (at the end of the report) that the email address is "zyga@debian-9"
<mvo> bugs via email ftw :/
<zyga> debian FTW
<zyga> well, it should show up here, eventually: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dh-golang;dist=unstable
<mborzecki> new TLD debian-9 :)
<mvo> hm, having .ubuntu as a TLD would be cool
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> pstolowski: hey
<mborzecki> mvo: ICANN awaits your application :P
<zyga> morphis: hey, andbox-support PR needs some love
<mvo> mborzecki: heh, maybe a bit too much work for my free evenings ;)
<zyga> mvo: it's just 5000 and you own it
<zyga> custom TLD were approved a while a go
<mborzecki> zyga: 5000 of what currency?
<zyga> USD AFAIK
<mvo> zyga: yeah, but you also need to make some comitments technically iirc, no? I don't remember the details though
<mborzecki> heh, doped to dogecoins :)
<mborzecki> s/doped/hoped/
<zyga> oh
<zyga> it's more pricy than that
<zyga> $185,000
<zyga> ouch
<mvo> autsch indeed
<zyga> journal cursors break some tests
<zyga> it looks like buffering is in theway
<mborzecki> iirc there's a --sync flag but it didn't work on 14.04 or sth
<mborzecki> anyways, in snapd-notify test, i think it'd be better to systemctl show -p SubState and ActiveState directly
<zyga> it failed on a totally unrelated test now
<morphis> zyga: hey! I know, but I am waiting for general feedback from jdstrand first before doing any further work. I have a side-channel conversation with him on this already.
<zyga> morphis: ack
<morphis> the PR might go into a completely different direction
<zyga> you still need to add those tests
<zyga> all interfaces need tests :)
<zyga> so ... just saying
<Moruy> Hi!
<zyga> hey Moruy
<Moruy> Can I set up a package mirror snap?
<morphis> zyga: I know, but will skip that until we're at that point :-)
<zyga> Moruy: would you like to mirror snap packages or install a snap that mirrors some other packages?
<Moruy> I want to mirror that "https://api.snapcraft.io/", but it's locked in source code.
<zyga> Moruy: you want to deploy this instead: https://forum.snapcraft.io/t/announcing-snap-enterprise-proxy-beta/4666
<zyga> you cannot mirror api.snapcraft.io as it is not a static website
<Moruy> Frankly, I want setup up a mirror that  similar with docker mirror.
<zyga> you cannot mirror the snap store, the only supported configuration is local deployment of a snap proxy
<Moruy> reverse proxy?
<zyga> please read the post I linked to
<Moruy> (à²¥â£à²¥)
<popey> Is there some way to purge old revisions of snaps in one go?
<popey> I have run out of disk space, and the old revisions are eating a ton of it
<zyga> popey: nope, I don't think there is
<popey> :(
<popey> 24G     /var/lib/snapd/snaps/
<zyga> popey: find the top three using ncdu
<zyga> and remove those specifically
<popey> that's not very user friendly
<popey> (and yes, I already did that)
<Moruy> Enterprise Proxy is so complex and I will try reverse proxy to mirror it.
<zyga> it won't work Moruy
<popey> https://forum.snapcraft.io/t/configure-number-of-old-revisions-to-keep/2337/4
<popey> :(
<Moruy> api.snapcraft.io low download speed, it not has any CDN using.
<zyga> Moruy: all downloads are using the CDN
<mup> PR snapd#5204 opened: data: add helper that can generate/start/stop the snapd service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5204>
<mvo> zyga: ^- this is based on what we talked about yesterday
<zyga> yep, looking
<zyga> sigh
<zyga> where are google credentials for spread stored?
 * zyga cannot find them
<Chipaca> moin moin
<mborzecki> zyga: travis secrets maybe?
<Chipaca> mvo: one thing that core18 needs, that I don't know a tidy way of getting it there short of forking, is the system-shutdown helper
<zyga> no, it's that thing you need to keep somewhere on your disk
<Chipaca> mvo: â¦ although, it's copied every time, so maybe just copy it from the snapd snap
<Chipaca> hmm
<mvo> Chipaca: yeah, it seems like we can run it from the snapd snap
<zyga> mvo: reviewed
<mvo> zyga: thank you
<mvo> Chipaca: the PR is just opened is about making our service work on bases, we probably need to plug it in there (also repairs and all the other services we use)
<popey> How terrible is this? https://www.irccloud.com/pastebin/MMTaDh6u/purge_old_snap_revisions.sh
<popey> ^ zyga / Chipaca - opinions?
<Chipaca> popey: I have *lots* of opinions
 * Chipaca clicks the link
<zyga> I don't think you need to close all snaps
<popey> what if I still have a snap running
<zyga> disables snaps don't run
<popey> like firefox which I have running for days, and it's refreshed already
<zyga> *disabled
<zyga> ahhh
<zyga> bummer :)
<Chipaca> popey: it  won't be happy if you do
<Chipaca> popey: OTOH, we also do it
<Chipaca> so, it won't be super sad either
<popey> warning is really just ass-covering
<popey> 12G     /var/lib/snapd/snaps/
<popey> it's halved the amount of space used
<popey> (I ran it before you reviewed it) :)
<Chipaca> popey: the idea is sane
<mvo> zyga: thanks for the review. I ran it on a core18 system. why? anything that looks suspicious?
<popey> thanks
<zyga> mvo: no, I just was curious since we don't have any automated feedback yet
<Chipaca> popey: I'd criticise the shell, but if it works and it's just a personal tool it's probably fine
<mvo> zyga: yeah, I was thinking what can be done, spread testing this at this point is hard :/ or a bit theoretical, i.e. I could very that the output looks vaguely correct but the real start is harder
<popey> So you don't think it's a good idea to share it Chipaca ?
<popey> (people *keep* asking for this feature)
<Chipaca> popey: in its present state, yes don't share it
<Chipaca> popey: making it robust and sharing it, â¦ a little torn about it
<zyga> making it a feature and releasing it
<zyga> snap remove --disabled
<mvo> would be nice to have a "snap set system.keep-revision=" option
<Chipaca> yeah, i'd rather do that :-)
<Chipaca> both things
<Chipaca> in fact, today's friday, means we can do 20% stuff right?
<popey> meanwhile, disks are ffilling up :)
<zyga> ohh
<zyga> Friday
<zyga> coming back from holidays mid week is weird
<zyga> I thought it is Tuesday
<Chipaca> zyga: it's not friday for you! you've had too much fun
 * Chipaca takes away zyga's friday rights
 * Chipaca adds extra tails to his whip
<zyga> Chipaca: I await the day when we are both at a bar in Spain and have a beer together watching the sea quietly shimmer outside
<zyga> Chipaca: (the sea in Spain is oddly silent)
<Chipaca> zyga: in barcelona, yeah
<Chipaca> long beach
<Chipaca> other places not so much
<zyga> Chipaca: at this point the only question is "when"
<Chipaca> zyga: either in the next month, or not for a ~year
<Chipaca> judging by past performance of the home office
<Chipaca> popey: how about: https://pastebin.ubuntu.com/p/6KWZXtJWwS/
<pstolowski> mvo: one tiny tiny nitpick re 5183 (feel free to ignore)
 * Moruy 
<popey> Chipaca: oh, that's prettier. I like that. Thanks, learned something too :) <3
<Chipaca> popey: shellcheck says I should use -r on the read,  but I don't know if that's portable
<Chipaca> popey: also, it needs a comment about GDPR complaince just before 'set -eu'
<popey> lulz
<popey> Chipaca: https://askubuntu.com/questions/1036633/how-to-remove-disabled-unused-snap-packages-with-a-single-line-of-command
<popey> earn some karma by pasting it there :)
<mborzecki> Chipaca: you're clearly excluding 'eu', so no gdpr notice needed
<mvo> pstolowski: thank you for the review. I think I can just remove those line and it makes sense to cleanup the control file too
<zyga> Chipaca: LOL
 * zyga googles for those google credentials
<zyga> Chipaca: remember when I was playing with flatpak edit?
<zyga> gedit
<Chipaca> popey: https://askubuntu.com/a/1040131/711
<zyga> I just noticed that left ~/.var on my disk
<zyga> with lots of goo inside
 * popey upvotes
<popey> thanks Chipaca
<pedronis> zyga: are you looking for ~/.config/gcloud/application_default_credentials.json   ? or something else
<zyga> ah
<zyga> yes, thank you pedronis !
<Chipaca> popey: I dount this will get me over the 10k hump though :-)
<popey> Chipaca: there are a thousand other snap questions you could answer :)
<popey> which would
<Chipaca> popey: I got very demotivated last time I did a round of questions there as there were a lot about how much my work sucks
<Chipaca> popey: but i'll give it another go sometime soon (or you can point me at 'em)
<popey> we have a bot in our slack channel which announces them all every morning to motivate us to answer them.
<popey> https://askubuntu.com/unanswered/tagged/snap?tab=noanswers
<popey> ones with no answers, tagged with snap.
<Chipaca> popey: if you know somebody in jetbrains, maybe forward https://askubuntu.com/q/988315/711 to them
<Chipaca> popey: in askubuntu, how do you flag something that should be a bug report instead?
<Chipaca> it's not 'too broad' -- it's too narrow :-)
<pedronis> mmh, pstolowski, IÂ had forgotten but auto-connect was simply ignoring conflicts, it still seems right tbh
<pedronis> so only reconnect could have this bug
<pstolowski> looking
<pstolowski> pedronis: hmm, yes and no.. we would never auto-connect in case of conflict, no?
<pedronis> pstolowski: don't we have a test exactly about that?
<Chipaca> jdstrand: if you're feeling lyrical, https://askubuntu.com/q/789231/711
 * zyga takes the dog out
<pstolowski> pedronis: indeed we have. now i wonder if the test is doing the right think, or if there is something else
<pstolowski> *thing
<pedronis> pstolowski: by definition  if we reached autoconnect we are done with our link-snap and setup-profiles, otoh the other side if it's conflicting hasn't
<pstolowski> pedronis: right, that's it
<pedronis> pstolowski: so it will do autoconnect later and shouldn't get a conflict
<pstolowski> and it will actually prevent running everything twice i think
<pedronis> yes
<pstolowski> okay, so probabaly i shouldn't touch autoconnect logic
<pedronis> but you changed ConnectOnInstall
<pedronis> so you need to do something
<pstolowski> yes
<pedronis> pstolowski: btw the same logic would probably also have worked for reconnect
<pedronis> except reconnect is less best-effort
<pedronis> than autoconnect
<pedronis> so not sure we can trust the fact that the other side will do reconnect
<pedronis> also probably we care about errors more
<pstolowski> yes
<pedronis> pstolowski: otoh we wouldn't need the helper,   and also doing things twice is strange problematic on its own
<pedronis> even for reconnect
<pedronis> pstolowski: anyway I think we should indeed put back autoconnect to ignore error/conflicts
<pedronis> pstolowski: keep the full new logic only for reconnect
<pedronis> pstolowski: added a couple of comments about this
<pstolowski> thanks
<mup> PR snapd#5183 closed: snapcraft.yaml: add minimal snapcraft.yaml with custom build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5183>
<mup> PR snapd#5205 opened: packaging: fix description <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5205>
<kjackal> is there a hook firing when a new revision is applied?
<kjackal> I mean when a snap get refressed/upgraded can I run anything?
<kjackal> its the configure hook
<pedronis> pstolowski: question: on reconnect the hook see the dynamic attributes as set on connect, right?Â not just the static ones?
<pstolowski> pedronis: yes, the will come from prepare- hook
<pstolowski> *they
<pedronis> pstolowski: no,  that is not what I mean
<pedronis> IÂ probably should look at the code
<pstolowski> pedronis: it should see potentially new attributes as that's the goal of reconnect
<pstolowski> but perhaps i misunderstand the question
<pedronis> pstolowski: it doesn't
<pedronis> pstolowski: I thought that on a reconnect we would set the dynamic attributes as their are on the connection that is redone
<pedronis> but it seems we start from scratch
<pstolowski> yes we start from scratch
<pedronis> pstolowski: the issue is if the slot side reserve some resource on connect, it willl do it again on reconnect
<pedronis> there should be a way for it to reuse the same resource
<pedronis> one way would be to give the last set state of the dynamic attrs
<pedronis> maybe there's another way
<pedronis> but starting completely from scratch
<pedronis> seems too simple
<pstolowski> pedronis: perhaps we should run disconnect hooks then
<pedronis> pstolowski: it it picks a new resources the slot wouldn't even know the old one is not in use anymore
<pstolowski> otherwise we have same problem as discussed before with undoing stuff
<pedronis> pstolowski: then it really becomes  disconnect/connect
<pedronis> it would work, but seems inefficent
 * zyga made some ice coffee 
<zyga> today is a pretty hot day
<mborzecki> pedronis: when validating uniqueness of appstream-ids, we'll bail out only during snap pack --check-skeleton, but when installing a snap we'd just log something, does that sound ok?
<pstolowski> pedronis: yes it would definately be inefficient and add even more hooks run every time
<pedronis> pstolowski: :(
<pedronis> pstolowski: anyway, do you see the problem I'm describing?
<pstolowski> pedronis: we can pass existing values, it just adds more complexity for hook authors
<pstolowski> pedronis: yes yes
<pedronis> mborzecki: do we have other things we treat like that? hard error on pack, just logged on install?
<mborzecki> pedronis: i don't think so
<pedronis> mborzecki: so maybe not
<pedronis> just error
<pedronis> in both cases
<mborzecki> fair enough
<mborzecki> i mean review tools should probably catch this, so such snap would not be in he store anyway
<pedronis> mborzecki: yea, I pinged jdstrand in the forum about that
<mborzecki> (hopefully?)
<pedronis> mborzecki: anyway atm there are not many snaps with this set
<mborzecki> yup, fair point
<Chipaca> hmm, shouldn't "snap get system refresh.timer" work?
<mborzecki> well, i know of telegram for sure, and there's also one that i just published tests-snapd-appstreamid
<zyga> wow, some heavy rain
<zyga> like in some jungle :)
<mborzecki> maciek@galeon:~ sudo snap get system refresh.timer
<mborzecki> 00:00-24:00/192
<mborzecki> Chipaca: ^^
<pedronis> mborzecki: it doesn't here
<pedronis> did we stopped storing it in the config if it's the default?
<Chipaca> and the error message is rather poor
<mborzecki> Chipaca: what does it say?
<Chipaca> $ snap get system refresh.keep-inactive
<Chipaca> error: snap "core" has no "refresh" configuration option
<pedronis> I don't have either schedule or timer
<mborzecki> aah ok, you've never set it
<pedronis> in my refresh config
<Chipaca> er, well, same with .timer :-)
<mborzecki> Chipaca: can you try set and then get ?
<pedronis> Chipaca: snap refresh --time prints it though?
<Chipaca> pedronis: yes
<Chipaca> mborzecki: sure, if i set it it works
<pedronis> mborzecki: the issue is that at some point at least for schedule we were setting it in the config even when we picked the default
<mborzecki> Chipaca: or snap get system -d
<mborzecki> pedronis: yeah, iirc it was set as in set-set, but then that went away when refresh timer was introduced with the comment that we should not set it if it's unset
<pedronis> Chipaca: ^
<mup> PR snapd#5206 opened: get-deps: work with an unset GOPATH too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5206>
<zyga> mvo your simple pr failed with
<zyga> The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
<mup> PR snapd#5207 opened: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <https://github.com/snapcore/snapd/pull/5207>
<Chipaca> ^ 'snap set system refresh.keep-inactive=99' (for popey)
<zyga> can we get that -v filter-out PR merged?
<pedronis> zyga: do we know it helps?  it's been -v since forever, what did change?
<pedronis> I still find a bit too hackish
<zyga> we spawn more machines
<pedronis> ?
<zyga> so if something fails early we see all the goo out of package building multiplied numerous times (per machine)
<zyga> I ran dpkg-buildpackage and it's far shorter now
<zyga> try it, it's really much more readable
<Chipaca> zyga: I enjoyed getting all the emojis way too much
<Chipaca> it's a high bar, but I will strive for it more often
<mup> PR snapd#5208 opened: interface hooks: update old AutoConnect methods <Created by stolowski> <https://github.com/snapcore/snapd/pull/5208>
<pedronis> pstolowski: do you need more input from me?   connect vs reconnect state is probably something to mention at the standup
<pstolowski> pedronis: indeed; no, thank you for the review
<pedronis> Chipaca: btw, do IÂ remember correctly that we still need to give proper error codes to conflict errors?
<pedronis> mvo: do have a SRU in progress for xenial?
<pedronis> Chipaca: s/code/kind/
<Chipaca> pedronis: possibly
<Chipaca> pedronis: we also have not advanced returning error kinds on async jobs
<pedronis> Chipaca: is that related?
<Chipaca> pedronis: I don't know the context of your question :-) so, maybe
<pedronis> Chipaca: we get conflict error because creating the changes, no?
<pedronis> I do remember you had a case for returning errors on async
<Chipaca> pedronis: s/because/before/ yes
<Chipaca> so they should be async indeed
<Chipaca> i mean sync
<Chipaca> heh
<pedronis> but IÂ don't remember what it was
<zyga> Chipaca: hey, question
<zyga> how to debug completion tests?
<zyga> better yet
<zyga> I'm in the debug shell
<zyga> how do I run them?
<Chipaca> zyga: https://forum.snapcraft.io/t/debugging-tab-completion/4198 ?
<Chipaca> zyga: ah
<zyga> failure log https://www.irccloud.com/pastebin/yC9IEnv0/
<Chipaca> zyga: expect -d -f thefailingthing.exp
<Chipaca> zyga: or drop the -d to understand the error, then add it back to understand why the error
<zyga> I need to export those variables?
<Chipaca> zyga: which variables?
<zyga> OUT, KEY etc
<zyga> otherwise I get an error instantly
<zyga> after setting some vars
<zyga> more errors https://www.irccloud.com/pastebin/9NmWJCbi/
<Chipaca> zyga: ah, sorry was looking at the main/completion
<Chipaca> zyga: yes, look at task.yaml for that
<Chipaca> zyga: that last one is an error?
<Chipaca> that looks like success to me
<Chipaca> maybe i'm missing something
<zyga> does anything in https://api.travis-ci.org/v3/job/378833810/log.txt look like an error?
<Chipaca> zyga: in the first thing you pasted there was an error
<jdstrand> 05:10 < pedronis> mborzecki: yea, I pinged jdstrand in the forum about that
<jdstrand> pedronis: I just came online, but may have missed it if it wasn't last night. what topic? ^
<Chipaca> zyga: 'does <....> match <..>? no\n timed out'
<Chipaca> zyga: that's what errors look like
<mborzecki> jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327
<zyga> Chipaca: honestly all those tests look like magic to me
<zyga> and I have no idea why it fails
<Chipaca> zyga: it failed because it completed nothing
<Chipaca> zyga: why did it complete nothing? can you reproduce that?
<pedronis> jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327/29
<zyga> Chipaca: ... perhaps? tell me what to do
<Chipaca> zyga: standing in that directory, type test-snapd-complexion <tab><tab>
<zyga> the branch enables apparmor
<zyga> but I don't see any denials
<zyga> ok
<pedronis> jdstrand: it's about review-tools   checking that common-id doesn't get repeated across apps in the same snap
<Chipaca> zyga: it should offer 'a/   b/   bar  baz  d/   foo'
<Chipaca> zyga: (same as 'ls <tab><tab>' would)
<zyga> google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion
<zyga> test-snapd-complexion      test-snapd-complexion.two
<zyga> it seems it doesn't
<Chipaca> (i lied, ls wouldn't)
<Chipaca> zyga: so, tab completion isn't working in opensuse
<zyga> mmm
<Chipaca> zyga: sadface
 * zyga thinks
<Chipaca> hold on
<zyga> but it used to
<zyga> it's just broken here in this branch
<Chipaca> zyga: did you enabe tab completion in that shell
<Chipaca> enable*
<zyga> oh? no
<zyga> how do I do that?
<pedronis> jdstrand: here's the wip snapd check:  https://github.com/snapcore/snapd/pull/5199/commits/17d9cab6366de447c2aa8049a1fd10b05ab947d4
<mup> PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199>
<zyga> jdstrand: I fixed 5203 for you
<Chipaca> zyga: if you  ls <tab><tab>, does it list things for you?
<zyga> Chipaca: yes
<Chipaca> zyga: ok
<zyga> also tab tab completed the command names above
<zyga> so some part of it must work
<Chipaca> zyga: you need to source one of the .complete files
<pedronis> mborzecki: if the snap is already created you need to ask store admins to transfer it to canonical shared account
<Chipaca> zyga: 1 sec
<zyga> thanks!
<jdstrand> zyga: oh, I was just looking at that
<zyga> I really want to get to the bottom of that
<zyga> to get apparmor operational in opensuse
<zyga> and in general, in more distros that can just opt in
<jdstrand> zyga: thanks
<zyga> jdstrand: :-)
<Chipaca> zyga: source hosts_n_dirs.complete
<zyga> ack
<zyga> done
<Chipaca> zyga: now what does test-snapd-complexion <tab><tab> do
<zyga> it is completing ... ip addresses?
<zyga> google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion
<zyga> ::1               fe00::0           ff02::1           ff02::3           ipv6-allhosts     ipv6-allrouters   ipv6-localnet     ipv6-mcastprefix  simple/
<zyga> data/             ff00::0           ff02::2           indirect/         ipv6-allnodes     ipv6-localhost    ipv6-loopback     localhost         snippets/
<Chipaca> ah, right, 1 sec
<Chipaca> zyga: look at hosts_n_dirs.sh
<Chipaca> zyga: do that :-)
<zyga> ah
<Chipaca> zyga: to be clear, none of this involves apparmor or anything
<zyga> # cat data/hosts.txt
<zyga> 127.1.2.3 foo bar baz
<Chipaca> zyga: at least from the 'simple' side of things, this is just sanity-checking the test suite
<Chipaca> the 'indirect' one does the same via a snap
<Chipaca> and that one does involve the whole dance
<zyga> I see
<zyga> and the .two app?
<zyga> the .two app appears to complete stuff in practice
<zyga> well, they both (main app and .two app) complete the exact same thing
<Chipaca> zyga: that's expected
<Chipaca> zyga: I'll go grab lunch
<zyga> can I trigger the completion failure somehow from this interactive shell?
<zyga> ok
<Chipaca> zyga: i can dig into this after
<zyga> I'll look at the non-completion tests
<zyga> thanks!
<Chipaca> zyga: my memory is stale, probably easier for me to debug it if it's reproducible
<zyga> yeah, all the time
<Chipaca> perfect
<zyga> Chipaca: interestingly, only _some_ have failed
<zyga> many of those work
<Chipaca> zyga: list 'em for me :-)
<zyga> one sec
<zyga> trying to close all other instances
<Chipaca> k
<zyga> failed tests https://www.irccloud.com/pastebin/N38F51o6/
<Chipaca> zyga: that's all the ones that go through (de)serialization
<zyga> mmm
<Chipaca> zyga: ie all the ones that talk to snap run
<zyga> mm
<zyga> I'll run the non-completion tests (well, running now) and see if there are any hints
<zyga> maybe it's something simple and obviously missing/broken
<Chipaca> ok
 * Chipaca ~> lunch or death
<mvo> pedronis: there is a SRU in progress for xenial, yes. do we need anything in there?
<pedronis> mvo: no, just wondered, because I noticed snapd there doesn't have SNAPD_BASES_CHANNEL yet afaict
<mvo> pedronis: yeah, its time that 2.33 gets out of the door :)
<mup> PR snapd#5205 closed: packaging: fix description <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5205>
<pedronis> mvo: I think is in one of the 2.33 already
<pedronis> possibly
<pedronis> but yea
<zyga> cachio_: hey, what's the chance of us getting a tumbleweed image?
<mup> PR snapd#5202 closed: packaging: filter out verbose flags from "dh-golang" <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5202>
<zyga> Chipaca: don't waste your time please, I found the issue
 * Chipaca ~> second lunch
<Chipaca> :-D
<mup> PR snapd#5155 closed: interfaces/apparmor: use strict template on openSUSE tumbleweed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5155>
<pedronis> heh, I meant 2.32
<mvo> pedronis: indeed, 2.32.3.2 is where we are in xenial I need to chase sergio
<mup> PR snapd#5118 closed: packaging/opensuse: build with apparmor <Squash-merge> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5118>
<pedronis> pstolowski: btw,  I'm thinking a bit more, I'm coming to the conclusion that we need to conflict also on connect carefully, I mean the same exact connect should be added at most once to a change
<zyga> cachio_: hey
<zyga> cachio_: can you work with me for a moment, I'd like to build a tumbleweed image for opensuse
<mup> PR snapd#5209 opened: packaging: add packaging for openSUSE Tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/5209>
<mup> PR snapd#5210 opened: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Created by zyga> <https://github.com/snapcore/snapd/pull/5210>
<pstolowski> pedronis: you mean when we do multiple Connects in a single change?
<pedronis> pstolowski: yes,  I fear  we will get very confused if we are not careful
<pedronis> because of state
<pedronis> and hooks
<pedronis> pstolowski: the connect-plug/slot-*Â hook cannot change the attributes anymore, is that right? only prepare can change them?
<zyga> https://lwn.net/Articles/755238/  <- entitlements are a little bit like interfaces
<mup> PR snapd#5206 closed: get-deps: work with an unset GOPATH too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5206>
<pstolowski> pedronis: yes
<Chipaca> mvo: ï¼­ï¼¡ï¼§ï¼©ï¼£
<mvo> Chipaca: \o/
<mup> PR snapd#5211 opened: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5211>
<mup> PR snapd#5200 closed: interfaces: reconnect, fix for autoconnect/reconnect conflict check <Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5200>
<mup> PR snapd#5196 closed: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5196>
<pedronis> pstolowski: let me know if you want to discuss a bit about checking conflicts for connect/disconnect
<pstolowski> pedronis: i've headache.. not the best moment :/
<pedronis> pstolowski: let's do it on monday then
<pstolowski> thanks
<mup> PR snapd#5210 closed: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5210>
<pedronis> pstolowski: and get well!
<pstolowski> will try to propose error handling improvement in the meantime
<pstolowski> thanks1
<mvo> pstolowski: yeah, get well!
<pstolowski> thanks, it's not too bad
<zyga> niemeyer: can you have a quick look at https://github.com/snapcore/snapd/pull/4889#discussion_r190898209
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<niemeyer> Heads up: forum is about to go down for maintenance!
<zyga> jdstrand: is there anything to do more on #5170
<mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<niemeyer> zyga: I can, but not right now.. forum migration under way
<jdstrand> zyga: I continue to have it on my list for today. keep in mind, it is still morning here ;)
<zyga> jdstrand: no worries, thank you :-)
<mup> PR snapd#5211 closed: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5211>
<mup> PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162,
<mup> snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209
<mup> PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162,
<mup> snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209
<mup> PR snapd#5212 opened: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5212>
<niemeyer> Forum migration completed. You may need to hard-refresh or restart your browser for it to see the new IP address.
<zyga> Chipaca, jdstrand: commented on https://askubuntu.com/questions/789231/how-are-snap-applications-being-protected/1040259#1040259
 * popey upvotes
<sil2100> mvo: is there any reason why we're running travis checks for core18 on trusty and not on xenial?
<sil2100> Just curious
<zyga> sil2100: travis sucks
<zyga> sil2100: no, we should use xenial if we can (there's a switch AFAIK)
<sil2100> zyga: ok, thanks ;)
<sil2100> yay travis is now giving some useful info
<zyga> popey: how can I mark one post as a duplicate of another (on askubuntu)
<Pharaoh_Atem> zyga: it'd be interesting if snapd was wired up with centos ci to use spread
<Pharaoh_Atem> https://wiki.centos.org/QaWiki/CI/GettingStarted
<Pharaoh_Atem> https://wiki.centos.org/QaWiki/CI/GithubIntegration
<zyga> what would be the point of that?
<Pharaoh_Atem> some better/more reliable backends for CI
<Pharaoh_Atem> the current CI stuff has been very hokey :/
<zyga> yes but the problem is everyone has something and then every snapd developer needs to know how to use _each_ of those systems to work
<zyga> yes, I would love to see a general way to build spread images for qemu, google or other systems
<Chipaca> zyga: under the question, click on 'close'
<Chipaca> zyga: there's a "is duplicate of..." option
<zyga> thanks!
<zyga> mvo:
<zyga> what is this?
<zyga> +ExecStartPre=/bin/touch /dev/iio:device0
<zyga> this is from 73ff712a89aa3bd65ab8b5b23e956413294375c8
<Chipaca> zyga: a hack to fake a device for a test
<Chipaca> zyga: tests/main/interfaces-iiio
<Chipaca> iio
<Chipaca> io
<Chipaca> o
<zyga> why does this fail? https://www.irccloud.com/pastebin/v4Mm7FrG/
<zyga> https://www.irccloud.com/pastebin/gywakiP4/
<zyga> hmmhmmhmm
<mvo> sil2100: no good reason, if we can switch to xenial I'm all for it
<mup> PR snapd#5212 closed: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5212>
<Pharaoh_Atem> mvo: travis still can't do xenial :/
<sil2100> Seems to work here
<mvo> sil2100: ohhhhh, nice
<sil2100> I mean, it still segfaults, but running on xenial
<sil2100> (investigating further)
<mvo> sil2100: hm, sad that it still segfaults, I wonder if it works in a normal VM
<sil2100> Let me test that
<sil2100> Since there's nothing else obviously broken
<popey> Chipaca: is there any caching when doing "snap find"?
<popey> I have updated sections in the store and one isn't showing up for me
<popey> snap find --section=server
<popey> ^ that should work, but it doesn't
<noise][> popey: two things at play - 1 hr cache on the store side (already refreshed) and i think snapd only refreshes the section list once per day
<popey> noise][: thanks!
<sil2100> mvo: I'm still looking into this, but interestingly it also segfaults on a xenial VM - from what I see it's segfaulting on executing the default override-stage scriptlet, which by default is handled by 'snapcraftctl stage'
<sil2100> mvo: both for snapcraft as a snap and deb - but since I have a local reproducer I can finally dig into this properly
<mup> PR snapd#5213 opened: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/5213>
<mvo> sil2100: cool, I guess sergio will also want to know
<mvo> another simple review to unblock the snap (finally) 5213
<mup> Bug #1773416 opened: Interface from Thunderbird/Firefox to LibreOffice/VLC <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1773416>
<kyrofa> Pharaoh_Atem, travis CAN do xenial, but it's pretty experimental right now
<kyrofa> sil2100, I can't quite determine what you're talking about from the scrollback, but snapcraft segfaulting on trusty is a known issue
<kyrofa> (for classic snaps anyway)
<kyrofa> (normal ones should be fine)
<kyrofa> But are you saying it's also segfaulting on xenial?
<Chipaca> popey: snap find doesn't cache, but sections are
<popey> Ok, good to know, thanks
<Chipaca> popey: but only for completion
<Chipaca> popey: if you type it, it should work
<popey> uh
<popey> nope
<Chipaca> hm
<Chipaca> hmm
<popey> https://www.irccloud.com/pastebin/omgnsTv3/
<Chipaca> hmÂ³
<Chipaca> yes, seeing same
<Chipaca> hah
<Chipaca> popey: I'm a lying liar
<Chipaca> popey: of lies
<popey> Noted
<Chipaca> popey: also, this is arguably a bug
<Chipaca> let's argue about it :-)
<popey> Ok!
<popey> It is a bug.
<Chipaca> I agree.
<Chipaca> dammit
<Chipaca> how were arguments supposed to work
<popey> I really am top of my game today
<popey> Would you like me to file a bug somewhere (where?)?
<Chipaca> popey: nah, i'll fush a pix right now
<popey> \o/ <3
<Chipaca> popey: as a workaround, sudo rm /var/cache/snapd/sections
<popey> \o/ success
<popey> Will everyone have to do that? (until the fix lands)?
<noise][> Chipaca: presumably it updates regularly? daily? or is the bug that it is never updating?
<Chipaca> noise][: it updates regularly
<noise][> cool
<Chipaca> noise][: the bug is just in the overzealous 'no such section' path
<Chipaca> I get it's trying to be helpful, but it could check the store if the cache doesn't have it
<Chipaca> that's what i'm implementing
<Chipaca> ok?
<Chipaca> check cache -> nope? check store
<Chipaca> and just in the --section=<foo> path
<Chipaca> hmm, OTOH the argument for it not being a bug is that sections are mostly static
<Chipaca> and we control them
<Chipaca> so we could just be patient :-D
<Chipaca> (it refreshes once a day, fwiw)
<popey> I want to do a social post to let everyone know about it
<Chipaca> popey: yes
<Chipaca> and I understand the motives for not having the section and not talking about it
<Chipaca> you want to add a section, and talk about it straight away, and have it work for early adopters and etc
<Chipaca> for teh buzz
<kyrofa> Hey Chipaca, I've got a PR up to make sure snapcraft doesn't toast the prime directory if a dev has used `snap try` on it. It works, but I'm parsing mountinfo just to see if the priming area is bind-mounted. It would be handier if snapd just exposed the mountpoint for tried snaps in the REST API. Thoughts?
<Chipaca> noise][: cprov: ok with you to hit the store if a user does 'snap find --section=xyzzy' and xyzzy is not in the cache?
<kyrofa> Er, not mountpoint, but root
<Chipaca> kyrofa: I agree! not sure how doable it is. Forum topic!
<kyrofa> Alright, I'll make one
<Chipaca> kyrofa: friday beer o'clock; cross-boundary problems are too deep
<Chipaca> kyrofa: (and that one might involve asking systemd stuff)
<Chipaca> or at least snapstate
<Chipaca> anyway, not fit for my head now
 * Chipaca wraps up the (un)cache one hoping to hear back from cprov and noise][ soonish
<cprov> Chipaca: I don't have any objections, the store endpoint is cached for 1h. In theory, hitting the store for unknown section would give us some idea of which sections users are looking for.
<Chipaca> cprov: profit :-)
<cprov> Chipaca: exactly, thanks for working this out.
<Chipaca> cprov: hold on
<Chipaca> cprov: I'd not be hitting the store asking for one section
<Chipaca> cprov: I'd be hitting it asking for all sections
<Chipaca> there isn't an api for "is this a section"
<popey> Chipaca: ok, will put the social post on hold for now until I get the nod.
<Chipaca> popey: when was the section created?
<cprov> Chipaca: you are right, there is no way to hint the store on this
<popey> a few hours ago
<Chipaca> cprov: 24 hours from that, everybody will have it
<Chipaca> um
<Chipaca> popey: ^
<Chipaca> cprov: a lot of people will have it before then though
<Chipaca> augh
<popey> ok so a social post on sunday to be safe
<Chipaca> popey: ^
<popey> sound reasonable?
<popey> (we want to try some weekend social posts)
<Chipaca> popey: as this chance is going to master, and that's ~2 months from everybody getting it, next time something like this needs doing create the empty section first, and populate it for the news
<Chipaca> capisce?
<popey> Gotcha
<popey> So one thing I'm not clear on. Right now, today as we stand, if I tell people on Sunday to "snap find --section=server" will that work?
<Chipaca> popey: yes
<popey> Ok, great! Thanks.
<Chipaca> popey: snapd refreshes that on boot, and then every 24 hours
<mup> PR snapd#5214 opened: cmd/snap: check with snapd for unknown sections <Created by chipaca> <https://github.com/snapcore/snapd/pull/5214>
<Chipaca> popey: ^
<popey> *hugs*
<cprov> thanks, Chipaca
<popey> cprov: i can't view sections in the web store can I?
<Chipaca> now i'm off to make fugazzetta
<Chipaca> o/
<popey> o/
<noise][> popey - not yet, is on the webteam's short-term todo though
<popey> sweet
<popey> It's coming togther :D
<cprov> popey: no, but you can use `curl -s https://api.snapcraft.io/api/v1/snaps/sections | jq '._embedded["clickindex:sections"]'`
<sil2100> kyrofa: yeah, segfaulting on xenial as well - I saw the issue you're talking about but I guess this might be different, as it's not during building a classic snap
<popey> seamless :)
<sil2100> kyrofa: anyway, I'll be digging into that more later
 * sil2100 EODs for now
<sil2100> o/
<jdstrand> roadmr: hi! one more small request. can you pull r1079? it is also not urgent. it can come after the first or after the first two, whatever you want
<niemeyer> zyga: You're hopefully not here anymore, but for monday, replied to that point
<zyga> Thanks
<zyga> I will check in some time
<zyga> Building stuff with bolts and nuts now
<pedronis> jdstrand: thanks for adding the common-id check
<roadmr> ohi jdstrand
<roadmr> jdstrand sure, r1079 will go to the queue, I'd like to roll out on Monday
 * mvo would love a review for 5213 pretty simple and hopefully unblocks the snapd snap building
<pedronis> mvo: have some comments there, IÂ don't understand the non-main changes
<erio> hello, has someone here snapped something with SDL2 ?
<erio> is anyone alive ?
#snappy 2018-05-26
<erio> :O
<erio> if someone has any ideas
<erio> https://github.com/ericoporto/ags-editor-snap
<erio> trying to pack ags editor as a snap
<erio> failing on steps that SHOULD work yet, didn't got to the difficult stuff :/
<AuroraAvenue> Which? snap is better for gmail - gearey or mailspring ?
<b_b> hi
<b_b> i'm trying to add 2 things to my snap
<b_b> https://gist.github.com/brunob/1155589f66171992c8661dd8a51d8555
<b_b> a .desktop file in snap/gui
<b_b> and an icon: meta
<b_b> i can't find a simple example about the path to use for that icon
<erio> are people here alive ?
#snappy 2018-05-27
<erio> is someone here ?
<popey> erio: hello
<erio> hey popey!
<popey> erio: what's up?
<erio> Erh, wanted to try something simpler, the ags engine for Linux
<erio> we have two builds of that currently
<popey> ok.
<erio> one it's a single static binary and the other is only dependent on sdl2
<erio> both are command line software
<popey> Ok, is there a problem I can help with?
<erio> you type ags in the command line, and if it finds an ags game in the folder, it runs that
<erio> 1 does the build HAS to be done in snapcraft.yaml ?
<erio> 2 is there any tool in linux for findout dependencies that need to ship?
<popey> 1) nope, you could build elsewhere and use the dump plugin to pull that in
<popey> 2) ldd
<popey> ldd will tell you what libraries the application needs
<popey> it's a good start
<erio> aahhh
<erio> ldd
<erio> thanks
<erio> is there any tool to find the plugs ?
<erio> I don't get this ...
<erio> https://gist.github.com/ericoporto/06b5a1c25b2656fdad7b04925200c961
<erio> it fails on permission denied
<erio> cp: cannot create regular file '/usr/local/bin/ags': Permission denied
<popey> probably something in the Makefile in the upstream project trying to copy install files there
<popey> might be possible to override by setting a PREFIX
<popey> I'll take a look later, but I need to sleep
<erio> aah ok
<erio> where do I need to copy the files?
<erio> in snap
<erio> is there a FAKE_ROOT variable ?
<erio> nah it's alright, good night popey
<erio> found $SNAPCRAFT_PART_INSTALL
<erio> let me left this here, maybe someone will look at it
<erio> https://github.com/ericoporto/ags-snap/blob/master/snapcraft.yaml
<erio> right now it gives no errors but generates no .snap file at the end of the build
<b_b> hi
<b_b> can we start playing with https://github.com/snapcrafters/gtk-common-themes or should we wait a bit ?
<b_b> i'd like to try this on timeline snap
<b_b> i'm not sure about the .desktop fil i'm providing here :
<b_b> https://github.com/brunob/timeline_snap/blob/master/snap/gui/timeline.desktop
<b_b> on ubuntu gnome 18.04 i have two problems with it :
<b_b> - it's named timeline.desktop.desktop in the app menu
<b_b> - cliking on it throw an error about a missing Exec in the .desktop file
<b_b> should i use Exec=timeline ?
<erio> hooray!
<erio> is there a verbose build command ?
<erio> I have a snapcraft.yaml that builds without errors but DOESN'T generate a .snap file at the end
<popey> erio: show us the yaml?
<erio> wait a second, retrying
<erio> https://github.com/ericoporto/ags-snap/blob/master/snapcraft.yaml
<erio> ooh.. wait. it worked now
<erio> I swear, thing weren't copying from stage to prime and now it did ..
<erio> hooray it's working in devmode :D
<popey> yay
<erio> I think I only need home, opengl, pulseaudio to migrate to strict
<erio> but not sure...
<erio> the snap store needs a way to link to the original .yaml file that originated the snap (if the developer wants at least)
<b_b> is there a way to tell to build.snapcraft.io that i only want adm64 build for now?
<cjwatson> b_b: Not yet; such a facility is in the works, but not finished yet.
<b_b> 'k, thx cjwatson
<b_b> was just thinking about it in order to avoid wasted time to build machines
<cjwatson> b_b: When it's implemented, it'll look like https://forum.snapcraft.io/t/architectures/4972
<b_b> nice build-on: amd64
<b_b> i'm trying to fix the desktop file provieded with my snap
<b_b> i'm reading this but not sure if it's outdated : http://ubuntudesign.github.io/docs-demo/snappy-dev/snaps_directory_structure/
<b_b> Exec=http.GET %U
<b_b> here my actual desktop file :
<b_b> https://github.com/brunob/timeline_snap/blob/master/snap/gui/timeline.desktop
<b_b> 'ive trid my snap on ubuntu 18.04 gnome, but i get an error about a missing exec line ine the dekstop file
<b_b> which doesn't seem to be the case when i look at the content of the .snap file
<b_b> shoul i call Exec=timeline.timeline ?
<b_b> timeline is the namp of the snap + timeline is also the name of the program
<cjwatson> (I'm hoping to get back to finishing the implementation of the architectures stuff on Tuesday; I got some way into it but then got sidetracked by some other urgent things.)
<cjwatson> No idea about the other thing, I'm afraid.
<b_b> thx anyaway
<b_b> i'll post on the forum
<b_b> https://forum.snapcraft.io/t/snapd-mangling-desktop-file-exec-line/2908/4 it seems to be that
<erio> is there a reason why alsa has no autoconnect ?
<erio> I found this https://forum.snapcraft.io/t/reusable-alsa-lib-part/3556/8
<erio> but there is no link to a repository - which would have newest version of snapcraft.yaml I guess
<popey> it's a remote part, you can just use after: [ partname ]
<popey> and snapcraft will go and find it
<popey> via https://parts.snapcraft.io/v1/status
<popey> (see the top of that page output - Processing origin 'https://github.com/diddledan/snapcraft-alsa.git' )
<b_b> "desktop doesnt precise is Exec field"
<b_b> weird
<b_b> if i cat /snap/tiemline/../*.desktop i can see my Exec=timeline.timeline
<erio> thanks popey !
<erio> trying that now
<b_b> Exec=<snap name>[.<app name>] [<argument> ...]
<erio>  Parts 'alsa-lib' and 'ags' have the following files, but with different contents ...
<erio> I guess I need to on the stage part , to tell snapcraft to prefer one of the parts
<erio> got it, stage can exclude with minus sign :D
<erio> uhm... it still can't access alsa from allegro
<erio> wonder if  desktop-launch is needed...?
<erio> this is the test to strict https://github.com/ericoporto/ags-snap/blob/ags-snap-to-strict/snapcraft.yaml
<erio> works, but no sound because the engine uses alsa
<erio> and it can't find alsa and then, it doesn't work
<b_b> 'k, got a working desktop file
<b_b> https://dashboard.snapcraft.io/snaps/timeline/revisions/15/
<b_b> anyone know if https://github.com/snapcrafters/gtk-common-themes can be used safely now ?
<b_b> see u ++
<ads20000> I'm loving the new refresh-date layout in 2.33! <3
<ads20000> very readable!
<popey> ads20000: you're up late :)
<ads20000> popey: need to do laundry at some point and sorting out housing for next academic year, bit of a nightmare :P
<popey> :)
<ads20000> tho a manageable nightmare...also my sleep schedule is dreadful xD
<popey> :)
<popey> Thanks for all your activity on snapcrafters. You're really all over the conversations in github and the forums.
<popey> It's really appreciated.
<ads20000> popey: I'm glad it's appreciated rather than annoying ;)
<ads20000> At least my procrastination does some good ;)
<popey> It's totally not annoying at all.
<ads20000> coolio, I'm happy to help out with a great project (despite some understandable flaws, all projects have flaws anyway)
<popey> ya
<ads20000> Love all my silently updating apps, so amazing, thanks all for the work, looking forward to even more stuff snapped in the future, particularly standard desktop stuff, silently updating GNOME is going to be amazing, we could have new GNOME well before any other fixed-release distro!
<popey> I have set my updates to happen at 4-7 am
<popey> so i wake up to new apps
<ads20000> niiiiice, tho that means you have your comp on all the time? ð¤ I guess most people do that tbh...I do it these days because my computer's alarm is good at waking me up xD
<popey> oh yeah. I sometimes suspend it if i remember
<ads20000> popey: was it you who marked yourself as affected by [this bug](https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1770961)? That would make it easier for people to access the refresh timer :)
<mup> Bug #1770961: Add options to set the snappy refresh schedule <amd64> <apport-bug> <bionic> <wayland-session> <software-properties (Ubuntu):Confirmed> <https://launchpad.net/bugs/1770961>
<ads20000> (on Ubuntu)
<popey> ooh, that would be cool
#snappy 2019-05-20
<zyga> Hello
<zyga> I will start later today. My son is going for a weekly school trip. Need to see him off
<mborzecki> morning
<zyga> Hey hey
<zyga> 07:09 <zyga> I will start later today. My son is going for a weekly school trip. Need to see him off
<mborzecki> zyga: hey
<zyga> Still waiting for the coach to pick the kids up
<zyga> Lots of traffic in Waw this morning, could be a while
<pstolowski> mornings
<mup> PR snapd#6875 opened: store,daemon: add client-user-agent support to store.SnapInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/6875>
<zyga> Hej PaweÅ
<zyga> Hey pedronis, how are you doing?
<zyga> I will be starting in about an hour
<zyga> Bus is packed and ready to go (school trip)
<mup> PR snapd#6876 opened: Optical-drive Interface: Add scsi-generic support <Created by diddledan> <https://github.com/snapcore/snapd/pull/6876>
<diddledan> morning :-)
<mborzecki> pstolowski: hey
<pstolowski> o/
<mborzecki> mvo taking a day off today?
<mvo> mborzecki: I'm here
<mborzecki> mvo: hi, didn't notice
<mvo> mborzecki: doing silly admin stuff right now :)
<mvo> mborzecki: yeah, mostly silent
<mborzecki> mvo: #6872 needs a glimpse from you
<mup> PR #6872: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
<mvo> mborzecki: sure, will do !
<pedronis> I'm around too, will swap Fri
<zyga> re
 * Chipaca thinks things are too quiet and goes to check his email
<zyga> Chipaca: hey :)
<zyga> how was last week
<zyga> man, it's good to be home with all the peace and quiet here!
<Chipaca> zyga: :)
<Chipaca> last week was a'ight
<zyga> and *plenty* of updates after last week's CPU bugs
 * zyga reboots 
<mvo> hey Chipaca and pstolowski !
<pstolowski> hey o/
<Chipaca> mvo: o/
<Chipaca> mborzecki: with parallel installs, hooks don't run with remapped names, right? ie a hook can't do "snapctl restart foo.bar", they need to do "snapctl restart $SNAP.bar"?
<mborzecki> Chipaca: the forum topic?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: just checking before telling them they're holding it wrong
<mborzecki> Chipaca: wanted to sync with pedronis/mvo first, but I believe, all the commands should use $SNAP_INSTANCE_NAME & $SNAP_NAME instead of hardcoding nextcloud
<mvo> yeah, hardcoding sounds bad(tm)
<mborzecki> Chipaca: in that case, SNAP_INSTANCE_NAME == nextcloud_1
 * Chipaca always hardcodes nextcloud even if the snap is called something else
<Chipaca> mborzecki: good :)
<Chipaca> bah, i can see the dev's perspecive on this, seems weird, but yeh
<pedronis> yes, I'm not sure we can reasonably ask them that
<mborzecki> doing magic could work, but i sense possible problems when we have cross snap ordering and whatnot
<pedronis> why?
<pedronis> by definition we will not let snap refer to other snaps by name
<zyga> I think snapctl driven requests could easily be remapped
<mborzecki> hmm if there's no chance they'd attempt to refer to other snap by name, then we can do it
<pedronis> mborzecki: we really don't want snap to talk about other snap by name,  default-provider are the only exception, for sure not at runtime
<pedronis> anyway I fear that the all set of service commands were a bit under thought out, as we know
<pedronis> anyway it's fine to suggest a workaround, I don't see us jumping on changing this now either
<mborzecki> i can put it my todo queue and take a look after gadget updates
<pedronis> mborzecki: ok, maybe,  let's discuss when we get there
<mborzecki> pedronis: sgtm :)
<mborzecki> zyga: can you take a look at #6874 later on?
<pedronis> pstolowski: hi, do you have something blocked on me?  what's the status of auto snapshot docs?
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
<zyga> mborzecki: will do
<mborzecki> zyga: pinged jdstrand and pedronis for reviews on this one too
<pstolowski> pedronis: hi, not really, you can take a look at the snap remove --purge PR, but it's not blocking antyhing. i've send the auto snapshot doc change to degville a few days ago
<degville> pstolowski / pedronis: morning! I updated the docs with the auto snapshot details pstolowski sent over - on the getting started page, system options page and on the snapshots page.
<pstolowski> degville: i think i forgot to clarify the time duration format ("d" for "days"), or did you sort that out yourself?
<degville> pstolowski: I removed the day example (just used the hours example) until we had some clarification, so it still makes sense.
<pstolowski> degville: k, thanks
<zyga> mborzecki: reviewed
<Chipaca> xnox: i'd like to know more about #1829510
<mup> Bug #1829510: snapd connectivity check did not change fastly cdn <subiquity:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1829510>
<Chipaca> xnox: istm there's more going on and you might've jumped to conclusions somewhere
<mvo> pstolowski: was "Infrastructure to measure subtimings for operations" done for 2.39 or for 2.40 (iirc the later but not quite sure)
<mvo> Chipaca: "snap download and related changes for snapcraft" is done, right? iirc it was 2.39 or is there something missing
<Chipaca> mvo: no not done yet
<mvo> Chipaca: oh, ok
<Chipaca> mvo: it has two parts, one part is done, the other isn't
<mvo> Chipaca: aha, ok - the --output part is missing?
<mup> PR snapd#6877 opened: overlord/configstate: don't panic on invalid configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/6877>
<pstolowski> mvo: let me check that
<Chipaca> mvo: yes
<mvo> Chipaca: ta!
<pstolowski> mvo: yes, timings are 2.40; 2.39 is missing some important commits. and i've one more PR and a bug to fix there too
<mvo> pstolowski: sure thing, thank you!
<mvo> pstolowski: I will update trello
<pstolowski> ty
<zyga> brb
<mvo> Chipaca: do you have a few min for a quick HO on the Snap-Client-User-Agent feature? just need someone to bounce ideas off :)
<Chipaca> mvo: in 5?
<Chipaca> got a bit of context right now
<pedronis> mvo: I suspect  you maybe should leave that to Chipaca at this point, I fear I'll have opinions on details and will drag a bit
<mvo> Chipaca: sure, or in 10 if you prefer
<mvo> pedronis: ok, I hope this won't change to radically from what we have right now up for review
<pedronis> probably not, but we are adding context everywhere, we should try to do it right, given now is in the new cycle work
<mvo> pedronis: do you already have a sense of how to transmit the client-user-agent from a "snap install"? I mean, have you looked at this yet? it seems we need to put it on the download task
<pedronis> have we agreed to need it on download?
<Chipaca> I thought it was only needed in the synchronous part
<Chipaca> i.e. in what we call the info and refresh endpoints
<mvo> pedronis, Chipaca we can do it either way, I think doing it in the task is more realistic but either way will work
<Chipaca> (refresh being what we hit for install/download/refresh)
<mvo> (this is mostly why I wanted to talk :)
<Chipaca> ok
<Chipaca> i'll just finish wrapping up this (more PRs for reviewage) and then will be free for y'awl
<pedronis> we can ask the store what they prefer, not needing it in download would slightly better for us
<mvo> pedronis: ok, I can kick this off and then we can decide based on their reply
<mvo> pedronis: out of curiosity, is your current thinking to add a context to "snapstate.Install" ?
<pedronis> yes
<pedronis> in theory anything that we would like to interrupt should take it
<pedronis> unrelatedly of this precise task
<mvo> pedronis: all right! I think thats all I wanted to know, so no need for further discussion with Chipaca  I think. and its easy to extend to download if we have to
<mvo> pedronis: thank you!
<mup> PR snapd#6878 opened: cmd/snap, etc: add health to 'snap list' and 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/6878>
<Chipaca> mvo: pedronis: ok i'm ready, am i needed?
<pedronis> Chipaca: I don't know
 * Chipaca weeps
<Chipaca> :-p
<mup> PR snapd#6653 closed: tests: try to be a little bit invariant <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6653>
<mvo> Chipaca: I think pedronis already answerd all my questions :)
<mvo> Chipaca: sorry, we can still chat if you want
<Chipaca> mvo: nah :)
<mvo> heh :)
<mvo> thanks degville for updating trello :)
<degville> oh, no problem mvo - sorry I left the card there so long.
<mvo> degville: no worries
<mup> PR snapd#6879 opened: [RFC] overlord: add context.Context to snapstate.Install() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6879>
 * Chipaca takes a break
<mup> PR snapd#6877 closed: overlord/configstate: don't panic on invalid configuration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6877>
<pstolowski> cac:
<pstolowski> ups
<mborzecki> zyga: about nsswitch, it doesn't happen in our spread setup bc it's modified in our image
<zyga> ahhh
<zyga> do you know why it was modified?
<zyga> mborzecki: https://github.com/zyga/mimic-bug offtopic
<zyga> mborzecki: this illustrates the issue I was fighting last week
<mborzecki> zyga: no clue, i don't see anything in our test setup or spread
<zyga> mborzecki: probably the image was "cured"
<zyga> mborzecki: if you have a moment please have a look at bug.sh
<zyga> I would love to have a call and discuss options
<zyga> I feel a bit stuck now :/
<zyga> just need to grab a coffee
<zyga> still overdosed from last week :)
<xnox> Chipaca:  re connectivity check => so snapd found new subiquity snap (visibile with like $ snap info SNAPNAME) but $ snap download SNAPNAME was stalling, ie. zero progress because connectivity to fastly requires proxy.
<xnox> Chipaca:  what logs / details do you need from me? i can try to recreate that network setup and gather things for you.
<zyga> mborzecki: ok
<Chipaca> xnox: but "snap download" and "snap refresh" are very different paths wrt proxies
<Chipaca> xnox: which one was it? because the bug mentions refresh
<xnox> Chipaca:  it was both.
<Chipaca> xnox: and the connectivity check reflects what happens on refresh, not download
<xnox> Chipaca:  both refresh, and download stalling, despite info showing that new stuff is available.
<xnox> Chipaca:  i believe subiqutiy queries snapd's connectivity check before showing the "new installer is available screen"
<zyga> mborzecki: do you have some time for interactive debugging?
<Chipaca> xnox: if you could turn set SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=7 in /etc/environment that might give us an insight into what's going on
<mborzecki> zyga: need ~15 minutes
<zyga> sure
<zyga> thank you!
<xnox> Chipaca:  ack.
<Chipaca> xnox: (snapd would have to restart to pick those up)
<xnox> sure.
<Chipaca> xnox: if the connectivity check is not picking up on the problem, something's wrong and needs fixing
<Chipaca> xnox: otoh i don't know where these things run, maybe cloud-init needs tweaking?
<Chipaca> its configuration i mean
<Chipaca> i honestly don't know
<Chipaca> here's hoping for logs :)
<xnox> well, i care about this in the context of subiquity server live image.... and I know how to hack that to do what I want =) so we are all good.
<xnox> mvo:  vorlon: i still think i want to pre-built correct initrds for all arches, and publish them into the snapstore. Only for the snapcraft kernel plugin to consume them as staging those snaps..... Not for them to be installed on target devices directly.
<xnox> Kind of like "shipping a snapcraft build-dependency as a snap in the store"
<xnox> cause i am being asked for a FDE embedable initrd, for uc16 and uc18 as well as uc20
<zyga> mborzecki: https://meet.google.com/bpg-rxba-igg?ijlm=1558350555676&hs=125&adhoc=1&authuser=0 when ready
<mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
<pedronis> Chipaca: connectivity-check tries a download but yes snap download will use different configs all together atm
<Chipaca> pedronis: yes as i said
<Chipaca> pedronis: but the bug talked about 'refresh', not download, otherwise i would've brought that up earlier
<Chipaca> pedronis: but it turns out connectivity-check works, but neither refresh nor download do
<Chipaca> pedronis: hence, gimme logs
<pedronis> yea, that's unexpected
<Chipaca> lunch is calling
 * Chipaca obeys
<cachio> pstolowski, hey
<pstolowski> cachio: hey! i've been debugging the test issue
<cachio> pstolowski, nice
<cachio> pstolowski, is it a test issue?
<cachio> or is it a problem in the code?
<pstolowski> cachio: so, first of, the test is incorrect
<pstolowski> cachio: after fixing it passed on 16.04
<cachio> nice
<cachio> pstolowski, and on core18?
<pstolowski> cachio: it sill fails on core 18 and i'm trying to find out why. fwtw i've flashed my pi3 with core18 from edge this morning and hotplug worked with real device, so i suspect it is still something with the est
<pstolowski> *test
<cachio> pstolowski, yes, probably, it is the first time we run this test on core
<pstolowski> cachio: also, not sure if you noticed, it's probably not affecting this test directly, but in both cases the "initialize device" change fails repeatedely and is retried
<pstolowski> cachio: https://paste.ubuntu.com/p/YRWth9FdjM/
<pstolowski> cachio: it's device serial to be exact
<cachio> pstolowski, yes
<cachio> I knew that
<pstolowski> ah ok
<cachio> pstolowski, but it shouldn't affect
<pstolowski> cachio: indeed, seems to be irrelevant
<pstolowski> cachio: re core18 test failure i think it's not using the latest versions?
<pstolowski> cachio: https://paste.ubuntu.com/p/67fJ4k8Mvw/
<cachio> pstolowski, snanpd is still on stable
<cachio> could you push the change you did to fix core16?
<pstolowski> cachio: right, that's the issue
<cachio> so then I'll push the fix fot that with other stuff that I also fixed today
<pstolowski> cachio: ok, will do in a while, trying to run everything from this test now
<cachio> pstolowski, nice
<pstolowski> cachio: here is the diff https://pastebin.ubuntu.com/p/c3kMDWhzzM/
<pstolowski> cachio: it passed for me on core16
<cachio> pstolowski, nice, I'll add it to the next commit
<cachio> thanks
<zyga> mborzecki: dziala!
 * zyga goes for lunch
<cachio> pstolowski, so, could you please paste the whole test
<pstolowski> sure
<cachio> thanks
<pstolowski> cachio: https://paste.ubuntu.com/p/mKryYZNtHK/
<cachio> pstolowski, with this change in ubuntu-image I'll create a new PR after this one
<cachio> so, the idea is to pre-generate the image witt the desired core/snapd and avoid the refresh which takes time
<pstolowski> cachio: it's basically the original test from classic, minus the -writing bits for serial port that required dialout to work
<cachio> pstolowski, nice, thanks
<mup> PR snapd#6869 closed: daemon: only allow `users`/`create-users` when not on classic* <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6869>
<pedronis> mborzecki: mvo: I gave my +1 to #6872
<mup> PR #6872: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
<mvo> pedronis: thank you
<mup> PR snapd#6872 closed: many: backport fixes to 2.39 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6872>
<pedronis> pstolowski: degville: auto snapshots docs don't seem to mention that atm they are off by default on core
<mborzecki> off taking the kids to the troop meeting
<degville> pedronis: thanks for checking - that's important - I'll add it now.
<mup> PR snapd#6880 opened: daemon: refactor user ops to api_users <Created by chipaca> <https://github.com/snapcore/snapd/pull/6880>
<Chipaca> pedronis: I addressed the concerned you'd raised in #6564 fwiw (other than two that're better left for a later pr)
<mup> PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564>
<pstolowski> pedronis, degville to clarify - no snapshots for core snaps are created, only for app snaps; yes
<pedronis> pstolowski: ?
<degville> pstolowski: thank you!
<pedronis> degville: pstolowski: I think we are talking about different things
<pedronis> degville: pstolowski: I'm talking about this: https://github.com/snapcore/snapd/blob/master/overlord/snapshotstate/snapshotstate.go#L103
<degville> pedronis/pstolowski: I'll mention both cases.
<pedronis> on core we default to no
<pstolowski> pedronis: ah, this landed while i was away beginning of May. i see, makes sense, thanks
<pedronis> pstolowski: likely, we did this to be more conservative with disk space on core
 * cachio lunch
<pedronis> pstolowski: Chipaca: I did a pass on #6870
<mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
<pstolowski> pedronis: ty
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<cachio> pstolowski|afk, hey, I pushed the hotplug test working on both cores
<cachio> pstolowski|afk, in a following PR I'll add the new improvemente to avoid test code duplication
<cachio> pstolowski|afk, but I prefer keep it as it is to simplify the change and start running this new change as part of the nightly suite
<mup> PR snapd#6618 closed: tests: validates snapd from ppa <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
 * cachio afk
<mup> PR snapd#6874 closed: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6874>
#snappy 2019-05-21
<mup> Issue core18#128 opened: Having issues installing core18 <Created by D3faIt> <https://github.com/snapcore/core18/issue/128>
<mup> Issue core18#128 closed: Having issues installing core18 <Created by D3faIt> <Closed by D3faIt> <https://github.com/snapcore/core18/issue/128>
<zyga> Hello
<mborzecki> morning
<zyga> hey mborzecki
 * zyga tries to wrap up propagation bug
<mborzecki> zyga: hey
<zyga> tests now pass, I'm still adding some more checks though
<zyga> and I have a lot of unit tests to adjust for extra calls
<mborzecki> zyga: i poked a bit around /etc/nsswitch.conf on fedora, vanilla 29 image starts with a symlink, but after dnf upgrade /etc/nsswitch.conf becomes a file, probably some scriptlet broke it
<zyga> mborzecki: ah, I wonder if it's a design or bug
<zyga> mborzecki: perhaps worth reporting a bug to ask the question
<mborzecki> zyga: looks like a bug/issue about authselect which is not installed in cloud images, so never gets to run and update nsswitch.conf to be a symlink
<mborzecki> zyga: found this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/G564T2VXADHS557BOT5L5K42SSF4QSIE/ and https://bugzilla.redhat.com/show_bug.cgi?id=1622272#c8
<mborzecki> looks like some monkey business to me
<zyga> yeah
<mborzecki> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P/
<mborzecki> meh, installed authselect, ran authselect select --force sssd and it errors out :/
<mborzecki> nvm, looks like this is fixed in f30, f29 will eol in a couple of months anyway
<zyga> yeah, at least that's good
<zyga> thanks for chasing this
 * zyga writes docs for test tool helper
<mborzecki> one more tweak for selinux policy for f30
<mborzecki> guess i'll never stop finding search on dir class confusing :/
<zyga> mborzecki: you should do talks on selinux
<mborzecki> zyga: i'm far from competent in this
<zyga> breakfast
<pstolowski> mornings
<zyga> hey pawel
<mup> PR snapd#6881 opened: data/selinux: allow snap-confine to do search on snappy_var_t directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6881>
<mborzecki> pstolowski: hey
<zyga> mborzecki: last bit in this tool is renumbering for deterministic test
<zyga> mborzecki: some heavy lifting from that old tool
<zyga> ok, I think the tool is ready now
<zyga> mborzecki: mountinfo-tool https://www.irccloud.com/pastebin/N5yQNZPX/
<mup> PR snapd#6803 closed: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6803>
<mup> PR snapd#6703 closed: tests: add deferred actions <â Blocked> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6703>
<Chipaca> bongiorno, principesse e principi!
 * Chipaca wonders if italian has "inclusive language" for plurals
<mvo> hey Chipaca
<Chipaca> mvo: 'sup
<pedronis> mborzecki: #6874 was merged but at least jdstrand should have looked at it
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6874>
<pedronis> mvo: ^
<mborzecki> pedronis: looks like cachio merged it yesterday, i'll ping jdstrand to have a look still
<mvo> pedronis: good morning! I was looking over the spike trello cards this morning
<mvo> pedronis: yeah, we need to ask jamie to double check it
<mvo> pedronis: and tried to flesh things out a little bit
<pedronis> mvo: maybe we need to tell cachio not to merge snap-confine/snap-update-ns stuff
<mvo> pedronis: while doing so I was stumbling on snap-verify and poked around a bit, it seems like we need something like assertstate.Batch just without the ties to the state, does that sound right? or do you have something else in mind for that?
<mvo> pedronis: yeah, I think that is a good idea
<mborzecki> my bad, should have added a blocked label or sth
<pedronis> it's a judgement call, just don't think he is worth having everybody be able to do that
<pedronis> mvo: yes, Batch could be useful, it depends what the api is though
<mvo> pedronis: yeah, it requires refactor because assertstate only exposes a RODatabase so we have to have a custom save function at least. anyway, I can poke around a bit but if you have a firm plan already I can also leave it alone, it seems nice and tracktable though :)
<pedronis> mvo: please leave it alone,  I don't think is a good use of your time, and a script that does exit 0 should unblock you
<mvo> pedronis: heh, I can do that
<pedronis> mvo: yes, Batch is in assertstate, I don't think we need that, a Fetcher is enough
<pedronis> but anyway
<mvo> ok
<pedronis> mvo: I think we need to understand what we should verify, before writing the tool
<pedronis> with relates more to the rest of the initramfs
<pedronis> s/with/which/
 * mvo nods
<pedronis> mvo: my biggest worry is that we will need to verify the kernel also on the run path
<pedronis> I mean worry related to the tool
<mvo> pedronis: verify the running kernel?
<pedronis> maybe
<pedronis> maybe not, we need to think
<mvo> pedronis: hm, interessting. you need to tell me more when we have high bandwidth time in a HO
 * zyga -> quick coffee
<mup> PR snapd#6882 opened: cmd: add snap-verify stub binary (UC20) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6882>
<Chipaca> pedronis: where is this meeting?
<pedronis> Chipaca: added a HO now
<Chipaca> pedronis: https://forum.snapcraft.io/t/downloading-snaps-via-snapd/11449
<Chipaca> pedronis: maybe point igor at that (dunno his nick)
<zyga> mvo: reviewed 6882
<mvo> ta
<zyga> ok, *really* time for that coffee
<mborzecki> pstolowski: can you take a quick look at https://github.com/snapcore/snapd/pull/6881 ?
<mup> PR #6881: data/selinux: allow snap-confine to do search on snappy_var_t directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6881>
<mup> PR snapd#6881 closed: data/selinux: allow snap-confine to do search on snappy_var_t directories <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6881>
<mborzecki> pstolowski: thanks!
<pstolowski> np
<cachio> pstolowski, hey, #6859 is ready I think
<mup> PR #6859: tests: new hotplug test executed on ubuntu core  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6859>
<cachio> pstolowski, hold on, I just read the comments you did
<pstolowski> cachio: great! does it pass on both cores?
 * zyga runs spread for propagation test!
<zyga> (so so so close now)
<cachio> pstolowski, yes
<pstolowski> cachio: awesome! thank you
<cachio> pstolowski, for a following PR I'll reuse the tests parts
<cachio> pstolowski, but I would keep it working first so then I can work on sharing test code
<pstolowski> cachio: yes, sounds good, let's land it and do a followup
<cachio> between tets
<cachio> pstolowski, nice
<pstolowski> cachio: i'll take a look today
<ackk> hi, is there any way to have snapcraft pull in a deb from a specific URL as stage-packages ?
<ackk> (or have it pulled from a repo)
<Chipaca> pedronis: my changes to the 'snap info' will probably conflict with the pr that depends on it (that i'd made to depend to avoid conflicts.... augh) but i think it's a lot nicer now
<sergiusens> morning, question about 2.39, when is it out?
<pedronis> sergiusens: should go out today , cc mvo
<mvo> pedronis, sergiusens correct
 * zyga afk for errand 
<pedronis> Chipaca: #6816 needs master merged, and has some conflicts right now
<mup> PR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
<Chipaca> pedronis: will do
 * Chipaca finishing lunch
<pedronis> thx
<zyga> re
<pedronis> not sure, don't know what they scheduled over the standup
<zyga> mborzecki: snapd tests now pass :-)
<zyga> mborzecki: also in spread
<zyga> I will run them on more systems and start to trim crap out of that branch for proposal
<mup> Issue core18#129 opened: Multiarch isn't working <Created by xordspar0> <https://github.com/snapcore/core18/issue/129>
<pedronis> Chipaca: did a pass over #6564
<mup> PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564>
<Chipaca> pedronis: thx
<zyga> is the standup over?
<mborzecki> zyga: yes
<zyga> ok
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#122, core18#126, core18#127
<mup> PR snapd#6867 closed: gadget: offset-write: fix validation, calculate absolute position <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6867>
 * zyga lunch break
<zyga> starving!
<zyga> mborzecki: lol, the branch has fixed one known test that just shows how layouts are broken in one case :)
<cachio> mborzecki, m
<cachio> https://travis-ci.org/snapcore/snapd/jobs/535240901
<cachio> thanks for the help on that one
<mborzecki> cachio: yay!
<mborzecki> cachio: land it while it's green :)
<cachio> mborzecki, done
<mup> PR snapd#6860 closed: tests: running tests on fedora 30 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>
<mvo> kenvandine: I updated bug 1825883 - its in 2.39
<mup> Bug #1825883: stale copy of plug and slot attributes is kept in connection state <snapd:In Progress by zyga> <https://launchpad.net/bugs/1825883>
<kenvandine> mvo: great, thanks!
<pedronis> Chipaca: oops, I was almost forgetting, this is my PR that changes the signatures of the users methods: https://github.com/snapcore/snapd/pull/6834
<mup> PR #6834: daemon: pass the model to the create known user helpers (instead of full Overlord) <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6834>
<pedronis> Chipaca: as I said maybe it's easier if you just incorporate that change in the refactor
<pedronis> your are doing
<Chipaca> looks like it :-|
<Chipaca> need to wrap up the info one :)
<mup> PR snapcraft#2568 opened: docs: consolidate on a simple HACKING.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2568>
<pedronis> Chipaca: no hurry, it's orthogonal to my other open PRs, I'm not blocked on it (I think)
<zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga> hmmm
<zyga> mvo: found a small bug in core18
<zyga> mvo: there's no profile for /usr/lib/snapd/snap-confine
<zyga> look at this plese
<zyga> *please
<zyga> https://www.irccloud.com/pastebin/MnHLkuvk/
<zyga> I think we don't notice because spread tests run as root
<mvo> zyga: ok, after the meeting (we have now)
<zyga> oh
<zyga> joining
<pedronis> that should be written by snapd, no?
<pedronis> it shouldn't be in the core18 itself
<mup> PR snapd#6859 closed: tests: new hotplug test executed on ubuntu core  <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6859>
 * cachio lunch
<pstolowski> cachio: i've merged your nested tests PR
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697,
<mup> snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6816, snapd#6825, snapd#6834, snapd#6835,
<mup> snapd#6836, snapd#6838, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6870, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6880, snapd#6882
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6108, snapd#6258, snapd#6325, snapd#6327, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6541, snapd#6564, snapd#6588, snapd#6648, snapd#6666, snapd#6680, snapd#6681, snapd#6691, snapd#6695, snapd#6697,
<mup> snapd#6705, snapd#6708, snapd#6714, snapd#6721, snapd#6734, snapd#6750, snapd#6759, snapd#6760, snapd#6767, snapd#6804, snapd#6805, snapd#6816, snapd#6825, snapd#6834, snapd#6835,
<mup> snapd#6836, snapd#6838, snapd#6839, snapd#6841, snapd#6848, snapd#6855, snapd#6870, snapd#6871, snapd#6875, snapd#6876, snapd#6878, snapd#6879, snapd#6880, snapd#6882
<pstolowski> pedronis_: your suggestion re RemoveFlags & flags.go on https://github.com/snapcore/snapd/pull/6870 was to simply move RemoveFlags there (or to extend Flags and not introduce RemoveFlags)?
<mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
<pstolowski> degville: hey, any thoughts on https://github.com/snapcore/snapd/pull/6870#discussion_r285659028 ?
<mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
<pedronis> pstolowski: to move it there, but as I said I would like Chipaca's input on some of my remarks
<pstolowski> ack
<pedronis> Chipaca: I asked your 2nd opinion on a couple of things in #6870 from pstolowski
<mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
 * Chipaca looks
<degville> pstolowski: looking...
<pedronis> Chipaca: made a small comment about the building of infoWriter discussion in 6564
<Chipaca> hah, degville just snuck in as i was writing it :-D
<Chipaca> degville: wdyt of the 'save' comment (now sitting below yours)?
<degville> Chipaca: It's a really good point. I think you're right.
<degville> (about saving. I like the idea of using consistent verbs too).
<pstolowski> Chipaca, degville thanks for comments; Chipaca, are you suggesting to simply reuse Flags (rather than just move RemoveFlags?)
<Chipaca> pstolowski: yes
<pstolowski> k
<Chipaca> pstolowski: dunno if pedronis agrees tho :-)
<pedronis> Chipaca: pstolowski: I don't
<pedronis> what other flags do they share?
<pedronis> if it needed to go into SnapSetup there would be a point, but that's not the case afaiu
<pstolowski> none. Flags seems to install related
<Chipaca> instlal/refresh/etc
<Chipaca> I don't mind if it's separate :)
<Chipaca> (there is ForSnapSetup that zeros out unwanted flags for snap setup fwiw)
<pedronis> I know
<pedronis> though is often forgotten
<Chipaca> yes :-|
<pedronis> pstolowski: my feeling right now is to keep it but move close to the function
<pedronis> right now is miles away
<pedronis> afair
<pstolowski> pedronis: done
<pedronis> pstolowski: thx
<Chipaca> hah, finding bugs by writing tests
<Chipaca> a novel endeavour
<pedronis> Chipaca: where? :)
<Chipaca> pedronis: maybePrintStandaloneVersion
<Chipaca> when no version in the snap file
<Chipaca> would produce bad yaml
<pedronis> ah
<Chipaca> not an easy path to hit as a versionless snap is invalid
<Chipaca> but, hey :)
<pedronis> :)
<pedronis> robustness in depth
<pedronis> or something
<mvo> pedronis, cmatsuoka, zyga I updated the gadget PR with most^Wsome^Wmost(?) things we discussed
<zyga> mvo: ack, thank you!
<Chipaca> pedronis: so many unit tests it's almost embarrassing
 * Chipaca EODs
<Chipaca> mvo: silly and low priority reminder about sprint approvals (just so they don't pile up on you :-p)
 * Chipaca again pretends to EOD
<mup> Issue core18#129 closed: Multiarch isn't working <Created by xordspar0> <Closed by xordspar0> <https://github.com/snapcore/core18/issue/129>
<mup> PR snapd#6883 opened: tests: fix how strings are matched on auto-refresh-retry test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6883>
 * zyga is back home :-)
<zyga> tomorrow morning will be busy :)
<mup> PR snapd#6870 closed: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6870>
 * cachio afk
<mup> PR snapcraft#2569 opened: lifecycle: warn about bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2569>
#snappy 2019-05-22
<zyga> Hi
<mborzecki> morning
<mup> PR snapd#6884 opened: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> mborzecki: I've opened a draft PR above
<zyga> and I'm rushing to the car to take Iza to the new school
<zyga> ttyls :)
<mborzecki> zyga: ok, i'll take a look
<zyga> I'll get rid of other bits from that branch
<zyga> namely defer patches
<zyga> and various other changes that can be broken out
<zyga> the essence of the main thing is there
<zyga> I'm not 100% sure about one part though
<zyga> https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R94
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> I need to make the test more clear so that the relationship (peer groups) is clearly visible
<zyga> mborzecki: the mountinfo-tool program can probably land in tests/lib somewhere
<zyga> On my way to the new school now
<zyga> mborzecki: darn, I committed the broken version that was going to work on older python
<zyga> Well, letâs fix that
<mborzecki> btw. totally forgot about the draft PRs, maybe should open one for all of gadget update code
<zyga> yeah!
<zyga> force pushed
<zyga> some weird gnome bug
<zyga> with x11 I have no desktop background
<zyga> with wayland I do but lots of other things are broken
<zyga> some error messages about using freed object in gnome shell
<zyga> eh
<zyga> Daughter is now at the new school
<zyga> Apart from the fact that we cannot leave because someone parked next to our car all is good
<zyga> mborzecki: trivial https://github.com/snapcore/snapd/pull/6885
<mup> PR #6885: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>
<mup> PR snapd#6885 opened: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6885>
<zyga> hey pedronis
<mvo> hey zyga, pedronis and mborzecki
<zyga> hey mvo, didn't see  you join earlier
<mvo> zyga: no worries, reading PRs and reporting bugs :)
<zyga> how are you doing? I have a very eventful day but I'm hoping to make progress
<mborzecki> pedronis: mvo: hey
<mborzecki> zyga: +1 on the PR, i think we had a note about that somewhere earlier in s-c code
<zyga> oh, I'll check
<zyga> thanks!
<pstolowski> morning
<zyga> good morning pawel
<zyga> mborzecki: one more similar change: https://github.com/snapcore/snapd/pull/6886  -- I'm shaving the main branch to have other tweaks separate so that they don't cloud the non-trivial review of the main part
<mup> PR #6886: cmd/snap-update-ns: use "none" for propagation changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>
<mup> PR snapd#6886 opened: cmd/snap-update-ns: use "none" for propagation changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6886>
<mvo> zyga: we have this mount propagation bug that we want in 2.39.1, right? I'm looking into doing 2.39.1 soon(ish) and just wanted to check whats missing
<zyga> mvo: yes, I'm shaving the branch for that now, there's a draft PR with some cruft still
<zyga> mvo: and one test that I mentioned yesterday that fails in the restore phase (fuse mounts, so related)
<mvo> ok
<zyga> mvo: the essence of the fix is https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> (though as I said the diff will still shrink slightly)
<mvo> zyga: woah, thats big - reading
<zyga> mvo: it's not *that* big, mostly verbose diff in test changes
<zyga> mvo: the non-test code changes are tiny
<mvo> zyga: yeah, lots of test changes
<zyga> mvo: the essence of the idea builds from ...
<zyga> https://github.com/zyga/mimic-bug/blob/master/bug.sh
<zyga> mvo: what we were missing is MS_SHARED so that ns:snap events  propagate to ns:user
 * mvo nods
<zyga> mvo: interestingly, due to inheritance of sharing flags, bulk of the changes are in snap-confine bootstrap
<zyga> mvo: the only other changes are to mimic construction code:
<zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-4480ffd44957efa3395867c929f88014R488
<zyga> here
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> literally one line :)
<zyga> mvo: the change makes the stash used during mimic construction private
<zyga> because due to the sharing that is now everywhere, events made during mimic construction would clobber it, this essentially makes the mimic behave as  it did before sharing was added on the outer layer
<zyga> mvo: on top  of this I wrote a tool like findmnt
<zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-427083700c87c7cd79d1ac50787fab0fR1
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> it's just a think wrapper around mountinfo
<zyga> but has two properties: it shows propagation flags better than findmnt
<zyga> and it has good renumbering features so that it works well in tests
<zyga> it's also great for interactive use
<zyga> using that tool I crafted some new tests
<zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-f54c331654290afe84ce29593d97a871R70
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> that check how things behave with content initially connected, initially disconnected and finally connected then disconnected and reconnected
<zyga> there's a smilar one for layout
<zyga> and I will still replicate that for parallel instances
<zyga> there's a chance parallel instances are still broken because the failure I observed is exactly in that scenario
<zyga> I wrote the test in defer style because it was way faster
<mvo> zyga: ok
<zyga> but I will remove defer from this patch
<zyga> so that it can land  separately
<zyga> mvo: one interesting thing is this existing test
<zyga> https://github.com/snapcore/snapd/pull/6884/commits/1580166e987d9b343b8b9e609e6bc2abbf65eb07#diff-a6e200ddb24754df8611a002020deccdR1
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> that used to be broken and is now fixed
<zyga> it essentially captures the fact that layouts *can* correctly change from revision to revision, now, with this fix
<zyga> mvo: it needs careful review
<zyga> and anyone doing so needs to readhttps://lwn.net/Articles/159077/ and https://lwn.net/Articles/159092/
<mvo> zyga: maybe worth linking to that in the PR description(?)
<mvo> zyga: thank you for the link!
<zyga> mvo: great idea, I will do so
<mvo> ta
<mup> PR pc-amd64-gadget#15 opened: add .travis.yml to enable basic smoke testing <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/15>
<mup> PR pc-amd64-gadget#16 opened: add .travis.yml to enable basic smoke testing (18) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/16>
<mup> PR pc-amd64-gadget#17 opened: add .travis.yml to enable basic smoke testing (20) <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/17>
 * zyga is back home
<mup> PR snapd#6885 closed: cmd/snap-confine: don't pass MS_SLAVE along with MS_BIND <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6885>
<Chipaca> pedronis: https://gopenpgp.org/ !
<pedronis> Chipaca: bookmarked
<pedronis> Chipaca: does my answer in the download topic makes sense?
<popey_> zyga: is there a bug open for content snaps not being connected sometimes, causing apps to fail?
<popey_> zyga: I suspect this kde calc bug is a snapd bug https://bugs.kde.org/show_bug.cgi?id=407234
<zyga> popey_: perhaps many
<popey_> zyga: as it can't find libqtcore which is in the kde frameworks snap
<zyga> yeah
<zyga> this is all coming together in https://github.com/snapcore/snapd/pull/6884
<zyga> it will be in 2.39.1
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> just shaving the yak so that it can land
<zyga> it fixes a bug where connect/disconnect would be broken for desktop apps
<popey_> thanks
<zyga> popey_: that was one tricky bug
<zyga> popey_: sorry for taking so long to nail it
<popey_> I can only imagine!
<popey_> np, glad it's on the radar
<zyga> popey_: reading the test here https://github.com/snapcore/snapd/pull/6884/files#diff-f54c331654290afe84ce29593d97a871R50 should show you what is ensured to work correctly now
<mup> PR #6884: WIP LP:#1828354 <Created by zyga> <https://github.com/snapcore/snapd/pull/6884>
<zyga> the key is that this test runs both as root and as non-root user
<zyga> that's where the bug has been mostly lurking
<zyga> root users are OK
<zyga> ironically all our tests run as root by default
<popey_> hah!
<pedronis> ironically wouldn't be the word I use
<popey_> There are many adjectives that could be used here. But we're a family friendly channel ;)
<pedronis> I always thought it was just problems waiting to happen
<mvo> mborzecki: silly question - do we use the ":role" yaml property in any of our gadgets? just looking at ubuntu-image
<pedronis> though is convenient
<zyga> pedronis: I agree
<zyga> pedronis: when I was coding this test I ran it locally as user and coded most of the test to use sudo
<mborzecki> mvo: we should be, type: mbr is supposed to be legacy, we ought to have role: mbr there instead
<zyga> pedronis: I think I would not stumble onto that part of the problem otherwise
<Chipaca> pedronis: yes indeed
<mvo> mborzecki: aha, I see - I have not seen role: system-boot/system-data in the wild I think(?)
<mvo> mborzecki: we probably need system-recovery here in the future :)
<mborzecki> mvo: neither did i
<mborzecki> mvo: we can add a new role
<mvo> mborzecki: maybe a case of YAGNI? anyway
<mborzecki> mvo: system-recovery fwiw
 * mvo adds a note to the trello
<mborzecki> mvo: probably better to have a new role in case there's actually someone using system-{boot,data}
<mborzecki> mvo: oh, and system-data may be used implicitly when a rootfs paritition is added automatically
<mvo> mborzecki: yeah, given that its already docuemtned and used in the wild I think you are right
<mvo> mborzecki: yeah, I need to look at this and make it not-automatic but maybe not for v0
 * mvo adds it to trello
<mborzecki> mvo: i should be albe to dump the whole gadget update branch as a draft work-in-progress pr, it includes the tool for building images
<mvo> sergiusens silly question - running snapcraft in travis now blocks with "Support for 'LXD' needs to be set up. Would you like to do that [y/N]" - do you have an example for a .travis.yml with snapcraft3/base: core18 that just builds the snap ? (or maybe popey knows?)
<popey_> Oh, maybe I do. I'll see if I can find one
<mvo> mborzecki: nice, yeah, I may be able to get away with a hack - marking the system-recovery partition with role: system-data so ubuntu-image will not create writable and will also put the files into the right place on disk
<mvo> mborzecki: its a bit of a fugly hack but maybe enough to get me one step further
<mvo> popey_: that would be lovely
<mup> PR snapcraft#2570 opened: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>
<Chipaca> pedronis: I'll be working on the users as soon as i've deconflicted the cohort refresh one
<pedronis> Chipaca: sounds good
<albertosottile> pedronis sorry to bother you, I saw that you found some time to address the pending forum tags... could you give a look at our request too? https://forum.snapcraft.io/t/classic-confinement-request-syncplay/11189/5 Thanks
<zyga> mvo: https://github.com/snapcore/snapcraft/pull/2570/files#r286389212
<mup> PR snapcraft#2570: cli: do not prompt when there is no tty available on stdin <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2570>
<mvo> zyga: thank you!
<zyga> mvo: socket activation when daemon goes off doesn't work; systemd stops snapd.socket too
<zyga> (totally offtopic)
<Chipaca> pedronis: in the cohort refresh pr I added an UpdateOptions struct
<Chipaca> pedronis: should device ctx be part of that?
<zyga> mvo: the test squashfs we mount on snapd startup briefly flashes in unity launcher, I think we are missing the mount option that makes the launcher ignore it
<Chipaca> pedronis: or is it being separate (like userID is separate) better?
<mvo> zyga: oh? meh, that will need some investigation then
<Chipaca> x-nothing-to-see-here
<cjwatson> Chipaca: Re your code import question on #launchpad, LP staff can edit existing code imports
<Chipaca> cjwatson: hi :) i think i probably broke something, or don't understand how any of it works as the whole ppa vanished now afaict
<cjwatson> ... PPA?
<cjwatson> you mean import?
<Chipaca> there was a ppa and a recipe and an import
<Chipaca> the import was failing, the recipe wasn't reciping and the ppa was stale
<Chipaca> but the gnu parallel people reply to "where's instructions for ubuntu" with "john lenton has a ppa"
<cjwatson> Changing a code import will not delete a PPA under any circumstances
<Chipaca> so i thought rather than try to convince gnu people that they're being bottom sombreros, i'd get it working again, but i probably broke something along the way
<Chipaca> cjwatson: never underestimate the power of a sleepy chipaca
<cjwatson> Right, *you* might :)(
<cjwatson> :)
<cjwatson> https://code.launchpad.net/~chipaca/parallel/+git/parallel looks promising now though
<Chipaca> yep yep
<Chipaca> cjwatson: that's a new one i made last night (trying to import the same thing to bzr failed with a credentials error?)
<Chipaca> something about the host name not matching the cert
<Chipaca> anyway
<Chipaca> cjwatson: I'll pick this up again on the weekend, there is no real urgency to it
<cjwatson> Chipaca: power tip: if you're quick then you might be able to use https://staging.launchpad.net/~chipaca as a reference for resurrecting deleted config, since staging is only restored from production weekly
<Chipaca> cjwatson: I do appreciate you reaching out though :)
<cjwatson> Chipaca: but you will need to do that before the weekend as it will vanish early on Saturday
<Chipaca> cjwatson: ack. I guess it's material for tonight then :) thanks!
<Chipaca> - Run install hook of "fwupd" snap if present (run hook "install": install: cannot create regular file '/usr/share/polkit-1/rules.d/org.freedesktop.fwupd.rules': No such file or directory)
<mup> PR snapd#6887 opened: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>
<zyga> mborzecki: one more bit of yak shave https://github.com/snapcore/snapd/pull/6887
<mup> PR #6887: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6887>
<mup> Bug #1829558 changed: Unable to install fwupd <Snappy:Invalid> <https://launchpad.net/bugs/1829558>
<pedronis> Chipaca: no, it should be kept separate, it might also be that once we pass context.Context everywhere we might need to use it less deeply, but we will see.
<Chipaca> ok
<mup> PR snapd#6886 closed: cmd/snap-update-ns: use "none" for propagation changes <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6886>
<zyga> Thanks!
<mup> PR snapd#6888 opened: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<zyga> pstolowski: is snap unset implemented now?
<pstolowski> zyga Im just about to propose it in a series of PRs
<zyga> great, looking forward to use it :)
<zyga> brb for quick coffee
<cachio> mvo, hey
 * zyga had a great idea
<zyga> brb
<zyga> re
<zyga> we live in interesting times for sure: https://www.bbc.com/news/technology-48363772
<Chipaca> sigh
<Chipaca> we have a test that waits for a condition in a limited loop, and then checks for the condition on exit
<Chipaca> which sounds fine and correct
<Chipaca> except those two conditions? not the same one
<Chipaca> so guess what :)
<popey_> i have a system where core18 won't install. It fails at the mount step. What info do I need to get from it?
<mborzecki>  5 files changed, 2256 insertions(+)  <-- guess nobody will the code now :(
<mborzecki> at least that 1639 lines are tests
 * zyga is happy about this: >
<zyga> mountinfo-tool on core18 :) https://www.irccloud.com/pastebin/J8uVY9P4/
<mup> PR snapd#6889 opened: tests/main/auto-refresh-retry: fix loop/break condition <Created by chipaca> <https://github.com/snapcore/snapd/pull/6889>
<Chipaca> popey_: depends :)
<Chipaca> popey_: _how_ does it fail at the mount step?
<popey_> https://forum.snapcraft.io/t/core18-fails-to-install-mount/11472
<popey_> yes
<mup> PR snapd#6890 opened: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>
<Chipaca> popey_: anything interesting about this system? is it running /var off nfs from a server in antartica, for example?
<popey_> nope, it's an hp microserver in my house
<popey_> it has a few snaps installed
<popey_> huh, I can't even remove snaps either
<Chipaca> hmm
<Chipaca> popey_: what does dmesg say?
<Chipaca> sounds like something nasssty
<popey_> nothing out of the ordinary
<Chipaca> popey_: what does it say when you try to remove a snap? also a timeout from mount?
<popey_> yeah, added to the forum post
<popey_> repeatedly
<popey_> (every 3 mins)
<Chipaca> hmmm
<Chipaca> popey_: ^C should abort that cleanly fwiw
<Chipaca> zyga: want to have fun? ^
<zyga> Chipaca: I always want to have fun
<Chipaca> ikr
<Chipaca> meanwhile I'll go have lunch instead
<zyga> popey_: can you look at dmesg to see any suspicious kernel messages?
<popey_> I'm tailing it and see nothing out of the ordinary, just a bunch of the usual apparmor stuff
<zyga> popey_: when something survives SIGKILL it is either 1) kernel recycled processes and systemd is confused or 2) the process is in an uninterruptible part of the kernel and cannot be killed
<zyga> popey_: run top, any process with "D" state?
<popey_> hmm, yes
<popey_> might be io blocked
<pedronis> Chipaca: did another pass on 6564, thanks for the work there, fear a couple more nitpicks though
<Chipaca> pedronis: :'( but also agreed with you
<Chipaca> pedronis: fwiw #6816 is defonclicted and green
 * Chipaca tries to actually go have lunch
<mup> PR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
<pedronis> Chipaca: yes, next on my list
<pedronis> thank you
<mvo> hey cachio !
<mvo> cachio: thanks for the update on the stable core release!
<mvo> cachio: all makes sense now :)
<mup> PR snapd#6887 closed: cmd/snap-confine: combine sc_make_slave_mount_ns into caller <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6887>
<cachio> mvo, hey
<cachio> mvo, yesterday we were waiting until last hour to do the promotion but finally we couldnt
<zyga> mvo: thank you
<cachio> mvo, do you prefer to make it after the stand up? or now?
<mvo> cachio: either way is fine
<mvo> cachio: now is ok
<popey_> zyga: Chipaca a reboot """fixed""" it ;)
<popey_> sorry for the noise
<Chipaca> pedronis: cachio: oops, yes 6889 and 6883 address the same issue
<cachio> Chipaca, :)
<Chipaca> cachio: what does the 'ip netns delete testns' accomplish?
<Chipaca> cachio: wondering whether i should merge yours into mine or viceversa :)
<cachio> Chipaca, if you execute twice the same test, the "ip netns add testns" fails
<cachio> because it is not deleted during the restore
<Chipaca> cachio: ah
<cachio> the test was leaving the namespace created
<Chipaca> cachio: wrt your fix for the loop thing, i like mine more because it uses a variable for the string (no dupe string), and doesn't print out the failure in a loop
<Chipaca> cachio: but yours has more fixes than just that
<Chipaca> cachio: i'll close mine
<cachio> Chipaca, nice, thanks :)
<mup> PR snapd#6889 closed: tests/main/auto-refresh-retry: fix loop/break condition <Simple ð> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6889>
<pedronis> Chipaca: commented on #6816, I think we need to agree on the func signatures/Options
<mup> PR #6816: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <https://github.com/snapcore/snapd/pull/6816>
<Chipaca> pedronis: the way i split it, UpdateOptions had everything that was about the update, whereas outside were things about how/where the update run (so state, user id, context would be outside of options, but name and flags would be inside)
<Chipaca> pedronis: not sure what the rationale would be to split out name and flags
<pedronis> Chipaca: because you can craft an options and use it with many names, we don't support it or want but in theory you could pass it in UpdateMany as well
<pedronis> Chipaca: about flags, it's already a struct. I don't think the goal is to have functions that take one struct. The goal is to bundle things reasonably
<pedronis> Chipaca: anyway my strong opinion at the moment is about name and the order of userID
<pedronis> Chipaca: st, name, options, userID, flags  seems a decent signature from where we stand atm
<Chipaca> pedronis: and device context?
<pedronis> yes
<Chipaca> pedronis: at the end?
<pedronis> there are different functions taking that
<pedronis> yes, at the end
<Chipaca> I could just do like I did in install, and multiply the functions
<Chipaca> leave the struct for later
<pedronis> that is a problem too, multiple styles
<Chipaca> but when i did install we said yeah do it via options so i did so i now i need to do over
<pedronis> Chipaca: we agree to do options, not exactly how they would look like
<mup> Issue core18#129 opened: Multiarch isn't working <Created by xordspar0> <https://github.com/snapcore/core18/issue/129>
<zyga> mup still has the typo "issues" (good) vs "issue" (broken)
<pedronis> Chipaca: I mean, doing a refactor and a feature in one commit/PR is a risky move
<pedronis> Chipaca: anyway, it's probably personal but this snapstate.Update(st, 0, &snapstate.UpdateOptions{Name: "foo", Channel: "stable"}) looks weird to me
<pedronis> the 0 position, and the name inside
<pedronis> it might also be that I don't feel the name is an option here
<pedronis> is the main thing we act on
<pedronis> being in the struct means you can also swap it around
<pedronis> &snapstate.UpdateOptions{Channel: "stable", Name: "foo"}
<pedronis> again not a clear win to be able to do that
 * zyga watches spread cycles cycle
<pedronis> Chipaca: maybe I'm sounding unreasonable, hope not
<Chipaca> pedronis: it seems arbitrary, but that might be on me
<pedronis> Chipaca: maybe your reference point it the store methods, SnapInfo / Find
<pedronis> not a fan of them, but they are fairly different, in terms of what they take or not
<Chipaca> both of these seem to be trying hard not to be SomeOperation{ the stuff it needs }.Do()
 * Chipaca hides
<Chipaca> maybe go needs named arguments a la python
 * Chipaca hides even more
<pedronis> Chipaca: maybe it does
<mvo> pedronis, Chipaca standup :) ?
<Chipaca> ops
<Chipaca> yes
<pedronis> Chipaca: but I invite to consider the differences between name for Update vs Query in Find
<mborzecki> zyga: standup?
<pedronis> Chipaca: also notice that at the moment SnapSpec is just Name
<zyga> sorry, joining
<pedronis> which is funny
<pedronis> in its own way
<pedronis> Chipaca: so maybe it merits the reverse treatment at some point
<mup> Bug #1830051 opened: Fails to recognize UTF-8 locale <Snappy:New> <https://launchpad.net/bugs/1830051>
<mup> Bug #1830052 opened: Ellipsis printed in UTF-8 regardless of locale <Snappy:New> <https://launchpad.net/bugs/1830052>
<mborzecki> running ediff on hexl views of partition tables, fun :)
<cachio> mvo, core 2.39 is in stable now
<cachio> mvo, snapd 2.39 also promoted to stable
<mvo> cachio: \o/ thank you!
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<kenvandine> woot
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<cachio> mvo, yaw
<zyga> mvo: core20 kickof URL?
<pedronis> mvo: are we using the same hangout as yesterday?  or something else
<mvo> zyga, pedronis sorry, added a url to the invite now
<mvo> silly me
<sergiusens> pedronis: not to let the conversation on the forum cold (wrt tracks, content interface, stage-snaps), I am not sure what you are asking. Also, I am not +1 nor -1 the request at all.
<mvo> sergiusens: hey, did you see my earlier question about how to run snapcraft 3 in travis ?
<sergiusens> mvo: no, sorry, it is a bit involved and it is what I said we would fix with travis in the coming days but I can give you something that would work today
<mvo> sergiusens: waiting some days is fine
<sergiusens> mvo: by involved, I mean 8 lines instead of 2, something like this works https://github.com/snapcrafters/gimp/blob/use-use-lxd/.travis.yml
<sergiusens> although I would put most of the lxd scaffolding in the `install` stanza for travis instead of `script`
<mvo> sergiusens: thanks! I'm in a meeting right now but have a look once this is over
<mvo> sergiusens: looks very reasonable, thank you!
<mvo> sergiusens: out of curiosity, how will it look soon?
<sergiusens> mvo: travis has a concept of actions and another one I cannot recall the name for now... regardless of that implementation detail, you will be able to say you want to have an environment that is correct for snapcraft and then just call `snapcraft --use-lxd`
<sergiusens> this is one of the work items we have for the Montreal Summit
<sergiusens> mvo: if you tell me where you want to build snaps on travis, I am happy to do a PR and as a side effect of that write up some documentation
<sergiusens> but right right now, I need to go and pickup my kid from school, I will be able to look into it an hour and a bit from now
<mvo> sergiusens: nice,thanks for this update
<mvo> sergiusens I think I know all I need to know
<mup> PR snapd#6884 closed: WIP LP:#1828354 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6884>
<mup> PR snapd#6891 opened: many: make new mount points MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> replaced one WIP branch with one that's much like the real thing
<zyga> mborzecki: hey still around?
 * cachio lunch
<zyga> mborzecki: in case you are https://github.com/snapcore/snapd/pull/6888
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<cmatsuoka> zyga: script fixed, the problem was the cpio format
<pedronis> mvo: pstolowski: this how it works ATM btw just to confirm (that's a snap with a no-op configure): https://pastebin.ubuntu.com/p/YJMd5KDMDZ/
<pstolowski> pedronis: ack, good, ty
<pedronis> Chipaca: +1 to 6564 with a question
<sergiusens> mvo: pedronis is it correct to assume that if I want 2.39 today I need to install core?
<sergiusens> it does seem so in practice
<jdstrand> roadmr: hi! are we to the point of doing git pulls for the review-tools? if so, can you pull 20190522-1231UTC?
<jdstrand> roadmr: I was going to do YYYMMDD but then I realized I sometimes ask you to do a second in the same day, so went out to the minute
<pedronis> mvo: cachio: what's the process for the snapd snap, it has a version like 2.39+git48.g1ae2fb7 for stable
<pedronis> which is not nice
<pedronis> sergiusens: you mean whether it's SRUd? seems not
<sergiusens> pedronis: just connecting the dots... if I move snapcraft to core18 and have an assumes on snapd239 it would not be satisfied until snapd is offered as a snap or the deb SRUed
<sergiusens> if SRUing is in plans, all is good though, there is no urgency, I am just aligning the order of work
<jdstrand> pedronis, ogra: hey, remind me, as the owner of an Ubuntu Core system (ie, *not* the gadget publisher, etc), is it possible for me to adjust the kernel command line? My understanding is 'no'
<pedronis> sergiusens: you probably need mvo for the timings
<cachio> pedronis, mvo defined that but it is following the same format since long time
<cachio> pedronis, I agree on that it is not nice
<cachio> pedronis, I think we never discussed a version pattern for snapd snap, we just did it for core18 snap
<pedronis> I think for stable at least it should be just 2.39 or 2.39.x etc
<pedronis> but sounds we need to talk with mvo
<cachio> pedronis, yes
<sergiusens> pedronis: I suspect your version setting will do the right thing if you go with an annotated tag instead of a normal git tag
<ogra> ARGH !
<ogra> did we just have a core update ?
<ogra> https://imgur.com/a/QgwRKo5
 * ogra knew running his 3D printer on UC16 wasnt a good idea !
<ogra> jdstrand, well, you can surely manually edit the cmdline parameters ...
<jdstrand> ogra: so, I can update grub on a core device? I'm just thinking through sepculative execution and in particular hyperthreading (nosmt)
<jdstrand> ogra: grub in this case since I'm thinking about intel, but more generally it could be armhf/arm64 so uboot/whatever
<ogra> jdstrand, there is a grub.cfg file somewhere in /boot/grub that carries the default cmdline
<mup> PR snapd#6564 closed: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6564>
<ogra> on arm it is usually nside the uboot.env ... which you can edit with the fw_setenv/fw_getenv tools from the shell (only UC16) or from the uboot shell
<ogra> (arm not being the rpi :P ... there it is in /boot/uboot/cmdline.txt)
<jdstrand> I see. so yes, the owner of the device can edit these things if desired. ok, thanks!
<ogra> as long as you have a login or serial access at least
 * jdstrand nods
 * ogra goes and starts over with the printer ... hoping there wont be an emergency point release today :P
 * cachio afk
<mup> PR # closed: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#17
<mup> PR # opened: pc-amd64-gadget#10, pc-amd64-gadget#11, pc-amd64-gadget#14, pc-amd64-gadget#15, pc-amd64-gadget#16, pc-amd64-gadget#17
<kyrofa> jdstrand, zyga we can specify autoconnections in the gadget now, right? Do we have docs for that?
<mup> PR snapd#6834 closed: daemon: pass the model to the create known user helpers (instead of full Overlord) <Remodel :train:> <Created by pedronis> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6834>
<kyrofa> ogra, HAHAHAHAHA
<kyrofa> zyga, that "please don't update me, I'm busy" functionality we've talked about should probably also apply to core updates/reboots ^
<kyrofa> roadmr, you around? Can you confirm that these docs are up to date and good to go for the snap proxy? https://docs.ubuntu.com/snap-store-proxy/en/
<roadmr> kyrofa: I am around but I'm not the best person to confirm that - sparkiegeek, bloodearnest, twom might be better candidates. They're UK timezone so probably asleep now
<jdstrand> kyrofa: we can, yes. there should be docs. I don't know otoh which page it is
<kyrofa> jdstrand, hmm. Not on the gadget page anyway
<roadmr> kyrofa: if you want to use the snap-store-proxy yourself the docs should be reasonably accurate and you can always ask us for help. If it's for sharing with a third party, it'd be best to wait for confirmation from the above mentioned folks ð
<bloodearnest> those docs are current
<kyrofa> roadmr, yeah, it's for sharing
<kyrofa> bloodearnest, thank you!
<roadmr> thanks bloodearnest ð
<jdstrand> roadmr: hey, did you see my request for a review-tools pull?
<jdstrand> kyrofa: perhaps degville knows?
<roadmr> jdstrand: I did! oooh fun! let's try this
<roadmr> perfect chance to adapt my fire-and-forget script too
<mvo> sergiusens sorry for the delay, we should have released the snapd snap today as well (2.39), let me check
<jdstrand> roadmr: cool. thanks. no rush, just wanted to make sure you saw it. if it works then I will stop using the bzr branch immediately
<mvo> cachio: (just reading backlog) there should be a 2.39 snapd snap and that is what we need to promote and test, it might get superseeded from beta when there is a new commit to 2.39 but thats the one we should promote to candidate/stable (the 2.39) "snapcraft history snapd" has the exact revision, its around 3289. it is slightly different from the way core is getting to beta, happy to talk about this tomorrow before the HO (for the details)
<degville> kyrofa / jdstrand: they are the latest (and only) docs that I know of for snap store proxy.
<kyrofa> degville, sorry, we had two conversations going at once. The question for you was: have we documented gadget interface auto-connection anywhere?
<degville> kyrofa: ah, right, no worries. re: gadget auto-connections, no - I don't think we've added anything to the docs to cover this. I can sync with zyga tomorrow and get back to you.
 * zyga is around but a bit too late to jump into new topics
<zyga> sorry kyrofa, degville
<degville> no problem zyga! it's getting dark :)
<mup> PR snapd#6892 opened: tests: reuse the image created initially for nested tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6892>
<kyrofa> degville, zyga thank you, that would be helpful for some stuff I'm writing
 * zyga gets the last part of the bug
 * zyga EODs
<zyga> ttyl
#snappy 2019-05-23
<mborzecki> morning
<mborzecki> kernel update, rebooting, brb
<mborzecki> aand back
<zyga> Hey :-)
<zyga> mborzecki: solved that issue last night
<mborzecki> zyga: hey
<zyga> Iâll eat dry and update the pr
<mborzecki> zyga: oh, solved mine too, i can create bootable images now  :)
<zyga> s/dry/sth/
<zyga> Sounds like a good day indeed
<zyga> What was the issue?
<mborzecki> zyga: the raw structure writer was dumping image content at a start offset that was within a complete volume, but since i'm constructing an image of each partition separately, i need to apply a bias to have the structure start at 0 offset
<mborzecki> now i need to figure out where the hell grubenv comes from in ubuntu-image
<mvo> mborzecki: the grubenv comes from `snap prepare-image`
<mborzecki> mvo: hi, and thanks for the tip
<mvo> mborzecki: yw and hi as well
<mup> PR snapd#6893 opened: gadget: helper for shifting structure start position <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6893>
<zyga> back in the office :)
<zyga> mvo: hey, I nailed that bug last night
<zyga> I need to make two small modifications to the fix PR and it's going to be green :)
<zyga> one is just shell quoting and another is reduction of a test that was really measuring the bug to begin with
<zyga> once I realised the test was buggy it was all obvious :)
<zyga> mvo: I also got a much nicer approach to defer, but separated out into its own branch
<zyga> it is much nicer than the v1
<zyga> I'll get to it now :)
<zyga> hey pedronis
<mvo> zyga: nice!
<mvo> hey pedronis
<mvo> zyga: looking forward to it
<pedronis> mvo: hi
<pstolowski> morning
<mborzecki> pstolowski: pedronis: hey
<amurray> is build.snapcraft.io a bit flaky at the moment? I can't seem to add a new repo (it just keeps spinning...)
<pedronis> pstolowski: hi, what are you working on ATM ?
<pstolowski> pedronis: hi, a small followup for snap debug timings output, then a small bugfix for them, then i'll move onto preventing nulls (with a forum topic at the same time)
<pedronis> pstolowski: I thought a bit further about the latter,  we should chat before we go there, also as we discussed it's probably 2.41 material
<pedronis> pstolowski: mvo: should we try to get "base: none" support sooner instead
<pstolowski> pedronis: there are two small issues with ensure timings, so perhaps we can discuss them + null at the same time
<pedronis> pstolowski: we can chat in 30 mins if you want
<pedronis> ~30
<pstolowski> pedronis: ok
<mborzecki> hmm shellcheck got an update apparently
<mvo> mborzecki: is it breaking our stuff?
<mborzecki> mvo: https://paste.ubuntu.com/p/Ztb7rqnzXP/
<zyga> mvo: hey, I'd love a review of https://github.com/snapcore/snapd/pull/6888
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<zyga> it's a pre-req for the test for the propagation bug
<mborzecki> mvo: https://github.com/koalaman/shellcheck/wiki/SC2251
<mvo> mborzecki: uh, thats pedantic
<mvo> mborzecki: let me read this but I'm not sure I like it
<mvo> mborzecki: eh
<mvo> mborzecki: if I'm reading this correctly our tests have some big holes?!?
 * mvo looks closer
<mborzecki> mvo: heh, yeah, not sure i understand the issue here, trying it out locally
<mvo> mborzecki: yeah
<mvo> mborzecki: https://paste.ubuntu.com/p/rtzBmt5Btf/
<mvo> mborzecki: this looks like either ! true or ! false trigger an errexit
<zyga> mborzecki: interesting, shell is a valley of landmines!
<mvo> zyga: its getting worse and worse
<zyga> mvo: fun
<zyga> yeah
<mvo> zyga: I mean, the more I learn the more I despair about all the corners one need to know
<zyga> it's all terrible
<zyga> mvo: right?
<mborzecki> mvo: don't trigger errexit you mean, right?
<zyga> I wish someone wrote a sane-sh
<mvo> zyga: also - I swear I saw this a gazillon of times in various scripts
<zyga> yeah
<zyga> mvo: we should donate to shellcheck
<pedronis> so yes, our tests are full of this, fun, not
<mvo> mborzecki: yeah, it seems like !true !false !whatever, nothing triggers an exit
<mvo> pedronis: /o\
<mborzecki> mvo: yup :/ ehh
<mvo> zyga: totally, at least we need to sent him some "you are a hero" mail or something
<mborzecki> mvo: at least it's good shellcheck flags that
<zyga> zyga@yantra:~/go/lnx-src/github.com/snapcore/snapd> git grep '!' -- */task.yaml | wc -l
<zyga> 490
<zyga> oh my
<zyga> mborzecki: which version of shellcheck is that?
<mborzecki> zyga: snap info shellcheck, look at edge
<zyga> zyga@yantra:~/go/lnx-src/github.com/snapcore/snapd> git grep '!' -- '*.sh' | wc -l
<zyga> 129
<mborzecki> btw. it's also published as a snap by the author :P
<mvo> mborzecki: yes
<pedronis> mvo: anyway trying here their correct doesn't work either
<pedronis> maybe I'm just confused
<mvo> zyga: if this guy is on twitter we should sent some hearts, I'm sure email will just get into his spam folder
<mvo> pedronis: same here, how strange
<mborzecki> we do ! foo, because we expect foo to fail, so if it doesn't fail, the test should err out i.e. errexit should get triggerred
<zyga> perhaps "correct" is just about telling shellcheck that is what you mean
<zyga> in all cases ! true doesn't exit
<pedronis> no, the wiki says, it will errexit
<pedronis> but doesn't
<mborzecki> maybe a different shell?
<mvo> I tried bash and dash
<zyga> I tried bash 3.2.57 (macos) and 5.0.7 (linux)
<zyga> same lack of result
<mvo> hey Chipaca
<zyga> hey chihchun
<zyga> I meant Chipaca
<mvo> Chipaca: great timing, we have shell fun again
<mborzecki> Chipaca: https://github.com/koalaman/shellcheck/wiki/SC2251
<pedronis> deep shell fun
<pedronis> pstolowski: want to chat now?
<zyga> pedronis: let me abberviate that to "deep sh"
<pstolowski> pedronis: yep, 1 minute
<zyga> mvo: strawman: uses python for tests
<mborzecki> mvo: fwiw ! true without {} doesn't work as expected either
<zyga> mvo: with that magic module that puts all shell commands as python functions
<zyga> mvo: via import magic
 * zyga looks
<mborzecki> zyga: sounds like you worked with bitbake :P
<Chipaca> mborzecki: mvo: nice
<zyga> oooh
<zyga> github now supports security patches
<Chipaca> so I've got bugs in my head, and we've got bugs in our code
<Chipaca> zyga: oh?
<mborzecki> Chipaca: so, the trick is finding a short form that actually works, bc one they say is correct does not seem to work
<zyga> I think I misread, security *bugs*
<zyga> https://twitter.com/github/status/1131470848513249280
<mvo> Chipaca: did you say "bugs on my head" ?
<zyga> mborzecki: I have an idea
<zyga> mborzecki: give me a sec
<zyga> mborzecki: and it ties into a super nice idea (famous last words) that I had in my last branch
<zyga> mborzecki: to put new things on $PATH for testing
<zyga> mborzecki: we can write "not ..." command
<Chipaca> mvo: in
<zyga> that just runs the rest in shell and negates the result
<pedronis> pstolowski: I'm in the standup
 * zyga does so quickly
<pstolowski> pedronis: ok coming
<mvo> zyga: oh, thats an interessting idea
<zyga> mvo: right?
<zyga> mvo: give me 3
<mborzecki> hack spread and make it define NOT
<mborzecki> mvo: ( ! true )
<mvo> aha!
<mvo> mborzecki: funny, the linked stackoverflow mentions ()
<mborzecki> ha!
<mvo> mborzecki: so probably worth a bugreport/patch
<mborzecki> should have done the reading
<mvo> mborzecki: to the shellcheck guy, least we can do
<mvo> nah, reading is overrated
<mborzecki> mvo: fwiw ( ! true ) isn't flagged
<zyga> mvo: https://github.com/snapcore/snapd/pull/6894
<mup> PR #6894: tests: add "not" command as replacement for "!" in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6894>
<mup> PR snapd#6894 opened: tests: add "not" command as replacement for "!" in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6894>
<zyga> mborzecki: ^
<Chipaca> um
<Chipaca> zyga: didn't you mean to put bin in the path
<zyga> Chipaca: didn't I put it?
<Chipaca> zyga: and the binary in the bin
<Chipaca> zyga: so the binary is in the path
<Chipaca> ?
<zyga> doh
<zyga> haha
<zyga> I see
<Chipaca> zyga: you even wrote a .keep file to keep the empty directory
<Chipaca> zyga: i think you need more coffee
<zyga> Chipaca: I'm having some now :D
<zyga> I recycled the bin idea from an earlier branch
<zyga> fixed now
<Chipaca> have of your neurons are all "whee" and the other half are all "g'waymnsfifCOMFYfmsmwm"
<Chipaca> half*
<zyga> Chipaca: I'm tempted to add tests/lib/man to MANPATH and write a man page now
<zyga> should I?
<zyga> mvo: if you like this idea (about not replacing !) I can adjust tests
<Chipaca> zyga: no
<Chipaca> zyga: (i don't really mind but nobody's gonna read it)
<zyga> mvo: perhaps we should invite shellcheck developer to a sprint sometime, he might be a good voice in the haskel community
<zyga> Chipaca: I'd read it in --debug
<Chipaca> zyga: have it look out for -h/--help then?
<Chipaca> zyga: but seems silly
<Chipaca> zyga: this is how /bin/true is not an empty file
<Chipaca> or was it /bin/false
<zyga> Chipaca: let's fix the tests story first
<Chipaca> anyway :)
<zyga> then I can play on this later :)
<mvo> zyga: I like the PR, unless pedronis disagrees I think we should use this approach and replace all our "! foo" with "not foo" or "assert_fail" or "assertFail foo" ?
<zyga> mvo: I agree
<Chipaca> /bin/true could be just an empty executable file and instead is a 27k dynamic binary, and it's all zyga's fault
<zyga> mvo: I'd go with "not foo" first
<zyga> not assert anything
<zyga> as we really are asserting each line
<zyga> because of the set -e
<mvo> so quicl poll on the name: "not", "assert_false", "assertFalse" ?
<zyga> mvo: we may also see bugs uncovered
<zyga> mvo: it should be "not" because of what I said
<mvo> zyga: oh yes
<zyga> and plays nice with the language, python and readability
<zyga> unless it starts to look ugly in tests
<zyga> but let's see how it works out
<zyga> mvo: I'll start attacking shell tests now
<mvo> zyga: sounds good, *if* there is a discussion about the naming we can easily sed the name again
<zyga> mvo: sounds good
<zyga> mvo: even inside the patch ):
<zyga> :-)
 * zyga is on it
<mvo> haha, true
<Eighth_Doctor> zyga, mborzecki
<Eighth_Doctor> have you guys tried the new snapd updates for fedora and el7?
<zyga> no, not lately, I just updated my F29 machine to usable status
<mborzecki> Eighth_Doctor: posted karma already, did you push any new updates?
<Eighth_Doctor> no
<Eighth_Doctor> it's the 2.39 update with the selinux stuff
<mborzecki> mvo: reported https://github.com/koalaman/shellcheck/issues/1588
<mborzecki> Eighth_Doctor: https://bodhi.fedoraproject.org/updates/FEDORA-2019-57826cb704#comment-944246 btw there's a systemd issue that also works better after a reboot
<mborzecki> zyga: do you think you could try the update in an actual workstation install?
<mvo> mborzecki: ta
<zyga> mborzecki: yeah, on F30
<Eighth_Doctor> mborzecki: I've marked the update as one that requires a reboot
<pedronis> zyga: mvo: given the spike and everything not sure zyga should work on this, can we put somebody else on it
<zyga> pedronis: it's done now, just running tests
<pedronis> zyga: done, as in you adjusted all tests?
<zyga> yes
<pedronis> ok, if some fail you probably pass it along to somebody else though
<zyga> yeah
<zyga> running now, fingers crossed
<zyga> I want, at least, the spread-shellcheck test to pass
<mvo> pedronis: agreed, we also need to finish the mount bug, iirc there are some loose ends here too. lets give the other parts to someone else
<mborzecki> Eighth_Doctor: other than that the updates seemed to work fine :P now that we also have f30 under spread it should be even better
<mborzecki> Eighth_Doctor: think you might be interested in this one: https://github.com/snapcore/snapd/pull/6874
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6874>
<mup> PR snapd#6895 opened: cmd/snap-confine, data/selinux: cherry pick Fedora 30 fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6895>
<mborzecki> hm should probably cherry-pick f30 for spread too
<mup> PR snapd#6880 closed: daemon: refactor user ops to api_users <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6880>
<zyga> mvo: how does https://github.com/snapcore/snapd/pull/6894 look?
<mup> PR #6894: tests: add "not" command as replacement for "!" in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6894>
<zyga> mvo: this is now shellcheck clean
<zyga> mvo: I'm running a pass of main/regression to see if something explodes
<zyga> but I will open the PR for review soon
<mvo> zyga: looking
<mvo> zyga: yeah, looks sensible
<zyga> updated the comment in the PR
<mup> PR snapd#6896 opened: cmd/snap: tweak the output of snap debug timings --ensure= <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6896>
<zyga> tests are looking good so far
<mvo> zyga: great, once that is ready please go back to the mount bug, its the last piece missing for 2.39.1
<zyga> mvo: mount bug is ready, it's just blocked by spread here
<zyga> but sure
<mvo> zyga: blocked by spread in the sense that tests are unstable?
<zyga> by spread-shellcheck specifically ;)
<zyga> mvo: let's do this:
<zyga> actually
 * zyga checks first
<mvo> zyga: hm, that seems silly, lets move to shellcheck from stable then for now
<zyga> my understanding is that master is red due to the shellcheck issue
<zyga> let's fix shellcheck in master
<mvo>   stable:    v0.6.0                2019-01-11 (329) 3MB -
<mvo> I think we should (temporarily) switch to shellcheck/stable
<mvo> and then move back to edge with the fix
<zyga> land the test tool from https://github.com/snapcore/snapd/pull/6888 (I can make it so that it doesn't conflict with the "not" branch)
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<zyga> mvo: and then I can just propose the mount propagation PR and start working on intramfs
<mvo> zyga: ok, that sounds like a plan - 1. move to shellcheck stable so that we can land things again, 2  we need reviews for 6888 3. propose the mount fix (even with 6888 not fully reviewed). sounds sensible?
<zyga> yep
<zyga> +1
<mvo> ta
<mup> PR snapd#6897 opened: tests/unit/spread-shellcheck: temporary workaround for SC2251 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6897>
<mborzecki> mvo: zyga: ^^
<zyga> thanks
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/6888
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<zyga> it's not small but it's a test tool
<mborzecki> zyga: looking
<zyga> thx
<mup> PR snapd#6898 opened: make snapstate.Update take *RevisionOptions instead of chan, rev <Created by chipaca> <https://github.com/snapcore/snapd/pull/6898>
<mup> PR snapd#6816 closed: daemon, overlord: support for cohort-key in refresh and switch <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6816>
<zyga> some bad news, for perfect support NOT would need to be a function like MATCH
<zyga> pipe expressions also need to be adjusted
<zyga> from
<zyga> ! echo foo bar | grep foo
<ubottu> zyga: I am only a bot, please don't think I'm intelligent :)
<zyga> to echo foo bar | not grep foo
<zyga> travis is pretty slow today
<zyga> I'll start working on initrd while we wait
<mup> PR core-build#39 opened: tests: fix RuntimeWarning coroutine was never awaited <Created by zyga> <https://github.com/snapcore/core-build/pull/39>
<pedronis> zyga: mmh, sounds like it needs more attention
<zyga> pedronis: yeah, I've dropped it for now
<zyga> pedronis: I will look in the evening, it's not hard, just tedious to look at 16 tests that fail
<zyga> pedronis: and to move the not around
<zyga> cmatsuoka, mvo: could you please look at https://github.com/snapcore/core-build/pull/39
<mup> PR core-build#39: tests: fix RuntimeWarning coroutine was never awaited <Created by zyga> <https://github.com/snapcore/core-build/pull/39>
<zyga> mborzecki: shellcheck branch switch failed on portal :/
<mborzecki> zyga: heh
<zyga> and auto refresh retry
 * mborzecki is not surprised
<zyga> mborzecki: how about https://github.com/snapcore/snapd/pull/6888 ?
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<mborzecki> zyga: just clicked send
<zyga> mborzecki: repleid
<zyga> *replied
<zyga> oddly everything is "outdated" in your review
<zyga> did you start it a while ago before I git mv'd files
<zyga> ?
<mborzecki> zyga: hmm maybe
<mborzecki> zyga: what i tought about with device being tuple: http://paste.ubuntu.com/p/78j96hf84m/
<zyga> mborzecki: mmmm, I see
<zyga> mborzecki: I would have used nametuple for that
<zyga> mborzecki: but I wanted to align more closely with C where that's a single variable
<mborzecki> zyga: or that, don't know if it's worth the change though
<cachio> mvo, hey
<Chipaca> mborzecki: zyga: what was the consensus wrt ! ?
<mborzecki> Chipaca: switched to --stable for now, zyga opened a PR with `not` helper
<Chipaca> mborzecki: is that on master?
<mborzecki> Chipaca: neither is, https://github.com/snapcore/snapd/pull/6897 https://github.com/snapcore/snapd/pull/6894
<mup> PR #6897: tests/unit/spread-shellcheck: temporary workaround for SC2251 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6897>
<mup> PR #6894: tests: add "not" command as replacement for "!" in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/6894>
<Chipaca> ack
<mborzecki> Chipaca: oh and opened an issue https://github.com/koalaman/shellcheck/issues/1588
<Chipaca> mborzecki: 'temporary workaround fo SCP 2251' (http://www.scp-wiki.net/scp-2251)
<cjwatson> oh god must not get sucked in
 * Chipaca updates his nerdsniping score
 * zyga has a great moment by reading a particular man page!!!
<mvo> zyga: tell us more
<zyga> mvo: haha, nothing special really, just mkfs.ext4 can copy data into the filesystem in one go
<zyga> so no root required :)
<mvo> zyga: yeah, ubuntu-image is doing this
<mvo> zyga: its pretty cool
<Chipaca> zyga: i think that's what mborzecki was using fakeroot for
<mup> PR snapd#6899 opened: image: make prepare-image recovery-system aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/6899>
<mborzecki> yup, otherwise it ends up owned by whoever ran mkfs.*
<mborzecki> fakeroot mkfs.ext4 <random-opts> -d <contents>
<mborzecki> wish mkfs.vfat supported that too :/
<zyga> mborzecki: dostools can copy files in and out
<mborzecki> zyga: and that's what i'm using
<mborzecki> zyga: what i meant is to mkfs.vfat have -d <contents> to popualte fs with some contents, instead of mcopy -i <image> -s <path> ::
<zyga> yeah
<pstolowski> pedronis: re base:none, we have code right now that installs "snapd" in prereq if core/snapd is not installed (for interfaces to work). should we keep doing this when installing a snap with base:none and there is nothing else in the system?
<pedronis> pstolowski: yes
<pstolowski> k
<cachio> mvo, I just updated the #6883
<mup> PR #6883: tests: fix how strings are matched on auto-refresh-retry test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6883>
<pedronis> mborzecki: I made a pass over #6871, couple of comments
<mup> PR #6871: gadget: raw/bare structure writer and updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6871>
<mborzecki> pedronis: thanks!
<mup> PR snapd#6897 closed: tests/unit/spread-shellcheck: temporary workaround for SC2251 <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6897>
 * Chipaca lunches
<mborzecki> mvo: can you cherry-pick 6897 to 2.39?
<mborzecki> off to pick up the kids
<zyga> mvo: can you review https://github.com/snapcore/snapd/pull/6888
<mup> PR #6888: tests: add mountinfo-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/6888>
<cachio> zyga, about the mountinfo-tool, it is really nice
<cachio> zyga, but I think that should be better if the test checks more stuff, I mean using the tool we check mount info on the system
<cachio> zyga, perhaps it could be a following PR
<cachio> also I can do it for sure
<zyga> cachio: do you mean the spread test?
<cachio> zyga, yes
<zyga> cachio: yeah, it's just a start, I plan to work on it some more
<cachio> zyga, nice, thanks
<mup> PR snapd#6900 opened: [RFC] snapstate: support base = "none" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6900>
<zyga> pstolowski: reviewed
<pstolowski> ty
<Chipaca> mborzecki: when we started using shellcheck from snap it was only in edge fwiw
<mborzecki> Chipaca: quite probable :) glad it has stable now too
 * zyga runs for lunch
<Chipaca> #6898 is now green. It's a pure refactor, and has one +1. Is that landable? :)
<mup> PR #6898: many: make snapstate.Update take *RevisionOptions instead of chan, rev <Created by chipaca> <https://github.com/snapcore/snapd/pull/6898>
<zyga> summer storms :)
<zyga> Chipaca: looking
<zyga> Chipaca: any chance of nil pointer breaking somewhere?
<zyga> Chipaca: or are all ingress paths defending against thatA?
<zyga> Chipaca: I also see the amend flag has moved from updateInfoOpts to just a flags argument
<zyga> Chipaca: I guess it looks ok,
<pedronis> zyga: Flags always had Amend
<pedronis> it has not moved
<zyga> yes, but the way it was conveyed to a piece of code has changed so it effectively "moved" to a different argument
<zyga> Chipaca: it's slightly odd that RevisionOptions starts with channel and only then goes to revision but that's cosmetics
<pedronis> it's just carried along a bit differently at that point
<zyga> right, I think it looks good
<zyga> Chipaca: merge away :)
<pedronis> Chipaca: ah, RevisionOptions merits a doc comment
<pedronis> I didn't notice but zyga comment about the order of things inside (which is correct) made me think that maybe it needs one for real
<pedronis> Chipaca: made a comment
<Chipaca> pedronis: i'll add a comment in the switch followup if that's a'ight
<pedronis> Chipaca: yes, that's fine
<mup> PR snapd#6898 closed: many: make snapstate.Update take *RevisionOptions instead of chan, rev <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6898>
<mup> PR snapd#6901 opened: overlord/snapstate, daemon: snapstate.Switch now takes a RevisionOption <Created by chipaca> <https://github.com/snapcore/snapd/pull/6901>
<Chipaca> super simple followup ^ :-)
<pedronis> cachio: what's the status of #6541 ?
<mup> PR #6541: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<mup> PR snapd#6902 opened: spread.yaml: make HOST: usage shellcheck-clean <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6902>
<cachio> pedronis, it needs reviews
<cachio> I addressed all the comments
<mup> PR snapd#6903 opened: spread-shellcheck: add support for variants and environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6903>
<zyga> mvo: ^ two last prereqs
<cachio> zyga, Chipaca could you please take a look to #6541
<mup> PR #6541: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<zyga> yep
<mup> PR snapd#6888 closed: tests: add mountinfo-tool <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6888>
<Chipaca> cachio: looking
<Chipaca> cachio: did you do address maciej's comment?
<zyga> Chipaca: looking now
<Chipaca> zyga: wrt pointer, it's checked on ingress (first few lines of update and switch)
<zyga> +1
<Chipaca> zyga: and even there it's just as a kindness to the tests
<zyga> thanks
<Chipaca> as all actual code is passing the thing in one way or another
<zyga> I wish golang had null type safety
<cachio> Chipaca, I tested that and that was not the solution
<Chipaca> cachio: you should probably reply to him then :-/
<Chipaca> zyga: it does!
<Chipaca> zyga: sometimes :-p
<zyga> hmm, I misunderstood the comment and the code then
<zyga> I assumed the pgrep check and the unmount was that
<cachio> Chipaca, I think  I did but in irc or during a standup
<cachio> Chipaca, I'll add a comment there too
<zyga> cachio: yeah, please explain to mborzecki in the PR first
<Chipaca> zyga: sorry i was being obtuse. a nil thing that is an interface and a nil thing that is a concrete pointer can be different in awkward ways.
<zyga> yeah
<zyga> I was mainly looking for type safety of:
<zyga> var foo *Foo
<zyga> foo.a = "baz" # should fail to compile
<zyga> if foo != nil { foo.a = "baz" } # should compile
<Chipaca> zyga: it's funny because it's got something like that for optimizations (branch elimination?), but not as part of the language
<zyga> yeah
<Chipaca> "funny"
<zyga> it'd be a breaking change now
<zyga> but I really miss it
<zyga> java's null was equally painful
<zyga> I'm happy that some newer languages can be nil/null safe
<zyga> (mainly by not having null)
<zyga> mostly
<mup> PR core-build#39 closed: tests: fix RuntimeWarning coroutine was never awaited <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/39>
 * pedronis mostly eows
<mvo> zyga: thanks, was in a meeting (and will be in one again shortly) will try to look in a wee bit
<zyga> thx
<zyga> mvo: https://github.com/snapcore/snapd/pull/6902
<mup> PR #6902: spread.yaml: make HOST: usage shellcheck-clean <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6902>
<zyga> https://github.com/snapcore/snapd/pull/6903
<mup> PR #6903: spread-shellcheck: add support for variants and environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6903>
<zyga> mvo: and lastly https://github.com/snapcore/snapd/pull/6891  but i will rewrite commit message
<mup> PR #6891: many: make new mount points MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> brb
<mup> PR snapd#6904 opened: timings: always store ensure timings as long as they have an associated change <Created by stolowski> <https://github.com/snapcore/snapd/pull/6904>
 * zyga finally had lunch
<zyga> now dinner really
<zyga> *starving*
<zyga> re
 * cachio lunch
<zyga> Chipaca: around?
<zyga> mvo: around?
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/6891
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> jdstrand: review appreciated, we'd like to land this in .1
<zyga> jdstrand: I will open the PR for real as soon as prerequites land
<jdstrand> hey, it is on the list
<zyga> thanks!
<zyga> it's not a big one but it's a big change
<mup> PR snapd#6901 closed: overlord/snapstate, daemon: snapstate.Switch now takes a RevisionOption <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6901>
<mup> PR snapd#6905 opened: daemon, overlord/snapstate: give RevisionOptions a CohortKey <Created by chipaca> <https://github.com/snapcore/snapd/pull/6905>
 * Chipaca EODs
 * cachio afk
<mup> PR snapd#6902 closed: spread.yaml: make HOST: usage shellcheck-clean <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6902>
<mup> PR snapd#6906 opened: cmd/snap-update-ns: rename ctx to upCtx <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6906>
<jdstrand> zyga: fyi, I commented on https://github.com/snapcore/snapd/pull/6891 (and I'm heading out now)
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> jdstrand: thank you very much
#snappy 2019-05-24
<mup> PR snapcraft#2568 closed: docs: consolidate on a simple HACKING.md <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2568>
<mborzecki> morning
<zyga> Hey mborzecki
<mborzecki> zyga: hey
<mborzecki> zyga: how's your day off coming? :)
<zyga> Haha
<zyga> I was just wondering the same thing
<zyga> Should I take today off for real
<zyga> Or work some more to get stuff done
<zyga> So many things to work on
<zyga> mborzecki: I sent a small patch for spread-shellcheck
<zyga> And had an idea on how to fix not MATCH
<zyga> We can save MATCH to lib/bin on startup
<zyga> Like we do now to match.sh include file
<zyga> Since it is on path it will be more flexible
<zyga> Then MATCH is no longer a function
<zyga> Then we can put ânotâ on path and fix all tests
<mborzecki> zyga: in other news, got an image built by snap-image (strawman) to boot up to a point where i got console conf :P
<zyga> Wooooot
<zyga> That is great
<zyga> It still feels that landing your changes will take a month
<mborzecki> yeah, and tests and all that
<mborzecki> zyga: if you guys have a system-rescue role that you'd like me to add or something, this coudl be done really easily
<zyga> Role as in partition type?
<zyga> I think we should talk about how the recovery system is designed, so far, to keep you in the loop
<mborzecki> zyga: role as role in gadget.yaml terms, and whatever that means practically, eg. like system-boot is a bit special
<mborzecki> zyga: and so is system-data
<zyga> I think some things there will change
<zyga> Though I think that is best for next week
<zyga> re, back in the office
<zyga> mborzecki: can you do a quick review of https://github.com/snapcore/snapd/pull/6906
<zyga> just a variable rename
<mup> PR #6906: cmd/snap-update-ns: rename ctx to upCtx <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6906>
<zyga> though more importantly I need a review for https://github.com/snapcore/snapd/pull/6903 to get 2.39.1 fix in place
<mup> PR #6903: spread-shellcheck: add support for variants and environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6903>
<zyga> the shellcheck change is not perfect
<zyga> but it's also not totally incorrect
<zyga> and allows my tests to not get stuck on that
 * zyga quick coffee
<zyga> mborzecki: if you can review the spread-shellcheck change I will be able to propose the propagation fixes
<zyga> I will do some branch gardening soon
<zyga> but first coffee
<pstolowski|afk> morning
<zyga> Hey :-)
<zyga> Interesting https://forum.snapcraft.io/t/snapshots-can-expose-sensitive-data/11493
<pstolowski> zyga: hmm interesting indeed
<mup> PR snapd#6906 closed: cmd/snap-update-ns: rename ctx to upCtx <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6906>
<zyga> makes me feel that snapshots should be saved back to $HOME
<zyga> as anything else is not correct wrt NFS and encryption
<zyga> pstolowski: quick trivial https://github.com/snapcore/snapd/pull/6907
<mup> PR #6907: cmd/snap-update-ns: add several TODO comments <Created by zyga> <https://github.com/snapcore/snapd/pull/6907>
<zyga> just comments
<zyga> but that's *all* of the refactoring :D
<zyga> wooooot
<mup> PR snapd#6907 opened: cmd/snap-update-ns: add several TODO comments <Created by zyga> <https://github.com/snapcore/snapd/pull/6907>
<pstolowski> +1Â§
<mborzecki> pstolowski: hey
<pstolowski> o/
<mup> PR snapd#6894 closed: tests: add "not" command as replacement for "!" in tests <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6894>
<mup> PR snapd#6908 opened: tests: add "not" command <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6908>
<zyga> mborzecki, pstolowski: how do you feel about ^ not
<zyga> I want to build this on top  https://github.com/snapcore/snapd/pull/6909
<mup> PR #6909: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
<zyga> and then fix our scripts to use not rather than !
<mup> PR snapd#6909 opened: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
<pstolowski> zyga: interesting; don't we still need to make it a compound expressionm e.g. { ! "$@" } ?
<zyga> no,  why?
<zyga> ! functions correctly
<zyga> note that this executable is not sourced, it's a program that runs without set -e
<pstolowski> zyga: ok, so -e is the key here. i was reading also https://stackoverflow.com/questions/39581150/why-do-i-need-parenthesis-in-bash-set-e-and-negated-return-code/39582012
<zyga> I wonder if snapd is going to get any sponsors: https://techcrunch.com/2019/05/23/github-launches-sponsors-lets-you-pay-your-favorite-open-source-contributors/
<zyga> mborzecki: https://github.com/google/pytype
<zyga> mborzecki: from that video you linkedto
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6903
<mup> PR #6903: spread-shellcheck: add support for variants and environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6903>
<mborzecki> zyga: nhm, lgtm
<zyga> nhm?
<zyga> mborzecki: something for you :) https://github.com/snapcore/snapd/pull/6910
<mup> PR #6910: spread.yaml: use "snap connections" in debug <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6910>
<mup> PR snapd#6910 opened: spread.yaml: use "snap connections" in debug <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6910>
 * zyga really gets that coffee now
<zyga> after the break I will try to land "not" and "MATCH" as commands and see if I can fix ! tree-wide
<zyga> and revert shellcheck patch so that we track edge again
<zyga> back now :)
<zyga> aaaand, "not" is red
<mup> PR snapd#6907 closed: cmd/snap-update-ns: add several TODO comments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6907>
<pstolowski> and i just had google:ubuntu-14.04-64:tests/main/parallel-install-aliases failure on one of my PRs
<pstolowski> never seen it failing
<zyga> pstolowski: how did it fail?
<pstolowski> zyga: it was expecting the change to fail with 'cannot enable alias "alias1" for "aliases_foo", already enabled for "aliases"', but instead got 'Done    today at 15:27 UTC  today at 15:27 UTC  Setup manual alias "alias1" => "cmd1" for snap "aliases"'
<pstolowski> zyga: i wonder it snap change --last=alias check there isn't racy
<zyga> huh, I saw that fail once as well
<zyga> yesterday
<pstolowski> because just above we test happy execution
<pstolowski> zyga: i'll kick it again on travis and in the meantime execute and investigate it locally
<zyga> k
<pstolowski> and if that's it, will fix it
<zyga> pstolowski: can you look at https://github.com/snapcore/snapd/pull/6903
<mup> PR #6903: spread-shellcheck: add support for variants and environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6903>
<pstolowski> k
<zyga> I need a 2nd review to open the fix for the mount propagation PR
<zyga> mborzecki: curious, permissions package seems to be updated with some snapd bits
<zyga> as a simple build in obs failed on that
 * zyga looks
<zyga> settle not converging
 * zyga loves when unit tests fail
<zyga> pstolowski: does this sound familiar?
<zyga> https://www.irccloud.com/pastebin/02IEvvjO/
<zyga> ah, this is device registration, not hotplug
<zyga> sorry
<zyga> bah
<zyga> this happens each time
 * zyga debugs
<mup> PR snapd#6893 closed: gadget: helper for shifting structure start position <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6893>
<zyga> hrm
<zyga> go test passes on my tree with 2.39
<zyga> fails in the tarball
<zyga> whhyyyyy
<zyga> hmmm
<zyga> I disabled unit tests and installed the resulting package
<zyga> let's see how it operates
<zyga> then I can see why they fail again
<zyga> eh
<zyga> in x11 mode I don't have /snap/bin on path
<zyga> in wayland mode some apps just crash
<zyga> lovely
<zyga> after reboot things seem to be have
<zyga> behave even
<pstolowski> zyga: hmm somewhat, seen failures like this from time to time while working on these tests, usually was a race. you're saying it fails each time like this?
<zyga> do you remember https://github.com/snapcore/snapd/pull/6360 <- I just merged master into it :)
<mup> PR #6360: cmd/snap-update-ns: refactor of profile application <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6360>
<zyga> pstolowski: yeah
<zyga> but only in packaging build
<zyga> not in a checkout
<zyga> I didn't look deeper yet
<zyga> "not" failed again
<pstolowski> zyga: on which test?
<zyga> service watchdog
<pstolowski> zyga: +1 on 6903 with a question
<zyga> looking
<pstolowski> of course parallel-install-aliases is passing when run locally... will keep it running during lunch
<zyga> pstolowski: replied there
<pstolowski> ty
 * pstolowski lunch
<mup> PR snapd#6903 closed: spread-shellcheck: add support for variants and environment <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6903>
<zyga> I've opened https://github.com/snapcore/snapd/pull/6891 for real now
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> tests *should* pass now
<zyga> so fingers crossed
<zyga> I think I need a break
<zyga> but it's moving along
<zyga> what do you guys think about https://github.com/snapcore/snapd/pull/6909 ?
<mup> PR #6909: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
<zyga> I will work on mountinfo-tool to support earlier versions of python so that we can use it in 16.04
<mup> PR snapd#6911 opened: cmd/snap-update-ns: rename leftover ctx to upCtx <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6911>
 * zyga breaks
<mup> PR snapd#6912 opened: gadget: keep track of the index where structure content was defined <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6912>
<mup> PR snapd#6883 closed: tests: fix how strings are matched on auto-refresh-retry test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6883>
<mup> PR snapd#6910 closed: spread.yaml: use "snap connections" in debug <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6910>
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/6890 really for review?
<mup> PR #6890: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>
<mborzecki> zyga: heh, yes
<zyga> *gulp*
<mborzecki> zyga: want to dive in? :)
<zyga> they told me to split a 1K diff
<zyga> took several moths to review
<zyga> *months
<zyga> (i'd be faster with moths :D
<mborzecki> zyga: 1.6k is tests :P
<zyga> for me 80% was tests
<zyga> good luck :-)
<zyga> no way to chunk that?
<mborzecki> idk, maybe i could sample, method by method :/
<zyga> at the end of the day I can review and approve but you need extra reviews from samuele
<mborzecki> hm maybe i could pull the writer thing apart, that's ~10% of the thing
<zyga> ok, really time to break now
<zyga> I'll merge "not" when green
<zyga> and if you guys can review https://github.com/snapcore/snapd/pull/6909 we could fix all of ! foo bugs
<mup> PR #6909: spread.yaml,tests: change MATCH and REBOOT to cmds <Created by zyga> <https://github.com/snapcore/snapd/pull/6909>
<mup> PR snapd#6913 opened: tests: force snap-reexec test to fail to reproduce the error on ubuntu 14.04 <â Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6913>
<mborzecki> zyga: should we have NOT instead of lowercase not to match MATCH and REBOOT?
<popey_> chipaca not working today?
<zyga> mborzecki: MATCH and REBOOT come from spread
<zyga> popey_: I think he's off today
<zyga> mborzecki: I think lowercase "not" looks nicer
<popey_> ta
<zyga> mborzecki: but to answer your question, I kept REBOOT and MATCH uppercase only to match spread names and avoid code changes
<zyga> not failed again :D
<zyga> heh
<zyga> landing a trivial unused file
<mborzecki> pstolowski: a look at https://github.com/snapcore/snapd/pull/6912 ?
<mup> PR #6912: gadget: keep track of the index where structure content was defined <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6912>
<zyga> this time on refresh-delta-from-core
<zyga> meh
<zyga> I'll grab some food
<zyga> ttyl
<zyga> tests still churning ...
<mborzecki> zyga: can you do another pass of #6750? you did one there already, and I pushed some changes in the meantime
<mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
<zyga> yep
<mup> PR snapd#6908 closed: tests: add "not" command <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6908>
<zyga> nice!
<zyga> mborzecki: can you discuss that portal test change PR with cachio please?
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6912 needs formatting fixes
<mup> PR #6912: gadget: keep track of the index where structure content was defined <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6912>
<cachio> zyga, sure
<zyga> probably need to reformat with ancient go
<zyga> (yuck)
<zyga> settle not converging (unit tests) https://www.irccloud.com/pastebin/KgUHJ07T/
<cachio> mborzecki, did you see the comments in the PR?
<zyga> loads of those
<mborzecki> omg, i hate they made the formatting change in 1.11
<mborzecki> super annoying
<jdstrand> zyga: fyi, I added a sprinking of emojis, a comment on your response to /etc and then also https://github.com/snapcore/snapd/pull/6891#issuecomment-495609846
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> :-)
<zyga> thanks!
<zyga> I noticed it failed for real in one specific test
<zyga> looking now
<zyga> pstolowski: standup
<pstolowski> yep
<Wimpress> Snapcraft Live is just starting - https://www.youtube.com/watch?v=yAnRM4m63MY
<zyga> Wimpress: nice!
<mborzecki> Wimpress: nice, shirt, tie and shorts right? :)
<zyga> mborzecki: *hopefully* there are shorts
<mborzecki> the upsides of working remotely :)
<mup> PR snapd#6911 closed: cmd/snap-update-ns: rename leftover ctx to upCtx <Simple ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6911>
<zyga> jdstrand: I consistently get a denial for a permission I hold
<zyga> perhaps something quirky with mount options and 14.04 (4.4) kernel
<jdstrand> zyga: does it go away with a bare mount rule?
<zyga> jdstrand: just "mount," ?
<jdstrand> yes
<zyga> jdstrand: curiously, it does not
<zyga> ahhh
<zyga> I'm a tool
<zyga> sorryt
<zyga> reexec bit me
<jdstrand> heh. it always does at least once ;)
<zyga> jdstrand: bare mount rule is ok
<zyga> let's see if without it it also works :D
<zyga> so it works but I don't know why ... let's restart and see
<zyga> jdstrand: I think something is still fishy but I cannot point to anything apart from the failure in spread
<zyga> jdstrand: I tweaked things a little os that they read:
<zyga> relevant fragment of apparmor permissions https://www.irccloud.com/pastebin/v267dsbt/
<pstolowski> zyga: do you have anything needing 2nd review that i can take a look at?
<zyga> the denial I got is associated with permission on line 6
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6891
<zyga> it's not 2nd but it needs review
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> that's the 2.39.1 patch
<jdstrand> zyga: so, you are saying there is no apparmor denial, but an eperm, but with a bare mount rule, it all works?
<zyga> there's a denial
<zyga> bare mount fixes it
<jdstrand> what is the denial?
<zyga> the denial is
<zyga> May 24 13:41:11 may241325-532686 kernel: audit: type=1400 audit(1558705271.095:74): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/snap/snapd/x1/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_dPNxms/" pid=18844 comm="snap-confine" flags="rw, rshared"
<jdstrand> you're missing rw
<zyga> but wait, rw I had
<zyga> I removed it
<zyga> (also rw makes no sense for propagation changes)
<jdstrand> I can only comment on what you have shown me
<jdstrand> :)
<zyga> yeah I know :)
<jdstrand> zyga: I'm not sure why rw would pop out. that may be a bug or it may be some subtlety in the kernel that needs it cause it is shared
<jdstrand> seeing the strace of that might help...
<zyga> yeah
<roadmr> jdstrand: hey! tools r... wait... checking the actual version... "20190522-1231UTC click-reviewers-tools version " is now in production \o/ I think you can now get rid of your bzr branch
<jdstrand> zyga: I mean, looking at the strace I have here, the rbinds don't specify rw, but there it is on line 4 of your paste
<jdstrand> roadmr: yay!!
<jdstrand>  \o\
<jdstrand>  /o/
<jdstrand>  \o\
<jdstrand>  \o/
 * jdstrand hugs roadmr :)
<roadmr> ð  hehe
<jdstrand> zyga: I suspect if you add the rw and account for reexec, you will be on your way
<zyga> there's rw there already
<zyga> it's not that
<zyga> I'm debugging
 * jdstrand is confused
<zyga> jdstrand: there *was* rw, I removed it thinking it is the issue
<jdstrand> zyga: but reexec?
<zyga> I changed the source and re-ran spread
<zyga> gah, I'm tired
<zyga> jdstrand: I merged master into the ancient huge PRs
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6341 is interesting (diff wise small)
<mup> PR #6341: WIP: persist per-user mount namespace profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6341>
<mup> Bug #1830382 opened: Have a progress indicator for snap pack (like with snapcraft pack) <Snappy:New> <https://launchpad.net/bugs/1830382>
<zyga> jdstrand: with that branch I should be able to answer your questions about the set of required capabilities
<jdstrand> these PRs are like rabbits
<mup> Bug #1830382 changed: Have a progress indicator for snap pack (like with snapcraft pack) <snapd:Triaged> <https://launchpad.net/bugs/1830382>
<jdstrand> I review a bunch and then end up with more than I started with
<zyga> yeah
<sparkiegeek> mvo, zyga: btw, shouldn't https://bugs.launchpad.net/snapd/+bug/1819318 be at least Fix Committed? and arguably Fix Released?
<mup> Bug #1819318: no interfaces when installing only core18 <snapd:In Progress> <https://launchpad.net/bugs/1819318>
<zyga> sparkiegeek: in a call
<zyga> mvo worked on that
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6891#issuecomment-495643768 I'm giving up now
<mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
<zyga> need to take a walk and think
<pstolowski> a few hours later and... parallel-install-aliases doesn't want to fail
<mup> PR snapd#6912 closed: gadget: keep track of the index where structure content was defined <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6912>
<mup> PR snapd#6914 opened: tests: change strace parameters on snap-run test to avoid the test gets stuck <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6914>
 * cachio lunch
 * zyga feels sick somehow, EODing now
<mup> Bug #1830412 opened: QT5 classic snaps segmentation fault <Snappy:New> <https://launchpad.net/bugs/1830412>
 * cachio afk
<mup> PR pc-amd64-gadget#17 closed: add .travis.yml to enable basic smoke testing (20) <Created by mvo5> <Merged by vorlonofportland> <https://github.com/snapcore/pc-amd64-gadget/pull/17>
<mup> PR pc-amd64-gadget#16 closed: add .travis.yml to enable basic smoke testing (18) <Created by mvo5> <Merged by vorlonofportland> <https://github.com/snapcore/pc-amd64-gadget/pull/16>
<mup> PR pc-amd64-gadget#15 closed: add .travis.yml to enable basic smoke testing <Created by mvo5> <Merged by vorlonofportland> <https://github.com/snapcore/pc-amd64-gadget/pull/15>
#snappy 2019-05-26
<popey_> ls
<popey_> oops :)
#snappy 2020-05-18
<mup> PR snapcraft#3129 opened: schema: add support for the daemon-scope property on apps <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3129>
<davido_> Does this channel support issues with the snap management tool?
<davido_> or is it only developer focused?
<mup> PR snapcraft#3130 opened: build_providers: don't show an error if there are no auto-refresh changes <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3130>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey, can you take a look at https://github.com/snapcore/snapd/pull/8604 ?
<mup> PR #8604: interfaces/builtin/desktop: do not mount fonts cache on distros with quirks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8604>
<mvo> mborzecki: sure
<mborzecki> mvo: thanks
<mvo> mborzecki: thanks, done, we should also squash it I think
<mborzecki> mvo:yeah, easier to cherry pick
<mvo> +1
<zyga> hey
<mvo> good morning zyga
<mborzecki> zyga: hey
<zyga> how was Friday?
<mborzecki> zyga: that opensuse go thing is weird, looks like there's a parallel install of go1.13 and go1.12, and the packages are conflicgting on who owns /usr/bin/go
<zyga> yeah
<zyga> maybe it is some kind of vendor change situation
<zyga> but I really don't know
<mborzecki> actually, afaiu both packages ship /usr/bin/go ?
<zyga> I never experienced this myself
<zyga> yeah
<mborzecki> zyga: we also ahve `BuildRequires:  go >= 1.9` so go1.13 should be just fine, unless it doesn't provide go?
<zyga> maybe something else depends
<zyga> or maybe we just mass-upgrade
<zyga> I didn't look that deeply
<mborzecki> maybe it's confused when we ask for go >= 1.9 :/
<mborzecki> it's funny, bc we end up with older go than we had :P
<zyga> mmm, as in doesn't understand that dependency is satisfied?
<zyga> I think that's unlikely
<zyga> btw, suse does roll back packages normally
<zyga> their repo points to the truth
<zyga> and systems adjust
<zyga> and it's not unheard of packages going to older releases
<zyga> maybe that's what going on
<pstolowski> morning
<zyga> hey pawel
<zyga> rainy morning
<zyga> perfect for Monday
<mvo> good morning pstolowski
<pstolowski> zyga: same here
<mborzecki> pstolowski: hey
<mborzecki> zyga: heh, zypper insists on installing 1.12, however what provides lists many options https://paste.ubuntu.com/p/P8NbcSGpRR/
<pstolowski> mborzecki: your hunch about selinux denials & go doing enumeration of network interfaces was good.. https://paste.ubuntu.com/p/JQQDrTqsg8/
<mborzecki> pstolowski: heh, no a question which part of the code does that
<mborzecki> pstolowski: maybe pulling in net package triggers is
<pedronis> it's the randutil code
<mborzecki> omg, i see now, it's listing interfaces
<pstolowski> ah
<mborzecki> / mix in net interfacles hw addresses (MACs etc)
<mborzecki>   if ifaces, err := net.Interfaces(); err == nil {
<pedronis> but it's inderect
<pedronis> it you neeed to be using RandDuration
<pedronis> but we have a few places that use RandomDuration at the top level
<pstolowski> it's only in my PR, apparently indirectly pulled (by configcore?)
<pedronis> https://github.com/snapcore/snapd/blob/master/randutil/rand.go#L93
<pedronis> pstolowski: let me think a second, we had something in mind that we might have forgotten
<pstolowski> pedronis: for clarity, this is now triggered by snap cli, not snapd
<pedronis> pstolowski: yes, we have worked toward a way to build configcore without pulling in the mangers
<pedronis> but we haven't finished the work
<pedronis> we really don't want the managers in snap
<pedronis> this is showing that very indirectly
<mvo> good morning pedronis !
<pedronis> pstolowski: we need to finish that work
<pedronis> and it's going to be a of a pain as we learned from nosecboot
<mborzecki> zyga: addeda  note under https://github.com/snapcore/snapd/pull/8685#issuecomment-630014236 perhaps it's worth checking with go packaging guidelines or in #opensuse about the best solution
<mup> PR #8685: opensuse: zypper --replacefiles <Created by zyga> <https://github.com/snapcore/snapd/pull/8685>
<pstolowski> mborzecki: btw i also saw some selinux denials that for some reason were not reported when using --checkpoint ..., only shown with ausearch -i -m AVC. i haven't investigated it and i don't know if it is anyhow related to my branch or also present in master - https://pastebin.ubuntu.com/p/TBRdbCFvkS/
<zyga> mborzecki: 1:1
<pedronis> pstolowski: am I making sense?
<pstolowski> pedronis: yes, i remember the general idea/desire we discussed some time ago. don't know what does this entail yet
<pedronis> pstolowski: mostly usinh build flags, except for some of the distro they don't quite work :/
<pstolowski> pedronis: in this particular case, is there a concern of entropy? could we land this early-config PR by temporarily relaxing selinux check in these tests?
<pedronis> pstolowski: temporarely for how long?  we really don't want to pull in the managers in snapd
<pstolowski> pedronis: i can start working on proper fix today, just don't know how annoying/long will it be and for long early config will be blocked because of this
<pedronis> pstolowski: to be clear I'm not too concerned about relaxing the selinux rules otoh is completely not the work we need
<mborzecki> pstolowski: i saw those only in our tests though, i suspect it's because we repack the core snap and try to prevent the new squashfs from picking up default label (home_t) by passing unlabeled_t epxliciltly, however we also expliclity set the context=.. when mounting the squashfs, but that doesn't stop the denials due to unlabeled_t when running hooks to appear, i suspect there may be some race
<mborzecki> between snapd accessing the contents and desired label set at the fs level
<mborzecki> pstolowski: iirc if you go an ls -lZ those locations they have snappy_snap_t as expected
<mup> PR snapd#8676 closed: tests: port interfaces-dbus to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8676>
<pstolowski> mborzecki: ack
<zyga> re
<zyga> mborzecki: looking
<zyga> mborzecki: nice work!
<zyga> brb, tea and back into the fray :)
<pedronis> pstolowski: are you blocked atm?
<pstolowski> pedronis: no
<zyga> and back
<pedronis> pstolowski: we can chat after lunch about what to do, I have a meeting now
<pstolowski> pedronis: ok, thanks
<mup> PR snapd#8686 opened: o/devicestate: cleanup system actions supported by recover mode <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686>
<pedronis> pstolowski: can you setup a meeting before the standup when is convenient for you?
<pstolowski> pedronis: will do
<mup> PR snapd#8687 opened: [RFC] overlord: show what manager throws a state ensure error <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8687>
<mup> PR snapd#8688 opened: [RC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688>
<mup> PR snapd#8689 opened: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<mup> PR snapd#8690 opened: devicestate: do not report "ErrNoState" for seeded up <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8690>
<mborzecki> mvo: left a comment under https://github.com/snapcore/snapd/pull/8687#discussion_r426544961
<mup> PR #8687: [RFC] overlord: show what manager throws a state ensure error <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8687>
<mvo> mborzecki: yeah, saw it, looks interessting. I guess we samuele to decide if we should consider this at all but yeah, if we do maybe doing something smarter would be good.
<pedronis> yes, I think we touch this, it's better to the work, it shouldn' be too hard to something sensible, it will need more than 1 line though
<mvo> pedronis: shall I close it given that it need to be reworked?
<mborzecki> btw. devicemgr seems to dtrt, maybe it's enough we add error wrappers for other managers and still log it in stateengine?
<mborzecki> xerrors would be nice too
<mup> PR snapd#8688 closed: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8688>
<mborzecki> it captures the frame info so we'd have exact line in the manager
<mvo> mborzecki: nice
<mup> PR snapd#8688 opened: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688>
<pedronis> mborzecki: I'm not sure I want to invest in xerrors atm
<pedronis> I pressed close by mistake
<pedronis> mvo: you want to land these things in 2.45 I imagine?
<mvo> pedronis: yeah, mostly to give us slightly better error reporting. I know it's not ideal but it seems not like a step backwards and we can always improve it
<mvo> pedronis: I care less about 8687
<mvo> pedronis: the other one 8688 is a bit more interessting I feel because I noticed when we ask for logs for install failure we tend to lack information
<mvo> pedronis: anyway, up to you - I totally understand if you prefer something better that is less "ad-hoc"
<pedronis> mvo: I have a old PR to address that, doing the right thing is quite a bit of work
<pedronis> though, it's probably time to do it, but not 2.45
 * mvo nods
<mvo> pedronis: for which one do you have a PR? or for the stateengine errors one?
<mvo> s/or//
<pedronis> for logging task errors
<pedronis> it's a PR from 2016 to give you a sense of things
<mborzecki> 8688 would be nice, it was super annoying debugging why install failed when running with too small image, there was no other way but to use the debug shell, not sure if even https://github.com/CanonicalLtd/subiquity/pull/771 will be enough
<mup> PR CanonicalLtd/subiquity#771: console-conf-wrapper: show snapd log during install <Created by mvo5> <https://github.com/CanonicalLtd/subiquity/pull/771>
<mvo> pedronis: woah :) ok
<mvo> mborzecki: 771 will be enough but I still think it would be nice to have task error in our log but again, I will not fight over this
<pedronis> mvo: to be clear, I'm not against the logging, the biggest issue is what to log
<pedronis> summaries are long, task numbers are not informative
<pedronis> I'm not sure all summaries are complete enough
<pedronis> the latter is less of an issue
<mvo> pedronis: right - I was thinking about this too and it seemed like the summary is usually ok but yeah, it's not ideal in all cases.
<mborzecki> mvo: i see xnox raised the same issue, i think there's a problem when snap watch/change is called to early
<mvo> pedronis, mborzecki fwiw, I created an image too small to install and tested all my changes against that to see if my changes improve the error/log output
<mvo> mborzecki: yes, I need to look, it did not happen in my testing but I was probably lucky
<mvo> mborzecki: for me it was the other way around actually, usually install-system was already done in the error case by the time this code was reached, but again, I think there is no gurantee :/
<mvo> mborzecki: I need to think
<mvo> pedronis: I think you raise an important point, *if* we log the task error we probably need the id there too for cross reference at least. my pr is not doing this right now
 * mvo shuts up for a couple of minutes to give others the chance to talk too :)
<pedronis> mvo: we don't display task numbers though usually
 * mvo nods
<mup> PR snapd#8680 closed: tests: port interfaces-autopilot-introspection to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8680>
<zyga> brb
<mup> PR snapd#8684 closed: tests: add a note about broken test sequence <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8684>
<mborzecki> mvo: in the context of https://bugs.launchpad.net/snapd/+bug/1878943 it'd be nice if we made use of the timinigs we have in the install-system handler
<mup> Bug #1878943: armhf core20 image unusable on rpi2, rpi3 <uc20> <snapd:New> <https://launchpad.net/bugs/1878943>
<mborzecki> mvo: there's still a question how to show the timings before reboot
<pedronis> mvo: I made a proposal
<pedronis> in #8688
<mup> PR #8688: [RFC] state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8688>
<pstolowski> pedronis: i'm in the HO
<mborzecki> mvo: do you think we could cherry pick https://github.com/snapcore/snapd/pull/8580 to 2.45.1?
<mup> PR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8580>
<mborzecki> i'll distro patch it in arch and fedora for now
<mborzecki> mvo: i can open a PR with relevant patches for 2.45 branch
<mup> PR snapd#8691 opened: tests/lib/bin: a TODO to improve the naming and uniformatiy of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
<mvo> mborzecki: yeah, let's cherry-pick the zsh
<mvo> mborzecki: let me look
<mup> PR snapcraft#3130 closed: build providers: don't show an error if there are no auto-refresh changes <bug> <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3130>
<mup> PR snapcraft#2843 closed: snap: only ship .pyc files, strip shared objects <Created by om26er> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2843>
<mup> PR snapd#8690 closed: devicestate: do not report "ErrNoState" for seeded up <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8690>
<mborzecki> hmm i cannot open files via xdg-desktop-portal anymore in 2.45
<mborzecki> maj 18 15:40:27 galeon xdg-desktop-por[466975]: g_desktop_app_info_get_string: assertion 'G_IS_DESKTOP_APP_INFO (info)' failed
<mborzecki> maj 18 15:40:27 galeon xdg-desktop-por[466975]: g_app_info_launch_uris: assertion 'G_IS_APP_INFO (appinfo)' failed
<ijohnson> oh no
<mborzecki> (on arch)
<mborzecki> pff, zip/pdf/directories open fine though
<mborzecki> graphical files do not
<mborzecki> they do open outside of snap tho
 * zyga -> lunch
<cachio> zyga, we need google-compute-engine  availlable for fedora-32 https://paste.ubuntu.com/p/V58T6xCv3v/
<zyga> cachio: where is that package coming from?
<cachio> Pharaoh_Atem, hey, you are the owner of the google-compute-engine package in fedora right?
<zyga> that's a copr repo
<zyga> perhaps we don't need it?
<cachio> zyga, I think Neal owners it
<zyga> cachio: no, he owns the copr we use to get it from
<zyga> cachio: perhaps we don't need the copr at all?
<zyga> cachio: or perhaps the package in general
<cachio> zyga, ah, ok, I'll try
<zyga> cachio: does the stock f32 cloud image have this package installed?
<cachio> zyga, let me check
<cachio> zyga, seems to be installed
<zyga> great, then we don't need anything, just use that
<zyga> (no need for copr)
<cachio>  zyga, yes, now creating the image again
<zyga> sounds good
<pedronis> mborzecki: in your chain of PRs when did you plan to create systems.go ?
<mborzecki> pedronis:  it's in this one: https://github.com/snapcore/snapd/pull/8689
<mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<pedronis> mborzecki: ok, thx
<MattJ> Curious if there is a reason /snap/bin is added in profile.d only, and therefore isn't added to non-interactive sessions?
<MattJ> e.g. snap install aws on server, then `ssh user@server aws` fails with 'command not found'
<pedronis> mborzecki: I reviewed #8672 and #8686
<mup> PR #8672: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672>
<mup> PR #8686: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686>
<mup> PR snapd#8692 opened: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
<pstolowski> pedronis: ^ this seems to be sufficient. i can do ConfGetter change separately, didn't do it in this PR as it would create noise in the diff
<pedronis> pstolowski: as I said it matters less
<pedronis> pstolowski: I will look at it in a bit
<mup> PR snapcraft#3131 opened: plugin handler: debug build commands if developer debug enabled <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3131>
<mborzecki> pedronis: thanks!
<pedronis> ijohnson: thanks for setting up a meeting
<ijohnson> pedronis: sure let me know if there's anything I can do to help or if we should try and pull in somebody from cloud-init
<pedronis> ijohnson: don't think so, I'll try to prepare a bit in my morning
<ijohnson> ack
 * cachio lunch
<pedronis> ijohnson: I did a pass on #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>
<ijohnson> thank you looking now
<zyga> cachio: hey, can you please update the tw image
<zyga> cachio: a "zypper dup" is enough to resolve our issue
<zyga> cachio: I could bake it into the prepare section but I think this is just better
<mup> PR snapd#8685 closed: opensuse: zypper --replacefiles <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8685>
 * zyga EODs
<ijohnson> pedronis: hmm while looking for documentation on the format of DM_UUID and/or the dm/uuid sysfs value it seems that we may have a slight problem
<ijohnson> according to some of the back and forth on https://bugzilla.redhat.com/show_bug.cgi?id=1322110, the DM_UUID is meant to be an implementation detail and ought not to be parsed because it could be broken at any time
<ijohnson> now that may be true generally, but I'm wondering if we can rely on it for now because 1) we are in control of the thing creating the volume (snap-bootstrap calling systemd-cryptsetup) , 2) the thing creating the volume is from other software version we kinda control, in that systemd version 245/luks/cryptsetup seems unlikely to bump and change significantly over the lifetime of the core20 snap
<ijohnson> 3) the version of systemd in the initramfs should always match what's in the core20 snap I think(?)
<cachio> zyga, sure, I am finishing fedora 32
<ijohnson> so all the things poking / creating this device mapper volume (which is where the DM_UUID value comes from) should be stable over the lifetime of uc20/core20 I think
<ijohnson> if that's not good enough then I will need to seriously think about how we can re-write this code, and moreover why we do not have the additional udev params that we expect in the initrd
<cachio> zyga, in 10 minutes will be ready
<cachio> and Ill fix tw
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8685#issuecomment-630315807 what do you mean by unlucky snapshot? does it install the latest aviablel go version (eg. go1.14) or rather the `go` package in version 1.12.sth?
<mup> PR #8685: opensuse: zypper --replacefiles <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8685>
<cachio> Saviq, hey, are you using fedora 28 and 29 images for testing?
<cachio> Saviq, we want to rmemove them
<cachio> Saviq, is it ok for you?
<Saviq> cachio: remove away https://github.com/MirServer/mir/blob/master/spread.yaml#L5
<cachio> sergiusens, same question for you
<sergiusens> cachio: we do not.
<cachio> Saviq, good, hopefully we will have fedora 32 today
<sergiusens> feel free to remove
<cachio> sergiusens, thanks
<mup> PR snapd#8672 closed: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8672>
<pedronis> ijohnson: well we either parse the uuid, or we call cryptsetup status <device-mapper-name> and parse the output
<ijohnson> pedronis: which do you think we should do? As I said it seems unlikely that the dm uuid will change for the lifetime of uc20, but then again it could since upsteam devs don't think it's meant to be inspected
<pedronis> ijohnson: it's probably easier to use cryptsetup status, otoh the output doesn't seem super machine friendly (differently for other tools it doesn't seem a way to control the output format)
<ijohnson> let me boot into the initrd and see how the output looks there
<ijohnson> pedronis: let me boot into the initrd to see how it looks there
<mup> PR snapcraft#3132 opened: go v1 plugin: warn when using go.mod and go < 1.13 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3132>
<ijohnson> pedronis: after some other new hurdles I learned about (now I have to always also re-build pc gadget to test initramfs changes), I now find that cryptsetup isn't even in the initramfs
<ijohnson> afaict we only have systemd-cryptsetup which doesn't understand the "status" argument
<pedronis> ijohnson: no, it can only setup things, so much fun
<ijohnson> yep!
<pedronis> ijohnson: let's pursue the parsing to unblock us, and then reconsider this I suppose
<ijohnson> pedronis: ok, I will add a TODO to the code about sorting this out perhaps
<mup> PR snapd#8693 opened: tests: adding fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
<cachio> zyga, ~
<cachio> tests breacking on fedora 32
<cachio> zyga, https://paste.ubuntu.com/p/vfQqBG2SCG/
 * cachio afk
<pedronis> ijohnson: are you now unblocked on what to do with #8683 ? also if you think is risky keep reading the dm files directly
<mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<ijohnson> pedronis: yes I'm unblocked I will address your comments
<pedronis> ok, thx, going to call it a day
<ijohnson> sounds good, talk to you tomorrow
#snappy 2020-05-19
<mborzecki> morning
<mup> PR snapd#8695 opened: data/completion, packaging: cherry-pick zsh completion (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8695>
<mup> PR snapd#8696 opened: packaging/arch: update PKGBUILD to match one in AUR <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8696>
<mborzecki> mvo: hey
<mborzecki> mvo: opened a cherry-pick of zsh completion: https://github.com/snapcore/snapd/pull/8695
<mup> PR #8695: data/completion, packaging: cherry-pick zsh completion (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8695>
<mborzecki> mvo: looks like we need the mount-ns fixes in 2.45 branch
<mborzecki> mvo: i believe the fixes are: https://github.com/snapcore/snapd/pull/8666 and https://github.com/snapcore/snapd/pull/8669
<mup> PR #8666: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8666>
<mup> PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669>
<zyga> o/
<pstolowski> morning
<mborzecki> zyga: pstolowski: hey
<mvo> hey zyga, pstolowski and mborzecki
<mup> PR snapd#8688 closed: state: log task errors in the journal too <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8688>
<mvo> 8604 needs a second review please :)
<mup> PR snapd#8695 closed: data/completion, packaging: cherry-pick zsh completion (2.45) <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8695>
<zyga> +1
<mborzecki> pstolowski: https://github.com/snapcore/snapd/pull/8692#discussion_r427101228
<mup> PR #8692: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
<pstolowski> mborzecki: thank you
<mborzecki> pstolowski: maybe we could siplify that even further
<pstolowski> mborzecki: what do you mean by whitelist and not using tags?
<mborzecki> pstolowski: instead of building snap command with -tags nomanagers, you could check which overlord packages are imported, we know that overlord/state and overlord/auth are needed (for debug state and macaroons iirc) so those are the whitelist, everything else should throw an error
<pstolowski> mborzecki: but how? we need to import configcore, it just needs conditional build to exclude certain parts
<pstolowski> mborzecki: this dependency is introduced in my other PR
<mborzecki> aaah ok
<pstolowski> mborzecki: for that reason the simple dependency check will not work either
<mborzecki> pstolowski: which is the other pr?
<pstolowski> mborzecki: the spread test will be updated to check if packaging was done right (in followup(s))
<pstolowski> mborzecki: #8533. the conditional build will fix selinux denials there
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> mborzecki: this is where we pull configcore from snap prepare-image: https://github.com/snapcore/snapd/blob/055397eb7bb37699ebe4ab885b378d3160771392/image/image_linux.go#L436
<mborzecki> pstolowski: btw. have you checked the size of snap binary with that branch?
<mborzecki> pstolowski: uhh, looks like it's importing every package found in overlord now? https://paste.centos.org/view/9964d6af
<pstolowski> mborzecki: i haven't check the size, will do in a moment, going to do packaging changes
<pstolowski> mborzecki: these imports are from current master, or from #8533?
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> mborzecki: nb snap bootstrap will benefit too
<mborzecki> pstolowski: isn't this import problem happening only because of devicestate.CanManageRefreshes() in configcore/refresh.go?
<pstolowski> mborzecki: i'm not sure, i haven't tracked it down precisely. nonetheless we want to eradicate all managers (i think snap bootstrap size is one of the main concerns)
<mborzecki> fwiw snapd package is full of bit fat binaries already, tried to fixed that via symlinking of snap to snapd (also the imports would not be a concern in such setup)
<mborzecki> pstolowski: snap is 20MB, with 8533 it's 21MB, snapd is 25MB, s-b is 16MB
<pstolowski> mborzecki: mhm, interesting numbers
<mborzecki> pstolowski: commented out devicestate.CanManageRefreshes() and the devicestate import in configcore, then proxy.go imports assertstate, but that's no fs-only-option either
<mborzecki> pstolowski: maybe it'd make sense to make the split with a tag in configcore rather than individual managers?
<mborzecki> pff nvm
<mborzecki> pstolowski: it's what you have in your latest change ;)
<mborzecki> apparently i need a coffee
<pstolowski> mborzecki: ok, good, i got very confused by this last remark ;)
<pstolowski> having fun with debian packaging now ;)
<zyga> pedronis: hi, IIRC you hinted at dbusutil package, did you mean a new top level or something else?
<pstolowski> mborzecki: thanks for the review!
<mborzecki> zyga: found some scripts that cachio is using: https://github.com/snapcore/snapd/pull/8693#issuecomment-630692280
<mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
<pedronis> zyga: would it contain only testing stuff atm
<pedronis> ?
<zyga> Not only, looking at the current code I would put isSessionBusLikelyPresent and the associated mocking code
<pedronis> zyga: then yes, a top-level dbusutil (I want to move all *util under some package at some point but not immediately)
<zyga> Ok, will do
<zyga> Should I also move the relevant test code from testutil to something like dbusutil/dbustest?
<zyga> It would be the non trivial dbus call testing stack
<pedronis> yes
<zyga> Great, on it
<pedronis> mborzecki: mvo: #8675 needs a 2nd review
<mup> PR #8675: osutil: add disks pkg for associating mountpoints with disks/partitions <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8675>
<mborzecki> i'll take a look, already got it opened in a tab since yday
<pedronis> mborzecki: thx, I did a pass on 8686 btw, there's a question there
<zyga> I need to do a small errand. Back in 45
<zyga> Itâs such a sleepy day that some air will help
 * mvo is in a meeting
<mup> PR core20#60 opened: Copy-in launchpad's build-archive <Created by xnox> <https://github.com/snapcore/core20/pull/60>
<mup> PR snapd#8678 closed: tests: port interfaces-contacts-service to session-tool <Test Robustness> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8678>
<zyga> Thanks guys
<zyga> Making progress on tests for dbus bits
<zyga> And perhaps pressure is better as Iâm not so sleepy anymore
<mup> PR snapd#8679 closed: tests: port interfaces-location-control to session-tool <Test Robustness> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8679>
<zyga> Also, it must be spring because look at those green tests :-)
 * mvo hugs zyga 
<mup> PR snapd#8697 opened: [RFC] packaging: build cmd/snap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<ogra> xnox, sil2100, we have some serious probs with customers not being able to diable console-conf anymore ... when you guys removed the --disable-console-conf option in ubuntu-image you only did that for core20 builds, didnt you ?
<xnox> ogra: that is correct. What is customer building? UC20 or 18/16?
<ogra> 18 ... but on a 20.04 host machine it seems
<xnox> ogra: what is the snap revision of ubuntu-image the customer is using?
<xnox> Or are they using the deb?
<ogra> xnox, apparently the deb (for whatever insane reason)
<mup> PR snapd#8696 closed: packaging/arch: update PKGBUILD to match one in AUR <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8696>
<ogra> (they are using 1.9-20.04 ... but i think we need to ask them to not use the deb anyway ... why is that still in the archive ? it will cause the same problems we have since yeats with the snapcraft db)
<ogra> *deb
<ogra> *since years
<xnox> ogra: because we still use it to build production images.
<xnox> And we have snap haters too.
<ogra> fix that and make them use the snap ;)
<ogra> there cant be snap haters n canonical :P
<roadmr> ð¤­
<xnox> ogra:  so
<xnox> ogra:  https://paste.ubuntu.com/p/zFMWpCqd2D/
<pstolowski> mvo: these 3 checks: https://github.com/snapcore/snapd/blob/80c895a0216cee4116826be5ceda8fa2791d7f97/packaging/ubuntu-16.04/rules#L179
<xnox> ogra:  ubuntu-image snap has --disable-console-conf option; the deb does not yet have it. As we update the snap more often.
<xnox> ogra:  but it might depend on channels too, I'm running latest/edge
<xnox> ogra:  let me check if stable has that option at all
<ogra> xnox, yeah .. they tried the snap before and switched to the deb because the stable snap was lacking the option ... heh
<ogra> probably time for a release to stable :)
<xnox> ogra:  but deb doesn't have it either.... so..... ?
<ogra> right, then they started to use a script to modify the image on the fly during build ... and then hell broke loose :)
<xnox> sil2100:  when will new ubuntu-image get released?
<ogra> now pointing them to the edge snap should fix them ...
<xnox> ogra:  beta has it too
<ogra> yeah
<xnox> stable|candidate do not
<xnox> deb does not
<ogra> yup ...
<xnox> 1.9+snap3 is the one they want for now
<xnox> ogra:  please test & ask for version numbers, before escalating next time =)
<ogra> i was only asking ... not "escalating" ... :)
<sil2100> xnox: yes
<sil2100> ;)
<sil2100> (I know that is not the answer to the question)
<sil2100> Seriously speaking, I talked with Samuele and Michael and I will be releasing the beta UI to stable soon, probably after my +1 maintenance shift
<mup> PR snapd#8674 closed: tests: fix nested tests  <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8674>
<mborzecki> does github work for you guys?
<mborzecki> i can't fetch or push anything
<ijohnson> mborzecki: seems fine to me
<ogra> works fine for me .... tried to re-connect the caonical VPN ?
<ogra> that hangs at times for me
<cachio> ijohnson, hey, which is the other step I need to do after re-sign the kernel?
<ijohnson> cachio: you need to re-build the gadget snap, signing shim with the snakeoil keys
<ijohnson> cachio: to do that, you need the snakeoil dir from this git repo: https://github.com/snapcore/pc-amd64-gadget/
<ijohnson> then unpack the pc gadget snap and run this:
<ijohnson> https://www.irccloud.com/pastebin/IgmkHoBY/
<cachio> ijohnson, I am using sbsign --key /etc/ssl/private/ssl-cert-snakeoil.key --cert /etc/ssl/certs/ssl-cert-snakeoil.pem
<cachio> currently to sign the kernel
<ijohnson> cachio: ok, I think the snakeoil keys from /etc/ssl are the same as from the gadget
<cachio> ijohnson, should I use the cert and key provided by the gadget?
<ijohnson> let me double check that they are the same
<cachio> ijohnson, thanks
 * zyga -> lunch
<ijohnson> cachio: hmm no the snakeoil key is different it seems, so I think you need to sign shim with the keys from the gadget dir
<ijohnson> cachio: when you sign the kernel, are you signing the kernel.efi ?
<cachio> ijohnson, yes
<cachio> which key and cert should I use?
<ijohnson> cachio: are you using the ubuntu-core-initramfs package to create the efi?
<ijohnson> i.e. are you running `ubuntu-core-initramfs create-efi` ?
<cachio> yes
<ijohnson> cachio: ok, so that is doing the same thing I am doing so you should be okay
<cachio> ijohnson, nice, thanks, I'll try that and re-test
<ijohnson> cachio: as long as you are not doing anything different from `ubuntu-core-initramfs create-efi` you should be good
<cachio> thanks for the help
<ijohnson> yeah np, let me know if you run into any more issues
<cachio> ijohnson, sure
<ijohnson> zyga: any idea why this check was "skipped" ? https://github.com/snapcore/snapd/pull/8683/checks?check_run_id=688936733
<mup> PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<zyga> yeah, I clicked twice
<zyga> and I cancelled a run
<zyga> that's a stale marker of some kind
<zyga> note that actual tests did run
<ackk> sergiusens, hi, I'm seeing a strange behavior wrt the rbac snap on core20. it works fine when installed on focal, but I get  https://paste.ubuntu.com/p/zNNJPdpSh5/ in a bionic container
<ackk> sergiusens, both on snapd 2.44.3
<zyga> ackk: any python native code?
<ackk> zyga, possibly, why?
<zyga> ackk: classic confinement?
<ackk> zyga, it's a fully confined snap, FTR
<zyga> ackk: different so versions, won't import
<zyga> just guessing
<ackk> zyga, "snaphelpers" doesn't use native code
<ackk> zyga, I just tried in a snap run --shell, trying to import that from python cli also fails
<zyga> Strace it perhaps
<cjp256> ackk: can you share the yaml?
<cjp256> i'm guessing you'll need to set PYTHONPATH for your runtime environment
<cjp256> ackk: e.g. https://github.com/snapcore/snapcraft/blob/master/tests/spread/plugins/v2/snaps/python-hello-with-stage-package-dep/snap/snapcraft.yaml#L15
<ackk> cjp256, I updated https://bugs.launchpad.net/snapcraft/+bug/1876370
<mup> Bug #1876370: Python libraries installed by python path are not found in sys.path <Snapcraft:New> <https://launchpad.net/bugs/1876370>
<roadmr> hey folks, - what happens if I install a snap that has an auto-alias that conflicts with an existing command on the system? does the snap's take precedence? does the deb-installed one? does snapd refuse to configure the conflicting alias?
<cjp256> ackk: out of curiosity, if you don't filter out files, do you get the same result? the bionic vs focal is interesting
<ackk> cjp256, haven't tried, let me
<cjp256> ackk: also consider staging all of python and see if that changes things: https://github.com/snapcore/snapcraft/blob/master/tests/spread/plugins/v2/snaps/python-hello-staged-python/snap/snapcraft.yaml
<ackk> cjp256, well that's what we did before, but it'd be nice not to have now that snapcraft supports using the builtin one
<cjp256> ackk: this is a strict snap, right?
<ackk> cjp256, correct
<pedronis> roadmr: it's the same as what happens with snap that have a name that matches a system command, snapd will install the snap. The precedence depends on PATH, as set by default snaps are searched after system commands.
<roadmr> thanks pedronis
<cjp256> ackk: i'll see if can repro on 18.04
<pedronis> roadmr: we check for conflicts among snaps, but not with the system commands
<roadmr> pedronis: right, I knew about inter-snap checking but was unsure about existing command behavior
<roadmr> asking for a friend :)
<ackk> cjp256, it's unfortunaly not a public snap, so I can't share the code here
<cjp256> with my own attempt at a reproducer anyhow
<ackk> cjp256, same issue without filtering files
<cjp256> ackk: i cannot reproduce on bionic.  if you want, you can gmail me the full yaml and i can give it a shot
<mvo> maybe one system is not marked as mandatory, let's see what spread says to this PR
<pedronis> ah
<witquicked> I'm struggling to get snapd to run inside an Ubuntu 18.04 docker container without having run that container in "privileged" mode. I've succeeded when the Docker host is Arch Linux, but am having issues when the host is also Ubuntu. The error is "main.go:123: system does not fully support snapd: cannot mount squashfs image using "fuse.squashfuse": fuse: mount failed: Permission denied"
<cachio> pedronis, mvo I tested that with "secureboot: true" and workerd
<witquicked> actually, scratch that, it's not working on Arch Linux anymore either...
<zyga> witquicked: hey
<zyga> witquicked: docker is not a supported snapd host IIRC
<zyga> witquicked: if you need a container and can use lxd instead, that should work
<cachio> mvo, do you have a link to the change where secure boot is not wortking?
<pedronis> cachio: I misunderstood the conversation claudio had with Gustavo
<pedronis> I thought the change landed in spread with the preferred syntax
<pedronis> but seems not
<pedronis> mvo: for your benefit, this is the spread part: https://github.com/snapcore/spread/pull/104/files
<mup> PR spread#104: Adding option for systems created on google to start with secure boot enabled <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/spread/pull/104>
<pedronis> there's a comment about the syntax by Gustavo
<witquicked> zyga, I know it's not officially supported, and that I'm fighting an uphill battle. I have successfully gotten it working several times, using various mount points...
<zyga> witquicked: I think it's a waste of your time, unless you have absolutely no other choice
<mvo> pedronis, cachio aha, htanks
<witquicked> I have a reasonable use-case for it...
<mup> PR snapd#8698 closed: spread.yaml: secureboot is really secure-boot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8698>
<zyga> witquicked: can you use lxd instead? that's a really easy way out
<pedronis> mvo: anyway it means something else failed
<pedronis> which isn't great either
<zyga> witquicked: if you absoulutely must use docker you are on your own as we don't support that and there will be random things you need to do each time that may or may not work
<zyga> witquicked: you need systemd and ability to mount squashfs (probably via fuse)
<cachio> pedronis, good, thanks
<witquicked> zyga, yep...
<witquicked> like I said, I can get it to work using the "privileged" command, so I know it's within the realm of possible
<zyga> witquicked: I don't know what that does in docker
<witquicked> and yes, I've done the work needed to get systemd to run inside Docker
<zyga> and if doing so is not messing up your system
<witquicked> that switch essentially allows the container to run as root.
<zyga> witquicked: out of all containers we only support lxd because it does apparmor nesting
<zyga> witquicked: it seems you are saying this is not a container anymore
<pedronis> mvo: anyway indeed store problems
<zyga> witquicked: if you do this it may appear to work but may actually break something on your host
<pedronis> mvo: making the PR red atm
<pedronis> PRs
<zyga> witquicked: and it may totally break if you run more than one "container" like that at the same time
<mup> PR snapd#8699 opened: interfaces/desktop-launch: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/8699>
<witquicked> zyga, I have multiple use-cases for running systemd in a container. The one that sidesteps the religious discussion is that I use the container for testing ansible playbooks...
<zyga> witquicked: systemd is probably not the problem
<zyga> witquicked: I'm specifically talking about snapd
<zyga> witquicked: (where "probably" is more of a I don't know)
<witquicked> zyga, agreed, it's not systemd. Fair enough. :)
<zyga> witquicked: but snapd will for sure misbehave and, given the chance, change the host, not the container
<zyga> I think we are talking in circles now, I can only wish you good luck
<zyga> witquicked: I'm sorry but we cannot support docker without docker growing more features
<witquicked> Actually, what you said about snapd changing the host is very helpful...
<zyga> witquicked: or someone writing a docker helper that lets you run more complex things
<witquicked> Are the changes you're referring to in "/sys/fs/fuse/connections", or "/sys/fs/cgroups", or the socket?
<zyga> witquicked: snapd loads apparmor profiles
<zyga> witquicked: apparmor is not namespaced
<zyga> witquicked: without special setup that is clobbering the host apparmor configuration
<witquicked> aha, but it can run without apparmor, yes?
<zyga> witquicked: snapd?
<witquicked> yes
<zyga> witquicked: yes but all security promises are gone then
<zyga> witquicked: at which point the question of what the docker container brings is questionable
<witquicked> yes, I'm aware - and apparmor is shipped to not start in a container...
<zyga> witquicked: if you entirely trust the payload that might work to some extent
<zyga> witquicked: it's not just the container, if your kernel has apparmor snapd will sue it
<zyga> *use it
<witquicked> Yeah, it's definitely pushing the boundaries of what it means to be a container...
 * zyga wonders what's the requirement
<witquicked> oh rilly?
<zyga> building in "docker"
<zyga> where it means that docker is the entry point and that's all
<zyga> ?
<witquicked> the requirement is to be able to test ansible playbooks in a "somewhat" isolated and repeatable environment
<zyga> I see
<zyga> and how does that interact with snapd? ansible setting up snaps?
<witquicked> it's also used to support a build environment, where the setup of that environment uses snap to install tools
<zyga> I know it's a big shift but lxd actually properly support sthat
<zyga> especially if you want to test something that feels more like a real system
<zyga> alternatively a vm as running in a container and out of a container does matter for both snapd and lxd
<witquicked> That's true
<witquicked> I know and love lxd, and it would be my first choice... however I need for this to support Linux, Mac and Windows hosts.
<zyga> I understand
<zyga> my only comment is that it's not testing something that looks like a normal system
<zyga> so the test may say "great, it works"
<zyga> but reality will be different
<witquicked> I see your point.
<witquicked> And it's absolutely valid... you're basically saying that any test that works without apparmor turned on isn't really a valid test.
<zyga> it depends
<zyga> for some snaps it might be okay
<zyga> it's just not something that I would say is a good test
<zyga> it's like a test that says "echo ok" is both fast and portable
<zyga> and it passes too
<zyga> but that's not the goal
<cachio> cmatsuoka, I see, I'll fix it
<cmatsuoka> cachio: thanks
<ogra> jdstrand, hmm, i'm playing with the account-control interface ... is there a chance we could get permission to "mkdir /home/$USER" ? it is kind f hard to create a valid user account with the interface the way it is atm
<ogra> (indeed it works if i tel useradd to not create/use a homedir, but thats kind of crippled in the end)
<jdstrand> ogra: I'll look into it as part of my 2.45 policy updates work. I think there is context I need to dig up
<ogra> thx !
#snappy 2020-05-20
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/8686 ?
<mup> PR #8686: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8686>
<mvo> mborzecki: sure
<mborzecki> mvo: thanks!
<mup> PR snapd#8686 closed: o/devicestate: cleanup system actions supported by recover mode <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8686>
<mborzecki> yay
<pstolowski> morning
<pedronis> zyga: hi, could you complete the comment #8123? is the only thing stopping it from landing
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> Good morning
<zyga> pedronis: certainly, in a moment
<pedronis> mvo: should we land #8682 and change the pattern after? or do you prefer it changed first?
<mup> PR #8682: tests: port interfaces-password-manager-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8682>
<zyga> Smak conflict there, lets resolve it
<mvo> pedronis: either way is fine
<mvo> pedronis: let's land as it will make tests better
<mvo> landed
<mup> PR snapd#8682 closed: tests: port interfaces-password-manager-service to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8682>
<pedronis> anyway there's the other one that needs some tweaks
<pedronis> still
<pedronis> mborzecki: hi, I re-reviewed #8689
<mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<mborzecki> pedronis: thanks, i'm merging master and will address those in the next batch of patches
<pedronis> mborzecki: zyga: the fedora failure here is interesting: https://github.com/snapcore/snapd/pull/8692
<mvo> I will push a new test-snapd-with-configure{,-core18} to edge, should not affect anyting but if you notice anything strange please let me know and I can revert
<mup> PR #8692: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
<zyga> looking
<pedronis> mborzecki: zyga: the cleanup is confusing snap.rootfs_* for a snap
<pedronis> a bit unclear why there's one around but never the less
<zyga> hmmm
<zyga> the snap.rootfs_ pattern is unusual to persist
<zyga> something has failed earlier and left it there
<mborzecki> btw. https://github.com/actions/cache/issues/208 is fixed
<mborzecki> mvo: ^^
<zyga> oooo
<zyga> good :)
<mborzecki> we should be able to revive the issue with caches
<mborzecki> s/issue/PR/
<zyga> 2020-05-20T06:18:51.4079959Z `-/tmp/snap.rootfs_9l42OX    /dev/sda1[/tmp/snap.rootfs_9l42OX] ext4       rw,relatime,seclabel                                                           shared
<mvo> mborzecki: holly cow
<mvo> mborzecki: let me update my PR
<zyga> yeah, this is curious
<zyga> I can only say this
<zyga> at some point snap-confine -> snap-* startup sequence failed
<zyga> this is the only possibility of a leftover /tmp/snap.rootfs_ mount point
<zyga> I have two simple ideas: we can add an invariant check to detect those and fail early
<zyga> probably a good idea in general
<pedronis> pstolowski: mvo: I think #8692 can be either force merged or it needs another run
<zyga> and we can also change the temporary directory name to contain the snap name
<mup> PR #8692: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <https://github.com/snapcore/snapd/pull/8692>
<zyga> but probably not so useful because we use test-snapd-sh a lot so it may be less revealing than a failure at a specific test
<zyga> I'll finish with conflicts and then look at this
<mvo> pedronis: I can force merge, let me look at the failures
<mup> PR snapd#8692 closed: configcore: add nomanagers buildtag for conditional build <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8692>
<pstolowski> mvo: thanks
<zyga> for the first time I resolved a mount-ns test conflict manually
<pedronis> pstolowski: there are some comments in #8697
<mup> PR #8697: [RFC] packaging: build cmd/snap with nomanagers tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/8697>
<pstolowski> pedronis: yes, i've been adressing them (almost done), except for your last comment
<mvo> I resurrected 8508 let's see how that goes
<pedronis> pstolowski: thx
<mup> PR snapd#8631 closed: image,cmd/snap,tests: add support for store-wide cohort keys <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8631>
<zyga> hmmm
<zyga> mup: ping
<mup> zyga: Roses are red, violets are blue, and I don't understand what you just said.
<zyga> so mup responds
<zyga> is github down?
<zyga> no...
<zyga> weird
<zyga> I cannot git-push
<zyga> dns works
<zyga> wth?
<zyga> mborzecki: can you git push anything to gh?
<zyga> or maybe even git fetch
<mborzecki> zyga: yup, but had some problems fetching/pushing yesterday afternoon too
<zyga> I cannot add comments either
 * zyga reboots
<zyga> rebooted
<zyga> git push hangs
<zyga> ssh hangs on
<zyga> debug1: Connecting to github.com [140.82.118.4] port 22.
<zyga> what does github.com resolve on your machine mborzecki ?
<mborzecki> zyga: 140.82.114.3 atm
<zyga> hmmm
<zyga> same result
<zyga> sigh
<zyga> what a morning
<mup> PR snapd#8702 opened: overlord/configstate: add log-control option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8702>
<zyga> gah
<zyga> any ideas
<zyga> it works :)
<mvo> zyga: 8578 looks ready - does it need jdstrand first or can I merge?
<zyga> checking
<mvo> zyga: hrm, I guess it does need him?
<zyga> yeah, I think he wanted to see it
<pedronis> mvo: should we turn all the ubuntu-20.04-* in our tests task.yaml to ubuntu-2* ?
<zyga> brb
<mvo> pedronis: I think so
<mvo> pedronis: not sure if zyga replied to my suggestion yet, I don't see a downside
<mvo> (but maybe I'm missing something?)
<zyga> mmm, mvo the one on tests to use 2*
<zyga> I didn't but I think it's a good idea
<mvo> zyga: cool, then we are in agreement
<zyga> but perhaps as a separate pass to do everything in one go
<mvo> sure
<mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/8689 also with some additional checks for non-uc20
<mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<mborzecki> pedronis: i suppose it's ok to assume that there's no explicit system mode in non-uc20
<pedronis> mborzecki: various methods will say we are in run mode?
<pedronis> zyga: mvo: yes, as a separate pass, there's a bunch, also there are core20 nested tests that I think really want 20.04 precisely
<zyga> pedronis: mmm, indeed, I think a simple guideline is that if a test is precise and targets one thing it can stay that way, if it targets subsequent LTSes we can expand that to include 2*
<mborzecki> pedronis: it's in the contxt of system requests on uc16/18, we don't support that and might as well error out early in such case
<pedronis> mborzecki: yes, I'm actually looking at that code
<pedronis> we don't do that anywhere else
<pedronis> I'm not sure it's a good check
<pedronis> mborzecki: which reminds me that the code should use m.SystemMode() and not systemMode much more
<mborzecki> pedronis: it will be blocked later on anyway, so it's ok to drop that
<pedronis> or maybe we should change things to just set systemMode to run
<pedronis> and make SystemMode a straight accessor
<mborzecki> pedronis: yes, it's a bit confusing, otoh knowing when it's != "" gives us a little more insight as it's set only based on modeenv
<pedronis> yes, what something has to give, either we refuse to operate on modeenv without mode
<pedronis> early
<pedronis> or something
<pedronis> right is all a bit not well defined
<pedronis> mborzecki: we never write modeenvs without mode, right?
<mborzecki> pedronis: i don't think we do, but looking at the modeenv code there's no sanity check for Mode != ""
<mborzecki> and tests seem to disagree now that i added such check, heh
<mborzecki> fortunately it's just the test mocks
<pedronis> mborzecki: yea, I think we want the read in boot to fail if no mode
<pedronis> an deal with it
<pedronis> mborzecki: can be a follow up
<pedronis> mvo: thanks for the new test, I added some comments in #8351, I see the newline issue only in the full diff view
<mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<mvo> pedronis: aha, thanks! I misread your comment about the gadget service, I will add that too
<pedronis> #8689 needs 2nd reviews
<mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<pedronis> mborzecki: #8661 is unblocked now, can you do another pass? (I will look myself but later)
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mup> PR snapd#8703 opened: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8703>
<mup> PR snapd#8123 closed: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8123>
<mup> PR snapcraft#3132 closed: go v1 plugin: warn when using go.mod and go < 1.13 <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3132>
<mup> PR snapcraft#3133 opened: go v1 plugin: go.mod support for 1.11 and 1.12 <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3133>
<zyga> pedronis: thanks for merging
<cmatsuoka> cachio: I pushed a fix for PR 8700 but we need to check with zyga if the latest spread is in use
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<zyga> cmatsuoka: thanks, I'll check that now
<cachio> cmatsuoka, checking
<cachio> cmatsuoka, I see the test is failing with
<cachio> panic: cannot seal the encryption key: cannot seal and store encryption key: cannot add EFI secure boot policy profile: cannot compute secure boot policy digests: the current boot was performed with secure boot disabled in firmware
<zyga> updating spread
<cmatsuoka> cachio: yes, it should work after zyga updates spread
<pedronis> cmatsuoka: that's an example of the errors that we need to think now to imrpove
<pedronis> *how
<zyga> our our defense it's much better than random errors from software
<zyga> but we do need to think about how to make a pattern for such errors that is easier to understand
<pedronis> yes, at least in this one most levels add some info (except the first two that feals redundant)
<pedronis> the one I saw the other day was worse
<zyga> that's true
<zyga> at least it's not a backtrace :)
<cmatsuoka> pedronis: in this case the first three are ours and we can clean them up, I'll check that
<pedronis> cmatsuoka: ah, interesting
<mup> PR snapd#8704 opened: cmd/snap-preseed: improve mountpoint checks of the preseeded chroot (1/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8704>
<cmatsuoka> pedronis: the tpm-sealing-in-secboot PR already gets rid of the second level
<zyga> cmatsuoka: done
<cmatsuoka> zyga: thanks!
<cmatsuoka> I restarted the tests, let's see what happens...
<cmatsuoka> zyga: I was playing with the pi4 here, and interestingly it keeps the cpu frequency at the maximum value even idle and with the ondemand governor
<zyga> cmatsuoka: on ubuntu or raspbian?
<cmatsuoka> changing it to conservative made it drop the frequency
<cmatsuoka> it's the current core20 beta
<zyga> I see
<zyga> feels like a bug
<zyga> how do I check the freq?
<zyga> I can check core18 on mine
<cmatsuoka> zyga: yes, please do, I'll check classic too
<cmatsuoka> hmm, interesting, switching back to ondemand now keeps the freq low
<zyga> not sure if that's the right measurement
<zyga> zyga@pi4-1:/sys/devices/system/cpu/cpufreq/policy0$ sudo cat cpuinfo_cur_freq
<zyga> 1500000
<cmatsuoka> root@ubuntu:/home/cmatsuoka# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
<cmatsuoka> 600000
<zyga> I'm on "ondemand"
<zyga> perhaps a kernel bug?
<cmatsuoka> try to switch to powersave and go back to ondemand
<zyga> cmatsuoka: raspbian on a pi0w has the same behavior
<zyga> 1GHz
<cmatsuoka> humm interesting
<zyga> I don't have another pi4 to confirm raspbian semantics there
<zyga> I have a large heatsink with two fans so it's not a problem
<zyga> but perhaps it does save some power
<zyga> I could connect it to my power supply and measure later if you are interested
<cmatsuoka> I'm using a small heatsink with no fans so it tends to heat up a little bit
<cmatsuoka> zyga: yeah, measuring could be interesting -- at least we'll know how well cpufreq works power-wise
<zyga> cmatsuoka: I need to look how to do that, I have a hacked micro cable but not a hacked usb-c cable
<zyga> stgraber: I think lxc file push needs confuses --mode
<zyga> an octal input is doing funny thing
<zyga> jdstrand: some low hanging fruit: https://github.com/snapcore/snapd/pull/8578
<mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<jdstrand> zyga: yes, I'm pivoting to PR reviews later today once I finish the store reviews which are almost done
<zyga> super, thank  you :)
<zyga> it's not urgent
<zyga> just low-hanging
 * jdstrand nods
<zyga> stgraber: s/needs// -- i meant to say that it seems it is confused by what --mode= is supposed to be, giving octal values does funny stuff
<court_jester> What's the difference between #snappy and #snapcraft?
<stgraber> zyga: with our without leading 0?
<zyga> without
<zyga> I think decimal mode is quite unusual so I didn't pass it
<zyga> court_jester: snappy is where most snapd developers talk
<ogra> court_jester, they kind of overlap ... but the fcus here is snapd development, Ubuntu Core development and such
<zyga> court_jester: snapcraft is where the snapcraft developer hang and where loads of people ask questions
<ogra> while the snapcraft channel is for developing snapcraft but also of packaging etc
<zyga> snapd is the package manager, snapcraft is the package builder
<ogra> s/of/for/
<zyga> mvo: should I drop the bitcacher now?
<ogra> take 8 of them and make it a bytecacher ;)
<mvo> zyga: yes please
<zyga> over the parallel port
<zyga> mvo: ack
<zyga> done
<mvo> ta
<zyga> gah
<zyga> I need to reboot again
<zyga> suspend during the standup nuked X input
<zyga> re
<zyga> cmatsuoka: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=274595&sid=05bfd24c66e0458db63482ae20121427
<zyga> ^ also a case for that eeprom update we talked about
<zyga> very tempted to buy a pi4 for testing this
<cmatsuoka> ah intersting
<zyga> pair pi4 with a SSD
<zyga> also case for ubuntu core *installer* that you use to write from sd to other storage
<zyga> I only wish pi4 firmware was open source
<pstolowski> short break, bbiab
 * ogra recommends https://www.amazon.co.uk/dp/B078SVRH4B/ref=twister_B07XTSVFS4?_encoding=UTF8&psc=1 for the pi4 
<ogra> it flies with writable on the SSD (and system-boot on SD)
<cmatsuoka> nice!
<zyga> ogra: thanks!
<zyga> oh, and usb-c too
<zyga> I personally would prefer something that I can fuse into one big enclosure, so that it's not a tangled mess of wires
<zyga> but I think that's very hard with pi design
<ogra> well, you might find cases to print on thingverse
<zyga> yeah, that's true
<zyga> I wish WD kept making those pi-specific usb drives
<zyga> just updated to SSDs now
<zyga> I still have the original set and it is amazing, apart from being a hdd
<zyga> (and the notion of native USB-HDD is fuN)
<ogra> i wish the pi foundation would add an M.2 PCIe socket to the next pi4 interation :)
<ogra> that saves all case issues by simply mounting it to the board itself
<zyga> yeah
<zyga> with pi4 having pci-e anyway, I think it's doable
<zyga> and could be something to put on that bottom side :)
<ogra> i really love the nanopc-t4 for that ... but still having driver issues (it occasionally dies even with BSP kernel snap)
<ogra> (but if it doesnt die ... OMG it is fast !)
<ogra> :)
<cmatsuoka> "tangled mess of wires" is something I'm getting increasingly familiar with
<mvo> zyga: 2020-05-20T12:53:27.3457005Z invariant-tool: system is corrupted - in https://github.com/snapcore/snapd/pull/8703/checks?check_run_id=692478727 maybe that is helpful?
<mup> PR #8703: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8703>
<zyga> mvo: yes!
<zyga> looking
<zyga> fantastic
<zyga> thank you
<zyga> I think it's a red herring here as old snap-confine did not clean some things up
<zyga> but it surely works
<zyga> and I wonder why it only failed here
<zyga> ah, that's the PR introducing it
<zyga> :D
<zyga> I'll adjust the test
<zyga> thanks
<cachio> cmatsuoka, https://paste.ubuntu.com/p/WQ7ZcDKmD5/
<cachio> I see thie error now
<cachio> I'll try to update the fedora image
<cmatsuoka> this error is strange
<cmatsuoka> ah, I think you're trying to create the instance with shieldedInstanceConfig empty
<cmatsuoka> does it make sense?
<cachio> cmatsuoka, I am just sending the parameters list empty when secboot is not enabled
<cachio> as I do with all the systems
<zyga> hmm
<zyga> 2020-05-20 14:49:17 Cannot allocate google:amazon-linux-2-64: cannot allocate new Google server for amazon-linux-2-64: invalid value for field 'resource.shieldedInstanceConfig': ''. Shielded VM Config can only be set when using a UEFI-compatible disk
<zyga> I think the thing we did did not do the thing we hoped it does
<zyga> cmatsuoka: ^
<zyga> does this indicate the spread patch is buggy
<cmatsuoka> cachio: and only fedora didn't like it?
<cachio> zyga, mmm, also amazon-linux
<zyga> this is from upstream spread now failing on our tests
<cachio> zyga, yes
<zyga> it feels like we need to revert something
<cachio> semms to be a gce thing
<zyga> I'll break for lunch and let you figure it out, I can happily deploy updated spread in minutes
<zyga> it seems the setting only works if the image is using UEFI
<zyga> which is sensible
<zyga> spread patch was not tested properly
<cachio> I know the simple fix for spread , but perhaps I can solve it from gce
<cachio> zyga, agree, I just validates that in some systems
<pstolowski> re
<zyga> cachio, cmatsuoka: please get a patch reviewed and ping me for deployment
<cmatsuoka> zyga: ack
<cachio> zyga, I'll update the images first
<cachio> zyga, I think the main problem is how we create the images, but seems to be also a problem in gce, because it doesn't like the configuration parameter even if it goes empty
<cachio> so for fedora we send the parameter empty and gce does not like the parameter
<cachio> I need to fix  that on spread
<cachio> zyga, but first I'll update our images to support uefi configurations
<zyga> cachio: perhaps fixing spread is faster
<cachio> and that is a trivial change
<zyga> there's no telling what happens if we move to uefi boot
<zyga> maybe something else breaks
<cachio> zyga, we are not moving to uefi oot
<cmatsuoka> cachio: I changed your code a little bit and I'll run a test here
<zyga> so what does the image update entail?
<cachio> zyga, the change I am doing is telling to gce that the image now is compatible with uefi, but it does not mean we are going to use uefi
<cachio> zyga, will just allow us to send uefi parameters
<cachio> while the instance is created
<zyga> so are there two knobs in GCE: 1) uefi supported 2) really use uefi to boot?
<cachio> yes
<zyga> weird :)
<zyga> ok
<cachio> uefi suported you set when you create the image
<cachio> boot with uefi you set it when you start the image
<cachio> so you can choose
<cachio> either if you want to boot with uefi or not
<cachio> the same image
<cachio> lets make a try with this change, and then make the update in spread
<zyga> sounds good
<zyga> brb
<zyga> mborzecki: I'll update opensuse today
<zyga> mborzecki: maybe next week we could chat about suse security's group idea
<cachio> zyga, fedora 31 is updated and now boots well
<cachio> I'll run the entire suite to validate there is not side efect
<cachio> zyga, udpating amazon linux now
<zyga> ta
<cmatsuoka> cachio: wdyt about something like https://pastebin.ubuntu.com/p/vtNg3Nx5Gk/ ?
<mvo> mborzecki: probably for tomorrow 8508 is ready but sadly all spread tests worked so we can't test the re-run in a meaningful way
<mvo> mborzecki: still ready for review
<cmatsuoka> cachio: it also addresses some of gustavos comments on your original patch
<mup> Issue core18#153 opened: missing /etc/cloud/cloud.cfg.d/99-snappy-azure.cfg <Created by anonymouse64> <https://github.com/snapcore/core18/issue/153>
 * zyga break to rest from standing
<zyga> more more more tests coming after
<cachio> cmatsuoka, I'll check it
<cachio> in the mean time I already updated fedora and amazon linux images
<cachio> so those are now working again
<cmatsuoka> cachio: it's important to fix spread as well, I suppose we're not the only users
<cachio> cmatsuoka, we I update the images that all use
<cachio> cmatsuoka, but the spread fix is also important
<cachio> cmatsuoka, are you creating a PR with that?
<cmatsuoka> I could, than perhaps you could run some tests on it?
<cachio> zyga, cmatsuoka as retrospective I think we need to be able to run some tests to validate the google backend
<cachio> cmatsuoka, ok, let me test it
<cmatsuoka> s/than/then/
<cachio> cmatsuoka,  in the PR 8700 just failing the ubuntu-secboot system
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<cachio> cmatsuoka, do you know how to fix it?
<cmatsuoka> cachio: is it the secure boot disabled bug? in this case I think we're running the old spread there
<cachio> cmatsuoka, well, we can run the new spread now
<cachio> zyga, is it possible to use the new spread there?
<zyga> where?
<cachio> in the pr 8700
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<zyga> cachio: ?
<cachio> zyga are we using the old spread there?
<zyga> cachio: spread is not specific to a PR
<zyga> cachio: I don't understand your question
<zyga> cachio: since we don't print spread version anywhere it's hard to guess
<cachio> zyga, I misunderstood what claudio said I think
<zyga> cachio: but I've updated spread across all the runners during the standup call
<cachio> zyga, we are using the last spread right?
<zyga> cachio: master
<cmatsuoka> it's interesting, because 8700 fails with the "current boot was performed with secure boot disabled in firmware" error
<cachio> zyga, perfect
<cachio> cmatsuoka, yes
<zyga> when did it fail, was it after the standup?
<cachio> not sure why but I debugged that test and secure boot is enabled
<cmatsuoka> zyga: I restarted the tests after the standup, yes
<zyga> hmmm
<zyga> one sec
<zyga> drat, my fault
<zyga> sorry, updating on nodes other than 1
<cachio> zyga, nice
<cachio> thanks
<cachio> zyga, I need to see if another image needs to be updated
<zyga> cachio: please restart them again
<cmatsuoka> restarted
<cachio> cmatsuoka, I already did it
<cachio> but for everything
<cachio> I need to see if any systems needs to be updated
<zyga> cachio: can you update leap / tw as well please
<zyga> maybe you did earlier
<cachio> I'll need to update some other images as well
<zyga> ok
<kyrofa> Does https://snapcraft.io/build build a new snap for pushes on ANY branch? Or only the default?
<diddledan> only the default IIRC
<kyrofa> Oh, that's unfortunate
<kyrofa> roadmr, can you confirm?
<ijohnson> mvo: reviewed 8661, it has 2 +1's now
<pedronis> ti doesn't need my review I think, but maybe Pawel should give it a quick look
<mvo> ijohnson: I merged your suggestion too, thanks for this
<cjwatson> kyrofa: it's a web team thing
<cjwatson> rather than store team
<kyrofa> cjwatson, ah, I was wondering if I might end up addressing that question to you
<cjwatson> I stopped working on this a year or two ago - definitely owned by the web team now :)
<cjwatson> (I was involved in getting the thing up and running, but not long-term)
<kyrofa> I don't actually know who that is these days, can you point me in the right direction?
<pedronis> time is hard our gdoc thinks monday was the 17
<diddledan> pedronis, well to be fair time is an illusion since we went into lockdown ;-p
<cjwatson> kyrofa: https://github.com/canonical-web-and-design/snapcraft.io/issues probably
<cjwatson> (I don't have names for you)
<kyrofa> Ah, someone there should probably idle here
<diddledan> yeah it'ld be a good idea for someone who maintains the build service to idle around here for questions
<diddledan> or in #snapcraft.. I still haven't worked out how to determine which channel I should be talking in ;-p
<kyrofa> Lukewh, any chance you know everything there is to know about https://snapcraft.io/build?
<ijohnson> pedronis: I think most of those issues are my fault tbh since I'm usually the one to add the new day in the gdoc haha
<pedronis> ijohnson: it's not a serious problem but I was confused for a bit
<zyga> cachio: can you please ping me when all images are up-to-date
<ijohnson> yeah I was quite confused myself when I realized we are not actually in june yet
<cachio> zyga, all of them are updated
<zyga> cachio: ah, excellent
<zyga> cachio: I'll restart a few PRs to see what we get
<cachio> I just retriggered the tests on that PR
<zyga> thanks!
<Lukewh> kyrofa: please file an issue. I need to verify the flow and I'm EODing so it'll remind me to check tomorrow :)
<cachio> I already run a test in all the ysstems to validate it
<kyrofa> Lukewh, will do
<Lukewh> kyrofa: thanks. make sure you say what you'd like to happen and we can see if we can do it
<zyga> mvo: https://github.com/snapcore/snapd/pull/8508#pullrequestreview-415527869
<mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8681#discussion_r428163052
<mup> PR #8681: tests: port interfaces-accounts-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8681>
<zyga> and I'll send a follow up to update tests to cover 2*
<mvo> zyga: thanks, merged
<zyga> thanks!
<mup> PR snapd#8681 closed: tests: port interfaces-accounts-service to session-tool <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8681>
<zyga> mvo: if you have a moment today, pushing forward that caching PR would be great
<cachio> zyga, now I see this error
<cachio> https://paste.ubuntu.com/p/F3Vgw6bp4V/
<zyga> cachio: looking
<cachio> this image didn't change
<zyga> cachio: heh
<zyga> cachio: /dev/sda1             9983268 4923644   5043240  50% /
<zyga> but
<zyga>  /dev/mapper/loop2p3    380872  372800         0 100% /mnt
<zyga> this is full
<cachio> yes
<cachio> it happens after I merged with master
<zyga> what do we mount at /mnt?
<cachio> did yo usee that in another pr?
<zyga> no
<zyga> I said "heh" because it seems that today everything breaks a little
<cachio> zyga, ok I'll research in that case
<zyga> it seems like the reflash magic
<cachio> yes
<zyga> note that ubuntu-core-16-64 uses an explicit image name
<cachio> yes
<zyga> maybe the implicit name we get for ubuntu-16.04-64 is different?
<cachio> but that image didnt receive any change
<zyga> check what we mount and what determines the size
<cachio> zyga, yes
<zyga> btw
<zyga> the exclude patterns look wrong
<zyga> we don't use /gopath, do we? we moved to /home/gopath
<zyga> so those are probably copying build noise
<zyga> anyway, 7PM
 * zyga EODS
<zyga> o/
<cachio> zyga, enjoy, lets continue tomorrow
<cachio> see you
<pedronis> mmh, 8681 needed a tweak before merging
<zyga> pedronis: what kind, I can send a patch quickly
<pedronis> zyga: it was in my comments there
<zyga> (back in the office for some stuff)
<zyga> looking
<pedronis> the autoremove will not remove the thin we installed manually
<zyga> I see it
<zyga> thanks, I'll fix that in a moment
<pedronis> we need to first remove it and then autoremove the rest
<pedronis> zyga: thx
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8705
 * zyga back to afk
<pedronis> thx
<mup> PR #8705: tests: remove gnome-online-accounts we install <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8705>
<mup> PR snapd#8705 opened: tests: remove gnome-online-accounts we install <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8705>
<mup> PR snapcraft#3133 closed: go v1 plugin: go.mod support for 1.11 and 1.12 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3133>
<cmatsuoka> cachio: https://github.com/snapcore/spread/pull/105 is my attempt to solve the issue
<mup> PR spread#105: google: only configure shielded instance when secure boot is enabled <Created by cmatsuoka> <https://github.com/snapcore/spread/pull/105>
<cmatsuoka> cachio: it also changes secureboot: to secure-boot: so PR 8700 will have to be changed accordingly
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<cachio> cmatsuoka, yes, but once this pr is merged into spread
<cmatsuoka> yes
<cmatsuoka> or when zyga makes this version available to snapd, I don't know how our private deployments work
<cachio> cmatsuoka, didn't work
<cachio> same issue I see
<cachio> cmatsuoka, I need to go to the doctor now, I'll fix it and test it and push
<cachio> once I am back
<cmatsuoka> cachio: oh really? I tested it here with create-partitions-encrypted and it worked (with secureboot changed to secure-boot in spread.yaml)
<cmatsuoka> ok
<cachio> cmatsuoka, I tested to run a test with not secboot
<cachio> and it fails with the same error
<cachio> https://paste.ubuntu.com/p/c7NQcNQmfB/
<cachio> cmatsuoka, I'll run again when I am back
<cachio> in 1 hour
<cmatsuoka> ok, I'll test with fedora in the meantime
 * cachio afk
<cachio> remember all the images support uefi now
<cachio> so it will work :)
<cachio> cmatsuoka, you can try with the image fedora-31-64-base
<cmatsuoka> ok!
<zyga> cmatsuoka: I can do it now
 * zyga waves from the garden
<zyga> cmatsuoka: is spread master updated?
<mup> PR snapcraft#3134 opened: cli: nicer message for status with no releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3134>
<cmatsuoka> cachio: I got this with fedora-31-64: https://pastebin.ubuntu.com/p/c5t9RdzBqv/
<zyga> cmatsuoka: o/
<zyga> 020-05-20 16:24:43 Project content is packed for delivery (176.12MB). <- ??
<zyga> that's a lot
<cmatsuoka> zyga: indeed, maybe there's something that shouldn't be there
 * cmatsuoka checks
<zyga> do you need me to do anything with spread?
<cmatsuoka> zyga: I'm waiting for sergio to validate my fixes, it works in my tests but it seems that it failed for him in an unexpected way
<cmatsuoka> and yes, there was a compressed image in the spread-image directory
<cmatsuoka> I mean, a compressed core image
<zyga> cmatsuoka: maybe a candidate to spread exclude
<cmatsuoka> I really don't know why it was there
<cmatsuoka> probably a leftover from a previous test
<mup> PR core20#60 closed: Copy-in launchpad's build-archive <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/60>
<mup> Issue core20#57 closed: "man" command should not suggest running unminimize <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/57>
<mup> PR core20#59 closed: static: provide friendly message when "man" is used <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/59>
<cachio> cmatsuoka, hey
<cachio> cmatsuoka, #8700 is in green now
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<cachio> cmatsuoka, zyga left some comments there about the changes that you did to the test, could you please answer those?
<cmatsuoka> cachio: ack, also I'm wondering why PR 105 failed for you, I succesfully opened a shell in fedora-31-64
<mup> PR #105: Track capability types <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/105>
<cmatsuoka> cachio: answered the comments in the PR
<cmatsuoka> cachio: is there a non-uefi image I can use to test spread?
<cmatsuoka> cachio: I see you used fedora-32-64 in your test and I tested fedora-31-64, are those different to the point it could affect this test?
<cachio> cmatsuoka, you need to test fedora-31-64-base and fedora-31-64
<cachio> cmatsuoka, the first does not support uefi
<cachio> the second it does
<cachio> cmatsuoka, in my case it failed with the images that don't support uefi
<cmatsuoka> ah ok, let me try the -base variant...
<cachio> the image you used it was updated by me :)
<cmatsuoka> Hmm, I think I tested -base already, I'll test both again to be sure
<zyga> cachio: is opensuse updated as well?
<zyga> cachio: I ran into some issues but perhaps that was from an earlier run
<cmatsuoka> cachio: so this is -base: https://pastebin.ubuntu.com/p/4MrXX4nscd/
<cmatsuoka> cachio: and this is the non-base: https://pastebin.ubuntu.com/p/PnXFBpmrZk/
<cachio> zyga, opensuse is updated
<cachio> 15.1 and tumbleweed
<zyga> ta, I'll get back to stuff tomorrow!
<cachio> cmatsuoka, nice, in that case I got an error
<cachio> zyga, ig #8700 ok for you?
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<cachio> cmatsuoka, and for you?
<zyga> +1
<cmatsuoka> cachio: 8700 works with the current spread, for PR-105 we'll need one more change (secureboot: to secure-boot:)
<cmatsuoka> but I'm still very intrigued with sergio's error with PR-105
<cmatsuoka> cachio: could you check if the binary was built from the correct branch and try the test that failed again?
<cachio> cmatsuoka, ok, once spread works using secure-boot we update snapd accordingly
<cachio> does it make sense?
<cachio> cmatsuoka, checking the error
<cmatsuoka> cachio: yes, we must keep things consistent
<cachio> cmatsuoka, it is merged now
<cachio> so tomorrow we update snapd and zyga deployes the new spread
<zyga> do you need master or something else?
<cachio> zyga, we have on master the fix
<zyga> ah, excellent
<zyga> I will deploy that in the morning
<cachio> nice
<cachio> I'll create the change on snapd to address that, so tomorrow you can approve it once the deploy is done
<cachio> cmatsuoka, is it ok to merge 8700 now?
<cmatsuoka> cachio: if it's passing the tests it should be fine
<cmatsuoka> cachio: I just noticed here that neither fedora-31-64 nor fedora-31-64-base have /sys/firmware/efi
<cmatsuoka> cachio: is that expected?
<cachio> cmatsuoka, yes
<cachio> cmatsuoka, what I did it to configure gce to allow uefi
<cmatsuoka> ah, it's allowed but not necessarily used?
<cachio> cmatsuoka, yes
<cmatsuoka> ah cool, ok
<cachio> I need to specify that when I start the instance
<cmatsuoka> and why did it failed for you?
<cachio> and we are sending the configuration empry
<cachio> because the image was not set to use uefi
<cachio> so when we sent the configuration empty, then gce rejects the parameters
<cmatsuoka> so in PR-105 we're not sending it empty anymore
<cachio> even when the arrey is empty
<cmatsuoka> we don't send it if secure-boot is disabled
<cachio> cmatsuoka, exact
<cmatsuoka> so PR-105 should have worked for you
<cachio> perhaps I did something wrong
<cachio> I'll try again in 1 minutes
<mup> PR snapd#8700 closed: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<cmatsuoka> ah ok, no hurry, I'm just intrigued
<cachio> cmatsuoka, it works
<cmatsuoka> ah nice, thanks :)
<cachio> I think I made a mistake to build
<cachio> just verified
<cachio> zyga, dont use master yet, it is still no merged
<cachio> the change on spread
#snappy 2020-05-21
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8689, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8701, snapd#8702, snapd#8703, snapd#8704, snapd#8705
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8689, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8701, snapd#8702, snapd#8703, snapd#8704, snapd#8705
<mborzecki> morning
<zyga> Heja
<zyga> Still outside
<zyga> See you in 49
<zyga> 40
<mborzecki> zyga: hey
<pstolowski> morning
<zyga> Hey PaweÅ
<mborzecki> pstolowski: hey
<zyga> jamesh: do you intend to support dbus activation on 14.04?
<jamesh> zyga: I don't think so.  System services are probably a bust due to dbus-daemon-launch-helper, and session services are a problem if I tie them to user daemons
<zyga> jamesh: shall I comment on the activation PR about various 14.04 bits then?
<jamesh> zyga: I need to add the "fail fast" bit to prevent installation on 14.04.  Is there more than that?
<zyga> I looked at packaging
<zyga> perhaps there is more, my review is partial
<zyga> ok, I'll make a quick coffee and back to work
<zyga> no coffee for me
<zyga> kitchen is a classroom now
<jamesh> maybe making coffee could be a science experiment?
<mborzecki> making good coffee is definitely like science :P
<mborzecki> zyga: https://www.redhat.com/en/blog/how-selinux-separates-containers-using-multi-level-security?amp=1 and 2nd part https://www.redhat.com/en/blog/why-you-should-be-using-multi-category-security-your-linux-containers?amp=1
<mborzecki> pstolowski: ^^
<zyga> jamesh: there's an active spanish class in progress now
<zyga> I'll just camp next door and wait
<zyga> mborzecki: when is it cheaper to just spin up a thin VM around each container so that dealing with selinux is not required? ;)
<zyga> thanks, queued
<mborzecki> zyga: where'd be fun in that? :)
<zyga> offtopic, skylake was 6000 series
<zyga> it's 10,000 and we still have the same horse
<zyga> intel is a funny company
 * zyga most commonly used command is: go test -coverprofile=/tmp/c.out && go tool cover -html=/tmp/c.out -o /tmp/coverage.html
<mup> PR snapd#8706 opened: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed device <Created by tsunghanliu> <https://github.com/snapcore/snapd/pull/8706>
<mborzecki> zyga: can you take another look at https://github.com/snapcore/snapd/pull/8508 ?
<mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<zyga> yep
<zyga> mborzecki: I think we need to wait till Monday
<zyga> merging this will change test name
<zyga> *names
<zyga> and we will have required tests not present
<zyga> ah, actually, probably not
<zyga> because unstable bits are unstable and not required
<zyga> hmm :)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8508/files#r428571757
<mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<mborzecki> zyga: hm i'd do that separately
<zyga> yeah
<zyga> mborzecki: in general I have a feeling this would be celaner with inputs/outputs
<zyga> a step early on sets the output from the cache
<zyga> and then we can use if: ...
<zyga> but that's fine
<zyga> it doesn't change the general idea
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8689 ?
<mup> PR #8689: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8689>
<pstolowski> yep
<mborzecki> pstolowski: thanks
<zyga> mborzecki: I think we need to teach spread https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-error-message
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8508#pullrequestreview-416046302 reviewed
<mup> PR #8508: github: run all spread systems in a single go with cached results <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<zyga> not sure if we should merge it,
<zyga> look at the cache comment please
<mborzecki> zyga: hmm trying to remember why using `if:` didn't work
<mborzecki> i remember this is what we tried first
<zyga> it didn't work because we used it to skip the part that was required
<zyga> but we could use it for the vast majority of that run there (unit tests and several others)
<mborzecki> zyga: ok, sounds like we want to iterate after it lands
<zyga> I would be happy with 1) a comment on each cache 2) a different cache name
<zyga> unless it's supposed to be the same
<zyga> core 20 secboot tests are slow
<mborzecki> zyga: hmm?
<mborzecki> zyga: apparently we were running too many tests there, a pr from cachio fixing that landed today
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8705/checks?check_run_id=695938599
<mup> PR #8705: tests: remove gnome-online-accounts we install <Simple ð> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8705>
<zyga> 1h:20 and still running
<mborzecki> zyga: yeah, merhe master
<zyga> mborzecki: this is super new
<zyga> mborzecki: was there some big improvement today?
<mborzecki> zyga: #8700 fixed that
<mup> PR #8700: tests: fix the issue where all the tests were executed on secboot system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8700>
<zyga> ah
<zyga> good
<zyga> thank $diety :|
<zyga> :)
<zyga> jamesh: could you have a look at https://github.com/snapcore/snapd/pull/8656
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<mup> PR snapcraft#3134 closed: cli: nicer message for status with no releases <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3134>
<mup> PR snapd#8705 closed: tests: remove gnome-online-accounts we install <Simple ð> <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8705>
<zyga> ta
<sergiusens> zyga: hey, do you know it https://github.com/snapcore/snapd/pull/5822 is on a stable release? degville do you know if this is documented and where?
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5822>
<zyga> sergiusens: it's marked for 2.45 which is in beta
 * zyga -> lunch
<sergiusens> thanks
<degville> sergiusens: I don't think it is documented. I'll speak to the team and ask them how best to approach it.
<mup> PR snapd#8701 closed: tests: sign kernel and gadget to run nested tests using current snapd code <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8701>
<mup> PR snapd#8707 opened: cmd/snap/model: support store, system-user-authority keys in --verbose <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8707>
<mup> PR snapcraft#3135 opened: providers: set HOME environment variable using posix format <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3135>
<mup> PR snapd#8708 opened: tests: setup portals before starting user session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8708>
<mup> PR snapcraft#2922 closed: cli: fix push on Windows <bug> <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2922>
<mup> PR snapcraft#2949 closed: cli: fix clean on Windows <bug> <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2949>
<zyga> travis is stuck again
<zyga> https://github.com/snapcore/snapd/pull/8703
<mup> PR #8703: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8703>
<zyga> brb
<mup> PR snapcraft#3136 opened: appveyor: disable artifact collection <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3136>
<cmatsuoka> mborzecki: who should be mounting /etc/writable in core?
<cmatsuoka> mborzecki: it seems that it's not being currently mounted
<ijohnson> cmatsuoka: but it is mounted tho
<ijohnson> ah actually
<ijohnson> it's doubly mounted
<ijohnson> $ cat /proc/self/mountinfo | grep etc/writable
<ijohnson> 146 122 179:3 /system-data/etc/writable /etc/writable rw,relatime shared:3 - ext4 /dev/mmcblk0p3 rw
<ijohnson> 147 119 179:3 /system-data/etc/writable /run/mnt/base/etc/writable rw,relatime shared:54 - ext4 /dev/mmcblk0p3 rw
<ijohnson> on uc20 ^
<ijohnson> on uc18 v
<ijohnson> $ cat /proc/self/mountinfo  | grep etc/writable
<ijohnson> 33 28 8:3 /system-data/etc/writable /etc/writable rw,relatime shared:9 - ext4 /dev/sda3 rw,data=ordered
<cmatsuoka> oh
<zyga> I don't know the cause
<zyga> but booting 20.10 daily is super slow
<zyga> on my x240 it takes ~ 30 seconds to get off the lenovo splash screen
<cmatsuoka> zyga: could it be a late console initialization? we have this in core
<zyga> cmatsuoka: it's not just that, it's really much slower
<zyga> in the past it booted in a few seconds
<cmatsuoka> zyga: when something appears in the console, the timestamp is already at 20s or 30s
<zyga> now systemd blame says it's 24s+
<zyga> but I think something is stuck before we boot even
<zyga> I can time it with a clock so it's not just my perception
<mup> PR snapcraft#3136 closed: appveyor: disable artifact collection <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3136>
<mup> Issue core20#61 opened: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
 * zyga EODs
<mup> PR snapd#8703 closed: tests: detect signs of crashed snap-confine <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8703>
<mup> PR snapcraft#3137 opened: lifecycle: use snap from path to --check-skeleton <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3137>
<mup> PR snapcraft#3135 closed: build providers: set HOME environment variable using posix format <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3135>
<mup> PR snapcraft#3137 closed: lifecycle: use snap from path to --check-skeleton <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3137>
<mup> PR snapcraft#3138 opened: project: add core20 linker version <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3138>
<mup> PR snapcraft#3139 opened: pluginhandler: run plugin commands in isolation <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3139>
<mup> PR snapd#8689 closed: o/devicestate: raise conflict when requesting system action while seeding <UC20> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8689>
 * cachio afk
<mup> PR core20#62 opened: Build consoleconf from git <Created by xnox> <https://github.com/snapcore/core20/pull/62>
<mup> PR snapcraft#3138 closed: project: add core20 linker version <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3138>
#snappy 2020-05-22
<pstolowski> morning
<mup> PR snapd#8709 opened: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
<mup> PR snapd#8710 opened: tests: spread test for preseeding in lxd container (3/3) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
<mup> PR snapd#8707 closed: cmd/snap/model: support store, system-user-authority keys in --verbose <Simple ð> <Created by anonymouse64> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8707>
<jamesh> it is fairly quiet today
<pstolowski> jamesh: some people are off today
<ackk> hi, is there a way to tell snapcraft not to use the 1.1.1.1 dns when building with --use-lxd
<ackk> >
<ackk> *?
<mup> PR snapd#8706 closed: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
<ijohnson> pstolowski: good morning!
<pstolowski> ijohnson: hi! it has been a very lonely morning
<ijohnson> pstolowski: I think in general it's better to wait for jdstrand to review PR's like #8706 before merging just in case there is something we don't know about
<mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
<ijohnson> this case is probably fine, and perhaps Jamie will do a post-merge +1 at some point, but best to wait I think for interface changes
<pstolowski> ijohnson:  it seemed rather simple but yeah, you're probably right
<ijohnson> no problem
<ijohnson> pstolowski: who else is in today?
<pstolowski> ijohnson: so far just me
<ijohnson> wow yeah pretty quiet I bet :-)
<pstolowski> indeed
<pstolowski> i think Claudio and Sergio will show up?
<ijohnson> pstolowski: sorry I haven't been able to give you any reviews on service stuff, what's the first thing I should look at for that stuff?
<ijohnson> most likely I don't think either of them said today was a holiday for them
<pstolowski> ijohnson: np, tbh i haven't proposed the 'real meat' of it yet, just some preparatory stuff.. they'are numbered and also independent of each other, can be reviewed in any order
<ijohnson> ok, cool
<zyga> Hey
<zyga> Bike trip time
<zyga> Anything on fire?
<pstolowski> zyga: hi! no, go biking!
<zyga> Small break
<zyga> Eating ice cream
<zyga> But no bad news is great news
<zyga> :-)
<pstolowski> woah, this test failure looks interesting https://pastebin.ubuntu.com/p/ZM6jTKgvwb/
<ijohnson> pstolowski: sssh don't tell z y g a
<pstolowski> ijohnson: haha
<pstolowski> pulseaudio test keeps on giving
<jdstrand> pstolowski, ijohnson: I'll retroactively look at it a bit later. first glance seems ok
<ijohnson> thanks jdstrand
<jdstrand> there is an unwritten rule that changes to security policy go through the security team, yeah
<pstolowski> thanks!
<pstolowski> jdstrand: yes i know, sorry about that, i thought it was very uncontroversial (as opposed to changes that e.g. modify a regex in an open-ended way)
<ijohnson> pstolowski: do you remember the signal to send to snapd process to get it to print where it's stuck? I have a snapd process hung doing something and I'd like to see a backtrace where it is currently stuck
<ijohnson> I thought it was like SIGUSR1 or something like that but I can't remember
<pstolowski> ijohnson: i'm not aware of this functionality!
<ijohnson> ah maybe it's ABRT ?
<ijohnson> pstolowski: yeah it's SIGABRT https://pro-tips-dot-com.tumblr.com/post/47677612115/kill-a-hung-go-process-and-print-stack-traces
<pstolowski> ijohnson: this is nice, thank you!
<ackk> sergiusens, hi, around?
<mup> PR snapcraft#3140 opened: [wip] specifications: environment management <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3140>
<ijohnson> hey cmatsuoka
<cmatsuoka> hi
<cmatsuoka> good morning
<cmatsuoka> ijohnson: I was thinking about the out-of-order minor device number in the Intel P600, it's weird but it seems unrelated to the install error
<cmatsuoka> or at least not related in a very obvious way
<ijohnson> cmatsuoka: yeah I was more asking about that to satisfy my curiosity, but it's still not clear what the issue was - very interesting that another NVME just works though
<mup> PR snapcraft#3141 opened: build providers: use LXD-provided DNS by default <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3141>
<mup> PR snapd#8711 opened: snap/squashfs: also symlink snap Install with uc20 seed snap dir layout <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8711>
<pstolowski> ijohnson, cmatsuoka : do we ship snap-bootstrap only on ubuntu? do you know?
<ijohnson> pstolowski: yes, we need it in the deb for ubuntu-core-initramfs deb to pick up snap-bootstrap
<cmatsuoka> pstolowski: yes
<pstolowski> i see, thanks!
<ijohnson> pstolowski: but also we don't use it anywhere other than ubuntu (or at least we shouldn't ship it anywhere else because it's not used anywhere else)
<Saviq> hey all, is `default-provider:` something supported for any random interface, or just content?
<ijohnson> Saviq: just content right now
<jdstrand> roadmr: hi! would you mind pulling 20200521-2148UTC ?
<roadmr> jdstrand: ohai :)
<roadmr> sure, queueing it up
<jdstrand> sergiusens, ackk: that has your py3 update ^ (that will fix the store part; in the process of releasing the snap to stable still)
<ackk> jdstrand, thanks!
<jdstrand> roadmr: thanks! :)
<jdstrand> ackk: np
<jdstrand> ackk: in the meantime, if you've uploaded something and need it, just ping me or emitorino and we can manually approve it
<jdstrand> emitorino: (talking about the python3 external symlink merged branch that is on its way but not in prod yet)
<ackk> jdstrand, https://dashboard.snapcraft.io/snaps/canonical-rbac/revisions/233/ would be the one showing the issue
<jdstrand> ackk: can you request a manual review then I can apprive
<jdstrand> approve even
<ackk> jdstrand, done, thanks
<jdstrand> ackk: done
<ackk> thanks
<jdstrand> roadmr: hey, I asked this elsewhere and didn't get an answer. curious if you know... as mentioned in the uf wtrack request (thanks btw!), I'm moving 'latest' to base: core20. we can't build i386 snaps using 'base: core20'
<jdstrand> roadmr: so I created another track that will use 'base: core18' with an older, supported release of ufw (fine)
 * roadmr reads attentively :)
<jdstrand> roadmr: but is there a mechanism for an i386 user to use 'snap install ufw' on i386 and have it fallback to the non-latest track, *without* making the non-latest track the default?
 * jdstrand plans to address this in documentation currently
<jdstrand> roadmr: what about existing i386 users that are on latest? how can they move automatically to a supported track?
<jdstrand> roadmr: really, this isn't so much about ufw as the ecosystem. I'm just using ufw as an example
<roadmr> jdstrand: wow :( I don't think any mechanisms exist for that kind of routing-to-tracks-by-architecture :(
<roadmr> particularly if all devices are pointing to the same latest/stable or other track
<roadmr> channels can be closed per-arch but that's about it
<jdstrand> roadmr: yeah, so, today, I can just snapcraft release the thing from my other track to i386 latest, but that is a little awkward
<roadmr> jdstrand: this would require more thinking/brainstorming/feedback, so maybe if you could shoot an email with this description to snap-store-admins@lists.canonical.com to see if anyone can think of a better way
<roadmr> jdstrand: indeed, sounds like that's what exists right now
<jdstrand> roadmr: I can do that. would a forum topic in the 'store' category be better?
<roadmr> jdstrand: oh actually - it probably would
<roadmr> it's general enough for that kind of audience
<jdstrand> roadmr: we might get a feel for how widespread it might be if it is in the forum
 * jdstrand writes it
<jdstrand> roadmr: thanks!
<mup> PR snapcraft#3142 opened: storeapi: reset account_id on store login <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3142>
<jdstrand> roadmr: https://forum.snapcraft.io/t/how-to-best-handle-i386-when-moving-a-snap-to-base-core20/17680
<roadmr> thanks!
 * cachio lunch
<kyrofa> Lukewh, did you see https://github.com/canonical-web-and-design/snapcraft.io/issues/2774 ? Can you at least let me know if it builds on tag pushes?
<Lukewh> hey kyrofa I did thanks, sorry for not getting back to you - it builds only on default branch
<kyrofa> Lukewh, not tags then?
<Lukewh> not tags
<Lukewh> kyrofa: correct
<kyrofa> Alright, thank you
<kyrofa> Consider that a feature request, then
<Lukewh> I did :)! Again sorry for not getting back to you
<cmatsuoka> ijohnson: I found a xfs bug report that mentions a disk corruption only in intel nvme
<cmatsuoka> "I am experiencing this exact issue with an Intel 600p NVMe SSD on brand new..."
<cmatsuoka> ijohnson: https://bugzilla.redhat.com/show_bug.cgi?id=1402533
<ijohnson> mmmm interesting
<cmatsuoka> at a certain point there's a report of success after updating firmware
<cmatsuoka> (comment #30)
<cmatsuoka> pft, no, he had the problem again after that. let me read the entire thread first :)
<ijohnson> cmatsuoka: I think we should add code to snap-bootstrap, `if disk == "this-nvme" { fmt.Println("broken firmware, giving up") }`
 * ijohnson is only half joking
<cmatsuoka> ijohnson: the last comment there is: "considering this is now fixed by Intel firmware update, and it was not a Linux/Fedora software issue, i'm going to close this ticket."
<cmatsuoka> so I think it would be worth to check Vic's nvme stick firmware version
<cmatsuoka> I'll add a note to the LP bug
<ijohnson> thanks cmatsuoka yeah maybe upgrading the nvme firmware will fix the issue
<mup> PR snapcraft#3142 closed: storeapi: reset account_id on store login <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3142>
<cmatsuoka> ijohnson: this is also interesting: https://www.anandtech.com/show/12742/latest-windows-10-version-incompatible-with-intel-ssd-600p
<ijohnson> cmatsuoka:
<ijohnson> > The Intel ... were Intel's first M.2 NVMe SSDs, a radical shift
 * ijohnson facepalms
<mup> PR snapcraft#3141 closed: build providers: use LXD-provided DNS by default <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3141>
 * cachio afk
<cwayne> ijohnson: I'm assuming that's what's in those nucs?
<ijohnson> cwayne: yep
<cwayne> Wonder if we've tested focal desktop on them..
<cwayne> Know we did uc18 and bionic
<ijohnson> cwayne: yah that's a good question does focal desktop/server work on them
<cwayne> ijohnson: it do
<cwayne> https://www.irccloud.com/pastebin/LHfQ6C5N/
<cwayne> thats the nvme in question ya?
<ijohnson> yep
<ijohnson> cwayne: can you check the firmware on that nvme ?
<cwayne> if you let me know how sure
<ijohnson> I assume you have the same one reserved that is used to try uc20 boots
<ijohnson> give me a minute
 * cwayne has never actually had a nvme
<cwayne> ijohnson: its one of them, im not sure which vic tried it on (though i think he said he tried all of them)
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # closed: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> PR # closed: core#38, core#107, core#108, core#110, core#111
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue core20#12 closed: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 closed: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> PR # closed: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # opened: core#38, core#107, core#108, core#110, core#111
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 opened: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#61 opened: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # opened: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # opened: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140
<mup> Issue core-build#60 closed: Consider setting RPATH for executables and libraries <Created by mikix> <https://github.com/snapcore/core-build/issue/60>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue core-build#60 opened: Consider setting RPATH for executables and libraries <Created by mikix> <https://github.com/snapcore/core-build/issue/60>
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # closed: core#38, core#107, core#108, core#110, core#111
<mup> PR # closed: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<xnox> mup go home =)
<mup> Issue core20#12 closed: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 closed: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#61 closed: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # closed: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 opened: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#61 opened: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # opened: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<ijohnson> Poor mup
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue core20#12 closed: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#61 closed: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # closed: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> PR snapcraft#3143 opened: cli: migrate close to use the new channel map <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3143>
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 opened: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#61 opened: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # opened: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> PR # closed: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140, snapcraft#3143
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # opened: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140, snapcraft#3143
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # closed: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140, snapcraft#3143
<mup> PR # opened: snapcraft#2413, snapcraft#2673, snapcraft#2696, snapcraft#2826, snapcraft#2871, snapcraft#2890, snapcraft#2910, snapcraft#2941, snapcraft#2971, snapcraft#3018, snapcraft#3062, snapcraft#3097, snapcraft#3107, snapcraft#3109, snapcraft#3110, snapcraft#3118, snapcraft#3127,
<mup> snapcraft#3128, snapcraft#3129, snapcraft#3131, snapcraft#3139, snapcraft#3140, snapcraft#3143
<mup> Issue core20#12 closed: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#61 closed: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # closed: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 opened: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#61 opened: /etc/writable is double mounted <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/61>
<mup> PR # opened: core20#11, core20#45, core20#49, core20#54, core20#58, core20#62
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<genii> holey moley
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # closed: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> PR # opened: snapd#6258, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8143, snapd#8271, snapd#8301, snapd#8317, snapd#8340,
<mup> snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8558, snapd#8567, snapd#8568, snapd#8569, snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608,
<mup> snapd#8609, snapd#8620, snapd#8639, snapd#8640, snapd#8643, snapd#8656, snapd#8661, snapd#8667, snapd#8675, snapd#8677, snapd#8683, snapd#8691, snapd#8693, snapd#8697, snapd#8699, snapd#8702, snapd#8704, snapd#8708, snapd#8709, snapd#8710, snapd#8711
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> Issue core-build#60 opened: Consider setting RPATH for executables and libraries <Created by mikix> <https://github.com/snapcore/core-build/issue/60>
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
#snappy 2020-05-23
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR core20#62 closed: Build consoleconf from git <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/62>
<mup> Issue core20#63 opened: fix travis builds with new subiquity from git <Created by xnox> <https://github.com/snapcore/core20/issue/63>
<mup> Issue core20#64 opened: Use more snapcraftish console-conf plugin <Created by xnox> <https://github.com/snapcore/core20/issue/64>
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # closed: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151, core18#153
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148, core18#152
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR snapcraft#3139 closed: pluginhandler: run plugin commands in isolation <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3139>
<nikolam> Hi, I have found Snap Store (in ubuntu) breaks all licenses of all applications in Snap store.
<nikolam> User is usually allowed (and by licenses itself required) to first see and accept the license(s) of an application before the install and usage.
<nikolam> Snap store does not display not make a link to neither makes available license(s) , and deliberately hides application license(s) from the user before install.
<nikolam> Therefore Snap store breaks all licenses of all applications in the snap store and by any lawful protection of any software license of applications, is not allowed to distribute and make available for installation of any application, before fullfilling licenses requirements.
<nikolam> Only way to fulfill licensing requirements by Snap Store, is to display list of all the licenses with links or option to display license text, so user can be informed in full of liceses he/she accepts BEFORE application installation.
<nikolam> I am not a lawyer, but I am pretty sure that most of the applications in Snap Store have a clear requirement of application distributor, to make license text available to every user of the application.
<nikolam> If by some mean Snap Store have changed distributed binaries and therefore changed license for all applications in the Snap Store to some "Snap Store binary license" or something similar, Snap Store is required by most of the licenses of the applications in the Snap Store, to make available changed source code of applications in the Snap Store.
