#snappy 2015-07-06
<Guest10540> Has anyone managed to get OVA on VirtualBox working? (https://developer.ubuntu.com/en/snappy/start/#ova) I see many complaints about not being able to log in after cloud-init, ..., and I wasn't able to, either.
<dholbach> good morning
<fgimenez> good morning
<sturmflut2> fgimenez: o/
<davidcalle> Morning o/
<JamesTait> Good morning all; happy Monday, and happy Take Your Webmaster To Lunch Day! ð
<Chipaca> JamesTait: Just realized: I'm my own webmaster!
 * Chipaca will take himself to lunch
<JamesTait> Chipaca, me too. :(
<Chipaca> JamesTait: :(? \o/!
<JamesTait> Chipaca, possibly. The benefit of someone else taking me to lunch is they'll pay. That may or may not be outweighed by the burden of their company, depending who they are.
<JamesTait> Chipaca, also, happy Fried Chicken Day! Enjoy your solitary trip to KFC. ð
<Chipaca> JamesTait: was about to point out i had no kfc close enough, but i was wrong!
<Chipaca> but there's a âkebabs & southern fried chickenâ closer than that
<Chipaca> i'm not feeling brave enough for either tbh
<JamesTait> Chipaca, so... happy fry your own chicken day?
<Chipaca> JamesTait: happy leftovers day \o/ :)
<JamesTait> Hah! You win!
<Chipaca> need to polish off some things before they go off
<Chipaca> including a palta and a ball of bufala mozzarella
<Chipaca> so dunno what it's going to be, but it's going to be awesome :)
<Chipaca> JamesTait: are you not in .uy?
<JamesTait> Chipaca, nope.
<Chipaca> JamesTait: ah, ok then :)
<JamesTait> Off the top of my head I'm not sure who's over there, tbh.
<JamesTait> I don't think it's many though, IIUC it's at Martin's place.
<Chipaca> JamesTait: here, one for you: http://www.whitevinyldesign.com/solarbeat/
<JamesTait> Chipaca, that is beautiful. âº
<vmayoral|pc> greetings
<vmayoral|pc> can i have someone review a framework i submitted yesterday called "capes"?
<vmayoral|pc> spent the weekend porting our packages from "binaries" to "services" and we'll need that framework in order to upload the apps
<rsalveti> ogra_: sergiusens: for https://bugs.launchpad.net/snappy/+bug/1429749, what would be the proper fix?
<ubottu> Ubuntu bug 1429749 in Snappy trunk "Ubuntu Core updated but not switch to new version after reboot on Raspberry Pi 2" [Undecided,New]
<rsalveti> not allow update for ubuntu-core?
<ogra_> yes, sergiusens added a warning to udf recently for that
<ogra_> and i thought the plan was to not support that at all
<rsalveti> ogra_: but this is on a running system?
<rsalveti> s/?//g
<ogra_> well, it does the download but wont switch partitions
<ogra_> i understood that will be fixed on a snappy level so it wont attempt the download
<rsalveti> ogra_: right, that's what I assumed as well, but don't know if we got anything for it yet
<rsalveti> maybe sergiusens knows more
<ogra_> i thin that waits for the s-i dropping
<ogra_> *think
<sergiusens> ogra_: rsalveti running systems won't be affected by the change, only new ones
<ogra_> indeed, since running systems wouldnt use udf :)
<ogra_> neither will people that use the stable image and dd it
<rsalveti> sergiusens: right, they can flash new images, that's fine
<rsalveti> sergiusens: but is there anything we can do in snappy itself to forbid such update?
<rsalveti> or give a better error or such?
<sergiusens> rsalveti: not without manual hacks
<rsalveti> sergiusens: why manual hacks?
<rsalveti> sergiusens: can't we check for the origin?
<ogra_> right, we discussed that before ... which made me think we'll wait for the switch away from s-i
<sergiusens> rsalveti: the origin feature only landed last week
<sergiusens> into rolling
<sergiusens> trunk
<sergiusens> and origins for device tarballs is sort of complicated
<rsalveti> sergiusens: sure, not necessarily for this week/release, just trying to understand what would be the proper solution
<sergiusens> rsalveti: move to snaps
<sergiusens> that's the proper solution ;-)
<sergiusens> for stable though, anything we do will be a hack
<ogra_> (on a sidenote it is trivial to hack around the issue currently ... by just hacking snappy-system.txt)
<sergiusens> unless it's done during prov
<rsalveti> yeah, was wondering for stable
<sergiusens> ogra_: right, but that is a prov thing
<ogra_> even if it would be supported, the RPi uboot cant handle it currently
<ogra_> (on another sidenote :) )
<elopio> good morning
<elopio> they are fixing the plumbing in my apartment today, so I might be on and off during the morning.
<elopio> fgimenez: have you seen any errors while doing the failover updates?
<rsalveti> mterry: ogra_: sergiusens: about bug 1444049, should we just include libc6:i386?
<ubottu> bug 1444049 in Snappy trunk "Shipping libc6:i386 in the amd64 images would be useful" [Undecided,New] https://launchpad.net/bugs/1444049
<rsalveti> I imagine this to be an issue soon
<rsalveti> and not a trivial one to let the user to fix himself
<fgimenez> elopio, yes, with version #98 TestZeroSizeSystemd is failing
<ogra_> hmm
<fgimenez> elopio, this branch fixes it https://code.launchpad.net/~fgimenez/snappy/fix-zerosize-systemd-failover-test
<elopio> fgimenez: I saw one grub error yesterday in that test, but didn't dig anything.
<ogra_> rsalveti, can we do that without additional deps ?
<elopio> cool, you already fixed it :)
<mterry> rsalveti, ogra_: depends how much we want to cater to running x32 executables...  It is rather difficult right now
<rsalveti> what would be the additional deps?
<rsalveti> this is just libc
<rsalveti> ogra_: one for you: https://bugs.launchpad.net/snappy/+bug/1456340 :-)
<fgimenez> elopio, yep, just setting the same permissions to the empty file fixes it
<ubottu> Ubuntu bug 1456340 in Snappy trunk "Add gdbserver to snappy image" [Undecided,New]
<ogra_> i understand the conveninece that adds ... but where do we draw the line ?
<elopio> let me give it a try.
<vmayoral|home> hi everyone! any chance i can get my new framework reviewed? (it's called "capes")
<ogra_> rsalveti, *yawn* ... always the same bugs everywhere ... thats boring
<rsalveti> ogra_: I'd say just libc for now
<mterry> rsalveti, ogra_: I think it pulls in libgcc1 too (but that's it)
<ogra_> rsalveti, yes, but then there is this other compelling lib to add ... and a week later another one ....
<rsalveti> ogra_: :-)
<rsalveti> ogra_: well, don't think we'll add much
<ogra_> i'm just a bit afraid that over time more and more sneaks into the image like this
<rsalveti> just that not having libc is kind of too much for someone to start
<ogra_> yeah, lets add it then
<rsalveti> ogra_: easy for rolling, how to add it for stable? :-)
<rsalveti> ogra_: should we create a meta package for it?
<ogra_> hmm, how did we handle stable til now ?
<rsalveti> and force that meta package in the livecd-rootfs script
<ogra_> (given we dont have meta packages at all)
<rsalveti> ogra_: in livecd-rootfs itself
<ogra_> if we need to hack livecd-rootfs anyway i wouldnt add a meta .... just add libc there
<rsalveti> ogra_: that's fine I guess, we don't plan to increase this much anyway
<ogra_> (though i'm not sure if live-build is multiarch aware )
<rsalveti> hm, right
<ogra_> needs a test i guess
<rsalveti> ogra_: and about gdbserver, should we add it as well?
<ogra_> yeah
<rsalveti> alright, adding both bugs to you then :-)
<ogra_> :)
<ogra_> gdbserver should eb a hard dep of libc :P then we dont need to seed it everywhere
<ogra_> *be
<elopio> fgimenez: with your filter branch, I started modifying the real update tests. Here's my idea:
<elopio> - when there are no available updates, we make the tests to fake one, as we discussed last week. So we flash the latest image, and run everything in there.
<elopio> - we flash rev -1. We use a filter that will only run the update so it will leave the image on the latest rev. And then we run on this image all the tests.
<elopio> - we flash 15.04. We run only a test that will update it to latest. And then we run on this image all the tests.
<ogra_> seems everyone and his cousin wants it installed everywhere anyway
<elopio> fgimenez: any thoughts?
<rsalveti> mterry: care to backport https://bugs.launchpad.net/snappy/+bug/1461070 ?
<ubottu> Ubuntu bug 1461070 in Snappy 15.04 "Running set active without sudo gives lower level error than it should" [Undecided,New]
<mterry> rsalveti, ok
<rsalveti> mterry: https://bugs.launchpad.net/snappy/+bug/1461917 as well
<ubottu> Ubuntu bug 1461917 in Snappy 15.04 "snappy app services should auto restart" [Undecided,Triaged]
<fgimenez> elopio, great! :) taking care also of passing the right testList (latest, previous,...) for each case and the testFilter to adtRun will make it very straightforward
<balloons> elopio, how's the images and everything today?
<elopio> fgimenez: yes, I didn't think your filters would be so useful. Looking at your comment on the branch...
<balloons> are we all set? what needs finishing?
<elopio> balloons: things seem on nice on wily and using the proposed ppa on vivid.
<elopio> balloons: rsalveti and the team are backporting things to the 15.04 branch. Once they are backported, we will have an RC.
<balloons> elopio, does install system-status.victor work for you? (sudo snappy install system-status.victor)
<elopio> balloons: I can give it a try in ~10 minutes.
<balloons> elopio, ack, tyu
<ogra_> Chipaca, so no console= should be the default
<ogra_> Chipaca, but we need a way to define one console= option for images that should default to serial
<Chipaca> when somebody comes to us complaining about X weird behaviour
<Chipaca> we would need to remember to ask for their boot commandline
<bregma> I'm working on a snap that will need to create some network devices (traditionally done as root during package installation) -- how does that, and other similar privileged admin tasks -- work with a snap?
<ogra_> Chipaca, well, certain HW implies certain console= settings ... embedded boards like the BB or RPi should efault to serial console
<ogra_> grub based images that run in a VM or on real HW shouldnt
<Chipaca> ogra_: i'm reading "i'm fine with it being in the gadget snap"
<ogra_> Chipaca, no, totally not fine with that ...
<ogra_> because it would mean you need separate gadget snaps pre console option
<Chipaca> ogra_: i know, that's why i said it -- so you'd expand :)
<ogra_> *per
<Chipaca> ogra_: but you're saying the default is per device, aren't you?
<Chipaca> ogra_: ie bb or rpi need it, vm or real hw don't
<ogra_> well ...
 * Chipaca notes ogra just said the bb wasn't real hardware
 * Chipaca blames the dentist
<ogra_> while the BBB is definitely not suited for personal, i would expect that RPi users might run kodi on their boards ... or some other graphical thing
<ogra_> so they'd want to be able to switch back and forth
<ogra_> personal specifically might want to use a boot splash ... and would need a graphical soncole device set
<ogra_> *console
<ogra_> as i said before already ... i thinbk the only sane way would be to have a u-d-f option to set a non-default console device ... but sergiusens didnt sound happy about addin more u-d-f options
<Chipaca> rsalveti: sergiusens: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917
<Chipaca> ogra_: right now, udf has no kernel options exposed. If we expose one, do you promise your axe to help us defend against the horde?
<ogra_> well, you can make it not look like a kernel option :)
<Chipaca> ogra_: (i'm not sure whether it's an option at all, really -- people are already complaining about too many obscure options in udf)
<rsalveti> ogra_: start a thread in snappy-devel :-)
<ogra_> i just dont think it is sane to have a million identical gadget snaps for changed kernel cmdline options
<Chipaca> ogra_: i agree with you :)
<Chipaca> ogra_: i just think you're the one who can defend your point the best. Please do make it on the list :)
<ogra_> and sadly snappy-config wont work until you booted ...
<rsalveti> Chipaca: thanks for the mr
<ogra_> yeah
<elopio> balloons: package with namespace not supported?
<Chipaca> bregma: how would the network devices be created traditionally?
<bregma> Chipaca, through the equivalent of a sudo operation, I imagine
<bregma> since this is done by the user at first-run
<Chipaca> bregma: i mean, you'd drop something into network/interfaces.d?
<balloons> elopio, yea.. https://bugs.launchpad.net/snappy/+bug/1466674.
<ubottu> Ubuntu bug 1466674 in Snappy "Snappy store contains packages with namespace" [Undecided,Incomplete]
<elopio> balloons: I don't fully understand what nessita is asking in there.
<elopio> but the error message doesn't come from the snappy source code.
<balloons> that makes two of us, heh. Is there anyway to get more verbose output? Where is the source for the error?
<elopio> let me see what install does.
<balloons> does it use alias?
<balloons> that's the only difference I see between the packages
<nessita> elopio, hey!
<elopio> balloons: what packages are you comparing?
 * elopio waves at nessita.
<nessita> elopio, what I'm asking/saying is that a package's manifest can vadily have as "name" the package full path (ie the store allows this)
<balloons> elopio, nessita I simply looked at the json for the hello-world package (which works fine) and the system status package from victor
<balloons> the hello world package has an alias, the system status package has null for that field
<elopio> balloons: can you please link to the source of that package?
<nessita> balloons, for package metadata you should query the index, since the fields inside a package may not be accurate
<nessita> (the package index)
<balloons> nessita, I used https://search.apps.ubuntu.com/api/v1/package/system-status.victor and https://search.apps.ubuntu.com/api/v1/package/hello-world
<balloons> elopio, links ^^
<bregma> Chipaca, we're trying to create an unprivileged LXC container, so there are a number of steps that need elevated privileges including creating UIDs and running LXC tools to create VETH devices (the exact nature of such operations is beyond my kenning)
<nessita> elopio, I'm currently in a sprint so I will try tyo answer as I can, need to run for lunch now (being kick off the room)
<balloons> thanks nessita
<Chipaca> bregma: i might be wrong, but i think having an unprivileged snap do privileged things is not currently possible
<Chipaca> arbitrary privileged things, that is
<elopio> nessita: buen provecho.
<Chipaca> bregma: although what you're wanting to do is something we want to suppor
<Chipaca> t
<Chipaca> bregma: so maybe we need to map out what you want, and expose it in some way
<bregma> Chipaca, our current plan is to just use PAM to elevate privs with authentiction, will that still work on Snappy?
<Chipaca> bregma: i'm going to guess 'no'
<bregma> :(
<Chipaca> but i'm not fully sure of what you mean, so :)
<Chipaca> if you mean "after snappy install, run sudo yadda yadda", then maybe yes
<Chipaca> but that won't work in a number of scenarios
<Chipaca> mostly around not having console access to the device :)
<ogra_> well, the lxd framework should offer you all this, no ?
<bregma> our snap is designed to work only on devices with full user interaction, so we don;t care about ones without console access
<Chipaca> ogra_: yep, but it'll need something very close to uncontained :)
<bregma> and LXD just doesn't meet our needs in any way
<ogra_> oh, why is that ?
<ogra_> i thopught it is only used to fire up lxc containers
<elopio> balloons: http://bazaar.launchpad.net/~vthompson/+junk/system-status/view/head:/meta/package.yaml
<elopio> http://paste.ubuntu.com/11831452/
<balloons> looks fine to me
<elopio> balloons: that's what's needed ^
<balloons> elopio, sure that would fix it I suppose; it's just odd that it fails when the hello-world package has name as hello-world.canonical as the name
<elopio> balloons: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-world/meta/package.yaml
<elopio> not on the metadata.
<balloons> ok, so then the question for nessita is why the package wasn't unpublished then
<balloons> as that was the old style
<balloons> ty elopio
<elopio> also, in here it says that "." is allowed in the name
<elopio> https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<balloons> ohh good catch!
<balloons> can you summarize in a comment on the bug?
<balloons> i'll add the website to it so it can be fixed too
<balloons> whoa.. "snappy autopilot triggered a reboot to boot into an up to date system"
<elopio> balloons: autopilot is following you!
<balloons> scary!
<Chipaca> sergiusens: you around?
<sergiusens> Chipaca: yes
<Chipaca> sergiusens: good.
<Chipaca> sergiusens: wondering why 'snappy search' would find a package, but install wouldn't
<Chipaca> sounds all very weird to me :)
<sergiusens> Chipaca: search does partial matching while install requires an exact match?
<Chipaca> sergiusens:
<Chipaca> (amd64)ubuntu@localhost:~$ snappy search mir
<Chipaca> Name Version Summary
<Chipaca> mir  snap1   Mir example server snap
<sergiusens> Chipaca: http://search.apps.ubuntu.com/api/v1/package/mir.mvp-demo that one?
<ogra_> bah, amd64 only ?
<sergiusens> Chipaca: it has no alias
<ogra_> not found on any armhf device
<sergiusens> Chipaca: and it is a framework, that is why
<ogra_> thats lame
<sergiusens> ogra_: we don't care about armhf ever since you stopped using your chromebook ;-)
<Chipaca> i still have the ac100
<sergiusens> have != use
<ogra_> damn ... i'll dig it out next WE !
<Chipaca> well.. i use it to separate the gray lego from the green lego
<Chipaca> ogra_: oooh! if snappy core boots that, i'll be happy :)
<ogra_> do you fear little dark green legos ?
<Chipaca> ogra_: if you saw the mess that is the lego box, you'd be laughing too :D
<ogra_> :)
<Chipaca> it's officially the lego box, but i think the floor has more lego
<sergiusens> ogra_: I'm waiting a bit more for that
<Chipaca> i should probably rename it 'misc junk' or sth
<ogra_> haha
 * Chipaca sideloads the mir snap
<Chipaca> aaand it's a bad snap :-(
<Chipaca> (amd64)ubuntu@localhost:~$ sudo snappy install ./mir.mvp-demo_snap1_amd64.snap
<Chipaca> Installing ./mir.mvp-demo_snap1_amd64.snap
<Chipaca> ./mir.mvp-demo_snap1_amd64.snap failed to install: can not parse package.yaml: missing required fields 'vendor' (from: "name: mir\nversion: snap1\narchitecture: amd64\ntype: framework\nservices:\n  - name: system-compositor\n    description: \"system compositor\"\n    start: bin/server\n    security-template: unconfined\n")
<sergiusens> elopio: Chipaca if you build images for 15.04/edge do they work out?
<sergiusens> elopio: Chipaca if you build images for 15.04/edge do they work out?
<sergiusens> there :-P
<elopio> sergiusens: let me try.
<sergiusens> elopio: seem to missing a systemd service here
<elopio> udf'ing
<nessita> elopio, balloons the package may be old style but is still super valid
<nessita> elopio, balloons, so code should be prepared to handle both formats
<nessita> we will not unpublish such packages since they are still valid, as far as the store is concerned
<Chipaca> nessita: which package?
<nessita> Chipaca, system-status.victor
<nessita> Chipaca, https://search.apps.ubuntu.com/api/v1/package/system-status.victor
<balloons> ok . . . well, then something on the installation side needs fixed. As it stands it can't be installed and gives the unhelpful error. I'd guess other packages might have the same issue
<sergiusens> nessita: it's not valid, frameworks and oems need to have an alias
<sergiusens> nessita: wrt beuno said oem and framework types would automatically get aliased when accepted
<nessita> sergiusens, as far as the store is concerned, that package name is very valid. If it needs an alias that is another feature/story
<nessita> sergiusens, which I'm not aware we have in our radar, but surely is on our backlog
<nessita> our radar == current items being worked on
<beuno> I've found an owner for that
<beuno> within the next few weeks
<beuno> hopeolly
<sergiusens> nessita: it's not supposed to be published; we have a very manual process for publishing frameworks and oems, can you track down who accepted that package into the store?
<nessita> sergiusens, yes
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943
<elopio> sergiusens: yes, it prints lots of errors. Not sure which is the first.
<nessita> sergiusens, last published version is 1.0.3 and was automatically approved by the scripts with no errors and only 1 warning
<nessita> sergiusens, last 4 uploaded versions (1.0.4 up to 1.0.7) are all failing with
<nessita> security_policy_vendor_matches_framework (meta/system-status.apparmor):
<nessita> ubuntu-snappy != ubuntu (ubuntu-core-15.04-dev1)
<nessita> sergiusens, does that give you any debug information?
<sergiusens> elopio: [    5.783593] systemd[1]: Failed to isolate default target: Unit snappy-workaround-apparmor.service failed to load: No such file or directory.
<sergiusens> nessita: date of last upload? I hope it's newer than the great purge date we did in austin with beuno
<sergiusens> nessita: according to the json result last_updated: "2015-02-24T03:44:14.674552Z",
<nessita> sergiusens, version 1.0.3 was approved and published on  2015-02-24
<sergiusens> this package should not be published
<sergiusens> nessita: we made a massive unpublish in April before release
<nessita> sergiusens, who should have unpublished it?
<nessita> (to try to track down debug information)
<sergiusens> nessita: beuno and james_w
<sergiusens> nessita: it was an implicit unpublish, asac had requested to wipe the store
<ogra_> yeah, the format of package.yaml changed
 * ogra_ still hasnt re-published all his packages
<ogra_> unpublishing was a requirement ... that package simply slipped through
<ogra_> there is no bug ...
<sergiusens> ogra_: no, it wasn't there and now it is
<nessita> sergiusens, so do you know what was the criteria to unpublish packages? obviously the store can not be wiped since we have all the click world in it :-)
<beuno> I think I decided to no unpublish things that would get filtered out automatically because we now required a release
<ogra_> sergiusens, that package is really old ... i used to try it out way before the unpublishing
<sergiusens> nessita: snappy store was to be wiped, the catalog at least; and it's because during the week of austin we decided to make breaking changes for release which required this
<nessita> sergiusens, see beuno s comment
<sergiusens> beuno: right, but I guess anyone going in can tick a release, right?
<beuno> yes
<beuno> so I guess I wasn't *that* smart
<nessita> I think that solves the mistery, now we need to come up with a fix that suits everyone
<sergiusens> beuno: which makes packages that were published before sort of dangerous
<sergiusens> because the semantics don't match anymore
<sergiusens> and to be honest, the system-status snap might as well be an app and not a framework ;-)
<sergiusens> rsalveti: image is broken due to https://launchpadlibrarian.net/210538856/ubuntu-core-config_0.6.15%2Bppa6_0.6.15%2Bppa7.diff.gz
<sergiusens> rsalveti: not sure if we need to revert that change or wait for that upstream fix to land...
<balloons> sergiusens, beuno nessita thanks for getting to the root of this
<sergiusens> elopio: I think that triggers the issue ^
<elopio> if we want the rc tomorrow, maybe we should revert.
<elopio> balloons: once we know what's the latest image we can test tomorrow, I'll make a note on the flashing section of the wiki page.
<elopio> are we missing something else?
<balloons> elopio, afaik, no. I just need to review the google form again
<balloons> I saw https://developer.ubuntu.com/en/snappy/guides/channels/ was updatedso 15.04/edge is what we want people to use yes?
<sergiusens> elopio: I think I know where this comes from, I'll take a look
<elopio> balloons: no, that should be 15.04/rc.
<balloons> elopio, ok, I'll update it again
<sergiusens> elopio: rsalveti I think this fixes our issue at hand http://paste.ubuntu.com/11831998/
<balloons> elopio, I don't see an rc image on cdimage though.
<balloons> This goes back to our conversation on u-d-f vs cdimage download
<elopio> sergiusens: how can we test that?
<elopio> balloons: yes, once we get the rc rsalveti will publish it on cdimage.
<sergiusens> elopio: new image build, or mount the .img and remove the dangling link
<balloons> elopio, I assumed as much, y
<sergiusens> elopio: I did that, worked fine
<sergiusens> elopio: sudo kpartx -avs 15.04.img; sudo rm /media/sergiusens/system-a/lib/systemd/system/multi-user.target.requires/snappy-workaround-apparmor.service; umount /media/sergiusens/system-a; sudo kpartx -ds 15.04.img; kvm_snappy 15.04.img
<sergiusens> elopio: but it requires a new image to get things going
<rsalveti> sergiusens: hm, I think mvo also published the real fix
<rsalveti> which is why he reverted the workaround
<rsalveti> sergiusens: oh, you got it
<rsalveti> sergiusens: just upload that fix then
<sergiusens> rsalveti: I just did ;-)
<rsalveti> great
<sergiusens> rsalveti: the workaround wasn't completely reverted though
<rsalveti> yeah
<sergiusens> rsalveti: btw, can you dput the latest snappy trunk?
 * sergiusens needs to get the ppu paperwork done
<rsalveti> sergiusens: sure
<sergiusens> rsalveti: thanks
 * elopio learns kpartx
<ogra_> sergiusens, seeing that you were the last one to touch the vivid livecd-rootfs in the snappy PPA, do we have a branch for that or do you just patch the package directly ?
<sergiusens> ogra_: I am not aware of a branch, I just used the packaging
<ogra_> k. sounds fine ...
<sergiusens> ogra_: same for ubuntu-core-config
<rsalveti> sergiusens: do we need to backport https://code.launchpad.net/~sergiusens/snappy/closeMe/+merge/263943 ?
<ogra_> thanks !
<sergiusens> rsalveti: nope, only required for the latest u-d-f builds to allow clean unmounts ;-)
<rsalveti> great
<sergiusens> ogra_: are you changing anything crazy? Since I want to trigger a new build soon to get a working image
<ogra_> rsalveti, so seeds definitely dont support multiarch ... (i asked cjwatson) ...
<rsalveti> ogra_: hm, that's interesting
<rsalveti> how is that done on the desktop?
<ogra_> sergiusens, one insane (test) thing and one easy and safe one
<rsalveti> or libc just gets installed when required/
<rsalveti> ?
<sergiusens> ogra_: hmmm, then let me trigger a build before that :-)
<ogra_> rsalveti, we dont have any images where foreign arch packages are preinstalled
<rsalveti> ogra_: nice
<sergiusens> ogra_: so we have a working test base and I don't need to chase my tail like a dog :-P
<ogra_> sergiusens, well, i can do it tomorrow morning (would actually prefer to) ... but it is for RC
<rsalveti> sergiusens: trigger an image now
<rsalveti> build is kind of fast anyway
<sergiusens> rsalveti: waiting for packages to publish
<ogra_> rsalveti, and i'm not sure about using :i386 in live-build, i need at least one test build to see what happens
<rsalveti> ogra_: right
<ogra_> (and indeed i have no local setup)
<rsalveti> sergiusens: gotta love launchpad
<sergiusens> rsalveti: did you read my latest blog entry? :-P
<rsalveti> sergiusens: not fully yet, in my toread
<rsalveti> new kernel landed in updates
<rsalveti> yay
<elopio> sergiusens: on your post I think that you are not taking into account that travis is not running trusty.
<rsalveti> sergiusens: package was just published
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.5ubuntu1
<Saviq> ogra_, if I edited uEnv.txt on the boot partition on a snappy Pi, it should change the kernel command line, should it? does uEnv (it's the bootloader, right?) itself talk console by any chance?
<ogra_> uboot you mean
<ogra_> yes, it talks to serial only
<ogra_> Saviq, any probs with that ?
<ogra_> (uEnv.txt is for overrides, it could well be that uboot itself sets some HW related defaults before processing uEnv.txt)
<sergiusens> elopio: we don't care, sbuild for package builds and go is avail on the platform so it is not far away from what we have today
<elopio> sergiusens: what about the calls we make to ubuntu-device-flash?
<sergiusens> elopio: that does not happen on tarmac today
<elopio> could we backport the ppa to ... lucid I think is what they have
<sergiusens> elopio: they have precise envs
<sergiusens> elopio: and we don't use ppa's in our tarmac setup
<sergiusens> elopio: nor package building
<elopio> oh, well, that's right. No much different to our present.
<sergiusens> elopio: but giving webhooks are instantly available, we can do a lot already
<sergiusens> elopio: rsalveti: ogra_ I triggered a vivid image
<rsalveti> mterry: https://code.launchpad.net/~mterry/snappy/set-sudo-15.04/+merge/263920 missing withMutex
<rsalveti> Chipaca: https://code.launchpad.net/~chipaca/snappy/fix-1461262/+merge/263917/comments/661898
<mterry> rsalveti, hah, whoops, run-checks failed but without a good error and I wasn't sure why, so I was going to let jenkins sort it out while I had lunch.  Looks like it did, thanks for the heads up  :)
<rsalveti> Chipaca: oauth/oauth_test.go:25:2: cannot find package "gopkg.in/check.v1" in any of
<rsalveti> mterry: :-)
<rsalveti> the joy of backports
<rsalveti> Chipaca: maybe we can just use gocheck to avoid a larger backport
<sergiusens> it should use gocheck, yes
<rsalveti> sergiusens: can you see why https://code.launchpad.net/~mterry/snappy/systemd-restart-15.04/+merge/263915/comments/661903 failed?
<mterry> rsalveti, yeah that is interesting.  run-checks locally *did* pass for that one -- and it's really a tiny change
<rsalveti> right
<sergiusens> rsalveti: cmd/snappy/cmd_internal_unpack.go:70:6: func readUid should be readUID helpers/touch.go:39:5: exported var ErrNotAbsPath should have comment or be unexported
<rsalveti> not related with the mr for sure
<rsalveti> sergiusens: why failing now?
<rsalveti> the check changed?
<sergiusens> rsalveti: mterry update golint
<rsalveti> right
<Saviq> ogra_, yeah, I've changed uEnv.txt and still I get garbage on boot when I have the emon board connected
<rsalveti> will just backport rev 520 then
<Saviq> ogra_, the board talks on ttyAMA0
<mterry> sergiusens, rsalveti: what's the Right way to do that in my workspace?
<sergiusens> mterry: go get -u "the go lint package" iirc
 * sergiusens takes a break
<mterry> sergiusens, thanks
<rsalveti> mterry: https://code.launchpad.net/~rsalveti/snappy/15.04-fixing-lint-errors/+merge/263956
<kyrofa> seb128, you mentioned last week that if I was willing to get my hands dirty, I could get an Ubuntu Personal-ish image up and running?
<mterry> rsalveti, I see those now too :)
<sergiusens> +1
<Saviq> ogra_, but it does seems as if it never goes to actually loading the kernel, so it might be u-boot itself is talking on tty (/me records a video)
<ogra_> Saviq, well, whats the actual kernel cmdline you end up with after booting (regardless if with or without the thing attached)
<Saviq> ogra_, right, checking that now
<rsalveti> ogra_: image finished already if you want to play with livebuild
<ogra_> rsalveti, k
<sergiusens> rsalveti: from what I see, the image is still building...
<rsalveti> sergiusens: just not yet fully imported
<rsalveti> sergiusens: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<Saviq> ogra_, yeah, it boots the right cmdline, but it never goes past u-boot when the thing's connected https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d#
 * Saviq needs to find out if u-boot talks ttyAMA0 for some reason
<Saviq> biab
<ogra_> rsalveti, bah ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7625955 ...
<ogra_> "Start in 5 hours "
<rsalveti> ogra_: that's arm64
<rsalveti> which we don't support
<rsalveti> you can cancel it
<ogra_> oh, will it still publish ?
<rsalveti> ogra_: or just let it there, lp will publish the other packages
<rsalveti> we don't have proposed for ppas :-)
<ogra_> oh, ok
<ogra_> (i thought it was more like the phone overlay PPA)
 * ogra_ kicks a build then
<ogra_> rsalveti, hmm, infinity just told me ubuntu-fan v1 isnt suitable for seeding, we should wait for v3 (which btw wont depend on dnsmasq)
<ogra_> so i'll unseed it again :P
<rsalveti> ogra_: oh, alright :-)
<rsalveti> we still need the kernel sru to be in place anyway
 * ogra_ sighs ... this is getting ebarassing 
<ogra_> most awkward seed changelog ... in -> out -> in -> out ..
<rsalveti> hahah
<sergiusens> ogra_: seeding in rolling should be fine though
<sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/snappy/originsOrNamespaceWhatever/+merge/263960
<ogra_> damned !
<ogra_> i just triggered a vivid phone build
<ogra_> sigh
<rsalveti> ogra_: hahah
<ogra_> and do you know why ?
<sergiusens> or Chipaca: https://code.launchpad.net/~sergiusens/snappy/originsOrNamespaceWhatever/+merge/263960
<ogra_> because i couldnt mark the whole line at the size the terminal window was ... the overlay scrollbar didnt let me reach the last letter ... so i maximized and ended up in the wrong line
<ogra_> yay design
<ogra_> hmpf
<ogra_> and snappy cant build due to a lockfile
<ogra_> which i assume comes from the stalled arm64 build of sergiusens image (which i just cancelled)
<ogra_> damn
<sergiusens> ogra_: hey, don't go around pointing fingers at me :-P
<ogra_> sergiusens, alll your fault that the arm64 builders are so slow !!!
<ogra_> aha, just took a moment
<ogra_> ok, that didnt go so well
<ogra_> E: Unable to locate package libc6
<ogra_> so just add_package wont work either ...
<bschaefer> Hello, just dd'd the ras pi 2 onto an SD and everything seems to be working except one issue
<bschaefer> "Net initialization skipped"
<bschaefer> and no ip or network at all on the image :(
<sergiusens> Chipaca or rsalveti: https://code.launchpad.net/~sergiusens/snappy/seccompError/+merge/263964
<sergiusens> rsalveti: not sure I can get this one done by today https://bugs.launchpad.net/snappy/+bug/1450169 I need to leave for a bit
<ubottu> Ubuntu bug 1450169 in Snappy 15.04 "snappy update downloads non-namespaced package when fork is installed" [High,Triaged]
<rsalveti> sergiusens: are you going to be around later today?
<rsalveti> I'll be off for a few as well, but back in a few hours
<rsalveti> and going to trigger a new image
<ogra_> rsalveti, so the multiarch doesnt work (and a meta package wont help)
<ogra_> it doesnt find any i386 packages at all during build
<ogra_> i'll roll back the libc part but keep gdbserver in ...
<ogra_> (and take a look tomorrow)
<balloons> elopio, so i've setup https://wiki.ubuntu.com/Snappy/OpenHouses/20150707 and tweaked https://wiki.ubuntu.com/Snappy/OpenHouses/. Going to work a little on the form. Let me know if there's anything els
<sergiusens> rsalveti: in 4hours or so, I have a dentist issue coincidentally :-P
<elopio> balloons: thanks.
<sergiusens> I broke a tooth last night :-P
<sergiusens> eating popcorn...
<elopio> sergiusens: ...rioting after the game.
<ogra_> sergiusens, did you pick the one with extra butter and concrete ?
<rsalveti> sergiusens: eating a popcorn?
<balloons> elopio, http://bit.ly/1KHQZF6 is the form
<elopio> balloons: +1. Thanks.
<kgunn> https://pastebin.canonical.com/134686/
<kgunn> sergiusens: wonder if you might know...this was working last thurs, was just trying and got that error ^
<kgunn> it actually created an image, but it just stuck at "booting from disk"
<elopio> kgunn: if you are on vivid, you can get the fix of that using the tools-proposed ppa.
<elopio> kgunn: if you are on wily, just upgrade.
<kgunn> ta
<kgunn> needed to upgrade
 * kgunn considers probably should just move to wily
<jdstrand> Saviq: hey, did you get an answer to emonhub?
<jdstrand> Saviq: the problem is that the review tools are expecting snappy-systemd in the click compatibility manifest and a corresponding meta/emonhub.snappy-systemd in the snap produced by snappy build
<jdstrand> Saviq: how did you generate the snap? snappy build? what version of snappy?
<jdstrand> Saviq: I see that you uploaded to the store. I'll comment there
<jdstrand> sergiusens: fyi, I left feedback in https://myapps.developer.ubuntu.com/dev/click-apps/2954/feedback/
<jdstrand> sergiusens: it looks like snappy perhaps dropped "snappy-systemd" from the hooks db in the click compatibility manifest
<jdstrand> sergiusens: either it is a bug in snappy or a bug in the review tools (can we please have the review tools run as part of the go build/check/whatever or the self-tests?)
<jdstrand> Chipaca: fyi, I came across that ^. I saw in backscroll from days ago about re-enabling the review tools. looks like an incompatible change rolled in recently
<elopio> jdstrand: we have just added a test for snappy build that does some simple checks.
<elopio> jdstrand: could you please report a bug, or make a card, or explain here how to reproduce that bug so we can automate it?
<elopio> should be easy.
<jdstrand> elopio: I think there is already a card for it
<jdstrand> let me see if I can find it
<jdstrand> I can't seem to find it
<jdstrand> it keeps coming up in email threads
<elopio> jdstrand: https://trello.com/c/Gp9gtKiu/59-self-tests-for-snappy-build
<elopio> I see your comment in there.
<elopio> we added tests for one correct snap and two simple errors.
<elopio> I'll make another card to extend the suite.
<jdstrand> elopio: you are doing 'click-review /path/to/snap'?
<elopio> jdstrand: no, just snappy build.
<jdstrand> elopio: ok, so right now snappy build disabled the click-review run
<elopio> I saw the code for click-review in the build command commented out.
<jdstrand> elopio: right. this was because the review tools were out of date cause the yaml was changing so fast and the review tools weren't updated in lock step
<jdstrand> elopio: so, I got them all up to date, but it looks like something changed in snappy again without a corresponding mp for the review tools
<elopio> I see. So update, uncomment, and add test.
<jdstrand> elopio: I'm happy to do the change in the review tools this time so that they are on good footing, but I want to make sure I understand the change and where it landed
<jdstrand> depending on the test, a few simple tests aren't going to be enough though
<elopio> jdstrand: for that part, lets wait for sergiusens.
<jdstrand> as it happens, if the simple yaml had a 'services' definition, it would have this time
<elopio> he had a fight with some chilean popcorn ;)
<jdstrand> but we are going to want build tests for all yaml
<jdstrand> if we want to be sure to avoid this in the future
<elopio> jdstrand: we should probably add some basic tests in the snappy branch, an extensive suite in click-review, and a way to trigger the click review tests when snappy is updated.
<jdstrand> but sure, I'll wait for sergiusens
<jdstrand> elopio: the review tools has extensive tests itself
<jdstrand> elopio: the problem is what is being fed to it
<jdstrand> if snappy build starts outputing something new or different...
<jdstrand> it seems the right place is to have a collection of simple but exhaustive snaps that click-review can iterate over
<jdstrand> personally, I think that should be in snappy itself or maybe the self tests
<jdstrand> well, probably not the self tests, those run on the image
<elopio> jdstrand: yes, we currently are doing the builds on the image. Is that wrong?
<elopio> seemed a lot more simple than to split the suite into running some in the testbed and some in the host.
<jdstrand> elopio: it isn't wrong per se, but I didn't think the review tools would be available on the image (they are python with various python deps)
<elopio> jdstrand: it works now. I suppose it will break soon.
<jdstrand> elopio: yes, as soon as the review tools are reenabled
<elopio> we are thinking about containers inside the testbed for these cases to make it easier to handle the adt-run calls. We'll have a prototype soon.
<jdstrand> that should be fine. install tests in a container won't, but build, sure
<elopio> a container that can do builds. We add a bunch of yamls and iterate over them. Shouldn't slow the selftests a lot.
<elopio> well, a lot more. They are already slow.
<rsalveti> comfy should help with that
<rsalveti> once we get the container in place
<rsalveti> for usual builds and such
<rsalveti> the same container will also be the bed for snapcraft, so should be good
<elopio> the future will solve all our present problems :)
<rsalveti> that's true, but comfy should be around the corner
<rsalveti> just waiting lool to return from his vacation
<elopio> now build in the container and install out of the container, I don't know how to handle that case. Federico will probably come with a clever solution.
<jcastro> is there a generic snappy x86 image that would work on like a NUC or old laptop?
<elopio> jcastro:  I see you can do:
<elopio> sudo ubuntu-device-flash --verbose core rolling --channel edge --oem generic-i386 -o snappy.img
<elopio> but I haven't tried that.
<rsalveti> mterry: https://code.launchpad.net/~mterry/snapcraft/debian-packaging/+merge/263937/comments/661944
<mterry> rsalveti, huh...  i depend on python3, would have expected that to include python3-minimal.  I didn't build in pbuilder though, oddly enough.  will make I pass in that
<rsalveti> yeah, it's a bit weird
<mterry> rsalveti, oh weird, dh_auto_clean tries to do a python2 thing by default (sigh, the world is still unready for py3-only stuff)
<Saviq> jdstrand, thanks, no, didn't get an answer et
<Saviq> +y
<elopio> I'm going to take a break.
<elopio> rsalveti: let me know if you need me to do something for the RC, and I'll get to it when I get back.
<rsalveti> elopio: sure, just started a new image build, which should be close to what we want
<rsalveti> just missing one more mr from sergiusens and the other change from ogra
<rsalveti> but we'll see if we can get to that tomorrow
<rsalveti> going to be off for a few as well, time to grab some dinner
<rsalveti> be back later
<Saviq> jdstrand, so if I understand correctly, this basically means that something in the build process failed?
#snappy 2015-07-07
<sergiusens> rsalveti: I am back
<sergiusens> rsalveti: jdstrand elopio I think that systemd change was orchestrated by Chipaca and mvo; I didn't have a part on it, sorry.
<sergiusens> now I think snappy-systemd as a hook was dropped for both 15.04 and rolling and it's all implemented in snappy now.
<sergiusens> it is just apparmor that remains
<sergiusens> rsalveti: https://code.launchpad.net/~sergiusens/snappy/qualifiedUpdate/+merge/263987
<elopio> ping pitti: do you have any clue about why this is happening? https://bugs.launchpad.net/snappy/+bug/1468868
<ubottu> Ubuntu bug 1468868 in Snappy "Selftests print a lot of messages about time stamps in the future" [Undecided,New]
<pitti> elopio: I replied in the bug
<elopio> thanks pitti. I'll ask what timezone we use on the image built.
<elopio> and we'll probably send a patch to you with the warning=none
<pitti> elopio: that should be simple to fix in autopkgtest, I'd just like to be able to reproduce it first; I think I see them occasionally, but I've never used --warning and thus I'm not 100% sure it will suppress that
<elopio> pitti: we see it on every ./run-checks on snappy. So it will be easy to confirm.
<pitti> lib/VirtSubproc.py:320:                'tar --create --absolute-names -f $d/autopkgtest-tmpdir.tar'
<pitti> lib/VirtSubproc.py:337:                ' tar --extract --absolute-names -f $d/autopkgtest-tmpdir.tar;'
<pitti> elopio: ^ those two are what you want to change
<pitti> /usr/share/autopkgtest/python/VirtSubproc.py
<elopio> pitti: ack. I'll try tomorrow.
<elopio> thank you!
<pitti> sorry, you want that too:
<pitti> lib/VirtSubproc.py:511:        taropts[idst] = '--preserve-permissions --extract --no-same-owner'
<pitti> I'll put those in the bug
<dholbach> good morning
<seb128> hey dholbach
<mvo> elopio: hey, are you still up by chance?
<elopio> mvo: o/
<mvo> elopio: nice! what do I need to run to run the new _intergration-tests ?
<mvo> elopio: the command in the readme gives me a error "failure File not found: snappy"
<elopio> mvo: install the latest autopkgtest
<elopio> mmm, I haven't seen that one.
<mvo> elopio: so the command from the readme should work?
<mvo> elopio: just running that in the top-level dir? or inside _integration-tests?
<mvo> fwiw, I have autopkgtest 3.15.1
<elopio> mvo: no, I have a branch that updates the REAMDE, in progress.
<elopio> mvo: that's alright. With that, just ./run-checks
<mvo> elopio: thanks!
<elopio> mvo: http://bazaar.launchpad.net/~elopio/snappy/bbb_integration/view/head:/_integration-tests/README.md
<mvo> elopio: neat!
<mvo> elopio: thanks, I have what I need now :)
 * ogra_ grumbles about live-build
<elopio> mvo: no problem.
<mvo> ogra_: heh, I thought you like it?
<elopio> fgimenez: please follow up the publishing of the RC on cdimage.ubuntu.com.
<seb128> hey mvo
<elopio> I'm going to be. be back soon.
<ogra_> mvo, well, until i was asked to somehow get libc6:i386 into the amd64 images :P
<elopio> s/be/bed
<mvo> hey seb128
<mvo> ogra_: heh
<seb128> mvo, the personal image boots to a working unity8 desktop session now ;-)
<mvo> seb128: \o/
<mvo> yay!
<fgimenez> good morning
<fgimenez> elopio, ack thanks (get some rest :)
<mvo> ogra_: let me know if there is anything I can do to help with the libc stuff
<fgimenez> mvo, thanks a lot for the AddCleanup functionality :)
<mvo> hey fgimenez - you are very welcome
<mvo> (was fun :)
<fgimenez> mvo, waiting for elopio's opinion i've added a couple of comments via email to the mp and they don't show up (hopefully they will :) shall i forward them to you?
<Chipaca> blame Chipaca!
 * Chipaca parties
<mvo> fgimenez: please forward it to me
<mvo> chey Chipaca
<mvo> Chipaca: its a bit early to party, no ;) ?
<Chipaca> mvo: seems like we got the blame for breaking something again
<Chipaca> mvo: nevah!
<mvo> Chipaca: or did you had a extra strong cup of coffee ?
<Chipaca> i think i'm going to have a *second* cup of extra strong coffee
<mvo> Chipaca: meh, stuff broke? what/where
<Chipaca> with some ginger snaps
<mvo> lol
<Chipaca> mmmm, yep
<fgimenez> mvo, done thx :)
<mvo> ta
<mvo> fgimenez: excellent suggestion!
<fgimenez> mvo, thx it's built upon your proposal :)
<fgimenez> mvo, we just should take care to call the SnappySuite.TearDownTest from the tests in other suites that define a TearDownTest, right?
<mvo> fgimenez: indeed,thanks! I did not check that
<JamesTait> Good morning all; happy Chocolate Day! ð
<yisamu> Hey guy! How are you?
<yisamu> guys!
<yisamu> I need an advice
<yisamu> Have anyone running lxc on snappy?
<yisamu> where should I dig to get it working?
<yisamu> Please advice
<ogra_> mvo, http://paste.ubuntu.com/11834942/ ... i guess a hook is the only possibility (i tried differnt config opts, but cant convince live-build to use multiarch)
<ogra_> mvo, one thing that isnt clear to me is if i need to explicitly remove the package lists that this apt-get update call creates ... (i guess that bloats the image) or if we already have some mechanism that wipes them
<ogra_> oh, crap ... we actually do have code for this ... but thats run in the first hook
<ogra_> ok, this should be good then http://paste.ubuntu.com/11834973/
<mvo> ogra_: looks good
<ogra_> ok, let me try a build with that in place then
 * ogra_ kicks off a 15.04 build and crosses fingers
<damjan> I have snappy running in kvm, how can I change the 'channel' it's on
<ogra_> hmm, that didnt work ... i wonder why
<seb128> nice, with yesterday snappy updates the personal grub menu works now
<seb128> only one "system-a" entry and it boots
<ogra_> OH !
<ogra_> it did work ...
<ogra_> but why is it executed so much earlier in the log ...
<seb128> what is earlier in the log?
<ogra_> seb128, my hack ...
<mvo> seb128: do you also get a system-b when you update :) ?
<seb128> oh, k
<ogra_> i added a hook for installing libc6:i386
<seb128> mvo, need an update to try that ;-)
<mvo> you have the power to create one ;)
<seb128> mvo, I'm going to kick a new image later on
<seb128> right
<ogra_> with a 12-* prefix ... so i would expect it to be executed after 11-* ... but seems it is executed way way earlier
<seb128> I just want to do some small changes first
<ogra_> well, at least it worked, libc6:i386 is installed now
<ogra_> hmm, i canceled the arm64 image build ... why do i get a failure mail for that
<dholbach> balloons, https://ubuntuonair.com/ is updated
<Aabdyldaev> Hi All!
<mvo> sergiusens: quick question, I'm preparing to send the patch(es) for shadow upstream with the --extra-users. I was curious about the use_extrausers, and I wonder if 1010_extrausers and 1011_extrausers-toggle should be merged? it seems to me that your approach is more localized and that maybe we don't need (most) of 1010 anymore with that? expect that I'm not sure if anything relies on the auto-detection and needs updating for the new --extrausers
<sergiusens> mvo: morning! Maybe merging is the right thing to do, but passwd relies on auto detection
 * ogra_ still finds xnox' comment interesting ... to bad he didnt answer my question on the bug 
<sergiusens> ogra_: whataya talking about?
 * sergiusens reads the backlog
<ogra_> sergiusens, about the extrausers bug
<ogra_> Bug 1323732
<ubottu> bug 1323732 in adduser (Ubuntu) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [High,In progress] https://launchpad.net/bugs/1323732
<rsalveti> sergiusens: https://code.launchpad.net/~sergiusens/snappy/qualifiedUpdate/+merge/263987 got one question from mvo
 * Chipaca waiting so long for a snappy build, he's starting to consider making build parallel
<seb128> hum
<mvo> Chipaca: wuuut? how long does it take?
<mvo> sergiusens: aha, I see, thanks, that makes perfect sense now
<Chipaca> mvo: 7 minutes of cpu time and counting
<sergiusens> Chipaca: get a newer laptop :-P
<mvo> Chipaca: woah, this includes the integration tests or really just the building? and if just the building what are you building this on?
<sergiusens> mvo: I don't mind changing it if you want, but the struct isn't that big to require a pointer
<mvo> Chipaca: or is it all dependencies?
<Chipaca> mvo: building a *snap*, not snappy
<Chipaca> sergiusens: ^
<Chipaca> 200M of libraries
<mvo> sergiusens: sure, its fine, I was just curious if there was a reason (i.e. I wanted to learn new tricks ;)
<mvo> Chipaca: ohhhh, sorry
<sergiusens> mvo: if so, we should also consider 'for i := range snaps' instead of for _, snap := range snaps' across the board (which we have debated a bit with Chipaca in some cases)
<mvo> sergiusens: if we make it use the struct instead of the pointer you mean?
<Chipaca> sergiusens: mvo: where is this?
<Chipaca> ah, yes, if it's going to be a struct and not a pointer, no copying in loop :)
<sergiusens> Chipaca: if the struct isn't hug, it's fine
 * Chipaca likes structs that are hugs
<sergiusens> err hugged I meant!
<sergiusens> :-P
<sergiusens> mvo: that MP brings in the issue that QualifiedName for a directory name was probably a bad idea as qualified names should always include the origin
<Chipaca> 15 minutes ...
<mvo> sergiusens: so whats the advantage of using the struct directly instead of the pointer? again, I'm just in learn-new-tricks land right now :)
<mvo> sergiusens: QualifiedName> hrm, the sometimes-there-is-a-origin-sometimes-not is annoying :/
<mvo> Chipaca: what is it doing? is it gzip that chewing all the cpu?
<mvo> rsalveti: anything urgent for the release I should look at ? otherwise I will just continue with my cards
<Chipaca> mvo: i presume so
<Chipaca> mvo: although gzip wouldn't take this long
<Chipaca> so i dunno
<rsalveti> mvo: nops, just missing this last mr from sergiusens
<sergiusens> mvo: there is always going to be one now on new systems
<mvo> sergiusens: yep
<sergiusens> mvo: well, if you use the latest u-d-f from wily at least
<sergiusens> mvo: but most of that code in there is to contemplate upgrades
 * mvo nods
<sergiusens> rsalveti: that just needs approval or an explicit please fix this from my PoV ;-)
<mvo> sergiusens: done, I didn't intend to block the MP, was just curious about the rational
<sergiusens> mvo: no worries.
<rsalveti> requested a new build for ubuntu-snappy and will trigger another image once it gets published
<rsalveti> ogra_: all good from the livecd-rootfs side, right?
<ogra_> yep
<ogra_> i just did build one btw
<ogra_> (to check the libc6:i386 addition)
<rsalveti> ogra_: great
<rsalveti> so we should be good
<ogra_> yeah
<ogra_> oh ... jolla gets split up
<ogra_> (into HW ans SW companies it seems)
<ogra_> *and
<Chipaca> ok, can confirm it's the actual tar creation that is this slow
<Chipaca> wth
<ogra_> Chipaca, tar itself or the compression ?
<Chipaca> poteito, potahto
<ogra_> haha
<Chipaca> i'd have to add more prints for that :)
<ogra_> tomeito tomatoh ?
 * Chipaca wishes gdb would actually work
<Chipaca> tomeito tomahto
<Chipaca> anyhow, it's finished; the 15+ minute one might've been a bug in a for-testing snappy i had lying around
<rsalveti> launchpad is so slow sometimes, more than 20 minutes and package is still not published
<ogra_> arm64 holding up the publication ?
<rsalveti> ogra_: no, aborted that build as well
<rsalveti> just waiting the armhf one to be published
<ogra_> weird
<rsalveti> so I can trigger another build
<rsalveti> sergiusens: elopio: fgimenez: latest tools published at tools-proposed
<rsalveti> we should use that ppa when validating the RC image
<rsalveti> so we can also validate the tools at the same time
<fgimenez> rsalveti, ack thanks
<rsalveti> yay, published
<sergiusens> ogra_: link?
<ogra_> sergiusens, ?
<ogra_> http://www.ubuntu.com/
<ogra_> thats a link :P
<sergiusens> ogra_: oh, jolla
<ogra_> ah, that
<sergiusens> good golly jolla
<ogra_> yeah,. they are splitting up into a HW company and a SW licensing sales one
<elopio> good morning.
<ogra_> (only german links)
<sergiusens> ogra_: to support the russian deal maybe?
<ogra_> yeah, perhaps
<ogra_> though the deal might have been fake
<ogra_> i just heard that russia now demands that all phones come without OS
<rsalveti> wtf
<fgimenez> hi elopio
 * ogra_ twiddles thumbs waiting for google
<elopio> hey fgimenez.
<elopio> so, do we have an rc to test today?
<ogra_> sergiusens, in case you want to use google translate http://www.golem.de/news/sailfish-os-lizenzierung-jolla-spaltet-sich-auf-1507-115094.html
<balloons> elopio, rsalveti http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/ is still 404
<rsalveti> balloons: yeah, working on that
<rsalveti> elopio: the image is building
<balloons> :-) ok, just wanted to make sure
<rsalveti> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<elopio> 51 minutes, that will be just in time :)
<seb128> Chipaca, sergiusens, mvo, the new grub config doesn't work well on personal, after install it has one install "system-a" which works, after a "snappy update" it has 4 entries which doesn't have labels mentioning system-a/b
<seb128> booting the default boots the b partition
<seb128> but then a snappy rollback ubuntu-core doesn't boot back to the system-a
<conyoo> QUESTION: can i install 10 snaps at the same time?
<conyoo> oh.. am i early?
<sergiusens> seb128: are you using the latest snappy?
<seb128> sergiusens, yes, upgraded this morning
<sergiusens> seb128: because we aren't running update-grub anymore, so there should be only 1 grub entry at all times
<seb128> sergiusens, oh, the image I did "snappy upgrade" on is likely having the old version installed
<seb128> I guess I need to kick a new build to be able to try the upgrade for today's image
<balloons> rsalveti, elopio ready for the hangout as well? Who all will be joining dholbach and I?
<conyoo> -40 minutes
<elopio> conyoo: yes, you are too early. And no, snappy install receives only one package as an argument.
<elopio> you would have to call it ten times.
<conyoo> :'(
<conyoo> thanks elopio
<elopio> balloons: ready here. I'm hoping the whole team will join.
<balloons> elopio, awesome
<balloons> no worries conyoo, we'll still answer  your questions until then :p
<conyoo> :D nice
<conyoo> but is it technically possible to install more than 1 snap at the same time? i mean.. they are isolated from each other
<conyoo> would be really nice to sudo snappy install snap1 snap2 snap3
<Chipaca> conyoo: you mean, can you have more than one snap installed at the same time?
<conyoo> yep
<conyoo> no
<conyoo> NO
<conyoo> i want to install 10 snaps at the same time in parallel
<conyoo> and download
<Chipaca> conyoo: you can't currently do that
<Chipaca> conyoo: why do you want to do that?
<conyoo> oh :'(
<conyoo> oh well :d
<conyoo> but it's not theoretically impossible?
<Chipaca> conyoo: no, it's not theoretically impossible.
<conyoo> super! thanks
<balloons> can you have more than one active snappy process?
<sergiusens> Chipaca: webdm is doing that today...
<Chipaca> balloons: there is currently a single lock for all writes
<sergiusens> parallel download unpack
<Chipaca> sergiusens: nice, i missed that, good job
<sergiusens> locking needs to happen after downloading at the least
<Chipaca> locking *could* be made to be per-package
<Chipaca> but it'd get fiddly :)
<balloons> gotcha.. that would be the only way. I assumed a global lock
 * conyoo awesome! brb beer low
<Chipaca> balloons: it does have a global lock, but only because it was the quickest way forwards; we don't have global state that would require it
<Chipaca> and one could argue that installing things is not supposed to be the most common state of a snappy system, so it isn't particularly high priority
<Chipaca> but one won't
<mterry> sergiusens, I switched the snapcraft trunk yesterday to our new python-based version.  Now tarmac is giving me crap: https://code.launchpad.net/~mterry/snapcraft/debian-packaging/+merge/263937
<mterry> sergiusens, how does tarmac know what to install (i.e. pep8)?
<Nikolay> Hello! Does anyone know how to read ADC data from BeagleBone Black with Ubuntu Snappy on it? There is no /sys/bus/iio file there.
<mterry> sergiusens, do I just add sudo apt-get install lines to .tarmac.sh?
<sergiusens> mterry: I'll install that, but no, we aren't rnning in chroots
<mterry> sergiusens, there are probably more packages too -- how do other packages handle this?
<mterry> sergiusens, I mean, more dependencies too
<josepht> the link to the RC image here is broken: https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
<balloons> hey josepht, it's currently building..
<elacheche> josepht, try this http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<balloons> it is indeed fresh fresh fresh
<elacheche> balloons, the workwhop will use a new build?
<elacheche> Ah ok!
<balloons> yes, I think the builder is going to cut it close, hehe :-)
<rsalveti> yeah, but the annoying sync that makes the image public might not run in time =\
<rsalveti> forgot this takes ages
<rsalveti> the image can be generated with ubuntu-device-flash at least
<balloons> rsalveti, is there a matching rev # on the edge channel or ?
<rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem generic-amd64 --install=webdm --enable-ssh --output ubuntu-15.04-snappy-amd64-generic.img
<rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem beagleblack --install=webdm --enable-ssh --output ubuntu-15.04-snappy-armhf-bbb.img
<rsalveti> image 117 for amd64 and 118 for armhf
<rsalveti> make sure to have https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed in your system
<elacheche> Anyone will use KVM? All of you have IoT hardware?? o_O x)
<balloons> elacheche, I've done it with KVM. No IoT hardware for me at the moment so :-)
<elacheche> Good to know that am not alone balloons x)
<balloons> rsalveti, will the image be ready or should we tell folks to use u-d-f as you've laid out above?
<woobadooba> hi all
<balloons> howdy woobadooba
<sergiusens> balloons: do we /join #ubuntu-on-air or is eveything going to be discussed here?
<adam8157> ypwong: I almost fogot, thanks to google calendar, XD
<balloons> everything will be here sergiusens
<elopio> balloons: updating some steps to use udf, because the sync won't finish on time.
<balloons> elopio, ok, I'll leave you to it. Thanks for updating the wiki
<rsalveti> balloons: elopio: http://paste.ubuntu.com/11835948/
<woobadooba> QUESTION: why is the irc chatbox under the video so tiny?
<balloons> woobadooba, is it really small
<balloons> ?
 * balloons looks
<woobadooba> yes
<elopio> balloons: what's the url for the hangout?
<balloons> hmm.. indeed. I wonder if we can make it larger
<woobadooba> the video is wider than the chatbox :))
<mariogrip> ChrisTownsend: I dunno if you saw this or not https://code.launchpad.net/~mariogrip/unity8-preview-lxc/unity8-preview-lxc-snappy I made it work with the snappy preinstalled personal tarballs, It boots but, does not seem to work correctly...
<eager1> Hi
<woobadooba> phew fixed it :d
<woobadooba> i just hached the html from chrome
<woobadooba> LOL
<balloons> woobadooba, I updated the width to be the same as the video. Check it out now
<woobadooba> balloons: perfect
<ChrisTownsend> mariogrip: Sweet!  I knew we would have to support that soon.
<elacheche> Here we go!
<ChrisTownsend> mariogrip: In what way does it not work correctly?
 * olli waves
<balloons> woobadooba, thanks for pointing it out.. you are right it was tiny ;-)
<woobadooba> balloons: thanks for fixing it so fast :D
<ypwong> adam8157 :)
<elacheche> ogra_, the img still building?
<ogra_> elacheche, which one ? RPi you mean ?
<elacheche> The one in the wiki ogra_
<elacheche> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/ubuntu-15.04-snappy-amd64-generic.img.xz
<mariogrip> ChrisTownsend: I need to do some debugging, but something is crashing. I get black screen with cursor.
<ogra_> elacheche, ah, i dont know if we actually have a new img.xz yet ... i think we are currently testing directly via ubuntu-device-flash from the 15,.04 edge channel
<ChrisTownsend> mariogrip: Ah, ok.  If you don't know already, try looking in /var/log/lightdm/unity-system-compositor.log and/or ~/.cache/upstart/unity8.log.
<ChrisTownsend> mariogrip: When I have some time, I'll try this too.
<ChrisTownsend> mariogrip: Thanks for working on this!  This is great!
<elacheche> ogra_, so we can't test using KVM? Should we just download the old IMG for KVM?
<rsalveti> elacheche: we're still waiting the publisher
<rsalveti> elacheche: you can build yourself with ubuntu-device-flash
<ogra_> elacheche, you should be able to use ubuntu-device-flash
<rsalveti> https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
<ogra_> (or yes, you would need to wait)
<rsalveti> there are instructions in there on how to build it
<mariogrip> ChrisTownsend: Awesome, i will do some more debugging and ping you when i get it working :)
<elacheche> thx rsalveti ogra_, I'll try that
<ogra_> :)
<ChrisTownsend> mariogrip: Great, thanks again!
<alecu> kyrofa: one thing I forgot, not only we have to include the snappy scope, but we also need webdm in the image
<alecu> seb128: is there a way to add a snap package to the seed?
<kyrofa> alecu, indeed, good point
<alecu> if not, we may need to repackage webdm as a deb
<kyrofa> alecu, although in the most recent Core image, webdm was preinstalled
<elacheche> ogra_, rsalveti unfortunately the PPA don't support 12.04 x(
<elacheche> Think that I should go home and use my home laptop x)
<seb128> alecu, no
<alecu> kyrofa: we need to check with seb128 if webdm is preinstalled in the Personal image too
<seb128> it's not
<dholbach> if you have questions, please prefix them with QUESTION: so we can more easily pick up the questions on the hangout
<ogra_> elacheche, oh, yeah, 12.04 is a bit ancient ... but ubuntu-device-flash is a static go binary
<woobadooba> QUESTION: when is the snappy personal image ready to download (amd64)?
<seb128> alecu, kyrofa, I guess the way to pre-install snap is to add them to the udf command that builds the image
<ogra_> elacheche, theoretically it could work on 12.04 if you just dpkg -i the deb package for trusty (14.04)
<seb128> woobadooba, subscribe to the snappy-devel list, it's going to be announced there
<alecu> seb128: that sounds good, thanks.
<seb128> alecu, yw
<woobadooba> seb128: what's a mailing list?
<ogra_> woobadooba, hmm, you just pointed out a flaw in our planning, we should have invited seb128 to this ubuntuonair ... he works on personal
<woobadooba> joking but eww
<woobadooba> thanks
<seb128> woobadooba, https://lists.ubuntu.com/mailman/listinfo/snappy-devel
<kyrofa> seb128, oh, that's pretty easy
<woobadooba> thanks seb128
<ogra_> dholbach, ^^^ how could we forget to invite the french guy :)
<woobadooba> and ogra_
<seb128> yw
<tsimonq2> QUESTION: When do you think it will be ready for Ubuntu Desktop? (IF APPLICABLE)
<woobadooba> QUESTION: is snappy fit for gigabit home routers?
<leafbold> QUESTION: Do you plan to have a possibility to mark official/verified snap packages, to allow users to differentiate between third party packages of a software and a package build by the dev.
<mzanetti> so far the theory :)
<tsimonq2> QUESTION: What is the delay on this Hangout?
<yisamu> QUESTION: Hey guys! are planning to add support for openvswitch, btrfs, lxd  in snappy itself or shell I look into making framework with it?
<rsalveti> https://launchpad.net/snappy/+milestone/15.04.2
<jcastro> QUESTION: How straightforward is it to install snappy on a normal x96 box, like say an Intel NUC?
<jcastro> I meant x86 of course. :D
<sergiusens> jcastro: you scared me there for a bit... new arch to support and all :-P
<tsimonq2> jcastro, It is probably pretty universal. Just my guess. :)
<mzanetti> QUESTION: I've managed to snappify my project with services, apps and everyhting. seems working so far. That project supports plugins. Can other people somehow publish plugins for my service through the store?
 * sergiusens leaves the real answers for the hangout
<ogra_> you can just dd the img to a USB stick and it should boot right away
<jcastro> tsimonq2: yeah I just want to know if I can just dd a stick and go to town?
<woobadooba> QUESTION: will the ubuntu phones use snappy in the future (whenish)?
<tsimonq2> jcastro, Good QUESTION hahahahaha
<ogra_> jcastro, yup. you can
<kyrofa> QUESTION: How do I enable i2c on the raspberry pi 2 using Ubuntu Core?
<jcastro> yeah, that option isn't on the instruction page so I was wondering if it was that simple
<sergiusens> pun for ogra_ :P
<balloons> here's the channel guide: https://developer.ubuntu.com/en/snappy/guides/channels/
 * ogra_ hides 
<jcastro> ogra_: good to know! flashing now. :D
<bschaefer> hello, so I flashed an SD card with the default raspi2 image, but it doesn't seem to support networking at all? Is there a different image or do i have to make my own?
<alecu> QUESTION: "snappy" is used for naming so many things that it's starting to be difficult to understand from context. (the OS that uses snap packages, the command line tool, the package format, and perhaps something else). Can we please start calling things using other names? (eg, the OS would be "Ubuntu Core" instead of "snappy", etc)
<kyrofa> bschaefer, I did that last week and DHCP worked fine...
<kyrofa> bschaefer, only ethernet, of course
<balloons> thanks for the questions guys.. we'll get started answering them in a just a moment. Great questions!
<bschaefer> kyrofa, right, ethernet wasnt being picked up sadly :(. (also didnt see an online demo was going on opps!)
<ogra_> bschaefer, networking definitely works for me and all testers ...
<elopio> https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
<bschaefer> ogra_, well super sad face, i see "net init skipped" on boot
<ogra_> bschaefer, you are not usin a wlan dongle or some suchm right ? you are talking about the wired NIC
 * bschaefer re-installs and hopes something broke
<bschaefer> ogra_, yup just a straight ethernet cable
<ogra_> (wlan works but needs manual tinkering)
<bschaefer> ogra_, and i tested it on a different raspi2 image (and it worked fine)
<bschaefer> so its not hardware
 * bschaefer tries re-installing
<biezpal> QUESTION: What about Java platform on Snappy?
<balloons> for those who want to help, this is the wiki page that should let you follow along with Leo: https://wiki.ubuntu.com/Snappy/OpenHouses/20150707
<seb128> sergiusens, mvo, it seems like the personal device tarball increased by 20+M since yesterday, do you know why/if any of the recent changes can explain that?
<saulo> QUESTION: how does configuration files behave between updates?
<ogra_> seb128, i included gdbserver and libc6:i386 in the core seed (respectively for imbc6 i needed a hook in livecd-rootfs)
<ogra_> but that shouldnt make up 20M
<ogra_> s/imbc6/libc6/
<seb128> ogra_, that should be in the rootfs not the device tarball no?
<ogra_> yeah
<ogra_> i didnt touch the device bits
<seb128> yeah, so that's not that
<ogra_> yeah, sorry, missed that you said device
<sergiusens> seb128: maybe diff the .manifest?
<sergiusens> oh, I missed the 'device' part of the comment as well
<ogra_> heh
<sergiusens> feel free to log webdm bugs as well
<balloons> For those willing to try, please remember to leave your feedback as well! http://bit.ly/1KHQZF6
<ogra_> sergiusens, url ?
<ogra_> :)
<sergiusens> ogra_: http://bugs.launchpad.net/webdm
<kyrofa> seb128, if we package the snappy scope as a .deb to be on the Personal image, how is it updated?
<seb128> kyrofa, uploads to ubuntu
<ogra_> kyrofa, with the next image build
<seb128> kyrofa, but you might just want to make it a snap and have image built with that snap preinstalled otherwise...
<kyrofa> seb128, I can do either/both. It's really whatever is easiest for you
<seb128> kyrofa, having a snap is probably easier since it's no work
<seb128> unsure if it's "right" though
<seb128> if that should be part of the core image or if having it a a snap is fine...
<seb128> we can maybe start with a snap
<seb128> easier to test/update
<kyrofa> seb128, kgunn might have some more thoughts there
<seb128> yeah
<sergiusens> mterry: pep8 is installed
<balloons> if you have a question, feel free to ask. Just prefix with QUESTION, and I'll add it to the list to be answered :-)
<balloons> And again, those willing to try running snappy, give it a try now and let us know how it works for you! http://bit.ly/1KHQZF6
<kgunn> kyrofa: if it's simple +1 to it being a snap
<olli> nicely put ogra_... snappy is ready for desktop,but desktop might not be ready
<sergiusens> ogra_: https://insights.ubuntu.com/2015/05/13/iot-world-snappy-for-whitebox-switches/
<sergiusens> switches ^
<tsimonq2> QUESTION: Define your terminology when you say "Snap"
<p_lorenz> QUESTION: what about official support of the raspberry pi 2 - will it come?
<adam8157> QUESTION: is there a doc like "snappy from scratch"? which we could learn the system-level mechanism from, also will help transplanting
<kyrofa> kgunn, alright, I'll play with that as soon as I have a personal image running. The only "weirdness" I see there is that unity8 etc. isn't a framework so the scope snap can't rely on it. Obviously I'll target the rolling-personal release, but it'll just have to _assume_ that unity8 is there
<kgunn> yes, understood....
<elopio> https://github.com/lxc/lxd-pkg-ubuntu/tree/snappy
<elopio> lxd snap ^
<mzanetti> but that still doesn't allow me to load .so plugins :/
<mzanetti> and IPC for those plugins is not an option
<mzanetti> ogra_, ^
<tsimonq2> QUESTION: If we have questions after this Hangout, is there an email we can use? Where do we go to get our questions answered?
<balloons> tsimonq2, great question. You can ask in this channel at a later time, although timezones might mean no one is around when you ask.. Either way, there's a lovely mailing list where you can get help and ask questions
<balloons> tsimonq2, https://lists.ubuntu.com/mailman/listinfo/snappy-devel
<tsimonq2> balloons: Thanks! :)
<elopio> and https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
<Sid_Payton> QUESTION: will we be able to easily install and configure (both via GUI) Server side apps like email, cloud, contacts Server? it would be brilliant if my parents (normal Joe) could easily do this and be more privacy aware.
<bmullan> lots of people on Reddit talk about snappy but many are asking the question does snappy = container.   That probably needs to be cleared up in snappy preso's.
<dougburks> QUESTION: Can we use DKMS or is there some other provision for kernel modules?
<blaroche> QUESTION:  is  https://bugs.launchpad.net/snappy the best/only resource for those looking to contribute?
<balloons> bmullan, interesting. Thanks for the feedback
<p_lorenz> QUESTION: i have to use custom apparmor and seccomp profiles in my snaps, but finding out what's missing in them is sometimes rather difficult. do you have any tricks on figuring out what's missing easily?
<tsimonq2> QUESTION: When Debian Ubuntu finally transitions into Snappy Ubuntu, won't it break everything, or will you have replacements for all of the packages? Will the config files and general GUI of the application stay, or will people have to start from scratch again?
<elopio> blaroche: depending on what you want to contribute. We welcome code, translations, bugs and questions.
<mterry> p_lorenz, often I just do "sudo grep DEN /var/log/syslog"
<balloons> dougburks, p_lorenz tsimonq2 I'll try and answer your questions now :-)
<mterry> mvo, can you make a new ~snappy-dev PPA?  "snapcraft-daily" or some such?
<p_lorenz> mterry: sometimes, it's difficult to find the main cause - a forbidden syscall is only listed by a number and sometimes enabling file/directory permissions for something doesn't fix the issue because of some special attributes :/
<balloons> dougburks, I don't believe dkms is an option. Is there a good way to get kernel modules ogra_ ?
<mterry> p_lorenz, another useful tool is to scp strace over to your snappy device and use that
<ogra_> balloons, i actually dont know, i know the architects were discussion DKMS support, but i do not know the outcome ... perhaps ricmm could answer this one
<mterry> p_lorenz, but yeah it would be nice to have a slick tool to tell you about denials
<ogra_> *discussing
<balloons> tsimonq2, you won't have to start from scratch. The debian base for ubuntu isn't going away, nor is the normal distribution. The point is the base for snappy and snap packages can still very much be debian
<tsimonq2> balloons: Thanks!
<p_lorenz> mterry: thanks, i'll try strace next time i run into a problem :)
<balloons> tsimonq2, I hope that helps. Plus there are some tools the team is working on to make packaging up existing stuff easy
<ogra_> tsimonq2, there will also be a tool called snapcraft in the future that is supposed to make it easy for you to create a snap from a bundle of deb packages to roll your own project into a store snap
<tsimonq2> ok
<tsimonq2> good
<balloons> So I'll link again, try out snappy and let us know what happens! http://bit.ly/1KHQZF6
<ogra_> i dont think we will just blindly convert deb to snap for everything in the archive though
<mvo> mterry: sure, does https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily look good? you should have edit access
<mterry> sergiusens, it's not just pep8.  I'd also need pyflakes, plainbox, and python3-yaml (maybe that's it?)
<balloons> lol ogra_ indeed! We don't want to reinvent the wheel, but we don't want to clone it either!
<sergiusens> mterry: sure, np
<ogra_> yeah, else we would have just renamed dpkg :)
<sergiusens> mterry: plainbox?
<kyrofa> tsimonq2, don't worry, normal Ubuntu isn't going anywhere!
<mterry> sergiusens, it's a test runner
<sergiusens> mterry: is there a plainbox for trusty?
<tsimonq2> kyrofa: YAY
<mterry> sergiusens, yes, but I haven't tried with that version...
<sergiusens> mterry: installed then, if there's a ppa we need, just send it over
<elopio> so, starting from now and until the RC is ready for release, the team will be testing the different snappy features.
<elopio> ping fgimenez or me if you want to test, if you get lost following the guides or if you find a bug.
<mterry> mvo, ah interesting...  I was thinking new PPA but using tools-proposed should be fine
<svij> isn't there a live stream? ubuntuonair.com links to the community q&a
<mvo> mterry: I don't mind either way, feel free to edit as needed
<esiotrot> For things like python/java/whatever would each snap come bundled with its own python interpreter/JVM/etc?
<mterry> mvo, thanks
<mvo> yw
<elopio> svij: the community q&a is the next on air session.
<sergiusens> svij: the on air part just ended
<mterry> esiotrot, yes (but de-duplication will eventually help avoid a lot of the space concerns)
<sergiusens> it's all irc now
<svij> sergiusens: oh right, so I just missed it, thanks
<tsimonq2> ogra_ balloons So, can you define what will change in the Ubuntu workflow once Snappy is implemented(kernel, APIs, apps, GUI, etc.)?
<esiotrot> mterry: Thanks.  Would that also avoid loading duplicate things in RAM?  Or just disk?
<balloons> svij, yes we had the last hour
<elopio> svij: https://www.youtube.com/watch?v=YMJ-R7KeMr0
<balloons> but we're still here chatting and testing
<svij> elopio: thanks!
<seb128> sergiusens, no idea about the device tarball increase/where to look at then?
<mterry> esiotrot, there was a plan to deduplicate RAM too
<balloons> svij, give it a try and tell us what happens: http://bit.ly/1KHQZF6
<esiotrot> mterry: OK
<esiotrot> How will updates to things like OpenSSL be handled?  Upgrade all affected snaps?  How will one know which snaps are affected?
<tsimonq2> QUESTION: ogra_ balloons So, can you define what will change in the Ubuntu workflow once Snappy is implemented(kernel, APIs, apps, GUI, etc.)?
<balloons> tsimonq2, what do you mean by workflow? I'm a little lost on what you are asking, sorry
 * ogra_ too 
<mterry> esiotrot, snap maintainers will need to update their snaps -- we have some plans to add metadata about library versions to snaps with our standard tools to help decide if something is affected
<tsimonq2> balloons, Implementing snappy means replacing...
<tsimonq2> GUI
<tsimonq2> Apps
<tsimonq2> etc.
<ogra_> tsimonq2, snappy images (and most likely also official snap packages that come from canonical) are usually based on deb packages from the archive ... so essentially there is just one additional step in the flow to "snappify" things
<esiotrot> mterry: OK, but essentially it is a case of updating all affected snaps instead of a single shared lib.  Why is this considered more secure? :)
<tsimonq2> So it makes it easier to install/develop applications?
<ogra_> we try to re-use the existing archive here as much as we can ...
<svij> isn't there some documentation on how to build a snap package which includes arm, x86_64 in one package? That's what I asked myself a few weeks ago when I tried to build a snap
<balloons> tsimonq2, it makes it easier for an end user to always have up to date and isolated stuff that won't break, and can rollback if it does
<kyrofa> ogra_, the i2c devicetree overlay will need to work in order to use the PiGlow, correct?
<tsimonq2> Cool!
<ogra_> kyrofa, yes, i fear so ...
<mterry> esiotrot, well there are other security threads with snappy -- namely each snap is very confined by apparmor (so snaps affected by a busted openssl can only hurt themselves)
<tsimonq2> Installing Snappy now
<esiotrot> mterry: I see
<balloons> tsimonq2, so for the app developer, they can push things out similar to the phone / store model. For the user, they can consume things in the same model. Historically on something like a server I would be loathe to update lots of things unless I needed to
<kyrofa> ogra_, but it's possible to get it working, albeit nasty?
<balloons> tsimonq2, I don't like breakage, but at the same time I do want the latest version of wordpress or something
<tsimonq2> Lol ok thanks
<ogra_> kyrofa, i'm trying to make the config.txt way that RPi upstream uses to work though ... so you might be able to just hack that fiule to have it working (as an interim solution)
<balloons> tsimonq2, let us know what you think :-) http://bit.ly/1KHQZF6. Thanks for giving it a shot
<balloons> do you have a device to try it on?
<esiotrot> balloons: So for ARM it's basically just beaglebone black and Raspberry pi?
<kyrofa> ogra_, I'd love to get that working, even in the interim. Do you plan on sending out an email to snappy-devel?
<ogra_> kyrofa, yes, indeed, as soon as the new snappy image is out i'll publish the RPi one and send a mail
<kyrofa> ogra_, I'm looking forward to it. Thank you for that!
<ogra_> :)
<elopio> esiotrot: there's a community port to odroid.
<tsimonq2> balloons: Can I link a screencast in the form?
<balloons> tsimonq2, sure! Sounds great
<elopio> https://github.com/longsleep/snappy-odroidc
<tsimonq2> balloons: I use LXDE hahahaha
<balloons> esiotrot, as far as I know those are the published images. rsalveti ogra_ will there / are there more? or a generic image
<balloons> ?
<esiotrot> elpio, balloons: OK.  The only device I would be able to try it on other than a VM would be an old AR7 DSL router, but even OpenWRT doesn't support it very well, so I am not surprised if Snappy doesn't :)
<ogra_> esiotrot, there is a odroidc image that longsleep maintains
<esiotrot> ogra_: OK
 * ogra_ has a few other borads here butr didnt find the time for images yet 
<ogra_> (parallella, and bananapi)
<ogra_> seb128, WOW ... yor last build exploded in flames
<ogra_> looks like an isotracker issue
<seb128> ogra_, hum? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next suggests it worked
<seb128> bah, can't ssh to recent personal images
<ogra_> http://paste.ubuntu.com/11836230/
<ogra_> thats the log i just got mailed by nusakan
<Laney> the tracker is down
<Laney> be becalmed
<ogra_> ah, right, so just ugly noise
<ogra_> seb128, and indeed you can ssh ... you removed cloud-init ... and i think sshd defaults to key auth
<seb128> "error: could not load host key: /etc/ssh/ssh_host_rsa_key"
<ogra_> *can not
<seb128> oh!
<seb128> :-/
<ogra_> you will need to add something that creates the keys on first boot
<ogra_> some systemd unit
<ogra_> and/or script
<tsimonq2> balloons: My screencast is (slowly) encoding, but I got an error.
<tsimonq2> balloons: I don't know how to fix it. hahahahahaha
<balloons> tsimonq2, awesome. Do you have steps to reproduce? I can try and do so
<elopio> fgimenez: I tried to set up my access in canonistack and failed because I can't follow instructions.
<elopio> can you help me tomorrow?
<fgimenez> elopio, sure :) i struggled to follow https://wiki.canonical.com/InformationInfrastructure/IS/CanonicalOpenstack?action=show&redirect=CanoniStack until it speaks about the dashboard, from there all is easy :)
<fgimenez> sergiusens, thx a lot for the pointer :) sorry where can i find those instructions again? https://developer.ubuntu.com/en/snappy/start/ doesn't mention it?
<tsimonq2> balloons: Sorry for the delayed reply, I can get you my system info and a list of all applications installed
<tsimonq2> YOu will have to see the video for the error
<balloons> tsimonq2, ack, I'll wait for that :-)
<tsimonq2> balloons: UGH 16% And I can't change rendering settings :(
<tsimonq2> And it is probably a REALLY simple error :D
<balloons> tsimonq2, can you take a couple screenshots?
<balloons> otherwise I guess we wait.. But I'll be here for some time so :-)
<sergiusens> fgimenez: no, ubuntu.com/snappy
<sergiusens> not developer ;)
<tsimonq2> balloons: Do you have Google Hangouts?
<tsimonq2> hahaha probably
<balloons> tsimonq2, certainly do
<tsimonq2> balloons: And no on the screenshots, sorry
<tsimonq2> Ok
<sergiusens> fgimenez: ah, it's a redirect now
<sergiusens> fgimenez: e.g.; https://developer.ubuntu.com/en/snappy/start/#snappy-amazon the cloud-data part
<sergiusens> ogra_: rsalveti any idea when we removed support for iso9660? http://paste.ubuntu.com/11836309/
<ogra_> sergiusens, modprobe ?
<sergiusens> ogra_: if it wasn't modeprobed before and needs so now it is a regression
<sergiusens> ogra_: that bug is the 15.04 blocker in any case
<tsimonq2> balloons: I have a hangouts call
<tsimonq2> https://goo.gl/pIylSG
<tsimonq2> I am showing my screen
<tsimonq2> Join
<tsimonq2> balloons: Would you like to?
<fgimenez> sergiusens, ok thx :) do you know where this cloud.cfg file should be generated? ubuntu's home?
<balloons> tsimonq2, sure, one second
<sergiusens> fgimenez: depends on the stack itself, maybe utlemming can help on how to feed that in for canonistack
<balloons> snappy is 64-bit only right?
<balloons> It's interesting trying to run a 64-bit kvm on a 32-bit host
<balloons> thoughts?
<fgimenez> sergiusens, sure thx
<bschaefer> ogra_, very strange i had to manually set my ip address to ssh into it with (ifconfig eth0 <ip>/24 up)
<bschaefer> also no default routing tables
 * bschaefer isn't sure if thats expected
<elopio> balloons: why don't you get a 32-bit image and vm?
<elopio> I think that should work, but haven't tried it.
<rsalveti> sergiusens: trying to think what could have changed for that bug to show up
<rsalveti> sergiusens: maybe cloud-init itself?
<rsalveti> or did it always require iso9660?
<sergiusens> rsalveti: from what I think, it may have always required it, utlemming might be the right person to ask
<sergiusens> rsalveti: but cloud-init did change, yes
<rsalveti> utlemming: do you have any idea about when this started to happen?
<balloons> elopio, is there a 32 bit snappy build?
<elopio> balloons: you can pass  --oem generic-i386 to ubuntu-device-flash.
<elopio> again, not sure what will happen. But you can try :)
<balloons> elopio, bah, I knew it. I figured u-d-f would let you
<rsalveti> balloons: the image is there but not properly validated atm, we officially only support amd64 and armhf (beaglebone black) atm
<balloons> rsalveti, right, but you plan to keep building 32-bit in the interim?
<rsalveti> no reason not to do it :-)
<rsalveti> elopio: another one that might be good for regression testing https://bugs.launchpad.net/snappy/+bug/1472317 (once we get the fix)
<ubottu> Ubuntu bug 1472317 in Snappy 15.04 "cloud-init requires ability to mount iso9660" [Critical,Confirmed]
<rsalveti> ogra_: sergiusens: can you guys work with utlemming to find out why this is broken?
<elopio> rsalveti: ack. Subscribing...
<tsimonq2> balloons
<balloons> ohh hello again tsimonq2
<tsimonq2> I pmed you\
<balloons> sorry, I don't always see those right away :-)
<tsimonq2> Ok
<tsimonq2> I am using Lubuntu 15.04
<tsimonq2> balloons
<tsimonq2> Quick question
<tsimonq2> Did you try this in a 32 bit ubuntu VM?
<tsimonq2> *Ubuntu
<ogra_> bschaefer, no, surely not expected and not seen by anyone else yet (to my knowledge)
<bschaefer> ogra_, sad face, not sure what im doing differently, but its working just strange
<ogra_> bschaefer, and you are using the right image ?
<balloons> tsimonq2, did I ? No I've not tried
<bschaefer> ogra_, the one from the snappy core site
<tsimonq2> Use something like VirtualBox and try it there
<bschaefer> ogra_, wget http://people.canonical.com/~platform/snappy/raspberrypi2/ubuntu-15.04-snappy-armhf-rpi2.img.xz
<bschaefer> is the image im using
<ogra_> yeah, thats the right one
<tsimonq2> I am but my computer is probably slower than yours :)
<sergiusens> rsalveti: ogra_: maybe we should just add iso9660 to /etc/modules-load.d/modules.conf ?
<tsimonq2> balloons
<ogra_> sergiusens, well, i dont get why module-init-tools doesnt load it on boot
<ogra_> it should load it on demand i mean
<ogra_> sergiusens, utlemming, was that a recent addition to cloud-init ?
<jcastro> I cannot seem to get any docker container to write a data directory in the /home/ubuntu directory, permission denied
 * ogra_ would like to find out why it broke before we hack around it 
<ogra_> jcastro, yeah, snaps cant write outside their defined space
<jcastro> oh, so I'm in the wrong defined space then?
<tsimonq2> balloons: Are you present?
<jcastro> ogra_: how do I find out where a snap is allowed to write to?
<ogra_> jcastro, there is $SNAP_APP_USER_DIR (which i forgot where exactly it points to by default) ... that should point to a subdir un the users home where you can pit data
<jcastro> got it, thanks!
<sergiusens> the data pit
<jcastro> that would explain this apps directory then I take it, heh
<ogra_> there was also some doc on dev.ubuntu.com that talks about the exact path
<balloons> tsimonq2, I'm here. I don't have a 32-bit vm
<ogra_> heh
<balloons> tsimonq2, but yours seems to be a packaging error
<balloons> I'm not sure
<balloons> we can try something simpler to eliminate the issue
<tsimonq2> balloons, Installing one uninstalls the other, which installing back uninstalls the other
<tsimonq2> So it seems to be circular
<tsimonq2> balloons, If it works in a VM, then it is my computer and we will need to diagnose. If it doesn't work on my VM, it is a problem either with Snappy or the command you gave me
<mterry> sergiusens, you said tarmac could use a ppa?
<mterry> sergiusens, we might need a ppa for newer version of plainbox
<tsimonq2> balloons, And either way, I want it to work in this VM
<tsimonq2> balloons, unless I can put it in another VM...
<tsimonq2> WAIT
<tsimonq2> OMG
<balloons> yes?
<sergiusens> ogra_: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/cloud-init/vivid/revision/389
<sergiusens> mterry: yeah, just tell me which one
<ogra_> sergiusens, whats that mess ?
<mterry> sergiusens, ppa:hardware-certification/public ?
<ogra_> (all these ~/.pc thingies there)
<tsimonq2> I should try it in VirtualBox, balloons
<sergiusens> ogra_: the cloud-init from updates that uses the azure data source
<ogra_> ah...
<sergiusens> ogra_: utlemming 583    for fstype in ("iso9660", "udf"):
<sergiusens> inside .pc/lp-1375252-1458052-Azure-hostname_password.patch/cloudinit/sources/DataSourceAzure.py
<ogra_> so thats new in cloud-init ...
<ogra_> ok
 * ogra_ just wanted to be sure it didnt work before and the image changed or whatnot
<sergiusens> ogra_ yes, but it may have been there for walinuxagent
<utlemming> sergiusens: that is the bit that enables it...but what is wierd is that it works for rolling
<utlemming> sergiusens: and yes, walinuxagent would have required it
<sergiusens> so the only thing I can think of is our new kernel
<ogra_> so it probably added the right bits for modprobing it
<jcastro> ogra_: that snap env variable doesn't appear to be set, also can't find where in the docs that would be listed. :-/
<tsimonq2> balloons, Looks like the img file you gave me won't work in VirtualBox, OR Disk Image Mounter...
<tsimonq2> Or that the command game me
<tsimonq2> *gave
<tsimonq2> There is a chance that it could be that
<sergiusens> utlemming: although sergiusens@lothlorien:~/source/walinuxagent-2.0.13$ grep -R iso9660 returns nothing
<ogra_> jcastro, i never used docker directly, only via the pwncloud snap yet ... perhaps you can deduct from there how it works (just install it and then look in /apps)
<ogra_> *owncloud
<tsimonq2> balloons, What do you think about that?
<jcastro> yeah I'll keep digging because I tried guessing from the owncloud.
<ogra_> sergiusens, is that kernel any different from our -generic one ??
<ogra_> or is it the very same package ?
<ogra_> oh
<tsimonq2> ballons, BRB
<ogra_> it is the first 4.0 kernel ?
<sergiusens> ogra_: it is the SAME kernel
<ogra_> are we talking wily or 15.04 ?
<sergiusens> ogra_: livecdrootfs now just does a cp of the generic one to the azure one
<ogra_> ok
<sergiusens> ogra_: wrt to device
<sergiusens> ogra_: and yes, 15.04
<ogra_> ah, k
<sergiusens> ogra_: as ben said, everything seems to be fine on rolling
 * ogra_ sees there was a walinuxagent upload to 15.04 yesterday
<sergiusens> ogra_: we aren't using walinuxagent anymore
<ogra_> k
<sergiusens> ogra_: it's all in cloud-init now
<tsimonq2> balloons, Here
<tsimonq2> balloons, Are YOU here?
<balloons> tsimonq2, the img file for snappy?
<balloons> it works in kvm only. There is an ova image that should work in vbox I would think
<ogra_> https://launchpad.net/ubuntu/+source/linux/3.19.0-22.22
<tsimonq2> balloons, yes
<tsimonq2> balloons, NOTHING can open it
<ogra_> nothing regarding filesystems :/
<tsimonq2> balloons, redownloading
<balloons> tsimonq2, my idea was to ppa-purge
<balloons> ppa:snappy-dev/tools-proposed
<balloons> then try installing snappy and going through the steps again
<balloons> just in case there's a packaging issue
<tsimonq2> balloons, I am downloading the .img file again. Then, I will try opening it again. If that doesn't work, I will do that.
<tsimonq2> ok
<tsimonq2> doing it
<tsimonq2> Running ppa-purge ppa:snappy-dev/tools-proposed
<mterry> mvo, do you mind creating a new ppa just for snapcraft (can still call it snapcraft-daily or something)?  I want to enable a new dependent PPA for building on trusty, and I'd feel better if it was more isolated (plus, users testing snapcraft may not want the rest of those tools)
<tsimonq2> balloons, welp, had to install ppa-purge
<jcastro> ogra_: found it, you just have to be explicit when telling docker the directory, I'll write it down on askubuntu for the next person
<tsimonq2> balloons, Note, I had to add sudo
<ogra_> jcastro, awesome, thanks !!
<tsimonq2> balloons, Then do I have to reinstall the PPA?
<tsimonq2> balloons, or am I good?
<tsimonq2> balloons
<ogra_> sergiusens, so lets just add isofs to /etc/modules on azure images i guess ...
<tsimonq2> balloons
<balloons> tsimonq2, after using ppa purge, update apt and try installing snappy again
<balloons> then run the same commands
<ogra_> sergiusens, hrm, but we cant do that during build i fear that would add isofs to all images ... not so good
<mterry> rsalveti, do you mind creating a snapcraft-daily ppa under ~snappy-dev?
<ogra_> sergiusens, any way to do that from the oem snap ?
<tsimonq2> Ok
<tsimonq2> balloons, So I am redownloading the image, or I am reinstalling snappy?
<tsimonq2> OHHH
<tsimonq2> Got it
<tsimonq2> Nevermind
<balloons> tsimonq2, :-) awesome
<balloons> is everything installing a-ok now? then you should be able to launch the image
<tsimonq2> I cannot install Snappy
<tsimonq2> proceeding
<tsimonq2> ballons, errors, emailing you a screenshot
<balloons> so snappy fails, and kvm still fails?>
<tsimonq2> You will see
<tsimonq2> Check your email
<tsimonq2> I sent you the screenshot as an attachment, balloons
<sergiusens> ogra_: we need to do it from the device tarball for azure
<ogra_> sergiusens, right ...
<sergiusens> ogra_: so it's a half revert of the livecd-rootfs change
<ogra_> *sniff*
<sergiusens> yeah :-P
<balloons> tsimonq2, I see it
<sergiusens> ogra_: who should do it?
<ogra_> i'm just trying to find the commit ... why didnt it have your name ?
<balloons> hmm.. your system is still a bit interesting because of the packaging stuff
<ogra_> ah
<ogra_> it had ... just well hidden :P
<sergiusens> ogra_: lol
<balloons> tsimonq2, I would probably go ahead and remove the packages
<sergiusens> ogra_: livecd-rootfs for vivid is what we need to change
<sergiusens> ogra_: I don't know why it works for wily as is, but it works
<ogra_> sergiusens, yeah, but i guess the dropped code was the same
<tsimonq2> balloons, I have to leave for a meeting. I will email you when I get back on in a couple of hours so we can experiment some more. I am emailing you this as well. Be back around 3PM CST(Central Standard Time, USA). Sorry. Bye!
<sergiusens> ogra_: right, we just need to tar up $HERE as the generic device, then echo the modules (isofs) and tar up again as azure
<sergiusens> ogra_: although...
<ogra_> http://paste.ubuntu.com/11837056/
<sergiusens> ogra_: we won't work on any openstack install and only on azure if we don't make it generic
<ogra_> so i guess thats the relevant bit
<sergiusens> ogra_: yes
<sergiusens> ogra_: I'm thinking we should just make it generic though...
<ogra_> hmm
<ogra_> you mean isofs in all images ? nah
<ogra_> thats super ugly (and might break with BSP kernels)
<sergiusens> ogra_: yeah, it's not azure specific
<ogra_> hmpf
<mvo> mterry: sure, one sec
 * ogra_ would really rather see cloud-init call modprobe then)
<mvo> mterry: is this https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily ok ?
<sergiusens> ogra_: in any case, why isn't it automatic?
<jcastro> well, I got docker containers up and running with data being saved in the right places
<jcastro> and then /oem seems to have filled up
<ogra_> sergiusens, why would it be loaded if there is no CDROM ?
<sergiusens> jcastro so /oem is bind mounted to /writable; maybe create a bigger image (--size X)
<sergiusens> ogra_: I don't know, mount should :-P
<mterry> mvo, yeah perfect
<mterry> mvo, thanks man
<sergiusens> ogra_: but why does it work on wily?
<ogra_> good question
<sergiusens> ogra_: also, special case it for amd64, not all arches
<ogra_> apw, do you know if anything in regard of loading filesystem modules changed in the recent vivid kernel ?
<jcastro> sergiusens: oh I see what happened, I gave it a 60gb disk but it seemed to partition that area for 1.6GB
<jcastro> I was assuming it would just use the rest of the disk as writeable
<ogra_> jcastro, you could just expand the writable partition with gparted or some such
<ogra_> (just dont touch system-a|b|boot ...)
<ogra_> sergiusens, utlemming, are we actually 100% sure the isofs module isnt loaded (or could the sr0 device be corrupt perhaps) ?
<sergiusens> jcastro: it should have
<sergiusens> ogra_: good point, bad superblock....
<ogra_> sergiusens, "bad option" ...
<ogra_> does "-o ro,sync" even work with isofs ?
<ogra_> (i thought isofs implies ro anyway, and i doubt it supports sync at all)
<sergiusens> ogra_: wait_for /dev/sr0
<utlemming> ogra_: based on what I am seeing, it looks like the module is not loaded
<ogra_> hmm, k
<ogra_> utlemming, and that code has worked before with these mount options ?
<utlemming> ogra_: yes, it works in rolling-edge incidently
<ogra_> k
<jcastro> hmm, so I clearly misinstalled this: http://pastebin.ubuntu.com/11837141/
<utlemming> ogra_: and I've confirmed the code path for cloud-init in a generic cloud image
<ogra_> right, then it can only be the kernel
<ogra_> i dont get why it wouldnt autoload
<ogra_> ogra@styx:~$ lsmod|grep isofs
<ogra_> ogra@styx:~$ sudo mount -t iso9660 /dev/foo /mnt
<ogra_> mount: /dev/foo is write-protected, mounting read-only
<ogra_> mount: special device /dev/foo does not exist
<ogra_> ogra@styx:~$ lsmod|grep isofs
<ogra_> isofs                  40960  0
<ogra_> i'm running the exact same kernel on this laptop :/
<ogra_> sergiusens, ! ... i like that --config idea !!
<deker> Anyone tried the OVA image of snappy ? Attempting to deploy http://cloud-images.ubuntu.com/ubuntu-core/15.04/core/stable/current/core-stable-amd64-cloud.ova fails because the sha256 hash of the .ovf file doesn't match
<rsalveti> balloons: elopio: took just a few hours :-) http://cdimage.ubuntu.com/ubuntu-snappy/15.04/rc/
<rsalveti> next time need to remember to do that one day earlier
<ogra_> sergiusens, i dont see any changes on the images over the last days that could anyhow cause this
 * ogra_ just re-activated his changelog script
<ogra_> http://paste.ubuntu.com/11837262/ ... nothing except the kernel itself ... but that kernel loads isofs just fine here
<ogra_> errr
<ogra_> looking at that ....
<ogra_> ah, nevermind
<rsalveti> yeah, it's super weird that is not loaded by default
<rsalveti> can you load it manually with modprobe?
 * rsalveti checks
<ogra_> i honestly have no idea why
<ogra_> rsalveti, see above, even "sudo mount -t iso9660 /dev/foo /mnt" loads it for me before it spillls the error
<rsalveti> mterry: seems mvo already created the ppa for you
<mterry> rsalveti, yeah thanks!
<rsalveti> mterry: guess we just need to ask it to be armhf as well (if not enabled by default)
<ogra_> rsalveti, and i use the exact same kernel here on my vivid laptop
<rsalveti> trigger the first build and we'll see
<rsalveti> ogra_: right, but that is not snappy :-)
<mterry> rsalveti, I got distracted by helping unity7 folks with a greeter document, will flesh out the PPA in a bit
<ogra_> rsalveti, it worked before the kernel upgrade i was told
<ogra_> (on snappy)
<ogra_> https://launchpad.net/ubuntu/+source/linux/3.19.0-22.22 has nothing that could touch this area either
<rsalveti> ogra_: yeah, the dependencies are definitely right, and I can load it manually just fine
<ogra_> right
<ogra_> rsalveti, rmmod it and try: sudo mount -t iso9660 /dev/foo /mnt
<rsalveti> is there any easy way to manually reproduce the issue?
<ogra_> see if it gets auto loaded
<ogra_> (here it auto loads before mounts spills the error)
<ogra_> *mount
<rsalveti> ogra_: yup, loaded fine
<ogra_> on snappy ?
<ogra_> hmm...
<rsalveti> ogra_: yup
<sergiusens> rsalveti: 15.04?
<ogra_> i dont get it then :P
<rsalveti> sergiusens: yes, 15.04/edge
<rsalveti> amd64
<sergiusens> ogra_: wait_for_root /dev/sr0
<sergiusens> won't that be a probable cause?
<ogra_> sergiusens, who would call that ?
<rsalveti> what creates /dev/sr0 ?
<sergiusens> rsalveti: azure's hypervisor I guess
<sergiusens> utlemming: ^
<utlemming> rsalveti, sergiusens: correct
<rsalveti> there is definitely no wait-for-root for every block device
<sergiusens> ogra_: I say maybe we should, it might just take time to show up?
<ogra_> ah
<rsalveti> a race would then explain why it works on rolling
<rsalveti> utlemming: sergiusens: can you manually restart/start cloud-init after booted the system?
<ogra_> sergiusens, yeah, so lets try it, but add a timeout so it doesnt hang forever :)
<rsalveti> just trying to understand how we can manually reproduce the issue
<sergiusens> ogra_: right, we only want to wait for it on azure if we do this
<sergiusens> rsalveti: launch a kvm instance with a cd attached I guess.
<rsalveti> https://github.com/Azure/WALinuxAgent
<rsalveti> The information flow from the platform to the agent occurs via two channels:
<rsalveti>   * A boot-time attached DVD for IaaS deployments.
<sergiusens> rsalveti: we saw the code, it tries to mount it, the new cloud-init, while the walinuxagent from vivid didn't
<rsalveti> utlemming: sergiusens: but will it always be there?
<sergiusens> rsalveti: I can't answer that ;-)
<rsalveti> saw that as well, just trying to understand why that device exists
<utlemming> rsalveti: for Azure, yes
<ogra_> well, if it is always there i doubt wait-for-root busy us anything
<ogra_> *buys
<sergiusens> ogra_: always there, but takes time
<rsalveti> ogra_: that helps giving a timeout for the block device to really show up
<rsalveti> we had similar issues for the other partitions
<rsalveti> but the wait-for-root logic can be called from somewhere else
<rsalveti> like in cloud-init itself
<sergiusens> as in always ever since it shows up and not since the begining of the vms lifecycle
<ogra_> yeah
<rsalveti> no need to hack up the initrd for an azure specific option (which is a pain)
<ogra_> /usr/lib/initramfs-tools/bin/wait-for-root foo bar
<sergiusens> utlemming: maybe hack that in for a test? ^
<utlemming> ogra_: actually, walinuxagent does mount the iso
<sergiusens> utlemming: yeah, I only saw that in the new cloud-init code
<utlemming> ogra_: its more obvious in the new cloud-init code...walinuxagent buries it
<utlemming> ogra_: and walinuxagent tries up to 6 times, sleeping for 5 seconds between attempts
<rsalveti> right :-)
<ogra_> ah
<rsalveti> that might explains
<ogra_> /usr/lib/initramfs-tools/bin/wait-for-root DEVICE TIMEOUT ...
<ogra_> add that then
<rsalveti> or just have a similar retry logic
<ogra_> yeah
<ogra_> but
<ogra_> ....
<utlemming> wild idea...udev rule that identifies if this is azure that blocks until the /dev/sr0 appears?
<ogra_> if the mount call doesnt load the isofs module, it wont load the module later either
<rsalveti> ogra_: I don't think that the module is the issue
<rsalveti> it was probably loaded
<sergiusens> utlemming: ogra_ rsalveti this boots fine btw kvm_snappy -cdrom ~/Downloads/ubuntu-14.04.2-desktop-amd64.iso azure.img
<ogra_> it should even load it if sr0 isnt there yet
<ogra_> rsalveti, utlemming said it wasnt
<sergiusens> /dev/sr0 is instantly there and cloud-init doesn't choke
<ogra_> ok
<rsalveti> sergiusens: was the module loaded?
<ogra_> obviously ... if he didnt get the error
<rsalveti> guess the kernel tried to read the block device and then loaded the correct module to handle that
<ogra_> well, mount -t iso9660 should omit any probing
<rsalveti> in the broken case I don't think it can even read the block device
<ogra_> and just blindly load isofs
<rsalveti> that's true
<ogra_> well, you did the test yourself on your snappy ... mounting /dev/foo doesnt exist either
<rsalveti> but in the azure case it was there, just not really there
<rsalveti> so not sure if that would case any other weird side effect
<ogra_> well, lets try the loop/wait logic and see
<rsalveti> yeah, in any case, having the retry logic seems a good thing to do anyway
<ogra_> yup
<sergiusens> sorry, intel driver crash
<rsalveti> utlemming: the udev rule could trigger something, but cloud init would still try to read it
 * sergiusens missed some bits and pieces
<rsalveti> sergiusens: http://paste.ubuntu.com/11837389/
<rsalveti> in case you missed irc as well
<Saviq> ogra_, are you building u-boot yourself for the pi2 images? could I ask for your config etc.? /me needs to disable serial in u-boot
<ogra_> Saviq, no, i pull ppisatis binary from github
<ogra_> and now i cant find the link :(
 * ogra_ has it in the browser history on the other machine :(
<ogra_> Saviq, https://github.com/piso77/ubuntu-embedded/tree/master/boards/raspy2/bootloaders
<Saviq> ogra_, thanks!
<ogra_> Saviq, originally the source comes from https://github.com/swarren/u-boot ... but i dont know which branch exactly ppisati used
<ogra_> (there are many rpi ones)
<Saviq> ogra_, yeah, let's see if I can get somewhere with this, otherwise I'll bug him tomorrow, thanks
 * sergiusens takes short break
<bschaefer> ls
<bschaefer> opps
<rsalveti> utlemming: so will you take care of trying to add a retry logic in there?
<rsalveti> just to make sure someone is on top of the issue
<Letozaf_> hey guys I have installed snappy and wanted to launch webdm on my local machine, I stared kvm with -redir :8090::80  but if I type http://localhost:8090 in my browser webdm does not start, what am I doing wrong ?
<manik_> Letozaf_: webdm is running on port 4200 i believe, you need to redirect that port to a local port on your computer as well
<sergiusens> Letozaf_: webdm listens on 4200
<Letozaf_> manik_, sergiusens ok thanks
<apw> ogra_, not that i know of ... no
<kyrofa> kgunn, are you running Ubuntu Personal in kvm?
<kgunn> kyrofa: yes, i use Virtual MAchine Manager
<kgunn> there's some magic for the gfx drivers
<kyrofa> kgunn, did you have to switch it to QGL?
<kyrofa> kgunn, QXL, rather
<kgunn> i wrote up my instructions for how i did it as part of the snappy gui
<kgunn> https://docs.google.com/document/d/14msTXe_cFulk9z4jFptEjFJzZx58b1mWU_r4VivLkfA/edit
<kgunn> kyrofa: ^
<kyrofa> kgunn, so you didn't have to change the machine config at all? Doing it that way I get to a lightdm-looking prompt, which gives me a black screen after I enter the password. If I change the video model to QXL I get more of a unity8-ish login prompt, but then I can't get past the intro demo thing
<kgunn> mmm
<kgunn> kyrofa: almost sounds like you're getting what i saw a week ago
<kgunn> kyrofa: and correct i didn't change a thing
<kyrofa> kgunn, hmm. And was the login screen lightdm or unity8?
<bschaefer> ogra_, hey, soo just ran into a fun issue with ras pi2. Theres no /dev/dri (which is causing the mir server to fail)
<kgunn> kyrofa: i do have instructions on how to dismiss the unity8 greeter from the command line (gotta ssh in ahead of time tho....cause you can't vt switch after you hit unity8 greeter)
<kgunn> kyrofa: so it's weird, greeter for desktop shows up on vt7
<kgunn> and unity8 greeter shows up on vt8
<kyrofa> kgunn, ohhh, interesting
<kgunn> kind of an artifact of the unity8-on-desktop
<kgunn> package....
<kgunn> eventually it should not be like that
<kgunn> kyrofa: so here's another doc thtat addresses what i saw last week
<kgunn> https://docs.google.com/document/d/13teoUPInWNfFONZ2Dq1U9VTiqs9aUEV52D2M8VCXOA4/edit
<kgunn> kyrofa: so seb was saying we shouldn't have to do those monkey manual steps...
<kgunn> but i haven't caught up myself, i was going to update to wily today and try
<kgunn> just been busy til now :)
<utlemming> rsalveti: well, we could put the retry logic into cloud-init, but that is going to take an SRU cycle.
<rsalveti> utlemming: we could experiment with that at our snappy ppa
<utlemming> rsalveti: true
<rsalveti> then if we actually confirm the fix, we can start a sru for it
<kyrofa> kgunn, no problem, I just thought I'd try taking it for a spin today :) . I'll keep playing with it, ping me when you get a chance to mess with it again?
<Saviq> jdstrand, resubmitted, thanks
<utlemming> rsalveti: fixing this in cloud-init is not exactly straight forward
<utlemming> rsalveti: actually, I don't think that fixing this in cloud-init is going to fix it
<rsalveti> utlemming: why?
<rsalveti> wither we do a retry logic in there or something before that code gets executed
<utlemming> rsalveti: the cloud-init code searches for devices that have iso9660 and udf types. From that it finds that /dev/sr0 is a candidate.
<rsalveti> right
<rsalveti> but it does call mount after that, right?
<rsalveti>  
<rsalveti> 98
<rsalveti>                 if cdev.startswith("/dev/"):
<rsalveti>  
<rsalveti> 99
<rsalveti>                     ret = util.mount_cb(cdev, load_azure_ds_dir)
<rsalveti> argh
<utlemming> rsalveti: so the mere fact that it identified /dev/sr0 as iso9660 means that the mount failing is not a cloud-init issue, per se
<utlemming> rsalveti: see lines 618
<utlemming> through 625
<jdstrand> Saviq: approved
<Saviq> jdstrand, thank you
<jdstrand> np
<rsalveti> utlemming: right, it's definitely an issue in cloud-init itself, but we need to add the workaround logic for azure somewhere
<rsalveti> we could add it before cloud-init, but it's also not so trivial since this is device specific
<rsalveti> *not an issue
<rsalveti> sorry
<Letozaf_> hey guys, but once you installed packages like snake, and chatroom, for instance, If I do not know them, how can I find out how they have to be used, just to  check if they are workign
<utlemming> rsalveti: so riddle me this...why does it work with rolling but not 15.04?
<rsalveti> utlemming: it could be a pure race condition
<rsalveti> slower boot?
<rsalveti> which is why we wanted to add a retry logic to at least identify if that could indeed be the reason
<rsalveti> we suspect it's the same issue we had for other block devices
<rsalveti> which we added the wait-for-root workaround
<utlemming> rsalveti: ack...okay, I can look
<Saviq> ogra_, /me just noticed ogra@anubis being in authorized_keys on the pi2 image, you planning to take over the world?
<rsalveti> yeah, that's his evil plan
<Saviq> and /me finally managed to get ubuntu to boot with the emon board in!
<Saviq> how do I preinstall webdm, for example, on my image? it's there in ogra_'s image, but not on mine, built using the same commands
<Saviq> ah, oem/software
 * Saviq tries
 * Saviq likes bmaptool
<Saviq> ok, oem/software is ignored
<Saviq> d'oh
<Saviq> it's actually working fine
<Saviq> with the exception that `snappy build` craps out trying to unmount
 * Saviq reboots for good measure
<utlemming> rsalveti: yeah, so actually, this is a cloud-init bug. Its trying to mount a udf file system as iso9660
<utlemming> rsalveti: I'm trying to track down why that is the case
<rsalveti> utlemming: but why would that work on rolling then?
<utlemming> rsalveti: I think it may be an ordering thing
<rsalveti> hm, alright
<utlemming> rsalveti: okay, nested exceptions....the real issue is https://bugs.launchpad.net/snappy/+bug/1472422
<ubottu> Ubuntu bug 1472422 in Snappy "/var/lib/waagent is not a writable path for 15.04" [Critical,Confirmed]
<utlemming> rsalveti: which is the reason why provisioning fails
<rsalveti> utlemming: interesting
<rsalveti> let me upload a fix for that
<utlemming> rsalveti: ack, thanks
<rsalveti> utlemming: do you know if we need any other dir than /var/lib/waagent ?
<rsalveti> this is just because we need a different fix in our images, since the main issue is that it tries to create that dir during runtime
<rsalveti> and /var/lib is ro
<rsalveti> so we need to create the dir in build time and make it writable
<utlemming> rsalveti: er, no, I think the others that are needed are there
<rsalveti> great
<rsalveti> utlemming: pushed the fix, will trigger another image once it lands
<rsalveti> we should know more tomorrow
<utlemming> rsalveti: thank you kindly, I'll verify first thing in the morning
<rsalveti> awesome, thanks for investigating the issue
<elopio> rsalveti: I can't login with ubuntu/ubuntu to that image you published in cdimage.
<elopio> that is on the amd image. On the beagle it works.
#snappy 2015-07-08
<elopio> um, scratch that.
<elopio> downloaded again and now it works.
<elopio> unping.
<Saviq> jdstrand, when you have a sec, I had to upload a new version of emonhub-pi, the review tools did not get an update yet
<jdstrand> Saviq: accepted
<dholbach> good morning
<fgimenez> good morning
<ogra_> Saviq, heh, yeah, thats a fake key (--developer-mode needs it) ... next image i'll edit my name out :)
<ogra_> Saviq, for installing packages ubuntu-device-flash has the --install option ;)
<ogra_> (that's how webdm gets into my image)
<Saviq> ogra_, yup, learned that, too, but oem/software works after all
<Saviq> is there (will there be) a way to hw-assign from an OEM snap? or a gadget snap?
<Saviq> heh and why does unity-settings-daemon die when building an image :D
<ogra_> you mean to ship a config with an app snap that enables certain hw access by default ?
<Saviq> ogra_, not sure if an app snap, but maybe an oem/gadget snap?
<Saviq> ogra_, but well, sure, app would work, too
<ogra_> i think you wont be able to upload that to the store, but for sideloading there should be an ability
<ogra_> an oem or gadget snap has full HW access
<ogra_> and access to hwe from a framework or app snap needs to be defined for that snap
<ogra_> *hw
<Saviq> ogra_, didn't find anything re: hw-assign in https://developer.ubuntu.com/en/snappy/guides/oem/ - that's where I'd expect to put it? under /oem/hardware
<ogra_> what exactly would you do with it ?
<Saviq> ogra_, I want for an app to have access to /dev/ttyAMA0 straight after flashing
<ogra_> right, so that app snap needs to define it, not the oem snap
<Saviq> but it won't be accepted to the store?
<ogra_> it wouldnt be accepted with a default that silently enables access to the device
<ogra_> the requirement is that the admin runs the hw-assign command for the snap to switch on the access
<ogra_> after installing it
<Saviq> hmm so how do we plan to support these kind of usecases, say, a managed switch app
<Saviq> if you want to sell a managed switch, you can't leave the hw-assign to the end user
<ogra_> well, for you as developer there will be a way to sideload
<Saviq> sure, I'm thinking end-user
<Saviq> [...] or expect for the factory line to boot and run hw-assign on every unit?
<ogra_> if you sell a managed switch with a branded and preinstalled image you will likely also have your own store namespace
<ogra_> in which you will be able to put such a snap
<Saviq> hmm
<ogra_> (for details better ask the store people :) )
<Saviq> ppisati, hi, do you know of a way to disable serial in u-boot for the raspi2? I tried changing std{in,out,err}, but that didn't help, only thing that worked was to set bootdelay to 0 so that it ignores any input (I've an expansion board that talks on ttyAMA0 and interrupts the boot process)
<Saviq> I thought changing std... should work, but u-boot still reads from the serial port and interrupts auto-boot because the board sends stuff through
<ppisati> Saviq: disabling uboot from reading the serial...
<ppisati> Saviq: no idea
<ppisati> Saviq: you probably need to build your own uboot
<ogra_> well, on the Rpi a lot of the initialization is done via the binary blob ...
<ogra_> so even building your own uboot might not help
<ppisati> right, i forgot about thir binary blob
<ppisati> ogra_: deos it emit anything on the console? i don't remember...
<ppisati> uhm
<ogra_> i dont think it does
<ogra_> but i think it initializes it
<ogra_> there might be a way to manage that via config.txt
<Saviq> well, bootdelay=0 it is :P
<Saviq> it's not like the usb keyboard works anyway ;P
<ogra_> bootdelay=0 in config.txt ?
<ogra_> as a uboot param it only disables the ability to stop the autoboot
<ogra_> wouldnt change anything in console usage
<Saviq> ogra_, no, setenv
<Saviq> ogra_, and my problem is exactly that - autoboot is stopped because serial is talking
<ogra_> but udev always talks to serial ... it just doesnt wait for input when autoboot is off
<ogra_> err
<ogra_> "autoboot interception"
<ppisati> Saviq: i don't see any option to disable the serial output
<ppisati> Saviq: you can try to change the baud/serial clock
<ppisati> Saviq: and hope that it doesn't interfer
<ppisati> albeit it's a crappy solution. i know :)
 * ogra_ just notes what he wrote above :P
<ogra_> s/udev/uboot/
<Saviq> ogra_, sure, and that's exactly it - I just need it to boot, and it doesn't if I leave it - because the board I have is talking on serial on boot, so interrupts u-boot
<Saviq> ppisati, it's not about output, input rather
<ppisati> Saviq: same logic applies
<ogra_> Saviq, well, thats a matter of luck then
<ppisati> Saviq: since you don't have any option to not init the serial, wreak it
<ppisati> Saviq: or better
<ppisati> Saviq: write an email to the raspy2/broadcom people
<ppisati> Saviq: and ask for that feature
<ppisati> Saviq: btw, how did you make it work with the original broadcom img?
<Saviq> ogra_, sure, I'm not saying bootdelay is the right solution
<Saviq> ppisati, it Just Works with https://wiki.ubuntu.com/ARM/RaspberryPi and Raspbian
<Saviq> ppisati, afaict the bootloader there (not u-boot) isn't talking on serial by default?
<ppisati> Saviq: then patch our uboot
<ppisati> Saviq: and rip out the serial input part
<Saviq> ppisati, yeah, need to dig into u-boot for that, there's no obvious configs for that, the only relevant thing I found was SILENT... but that won't help with input I don't think
<Saviq> I was really expecting setenv stdin "usbkbd" to work
<Saviq> because it was serial,usbkbd by default
<Saviq> but that didn't change anything
<Saviq> so yeah, still looking for the right solution, am ok with the interim one though
<Rlyeh> Hi all
<Rlyeh> Is there any GUI for snappy?
<dholbach> Rlyeh, https://developer.ubuntu.com/en/snappy/guides/webdm/?
<ogra_> only web currently
<Rlyeh> I'm using it now
<Rlyeh> Thank you
<seb128> bah, I don't understand
<seb128> upgrading that snappy install, mounting /boot/efi fails
<seb128> "FAT-fs (vda2): IO charset iso8859-1 not found"
<seb128> but the same partition mounts fine booting the old / on system-b
<ogra_> shouldnt it be mounted all the time ?
<seb128> ogra_, I don't think so, it's in fstab
<seb128> the mount target fails and sends systemd in debug mode
<ogra_> sounds like a module mistmatch or so
<ogra_> can you check lsmod between the two boots ?
<seb128> ogra_, yeah, on the failed boot lsmod lists only psmouse and pata_acpi
<ogra_> do you see modules in /lib/modules/* ?
<seb128> hum
<seb128> only a /lib/modiles/4.0.0-4-generic
<ogra_> and nothin underneat ?
<seb128> but the kernel in use is 3.19.0-22
<ogra_> ah
<seb128> yes, they are there
<seb128> but modproble looks for a 3.19
<ogra_> right
<seb128> wth
<seb128>  /boot has 4.0
<ogra_> sounds like an issue with the grub stuff again ?
<seb128> where is the booted 3.19 kernel coming from?
<seb128> I guess
<ogra_> Chipaca, ^^^ ?
<seb128> mvo_, sergiusens, Chipaca, ^
<ogra_> i wonder if we hardcode 3.* soemwhere for the version :P
<seb128> could be...
<Chipaca> whasup?
<Chipaca> seb128: is this on personal?
<seb128> yes
<seb128> Chipaca, I installed personal 28 yesterday
<seb128> and upgraded to 30 with "snappy update"
<seb128> the new version fails to boot, it load a kernel 3.19 but the /boot version is 4.0
<seb128> which makes it fail to load modules
<Chipaca> seb128: what gadget snap does personal use?
<seb128> no idea, how do I tell?
<seb128> amd64_generic iirc
<seb128> if that's one
<Chipaca> seb128: rolling , yes?
<seb128> yes
<seb128> Chipaca, http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/
<seb128> Chipaca, looks like $prefix/a and /b both have the 3.19 kernel
<seb128> where today's image /boot has 4.0
<Chipaca> why does /boot have a kernel, and why are you booting that instead if $prefix/a or /b?
<seb128> so unsure what is supposed to update the boot kernels but that went wrong
<seb128> Chipaca, well, it's booting $prefix/a /b
<seb128> which is what creates the issue
<Chipaca> sounds to me like personal is broken
<seb128> the system-b partition has /lib/modules/4.0
<seb128> which is the current wily kernel
<seb128> $prefix/b should have a 4.0 kernel
<seb128> that matches the installed os
<seb128> Chipaca, could be, but the issue is that the $prefix/b kernel is the old one and not matching the current image kernel
<seb128> new image work fine
<seb128> it's just a snappy updated one that has that issue
<Chipaca> seb128: the kernel should not be on /boot
<Chipaca> it should be on /boot/a/etc
<seb128> right
<Chipaca> boot/grub/a/ or whatever it is
<seb128> it loads (gd0,gp2)/EFI/ubuntu/grub/a
<seb128> that is 3.19
<seb128> but then it tries to boot
<Chipaca> which is why i say it sounds like personal is broken
<seb128> and disk has /lib/modules/4
<seb128> no 3.19
<seb128> so it fails to load modules
<seb128> sorry if what I wrote is confusing
<seb128> it does boot the a/b vmlinuz versions
<seb128> the issue is that personal 30, which is today image has /lib/modules/4
<seb128> new kernel major
<seb128> and for some reason the b partition from the upgrade has an old kernel
<seb128> so boot fails because it doesn't find modules matching the kernel
<Chipaca> yes, yes, i understand
<Chipaca> it was not confusing
<ogra_> Chipaca, how would personal be able to break an underlying mechanism ?
<Chipaca> i mean, your description wasn't
<seb128> k
<ogra_> snappy should work distinct from that
<seb128> but it's not personal which includes the boot/grub/b
<seb128> that was generated/build at the upgrade time
<seb128> new image don't have that issue
<seb128> Chipaca, the b partition kernel is somehow copied when updating the image I guess? do you know what code does that?
<Chipaca> seb128: snappy copies it
<seb128> from where?
<Chipaca> seb128: the new version might not include a kernel, in which case it gets copied
<seb128> is that coming from the device tarball?
<seb128> well the "new version" has a kernel, if you meant the image
<Chipaca> i don't know where and if the device tarball comes into it :)
<seb128> since a fresh image builds fine
<seb128> boots fine
<Chipaca> i expect sergiusens will take one look at the symptoms and know what's going on
<seb128> k
<Chipaca> so better wait for him than waste time guessing now
<seb128> let's wait for him then
<seb128> thanks
<Chipaca> if he comes in and doesn't, then let's sleuth around
<sergiusens> seb128: Chipaca ogra_ the livecdrootfs "kernel" and "initrd" entries are all that matter now
<ogra_> sergiusens, and seb128 got that one installed ... but the old one was completelly removed (so no modules)
<Chipaca> sergiusens: mo'in :)
<sergiusens> so /boot/grub/[a|b]/vmlinuz
<sergiusens> ogra_: oh nice, how did that happen?
<seb128> sergiusens, hey
<seb128> sergiusens, install snappy personal 28 from yesterday
<seb128> snappy update
<seb128> reboot
<seb128> get a system-b boot
<seb128> kernel loaded is 3.19
<seb128> disk / files are 4.0
<seb128> boots fail to load any module
<seb128> sergiusens, that's the summary
<sergiusens> seb128: lib/modules/ only for 4 as well?
<seb128> yes
<seb128> which is basically what fails the boot
<sergiusens> strange
<ogra_> do you have another kernel in /boot directly or some such ?
<seb128> modprobe something gives a "fails to load /lib/modules/3.19..."
<seb128> no
<sergiusens> ogra_: there is, I didn't clean those up either in the 500-.*kernel.* task
<ogra_> sergiusens, perhaps grub falls back to that ... lbut if seb128 says there isnt one ...
<sergiusens> there should be in /boot (system-[ab])
<sergiusens> ogra_: our grub.cfg doesn't look for one there
<seb128> sergiusens, ogra_, http://picpaste.com/grub-9EyGcmUy.png
<seb128> if that helps
<seb128> http://picpaste.com/pics/grub-9EyGcmUy.1436355024.png
<seb128> the vmlinuz size on those matches the 3.19 from hd0,4
<sergiusens> seb128: right, that /boot is system-a/boot/
<seb128> sergiusens, well, in any case $prefix/a|b shouldn't be identical
<sergiusens> seb128: what's in (hd0,2)/[a|b] ?
<sergiusens> oh, sorry it's above
<seb128> right
<seb128> neither matches the system kernel
<seb128> they both match the old image 3.19 one
<sergiusens> seb128: I need to see the system-image delta because this would make them look the same: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-desktop-next/hooks/500-move-kernel-to-device-tar.binary
<seb128> sergiusens, where is the delta?
<sergiusens> seb128: /pool/device-c06d05a678026547b8d48d99556b24281164724e7bffd61c95c261c6e9e3ab70.delta-device-4c246a16efc5ecf0c5f861394250cd68147710376c24d533939365c748939449.tar.xz
<seb128> sergiusens, do you need that from my system or...?
<sergiusens> seb128: oh no, I'm downloading for s-i, you don't have it in it's original form anymore ;-)
<seb128> k
<seb128> let me know if you need more info from me
<seb128> but you can probably reproduce by installed personal 29
<seb128> then doing a snappy update
<seb128> installing*
<sergiusens> seb128: I bet core has the same problem
<sergiusens> fgimenez: ^
<seb128> yeah, I'm doing an install now to see
<seb128> but I would bet the same
 * ogra_ thinks seb128 should just have used the stable personal image ... there also lightdm and the session would work :P
<seb128> :-)
<utlemming> sergiusens, rsalveti: I am happy to report that with 118, we have a working 15.04 edge for Azure.
<rsalveti> utlemming: \o/
<rsalveti> elopio: fgimenez: I published another image yesterday with a minor fix for azure, and hopefully that should be the last known bug we have
<ogra_> utlemming, yay
<fgimenez> rsalveti, ok thx 118 then right?
<sergiusens> utlemming: \o/
<rsalveti> fgimenez: yeah, and 119 for armhf
<rsalveti> they are out of sync
<fgimenez> rsalveti, ok
<fgimenez> sergiusens, sorry wasn't connected :) which problem on core?
<utlemming> sergiusens, rsalveti: thank you guys for the help in getting this cleared. You guys were great :)
<sergiusens> np
<sergiusens> seb128: ogra_ mvo_ Chipaca these are the system image delivered files in the delta: http://paste.ubuntu.com/11841020/
<sergiusens> seb128: ogra_ mvo_ Chipaca assets/vmlinuz and system/boot/vmlinuz-4...
<sergiusens> this is a livecd-rootfs/s-i problem and not a snappy update one I think
<sergiusens> and 'removed' basically removes 3.19
<ogra_> sergiusens, eparse ? (for your last line)
<mvo_> sergiusens: hm, it should be possible to reproduce this on core too - let me try that
<sergiusens> ogra_: the s-i 'removed' file has 3.19 listed as a remove target
<sergiusens> mvo_: yeah, that is the suspicion
<ogra_> ah
<sergiusens> mvo_: I'm not sure how to make livecd-rootfs and/or s-i do what we want though
<ogra_> hmm
<ogra_> how often do we actually copy the azure tarball around ?
<ogra_> there seems to be a cp in live-build/auto/build and there is a hook as well where the same cp gets called
<sergiusens> ogra_: for rolling we shouldn't be needing it soon-ish
<ogra_> well, and even then i guess once would be enough :)
<ogra_> i dont see where livecd-rootfs could be wrong here
<ogra_> the code seems all fine
<sergiusens> ogra_: yeah, I don't either
<sergiusens> ogra_: but how would a different kernel than the one copied end up there?
<ogra_> bug in s-i ?
<sergiusens> ogra_: hmmm, maybe .signed is != than the unsigned one
<ogra_> yeah
<ogra_> well, we dont ship .signed
<ogra_> we copy/move it to be plain vmlinuz, no ?
<sergiusens> ogra_: yes we do, vmlinuz-4.0.0-4-generic.efi.signed
<sergiusens> ogra_: yeah, there's an if in the 500 task that prefers the .signed one
<sergiusens> ogra_: mvo_ that's it
<ogra_> but we should have the signed 4.0 one there at that point
<sergiusens> ogra_: mvo_ I mean, that is the reason for the different sig http://paste.ubuntu.com/11841115/
<ogra_> why would we end up with a 3.x signed one during build
<ogra_> ah
<sergiusens> seb128: can you md5sum the kernels?
<sergiusens> ogra_: they are all 4.0 delivered in the delta
<sergiusens> mvo_: this makes me thing the SyncBootAssets stuff runs after the upgrader logic and it is overwritting
<sergiusens> think*
<seb128> sergiusens, what kernels? the a/b vmlinuz?
<sergiusens> seb128: yeah
<seb128> that's going to match the 3.19 kernel I guess
<seb128> since they are byte identical in size
<rsalveti> Saviq: ogra_: you'll be able to assign hardware to snaps at the gadget snap later on, the spec for that is still in progress
<seb128> from the ls earlier
<ogra_> rsalveti, that still wont enable it in your app snap
<Saviq> rsalveti, ah, /me just wrote a nice post to the snappy-devel  ML ;)
<sergiusens> seb128: right, then no worries
<ogra_> rsalveti, for that you still need to either call hw-assign or have a sideloaded snap that has it enabled
<Saviq> hmm?
<sergiusens> Saviq: rsalveti dev nodes are assignable through the oem snap today
<Saviq> d'oh
<rsalveti> if just hw-assign yeah, you can do that
<rsalveti> but for the gadget snap there is also the idea of abstracting hardware and assigning a special piece of hardware to an app or framework
<sergiusens> Saviq: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<Saviq> ogra_, ppisati, btw, I just grokked what you guys were talking about "the raspi blob and config.txt", I don't think that's a problem as when not using U-Boot (and IIUC booting straight into the kernel) there's no such problems
<Saviq> sergiusens, right, I was sure I read about that somewhere, but it's not there in the oem guide, or in the packaging reference
<sergiusens> Saviq: no it's not :-/
 * sergiusens blames mvo ;-)
<rsalveti> guess we can make an mr for that doc :-)
<ogra_> Saviq, RPi can not boot without the binary blob ...
<mvo_> sergiusens: hm?
<ogra_> Saviq, it is: blob -> u-boot -> kernel
<Saviq> ogra_, yes
<sergiusens> mvo: not documenting the oem hw-assign work :-)
<mvo> *cough*
<mvo> lalalala
<Saviq> ogra_, others go blob -> kernel directly
<ogra_> yes
<ogra_> and dont use an initrd
<Saviq> ogra_, so disabling console=ttyAMA0 there is enough
<ogra_> in the config.txt you mean ?
<Saviq> ogra_, yes
<Saviq> ogra_, but when u-boot comes into play, u-boot itself talks serial, too, so changing uEnv.txt is not enough
<Saviq> ogra_, so all in all I still just need to disable serial in u-boot, and bootdelay 0 gets it done, while obviously not a good solution
<ogra_> well, i fear there is no good solution :)
<ogra_> as long as there is that binary blob ...
<Saviq> that's why I thought dropping "serial" from u-boot's env std{in,out,err} would work, but it didn't (sounds like a bug)
<ogra_> well, sounds like an upstream bug then
<Saviq> ogra_, well, it's u-boot that's problematic in my case, blob isn't great for sure, but isn't a problem atm
<Saviq> ogra_, totally, will go to them to find out
<seb128> sergiusens, mvo, do you want a bug report/more info from me on that upgrade/kernel issue?
<mvo> seb128: I think that would be good, with the exact image versions
<Saviq> beuno, hey, sorry to bug you, could I ask you to remove emonhub-pi.saviq from the store? I had to rename it (if you could ack emonhub.saviq please - it passes click-review with tools-proposed PPA) and it ended up under phone for some reason, as well as snappy
<ogra_> Saviq, isnt there an option in the store UI for you to do it yourself ?
<Saviq> ogra_, can't see it, it's there for drafts, otherwise I can only unpublish
<ogra_> yeah, unpublish was what i meant
<ogra_> unpublish and publish again
<Saviq> ogra_, don't think I can rename this way, can I? and I don't want it under Phone, either, not sure how it ended up there
<ogra_> you can not rename
<kyrofa> seb128, so I created an Ubuntu Personal image with u-d-f and got it in KVM, but I only get the unity8 greeter with the QXL video model, and then my mouse pointer is strangely offset from my actual mouse so I can't possibly get through the edge demo, haha
<ogra_> you need a new submission and delete the old one from the store
<Saviq> ogra_, yeah, which is what I asked for, I can't delete myself it seems
<ogra_> kyrofa, wow, thats more than i get !
<seb128> kyrofa, use virt-manager rather than kvm maybe?
<ogra_> Saviq, you can unpublish
<seb128> kyrofa, I don't get those issues with it
<Saviq> ogra_, that I did
<ogra_> that should delete everything
<Saviq> ogra_, well, it's still there, just not published ;)
<ogra_> and then create a new app in the store under the new name
<ogra_> you can not use the old bits anyway
<kyrofa> seb128, I used virt-manager... thought that was still kvm?
<Saviq> ogra_, that still leaves me with the original in the list, my OCD can't deal with that ;)
<ogra_> heh
<kyrofa> ogra_, what's happening for you?
<ogra_> kyrofa, lightdm with guest account ... if i hit enter it logs into a black screen
<kyrofa> seb128, initially I tried it with regular-old kvm, but them I get the lightdm
<kyrofa> ogra_, try QXL video model
 * ogra_ will ty that later after we released 15.04 :)
<kyrofa> ogra_, that's exactly what I get if I DON'T use QXL
<seb128> kyrofa, k, unsure about the mouse ofset, you should be able to focus the password entry by clicking around no?
<ogra_> (currently my bandwith is used for other images)
<kyrofa> seb128, that's correct, but the edge demo is hopeless haha
<seb128> ogra_, when did you try that? those issues are resolved since friday
<seb128> kyrofa, oh :-/
<kyrofa> seb128, and I don't get a mouse offset with a regular ubuntu image
<seb128> it's just one dnd from the left
<ogra_> seb128, thursday ;)
<seb128> ogra_, k, try again then!
<ogra_> yeah
<ogra_> takes a century to download that image :P
<ogra_> you carry so much bloat
<seb128> lol
 * Chipaca ~> late lunch
<seb128> yeah, what's up with those people installing softwares so you can actually do something with your system
<seb128> rather than watching a blinking cursor
<ogra_> my phone doesnt need all that !
<ogra_> :P
<seb128> no unity8 on your phone, right ;-)
<kyrofa> seb128, talking to kgunn it sounded like when he was testing it earlier lightdm was on vt7 and unity8 was on vt8. I couldn't verify that-- is that still how it's supposed to be working?
<seb128> kyrofa, we activated autologin now so no
<seb128> what kgunn described was when you were getting the greeter at boot
<kyrofa> seb128, when you run the image, do you see a unity8 login or lightdm?
<kyrofa> seb128, ah, okay
<seb128> unity8
<kyrofa> seb128,  but you didn't have to mess with the video model settings at all?
<seb128> you have to use qlx/spice
<seb128> otherwise unity8 doesn't work
<seb128> and you get a session which fails to start and send you back to the lightdm greete
<seb128> greeter
<kyrofa> seb128, ah, okay so that makes sense. Definitely what ogra_ is running into then
<kgunn> unless you install VMM
<kgunn> then it's magic
<seb128> right
<kyrofa> kgunn, haha man, you guys must have a cooler VMM than I do
<kyrofa> kgunn, although I'm running mine on trusty. Too old?
<kgunn> oh may be
<ogra_> hopefully not
<kgunn> kyrofa: curious, what's your desktop gpu
<ogra_> if it is it should be updated via an SRU
<kyrofa> kgunn, I have one of those wonky dual-GPU things. Right now I'm running on intel, but I also have an nvidia auadro K1100M
<kyrofa> kgunn, s/auadro/quadro/
<kgunn> mmm
<kyrofa> kgunn, yeah, if I fire up an VM using the personal.img I made without modifying the config at all, I get lightdm
<kgunn> oh ok
<kgunn> kyrofa: but from scrollback, you're seeing mouse offset being an issue as well ?
<kyrofa> kgunn, if I fire it up and modify the explicitly use QXL, I get unity8 but my mouse is offset enough I can't make it through the demo
<kyrofa> kgunn, yeah
<kgunn> yeah, edge demo was really tricky for me, but got thru
<kgunn> still not tried yet on wily, am going to as soon as i get off this hangout i'm on :)
<kgunn> HO + vmm at once is bad :)
<kyrofa> kgunn, haha
<sergiusens> seb128: mvo I'm going through the code now, but I have a feeling
<kyrofa> seb128, I switched from VPN to spice in VMM and now I can't seem to click on anything at all
<kyrofa> seb128, ugh... VNC. Been dealing with the VPN lately
<kyrofa> I wonder if bregma has played with this at all yet. Get it running on any hardware?
<mvo> sergiusens: the s-i code? or snappy? sorry, was in a meeting
<kyrofa> seb128, ah, I got it working!
<sergiusens> mvo: I think SyncBootloader files is being done after applying the updates
<mvo> sergiusens: ohhh
<kyrofa> seb128, this is cool man, awesome job!
<mvo> sergiusens: that rings a bell, it might be me who broke that :(
<sergiusens> mvo: essentially stepping over
<kyrofa> ogra_, kgunn I had to explicitly set QXL and spice in VMM, and make sure there were no tablet devices in the hardware list (I added one messing around with trying to get VNC to work). VNC worked, but gave me a mouse offset. Spice seems to work great
<mvo> sergiusens: I think you are spot on
<sergiusens> mvo: I wish I were; but it seems it is not the case
<kyrofa> seb128, other than that trouble (which was really my own fault), the only thing I ran into was SSH. There's an SSH server, but it has no host keys. Is that a feature?
<mvo> sergiusens: meh, ok
<sergiusens> mvo: systemimage.go:180 shows me a sync first and then an applying updates from the server
<sergiusens> seb128: in your grub you had a hardware.yaml inside a/b, right?
<kyrofa> sergiusens, what conclusions can I make if `snappy search webdm` gives me nothing?
<sergiusens> kyrofa: that's it's not available for the released image you are using
<kyrofa> sergiusens, ah, so when it was uploaded to the store it was specifically targeting ubuntu-core?
<sergiusens> kyrofa: maybe
<kyrofa> sergiusens, any chance we could get it targeting ubuntu-personal as well?
<sergiusens> kyrofa: and this says yes http://search.apps.ubuntu.com/api/v1/package/webdm
<sergiusens> kyrofa: sure, if in a hurry just download from the anondownload link there
<kyrofa> sergiusens, ah, good idea. No rush then :) . The snappy scope just needs it until the snappy service has the API. Then webdm can stop targeting ubuntu-personal
<seb128> sergiusens, yaml, yes
<sergiusens> seb128: mvo I found the issue; "HandleAssets" is ignored because it can't find the hardware.yaml in writable/cache/system during the upgrade
<elopio> good morning.
<ogra_> schnaaapiee
<elopio> http://paste.ubuntu.com/11839856/
<elopio> can somebody give me a hand here? This happens on beagle the second time we fake an update ^
<elopio> any idea what could cause it? Works alright on kvm.
<sergiusens> mvo: and I know why the hardware.yaml is not coming through in the update... it doesn't change
<sergiusens> mvo: ogra_ https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158 if that works, we should get it in for seb128's personal
 * ogra_ goes to check his wine cave to see what kind of bribes tro accept
<sergiusens> lol
<sergiusens> rsalveti: elopio mvo fgimenez Chipaca btw ^ should be affecting 15.04 and bbb; luckily we now have the same codepath in rolling so it's faster to detect
<sergiusens> I'll explain during standup
 * rsalveti looks
<seb128> sergiusens, changes in livecd-rootfs impact the image build, do they also impact the upgrades?
<rsalveti> cool, will wait you to explain the issue during the standup
<seb128> sergiusens, because a fresh image boots fine
<sergiusens> seb128: yeah, hmm
 * sergiusens notices he'll have to explain twice
<seb128> sergiusens, don't bother explaining it to me if I just don't get how the snappy details
<seb128> as long as you are sure it's going to do the trick ;-)
<sergiusens> seb128: what happens is snappy ignores the new kernel and initrd if there is no hardware.yaml, the s-i doesn't not provide the hw.yaml because it is always the same, so it is essentially ignored and you do't get the new kernel
<sergiusens> seb128: adding versioned kernel's and initrd's to the hardware.yaml effectively changes the file and triggers s-i to provide it
<seb128> I see
<sergiusens> that's it in a nutshell
<seb128> sergiusens, thanks for the explanation
<sergiusens> oh, and the important part is that it is ogra_'s fault!
<sergiusens> :-D
<ogra_> yeah, sorry
<ogra_> :P
<seb128> he better makes up for it by reviewing the fix then! :-)
<ogra_> you just want to keep your wine !
<ogra_> the fix looks fine :)
<ogra_> ppisati, http://paste.ubuntu.com/11839856/ any idea what that means ?
<ogra_> seems elopio gets that on upgrades
<elopio> ogra_, ppisati: more precisely, on the second fake update. We change the channel cfg to have version -1 to test snappy update on the latest image.
<elopio> the first time we do that, it works. The second time, the board doesn't boot.
<ogra_> elopio, right, that shouldnt really matter ... though what i dont get is that it is the second upgrade but it boots from the b partition
<ogra_> if it is the second it should boot from a
<ppisati> same kernel and same dt? weird
<ogra_> not sure it is the same
<ppisati> FDT_ERR_BADLAYOUT
<ogra_> yeah
<ppisati> sounds like a malformed dtb
<ppisati> if these are not the same, try to switch to the old one
<ppisati> if they are the same, can you check with md5sum?
<ppisati> and report the version if they are different
<ogra_> elopio, ^^ can you try that ... alos check if there is actually a dtb
<ogra_> on the b dir
<ppisati> it seems there is
<ppisati> because it's loading it
<ppisati> reading b/dtbs/am335x-boneblack.dtb
<ppisati> 30025 bytes read in 9 ms (3.2 MiB/s)
<ogra_> oh, right
<ppisati> i wonder if it's intact and sound
 * elopio checks some things.
<seb128> hum
<ogra_> dont say that !
<seb128> so in snappy list, upgrade, etc the system refers to "ubuntu-core" versions
<ogra_> (that usually means something bad)
<seb128> even on personal
<seb128> lol
<seb128> that one is a detail :-)
<ogra_> haha
<seb128> I wonder if there is a valid wishlist there
<seb128> or if we see personal as a temporary thing/don't want to abstract the name
<ogra_> definitely worth a bu, though i guess once ubuntu-* are snaps it will fix itself
<ogra_> *a bug
<seb128> https://launchpad.net/ubuntu/+source/ubuntu-snappy/+bugs
<seb128> 3 bugs reported only
<seb128> I've a feeling snappy is one of those projects with unsynced buglists :p
 * ogra_ quietly points to the channel topic :)
<seb128> yeah
<sergiusens> seb128: create a bug please, that's an easy fix
<sergiusens> seb128: goes back to the hardcoded days (but I haven't been able to remove all)
<seb128> sergiusens, https://bugs.launchpad.net/snappy/+bug/1472676
<ubottu> Ubuntu bug 1472676 in Snappy "refers to "ubuntu-core" even for "ubuntu-personal" images" [Undecided,New]
<sergiusens> seb128: thanks
<seb128> yw!
<sergiusens> ogra_: hmm, mvo seems to be MIA, can you validate this? http://paste.ubuntu.com/11842157/ (I can upload)
<ogra_> sergiusens, ACK., go ahead
<sergiusens> ogra_: thanks
<seb128> ogra_, sergiusens, should the same be done to desktop-next?
<sergiusens> seb128: doing it differently on desktop next, this is just for 15.04
<seb128> k
<sergiusens> seb128: the other MP, if it works, we will use for desktop-next as well
<seb128> great
<ogra_> sergiusens, well, but seb128 surely wants https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158 for that
<sergiusens> ogra_: yup
<sergiusens> after we know it works
<ogra_> sergiusens, merged and uploaded
<sergiusens> yuppie
<sergiusens> rsalveti: elopio fgimenez ogra_ I'm going to trigger a 15.04 image build in a bit which might solve the hardware.yaml on upgrades issue for bbb
<ogra_> yay
<sergiusens> oh, stuck waiting on arm64
<sergiusens> ogra_: do you just cancel the build?
<ogra_> yep
<fgimenez> sergiusens, ack thanks
<kyrofa> sergiusens, the anon download link for webdm is giving me a 503. Any ideas?
<elopio> kyrofa: here too.
<kyrofa> elopio, oh. Maybe it actually IS temporarily unavailable, eh?
<elopio> kyrofa: maybe. beuno do you know something?
<beuno> yes
<beuno> it's down
<ogra_> there is a bunch of stuff down atm
<ogra_> phones cant install apps either currently
<sergiusens> kyrofa: store is down
<rsalveti> lovely
<rsalveti> right time for lunch
<ogra_> heh
<kyrofa> sergiusens, beuno thanks guys. Is there a status page I can keep an eye on?
<beuno> kyrofa, not at the moment, no
<beuno> sorry
<kyrofa> beuno, that's alright. Any estimate?
<beuno> kyrofa, minutes, 5-30
<kyrofa> beuno, great, thank you :)
<seb128> ogra_, thanks for the merge/upload
<ogra_> np
<ogra_> i'll trigger a core build too so it can be tested
<kgunn> seb128: i updated to wily, just tried personal image....works like a champ! \o/
<seb128> kgunn, excellent!
<kgunn> bregma: willcooke ^
<bschaefer> ogra_, hello, so i've my raspi2 image set up with snappy, but it seems to be missing the /dev/dri/card*? This will seem to be problematic for running a mir server
<bschaefer> i was told possibly something is missing from the kernel in that image?
<ogra_> bschaefer, well, that will need a lot more extra work to make the binary blob work to actually drive the graphics HW
<bschaefer> ogra_, shoots
<bschaefer> bregma, kgunn ^
<bschaefer> ogra_, is this the same with the BBB? (besides not being able to flash the eMMC)
<ogra_> the upcoming 15.04 image will have some raw support to hack overlay dtb's and graphical options into the kernel commandline
<ogra_> the BBB isnt suitable for graphical stuff
<bschaefer> i see, thats what i heard but wasnt sure :)
<bschaefer> ogra_, do you know when that image would be released?
<ogra_> dont bother with it ... it is fine for a single app for mmanaging some relais on an attached touchscreen or some such
<bregma> ogra_, what's the expecxted delivery date for the PI image?
<ogra_> but you wont be running a desktop on a BBB
<bschaefer> ogra_, right, yeah just trying to figure out whats possible and not
<ogra_> bregma, for the 15.04 uupdate ? this week i think
<bschaefer> ogra_, awesome thank you!
<bregma> ogra_, and we'll be able to run Mir on the PI then?
<ogra_> i'll also start providing buuilds of the edge channel with that hw tarball and oem snap
<ogra_> bregma, well, it is 15.04
<ogra_> not sure how much you can do on that base ... i would assume you want to wait for the edge image (on my plan for next week)
<kgunn> 15.04 prollly ok to start with
<ogra_> ah, fine then
<kgunn> ogra_: why is BBB not good for gfx ?
 * kgunn has no history
<bregma> no binary blob graphic driver support for gles, I assume
<ogra_> kgunn, single core-industirl-embedded CPU ... while it has a GPU it is really not a powerful one
<kgunn> ogra_: it has like a sgx530 or some such i thot
<ogra_> i think there is an SGX driver for it but that likely needs a specific (and likely very old) kernel and patches
<kgunn> which is enough for kiosk type thingy
<ogra_> right
<bregma> Mir support for software rendering should fix that, as I understand it
<ogra_> thats what i meant above
<bschaefer> it would still need to support running the server
<ogra_> enough to run a UI for your heating controller as single purpose UI
<bschaefer> which from what i understand you need at lease the /dev/dri/card0*
<beuno> downloads should be back
<bregma> that is definitely what we're aiming for here
<kgunn> ogra_: ok, so it's possible, "we" 're just not investing in it (bbb gfx)
<ogra_> bschaefer, i thought dri is dead ? and it is all kms nowadays
<ogra_> kgunn, it isnt suitable for desktop ... if you want to build a kiosk thingie, go ahead :)
<kgunn> k
<bschaefer> ogra_, err i suppose i could be looking for that as well... that was just waht i got when i was talking to #mir yesterday :)
<bregma> all we really need for kiosk should be good 2D acceleration
 * bschaefer hopes it works outside of that
<ogra_> (though the price you pay for BBB plus LCD cape will likely be more expensive than a cheap tablet)
<kgunn> hehe
<bschaefer> ogra_, pfft it has a mini HDMI
<ogra_> heh
<bschaefer> but yeah still more expensive
<bschaefer> (if you get a small screen)
<kgunn> ok, gonna run/lunch bbiab
<bregma> a BBB, and old cast-off monitor, a carboard box and some duct tape is all I need to build my info-kiosk for my front door
<bschaefer> haha
<ogra_> thnen you just need to learn to use directfb
<ogra_> that should work already :)
<ogra_> without any drivers
<bregma> I don't think that's yet available in Mir
<ogra_> no, that is something lower than Mir
<ogra_> talking directly to /dev/fb0 via a lib
<ogra_> (unaccelerated 2D)
<elopio> kyrofa: udf works for me now, maybe your server is up too.
<kyrofa> elopio, yeah, all good here. Thanks beuno!
<kyrofa> sergiusens, do you know anything about the snappy examples?
<kyrofa> sergiusens, lp:~snappy-dev/snappy-hub/snappy-examples
<kyrofa> sergiusens, the hello-dbus example puts the service into a framework and the client into an app. Is there a good reason to do that instead of including both in the same snap?
<kyrofa> Looks like jdstrand initially wrote it. jdstrand ^^ any input?
<sergiusens> kyrofa: because the app depends on the framework, it's the only dependency chain allowed
<sergiusens> kyrofa: and it's just an example, so maybe useless for a real case
<kyrofa> sergiusens, but couldn't a single snap include both the dbus service and the client?
<sergiusens> kyrofa: yes they can
<sergiusens> kyrofa: I had that in one of my apps from before the release
<sergiusens> elopio: rsalveti do you have a revno for 15.04 on edge handy with an older kernel?
<rsalveti> sergiusens: hm, not handy
<rsalveti> sergiusens: we landed a new kernel on monday
<kyrofa> sergiusens, is there a reason to do one over the other? I understand that this is just an example, I'm just curious. Obviously a framework can be relied upon by multiple snaps, and it decouples the service and the client. Would that really be the only reason to do it that way?
<rsalveti> since then, I believe we did 2,3 new builds
<elopio> sergiusens: no sir. Just old 15.04 stable here.
<sergiusens> rsalveti: k, will check some dates in the index; I wish this process weren't so manual :-)
<sergiusens> kyrofa: different vendors providing extensions
<sergiusens> kyrofa: just like docker
<sergiusens> kyrofa: docker framework and runtimes/dockerapps in apps
<sergiusens> kyrofa: I don't know how to make it clearer :-)
<kyrofa> sergiusens, alright, makes sense. Thanks :)
<rsalveti> sergiusens: well, you own the tool that interacts with that server :P
<sergiusens> rsalveti: but not the one that does the s-i->cdimage part
<kyrofa> beuno, how do manual snap upload reviews occur? How long does it typically take?
<sergiusens> rsalveti: do you see a problem with this? http://paste.ubuntu.com/11842157/
<rsalveti> sergiusens: looks fine
<sergiusens> rsalveti: I get 'hashes: -\n' after building
<beuno> kyrofa, as a rule, if something is manual it will likely get rejected
<sergiusens> rsalveti: oh, ic the problem :-/
<sergiusens> I think
<rsalveti> sergiusens: either the var is not protected or we got nothing with md5sum
<sergiusens> rsalveti: yeah, I don't see the problem, damn shell scripts
<ogra_> whats the issue
<kyrofa> beuno, hmm. I'm referring to the last paragraph on this page: https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<sergiusens> lol
<kyrofa> beuno, it implies that all snap reviews are manual?
 * sergiusens thinks ogra_ has a highlight for shell script blasfemy
<rsalveti> lol
<ogra_> shhh
<sergiusens> ogra_: I get 'hashes: -\n' after building
<sergiusens> ogra_: with http://paste.ubuntu.com/11842157/
<beuno> kyrofa, they are not. They are automatic and get approved within seconds (if they pass automatic review scripts_
<beuno> kyrofa, that's outdated, I guess
<ogra_> sergiusens, hmm, i think thats a bashism
<beuno> asac, who maintains this?  https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
<ogra_> cut -f1 -d' '
<ogra_> instead of cut -f1 -d\
<kyrofa> beuno, ah! Okay good deal
<sergiusens> ogra_: ok
<sergiusens> ogra_: is that the only thing? I want to avoid another 30 cycle :P
<rsalveti> beuno: our team I guess, why?
<ogra_> sergiusens, not sure, do you have any log ?
<beuno> rsalveti, it says all submissions are manual
<rsalveti> sergiusens: guess you can easily test that logic locally first
<beuno> they are not
<ogra_> quotes wouldnt be abd either i guess
<ogra_> *bad
<sergiusens> rsalveti: I have
<rsalveti> beuno: yeah, we can update that
<beuno> rsalveti, thanks
<ogra_> sergiusens, in any case make sure to have a "set -ex" at the top of the script, then we get more detailed logs ... log space is cheap
<sergiusens> rsalveti: ogra_ ... md5sum: /tmp/tmp.csXhKqYL59/assets/vmlinuz: No such file or directory
<sergiusens> there we go
<ogra_> aha
<jdstrand> kyrofa: I did it as an example of writing a framework that another snap would depend on. it is fine for a framework to ship other services or binaries
<kyrofa> jdstrand, thank you
<kyrofa> jdstrand, hey, thanks for the email about the QHD stuff too. Nice to have crisp notifications again, haha
<jdstrand> kyrofa: I know, right? that was annoying
<jdstrand> glad it helped :)
<ogra_> sergiusens, hmm, where do you see that ? the build log properly has http://paste.ubuntu.com/11842705/
<sergiusens> ogra_: it's set
<ogra_> yeah, just noticed
<sergiusens> ogra_: https://launchpadlibrarian.net/211113785/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz
<kyrofa> jdstrand, it's just such a beautiful, crisp screen... and then... yeah
<ogra_> cat'ing hardware..yaml at the end would be helpful
<ogra_> sergiusens, LOL
<ogra_> sergiusens, vmlinux != vmlinuz ;)
<ogra_> (your patch has a typo)
<sergiusens> ogra_: yeah, fixed
<sergiusens> ogra_: still won't fix the issue ;-)
<ogra_> yeah
 * ogra_ looks at the full code ...
<ogra_> who wrote that code originally ?
<ogra_> (why are there all these brackets ?)
<sergiusens> ogra_: mvo did
<Saviq> jdstrand, I know you'll hate me, but I'll need an ACK for emonhub.saviq please, same old same old (but I renamed the app...)
<sergiusens> ogra_: interesting, hashes thing seems to be fine for armhf builds
<sergiusens> ogra_: I just need to fix that type; on 15.04, hardware.yaml is only used by the bbb
<ogra_> well, i think the brackets cause all that stuff between them to be executed in a subshell (which seems a bit ppointless but doesnt explain why you end up with empty vars in the here doc)
<sergiusens> ogra_: the parens you mean?
<ogra_> yeah
<sergiusens> unspecific germans, sigh :-P
<ogra_> i dont really get why mvo used them
<jdstrand> Saviq: no worries. I think pindonga said the store would be updated today
<sergiusens> ogra_: http://paste.ubuntu.com/11842767/
<jdstrand> Saviq: it isn't downloading right
<sergiusens> ogra_: I think I prefer that
<jdstrand> Saviq: I get just an empty file
<ogra_> sergiusens, yeah ... and add quotes around the $()
<sergiusens> ogra_: ok
<jdstrand> beuno: looking at https://myapps.developer.ubuntu.com/dev/click-apps/3029/review/, if I try to download I only get an empty file
<beuno> jdstrand, yes, slight issue atm
<jdstrand> beuno: is there an issue with the store?
<beuno> will ping back
<jdstrand> ah, ok
<jdstrand> Saviq: ^
<sergiusens> ogra_: http://paste.ubuntu.com/11842781/
<beuno> for a handful of packages
 * sergiusens dputs
<ogra_> sergiusens, thats schnappy :)
<sergiusens> \o/
<sergiusens> ogra_: I might need one more fix to make this bullet proof
<ogra_> sergiusens, well, and a "cat $TMPDIR/hardware.yaml" at the end of the script to get it into the log might not do harm either
<ogra_> saves you from having to install an image to find out the file is brooken
<ogra_> -o
<ogra_> (or download or whatever)
<jdstrand> sergiusens: there are ubuntu personal images now?
<jdstrand> sergiusens: cause we need to figure out how to deal with security policy in snappy build
<kyrofa> jdstrand, yeah, seb128 has been working on them
<elopio> sergiusens: did you find the rev# of the old kernel?
<jdstrand> sergiusens: since my plan was to use existing phone policy for ubuntu-personal
<sergiusens> jdstrand: yes there are
<jdstrand> sergiusens: so that means snappy build needs to know about core vs personal and pick the right policy vendor
<sergiusens> jdstrand: and seb128 is creating/seeding all the bits
<sergiusens> jdstrand: yes, I've proposed adding a --release to Chipaca and mvo
<jdstrand> (not to mention we need to work out what to do for policy version instead of just hardcoding 15.04
<jdstrand> )
<jdstrand> ok, cool
<utlemming> sergiusens: er, looks like build 119 broke cloud images
<utlemming> sergiusens: sgdisk is needed in for cloud-init to resize the disk
<sergiusens> utlemming: is that rolling or 15.04?
<utlemming> sergiusens: 15.04
<ogra_> utlemming, where does that dep come from all of a sudden ?
<ogra_> (also did you consider making it a dependency of the cloud-init package then ? )
<utlemming> ogra_: that is likely my fault of not catching it in cloud-init logs -- my apologies
<utlemming> ogra_: checking on the dep piece
<ogra_> utlemming, well, i dont get why it worked before in 15.04 and in 119 it doesnt
<utlemming> orga_: yeah, lets hold on that for a minute...let me dig deeper before calling it the cause
<ogra_> doesnt look like we ever had gdisk installed
<beuno> jdstrand, fixed
<jdstrand> thanks!
<sergiusens> ogra_: http://paste.ubuntu.com/11842889/
<ogra_> sergiusens, looks good ... go ahead
<sergiusens> ogra_: rsalveti seems to be one problem still and I'm not sure how to solve; but if we pull a new initrd and no new kernel, then s-i would remove the kernel from the delta and the upgrade would fail
<ogra_> hmm
<kyrofa> sergiusens, looking at the snappy examples in contract to the snappy document, can I safely assume that .svg icons are no longer required even though the docs say so?
<sergiusens> ogra_: it's almost as if s-i should generate the hardware.yaml
<sergiusens> kyrofa: I don't attest to that; I'll leave that to beuno
<sergiusens> kyrofa: we are mostly killing package.yaml in the future btw...
<utlemming> ogra_: red-herring
<kyrofa> sergiusens, ah, good to know. Is there other docs I should be referring to to build snaps, then?
<sergiusens> kyrofa: well, if you are targetting rolling, the docs on developer.u.c are not what you want
<sergiusens> lp:snappy /docs
<sergiusens> but I don't think there is anything in place yet
<kyrofa> sergiusens, I am indeed. Thank you!
<sergiusens> kyrofa: rolling has no docs yet and anything is subject to change ;-)
<rsalveti> sergiusens: why would the upgrade fail?
<kyrofa> sergiusens, that's alright, I can roll with it
<utlemming> ogra_: the reason I wasn't seeing the error before was that with /etc/cloud/cloud.cfg.d being a writable path, the regular configurations where not being read when I built an image with that content populated.
<utlemming> i.e I put stuff in /writable/system-data/etc/cloud/cloud.cfg.d
<ogra_> ah
<sergiusens> rsalveti: because now the opposite happens, during the livecdrootfs phase we don't know what will be added or removed, so we add a kernel and initrd entry
<ogra_> yeah, understood
<sergiusens> rsalveti: but s-i might determine that initrd doesn't need to be in th delta
<sergiusens> rsalveti: so the entry would point to an invalid file
<sergiusens> rsalveti: as I was telling ogra, it feels like livecdrootfs is the wrong place to generate this file and it should be done during s-i
<rsalveti> right, indeed
<rsalveti> sergiusens: so what can we do for now?
<sergiusens> rsalveti: update both
<sergiusens> rsalveti: or none
<sergiusens> rsalveti: this problem exists in rolling as well
<rsalveti> guess just update both
<rsalveti> right, maybe not something we need to fix for this stable release
<ogra_> well, how do you update both if one didnt change ?
<rsalveti> since your fix should already be enough for the current issue
<ogra_> in snappy ?
<sergiusens> ogra_: generated images should update both init and kernel or the updates would fail
<ogra_> sergiusens, right, but how do you enforce that ?
<ogra_> if one of them is missing thanks to s-i
<sergiusens> ogra_: we control the stable channels, so it is easier
<sergiusens> ogra_: in the end, if we want to survive, we would need to have s-i generate the hardware.yaml
<ogra_> yes
<rsalveti> sergiusens: yeah, stable is fine for now I'd say, but definetly something we need to fix in s-i
<rsalveti> sergiusens: just create a card for it and put it in the backlog
<sergiusens> rsalveti: card created, I need to leave for a bit
<rsalveti> sergiusens: sure
<rsalveti> sergiusens: did you trigger a new image with your recent change?
<ogra_> yes, he did
 * ogra_ cancels the arm64 build
<rsalveti> cool
<Letozaf_> hey guys, once you installed packages like snake, and chatroom, for instance, If I do not know them and how they work, how can I find out? Is there some documentation somewhere, if I have to check if they work after install I have to know how they work.
<ogra_> Letozaf_, webdm is supposed to show descriptions and also have a link that opens their externally defined port
<ogra_> the description stuff is still broken i think
<Letozaf_> ogra_, I will try again, but yesterday the link did not open anything, just a blank browser page
<ogra_> for which app ?
<Letozaf_> ogra_, yesterday I install snake and chatroom, just these two, but could not try them out
<ogra_> hmm, works fine here ... i click on "raspberyy pi2" in webdm ... then on chatroom ... and there on open/manage
<ogra_> that opens the chatroom page for me
<Letozaf_> ogra_, I will try again just now, give me two minutes
<ogra_> sure
<ogra_> (note that chatroom only works in chromium ... (which the description would tell you if it would be shown :P ))
<ogra_> sergiusens, rsalveti, hmm, that didnt work it seems
<ogra_> https://launchpadlibrarian.net/211130437/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz
<ogra_> oh
<ogra_> ignore that :P
<ogra_> wrong arch :P
<ogra_> hmm, doesnt look like the "cat hardware.yaml" is executed
<Letozaf_> ogra_, I am running yesterday's snappy 15.04 amd64 image (ubuntu-core vers. 117) I installed chatroom and in  Chromium when I click on "open/manage" I get "The webpage is not available" message
<ogra_> weird
<rsalveti> ogra_: cat should only show up on armhf, right?
<Letozaf_> ogra_, I am runnin wily on my Desktop PC
<ogra_> Letozaf_, http://webdm.local:6565
<ogra_> try that
<ogra_> rsalveti, right, but it doesnt
<Letozaf_> ogra_, same: This webpage is not available
<ogra_> i can see the hashes being assigned to the vars though
<ogra_> but that worked before already
<ogra_> Letozaf_, weird, works fine on armhf ... i havent tried on amd64 in a while i must admit
<rsalveti> ogra_: indeed
<rsalveti> ogra_: guess we can open the device tarball and see
<Letozaf_> ogra_, I have Wily installed and I am also using systemd
<ogra_> yeah :/ ... thats what the cat was supposed to avoid
<ogra_> but cats never do what you want :P
<Letozaf_> am I the cat ? LOL
<ogra_> lol
<ogra_> meow
<ogra_> no :)
<ogra_> Letozaf_, a "cat" command that is supposed to put stuff in a logfile ;)
<Letozaf_> ogra_, Hah! the cat command I thouth you were talking about a cat animal lol
<Letozaf_> lolololo
<Letozaf_> rotfl
<ogra_> :D
<elopio> ppisati: ogra_: http://paste.ubuntu.com/11843280/
<elopio> was that what you wanted me to compare? How to know if it's correct?
<ogra_> elopio, well, does it boot from a ?
<elopio> and ogra_, it tries to boot first a, then it tries b. And keeps retrying be.
<ogra_> if ti is in that state
<ogra_> ah
<ogra_> and both print that dtb error ?
<elopio> what I pasted before was not the first try.
<ogra_> well, i'd like to see the error from an a boot
<ogra_> before it panics and reboots
<elopio> let me see if I pasted that one somewhere.
<elopio> nop. I hate that I can't scroll back on screen.
<elopio> I will reproduce it one more time.
<ogra_> partition-layout: system-AB
<ogra_> hashes: 462b31071b9f41c50ef05670ca764780-9b0c722b5d417f5152a4f5a5d5084910
<ogra_> dtbs: assets/dtbs
<ogra_> rsalveti, sergiusens ^^ looks fine
<rsalveti> ogra_: yeah, now to test the upgrade and see :-)
<ogra_> argh
<ogra_> but we have everything duplicated in assets
<ogra_> that makes it 52MB big now
<rsalveti> what
<ogra_> initrd.img and initrd.img-3.19.0-22-generic ...
<ogra_> same for the kernel
<Letozaf_> ogra_, it works, it was a port redirect error :-P
<ogra_> ha !
<ogra_> Letozaf_, awesome :)
<Letozaf_> ogra_, sorry for the hassle :)
<ogra_> np
<ogra_> i do that all the time when using kvm :)
<Letozaf_> :-)
<ogra_> rsalveti, wow, an we ship each and every available dtb by default
<ogra_> 8MB of dtb files
<rsalveti> ogra_: right, at the kernel snap that is expected
<ogra_> once that exists, yeah
<rsalveti> well, it's the evolution from the device tarball :-)
<ogra_> evolution ... like growing a third arm to pick your nose and such :P
 * ogra_ likes that the device tarball is small and on the point ... 
<ogra_> but for generic thats probably fine ...
<rsalveti> right
<ogra_> though wasting 25MB for the kernel and initrd duplication doesnt feel right
<ogra_> i wonder if we can safely drop the unversioned ones
<ogra_> hmm, no .. hardware.yaml uses them by default
<Saviq> the 'services' and 'no-cloud' config options from https://developer.ubuntu.com/en/snappy/guides/oem/ are a wish for now, right?
<elopio> ogra_: http://paste.ubuntu.com/11843609/
<elopio> that's the first error booting a after the second update. Same badlayout.
<ogra_> elopio, so the dtb file is corrupt in general
<elopio> I wonder if two real updates in a row end up in this too
<elopio> I'll have to wait for tomorrow to check that.
<rsalveti> can't we specify the version we want to update?
<rsalveti> if this indeed causes an issue, we might just break everyone that is using bbb :-)
<elopio> rsalveti: not without faking things.
<elopio> fgimenez did a script to update to rev -1
<rsalveti> right
<elopio> Full adventure logs:
<elopio> http://paste.ubuntu.com/11843622/
<elopio> http://paste.ubuntu.com/11843624/
<elopio> I don't know how remounting / could cause this. I'll flash 94, update to 95, and wait for 96 to be available.
<rsalveti> we can trigger a new wily one if you want
<rsalveti> let me do that while you flash 94
<elopio> rsalveti: wait for me to finish the update to 95
<rsalveti> elopio: sure, on your command :-)
<elopio> it will take like ~30 minutes here to do the whole dance.
<rsalveti> right, probably the same time it takes to get the new image out
<elopio> rsalveti: I'm in #95. go, please.
<rsalveti> elopio: done
<elopio> oh shit. The reboot ended up in emergency mode.
<rsalveti> man, we got some serious issues with bbb
<elopio> I bet when I decided to work in QA, all the bad karma came in my aid.
<ogra_> rsalveti, serious and weird
<elopio> fwiw, federico could reproduce the second update issue.
<elopio> and I haven't had an emergency mode for two weeks now.
<ogra_> rsalveti, btw, do we have any complelling reason to use vfat and not ext2 ? we always seem to have issues with files on the fat
<rsalveti> not sure, would need to ask lool I guess
<rsalveti> probably because vfat is usually supported everywhere
<rsalveti> even with super old uboot
<ogra_> yeah
<ogra_> but we insist on the very latest uboot :)
<rsalveti> right, which is why would be good to check with lool
<ogra_> and we use very new features too
<ogra_> bah, crap
<ogra_> wily needs the same change in livecd-rootfs
<Saviq> is there a place recommended to file bugs about docs?
<ogra_> + cp -ar boot/initrd.img-* /tmp/tmp.MYidIUKLNU/assets/
<ogra_> cp: cannot stat 'boot/initrd.img-*': No such file or directory
<ogra_> E: config/hooks/500-move-kernel-to-device-tar.binary failed (exit non-zero). You should check for errors.
<ogra_> P: Begin unmounting filesystems...
<ogra_> grrrr
<elopio> Saviq: about docs in developer.ubuntu.com?
<Saviq> elopio, yeah
<elopio> Saviq: https://bugs.launchpad.net/developer-ubuntu-com/
<Saviq> elopio, thanks
<elopio> Saviq: please link the bug here.
<kyrofa> jdstrand, so if I write a dbus service, I'm getting the impression that it _must_ be a framework. Yes?
<jdstrand> yes
<jdstrand> bus-name is only available to frameworks
<kyrofa> jdstrand, right, okay. Does that immediately mean that I need custom apparmor profiles? All the service does is obviously listen on dbus and act as a network client
<elopio> ugh, this is no good. Tried again and I'm in emergency mode. It's good I ordered more sd cards.
<elopio> can somebody try a bbb update from rolling edge #94?
<Saviq> bug #1472778
<nothal> Bug #1472778: "start exploring snappy..." link feels broken <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472778>
<ubottu> bug 1472778 in Ubuntu Developer Portal ""start exploring snappy..." link feels broken" [Undecided,New] https://launchpad.net/bugs/1472778
<jdstrand> kyrofa: that isn't enough-- you need to have dbus bus policy to start a dbus service. I'm confused though-- why does an app need to be a dbus service?
<elopio> Saviq: :) would you think it's better to link directly to the snappy tour instead?
<Saviq> bug #1472780
<nothal> Bug #1472780: No documentation about "assign" in oem guide <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472780>
<ubottu> bug 1472780 in Ubuntu Developer Portal "No documentation about "assign" in oem guide" [Undecided,New] https://launchpad.net/bugs/1472780
<Saviq> elopio, TBH I'd just drop the link
<Saviq> elopio, you're looking at "Next steps" by the time you're clicking it already
<ogra_> sergiusens, fixed a quoting issue with the wily livecd-rootfs MP, uploaded
<elopio> Saviq: done.
<rsalveti> ogra_: thanks for uploading the fix
<kyrofa> jdstrand, it's the scope to install snaps for ubuntu personal. Scopes can't maintain state, thus the stateful bits are pulled into a dbus daemon
<kyrofa> jdstrand, so there are two parts-- the dbus daemon and the scope itself
<Saviq> bug #1472782
<nothal> Bug #1472782: webcam guide's assign/part-id does not work <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472782>
<ubottu> bug 1472782 in Ubuntu Developer Portal "webcam guide's assign/part-id does not work" [Undecided,New] https://launchpad.net/bugs/1472782
<Saviq> elopio, â that might be really a snappy bug, but it's unclear without real docs about assign
<ogra_> rsalveti, so i guess it will still take a while til there is something to copy to the alpha channel
<rsalveti> ogra_: yeah, not today
<ogra_> cool
<rsalveti> it's all fine and good until we start finding blockers all around
<ogra_> (or not)
<elopio> Saviq: thanks for the bugs. I'm not sure, so I'll left them for somebody to triage.
<Saviq> bug #1472783
<nothal> Bug #1472783: oem guide mentions unsupported config parameters <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472783>
<ubottu> bug 1472783 in Ubuntu Developer Portal "oem guide mentions unsupported config parameters" [Undecided,New] https://launchpad.net/bugs/1472783
<Saviq> elopio, there's some indentation issues on https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<elopio> we are trying to fix the doc bugs before the next release.
<Saviq> elopio, in the yaml listings
<Saviq> bug #1472784
<nothal> Bug #1472784: oem guide does not explain immutable config properly <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1472784>
<ubottu> bug 1472784 in Ubuntu Developer Portal "oem guide does not explain immutable config properly" [Undecided,New] https://launchpad.net/bugs/1472784
<jdstrand> kyrofa: why wouldn't this be shipped as part of the ubuntu personal image like it is on touch?
<kyrofa> jdstrand, it can be. We figured it would be easier to update if it was a snap
<kyrofa> jdstrand, do you disagree?
<jdstrand> kyrofa: you can't right now. today, you must be framework to be able to be a dbus service
<jdstrand> kyrofa: note you can't do this as a click either
<jdstrand> kyrofa: because you need to adjust dbus bus policy (ie, not apparmor) in order to be a service
<jdstrand> there is no current mechanism to do that (unless you are a framework snap)
<kyrofa> jdstrand, is it a big deal for it to be a framework snap?
<jdstrand> kyrofa: I suggest for now keeping it in ubuntu personal image and bringing this up with the architects group
<jdstrand> kyrofa: it isn't a framework though, is it? you just are picking it as type framework because that happens to get you something you need
<jdstrand> which I understand why you are doing that
<jdstrand> I'm just saying that all the use cases for ubuntu personal have not been defined
<elopio> Saviq: I only see the wrong identation on "build-in:"
<elopio> am I missing another?
<Saviq> elopio, that might've been it, checking
<kyrofa> jdstrand, yeah, it's really quite minimal, but apparently the only way to use dbus is to be a framework, that's all
<jdstrand> and so there aren't appropriate mechanisms for you to use
<kyrofa> kgunn, are you still around? ^^
<Saviq> elopio, - kernel: video* is 3 spaces in
<Saviq> and that seems to be it
<jdstrand> kyrofa: it might be that we want to allow bus-name in app types but trigger a manual review. I don't know (again, architects group (aka, tvoss))
 * jdstrand -> meeting
<kgunn> kyrofa: i am...
<elopio> mmm, ok, that one comes from the source. Will propose a change in there.
<elopio> and the built-in seems to be playing funny tricks with the editor.
<jdstrand> kyrofa: it might be worth noting that snaps aren't meant to replace debs in a 1 to 1 fashion. this is providing a service to a specific something. perhaps put all those somethings into one snap and make that a framework (still, need architect's direction)
<jdstrand> kyrofa: frameworks are strictly defined:
<davidcalle> Saviq, elopio, I've just imported the latest stable oem doc, don't touch the page :p
<Saviq> ;)
<davidcalle> Seriously :)
 * kgunn wonders why Saviq is here :)
<jdstrand> kyrofa: https://developer.ubuntu.com/en/snappy/guides/frameworks/
<Saviq> kgunn, Orange Matchbox ;)
<elopio> davidcalle: I'm not touching the oem page
<kgunn> ah
<jdstrand> kgunn: he's keeping me busy :P
<kgunn> fun
<Saviq> am monitoring my energy use!
 * jdstrand iskidding (happy to help)
<davidcalle> Note that we are working on auto-import for stable and edge snappy docs. In ~two weeks or so.
<Saviq> oops
<Saviq> jdstrand, but but but!
 * Saviq is filing bugs for you all!
<Saviq> bugsies
<Saviq> so many bugsies
<kyrofa> jdstrand, I gotcha. Yeah, I definitely don't need a framework... I guess I didn't expect dbus to be limited to frameworks is all
<kgunn> kyrofa: i wouldn't have expected that either...thanks for poking
<kyrofa> kgunn, so the scope is two pieces-- the scope itself and a little dbus daemon for maintaining state. The docs and jdstrand point out a dbus service is only supported for frameworks, which is way overkill for this
<jdstrand> kyrofa: well, a dbus service is a service to other apps
<kgunn> kyrofa: sure...
<kgunn> jdstrand: but in a generic case, "apps" using dbus are consuming that service no ?
<kgunn> at least, i'd have thot if you provide a service you have to be an app....
<kyrofa> kgunn, yes, but in that case they depend on the framework and have a capability inherited from the framework
<kgunn> dang it...i mean fmwk
<kgunn> kyrofa: so in turn "they" proxy dbus? in that case i do understand
<jdstrand> kgunn: apps may use a service if they security policy allows it. that policy is expressed via framework-policy
<jdstrand> kgunn: or via system supplied policy
<jdstrand> kgunn: right now on touch, we have a bunch of dbus services that are shipped as part of the image, and the image ships security policy that apps may specify to use it
<jdstrand> kgunn: but the services themselves aren't shipped as clicks
<kyrofa> jdstrand, so the only way to update them is OTA, yes?
<jdstrand> kgunn: it is the same on snappy. things that ship services to other apps either need to be in the image or shipped as framework snaps
<jdstrand> kyrofa: if on the image, yes. just like on touch
<jdstrand> kgunn: my understanding was that the ubuntu personal image was going to be a big image (compared to core) like it is now on touch, as opposed to a collection of snaps on top of core
<kgunn> jdstrand: yep, and no problem, i think kyrofa can continue down the "it's just in the image" road....
<jdstrand> kgunn: if the latter, then we really need to get the architects talking about things with the various stakeholders (core, security, etc)
<kgunn> i was just curious about the dbus use mandating a thing be a fmwk....
<kyrofa> kgunn, jdstrand indeed I can. debs are easy
<jdstrand> kgunn: well, it is because apps aren't supposed to be services to other apps
<jdstrand> kgunn: apps are isolated
<kgunn> got it
<jdstrand> kgunn: consider this-- if we did make it so that an app could ship a dbus service and that service could listen on the dbus, no other apps would be able to talk to it because there is no security from them to declare to talk to it
<jdstrand> s/no security from/no security policy for/
<kyrofa> jdstrand, except a binary shipped in the same snap, yes?
<jdstrand> yes
<jdstrand> you can always do that
<kyrofa> jdstrand, which is exactly what I need
<jdstrand> ok, well, you can setup a private dbus
<jdstrand> and not use the system one. it would be a private session bus
<kgunn> :P
<kgunn> please allow myself to talk to myself
<jdstrand> actually, that won't work just yet
<jdstrand> you would need the 'sockets' stuff that isn't implemented yet
<jdstrand> actually, perhaps just an abstract socket unix rule that is namespaced...
<jdstrand> I need to think about that
 * jdstrand makes note
<jdstrand> anyhoo, that isn't available today
<kyrofa> jdstrand, alright, not a big deal, getting it in the image is easy enough, just a little more work for seb
<jdstrand> kgunn: today, you can setup a writable named unix socket in the snap's writable area and have apps communicate over that
<jdstrand> but that is probably more work than just putting it on the image
<kyrofa> kgunn, do you think the long-term vision is having this as a snap, or leaving it in the image? If we want it as a snap eventually it sounds like we should start talking to people
<jdstrand> ok, meeting for real now
<kyrofa> jdstrand, :P
<kyrofa> jdstrand, thanks for all your time!
<jdstrand> np
<kgunn> kyrofa: honestly, it kinda feels like it'll always be in the image ? i mean at some point
<kgunn> we'll go all snaps all the time
<kgunn> and we'll always need a scope installed for the store
<kyrofa> kgunn, yeah, it's kinda integral
<kgunn> feels more like a nice to have
<kyrofa> kgunn, agreed
<kgunn> in terms of it being a snap
<kgunn> but thanks for trying
<kgunn> these are great attempts, we always learn a little more :)
<kyrofa> kgunn, definitely! Okay, I'll invest some time making sure I've got a good .deb coming out of the CI then instead
<kyrofa> kgunn, thanks for letting me drag you in! :)
<kgunn> kyrofa: thank you!
<Saviq> looking for +1s on bug #1472797, anyone?
<nothal> Bug #1472797: Should use bmap or a bmap-like solution to reduce flashing time <goget-ubuntu-touch (Ubuntu):New> <http://launchpad.net/bugs/1472797>
<ubottu> bug 1472797 in goget-ubuntu-touch (Ubuntu) "Should use bmap or a bmap-like solution to reduce flashing time" [Undecided,New] https://launchpad.net/bugs/1472797
<Saviq> ;)
<Saviq> hmm where do I file bugs against ubuntu-core?
<jdstrand> Saviq: the snappy project is prbably a fine first choice
<fjay> should /var/lib/apps/<pkgname>/current/
<fjay> exist?
<fjay> w/ the proper packagename obviously
<fjay> or has that approch been deprecated and the docs do not reflect that.
#snappy 2015-07-09
<elopio> https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472829
<ubottu> Ubuntu bug 1472829 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash fails to flash latest image: /tmp/diskimage890136169/assets/vmlinu?-*: no such file or directory" [Undecided,New]
<tsimonq2> balloons
<dholbach> good morning
<fgimenez> good morning
<davidcalle> Good morning o/
<mvo> hey fgimenez and davidcalle, good morning!
<ogra_> Saviq, err ... looking at bug 1472788 ... dont you need to pipe something into snappys stdin ?
<ubottu> bug 1472788 in Snappy "snappy config does not work from stdin" [Undecided,New] https://launchpad.net/bugs/1472788
<Saviq> ogra_, maybe, but shouldn't it just wait for me to type?
<Saviq> ogra_, sry, that's what "stdin" means to me ;)
<Saviq> didn't try piping, but that might very well be
<ogra_> note that i dont know if it works :) but thats what stdin means to me
<Saviq> ogra_, btw, I noticed uboot's env has a eth hwaddr set, should we (could we?) use that?
<ogra_> Saviq, http://paste.ubuntu.com/11846901/
<ogra_> (that was UTC before)
<Saviq> ogra_, was it not Europe/Berlin before? ;)
<Saviq> right
<Saviq> ogra_, maybe it's just a doc issue then, or maybe it's a PEBKAC on my side
<ogra_> for what do you want to use hwaddr ?
<Saviq> ogra_, to set eth0 MAC
<ogra_> why do you want to set it ?
<ogra_> (instead f using the one the device has imprinted)
<Saviq> ok well, the latter would be fine for me, too
<Saviq> just noticed it there
<Saviq> wasn't sure if it was imprinted elsewhere
<ogra_> yeah, i have a fix for that pending ...
<ogra_> the MAC comes from the blob (who is the only one able to actually read it from the board) ... i have code here that hands it over to uboot
<ogra_> next image will have that
<Saviq> ok coolz
<JamesTait> Good morning all; happy Sugar Cookie Day! ð
<Chipaca> Saviq: âsnappy config ubuntu-core -- -â works
<Saviq> Chipaca, that waits for you to type? looks undocumented then :)
<Chipaca> Saviq: yes
<Chipaca> ogra_: you around?
<ogra_> yes, but i try to get thinner
<ogra_> (bad joke, i know)
<Chipaca> http://instantrimshot.com/
<Chipaca> ogra_: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472829
<ogra_> :)
<ubottu> Ubuntu bug 1472829 in livecd-rootfs (Ubuntu) "ubuntu-device-flash fails to flash latest image: /tmp/diskimage890136169/assets/vmlinu?-*: no such file or directory" [Undecided,New]
<ogra_> Chipaca, that should be fixed already
<Chipaca> oooh
<Chipaca> ogra_: already where/how?
<Chipaca> i'm getting that bug right now, 's blocking me
<ogra_> hmm, vivid ?
<Chipaca> me? wily
<ogra_> ah
<ogra_> weird
<Chipaca> weird werewolf works too
<Chipaca> ogra_: 2.329?
<ogra_> aha
<ogra_> there was a quoting error in sergiusens MP ... i thought i fixed all occurences ... seems there is another one
<Chipaca> sure, blame sergiusens today that he's not here :)
<ogra_> he uses globbing in variable content ... but later quotes the vars when using them ... the quoting suppresses the globbing
<ogra_> http://paste.ubuntu.com/11847452/
<Chipaca> lel
<ogra_> uploaded
<ogra_> i'll trigger a new build once everything migrated
<Chipaca> ogra_: thanks. any idea how long that'll take?
<ogra_> the publisher can take 30min ...
<ogra_> plus build time then
<ogra_> (image build time that is)
<ogra_> 1h or so i guess ... or a bit more
 * Chipaca thinks of the xkcd comic about compiling
<lool> ogra_: ext2 is fragile in the face of abrupt power loss; fat32 is usually already there because a lot of SoCs will read the SPL from the first bootable fat partition or similar
<ogra_> lool, well, i have the unfounded feeling that vfat causes many of our issues ...
<lool> ogra_: in general, we dont particularly insist on the latest u-boot, we just need specific features to be supported and turned on, such as HUSH (more advanced commands than defaults), fat write support and such
<Chipaca> lool: surely fat32 is just as fragile wrt power loss as ext2?
<ogra_> right ... the fatwrite bit still scares me here ... hush support is years old
<Chipaca> maybe more so? i don't remember it having back up tables
<lool> Chipaca: fat32 does have backup table and simpler format; there is no recovery process in fat32 but usually the data is still there while with ext2, a typical fsck after an unclean shutdown will result in missing or empty files
<lool> u-boot doesn't support any kind of journal like ext3 or ext4
<ogra_> well, and you usually dont need it
<lool> so it becomes a critical moment to write to the ext2 fs, while fat32 is less so IMO
<ogra_> though usually people also dont write files from uboot to the fat
<lool> but then again I dont even if u-boot has write support for ext2
<lool> ogra_: we do, we write the stamp file
<ogra_> lool, people :) ... i know what *we* do ;)
<lool> but frankly we're discussing two equally half good options
<ogra_> and it scares me that we every now and then seem to end up with file or filesystem corruption ... even though we already try to do everything to avoid that
<davmor2> ogra_: yes we break stuff right?
<ogra_> Chipaca, building ... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image
<Chipaca> ogra_: wee :)
<ogra_> Chipaca, and ready ... looking at the log it should be fine now ... let me know if it isnt
<Chipaca> ogra_: now i'm back to getting the double map panic
<ogra_> Chipaca, well, thats a udf thing i fear
<ogra_> the hardware.yaml should at least be fine now
<seb128> ogra_, snappy upgrade still fails to boot the new partition with today image, was the fix supposed to be in the new image?
<seb128> or does it require to have some new bits in the snappy install from the system-a disk?
<ogra_> seb128, it was supposed in the image from ~30min ago
<ogra_> +to be
<ogra_> the one before had an issue
<seb128> why?
<ogra_> because there was wrong quoting in the MP
<seb128> oh, there was another quoting bug
<ogra_> right
<seb128> yeah, I saw your fix
<seb128> but that was yesterday
<seb128> I didn't see there was another round
<ogra_> there was an upload today too
<seb128> need to rekick personal as well
<seb128> or did you do that?
<ogra_> no, but you dont have the code yet
<ogra_> sergiusens said "after we confirmed it works" ... which we havent yet
<ogra_> and while this particular issue is fixed nopw, there seems to be something else still
<seb128> shrug
<ogra_> see Chipaca above
<seb128> k
<seb128> I'm unsure it makes sense to "test on core before doing the change on personal"
<seb128> imho having it on both allows to stay in sync and do extra testing
<seb128> but oh well
<ogra_> do you prefer having both broken instead ?
<seb128> personal is currently buggy anyway
<seb128> upgrade boots to a systemd recovery
<ogra_> ok, confirmed, hardware.yaml and the assets dir match now
 * ogra_ closes the bug 
<ogra_> Chipaca, looks all fine here http://paste.ubuntu.com/11848094/
<Chipaca> yeah, this thing is weird and intermittent (but right now i'm stuck with it)
<ogra_> ah, heh, but i end up at a grub prompt
<ogra_> i assume grub also needs to learn about versioned kernel and initrd now
<ogra_> hmm, how do i debug that
<Chipaca> ogra_: um
<Chipaca> ogra_: wait 3 seconds?
<kyrofa> seb128, yesterday after your EOD we discovered that the snappy scope doesn't really fit into the the snap packaging architecture so well... so we've gone back to making it a .deb
<ogra_> Chipaca, and then ?
<seb128> kyrofa, ok, just curious but what's the issue with snaps?
<kyrofa> seb128, do you anticipate having it set up in the CI somehow so I can land packages in there through the train?
<seb128> was it discussed on this channel?
<seb128> (just to know if I should read the irclog)
<Chipaca> ogra_: and then it just boots
<seb128> kyrofa, yeah, having it in CI would be nice
<ogra_> Chipaca, "grub>_" .... thats all i get here
<kyrofa> seb128, indeed it was-- look for the last mention of my nick yesterday
<kyrofa> seb128, but I can give you a quick overview
<ogra_> blinking cursor
<seb128> kyrofa, thanks, but I'm going to read the log first and I might ping you for extra details then ;-)
<kyrofa> seb128, sounds good
<kyrofa> seb128, so the scope is already in CI, it's jut not going through the train (just autolanding)
<ogra_> Chipaca, that doesnt look like udf creates a proper grub.cfg http://paste.ubuntu.com/11848214/
 * ogra_ sees no entries at all for any kernel/initrd
<Chipaca> ogra_: it worked here :-/
<Chipaca> ogra_: that's not grub.cfg
<ogra_> Chipaca, you mean with the current image ?
<ogra_> ogra@anubis:~/datengrab/kvm$ pastebinit /mnt/EFI/ubuntu/grub/grub.cfg
<ogra_> http://paste.ubuntu.com/11848214/
<Chipaca> i mean i used udf just now and finally got a wily rolling thing working
<ogra_> thats grub.cfg :)
<ogra_> weird
 * ogra_ re-runs udf
<Chipaca> ogra_: http://pastebin.ubuntu.com/11848223/
<ogra_> yeah, definitely not whats in my image
<ogra_> ogra@anubis:~/datengrab/kvm$ ubuntu-device-flash --version
<ogra_> unknown flag `version'
<ogra_> oh ... come on !
<mvo> ogra_: heh, patches welcome!
 * ogra_ has 0.25-0ubuntu1
<Chipaca> ogra_: 0.26
<Chipaca> 0ubuntu1wtfbbqftw
<ogra_> bah, so someone didnt update the trusty version in the PPA
<Chipaca> ogra_: you're using software so old it's starting to red-shift
<ogra_> i'm using supported SW on my production systems :P
<ogra_> wow
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
<ogra_> the PPA is even at 0.23
<Chipaca> niiice
<Chipaca> let's blame rsalveti
<ogra_> yeah
<Chipaca> at least he's here today
 * ogra_ blames
<rsalveti> we only update tools when we do a release
<rsalveti> so once we release the stable update we'll migrate thhe packages from tools-proposed
<rsalveti> what is happening? :-)
<rsalveti> more breakages from sergiusens ?
 * rsalveti reads backlog
<ogra_> rsalveti, cant build amd64 kvm images on trusty anymore
<ogra_> yay ... works with 0.26
<ogra_> hmm, doesnt find webdm
<ogra_> aha, doesnt bring up the interface ... fun
<ogra_> even though there is a /e/n/interfaces.d file for it
<ogra_> hmm, installing mir just spits out an error
<kyrofa> ogra_, I'm so glad I'm not the only one using trusty :P
<rsalveti> ogra_: what is the issue you're having?
<rsalveti> ogra_: and would assume only rolling
<ogra_> rsalveti, there was another quoting issue in the MP ... i fixed that ... and just tried to test the new image
<rsalveti> or you can't even with 15.04?
<ogra_> that was rolling ...
<ogra_> with 0.25 i ended up at a grub prompt
<ogra_> 0.26 is fine now
<ogra_> (udf that is)
<rsalveti> right, cool
<rsalveti> we'll migrate the new packages to tools tomorrow
<rsalveti> if all goes well
<ogra_> good
<rsalveti> ogra_: elopio: fgimenez: and how is 15.04 looking?
<ogra_> i didnt really spend much time with it yet due to the other issue with rolling (and failing images etc)
<ogra_> but i havent heard anything beyond what we knew yesterday
<rsalveti> ogra_: you said there was the duplicated initrd and kernel, right?
<rsalveti> or is that only with rolling?
 * rsalveti looks
<ogra_> no, that was 15.04
<ogra_> armhf
<rsalveti> ogra_: right, so guess that's something we still need to fix
<ogra_> i'm not sure what to do though ... i dont want to break the image the last minute just to save some space
<rsalveti> right, not critical but good to have
<ogra_> yeah ...
<rsalveti> guess we just need to properly validate the update from the sunday's image to the latest
<rsalveti> and make sure the new kernel is indeed in place
<rsalveti> fgimenez: can you take a look at that one?
<rsalveti> oh, and that needs o happen on a bbb
 * ogra_ goes to have some afternoon brunch 
<fgimenez> rsalveti, ok i'll take a look
<fgimenez> rsalveti, it would be 111 to 121, right?
<rsalveti> fgimenez: hm, don't know the number exactly, but would guess so
<rsalveti> just check the kernel version
<fgimenez> rsalveti, ok
<rsalveti> ogra_: care to review https://code.launchpad.net/~sergiusens/livecd-rootfs/eth0Not/+merge/263812 ?
<ogra_> rsalveti, looks fine, want me to merge it ?
<rsalveti> ogra_: if you can do the landing dance would be nice :-)
<ogra_> sure
<seb128> rsalveti, ogra_, was there any reason you didn't apply that change to personal as well?
<mvo> seb128: *code duplication *mumble* *hrmf* *code duplication*
<mvo> ;)
<seb128> mvo, patches are welcome ;-)
<ogra_> seb128, only that i wanted to do a "personal" sync later today that also includes the versioned kernel stuff etc
<seb128> ogra_, k, good ;-)
<seb128> I can do that if you want
<ogra_> mvo, teach live-build about smylinks for build hooks :P
 * mvo nods
<ogra_> seb128, yeah, if you feel like ... i have a meeting now and would earliest do it in 1h
<seb128> ogra_, k, can do
<ogra_> thanks !
<seb128> yw!
<Chipaca> seb128: you around?
<seb128> Chipaca, yes
<Chipaca> seb128: you're running personal in kvm and getting past the login, yes?
<seb128> Chipaca, no, I'm using virt-manager
<seb128> but I guess kvm should be the same
<seb128> need to use qxl video and spice
<Chipaca> seb128: so you're not on wily?
<seb128> I'm on wily
<Chipaca> how does virt-manager work for you on wily?
<Chipaca> it completely fails to work here
<Chipaca> seb128: to me, i tell it to use an image, it chowns it to root, and then tries to read it as me
<Chipaca> s/read/use/
<seb128> Chipaca, wfm
<seb128> I didn't do anything
<Chipaca> seb128: can you walk me through what you did?\
<seb128> Chipaca,
<seb128> - start virt-manager
<seb128> - click on the first icon in the toolbar
<rsalveti> mvo: if you got some time left https://code.launchpad.net/~snappy-dev/snapcraft/core/+activereviews
<seb128> - select the first option (iso or CD)
<rsalveti> otherwise will try to get to it later today as well
<seb128> - next
<seb128> - select the snappy image
<seb128> - select os type ubuntu
<seb128> - next, next, done
<seb128> in the preferences select qxn/spice as described on http://unity.ubuntu.com/mir/setup_kvm_for_mir.html
<seb128> Chipaca, ^
<seb128> or I'm using qcow images, unsure if that makes a difference
<seb128> qemu-img convert -O qcow2 wily.img new.img
<Chipaca> seb128: i get âCould not open '/var/tmp/personal_copy.img': Permission denied
<Chipaca> 'â
<Chipaca> where that img is the snappy file
<seb128> Chipaca, are other users allowed to read that location?
<Chipaca> seb128: "others"?
<Chipaca> seb128: o
<Chipaca> seb128: i've made it 0666
<Chipaca> seb128: same error
<Chipaca> it chowns it
<seb128> Chipaca, I think the vm uses its own user
<Chipaca> to libvirt-qemu:kvm if used as cdrom, to root:root if used as raw image
<Chipaca> and then gets permission denied
<seb128> is your user in the libvirtd group?
<Chipaca> yes
<seb128> k, I don' tknow then, sorry
<Chipaca> maybe it's trying to do something silly and the sticky directory gives it an error it isn't expecting?
 * Chipaca tries
<Chipaca> that ... worked
<Chipaca> /o\
<seb128> so it was a permission issue?
<Chipaca> apparently?
<rsalveti> mterry: created https://trello.com/c/IK3aJj2d/170-documentation-for-snapcraft
<rsalveti> mterry: this is the one you want to get done soon as well, right? https://trello.com/c/i3C75NVD/152-be-able-to-create-snap-just-from-snapcraft-yaml
<mterry> rsalveti, yeah that too
<mterry> rsalveti, and local-plugin
<rsalveti> right
<ogra_> seb128, wow, awesome !
 * ogra_ just booted the last personal image 
<ogra_> now how do i get past the intro ? i cant swipe the launcher in it seems
<ogra_> Chipaca, sudo ubuntu-device-flash personal rolling --channel edge -o personal_x86.img --developer-mode
<ogra_> Chipaca, kvm -m 2048 -vga qxl personal_x86.img
<ogra_> that gets me going here
<seb128> ogra_, why can't you?
<ogra_> ah, i just tried to click on the wrong thing :P
<ogra_> now i got it out of the way
<seb128> good :-)
<ogra_> mir is still pretty laggy in this setup
<seb128> indeed it is
<seb128> but at least it loads
<ogra_> yup, looks very nice already
<ogra_> hmm, interesting, browser doesnt start from the dash ... only from the launcher
<fgimenez> leaving, nice evening everyone
<seb128> ogra_, it does from the launcher?
<seb128> ogra_, I though it was bug #1466012
<nothal> Bug #1466012: Browser crashes on launch on Unity8 Desktop <webbrowser-app (Ubuntu):New> <http://launchpad.net/bugs/1466012>
<ubottu> bug 1457458 in Oxide 1.8 "duplicate for #1466012 "No suitable EGL configs found" on desktop-next" [Medium,Triaged] https://launchpad.net/bugs/1457458
<ogra_> might be, i dont have a console currently ... just clicking around a bit
<ogra_> hmm, i havent set up networking it seems
<seb128> that should work out of the box
<seb128> it's annoying that you can't vt switch with mir
<seb128> but you can log out from the unity8 session, that goes back to lightdm, then you can go to a vt and do command line things
<ogra_> yeah, i could probably ssh, havent tried with any -redir options yet
<ogra_> i did build with --developer-mode
<seb128> well, no cloud-init, so no ssh key....
<ogra_> sigh .. the alt key doesnt work, now i have all windows with their top bar hidden behind the panel :P
<ogra_> no way to move them anymore
<seb128> how did you get them there?
<ogra_> just dragging them to the very top
<davidcalle> ogra_, if you happen to have a touch screen, tap three fingers on the window
<ogra_> davidcalle, none of my three monitors has touch on this machine :)
<davidcalle> ogra_, grab the bottom edge and reduce the size while holding shift
<ogra_> nope, only lets me scroll inside the window
<ogra_> cant resize windows
<davidcalle> You have weirds window, for me it brings down the top edge symmetrically :)
<ogra_> under unity8 personal ?
<davidcalle> ogra_, hah, no, Unity7
<ogra_> aaah !
<davidcalle> ogra_, but maybe mzanetti can do a quick fix for that and you can update :p
<davidcalle> [Critical] Alt key not working, need new Unity release
<mzanetti> INPROGRESS
<davidcalle> :)
<ogra_> damn, i cant log in to my U1 account to install apps
<seb128> well, that wouldn't work anyway
<seb128> we don't have click support on that image
<ogra_> details :P
<ogra_> hmm, is log out supposed to get me lightdm back ?
<ogra_> (it doesnt)
<ogra_> oh, interesting ... doin a snappy serch on cmdline gets me a lot of uninteresting stuff
<seb128> ogra_, logout works for me
<seb128> I get lightdm unity-greeter
<ogra_> strange, i didnt
<elopio> hello
<elopio> I'm sorry I'm late. No internet access this morning.
<rsalveti> elopio: hey :-)
<elopio> rsalveti: hi!
<rsalveti> elopio: do you mind if I move our sync two hours later today?
<elopio> rsalveti: not at all.
<rsalveti> got a doctor appointment in 30 mins
<rsalveti> great, thanks :-)
<conyoo> holly cow! snappy personal desktop!
<conyoo> gg
<conyoo> doesn't work for me :(
<conyoo> never mind.. it does work :D i'm stupid :(
<carif> mterry, https://github.com/mikix/deb2snap looks pretty formidable, is there a way to install emacs24 on 'ubuntu-core/15.04/stable' in a more direct way? 'snappy search emacs' doesn't find anything.
 * carif won't learn vi (yet)
<elopio> carif: if you make a snap for emacs24, I'll use it extensively :)
<carif> lol
 * carif knows barry has one somewhere
<carif> ... he's just holding out
<elopio> that's a nice example to highlight some of the subjects that are being discussed now.
<elopio> for example, I would like to extend the emacs snap you provide by adding my favorite modules.
<elopio> do I have to repackage the snap with the modules included, or will there be a way to extend install snap extensions?
<mterry> carif, hello!
<carif> dude!
<mterry> carif, no, deb2snap would probably be the most direct way currently
<carif> sudo snappy install emacs24  # or some variant?
<carif> mterry, ^^^   # lost like in olden days...
<mterry> carif, that would work if someone had made an emacs24 snap already
<mterry> carif, but if you want to make one, deb2snap is probably the fastest
<mterry> currently
<barry> carif: ha :)  i wish!
<carif> ok, are you available for consulting services ## ... as in olden days ...
<carif> as I make my way through the snappy tutorial (in a snappy fashion) do snaps "stack"? So suppose there was indeed an emacs24 snap and I installed it, where would it actually land?
<mterry> carif, heyo
<mterry> carif, got distracted
<mterry> carif, if there was an emacs24 snap, it would install into something like /apps/carif.emacs24/VERSION/ (assuming 'carif' was the account that uploaded it to the store)
<mterry> and there would be a symlink at /apps/carif.emacs24/current and a wrapper script installed at /apps/bin/carif.emacs24 that would launch the executable inside your snap
<carif> ah, so the installed stuff winds up in /apps/${app}/${version}/ and /apps/bin "points" to the right one ... you beat me to it
<carif> mterry, vg, who's user 'clickpkg' and what's /apps/${app}/${version}/ .click/info/${app}.manifest? Is click the old name for snap?
<mterry> carif, yeah, click is predecessor to snap
<mterry> carif, I thought we got rid of most references, but looks like we still have some  :)
<carif> mterry, vg, so the plan-o-record is to evenually use snappkg and .snap?  ## Captain Obvious returns
<mhall119> is there a way to tell my RPi2 my wifi credentials via USB like I could with the phone?
<mhall119> trying snappy on it for the first time
<mterry> carif, I don't know about that specifically -- it may be too much bother to rename those specific things at this point?  Not my area of expertise
<mhall119> asac: ^^ can you help me get started with snappy?
<asac> mhall119: unlikely, because thats a vertical specific logic i am quite sure ... but tell me how you do it with the phone
<mhall119> asac: phablet-network command could copy the data over (via adb I assume)
<mhall119> asac: could a custom overlay or snap, built locally on my laptop, be used to install that automagically onto the device?
<asac> mhall119: so core itself does not make a choice about what network mgmt stack you want to use. configuring wifi or network in general would depend on making such choice. what we include is wpasupplicant, but how to use that is up to you... or someone making a wifi mgmt framework.
<asac> mhall119: and yes, you could make a very basic network mgmt solution that just takes a config that you can set and brute force connects to the AP you configured
<asac> and snap that up :)
<asac> so far folks have done the networking code in their main snaps
<asac> mhall119: do you know how to use wpasupplicant raw?
<elopio> mhall119: what phablet-network does is to use adb to get into the phone, and then execute nmcli
<mhall119> asac: nope
<mhall119> so I dd'd the rp1 disk image to my SD card, and it appears to have booted my device, but I have no way of connecting to it via ssh or http
<mhall119> oh, no, wait, I have ssh now, but I had to connect it to ethernet *and* find the actual IP address from my router's admin
<asac> mhall119: yes, what i do is usually plug eth in my desktop
<asac> setup NM to share connection
<asac> mhall119: if you have webdm installed you can find it with webdm.local
<elopio> mhall119: yes, that's what I'm doing. You can also connect through serial.
<asac> or if you changed hostname its hostname.local
<asac> mhall119: i think our default images have that
<mhall119> I haven't changed hostname
<asac> so try ping webdm.local :)
<mhall119> and webdm.local didn't work
<asac> ogra_: no webdm on pi2 image?
<mhall119> it's there, but the domain resolution didn't work
<asac> feels like a problem with your router/network topology i guess then
<mhall119> could be, using the IP address works though
<asac> if you can pluyg eth in your desktop you can for sure do it
<mhall119> what port does webdm listen on?
<asac> mhall119: well, ssh should be up
<asac> on normal port
<mhall119> it is, I can ssh in
<asac> ssh webdm.local -lubuntu ?
<mhall119> what does that do?
<asac> ssh into the machine that claims the webdm.local name
<asac> which should be your pi2 if its on the same subnet etc.
<elopio> mhall119: webdm is port 4200
<mhall119> huh, that worked, but ssh ubuntu@webdm.local didn't
<asac> maybe took a while for the name to propagate
<mhall119> elopio: thanks!
<mhall119> alright, I have access to the store now
<mhall119> what fun things can I try?
<asac> mhall119: hello-world :)
<mhall119> already installed it, how do I use it?
<asac> mhall119: type hello<tab><tab> :)
<asac> and see what it has to offer
 * asac wonders if we added all the seccomp stuff needed for hello-world.shell
<asac> jdstrand: you remember
<asac> ?
<mhall119> there's a jdstrand fork of hello-world
<elopio> mhall119: chatroom.
<mhall119> asac: why do snaps install into /apps/ rather than /opt/${store}/${app}/ ?
<asac> mhall119: but also the offical one right?
<mhall119> asac: yes, I installed the official one
<asac> mhall119: next you could learn how to side load local snaps using the snappy-remote command ... wget http://people.canonical.com/~asac/tmp/hello-world_1.0.16_all.snap
<asac> and then use snappy-remove --url ssh://webdm.local install hel*snap
<asac> err
<asac> and then use snappy-remote --url ssh://webdm.local install hel*snap
<asac> mhall119: if you have that tell me what happens if you run hello-world.shell
<asac> that should drop you into a shell where you see the world exactly from an app perspective
<asac> e.g. a nice isolated place where you feel kinda trapped but maybe also secure :)
<mhall119> I don't have snappy-remote
<asac> install snappy-tools
<asac> thats your meta package for basic dev tools
<asac> from the official tools ppa
<mhall119> which ppa?
<asac> https://developer.ubuntu.com/en/snappy/
<asac> -> get started
<asac> right on top there :)
<mhall119> thanks
<ogra_> asac, indeed webdm on pi image
<jdstrand> asac: re hello-world.shell-- iirc it depended on the shell. one of them wanted to setuid or something and we don't allow that cause we don't a) have seccomp arg filtering yet and b) have a uid to change to
<asac> jdstrand: one of them, but not both, right?
<asac> so either busy works or dash
<asac> lets see
<jdstrand> yes
<asac> mhall119: if shell doesnt work let me know :)
<jdstrand> I can't remember which otoh
<asac> i wil give you a different variant that should work
<jdstrand> iirc, there were a couple of other syscalls, but I'm pretty sure I added those
<asac> right. lets see :)
<asac> .shell is cool for sure
<mhall119> asac: hello-world.sh exists with the store-installed version
<mhall119> but not hello-world.shell
<asac> mhall119: oh right ... i think its sh
<asac> hmm shouldnt
<asac> wait let me see if someone pushed something to bzr without telling me :)
<asac> mhall119: does it work?
<asac> e.g. do you end up in a shell or get a weird error>?
<jdstrand> $ hello-world.sh
<jdstrand> Launching a shell inside the default app confinement
<jdstrand> $
<jdstrand> it seems to work
<asac> jdstrand: env | grep SNAPPY :)
<jdstrand> ubuntu-core/15.04/edge r120 on amd64
<asac> should be good
<asac> or SNAP
 * asac not a hacker
<mhall119> asac: it works
<asac> cool. so use env to see what env is set
<asac> and try to write to dangaerious places like /home/ubuntu/evil.txt
<asac> echo "hallo" > /home/ubuntu/evil.txt
<asac> echo "hallo" > $HOME/good.txt
<asac> echo "hallo" > $TMPDIR/good.txt
<asac> echo "hallo" > /tmp/evil.txt
<asac> evil should bail
<asac> good should work i hope
<ogra_> mhall119, try chatroom ;) (needs chromium though but gives you in-house hangouts on webdm.local:6565 )
<asac> try echo "Hallo" > /dev/tty0
<asac> then ssh in from other terminal
<mhall119> $ echo "hello" > /tmp/bad.txt
<mhall119> $ ls /tmp
<mhall119> bad.txt
<asac> do snappy hw-assign /dev/tty0 hello-world
<asac> then you should be able to poke it
<asac> hmm
<asac> mhall119: sure you are in the shell?
<asac> env | grep SNAP
<asac> if that thing has no hit you are not there
<mhall119> asac: yup, when I exit the shell I don't see bad.txt in /tmp/
<asac> run hello-world.sh again
<asac> interesting
<ogra_> yes, snaps have their own tmpdir
<asac> oh maybe we do more magic with containers and tmp now
<jdstrand> the /tmp handling changed
<asac> because too many apps are hard coding /tmp path
<jdstrand> right
<asac> so guess try the /home/ubuntu one
<asac> and the tty0 one
<asac> hehe
<jdstrand> /tmp/ok is now allowed within the app's process
<mhall119> so /tmp/ and ~/ are both okay to use by snap apps, but they don't point to unsafe places
<jdstrand> but that ends up in /tmp/somewhere/ok
<jdstrand> where 'somewhere' is something I can't recall otoh
<asac> not sure if we did same for home
<asac> but would assume yes :)
<asac> didnt know we did that for /tmp tbh
<jdstrand> that happened after 15.04 was released
<mhall119> ok, this is pretty cool, now I need to make a snap app
<asac> jdstrand: do we still set the TMPDIR etc. ?
<asac> i hope not :)
<asac> mhall119: sure the limit is the sky
<jdstrand> $ env|grep TMP
<jdstrand> TMPDIR=/tmp
<jdstrand> SNAP_APP_TMPDIR=/tmp
<jdstrand> SNAPP_APP_TMPDIR=/tmp
<asac> just include everyting you need in your snap
<jdstrand> $ env|grep HOME
<jdstrand> HOME=/home/ubuntu/apps/hello-world.canonical/1.0.18
<mhall119> what's the difference between SNAP_ and SNAPP_ ?
<jdstrand> we are not bind mounting HOME
<asac> mhall119: branch these to learn: https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples
<asac> jdstrand: legacy and new
<asac> err
<asac> mhall119: ^^
<asac> we had SNAPP in the beginning, but changed our mind and kept the old one because we had apps that used it
<mhall119> legacy? how do we have legacy stuff already?
<asac> use SNAP_
<ogra_> snappy is ancinet already :)
<ogra_> *ancient
<asac> mhall119: well, remember that we have big industry player adoptions that did snaps
<asac> most snaps are just not in the store :P
<asac> but almost all big companies have snaps already :D
<jdstrand> $ sudo find /tmp -name ok
<jdstrand> /tmp/snap.1000_hello-world.canonical_zYPh54/tmp/ok
<asac> those guys hate it if they go to a roadshow and their awesome app is broken :)
<mhall119> asac: why aren't they in the store?
<jdstrand> fyi, I noticed the /tmp handling is a little weird: https://bugs.launchpad.net/snappy/+bug/1473218
<ubottu> Ubuntu bug 1473218 in Snappy "TMPDIRs are not cleaned out/are not correctly preserved across app invocations" [Undecided,New]
<asac> mhall119: think about it :) i am sure you can come up with the right answers
<ogra_> mhall119, dont listen to him, dont waste time to think about it, just produce snaps !
<ogra_> ;)
<asac> lol
<mhall119> heh
<mhall119> ok, now what's the easiest way to convert a source deb to a snap?
<asac> mhall119: source deb? why not a binary deb :)?
<ogra_> there is deb2snap .... and yeah, you want binaries ... no need to compile stuff :)
<asac> we have the awesome innovation by mterry called deb2snap
<asac> which works for many cases
<mhall119> asac: can I run deb2snap on an armhf deb from my i386 laptop?
<mterry> mhall119, err...  not really.  maybe you can multiarch stuff by specifying libfoo:armhf
<mterry> mhall119, but in general, it's just meant to grab what's on  your machine
<asac> hey, i am the guy most detached from reality :P ... lets try to find out
<asac> https://launchpad.net/deb2snap
<asac> is what google tells me might be one place
<asac> found http://bazaar.launchpad.net/~mterry/deb2snap/trunk/view/head:/README.md
<asac> mterry: if you hate all those nasty cross arch dev challenges you could try to be smart and install docker on your pi2
<asac> snappy install docker
 * ogra_ needs to do a writeup how to use deb2snap in an armhf chroot then ;) 
<asac> and then use some magic cli to get a ubuntu env
<mhall119> hmmm, doesn't look like an armhf binary exists for irssi :(
<asac> lol
<asac> mhall119: bip maybe?
<asac> bip would be cool to have
<mhall119> what is bip?
<ogra_> mhall119, there is definitely an irssi binary
<jdstrand> mterry: btw, did you see this: https://docs.google.com/document/d/1fkCj_ShgNw0gPqZR7lkTUaMavuj1MEUfBGx8LSgAT-s/edit (see 3rd point, 'denial on lchown'
<asac> i was too ambitious trying to solve all problems at once so i am stuck at a stage that i have no time to solve :)
<asac> mhall119: bip is an irc proxy
<ogra_> i know popey used it on his N4 a while ago :)
<asac> that you can then connect to
<asac> so your pi2 up could  keep you always on and you can connect from whever you want
<asac> i run it in the cloud right now
<asac> buut would love to move that thing to my snappy cloud server
<ogra_> +1
<ogra_> same here
<mterry> jdstrand, yeah but I've been busy on snapcraft, haven't spent any time  on deb2snap
<mhall119> asac: does bip support connecting to multiple networks?
<asac> of course
<asac> i am on 4
<asac> if you connect you get all the backlogs and pings
<asac> you get logs
<asac> everything you want
<asac> its slightly buggy
<jdstrand> mterry: sure, it was more just an fyi
<mhall119> hmm, nice, I'll take a look at that
<ogra_> yeah, it really nicely replays the night for you :)
<asac> some folks prefer something more modern
<jdstrand> mterry: where does deb2snap live?
<asac> mhall119: it even remembers the channels you were in ... and gives them back to you next time you start your irssi or xchat or phone irc client
<mterry> jdstrand, github.com/mikix/deb2snap or lp:deb2snap
<asac> mhall119: your problem is that there is no multiarch package avail for irssi i am sure...
<asac> if you go the docker route above it should be there
<asac> mhall119: kickinz1 can tell you how to get a trusty/wily etc. docker env ... its just one command that i dont remember :(
<ogra_> you could just install docker and afterwards owncloud ... and then check the processlist ;)
<asac> to figure how to start a docker with trusty?
<asac> odd way :)
<ogra_> ah , i thought yu wanted to run a docker on the pi
<asac> no i wnt to tell mhall how to use docker to get a chroot on pi2 so he can use deb2snap for armhf irssi :)
<mhall119> man, I just want to install something I use on my server onto snappy, not learn how to use docker
<ogra_> lol
<asac> mhall119: its pretty easy i think
<asac> mhall119: https://docs.google.com/document/d/1cPX-yvZWMgshcnBeu2-mroZXnQEEK3jXJbtQqb09LiM/edit
<asac> just read first paragraph
<asac> two commands :)
<asac> and tomorrow hunt down kickinz1 and ask him if there is official place where we have this documented...
<asac> and then go to lool and ask him when we get comfy :P
<asac> lol
<mhall119> will snappy always require sudo?
<asac> not if you are root :P
<ogra_> for admin tasks ? ... sure
<asac> hard to predict the future
<mhall119> so it won't be like click then, where non-admin users can install things?
<mhall119> that was a nice thing about the phone
<asac> for now we are not rethinking it at least
<asac> mhall119: we dont have per-user packages anymore
<mhall119> what?
<mhall119> why not?
<asac> mhall119: why do you think are they needed?
<mhall119> so that users could install what they wanted when they wanted
<mhall119> without needing admin rights
<ogra_> click needs admin rights as well
<ogra_> it just shields that from you via packagekit ...
<mhall119> ogra_: but it doesn't require sudo to install click packages
<mhall119> right, which is nice
<ogra_> it wouldnt require sudo to use snappy install either if you hook it into policykit like packagekit does
<ogra_> thats a tech detail really
<ogra_> they are not different ... click needs admin permission the same way snappy needs them ... (it installls clicks in /opt ... )
<mhall119> asac: docker command failed: FATA[0113] Error response from daemon: Cannot start container 7d047b0b0d7891f51846dfdb07ac3583d402522a53583be60b774085faddcc30: [8] System error: exec format error
<mhall119> ogra_: right, but the user triggering the install didn't need to be given admin rights
<mhall119> that was what was nice
<mhall119> it means I could let my kids install apps without giving them sudo access
<mhall119> and having per-user apps meant that they could upgrade apps that I use, without me getting upgraded too
<ogra_> mhall119, thats a 30min job of putting policykit configs in place to make the same thing work with snappy or apt
<ogra_> this has nothing to do with click, really
<mhall119> ogra_: got 30 minutes? :)
<ogra_> it is like having click hardcoded in /etc/sudoers with nopasswd
<mhall119> ok, that's fine, I hope somebody does that work at some point
<ogra_> and it only works on the phone because we have a single hardcoded user
<mhall119> though without per-user apps, it's probably not a good idea
<ogra_> webdm didnt ask you for a password, did it ?
<ogra_> :)
<mhall119> ogra_: to do what?
<ogra_> the snap scope doesnt either :)
<ogra_> to install anything
<mhall119> ogra_: it prompted me to use sudo
<ogra_> webdm ?
<mhall119> snappy did
<ogra_> surely not
<mhall119> I didn't install anything through webdm yet
<ogra_> thats why i said webdm and the snap scope :)
<ogra_> ah
<mhall119> yeah, webdm doesn't prompt me to, okay
<ogra_> it is all a matter of configuration ;)
<mhall119> ok, so now I need to get docker running, anybody know what's causing the failure I pasted above?
<ogra_> all contact i had with docker yet was in webdm ... when installing it (and owncloud)
<mhall119> installing docker ran fine, but running an instance fails
<asac> mhall119: its because the name is different
<asac> mhall119: try docker search armhf maybe
<asac> kirkland: you know the CLI to run the armhf docker instance?
<asac> mhall119: use -t armbuild/ubuntu:trusty
<asac> instead of '-t ubuntu:trusty'.
<asac> seems jdstrand is the expert :)
<asac> he answered that on ML
<asac> :)
<mhall119> asac: thanks, that got it working
<mhall119> jdstrand: ^^ thanks to you too
<mhall119_snappy> woot! woot!
<ogra_> hey hey
<mhall119> so irssi works inside of docker
<asac> mhall119: guess directly from docker or did deb2snap just work awesome?
<asac> heh
<mhall119> I just ran apt-get install irssi inside of docker
<asac> so dont ask me how you can even preserve that state
<asac> lol
 * asac is super clueless about docker
<asac> run to lool and ask him where comfy is :)
<mhall119> asac: that's okay, "learn docker" should never be our response to somebody wanting to build a snap package
<asac> its not
<asac> just for those that dont know how to do things if they dont find the old world on their machine :)
<asac> until we have the old world nicely done on snappy
<asac> which comfy is about
<asac> mhall119: makng snaps is super trivial. just put everything you need in a directory tree, add a description, name, logo and in meta/package.yaml and run snappy build :)
<asac> mhall119: anyway, we are working on embracing those that have forgotten how to put everything together because they are used to the ease they get everything needed in ubuntu :P. wont take long i really hope
<jdstrand> mhall119: heh, yw
<jdstrand> I am hardly the expert though :)
<asac> mhall119: on app per user ... we couldnt really find that this is a primitive we will want forever in our platform. we identified enough things that world thinks this solves that actually dont need this feature that we decided to not do it for now. actually - without recalling all that - the only reason that was not possible in other ways was the "user X wants to have different version thatn user Y of same app"
<asac> that you funnily enough mentioned
<asac> mhall119: the key thing to remember that snappy core is not a platform, its a platform for building platforms; so whatever things we pick and do here, it could limit the potential of innovation in our ecosystem, so unless its clear that this is the way that the problem we solve everyone will want or if not everyone at least we are sure it will not block others to solve their problem, we rather do less :)
<asac> err hard to pars :P
<asac> late here
<asac> but i guess you get the point
<kirkland> asac: yeah, you got it :-)
#snappy 2015-07-10
<carif> almost there with my first simple snap, an "echo" shell script. The script isn't executable in the snap, but is in the "source" directory. is that what 'caps: []' does?
<dholbach> good morning
<fgimenez> good morning
<biezpal> Hi guys, can anyone help us with libs in .snapp package? Where we should place our libs in snapp package to make it visible for app?
<ogra_> anywhere you want ... just make sure to point LD_LIBRARY_PATH to it and export it
<biezpal> and how we can set the variable for all users?
<biezpal> now we are doing it manually
<ogra_> you usually set it in your wrapper script for the binary or service
<biezpal> alaik, automatically generated wrapper script is stored in /apps/bin/<appname>, but we cannot customize it during snapp installation. Am I right?
<biezpal> Or we should create our own wrapper script which will be executed by automatically generated wrapper script?
<ogra_> yes
<ogra_> (the latter)
<ogra_> seb128, hmm, did you ever try snappy update on personal ?
 * ogra_ gets out of space errors for /system-boot
<biezpal> thanks
<seb128> ogra_, yes, remember me reporting those kernel mismatch error some days ago :p
<seb128> ogra_, let me try with today's image
<ogra_> i guess u-d-f needs to learn to assign a bigger /boot
<ogra_> well, my update actually failed, i didnt get to a point where i could even boot into the update
<seb128> it was working for me yesterday
<seb128> well "working"
<seb128> the updated system failed to load modules and booted in debug mode
<ogra_> right, i remember
<seb128> but it's weird, /boot shouldn't be bigger on personal than core, should it?
<seb128> we use the same kernel
<ogra_> the initrd might be
<ogra_> hah ... booting with "kvm -m 384 -vga qxl personal_x86.img" works !
<ogra_> -m 256 sadly doesnt anymore :(
<seb128> so I've a "snappy update --automatic-reboot" process
<seb128> is there any way to query it for status?
<ogra_> not sure, sergiusens would know i guess ... or mvo
<seb128> mvo is hidding again!
<ogra_> hmm, i take back the above ... 384MB boots ... but i cant log in
<seb128> stop asking for more
<ogra_> (512M works fine though)
<seb128> ogra_, I'm getting that "no space left on device" as well now
<ogra_> i think we duplicate kernl and initrd now ...
<ogra_> with and withoout version in the name ...
<ogra_> hmm, no, a and b only have a single copy each
<biezpal> ogra_, is there are plans to add something like "LD_LIBRARY_PATH" parameter into meta/package.yml ?
<ogra_> no, i dont think so ... but we might add a standard path that the launcher defaults to ... (we use <appinstalldir>/lib/<arch> in click packages for example ... ) so you have a place that always works with extra variable hackery
<ogra_> s/with/without/
<biezpal> ogra_, cool, thx
<pitti> sorry, I forgot: what do I have to downgrade in wily again to make ubuntu-device-flash work?
<seb128> ogra_, ubuntu-core is having the same upgrade /boot size issue
<ogra_> yeah, i would have expected so
<pitti> ("panic: cannot double map partitions')
<pitti> (we've had this for weeks, is it so hard to fix?)
<ogra_> pitti, i think you should just retry ... iirc Chipaca had the same issue yesterday and it just worked at some point
<ogra_> IIRC
<pitti> I remember fgimenez downgraded something and then it worked
<seb128> pitti, nothing to "downgrade" afaik, I'm using wily standard and not having issues
<pitti> some *mutter* *mutter* go incompatibility
<pitti> http://paste.ubuntu.com/11854764/
<Chipaca> pitti: yes, that's the error we're talking about
<pitti> and --channel=alpha with rolling doesn't work at all ("Failed to locate latest image information")
<seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 has a mr ready for review, you might want to give the fix a try?
<ubottu> Ubuntu bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,New]
<pitti> seb128: ah, thanks for the bug pointer!
<seb128> yw!
<Chipaca> pitti: AIUI even though the error isn't handled (hence the panic), it is "real" and coming from a race in partx or sth like that
<Chipaca> and AIUI the fix to the error is to print it prettier
<fgimenez> pitti, yep, it's already reported, as ogra_ mentioned retrying helps
<pitti> ah, it seems the 7th retry worked
<seb128> ogra_, so, who need to be nagged about "snappy upgrade" being busted because /boot is too small now?
<ogra_> seb128, well, i see we only assign 63M in total for that partition ... u-d-f defines the partition sizes i think
<ogra_> a) we need to get back to normal size again ... b) we should assign more space by default anyway
<pitti> do I need anything else to enable ssh? sshd is running inside, but trying to ssh in just hangs
<pitti> (I ran with --developer-mode, which should include --enable-ssh)
<ogra_> it should even copy your key inside
<pitti> I see the open port in netstat too
<pitti> ah - eth0 is not up
<ogra_> how long did you wait ... creating the host keys takes a while (cloud-init is pretty slow)
<pitti> that would do it :)
<ogra_> ah
<ogra_> well, there is no eth0 anymore because someone changed the device names :P
<pitti> there is an eth0 in qemu, it's just not up :)
 * pitti runs sudo ifup eth0 for now
<ogra_> oh ... there should be an entry for it in /e/n/interfaces.d/ then
<ogra_> wonder why it isnt brought up now ...
<pitti> ogra_, Chipaca: thanks for your help! enough to test the updated autopkgtest snappy script
<ogra_> Chipaca, ^^ i guess we need to re-visit the NIC changes
 * Chipaca reads
<ogra_> (the configuration is created fine on boot apparently ... but the interface isnt brought up)
<Chipaca> very odd
<pitti> perhaps it's created too late?
<pitti> i. e. after /etc/init.d/networking already run, respectively after eth0 was already detected and thus ifup@eth0.service triggeerd?
<pitti> then these need to be restarted
<Chipaca> pitti: perhaps
<Chipaca> in which case we need to move firstboot way up :)
<pitti> Chipaca: note that allow-hotplug gets triggered via udev rules, so it'll run fairly early after udev trigger
<pitti> Chipaca: probably better to just restart ifup@ after you wrote the file
<Chipaca> pitti: but we can't restart a service from inside a service
<Chipaca> it deadlocks
<pitti> Chipaca: you can, with --no-block
<pitti> Chipaca: you can also do it more indirectly, with udevadm trigger --sysname-match=eth0
<pitti> (or whatever the interface name is)
<pitti> that pretends eth* was "re-hotplugged", and you don't need to know the precise mechanics how it's brought up
<JamesTait> Good morning all; happy Friday, and happy Donât Step On A Bee Day! ð
<ogra_> save the bees !!
<ogra_> (and the bumblebees too)
<seb128> ogra_, so, who is to nag about snappy update being busted?
<seb128> Chipaca? sergiusens? mvo?
<ogra_> seb128, sergiusens i think
<Chipaca> who shouldn't be here today
<Chipaca> as it's a national holiday for him
<ogra_> Chipaca, wasnt that yesterday ?
<Chipaca> ogra_: yes, but the president got bored or something
<ogra_> or did he take a bridge holiday
<ogra_> ah
<Chipaca> declared it a bridge
 * ogra_ gets ready for dentist ... back later ... 
<Chipaca> glad she chose that, as the other button was "declare war"
<sergiusens> ogra_: seb128 Chipaca I am here today, but I've been playing fix the image for a week now, time to pass it on to someone else in the team
<sergiusens> Chipaca: it's not a bridge
<Chipaca> sergiusens: my sources have lied to me!
 * Chipaca has them all go on reddit and bash kittens
<sergiusens> Chipaca: http://www.mininterior.gov.ar/tramitesyservicios/feriados.php
<sergiusens> Chipaca: or en.ar#holiday@group.v.calendar.google.com)
 * Chipaca tries to decide whether continuing to be wrong would be more o rless fun than being correct
<ogra_> sergiusens, well, i have no clue how the partitioning is done ... but 63M is definitely not enough for three kernels and three initrds on x86/amd64
 * ogra_ is happy to take over parts of the image indeed
<ogra_> >(but thats u-d-f which is a black hole for me)
<sergiusens> ogra_: 63M
<sergiusens> ogra_: supposed to be 512M
<sergiusens> ogra_: and I'm not sure what you are talking about
<ogra_> hmm, df shows 63
<sergiusens> ogra_: oh, right, blame lool
<sergiusens> ogra_: why are there 3 kernels?
<sergiusens> should only be 2
<ogra_> sergiusens, amd64 core and personal fail snppy update with an out of space error when copying the kernel to /boot
<ogra_> there is one in /boot from the rootfs still
<ogra_> (which we should get rid of, but didnt yet apparently)
<ogra_> so you have three kernels and initrds
<sergiusens> ogra_: /boot is part of system-a/b
<sergiusens> ogra_: /boot/u-boot, /boot/grub and /boot-efi are mounted for system-boot
<sergiusens> ogra_: and I thought my MP did get rid of the extra kernels fwiw
<ogra_> right, /boot/efi is 63M for me here
<sergiusens> ogra_: right, it is 64M (give or take for alignment), blame lool ;-)
<ogra_> i'm currentl ylooking at personbal ... might be that this doesnt have the MP yet
 * ogra_ blames lool in absence
<sergiusens> ogra_: well it's the one you merged ;-)
<ogra_> sergiusens, seb128 only merged it yesterday for personal
<sergiusens> ogra_: the first red in https://code.launchpad.net/~sergiusens/livecd-rootfs/snappyDevicePart/+merge/264158
<ogra_> since it had a bunch of issues i fixed in core first (quoting)
<sergiusens> ogra_: but that does not come into play for system-boot at all
<ogra_> right, only for /boot
 * davmor2 blames that ogra_ bloke bound to be his fault somewhere along the lines
<sergiusens> ogra_: yeah, your code review was terrible ;-) just proving how shell scripting can go ;-)
<seb128> ogra_, sergiusens, ubuntu-core has the same issue, I download core 98 and did a "snappy update" before lunch and it failed the same way
<ogra_> sergiusens, well, i fixed it at least :P
<sergiusens> seb128: it was 512M before and I was told to lower it to 64, I don't mind making it 512 again
<ogra_> yeah, lets do that again
<seb128> smaller is better
<ogra_> who knows what people come up with and add to their initrd on custom images :)
<seb128> ideally personal would fit on a 8G stick
<seb128> but otherwise I've no strong opinion
<ogra_> 8G ?
<ogra_> i would say 4 ;)
<seb128> the personal image doesn't fit on a 8Gb stick
<seb128> ogra_, even better
<sergiusens> seb128: btw, I did your s/ubuntu-core/ubuntu-personal/ thing, but this will play in negatively with the oem snaps, you might need to roll your own due to snappy config ubuntu-core
<seb128> but today it's 10Gb
<ogra_> (without libreoffice and thunderbird though :) )
<seb128> sergiusens, oh, ok
<seb128> ogra_, 4 is a bit short with system-a/b for a full desktop
<ogra_> seb128, currently the booted personal image uses 2.3G writable space ...
<seb128> why is our image take 10Gb then?
<ogra_> system-a|b dupplicates that
<ogra_> and you want some wiggle room
<seb128> right, but 2.3*2=4.6
<seb128> + boot = 64M atm
<seb128> + writable
<ogra_> right, 6 should be fine ... and i think we can slim it down a bit still
<seb128> we should be able to do e.g a 6G
<seb128> well, before sergiusens merged his changed with the 10G size, I tried to build with the size specified to 8 and it failed for some reason
<seb128> I never debugged by it wanted more that 8 though
<ogra_> anyway, i would at least go with 128M for /boot
<sergiusens> seb128: ogra_ I chose 10 just to get started, we can lower that as soon as you have the right package set stabilized a bit
<seb128> sergiusens, well, when you picked 10 I tried 8 locally because that's what I had as usb  stick, but it failed for some reason
<seb128> so it seemed it wanted > 8G
<seb128> ogra_, right
<ogra_> seb128, we were recently discussing making the writable part realyl tiny in the img and then just expand it to full disk on first boot
<sergiusens> seb128: yeah, the min required size is enforced so people don't have the disk full issue when creating images
<ogra_> that should make everyhting way more flexible
<ogra_> (and give you a way snaller image)
<sergiusens> seb128: https://code.launchpad.net/~sergiusens/snappy/rollYourOwnCorePersonal/+merge/264405
<seb128> sergiusens, should that maybe be discussed on the list? I think it is useful, would it only to let people know about the change
 * ogra_ grumbles about the anesthesia not wearing off today ... annoying
<sergiusens> Chipaca: did you get a chance to review the u-d-f MP?
<Chipaca> sergiusens: url?
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/unmapErr/+merge/264250
<Chipaca> yes, i had
<Chipaca> and now i told launchpad about it and all
<sergiusens> Chipaca: that makes things better :)
<rsalveti> sergiusens: is that just to help exposing the error or actually fixing it?
<rsalveti> ogra_: sergiusens: do we want to remove the duplicated kernel from stable still?
<rsalveti> sergiusens: moved the meeting to tuesday since we had conflicts on monday
<rsalveti> mterry: what do we need to change regarding tarmac to land the snapcraft branches?
<mterry> rsalveti, sergiusens: add ppa:hardware-certification/public to our tarmac machine
<ogra_> rsalveti, not sure, i wonder what the risk is
<ogra_> (the change would just be two rm's indeed)
<rsalveti> ogra_: if it's fine to not fix it now, it's also ok
<rsalveti> but would the kernel always be there after we fix and update?
<ogra_> it should be handled like a normal file by s-i
<ogra_> so if it goes away in the image it should go away on disk
<rsalveti> yeah
<rsalveti> fgimenez: any other issue with the image?
<rsalveti> fgimenez: https://bugs.launchpad.net/snappy/+bug/1473014 should be fixed with latest
<ubottu> Ubuntu bug 1473014 in Snappy "waagent related systemd-fstab-generator error" [High,Fix committed]
<rsalveti> hm, created latest kvm image, did control+c on qemu after it booted completely, trying to boot again but I can't login now
<rsalveti> and ssh is not giving me the login prompt either
<ogra_> lovely :/
<rsalveti> and boot took longer as well
<rsalveti> this is with 15.04/edge
<sergiusens> mterry: rsalveti k
<sergiusens> rsalveti: ogra_ it doesn't really matter to ship those kernels
<ogra_> sergiusens, rsalveti, hmm, though i wonder if elopio's second fake upgrade issue could be related to a full vfat on the BBB
<rsalveti> Jul 10 13:50:09 localhost login[656]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', User not known to the underlying authentication module
<rsalveti> user ubuntu unknown
<ogra_> ugh
<sergiusens> ogra_: rsalveti fwiw https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/biggerPartition/+merge/264421
<rsalveti> Jul 10 13:49:36 localhost systemd[1]: Failed to start Login Service.
<rsalveti> that is why
<ogra_> sergiusens, will that automatically adjust the other sizes ?
<ogra_> rsalveti, yeah, but why :P
<sergiusens> but that makes our 4GiB images look like 512MB(system-boot), 1Gib (system-a/b), 512MB (writable)
<rsalveti> ogra_: my boot log http://paste.ubuntu.com/11856027/
<sergiusens> ogra_: yes, it adapts everything else
<ogra_> sergiusens, 128M would suffice i guess
<sergiusens> ogra_: that's what people said about 64 ;-)
<rsalveti> 512 is a bit too much, isn't it?
<rsalveti> and why are we changing?
<rsalveti> sorry, no context
<sergiusens> ogra_: give me numbers!
<sergiusens> rsalveti: because ogra_ said so :-P
<ogra_> well, people were at least cleverer than bill gates then ... he said 640k is enough ;)
<sergiusens> rsalveti: ogra_ fwiw, 512 is the recommended size to hold grub stuff from cjwatson
<ogra_> rsalveti, rolling has an issue with upgrading on core and personal
<ogra_> rsalveti, fails with ENOSPC on /boot
<ogra_> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,808 - cc_growpart.py[DEBUG]: '/' FAILED: failed to resize: disk=/dev/sda, ptnum=3: Unexpected error while running command.
<ogra_> Jul 10 13:48:24 localhost cloud-init[605]: Command: ['growpart', '--dry-run', '/dev/sda', '3']
<ogra_> whats that ?
<ogra_> rsalveti, smells to me like we run cloud-init in some werd mode
<ogra_> *weird
<rsalveti> yeah, no idea
<rsalveti> Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service: main process exited, code=exited, status=1/FAILURE
<rsalveti> Jul 10 13:48:21 localhost systemd[1]: Failed to start Notify bootloader that boot was successful.
<rsalveti> Jul 10 13:48:21 localhost systemd[1]: Unit ubuntu-snappy.boot-ok.service entered failed state.
<rsalveti> Jul 10 13:48:21 localhost systemd[1]: ubuntu-snappy.boot-ok.service failed.
<rsalveti> wow, why?
<ogra_> you dont have any network device
<rsalveti> Jul 10 13:48:21 localhost snappy[554]: invalid package on system
<sergiusens> rsalveti: what system is this?
<rsalveti> sergiusens: 15.04/edge, created latest with kvm, booted, hit control+c, started again
<rsalveti> and now can't even login anymore
<sergiusens> rsalveti: invalid package on system means you have a package with a . in it when it's no supposed to
<rsalveti> this is just the base system + webdm
<rsalveti> didn't change anything, was my second boot
<sergiusens> rsalveti: created just now?
<rsalveti> sergiusens: yes
<sergiusens> rsalveti: no update happened?
<rsalveti> sergiusens: nops, was latest already
<sergiusens> rsalveti: command run so I can run
<ogra_> rsalveti, hmm, works fine here
<ogra_> sudo ubuntu-device-flash core --channel edge -o snappy_core_x86.img --developer-mode 15.04
<rsalveti> sudo ubuntu-device-flash core 15.04 --channel edge --oem generic-amd64 --install=webdm --enable-ssh --output ubuntu-15.04-snappy-amd64-generic.img
<ogra_> boots even in seconds
<rsalveti> got image 121
<sergiusens> rsalveti: fwiw, you don't need to specify  --oem generic-amd64 ;-)
<ogra_> yep, same here
<ogra_> (imagenumber)
<ogra_> let me try with installing webdm
<rsalveti> sergiusens: I know, this is because I was creating the released images, and wanted to be explicit in my script
<sergiusens> rsalveti: that's fine
<ogra_> rsalveti, with webdm boots fine too
<rsalveti> ogra_: right, it seems to be a fs corruption issue or something along that line
<rsalveti> can't reproduce every time
<fgimenez> rsalveti, no new issues on my side, the upgrade from 106 (kernel 3.19.0-21) to 122 (kernel 3.19.0-22) went fine on bbb http://paste.ubuntu.com/11855291/
<ogra_> i use the udf with personal enabled ... 0.26-0ubuntu1
<ogra_> do you use an older one ?
<fgimenez> rsalveti, i've been hitting the space problem on rolling http://paste.ubuntu.com/11855475/
<rsalveti> fgimenez: great
<rsalveti> right
<ogra_> aha, so it affects arm too
<sergiusens> rsalveti: works fine here too
<elopio> good morning
<fgimenez> hi elopio
<rsalveti> sergiusens: yup, as I said, I can't always reproduce it either
<rsalveti> https://bugs.launchpad.net/snappy/+bug/1473465
<ubottu> Ubuntu bug 1473465 in Snappy "kvm/generic-amd64: system got in a broken state in the second boot" [Undecided,New]
<ogra_> rsalveti, bah, seems it hit it as well now
<rsalveti> ogra_: \o/
<ogra_> rsalveti, bah, seems it hit it as well now
<ogra_> bah
<ogra_> EFOCUS
<rsalveti> hahah
<sergiusens> ogra_: rsalveti second boot? So if I reboot reboot reboot I eventually hit it?
<rsalveti> sergiusens: complete first boot then control + c on your kvm console
<rsalveti> then start it again
<ogra_> sergiusens, my first boot was fine ... not sure it was the second ... but now i cant get in at all anymore
<sergiusens> ogra_: rsalveti get in meaning log in?
<ogra_> yes
<sergiusens> ogra_: ssh or console?
<ogra_> login incorrect on all consoles
<ogra_> tty and serial in kvm
<sergiusens> meh, I've rebooted 10 times already
<ogra_> cloud-init suddenly seems to write a lot of files
<ogra_> i dont think i have seen that before
<sergiusens> ogra_: rsalveti mount the writable partition and run 'find [mountpath] -ls' and pastebin for me
<sergiusens> ogra_: rsalveti the growpart will surely break things I guess
<ogra_> yeah, i think we hit a stramge cloud-init mode
<ogra_> rsalveti, what was the dir you made writable ?
<rsalveti> ogra_: waagent
<rsalveti> but that is just for azure
<sergiusens> rsalveti: there is no waagent anymore
<rsalveti> /var/lib/waagent
<sergiusens> rsalveti: it's all in cloud-init now
<rsalveti> sergiusens: right, but it still uses that dir
<ogra_> ah, not /var/lib/cloud
<sergiusens> the logic
<ogra_> k
<rsalveti> that was for cloud-init
<rsalveti> sergiusens: http://paste.ubuntu.com/11856151/
<ogra_> sergiusens, http://paste.ubuntu.com/11856150/
<ogra_> hah ! i beat you by 1
<rsalveti> not here :P
<sergiusens> yeah, rsalveti's showed first here, but ogra ran it faster :-P
<rsalveti> I'm uploading the image as well
<rsalveti> that will take a few minutes
<sergiusens> ogra_: rsalveti now "find [mountpath] -name 'package.yaml' -exec cat {} \; "
<rsalveti> nothing
<rsalveti> guess the syntax is wrong
<ogra_> same
<sergiusens> rsalveti: maybe :-P
<sergiusens> mnt/system-data/apps/webdm/0.9/meta/package.yaml
<ogra_> ogra@anubis:~/datengrab/images$ sudo find mnt/ -name 'package.yaml'
<ogra_> mnt/system-data/apps/webdm/0.9/meta/package.yaml
<ogra_> mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml
<sergiusens> and mnt/system-data/oem/generic-amd64/1.4/meta/package.yaml
<sergiusens> ogra_: rsalveti
<sergiusens> oh
<sergiusens> I see
<sergiusens> size 0!
<sergiusens> ogra_: rsalveti it's empty!!!
<rsalveti> yup, size 0
<sergiusens> rsalveti: everything is empty (checks paste again)
<sergiusens> rsalveti: ogra_ some process did something nasty
<rsalveti> everything is empty
<rsalveti> lol
<rsalveti> fuck
<rsalveti> lol
<ogra_> yeah
<ogra_> the prowpart thing from cloud-init i bet
<sergiusens> we can blame cloud-init and that growpart
<ogra_> *grow
<sergiusens> it's a cloud-init-utils
<rsalveti> we have a suicidal process around
<rsalveti> not everything in the partition is 0 size
<rsalveti> actually no
<rsalveti> everything is 0, the stuff that is not 0 is because of my other boot
<sergiusens> rsalveti: directories have sizes different than 0?
<rsalveti> mostly logs
<sergiusens> rsalveti: and boots
<rsalveti> etc/dbus-1/system.d all 0 as well, which explains why systemd is complaining
<sergiusens> rsalveti: well given that system-data is made out of copies from system-a which is partition 3  which is what growpart wants to play with, I don't think this is surprising
<rsalveti> right, do we know why it decided to play with that partition?
<rsalveti> and why didn't this affect first boot
<rsalveti> and why it works sometimes?
<rsalveti> :-)
<sergiusens> rsalveti: why would growpart run anyways? that's cloud-init world
<rsalveti> sergiusens: I ask you the same question :P
<sergiusens> rsalveti: darn, I'm always hand picked for debugging :P
<ogra_> i dont see all that cloud-init output when removing waagent from writable paths and emptying system-data
<rsalveti> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,777 - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: {'mode': 'auto', 'ignore_growroot_disabled': False, 'devices': ['/']}
<rsalveti> Jul 10 13:48:24 localhost cloud-init[605]: 2015-07-10 13:48:23,809 - cc_resizefs.py[DEBUG]: resize_info: dev=/dev/sda3 mnt_point=/ path=/
<rsalveti> growpart actually failed
<ogra_> but it tried to run ...
<rsalveti> resizing went fine
<sergiusens> rsalveti: ogra_ we can probably be safe from this if we write a cfg in /etc/cloud/... where we remove growpart's '/' option
<ogra_> failed perhps because it was mounted
<rsalveti> but also something we shouldn't be running
<ogra_> sergiusens, well
<ogra_> sergiusens, how did it get ther ein the first place
<rsalveti> we need to understand why this is even required
<ogra_> yes
<rsalveti> maybe utlemming can give us a hand here
<ogra_> it wasnt on yesterdays image
<ogra_> i booted that a bunch of times
<sergiusens> ogra_: SRU ;-)
<rsalveti> the waagent change I did was earlier in the week
<rsalveti> right, unless cloud-init itself changed
<rsalveti> but it works sometimes
<sergiusens> rsalveti: I don't think is related to waagent
<sergiusens> at all
<rsalveti> yeah
<sergiusens> completely orthogonal
<rsalveti> that would only make a difference for azure
<ogra_> rsalveti, clud-init didnt change in the iage
<ogra_> *image
<ogra_> according to the manifest
<sergiusens> rsalveti: not only that, it would only make a difference if we didn't provide a seed which we do
<sergiusens> ogra_: this might have been there for a few weeks and you guys seeing, I haven't seen it yet
<ogra_> sergiusens, well, yesterday i definitely booted the same image several times
<rsalveti> right, I believe it was always there
<ogra_> now even a fresh image only works once
<sergiusens> ogra_: rsalveti we should just add a config with growpart/mode: false
<sergiusens> ogra_: rsalveti or in ubuntu-core-config -> touch /etc/growroot-disabled
<sergiusens> or growpart/devices: "" in the config
<sergiusens> default is '/'
<rsalveti> yeah, that looks better
<rsalveti> #   if the file /etc/growroot-disabled exists, then cloud-init will not grow
<rsalveti> #   the root partition.  This is to allow a single file to disable both
<rsalveti> #   cloud-initramfs-growroot and cloud-init's growroot support.
 * ogra_ still doesnt feel comfortable not knowing where that came from
<sergiusens> ogra_: it comes from cloud-init
 * sergiusens is reading the sources
<ogra_> sergiusens, i know where it comes from
<ogra_> how could that sneak into our image
<sergiusens> ogra_: then I don't understand "ogra_ still doesnt feel comfortable not knowing where that came from
<sergiusens> lolz
<ogra_> especially on a stable channel
<ogra_> yeah, badly phrased :)
<jdstrand> dholbach: hey, I think there is a problem on the documentation site
<sergiusens> ogra_: well, it's super hard to diff packages
 * ogra_ sets up a changelo diff script 
 * sergiusens wants an all source build system
<jdstrand> dholbach: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ doesn't seem to be talking about the correct thing
<ogra_> naaah
<sergiusens> ogra_: well, that does not give me the diff of the orig tarballs which is what I want
<ogra_> sergiusens, i want to see if a new clud-init version silently landed in the rootfs
<ogra_> (for example)
<jdstrand> dholbach: it doesn't describe the FHS at all, but instead how updates are applied
<sergiusens> ogra_: it didn't silently land, it was SRUd
<ogra_> without any testing on snappy ?
<jdstrand> dholbach: it used to be another document I think (I'm not sure)
<rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] stages.py[DEBUG]: Running module growpart (<module 'cloudinit.config.cc_growpart' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py'>) with frequency always
<rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x7fb5149843c8>)
<rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] cc_growpart.py[DEBUG]: growpart disabled: mode=False
<ogra_> i guess we need to add that to the SRU reqs
<sergiusens> ogra_: not sure, and growroot might have always been there
<rsalveti> Jul 10 14:45:00 localhost [CLOUDINIT] cc_resizefs.py[DEBUG]: Skipping module named resizefs, resizing disabled
<rsalveti> on first boot
<rsalveti> it didn't run
<dholbach> jdstrand: I think that's an issue in https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst then
<ogra_> sergiusens, but hasnt been enabled
<rsalveti> also didn't run now during my second boot
<rsalveti> ogra_: sergiusens: so it's not always running
<sergiusens> dholbach: I thought we were not supposed to use trunk for the stable documentation
<sergiusens> dholbach: but lp:snappy/15.04 /docs
<dholbach> sergiusens, sorry, wrong branch
<dholbach> sergiusens, I doubt the file has changed since then
<ogra_> http://launchpadlibrarian.net/208620766/cloud-init_0.7.7~bzr1091-0ubuntu2_0.7.7~bzr1091-0ubuntu3.diff.gz
<dholbach> https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst
<dholbach> jdstrand: ^ sorry, wrong branch earlier
<jdstrand> I just filed bug #1473478 for this
<nothal> Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <http://launchpad.net/bugs/1473478>
<ubottu> bug 1473478 in Ubuntu Developer Portal "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] https://launchpad.net/bugs/1473478
<rsalveti> sergiusens: ogra_: the interesting piece: http://paste.ubuntu.com/11856263/
<dholbach> thanks jdstrand
<rsalveti> there is already a config disabling it
<rsalveti> now why did it run? nobody knows yet
<sergiusens> rsalveti: ogra_ might be related to making /etc/cloud/cloud.cfg.d a writable path and a race there
<rsalveti> hm, that's a writable space
<rsalveti> right
<rsalveti> the broken image http://people.canonical.com/~rsalveti/ubuntu-15.04-snappy-amd64-generic-broken.img.xz
<rsalveti> sergiusens: if you want to take a look
<sergiusens> although writable paths are computed before anything else
<rsalveti> yup, initrd
<sergiusens> rsalveti: the only way for writable to be setup is for it run from initrd
<sergiusens> ogra_: which begs the question, was the SRUd kernel+new init tested with snappy ;-)
<ogra_> sergiusens, why initrd ?
<ogra_> nothing should have changed there
<sergiusens> rsalveti: so the initial copy went bad, cloud-init ran with its "default" config as all those file were empty
<sergiusens> that settles it
<rsalveti> right, growroot running is just a consequence
<sergiusens> so the component that copies with the 'transition' rule is doing something bad
<rsalveti> but, having such an important config as part of a writable space is dangerous
<rsalveti> not sure if the copy was broken
<rsalveti> control + c, might be that the fs was just corrupted
<sergiusens> control + c?
<rsalveti> on kvm
<rsalveti> if I call sudo reboot it always works
<rsalveti> the bug I got was when aborting kvm with a running system
<ogra_> rsalveti, could your wait-for-root change trigger any races in the transition copying ?
<rsalveti> ogra_: don't think so
<ogra_> the PPA diff is a joke https://launchpadlibrarian.net/209263590/initramfs-tools-ubuntu-core_0.7.7~ppa1_0.7.7~ppa2.diff.gz
<rsalveti> how are we mounting the writable dir?
<ogra_> i assume you didnt only quieten the output there, right ?
<ogra_> rsalveti, systemd shoudl parse fstab
<ogra_> (which we feed from initramfs )
<rsalveti> ogra_: that was the second upload, since wait-for-root was printing the fs format
<ogra_> rsalveti, right, thats what i mean ... PPA diffs are the moste useless thing
<ogra_> *most
<rsalveti> /dev/sda5 on /writable type ext4 (rw,relatime,discard,data=ordered)
<ogra_> sounds fine
<rsalveti> yeah
<jdstrand> rsalveti: fyi, bug #1473478 - dholbach says it is an issues in the snappy docs. I think it is a critical issue for devs
<nothal> Bug #1473478: snappy/guides/filesystem-layout/ no longer describes the FHS in detail <Ubuntu Developer Portal:New> <Snappy:New> <http://launchpad.net/bugs/1473478>
<ubottu> bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New] https://launchpad.net/bugs/1473478
<mattyw> hey folks, my snap is producing the following error when I run it - fork/exec /usr/bin/ssh: operation not permitted. Can't quite work out what I should be adding to the seccomp stuff, seems like I might not even be allowed?
<mattyw> sergiusens, do you know the answer ^^ ?
<sergiusens> mattyw: that's not seccomp, that's apparmor; dmesg|grep DEN
<mattyw> sergiusens, any idea what should I be putting in apparmor?
<sergiusens> jdstrand: I don't understand the 'no longer' part as we haven't been updating the docs in lp:snappy/15.04 for this to be consumed incorrectly
<sergiusens> mattyw: you need to go deeper into the apparmor world, jdstrand can help, you can start out by looking at the one in webdm
<jdstrand> sergiusens: there used to be a doc that had a table of /apps, /var/lib/apps, /home, etc that described all the FHS bits. that doc used to be at https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. What is in https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ now seems a totally different doc
<sergiusens> jdstrand: right, I don't see how a document explaining how updates work are the culprit for this...
<jdstrand> sergiusens: actually, can we recommend looking at the one in hello-dbus-fwk going forward instead? webdm is a huge exception with its policy and lack of seccomp
<jdstrand> mattyw: ^
<rsalveti> sergiusens: ogra_: so the image only breaks if you hit control + c after the first boot
<sergiusens> jdstrand: sure, but mattyw wants to exec ssh and on second though, he may need to provide it in his snap instead
<ogra_> hmpf
<rsalveti> because the fs gets corrupted
<ogra_> ext4 should still recover
<sergiusens> rsalveti: oh, ctrl+c from the terminal running kvm you mean?
<jdstrand> sergiusens: no, I get that. what I am saying is the hello-dbus-fwk has security-policy that is better for people to model their stuff on than webdm. that is all
<rsalveti> sergiusens: yes
<sergiusens> jdstrand: sure, I'll recommend that, but typing webdm is faster than hello-dbus-fwk :-P
<jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/package-dir-fwk/
<jdstrand> sergiusens: yes, but I was just in an hour meeting talking to people about how their policy is far too lenient because they used webdm as a template :P
<jdstrand> to be fair, the whole meeting wasn't on that
<davidcalle> jdstrand, about https://bugs.launchpad.net/developer-ubuntu-com/+bug/1473478
<ubottu> Ubuntu bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New]
<jdstrand> sergiusens: re the docs site, I don't claim to know where the problem lies, I only know there is a problem
<davidcalle> jdstrand, are you looking at the page in "live" or "draft" mode?
<jdstrand> davidcalle: I just went to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/. I am not logged in
<jdstrand> I think the mapping is wrong
<jdstrand> ie, the url is https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
<davidcalle> jdstrand, ok, then the fix needs to happen here https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/system-updates.rst (afair, the doc has barely changed over time)
<jdstrand> but the title is 'Snappy Transactional System Updates'
<jdstrand> ie, it is just not the correct subject
<elopio> fgimenez: (amd64)ubuntu@localhost:~$ which dpkg-query
<elopio> /usr/bin/dpkg-query
<elopio> that's 15.04
<elopio> (amd64)ubuntu@localhost:~$ which dpkg-query
<elopio> (amd64)ubuntu@localhost:~$
<jdstrand> davidcalle: why does system-updates.rst refer to filesystem-layout?
<elopio> that's rolling.
<jdstrand> those are different topics
<fgimenez> elopio, yes, makes sense
<davidcalle> jdstrand, that's also the only doc talking about the layout
<jdstrand> davidcalle: well, here is further proof of what I am saying
<jdstrand> davidcalle: 'system-updates.rst' refers to https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ for more info
<jdstrand> at the bottom
<jdstrand> something went wrong
<jdstrand> look in section 10
<davidcalle> jdstrand, oh... ok. I don't think that's a doc regression, though, as I don't remember anything else about the fs. But yes, we need a proper fs doc.
<davidcalle> (otp, brb)
<jdstrand> davidcalle: I promise you it is a regression. I refer to that doc all the time
<jdstrand> I refer to it in the security.md
<jdstrand> precisely because it used to go into the FHS in detail
 * jdstrand attempts a google cache to prove
<sergiusens> jdstrand: the title and the .rst pointed to correlate to me; the paritioning thing came from a google doc afaik
<jdstrand> but clearly, even system-updates.rst expects this to gbe a different document-- it is referencing it in rreferences
<jdstrand> sergiusens: ok, then can someone put the partitioning bits back?
<jdstrand> ie, update system-updates.rst
<jdstrand> really, I don't care-- either https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ needs to get the info back or a new page needs to be written and everything needs to be updated to refer to it. the former is easier by far
<jdstrand> google cache is already updated
<sergiusens> jdstrand: https://docs.google.com/document/d/1NdBgQXfuJWBOYT-iceTgagavE2r44dUs822gfAM9Srw/edit
<sergiusens> jdstrand: I think the doc huys just imported the wrong docs
<jdstrand> davidcalle: ^
<rsalveti> sergiusens: ogra_: I think it's the same fs corruption issue we had with touch
<jdstrand> yes!
<rsalveti> which made us change from data=ordered to data=journal
<jdstrand> that is the page I was referring to
<sergiusens> jdstrand: I updated the bug report
<jdstrand> thanks
<sergiusens> np
<sergiusens> rsalveti: change it then ;-)
<rsalveti> ogra_: sergiusens: I think we should probably do the same with snappy
<rsalveti> right
 * jdstrand notes that dpm said "Content now published on http://developer.ubuntu.com/snappy/filesystem-layout/" in a comment in that google doc :) I knew I wasn't crazy
<ogra_> rsalveti, yeah
<jdstrand> davidcalle: this is what it used to be: http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
<jdstrand> davidcalle: web.archive.org had the new cache around June 10th
<sergiusens> mterry: http://paste.ubuntu.com/11856443/
 * mterry hugs sergiusens
<ogra_> hmm why does sudo halt not kill my kvm
<ogra_> rsalveti, hmm, so after halting the system properly on first boot it doesnt fall over anymore if i ctrl-c
<jdstrand> beuno: what does "Move to waiting for updates queue" do in the store? is that the correct thing to do if they need to perform an update before acceptance?
<ogra_> i cant get into the broken state
<rsalveti> ogra_: that's because the writable data is already there
<beuno> jdstrand, it's to dismisss something from the queue until they reply or upload
<rsalveti> ogra_: it's a first boot thing as it's when the writable data gets copied over
<beuno> so I think, yes
<beuno> if you ask for more info
<beuno> it does that as well
<ogra_> rsalveti, yes, but i think we dont need to change the mount options but call sync a few times in the right place
<beuno> so it's more to do that, without having to write something becuase you've already communiuated
<jdstrand> beuno: great, thanks!
<rsalveti> ogra_: journal is a safe option, and also good since we can avoid the same apparmor issues we had
<rsalveti> with phone
<ogra_> rsalveti, the initrd script mouonts /writable and copies the stuff ... but never unmounts or syncs
<rsalveti> ogra_: because it stays there
<rsalveti> for the bind mounts
<ogra_> so the partition content stays in cache
<ogra_> and then you ctrl-c
<ogra_> so simply adding a sync call at the end of the copying to flush the cache on boot already should save us
<rsalveti> right, a sync would already help, but I think journal is still a better option
<rsalveti> to avoid general writable space corruption issues
<ogra_> yes, we should do that, but will it be enough (will it write synced then  ?)
<rsalveti> ogra_: I think so, it gets to the journal first
<rsalveti> we can try
<ogra_> i suspect even with the mount option set you wont flush the cache in time
<rsalveti> let me upload the change
<ogra_> +1
<sergiusens> rsalveti: ogra_ just do both
<rsalveti> sergiusens: don't think we need sync with journal
<rsalveti> but yeah, already uploaded just with journal
<rsalveti> will test once the new image is out
<ogra_> right, lets test that first
<ogra_> a sync after copy makes sense in any case though ... but if journal helps for this image thats enough
<davidcalle> jdstrand, can you confirm that doc is still valid with latest 15.04?
<rsalveti> sergiusens: don't know if you replied, but for https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1472516 we still need a fix, right?
<ubottu> Ubuntu bug 1472516 in goget-ubuntu-touch (Ubuntu) "udf cannot double map partitions error" [Undecided,Confirmed]
<ogra_> some poeople did hit it the last two-three days in here
<rsalveti> yeah, I'm expecting a lot of people getting that bug once we promote it to tools
<ogra_> merged 3h ao :)
<ogra_> *ago
<rsalveti> ogra_: but don't know if that is the fix
<rsalveti> that was my question to sergiusens
<ogra_> ah
<sergiusens> rsalveti: ogra_ there's an MP at the end there
<jdstrand> davidcalle: system-updates.rst is invalid with 15.04. http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ is correct
<rsalveti> sergiusens: my question is if the mp really fixes the issue
<jdstrand> davidcalle: I think that http://web.archive.org/web/20150122213306/https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ should be restored and system-updates.rst mapped to something else
<sergiusens> I can release that, it is related to error encapsulation; this would expose the actual issue and fail gracefully
<sergiusens> rsalveti: I don't know, I can't reproduce
<rsalveti> sergiusens: right, let's release this and copy to tools-proposed then
<sergiusens> rsalveti: I just followed the trace
<rsalveti> then we can get people to test it a bit more
<rsalveti> at least Chipaca was getting it all the time
<jdstrand> davidcalle: but, please talk to the snappy guys-- sergiusens suggested system-updates.rst may be wrong to begin with
<sergiusens> rsalveti: yeah, that's why I asked him to review, not sure if he tested though
<elopio> fgimenez: can you run the integration suite? In the latest #103 it can't ssh, but it seems to work in #102.
<jdstrand> looking at the bzr commits, james hunt added ./system-updates.rst on 2015-04-15
<davidcalle> jdstrand, ok, I'm finishing restoring the old one (as Filesystem layout). I'll rename the existing one to "Transactional updates", then we'll see what to do with it.
<jdstrand> it references https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/
<jdstrand> it is intended to be a difference doc
<jdstrand> davidcalle: that sounds perfect
<jdstrand> davidcalle: thank you so much! :)
<sergiusens> +1
<Chipaca> rsalveti: sergiusens: i got it a lot, but not all the time; after N tries i got an image
<Chipaca> sergiusens: i did not get the error with your branch, but i didn't try 20 times either
<Chipaca> sergiusens: should i?
 * Chipaca can do a for
<rsalveti> would be nice, yeah
<sergiusens> Chipaca: maybe :-P at least we can see the underlying error
<fgimenez> elopio, i'm having problems with udf, let me try
<Chipaca> sure
<sergiusens> and I can fix before releasing
<sergiusens> fgimenez too if time permit
<fgimenez> sergiusens, ok
<sergiusens> Chipaca: btw, pb has a race wrt to start and finish calls
<jdstrand> vmayoral|pc, lool: fyi, the https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ wrong content issue is https://bugs.launchpad.net/snappy/+bug/1473478. davidcalle is fixing it as we speak
<ubottu> Ubuntu bug 1473478 in Snappy "snappy/guides/filesystem-layout/ no longer describes the FHS in detail" [Undecided,New]
<sergiusens> Chipaca: we might need a package update
<lool> jdstrand: ah great thanks
<Chipaca> sergiusens: goget-ubuntu-touch is missing gettext in dependencies?
<mattyw> sergiusens, sorry, me again, any idea what a aa_change_onexec failed with -1 error is telling me?
<fgimenez> elopio, btw, finally in azure with --vm-size Medium works fine for me :)
<elopio> fgimenez: good, once we get the tests running we can put the instructions in the readme
<sergiusens> Chipaca: oh, I added that to my release branch...
<rsalveti> ogra_: sergiusens: elopio: building new image for 1473465
<sergiusens> rsalveti: ok for 0987654321 (?)
 * sergiusens takes a chance with a bad joke
 * ogra_ has a lottery bill with exactly that number !
<sergiusens> mattyw: most likely that your appamor profile is bad
<sergiusens> or points to a file that doesn't exist
<davidcalle> jdstrand, sergiusens : so, https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ and https://developer.ubuntu.com/en/snappy/guides/transactional-updates/
<jdstrand> davidcalle: looks great!
<jdstrand> davidcalle: thanks! :)
<sergiusens> wfm
<sergiusens> Chipaca: scratch that, I didn't upload the 0.26 branch :-/
 * Chipaca scratches
<davidcalle> np :)
<sergiusens> Chipaca: grab trunk again and it will all bzr bd/sbuild just fine
<Chipaca> i'll take your word for it :)
<fgimenez> sergiusens, building from trunk works for me
<fgimenez> but 0.25-0ubuntu1, don't know if that's right
<fgimenez> elopio, it cannot ssh with latest rolling/edge, trying now with revision -1
<fgimenez> elopio, 102 works fine
<fgimenez> sergiusens, in fact i'm not sure if it works http://paste.ubuntu.com/11856655/
<fgimenez> elopio, i'm getting the same error on 102 too eventually, will catch up next monday o/
<mattyw> sergiusens, sorry, me again, nothing I do gives me anything other than that error message. Could I send you the snap to see what's wrong?
<mattyw> sergiusens, and I'm sure nothing has changed - and I used to get a different error
<mterry> rsalveti, if you can also review https://code.launchpad.net/~mterry/snapcraft/local-plugins/+merge/264305 that would be swell
<mattyw> sergiusens, or suggest someone else who might be able to help?
<mattyw> sergiusens, ah, I might have it
<sergiusens> mattyw: send me the snap if you want (or link to it)
<mattyw> sergiusens, I finally found it :) sorry for pestering :)
<sergiusens> no worries
<sergiusens> Chipaca: given http://paste.ubuntu.com/11856655/ I now know that format is failing, just need a better message, going to craft an MP
<mattyw> sergiusens, it would be nice to have some tooling to parse package.yaml and apparmor/ seccomp files to at least check they parse ok, the problem seems to be that snaps can get built with that stuff not being valid
<ogra_> mattyw, we have tools for that in snappy build ...
<sergiusens> mattyw: yeh, we are discussing adding json-schema support to all yamls with ricmm
<ogra_> they are just temporary disabled
<sergiusens> jdstrand: btw, we are considering adding json-schema support to all our yamls
<mattyw> ogra_, sergiusens awesome news
<sergiusens> mattyw: for now, run click-reviewer-tools against the built package
<vmayoral|pc> jdstrand: that's great thanks!
<mattyw> sergiusens, what ppa is that in?
<mterry> sergiusens, it would be nice if we had proper jenkins instances for snappy branches.  Could build the debian package, could install packages as needed, etc
<sergiusens> mterry: ppa:snappy-dev/tools
<mterry> mattyw, ^
<sergiusens> yeah
<mterry> :)
<mattyw> mterry, sergiusens thanks :)
<sergiusens> mterry: maybe; as I said, this tarmac thing was meant for go and snap packages not having debian packaging
<sergiusens> mterry: I don't like jenkins so I'll leave that to someone else
<sergiusens> already had my fair share of grief with it when I was with the ci+qa team
<mterry> sergiusens, ah hrm.  Do you have a preferred tool in the same problem space?
<sergiusens> mterry: I don't think we have one for launchpad, at least a one size fits all solution
<jdstrand> sergiusens: json-schema support? you mean, supporting json in the yaml?
<sergiusens> jdstrand: http://www.yaml.org/spec/1.2/spec.html#id2803231
<sergiusens> mterry: I would love to just use travis fwiw
<sergiusens> rsalveti: Chipaca https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/ErrExec/+merge/264440
<sergiusens> rsalveti: Chipaca from fgimenez' pastebin I guess the error he gets either comes from dmsetup clear or kpartx -ds, both related to unmapping
 * Chipaca thinks it's nigh on beer o'clock
<Chipaca> sergiusens: 100 runs didn't get me the error here :-(
<sergiusens> Chipaca: did you reboot? /me thinks kernel got confused
<Chipaca> sergiusens: yesterday to fix it? dmsetup clear'ing between tries got it working
<Chipaca> losetup/dmsetup/partx thing
<sergiusens> Chipaca: what order is the suggested order?
<sergiusens> Chipaca: dmsetup clear, kpartx -ds and last losetup -d ?
<Chipaca> sergiusens: i did no research on this. i did it backwards to that though.
<Chipaca> i think
<Chipaca> not sure :)
<sergiusens> Chipaca: you should delete the mapping for a loop device before deleting the loop device though
<sergiusens> Chipaca: shouldn't
<sergiusens> rsalveti: new u-d-f building
 * elopio goes home before getting trapped here by the rain.
<rsalveti> sergiusens: cool
<rsalveti> builders are busy it seems
<rsalveti> just built for ppc
<rsalveti> webdm failed to install: Get https://public.apps.ubuntu.com/anon/download/canonical/webdm.canonical/webdm.canonical_0.9_multi.snap: EOF
<rsalveti> niiice
<rsalveti> trying again
<rsalveti> ogra_: interesting https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/32102
<rsalveti> started 2 hours ago, still running
<rsalveti> let's try yet another build
<carif_> is this channel archived somewhere?
<Letozaf_> higgins, someone asked me if you can open a terminal in Snappy personal desktop, can it be done ?
<Letozaf_> hi not higgins :( sorry
<sergiusens> Chipaca: btw, I don't see you on untappd!
<sergiusens> rsalveti: https://launchpad.net/builders seems to be availability for amd64 for only
<rsalveti> sergiusens: yeah, everything is currently stuck
<rsalveti> image, package builds, etc
<Letozaf_> no matter, found out by myself how to do it, thanks
<elopio> a man came and brought the internet \o/
<rsalveti> elopio: \o/
<rsalveti> sergiusens: yeah, builds are busted
<rsalveti> database outage
<rsalveti> so yeah, guess no release for today =\
<sergiusens> rsalveti: oh well
<rsalveti> sergiusens: at least it's already beer o clock for you it seems :-)
<sergiusens> rsalveti: yup :-)
<ogra_> carif_, on irclogs.ubuntu.com
<ogra_> rsalveti, hmm, looks like it built fine
<rsalveti> ogra_: image is still building
<ogra_> well, the log disagrees
<rsalveti> colin said the buildds should be mostly fine now
<rsalveti> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<rsalveti> needs building here
<rsalveti> that other one was canceled
<rsalveti> since it got stuck
<ogra_> i dont see amd64
<ogra_> did you run it with ARCHES= set ?
<ogra_> <cjwatson> boiko,robru: lots of buildd breakage at the moment due to a partial database outage today, need to analyse the whole lot and repair
<ogra_> from #ubuntu-ci-eng
<ogra_> seems to affect a lot of LP
<rsalveti> yup, what I said a bit earlier
<rsalveti> all broken
<rsalveti> :-)
<ogra_> rsalveti, hmm, so that also means we dont know yet if the fix works ?
<rsalveti> ogra_: nops
<ogra_> damn
<rsalveti> let me see if system-image imported the amd64 build at least
<ogra_> cdimage seems to have it at least
<ogra_> yup, system-image seems to have updated amd64
<ogra_> has a timestamp that matches the cdimage build
<ogra_> hmm, but no package changes
<ogra_> oh
<ogra_> heh
<ogra_> ogra@anubis:~/datengrab/images$ ./compare-snappy-manifests.sh 20150709 20150710
<ogra_> Package changes between 20150709 and 20150710
<ogra_> === Upgraded Packages ===
<ogra_> initramfs-tools-ubuntu-core from 0.7.7~ppa2 to 0.7.7~ppa3
<ogra_> there we go ...
<ogra_> my script only checked armhf
 * ogra_ twiddles thumbs waiting for udf
<rsalveti> yeah, let me give it a try
<rsalveti> worked fine the first time, let me try a few more
 * ogra_ is at the second time
<ogra_> yup
<ogra_> no matter if i close the window or ctrl-c ... seems fine
<ogra_> 5 times no corruption ...
 * ogra_ builds a new image and does another 10 
<ogra_> bah, i wish it could cahe webdm
<ogra_> *cache
<rsalveti> ogra_: yeah, seems fine here
<ogra_> yup, 10 10x killed and stable
<ogra_> -10
<ogra_> :P
<rsalveti> :-)
<rsalveti> now to wait the armhf image
<ogra_> well, the build seems done
<rsalveti> waiting https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.27-0ubuntu1 to be promoted as well
#snappy 2015-07-12
<carif__> can snappy look for snaps at multiple websites besides system-image.ubuntu.com? If so, how do I add my own website on an unbuntu core system?
<carif__> I'm thinking something in /etc/system-image/config.d/30_local_repository.ini
<carif__> ... and its a little odd that these are ini files and not yaml files
<damjan> .ini files are just fine for most things. it's not often that you need hierarchy in configs
<svij> I've created a my packageâ¦ but when I try to run the binary, I'll get a "execv failed: Permission denied". Any hint where I should look to fix this?
<svij> *my first snap package
<Chipaca> svij: you still there?
<carif__> svij, from the hello-world example, i noticed they added a 'caps: []' to each binary in the sequence of binaries in package.yaml, see http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-world/meta/package.yaml
<carif__> I think this is for apparmor but I don't know much about apparmor so I defer to the more knowledgable on the channel
<carif__> for my first snap, I got a similar error, added this and then it worked
<carif__> the documentation doesn't identify this in its example
#snappy 2016-07-11
<mup> PR snapd#1486 closed: interfaces: add wireless-control <Created by lpotter> <Closed by lpotter> <https://github.com/snapcore/snapd/pull/1486>
<liuxg> has anyone successfully done a ubuntu phone snap app? I am having a little problem in creating a qmake snap app for 16.04. my code is at https://github.com/liu-xiao-guo/snaptest thanks
<liuxg> when I am trying to snap a qmake application, I get the error like http://paste.ubuntu.com/19046504/. My source code is at https://github.com/liu-xiao-guo/rssreader_snap. what could be the problem for it? thanks
<dholbach> hey hey
<zyga> mwhudson: hey, can I ask you to update snap-confine to 1.0.36
<zyga> mwhudson: or alternatively, review a patch that I make
 * zyga needs to refresh his git-buildpackage skills
<knurd> lo; does Snap require any AppArmor stuff that is not in the upstream kernel? Just wondering, because LWN.net wrote "[â¦] In particular, most distributions lack Ubuntu's patched version of AppArmor [â¦]" http://lwn.net/Articles/691372/
<zyga> good morning
<zyga> knurd: yes, that's accurate
<zyga> knurd: we've developed many new features for apparmor and not all of them are upstream yet
<zyga> knurd: the security and kernel teams at Canonical are working on upstreaming all the patches
<knurd> zyga: k, thx for the clarification
<mwhudson> zyga: sure
<mwhudson> zyga: the ./configure arguments have changed yet again?
<mwhudson> zyga: and it's /usr/bin/snap-confine now, not /usr/lib/snapd/snap-confine?
<mwhudson> zyga: can you provide me a changelog too? the differences between 1.0.35 and 1.0.36 seem almost entirely trivial?
<zyga> mwhudson: no, they shoulnd't have
<zyga> mwhudson: sure, .36 fixed apparmor confinement, .34 and .35 were unconfined by accident
<zyga> (confinement of snap-confine itself)
<zyga> mwhudson: I will spend some time this week to discard debian/ from upstream repository entirely
<zyga> mwhudson: so that there's no confusion
<zyga> mwhudson: but I will only do that after I'm ready with spread tests for debian
<mwhudson> zyga: maybe send me a patch for the debian directory then?
<zyga> mwhudson: for the current tree on alioth?
<mwhudson> zyga: one second
<mwhudson> zyga: for the tree as of now (i.e. a410e5e)
 * mwhudson brb
<zyga> mwhudson: thanks, I'll do that today
<mwhudson> zyga: do it in an hour if you want it uploaded before my tomorrow morning :)
<mup> Bug #1600713 opened: snapd.boot-ok.service always failed after booting <Snappy:New> <https://launchpad.net/bugs/1600713>
<nhaines> zyga: Do you happen to know what the status of snappy is on the Raspberry Pi 2?
<mup> Bug #1600719 opened: The camera interface only grants access to /dev/video0 <Snappy:New> <https://launchpad.net/bugs/1600719>
<mup> PR snapd#1492 closed: overlord/auth: add Device/SetDevice to persist device identity in state <Created by wgrant> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1492>
<mup> PR snapcraft#570 closed: Add https_proxy support to maven plugin <Created by squidsoup> <Closed by squidsoup> <https://github.com/snapcore/snapcraft/pull/570>
<mup> PR snapd#1522 opened: Introduce a simple key-value store for user-specific data <Created by stevenwilkin> <https://github.com/snapcore/snapd/pull/1522>
<zyga> mwhudson: ah, sorry, I got stuck in suse bits, it's not urgent, it can wait till tomorrow
<zyga> nhaines: hey
<zyga> nhaines: all all-snap devices are still in progress, we're adding things required to make them work reliably, they will only be relased when it is sensible to do so (e.g. you can update reliably) - you can run snappy on those devices earlier (now) but this is not the final version
<hikiko> hello
<hikiko> I've written my first snap and I was wondering what's the next steps until I upload it to playpen.. is there any tutorial somewhere? (thanks)
<tsimonq2> hikiko: hi, are you familiar with Git?
<hikiko> well a little bit tsimonq2
<hikiko> I know the basics: checkout, push, commit...
<tsimonq2> hikiko: let me walk you through it here
<tsimonq2> hikiko: git clone https://github.com/ubuntu/snappy-playpen.git
<hikiko> thanks tsimonq2 :)
<tsimonq2> hikiko: no problem :)
<tsimonq2> hikiko: after that: cd snappy-playpen
<tsimonq2> hikiko: then: cp -rsnap-template/ YOUR-SNAP-NAME/
<tsimonq2> whoops
<tsimonq2> hikiko: then: cp -r snap-template/ YOUR-SNAP-NAME/
<tsimonq2> hikiko: then customize the snapcraft.yaml file and the README.md to your liking
<tsimonq2> hikiko: after that, open the README.md in the main snappy-playpen directory
<tsimonq2> hikiko: where you see the other snaps, copy/paste an entry and customize it to fit your snap
<tsimonq2> hikiko: when you are done with all of that, do: git add YOUR-SNAP-NAME/ README.md
<nhaines> zyga: yes, but if I run snappy on those devices, I can't run any current snaps, and anything I learn about setting up, administering, and developing for those systems will be completely obsolete.
<tsimonq2> hikiko: then: git commit -am "Added (SNAP NAME) snap"
<tsimonq2> hikiko: I'll pause and wait for you to catch up :)
<nhaines> So since we were promised all-snap systems in May, and now it's halfway through July, I'm curious if there are any newer estimates on that.
<hikiko> tsimonq2, I am reading you :)
<tsimonq2> hikiko: now it gets a little complicated
<tsimonq2> hikiko: then, go to the following URL: https://github.com/ubuntu/snappy-playpen
<zyga> nhaines: you can run all current snaps
<zyga> nhaines: only device specific things can still change (e.g. how the kernel and gadget snaps are defined)
<tsimonq2> hikiko: sign into your GitHub account, then click the fork button at the top
<nhaines> zyga: I can run (for instance) the NextCloud snap on a Raspberry Pi 2 running snappy Ubuntu 15.04?
<zyga> nhaines: no, only with the not-yet-released snappy 16.04
<hikiko> tsimonq2, I have a personal github account should I create another one using canonical's email?
<nhaines> zyga: yes so that's what I'm saying.
<hikiko> or it's fine to use the personal?
<tsimonq2> hikiko: wait, do you have an @canonical.com email address?
<hikiko> yes tsimonq2
<tsimonq2> hikiko: you can add that email to GitHub if you wish
<tsimonq2> hikiko: or you can create another account
<nhaines> zyga: we went from "It'll probably be 6 weeks because we want this to be reliable" to... now it's 10 weeks with no updates.  And I'm okay with that--I want stable, too.  But I have an RPi2 sitting here doing nothing.  :)
<tsimonq2> hikiko: your choice :)
<zyga> nhaines: there are updates every day but you know how things are with scheduling
<hikiko> ok!
<tsimonq2> hikiko: go to https://github.com/settings/emails and add an email address, then you should be all set with that email address! "_
<tsimonq2> *:)
<nhaines> zyga: I don't mean "no updates" as in "nobody's working on it."  I'm certain everyone is.  I mean "no updates" as in "things are obviously taking longer but no one's talking about it on the mailing list anymore."  :)
<zyga> ah
<zyga> I agree on that
<nhaines> At least you can install a classic 16.04 system to an RPi2 and run snaps that way, which is not a bad consequence of how awesome it is that snapd made it into Ubuntu 16.04 classic, which did I mention is super awesome?  :)
<hikiko> done tsimonq2 :)
<nhaines> And frankly, way more useful to me in general.  But I still want to do RPi2 stuffs.  :)
<tsimonq2> hikiko: when you have created the fork, run the following: git remote add fork https://github.com/YOUR_USERNAME/snappy-playpen
<tsimonq2> hikiko: then git push fork master
<tsimonq2> hikiko: after that, go to https://github.com/ubuntu/snappy-playpen and you should then be able to create a pull request
<tsimonq2> hikiko: after you create the pull request, someone will comment
<tsimonq2> hikiko: you then work with them until you get it merged
<tsimonq2> hikiko: then there you go! :)
<hikiko> thanks *a lot* tsimonq2 :) I am going to follow the steps!
<tsimonq2> great hikiko, I follow the PRs, I hope to see yours soon :)
 * tsimonq2 creates PR to fix the lack of documentation explaining this :P
<brunch875> Hello! I'm using the telegram snap and it's mildly annoying having to copy the images I want to send to a buddy into the sandbox
<brunch875> is there a way to change the scope of the sandbox?
<zyga> brunch875: no, that's something the snap author would have to do, in addition we know about this restriction but integrting a better solution is still some time away
<brunch875> aww
<mup> PR snapd#1340 closed: many: introduce a tool to sign assertions <Reviewed> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1340>
<mup> PR snapd#1489 closed: snap: ensure unknown arguments to `snap run` are ignored <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1489>
<mup> PR snapcraft#643 closed: Release debian/changelog for 2.12.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/643>
<liuxg> sergiusens, OK. let me check my email. thanks
<mup> PR snapd#1523 opened: asserts: fix minor doc comment typo <Created by emgee> <https://github.com/snapcore/snapd/pull/1523>
<liuxg> sergiusens, I think the question I asked is different from one I asked in the mailinglist. I have made it working and I used the one in your blog by using the desktop_launch. My final working one is at https://github.com/liu-xiao-guo/snaptest_working/blob/master/snapcraft.yaml. The not working one is at https://github.com/liu-xiao-guo/snaptest/blob/master/snapcraft.yaml. It gave me the error http://paste.ubuntu.com/19078940/. I do not know whether this is a
<liuxg>  bug or not. thanks
<liuxg> sergiusens, I do not know why it gives error if I set the package name and the app name the same. I have to make them different to make it working.
<sergiusens> liuxg so `command: desktop-launch snaptest` does not work?
<liuxg> sergiusens, no in fact, it does not generate the .snap file. I gives me the error like http://paste.ubuntu.com/19078940/. In the snapcraft.yaml file at https://github.com/liu-xiao-guo/snaptest/blob/master/snapcraft.yaml, I define the package name and the app name the same. I have to change the app name to make it compile for me.
<liuxg> sergiusens, this snapcraft.yaml at https://github.com/liu-xiao-guo/snaptest_working/blob/master/snapcraft.yaml  gives me the correct .snap file, and it invokes the app for me
<sergiusens> liuxg ok, log a bug so we can triage and determine if it is a bug or not (as I don't have time right now)
<liuxg> sergiusens, sure, thanks. so, this is the link for filing a bug https://bugs.launchpad.net/snapcraft/+filebug, right?
<sergiusens> liuxg that is correct
<liuxg> sergiusens, thanks. I will do that.
<mup> PR snapd#1524 opened: classic: remove (most of) "classic" mode, this is implemented as a snap now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1524>
<liuxg> sergiusens, I have filed a bug at https://bugs.launchpad.net/snapcraft/+bug/1601834 thanks
<mup> Bug #1601834: Error "[Errno 21] Is a directory" when building a snap package for a qmake project <Snapcraft:New> <https://launchpad.net/bugs/1601834>
<tgm4883> Making a new snap an having trouble with the build binaries getting added. I think I need to specify INSTALL_ROOT during the make install, but I don't see a way to specify that. What are the "Common plugin keywords"?
<ogra_> INSTALL_ROOT=$(DESTDIR)
<ogra_> ?
<ogra_> (at least in the make plugin)
<tgm4883> ogra_: possibly. I was using autotools
<tgm4883> let me look at the make plugin again
<tgm4883> ogra_: so looking at the make plugin, how do I specify flags for 'configure' then other flags for 'make install'?
<ogra_> dunno, i always do  it in the makefile itself
<tgm4883> I suppose that makes sense, but now I need to patch upstream somehow
<tgm4883> Does snapcraft have some variant of debian/patches ?
<josepht> tgm4883: not at the moment, you'd likely need to create your own custom plugin
<ogra_> tgm4883, not within plugins i think ... (i work around that by using the make plugin and just call the patch command from the makefile usually)
<ogra_> https://github.com/ogra1/packageproxy is an example
<dholbach> sergiusens, do you know when you're going to land 2.12.1? :)
<dholbach> oh, it's already landed, just still in SRU
<tgm4883> hmm, ok
<ogra_> dholbach, it suffers from test anxiety :)
<tgm4883> Let me ask a different question. The DESTDIR. Does the snap application know about this directory or does it still think it's in /usr/share
<ogra_> well, if you use --prefix=./ it will thinnk ./share ;)
<tgm4883> just trying to figure if it would make sense to try --prefix=${DESTDIR)
<tgm4883> willcooke: in case  you've made some changes and haven't commited them to github, I took your mythtv snap initial work and played with it this weekend. It seems to compile file, although doesn't install fine yet.
<willcooke> tgm4883, hey!  Yeah, I got it to build and then got busy with other things.
<willcooke> tgm4883, I was toying with the idea of building a separate frontend and backend snap - but I know that's not really a supported thing
<tgm4883> I think there was one build dep missing from the github repo for xinerama, other than that it seems to build
<tgm4883> Did you get it to install properly?
<willcooke> tgm4883, didnt try tbh
<tgm4883> ok
<tgm4883> that's what I was working on ^ but it sounds like I'll need to create a plugin
<tgm4883> As for separate backend/frontend, mythbuntu's always supported that.
<tgm4883> Still working through the snap documentation, which I see there is a way to autostart snaps. Need to figure out if that's configurable by the user though
<tgm4883> if so, I don't see why we wouldn't just have 1 'mythtv' snap. I don't believe the extra backend vs frontend code would be that much
<willcooke> oki, so if the b/e isnt set to autostart then you just have a box with both installed but only firing up the f/e?
<tgm4883> yep
<willcooke> neat
<tgm4883> ideally, we'd just ship both as different internal binaries and have the user say "snap autostart mythtv.mythbackend", not sure if that is possible
<ogra_> i dont think it is
<ogra_> until "snappy config" comes back at least
<ogra_> but you can work around that ...
<tgm4883> ogra_: I need that to happen for 18.04 then :)
<ogra_> (you can not actually modify the systemd units, snapd generates them at install time)
<ogra_> what yxou can do is to have your start script that the sytzemd unit calls check for a flag on disk and fail gracefully
<zyga> tgm4883: all services are auto-started
<ogra_> and have a script "mythtv.toggle-autostart"
<ogra_> which sets the flag
<tgm4883> ogra_: ah, that might work
<tgm4883> zyga: when you say services, are you talking about all the exposed binaries in a snap?
<ogra_> all services
<tgm4883> (I might have to go back and look at the documentation as I might be forgetting stuff)
<ogra_> you can have either apps or services
<ogra_> (an app with "daemon:" property magically becomes a service)
<tgm4883> ok that makes sense
<tgm4883> so we'd have a mythtv.mythbackend service that checks for a file on disk (eg. /etc/mythtv/backendstart ) and if it exists, call the actual mythbackend binary
<ogra_> well ... $SNAP_DATA/backendstart
<ogra_> (/etc isnt visible to your snap)
<ogra_> (and if it was, it would be readonly)
<tgm4883> ogra_: where "$SNAP_DATA" is disk space that is writable for the snap?
<ogra_> yeah
<tgm4883> ok cool. I haven't gotten to that part of the documentation yet
<ogra_> $SNAP is readonly, $SNAP_DATA is rw for services etc ... $SNAP_USER_DATA is rw for user apps
<tgm4883> So the flip side of this is the frontend, which is a graphical application. Could this be autostarted in the same way
<zyga> tgm4883: no, all "background applications", aka apps that have a daemon field
<tgm4883> Could it be handled the same way that non-snap applications are currently autostarted? (Via ~/.autostart or whatever)
<ogra_> if you would auto-start it it would run as root ...
<ogra_> i dont think we have actual autostart support for desktop apps yet
<tgm4883> ok
<ogra_> (sounds like a good wishluist bug to file ;) )
<tgm4883>  https://launchpad.net/snappy ?
<ogra_> yep (that used to be in the topic ... but our managers didnt manage to put it back when changing it ... /ma glares at olli| and jamiebennett  :)  )
<tgm4883> bug filed
<mup> Bug #1601859 opened: Need a way to autostart applications (not services) <Snappy:New> <https://launchpad.net/bugs/1601859>
<mup> PR snapd#1525 opened: tests: mount-observe interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1525>
<joc_> elopio: sergiusens: looks like there was an unfortunate timeout during the "autopkgtest snaps" run on my PR :(
<joc_> really hoped this one was going to be a good one
<iliv> hi guys, I'm packaging (still) PostgreSQL and one of the problems that I'm currently facing is basically this error message when I'm trying to run initdb:
<iliv> initdb: invalid locale settings; check LANG and LC_* environment variables
<iliv> I tried to export LANG= in my wrapper script but that didn't help
<iliv> what is LANG= in the sandbox? or is there one at all by default?
<iliv> I installed this package in --devmode
<sergiusens> joc_ as in something a retry would fix?
<joc_> sergiusens: maybe, looked to have happened after the mosquitto demo was being built/tested, thing leo already kicked it off again though
<joc_> s/thing/think/
<mup> PR snapd#1523 closed: asserts: fix minor doc comment typo <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1523>
<sergiusens> joc_ ah, good
<joc_> sergiusens: finished already?!
<joc_> there was definitely something wrong with last run then - it was taking hours
<sergiusens> elopio kyrofa and josepht what's up?
<elopio> o/
<elopio> sergiusens: All good here. kyrofa is moving.
<sergiusens> elopio right, thanks for the reminder
<sergiusens> and I joined the standup early :-P just got a notification for it :-P
<elopio> I assumed that :D
 * sergiusens gets some coffee started in the meantime
<mup> PR snapd#1521 closed: many: removed authenticator, store gets a user instead <Created by matiasb> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1521>
<mup> PR snapd#1526 opened: Interfaces: Builtin: add pluggable storage interface <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1526>
<rookie_> hi all, i have aquestion. is ubuntu core snappy available for raspberry pi 3 ? i can't seem to find any info over it
<both> hi, what is 'apg-get upgrade' equivalent on snappy?
<sergiusens> both snap refresh
<mup> PR snapd#1527 opened: overlord/state,overlord/ifacestate: define basic infrastructure for and then setting up serialising of interface mgr tasks <Created by pedronis> <https://github.com/snapcore/snapd/pull/1527>
<both> sergiusens: there's no such command on my snappy. (ubuntu-core/15.04/stable; armhf)
<both> There's no 'snap find' command on my snappy. How to get it?
<mwhudson> zyga didn't send me a patch
<tsimonq2> maybe it's just been a couple of days and it got lost in inboxes, but could I get eyes on https://github.com/snapcore/snapcraft/pull/619 please?
<mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619>
<thomi> sergiusens: any thoughts on https://bugs.launchpad.net/snapcraft/+bug/1599709 ?
<mup> Bug #1599709: organize feature deletes destination folder, is surprising <Snapcraft:New> <https://launchpad.net/bugs/1599709>
#snappy 2016-07-12
<sergiusens> thomi aside from, it should be fixed?
<sergiusens> both oh, I was thinking 16.04; try `snappy update`
<thomi> sergiusens: I'm 90% sure it happens on 2.12 - which AFAIK is the latest on xenial
<thomi> sergiusens: or do you mean it should be fixed in the git repo?
<sergiusens> thomi I mean we should take the time and fix it
<thomi> sergiusens: ahhh - gotchya - english is a PITA :D
<thomi> I thought you meant it should already be fixed :D
<sergiusens> heh, it is the least complicated wrt double speak :-)
<tsimonq2> o/ sergiusens :)
<both> sergiusens: 'snappy update' is working, but I don't mean 'update' but 'upgrade'
<both> and BTW...
<both> there's no 'snap' command in my snappy. why? how to get it?
<qengho> both: having little information to go on, that smells like an ancient version.
<both> qengho: this is arm(hf) version
<both> for RPi2
<qengho> both: Ah. Right. I have not watched closeley lately, but I don't know of any fresh versions of that. :(
<both> is there any magical command that will make 'trusty ubuntu' from 'snappy ubuntu'?
<qengho> trusty=Ubuntu 14.04 LTS?
<both> qengho: yes :)
<Kamilion> 'chroot'
<mup> Bug #1602063 opened: find doesn't show snap size <Snappy:New> <https://launchpad.net/bugs/1602063>
<qengho> both: There are newer releases than the 2014-April one but no, you can't change Ubuntu Snappy into Ubuntu or backwards. Inside each, you can simulate the other.
<both> I need php, apache, mysql, python running on my snappy. How to get it without 'snap' command?
<Kamilion> dd a different ubuntu image on the card
<qengho> both: In ubuntu, "apt install snapd". In Ubuntu, "snappy enable-classic" or something similar later.
<both> Kamilion: there's only ubuntu snappy and ubuntu mate available so far for ARM boards AFAIK. Do you know anything else better than that?
<Kamilion> i'd suggest the https://ubuntu-mate.org/raspberry-pi/ image
<Kamilion> then install snapd from the repo.
<qengho> +1 Kam
<Kamilion> i should point out, the only thing that's really raspberry pi specific on that image is the kernel.
<Kamilion> the userspace is standard armv7.
<Kamilion> in theory it should work with odroids as well, if you use an odroid-specific kernel.
<Kamilion> or banana pi, or whatever other ARM7+ board you can come up with. But not the original armv6 raspberry pi.
<Kamilion> you're pretty much stuck with their custom debian armv6+ userspace as well as their kernel.
<Kamilion> (if you're on a pi1)
<Kamilion> or one of it's clones like the odroid-w
<both> I had some problems with ubuntu mate :/ I hope it's just mSD size (8GB).
<Kamilion> but once you get a working linux kernel, you've pretty much got open choice of who's flavor of gnu userspace to run under it
<Kamilion> there's also a 16.04 server image bouncing around somewhere
<Kamilion> i don't think it's official though
<Kamilion> i'm not seeing it in the normal place at least
<Kamilion> ah, there it is.
<Kamilion> both: https://wiki.ubuntu.com/ARM/RaspberryPi
<Kamilion> i knew there was a minimal 16.04 image stashed somewhere
<both> Kamilion: oh, thx :)
<Kamilion> https://wiki.ubuntu.com/ARM/RaspberryPi/RaspberryPi3   reading this tells me pi3 support is still a little broken
<Kamilion> pi2 should be fine though.
<Kamilion> http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/ubuntu-16.04-preinstalled-server-armhf+raspi2.img.xz
<both> I'll try later today.
<Kamilion> says it's 4GB
<Kamilion> so if you're unpacking onto an 8GB card; be sure to run resize2fs on it
<tsimonq2> o/ Kamilion
<qengho> I think the image will resize itself on first reboot.
<qengho> Doesn't the boot config have something else? /me shrugs.
<trijntje> I'm trying to create a snap for an existing java app, so I just have a .jar file. What is the correct way to include java in the snap?
<qengho> trijntje: I  plugin: nil, source: ..., stage-packages: [ openjdk-7-jre ]
<trijntje> qengho: I have this now, but it still complains about not having java http://pastebin.com/sKtGxpqV
<qengho> trijntje: Error message?
<dholbach> hey hey
<qengho> trijntje: Your command might be "bin/java $SNAP/something something".
<qengho> trijntje: use  find snap  to learn paths.
<qengho> trijntje: or update your program with what you learn from "find"^.
<trijntje> qengho: $ archaeopteryx
<trijntje> /snap/archaeopteryx/x5/bin/archaeopteryx: line 3: java: command not found
<trijntje> qengho: something weird happened, it also put /home/trijntje/snap/archaeopteryx etc into the snap
<trijntje> qengho: if java is properly included in the snap I should be able to use it directly right? Without messing with paths
<trijntje> like here https://github.com/snapcore/snapcraft/tree/master/demos/java-hello-world
<trijntje> I just cant figure out how they tell the snap they want java available
<liuxg> I just found that "snap find" command does not really list all of the available apps for installation. For example, I cannot find "ubuntu-calculator-app" output from the command. However, I can use "snap find ubuntu-calculator-app" to get the result of it. is this a bug?
<iliv> liuxg, if I run that command, I don't see ubuntu-calculator-app
<liuxg> iliv, yes, I do not see the ubuntu-calculator-app as well. By right, it is supposed to show all of the available apps on the system if the "search-term" is empty in the command "snap find <search-term>"
<iliv> liuxg, running "snap find" doesn't show ubuntu-calculator-app either. Why do you think it should?
<liuxg> iliv, that is according to the document at https://developer.ubuntu.com/en/desktop/get-started/, it says: Tip: you can call snap find without a search term to show all apps available to install on your system.
<iliv> liuxg, I mean, why you do you think ubuntu-calculator-app should be displayed in "snap find" output? Maybe it just isn't there? It certainly isn't when I run either "snap find" or "snap find ubuntu-calculator-app" (contrary to your experience where you say "snap find ubuntu-calculator-app" does ...
<iliv> ... show ubuntu-calculator-app as an available package)
<liuxg> iliv, in fact, for me, I can find it by running "snap find ubuntu-calculator-app". I can install it by "sudo snap install ubuntu-calculator-app". I think the app should be available for installation.
<liuxg> iliv, "snap find" should return all of the AVAILABLE snap apps for viewing. this is my understanding. Currently, I can install ubuntu-calculator-app, however, it is not listed there in the command "snap find". this is my point.
<iliv> liuxg, > - Download snap "ubuntu-calculator-app" from channel "stable" (snap not found) // this is what I get when I try to install it. What channel is it on?
<iliv> yeah, it makes sense
<iliv> if you can install it, you should be able to see it in "snap find" output
<liuxg> iliv, I think maybe you have to enable the universe.
<iliv> sounds like a bug report to me :)
<liuxg> iliv, http://imgur.com/2OM6dZM
<liuxg> iliv, do you know what project I should report it to?
<liuxg> iliv, if you know the link, please give me the link for it.
<liuxg> iliv, are you able to install the calculator app on  your system?
<dz0ny_> Is there a public repo with all public snapcraft recipes?
<dz0ny_> demos are great but it feels like I'am reinventing the wheel
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<zyga> o/
<davidcalle> dz0ny_: https://github.com/ubuntu/snappy-playpen
<dz0ny_> davidcalle: thx
<liuxg> dholbach, I can install the ubuntu-calculator-app, however, I cannot find it by using "snap find" command? is this a bug? if yes, what project should I file to?
<davidcalle> dz0ny_: no :)
<davidcalle> np* !
<dholbach> liuxg, I don't know - it could be... check http://bugs.launchpad.net/snappy
<dholbach> liuxg, maybe it's a store-thing too - maybe it just returns just a limited subset of apps(?)
<dholbach> I really don't know
<liuxg> dholbach, do you think this is a bug? Can you duplicate it in your place?
<dholbach> yes, I can see the issue
<liuxg> dholbach, let me firstly file the bug to  http://bugs.launchpad.net/snappy
<dholbach> ok
<hikiko> hello
<hikiko> tsimonq2, here?
<seb128> dholbach, liuxg, I think it's a known store issue
<seb128> it doesn't do substring matching
<seb128> unsure where the store bugs are reported though
<dholbach> seb128, do you know if "snap find" is supposed to show a list of everything?
<seb128> I don't
<seb128> I would expect so though
<dholbach> JamesTait, ^ do you know?
<JamesTait> dholbach, "a list of everything"?  As in, every package in the store?
<dholbach> every available snap for that user (arch, release, channel)?
<JamesTait> I don't know if it's *supposed* to, or if it would be a good idea to, especially when we have more than a couple of hundred snaps, but atm I don't think it does anything with result set size or pagination, so it'll be limited to 100 results.
<tsimonq2> hey hikiko :)
<hikiko> hi tsimonq2 !
<tsimonq2> how are you hikiko? :)
<hikiko> good tsimonq2 and you?
<dholbach> seb128, liuxg: ^ what JamesTait said
<seb128> dholbach, thanks
<dholbach> maybe it'd help to tell the user that there's a limit of 100 results
<liuxg> seb128, dholbach, anyway, I have reported a bug at https://bugs.launchpad.net/snappy/+bug/1602154
<mup> Bug #1602154: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:New> <https://launchpad.net/bugs/1602154>
<mup> Bug #1602154 opened: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:New> <https://launchpad.net/bugs/1602154>
<dholbach> ok, I'll expand on that
<trijntje> I'm trying to create a snap for a java program. I've added java to my snap and it get installed, but for some reason the snap cannot execute java
<trijntje> $ archaeopteryx
<trijntje> /snap/archaeopteryx/x10/bin/archaeopteryx: line 4: usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java: Permission denied
<trijntje> if I cd to the snap dir and run usr/lib/etc etc/java, it runs fine
<trijntje> $ ls -l usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
<trijntje> -rwxr-xr-x 1 root root 6464 Apr 23 10:26 usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
<liuxg> dholbach, JamesTait, I think it would be better to expand it so that we can use "grep" command to find the needed apps
<liuxg> dholbach,  JamesTait, 100 may not be enough. Anyway, currently, it shows 100 results.
<JamesTait> liuxg, tbh I think I'd prefer it if the user had to explicitly opt in to thousands of results, but there may be precedent with, for example, apt - I don't know if that limits the number of results.
<dholbach> JamesTait, it doesn't
<dholbach> I updated https://bugs.launchpad.net/software-center-agent/+bug/1602154
<mup> Bug #1602154: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:New> <https://launchpad.net/bugs/1602154>
<liuxg> JamesTait, dholbach, if I use snap find ubuntu-calculator-app, it returns messy result even though the calculator is inside it.
<tsimonq2> hikiko: great :)
<tsimonq2> hikiko: so what's going on? :P)
<tsimonq2> *:)
<trijntje> can someone help me understand how the java-hello-world demo can call 'java' without including it in the snapcraft.yaml file?
<trijntje> https://github.com/snapcore/snapcraft/tree/master/demos/java-hello-world
<JamesTait> liuxg, I'm not certain which endpoint snapd is currently using for the search, but the reason for the larger-than-expected result set is that it's tokenising the search term and returning all results that match "ubuntu OR calculator OR app" in the package name.
<mup> PR snapd#1528 opened: overlord/devstate: add DeviceManager which checks assertions <Created by wgrant> <https://github.com/snapcore/snapd/pull/1528>
<liuxg> JamesTait, I am thinking it should take "ubuntu-calculator-app" as a whole phrase to search. the searched result is pretty messy now, and make it less useful as it would be.
<mwhudson> zyga: poke
<JamesTait> liuxg, possibly, yes, there's probably room to tweak how we handle searches.  It's a matter of balancing between "I know exactly what package I'm loking for" (in which case why not just use snap install straight off?), "I know roughly what package I'm looking for" (e.g. linux-image-something) and "I don't know what package to install, but I want something that does ...
<JamesTait> ... X" (e.g. snap find vector editor, which would actually probably be a different subcommand and endpoint).
<JamesTait> Oh, already gone.
<dholbach> you could just follow up on the bug report
<JamesTait> Yeah, just doing that.
<dholbach> thanks!
<dholbach> sergiusens, kyrofa: can I exclude files from my snap if a remote part pulls them in?
<zyga> mwhudson: hey
<zyga> mwhudson: no update since yesterday, I'll try to do it today
<Chipaca> dholbach, if there's something untrue on https://developer.ubuntu.com/en/desktop/get-started/, is that a you thing?
<dholbach> Chipaca, yes, I can take care of it
<Chipaca> dholbach, âTip: you can call snap find without a search term to show all apps available to install on your system.â
<Chipaca> dholbach, that is incorrect
<dholbach> yes, that's what we just talked about earlier
<Chipaca> oh?
<Chipaca> ok :-)
<dholbach> https://bugs.launchpad.net/snappy/+bug/1602154
<mup> Bug #1602154: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:In Progress by chipaca> <https://launchpad.net/bugs/1602154>
<dholbach> it's quite confusing for users right now :)
<Chipaca> dholbach, right, I'm coming here from that bug
<dholbach> ah yes, ok :)
<Chipaca> dholbach, commented there, even
<JamesTait> Uh, why is the affected project changing to "Snappy" when I try to change "Software Center Agent" to "Click Package Index"?
<Chipaca> because it's wrong
<Chipaca> it's snappy
<dholbach> thanks Chipaca
<Chipaca> JamesTait, my doing, I suspect (refresh)
<mup> PR snapd#1529 opened: snap: rework the output after a snap operation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1529>
<Chipaca> JamesTait, refresh and read my comment, i'd say
<JamesTait> Ah - will do, once I've taken my wife to hospital.
<Chipaca> JamesTait, ouch?
<Chipaca> JamesTait, take care
<dholbach> JamesTait, all the best!
<hikiko> tsimonq2, I have some problems with lxc
<Chipaca> where is liuxg?
<hikiko> tsimonq2, I tried to run snapcraft cleanbuild before I do a merge proposal
<hikiko> and I see lxc related errors although I am in lxd group
<dholbach> Chipaca, updated the doc - thanks
<Chipaca> dholbach, cheers
<tsimonq2> hikiko: I know this sounds weird, but restart your computer
<hikiko> ! :) let's see (thanks tsimonq2) brb
<ubottu> hikiko: I am only a bot, please don't think I'm intelligent :)
<oSoMoN> Iâm seeing the following audit log when trying to run my webbrowser-app snap confined, any idea what might be preventing the app from starting?
<oSoMoN> Jul 12 10:49:29 bribon kernel: [14714.106636] audit: type=1326 audit(1468313369.337:852): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16316 comm="webbrowser-app" exe="/snap/webbrowser-app/x1/bin/webbrowser-app" sig=31 arch=c000003e syscall=49 compat=0 ip=0x7f606d519837 code=0x0
<Chipaca> oSoMoN, sudo snap install snappy-debug
<Chipaca> oSoMoN, then, sudo snap connect snappy-debug:log-observe ubuntu-core:log-observe
<Chipaca> oSoMoN, then, (sudo) snappy-debug.security scanlog
<Chipaca> oSoMoN, if this is amd64, syscall 49 is bind
<Chipaca> oSoMoN, you probably need "network-bind"
<oSoMoN> chipaca, thanks, thatâs very helpful!
<Chipaca> oSoMoN, snappy-debug's scanlog would've told you this fwiw
<oSoMoN> yes it did, thatâs much easier to understand than the raw seccomp audit log in /var/log/syslog :)
<Chipaca> oSoMoN, if it is that you need network-bind, it's probably because of something wrt dns
<Chipaca> which is a bummer, but we'll get to it at some point
<oSoMoN> that makes sense
<Chipaca> (the bummer is that you shouldn't need network-bind for something that isn't a server)
<oSoMoN> Chipaca, indeed, although in the case of webbrowser-app devtools require server caps, so it was going to be needed anyway
<Chipaca> ah ok :-)
<ppisati> mvo: is u-d-f still the tool to build images?
<ppisati> mvo: it complains about the gadget snap - http://pastebin.ubuntu.com/19158950/
<tsimonq2> hikiko: did that work? :)
<hikiko> tsimonq2, almost :) I now have permissions but I didn't configure the lxd network correctly so I can't connect.. :)
<ppisati> ogra_: ^ maybe you know that too
<mvo> ppisati: it sort of is, can you please try if ubuntu-device-flash-experimental is doing better? in the same dir as u-d-f ? also - do you have the latest binary of u-d-f from my people repo?
<ppisati> mvo: already tried, same problem
<mvo> ppisati: its all a bit in the flux still and u-d-f will be replaced soon (but not just yet)
<mvo> ppisati: aha, ok, I will have a look in some minutes then
<tsimonq2> hikiko: aww okay
<ppisati> mvo: http://pastebin.ubuntu.com/19160179/
<mup> PR snapd#1530 opened: asserts: add cross checks for snap asserts <Created by pedronis> <https://github.com/snapcore/snapd/pull/1530>
<hikiko> tsimonq2, have you ever seen this bug before:
<hikiko> :s/bug/error
<hikiko> $ snapcraft cleanbuild
<hikiko> error: Get https://images.linuxcontainers.org:8443: Unable to connect to: images.linuxcontainers.org:8443
<hikiko> error: not found
<tsimonq2> hikiko: hm weird
 * JamesTait hugs Chipaca for his work on snapd and his comments on the bug.
<zyga> Chipaca: oSoMoN: that thing you are talking about written in Go?
<mwhudson> zyga: ok, good luck finding the time
<mwhudson> zyga: btw, if it helps, maybe push the alioth repo to github, and i can there
<zyga> mwhudson: hmm, I don't own the alioth repo, that's something slangasek did
<mwhudson> zyga: yes, i know, but if you want to get changes into it, push your changes somewhere else and i'll merge them
<mwhudson> zyga: possibly i'm not making much sense
<zyga> ah, I see
<zyga> I'll clone alioth and push it to my personal github and share the link with you
<zyga> iff I get suse packages done today :)
<zyga> though now seeing the end of the tunnel
<mwhudson> +1
<hikiko> mm, could anyone help me configure the lxd container for snappy-playpen to work?
<dpm> good work davidcalle :) https://plus.google.com/u/0/+davidcalle/posts/NCYiHBTyKzL
<oSoMoN> zyga, no, webbrowser-app is written in C++/QML
<trijntje> is it  currently possible to use snappy X11 programs over ssh with X forwarding? I keep getting  "X11 connection rejected because of wrong authentication.",  I guess because snaps run as a different user?
<zyga> oSoMoN: I see
<zyga> oSoMoN: can you get a strace of the app starting? I wonder where it uses bind
<zyga> trijntje: snaps don't run as a different user
<zyga> trijntje: whatever it is, this is not it
<oSoMoN> zyga, let me try to get you this
<oSoMoN> zyga, it looks like strace is not available in snappy-debug (https://bugs.launchpad.net/snappy/+bug/1507693), how do I get a useful strace of my app ?
<mup> Bug #1507693: please add gdb, strace, ltrace, etc to snappy-debug <Snappy:Triaged> <https://launchpad.net/bugs/1507693>
<trijntje> zyga: I can use all 'regular' programs over ssh, but snaps give that error and fail to start
<zyga> oSoMoN: just run sudo strace -f o /tmp/something
<zyga> (on the outside)
<zyga> to run your app
<zyga> my spec files start to look sensible :)
<zyga> https://build.opensuse.org/package/view_file/system:snappy/golang-github-codegangsta-negroni/golang-github-codegangsta-negroni.spec?expand=1 :)
<oSoMoN> zyga, but that will run my app as root, which results in all sorts of unrelated problems
<zyga> oSoMoN: but should give you a strace
<zyga> oSoMoN: you can even run sudo strace su -u $(id -u) your app
<oSoMoN> zyga, http://pastebin.ubuntu.com/19164311/
<oSoMoN> not seeing any call to bind though
<zyga> oSoMoN: did you call strace with -f
<oSoMoN> ah, no
<zyga> :-)
<oSoMoN> zyga, http://pastebin.ubuntu.com/19164556/
<oSoMoN> now IÂ did, and the source of the call to bind becomes obvious
<zyga> :-)
<zyga> nice, I see it too
<oSoMoN> webbrowser-app uses a unix socket to ensure thereâs only one single instance of the app running at any given time
<mup> PR snapd#1505 closed: store: introduce a search grammar (baby step #1) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1505>
<mvo> ppisati: oh, please try "ubuntu-device-flash core 16" instead of core rolling
<mvo> ppisati: sorry that I did not spot this earlier
<zyga> I'm sending first pull requests to SUSE for snapd dependencies :)
<mup> PR snapd#1531 opened: many: present user with a choice of payment backends <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1531>
<mup> PR snapd#1532 opened: release: fix Elementary support <Created by zyga> <https://github.com/snapcore/snapd/pull/1532>
<ogra_> trijntje, ssh adds a local proxy ... looks like the X11 interface simply blocks bits of proxy forwarding here
<ogra_> trijntje, file a bug and add the tag snapd-interface
<ogra_> that will make the security team take a look ;)
<trijntje> ogra_: will do, against the snapd package?
<ogra_> just against the snappy project
<ogra_> https://bugs.launchpad.net/snappy
<trijntje> https://bugs.launchpad.net/snappy/+bug/1602233
<mup> Bug #1602233: "X11 connection rejected because of wrong authentication." when using snaps over ssh <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1602233>
<mup> Bug #1602233 opened: "X11 connection rejected because of wrong authentication." when using snaps over ssh <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1602233>
<mup> PR snapd#1533 opened: many: add authservice to handle user updates to state <Created by matiasb> <https://github.com/snapcore/snapd/pull/1533>
<dpm> mariogrip, when you've got a minute, could you look at replying https://github.com/ubuntu/snappy-playpen/pull/69 ?
<mup> PR ubuntu/snappy-playpen#69: Add octoprint <Created by mariogrip> <Conflict> <https://github.com/ubuntu/snappy-playpen/pull/69>
<dpm> it'd be nice to get it into the playpen :)
<dpm> mariogrip, also on https://github.com/ubuntu/snappy-playpen/pull/76 , rather to block on the rust plugin to be released (unless it's already milestoned for the next snapcraft release), perhaps you want to temporarily ship rust as a local plugin?
<mup> PR ubuntu/snappy-playpen#76: Add iota snap <Created by mariogrip> <Conflict> <https://github.com/ubuntu/snappy-playpen/pull/76>
<ogra> jamiebennett, btw reminder ...... echo "| Bugs: https://bugs.launchpad.net/snappy" >> channel topic
<ogra> :)
<ogra> (i would do it but i'm no op here)
<jamiebennett> ogra: right, maybe we should get you to be an op instead ;)
<ogra> fine as well :)
<jamiebennett> ogra: can you ping asac or popey to make that happen?
<ogra> (not sure who can do that though)
<ogra> ah, sure
<ogra> asac, popey ping :P
<asac> ogra: hi :)
<dpm> ralsina, there's someone trying to snap nikola, perhaps you might want to give them a hand? -> https://github.com/ubuntu/snappy-playpen/pull/72
<mup> PR ubuntu/snappy-playpen#72: Add Nikola <help wanted> <Created by flexiondotorg> <Conflict> <https://github.com/ubuntu/snappy-playpen/pull/72>
<ralsina> dpm: but I already snapped it! :-)
<dpm> ralsina, oh, good work then :)
<ralsina> hahaha
<dpm> ralsina, would you mind adding a note to that PR pointing to your snap, and then we'll close it?
<ralsina> am on it
<dpm> thanks!
<asac> jamiebennett: ogra: no permissions anymore it seems
<asac> check with niemeyer
<asac> cannot op myself for instance :)
<ogra> oh
<jamiebennett> asac: you were on the list, let me see who else is there
<ralsina> dpm: done
<dpm> great, thanks
<asac> jamiebennett: do you see me still there?
<jamiebennett> asac: yes
<asac> jamiebennett: where?
<jamiebennett> asac: on the list IS gave me ;)
<asac> right
<asac> maybe oversight when niemeyer changed channel info
<asac> check with him
<asac> i see him in info as a founder
<jamiebennett> niemeyer was not on the list, strange
<ogra> well, olli| is definitely OP (he did set the current topic)
<jamiebennett> stgraber and slangasek are also there.
<asac> see if anyone can still op
<olli|> jamiebennett, IS can help
<asac> might be just oversight when they changed channel meta info for snapcraft.io
<olli|> ogra, I was op'd by beuno who was op at that time
<ogra> ah
<sergiusens> trijntje java in the java hello-world example lives in PATH, that's why
<jamiebennett> olli|: IS pointed me at the list
<ogra> well, current ops are only popey and niemeyer ...
<popey> hmm?
<ogra> according to "/msg chanserv access #snappy list"
<popey> wassup?
<ogra> popey, can you make me op in here ?
<jamiebennett> (and me)
<jamiebennett> The list is a little stale it seems
<jamiebennett> popey: thanks
<ogra> (i am in the irc council for edubuntu ... funny that i cant OP, seeing the Ubuntu IRC council is op here too)
<popey> probably need yo make it more permanent with flags
<popey> but for now
* ogra changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug
<ogra> yay
 * popey gets back in the pool
<ogra> enjoy
<ogra> and dont get burned !
<trijntje> sergiusens: but how? If I make a wrapper that does 'java bla bla' I get a java not found error
<trijntje> sergiusens: and I cant check that example in /snap because it no longer present in stable, so I cannot test it
<ogra> hmm, i cant get myself onto the actual op list ... "/msg chanserv access #snappy add ogra op" only gets me "You are not authorized to execute this command."
<ogra> so this is only temporary
<flexiondotorg> ralsina, I saw your snapcraft yeterday :-)
<flexiondotorg> What help do you need from me to resolve that conflict?
<ralsina> flexiondotorg: conflict?
<flexiondotorg> ralsina, I had the pull-request for Nikola.
<flexiondotorg> IN the snappy-playpen.
<ralsina> flexiondotorg: well, since the snapcraft in nikola is already upstream and I upload snaps to the store, maybe you can just do PRs on the nikola repo?
<flexiondotorg> OK :-)
<ralsina> flexiondotorg: I noticed our approaches were wildly different :-)
<flexiondotorg> I'll drop my PR to the snappy playpen and contribute upstream.
<ralsina> flexiondotorg: awesome!
<ralsina> Question: does snapcraft allow specifying a channel when uploading a snap?
<dholbach> ralsina, https://bugs.launchpad.net/snapcraft/+bug/1549211
<mup> Bug #1549211: [upload] Allow specifying the release channel  <Snapcraft:Triaged by sergiusens> <Software Center Agent:Fix Released> <https://launchpad.net/bugs/1549211>
<ralsina> dholbach: cool, thx
<ralsina> in the same vein: can I mark an upload as published using snapcraft?
<netphreak> Hi, guys!
<dholbach> ralsina, not that I know of, but maybe Sergio or Kyle know more
 * ralsina really wants to automate both stable and edge snap uploads
<trijntje> does anyone have experience using java in snaps? I've included openjdk-8-jre as a site package, but I get these errors: http://pastebin.com/MtvqV7bf
<ppisati_> sergiusens: i was installing a kernel in a brand new amd64 kvm image when i hit this - http://pastebin.ubuntu.com/19173481/
<trijntje> running it with openjdk-8-jre from outside the snap it runs fine
<ppisati_> sergiusens: havne't touched the snapcraft.yaml in ~2months since it was working back then
<josepht> ralsina: no publish yet
<ralsina> josepht: but it's planned?
<josepht> ralsina: there's a bug for updating snapcraft to match the new upload and publish endpoints
<ralsina> josepht: cool
<netphreak> trijntje: Looks like you are scanning the system for available fonts?
<trijntje> netphreak: I'm not sure, I'm trying to snap an existing program for displaying phylogenetic trees
<netphreak> Can i see your snapcraft.yaml file?
<ogra> ppisati_, 2 months is a long time :)
<mup> PR snapd#1500 closed: many: remove snapstate.Candidate <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1500>
<ppisati_> ogra: eh... :)
<trijntje> netphreak: sure http://pastebin.com/Sbxa6eFd
<trijntje> its my first snap, so any feedback is welcome
<ppisati_> ogra: but it complains about a missing kernel.yaml, i guess something snapcraft should pack in
<ppisati_> ogra: do you know what is talking about?
<ogra> yeah, i would expect so
<ppisati_> ogra: or do you still craft you kernel manually?
<ogra> the official kernels are rolled just by "snapcraft snap $kerneldir"
<josepht> ppisati_: which snapcraft version are you using?
<ogra> wouldnt make any sense to build them differently
<ogra> (since we couldnt use the deb otherwise)
<ppisati_> josepht: 2.12
<ppisati_> ogra: never tried that way
<ogra> souns definitely like an issue with snapcraft
<ogra> ppisati_, well, for your usecases you really dont want that ... for my usecases where i need a signed binnary from the archive it works thoough
<netphreak> trijntje: Looking at your snapcraft.yaml it seems like you are missing a wrapper.. Try looking at this example: https://github.com/snapcore/snapcraft/tree/master/demos/tomcat-maven-webapp
<ogra> ppisati_, i fear you need sergiusens or kyrofa, probably the kernel plugin needs fixing
<ppisati_> kyrofa: ^
<ppisati_> ogra: yep, let's see if they show up
<trijntje> netphreak: isn't "command: bin/archaeopteryx" my version of the wrapper. Or does it need to be named wrapper?
<josepht> kyrofa: is in the middle of moving
<netphreak> trijntje: The example uses a wrapper.sh
<josepht> ppisati_: can I see your snapcraft.yaml?
<ppisati_> josepht: http://paste.ubuntu.com/19175226/
<trijntje> netphreak: but does it matter if it is called 'wrapper' or 'archaeopteryx'?
<netphreak> ahh.. didn't see it was a .sh file..
<netphreak> No don't think it matters.
<netphreak> And it starts correctly when running it with plain java -jar?
<netphreak> same openjdk?
<ogra> trijntje, https://github.com/ogra1/jtiledownloader for inspiration ...
<josepht> ppisati_: can you also give me a link to a kernel repo I can test that with please? :)
<trijntje> netphreak: it even runs like this http://pastebin.com/7spry1CK
<trijntje> so I use both the java and .jar file from the snap, and it runs fine. But if I actually run the snap as intended, I get those errors
<ppisati_> josepht: https://github.com/snapcore/sample-kernels - branch stable-3.10.y
<netphreak> Hmm.. weird..
<ppisati_> josepht: as you can see the snapcraft i posted in pastebinit is slightly different, so replace it
<netphreak> could be some missing interfaces?
<ogra> trijntje, well, take a look at https://github.com/ogra1/jtiledownloader it does exactly the same and works fine ... (it is also in the store already) i guess you want to look specifically at the wrapper
<netphreak> although you are running in devmode
<trijntje> ogra: thanks, that looks exactly like what I want. Is using 'wrapper' a convention for snaps?
<ogra> well, i personally use them a lot to set env vars
<trijntje> netphreak: I'll just try to copy what _ogra has, and see if I still get the problem then
<ogra> but afaik there is a change in the works that allows you t define env vars from snapcraft.yaml
<ogra> so this might be obsolete some day
<netphreak> yup.. :)
<ogra> i think:
<ogra> export JAVA_HOME=$SNAP/usr/lib/jvm/java-1.8.0-openjdk-$SNAP_ARCH
<ogra> export PATH=$JAVA_HOME/bin:$JAVA_HOME/jre/bin:$PATH
<ogra> an
<ogra> d
<ogra> cd $SNAP_USER_DATA
<ogra> are the important bits for you to get the basics up
<ogra> (the rest in my wrapper is mostly themeing, since i dont like that win95 look)
<sergiusens> ogra ppisati_ I have not kept up with the core changes to kernels, was only going to look into it once it was final but don't mind patches
<trijntje> Its building now. I missed the $SNAP_USER_DATA part, I guess thats in the users home dir where a snap can store its files?
<ogra> yep
 * sergiusens is distracted writing a bazillion tests for simple code changes
<sergiusens> I might take a while between replies
<ppisati_> it seems that file should only contain the kernel version:
<ppisati_> ubuntu@localhost:~$ cat /snap/canonical-pc-linux/30/meta/kernel.yaml
<ppisati_> version: 4.4.0-23
<trijntje> ogra, netphreak: I get the exact same error. snapcraft.yaml http://pastebin.com/W6k90K1Z
<trijntje> wrapper http://pastebin.com/qLEyuZAx
<mup> PR snapd#1524 closed: classic: remove (most of) "classic" mode, this is implemented as a snap now <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1524>
<mup> PR snapd#1526 closed: Interfaces: Builtin: add pluggable storage interface <Created by ssweeny> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1526>
<dholbach> sergiusens, kyrofa: http://askubuntu.com/questions/797031/how-do-you-exclude-files-from-wiki-part-used-in-snapcraft-yaml is basically what I meant
<roadmr> jdstrand: so, c-r-t 692 is now live on the store (as of yesterday) - sorry for the delay!
<sergiusens> dholbach no one reads my blog :-p
<dholbach> sorry, taking a look now
<sergiusens> dholbach nah it is fine
<sergiusens> I can reply to that
<dholbach> thank you!
<joc_> zyga: if i want to test an in development interface but need my custom snapd to run at boot what are my options?
<ogra> trijntje, why -cp ... did you try -jar ?
<zyga> joc_: at boot?
<zyga> joc_: hmmm, your options are to rebuild the core snap
<ppisati_> ok, repackaging the snap with a meta/kernel.yaml file containing only the string "version: $VERSION" fixed it
<zyga> joc_: (I assume this is about an all-snap device)
<joc_> zyga: yep
<joc_> zyga: are there instructions/scripts anywhere for building the core snap?
<zyga> joc_: if you can come up with an idea then you can patch refresh-bits
<zyga> joc_: ask ogra, those that I know about are probably stale
<zyga> joc_: one thing you can do is to add something to initrd
<zyga> joc_: to create a fake core snap that has symlinks for the essential binaries
<ogra> just download the core snap ... unsquashfs ...
<ogra> make changes
<zyga> joc_: sothat you can put them into writable space
<zyga> joc_: and iterafe quickly
<ogra> run snapcraft snap $unpackdir
<netphreak> how often does snapd check for snap updates?
<zyga> netphreak: look at snapd.refreshtimer
<zyga> netphreak: look at snapd.refresh.timer
<zyga> netphreak: it is in the snapd package
<netphreak> thx
<zyga> netphreak: the answer is: complicated :)
<joc_> thanks ogra, that sounds like a reasonable solution for my purposes
<netphreak> hehe
<ogra> joc_, dont spread it ;) we dont want everyone to just randomly change it :)
<joc_> :)
<dz0ny_> how do you specify different settings per platform(device)
<dz0ny_> for example ffmpeg need different build params for rpi than x86
<dz0ny_> create new package? or there is other way
<ogra> how would you do it if you were in a non snappy env ?
<dz0ny_> in go i would use tags :)
 * ogra would have a toplevel makefile and use uname -m or some such to switch them
<ogra> then use tags ;)
<dz0ny_> :)
<dz0ny_> uname it is
<dz0ny_> qq are env variables reflected to the build?
<dz0ny_> or it is a pristine env?
<ogra> depends on the plugin :)
<dz0ny_> so plugin can inject env variables?
<dz0ny_> if that's true, then problem solved
 * ogra always uses the mak plugin and just does the variables in a makefile script
<dz0ny_> I see it now https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/go.py#L98 :)
<mup> PR snapd#1534 opened: tests: add system-observe interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1534>
<ogra> sergiusens, hmm, could we put some size restriction on remote parts descriptions or add a --linewrap option to teh search command  ? "snapcraft search" actually requires my terminal to be full screen on a 1080p monitor to read the end of the descriptions for all of didrocks desktop helpers
<ogra> (and if i make it any smaller it lust gets ellipsized)
<la_juyis> hi o/
<la_juyis> source for a part can't be ftp?
<ogra> i dont think anyone has needed that yet ... file a bug :)
<la_juyis> :)
<la_juyis> done
<ogra> cool
 * la_juyis searches for another thing to snap
<ogra> well, use the makeplugin and put the ftp command into a makefile to work around the issue ;)
<la_juyis> let's try inkscape, hoping it not too much of a trouble
<la_juyis> ogra :O hm...
<la_juyis> might try that :)
<la_juyis> thanks!
<mup> Bug #1602323 opened: source for a part can't be ftp <Snappy:New> <https://launchpad.net/bugs/1602323>
<ogra> la_juyis, https://github.com/ogra1/laidout/blob/master/Makefile like that
<ogra> (also see the snapcraft.yaml next to this)
<la_juyis> awesome :)
<iliv> I get this error message from initdb: initdb: invalid locale settings; check LANG and LC_* environment variables
<iliv> I tried to export LANG= in my wrapper script but that didn't help
<iliv> what is LANG= in the sandbox? or is there one at all by default?
<iliv> I installed this package in --devmode
<zyga> iliv: I bet this is related to the missing locale inside your snap
<ogra> there are no locales in the env .. so set it to LANG=C or C.UTF-8
<ogra> then the error goes away
<iliv> okay. how would I install locales?
<ogra> iliv, put locales and libc6-bin in your stage-packages and put the right vars into your wrapper ... https://github.com/ogra1/nethack is an example
<iliv> ogra, is C.UTF8 the same as en_US.UTF-8? if not, I need to figure out a way to get en_US.UTF-8 working in the sandbox.
<ogra> no, C is the fallback locale ... i think it is very close to en_US ... but not 100%
<iliv> I see. Thanks for the link.
<ogra> anyway, if it is just locales you can follow the nethack example above ... if gettext is involved it ges a lot trickier
<ogra> *gets
 * iliv suspects a lot trickier is what's in store -_- 
<iliv> but okay let me add stage-packages and see what happens...
<ogra> you also need to set up the wrapper correctly
<iliv> export LANG= ?
<iliv> or it gets a lot trickier than that? :P
<ogra> look at the nethack.sh script
<ogra> (it generates the locale on startup)
<iliv> I see
<iliv> Interesting
<_jaymell> Hi. I'm wondering if there are any plans, or if it's currently possible, to add the ability to customize systemd unit files for snap services... eg, adding custom environment variables
<ogra> _jaymell, bug 1583259
<mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <Canonical Click Reviewers tools:Fix Committed by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <https://launchpad.net/bugs/1583259>
<ogra> in the works
<_jaymell> Thanks, I appreciate the link
<pmp> we are currently in dev-mode for our snap
<pmp> our applicatation is doing a lot of syscalls (1000-1200/sec)
<pmp> for each of them apparmor is printking things
<pmp> is there a simple way to deactivate its verbosity?
<pmp> (the problem is, that our applicaiton is relying on a realtime-cadence and we suspect that printk is breaking the flow)
<pmp> (or worse, it is apparmor's checks which are slowing down things)
<tyhicks> pmp: can you paste an example of one of the log messages?
<tyhicks> (maybe one of the more commonly seen denial messages would be good)
<pmp> all of them are =ALLOW because we are in devmode
<pmp> I don't have a message at hand, it is the standard audit-messages when a snap is doing something which would normally be denied
<tyhicks> pmp: it would still be helpful to see what the application is doing that would cause the denial
<pmp> open, read etc on /sys and /dev-nodes
<pmp> mostly iio
<pmp> but also custom device-nodes
<tyhicks> pmp: do you want a bandaid workaround to stop the messages temporarily on your system or are you looking for a more permanent solution?
<pmp> a temporary solution would be OK
<pmp> we have some realtime-problems when reading sensors and we suspect the quantity of synchronous audit-messages to be the root-cause
<tyhicks> pmp: you could copy the apparmor profile in /var/lib/snapd/apparmor/profiles/snap.* to /tmp/, then modify the profile in /tmp/ by adding "  file," just before the closing '}', and then run `sudo apparmor_parser -rC /tmp/snap.PROFILE`
<tyhicks> pmp: let me know if that doesn't work and we can try some other things
<ppisati_> sergiusens: where can i find snapcraft.yaml::version field? i mean, which object contains that string?
<pmp> tyhicks: file would be the filename to be accessed?
<tyhicks> pmp: no, it is a rule that says all file accesses should be allowed
<tyhicks> pmp: the last two lines in the profile will look exactly like this:
<pmp> tyhicks: thanks, we will try
<tyhicks>   file,
<tyhicks> }
<tyhicks> pmp: there may be one other option but I'll need to dig through some documentation - be sure to stick around for a bit
<pmp> tyhicks: feel free to comment on #1596515 with this "file" workaround - if it works ;-)
<mup> Bug #1596515: IIO access and configuration from a snap <apparmor> <iio> <snapd> <snapd-interface> <Snappy:Triaged> <https://launchpad.net/bugs/1596515>
<tyhicks> pmp: my other idea didn't pan out so hopefully the file trick works for you
<ysionneau> tyhicks: but audit still says apparmor="ALLOWED" , right?
<tyhicks> ysionneau: not if the profile allows the file access
<tyhicks> ysionneau: apparmor="ALLOWED" indicates that the profile would block the access if the profile were in enforcing mode
<tyhicks> ysionneau: we're allowing all file accesses by adding "  file,"
<ysionneau> ok thanks!
<ysionneau> is there a way to say ubuntu-core-launcher to *not* put seccomp and/or apparmor protection at all?
<ysionneau> instead of putting apparmor profile + putting it in complain mode
<ysionneau> I'm guessing no, but asking anyway =)
<pmp> tyhicks: ( ysionneau and I are working on the same project/problem, fyi)
<tyhicks> ysionneau: yes but you have to rebuild snap-confine
<tyhicks> pmp: good to know
<ysionneau> snap-confine ?
<ysionneau> what is it?
<ogra> not released yet
<ogra> the new way of doing confinement :)
<tyhicks> ysionneau: ubuntu-core-launcher is renamed to snap-confine but you can ignore that detail
<sergiusens> ogra if you see ppisati any time soon tell him we have a bug for exposing version, should be coming soon
<ogra> sergiusens, i'll probably see him the same time as you ;)
<ogra> in heidleberg
<ogra> (but yeah, jokes aside, i will tell him if he is around on IRC)
<ysionneau> ah ok good to know tyhicks
<davmor2> JamesTait, and guys interesting issue if you type snap find clock it shows ubuntu-clock-app and ubuntu-calculator-app (not sure why on the last) if I type in ubuntu-clock-app it finds everything
<davmor2> JamesTait: even more interestingly gnome-software shows nothing for ubuntu-clock-app and if I type in clock it shows me every clock app except the ubuntu-clock-app :D
<JamesTait> davmor2, `snap find clock` returns calculator because its description is: "This is currently a proof-of-concept for the phone Calculator app packaged as a snap package for Unity 7. As such, it's not production-ready and has not the full functionality as the current clock ap on the phone.\r\n"
<JamesTait> davmor2, Chipaca has some work in progress that will alleviate that, by not searching the extra fields, only the package names.
<JamesTait> davmor2, when you say "if I type in ubuntu-clock-app it finds everything" I don't believe you. ð  Everything?
<JamesTait> I get 27 results.
<davmor2> JamesTait: okay not every thing but it is still a hell of a lot :D
<mup> PR snapcraft#647 opened: add a link for filing bugs/issues <Created by dustinkirkland> <https://github.com/snapcore/snapcraft/pull/647>
<JamesTait> davmor2, if that's what you're seeing, Chipaca's work will alleviate that as well.
<JamesTait> Searching for `ubuntu-clock-app` breaks down to `ubuntu OR clock OR app` in title, description, keywords or summary field.
<davmor2> JamesTait: stupid search ;)
<JamesTait> Nope: phone-focused search with snap CLI support retrofitted.  Really the client is using the wrong search functionality atm, but that's because the right functionality is very new. âº
<JamesTait> The gnome-software behaviour is more interesting to me.
<JamesTait> davmor2, is that actually gnome-software, not "Ubuntu Software"?
<JamesTait> davmor2, and if so, can you see other snaps?
<JamesTait> Asking because on my Xenial system, in Ubuntu Software, I get behaviour consistent with "snap find" when searching for "ubuntu-clock-app", and ubuntu-clock-app is the first hit if I just search for "clock".
<aatchison> Good morning all
<aatchison> I've looked around a bit, but I can't figure out how to upload my yaml to launchpad for builds?
<aatchison> or is that even a thing? :D
<sergiusens> aatchison hey! you need to push to a repo you have on launchpad
<aatchison> hello
<sergiusens> aatchison if you are using github, just create a launchpad project and push that clone there
<aatchison> ok, a bazzar repo?
<sergiusens> elopio https://github.com/snapcore/snapcraft/pull/648
<mup> PR snapcraft#648: Implemented `snapcraft release` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/648>
<aatchison> oh, ok!
<sergiusens> aatchison it can be git
<aatchison> thanks again
<sergiusens> aatchison or if you some sense of automation, there's a bzr git importer thing you can setup when creating a new project
<mup> PR snapcraft#648 opened: Implemented `snapcraft release` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/648>
<aatchison> cool! Is it tied to releases or just master. I guess I can take a look right now
<sergiusens> aatchison I have not used it in a while so don't really know
<aatchison> ok, no biggie :)
<mup> PR snapd#1535 opened: overlord: switch snapstate.Update to use ListRefresh (aka /snaps/metadata) <Created by pedronis> <https://github.com/snapcore/snapd/pull/1535>
<aatchison> hmm, not sure what I did correctly or incorrectly here: http://paste.ubuntu.com/19199832/
<aatchison> I imported a github repo, and clicked build a snap :D
<aatchison> I have basically no experience with launchpad, so bears with me
<aatchison> http://launchpadlibrarian.net/272616649/arron-atchison-snapcraft-mimic-snapcraft-mimic.log
<aatchison> It seems it is unable to import my code. I'll check again
<mup> PR snapcraft#649 opened: Use '/usr/bin/env python3' <Created by josepht> <https://github.com/snapcore/snapcraft/pull/649>
<aatchison> ahh, I figured it out. Savvy me!
<sergiusens> great
<monsterjamp> So I keep getting this error when trying to make a snap: multiple repeat at position 36
<monsterjamp> Is it my fault or is snapcraft buggy?
<dz0ny_> lol https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<dz0ny_> how the hell do i run this generated package
<dz0ny_> 'just thought'
<mup> PR snapcraft#642 closed: Make maven plugin honour https_proxy and proxy authentication <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/642>
<mup> PR snapcraft#646 closed: Feature/gradle plugin <Created by ZenHarbinger> <Conflict> <https://github.com/snapcore/snapcraft/pull/646>
<kgunn> jdstrand: hey you around to discuss your last review of my PR ?
<kgunn> might be faster on irc or hangout vs git ping-pong
<mup> PR snapcraft#636 closed: parser - Handle malformed wiki entries <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/636>
<mup> PR snapcraft#589 closed: Add the test for the downloader snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/589>
<mup> PR snapcraft#634 closed: Run the parser integration tests with debug flag <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/634>
<mup> PR snapcraft#638 closed: Wishlist feature/maven-targets branch for snapcraft <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/638>
<mup> PR snapcraft#650 opened: feature/maven-targets w/ re-based maven.py <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/650>
<monsterjamp> How can I force install a snap?
<mup> PR snapcraft#609 closed: Create Plainbox Provider plugin <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/609>
<monsterjamp> I can't install snappy-debug :(
#snappy 2016-07-13
<monsterjamp> Anyone know how to force install snap? Snap still thinks snappy-debug is still installed, but it's not. So I can't reinstall.
<mup> PR snapcraft#648 closed: Implemented `snapcraft release` <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/648>
<mup> PR snapcraft#649 closed: Use '/usr/bin/env python3' <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/649>
<tsimonq2> sergiusens: thank you for taking the time to look over my PR, I really appreciate it :)
<mup> PR snapcraft#644 closed: Feature/ant plugin test <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/644>
<mup> PR snapcraft#646 closed: Feature/gradle plugin <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/646>
<mup> PR snapd#1536 opened: tests: stop using hello-world.echo in the tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1536>
<dz0ny_> morning
<dz0ny_> is there a way to lock source for each part to specific commit?
<dz0ny_> something like github.com/prokject/repo.git#v1.24?
<tsimonq2> you mean a specific tag?
<tsimonq2> if so, we have source-tag
<dz0ny_> yep
<dz0ny_> master is not stable :)
<dz0ny_> well in most cases or whatever repo defaults
<trijntje> I'm trying to create my first snap, but I have this weird problem where all the parts of the snap appear to work, but using the snap itself gives a bunch of java errors
<trijntje> http://pastebin.com/Tcy8KvyX
<qengho> trijntje: Anything in "dmesg"?
<qengho> trijntje: put "set" in your wrapper to see if the environment you have is what you expect.
<trijntje> also, I get a java crash error when I install it using devmode http://pastebin.com/AniwGkBp
<trijntje> qengho: as far as I can tell it only shows apparmor allowing the snap: http://pastebin.com/YJSmPVzf
<qengho> trijntje: I see fonts in the name in that crash. Do you have fonts installed in your snap?
<qengho> "fc" is probably fontconfig, too.
<trijntje> qengho: I don't. I tried asking about the errors in #java since I'm not a java programmer, but they said my java install was broken
<qengho> It is broken. You don't have fonts installed. If you don't put it in the snap, it doesn't exist.
<qengho> trijntje: You should run your program normally under "strace -f -e trace=file -o ~/trace ....", and see what font files it touches, and then "stage" the packages that provide those fonts. That will probably fix it.
<trijntje> they thought that ubuntu messed up java to the point that it didn't contain any GUI code at all
<trijntje> they explicitly said it wasn't a font problem, but ill give strace a go to be sure. I don't think they wanted to help to be honest
<qengho> That "strace" will tell you a lot. Use "dpkg -S $filenamementionedinstrace" to map back to package names that could be in your snapcraft.yaml .
<qengho> trijntje: Also add to your wrapper,
<qengho> # Font Config
<qengho> export FONTCONFIG_PATH=$SNAP/etc/fonts/config.d
<qengho> export FONTCONFIG_FILE=$SNAP/etc/fonts/fonts.conf
<dholbach> hey hey
<pbek> *wave*
<qengho> 'sup.
<dholbach> hey pbek
<pbek> good moring, dholbach ^_^
<dholbach> how are things? :-)
<hikiko> hello people :) I have a problem with snappy playpen...
<dholbach> hikiko, what is it?
<tsimonq2> hello hikiko :)
<hikiko> dholbach, I made my first snap and snapcraft cleanbuild returns this error: http://pastebin.com/HEDwtuzD
<hikiko> hi tsimonq2 :)
<hikiko> how are you?
<pbek> dholbach: testing, testing... :)
<dz0ny_> hm is it possible that snapcraft is picking up deps from host?
<dz0ny_> ld deps
<tsimonq2> great hikiko, 2:30 AM, just about to go to bed ;)
<hikiko> wow
<tsimonq2> so night :P
<dholbach> hikiko, I don't know what to do about it - it was asked here: http://askubuntu.com/questions/787258/internal-server-error-when-retrieving-files-from-the-archive-in-lxd
<dholbach> good night tsimonq2
<tsimonq2> night dholbach :)
<hikiko> tsimonq2, time to get some rest! :) what are you doing here!!
<hikiko> good night!
<pbek> sleep well, tsimonq2 ;)
<trijntje> qengho: strace found that the program accesses 3500 files with 'font' in the path
<hikiko> dholbach, I had similar issues in the past when I was trying to apt-get update from those repos I had to use mirrors
<hikiko> dholbach, is it possible to change archive.ubuntu.com.. to uk.archive or de somehow?
<trijntje> I'm feeding them to dpkg -S automatically now, lets see how many packages we end up with
<pbek> tzzzz, sourceforge is down, bad if source files are hosted there for the snaps... :/
<liuxg> dholbach, ping
<dholbach> liuxg, pong
<dholbach> hikiko, does --enable-geoip work there?
<hikiko> this will use my country's mirror right?
<dholbach> try it - it's the only idea I have right now
<hikiko> ok :) thanks dholbach!!
<hikiko> dholbach, the syntax should be: snapcraft cleanbuild --enable-geoip?
<liuxg> dholbach, today, I met a very strange problem. I have a snap app at https://github.com/liu-xiao-guo/rssreader_snap. if I add "network" into the plug, I do not have any AppArmor warnings, but the app does not get up (no UI). If I remove "network" into the plug, the app can be running, but with an error/warning like http://paste.ubuntu.com/19253339/.
<dholbach> I don't know - maybe it just works with "build"?
<dholbach> liuxg, I have never heard of anything like this before
<liuxg> dholbach, the UI of the app is documented at http://blog.csdn.net/ubuntutouch/article/details/51894469
<dholbach> liuxg, which other plugs does it use?
<dholbach> liuxg, does "snappy-debug.security scanlog" say anything if you start the app?
<liuxg> dholbach, you may find it at https://github.com/liu-xiao-guo/rssreader_snap/blob/master/snapcraft.yaml
<liuxg> dholbach, do I need to run it separately in another terminal after the app is running?
<dholbach> separately in another terminal and start it before you start the app
<liuxg> dholbach, OK. I will do it. what pacakge should I install for snappy-debug.security?
<dholbach> snap install snappy-debug
<liuxg> dholbach, OK. thanks
<mup> PR snapd#1537 opened: tests: add env command to test-snapd-tools <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1537>
<liuxg> dholbach, http://paste.ubuntu.com/19253833/, this is the message.. I do not know how to interpret it
<dholbach> liuxg, maybe it needs "network" and "network-bind"?
<dholbach> I'm just guessing
<dholbach> I'm not an expert on this one
<hikiko> dholbach, that solved my issue but now I have a new one... (sorry) I have some compile errors, what can I do in this case? fix them send the patch to the developers and try again in a few days? They forgot to include a file somewhere...
<dholbach> hikiko, or push to your own branch for now and use that as a basis for building
<liuxg> dholbach, in fact, it is just a rss reader app. I did not use it to pull any data yet (just use local static images).  The app works well for the phone.
<dholbach> (and at the same time get them to include it if it's a more general issue)
<hikiko> dholbach, what is preferable?
<dholbach> liuxg, I have no idea - try it
<dholbach> hikiko, I don't know how that particular project operates, but I would send the patch (or PR or whatever they use) and use a local branch for continuing to snap - that way you don't get blocked for a few days waiting for an answer
<hikiko> hexchat
<liuxg> dholbach, the thing is that if I add network, the UI does not show up at all.. Anyway, I will try to add network-bind to see how it goes.
<hikiko> ok :)
<hikiko> thanks dholbach
<dholbach> anytime
<mup> PR snapd#1538 opened: snap-exec: fix silly off-by-one error <Created by mvo5> <https://github.com/snapcore/snapd/pull/1538>
<mup> PR snapd#1537 closed: tests: add env command to test-snapd-tools <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1537>
<mup> PR snapd#1539 opened: tests: improve snap run symlink tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1539>
<mup> PR snapd#1536 closed: tests: stop using hello-world.echo in the tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1536>
<mwhudson> zyga: https://launchpad.net/ubuntu/+source/snap-confine
<mwhudson> jamiebennett, mvo: https://launchpad.net/ubuntu/+source/snap-confine has 1.0.36-1 now
<mwhudson> jamiebennett, mvo: want me to tack ~16.04 on the end of the version number and upload it to the xenial queue?
<zyga> mwhudson: I'm doing 1.0.36.1 now :/
<mwhudson> zyga: ok
<mwhudson> zyga: i made some packaging changes beyond what is in master btw
<mwhudson> (renaming the apparmor profile to usr.lib.snapd.snap-confine mostly)
<zyga> mwhudson: thanks for doing that
<zyga> mwhudson: do you have an idea on how I could use debian packaging in spread tests?
<mwhudson> zyga: how do the spread tests work?
<zyga> mwhudson: look at spread.yaml and spread-tests/**/task.yaml
<zyga> mwhudson: you have a pre/post/execute script
<mwhudson> zyga: but i guess git-recipe-builder or something?
<zyga> mwhudson: you allocate some VMs
<zyga> mwhudson: send all the code there
<zyga> mwhudson: and run the scripts
<mwhudson> zyga: spread.yaml where?
<mwhudson> oh, master
<mwhudson> (was in debian branch)
<zyga> yep, sorry
<mwhudson> zyga: for the package building stuff, basically you want a launchpad git recipe i think
<mwhudson> take one git tree, transplant debian/ from some other git tree into it (that's https://launchpad.net/git-build-recipe)
<mwhudson> then some fluff around guessing where the upstream tarball is or making it into a native package
<mwhudson> can't remember where that code is
<mwhudson> but cjwatson will know :)
<cjwatson> git-build-recipe
<cjwatson> oh, you already mentioned that
<cjwatson> what code are you looking for?
<cjwatson> all the upstream tarball etc. stuff is in git-build-recipe too ...
<cjwatson> there's a tiny bit of glue in lp:launchpad-buildd (buildrecipe) to call it with suitable arguments
<mwhudson> cjwatson: ah ok, good to know
<mwhudson> zyga: use git-build-recipe, problem solved!
<zyga> mwhudson: yep, I'll try to do that
<mwhudson> zyga: this is a recipe that's a bit like the sort of thing you're doing, fwiw https://code.launchpad.net/~gophers/+recipe/golang-tip
<dholbach> sergiusens, can you reply to http://askubuntu.com/questions/797031/how-do-you-exclude-files-from-wiki-part-used-in-snapcraft-yaml# later on?
<dholbach> ^ or anyone else really
<mwhudson> hey so it looks like snapd autopkgtests now fail because "snap install hello-world" doesn't provide hello-world.echo any more
<mwhudson> is that plausible?
<mwhudson> false alarm, maybe
<zyga> mwhudson: should be unlikely, maybe PATH does not contain /snap?
<sborovkov> Hello. How do I make image that will use custom store instead of the stock one?
<mup> PR snapd#1540 opened: spread.yaml, tests: replace hello-world with test-snapd-tools <Created by fgimenez> <Conflict> <https://github.com/snapcore/snapd/pull/1540>
<hikiko> dholbach, ping :)
<hikiko> I've fixed my snap
<dholbach> hikiko, pong :)
<dholbach> awesome
<hikiko> but
<hikiko> I am not sure I am using git correctly :p
<hikiko> dholbach, does git push fork master updates my pull request as well?
<hikiko> it seems so
<dholbach> yes, https://github.com/ubuntu/snappy-playpen/pull/171 (and https://reviewable.io/reviews/ubuntu/snappy-playpen/171#-) look like it :)
<mup> PR ubuntu/snappy-playpen#171: Add hexchat snap <Created by hikiko> <https://github.com/ubuntu/snappy-playpen/pull/171>
<hikiko> ok :) sorry it's a bit messy, it's my first snap :)
<dholbach> no worries
<dholbach> take all the time you need :)
<hikiko> dholbach, should I add all the packages that are in build-depends of apt-cache show
<hikiko> :s/show/showsrc
<dholbach> yep, it should be a good start
<dholbach> if we want we can still trim down the list of build-packages later on
<hikiko> and for example some packages have a version like:
<dholbach> if you want to test the build in lxd locally, you can try "snapcraft cleanbuild"
<hikiko> debhelper (>= 9.0.0)
<dholbach> drop the version - snapcraft has no equivalent of this - it will use whatever is in xenial right now
<hikiko> yeah that was my question :D
<dholbach> debhelper (just as an example) is likely not required
<hikiko> ok let me fix it :) thanks a lot dholbach
<dholbach> thank YOU!
<joc_> zyga: after i've used devtool refresh-bits i often end up in a situation where i can't run the original snapd again, i think because original snapd quits with "error: cannot downgrade: snapd is too old for the current system state" - is there any way to force this downgrade?
<zyga> joc_: you could backup and restore /var/lib/snapd/state.json
<joc_> zyga: so make a backup after a fresh install and use that in future to downgrade?
<zyga> joc_: perhaps tie this into setup and restore steps?
<joc_> yeah, could be useful
<sborovkov> Hi. Is it possible to make system journal log to tmpfs instead of disk?
<sborovkov> on snappy on rpi
<mup> PR snapd#1538 closed: snap-exec: fix silly off-by-one error <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1538>
<mup> PR snapd#1535 closed: overlord: switch snapstate.Update to use ListRefresh (aka /snaps/metadata) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1535>
<Sweet5hark> hmmm, so I uploaded an snap to the store in the beta channel, but "snap install --channel=beta libreoffice" does find anything. hints?
<ogra> --devmode ?
<ogra> (might be (falsely ?) implied by beta)
<Sweet5hark> ogra: snap is _not_ devmode anymore
<ogra> Sweet5hark, nope, but the store might require --devmode if you use other channels than stable ... not sure
<Sweet5hark> ogra: soo, uhmm, when I have a confined app in a beta channel we cant install it confined? that sounds very wrong.
<ogra> it definitely installs here with "sudo snap install --channel=beta libreoffice --devmode"
<ogra> yes, thats why i said "falsely" ... definitely a store bug
<Sweet5hark> ogra: meh. that doesnt install the right stuff.
<ogra> i could understand edge to enforce --devmode ... but the staging channel for stable should not need it
<ogra> oh, wait ... that channel might actually be "candidate"
<Sweet5hark> ogra: ah!
<Sweet5hark> ogra: the 5.2.0.2 I uploaded still has "manual review pending"
<ogra> try if candidate works without devmode
<ogra> oh ? it should tell you why
<ogra> in the review details
<ogra> sborovkov, not easily ... we use syslog and the configs are readonly iirc
<Sweet5hark> ogra: I guess someone still needs to look under each bit if there is some even visual basic macro hidden by me there ....
<ogra> oh you evil guy :)
<pedronis> Sweet5hark: Chipaca might help understanding what is happening there, might depend on which snapd version you have as well
<ogra> jokes aside, the erros should usually give you some detailed info
<Sweet5hark> btw that store UI is hugely misleading: it says both "Package status is Published" and "Status: Manual Review Pending" on the same page. :/
<ogra> (on the myapps page that is)
<ogra> Sweet5hark, but for different revisions i guess
<trijntje> my internet isn't that fast, does it make sense to set up a local apt chache server when you build snaps with a lot of stage packages? Or will snapcraft bypass apt proxy settings?
<Sweet5hark> ogra: I dont think its rejected or errored yet. At least "pending" does sound like "you suck" to me. Rather like "Im still looking at all the wonderful bytes you threw over the fence".
<ogra> if you dont use cleanbuild it uses your local sources,.list iirc
<ogra> so if that points to a package proxy the build shoudl too
<ogra> Sweet5hark, well, if you click on the revision you can see it chug along
<Sweet5hark> ogra: hohum, it says "reserved interface 'bluez' for vetted applications only         security-snap-v2_app_plug_safe (libreoffice, bluez)"
<ogra> Sweet5hark, oh, then you need someone to manually approve
<ogra> (i think)
<trijntje> ogra: thanks, I might set up a proxy in that case
<Sweet5hark> ogra: speaking teutonic, this is all bohemian villages to me ;)
<Sweet5hark> ogra: ok, who do I need to get drunk?
<ogra> trijntje, sudo snap install packageproxy ... then point to localhost:9999
<ogra> ;)
<trijntje> qengho: I added 58 font packages to my snap, which were accessed by the app when it runs outside the snap, but i still get the exact same error trace
<ogra> Sweet5hark, i dont really know, beuno was always whom i harassed in that case ... but he is gone ... all others i wiould know are on vacation
<ogra> Sweet5hark, usually popey or jdstrand ... perhaps tyhicks can chime in as security team person to nod it off
<trijntje> ogra: perfect, ill give it a go
<ogra> Sweet5hark, out of curiosity, why does libreoffice need direct BT access ?
<Sweet5hark> ogra: well, I havent tested it yet. but it will need bluetooth in the end for https://play.google.com/store/apps/details?id=org.libreoffice.impressremote
<ogra> ah !
<ogra> yeah, that makes sense (also for physical pointers)
<trijntje> I'm trying to create my first snap, but I have this weird problem where all the parts of the snap appear to work, but using the snap itself gives a bunch of java errors
<trijntje> http://pastebin.com/Tcy8KvyX
<trijntje> dmesg only shows a bunch of apparmor ALLOW lines, and including 58 font packages in the snap did not solve this issue
<ogra> trijntje, sis you try using -jar instead of -cp in your launcher (i think thats what i asked last yesterday)
<ogra> s/sis/did/
<ogra> i thinnk the first one is java itself ... the second error you have is clearly fonts related ...
 * ogra goes for a break
<Sweet5hark> popey, jdstrand, tyhicks: Anyone in for nodding off the libreoffice snap?
<trijntje> ogra: I'll give that a go now, thanks. I must have missed that yesterday
<hikiko> dholbach, when I run snapcraft clean and snapcraft build locally I see no errors and then I push to git and there are still unsolved dependencies :s
<dholbach> hikiko, that's because you very likely have lots of local build-dependencies already installed :)
<dholbach> and the build in travis uses a clean ubuntu container
<dholbach> so you need to specify each and every package in there
<Chipaca> hello hello
<Chipaca> Sweet5hark, what's up
<Chipaca> Sweet5hark, doing a quick scan of the backlog: you have a non-devmode snap in the beta channel that only installs when you specify --devmode?
<Sweet5hark> Chipaca: could you nod off the "libreoffice.canonical" package in the store? it hangs there because of wanting bluez.
<Sweet5hark> Chipaca: https://myapps.developer.ubuntu.com/dev/click-apps/5179/rev/2/
<Chipaca> I don't know what nodding off something is in this context, but I don't have admin on the server so probably no :-)
<Sweet5hark> Chipaca: well, it says "pending manual review", so hmm ...
<ogra> hikiko, you can mimic that behaviour with "snapcraft cleanbuild", that builds locally in a container as well
<hikiko> ogra, I know but cleanbuild fails at downloading because it can't find some repos
<olli|> Sweet5hark, noise][ , ev or maybe jdstrand can help
<ogra> hikiko, oh ?
<Chipaca> Sweet5hark, but what was the thing about beta and devmode?
<hikiko> ogra give me  some time to run cleanbuild and paste the error
<ogra> hikiko, do you use any remote parts like the desktop launchers ? iirc thats a known issue ... repos shoulld be fine though
<hikiko> I pasted it here before but I can't find the link
<hikiko> ogra, maybe, how can I test that?
<hikiko> ogra, it's my first snap I might have done things accidentally...
<ogra> well, you would know if you added something "desktop/..." to your snapcraft.yaml i assume :)
<hikiko> oh no I didn't
<ogra> ah, then it shouldnnt use the launchers that make it fail
<ogra> norml deb repos should just work
<hikiko> ogra, I wonder if the problem is unrelated to snap, because sometimes apt-get update fails as well if I use the original repos instead of mirrors, if I run snapcraft --enable-geoip there's no problem but that's not equivalent to cleanbuild :/
<ogra> yeah, weird
<sborovkov> ogra: meh. So no easy solution? Cause all this writes are going to be killing SD card on RPI very fast.
<ogra> i doubt that, unless you have an app that dos excessive writing
<ogra> (fox that app then :) )
<ogra> *fix
<ogra> usually there isnt much log activity
<sborovkov> App does not do a lot of writing. Devices uptime is 24 hours a day though... And we really want to minimize the writes since Sd cards dying is like the most common issue when using RPI. On raspbian we were just logging to tmpfs. Oh well.
<ogra> when we still had "snappy config" you cuold modify some parameters ... i guess once that feature comes back we will add something for this again ... but i dont know where that stands ... perhaps Chipaca knows
<Chipaca> config is kyrofa these days :-D
<ogra> ah
 * Chipaca leveled up his deflection skills
 * ogra needs to get the wiringin his brain fixed for that evemntually :) 
<ogra> *wiring
<Chipaca> ogra, you have the deflection skills of a horny buffalo :-D
<ogra> lol
<sborovkov> Hello again, How do I build image that uses private store?
<ogra> sborovkov, you mean with a private kernel and gadget ? i dont think you can yet ... ubuntu-image will support that once it replaced ubuntu-device-flash
<ogra> (i know it was possible in 15.04, but not yet for the 16 series due to architectural changes)
<hikiko> https://paste.ubuntu.com/19269020/ ogra
<hikiko> that was the error
<ogra> well
<ogra> 500  Internal Server Error
<ogra> i blame IS
<hikiko> ogra which are the steps of cleanbuild? maybe I can follow them manually
<ogra> or the infrastructure or some such ... that should be a temporary issuue
<hikiko> good news :D
<ogra> instead of "snapcraft" you run "snapcraft cleanbuild" to build  your package :)
<ogra> thats all ... it wll magically create an lxc container and build in there
<nhaines> ogra: oh, that's interesting.  Right now I magically create an lxc container myself and do all my snapcraft thingies in there, then lxc pull the snap out onto my system afterward.  :)
<ogra> nhaines, well, it has its drawbacks ... like remote snapcraft parts doo not work atm
<ogra> (so you cant build anything that uses the desktop launchers)
<ogra> should be fixed with the next snapcraft i think
<nhaines> ogra: slightly disappointing, but luckily I'm just trying (and always failing) to work on a little personal project that only needs debian packages, and also the good news is that there's always a new snapcraft around the corner.  :D
<ogra> yeah, sergiusens is tireless :)
<mup> PR snapcraft#651 opened: Re-based feature/gradle-plugin <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/651>
<nhaines> ogra: do you have any suspicion on when the RPi2 will get an all-snap image?
<ogra> nhaines, not yet, no ... we're waiting for ubuntu-image ... which waits for some snpd and store features in turn
<ogra> *snapd
<nhaines> Okay.  My RPi2 is sitting in its little Ubuntu case, just waiting.  :D  Although it's not a half bad retrogaming machine until then, either.
<nhaines> Full bad desktop machine (Ubuntu MATE is impressive, but mouse lag drives me crazy on any computer.)
<sborovkov> ogra: I mean. I can build custom ones manually. Just need to unsquashsf current one and make changes and squashfs again. We have private store. 'screenly'. I want image in which it's turned on. So I can install snap from there
<ogra> sborovkov, right, as i said, i dont think the 16 series supports that yet ...
<ogra> since it will change the gadget and kernel snaps to use assertions, whichin turn defin the store your image uses
<ogra> (as i understand it)
<sborovkov> ogra: Is it possible to connect to private store from console at least? I can work with that
<sborovkov> Oh
<ogra> ubuntu-image will support tht once it is there ... but currently we are waiting for the store and snapd to have full support for assertions
<liuxg> I have an app with the interfaces at http://paste.ubuntu.com/19270412/. when I run my app, I still get the some errors like http://paste.ubuntu.com/19270507/. However "snappy-debug.security scanlog" does not give me much info at http://paste.ubuntu.com/19270592/ what could the cause of it? thanks
<ogra> liuxg, well, the -control and -manage interfaces obviously arent autoconnect ones, you need to manually connect them
<ogra> (seems -observe too, which i find a bit weird, but it might allow access to the MAc address or so)
<liuxg> ogra, thanks. May I know how to connect them? In fact, the app is just a very simple app, it uses network manager to create a cache. I think network manager might be the one needed..
<ogra> you use snap connect :)
<liuxg> ogra, what I am currently doing is just try to add all of them. after that, I can isolate the problem. where can I find an example for it? I need to do it in terminal, right?
<ogra> calling the command without options gives you an example
<ogra> something like: sudo snap connect foobar:network-control ubuntu-core:network-control
<liuxg> ogra, thanks! I will have a try!
<trijntje> I'm still messing with my first snap, now I'm getting apparmor DENIED in dmesg http://pastebin.com/1BEBRS3G
<trijntje> Even though I believe I have given the snap permission to acces home
<trijntje>         plugs: [x11, network, network-bind, home]
<ogra> trijntje, no dotfiles ... just home data
<liuxg> ogra, many thanks for your help. You are right. now the error disappears. I used the command "sudo snap connect rssreader-app:network-manager ubuntu-core:network-manager" to do it.
<ogra> you need to make sure to point your XDG dirs to the SNAP_USER_DATA dir
<ogra> (i gve you the wrappper of jtiledownloadeer yesterday, didnt i ? that should have the needed vars)
<ogra> liuxg, now the million dollar question ... wh does your rss reader need to manage your network connection ? :)
<ogra> *why
<trijntje> ogra: yes, looking them up now. Thanks for all the hand holding, I'm going to be so happy when I finally get my first snap running
<liuxg> ogra, the source code of the project is at https://github.com/liu-xiao-guo/rssreader_snap
<ogra> trijntje, me too :)
<liuxg> ogra, in the file https://github.com/liu-xiao-guo/rssreader_snap/blob/master/src/rssreader/main.cpp, it uses NetworkManager to create a cache for the app.
<liuxg> ogra, I think normally it should not need that at all
<ogra> wow, weird ... why does it need NM for creating a disk cache
<ogra> yeah
<liuxg> ogra, could you please take a look at MyNetworkAccessManagerFactory::create(QObject *parent) function. it caches the pictures if any during the network connection.
<ogra> i'm really bad at C++, but i can take a look indeed :)
<liuxg> ogra, in phone app, only network is needed. I do not know why it needs to have network manager in the snap app.
<liuxg> ogra, OK. thanks for your help indeed!
<ysionneau> hi
<ysionneau> is it mandatory that the "system-boot" partition be named like this?
<ysionneau> system-boot / writable
<ysionneau> I know that writable is a requirement and the label is used
<ogra> liuxg, well, on the phone there are less fine grained interfaces ... once the phone uses snappy it will be similar
<ogra> ysionneau,
<liuxg> ogra, yeah, I agree with you. that is the ideal situation. the app was orignally a phone app :)
<ogra> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.43+ppa6$ grep system-boot scripts/ubuntu-core-rootfs
<ogra> 	boot_partition=$(findfs LABEL="system-boot" 2>/dev/null || :)
<ogra>                 tmpboot_mnt="/tmpmnt_system-boot"
<ogra> yes ...
<ogra> ysionneau, note that this might change with ubuntu-image though ... not sure if we can keep the partition names wiith that
<arges> are there known issues with snap login not working?
<arges> worked yesterday for me, today not so much
<arges> wierd, stopped my vpn and things work. nevermind
<msvb-lab> A little lost (sorry) but I'm looking for some official collaboration from Canonical for a few forthcoming educational events, workshops. Anyone know who the contact would be for embedded/IoT snappy education?
<ogra> thibautr_, ^^ ?
<ysionneau> ogra: thanks
<pcoca> mvo, Hi Michael!
<pcoca> mvo, I had some issues running the new classic, so I just filed a bug.
<mvo> pcoca: hello, what is the bugnumber?
<pcoca> mvo, #1602693
<mup> Bug #1602693: classic.create error: chroot: failed to run command â/var/lib/classic/enable.shâ: No such file or directory <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1602693>
<ogra> heh
<mvo> pcoca: what version of ubuntu-core do you have installed?
<ogra> just answered
<ogra> you missed switching ubuntu-core to edge
<mvo> pcoca: what ogra said is also my theory
<ogra> (as the version in the bug tells ... i only saw the version after asking :) )
<pcoca> ogra, mvo: thanks!
<mup> PR snapd#1457 closed:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1457>
<pcoca> mvo, ogra, I added the comment and changed to bug to invalid.
<mup> PR snapd#1444 closed: many: allow refresh to locally installed snaps (with data copy) <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1444>
<ogra> pcoca, cool, thanks ("incomplete" would have auto-closed it in 60 days anyway :) )
<mvo> pcoca: your welcome, thanks for testing this new feature, much appreciated
<ogra> +1
<mup> PR snapd#1507 closed: cmd: add buy command <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1507>
<mup> PR snapcraft#651 closed: Re-based feature/gradle-plugin <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/651>
<sergiusens> dholbach answered
<dholbach> thanks sergiusens!
<dholbach> aha!
<mup> PR snapd#1506 closed: store/auth: add helper for the macaroon refresh endpoint <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1506>
<dholbach> sergiusens, should http://paste.ubuntu.com/19276737/ work?
<dholbach> I'm getting this: Issues while validating snapcraft.yaml: The 'parts' property does not match the required schema: Additional properties are not allowed ('desktop/qt5' was unexpected)
<sergiusens> dholbach yeah, you found a bug
<dholbach> thanks sergiusens - shall I file it?
<sergiusens> dholbach in theory, the part/subparts thing was not supposed to be something we end user exposed (it was for dependencies to statisfy the main part)
<sergiusens> dholbach yeah, I guess we need to support it
<dholbach> ok, thanks - I'll file a bug
<dholbach> https://bugs.launchpad.net/snapcraft/+bug/1602728
<mup> Bug #1602728: Redefining elements of remote parts does not work <Snapcraft:New> <https://launchpad.net/bugs/1602728>
<dholbach> thanks
<mup> PR snapd#1541 opened: snap-exec: add proper integration test for snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/1541>
<iliv> hey ogra. wanted to say thanks for pointing me to the nethack in your repository for example of locale installation and initialization. helped me move forward in my work on postgresql package.
<iliv> I'm now looking at this error message:
<iliv> 2016-07-13 15:32:13 GMT [480-1] LOG:  invalid value for parameter "log_timezone": "PST"
<iliv> which I understand now is most likely due to missing timezone, much like the problem with locale
<iliv> I'm wondering if I can get away with just including a tzdata to stage-packages..
<ogra> iliv, there i a "timezone-control" interface your snap could perhaps use (though what you really want is rather something to read the TZ, not to control it)
<ogra> i assumewe are missing an interface here
<ogra> tyhicks, ^^ shouldn't we have a timezone-read interface additionally to -control ?
<tyhicks> ogra: yes, I'd think so
<ogra> iliv, mind filing bug for this?
<iliv> sure. however, I don't know where to do so.
<ogra> see the channell topic :)
<ogra> and add the "snapd-interface" tag to the bug
<ogra> so it shows up in the right list
<iliv> ogra, tyhicks done https://bugs.launchpad.net/snappy/+bug/1602752
<mup> Bug #1602752: Add support for timezone-read interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1602752>
<ysionneau> in the gadget snap, you can specify a set of snaps to be already installed in the generated by UDF ubuntu image
<mup> Bug #1602752 opened: Add support for timezone-read interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1602752>
<ysionneau> can you specify that one snap has to be installed in devmode ?
<iliv> ysionneau, yes, you can use confinement: devmode in snapcraft.yml, which is a per snap configuration setting. you can also use snap install package.snap --devmode
<ogra> iliv, thanks !!
<ysionneau> iliv: how can I set devmode in the snapcraft.yaml ?
<mup> PR snapd#1533 closed: many: add authcontext to handle user updates to state <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1533>
<iliv> ysionneau, add after description: this "confinement: devmode" (without quotes)
<iliv> how does one rebuild a package after adding only plugs in snapcraft.yml without actually rebuilding any of the parts?
<ysionneau> thx iliv
<iliv> ysionneau, be sure to install your package with: snap install package.snap --devmode. I may be wrong but I think you need both confinement: devmode and a package installed with the --devmode flag.
<ysionneau> I know that just snap install --devmode is enough
<ysionneau> but question is, is confinement: devmode enough when it is listed as a package in gadget snap ?
<ysionneau> so that it is automatically installed ... in devmode
<iliv> that is something I'm not really sure about
<iliv> somebody else here should be able chime in and give a better answer
<jacekn> I am trying to create snap for go application that needs "GO15VENDOREXPERIMENT=1" environment variable. How can that be done?
<mup> PR snapcraft#650 closed: feature/maven-targets w/ re-based maven.py <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/650>
<mup> PR snapcraft#637 closed: Do not clean before running the snaps tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/637>
<Croepha> so if I have `daemon: simple` in my app entry, then it should install as a system service when it gets installed right?
<Croepha> jacekn
<Croepha> jacekn: the only way that I know how, is to add a shell script to setup the environment
<Croepha> jacekn: also, I dont know go, but most languages have the ability to set their own environment, for example in python you can do os.environ["GO15VENDOREXPERIMENT"] = "1"   not sure if thats what you want or not
<plars> is it no longer possible to run snap commands from inside a snap? I have a test that is inside a snap, and even something as basic as 'snap list' fails with:
<plars> error: cannot list snaps: cannot unmarshal: json: cannot unmarshal string into Go value of type int
<plars> or is this just a bug in the version of snap it uses? I also noticed that /usr/bin/snap that it sees is different from the one I have on the host system
<plars> or maybe it uses the one from ubuntu-core?
<plars> ah, yes. If I copy the snap binary from the host system, it just works.
<Croepha> do snappy daemons log stdout anywhere?
<Croepha> nvm, found it
<mup> PR snapcraft#613 closed: parser - Don't allow duplicate wiki entries <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/613>
<mup> PR snapcraft#652 opened: Demo/gradle <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/652>
<mup> PR snapcraft#653 opened: Implement `snapcraft push` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/653>
<sergiusens> elopio josepht https://github.com/snapcore/snapcraft/pull/653
<mup> PR snapcraft#653: Implement `snapcraft push` <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/653>
<mup> PR snapcraft#571 closed: Add setuptools tests_require <Created by squidsoup> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/571>
<mup> PR snapcraft#655 opened: Gradle plugin fix for command invocation <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/655>
<luaf> hey there, i just installed snappy core on my raspberry pi. now i have to login but i don't know username nor password :(
<noise][1> luaf: ubuntu:ubuntu if I'm recalling correctly
<Croepha> im considering running core inside of docker, inside of core
<Croepha> core inseption
<Croepha> core inception
<mup> PR snapcraft#656 opened: Use requirements files in travis tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/656>
#snappy 2016-07-14
<mup> PR snapd#1457 opened:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/1457>
<mup> PR snapd#1534 closed: tests: add system-observe interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1534>
<mup> PR snapd#1520 closed: tests: add locale-control interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1520>
<mup> PR snapd#1522 closed: Introduce a simple key-value store for user-specific data <Created by stevenwilkin> <Conflict> <https://github.com/snapcore/snapd/pull/1522>
<mup> PR snapd#1512 closed: overlord: initial work on renaming core snap <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1512>
<trijntje> Good morning all, I'm still strugling with my first snap. If someone could look at it (https://github.com/Redmar-van-den-Berg/archaeopteryx) and the errors I get  http://pastebin.com/PLNdH3yM I would be grateful
<mup> PR snapd#1519 closed: Add Qt5 indicator support in unity7 interface <Created by didrocks> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1519>
<dholbach> hey hey
<tsimonq2> hey hey hey!
<dz0ny> Is that just me https://github.com/ubuntu/snappy-playpen/issues/176
<dholbach> dz0ny, what if you open https://reviewable.io/reviews/ubuntu/snappy-playpen/166?
<dholbach> I agree that reviewable clutters up the normal pull request views
<dholbach> but I feel that it makes it much easier to keep track of what exactly still needs to be resolved in a list of PRs where some get stale and sit there and you never know which one you still need to look at
<dholbach> https://reviewable.io/reviews#- is a very clear overview for me
<dholbach> pbek, https://myapps.developer.ubuntu.com/dev/click-apps/5374/rev/5/ is "ready to publish" - so I guess you need to hit the "publish" button yourself still - just in case if you were wondering
<pbek> dholbach: I totally not saw that button! I just looked at the "published" state at the top. Thanks a lot!
<dholbach> anytime
<dholbach> I'm not sure if you can configure it to auto-publish - I seem to remember there was something like that
<dz0ny> dholbach: butterflies fly around following my mouse and each button hover shows 3 options :)
<hikiko> tsimonq2, hello
<hikiko> mmm I guess is too late for you...
<pbek> dholbach: btw. do you know if I can trigger a snappy build process from the command line on launchpad after I `git push` the snapcraft to the launchpad repo?
<hikiko> dholbach, how do we wrap the description in 80 characters? does a special 80th character does that or just wraping the lines in the text snapcraft.yaml file is enough?
<hikiko> do I need something like \n at the end?
<dholbach> pbek, no idea, sorry
<pbek> thx ^_^
<dholbach> pbek, but you can ask in #launchpad
<pbek> I wanted, but the one who knows everything (you) wasn't online there :D
<dholbach> hikiko, no, just a normal new line - you should be able to just copy/paste what I put in the review at https://reviewable.io/reviews/ubuntu/snappy-playpen/171
<dholbach> dz0ny, I never quite understood that - is that a comment which requires your attention? :-)
<dz0ny> dholbach: do you rly have to click all "eyes" http://i.imgur.com/qiIMeC0.png next to change to make pr "resolved"
<dz0ny> dholbach: also did you delete comments? or where they are?
<dholbach> dz0ny, at the top there's also a "mark as reviewed" button
<dholbach> no, I didn't delete them, they're just folded away ("Resolved - show 4 comments")
<dz0ny> dholbach: where's that button? I only have this http://i.imgur.com/lT9Q3m9.png
<dholbach> maybe it doesn't see you as a reviewer in this PR, that's why it's "mark as reviewed" is greyed out for you?
<dz0ny> :D
<mup> PR snapd#1540 closed: spread.yaml, tests: replace hello-world with test-snapd-tools <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1540>
<commander_> whatsup guys
<commander_> what are ops
<zyga> ?
<commander_> am on xchat and it says 2 ops
<commander_> 2 ops and 242 total
<commander_> snappy and snap are different ?
<commander_> join #ubuntu
<mup> PR snapd#1541 closed: snap-exec: add proper integration test for snap-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1541>
<dholbach> hikiko, can you check the PR again - dpm said network-bind might be necessary as a plug?
<mup> PR snapd#1501 closed: client: existing JSON fixtures uses tabs for indentation <Created by stevenwilkin> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1501>
<hikiko> yes dholbach I didn't finish it I am adding icons too as dplanella said
<dholbach> ok cool
<hikiko> just too many things to learn
<hikiko> thanks for your comments :) +the patience...
<mup> PR snapd#1515 closed: asserts,daemon: cross checks for account and account-key assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1515>
<dholbach> hikiko, thanks for your great work on this!
<dpm> thanks hikiko!
<trijntje> Good morning all, I'm still strugling with my first snap. If someone could look at it (https://github.com/Redmar-van-den-Berg/archaeopteryx) and the errors I get  http://pastebin.com/PLNdH3yM I would be grateful
<dholbach> hikiko, sorry, I meant network-bind as a plug, not as a build-package
<hikiko> oops
<hikiko> sorry dholbach
<hikiko> dholbach, dpm I write a hexchat.desktop file following the qcomicbook example and I was wondering how could I test it works locally? (I still can't run cleanbuild)
<dpm> hikiko, you can just run `snapcraft clean` and then `snapcraft`. That will build your snap
<dpm> hikiko, then install the snap with `sudo snap install *.snap`
<dpm> hikiko, and once it's installed, you can just open the dash to check if the icon appears there and launch hexchat
<hikiko> dpm, thank you! I am going to try it
<dpm> np :)
<dpm> hikiko, I'm not sure you've seen the PR I sent earlier against your playpen repo on github. I added a couple of changes more (specifying the right version, using the unity7 plug, removing dh-autoreconf)
<hikiko> sorry dpm, I just did, I am going to merge it right now
<mup> PR snapd#1542 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/1542>
<dpm> great
<mup> PR snapd#1450 closed: tests: extend refresh test to talk to the staging and production stores <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1450>
<mup> PR snapd#1391 closed: overlord/snapstate, daemon, client, cmd/snap: devmode override (aka confined) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1391>
<dpm> trijntje, a couple of comments: I think you might be better off asking on the mailing list for this one, as I'm not sure if there are any java experts around atm.
<dpm> trijntje, Another thing: rather than including the .jar file in your repo, you can specify a remote source for the `copy` plugin, that is https://googledrive.com/host/0BxMokdxOh-JRM1d2azFoRnF3bGM/download/forester_1041.jar directly
<dpm> trijntje, you might also want to look at a couple of other .jar snap examples:
<hikiko> dpm, I think I messed it up :p I am not sure I merged your branch and not something else.. I tried to resolve/commit/merge following the git instructions here:
<hikiko> https://githowto.com/resolving_conflicts
<dpm> trijntje, here's one example: https://github.com/filebot/filebot/tree/master/installer/snappy
<dpm> trijntje, here's another one: https://github.com/dplanella/snappy-playpen/tree/jtiledownloader/jtiledownloader and an alternative: https://github.com/ogra1/jtiledownloader
<dpm> hikiko, unfortunately, I'm not a git expert, so I'm not sure I can help. What I generally do is to do `git merge`, then manually edit the files that have the conflict to resolve it, and then `git commit`
<hikiko> mm that's what I did, I don't know much git either
<hikiko> it seems to have the changes but I think I merged the master too accidentally afterwards
<mup> PR snapd#1543 opened: store & many: a mechanical branch shortening store names <Created by chipaca> <https://github.com/snapcore/snapd/pull/1543>
<hikiko> ouch dpm, I merged mine to yours and master to mine, I now merged the merged yours to mine and it seems fixed :) I have to add the desktop and done... dpm thanks a lot!
<dpm> glad it worked out in the end! :)
<trijntje> dpm: thanks for the feedback, I'll also have a look at the snaps you listed.
<dpm> no worries, I hope it helps
<dpm> hikiko, have you been in touch with hexchat upstream about your snap?
<hikiko> no dpm should I?
<hikiko> is there some process I have to follow for every snap?
<dpm> hikiko, no worries, I was just wondering if you'd been in touch with them. I think he important thing is to get the snap running well first
<hikiko> dpm, I did a merge proposal though because there was a compile error in hexchat and I sent a fix which isn't merged yet
<dpm> hikiko, yeah, I saw that, good work
<dpm> hikiko, so once the snap is working, we encourage folks to submit their snapcraft code upstream. Here are some guidelines: https://github.com/ubuntu/snappy-playpen/wiki/Upstreaming#forwarding-your-work-upstream
<dpm> but we can look at it once the review for the playpen has finished
<jacekn> Croepha: thanks. Would you have more detaila bout adding scripts to the environment? I can't do it inside my software because it's the build itself that's failing
<mup> PR snapd#1544 opened: overlord/snapstate: kill flagscompat <Created by chipaca> <https://github.com/snapcore/snapd/pull/1544>
<mup> PR snapd#1545 opened: snappy: what snappy <Created by chipaca> <https://github.com/snapcore/snapd/pull/1545>
<mup> PR snapd#1544 closed: overlord/snapstate: kill flagscompat <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1544>
<mup> PR snapd#1545 closed: snappy: what snappy <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1545>
<mup> PR snapd#1543 closed: store & many: a mechanical branch shortening store names <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1543>
<asac> sergiusens: so the java thing is trickier; we have maven for instance that also installs packages
<asac> so it kind of bubbles up etc.
<mup> PR snapd#1494 closed: tests: add content sharing interface spread test <Reviewed> <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1494>
<ogra> trijntje, http://paste.ubuntu.com/19358043/ ... that gets me a runnable snap
<ogra> (not sure why you have that gazillion of fonts in your snapcraft.yaml :) )
<trijntje> ogra: because I kept finding references to font troubles when I tried to google the errors I got. I figured I'd remove all of them once I got the snap running
<ogra> trijntje, well, it stearts on my laptop when i build it with the patch above
<ogra> (surely could still need some additional optical adjustment, but it runs fine at least)
<trijntje> ogra: your version works for me as well, thanks a million
<ogra> trijntje, add "touch $SNAP_USER_DATA/_aptx_configuration_file" to your wrapper too ... then it stops complaining about the missing config
<dpm> nice one ogra!
<ogra> note that you might still need to ship some fonts and some more fontconfig magic ... i see crashes when i fiddle with the options in the app
<ogra> (specifically when changing the fonts)
<dpm> trijntje, you might want to submit it as a snappy playpen example too: https://github.com/ubuntu/snappy-playpen (just as a suggestion and to get more eyes on it, we've now got another jar example already)
<ogra> hmm, on the upstrram page it is actually suggested to use the default config file they provide
<ogra> *upstream
<ogra> so you should probably ship that and copy it in place from the launcher
<trijntje> ogra: would that be the preferred way, copy the config file to $SNAP_USER_DATA every time the snap is started?
<ogra> [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp _aptx_configuration_file $SNAP_USER_DATA/
<ogra> trijntje, add that line ... then it only copies it on first start
<ogra> hmm
<ogra> [ -e "$SNAP_USER_DATA/_aptx_configuration_file" ] || cp $SNAP/_aptx_configuration_file $SNAP_USER_DATA/
<ogra> thats bettr :)
<trijntje> ogra: thanks. I was also thinking about modifying the default configuration file, but I guess that would be considered rude if I were to publish this snap to the store
<ogra> why would that be rude ?
<ogra> as long as you pick sane defaults i wouldnt think it is rude
<ogra> thats the freedom of being a packager ... :)
<ogra> (picking propoer defaults)
<ogra> *proper
<trijntje> fair enough, I wasn't planning on going crazy anyway ;)
<ogra> :)
<trijntje> ogra: one final question, if I submit it to the playpen, should I add the .jar file as well? _dpm suggested I should use the download link in the snapcraft file, but I'm worried that will change and break snap with the next release
<ogra> well, you will need to update the link if the version changes upstream ...
<ogra> but the download only happens at build time, so nothing that is already in the store will break
<dpm> yeah, and I'm not sure we want to have huge binary files in the repo
 * ogra doesnt care, but using the download is definitely more elegant ... 
<mup> PR snapd#1539 closed: tests: improve snap run symlink tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1539>
<ogra> and you can perhaps convince upstream more easily to take it if it comes down to only a snapcraft.yaml and wrapper
<trijntje> download link it is then, and I'll also remove the gazillion font package I added in a bit of cargo cult madness
<ogra> yeah
<ogra> as i said, there is still some issue with the font selection ... but you can fix that iteratively later :)
<trijntje> ogra: thanks again for looking into it for me, I was about to give up after doing 53 revisions without getting it to even start ;)
<szszsz> Hi! Had anyone a problem with qt systray and snapd /tmp ?
<ogra> trijntje, next time post your tree as first thing ;)
<ogra> guessin by error message takes way longer than just trying out existing code ;)
<dz0ny> trijntje: compiled binaries should be never in git repo
<dz0ny> just one of cardinal rules
<mup> PR snapd#1542 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by mvo5> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1542>
<kyrofa> szszsz, what kind of problem? The only one I know about is a broken icon
<szszsz> kyrofa: For Qt5 it is not shown at all. I have found  that Qt creates png image in /tmp directory. Maybe App has no access there?
<szszsz> kyrofa: could you share link to bug?
<szszsz> kyrofa: correction, systray is shown but with default icon
<kyrofa> szszsz, #1600136
<mup> Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136>
<trijntje> dz0ny: its too late now, unless there is a way to re-write history on a github repository
<szszsz> when runned without snappy it works correctly
<kyrofa> szszsz, sound about right? Your instincts were spot on there, by the way (due to the use of /tmp)
<kyrofa> szszsz, but slightly backwards-- the snap can put stuff in /tmp, but its /tmp actually ends up being in the system's /tmp/snap.foobar/, and the indicator looks for it in /tmp
<szszsz> kyrofa: mup nice, thanks! I could not have found this one in google today
<kyrofa> szszsz, mup is a bot that listens for bugrefs and other things
<kyrofa> trijntje, there's always a way to rewrite history
<kyrofa> trijntje, but it's not typically nice to your users
<szszsz> kyrofa: Ahh, I see :)
<trijntje> kyrofa: the good news is I dont have any users yet. I'll just remove the repository from github and add it again without the binary file
<trijntje> unless thats forbidden on github?
<kyrofa> trijntje, you can do that all from git
<kyrofa> trijntje, oh not at all. I can help you do this without touching github-- you can do it all from git
<kyrofa> trijntje, can I have a link to the repo?
<trijntje> https://github.com/Redmar-van-den-Berg/archaeopteryx
<kyrofa> trijntje, oh yeah, this'll be easy
<kyrofa> trijntje, what are you trying to remove?
<kyrofa> trijntje, or have you commited a removal already?
<kyrofa> trijntje, the jar?
<trijntje> kyrofa: no, the jar is still in the repository now
<kyrofa> trijntje, indeed, and that's what you want to remove? It's used in your YAML... how do you plan on removing it?
<trijntje> kyrofa: I want to remove the jar, and replace it with a copy from the download link in the yaml file
<kyrofa> trijntje, ah ha
<trijntje> this one: https://googledrive.com/host/0BxMokdxOh-JRM1d2azFoRnF3bGM/download/forester_1041.jar
<kyrofa> trijntje, run this: `git rebase -i 44b29958d14a2b690fd6a4f062fe1e0b28090c50`
<kyrofa> trijntje, it will bring up your editor. You'll see a few lines there, one of which is "pick 25a4443 Added wrapper and the jar file"
<kyrofa> trijntje, change the "pick" to "edit"
<kyrofa> (only on that single line)
<kyrofa> Then save and exit
<kyrofa> Now your terminal will drop to the shell and allow you to alter that commit however you like
<kyrofa> Remove the jar and update the YAML. Give it a test, make sure it works the way you had in mind
<kyrofa> Once you're happy with it, make sure you've `git add`ed everything, and run `git rebase --continue`
<kyrofa> trijntje, err, you need to `git commit --amend` before you `git rebase --continue` though
<kyrofa> Sorry
<trijntje> ok, i'm trying to build the new snap now
<mup> PR snapd#1508 closed: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1508>
<mup> PR snapd#1530 closed: asserts: add cross checks for snap asserts <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1530>
<trijntje> kyrofa: I did all the commands, but now the wrapper is also back to an earlier version
<kyrofa> trijntje, did you run the `git rebase --continue` command?
<trijntje> kyrofa: I did http://pastebin.com/eaL3HDGM
<trijntje> I ran it again: http://pastebin.com/6Yn7D0ca
<kyrofa> trijntje, huh, so the changes you made completely negated that commit?
<trijntje> kyrofa: I dont think so, I changed the yaml file, but I didn't touch the wrapper at all
<ogra>  hmm .. do we have any interface that gets me acces to /dev/fuse ?
<ogra> zyga, ^^ do you know ?
<zyga> ogra: re
<zyga> ogra: no we don't have one
<zyga> ogra: is fuse something that could be tagged with an udev rule?
<ogra> ah, i'll file a whishlist bug then ...
<zyga> ogra: if so it should be relativelt simple to do the mechanics of granting permissions
<ogra> well, as long as a user has fuse access he usually can mount/unmount all fuse based filesystems unprivileged
<ogra> that sounds like th perfect thing for snaps
<ogra> (i'm playing with a tool to do an automatic sshfs mount of my ubuntu phone... )
<zyga> ogra: hmm, mount is probaby a no-go
<zyga> ogra: with enough mount you can escape
<zyga> ogra: but I'll let security guys comment on hat
<ogra> it isnt mount ... it is fusermount
<zyga> ogra: we can probably figure something out, maybe via a trusted helper
<ogra> you cant mount/umount aything relevant
<zyga> is fusermount a different system call?
<ogra> could be ...
<ogra> http://paste.ubuntu.com/19368313/ ... doesnt look like it needs special syscalls
 * ogra tries devmode ... 
<zyga> ogra: add "/dev/fuse rw," to the apparmor profile
<zyga> ogra: and reload with apparmor_parser -r /path/to/profile
<zyga> ogra: you should nail it faster this way
<ogra> hmm
<ogra> http://paste.ubuntu.com/19368550/ ...
<ogra> devmode blocks too
<ogra> the user needs to be in the fuse group (which i am) ... i wonder if that gets handed through to the launcher
<zyga> ogra: I think so
<zyga> ogra: we don't drop groups
<ogra> k
<zyga> ogra: so it does require mount
<ogra> then it is something else
<zyga> ogra: I think we could do something around that given that the argumennts are something apparmor can control
<ogra> i can run the script from the snapcraft dir just fine
<ogra> so something else is blocking additionally here
<zyga> ogra: well, I see you are in devmode already
<ogra> in tezh second paste i'm in devmode
<zyga> yep
<zyga> ogra: let's talk about this next week, :) I need to fix snap-confine
<ogra> k
<mup> PR snapcraft#657 opened: Add constraints to python2 plugin <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/657>
<mup> PR snapd#1531 closed: many: present user with a choice of payment backends <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1531>
<mup> Bug #1603113 opened: add fuse filesystem interface <Snappy:New> <https://launchpad.net/bugs/1603113>
<mup> PR snapd#1546 opened: store: kill setUbuntuStoreHeaders <Created by chipaca> <https://github.com/snapcore/snapd/pull/1546>
<imexil> looking at popey's snapcraft screencast I was wondering if there also exits a snap for simplescreenrecorder
<ogra> ogra@styx:~/Devel/packages/snaps/phonemount$ snap find screen recorder
<ogra> Name  Version  Developer  Notes  Summary
<ogra> vlc   daily    caldav     -      Read, capture, broadcast your multimedia streams
<ogra> doesnt look like it ...
<ogra> go ahead and package it ;)
<imexil> I was afraid that would be the answer ;-)
<ogra> haha
<ogra> surely some good finger training :)
<dholbach> I think that was asciinema
<ogra> well, but having a gui recorder would be nice too
<dholbach> sure, just saying
<mup> PR snapcraft#658 opened: parser - Return non-zero code for wiki errors <Created by josepht> <https://github.com/snapcore/snapcraft/pull/658>
<SamYaple> new to snappy here. Does snappy have a way to share layers similiar to docker/rkt? I am packaging openstack in snappy but I spend alot of time building the same python packages over and over
<Croepha> SamYaple not really
<SamYaple> yea i thought not. thats fine, im just worried about total size being an issue
<SamYaple> ~20 different services all at 200MB... ouch
<SamYaple> not to mention the build time, though thats less of an issue
<Croepha> SamYaple, it might be best to bundle them all in one snap... you can do multiple apps in one snap
<SamYaple> Croepha: I am considering that, but that limits flexibility in version selection. not all of the services package/tag at the same time
<SamYaple> they are different apps
<Croepha> I'm not exactly recommending this as a course of action, but i think it is technically possible for one snap to reference content from another snap
<SamYaple> Croepha: do you have any links so I can evaluate that?
<Croepha> via /snap/othersnap/current/...
<Croepha> not really, sorry
<SamYaple> not a problem at all
<Croepha> i'm not even sure that is a supported  use case, i just found that out by playing around
<SamYaple> since I am new to snappy, im unsure where /snap/othersnap/current would come into play
<Croepha> its a path on the filesystem
<SamYaple> oh.. i see what youre saying
<SamYaple> yea im not a fan of that
<SamYaple> ill get a total size of the packages and see
<SamYaple> I can save alot of space in each service by cherry-picking files
<Croepha> if you do bundle them all as one snap, then it might be best to do a periodic release strategy
<SamYaple> maybe that will eb enough
<SamYaple> well asuming this packing goes well ill be throwing this into an openstack offical project, but it would almost certainly need to be seperate rather than a bundle
<Croepha> like 2016.7 2016.8 ... 2016.12 for each month?
<SamYaple> I do agree that should that be required, periodic would be best
<Croepha> you do have the benefit of differential updates too, so what is common between versions wont have to be downloaded again
<SamYaple> differential between individual packages?
<iliv> I added a few interfaces for apps in snapcraft.yml and it seems like the only way for this change to come to life is to rebuild all associated parts. Is there a way to do this without rebuilding source code? In my case it is a bit a lengthy process so not much fun just sitting here waiting for a ...
<iliv> ... program to finish compiling.
<Croepha> no, differential between versions of the same package
<mup> PR snapd#1547 opened: many: remove all traces of channel from the buying codepath <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1547>
<SamYaple> Croepha: right thats what i was asking. ok thats good to know
<Croepha> SamYaple: it might be worth checking if some kind of layers like support is in the issue tracker
<SamYaple> I will
<SamYaple> to be honest, im kind of glad there are no layers. layers add complication
<SamYaple> i didnt really like them when i built them into kolla (the openstack in docker containers project)
<SamYaple> you always had to make compromises about what would be in both and it tied all the packages together more than i liked
<Croepha> iliv: I don't know the answer to that question... but from my experience  you pretty much have to do a full clean for most snapcraft.yaml changes, but you might want to try building outside of snapcraft and then copying back in, thats what I have resolved to doing
<iliv> that sucks Croepha
<ogra> iliv, look as the snapcraft clean options ...
<iliv> ha, I was just about to highlight you ogra and ask to chime in on this matter
<Croepha> iliv: also, you know about --try right?
<ogra> you can clean different stages
<mup> PR snapd#1548 opened: many: add new `snap weld` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/1548>
<mup> PR snapd#1549 opened: docs: add payment methods documentation <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1549>
<iliv> Croepha, know but I'll look into it
<iliv> ogra, right, I use clean --step build a lot
<SamYaple> what is the difference between build-packages and stage-packages? are stage-packages included in the final snap and build-packages are nto?
<iliv> SamYaple, that sounds correct
<Croepha> iliv: my usual iteration loop is sudo snap remove my-app; snapcraft clean && snapcraft prime && snapcraft try --devmode prime/  (and that is after I have built the binaries externally and in my snapcraft.yaml is just a copy)
<iliv> SamYaple, build-packages are required for compiling/building your application. stage-pacakges are sort of like dependecies that are included in the resulting snap package.
<iliv> Croepha, I've been doing it similarly but I'm happy with a complete snap package. Install it, test it and see what doesn't work and the adjust snapcraft.yml and rebuild.
<ogra> iliv, well, just use --step stage ...
<SamYaple> iliv: strange then. i have all packages in build-packages and yet there are libs in teh stage folder
<SamYaple> i _want_ those libs there, but im wondering if that is snappy being clever, or be not understanding something
<vidasov> Hi
<vidasov> Sorry I have basic questions regarding snapcraft if possible?
<Croepha> SamYapleL I think Snappy tries to be clever, using ldd (or more?) to do things like that
<Croepha> SamYaple doesn't work well with dload though...
<kyrofa> vidasov, ask away!
<SamYaple> Croepha: it seems to keep around all the of header files and manpage docs
<Croepha> from stage-packages?
<SamYaple> from build-packages
<SamYaple> i have no stage-packages
<Croepha> huh, i wouldn't have expected that, maybe some experts here can chime in
<vidasov> yes thanks, I started this morning with snapcraft and went trough ubuntu page tutorial which is the same thing as in snapcraft.io but it didn't work for me and looks lilke snapcraft doesn't apply changes is yaml file is changed
<ogra> SamYaple, where does it keep them around ? build-packages should definitely not be copied into the final snap
<ogra> (they surely stay around in youtr build tree until you call "snapcraft clean")
<dz0ny> SamYaple: build-packages are host packages, stage-are those that are bundled into your snap
<Croepha> vidasov, snapcraft clean ?
<mup> PR snapd#1550 opened: tests: base security spread tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1550>
<SamYaple> ogra: /usr/include/* has a whole lotta header files from packages like libc6-dev
<kyrofa> vidasov, indeed, snapcraft is slowly gaining those types of features
<ogra> vidasov, you need to clean first before running a new snapcraft build, else it will just copy the existing bits from the parts/*/install dirs
<SamYaple> ogra: i never explicitly installed libc6-dev, it was building in by build-essential (or maybe python-dev)
<Croepha> SamYaple, but what about prime/usr/include ?
<kyrofa> vidasov, until it gets smarter you need to clean between changes. You can clean individual steps though instead of cleaning entirely
<SamYaple> Croepha: same
<ogra> SamYaple, that is in your installed snap (under /snap/$packagename/current/) ?
<dz0ny> I kindo don't like that it picks libs from host at all
<dz0ny> when i started i assumed it would start from ubuntu-core
<SamYaple> ogra: its in the squashfs of the snap, i havent installed it, but i mounted teh squashfs
<ogra> weird, i have never seen that happen here
<SamYaple> maybe its because build-essential is a meta package?
<ogra> since ... if you dont use cleanbuild ... the dev packages are all installed on your host machine ...
<Croepha> SamYaple:  which package? if you dont mind
<ogra> and bits from the host machine can technically not really end up inside the snap
<SamYaple> let me try to clean this entirely out
<dz0ny> ogra: they can :)
<ogra> using meta packages is fine
<ogra> dz0ny, they shouldnt
<dz0ny> snpacraft is not isolated from host system
<ogra> how would they end up insdie the build tree
<vidasov> OK thanks for your clarification, sound good for beginning, so I did a workaround prepared everything in one shot and compiles ok, this webcam tutorial so how to check if it works actually? it looks i cant run new app from command line
<ogra> given they get installed in the host and not in the "parts" staging area
<dz0ny> LD_*
<ogra> only bits under parts/ end up in the snap
<SamYaple> rebuilding now, clean parts folder and all
<Croepha> vidasov: When you do a snap install, it adds special commands to your system path, look for a command that starts with your snap name
<dz0ny> but when you compile something it's picked from host (header files,libs etc)
<ogra> you would have to have symlinks or bindmounts into that dir to have them end up in prime/ or stage/
<dz0ny> no
<dz0ny> ogra: I have a test
<vidasov> yes and when I do snap list, I see app, but when I try to run it nothing
<Croepha> vidasov, like no output, and no error?
<vidasov> like no app at all
<ogra> did you check syslog ?
<ogra> there should be errors if it didnt start
<dz0ny> ogra: https://github.com/ubuntu/snappy-playpen/pull/166 try this one on system without ffmepg libs in normal paths
<mup> PR ubuntu/snappy-playpen#166: Add champ snap <Created by dz0ny> <https://github.com/ubuntu/snappy-playpen/pull/166>
<Croepha> vidasov: this is the webcam example?
<dz0ny> it does build on docker+travis but not in isolated machine
<vidasov> yes, webcam
<dz0ny> if it has ffmpeg isntalled
<SamYaple> yep, totally clean rebuild the final snap squashfs has a bunch of headers in /usr/include
<ogra> dz0ny, not really sure whast you mean with "ld" ... ld always comes from ubuntu-core at runtime
<vidasov> if syslog and ffmpeg were meant for me, thanks but I cant even run app and it is listed as installed
<ogra> vidasov, syslog was meant for you,. yes ... watch it when you try to start the app or when yiou install the snap (in case it has a service and not an enduser app inside)
<SamYaple> ok well im going to go to lunch, ill dig into this more when i get back. if anyone has more suggestions for me to try, just ping me. thanks!
<Croepha> vidasov: ok, I think that installs as a daemon, so that wont be in your $PATH, do you get anything when you do "systemctl --all | grep webcam"
<vidasov> ok this tells something: snap.webcam-webui.webcam-webui.service                                                      loaded    inactive dead
 * ogra would just open an additional terminal and run "tail -f /var/log/syslog" and then uninstall and re-install the snap 
<ogra> that should give you all errors
<vidasov> ok, will do
<Croepha> there is also journalctl -u snap.webcam-webui.webcam-webui.service
<ogra> doesnt the webcam demo need the camera inetrface ?
<ogra> i thnk that one needs manual connecting after installing the snap
<ogra> something like: "sudo snap connect $yourpackage:camera ubuntu-core:camera"
<vidasov> ok, does that mean that "$yourpackage:camera" is app on ubuntu and "ubuntu-core:camera" is app which I need to install in ubuntu core
<vidasov> as a snap
<vidasov> so little bit confuzed
<kyrofa> vidasov, ubuntu-core is a snap that is a prerequisite for all other snaps. You should see it in the `snap list` output
<kyrofa> vidasov, it provides the slot side of many interfaces
<kyrofa> vidasov, including the camera
<vidasov> ok, I saw it
<kyrofa> vidasov, but as ogra mentioned, that interface it not connected by default, so you'll need to connect it manually using the command he gave
<vidasov> good, I'll try
<vidasov> thnx
<kyrofa> sergiusens, elopio bug planning today, or no?
<josepht> kyrofa: sergiusens is out today and tomorrow
<kyrofa> josepht, ah ha
<kyrofa> josepht, thanks for letting me know!
<josepht> kyrofa: np :)
<kyrofa> elopio, what is YOUR excuse?
<mup> PR snapd#1551 opened: systemd,wrappers: map "never" restart condition to "no." <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1551>
<wililupy> Is it possible for me to do a git checkout from snapcraft.yaml?
<mup> PR snapcraft#659 opened: Support "never" as a daemon restart condition <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>
<kyrofa> wililupy, of course
<kyrofa> wililupy, provide the git URL to the source. Depending on what the URL looks like you may also need to specify source-type: git
<wililupy> kyrofa: \o/
<kyrofa> wililupy, you can also specify source-branch or source-tag
<kyrofa> wililupy, `snapcraft help sources` for more info
<wililupy> kyrofa, perfect, that is what I was looking for.
<wililupy> kyrofa: For source-branch, can I use the first 7 chars from the hash or do I need to full hash?
<wililupy> kyrofa, git specific
<wililupy> ly
<kyrofa> wililupy, you should be able to use the short
<wililupy> kyrofa, excellent. I'm going to give it a shot. Thanks!
<kyrofa> wililupy, sure thing
<mup> PR snapd#1549 closed: docs: add payment methods documentation <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1549>
<mup> PR snapcraft#596 closed: Preserve the ordering of the wiki entries <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/596>
<kyrofa> elopio, josepht mind taking a look at #659?
<kyrofa> snapcraft#659 maybe?
<mup> PR snapcraft#659: Support "never" as a daemon restart condition <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>
<vidasov> hi, does snappy has bluetooth interface, looks like not?
<josepht> kyrofa: done
<ali1234> which tarball do i need to make a development chroot?
<ali1234> ubuntu-core or ubuntu-base?
<mup> PR snapcraft#660 opened: Fix python2 compile cache removal <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/660>
<elopio> kyrofa: reviewed. And replying to the previous ping, my excuse is that I had to my swimming lessons. I need to apply myself if I want to beat all my elder classmates :)
<ali1234> hmm.. well that totally failed
<vidasov> sorry, question please: can snappy app connect to bluetooth as to interface? Or is it possible to have snappy communicate over bluetooth?
<ali1234> i'm sure it will be possible eventually
<ali1234> i don't know if it is possible now
<vidasov> thanks, I was afraid of it. :-) but let us be patient.
<ali1234> looks like the ubuntu raspberry pi image doesn't have drm support or something
<mup> PR snapd#1546 closed: store: kill setUbuntuStoreHeaders <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1546>
<mup> PR snapd#1546 closed: store: kill setUbuntuStoreHeaders <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1546>
<SamYaple> do all of the binaries go to /snap/bin ? what about those that are located in usr/bin/* in the snap?
<SamYaple> i suppose my question is, what is _meant_ to be in /snap/bin ?
<Croepha> vidasov: if you want to access something that isn't supported, just run with devmode enabled for now until its supported, and you should probably also file a bug outlining what you want access to
<Croepha> SamYaple: /snap/bin is just shell scripts that act as entry points into files stored in /snap/.../current/bin/...
<vidasov> ok, thanks Croepha, that is nice to hear that is possible, after all :-)
<Croepha> SamYaple: you only get files in /snap/bin if you set them as apps in your snapcraft.yaml file
<ali1234> okay i've got a challenge for anyone who is bored... snap a Qt5 app so that it runs on the raspberry pi without a windowing system, using the eglfs platform, and having full accelerated graphics
<ali1234> this is how you do it on raspbian: https://wiki.qt.io/RaspberryPi2EGLFS
<Croepha> ali1234 I did that the other day
<ali1234> great. how?
<Croepha> well, i got it running on amd64
<Croepha> sec
<ali1234> doing it on amd64 is trivial
<ali1234> to do it on raspberry pi you need: Qt >= 5.6 (not available in ubuntu)
<ali1234> you also need the raspberry pi EGL libs from this ppa: https://launchpad.net/~ubuntu-raspi2/+archive/ubuntu/ppa
<Croepha> huh ok, nvm then, i don't remember it being trivial, I had to set all kinds of variables for alsa and gstreamer to know where to load their modules and stuff
<ali1234> you also need to fix the raspberry pi ubuntu kernels so that DRM works
<ali1234> it's trivial in comparison
<ali1234> whatever you needed to do, you need to do all that stuff on top ^
<Croepha> ok, i still can't figure out how to build a 16 ubuntu-core image
<ali1234> i've done that
<Croepha> let alone put a custom kernel in it
<ali1234> ubuntu-device-flash builds the image
<ali1234> but at the moment i'm working with the server image
<ali1234> so not ubuntu-core
<ali1234> i'm trying to build a custom qt to see if it makes drm work, but i'm not holding my breath
<Croepha> can you point me to a doc? something more up-to-date than this: https://developer.ubuntu.com/en/snappy/guides/porting/ ?
<ali1234> something like this http://people.canonical.com/~mvo/all-snaps/make-rpi2-all-snap.sh
<ali1234> although that might be out of date
<Croepha> this looks promising: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/
<Croepha> except for the fact that im starting with kernel debs instead of the source
<Croepha> i'll have to look at that tomorrow
<Croepha> its weird that they woundn't build the rpi kernel with DRM
<ali1234> yes
<ali1234> maybe it's some other problem, i don't know
<Croepha> thats like what 200Kb more?
<ali1234> the problem is the raspberry pi libs aren't in the main repo
<ali1234> so they can't build anything against them
<ali1234> i don't know if that matters for the kernel though
<ali1234> maybe the raspi stuff isn't upstreamed
<ali1234> i guess i'll have to just keep using raspbian for now (again)
<ali1234> even ./configure on qtbase has taken like 20 minutes so far
<Croepha> ali1234 are you crosscompiling ?
<ali1234> no
<ali1234> i cross compiled it for raspbian
<Croepha> that will probably take days
<ali1234> but i wanted to see how long it will take native
<ali1234> it should not take days, qtbase is not that big any more now everything is modular
<ali1234> actuallyi can probably just push my cross compiled version to ubuntu
<ali1234> it will probably work right? right?
<ali1234> configure says:      EGLFS Raspberry Pi . no
<ali1234> so that not gonna work :/
<Croepha> its a shame there is no https://launchpad.net/~beineri/+archive/ubuntu/opt-qt57-xenial for rpi
<ali1234> yes, i already tried that
<ali1234> maybe i need some magic config option
<Croepha> might be easier just to give up on QT
<ali1234> lolno
<ali1234> it would be easier to just use raspbian
<Croepha> right
<ali1234> i can't give up on qt, there is literally nothing else as good
<ali1234> and it works perfectly on raspbian... 60FPS, no tearing, touch screen works perfectly
<Croepha> can you just copy out all the QT binaries from raspian?
<ali1234> i could do yes, but i would not expect them to work
<Croepha> it will probably work, with some elbo-grease
<ali1234> except it wont, if drm is missing
<ali1234> let me try it, hang on
<Croepha> right, if DRM is missing then thats a stopper
<Croepha> ok, can you copy the kernel from rasbian ?
<ali1234> hang on testing qt first
<ali1234> if i copy the kernel and the user space i might as well just use raspbian at that point :)
<Croepha> well, the advantage of snappy, is that you will be able to do transactional updates
<Croepha> but yea, the work will probably not be worth it
<Croepha> atleast for first movers
<ali1234> hmm egl library problems
<ali1234> libraspberrypi0 from the ppa installs it in /usr/lib and it conflicts with mesa
<Croepha> hmm
<Croepha> im not sure what libraspberrypi0 is, but if it provides a mesa implementation, then you should probably link with that instead of what ever is default
<ali1234> you don't link against it directly
<ali1234> mesa implementations are interchangable
<ali1234> the problem is i can't get it top open the thing
<Croepha> well, snappy sets the LD_LIBRARY_PATH, so that stuff in your snap gets loaded first
<ali1234> yeah qt built for raspbian doesn't work on ubuntu
<ali1234> This application failed to start because it could not find or load the Qt platform plugin "eglfs"
<ali1234> the plugin is definitely there, it just won't load
<Croepha> i know this one
<ali1234> HAH
<ali1234> i know why none of this works
<Croepha> you need a export QT_PLUGIN_PATH=/snap/$your_app/usr/lib/x86_64-linux-gnu/qt5/plugins/
<ali1234> i'm not running it in a snap
<ali1234> i'm running it from /usr/local
<Croepha> ahh ok
<ali1234> it doesn't work
<ali1234> anyway the qt source has this handy little test program for eglfs-brcm
<ali1234> it fails to build on ubuntu, hence why it doesn't work
<Croepha> in order to get my QT working in snap, I had to set these variables:  XDG_DATA_HOME XDG_CONFIG_HOME QT_PLUGIN_PATH GST_PLUGIN_SYSTEM_PATH_1_0 GIO_MODULE_DIR GSETTINGS_SCHEMA_DIR
<Croepha> oh and ALSA_CONFIG_PATH
<ali1234> so here's a revised version of my challenge. snap this: http://paste.ubuntu.com/19414877/
<ali1234> it's only 11 lines of code, should be easy right?
<Croepha> you have to do it in devmode, because there is no interface for it
<Croepha> but assuming there is /dev/drm it should be easy
<mup> PR snapd#1532 closed: release: fix Elementary support <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1532>
<mup> PR snapd#1552 opened: release: work around elementary mistake <Created by chipaca> <https://github.com/snapcore/snapd/pull/1552>
<mup> PR snapcraft#661 opened: Added a test Jenkinsfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/661>
<mup> PR snapcraft#659 closed: Support "never" as a daemon restart condition <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/659>
#snappy 2016-07-15
<ali1234> hmm... getting somewhere
<ali1234> i now know how to properly make Qt detect the libraspberrypi headers
<Croepha> ali1234: what did you have to do?
<ali1234> modify the device file to fix the paths /opt/vc -> /usr/include
<ali1234> actually just /usr
<Croepha> huh
<ali1234> wow, it actually works
<ali1234> now i need to figure out how to make it build native so i can build it with snapcraft
<Croepha> what do you mean by native exactly? if you have working binaries on your target architecture, just copy them, and fix the pathing issues with environmental variables
<ali1234> i don't understand what you mean
<ali1234> snapcraft wants to build tings from source
<Croepha> you dont have to, there is a copy plugin
<ali1234> but again, i don't understand
<ali1234> snapcraft doesn't know how to cross compile
<Croepha> i must be misunderstanding... i thought you said that you got it working in on your pi, you just needed to get it snapped
<ali1234> i got it working by cross compiling it on x86
<ali1234> if i want to build a snap for arm, i have to run snapcraft on arm
<ali1234> therefore i can't cross compile qt
<Croepha> so copy the binaries that you made on x86 for arm, onto a pi, and run snapcraft on that pi with the binaries you made on x86
<ali1234> the whole point of using snapcraft is to automate all this
<ali1234> if i copy the qt binaries manually like that i can just skip the whole snap part entirely
<ali1234> so it turns out that you can build native. just tell it you're cross compiling and then point it to the native toolchain in /usr/bin
<Croepha> i mean, you /can/ autmate that process (via scripts)... but snapcraft might not be integral to that goal, i think of snappy as more of a deployment solution
<ali1234> yes. but you're telling me to deploy Qt in order to build a snap out of it so i can deploy it... that's cyclic
<renatu> tedg, guys how I can use this "qml" plugin? http://gould.cx/ted/blog/Creating_a_QML_snap_with_Snapcraft
<renatu> probably I need a new snapcraft version. Any ppa with that version?
<renatu> I tried this one: https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+packages
<tsimonq2> renatu: what Ubuntu version are you running?
<renatu> xenial
<tsimonq2> renatu: the snappy command is very old, so I think that article is very outdated
<tsimonq2> a lot of this is a bit outdated
<renatu> tsimonq2, ok. Do you know if the "qml" plugin still exists?
<tsimonq2> renatu: try and see :)
<renatu> not in my version
<renatu> Searching for local plugin for qml
<renatu> Issue while loading plugin: unknown plugin: qml
<renatu> :D
<tsimonq2> renatu: what's the output of apt-cache show snapcraft | pastebinit ?
<renatu> http://paste.ubuntu.com/19456102/
<tsimonq2> renatu: that's the latest version, so if it isn't showing, we don't have it :)
<tsimonq2> renatu: that article is very outdated anyways
<renatu> ok thanks
<qengho> Has anyone used a snap that relies on Oxide or the Qt wrapper for Oxide yet? I'm trying to figure out the SUID dropping and how to avoid crashing if not SUID.
<mup> PR snapd#1552 closed: release: work around elementary mistake <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1552>
<qengho> "work around elementary mistake <Created by chipaca>"  Don't be rude, mup.
<mup> PR snapd#1517 closed: wrappers: run update-desktop-database after add/remove of desktop files <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1517>
<mup> PR snapd#1551 closed: wrappers: map "never" restart condition to "no." <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1551>
<tsimonq2> hi hikiko
<hikiko> hello tsimonq2
<hikiko> how are you?
<tsimonq2> great hikiko :)
<tsimonq2> hikiko: I'm making inline notes on your PR
<hikiko> tsimonq2, thank you, I fixed the first 2 things
<hikiko> tsimonq2, I have an issue though: my snap can be successfully installed but I can only find it with Alt+F2 and there's no icon only the default gears
<hikiko> (u7)
<tsimonq2> weird
<hikiko> I should see an icon isn't it? the path is correct
<hikiko> maybe I have to restart unity
<tsimonq2> yeah I think so, try looking at other snaps that have working icons
<tsimonq2> oh, maybe
<tsimonq2> *shrug*
<tsimonq2> I use LXQt :)
<hikiko> I checked vlc and qcomicbook
<tsimonq2> hikiko: have you watched popey's video on this? If I remember correctly, he covered this
<hikiko> no, tsimonq2 do you know where I could find it?
 * tsimonq2 hunts it down
<tsimonq2> hikiko: https://www.youtube.com/watch?v=K0IzxsIFjJY
<tsimonq2> thanks popey for the awesome video! :D
<hikiko> oh, nice :) thanks tsimonq2, I am going to watch it as soon as I fix the things you highlighted on github
<hikiko> yeah thanks popey too ;)
<tsimonq2> one more comment hikiko :)
<hikiko> haha, I'll check it in  a while tsimonq2, I am fixing the README and :s/hexchat/HexChat
<tsimonq2> alright hikiko :)
<seb128> hikiko, what Icon= did you use in the .desktop?
<hikiko> seb128, I downloaded a transparent, high res from wikimedia and put it on the folder (like in vlc and qcomicbook examples)
<seb128> hikiko, that's not what I asked :-)
<hikiko> oh
<hikiko> sorry
<hikiko> Icon=${SNAP}/meta/gui/hexchat.png
<hikiko> seb128, ^
<seb128> unsure what snappy does with that env
<seb128> somebody in the snappy team might be able to help you
<ogra> that looks fine
<seb128> dpm mentioned having issues with a .desktop on g+ as well I think, unsure if he solved it
<seb128> there might be a bug
<ogra> ogra@styx:~/Devel/packages/snaps$ grep Icon jTileDownloader/setup/gui/jtiledownloader.desktop
<ogra> Icon=${SNAP}/meta/gui/icon.png
<ogra> it will be expanded properly
<ogra> ogra@styx:~/Devel/packages/snaps$ grep Icon /var/lib/snapd/desktop/applications/jtiledownloader_jtiledownloader.desktop
<ogra> Icon=/snap/jtiledownloader/2/meta/gui/icon.png
<dpm> seb128, yeah, it's generally worked for me, but when I added the desktop file to the clock app it didn't show up for some reason
<seb128> dpm, is it still not working?
<dpm> using the ${SNAP} and meta/gui as usual
<dpm> seb128, last night it wasn't
<ogra> i noticed that the order of lines in the .desktop entry itself seems to matter ...
<seb128> it shouldn't
<ogra> i know
<seb128> dpm, did you restart your session, just in case it's an unity issue?
<dpm> seb128, good point, I did not. In any case, here's the syntax I used -> https://github.com/ubuntu/snappy-playpen/pull/179/files#diff-fcc4e52ba28709a4626828851c550779R135
<mup> PR ubuntu/snappy-playpen#179: Clock snap running on Unity 7 and Unity 8 <Created by dplanella> <https://github.com/ubuntu/snappy-playpen/pull/179>
<dpm> interesting to hear the order of lines matter... I wonder if that's the issue, even if it's not supposed to affect the launch
<seb128> dpm, try restarting your session first I would say
<dpm> it'll take a while, too many windows open and not much time for looking at that snap today
<dpm> but I'll try, thanks for the suggestion
<seb128> dpm, you can try to kill the unity-scope-loader process
<seb128> it might force a dash refresh
<dpm> is it a service?
<ogra> iirc i had to put "Type=Application" to the top, then the dash pisked it up ...
<ogra> *picked
<ogra> but that might have been a coincidence or something ... is there any kind of scan interval in which it picks up new .desktop files ?
<seb128> no
<seb128> it does inotify watch the dirs
<seb128> and react on events
<trijntje> is there a way to tell snapcraft to use a specific commit from a git repository? The repository doesn't have any tags
<tsimonq2> trijntje: unfortunately not
<trijntje> tsimonq2: thanks, thats good to know at least
<ysionneau> hi
<ysionneau> when using ubuntu-device-flash, with a gadget snap that lists a few preinstalled snaps. is it possible to use locally available snaps? and not ones from the store?
<ogra> not sure if that still works, but there was the --install option to u-d-f
<ysionneau> ah, maybe with --install=
<ogra> that could be used for local snaps
<ysionneau> do I need to remove the preinstalled section from the gadget snap ?
<ogra> uh, not sure
<ysionneau> hmm it seems so
<ysionneau> but install= does not seem to understand that the snap is a local one
<ysionneau> failed to install "~/dev/snappy_paros/autopilot_98_armhf.snap" from "edge": ~/dev/snappy_paros/autopilot_98_armhf.snap failed to install: snap not found
<qengho> jdstrand: Would you say LD_LIBRARY_PATH containing empty path part is a grave bug?
<ogra> ysionneau, try a full path ... perhaps it cant expand the tilde
<mup> PR snapd#1553 opened: cmd: support defaulting to the user's preferred payment method <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1553>
<ysionneau> ogra: awesome, it does work!
<ysionneau> thanks
<ogra> :)
<asac> ysionneau: i thought --install is supplementing what is in gadget... e.g. you can still do preinstalls from gadget (at least in 15.04 that was the case). can you confirm that both work?
<tsimonq2> hikiko: there's two more changes you need to make :)
<hikiko> heh, just saw it tsimonq2
<ysionneau> asac: I can confirm both work in parallel
<tsimonq2> alright hikiko :)
<asac> thanks!
<hikiko> tsimonq2, I think I've fixed them now, I hope I didn't miss anything this time
<hikiko> thanks a lot for the help!
<tsimonq2> hikiko: I'll look it over one more time, then when I think it's ready, I'll give it a thumbs up :)
<hikiko> thanks a lot tsimonq2 :)
<tsimonq2> no problem! if you ever need any more help, I'll be around :)
<tsimonq2> (at whatever time zone I decide to be in that day :P)
<hikiko> thanks! I hope in my next snaps I won't ping you all so many times! that was the 1st one
<hikiko> hahaha
<ysionneau> ogra asac : I can also confirm that putting "confinement: devmode" in the snap is not enough for it to be installed in devmode by UDF with the --install=
<ysionneau> it is installed, but not in devmode
<tsimonq2> hikiko: believe me, I'm *terrible* at excessive pings, don't feel bad, ping me all you want ;)
<hikiko> haha, thanks tsimonq2
<tsimonq2> hikiko: I'm currently working on snapcraft#619
<mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> hikiko: I actually like contributing to Snapcraft a lot more ;)
<ysionneau> ogra asac : hmm let me check again ...
<hikiko> oh, cool :) snappy will support checksums as well now :D
<tsimonq2> yep hikiko :)
<tsimonq2> hikiko: it actually works right now, it just needs to be simplified :)
<hikiko> :D
<hikiko> nice work tsimonq2!
<tsimonq2> sergiusens: re: dictionary in snapcraft#619 , I was looking for a switch-case statement in Python but I couldn't find any :)
<mup> PR snapcraft#619: Add source-checksum option <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
<tsimonq2> sergiusens: so thanks for telling me about dictionaries, it solves that problem XD
<pbek> Hi all! Since the upgrade to snapcraft 2.12.1 I get the following error message for https://github.com/ubuntu/snappy-playpen/blob/master/qownnotes/snapcraft.yaml:
<pbek> Parts 'desktop/qt5' and 'env' have the following file paths in common which have different contents:
<pbek> usr/share/pkgconfig/xkeyboard-config.pc
<pbek> does that sound familiar to anyone?
<qengho> pbek: Do you need any pkgconfig data files? Probably not, right?
<qengho> pbek: Remove in a  stage: [ -usr/share/pkgconfig/xkeyboard-config.pc ]  list
<pbek> qengho: not that I'm aware of, I just want to build a Qt5 app
<pbek> qengho: can you please explain what I have to do?
<qengho> Qt is a fickle mistress whose wily ways are unknown to me, but I can't imagine it wants pkg-config files.
<pbek> so, what do I need to do, qengho ;) I didn't quite grasp your explanation "Remove in a stage"
<pbek> it worked great before snapcraft 2.12.1...
<pbek> hi, dholbach ;)
<dholbach> hi pbek
<pbek> the QOwnNotes snap ran into some troubles with snapcraft 2.12.1 ;)
<pbek> building the snapcraft throws a: Parts 'desktop/qt5' and 'env' have the following file paths in common which have different contents: usr/share/pkgconfig/xkeyboard-config.pc
<ogra> ysionneau, i think "confinement: devmode" only applies to store snaps
<ogra> (and i dont think u-d-f knows about devmode at all)
<dholbach> sergiusens, elopio: ^ did you see what pbek said?
<dholbach> pbek, can you try so use something like this? https://github.com/ubuntu/snappy-playpen/pull/178/files
<mup> PR ubuntu/snappy-playpen#178: fix build by working around #1600238 <Created by dholbach> <https://github.com/ubuntu/snappy-playpen/pull/178>
<pbek> dholbach: ah, that's what qengho mentioned, I'll try that
<pbek> dholbach: then I get a `[Errno 2] No such file or directory: '~/_test/QOwnNotes-Snapcraft/prime/etc/xdg/qtchooser/snappy-qt5.conf'`
<qengho> pbek: Not related to the first.
<pbek> one more try, i removed the qt5conf and used desktop/qt5
<pbek> and I added `-usr/share/pkgconfig` for every part, it is currently building. let's see if it gets through
<dholbach> pbek, sorry about that - no idea where this came from
<dholbach> it looks like a regression somewhere in the parts handling
<dholbach> we should probably file a bug for this
<pbek> the snap was created, I could install it but when I start `qownnotes` it's a zombie :(
<dpm> dholbach, having seen this yesterday myself, I'm afraid if we rebuild all the playpen snaps all of those using the desktop launcher might hit the same issue
<dholbach> dpm, it wouldn't surprise me if we find a few more
<pbek> and the firest time I run `qownnotes` I also get a: ln: failed to create symbolic link '/home/omega/snap/qownnotes/x16/.themes/themes': Read-only file system
<ogra> pbek, add: "cd $SNAP_USER_DATA" to your launcher
<pbek> ogra: do you mean to the `command: desktop-launch $SNAP/usr/bin/QOwnNotes` line in the snapcraft.yaml?
<ogra> ah, you dont use a wrapper ...
<ogra> create one ;)
<qengho> ogra: Command parts need a   pwd: str
<pbek> no, ogra. that's what I'm using unitl now: https://github.com/ubuntu/snappy-playpen/blob/master/qownnotes/snapcraft.yaml
<ogra> pbek, create a shell wrapper and add the line you have in the command section to it ... then replace the command section to point to the wrapper
<ogra> and add the cd command before the desktop-launch line in there
<qengho> pbek: The ogra is saying you should run a script instead of your command above. That script prepares the environment for the launcher line instead.
<ogra> qengho, yeah
<ogra> do we have a bug open for that ?
<pbek> ogra: will that fix the zombie problem?
<ogra> thats really something all desktop launchers should do themselves
<qengho> pbek: We can't know. One problem at a time, plz.
<ogra> pbek, it will fix the "readonly filesystem" error
<pbek> is there an example to create a shell wrapper?
<ogra> https://github.com/ogra1/jtiledownloader
<ogra> or wait
<ogra> https://github.com/ogra1/laidout
<ogra> that one is more like what you want
<pbek> thanks, ogra
<pbek> ogra: strange, snapcraft tells me it can't find the wrapper in: `'/home/omega/Code/_test/QOwnNotes-Snapcraft/prime/./wrapper.sh'`
<pbek> I placed it in the same directory as the snapcraft.yaml and it is executable
<ogra> pbek, add a copy plugin for it
<pbek> ogra: strange, https://github.com/ogra1/laidout/blob/master/snapcraft.yaml has no copy plugin
<ogra> it uses a make plugin and does the copying from the Makefile
<pbek> ah, in the makefile. I see
<pbek> snapcraft went through, but still the same error on the first run: ln: failed to create symbolic link '/home/omega/snap/qownnotes/x17/.themes/themes': Read-only file system
<ogra> hmm, when using the wrapper ?
<ogra> for me that usually fixes it
<pbek> yes, I use `command: ./wrapper.sh`
<ogra> weird
<pbek> btw. will there be a mountpoint for every revision of every snap be present until the end of uptime or are mountpoints for old revisions removed at some point?
<ogra> i think thats only happening for sideloaded snaps
<pbek> ah, ok
<ogra> snaps from the store only keep two mountpoints (and squashfses)
<ogra> while i develop i occasionallly call snap remove to clean that up
<ryanjdillon> Hi all, new to IRC here, and checking out nick registartion docs, is the following command to be ran in the chat? `/msg NickServ REGISTER password youremail@example.com `
<Kamilion> yep.
<ryanjdillon> thanks
<Kamilion> you can ask in #freenode for a hostmask cloak to hide your ip address once your nick is registered.
<Kamilion> probably end up with ~ryan@freenode/unaffiliated/ryanjdillon instead of ~ryan@2a02:fe0:cb10:53a0:d072:c794:a030:cdcf
<Kamilion> maybe it's now @unaffiliated/name... they might have dropped the freenode/ prefix these days, Iunno.
<Kamilion> welcome to IRC; don't forget to idle after asking questions in case someone answers several hours after you ask.
<ryanjdillon> hmmm... good to know. thanks!
<ryanjdillon> /msg NickServ VERIFY REGISTER ryanjdillon nnuanddphqwt
<Kamilion> uhhhhh
<ryanjdillon> It looks like everybody can see that. Is there anything important to know before I relive my old Diablo account hack?
<Kamilion> yeah, don't use that password
<Kamilion> good thing it looks randomish.
<dz0ny> type commands into server window not chan one :)
<Kamilion> it appears whatever IRC client you're using ignored the / to make that a command somehow.
<ryanjdillon> using pidgin on ubuntu
<Kamilion> Ah, libpurple, no wonder
<Kamilion> try /query nickserv
<ryanjdillon> here to get more developer insight, so guess that's a start ,)
<Kamilion> then type help in the new window it should make
<Kamilion> if you get a bunch of help text from nickserv, that window should work
<Kamilion> then you can drop the leading /msg nickserv from the command and just use the private message window to register.
<Kamilion> most irc services will respond to 'help' or 'help <something>', so don't be afraid to jab it. I've been ircing for 20 years and i never bother to remember all the commands, just that 'help' will tell me which commands whatever irc network i'm on will support.
<ryanjdillon> awesome. thanks for all the tips/help
<Kamilion> also other clients like weechat / xchat/hexchat / kvirc
<Kamilion> i happen to like kvirc; but it wants to pull in ~100mb of QT packages if they're not already installed from some other app
<ryanjdillon> ah ok. yeah, i'm not so into QT, but I will check those out.
<dholbach> pbek, I filed https://bugs.launchpad.net/snapcraft/+bug/1603403
<mup> Bug #1603403: [Regression] qownnotes in snappy-playpen stops building with snapcraft 2.12.1 <Snapcraft:New> <https://launchpad.net/bugs/1603403>
<dholbach> elopio, sergiusens: ^
<mup> PR snapd#1554 opened: store: Find now takes a Search instead of a query and channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/1554>
<dholbach> hikiko, nice work!
<hikiko> thanks for the help dholbach :)
<dholbach> anytime :)
<tsimonq2> ditto dholbach, nice job :)
<tsimonq2> hikiko: it's merged! :D
<dholbach> *I* didn't do much :)
<hikiko> well, you all helped me understand how snaps work, glad it's merged :)
<tsimonq2> \o/
<mup> PR snapcraft#662 opened: Update the debian/control file <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/662>
<mup> PR snapd#1555 opened: store, daemon, client, cmd/snap: implement `snap find --private` <Created by chipaca> <https://github.com/snapcore/snapd/pull/1555>
<tsimonq2> dholbach: could you please give your input on bug 1599125 ?
<mup> Bug #1599125: Allow Launchpad Git URLs <bitesize> <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1599125>
<pbek> thank you, dholbach
<Croepha> so, im just double checking, but ubuntu-core/rolling/edge is for 16 right?
<SamYaple> does snappy have any tests currently that validate teh base_plugin schema? I am not finding any
<renatu> guys I am trying create a snappy package for ubuntu-calendar-app based on this http://bazaar.launchpad.net/~ubuntu-calculator-dev/ubuntu-calculator-app/trunk/view/head:/snapcraft.yaml
<renatu> but I am getting this error:
<renatu> Parts 'desktop/qt5' and 'ubuntu-calendar-app' have the following file paths in common which have different contents:
<renatu> usr/share/pkgconfig/shared-mime-info.pc
<renatu> usr/share/pkgconfig/xkeyboard-config.pc
<renatu> how I can solve that?
<ogra> there is a new bug with the very latest snapcraft ... introduced yesterday ... so yu are lucky it seems :)
<ogra> you can add a removal stanza to your snapcraft yaml so the file is only there once
<ogra> see line 60 in https://github.com/ogra1/upnp-server/blob/master/snapcraft.yaml
<renatu> ogra, thanks
<renatu> yes I thought that I was crazy because I got it working some days ago :D. and then it start to fail without reason
<dpm> renatu, you might want to have a look at https://github.com/ubuntu/snappy-playpen/pull/179 - the clock app cannot use the the desktop launcher, so just for lucky coincidence it's not affected by the bug
<mup> PR ubuntu/snappy-playpen#179: Clock snap running on Unity 7 and Unity 8 <Created by dplanella> <https://github.com/ubuntu/snappy-playpen/pull/179>
<Croepha> so, im trying to build a kernel snap using the copy plugin, (because I only have the .debs) and im getting a [Errno 2] No such file or directory: '/home/cro/ics_build/parts/kernel
<tedg> How do I build a deb of snapd?
<ogra> debbuild ?
<ogra> dpkg-buildpackage ...
<tedg> That seems to say that I don't have the macaroon gopkg installed, but I do.
<mup> PR snapcraft#663 opened: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663>
<renatu> hey guys now I am getting: (qmlscene:30059): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
<renatu> when running my snappy
<ogra> did you add the gsettings interface ?
<renatu> yes
<renatu> ogra, like that?  plugs: [gsettings,unity7,opengl]
<ogra> https://github.com/snapcore/snapd/blob/master/docs/interfaces.md
<ogra> yeah, that should theoretically work
<renatu> did not solve the problem
 * ogra has no single app that uses gsettings ... cant help with that ...
<renatu> how to debug it?
<ogra> ask in gitter
<ogra> http://gitter.im/ubuntu/snappy-playpen
<ogra> i see that galculator uses gsettings
<ogra> https://github.com/ubuntu/snappy-playpen/tree/master/galculator
<ogra> so you might need tto use a desktop launcher
<renatu> I am using desktop-launcher already
<ogra> well, ask on gitter ... perhaps there someone knows
<renatu> thanks ogra
<SamYaple> is there anyway to create a non-prefixed /snap/bin/ command? right now I get /snap/bin/<snapname>.command
<SamYaple> I would like /snap/bin/command
<SamYaple> in this case my snap provides multiple commands I would like to address without the prefix
<ogra> you can only get rid of the prefix if you have a single command with the same name as the package i think
<SamYaple> ogra: thats definetely what I see, but thats a shame. i understand the reasons though
<ogra> you could wrap a shellscript around your commands with a case switch and have "snapname --command"
<SamYaple> im packaging an existing app with existing commands, anything I could do would change teh existing interaction with it
<ogra> not much better indeed :)
<SamYaple> so it wwouldnt be seemless
<SamYaple> is there a way to do like meta packages with snap?
<SamYaple> since all teh commands are unique I could have one snap, and then like 3 metasnaps named as the appropriate command... mabye?
<ogra> nope
<ogra> a snap is already a kind of meta package after all
<SamYaple> this is a pretty big blow to seemlessly replacing system installed packages
<ogra> well, file a whishlist bug ... not sure if that fits into the concept though
<SamYaple> im not sure if it fits with the concept ogra. havent seen the concept defined to well anywhere
<ogra> it is buried in some public google docs somewhere
<ogra> anyway, file a bug ... you will get feedback from one of the architects i guess :)
<SamYaple> of course. where else would it be :)
<SamYaple> yea i can't set the wishlist status, but I can certainly file a bug
<sborovkov> jamiebennett: Hi. Tried clearing private store id. Still can't install ubuntu-core - the same error (can not set next boot: cannot determine bootloader) pops up during the installation of security profiles.
<jamiebennett> ogra:  have you see issues installing ubuntu-core on classic RPi?
<jamiebennett> ^^
<ogra> i must admit i havent done that
<ogra> but i thought that bug got fixed a while ago ... zyga mvo ^^^^ ?
<jamiebennett> sborovkov: I guess you have already updated to the latest software on your Pi (apt update/upgrade ?)
<ogra> sborovkov, try "sudo touch /boot/uEnv.txt" and then try again
<ogra> (not sure if snapd still checks for that file though)
<ogra> (it might be checking for a mounted /boot/uboot nowadays, or fr some file below that)
<sborovkov> Did not update, just flashed the latest image I found.
<sborovkov> Updating now
<sborovkov> touch /boot/uenv.txt did not help
<ogra> then mkdir /boot/uboot and touch the same file underneth that dir
<ogra> (i really dont know what snapd looks for nowadays, but it must be something like that)
<ogra> theoretically it shouldnt check that bit at all in classic mode ...
<sborovkov> One sec, doing apt upgrade. May be it will be fixed after apt upgrade
<mvo> ogra: what is the error?
<ogra> mvo, "can not set next boot: cannot determine bootloader" ...
<ogra> mvo, on a RPi classic install
<ogra> i thought classic makes it skip the bootloader checks completely
<mvo> ogra: interessting - what version of snapd  is installed?
<ogra> sborovkov, ^^ ?
<mvo> ogra: yes it does
<ogra> ah, well, might be a 16.04.0 image ...
<ogra> which probably has an outdated snapd
<ogra> so lets wait til sborovkov has done his upgrade :)
<mvo> :)
<mup> Bug #1603481 opened: multiple binaries from the same package <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1603481>
<sborovkov> ogra: mvo: Alright, I upgraded but now I can't connect to my system via ssh as it does not receive address on DHCP for some reason. I will get back to you once I resolve that.
<mup> PR snapd#1556 opened: asserts: add Assertions.Prerequisites and Ref, SigninKey and FindTrusted <Created by pedronis> <https://github.com/snapcore/snapd/pull/1556>
<mup> PR snapcraft#653 closed: Implement `snapcraft push` <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/653>
<sborovkov> ogra: Yes, it works after upgrade. My bad for not upgrading first of all. Do you know where should I file the bug that internet connection is not working after upgrade? Had to manually attach keyboard and run sudo dhclient to get it working (and it's reproducible, flashed the image twice and upgraded)
<mup> PR snapd#1557 opened: many: introduce an assertstate task handler to (pre)fetch assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1557>
<ogra> sborovkov, well, thatsa generic ubuntu server bug ... not really sure where that should go ... prehaps ifupdown or systemd
<kyrofa> elopio, are you around?
<elopio> kyrofa: hello
<kyrofa> elopio, sergiusens asked me to investigate bug #1600238 today
<mup> Bug #1600238: [pull] Same packages pulled twice with different timestamps cause clash <Snapcraft:New> <https://launchpad.net/bugs/1600238>
<sborovkov> ogra: Ok. One more question - how do I install package from beta/edge channel?
<kyrofa> elopio, from the comments I can't quite glean what's happening there, but I'm able to reproduce it using dholbach's pastebin
<ogra> sborovkov, sudo snap install foo.snap -devmode --edge
<kyrofa> elopio, can you give me any more information before I dig in?
<ogra> *--devmode
<elopio> kyrofa: one part pulls the deb. Then other part pulls the deb too. Some files will get a different timestamp, which we consider as a conflict.
<kyrofa> elopio, they even have different md5sums!
<elopio> hum, that's not what they told me.
<elopio> so, what's different from the content?
<kyrofa> elopio, that's what I'm seeing anyway
<kyrofa> elopio, the file I'm specifically referring to is a .so
<kyrofa> So I'm not sure
<kyrofa> Very odd
<sborovkov> ogra: Hmm. I have UBUNTU_STORE_ID set in /etc/environment. But it does not try to install from there it seems
<sborovkov> :(
<ogra> ah, i have no clue about custom stores, sorry
<sborovkov> jamiebennett: ping
<ogra> the above works fine with the default store
<elopio> kyrofa: did you confirm they come from the same deb?
<sborovkov> Yeah, understood
<kyrofa> elopio, not yet, I was going to talk to you first, but you're apparently useless to me. Useless!
<kyrofa> elopio, ooo, they aren't from the same deb
<kyrofa> elopio, I'm starting to suspect this isn't even a bug
<elopio> :_)
<elopio> I'm just passing the information along. I haven't triaged it.
<kyrofa> elopio, I know, I'm just messing with you ;)
<elopio> kyrofa: if they come from a different deb, then what Daniel suggests makes no sense. But we still have a problem, when this happens, it's really hard to understand where the conflic comes from.
<kyrofa> elopio, yeah, libqt5gui5 from the desktop helper, and libqt5gui5-gles from the yaml
<kyrofa> elopio, I'm not sure how we might make that more clear, though. We can't really say "this came from that deb" because we don't even know that the file came from a deb at all
<elopio> kyrofa: wouldn't that be a deb bug? Why libqt5gui5-gles ship the duplicated lib?
<kyrofa> elopio, great question
<elopio> I mean, if we find that the archive shouldn't allow this to happen, there's nothing for us to do.
 * kyrofa checks the deb metadata, maybe they're supposed to conflict
<elopio> if there's no deb rule against it, then yes, we should find a way to make a nicer error.
<kyrofa> elopio, indeed, the libqt5gui5-gles deb has a "conflicts" with libqt5gui5. THAT'S the bug
<kyrofa> elopio, snapcraft needs to be able to toss errors about that
<kyrofa> elopio, still not an easy fix though
<kyrofa> elopio, and probably only a warning, since they can be filtered out with the stage/snap keywords
<elopio> kyrofa: ok, nice finding. And yes, I have no idea how to solve it. The list of packages might make sense again.
<boriseto> Hi, how do the snaps work actually? Like I have VLC installed via snap and apt, but it only shows the one with apt when trying to open a file?
<Croepha> snapcraft is wanting me to login, but im not sure why, im just trying to build a kernel snap, not upload it or anything
<Croepha> boriseto, look for a file in /snap/bin that points to vlc
<Croepha> that will be how to launch vlc in the snap
<boriseto> Croepha: got it. Thanks
<kyrofa> Croepha, because it needs to download the OS snap in order to obtain the initrd
<Croepha> kyrofa: ok thanks
<boriseto> Croepha: if I just do it like that, I still won't be able to set it as a default app in the System settings, right?
<Croepha> im not sure how default app works... does it take a path? or is it looking for a .desktop file?
<Croepha> if it takes a .desktop file, then you will have to craft one manually, using the /snap/bin path... but i think that should work, because it will pass the command like arguments to vlc, running inside the snap and it should run
<Croepha> you need to do some interface stuff that im not sure how to do in order for vlc to actually connect to Xorg, but it  should be simple id expect
<EdwardMorbius> hello, is there some problem with snaps at the moment? after using snap find or snap refresh I am getting a long error
<Croepha> EdwardMorbius: works for me...
<Croepha> paste the error?
<EdwardMorbius> Croepha snap find
<EdwardMorbius> error: cannot list snaps: Get https://search.apps.ubuntu.com/api/v1/search?fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha512%2Csummary%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cprivate%2Cconfinement&q=: dial tcp: lookup search.apps.ubuntu.com on [::1]:53:
<EdwardMorbius> read udp [::1]:54036->[::1]:53: read: connection refused
<Croepha> firewall? or regional issue?
<EdwardMorbius> It worked before, I am using ufw but it worked before, might be regional?
<Croepha> maybe
<Croepha> what continent are you located at?
<EdwardMorbius> europe
<Croepha> im na
<Croepha> so my observations probably aren't very useful to you
<EdwardMorbius> It might be something temporary
<Croepha> might want to run wireshark, and see if there is any related icmp traffic
<EdwardMorbius> also is the problem with running some snaps on nvidia proprietary drivers known and reported? some of them dont start on my computer with unrecognized opengl version type errors
<ogra> yes, known
<EdwardMorbius> ogra ok thanks
<ogra> (and snap find works fine here from germany)
<EdwardMorbius> I just tried removing a ubuntu clock snap and got another error
<EdwardMorbius> sudo snap remove ubuntu-clock-app
<EdwardMorbius> 2016-07-15T20:37:56+02:00 ERROR cannot remove snap file "ubuntu-clock-app", will retry: [stop snap-ubuntu\x2dclock\x2dapp-5.mount] failed with exit status 1: Job for snap-ubuntu\x2dclock\x2dapp-5.mount failed. See "systemctl status "snap-ubuntu\\x2dclock\\x2dapp-5.mount"" and "journalctl -xe" for details.
<EdwardMorbius> notes was removed successfully
<joc_> zyga: hi, is the field "Label" on the PlugInfo struct what jdstrand refers to when he says "security label for the plug"
<joc_> (in zigbee-dongle PR comments)
<joc_> hmm guess not, looks more likes something to be used in yaml for identifying plugs
<Croepha> so, when snapcraft is building a kernel, and grabbing the os image in order to build the initrd, how does it know which os image to use? like which version?
<kyrofa> elopio, sounds like we might need to get train tickets online
<elopio> kyrofa: do they have an hour, or are they good for the whole day?
<ogra> Croepha, it just uses the latest
<Croepha> cool
<kyrofa> elopio, and I can't figure out the difference between Heidelberg Hbf and Heidelberg Hauptbahnhof. ogra, help?
<ogra> (from the stable channel by default)
<ogra> kyrofa, its the same ... one is the abbreviation of the other
<kyrofa> ogra, what's the best way to get to heidelberg from FRA?
<kyrofa> ogra, argh. They show up in different places in the marriott map :P
<ogra> i guuess by train
<kyrofa> ogra, also both are options in the train destinations
<kyrofa> ogra, and that needs to be booked in advance, correct?
<Croepha> orga: what if i wanted edge
<josepht> kyrofa: Hbf is probably a shortcut ;)
<ogra> https://www.google.de/maps/place/Heidelberg+Hbf/@49.4042719,8.673773,17z/data=!3m1!4b1!4m5!3m4!1s0x4797c0d8fef51cbd:0x9b2b52faa371d535!8m2!3d49.4042719!4d8.675967?hl=de
<kyrofa> josepht, hahaha
<Croepha> actually it might now even be a big deal, ill see if it actually a problem first
<ogra> https://www.google.de/maps/place/Hauptbahnhof/@49.4042719,8.673773,17z/data=!4m5!3m4!1s0x4797c0d8dcf7aa13:0x1c97ffb21cfc7c77!8m2!3d49.404397!4d8.6769227?hl=de
<kyrofa> ogra, I dread someone asking where I'm trying to go. "hopt-on-hoff!"
<ogra> hauptbahnhof is actually a different waypoint on the map ... interesting
<ogra> (thy are 100m apart or so)
<kyrofa> ogra, indeed, a little confusing
<ogra> aha
<kyrofa> ogra, but no matter
<ogra> one is a tram station in front ... the other is actually the central station building
<ogra> so they are the same after all :)
<ogra> kyrofa, if you can get an ICE train from frankfurt to heidelberg that should be the most relaxing option
<zyga> joc_: no, he referred to apparmor labels
<ogra> Croepha, not sure the plugin offers that yet ...
<ogra> Croepha, https://bugs.launchpad.net/snapcraft/+filebug ;)
<Croepha> will do
<ogra> thx
<camako> I'm trying to run the ubuntu-calculator-app from a terminal under U7 as explained in https://developer.ubuntu.com/en/desktop/get-started/, but it just waits there. Syslog shows http://pastebin.ubuntu.com/19531599/ - an apparmor denial. What am I missing?
<kyrofa> ogra, looks like that eventually transfers to a "regional express" in mannheim?
<ogra> kyrofa, ^^ i assume the kernel plugin has no way to tell it wants the os snp from edge ?
<ogra> *snap
<kyrofa> ogra, unfortunately no, I seem to remember stable being hard-coded
<ogra> kyrofa, nothing direct from fra. to heidelberg ?
<kyrofa> Doesn't seem so
<kyrofa> But that's not a big deal
<kyrofa> ogra, what if I book a ticket and my flight is delayed?
<ogra> you can buy a ticket at the frankfurt airport
<joc_> zyga: can you tell me how to access the label?
<joc_> from my interface definition
<kyrofa> ogra, oh! Well then, elopio we can just do that
<ogra> i wouldnt pre-book
<elopio> kyrofa: sounds easier.
<kyrofa> ogra, okay, I didn't want to anyway
<kyrofa> elopio, indeed
<kyrofa> Thanks ogra :)
<ogra> and really, take an ICE ... power, wlan, restaurant (beer) ;)
<kyrofa> ogra, do you know if FRA has open wifi?
<ogra> it should, yep
<kyrofa> ogra, heh, that does sound nice
<ogra> might be time limited
<elopio> kyrofa: just save this in the phone, and play it to the person selling tickets: https://upload.wikimedia.org/wikipedia/commons/d/df/Heidelberg.ogg
<kyrofa> Hahaha :D
<kyrofa> elopio, and when they ask what stop I want?
<kyrofa> Just start making gutteral sounds?
<ogra> then you play it again ;)
<kyrofa> Haha
<elopio> kyrofa: https://upload.wikimedia.org/wikipedia/commons/b/b3/De-Berlin_Hauptbahnhof.ogg
<elopio> we need a remix.
<kyrofa> Ooo!
<kyrofa> Oh man, I was way off
<ogra> elopio, oh, you are evil :)
<kyrofa> Alright, I'm off to house hunt for a little bit. Be back soon
<elopio> so S banh or ICE, transfer in mannheim.
<tsimonq2> kyrofa: is that the only thing wrong with snapcraft#662 ? ;)
<mup> PR snapcraft#662: Update the debian/control file <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/662>
<jose__> I am trying the snapcraft "build your first snap" tutorial and I have build the snap, and installed it. How do I run it?
<Croepha> jose__ is it a daemon?
<jose__> that must be it, the yaml says its a simple deamon
<tsimonq2> jose__: whereis SNAPNAME
<tsimonq2> jose__: you can probably just run it
<Croepha> jose__ ok, if its a daemon, then it will be running automatically, and it will not be able to be run directly
<Croepha> jose__ get its status with: systemctl -a | your_snap_name
<Croepha> you can get the log output via journalctl -u <your app's service name>
<jose__> ok thanks that helps
<Croepha> can you bake a snap into a flash image?
<zyga> Croepha: ubuntu-image that is being developed might allow that
<zyga> Croepha: the device maker can design the partition layout
<zyga> Croepha: currently it is able of making only one "image" (e.g. all flash)
<zyga> Croepha: but it is just the first version so I bet more feaures will come
<Croepha> well, i dont need to change the partitions to bake in a snap to I? the snaps just reside on the root filesystem dont they?
<Croepha> mounted of course
<zyga> Croepha: yes, in /var/lib/snapd/snaps
<zyga> Croepha: that space has to be writable
<Croepha> i must be misunderstanding, im not sure what this has to do with partitions, but ubuntu-image sounds promising, i'll have to hunt it down
<monsterjamp> Hello
<monsterjamp> Can I run a bash script using snapcraft?
<Croepha> monsterjamp: yes
<monsterjamp> Croepha: How? I've been reading the documentation but can't seem to figure out how.
<Croepha> well, it may not be straight forward as you might expect, but any of the build plugins, like automake or python can be run a bash script indirectly
<Croepha> like you could make a Makefile, that runs a shell script
<Croepha> there may be a plugin that is more direct than that, but I don't know of it
<monsterjamp> I see, I guess that works.
<Croepha> you could write your own plugin for it
<monsterjamp> How do I write my own plugin?
<tsimonq2> monsterjamp: do you want it to be snap-specific or do you want to contribute it to Snapcraft?
<monsterjamp> tsimonq2 Snapcraft
<Croepha> im not sure if this is current, but: https://developer.ubuntu.com/en/snappy/build-apps/plugins/
<tsimonq2> Croepha: I don't think it is
<Croepha> might have better luck in the github repo
<Croepha> https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md
<tsimonq2> monsterjamp: yeah, git clone https://github.com/snapcore/snapcraft.git
<tsimonq2> monsterjamp: take a look at the existing plugins, write one, and make a pull request :)
<monsterjamp> Seems simple enough :O
<monsterjamp> Although I wonder why someone hasn't already made a bash plugin
<tsimonq2> I don't know :)
<Croepha> yea, it does seem pretty basic
<Croepha> there are quite a few things like that right now
<Croepha> but things are moving fast
<monsterjamp> Are you guys all snapcraft developers?
<Croepha> i am not really one
<Croepha> but i think most are
<tsimonq2> monsterjamp: I've contributed a little bit ;)
<tsimonq2> monsterjamp: so if/when you get a PR submitted, I'll be sure to take a look :)
<monsterjamp> :D
<monsterjamp> I haven't programmed much in python so forgive me in advance.
<tsimonq2> I was the same way when I started contributing :)
<monsterjamp> I'm getting this error when trying to use my bash plugin: 'Options' object has no attribute 'bash'
<monsterjamp> Not entirely sure what it means
<Croepha> monsterjamp you are trying to .bash on something?
<Croepha> can you paste your code?
<monsterjamp> Well so far I just copied the make plugin, I think I'm using the 'options" object wrong?
<monsterjamp> http://paste.ubuntu.com/19556135/
<Croepha> self.options['bash-arguments']
<Croepha> on line 74
<Croepha> i guess now that means im a contributor
<monsterjamp> 'Options' object is not subscriptable
<josepht> monsterjamp: I think you need 'self.options.bash_arguments'
<monsterjamp> I think that works
<monsterjamp> But why is it an '_' and not '-'
<Croepha> because - is an oporator
<Croepha> it was like options.bash minus arguments
<Croepha> so something is probably mangling the names to make it work within the language
<monsterjamp> I think it's working now :O
<monsterjamp> For the make plugin there's an additional command to run `make install` should I have something like that for the bash plugin?
<monsterjamp> nvm, I don't think it makes sense to leave that in
<Croepha> you know, for a bash plugin, it might make sense to have commands that you can run at any build step
<Croepha> like pull, or build
<monsterjamp> Croepha: I didn't even know it was for the plugins to do different things at each build step.
<monsterjamp> Is there a plugin that already does this?
<Croepha> i know there are atleast two
<monsterjamp> Which ones?
<Croepha> so if you look at https://github.com/snapcore/snapcraft/blob/master/snapcraft/_baseplugin.py
<Croepha> there are all kinds of methods that you can essentially override
<Croepha> clean_pull, build,  pull, clean_build
<Croepha> im thinking that pull and build are the only usefully ones to do a arbitrary command
<monsterjamp> Should I make another property to see if the user want the script to do anything during the pull?
<Croepha> thats what I would do
<Croepha> but its up to you
<Croepha> actually, its up to the maintainer
<monsterjamp> Well even if  the plugin doesn't get merged, it'll still be useful to use for myself.
<monsterjamp> I decided to keep the install part at the end.
<monsterjamp> What do you guys think of it: https://gist.github.com/monsterjamp/570fbfe8bbdf959d94486f293956fdbe
<monsterjamp> Shoud I add anything else?
<Croepha> i think thats good, but I really dont know anything
<monsterjamp> Alright, I made the pull request after a few tweaks.
<monsterjamp> https://github.com/snapcore/snapcraft/pull/664
<mup> PR snapcraft#664: New plugin: Bash <Created by monsterjamp> <https://github.com/snapcore/snapcraft/pull/664>
<monsterjamp> Looks like I'm faster than the bot :P
<Croepha> :)
<mup> PR snapcraft#664 opened: New plugin: Bash <Created by monsterjamp> <https://github.com/snapcore/snapcraft/pull/664>
<monsterjamp> tsimonq2 do you wanna check out the pull request?
#snappy 2016-07-16
<tsimonq2> monsterjamp: I saw, I'll check it out later or tomorrow :)
<monsterjamp> Alright, although I just realized I need to do more than just make the plugin. Apparently I need to make unit tests and integration tests.
<monsterjamp> So earlier today I was trying to make a snap which led me to making a web installer script for a dependency and then I ended up making a plugin for snapcraft to be able to run the web installer script.
<qengho> Nice.
<monsterjamp> So by trying to contribute to one project, I ended up contributing to 3 (kinda).
<qengho> monsterjamp: simple. I like it.
<monsterjamp> :D
<qengho> monsterjamp: So, if I don't include an build_arguments string, it doesn't run the script in the build stage?
<monsterjamp> Yeah however the string can be empty
<monsterjamp> build-arguments: []
<monsterjamp> I'm not sure if I should change the way the plugin works.
<qengho> monsterjamp: How about making thea args an array instead of a string? My arg has a space inside it. Getting that escaped through YAML is hard.
<monsterjamp> It is an array?
<qengho> Oh, it is!Cool.
<qengho> Looks like the default is already  [], so defining it as [] should change nothing. I think an empty list will be be false-y.
<monsterjamp> I see, I guess I have to change some things then.
<monsterjamp> I completely missed the "default []" line.
<monsterjamp> qengho I updated the plugin: https://gist.github.com/monsterjamp/570fbfe8bbdf959d94486f293956fdbe
<monsterjamp> Now there's another optional property called 'stages' which tells snapcraft which stages the script should be called in.
<tsimonq2> monsterjamp: I can help with unit and integration tests in a bit
<monsterjamp> tsimonq2 Thanks, that would be really helpful. I haven't ever really done anything to do with unit/integration test.
<monsterjamp> Although it looks rather straight forward.
<tsimonq2> they can be a pita so I'll help after I'm done eating. :)
<tsimonq2> monsterjamp: so let's start with this
<monsterjamp> :D
<tsimonq2> do you know waht unit and integration tests are?
<tsimonq2> *what
<monsterjamp> Well I'm guessing they're used to check if a feature works?
<tsimonq2> monsterjamp: yes that, but it also makes sure that the feature doesn't regress in the future
<monsterjamp> I see, but what are unit tests?
<tsimonq2> the unit tests are more of a Pythonic way to test things, if that makes sense
<tsimonq2> monsterjamp: so in Snapcraft we actually have three types of tests
<tsimonq2> static - syntax/typo check
<tsimonq2> unit - Pythonic testing of the code
<tsimonq2> integration - more of a real example testing
<tsimonq2> monsterjamp: so you should always make sure static passes first, because that might point out the obvious
<monsterjamp> I'm not sure what Pythonic means :P
<tsimonq2> call the functions in Python instead of the usual, user-facing way
<tsimonq2> monsterjamp: so let's look at your static tests here: https://travis-ci.org/snapcore/snapcraft/jobs/145144193
<monsterjamp> I fixed my script to pass the static tests here: https://gist.github.com/monsterjamp/570fbfe8bbdf959d94486f293956fdbe
<tsimonq2> then git add, git commit, git push
<tsimonq2> :)
<monsterjamp> kk
<monsterjamp> I pushed, I guess it'll take a while before travis-ci can check it again.
<tsimonq2> a little bit :)
<tsimonq2> I can tell you what's wrong with your unit tests, though
<tsimonq2> it prints the plugin list in several unit tests, and it expects a certain output
<tsimonq2> the problem with that is that it indents
<tsimonq2> so you need to go to all three of those failing tests and correct the errors :)
<monsterjamp> I'm a bit confused this is what I get for the unit test: http://paste.ubuntu.com/19576664/
<monsterjamp> But AFAIK that has nothing to do with my plugin?
<tsimonq2> well sometimes other things break when you add things :)
<tsimonq2> wait hm
<tsimonq2> monsterjamp: sudo apt install python3-tabulate
<monsterjamp> Oh, that makes sense.
<tsimonq2> monsterjamp: you *could* use pip but I usually prefer to do the package :)
<monsterjamp> Looks like I'm missingmore than one dependency
<monsterjamp> But the dependencies aren't even listed in HACKING.md
<monsterjamp> Looks like the unit test is working now
<monsterjamp> I gtg, I'll be back in 30mins
<monsterjamp> Actually nvm, I'll stay here for a bit longer.
<monsterjamp> tsimonq2 how long do these unit tests take?
<tsimonq2> flexiondotorg: between 5 and 10 mins
<tsimonq2> whoops sorry flexiondotorg
<tsimonq2> monsterjamp: between 5 and 10 mins
<monsterjamp> lol I see
<monsterjamp> tsimonq2 so am I supposed to get it to line up? Cause I can't seem to even get the list without "bash" to line up
<tsimonq2> monsterjamp: correct
<tsimonq2> monsterjamp: it takes some work ;)
<tsimonq2> monsterjamp: tip, instead of running all the unit tests over and over, you can do: python3 -m unittest snapcraft.tests.test_commands_list_plugins.ListPluginsCommandTestCase (for example)
<tsimonq2> monsterjamp: that will save you some time! :D
<monsterjamp> Oh, thanks that will be useful
<monsterjamp> tsimonq2 how does this look on your terminal? I can't get it to line up perfectly: http://paste.ubuntu.com/19580796/
 * tsimonq2 plays a bit with it
<tsimonq2> monsterjamp: well look at the output, it outputs what it expects as well
<tsimonq2> snapcraft.tests.test_commands_list_plugins.ListPluginsCommandTestCase seems to be easy to fix
<tsimonq2> + ant        catkin  copy  gradle  jdk     kernel  maven  nodejs             python2  qmake  tar-content
<tsimonq2> - ant        bash    cmake  go      gulp  kbuild  make   nil     plainbox-provider  python3  scons
<tsimonq2> sort of the same with snapcraft.tests.test_commands_list_plugins.ListPluginsCommandTestCase
<tsimonq2> wait...same test case?
<tsimonq2> you get my point, look at the travis logs
<tsimonq2> monsterjamp: this is going to be a HUGE pita, but you have to fix it... :/
<tsimonq2> wait I have an idea, I'll get back to you
<tsimonq2> see, if I disable these tests, build the Debian package, then install it on my system, I can get the same output it's expecting
<tsimonq2> then I can give that to you!
<tsimonq2> perfect!
<tsimonq2> monsterjamp: couldn't get it to work sorry
<monsterjamp> tsimonq2 :(
<monsterjamp> What is MAX_CHARACTER_WRAP? Is it equal to 65?
<tsimonq2> I don't know, sorry
<monsterjamp> If only I knew when it wrapped :/
<tsimonq2> monsterjamp: well it shows what it expects to look like and what it was presented in the error
<tsimonq2> monsterjamp: change it to what is presented :)
<tsimonq2> for example: AssertionError: 'ant        bash    cmake  go      gulp  kbuild  make[152 chars]nt\n' != 'ant        catkin  copy  gradle  jdk     kernel  mav[139 chars]ns\n'
<tsimonq2> + ant        catkin  copy  gradle  jdk     kernel  maven  nodejs             python2  qmake  tar-content
<tsimonq2> - ant        bash    cmake  go      gulp  kbuild  make   nil     plainbox-provider  python3  scons
<tsimonq2> ?  ^ ^^^^^^^^^^ ---           --                            -                                     ------
<tsimonq2> + autotools  cmake   go    gulp    kbuild  make    nil    plainbox-provider  python3  scons
<tsimonq2> ?  ^ ^^^^^          +          ++                 +
<tsimonq2> - autotools  catkin  copy   gradle  jdk   kernel  maven  nodejs  python2            qmake    tar-content
<monsterjamp> I see but what to the + ^ - adnd ? mean, it's overwhelming me :P
<tsimonq2> monsterjamp: compare it to what's in the code :)
<tsimonq2> does it want the line that has + or the line that has -?
<monsterjamp> I think I understand now
<tsimonq2> great :)
<tsimonq2> sorry I can't help more
<monsterjamp> You signing off?
<tsimonq2> no, just sorry I couldn't help more :)
<monsterjamp> I can't figure it out, I thought I understood the terminal output :(
<tsimonq2> monsterjamp: I'll help tomorrow :)
<monsterjamp> What time will you be on tsimonq2?
<tsimonq2> I have no clue, but sooner rather than later
<monsterjamp> Wait I think I figured it out. I have to modify  expected output too...
<monsterjamp> :/
<tsimonq2> yes! :P
<monsterjamp> I passed the 3 unit tests :O
<tsimonq2> monsterjamp: push! :D
<monsterjamp> tsimonq2 pushed :O
<tsimonq2> yay!
<tsimonq2> monsterjamp: so the build passed
<monsterjamp> :D
<tsimonq2> but coveralls failed
<monsterjamp> :(
<tsimonq2> which means you need coverage
<tsimonq2> what time zone are you in? just curious
<monsterjamp> GMT-6
<monsterjamp> It's midnight right now :P
<tsimonq2> 12:38 by me
<tsimonq2> same?
<tsimonq2> (AM)
<monsterjamp> :O
<monsterjamp> Where are you from? I'm from the suburbs of Chicago.
<tsimonq2> oh! I'm in Green Bay
<monsterjamp> So we're both on the east-most edge of the GMT-6 timzone
<tsimonq2> yep! :D
<mup> Bug #1555569 opened: [snaps] Show human-readable names for store apps <gnome-software> <sdoc> <Canonical Click Reviewers tools:New> <Snappy:New> <Software Center Agent:Fix Released> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1555569>
<tsimonq2> monsterjamp: I'm going to bed now, then I'll be up in the morning, then I'll be AFK from 12:30ish onwards, so can we talk then or won't you be around?
<mup> Bug #1603610 opened: Snaps have no screenshots <Snappy:New> <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1603610>
<monsterjamp> tsimonq2 Yeah I'll be on.
<tsimonq2> great, see you then :l
<monsterjamp> Probably arounf 9am-10am
<tsimonq2> o/
<monsterjamp> cya
<mup> PR snapd#1558 opened: client,cmd/snap: cleanup cmd/snap test suite, add extra args test <Created by pedronis> <https://github.com/snapcore/snapd/pull/1558>
<mup> PR snapd#1558 closed: client,cmd/snap: cleanup cmd/snap test suite, add extra args test <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1558>
<monsterjamp> Hello
<monsterjamp> tsimonq2 I passed the coverage test :D
<tsimonq2> :D
<kyrofa> This airport is boring. Anyone around?
<ali1234> kyrofa: if you are bored you could try to tackle my challenge from the other day. snap the qopenglwidget so that it runs on the EGLFS backend on raspberry pi.
<kyrofa> ali1234, no pi with which to test I'm afraid. I'm trying out let's encrypt instead
<mup> PR snapcraft#497 opened: Catkin plugin: Enforce C.UTF-8 locale <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/497>
#snappy 2016-07-17
<LBo> I wanted to try building a snap package so I decided to try build a go 1.7 snap
<LBo> The recommended way for building go is running ./make.bash
<LBo> Is there a snapcraft plugin for running shell scripts? Or should I solve this in another fashion?
<popey> i eneded up making my own plugin for things which have oddball build systems LBo
<popey> basically just a simple plugin which sets the environment up and calls the shell scripts required, one by one
<monsterjamp> LBo you're just in luck, I recently made a plugin to run bash scripts.
<LBo> monsterjamp: awesome
<LBo> Where can I find it?
<popey> yay!
<monsterjamp> One sec, I'll put it up on gist.github
<LBo> Thanks!
<monsterjamp> LBo: https://gist.github.com/monsterjamp/570fbfe8bbdf959d94486f293956fdbe
<monsterjamp> Just put this file in parts/plugins/
<LBo> monsterjamp: thanks! Seems to work great!
<monsterjamp> LBo: If you have any questions or suggestions, let me know.
<monsterjamp> Your welcome
<LBo> Now I have to find out how to set some env variables
<dz0ny> LBo: you have binary builds on download.golang.org, why not just package those?
<mup> PR snapd#1559 opened: network-observe: add device read support <Created by jaymell> <https://github.com/snapcore/snapd/pull/1559>
<verwilst> Hello! Wanted to make a snap for phpstorm, but the docs are awful..
<verwilst>  :(
<verwilst> I want to create a snap and a flatpak for the package, and see which one i prefer and stick with that
<verwilst> maybe somebody can point me in the right direction?
<monsterjamp> What do you need help with?
<verwilst> well.. it's a java app.. so i tried parts: jdk: plugin: jdk, but i hardly know what i'm doing.. :-) I wanted to download the tarball and extract it and go from there.. so i messed with plugin tar-content ( which seems absolete, it says to use copy, but can't find a connection between tar and copy :-p ), source-type: tar, etc..
<verwilst> obsolete*
<monsterjamp> Can I see your snapcraft.yaml file?
<verwilst> so then i dowloaded and untarred the package myself, and put the snapcraft.yml in the root folder
<verwilst> http://pastebin.ca/3660258
<verwilst> it's a concat from all different snippets and lines i've seen online :-p
<verwilst> http://pastebin.ca/3660260
<verwilst> maybe this is more like it
<verwilst> download/extract and then run a script ( i know i still need to add the apps thingy :-)
<monsterjamp> Hm... I'm not entirely sure how to use the copy plugin either :P
<verwilst> don't even know if i need the copy plugin
<verwilst> i just want to download and untar the archive :-)
<monsterjamp> verwilst: https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/simple-copy/snapcraft.yaml
<monsterjamp> Here's an example of how copy is used
<monsterjamp> verwlist are you able to make a snap if you download and untar it manually?
<verwilst> i'm not getting anywhere for now, so no :-)
<verwilst> even the yaml you showed me, src: dst,  srcdir: dstdir.. say what?
<verwilst> oh wait :-)
<verwilst> it doesn't support http
<verwilst> [Errno 2] No such file or directory
<monsterjamp> Also the website is forbidden
<monsterjamp> https://download.jetbrains.com/webidePhpStorm-2016.2.tar.gz
<monsterjamp> Actually I think you can use http in snapcraft
<verwilst> https://download.jetbrains.com/webide/PhpStorm-2016.2.tar.gz
<monsterjamp> It works now :O
<monsterjamp> Although I don't know where the files will be after it's extracted
<monsterjamp> How big is this file?
<verwilst> couple of 100MBs :-)
<monsterjamp> Oh...
<monsterjamp> http://paste.ubuntu.com/19818676/
<monsterjamp> This downloads the tar but it's gonna be a while before I know what copy does with the tar :/
<verwilst> that doesn't work right?
<verwilst> it does? uh
<monsterjamp> It works
<monsterjamp> Snapcraft is downlaoding the tar atm
<verwilst> but src: dst  doesnt make any sense :-)
<verwilst> any why copy after a download.. copy where.. :-p
<verwilst> but idd it downloads
<monsterjamp> I don't know, `snapcraft help copy` doesn't even explain what copy does :/
<verwilst> extracting..
<monsterjamp> You've already finished downloading ?
<verwilst> http://pastebin.ca/3660271
<verwilst> sure :-) I usually get around 25MB/sec
<monsterjamp> Does it extract the tar?
<verwilst> The copy plugin takes a list of files to just directly copy without building or downloading anything. In
<verwilst> yeah think so, since there was a big pause after downloading
<verwilst> although my stage dir is empty
<monsterjamp> It should be in parts/phpstorm/src
<verwilst> ls parts/download/src/
<verwilst> bin  build.txt  help  Install-Linux-tar.txt  jre  lib  plugins
<verwilst> that seems correct
<monsterjamp> I don't think you need the copy plugin, it's already extracted :O
<verwilst> http://pastebin.ca/3660279
<verwilst> well, i think the copy files: thing then allows you to copy the extracted contents to the stage dir..
<verwilst> 23:03:57 desktop ~/Downloads/phpstorm/PhpStorm-162.1121.38 $ ls stage/
<verwilst> bin  build.txt  help  Install-Linux-tar.txt  jre  lib  plugins
<verwilst> so now i might only have to specify an app
<verwilst> http://pastebin.ca/3660282 this seemed to download and install a jdk from the ubuntu repos..
<monsterjamp> That's weird...
<monsterjamp> verwilst: I think the easiest way to get your snap working would probably be to use my bash plugin: https://gist.github.com/monsterjamp/570fbfe8bbdf959d94486f293956fdbe
<verwilst> Snapped phpstorm_2016.2_amd64.snap
<monsterjamp> It worked :O
<monsterjamp> nvm then
<verwilst> not sure.. installed it
<monsterjamp> Did you add the apps section?
<verwilst> yup
<verwilst> bin/phpstorm.sh
<verwilst> there is a /snap/bin/phpstorm.test file now?
<verwilst> bash
<verwilst> is that the way to start apps?
<verwilst> http://pastebin.ca/3660285
<verwilst> http://pastebin.ca/3660286
<monsterjamp> Wait... Check parts/phpstorm/install
<monsterjamp> Is there a folder in there a bin folder there
<verwilst> yup
<verwilst> that folder seems to be the untarred source pkg
<monsterjamp> Try install the snap with the argument `--devmode`
<monsterjamp> Does the snap start?
<verwilst> devmode is in my yaml already
<monsterjamp> You have to specify it at install
<verwilst> confinement: devmode
<monsterjamp> The confinement is still strict if you don't install it with `--devmode`
<verwilst> ah ok
<monsterjamp> Or at least it is for me (could be a bug)
<verwilst> well, it started..
<verwilst> somehow
<verwilst> still it's strange to having to start a /snap/bin/phpstorm.test file
<verwilst> ooh
<verwilst> i named my app: test :-p
<monsterjamp> Yeah
<monsterjamp> Try typing `test` in the terminal
<verwilst> test is kinda taken i think :-p
<monsterjamp> lol
<verwilst> going to rename it
<verwilst> still, the jdk stuff seems fishy
<monsterjamp> Do you know how to use snappy-debug?
<verwilst> i should just have it as a dep
<verwilst> nope
<monsterjamp> Yeah I really don't like the plugins, they're limiting
<verwilst> /snap/bin/phpstorm.letmetrythis works
<verwilst> phpstorm.letmetrythis is in my path
<monsterjamp> verwlist: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
<verwilst> ah, it uses apparmor?
<monsterjamp> Yeah
<monsterjamp> In devmode the snap is given permission to everything.
<verwilst> but i guess an IDE has to have access to everything :-p
<monsterjamp> The part the documentation almost completely skips over is the interfaces
<verwilst> i think documentation is a big word :-p
<monsterjamp> I'm guessing you have to allow phpstorm to access the X11 interface
<verwilst> yeah, but disk-wise i mean
<verwilst> some put their code under Documents, some under Projects, some under PhpStormProjects, etc
<monsterjamp> I think that's under the home interface
<monsterjamp> https://developer.ubuntu.com/en/snappy/guides/interfaces/
<verwilst> Can access non-hidden files in $HOME
<verwilst> that's already a lot safer
<verwilst> no access to other settings or .ssh, .gpg
<monsterjamp> ssh might be under the network interfaces
<verwilst> i hope you can say 'but allow .phpstorm' for example
<monsterjamp> verwlist your snapcraft.yaml file will looking something like this: http://paste.ubuntu.com/19822190/
<verwilst> why network-control?
<verwilst> Can configure networking. This is restricted because it gives wide, privileged access to networking and should only be used with trusted apps.
<verwilst> it's an IDE?
<monsterjamp> I thought you mentioned ssh :P
<verwilst> .ssh
<verwilst> the place you put your private key
<monsterjamp> Oh :P
<monsterjamp> Snaps are currently really limited mainly because it's "too secure".
<verwilst> i wonder what will come of flatpak and snappy
<verwilst> but it's definitely the way forward
<monsterjamp> Me too, have you used flatpak yet?
<verwilst> nope
<verwilst> i will try to package phpstorm as well though
<verwilst> just to get the feel for it
<verwilst> java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable
<monsterjamp> I've been meaning to try out flatpaks but the whole repo thing overwhelms me.
<verwilst> with plugs: [X11, home, network]
<monsterjamp> What does the snappy-debug logs say?
<monsterjamp> If it works with devmode, it should work in strict mode with plugs.
<verwilst> Jul 17 23:30:22 desktop kernel: [ 8746.944817] audit: type=1400 audit(1468791022.946:540): apparmor="DENIED" operation="connect" profile="snap.phpstorm.phpstorm" pid=19790 comm="java" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined"
<verwilst> maybe it's lowercase
<monsterjamp> The permissions for snaps is still very confusing for me so I'm not sure how to fix that.
<verwilst> plugs: [x11, home, network]
<verwilst> going to try that
<verwilst> http://pastebin.ca/3660292
<verwilst> Invalid Log Path: Log path '/home/verwilst/.PhpStorm2016.2/system/log' is inaccessible.
<verwilst> :-p
<verwilst> as i thought
<monsterjamp> Is that the error you get when runnig snappy-debug?
<verwilst> no, when running phpstorm
<monsterjamp> Oh, well snaps are pretty limiting :P
<verwilst> so they seem..
<verwilst> well, thanks a lot for the help :-) At least i've gotten my toes wet ;-)
<monsterjamp> :D
<verwilst> bedtime!
<LBo> I created a snap for go 1.7 just to try it out
<LBo> dz0ny: that's true but I wanted to
<LBo> http://paste.ubuntu.com/19825355/
<LBo> When running /snap/bin/golang17.go17 version I get this error: "execv failed: Permission denied"
<LBo> What could be the problem here?
<LBo> I've enabled devmode but that didn't solve the problem
<monsterjamp> LBo: Did you install it with the `--devmode` argument?
<LBo> not yet
<LBo> I'm going to try that
<LBo> Did that. Same error
<LBo> dmesg doesn't show anything useful
<LBo> [2250360.316093] systemd[1]: snapd.refresh.timer: Adding 1h 43min 31.266732s random time.
<LBo> [2250360.576927] audit: type=1400 audit(1468792753.293:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.golang17.go17" pid=3709 comm="apparmor_parser"
<monsterjamp> I'm not really sure then, afaik if it doesn't work in devmode it won't work at all :/
<LBo> monsterjamp: ok, thanks for looking at it!
<LBo> sudo /snap/bin/golang17.go17 works
<tsimonq2> hey monsterjamp, I'm back :)
<LBo> If I copy it out of /snap/golang to my home directory and run it it runs fine
<LBo> Doing an strace results in this: http://paste.ubuntu.com/19829595/
<LBo> Googling that error message in strace leads back to: https://github.com/snapcore/snap-confine/blob/master/src/sc-main.c#L70
#snappy 2017-07-10
<Populus> Hiya
<__chip__> my main machine is doing the cute "don't POST, blink some leds" routine, so I'll probably spend some time with a screwdriver and a cursebook
<zyga> re
<__chip__> zyga: o/
<zyga> __chip__: hey :)
<__chip__> zyga: how's poland?
<zyga> __chip__: just as we left it, I think
<zyga> not much has changed
<zyga> (including the reasons for not being here in the first place)
<zyga> in other news, we're looking to move out ASAP
<zyga> but unable to for some time
<zyga> how's UK?
<zyga> still U?
<__chip__> zyga: out of the place, or the country?
<zyga> the place
<__chip__> ah, phew
<zyga> being in the country for now will help
<__chip__> UK still divided, still better than ar :-)
<zyga> "universally divided, we stand united" or something
<__chip__> sounds about right
<__chip__> anyway, i need to go find a screwdriver
<zyga> how are things, I'm sorry I was off all morning but I was stuck in "register your company" webbrowser windows hell
<__chip__> zyga: <__chip__> my main machine is doing the cute "don't POST, blink some leds" routine, so I'll probably spend some time with a screwdriver and a cursebook
<ogra_> wow, i hadnt one doing that in a decade i think
<zyga> __chip__: ouch, I hope it's nothing serious
<zyga> __chip__: in case you need a spare machine, I have some still boxed, just come to warsaw and collect it
<zyga> __chip__: PC speaker helps
<zyga> but if it doesn't post and you didn't pour coffee on it, it's the RAM
<zyga> hey ogra_ for a moment I was wondering if you were referring to setting up a company or having a machine not post
<zyga> must be morning
<zyga> mvo: how's everything?
<ogra_> lol
<mvo> zyga: good morning, looking at the tsync issue on trusty currently, mostly understood I think
<mvo> zyga: there is the open question what to do about it, I will write a forum post about it I think, we have some options, not exactly sure which is the best one just now
<__chip__> zyga: numlock and scroll lock on, caps lock blinking, led machine --> RAM issue
<__chip__> zyga: https://www.parts-people.com/blog/2014/07/02/dell-latitude-e6400-led-post-codes-diagnostic-indicators/
<__chip__> s/led machine/dell machine/ :-)
<zyga> __chip__: did anything happen to your machine or power grid since it last worked?
<ogra_> your obsolescence-counter is full :)
<zyga> mvo: this is about the "re-execed" version of the tool being unsuitable for older systems?
<mvo> zyga: correct, its a combination of issues.
<mvo> zyga: the best option is probably to statically link snap-seccomp on the core snap - the downside is that the debian/rules modification is ugly
<zyga> mvo: is that a per "go build" option?
<zyga> mvo: one idea we might try is to run ld-so on snap-seccomp
<zyga> mvo: not sure if you think this is sensible
<mvo> zyga: I tried that and things segfaulted
<zyga> oh, that's interesting (and unfortunate)
<zyga> how did you run it?
<mvo> zyga: I did not investigate the segfault further tough
<zyga> (I was hoping to use this approach for other things0
<mvo> zyga: I can look again
<zyga> not urgent, just curious
<mvo> zyga: I don't get anything useful from gdb,  i use the same commandline as CommandFromCore() is using
<zyga> I see
<mvo> zyga: funny enough, even LD_LIBARARY_PATH=... ldd ./usr/lib/snapd/snap-seccomp core dumps
<mvo> zyga: ok, anything does, hm, hn
<Chipaca> huzzah!
<mvo> zyga: aha, getting closer, broken symlinks
<zyga> lip 10 11:28:47 fyke kernel: audit: type=1400 audit(1499678927.313:439): apparmor="DENIED" operation="capable" profile="/snap/core/2329/usr/lib/snapd/snap-confine" pid=19314 comm="snap-confine" capability=4  capname="fsetid"
<zyga> mvo: curious if this is not one of our chown's
<mvo> zyga: could be, where do you see this?
<pstolowski> Chipaca, #3569 updated
<Chipaca> pstolowski: looking
<Chipaca> hmm, something is still not happy with this box
<Chipaca> psftw: thank you!
<Chipaca> uh
<Chipaca> pstolowski: ^
<pstolowski> Chipaca, ty!
<mvo> zyga: CommandInCore now also works, things look good, need to clean that up a bit more though
<mvo> zyga: but at least things move forward
<zyga> mvo: just running hello-world.evil
<zyga> mvo: I installed aa-notify
<Chipaca> wellp, and now a kernel BUG thing
<Chipaca> sounds like i need to re-reseat the memory and run memtest for a while
 * Chipaca declares victory over the ram monster, in order to tempt it early
<mup> PR snapd#3576 opened: tests: snap debug confinement does not exists yet in 2.26.x <Created by mvo5> <https://github.com/snapcore/snapd/pull/3576>
<mvo> zyga: I created the forum topic now about the snap-seccomp, I wonder what the best way forward is, it could be either static linking or using osutil.CommandFromCore() - I lean towards the later
<zyga> mvo: let me read and comment
 * zyga experiments with apparmor tracing on 2nd computer
 * Son_Goku grumbles about fontconfig
<Son_Goku> libfontconfig isn't thread-safe, woo :(
<Chipaca> Son_Goku: party yeah party woo </vihart>
<Son_Goku> this happened, which is why I'm grumbling about libfontconfig: https://github.com/hughsie/appstream-glib/issues/177
<Chipaca> Son_Goku: (that's a reference to https://www.youtube.com/watch?v=4niz8TfY794&feature=youtu.be&t=212 fwiw -- sorry if it was obscure :-) )
<Chipaca> anyway, machine seems moderately happy, i'm off for a run and lunch will bbl
<niemeyer> Good mornings
<Son_Goku> niemeyer: morning
<mvo> jdstrand: hey jdstrand, good morning! I looked into the tsync issue with snap-seccomp on trusty this morning and wrote whats going on in https://forum.snapcraft.io/t/2-26-8-libseccomp-on-trusty/ - let me know what solution you prefer
<jdstrand> mvo: good morning, lookingn
<jdstrand> looking*
<zyga> jdstrand: hey, after you are done with that, can you please have a look at https://forum.snapcraft.io/t/apparmor-profile-caching/1268 and https://forum.snapcraft.io/t/using-snap-update-ns-from-snap-confine-to-initialize-mount-namespaces/1266/1 please
<jdstrand> mvo: done
<niemeyer> Sorry, running late for the standup.. will be there in a second
<jdstrand> zyga: looking
<mup> PR snapcraft#1400 opened: lxd: Distingish FileNotFoundError if not installed <bug> <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1400>
<zyga> jdstrand: thank you :)
<cachio> mvo, zyga, about the snap-seccomp error? any idea why the lib is not there? is it related to the other issue?
<mvo> cachio: could you please pastebin the exact error again? I suspect it is just a spec file update, i.e. I think the binary is not copied into the right place for some reason. is this happening with master?
<cachio> mvo, it is happening with the fedora branch
<cachio> mvo, https://paste.ubuntu.com/25061349/
<cachio> I'll rebase again to discard any other problem
<mvo> cachio: could you please also show e the link for the fedora branch?
<cachio> mvo, https://github.com/snapcore/snapd/pull/3505
<mup> PR snapd#3505: PLEASE IGNORE: Enable more tests for suse and fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
<zyga> cachio, mvo: I'll resolve 3505
<mvo> zyga: ta
<Chipaca> mvo: was your "thank you" on sil's snapd#3574 a +1?
<mup> PR snapd#3574: snap find only searches stable <Created by stuartlangridge> <https://github.com/snapcore/snapd/pull/3574>
<mup> PR snapd#3531 closed: interfaces: updates default, mir, optical-observe, system-observe, screen-inhibit-control and unity7 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3531>
<mup> PR snapd#3574 closed: cmd/snap: snap find only searches stable <Created by stuartlangridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3574>
<pstolowski> cjwatson, hey! do you want to make the simple change to #3501 suggested by Samuele, so we can land it?
<cjwatson> sure, give me a minute to run tests and such
<Chipaca> woo, mwhudson got the golang fix backported and sitting in xenial-proposed :-D
<cjwatson> pstolowski: done
<mup> PR snapd#3409 closed: tests: fix snap confine from core test to check the restart was done <Created by sergiocazzolato> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3409>
<pstolowski> cjwatson, thanks
<Chipaca> snapd#3478 is a nice easy review, if anybody's looking for something to do
<mup> PR snapd#3478: tests: extend upower-observe test to cover snaps providing slots <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3478>
<Chipaca> (it's already got one +1)
<ppisati> ogra_: i'm using this ubuntu core pi3 img: http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-pi3.img.xz
<ppisati> ogra_: but i can't get any overlay to load, how is that?
<Chipaca> snapd#3481 is a slightly more involved PR, but still straightforward, needing a second review
<mup> PR snapd#3481: tests: add avahi-observe interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3481>
<ogra_> ppisati, you need to unpack the overlays.tgz
<ogra_> iirc in stable we still had that only as tarball
<ogra_> ppisati, this got fixed shortly after the first stable release, but since we cant update gadget content yet tsble still has the initial setup with the tgz
<ogra_> s/tsble/stable/
<ppisati> ogra_: i unpacked that in /boot/uboot where the rest of the boot fw resides, modified config.txt accordinlgy but nothing is loaded
<ogra_> it needs to be in an "overlays" subdir
<ppisati> ogra_: if i build a beta image, would it work? or is there a pre-baked image that i can use?
<ogra_> the blob has the path hardcoded
<ppisati> ogra_: yes, it's in /boot/uboot/overlays/*
<ogra_> ppisati, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
 * ppisati tries the current
<ogra_> that loads the vc4 overlay by default
<ppisati> ogra_: ok
<ogra_> so i'm 100% prositive that overlays work
<ppisati> ogra_: ooook
<mup> PR snapd#3501 closed: store: orders API now checks if customer is ready <Created by cjwatson> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3501>
<mup> PR snapd#3481 closed: tests: add avahi-observe interface test <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3481>
<mup> PR snapd#3399 closed: many: add the interface command <Decaying> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3399>
<mup> PR snapd#3495 closed: tests: remove snapd before building from branch <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3495>
<mup> PR snapcraft#1401 opened: Correct capitalisation for PyPI <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/1401>
<pachulo> hey! how do you delete a snap from the store?
<mvo> niemeyer: I updated https://forum.snapcraft.io/t/2-26-8-libseccomp-on-trusty/1265 - if you have a moment, it would be great if you could have a look and comment. no rush, I have dinner now and call it a day soon
<niemeyer> mvo: Will definitely do, thanks for that
<cachio> zyga, any idea why it could be failing? https://paste.ubuntu.com/25062665/
<cachio> zyga, it is happening on fedora
<sergiusens> tyhicks: jdstrand hi there, mind directing me to the snappy security whitepaper?
<tyhicks> hey sergiusens
<tyhicks> jdstrand: I'm getting a 404 for the whitepaper (https://developer.ubuntu.com/snappy/guides/security-whitepaper) is this an updated copy? http://people.canonical.com/~davidcalle/core/Whitepaper:%20Ubuntu%20Core%2016%20-%20Security.pdf
 * sergiusens waits for confirmation
<cachio> Son_Goku, hey
<Son_Goku> cachio: hi?
<zyga>  z
<zyga> cachio: looking
<cachio> Son_Goku, I am now working on morphis stuff to make snapd tests work on fedora
<Son_Goku> cachio: who are you?
<cachio> Son_Goku, I am sergio, we meet on london
<zyga> cachio: no idea
<Son_Goku> ah
 * zyga returns to fighting his network issues :/
<cachio> zyga, any idea bout the issue with snap-seccomp ?
<cachio> did you take a look?
<cachio> Son_Goku, I am trying to fix the tests for fedora and I see this issue trying to build the snapd binary
<cachio> error: File not found: /usr/src/packages/BUILDROOT/snapd-1337.2.26.4-2.x86_64/usr/lib/snapd/snap-seccomp
<cachio> Son_Goku, did you see that before?
<cachio> morphis told you something about that one?
<morphis> cachio: I guess the snapd rpm packaging isn't yet updating to include that binary
<cachio> morphis, you mean the spec to build it is missing?
<morphis> I guess so
<morphis> snap-seccomp seems to be a really recent addition
<cachio> morphis, ok, I'll try to add that
<cachio> morphis, thanks
<morphis> great
<morphis> np
<jdstrand> davidcalle: hey, it appears https://developer.ubuntu.com/snappy/guides/security-whitepaper is 404
<jdstrand> davidcalle: also, http://people.canonical.com/~davidcalle/core/Whitepaper:%20Ubuntu%20Core%2016%20-%20Security.pdf is out of date, should be rc9
<jdstrand> tyhicks, sergiusens: fyi ^
<sergiusens> jdstrand: thanks, do you have it on your p.c.c ?
<jdstrand> sergiusens: I do not, davidcalle manages it, but I gave you the link to the source doc in privmsg
<jdstrand> you could export to pdf from there
<DeeJayh> Is there a way to use the ubuntu core without snaps? I used to use the core on minimalist builds to have only what I need/want kind of like a archlinux/gentoo style build if you will
<jdstrand> DeeJayh: others may say point you at something different, but Ubuntu Core must use snaps and isn't a building block for an apt-based system. you probably want to consider the netboot images: http://cdimage.ubuntu.com/netboot/
<jdstrand> DeeJayh: actually, I think http://cdimage.ubuntu.com/ubuntu-base/ is better for that
<jdstrand> DeeJayh: see https://wiki.ubuntu.com/Base
<DeeJayh> you're a god
<DeeJayh> *bows*
<DeeJayh> Thanks jdstrand I had no idea this existed
<jdstrand> it has gone through a few different names over the years
<DeeJayh> I was aware of netboot but it didn't fit my needs, that base build is exactly what I've been dreaming of lol
<DeeJayh> I used to compile core before it became snappy
<jdstrand> cool, glad it fits your needs :)
<jdstrand> right
<jdstrand> that was one of the names. since ubuntu-core as a minimal os and Ubuntu Core were confusing, they renamed ubuntu-core ubuntu-base
<DeeJayh> sounds like a good call on their part lol
<DeeJayh> the only other question I have, because I am unfamiliar with the architectures, for ARM devices, is the arm64 64bit and armhf the 32bit?
<DeeJayh> nvm quick google search alleviated my curiousity lol thank you again
<davidcalle> jdstrand: pdf should be up to date now, PR for redirects waiting to be merged and deployed, sorry for the delay
<davidcalle> Will update the source comments once it's done
<jdstrand> davidcalle: ok, thanks! (tyhicks, fyi ^)
<tyhicks> thanks
<mwhudson> Chipaca: you ok to do the verification on that?
#snappy 2017-07-11
<Son_Goku> oh man
<Son_Goku> you've got to be kidding me
<Son_Goku> mvo forked the golang seccomp bindings? :(
<Son_Goku> is there a chance of a happy re-merge?
<Son_Goku> oh wait, this fork is trivial
<Son_Goku> it's just to do weird things with old libseccomp
<mup> PR snapd#3577 opened: packaging/fedora: Fix build for snapd <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
<mup> PR snapd#3500 closed: store: talk to api.snapcraft.io for assertions <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3500>
<lukav> hello
<lukav> is it possible to deploy a single out of tree built kernel module inside a snap? without making a kernel snap?
<Chipaca> lukav: I don't think so, but maybe?
<Chipaca> lukav: I mean, it's not supported as far as I know, but it might be possible
<lukav> Chipaca: there is a kernel-module-control interface in the reference, but I don't know if I need to load the module by a custom script or snap can be configured to do that automatically
<Chipaca> lukav: yes. But can that interface be used to insmod things from your snap?
<Chipaca> lukav: how would you support the different kernels?
<lukav> Chipaca: I will have to try insmoding it, not sure how to go about different kernel version support
<Chipaca> lukav: what are you trying to do?
<lukav> Chipaca: I'm trying to use a camera that requires patching the uvc kernel module
<Chipaca> lukav: it sounds like you're building a device / gadget / thing
<lukav> Chipaca: it will probably end up as a custom ubuntu core device image, but I'm trying to explore my options
<Chipaca> lukav: if your end goal is to have something like a device, you'll presumably be able to control the kernel, so that part'd be fine
<Chipaca> control as in decide which one gets installed, not necessarily roll your own
<Chipaca> the kernel-module-control interface is manually connected, but it'd probably work for development
<Chipaca> lukav: give it a try and let us know how it goes :-)
<lukav> Chipaca: I was initially thinking to have both options, have a snap of my application that can provide the option to access that type of camera by loading a custom uvc kernel module, and a custom device image with the required kernel and application snaps installed
<lukav> Chipaca: sure, thanks for the info
<mup> PR snapd#3578 opened: store: talk to api.snapcraft.io for purchases <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3578>
<pstolowski> Chipaca, +1 on #3554 with two very minor comments
<Chipaca> pstolowski: yep, was responding to one of 'em
<Chipaca> pstolowski: you mean to say you don't think having png image data in the journal is useful?
<Chipaca> pstolowski: I don't know what you're talking about
 * Chipaca sends an mp3 too, for good measure
<Chipaca> "this is what the server sounded like as it was dying"
<pstolowski> Chipaca, I mean numbers vs strings
<Chipaca> i know, i know
<Chipaca> as i say, that's fine; they're always strings (or []bytes, and then i suddenly honestly don't care)
<Chipaca> without a clear non-nonsense use case, i shall continue not caring
<mup> PR snapd#3576 closed: tests: snap debug confinement does not exists yet in 2.26.x <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3576>
<mup> PR snapd#3579 opened: snap-seccomp: link libseccomp statically to snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3579>
<pstolowski> Chipaca, that's fine. it was just to check if you are aware of any actual numbers there and if you aren't, that's ok
<zyga> test...
<zyga> \o/
<zyga> mvo: are you reading this?
<Chipaca> zyga: I don't know if mvo was, but I was reading it
<zyga> Chipaca: yay!
<zyga> so I *may* have working multi-homed network now
<zyga> on an old sempron class PC
<zyga> (screw you arm)
 * zyga had a very long night
 * zyga shuts the whole network contraption and moves it to the desired location
<Saviq> davidcalle, hey, any word on https://developer.ubuntu.com/snappy/guides/mir-snaps ?
<zyga> whee
<zyga> desk assembled
<ppisati> ogra_: edge was still running pi2-kernel #30 when #34 was available, so i released #34 in edge
<ppisati> ogra_: now i found a problem with it, if i release #30 back to edge to i cause breakage or what?
<ppisati> *do i
<ogra_> ppisati, thanks ... while i'd really like us to keep edge for manual uploads when testing stuff, we shouldnt exclude it from the auto uploads ... i wonder if thats possible in one of brads scrips
<ogra_> ppisati, if you release 0 it should update (well, actually downgrade) again
<ppisati> ogra_: 0?
<ogra_> *if oyu release 30 (sorry brokwn 3 here)
<ppisati> ogra_: ok, me tries
<ogra_> what was the prob ?
<ogra_> if the boot fails it will auto-rollback anyway
<ogra_> if it is more subtle like a broken driver it wont indeed
<ppisati> ogra_: no, the dtb overlay files had the wrong extension (.dtbo)
<ogra_> ah
<ppisati> ogra_: well, actually that's the correct extension, it's just that our bootloader is old and doesn't know it
<ogra_> we shoould update it then :)
<ppisati> ogra_: so first i fix that part, than i update the bootloader in the archive, test everything, then we can revert this fix and pick the new bootloader tpgether
<ogra_> so at least with fresh images from edge you get the right thing
<ppisati> ogra_: actually, it didn't break anything because daily images still had the overlay from #30 in /boot/uboot/overlays/
<ogra_> i need to re-work the whole gadget stuff anyway ... ondra did the dragonboard already, but pi is still behind
<ppisati> ogra_: but if i didn't roolback it, i would break overlay in today's daily
<ogra_> (make it build from upstream u-boot and all )
<ppisati> ogra_: yes, the gadget update part is really important for us
<ppisati> ogra_: in stable we are still shipping an old kernel with known vulnerabilities
<ogra_> well, the update bit is the jjob of the snapd team ...
<ogra_> i'll adjust the gadgets to use it but first i need the infrastructure
<ppisati> ogra_: ack, anyhow, the rollback worked
<ppisati> ogra_: so now i can got get some lunch and later fix this overlay rename thing
<ppisati> ogra_: ta
<ogra_> ppisati, right, that is why the blobs and dtbs should in the future be shipped with the kernel snap
<ppisati> ogra_: did you see this?
<ogra_> and be copied in place ....
<ogra_> see what ?
<ppisati> ogra_: ah crap, it wasn't pushed yet, hold on
<ppisati> ogra_: here is for the dragonboard - 4833c0343531aee507e80771c83c086da7488a71
<ppisati> ahhhhhhhh
<ppisati> ogra_: https://patchwork.ozlabs.org/patch/780737/
<ppisati> ogra_: and here is for the raspi2 - https://patchwork.ozlabs.org/patch/781277/
<ppisati> tought for the raspi2, we need the wireless package to enter the archive
<ppisati> it builds on LP though, but it'll break locally
<ogra_> because we cant force PPAs
<ogra_> you could add a "prepare" scriptlet that downloads the deb and uses dpkg -x or so
<ogra_> (nice btw)
<ogra_> (or simply add an extra part that pulls it from the upstream github branch)
<ogra_> (it is just binary firmware after all)
<ppisati> ogra_: me goes out for lunch, we can discuss about it later again
 * zyga breaks for lunch and will catch up with everyting
<mup> PR snapcraft#1402 opened: Better explain dependency link processing <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/1402>
<mvo> fgimenez: I have a 2.26.9~ppa2 in edge on amd64, could you please double check that this fixes the issue you saw on trusty?
<fgimenez> mvo: sure! on it
<mvo> ta
<mup> PR snapcraft#1398 closed: tests: fix issues with python 3.6 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1398>
<mup> PR snapcraft#1401 closed: Correct capitalisation for PyPI <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1401>
<mup> PR snapcraft#1393 closed: python plugin: output json in pip list <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1393>
<zyga> Chipaca: hey
<zyga> Chipaca: standup time?
<niemeyer> Chipaca: Oops.. wrong channel.. yeah, that ^
<niemeyer> :)
<mup> PR snapcraft#1375 closed: tests: allow to filter tests in docker <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1375>
<mup> PR snapcraft#1383 closed: autotools: Enable cross-compilation support <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1383>
<mup> PR snapcraft#1396 closed: rust plugin: unset http_proxy for test_cross_compile <Created by chihchun> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1396>
<Son_Goku> cachio, mvo: travis/spread failures in https://github.com/snapcore/snapd/pull/3577
<mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
<Son_Goku> not sure what happened
<cachio> Son_Goku, there are some errors to build fedora, I fix them in https://github.com/snapcore/snapd/pull/3505
<mup> PR snapd#3505: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
<Son_Goku> ah
<Son_Goku> cachio, so then that means the fedora test shouldn't be enabled yet anyway
<cachio> Son_Goku, trying to enable fedora tests for main test suite
<mup> PR snapd#3051 closed: interfaces: add consoles interface <Blocked> <Decaying> <Created by femdom> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3051>
<cachio> Son_Goku, you can fix that error by changing in the file tests/lib/prepare-project.sh as I did in that PR
<jdstrand> mvo: hey, looking at https://github.com/snapcore/snapd/pull/3579 you've decided to just use what is in the archive instead of embedded the upstream source? (I read the forum posts but wasn't sure)
<mup> PR snapd#3579: snap-seccomp: link libseccomp statically to snap-seccomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3579>
<Son_Goku> cachio: https://github.com/snapcore/snapd/pull/3577
<mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
<Son_Goku> I added your commit
<mvo> jdstrand: I hit a bit of a roadblock with the embedding releated to tests, gustavo suggested some possible workarounds
<cachio> Son_Goku, nice, I'll take a look to the results
<jdstrand> mvo: yeah, that is what I read, but the new PR seems to just use archive packages, correct?
<jdstrand> (which I happen to prefer in terms of security tracking)
<mvo> jdstrand: correct
<mvo> jdstrand: its as minimal as possible
<mvo> jdstrand: exploring with fgimenez currently if it really fixes all the issues
<jdstrand> mvo: ok, I wasn't sure another larger PR didn't sneak in-- it was so small :)
<mvo> jdstrand: so because I hit this roadblock, I decided to try the static linking first to unblock us. I'm a bit worried about timing mostly, I want to release. and I think the static linking is not a bad solution, we can still do the full embedding later (once the problem with the tests is better understood)
<jdstrand> mvo: I commented with +1. Like I said, I personally prefer this PR's approach with my Ubuntu security team hat on, so if you never circle back around, I'm still happy ;)
<Son_Goku> mvo, I don't particularly prefer to statically link if I don't have to
<Son_Goku> can we make this an ubuntu-only special somehow?
<Chipaca> zyga: niemeyer: oops, sorry for not letting you know: i had an annual echp review meeting at standup time
<zyga> Chipaca: echp?
<Chipaca> zyga: ehcp, typo
<zyga> ehcp? :D
<Chipaca> zyga: boys' school stuff
<zyga> ah :)
<zyga> such a fancy name
<Chipaca> zyga: âeducation, health and care planâ
<Chipaca> i've got two of those every year, and a couple of "mini" ones every four months
<zyga> embedded hampster cthulu party
<Chipaca> JamieBennett: but the good news is, the other ones i thought were actually this month are in august instead \o/
<Chipaca> Son_Goku: are the followup commits on snapd#3577 because it failed to actually work once it started actually trying to run tests?
<mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
<Son_Goku> Chipaca: yes
<Chipaca> Son_Goku: sorry if this sounds uppity, but i'm glad i asked for that then :-D
<Son_Goku> cachio pointed them out to me
 * Son_Goku should also make a script to generate fancy from-git changelogs like the ones mvo does for debian packaging
<zyga> Son_Goku: woot, thanks!
<Son_Goku> zyga: this doesn't fix everything, as there's still problems with the test suite
<Son_Goku> and spread is still being flakey
<zyga> Son_Goku: but it moves a lot towards where it should be
 * Son_Goku shrugs
<Son_Goku> it was mentioned at the sprint that the spec wasn't working with git master
<zyga> Son_Goku: I wanted to sync with downstream packaging but I wasted 15 hours on raspberry PIs and other SBC and my modem connection
<Son_Goku> and no one wanted to actually fix it, so I just pulled my pending changes and pushed them
<zyga> Son_Goku: now I even have my desk assembled, soon will be back to operational status
<zyga> Son_Goku: I love how you improved the packaging btw :
<zyga> :)
<Son_Goku> well, I was horrified by the mvo5 fork of seccomp-golang
<Son_Goku> then I looked at the fork and was like, "nah, I don't care"
<Son_Goku> so I forced it back to mainline
<Son_Goku> the benefits of not using vendored go deps :)
<zyga> Son_Goku: I just send some review your way
<zyga> Son_Goku: I think the quoting is off
<Son_Goku> I ripped it from the original commit in a different PR
<Son_Goku> if it's wrong, I'll clean it up
<zyga> Son_Goku: I think it's wrong
<zyga> Son_Goku: try it out
<Son_Goku> yeah, I think it's wrong
<Son_Goku> zyga: done
<zyga> Son_Goku: approved
<Son_Goku> now we wait for spread to fail
 * zyga moves modem contraption to the attic, offline for 5 minutes
<Son_Goku> :)
<Saviq> kalikiana_, hey, does this ring a bell http://pastebin.ubuntu.com/25068497/? same happens with container builds... the part is just nil plugin with some stage-packages...
<mup> PR snapcraft#1402 closed: Better explain dependency link processing <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1402>
<fgimenez> mvo: after adding the reboot all works fine with 2.26.9 on 14.04 http://paste.ubuntu.com/25068518/ \o/
<zyga> :-)
<fgimenez> mvo: i've tried with reexec both disabled (the default for the sru validation) and enabled, in this case only a few tests, the prepare step which was failing passes now
<jdstrand> sergiusens, tyhicks: thanks to davidcalle, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/. This is a redirect to the new location at https://developer.ubuntu.com/core/documentation
<tyhicks> very nice
<cachio> Son_Goku, you got another error about permission denied to install packages
<coreycb> jdstrand: should the openstack auto-aliases should be enabled automatically at this point at install time? i'm on xenial with snapd 2.26.8.
<cachio> Son_Goku, apply the change in tests/lib/pkgdb.sh from my P
<cachio> R
<cachio> Son_Goku, it is to fix that problem
<coreycb> jdstrand: they don't appear to be, at least for keystone.  but first time using auto-aliases so could be a user error.
<Son_Goku> zyga told me to remove it :P
<Son_Goku> I'll add it back in a bit
<Son_Goku> about to drive
<cachio> Son_Goku, I am gonna lunch, I'll be back in 20 minuteas
<mvo> fgimenez: nice, so all tests looking good so far? great to hear
<fgimenez> mvo: yep, to be extra sure i've triggered the full suite with reexec enabled and is good so far 121/175
<mvo> fgimenez: much appreciate your care on this, thank you
<fgimenez> mvo: np, thank you for finding the solution!
<jdstrand> coreycb: they should be in effect. let me check something
<niemeyer> Lunch, biab
<pstolowski> fgimenez, hey, I think you addressed the comments to #3489? if so I'm going to merge it
<fgimenez> pstolowski: hey, let me check
<fgimenez> pstolowski: indeed, the changes mentioned in the review were mistakingly done in spread.yaml, all fixed now
<pstolowski> fgimenez, thanks
<fgimenez> pstolowski: np thank you
<mup> PR snapd#3489 closed: tests: add bluetooth-control interface test <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3489>
<jdstrand> coreycb: there is a bug in the store that led me to enter the wrong snap declaration
<coreycb> jdstrand: ah, ok
<jdstrand> coreycb: I'll followup with the store team
<coreycb> jdstrand: sounds good, thanks
<jdstrand> coreycb: actually, strike that. it was only the snap declaration that was wrong. keystone should be fixed now
<coreycb> jdstrand: cool i'll give it a shot
<Saviq> sergiusens, hey, does this ring a bell http://pastebin.ubuntu.com/25068497/? same happens with container builds... the part is just nil plugin with some stage-packages...
<sergiusens> no it really doesn't ring any bell. I can try that here... it only fails on containers? if it is a cleanbuild, add `--debug` at the end and you should get a shell
<jdstrand> coreycb: I just fixed glance, neutron and nova. nova-hypervisor was not affected. verified locally with snap install and 'snap aliases'
<jdstrand> coreycb: sorry for the hiccup
<coreycb> jdstrand: np!  it's looking better.  going for a full deploy now. if you don't hear back from me i'm all good.
<fgimenez> i'm EOD'ing now, see you tomorrow o/
<untoreh> can I disable seccomp in snapd ?
<Chipaca> untoreh: tell me more
<untoreh> I am trying to run anbox and dmesg is dumping audit with sig=31 so I want to disable seccomp, anbox is using bpf
<mup> PR snapd#3580 opened: store: configurable base api <Created by atomatt> <https://github.com/snapcore/snapd/pull/3580>
<Chipaca> untoreh: anbox is only available as a devmode snap
<Chipaca> untoreh: so the seccomp things are warnings only
<Chipaca> untoreh: (if they weren't, your application would've been terminated)
<zyga> Chipaca: 31 is SIGSYS
<zyga> Chipaca: seccomp doesn't have advisory mode
<Chipaca> zyga: oh, i thought it did? bah :-(
<ogra_> Chipaca, anboox is a classic snap ...
<Chipaca> nope
<ogra_> well, the installer at least
<Chipaca>   beta:      1-dev     (15) 357MB devmode
<Chipaca>   edge:      3-7fc8bb4 (37) 357MB devmode
<Chipaca> zyga: i thought it had advisory mode, but not return-error-instead-of-dying mode
<Chipaca> shows how much i know about that side of things =)
<zyga> Chipaca: nope, it has kill or do nothing modes today
<zyga> where nothing includes not logging
<Chipaca> then i don't know how untoreh is seeing what they're seeing
<Chipaca> maybe they're installing it with --jailmode ?
<Chipaca> anyhow, eod for me
<Chipaca> cuppa tea and guitar
<Chipaca> o/
<mup> PR snapd#3505 closed: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3505>
<untoreh> the installer is classic, andbox is dev
<untoreh> the bpf profiles are @complain
<zyga> untoreh: that is equal to no-op for now
 * zyga_ got routing metrics reversed
<zyga_> now things actually should behave /o\
<zyga_> why isn't home network not just "snap install smart-home-router"
<cachio> niemeyer, about the PR 3505 that you recently closed, I have all the test cases fixed for fedora
<cachio> it is ok if I reopen this
<cachio> this PR has some overlap with the 3577
<cachio> the idea is, once the 3577 is merged, then I'll remove the code to fix the building from the 3505 and then I'll propose it for reviewing
<mup> PR snapd#3505 opened: PLEASE IGNORE: Enabling main test suite for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
#snappy 2017-07-12
<nacc> hrm, i've been seeing some ProxyError's from the lp snap builders (worker earlier today and stopped for the last three): https://launchpadlibrarian.net/328378888/buildlog_snap_ubuntu_xenial_i386_git-ubuntu_BUILDING.txt.gz
<nacc> cjwatson: --^
<nacc> it seems to be a perm error when trying to get the core snap?
<mup> PR snapd#3581 opened: Add polkit authorization support to /v2/login <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3581>
<elopio> !tryme
<baymax-elopio> It works !
<mup> PR snapd#3579 closed: snap-seccomp: link libseccomp statically to snap-seccomp <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3579>
<elopio> !tryme
<baymax-elopio> It works !
<zyga> good morning
<pstolowski> morning!
<mup> PR snapd#3582 opened: Merge release 2.26.9 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3582>
 * zyga hugs mvo
<mup> PR snapd#3583 opened: tests: fix econnreset test in 2.26 (store urls changed) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3583>
 * mvo hugs zyga
<mwhudson> er all my classic snap builds failed
<mwhudson> downloading the core snap failed with
<mwhudson> HTTPSConnectionPool(host='api.snapcraft.io', port=443): Max retries exceeded with url: /api/v1/snaps/download/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_2314.snap (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 403 Forbidden',)))
 * zyga fixes a typo in fedora build
<zyga> (space exploding typo)
<zyga> Pharaoh_Atem: can you please allow me to push to https://github.com/snapcore/snapd/pull/3577
<mup> PR snapd#3577: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3577>
 * zyga -> quick breakfast
<zyga> mvo: I have a fixed fedora branch, if Pharaoh_Atem doesn't respond soon (it's early for US so I don't expect him to) we can just push that to a separate branch and close his PR
<zyga> mvo: together with your fix for econreset it should fix master
<mvo> zyga: sounds good
<zyga> /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 14: fw_printenv: command not found
<zyga> hmm
<cjwatson> nacc: Yes, see RT#104230
<cjwatson> mwhudson: ^- you too
<zyga> mvo: since I "care" more about it now, I will improve proxy support for qemu testing
<cjwatson> nacc,mwhudson,stokachu: classic snap builds should be fixed now; try again
<mup> PR snapd#3577 closed: packaging/fedora, tests: Fix build for snapd and enable a test for Fedora <Created by Conan-Kudo> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3577>
<mup> PR snapd#3584 opened: packaging: fix Fedora support <Created by zyga> <https://github.com/snapcore/snapd/pull/3584>
<Son_Goku> zyga, you could have just asked for me to turn your ability to push on
<zyga> Son_Goku: I did :)
<zyga> Son_Goku: (earlier above)
<Son_Goku> you asked the wrong me :)
<Son_Goku> but anyway, it's on
<zyga> Son_Goku: I poked Pharaoh_Atem though, sorry about not realizing both of your accounts were on
<zyga> thanks!
<zyga> did you turn it off before?
<zyga> I wonder why it wasn't on in the first place
<Son_Goku> zyga: I turn it off by default because sometimes people rewrite commits without telling me
<zyga> Son_Goku: aha, good
<zyga> Son_Goku: I was just curious if some github default changed
<Son_Goku> and I really hate it when I'm attributed to things I didn't do :)
<zyga> Son_Goku: I will have one more fedora improvement for testing in a moment
<Son_Goku> okay
<Son_Goku> well, you can reopen my PR and push there
<zyga> this one is already in progress (testing) so it would not be any diferent
<zyga> all of your commits are there alreday :)
<zyga> (unchanged)
 * Son_Goku shrugs
<Son_Goku> okay then
<mup> PR snapd#3582 closed: Merge release 2.26.9 back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3582>
<mup> PR snapcraft#1403 opened: lxd: Only remove container if one exists <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1403>
<zyga> curious
<zyga> mvo: so...
<zyga> mvo: I bet that fedora doesn't provide libseccomp.a
<zyga> mvo: ... :-(
 * zyga wants to start entertaining alcoholic addition
<mvo> zyga: right, we can link it dynamically there
<mvo> zyga: we really only need the static build on the core snap
<Son_Goku> mvo: which is why I asked about it yesterday :)
<Son_Goku> technically... libseccomp.a *does* exist, though
<zyga> Son_Goku: it does? (my fedora box is not unpacked yet)
<zyga> Son_Goku: which package is it in?
<Son_Goku> all static link libraries are separated out into -static subpackages
<zyga> ah
<zyga> perfect
<zyga> I'll make it happen then
<Son_Goku> ugh
<zyga> Son_Goku: for today that's the best way
 * Son_Goku groans
<Son_Goku> fine
<zyga> Son_Goku: we can expore build tags and dynamic linking but mvo needs to get this out
<Son_Goku> wait, are we going to have 2.27 today or something?
<zyga> Son_Goku: I personally would love to drop libseccomp and just genrate bpf from go (because I'm a compiler addict)
<zyga> Son_Goku: that's a question for mvo
<Son_Goku> please don't make me cry
<Son_Goku> golang makes me sad
<Son_Goku> the ecosystem is nuts
<ogra_> great, aint it ? so you only need blots for functional apps ;)
<ogra_> *bolts
<Son_Goku> I've even heard from ex-Googlers that most Googlers hate golang
<zyga> Son_Goku: why?
<Son_Goku> the development experience is really bad
<zyga> Son_Goku: (I really really like writing precise bpf programs from snapd directly)
<Son_Goku> and maintaining golang packages is obnoxious
<zyga> Son_Goku: anyway, not arguing about golang being nice or not
<Son_Goku> like, as in with the way vendoring works and whatnot
<Son_Goku> at least one person told me there are more people who like D than there are who like golang
<Son_Goku> it's pretty much the domain of the borg group
<Son_Goku> (which makes kubernetes)
<sil2100> Hello! I have a question related to the snapcraft.yaml 'install:' bit that can be defined for a given part
<sil2100> I can't find any documentation
<sil2100> When is that run? At which step?
 * zyga doesn't get the vendoring argument (vendoring is a fact, how does golang make it different from python, ruby, C and others?)
<Son_Goku> the problem is that golang vendoring works based exclusively off of git commits
<Son_Goku> which makes things way more brittle than you think
<Son_Goku> zyga, also, not having a debugger unless you use gccgo sucks ass
<zyga> Son_Goku: debugger yeah, but then again golang behaves differently from other languages, I rarely use debugger in python (and when I did it was because C exploded)
<Son_Goku> but python provides tracebacks and repl capabilities
<zyga> Son_Goku: golang has tracebacks as well
<Son_Goku> golang compiler failures are inscrutable, too
<Son_Goku> as we found out a couple of weeks ago
<zyga> Son_Goku: ??!
<zyga> well
<zyga> those were very much not golang but gccgo and on unsupported arch, right?
<Son_Goku> zyga: we weren't using gccgo
<zyga> Son_Goku: all I'm saying is that daily hacking on golang code is anything but bad
 * Son_Goku shrugs
<zyga> Son_Goku: on ppc64 we were, I tink
<Son_Goku> I've had to figure out failures on armv7hl before
<zyga> hl?
<zyga> offtopic
<Son_Goku> armv7l with hfp (hard-float)
<zyga> ah
<Son_Goku> debian calls it armhf
<zyga> hf in debian land
<zyga> right
<Son_Goku> but the internal architecture name is armv7hl
<zyga> offtopic: I found my warcraft 2 CD
<Son_Goku> ooh nice
<zyga> and it's slightly scratched :-(
<Son_Goku> Nooo :(
<zyga> I'm playing the soundtrack
<zyga> but some tracks (my fav) are not working
<Son_Goku> ah, the days where games abused CDAudio for music :)
<zyga> yeah
<zyga> tack 2 and track 3 are very nice
 * zyga looks at fedora VM prep
<mvo> zyga, Son_Goku: you could simply sed aways the #cgo LDFLAGS: -Wl,-Bstatic via the spec file if you want to get rid of the static linking
<mvo> that seems like the simplest option for now
<mup> PR snapd#3585 opened: many: configure store from state, reconfigure store at runtime <Created by atomatt> <https://github.com/snapcore/snapd/pull/3585>
<Son_Goku> welp, that's up to zyga now, I can't do anything anymore
<Son_Goku> he closed my PR :)
<Son_Goku> mvo: but at least, my spec compiled as of yesterday
<mvo> zyga, Son_Goku: re 2.27 - I want to discuss this today, my idea is to have a 2.27~rc1 today and see if it behaves well everywhere (it got more churn than usual). and if that looks ok a real 2.27 EOW maybe
<Son_Goku> okay
<mvo> Son_Goku: \o/ for the spec work
<mvo> Son_Goku: or maybe early next week, but definitely soon as its overdue
<zyga> mvo: sounds like a plan
<Son_Goku> yeah, it's a couple months overdue :P
<Son_Goku> I was hoping for 2.27 to be in Fedora 26
<mvo> *cough*
<davidcalle> sil2100: check out https://snapcraft.io/docs/build-snaps/scriptlets
<sil2100> davidcalle: oh! Thanks! I see it there
<zyga> ugh
<zyga> why does my fedora VM use de keymap?
<zyga> why doesn't localectl change it :/
<Son_Goku> because you're nuts and you have too much stuff
<zyga> *V-M*
<Son_Goku> you need to use set-keymap
<Son_Goku> with localctl
<zyga> I did
<zyga> but I was foolish
<zyga> to assume "en" is sane
<zyga> I wanted "us"
<zyga> en is just the same as "de", just worse
<Son_Goku> :/
<zyga> keys are all over
<zyga> us works, I can do what I wanted
<zyga> eh, my wired network caps at 0.5MB/s
<zyga> because yeah, that's why
<Son_Goku> mvo: well, I'll just ship it as an update
<Son_Goku> it's no biggie
<Son_Goku> it's not like it's a pain to ship updates :P
<zyga> yeah, that's true :-)
<zyga> later today I'll try to put my fedora box up so I can have real hardware to work on
<zyga> Son_Goku: so, where is libseccomp-devel-static?
<Son_Goku> it's just libseccomp-static
<zyga> (took my a while but now I have a shell)
<zyga> ah
<zyga> thanks!
<Son_Goku> "dnf repoquery *-static" will give you a list of them all
<zyga> ok, pushed to 3584
<zyga> tests fine locally
<Son_Goku> :/
<zyga> what's wrong?
<Son_Goku> do you know how to use "git rebase" with arbitrary remotes?
<zyga> Son_Goku: yes
<zyga> Son_Goku: first add the remote
<zyga> Son_Goku: then fetch
<zyga> Son_Goku: then just reabse against remote/branch
<Son_Goku> yep
<Son_Goku> I'm a bit weirded out by the merge commit in PR#3584 then
<zyga> Son_Goku: I didn't rebase, I merged master
<zyga> Son_Goku: note that snap-seccomp is a part of snapd, not snap-confine
<Son_Goku> I'm aware
<zyga> Son_Goku: and the distinction is more less arbitrary now
<Son_Goku> yes, it's for my own sanity
<Son_Goku> meh, I don't care
<Son_Goku> I'll resync everything later from Dist-Git
<zyga> not sure I understand
<zyga> ok
<zyga> I can move it around
<zyga> I want to land this to unbreak fedora and then we can polish the layout
<Son_Goku> yeah, go ahead
<zyga> so what is the layout you want?
<Son_Goku> I prefer keeping security stuff together, and the C stuff typically lives in snap-confine
<Son_Goku> because snapd is already insane enough as it is, I try to keep things separate in such a way I know which parts to touch every time something breaks
<fgimenez> mvo: a test just failed on db http://paste.ubuntu.com/25074862/, other than that things are looking very good
<zyga>  oh
<zyga> how did that happen?
<mvo> fgimenez: what is the output of /usr/lib/snapd/snap-seccomp there? and that is the revision of the core?
<fgimenez> mvo: this was executed on testflinger, i don't have access to the testbed, the scenario is the basic beta image, core should be from beta without refreshes
<mvo> fgimenez: found it
<mvo> fgimenez: please re-run
<fgimenez> mvo: sure on it
<zyga> geez, tests are sure slow today
<mvo> fgimenez: there was an error on snapcraft release for the arm64 revision, now its good
<fgimenez> mvo: great thanks!
<zyga-suse> re
<mup> PR snapd#3583 closed: tests: fix econnreset test in 2.26 (store urls changed) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3583>
<zyga-suse> thanks!
<zyga-suse> a small observation, I patched spread to spawn 4 core VMs and this cut a good 3 minutes out of 15 minute run of fedora tests/main/help
<zyga-suse> s/15/18/
<zyga-suse> so down from 18 minutes before to 15 minutes after
<zyga-suse> mvo: bummer
<zyga-suse> mvo: time exceeded
<zyga-suse> another hour wasted
<zyga-suse> on 3584
<zyga-suse> mvo: please advise, do you want to merge it anyway or re-run
<mvo> zyga-suse: can we increase the workers or something? I would really like to not override this
<stokachu> cjwatson: thanks building now
<zyga-suse> mvo: let me check
<zyga-suse> pushed update with more workers
<mvo> ta
<zyga-suse> though what has failed seems to be ubuntu-16.04-64
<zyga-suse> I think that one could use x10 workers (up from 4)
<zyga-suse> I can try and see what we get
<zyga-suse> (say up to 6)
<zyga-suse> 24 VMs for each git push
<zyga-suse> that's $$$
<cachio> zyga-suse, did you get a timeout for fedora?
<zyga-suse> no
<zyga-suse> travis 49 minute timeout
<cachio> ok, because it is not needed to increase the number of workers for suse and fedora if they they running one test
<cachio> zyga-suse, do you have a link to see the timeout ?
<zyga-suse> yes but I cannot paste it ... one sec
<zyga-suse> https://travis-ci.org/snapcore/snapd/builds/252773594?utm_source=github_status&utm_medium=notification
<cachio> zyga-suse, there was a problem with linode that caused the several machines were discarded
<cachio> zyga-suse, that caused the delay on the execution
<cachio> zyga-suse, I'll monitor that to see if it happen again
<zyga-suse> mvo: it passed!
<zyga> mvo: can you please review 3584
<zyga> cachio, fgimenez: can you please review it from the POV of incresed worker count
<Son_Goku> zyga-suse: you dropped the increased capacity for fedora/opensuse :(
<zyga-suse> Son_Goku: because cachio will increase it in his branch that unlocks +100 tests
<Son_Goku> ah
<zyga-suse> Son_Goku: he's already done this for Fedora, going through suse
<zyga-suse> Son_Goku: this branch doesn't need the extra workers here (yet)
<zyga-suse> fgimenez, cachio, mvo: shall I decrement the workers back to 4?
<cachio> cachio, I think so
<cachio> zyga-suse,
<cachio> zyga-suse, I'll try to see what is happening with those machines that are discarded
<cachio> zyga-suse, but it seem to be a problem in linode
<fgimenez> zyga-suse: sure on it
 * Son_Goku sighs
<Son_Goku> it works now, can't we just merge it?
<Chipaca> zyga-suse: I'm wondering where 'suse' fits in https://en.wikipedia.org/wiki/Japanese_honorifics
<zyga-suse> oh :) ?
<zyga-suse> heh :)
<zyga-suse> Chipaca, niemeyer: after you discuss the services API I'd like to know if the evolution of that idea has any impact on the interfaces api
<zyga-suse> Son_Goku: I'd like to
<Son_Goku> then hit the green button
<zyga-suse> mvo: can you make a call?
 * Son_Goku hypnotizes mvo to say 'yes'
<zyga-suse> Son_Goku: I need more reviews
<zyga-suse> Son_Goku: offtopic, in my language we often use "no" to indicate "yes" and "nie" to indicate "no"
<zyga-suse> Son_Goku: we also have "tak" which is just "yes" but "no" is used very often
 * zyga-suse fetches tea
<cachio> zyga-suse, just move the workers to 4 and push, you will have a green in 40 minutes
<cachio> zyga-suse, otherwise we will be wasting resources for all the pushes
<zyga-suse> done
<zyga-suse> let's see
<mvo> zyga-suse: lets wait for another run, 2.27 is still in ~rc so things are not super urgent just yet
<zyga-suse> mvo: yep, sounds good
<zyga-suse> if you can review the change it would accelerate the time to landing (once green)
<Chipaca> zyga-san, I don't think it impacts the interfaces api, at least in the short term
<Chipaca> zyga-san, there'll still be a /v2/apps/ endpoint with nice juicy appy stuff
<Chipaca> zyga-san, and a /v2/logs/ for all your woodworking needs
<zyga> Chipaca: aha, I see, thank you
<zyga> Chipaca: I see you are feeling honorific today :)
<Chipaca> zyga, you started :-p
<zyga> me?
<Chipaca> âzyga-suseâ :-)
<zyga> Chipaca: LOL :D
 * Pharaoh_Atem sighs
<Pharaoh_Atem> back to the grind
<ogra_> fgimenez, the dragonboard-kernel in edge is quite a bit behind the other channels, any objections to bumping it to the same version the others have ?
<fgimenez> ogra_: any at all , in fact we currently start using it at beta, hopefully will be watching edge changes for db soon, thanks!
<ogra_> great, thanks !
<zyga> mvo: fedora fix merged
<mup> PR snapd#3584 closed: packaging: fix Fedora support <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3584>
<Saviq> cjwatson, hey, does LP reuse/cache instances it builds snaps on? alan_g's seeing weird behaviour after fixing snapcraft.yaml - it failed on 50% of arches... https://launchpad.net/~alan-griffiths/+snap/mircade-snap
<cjwatson> Saviq: there's no reuse, no
<Saviq> why would we ever see "Skipping pull... (already ran)" thenÂ¿?
<cjwatson> Saviq: because LP runs snapcraft more than once
<sergiusens> Saviq: because launchpad builders run each command
<Saviq> ah separately, ok
<sergiusens> they first run `snapcraft pull` and then the others
<sergiusens> this is from the time of only having network during pull
<cjwatson> yeah, it's slightly historical now, but meh
<Saviq> then there's a race of some kind...
<cjwatson> yeah, you're doing a parallel build so my money is on a bug in that build system
<cjwatson> try it in cleanbuild a few times maybe
<Saviq> well, "that build system" being snapcraft, as far I can tell...
<Saviq> since it tries to operate on a part directory it's not created yet
<sergiusens> Saviq: install should be created. What is not is the leaf directory of `usr`
<Chipaca> zyga: are you (or is somebody) working on getting spread running on opensuse again?
<sergiusens> Saviq: may I be so bold so ask you to look in your cmake given the `-j4` (you can disable parallel builds in the yaml)
<Saviq> sergiusens, it fails on the games part, which uses the nil plugin
<Saviq> and is just a dump stage-packages dump
<Saviq> dumb, even
<sergiusens> Saviq: oh, I am looking at https://launchpadlibrarian.net/328470482/buildlog_snap_ubuntu_xenial_i386_mircade-snap_BUILDING.txt.gz
<sergiusens> what should I be looking at?
<Saviq> sergiusens, yeah, that's it, [Errno 2] No such file or directory: '/build/mircade-snap/parts/games/install/usr'
<cachio> zyga, we are doing "dnf -y -q upgrade" when we prepare the project on fedora and it could be skipped
<cachio> zyga, is it right?
<cachio> no need to refresh metadata if using dnf
<zyga-suse> cachio: not sure if, I think it might have been there for a reason
<Saviq> sergiusens, oh and btw, cleanbuild --debug does not give me a shell after this failure :/
<zyga-suse> cachio: we do a similar "apt-get update"
<sergiusens> Saviq: unfortunate :-/
<sergiusens> Saviq: that failure however is from running the miral part (`games`)
<Saviq> sergiusens, why would the miral part try and look in the "games" part's folderÂ¿?
<cachio> zyga-suse, the problem is that the dnf upgrade is not the than apt update
<cachio> it is upgrading the system
<zyga-suse> Pharaoh_Atem: ^ should we skip that?
<zyga-suse> cachio: let's try, once it starts failing we can make spread-cron do the updates
<fgimenez> mvo: just got this error in the from-archive scenario on xenial http://paste.ubuntu.com/25075603/, in this case snapd is not built from branch, the deb package is installed from proposed and core is installed from beta (and not modified)
<fgimenez> the same scenario passed ok on trusty
<alan_g> Saviq: retrying armhf worked, i386 didn't (retrying that now). So "racy build" seems plausible.
<Saviq> sergiusens, â
<sergiusens> Saviq: still, this is not the `games` part running, it is from the miral part
<Saviq> sergiusens, even so, that would mean snapcraft's telling cmake the wrong install prefix/chroot/something?
<sergiusens> I see no "Building games" message in those logs
<Saviq> sergiusens, sure, just means the parts' env is leaking between parts?
<sergiusens> Saviq: yes. Maybe. That could be it. This is there since the days of mvo and mterry caring for the code base. But I can check
<Saviq> sergiusens, it reproduces here in cleanbuild on zesty
<sergiusens> Saviq: on and off?
<sergiusens> or always?
<Saviq> sergiusens, I'd say more than 50%
<Pharaoh_Atem> zyga-suse: dnf makecache is equivalent to apt update
<zyga-suse> Pharaoh_Atem: intereting, thanks (I never ran that command myself)
<Pharaoh_Atem> on a normal system, you don't need to
<Pharaoh_Atem> there's a systemd timer that takes care of it for you
<nacc> cjwatson: thanks! yes, my snap built fine overnight, it appears
<zyga-suse> jdstrand: hey, replied to the "using snap-update-ns from snap-confine" thread
<Pharaoh_Atem> zyga-suse: if you need to force a metadata update independent of the actual action, that's how you do it
<Pharaoh_Atem> normally, you only care in the context of a system upgrade, so "--refresh" can be used as an option to force it
<zyga-suse> Pharaoh_Atem: the goal is to accelerate test cycles, if we can not run "dnf update" that's all good
<Pharaoh_Atem> don't you run system upgrades before every test?
<Pharaoh_Atem> for ubuntu
<zyga-suse> Pharaoh_Atem: I worry though that we'll hit stale cache issues sooner or later unless we do base image updates separately like every 12 hours
<zyga-suse> Pharaoh_Atem: we don't
<Pharaoh_Atem> well, if the metadata is expired, dnf will fetch anyway
<Pharaoh_Atem> you don't need makecache normally
<zyga-suse> Pharaoh_Atem: it was way to slow and it'd be better to just have fresh images updated out-of-band
<Pharaoh_Atem> then take it out entirely from suse and fedora spread runs
<Pharaoh_Atem> both of them do metadata refresh and system upgrade
<Pharaoh_Atem> well, zypper requires metadata refresh manually
<zyga-suse> yep
<ahasenack> hi, shouldn't I need root to install a (classic even) snap? http://pastebin.ubuntu.com/25075675/
<zyga-suse> ahasenack: no if you "sudo snap login"ed before
<ahasenack> I see
<ahasenack> nacc: ^
<nacc> ahasenack: thanks
<ahasenack> zyga-suse: the result of that login is what is stored in ~/.snap/auth.json?
<zyga-suse> yes
<mvo> fgimenez: the error is "expected", we could SRU 2.26.9 - then it will go away. maybe thats cleaner
<ahasenack> hm
<ahasenack> thx
<zyga-suse> uh, oh
<zyga-suse> thunderstorm
<fgimenez> mvo: np, thank you, btw all the ongoing dragonboard test executions on testflinger have suddenly stopped with "Timeout while trying to communicate with the server.", i'll try to retrigger them but this is going to make the validation longer, pi2 and pi3 finished successfully
 * zyga-suse shuts the desktop down :/
<zyga-suse> but hey, laptops
<Saviq> sergiusens, alan_g, bug #1703878
<mup> Bug #1703878: Race/environment leak between parts <Snapcraft:New> <https://launchpad.net/bugs/1703878>
<mvo> fgimenez: thanks - strange, any idea what happend there?
<fgimenez> mvo: nope, maybe plars can help
<zyga-suse> do you have a log?
<mvo> fgimenez: all 2.26.9 debs uploaded to -proposed, things should be in sync now test-wise (once they get accepted)
<fgimenez> mvo: great thanks!
<mup> PR snapd#3544 closed: tests: make main/help run on opensuse and fedora again <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3544>
<sergiusens> Saviq: `snapcraft cleanbuild --debug` or `snapcraft --debug cleanbuild`?
<sergiusens> Saviq: http://paste.ubuntu.com/25075840/ (I am fixing it so it works when specified the other way around)
<zyga> cachio, fgimenez: I just found a weird bug where one spread test failed because core had a random refresh
<zyga> are we rescheduling refreshes in the prepare stage?
<zyga> more, I think (not sure if possible) is that it was *snapshotted* this way
<zyga> so each subsequent test fails on the same "core has changes in progress"
<fgimenez> zyga-suse: looks like bad timing, maybe your test was run at the same time the last edge core was published
<fgimenez> in other words, perhaps the new core was made available during the run, we have had this issue before
<plars> fgimenez: I'm out this week, but if it's one of ours, I can tell you that I just got results in email of one of our runs that was successful. If you have a log or something, please send it so I can see what was going on when I get back. Otherwise maybe retry it?
<fgimenez> zyga-suse: last core was available about 2h ago https://travis-ci.org/snapcore/spread-cron/builds/252825721
<fgimenez> plars: thanks! it just printed "Timout while trying to communicate with the server." (sic) during the execution, now i'm not able to retrigger, i get a job id but the polling gets stuck
<fgimenez> plars: i had good executions until ~1:30min ago, i'll sned you the details by mail, thx!
<mup> PR snapd#3498 closed: hooks: support for install and remove hooks <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3498>
<mup> PR snapcraft#1404 opened: cleanbuild: ensure we enter a shell on failures on --debug <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1404>
#snappy 2017-07-13
<liveuser> Hello. Is this the IRC channel for snapcraft?
<liveuser> I want to edit a snap, but it appears to be read-only.
<liveuser> This is my first snap, how do I get around this? I need to edit a bash script included in the snap.
<liveuser> The internet says run it in "Classic" containment
<liveuser> but I have no idea where the snapcraft.yaml is located
<liveuser> Also, what happens to the files when I'm examining the hard drive from a live instance?
<liveuser> I went into my /snap directory, found the program, and the directory is empty
<liveuser> This is a lot of effort just to edit a bash script. :c
<mz_> I have installed snapd, snapcraft.ãThen installed snap package hello-word.But when run "hello-world.env",output "command not find",why?
<mwhudson> mz_: you might need to log out and in again to get /snap/bin on $PATH?
<zyga> good morning
 * zyga slowly tunes into Polish weather and timezone
<mup> PR snapd#3578 closed: store: talk to api.snapcraft.io for purchases <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3578>
<davidcalle> elopio: for you to have a look https://github.com/canonical-websites/tutorials.ubuntu.com/pull/283
 * zyga -> breakfast
 * Chipaca needs more coffee today
<mvo> pstolowski: hey, we do generate the snapctl cookies on startup now in master, right? I was doing the following: "snap run --shell hello && snapctl get foo" but I get an "invalid snap cookie requested" error. is this expected?
<pstolowski> mvo, hey, yes, this change landed in master. snapd generates them if missing. so no, that's not expected
<mvo> pstolowski: ok, I dig a bit to see what is going on
<pstolowski> mvo, i'm looking at this too, may have a few questions in a sec
<mvo> pstolowski: but the usage above should work, right? i.e. if I run inside the snap environment I should be able to use snapctl get?
<mvo> pstolowski: fwiw, I see snap-cookies in the state
<mvo> pstolowski: including one for "hello"
<mvo> pstolowski: meh, it maybe that I have not everything updated to master, looks my snap-confine is too old
<pstolowski> mvo, hmm wait, the snapctl.. part is not run the context of the hello snap, is it?
<mvo> pstolowski: it should be, snap run --shell hello should give me the exact environment that "hello" would run in. but like I said, I tink my snap-confine is out-of-date
<pstolowski> mvo, one other thing to check is if /var/lib/snapd/cookie/ has a cookie file for hello snap (both snap-cookies and /var/lib/snapd/cookie should be in sync)
<mup> PR snapd#3549 closed: many: expose services commands for snap services <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3549>
<mup> PR snapd#3552 closed: daemon: implement service commands <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3552>
<mup> PR snapd#3554 closed: client: wrap services calls <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3554>
<mvo> pstolowski: yep, sorry for the noise, all is fine, I my system was not using master for everything
<pstolowski> mvo, np, good to hear it's fine, thanks
<davidcalle> Saviq: for you https://github.com/canonical-websites/developer.ubuntu.com/pull/305
<pstolowski> davidcalle, hi David!
<davidcalle> pstolowski: hey o/
<davidcalle> (on my way to lunch, but I'm around)
<pstolowski> davidcalle, fyi, we have just landed support for install & remove hooks in snapd master. and some more hooks are in the pipeline and will probably land in next few weeks
<pstolowski> davidcalle, so we may need to update the docs
<davidcalle> brilliant!
<Saviq> davidcalle, ack!
<mup> PR snapd#3586 opened: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3586>
 * zyga -> break
<Son_Goku> what wait
<Son_Goku> niemeyer: what is snapd#3586?
<mup> PR snapd#3586: client, daemon: rest api to reconfigure snapd with a custom store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3586>
<Son_Goku> dare I hope that this means arbitrary stores could be configured without patching and recompiling snapd?
<niemeyer> Son_Goku: This is about hosting of local stores in environments that can't talk to the open net
<niemeyer> It's a sort of proxy pretty much, and changes the system altogether, so won't be very good at handling what you describe.. at least not yet
<Son_Goku> niemeyer: I see
<davidcalle> pstolowski: what are the other hooks?
<zyga> re
<davidcalle> (in the pipeline, I mean)
<pstolowski> davidcalle, in the pipeline: refresh hook and interface hooks (executed when you 'snap connect ..' 2 snaps)
<davidcalle> ty
<davidcalle> pstolowski: I'll send you a PR to look over the doc update (probably not before tuesday, though)
<pstolowski> davidcalle, sure. keep in mind this stuff just started landing and it will become available in next release(s)
<davidcalle> pstolowski: +1
<pstolowski> davidcalle, so a few weeks away i suppose. nb, i'll be off for next 2 weeks
<davidcalle> pstolowski: I'll be off for three weeks in 10 days, but we'll manage something ;)
<ogra_> three weeks!
<ogra_> vive la france ? :)
<davidcalle> Ahaha
<Chipaca> ogra_: we get twenty something days too (but the custom here is to not take them all together)
<ogra_> yeah
 * davidcalle raises his 2y and 3y old kids card
<zyga> 2017-07-13T14:46:32+02:00 ERROR cannot create alias symlink: symlink etcd.etcdctl /snap/bin/etcdctl: file exists
<zyga> hmmm
 * zyga happily switches to the interfaces branch
<zyga> at least something I can bash and smash _and_ see a result
<cachio> mvo, some change introducing in 2.26 is making tests fail when we do "systemctl stop snapd.service snapd.socket"
<cachio> mvo, I'll research it
<zyga> mvo, niemeyer: question about the idea to use and release "RC"s rather than releases, what will the core snap version look like then?
<ogra_> same as the final one, no ?
<ogra_> after all the version doesnt get modified when core migrates from beta->candidate->stable
<mvo> cachio: thank you - where do you see that?
<niemeyer> I don't have a strong opinion.. if we intend to release the same build assuming the candidate "tastes good" we'll need to preserve the final version on it though
<niemeyer> What ogra_ said, basically
<cachio> mvo, two builds failed on master
<ogra_> i guess it would simply just be ahead one version bump
<zyga> yes
<zyga> though that looks "less nice"
<cachio> mvo, this is the last one https://travis-ci.org/snapcore/snapd/builds/253090762#L3796
<ogra_> while edge is jumping between git and release versions as needed
<zyga> maybe we could alter the version in a snap revision assertion?
<zyga> (purely presentation-wise)
<ogra_> do you really think people look at it that much that it is worth it ?
<mvo> cachio: hm, "Job for snaps.service canceled" is a bit dry as an error message :/
<zyga> ogra_: not on core
<zyga> ogra_: but maybe, not sure
<ogra_> i'd say also not on classic ... except when they run snap --version to copy/paste that into bugs :)
<cachio> mvo, yes, it started yesterday and it happened on different tests
<cachio> mvo, trying to reproduce it now
 * zyga tried to write "spans" and kept typing "snaps"
<Chipaca> zyga: snaps span pan-sass pans
<ogra_> schnaps !
<Chipaca> ogra_: a bit early for me
<ogra_> but helps to get things back in order ;)
<ogra_> (or totally out of order ... a matter of volumes ... )
<Pharaoh_Atem> so... snapd-glib 1.15 for fedora, thanks to robert-ancell:
<Pharaoh_Atem> * F24: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5d326072db
<Pharaoh_Atem> * F25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f3da5ab6fc
<Pharaoh_Atem> * F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-8ba37dcc1c
 * zyga dinner
<mvo> fwiw, I branched 2.27 now and will update the forum topic
<mvo> if anyone absolutely needs something in 2.27 shout!
<Pharaoh_Atem> mvo: do we have an upstream changelog for 2.27 yet?
<Pharaoh_Atem> I figured I'd experiment with shipping an upstream-ish changelog entry in the package changelog
<mvo> Pharaoh_Atem: I will write a short (highlights) changelog into the forum soon, the auto-generated one is part of debian/changelog, I will push the branch in a little bit
<Pharaoh_Atem> mvo: I was wondering if maybe we should also push a variant of that into the fedora spec
<mvo> its based on current master, so the new install/remove hooks are part of it (thanks to pstolowski)
<mvo> Pharaoh_Atem: sure, I can do that, its mostly automatic, I will need to look at how changelogs work in spec files :)
<Pharaoh_Atem> they're pretty simple :)
<Pharaoh_Atem> I'm guessing though that you probably don't have rpmdevtools on your computer, right?
<Pharaoh_Atem> https://build.opensuse.org/package/show/home:Pharaoh_Atem:debrpm/rpmdevtools :)
<mvo> Pharaoh_Atem: apt list rpmdevtools gives me an empty list
<mvo> Pharaoh_Atem: how does http://paste.ubuntu.com/25082523/ look?
<mvo> Pharaoh_Atem: hm, not good at all I suppose, missing the date and revision, right?
<mvo> eh version
<Pharaoh_Atem> yeah
<Pharaoh_Atem> you're missing the header
<Pharaoh_Atem> note the entry below yours
<mvo> Pharaoh_Atem: yeah
<Pharaoh_Atem> you can also indent multiple levels
<Pharaoh_Atem> changelogs are mostly freeform
<mvo> Pharaoh_Atem: how do you guys represent "rc" versions. 2.27~rc1 ?
<Pharaoh_Atem> officially, Fedora uses 0.rc1.1 in the Release field
<Pharaoh_Atem> but you can use ~rc1
<Pharaoh_Atem> that's totally acceptable
<Pharaoh_Atem> and in fact, I'm okay with that
<Pharaoh_Atem> so just use 2.27~rc1 and leave the Release value at 0%{?dist}
<mvo> Pharaoh_Atem: so http://paste.ubuntu.com/25082538/ ?
<Pharaoh_Atem> so the changelog entry version would be 2.27~rc1-0
<Pharaoh_Atem> looks good
<Pharaoh_Atem> though I think you're the author :)
<mvo> Pharaoh_Atem: aha, so this is the author, not the uploader? sure, I can fix the field
<Pharaoh_Atem> it can be either
<Pharaoh_Atem> but I prefer author of change :)
<Pharaoh_Atem> besides, I'll just have a 2.27-1 entry when I release into Fedora :)
<mvo> Pharaoh_Atem: sounds good
<zyga> re
<mvo> Pharaoh_Atem: thanks for your help! I
<Pharaoh_Atem> np
<Pharaoh_Atem> this is my particular experiment with having upstream changelogs along with maintainer ones
 * zyga hugs both Pharaoh_Atem and mvo 
<Pharaoh_Atem> historically speaking, I've never been a fan of them, but enough people ask for them now that I'll see how it plays out
<mvo> Pharaoh_Atem: sure, I will keep this in mind (or try) - just let me know if the experiment does not pan out
<mvo> (and you want the short maintainer ones back)
<Pharaoh_Atem> mvo: My preference would be that you'd do the following structure for the entry
<Pharaoh_Atem> * @DATE@ @AUTHOR@ - @VERSION@
<Pharaoh_Atem> - New release
<Pharaoh_Atem>   - Entry details
<Pharaoh_Atem> you can indent freeform just like you do with debian changelogs
<Pharaoh_Atem> the idea is to just make it clear
<Pharaoh_Atem> and adjust the Version: tag to be the same as @VERSION@ :)
<Pharaoh_Atem> I still plan on using the highlights for the updateinfo data used for bodhi updates
<mup> PR snapd#3587 opened: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3587>
<Pharaoh_Atem> mvo: is that alright with you?
<mvo> Pharaoh_Atem: sure!
<Pharaoh_Atem> we can tweak as needed going forward
<Pharaoh_Atem> I think that as long as the entries are prepared alongside, it'll go pretty well
<zyga> wa
<zyga> :w
<mvo> Pharaoh_Atem: https://github.com/snapcore/snapd/blob/release/2.27/packaging/fedora/snapd.spec#L638 I pressume?
<mvo> zyga: :!
<Pharaoh_Atem> :)
<Pharaoh_Atem> perfect
<Pharaoh_Atem> mvo: you can also adjust the version field: https://github.com/snapcore/snapd/blob/release/2.27/packaging/fedora/snapd.spec#L51
<Pharaoh_Atem> unless you don't plan on tagging 2.27~rc3
<Pharaoh_Atem> mvo: could you also adjust the Version field?
<Pharaoh_Atem> something I'm thinking of trying is having COPR track branches to offer pre-release builds from Git directly
<Pharaoh_Atem> no biggie if you don't want to, though
<Pharaoh_Atem> I'm can just track myself
<mvo> Pharaoh_Atem: aha, the version is not taken automatically from the changelog?
<Pharaoh_Atem> mvo: nope
<Pharaoh_Atem> in fact, you can leave the version off entirely and put it in the changelog text
<mvo> Pharaoh_Atem: ok, updating this
<Pharaoh_Atem> some people prefer that
<Pharaoh_Atem> again, I debate about it myself
<Pharaoh_Atem> technically, RPM is actually only aware of @DATE@ @AUTHOR
<Pharaoh_Atem> err @AUTHOR@
<mvo> Pharaoh_Atem: hm, ok. no idea :) if I can leave it off, thats nice because it means less things to remember
<Pharaoh_Atem> mvo: if you do that, please put it in the changelog text :)
<Pharaoh_Atem> it helps so people know what it's associated with
<Pharaoh_Atem> so you can do "New upstream release 2.27~rc3"
<Pharaoh_Atem> which is probably okay for both Debian and Fedora changelogs
<mvo> Pharaoh_Atem: sounds good. updated. I think its ok to now upload this just yet to fedora I hope we have a real 2.27 early next week
<Pharaoh_Atem> awesome
<Pharaoh_Atem> mvo: sorry if I seem like I'm being picky, but I'm excited that with Fedora actually plugged into the CI (admittedly not doing a lot), it'd be nice if it was also bumped in a similar manner for releases
<Pharaoh_Atem> mvo: hold on
<Pharaoh_Atem> this is wrong
<Pharaoh_Atem> https://github.com/snapcore/snapd/commit/9610a9260e80cd059394d9ef5c729f5698064ef1
<Pharaoh_Atem> the Version: does need to be filled in
<Pharaoh_Atem> I meant that
<Pharaoh_Atem> * Thu Jul 13 2017 Michael Vogt <mvo@ubuntu.com> [ - 2.27~rc3 ]<= not mandatory
<Pharaoh_Atem> I misunderstood you
<Pharaoh_Atem> Version: is mandatory
<Pharaoh_Atem> the version in the changelog entry header is not
<mvo> Pharaoh_Atem: aha, ok
<Pharaoh_Atem> rpm doesn't use that at all for anything
<mvo> Pharaoh_Atem: let me fix that
<Pharaoh_Atem> mvo: sorry for that :)
 * Pharaoh_Atem sighs in relief
<Pharaoh_Atem> mvo: awesome, now it's right
<mup> PR snapcraft#1404 closed: cleanbuild: ensure we enter a shell on failures on --debug <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1404>
<mup> PR snapd#3588 opened: tests: fix how package lists are updated for opensuse and fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3588>
<zyga> Pharaoh_Atem: can you have a look at ^
<zyga> Pharaoh_Atem: it smells like that metadata-update you mentioned
<mup> PR snapcraft#1357 closed: tests: do not break a systems `bzr whoami` <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1357>
<noise][> FYI, we are having an issue with snap downloads, investigating
<pstolowski> niemeyer, wrt #3569 when writing the tests I found out that some of the unmarshall -> decoder+usenumber change were not actually needed, so I reverted them. moreover, I found that the changes to state.go are most likely not needed either - the end-to-end spread test execute without state.go changes proves that, however one unit test disagrees and I need to understand why, but probably it's a problem with how this unit test is implemented
<pstolowski> niemeyer, long story short.. the change may become 2x shorter and a single problematic unit test led me to some dead ends
<niemeyer> pstolowski: Nice, that's good news I guess
<niemeyer> pstolowski: Why are those cases not needed?
<niemeyer> pstolowski: Without digging in much, it felt like a good thing that we were preserving the numbers as originally fed
<pstolowski> niemeyer, they apparently don't affect the data format (thanks to json.RawMessage I guess?). the critical part is snap-get/snapctl-get and config/transaction
<pstolowski> it's getting late here.. ttyt o/
<Pharaoh_Atem> mvo: what's this "profilese" you speak of? :P https://github.com/snapcore/snapd/commit/7cb1b27c546bce219114010fe9c8f4d0e6a48071
<davidcalle> elopio: https://tutorials.ubuntu.com/tutorial/continuous-snap-delivery-from-travis-ci
<mwhudson> is chipaca on leave currently?
#snappy 2017-07-14
<mup> PR snapcraft#1405 opened: pluginhandler: check for collisions only in existing files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1405>
<mup> PR snapcraft#1406 opened: manifest: rename the file to manifest.yaml <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1406>
<mup> PR snapcraft#1394 closed: tests: document the test suites in the snapcraft repo <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1394>
<qu1nn_1> ultra newb to snappy packages.  using debian stretch. installed snapd package via "sudo apt install snapd" this appears to have taken.  Went to install nextcould via "sudo snap install nextcloud" and the terminal window states "error: cannot install "nextcloud": snap "nextcloud" has changes in progress"  what does that mean?
<mup> PR snapd#3588 closed: tests: fix how package lists are updated for opensuse and fedora <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3588>
<mup> PR snapd#3580 closed: store: configurable base api <Created by atomatt> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3580>
<mup> PR snapcraft#1407 opened:  recording: record the original snapcraft.yaml <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1407>
 * zyga ran away from home, won't be back today
 * zyga updates interfaces API to new agreements
<Chipaca> my ISP is not happy today :-(
<zyga> Chipaca: what's the problem?
<Chipaca> zyga: https://aastatus.net/
<zyga> shellcheck is really really smart
<zyga> In packaging/fedora/snap-mgmt.sh line 69:
<zyga>             rm -rf "${SNAP_MOUNT_DIR}/$snap/$rev"
<zyga>                    ^-- SC2115: Use "${var:?}" to ensure this never expands to / .
<zyga> Chipaca: mind the outage
<zyga> Chipaca: on the upside, I can tell you how to do multi-homing
<zyga> Chipaca: on the downside, I don't know if I do it correctly, my experience was so-so when I enabled load-balancing
<Chipaca> zyga: son can my isp (but it's more expensive)
<Chipaca> so can*
<zyga> Chipaca: multi-home with a usb modem
<Chipaca> if this happened more frequently i might consider it
<zyga> Chipaca: but I already had those from last year when I was working in the woods
<Chipaca> as it is i can tolerate having to switch manually (and losing access to my music player!)
<zyga> Chipaca: the horror!
<Chipaca> zyga: the router these guys give you can take a usb modem and switch, i think (or maybe it's the more expensive router), but they can also connect you up to multiple circuits properly
<zyga> Chipaca: ah that's pretty nice
<Chipaca> in any case, probably not worth it
<zyga> Chipaca: I did it manually on ubuntu
<Chipaca> because when you fix a SPOF by doubling stuff, your failure rate goes up
<zyga> Chipaca: but I also wanted to set up squid and a few other things to make my no-broadband network manageable
<Chipaca> zyga: is wwwoffle still a thing?
<Chipaca> i remember using that a lot
<zyga> Chipaca: wwwoffle? I never heard about it
<zyga> Chipaca: I'm using squid, bind, dhcpd and systemd-networkd
<Chipaca> zyga: wwwoffle is no longer in the (ubuntu) archive, but polipo claims to be similar
<zyga> (though I need to see if it can do what I need, I may have to switch to something more manual as it doesn't let me configure routing the way I need)
<Chipaca> zyga: https://www.gedanken.org.uk/software/wwwoffle/
<Chipaca> basically a agressive squid that if offline just serves up stale content no probs
<zyga> ah, interesting
<zyga> yeah, I wanted to script my installation a little to probe the network and switch to offline mode if both links are down
<zyga> well, maybe one day
<Chipaca> zyga: https://control.aa.net.uk/blip.cgi/ <- not a happy puppy
<zyga> what is that?
<zyga> that's not the store monitoring thing
<Chipaca> zyga: logins and logouts at my isp
<zyga>  - failed signature verification: openpgp: invalid signature: hash tag doesn't match
<Chipaca> lots of 'em means things are broken
<zyga> have you seen an error message like this before?
<zyga> (this is me running snapd from the tree)
<Chipaca> zyga: no but don't tell Son_Goku or he'll start ranting about gpg again
<Son_Goku> moo
<zyga> hey Son_Goku how are you doing?
<zyga> it finally stopped raining here
<zyga> (fingers crossed)
<zyga> so I'm in good (relatively) mood
<Chipaca> Son_Goku: :-)
<Son_Goku> my mouth tastes like cotton
<Son_Goku> I just woke up
<zyga> hangover?
<zyga> did you like the Å¼ubrÃ³wka shot?
<zyga> (please please please like it)
<ogra_> ppisati, any idea about the oops in https://forum.snapcraft.io/t/wifi-and-bluetooth-on-snappy-ubuntu-on-a-dragonboard/1297 ?
<ogra_> (i have the feeling i have seen it before but cant remember the context)
 * zyga relocates, brb
<ppisati> ogra_: uhm, not really
<zyga> fd
<zyga> re
<zyga> mvo: should we be worried?
<zyga> 2017/07/14 12:20:28.730790 snapmgr.go:418: Cannot prepare auto-refresh change: cannot add some assertions to the system database:
<zyga>  - failed signature verification: openpgp: invalid signature: hash tag doesn't match
<zyga> is that a side effect or running locally
<zyga> (go build and just run)
<zyga> or do we have a gpg issue at hand
<Son_Goku> zyga: no, never
<zyga> Son_Goku: you didn't like it? aww :-(
<zyga> Son_Goku: maybe next time I can bring you something nicer
<Son_Goku> ... with food to go with it
<zyga> Son_Goku: ah
<zyga> :D
<zyga> Son_Goku: herring with cream and vodka (though not Å¼ubrÃ³wka anymore, doesn't fit)
<zyga> Son_Goku: very traditional Polish quisine
<Son_Goku> herring? as the fish?
<zyga> yes
<Son_Goku> I hate fish :D
<zyga> you know this sentence can be understood in two opposite ways? ;-)
<zyga> Son_Goku: I hate fish thus I will kill each one and possibly eat it
<zyga> Son_Goku: I hate fish thus I would rather not eat any
<Son_Goku> the latter
<zyga> Son_Goku: seriously you didn't try this, it's a very unique taste
<zyga> Son_Goku: along with onions and cream
<Son_Goku> we'll see then
<mvo> zyga: I have not seen this one yet :/
<zyga> https://www.google.es/search?q=%C5%9Bled%C5%BA+ze+%C5%9Bmietan%C4%85&client=ubuntu&hs=gNL&channel=fs&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiNqeCdzIjVAhXCExoKHZ65BuEQ_AUICigB&biw=1280&bih=653 :D (sorry for google.es searching for polish food)
<zyga> mvo: neither did I
<zyga> mvo: it comes out of snapd periodically while I'm wokring today
<mvo> zyga: I do see a debian-unstable-64 test failrue in master, but when I run the test myself
<zyga> actually both do:
<zyga> 2017/07/14 12:37:23.557705 snapmgr.go:418: Cannot prepare auto-refresh change: cannot add some assertions to the system database:
<zyga>  - failed signature verification: openpgp: invalid signature: hash tag doesn't match
<zyga> 2017/07/14 12:37:23.557770 stateengine.go:98: state ensure error: cannot add some assertions to the system database:
<zyga>  - failed signature verification: openpgp: invalid signature: hash tag doesn't match
<zyga> note that this is not a failure, it's just a message out of the blue
<zyga> though I suspect it'd fail a refresh test
<zyga> Son_Goku: I even found a wikipedia article about it https://en.wikipedia.org/wiki/Dressed_herring
<Son_Goku> the Slav is strong in that one
<zyga> indeed
<zyga> maybe we could do a winter sprint in poland somewhere, it would surely show up
<fgimenez> hi mvo, i got this error during 2.27~rc3 validation http://paste.ubuntu.com/25088294/, so far in amd64 and i386 (not yet executed in the rest of archs), the session is open in case you want to take a look
<zyga> fgimenez: looks like activation didn't trigger?
<zyga> mvo: could this be caused by the same thing we found at the sprint, where master was out of date wrt packaging and it did the wrong thing via reexec
<Son_Goku> zyga: uh, no
<Son_Goku> winter sucks
<zyga> Son_Goku: not when you have Åledzik and wÃ³dka or reason to go outside into the snow
<zyga> Son_Goku: seriously though I think you are right,
<mvo> fgimenez: yeah, if you could /msg me how to login, that would be nice
<mvo> fgimenez: I suspect its something silly
<zyga> Son_Goku: do you have strong winters back home?
<Son_Goku> yes
<Son_Goku> not this year, but the years before, we did
<mvo> zyga: could be, but 2.27 should be close to master still
<Son_Goku> blizzard after blizzard
<zyga> Son_Goku: and you don't like winter?
<Son_Goku> I love it when it's relatively calm
<zyga> Son_Goku: I really really dream about one sprint location
<zyga> Iceland
<Son_Goku> Iceland is green...
<zyga> just because it's such a outwordly location
<zyga> and so barren
<zyga> I'd like to see it
<Son_Goku> greenland is the barren place
<zyga> get us a cabin in the middle of 100km patch with no other peoplpe
<zyga> iceland is also barren in the sense that few people live there
<zyga> and it's rather large
<zyga> I doubt greenland has sprint sustaining conditions
<zyga> apart from BUILD THE DAM IGLOO THE BEAR IS COMING!!!!
<Son_Goku> haha
<zyga> aka team building and bonding exercise
<zyga> (PM dressed up as bear)
<Son_Goku> oh dear
<Son_Goku> the PM would die first
<zyga> see
<zyga> PM woud have to kill and eat the inside of the bear first
<zyga> the running caracas shouting "rrrrrreeeeleease"!
 * zyga gets back to yaml
<zyga> Chipaca: do you know any simple command line yaml thing
<zyga> that I could pipe yamlto
<zyga> and it'd shout "that's not yaml dummy, ask Chipaca how it's made"
<fgimenez> mvo: sure 1sec
<zyga> Chipaca: and while we're talking, is there an implict assumption that our CLI commands speak in text that magically is parsable as valid yaml?
<zyga> Chipaca: or can we be free-form
<zyga> aha
<mup> PR snapd#3589 opened: tests: remove unneeded check for re-exec in InternalToolPath() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3589>
<zyga> re Chipaca
<zyga> 13:01 < zyga> Chipaca: do you know any simple command line yaml thing
<zyga> 13:01 < zyga> that I could pipe yamlto
<zyga> 13:02 < zyga> and it'd shout "that's not yaml dummy, ask Chipaca how it's made"
<zyga> 13:02 < zyga> Chipaca: and while we're talking, is there an implict assumption that our CLI commands speak in text that magically is parsable as valid yaml?
<zyga> 13:02 < zyga> Chipaca: or can we be free-form
<Chipaca> zyga: yq?
<Chipaca> zyga: tbh i've been using yaml-online-parser.appspot.com for that, because i'm lazy, but yq exists
<zyga> is that a command name?
<zyga> ah
<Chipaca> like jq but for yaml, yes, it exists
<zyga> mmm, are you on 16.04?
<Chipaca> not particularly good when i tried it
<Chipaca> i am
<Chipaca> zyga: i'd say snap instlal yq, but it's not mature enough imho
<Chipaca> zyga: so virtualenv + pip install
<zyga> Chipaca: ah
<Chipaca> hm
<Chipaca> https://pypi.python.org/pypi/yq
<zyga> Chipaca: how do you feel about output like this? http://pastebin.ubuntu.com/25088397/
<Chipaca> maybe i got it from a duff github thing, because that's at 2.20
<Chipaca> 2.20 doesn't sound immature
<zyga> Chipaca: observe how output differs depending on label/attrs being there and visible
<zyga> (I added a label and implicit attribute to network interface so that it would show)
<Chipaca> zyga: why's the label like a slightly more verbose summary
<Chipaca> anyway, it seems alright to me
<Chipaca> now i'm going to go for a run
<zyga> Chipaca: label is per instance
<Chipaca> i expect my network to continue frobbling in my absence
<zyga> Chipaca: the actual text there is fake
<zyga> Chipaca: summary is per interface class
<Chipaca> zyga: a'ight, even better then
<zyga> Chipaca: I'm trying to come up with something in response to https://github.com/snapcore/snapd/pull/3399#discussion_r121195898
<mup> PR snapd#3399: many: add the interface command <Decaying> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3399>
<Chipaca> zyga: as i say, it seems alright to me at a glance
<zyga> great!
<zyga> I think it's fine
<zyga> it's not API-fine because the output may be a list of strings
<zyga> or a list of objects
<zyga> but that's fine
<zyga> people that do dynamic languages love that anyway
<zyga> ;-)
<zyga> I wanted to retain the abiity to show details
 * zyga needs to run and pay for parking 
 * zyga fed the parking meter 
<morphis> zyga: ping
<zyga> yes
<zyga> mvo, Chipaca: can you pastebin (private) the details of this snapd install oops please Jul 12 22:04:59 test-container /usr/lib/snapd/snapd[24472]: handlers.go:204: Reported install problem for "core" as 255c06b6-674e-11e7-8c10-fa163e54c21f OOPSID
<zyga> morphis: what's up?
<morphis> zyga: just checking if you or I should update the opensuse snapd package for the latest 2.26 release
<zyga> morphis: I wanted to update to 2.27 as it gets released (mvo said monday)
<morphis> zyga: release to stable on monday?
<zyga> morphis: I think so
<morphis> ok
<zyga> morphis: sync packaging to master, update and release
<morphis> makes sense
<morphis> zyga: ok, then I leave that up to you
<morphis> give me a ping when you need another test on the PR
<zyga> morphis: okay, I'll try to sync the package and fix tests over weekend, hoping that we can smoothly press the button first thing next week
<morphis> sounds good
<morphis> zyga: you're in Warsaw next week?
<zyga> morphis: I'm in Warsaw right now :)
<zyga> morphis: as for the sprint, I won't be there for the week
<morphis> zyga: ah, great!
<zyga> (maybe I'll lurk for food ;-)
<morphis> hehe
<zyga> mvo has the tough job next week
<zyga> I'll be there to hug him and offer refreshments
<mup> PR snapcraft#1408 opened: Set XDG_CACHE_HOME in persistent LXD container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1408>
<Son_Goku> zyga, what's going on with mvo next week?
<morphis> Son_Goku: sprinting :-)
<zyga> Son_Goku: sprinting in Warsaw
<zyga> Son_Goku: on a business sprint, little coding, lots of tables and stuf
<Son_Goku> ah, so mvo will be able to twiddle his thumbs a bit :P
<niemeyer> Hello all!
<Son_Goku> niemeyer: morning!
<Son_Goku> mvo: did you see the typo of the word "profiles" in the changelog
<mvo> Son_Goku: I have not, I will check and fix
<Son_Goku> mvo: you should see my message to you yesterday about "profilese" :)
<Son_Goku> (as Pharaoh_Atem )
<zyga> niemeyer: hello
<mvo> Son_Goku: uh, sounds like irc ate it
<zyga> niemeyer: offtopic, remember when I asked all those questions about the interface API
<niemeyer> zyga: Yeah
<zyga> niemeyer: I really must have been tired then, it's all perfectly logical on fresh read
<niemeyer> zyga: (what's the topic, btw? :P)
<zyga> niemeyer: not sure how I can come across so different now
<zyga> niemeyer: PR 3399
<zyga> niemeyer: anyway, all good, will be done soon
<niemeyer> zyga: Hah, yeah.. I thought it'd make more sense after sleeping on it :D
<niemeyer> zyga: Thanks!
<zyga> niemeyer: and now some more ontopic things: https://forum.snapcraft.io/t/cannot-refresh-cannot-add-assertions-failed-signature-verification-while-hacking-on-master/1324
<zyga> niemeyer: never saw this, didn't dive into it yet but I wanted to keep this on the radar given the immenent release
<niemeyer> zyga: The agreements around the apps API shouldn't change this much, I think
<Son_Goku> [Thursday, July 13, 2017] [3:11:33 PM EDT] <Pharaoh_Atem>       mvo: what's this "profilese" you speak of? :P https://github.com/snapcore/snapd/commit/7cb1b27c546bce219114010fe9c8f4d0e6a48071
<niemeyer> zyga: The most interesting outcome of that conversation is that we'll now have an endpoint that talks about APIs in general
<niemeyer> Erm
<niemeyer> "apps in general"
<mvo> Son_Goku: woah, that is a typo so big you can drive a car through
<Son_Goku> :D
<zyga> niemeyer: are you referring to the the discussion between you and Chipaca about the services and how apps are represented there?
<niemeyer> zyga: Yeah, the one you asked about yesterday
<zyga> niemeyer: ah, right
<Chipaca> snappers, my internets are very very flaky today (isp's cisco hw is having a bad bgp day), so assume anything you say to me on irc wasn't heard unless directly answered
<zyga> niemeyer: thanks for confirming that
<zyga> Chipaca: I will make you feel at ease by acking the statement
<zyga> at least now we know
<Chipaca> zyga: ta :-)
<zyga> Son_Goku: profilese is profiles in snapese languagese
<Son_Goku> haha
<Chipaca> zyga: I'd tell you a tcp joke, but I'd never know if you got it
<zyga> "for uniformitese our changeloges will now be written in snappese"
<zyga> Chipaca: hehe
<zyga> Chipaca: wasn't that an UDP joke?
<Chipaca> zyga: but you might not get it in order
<Chipaca> zyga: I'd tell you an UDP joke
<zyga> boy someone is in good mood today :)
<zyga> boy someone is in good mood today :) [dup]
<zyga> boy someone is in good mood today :) [dup]
<Chipaca> TCP is the one that can have the bizantine generals problem (whereas udp lets the app deal with that)
<Chipaca> my isp is having such a bad day its twitter notifications are getting rate-limited
<Son_Goku> zyga: here we go: https://copr.fedorainfracloud.org/coprs/ngompa/snapd-prerel-fedora/build/579417/
<Son_Goku> zyga: incidentally, COPR supports webhooks, so every commit or every tag could lead to a build in COPR
<Son_Goku> zyga: if we had a Snappy SIG in Fedora, we could have an official group on copr for these things :)
<zyga> very nice, thank you!
<Chipaca> something something Launch all 'SIG'!
<zyga> `Instructions not filled in by author. Author knows what to do. Everybody else should avoid this repo. `
<zyga> Son_Goku: is there a flatpak SIG in place already?
<Son_Goku> zyga: there is not, because the Workstation guys are driving that directly
<zyga> Son_Goku: I'm following the ongoing thread that opposes the "graphical apps as flatpacks" change
<Chipaca> niemeyer: wrt linode etc etc, have you seen the price on alibaba instances?
<zyga> I see
<zyga> alibaba is a cloud now?
<Son_Goku> there is a Modularity SIG
<Son_Goku> err, workgroup (WG)
<Chipaca> https://www.alibabacloud.com/product/ecs?spm=a3c0i.7911826.709257.dproducta1.289572c4oGWOX6#EcsInsTableTrans_linux_SG
<Son_Goku> zyga: https://fedoraproject.org/wiki/Modularity_Working_Group
<zyga> Chipaca: all the VMs are backed up by china, for free ;-)
<Son_Goku> zyga: a Snappy Fedora would most likely involve working with the modularity guys
<zyga> I agree
<zyga> niemeyer: "SSD Cloud Server from $30 USD per instance
<zyga> for a whole year, with 1TB free data transfer!"
<zyga> that's nice~
<Chipaca> zyga: they do indeed have a cn availability zone -- and apparently have simplified some of the cn paperwork for you to have a cn pop
<Chipaca> but i'm assuming that's not interesting for us on the snapd side (whether it's interesting for noise][ & co is a different point)
<zyga> meh
<zyga> This promotion is limited to 3 orders per user, with 1 instance per order. Each user can purchase up to 3 instances.
<zyga> not so nice
<Son_Goku> zyga: wut
<Son_Goku> snapd is broken for i386?
<Chipaca> wut?
<Chipaca> certainly shouldn't be :-)
<zyga> Son_Goku: how?
<Son_Goku> zyga: https://copr.fedorainfracloud.org/coprs/ngompa/snapd-prerel-fedora/build/579417/
<Son_Goku> the build just failed for all 32-bit x86 targets
<zyga> mvo's fav
<zyga> # github.com/snapcore/snapd/cmd/snap-seccomp
<zyga> In file included from /usr/include/xfs/xqm.h:21:0,
<zyga>                  from src/github.com/snapcore/snapd/cmd/snap-seccomp/main.go:49:
<zyga> /usr/include/xfs/xfs.h:53:12: error: size of array 'xfs_assert_largefile' is too large
<zyga>  extern int xfs_assert_largefile[sizeof(off_t)-8];
<zyga> feels like missing -D_LARGE_FILE_SUPPORT=1 or similar
<Chipaca> uhh
<zyga> whatever that macro was
<zyga> but my 0.99PLN goes there
<Chipaca> -D_WTF_BBQ
<Son_Goku> zyga: and this is why we do this :)
<zyga> Son_Goku: yep
<zyga> Son_Goku: thank you!
<zyga> speaking of which
<zyga> I need to setup for the call
<mvo> Son_Goku: uh, thank you
<Son_Goku> mvo: for what?
 * zyga preeemptively hugs mvo who will now setup fedora 25 i386 system to see which build flag is missing
<mvo> Son_Goku: for the build log!
<Son_Goku> haha
<Son_Goku> mvo: no problem :)
<Son_Goku> you can also use the generated src.rpm to actually rebuild locally :D
<mup> PR snapcraft#1406 closed: recording: rename the file to manifest.yaml <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1406>
<zyga_> ogra_: can we please merge https://github.com/snapcore/core-build/pull/14
<mup> PR core-build#14: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <https://github.com/snapcore/core-build/pull/14>
<zyga_> ogra_: I'd rather have *some* test support than none
<zyga_> and we can iterate on it ad nauseam once it is in
<zyga_> it's just python :)
<ogra_> zyga_, do they work ?
<zyga_> ogra_: of course!
<zyga_> ogra_: travis runs them
<zyga_> ogra_: feel free to try to write a few
<ogra_> i thought there were still open issues ...
<zyga_> nope
<zyga_> it's all good
<ogra_> well, no objections to merging it then
<zyga_> woot :)
<zyga_> I only updated it once after I got new mypy to make the whole python code statically tpyed
<zyga_> typed*
<zyga_> (mypy is a blessing)
<zyga_> my code could be better but it it's not critical
<zyga_> I will return to it when the load is smaller, to write more tests
<zyga_> ideally people doing android bootloader support could now tests their code
<zyga_> ogra_: merged now
 * zyga_ -> walk & break towards the bus stop
<mup> PR core-build#14 closed: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/14>
<Chipaca> EHLO
<zyga_> hey Chipaca-SMTP
<zyga_> Chipaca: is SMTP a honorific suffix used on IRC by geeks who read the wikipedia article?
<Chipaca> did i miss anything fun?
<Chipaca> zyga_: if it is, it's somewhere under "-bo"
<zyga_> Chipaca: :D
<zyga_> nah, I'm turning gray, can't be -bo
<zyga_> unless it recycles when one becomes senile
 * zyga_ starts walking, ttyl
<Chipaca> zyga_: or you experience time backwards
<mup> PR snapcraft#1405 closed: pluginhandler: check for collisions only in existing files <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1405>
<cachio> mvo, are you working on the linode:debian-unstable-64:tests/upgrade/basic ?
<mup> PR snapcraft#1409 opened: snap: remove completer entry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1409>
<mvo> cachio: sort of, I was looking into it and then got into meetings - its "funny" because when I run this test via spread linode:debian-unstable-64 it does not fail for me
<mvo> cachio: I have a theory why it might fail, but if you also have one I'm keen to hear it
<cachio> mvo, I don't. I'll take a look now
<mvo> cachio: I think the problem is the following - in 2.21 we had only SNAP_REEXEC as the environment. so snapd starts, then re-execs and sets SNAP_REEXEC=0 to prevent it from re-execing again. now in cmd.go:InternalToolpath() we check for that key and if it is set we don't use the  tool from core. which is wrong in this case, I put a PR up for it, but it fails on test sright now
<cachio> mvo, ah, ok,
<cachio> mvo, which is th PR?
<mvo> cachio: 3589
<mvo> cachio: I think I have an idea, let me push something (once local unit tests are happy)
<Pharaoh_Atem> morning
<mvo> cachio: I pushed a new commit, lets see if 3589 is now happy
<cachio> mvo, ok, I could reproduce the issue
<cachio> mvo, I am in the machine
<cachio> mvo, do you want to check something?
<mvo> cachio: if you could run it with the two commits from 3589 that would be nice
<mvo> cachio: what did you do to reproduce?
<cachio> mvo, just executed using the flag -repeat 20 for the test
<cachio> to rerun it until it fails
<cachio> mvo, I'll try the same with your branch
<mvo> cachio: aha, nice. please let me know how it goes! strange that it needs -repeat 20 when in master it seems to fail consitently
<cachio> mvo, I am running on your branch now
<cachio> mvo, I'll let you know
<mvo> ta
<cachio> mvo, I reproduced the error with your branch :(
<cachio> mvo, https://paste.ubuntu.com/25089342/
<zyga> re
<niemeyer> cachio_lunch: #3505 reviewed, thanks!
<niemeyer> Hmm.. lunch is a good idea, biab
<mup> PR snapd#3590 opened: cmd/snap: snap cli to set or revert the custom store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3590>
<cachio> mvo,  I see this comment on the test https://paste.ubuntu.com/25089614/
<cachio> mvo, could it be affecting in 2.26
<cachio> ?
<zyga> re
<zyga> aha, good catch cachio!
<ogra_> zyga, if you have a bored moment on the weekend or so ... https://github.com/snapcore/pi3-gadget/pull/11 (though just taking a look at the resulting branch is probably easier than the diff https://github.com/ogra1/pi3-gadget )
<mup> PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/11>
<mup> PR snapd#3591 opened: interfaces/greengrass-support: adjust accesses now that have working snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3591>
<mvo> cachio: hm, thank you. there goes my theory. /me scratches head
<cachio> mvo, so /usr/lib/snapd/snap-update-ns should exist, right?
<pstolowski> mvo, cachio do you know if there is anything happening to linode? my travis job for #3569 has been sitting and waiting for start for ~4 hours. I've just cancelled it and restarted and it's still waiting for something
<mvo> cachio: yes, but this test is using snapd 2.21 which does not have it, in this case it should come from the core snap
<mup> PR snapcraft#1410 opened: tests: remove download timeout workaround <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1410>
<cachio> pstolowski, something weird is happening, perhaps we are reaching the limit of machines
<cachio> niemeyer, any idea about what pstolowski is saying?
<cachio> mvo, ok
<om26er> Hi! I can't login to snapd as it asks for 2-pass credentials. From the web interface I can login without 2-pass credentials.
<zyga> ogra_: oh, nice!
<zyga> jdstrand: commented on the greengrass PR
<cachio> pstolowski, I think the problem is on travis
<cachio> pstolowski,  it is not running the tests
<zyga> pstolowski: travis has limited capacity
<zyga> pstolowski: existing tests block running subsequent tests
<zyga> pstolowski: this should be displayed on the PR status page
<jdstrand> zyga: I responded
<jdstrand> zyga: unrelated, fyi https://bugs.launchpad.net/snapd/+bug/1704222
<mup> Bug #1704222: snap debug get-base-declaration does not work with 2.26.9 <snapd:New> <https://launchpad.net/bugs/1704222>
<niemeyer> cachio, pstolowski: Looking
<cachio> mvo, I think the problem is on the core which is in beta
<niemeyer> pstolowski: You mean it's sitting there yellow?
<cachio> mvo, not the stable one
<niemeyer> cachio: Is that what he was talking about?
<pstolowski> niemeyer, yes, it's been like that for a few hours
<niemeyer> pstolowski: Travis has a few queues.. one for the project, we can only run so many things concurrently, but also one for everybody
<cachio> niemeyer, the builds are in created state
<niemeyer> pstolowski: In some cases there's just too much going on
<niemeyer> cachio, pstolowski: When it's yellow, it hasn't even started, which means it can't possibly be about Linode
<niemeyer> Looking here we can see that indeed Travis has built some global backlog today:
<niemeyer> https://www.traviscistatus.com/
<cachio> niemeyer, I said the same
<niemeyer> This, specifically:
<niemeyer> https://usercontent.irccloud-cdn.com/file/7AqxcV5f/image.png
<mvo> cachio: interessting - does it work with stable?
<pstolowski> niemeyer, yeah i know.. i just don't recall it taking that long
<pstolowski> fair enough
<niemeyer> pstolowski: Unfortunately, your strategy of stopping and restarting was a really bad one in this specific case :)
<pstolowski> niemeyer, yes!
<cachio> mvo, I ran the test manually and worked, I am running it again
<cachio> mvo, I am running manually with beta now
<cachio> if it fails it means the problem probably is in the beta
<Chipaca> I'm in a maze of twisty circular imports, all alike
<Chipaca> so I'm going to EOW right about here
<Chipaca> niemeyer: mvo: (anybody else?): safe travels!
<jdstrand> zyga: is there a particular pivot_root mediation issue you were thinking about? I'd like to make sure we have a bug for it
<niemeyer> Chipaca: Thanks!
<mvo> Chipaca: thanks, appreciated!
<niemeyer> pstolowski too, but out of Warsaw rather than into it :)
<mvo> cachio: ta
<pstolowski> niemeyer, i got part of the https://forum.snapcraft.io/t/how-to-snap-get-root-document/522/2 story implemented (printing the keys), but not the ability to print root document. I need to add a spread test though so not proposing it just yet. i need to start packing stuff for tomorrow
<niemeyer> He's running away from us
<niemeyer> pstolowski: ð
<Chipaca> niemeyer: my envy stops me from wishing him well
<niemeyer> LOL
<pstolowski> :)
<Chipaca> pstolowski: break a leg :-)
<pstolowski> i'll drink a few beers for you guys :)
<cachio> mvo, manually works also with beta
<pstolowski> once afain, safe travels everyone, have a good sprint & time in Warsaw!
<pstolowski> o/
<cachio> mvo, the change that you did should work if the test updates the core from the store?
<zyga> jdstrand: just that pivot_root is the reason we are not using chroot, pivot root is transparent to apparmor so one can construct a fs where after pivot root all paths are allowed
 * zyga takes a break for birthday party (not his), back to hacking tomorrow, have some things to catch up after a slow eek
<zyga> week
<kyrofa> zyga, a kid? My son's was yesterday
<cachio> mvo, I think the problem is that this test is using a snapd from the store and not the built one
<jdstrand> bye zyga, have fun
<zyga> kyrofa: no, friends that are expecting one (finally we're not going to be the sole parents)
<zyga> kyrofa: kids are very unpopular in this generation apparently
<zyga> jdstrand: btw, just a quick question
<zyga> jdstrand: are you familiar with the hybrid DFA/NFA tables used by the binary representation?
<zyga> I found them rather curious
<zyga> I'm planning on documenting them via Documentation/ patch
<dpb1> hi there -- how do I build the core snap?  I'm searching online and not finding a lot
<jdstrand> zyga: only at the very highest levels. you would want to talk to jjohansen1
<kyrofa> zyga, ha!
 * zyga waves
<niemeyer> Yeah, Travis is definitely having trouble today.. we have almost the entirety of our machine pool powered off right now
<zyga> jdstrand: thank you!
<cachio> mvo, there?
<mvo> cachio: not really, its getting late here :/
<cachio> ok, I'll tell you on monday
<cachio> I have a fix for the upgrade test but it is partial
<mvo> cachio: ok, I think my PR is still useful, but slightly sad that this particular case is not fixed. *if* its getting the snapd from the store in the test, we probably just need to merge it to master and 2.27 and things should start working again?
<mvo> cachio: (I still think my PR addresses the root cause of the bug)
<cachio> mvo, agree
<cachio> if I install from stable the core
<cachio> mvo, I can't reproduce the error
<cachio> but if I remove the line "snap install core"
<cachio> the test gets stuck running
<cachio> Run configure hook of "core" snap if present
<mvo> cachio: ok, keep me updated on this, I have only half-a-brain available for it right now
 * mvo vanishes for some minutes
<cachio> mvo, I am gonna update your branch to push the fix in the test, is ok?
<cachio> mvo, or you prefer a different branch
<mvo> cachio: sure, just push to my branch
<cachio> mvo, I did it, tx
<mup> PR snapd#3592 opened: interfaces: opengl support pci device and vendor <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3592>
<kyrofa> jdstrand, please add that to your review backlog ^^
<jdstrand> I know this PR :) I'll do it now
<kyrofa> jdstrand, you're the best!
<mup> PR snapd#3593 opened: interfaces/wayland: add access to wayland compositors <Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3593>
<qu1nn_1> anyone familiar with the nextcloud snap?
#snappy 2017-07-15
<mcphail> qu1nn_1: yes...
<qu1nn_1> I followed the instructions and it is saying that when I go to <hostname>.local that the nextcloud page should come up, I am getting the apache page... any guidance on what to do now? (i am on a fresh install of debian 9)
<qu1nn_1> the instructions say I am supposed to create an admin pw on a nexcloud web interface.
<qu1nn_1> I will be right back going to reboot....
<qu1nn_1> nope, still coming up with the "apache2 Debian default page" when I type <hostname>.local
<qu1nn_1> is there a troubleshooting guide for nextcloud snap?
<qu1nn_1> how do you remove a snap install
<zyga> good morning
<mcphail> qu1nn_1: you must already have apache set up, and this will have claimed port 80 and probably 443. So, the nextcloud snap won't be able to claim them and won't work
<mcphail> qu1nn_1: if you're using the snap, you're going to be using the machine for a single purpose. If you need more flexibility, tge snap won't be for you (unless something has changed recently in the way kyrofa arranges the config)
<mup> PR snapcraft#1409 closed: snap: remove completer entry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1409>
<mup> PR snapcraft#1411 opened: tests: build the snapcraft snap in travis tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1411>
#snappy 2017-07-16
<qu1nn_1> how to I uninstall a snap on debian 9?
<mup> PR snapd#3594 opened: corecfg: add proxy configuration via `snap set core proxy.{http,https,ftp}=...` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3594>
<Son_Goku> jjohansen: hey
<mwhudson> is there any non-outrageous way to find out if a snap is available for a different architecture than the one you are on?
<Son_Goku> mwhudson, afaik, no?
<jjohansen> Son_Goku: hi
<mwhudson> (the outrageous way is curl --silent -H 'X-Ubuntu-Series: 16' -H 'X-Ubuntu-Architecture: arm64' 'https://api.snapcraft.io/api/v1/...')
<Son_Goku> mwhudson: yep
<Son_Goku> jjohansen, so how are things going?
<mwhudson> ah well at least i'm not missing something
<Son_Goku> mwhudson: unless we all are :)
<jjohansen> Son_Goku: alright, trying to get back into it/dig myself out of the pile of email after some vacation
<Son_Goku> did you at least enjoy your vacation?
<jjohansen> yep
<Son_Goku> jjohansen, what did you do?
<jjohansen> visited family, went kayaking, hiking, and spent a day at a water park
<Son_Goku> nice
#snappy 2018-07-09
<pstolowski> morning!
<zyga> good morning!
<zyga> man, sorry for being so late,
<zyga> pstolowski: hey, how are you? :)
<zyga> on the up side, my working space is ready and I'm after breakfast so ready to hack :)
<pstolowski> zyga: hey, great! it was a nice weekend, how about you?
<zyga> pstolowski: my wife has arrived here for the week, we saw more widelife yesterday and managed to score some nice photos :)
<pstolowski> :)
<Chipaca> ogra_: mo'in
<Chipaca> ogra_: you said "mvo is wrong, /etc/environment is rw", but mvo was talking about /etc/profile unless I missed something
<mup> PR snapd#5489 closed: release: snapd 2.34 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5489>
<zyga> pstolowski: question on https://github.com/snapcore/snapd/pull/5488#pullrequestreview-135324049
<mup> PR #5488: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488>
<zyga> hey Chipaca :)
<Chipaca> zyga: 'sup
<zyga> Chipaca: monday :)
<zyga> it's a bit chilly today but I'm doing allright
<zyga> I had a fantastic coffee this morning
<zyga> we scored a coffee grinder from the exposition in a store on Saturday
<zyga> and used it to grind coffee for the first time in ages
<zyga> the aroma and taste is superb
<Chipaca> zyga: :-D
<zyga> Chipaca: did you see this PR: https://github.com/snapcore/snapd/pull/5475
<mup> PR #5475: Remove unneeded calls to daemon-reload <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5475>
<zyga> I wonder if it is correct and we were doing useless ops all the time
<Chipaca> zyga: it's possible, yes
<zyga> or if there is a reason for deamon-reload _apart_ from updating systemd itself
<Chipaca> daemon-reload is needed for when an existing service file changes
<Chipaca> that's all afaik
<Chipaca> and we probably do it all the time just in case  (because thinking about whether the change we did means the service file changes is harder than just doing it)
<zyga> Chipaca: well, the PR claims that's not true
<zyga> Chipaca: it claims that the side-effect of daemon-reload is to clear the status of a failed service
<zyga> but otherwise systemd can manage by itself
<Chipaca> âIf you want systemd to reload the configuration file of a unit, use the daemon-reload command.â
<Chipaca> ^ from systemctl(8)
<zyga> I wonder if any of our tests actually capture this
<zyga> that is, changes the service file
<Chipaca> zyga: in any case it's marked as wip
<Chipaca> zyga: so I wouldn't assume e.g. all the Â«systemctl status yadda yadda || trueÂ» are meant to be definitive
<zyga> thank you, I will add that PR to the back burner to see what to do about it
<ogra_> Chipaca, hmm, not sure what i was reading there ... sorry :P
<Chipaca> zyga: there're a lot of failing spread tests saying "you should've run daemon-reload" fwiw
<zyga> aha, that is a good indication then
<Chipaca> zyga: all the ones i saw were 14.04, so it might indeed not be necessary after that
<Chipaca> zyga: OTOH the _unit_ tests were failing, so we didn't get to see the whole log
 * Chipaca hugs abeato 
<zyga> mmm
<Chipaca> it's possible we need to add a bunch of 'if systemd.IsOld() { systemd.Coddle() }
<abeato> zyga, Chipaca I am basically doing some testing on whether snapd needs to call daemon-reload all the time, please consider it a WIP as I just wanted to run CI on it  - not sure if I could do that without the PR :)
<Chipaca> abeato: it might be needed in 14.04 and optional afterwards, in which case i'd be ok with checking that
<zyga> abeato: maybe just ask systemd devs
<Chipaca> abeato: you can run ci on it but you'd need a key, and the keymaster is on holidays i think (or is that in august)
<Chipaca> abeato: doing it this way is fine (but as i said on the pr please check unit tests first)
<Chipaca> abeato: otherwise you're wasting resources to the kÃ±ot
 * Chipaca wonders if that's obviously Â«al Ã±udoÂ»
<abeato> Chipaca sure, will do
<Chipaca> abeato: ./run-checks --unit  should do it
<abeato> nudo maybe :)
<Chipaca> abeato: and ./run-checks --static should catch fmt and stuff also
<Chipaca> abeato: knot -> nudo, kÃ±ot -> Ã±udo, clearly
<abeato> there are things there that I think are needed for sure: reset-failed probably needs to be done whenever snapd removes a unit file, to clean the state
<Chipaca> abeato: reset-failed is a great insight, maybe in a separate pr?
<abeato> lol
<abeato> Chipaca, yup, as a minimum I will propose that later
<Chipaca> zyga: https://twitter.com/willkirkby/status/1016014401479041024
<zyga> that would win the obfuscated C++ contest if there ever was one ;)
<Chipaca> zyga: I thought Stroustrup was the IOC++CC winner for life
<niemeyer> Mornings
<pstolowski> o/
<niemeyer> Chipaca: That might be the Steering Committee
<mup> PR snapd#5436 closed: tests: add basic integration test for spread hold <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5436>
<mup> PR snapd#5485 closed: testing: support for interfaces on core18 <Blocked> <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5485>
<mup> PR snapd#5375 closed: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
<mup> PR snapd#5405 closed: tests: do not mask errors in interfaces-timezone-control <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5405>
<niemeyer> zyga: #5439 says it will be split.. should we close it then?
<mup> PR #5439: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5439>
<zyga> yes,
<zyga> I'm working on the 2nd patch of the split now, just pushed the first one :)
<mup> PR snapd#5439 closed: overlord/ifacestate: translate "core" <=> "snapd" as appropriate <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5439>
<niemeyer> zyga: Thanks!
 * zyga takes a break for lunch
<zyga> only a few tests left and I will propose all of remapping, ready and tested :)
<ogra_> cjwatson, do you happen to know how far https://forum.snapcraft.io/t/architectures/4972 is supported on the builders yet ? (i have some gadgets that can only be cross compiled where the build-on/run-on bits would be very handy, they workk locally but i dont know about build.snapcraft.io)
<cjwatson> ogra_: It's not.  I'm working on it
<ogra_> ok, thanks
<cjwatson> (as in, it's my top task)
<ogra_> awesome
<ogra_> happy to be your guinea pig if you need one :)
<cjwatson> the actual testing shouldn't be the hard bit.  just trying to get a huge pile of prerequisites in place
<ogra_> k
<pstolowski> zyga: hey do you have a moment for HO?
<zyga> pstolowski: yes, after the standup
<Chipaca> zyga: wrt transportation options for flock, https://i.imgur.com/jczldiD.jpg
<Son_Goku> kyrofa, are we at a point where we're going to want to package snapcraft for fedora?
<zyga> Chipaca: tank you :)
<pstolowski> zyga: thanks for the suggestion of looking into udevadm code
<pstolowski> zyga: those two binds we saw correspond to two event sources that udevadm monitor subscribes to - UDEV_MONITOR_KERNEL and UDEV_MONITOR_UDEV
<pstolowski> zyga: the kernel one gives very limited data that seem to correspond to what I get with go-udev
<pstolowski> zyga: you can tell udevadm monitor which one you want with --kernel or --udev  - it's both by default, thus two binds
<zyga> aha
<zyga> interesting
<zyga> can you subscribe to the other event source in go?
<zyga> and see what we get
<pstolowski> zyga: yes that's what i'm going to try
<pstolowski> zyga: ha! the comment in go-udev: Groups: 1, // TODO: demistify this field because msg receive if Groups != 0
<zyga> ;D
<zyga> yeah, I saw that TODO as well :)
<zyga> funny
<zyga> it's all undocumented mess
<pstolowski> zyga: that's tha 1 vs 2 magic value, it tells if you want kernel or udev
<zyga> this looks like a multicast group
<zyga> and it seems that 1 and 2 are just used in practice
<zyga> but man, which man page says so?
<pstolowski> zyga: yep, sounds plausible
<pstolowski> ok, go-udev doesn't accept udev events, looks like the format is different..digging in
<zyga> mmm, indeed
<zyga> see if you can read things with netcat
<zyga> or maybe not
<zyga> just do what you were doing :)
<pstolowski> zyga: i'm almost there (with go-udev), needs only small changes
<zyga> pstolowski: what is the wire format?
<kyrofa> pstolowski, this sounds suspiciously like... no... can it be hotplug?
<pstolowski> zyga: just a small header, followed by null-separated KEY=VALUE strings ;). only the headers differ between kernel and udev format
<zyga> kyrofa: yes
<zyga> kyrofa: but those are not the news you are looking for
<zyga> kyrofa: ;-)
<pstolowski> kyrofa: shh
<zyga> it's still far away
<kyrofa> Hahaha
<kyrofa> I figured, just nice to see movement
<pstolowski> kyrofa: 2 steps forward, 1 step back, that's how it goes ;)
<kyrofa> I feel ya
<zyga> kyrofa: I, for one, cannot wait to see those hotplug serial ports
<pstolowski> zyga: got it working!
<pstolowski> zyga: i get super rich data now \o/
<zyga> pstolowski: that's great
<zyga> pstolowski: does it also mean we can largely ignore reading sysfs now?
<zyga> (ourselves, udev handles that)
<pstolowski> this will probably be the most significat patch i'll have for upstream... but needs some more work. plus enumarating of existing device (info mode) based on udev is still TODO
<pstolowski> zyga: indeed i don't think we will need to read /sys
<zyga> pstolowski: I suspect that once you get the initial enumeration done you will have a very solid understanding of how hotplug will work
<zyga> as in, on your laptop you will see plenty of devices
<pstolowski> zyga: yes, it's just the go-udev enumeration which has same limitations as monitor mode.. will need to re-do it i think
<pstolowski> zyga: sweet, even for device unplugging i'm getting all the nice data such as serial etc
<zyga> right, because udev knows it
<joc> does anyone know if the 2.34 is release is expected to be progressed in the next few days? or is it held while people are offline?
<zyga> hey joc
<zyga> I think it will be on hold until next week
<joc> ok, thanks zyga
 * zyga is writing missing tests
 * zyga has some more useful tests now and iterates
<zyga> I could use some proteins
<zyga> ok, time to take a walk
<zyga> I'm close to submitting the whole lot
<ogra_> zyga, bugs have a lot of protein ... just eat some
 * zyga is back from a walk in the forest
<zyga> I met a small family of Badgers
<zyga> never saw any in my life before
<zyga> took some shaky photos while holding my dog so he would not chase after them
<mup> PR snapcraft#2177 opened: pluginhandler: use uname from the host <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2177>
<kyrofa> ondra, ^
#snappy 2018-07-10
<pstolowski|> mornings
<zyga> good morning!
<zyga> I'll start later as today is the market day so we need to go and buy groceries
<zyga> and my wife should not carry and heavy things anymore so I need to help
<zyga> hey Pawel :)
<zyga> ok, I did most of the heavy lifting now
<pstolowski> zyga: enumerating existing device as udev knows them is... problematic. now i understand why all the go udev implementations are cgo wrappers around libudev
<pstolowski> zyga: and go-udev might be the only native go, except it doesn't really use udev stuff :/
<pstolowski> zyga: parsing the output of `udevadm info -e` (exports udev database in a simple key=value format) might be one of the better options
<zyga> pstolowski: can you tell me more please?
<zyga> pstolowski: specifically what is problematic?
<zyga> pstolowski: what is the format natively used by udev?
<pstolowski> zyga: /var/run/udev/* has simple flat text files - one for every device/node it seems, and it's very bare. it doesn't have all devices it seems, e.g. when i plug a serial adapter it doesn't appear there, it seems udev keeps it in-memory only. to enumerate existing devices via udevadm you either query specific ones by names/paths, or just dump everything with `udevadm -e` and there is tons of logic in libudev when it
<pstolowski> enumerates
<zyga> pstolowski: and when you subscribed to the other netlink group and started to parse events, what kind of data was broadcast there?
<pstolowski> zyga: only the devices that get plugged since i subscribed
<zyga> aha, I see
<pstolowski> zyga: so it's two worlds to deal with
<zyga> so the problem is how to enumerate existing data set,
<pstolowski> zyga: yes
<zyga> I see
<pstolowski> zyga: the way i see it for the moment:
<pstolowski> zyga: we either subscribe to netlink for hotplug events, and parse udevadm to enumerate existing devices; or we just parse udevadm output for both cases (bonus is it's the same output format to parse then, then we don't actually need go-udev anymore); or we switch to some other go-udev implementation based on cgo+libudev
<zyga> I think cgo+libudev is strongly undesired
<zyga> because libudev has unstable protocol
<zyga> and this would complicate re-exec seriously
<zyga> we need to think how to approach the problem
<zyga> can you look into what libudev C code does?
<zyga> so that we understand the on-disk data format
<zyga> and the current on the wire format
<zyga> it seems that we could indeed run udevadm --monitor and just feed of that pipe
<zyga> but not sure
<zyga> this is something to discuss with gustavo IMO
<pstolowski> zyga: yep, i'll look into libudev more. also, the parsing of netlink data from udev is questionable and might have potential to break. they have a custom header (a bunch of ints, one of them tells you the offset where actual data starts). this header is *private* to the libudev/udevdaemon, it means it's a contract between libudev/udev basically and can change at any time (they don't even care about endianess there). so
<pstolowski> even monitoring via netlink has a risk of breaking
<zyga> pstolowski: I think we need to (realistically) support every wire format used by udev since Ubuntu 14.04-era onwards
<zyga> pstolowski: it is either that or parsing of (potentially equally fragile) text representation from udevadm
<zyga> pstolowski: or writing our own udev and shoving it into early boot
<zyga> (initrd)
<pstolowski> oh noes
<Chipaca> pstolowski: ?
<pstolowski> Chipaca: that's in response to what zyga suggested re own udev
<Chipaca> pstolowski: we'll write our own udev, with blackjack and hooks
<pstolowski> zyga: fwtw the text repr of udevadm looks quite stable due to its simplicity. but yes, it's all fragile
<zyga> pstolowski: yeah, all --porcelain
<zyga> Chipaca: lol
<zyga> Chipaca: on the other hand I'm very much happy to write one if we choose to
<zyga> Chipaca: if we choose to do this we must mask it as something entirely non-udev like so that phoronix won't notice ;-)
<pstolowski> :)
<Chipaca> call it Âµdev
<zyga> Chipaca: ooooh, I love it!
<zyga> Chipaca: can I can I can I? :D
<Chipaca> it looks like I'll never have time to do Âµubuntu, so, sure
<zyga> moobuntu for livestock
<zyga> but it would have to use apt for packaging, it is so apt
<niemeyer> Mornings
<zyga> hey hey
<pstolowski> morning niemeyer !
<niemeyer> pstolowski: Heya
<pstolowski> niemeyer: some interesting findings re udev, go-udev etc., we will need to meet and take some decisions
<niemeyer> pstolowski: Sounds good, let's try after the standup today
<zyga> niemeyer: we have the core 18 meeting then
<niemeyer> pstolowski: I'm hoping for a slightly shorter meeting as we have less people
<zyga> ah, indeed
<zyga> we should have plenty of time in between
<pstolowski> sure
<mup> PR snapd#5490 opened: store: make snap blobs be 0600 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5490>
<Chipaca> ^ should be an easy one to review
<zyga> done
<pstolowski> Chipaca: +1, with a suggestion
<Chipaca> pstolowski: your suggeestion wouldn't catch seeds though
<pstolowski> Chipaca: right, i didn't know it was supposed to; $(find /var/lib/snapd/{cache,snaps,seed/snaps} then; but, nvm
 * zyga is happy now
<zyga> all the remapping is tested and can be proposed now
<niemeyer> pstolowski: Have you seen the note on #5488?
<mup> PR #5488: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488>
<pstolowski> niemeyer: yes, thanks, will respond
<pstolowski> replied and closed
<mup> PR snapd#5488 closed: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5488>
<niemeyer> pstolowski: What's the status of #4940?
<mup> PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<pstolowski> niemeyer: i'm hitting various issues with it on existing spread tests; no clear pattern, various failures inluding kill timeouts. no idea why, there is no clear indication in the logs pointing at my changes (but oviously they are the suspect), and just re-runiing a failing test locally doesn't reproduce the failure
<pstolowski> niemeyer: in any case, in the light of what i'd like to discuss today i might need to make changes
<niemeyer> pstolowski: Are we seeing the same errors on master?
<pstolowski> niemeyer: no, except ocasionally with flaky tests
<niemeyer> pstolowski: We've seen kill timeouts on master before, but my understanding is that those were related to core and were fixed
<pstolowski> niemeyer: yes. but not at the rate i see on my PR
<pstolowski> niemeyer: i basically didn't have a succesful run on this PR yet
<niemeyer> pstolowski: If you're wondering about whether it's your PR's fault, I suggest breaking it down into smaller chunks, and pushing it so we can review and merge until we hit something suspicious
<niemeyer> pstolowski: In fact, given how long that's been up for review and the long history of merges, that might be a good idea either way
<niemeyer> pstolowski: It feels like that's been blocked for months now
<Chipaca> cp: not writing through dangling symlink 'squashfs-root/usr/bin/snapctl'
<Chipaca> ^ anybody seen those before now?
<niemeyer> Chipaca: No, but that's pretty nice actually
<niemeyer> Chipaca: In terms of cp not doing that, I mean
<pstolowski> niemeyer: the biggest suspect is plugging go-udev in.. which is the meat of this PR. I can probably split it into two PRs - some scaffolding, and then actually plugging it in
<niemeyer> Chipaca: We've recently merged a PR from mvo that changed the way this worked..
<niemeyer> Chipaca: It wasn't a symlink before
<niemeyer> Chipaca: by recently I mean yesterday :)
<niemeyer> pstolowski: I don't see go-udev in that RP
<niemeyer> PR
<niemeyer> pstolowski: Maybe that's why it's failing? :)
<pstolowski> niemeyer: and it was blocked for long time by go-udev dependency.. which got resolved ~2 weeks ago by incorporating go-udev
<pstolowski> niemeyer: no, go-udev package landed
<niemeyer> pstolowski: Ah, ok
<pstolowski> this PR actually makes use of it
<niemeyer> pstolowski: Ok.. how about this.. can we close it and get smaller PRs in, oriented after whatever we discuss today?
<niemeyer> pstolowski: We need to start flowing bits in
<pstolowski> niemeyer: okay. fwtw a few small bits landed already
<pstolowski> niemeyer: anyway.. the topic to discuss today might be a tough nut to crack for this entire story
<Chipaca> niemeyer: hmm. I wonder if master is broken because of this, then. Pretty consistent anything-but-ubuntu-16+ broke in the same way with my pr (but maybe it's my pr)
 * Chipaca running spread from master now
<niemeyer> pstolowski: Cool
<niemeyer> Chipaca: I received mixed broken/not-broken messages from Travis yesterday.. wouldn't be entirely surprising if something that got landed isn't entirely right given prior merges
<niemeyer> Chipaca: This is the relevant PR: #5375
<mup> PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
<niemeyer> jdstrand: Gentle ping about #4951.. no rush, just want to make sure it's featured somewhere in your list still
<mup> PR #4951: interfaces/screenshot: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
<mup> PR snapd#5491 opened: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<Chipaca> niemeyer: yep, master broken
<niemeyer> Chipaca: Well, at least it's a well known cause for once
<mup> PR snapd#5492 opened: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
<Chipaca> niemeyer: grmbl grmbl grmbl
<niemeyer> Chipaca: Any ideas given what you've seen?
<Chipaca> niemeyer: replace Â«cp -a /usr/bin/snap /usr/bin/snapctl squashfs-root/usr/bin/Â» with something that's mindful of the symlink
<niemeyer> Chipaca: Hmm
 * zyga proposed the interface re-mapping integration PR and the first of the tree patches :)
<niemeyer> Chipaca: The error is likely that we're doing that twice
<niemeyer> Chipaca: I mean, that command, if done twice, will fail on /usr/bin/snapctl
 * niemeyer tests the theory
<zyga> niemeyer: didn't we change the base snap by now?
<Chipaca> niemeyer: I don't think so, I think it's that core already has a symlink there
<zyga> so maybe base and the test support is doing the same thing now
<zyga> I can now start looking at existing PRs
<niemeyer> Chipaca: Yeah, but there's something that doesn't smell right there
 * zyga catches up with IRC
 * Chipaca takes a shower
<niemeyer> Chipaca: "cp -a" works on symlink over symlink
<Chipaca> niemeyer: *dangling* symlink is key i think
<niemeyer> Chipaca: This is copying a file over a symlink
<zyga> pedronis: would you have time to review 5492, you did an earlier iteration of the idea
<zyga> pedronis: I have it fully fleshed out now
<pedronis> I'll look at it later today  (it's a couple of nights that I'm not sleeping well and it makes me a bit slow)
<Chipaca> niemeyer: ok, so new hypothesis: coreutils change the behaviour of cp over dangling symlink, which is why it fails in 14.04 but not 16+, and presuambly fedora and opensuse have the old one
<Chipaca> hmm, that sounds wrong, fedora usuallly ship bleeding edge coreutils
 * Chipaca runs the test on fedora to check
<pedronis> Chipaca: anyway , it's probably more complicated than that becausee if we have snapd and core18, we want to change snapd, not the symlink in core18
<pedronis> I'm not quite sure how far we are in that
<Chipaca> niemeyer: actually, in 16.04, cp -a refuses to copy over a dangling symlink
<zyga> pedronis: thank you and take care, sleep is like credit, you have to pay back eventually
<niemeyer> Chipaca: I don't get what changes in the last few days for this logic to be broken now, but the logic does look broken indeed
<Chipaca> niemeyer: /usr/bin/snapctl became a symlink
<Chipaca> niemeyer: you yourself told me :-D
<niemeyer> Chipaca: I mean, the rm right above it removes snapctl from /usr/lib/snapd.. the follow up command then copies it into a different place
<zyga> niemeyer: new core snap was built?
<mup> PR snapd#4940 closed: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<niemeyer> Chipaca: It's just inconsistent... I suggest fixing it by removing *both* /usr/bin/snapctl and /usr/lib/snapd/snapctl, and copying *both* back
<niemeyer> Chipaca: The rm will likely have to be -f
<Chipaca> niemeyer: I'll give you a clearer picture of the failure in a bit (test spinning up)
<niemeyer> Chipaca: It's a bit uncertain because we're dealing with an external core
<niemeyer> Chipaca: Actually, that's likely where the failure comes from
<niemeyer> Chipaca: The passing code expected a previous core from edge.. once the PR was merged, the logic in the test became incompatible with the logic that was merged, somewhat ironically
<Chipaca> niemeyer: so, snapctl needs to be in libexec, and the one in bin a symlink to it, right?
<Chipaca> as per #5375
<mup> PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375>
<Chipaca> lynch! launch! lunch!
<niemeyer> Chipaca: Not libexec, lib/snapd
<Chipaca> niemeyer: http://paste.ubuntu.com/p/jq8nw6H8q2/
<niemeyer> Ah, nevermind.. we put that in libexec in some distros
<niemeyer> Chipaca: Typo in usrs
<Chipaca> dammit
<Chipaca> niemeyer: ta
<niemeyer> Chipaca: No need for the -f I think.. I missed the fact it was a * when reading the output
<niemeyer> Chipaca: Looks good
<mup> PR snapd#5493 opened: tests: prepare needs to handle bin/snapctl being a symlink <Created by chipaca> <https://github.com/snapcore/snapd/pull/5493>
<jdstrand> niemeyer: thanks for the reminder. I had it as blocked in the list so I fixed that
 * zyga focuses on core18-tests3 for now
<zyga> hey jdstrand
<zyga> how are you doing?
<zyga> jamesh: hey
<zyga> I saw some tweets from the conference
<zyga> how are you doing?
<zyga> jamesh: anything interesting to share?
<Chipaca> a curse on google:ubuntu-16.04-64:tests/main/interfaces-accounts-service
<Chipaca> was anybody looking into that one?
<jamesh> zyga: hi.  I had a chat with the flatpak/xdg-desktop-portal guys this morning during a BoF about improving support for snaps
<zyga> Chipaca: mmmm, perhaps pstolowski but I don't remember for sure
<Chipaca> jamesh: zyga: so much paella
<jamesh> zyga: we want to provide more info about a snap to xdg-desktop-portal, but don't want to add a new dependency, so the current plan is to add a new "snap" sub-command that returns the info in a machine readable format (probably keyfile or yaml), and have xdg-desktop-portal call that
<jamesh> zyga: probably passing the AppArmor security label as an argument, and maybe also process ID
<jamesh> zyga: the extra info I want is the desktop file ID for the confined app, and whether it has the network interface plugged
<jamesh> there might be more in future
<Chipaca> zyga: https://github.com/tremby/imgur.sh
<zyga> thank you!
<jamesh> Chipaca: we did have paella at the beach party, yeah.
<Son_Goku> jamesh, why would the AppArmor sec label matter?
<zyga> jamesh: neat
<Son_Goku> and that wouldn't be particularly useful when that isn't available (e.g. Fedora, CentOS)
<Son_Goku> I'd also suggest using either keyfile or json
<Son_Goku> those are a lot less brittle
<jamesh> Son_Goku: at the moment, xdg-desktop-portal won't detect a snap as confined without the security label
<Son_Goku> jamesh, could you do it in a more generic fashion?
<Son_Goku> I don't understand why the AppArmor label is required specifically for this
<Son_Goku> that defeats the abstraction between AppArmor and the sandboxing control
<jdstrand> hey zyga. pretty good, how are you?
<zyga> jdstrand: I'm good, enjoying the time with my family in the woods,
<zyga> I'll be in Montreal next week, are you going?
<jdstrand> nice! yes, I'll be there
<zyga> jamesh: I'd love to know what your plans are after the event, let me know if you think it would be useful to sync _during_ the event so that you can still discuss ideas with the flatpak team
<jamesh> Son_Goku: the AppArmor label was the most obvious way to detect that the application really was a confined snap (rather than a flatpak, or an unconfined app).  What would you suggest for systems without strict confinement?
<Son_Goku> jamesh, snap-confine has "grades" of confinement, which could be passed to xdg-desktop-portal
<zyga> jamesh: we could look at the root filesystem of the mount namespace
<zyga> jamesh: and see if it is /var/lib/snapd/snap/* or /snap/*
<zyga> jamesh: this could be used as a fallback in case the apparmor label is problematic in any way
<jamesh> Son_Goku: for reference, this is the information dbus-daemon gives us to make the decision: https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials
<jamesh> Son_Goku: I meant strict confinement as in what "snap debug confinement" prints
<jamesh> Son_Goku: that will say "strict" on systems where we have MAC controlling file system access and mediated D-Bus communication
<Son_Goku> that means it'll fail in partial confinement situations
<Son_Goku> which is basically everyone except Ubuntu
<Son_Goku> (and Solus)
<jamesh> zyga: so I guess the solution to ever problem ends up being "parse the mountinfo file" :)
<zyga> jamesh: no, you can really just read one symlink in proc
<zyga> it's nicer than mountinfo :)
<zyga> jamesh: AFAIR /proc/$PID/root
<jamesh> oh
<zyga> and then match against two patterns
<zyga> thigh AFAIR the symlink value is dynamic depends on the POV of the beholder, so if you are "inside" it will always have a value of /snap/* (needs checking)
<jdstrand> fyi, that's overstated-- there are quite a few distros that have it where snapd is supported. @popey provided me with a list recently
<jamesh> zyga: hmm.  readlink() on that returns "/"
<zyga> jamesh: ah, that's not useful then :/
 * jdstrand is referring go "< Son_Goku> which is basically everyone except Ubuntu (and Solus)"
<zyga> from the outside it would be different but it makes sense to be / on the inside
<jdstrand> to*
<Son_Goku> jdstrand, dbus mediation isn't upstream
<jamesh> zyga: it is a magic proc symlink, so doing open() on it would give a dir fd for the confined root.  I'm not sure how to convert that to the root file system though
<jdstrand> Son_Goku: dbus mediation *is* upstream in dbus. the kernel feature not yet, but is super close
<zyga> jamesh: I see, well, I'm offering to help if you need to discuss something and think I could be useful
<jdstrand> Son_Goku: I'm not arguing against your point of having to deal with partial confinement like Debian/OpenSUSE or devmode like Fedora, I was just clarifying your specific comment on 'only Ubuntu (and Solus)'
<Son_Goku> for full confinement, that's it, though
<jdstrand> Son_Goku: no, it isn't. that is my point. popey showed me a list recently
<Son_Goku> and that list is?!
<jdstrand> I'll let popey comment since I would have to dig around for it. if he doesn't have it at hand, I will do that
<popey> It's just a list of distros I've booted in a vm and run hello-world.evil to see if confinement works
<popey> i replied citing them in a thread on the forum
<jamesh> zyga: if there's anything more you'd like me to bring up, there's still another day of the conf.  Getting the in-principle support for the "call snap as a subprocess" solution was a good start
<jamesh> (and is probably the first step towards something that will work better on Fedora, etc too)
<jamesh> given what's currently in xdg-desktop-portal relies exclusively on AppArmor security labels
<zyga> jamesh: one thing that we can do that's simple
<zyga> jamesh: snapctl
<popey> jdstrand / Son_Goku https://forum.snapcraft.io/t/joystick-connection-request-for-xonotic/6244/7 the post in question
<zyga> jamesh: snapctl uses a cookie to talk to snapd as a given snap
<Son_Goku> popey, you proved my point
<zyga> jamesh: so it could be there, regardless of confinement we would be able to present meta-data about the snap being executed
<popey> Son_Goku: I don't know what point I proved :)
<jamesh> zyga: where is the cookie?
<zyga> jamesh: I think it is in the environment
<Son_Goku> jdstrand, popey's list boils down to Ubuntu and Solus
<zyga> jamesh: so running snapctl from inside a snap "authorizes" it as the snap
<Son_Goku> all the various Ubuntu flavors are a distinction without a difference
<popey> elementary, KDE Neon and Linux Mint are not flavours.
<Son_Goku> but they are derived from Ubuntu and do not change anything about Ubuntu in that manner
<Son_Goku> (Mint and Neon's irresponsibility about sec updates aside)
<ogra_> mint also installs its own kernel by default
<popey> (oh, and Zorin, which isn't in that list because that list if systems which do _not_ have GNOME Software by default).
<popey> ogra_: uh, you may be on outdated info
<ogra_> (which might or might not cause issues with snaps)
<Son_Goku> ogra_, you're wrong
<ogra_> oh, really ?
<Son_Goku> Mint uses Ubuntu kernel
<popey> yes, please check before claiming that again
<Son_Goku> they've done that for at least a few years
<ogra_> i know you can install the ubuntu kernel manually but their main reason for existance was always their own kernel
<Son_Goku> no
<popey> No
<Son_Goku> their existence is for Cinnamon Desktop
<Son_Goku> just like elementary's is Pantheon Desktop
<ogra_> it used to be the kernel too
<ogra_> good that this changed then
<popey> Lets talk about today rather than the past
<Son_Goku> anyway, point is, anything using Ubuntu AppArmor (aka Ubuntu or Solus kernel) has it
<Son_Goku> no one else does
<Son_Goku> one day, that situation will change (and I can stop calling it Ubuntu AppArmor then), but that day is quite a ways out
<jamesh> zyga: if we resort to parsing /proc/$pid/env, we may as well just look for SNAP_NAME
<jamesh> (as an indicator that it might be a snap app: the snap command could do a more rigorous check)
<zyga> jamesh: yes, though that's easier to spoof
<roadmr> jdstrand: hey! sorry for not announcing it earlier, reviewer-tools r1093 is live in the store (as of Friday I believe)
<jamesh> zyga: right, but false positives are okay here.  It'd just mean we unnecessarily call the snap command, and get back an error saying it isn't really a snap confined app
<zyga> jamesh: sure but if we are looking for anything and calling snap we could look at SNAP_COOKIE and run snapctl with some command, as a protocol it feels nice
<jdstrand> roadmr: thanks! fyi, I may ask you to turn on resquash enforcement this week when the squashfs-tools make it through SRU
<roadmr> jdstrand: great! sure, let me know. Remember we'll be in sprint mode next week, maybe to keep in mind.
<roadmr> jdstrand: but of course I'm available that week if we need to flip it back quickly (and we'll mostly be in the same room so that might be a plus hehe)
<jdstrand> roadmr: once they hit -updates, remind me, can we depend on -updates being applied immediately?
<jdstrand> roadmr: yes, it would be nice to say at the sprint "we just turned on enforcement again and are keeping an eye on it"
<roadmr> jdstrand: uhh great question. The safest bet would be to do an explicit upgrade, which I can do via an IS ticket request
<roadmr> jdstrand: so when it hits -updates, it should be in the store units in the next 24 working hours
<jdstrand> roadmr: ok, I'll keep that in mind
<niemeyer> zyga: You coming?
<zyga> yes
<thresh> is it only me or the color picker in the snapped gimp select the one and only blue color? 007ffd?
<Chipaca> thresh: wayland?
<zyga> re, sorry I had to feed my dog
<Chipaca> zyga: in soviet russia, something something something
<zyga> Chipaca: so we dogfood our stuff, right?
<Chipaca> zyga: isso
<popey> I prefer "Drink our own champagne" :)
<Chipaca> we've got enough verified developers i think i should work on the snap cli bit of that
 * Chipaca looks
<cwayne> popey: what you don't like dogfood?!
<popey> only on wednesdays
<cwayne> makes sense
<zyga> popey: that is grose ;-)
<zyga> my dog is grateful and returned for a hug
<thresh> Chipaca, nope
<thresh> i'm not that hip
<zyga> Chipaca: tests are not happy today, are they?
<zyga> Chipaca: that's a nice one
<zyga> Chipaca: MATCH errors, opensuse download errors, mount errors
<zyga> bonus combo
<zyga> https://api.travis-ci.org/v3/job/402187098/log.txt
<Chipaca> zyga: plz restart it
<zyga> ack
<zyga> done
<Chipaca> taw
<Chipaca> I'm going to have to reimplement tabwriter for this thing
<Chipaca> fun :-)
<zyga> which thing?
<zyga> pedronis: replied on your comment
<zyga> as for the incoming/outgoing terminology I'm open for changes but this is actually factually accurate representation of what happens
<zyga> pedronis: to stop changeing snap.Info we need to patch the interfac API layer heavily (ish)
<zyga> *changing
<zyga> pedronis: on the up side those are not really full snap.Infos, those are just re-mapped on the outgoing path and are no longer linked to anything else in snapd
<pstolowski> niemeyer: re talking to udev: no generic udev->dbus bridge (only udisks2 for storage devices). the most appealing to me is a proxy executable that both enumerates and monitors the devices, and links with libudev. for the prototype I could just wrap udevadm info & monitor in a script (or have a script that just outputs predefined events) and focus on business logic of snapd, once that works have a proper udev helper binary.
<mup> PR snapcraft#2178 opened: lifecycle: pass commands to containerbuild, not steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2178>
<zyga> pstolowski: I think the answer to your main comment is that those are not _really_ snap.Infos, we just use the type for that because certain things about it are the same
<zyga> er
<zyga> pedronis: ^
<zyga> pedronis: if you want I can look at separating those types out completely
<pedronis> zyga: I need to look a bit at code, but I'm close to eod
<zyga> pedronis: ok, I'll prepare a small PR that shows what this would look like
<zyga> pedronis: essentially interfaces.Info type needs to grow some counterparts for snap.{Plug,Slot}Info
<zyga> pedronis: and then we need to copy the data out of snap.{Plug,Slot}Info into the new interfaces.{Plug,Slot}PartialInfo
<zyga> so that there is no need to ever modify snap.{Plug,Slot}Info
<zyga> the new interfaces.{Plug,Slot}Info would only be used in the response to /v2/interfaces (and perhaps partially to connections later)
<zyga> but this doens't change the essence of the re-mapping, I think that is still correct
<Chipaca> zyga: I shal name thee 'hitter of restart job'
<Chipaca> zyga: (it just became green i think)
<zyga> Chipaca: oooh
<zyga> merge it pretty please
<Chipaca> it's only got one  +1 :-)
<zyga> Chipaca: I'm the serverless api server  that makes things work ;0
<Chipaca> but, yeah, niemeyer reviewed it on irc :-)
<zyga> pstolowski: we need a +1, can you spare a sec?
<Chipaca> merged
<Chipaca> done
<mup> PR snapd#5493 closed: tests: prepare needs to handle bin/snapctl being a symlink <Critical> <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5493>
<zyga> thanks!
<pstolowski> #4767 needs a second review... (for the brave only)
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<Saviq> hi all I've been getting store release / upload failures (500) from Launchpad, is that known? anything I can help with? https://launchpad.net/~saviq/+snap/subsurface-edge/+build/274030 is the failed release
<jdstrand> roadmr: hey, can you pull in r1095 of the review tools (adds 2.34 interfaces and an override)
<roadmr> jdstrand: sure!
<jdstrand> thanks!
<Chipaca> cprov: ^ see Saviq's q
<roadmr> mhh Saviq it looks like it was an error releasing only, for the arm64 upload
 * roadmr dives into logs
<zyga> pedronis: still here?
<mup> PR snapd#5494 opened: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494>
<Saviq> roadmr: I've been getting those in ~20% of the builds since the weekend, some of them upload failures, some release
<roadmr> Saviq: let's see what log diving says :)
<zyga> pedronis: this is roughly the kind of change we'd have to apply to stop sending snap.PlugInfo in api responses: http://paste.ubuntu.com/p/5YqMTm3j9P/
<Saviq> roadmr: https://launchpad.net/~saviq/+snap/subsurface-edge/+build/273719
<zyga> this is _just_ the patch to the interface repository
<zyga> a small change along this vein is needed in api.go and in the mapper (to stop changing PlugInfo)(
<zyga> I can polish this all the way and propose
<Saviq> roadmr: 0324, 0701, 1016, 1037, 1544 today (all UTC)
<Saviq> and ok, it's only been today, not since the weekend
<roadmr> Saviq: nice, thanks!
<zyga> pedronis: let me know what you think
<zyga> I need to break to take the dog out while it is not raining
<roadmr> Saviq: I think it's because of a problem we identified yesterday and a rollout is in progress to fix it (hopefully)
<roadmr> Saviq: I'll let you know when done and after that please let me know if it happens again
<Saviq> roadmr: ack, will do
<niemeyer> pstolowski|afk: If udevadm is enough, why not just calling it?
<niemeyer> pstolowski|afk: Send some notes on that forum message.. that should probably be an open thread, btw
<niemeyer> (sounds generally interesting and worth archiving)
 * zyga returns home wet
<zyga> so the week of rain starts now
<zyga> I also saved the home camera by wrapping it in one of the bags for dog poo, I was glad to have a few extras
 * zyga -> hot shower
<niemeyer> pstolowski|afk: Sorry, s/Send/Sent/ (but that was probably obvious)
 * Chipaca eods
<niemeyer> Have fun Chipaca
<niemeyer> I'll step out to run some errands as well.. back later
<jdstrand> roadmr: hey, what does this mean: "Store upload failed: The request is missing an Authorization header field containing a valid macaroon" - https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/274620
<jdstrand> roadmr: a better question is, how do I fix that?
<roadmr> jdstrand: macaroons have a hard expiration date of (I think) a year, is it possible this project has been pushing builds for a year or so?
<jdstrand> roadmr: yes
<jdstrand> roadmr: how do I regenerate the macaroon?
<roadmr> jdstrand: does this use build.snapcraft.io? or just launchpad?
<jdstrand> roadmr: just launchpad
<jdstrand> roadmr: I wonder if 'Update snap package' would do it, if I change nothing else
<jdstrand> (under 'Edit snap package')
<roadmr> hmm maybe but let me check
<roadmr> jdstrand: ok, so that should work, yes
<roadmr> jdstrand: ideally you'd get sent to SSO for authentication, that would strongly suggest it's getting a new macaroon
<roadmr> jdstrand: if not try changing some bogus value (and then back, like the channel for publishing)
<jdstrand> ok
<jdstrand> roadmr: chaning nothing didn't work. trying changing something now
<roadmr> \o/
<jdstrand> roadmr: chaning something, updating, changing back, updating didn't work for an existing build. will now try a new build
<jdstrand> it'll be a few minutes
<roadmr> O;/ sorry about that
<jdstrand> roadmr: oh, I was sent an email to go to https://launchpad.net/~jdstrand/+snap/snappy-debug/+authorize
<roadmr> interesting
<roadmr> jdstrand: Colin would be the expert here, this explains my amazed face at most everything you're encountering
<jdstrand> heh
<jdstrand> I'm going to wait to see what happens with the build before clicking the url
<roadmr> jdstrand: if you click on authorize you'll get a page "Authorize store uploads of fongo"
<roadmr> jdstrand: after clicking the button and going through the flow, I see "Uploads of fongo to the store are now authorized."
<roadmr> fongo is my snap :D
<roadmr> jdstrand: if your build still doesn't upload, it seems very likely hitting /+authorize will work
<jdstrand> roadmr: it didn't upload. hitting authorize
<roadmr> fwiw I saw the same flow to authorize the uploads, because I was just creating the snap
<roadmr> which is why I sent you on the wild goose chase :( sorry
<jdstrand> roadmr: that took me through SSO
<roadmr> \o/
<jdstrand> roadmr: and I can upload again. thanks!
<roadmr> whee
<roadmr> jdstrand: TIL about +authorize by the way :)
<mup> PR snapd#5495 opened: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <https://github.com/snapcore/snapd/pull/5495>
#snappy 2018-07-11
<Ronin> Hii there, so im using crux
<Ronin> anyway for me to install snap from source ?
<Pharaoh_Atem> niemeyer: you there?
<Pharaoh_Atem> Ronin: no
<Pharaoh_Atem> Ronin: unless you're referring to snapd?
<Ronin> Pharaoh_Atem: yee i was referring to snapd
<Pharaoh_Atem> Ronin: crux would be difficult due to missing systemd
<Ronin> i wouldnt call it missing , but thats unlucky i guess
<Ronin> my search for a way to get discord continues lol
<Pharaoh_Atem> Ronin: does CRUX provide flatpak?
<Pharaoh_Atem> hmm guess not
<Pharaoh_Atem> Ronin: Discord is available as a snap and a flatpak
<Ronin> Pharaoh_Atem: yupp i know
<Ronin> its the one package im missing
<Pharaoh_Atem> heh
<Pharaoh_Atem> it's the first time in a while I've heard of anyone using CRUX
<Ronin> im using void linux on my main system
<Ronin> installed crux on my laptop to try it out, gotta say i quite like it so far
<Ronin> just that im missing some packages
<mup> Bug #1781120 opened: 18.04 kernel 4.15.0-24 snappy can't start <Snappy:New> <https://launchpad.net/bugs/1781120>
<zyga> good morning
<pstolowski> mornings, hey zyga
<zyga> czeÅÄ!
<zyga> pedronis: hey
<zyga> pedronis: around?
<zyga> pstolowski: I'll move json serialization of various repo types to the daemon
<pstolowski> zyga: makes sense
<zyga> I think we agreed to do this long time ago
<zyga> or something similar
<zyga> wow
<zyga> I found a file with copyright 2014
<zyga> wow
<zyga> we have copies of repo json code in daemon :)
 * zyga is happy to clean this up
<oSoMoN> can someone in the know confirm that when a snap is unpublished from the store, it doesn't get uninstalled from user's devices?
<zyga> oSoMoN: that's correct
<zyga> we don't have any code that could uninstall a snap
<zyga> this way that is
<oSoMoN> zyga, thanks
<zyga> pstolowski: can you please look at https://github.com/snapcore/snapd/pull/5496
<mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
<pstolowski> zyga: sure
<mup> PR snapd#5496 opened: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
<zyga> I'll keep hacking in that direction, there is clearly some more cruft there
<zyga> Chipaca: hey
<zyga> around?
<Chipaca> zyga: no
<zyga> :D
<Chipaca> zyga: asquare
<zyga> perfect
<zyga> daemon api question
<zyga> how would you feel if I moved all the jsonization types to api_json.go
<zyga> I added some there because I'm cleaning up the interface repository json story
<zyga> and I noticed we have a few types scattered around the api.go file
<Chipaca> zyga: including the stuff in snap.go?
<zyga> while you think please look at 5496 api_json.go to see what that would look like
<zyga> no, only stuff unique to the api layer
<zyga> that is currently in random places in api.go
<Chipaca> zyga: daemon/snap.go
<zyga> ah, this one
<zyga> no, I don't think so
<Chipaca> zyga: it's the only snap.go :-)
<zyga> nothing there uses json tags
<zyga> I though of snap/*.go
<Chipaca> zyga: correct, code there just builds map[string]stuff
<zyga> that is fine
<zyga> I just noticed we have some duplication in the types
<zyga> because they were in separate packages
<zyga> and also some types were super-alike
<zyga> and just defined few pages away from each other
<Chipaca> zyga: if it's duplication between daemon and client, that was intentional
<zyga> no no
<Chipaca> (which isn't to say i agree with it)
<zyga> this is all in the daemon/* area
<zyga> I know about the purpuseful duplication with the client package
<Chipaca> k
<Chipaca> zyga: I'm not sure I understand 5496
<Chipaca> zyga: in general I think it's better to have the marshaller next to the type it's  marhsalling
<zyga> yes, but:
<Chipaca> zyga: were the slotJSON etc in daemon even used?
<zyga> 1) we never intended to return snap.{Plug,Slot}Info this way
<zyga> 2) we had duplicates between repo and daemon
<zyga> (yes, both were used /o\)
<zyga> 3) we want to introduce code that changes some of the info's just before they are sent and pedronis opposed doing that to the original types
<zyga> so I want to do that to the json types instead
<zyga> hence the clenaup
<zyga> *cleanup
<zyga> both types were used because we have legacy/non-legacy interface APIs
<Chipaca> fair
<zyga> and they used both by accident
<zyga> a bit silly
<pedronis> zyga: seems my worry is introducing lots of complications, otoh that remapping by taking an info and just changing name inside looks very strange/fragile at face value
<zyga> pedronis: not complications, cleanups
<zyga> pedronis: there were clearly copy/pasted types around
<zyga> pedronis: not that I didn't change the info that was handed in, I returned a modified copy
<Chipaca> some day I'll have time to rewrite daemon
<pedronis> IÂ know
<Chipaca> there's so much stuff i'd do better today
<pedronis> still strange
<pedronis> I'm also not sure did those infos had implicit slots in them, does it matter ?
<zyga> pedronis: they had slots, both implicit and not
<zyga> pedronis: they were added at a much earlier stage
<zyga> in the request/response timeline, not in our git log  timeline)
<pedronis> so were basically taking a snapd  snap info (with implicit slots) and calling it core ?  or the other way around
<pedronis> that's admittedly strange
<zyga> yes
<zyga> in reality it was just a way to return a snap name and slot name
<pstolowski> zyga: thanks for that cleanup.. i remember cleaning some of that (the legacy connections) but missed the second part
<zyga> pstolowski: I pushed the second patch to the PR so that there is no duplication inside the daemon either now
<zyga> ok, with this the re-mapping code should no longer have to touch snap.Info
 * zyga cannot wait for tests to finish
 * Chipaca afk for a while
<zyga> pstolowski, pedronis: https://github.com/snapcore/snapd/pull/5496 is green and blocking me
<mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
<zyga> can we land it
<mup> PR core18#44 closed: hooks: fix 030-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/44>
<zyga> guys?
<zyga> jdstrand: hey, around?
<pstolowski> zyga: i need to give it proper looked, only skimmed through it; will review before/after standup
<pstolowski> *look
<zyga> thanks
<pstolowski> zyga: sorry about that
<mup> PR snapd#5497 opened: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>
<zyga> pedronis: hmm is this expected:
<zyga> https://www.irccloud.com/pastebin/8R1R97lR/
<zyga> pedronis: I cannot abort change 54
<Son_Goku> kyrofa, when snapcraft can finally build Fedora based snaps, it should forbid excluding `/usr/share/licenses`: https://forum.snapcraft.io/t/legal-issues-when-excluding-usr-share-doc/6341
<pedronis> zyga: no idea
<zyga> ah, it timed out now
<pedronis> it has an undo
<pedronis> but systemctl as well
<Son_Goku> niemeyer: hey, you there?
 * zyga iterates on the signal test
<zyga> Chipaca: around?
<zyga> Chipaca: can you please review https://github.com/snapcore/snapd/pull/5496
<mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
<Chipaca> zyga: knee deep in spread tests
<zyga> ack
<zyga> next step: waist deep? :)
<Chipaca> zyga: I daren't venture more into the miasma, as it sucks you in
<Chipaca> also, I daren't postpone lunch
 * Chipaca goes to sort that out
 * zyga prepares for lunch
<zyga> eh eh eh
<zyga> Chipaca: would it make sense to have a way to install a snap without starting the services
<zyga> because the services require connection to an interface
<zyga> that is not denied but also not auto-connected
<zyga> Chipaca: the particular use-case is daemon-notify
<zyga> it is a bit silly but it is not auto-connected
<zyga> and this prevents daemon: notify services
<zyga> this prevents the snap from being installed
<zyga> catch 22
<zyga> in effect nobody can develop a daemon: notify service ever
<zyga> jdstrand: ^ FYI daemon: notify requires connected daemon-notify plug (not auto-connected) but this can never be done because failing services prevent the snap from being installed
<zyga> jdstrand: I'm not sure if a snap-declaration assertion can override this (auto-connection of a slot that can be connected manually) but this is not useful for developers as far as experience is concerned
<zyga> I think something has to go
<pedronis> zyga: yes, snap-declaration can set auto-connect per snap
<zyga> pedronis: thanks
<jdstrand> zyga: it isn't silly that it isn't auto-connected. there have been vulnerabities on the notify socket. there is a card (still) to investigate that further, but the decision was to manually connect for now.
<jdstrand> zyga: this sounds like a problem with the application. why is it crashing so hard?
<Chipaca> jdstrand: systemd kills a notify daemon if  it doesn't notify within a timeout
<jdstrand> I see
<jdstrand> well, yes, auto-connection is available for now
<Chipaca> but I thought you could just use snapctl to disable the service from the instlal hook
<zyga> jdstrand: it is not crashing, it is not starting according to systemd as Chipaca explained
<zyga> hmm, I wonder what to do, this is really about me fixing a flaky test
<zyga> jdstrand: so it _should_ auto connect in when installed locally with --dangerous?
 * zyga removed it for now, trying to see if this helps
<zyga> it's quite annoying trying to develop a snap that keeps failing to install :)
<zyga> I should break
<zyga> see you at the startup
<newbee> hi guys,  I have a java web application, now i want to create a snap for this app. when I tried to create a snap it shows "[Redirection detected from https to http. Protocol switch unsafe, not allowed.]" in the build part. please someone guide me to solve this problem.
<zyga> newbee: not a snapcraft expert but this seems like the URL was specified as HTTPS but something (perhaps a proxy) redirected that to a HTTP, thus nullifying the encryption of the connection.
<zyga> what is the URL you are hitting?
<newbee> @zyga, I am not using any URL for this, in my snap I call tomcat in the part. In the building part it shows this error.
<newbee> @zyga : the snap access the URL in the build.xml file to buils the tomcat
<newbee> @zyga :Can you please give me some examples to create the tomcat snap.
<zyga> no
<zyga> I don't know anything about tomcat
<zyga> let me look if we have any stock examples though
<newbee> Okay thank you...
<zyga> newbee: looking at https://wiki.ubuntu.com/snapcraft/parts I see some tomcat parts, maybe that will be of some help
<newbee> Is there any other way to create the web snap in ubuntu core?
<Chipaca> newbee: I think you'd be best starting a topic on the forum
<zyga> newbee: I think you can create a web-talking snap using the typical suspects: python, java, go; it's just that I'm not the best person to share examples with you as I work on the other side of snappy (the service)
<zyga> newbee: perhaps kyrofa or popey have some tomcat-based snaps they can point you to
<zyga> newbee: though Chipaca's advice stands: this is a perfect topic for the forum where people will see it outside of the 15minute focus window of your question here
<newbee> @zyga : Thanks for your help... I will start this topic on the forum...
<Chipaca> hmm, standup
<newbee> @Chipaca : Okay....
<popey> zyga: i have no tomcat snaps
<zyga> jdstrand: hey, about sd-notify, did we consider having snapd be the proxy for the socket
<zyga> jdstrand: so it could read the requests, inspect them and forward/ignore
<zyga> jdstrand: is this something that is doable or is systemd going to ignore the messages relayed by another process?
<jdstrand> zyga: we didn't afaik. I suspect that systemd would then monitor snapd in that case
<zyga> mmm, interesting,
<zyga> if this is something that would need systemd patches then we cannot rely on it
<zyga> so no notification by default, no proxying possible,
<zyga> jdstrand: although systemd-notify has a --pid argument so _perhaps_ we could
<jdstrand> zyga: as mentioned, this isn't a feature I'm super familiar with. there is a card to investigate further to see if we can make it auto-connect. that card continues to have several things in front of it
<zyga> jdstrand: sure, no worries, this is not a priority bump of any kind
<pedronis> zyga: I triple-checked,  with --dangerous auto-connect are based on the base declaration, so you get the things that are allowed there
<zyga> pedronis: thank you!
<zyga> pedronis: this makes sense now
<jdstrand> zyga: I can say that if snapd could somehow proxy it, it could probably be made auto-connectable (just need to make sure that a snap couldn't interfere with other snaps via the proxy
<zyga> pedronis: because base declaration connections vs no connections at all makes the difference
<zyga> jdstrand: right
<zyga> thank you both
<pedronis> zyga: notice that if we made  non-installable vs not auto-connectable, it would also solve the issue
<pedronis> given that it seems installing doesn't work anyway
<zyga> hmm, what do you mean by non-installable?
<pedronis> say you annot install a snap with interface, unless the snap-declaration says so
<zyga> ah, right
<zyga> yes
<zyga> though I'm not sure if we would dump the plug/slot and carry on as today or refuse outright
<pedronis> ?
<pedronis> it refuses outright
<zyga> re
<jdstrand> zyga: that said, writing up a proxy just because an analysis isn't done isn't great. someone could write up an in depth analysis and provide it to me, justifying auto-connecction (ie, that the code is safe from root attacks and the mechanism can't be used to influence other snaps)
 * jdstrand -> errand
<zyga> jdstrand: I won't write the proxy anytime soon, though the analysis seems like more complex (given the extent of systemd and the numerous versions we'd have to inspect)
<zyga> Chipaca, pstolowski: gentle ping about https://github.com/snapcore/snapd/pull/5496
<mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
<Chipaca> zyga: reviewing is happening as we speak
<Chipaca> zyga: or rather, it would be, but instead we're speaking
<pstolowski> zyga: you got my +1 an hour ago
<zyga> oh
<zyga> drat, github stale page :)
<Chipaca> zyga: what happened to the tests
<zyga> I would love to use github on a text mode interface with mouse clicks support if it at least reliably worked
<zyga> Chipaca: the tests for MarshalJSON, gone with the method, this is already tested by the api tests
<zyga> specifically for the code that runs getInterfaces or getLegacyConnections (AFAIR, the typing names from memory)
<zyga> the single call was inlined and that is tested as before, note that this patch didn't change any outcomes anywhere
<zyga> just removed redundancy
<zyga> Chipaca: thank you :)
<mup> PR snapd#5496 closed: interfaces,daemon: move JSON types to the daemon <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5496>
<Chipaca> zyga: that's not a thumbs up, that's a "if the nuclear explosion is bigger than my thumb i need to evacuate"
<zyga> haha :)
<zyga> aka the "nuclear painter's algoritm"
<zyga> algoritm
<zyga> man
<zyga> algorithm
<Chipaca> zyga: al juarismi
<Chipaca> zyga: so we can get into a gif vs jif fight about that as well
<zyga> giajef?
<zyga> poles often enumerate the letters in abbreviations
<zyga> so things are more like G-I-F than jif or gif
<Chipaca> zyga: it depends on whether you can read it or not i guess; Spanish does that for jpg but not for gif
<zyga> heta-i-efa
<zyga> or something
<zyga> efe
 * zyga needs to run an errand
<Chipaca> zyga: is it very obvious that we're waiting for spread here
 * Chipaca looks into tea
<Chipaca> zyga: niemeyer: what we should do i snapd is not try to start a service if it's type:notify and it's not connected
<Chipaca> that's enough
<Chipaca> in a world with warnings, we'd issue a warning at the same time
<ogra_> Chipaca, found anything interesting in your tea ?
<Chipaca> ogra_: enlightenment
<ogra_> !
<Chipaca> ogra_: a very narrow enlightenment, but still
<mup> PR snapd#5490 closed: store: make snap blobs be 0600 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5490>
<pstolowski> niemeyer, zyga good news, the libudev internal data header for udev events is the same in 14.04 and 18.04
 * zyga is in Åukta now
<Chipaca> zyga: is that pronounced "wukta"?
<pstolowski> Chipaca: wookta
<Chipaca> pstolowski: tks
<mup> PR snapcraft#2178 closed: lifecycle: pass commands to containerbuild, not steps <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2178>
<smoser> hi. if i try to register a name (pdftk) and it is coming up as "reserved". does that mean it has been reserved by someone else ? or possibly just that it is reserved due to there being a package name ?
<smoser> or per https://forum.snapcraft.io/t/pending-review-on-flock-reserved-name/5442 maybe all binaries in ubuntu got reserved names automatically ?
<kyrofa> smoser, indeed, just submit a claim for it
 * zyga returns for some evening hacking :)
<zyga> hey kyrofa
<zyga> how have you been?
<kyrofa> Hey zyga, not bad, how about you?
<jdstrand> matiasb_: hi! with the full epoch syntax, is this true: read and write must be lists of positive integers, with no transition specified (ie, no '*') and '0' not allowed?
<jdstrand> matiasb_: ie, this is ok epoch: {'read': [1, 2]}
<jdstrand> matiasb_: but this is not: epoch: {'write': [0, 1]}
<jdstrand> matiasb_: and neither is this: epoch: {'write': [1, 2*]}
<jdstrand> matiasb_: from the examples, it seems clear [1, 2*] is not allowed, but nowhere does it say n>0, so not sure about [0, 1]
<jdstrand> matiasb_: (n>0 is only specified with the simple syntax)
<matiasb_> jdstrand, o/ right, I think 0 is allowed in the lists; the only case where 0 is not allowed is when using the * syntax, which is not allowed inside a list
<jdstrand> ah, 0 is ok, just not with *
<jdstrand> gotcha
<matiasb_> exactly
<jdstrand> matiasb_: thanks!
<matiasb_> np!
<mup> PR snapd#5498 opened: snap: support hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5498>
<kyrofa> niemeyer, that's ^ for you
<niemeyer> <3
<niemeyer> kyrofa: Thanks!
<kyrofa> niemeyer, I just learned that the `command` of an app doesn't take the PATH in the `environment` key into account. Is that on purpose, or a bug?
<kyrofa> It always just appends it to the snap mountdir
<niemeyer> kyrofa: Yeah, it's on purpose.. what would be the use case for looking at an arbitrary path?
<kyrofa> niemeyer, for binaries in bin, for example
<kyrofa> Snapcraft supports this by placing wrappers in the root with the PATH defined, if snapd doesn't support it migration will be somewhat rough
<niemeyer> kyrofa: Sure, but what's the use case for not defining that explicitly?
<kyrofa> A nicety, I suppose. You can put a dir in the PATH and then not have to include the entire path in the command
<kyrofa> The real issue is that people are doing it today, so getting rid of wrappers either means rewriting folks `command`, or adding support to snapd to check the PATH
<niemeyer> kyrofa: They need to touch the command either way
<niemeyer> Right?
<niemeyer> Sorry, perhaps not the command.. the yaml I mean
<niemeyer> Since we need to support the current files untouched
<kyrofa> No, snapcraft does. Today it generates the wrapper and rewrites the command. Tomorrow it (ideally) stops generating the wrapper and only touches the `environment` of the command. But that can't happen if the command isn't found
<kyrofa> The user should notice no difference
<kyrofa> Again, ideally
<niemeyer> kyrofa: Yeah.. it's a bit of a bummer..
<kyrofa> Snapcraft can rewrite the app to be absolute, but that kinda sucks
<kyrofa> Err, relative to the root of the snap I mean
<niemeyer> kyrofa: I guess snapcraft could resolve the PATH itself in those cases
<kyrofa> Indeed
<kyrofa> Still probably better than a wrapper, but I was hoping we wouldn't have to touch what the user provided anymore
<niemeyer> kyrofa: and then ideally stop doing it when we detect a new format yaml
<niemeyer> (with base, etc)
<kyrofa> niemeyer, it also means that command chain items need paths to them. That doesn't seem overly verbose?
<niemeyer> kyrofa: No, seems okay.. the PATH in general is something the user sets up for their environment.. for a snap, we are explicitly defining what the command means.. it shouldn't change if things fiddle with the path
<kyrofa> Okay. Caught me by surprise, it may catch others
<niemeyer> kyrofa: I'm surprised in the opposite direction :D
<kyrofa> Heh
<kyrofa> Snapcraft can help with the messaging
<kyrofa> Hmm... that still won't solve all the cases though, e.g. where people actually use shell commands as a command
<kyrofa> `command: echo "hello"` works today. It can never work in that world
#snappy 2018-07-12
<kyrofa> That type of thing has been pretty handy for me in the past, I'd rather not lose it
<kyrofa> Suddenly all commands must be 1) binaries within the snap, and 2) be paths relative to the root of the snap, when historically neither was the case
<kyrofa> (from the point of view of a user of the snapcraft CLI)
<niemeyer> kyrofa: Historically that was actually the case in the design we discussed at least
<niemeyer> kyrofa: It's trivial to have any content inside a script
<niemeyer> kyrofa: And the path of the command being relative to the snap just means you know what you are calling
<niemeyer> kyrofa: Instead of trusting on the environment of the snap to define what a command even means
<niemeyer> kyrofa: The application stanza was supposed to be a way to hook up a script, not be the script
<niemeyer> kyrofa: EIther way, we have what we have.. let's catch up next week and spend some quality time to agree on a way to move forward that has more pros than cons
<niemeyer> kyrofa: By the way, that's always been part of the reason why I have a deep dislike for wrappers.. it makes it all magical and hard to understand a consistent design
<hunterk> hey guys, does vulkan work with snap packages?
<hunterk> I ask because I make the snap package for RetroArch and I've been trying to get our vulkan driver to work with it but it's just not coming together
<hunterk> I figured I'd check here before continuing to bang my head against it
<hunterk> it looks like libvulkan1 is getting included properly...
<pstolowski> morning
<zyga> hey hey
<zyga> boy, what a damp morning it is
<Chipaca> moin moin
<Chipaca> have you seen https://launchpadlibrarian.net/378130619/journalctl_-u_snapd.txt ?
<Chipaca> not sure what to make of it
<zyga> good morning Chipaca
 * zyga looks
<zyga> Chipaca: hmm, we are type: notify
<zyga> and it seems we didn't respond in time
<Chipaca> zyga: yeah, this is attached to the #1779948 so maybe it's just that
<mup> Bug #1779948: Snapd gets stuck when starting Ubuntu. <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1779948>
<Chipaca> zyga: the dns thing threw is what puzzles me though
<zyga> that dns thing looks like resolved
<Chipaca> zyga: did they call it that just to make conversation about its bugs harder
<zyga> Chipaca: could it be first boot and seeding and what not on an offline system with super laggy dns
<zyga> like I have a dns at home that doesn't work over tcp
<zyga> and doesn't work over udp with packet fragmentation
<zyga> so stuff keeps falling back to older/crappier version
<zyga> but it takes time each time
<zyga> actually
<zyga> about that:
<Chipaca> zyga: it's not first boot (earlier in the log output you see things being fine)
<zyga> Chipaca: I read that you can tell systemd that you are alive and still starting
<zyga> but not ready yet
<Chipaca> zyga: yes
<zyga> and then systemd extends the startup timeout
<pedronis> anyway reaching notify shouldn't involve seeding or any task really
<zyga> maybe we should?
<Chipaca> zyga: problem is that the random drain was done from an init() i think, so too early for us
<Chipaca> early and in arbitrary order i think (but i'm not sure)
<Chipaca> pedronis: mo'in! how're you doing today?
<pedronis> could be better, could be worse
<pedronis> Chipaca: could you look at #5473 when you have a bit of time
<mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
<Chipaca> pedronis: yep
<pedronis> Chipaca: I suppose, I should look at the warnings PR when IÂ have a bit of time
<Chipaca> pedronis: no rush
<Chipaca> afk, bbiab (need to go to the boys' school)
<pstolowski> need to take my daughter to the doctor, bbiab
<mup> PR snapd#5499 opened: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
<mup> PR snapd#5500 opened: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
<mup> PR snapd#5501 opened: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <https://github.com/snapcore/snapd/pull/5501>
 * Chipaca returns
<Chipaca> zyga: did you see what i said yesterday about not trying to start an app with an unconnected daemon-notify?
<zyga> mmmj
<zyga> maybe/
<zyga> I thought that was Samuele
<zyga> can you repeat please?
<Chipaca> zyga: âwhat we should do in snapd is not try to start a service if it's type:notify and it's not connectedâ
<Chipaca> that last 'it' is the daemon-notify interface
<zyga> mmm
<zyga> I didn't see that
<zyga> not sure if I agree, we should generalize that to be able to say
<zyga> this snap cannot be installed (or perhaps activated) when {set of interfaces} are not connected
<zyga> Chipaca: something like: plugs: daemon-notify: required: true
<Chipaca> zyga: the problem with generalising it is that then you need to make it general
<zyga> well, the problem of specializing it is that then you need to make it general too ;)
<Chipaca> zyga: first of all, required:true sounds wrong, like the snap won't install
<Chipaca> zyga: but that's just a name
<Chipaca> zyga: what happens if you put required:true on an app?
<Chipaca> on a plug on an app i mean
<zyga> Chipaca: one of the questions is if we want to have partially enabled snaps
<zyga> like you have app1 and app2 but not app3
<Chipaca> zyga: and it starts to seem more masturbatory than practical
<zyga> Chipaca: the syntax won't allow that AFAIK but even if it did my point was to indicate a given plug or slot as required, not the association
<Chipaca> zyga: I didn't follow that last bit
<zyga> defining a plug or slot on an app does two things:
<zyga> defines the plug or slot
<zyga> indicates association with an app
<zyga> my point was that the attribute ought to be associated with the interface, not with the association
<zyga> my gut feeling is this:
<zyga> let's sleep over it, think and come up with brainstorm material
<zyga> we can implement the subset for daemon-notify once we know where we want to go to
<zyga> so that we can implement a slice of the bigger cake
<Chipaca> zyga: where is this cake, and does it go well with coffee
<zyga> Chipaca: you are tempting me sir ;)
<Chipaca> zyga: cakes that don't go well with coffee: https://en.wikipedia.org/wiki/Yellowcake
<zyga> there is raspberry cake indoors
<zyga> it's raining all night and all morning here
<zyga> so mood is perfect for cake
<Chipaca> zyga: nice gentle rain in the middle of a forest? heck yea
<zyga> Chipaca: heck ...bzzzz (mosquito) yeah :(
<Chipaca> cake and spiced tea, or spiced cake and tea
<zyga> it's okay but at most 2/3 days a week
<zyga> I recall summer holidays when there was really no day without this never-ending rain
<Chipaca> zyga: ah, yes, after the second night it suddenly becomes a dystopia
<zyga> it's supposed to rain for the next 10 days
<Chipaca> "la ciÃ©naga" but with rain
<Chipaca> zyga: "oops they moved my flight i need  to leave right now to make it byeeeee"
<zyga> hahah
<zyga> montreal feels like going to the other hemisphere now
<Chipaca> zyga: almost but not quite
<Chipaca> vancouver would be
<Chipaca> zyga: bah, even montreal gets you from positive to negative longitudes
<Chipaca> so technically yes :-)
<niemeyer> Mornings
<Chipaca> [citation needed]
<zyga> my LTE link is down
<zyga> not sure if I can do standup video today
<zyga> if the weather continues like that
<AuroraAvenue> It surprises me that there are no separate ways to flag an issue with the developer with snap - except github or launchpad.
<popey> AuroraAvenue: do you have a specific issue to report?
<AuroraAvenue> popey, well I am tired, very tired, but if its an issue ya want then its an issue I'll grant you.
<AuroraAvenue> Xonotic doesn't open on Solus Os.
<popey> is there any kind of error message?
<popey> (if launched from the command line)
<AuroraAvenue> erm, hangon #fatfingers (me).
<AuroraAvenue> https://paste.ubuntu.com/p/Vhs5CgqK2J/
<popey> interesting. what's the output of `snap version` please?
<AuroraAvenue> I type > snap xonotic , right ?
<popey> `snap version`
<AuroraAvenue> oh sorry
<popey> I just installed it on Solus here and it works.
<AuroraAvenue> https://paste.ubuntu.com/p/PdDgrwtjCd/
<AuroraAvenue> must be my crud laptop, then.
<AuroraAvenue> popey, this isnot a pressing issue by the way.
<popey> it is more likely a kernel issue
<niemeyer> popey, AuroraAvenue: That looks like a confinement issue.. from the error message, looks like it cannot change to another apparmor profile
<niemeyer> zyga ^
<niemeyer> zyga: Any ideas?
<zyga> looking
<AuroraAvenue> right - originally install from solus 3.999 - its updated to past v.4 now - all upto date though.
<zyga> AuroraAvenue: hey
<zyga> I reported this issue to ikey a few weeks ago
<AuroraAvenue> hello
<zyga> AuroraAvenue: please run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*
<AuroraAvenue> right-oh
<zyga> and see if this fixes the issue
<niemeyer> AuroraAvenue: Depending on the version of snapd you are using, the snapd there may not be able to tell that the world shifted around it
<niemeyer> AuroraAvenue: More recent versions (as of several months now) can tell that, and will recompile things automatically when necessary
<zyga> it seems that apparmor in solus stopped loading profiles generated by snapd on boot
<niemeyer> AuroraAvenue: But it may always be an unrelated bug, obviously
<Chipaca> popey: what was the name of that better zenity you were using for i-don't-remember-which-snap?
<popey> yad
<popey> (used in tmnationsforever)
<Chipaca> popey: care to comment on https://forum.snapcraft.io/t/zenity-dialogs-in-a-snap/6359 about the why?
<Chipaca> popey: otherwise I will, and steal your karma
<AuroraAvenue> Okay - were rockin' xonotic now :D
<popey> woohoo
<Chipaca> AuroraAvenue: now put down the fps and get some sleep
<AuroraAvenue> yeah - must go to bed, your very true.
<AuroraAvenue> okay bye then.
<popey> :)
<AuroraAvenue> & thank-you
<popey> thanks for the report
<zyga> I'll ask ikey again
<popey> zyga: does this only affect new installs?
<popey> my vm works fine, and it's up to date
<daniellimws> hi, I know someone that recently received emails regarding snapcraft saying packages from the Ubuntu archive have received security updates, and even after making a small commit to rebuild the snap, he still receives these emails
<daniellimws> may I know if there's anything he missed?
<daniellimws> https://github.com/dj3500/hightail/pull/105#issuecomment-349701547
<mup> PR dj3500/hightail#105: Add snapcraft <Created by daniellimws> <Merged by dj3500> <https://github.com/dj3500/hightail/pull/105>
<popey> daniellimws: he probably got multiple emails over a few days
<popey> one for libjpeg and another for libcups2 and libpng12
<daniellimws> oh, so he does not need to do anything right? it will stop soon?
<popey> No, it will not stop.
<popey> He only gets one mail per security update.
<popey> but there were likely two security mails for different libraries.
<popey> He needs to trigger a rebuild and publish it
<daniellimws> ok thanks!
<popey> no problem
<ogra_> i wonder if anything in the mail text isnt clear enough
<ogra_> but re-reading the ones i got i personally find it pretty clear and understandable
<ogra_> perhaps some hint that this can happen frequently and even frequently in succession might be helpful ?
<zyga> popey: I don't know
<zyga> popey: perhaps?
<zyga> popey: but it was clearly the case that on reboot profiles were not loaded
<popey> Strange.
<zyga> and the command I gave above was fixing it
<niemeyer> pedronis, pstolowski: #4767 reviewed
<mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<pstolowski> niemeyer: thank you
<niemeyer> pedronis, pstolowski: If possible, please have a look soon over the comments so we can discuss further today
<pedronis> IÂ added some more thoughts on one of the main comments
<zyga> niemeyer: I pushed to https://github.com/snapcore/snapd/pull/5410
<zyga> running with --repeat 50 here
<mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
<zyga> so far so good
<niemeyer> pedronis: +1 on the general idea there
<zyga> Chipaca: hey, what's the back story for https://github.com/snapcore/snapd/pull/5494
<mup> PR #5494: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494>
<zyga> it looks ok but curious?
<pedronis> zyga: ?
<zyga> pedronis: ?
<zyga> are you asking about 5494
<pedronis> yes, John said the progress bar messes up the logs
<pedronis> not sure what is curious about that
<zyga> pedronis: well, that's what I was after
<zyga> there was no commit message that would say as much
<pedronis> he staid that at standup
<pedronis> *said
<zyga> must have slipped my mind, thank you
<zyga> pedronis: can you have a 2nd look on https://github.com/snapcore/snapd/pull/5492
<mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
<zyga> I dropped the functions that were problematic now; because of the re-factor in master they are no longer needed
<Chipaca> zyga: what pedronis said
<Chipaca> zyga: what's the commit message say?
 * Chipaca looks
<zyga> it says what's changed (-n) not why
<Chipaca> zyga: oops. fixed.
<zyga> thank you :)
<Chipaca> np
<zyga> I'll get some warm tea and be back shortly
<Chipaca> lunch
<zyga> it's so cold and humid today :/
<zyga> is damp the best way to express that?
<Chipaca> not sure,  i only begin to scratch the surface of the weather vocabulary
<pedronis> pstolowski: hi, could you finish looking at #5473 ?
<mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
<pstolowski> pedronis: will do
<zyga> pstolowski: I think you would be a good person to co-review https://github.com/snapcore/snapd/pull/5492
<mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
<zyga> https://github.com/snapcore/snapd/pull/5499 is trivial an green
<mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
<zyga> https://github.com/snapcore/snapd/pull/5500 is very simple and green
<mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
<zyga> pedronis: I pushed a fix to one of the core18 PRs you reviewed https://github.com/snapcore/snapd/pull/5401
<mup> PR #5401: [RFC] asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5401>
<pstolowski> zyga: sure
<pedronis> zyga: ah, thanks also for checking for classic (it doesn't make sense there)
<zyga> jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/5469
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<hunterk> does vulkan work with snap packages?
<jdstrand> zyga: yes (it's on the list already). I looked at it but want to check out a few things
 * zyga -> coffee
<zyga> jdstrand: super, thank you
<zyga> hunterk: hey, I believe it may but we don't have an end-to-end test for that
<zyga> hunterk: if you plan to make a snap with vulkan support please stay in touch
<zyga> hunterk: if you know of one please share it and try it out
<hunterk> eyy, thanks for the response! I added the dependencies to the RetroArch snap and it fails to load. Self-compiled (i.e., non-snap) works
<hunterk> but I figured it might need a plug or something, like the way there are Wayland and X11 plugs
<hunterk> https://github.com/libretro/retroarch-snap
<hunterk> btw, thanks popey for the recent PR!
<popey> np :)
<jdstrand> roadmr: hey, can you pull r1102? this has the epochs changes and two other bugs reported by the store team (and a fix for arm64)
<jdstrand> s/bugs/bug fixes/
<roadmr> hi jdstrand
<roadmr> sure, I'll do that
<jdstrand> roadmr: thanks! :)
<jdstrand> sergiusens_: hey, can you remind me about something with the vm work? I have little armhf and arm64 boards with Ubuntu Core that I 'snap install classic' and then install the snapcraft deb in them, then run 'snapcraft'. this has been the recommended way to build snaps for architectures that don't match one's laptop/desktop
<jdstrand> sergiusens_: while it is possible to use qemu to fully emulate armhf or arm64, that is painfully slow. will the new vm require a slow vm or can I still use the classic snap in this manner?
<popey> jdstrand: surely launchpad is faster?
<jdstrand> popey: no, it isn't. my builds won't start for an hour atm for both armhf and arm64
<jdstrand> that is pretty common in my experiencce. plus, sometimes you don't want to push something to edge. you want to test before pushing to edge
<popey> Sure.
<popey> I tend to use a Pi running classic
<popey> not core
<jdstrand> that's the same question essentially
<jdstrand> I don't have vms of armhf and arm64, so what will I have to do in the new world?
<zyga> hunterk: do you get any apparmor denials? missing so files on startup?
<jdstrand> s/will the new vm/will the new vm work/
 * zyga finished some life interrupts and returns to coffee and another patch
<mup> PR snapd#5501 closed: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5501>
<sergiusens_> jdstrand: there is going to be a I know what I doing kind of toggle where you won't be forced into a VM
<sergiusens_> jdstrand: the "I know what I am doing" and the implications of that (also related to buildd, docker and what not) has a session setup for the sprint next week; I suggest you attend :-)
<sergiusens_> jdstrand: we have two follow up stories wrt cross compiling and native building which aren't ironed out completely; as a personal sidenote, building using qemu-system-aarch64 for me was faster tha building on a rpi with its really slow i/o.
<hunterk> zyga: no, it just says it can't find the vulkan loader, though the vulkan loader lib (libvulkan1) is indeed in the snap's libs
<mup> PR snapd#5502 opened: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502>
<pedronis> Chipaca: pstolowski:  ^
<pstolowski> thanks
<Chipaca> pedronis: ack
<mup> PR snapd#5503 opened: tests: add missing slots in classic and core provider test snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5503>
<zyga> hunterk: hmm, can you wait till next week, we have one person on the team that worked on vulkan lately
<zyga> hunterk: just show up on Monday and ask mborzecki here
<hunterk> sure thing. I'll just idle in here and they can ping me or I'll ping them
<zyga> hunterk: thank you, and welcome :)
<zyga> hunterk: we cannot fix and find everything outselves so hands on experiments and feedback like yours is crucial
<hunterk> my pleasure. I've been enjoying the snap format so far
<popey> <3
<zyga> I imagine it's quite like the 0.x days of dpkg :)
<zyga> just with different set of issues
<zyga> niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/5410 please
<mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
<pedronis> zyga: is some kind of follow up using #5492 up for review?
<mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
<zyga> pedronis: yes, there's a PR with everything remaining ...
<pedronis> zyga: ?
<zyga> pedronis: here
<zyga> https://github.com/snapcore/snapd/pull/5491
<mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<pedronis> zyga: why is it blocked and not marked core18 ?
<zyga> because that is my integration PR and as I said in the description there the point is to review this patch by patch to avoid one big PR it was before
<zyga> as for core18, yeah, it should be marked
<zyga> if you prefer to review the whole lot we can do that too
<zyga> it's the same code
<pedronis> zyga: I don't prefer the whole lot, but I prefere something with a bit of usage
<pedronis> before approving the other one
<zyga> that's why I cross-linked them
<zyga> so reviewers can see the code in context
<pedronis> ?
<pedronis> an integration branch might or might not be context
<pedronis> it depends how close to final it is
<pedronis> I'm just a bit confused atm
<zyga> sorry about that, the cross linked branch is the complete use case
<zyga> everything I intended this for
<zyga> this is not the huge core18 integration branch that mvo opened, it's scoped and focused for interface remapping alone
<pedronis> ok, then there is nothing to split out of it, no?
<zyga> that's correct
<pedronis> it needs to be marked core18 and reviewed?
<zyga> it's just the first patch out of the set
<pedronis> which one?
<pedronis> are you talking 5491 or 5492 or both?
<zyga> the small PR (5492) is just the first patch of the whole feature (5491)
<zyga> in reality we could close 5492 and review 5491 but I thought this would be harder
<pedronis> but you said there is nothing more to split out of 5491  ?
<pedronis> I'm missing what "first" means here
<zyga> nothing to split as in split one patch into two
<zyga> it's just a way to review patch-by-patch on github
<pedronis> you lost me
<pedronis> what more patches are coming?
<pedronis> things before 5491 or after?
<zyga> there are two branches, one with 5 patches, one with 2 patches that are the 2 oldest of the 5
<zyga> before nothing
<zyga> after all of this lands we need to actually enable "snapd" to host implicit slots, this is not proposed yet as that was blocked by a number of other branches
<pedronis> are you saying you will make a PR for each patch in 5491 ?
<zyga> that was my plan, yes
<pedronis> ????
<pedronis> it doesn't seem that big
<pedronis> but maybe I'm missing something
<zyga> no, that's all really, if you think reviewing 5491 is okay we can just do that instead
<pedronis> yes, might be simpler
<zyga> I tend do to this because shorter reviews are easier to collect
<zyga> pedronis: feel free to close 5492 and let's focus on 91 then :)
<pedronis> to be clear  I like patches <300,  I can live with 500+, I find stuff over 600 large, but also dislike reviewing stuff without context
<zyga> understood
<zyga> I should have communicated that clearer in the PRs
<pedronis> yes, the fact that they are obviously out of order and not all tagged confused things a bit more
<pedronis> zyga: I'll try to go over 5492 in my morning tomorrow
<zyga> pedronis: thank you
<zyga> shall I close https://github.com/snapcore/snapd/pull/5492 ?
<mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
<mup> PR snapcraft#2179 opened: cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2179>
<pedronis> zyga: yes
<pedronis> sorry, I mean going over 5491
<zyga> ah, yes
<mup> PR snapd#5492 closed: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5492>
<zyga> since the history is the same you can look at how the usage is on either "end" of snapd by looking at
<zyga> https://github.com/snapcore/snapd/pull/5491/commits/0a53fdc733ffe1d1ca0fc0bf0d619e333ac73e3b
<mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<zyga> https://github.com/snapcore/snapd/pull/5491/commits/24c2448b880321f6bf28da24b3cc7bedfef06ece
<zyga> the API tests in the latter patch are interesting, I used a case-swapping mapper to show how things like "snap connect PLUG:SLOT" are handled
<zyga> similar approach was used in the state tests
<zyga> though there the change is smaller
<zyga> thank you pedronis!
<zyga> I need to break for a walk with Bit soon
<zyga> but expect one more PR from me
<zyga> pedronis: and if we can land a support branch for tests I will also have the patch that enables implicit slots on snapd snap
<mup> PR snapd#5504 opened: interfaces/pulseaudio: be clear that the interface allows playback and record <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5504>
<jdstrand> niemeyer: fyi, https://forum.snapcraft.io/t/pulseaudio-recording/6361. It would be good if someone (I've requested the desktop team) to drive this, but want you to be aware
<Saviq> kyrofa: hey, is `snapcraftctl set-version` a thing yet?
<niemeyer> jdstrand: Thanks, looking
<niemeyer> jdstrand: Commented
<jdstrand> niemeyer: thanks, I responded
<kyrofa> Saviq, yessir, https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
<sergiusens_> Saviq: kyrofa for an easier to read version of that https://snapdocs.labix.org/extracting-information-from-sources-in-snapcraft-parts/4642
<niemeyer> jdstrand: re-replied
<Saviq> kyrofa, sergiusens_: thanks :)
<Saviq> store folk, can you say what does this store upload fail mean: https://launchpad.net/~mir-team/+snap/mir-kiosk-edge/+build/276950 ?
<jdstrand> niemeyer: and so did I, twice. and will replied
 * zyga returned from a 10km walk :)
<zyga> jdstrand: https://lwn.net/Articles/759499/ (!!!)
<jdstrand> apparently my subscription has expired
<zyga> feels like I could write snap-confine again with those new syscalls
<zyga> jdstrand: can you ack trivial https://github.com/snapcore/snapd/pull/5500 and even more so https://github.com/snapcore/snapd/pull/5499
<mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
<mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
<jdstrand> zyga: done
<zyga> thank you
<mup> PR snapd#5500 closed: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5500>
<mup> PR snapd#5499 closed: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5499>
#snappy 2018-07-13
<pstolowski> Mornings
<zyga> hey ho
<Chipaca> let's go
<zyga> morning :-)
<zyga> overcast but warm today
<zyga> Chipaca: I wrote down my thoughts on daemon-notify: https://forum.snapcraft.io/t/its-a-little-bit-hard-to-use-daemon-notify-for-sd-notify/6366
<zyga> also did a tweet storm on twitter :)
<Chipaca> zyga: I saw your tweets
<Chipaca> zyga: also yesterday's
<Chipaca> zyga: keep it up :-)
<zyga> thank you for the encouragement :)
<zyga> I was wondering if those are useful
<zyga> and how long I will keep it up
<zyga> uh, Guido resigned from Python
<zyga> that's a biggie
<Chipaca> zyga: he got his calendar wrong, it's not april 1
<Chipaca> maybe it's some crazy dutch version of april fool's
<zyga> I envision he will pick up gardening now
<zyga> or sheep
<Chipaca> like april fool's but more racist
<zyga> so, the bottom line is
<zyga> if you do something for fun and love
<zyga> don't let others tell you how
<zyga> I cannot imagine how he must feel
<Chipaca> zyga: and now you know why snapd team doesn't have a line manager
<popey> zyga: is there any particular reason you're doing long tweet threads rather than blog posts recently?
<zyga> popey: experimenting with the format mainly
<popey> If you collated those tweets together, they'd probably make great blog posts for snapcraft.io/blog
<zyga> popey: I may do both actually, since the text can live in two places
<zyga> mmm, I can do that
<popey> we'd love to have more content there which is technical and approachable
<zyga> I'll do a hybrid twitter/blog post today and we can see how that can show up on snapcraft.io
<popey> we make quite a bit of effort to get the blog posts out there. your tweets will die overnight, "nobody" will see them
<popey> the blogs will live on, and can be re-shared (if they're evergreen)
<zyga> evergreen?
<popey> timeless
<zyga> ah
<pedronis> well afaiu zyga's is tweeting about work in  progress work
<zyga> yes, it's not the kind of post to return in 3 weeks
<popey> right, some are, some aren't
<zyga> but yeah, it's easier to read on a blog so I will aggregate as posts as well
<pedronis> all code will be written and deleted and then rewritten (maybe)
<popey> but putting it on twitter from an account nearly nobody follows means nobody sees it
<popey> if the goal is just braindump fair enogh :)
<zyga> I refreshed https://github.com/snapcore/snapd/pull/5307
<popey> but if you want the content out there, I'd encourage blogging and working with us to promote them :)
<mup> PR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
<zyga> it should go green soon
<zyga> popey: I want it out there, it was just me experimenting with the format really
<zyga> and as evening memory save for tomorrow (but a blog does that too)
<popey> :) gotcha
<zyga> and thank you for noticing, this is important to me
<popey> <3
<zyga> pstolowski: hey
<zyga> do you need https://github.com/snapcore/snapd/pull/5433 ?
<mup> PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433>
<zyga> or has that changed since we discussed last?
<zyga> Chipaca: last chance to see https://github.com/snapcore/snapd/pull/5446 in case you want before I merge it
<mup> PR #5446: coreconfig: add support for `snap set core network.disable-ipv6` <Created by mvo5> <https://github.com/snapcore/snapd/pull/5446>
<zyga> it's green and has +2
<Chipaca> zyga: that should be 'system' though, right
<Chipaca> in any case, go for it
<zyga> should it?
<zyga> I can chance it to system
<Chipaca> zyga: I mean, in user-facing docs
<zyga> ahh
<zyga> I see what you mean now
<pstolowski> zyga: yes i need it, it's independent of udev bits we discussed
<zyga> I misunderstood that as "snap set core system.disable-ivp6"
<Chipaca> zyga: internally right now it's core, but system is what we should talk about because system is core now but coreXYZ later
<zyga> Chipaca: totally agreed
<zyga> Chipaca: I will tweak the spread test
<zyga> in a world of iot customers ask for an off switch for ipv6
<zyga> in some distant future the core snap version 1664 will be easy to confuse with 16-64 but perhaps nobody will use embedded 64bit address space anymore
<zyga> Chipaca: I added a test for system snap for the ipv6 config now, thank you!
<zyga> I will merge when green
<Chipaca> zyga: ð
<Chipaca> zyga: or should I say ððð¯
<zyga> I feel emoji deficient now
 * zyga is enjoying fresh coffee
<zyga> pressure must be low today, I'm more sleepy than usual
<mup> PR snapd#5505 opened: interfaces/hotplug: udevadm output parser <Created by stolowski> <https://github.com/snapcore/snapd/pull/5505>
<mup> PR snapd#5506 opened: cmd/snap: add a green check mark to verified publishers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5506>
<Chipaca> ^^^ look maw, it's terminfo's stupid inbred cousin!
 * zyga forgot to eat breakfast today
<zyga> Break
<zyga> Mmmm, I feel tired somehow
<zyga> pedronis: what do think about the branch?
<pedronis> zyga: what branch?
<zyga> The remapping one
<pedronis> zyga: I added comments there
<pedronis> a while ago
<zyga> Oh, super. Let me look
<zyga> Thank you!
<zyga> Replied just now
<zyga> I will deal with the coffee and add mapper that returns system in the API layer. We may need to differentiate the state and API mappers though, to keep rollback around (so that state is always mapping âsnapdâ to âcoreâ on disk)
<zyga> This is also a chance to rename the incoming outgoing words
<zyga> To do explicitly talk about state loading/saving and API requests/responses
<Chipaca> in test-snapd-tools.publisher expected 'canonical', got 'CanonicalÃ¢Åâ'
<Chipaca> Iï¿½Unicode
<zyga> Woah?
<zyga> Hehehe
<zyga> But ... why?
<Chipaca> zyga: why what?
<zyga> Is the real value ascii
<zyga> Why did it get corrupted
<Chipaca> zyga: answering that requires investigation
<Chipaca> zyga: did the python checker get it wrong? did the log print it wrong? is the browser using the wrong encoding? etc etc
<zyga> Because software sucks and weâll all pick up gardening instead ;-)
<zyga> I vote for python
<Chipaca> zyga: I name myself BGFL
<zyga> Since Guido left python started throwing Unicode errors on all 7 bit ascii values
<Chipaca> zyga: for _this_ one, my money is on the browser
<zyga> Dead hand system (aka dead snake)
<Chipaca> zyga: confirmed, it's the browser; log file is fine
<Chipaca> in test-snapd-tools.publisher expected 'canonical', got 'Canonicalâ'
<Chipaca> HAH! suse's default locale is not UTF-8ish
<Chipaca> for suse: in test-snapd-tools.publisher expected 'canonical', got 'Canonical*'
<mup> PR snapd#5498 closed: snap: support hook environment <Created by kyrofa> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5498>
<King_InuYasha> obs-build defaults to POSIX / C, even though openSUSE itself defaults to C.UTF-8
<King_InuYasha> zyga, Chipaca ^
<Chipaca> King_InuYasha: I wonder why our spread box isn't getting that one
 * Chipaca spins it up to check
<cjwatson> one of the reasons very recent python has the automatic UTF-8 upgrade stuff
<zyga> hmm
<zyga> bad restore codE? https://www.irccloud.com/pastebin/d59S4fs6/
<mup> PR snapd#5504 closed: interfaces/pulseaudio: be clear that the interface allows playback and record <Simple> <Created by jdstrand> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5504>
<Chipaca> King_InuYasha: in opensuse 42 that we run spread on in GCE, LANG=POSIX, with just LC_CTYPE=en_US.UTF-8
<Chipaca> what even is LANG=POSIX
<Chipaca> 'in the lang of posix where the standards lie [through their teeth]'
<ogra_> that definitely needs to be POSIX.UTF-8 :P
<ogra_> how else would you get standardized umlauts
<mup> PR snapd#5494 closed: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5494>
<King_InuYasha> Chipaca: POSIX is an alias for C
<jdstrand> niemeyer: can you add https://forum.snapcraft.io/t/tio-request-for-classic-confinement/6209 to your list of considerations for classic?
<niemeyer> jdstrand: Of course, thanks
<jdstrand> thanks
<smoser> hi. is it possible to change the mode (jailmode/devmode/classic) of an installed snap ?
<Chipaca> smoser: it is not
<Chipaca> smoser: well
<Chipaca> smoser: 'snap refresh' can do it
<Chipaca> smoser: but 'snap switch' cannot
<Chipaca> smoser: why?
<smoser> jsut curious mostly.
<smoser>  https://github.com/smoser/pdftk/issues/1
<smoser> one solution to that is to instlal with --devmode (i think)
<Chipaca> smoser: devmode stops you from getting updates though
<jdstrand> smoser: that won't work cause devmode also uses the mount namespace and snap-specific /tmp
<Chipaca> heh, and what jdstrand said
<smoser> right.
<Chipaca> smoser: what i've done when I had things in tmp is use bash's <()'s
<smoser> thanks jdstrand . so the only solution there is "don't  use /tmp"
<Chipaca> smoser: so instead of pdftk infile outfile, pdftk <(cat infile) >(cat > outfile)
<smoser> well the snap should be able to write to its stdin and stdout anyway
<smoser> so you shouldnt need the (cat)
<Chipaca> smoser: ah, if pdftk handles stdin/stdout, sure
<smoser> just snap-program </tmp/my-input >/tmp/my-output
<cjwatson> you might want to double-check that, since apparmor revalidates access to open fds
<smoser> i yeah.. i hit that somewhere. it works sometimes.
<cjwatson> so it's at least potentially the sort of thing that might not work even though it feels like it should
<pstolowski> zyga: can you take a look at #5451?
<smoser> i went looking for where i found it. thought i reported it, cbut coudnt find it.
<mup> PR #5451: interfaces: honor static attributes when reloading conns <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5451>
<smoser> https://bugs.launchpad.net/snappy/+bug/1766667
<mup> Bug #1766667: commands in a container cannot write to inherited filehandles such as stdout <Snappy:New> <https://launchpad.net/bugs/1766667>
<smoser> is that in the worng place ?
<Chipaca> smoser: i'll move it to snapd, but no
<Chipaca> smoser: (snappy is the catchall for snapd + snapcraft + etc etc, in lp)
<Chipaca> I'll leave it to jdstrand to figure out if it's actually snapd or lxd-in-a-snap or what :-)
<mup> Bug #1766667 changed: commands in a container cannot write to inherited filehandles such as stdout <snapd:New> <https://launchpad.net/bugs/1766667>
<zyga> pstolowski: yes
 * Chipaca afk for a bit
<zyga> pedronis: hey, I updated https://github.com/snapcore/snapd/pull/5491
<mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
<zyga> I swiched the helpers to be functional now
<zyga> switched*
<zyga> I'm looking if we can cheaply translate differently inside and outside to get  "core" in state, "snapd" in memory and "system" in the API
<zyga> I think so, just making the changes now
<pedronis> zyga: ok, thank you
<zyga> pedronis: question on api naming:
<zyga> https://www.irccloud.com/pastebin/0wawqbLN/
<zyga> I tried to come up with useful names for the state vs api remappers
<zyga> what do you think?
<zyga> pedronis: basically I'm open to suggestions as I'm making that change anyway
<pedronis> the names seem reasonable
<zyga> great, I'll run with those, thank you
<scientes> How do I list all files in all snaps in the database?
<scientes> is there a database I can download?
<scientes> (like apt-file/apt's Contents.gz)
<noise][> scientes: there is not currently a manifest such as that
<Chipaca> scientes: what for?
<scientes> command-not-found
<ogra_> there is definitely nothing client side like Packages.gz (or the apt list files which are the local equivalents), this is all handled store side
<Chipaca> scientes: what about command-not-found?
<Chipaca> scientes: (we already have commant-not-found integration)
<scientes> when I rewrote it ( https://github.com/shawnl/command-not-found/ ), there was comments that it should support snap
<scientes> I re-wrote it to avoid the python dependency
<Chipaca> scientes: oh! hi :-)
<Chipaca> scientes: the person that did the majority of the integration with cnf is away this week
<scientes> i'll look at the source
<Chipaca> scientes: but, not command-not-found itself has grown support for being extended
<Chipaca> scientes: and snap uses that extension point
<scientes> oh i c
<Chipaca> I say "has grown", but we were instrumental to that growth
<scientes> does it increase the latency, given that it has to make a network request for every command_not_found hook?
<Chipaca> scientes: it does not have to make a network request
<Chipaca> scientes: the list of all commands _is_ available
<Chipaca> scientes: the list of all files is not
<scientes> oh i c that is better
<Chipaca> scientes: if you have snapd on your system, you can look at the database, /var/cache/snapd/commands.db
<Chipaca> scientes: snapd refreshes that periodically
<Chipaca> scientes: all command-not-found does is then call (via an extension mechanism that I don't know offhand), e.g., âsnap advise-snap --command tmnationsforeverâ
<scientes> do you know what format that is?
<Chipaca> scientes: boltdb
<Chipaca> scientes: the integration made it into 18.04, but has not been backported, fwiw
<scientes> yeah im' running 18.04
<Chipaca> cool
<scientes> looks like boltdb is deprecated
<Chipaca> so 'command_not_found_handle tmnationsforever' should show you
<Chipaca> scientes: whatever the new thing is called, it's the same
<Chipaca> scientes: bbolt
<Chipaca> scientes: before you start looking into that database, keep in mind that the cnf extension mechanism was at least in principle built to also support flatpak
<Chipaca> anyhow, back to work for me
<scientes> thanks
<mup> PR snapd#5507 opened: Changes to network-control interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/5507>
<pedronis> zyga: I will re-review on Monday morning if you push there
<zyga> yes, I will, just getting dinner now
<zyga> thank you!
<pedronis> pstolowski: I will also look at the patch PR next week
<pedronis> pstolowski: 5502 it's maybe something you could look at when you have time
 * Chipaca encourages spread to finish so he can EOW
<pstolowski> pedronis: yes i started looking at it
 * zyga is "lucky"
<zyga> every time I go out for a walk it rains
<mup> PR snapcraft#2179 closed: cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2179>
<roadmr> what's the cross-section between snapd-control interface and classic?
<roadmr> if a snap uses classic, can it do snapd-control stuff? or is snapd-control isolated even from a classic snap?
<pedronis> roadmr: if it has bits that run as root, yes
<roadmr> ohh I see pedronis
<roadmr> pedronis: and we have no way of knowing whether it does stuff as root, right?
<roadmr> pedronis: so to ask another way: if a snap asks "I need either classic or snapd-control", we would prefer to grant snapd-control as it's less powerful than classic? (but I understand it's still quite powerful and dangerous)
<pedronis> roadmr: yes, but it depends, there are factors of trust at play, also snapd-control is not useful for something like a compiler or an ide
<noise][> and snapd-control gives you those powers in fully confined (core) systems as well
<roadmr> pedronis: right, I'm thinking about the case of a snap that wants classic to be able to interact with snapd
<pedronis> yes, no classic on core
<roadmr> ahh interesting, noise][
<pedronis> roadmr: it probably should instead make a case to get snapd-control
<pedronis> talk to snapd is a case for snapd-control, not for classic
<pedronis> (taken by itself)
<roadmr> pedronis: right. OK, so that's guidance we can provide to developers in this case
<pedronis> roadmr: I mean we shouldn't give classic to something we wouldn't give snapd-control, if the situation is talk to snapd
<noise][> that said we are very reluctant to grant snapd-control for anything in the global store
<roadmr> totally
<pedronis> noise][: yes, but in general we have been reluctant with any manage the system kind of thing so far
<pedronis> in the global store
<pedronis> (afaiu)
<pedronis> I don't see classic vs snapd-control changing that equation
<roadmr> noise][: yep, I remember that... so  without guarantees that snapd-control will be granted, if someone wants classic and when asked why, says "so my snap can manage/add/remove/update snaps", we can say "the right thing to use is snapd-control" - but to reiterate, snapd-control use is evaluated on its own merits
<roadmr> terrific, well this is enough info for what I wanted to know :) thanks both
<zyga> pedronis: I got the state<=>memory<=>api mapper working, playing with more tests but it looks very good
 * zyga wraps up for the week
#snappy 2018-07-15
<eraserpencil> does anyone know if there's a gadget snap for the Nvidia TX2 available?
<mup> PR snapd#5508 opened: cmd/snap: print unset license as "unset", instead of "unknown <Created by chipaca> <https://github.com/snapcore/snapd/pull/5508>
<mup> Bug #1781789 opened: The main docs https://docs.snapcraft.io/core/ don't mention snapctl <Snappy:New> <https://launchpad.net/bugs/1781789>
<MrJones> side remark: why is the tool named snap, the page snapcraft but the package snappy? that is quite confusing
<mup> Bug #1781790 opened: snapctl start gives error message that is useless to beginners, and nothing of it is explained in --help or a man page (which doesn't seem to exist) <Snappy:New> <https://launchpad.net/bugs/1781790>
<MrJones> I want to start kubelet as packaged in snap, and tried this: snapctl start kubelet
<MrJones> this gives me the error: "error: error running snapctl: cannot start without a context"
<MrJones> I odn't know what that means, and as you can see by the ticket I just filed ( #1781790 ) neither --help nor man snapctl explain it
<mup> Bug #1781790: snapctl start gives error message that is useless to beginners, and nothing of it is explained in --help or a man page (which doesn't seem to exist) <Snappy:New> <https://launchpad.net/bugs/1781790>
<MrJones> and in the docs I can't find how to use snapctl either, just how to use the snap command
<MrJones> so how does starting a service work? what is this "context" I'm missing?
<MrJones> I'm testing this on an ubuntu 18.04 lts install
<mup> Bug #1781789 changed: The main docs https://docs.snapcraft.io/core/ don't mention snapctl <Snappy:Invalid> <https://launchpad.net/bugs/1781789>
<MrJones> are the kubelet/kubeadm snaps still maintained? because I can't get them to work
<cjwatson> MrJones: Did you try just "snap start kubelet"?  As I understand it (I work on the server side of things - not a snapd hacker myself), snapctl is meant for use by package hooks and things rather than being something users are supposed to run directly
<MrJones> cjwatson: yea, it took me a really long time to realize that xD
<MrJones> but even doing that, I got errors
<MrJones> kubeadm is confused that kubectl isn't run via systemctl and complains the kubelet port is used up
<MrJones> and when I make it ignore the error, it times out on something
<MrJones> oh and it lacks crictl which needs to be installed separately (but no apt or snap is available, so it's not that easy to do)
<MrJones> so it seems the kubelet/kubeadm snap packages simply aren't packaged in a working state right now
<mup> Bug #1781789 opened: snapctl doesn't advertise that it's an internal tool <Snappy:New> <https://launchpad.net/bugs/1781789>
<mup> PR snapcraft#2180 opened: code: use black as the standard style <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2180>
<mup> PR snapd#5465 closed: daemon, overlord/state: warnings pipeline <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5465>
<mup> PR snapd#5509 opened: daemon: move to use a constructor for Meta <Created by chipaca> <https://github.com/snapcore/snapd/pull/5509>
<mup> PR snapd#5510 opened: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5510>
#snappy 2019-07-08
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> mborzecki: good morning!
<mborzecki> mvo: some conflicts in https://github.com/snapcore/snapd/pull/7072
<mvo> mborzecki: checking
<mvo> mborzecki: aha, I see, will fix
<mborzecki> mvo: i think you had some pointers to docs about running spread tests with rspi, can you remind me where they were?
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> Hey everyone
<zyga> On Friday I managed to finish the huge test
<zyga> I will upstream it today
<zyga> I will be starting late today though as we are moving once again
<zyga> See you in two hours
<pstolowski> mornings
<mvo> mborzecki: sure, tests/external-backend.md
<mvo> zyga: good morning
<mvo> and good morning pstolowski :)
<mborzecki> mvo: got it, thanks!
<mborzecki> pstolowski: hey
<mborzecki> mvo: hm guess that brings me back to the problem i had earlier, is there a way to create a user without console-conf (no display, and no working serial) or user assertion (cannot sign one for canonical signed model)?
<mborzecki> mvo: i do use cloud-init for qemu amd64 images, but iirc pstolowski did not manage to get it to work with rspi before
<ondra> zyga https://github.com/snapcore/snapd/pull/7074
<ondra> zyga first shot, feel free to leave comment if something is missing or something to change
<zyga> ondra: thank you
<mvo> mborzecki: oh, thats a good one, I am not sure what the best option is
<mvo> mborzecki: you could simple add the user by removing the sd card?
<mvo> mborzecki: and adding it "offline" ?
<zyga> mvo, mborzecki: please have a look at https://github.com/snapcore/snapd/pull/7071 -- I will try to upstream all of the test I wrote last week today
<zyga> ondra: you need to change gpio-contorl PR a little to include a change to a spread test
<zyga> https://www.irccloud.com/pastebin/wn7CUxZQ/
<Chipaca> zyga: do you know the ouid is in an apparmor denial message?
<zyga> do you mean if I know what ouid is?
<Chipaca> zyga: yes
<zyga> object uid
<Chipaca> fsuid i presume is the uid of the filesystem thing
<Chipaca>     Log: apparmor="DENIED" operation="file_perm" profile="snap.olivia-test.olivia" name="/home/bulld/snap/olivia-test/114/.local/share/org.keshavnrj.ubuntu/Olivia/fifos/1562106609366.fifo" pid=21796 comm="socat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<Chipaca> does that ^ mean it's trying to access a fifo owned by the user, as root?
<zyga> fsuid is the ID of the user from the point of view of the filesystem AFAIK
<zyga> yeah
<zyga> I think so
<Chipaca> zyga: tks
<zyga> pstolowski, mborzecki: I need a review for https://github.com/snapcore/snapd/pull/7071
<zyga> more python test code
<pstolowski> +1
<zyga> pstolowski: thank you!
<Chipaca> omg
<Chipaca> mborzecki: "cannot install lxd snap" â¦ why would they omit the most relevant bit of info from the title?
<Chipaca> "... on WSL"
<zyga> Chipaca: don't we detect WSL?
<zyga> Chipaca: unless that is on  wsl2
<Chipaca> zyga: this guy has patched snapd and is working to get it to work on wsl2
<mvo> we do detect it, maybe somehthing changed there (os wsl2)
<zyga> Chipaca: oh, cool
<zyga> mvo: yeah, wsl2 is quite different
<zyga> mvo: I played with it  last week a little, it's interesting
<mvo> cool
<mborzecki> Chipaca: yeah, figured as much seeing the guy comment in wsl2 topics
<zyga> mvo: /init is a bind mount from a plan9 fs from windows VM  that is full of microsoft-style windows symbol names
<zyga> mvo: the boot process boots a small container manager on linux, then ubuntu is a container there
<zyga> anyone https://github.com/snapcore/snapd/pull/7071 (2nd review only, python test code)
<zyga> mborzecki: thank you!
<zyga> mborzecki, pstolowski: small tweak on top of the renumbering patch
<zyga> https://github.com/snapcore/snapd/pull/7078
<mborzecki> mvo: opened a RFC with snap-image https://github.com/snapcore/snapd/pull/7079
<mborzecki> mvo: those are cherry-pickings from a work in progress branch, hopefully the spread test works too
<pedronis> mborzecki: we'll need to iterate on the commands and name of that tool, I read the forum topic and I'm not sold on the current ones
<mborzecki> pedronis: sure, as you probably noticed already i'm terrible at naming things :)
<mvo> zyga: nice!
<mvo> mborzecki: thanks, will have a look (was in a meeting)
<zyga> wow, it is raining
<zyga> this soil badly needs water
<zyga> I'm  inclined to take a break and just enjoy the rain for a sec
<Eighth_Doctor> mborzecki: will this help with making fedora snappy core systems? :)
<zyga> Eighth_Doctor: hey :)
<mborzecki> Eighth_Doctor: well, you don't need ubuntu-image to build an image anymore
<zyga> Eighth_Doctor: what  willhelp?
<zyga> ah,ubuntu-image
<Eighth_Doctor> well, I saw `snap image`, and I thought, well maybe that might help
<Eighth_Doctor> since the whole thing is kinda undefined at the moment
<zyga> Eighth_Doctor: but fedora  based core  systems are still a bit away for multiple reasons
<Eighth_Doctor> aww
<zyga> Eighth_Doctor: mborzecki's work is making the image building much more solid and well tested/defined
<zyga> and something snapd can be a part of for core20
<mborzecki> zyga: hm that could actually be an interesting experiment just to check how far one could go
<zyga> mborzecki: yeah but ENOTIME
<zyga> mborzecki: but yeah
<zyga> speaking of time
<zyga> it's time to look at https://github.com/snapcore/snapd/pull/7080
<zyga> and at  https://github.com/snapcore/snapd/pull/7078
<zyga> after those two I only have one python change left
<zyga> changing renaming order
<ogra> Chipaca, I fixed the (WSL) topic for you ;)
 * zyga wraps up for late breakfast and walk
<mborzecki> hm no way to tell if spread test exited early/was skipped due to some extra checks :/
<zyga> mborzecki: nope, no SKIP
<mborzecki> i think we discused that but there was no outcome
<mborzecki> cannot snap ack test keys on rpi, error: cannot assert: assert failed: cannot find account (testrootorg)
<zyga> need to tweak renumbering some more, tmpfs size depends on instance memory and it seems we get one of two sizes
<zyga> oh well
<zyga> after  lunch
<mborzecki> aand cannot use a fakestore with external backend :/
<zyga> bbl
<popey> kyrofa: is nextcloud-client one of yours? It's private. Does it need work, or handing over to someone active?
<zyga> re
<zyga> - Download snap "go-example-webserver" (25) from channel "stable" (received an unexpected http response code (503) when trying to download https://canonical-lgw01.cdn.snapcraft.io/download-origin/canonical-lgw01/AXQwkeqxpsWVOF2kUsgT6zJKVW8H9NIm_25.snap?token=1562594400_3c2fed171bc8c205f871d84b418ef6de7625d0f8)
<zyga> some CDN woes
<zyga> maybe store woes? https://www.irccloud.com/pastebin/qmzSIDds/
<zyga> I restarted three runs
<mvo> zyga: might be worth checking with the store people
<zyga> I checked status.snapcraft.io, all green there
<zyga> if this  happens again I'll ping store
<mvo> cmatsuoka: hey, good news. I managed to boot a luks enabled uc20 now (with your prs). could you please check https://github.com/snapcore/snapd/pull/7077  ? I made some small tweaks
<mvo> cmatsuoka: once that is merged into uc20 the spike-tools from github.com/snapcore/spike-tools should be able to do the full image build, i.e. this should then work end-to-end (when building on bionic)
<zyga> mvo: what do you think we should do with  https://github.com/snapcore/snapd/pull/7062
<zyga> mvo: 1) scope it to 16.04 so that it passes, close the PR?
<cmatsuoka> mvo: awesome! I have some clean-ups in my todo list, mostly debug code related to certain actions requiring a small delay -- did you experience any non-deterministic behavior during your tests?
<mvo> zyga: let me look
<mvo> cmatsuoka: I added one more sleep before the filesystem creation
<mvo> cmatsuoka: and some error checking
<ogra> ogra@pi4:~$ snap debug confinement
<ogra> strict
<ogra> ogra@pi4:~$ uname -a
<ogra> Linux pi4 5.1.16+ #1 SMP Mon Jul 8 10:31:01 UTC 2019 armv7l armv7l armv7l GNU/Linux
<ogra> \o/
<zyga> ondra: can we get 5.2?  :D
<zyga> ogra: ^
<zyga> sorry :)
<ogra> haha ... i know ondra likes to be me :)
<zyga> 5.2 has the new mount APIs
<cmatsuoka> mvo: yeah, I just saw the extra delay -- I'll try arighi's kernel to see if it behaves better regarding potential races
<ogra> zyga, i'll take a look ... thats all very early anway ... we have no u-boot for the pi4 yet ... but i want to get at least a hacked up classic image to work with this kernel and the upstream bootlaoder setup (no initrd)
<zyga> ogra: classic is fine :)
<ondra> zyga you can just use ondra, ogra has highlight on my nick anyway :P
<ogra> well, its "hacked classic"
<zyga> hahaha
<ogra> (i.e. just a debootstrapped rootfs plus kernel and upstream bootloader)
<cmatsuoka> mvo: there was a place where I manually added a bunch of modprobes to make cryptsetup work, now I think I was actually adding minute delays and we may have hit another race there
<mvo> cmatsuoka: I see minute waits when booting
<mvo> cmatsuoka: should I look into initramfs to see these sleeps?
<cmatsuoka> mvo: I'm removing the lines that shouldn't be there and running some tests
<cmatsuoka> If these are really required I'll test them again with the new kernel
<mvo> ta
<zyga> Chipaca: hey
<zyga> Chipaca: do you need that WSL2 data?
<zyga> Catalog update is doing verbose http logging (it should not).
<zyga> hmm
<zyga> I'm not lucky with PRs today
<Chipaca> zyga: I'd like it, but it's not essential, why?
<zyga> Chipaca: I can try to unpack that laptop after lunch and give you the answer
<Chipaca> zyga: no rush
<zyga> Chipaca: alternatively I can easily give you the answer in the evening
<zyga> Chipaca: after we check in
<Chipaca> zyga: basically i want to know if the default WSL2 kernel still has Microsoft in /proc/version
<Chipaca> zyga: the person in the forum is running their own kernel so anything goes in there :-/
<zyga> aha
<zyga> there are ways to detect wsl 2
<zyga> simple one: /init is a p9 mount
<Chipaca> but as this is meant as a "yeah this won't work" aid to users, I'm not worried if they circumvent our checks and then things break
<Chipaca> "when I try to change channels it doesn't work and my eyes hurt!" "hitting yourself with the remote is a bad way to change channels, don't do that" "i removed my eyes, trying to change channels no longer hurts, but it still doesn't work!"
<Chipaca> *sigh*
<zyga> hehe
<zyga> in that case
<zyga> I'm off for lunch
<zyga> if anyone wants to look: two simple python PRs are pending
<pedronis> at least 3 of PRs need a review or 2/3 review: 7006, 7020, 7066
<pstolowski> looking at 7006
<pstolowski> *7066
<pstolowski> grr, 7006
<ijohnson> morning folks
<pedronis> Chipaca: 6977 is probably something you should review (it relates to the refactor)
<zyga> Hey ijohnson
<ijohnson> hey zyga
<zyga> mvo:I will not be able to make it
<zyga> Mvo sorry, still finishing lunch
<cmatsuoka> uh, it was just me or  something strange just happened in the video call?
<jdstrand> Chipaca: ouid is the 'object id' of the thing being referenced in the permission check. so in that case, the fifo (the object) is owned by root and being accessed by non-root (the fsuid)
<jdstrand> zyga: hey, why do we have a meeting on pr 7058?
<jdstrand> mvo: ^ (hi btw)
<mvo> jdstrand: in a meeting right now, I will get back to you in 5min or so
<ogra> ouid ? are you sure thats not a french daemon saying yes all the time ?
<mvo> jdstrand: I think the idea about hte meeting was to see what (if anything) would break if we enable apparmor on upstream kernels and also what security features will be missing
<mvo> jdstrand: it will hopefully be a short meeting :)
<jdstrand> mvo: I thought we had that meeting in Lyon :) we don't really know what will break because we haven't run it in strict mode on those distros
<jdstrand> well, we'll see. it might sound like I'm rehashing an old argument, but I promise I won't be. I'll just be honest in the assessment
<pedronis> jdstrand: we are having a meeting because I was told you were +1 on this change now
<pedronis> and wanted to understand the new reasoning
<jdstrand> pedronis: it is because in Lyon, where I said that if we were going to make the change, I wanted to be sure everyone understood the cost (maintenance, regression, reputation). people said they understood the cost and wanted to do it
<pedronis> jdstrand: I didn't
<jdstrand> hmm, you were in the room. ok, does sound like a meeting is warranted
<pedronis> yes, that's why we have one, lots of mixed messages
<zyga> jdstrand: yes
 * zyga misread  the question, reading backlog
<zyga> ok, see you all in a minute
<mborzecki> pedronis_: updated the big one https://github.com/snapcore/snapd/pull/6890
<pedronis> mborzecki: thx, I'll try to go back to those PRs tomorrow
<mborzecki> pedronis: great, thank you!
<ijohnson> pedronis, mvo: the bug about seeding a classic image I talked about is here: https://bugs.launchpad.net/snapd/+bug/1835795
<jdstrand> ackk: re those bugs you asked about, they will be fixed in the upcoming 2.40 release
<ackk> jdstrand, thanks, awesome!
<jdstrand> ackk: and sorry for the delay, I was on holiday
<ackk> jdstrand, np, I figured :)
<mvo> I see a lot of red tests, did anyone investigate?
<zyga> rre
<ondra> zyga I fixed test, still running slow ones, but it's looking way better now
<zyga> thanks!
<zyga> - Download snap "ubuntu-core" (1797) from channel "stable" (received an unexpected http response code (503) when trying to download https://canonical-lgw01.cdn.snapcraft.io/download-origin/canonical-lgw01/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap?token=1562601600_d9a2f9b4f5f2050b5dfa14ea244831be9b8bfd51)
<zyga> noise][: ^ https://status.snapcraft.io says it's all good but I've seen a few of those today
<zyga> this was strictly after 2019-07-08 12:58:56
<zyga> (not sure which TZ is  that, reported by travis)
<diddledan> something appears to have changed, and I can't figure out what - the extra menu items for gnome-twitch aren't visible any more: https://usercontent.irccloud-cdn.com/file/1vAA2qxd/image.png
<zyga> diddledan: when did it change?
<diddledan> I can't figure out what I've changed
<diddledan> no idea
<zyga> ijohnson: do you have time for 5 minute reviews today?
<diddledan> I've tried rebuilding an ancient copy that I'm ssure was working in the past and it is also showing the empty menu
<noise][> zyga: thx, we'll take a look
<zyga> noise][: thank you
<ijohnson> zyga: sure I can look at some small stuff in my afternoon
<diddledan> it's interesting that there's a gap where the items should be, but it's only the size of one extra item when I think there should be more than one item in there
<zyga> ijohnson: two simple PRs (with that label) from me
<zyga> ijohnson: if you can it would help me move forwarrd
<ijohnson> zyga: 7080 and 7078?
<zyga> ijohnson: yes
<ijohnson> cool I'll take a look in a bit
<mvo> sergiusens: silly question, does snapcraft 2.43 not include the pyc files? is that fixed in later snapcraft version? we got a bugreport in the forum that indicates this is the case(?)
 * zyga takes a break until next call
 * ijohnson lunches
<diddledan> I should do that. a few hours late at 17:10.... oops
<diddledan> who needs food?!
<mvo> sergiusens: hm, I just tried snapcraft 3.6 and in this snap (https://github.com/phocean/volatility-snap) there is no pyc files, is that expected (cc cjp256)
<mvo> ?
<mvo> (this is a python2.7 snap fwiw)
<cjp256> sergiusens is on holiday today, i'll take a look
<cjp256> in old versions of snapcraft, did it snap up the pyc files?
<mvo> cjp256: no, no pyc files in both new and old
<mvo> cjp256: I can (probably) workaround this by adding "python -m compileall ." during the build, I'm trying this now. but my understand was that snapcraft would do that (or something similar) for me automtically(?)
<cjp256> ok, i haven't had a reason to look at how the python plugin works yet, but this is as good a reason as any :) i'll get back to you
<mvo> cjp256: thanks, no rush, I will add my findings in the forum, its almost EOD here anyway :)
<zyga> today is a day lost for travis
<cjp256> mvo: fwiw, snapcraft itself compiles pyc files in override-prime: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml#L100
<mvo> cjp256: interessting, for some reason that seems to have not worked when I build this example snap, maybe I did something wrong
<mvo> cjp256: I can try a fresh build on a different machine tomorrow but for me the pyc files are currently missing
<cjp256> did you add anything to the snapcraft yaml?
<cjp256> the compileall?
<cjp256> i should perhaps clarify: it appears that snapcraft's snapcraft.yaml explicitly does compileall in its override-prime in order to ship pyc files
<mvo> zyga: do you know from the top of your head if/how I can disable seccomp in devmode (i.e. I don't even want complain mode, just nothing if possible)
<mvo> cjp256: I ran the compileall in the prime dir and used that, its a bit of a tangent for my real investigation, I just happend to notice the pyc files are missing
<cjp256> when using pip, it's directed to --no-compile (https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/_python/_pip.py#L352) and appears filtered from snap_fileset  (https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L440) - but that's just a cursory glance and I haven't traced what's happening in this case yet.
<mvo> cjp256: the snap is using the "python" plugin: https://github.com/phocean/volatility-snap/blob/master/snap/snapcraft.yaml
<zyga> mvo: no, devmode does not disable seccomp
<zyga> mvo: you must use classic for that
<mvo> zyga: yeah, just @complain - I switched to @unrestricted now
<mvo> zyga: for testing
<zyga> yeah that will work
<mvo> zyga: context is the "Concerns about performance" forum post
<zyga> aha
<zyga> good thinking
<mvo> zyga: updated the post with some more numbers, need to have dinner now
<zyga> mvo: danke
<plars> ogra: hi, I'm trying to limit ram for some testing on core with rpi using mem= set in the cmdline.txt, but so far it only gets as far as "Starting kernel..." and stops. Is this not possible on pi for some reason you can think of? I've tried 512M and 768M so far
<ogra> hmm, it shouldnt block your boot, are you sure you dont have any syntax errors or some such ?
<plars> ogra: all I did was add " mem=512M" to cmdline.txt
<plars> if I take it out, it boots fine
<ogra> weird ... probably related to the pi bootloader though
<ogra> since it inits the GPU (and such the videoram) before powering up the arm SoC
<ogra> perhaps try setting gpu_mem=16 (default is 64) in your config.txt
<ogra> there is also disable_l2cache=1 you could try so the kernel doesnt use L2 from the CPU (but not sure if the kernel can cope without nay L2 at all)
<ogra> s/CPU/GPU/
<plars> ogra: hmm, not helping so far
<plars> ogra: ah, ok I may have found a workaround by setting total_mem in config.txt instead of mem= in cmdline.txt
<plars> ogra: thanks for the ideas!
<cmatsuoka> what's the best way to build a kernel snap from kernel debs?
<ogra> plars, awesome ... good to know (i didnt kow about that option)
<ogra> *know
#snappy 2019-07-09
<scoopex> the rocketchat snap package is missing two rules (https://github.com/RocketChat/Rocket.Chat/issues/14562). how can i add them?
<scoopex> sorry, i mean apparmor rules
<jamesh> scoopex: rebuilding the snap with the network-observe plug would probably do the trick.
<jamesh> that exposes a lot more though.
<mborzecki> morning
<zyga> Hello
<mborzecki> zyga: hey
<zyga> How are you?
<zyga> We had first rain in weeks
<zyga> It is still raining now
<zyga> Hey mvo
<mvo> hey zyga
<mborzecki> mvo: hey
<mvo> hey mborzecki ! thanks for your decompile of the bpf in the performance thread
<mborzecki> mvo: sure, do you have the link to the image you used with volatility?
<mborzecki> mvo: i'm inclined to try rebuilding a couple of versions of libseccomp, check the bpf they generate and how it impacts the performance
<mvo> mborzecki: i used http://amnesia.gtisc.gatech.edu/~moyix/ds_fuzz_hidden_proc.img.bz2
<mvo> mborzecki: it was more or less a random choice in their example image section
<mvo> (its one of the smaller ones though)
<mborzecki> mvo: hah, i could probably write a small benchmark but we could equally well use volatility :)
<mvo> mborzecki: yeah, volatility is nice as it exhibits the issue easily
<zyga> Wimpress: hello
<zyga> Wimpress: please ping me when you are working, we need to sync
<zyga> https://github.com/snapcore/snapd/pull/7062 is green and needs a 2nd review (re-enabling test)
 * zyga is a little sleepy after uberlong day
<zyga> on the upside the new bed is ok
<zyga> pstolowski|afk: neat stuff
<pstolowski> mornings, hey zyga
<zyga> hey :)
<zyga> good morning
<zyga> pstolowski: it was raining all night
<zyga> every bit of soil and plant around here needed that
<pstolowski> zyga: it has been rainy and cloudy here as well for over a week.. and it's actually a little chilly
<zyga> pstolowski: I kind of miss that now
<zyga> brb
<zyga> coffee and back to work soon
<zyga> pstolowski: I'll reivew your PR first
<pstolowski> ty
<zyga> pstolowski: thanks!
<zyga> coffee-in-hand, review mode :-)
<pstolowski> yw
<pedronis> jamesh: hi,  could you work to try to land 6959 ?
<mborzecki> pstolowski: little chilly, 16C right now here :/
<zyga> mborzecki: wow
<zyga> pstolowski: can you help me understand the code in the PR please
<zyga> pstolowski: what sets skip-setup-profiles?, I cannot see it
<zyga> EDIT: d'oh
<zyga> sorry, typo in search
<zyga> I should finish that coffee, I see it now
<pedronis> pstolowski: I moved some cards related to the interface connection work, doesn't seem you have a card in doing about it though
<pstolowski> zyga: good
<pstolowski> pedronis: indeed, thanks
<zyga> pstolowski: I'd like to run a scenario by you,
<zyga> pstolowski: (still assembling the scenario, I'll get back to you)
<mborzecki> mvo: i'm experimenting a bit with versions of libseccomp, so the impact is marginal
<mborzecki> mvo: i've checked 2.4.1, 2.3.3, latest master and the binary tree branch
<mvo> mborzecki: I wonder if we could do a lookup table or if bpf is too limited
<mborzecki> mvo: with ebpf yes, cbpf is limited
<mborzecki> mvo: sadly seccomp is cbpf
<mborzecki> mvo: if you're interested, this is the profile with 2.4.1 https://paste.ubuntu.com/p/wRTDmq39Sw/ and this one is with binary tree patches https://paste.ubuntu.com/p/Q9VYyhchRR/
<Wimpress> zyga: Morning
<zyga> Wimpress: hello
<pstolowski> pedronis: i'm removing ...== "snapd" checks; wondering what to do about client-side filtering and special-casing around connections/interfaces
<pedronis> pstolowski: we are mostly interested about places that were using .Type for anything else
<pedronis> pstolowski: client side, not sure, we had a lot of back and forth there
<pedronis> pstolowski: what's the special casing around connections/interfaces ?
<pstolowski> pedronis: it's mostly about system nickname afaiu
<pedronis> pstolowski: that goes through the mapper, no?
<pedronis> the mapper decision could use the type now
<pstolowski> pedronis: maybe, but that may not solve everything, e.g. cmd_connections uses different format for system snaps, i.e. it omits snap name for system snaps, and uses just the name match
<pedronis> pstolowski: if we do things correctly, selectInterfaceMapper  can use the type
<pedronis> pstolowski: maybe I wasn't clear,  the issue is not that we compare with the name in general
<pedronis> the issue is places that were checking the type of snapInfo for most things
<pedronis> but the  name for snapd
<pedronis> but I'm probably still confused what the problem is
<pedronis> pstolowski: are you talking about places that use SystemSnapName ?
<pstolowski> pedronis: isn't the goal to support snapd snap whatever its name might be in the future?
<pedronis> pstolowski: not really
<pedronis> never said that
<zyga> NOTE: the client side checks were there because some parts of the API did not return enough information AFAIK
<pedronis> pstolowski: the goal is to make decision sensitive based on the type
<pstolowski> pedronis: allright. wrong assumption on my side then. there is no issue then.
<mborzecki> mvo: added a note about compiled bpf with 2.4.1 and the binary tree branch: https://forum.snapcraft.io/t/concerns-about-performance/12194/8
<pedronis> pstolowski: you are talking about isSystemSnap in cmd_connections ?
<pstolowski> pedronis: yes. and there is some special-casing in cmd_interfaces as well. although they're both irrelevant in the light of what you just clarified
<pedronis> we might want to do something about that, but is not a priority
<Chipaca> pedronis: what should I do wrt the code for snaps with no health?
<Chipaca> in info
<Chipaca> pedronis: I don't have a strong opinion on this :)
<Chipaca> having a code seems more uniform, but this being snap and not snapd it's purely cosmetic
 * Chipaca proposes snapd-health-is-a-state-of-complete-physical-mental-and-social-well-being-and-not-merely-the-absence-of-disease-or-infirmity
<mvo> mborzecki: thank you
<pedronis> Chipaca: no code please, it's the unknown unknown case
<pedronis> Chipaca: also, code are optional, we should embrace that, not give the impression they aren't
<pedronis> Chipaca: if you think the code really adds value, then we should always set in the api, and not leave the field empty
<pedronis> there
<pedronis> but I don't think it's worth it/makes a lot of sense
<Chipaca> agreed then, no code in this case
<Chipaca> break time!
 * Chipaca dances
<Chipaca> https://www.youtube.com/watch?v=otCpCn0l4Wo obvs
 * zyga -> breakfast
<zyga> back
<zyga> pstolowski: I sent a partial review earlier; I cannot poke any holes in it
<pstolowski> zyga: ty, i saw you comment. i think it's no different (in terms of risk) to anything else we do; fwtw if we made any error in that logic, we would end up with less persmissions, not more (initial setup-profiles is always done before auto-connect and link-snap). we just need to be careful as always
<mborzecki> pstolowski: left some comments under https://github.com/snapcore/snapd/pull/7081
<pstolowski> thanks
<zyga> Walk
<zyga> re
<zyga> oho
<zyga> splits
<zyga> mborzecki: one last python patch https://github.com/snapcore/snapd/pull/7082
 * zyga switches to reviews
<jdstrand> mborzecki: r cbpf> for some definition of sadly, ebpf would give us a lot of grief due to spectre (and its mitigations)
<jdstrand> (cc mvo) ^
<mborzecki> jdstrand: as in https://seclists.org/oss-sec/2019/q1/106 ?
<jdstrand> mborzecki: if we're looking to ease the pain of the lookup, trying to push oracle's patch forward is likely the way forward. we could do experimental builds and determine if it is good enough, then vendor libseccomp with that patch if it seemed ok
<jdstrand> mborzecki: yes. some are disabling ebpf entirely. everyone else says only root can use it (if not running under seccomp already iirc)
<jdstrand> mborzecki: I see you post that bintree didn't help. we could try to tweak libseccomp to put common syscalls like openat sooner.
<jdstrand> mborzecki: and then send that upstream
<mborzecki> jdstrand: yeah, the cost seems to be better on average, but lower number syscall seem to fare worse
<jdstrand> and vendor it in the meantime. before vendoring or sending upstream, we'd need to run through the tests I wrote for the daemon user though...
<jdstrand> mborzecki: I suspect if you posted your findings to the bintree one, people would try to come up with a compromise approach
<mborzecki> jdstrand: actually that is interesting whether we should aim for all syscalls be similarly impacted by seccomp filter, rather than favoring some and penalizing others
<jdstrand> mborzecki: since the goal is spead up when it actually slowed down
<mborzecki> jdstrand: right, but if you do say, recvmsg/sendmsg a lot you'd see gains :)
<jdstrand> mborzecki: well, seccomp is always going to have a measurable impact ime. what we can do to soften that... it seems plausible to put massively used ones earlier (like recvmsg/sendmsg). one would think that openat would be at the end though-- read/write/lseek at the beginning since you tend do that more than opens.
<jdstrand> mborzecki: which means that we're always going to be slow in some pathological cases
<jdstrand> mborzecki: if you are right about python compiling modules, shouldn't it be shipping pyc files?
<jdstrand> mborzecki: the fact that we do a lookup at all, for volatility, it seems difficult to imagine doing better than bintree. I mean, read is very high in the list with only 6 syscalls before it, and lseek only 14. they are highly prioritized already
<zyga> jdstrand: we can  LD_PRELOAD and translate all the syscalls  to open + mmap + caching  (don't close and reopen)
<zyga> jdstrand: we can  perhaps do some tricks with multiple profiles, hand written,  that use bitmasks to quickly ACK numbers that are high up the call  frequency and then offset the cost for the NACK syscalls, maybe some sort of bloom filter approach crafted out of multiple filters that are all attached together
<mborzecki> jdstrand: sorry for delayed replies, we're in the standup currently
<mborzecki> jdstrand: mvo posted some info about -m compileall, but I did not apply it locall
<jdstrand> mborzecki: it is unclear to me the frequency of the syscalls for volatility. the table tells my with <2.4, read has 0 syscalls before RET and with 2.4, 6, but how often is read called? (we know read will be high, but perhaps there is some frequently used syscall that could reasonably moved up the list)
<jdstrand> mborzecki: mvo mentioned lseek and mmap...
<mborzecki> jdstrand: let me grab a summary from strace
<mborzecki> jdstrand: http://paste.ubuntu.com/p/F8PSHcscDg/
<jdstrand> zyga: I'm not clear on your LD_PRELOAD proposal. you are saying you want to modify program behavior to sidestep the issue?
<mborzecki> jdstrand: so read, lseek, mmap, munmap, fstat should already be handled rather early
<mborzecki> jdstrand: openat is probably an artifact of snap-confine and perhaps python module compilation (?)
<jdstrand> mborzecki: how easy it for you to put lseek first in the list with 2.4 and rerun?
<mvo> mborzecki: just to double check - you also see the problem go away once you add @unrestricted into the .src file and compile that, right?
<mborzecki> mvo: yes, @unrestricted is ~14s vs 20 with seccomp set up
<mborzecki> jdstrand: where's the list?
<jdstrand> mvo: it's always been known there is overhead with syscall filtering. a map would sure be nice here... lseek is already prioritized and towards the top of the list. we knew pathological cases would be problematic (eg, opening lots of files over and over, etc)
<jdstrand> mborzecki: well, yes, then I guess that is already putting it towards 'not easy' (I don't know otoh)
<jdstrand> mvo: but volatility is executing lseek nearly a million times...
<mvo> jdstrand: yeah, I think this forum post hit exactly this pathological case
<mborzecki> jdstrand: i'll look into how libseccomp generates bpf, i see there's some syscall sorting happening early on so that's probably the right spot :)
<mvo> jdstrand: its fine, if we can't do anything we can't do anything :) I was mostly trying to understand the details
<jdstrand> mborzecki: it looks like there is a priority field looking at gen_bpf.h
<jdstrand> err gen_bpf.c
<jdstrand> mborzecki: iirc, upstream said there was more that could be done in this area, separate from bintree
<zyga> I think that given the number of system calls it is silly a seccomp program cannot have a small array that has âyes, no, computeâ action. Vast majority of times a simple lookup is sufficient
<zyga> Maybe we need to invest in a kernel patch
<mvo> zyga: I was wondering the same - it seems the bpf machine is very limited here (maciej mentioned this earlier here)
<jdstrand> mborzecki: db.c talks about the priority field, and talks about 'user hints'
<jdstrand> mborzecki: which is... interesting...
<zyga> Ebpf seems to have everything we want though. Maps arrays jumps. It is just out of reach :-(
<zyga> But even regular bot we could use some tricks with bit mask
<zyga> a/bot/bpf
<mvo> yeah, was wondering that too
<jdstrand> zyga: once we have the daemon user tests in place, perhaps we could consider using ebpf on systems that have it available. I mean, snap-confine is running as root. it will have CAP_SYS_ADMIN for using bpf()...
<jdstrand> zyga: it wouldn't be something we would want to rush and we'd have to really justify it in my mind, cause the entire industry is using libseccomp. if we go out on our own and get it wrong, that would be, let's shall we say, less than ideal
<jdstrand> (cc mvo) ^
<mborzecki> jdstrand: hm seccomp_syscall_priority()
<zyga> jdstrand: but seccomp does not do eBPF, or does it?
<mborzecki> jdstrand: let's see if i can tweak the code to call it and make it prioritize lseek
<jdstrand> I'd much prefer to see mborzecki's findings as feedback in the bintree pr
<jdstrand> zyga: no, it would need to be a new LSM
<jdstrand> zyga: there are some patches for seccomp to use ebpf. that would definitely need to be evaluated :)
<zyga> Understood
<jdstrand> anyway, I suspect bintree is going to help lift everything, even if some pathological cases remain
<jdstrand> mborzecki: yes, look at that, a C api and everything. huh. so, assuming that can make things better, it is theoretically possible for snapd to expose some knobs to tune the filter
<jdstrand> mborzecki: eg, seccomp_syscall_priority(ctx, SCMP_SYS(lseek), 220); seccomp_syscall_priority(ctx, SCMP_SYS(read), 219);
<jdstrand> mborzecki: with knobs, we could perhaps make pathological cases not so bad...
 * jdstrand is a little concerned what that might do to the added tests for snap_daemon since that whole thing was so brittle prior to 2.4 (and its defaults)
<jdstrand> mborzecki: I of course made up 220 and 219. I don't know what the current prio is for either. maybe for your 'quick' test, 255 and 254 is best since volatility is dominated by those two
<mborzecki> jdstrand: heh, https://paste.ubuntu.com/p/CPZ6cGkt8q/ shaved off ~1s
<mborzecki> jdstrand: fwiw scmp_bpf_sim tells me it's fewer instructions now for those syscalls
<jdstrand> mborzecki: hmm, only one second. that suggests the act of filtering at all causes a fairly significant slowdown (at least when calling a function a million times), with the ordering being an additional factor
<mborzecki> jdstrand: fwiw i could possibly come up with a trace to measure how much it takes
<mborzecki> jdstrand: had to fix the unrestricted time in the forum note, idk why i had 14s instead of 18s
<mborzecki> jdstrand: so fiddling with bintree branch or the regular branch, we can gain a bit, but not much tbh
<jdstrand> mborzecki: it might be interestinng for completeness since we were talking about sort order so much and that a map would help (which these finding suggest perhaps not)
<jdstrand> mborzecki: re gain> right
<mborzecki> jdstrand: a map of what? or an eBPF map?
<mborzecki> jdstrand: fwiw http://paste.ubuntu.com/p/DHV5tfChq6/ disassembly output with prioritized syscalls
<zyga> that has to be optimizable
<jdstrand> mborzecki: I was saying that your run might suggest that the filtering code in the kernel is what is slow. if lseek is at the top of the list then sort order is essentially taken out of the equation for that syscall. so a(n ebpf) map isn't going to help that
<jdstrand> mborzecki: perhaps the kernel could be improved to do caching of a previous lookup... that is likely memory intensive though
<jdstrand> mborzecki: however, your 18s:20.5s vs 14s:20.5 is a big deal. I think we can live with that overhead for the foreseaable future. we can pull back bintree in the fullness of time and lift everyone a bit. with higher priority items out of the way, we could consider adding seccomp_syscall_priority() to the mix
<mborzecki> jdstrand: w8, that's 18s with @unrestricted, vs 20.<closer to 0> with bintree or priorized vs 20.<closer to 1> with 2.4.1
<jdstrand> mborzecki: even better
<jdstrand> mborzecki: point is, the delta between unrestricted and restricted is not great
<mborzecki> jdstrand: right, the penalty is there and it's measurable
<jdstrand> it is there, it is measurable. we knew that (we just didn't measure it). my point is that a 10% slowdown for a pathological case is not terrible
<mborzecki> jdstrand: also, we probably need a better benchmark
<jdstrand> and that perhaps in the future, we can get that to 5% with seccomp_syscall_priority() if that bubbles up to a roadmap item
<jdstrand> mborzecki: re benchmark> absolutely
<zyga> mborzecki: some of the rain got here :)
<zyga> even storm
<zyga> finally colder though
<zyga> lots of thunder and rain here, if I don't respond it may that my network got knocked outu
<zyga> *out
<jdstrand> mborzecki: fyi, I see you are responding-- I just responded again with my thoughts (perhaps you want to consider/agree/refute them in your response)
<pedronis> mborzecki: did another pass on 6890, still not super clear why the calls to checkpointPrefix and rollbackPrefix are not more symmetric
<mborzecki> pedronis: hm must have missed that in your previous review, will take a look
<mborzecki> jdstrand: left a note with results from more runs, so only conclusions at this point are: @unrestricted has no overhead and we need a better benchmark
<jdstrand> mborzecki: thanks! those are concrete conclusions. I think an important additional conclusion is that sort order isn't everything and there is overhead in mediating it at all. that is useful and can guide us going forward
<jdstrand> mborzecki: I also think that there is reasonable hope that bintree will help non-pathological cases, but that needs measuring
<jdstrand> mborzecki: it is interesting that bintree/prioritized is slower with the averages than straight 2.4.1
 * jdstrand updates his math
<jdstrand> mborzecki: I wonder if it makes sense for when bintree is available, to make it chooseable. ie, add an api call to opt into/out of bintree... it seems that the upstream patch doesn't make this tunable. it only looks at MIN_SYSCALLS_TO_USE_BINTREE
<jdstrand> mborzecki: fyi, our default template uses 368 syscalls today
<pstolowski> degville: hey, thanks for debug timings doc tweaks! one typo there: "snapd stores up to 100 measurements with the oldest dropped to for new measurements"; did you mean "to make room for.." ?
<degville> pstolowski: no problem, and yes, you're right.
 * zyga food
<pstolowski> mvo: btw, #7016 needs 2nd review
<mvo> pstolowski: yes, will do
<pstolowski> mvo: thanks
<cmatsuoka> mvo: oh well it seems that govendor doesn't like pull requests
<cmatsuoka> has anyone used govendor with an unmerged PR?
<zyga> cmatsuoka: what do you mean?
<cmatsuoka> zyga: I have code that depends on a go-tpm PR
<zyga> you have to update govendor's  json thing
<zyga> we rarely do that though
<zyga> you may also need to check if debian has that as a package
<zyga> or otherwise part of CI will fail
<zyga> similar thing for fedora (sorry)
<cmatsuoka> zyga: you mean, by hand? because the govendor utility ignores the package
<zyga> no, not by hand
<zyga> I forgot how to useit
<zyga> AFAIK you need to "go get" it
<zyga> and tell govendor to add it
<zyga> which will update the json
<zyga> look at the history for vendor.json, maybe there are some clues
<zyga> I honestly don't remember how to use it
<cmatsuoka> if you govendor add the package (that's already positioned at the right branch) it's ignored, govendor doesn't add it
<cmatsuoka> but if it's a "normal" package it works
<cmatsuoka> aha, I can tell govendor to use the downstream tree with the upstream name
<cmatsuoka> ok, that will solve the problem (hopefully)
<cmatsuoka> yay, it worked!
<cmatsuoka> thanks zyga for making me read the FAQ again :D
#snappy 2019-07-10
<mborzecki> morning
<zyga> Hi
<mborzecki> zyga: hey
<mborzecki> rebooting, brb
<mborzecki> re
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6939 ? got +1 from pedronis, needs a 2nd review
<pstolowski> k
<mborzecki> pstolowski: thanks!
<zyga> Hey Pawel
 * zyga goes for breakfast
<zyga> re
<Chipaca> zyga: in NewAtomicFile there isn't a 'no chmmod' because there is no chmmod, there is a mode for the mode to create the file with
<Chipaca> which is the 0644 in the code you commented on
<mborzecki> hm foobar seems to be getting some attention in the forums
<Chipaca> mborzecki: you mean two posts by the same person? :-)
<mborzecki> Chipaca: yeah :/
<mborzecki> Chipaca: 2 posts and i still don't know what the actual problem is
<Chipaca> mborzecki: in the first one, the fonts are too small (not picking up hidpi)
<Chipaca> mborzecki: in the second one, it's the WRONG VERSION
<Chipaca> mborzecki: completely UNUSABLE what is even the POINT
<mborzecki> Chipaca: basically like any other windows app running under wine
<Chipaca> mborzecki: is that what it is?
<mborzecki> Chipaca: foobar2000? it's a windows app
<Chipaca> Â¯\_(ã)_/Â¯  ok :-)
<Chipaca> step 1. get a proper music player
<Chipaca> step 2. quit yer complainin'
<mborzecki> Chipaca: foobar2000 is an opinionated music player ;) superior sound quality on them crapphy on-board DACs
 * Chipaca hugs his onboard DACs to his chest and screams like a banshee
<Chipaca> mborzecki: do you recognise the distro / wm they're using?
<mborzecki> Chipaca: is that mint?
<Chipaca> je ne sais pas
<Chipaca> (je ne sais rien, aussi)
 * Chipaca runs out of french
<mborzecki> Chipaca: the icon looks similar https://linuxmint.com/
<Chipaca> mborzecki: indeed
<Chipaca> mborzecki: if you had told me it was limewire I would've believed you also
<mborzecki> Chipaca: looks like crap on 4k https://i.imgur.com/JM5gapb.png
<Chipaca> mborzecki: and clementine?
<Chipaca> I'll be getting 4k sometime soon (there's a queue of big-ticket things... :)
<pedronis> mborzecki: hi, does my comment about symmetry of call patterns make sense, or do we need to chat about it?
<mborzecki> pedronis: yup it's clear, i missed that in your previous review, i'll be pushing out patches soon
<pedronis> mborzecki: basically, except that they are kind of like push pop, I would expect to see calls to those *Prefix helpers in roughly the same place/numbers in the rollback and backup flows
<mborzecki> Chipaca: https://i.imgur.com/rQsOcCm.png window in the left is clementine from the snap, right one is distro packages, also snap version seems to use qt 4.8 (?)
<Chipaca> hmm, ok
<mborzecki> pstolowski: updated https://github.com/snapcore/snapd/pull/6939 please take a look
<pstolowski> ok
<pstolowski> +1
<mborzecki> pstolowski: yay ;) will land it once it's green
<Chipaca> I'm going to take a break, take a couple of pills and see if I feel better
 * Chipaca feeling blagh
 * Chipaca will bbl
<zyga> take care Chipaca!
 * zyga goes to do reviews
<pstolowski> mborzecki: can you take another look at #7052? needs 2nd review
<mborzecki> pstolowski: sure
<jamesh> zyga: re. https://github.com/snapcore/snapd/pull/6959, do you have any feedback on my responses to your earlier review?
<zyga> jamesh: hey
<zyga> jamesh: let me look
<jamesh> zyga: I agree that it would be good to do something about "directories matching the glob pattern".  I'm just not sure exactly what that should look like
<zyga> jamesh: I think we should not just execute the logic as is
<zyga> jamesh: and instead error or panic
<zyga> jamesh: I think this one is also actionable: https://github.com/snapcore/snapd/pull/6959#discussion_r296584872
<jamesh> zyga: the problem is that the directory blacklist glob is not the same as the glob for files we want to update
<jamesh> the first needs to be a glob that will match any other globs that might be used for this directory
<zyga> jamesh: what is the use case of the function?
 * zyga re-reads that fragment
<jamesh> consider the case that I call EnsureTreeState with a glob of "snap.foo.*", asking to put a create a file "snap.foo.file" in a directory "snap.bar.dir"
<jamesh> the passed in glob won't have any problem with the directory, but it will cause a problem for a second EnsureTreeState call with a glob of "snap.bar.*"
<jamesh> zyga: the use case is allowing a snap to export icon theme icons
<jamesh> essentially we want to create a merged /usr/share/icons style tree with data from multiple snaps by only letting the snaps create icons prefixed with the snap name
<zyga> jamesh: what's the rough structure there?
<jamesh> zyga: the first level of directories is the icon theme name.  Directories after that is "whatever is defined in the index.theme file"
<zyga> so /usr/share/icons/$theme/$anything?
<jamesh> we don't let snaps install an index.theme: they'd need to match the layout of the icon theme they're providing an icon for
<jamesh> yes.  We're installing icons to /var/lib/snapd/desktop/icons though
<jamesh> it all gets merged via $XDG_DATA_DIRS
<zyga> I see
<jamesh> so the directory tree is under snapd's control, but we don't have full knowledge of its structure
<zyga> I wish we had set $XDG_DATA_DIRS to /var/lib/snapd/export/desktop
<zyga> it would play nicely with the idea to export other kinds of content
<jamesh> or export/share
<zyga> jamesh: would it be okay to iterate over keys of "content" and error if it matches any of the globs? similar to what this does: https://github.com/snapcore/snapd/blob/master/osutil/syncdir.go#L69
<zyga> I'm really trying to avoid the situation when this executes in unexpected ways
<jamesh> zyga: as I said, I think it would need to be a second glob (or set of globs)
<jamesh> to avoid one snap poisoning a second snap
<zyga> jamesh: wait, perhaps I'm missing something
<zyga> (I might as well be, it's hot and there's no air conditioning here)
<zyga> jamesh: I'm not talking about the directory walk
<zyga> jamesh: just about the input arguments
<jamesh> I'll try expressing myself in code in a comment on the PR
<zyga> ok
 * Chipaca still bleugh but trying to work
<jamesh> zyga: https://github.com/snapcore/snapd/pull/6959#discussion_r302010405 <- I think this demonstrates the problem
<zyga> looking
<zyga> jamesh: and what will actually happen if you do this pair of calls?
<zyga> what will happen to disk and what will the function return?
<jamesh> zyga: at the moment, we don't protect against it, so there will be an EnsureDirState call for "$baseDir/somedir" that will fail when it tries to remove "snap.bar.directory"
<jamesh> If the first call is done on behalf of snap A, and the other on behalf of snap B, then the source of the problem is going to be fairly far removed from the symptom
<zyga> re, net failure
<zyga> could we detect that in the dir walk and bail out, doing nothing?
<zyga> I'm just trying to make this function fail in a well-defined way
<jamesh> yes.  The second call could bail out when it detects the trap the first call set
<zyga> this one is also related https://github.com/snapcore/snapd/pull/6959#discussion_r296584872
<zyga> since when something fails it will rm -rf all matching content
<zyga> and this is surprising because one has to consult the documentation of EnsureDirStateGlobs to know that
<jamesh> I guess for the tree version that should cover all the subdirs it successfully synchronised
<jamesh> before the failure
<zyga> jamesh: indeed, I though about just documenting it but now that you mention it, it seems actual code is needed
<jamesh> combinging with the previous issue, it would fail to remove the "somedir/snap.bar.directory" trap since it isn't empty
<jamesh> I'll have a look at this again tomorrow.
<zyga> jamesh: thank you!
<pedronis> mvo: could you review 7016 ?
 * zyga small break from heat
<mvo> pedronis: yes, after lunch
<zyga> re
<tartley> o/ Morning all
<tartley> oops wrong channel
 * zyga hammers spread and grabs a cofee
<mborzecki> still spamming with new PRs: https://github.com/snapcore/snapd/pull/7087
<zyga> mborzecki: looking
<roadmr> zyga: it's easier if you... spread it around with a knife. Hammering it will just crush your bread.
<roadmr> context-dependent jokes are the best ð
<zyga> today I would love to see rain, my mind is melting away at the heat
<roadmr> "I live in such a hot, tropical place". "Where, Cuba? the Caribbean?" "No - Poland"
<zyga> roadmr: today it's actually closer to cuba, we're back in Spain
<zyga> roadmr: poland already has autumn
 * zyga took hold shower
<roadmr> hehe zyga
<zyga> I needed that
 * zyga needs a review on https://github.com/snapcore/snapd/pull/7082
 * zyga continues reviews
<ogra> https://www.omgubuntu.co.uk/2019/07/devs-want-to-drop-snap-support-from-gnome-software
<ogra> heh ... it is funny that the reaction in the commenst seems to be "drop GNOME" ... not "drop this snap stuff"
<ogra> *comments
<zyga> ogra: sensationalism, it's just "press" latching onto a story
<ogra> zyga, sure, but usually the comments section has "cnonical should drop that snap stuff, flatpack is so much better" (ignoring the actual difference) or "shitty canonical NIH stuff" (ignoring that snaps are two years older than flatpak)
<zyga> ogra: that's true but I would say that comment sections are in general, horrible
<zyga> ogra: it's just that we are more lucky this time
<ogra> the article itself is indeed definitely  clickbait
<zyga> ogra: having said that, I'm curious about the snap store app
<ogra> i find comments sections a big source of entertainment ... and after all they reflect a fraction of users out there
<ogra> (just dont comment yourself ... )
<ogra> zyga, well, ask robert_ancell_ then ;)
 * ogra senses a webdm comeback as electron app :P
<ogra> j/k
<zyga> ogra: maybe we will all use enlightenment again ;)
<ogra> lol
 * diddledan peeks in.. sees ogra has op status.. runs out screaming about the end of the world
<ogra> LOL !!
<zyga> ogra: oh, you are *the* op
 * zyga spawns lots of spread machines to check a change and takes a break
<zyga> mvo: I would love a review for https://github.com/snapcore/snapd/pull/7082 to unblock me
<zyga> ijohnson: ^
<ijohnson> zyga: thanks I'll take a look after my meeting right now
<zyga> thanks, I'm really blocked by that
<zyga> it's not super perfect, I know, it could use more testable design, I just really want to move towards the code that uses it :)
<mvo> zyga: meetings :/
 * zyga hugs mvo
 * cachio lunch
 * zyga takes a break for some back pain relief
<ijohnson> zyga: approved 7082
 * ijohnson lunches
<zyga> ijohnson: fantastic, thank you
<zyga> ijohnson: one more if you have time today https://github.com/snapcore/snapd/pull/7089
<zyga> ijohnson: treating size= differently because it is not super deterministic even when rewriting
<zyga> ijohnson: also some advice on the upcoming test, it measures mount namespaces of a number of things; the bulk of the test is normalized expected data
<zyga> ijohnson: I wonder if I should propose it all at once and then work on reviewing or split it
<zyga> ijohnson: e.g. qemu vs google could be split easily (separate data sets per backend)
<zyga> ijohnson: I will propose it all-at-once once 7089 is merged, then we can discuss
<zyga> ijohnson: it's is mainly either establishing a baseline
<zyga> ijohnson: so not a sophisticated review
<zyga> ijohnson: or actually reviewing the sensibility of the mount namespace
<zyga> ijohnson: and here I'd argue that some things are silly and warrant changing
<zyga> ijohnson: in either case I have some work on early changes to core legacy to fix things
<zyga> ijohnson: the mount namespace test will be used to sanity check changes to propagation settings and to some corrections to ubuntu-core legacy mode
 * cachio afk
<jdstrand> roadmr: hi! can you pull 20190709-2230UTC?
<roadmr> jdstrand: sure thing, will put it in the queue at least
<ijohnson> zyga: I looked at 7089 for you and approved with a couple name/description suggestions. I don't quite follow all of what you said about about the future work, but it will probably make sense to me after seeing the full test
<zyga> ijohnson: ack
<zyga> ijohnson: suggestions applied, thank you!
<zyga> ijohnson: I'm slowly heading to bed, I'll open the main PR for the ns test tomorrow
<zyga> thank you again :)
<mwhudson> zyga: do you get mail about debian snapd bug reports?
<mwhudson> or more generally, does some snapd developer?
#snappy 2019-07-11
<ghostnik11> hi i have a question about snap and getting firefox updated to the latest version? how can i, b/c apt and snap don't talk to each other and i want to have firefox updated to version 67 but in snap its only at 66
<ghostnik11> okay i found the clue was to run command: sudo snap refresh
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> and back
<zyga> mwhudson: perhaps, though I haven't seen any lately
<zyga> good morning mborzecki
<mborzecki> zyga: hey
<zyga> brbr
 * zyga dog walk and coffee
<zyga> hey mvo
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7091
<mborzecki> mvo: morning
<zyga> mborzecki: shall I split that ;D
<zyga> and with that, I'll be back in 20
<zyga> mborzecki: perhaps I should add one sub-variant first?
<mvo> good morning mborzecki and zyga
<pstolowski> hey
<mborzecki> pstolowski: hey
<zyga> back
<zyga> good morning mvo, good morning pawel
<zyga> mborzecki: perhaps I should really split the PR into something people won't run away from
<mborzecki> zyga: hmm maybe start with core16 or 18 first and drop qemu
<zyga> mvo: *the* test https://github.com/snapcore/snapd/pull/7091/files
<zyga> mborzecki: +1
<zyga> mborzecki: good idea on qemu
<zyga> it's x2 the data with qemu
<mborzecki> zyga: the tool doesn't support comments in mountinfo dumps, wonder whether it'd be useful to add some annotation to the expected outputs
<zyga> mborzecki: hmmm, that would be pretty easy
<mborzecki> zyga: prbably the test should include backends: [-autopkgtest] too ?
<zyga> good idea, I was thinking about how to block backends for qemu
<jamesh> zyga: could you restart this CI run for me?  It looks like it got stuck some how.  https://travis-ci.org/snapcore/snapd/builds/557127004
<zyga> sure
<zyga> done
<jamesh> it'd be nice if Travis let regular users restart jobs associated with their own PRs
<zyga> mborzecki: done, only google is used now
 * zyga does reviews
<mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/7087 is probably harmless to land, the gadget code uses noop updaters, so we'll at least have the edition and checks logic executed at this point
<mborzecki> pedronis_: i can tweak the existing spread test for gadget update to only go through updating the snap, without verifying whether the content was updated, and add it to the PR
<pstolowski> mvo: re what we discussed yesterday evening - https://github.com/snapcore/snapd/pull/7092
<mvo> pstolowski: thanks, looking
<mvo> pstolowski: I'm reviewing your patch PR now btw
<pstolowski> mvo: no pressure, this needs to wait for other stuff anyway
<mvo> (finally, sry for the delay)
<pstolowski> no worries
 * zyga fixes leaky tests
<pedronis> mborzecki: sorry, not sure I follow, anyway chasing other things atm
<pedronis> mvo: pstolowski: seems we all forgot about this code:  https://github.com/snapcore/snapd/blob/master/snap/info_snap_yaml.go#L243
<mborzecki> pedronis: ok, np, we can sync later
<zyga> but must me my "lucky" time, I ran this many times on all the suites and it didn't fail
<zyga> I propose my PR and WHAM
<zyga> but that's ok :)
<zyga> one test seems to leak netns mount
<zyga> should be easy
<pstolowski> pedronis: i removed it in 7083 with the assumption that it's either set correctly by us or comes correct from the store, does it make sense?
<pedronis> pstolowski: I think it will should be removed when we add type: snapd to snapcraft.yaml
<pstolowski> pedronis: so maybe #7092 should land first (once new snapcraft is in stable)?
<ackk> jdstrand, hi, would it be possible to get a new deb (or snap if it's easier) for the patched snapd with users support, based on the current master? it'd help us testing the fixes to interfaces you recently landed (like running systemd-detect-virt and accessing /proc/sys files)
<pedronis> pstolowski: maybe,  it would avoid this: https://github.com/snapcore/snapd/pull/7083/files#diff-556bb7431481e375713ea3e0883a771a
<pstolowski> pedronis: indeed
<pedronis> but I don't want to block John either
<Chipaca> ð
<pstolowski> sergiusens: hey, what's the timeframe for "snapd" type support in snapcraft to hit "stable"?
<popey_> pstolowski: what does that mean?
<pstolowski> zyga: woah @ 7091
<pstolowski> popey_: i've landed a small enhancement in snapcraft to support "type:snapd", we need it in stable to proceed with symmetric changes in snapd code
<zyga> pstolowski: it's half the size as in the morning :)
<popey_> neat
<pstolowski> zyga: nice. i finally get the big picture of all the python PRs i looked at recently ;)
<zyga> pstolowski: it's not over yet, now to combat leaky tests
<pstolowski> zyga: looking at it, this looks super nice (i hope it's not going to surprise us with unexpected failures)
<zyga> pstolowski: I'm sure it will a little, I just fixed a leaky netns test
<zyga> but I hope not that  many
<zyga> I'm looking at changing spread.yaml to ensure leaky tests are "caught"
<zyga> but yeah, took some pain to get to the point where it generally works okay and when it fails, it can be reliably said to show something being wrong elsewhere
<zyga> pstolowski: the only "late" addition is classic, since we want to start changing classic confinement I thought those extra tests would be useful
<pstolowski> zyga: i see, indeed, sounds like a good plan
<sergiusens> pstolowski wrapping up a couple of uc20 related PRs and doing a release. I am off today and tomorrow, so most likely next week and once tagged and in candidate the speed depends on how fast people respond to the call for testing (and how out more exhaustive tests go)
<pstolowski> sergiusens: sounds good, thank you. fwtw i tested yesterday's snapcraft from edge with snapd and type:snapd
<pstolowski> zyga: reviewed
<zyga> pstolowski: thanks!
<pstolowski> zyga: replied
<zyga> thanks
<zyga> I'm running all tests in a loop and just got another clean pass, hopefully the netns one was a one-off
<zyga> and having fixed that test we will not see other tests resurface
<pstolowski> nice
 * pstolowski early lunch & an errand
<mvo> pstolowski: silly question, in an ideal world where we have all the information, when would we do the reset of the sublevel for level60? the old code checked for revno 5332, does that mean (in an ideal world with all the data) we would only reset the sublevel if we come from something older than 5332? if we are on a newer revno, would we ever need to reset the sublevel?
<mvo> pstolowski: replied in the pr, if you don't mind I would like to squash 7016 and cherry pick to 2.40
<zyga> brb
<zyga> re
<zyga> I'm merging the mount-ns test with the MS_SHARED branch locally, on very quick inspection the mount namespaces actually look good!
<zyga> :)
<zyga> I haven't moved to core yet, just classic for now
<zyga> I will probably write a new test as well, to show how specific things are set up (e.g. /home across all three) to show that propagation is good (in a manner more readable then the full dump)
<zyga> interfaces-contacts-service test failing https://www.irccloud.com/pastebin/LoVplaZj/
<pedronis> cachio mentioned there's a timing issue there and was looking into that
<jdstrand> ackk: sure. I'll be spending some time on that pr today so will give it to you after that
<ackk> jdstrand, thanks!
<mborzecki> zyga: this PR from cachio: https://github.com/snapcore/snapd/pull/7088 through i'm not certain about the fix
<zyga> mborzecki: interesting, looking
<zyga> hey jdstrand
<zyga> the new test is fantastic
<zyga> MS_SHARED causes quarter of mount points to go away
<zyga> on core16
 * zyga goes to analyze why
<Eighth_Doctor> zyga, mborzecki: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/
<Eighth_Doctor> zyga, mborzecki: this is kind of a crappy thing to wake up today
<mborzecki> Eighth_Doctor: heh
<mborzecki> pedronis: mvo: ^^
<Eighth_Doctor> I didn't know you guys were planning on discontinuing effort on g-s-snap
<Eighth_Doctor> I wish I had been told about this ahead of time so that I could have had a contingency plan for this...
<pedronis> Wimpress: willcooke: ^
<mborzecki> Eighth_Doctor: thanks for the heads up anyway!
<Eighth_Doctor> a number of my friends and colleagues actually use snaps through g-s, since Fedora Workstation is the main variant people use
<willcooke> We are going to continue to maintain the g-s snap plugin
<Eighth_Doctor> and whenever folks installed snapd in Fedora, it would auto-install the plugin, giving people a seamless experience :(
<willcooke> kenvandine, ^
<Eighth_Doctor> what am I supposed to do for GNOME people now?
<zyga> brb
<Eighth_Doctor> willcooke: can someone _please_ reply to this thread on devel@ so that they know that, because right now this looks kind of bad... and I just started working on my presentation for Flock on snaps too :(
<zyga> Eighth_Doctor: I wasn't aware of this until a few days ago
<Eighth_Doctor> the worst part is I'm finding this out because of Phoronix
<Eighth_Doctor> https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Software-Dropping-Snap
<Chipaca> Eighth_Doctor: FWIW I found out because of askubuntu :-|
<Eighth_Doctor> wtf ð
 * Chipaca always reads that as "as kubutu" and then is disappointed
<Chipaca> Eighth_Doctor: sorry i meant omgubuntuwtfbbq
<Chipaca> Eighth_Doctor: https://www.omgubuntu.co.uk/2019/07/devs-want-to-drop-snap-support-from-gnome-software
<Eighth_Doctor> ah that site
<Chipaca> Eighth_Doctor: frain bart
<Eighth_Doctor> oh god
<Chipaca> Eighth_Doctor: don't read the comments
<Chipaca> Eighth_Doctor: just, don't
<Chipaca> zyga did and he is lost to us now
<pedronis> Chipaca: zyga: mvo and me have a different meeting that clashes with the standup today
<Chipaca> holidays for everybody \o/
<Eighth_Doctor> Chipaca: damn it, I hate people now
 * Chipaca hugs Eighth_Doctor 
<zyga> pedronis: ack
<Chipaca> Eighth_Doctor: when did we promise sandboxing support, btw?
<willcooke> kenvandine, can you ask Robert to reply to that thread? ^
<Eighth_Doctor> Chipaca: from the beginning, I think? though it hasn't worked in Fedora until very recently
<Eighth_Doctor> though non-Ubuntu snap sandboxing is much more rudimentary than Ubuntu snap sandboxing
<zyga> Chipaca: are you coming?
<kenvandine> willcooke: Will do
<Chipaca> zyga: nah, i'm good
<Chipaca> :-p
<jdstrand> hey zyga :)
<cachio> Chipaca, hey, about the snap pack option, what is that?
 * zyga quick lunch
<Chipaca> cachio: which is the test in question?
<cachio> Chipaca, failover
<Chipaca> cachio: tests/main/failover, or tests/core18/snapd-failover?
<cachio> Chipaca, tests/main/failover
<Chipaca> cachio: so, to see if it fixes the issue, we'd change the 'snap pack' to a mksquashfs
<cachio> Chipaca, ah, ok
<Chipaca> cachio: if it does, we can then look into a low-mem 'snap pack'
<cachio> I'll try it
<cachio> thanks
<Chipaca> cachio: you know all the mksquashfs flags needed?
<cachio> Chipaca, no
<Chipaca> 1 sec :)
<Chipaca> cachio: it's packing core, yes?
<cachio> yes
<cachio> Chipaca, ~
<Chipaca> cachio: give me a bit
<cachio> Chipaca, sure
<zyga> Chipaca: we repackage core in tests
<zyga> Chipaca: in prepare
<zyga> Chipaca: just don't pass -comp xz
<Chipaca> zyga: exactly
<Chipaca> cachio: /snap/core/current/usr/bin/mksquashfs "$BUILD_DIR/unpack" "./core_<something something>.snap" -noappend -comp gzip -no-fragments -no-progress
<cachio> Chipaca, perfect, thank you very much
<Chipaca> cachio: I *think* the "./core_<...>.snap" is just "failing.snap" (and you skip the mv)
<cachio> Chipaca, yes
<Chipaca> cachio: following zyga's lead, note you could also instead load lib/snaps.sh and use mksnap_fast
<cachio> Chipaca, nice, I'll try that also
<cachio> and see which works better
<cachio> also I need to velidate that on the boards because there we have just 1 gb of RAM
<zyga> re, back from calls
 * cachio afk
<ijohnson> hey zyga are there any more mountinfo-tool PR's you need me to look at? or is the MS_SHARED PR ready to use those changes?
<zyga> ijohnson: no, that's all
<ijohnson> zyga: ack I'm just gonna focus on the snapctl netplan-apply stuff today then
<zyga> ijohnson: ack, thank you
<mvo> Eighth_Doctor: hey, sorry I am in meetings but I was unware of what was happening I will figure out what happend
<roadmr> jdstrand: the tools update from yesterday is now in prod \o/
<Eighth_Doctor> mvo: thanks
<jdstrand> roadmr: thanks! :)
<jdstrand> roadmr: that was fast :)
<zyga> re
 * zyga goes to debug leaky test
<mvo> sergiusens: I get ""snapcraft-josm:/var/cache/snapcraft/snaps" is already mounted" when running snapcraft pull - how can I fix this? any suggestions? I tried to stop the multipass machine but that was not enough
<sergiusens> mvo might need to Snapcraft clean first but would appreciate if the state before that is discussed with Saviq or ChrisTownsend
<cachio> zyga, hey
<zyga> cachio: hey
<cachio> zyga, quick question
<zyga> yeah?
<cachio> running the test base-migration
<cachio> I run test-snapd-core-migration.sh -c "cat /usr/lib/os-release"
<cachio> and it is not creating the file /run/snapd/ns/snap.test-snapd-core-migration.info
<cachio> on ubuntu core on rpi
<zyga> is the version of snapd in sync with the test?
<zyga> cachio: the .info file is created unconditionally
<zyga> cachio: so I suspect it's just old snapd/core
<zyga> cachio: running against "new" tests
<cachio> core from beta
<cachio> this fails running beta validation
<zyga> I don't know if this is recent enough
<cachio> 2.40
<zyga> all I'm saying is that it indicates snap-confine is just  older than the test
<cachio> zyga, ah
<cachio> weird because I use the beta branch
<cachio> for the test
<zyga> 77e3ff647bd40764a0ab366cb0b4cfdc8157ff3f
<zyga> this is the merge commit for the feature
<zyga> if you can check that it is present in the build you can know
<zyga> you can also look for this debug message visible when SNAP_CONFINE_DEBUG=yes is set:
<zyga> debug("saved mount namespace meta-data to %s", info_path)
<cachio> zyga, https://paste.ubuntu.com/p/hQkM4cvXBm/
<zyga> yeah, this looks good
<cachio> zyga, ok, I'll check if the variable is set
<zyga> you can run "strings" on snap-confine to check
<cachio> how could I run it ?
<zyga> cachio: re
<zyga> cachio: just "strings"
<zyga> it's a command name
<zyga> just run it on the snap-confine binary
<zyga> if it shows something similar to the debug message I pasted then that binary has that patch
<zyga> if it doesn't it is not the right snap-confine
<zyga> maybe the build system is stuck?
<cachio> test@localhost:~$ /usr/lib/snapd/snap-confine strings
<cachio> Usage: snap-confine <security-tag> <executable>
<cachio> executable name was not provided
<zyga> cachio: the binary is strings
<zyga> strings  /path/to/snap-confine
<cachio> ahh
<zyga> don't run strings through snap-confine :)
<cachio> external:ubuntu-core-16-arm-32 .../tests/main/base-migration# sudo /snap/core/7345/usr/share/bash-completion/completions/strings /usr/lib/snapd/snap-confine
<cachio> sudo: /snap/core/7345/usr/share/bash-completion/completions/strings: command not found
<zyga> cachio: copy the binary to another system?
<cachio> ok
<cachio> zyga, no output running in my machine
<cachio> I copied both binaries
<zyga> cachio: what do you mean no output? nothing at all?
<zyga> cachio: both?
<cachio> nothing
<cachio> zyga,  yes both
<zyga> cachio: that's unexpected, there are surely other strings there
<zyga> do you mean that nothing when piped through grep?
<zyga> or entirely nothing?
<cachio> nothing nothing :)
<zyga> cachio: is the file empty?
<zyga> you can look at the snap-confine binary yourself to assure yourself that it is full of text
<zyga> so something must be fishy
<cachio> https://paste.ubuntu.com/p/pcJQDyWwQp/
<zyga> zyga@yantra:~/snapd> strings /usr/lib/snapd/snap-confine  | wc -l
<zyga> 1100
<zyga> how did you copy strings?
<zyga> or actually
<zyga> scratch that
<cachio> scp
<zyga> can you not copy strings but actually just snap-confine from the device under test
<zyga> and then run strings on your system against that binary
<zyga> look at what I pasted above ^
<zyga> it has over a thousand strings recognized
<zyga> so either your binary is empty
<cachio> using the strings comman on my machine
<zyga> or you didn't run the same strings command I did
<cachio> and the snap-confine from the rpi3
<cachio> I get 1240
<zyga> ah, so it's not nothing?
<zyga> so what changed, I'm confused
<cachio> I used the strings command on my machine
<zyga> but that's what you did before, no?
<zyga> aynway
<zyga> can you grep for that debug message please?
<cachio> sure
<cachio> sergio@cachiomachine:~/workspace/validator/images$ strings ./snap-confine | grep SNAP_CONFINE_DEBUG
<cachio> SNAP_CONFINE_DEBUG
<zyga> don't grep for SNAP_COFNINE_DEBUG
<zyga> grep for the debug message that was added the merge patch
<zyga> debug("saved mount namespace meta-data to %s", info_path)
<cachio> zyga, that one does not appear
<zyga> in that case the build is out of sync with the tests
<cachio> zyga, ok, that explains everything
<cachio> I'll talk to mvo tomorrow about that
<cachio> zyga, thanks for the support
<zyga> happy to help, good luck!
<cachio> zyga, the weird part is that it works well on pc-amd64 and pc-i386
<zyga> is that debug message present there?
<cachio> not sure yet
<cachio> I am creating the image agin
<cachio> again
<cachio> zyga, I think the problem is that the test was merged into release/2.40 after the beta core was created and before the tests were executed
<cachio> zyga, I'll continue tomorrow with that one
<cachio> see you
<jdstrand> ackk: fyi, https://people.canonical.com/~jamie/snapd-daemon-user/
#snappy 2019-07-12
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mvo> pstolowski: 7016 has two +1, can I squash it and cherry pick it to 2.40?
<mborzecki> https://github.com/snapcore/snapd/pull/7093 can land easily
<mvo> pstolowski: also see my last comment, AIUI the sublevel patch is applied not more often now than before? or am I misreading something?
<pstolowski> mvo: yes! thank you
<mvo> pstolowski: thank *you*
<mborzecki> passing a suite selector with ... on spread command line, those are nor ORed apparently
<mborzecki> duh, manual: true :/
<zyga> Hey, trying to connect from my laptop but fighting network issue
<zyga> Somehow cannot tether
<pedronis> mborzecki: reviewed again 6890, it needs a 2nd review, John gave it but has changed a lot since.
<mborzecki> pedronis: great, i'll ping Chipaca when he's around
<zyga> re
<zyga> yay
<ackk> hi, is there a way for a (confined) snap to know the channel it's tracking?
<zyga> ackk: no, but we discussed adding that via snapctl
<zyga> ackk: perhaps pstolowski knows this?
<pedronis> I don't remember discussing this in particular
<pstolowski> yep, as pedronis says
<pedronis> we mainly discussed: checking whether an interface is connected, check whether there is new revision, and very recently checking whether there's a missed/pending auto-refresh because an app was running
<pedronis> I think is not totally out of question to return this info in the 2nd of that list
<pedronis> but I would like to understand the use case
<ackk> pedronis, in maas' case, we have an option to deploy a machine as a maas rackcontroller, which installs the snap. ideally we want the same version of the currently running maas. of course there's no guarantee that the channel doesn't have a newer revision, but pointing the new machine to the same channel is the best option
<pedronis> ackk: you want to use cohorts for that
<pedronis> that's what they are designed for
<ackk> pedronis, how do they work?
<pedronis> make sure a cluster always uses the same revision
<pedronis> ackk: https://forum.snapcraft.io/t/managing-cohorts/8995  they will be in 2.40
 * ackk reads up
<ackk> pedronis, so the idea is you create a cohort on machine A ("pinning" the version of maas), deploy machine B and install maas using the cohort, delete the cohort?
<pedronis> ackk: yes, you don't delete cohorts though
<pedronis> they don't take space in the store
<ackk> pedronis, but they will prevent both machines for getting updated if a new snap is released right?
<zyga> pedronis: we did discuss checking which channel is being tracked in lyon
<pedronis> zyga: I don't remember, maybe in a conversation I was not in, or maybe it was before I arrived
<zyga> pedronis: perhaps in a hallway but I'm sure we had that conversation
<zyga> I don't recall that detail
<pedronis> ackk: they will prevent the machine to get updated for 90 days, then they update but they will again update to the same revisions
<ackk> pedronis, ok. so if we don't want to hold the update, just to get them on the same channel, deleting is fine. correct?
<pedronis> ackk: deleting what?
<ackk> pedronis, the cohort after installing machine B
<pedronis> ackk: there is not deleting of cohorts
<ackk> sorry, i mean, leaving it
<pedronis> ackk: no, if you leave it
<pedronis> they will potentially go out of sync
<pedronis> if you want to refresh you do the same
<pedronis> get a new cohort
<pedronis> on a machine
<pedronis> and refresh again on the others using that cohort
<zyga> mborzecki: found one more leaky test https://github.com/snapcore/snapd/pull/7091/commits/bace705b928d065a61870cf16953b652ad5c576a
<ackk> pedronis, but you have to leave the cohoort to refresh, right?
<pedronis> ackk: no
<ondra> zyga ping
<zyga> hey ondra
<pedronis> acck: you do snap refresh --cohort=<new-cohort>
<ondra> zyga I have machine which just went into funny state
<pedronis> <snap>
<ondra> zyga opengrok-2 opengrok.tomcat[3188]: cannot locate base snap core18: No such file or directory
<ondra> zyga ut
<ondra> zyga it's classic ubuntu 18.04
<pedronis> ackk: you can switch from cohort to cohort without leaving using those ops
<zyga> ondra: is core18 mounted?
<ackk> pedronis, oh, I see, I thought create-cohort would be related to what you have, I see it's not
<zyga> ondra: mborzecki reported weird system state after systemd update today
<ondra> zyga it has not rebooted for weeks
<ondra> zyga it's mounted, but there is not sym link to 'current'
<zyga> ondra: but systemd updates in place
<zyga> ondra: oh, that's curiour
<mborzecki> ondra: looked like systemd lost track of loopback devices and where they were mounted at after it was daemon-reexec'ed during the update
<zyga> ondra: can you check snap changes?
<zyga> mvo: ^^
<ackk> pedronis, I see, thanks
<zyga> mvo: current went away on ondra's machine
<ondra> zyga yep 86   Error   today at 07:04 UTC      today at 07:04 UTC      Auto-refresh snap "core18"
<ondra> zyga https://paste.ubuntu.com/p/G4rT485kFr/
<ondra> zyga hmm Error   today at 07:04 UTC  today at 07:04 UTC  Make current revision for snap "core18" unavailable
<ondra> zyga I did not. update systemd for ages there
<zyga> ondra: can you show snap tasks  for that change please?
<ondra> zyga this machine is running web service, so I did not touch it for several weeks/months
<zyga> ondra: some updates auto apply via security pocket
<ondra> zyga do you mean that paste bin I sent?
<zyga> oh, looking
<zyga> ondra: your fs is broken
<zyga> ondra: is / writable?
<ondra> zyga it's classic ubuntu
<zyga> ondra: is it writable
<zyga> looks like it switched to read only mode
<ondra> zyga looks like
<ondra> I was able to touch file in home
<ondra> zyga and root
<zyga> actually, the error is curious
<zyga> https://www.irccloud.com/pastebin/CEml5ETz/
<zyga> er
<zyga> that's the $SNAP_DATA data-set
<zyga> is /var/snap mounted on another partition>?
<ondra> zyga it is :)
<zyga> is that partition read only?
<ondra> zyga nope writable
<zyga> ondra: then I don't know
<zyga> ondra: check system logs for around 2019-07-12T07:04:46Z
<zyga> maybe something happened then?
<ondra> zyga no I could only see there that read only error
<ondra> zyga so manual 'snap refresh core18' went fine and fixed it
<zyga> ondra: which cloud provider is this?
<mvo> pstolowski: thanks for 7096! really nice to see how straightforward this is now
<pstolowski> mvo: it became so much simplier with nulls internally
<mvo> pstolowski: cool stuff!
<pstolowski> i could throw away a large chunk of the new code
<ondra> zyga you do not want to know, canonistack :D
<ondra> zyga I blame it on cosmic rays
<zyga> pstolowski: with https://github.com/snapcore/snapd/pull/7096/files we could look at tests that set stuff to unset it
<zyga> I have a few for sure
<zyga> thanks for that!
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/7096#pullrequestreview-261176295
<pstolowski> zyga: thanks!
<Chipaca> pedronis: fwiw, fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1828500
<zyga> pstolowski: one more https://github.com/snapcore/snapd/pull/7096/files#r302922240
<pedronis> Chipaca: we need to loop in whoever is making those images
<Chipaca> pedronis: loop in, yes. With steel wire around <body parts>.
<Chipaca> pedronis: assuming my suspicion is correct
<Chipaca> which I suspect it is :-)
<pstolowski> zyga: right, thanks!
<Chipaca> anyhow, time for a break
 * Chipaca breaks things
<mborzecki> this is interesting https://forum.snapcraft.io/t/too-early-for-operations/12243/8
<mborzecki> shouldn't core be listed there?
<zyga> mborzecki: yes
<zyga> whoever makes that seed needs to fix it
<mborzecki> hm that's 19.10 :) at least it hasn't been released yet
<mborzecki> mvo: do you know how seed.yaml is generated for those images?
<zyga> mborzecki: perhaps manually
<zyga> mborzecki: many people don't know about snap prepare-image and use a page full of shell to do the "equivalent"
<zyga> given that there are on snap IDs there I bet it is the shell versioni
<mvo> mborzecki: what image exactly?
<mborzecki> mvo: see the topic, someone installed 19.10 from a daily image, seed.yaml looks broken
<mvo> mborzecki: :( I think those seeds are generated "manually" by some livecd-rootfs shell. we can ask foundations (cc sil2100) how 19.10 daily image seed.yaml is generated and if it can be fixed
<pedronis> we are trying to move them to prepare-image --classic
<pedronis> but given the complexity of livecd-rootfs, is not trivial
<diddledan> Chipaca: I just added the seed.yaml from a hyper-v image
<diddledan> ref: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1828500
<Chipaca> diddledan: thanks! could you do the followup, ie sudo snap info --verbose /var/lib/snapd/seed/snaps/*.snap | grep base:  ?
<diddledan> done
<Chipaca> diddledan: who creates these images, do you know?
<diddledan> I don't
<diddledan> looks like willcooke might know as he posted the blog entry about them https://ubuntu.com/blog/optimised-ubuntu-desktop-images-available-in-microsoft-hyper-v-gallery
<Chipaca> willcooke: can we talk about QAing stuff :/
<zyga> I can try the hyper v image later if anyone needs me to
<diddledan> does snapd wait for the user to login before doing any pre-seed? I'm wondering if the way those images logs you in is confusing matters - it uses XRDP over a Hyper-V internal socket
<Chipaca> diddledan: no it does not
<diddledan> ok, ignore that then :-p
 * diddledan throws more random at the wall until stuff sticks :-D
<Chipaca> diddledan: it's simple, the seed.yaml needs to be self-contained
<willcooke> Chipaca, it has been working previously, because things like calc are snaps.  I have a feeling we have talked about this problem previously, but kenvandine will need to comment further.
<Chipaca> diddledan: if a snap in seed needs core18, core18 needs to be in the seed
<diddledan> aha. so the seed.yaml is missing core18!
<Chipaca> willcooke: calc and things have needed core18 since shortly after 18.04
<Chipaca> willcooke: those images have gone out, and we blogged about them, without them working: the _seeded_ snaps have core18
<diddledan> that makes sense, because core did get installed by the pre-seed
<Chipaca> this isn't a weird things-got-updated-after-image-baking, the image is baked and has not been tested
<Chipaca> willcooke: thus me asking about QA
<Chipaca> willcooke: you have the same issue in dailies fwiw, if that's also 'under' you
<Chipaca> willcooke: https://forum.snapcraft.io/t/too-early-for-operations/12243?u=chipaca
<Chipaca> (i'm less concerned about these because those are explicitly not qa'd)
<willcooke> Chipaca, kenvandine knows about this, he'll be online in an hour or so I expect
<Chipaca> ok
<Chipaca> willcooke: both of these?
<willcooke> Chipaca, yes, I think it's the same problem, and I have a feeling that he's spoken to someone in your team about this recently. I thought he'd worked around it, but it would seem not
<Chipaca> willcooke: I'll wait and talk with kenvandine when they're around, then
<Chipaca> my view is very snapd-centric but I don't see what there's to workaround :-)
<ackk> I've been seeing a weird behavior recently. At times some snaps (maybe it's actually just core18) show up in nautilus as removable devices. If I click on it it gets mounted under /media and I see the content, but the file is not actually there: https://paste.ubuntu.com/p/9DMCxHR3RN/
 * zyga sees that as more rationale to mount snaps in dedicated namespaces only
<ackk> zyga, I don't understand how nautilus finds it, the file is not there but I can mount/umount it multiple times and it actually works
<zyga> ackk: nautilus probably tracks all mount ops
<ackk> zyga, yeah but the snap is gone, and it's not mounted anymore
<Chipaca> ackk: wait until you notice using tab completion on snap makes devices flicker in nautilus
<Chipaca> ackk: *that* will do your head in
<zyga> Chipaca: whaaat?
<ackk> wat?
<Chipaca> not all the time, sadly
<mborzecki> zyga: rawhide cloud image https://paste.ubuntu.com/p/FTTpjJv2Hj/ hm doesn't look like only v2
<zyga> mborzecki: perhaps not switched by default yet, the plan is to by release though
<mborzecki> zyga: mhm
<mborzecki> zyga: ok, on cgroup2 now only
<zyga> mborzecki: woot
<zyga> mborzecki: I'm fixing leaky tests
<zyga> mborzecki: found a good way now
<mborzecki> zyga: i mean the image is switched to unified hierarchy https://paste.ubuntu.com/p/YzcFg4rD7z/ ;)
<zyga> mborzecki: ?
<zyga> mborzecki: did you switch yourself
<zyga> mborzecki: or did you update?
<zyga> mborzecki: I like one thing about v2
<zyga> mborzecki: run mount
<zyga> mborzecki: see how short that is? :D
<mborzecki> zyga: switched it myself, this the yesterday's compose
<mborzecki> zyga: shorter but not super short :)
<zyga> mborzecki: how long is it?
<mborzecki> zyga: https://paste.ubuntu.com/p/sbfygMW6Hr/
 * zyga sees more bpf
<mborzecki> heh
<mborzecki> poeple seem use some automation to track upstream releases for aur packages, mvo uploaded a release 2h go, 40 minutes ago got an email from aur that the package has been flagged already
<zyga> god, why is apt removing lxd all the time
<zyga> mvo: how can I check that a package is installed vs auto-installed
<mvo> zyga: apt show lxd
<mvo> zyga: watch out for "APT-Manual-Installed: yes
<mvo> "
<zyga> mvo: thank you
<zyga> mvo: tests are wreaking havoc to lxc preinstalled in cloud image
<zyga> mvo: because unrelated apt-get autoremove other-package # removes lxd
<mvo> fun
<mvo> apt install xld
<mvo> apt install lxd
<mvo> will set lxd to manual installed
<zyga> yeah, I'm just double checking the initial state
<zyga> the qemu images don't have lxd
<zyga> but cloud images do
 * pstolowski lunch
<mvo> 7k closed PRs
 * mvo is impressed
<zyga> mvo: so, I don't see the manual flag
<zyga> mvo: but apt autoremove doesn't remove it
<zyga> https://www.irccloud.com/pastebin/qI2YEpuO/
<mborzecki> Chipaca: also https://forum.snapcraft.io/t/too-early-for-operations/12243/ is a daily 19.10 image
<zyga> hmmmm
<zyga> gosh
<zyga> what is making this broken :.
<Chipaca> zyga: which thing?
<zyga> Chipaca: tests installing and removing packages
<zyga> I don't understand it yet
<zyga> but some remove operations remove lxd
<zyga> why, don't know
<zyga> fighting spread to give me shell before changing the image much
<zyga> usability of spread is sometimes lacking
<mvo> zyga: that means its used by something
<zyga> mvo: is that apt show line going to show me this  information reliably, that it is auto-installed?
<zyga> mvo: I want to understand what is breaking the state (changing it from manual to auto)
 * zyga is extremely fed up with the heat
<mvo> zyga: maybe we can have a quick chat ? I'm not sure I have enough context but there are a bunch of debug option available to figure out why something gets removed
<mvo> zyga: do you have a link to a log or something?
<zyga> mvo: I'm tired, need a break
<zyga> mvo: I will look at this later
<jdstrand> ackk: not sure you say from yesterday: 17:24 < jdstrand> ackk: fyi, https://people.canonical.com/~jamie/snapd-daemon-user/
<mvo> zyga: yeah, lets just talk after the standup
<mborzecki> zyga: broken snaps looks like a larger problem with systemd/5.2 kernel
<mborzecki> zyga: just got the same state after a reboot
<mborzecki> zyga: https://paste.ubuntu.com/p/QMH66ZXcNW/
<mborzecki> arch package updated
<Chipaca> drat, late for lunch
 * Chipaca runs
 * Chipaca om noms
 * Chipaca is on fire
 * Chipaca makes a note to use fewer chillies next time
<Eighth_Doctor> ugh...
 * Chipaca omw
<Eighth_Doctor> https://twitter.com/hughsient/status/1149663770026733571
<Eighth_Doctor> https://blogs.gnome.org/hughsie/2019/07/12/gnome-software-in-fedora-will-no-longer-support-snapd/
<Chipaca> I was particularly perturbed by him saying we're at war
<diddledan> "One ISO consortium member asks whether they should remove hydrogen engine support from the ISO car as they feel BMW is not playing fair." <-- that's the crux, it is being used as a punishment for daring to consider alternatives
<diddledan> and let's be clear. the investigation is barely 20 days old
<Eighth_Doctor> diddledan: imo, having something that isn't g-s for the non-gnome flavors would be useful anyway
<Eighth_Doctor> right now, there's nothing available for DEs that don't have their own software management frontend
<Eighth_Doctor> like MATE, for example
<Eighth_Doctor> diddledan: I'm not happy that I'm being caught in the crossfire though :(
<mborzecki> zyga: added a topic about mount problems with 5.2 I see here: https://forum.snapcraft.io/t/snap-mounts-broken-with-kernel-5-2-and-systemd-242/12272
<zyga> thank you, looking
<Chipaca> Eighth_Doctor: is there anything i can do to help
<diddledan> cuddles?
<Chipaca> Eighth_Doctor: even if it's just something like, send you pizza or flowers or beer or something
<Eighth_Doctor> Chipaca: I don't know
<Eighth_Doctor> haha
<zyga> mborzecki: thank you for reminding me about 2.40; I'll update openSUSE and look at Debian
<Eighth_Doctor> zyga: is 2.40 out now?
<mborzecki> Eighth_Doctor: yes
<Eighth_Doctor> joy...
<roadmr> https://snapcraft.io/core
<Eighth_Doctor> alright, since hughsie is being a jerk, I guess I have to package gnome-software-snap separately
<Eighth_Doctor> Chipaca: what makes this situation worse is that he's trapped me with the snap store thing
<Eighth_Doctor> I don't know if I dare bring up this to FESCo or the Council, because he might try to use it to get snapd removed from the distro entirely
 * diddledan wants 2.41 already :-p ('cos it'll have my change from https://github.com/snapcore/snapd/pull/6876)
<Eighth_Doctor> Chipaca: he put that in the changelog entry for justification: https://src.fedoraproject.org/rpms/gnome-software/c/ef1746da8c7613c6bd29d9b9bbfbe95c4291bc85
<Chipaca> Eighth_Doctor: *hugs*
<diddledan> surely all this throwing of toys is just gonna force Ubuntu to not use gnome software ever again?
<Eighth_Doctor> to me, it looks like he's just unhappy he can't have flathub
<Eighth_Doctor> that's what it seems like to me, but he says he was already told Ubuntu wasn't going to
<Eighth_Doctor> I think I've handled this fairly well, all things considered: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O4CMUKPHMMJ5W7OPZN2E7BYTVZWCRQHU/
<zyga> Eighth_Doctor: oh man
<zyga> Eighth_Doctor: changelog entry
<Eighth_Doctor> zyga: yup
<zyga> Eighth_Doctor: yeah, it feels like a lot of hurt feelings now
<pstolowski> mvo: btw #6977 needs your re-review
<zyga> Eighth_Doctor: thank you for participating in that discussion, I feel that it is unfortunate it ended up like that and that  some heat-of-the-moment-commit-messages will be regretted eventually
<zyga> but what's done is done
<mvo> pstolowski: aha, nice - thank you!
<Eighth_Doctor> zyga: I guess I'm packaging gnome-software-snap separately now
<Eighth_Doctor> god damn all of this
<mvo>  /o\
<mborzecki> Eighth_Doctor: hopefully it's smooth as long as g-s doesn't break the a[pb]i
<mvo> Eighth_Doctor: sorry for the trouble
<Eighth_Doctor> mborzecki: ABI breaks every release
<Eighth_Doctor> that's why no one does out of tree plugins
<zyga> https://twitter.com/hughsient/status/1149677435933224960
 * cachio afk
<kenvandine> mvo: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?h=eoan&id=6f3707c8dd8fdc7c4c0ca1eeff428fa0e4678db6
<diddledan> \o/
<diddledan> awesome, kenvandine :-)
<Chipaca> kenvandine: note you also need to have 'core'
<kenvandine> Chipaca: iirc livecd-rootfs pulls in core explicitly
<Chipaca> dunno if the new logic thing does that
<kenvandine> or was
<kenvandine> right
<diddledan> you need to have both now
<Chipaca> kenvandine: yesterday's daily did not
<kenvandine> right
<Chipaca> kenvandine: that's what the forum issue was about
<kenvandine> looks like this has been broken for a while
<Chipaca> kenvandine: the launchpad one was a missing core18
<mvo> kenvandine: thank you!
<Chipaca> kenvandine: what project should I assign the launchpad one to?
<kenvandine> livecd-rootfs i guess
<kenvandine> since according to this commit should be explicitly pulling in core18
<Chipaca> https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1828500
<Chipaca> done :)
<diddledan> the commit is `- * core18` - the commit explicitly removed core18 from the list
<kenvandine> right
<kenvandine> but the commit message said they did that because livecd-rootfs explicitly adds it
<Chipaca> kenvandine: what QA is done on these images? how did get to make a blog post about an image that was broken in this way?
<Chipaca> kenvandine: talking about the hyperv ones in particular
<kenvandine> we manually tested he hyperv images, so i don't know what happened there
<kenvandine> Chipaca: remember i had run into a similar problem with this?
<kenvandine> and we figured out what was needed to get the seed to work
<Chipaca> kenvandine: yes which is why i assumed there was some sort of automated qa to catch it
<kenvandine> when i was creating the 19.04 images
<Chipaca> 18.05 already had these issues (from hwe peeps)
<Chipaca> or was it 18.06
<kenvandine> and it was working, so i'm really confused as to how what ended up on partner-images is broken
<Chipaca> anyway, yeah
<kenvandine> unless it wasn't the right image that was copied there
<kenvandine> which could b
<kenvandine> +e
<kenvandine> at the time we were manually moving files around and had a series of broken images
<kenvandine> we're just now getting a more formalized process as foundations is taking over creating those images
<kenvandine> Chipaca: so i guess we should actually revert that commit and add core18 to the bionic seed?
<diddledan> I can't find a corresponding commit (removing core18) for bionic branch - it looks like core18 was never added in the first place
<kenvandine> right
<kenvandine> it wasn't
<kenvandine> livecd-rootfs was supposed to be handling that
<diddledan> well it seemingly does for the downloadable isos.. somehow the hyper-v ones were different (unavoidably they need a separate spin because they have the xrdp changes)
<pedronis> mvo: this is the pastebin I mentioned in the standup (about core18): https://pastebin.canonical.com/p/hVfzbMmwm2/
<diddledan> bah @ private pastes :-p
<diddledan> how's a nosey busybody gonna watch what ya'll up to if you keep it private ;-p
<mvo> diddledan: haha - sorry for that, its just about testing stuff
<diddledan> for "nosey busybody" read: diddledan
<kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-seeds/+git/ubuntu/+merge/370061
<kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-seeds/+git/ubuntu/+merge/370062
<kenvandine> https://code.launchpad.net/~ken-vandine/ubuntu-seeds/+git/ubuntu/+merge/370063
<diddledan> heh. launchpad is having a brainfart
<diddledan> .. and it's back
<diddledan> will need to make sure to check the images this produces that explicitly adding core18 doesn't somehow conflict with anything livecd-rootfs does
<diddledan> I'm thinking about the non-hyper-v cases here where we had the right thingâ¢ already
<ackk> did something changed in recent snapds wrt /proc/PID/mounts?
<kenvandine> diddledan: we didn't though, the latest 19.10 isos have the same problem
<diddledan> oh ok..
<kenvandine> it's not just hyperv
<kenvandine> the released 19.04 and 18.04.2 isos were fine
<diddledan> I figured they were fine 'cos bionic and cosmic seemingly did the right thing
<zyga> ackk: what are you seeing?
<diddledan> you need mount-observe IIRC?
<ackk> zyga, denials on those files. not sure if they're causing issues, but I don't think they were there before
<zyga> ackk: the mount table is a "mild information leak" so it was always denied without mount-observe AFAIR
<ackk> zyga, I see
<zyga> ackk: I think nothing has changed there recently
<ackk> zyga, thanks
<Chipaca> kenvandine: the latest 19.10 isos have a different problem, maybe, not the same
<Chipaca> kenvandine: as they have core18, and they don't have core
<kenvandine> ah... actually i think they wanted to drop core and add the snapd snap?
<kenvandine> they tried that late in disco and found problems
<kenvandine> Chipaca: so maybe attempting the same for eoan
<kenvandine> mvo: ^^ do you recall that?
<mvo> kenvandine: in a meeting right now
<kenvandine> ok
<Chipaca> kenvandine: that will only work if you have a model and the model has a base
<kenvandine> ok, i know that's something they wanted to do.
<Chipaca> kenvandine: given that we're getting Â«cannot proceed without seeding âcoreâÂ»
<Chipaca> kenvandine: then you're missing one of those two things :-)
<Chipaca> s/you/we/
<Chipaca> s/you/we/g
<Chipaca> kenvandine: to be clear, you'd only get that message in three scenarios:
<Chipaca> dammit!
<Chipaca> kenvandine: to be clear, we'd only get that message in three scenarios:
<Chipaca> 1. we don't have a model (wut)
<Chipaca> 2. the model doesn't have a base
<Chipaca> 3. the model has a base that is explicitly set to "core"
<Chipaca> that's because that message comes from installSeedEssential
<Chipaca> which happens before the rest of the seeding proceeds
<kenvandine> https://git.launchpad.net/ubuntu/+source/livecd-rootfs/tree/live-build/functions?h=ubuntu/eoan#n434
<Chipaca> kenvandine: yeah, the "is the model ok with this" isn't in the picture there is it
<kenvandine> right
<Chipaca> snap_prepare_assertions does look into the model, so maybe it can extract this info to feed into the seeding logi
<Chipaca> but, dunno
<Chipaca> anyway, imma go break things for a bit
 * Chipaca takes a break
<kenvandine> looks to me like the disco branch has the same logic, so expects to be able to seed snapd instead of core
<kenvandine> but the bionic branch doesn't, it does explicitly seed core
<Chipaca> kenvandine: I don't know what model we use, but all it would take would be for it to have a core18 base
<Chipaca> pedronis: maybe you know ^
<pedronis> Chipaca: no base doesnt make sense for classic images
<pedronis> it's only for core images
<Chipaca> pedronis: ?
<pedronis> what I said
<Chipaca> pedronis: 'snap known model' on classic ubuntu 16 says we don't have a base
<pedronis> cannot put base: core18 and classic: true in a model
<pedronis> Chipaca: true
<pedronis> doesn't mean core is the base
<pedronis> there's no root base for a classic system
<Chipaca> d'oh, i missed trivialSeeding
<Chipaca> 	configTs := snapstate.ConfigureSnap(st, "core", 0)
<Chipaca> grr
<Chipaca> kenvandine: classic always needs core
<Chipaca> pedronis: thank you
<Chipaca> pedronis: also maybe classic always needing core is a bug
<pedronis> it doesn't quite need core
<pedronis> that is config
<Chipaca> sigh
<Chipaca> pedronis: hol' up
<Chipaca> pedronis: there's only one place that prints that error message
<pedronis> which error message?
<Chipaca> pedronis: so we're obviously hitting that code path
<Chipaca> pedronis: cannot proceed without seeding âcoreâ
<pedronis> Chipaca: to be clear, I'm not saying there are no bugs
<Chipaca> :-)
<pedronis> just makign clear that setting a base
<pedronis> is not the answer
<Chipaca> yeah, i got you so far
<Chipaca> ah, we only do trivial seeding if _no_ seed is there
<Chipaca> otherwise we do seeding as normal
<Chipaca> and, given you can't set a base for a classic model
<Chipaca> you'll always require core
<pedronis> atm yes
<Chipaca> which means adding snapd makes no sense
<Chipaca> so that code in livecd-rootfs-wotsit is wrong, or at least ahead of its time
<Chipaca> kenvandine: ^
<kenvandine> ok
<pedronis> Chipaca: we don't have tests about this
<pedronis> classic with just snapd
<pedronis> that's why is not worky
<Chipaca> pedronis: well, we do now, in the shape of cd images in the wild
<Chipaca> :)
<Chipaca> rather expensive tests
<pedronis> I wouldn't call it
<pedronis> us having a test
<pedronis> more, there is a test
<Chipaca> make your 'we' bigger and you'll get there
<Chipaca> :-p
<pedronis> also why livece-rootfs shouldn't be in the game
<pedronis> for 2nd guessing snapd
<pedronis> Chipaca: anyway just a matter of having a variant tests/main/classic-firstboot/task.yaml
<pedronis> and fixing first boot to do sane things
<pedronis> Chipaca: relatedly, this is still wip: https://github.com/snapcore/snapd/pull/6404
<Chipaca> I'm going afk for a while, will be back later to EOW properly
 * pstolowski pstolowski|afk
<Chipaca> you know it's time to EOW when you're having to up the font size of everything
<Chipaca> have an excellent weekend, all!
<zyga> Chipaca: heh :)
<zyga> Chipaca: see you after next week
<zyga> Chipaca: enjoy the quiet days
<Chipaca> Eighth_Doctor: still waiting on where to send pizza etc
<zyga> (when everything is on fire and nobody picks up the phone ;-)
<Chipaca> Eighth_Doctor: (but reach me on twitter :) )
<Chipaca> zyga: we'll give everybody your tg contact info, no fear
<zyga> Chipaca: excellent, I'll be somewhere between here and poland
#snappy 2019-07-13
<chachasmooth> why is there still no way to disable automated snap updates?
<chachasmooth> suppose someone whose snap I'm running releases a new snap version which has a critical bug
<chachasmooth> why can't system administrators decide for themselves when it's time to upgrade something?
<chachasmooth> I don't want my system to break when I'm on holidays and can't access my server to fix it
<chachasmooth> automated updates are nice for beginners, but there has to be a way to disable it â at least manually
<probono> i'd even go so far as to say you should be able to update one application without interfering with the rest of the system
<probono> and you should be able to have multiple versions of the same application in parallel (getting a new version should not automatically remove the old version)
<probono> this is how it works in #Appimage chachasmooth
<sincere_fox> guise, can I make a snap package that includes a webapp and postgresq
#snappy 2019-07-14
<Eighth_Doctor> zyga, robert_ancell_: https://src.fedoraproject.org/rpms/gnome-software/pull-request/1
#snappy 2020-07-06
<mborzecki> morning
<pstolowski> morning
<zyga> good morning
<zyga> sorry for being late, not feeling well
<pstolowski> oh, sorry to hear
<mborzecki> pstolowski: zyga: hey
<zyga> I need a review for https://github.com/snapcore/snapd/pull/8977 to make progress on raa
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> it's almost entirely spread tests + tiny new feature in snap-ru
<zyga> run
<mborzecki> quick errand, back in 30, and then i'll do a review of zyga's PR
<zyga> thank you
 * zyga tweaked his PR and goes to review top-to-bottom
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8976 fails on preseed tests
<mup> PR #8976: snap-confine: don't die if a device from sysfs path cannot be found by udev (2.45) <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8976>
<zyga> do you need to put something into the release branch to unbreak it?
<zyga> it seems unrelated to the change in the PR itself
<pstolowski> zyga: oh... we have quite a bit of delta with master for these tests & lib/nested.sh :/
<zyga> hmm, making a point release could be difficult then
<pstolowski> zyga: maybe we should disable them in release . might be painful if we update nested.sh
<zyga> at the same time, the preseed test is pretty important
<pstolowski> zyga: many changes in spread.yaml as well, it's all interconnected
<zyga> do you know why the existing test may have stopped working?
<pstolowski> zyga: i'll investigate in a moment, but from a quick glance it seems to be core -> snapd snap transition that we fixed before in master
<pstolowski> afair it affected match rules in the tests & nested.sh helpers
<mborzecki> re
<jamesh> mvo: I got around to testing out a scheme to share private fontconfig caches: https://forum.snapcraft.io/t/shared-fontconfig-cache-prototype/18660
<zyga> brb
<zyga> jamesh: mvo is on a sprint this week
<jamesh> zyga: ah.
<zyga> he's starting at around noon and has limited availability
<jamesh> zyga: you might be interested in the post too
<zyga> (so roughly 3-4 hours later than usual to be in sync with US)
<zyga> yeah, I just opened it :)
<zyga> I'm very interested, I had to rm -rf cache on my groovy system the other day
<zyga> brb, need to fetch glasses from the other room
<jamesh> zyga: in particular: what are the chances of relaxing the restrictions on where content interface can mount stuff?
<zyga> jamesh: where do you need to mount stuff?
<jamesh> zyga: Ideally I'd like to do a content interface share mounted to /var/cache/fontconfig
<zyga> I see
<zyga> let me think, I think in theory content could behave more like layouts
<zyga> but first, glasses
<mup> PR snapd#8974 closed: spread.yaml: remove tests/lib/tools from PATH <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8974>
<mup> PR snapd#8976 closed: snap-confine: don't die if a device from sysfs path cannot be found by udev (2.45) <Bug> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8976>
<mvo> zyga, jamesh good morning
<mvo> jamesh: oh, private caches! exciting!
<jamesh> Trying to combine content interface plus layouts didn't work because the layouts mount occurred first.  I just ended up with an empty directory on /var/cache/fontconfig
<pstolowski> hi mvo!
<zyga> re
<zyga> mvo: hey :)
<mvo> hey pstolowski
<mvo> anything I can help with that does not require too much brian power :) ?
<pstolowski> mvo: who is brian? ;)
<mvo> brain
<mvo> see, that's my point :)
<pstolowski> :)
<zyga> mvo: I wanted to ask you about https://github.com/snapcore/snapd/pull/8974 but you just merged woot!
<mup> PR #8974: spread.yaml: remove tests/lib/tools from PATH <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8974>
<zyga> thank you :)
<mvo> :)
<mborzecki> pstolowski: brian, the man called brian? ;)
<mborzecki> zyga: https://www.jeffgeerling.com/blog/2020/uasp-makes-raspberry-pi-4-disk-io-50-faster
<mborzecki> via hackernews
<zyga> woah
<zyga> that's neat
<zyga> once I'm okay again and can work from the office I will get something like this for my 8GB PI4
<mborzecki> ok, on to the reviews
<mborzecki> zyga: do you have a spread test for tracking where everything works and with v2?
<zyga> mborzecki: tracking is already tested in v2
<zyga> cgroup-tracking shows this
<zyga> raa is not tested here yet as I broke the patch so that overlord bits are not there yet
<zyga> but the test for that exists in the other branc
<mborzecki> zyga: the large branch right?
<zyga> well, not so much anymore but yeah :)
<zyga> the bigger branch
<mborzecki> ok
<zyga> after this lands it will be quite small actually, mostly removals and small changes to overlord, and one last spread test
<zyga> there's more later, mainly test coverage improvements
<zyga> for hooks in particular
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8977#pullrequestreview-442883866
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mborzecki> zyga: some tweaks, are the unit tests in the other branch too?
<zyga> mborzecki: lookig
<zyga> mborzecki: there are no more unit tests in the other PR
<zyga> mborzecki: yeah, about mocking, I wonder where those tests went, I think I wrote some but perhaps I didn't or perhaps they got lost somehow along the path
<zyga> mborzecki: thanks for the review, I'll finish pawel's service PR and get back to it
<mborzecki> zyga: https://forum.snapcraft.io/t/snapd-for-aarch64-opensuse/18663
<zyga> thanks
<mup> PR snapd#8979 opened: tests: more checks in core20 early config spread test <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8979>
<mvo> pstolowski: fwiw, 8960 has a conflict
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8960#pullrequestreview-442914596
<mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
<zyga> I will park reviews and go back to https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<pstolowski> mvo: ah, on it, ty
<pstolowski> zyga-x240: thanks for the review!
<mup> PR snapd#8980 opened: tests: backport preseed test fixes to 2.45 <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8980>
<pstolowski> zyga-x240: ^ this should fix the error you reported earlier
<pedronis> pstolowski: mborzecki: I updated #8906
<mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<mborzecki> pedronis: thanks
<pedronis> mborzecki: I'll do a follow up about 001
<pstolowski> thanks, checking
<pedronis> and 010
<zyga-x240> pstolowski: thanks
<zyga-x240>  brb
<ijohnson> hello folks
<zyga-x240> ijohnson: hey
<ijohnson> hey zyga-x240
<pstolowski> hi ijohnson !
<ijohnson> o/ pstolowski
<zyga-x240> mborzecki: I've added tests to https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga-x240> mborzecki: I'll do a pass over spread tests and comment suggestions after lunch/standup
<zyga-x240> mborzecki: thanks, your comment helped to find a bug
<mborzecki> zyga-x240: hm hm? where?
<mborzecki> snap run?
<zyga-x240> yeah
<zyga-x240> mborzecki: it's a subtle bug that wasn't screaming broken
<zyga-x240> but testing uncovered it just ifne
<zyga-x240> *fine
<pstolowski> cachio: hey, #8558 has conflicts
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<cachio> pstolowski, checking, thanks
<zyga-x240> hmm
<zyga-x240> no standups?
<zyga-x240> I don't see a standup in my calendar
<mborzecki> no more standup link?
<zyga-x240> I guess we can skip
<zyga-x240> or do it here
<zyga-x240> how do you guys feel about doing an IRC standup/
<cachio> pstolowski, I'll need to apply some changes to this once #8942 is merged
<mup> PR #8942: tests: support different images on nested execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8942>
<mborzecki> zyga-x240: standup?
<zyga-x240> mborzecki: where?
<zyga-x240> mborzecki: there's no standup in the calendar
<pstolowski> cachio: ah, ok, let's try to get #8942 in
<zyga-x240> cachio: thank you for all the tooling improvements
<pstolowski> cachio: i made a few comments to your PRs
<zyga-x240> I know it's a lot of work but I really think those are important for the longevity of the testing code
<zyga-x240> cachio: how would you feel about adding a test helper for the defer.sh/tac trick?
<cachio> zyga-x240, it is ok
<zyga-x240> I wanted to use it without repeating the code around
<cachio> I'll add this to my todo list
<zyga-x240> tests.cleanup perhaps
<cachio> so I can start it after the snaps.sh migration is proposed
<cachio> zyga-x240, nice, yes, makes sense
<mborzecki> cmatsuoka: https://github.com/snapcore/snapd/pull/8981
<mup> PR #8981: boot, bootloader: query kernel command line of run mod and recovery mode systems <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8981>
<cmatsuoka> mborzecki: ack, will check
<mborzecki> ijohnson|sprint: ^^ if have the time between the meetings
<ijohnson|sprint> mborzecki: nice I will add it to my queue, let's see how much time I have :-)
<mup> PR snapd#8981 opened: boot, bootloader: query kernel command line of run mod and recovery mode systems <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8981>
<mborzecki> cmatsuoka: ijohnson|sprint: thanks!
<pedronis> mborzecki: I had a prepare failure on centos 7 on my PR, is tht known?
<mborzecki> pedronis: do you ahve the log?
<mborzecki> pedronis: or which pr, and i can take a look
<pedronis> mborzecki: https://github.com/snapcore/snapd/pull/8906/checks?check_run_id=841248103
<mup> PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<mborzecki> pedronis: looks like somehting temporary
<zyga-x240> mborzecki: updated https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mborzecki> pedronis: other prepare jobs were successful, so maybe something with a particular mirror getting synced at the time of the request
 * zyga-x240 needs a moment for painkillers to work
<mborzecki> pedronis: restarted the spread jobs in that pr
<mborzecki> time to run some errands
<mup> PR snapcraft#3202 opened: build providers: fix base change warning message <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3202>
<mup> PR snapcraft#3155 closed: storeapi: specify Content-Type for icon <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3155>
 * cachio lunch
<zyga-x240> cachio: I have something for that now,
<zyga-x240> cachio: I'll open a pull request in a minute
<mup> Issue core18#161 closed: mknod: /home/ubuntu/core18/parts/boostrap/install/dev/null: Operation not permitted <Created by WillNilges> <Closed by WillNilges> <https://github.com/snapcore/core18/issues/161>
<mup> Issue core18#162 opened: Beef up build instructions <Created by WillNilges> <https://github.com/snapcore/core18/issues/162>
<pedronis> mborzecki: the centos 7 problem seems more persistent my PR failed again
<pedronis> same way
<mborzecki> pedronis: can you make it non-required for now?
<pedronis> I should be able to now
<mborzecki> funny, how prepare failed on one now, but all the tests run on the other nodes
<mborzecki> bbiab
<pedronis> mborzecki: done
<mup> PR snapd#8906 closed: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8906>
<mup> PR snapd#8982 opened: snapshots: export of snapshots <Created by slimjim777> <https://github.com/snapcore/snapd/pull/8982>
<mup> PR snapcraft#3097 closed: colcon v2 plugin + ros2 extension <enhancement> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3097>
<zyga-x240> cachio: https://github.com/snapcore/snapd/pull/8983
<mup> PR #8983: tests: add tests.cleanup helper <Created by zyga> <https://github.com/snapcore/snapd/pull/8983>
<mup> PR snapcraft#3203 opened: experimental ros2 extension & colcon v2 plugin <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3203>
<mup> PR snapd#8958 closed: tests: nested test improvements from master (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8958>
<mup> PR snapd#8983 opened: tests: add tests.cleanup helper <Created by zyga> <https://github.com/snapcore/snapd/pull/8983>
<cachio> zyga-x240, nice, I'll take a look
<mup> PR snapcraft#3097 opened: colcon v2 plugin + ros2 extension <do-not-merge> <enhancement> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3097>
<sdhd-sascha> hey, zyga, and anybody who mention ;-) how are you ?
<sdhd-sascha> zyga: is the merge ok enough? the unit-test stop with some pgp ...
<sdhd-sascha> mvo: how are you?
<sdhd-sascha> hi, alan_g - you generalist ... what do you today ?
<sdhd-sascha> sorry, i'm afk ...
<sdhd-sascha> zyga: look's like nobody talk to me.
<ogra> sdhd-sascha, there is a virtual company sprint going on i guess the whole snapd team is busy with that
<sdhd-sascha> ogra: thank you ;-) i didn't know
<ogra> well, its an internal thing, usually not promoted to the outside world a lot
<sdhd-sascha> ogra: i had understood. But, you helped me. That is the cause, why  i said "thank you", to you ;-)
<ogra> ð
<sdhd-sascha> :-)
<mvo> sdhd-sascha: yeah, what ogra said, busy in meetings :/ but nice to "see" you :)
<sdhd-sascha> me too, i feel the same ;-) (don't know why...)
<sdhd-sascha> i listen: https://www.youtube.com/watch?v=QRQwZDWz1Pw&t=4051s
<diddledan> that's my educational friendly to youngsters bit done for today ;-) https://github.com/dotnet/runtime/issues/1634
<ogra> hah, teaching LD_PRELOAD to the masses !
<diddledan> IKR!
<diddledan> obviously by "very experienced developers" I'm referring to myself, because until I got going on Snapping stuff I was oblivious
<diddledan> in my defence, I'm supposed to be a PHP dev :-p
<diddledan> as in using PHP to dev, not writing the PHP language
<sdhd-sascha> mvo: you, didn't believe it! some guy want to programm a webserver from me. I know, i can do low-level with sockets... and i can do the other way.... (But really, i feel sucked, but that question.... I learned all my way ;-) )
<diddledan> sdhd-sascha: netcat into bash? ;-p
<sdhd-sascha> diddledan: ;-) nice ... sometime i didn't know "nc" ;-)
<diddledan> I've seen router firmwares running their webserver scripts as bash
<diddledan> as in using bash for the application code
<mvo> sdhd-sascha: if you need a webserver, https://bazaar.launchpad.net/~snappy-dev/snappy-hub/go-example-webserver/revision/1 could be a starting point,
<sdhd-sascha> diddledan: you mean, that bash as parent process is a problem? i only see such routers ? ...
<sdhd-sascha> mvo: no... i mean, some person, ask me to write a socket "daemon" .... (me?)
<diddledan> ogra, about fabrica, could it possibly be extended to use containers a la docker, you think? I've got snapcrafty building into images for all the supported architectures, which work with qemu-user-static on Githug actions, so I wonder if we could add them to fabrica too
<diddledan> ... they also spin up a real snapd and systemd inside them
<ogra> i surely wont reject patches ð
<diddledan> the downside is you need to start the containers in --privileged mode
<ogra> well, fabrica is a daemon
<ogra> though it would require a lot of code to make it use docker or some other container system ... the current code is only lxd go stuff
<diddledan> aye
<ogra> but i indeed wouldnt refuse it ð
 * diddledan pops it on the toedoe list
<ogra> heh
<diddledan> sdhd-sascha, I meant that the scripts generating the HTML for the browser are BASH. you open your browser, go to the router page, the webserver executees some bash and returns the output
<diddledan> insert-exploit-here
<diddledan> who remembers shellshock? :-o those were fun times
<sdhd-sascha> diddledan: ??? ok ??? i read alot how to exploit my router... but it isn't mine.... the owner is the telephonee company... so i do nothing!!!!
<ogra> i have a few toshiba flash-air cards here ... you can actually flash the OS on them through such an exploit and make them run a proper linux ð
<sdhd-sascha> diddledan: thank you ;-) i respect you ;-)
<sdhd-sascha> diddledan: just soom boot"s ... i know ;-)
<zyga-x240> re
<sdhd-sascha> ogra: i really want to know more of you knowledge ;-)
<diddledan> allo zyga-x240
<sdhd-sascha> zyga-x240: why did you change your nick? And... ....
<zyga-x240> I stopped using irccloud so I use separate nicknames for each machine
<sdhd-sascha> zyga-x240: really? what test at cannocial was it now ? and why, do you think?
<zyga-x240> I don't understand your question, sorry
<sdhd-sascha> here, at my place... i often use "rke" kubernetes installer... it works goood... but today, it says "no" ...
<sdhd-sascha> zyga-x240: no, problem...
<sdhd-sascha> zyga-x240: just, want say. That i respect you ;-)
<cachio> zyga-x240, the #8973 is updated
<mup> PR #8973: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8973>
<zyga-x240> cachio: thanks, I'll check it out tomorrow though
<cachio> zyga-x240, thanks
<zyga-x240> I came to check the weird failures in some tests
<sdhd-sascha> zyga-x240: how are you weather today? we have small rain at 7. And the rest strong wind.... (But everybody is happy about the sun...)
<zyga-x240> sdhd-sascha: it was rather cold most of the day with some rain starting in the late afternoon
<sdhd-sascha> zyga-x240: cold ? really ? can't beleave ... it was 20 degreee here...
<sdhd-sascha> all the day...
<sdhd-sascha> zyga-x240: you are a good guy/people, for me at least ;-)
<zyga-x240> thanks, I'm just trying to do my best :)
<sdhd-sascha> that's why i say it ;-)
<zyga-x240> cachio: something very wrong and weird happend
<sdhd-sascha> i just listen (or read) ;-)
<zyga-x240> cachio: I think prepare/restore across the new "tools" suite is broken
<sdhd-sascha> zyga-x240: i know
<zyga-x240> cachio: all of the failures can be summarized as "tests/bin" is either empty or not on PATH
<zyga-x240> cachio: all of the tests pass in isolation, I'm trying a larger run now
<sdhd-sascha> cachio: is there no zyga left?
<cachio> zyga-x240, are you talking about master?
<zyga-x240> cachio: I don't know yet, I cannot understand how those things are failing
<zyga-x240> I just ran a few of those tests one-by-one and they did not fail
<cachio> zyga-x240, do you have a url with the errror?
<zyga-x240> do you see any typos there?
<zyga-x240> hmmm
<cachio> zyga-x240, I'll try to reproduce
<zyga-x240> cachio: wait a sec
<zyga-x240> spread.yaml seems stale, maybe I haven't rebased this on recent master
<zyga-x240> I see tests/lib/tools in PATH still
<zyga-x240> maybe that's why?
<sdhd-sascha> i see typos... but i .... hmm. ... i wonder onllllllllly .... hmm .... i'm behind you and my strenght is for you ;-)
<zyga-x240> trying again
<sdhd-sascha> +49 15 15 5789 0 752
<sdhd-sascha> what, try again ?
<zyga-x240> sdhd-sascha: hmm? what are you saying
<sdhd-sascha> zyga-x240: where are you from?
<zyga-x240> sdhd-sascha: from Poland, why?
<sdhd-sascha> zyga-x240: sorry, for my question. (again) my grandparents was from slowakiya ... I'm love earth.
<sdhd-sascha> zyga-x240: can i visit you? maybe my skepticial wife ...
<zyga-x240> cachio: I force-pushed without changes just after rebasing
<zyga-x240> sdhd-sascha: I don't think so
<cachio> zyga-x240, good
<zyga-x240> sdhd-sascha: I'm totally not in shape right now and I don't know you that much to begin with
<mup> PR snapcraft#3202 closed: build providers: fix base change warning message <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3202>
<sdhd-sascha> if cachio did you harm... than someone should stop him!!
<sdhd-sascha> that, was not the last, what i send
<zyga-x240> sdhd-sascha: ?!?
<zyga-x240> what are you talking about
<sdhd-sascha> zyga-x240: and you? are  you ok ?
<zyga-x240> sdhd-sascha: I'm not okay but my colleague cachio has nothing do with that, what made you think that?
<sdhd-sascha> why, did you mention "cachio" ? i',m try to be fair to anyone...
<mup> PR snapcraft#3204 opened: Improvements to the flutter plugin <Created by kenvandine> <https://github.com/snapcore/snapcraft/pull/3204>
<zyga-x240> sdhd-sascha: I'm talking to cachio about test failures in a pull request
<sdhd-sascha> zyga-x240: thank you. Your mention. Is better, then others!!!!
<sdhd-sascha> yesterday, on german tv, there was titanic.
<zyga-x240> I'm stuck in bed with serious back problems, no TV for me
<sdhd-sascha> what back probs?
<sdhd-sascha> zyga-x240: if you give me a probLEM .... i solve it... maybe 3 weeks later....
<zyga-x240> spinal cord herniation
<diddledan> yeah, that's not gonna get fixed remotely ;-p
<sdhd-sascha> oooh ;-) i try to translate...
<sdhd-sascha> hmmm...
<zyga-x240> diddledan: I wish it could
 * diddledan files a spinal PR
<sdhd-sascha> i too:-) (Hope i understand)
<cachio> heheheh
<diddledan> you need a rock band to give it a prod.. a spinal tap, if you will ;-p
<cachio> I also have issues with my spine
<zyga-x240> cachio: I'm sorry to hear that, I know the pain
<cachio> zyga-x240, yes, but for sure it is not like you
<cachio> I am going to the kinesioligist weekly
<cachio> because of the pain
<cachio> but it is improving litle by litle
<cachio> zyga-x240, I hope you will be better as well
<zyga-x240> I hope so too
 * diddledan hugs everyone remotely
<zyga-x240> :-)
<cachio> :)
<sdhd-sascha> cachio: i know, it would different without "brexit" ...
<sdhd-sascha> or did i say that to bad?
<sdhd-sascha> @cachio i'mean i didn't wont to suppset you ;-)
<mup> PR snapd#8984 opened: asserts: integer headers: disallow prefix zeros and make parsing more uniform <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8984>
<zyga> cachio: mystery solved, I forgot to git add a file :)
<zyga> cachio: it will pass now, I opened the review
<sdhd-sascha> zyga: i just merge it. Should i think about it? Snapd is not my child?!... Should i understand all the source ?
<sdhd-sascha> hmm, sorry
<mup> PR snapd#8985 opened: snap/validate.go: disallow snap layouts with new top-level directories <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8985>
#snappy 2020-07-07
<mborzecki> morning
<pedronis> mborzecki: hi, I would appreciate reviews for #8907 and #8984
<mup> PR #8907: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907>
<mup> PR #8984: asserts: integer headers: disallow prefix zeros and make parsing more uniform <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8984>
<mborzecki> pedronis: hi, will do
<pedronis> thx
<pstolowski> morning
<mborzecki> mvo: pedronis: sent out the tiny spec for uc20 recovery on rpi, please take a look
<mborzecki> pedronis: mvo: i'll write down something similar about grub.cfg command line and share it with you guys
<pedronis> mborzecki: ok, I'll see when I can look at it
<pedronis> pstolowski: hi, #8907 needs a review, I also made #8984
<mup> PR #8907: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907>
<mup> PR #8984: asserts: integer headers: disallow prefix zeros and make parsing more uniform <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8984>
<pstolowski> pedronis: hi, will review today
<mvo> mborzecki: thank you
<zyga> good morning
<zyga> sorry for starting late, I woke up very early due to pain and then tired to sleep again after taking painkillers
<mup> PR core18#159 closed: 030-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/159>
<zyga> drat, lucy just walked over the keyboard and sigquit spread
<pstolowski> zyga: haha
<zyga> what are the chances...
 * zyga is debugging some weird failures
<zyga> mborzecki: something weird is going on in feature/track-launched-apps on tumbleweed
<zyga> on master that test passes
<zyga> on the feature branch it fails
<zyga> as if making the transient scope actually affected the existing tracking using the pid cgroup
<zyga> but why only on tumbleweed?
 * zyga investigates
<zyga> maybe they moved to cgroupv2?
<zyga> notably the test does not fail in the big branch where we use the new information for the same decision
<zyga> so maybe ...?
<zyga> baaah
<zyga> and now it passes
<zyga> what the heck?!
 * zyga thinks and tries to drink coffee
<mborzecki> ok, docs updated, now onto the reviews
 * sdhd-sascha Ooh, too much beer yesterday
<zyga> mborzecki: thanks
<mborzecki> zyga:  can you review https://github.com/snapcore/snapd/pull/8883 ?
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<zyga> mborzecki: after the call
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8883/checks?check_run_id=845292346 fails
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mborzecki> uh, 14.40
<mborzecki> pff fun
<zyga> re
<zyga> mborzecki: ping me when ready
<zyga> I'm debugging something related to old tracking
<ijohnson|sprint> mborzecki: took a real quick look at your doc
<mborzecki> ijohnson|sprint: hey, thanks
<zyga> eh, I add logging and now it passes
<zyga> there must be something racy there
<zyga> all right, it failed now
<zyga> ahh, I have a feeling I know what's wrong
<zyga> mborzecki: heh, start transient scope keeps on giving
 * zyga thinks
<zyga> thinks it's time to join the call
<mborzecki> heh ;)
<mup> PR snapd#8986 opened: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>
<ijohnson|sprint> zyga: I managed to fix my layout verification PR, it was as expected to use Layout.Path instead of the key in the map
<zyga> thanks!
<mvo> ondra: hey, I played with the latest go which has some linker improvements - the snap-bootstrap binary is down from 11mb stripped to 7.7mb stripped. so low mem snapd looks more feasible
 * zyga break for meds and some rest
 * cachio lunch
<pstolowski> cachio: +1 for your 'run nested' pr, please ping someone for 2nd review
<cachio> Psi-Jack, thanks
<Psi-Jack> What?
<ogra> just take the credit, don't complain ...
<cachio> Psi-Jack, sorry, was pstolowski but he quited
<Psi-Jack> lol
<cachio> Psi-Jack, I think it is the seconds time I do the same
<cachio> hehe
<Psi-Jack> Yep!
 * zyga tested 16.04 and 18.04 and systemd is not racy there
<zyga> trying 20.04 and adding workaround in software on our side
<zyga> 20.04 also passes, trying 20.10 which should be close to sid
<zyga> but this suggests either a regression in systemd
<zyga> or a "feature"
<zyga> 20.10 testing now..
<zyga> amd it seems to pass
<zyga> maybe we have patches in systemd
<zyga> jdstrand: ^ more tracking mystery
<zyga> going to test debian-9 vs sid
<sdhd-sascha> hey people, i really regret my level of alcohol, yesterday ;-) sorry ;-)
<ogra> it was rather obvious ð
<sdhd-sascha> ogra: thank you ;-) i try to go another way in future ;-)
<sdhd-sascha> did anybody mention the birds, and there song's? here in bavaria, they decrease volume. Then after lockdown they increase there songs... And now, they have learn both ;-)
<zyga> hmm, debian, even sid does not fail, so it is really just tumbleweed or was my sample size too small
<mup> PR snapd#8907 closed: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8907>
<sdhd-sascha> ogra: i share your love for graph-algos . But didn't have a hint how to optimize it?!
<cachio> zyga, hi
<zyga> cachio: hi
<cachio> I was checking and to run shellcheck on tools tests we need to install the shellcheck snap
<cachio> but for that we need to have the snap command available
<cachio> zyga, does it make sense?
<zyga> cachio: yes, I ran into this myself, it's not fortunate but perhaps unavoidable
<cachio> zyga, currently we prepare the suite with --prepare-suite-each-minimal-no-snaps
<zyga> cachio: alternatively, don't install it
<zyga> cachio: but install it only on one system
<zyga> cachio: and run shellcheck e.g. only on ubuntu 20.04
<zyga> this way we test on more systems
<zyga> and shellcheck at least once
<zyga> note that that suite does not have full snapd ready
<zyga> so it may not be possible to install snaps
<cachio> but then we also need to have snap to test the snaps tool that I just created
<sdhd-sascha> ooh, just a "deb" problem ? or others have that too?
<cachio> zyga, but for that I could install snapd and then purge
<zyga> cachio: hmmm
<zyga> cachio: perhaps the snap helper needs different strategy
<zyga> cachio: for generic helpers I would not install snapd
<zyga> cachio: perhaps the snap helper needs to live in main
<zyga> (as in tests)
<mup> PR snapd#8984 closed: asserts: integer headers: disallow prefix zeros and make parsing more uniform <validation-sets :white_check_mark:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8984>
<cachio> zyga, you need the test
<sdhd-sascha> cachio: i love purge... But there was a AI, which should sort a list. The AI has won, with purging the complete list ;-)
<cachio> zyga, so I'll move the test to main in that case
<zyga> cachio: I think that's better
<cachio> zyga, good
<zyga> thanks!
<zyga> what's the name of the tool btw?
<cachio> snaps-state
<ogra> schnaps-state ...
<cachio> zyga, but it could change
<zyga> cachio: do you want it to be on PATH?
<zyga> cachio: note that the naming rules differ between the two
<cachio> zyga, no
<cachio> just to be on path when we debug
<zyga> ok
<zyga> hmm?
<zyga> how would that work?
<cachio> I'll use it like $TESTSTOOLS"/snap-state
<cachio> so it should be fine
<zyga> I see
<zyga> if you want it on path it could be called tests.snap or something like that
<zyga> I think that's okay too
<zyga> no strong opinion either way
<cachio> ok, so far it is ok
<cachio> having this "$TESTSTOOLS"/snap-state is it ok
<cachio> zyga, also we could have a test targeted to ubuntu-18.04 which runs shellcheck for all the bash files in tools
<zyga> cachio: I think we kind of do that already (perhaps) via run-checks but yeah
<zyga> but I really prefer each tool test to check itself
<zyga> then it's obvious
<cachio> ok
<sdhd-sascha> zyga: cachio: hey, at high-level language, it's possible to write once, and work everywhere ;-)
 * sdhd-sascha short afk
<mup> PR snapcraft#3205 opened: spread tests: higher timeout for extension tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3205>
<zyga> jdstrand: o/
<zyga> jdstrand: some weird news
<zyga> https://github.com/snapcore/snapd/pull/8977#issuecomment-655057400
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> at this rate systemd will remove the API before it becomes reliable and we can merge it
<mup> PR snapd#8957 closed: tests: improve nested tests flexibility <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8957>
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/8977/commits/e2a21fbb16000ec87632f7f34a860d121933e1e9
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<mup> PR snapcraft#3206 opened: tests: add missing asserts to python unit tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3206>
<zyga> jdstrand: if you are keeping track, the patch to read is https://github.com/snapcore/snapd/pull/8977/commits/ee673c8a06c7f57e3a030bcf721c6d340e987303
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<cachio> zyga, updated #8949, #8950 and #8973
<mup> PR #8949: tests: new fs-state which replaces the files.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8949>
<mup> PR #8950: tests: new str-tool which replaces the strings.sh helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8950>
<mup> PR #8973: tests: moving journalctl.sh to a new journal-state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8973>
<lawl> hey, i'm trying to debug what i think is a race condition in snapd/ the pulseaudio snap-policy module. rebuilding a package with debug code everytime would be incredibly annoying though. So what i'm trying now is to start my app and then enter the sandbox with `nsenter` to give myself a shell in the snap application namespaces.
<lawl> However when I run `pacmd` i get `No PulseAudio daemon running, or not running as session daemon.`, any ideas how to better debug this/provide a simple repro?
<zyga> lawl: note that this is isufficient
<zyga> the namespace is not the whole sandbox
<zyga> if you want to be in the sandbox use snap run --shell
<zyga> in addition, many wrappers "patch" the environment for things that are in different location
<zyga> one such thing is the location of the pulse socket
<zyga> there's a bug tracking that
<zyga> in practice the socket is in $XDG_RUNTIME_DIR/..
<zyga> hope that hepls
<zyga> *helps
<lawl> yeah, XDG_RUNTIME_DIR was empty, i checked, i'll try `snap run --shell`, thanks
<lawl> ugh, it seems `pacmd` checks for a PID file and errors because it doesn't find it, that's annoying.
<zyga> if that helps look at snapd tree
<zyga> at tests/main/interfaces-pulseaudio/task.yaml
<lawl> nope, really seems to be a specific check in `pacmd` that's failing, test doesn't seem to call `pacmd`.
<lawl> I'll figure something out.
<jdstrand> zyga: sorry, sprinting, but erf
<jdstrand> zyga: is there an upstream bug?
<lawl> Or, actually, can anyone point me to the pulseaudio `module-snap-policy`? I've tried google the source but couldn't find it, patching that with debug output might actually be easier
<zyga> jdstrand: I didn't file one yet
<zyga> jdstrand: but it looks like it
<zyga> lawl: most likely in pulseaudio deb in ubuntu
<zyga> lawl: 0700-modules-add-snappy-policy-module.patch
<zyga> pastebin https://paste.ubuntu.com/p/GKMcz9ZPKj/
<lawl> ah, thanks!
<mup> PR snapcraft#3205 closed: spread tests: higher timeout for extension tests <tooling> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3205>
<lawl> ahh, there we have it `snapd_client_get_snap_async` in `check_access`. it fetching access permissions async and not receiving them fast enough would explain exactly what i'm seeing
<jdstrand> lawl: there are a couple of patches
<jdstrand> one for the infra to do the mediation and one for the policy, iirc
 * jdstrand gets url
<lawl> i see hi jdstrand btw. we already talked briefly on the forums about classic mode :)
<lawl> i'm pretty sure the patch already linked is one one causing the issue, as i also see `AppArmor profile could not be retrieved.` spammed in the logs, which seems to come from this patch
<jdstrand> lawl: ah, ok. if it isn't working for you, I suggest filing a bug at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+filebug
<lawl> i can file a bug, but i don't have a small repro, i can provide my packaged snap i suppose
<lawl> but i was hoping to provide a minimal repro
 * jdstrand nods
<jdstrand> 'AppArmor profile could not be retrieved' is from a call to aa_gettaskcon(client->creds.pid, &context, NULL)
<jdstrand> the error handling isn't looking at errno (it would be nice if the pa_log_error() included that)
<lawl> yeah, so the bug is that PA reports permission denied and it spams this apparmor log the first time i start my snap after snapd is restarted or the system reboots
<jdstrand> http://manpages.ubuntu.com/manpages/focal/man2/aa_getcon.2.html show the error conditions
<lawl> i'll play around a bit with the patch to confirm my suspicions from glancing over the source in a VM tmrw and then file a bug
<jdstrand> lawl: a description of the problem in a bug and saying you'll try to find a simple reproducer might be enough. jamesh may be able to spot the issue from a good description
<jdstrand> cool, thanks!
<jdstrand> the more info the better :)
<ijohnson|sprint> cmatsuoka: did you want to review https://github.com/snapcore/snapd/pull/8956 ? it has 2 +1s and is green so I'm inclined to merge it :-)
<mup> PR #8956: tests/core/gadget-update-pc: port to UC20 <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8956>
<sdhd-sascha> It is not the software. And it is not the Hardware. It is bptj&
<cmatsuoka> ijohnson|sprint: go ahead, I read it and don't have further comments
<ijohnson|sprint> cmatsuoka: ack
<cmatsuoka> in fact I should have approved it a few days ago, I probably closed the browser tab and didn't return
<mup> PR snapd#8956 closed: tests/core/gadget-update-pc: port to UC20 <UC20> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8956>
<mup> PR snapcraft#3204 closed: Improvements to the flutter plugin <bug> <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3204>
<mup> PR snapcraft#3206 closed: tests: add missing asserts to python unit tests <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3206>
#snappy 2020-07-08
<mborzecki> morning
<mup> PR snapd#8962 closed: tests: allow to add a new label to run nested tests as part of PR validation <Run nested> <Skip spread> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8962>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: is it as cold at your place?
<mvo> good morning pstolowski and mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: i need to push one more tweak to https://github.com/snapcore/snapd/pull/8883
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mvo> mborzecki: can you +1 8883 if you are happy with it?
<mvo> (please :)
<mup> PR core20#75 opened: 030-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <https://github.com/snapcore/core20/pull/75>
<mborzecki> mvo: i'll push the last tweak, let me know what you think about it
<mvo> mborzecki: ok
<mborzecki> mvo: funny, that since we moved DEBHELPER in postrm earlier, there's no systemd daemon-reload happening after we remove the service/mount units
<mborzecki> btw. zyga wrote me he's had a hard night and it's fully up yet
<mborzecki> mvo: pushed https://github.com/snapcore/snapd/pull/8883/commits/f1897983d9d79b96d0b9306cf4fdf9711d729f46
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mborzecki> taking the kids for a dentist checkup, back in 1h or so
<pstolowski> mborzecki: yeah, 14C
<zyga> hello
<zyga> sorry for starting late, I'm very tired lately
<zyga> it's hard to sleep
<mvo> mborzecki: thank you
<zyga> hey mvo, good morning :)
<mvo> mborzecki: nice one!
<mvo> zyga: good morning
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8977 needs reviews
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> mborzecki: it's somewhat more complex than initially assumed but I think what is there now is acceptable
<zyga> PSA: it seems that actions are buggy wrt refreshing the tree sometimes
<zyga> pushing new patches clearly seems to test older versions
<zyga> I will update the workers to use the latest stable agent later today
<zyga> mborzecki: I will dig into systemd to find and report the bug
<mborzecki> re
<mborzecki> mvo: looks like it's green on ubuntu & debian
<mborzecki> zyga: pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8883  ?
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<zyga> mborzecki: sure
<mvo> mborzecki: thank you, yeah, it needs review(s)
<zyga> mborzecki: I think this is wrong
<zyga> mborzecki: we placed debhelper there for a reason
<zyga> mborzecki: remember that stopping systemd units of snaps may require snapd to be up
<pstolowski> yep
<zyga> mborzecki: I think it needs to be more elaborate :/
<zyga> mborzecki: also remember that snap reexec will come into play
<zyga> so we must not unmount core/snapd before stopping any service units
<zyga> as those will wait on system key mismatch
<zyga> perhaps it's time to bail out of the debhelper helper entirely
<zyga> or move it to the very bottom after we've done everything ourselves
<zyga> mborzecki: does this make sense?
<pstolowski> i'm afraid i cannot comprehend possible effects of this PR
<zyga> mborzecki: added a comment
<pstolowski> me too
<mborzecki> zyga: hm snapd.socket/service are masked, so the stop comand, even if it tries to poke snapd, should fail right away
<mborzecki> zyga: iow, there's no socket to talk to
<mborzecki> zyga: and since the units are masked, they won't be started by accident
<zyga> mborzecki: masking is fine, but I think the remove sequence should first reduce the system to equivalent of "snap remove --all-the-snaps"
<zyga> and then remove just snapd as it does now
<mborzecki> zyga: hm but isn't that what it does currently?
<zyga> not quite, we never remove the snaps, we just unmount and delete them (e.g. hooks don't run)
<zyga> but on a bigger note, I strongly think we should not stop snapd while we do the purge, only at the very end
<zyga> could purge really be "snap remove --purge --all-snaps" followed by ##DEBHELPER## ?
<mborzecki> zyga: not really, there's no snap command at this point
<zyga> because .postrm?
<mborzecki> yup
<zyga> I see
<zyga> I mean we could adjust prerm/postrm
<mborzecki> zyga: you could do it in prerm, but snapd is on it's way out, so why bother?
<zyga> mborzecki: because there's one implementation then
<zyga> not two
<zyga> mount namespaces are discareded, hooks run
<zyga> data is removed
<zyga> right now all the shell scripts need to reimplement that
<zyga> in addition, snapd should stop / abort all background refresh tasks
<mborzecki> zyga: what you're describing needs to run in prerm
<zyga> I agree
<zyga> I guess I'm saying we are here because what we got is complex and buggy
<zyga> and I'm looking for a way to make it simple and not buggy
<zyga> by piggy-backing on the existing machinery
<zyga> in addition, this needs to be implemented in all the distro scripts
<zyga> one other thing prerm could do is to ask you if you want to retain snapshots or not
<mborzecki> zyga: so first we probably need ot know why postrm cleans up the stuff and not prerm
<zyga> (debconf)
<zyga> good point
<mborzecki> zyga: secodnly, can we expect snapd to be running at all in prerm
<zyga> it may be running or not
<zyga> if it doesn't run we could just not remove things
<zyga> it's not the best outcome but I think that's unavoidable
<mborzecki> zyga: but we can't leave things behind, can we? that's the whole point of purge aiui
<zyga> well, it depends
<zyga> I think we should take a step back
<zyga> and look at what those scripts should do
<zyga> and separately fix the immediate problem
<zyga> where purge is racy
<zyga> perhaps we come to a conclusion that problem #2 is really problem #1
<zyga> perhaps there's a shorter intermediate path we can take
<mborzecki> zyga: hm, tbh i thin i can move the debhelper in postrm back, it's not really changing anything
<zyga> mvo: ^ perhaps we need your opinion and wisdom
<mvo> zyga: slightly busy right now .( sorry, I can have a look in a bit, could you summarzize the input in the PR?
<zyga> mvo: I did already, we're wondering what to do about the pre/post rm scripts
<zyga> mborzecki: are centos8 failures expected now?
<mborzecki> zyga: something new?
<zyga> not specific, just mostly red tests across PRs
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8981#pullrequestreview-444566073
<mup> PR #8981: boot, bootloader: query kernel command line of run mod and recovery mode systems <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8981>
<pedronis> mborzecki: I did a pass on #8947, some questions/comments there
<mup> PR #8947: many: update managed boot config when refreshing snapd <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8947>
<mborzecki> pedronis: thanks
<mborzecki> zyga: thanks for the review too
<pedronis> mborzecki: pstolowski: I made the follow to my PRs: #8987
<mup> PR #8987: asserts: small improvements and corrections for sequence-forming assertions' support <Created by pedronis> <https://github.com/snapcore/snapd/pull/8987>
<pstolowski> ack
<mup> PR snapd#8987 opened: asserts: small improvements and corrections for sequence-forming assertions' support <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8987>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8979#pullrequestreview-444594855
<mup> PR #8979: tests: more checks in core20 early config spread test <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8979>
<pstolowski> ty
<zyga> I need reviews for 8977
 * zyga dives into https://github.com/snapcore/snapd/pull/8843
<mup> PR #8843: [RFC] many: export tools from core/snapd to mount namespaces <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8843>
<zyga> eh, conflicts
<zyga> snapstate_test.go conflicts are fun
<mup> PR snapd#8985 closed: snap/validate.go: disallow snap layouts with new top-level directories <Bug> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8985>
<zyga> brb, break
<mborzecki> zyga: tumbleweed seems to be failing, xdg-desktop-portal package is no longer present?
<zyga> dunno
<zyga> maybe a new image?
<zyga> ok, coffee and back in a moment
<zyga> gotta rebase that thing
<zyga> re
<pstolowski> doh, we're hitting 'unknown nfs option' error on debian sid on 2.45, that was fixed in master some time ago
<mborzeck1> pfff power outage
<mborzeck1> ofc, synchronized home dirs like an hour ago, so missing the latest code changes
<zyga> synchronized?
<zyga> as in sync?
<mborzeck1> yeah
<zyga> as in write from ram to disk?
<mborzeck1> zyga: no, as in synchronize the content of $HOME between my laptop and the desktop
<zyga> ahh
<mup> PR core20#75 closed: 030-fix-timedatectl.chroot: fix quoting issues <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/75>
<mborzeck2> pfff
<zyga> hmm?
<mborzeck2> power comes back, and it's off a minute later
<mborzeck2> and there's no even a thunderstorm or strong wind
<zyga> haha
<zyga> it's very common when guys are fixing power lines
<mup> PR snapd#8988 opened: many: use more specific check for unit test mocking <Bug> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8988>
 * zyga has a cool idea  :)
<realtime-neil> How does one build snapcraft from source?
<mup> PR snapd#8981 closed: boot, bootloader: query kernel command line of run mod and recovery mode systems <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8981>
<zyga> drat,
 * zyga ran out of space
<zyga> realtime-neil: hey
<zyga> I presume with snapcraft but for best advice please ask on the #snapcraft channel
<realtime-neil> zyga: whoops, sorry
<diddledan> realtime-neil, do you mean the snapcraft utility to build snaps or the snapd daemon that mediates a system and the snaps installed upon it?
<diddledan> for snapcraft the utility to build snaps, it's python so there isn't much building required - the best way to build that is to use snapcraft itself to build it into a snap (chicken and egg, meet catch 22)
<realtime-neil> diddledan: probably all of the above, modulo the topological sort along dependencies.
<realtime-neil> diddledan: what would the workflow look like for someone trying to bootstrap from, say build-essential ?
<zyga> realtime-neil: what are you trying to achieve?
<diddledan> it depends what you want to work on
<zyga> note that snapcraft is now a snap, not a classic package
<zyga> so it's not using the traditional methods of building
<realtime-neil> zyga: yeah, I'm noticing that from the more recent (early 2019) tutorials I find.
<realtime-neil> zyga: I'm trying to achieve better understanding I like knowing where these things come from
<zyga> realtime-neil: well, that's pretty easy, both are in github.com/snapcore/{snapcraft,snapd}
<zyga> one is python the other is go, mostly
<zyga> each with their own deps
<zyga> I assume you understand the difference between those but ask if you want to know more
<zyga> snapd is built into several distinct ways depending on the purpose
<zyga> I don't know much about snapcraft though
<realtime-neil> you assume correctly, and I was having trouble finding those repos from the snapcraft.io site, so thanks
<zyga> cachio: standup
<diddledan> no, sit down!
<mup> PR snapd#8987 closed: asserts: small improvements and corrections for sequence-forming assertions' support <validation-sets :white_check_mark:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8987>
<mup> PR snapd#8989 opened: osutil/systemd: add new pkg and systemd.EscapePath <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8989>
<mborzecki> do we ahve grub-editenv packaged as a snap maybe?
<mborzecki> s/ahve/have/
<mup> PR snapd#8989 closed: osutil/systemd: add new pkg and systemd.EscapePath <Simple ð> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8989>
<pedronis> pstolowski: mborzecki: thanks for the reviews of the validation-set PRs
<mborzecki> pedronis: yw
<zyga> mborzecki: can you re-review https://github.com/snapcore/snapd/pull/8977
<mup> PR #8977: cmd/snap: track started apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/8977>
<zyga> I'd love to make progress on that front and I think this step is ready
<mup> PR snapd#8990 opened: systemd/escape: fix issues with "" and "\t" handling <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8990>
 * cachio lunch
<pstolowski> pedronis: yw
<pstolowski> hmm i could swear we had a helper for human-friendly unit (kB, mB...) output but cannot find it
<pstolowski> maybe i confused it with helpers for time
<pstolowski> ah, got it, SizeToStr in strutil
<mup> Bug #1886840 opened: classic confined snap can't access audio devices <Snappy:New> <https://launchpad.net/bugs/1886840>
<mup> Bug #1886840 changed: classic confined snap can't access audio devices <Snappy:New> <https://launchpad.net/bugs/1886840>
<mup> Bug #1886840 opened: classic confined snap can't access audio devices <Snappy:New> <https://launchpad.net/bugs/1886840>
<jdstrand> oSoMoN: hey, fyi, 20200706-1602UTC is now in prod (thanks roadmr!) so you should be able to use system-packages-doc now
<oSoMoN> jdstrand, excellent, thanks!
 * cachio -> kenesiologist
<mup> PR snapd#8991 opened: tests: preinstall shellcheck and run tests on focal <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8991>
<mup> Bug #1886840 changed: classic confined snap can't access audio devices <snapd:New> <https://launchpad.net/bugs/1886840>
<mup> PR snapcraft#3207 opened: packaging: use PEP-440 compliant versioning for python & snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3207>
<mup> PR snapcraft#3207 closed: packaging: use PEP-440 compliant versioning for python & snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3207>
<mup> PR snapcraft#3208 opened: snap: set PATH for snapcraft command <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3208>
#snappy 2020-07-09
<mborzecki> morning
<pstolowski> morning
<zyga> good morning
<mvo> good morning pstolowski and zyga
<zyga> hey, how is the sprint progressing?
<mvo> zyga: good so far
<mup> PR snapd#8990 closed: systemd/escape: fix issues with "" and "\t" handling <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8990>
<mborzecki> hello guys
<mup> PR snapd#8988 closed: many: use more specific check for unit test mocking <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8988>
<pstolowski> o/
<mborzecki> it'd be so nice if go had a way to check whether the binary is runing as part of go test invocation
<mvo> good morning mborzecki
<zyga> snap run --strace does not support snap aliases
<zyga> aliased snaps are just ignored
<zyga> and strace static is out of date and needs updates
<zyga> mvo: are you the only one who can update strace static?
<zyga> mborzecki: we have that
<mborzecki> zyga: see #8988
<mup> PR #8988: many: use more specific check for unit test mocking <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8988>
<zyga> ah
<mborzecki> we have something, but it's not necessarily 100% correct ;)
<mborzecki> wish there was something in go runtime/stdlib to tell you that
<zyga> meh, I see
<jamesh> pedronis: I know you're busy at the sprint, but I'd appreciate some comment on https://forum.snapcraft.io/t/proposal-new-rest-api-for-theme-installation/18732 -- particularly the authentication section.
<jamesh> if you have time at some point, any feedback would be welcome
<pedronis> jamesh: yes, I'll try to look at it today
<jamesh> pedronis: cheers.
<zyga> hmm
<zyga> brb, small break
<zyga> re
<mup> PR snapd#8992 opened: boot: better naming of helpers for obtaining kernel command line <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8992>
<mup> PR snapd#8993 opened: bootloader, boot: compose kernel command line passed by grub bootloader <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8993>
<mborzecki> meh, no grub-editenv means i need to reboot, go to grub cmdline, load_env myself, edit, save_env, reboot
<ijohnson> mborzecki: I thought there was an issue for adding those to core20 snap ?
<ijohnson> mborzecki: did they not get added to the core20 snap?
<mborzecki> ijohnson: i don't see it on my $PATH
<mborzecki> actually not in the snap either
<ijohnson> ah yeah that's unfortunate
<ijohnson> probably they should be added to core20, are they in core18?
 * mborzecki checks quickly
<mborzecki> ijohnson: nope, only in core
<ijohnson> ah interesting
<ijohnson> perhaps it was intentionally left out of core18 then
<mborzecki> heh, was suppsoed to do bug triage today
<zyga> mborzecki: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/8
<zyga> can you tell me if this makes sense to you?
<zyga> hmm, some problems with parallel instances https://forum.snapcraft.io/t/parallel-instances-cant-remove-cant-connect-interfaces-cant-use-layouts-env-vars-are-wrong/18696
<zyga> small break and then back to coding
<zyga> and maybe time for meds
<zyga> eh
<zyga> ok, 50C now, no longer burning my legs
 * pstolowski lunch
<zyga_> mborzecki do you have time to review snap run changes today?
<mborzecki> zyga-mbp: i can certainly try
<zyga-mbp> please :)
<zyga-mbp> I would move a lot with that
<mup> PR snapd#8992 closed: boot: better naming of helpers for obtaining kernel command line <Simple ð> <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8992>
 * zyga-mbp reboots to tweak the kernel
<zyga-mbp> brb
<zyga-mbp> well... the vm that is
<mup> PR snapcraft#3208 closed: snap: set PATH for snapcraft command <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3208>
<mup> PR snapd#8994 opened: tests: fix some snapstate tests to use pointers for snapmgrTestSuite <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8994>
<pstolowski> zyga-mbp: ^ can you tak a look, it's trivial
<pstolowski> ?
<zyga-mbp> sure
<zyga-mbp> looking now
<pstolowski> ty
<zyga-mbp> done
 * zyga-mbp -> coffee
<mup> PR snapd#8994 closed: tests: fix some snapstate tests to use pointers for snapmgrTestSuite <Simple ð> <Created by stolowski> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8994>
#snappy 2020-07-10
<mborzecki> morning
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> mvo: hey, the last day of sprint!
<mvo> mborzecki: good morning!
<mvo> mborzecki: yeah
<mup> PR snapd#8979 closed: tests: more checks in core20 early config spread test <Run nested> <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8979>
<mborzecki> zyga wrote me he's off today
<jamesh> mborzecki: I think this might be the root cause of that parallel install problem reported on the forum: https://forum.snapcraft.io/t/parallel-instances-cant-remove-cant-connect-interfaces-cant-use-layouts-env-vars-are-wrong/18696/8?u=jamesh
<jamesh> i.e. whether a non-instance keyed version of the snap is installed or not
<mborzecki> jamesh: we ensure that my-snap directory exists when  my-snap or my-snap_* gets installed
<mborzecki> jamesh: or at least we did and had some tests for it, let me double check the tests are actually testing the right thing
<mborzecki> jamesh: fwiw, quick install of a random snap with instance key creates the snap-name (without instance key) directory
<jamesh> mborzecki: it certainly looks like the $SNAP mount is failing somehow, based on his message
<mborzecki> jamesh: asked more questions there, i suspect it's something else being broken here
<mborzecki> sadly zyga is off today
<mup> PR snapd#8995 opened: osutil: add CheckFreeSpace helper (1/N) <Disk space awareness> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8995>
<mborzecki> seriously it's hard to tell when soemone is trolling or being misinformed
<mborzecki> running spread tests for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1887134
<mup> Bug #1887134: Purging of snapd package should remove all files in / installed by snaps <amd64> <apport-bug> <bionic> <eoan> <focal> <groovy> <xenial> <snapd (Ubuntu):In Progress by maciek-borzecki> <https://launchpad.net/bugs/1887134>
<mborzecki> quick errand, back in 30
<ijohnson> do we have anywhere in the snapd codebase where we wait for systemd units to become active ?
<ijohnson> mborzecki: do you know ?
<ijohnson> pstolowski: or maybe anything we do in managing snap services? I seem to remember we did something like this somewhere but I can't find it
<pstolowski> ijohnson: one sec
<mborzecki> ijohnson: let me check, iirc we had --no-wait for some actions
<ijohnson> haha thanks folks
<mborzecki> ijohnson: but systemctl start waits for unit to become active (where the meaning of active depends on the type of unit)
<ijohnson> there's systemd.IsActive
<mborzecki> that's a thin wrapper around systemctl is-active
<ijohnson> mmm so actually I'm using systemd-mount from the initramfs
<ijohnson> and looking at the docs it says this
<ijohnson> > the job will be verified, enqueued and systemd-mount will wait until the mount or automount unit's start-up is completed.
<ijohnson> it's not clear to me though that means the unit is active, it kinda seems like that means the unit exists, not necessarily that the mount is done
<mborzecki> ijohnson: there's StartNoBlock but it's used only for snapd services on core18+
<mborzecki> ijohnson: iirc for mounts we have some special handling in link.go that double checks that snap metadata is present at the mount location
<ijohnson> mmm ok, yeah it seems like we don't have what I thought we had
<ijohnson> thanks for looking!
<mborzecki> ijohnson: err, it's in snapstate/handlers.go in doMountSnap
<mborzecki> ijohnson: there's a for loop that retries readInfo right after SetupSnap
<mup> PR snapd#8996 opened: packaging, cmd/snap-mgmt, tests: remove modules files on purge <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8996>
<mborzecki> cmatsuoka: what input the new split helper fails on?
<cmatsuoka> mborzecki: ==a, a==, maybe a lone =?
<mborzecki> haha
<mborzecki> let me try that
<cmatsuoka> I mean, it's not that it fails, but I don't know what the kernel thinks about that
<mborzecki> cmatsuoka: me neither, probably ignores that because what else can you do at this point
<cmatsuoka> probably it will ignore all ill-formed parameters
<cmatsuoka> well, or maybe parse it partially, who knows
<cmatsuoka> s/it/them/
<mup> PR snapcraft#3209 opened: extensions/desktop/common: add snapd gl vdapu dir to LD_LIBRARY_PATH <Created by anonymouse64> <https://github.com/snapcore/snapcraft/pull/3209>
<ogra> ijohnson, ^^^ that should be vdpau not vdapu ...
<ijohnson> man I open one PR to snapcraft and 2 people tell me it's got a typo within less than 2 minutes
<ogra> teamwork !
<mup> PR snapd#8997 opened: packaging: add "ca-certificates" to build-depends <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8997>
<mup> PR snapd#8998 opened: tests/cmd/snap-bootstrap/initramfs-mounts: fix typo <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8998>
<mup> PR snapcraft#3210 opened: docker: install snapd dependency <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3210>
<mup> PR snapd#8997 closed: packaging: add "ca-certificates" to build-depends <Simple ð> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8997>
<mup> PR snapd#8983 closed: tests: add tests.cleanup helper <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8983>
<mup> Bug #1887204 opened: Snap is not clear about partial strict confinement <Snappy:New> <https://launchpad.net/bugs/1887204>
<mup> Bug #1887204 changed: Snap is not clear about partial strict confinement <Snappy:New> <https://launchpad.net/bugs/1887204>
<mup> Bug #1887204 opened: Snap is not clear about partial strict confinement <Snappy:New> <https://launchpad.net/bugs/1887204>
#snappy 2020-07-11
<mup> Bug #1887217 opened: snapd auto update is way too aggressive <Snappy:New> <https://launchpad.net/bugs/1887217>
<mup> Bug #1887238 opened: snap fails to reload udev rules in docker <docker> <udev> <Snappy:New> <https://launchpad.net/bugs/1887238>
<mup> PR snapd#8999 opened: strutil: add a helper for parsing kernel command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8999>
<phunyguy> Greetings. Is it possible to make a snap package depend on a systemd unit being started?
<phunyguy> oh yay, didn't realize there is a systemd unit already for snap packages.  I can use that to override in a dep.
<phunyguy> yay that worked.
