[05:55] <zyga> good morning
[06:01] <morphis> zyga: morning!
[06:02] <morphis> zyga: did you find any solution for the "cannot find package "golang.org/x/crypto/ssh/testdata"" error on travis?
[06:59] <morphis> ogra_: ping
[07:16] <zyga_> morphis: hey
[07:16] <zyga_> hey ara :)
[07:16] <ara> morning zyga :)
[07:16] <morphis> zyga: hey :-)
[07:16] <zyga> morphis: I commented on https://github.com/snapcore/snapd/pull/3271 - trivial stuff if you want to apply that
[07:16] <mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
[07:16]  * zyga goes back to reviews
[07:17] <morphis> zyga: what is the difference between details and description?
[07:17] <morphis> ah looks like I did that wrong until now
[07:18] <morphis> and spread doesn't complain about details:
[07:18] <morphis> s/details:/description:/
[07:22] <zyga> morphis: it's not used at all
[07:22] <morphis> zyga: yeah, just saw that I used description: in all my previous MPs
[07:22] <zyga> morphis: but you didn't give any details or description so I wrote some :)
[07:22] <zyga> morphis: it's a purely human-readable thing
[07:22] <morphis> will clean that up
[07:23] <zyga> morphis: thanks!
[07:37] <morphis> zyga: fixed https://github.com/snapcore/snapd/pull/3271
[07:37] <mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
[07:37] <zyga> morphis: thank you
[07:58] <morphis> zyga: also updated https://github.com/snapcore/snapd/pull/3274
[07:58] <mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
[08:00] <zyga> morphis: great, thank you
[08:01] <morphis> that one still needs conversion of all other tests not converted yet but once I get a pass from travis I will do that
[08:02] <zyga> morphis: replied
[08:02] <zyga> morphis: one thing about !
[08:03] <morphis> fixed
[08:03] <zyga> morphis: great!
[08:19]  * zyga -> coffee
[08:19] <zyga> brb
[08:23] <ali1234> morning. can i get some help finishing my sigrok snap and getting it into the store?
[08:23] <zyga> ali1234: hey, what kind of help do you need
[08:24] <ali1234> it works with strict confinement, i just need to finish off the house keeping: build dependencies, version number etc
[08:24] <ali1234> and get it uploaded
[08:24] <ali1234> cleanbuild still does not work for me
[08:24] <ali1234> also i have a weird bug where Qt apps are not themed correctly, but that affects every snap afaict
[08:25] <ali1234> every snap on my system i mean
[08:25] <ali1234> https://github.com/ali1234/mysnaps/blob/master/sigrok/snapcraft.yaml is what i have
[08:27] <ali1234> oh, also i'm not sure why i need the network plug. libusb uses netlink and raw-usb alone isn't enough to make it work
[08:27] <zyga> ali1234: themes are hard :) https://forum.snapcraft.io/t/use-the-system-gtk-theme/496/4
[08:27] <ali1234> oh, so its because i don't use the default theme?
[08:28] <ali1234> okay, well i guess that's the least important issue
[08:37] <zyga> ali1234: yes, because the theme in the snap is not the same as the themes in the system
[08:37] <zyga> ali1234: can you share dmesg | grep DENIED
[08:38] <ali1234> for what? the netlink thing?
[08:38] <zyga> ali1234: and also dmesg | grep type=1326
[08:38] <zyga> ali1234: this will show any apparmor and seccomp denials
[08:38] <ali1234> if i have the raw-usb plug but not the network plug i get: type=1400 audit(1494097705.817:107): apparmor="DENIED" operation="create" profile="snap.sigrok.sigrok-cli" pid=8274 comm="sigrok-cli" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
[08:38] <zyga> so we can figure out what sigrok is doing that needs more interfaces
[08:39] <zyga> aha so NETLINK_KOBJECT_UEVENT
[08:39] <ali1234> it may be that sigrok supports analyzers on ethernet and is trying to scan for them
[08:39] <ali1234> i am not sure, i only have a usb one to test with
[08:39] <zyga> the good news is that we have some nice netlink interface lately
[08:41] <zyga> even if sigrok requires a dedicated interface one can be crafted very quickly
[08:41] <ali1234> as i said, it works with the network plug
[08:42] <ali1234> and sigrok does support ethernet devices according to the hardware page
[08:43] <ali1234> i think it can use rs232 devices as well
[08:50] <ogra_> morphis, yes ?
[08:53] <morphis> ogra_: I saw https://paste.ubuntu.com/24535422/ in a spread test this morning
[08:54] <morphis> ogra_: any idea?
[08:54] <ogra_> morphis, ouch ... looks like there was a newer shadow version uploaded to the archive ... overriding the PPA
[08:54] <morphis> uups
[08:57] <morphis> zyga: looks like you referenced the wrong link in https://github.com/snapcore/snapd/pull/3277#issuecomment-299792600
[08:57] <mup> PR snapd#3277: cmd/snap, client: add "whoami" command <Created by chipaca> <https://github.com/snapcore/snapd/pull/3277>
[08:58] <zyga> aha, thanks
[08:58] <morphis> ogra_: if you want more details https://travis-ci.org/snapcore/snapd/builds/229850432?utm_source=github_status&utm_medium=notification
[08:58] <ogra_> morphis, i dont need any details ... i need to merge a package :P
[08:58] <morphis> :-)
[08:58] <zyga> corrected :)
[09:02]  * ogra_ sighs ... and indeed its a manual merge, the CVE fix touches the same file
[09:11] <abeato_> ogra_, hey, is there any way I can avoid starting console-conf on first run?
[09:13] <ogra_> abeato_, i think you can touch some file but not sure what the path was ... perhaps mwhudson can help
[09:15] <morphis> abeato_: there is, have a look at our tests-extras repo
[09:15] <ogra_> (not sure how the getty setup reacts on that though ... there is some special setup to print the IP and ssh keys)
[09:15] <morphis> abeato_: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/tests-extras/tree/create-image-scripts/create-image.sh#n135
[09:15] <ogra_> (and to prevent spawning a login prompt)
[09:16] <abeato_> morphis, I see, thanks
[09:16] <abeato_> ogra_, well, provided I get a shell I can manage :)
[09:17] <ogra_> if you would that would be a bug :)
[09:17] <ogra_> you shouldnt get a shell login offered without configured user
[09:18] <abeato_> yeah, I will try to create one with a system-user assertion
[09:18] <ogra_> yeah, that shoudl work
[09:26] <mwhudson> abeato_, ogra_: /var/lib/console-conf/complete i think
[09:27] <abeato_> mwhudson, great... how can I some debugging for console-conf, anyway?
[09:31] <ali1234> what approach should i take to automatic building and versioning?
[09:31] <ali1234> upstream has this repo that contains build scripts for various platforms: http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=cross-compile;h=e3013fd578b6d07b55ca32a4c43d082e36cc5e24;hb=HEAD
[09:32] <ali1234> as you can see, they already have an appimage
[09:32] <ali1234> it would make sense to put the snapcraft.yaml in here i think
[09:32] <ali1234> but it builds from several other repos
[09:36] <zyga> ali1234: you can look at build.snapcraft.io
[09:36] <zyga> ali1234: it's a free service that's very useful :-)
[09:36] <ali1234> upstream does not use github though
[09:37] <zyga> Chipaca: hey
[09:37] <zyga> Chipaca: do you know if any of the sprint-going people will be around today?
[09:37] <ali1234> i assume it does the same thing as https://snapcraft.io/docs/build-snaps/ci-integration
[09:38] <Chipaca> zyga: I don't
[09:38] <zyga> ali1234: ci integration is sligthly different but I'm not actively using it myself so I could be worng
[09:38] <Chipaca> zyga: I do know I'm about to go off to a doctor's appointment :-)
[09:40] <zyga> Chipaca: take care! Look after yourself!
[09:40] <Chipaca> zyga: this is the physio \o/
[09:40] <Chipaca> anyway, should be back for the standup
[09:40] <zyga> sounds good
[09:41] <ali1234> is it still a thing to prefix your name on packages to prevent collisions?
[09:41] <mwhudson> abeato_: painfully
[09:42] <abeato_> lol
[09:42] <mwhudson> abeato_: ui things get debugged in dry-run mode
[09:42] <abeato_> yes, that is something I suspected...
[09:42] <mwhudson> more complicated things mostly by staring at the log file
[09:42] <abeato_> mwhudson, it is more about some issue with handling interfaces
[09:42] <zyga> ali1234: if this will be the official snap I'd skip the prefix
[09:42] <ali1234> it wont be, i am not upstream
[09:42] <zyga> ali1234: especially if it comes from the upstream repository
[09:42] <mwhudson> abeato_: as in NICs?
[09:42] <zyga> ali1234: aha
[09:42] <zyga> ali1234: maybe try talking to them
[09:42] <zyga> ali1234: it's just packaging :)
[09:42] <abeato_> mwhudson, yes
[09:42] <ali1234> i have done
[09:42] <zyga> ali1234: and they may like it
[09:43] <ali1234> they did like it
[09:43] <zyga> ali1234: if they commit the snapcraft.yaml into their tree
[09:43] <ali1234> they want to see it working
[09:43] <mwhudson> abeato_: fun times
[09:43] <abeato_> mwhudson, where is the log stored for console-conf?
[09:43] <zyga> ali1234: I don't see why it should be prefixed
[09:43] <mwhudson> abeato_: /var/log/console-conf
[09:43] <ali1234> i added my repo on build.snapcraft.io and it says it does not have a snapcraft.yaml
[09:43] <ali1234> this is not true, it actually has three
[09:43] <abeato_> mwhudson, ok, thanks
[09:44] <zyga> ali1234: it looks at a specific location, where are your snapcraft.yaml files?
[09:44] <zyga> ali1234: perhaps ask in the forum (forum.snapcraft.io) as the people working on this are in other timezones
[09:44] <ali1234> well the sigrok one is in sigrok/snapcraft.yaml
[09:44] <ali1234> if it goes in upstream it will be in cross-compile/snap/snapcraft.yaml
[09:45] <mwhudson> abeato_: you could try using a system user assertion to have an account created on first boot and then poke around more interactively
[09:45] <zyga> ali1234: AFAIR it can be in (paths) snap/snapcraft.yaml or snapcraft.yaml relative to the root of the project
[09:45] <mwhudson> but that's a bit hairy too
[09:45] <zyga> ali1234: it cannot be in an arbitrary location
[09:45] <ali1234> okay i will fork upstream repo and try with that
[09:45] <abeato_> mwhudson, yes, that is something I want to do too
[09:45] <mwhudson> abeato_: what sort of problem are you having?
[09:46] <abeato_> mwhudson, the one signing the system-user assertion should be the same that signed the gadget snap, right?
[09:46] <abeato_> mwhudson, some issue with interface configuration, it looks apparently configured but I cannot reach the store
[09:46] <mwhudson> abeato_: s/gadget snap/model assertion/ i think, but yes
[09:46] <abeato_> mwhudson, yes, model :)
[09:47] <mwhudson> abeato_: ugggh
[09:47] <ali1234> although it won't work for upstream since it isn;t on github
[09:47] <ogra_> well, unconfigured interfaces still run a dhclient
[09:47] <ogra_> even before cvonsole-conf ever comes up
[09:48] <abeato_> mwhudson, not sure if maybe the issue comes  from some p2p0 interface that is around
[09:48] <abeato_> mwhudson, ogra_ http://paste.ubuntu.com/24535879/
[09:48] <ogra_> looks like you cant reach your nameserver
[09:49] <mwhudson> yes i guess you should check for broken / bogus dhcp servers :)
[09:49] <zyga> ali1234: where is upstream?
[09:49] <abeato_> ogra_, in fact I can ping the device when I am in the "network connections" screen, but after "configuring" the network, the IP gets lost
[09:49] <ali1234> http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=cross-compile;h=e3013fd578b6d07b55ca32a4c43d082e36cc5e24;hb=HEAD
[09:50] <abeato_> it actually removes connectivity instead of providing it
[09:50] <ogra_> abeato_, yeah, consiole-conf changes it
[09:51] <ali1234> i am importing that repo to github just for testing purposes
[09:51] <mwhudson> abeato_: anything incriminating in syslog?
[09:51] <abeato_> mwhudson, it is pretty difficult for me to grab logs, will change initramfs to get those
[09:52] <zyga> ali1234: perhaps you could create a launchpad project, setup git mirroring and just build on launchpad with a snap packaging recipe
[09:52] <zyga> ali1234: build.snapcraft.io is just a fancy front end
[09:52] <ali1234> yes, that's the thing i linked to before :)
[09:52] <zyga> ali1234: aha :-)
[09:52] <mwhudson> abeato_: system user assertion approach probably best then
[09:53] <mwhudson> i wonder if that is documented anywhere yet...
[09:53] <ali1234> but the thing is that repo gets pushes all the time for other things
[09:53] <abeato_> ok
[09:53] <ali1234> also it doesn't get pushes when the actual source repos are updated
[09:53] <ali1234> so idk how to make it rebuild properly
[09:53] <mwhudson> or i dunno, unpack core snap, chroot into it, add a user, repack, reimage, reflash, would that work?
[09:54] <mwhudson> maybe not actually, you wouldn't get a getty, could always hack up systemd config to make sure you do but that gets a bit involved again
[09:55]  * mwhudson is rambling, it's a bit late here
[09:55] <zyga> ali1234: it pulls automatically every 6 hours
[09:55] <zyga> ali1234: it's not amazing but not terrible either
[09:55] <zyga> ali1234: and the recipe can build on each push
[09:55] <zyga> ali1234: look at this:
[09:55] <ali1234> yes, i understand that
[09:56] <zyga> https://github.com/snapcore/pi2-gadget
[09:56] <zyga> this is mirrored on launchpad and built to a snap
[09:56] <zyga> exactly the way I described
[09:56] <zyga> and it is documented in the readme
[09:56] <ali1234> the problem is that the repo gets pushes eg when the appimage changes
[09:56] <ali1234> but it doesn't get pushes when the source code of the app itself changes
[09:56] <zyga> look at the links and you can do the same thing
[09:56] <zyga> aha
[09:56] <zyga> wait, so where is the source code?
[09:56] <abeato_> mwhudson, it is an idea... will go first for the system-user assertion though ;)
[09:56] <ali1234> in several other repos
[09:56] <zyga> I see
[09:56] <ali1234> look at the snapcraft.yaml :)
[09:56]  * zyga looks
[09:57] <ali1234> https://github.com/ali1234/mysnaps/blob/master/sigrok/snapcraft.yaml
[09:57] <zyga> well
[09:57] <zyga> no idea, ask on the forum :)
[09:57] <zyga> it's an interesting problem for sure
[09:57] <ali1234> so far everything i tried to snap ended up as an interesting problem :)
[09:58] <ali1234> that's why my repo is called "museum of broken snaps"
[09:58] <zyga> ali1234: this is how exploring the unknown feels like :D
[09:58] <ali1234> none of them actually work
[09:58] <morphis> zyga: any idea why `snap info core` doesn't print out the snap type on Fedora?
[09:58] <ali1234> sigrok does now though so i want to promote it :)
[09:59] <mwhudson> ali1234: i just have a launchpadlib script in cron that triggers a build every 24 hours
[09:59] <ali1234> mwhudson: doesn't that mean users have to download an update every day, regardless of if anything changed?
[09:59] <mwhudson> ali1234: http://paste.ubuntu.com/24535900/
[09:59] <ali1234> the sigrok snap comes out at 74MB
[10:00] <zyga> morphis: no, can you share the output?
[10:00] <mwhudson> ali1234: ah yes, well nothing stops you being slightly cleverer in the script i guess :)
[10:00] <mwhudson> ali1234: i agree this is a problem, i don't have a great solution
[10:00] <morphis> zyga: https://paste.ubuntu.com/24535903/
[10:00] <morphis> zyga: on ubuntu that gives me type: core
[10:01] <zyga> yeah
[10:01] <zyga> I see
[10:01]  * zyga looks
[10:01] <zyga> so we have maybePrintType
[10:02] <morphis> zyga: yes, but that should print the type for the core snap
[10:02] <ali1234> um... why doesn't the snapcraft forum have SSO?
[10:03] <ogra_> its in the works
[10:03] <morphis> zyga: ok, I know why
[10:03] <morphis> zyga: `snap list` marks it as broken
[10:03] <ogra_> morphis, new core with new shadow building ...
[10:03] <zyga> morphis: aaah
[10:03] <zyga> morphis: :)
[10:03] <zyga> morphis: there you go
[10:03] <morphis> ogra_: nice
[10:03] <zyga> morphis: /var/lib/snapd/snap vs /snap issue somewhere
[10:03] <zyga> morphis: broken meant that snapd didn't find the meta/snap.yaml file
[10:04]  * zyga would really like for snapd to cache snap.info per revision 
[10:04] <zyga> then we could even lazily mount snaps or keep only one revision mounted instead of three
[10:04] <zyga> less memory use
[10:04] <zyga> and we could keep a finite set mounted even if the user has many times more snaps installed (just not running)
[10:04] <zyga> part of the lifecycle idea we had earlier
[10:09] <ali1234> does the name: in snapcraft.yaml have to match the registered name on build.snapcraft.io?
[10:09] <zyga> ali1234: yes
[10:09] <zyga> ali1234: well
[10:09] <zyga> ali1234: any name you want really but you need to be able to push snaps there
[10:10] <ali1234> which?
[10:12] <ali1234> okay it still can't see the snapcraft.yaml
[10:12] <ali1234> https://github.com/ali1234/sigrok-util/tree/master/cross-compile/snap
[10:14] <morphis> zyga: debian should run in force devmode true, right?
[10:23] <zyga> morphis: yes
[10:23] <zyga> morphis: unless with ubuntu apparmor patches, then it will be automatically not be devmode
[10:24] <morphis> ok
[10:31] <morphis> zyga: hm .. qemu:debian-9-64 .../tests/main/forced-devmode# snap forced-devmode
[10:31] <morphis> false
[10:31] <cjwatson> ali1234: one of snap/snapcraft.yaml, snapcraft.yaml, or .snapcraft.yaml has to exist at the *top level* of your branch
[10:31] <cjwatson> ali1234: (I believe symlinks work)
[10:31] <ali1234> yeah that's not going to happen
[10:31] <cjwatson> not my choice, sorry
[10:31] <ali1234> upstream won't accept it, and that's not my choice
[10:32] <cjwatson> probably best bring it up on the forum or similar - it's not going to change without user protest
[10:32] <ali1234> i have done https://forum.snapcraft.io/t/trying-to-build-sigrok-snap/503
[10:36] <zyga> morphis: interesting
[10:36] <zyga> morphis: I wonder how is this possible
[10:36] <zyga> morphis: is it a boolean flip somewhere/
[10:36] <morphis> zyga: it loosk like there is a problem in my code
[10:54] <AdamH_> hello, is there a snap with the same sort of functionality as plymouth for Ubuntu core?
[11:03] <morphis> zyga: ok, was again my fault ..
[11:06] <ogra_> AdamH_, nope ... not yet (and it would be a bit tricky sinc eplymouth needs initrd inclusion for some use cases)
[11:07] <ogra_> AdamH_, i'm locally playing with uboot spash screen but dont have anything to look at yet
[11:07] <ogra_> *splash
[11:07] <ogra_> that wont help much with the rest of the boot though ...
[11:08] <fgimenez> ogra_: the new core (1870) fixes the ubuntu-core-create-user error https://travis-ci.org/snapcore/spread-cron/builds/229908080 all green now
[11:08]  * ogra_ hugs fgimenez ... thanks for the feedback !
[11:08] <zyga> :-)
[11:08] <zyga> I could use a simple review for https://github.com/snapcore/snapd/pull/3262/files
[11:08] <mup> PR snapd#3262: cmd/snap-confine: aggregate operations holding global lock <Created by zyga> <https://github.com/snapcore/snapd/pull/3262>
[11:09]  * zyga goes back to other reviews
[11:09]  * ogra_ ponders to add a check to the core build scripts with a blacklist of packages we dont want from the archive 
[11:09] <ogra_> so it would fail the next time a newer shadow is there
[11:10] <fgimenez> ogra_: :) thank you! morphis ubuntu-core-create-user should pass with the new core
[11:11] <morphis> fgimenez: great!
[11:22] <AdamH_> ogra_: Thanks, If you need any help testing let me know. I will come back to this task later. Still plenty to develop!
[11:22] <ogra_> will do, thanks for the offer
[11:31]  * zyga afk for a moment
[11:34]  * Chipaca returns
[11:34] <Chipaca> fgimenez: do you know what's up with ubuntu-core-16-64:tests/main/ubuntu-core-create-user ?
[11:35] <Chipaca> ogra_: or maybe you?
[11:35] <Chipaca> /usr/bin/chfn: unrecognized option '--extrausers'
[11:35] <Chipaca> ^
[11:36] <ogra_> Chipaca, fixed already
[11:36] <ogra_> re-run wih a newer core
[11:37] <Chipaca> woot
[11:38] <Chipaca> ogra_: what had happened?
[11:38] <ogra_> Chipaca, CVE upload in the archive with a higher version
[11:38] <ogra_> so the PPA package wasnt used anymore
[11:40] <Chipaca> ogra_: in an ideal world we'd get alerted when that happened, yes?
[11:41] <ogra_> Chipaca, yes. see what i wrote above ...
[11:41] <ogra_> gra_ ponders to add a check to the core build scripts with a blacklist of packages we dont want from the archive
 so it would fail the next time a newer shadow is there
[11:41] <Chipaca> ogra_: yeah!
[11:42] <Chipaca> must be blind because i scanned up several times and didn't spot you saying that there
[11:42] <sborovkov> Is mvo not around today?
[11:42] <Chipaca> sborovkov: I wouldn't be surprised if he took the day off
[11:42] <Chipaca> (he's been travelling back from the sprint)
[11:42] <Chipaca> JamieBennett might know more
[11:43] <sborovkov> that's fine. it's not urgent anyway
[11:43] <sborovkov> just wanted to ask him to add another rpi config option
[11:43] <JamieBennett> sborovkov: he is on vacation today
[11:43] <ogra_> sborovkov, just provide a PR ;)
[11:45] <ogra_> sborovkov, just provide a PR ;)
[11:45] <ogra_> oope
[11:45] <ogra_> *oops
[11:45] <ogra_> sorry
[11:45] <sborovkov> oh right I can do that
[11:45] <sborovkov> and it seems it should be one liner
[11:46]  * ogra_ notes he just killed his pi3 boot ... adding a unit to multi-user-target.wants that has a Before=network.service inside seems to not be such a clever thing ...
[11:46] <Chipaca> ogra_: it shouldn't kill it though
[11:46] <Chipaca> ogra_: systemd will break the cycle by ignoring a unit at random
[11:47] <ogra_> Chipaca, well, ssh doesnt come up, i'm in the living room having some lunch, board is upstairs in the office ...
[11:47] <Chipaca> ogra_: guess which one it chose to break the cycle
[11:47] <ogra_> hehe
[11:47] <Chipaca> ogra_: easy to fix without going upstairs: power cycle the house
[11:48]  * ogra_ plugs two fingers in the socket
[11:48]  * Chipaca sends flowers
[11:48] <ogra_> ah, damn, you said cycle ... means i need to go to the basement after the fuse blew
[11:49] <ogra_> so that ends up in being the same effort ... i'll just finish lunch :P
[11:50] <AdamH_> Any pointers on where to look to rotate the screen to portrait and hide the cursor? I am using mir-kiosk but can't see any config files or options?
[11:50] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[11:50] <sborovkov> ogra_: who should I ask to take a look at that pr - https://github.com/snapcore/core/pull/38
[11:50] <mup> PR core#38: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[11:51] <ogra_> sborovkov, you are aware that enabling the usb mode isnt reversible ? ... not sure thats a clever thing to have in the default options
[11:52] <ogra_> (or did that bevaiour change)
[11:52] <ogra_> *behaviour
[11:53] <sborovkov> ogra_: I am not sure about that behavior, but how can I set it otherwise? Configure hook will comment out everything else in config.txt and well without it I can't even set it
[11:53] <sborovkov> at all
[11:54] <sborovkov> and we want to use that option eventually because SD cards are dying very often and that's actually super cool feature
[11:54] <Chipaca> sborovkov: question, have you signed the CLA?
[11:54] <ogra_> sborovkov, oh, why are your SD cards dying ?
[11:54] <Chipaca> (couldn't figure out your lp nick from your irc nick, if you have an lp account, which is the easiest way of me checking CLA status)
[12:02] <sborovkov> ogra_: well we have around 10000 rpis in production... that's the most frequent case of failure
[12:02] <sborovkov> Chipaca: not sure - https://launchpad.net/~serge-borovkov
[12:03] <Chipaca> sborovkov: that's a nope
[12:05] <sborovkov> Chipaca: where do i sign it actually? here? https://www.ubuntu.com/legal/contributors/submit
[12:06] <ogra_> sborovkov, and adding 10000 USB keys is a cost effective solution ? :)
[12:07] <Chipaca> sborovkov: yep
[12:07] <sborovkov> ogra_: it actually is. Because for the bigger clients especially they can have a bunch of devices across the country. Sending technician to replace SD card for them is not very convenient and would cost more
[12:07] <sborovkov> Chipaca: Please add the Canonical Project Manager or contact. Who should I list here?
[12:08] <Chipaca> sborovkov: Jamie Bennett
[12:22] <zyga> re
[12:22] <Chipaca> mi
[12:24] <ogra_> fa
[12:30] <zyga> so
[12:30] <zyga> Chipaca: I think we want to do a small experiment on exposing interface meta-data
[12:30] <zyga> Chipaca: e.g. an optional method
[12:30] <zyga> Chipaca: that returns a struct
[12:30] <zyga> Chipaca: that has various stuff
[12:30] <zyga> Chipaca: it could replace AutoConnect
[12:30] <zyga> Chipaca: Name
[12:30] <zyga> Chipaca: (well, if we do Name it could be mandatory)
[12:30] <zyga> Chipaca: it could return description
[12:31] <zyga> Chipaca: and one-to-many/many-to-many
[12:31] <zyga> Chipaca: what do you think?
[12:31] <Chipaca> zyga: you mean so the client could make smarter decisions for tab completion?
[12:32] <zyga> Chipaca: yes
[12:32] <zyga> Chipaca: and we could show nice stuff in CLI
[12:32] <zyga> Chipaca: e.g. (what is this interface)
[12:32] <zyga> Chipaca: is that interface restricted
[12:32] <zyga> Chipaca: whatever we can come up with
[12:32] <Chipaca> zyga: could do. Or we could add something on the daemon like "what can connect to <this>"
[12:32] <zyga> Chipaca: it's just a struct
[12:32] <Chipaca> ah, yeah, that'd be nice to have
[12:32] <zyga> Chipaca: yes, that's possible too but I think we want the meta-data anyway; I agree that the daemon may make better decisions about what to suggest as an option
[12:33] <Chipaca> zyga: that would make “snap interface foo:bar” make sense
[12:33] <zyga> Chipaca: especially if we could get rid of some of the optional boring copy pasted methods now
[12:33] <zyga> Chipaca: yes!
[12:33] <zyga> Chipaca: I just +1'd 3214
[12:33] <zyga> shall I merge?
[12:34] <Chipaca> oh! that old thing
[12:34] <Chipaca> zyga: sure! :-)
[12:35] <mup> PR snapd#3214 closed: cmd/snap: iterate interface tab completion <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3214>
[12:35] <zyga> Chipaca: if you review https://github.com/snapcore/snapd/pull/3272 quickly we could land it
[12:35] <mup> PR snapd#3272: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
[12:35] <zyga> it has 1.9 +1s
[12:40] <Chipaca> zyga: on it
[12:43] <Chipaca> jdstrand: snapd#3272 is GTG, unless you want to remove the restore section RSN we should land it
[12:43] <mup> PR snapd#3272: add interfaces-shutdown-introspection spread test <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
[12:43] <Chipaca> bitrot an' all that
[12:49] <jdstrand> Chipaca: hey, I can remove it
[12:49] <Chipaca> jdstrand: your call :-)
[12:49] <Chipaca> you've got the +1s either way
[12:51]  * Chipaca goes in search of tea
[12:51] <zyga> Chipaca: I can remove it
[12:51] <zyga> jdstrand: oh
[12:51] <zyga> jdstrand: hey :)
[12:51] <jdstrand> zyga: hey :)
[12:51]  * zyga read backlog in the wrong order :D
[12:51] <zyga> jdstrand: go ahead then, I'll gladly merge it when tests show green
[12:53] <zyga> fgimenez: did you see this:
[12:53] <zyga>    __all__: The name test-snapd-kernel-module-control-consumer should not be longer than 40 characters.
[12:54] <fgimenez> zyga: sure, there's a problem with snaps already in the store with a name longer than 40chars, currently they cannot be updated
[12:54] <zyga> I need to look at that ensure prune loop test, it is failing again while it should not
[12:55] <zyga> fgimenez: yeah, should we truncate the name then?
[12:56] <fgimenez> zyga: i already pinged nessita about this, i think a fix is on its way to allow the snaps already in the store to be updated
[12:57] <zyga> fgimenez: thanks
[12:57] <fgimenez> zyga: anyway in the kernel-module-control case the snap changes are only related to add a simple command to the snap, this pattern is common to other tests and maybe we could create a generic-consumer snap, i'm working on a branch with this approach
[12:58] <morphis> zyga: who else do we need to do a review on https://github.com/snapcore/snapd/pull/3271 ?
[12:58] <mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
[13:01] <sborovkov> ogra_: but AFAIK rpi needs to be booted from SD card first before you can boot from USB? So how will that work if we set the option in gadget code initially
[13:01] <ogra_> sborovkov, you would still need to boot from Sd first indeed .... the bootloader blob then sets the ROM option and on reboot you can use USB
[13:02] <ogra_> (but thats completely unrelated to having the option in the config interface or not)
[13:02] <zyga> niemeyer: hey, are you around for the standup today?
[13:02] <sborovkov> ah alright, I will create a bug for this then
[13:03] <ogra_> zyga, or Chipaca i'd appreciate a thumbs up for https://github.com/snapcore/core/pull/37 (fixes the tests along with the change)
[13:03] <mup> PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
[13:03] <Chipaca> ogra_: standup
[13:03] <zyga> ogra_: standup?
[13:03] <ogra_> OMW
[13:08] <mup> Bug #1689301 opened: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689301>
[13:08] <mup> Bug #1689302 opened: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689302>
[13:13] <sborovkov> Just tried snapd from edge channel. My snap stopped working. Well not completely but I was showing web page and not it does not work (works with stable, installing beta at the moment). In the logs I only found this, any idea what can be the cause?
[13:13] <sborovkov> May 08 12:49:35 localhost.localdomain kernel: audit: type=1326 audit(1494247775.268:70): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1499 comm="ld-linux-armhf." exe="/snap/screenly-client/x7/viewer/lib/ld-2.18.so" sig=31 arch=40000028 syscall=281 comp
[13:13] <sborovkov> May 08 12:49:35 localhost.localdomain audit[1499]: SECCOMP auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1499 comm="ld-linux-armhf." exe="/snap/screenly-client/x7/viewer/lib/ld-2.18.so" sig=31 arch=40000028 syscall=281 compat=0 ip=0x7544b62c code=0x0
[13:18] <zyga> jdstrand: I'd like to take over https://github.com/snapcore/snapd/pull/3045 by pushing the fixes you requested directly into that PR
[13:18] <mup> PR snapd#3045: interfaces: add random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
[13:20] <zyga> jdstrand: I'm just letting you know in case you wanted to do that as well
[13:31] <jdstrand> zyga: I didn't have any plans to do that
[13:34] <sborovkov> ogra_: any idea about my error? Everything works with snapd from beta channel as well.
[13:37] <ogra_> sborovkov, using the stable kernel i guess ?
[13:37] <ogra_> could be a missing kernel feature
[13:38] <ogra_> (definitely sceeomp blocking the linker there)
[13:39] <ogra_> ask jdstrand if anything in the profiles changed in that regard
[13:47] <sborovkov> jdstrand: any idea?
[13:48] <sborovkov> ogra_: only difference is snapd version. gadget snap was not touched. Just upgraded core snap
[13:49] <Chipaca> sborovkov: we're in a meeting, we're not ignoring you :-)
[13:51] <sborovkov> haha
[13:55] <zyga> fgimenez: can you tell me more about that test, so does it fail if I run it in qemu on master?
[13:56] <fgimenez> zyga: sure, the tests are in this repo https://github.com/fgimenez/validator/tree/master/tests
[13:56] <zyga> thank you, let me look
[13:56] <fgimenez> zyga: you need to setup some env vars before executing 1sec
[13:58] <fgimenez> zyga: http://paste.ubuntu.com/24536879/
[14:00] <fgimenez> zyga: running "SNAP_CONFINE_DEBUG=yes /snap/bin/test-snapd-tools.echo hello" doesn't give any snap-confine debug output, just the same error "internal error, please report: running "test-snapd-tools.echo" failed: no such file or directory"
[14:03] <zyga> fgimenez: this doesn't reach snap-confine AFAIK
[14:03] <zyga> fgimenez: this error comes from snap-run
[14:03] <zyga> fgimenez: do  you have the debug shell??
[14:03] <zyga> fgimenez: might be faster than me running it
[14:03] <zyga> ah actually, let me just
[14:05]  * zyga runs that
[14:05] <zyga> raise your hand if you hate ctrl-shit-c working as copy in shell but working as show inspector in firefox
[14:05]  * zyga misses mac's command-c that works in both places while keeping ctlr-c sane
[14:07] <fgimenez> zyga: not currently up but will have in a moment
[14:09] <zyga> fgimenez: no worries, it's running locally already
[14:13] <fgimenez> zyga: ok i have already the session open in case you need it
[14:15] <Son_Goku> zyga, niemeyer, morphis: Yo
[14:16] <morphis> Son_Goku: hey!
[14:16] <Son_Goku> vacation approved!
[14:16] <morphis> :-)
[14:16] <Son_Goku> niemeyer: so I'm looking forward to the email to get things set up for me to be at the snappy sprint at the end of June!
[14:24] <mup> PR snapd#3277 closed: cmd/snap, client: add "whoami" command <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3277>
[14:28] <niemeyer> Son_Goku: Sweet, glad that you are going!
[14:29] <niemeyer> Son_Goku: Let me sort out the initial steps to get the event set up on our end, and will let you know how to proceed
[14:29] <Son_Goku> niemeyer: excellent
[14:29] <Son_Goku> have you reached out to the elementary guys yet?
[14:29] <Son_Goku> they've just completed the first bit of getting an actual appstore frontend
[14:29] <niemeyer> Son_Goku: Wow, nice
[14:30] <Son_Goku> https://www.indiegogo.com/projects/appcenter-the-pay-what-you-want-app-store#/
[14:30] <niemeyer> Son_Goku: We haven't really invited anyone explicitly yet, other than people participating in the thread..
[14:30] <Son_Goku> ah
[14:31] <Son_Goku> well, since they do the thing where they actually are building an app ecosystem, it might be a good idea to invite some of those guys :)
[14:32] <Son_Goku> Cody is on the Snap technical format board like I am, so there's at least that
[14:50] <mup> PR snapd#3272 closed: add interfaces-shutdown-introspection spread test <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3272>
[14:57] <zyga> 3re
[15:01]  * zyga took a longer lunch break but is now looking at the issue fgimenez reported
[15:06] <zyga> hmm
[15:06] <zyga> very interesting
[15:07] <zyga> fgimenez: so there are a few things
[15:07] <zyga> fgimenez: one is that I see this in the error log:
[15:07] <zyga> May 08 16:31:24 autopkgtest /usr/lib/snapd/snapd[1798]: stateengine.go:98: state ensure error: internal error: could not unmarshal state entry "ubuntu-core-transition-last-retry-time": parsing time ""2017-05-08T1
[15:08] <zyga> this implies that we don't patch the state correctly
[15:08] <zyga> this is also interesting
[15:08] <zyga> /snap/ubuntu-core/current/usr/bin/snap
[15:08] <zyga> ah, wait
[15:08] <zyga> this is not a core system
[15:08]  * zyga reads
[15:09] <fgimenez> zyga: aha, checking the state patching
[15:09] <fgimenez> zyga: nope, classic
[15:09] <zyga> fgimenez: right
[15:09] <zyga> the actual error is that new snapd hard-codes this: /snap/core/current/usr/lib/snapd/snap-confine
[15:09] <zyga> note the core vs ubuntu-core
[15:10] <zyga> let me check if that's a bug in the code or is there a fallback
[15:10] <fgimenez> zyga: ok thanks!
[15:10] <zyga> fgimenez: yes, it's a simple bug
[15:10] <zyga> runSnapConfine
[15:10] <zyga> in this function we need to be bit smarter
[15:11] <zyga> I think we used to have this code but we may have lost it
[15:11] <zyga> I'll take the bug to fix it
[15:11] <zyga> fgimenez: is this tracked anywhere/
[15:11] <fgimenez> zyga: great thanks a lot
[15:11] <fgimenez> zyga: not yet
[15:12] <zyga> offtopic
[15:12] <zyga> I should patch my systems for the AMT fiasco :(
[15:12] <zyga> niemeyer: I want snapd to fix my firmware (I know, won't happen on pre-uefi machines) :-(
[15:12] <ogra_> just turn it off :P
[15:13] <ogra_> (why do your systems have AMT on ?!?)
[15:13] <zyga> ogra_: yeah, I did but I actually like some of the features
[15:13] <zyga> ogra_: well, not anymore ;)
[15:13] <zyga> ogra_: and they are not on the network
[15:13] <zyga> ogra_: but still :/
[15:13] <ogra_> well, then nothing to worry about :)
[15:14] <zyga> ogra_: my laptop actually has AMT but I just disabled it when I realized this was out there
[15:14] <zyga> ogra_: I really hope lenovo will make all the bios updates
[15:14]  * ogra_ has never enabled it in his life
[15:20] <zyga> ogra_: I tried it since the linaro days, I really wish it wasn't closed and unfixable outside of intel
[15:20] <ogra_> yeah, thats why i never disabled it ... i find any BIOS driven features that run a network-server a really bad idea
[15:25] <zyga> ogra_: s/disabled/enabled/
[15:25] <ogra_> err, indeed :P
[15:36] <morphis> zyga: did you ever saw something like https://paste.ubuntu.com/24537293/ on Fedora?
[15:40] <zyga> morphis: you mean the funky unit names?
[15:40] <morphis> zyga: yes
[15:40] <zyga> morphis: yes, they are normal
[15:40] <morphis> really?
[15:40] <zyga> morphis: this is a systemd requirement
[15:40] <zyga> morphis: yes
[15:40] <fgimenez> zyga: https://bugs.launchpad.net/snappy/+bug/1689332
[15:40] <mup> Bug #1689332: internal error on any command due to missing snap-confine <Snappy:New> <https://launchpad.net/bugs/1689332>
[15:40] <morphis> zyga: with the '?
[15:40] <zyga> they must encode the name of the mount directory
[15:40] <zyga> with ?
[15:40] <zyga> I don't see ?
[15:41] <zyga> '?' (question mark)
[15:41] <zyga> - needs to be escaped
[15:41] <zyga> as it escapes /
[15:41] <zyga> as you can see
[15:41] <zyga> morphis: systemd-escape /foo/bar-froz
[15:42] <mup> Bug #1689332 opened: internal error with any command using ubuntu-core snap on classic <Snappy:New> <https://launchpad.net/bugs/1689332>
[15:42] <morphis> zyga: that is fine, but the actual name is 'var-lib-snapd-snap-test\x2dsnapd\x2ddevmode-1.mount'
[15:43] <morphis> with the quotes
[15:43] <morphis> zyga: never saw yet that systemd requires the quotes in a file name
[15:44] <zyga> yes
[15:44] <zyga> it does
[15:44] <zyga> run snapd-escape
[15:44] <zyga> it's also documented in the manual page
[15:44] <zyga> morphis: no
[15:44] <zyga> morphis: the quotes are from bash
[15:45] <zyga> morphis: it's not in the file name
[15:46] <morphis> zyga: that is funky ..
[15:46] <morphis> why is bash doing that or better said ls
[15:47] <zyga> morphis: or actually ls :)
[15:47] <zyga> morphis: for sescurity
[15:47] <zyga> morphis: it escapes stuff so it is not nasty
[15:47] <zyga> morphis: I like that feature :)
[15:57] <ryebot> Can anyone explain why I'm seeing these?
[15:57] <ryebot> cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.24 2.24]): older than "/usr/bin/sn
[15:57] <ryebot> cannot change profile for the next exec call: No such file or directory
[15:57] <ogra_> the rest of the "older than" line would be interesting :)
[15:57] <ryebot> sorry!
[15:58] <ryebot> cmd.go:114: DEBUG: not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.24 2.24]): older than "/usr/bin/snap" (2.24.1)
[15:58] <zyga> ryebot: hey
[15:58] <ogra_> that just means it uses the local binary from the deb (because thats newer) instead of re-execing into the snapd binary inside the core snap
[15:59] <zyga> ryebot: yes, as ogra said
[15:59] <ogra_> technically it sghould be harmless
[15:59] <zyga> ryebot: the next line is more interesting
[15:59] <zyga> ryebot: what were you trying to run?
[15:59] <ryebot> okay cool
[15:59] <ryebot> this is our kube-apiserver snap running as a daemon
[16:00] <ryebot> more complete logs here: http://paste.ubuntu.com/24537348/
[16:00] <zyga> ryebot: what is the distribution you are running on?
[16:00] <zyga> ryebot: please pastebin the output of "snap version"
[16:00] <ryebot> distro: http://paste.ubuntu.com/24537420/
[16:01] <ryebot> snap version: http://paste.ubuntu.com/24537426/
[16:02] <mup> PR snapd#3279 opened: tests: extend kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3279>
[16:02] <zyga> ryebot: hmm, everything looks ok
[16:04] <ryebot> zyga: https://bugs.launchpad.net/snappy/+bug/1687079?comments=all
[16:04] <mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
[16:04] <ogra_> ryebot, snap refresh core --beta
[16:04] <zyga> ryebot: can you look if /var/lib/snapd/apparmor/profiles exists
[16:04] <ogra_> ;)
[16:04] <ryebot> zyga: looks like I'm waiting on the 2.25 release
[16:05] <ogra_> just try it from beta ...
[16:05] <zyga> ah
[16:05] <ogra_> you can go back to stable at any time with: snap refresh core --stable
[16:05] <ogra_> (the biggest beauty about snaps ;) )
[16:05] <zyga> ryebot: I'm afraid something else may be at play
[16:06] <zyga> ryebot: look at that directory and tell me if you see the apparmor profile of the app you were trying to run?
[16:06] <ryebot> ogra_: it's a little tricky as this is an automated installation and things seem to work fine after the fact
[16:06] <ryebot> zyga: looking
[16:06] <ogra_> ryebot, ah, yozu have no shell access ?
[16:06] <ryebot> ogra_: not during the image build
[16:07] <fgimenez> hi jdstrand, quick question, i've noticed that /proc/meminfo is readable by any snap, no matter its confinement, connected plugs, etc, is this intended? http://paste.ubuntu.com/24537464/
[16:07] <ryebot> zyga: I do see one
[16:08] <ogra_> fgimenez, same goes for /proc/cpuinfo i think
[16:09] <fgimenez> ogra_: indeed, it's also readable
[16:09] <zyga> ryebot: can you run "sudo apparmor_parser -r /path/to/that/file"
[16:09] <ogra_> iirc it breaks to many things if we disable it
[16:09] <zyga> ryebot: and try running the application again
[16:10] <ryebot> zyga: after the first attempt, I am able to run the daemon just fine; sorry, should have made that clear.
[16:10] <fgimenez> ogra_: aha, ok thanks good to know
[16:11] <ogra_> also ... meminfo doesnt reveal anything super secret
[16:11] <zyga> ryebot: interesting
[16:11] <zyga> ryebot: can you reproduce the issue somehow?
[16:11]  * ryebot thinks
[16:11] <ogra_> __chip__, did you grow wings or is that a superhero cape ?
[16:12] <__chip__> ogra_: it's an old joke about me being "special"
[16:12] <ogra_> :)
[16:12] <__chip__> (a pythony joke)
[16:12] <ryebot> zyga: not trivially -- do you think there's more going on than that bug?
[16:12] <zyga> ryebot: not sure
[16:12] <__chip__> also this is my netbook, and i sync logs so i don't want to get them jumbled (nor have to do 3-way merge)
[16:12] <zyga> ryebot: that bug was about running a kernel without apparmor
[16:12] <zyga> ryebot: and I don't think you are doing that
[16:13] <ryebot> This is running in an lxc, if that helps
[16:13] <ogra_> morphis, so here is a super simple approach to the hciattach ... http://paste.ubuntu.com/24537569/ we'd then just add additional HW to the case statement
[16:13] <ryebot> Really gotta stop giving you details piecemeal!
[16:13] <zyga> ryebot: aha
[16:13] <zyga> ryebot: :D
[16:13] <zyga> ryebot: yes, that's an interesting and important fact
[16:13] <ryebot> sorry!
[16:14] <zyga> ryebot:
[16:14] <zyga> ryebot: not sure, please let me know if it happens and if it is possible to reproduce
[16:14] <ryebot> zyga: +1 thanks & will do!
[16:20] <niemeyer> __chip__: You got a review on #3278
[16:21] <__chip__> niemeyer: so I do! :-) huzzah
[16:21] <__chip__> currently wondering about cat pages
[16:22] <zyga> __chip__: cat pages?
[16:22]  * ogra_ throws in a mouse page to distract the cat page
[16:22] <zyga> furry(7)
[16:31] <jdstrand> sborovkov: hey, what architecture is this on?
[16:32] <jdstrand> fginther: meminfo should only be available under system-observe on devices where strict confinement is available. what distro is this?
[16:32] <jdstrand> fginther: sorry
[16:33] <jdstrand> fginther: that was for fgiminez
[16:57] <kyrofa> Hey zyga, does the configure hook have a timeout nowadays?
[16:59] <zyga> kyrofa: yes, but there's a bug that pstolowski is fixing
[16:59] <zyga> jdstrand: quick questsion about https://github.com/snapcore/snapd/pull/3045 should I allow https://github.com/snapcore/snapd/pull/3045/files as "r" for the -observe interface?
[16:59] <mup> PR snapd#3045: interfaces: add random interface <Created by femdom> <https://github.com/snapcore/snapd/pull/3045>
[16:59] <pstolowski> yeah i'm on it
[17:00] <kyrofa> zyga, how long is it?
[17:01] <zyga> kyrofa: 5 minutes unless you are hit by a bug
[17:01] <kyrofa> zyga, good deal, thank you
[17:02] <kyrofa> zyga, last question: if the timeout expires, what happens? Does the hook "succeed," or does the snap revert?
[17:02] <zyga> the hook is cancelled but we carry on
[17:02] <zyga> AFAIR
[17:02] <zyga> but that's a special-case on core
[17:03] <zyga> (as in the core snap)
[17:03] <zyga> not in the core system
[17:04] <jdstrand> zyga: I'm about to head into a meeting. 'r' for observe, yes. if you are implementing 'control' too, that one has rw
[17:08] <zyga> jdstrand: I did implement both
[17:08] <zyga> jdstrand: I'll push and let you review, I probably got the apparmor part slightly wrong but I'll let you comment
[17:21] <zyga> jdstrand: done
[17:27] <zyga> ogra_: can you re-affirm my understanding of https://github.com/snapcore/core/pull/37#pullrequestreview-36832829
[17:27] <mup> PR core#37: install keyring (LP: #1670475), update pkglists <Created by ogra1> <https://github.com/snapcore/core/pull/37>
[17:30]  * zyga EODs
[17:35] <ali1234> launchpad build failed with "sigrok.org: Name or service not known"
[17:44] <koza> ogra_, thanks for the BT on RPI update, reading through it
[17:44] <niemeyer> Need to step out to run an errand.. will be back later.
[17:52] <ogra_> zyga, yeah, make check is run by snapcraft anyway (and with the right shellcheck installed)
[17:52] <ali1234> hmm i broke launchpad
[17:52] <ogra_> ali1234, no worries, we'll use github meanwhile
[17:52] <ali1234> but you can't build from github on launchpad
[17:53] <ali1234> you can't build from any remote afaict
[17:53] <ogra_> well
[17:53] <ali1234> you have to import them onto lp
[17:53] <ali1234> and that doesn't work properluy
[17:53] <ogra_> snapcraft.io is just a different frontend to the Lp builders ...
[17:53] <ali1234> yeah the lp builders are what is broken
[17:53] <ogra_> and you can set up auto imports for foreign git trees
[17:53] <ali1234> that also doesn't work properly
[17:54] <ogra_> good enough for our official packages at least
[17:54] <ali1234> they must be really simple then
[17:54] <ogra_> we build core, kernels and gadgets that way
[17:54] <ogra_> not really
[17:54] <ali1234> do you build anything that needs more than one repo?
[17:55] <ogra_> we have one that chainloads another one ... but not at the same time though
[17:55] <ogra_> s/same time/in parallel/
[17:55] <ali1234> hang on i will write a bug report
[17:56] <ogra_> yeah, do that
[17:57] <ogra_> i used to have a kodi snap that used different GH trees in the past ... but that evolved to not do that anymore :)
[18:03] <mup> PR snapcraft#1286 closed: lxd: Setup image and target arch for cross-compilation <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1286>
[18:16] <ali1234> ogra_: https://bugs.launchpad.net/launchpad/+bug/1689369
[18:16] <mup> Bug #1689369: Uploading multiple git repos to a project is confusing <Launchpad itself:New> <https://launchpad.net/bugs/1689369>
[18:19] <ali1234> here's a crazy idea... what if, instead of having to mess around importing 8 different repos onto lp to make my snap build, what if lp would just read my snap build and import the needed repos automatically?
[18:35] <ali1234> also its been half an hour and none of the repositories have imported yet
[18:44] <ali1234> okay the builder can't clone from launchpad anyway
[18:44] <ali1234> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~a-j-buxton/sigrok-snap-test/+git/libserialport": no supported schemes
[19:41] <ali1234> did anyone try to run snapcraft in docker?
[19:42] <ali1234> i just get "'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128)"
[19:42] <nacc> ali1234: fwiw, your earlier message from lp appears to be a mismatch between bzr and git
[19:43] <ali1234> nacc: it might be because the repositories never imported (they still haven't)
[19:43] <Chipaca> niemeyer: question for you sah
[19:44] <ali1234> i have pretty much given up on launchpad at this point, and cleanbuild doesn't work either, hence why i am trying to use docker now, because i know that works
[19:44] <Chipaca> niemeyer: is stringList still a good name given it's loaded from something that can be a list or not (in json)?
[19:44]  * Chipaca is bad with names and defers to others' judgement on them (when not having too much fun)
[19:45] <nacc> ali1234: why doesn't cleanbuild work?
[19:45] <ali1234> nacc: it cannot connect to https URLs from inside the container
[19:45] <nacc> ali1234: sounds like a bug in your lxd configuration?
[19:45] <nacc> ali1234: cleanbuild relies on working lxd
[19:46] <ali1234> i followed the lxd setup instructions
[19:46] <ali1234> it doesn't work
[19:46] <ali1234> *shrug*
[19:46] <ali1234> docker doesn't require me to spend several days debugging it
[19:46] <ali1234> it just works
[19:46] <nacc> ali1234: 'lxc setup instructions'? on ubuntu, `sudo apt install lxd` generally works
[19:46] <ali1234> yes
[19:47] <nacc> ali1234: except ... it doesn't? you just said it didn't work
[19:47] <ali1234> here is the error message: HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries exceeded with url: /v1/parts.yaml (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f50da481748>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
[19:48] <nacc> well, that's just weird -- parts.snapcraft.io redirects to snapcraft.io just fine
[19:48] <nacc> and this loads ok: https://parts.snapcraft.io/v1/parts.yaml
[19:48] <ali1234> yes it loads okay for me, as long as i am not trying to use lxd
[19:49] <Chipaca> ali1234: are you on 16.04?
[19:49] <ali1234> yes
[19:49] <Chipaca> stgraber: you around?
[19:49] <nacc> ali1234: lxc launch ubuntu:xenial; lxc exec <container> -- wget https://parts.snapcraft.io/v1/parts.yaml
[19:50] <stgraber> Chipaca: what's up?
[19:50] <ali1234> bash: container: No such file or directory
[19:50] <Chipaca> stgraber: ali1234 is getting dns errors inside lxd ^ and i thought maybe you already knew what it might be
[19:50] <nacc> ali1234: well, substitue the container name for what `lxc launch` retuned
[19:50] <nacc> *retuned
[19:50] <nacc> *returned, bah
[19:51] <ali1234> wget: unable to resolve host address 'parts.snapcraft.io'
[19:52] <stgraber> ali1234: host parts.snapcraft.io; lxc launch ubuntu:xenial test; sleep 5; lxc exec test -- host parts.snapcraft.io
[19:53] <ali1234> http://paste.ubuntu.com/24538636/
[19:54] <ali1234> it took a really long time to time out too
[19:58] <ali1234> hmm launchpad is syncing those repos now
[19:58] <nacc> ali1234: when you installed lxd, did you just take the defaults for the network config?
[19:58] <ali1234> and every time it imports one it retriggers the snap build, so now i am getting spammed with failed build logs
[19:59] <ali1234> nacc: i can't remember
[19:59] <ali1234> probably
[19:59] <ali1234> i can't think of a reason why i would change it
[19:59] <ali1234> unless there was a question that says "do you want networking to actually work?" if so i would have said yes
[19:59] <nacc> stgraber: default on 16.04 w/o backports is lxdbr0?
[20:00] <stgraber> ali1234: can you pastebin "lxc info"?
[20:00] <ali1234> is it safe to pastebin that certificate?
[20:00] <stgraber> nacc: yeah which if unconfigured gives you just link-local ipv6
[20:00] <stgraber> ali1234: yes, it's just the public half of the cert
[20:01] <ali1234> http://paste.ubuntu.com/24538661/
[20:01] <nacc> stgraber: right
[20:03] <stgraber> ali1234: can you pastebin /etc/default/lxd-bridge?
[20:03] <ali1234> http://paste.ubuntu.com/24538672/
[20:12] <ali1234> okay i told launchad that the repos are git repos, now the builder says "error: cannot run ssh: No such file or directory"
[20:12] <ali1234> Command '['git', 'clone', '--recursive', 'lp:~a-j-buxton/sigrok-snap-test/+git/libserialport', '/build/sigrok/parts/libserialport/src']' returned non-zero exit status 128
[20:17] <stgraber> ali1234: ok, your network is unconfigured
[20:17] <stgraber> ali1234: run dpkg-reconfigure -p medium lxd
[20:17] <stgraber> ali1234: using the default values it gives you should be fine
[20:19] <ali1234> how do i get rid of all the containers that i made while debugging this?
[20:19] <ali1234> lol it still doesn't work
[20:19] <ali1234> but now the error is the exact same as the one i got from docker half an hour ago!
[20:19] <ali1234> 'ascii' codec can't encode character '\u29f8' in position 35: ordinal not in range(128)
[20:20] <ali1234> apparently it is in a different position now
[20:22] <ali1234> \u29f8 is ⧸ which looks a lot like / but isn't
[20:23] <ali1234> Bug #1607015
[20:23] <mup> Bug #1607015: 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) <eco-team> <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1607015>
[20:25] <ali1234> i see this is a well known problem
[20:27] <Chipaca> ouh, i missed it
[20:27] <ali1234> so the problem here is that you put the parts in a wiki, and the wiki turned / into BIG SOLIDUS because it's written by web designers not programmers?
[20:28] <ali1234> looks like cleanbuild is finally workin
[20:29] <ali1234> hmm noe
[20:29] <ali1234> oh wait i've finally got to the point where i need to figure out the build-packages:
[20:42] <stgraber> ali1234: good, sounds like the LXD side of things is fixed at least. You can use "lxc delete" to remove all the containers you created ("lxc list" to list them)
[20:43] <ali1234> yeah it's working now, thanks
[20:44] <ali1234> everything compiled, it got to the copy plugin, then couldn't find the file i asked it to copy
[21:11] <icey> jdstrand: might be easier to talk about rg here too :)
[21:25] <jdstrand> icey: hi :) note we are following a specific voting process for things like auto aliases so the discussion should really be in the forum. see https://forum.snapcraft.io/t/process-for-reviewing-aliases-and-auto-connections/455
[21:25] <ali1234> okay i need to build a qt5 app, but it uses cmake for the build system so i can't use the cmake plugin
[21:26] <icey> ah, no worries jdstrand  :)
[21:26] <ali1234> what packages do i need to pull in to get it to build?
[21:26] <icey> well jdstrand I want to get the actual maintainer to own the snap but he was lukewarm about including the snapcraft.yaml in tree
[21:26] <icey> he did make the merge but I don't want to push him too fast :)
[21:27] <lazyPower> How long does it take to get a name approved for the snapstore? I submit a registration for lazy-dex a little over 6 days ago, seems like its stuck in the process somewhere. No feedback that I'm aware of
[21:27] <lazyPower> icey: nice :)
[21:27] <lazyPower> thats progress right?
[21:27] <jdstrand> icey: that is worth mentioning in the forum. note that upstream taking over maintaining the snap is not a requirement, it's just a data point
[21:27] <icey> lazyPower: yeah :) I have another PR up on another project
[21:27] <jdstrand> it is progres :)
[21:27] <icey> jdstrand: I did reply on the forum as well :-D
[21:27] <jdstrand> progress even :)
[21:28] <jdstrand> ok, cool
[21:28] <icey> lazyPower: I've done some community work on rust snaps :)
[21:29] <lazyPower> i fear the commitment to rust
[21:29] <icey> haha lazyPower
[21:29] <lazyPower> :D
[21:29] <icey> lazyPower: spare time :) (except the work on the plugin)
[21:29] <lazyPower> I'm still bummed i cant push my snap :S
[21:29]  * lazyPower is doing charm work with resources :S
[21:29] <icey> lazyPower: most let me push pretty quickly
[21:30] <lazyPower> icey: do you just get the ack or what? i submit a request for a non-top-level name last week, i'm still waiting ot hear back
[21:30] <lazyPower> or do you just not register or?
[21:30] <icey> lazyPower: I registered both alacritty and ripgrep
[21:30] <icey> both are currently in --edge
[21:31] <lazyPower> OH MY GOODNESS
[21:31] <lazyPower> i didn't even need to request registration
[21:31] <lazyPower> i can just snapcraft push
[21:31] <lazyPower> welp nothing to do here then *whistles*
[21:31] <icey> I think it only matters for "reserved" names lazyPower  :)
[21:31] <icey> glad I could help lazyPower :-P
[21:31] <lazyPower> that'll teach me for assuming stuff i guess
[21:32] <lazyPower> i hit the dashboard and saw the "new snap" button and followed that process
[21:32] <lazyPower> never again will i follow the rules
[21:32] <icey> haha lazyPower
[21:32] <icey> if you try to upload 'lynx' (or other popular? program) it will refuse you
[21:34] <lazyPower> well i didn't want to own the dex snap until its complete so i figured prefix with my handle is a good starting place
[21:34] <lazyPower> i think others have done that based on snapcraft search results
[21:34] <icey> lazyPower: with ripgrep and alacritty, I'm working to push them upstream :)
[21:34] <lazyPower> icey: dont make this about you :|
[21:34] <lazyPower> <3
[21:34] <icey> so I pushed them and published to --edge, you can always transfer ownership as well
[21:34] <lazyPower> nice
[21:34] <lazyPower> i doubt coreos is going to jump on maintaining any of their tech in snaps
[21:35] <lazyPower> who knows though they might
[21:35] <icey> touche
[21:35] <icey> as jdstrand mentioned above, being maintained upstream isn't a requirement :) I liek using the --edge channel until a snap is "done" and then for dev style builds
[21:35] <icey> s/liek/like
[21:38] <lazyPower> ooo spiffy
[21:39] <lazyPower> https://dashboard.snapcraft.io/dev/snaps/7608/
[21:39] <lazyPower> not sure if that link will work for you
[21:39] <lazyPower> but i'm sorted and in edge
[21:39] <icey> nah, can't see it :-/ those pages aren't public, not sure if there's a really good place to show a snap that's up
[21:39] <icey> +1 for somebody making that ^^
[21:39] <lazyPower> icey: good plan. I'm not sure how to move forward with this until i've had more time to talk with the team about ownership
[21:39] <icey> but congrats lazyPower !
[21:40] <lazyPower> because i cant be a single point of failure. i'd rather CI own it tbh
[21:40] <lazyPower> that way anyone can push button release the snap and sip tea
[21:40] <icey> lazyPower: yeah, there's ways to setup travis to build / publish into --edge
[21:40] <lazyPower> we're using jenkins for the k8s stuff so it'll live in there, but all the same, yeah.
[21:40] <icey> or you can use build.snapcraft.io
[21:41] <lazyPower> the one thing i've had an issue with is that the builders dont support github orgs yet
[21:41] <icey> yea
[21:41] <lazyPower> so we're kinda doing an alternative impl that we're not crazy about but it gets the job done
[21:47] <ali1234> bug #1650087
[21:47] <mup> Bug #1650087: [Tour] 20-PARTS-PLUGINS/01-reusable-part: missing g++ dependency <bitesize> <tour> <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1650087>
[21:48] <ali1234> hmm
[21:51] <mup> PR snapcraft#1293 closed: recording: record stage packages installed in the snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1293>
[22:08] <mup> PR snapd#3278 closed: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3278>
[22:33] <mup> PR snapd#3280 opened: configstate: return error if patch is invalid <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3280>
[23:10] <mup> PR snapd#3045 closed: interfaces: add random interface <Created by femdom> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3045>
[23:29] <cjwatson> ali1234: so I would agree that we ought to make the lp: alias work by default in LP snap builds, one way or another, but you should just change lp: to https://git.launchpad.net/ so that your snapcraft.yaml isn't dependent on specific git configuration
[23:30] <ali1234> and that works?
[23:30] <cjwatson> ali1234: and cloning from github in LP snap builds works too, as long as you use https:// and not git://
[23:30] <cjwatson> yes
[23:31] <ali1234> i mean, ideally i would just clone from upstream, but the builders don't see to be able to resolve hostnames
[23:31] <cjwatson> I bet you're using git://
[23:31] <ali1234> yes, upstream only has git://
[23:31] <cjwatson> so, I have a patch in review to fix that
[23:31] <ali1234> okay
[23:32] <ali1234> also i keep getting spammed with failed builds, any idea about that?
[23:33] <ali1234> it keeps on trying to build it over and over, but i am not pushing anything to the repo with snapcraft.yaml, which is not an import
[23:33] <cjwatson> not right now, about to go to sleep
[23:34] <ali1234> i got it to build locally in cleanbuild so that's something
[23:35] <nacc> ali1234: nice, sorry it was such a pain to get to that point
[23:35] <cjwatson> can have a look tomorrow if you give me a link or something
[23:35] <ali1234> https://code.launchpad.net/sigrok-snap-test
[23:36] <nacc> ali1234: i mean, it appears to have tried 4 times so far to build?
[23:37] <ali1234> i have 7 failure reports
[23:38] <ali1234> i did delete the project a couple of times though
[23:38] <ali1234> and one was a manual build
[23:39] <ali1234> it seems like it triggered a rebuild each time it finished importing a repo
[23:39] <ali1234> but rate limited
[23:44] <ali1234> pushing the fixed build deps + https URLs... lets see if it triggers a build or not
[23:45] <ali1234> hey its building :)
[23:49] <ali1234> cloning is working
[23:49] <ali1234> i think this might work :)
[23:59] <diddledan> has anyone come across snapcraft complaining on a .desktop file containing non-ascii characters? specifically it dies with a message "'ascii' codec cannot decode byte 0xec at position 224: ordinal not in range (128)" which is a rather cryptic message not really telling us that the desktop file contains non-ascii chars