#snappy 2015-10-26
 * Guest42341 What a fine day for science! 
<dholbach> good morning
<clobrano> good morning :)
<fgimenez> good morning
<zyga> good morning
<JamesTait> Good morning all; happy Monday, and happy OK Corral Day! ð
<Chipaca> what's /usr/lib/snappy-systemd/systemd-snappyhook ?
<Chipaca> ogra_: is that one yours? ^
<dholbach> dpm, thanks for the emails
<dholbach> I'll bring it up in the snappy standup later on as well
<dpm> great, thanks dholbach
<clobrano> Chipaca: hi, eventually I decided to propose the simple solution for Bug #1496319 (just a symlink without filters) :)
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<Chipaca> clobrano: still needs jdstrand's and/or co's input
<clobrano> Chipaca: co?
<zyga> mvo: hey
<zyga> mvo: nice to see you again, how are you?
<Chipaca> clobrano: "and/or his team"
<clobrano> Chipaca: aahh, get it now ;). It's fine :)
<mvo> hey zyga! thanks, I'm very well. how are you?
<zyga> mvo: I just returned from holidays, I'm settling in
<zyga> mvo: I wanted to ask about snaps for the kernel and a few other bits, if you remember our conversation from the sprint
<mvo> zyga: I'm not sure I do, but there is progress for kernel snaps since the sprint
<zyga> mvo: is there enough bits now to come up with an image for any system with just the snaps?
<mvo> zyga: http://people.canonical.com/~mvo/all-snaps/ has all thats needed. there is a example image, there is a ubuntu-device-flash, a kernel and os snap and the run to show how to drive udf in the new world. the next step is store support for the kernel/os snaps and then we can get serious about testing them
<zyga> mvo: that's a lot, thanks! I'll read that and see how to start desigining skeleton for ubuntu-image
<mvo> zyga: this is what we did for u-d-f to support all-snaps https://code.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/+merge/275273
<mvo> zyga: it needs some cleanup, its just enough to get us going for better testing
<zyga> mvo: I see, thanks
<zyga> sergiusens: hey!
<zyga> sergiusens: how are you :)
<zyga> sergiusens: I'm back from holidays today
<zyga> sergiusens: would you have a moment to sync later today?
<shuduo> lool: ping
<lool> shuduo: pong
<sergiusens> zyga, sure, but later, not just now ;-)
<shuduo> lool: i'm working to create a webapp snap example based on tomcat-maven-webapp. i wonder how the scribpt 'wrapper' be generated?
<zyga> sergiusens: I'll setup a meeting and we'll see
<lool> shuduo: see tomcat-maven-webapp/Makefile
<lool> shuduo: install -D -m755 wrapper $(DESTDIR)/bin/wrapper
<lool> bottom of snapcraft.yaml runs make
<shuduo> lool: i mean, is it composed by you or someone else for tomcat-maven-webapp? Is it necessary for tomcat-hosted webapp?
<lool> shuduo: it's part of the example snap and helps start tomcat properly; you're free to get rid of it
<lool> shuduo: perhaps you should mention your higher level goals; it looks like we're discussing specifics but you have a larger point to make
<shuduo> lool: sorry i just try to understand the structure and call stack. i'm not an expert of webapp. i just tried to learn it as our customer maywant my answer regarding example code
<shuduo> lool: i tried to program a tomcat-hosted spring based webapp then make it as a snap
<shuduo> lool: i'm curious why we need wrapper and who call it after it be installed
<shuduo> lool: oh, i find the part of snapcraft wrapper script explaied. it should answered my question.
<lool> shuduo: basically snaps can either expose commands or services; in the case of this example snap, a tomcat service is exposed and is launched with this wrapper; note that snapcraft will generate intermediate wrappers (e.g. to set environment variables such as LD_LIBRARY_PATH or PATH)
<shuduo> lool: let me read application developer manual first. thanks for your explaining. :)
<lool> shuduo: anytime; let me know if you have issues or questions with this sample
<shuduo> lool: i found my sample  project seems not packed well. after I installed on snappy on vm i can't see webapp run on specified url.
<lool> shuduo: try sudo snappy service logs <snap-name>
<Guest42341> nope nope nope
<shuduo> lool: my sample project is a webapp use tomcat8 as host, spring as framework, mvn build system. I verified on my laptop with localhost:8080/SpringMVC. then i build by snapcraft and installed on snappy system on vm. then i use IP:8080/SprinMVC but it return 404
<lool> shuduo: can you connect to :8080?
<lool> shuduo: do you get tomcat 8 running there?
<shuduo> lool: yes
<lool> shuduo: if yes, then it's a webapp deployment issue
<shuduo> lool: then how i debug it?
<lool> shuduo: so this is more tomcat world than snappy world, but either you dump webapps preinstalled in the tomcat runtime dir, or you put the webapp to deploy in the to-be-deployed tomcat location
<lool> shuduo: typically in the later case you'd install a .war in the to-be-deployed dir
<lool> and that'd be installed in the runtime webapps dir
<lool> shuduo: checkout the logs under the runtime dir
<balloons> fgimenez, so I haven't forgotten about your session for UOS :-)
<balloons> we'd like to get things all scheduled this week, so it would be great if you could propose the session.
<elopio> nessita: I've just gotten this TLS error: http://pastebin.ubuntu.com/12970390/
<nessita> elopio, checking!
<shuduo> lool: i can se the war file be placed in /var/lib/apps/spring-mvc-demo.sideload/current/webapps. I pasted the logs content at https://pastebin.canonical.com/142681/. i don't know what is clue. could you pls take a look?
<nessita> elopio, but is for an image not a package?
<fgimenez> balloons, :) ok, tbh i'm not yet sure about this, anyway i'll try to find the time and contents to prepare something and let you know
<elopio> fgimenez: sorry for throwing you here... :)
<elopio> you can say no, but you'll break balloons' heart.
<sergiusens> elopio, care to look at https://code.launchpad.net/~sergiusens/snapcraft/1481122/+merge/275237 again?
<elopio> nessita: generic-amd64 is a package.
<elopio> that u-d-f downloads to create an image.
<nessita> elopio, but the error is about downloading the package icon?
<sergiusens> elopio, but it also downloads the icon; nessita is on the right track
<sergiusens> what is failing is the link in the store manifest to retrieve the icon
<nessita> the client should definitely retry and perhaps install without icon; on the other hand I will pursue the myapps setup about icon downloads
<nessita> elopio, have a bug for this?
<balloons> thanks elopio and fgimenez :-)
<elopio> nessita: https://bugs.launchpad.net/snappy/+bug/1488186
<ubottu> Launchpad bug 1488186 in Snappy "Failed to update: gnutls_handshake() failed" [High,Triaged]
<elopio> we need to retry in many places.
<nessita> elopio, thanks. I was thinking on a bug report more specific to icon download error vs package download error vs system image download error, because each one is fetched from very different places
<elopio> nessita: I was thinking about marking more projects as being affected by this. But if you prefer that, I'll split it in three.
<nessita> elopio, well, I would like to track ocurrences of each kind, becase I'm not sure you have noticed issues downloading a package yet?
<nessita> elopio, so since each source is served from very different servers, I was thinking on tracking each separately (icons, packages and system images)
<elopio> nessita: yes, http://pastebin.ubuntu.com/12896071/
<nessita> elopio, interesting
<nessita> elopio, so are all these errors happening in the same place?
<nessita> or is reproduceable in different envs?
<elopio> ok, I'll report two more. Should I mark them as affecting a server project in addition to u-d-f?
<elopio> nessita: I have seen the system image one in canonistack, and locally. The other two just from my machine, haven't seen them yet in the cloud
<nessita> elopio, well, we haven't had any other reports, for example we never got reports from the phone
<nessita> elopio, so it may also be a low timeout in the client for TLS timeout?
<sergiusens> nessita, icons is a must though, it is part of the package install, just delivered outside of the package
<sergiusens> elopio, check the date on your workstation ;-)
<elopio> nessita: maybe. What I find weird is that it wasn't like this two weeks ago.
<elopio> nessita: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1510136 and https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1510138
<ubottu> Launchpad bug 1510136 in goget-ubuntu-touch (Ubuntu) "Failed to install the oem package: TLS handshake timeout" [Undecided,New]
<ubottu> Launchpad bug 1510138 in goget-ubuntu-touch (Ubuntu) "Failed to download the oem package icon: TLS handshake timeout" [Undecided,New]
<elopio> ah, I know why I haven't seen this in the cloud, we don't use u-d-f in the suite :p
<sergiusens> elopio, those icon retries are all snappy bugs though
<sergiusens> elopio, the icon download comes from using the snappy api
<elopio> sergiusens: um, that's better. So we can fix it in one single place.
<sergiusens> elopio, you do need to rebuild u-d-f so it is fine to leave the bug open for it
<elopio> sergiusens: yes, just marking it as affecting snappy now. You guys can later mark it invalid or duplicate.
<elopio> ppisati: hello. I'm starting to learn about dtb and the board leds and was wondering why the heartbeat is not blinking in bbb.
<ppisati> elopio: you can find which trigger that led is using, looking at the
<ppisati> elopio: cat /sys/class/leds/$LED/trigger
<ppisati> elopio: or something along that line
<ppisati> elopio: kernel version?
<elopio> pitti: it's set to none, but the dtb tries to set it to heartbeat.
<elopio> I tried echoing heartbeat in there too, which works on debian but doesn't in snappy.
<ppisati> elopio: do you have the heartbeat module loaded?
<elopio> ppisati: I don't know.
 * elopio starts the bbb again.
<elopio> ppisati: 4.2.0-16-generic
<elopio> not sure how to load the hearbeat module. lsmod doesn't show anything with heartbeat in the name.
<shuduo> lool: ping
<ppisati> elopio: cat /sys/class/leds/$LED/trigger
<ppisati> elopio: and show me the output
<elopio> ppisati: http://pastebin.ubuntu.com/12970889/
<sergiusens> elopio, Chipaca care to take a look at https://code.launchpad.net/~sergiusens/snapcraft/1510160/+merge/275736 ?
<ppisati> elopio: sudo modprobe ledtrig-heartbeat
<Chipaca> sergiusens: trade ya https://code.launchpad.net/~chipaca/snappy/no-empty-channel-in-update/+merge/275731
<ppisati> elopio: and then try to set it again
<elopio> ppisati: awesome.
<elopio> ppisati: so, how do we tell the bbb oem package to load that module?
<ppisati> elopio: if the correct trigger is not built into the kernel
<ppisati> elopio: you can't do that at boot time
<ppisati> elopio: i'm checking one thing, hold on
<elopio> huh, so we need it in the kernel snap instead.
<ppisati> elopio: we need a kernel with tha option built-in
<ppisati> elopio: i checked vivid, and we had the same config back then
<ppisati> elopio: so it's not a regression
<ppisati> elopio: if you care to open an lp bug, i'll prepare a config patch and send it
<elopio> ppisati: sure. in lp:snappy? or in a project for the kernel?
<ppisati> elopio: just a normal lp bug, we are using the same kernel (ubuntu vs snappy)
<elopio> ppisati: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1510165
<ubottu> Launchpad bug 1510165 in linux (Ubuntu) "heartbeat module is not loaded" [Undecided,New]
<elopio> thank you!
<sergiusens> Chipaca, fair trade
<shuduo> lool: just let you know i found out why my web app did not run. Seems your sample code use <build><finalName> to define a short app name but I use original pom.xml has no the section then lead the web app full name contain version and SNAPSHOT postfix. I can see my webapp run well with right url with long name now. Thanks your sample as good referance. :)
<dholbach> all rightie... I call it a day - see you all tomorrow!
<Chipaca> sergiusens: mvo: can you kick a new build of u-d-f so it picks up a new snappy?
<Chipaca> mvo: if you have a release checklist, can you add building a new u-d-f and a new webdm to it?
<Chipaca> mvo: if you don't have a release checklist, http://www.amazon.co.uk/dp/1846683149
<elopio> sergiusens: any idea what are we missing here? https://code.launchpad.net/~stephen-stewart/webdm/use-correct-version-for-post-css-bemlinter/+merge/272467/comments/696732/+download
<lool> shuduo: awesome
<lool> shuduo: we can adjust the sample if it's not good enough
<lool> shuduo: the idea is to keep it simple and robust, yet do something relatively advanced
<Chipaca> elopio: i just saw your comment wrt licensing
<Chipaca> elopio: and i know why you're seeing what you're seeing
<elopio> Chipaca: and you have a magic solution?
<Chipaca> elopio: yes, yes I do.
<Chipaca> elopio: software is magic, right?
<elopio> yes it is.
<Chipaca> elopio: do you have an easy way, from the integration tests, to give the test an actual terminal?
<Chipaca> elopio: if you do, do it. If you don't, do this instead: http://pastebin.ubuntu.com/12971806/
<elopio> Chipaca: I have no idea how to give it a terminal, but I can search.
<Chipaca> elopio: probably easier to include the above diff in your branch
<elopio> yes, probably.
<elopio> thanks Chipaca. I'll try to write the test with that.
<elopio> I'm also having a problem sending y to the stdin, and I'm not sure that fixes it.
<Chipaca> elopio: echo y | your-test ?
 * Chipaca fights down the urge to mention yes `yes`
<elopio> Chipaca: I haven't tried that, just writing the the stdin pipe. /me tries
<Chipaca> elopio: ah!
<Chipaca> elopio: let me write it in go for you, gimme a bit
<sergiusens> elopio, phantomJS fails   TypeError: 'undefined' is not an object (evaluating 'Backbone.Marionette.ItemView')
<elopio> sergiusens: that I know. But how come it is returning undefined?
<sergiusens> elopio, I don't know, beowulf who isn't here should know
<sergiusens> I don't know much about JS much less supporting tools
<elopio> sergiusens: I've pinged him.
<snappyc> getting a 'connection to Mir server failed' error when trying to start clocks example
<Chipaca> elopio: http://paste.ubuntu.com/12971957/
<Chipaca> snappyc: is mir running and creating its socket?
<Chipaca> snappyc: I think it creates it as /tmp/mir_socket or something like that
<Chipaca> snappyc: you need to make it use that socket
<snappyc> thanks chipaca.  how do i check the log?
<Chipaca> snappyc: mir's logs would be under "snappy service logs mir"
<Chipaca> snappyc: is that the log you mean?
<snappyc> yeah.  how do i get to it?  /var/log/... ?
<snappyc> or is it somewhere else?
<Chipaca> snappyc: snappy service logs mir?
<sergiusens> snappyc, run what Chipaca mentions
<Chipaca> yeh, that's an actual command
<Chipaca> snappy service logs mir
<Chipaca> mvo: we should make snappy a snap
<snappyc> how to execute ur script?
<snappyc> :{
<elopio> sergiusens: beowulf is on parental leave.
<snappyc> $snappy service logs mir  --returns -- unknown command "service".  Please specify one command of: booted, build, config, ...
<mvo> Chipaca: es, I think we should
<Chipaca> snappyc: your snappy is quite old
<Chipaca> snappyc: update that, first
<Chipaca> snappyc: "snappy update" should do that for you
<snappyc> ubuntu-personal/rolling/edge
<Chipaca> personal! is that supported in any way right now?
 * Chipaca has no idea
<snappyc> lol. :{
<sergiusens> the personal target is not supported
<sergiusens> the mir snap should not be installable on snappy personal either
<Chipaca> snappyc: what are you trying to do?
<snappyc> mir snap installed.
<Chipaca> sergiusens: i just assumed it was from the mir snap, it might be the system mir on personal? (dunno) (because, see: dunno)
 * sergiusens doesn't want to discuss mir dev as he is not the right person
 * sergiusens uses his remaining mana to invoke kgunn 
<Chipaca> snappyc: snappy ubuntu personal is still a way in the future, fwiw
<Chipaca> snappyc: i don't know what you're trying to do, but you're probably better off using snappy ubuntu-core
<Chipaca> snappyc: are there instructions out there that point at -personal, or did you do that yourself?
<sergiusens> mvo, Chipaca elopio are you already on xenial?
<elopio> sergiusens: nop.
 * sergiusens updated to wily yesterday and is considering going all in
<Chipaca> sergiusens: updating now
<snappyc> just doing it myself
<mvo> sergiusens: not yet, but soon :-D
<mvo> sergiusens: at least on my main box
<Chipaca> snappyc: ah. Good job on figuring out the bits :)
<Chipaca> snappyc: but yeah, that's very much not ready for anything right now
<Chipaca> snappyc: it only gets updated when people want to take a poke to see how things would look
<snappyc> Chipaca: can i install snappy desktop on snappy core?
<Chipaca> snappyc: there isn't a "snappy desktop"
<snappyc> :{
<Chipaca> snappyc: ?
<snappyc> Chipaca: any way to export installed app?
<snappyc> *snap
<Chipaca> snappyc: you're going to have to explain that one to me, i'm afraid
<snappyc> :{
<snappyc> um
<snappyc> how is ubuntu-core updated?
<snappyc> can i update it manually?
<wiggleworm> I tried to change the time on my snappy system with the command "sudo date 102613392015.00" but the new date will not stick
<wiggleworm> am I doing something wrong?
<Chipaca> snappyc: depends what you mean by "manually". "snappy update" updates the system, and you can run that command yourself
<Chipaca> snappyc: it's also run automatically, so you don't have to
<snappyc> chipaca: snappy update doesnt work.  so i need to update manually
<Chipaca> snappyc: on your snappy personal?
<snappyc> yeah
<snappyc> how do i download ubuntu-core.snap?
<snappyc> wiggleworm: $ sudo date --set="Sun Apr 04 17:43:26 UTC 2015"
<Chipaca> snappyc: you can't update from personal to core, they are different things
<snappyc> personal has core
<snappyc> Chipaca: is there a ubuntu-core.snap  i can download?
<Chipaca> snappyc: I don't think so, no.
<Chipaca> snappyc: the base system is not (yet) itself a snap
<snappyc> :{
 * kgunn reads scrollback
<Chipaca> snappyc: and i'm not sure in what sense "personal has core", but whatever you're trying to do, it probably won't work
<Chipaca> snappyc: what are you running this on? a vm?
<snappyc> yep
<Chipaca> snappyc: so why not download the ubuntu-core image?
<snappyc> i did.. but if i can update ubuntu-personal... id like to stick with it
<kgunn> snappyc: why do you need ubuntu-personal ?
<snappyc> no reason
<wiggleworm> snappyc: sorry that did not work either (time change)
<snappyc> Chipaca: thx for the help
<Chipaca> wiggleworm: when you say "will not stick"
<Chipaca> wiggleworm: what do you mean?
<wiggleworm> Chipaca: stick as in - after I issue the change date command I check the date
<wiggleworm> time and its not changed
<Chipaca> wiggleworm: ok, so, two things
<Chipaca> wiggleworm: if you don't say --set or -s, date will just interpret the date you give it and print it out
<Chipaca> afaik at least
<Chipaca> wiggleworm: date --help might help
<wiggleworm> command that I am running "sudo date --set="Sun Apr 04 17:43:36 UTC 2015"
<wiggleworm> not the actual date, just an example
<wiggleworm> Chipaca: thanks, I tried date --help first - still no luck
<Chipaca> wiggleworm: also, note that snappy runs a time sync daemon
<Chipaca> wiggleworm: so maybe use timedatectl
<wiggleworm> Chipaca: what is that? time sync daemon
<Chipaca> wiggleworm: systemd-timesyncd.service
<Chipaca> wiggleworm: on a full ubuntu system, man systemd-timesyncd
<Chipaca> wiggleworm: also man systemd-timedated
<wiggleworm> Chipaca: Sorry I meant what does it do - I am guessing it syncs with some time server?
<Chipaca> wiggleworm: yes
<Chipaca> wiggleworm: although i think by default no server is configured, so it'll take them from dhcp if given
<Chipaca> wiggleworm: in any case, to set the time, timedatectl
<Chipaca> wiggleworm: thank you for asking this, btw, because i didn't know :)
<wiggleworm> Chipaca: thank you - I just maned the timedatectl and I see how I should do it. I also figured out that I needed to change the time zone - :) after that my time looked right
<Chipaca> wiggleworm: hah
<Chipaca> wiggleworm: that's one you set via snappy, fwiw
<Chipaca> defaults to etc/utc
<Chipaca> mvo: is there an easy way to get the tools ppa rebuild for x?
<mvo> Chipaca: all of it? I don't think so, may I ask for the use-case?
<Chipaca> mvo: dunno about "all of it" :)
<Chipaca> mvo: i mean, i'm moving to x
<Chipaca> mvo: should i worry about that ppa? :)
<mvo> Chipaca: do we have ppa builds for X already?
<Chipaca> mvo: no
<mvo> Chipaca: but sorry, let me reply properly
<mvo> Chipaca: I think its fine to not worry about the X ppa for now, we just push everything into X proper
<mvo> problem solved :)
<Chipaca> mvo: \o/
<tasdomas> If I deploy a snap with a service and a binary (two separate files), is the there something special I need to do to let the service run the binary?
<tasdomas> because currently /apps/bin is not in the PATH of the service
<Chipaca> tasdomas: you don't want to run things from /apps/bin from inside a service
<Chipaca> tasdomas: double-confinement won't work :)
<Chipaca> tasdomas: instead, do
<Chipaca> tasdomas: $SNAP_APP_PATH/bin/whatever
<tasdomas> Chipaca, thanks!
<Chipaca> np
<Chipaca> augh
<Chipaca> ogra_: looks like we messed something up :(
<mvo> Chipaca: whats broken?
<Chipaca> mvo: replied to jdstrand's mail in reply to your announcement
<Chipaca> mvo: not a regression though :)
<mvo> Chipaca: hrm, hrm, I need to look why the writable path change did not land, this is terrible
<Chipaca> mvo: no, it's not terrible
<Chipaca> mvo: it's just bad
<Chipaca> mvo: relax a little :)
<Chipaca> mvo: or maybe i just read too much panic in your "this is terrible"
<mvo> Chipaca: /me relaxes
<mvo> Chipaca: well, maybe its too stronly worded, sorry for that
<Chipaca> mvo: i mean, yes it's bad, but it's not a regression and has an easy fix
<jdstrand> yikes
<jdstrand> I didn't mean to stress people out
 * jdstrand just viewed it as a feature that didn't land
<jdstrand> hence the email rather than ping
<mvo> jdstrand: yeah, its fine, no worries
<mvo> sorry for using too strong language
<mvo> its just that I want things to be perfect :)
<jdstrand> well, if you typed it, you might be feeling it
<mvo> if it they are not "its terrible"
 * jdstrand hugs mvo :)
 * mvo hugs jdstrand and Chipaca
 * Chipaca hugs everybody
 * jdstrand hugs Chipaca :)
 * mvo will backport the fix tomorrow and calls it a day
<NuisanceValue> should I be using snappy and possibly docker? I have a small project which I was going to use a raspberry pi to capture images from an ip camera and rsyncing them to a remote server. Or should I just go for 14.04
#snappy 2015-10-27
<liuxg> hi, I have my raspberry pi 2 device. I do not have a HDMI display yet for it. I have flashed the Snappy software for it at the instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/. Now, I boot it, how can know it is booted? I connect it to my TTPlink router. I want to find its IP address to ssh login
<dholbach> good morning
<clobrano> morning all
<fgimenez> good morning
<shuduo> morning, anyone has made mir working as snap on arm platform like RPi2 or BBB?
<Chipaca> shuduo: not yet
<Chipaca> shuduo: that's blocked on mir having a software renderer i think?
<shuduo> Chipaca: can it be rendered by software render with bad performance?
<Chipaca> shuduo: I don't think it can, at present, but I'm not entirely sure.
<shuduo> Chipaca: :(
<supadupa> ??????
<dholbach> mvo, the diff in https://code.launchpad.net/~mvo/click-reviewers-tools/snappy/+merge/275058 looks like it has a conflict - I also had a question about the recommends: wouldn't it be better to just make it depends instead?
<mvo> dholbach: let me fix the conflict
<mvo> dholbach: not sure about the depends/recommends, I have no strong opinion
<dholbach> mvo, I just thought that if it's a recommends c-r-t would need a check if the tools are actually available
<mvo> dholbach: yeah, it will fail to unpack a squashfs and error in this case. I'm happy to make it a depends
<dholbach> oh ok... if we have the check, then I guess it's fine - I don't have a strong preference either
<mvo> dholbach: maybe you can mention it in the review and jamie can decide what he prefers?
<dholbach> sure
<dholbach> mvo, good work
<Chipaca> top of the morning, people!
 * Chipaca 's coffee kicked in
<dholbach> hey, good morning Chipaca
<Chipaca> dholbach: how's things?
<dholbach> good good - just scheduling UOS sessions :)
<dholbach> how about you?
<Chipaca> dholbach: no, not scheduling uos sessions :)
<dholbach> yeah, that would have surprised me :)
<JamesTait> Good morning all; happy Tuesday, and happy Cranky Co-Workers Day! ð
<ogra_> mvo, oops, sorry, i only landed the modules bits in wily it seems
<mvo> ogra_: no worries, I uploaded it to vivid now
 * ogra_ sighs, so much email backlog
<ogra_> mvo, sergiusens, so if i understand the oem snap change  correctly i now need to ship all the files that would live under /boot/overlay/* in the toplevel, need to mention each of them separately in the yaml and define a dst /boot/overlay/foobar.dtb ?
<sergiusens> ogra_, heh, mvo is working on it, not me ;-)
<sergiusens> ave you heard, I'm not doing provisioning anymore :-P
<ogra_> sergiusens, ah, i thought it was also a u-d-f feature
<sergiusens> it is ;-)
<ogra_> oh, not at all ?
<ogra_> k
<sergiusens> well I am helping out, but not driving features anymore
<mvo> ogra_: its a u-d-f feature but sergiusens is sneaking away from it. so I think /boot/overlay was not working at all before
<mvo> ogra_: now it works, would you prefer a glob? I'm not sure I understand the question, what will be needed? i.e. what should /boot/overlay/ look like eventually?
<ogra_> mvo, no, it wasnt, which is why i simply shipped a tarball of it on the RPi that the admin can extract
<mvo> ogra_: ok, now it does
<ogra_> mvo, the binary blob expects the overlay dtb's in the overlay subdir relative to where itself is stored (in oyur case /boot/overlay)
<mvo> ogra_: ok, thats support by u-d-f now, snappy does not yet have it
<ogra_> err
<ogra_> sorry
<ogra_> /boot/uboot/overlay
<mvo> oh
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /boot/uboot/over*
<ogra_> /boot/uboot/overlays.tgz
<mvo> /boot/uboot/overlay should already work
<ogra_> this is what i ship now
<ogra_> so you ave to cd /boot/uboot/ and tar xf that file
<ogra_> (RaspberryPi2)ubuntu@localhost:/boot/uboot$ sudo tar xf overlays.tgz
<ogra_> (RaspberryPi2)ubuntu@localhost:/boot/uboot$ ls -l overlays|wc -l
<ogra_> 40
<mvo> ogra_: so you want a glob to avoid to list the 40 things idividually?
<ogra_> it would indeed be good to have globbing, so i dont need 80 extra lines in the yaml ...
<ogra_> but at least it is better than before if i can somehow ship them by default without the untarring
<mvo> ogra_: hm, so if the target is /boot/uboot/overlay that should work now already, what am I missing? what failure do you get?
<ogra_> mvo, i'm not getting any failure :) i was asking if this works now
<ogra_> so i can change the build setup for the oem
<ogra_> (and get rid of the untarring)
<mvo> ogra_: it should also work before, it requires the files to be listed individually though
<ogra_> (before it simply ignored /boot/uboot/overlay completely, it didnt show up at all)
<mvo> ogra_: you can give it a "target: overlay/new-name" iin the yaml
<ogra_> ok, thats what i tried in the past and didnt work ...
<ogra_> if that works now i'm fine
<ogra_> (dirs were completiely ignored)
<mvo> ogra_: it should, lets talk after lunch
<ogra_> ok
<mvo> ogra_: no glob support yet though, that would have to be added
<ogra_> that would surely be helpful ... but i'm also fine defining two lines for each file
<ogra_> mvo, but we need to talk about dtb handling on RPi anyway ... since the dtb needs to be loaded by the blob before uboot and we have no way to make that happen from /boot/uboot/a|b ...
<ogra_> (so kernel upgrades will not work)
<Facu> Hola :)
<ogra_> hey hey :)
<Facu> sergiusens, so, what do you mean with "my cache"? in my host?
<ogra_> Facu, do you run multiple snappy installs in your lan (with each of them having a webdm) ?
<sergiusens> Facu, mdns is just multicast dns; something multicasts a name (webdm.local) and the clients cache it
<Facu> ogra_, no, only one (a raspi)
<ogra_> mDNS can indeed only assign that name once
<sergiusens> Facu, the cache should be as the ttl of the multicast dns entry (iirc)
<noise][> fwiw, we've seen that IP bug in a few different environments now
<noise][> cprov and I have both run into it as well, and for some odd reason it seems to resolve properly from OS X hosts but not from Ubuntu hosts
<ogra_> sounds like our avahi client setup might be buggy
<mvo> ogra_: yeah, maybe we can talk after the standup?
<ogra_> mvo, sure
<ogra_> btw ... could we probably fix the schedule somehow ?
<mvo> ogra_: sure, just create a meeting
<ogra_> i mean the standup one :)
<mvo> ogra_: oh
<mvo> ogra_: fix in the sense of moving it 1h later?
<ogra_> when brazil got DST it moved by 1h ... now that germany got DST it moved by another hour
<ogra_> so effectively (for me at least) it moved 2h
<ogra_> (15:00 local time for me instead of the former 17:00)
<sergiusens> ogra_, move one hour into the future again would not hurt :-)
<ogra_> i mean, i'm fine if we keep it that way but i think thats a bit early for the western countries
<ogra_> sergiusens, yeah
<sergiusens> ogra_, that way, it would be steady all year long for the saner countries ;-)
<ogra_> well, sane countries are rare in this case ... thats the prob :)
<longsleep> +1 for the snappy timezone
<mvo> fgimenez, elopio: if its trivial for you, it woudl be great if you could stop tarmac. the git move is happening today. if you are busy I can try to find the right card and do it myself (stop cron)
<longsleep> urgs snapcraft now has JSON schema
<fgimenez> mvo, ok on it
<mvo> thanks a lot fgimenez
<fgimenez> mvo, i've commented out the crontab entry, now it should be disabled
<mvo> fgimenez: \o/
<Chipaca> ogra_: why have bip and kiwi in the same snap? wouldn't them being separate be just as easy?
<ogra_> Chipaca, to make install and maintenance easier ...
<Chipaca> ogra_: ok :)
<plars> is there a good way to pass ssh options to snappy-remote?
<ogra_> Chipaca, i wouldnt drop the standalone ircproxy bip snap ... this would be more a "irc-client-phone-backend" project snap that actually bundles everything needed and has all bits hardwired
<ogra_> i.e. an "application backend" that ships all parts pre-configured already
<ogra_> indeed there could be standalone a kiwi snap too
<Chipaca> ogra_: three snaps: one bip snap, one kiwi snap, one ogra-badass-oem snap to tie them up and config them
<ogra_> Chipaca, i dont want to build an appliance
<ogra_> (you make it sound like i could just use oem as "metapackage" replacement)
<Chipaca> ogra_: i'm *shocked* you'd even *hint* at me saying something like that
 * Chipaca tries to deliver that without smiling
<ogra_> heh
<plars> sergiusens: is snappy-remote intended to be a supported tool? seems to be in a junk branch?
<plars> sergiusens: or should I just bypass it and do everything over ssh
<ogra_> plars, isnt it the same as ssh ... ?
 * ogra_ doesnt really see the advantage over just plain ssh
<plars> ogra_: I could do the same by just doing scp the package, install over ssh, yes
<sergiusens> ogra_, as soon as we use the rest api it will add more value
<plars> ogra_: it's just a convenience thing, and if it's a supported tool I'm happy to use it
<ogra_> ah
<plars> ogra_: but that's why I asked. I'm getting the impression I should just ignore it
<plars> for now at least :)
<ogra_> i surely do :)
<Facu> sergiusens, ogra_, noise][, it seems that webdm is answering the bad IP
<Facu> sergiusens, ogra_, noise][, remember, first ping webdm.local goes to 192.168.100.130, second one goes to 254.86.90.140
<Facu> sergiusens, ogra_, noise][, and this is the multicast dns response from the raspi: http://linkode.org/U6Tclhm1i4S9VcbmNjMEM6
<Facu> see line 98 there
<noise][> interesting
<Chipaca> Facu: what logs do you get from webdm? the Publish <....> are the ones i'm interested in
<Chipaca> Facu: sudo snappy service logs webdm
<Facu> Chipaca, http://linkode.org/DnzzdEWN8dffBE3FkpCzk2
<Facu> Chipaca, see the IPv6 in the last line of the logs, the weird IPv4 returned in the mdns response, and this:
<Facu> >>> 0xfe, 0x56, 0x5a, 0x8c
<Facu> (254, 86, 90, 140)
<Chipaca> that was what i was looking at just now, indeed
<Facu> it looks like it's adapting the IPv6 to a IPV4 to fit in the mdns response using... a hammer?
<Chipaca> Facu: yes, but i'm not sure who 'it' is in that sentence
<Facu> Chipaca, neither do I, for sure
<sergiusens> Facu, that is why I asked for the webdm logs ;-)
<sergiusens> Chipaca, we need to skip ::1
<sergiusens> Chipaca, and we can probably just ignore ipv6 in general
<Facu> sergiusens, who is "we"?
<noise][> i disabled ipv6 on my trusty vm and it gets the right IP after
<Chipaca> it's webdm building the wrong rr
<Chipaca> using a instead of aaaaaaaaaaahrgh
<sergiusens> elopio, care to rejoin?
<elopio> sure
<elopio> mvo: your msg branch needs a po update.
<mvo> elopio: will do that, thanks!
<dholbach> ppisati, can we do something about https://bugs.launchpad.net/snappy/+bug/1506480?
<ubottu> Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New]
<elopio> ogra_: we are getting the watchdog config error, the one that says it's read-only.
<elopio> But I see that the last wily commits are your fixes
<Chipaca> Facu: noise][: can i give you a new webdm to try?
<noise][> sure, probably in 20' or so
<Facu> Chipaca, yes, please
<Chipaca> Facu: noise][: http://people.canonical.com/~john/webdm_0.9.4_multi.snap
<Facu> Chipaca, is there a way to install it directly into the raspi?
<Chipaca> Facu: sudo snappy install http.chipaca
<Facu> awesome
<Chipaca> Facu: http.GET http://people.canonical.com/~john/webdm_0.9.4_multi.snap > webdm.snap
 * Facu installs a chipaca
<Chipaca> Facu: sudo snappy install ./webdm.snap
<Facu> Chipaca, no http.GET or wget in the raspi
<Chipaca> Facu: but you just got it by installing http.chipaca
<Facu> oh, right
<Facu> sorry
<Chipaca> :)
<Facu> Chipaca, just because it may be useful for you: 2015/10/27 15:15:48.720387 verify.go:85: Signature check failed, but installing anyway as requested
<sergiusens> Chipaca, elopio initial thoughts? https://code.launchpad.net/~sergiusens/snapcraft/help/+merge/275858
<Chipaca> Facu: yep, that's expected
<Facu> Chipaca, it doesn't want to install it because there's other package already installed with same name... should I remove the old one, or do an upgrade?
<Chipaca> Facu: remove it, yeh
<ogra_> elopio, which one exactly, there were two
<Chipaca> sergiusens: the âcan be used in any part irrespective of the pluginâ seems to be stronger than what you were describing yesterday
<sergiusens> Chipaca, there are two; what I was describing yesterday is what is in sources
<sergiusens> Chipaca, those are builtin keywords
<sergiusens> oh and ted https://code.launchpad.net/~sergiusens/snapcraft/help/+merge/275858
<Chipaca> sergiusens: print(getattr(_TOPICS[module_name], '__doc__'))
<Chipaca> sergiusens: why not _TOPICS[module_name].__doc__ instead of the getattr?
<sergiusens> Chipaca, hah, that is indeed better
<Chipaca> sergiusens: the getattrs are getting to you :)
<clobrano> I'm having a problem with a snap that contains both a binary and a shell script. I'm using security-template: unconfined, but when the binary (called by the script) tries to access an assigned serial device I got this error: ubuntu-core-launcher: error while loading shared libraries: cannot apply additional memory protection after relocation: Permission denied. Any idea?
<sergiusens> Chipaca, the only sucky thing, and elopio pointed it out is if I do a 'help' against this I get a mix of markdown and whatever python's help does
<Chipaca> clobrano: sounds like you're doing a double-wrap
<Chipaca> clobrano: your binaries should just call your binaries
<sergiusens> clobrano, as in the non exported ones; also read as, the internal ones
<jdstrand> or put another way. call them from SNAP_APP_DATA
<Chipaca> SNAP_APP_PATH
<jdstrand> meh
<Chipaca> :)
<jdstrand> yes, SNAP_APP_PATH
<jdstrand> :)
<Chipaca> although some people are copying the whole snap to SNAP_APP_DATA because their binaries write stuff (?)
<Facu> Chipaca, http://linkode.org/DnzzdEWN8dffBE3FkpCzk2/XoBMe0RVZe8azht6zd0061
<sergiusens> if you built it with snapcraft some things inside there are already in your PATH (./bin, ./usr/bin)
<Facu> Chipaca, doing multiple pings now it works!!!
<Facu> Chipaca, I assume that the mdns response comes ok
<Chipaca> Facu: shocking!! :)
<Facu> Chipaca, you'll publish this new webdm?
<Chipaca> Facu: i'll have sergiusens check the code, and then ask him to publish it, yes :)
<sergiusens> mvo, about the comment from gustavo, I feel it might be good to use target-absolute instead of dst; are we too late to change that?
<jdstrand> clobrano: do you have snappy-debug installed? you could run in another console 'sudo snappy-debug.security scanlog' and it will give you suggestions (your case here is detected)
<Facu> Chipaca, gracias :)
<mvo> sergiusens: we can do that, I think target-abolute is better indeed
<noise][> Chipaca: many thanks for the quick fix there
<clobrano> jdstrand: unfortunately snappy-debug crashes with an UnicodeDecodeError...
<sergiusens> mvo, I approved the size one btw
<mvo> sergiusens: ta
<Chipaca> sergiusens: https://code.launchpad.net/~chipaca/webdm/mdns-nicer-with-ipv6/+merge/275866 when you have a mo
<sergiusens> mvo, but I leave the addition of the commit message to you
<sergiusens> Chipaca, I have moments now, idling waiting for comments on that help branch now ;-)
<jdstrand> clobrano: interesting. can you file a bug? alternatively, can you paste the output of 'sudo grep audit /var/log/syslog'
<jdstrand> ?
<clobrano> jdstrand: sure I'll do it
<jdstrand> clobrano: if you file a bug, please attach /var/log/syslog
<clobrano> jdstrand: SNAPP_APP_PATH is? I tried all the dirs starting from /apps/<package-name>/, but the result's the same
<sergiusens> Chipaca, no need for reverse lookups?
<jdstrand> SNAP_APP_PATH
<clobrano> jdstrand: yep, typo, SNAP_APP_PATH
<Chipaca> sergiusens: you weren't doing them before, so Â¯\_(ã)_/Â¯
<jdstrand> it is /apps/<pkgname>/<version>/
<sergiusens> Chipaca, hah, touche
<clobrano> jdstrand: ok, tried but still the same
<Chipaca> clobrano: how are you exec'ing the other program, in your program?
<Chipaca> sergiusens: http://people.canonical.com/~john/webdm_0.9.4_multi.snap <- publish plz :) tested by facu
<clobrano> Chipaca: is <programname>.<programname> inside the script
<Chipaca> clobrano: why programname.programname?
<Chipaca> clobrano: say you have two programs
<Chipaca> clobrano: one in bin/foo, one in bin/bar
<Chipaca> clobrano: say foo is a shellscript
<Chipaca> clobrano: to run bar, you do: $SNAP_APP_PATH/bin/bar
<elopio> ogra_: sorry, they started cutting down the power here :@
<Chipaca> clobrano: bin/bar doesn't even need to be in your package.yaml, even
<elopio> ogra_: so I see your two fixes in the wily package in the ppa.
<ogra_> right
<clobrano> Chipaca: it's the opposite, actually. Is the script that calls the binary. So I have bin/foo, which I can call typing pkgname.foo. Inside foo I call the binary using pkgname.bar
<Chipaca> clobrano: yes, you do, and that's why it fails
<ogra_> elopio, so show me the exact error ....
<Chipaca> clobrano: that's what i'm telling you
<Chipaca> clobrano: don't do that
<elopio> ogra_: Error: open /etc/default/watchdog.HXUWIktPalrj: read-only file system
<clobrano> Chipaca: get it, $SNAP_APP_PATH/bin/bar is the right way to do it?
<Chipaca> clobrano: yes
 * clobrano tries 
<ogra_> elopio, and /etc/default/watchdog is a link to /etc/writable/default/watchdog ?
<elopio> ogra_: give me a second to check that.
<clobrano> Chipaca, jdstrand: that works, thank you. Of course I have another problem now :D but not sure is cause by snappy
<Chipaca> clobrano: i'm sure it is :-p
<clobrano> Chipaca: ahaha, don't know. Just the binary is blocked opening the device :|
<clobrano> Chipaca: might be the device
<fgimenez> elopio, have you seen IS email? we can finally access scalingstack from canonistack's lcy01 \o/
<elopio> fgimenez: yes :)
<elopio> fgimenez: have you tried it?
<fgimenez> elopio, yep, i've been playing around, the key is in tarmac's host
<elopio> ogra_: there is no /etc/writable/default
<elopio> and /etc/default/watchdog is not a link.
<elopio> fgimenez: great, thanks!
<ogra_> thats the issue then
<ogra_> is that a recent image ?
<fgimenez> elopio, we need to make some adjustments in snappy-tests-job, i'll prepare a branch
 * ogra_ goes to check the rootfs build logs if anything with the linking went wrong
<fgimenez> elopio, there are no snappy images in scalingstack, we must upload our own, snappy-cloud-image fits here well :)
<elopio> fgimenez: just in time :D
<ogra_> hmm
<ogra_> I: Moving /etc/watchdog.conf to /etc/writable/
<ogra_> I: Linking /etc/watchdog.conf to /etc/writable/
<ogra_> I: Moving /etc/default/watchdog to /etc/writable/default
<ogra_> I: Linking /etc/default/watchdog to /etc/writable/default
<ogra_> the log for the last stable image looks fine
<Chipaca> sergiusens: sorry this review is taking long -- getting sidetracked a lot
<ogra_> elopio, we are talking about stable, right ?
<elopio> ogra_: this is rolling edge #208 generic amd.
<ogra_> oooh
<ogra_> elopio, bah, sigh ... the change went to the PPA livecd-rootfs because the distro was in final freeze, seems that even though it was frozen, a newer livecd-rootfs ended up in wily ...
<ogra_> i'll bump the version
<niemeyer_> Folks, I'm starting the dance to move the code into GitHub..
<niemeyer_> mvo: Is Tarmac frozen?
 * tedg hopes this is like a rain dance
<elopio> thanks ogra_
<elopio> niemeyer_: yes, tarmac is not running.
<niemeyer_> tedg: Pretty much :)
<niemeyer_> elopio: Thanks
<ogra_> niemeyer_, videos please :)
<clobrano> jdstrand: where's the right place to file the bug? Under the snappy project itself?
<niemeyer_> ogra_: Ah, that wouldn't work.. the vcs gods don't like soul-stealing devices
<ogra_> lol
<jdstrand> clobrano: yes, that's fine
<clobrano> jdstrand: ook
<ogra_> elopio, i assume it was fine in stable when you tested for the release  (just to make sure)
<ppisati> dholbach: i commented lp1506480
<dholbach> thanks ppisati
<sergiusens> Chipaca, no worries, I'm going for lunch; my only big regret and open is handling markdown and python help
<sergiusens> oh, elopio told me to reach out to alecu for that
<Chipaca> oh, i dunno, alecu is a *manager* now
<Chipaca> we are not worthy
<Chipaca> :-D
<sergiusens> alecu, do you know how to write fancy titles in python docstrings
<sergiusens> you have to come full circle, right? :-)
<dholbach> ppisati, brilliant - I'll change it
<mvo> niemeyer_: yes, tarmac is out of cron
<sergiusens> mvo, ah, you kill all of tarmac and not just lp:snappy? That explains why other projects aren't landing ;-)
<niemeyer_> Hmm.. strange..
<niemeyer_> Got a complaint about tags
<niemeyer_> 14:09:10 WARNING: not creating tag u'\t' pointing to non-existent revision G1szODs1OzIyNm0bWzQ4Oz......
<niemeyer_> and the output of "bzr tags" indeed seems dirty
<mvo> sergiusens: you move as well, no?
<niemeyer_> Is it just me?
<mvo> niemeyer_: uh, indeed
<elopio> ogra_: yes, stable passes the test.
<ogra_> phew
<Chipaca> sergiusens: reviewed! phew
<Chipaca> niemeyer_: no, it's not just you
<Chipaca> niemeyer_: that's my fault, or bzr's fault
<Chipaca> niemeyer_: you can delete those two tags locally
<Chipaca> but lp seems to resurrect them
<niemeyer_> Chipaca: Ok, no worries.. the import process seems to have filtered out exactly the bad ones
<clobrano> jdstrand: I had a look at snappy-debug, a possible fix would be to open the codecs adding the argument errors='replace' (codecs.open(path, 'r', encoding="UTF-8", errors='replace')).
<Chipaca> niemeyer_: ah, good
<jdstrand> clobrano: thanks!
<clobrano> jdstrand: I mean, with that change, the crash does not occur anymore on my env, but I'm not sure t'is acceptable as solution
<jdstrand> I'll take a look
<jdstrand> clobrano: can you also add the output of this to the bug: set|egrep '(LC_|LANG)'
<clobrano> jdstrand: sure
 * clobrano done
<Chipaca> jdstrand: have you been able to look at https://code.launchpad.net/~c-lobrano/snappy/hw-assign-symlink/+merge/274908 at all?
<sergiusens> Chipaca, thanks for the review
<Chipaca> sergiusens: you say that, but :)
<ogra_> elopio, i kicked off a new rolling build
<Chipaca> jdstrand: sys:1: PyGIWarning: Click was imported without specifying a version first. Use gi.require_version('Click', '0.4') before import to ensure that the right version gets loaded.
<elopio> :)
<jdstrand> Chipaca: re click-apparmor. I can fix that. fyi, still chipping away at removing click-apparmor/go rewrite
<Chipaca> jdstrand: i never doubted it
<longsleep> Hey folks, anyone knows when/if the /tmp/snap.* folders are supposed to be cleaned up?
<Chipaca> jdstrand: that warning is brought to you from xenial, btw
<Chipaca> longsleep: right now, never
<longsleep> Chipaca: ok - simple enough answer
<Chipaca> longsleep: eventually, we want something like tmpreaper
<Chipaca> longsleep: but it's not there yet
<longsleep> Chipaca: any suggestions what i could do in the meantime?
<Chipaca> longsleep: if it's becoming an issue, file a bug and let us know
<Chipaca> longsleep: we've only not done anything because it's not been an issue
<Chipaca> and, priorities
<longsleep> Chipaca: well, every command run does create a new temp file when that command is from a snap
<longsleep> temp folder i mean
<longsleep> run hello-world.env 1000 times - you have 1000 temp folders
<Chipaca> longsleep: yes. otoh /tmp is tmpfs, so you're not going to run out of inodes or anything
<Chipaca> you will eventually run out of space though
<longsleep> Chipaca: right, but if there are files in it it eats ram
<Chipaca> longsleep: care to file a bug?
<jdstrand> Chipaca: regarding that branch-- fyi, I didn't write the hw-assign udev bits and I wasn't sure how this fit into the future direction for hw assignment, which is why I haven't been looking at it. I figured a snappy core/architect would look at it and I could be pulled in to verify (ie, once the implementation and approach was deemed ok)
<longsleep> Chipaca: sure
<Chipaca> jdstrand: good point. ok.
<Chipaca> oh, wait
<Chipaca> longsleep: hold on
<Chipaca> longsleep: we might actually be doing automatic cleanup already
<Chipaca> longsleep: AFAIUI we're running systemd-tmpfiles --clean once a day
<longsleep> Chipaca: oh? i just filed bug #1510638 which is slightly different from automatic cleanup
<ubottu> bug 1510638 in Snappy "Per process tmp folders in /tmp/snap.0* are not removed" [Undecided,New] https://launchpad.net/bugs/1510638
<alecu> sergiusens: Chipaca: I didn't get the bit about me helping with python docstrings...
<alecu> I thought nessita was the authority there
<Chipaca> alecu: sergiusens is a struggling artist of the docstring scene
<sergiusens> Chipaca, ok just pushed your review fixes
<sergiusens> alecu, heh, elopio said either or :-P
<elopio> alecu: I imagined you had  something to do with the u1 clients man.
<longsleep> whooohooo https://github.com/ubuntu-core/snappy !! Now if snapcraft would move to GitHub too - that would be aweseome!
<sergiusens> hey elopio neither you or me show up as contributors :-P
<elopio> sergiusens: we are not wanted :'(
<sergiusens> elopio, we do show up in the commits though :-P
<elopio> sergiusens: I see my face in some commits.
<sergiusens> alecu, nessita so as the docstring folk I'd like to ask: is there an easy straighforward way to override 'help' so it doesn't show the __<atrib-name>__'s such as __weakref__ et. al.? The other one is, are there any formatting rules I can use?
<elopio> sergiusens: I think it's because I am missing the canonical email in my account
<sergiusens> elopio, ah
 * sergiusens tries
<sergiusens> elopio, nope
<nessita> sergiusens, never done that... google does not know?
<sergiusens> nessita, google might know, I'm sure I just haven't done the right search :-)
<sergiusens> there is no way google can't know :-P
<alecu> sergiusens: elopio: I think after changing/adding emails in github it takes a while until contributions start showing properly.
<sergiusens> seems I need to fork pydoc which I don't want to :-)
<alecu> sergiusens: formatting rules: https://www.python.org/dev/peps/pep-0257/
<alecu> sergiusens: and, if help(dict) shows all the __xxx__ methods, why do you worry about not showing yours?
<sergiusens> alecu, right, all good with the peppy stuff ;-) Just wondering if there was a way to say "bold" :-)
<sergiusens> alecu, I don't want to show them because elopio asked me not to :-P
<alecu> sergiusens: elopio: I just did "import httplib; help(httplib)" and I can see *a lot* of __weakref__'s
<elopio> alecu: right, but they don't show them in the man page.
<elopio> sergiusens is trying to autogenerate the man from docstrings. And I think it's showing too much info.
<elopio> sergiusens: I think you can generate the man with sphinx. So you choose the format and what to show.
<alecu> sergiusens: elopio is right, sphinx is what you want there.
<alecu> also, define the __all__ list at the toplevel of the module, so only those symbols are "public" and I guess the doc generators have some smarts regarding that.
<sergiusens> elopio, oh, I don't want to generate a man page
<elopio> well, a help page. Almost the same :)
<sergiusens> elopio, but with --devel as a switch ;-)
<ogra_> argh
<ogra_> mvo, seems we cant build rolling anymore
<ogra_> the builds already point to xenial and that completely fails
<sergiusens> alecu, elopio is it easy to generate documentation on the fly with sphinx?
<sergiusens> all the intros I've seen require a lot of setup
<alecu> sergiusens: no idea there
<alecu> sergiusens: it seems that a little of markup is allowed on python docstrings: http://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
<alecu> and https://pythonhosted.org/an_example_pypi_project/sphinx.html#full-code-example
<sergiusens> elopio, Chipaca so for the general case I'm not going to worry about sphinx as this looks good to me http://paste.ubuntu.com/12981760/
<ogra_> mvo, so i did a final wily image build manually now ... nightly rolling will build xenial by default then
<ogra_> mvo, tomorrow we need to check what we want to copy around in the PPA and what should instead go to the archive, i think this is the moment to clean up the PPA bits for the next release :)
<elopio> ogra_: \o/ xenial
<ogra_> heh
<elopio> sergiusens: that looks good. I'm not quite sure about starting with a new line, but looks nice.
<sergiusens> elopio, oh, it is because my docstrings are not right after """ I can fix that
<sergiusens> elopio, ok, pushed that, I'll wait for your review
<elopio> sergiusens: I would leave the deprecated comment for when you do the deprecation.
<sergiusens> elopio, ok
<sergiusens> elopio, done
<elopio> sergiusens: the key is the internal filename whilst the value *IS* the exposed filename
<sergiusens> elopio, ah, there used to be a comma there... :-)
<sergiusens> done
<elopio> sergiusens: on the topic docstring, you are using ''' instead of """
<sergiusens> elopio, where? I thought I switched, but habits :-)
<elopio> sergiusens: do you want the review here or in the branch?
<elopio> l192
<sergiusens> elopio, done
<elopio> sergiusens: l222, s/exists/exist/
<elopio> sergiusens: l251, s/topis/topics/
<elopio> sergiusens: The maven plugin is useful for building parts that use the maven.
<elopio> I supposed you are missing a word after the second maven, but I doubt it will fit in 88 chars.
<sergiusens> elopio, let me rephrase
<elopio> maybe: The plugin is useful for building parts that use maven.
<sergiusens> elopio, word! :-)
<elopio> sergiusens: and feel free to top-approve after that, because I'm starving.
 * elopio leaves for lunch.
<alecu> So, it's *the* Dan Kegel (of C10K fame) the one asking about binary video drivers packaged for snappy...
<alecu> I wonder if he wants to use snappy for mezzanine: http://www.oblong.com/
<alecu> it looks really slick
<sergiusens> elopio, great I had already pushed ;-)
<sergiusens> elopio, is tarmac on again?
<sergiusens> mvo, or was it you driving tarmac disabling/enabling?
<tedg> alecu: I hope so, I think we'll need test system though... to help with... collaboration.
<mvo> sergiusens: I was driving the disable
<mvo> sergiusens: I mean, I asked for it
<mvo> sergiusens: if we just disable snappy, thats all I need
<sergiusens> mvo, great, your goget branches are stuck too btw ;-)
<alecu> sergiusens: btw, it seems that the dev portal is already using sphinx for some of our APIs:
<alecu> https://myapps.developer.ubuntu.com/docs/api/click-purchases.html
<alecu> https://myapps.developer.ubuntu.com/docs/api/iap.html
<alecu> sergiusens: that means that all the styling bits should be solved
<alecu> sergiusens: I understand that the deploy bits too, but I'm guessing you want this to be run on 3rd party devels build environments.
<sergiusens> alecu, yes, I want it to be interactive and local. In any case; we've moved to the model of writing markdown and d.c.c pulls that in automatically for actual portal docs. With the popularity of github I've seen some projects drops sphinx in favor of githubs internal renderer which to be honest is the perfect balance between simplicity and elegance
<AlekMabry> Hello!
<AlekMabry> When you create a snappy app, can you add applications installed with apt-get to it?
<AlekMabry> I am making an application that relies on flite, installed with 'sudo apt-get install flite'
<AlekMabry> But I don't know how to include flite in my snappy application
#snappy 2015-10-28
<dholbach> good morning
<fgimenez> good morning
<tetor1> good evening (from Tokyo)
<mvo> hey good morning fgimenez and tetor1
<mvo> tetor1: well, good evening for you of course :) still morning here in europe
<fgimenez> hi mvo :)
<mvo> I'm looking for ideas how to do git branches similar to bzr pipelines or LPs prerequiste branches model so that I can work on a set of changes but broken into smaller branches
<mvo> fgimenez or Chipaca, any ideas?
<fgimenez> mvo, afaik you could branch from a base branch, which would be the equivalent of the prerequisirte, but i think that nothing prevents you from merging the dependent branch before its dependency (which would merge the complete diff)
<fgimenez> mvo, imo the model is different here, the work should be split in small chunks and rebased frequently to master, or the long lived branch taken as base
<Chipaca> mvo: you create a long-lived staging branch, do your work against that, then merge that into trunk? isn't that the git way?
<Chipaca> mvo: what fgimenez said
<Chipaca> mvo: but i'm not a git expert at all
<mvo> Chipaca, fgimenez: thanks, I will try that
<zyga> good morinng
<clobrano> good morning all
<Guest42341> noooooooooooooooooooo!
<Chipaca> what on earth is up with that guy
<Chipaca> s/guy/person
<clobrano> wrong chat, I suppose :D
<clobrano> is there any string I can get from shell that differentiate Snappy from other Linux distro?
<Chipaca> clobrano: not afaik. I think /etc/ubuntu-build is there on both snappy and click for example
<Chipaca> clobrano: wrt wrong chat, no: Guest42341 comes in every day, shouts something, and goes away
<clobrano> Chipaca: about Guest42341 I did'n know :D
<Chipaca> clobrano: and now that i've said two things with the same length I've got to try to say more
<clobrano> Chipaca: ok for the string, I'll ask the user to select the OS ;)
<longsleep> Chipaca: Hey, i am still having issues with seccomp and Nginx on snappy. Would you eventually have some time to help me figuring out why exactly i see no audit logs for seccomp and Nginx just works when i add @unrestricted to its profle, but does not with snappy common + networking + network-service?
<Chipaca> longsleep: sure, bring it on. At least until somebody more knowledgeable on seccomp/apparmor shows up :)
<longsleep> Chipaca: ok awesome - first thing i do not understand is if i should get seccomp reject messages in syslog
<longsleep> (or how they would look)
<Chipaca> longsleep: if seccomp is what's blocking things, yes you should
<longsleep> Chipaca: yeah i thought so too, but i do not have a single seccomp message in my log
<Chipaca> longsleep: and sc-logresolve should find those for you
<longsleep> Chipaca: yeah - that command shows nothing unfortunatly
<Chipaca> longsleep: and no DENIED either?
<longsleep> Chipaca: i only see DENIED when running with @unrestricted in the seccomp profile (apparmor DENIED)
<longsleep> Chipaca: like this http://paste.ubuntu.com/12988041/
<Chipaca> interesting!
<longsleep> but this is with @unrestricted - if i run restricted it just crashes when forking without any message to the logs
<Chipaca> longsleep: and âsudo snappy service logsâ doesn't give you anything either?
<longsleep> Chipaca: nothing related to audit
<longsleep> Chipaca: i also have a hard time to figure out where it is crashing. The syscalls it is using are all in the seccomp profile.
<longsleep> Chipaca: so i am trying to figure out why @unrestricted makes it work
<Chipaca> longsleep: have you strace'd it with and without?
<Chipaca> longsleep: (the strace needs to go outside of confinement -- if it's a service, in the .service file)
<longsleep> Chipaca: How can i strace it when a child process is crashing but the main process works fine?
<longsleep> Nginx uses a master process, which works fine, that spawns worker processes - and those crash when
<longsleep> started
<longsleep> or created - not sure
<Chipaca> longsleep: strace -f follows forks
<longsleep> ok let me try that
<Chipaca> longsleep: strace -ff splits each fork's trace into a different file
<Chipaca> longsleep: you'll have to copy strace in
<longsleep> Chipaca: that might help in figureing out why it crashes
<longsleep> Chipaca: sure - hold on a sec
<longsleep> What i still do not get is why i do not get seccomp logs though
<Chipaca> longsleep: yeh. You should be seeing logs, so that's a question for jdstrand i think
<longsleep> I mean i run kernel 3.10 - maybe i am missing something there but i have checked and did not find anything
<Chipaca> oh, that's fairly old isn't it?
<Chipaca> $ uname -r
<Chipaca> 4.2.0-16-generic
<Chipaca> yeesh
<longsleep> Chipaca: yeah - ODROID is sadly stuck at 3.10
<Chipaca> longsleep: anyway, strace should shed light on it one way or another
<longsleep> ok i got strace now
<longsleep> Chipaca: ok the crash case seems simple: http://paste.ubuntu.com/12988105/
<Chipaca> longsleep: that's seccomp alright
<Chipaca> longsleep: you need to know what comes *next* though :)
<longsleep> yeah on it
<Chipaca> :)
<longsleep> setgid32(0)
<longsleep> thats next
<longsleep> ah i see and that is commented in the profile
<longsleep> # snappy doesn't currently support per-app UID/GIDs so don't allow this family
<longsleep> # of syscalls. To properly support these, we need to have syscall arg filtering
<longsleep> # (LP: #1446748) and per-app UID/GIDs.
<ubottu> Launchpad bug 1446748 in ubuntu-core-security (Ubuntu) "implement seccomp filtering by argument" [Wishlist,Triaged] https://launchpad.net/bugs/1446748
<longsleep> Chipaca: that was helpful - thanks!
<JamesTait> Good morning all; happy Wednesday, and happy International Animation Day! ð
<longsleep> Chipaca: so what do i need to do, to get some seccomp profile which allows this?
<Chipaca> longsleep: can't you tell nginx not to switch users?
<longsleep> Chipaca: no :/
<longsleep> Chipaca: it always switches to whatever configured or nobody when run as root
<longsleep> Chipaca: only way it will not switch is when not run as root
<Chipaca> longsleep: we need to poke jdstrand then
<Chipaca> longsleep: maybe allowing just switching to nobody is possible
<longsleep> Chipaca: yeah that would be a good idea probably, but as long as bug #1446748 that might be hard
<ubottu> bug 1446748 in ubuntu-core-security (Ubuntu) "implement seccomp filtering by argument" [Wishlist,Triaged] https://launchpad.net/bugs/1446748
<longsleep> Ah i just found why i missed finding the syscall in the first place
<longsleep> Linux 2.4 added setgid32() supporting 32-bit IDs. The glibc setgid() wrapper function transparently deals with the variaâ tion across kernel versions
<longsleep> "transparent wrapper function" ...
<Chipaca> glib is full of those
<longsleep> Chipaca: so i can fix this by patching Nginx - leaves the issue why i cannot see seccomp denies in the logs
<longsleep> Chipaca: another approach would be if snappy would somehow run a service as non root
<longsleep> Chipaca: the check in nginx is simple: if (geteuid() == 0) {
<Chipaca> mvo: wrt https://travis-ci.org/ubuntu-core/snappy/builds/87841510, comment out or skip the last line in that test
<mvo> Chipaca: thanks, I will do that now, I was not sure what its doing
<Chipaca> mvo: trying to test that which go deems unknowable
<mvo> Chipaca: yeah, I figured it from your conversation from last night :)
<Chipaca> mvo: all the branches are blocked by that, so maybe i should make a separate branch just for this
<Chipaca> mvo: what say you
<mvo> Chipaca: yeah, I was thinking the same
<Chipaca> ok, coming up
<mvo> Chipaca: how does https://github.com/ubuntu-core/snappy/compare/ubuntu-core:master...mvo5:bugfix/fix-daemon-vet-issue?expand=1 look?
<Chipaca> mvo: that's relying on the same undefined behaviour
<Chipaca> fighting with git now, it doesn't want to push stuff
<Chipaca> but i've got a branch for it
<mvo> Chipaca: I have no strong opinion but it seems like we can add a comment and once the undefined behavior actually bites us we remove the test
<mvo> Chipaca: it seems right now undefined means "may change in future compiler versions"
<mvo> Chipaca: but if removing is the better option, I don't mind
<Chipaca> gah
<Chipaca> how do i set a branch's "upstream"?
<morphis> ogra_, mvo: you know if /etc/network/interfaces.d/eth0 is present in all Ubuntu Core snappy images by default?
<mvo> Chipaca: not sure I understand the question? hangout?
<mvo> morphis: it wil generated on first boot
<ogra_> morphis, it gets created on firstboot by snappy config
<morphis> so lets say, when I have a image with the network-manager snap included I just need to change the snappy configuration of the image at build time?
<ogra_> if you have an oem snap that defines that the nm-snap gets included you can also set default config options in its yaml file for snappy config
<morphis> ok
<ogra_> i dont think we have a way to not create the file at all though ( Chipaca would know if thats possible)
<Chipaca> other than not having an ethernet device, no there isn't
<Chipaca> morphis: what's breaking?
<morphis> Chipaca: nothing
<ogra_> nobody said anything is broken :)
<morphis> Chipaca: however as we have network-manager now we want network-manager to control eth0 rather than ifupdown
<morphis> I could just teach networkmanager to still use eth0 even if its configured through eth0
<Chipaca> i'd rather we taught snappy a new config option
<ogra_> Chipaca, well, nm is in a snap ... you dont want that option in ubuntu-core i guess
<ogra_> /etc/NetworkManager/NetworkManager.conf has the "managed=" option for that ...
<ogra_> so you want to have a config option in the nm snap that sets it and have your oem snap set this to true
<ogra_> (that way an admin/integrator can still disable it and keep the wired config in ubuntu-core if wanted)
<morphis> ogra_: I see
<ogra_> mvo, so i managed to get the rolling edge images to build again after all of LP was switched to xenial ...
<ogra_> mvo, can we go over https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=wily and see what needs to be forward copied for xenial (and what goes to the archive instead)
<ogra_> since ubuntu-snappy 1.6 was never uploaded to wily i assume we want to forward port it ? apparmor and ubuntu-core-config seem fine to come from the archive ... i'm not sure about the go* packages in that list
<ogra_> s/forward port/forward copy/
<ogra_> (btw, 209 is our first xenial image in rolling/edge, if anyone wants to test that)
<Chipaca> mvo: https://github.com/ubuntu-core/snappy/pull/21 and thanks again
<mvo> Chipaca: could you please remove the "fmt" import in there too and just "git commit --amend" and "git push -f"?
<Chipaca> mvo: you mean, actually run tests?
<mvo> Chipaca: well, thats not needed :P
<mvo> Chipaca: travis is doing that for you and tells you it's failing
<Chipaca> sorry, got carried away with this argh-why-is-push-not-working and forgot i was actually in the middle of it
<mvo> Chipaca: no problem at all
<Chipaca> mvo: https://github.com/ubuntu-core/snappy/pull/21 is green
<dholbach> tedg, will snapcraft move to github too?
<Chipaca> mvo: any idea why git is angry-red-highlighting the second-plus lines in the pot diff in https://github.com/ubuntu-core/snappy/pull/14/files ?
<ogra_> dholbach, ??
<dholbach> ogra: mh?
<ogra_> (community sync)
<ogra_> (another meeting that nicely moved 2h)
<dholbach> oops.... sorry
<dholbach> I'll be right there
<mvo> ogra_: thanks, I think we pretty much want it all in the archive
<mvo> Chipaca: I don't know why its angry red, sorry
<Chipaca> mvo: and do you know how to ask travis to do its thing again?
<Chipaca> there's supposed to be a "rebuild" button, but i can't even find the build tab :)
<mvo> Chipaca: I'm dong that now, there is a retry button
 * ogra_ notes down "mvo is dong now"
<Chipaca> ogra_: "dong that"*
<mvo> *cough*
<mvo> doing
<mvo> DOING
<mvo> *sigh*
<Chipaca> mvo: too late, your profile has been updated
 * ogra_ grins evil 
<longsleep> Chipaca: Patch to make Nginx run on snappy: http://paste.ubuntu.com/12989119/
<Facu> morning!
<Facu> question: how can I know (manually, like browsing a web page) which version of a snap is published? thanks!
<Chipaca> Facu: are you the owner of the snap?
<Facu> Chipaca, nop
<Chipaca> Facu: GET -H "Accept: application/hal+json"  -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1' -H 'X-Ubuntu-Architecture: armhf' -H 'X-Ubuntu-Release: 15.04-core' -H "X-Ubuntu-Device-Channel: stable" https://search.apps.ubuntu.com/api/v1/package/webdm
<Chipaca> Facu: for example
<Facu> Chipaca, ah, no web page?
<Facu> Chipaca, thanks!
<Chipaca> Facu: i'm not sure web pages know about channels yet
<ogra_> Facu, https://uappexplorer.com/apps?type=snappy
<ogra_> (thats a community page for phone apps, but it also lists snaps)
<Chipaca> yeah, was just about to point at https://uappexplorer.com/app/webdm.canonical
<Chipaca> Facu: version is in the "info" tab
<Chipaca> but, no channels
<Facu> awesome!
<Facu> Chipaca, ogra_, thank you very much
<Chipaca> Facu: that'll be (another) beer
<Facu> Chipaca, we don't drink enough beers together :/
<Chipaca> Facu: i agree
<zyga> sergiusens: hey
<sergiusens> zyga, ho
<zyga> sergiusens: hey, I have a question
<zyga> sergiusens: building a snap I ran across an error I'm not familiar with
<zyga> sergiusens: Failed doing pull for foo: [Errno 1] Operation not permitted: '/home/zyga/foo/parts/foo/install/sbin/mount.ntfs'
<zyga> sergiusens: does that sound familiar?
<zyga> sergiusens: this is snapcraft trunk
<tedg> sergiusens: dholbach was asking whether snapcraft will move to github. Thoughts?
<sergiusens> tedg, heh; soonish, lets get 0.4 out the door first
<sergiusens> zyga, that's from a stage package, right? Are you in a container?
<sergiusens> zyga, if you are in a container, check if it is suid; that might be it
<zyga> sergiusens: not in a container
<zyga> sergiusens: vanilla wily
<sergiusens> zyga, what snapcraft are you using and I guess this is from a deb, right?
<sergiusens> not all debs just work
<sergiusens> zyga, btw, I was pinging you yesterda as guacamole and trusty and maybe first moving our current cli to it and then do the new one
<zyga> sergiusens: I'm using snapcraft trunk
<zyga> sergiusens: mmm, yeah that's doable
<zyga> sergiusens: I'm commited to snappy topics as soon as today ends :)
<zyga> sergiusens: as for ntfs, not sure, it's nothing new
<zyga> sergiusens: I can run snapcraft again and it "works" but I suspect it just didn't notice the problem and marked the prior stage as done
<zyga> sergiusens: stage packages have
<zyga>         stage-packages:
<zyga>             - libglib2.0-dev
<zyga>             - libnl-genl-3-dev
<zyga>             - libssl-dev
<zyga> sergiusens: I'll try some more, thanks
<zyga> sergiusens: a lot of stuff has changed over the past month :)
<sergiusens> zyga, yeah, bot not deb handling ;-)
<sergiusens> *but
<zyga> sergiusens: where did handle source options something go?
<zyga> sergiusens: aka def pull()
<sergiusens> zyga, into the base plugin
<sergiusens> zyga, you complained about it, remember ;-)
<sergiusens> zyga, and the implementation is now in sources.py
<zyga> sergiusens: yeah, I just realized why it didn't work
<zyga> sergiusens: it now relies on schema
<zyga> sergiusens: and I had a custom one, no worries now
<zyga> sergiusens: thanks!
<sergiusens> zyga, right 'snapcraft help plugins --devel'
<zyga> oh
<zyga> nice
<zyga> sergiusens: I have a problem, I need an extra ppa and so I have this hacky patch, http://bazaar.launchpad.net/~zyga/snapcraft/plainbox/revision/256
<dholbach> sergiusens, nice work on 'snapcraft help'!
<dholbach> I just found a small issue with it: http://pastebin.ubuntu.com/12989697/ - shall I file a bug?
<sergiusens> zyga, look at the ros plugin
<zyga> sergiusens: this howerver, now (but not before), started to cause issues with apt
<zyga> sergiusens: thanks!
<sergiusens> zyga, it is undocumented, there's and extra sources attrib
<zyga> nice
<fgimenez> ogra_, when booting rolling/edge 210: Press Enter for maintenance (or press Control-D to continue):
<ogra_> tgm4883, do you see an nls codepage error somewhere in the boot lo ?
<ogra_> *log
<ogra_> err
<ogra_> fgimenez, ^^^
<ogra_> we usually et that when it cant mount /boot due to missing vfat  modules
<sergiusens> dholbach, yeah
<dholbach> thanks sergiusens
<dholbach> https://bugs.launchpad.net/snapcraft/+bug/1510954
<ubottu> Launchpad bug 1510954 in Snapcraft "Help crashes if specified plugin does not exist" [Undecided,New]
<fgimenez> ogra_, nope http://paste.ubuntu.com/12989745/
<ogra_> fgimenez, hmm, it doesnt seem to get to mount /boot at all
<ogra_> looks like systemd to me
<ogra_> sigh, so i guess i need to try myself to debug this
<ogra_> that seems to go deeper
<fgimenez> ogra_, booting from a udf generated image it throws me to emergency mode
<ogra_> well, the same one as in the paste, right  ?
<fgimenez> ogra_, yep, it shows more text anyway, journalctl -xb shows errors about mounting /etc/watchdog.conf, don't know if it might be related
<ogra_> are you sure thats 210 ?
<ogra_> the watchdog stuff should be fine in that one
<fgimenez> ogra_, yep, sudo ubuntu-device-flash core rolling -o kvm-rolling-edge.img --channel edge --developer-mode
<ogra_> hmm, k, i'll check that
<ogra_> i dont see it starting udev in your paste
<fgimenez> ogra_ the paste comes from autopkgtest, don't know if it's complete, for example booting the image with kvm shows the emergency mode welcoming text that is not present in autopkgtest's output
<zyga> sergiusens: http://bazaar.launchpad.net/~zyga/snapcraft/plainbox/revision/256
<zyga> sergiusens: do you think it would be appropriate to just not inspect symlinks at all?
<sergiusens> zyga, we've been asked for the opposite as dangling symlinks in a snap are not allowed
<Chipaca> writing 4G at 20MB/s gets old
<ogra_> use --faster
<Chipaca> i'm getting dropped into emergency thing
<Chipaca> on bbb rolling/edge
<ogra_> Chipaca, see above
<zyga> sergiusens: ah
<ogra_> xenial isnt ready yet it seems
<Chipaca> ogra_: ouh
<ogra_> i'll get to debugging it soon ...
<Chipaca> ogra_: do you know offhand what's the latest edge that boots?
<ogra_> the last wily image was 208 ...
<Chipaca> good enough :)
<Chipaca> thanks
<ogra_> 209 was completely broken, 210 is the first actual xenial image
<Chipaca> ogra_: i got to see "welcome to ubuntu 16.04", so that's nice :)
<ogra_> ah, it moves on properly when you hit ctrl-d ?
<Chipaca> no, it prints that before emerg mode
<ogra_> ah
<Chipaca> in other news, if you don't plug in the sd card, dd is super fast! 843MB/s!!
<ogra_> lol
<ogra_> and you get a new device node in /dev for free as well !
<sergiusens> dholbach, https://code.launchpad.net/~sergiusens/snapcraft/1510954/+merge/276013
<ogra_> ogra@styx:~/Devel/images$ sudo ubuntu-device-flash core --channel edge -o xenial-rolling.img ----developer-mode rolling
<ogra_> Determining oem configuration
<ogra_> generic-amd64 failed to install: snappy package not found
<ogra_> hmpf
<ogra_> oh
<ogra_> perhaps i tried to hard to use developer mode :P
<sergiusens> ogra_, how many - do you need? don't waste them
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/integrate-snappy-tutorials-build-snaps/+merge/276012
<elopio> ogra_: rolling edge #210 amd64 doesn't boot
<ogra_> elopio, yes
<ogra_> see above
<ogra_> i'm u-d-f'ing ...
<ogra_> to debug
<elopio> sorry, I'm late :)
<ogra_> :)
<zyga> sergiusens: I think that's a valid thing to do, maybe the exception could be something that we have in the image already
<zyga> sergiusens: I don't even know why ntfs is pulled in, I worry that if we are too strict about it, we'll break a random snap out there that doesn't rely on the symlink, just on some package that pulls it in
<sergiusens> zyga, right, the problem is 'being in the image already' can only be guaranteed for libc6 and that is the only thing we leave dangling today
<sergiusens> zyga, right; ubuntu debs in stage packages are going to need a lot of refinements as we go
<jdstrand> seb128: hey, do you have an ubuntu-personal system available? if so, can you paste the output of 'snappy list' on that system?
<seb128> jdstrand, hey, no sorry, the image have been discontinued before wily
<Chipaca> ogra_: 208 also lands me in emergency mode
<ogra_> Chipaca, uuuh, any error ?
<sergiusens> or Chipaca a quick one https://code.launchpad.net/~sergiusens/snapcraft/1510954/+merge/276013
<jdstrand> seb128: as in, ubuntu-personal images are no longer being generated or you just happen to not have one?
<seb128> jdstrand, they are not longer generated
<jdstrand> I see
<jdstrand> thanks
<seb128> yw
<Chipaca> ogra_: some not relevant i think ,but:
<Chipaca> ogra_: etc-watchdog.conf.mount: Mount on symlink /etc/watchdog.conf not allowed.
<ogra_> Chipaca, yeah, thats known
<Chipaca> ogra_: that's about it
<ogra_> the fix went in but there were no wily images anymore
<ogra_> not sure that can block the boot
<Chipaca> will try going back one further
<Chipaca> see what happens
<longsleep> are there any known issues in u-d-f on trusty? I just got a report that it does not work and fails with error while executing external command kpartx -ds spreedbox-15.04-stable-dev.img: device-mapper: remove ioctl on loop0p4 failed: Device or resource busy
<longsleep> loop deleted : /dev/loop0
<longsleep> anyone seen this before?
<longsleep> (it works the very first time after boot)
<Chipaca> longsleep: that's an error that comes up often with u-d-f, that we don't have a good way to fix
<Chipaca> longsleep: at least we haven't found it yet
<Chipaca> longsleep: but you can clean up and try again
<longsleep> Chipaca: oh - it never happend for me
<zyga> sergiusens: I agree with both
<longsleep> Chipaca: how to clean up? losetup -d and kpartx -d did not help
<Chipaca> 1 sec
<Chipaca> longsleep: sudo dmsetup clear loop0p4 && sudo losetup -d /dev/loop0 && sudo kpartx -ds /dev/loop0
<longsleep> Chipaca: cool
<Chipaca> longsleep: after that "sudo losetup -l" should be empty
<longsleep> Chipaca: He will try it in a moment
<sergiusens> Chipaca, the root cause is generally a failure to unmount do to a missing .Close()
<Chipaca> sergiusens: shaaaaame
<Chipaca> ogra_: just in case, am i missing anything? ubuntu-device-flash --revision 207 core rolling --oem=beagleblack --channel edge -o bbb_rolling_edge.img --developer-mode
<longsleep> Chipaca: i can confirm that your commands do the trick and resolve the issue - thanks. Though for him it is always required.
<sergiusens> Chipaca, right; the snappy tests need to check for left over FDs if easy to do :-)
<ogra_> Chipaca, should work, yes
<Chipaca> longsleep: it *never* succeeds for him?
<longsleep> Chipaca: it never seems to clean up after it ran before, though u-d-f does not finish because it does not find a snap defined in the oem yaml
<longsleep> Chipaca: maybe that is related and it does not properly cleanup in this case
<ogra_> ok, i found the issue ...
<Chipaca> ogra_: \o/ ?
<ogra_> seems ubuntu-core-config is broken in xenial
<Chipaca> ogra_: /o\
<ogra_> i'm sure i dropped watchdog.conf and /etc/default/watchdog before from it
<ogra_> but they are in writable-paths so systemd tries to double mount
<ogra_> yup, removing them both makes it boot fine
<ogra_> ok, fix uploaded
<ogra_> next image should boot
<elopio> zyga: your landing bot might be a little too verbose :)
<Chipaca> ogra_: 207 *also* lands me in emergency mode
<Chipaca> ogra_: wat
<zyga> elopio: https://bugs.launchpad.net/launchpad/+bug/1510993
<ubottu> Launchpad bug 1510993 in Launchpad itself "Regression in tracking merged git merge requests" [Undecided,New]
<zyga> elopio: perhaps that's the reason
<ogra_> Chipaca, sure, the fix landed in wily when the buildds were already switched to xenial i fear you have to go far further back to have a booting image
<ogra_> like ... before watchdoog was added
 * Chipaca goes back to 200
<Chipaca> as per bug 1503329 187 booted, so that's the farthest back i'll have to go
<ubottu> bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed] https://launchpad.net/bugs/1503329
<elopio> zyga: I mean that the two messages after the +1 seem unnecessary. The approval generally says thanks. And launchpad will send a message when the merge is done.
<zyga> elopio: ah, I see
<zyga> elopio: yeah, you are right
<zyga> elopio: I can remove that
<zyga> elopio: btw, what are you using it for?
<elopio> zyga: tarmac by default just talks if something goes wrong.
<elopio> zyga: I'm not using anything in there. Somebody subscribed me to those branches, so I woke up to tons of your bot messages.
<elopio> well, not tons.
<elopio> many.
<Chipaca> ogra_: could you kick off an image build, at least for armhf?
<Chipaca> bootcharts on the bbb or wiiiiiiiiiide :)
<Chipaca> ogra_: with modprobe + modules in oem, we can make the bbb bring up the option module with the right bits!
<ogra_> Chipaca, i'll kick an image as soon as https://launchpad.net/ubuntu/+source/ubuntu-core-config/0.6.31 is ready
<ogra_> proposed migration is sloow atm
<Chipaca> :) ok
<Chipaca> ogra_: anyway, i'm not blocked by that
<Chipaca> have plenty to figure out here :)
<ogra_> Chipaca, remount / rw ... remove all lines mentioning watchdog from /etc/system-image/writable-paths and be fine ...
<ogra_> (from the emergency shell)
<ogra_> next boot will just work
<Chipaca> i'll try that
<snappy_> which version of snappy do i need for service logs to work?
<Chipaca> system-ifup.service is not present in 208, which is strange
<ogra_> Chipaca, does that come from snappy ?
<ogra_> (the ubuntu-snappy package )
<Chipaca> snappy_: 5
<Chipaca> ogra_: not afaik
<ogra_> hmm
<Chipaca> ogra_: i mean 200, not 208, there
<Chipaca> ogra_: am updating to 208 now
<ogra_> ah
<Chipaca> ogra_: probably part of the systemd changes
<Chipaca> ogra_: but if so, possibly bad news for this fix on stable
<Chipaca> we'll see
<ogra_> yep
 * ogra_ twiddles thumbs ... 
<ogra_> come on publisher
<ogra_> sergiusens, why did you unmilestone all the milestone 0.4 bugs ?
<ogra_> are they getting dropped ?
<sergiusens> ogra_, only 2 or three; they won't make it in today
<ogra_> ah, k
<snappy_> Chipaca: I have Snappy 15.04 edge... but sudo service log returns "log: unauthorized service"
<longsleep> snappy builds seems to generate invalid package.yaml for oem packages if the oem package contains a preinstalled section. It replaces preinstalled with builtin and adds 4 bogus extra bytes at the end.
<ogra_> snappy_, it is "sudo snappy service log <service name>"
<Chipaca> snappy_: i'm going to need you to copy-paste that into a pastebin please
<Chipaca> ogra_: urm, no :)
<ogra_> no ?
<Chipaca> ogra_: sudo snappy service logs [ package [ service ]]
<snappy_> Chipaca: ubuntu-core version is 229
<ogra_> ah logs, not log
<ogra_> "sudo snappy service logs webdm" works here
<Chipaca> ogra_: yep. webdm is the package :)
<ogra_> :)
<Chipaca> snappy_: pastebin, please
<snappy_> Chipaca: I cant copy and paste text
<Chipaca> snappy_: why?
<snappy_> Chipaca: I can post an image
<snappy_> oh nvm
<Chipaca> image works, but is often more work, and if you're not able to ssh in you're going to have a hard time :)
<snappy_> Chipaca: pastebin.com/NLrbkWXN
<Chipaca> snappy_: unrecognised, not unauthorized
<ogra_> snappy_, it is "sudo snappy service ..."
<Chipaca> and what ogra_  said
<ogra_> you are missing a snappy in your command ...
<snappy_> oic
<ogra_> service is a snappy command, not a standalone thing ...
<snappy_> thx
<longsleep> Added bug #1511050 - someone should look at this asap as it currently seems to be impossible to build a oem snap with preinstalled snaps.
<ubottu> bug 1511050 in Snappy "snappy build generates invalid package.yaml when using preinstalled section" [Undecided,New] https://launchpad.net/bugs/1511050
<Chipaca> pitti: are you around?
<ogra_> Chipaca, images for armhf and amd64 building (FYI)
<Chipaca> ogra_: ta
<Chipaca> i'm wondering where system-ifup.slice went :-(
<ogra_> where on disk should that be ?
<ogra_> /etc/systemd ?
<Chipaca> ogra_: no, it's magic afaict :)
<ogra_> ah
<Chipaca> ogra_: hence me bleating for pitti
<ogra_> yeah
<Chipaca> elopio: about quoting in python
<Chipaca> elopio: consistency is good, but not at the expense of legibility
<elopio> Chipaca: I agree. Where are we losing legibility?
<Chipaca> elopio: if you want to create a string that has single quotes in it
<Chipaca> elopio: you should use double quotes for the string
<Chipaca> elopio: not escape all the single quotes
<Chipaca> I mean, sure, having in a same line three strings with different quotes *for no good reason* is bad
<elopio> yes, that's what I try to do and I've seen sergiusens doing that.
<Chipaca> but  foo("'hello'", '"yes"', '''"what's this?''') is better than the mishmash of backslashes
<Chipaca> (a contrived example, but i'm right now reviewing code that suffers from a lesser case of this problem)
<sergiusens> Chipaca, I've fixed that fwiw
<Chipaca> sergiusens: cool
<sergiusens> Chipaca, also, we don't have consolidation in the messages/strings wrt use of ' or ".
<sergiusens> I was consolidating with "
<Chipaca> Â¯\_(ã)_/Â¯
 * ogra_ u-d-f's 211 ...
 * ogra_ curses
<ogra_> seems rmadison lied to me
<ogra_> so 212 it will be then
 * ogra_ triggers a new build
<elopio> ogra_: this issue is similar to the one last week? No way to test it without generating the image?
<ogra_> elopio, it is the watchdog files
<ogra_> elopio, i fixed it for wily but before there was an image built with my fix the image builders were switched to default to xenial
<ogra_> and since then we had no images at all
<ogra_> now i uploaded the same fix to xenial ...
<elopio> I got it until this point ^.
<ogra_> but rmadison lied to me and told me the package was promoted to the archive while it wasnt yet ... so i need another rebuild
<ogra_> the 212 rolling image that is just building will boot fine i guess
<ogra_> (now the fix is in the archive)
<balloons> elopio, are you still a-ok with having that snappy testing session? If so, I'll schedule it for you now
<elopio> balloons: like automation or manual testing?
<elopio> balloons: ah, just go for it, we'll talk about both automated and manual tests. Please make it early in the morning so Federico can join us. I will try to convince him to take care of the automated part :)
<tedg> elopio: sergiusens: So this is getting insane. What do I do to reduce the length of a URL that is longer than 79 characters?
<tedg> I already deduplicated one string using format to remove common occurances of "certificate" but this one has too much unique data.
<elopio> tedg: you can url = ("...."
<elopio> "...."
<elopio> "....")
<tedg> Uhg, okay.
<elopio> the strings in each line will contact. Split the URL whererver it makes sense, like after /
<ogra_> intuitive :P
<elopio> *concat
<elopio> ogra_: well, you can put + between the lines too to make it more explicit. I find it nice, but I'm biased :)
<ogra_> i'm a shell addict ... i'd prefer backslashes :)
<tedg> If only we could have a computer program that could wrap long lines on its own. We could call it a "text editor". Ah, to dream of the future.
<ogra_> tedg, hmm
<ogra_> not a bad idea though
<ogra_> we should write one ...
<ogra_> ... and call it vimacs !
<tedg> Multiple modes that require for control key combinations to switch between. It'd be intuitive!
<elopio> ogra_: I think this works too: url = "..." \
<elopio> "..." \
<elopio> "..."
<ogra_> oh, neat
<elopio> you see? there's python for everybody!
<tedg> Yeah, actually I've found you can get around the checks on which things can break lines by using \
<ogra_> python.sh !
<tedg> The linter seems to not catch things in that case.
<elopio> tedg: yes, but pythonistas don't like \ that much.
<tedg> It's okay. I don't like them either :-P
<elopio> I must admit that I'm enjoying the golang long lines.
<elopio> but don't tell anybody.
<balloons> elopio, will do. I will put in on the schedule, but we can easily drop it if it doesn't work out. Thanks for being willing to try.
<ogra_> until you have to edit them via a serial terminal for the first time :P
<elopio> balloons: I have lots of things to talk about, most of them in progress so even better to find people who want to help. It will work.
<tedg> elopio: Welcome to the dark side, we have cookies!
<balloons> hey tedg btw.. I would be remiss if I didn't offer you a lovely trip to some warmer weather in a month. Orlando is lovely that time of year, and mhall119 will be there. What more could you ask for?
<balloons> tedg, I'm obviously talking about fossetcon. Mike was looking for someone who could speak about snappy and show off snapcraft. is it an option for you?
<balloons> so you know, elopio volunteered you :-)
<tedg> balloons: Uhm, could be. Depends if elopio will turn off the DEP8 tests :-)
<balloons> nicely done!
<tedg> balloons: Link?
<balloons> http://fossetcon.org/. It's November 19-21
<balloons> ubucon would just be the 19th
<tedg> Generally yes, I think I could probably do that.
<tedg> Have to redo my snapcraft talk anyway, kinda failed at TXLF
<ogra_> the snappy/snapcraft talk at ubucon.de was actually crowded
<Guest42341> how do i end up on this channel???
<tedg> ogra_: I tried for a demo in mine, and someone broke the docker snap an hour before...
<ogra_> yeah
<ogra_> i remember
<tedg> Live demos are always a bad idea... I need to learn that for reals sometime.
<balloons> ahh yes. So much can go wrong when you try things live
<elopio> tedg: hey, I didn't turn the dep8 tests on!
<elopio> I was happy and surprised when other people started adding the checks :)
<ogra_> the latest rolling/edge image should now work
<elopio> ogra_: 212 boots, but the ens3 interface is down.
<ogra_> well
<elopio> ogra_: the config test passes.
<ogra_> i see ens3 in my kvm here
<ogra_> anyway, thats for tomorrow ...
<ogra_> mail sent and i'm EOD ....
<elopio> ogra_: good night. And thanks.
<sergiusens> tedg, any luck with the plugin or those bug fixes?
<tedg> sergiusens: Plugin almost done. Talking with "upstream" now.
<tedg> I've got some complexity to fix though :-(
<tedg> Haha, oops. I made it more complex.
<sergiusens> tedg, don't hang yourself :-P
<tedg> Oh, you got rid of all the booleans!
<tedg> Nice, need to update.
<sergiusens> tedg, oh, the if self.run and blah blah. Of course, now we type less :-)
<tedg> Well, it reduces the complexity as well.
<sergiusens> tedg, right, but man, that change landed ages ago ;-)
<pitti> Chipaca: what is system-ifup.slice? you mean ifup@.service?
<snappy_> hi
<snappy_> Chipaca: u online?
<Chipaca> snappy_: no
<Chipaca> pitti: I don't know what it is, exactly! was hoping you'd tell me :)
<Chipaca> snappy_: what's up?
<Chipaca> pitti: it shows up in an amd64 kvm, but not in a bbb, fwiw
<snappy_> hi
<Chipaca> snappy_: how's things?
<snappy_> Chipaca: good thx
<snappy_> Chipaca: getting a failed to connect to Mir on ubuntu 15.04 edge.
<Chipaca> snappy_: core?
<snappy_> Chipaca: when trying to run freerdp snap
<snappy_> Chipaca: snappy ubuntu core*
<snappy_> Chipaca: edge
<Chipaca> snappy_: ok, questions for you
<Chipaca> snappy_: is mir starting successfully? that is: do you get a black screen with a pointer?
<snappy_> Chipaca: no.  doesnt run
<snappy_> Chipaca: on edge
<Chipaca> snappy_: right. The only way I got it to work was by running it under virt-manager, and making sure the display was "spice"
<snappy_> oic
<snappy_> hmm
<snappy_> thx ill try that
<Chipaca> pitti: and ifup@.service doesn't "run"; i can't after: or before: it
<sergiusens> elopio, are you testing/exploring on trusty, vivid or wily?
<elopio> sergiusens: vivid and wily.
<sergiusens> elopio, have you built the ros example?
<elopio> sergiusens: I left it running, let me check...
<elopio> Failed doing build for tomcat: Error -3 while decompressing data: invalid block type
<elopio> let me re-run it to confirm.
<sergiusens> elopio, hm that might be networking playing tricks
<sergiusens> elopio, what about ros?
<sergiusens> elopio, I ask about ros because I want to know where the 'listener' and 'talker' end up in that build
<elopio> sergiusens: ros succeeded, that was executed just before that tomcat error.
<sergiusens> elopio, do you have the snap to test the 'binaries' or access to the ./snap dir?
<sergiusens> does snap/opt/ros/indigo/beginner_tutorials/lib/beginner_tutorials/listener exist?
<elopio> sergiusens: running again because I don't know where plainbox leaves the files.
<sergiusens> elopio, oh, plainbox just wipes them :-P
<elopio> sergiusens: listener exists in that path.
<elopio> also talker
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/path_ros/+merge/276070
<elopio> sergiusens: +1
<elopio> sergiusens: should we retry when the downloads fail?
<sergiusens> elopio, maybe, but did it fail or was it incorrect?
<elopio> I retried and it worked. My network is sucking even more this days.
<elopio> sergiusens: on the run I had running on the other machine I got:
<elopio> Failed doing pull for local: [Errno 1] Operation not permitted: '/home/elopio/.cache/plainbox/sessions/pbox-_anzho6q.session/CHECKBOX_DATA/parts/local/install/sbin/mount.ntfs'
<sergiusens> elopio, for which example?
<elopio> sergiusens: trying to figure that out to retry. the wall of text in the test doesn't make it easy.
<sergiusens> elopio, yeah, I agree; I wanted those examples to be individual tests not one big blob :-)
<elopio> with testools and subunit details.
<elopio> it's the one after gopaste, and mentions ant, so I'm guessing java-hello-world. Retrying...
<sergiusens> elopio, strange that built fine for me
<sergiusens> inside an lxd container even
<elopio> sergiusens: built alright in the wily machine. This is vivid. Pull only downloads things, right? It's a weird error.
<sergiusens> elopio, it also does the ubuntu unpack magic
<sergiusens> elopio, I bet vivid is the one in the container?
<sergiusens> elopio, or chroot or clean environment
<elopio> sergiusens: no containers here. vivid is the laptop, wily is the desktop
#snappy 2015-10-29
<sergiusens> elopio, hmm
<sergiusens> elopio, do you have ntfs-3g installed on vivid?
<sergiusens> elopio, and wily
<elopio> sergiusens: yes, on both.
<elopio> failed again on vivid. Trying on wily.
<elopio> tedg: where can I find your ginac example?
<sergiusens> elopio, can you open a bug for the ntfs thing?
<elopio> sergiusens: yes. still trying to understand what it's trying to install on vivid.
<elopio> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1511161
<ubottu> Launchpad bug 1511161 in Snapcraft "java-hello-world example fails to snap on vivid: Operation not permitted: '/home/elopio/workspace/canonical/snapcraft/trunk/examples/java-hello-world/parts/local/install/sbin/mount.ntfs'" [Undecided,New]
<sergiusens> elopio, care to try this http://paste.ubuntu.com/12995475/
<sergiusens> elopio, that function still seems to have legacy from the whole return True/False era; not going to fix that now though...
<elopio> sergiusens: that fails the same.
<sergiusens> elopio, really?
<elopio> really
<sergiusens> elopio, can you apply this //paste.ubuntu.com/12995549/
<sergiusens> I eventually forgot to add the command line switch for that to show :-/
<elopio> sergiusens: paste.ubuntu.com/12995571/
<elopio> sergiusens: I need to go, my girlfriend is waiting me for dinner. I'll be back and test for a one and two more hours, so send me an email  if you need something else.
<sergiusens> elopio, ok, I fix the wrong location :-)
<sergiusens> elopio, https://code.launchpad.net/~sergiusens/snapcraft/1511161/+merge/276075
<tedg> elopio: http://pastebin.ubuntu.com/12862605/
<tedg> I should probably put that in a gist, that's what the cool kids do.
<tedg> https://gist.github.com/ted-gould/304a3a828baaaaed272f
 * tedg is bad ass with color highlighting
<sergiusens> tedg, or on the parts wiki ;-)
<pitti> Chipaca:  if you really want to wait for a particular interface you can After/Before=ifup@enXXX.service; but please don't do that :)
<pitti> Chipaca: what's your use case? Normally a service would  say "I need to run after the network is up" (After=network-online.target)
<pitti> Chipaca: or e. g a firewall would say "I need to run *before* starting any services on the network" (Before=network-pre.target)
<Chipaca> pitti: i need to run before the network is started, but after the filesystem is mounted
<pitti> Chipaca: so sounds like Before=network.target then
<pitti> Chipaca: if your service has DefaultDependencies=no (i. e. early boot), then also After=local-fs.target
<pitti> but services without that (i. e. the implied DefaultDependencies=yes) always have local-fs.target already
<Chipaca> pitti: won't that get me in a race with networking.service?
<pitti> Chipaca: oh, you need to run before that too? well, then you need DefaultDependencies=no, Before=network-pre.target
<pitti> Chipaca: I'd really stick to targets; note that networking.service is just ifupdown, that might change etc.
<Chipaca> pitti: i'll give that a try, thank you very much!
<Chipaca> but after breakfast. first things first :)
<pitti> Chipaca: man systemd.special explains these targets and what they do, btw
<pitti> Chipaca: absolutely! :)
<mvo> Chipaca: just fyi, there seems to be some race in one of the priv tests, I sometimes get test failures in travis and a rebuild fixes them
<mvo> Chipaca: have not looked in detail yet, just wanted to share it for now
<dholbach> good morning
<mvo> fgimenez: hey, good morning. would it help you if I import the branches of lopio into git so that you can continue with your workflow of review/merge? or is this already on the radar (not want to push, just want to help :)
<mvo> hey dholbach
<fgimenez> mvo, hey, of course helps thx! :) btw, could you add me to the team, pls?
<Chipaca> mvo: thank you for the heads up. I'm still in why-does-the-bbb-not-have-ipv4 mode here.
<fgimenez> ogra_, rolling/edge 212 boots ok but ens3 is down on first boot
<Chipaca> fgimenez: yeh, that's probably my fault
<Chipaca> but figuring it out on the bbb first
<fgimenez> Chipaca, ah ok :)
<clobrano> mvo: thank you for the branch on github
<mvo> clobrano: your welcome!
<guest123124> error while executing external command kpartx -ds personal_x86.img: device-mapper: remove ioctl on loop0p5 failed: Device or resource busy
<guest123124> loop deleted : /dev/loop0
<guest123124> got this error while flashing ubuntu personal
<fgimenez> mvo, thx! :)
<fgimenez> mvo, i'm getting a lot of "another snappy is running, try again later" errors running the test suite on kvm, both for rolling and 15.04
<mvo> fgimenez: interessting, that hasn't changed :/ or it should not
<mvo> elopio, fgimenez: https://github.com/mvo5/snappy/tree/from-bzr/integration-fix-rollback, https://github.com/mvo5/snappy/tree/from-bzr/expose-bug1498293-boot-try, https://github.com/mvo5/snappy/tree/from-bzr/integration-tests-verbosity-flag, https://github.com/mvo5/snappy/tree/from-bzr/result_on_error
<mvo> elopio, fgimenez: all imported now into git, feel free to fork and hack away. if they are good to go I can also create pull requests from them of course, just let me know
<fgimenez> mvo, ok thanks a lot
<mvo> your welcome!
<fgimenez_> mvo, you can execute the suite with go run _integration-tests/main.go -release 15.04
<fgimenez_> mvo, rolling has no ens3 up now, you can create the image with , run an instance with kvm, enable ens3 from the console and execute the suite with -ip and -port
<fgimenez_> create the image with udf :)
<Chipaca> ogra_: how do I edit the kernel commandline on bbb?
<ogra_> fw_printenv |grep ^mmcargs
<ogra_> sudo fw_setenv mmcargs setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot} foobar"
<ogra_> oh, except ... quoting
<Chipaca> got it, thanks
<ogra_> sudo fw_setenv mmcargs 'setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot} foobar"'
<ogra_> (else the curly brackets get swallowed)
<ogra_> works the same on RPi btw
<Chipaca> mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype}
<Chipaca> that's what i have
<ogra_> yeah, mine is from RPi
<ogra_> rootfstype is nonsense, we need to clean that up some point
<Chipaca> ah, ok
<ogra_> on the BBB you can obviously also use optargs instead of mmcargs
<ogra_> (the default vars come from upstream, we only add the snappy bits)
<Chipaca> pitti: with before:networking-pre i'm still not running it early enough it seems
<Chipaca> pitti: but i can't see what it is that i need to run earlier than
<pitti> Chipaca: networking.service has After=network-pre.target, so that really ought to work
<pitti> Chipaca: what is "it" and how does it fail?
<Chipaca> pitti: on first boot, we create a file for the first ethernet device, to be brought up by ifup
<pitti> Chipaca: does the service get run and the file created? any dependency cycles in journalctl perhaps?
<pitti> Chipaca: did you set DefaultDependencies=no?
<Chipaca> pitti: without defaultdependencies i'd get a cycle
<Chipaca> without DefaultDependencies=false i mean
<pitti> right, I expect that
<Chipaca> but now no, no cycle, firstboot process is run
<Chipaca> i even added a before: wait-for-ifup-whateveritscalled
<Chipaca> because that was started at the same time
<Chipaca> and no
<pitti> that runs after ifup@.service, so even later
<pitti> s/run/finishes/, sorry
<Chipaca> well, but ifup@.service isn't running? or isn't in the logs
<pitti> but please don't add deps to that, it's just an "internal" helper unit to implement network-online.target
<Chipaca> ok, let me remove that, and i'll show you the boot graph
<pitti> Chipaca: oh, so the problem isn't that your firstboot unit runs too late, but that ifup@.service does *not* run on first boot?
<pitti> (I could explain that)
<Chipaca> pitti: i'm listening :)
<pitti> Chipaca: first -- is that the problem?
<Chipaca> pitti: I don't know enough to know whether that is a consequence of the problem, or a cause of it
<Chipaca> pitti: that happens, certainly
<pitti> Chipaca: but I mean, your firstboot unit runs and creates /e/n/i, but ifup@ doesn't get run and you have no network?
<Chipaca> pitti: firstboot unit runs. ifup@ doesn't get run.
<pitti> actually, /etc/init.d/networking should then still bring it up, so that's a bit strange
<Chipaca> pitti: i have ipv6
<Chipaca> pitti: but not ipv4
<pitti> Chipaca: does networking.service run?
<Chipaca> pitti: yes
<Chipaca> let me double-check that actually
<pitti> because that should "mop up" things that ifup@.service didn't catch
<Chipaca> no, networking.service is not in journalctl
<pitti> Chipaca: so, I know why ifup@ didn't run, but I can't explain why networking.service didn't bring up the eth
<pitti> Chipaca: if you grep, search for "Description=LSB: Raise network interfaces"
<Chipaca> (BeagleBoneBlack)ubuntu@localhost:~$ sudo journalctl | grep "Description=LSB: Raise network interfaces"
<Chipaca> (BeagleBoneBlack)ubuntu@localhost:~$
<pitti> Chipaca: nah, not "Description=" :)
<Chipaca> Oct 29 09:35:50 localhost.localdomain systemd[1]: Starting LSB: Raise network interfaces....
<pitti> that sohuld run ifup -a
<pitti> does that run after your firstboot thingy?
<Chipaca> yes
<Chipaca> and then after that runs i have
<Chipaca> a bit of dhcp, and
<Chipaca> Oct 29 09:35:57 localhost.localdomain kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<pitti> so dhclient ran, but didn't give you an IPv4 address?
<Chipaca> correct
<pitti> wow; I don't have the slightest idea about that then
<Chipaca> but only on first boot
<Chipaca> from then on, ipv4 comes up fine
<pitti> sudo journalctl -u networking.service should have the dhclient output, what did it say?
<Chipaca> nothing about dhcp
<Chipaca> let me pastebin
<Chipaca> pitti: http://paste.ubuntu.com/12997839/
<pitti> Chipaca: could you set VERBOSE in /etc/default/networking (or change the default in /etc/init.d/networking), and add "grep -r . /run/network/" to the start) part of /etc/init.d/networking?
<pitti> it seems this doesn't actually start anything, it seems to think that they are already up for some reason
<pitti> Chipaca: also, something to try: to your firstboot, add Before=systemd-udev-trigger.service
<pitti> Chipaca: that should hopefully make ifup@*.service start on firstboot
<pitti> that doesn't explain why /etc/init.d/networking didn't bring them up, of course
<Chipaca> rebooting with those changes, plus systemd.log_level=debug in commandline
<Chipaca> ah, and this is still the last wily, I could bump it to xenial if it makes a difference
<Chipaca> pitti: just to keep things interesting, now it came up with no ipv6 either
<pitti> Chipaca: I suppose ipv6 is just the fe80: LL address?
<pitti> or do you actually get a DHCP address for it?
<Chipaca> fe80::d25f:b8ff:fea3:907f
<Chipaca> which afaik is not ll
<pitti> Chipaca: no, wily  should be fine; note that one change was debugging why networking.service doesn't call ifup -a; if you do the Before=udev-trigger, then neworking.service will almost surely not do anything because ifup@ already did
<pitti> Chipaca: that's LL
<pitti> fe80:<some hash of the MAC>
<Chipaca> oh
<Chipaca> d'oh
<pitti> curious where that comes from, of course
<pitti> you don't have networkd enabled/configured or something such?
<pitti> if neither networking.servcie nor ifup@ up the interface, then what does
<JamesTait> Good morning all; happy Thursday, and happy Internet Day! ð
<pitti> Chipaca: btw, you coudl probably make all of this a lot simpler
<pitti> Chipaca: let your network config thing run later (no DefaultDependencies), create your interfaces.d snippet and just call ifup <yournewinterface>
<pitti> Chipaca: but anyway, for the sake of understanding what on earth happens there, let's finish this :)
<Chipaca> pitti: networking service now failed to start
<Chipaca> pitti: so i probably bungled an edit
<Chipaca> pitti: http://paste.ubuntu.com/12997894/
<Chipaca> pitti: but i'm not seeing the error
<pitti> Chipaca: grep -r . /run/network/ || true
<pitti> Chipaca: if the script is set -e
<pitti> Chipaca: if there are no files, grep exits with 1
<Chipaca> ah! right
<Chipaca> pitti: where would i see this output btw?
<pitti> Chipaca: but that already tells us that there's no /ifstate
<pitti> Chipaca: should be in the journal, or systemctl status -l networking
<Chipaca> i can't see the ####s there
<pitti> Chipaca: sure -- the command is just "echo" :) # is a comment
<Chipaca> anyway, adding the ||true and rebooting
<pitti> ech '###'
<Chipaca> augh!
<Chipaca> stupid me is stupid :)
<ogra_> blame the weather
<pitti> Chipaca: of all the --- ____ **** etc. chars you could have picked you got the wrong one :)
<Chipaca> pitti: i nearly went with ****
<pitti> but yeah, shell is fun, isn't it
<Chipaca> pitti: that's my usual :)
<pitti> Chipaca: that will actually do a glob
<Chipaca> exactly
<Chipaca> i caught myself :)
<pitti> Chipaca: so you might see "bin" or "usr" or whatever comes first in / :)
<Chipaca> ogra_: i'll blame you instead. it's shell, afterall.
<ogra_> oh, ok, sorry for breaking :)
<pitti> we didn't get rid of shell in shappy yet? :-)
<ogra_> luckily not
<Chipaca> ... yet
<Chipaca> ]:D
<ogra_> glue is glue :P
<pitti> of all programming languages this is probably the most error-pone
<Chipaca> first, init=/snappy
<Chipaca> then, the world
<pitti> almost as error p*r*one than my spelling, of course
<ogra_> but also the easiest to learn which gets you lots of free contributions of more broken code :)
<pitti> ogra_: I was about to say PHP *cough* *cough*
 * Chipaca twiddles his thumbs while the bbb recreates the universe
<pitti> Chipaca: ugh, poor you -- this doesn't reproduce in a VM?
<Chipaca> pitti: nope
 * ogra_ doesnt want the universe to depend on a single BBB
<Chipaca> pitti: http://paste.ubuntu.com/12997933/
<Chipaca> >>>>> Parsing file /etc/network/interfaces.d/eth0 <<<<<<
<Chipaca> W
<Chipaca> T
<Chipaca> <expletive>
<pitti> Chipaca: i. e. it sees /etc/network/interfaces.d/eth0 but doesn't see any contents or so?
<pitti> Chipaca: could that be a missing fsync, i. e. the file is still in write cache?
<pitti> I mean, other processes see that cache too, but who knows
<pitti> Chipaca: oh -- is your firstboot thing Type=oneshot? And/or, did it actually *finish* before networking.service? Can you pastebin the full journal?
<Chipaca> pitti: it does the whole sync/rename/sync directory dance
<pitti> Chipaca: ok -- le journal entier, s'il te plaÃ®t
<pitti> Chipaca: (silly question, but /etc/network/interfaces.d/eth0 looks alright after boot?)
<Chipaca> allow-hotplug eth0
<Chipaca> iface eth0 inet dhcp
<pitti> aah!
<pitti> that explains why /e/i/networking doesn't do it
<pitti> that only does "auto" interfaces
<Chipaca> hmm
<pitti> Chipaca: "auto" works for both cold and hotplug in Ubuntu; stgraber told me that several things in Ubuntu (ifenslave and what not) never learned about "allow-hotplug"
<pitti> Chipaca: so allow-hotplug is only caught by ifup@.service
<Chipaca> that's ok, though, that's what we want
<pitti> Chipaca: and that gets triggered very early on via udev rules, at which point your firstboot didn't run yet
<pitti> Chipaca: do you? I think you want "auto" there, there is little reason to not use it
<Chipaca> auto introduces a huge boot delay if the cable isn't plugged in
<pitti> Chipaca: for ifup@ via udev rules you need to run before systemd-udev-trigger.service
<pitti> Chipaca: ah, ok -- you don't want that?
<ogra_> no
<pitti> I was specifically asked to implement that
<ogra_> we want allow-hotplug
<ogra_> else if you have no cable connected it will wait for the timeout
<pitti> that's what we did in upstart for years, and apparently we wanted that behaviour in systemd too to work with services which don't get along with hotplugged interfaces
<pitti> ok then
<pitti> so that means /etc/init.d/networking is out of the game
<Chipaca> well
<pitti> which already explains a lot of the above confusion :)
<Chipaca> we do have services that don't get along with hotplug
<ogra_> well, a drone might only have a wired connection while you maintain it ... but not while you fly it
<ogra_> if it reboots while flying or some such you want it to do that before it hits the ground ;)
<pitti> Chipaca: things like ssh ship an /etc/network/if-up.d/ script to reload/restart themselves
<pitti> which is utterly "erks", but oh well
<ogra_> and not have it wait 3min for a cable connection
<pitti> IP_FREEBIND!
<pitti> ogra_: oh, I'm absolutely on your side
<ogra_> i think the master plan is still to use systemds network management or nm
<ogra_> in the longer term
<Chipaca> pitti: so, looking at http://people.canonical.com/~john/bbb.svg
<ogra_> which should make dynamic services work
<pitti> I didn't *like* this "block boot for 2 mins", but I was asked to do that to mirror what we did before
<ogra_> yeah
<Chipaca> pitti: systemd-udev-trigger comes up very early, before mounts
<Chipaca> pitti: i suspect it's not going to like me saying i want to go before that and after mount
<pitti> Chipaca: yeah; it's not that easy to run stuff before that
<pitti> Chipaca: IMHO it's much simpler (and much more parallel) to just call ifup after you created the definition
<Chipaca> ok, fair enough, i'll do that
<Chipaca> pitti: you do now know why things were weird, then, no more debugging needed?
<pitti> Chipaca: so from the mysteries above the one thing which isn't clear to me yet is what brought up eth0 and assigned an IPv6LL address
<Chipaca> dhcp
<Chipaca> (why? oh i have no idea)
<pitti> Chipaca: it's clear why networking.service didn't bring it up, and why ifup@ didn't run (as udev rules run much earlier than your firstboot thing)
<Chipaca> here, let me pastebin the journal
<Chipaca> pitti: http://paste.ubuntu.com/12998003/
<Chipaca> pitti: if you look for ipv6 in there
<pitti> (OTP, brb)
<pitti> Chipaca: is/was the device actually up? or did it merely get a  default address assigned by the kernel, but was down?
<pitti> "down" would be expected; "up" would be a surprise
<Chipaca> up
<Chipaca> down in the vm
<Chipaca> up in bbb
<Chipaca> pitti: well, that worked
<Chipaca> let me check journal just in case
<Chipaca> Oct 29 10:30:37 localhost.localdomain systemd[1]: ubuntu-snappy.firstboot.service: Failed to send unit change signal for ubuntu-snappy.firstboot.service: Transport endpoint is not connected
<Chipaca> pitti: what does that ^ mean?
<Chipaca> (everything else seems correct)
<pitti> Chipaca: presumably that dbus isn't running at that time yet
<pitti> Chipaca: but that's a debug message; still running with "debug"?
<Chipaca> yes
<Chipaca> kernel options go in firmware
<Chipaca> so Â¯\_(ã)_/Â¯
<pitti> Chipaca: pronounce that quickly ten times in a row
<Chipaca> :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg: :shurg:
<Chipaca> dammit
 * pitti feels the rhythm & beat
<Chipaca> obviously :shrug with another : turns into Â¯\_(ã)_/Â¯
<Chipaca> but not :shurg:
<Chipaca> weird, that
<Chipaca> :)
<Chipaca> anyway
<Chipaca> pitti: should i move firstboot away from being so early in the boot, now that you know more about what it does/needs/wants to do?
<pitti> Chipaca: please drop the before=udev-trigger, indeed
<pitti> Chipaca: defaultdeps=no and after=local-fs.target still sound fine, and do keep the before=network-pre.target too
<Chipaca> After=local-fs.target
<Chipaca> Before=network-pre.target
<Chipaca> DefaultDependencies=false
<Chipaca> is what i have now
<pitti> I mean, it's first boot, so it's not a biggie if that takes .5 seconds longer, but *shrug*
<pitti> Chipaca: LGTM
<Chipaca> oh, that's a good point, is there a systemd idiom for "don't run if this file exists"?
<pitti> Chipaca: oh, you want that, right
<pitti> [Unit]
<Chipaca> firstboot itself checks, but why even start it :)
<pitti> ConditionPathExists=!/path/to/file
<Chipaca> nice
<pitti> Chipaca: perhaps you also want ConditionPathExistsGlob=!/etc/network/interfaces.d/*
<pitti> Chipaca: see man systemd.unit, there's a bunch of them
<pitti> there's even a ConditionFirstBoot=, but that doesn't really work for us yet
<Chipaca> thanks
<pitti> (that means "/etc is empty")
<pitti> Chipaca: yeah, more efficient than starting a program just to determine that you don't need it
<Chipaca> i'll just leave it at stamp for now
<Chipaca> as creating that iface is not the only thing it does
 * Chipaca reboots to test
<Chipaca> anyway, pitti, i've stolen enough of your time already :) thanks a bunch
<pitti> Chipaca: ah, that sounds fine; I thought you wanted to do FileExists=/etc/network/interfaces.d/eth0, which would be a bit pointless
<pitti> Chipaca: if you have some "first-boot ran" stamp, then do use that of course
<Chipaca> pitti: it's not always eth0, is where the fun started :)
<pitti> Chipaca: right, that's what I meant
<Chipaca> but yeh, we've got a stamp file for this
<pitti> but yeah, networkd :)
<Chipaca> pitti: networkd?
<pitti> I thought Mark wanted to move to that at some point
<Chipaca> ah. well, it's on there, isn't it?
<pitti> or to a different naming schema for interfaces
<pitti> or both
<pitti> Chipaca: right, but we currently use ifupdown
<Chipaca> :)
<pitti> [Match]
<pitti> Name=en* eth*
<pitti> done
<Chipaca> pitti: how well does that play with networkmanager?
<pitti> Chipaca: same way ifupdown does -- not at all
<pitti> i. e. you need to pick one network management thingy for each interface
<pitti> (and ideally for the whole system, otherwise it's too confusing)
<Chipaca> pitti: right. Which means ifupdown gives us a way to say "we'll bring up just the first ethernet differently, just so you can then install network manager for the rest", whereas networkd makes that "all ethernet devices are networkd-managed"
<Chipaca> which is the same but different
<pitti> Chipaca: right; if we want to pick one particualr interface, the Name= thing woudl be the same as with ifupdown
<pitti> Chipaca: but if we are going to have NetworkManager on snappy, why not use that for eth as well then?
<Chipaca> pitti: because it's a .snap, not part of the base
<Chipaca> pitti: well --- having said that
<pitti> ah, ok; so not "on" snappy, just "for" snappy
<Chipaca> it would be easy to turn off this thing
<Chipaca> snappy config lets you write an empty file to interfaces.d, and that would sort that out
<Chipaca> but a bit more code would be needed
<ogra_> well ... given that NM will want to manage eth0 too we need somw wa for the nm snap to tell snappy to not apply the config
<ogra_> *some way
<Chipaca> ogra_: that's doable
<Chipaca> ogra_: although not from the package itself
<Chipaca> it's package+config doable
<Chipaca> ogra_: from u-d-f, if you want to preload n-m, just create an empty file in interfaces.d
<Chipaca> create empty file -> via snappy config
<Chipaca> ogra_: if you install it after, use snappy config to overwrite the eth file with an empty one
<Chipaca> ogra_: done
<ogra_> i dont want an empty one
<ogra_> NM will mangae that file
<ogra_> i think we need a way for snaps to turn off core features they deliver themselves
<ogra_> look at bug 1504657 and longsleep's comments ... same thing
<ubottu> bug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/1504657
<ogra_> he might ship ntpd inside a spreedbox snap ... which would then want to disable timesyncd
<Chipaca> ogra_: good point
<ogra_> Chipaca, oh, and another thing ... why cant the atomic write use /tmp (the above will force me to add another link to /etc/writable, this is getting really awkward)
<Chipaca> actually, i'd be happier if all these were snaps :)
<Chipaca> ogra_: because different partition
<ogra_> hmpf
<Chipaca> ogra_: only rename is atomic :-(
<Chipaca> and even then you need to sync the dir
<ogra_> i wonder why everything else gets along without atomic writing .... on the phone we have exactly three files in /etc/writable
<Chipaca> probably because i wasn't looking :D
<ogra_> in snappy we'll have 10-20 soon if it goes on at this pace
<Chipaca> ogra_: probably because most of them are small enough, and written to sporadically enough, that crashes due to this are impossible to reproduce
<Chipaca> ogra_: so you'll find that sometimes things won't work, and try again, and they will, and shrug your shoulders and move on
<ogra_> hmm
<ogra_> the problem with the setup we use now is that these files will never be upgraded
<ogra_> i.e. if the tool needs new options they wont show up, the setup completely works around system-image
<ogra_> (where we have sync and transition options)
<ogra_> (i.e. we are doing a three way merge but ignore upstream to turn it into a two way one)
<Chipaca> fgimenez_: you know the "bbb only has ipv6 on first boot" bug, and the "kvm has no network on first boot" bug?
<Chipaca> ogra_: i'm afraid i don't know enough to be helpful :-( glad to learn if you need help though :)
<ogra_> well, there is no solution to this
<ogra_> which is why we generally dont really use /etc/writable on the phone
<fgimenez_> Chipaca, there's one for the bbb ipv6 issue, not sure about kvm one, let me check
<ogra_> exccept for files where we know no new upstream options will show up
<ogra_> (hostname, timezone and localtime are single option config files)
<ogra_> if we use watchdog.conf  and watchdog grows a new option it will never show up in the config
<Chipaca> ogra_: why? that's the bit i don't follow
<Chipaca> ahhh
<Chipaca> i got you now
<ogra_> beacuse files in /etc/writable come from snappy only
<ogra_> and are never synced with the upstream version again
<ogra_> (i.e. on upgrades)
<fgimenez_> Chipaca, https://bugs.launchpad.net/snappy/+bug/1503329
<ubottu> Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Critical,Confirmed]
<Chipaca> ogra_: you mean when updating, if the new watchdog grows more options, 3-way-diff a la dpkg is a no-go, etc
<ogra_> right, it simply doesnt happen ... your local config will override  it forever
<Chipaca> ogra_: now everything you said makes sense :)
<Chipaca> agreed, but that to me means
<ogra_> the system-image writable thing cares for syncing
<Chipaca> the config should be generated from snappy based on stuff snappy tracks
<Chipaca> then when things change, snappy can have the smarts to update the config with sane defaults
<Chipaca> with no chance of the user/owner/etc breaking the config, as it'd get stomped on every time
<Chipaca> hmm
<ogra_> in general i wonder if we cant edit the file in /tmp and then mv it or some such ... while thats a bit less reliable it will really only be minimal
<ogra_> that way we could use the system-image setup again
<Chipaca> ogra_: system-image is going away though
<ogra_> not the mounting functions
<ogra_> unless we really fgo for overlayfs and leave the phones behind
<zyga> pindonga: hey
<pindonga> hey
<pindonga> so, I'm running snapcraft again from scratch
<pindonga> I'll let you know in a sec how it goes
<zyga> pindonga: okay :)
<longsleep> Anyone can tell me where to find all possible config options for ubuntu-core? Or maybe a link to the config hook would be awesome.
<Chipaca> longsleep: ubuntu-core is a bit special and different wrt config
<Chipaca> longsleep: but i can give you a link
<Chipaca> longsleep: https://github.com/ubuntu-core/snappy/blob/master/coreconfig/config.go
<longsleep> Chipaca: that would be aweseome - i also would like to understand what and why ubuntu-core is special so the code should help a lot thanks!
<Chipaca> longsleep: it's special in that it's handled internally by snappy
<Chipaca> longsleep: other than that, it's the same, really :)
<longsleep> Chipaca: so one could say it as virtual snap right?
<Chipaca> longsleep: something like that :)
<longsleep> Chipaca: ok great thanks
<Chipaca> mvo: when core becomes a snap, do we move the config to a hook in the snap itself?
<sergiusens> Chipaca, mind looking at that review from earlier?
<ogra_> if you look for a config handler, here is a shell variant :) http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/config.sh
<Chipaca> sergiusens: no, i don't. have a link?
<mvo> Chipaca: maybe, I have no plan for this yet
<sergiusens> Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/1501222/+merge/276089
<mvo> Chipaca: it would make sense plus we move snappy into a snap
<sergiusens> Chipaca, sorry, sent it in private as I felt like writing in spanish :-P
 * sergiusens thinks we need #snappy-es :-)
<ogra_> mvo, that sounds awfully recursive :) snappy ships snappy in a sap
<Chipaca> sergiusens: gah, and i have too many channels open, never saw your pm
<ogra_> *snap
<sergiusens> Chipaca, yeah, I'm thinking of using telegram more these days for private messages, but then notifications don't work for you :-P
<sergiusens> Chipaca, which brings to mind, you should use the ubuntu push notifications, I've heard they were implemented by a very good dev ;-)
<Chipaca> sergiusens: notifications work for telegram!
<sergiusens> Chipaca, oh, I thought they weren't working for you on the desktop
<Chipaca> sergiusens: it's just some of the group chats i've disabled them for
<sergiusens> oh, goodie
<Chipaca> sergiusens: ah, well, sometimes when pulseaudio is having a bad day, yes
<sergiusens> :-)
<pindonga> zyga, wow, this time after a second snapcraft clean and full run it seems to have worked!
<Chipaca> pindonga: snapcraft working? surely you jest!
<pindonga> Chipaca, I wish I was :)
<Chipaca> :)
<pindonga> Chipaca, I think it's one of these pieces of software that work with quantum mechanics
<pindonga> they only seem to work when smart people are watching me
<Chipaca> pindonga: you should get sergiusens to watch you instead
 * Chipaca runs for the hills
 * sergiusens read that
 * Chipaca runs faster
<sergiusens> pindonga, can I see your yaml?
<Chipaca> sergiusens: at least buy him dinner first
<pindonga> sergiusens, it worked , but sure, if you like :)
<sergiusens> pindonga, right, I want to know how it failed to make it easier
<ogra_> "can i see your yaml"  ... this has turned into a nasty channel over time
<pindonga> let me paste your a few things
<ogra_> everyone wants to see each others yaml !
<pindonga> sergiusens, http://pastebin.ubuntu.com/12998485/
<Chipaca> ogra_: it's called freiyamlkultur
<ogra_> lol
<Chipaca> ogra_: you wouldn't understand
<longsleep> ogra_: In your crazy config.sh for irc proxy, you are storing a yaml file separatly from the real config. Is that the suggested approach? I am currently processing existing config in both directions without storing the yaml.
<ogra_> longsleep, no idea whats the suggested approach, thats what i picked, one of the configs needs to be the master
<longsleep> ogra_: right, in spreed-webrtc the real ini config is the master and is used to generate yaml on read
<ogra_> you could surel also do it the other way round, but i want to reflect the implementation state in the snap, not all bip.conf options are handled yet
<ogra_> there is one issue with shell here ... at least with my approach of using eval ... you cant use dashes in options (shell doesnt allow vars to have them)
<longsleep> yeah, for now i chose python3 to create the config hooks
<ogra_> yeah, i didnt want to ship python in my snap :)
<longsleep> i am using python3 from the system - i figured that is safe enough for now
<ogra_> until we drop it, yeah
<zyga> pindonga: :)
<zyga> pindonga: magic
<zyga> pindonga: I'm glad I could help
<sergiusens> pindonga, zyga ah flexget has a strange setup.py
<pindonga> how so?
<sergiusens> pindonga, https://github.com/Flexget/Flexget/blob/develop/setup.py
<pindonga> oh, right
<sergiusens> not saying wrong, just strange ;-)
<pindonga> not setuptools based
<sergiusens> pindonga, right, so you don't get your requirements installed by default
<pindonga> right, but that failure was ok, easy to understand and fix
<pindonga> the first failure was odd
<pindonga> before I had to run snapcraft clean
<sergiusens> pindonga, that is a bug; mind logging it?
<pindonga> I'll try to reproduce it , then yes!
<sergiusens> pindonga, I bet if you run snapcraft all --force without cleaning again the error will show
<ogra_> mvo, would you mind if we moved the installation of the linux package and the creation of the device tarballs after the rootfs creation in livecd-rootfs ? (i,e, from a hook into live-build/auto/build)
<ogra_> that way we dont need to wipe all that stuff from /boot and can also create multiple tarballs fr different subarches without tainting the rootfs
<ogra_> i think we are currently doing it pretty wrong
<ogra_> (and it makes rpi device tarball creation really hard)
<ogra_> similar to how we do it for the phone device tarballs (or for the ac100 images in the past)
<jdstrand> pindonga: hi! you still have minecraft 0.1 in the store that is pending review. do you need it reviewed or do you plan to remove it?
 * pindonga checks
<pindonga> jdstrand, what minecraft?  I see no minecraft ;-)
<jdstrand> pindonga: thanks! :)
<longsleep> I just noticed that autopilot fails to start when bootup without network in 15.04/edge (added bug #1511374)
<ubottu> bug 1511374 in Snappy "snappy.autopilot service fails to start when no network connection" [Undecided,New] https://launchpad.net/bugs/1511374
<jdstrand> Chipaca: hi! I know you told me before, but I can't seem to find it.... how do I workaround bug #1509451 ?
<ubottu> bug 1509451 in Snappy "snappy update is not updating snappy-debug" [Critical,Fix committed] https://launchpad.net/bugs/1509451
<jdstrand> Chipaca: before I uninstalled and installed. I'm hitting this on another package and would prefer not to do that with this one
<Chipaca> jdstrand: from memory,
<Chipaca> jdstrand: for i in $( grep -L ^channel: /var/lib/snappy/meta/*.manifest ); do echo -e "\nchannel: stable" | sudo tee -a $i; done
<pindonga> so, I managed to build my snap pkg using snapcraft, but it fails review in the store
<pindonga> package contains external symlinks: /tmp/clickreview-kb8ua64p/usr/lib/python2.7/site-packages lint_external_symlinks
<pindonga> is there a way to fix this via snapcraft itself?
<sergiusens> pindonga, quick way, in snapcraft.yaml, for the part using python2 add 'snap: -usr/lib/python2.7/site-packages' and log a bug with a reproducer :-)
<jdstrand> Chipaca: yes, that worked. thanks!
<jdstrand> Chipaca: also, what is the deal with git vs bzr. should we only be using git now?
<Chipaca> jdstrand: yes
<jdstrand> ok
<Chipaca> jdstrand: bzr is so 2008
<ogra_> and rock solid :P
<jdstrand> but it is so under my fingers
<Chipaca> jdstrand: yeah :(
<Chipaca> jdstrand: still, it's proving to be less of a pain than i remembered it to be
<Chipaca> i guess the last time i looked was 1.4something-era?
<sergiusens> Chipaca, the git cli improved a lot
<sergiusens> Chipaca, and github is what really makes git easy to use
<jdstrand> curious on why git support in lp wasn't chosen
<longsleep> Chipaca: do you have any thoughts on ntp configuration in snappy? Is there anything planned to get rid of systemd ntp client and have snappy use a ntp client which can validate the time?
<Chipaca> longsleep: i still need to look up that about validation
<Chipaca> longsleep: do you have anything you can point me at wrt that?
<longsleep> Chipaca: sure - https://marc.info/?l=openbsd-tech&m=142356166731390&w=2
<longsleep> Chipaca: also a nice read is https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-using-it.html
<longsleep> Chipaca: also agl from Google has some nice writeups about this how its done in Chrome OS
<Chipaca> jdstrand: thoughts on that?
<longsleep> Chipaca: here it is, part of a larger discussion: https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/oj2xXq3CF0E/f7BtsfkVhe8J
<longsleep> Chipaca: I think bug #1504657 is pretty critical, especially as systemd is using google timeservers by default
<ubottu> bug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/1504657
<Chipaca> longsleep: not in ubuntu
<longsleep> Chipaca: oh really? I was trying to find a patch for that but could not find it
<ogra_> systemd onbly uses google servers for its test
<Chipaca> longsleep: it's a compile-time setting, and /etc/systemd/timesyncd.conf shows you the compile-time defaults, commented out
 * Chipaca wrote that filepath from memory, and that's not a good memory
<longsleep> Chipaca: ok then, that is slightly better then
<ogra_> the actual server used in packages is supposed to be picked by the distros
<jdstrand> ogra_: I think it is using debian time servers though. that should be changed to ubuntu (but obviously not just for snappy)
<ogra_> (and afaik all distros that ship systemd use their own setting here)
<Chipaca> ntp.ubuntu.com
<Chipaca> is what's built in
<ogra_> jdstrand, yeah, it should be ntp.ubuntu.com for us
<longsleep> Chipaca: do you have a link to the patching?
<ogra_> right
<ogra_> longsleep, only LFS wouold use the google servers :)
<jdstrand> Chipaca: I think it is premature to make tlsdate or openntpd (the OpenBSD version)
<jdstrand> the default
<longsleep> jdstrand, Chipaca - i agree with that statement, thats why i ask for a way to disable timesyncd in snappy (by config) and by that make it possible for snaps to provide time synchronization
<jdstrand> longsleep: I agree it should be disableable
<Chipaca> yep, and ogra's already looked into it
<Chipaca> and shouted at me because of the issues each new thing we add to writable brings
<longsleep> ok cool
 * ogra_ hugs Chipaca 
 * Chipaca hugs ogra_ back
<ogra_> i didnt shout :)
<ogra_> I NEVER SHOUT !!!!
<jdstrand> do note, for the moment the templated policy will block setting the time
<ogra_> time is overrated anyway ...
 * ogra_ is more for space than for time
<Chipaca> jdstrand: did i ever tell you about the switch from @snapd to /run/snapd.socket?
<jdstrand> no
<jdstrand> Chipaca: is that live in 15.04 or just for rolling?
<jdstrand> Chipaca: ie, I need to know where to upload the change
<longsleep> jdstrand: templated policy means when running unconfined or with an own policy it should work to set the time from a snap right?
<ogra_> jdstrand, i think 15.04 is done and wont change much wrt features
<Chipaca> jdstrand: ok. No big deal, as the only people using it right now are unconfined, but yes i'll get you that info
<Chipaca> ah, good point
<Chipaca> jdstrand: just rolling :)
<jdstrand> longsleep: templated policy means the default policy and shipped policy groups. running unconfined would work. using security-policy would work.
 * ogra_ expects us to move stable over to 16.04 after feature freeze
<longsleep> jdstrand: ok great, thanks for confirming
<Chipaca> ogra_: i know you didn't shout, i lied. In my defence, it was for effect (?)
<ogra_> and til then leave it untouched
<ogra_> Chipaca, being the #1 drama queen in the company i think i can appreciate fishing for effect :)
<jdstrand> longsleep: I am actually revamping security-override to make it more relevant on snappy, so it will be easier to say 'give me the default policy, but with this one extra thing'
<jdstrand> it would still trigger a manual review
<longsleep> jdstrand: ah that sounds great
<jdstrand> but, it will mean that it opens the possibility for a time server with an addition for changing the time to be more easily reviewed and accepted
<longsleep> Btw, i have another interesting use case for the problem that one snap cannot write to another snap. I have used a framework snap to provide a binary. Now that binary is executed from another snap. Execution works fine, though the runtime environment of that binary is not allowed to store or write files into the environment of the calling snap. Any ideas / thoughts on such a use case?
<tedg> It seems like the framework shouldn't provide a binary that's expected to be used by other snaps. That binary should be included in those other snaps and communicate with the framework via IPC.
<longsleep> tedg: yeah i know that this is the indended behavior, though i thought i try to avoid having to ship the very same binary in 20 snaps.
<tedg> longsleep: Probably not a good optimization overall, fights against the design of the system for a minimal gain.
<sergiusens> longsleep, what binary is that and maybe doing ipc is better if it is home grown
<jdstrand> longsleep: you can make it work by adjusting the framework snaps framework-policy to allow the writes you need
<longsleep> sergiusens: in that case - openssl
 * sergiusens runs away from openssl
<sergiusens> :-)
<jdstrand> longsleep: just like you added an 'ix' rule to the policy, you would add file rules
<sergiusens> I'll defer
<longsleep> jdstrand: yes thats possible, though i am wondering if there might be a better solution
<longsleep> without having to ship openssl in essentially all the snaps
<jdstrand> longsleep: well, given the contraint that it must write to the framework snap's dir, no.
<longsleep> sergiusens: ok, i lied - its actually libressl
<jdstrand> longsleep: but, a framework shipping binaries is problematic
<jdstrand> longsleep: if the framework uses shared libs, the calling snap won't have those, so you need to deal with that
<longsleep> jdstrand: i could do most of the stuff with stdout with openssl and have the calling environment pipe it to a file. Unfortunatly not all commands get that right.
 * jdstrand nods
<longsleep> jdstrand: snapcraft creates a wrapper script which sets the ld paths
<jdstrand> longsleep: yes, but not for external snaps
<longsleep> jdstrand: external snaps? what does that mean?
<jdstrand> longsleep: ie, it will work fine from the shell and from within the snap itself
<jdstrand> but another snap won't be able to use that wrapper
<longsleep> oh
<jdstrand> longsleep: snap foo ships libressl, ship bar uses it
<longsleep> thats bad then for the stdout apprach as well
<jdstrand> anything in foo can use it fine
<jdstrand> bar won't because bar's SNAP_ directories are set to its own paths
<jdstrand> it can be made to work by shipped a different wrapper that hard codes /apps/foo/current/... in LD_LIBRARY_PATH
<longsleep> jdstrand: why not? when i call /apps/libressl/bin/libressl-openssl i was assuming that the wrapper script sets it again
<jdstrand> but like I said, this is all rather ugly. frameworks aren't really meant for this
<jdstrand> longsleep: look at /apps/libressl/bin/libressl-openssl
<jdstrand> longsleep: it is using SNAP_APP_PATH
<jdstrand> anything in foo will have a SNAP_APP_PATH that is /apps/foo/...
<longsleep> jdstrand: mhm hold on - i think it is setting it
<jdstrand> anything in bar will have a SNAP_APP_PATH that is /apps/bar
<longsleep> jdstrand: see http://paste.ubuntu.com/12999228/ thats the wrapper script as generated
<longsleep> i did not test to run this from another snap, but i think it should just work
<longsleep> maybe i am missing something
<jdstrand> longsleep: snapcraft did not create that
<jdstrand> longsleep: that is what is in /apps/bin
<longsleep> jdstrand: uhm ok - what created it then?
<jdstrand> longsleep: snappy install
<longsleep> ah
<jdstrand> longsleep: but that isn't what I'm talking about
<jdstrand> apps cannot call things in /apps/bin
<longsleep> i see
<jdstrand> cause that requires calling the privileged launcher to setup a sandbox
<jdstrand> no sandbox within a sandbox is allowed
<jdstrand> (it can't work for a lot of reasons)
<jdstrand> longsleep: what I'm saying is you ship another wrapper
<longsleep> got it - so to be in line with the framework concept, i would have the libressl snap create some IPC interface and have the other snaps call that.
<jdstrand> eg, foo ships /apps/foo/current/bin/libressl.external
<longsleep> ok
<jdstrand> the bar uses /apps/foo/current/bin/libressl.external
<jdstrand> /apps/foo/current/bin/libressl.external hardcodes LD_LIBRARY_PATH/whatever else to use /apps/foo/current/usr/lib/...
<longsleep> jdstrand: and that wraper i would create manually
<longsleep> =r
<longsleep> +r
<jdstrand> you adjust foo's framework-policy to allow executing /apps/foo/current/bin/libressl.external, etc
<jdstrand> longsleep: you would have to
<longsleep> jdstrand: got it - great thanks!
<jdstrand> bar depends on the foo framework and adds foo's framewrok-policy cap to its caps
<longsleep> yeah - so is that a way how frameworks "could" be used or should i better investigate a more general approach on sharing binaries between snaps?
<jdstrand> longsleep: it can be made to work, but you'll see that it is not 'the snappy way'. the 'snappy way' is create a service that apps can consume via network, dbus or unix socket
<longsleep> jdstrand: all right, i might try that then and see how it goes :)
<longsleep> jdstrand: is there some example for this somewhere?
<jdstrand> longsleep: it is the only way to share binaries in the traditional sense of executing them. a service could be in place to do it though. eg, setup a socket then pipe commands over it for the server to process
<jdstrand> longsleep: no, it isn't the snappy way :)
<jdstrand> it is important to keep in mind that frameworks are not meant as a general purpose way to ship libraries (and by extension binaries). it is a different paradigm than debs
<jdstrand> longsleep: another thought, you might find it easier if the framework snap's binaries that you expose in framework-policy are statically linked
<longsleep> jdstrand: yeah i get that - though i still feel the need to share some things wto avoid duplicating so much.
<longsleep> jdstrand: true, libressl is easy to link statically.
<longsleep> others might be not so easy
<jdstrand> I believe tedg can comment on duplication. I'll just say that it the issue is understood and that people are thinking about how to improve it
<longsleep> jdstrand: btw, you mentioned unix sockets, i have another snap providing one - problem is that there was no non persistent location which i could use in the past like /run or something. Do you know if that has changed?
<longsleep> jdstrand: or where do you suggest to put the socket files?
<jdstrand> longsleep: by definition apps are isolated from each other, so no, there is no shared dir for that sort of thing
<jdstrand> longsleep: a framework can simply expose it via framework-policy
<jdstrand> apps within the same snap are free to use and access SNAP_APP_DATA_PATH
<jdstrand> a framework snap would put a named socket in its SNAP_APP_DATA_PATH and have framework-policy allow access to it
<longsleep> jdstrand: yes that is what i meant. That is a persistent location. There should be a temporary location similar to that so apps from the same snap can access the socket.
<longsleep> jdstrand: i tried to put it in /tmp earlier until i discovered that this folder is per process
<jdstrand> there are also abstract sockets-- but those are mediated too (same process as for named sockets)
<jdstrand> longsleep: oh, use, to have it removed on reboot. there is a path in /run that is app specific
 * jdstrand fins it
<jdstrand> finds*
<longsleep> jdstrand: yeah i mentioned this a couple of months back, i lost track of it - maybe someone has added it in the meantime.
<jdstrand>  /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/*
<longsleep> jdstrand: I think sockets or anything else which is used for IPC should be there and not in SNAP_APP_DATA_PATH
<longsleep> jdstrand: cool thanks - i will try that asap
<jdstrand> I'm not sure the launcher is creating /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ though. if not that is a bug
<jdstrand> longsleep: you can also use an abstract socket
<jdstrand> create it as @<pkgname>_... and processes within the same snap can use it
<jdstrand> (we have this rule for that: unix peer=(label=@{APP_PKGNAME}_*),)
<longsleep> jdstrand: That works with the normal c level socket code? I want to avoid patching upstream code.
 * longsleep does no nothing about abstract sockets
 * longsleep reads about it now
<jdstrand> abstract sockets are something that is available to standard Linux and all major languages on Linux support it, yes
<jdstrand> longsleep: man unix
<jdstrand> it requires patching the code though, but in a minor way
<longsleep> jdstrand: ok - i will investigate on this. Thanks for all your help an suggestions!
<jdstrand> np
<elopio> I hurt my back yesterday. As of today, I'm officially old.
<jdstrand> longsleep: one more item for food for thought> there is a coupling between an app and its depenedent framework regardless. with a service and IPC protocol (network, unix, dbus) the coupling is limited to the protocol itself. if you introduce binaries and shared libraries, there is a much tighter coupling that would likely be brittle. this is something snappy attempts to solve, which is part of why doing the shared binaries approach is not the snappy
<elopio> Chipaca: what do you do to test your first boot branch? unpack the .img and overwrite some files there?
<longsleep> jdstrand: yeah - i agree on the idea. Though in some situations it might be overkill and sharing a binary might be much easier.
<Chipaca> elopio: that would work. On the other hand, mvo just went ahead and merged it :)
<elopio> Chipaca: I saw that. I was just wondering how to avoid waiting until a new image is generated.
<jdstrand> longsleep: I agree there might be times, particularly with a static binary or shell script
<longsleep> longsleep: I will for sure make a snap with a IPC service to check it out and get some ideas.
<Chipaca> elopio: you could boot, remount rw, replace snappy and the firstboot .service files, remove the eth file and the firstboot stamp file, and reboot
<elopio> ah, there's a firstboot stamp file. That will be handy.
<mvo> Chipaca, elopio: I'm not sure I follow, but would it help if I create a new image for you guys?
<elopio> mvo: yes, please.
<Chipaca> elopio: /var/lib/snappy/firstboot/stamp
<mvo> elopio: a 16.04 image I presume?
<elopio> mvo: rolling, please.
<jdstrand> Chipaca: fyi, upload snapd.socket change
<jdstrand> uploaded*
<Chipaca> jdstrand: muchas gracias
<ogra_> mvo, hmm, looks like two image builds of wily you did exploded
<mvo> ogra_: yes
<mvo> ogra_: I just asked in #launchpad
<ogra_> ah, k
<mvo> <mvo> hm, I get build failures in the livefs build for https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image with "?: keyserver.ubuntu.com: Connection refused". or is that a red herring?
<ogra_> ?: keyserver.ubuntu.com: Connection refused
<ogra_> gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
<ogra_> gpg: no valid OpenPGP data found.
<ogra_> yeah, looks like some bad network connection
<ogra_> mvo, btw, why are the dailies disabled for 15.04 ?
<ogra_> i thought we ant to get security and SRU fixes automatically into 15.04 edge
<ogra_> was that a concious decision or just an oversight ?
<mvo> ogra_: I don't know why they are disabled, not done by me
<ogra_> ah, k
<mvo> ogra_: I wish we had a easier way to track this :/
<ogra_> yes
<mvo> i.e. why stuff happened in the shared account
<ogra_> well, usually it has a bzr record ... crontab is a bit special though
<ogra_> (since there are often temporary changes)
 * mvo nods
<longsleep> We just found a critical issue with ubuntu-snappy.firstboot.service - it fails to run when the a preinstalled snap is configured (Oct 29 15:26:16 localhost.localdomain snappy[808]: config failed with: 'aa-exec: ERROR: profile 'spreed-webrtc.sideload_snappy-config_IENQKIBcWPBJ' does not exist) - anyone can tell me if that is an error on our end? I added bug #1511435
<ubottu> bug 1511435 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains preinstalled snap" [Undecided,New] https://launchpad.net/bugs/1511435
<Chipaca> longsleep: looking
<mvo> elopio: a new image of rolling finished building 1min ago :) needs to get imported into the system-image server now, then its ready for you to test
<kyrofa> Hey ogra_ do you know what kernel config we're using for squashfs?
<ogra_> there are kernel configs for squashfs (beyond turning it on/off in the kernel ?)
<kyrofa> ogra_, so many...
<ogra_> really ?
<kyrofa> ogra_, http://lxr.free-electrons.com/source/fs/squashfs/Kconfig
<ogra_> wow, that grew quite a lot ...
<kyrofa> ogra_, they aren't required, but I thought maybe we were tuning the cache size for embedded platforms?
<ogra_> no, i dont, but the kernel config file should tell you
<ogra_> just check on a desktop in /boot/config-* ...
<kyrofa> ogra_, ah, so the config is the same?
<ogra_> the kernel is the same
<kyrofa> Okay good deal
<kyrofa> ogra_, thank you!
<fgimenez_> Chipaca, about the login test https://github.com/ubuntu-core/snappy/compare/master...fgimenez:cli-login-test
<fgimenez_> Chipaca, you can try it with go run _integration-tests/main.go -snappy-from-branch -filter loginSuite.* -revision 208
<rickspencer3> if I have my Go code in launchpad, how do I go about telling snapcraft how to go get it? Or is that not supported/possible?
<longsleep> Chipaca: the firstboot service is very picky - it also fails with things like: main.go:57: DEBUG: [/usr/bin/snappy firstboot] failed: configuring an invalid snappy package
<longsleep> Chipaca: i suggest to make things like that non fatal
<Chipaca> longsleep: agreed, especially given that the error is essentially invisible, and all that'll happen is that you won't get an eth device or whatever
<Chipaca> oh, wait
<Chipaca> yes you do
<elopio> rickspencer3: take a look at examples/gopaste. Just instead of git:... use lp:...
<Chipaca> longsleep: what's the consequence of the failure you're seeing?
<rickspencer3> elopio, I think I tried that, do you have a link where I can see the examples?
<Chipaca> fgimenez_: what am I looking at here?
<Chipaca> fgimenez_: this is whaty i get; http://pastebin.ubuntu.com/12999856/
<elopio> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/gopaste/snapcraft.yaml
<fgimenez_> Chipaca, you should first get the branch with the changes, https://github.com/fgimenez/snappy/tree/cli-login-test
<fgimenez_> or apply the diff to master
<Chipaca> ahh :)
<rickspencer3> elopio, ok, thanks, but I meant an example that uses launchpad
<fgimenez_> yep, sorry for not being clear :)
<elopio> rickspencer3: we don't have an example that uses both go and launchpad
<elopio> rickspencer3: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/libpipeline/snapcraft.yaml
<longsleep> Chipaca: well, i am not sure about the consequence - we are experimenting with providing config and snaps via oem snap and i am reporting issues which appear.
<rickspencer3> elopio, ok, that shows that source: uses the same syntax as bzr for lp:~ blah blah blah
<rickspencer3> which is groovy, but it doesn't for me with Go
 * rickspencer3 files bug
<Chipaca> longsleep: thank you. Please do also file a bug for the "any config makes firstboot fail" bug
<Chipaca> longsleep: you only see that failure because you're actively searching for it, yes?
<elopio> rickspencer3: thanks. I only see a piece of code that's different in the go plugin, that might be the problem.
<elopio> I'll take a look.
<longsleep> Chipaca: Well, no - its not that i am searching for bugs :)
<Chipaca> longsleep: i mean, the system boots and works as you'd expect?
<francksolo> :'( you people broke personal
<longsleep> Chipaca: except that the stuff i wanted to test from the OEM snap (config, and snap) did not work yes.
<ogra_> francksolo, ?
<longsleep> Chipaca: not sure what else might be not applied if the service fails like this
<francksolo> ogra_, the mouse input doesn't register :))
<ogra_> francksolo, you are aware that this is the snappy channel  ?
<francksolo> ogra_, i can click on the login input 4 ever and nothing
<ogra_> we dont do personal
<Chipaca> longsleep: once one config fails, all configs that come later won't be applied
<francksolo> ogra_, isn't personal snappy based?
<ogra_> (well, there was a one shot experimental image to test the build infrastructure, but thats about it)
<Chipaca> francksolo: only snappy ubuntu core is supported
<Chipaca> francksolo: snappy personal is a sporadic experiment
<longsleep> Chipaca: ok that makes sense, so s comes before u, means ubuntu-core config will also not be applied
<francksolo> oooooo but the ubuntu roadmap graph
<ogra_> snappy personal will surely exist one day ... but that day is far out
<ogra_> francksolo, you mean the phone roadmap ?
<francksolo> :'(
<Chipaca> longsleep: from looking at the code i would say the order is the one you defined in the oem yaml
<ogra_> pocket desktop is different from "personal snappy PC image"
<francksolo> ogra http://i.imgur.com/plQvwch.jpg
<Chipaca> francksolo: that very thin line is where we are now
<francksolo> so.. desktop next is dead, personal is nowhere :(
<francksolo> :'( x10000
<Chipaca> francksolo: "desktop next is dead"?
<Chipaca> sigh
<francksolo> yep, 404
<Chipaca> francksolo: you probably want dpm
<longsleep> Chipaca: the other bug also added as #1511448
<Chipaca> unless i've got my faces wrong
<longsleep> bug #1511448
<ubottu> bug 1511448 in Snappy "ubuntu-snappy.firstboot fails when oem snap contains config for snaps not preinstalled, built-in" [Undecided,New] https://launchpad.net/bugs/1511448
<ogra_> francksolo, as you can see the merge only happens in 16.10 (or even after)
<Chipaca> longsleep: much appreciated sah
<ogra_> francksolo, for 16.04 ubuntu personal isnt a thing
<francksolo> yeah.. but i need somehing to play with until 16.10 :D
<elopio> yes, this is busted.
 * francksolo n4 or the pd 
<ogra_> francksolo, just install 15.10 and install the Mir session
<francksolo> 15.10 is dead
<francksolo> for unity8 (you will not get updates)
<francksolo> vivid or xenial
<francksolo> ogra_, unity8 mir session is nice but it's not desktop next
<ogra_> well, then take a n4 and install all the bits you need
<francksolo> you can't install apps from the store
<francksolo> ogra_, yeah
<ogra_> though thats more appropriate for #ubuntu-touch :)
<francksolo> nah :D i like this channel more
 * francksolo #snappy is fantastic
<francksolo> ok. sorry for spam :D
<kyrofa> francksolo, you can't make a personal image from ubuntu-device-flash?
<ogra_> then you have to start talking about headless stuff :)
<ogra_> kyrofa, no
<ogra_> kyrofa, it was disabled
<kyrofa> ogra_, ah, I didn't realize that
<ogra_> the iage we had was just a proof of concept ... it wasnt supposed to even persist that long
<ogra_> *image
<ogra_> non-phone-personal images will be a thing in 16.10 ... but not before
<Chipaca> fgimenez_: do you know how i can merge your repo to mine in git?
 * Chipaca habla poco git
<longsleep> Chipaca: git pull --no-ff git@github.com:some.git somebranch
<Chipaca> longsleep: m'kay ...
 * Chipaca tries
<longsleep> Chipaca: usually you create a local branch frist and merge there for review and local changes and then merge into that local branch, review and fix up and then merge that fixed up branch to whatever branch you want to continue
<elopio> sergiusens: tedg: please put this one high on your backlog: https://bugs.launchpad.net/snappy/+bug/1511447
<ubottu> Launchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed]
<rickspencer3> elopio, I assume I am doing something wrong, but I logged a bug anyway, if you want to take a look: https://bugs.launchpad.net/snappy/+bug/1511447
<ubottu> Launchpad bug 1511447 in Snappy "snapcraft stage does not work with Go and Launchpad" [Undecided,Confirmed]
<elopio> rickspencer3: it's not you, it's us :)
<rickspencer3> very rarely the case, but ... sure ;)
<Chipaca> fgimenez_: now i'm getting http://pastebin.ubuntu.com/13000131/
<Chipaca> fgimenez_: is that what you wanted me to see and look at?
<fgimenez_> Chipaca, yes, that "inappropriate ioctl for device" and "broken pipe"
<Chipaca> fgimenez_: right. If you really need to test that, you're going to need something that looks a lot more like a terminal :)
<Chipaca> fgimenez_: how's it being run now?
<Chipaca> fgimenez_: you exec.Command("snappy", "login") ?
<fgimenez_> Chipaca, :) yes, including the loginName, in setupInteractiveCmd
<fancycode> Hi, I'm building an image using a custom oem and additional built-in snaps. The oem snap specifies "architecture: armhf" but the architecture of the additional snaps is checked against the architecture of my host machine ("amd64") so "ubuntu-device-flash" fails with "package's supported architectures (armhf) is incompatible with this system (amd64)". Is there a way to specifiy the arch as parameter to "ubuntu-device-flash"? (for now I removed the chec
<fancycode> k in snapp.go and rebuilt the tool)
<Chipaca> fancycode: yeah, bug in u-d-f
<Chipaca> fancycode: i think sergiusens knows about it, but check with him just in case
<Chipaca> Facu found it the other day
<Chipaca> at least, that's when i found out about it
<Chipaca> fgimenez_: so
<fancycode> Another thing: I added "load-kernel-modules: [X, Y]" to the ubuntu-core conf in my oem snap, now the firstboot service fails with "/usr/bin/snappy[799]: main.go:57: DEBUG: [/usr/bin/snappy firstboot] failed: open /etc/modules-load.d/ubuntu-core.conf.tmQQxGVXiMGK: read-only file system". Anything I need change in my snap?
<longsleep> fancycode: I just added bug #1511464 for this
<ubottu> bug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/1511464
<fancycode> longsleep: thanks
<ogra_> longsleep, no, it isnt missing from writable paths ...
<longsleep> ogra_: no? its not in my writable-paths
<ogra_> it is another one of these "snappy atomic write" issues that forces us away from using writable paths at all
<ogra_> hmm, i thought i added it to rolling
<longsleep> ah rolling
<longsleep> we are using 15.04/stable for now
<ogra_> still
<Chipaca> fgimenez_: http://pastebin.ubuntu.com/13000343/
<Chipaca> fgimenez_: you need an actual tty, e.g. via a pty
<ogra_> all config options that snappy uses use that atomic write and are thus not working with writable paths
<Chipaca> fgimenez_: that ^ is how you'd go about that
<Chipaca> fgimenez_: (the io.Copy is me just being lazy at the end; a second f.Read() works)
<Chipaca> fgimenez_: the \n after the password is very important :) otherwise it hangs forever, as expected
<longsleep> ogra_: ok, but writing to /etc/modprobe.d works just fine from firstboot - or is there some other mechanism involved there?
<Chipaca> fgimenez_: github.com/kr/pty is already packaged in ubuntu, fwiw
<Chipaca> fgimenez_: golang-pty-dev
<ogra_> longsleep, not from snappy config
<fgimenez_> Chipaca, great thanks a lot, i'll try it, should it be added to the dependencies?
<ogra_> longsleep, snappy configs atomic write actually requires that we re-locate the whole dir and link it or re-loactae the whole file and link it
<fgimenez_> Chipaca, swordfish, the better marxist password ever :D
<ogra_> which kind of defeats the purpose of writable-paths being bind mounts
<fancycode> sergiusens: I found a bug in u-d-f where the architecture of built-in oem snaps is checked against the arch of the host instead of the oem snap, causing "package's supported architectures (armhf) is incompatible with this system (amd64)". Chipaca told me you might know about it?
<longsleep> ogra_: ok - so what should we do then - to load kernel modules on boot?
<ogra_> longsleep, hack it into the buuld system to force moving of the dir to a writable location and then create a ton of links for all files in there
<Chipaca> ogra_: i've got too much on my plate today, but tomorrow morning maybe we have a chat about writable paths a bit? figure out if we can have the pig and the sausage
<Chipaca> i hear tofu sausages are not completely horrible
<ogra_> Chipaca, yeah, that would help ... i mean, i dont mind dropping writable-paths if we find anything better .... the current situation starts to get awkward though
<sergiusens> fancycode, the oem snap should be arch all though
<Chipaca> ogra_: fwiw by the pig and the sausage i mean atomic writes and 3-may merges on update. Which is which I don't know :)
<ogra_> Chipaca, hmm, though i'm a bit confused, i thought it worked in 15.04 ...
<ogra_> iirc it was even actually tested when landing
<sergiusens> fancycode, or we need to add yet another switch to u-d-f to query the store for it beating the purpose
<Chipaca> ogra_: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001102.html
<fancycode> sergiusens: sorry, the oem snap result is arch all, however inside it specifies oem -> hardware -> architecture: armhf
<ogra_> now ... if my firefox wouldnt totally act up
<ogra_> grrr
<Chipaca> ogra_: lynx -dump ftw ;)
<ogra_> heh
<ogra_> https://launchpadlibrarian.net/223054208/ubuntu-core-config_0.6.15%2Bppa24_0.6.15%2Bppa25.diff.gz
<ogra_> so this definitely landed in 15.04
<Chipaca> fgimenez_: wrt dependencies, yes, if you go with this solution it should be added to the dependencies.tsv (and to debian/control's build-dependens if/when we run integration suite from buildpackage)
<Chipaca> ogra_: ah, yes, the problem is the atomic
<ogra_> so yeah, another atomic write
<Chipaca> yeh
<ogra_> Chipaca, right, i was just not sure it had landed in 15.04
<longsleep> cat /etc/system-image/writable-paths |grep modules
<longsleep> (i see nothing)
<ogra_> especially because longsleep calims he doesnt have the dir in writavble-paths
<Chipaca> maybe longsleep is using ancient software
<Chipaca> like pre-last-week
<longsleep> maybe
<Chipaca> :)
<longsleep> actually it might be true again :D
<ogra_> hah
<longsleep> but fancycode is not using ancient software
<ogra_> well, it wont fix you :)
<longsleep> i current have ubuntu-core         2015-10-13 196
<ogra_> the dir is writable but the tool cant write
<longsleep> which might be a little old
<ogra_> ancient
<longsleep> but fancycode has 9 (stable) and also does not see the patch you linked
<ogra_> weird, iirc the release was held back for it to land
<Chipaca> longsleep: i suspect the preinstalled codepath has a lot less testing than we'd like. I'll have to dig into that.
<Chipaca> longsleep: tomorrow or maybe next week...
<Chipaca> longsleep: how urgent is this for you?
<fancycode> I'm running ubuntu-core-config 0.6.15+ppa24
<longsleep> Chipaca, ogra_ reason is that 9/stable has 0.6.15+ppa24 and the patch is for 0.6.15+ppa25
<fancycode> so that's one version too old then, right?
<ogra_> yeah
<ogra_> the release was on the 23rd
<ogra_> the patch only landed on the 27th
<Chipaca> /o\
<longsleep> ok so its already fixed and the next release will have it - all good then
<longsleep> Chipaca: got me again, i am running  0.6.15+ppa22 :D
<fgimenez_> Chipaca, works like a charm thanks! :)
<longsleep> Chipaca: If it eventually works then its fine. So next week no problem.
<Chipaca> longsleep: wrt that package in oem, you're getting it preinstalled from the store, or from local fs?
<longsleep> Chipaca: local fs
<Chipaca> longsleep: in other words, is it right to be 'sideload'
<Chipaca> ah, ok
<Chipaca> phew :)
<longsleep> Chipaca: yes it is sideloaded
<longsleep> Chipaca: its not found in the store, because the package is armhf only and u-d-f does not find those
<Chipaca> gaarhgh
<Chipaca> longsleep: sorry :(
<fancycode> Chipaca: that's most likely also because I'm building on an amd64 host, maybe can try on an armhf tomorrow
<longsleep> Chipaca: well - fancycode is having all the fun with it :)
<fancycode> longsleep: haha :-/
<Chipaca> yes, it's because u-d-f is not calling SetArch before installing
<Chipaca> it's a silly fix, but somebody needs to do it :)
<fancycode> Chipaca: is that "SetArchitecture" from snappy/arch.go?
<Chipaca> yep
<fancycode> ok, I might be able to take a look tomorrow
<longsleep> ogra_: So i guess you can close bug #1511464 as you already fixed it and it will be released eventually.
<ubottu> bug 1511464 in Snappy "/etc/modules-load.d missing from writable-paths, used by snappy firstboot " [Undecided,New] https://launchpad.net/bugs/1511464
<ogra_> longsleep, no, it isnt fixed
<ogra_> i mean, it is in writable-paths ... but wont be usable yet
<ogra_> we'll have a discussion about a proper fix tomorrow
<longsleep> ogra_: ok great
<Chipaca> longsleep: https://lists.ubuntu.com/archives/snappy-devel/2015-October/001124.html
<john-mcaleely> ogra_, are there plans for snappy on the raspberry pi to expose things like the SPI bus in the connector to app snaps?
<john-mcaleely> maybe that already works?
<ogra_> yeah, it does
<john-mcaleely> yay!
<john-mcaleely> must play more with mine, I guess
<ogra_> you might need to adjust bits in config.txt for finer grained stuff, but in general everything you might want should be there or easy to enable
<john-mcaleely> sure, that's cool
<pindonga> sergiusens, is there a way to exclude files in the snap stage, or just to include?
<pindonga> (in snapcraft)
<sergiusens> pindonga, get snapcraft 0.4 (apt update) and then run 'snapcraft help plugins'
<sergiusens> pindonga, shorter answer is with a preceding '-'
<pindonga> ack
<pindonga> tx
<pindonga> sergiusens, the bug you asked: https://bugs.launchpad.net/snapcraft/+bug/1511440
<ubottu> Launchpad bug 1511440 in Snapcraft "python based package created using external symlink" [Undecided,New]
 * pindonga just noticed the title was wrong and updated it
<tedg> What is the bazaar plugin to do fastimport/export ?
<rickspencer3> so, I want to make a snap that is not a service, but runs like an app
<rickspencer3> i.e. you ssh in and run a command
<rickspencer3> anyone have an example of snapcraft doing that?
<tedg> rickspencer3: binaries is the header
<rickspencer3> binaries instead of services?
<rickspencer3> that sounds easy
<tedg> https://gist.github.com/ted-gould/304a3a828baaaaed272f
<rickspencer3> hey tedg, this snaps up no problem, but ...
<tedg> Heh, then my job is done :-)
<rickspencer3> but then when I use it in the kvm instance, it says it can't find zork?
<rickspencer3> http://pastebin.ubuntu.com/13002903/
<tedg> Like literally zork?
<rickspencer3> tedg, mind taking a quick look?
<rickspencer3> yeah
<tedg> Oh, I see. I was confused :-)
<rickspencer3> yeah, well, without the link, it was a pretty confusing question ;)
<tedg> rickspencer3: Is there a zork1.zork in /apps/bin ?
<rickspencer3> no
<rickspencer3> tedg, no
<rickspencer3> is that what I need?
<rickspencer3> make a bash file and put it there?
<tedg> Hmm, yeah, but snappy should build it for you.
<tedg> Is there a "binaries" in /apps/zork1/current/meta/package.yaml ?
<rickspencer3> um
<rickspencer3> tedg, yes
<rickspencer3> it has the exec like I wrote it in snapcraft.yaml
<rickspencer3> and a ... name:zork
<rickspencer3> well .. name: zork
<tedg> Yeah, that seems right. It should be roughly your snapcraft.yaml without the "parts" section.
<rickspencer3> tedg, but I never made an actual file called "zork" anywhere
<tedg> rickspencer3: I don't think it'll be "zork", but it'll be "zork1.zork" ($pkg.$bin)
<rickspencer3> tedg, ok, so I did zork1.zork, and got an error like: binary must be inside /apps/zork1.sideload/ or /oem/zork1.sideload
<tedg> I think that snappyd is the person that is supposed to create that script.
<tedg> Hmm, sorry rickspencer3 I'm not sure what could be up there.
<tedg> Snappy should be making the shell script wrapper based on the binaries
<rickspencer3> tedg, I think my VM is not up to date on snappy
<rickspencer3> maybe if I force it to the last stable 15.04 release?
<tedg> Sure, you shouldn't have to force it, it should upgrade itself unless you turned that off.
<tedg> sudo snappy upgrade to upgrade
<tedg> snappy list should show your version.
<tedg> ubuntu-core                   2015-10-23 9            ubuntu
<rickspencer3> tedg, well, it keeps telling me that it is going to reboot later :)
<tedg> Heh
<rickspencer3> hmmm
#snappy 2015-10-30
<liuxg> I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error.
<liuxg> I have compiled a .snap file for the java sample app at https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world, and I have deployed onto my KVM. what is the correct command to run the java? I did "java-hello-world.wrapper", but I got error like "java-hello-world.wrapper" command is not found error.
<woodrowshen> hi, i have a problem about snapcraft, may someone give a hand ?
<dholbach> good morning
<zyga> good morning :)
<fgimenez> good morning zyga and all
<longsleep> Good morning snappy
<longsleep> Now with snapcraft and snappy on GitHub, do you guys accept and review pull requests there or is that still to be done through launchpad/bzr ?
 * longsleep hopes to get rid of git-bzr eventually
<mvo> longsleep: we prefer github now
<mvo> longsleep: we will stop the bzr repos at some point (once the migration is fully done)
<longsleep> mvo: yay i like this!
<dholbach> niemeyer, do you know when the snapcraft daily builds will be set up to build from github?
<dholbach> can we also set https://launchpad.net/snapcraft up so that bugs are not accepted any more?
<woodrowshen> hi, can I ask snapcraft related problems here ? @@a
<ogra_> woodrowshen, indeed
<ogra_> (not all people that can answer might be awake yet though, so be patient)
<woodrowshen> ogra_: thanks. :)
<woodrowshen> woodrowshen: i just clear one thing about snapcraft, can the snapcraft build a armhf snap ?
<woodrowshen> i just clear one thing about snapcraft, can the snapcraft build a armhf snap ?
<ogra_> yes, but it needs an armhf environment
<ogra_> (i.e. a native armhf install on a board, or an armhf container or a vm)
<ogra_> there is no cross building yet
<woodrowshen> ogra_: ok, that's point i'm stuck...
<ogra_> what do you want to do ?
<woodrowshen> use snapcraft to build grafana snap for armhf
<ogra_> well, there are several ways to do that
<ogra_> create an armhf chroot on your PC is most likely the easiest but wont work aith all compilers (go and .net/mono definitely have issues)
<ogra_> *with
<ogra_> assuming you have an arm board for testing your snap, using a chroot on the arm board would then be my second choice
<ogra_> and third you can indeed run a full arm VM in which you build, though thats the slowest option
<woodrowshen> thanks your suggestion. Fortunately, we have a native arm env on cloud, scaleway :)
<woodrowshen> for originally, i just wrote makefile to use cross-toolchain to build it under snapcraft, and gave a armhf in the field of architecture in the snapcraft.yaml
<woodrowshen> but i found the output snap filename and package.yaml was still amd64 string. XD
<longsleep> woodrowshen: See https://github.com/ubuntu-core/snapcraft/pull/53 - it has instructions in the description how to set the output arch for snapcraft by using environment variables.
<woodrowshen> longsleep: cool! so i don't need a arm platform, right ?
<longsleep> mvo: Is travis supposed to work for snapcraft? https://travis-ci.org/ubuntu-core/snapcraft/builds/88307476 does not seem to be related to whatever i changed
<longsleep> woodrowshen: Not for packaging previously built stuff with snapcraft or for non binary stuff.
<longsleep> mvo: found the travis pr, so ignore the question :)
<mvo> longsleep: one issue with the integration tests, otherwise its looking good in the PR
<svij> I've just tried out snapcraft the first time and found a bug. Should I open a bug report or directly fix it in a PR?
<pindonga> so, I managed to successfully build both and amd64 and an armhf snap of flexget, now I'd like to create a snap that works in both architectures... what's the best way to do that right now?
<longsleep> pindonga: last time i asked that it was not easily possible - you can do it manually by some wrapper scripting similar to what webdm is doing.
<pindonga> so, basically manually combine the contents of both snaps and add a wrapper that runs the arch specific binary ?
<longsleep> pindonga: thats how webdm is doing it yes
<pindonga> ack, thx
<woodrowshen> longsleep: thank you, i think i still needs arm machine because i used plugin: make to build the grafana and there's no deb for armhf.
<longsleep> woodrowshen: yeah if you need to compile or use any other plugin than copy (or debs) then you need armhf environment
<woodrowshen> longsleep: anyway, i got lots of useful information, thanks your great help
<ogra_> ls
<ogra_> bah !
<ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ time ./rootstock-touch -s xenial -a amd64 -t ubuntu-core -m http://localhost:9999/ubuntu
<ogra_> ....
<ogra_> real	2m24.491s
<ogra_> user	1m40.186s
<ogra_> sys	0m44.196s
<ogra_> WHEE !
<sergiusens> pindonga, thanks
<pindonga> sergiusens, thank you :)
 * pindonga this > < close to finally submit a snap to the store for real
<pindonga> just need to make the snap multi arch
<sergiusens> tedg, did you find it
<sergiusens> afaik, you don't need plugins bzr fast-export --plain . | git fast-import
<zyga> sergiusens: hey, so snapcraft is no longer using bzr?
<sergiusens> zyga, don't you read email ;-)
<zyga> sergiusens: I have too much, I just hold hoping it will eventually stop ;)
<zyga> sergiusens: (still catching up after holidays)
<sergiusens> zyga, https://github.com/ubuntu-core/snapcraft
<zyga> sergiusens: yeah, I see
<zyga> sergiusens: so everything including issues is now on github?
<sergiusens> zyga, yes
<zyga> sergiusens: nice!
<zyga> sergiusens: that's a very interesting move
<sergiusens> zyga, I haven't killed the issues on lp yet as there are active conversations I don't want to destroy
<zyga> sergiusens: right
<zyga> sergiusens: oh, snappy is there too
<zyga> mmm, cool
<dholbach> sergiusens, tedg: do you know what we're going to do with daily builds and lp bugs of snapcraft after the move to github?
<sergiusens> dholbach, I alreday moved the bugs to github issues
<sergiusens> dholbach, daily builds I need to sync with mvo
<dholbach> ok, cool
<dholbach> or well "cool" :)
<dholbach> sergiusens, can we close LP bugs for snapcraft completely?
<sergiusens> dholbach, I'll be closing bugs today, but not the tracker as conversations are happening there right now
<dholbach> ok, thanks
<mvo> sergiusens: hi
<sergiusens> mvo, hello hello
<mvo> sergiusens: I can set them up for you, you will need a code import and update the daily build recipe
<sergiusens> mvo, oh, and we need to talk about other things too
<sergiusens> mvo, does it support gbp?
<mvo> sergiusens: I think it does not matter as long as there is debian/* dir
<sergiusens> oh, that works; but it needs to be bzr, right?
<mvo> sergiusens: iiirc/afaik bzr-builddeb and the bzr daily builders are different tools
<mvo> sergiusens: yes, thats why you need the code import
<sergiusens> mvo, right, it could of been a straight git code import too ;-)
<sergiusens> mvo, have we seen what stgraber is doing with lxd?
<mvo> sergiusens: its easy we do it for snappy
<tedg> sergiusens: I just pulled fast-import from LP in the plugins dir
<tedg> Worked :-)
<sergiusens> tedg, oh, by dir is possible too? nice
<sergiusens> mvo, heh, but but I wanted to remove ./debian/ from master and put it in a debian branch ;-)
<mvo> sergiusens: if you use full branches, that works as well, just make sure you import the right branch
<sergiusens> mvo, it won't be useful for daily builds though as we would have to constantly sync 'master' with 'debian'
<mvo> sergiusens: indeed
<rickspencer3> so, I am snapping frotz (for "interactive fiction")
<rickspencer3> frotz puts the save files next to the data files that it opened
<rickspencer3> so, for example, if I have ~/zork/ZORK1.DAT , it will make the save file ~/zork/game1.SAV
<rickspencer3> so, where should I put the data files in my snap so the save files work? i.e. in a readable/writable space?
<tedg> Could you put a link to the data file in the writable directory and then run it with that as the path to the data?
<rickspencer3> can you tell me more about that strategy?
<fancycode> finally got u-d-f to cross-build an armhf system image including built-in snaps on my amd64 machine :-) pull-request/proposed branch are ready for review
<tedg> So do a ln -s $SNAP_APP_PATH/zork.DAT $SNAP_APP_USER_DATA_PATH/
<tedg> Then do a frotz $SNAP_APP_USER_DATA_PATH/zork.DAT
<rickspencer3> tedg, will frotz $SNAP_APP_USER_DATA_PATH/zork.DAT work in the binaries declaration of snapcraft?
<tedg> rickspencer3: It would, but I think you'll need a shell script to do the link anyway.
<tedg> So you'll probably want a wrapper that sets things up and does an exec
<rickspencer3> ok
 * rickspencer3 tries
<mvo> jdstrand: hey, I noticed your security-cleanup branch, is there anything I can help with?
<jdstrand> mvo: not just yet. everything seems to work but I need to add a bunch of tests
<jdstrand> mvo: actually that isn't true, hw-assign needs work still
<jdstrand> anyway, it is a really good start
<mvo> jdstrand: I'm exciting if it means the hook is gone afterwards :)
<mvo> jdstrand: uh, excited of course
<jdstrand> mvo: you could answer me this: what is the *Remote* code expected to do? I've been ignoring it thus far
<mvo> jdstrand: remote code?
<jdstrand> mvo: oh yes, the hook will be gone, so will sc-filtergen (ie, no python), all the weird directories cleaned up (ie, just /var/lib/snappy/apparmor afterwords) and security-override is getting revamped to be:
<jdstrand> binaries:
<jdstrand>  - foo
<jdstrand>    apparmor:
<jdstrand>     read-paths: /path/to/something
<jdstrand> (instead of doing the weird json override)
<mvo> jdstrand: can I use the branch for testing already? for the squashfs work, the hooks will no longer work because the click manifest can not be generated because at build time the origin is unknown. so having this would make my life a lot easier (even if tests are missing :)
<jdstrand> mvo: yes, like, install remote and stuff
<jdstrand> mvo: sure, that's fine. most of the code is changed in security.go. obviusly, I had to change the other parts to use the new internal api
<mvo> jdstrand: nice, I have a look
<jdstrand> mvo: I did rip out aaClickHook, etc where I found it, but I did not remove .click or the manifest
<jdstrand> mvo: I figured I'd focus on the security bits and let others do the nail in the coffin for click compat
<mvo> jdstrand: so "install remote", I'm probably a bit slow today, but I still don't know exactly what you mean
<jdstrand> ok, let me get the function name
<mvo> jdstrand: yeah, I will create a branch based on yours and kill the rest of the click compat :)
<jdstrand> RemoteSnapPart, RemoteManifest, (s *RemoteSnapPart) Install(), etc, etc
<jdstrand> mvo: fyi, I'm going to keep the launcher json .additional file for this branch to reduce the (already massive) changes
<mvo> jdstrand: aha, ok. so thats just a snap on the server, to install it, snappy will download it and install it as a SnapPart, i.e. a normal snap
<jdstrand> mvo: I would expect someone (could be anyone) to clean that up in a separate step
<mvo> jdstrand: can I write some tests for you to get the branch landed earlier :) I'm really keen (and excited) about it, massive win for me
<jdstrand> mvo: ok, so that remote stuff I can ignore
<jdstrand> mvo: I would love help. I'm sprinting next week and low on resources in general
<mvo> jdstrand: hangout or irc so that you can give me hints what needs to be done?
<mvo> jdstrand: I will also migrate the branch to git along the way if you don't mind
<jdstrand> mvo: it isn't heavily tested. things I know need work are finishing hw-assign, making sure framework-policy updates work as expected and deal with the upgrade path
<jdstrand> mvo: re git, that's fine-- I started this right before the announcement
<jdstrand> mvo: if you focus on the tests and code reviews outside of hw-assign, I think that would be the best first step
<jdstrand> mvo: there is an additional cmd/policygen, that I expect to be used as part of a systemd unit for detecting policy updates when system policy changes
<mvo> jdstrand: ok
<jdstrand> mvo: my thoughts were: create a ssytemd unit, run something that checks if the system poicy (ie, ubuntu-core-security, apparmor, libseccomp) was changed. if so, see what snaps are affected. for those that are affected, run policygen
<jdstrand> mvo: maybe it makes sense to move cmd/policygen into 'snappy policygen'
<jdstrand> mvo: I haven't gone that far yet. if you want to think about how all that should work, that would be helpful as well
<jdstrand> mvo: or not, I know you're busy, but I figured that would be an area where the snappy core team would definitely want input
<jdstrand> mvo: but with this we solve the 'seccomp policy not updated on upgrades' card
<jdstrand> (and move apparmor to the new mechanism, since it is currently using aa-clickhook)
<jdstrand> anyway, that is probably information overload. thinking about if policygen should be its own command or in snappy is one thing to consider, and thinking about my design thoughts on upgrades is another
<mvo> jdstrand: in a meeting right now, but https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup is the imported branch if you want to continue with that
<jdstrand> ok, thanks
<jdstrand> mvo: thanks
<fgimenez> elopio, we could use build tags, take a look at http://stackoverflow.com/a/28007631
 * elopio looks.
<elopio> ah, nice!
<mvo> jdstrand: thanks, meeting is over, I updated https://github.com/mvo5/snappy/tree/from-bzr/snappy-security-cleanup with master, fixed the imports and its doing fine, I look at the missing tests you mentioned now
<jdstrand> mvo: note, the existing framework-policy updates and hw-assign tests need to be gone through and some certainly need to be reworked
<mvo> jdstrand: interessting, they don't fail right now
<jdstrand> mvo: no, because I stripped out the failing parts. hw-assign isn't done, so iirc, I just removed the failing tests expecting to add new tests
<jdstrand> mvo: framework-policy I removed the 'touch' bits since that was only relevant for touching the symlink for aa-clickhook to work
<jdstrand> mvo: but, we need to have tests making sure that policy is getting updated if framework-policy does
<mvo> jdstrand: indeed, thanks
<mvo> jdstrand: I let me know how best to coordindate, my plan is to go over the diff now and tweak if something stands out, add tests and then get back to what you wrote here and in +2h I will stop with the branch. sounds ok?
<jdstrand> you plan to write all the tests in 2 hours? wow :)
<jdstrand> sure, that sounds fine-- thanks for the help
<mvo> jdstrand: nono :) its just that I need to stop in +2h for dinner :)
<mvo> jdstrand: if I manage a single test I will consider myself lucky
<jdstrand> hehe
<longsleep> jdstrand: yesterday you told me about /{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/* - that does not seem to exist. Should i add a bug for it?
<jdstrand> longsleep: yes. against ubuntu-core-launcher
<jdstrand> longsleep: basically, it should do the same thing for that as is being dome in $HOME
<jdstrand> done*
<longsleep> jdstrand: all right
<longsleep> jdstrand: see bug #1511762
<ubottu> bug 1511762 in Snappy Launcher "/{dev,run}/shm/snaps/@{APP_PKGNAME}/@{APP_VERSION}/ folders not created" [Undecided,New] https://launchpad.net/bugs/1511762
<jdstrand> longsleep: thanks!
<elopio> Hello fancycode.
<fancycode> elopio: Hi
<elopio> heh, I had a huge lag :)
<mvo> jdstrand: quick question about findCaps() - the "template" parameter is only used to test for emptiness. is that intended?
<snappy_> ubuntu core not updating on snappy edge.  Any suggestions?
<rickspencer3> tedg, so, if I am using your method of sym linking to the app data directory, and execing the sh file ...
<rickspencer3> sorry, I mean exec'ing in the sh file
<rickspencer3> in snapcraft.yaml, do I exec the sh file?
<rickspencer3> i.e. this is in the shell script I put in bin : exec $SNAP_APP_USER_DATA_PATH/frotz $SNAP_APP_USER_DATA_PATH/
<rickspencer3> so do I define the binary like this?
<rickspencer3>  zork1:
<rickspencer3>   exec: bin/zork1
<rickspencer3> also, is there reference documentation for the allowable yaml that I could read?
<tedg> Yeah, that should work. Make sure to make the script executable.
<tedg> Let me find that doc
<jdstrand> mvo: yes
<jdstrand> mvo: if the template and caps are empty, we set caps to 'network-client'
<jdstrand> mvo: that is the only reason why template is needed
<mvo> jdstrand: aha, thanks
<tedg> rickspencer3: https://developer.ubuntu.com/en/snappy/guides/package-metadata/
<rickspencer3> thanks tedg
<jdstrand> mvo: when reviewing this, do remember that 'security-override' is revamped
<jdstrand> mvo: if you recall, before it would point to a json file that was something aa-clickhook would use
<elopio> ogra_: could you check why the latest images don't have the boot fixes by Chipaca?
<elopio> snappy_: are you getting an error?
<Chipaca> elopio: at a pinch, i'd wager it's because it was built from lp and not from github
<jdstrand> mvo: that is rather weird for a compat-less snappy, so I took the important parts out of that json and put it into the yaml directly
<mvo> jdstrand: thanks, I started with some tests and tiny refactoring and pushed to git, when you have time I would appreciate if you could fork/remerge. I will stop soon for today
<mvo> jdstrand: yeah, thats pretty nice
<elopio> ah, so we'll have the daily sync, then the daily release.
<jdstrand> mvo: that has a number of nice qualities like, you can use the default template but add a single syscall
<mvo> jdstrand: look al lvery nice, I'M super happy about this branch, thanks a lot!
<jdstrand> mvo: nice! yw
<jdstrand> it was always something I wanted to do, but alas, time
<mvo> jdstrand: :)
<mvo> jdstrand: a common problem
<mvo> jdstrand: hm, looks like I broke something, so please do not merge just yet
<snappy_> elopio: no errors.  just stuc in version 117
<elopio> snappy_: I don't have 117 and that's too old to download from the server. snappy_ please report a bug.
<mvo> jdstrand: ok, unbroke it, tests started and coverage increased etc, still work left of course, let me know if its looking ok and when you have a git repo so that I can merge from there too
<snappy_> elopio: it says updated to version 229.  and "reboot to use the new ubuntu-core" when I run update.  But it doesn't update on reboot
<elopio> snappy_: ah, you should have some information on the console. Is that kvm?
<snappy_> elopio: yes. its kvm
<elopio> snappy_: boot your machine with something like kvm -m 512 -redir :8090::80 -redir :8022::22 -snapshot /media/elopio/vms/images/snappy/ubuntu-snappy-rolling-edge-amd64-generic-214.img --serial stdio > out.log
<elopio> try to reproduce the problem, and attach the out.log to the bug report.
<snappy_> elopio: k
<snappy_> elopio: how to download current .img.xz for snappy edge?
<elopio> snappy_: I prefer to use u-d-f. Something like:
<elopio> sudo ubuntu-device-flash core rolling âchannel edge âdeveloper-mode -o ubuntu-snappy-rolling-edge-amd64-generic.img
<beuno> (amd64)ubuntu@localhost:~$ sudo snappy update
<beuno> another snappy is running, try again later
<beuno> snappy has been stuck there for a good 30 minutes
<beuno> how can I know what it's doing?
<elopio> beuno: try sudo journalctl -u snappy-autopilot.service
<elopio> on the next version, that message is improved a little.
<beuno> ah
<beuno> it answered itself while I was waiting
<beuno> snappy autopilot triggered a reboot to boot into an up to date system-- temprorarily disable the reboot by running 'sudo shutdown -c'
<beuno> The system is going down for reboot at Fri 2015-10-30 18:24:37 UTC!
<elopio> beuno: so it was just a slow download. Sounds like you are in latin america.
<beuno> elopio, gathering from the fact that I am wearing flip-flops: yes
<ogra_> is that the continent thats connected via a dialup line to europe ?
<beuno> mvo, sergiusens, Chipaca, I wonder if we could return a more information-rich message?
<beuno> ogra_, it's mostly connected by salt water
<ogra_> lol, true
<elopio> beuno: the new message says:
<elopio> The snappy autopilot is updating your system in the background. This may take some minutes. Will try again in %d seconds...
<elopio> Press ctrl-c to cancel.
<elopio> how does it sound to you?
<beuno> a lot better!
<elopio> I agree, mvo makes cool stuff.
<beuno> +1000
<tetor1> hellow everybody! I have some problem. I tried to create framework type snap named 'cURL for Snappy Core'. It's a wrapper of cURL, the users can use curl command at Snappy Ubuntu.
<tetor1> And I can create it and publish but some errors thrown at web register page. I think those problems are permission or setting file is incorrect.
<tetor1> But I have no idea to fix it.
<tetor1> I create 'ask Ubuntu' question. Can you help me, someone?
<tetor1> http://askubuntu.com/questions/690953/lint-control-architecture-valid-contents-error
<beuno> tetor, for starters, it won't be accepted in the store as a framework
<elopio> tetor: why are you making it a framework?
<elopio> tetor: framework need to be manually reviewed before putting them in the store, so you'll have to wait for somebody to take a look
<elopio> they will probably tell you that you don't need a framework to make a curl snap.
<snappy_> elopio: thx
<beuno> I can tell you already, it won't get in
<beuno> found binaries for architecture 'all': bin/curl lint_control_architecture_valid_contents
<tetor> Oh, year? I thought the cause of reject was setting file (package.yaml) was incorect.
<beuno> is because you've specified that it runs on all architectures, but it's compiled so clearly it targets specific architectures
<tetor> beuno: yes! it's error message!
<tetor> I got it. I'll write target arch e.g. x86_64 and try re publish!
<tetor> Why I'm making it is, I want to run some command in Snappy. e.g. curl tmux zsh... Without these, I can't work well.
<beuno> tetor, again, note that it won't be approved as a framework
<tetor> I have more one question. where is the reference of package.yaml?
<tetor> beuno umm.. how can I be the 'not starter'?
<ogra_> tetor, "for starters" = "first of all" ...
<ogra_> frameworks are for shared system resources that other snaps can use ... for example bluetooth
<ogra_> a single app will not be accepted as a framework
<tetor> Sorry, English is too difficult for meâ¦
<tetor> I see, I'll try to re-create cURL for Snappy as application. Many thanks all!!
<elopio> tetor: take a look at snapcraft: https://github.com/ubuntu-core/snapcraft/tree/master/examples/downloader-with-wiki-parts
<elopio> it will make things easier.
<tetor> elopio: awesome!! Thank you!
<snappy_> mir not starting on snappy 1504 edge
#snappy 2015-10-31
<liuxg> does anyone cross-compile a pyton project for ARM architecture? an example will be appreciated. thanks
<liuxg> how to compile a python project for raspberry pi https://github.com/ubuntu-core/snapcraft/tree/master/examples/py3-project
<ogra2> moo
#snappy 2015-11-01
<tasdomas> hi, I just wanted to check - does hw-assign restart the affected service?
<Chipaca> tasdomas: it should, but I think there's an open bug about it not doing so
<tasdomas> Chipaca, understood - thanks
<Chipaca> bug #1484645 in launchpad
<ubottu> bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [High,Triaged] https://launchpad.net/bugs/1484645
#snappy 2016-10-31
<rvr> ogra_: Still no wifi on the Raspi 3
<ogra_> rvr, yes, likely a kernel issue
<mup> Bug #1637981 opened: failed snap refresh removes security profiles <Snappy:New> <https://launchpad.net/bugs/1637981>
<mup> PR snapd#2231 opened: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <https://github.com/snapcore/snapd/pull/2231>
<bzoltan> elopio: I would need some help with the snapcraft tests
<zyga> Pharaoh_Atem: hey, how are you?
<Son_Goku> zyga: yo
<Son_Goku> zyga: I just pushed a commit to (theoretically) grant homedir access: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/0e2c1fb73a520b348254142347bb7f4b8445b63a
<kalikiana_> Hrm
<kalikiana_> Cannot allocate qemu:ubuntu-16.10-64: cannot launch qemu qemu:ubuntu-16.10-64: exec: "kvm": executable file not found in $PATH
<kalikiana_> Trying to run 'spread -v qemu' as suggested by HACKING.md
<kalikiana_> Tried to add a symlink in /snap but even that's not helping
<kalikiana_> It goes without saying I've installed what was asked for, and I do have a working kvm command on the host
<kalikiana_> Also: I do have the image in ~/snap/spread/23/.spread/qemu because I realized that's where spread is looking for it, even though it's not clearly stated and spread's readme actually talks about ~/.spread/qemu
<sitter> We're having some problems with dbus confinement. KDE has lots of apps that (semi-implicitly; as in: devs might not even know dbus is involved) access the session bus and claim a service name on it. For all intents and purposes these are like dbus service-daemons with a well defined service name of the form org.kde.$appname.
<sitter> This is how we implement unique application behavior (e.g. user starts foo, foo claims org.kde.foo, when foo is invoked again by whatever means it will first check if org.kde.foo is claimed and if so send a raiseWindow to that instead of starting a second instance of foo).
<sitter> This also can be the case with multiple apps registering org.kde.$appname-* where * can be $pid or $pid-$randomstuff.
<sitter> I am wondering if it would be possible to have a common interface which allows a snap to connect to the session bus and interact with a specific service name there (i.e. its own).
<sitter> I did see a bus-name property in snapd's app validator, that doesn't seem to be supported as per snapcraft's validator though.
<sitter> zyga, popey ^
<ogra_> grrr, reconnect ...
<ogra_> kalikiana_, all necessary interfaces connected ?
<kalikiana_> ogra_: I have no idea. There's 0 information on what I might need :-)
<sitter> popey: also, I just filed reservation requests for kcalc, kruler and ktuberling when you find a minute to approve them :)
<ogra_> kalikiana_, snap interfaces ... check if there are unconnected ones for the spread snap
<kalikiana_> ogra_: it has home,network,network-bind
<ogra_> well, was worth a try :)
<kalikiana_> it's also running in --devmode as per instructions, but I can't see that here
<ogra_> snap list should show that
<kalikiana_> Ah, it does indeed
<popey> sitter: will do
<kalikiana_> ogra_: So you have the same ones? I feel I might be missing some kind of magic OR the snap itself has the wrong version - although it doesn't say anything about needing an edge channel version
<Son_Goku> zyga, I wish snapd failed gracefully when it can't write files in protected places rather than hanging
<ogra_> kalikiana_, i never used spread before ...
<kalikiana_> Aha, okay.
<ogra_> seems edge and stable have th same revision though
<kalikiana_> I'd have to say I'm suspicious how it should be able to access "kvm" on my host, it'd be the first snap I see that can run anything from /usr/bin
<kalikiana_> And there's no such script inside it
<ogra_> well, --devmode should allow it to do anything it likes
<ogra_> (but spam your syslog like crazy)
<Son_Goku> zyga, does snapd use FUSE for something?
<kalikiana_> Except accessing /usr/bin - even if it was in its PATH, it will see the core's /usr/bin
<ogra_> hmm, indeed
<kalikiana_> I don't see how that could ever work
<kalikiana_> So... there must be some other trick to it
<bzoltan> ogra_:  do you know who could be around this time who has some understanding of the snapcraft tests?
<ogra_> snap-confine does some bind mount magic here ... though i'm nmot sure how much of /usr/bin
<ogra_> bzoltan, fgimenez perhaps
<bzoltan> ogra_:  thanks
<bzoltan> fgimenez:  I would need some help with the snapcraft tests. How to run individual tests?
<kalikiana_> ogra_: I can see via snap run --shell that it's got a bunch of stuff but none of the qemu or kvm bits
<kalikiana_> (awesome command to have for debugging, sadly I'm still poking in the dark)
<ogra_> kalikiana_, i fear you need to wait for niemeyer
<niemeyer> kalikiana_: If it is in --devmode, it should see the host filesystem in /var/lib/snapd/hostfs
<niemeyer> kalikiana_: We're also working on a feature that will enable you to see that in / soon
<kalikiana_> Aha that's good to know
<kalikiana_> niemeyer: Would you know anything about using spread to run snapd tests? I can't get past 'Cannot allocate qemu:ubuntu-16.04-64: cannot launch qemu qemu:ubuntu-16.04-64: exec: "kvm": executable file not found in $PATH'
<fgimenez> hey bzoltan, i don't know too much about snapcraft testing, probably elopio can explain accurately, but according to https://github.com/snapcore/snapcraft/blob/master/runtests.sh#L70 you can execute individual integration tests passing the name of the file, same goes for unit tests, hope this helps
<bzoltan> fgimenez: thanks. i will check that out
<mup> PR snapd#2232 opened: tests: add test for incorrect security files generation on undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2232>
<Son_Goku> niemeyer, does snapd have its own SSL cert loader?
<niemeyer> Son_Goku: Hi
<niemeyer> Son_Goku: What's the context?
<zyga> Son_Goku: no, but it can control fuse through an interface somehow AFAIK
<zyga> ogra_: what was the question about snap-confine?
<Son_Goku> niemeyer, I'm writing the snapd selinux policy, and I got to the point where now it throws errors instead of hanging on enforcing...
<Son_Goku> this is what I get: https://paste.fedoraproject.org/466809/47791801/
<kalikiana_> fgimenez: Any idea on the 'kvm: executable not found' error? I'm out of ideas on how to run the spread tests
<mup> PR snapd#2231 closed: overlord/ifacestate: setup profiles is its own undo task <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2231>
<Son_Goku> niemeyer, why does snapd download the /tmp instead of downloading to /var/lib/snapd/snaps?
<niemeyer> Son_Goku: Hmm.. the former issue looks like snapd cannot open the local certificate on the host system
<Son_Goku> yeah, I fixed that
<niemeyer> Son_Goku: Ah, ok.. after you asked the previous question (SSL cert loader), or was that a different question?
<Son_Goku> after I asked the SSL question, I pretty much guessed it does its own HTTPS stuff
<Son_Goku> so I added rules for it: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/3b7e03c4428f8908e1d21a22cea9a78b522694fe
<Son_Goku> niemeyer, now I want to know why snapd downloads snaps to /tmp instead of /var/lib/snapd/snaps
<Son_Goku> it doesn't make much sense to me
<niemeyer> Son_Goku: Yeah, it can talk to remote systems using TLS so it needs a proper db of certs indeed
<niemeyer> Son_Goku: Yeah, we've fixed that already
<niemeyer> Son_Goku: 2.17 will have that corrected
<Son_Goku> ah, so it doesn't do this anymore, good
<Son_Goku> because I wasn't sure how to handle the context transition case when files get moved around
<Son_Goku> from /tmp to /var/lib/snapd
<niemeyer> Son_Goku: Yeah, 2.17 will write .partial files on a download directory and then rename them in place, which is much nicer for multiple reasons
<Son_Goku> yep
<Son_Goku> and it neatly solves an selinux problem I wasn't sure how to solve
<Son_Goku> and the practical problem of systems having ramdisk /tmp run out of space
<Son_Goku> niemeyer, the download directory is in /var/lib/snapd?
<Son_Goku> as long as it's in there, I don't need to do anything to handle it
<ogra_> zyga, already answered (/var/lib/snapd/hostfs)
<zyga> ogra_: ah, thanks
<Son_Goku> zyga, why does snapd need to read the dbus config dir?
<lorenzo__> Hello
<lorenzo__> Quick question, does anyone know how to install snapd on CentOS?
<zyga> Son_Goku: it needs to read it to remove stale files it creates
<zyga> Son_Goku: in all those cases it manages a subset of "snap-*"
<niemeyer> Son_Goku: Yes, it will be in there for sure
<Son_Goku> zyga: so it needs read/write access there
<niemeyer> Son_Goku: Not sure if under .../partial or .../snaps yet.. we're likely touching this today/tomorrow for making it nicer
<Son_Goku> niemeyer, as long as it's in /var/lib/snapd, I don't care :)
<niemeyer> Son_Goku: So you're good :)
<Son_Goku> niemeyer, I'd probably suggest /partial or /snaps/partial
<Son_Goku> the latter is more intuitive
<niemeyer> Son_Goku: That's what we have in master, but it creates some non-obvious consequences
<Son_Goku> oh?
<niemeyer> Son_Goku: e.g. on "snap download foo", we want foo.snap.partial in $CWD
<niemeyer> Son_Goku: We're still figuring the details, but we want to make sure the same code path works nicely both on snapd and on snap download, etc
<Son_Goku> snap download doesn't use snapd?
<niemeyer> Son_Goku: It does, but not for everything.. we don't want plain users fiddling with content that goes into sensitive directories
<niemeyer> Son_Goku: IOW, anyone in the system can do "snap download".. only root can put content into snapd/...
<Son_Goku> niemeyer, what does snapd depend on fusedevice for?
<mhall119> sitter: I've approved your app name registrations
<bzoltan> elopio: ping
<elopio> bzoltan: pong
<bzoltan> elopio: yo man :) I need some help with snapcraft plugin/tests
<elopio> bzoltan: sure. Unit or integration?
<bzoltan> elopio:  whatever needed. I guess unit
<elopio> bzoltan: well, if you are adding a plugin you need the two types :) I first need to take a look at the ones from Pharaoh_Atem, and then I have all the time for you. How can I help you?
<elopio> pitti: ping. Any idea about "No annotated tags can describe 'cdefe0fc2dda29b4290eb4a054dbe607b61da21b'."? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-elopio-snapcraft-semaphore/xenial/amd64/s/snapcraft/20161028_194936_f7252@/log.gz
<bzoltan> elopio:  I made a simple plugin what zips up the staging space after build. This is for development use. For example when we build the qt-ubuntu content interface we will need a tar.gz with the  .h and .so files. Like -dev package in deb world.
<bzoltan> elopio:  the plugin is ready (super simple) and I want to make nice tests for it... I am not familiar with the test framework of the snapcraft.
<elopio> bzoltan: we have unit tests for full line coverage, and integration tests where you call the snapcraft command in a real snapcraft.yaml
<kalikiana_> balloons: Did you have a chance to check out the lxd-client interface?
<elopio> bzoltan: your plugin sounds really similar to dump, so you can probably start copying the initial tests from snapcraft/tests/test_plugin_dump.py
<elopio> and integration_tests/test_dump_plugin.py
<elopio> I see a naming inconsistency there :/
<ogra_> mvo, !
<mvo> hey ogra_
<ogra_> mvo, do you mind if we kill the arch: all pi3 gadget in the store (seems there was an old one that used to be arch: all, not armhf ... people can actually download it on x86 machines)
<mvo> ogra_: sure, lets do that
<bzoltan> elopio:  the problem is that the dump is done before the build... my plugin needs a built snapcraft project.
 * ogra_ goes ahead
<mvo> ogra_: aynthing new on the pi3 wifi issue? if not I will try to get pitti to have a look at it too
<ogra_> mvo, i suspect there is also a relared kernel issue here ... sadly ppisati fried his pi3 during the sprint :(
<ogra_> (and now he is on vacation)
<ogra_> mvo, but having pitti aboard might help (if there is no bank holiday for him today (reformationstag))
<ogra_> bah ... so i cant just uncheck all channels for pi3 rev2
<elopio> bzoltan: I thought your plugin would be dump + zip. Do you need it as a post-step for all the existing plugins?
<ogra_> but at least i can unpublish
<ogra_> sigh
<bzoltan> elopio: it is just a zip
<ogra_> and the store automatically went back to publish rev1 instead
 * ogra_ unpublishes that too
<ogra_> ok, thats better, only rev6 now ... and armhf only
<bzoltan> elopio:  it will look like this: http://pastebin.ubuntu.com/23407202/ and the project produces the qt-ubuntu.snap and the qt-ubuntu-api.tar.gz files
<elopio> bzoltan: to me, that sounds like a new step in the lifecycle, probably handled with a new attribute in the yaml. But Sergio and kyrofa are the ones that decide about that kind of design.
<elopio> Sergio is in a sprint. You can find him in rocket or telegram.
<bzoltan> elopio:  well... i am doing the plugin and will offer to upstream :) But my problem is that I do not understand the unit test structure
<sitter> mhall119: thanks
<elopio> bzoltan: put a simplified version of your paste into integration_tests/snaps, and in integration_tests/test_development_plugin.py write a test that calls snapcraft and checks that it creates the zip file.
<bzoltan> elopio: ok, that is the integration test part. That sounds doable. What about the unit test?
<elopio> bzoltan: on the unit tests, it really depends on the code you write. I imagine a test like this one: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_plugin_dump.py#L42 but called something like test_build_creates_zip
<bzoltan> elopio:  Okey, thanks. I will pull together something and we'll see if it does the job.
<bzoltan> elopio:  my problem with the  unit test is that I do not know how to create a stage space from a template yaml
<bzoltan> elopio:  the integration test you suggest will do the trick...
<elopio> but I'm confused about your code. I'm not really sure how you would enforce that there are contentes in stage, or how to make sure that it's the last to run.
<elopio> bzoltan: but if you want, push the code to a PR, and comment on it that's work in progress. It will make the discussion easier.
<elopio> bzoltan: in unit tests, you don't always need a yaml. You just mkdir stage, and put some files in there.
<bzoltan> elopio: ahh... mkdir and file creation... cool
<balloons> kalikiana_, is the interface ready?
<balloons> kalikiana_, I can definitely try it out if it's ready
<kalikiana_> balloons: It's in the branch, https://github.com/snapcore/snapd/pull/2225
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<balloons> kalikiana_, awesome. I've got release work to do today and tomorrow, but I will definitely try it this week. If you want to vet it out yourself, feel free to try adding it to juju and building a snap: https://github.com/juju/juju/blob/staging/snapcraft.yaml
<sitter> mhall119: something that puzzles me about the store. I upload something -> it gets auto rejected on account of being crap quality -> I upload a new revision with fix -> new revision is now queued for automatic checks saying "Revision waiting for review of a previous upload." and that previous upload is in status "Manual review pending". is that intentional?
<sitter> because that is fairly screwing with my productivity just now :/
<mhall119> nessita: ^^ can you answer that? It sounds like a bug in the workflow to me
<kalikiana_> stgraber, jdstrand: wrt lxd-client being all-powerful, is that a shortcoming in apparmor/seccomp? or the lxd API being unrestricted?
<kalikiana_> Wondering where to take that discussion, presuming the current unconfined state is temporary
<stgraber> kalikiana_: nothing to do with apparmor/seccomp limitations, it's just that LXD has legitimate use for all of that access
<stgraber> kalikiana_: the LXD API lets you define containers that have raw access to disks, PCI devices, USB devices, specific kernel modules and intefrace, ...
<stgraber> and things like Juju actually use that to pass through access to openvswitch for OpenStack or even /dev/mem in some cases
<stgraber> kalikiana_: we may at some point add the concept of tenants to LXD and could then in theory have security profiles or something to restrict what those tenants can pass to containers and then build a snapd interface on top of that to allow for auto-connect to lxd. But that's not on our roadmap for this cycle nor even for the next one, so right now, the LXD API is very much privileged and can't be given to
<stgraber> any random user/snap.
<Sweet5hark> "cannot bind mount nvidia driver /usr/lib/nvidia-340 -> /tmp/snap.rootfs_OKbiYH/var/lib/snapd/lib/gl. errmsg: No such file or directory" <- anyone has an idea what that is?
<ogra_> Sweet5hark, some leftover nvidia driver cruft ?
<ogra_> does /usr/lib/nvidia-340 exist and does it have the GL libs inside ?
<Sweet5hark> ogra_: yes and yes
<ogra_> any other nvidia-* dirs in /usr/lib ?
<Sweet5hark> FWIW, /tmp/snap.rootfs_OKbiYH/ exists, is owned by root:bjoern and is empty -- the paths below it do not exist.
<Sweet5hark> Also for context: I tried to install libreoffice from edge, aborted the dl, which FUBARed snap state. Thus I ran https://raw.githubusercontent.com/zyga/devtools/master/reset-state -- retried, it installed fine, but doesnt start because of the above ....
<Sweet5hark> ogra_: There is nvidia-340 and nvidia-340-prime in /usr/lib
<ogra_> the message comes from inside the core snap, i dont think you can see anything when looking from the outside
<ogra_> probably it chokes on -prime ...
<ogra_> zyga, ^^ any known remaining bugs with snap-confine and nvidia ?
<kyrofa> Isn't the core snap supposed to handle GL access?
<kyrofa> ogra_, do you know anything about that? I have an app dying because it can't access libGL.so.1
<ogra_> nop
<ogra_> e
<ogra_> it isnt so much the core snap, rather snap-confine that bind mounts the libGL stuff from the host into the core snap and provides the gl interface
<cwayne> kyrofa: ISTR having to  have something like this in my wrapper script: export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/$ARCH/dri
<kyrofa> Huh... I just ran `snap run --shell` and it's not in there anywhere, so it must not be bind-mounted in. zyga, any ideas?
<kyrofa> Oh my. I completely missed that opengl was an interface now
<kyrofa> I'm sure that's it
<kyrofa> Nope, nevermind. Changes nothing
<kyrofa> Looking at the interface, looks like something should be contained within /var/lib/snapd/lib/gl, but it's not
<ogra_> kyrofa, well, snap-confine should mount your hosts GL libs there
<kyrofa> ogra_, yeah, that doesn't seem to be working
<ogra_> (on demand i think)
<kyrofa> Man it's quiet around here
<femme> Did a snappy security audit happen (yet)?
<femme> We're considering using snaps for tor as distros tend to not update after a while and so I just joined to get caught up on the snap ongoings and discussions and maybe someone would like to help
<qengho> femme: Hi hi. I can't answer about an audit, but I would like to be a bridge between Tor and snappy communities. I think it's a great fit. I made the tor-middle-relay snap, and am on the OFTC channel too.
<qengho> femme: I would love to contribute what I know to make snaps a side-effect of building the official builds for deb packages.
<femme> qengho: great, I didn't know there was a middle relay snap
 * qengho moves to that dev channel.
<kyrofa> femme, I'll point you to the security team -> tyhicks?
<kyrofa> femme, qengho please let me know if you run into difficulties from a packaging perspective
<tyhicks> femme: hey - there's not been an independent security audit of snappy as a whole but the Ubuntu security team is active in the development of snappy
<tyhicks> femme: for example, we review all that changes that go into the snap launcher (snap-confine) and we also review and/or author the changes to the interfaces (security policy)
<zyga> tyhicks, femme: suse security team did review snappy security
<zyga> and found a few issues that were since fixed
<zyga> you can count that as indepdentend security review i think
<tyhicks> oh, good point
<zyga> kyrofa: it's been a long day :)
<tyhicks> I had forgotten about that
<kyrofa> zyga, yeah I bet! How's the sprint?
<zyga> kyrofa: hey, so wha'ts about nvidia that you have issues with?
<zyga> kyrofa: and which distro are we talking about as each one is different
<kyrofa> zyga, I've got an app that wants libGL.so.1, and it's not finding it. Neither am I, using snap run --shell
<zyga> kyrofa: sprint is tense :) we're working on the release again
<kyrofa> zyga, classic
<zyga> libGL.so.1 you say?
<kyrofa> Yep
<femme> tyhicks: thanks for the response, so I'm having a glance and the parts wiki page jumps out at me. It seems more complicated than it has to be when a (signed) repo would have been better.
<femme> zyga: great to hear
<zyga> kyrofa: do you see it in /usr/lib/nvidia-/ anywhere?
<femme> would love to read a writeup if there was one
<zyga> femme: signed repo of what?
<femme> https://wiki.ubuntu.com/snapcraft/parts
<kyrofa> zyga, indeed, both /usr/lib/nvidia-340/libGL.so.1 and /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
<zyga> femme: you do relise the whole idea is that that we don't review actual code, just the sandbox
<kyrofa> femme, those are just build-time parts for users to utilize when building snaps. It has nothing to do with snapd itself
<zyga> kyrofa: the latter is not something we handle, the former, hmm, is this a hybrid system?
<femme> I know
<zyga> kyrofa: can you do snap-confine --version by any chance (or just tell me the version from dpkg)
<kyrofa> zyga, yes, it's one of those monstrosities. Never do it!
<zyga> s/relise/realise/
<kyrofa> zyga, 1.0.43-0ubuntu1~16.04.1
<zyga> kyrofa: is it a hybrid system?
<kyrofa> zyga, yes
<zyga> kyrofa: if it is, then what you may be observing is that a) we have a bug (maybe) b) nvidia driver is not really loaded yet
<kyrofa> zyga, indeed, the nvidia driver isn't loaded
<zyga> kyrofa: please collect as much data as you can and report a new bug
<kyrofa> zyga, well, I'm using the intel side
<zyga> kyrofa: for hybrid systmes I bet we need more smarts
<kyrofa> zyga, but I shouldn't HAVE to be using nvidia...
<femme> I realize it's not directly snapd related but it's a single point of failure for those using the parts, which seems to be recommended
<kyrofa> femme, no need to use them, they just help sometimes when snapping things
<zyga> kyrofa: I agree, I just need data to know how to fix it
<kyrofa> zyga, sounds good, happy to help
<zyga> femme: snaps should be okay to use even if you use none of the shared parts
<kyrofa> Even the shared parts get confined the same if used
<zyga> kyrofa: look at /sys/module/nvidia/version
<zyga> kyrofa: do you have it?
<zyga> kyrofa: and if so, what's in it?
<kyrofa> zyga, it seems I don't have it when using intel
<zyga> kyrofa: right, then what I think is happening is that the app expects a particular GL.so but the snap is not providing it
<zyga> kyrofa: typically snaps seem to bundle all FOSS userspace side drivers
<nacc> femme: i think what you're referring to is that if the shared parts were to change/break in some way, there's not really a way to fix it in your current build; but that only matters for building a new version, the existing snaps don't depend on the parts any longer (the shared parts were integrated during the build, aiui)
<zyga> kyrofa: maybe that's just missing
<femme> With the whole Startcom thing and whoever else has access to SSL CA certs I wouldn't want to wait until something goes wrong to say "you could have not used it"
<kyrofa> nacc, you understand correctly
<nacc> kyrofa: thanks
<zyga> kyrofa: I need to sleep, please report a new bug and let's work together on solving this
<femme> nacc: yes, which makes the developer a target
<zyga> kyrofa: I'm so sleepy now, sorry
<kyrofa> zyga, yeah, go away, I'm sorry I pinged you, I forgot about the sprint ;)
<zyga> kyrofa: no worries, it' the (wink wink) last one this year
<kyrofa> zyga, ha!
<zyga> (conditions apply, your mileage may vary)
<nacc> femme: depends on how you mean that -- the developer is expressing a dependency by relying on the external code (which is really what the shared part is); so yes, the developer is a 'target' if that external code breaks
<kyrofa> femme, that's an argument against any dependencies
<femme> It's an argument against not checking the integrity of dependencies, aka relying on https as your only line of defense
<nacc> femme: so are you arguing purely against how the shared parts are currently distributed?
<femme> if the developer's connection is mitm'ed by someone who can issue valid wiki.ubuntu.com ssl certs they can put whatever they want on that parts page
<femme> and it gets built into the binary and distributed to everyone
<kyrofa> femme, if an attacker has that power I feel like that's the least of the dev's worries
<zyga> femme: isn't that true in general
<zyga> femme: your ubuntu.iso was fetched over https
<zyga> femme: and we can do better but at some point you have to have some way to bootstrap trust
<femme> kyrofa: that's a step above what the ubuntu security team said when I told them years ago that they should have ssl certs on ubuntu.com but they closed the ticket as WONTFIX
<zyga> femme: remember that when this happes, the most you can exploit is what that single snap could do
<femme> but hey, they turned around on that too, only took them a few years.
<kyrofa> femme, even if we could integrity check the contents of the wiki, it's just a dict pointing elsewhere. The code comes from github etc
<nacc> iirc, the ubuntu isos are actually served over http; the md5sums are served over https. We just had this argument a few days ago on #ubuntu. :)
<kyrofa> femme, if an attacker can impersonate https-protected websites they can just impersonate that one
<femme> kyrofa: that would've been the next point, there should be some signing mechanism implemented
<nacc> if all https sites are compromised (potentially), it does feel like there is a large issue at hand
<kyrofa> nacc, exactly
<femme> if all https sites are compromised I'm fine because I'm using tor
<kyrofa> femme, how do you check a svn repo? Or git?
<femme> A few measures I would take are: 1) enable and test key pinning with wiki.ubuntu.com's key in snapd 2) have every snap developer keep a key with which they sign the tar of the sources and include the md5 of it in the yaml
<femme> s/md5/sha256/
<kyrofa> femme, they aren't necessarily tarballs, that's my point
<femme> kyrofa: they can be tarred on the developers machine
<kyrofa> femme, how are they verified then if the build recipe itself pulls from git?
<femme> https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Securing_Updates
<femme> kyrofa: they are made by ubuntu they can just be signed by a key already trusted
<kyrofa> What are made by ubuntu? How is the signature of the tarball verified if the tarball isn't downloaded?
<femme> if the tarball isn't downloaded what is the dev planning on building the sources with?
<kyrofa> femme, git cloned sources. Or svn. Or hg. Or any of the myriad of source types supported by snapcraft
<femme> kyrofa: which can be tarred?
<femme> the tarring bit is just a technicality
<kyrofa> femme, so your recommendation is to get rid of all source types except tarballs?
<femme> no
<femme> I'm kinda done with this conversation for now
<femme> I'll gladly write a report if someone pays me ;)
<mup> PR snapd#2233 opened: docs: update the name of the command for the cross-build <Created by elopio> <https://github.com/snapcore/snapd/pull/2233>
<kyrofa> Alright, have a nice day femme
<femme> (speaking of keys already trusted by ubuntu, it's kinda scary with two keys from 2004 still there)
<femme> kyrofa: the idea is that the sha256 of every source is included (and if it's not a single file, tar them and sha256) and that it's signed by the developers private key (the public part which is also included)
<femme> It could be implemented for parts which was my main example but I don't know much about the key infrastructure of ubuntu and if it would make sense to suggest for example pinning the key for parts in snapd alongside the pinning of the ssl cert of the URL, because if both keys are kept at the same place it doesn't matter but otherwise it is an improvement
<femme> And it would use trust-on-first-use on a per snap basis for other keys
#snappy 2016-11-01
<mup> PR snapd#2234 opened: static tests: add spell check <Created by elopio> <https://github.com/snapcore/snapd/pull/2234>
<liuxg> elopio, ping
<mup> PR snapcraft#879 opened: The latest icon definition is deprecated <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/879>
<liuxg> I have a .gz file, what should be the source-type to use when I download it in the snapcraft.yaml. I have tried to use zip, bit it does not succeed. thanks
<mup> PR snapd#2233 closed: docs: update the name of the command for the cross-build <Created by elopio> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2233>
<pitti> ogra_: no holiday, but being stuck in cloud roadmap review sessions all day, laptop-less :) (yesterday)
<pitti> elopio: I didn't see this before, no; did you try this locally? sounds like your way of checking out a github (?) PR doesn't work
<mup> PR snapd#2235 opened: debian: wrap-and-sort <Created by zyga> <https://github.com/snapcore/snapd/pull/2235>
<mup> PR snapd#2228 closed: interfaces/bulitin: allow fwupdmgr refresh on fwupd plug <Critical> <Created by timchen119> <Closed by timchen119> <https://github.com/snapcore/snapd/pull/2228>
<mup> PR snapd#2236 opened: interfaces: add realsense interface <Created by swem> <https://github.com/snapcore/snapd/pull/2236>
<mup> PR snapcraft#877 closed: Add new "source-commit" field for VCS sources <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/877>
<Son_Goku> for the life of me, I can't figure out where the man page is generated from when running snap help --man
<Son_Goku> niemeyer: ^
<niemeyer> Son_Goku: It's generated from the flag metadata in the code itself
<Son_Goku> niemeyer, it says the man page is snap(1) rather than snap(8)
<Son_Goku> I just want to fix that
<Son_Goku> or have it fixed
<Son_Goku> either way works
<niemeyer> Ah, let me see where the code lives
<Son_Goku> I tried diving into it yesterday and got lost in the wave of golang things ;)
<Son_Goku> niemeyer, it's been a section 8 manpage for a while, but apparently the man page generation code still writes snap(1)
<niemeyer> Son_Goku: Will be slightly trickier than it sounds: https://github.com/jessevdk/go-flags/blob/master/man.go#L179
<Son_Goku> eek
<niemeyer> Son_Goku: Might be easier to patch it locally, if you want a quick fix
<faenil> hi everyone. I was having a look at snapcraft.io homepage, I saw this line "A snap can declare daemons to be started as well, this one just describes some apps.
<Son_Goku> yeah, I think I'm just going to patch the man page itself until that's figured out
<faenil> but I'm not sure what that means. "This one?"
<faenil> does it refer to the example above?
<Son_Goku> but since Debian, Ubuntu, and Fedora install it per the reference debian packaging data (as section 8), the man page is obviously wrong here
<niemeyer> Son_Goku: Both snap and dpkg are (1) in Ubuntu/Debian
<faenil> (maybe it needs some rephrasing?)
<niemeyer> (FWIW)
<Son_Goku> snap is in section 8
<Son_Goku> niemeyer: https://github.com/snapcore/snapd/blob/master/debian/rules#L157
<Son_Goku> someone changed it a while back
<niemeyer> Son_Goku: $ dpkg -L snapd | grep 'man[0-9]/snap'
<niemeyer> /usr/share/man/man1/snap.1.gz
<Son_Goku> wtf?
<Son_Goku> but... https://github.com/snapcore/snapd/commit/d1bd21632f3bca781bb64cb6a62e099f7978658d
<Son_Goku> I'm completely confused now
<niemeyer> Son_Goku: We need to kill the debian/ directory really
<Son_Goku> alright, I'll fix it in the spec for now
<Son_Goku> I think does belong in 8, though
<niemeyer> It's super confusing indeed.. basically it can be out of date with the actual packaging rules in use in Debian and/or Ubuntu
<niemeyer> Son_Goku: Not any more than dpkg itself
<Son_Goku> rpm and yum/dnf are in section 8
<Son_Goku> I'm not sure why dpkg isn't
<niemeyer> Son_Goku: I think it's reasonable
<niemeyer> Son_Goku: Users care about what is installed too
<Son_Goku> apt is in section 8 as well
<Son_Goku> as is aptitude and... synaptic?!
<Son_Goku> synaptic has a man page...?
<niemeyer> Son_Goku: But I won't bikeshed much on this one.. it's just a number really
<Son_Goku> yeah, meh
<Son_Goku> I'll just fix it to point to 1 for now
<niemeyer> and a pretty irrelevant one at that
<Son_Goku> I don't actually care, but the inconsistency annoyed me
<niemeyer> Yeah
<niemeyer> Having it in one is the easiest, given it's hardcoded in go-flags
<Son_Goku> that's a weird and terrible thing to be hardcoded
<Son_Goku> but whatever
<mup> PR snapd#2235 closed: debian: wrap-and-sort <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2235>
<Son_Goku> zyga: ping
<Son_Goku> zyga: https://github.com/zyga/snapcore-fedora/pull/11
<mup> PR zyga/snapcore-fedora#11: Update SELinux subpackage commit and move snap.8 to snap.1 <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/11>
<Son_Goku> I'm at the point where I don't want to keep hitting it with a hammer anymore
<Son_Goku> the policy *should work* once niemeyer lands the change to stop downloading things into /tmp and download them in /var/lib/snapd/<foodir>
<Son_Goku> for the curious, here's what the policy looks like now: https://gitlab.com/Conan_Kudo/snapcore-selinux/blob/master/snappy.te
<Son_Goku> it could stand to have some cleanup, but I don't want to do that now
<Son_Goku> zyga, please merge the pull request and then update the snapd review with it
<Son_Goku> I want to approve it already... :/
<Son_Goku> that way the preset rules can make it into Fedora asap
<Son_Goku> niemeyer, has the code landed for making it download in /var/lib/snapd/<foodir> yet?
<niemeyer> Son_Goku: Not yet.. hopefully today
<Son_Goku> cool
<tptr> hi all, I tried to install http://cdimage.ubuntu.com/ubuntu-snappy/16.04/20160919/ubuntu-core-16-amd64.img.xz on an Intel compute stick (STK1A32SC). It gets stuck when booting, saying 'grep: /proc/device-tree/model: No such file or directory' and later "findfs: unable to resolve 'LABEL=writeable'"
<tptr> booting ubuntu-15.04-snappy-amd64-generic.img.xz goes fine on the same hardware.
<tptr> I am wondering if it is known prob or should I report somewhere?
<ogra_> tptr, that is from a USB key ?
<ogra_> (or how do you boot ?)
<tptr> well, I boot a normal 16.04 on the stick from a USB key. then download this image, unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz | sudo dd of=/dev/mmcwhatever bs=32M
<mup> Bug #1638248 opened: No 'current' symlink for $SNAP_USER_DATA <Snappy:New> <https://launchpad.net/bugs/1638248>
<tptr> then it starts booting OK but then gets stuck at the above mentioned point. Unfortnately keyboard does not work either so cannot interact with it...
<tptr> ( tre instructions from https://developer.ubuntu.com/en/snappy/start/#try-x86 )
<ogra_> tptr, if you dd directly to the USB key and boot from there, does it work ?
<ogra_> oh, wait
<ogra_> you downloaded 15.04 ...
<tptr> this is what I do
<tptr> with 15.04 it works fine
<tptr> with 16.04/20160919/ubuntu-core-16-amd64.img.xz it gets stuk
<ogra_> well, 15.04 is pretty much EOL (within the next 4 weeks or so) ...
<ogra_> and completely different too (regarding the overall image design)
<tptr> yes...
<tptr> this is why I would love to switch to 16.04 as soon as I can
<tptr> but I cannot boot it on this device. due to this problem.
<ogra_> well, try booting from the USB key
<ogra_> oh, wait ... you also downloaded the wrong image
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ is waht you want
<tptr> aaah ok. I will give this a try. thanks a bunch.
<zyga> slangasek: can we release snap-confine 1.0.44 into ubuntu?
<zyga> slangasek: there's some SRU work that needs to happen for that
<zyga> slangasek: https://bugs.launchpad.net/snap-confine/+milestone/1.0.44
<Son_Goku> zyga, can you please update the snapd review with the latest SRPM and spec
<sree> hai
<sree> i want to know about ubuntu mobile os
<sree> can you help me
<Son_Goku> sree, you should probably ask in #ubuntu
<sree> okay
<Son_Goku> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825
<Son_Goku> zbyszek is waiting on my to approve the package so he can merge the presets in
<Son_Goku> s/my/me/
<Son_Goku> zyga, technically, the selinux policy as-is isn't going to completely work with snapd 2.16
<Son_Goku> because of it downloading to /tmp instead of /var/lib/snapd
<Son_Goku> but niemeyer says that change will land today, so you can backport it before making a build in koji and submitting it as an update
<femme> snapd is vulnerable to all of these currently, in some form: https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html
<Son_Goku> erm
<niemeyer> femme: No, none of them, actually
<Son_Goku> it shouldn't be
<Son_Goku> the connection is secured between snapd and the Canonical store
<Son_Goku> and the data is document signed and checksummed
<Son_Goku> femme, the major Linux distributions today provide mechanisms to defeat those particular attacks
<femme> the 'parts' are not signed or checked for integrity any way - it's just a wiki page and it will download and execute whatever is on that page
<niemeyer> femme: snapcraft is not snapd
<femme> ok, my mistake then, snapcraft
<Son_Goku> snapcraft has its own issues, sure
<niemeyer> femme: This page is about apt and yum, not their build infrastructure
<Son_Goku> it's also horribly out of date for apt and yum too
<femme> niemeyer: doesn't matter
<Son_Goku> both package managers have solved these issues a long time ago
<femme> it's a research paper and they only solved the issues because of it...
<niemeyer> femme: Of course it matters.
<femme> niemeyer: how?
<femme> I humored this channel enough with the pedantic questions yesterday, I hope today won't be a repeat because I won't be coming back
<niemeyer> femme: This page is entirely about APT and YUM, and discuss issues related to package management and not how these packages are build
<niemeyer> built
<Son_Goku> the way packages are built has a different set of issues
<niemeyer> femme: If you want to raise issues with snapcraft, that's fine.. but that's completely unrelated to snapd and do the page you pointed out
<niemeyer> femme: So, sort of fundamental to the point
<femme> niemeyer: it's about dependency management
<Son_Goku> snap build infrastructure is quite weak, sure, but that's not necessarily the same as the snap runtime/install infrastructure
<femme> So you're missing a fundamental point
<niemeyer> femme: Exactly, and snapcraft is not about package management dependency
<femme> niemeyer: then why does it include that functionality?
<niemeyer> femme: This is the *build* system
<Son_Goku> femme, snaps cannot do direct dependencies
<niemeyer> femme: The tone of the conversation is also very unfriendly.. unnecessarily unfriendly
<Son_Goku> they can indirect, capability oriented dependencies
<Son_Goku> much coarser than package deps
<niemeyer> femme: I appreciate the point you are trying to make, though.. it's just a bit misguided
<femme> No, I think you either don't understand or you don't care if snapcraft users are targeted.
<niemeyer> femme: You are very strongly making the wrong point, instead of kindly making the right one.
<Son_Goku> femme, I agree that what you're saying is a problem
<Son_Goku> but the issue is, the person you should be talking to isn't even here right now
<femme> Son_Goku: I'll probably never talk to them thanks to people like niemeyer
 * Son_Goku sighs
<mup> PR snapd#2237 opened: bugfix: use a .partial file in download to unbreak `snap download` as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2237>
<femme> Just keep up with the pedantics, it's a build system as if it doesn't do dependency resolution in a vulnerable way
<Son_Goku> that went well </sarcasm>
<mhall119> is there a way to prompt the user for input during the installation of a snap? couchdb needs to setup an admin username and password when you install it
<dholbach> can somebody reply to http://askubuntu.com/questions/842792/unable-to-install-ubuntu-snap-in-16-04-lts?
<niemeyer> Yes, security is pedantic femme.
<jdstrand> kalikiana_: re lxd clients-- it is is limitation of lxd. if you can connect to the lxd socket, you can trivially escape confinement. this is not unlike docker or libvirt (not quite as trivial, but scriptable)
<niemeyer> I've followed up up privately.
<zyga> Son_Goku: yes, I'll do it shortly
<jdstrand> kalikiana_: aiui, they have todos to improve that, I think using acls
<zyga> Son_Goku: understood
<jdstrand> hey niemeyer and zyga :)
<jdstrand> kalikiana_: ah, I see stgraber already anwswered you
<mhall119> zyga: niemeyer: do we have documentation somewhere about the configuration hook and how to use it?
<niemeyer> mhall119: I'm working on that.. will finish as soon as the holy image is out.
<zyga> jdstrand: hey
<mhall119> thanks niemeyer, I think that will solve couchdb's needs
<femme> <    niemeyer> | We know about the *actual* underlying issue, and the fix is planned. <    niemeyer> | I was merely pointing out that this is unrelated to snapd, and to the page you linked saying "snapd is vulnerable to all of those" <    niemeyer> | Your attitude makes it very hard to even start a conversation, though  <    niemeyer> | Yes, I am pedantic. Security is pedantic, very.
<femme> Yeah, *my attitude* is the problem. It's not like I immediately said I was mistaken and in fact meant snapcraft, right?
<mhall119> niemeyer: are there any security restrictions on who can call "snap set"?
<femme> But I'm the one that made it hard to start a conversation, sure.
<niemeyer> mhall119: Yeah, root only for now.
<mhall119> cool
<niemeyer> mhall119: Sorry, more clearly: auth-only for now
<niemeyer> mhall119: As in, works through the API
<mhall119> so, same auth requirement as was needed to install it in the first place?
<zyga> jdstrand: is everything okay?
<niemeyer> femme: the issue of it being a wiki page is being sorted out as we speak.. it was obviously a cheap way to start, and a visible one, which was handy for a while
<niemeyer> femme: There will be an actual server handling those things, with proper auth, etc
<femme> niemeyer: you could have just said that instead of repeating over and over that they weren't talking about build systems but you instead chose to ignore everything I was saying and when I left to tell me that I was the problem.
<jdstrand> zyga: yes, I got back and just wanted to say 'hi' :)
<zyga> jdstrand: ah, great to have you back :)
<jdstrand> thanks! :)
<femme> the 'fundamental point' you were talking about, was one you were and still are missing
<niemeyer> femme: That's what I've been trying to do. Sorry if I failed at that.
<mhall119> femme: niemeyer: we're all just trying to get stuff done, there's nothing personal about it, it's just code.
<Son_Goku> zyga, I think mvo's PR here is the one that fixes this: https://github.com/snapcore/snapd/pull/2237
<mup> PR snapd#2237: bugfix: use a .partial file in download to unbreak `snap download` as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2237>
<femme> I don't like being talked over by people that think they know more than you.
<mhall119> give each other the benefit of the doubt, text doesn't lend itself to expression very well, and sometimes we don't come across the way we meant to
<mhall119> femme: niemeyer just wants to help people use snaps, he wants to help you too. I'm positive he wasn't trying to talk over you
<zyga> Son_Goku: he's sitting right besides me, I'll update the SRPM when the branch lands
<Son_Goku> zyga, did you go ahead and make the SRPM and spec update to the bugzilla ticket, though?
<Son_Goku> I'd like to go ahead and give it my stamp of approval
<femme> Great, I came here because at the tor project we were considering snaps but this has only left a bad taste in my mouth.
<zyga> Son_Goku: ah, ok, I'll do that now
<zyga> Son_Goku: thank you for all the contributions, this is fantastic milestone!
<mhall119> zyga: Son_Goku: is this the contribution I think it is?
<zyga> femme: tor can use snaps, you don't have to use the parts wiki
<zyga> mhall119: yes
<mhall119> \o/
<Son_Goku> mhall119, yes, it is :D
<mhall119> Son_Goku: you're going to blog about it somewhere, right? right?
<Son_Goku> mhall119, yes, yes
<zyga> mhall119: I think many people will :)
<Son_Goku> as soon as I have a working version of snapd in the repos, yes
 * mhall119 prepares the share/like/+1 button
<niemeyer> femme: you don't even have to use snapcraft, strictly speaking
<zyga> femme: you can very precisely build a snap manually, controlling all the bits
<zyga> femme: and publish gpg signatures and anything else you want for cross-checks
<niemeyer> femme: Again, I'm sorry if it sounded like I was trying to "talk over you" or offend in any other way. The point above is exactly what I was trying to convey, and failed apparently.
<femme> We need reproducible builds so I think that's the only way we can go about it.
<zyga> femme: and you can
<zyga> femme: snap is a fancy zip file
<zyga> femme: just build the content
<Son_Goku> ehhh
<Son_Goku> it's not *quite* that
<mhall119> a fancy squashfs file
<mhall119> :)
<mup> PR snapd#2238 opened: many: fix download as user with nice partial filename <Created by mvo5> <https://github.com/snapcore/snapd/pull/2238>
<niemeyer> femme: This should give you ideas: https://github.com/snapcore/snapd/tree/master/tests/lib/snapbuild
<qengho> Incidentally, I have a branch of snapcraft that (almost) takes a  source-signed-by: [ 0xGPG, 0xGPG ]  argument in snapcraft yaml parts.
<niemeyer> femme: It takes the final content of a snap and simply bundleds it into the .snap file
<niemeyer> bundles
<qengho> I haven't published because GPG is kind of dumb, take ALL instead of ANY OF in its verification step.
<Son_Goku> and I've written an independent snap build implementation for core snaps
<Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
<Son_Goku> it wouldn't take much for me to be able to do snapcraft-like things
<niemeyer> femme: These are all snaps we use on the test suite, that we "build" with it: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps
<niemeyer> femme: It doesn't actually build anything, though.. it merely packs it up
<mhall119> niemeyer: are there any plans for an install-time hook?
<niemeyer> femme: As an interesting property of the system in this context, the snap is never modified.. the digest of whatever is built on your machine is the digest that lands on the users machine
<mhall119> it would be useful to bootstrap stuff in $SNAP_DATA or $SNAP_COMMON
<niemeyer> femme: And there are two signatures on it, one by the store, one by the snap publisher
<niemeyer> mhall119: configure!
<mhall119> niemeyer: does that get called at install time? Or only when a user calls snap set?
<niemeyer> mhall119: It's called at install time
<niemeyer> mhall119: and on every refresh
<Son_Goku> zyga, my VM is a complete mess now :)
<mhall119> oh, perfect! Are docs coming for that soon too?
<niemeyer> mhall119: Wait, I need to confirm the second part of it
<niemeyer> mhall119: Definitely at install time
<mhall119> that's the main one for me
<niemeyer> mhall119: Yeah, it's part of that doc wiki
<zyga> Son_Goku: build in progress
<zyga> Son_Goku: /var/tmp/rpm-tmp.XLkaC3: line 62: /home/zyga/rpmbuild/BUILDROOT/snapd-2.16-1.fc24.x86_64/usr/share/man/man1/snap.1: No such file or directory
<Son_Goku> uhh
<femme> niemeyer: enabling HPKP on wiki.ubuntu.com and snapcraft would go a long way
<Son_Goku> you messed up
<niemeyer> femme: We'll drop that entirely, and have a proper database for that content, with proper authentication, etc
<Son_Goku> or rather I did
<Son_Goku> zyga: https://github.com/zyga/snapcore-fedora/blob/master/snapd.spec#L172
<Son_Goku> that needs to be man1
<zyga> Son_Goku: right
<zyga> Son_Goku: fixing, thanks
<Son_Goku> np
<niemeyer> femme: But if you'd like to start sooner, I'd suggest going the snapbuild route.. it's really not that big of a jump. Once we've nailed down these snapcraft edges, should be trivial to move back
<niemeyer> femme: We should also have a --no-remote sort of flag
<niemeyer> femme: Which forces snapcraft to operate only on local parts
<niemeyer> I'll talk to Sergio about this
<niemeyer> serguisens is our snapcraft master
<Son_Goku> niemeyer, that would be handy for integration of snapcraft into something like Koji
<Son_Goku> or OBS
<zyga> Son_Goku: uploaded
<Son_Goku> you've uploaded a new SRPM and spec to your fedorapeople space and linked it in the bug?
 * Son_Goku doesn't see it...
<zyga> Son_Goku: bug updated
<zyga> Son_Goku: really?
<zyga> Son_Goku: yes, both
<Son_Goku> https://fedorapeople.org/~zyga/snapd.spec
<Son_Goku> shows me snapd 2.12
<mup> PR snapd#2238 closed: many: fix download as user with nice partial filename <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2238>
<Son_Goku> and nothing here https://bugzilla.redhat.com/show_bug.cgi?id=1367825
<zyga> oh, sorry wrong directory
<zyga> and bug was updated separately now
<zyga> Son_Goku: check now please
<Son_Goku> there we go
 * zyga hugs Son_Goku  :)
<tptr> @orga I have just tried with  http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ but I got the same. dd image to intel stick. it starts booting then gets stuck at Running /scripts/local-premount ... grep: /proc/device-tree/model: No such file or directory
<nothal> tptr: No such command!
<tptr> @ogra_ :-)
<nothal> tptr: No such command!
<zyga> Son_Goku: ok, we just need that patch and we're good
<ogra_> tptr, thats a red herring (i just rolled a new kernel snap that suppresses that warning)
<Son_Goku> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c23
<ogra_> tptr, it shouldnt influence your boot process though ...
<zyga> Son_Goku: going to create the package now
<Son_Goku> :D
<ogra_> tptr, did you try booting directky from usb stick ?
<tptr> next line: findfs: unable to resolve 'LABEL=writable'
<ogra_> right, thats the issue ... but also not the cause
<ogra_> you said something about mmc
<ogra_> i assume the missing mmc/SD card driver in the initrd is your issue
<Son_Goku> zyga, so far, this was the worst part: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/6331fd4a058271b0246714bc6746ab1e7ce2aa09 :(
<ogra_> try booting off USB, if that actually worksd we know for sure
<zyga> Son_Goku: should I ask for epel as well?
<zyga> Son_Goku: nice, I need to learn this better
<mup> PR snapd#2239 opened:  snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2239>
<Son_Goku> zyga, let's not bother with EPEL for now
<zyga> Son_Goku: ok
<Son_Goku> but I think it'd be a good idea to start testing epel builds with COPR
<Son_Goku> I think that EL7 may not require the SELinux policy module right now
<zyga> Son_Goku: package requested
<zyga> Son_Goku: good idea
<tptr> yes, so my steps are: 1) I boot a normal ubuntu desktop 16.04 on the stick 2) download and then unxz -c ubuntu-core-16-amd64-rc2.img.xz | sudo dd of=/dev/mmcblk0 3) sync 4) reboot. -> boot starts OK then gets stuck at this point.
<ogra_> tptr, right, dd to the USB key instead and boot off the os thats on theer, see if that works, then we have proof that it is the missing mmc driver
<Mirv> mvo on hols?
<zyga> Son_Goku: after this lands we can finish snapd-glib
<tptr> ok I do that now. thx
<zyga> Son_Goku: should be a low hanging fruit by now
<Son_Goku> zyga, you can start it now, technically
<Son_Goku> snapd-glib has no direct dep on snapd
<zyga> Son_Goku: ok, I'll start that then
<Son_Goku> at build time
<Son_Goku> snapd and snapd-glib can be submitted to bodhi in the same update along with updated snap-confine (if a new one arrives)
<zyga> Son_Goku: .44 is good for now I think
<zyga> Son_Goku: I'll do .45 without patches and then we fuse them into snapd
<zyga> Son_Goku: (probably)
<Son_Goku> blech
<zyga> Son_Goku: some updates for snapd-glib, I'll finish this in the evening as I'd like to test it from python
<Son_Goku> okay, cool
<zyga> Son_Goku: what's about blech?
<Son_Goku> merging snap-confine into snapd
<zyga> Son_Goku: you'll thank me after 3 releases where it's just painless :)
<Son_Goku> mixing golang and other things, by definition, is not painless
<zyga> Son_Goku: we'll make the packaging work, then updates are painless, and so is development
<zyga> Son_Goku: especailly for things like selinux integration, one branch, one CI, one result
<Son_Goku> travis sucks, though :/
<zyga> Son_Goku: spread!
<zyga> :-)
<Son_Goku> mugh
<Son_Goku> ugh
<Son_Goku> that means figuring out lxd
<zyga> Son_Goku: don't worry about it, I'll make it work brilliantly
<zyga> Son_Goku: not really, you can use qemu or linode and linode will run fedora CI
<Son_Goku> unfortunately, no one has packaged lxd in Fedora :/
<Son_Goku> so local spread things with containers don't work
<zyga> Son_Goku: I think initilly kvm will be much much better
<Son_Goku> we have libvirt/KVM and systemd-nspawn
<Son_Goku> and of course, lxc 2.0 itself
<Son_Goku> and rkt too
<Son_Goku> and of course docker
<Son_Goku> but, bleh on docker
<Mirv> was store updated already to accept content interface users with the content property defined?
<tptr> ogra_: bingo, intel compute stick is booting ubuntu-core-16-amd64-rc2.img.xz fine from the USB stick.
<zyga> Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1390616
<elopio> ogra_: ping. Have you measured the boot time with cloud-init lately?
<ogra_> tptr, ok, i'm spinning new daily images, i'll ping you once they are ready (30min or so) they should have the fix
<ogra_> elopio, i didnt really care for cloud-init since we disabled it by default
<tptr> ah, great, thx
<elopio> ogra_: can you help me to make a gadget snap that enables cloudinit for rpi2? I
<elopio> I'm going to look for the sources. It might be obvious.
<ogra_> elopio, i have not the slightest clue how the cloud.cfg needs to look like
<ogra_> the gadget side is easy though, iirc you just need to include it in the toplevel dir of the gadget
<ogra_> but i dont know anything about the format
<ogra_> (with the requirement for a special gadget, i actually doubt that people will use cloud-init on realy hardware ... i.e. non-cloud images)
<ogra_> *real
<elopio> thanks ogra_. I'll look for somebody who knows about it. I think this is for cloud people.
<elopio> I mean, it's coming from the people attending the cloud sprint.
<ogra_> ah
<ogra_> well, mvo might know something about the cloud.cfg file
<ogra_> but he isnt on irc
<ogra_> (not sure if he took off the week, i see commits from him on github :P )
<elopio> ogra_: yes, I'm talking to him on telegram and passing the messages through to you :)
<ogra_> lol
<ogra_> is he to shy for irc ? :)
<elopio> ogra_: irc doesn't have gifs, it's doomed :p
<elopio> ogra_: hey you might like this one: https://github.com/matrix-org/synapse/pull/1158
<mup> PR matrix-org/synapse#1158: Add the packaging metadata to build the synapse snap <Created by elopio> <https://github.com/matrix-org/synapse/pull/1158>
<elopio> peer to peer, encrypted, with a bridge to irc.
<ogra_> elopio, lol ... that name reminds me of https://en.wikipedia.org/wiki/Antitrust_(film)
<ogra_> nice one though
<elopio> that sounds like a terrible film... so I'll watch it during lunch.
<ogra_> elopio, dude ! you dont know it ? it is the movie where gnome made its first appearnce ever in a movie :)
<ogra_> tptr, try the amd64 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<tptr> ok
<ogra_> that should have all needed drivers included now
<elopio> rharper: can you help me generating an image with cloud-init for rpi2?
<Croepha> is there a standard way to include the contents of the linux-firmware debian package in your kernel snap?
<mup> PR snapd#2240 opened: interfaces: network-manager: give slot full read-write access to /runâ¦ <Created by morphis> <https://github.com/snapcore/snapd/pull/2240>
<Croepha> will stage-packages actually just work?
<kyrofa> elopio, great film! You'll love it!
<elopio> kyrofa: we'll see.
<kyrofa> elopio, let us know
<Croepha> the only reason I ask, is because every time i make a change to the kernel snapcraft.yaml, it takes like 30 minutes to build the snap...
<Pharaoh_Atem> zyga: grabbed the review and left a comment already
<Pharaoh_Atem> also requested comaintainership for snapd in pkgdb: https://admin.fedoraproject.org/pkgdb/package/rpms/snapd/
<tptr> ogra_: intel stick is booting your image ok from the internal mmc. yey. :-)
<tptr> thanks a lot for the help
<mup> PR snapcraft#880 opened: Remove license concepts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/880>
<ogra_> tptr, thanks for verifying the fix ;)
<mup> PR snapcraft#881 opened: Catkin plugin: Python nodes require gcc/g++ too <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/881>
<mup> Bug #1638320 opened: remove core snap via snapweb fails but it still removes from the web interface <Snappy:New> <https://launchpad.net/bugs/1638320>
<Pharaoh_Atem> zyga: snapd-glib approved
<zyga> Pharaoh_Atem: thanks, I'll do the rest :)
<mup> PR snapd#2240 closed: interfaces: network-manager: give slot full read-write access to /runâ¦ <Created by morphis> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2240>
<mup> PR snapcraft#788 closed: support npm install from npm-shrinkwrap.json in nodejs plugin <Created by mvayngrib> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/788>
<Croepha> tptr: is your intel compute stick working with wifi/hdmi audio/ and direct rendering?
<Croepha> i was using the linuxium sources to get those features, had to roll my own kernel
<tptr> I am using it only for some IoT usecase. no graphics... model is STK1A32SC
<tptr> just struggling to make docker available to my own snap somehow...
<tptr> previously I used it with 15.04 snappy image. there wifi was working fine too.
<tptr> so far all looks good with the 16.04 too... using the above image from ogra_
<thresh> hi.  how do I go about the autotools-based project where I need to build something before launching actual configure/make/makeinstall?
<Pharaoh_Atem> zyga: there's no point in submitted snapd-glib yet
<Pharaoh_Atem> you don't have snapd with it
<Pharaoh_Atem> it's completely useless without it
<kyrofa> thresh, you mean you need to run a command before configure?
<thresh> kyrofa, exactly, yeah.
<thresh> and the command is not autoreconf :)
<kyrofa> thresh, you'll need to create a plugin within your project for snapcraft to use
<kyrofa> thresh, are you familiar with that at all?
<zyga> Pharaoh_Atem: nobody can download and test it
<zyga> Pharaoh_Atem: we'll get snapd in in a few hours
<zyga> Pharaoh_Atem: did you try running any snaps?
<Pharaoh_Atem> once built in koji, people can do that
<zyga> Pharaoh_Atem: with some workaround for /tmp?
<zyga> Pharaoh_Atem: ook
<thresh> kyrofa, I'm not.  I'm actually trying to make VLC (http://git.videolan.org/?p=vlc.git;a=tree;f=extras/package/snap) use the contribs (self-built deps) instead of Ubuntu ones, which are outdated (only Zesty seems to have needed ffmpeg).
<Pharaoh_Atem> I can write a temporary patch to add support for read/write /tmp in the selinux policy
<thresh> kyrofa, any tips on how to do that?  Appreciate it.
<zyga> Pharaoh_Atem: please do
<zyga> Pharaoh_Atem: let's check that it works
<zyga> Pharaoh_Atem: and undo it later tonight
<kyrofa> thresh, of course, let me grab some docs for you
<kyrofa> thresh, here's a high-level example: https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md
<zyga> Pharaoh_Atem: so the package in mater is good, we'd have to rev the policy and later on rev both when it's ready
<kyrofa> thresh, yours might look a little more similar to this one: https://github.com/nextcloud/nextcloud-snap/blob/master/parts/plugins/x-redis.py
<kyrofa> thresh, that one needed to run `make install PREFIX=` instead of `make install DESTDIR=` (the make plugin now supports this, but it didn't at the time)
<kyrofa> thresh, so you can almost copy this, inherit from the autotools plugin, and run the commands you need
<thresh> kyrofa, right, seems easy!  Thanks!
<kyrofa> thresh, any time :)
<kyrofa> Let me know if you run into problems
<mup> Bug #1638334 opened: snap install not properly generating ConnectedSlot policy when auto-connecting via snap-declaration-allowed connection <Snappy:New> <https://launchpad.net/bugs/1638334>
<Pharaoh_Atem> zyga: I've added a patch for it
<Pharaoh_Atem> you can go ahead and build for all targets and merge it into the update that includes snap-confine and snapd-glib
<zyga> Pharaoh_Atem: I don't know how to merge updates in bodhi
<Pharaoh_Atem> it's super easy
<zyga> Pharaoh_Atem: did you test it in any way? any hello snaps running?
<Pharaoh_Atem> I have not, as I'm at work and it's tricky for me to do that
<sborovkov> Hello. Anyone knows how I can trigger first boot again on classic? We are creating image from classic, need it to repartition free space when users use the resulting image
<zyga> Pharaoh_Atem: ok, Ill check
<Pharaoh_Atem> cool
<zyga> Pharaoh_Atem: FYI: https://github.com/zyga/snapcore-fedora/issues/4
<zyga> Pharaoh_Atem: I think we need to try it on a cloud variant too
<zyga> Pharaoh_Atem: but we can do  that after trying workstating
<zyga> workstation*
<zyga> Pharaoh_Atem: thank you again :) building now
<Pharaoh_Atem> I know what's wrong with the cloud thing
<Pharaoh_Atem> mismatched kernel packages
<zyga> Pharaoh_Atem: can we somehow fix that?
<zyga> Pharaoh_Atem: something we can improve in fedora?
<Pharaoh_Atem> not really, people just need to make sure they install kernel-modules matching their kernel, or get things upgraded properly
<zyga> Pharaoh_Atem: or in the dependencies in snapd.spec?
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> the kernel package is multiversioned
<zyga> Pharaoh_Atem: well, we install kernel-modules via a dependency
<zyga> Pharaoh_Atem: hmm hmm hmm
<Pharaoh_Atem> there has been talk of making a DNF plugin to handle this by providing additional, environment specific hints
<zyga> Pharaoh_Atem: ok, at least you've identified the issue correctly, thanks
<Pharaoh_Atem> see this thread (relevant in our case as well): http://lists.rpm.org/pipermail/rpm-ecosystem/2016-October/000430.html
<zyga> looking
<thresh> kyrofa, looks like I got it working, many thanks!
<kyrofa> thresh, excellent!
<zyga> Pharaoh_Atem: maybe those should be snaps? :)
<Pharaoh_Atem> ugh
<Pharaoh_Atem> when snapcraft and snapd are properly decoupled from Ubuntu so that a Fedora-built Snappy Core could be done, we'll talk then
<zyga> Pharaoh_Atem: very soon I hope :)
<zyga> Pharaoh_Atem: one more thing
<zyga> Pharaoh_Atem: lis 01 19:08:45 fedora24 setroubleshoot[51485]: SELinux is preventing snapd from execute access on the file unsquashfs. For complete SELinux messages. run sealert -l 116eed8f-b15a-4a60-9532-3268ba616497
<Pharaoh_Atem> mrgh
<Pharaoh_Atem> I thought I got all of those
<zyga> Pharaoh_Atem: but it download now
<zyga> Pharaoh_Atem: we're so so close now
<Pharaoh_Atem> I'm revoking your bodhi updates
<zyga> Pharaoh_Atem: OK
<zyga> Pharaoh_Atem: is that something we can fix quickly today?
<Pharaoh_Atem> yes, but I need to set up a fresh VM
<Pharaoh_Atem> I have to add more rules... :/
<AlbertA> question: if I declare a package through stage-packages is there a way to only include a subset of files from that package?
<Pharaoh_Atem> purge the files afterward?
<AlbertA> for example I've tried this: http://pastebin.ubuntu.com/23412484/
<zyga> Pharaoh_Atem: purge?
<zyga> Pharaoh_Atem: ah, sorry :)
<AlbertA> but I get "[Errno 2] No such file or directory: '/home/alberto/source/mir-demos-snap/stage/usr/share/doc-base'" during priming
<AlbertA> Pharaoh_Atem: purge? how though?
<sborovkov> Hello. Anyone knows how I can trigger first boot again on classic? We are creating image from classic, need it to repartition free space when users flash the resulting image.
<ogra_> sborovkov, thats not in firstboot but inside the special core initrd (you need to resize before anything gets mounted if you dont want to risk corruption)
<ogra_> you wont get it on classic
<mup> PR snapd#2241 opened: overlord/state: introduce state lanes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2241>
<ogra_> (without hacking your own resize initrd together)
<mup> PR snapd#2242 opened: tests: do not use hello-world in our tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2242>
<pmcgowan> ogra_, if my dragonboard is rebooting itself that means I got a new kernel?
<sborovkov> ogra_: oh ok, that's unfortunate
<mup> PR snapcraft#882 opened: Python plugin: remove pip packages when cleaning pull <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/882>
<kyrofa> pmcgowan, either a new kernel or a new core
<pmcgowan> kyrofa, ack thanks
<mterry> How do I unpack a snap, so I can quick edit and repack it?
<mterry> I thought it used to be a command under 'snap', but don't see it any longer
<kyrofa> mterry, you mean snap try?
<kyrofa> mterry, it doesn't quite do that, but it allows you to edit it while mounted rather than going all the way to creating the squashfs
<mup> PR snapd#2227 closed: overlord/snapstate: add dynamic snapdX.Y assumes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2227>
<mup> PR snapd#2232 closed: many: fix incorrect security files generation on undo <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2232>
<mup> PR snapcraft#882 closed: Python plugin: remove pip packages when cleaning pull <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/882>
<ogra_> pmcgowan, snap changes (and snap change $changenumber) will tell you ;)
<mup> PR snapd#2243 opened: overlord/ifacestate: add unit tests for undo of setup-snap-security <Created by zyga> <https://github.com/snapcore/snapd/pull/2243>
<pmcgowan> ogra_, I see it  Update kernel and core snap revisions
<ogra_> well, then it eventually reboots :)
<ogra_> the changes should have timestamps so you can see if they match the reboot
<pmcgowan> yeah it says it requested it
<Pharaoh_Atem> mhall119 & zyga: the presets have been merged into fedora-release for f24, f25, and rawhide/f26
<Pharaoh_Atem> Fedora 25 final will be the first release of Fedora where the installation of snapd will automatically activate the socket
<Pharaoh_Atem> so that "snap install" will Just Work(TM)
<zyga> Pharaoh_Atem: :-)
<Pharaoh_Atem> and snap install hello threw no denials related to the policy :)
<mup> PR snapd#2239 closed:  snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2239>
<mup> PR snapd#2229 closed: interfaces/sytemd: enable/disable generated service units <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2229>
<mup> PR snapd#2244 opened: snapstae: use lanes when building a "refresh-many" change <Created by mvo5> <https://github.com/snapcore/snapd/pull/2244>
<mup> PR snapd#2224 closed: overlord/snapstate: update ux around explicit refresh of reverted, anâ¦ <Critical> <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2224>
<mup> PR snapcraft#883 opened: python plugin: wheel and install in the proper order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/883>
<mup> PR snapd#2241 closed: overlord/state: introduce state lanes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2241>
<mup> PR snapd#2245 opened: overlord/state: marshaling tests for lanes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2245>
<mup> PR snapd#2244 closed: snapstate: use lanes when building a "refresh-many" change <Critical> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2244>
<zyga> Pharaoh_Atem: around?
<mup> Bug #1638405 opened: libunity not added to LD_LIBRARY_PATH <Snappy:New> <https://launchpad.net/bugs/1638405>
<mup> PR snapd#2245 closed: overlord/state: marshaling tests for lanes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2245>
<mup> Bug #1638405 changed: libunity not added to LD_LIBRARY_PATH <Snapcraft:New> <Snappy:Invalid> <https://launchpad.net/bugs/1638405>
<mup> PR snapd#2213 closed: tests: skip tests that use expect when expect is not working (like on ppc64el) <Critical> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2213>
 * mwhudson wonders if the snapd autopkgtest just needs some zesty upload to ppa:snappy-dev/image
<mup> PR snapd#2237 closed: daemon,overlord,snap,tests: download to .partial in final dir <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2237>
<mup> PR snapd#2243 closed: overlord/ifacestate: add unit tests for undo of setup-snap-security <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2243>
<mup> PR snapd#2246 opened: releasing package snapd version 2.17 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2246>
#snappy 2016-11-02
<mup> Bug #1638425 opened: The documentation to install snapd in archlinux doesn't mention that the socket needs to be started <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1638425>
<mup> PR snapd#2247 opened: interfaces/builtin/mir: allow client access to /dev/shm/ <Created by albaguirre> <https://github.com/snapcore/snapd/pull/2247>
<mup> PR snapcraft#883 closed: python plugin: wheel and install in the proper order <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/883>
<mup> PR snapd#2248 opened: tests: make refresh-undo wait a bit for the output of the restarted v1 service <Created by mvo5> <https://github.com/snapcore/snapd/pull/2248>
<Mirv> nessita: hi! I'm getting 404 on my " To accept this share, please visit:" link in e-mail I got thanks to upload by mvo for me
<foxmask> bonjello
<thed46> im new ...i mean right now new, to ubuntu im lost
<mup> PR snapd#2208 closed: store: add support to resume partial downloads <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2208>
<dholbach> hey hey
<Mirv> nessita: seems like case sensitive e-mail address detection
<Mirv> nessita: got now with lower case e-mail address. the next problem is that the new store with support for 'content' field is not there, any ETA on deployment? it was reportedly fixed in master already during the sprint.
<morphis_> pitti: ping
<mup> PR snapd#2249 opened: store: use range requests if we have a local file already <Created by mvo5> <https://github.com/snapcore/snapd/pull/2249>
<mvo> ogra_: hi, I noticed there is a new rev 24 of the dragonboard gadget. do we need this for stable? it got little testing so far
<mvo> ogra_: its only in edge
<mvo> ogra_: same for pc-kernel, do we need the one in edge?
<morphis_> mvo, ogra_: do you guys have any insight on why networkd stores its DHCP lease inside /run where they are lost on next device boot?
<mvo> morphis_: pitti will probably know
<mup> Bug #1638511 opened: Can't install snap in LXD container <Snappy:New> <https://launchpad.net/bugs/1638511>
<mup> PR snapcraft#872 closed: Add some further bash-completion <Created by cwayne18> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/872>
<bzoltan> elopio: https://github.com/snapcore/snapcraft/pull/884
<mup> PR snapcraft#884: Implement API packaging plugin as requested in #1638508 <Created by bzoltan1> <https://github.com/snapcore/snapcraft/pull/884>
<mup> PR snapcraft#884 opened: Implement API packaging plugin as requested in #1638508 <Created by bzoltan1> <https://github.com/snapcore/snapcraft/pull/884>
<morphis_> mvo: yeah
<ogra_> mvo, yes to both
<ogra_> mvo, pc-kernel adds the mmc modules to the initrd (needed by NUC)
<mvo> ogra_: ok
<ogra_> mvo, dragonbvoard just adds a tty0 console arg so all arm images are consistent
<Subhash> can anyone guide me how to change library path after prime stage in snapcraft snap process. Thanks in advance
<femme> what is the current ubuntu core release?
<Son_Goku> zyga, systemd mounts support setting an SELinux context
<zyga> Son_Goku: how can we do this?
<zyga> Son_Goku: what should be in the unit
<zyga> Son_Goku: I'll make that happen
<zyga> Son_Goku: (good morning)
<zyga> Son_Goku: (long night)
<Son_Goku> under the [Mount] section
<Son_Goku> add 'Options=context="system_u:object_r:snappy_var_lib_t:s0"'
<zyga> Son_Goku: trying
<Son_Goku> it's essentially a mount option
<Son_Goku> with the mount command, this is done as the following command
<Son_Goku> mount -o context="system_u:object_r:snappy_var_lib_t:s0"
<Son_Goku> that overrides/enforces a default label
<zyga> Son_Goku: just fiddling, should have a patch in a sec
<Son_Goku> It'd probably be better if systemd had a specific SELinuxContext for mounts, but it doesn't :/
<Son_Goku> something for your systemd guys to add, maybe
<zyga> Son_Goku: ok, I just pushed something to f24
<zyga> Son_Goku: tell me if that what's you expected
<zyga> Son_Goku: didn't build it yet
<zyga> Son_Goku: can you update f24 to have the right commit ID for the polcy?
<zyga> Son_Goku: I just want to be in sync with you
<Son_Goku> yes, give me a sec
<mup> PR snapd#2250 opened: Range requests but no snap logging <Created by chipaca> <https://github.com/snapcore/snapd/pull/2250>
<Son_Goku> zyga, also, what creates the ~/snap directory?
<zyga> Son_Goku: snap
<zyga> Son_Goku: cmd/snap
<zyga> Son_Goku: the snap run command specifically
<zyga> Son_Goku: snap confine tries as well but by now snap run already did it
<Son_Goku> policy commit updated
<zyga> Son_Goku: I fixed the patch
<rvr> ogra_: Still no wifi in the raspi 3 image
<ogra_> rvr, i just had it working for the first time ... but i went afk for like 10min before pressing enter and i had a cable plugged in to eth when i booted
<mup> PR snapd#2251 opened: interface hooks: snapctl get-attr and set-attr (phase 3) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2251>
<ogra_> (disabling eth0 and configuring wlan0 worked fine then) ...
<ogra_> might be that the system is under high load on boot
<zyga> t
<zyga> Son_Goku: trying, fingers crossed :)
<Son_Goku> :)
<zyga> Son_Goku: lis 02 12:57:47 fedora24 audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { reload } for auid=n/a uid=0 gid=0 cmdline="systemctl daemon-reload" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system
<zyga> Son_Goku: we just need this I think
<mup> Bug #1638524 opened: /etc/modprobe.d adds one to much directory level <Snappy:New> <https://launchpad.net/bugs/1638524>
<Son_Goku> can you do the ausearch thing to give me the .te file lines?
<zyga> Son_Goku: the thingh is, I don't get the denial this time
<Son_Goku> that's because it was a soft-fail
<zyga> Son_Goku: it's not like I get the usual selinux thing there
<zyga> ah
<Son_Goku> or perhaps, do you not have setroubleshoot-server installed
<zyga> sealarm -b shows nothing
<Son_Goku> one of the two
<zyga> I do have it
<zyga> it's just not triggering
<zyga> it must be something that's specified by the policy as, not undefined by the policy (just a hunch)
<zyga> (as denial)
<zyga> do you have any ideas where that might be?
 * Son_Goku shrugs
<Son_Goku> we're really in the weeds now
<zyga> Son_Goku: I think the weeds (for hello-world) are shallow,
<zyga> I'm trying to grok what might be going on now
<zyga> Son_Goku: could that be a dbus request for systmed to reload?
<Son_Goku> maybe?
<Son_Goku> selinux covers that too...
<zyga> jdstrand: does this ring any bells vvvv
<Son_Goku> contexts apply to literally everything
<zyga> lis 02 12:57:47 fedora24 audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { reload } for auid=n/a uid=0 gid=0 cmdline="systemctl daemon-reload" scontext=system_u:system_r:snappy_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system
<zyga> Son_Goku: we should ask on selinux channel (maybe you already did)
<Son_Goku> I don't know why you're not there :P
<Son_Goku> and no, I haven't yet
<Son_Goku> I'm still trying to work out why the homedir transition isn't occurring automatically
<Son_Goku> zyga, you *really* should be in #selinux
<Son_Goku> I'm getting asked questions I don't know the answers to
<mup> Bug #1638529 opened: Auto-connect is not working for connection between network-manager and modem-manager <Snappy:New> <https://launchpad.net/bugs/1638529>
<samplejava> hi there guyts
<samplejava> i'm just trying to snap a java application
<samplejava> i have the -jar file and i want to create a snap package but i am unable to properly install java along with the package
<samplejava> my snapcraft.yaml looks like this:
<samplejava> http://hastebin.com/bofiwuviyu.sql
<samplejava> the app is just a window poping up a hello world message
<didrocks> samplejava: hey! I would try using the jdk plugin from snapcraft. This one will do the correct things to stage a local jvm that could be used by your jars
<samplejava> hmmm
<samplejava> so adding it as a part?
<didrocks> (also, I think you did notice that you had a typo in default-jdk stage-package)
<didrocks> samplejava: one part with plugin: jdk instead of copy
<didrocks> and use stage/snap keyword to copy the files you need
<didrocks> if you are using maven build system, you can also look at using this plugin
<popey> jdstrand: bug 1598309 (your comment #4) is affecting me. I have a snap which barfs accessing /dev/snd/seq. Is there anything I can do other than use --devmode?
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1598309>
<samplejava> in fact it is only an old .jar file which used to work but my users always complain about needing to install jdk on fedora, ubuntu, and so on
<samplejava> if i can manage this for them...
<samplejava> noticed the typo, but the error remains...
<samplejava> Something like this: /snap/jsignpdf/x8/command-jsignpdf.wrapper: 7: exec: java: not found
<didrocks> samplejava: yeah, that's because you didn't export JAVA_HOME and such
<didrocks> which is what this plugin is doing
<didrocks> if you look at the jdk plugin, it's just creating a small wrapper with simple env variables
<didrocks> pointing up JAVA_HOME and PATH to your local jre/jdk install
<didrocks> you can do this as well
<didrocks> samplejava: this is what the plugin is doing: http://paste.ubuntu.com/23415767/
<samplejava> oh
<didrocks> the root variable is $SNAP in your snap environment
<samplejava> i will have to review the docs
<samplejava> because i bet that i am not understanding
<didrocks> your java is local to your snap
<didrocks> so you need to override some variables to point to it
<didrocks> that's what the plugin is doing for you
<didrocks> (here, the jdk plugin)
<samplejava> okey, so you mean modifying my plugin from plugin: copy to plugin:jdk would do the trick
<samplejava> or ill need to add a new part
<didrocks> correct, just modigyin your plugin to plugin:jdk
<didrocks> then, you need to use "stage" and "snap" keywords to ship your files
<samplejava> stage and snap
<samplejava> okey ill try
<didrocks> yeah, that's the part you should look into the doc :)
<didrocks> http://snapcraft.io/docs/build-snaps/syntax could be a good start
<samplejava> got  it
<samplejava> http://snapcraft.io/docs/build-snaps/parts
<samplejava> ;)
<didrocks> also ;)
<samplejava> you were faster
<didrocks> heh
<didrocks> good luck, do not hesitate if you have any blocker!
<samplejava> hope not
<samplejava> i love the philosophy
<samplejava> thinking about deploying elasticsearch and so on similarly
<samplejava> looks great really
<Son_Goku> zyga, I've bumped the policy again, this time hopefully fixing the homedir issue
<Son_Goku> I'm going to take a little break on this
<Son_Goku> if you find issues, file them on the GitLab project
<Son_Goku> zyga: https://gitlab.com/Conan_Kudo/snapcore-selinux/issues
<zyga> re
<zyga> Son_Goku: thank you
<Son_Goku> zyga, also, if you need help deciphering SELinux issues, #selinux is a good place to be
<jdstrand> popey: as of today, you need to use devmode. I've added a card to implement it, but it is prioritized behind other cards. you (or someone else) could create a PR for 'alsa' if you don't want to wait
<samplejava> im sorry didrocks
<samplejava> don't see the difference between stage and snap
<samplejava> i have defined a fileset called binaries which includes all the -jar files in my folder (- blabla/*)
<didrocks> samplejava: stage is for the stage step (what's ending up in the stage/ directory), snap is for the prime/snap stages (in the prime/ directory). See http://snapcraft.io/docs/reference/snapcraft
<didrocks> samplejava: if you don't know what to put, it's probably because you need both (refering to the same fileset)
 * didrocks goes for a run, will be back later
<jdstrand> zyga: I don't, no. tyhicks may have an idea, but I suspect Son_Goku is right about #selinux
<Son_Goku> zyga & jdstrand: also this can be helpful: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/
<Son_Goku> just for understanding the concepts and stuff
<zyga> tyhicks: do you think we can get someone with selinux brains to help us bootstrap snapd confinement (not interfaces)?
<zyga> tyhicks: to the point where snapd itself is confined and runs correctly on f24+
<femme> zyga: I was thinking about something related, snap support in subgraph os which uses a system sandbox called oz
<zyga> femme: if you are interested in expanding and improving security subsystems in snappy then we have space where you can do that
<zyga> femme: the code is very modular already
<zyga> femme: and it's designed for runtime choice and can easily support many things
<popey> jdstrand: ok, thanks.
<mup> Bug #1638537 opened: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0c <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537>
<kalikiana_> jdstrand: Hey. I'm making the changes suggested in https://github.com/snapcore/snapd/pull/2225 but I gather I'm not fully clear, as now I'm seeing 'snap "ubuntu-core" has no slot named "lxd"' after I changed the declaration and removed it from builtins
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<kalikiana_> Updating the tests atm which may or may not yield some hints
<mup> Bug #1638558 opened: interface to register and talk to well defined name on dbus session bus <Snappy:New> <https://launchpad.net/bugs/1638558>
<mup> Bug #1638524 changed: /etc/modprobe.d adds one to much directory level <Snappy:Fix Released> <ubuntu-core-config (Ubuntu):Fix Released> <https://launchpad.net/bugs/1638524>
<bzoltan> elopio:  are you sprinting too?
<tyhicks> zyga: hey - who did you have in mind for that?
<mup> PR snapd#2252 opened: interfaces: add unconfined access to modem-manager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2252>
<tsdgeos> any idea what's wrong in here? http://paste.ubuntu.com/23416363/
<jdstrand> Chipaca: hey, do you know who I should talk to about testsuite failures when running run-checks locally? http://paste.ubuntu.com/23416405/
 * Chipaca looks
<jdstrand> Chipaca: these failures have been around for a while now
<Chipaca> jdstrand: I don't see those; how're you running things?
<Chipaca> jdstrand: you can talk to me for example :-D
<jdstrand> Chipaca: I just do ./run-checks
<Chipaca> jdstrand: in what environment?
<jdstrand> Chipaca: now, my environment is that I have the lxd snap installed, then created a container for snapd developement
<Chipaca> jdstrand: on what branch?
<Chipaca> ah
<jdstrand> it is every branch, but I'm trying master now
<Chipaca> jdstrand: so the next question is what version of snapd and core and lxd you're on :-D
<jdstrand> yes, same thing on master
<jdstrand> snapd 2.16ubuntu3. ubuntu-core 423, core 6, lxd 241 (2.5)
<jdstrand> snap-confine 1.0.43-0ubuntu1~16.04.1 (if you need that)
<jdstrand> Chipaca: fyi, same error if using a system container or setting TMPDIR=~/tmp
<Chipaca> jdstrand: ubuntu-core *and* core?
<jdstrand> well, yes
<Chipaca> jdstrand: you've been having fun!
<jdstrand> I installed core cause I was excited to use it, then I couldn't remove either
<Chipaca> jdstrand: you should be able to remove the one you're not using
<Chipaca> jdstrand: but that might depend on which one you're using
<jdstrand> Chipaca: I'd love to get rid of ubuntu-core. how will I know that it isn't being used?
<Chipaca> jdstrand: you could try "snap disable ubuntu-core; snap remove ubuntu-core"
<jdstrand> ah
<jdstrand> disable first
<jdstrand> that did it
<Chipaca> jdstrand: that's exploiting a bug to fix a different bug, but yes :-D
<jdstrand> nice! :)
<Chipaca> jdstrand: what does snap --version say?
<jdstrand> $ snap --version
<jdstrand> snap    2.16ubuntu3
<jdstrand> snapd   2.16ubuntu3
<jdstrand> series  16
<jdstrand> ubuntu  16.04
<jdstrand> ok, with just core installed and disabling then re-enabling lxd to restart everything, same issue
<jdstrand> Chipaca: shall I install snapd 2.17 from the ppa?
<Chipaca> jdstrand: that would be helpful, but only if you don't mind then being stuck on it
<jdstrand> it's fine
<jdstrand> Chipaca: I have to step away for a little bit. I'll try snapd 2.17 and circle back
<kalikiana_> Hey jdstrand. After making the changes you suggested in https://github.com/snapcore/snapd/pull/2225 I'm seeing 'snap "ubuntu-core" has no slot named "lxd"' when doing 'snap connect', I'm guessing removing it from builtins I might have to add it somewhere else?
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225>
<mup> PR snapcraft#885 opened: Release changelog for 2.21 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/885>
<bschaefer> hello, i have a snap that depends on different packages depending on architecture. Is there a way to specify architecture for packages, or optional packages?
<bschaefer> or do i need a snap per different architecture?
<abeato> does anybody know how to generate core files in ubuntu core?
<zyga> tyhicks: hey
<zyga> tyhicks: sorry for the lag
<zyga> tyhicks: I was thinking if there's anyone we can tap into to help us finish selinux in fedora for snapd
<zyga> tyhicks: not for interfaces, just for snapd itself
<tyhicks> zyga: I don't know of anyone that has the skills and the spare cycles to work on that
<zyga> tyhicks: do you know anyone with the skills that we can maybe try to get cycles?
<tyhicks> zyga: on the ubuntu security team?
<zyga> anyone?
<tyhicks> not these days
<tyhicks> I haven't been around the selinux policy community for at least 5 years
<ratliff> zyga: it might be possible to hire a consulting firm like Quark Security to help out with selinux policy
<ratliff> alternately, it might be possible to rope in some graduate students if some grant money were to be offered
<ratliff> Trent Jaeger did some analysis of the reference policy back in the day and is now a professor at Penn State - he might be able to come up with a grad student and define a mutually beneficial project
<jdstrand> kalikiana_: sorry, I stepped away. right, so, if the interface isn't implicit and supplied by the core snap, then an app snap needs to supply the slot implementation for the interface
<jdstrand> kalikiana_: since lxd is what provides the socket the interface grants access to, the lxd snap needs to provide the slot implementation
<jdstrand> kalikiana_: in this specific case, the lxd service (command) that listens on the socket needs to simply 'slots: [ lxd ]' in its snap(craft).yaml
<jdstrand> kalikiana_: then, you install lxd and you get the slot for your client to connect to
<elopio> 
<elopio> bzoltan: no, I'm home
<jdstrand> zyga (cc ratliff and tyhicks): one thing that come out of the sprint that I think you may not have heard that you should be aware of is that whenever interfaces are implemented for snapd, the selinux policy for dbus will be far more open. selinux doesn't have the concept of fine-grained dbus rules. all selinux has (essentially) is 'is this process allowed to talk to that one over dbus'
<jdstrand> zyga: the same will be true of fine-grained gsettings mediation when that lands (aiui)
<tyhicks> that's a good point but I think zyga is only wanting snapd confinement right now and he's not as worried about selinux policy for interfaces
<jdstrand> tyhicks: sure, but this conversation reminded me that I needed to let zyga know that
<tyhicks> ah
<jdstrand> that's why I said "whenever interfaces are implemented" (since aiui, that isn't what they are trying to do now)
<tyhicks> jdstrand: the same is true even for file access rules - the selinux policy for interfaces can only be as fine-grained as the labeling applied to the inodes
<tyhicks> it isn't as easy to arbitrarily split up access to files in /home/tyhicks/, for example
<jdstrand> tyhicks: yeah
<tyhicks> I haven't looked at the labeling in fedora system in a while but it'd be interesting to see the output of `ls -alZ ~/`
<jdstrand> it wouldn't surprise me if it was (predominately) the same label
<jdstrand> like a session label
<jdstrand> since that corresponds with the traditional desktop trust model
<tyhicks> yeah, that's what I would guess, as well
<jdstrand> Chipaca: fyi, I'm back and there is no difference
<jdstrand> Chipaca: with 2.17
<Chipaca> jdstrand, time to file a bug! :-/
<jdstrand> let me try one more thing
<kalikiana_> jdstrand: Hmmm you wouldn't by any chance happen to know where to find lxd's snapcraft yaml? I installed it from the store
<jdstrand> kalikiana_: I would think it would be in the upstream source. if not, ask stgraber
<kalikiana_> stgraber: Any idea where to find lxd's snapcraft.yaml?
<kalikiana_> It's not in the source tree as far as I can see
<jdstrand> Chipaca: ok, so I tried it on another system without lxd involved and it worked. I'll file a bug with a reproducer
<mup> Bug #1638558 changed: interface to register and talk to well defined name on dbus session bus <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1638558>
<mup> PR snapd#2253 opened: interfaces/builtin/mir: allow slot to make recvfrom syscalls <Created by albaguirre> <https://github.com/snapcore/snapd/pull/2253>
<jdstrand> stgraber: hey, I don't seem to have any logs from containers using the lxd snap. is there something special I need to do to enable logging?
<jdstrand> stgraber: (I'm just looking at /var/log/syslog)
<mup> Bug #1638656 opened: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
<jdstrand> Chipaca: ok, bug #1638656. I think I was able to rule out a whole bunch of stuff-- the reproducer I gave is for lxd from the archive so snapd/snap-confine/core/lxd/etc interactions can all be ruled out
<mup> Bug #1638656: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
<jdstrand> Chipaca: it is simply run the testsuite in a container and it fails
<femme> can you use lxc inside snaps?
<jdstrand> Chipaca: I also noticed a typo in HACKING.md: https://github.com/snapcore/snapd/pull/2254
<mup> PR snapd#2254: fix path for source files location in HACKING.md <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2254>
<mup> PR snapd#2254 opened: fix path for source files location in HACKING.md <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2254>
<jdstrand> femme: an lxc interface is in development that would allow snaps to access the lxd socket
<jdstrand> I'm not sure if that is what you were asking
<jdstrand> but there is also an lxd snap that can be used (I use it every day)
<jdstrand> and with a new enough kernel, snapd, snap-confine and continer (eg, ubuntu 16.10), you will be able to run snaps inside a container from the lxd snap
<jdstrand> people are working to get all that stuff into 16.04
<femme> jdstrand: I'm trying to package a build system that uses lxc in snappy
<jdstrand> femme: you would need the lxc interface then. that should land in trunk in the next week or so
<jdstrand> in the mean time, use devmode to be able to access the lxd socket
<femme> jdstrand: so i need to use lxc *inside* the snap package, the package is going to build another package
<jdstrand> femme: yes, I understand. with the lxc interface, that will allow you to specify 'plugs: [lxd]' in your snap. when connected your snap will be able to connect to the lxd socket so you can drive it with the lxc command
<femme> jdstrand: ah great, I'll wait :)
<mup> Bug #1638661 opened: Undo on failed refresh doesn't keep the previous snap intact <Snappy:New> <https://launchpad.net/bugs/1638661>
<vigo> ogra_, do you know why it's possible to "snap login" repeatedly with the same account?
<stgraber> kalikiana_: git://github.com/lxc/lxd-pkg-ubuntu, snappy-16 branch
<stgraber> jdstrand: they'd be logged in /var/snap/lxd/common/lxd/logs/ or some similar path
<ogra_> vigo, nope
<vigo> ogra_, I'll file a bug for it
<ogra_> yep
<mup> Bug #1638665 opened: User can login with "Snap login" repeatedly with the same account <Snappy:New> <https://launchpad.net/bugs/1638665>
<wililupy> I have an interresting issue that just came up....
<wililupy> So I setup my device with Ubuntu-Core. I had to make some udev rule changes, and when I reboot, the system can no longer find the core.snap. Sure enough, I look in system-data/var/lib/snapd/snaps and only the kernel.snap is there and an empty directory named partial.
<wililupy> Any ideas?
<wililupy> Also, after initial login, when I type snap list, it shows no installed snaps.
<zyga> re
<Croepha> on ubuntu 16.04 it seems that /writable/ inside a snap isn't writable, is that normal?
<qengho> Croepha: The only place you can write is given by env variables with DATA in the name.
<qengho> Don't be fooled by the pathname. Some things can write there. Not snaps.
<Croepha> qengho: ok, good to know, I had hardcoded some stuff to use /writable, worked fine before, but breaks on newer snapd
<Croepha> thanks
<Croepha> hmm, looks like $SNAP_DATA is version specific... is there a scheme to accessing data from previous version?
<qengho> Croepha: The data from previous version (if any) is copied into the place for this version. It exists already.
<Croepha> ahh, good deal, thats a smart behavior
<Croepha> i imagine there is also a garbage collection/clean-up scheme? probably when you remove older versions?
<qengho> Croepha: A user can roll-back your version, and get data that existed at the instant of upgrade/refresh.
<qengho> Croepha: Yes. That is intended, at least. Perhaps not finished being implemented.
<qengho> Croepha: Also, there are places defined in "COMMON" env vars, which are not versioned and remain constant across snap versions, in case something is very large or should never be versioned or for other reasons.
<Croepha> ahh, nice
<Croepha> thanks qengho, you have been a big help
<qengho> Croepha: Welcome! Make something awesome!
<Croepha> trying :)
<mup> PR snapcraft#885 closed: Release changelog for 2.21 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/885>
<mup> PR snapcraft#884 closed: Implement API packaging plugin as requested in #1638508 <Created by bzoltan1> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/884>
<wililupy> ok, so I found the core_383.snap in the var/lib/snapd/seed/snaps directory. So I copied it to var/lib/snapd/snaps and rebooted and the device came back up, but when I went to /var/lib/snapd/snaps, it is deleted again. Any ideas as to why this is happening?
<Croepha> wililupy: I dont really know your circumstances, but that sort of sounds like an issue that I ran into
<Croepha> check your jounrnalctl logs for snapd
<Croepha> see if there are any "undo" lines, like it ran into a problem and then tried to undo them
<wililupy> Croepha: ack
<Croepha> i think there might be a bug there somewhere
<Croepha> also, the root of my issue, was that the model assertions for ubuntu-image specified my custom kernel incorrectly so it was failing there
<mwhudson> has anyone seen a test failure like this for snapd: https://buildd.debian.org/status/fetch.php?pkg=snapd&arch=arm64&ver=2.16-1&stamp=1478105694
<mwhudson> "2016/11/02 16:51:30 http: panic serving 127.0.0.1:48622: info failed to parse: yaml: control characters are not allowed"
<mup> PR snapd#2255 opened: tests: improve refresh-undo test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2255>
<wililupy> Croepha: I see an undo for the core snap. The error after it is very vague, "No Option snap_mode in section"
<wililupy> I also see errors for my kernel snap. For some reason, I installed it with the name the assertion is calling it, but when i look at the snap file in the writable partition, it is named kernel-x1.snap instead. I'm thinking that is why it is not showing up properly as an installed snap and why it looks like no snaps are installed on my system.
<Croepha> wililupy: ok, rebuild the image
<Croepha> so if the name of the snap file on the system is kernel-x1.snap  then use "kernel" as the name of the kernel in your assertion
<wililupy> will that work with the --extra-snaps variable?
<Croepha> yes
<Croepha> --extra-snaps needs to be the path of the kernel file regardless of what its called in any yaml files
<wililupy> ahh. ok.
<Croepha> ubuntu-image will open up the extra-snaps and figure out what to call it based on the meta info
<Croepha> so, it looks like your issue is exactly what mine was
<Croepha> i think there are two bugs here, first, ubuntu-image should validate the states of everything before the image gets created
<Croepha> second: snapd should avoid breaking its state when it gets a strange kernel-name
<wililupy> That makes sense.
<wililupy> Croepha: That worked!! Its consistant now! Thank you so much. No I just need to work on my automation script for the conversion of the image to another format, but at least I have a working image for the vendor. Thanks!
<Croepha> wililupy, yeah, no problem :)
<Croepha> wililupy: just curious, but what other format?
<wililupy> Croepha: I work in Whitebox switches, and they use ONIE images to install NOS's, so I convert the custom ubuntu-core image into a format that is ONIE compatible.
<Croepha> ahh. gotcha
<Croepha> are targeting ARM?
<wililupy> no x86
<Croepha> cool
<Croepha> im in digital-signage
<Croepha> one of us should really do a bug/pr for snappy_docs for the kernel thing
<wililupy> hah. I've got a lot of docs on building kernel snaps through the progression of ubuntu-core. The assertion naming one is quite interresting though. Never would have thought of that and that was why it was always reverting and removing my snaps. Learn something new everyday.
#snappy 2016-11-03
<mup> PR snapd#2256 opened: overlord/ifacestate: fix missing security setup for connected slot <Created by albaguirre> <https://github.com/snapcore/snapd/pull/2256>
<sergiusens> Saviq hey there, can you help me in triaging LP: #1638405 ?
<mup> Bug #1638405: libunity not added to LD_LIBRARY_PATH <Snapcraft:Incomplete> <Snappy:Invalid> <https://launchpad.net/bugs/1638405>
<mup> Bug #1638796 opened: mir clients that use cpu renderable surfaces don't work under confinement <Snappy:New> <https://launchpad.net/bugs/1638796>
<mup> Bug #1638798 opened: mir server process goes defunct when a mir client attaches under confinement <Snappy:New> <https://launchpad.net/bugs/1638798>
<zyga> jdstrand: ack, thank you (for the policy comment)
<foxmask> bonjello
<mup> PR snapd#2257 opened: debian: golang is not installable on powerpc <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/2257>
<mup> PR snapd#2257 closed: debian: golang is not installable on powerpc <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2257>
<tsdgeos> am i right in assuming snapcraft makes a local copy of my sources file?
<didrocks> tsdgeos: if the source is remote, indeed
<tsdgeos> if so any reason it doesn't make so of my /etc/apt/preferences one?
<didrocks> otherwise, it's using symlinks
<didrocks> I think that was planned to support that
<tsdgeos> because it's complaining abotu packages being broken
<tsdgeos> when they're fine
<didrocks> but they are creating their own local repo
<tsdgeos> it's snapcraft that broke them
 * didrocks got that you told sources file as apt source, wasn't obvious at the start
<didrocks> but yeah, IIRC, there is a bug (or you should open one) about it
<didrocks> note though that wouldn't help building from launchpad
<mup> PR snapd#2258 opened: docs: move to github.com/snapcore/snapd/wiki <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2258>
<tsdgeos> didrocks: ok, will try to open a bug
<didrocks> thanks!
<mup> PR snapd#2258 closed: docs: move to github.com/snapcore/snapd/wiki <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2258>
<niemeyer> Docs mooooved
<niemeyer> Well, some docs anyway
<mup> PR snapd#2259 opened: tests: /dev/ptmx also broken on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/2259>
<mup> PR snapcraft#886 opened: Support for gadget snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/886>
<sergiusens> didrocks tsdgeos we never planned to support /etc/apt/preferences
<didrocks> sergiusens: oh, didn't you tell you wanted to support ppas?
<didrocks> and use host apt sources.list?
<didrocks> (and so I guess host apt, which is supporting apt pinning and such)
<sergiusens> didrocks yeah, but never discussed /etc/apt/preferences at all
<didrocks> sergiusens: well, if you use host apt, you will get those options supported automatically :)
<tsdgeos> sergiusens: i don't know how half of this thing works, but if you're copying the sources file (that it seems you are at ./parts/unity8/ubuntu/etc/apt/sources.list) it only makes sense to copy the preferneces file
<tsdgeos> otherwise you're going to end up packaging the .deb file i didn't expec
<tsdgeos> t
<sergiusens> tsdgeos it makes sense to you maybe; but sure, log a bug against the project
<tsdgeos> i already did
<sergiusens> tsdgeos that's why you clean build ;-)
<sergiusens> tsdgeos where? It never reached me, did you log it against the project?
<tsdgeos> https://bugs.launchpad.net/snapcraft/+bug/1638840
<mup> Bug #1638840: snapcraft copies /etc/apt/sources but ignores /etc/apt/preferences <Snapcraft:New> <https://launchpad.net/bugs/1638840>
<Saviq> sergiusens, you probably want pstolowski to help with bug #1638405
<mup> Bug #1638405: libunity not added to LD_LIBRARY_PATH <Snapcraft:Incomplete> <Snappy:Invalid> <https://launchpad.net/bugs/1638405>
<sergiusens> tsdgeos oh, 15 minutes ago
<tsdgeos> yes
<sergiusens> tsdgeos how will you solve launchpad builds with your setup btw?
<tsdgeos> i don't understand the question
<tsdgeos> i'm a total snapcraft newbie
<sergiusens> Saviq he mentioned unity7 (yeah, wrong person), just want to figure out how this is in his LD_LIBRARY_PATH...
<sergiusens> but yeah, no worries
<pstolowski> sergiusens, $SNAP/usr/lib/x86_64-linux-gnu/libunity should be added to a part / wrapper script, no?
<sergiusens> pstolowski yes, but not as part of the base
<sergiusens> we will be adding `build-environment` for parts to solve this per part
<mup> PR snapd#2259 closed: tests: /dev/ptmx also broken on powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2259>
<mup> PR snapd#2260 opened: tests: add test that ensures the right content for /etc/os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/2260>
<Son_Goku> oh dear
<Son_Goku> the Cubs won
<Son_Goku> who knows what could happen now?!
<kalikiana_> stgraber: jdstrand I can't install the lxd snap I built... It fails on 'installation not allowed by "lxd" slot rule of interface "lxd"' if I add slots:[lxd] to it, or without it the same with lxd-support
<kalikiana_> The error isn't very descriptive unfortunately... it doesn't even say exactly what part of it is the blocker. Not even --devmode makes a difference
<kalikiana_> Nothing in the logs
<Chipaca> kalikiana_, what error? (not sure if you're talking to somebody, in which case ignore me)
<kalikiana_> Chipaca: installation not allowed by "lxd" slot rule of interface "lxd" - I used lxd: allow-installation: false deny-connection: true deny-auto-connection: true in basedeclaration.go for the lxd interface and added slots: [lxd] to the lxd snap
<kalikiana_> This was what was suggested I do in the review for https://github.com/snapcore/snapd/pull/2225/files
<mup> PR snapd#2225: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <Conflict> <https://github.com/snapcore/snapd/pull/2225>
<kalikiana_> The idea being, snapd can pull in the lxd snap when it's needed
<kalikiana_> Alas, I can't install that "providing" snap in the first place
<jdstrand> kalikiana_: yes, that is a development rough edge that I brought up on the list recently. for now, temporarily adjust the base declaration so you can install it
<kalikiana_> jdstrand: Hmm which means what exactly? How can I "adjust" without changing the interface I want to have?
<kalikiana_> devmode doesn't work
<jdstrand> kalikiana_: just make it look like 'bluetooth-control' but use 'app' instead of 'core'
<jdstrand> kalikiana_: in other words, just have it not autoconnect, but otherwise it is installable and connectable
<jdstrand> kalikiana_: when you are satisified with testing your snapd, undo that bit and submit the PR
<jdstrand> kalikiana_: you'll need to do that for both lxd and lxd-support
<tsdgeos> can i remount the snap mounts as read/write?
<tsdgeos> i tried
<tsdgeos> sudo mount -o remount,rw /var/lib/snapd/snaps/unity8-session_x1.snap /snap/unity8-session/x1
<tsdgeos> but didn't work
<ogra_> tsdgeos, indeed you can remount anything you like as readwrite ... but in case of a squashf img file that wont gain you anything ;)
<zyga> tsdgeos: squashfs doens't support writing at all
<jdstrand> tsdgeos: no. squashfs files are not writable
<jdstrand> heh
<tsdgeos> meh
<Chipaca> tsdgeos, what're you trying to do?
<valve> hi. Is this the correct channel to ask for advices on writing my snap.yaml (and packaging in general) ?
<tsdgeos> Chipaca: i'm trying to debug stuff, basically why unity8 snap doesn't start, by adding debugs, given how debug unfriendly this whole snap thing is
<kalikiana_> tsdgeos: snap try?
<Chipaca> valve, probably :-) although writing the snap.yaml by hand is discouraged
<valve> Chipaca: how should I do ?
<Chipaca> tsdgeos, what kalikiana_ said; don't create the snap, stage it and then snap try on the directory
<Chipaca> valve, what're you trying to do?
<jdstrand> tsdgeos: there is a trick you can do with overlayfs though to aid in debugging, etc. http://paste.ubuntu.com/23420437/
<Chipaca> valve, for most things, snapcraft is the way to do it
<tsdgeos> i guess i can try the try thing
<tsdgeos> tx
<valve> Chipaca: but have to start from a snap.yaml anyway (afaik)
<Chipaca> valve, snapcraft.yaml
<valve> Chipaca: yes yes sorry
<ogra_> tsdgeos, "snap run --shell unity8-session" will spawn a shell inside your snap env ...
<ogra_> tsdgeos, and if you want to tyr our single chnages you can bind-mount writable files on top of the files inside the snap
<ogra_> *try out
<valve> My current problem is the following: I'm trying to pack a python application into a snap. The problem I've right now is that the app wants to access /etc/<its-config-file>.cfg
<Chipaca> valve, it has no way of overriding that?
<Chipaca> valve, (what app, btw?)
<valve> Chipaca: that's true, might give it a different path (via a parameter).
<valve> but
<valve> What's the correct procedure to pack a "daemon" (general question) that assumes a configuration in <prefix>/etc (just as an example) ?
<tsdgeos> kalikiana_: how does the snap try thing work? what directory do i have to pass it?
<tsdgeos> because if i pass the dir the snapcraft yaml file is, it doesn't like it
<tsdgeos> so it seems it needs the "prime" folder
<tsdgeos> very explanatory
<valve> the point is: the application brings in its dependencies and these assume files in <prefix>/etc (just to get to my point)
<valve> I can change my application settings but have no (or just few) controls over the dependencies
<valve> I was assuming that the plugines were doing the maginc (just changing the prefix) underway
<valve> But while running the application (daemon to be correct) it cannot access /etc and thus doesn't work
<valve> I'm surely wrong somewhere (bad assumptions and/or understanding). The snapcraft.io documentation doesn't help me.
<valve> Where should I dig for mode documentation ?
<zyga> valve: I don't think the plugins do prefix changing magic
<valve> zyga: the whole thing does use prefixes since (AFAIK: it builds and pack things accordingly). My point (due to ignorance - mostly) is: bringing things into a snap is process that tends to be bloody. I.e. I can change my app, I can delve into the details of some app. If I have a huge chain of dependencies ... the problems could be many
<valve> I supposed (probably wrong assumption) to have an "internal mapping" to let the code see a (sort of) container FS as a chroot-ed thing (please try to get me)
<valve> (Assuming that a package resolves to an environment variable to get a correct prefix ... works in - probably - just an handful of times))
<valve> However: is there a point where to grab fresh / more complete documentation ? At the moment what I'm using is snapcraft.io
<zyga> valve: we're cooking a feature that will make it easier, right now if you can pass various switches to make it ignore /etc it is much better/eaier
<zyga> easier*
<valve> zyga: will do that using HOME (SNAP_DATA) at build and running phases
<valve> zyga: thanks
<mup> PR snapcraft#886 closed: Support for gadget snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/886>
<mup> PR snapd#2261 opened: release: os-release on core has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2261>
<sergiusens> renato replied on telegram
<valve> Is there a timing for the jhbuild plugin (https://github.com/snapcore/snapcraft/pull/812) ?
<mup> PR snapcraft#812: New plugin: jhbuild <Created by attente> <Conflict> <https://github.com/snapcore/snapcraft/pull/812>
<attente> valve: there's some issues with that PR that i need to work through...
<attente> valve: i'm trying to remove the use of lxc in that plugin
<attente> it's a substantial re-write...
<valve> attente: thank you
<steve___> Hi All, I'm new here. Just started working on snapping some neuroimaging tools.
<steve___> Is there a way to create a "local" store so we can test everything out entirely without polluting the Ubuntu store with half baked packages?
<cwayne> steve___: hiya, welcome :)  generally I'd say that's the purpose of the edge channel on the store, those packages aren't meant to be stable and could very well be half-baked
<steve___> perfect!
<cellash> Hi all, Im currently have a working .snap on Unity 7 on 16.04 and 16.10 however when I try to run it on Unity 8 (16.10) I get this error: https://pastebin.ubuntu.com/23420077/. Does anyone know what this means or knows a way to fix this? Any hep would be appreciated.
<Mirv> qt-ubuntu^Wubuntu-qt-runtime^W long live ubuntu-app-runtime!
<didrocks> renato__: Mirv: so, indeed, I think we should have the desktop launcher as part of the runtime content-shared snap
<renato__> didrocks, hi
<qengho> Hi all. How is snap set/get supposed to work?
<didrocks> orâ¦ hum, I wonder if the remote parts is after: another remote one, if that would work?
<didrocks> sergiusens: did you already try to test this: ^ ?
<Mirv> didrocks: so I was thinking about a launcher as part of a cloud part that is combined with the content shared snap use
<didrocks> yeah, either we combine, or we chain them
<sergiusens> didrocks I did add logic for this to work in one of the latest releases; is it failing bad?
<Mirv> yeah chaining if possible
<didrocks> sergiusens: no, I was just curious, let's see if we can break it then! :-)
<sergiusens> didrocks I am basically resolving the whole build chain before trying to even load a plugin now
<renato__> didrocks, we will need a combination of gtk and qt launch, since some of our apps uses glib and qt
<didrocks> Mirv: ok, so to avoid repetition, let's have the 2 chaining each other, and adding a new part refering your work
<Mirv> so after: [ubuntu-app-runtime], which pulls in the ubuntu-app-runtime and the app plugs into it and uses ubuntu-app-launch (or some other name) to launch the app
<didrocks> renato__: but everything is shipped in ubuntu-app-runtime, correct? (gtk/glib and qt?)
<didrocks> Mirv: FYI, the launchers are https://github.com/ubuntu/snapcraft-desktop-helpers, adding a new built one isn't an issue, we just need to ensure the paths are correct and we ship in the runtime what we need
<renato__> didrocks, I think so, Mirv can confirm that
<Mirv> there's a lot yes planned at the moment to be included
<qengho> How is a snap supposed to get values set from the outside with "snap set"?
<didrocks> qengho: snapctl set/get from the hook itself
<didrocks> qengho: snapd has an example in the tests for this + the hook documentation
<didrocks> Mirv: so, yeah, let's add another flavor for it. Look at the current built-in helper (like the one used in the vlc snap) and tell me what paths needs to change. Then, we can revisit
<didrocks> and I think we'll "force" apps using this runtime to bindmount it in a well-known location
<didrocks> like $SNAP/snap-platform maybe
<Mirv> didrocks: right, after we have something (not really started on the cloud part / launcher yet, just have custom launchers for apps), it could live there too instead of own repo
<renato__> didrocks, Mirv, we need to mount the share content in a fixed dir to get it working right?
<renato__> right now the app can mount it whatever it want
<Mirv> renato__: yes well the launcher would want it to be in the known dir, like we now have it mounted under the app's ubuntu-app-runtime dir
<Mirv> didrocks: do you think a custom interface would be then better than content interface where we need to actually specify the directory?
<didrocks> Mirv: it would be better to reuse the same launcher structure directly, there is a common file and we try to share as much code between launchers as possible (which is the goal of this repo)
<didrocks> rather than each one having his own repo. We saw what happened then (broken in some place, not sure what people took)
<didrocks> there are makefiles to build them dynamically
<didrocks> (and so, they all have a common part, and a specific/dedicated one)
<didrocks> renato__: Mirv: for mounting, I would really force to mount them in a directory for the launcher to know where to look for (or add an option to the launcher to specify if default doesn't work for them)
<Mirv> didrocks: makes sense indeed
<didrocks> but best practice is to agree on a path
<didrocks> and use the same for all runtime
<didrocks> so content-share interface, and specifying a path (I would avoid runtime though for confusion with flatpak)
<didrocks> as they are not exactly the same thing
<renato__> will be nice if the interface could create the path if that does not exists, right now the app need to install a empty dir
<didrocks> we agreed 3 months ago to use the term "platform"
<didrocks> renato__: yeah, it's because we are using bindmountâ¦ and the path is RO
<didrocks> so you can't create the dir dynamically to bindmount to it
<Mirv> didrocks: we agreed this week against platform and framework, and agreed today on ubuntu-qt-runtime -> ubuntu-app-runtime :)
<didrocks> (and we don't use overlayfs or something similar)
<didrocks> Mirv: hum, you should have talked to us, runtime was voted against by executive decision
<didrocks> so really, don't use it :)
<renato__> the name again :D
<Mirv> oh this bikeshedding :)
<didrocks> classical, isn't it! :)
<Mirv> didrocks: yeah we've the content interface working now as described, renato__ is running calendar on it
<didrocks> Mirv: let's call it -foo for now :)
<didrocks> ok, so you only need to integrate to the launcher
<Mirv> yes renato just copy-pasted the launcher from my test app
<didrocks> do you want to have a first look? I think we can then amend the existings one to add more options if needed
<seb128> should building snaps that pull a git repo work on launchpad?
<seb128> I've a simple one that fails to build on
<seb128> "git.gnome.org: Name or service not known"
<renato__> Mirv, no I was using gtk-launcher and this consumes 50MB on the package
<Mirv> yeah I plan to take an actual first look really-soon-now, it's just all this bikeshedding that gets in front of it :)
<didrocks> seb128: I got some issues on some domains as well. It's pulled as source:, correct?
<renato__> Mirv, didrocks we need a launcher that make uses of the library on the content share instead install new ones
<Mirv> renato__: oh, ok, I thought you copy-pasted from the timostestapp3 that would have the correct paths already
<seb128> didrocks, yes, http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/snapcraft.yaml
<Mirv> renato__: that's what the launcher on timostestapp3 does, yes :)
<renato__> Mirv, I did a mix of both
<didrocks> seb128: I guess for the launchpad team, but yes, it's supposed to work
<didrocks> Mirv: creating a complete launcher respecting themes and such is really complex (with gsettingsâ¦)
<didrocks> I guess that's why renato__ pulled from both :)
<Mirv> didrocks: so indeed this https://github.com/tjyrinki/timostestapp3/blob/master/launcher is basically copy-pasting + sed from desktop-helpers
<didrocks> Mirv: ok, do you want me to work on this? (in this case, it will be on Monday), or do you want to have a go?
<seb128> cjwatson, hey, should launchpad be able to pull a source from git.gnome.org to build a snap? I don't know if I do something wrong/stupid but my build fails on "git.gnome.org: Name or service not known"
<didrocks> seb128: git:// is using ssh IIRC, did you try the http:// version?
<seb128> didn't, that could be it
<didrocks> if you use http:// postfix with .git
<seb128> I think I changed it to git: because snapcraft is not smart enough to figure out that http://git is a git type source
<didrocks> (if gnome git doesn't support that, try with source-type: git instead)
<didrocks> yeah, it doesn't
<didrocks> so either gnome git support .git suffix on http url
<didrocks> or source-type
<didrocks> that should fix it
<cjwatson> yes, you must use http://
<cjwatson> (or https://)
<seb128> didrocks, I reported https://bugs.launchpad.net/snapcraft/+bug/1590797 on snapcraft about that btw just for the record
<mup> Bug #1590797: "no handler to manage source" is not an helpful error <bitesize> <Snapcraft:Triaged> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590797>
<cjwatson> but it's not about git:// using ssh (which it doesn't)
<cjwatson> it's that builds currently go through a proxy that doesn't proxy the git:// protocol
<renato__> didrocks, Monday is ok for me I will be off tomorrow :)
<didrocks> seb128: I did the .git suffix for detecting it, but yeah, I think if you have https://git.<something>, it should be considered as git
<Mirv> didrocks: I'll check tomorrow how does it look, but it's basically down to "use Qt and other libs primarily from $SNAP/ubuntu-app-foo" so let's check on Monday
<didrocks> renato__: ahah, ok :)
<seb128> cjwatson, didrocks, thanks
<didrocks> Mirv: ok, let's do this!
<renato__> Mirv, didrocks in case you need a app to try: https://code.launchpad.net/~renatofilho/ubuntu-calendar-app/snappy-runtime
<didrocks> great! that will be of a great help
<Mirv> didrocks: or the simple QML case https://github.com/tjyrinki/timostestapp3 :)
<sergiusens> niemeyer this is the link that is needed https://hub.docker.com/add/automated-build/github/form/snapcore/snapcraft/ but the sad thing is, you need r/w https://forums.docker.com/t/cant-access-new-github-organization-for-automated-builds/1080/16
<sergiusens> niemeyer I'll keep it manual for now
<didrocks> Mirv: ok, please have a look tomorrow and let's sync up on Monday! :)
<niemeyer> sergiusens: This is what I get when I try to create it: The repository name `snapcore/snapcraft` is already taken.
<niemeyer> sergiusens: Did you create it?
<sergiusens> let me delete it
<sergiusens> niemeyer it is deleted now
<niemeyer> sergiusens: "Could not find github repo `snapcore/snapcraft`"
<niemeyer> sergiusens: Ah, wait
<niemeyer> sergiusens: Maybe GitHub is preventing Docker from seeing it.. let me check the config on GH's side
<Mirv> renato__: didrocks: now with more bikeshedding :) https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-app-platform/+build/9019
<didrocks> Mirv: ahah! well done :)
<mup> PR snapd#2262 opened: tests: disable autorefresh for the external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2262>
<mup> Bug #1638320 changed: remove core snap via snapweb fails but it still removes from the web interface <snapweb:New> <https://launchpad.net/bugs/1638320>
<pachulo> Hi all! Is there any way of cleaning old versions of a snap in Ubuntu desktop other than removing the old revisions one by one?
<mup> PR snapd#2261 closed: release: os-release on core has changed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2261>
<mup> Bug #1638988 opened: Cannot run spread hello world on all-snaps image <Snappy:New> <https://launchpad.net/bugs/1638988>
<mup> PR snapd#2263 opened: tests: check that gpio device nodes are exported after reboot <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2263>
<mup> Bug #1638995 opened: lslogins displays user and email info <Snappy:New> <https://launchpad.net/bugs/1638995>
<swaveck> QUESTION: I've just installed Ubuntu Core on my Pi3, authenticated on UbuntuOne; what is my password? UbuntuOne pass isn't working.
<ogra_> swaveck, there is no local login ... use ssh
<ogra_> (like the config tool told you on the last page)
<ogra_> you can ssh and run "sudo passwd $USER" to set a password, that will also allow console logins then
<swaveck> thanks for help, I'll try it
<qengho> Should I be able to run "snap set ..." and get a configure hook script called in a snap? When I add a configure file in meta/hooks/, "snap set" fails with  error: cannont perform the following tasks:\n- cannot find hook "configure" in "snapname"
<qengho> snap    2.16+16.10ubuntu1.2
<mup> PR snapcraft#880 closed: Remove license concepts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/880>
<nottrobin> How can I switch the channel of a snap?
<nottrobin> If I was following "candidate" but now I want to follow "stable"?
<noise][> nottrobin: snap refresh foo âstable
<nottrobin> ah ha!
<nottrobin> thanks
<zyga> Pharaoh_Atem: thank you for helping on the release
<zyga> Pharaoh_Atem: next week I'll look at what I can do to get the last few bits fixed
<Pharaoh_Atem> zyga: you're welcome
<zyga> Pharaoh_Atem: tomorrow is wrap up and travel home (finally!) for me
<Pharaoh_Atem> well, at least we have the presets in Fedora 25
<Pharaoh_Atem> https://bodhi.fedoraproject.org/updates/FEDORA-2016-7b70ad9b8e
<zyga> Pharaoh_Atem: yes, and I'm sure we'll crack that last permission with fresh minds next week
<zyga> nice :)
<vagpag_> hi, could you pls help me on how to connect on ubuntu core 10 as loclahost?
<qengho> vagpag_: You said "how to connnect on" and "10", and neither of those make any sense to me. Maybe say that another way.
<vagpag_> Sorry! Let me try again.
<vagpag_> After installing ubuntu core 16 on my pi 3 and first boot, I can't login as localhost. Hope that helps...
<zyga> vagpag_: did you create the user account>?
<qengho> vagpag_: That "localhost" part makes no sense still. After you initialize and give it an email address in Launchpad, it listens for incoming ssh. If you ssh to that from another place, with your username equal to your launchpad id, then you should be able to log in. That's the normal path. Did you do all that, or something else?
<qengho> If something else, where did you differ?
<qengho> $ ssh -l vagpag raspberrypiIPddress
<qengho> Assuming https://launchpad.net/~vagpag is you
<vagpag_> gengho: after entering my Ubuntu SSO credentials (step three in first boot), my screen says Ubuntu Core 16 on <my ip> (tty1) / localhost login:.
<zyga> vagpag_: ssh into that ip from a machine that has corresponding SSH keys
<zyga> vagpag_: the username is your launchpad user ID (not email)
<valve> sorry. Can I pass parameters to a daemon such as:  'command: bin/fcd -d -c $SNAP/etc/fcd.cfg' (simple daemon) ?
<qengho> valve: Sure!
<valve> supposed so BUT got 'fcd: error: unrecognized arguments: /snap/...'
<vagpag_> zyga: how do i do that? ssh and ip of the machine?
<qengho> valve: I should distinguish here, that snapcraft will let you do that. I'm not saying your command you are providing will like it. You're running "fcd" there. It complaining. Fix that.
<zyga> vagpag_: like this
<qengho> $ ssh -l vagpag raspberrypiIPddress
<zyga> vagpag_: ssh zyga@1.2.4.4
<zyga> vagpag_: assuming zyga is the username on launchpad
<zyga> vagpag_: and the box that runs the ssh command has ssh keys set and uploaded to launchpad under the account "zyga"
<mup> PR snapcraft#887 opened: Cache apt related files (config, packages) in 'apt' parent directory <Created by squidsoup> <https://github.com/snapcore/snapcraft/pull/887>
<qengho> Just to brag, I made a snapcraft yaml that reads params from a config file (that is previously written by a snap-set hook) and optionally sets args for a daemon, without a wrapper. http://bazaar.launchpad.net/~cmiller/+junk/sshesame-snap/view/head:/snapcraft.yaml
<valve> qengho: thanks
<valve> qengho: thanks
<zyga> qengho: nice :)
<zyga> qengho: there's a feature in snappy that's not yet available through snapcraft that will let you do that in a way that's even cleaner than that
<qengho> zyga: really?!
<zyga> qengho: there's a hook system and a way to run a special "app" (hook) on install
<zyga> qengho: you can us it now but there's no way to express that in snapcraft yet
<qengho> zyga: What's the new hook name?
<zyga> qengho: configure
<vagpag_> zyga: from a mac's terminal i run ssh -l vagpag and pi ip and know asks for a password
<zyga> qengho: I hope it will be docuented soon at https://github.com/snapcore/snapd/wiki
<qengho> zyga: Er, that's what I'm using. Walk back up that tree. ^
<zyga> vagpag_: do you have ssh keys on your launchpad account?
<zyga> hmm :)
<zyga> ohhh
<zyga> nice!
<zyga> qengho: this line, you can simplify it
<zyga>     command: sh -c "'test ! -f $SNAP_DATA/configuration || . $SNAP_DATA/configuration; $SNAP/bin/sshesame ${port:+-port $port} ${listen_address:+-listen_address $listen_address} 2>&1 |$SNAP/usr/bin/logger -t $SNAP_NAME'"
<qengho> zyga: How?
<zyga> qengho: configure runs before we start services AFAIR
<vagpag_> zyga: yes. I have it on my ubuntu one account
<zyga> vagpag_: do you have that ssh key on your mac?
<vagpag_> zyga: No!
<qengho> zyga: I guess i could put or "code" in the configuration file, but I'd rather not.
<zyga> vagpag_: user account setup doesn't use passwords, you have to use ssh keys to log in
<qengho> zyga: I don't know how to get optional params in the command:... otherwise.
<zyga> vagpag_: afer that you can use 'sudo passwd' to set a password if you want
<zyga> qengho: I mean you can just do any initial setup in the hook itself
<qengho> zyga: I don't see it, but I'm happy with this anyway.
<qengho> zyga: Is it up to me to poke at systemd to restart the service on config change?
<qengho> me=user?
<zyga> qengho: the hook can send it a signal to restart the service / reload it
<zyga> qengho: the service can observe a config file
<zyga> qengho: you can do many things
<qengho> zyga: Hmm, is that in a "machines can theoretically do that"-sense, or a "hooks can sighup their process group to signal the services attached should reload and that's what we expect snap packagers to do" or something?
<qengho> I have a simple daemon. No pidfile. systemd manages it, but I don't know the process name, and I'd be surprised if confinement lets me to a lot.
<zyga> qengho: you can do that to your process from your own hook
<zyga> qengho: the daemon can use inotify to look at the config file
<zyga> qengho: and you can write a pidfile if that helps
<zyga> qengho: or use any form of IPC to push new data into the sevice
<zyga> qengho: snappy dosen't help or get in the way much
<qengho> zyga: is this after we get a patches: object in snapcraft yaml so I can add inotify watching to somebody's code?
<zyga> qengho: ?
<zyga> qengho: no, why?
<zyga> qengho: the service can inotify observe a config file
<zyga> qengho: (or dir or something)
<qengho> Oh, a wrapper can? I see.
<zyga> qengho: and the config hook can just write to those files
<zyga> perhaps I'm missing something and I didn't understand your question
<qengho> zyga: I'll tell you my wishlist. The "configure" hook has an environment variable set that contains a list of the process IDs or service names of all the daemons snapd started, and the configure hook can maybe send some signal to those.
<AlbertA> qengho: zyga: I was able to put a configure hook by "organize: configure: meta/hooks/configure" seems to work for me for now :)
<qengho> AlbertA: I think that will fail when you try to "snap set"
<AlbertA> qengho: worked fine for me :)
<qengho> AlbertA: Not for me. :\ The nightly snapcraft PPA supports hooks too.
<zyga> qengho: interesting though it would always be racy I'm afraid
<zyga> AlbertA: nice!
<zyga> qengho: though the hook might detect that and just fail
<zyga> qengho: (if the user happens to concurrently restart services and use set"
<zyga> )
<zyga> qengho: I need to get some rest, good night
<qengho> zyga: Good night!
#snappy 2016-11-04
<mup> Bug #1638425 changed: The documentation to install snapd in archlinux doesn't mention that the socket needs to be started <snap-docs> <Snappy:Fix Released by fgimenez> <https://launchpad.net/bugs/1638425>
<mup> Bug #1639095 opened: On archlinux, /snap/bin is not added to the $PATH <archlinux> <Snappy:New> <https://launchpad.net/bugs/1639095>
<mwhudson> uh
<mwhudson> i apparently can't download snaps
<mwhudson> i get 500s from the cfn
<mwhudson> *cdn
<mwhudson> heh working now
<DSS> First boot is not accepting my Ubuntu Store login credentials...
<DSS> Ok, so I have to login via SSH first...
<DSS> Never mind...
<mup> PR snapd#2264 opened: Reinstate delta download <Created by absoludity> <https://github.com/snapcore/snapd/pull/2264>
<liuxg> ogra_, ping
<liuxg> ogra_, ping
<liuxg> I am now using kvm to launch ubuntu core, when I am trying to login using "ssh -p 10022 USER@localhost", it prompts me a password. May i know what password should it be? is it the one for the Ubuntu One account or the ssh keys? thanks
<liuxg> what should be the correct password for logging into a kvm ubuntu core system? I have tried to use the Ubuntu One password, but it fails. thanks
<foxmask> bonjello
<mup> PR snapd#2265 opened: Fix build failure on call to UbuntuArchitecture <Created by stolowski> <https://github.com/snapcore/snapd/pull/2265>
<mup> PR snapcraft#887 closed: Cache apt related files (config, packages) in 'apt' parent directory <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/887>
<thomi> Hi snappy devs, we're considering deploying a new search.apps.u.c today, and wanted to check the state of snapd integration tests, but https://travis-ci.org/snapcore/snapd/builds seems to think nothing has landed in the last 17 days. Am I looking in the wrong place?
<zyga> Pharaoh_Atem: hey, I'm heading home but I have an idea
<zyga> Pharaoh_Atem: can we detect via getenforce if selinux is on and just print a big fat warning
<zyga> Pharaoh_Atem: and release the package as is
<zyga> Pharaoh_Atem: it's better than keeping it siloed
<zyga> Pharaoh_Atem: and more eyes == better
<zyga> Pharaoh_Atem: perhaps someone will figure out how to actually fix the remaining warts
<mup> PR snapcraft#881 closed: Catkin plugin: Python nodes require gcc/g++ too <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/881>
<thomi> niemeyer: Any idea? ^^
<zyga> thomi: looks odd, we definitely land stuff all the time
<thomi> zyga: that's what I figured - perhaps you stopped using travis for some reason?
<mup> PR snapcraft#671 closed: Add initial snapcraft manpage <Created by tsimonq2> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/671>
<mup> PR snapcraft#879 closed: The latest icon definition is deprecated <Created by liu-xiao-guo> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/879>
<zyga> thomi: look at pull requests
<thomi> hmmm, well that's odd
<thomi> but at least I see some green builds. Thanks zyga !
<tsdgeos> what's the optimal workflow for integrating changes into a snap to see if they fix a bug? the only thing i can think of is, but MR in launchpad, make bileto create a ppa, add ppa to my system, rebuild the snap
<tsdgeos> but that looks like a very slow cycle
<mup> PR snapcraft#661 closed: Added a test Jenkinsfile <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/661>
<mup> PR snapcraft#674 closed: Add reference.md <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/674>
<mup> PR snapcraft#736 closed: Disable internet access during unit tests <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/736>
<zyga> thomi: I think those are master builds on push that we've disabled
<zyga> thomi: we test PRs instead
<zyga> thomi: as we don't just push to master willy nilly
<kalikiana_> stgraber: jdstrand FYI conflicts resolved and the branch has got the latest definitions - I think it works, but by design, apparently, I can't actually test it... so how do we proceed from here? Not quite sure how this will work in the end
<mup> PR snapcraft#874 closed: Remove the debian packaging <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/874>
<sergiusens> Pharaoh_Atem hey, I want to land your RPM support to make it go into the next release, will you have time to do the catching up in the branch?
<tsdgeos> how do i remove stuff i've added with snap try?
<dholbach> tsdgeos, "snap remove <snap-name>"
<tsdgeos> dholbach: but that removes everything
<tsdgeos> dholbach: the thing is, if i have the snap, then i "try" twice, i end up with 3 copies of the snap in /snap
<dholbach> tsdgeos, I'm not sure I understand... what would you like to remove and what would you like to keep?
<tsdgeos> i want to remove the two copies added by try
<tsdgeos> and just be left with the one i actually installed
<dholbach> [remove command options]
<dholbach>           --revision= Remove only the given revision
<dholbach> I've never tried it, but ^ maybe that?
<tsdgeos> i can try thta i guess
<Chipaca> tsdgeos, --revision should work
<Chipaca> tsdgeos, btw, why are you wanting to remove 'em?
<tsdgeos> Chipaca: because space?
<Chipaca> tsdgeos, they aren't copies
<tsdgeos> Chipaca: doesn't seem to work or i can't pass the correct revision number
<Chipaca> tsdgeos, unless your app creates a lot of data
<Chipaca> oh?
<Chipaca> let me look
<tsdgeos> $ ls /snap/unity8-session/
<tsdgeos> current  x1  x2
<tsdgeos> how do i remove x2 ?
<mup> PR snapd#2265 closed: Fix build failure on call to UbuntuArchitecture <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2265>
<tsdgeos> ah i have to revert and then remove
<Chipaca> tsdgeos, snap remove --revision x2 unity8-session
<tsdgeos> Chipaca: no that didn't work without reverting first
<Chipaca> tsdgeos, ah, if it's current, yes
<Chipaca> tsdgeos, that's why the help says "revert first" :-D
<Chipaca> not the help, the error message
<tsdgeos> with a ?
<tsdgeos> doesn't make one very confident
<Chipaca> well, it's not a mind reader
<Chipaca> whether or not it's the right thing to do depends on what you're wanting to do
<tsdgeos> well i told it to remove the thing
<Chipaca> for example, you might not *want* to remove the current revision
<tsdgeos> then remove the thing
<bzoltan> dholbach: will you join our call in 11.5h? I would appreciate your input.
<bzoltan> popey: mhall119:dholbach: I have added a doc to the invitation.. if you can spare few minutes to review that would make our call more efficient.
<mup> PR snapd#2130 closed: store: retry store ops (phase 1) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2130>
<mup> PR snapd#2266 opened: tests: run autopkgtests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2266>
<popey> bzoltan: okay! :)
<Son_Goku> elopio: thanks for the unit test example
<Son_Goku> I was able to add another test based on that one, so there's two tests now
<dholbach> bzoltan, 11.5h?
<Son_Goku> I'll have to play with the code to see if I can make a cpio archive with "./" at the beginning of the path, as well as one with "/" at the beginning too
<dholbach> bzoltan, but yeah
<bzoltan> dholbach: ohh... a typo :) in 11.5h i will be in my pyjama and sleep like a baby
<dholbach> +1
<mup> Bug #1639234 opened: docs/rest has not url for install (refresh, revert, remove) example <Snappy:New> <https://launchpad.net/bugs/1639234>
<jdstrand> kalikiana_: ack
<tsdgeos> is there a way for snapcraft to use a local deb instead one from the archive?
<tsdgeos> when building the snap file?
<qengho> tsdgeos: Yes!
<qengho> tsdgeos: You know the file path?
<tsdgeos> qengho: for the deb i want to use?
<tsdgeos> i can know it, yes
<tsdgeos> or i guess i can dpkg -x into the prime folder?
<qengho> tsdgeos: Not merged yet, but you could use it anyway. https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin/+merge/266650
<bzoltan> dholbach: popey: once again, thank you for your time. I have edited and format a bit the minutes. Would you please take a quick look at it and call me an idiot if i missed something or interpreted something wrong?
<dholbach> sure, hang on
<qengho> Do we have any way of knowing when snapcraft builder for launchpad-hosted snap building is updated?
<mup> Bug #1639284 opened: Cant start any snap application on Xenial <Snappy:New> <https://launchpad.net/bugs/1639284>
<tsdgeos> so the unity8-session snap is missing some symlinks that are created by the deb " using the alternate system", i guess snapcraft doesn't run those steps?
<tsdgeos> i.e. is deb postinst run?
<qengho> tsdgeos: Correct. There is no post-install. post-install runs have to be done at "stage" or "snap" time, when fabricating a snap package.
<tsdgeos> ok
<mup> PR snapd#2267 opened: Release version 2.17.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2267>
<mup> PR snapd#2253 closed: interfaces/builtin/mir: allow slot to make recvfrom syscalls <Created by albaguirre> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2253>
<Pharaoh_Atem> sergiusens: I'm working on it now
<Pharaoh_Atem> but I'm having a problem
<Pharaoh_Atem> I don't know why this unit test is failing
<Pharaoh_Atem> the code it's failing on is exactly the same as the deb source code
<Pharaoh_Atem> by all rights, it should work
<Pharaoh_Atem> I don't know why it isn't
<Pharaoh_Atem> I think I may not understand how this test is supposed to be written, but... :/
<_markfeatherston> Hello, I'm trying to build a kernel for ubuntu core and I'm running into troubles (Failed downloading ubuntu-core/edge).  Is anyone here familiar with this error?
<_markfeatherston> Error: https://paste.ee/p/PjiEd
<_markfeatherston> yaml: https://paste.ee/p/pW24W
<ogra_> _markfeatherston, looks like there is a store problem currently
<_markfeatherston> Ahh, good to know.  I'll hold off a bit on this then.  Thanks!
<_markfeatherston> Actually I do have other questions in the meantime.  I'm looking at the 96boards kernel as a reference.  It has "confinement: strict" in the yaml.  I think I understand what this means in context of an application, but does the confinement do anything with kernels?
<ogra_> well, if you set devmode you also need --devmode for snap install and snap refresh ...
<ogra_> beyond that i dont think it does anything actively atm (it probably will)
<_markfeatherston> ok, makes sense
<_markfeatherston> the example kernel yaml also had "kdefconfig: [defconfig, distro.config]".  What is the distro.config in this case?  Is that ubuntu core's kernel config options?
<ogra_> i think thats a question for the kernel team :) ppisati might be your man, but he is at the plumbers conference
<_markfeatherston> Ok, I'll check back later for that or just experiment when the store comes back up.  thanks :)
<qengho> Where should I file about about the official disk images' compression scheme, xz?
<qengho> That is, I want to ask for images to be gz compressed too. MEMDISK doesn't support xz.
<mup> Bug #1639328 opened: Snappy Ubuntu Core images are not in a format readable by MEMDISK <Snappy:New> <https://launchpad.net/bugs/1639328>
<pippo_> ho installato ubuntu core ma ad un certo punto mi chiede un email address "from your account in the store": di quale account si tratta ?
<Pharaoh_Atem> elopio: ping
<Trevinho> Hey, how can I understand what snap versions are available in each channel?
<Pharaoh_Atem> elopio: I removed the pull() call, but it's still breaking, and I'm not sure why... https://travis-ci.org/snapcore/snapcraft/jobs/173348023
<Trevinho> I was expecting snap refresh --list <snap> to give me that info...
<Trevinho> but...
<Trevinho> it doesn't seem to do
<Trevinho> I can only snap refresh --edge <snap> and see what will happen, but not get those inofs without changing
<Trevinho> I mean something similar to snapcraft status for your pkgs...
<noise][> Trevinho: I believe we intend to make a `snap info foo` command to provide that information, but is not available yet
<dobey> Trevinho: can't you do snap refresh --list --edge?
<jdstrand> roadmr: hi! please feel free to test r791. that has the fix for bools as strings as well as everything for parsing the base declaration and applying overrides with --plugs/--slots
<roadmr> jdstrand: awesome! Sure, I'll give it a whirl in a sec
<jdstrand> roadmr: I have one more thing to implement for completeness, but it isn't used anywhere yet
<Trevinho> noise][: yeah, I was wondering why that isn't available too...
<roadmr> jdstrand: ok
<Trevinho> dobey: I tried the same, but no... It says --list does not take mode nor channel flags
<noise][> Trevinho: i think just didn't make the cut in the rush to the UC 16 release but I suspect will get added before long
<Trevinho> noise][: I hope so. Thanks for the info about `info` tho :-)
<roadmr> jdstrand: it works! so if I pass a --plugs plugs.json with a payload allowing e.g. lxd-support, my snap which uses it gets auto-passed; if I just change the interface name in the payload, it gets flagged for manual review
<roadmr> jdstrand: the message is a bit cryptic (if accurate): "not allowed by 'allow-installation' in base declaration" doesn't hint that it could also be allowed in a --plugs or --slots override. But I think it's fine like this and we can tweak if we get confusion
<jdstrand> roadmr: we are going to give the messages an overhaul. the message is meant to convey what denied it, not how to override it since a reviewer will presumably know that
<jdstrand> roadmr: but again, yes, we'll be giving the errors a once over
<roadmr> jdstrand: thanks, that'll be quite useful
<roadmr> reviewers are humans too \o/
<Trevinho> sergiusens: hey... Is there any way to make the version in the snapcraft.yaml to be more dynamic? I.e. to add a cvs revision or something similar?
<elopio> Pharaoh_Atem: doesn't make a lot of sense. It's the same code as the other test Â¯\_(ã)_/Â¯
<elopio> let me finish my travis builds, and I'll try to debug it.
<Pharaoh_Atem> okay
 * Pharaoh_Atem is starting to feel really frustrated with this particular test
<Pharaoh_Atem> I was tempted to just delete the test, but that feels like cheating...
<elopio> it's almost done. I just feel bad that we were so slow to review it. Hopefully we get faster now that there are no sprints and no big releases.
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> elopio: I wanted it to make it into the next version of snapcraft
<Pharaoh_Atem> but I think it just went out today
<Pharaoh_Atem> hmm, went out two days ago
<Pharaoh_Atem> kyrofa: why do you think you'll get to avoid SRUs with snaps?
<Pharaoh_Atem> if anything, I think the SRU process would transfer over to snaps, since it'd be more important with the coarser dependency logic
<nacc> SRU is a way to control the rollout in the repository; snaps are controlled by the developer independently, no?
<Pharaoh_Atem> nacc: sure, but if you're the developer...?
<Pharaoh_Atem> you better have a process for ensuring things are worth releasing
 * nacc lacks context
<nacc> but i think it's just saying that there is no such thing as the SRU process for snaps
<nacc> you just push fixes
<nacc> with your own CI
<nacc> presumably
<nacc> and QA
<Pharaoh_Atem> yes, but in https://github.com/snapcore/snapcraft/pull/880, kyrofa makes the comment that pushing major version updates will not have an SRU process
<mup> PR snapcraft#880: Remove license concepts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/880>
<Pharaoh_Atem> I'd argue that you'd likely be forced to be more careful, because there's literally no way to check and guard against breakage at all
<nacc> SRU and various other tools require that you go through a formal process
<Pharaoh_Atem> yes
<nacc> run by the SRU team
<nacc> there is no such process for snaps
<Pharaoh_Atem> there probably will be eventually
<nacc> you as the end developer can push whatever version you want to whatever stream
<Pharaoh_Atem> sure
<Pharaoh_Atem> but you (as Canonical) would have a process for pushing updates to your own snaps
<nacc> i'm not so sure; the lack of SRU is meant to be one of the pros :)
<Pharaoh_Atem> just as I (as a dumb human) would have a process for ensuring what I push is halfway decent
<nacc> well for canonical owned snaps, they'd figure something out, i'm sure
<nacc> i'm not sure what that has to do with SRU
<Pharaoh_Atem> imho, tools cannot eliminate processes
<nacc> that's more a statement that if you change something, test it and make sure it doesn't break anything -- SRU is a specific implentation of that
<Pharaoh_Atem> only people can eliminate processes
<Pharaoh_Atem> nobody said you *have* to have an SRU process for Ubuntu repos
<nacc> Pharaoh_Atem: dunno; i think the point in there was that SRUs are generally not meant to be major version bumps -- but snaps make that easier to deleiver
<Pharaoh_Atem> but breaking people's world is generally not a good idea and something you probably don't want to do
<Pharaoh_Atem> so that would require implementing a process to ensure you don't do that
<nacc> how would you break their world?
<Pharaoh_Atem> well, at least in this example (PR880), they broke snapcraft.yaml files that used the license stuff because they removed it
<Pharaoh_Atem> making those files that used it now invalid
<_markfeatherston> Is this at all still relevant for ubuntu core 16? https://developer.ubuntu.com/en/snappy/guides/porting/
<nacc> Pharaoh_Atem:  i don't know the specific context, sorry
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> the general point I'm making is that tools don't necessarily get rid of processes
<Pharaoh_Atem> only people do
<Pharaoh_Atem> if you want a lighter process, you change the process to be so
<mup> PR snapcraft#888 opened: Always respect go-buildtags <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/888>
#snappy 2016-11-05
<andywork> hey what do I need to do to include the libs from libasound2 into my snap package?
<andywork> I have it declared under "stage-packages:" but somehow it is not bundled into the snap
<mpounta> Hello, does anyone know if there is a related channel to ubuntu-core? :)
<jdstrand> ogra_: thanks for the bbb image-- I reflashed my bbb and it is working great! :)
<jdstrand> $ snap list
<jdstrand> Name               Version       Rev  Developer  Notes
<jdstrand> bbb                16.04-1       1    ogra       -
<jdstrand> core               16.04.1       396  canonical  -
<jdstrand> linux-generic-bbb  4.4.0-46-1    6    ogra       -
<jdstrand> ufw                0.36pre-16.3  3    canonical  -
<|zno> I'm having problems with installing snaps in LXC. Does any one have experience with this?
<|zno> Its a Privileged LXC
<stgraber> |zno: yeah, that's not going to work. Snaps need to be able to mount squashfs and setup apparmor and seccomp policies.
<stgraber> |zno: it will very soon be possible to reliably install snaps inside unprivileged containers though as support for apparmor stacking is now in the Ubuntu kernel (with a few last bugs being looked at), but that feature will not be available to privileged containers
<stgraber> jjohansen (apparmor developer) is working on fixing what's hopefully the last blocking issue with running snaps, once that's fixed and pushed to the Ubuntu kernels, I'll publish a blog post explaining how to get everything working so you can install snaps in containers
<|zno> stgraber, Ok thanks... Maybe it's time to have a look at LXC. (But to move my lxcs... maybe in 4,5 years ;) )
<|zno> jjohansen, nice, wheres the blog?
<|zno> And I ment LXD ...
<stgraber> |zno: it's going to be on my personal blog (https://www.stgraber.org) as I've got quite a lot of LXD posts there already, but it's syndicated on Planet Ubuntu and usually picked up by ubuntu.com too, so should be pretty visible once it gets out :)
<|zno> stgraber, Ok, thanks for the info. I will definitely have a look at your blog then.
<brenda> hi there
<brenda> just installed core 16 on a raspberry pi 3, screen and keyboard are attached and I get the login prompt
<brenda> but the default user/password ubuntu/ubuntu won't work
<brenda> anybody have an idea?
<brenda> ssh with the ubuntu one ssh key doesn't work either
<ogra_> brenda, how do you try to ssh ? and do you have the secret key on the machine you try to ssh from ?
<ogra_> local logins are disabled by default but after ssh'ing in you can run "sudo passwd $USER" and can set a password for a local login
<brenda> hi there
<brenda> i generated the key on my laptop, copied the pub content to ubuntu one, set up the box, it only requested the registered email address
<brenda> entered that and then the box sits at the prompt
<brenda> i then used ssh ubuntuonename@ip
<brenda> i didnt set a passphrase, so I shouldn't need to enter a password
<brenda> so i just hit enter but the login fails
<brenda> i'm using the nextcloud box with the RP3 by the way
<Pharaoh_Atem> elopio: yay, the unit tests pass
<Pharaoh_Atem> now I just have to wait for the integration tests to finish and turn the checkmark green :D
<digitalcoder> hi !
<digitalcoder> plz wanna get the default login/pass firstboot Snappy Ubuntu Core on Raspberry Pi 2
<digitalcoder> could U help me ?
<femme> are there going to be vagrant images of the new ubuntu core 16?
#snappy 2016-11-06
<monkey> hi guys, i have installed ubuntu core on my rpi2 and it works! thx for that.
<monkey> i also tried a next step for me, snap install docker and it seems that this worked too
<monkey> but now i wonder how to use docker there? docker info just says "Cannot connect to the Docker daemon. Is the docker daemon running on this host?"
<monkey> ps -ax | grep docker  8274 ?        Rsl    0:00 docker daemon --debug --log-level=debug --exec-root=/var/snap/docker/51/run/docker --graph=/var/snap/docker/common/var-lib-docker --pidfile=/var/snap/docker/51/run/docker.pid
<monkey> so it seems taht docker is running, but i dont know how to connect to it
<monkey> does someone have a hint?
<monkey> another thing that seems strange is that the docker pid is changing permanently.. it think docker has its problems to run on my rpi2, where are the logs of that?
<Guest59172> Hello. Does someone know how to allow a snap to use special /dev/file ? My program just stops when it tries to access /dev/vcio and this is what snappy-debug tells me: http://pastebin.com/6gB7U2i1
<wolflarson> hello!
<mup> Bug #1639603 opened: Unable to access documents when /home/user/Documents is a symlink <Snappy:New> <https://launchpad.net/bugs/1639603>
<mup> Bug #1639614 opened: Sandbox denials with snap using thumbnailer <Snappy:New> <https://launchpad.net/bugs/1639614>
<mup> Bug #1639646 opened: Unable to login for first time <Snappy:New> <https://launchpad.net/bugs/1639646>
#snappy 2017-10-30
<Guest65397> hi
<mvo> hey zyga-ubuntu! good morning
<zyga-ubuntu> hey mvo
<zyga-ubuntu> sorry, a bit stiff
<zyga-ubuntu> I decided to move back to the office
<mvo> zyga-ubuntu: no worries - reviews for the 2.29 targeted PRs would be great
<zyga-ubuntu> mvo: ack
<mup> PR snapd#4098 closed: snap-confine: allow reading uevents from any where in /sys <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4098>
<zyga-ubuntu> mvo: btw, I think we can close the 2.28 milestone now
<zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/4095
<mup> PR #4095: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4095>
<zyga-ubuntu> mvo: I think Pharaoh_Atem is 100% spot on here
<zyga-ubuntu> mvo: shall I spend a while to make the copyright file non-fake today/
<zyga-ubuntu> mvo: I feel bad about this because debian/copyright is one of the most important parts of debian and ubuntu
<mvo> zyga-ubuntu: ok, but lets not block 2.29 on this as its not a regression
<zyga-ubuntu> mvo: tongue-in-cheek it is a regression since we started vendoring, we just get a free pass to ignore that in ubuntu, it seems
<zyga-ubuntu> mvo: I'll get to work :)
<mvo> zyga-ubuntu: not a regression comapred to 2.28
<mvo> zyga-ubuntu: but yeah, I think we are in agreemeent
<mup> PR snapd#4095 closed: debian: make packaging/ubuntu-14.04/copyright a real file again <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4095>
<zyga-ubuntu> sanity timeout expired: Interrupted system call
<zyga-ubuntu> mvo: 6 seconds not enough?
<mvo> zyga-ubuntu: I don't know what is going on :(
<zyga-ubuntu> mvo: maybe we should not hold that lock on this long
<mvo> zyga-ubuntu: makes me unhappy because it may mean we will run into autopkgtest issue on the distro
<zyga-ubuntu> mvo: I wish I could reproduce this
<mup> PR snapd#4096 closed: spread: welcome bionic beaver <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4096>
<mvo> zyga-ubuntu: thanks for your merges. I cherry pick in parallel to 2.29
<zyga-ubuntu> ah, wait
<zyga-ubuntu> 2.29~rc2 had the 6 second timeout change
<mup> PR snapd#4099 closed: merge 2.29~rc2 release back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4099>
<zyga-ubuntu> so maybe that was still on the 3 second one
 * mvo nods
<mup> PR snapd#4097 closed: interfaces/many: miscellaneous updates based on feedback from the field <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4097>
<zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/4078
<mup> PR #4078: tests: new test to check interfaces after reboot the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4078>
<mvo> zyga-ubuntu: I thin for this one we need a 2.29 PR - 11 commits
<zyga-ubuntu> mvo: we need the code to update mount units in the field, right?
<zyga-ubuntu> mvo: yes, I was thinking the same thing after not squash merging it
<zyga-ubuntu> mvo: I'll make one
<mvo> zyga-ubuntu: is that the right PR number? but yeah we need this code to update the mount units in the fields but I think it should not block 2.29, no regression and 2.30 can have it
<zyga-ubuntu> mvo: hmm, not sure, it's a serious bug that can stop people from operating servers
<mvo> zyga-ubuntu: if we have a fix ready quickly it can be considered, in the meantime the workaround is to reinstall snapd 2.29 and things will work
<mup> PR snapd#4101 opened:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4101 is the backport
<mup> PR #4101:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
<zyga-ubuntu> mvo: I don't have a fix handy, let me see if there's a simple way to make that
<zyga-ubuntu> ouch
<zyga-ubuntu> man
<zyga-ubuntu> back.hurt()
<mvo> zyga-ubuntu: :( good luck
<mvo> zyga-ubuntu: don't get me wrong, we want to fix that. but we also need to release and there is a reasonable workaround (dpkg --purge snapd ; apt install snapd) that we can release-note
<zyga-ubuntu> mvo: purging sytem state
<zyga-ubuntu> that's not a reasonable solution IMO
<zyga-ubuntu> (disrupts production)
<mvo> zyga-ubuntu: well, for people who are affected by the bug there is no system state because snapd did not work
<mvo> zyga-ubuntu: and for the people who are not affected there is nothing to do
<mvo> zyga-ubuntu: alternatively we could do something trivial in the trusty postinst?
<mvo> zyga-ubuntu: like "sed s/[Unit]\n.../fix/"
<mup> PR snapcraft#1646 opened: sources: enforce default language in subversion info <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1646>
<zyga-ubuntu> mvo: not really, it's something that is broken but not each time
<zyga-ubuntu> mvo: yeah
<zyga-ubuntu> mvo: the postinst idea is not too shabby :)
<mvo> zyga-ubuntu: unrelated question, if I have a snapName and a plugName, is there an easy way to check if that is connected (ie what api should I use for this)?
<zyga-ubuntu> let me see
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> mvo: you can use repo.Plug(snapName, plugName).Connections
<zyga-ubuntu> mvo: what are you making? :)
<zyga-ubuntu> mvo: on that note: http://turnoff.us/geek/what-your-code-looks-like/
<mvo> zyga-ubuntu: thank you! I work on snapd-control attributes, things get a bit messy because snapd control cannot import ifacestate nor does it have access to ifacemanager. I guess I think to think a bit how to cleanly untangle this
<zyga-ubuntu> snapd-control attributes?
<mvo> zyga-ubuntu: repo is initialized from the state?
<zyga-ubuntu> yes
<mvo> zyga-ubuntu: could I use it outside of ifacemanager?
<zyga-ubuntu> the repository?
<mvo> zyga-ubuntu: like what we did with configstate
<mvo> zyga-ubuntu: yes
<zyga-ubuntu> yes
<zyga-ubuntu> I think so
<mvo> zyga-ubuntu: cool
<zyga-ubuntu> though locking
<mvo> zyga-ubuntu: thats ok, the state lock should do it for us, no?
<zyga-ubuntu> the ifacestate has an API that returns the repo
<zyga-ubuntu> yes, the repo also has its own locking
<mvo> zyga-ubuntu: so I guess I could move the repo/state code into ifacestate/repo and import that from both ifacestate and snapstate?
<mvo> zyga-ubuntu: I imagine we will have more cases where a certain decision in snapstate is based on an interface connection
<zyga-ubuntu> mmmm
<zyga-ubuntu> move the interfaces/repo code to ifacestate?
<zyga-ubuntu> unless that's really necessary I'd rather not move it, it's a huge change that would just be painful to do (unless we must)
<mvo> zyga-ubuntu: there are bits that initialize repo from state, no?that live in ifstate right now?
<zyga-ubuntu> yes, those live in ifacestate
<mvo> zyga-ubuntu: I am thinking about just moving that small part into something that I can import from snapstate
<zyga-ubuntu> ah
<zyga-ubuntu> can you import ifacestate from snapstate?
<zyga-ubuntu> I guess no, recursive
<mvo> zyga-ubuntu: no, circular
<zyga-ubuntu> drat
<zyga-ubuntu> well, have a look
<mvo> zyga-ubuntu: thats why I'm thinking about this split
<mvo> zyga-ubuntu: it worked very well in configstate
<zyga-ubuntu> I think the overlord split is bogus
<zyga-ubuntu> because of go rules
<zyga-ubuntu> they should all be able to access each other
<zyga-ubuntu> but golang
<mvo> zyga-ubuntu: yeah, its a bit annoying
<pedronis> mvo: well the usual approach is  snapstate needs a predicate from othe *state, is for *state to set a hook on snapstate
<pedronis> mvo: that's how we do some of the install checks
<pedronis> and hi
<mvo> pedronis: good morning
<mvo> pedronis: yeah, I think it makes sense. especially now that I looked a bit closer it seems there is nothing that can easily be extracted
<mvo> zyga-ubuntu: -^
<zyga-ubuntu> mvo: that's a good way to solve it, thank you for the insight pedronis!
<pedronis> mvo: you might to anyway stick the repo in the state cache (as we do for store and assertion db), I think it's only on the manager so far
<pedronis> *might need
<pedronis> mvo: unrelated, not super urgent question, what's the state of the work to support default-provider to install things like for base? I remember we discussed this at the really, but didn't any relevant PRs or merges, did IÂ miss something
<pedronis> s/really/rally/
<mvo> pedronis: the default-provider should be in, let me double check, I worked on this during the sprint
<mvo> pedronis: yeah, the repo in the manager is a bit problematic with the callback approach we are using. the callback works, I did a prototype but it shows the problem (NewInterfaceManager sets the snapstate.PlugConnected() which feels wrong)
<pedronis> we set  callbacks that way for isolation between tests
<zyga-ubuntu>  mvo: maybe just expose the repository instead of one methof?
<pedronis> but I see it also "solves" the repo in manager issue
<pedronis> mvo: I'm very confused IÂ don't see any mentions of default-provider in the code?  am IÂ looking at the wrong places?
<mvo> pedronis: let me check
<zyga-ubuntu> mvo: I think that didn't land as well
<zyga-ubuntu> mvo: I saw PRs but I don't think we merged it
<pedronis> mvo: for context, I'm interested in that because of the discussion about what the new install/refresh API should support returning
<pedronis> mvo: at the rally we discussed always getting snap_yaml_raw for this?
<mvo> pedronis: yeah https://github.com/snapcore/snapd/compare/master...mvo5:default-plugin-provider?expand=1 is what I have
<mvo> pedronis: and indeed it looks like its not merged not even proposed :(
<mup> PR snapd#4090 closed: interfaces/mount: exspose mount.{Escape,Unescape} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4090>
<mup> PR snapd#4091 closed: cmd/snap-update-ns: allow fault injection to provide dynamic result <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4091>
<pedronis> mvo: ah, ok,  are you planning to work on more that?Â or did you it  a blocker? or just shifted priorities?
<pedronis> *hit a blocker
<mup> PR snapd#4074 closed: partition/ubootenv: don't panic when uboot.env is missing the eof marker <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4074>
<pedronis> mvo: either it's an important datapoint for the new api if we always need the full yaml in advance
<mup> PR core#62 closed: create xdg-settings inside the core snap <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/62>
<mvo> pedronis: I will pick it up again, it just go lost in $stuff :(
<pedronis> ok, thank you
<zyga-ubuntu> mvo: I can now help smoke testing releases with a nvidia GPU
<ackk> Chipaca, hi, any chance you could take a look at https://github.com/snapcore/snapd/pull/3916 ?
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<Chipaca> ackk: yes! thank you for reminding me
<ackk> Chipaca, np, thanks for looking into it :)
<zyga-ubuntu> ackk: small feedback from me
<zyga-ubuntu> whee, we are at 19PRs
<mup> PR snapd#3976 closed: snap-confine: Support biarch Linux distribution confinement <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3976>
<pedronis> Chipaca: hi, did you see the invitation from Facu to discuss about the new APIs later today?
<Chipaca> pedronis: hiya
<Chipaca> pedronis: yes
<Chipaca> at my half three
<zyga-ubuntu> pstolowski: I'm adding questions to 4013
<pstolowski> zyga-ubuntu, yep, thanks, looking/answering
<zyga-ubuntu> ogra_: can we have some tests for snapcore/pi3-gadget
<zyga-ubuntu> ogra_: enough to see that in "snapcraft" builds
<zyga-ubuntu> ogra_: and that yaml is valid
<ackk> zyga-ubuntu, thanks, how do I add a spread test?
<zyga-ubuntu> ackk: look at tests/main/
<zyga-ubuntu> ackk: add a snap to tests/lib/snaps that shows this feature
<ackk> ah cool, thanks
<zyga-ubuntu> ackk: and add a directory to tests/main/ with task.yaml
<zyga-ubuntu> look around for ideas, there are plenty of things there
<zyga-ubuntu> if you need help just ask please
<ackk> ok, thanks
<Chipaca> anybody remember the limit on snap name length?
<ackk> zyga-ubuntu, how can I run a single spread test locally?
<Chipaca> ooh, pr updated mid-review
<Chipaca> auch
<zyga-ubuntu> ackk: you need a qemu image
<zyga-ubuntu> ackk: put it in .spread/qemu
<zyga-ubuntu> ackk: you can get some from https://spread.zygoon.pl/
<zyga-ubuntu> then you can run spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest
<ackk> and where do I get spread ? :)
<zyga-ubuntu> ackk: go install snapcore/spread/cmd/spread
<zyga-ubuntu> (you may need deps)
<zyga-ubuntu> well
<zyga-ubuntu> ackk: go install github.com/snapcore/spread/cmd/spread
<zyga-ubuntu> once you actually run spread locally do this:
<zyga-ubuntu> SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/mynewtest
<zyga-ubuntu> this is more friendly
<Chipaca> ackk: alternatively "curl https://niemeyer.s3.amazonaws.com/spread-amd64.tar.gz  | tar xzv" if you trust that guy
<zyga-ubuntu> oh, nice Chipaca ! :)
<ackk> heh
<Chipaca> ackk: also: read the HACKING.md
<ackk> zyga-ubuntu, Chipaca thanks
<zyga-ubuntu> ackk: run something else, just run all of main tests to ensure things work
<Chipaca> ackk: zyga's spread.zygoon.pl images save you the adt step which can be slow
<zyga-ubuntu> I need to refresh those :)
<zyga-ubuntu> https://github.com/zyga/spread-qemu-images
<Chipaca> ackk: half a review up
<ackk> Chipaca, thanks
<zyga-ubuntu> Chipaca: can you please look at 4092
<zyga-ubuntu> it's small and it's my last blocker
<Chipaca> zyga-ubuntu: i'll take a look
<zyga-ubuntu> Thank you :)
<Chipaca> i need to go out for a bit real soon otherwise i won't be back in time for the standup
<ogra_> zyga-ubuntu, well, buildign in snapcraft tests the yaml automatically ... i'll see what i can do, a simple travis test should surely be easy
<zyga-ubuntu> ogra_: yeah, that's what I was thinking about
<zyga-ubuntu> ogra_: thank you! :)
<ogra_> np
 * zyga-ubuntu break, back hurts too much today
<zyga-ubuntu> pstolowski: can you do a 2nd trivial review on 4013
<zyga-ubuntu> er
<zyga-ubuntu> :D
<zyga-ubuntu> not on 4013
<zyga-ubuntu> on 4092
<pstolowski> zyga-ubuntu, sure, will do when back from lunch
<ackk> zyga-ubuntu, the command line you gave me seems to be executing a whole bunch of tests, not just mine
<zyga-ubuntu> pstolowski: thank you
<zyga-ubuntu> ackk: can you paste your command?
<ackk> oh, wait
<ackk> I think my task.yaml is wrong
<zyga-ubuntu> brb
<zyga-ubuntu> re
<zyga-ubuntu> mvo, Chipaca, pstolowski, pedronis: heads up, standup is one hour earlier now
<ogra_> zyga-ubuntu, https://travis-ci.org/ogra1/pi3-gadget
<ogra_> FYI
<ogra_> (i have other branches i want to land first, before merging this in)
<zyga-ubuntu> checking
<zyga-ubuntu> ogra_: whee, nice!
<zyga-ubuntu> ogra_: maybe make apt installs less verbose
<zyga-ubuntu> or use some trick to fold-hide it
<zyga-ubuntu> but very nice indeed :)
<ogra_> well, if it doesnt fail, does anyone actually read the logs ?
<ogra_> (and if it fails you probably want to see all of it anyway)
<ogra_> i have a template ;) that makes it quick
<zyga-ubuntu> ogra_: the fold makes it both available and out of one's way
<ogra_> (clicking around in webforms to enable travis for that tree took longer than adjusting the travis.yml)
<zyga-ubuntu> ogra_: do you know of the travis CLI?
<ogra_> CLI ? nah, never needed it
<ogra_> but i'll look inot the folding ... and land the branch once i have all the splash branches in (i dont want to have to re-merge them with master)
<zyga-ubuntu> thank you :)
<ogra_> np
<ogra_> will take a bit though ... i have meetings the next few hours
<zyga-ubuntu> mvo, pstolowski: standup
<pstolowski> oh
<zyga-ubuntu> on the unpacking-my-backup-tarball side, gnome-boxes has terrible habit of naming each new VM "unknown"
<zyga-ubuntu> I need to jump into those images and see what's what
<zyga-ubuntu> silly silly gnome boxes
<zyga-ubuntu> especially since you can name them in the UI already but that is just ignored
<mvo> zyga-ubuntu: sorry, missed it due to lunch,
<mvo> zyga-ubuntu: did it happen? DST change got me
<Chipaca> mvo: yes
<Chipaca> mvo: done and dusted
<Chipaca> mvo: you get to do all the things now \o/
<mvo>  /o\
<Chipaca> ackk: i hope my review didn't come across as overly harsh. Overall it's good! and thank you for doing that.
<cachio> mvo, hi
<cachio> there were some changes introduced in 2.29
<cachio> mvo, is it ready for a new run or I should wait?
<mvo> cachio: I was waiting if the CE test turns out anything unexpected. but if that is green I will push 2.29-final I think
<mvo> cachio: with the changes in 2.29, all very small and targeted
<cachio> mvo, ok
<zyga-ubuntu> mvo: yes, it happened
<zyga-ubuntu> mvo: no worries, it was bound to affect someone
<zyga-ubuntu> mvo: what about https://github.com/snapcore/snapd/pull/4101
<mup> PR #4101:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4101>
<mvo> cachio: do we have results from the automated testing yet?
<cachio> mvo, for the last changes?
<mvo> zyga-ubuntu: \o/
<mvo> cachio: for the beta core from friday
<mvo> zyga-ubuntu: thank you
<cachio> mvo, it is completed
<cachio> mvo, my part
<mvo> cachio: right, I mean, did we get feedback from the CE team about their automated testing yet?
<mup> PR snapd#4101 closed:  interfaces/many: miscellaneous updates based on feedback from the field (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4101>
<Chipaca> zyga-ubuntu: did we ever do thing so apps could use /run/ ?
<cachio> mvo, no yet, their jobs are testing the last changes
<cachio> mvo, I'll ask again
<zyga-ubuntu> mvo: thanks
<zyga-ubuntu> Chipaca: can you be more specific? see /run? write anything to /run?
<cachio> mvo, the automated test should be executed but they didn't report that because there were some extra chnages after
<mvo> cachio: hm, hm, would be nice to know if there was an issue or not. do you think you could find this out?
<mvo> cachio: once we know that I will do a new 2.29
<cachio> mvo, I just sent an email
<mvo> ta
<mup> PR snapd#4102 opened: tests: refactor and expand content interface test <Created by zyga> <https://github.com/snapcore/snapd/pull/4102>
<cachio> spineau, hey
<cachio> spineau, do you have the results for the build that was pushed on Friday?
<spineau> cachio: in a meeting, wil lcheck
<cachio> spineau, sure, tx
<ackk> Chipaca, no worries. haven't had time to go through all your feedback, but thanks for looking into it
<ackk> Chipaca, wrt allowing other paths for unix sockets, I think the idea is to have an initial implementation than can be later expanded. but you might want to check with niemeyer about what paths we need to support
<Chipaca> zyga-ubuntu: create a file in /run/ (say /run/snap.<snapname>.blah)
<Chipaca> ackk: niemeyer is away this week
<ackk> Chipaca, i see
<Chipaca> ackk: my problem with SNAP_DATA and SNAP_COMMON is that people have already come into issues with that
<Chipaca> (it's too easy to hit the length limit)
<ackk> I see
<pedronis> Chipaca: I agree that having people to have to repeat the snap name is problematic, otoh IÂ don't see getting a decision/discussion without niemeyer around
<Chipaca> to make things worse, systemd just ignores the entry if it's too long
<pedronis> otoh other snaps need to know the name too
<pedronis> so that's  a problem either way
<pedronis> s/other snaps/consuming side software/
<pedronis> I suppose one question is how does this mesh with the content interface from a offering/consuming pov
<Chipaca> pedronis: agreed about decision/discussion needing gustavo
<Chipaca> pedronis: and i wouldn't block this work on this point
<zyga-ubuntu> Chipaca: hmmm, not sure, I'll check and get back to you
<cachio> mvo, so far for the Friday release there are not issues from Cert
<cachio> just missing some results from one device
<kyrofa> snappy-m-o, autopkgtest 1642 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> sergiusens, elopio kalikiana I have another meeting this morning, I may be late. Please start without me if I'm not there
<cachio> zyga-ubuntu, any idea why it could happened? "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied"
<cachio> I am running with sudo
<pedronis> Chipaca: fun, seems one of the test helpers in store_test was doing the wrong check since a while
<zyga-ubuntu> cachio: 3.14?
<zyga-ubuntu> cachio: if this is a 14.04 VM
<cachio> zyga-ubuntu, yes
<cachio> a jenkins one
<zyga-ubuntu> cachio: it's runnin the trusty kernel still, you need to reboot it to get a xenial kernel
<cachio> zyga-ubuntu,  I'll try that, tx
 * zyga-ubuntu -> lunch
<Chipaca> pedronis: wrong how?
<elopio> kalikiana: sergiusens: I'm alone. Are you coming?
<pedronis> Chipaca: didn't check what it was supposed to check, seems no test was affected after fixing but a bit worrying
<zyga-ubuntu> re
<mup> PR snapcraft#1587 closed: lifecycle: clean after deleting container <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1587>
 * Pharaoh_Atem blinks
<Pharaoh_Atem> apparently I was mentioned over the weekend?
<Pharaoh_Atem> or at least earlier today
<Pharaoh_Atem> zyga-ubuntu: oh, you mentioned me over debian/copyright
<Pharaoh_Atem> the only reason no one has *cared* thus far is because it's unbundled in Debian
<Pharaoh_Atem> otherwise it'd be rejected all the time
<zyga-ubuntu> Pharaoh_Atem: I'll fix this soon, this is now bugging me too
<zyga-ubuntu> how are you doing?
 * Pharaoh_Atem sighs
<Pharaoh_Atem> I'm so busy and tired
<Pharaoh_Atem> I have had no time lately to evaluate what to fix in snapd selinux policy
<Pharaoh_Atem> and adding the dnf backend to snapcraft is still on my todo
<zyga-ubuntu> Pharaoh_Atem: little by litte, I'm sick since yesterday, limping along slowly
<mup> PR snapd#4103 opened: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<mup> PR snapd#4092 closed: cmd/snap-update-ns: allow Change.Perform to return changes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4092>
<zyga-ubuntu> trivial logging PR ^
<mup> PR snapd#4104 opened: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/4104>
<zyga-ubuntu> actually ^
<pstolowski> zyga-ubuntu, i had your 4092 opened and was adding a comment, but it landed in the meantime and github rejected me :/
<pstolowski> zyga-ubuntu, i was wondering if the code you removed of Keep case shouldn't be moved into Perform() to make it explicit what happens on Keep - in case new code gets added there
<zyga-ubuntu> pstolowski: ah, sorry, I'm trying to push things forward
<zyga-ubuntu> pstolowski: I think you can still comment on the specific code
<zyga-ubuntu> pstolowski: as for Keep, you mean moving the return nil to Perfomr?
<zyga-ubuntu> *Perform?
<pstolowski> zyga-ubuntu, yes, `if action == Keep ... ` would make the intention readable
<zyga-ubuntu> pstolowski: I can squeeze that into the logging PR (4104)
<cachio> mvo, confirmed that Cert team did not find any issue in the Friday's build.
<mup> PR snapd#4105 opened: snap-seccomp: skip in-kernel bpf tests for socket() in trusty/i386 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4105>
<mvo> cachio: great, I just found one last issue on trusty/i386 and pushed a PR, once that is in we are good
<mvo> jdstrand: if you have a moment, a look at 4105 would be great.
<cachio> mvo, great
<mvo> jdstrand: last piece for the 2.29 release
<zyga-ubuntu> mvo: so are we getting a beta today?
<jdstrand> mvo: ack, done
<zyga-ubuntu> hey jdstrand, good day
<jdstrand> zyga-ubuntu: hello :)
<mvo> zyga-ubuntu: yeah, 2.29-final to beta and hopefully all the way to stable
<mvo> zyga-ubuntu: well, not today to stable :)
<zyga-ubuntu> mvo: fingers crossed
<zyga-ubuntu> let's hope this one is not another .8
<mvo> zyga-ubuntu: yes!
<mvo> zyga-ubuntu: and yes!
<mup> PR snapd#4106 opened: many: lookup and use the url from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<pstolowski> zyga-ubuntu, can you take another look at #4013?
<mup> PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
<kyrofa> elopio, how to I subscribe to autopkgtests again?
<elopio> snappy-m-o github subscribe 1643
<snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1643 ([WIP] tests: run daily autopkgtest in travis).
<mup> PR #1643: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1643>
<elopio> kyrofa ^
<kyrofa> snappy-m-o, github subscribe 1642
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1642 (tests: move the plainbox test to the integration suite).
<mup> PR #1642: many: pass device to store <Created by matiasb> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1642>
<kyrofa> Wait...
<kyrofa> Oh that was confusing
<kyrofa> Got it, thanks elopio :)
<zyga-ubuntu> snappy-m-o: make me a coffee
<snappy-m-o> Command ":" / ": make" not found.
<zyga-ubuntu> do I need to use sudo?
<ogra_> nah, fakeroot
<ogra_> (it is helloween ... you use costumes, not sudo)
<diddledan> haha. I like that
<ogra_> oh, this is lovely https://www.konsulko.com/yaml-and-device-tree/
<om26er> flexiondotorg: Hello! mind throwing some views on https://forum.snapcraft.io/t/classic-confinement-for-android-studio/2634 ?
<zyga-ubuntu> ogra_: that would give me a decaff coffee :D
<mup> PR snapd#4105 closed: snap-seccomp: skip in-kernel bpf tests for socket() in trusty/i386 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4105>
<zyga-ubuntu> ogra_: hell-o-ween?
<zyga-ubuntu> speaking about coffee
<zyga-ubuntu> I really want one now
<zyga-ubuntu> darn you
<mup> PR snapd#4107 opened: release: snapd 2.29 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4107>
 * Chipaca EODs
<sergiusens> is the forum down just for me?
<kyrofa> sergiusens, working for me
<sergiusens> hmmm
<kyrofa> sergiusens, no no, I lied
<kyrofa> It was working like three minutes ago when I visited this page though
<sergiusens> ok, I'll ask is
<sergiusens> kyrofa btw, have you seen what got moved to 2.35? :-)
<kyrofa> sergiusens, ah! I had not
<kyrofa> sergiusens, that's kind of a big change, you sure?
 * sergiusens relocates as he started that thinking internet had died and it was only the forum
<kyrofa> Hahaha
<sergiusens> kyrofa sort of needed to be able to properly release a no "patched" version which would work on pypi
<kyrofa> Ah ha
<sergiusens> kyrofa the big change is patchelf ;-)
<sergiusens> this is minor in comparison
<kyrofa> Oh man, that's 2.35? No kidding, let's land everything
 * sergiusens looks to the side at his time machine and wonders why it ain't working
<sergiusens> I just need time
<sergiusens> kyrofa well we cannot succesfully SRU if not
<sergiusens> unless we make it a snap only release, then let's do that now ;-)
<kyrofa> Oh, autopkgtests?
<sergiusens> yes
<kyrofa> Dang
<ogra_> hmm, is the forum down or is it me ?
<mvo> ogra_: hm, looks down indeed
<zyga-ubuntu> forum is down
<sergiusens> zyga-ubuntu yeah, look above
<sergiusens> zyga-ubuntu also asked is
<sergiusens> zyga-ubuntu but I have a suspicion it is not under their supervision
<cmars> is forum.snapcraft.io down?
<ikey> error: unknown command "oi-you-there", see "snap --help"
 * ikey tried
<cmars> duh, just read scrollback. ok, not just me :)
<zyga-ubuntu> ikey: hey, quick question, is there any delta you have left?
 * jdstrand also notices forum seems down
<ikey> zyga-ubuntu, erm i think all my PRs went in
<ikey> but ima need to rebase
<ikey> 2.28.5 i spose
<ikey> and see how things be
<ikey> im guessing 2.28.x wont have any of my PRs in it
<zyga-ubuntu> ikey: 2.28.x is stable now so would be good to have
<ikey> ack
<ikey> plus i want solus 4 to support snapd in the SC
<ikey> i.e. land my branch
<sergiusens> elopio kyrofa so you think patch the world and pip as package should go to 2.36? If so, let's get this process started
<kyrofa> sergiusens, your call, but it's already a pretty good-sized release
<kyrofa> We're still battling autopkgtest anyway
<sergiusens> kyrofa let's do it then, we can navigate the SRU, it won't be more broken than before
<sergiusens> kyrofa only for artful+
<kyrofa> sergiusens, good deal
<elopio> yes, please release :)
<sergiusens> kyrofa still, focus on that PR, if we need a small 2.36 with only the elf and this stuff so be it
<kyrofa> sergiusens, alrighty
<sergiusens> kyrofa for which, dig deep into it ;-) Maybe just enable the failing tests on travis if that is the problem and see if it all works when ran on itself
<kyrofa> sergiusens, I'm assuming we're talking about the BlockingIOError issues? Yeah I'm launching into subprocess
<kyrofa> Launching myself, I mean. I guess that was ambiguous :P
<kyrofa> Giving preference to autopkgtests though, we have a few PRs in flight that hopefully greenify them
<kyrofa> Work should be done though
<sergiusens> kyrofa yes, exactly that
<sergiusens> kyrofa which PRs?
<kyrofa> snapcraft#1642
<mup> PR snapcraft#1642: tests: move the plainbox test to the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1642>
<kyrofa> and snapcraft#1644 I think (right elopio?)
<mup> PR snapcraft#1644: lxd: fix the push in container builds <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1644>
<kyrofa> Definitely the first though
<sergiusens> kyrofa oh, those two, yeah
<sergiusens> been waiting on those to be green for most of the day today
<kyrofa> *sigh*
<sergiusens> forum is back everyone
<sergiusens> kyrofa this seems to down your alley https://forum.snapcraft.io/t/encountering-problems-when-packaging-rviz/2659
<kyrofa> sergiusens, yeah he emailed me first, I asked him to post on the forum-- I'm all over it
<kyrofa> Unfortunately the forum went down moments afterward, so of course our conversation continued over email :P
<sergiusens> seems simple enough to solve, but getting an idea of why it didn't feel like the tool to solve the problem could be taken back in as feedback
<kyrofa> Couldn't agree more
<kyrofa> Perfect timing too, as we're revamping errors
<sergiusens> kyrofa also for you LP: #1728481
<mup> Bug #1728481: CXX_Flags not generated properly for catkin plugin <catkin-plugin> <snapcraft> <Snapcraft:New> <https://launchpad.net/bugs/1728481>
<kyrofa> Yeah I saw that, I'll look into it after this
<mup> PR snapd#4107 closed: release: snapd 2.29 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4107>
<jdstrand> stgraber: hey, not sure you saw but if you plugs system-observe with the lxc command, this denial will go away (in 2.29+): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=16717 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<stgraber> jdstrand: I saw your earlier ping, but that doesn't make any sense
<stgraber> jdstrand: the only thing that snap.lxd.lxc does is call aa-exec -p unconfined
<stgraber> jdstrand: after that we don't have any apparmor confinement, so I'm confused as to why we'd trigger that denial in the first place
<stgraber> jdstrand: also, that denial is listed under "snap-exec", not "lxc"
<mwhudson> jdstrand: (or anyone else) hey, does this look familiar at all? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880174
<mwhudson> "libGL error: No matching fbConfigs or visuals found" / "libGL error: failed to load driver: swrast" on debian with nvidia
<mwhudson> ah it's also here https://forum.snapcraft.io/t/debian-and-nvidia-issue/2583
<mup> PR snapcraft#1642 closed: tests: move the plainbox test to the integration suite <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1642>
#snappy 2017-10-31
<mup> PR # closed: snapd#3734, snapd#3916, snapd#3963, snapd#3992, snapd#3994, snapd#3998, snapd#4013, snapd#4040, snapd#4049, snapd#4059, snapd#4063, snapd#4064, snapd#4068, snapd#4073, snapd#4076, snapd#4078, snapd#4100, snapd#4102, snapd#4103, snapd#4104, snapd#4106
<mup> PR # opened: snapd#3734, snapd#3916, snapd#3963, snapd#3992, snapd#3994, snapd#3998, snapd#4013, snapd#4040, snapd#4049, snapd#4059, snapd#4063, snapd#4064, snapd#4068, snapd#4073, snapd#4076, snapd#4078, snapd#4100, snapd#4102, snapd#4103, snapd#4104, snapd#4106
<Son_Goku> that's... a lot of pulls
<zyga-ubuntu> good morning
<zyga-ubuntu> man, it's a nice and sunny 1C day over here :)
<zyga-ubuntu> quiet day...
<zyga-ubuntu>  /exit
<zyga-solus> one IRC is enough today
<mup> PR snapd#4108 opened: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<zyga-solus> pstolowski: hey, thank you for 4108
<zyga-solus> pstolowski: do you think you could write some text in the PR description to help reviewers understand what is going on more clearly?
<pstolowski> zyga-solus, added a few more info to the second paragraph of the description, not sure if there is anything else unclear (the link to the forum topic is also helpful)
<zyga-solus> pstolowski: "add new data types for connected plugs/slots"?
<zyga-solus> this is a bit terse for ~1K diff
<pedronis> pstolowski: hi, what's blocking #4013 ?
<mup> PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
<pstolowski> zyga-solus, see pt. 5 of the plan
<zyga-solus> pstolowski: I think that kind of stuff should be in the PR
<pedronis> it will not be that big in 4013 gets in
<pedronis> s/in 4013/if 4013/
<pstolowski> zyga-solus, ah, sorry. i was still referring to the description of 4013. you're talking about 4108.
<zyga-solus> pstolowski: yes, sorry :)
<pstolowski> zyga-solus, will expand it, yes
<zyga-solus> thank you!
<pstolowski> pedronis, i hope three is nothing blocking 4013 once zyga-solus approves
<pedronis> pstolowski: tests are red though?
<zyga-solus> I will look at 4013 soon
<pstolowski> pedronis, linode:ubuntu-core-16-64:tests/main/snap-seccomp failed, 1369 passed, 1 failure. it failed on matching libs with ldd.
<pstolowski> pedronis, will restart them
<pstolowski> zyga-solus, and yes, as pedronis said, 4108 will actually be small
<pedronis> no mvo today?
<zyga-solus> pedronis: no, he is off today and tomorrow
<pedronis> ah
<ogra_> pedronis, germany is celebrating nailing of paper to a church door today ...
<Son_Goku> ?
<pedronis> https://en.wikipedia.org/wiki/Reformation_Day  (I think)
<ogra_> Son_Goku, google martin luther ...
<Son_Goku> oh right
<Son_Goku> we don't recognize it in the USA
<Son_Goku> but I knew it was a thing
<ogra_> the northern parts of germany are all protestant (that is why we complain so much i guess)
<pedronis> Chipaca: hi, a review of #4106 would be appreciated when you have time
<mup> PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<zyga-solus> man, logging
<zyga-solus> on the upside I get to the point where tmpfs is usable
<zyga-solus> but I found another place where logging breaks
<zyga-solus> and what I do now feels like laying a set of extension cords across the stac k
 * zyga-solus lunch
<jdstrand> mwhudson: there have been a lot of issues with nvidia (re https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880174). I'm not sure who has been focusing on those issues lately. historically it's been zyga-solus and mvo iirc
<jdstrand> I know oSoMoN has been affected of late. I don't know if he has looked at it in depth
<zyga-solus> I think debian needs updates
 * sergiusens goes for a walk
<oSoMoN> jdstrand, IÂ have tried to get feedback from users with nvidia hw (I don't have any myself), but nothing conclusive so far
<flexiondotorg> om26er: Would you like to move Android Studio to Snapcrafters?
<om26er> sure @flexiondotorg
<flexiondotorg> Cool.
<flexiondotorg> Just reply on the fourm.
<flexiondotorg> Oops.
<flexiondotorg> I'm just replying on the forum :-)
<flexiondotorg> @om26er I've not used ANdroid Studio myself. Do you know if it interfaces with fastboot or adb?
<nothal> flexiondotorg: No such command!
<pedronis> Chipaca: standup?
<Chipaca> oh hello 2fa
<Chipaca> no not even 2fa
<om26er> flexiondotorg: it does ship adb/fastboot with it, yes.
<om26er> when you say "interfaces" is that in the terminologies of snapd ?
<om26er> (and sorry for the late reply, I was driving)
<flexiondotorg> om26er: Thanks. I suspected as much.
<flexiondotorg> Yes, in the forum post I am referring to snap interfaces.
<flexiondotorg> @om26er No problem. I just got round to this on my job list :-)
<nothal> flexiondotorg: No such command!
<om26er> flexiondotorg: replied.
<flexiondotorg> Cheers. I'll import it when you've had the chance to add the README :-)
<zyga-solus> cachio: so about debian, as I said I don't see the thing in sysfs but I didn't google or search in the kernel tree to see what makes that sysfs available
<cachio> zyga-solus, ok, I'll try to see what is missing
<Chipaca> pedronis: AFAICT we are not doing gzip
<zyga-solus> pstolowski: I'll get a coffee/tea and I'll do one more pass through 4013
<pedronis> Chipaca: is it worth it? something to look into?
<pedronis> at least for this API
<pstolowski> zyga-solus, thanks!
<Chipaca> pedronis: AFAICTÂ², golang's standard library doesn't do it -- i guess they figure you should just use http2?
<zyga-solus> jdstrand: I have a tmpfs+bindmount fallback now but I need to address a few shortcomings (files and broken undo)
<zyga-solus> jdstrand: I ran into a number of odd cases where denials are not logged
<zyga-solus> jdstrand: what do I need to do to enable that?
<pedronis> Chipaca: fun
<Chipaca> pedronis: there was something about https + gzip == bad, but i don't remember
<pedronis> Chipaca: https://en.wikipedia.org/wiki/BREACH ?
<zyga-solus> 21st century, the day where security exploits are commonplace but at least we give a random one cool name, icon and website
 * sergiusens is back
<Chipaca> pedronis: sounds like it
<Chipaca> zyga-solus: we are tribal animals; names and stories are how we learn
<pedronis> Chipaca: anyway not clear the attack is relevant for the content of here, anyway in this case the request doesnt' strictly need to be https, that's just our default
<Chipaca> zyga-solus: also punches to the face, but i'd rather names and stories
<zyga-solus> Chipaca: we need to paint those cave walls with shellcode
<zyga-solus> Chipaca: don't forget chanting and smoking various substances ;)
<Chipaca> zyga-solus: sshhh
<om26er> flexiondotorg: added the README, we can improve from there: https://github.com/om26er/android-studio-snap
<om26er> so whats the update story for this ? When a new version arrives would I need to notify snapcrafters ?
<sergiusens> stgraber do you know if that snapd/systemd nice issue is gone with the latest snapd requiring privileged containers?
<zyga-solus> pstolowski: about 4013, can you please add docstrings to all the new public things?
<pstolowski> zyga-solus, ok, doing
<zyga-solus> pstolowski: I'll provide ideas
<zyga-solus> pstolowski: if you wait ~20 min
<pstolowski> zyga-solus, let me push something, just let me know if you have better descriptions
<zyga-solus> kk
<zyga-solus> on the upside, I found the missing SNAPD_DEBUG bridge
<Facu> sergiusens, elopio, may I get re-reviews on this? https://github.com/snapcore/snapcraft/pull/1634  thanks!
<mup> PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634>
<Facu> roadmr, ^
<mup> PR snapcraft#1644 closed: lxd: fix the push in container builds <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1644>
<zyga-solus> pstolowski: done
<zyga-solus> and I fixed a silly bug in my code, swapped mount args :D
<jdstrand> zyga-solus: if there are explicit deny rules, prepend them with 'audit' to log them (eg: audit deny /path/to/... r,). or disable rate limiting: sudo sysctl -w kernel.printk_ratelimit=0
<zyga-solus> ah
<zyga-solus> rate limiting fixed it
<zyga-solus> thank you!
<zyga-solus> :)
<zyga-solus> man, I feel like turning the light on
<zyga-solus> working in the blind was annoying
<zyga-solus> jdstrand: so, any reason not to disable rate limiting in spread in general?
<jdstrand> zyga-solus: I thought we were. istr sending something up that did that
<zyga-solus> nope, I just got the logs to work when I ran the command myself
<zyga-solus> I'll include this as a RFC PR to consider
<jdstrand> zyga-solus: it is commented out of tests/lib/prepare.sh
<zyga-solus> I see
<zyga-solus> reading the forum
<zyga-solus> thank you, I'll check that out after this PR
<zyga-solus> jdstrand: do you hae time to look at one function today?
<zyga-solus> jdstrand: not a security review, just a sanity check
<jdstrand> zyga-solus: I can do that
<zyga-solus> jdstrand: can you please fetch my remote and look at feature/transparent-tmpfs, look at cmd/snap-update-ns/utils.go createWritableMimic
<roadmr> Facu: yay thanks!
<sergiusens> Facu we are trying to wrap up our 2.35 milestone, I've marked that as 2.36 so it might be something for next week
<stgraber> sergiusens: pretty sure the systemd SRU has been published
<Facu> sergiusens, perfect, thanks!
 * Chipaca needs to step out for a while, will bbl
<sergiusens> stgraber great, I will try and remove our workarounds for travis and see how it goes
<zyga-ubuntu> "cannot parse mountinfo of the current process
<zyga-solus> well
<zyga-solus> nobody said it would be boring :)
<zyga-solus> ha
<zyga-solus> found a cute mountinfo parsing bug now :)
<zyga-solus> but also, kernel is not hepful here :)
<kyrofa> elopio, how is autopkgtest looking this morning?
<kyrofa> snappy-m-o, autopkgtest 1583 xenial:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<elopio> kyrofa: I really really hope it's good. I'll update the one for adt-lxd, It's so close...
<kyrofa> Good deal. Everything I know about has been merged, so let's see...
<kyrofa> sergiusens, are you around? Can you create https://github.com/snapcraft-docs/ros2-talker-listener for me?
<sergiusens> kyrofa sure
<sergiusens> kyrofa done
<kyrofa> sergiusens, thank you!
<zyga-ubuntu> woot
<zyga-ubuntu> it works :D
<zyga-ubuntu> jdstrand: it works :)
<zyga-ubuntu> I'll break it down and start sending PRs up :)
<zyga-ubuntu> I also worked aournd an apparent kernel bug
<zyga-ubuntu> *around
<zyga-ubuntu> jdstrand: I found that mount() can be called with empty source and it will not be quoted in any way, resulting in weird (and harder to parse) mountinfo
<zyga-ubuntu> I now generate 'none' tmpfs so it's okay and no tools break but I will send a patch anyway
<zyga-ubuntu> after the cleanup I'll send my early tmpfs PR and start working on unit tests as there are none for the new code yet
<pstolowski> and now 4013 failed with error: cannot perform the following tasks:
<pstolowski> - Download snap "test-snapd-tools" (6) from channel "stable" (Get https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap: dial tcp 91.189.92.20:443: i/o timeout
<pstolowski> grr
<zyga-ubuntu> pstolowski: store woes
<zyga-ubuntu> we had a lot over weekend
<jdstrand> zyga-ubuntu: ack, cool
<zyga-ubuntu> jdstrand: small one for you https://github.com/snapcore/snapd/pull/4109
<mup> PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109>
<mup> PR snapd#4109 opened: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109>
<om26er> is there a way to refer the value gathered from `version-script` in snapcraft.yaml ? Think of $SNAPCRAFT_PROJECT_VERSION but for version-script
<om26er> sergiusens: ^
<om26er> So I think that might be a bug, hmm.
<zyga-ubuntu> pstolowski: hey, I also pushed https://github.com/snapcore/snapd/pull/4104 if you want to have a quick look, it's very short and simple
<mup> PR #4104: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/4104>
<pstolowski> zyga-solus, yep, looking
<zyga-ubuntu> thank you :)
<zyga-ubuntu> pstolowski: https://github.com/snapcore/snapd/pull/4109#discussion_r148051564 :-)
<mup> PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109>
<pstolowski> zyga-solus, thanks! reading
<zyga-ubuntu> pstolowski: if you think something is wrong please ask, maybe I'm confused myself
<zyga-ubuntu> offtopic, tests seem rapid today
<sergiusens> om26er no there isn't, it is for setting things, not reading
<om26er> sergiusens: I have a use case: I want to dynamically read the latest version number of my software from a server url (version-script is fine for that). I then want that same version to be used by my source url in the `dump` plugin.
<om26er> I would generally expect the value returned to from version-script to be exported as $SNAPCRAFT_PROJECT_VERSION not the fallback `version` that I have in place.
<om26er> my snap here could definitely use that: https://github.com/om26er/sublime-text-3-snap/blob/master/snap/snapcraft.yaml
<pstolowski> zyga-solus, i find it hard to digest it at this late hour tbh ;)
<zyga-ubuntu> pstolowski: no worries, it's not urgent :)
<zyga-ubuntu> thank you for looking
<zyga-ubuntu> cachio: hey, can you have a 2nd look at 4102 please?
<pstolowski> zyga-solus, is it possible for 2 adjacent fields to be empty like that?
<cachio> zyga-ubuntu, sure
<zyga-ubuntu> thank you :)
<pstolowski> zyga-ubuntu, , is it possible for 2 adjacent fields to be empty like that?
<zyga-ubuntu> pstolowski: I honestly don't know, this feels like a kernel bug
<zyga-ubuntu> pstolowski: the only case I encountered was tmpfs with "" mount source
<zyga-ubuntu> pstolowski: proc(5) doesn't mention this
<pstolowski> zyga-ubuntu, yes, that would be unexepected but i'm curious if it deserver a test for the behavior of the parser (i.e. make sure we don't crash)
<pstolowski> *deserves
<zyga-ubuntu> ah, sure, I can add more tests
<zyga-ubuntu> good idea
<pstolowski> thanks
<om26er> are build.snapcraft builders on maintenance of something ? My build haven't started for quite a bit.
<kyrofa> om26er, things tend to slow down when a new Ubuntu release opens
<kyrofa> elopio, all our tests use testtools nowadays, right? Is there a reason we're still running them with unittest?
<kyrofa> I'm digging into this weird BlockingIOError thing. It seems to be coming from unittest, particularly a section of it that has been re-implemented by testtools, but we
<kyrofa> 're not using testtools to run
<elopio> kyrofa all should be using testtools. Changing the runner sounds worth a try.
<kyrofa> elopio, alright, I'm trying it
<kyrofa> Just wanted to make sure I wasn't insane, thanks elopio :)
<sergiusens> om26er well, version-script is only analyzed after prime so that won't be possible anyways
<om26er> that's an implementation detail :) As a developer I expected $SNAPCRAFT_PROJECT_VERSION to behave differently.
<sergiusens> om26er well, the docs for version-script says it affects only the resulting metadata
<sergiusens> kyrofa if that's it, nice find
<kyrofa> sergiusens, no guarantees, testing now
 * zyga-ubuntu is too tired now
<zyga-ubuntu> back demands a break
<zyga-ubuntu> ttyl
<kyrofa> sergiusens, what I actually think is happening is that the test runners don't handle EAGAIN properly
<kyrofa> Which means we have a few options assuming testtools has the same issue: try to stay under whatever threshold we're hitting that's causing the EAGAIN, or fix the runner to handle it properly. It just so happens that one seems like a short-term fix and another seems like a long-term, so I'm looking into both
<sergiusens> got it
<stokachu> anyone seen this error before "- Run configure hook of "conjure-up" snap if present (run hook "configure": / not root-owned 66094:40918)."
<stokachu> this is from a snap install conjure-up --classic on arm64
<stokachu> wililupy: ^ is the one having the issue
<wililupy> stokachu: yes
<kyrofa> stokachu, yuck. jdstrand any idea what that ^ may be?
<jdstrand> kyrofa: I have not
 * sergiusens is commuting on a bus
<wililupy> kyrofa,jdstrand: I can give you access to the server if that helps?
<kyrofa> wililupy, sure, I'm curious. pubkey: https://pastebin.ubuntu.com/25860353/
<kyrofa> wililupy, what the heck is wrong with this machine :P
<kyrofa> $ ls -ld /
<kyrofa> drwxr-xr-x 24 66094 40918 4096 Oct 31 16:23 /
<kyrofa> wililupy, there's a weird mixture of that in / as well
<kyrofa> wililupy, bin looks good, but boot is weird, etc.
<genii-zombii> odd UID/GID
<kyrofa> Indeed
<kyrofa> wililupy, not sure what the deal is, but snap-confine barfs at it definitely
<kyrofa> Fix that up and I bet it'll start working
<wililupy> Thats good info. I'll try to re-install the OS and see what happens. I'll keep you posted. Thanks
<kyrofa> Sure thing
<kyrofa> stokachu, FYI ^
<jdstrand> kyrofa: probably 'owner' in the apparmor rules
<jdstrand> </guess>
<kyrofa> jdstrand, it's an explicit check in snap-confine
<kyrofa> jdstrand, ensuring the bpfpath is owned by root, presumably to ensure tampering would be difficult
<jdstrand> oh yes
<jdstrand> kyrofa: I should've remembered that from the error, but for some reason it didn't trigger in my head
<mup> PR snapd#4102 closed: tests: refactor and expand content interface test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4102>
<kyrofa> jdstrand, I imagine you have a few other things vying for space ;)
<jdstrand> heh
<om26er> sergiusens: Hey! Have you considered renaming telegram-sergiusens to telegram ?
 * Pharaoh_Atem sighs
 * zyga-ubuntu hugs Pharaoh_Atem 
<zyga-ubuntu> what's up?
<Pharaoh_Atem> I want proper SELinux support in snapd already :(
<zyga-ubuntu> I don't even know where to begin on that
<zyga-ubuntu> snap-confine should probably do something but that is a deep-dive sprint
 * zyga-ubuntu goes to fix his manual pages 
 * zyga-ubuntu tries to learn manual page syntax
 * zyga-ubuntu reads groff source code
<nacc> zyga-ubuntu: good luck :)
<zyga-ubuntu> nacc: man, what is .tmac?
<nacc> zyga-ubuntu: troff macros
<zyga-ubuntu> mmm
<zyga-ubuntu> I'm trying to understand why I'm getting a warning:
<zyga-ubuntu> mdoc warning: .Lb: no description for library `libkeep' available (#8)
<mup> PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy <Created by chipaca> <Merged by elopio> <https://github.com/snapcore/snapd/pull/8>
<nacc> silly mup
<nacc> zyga-ubuntu: can you pastebin the source?
<zyga-ubuntu> of the man page?
<nacc> zyga-ubuntu: yeah
<zyga-ubuntu> I'm a bit shy, it's my pet project
<zyga-ubuntu> the relevant part is
<zyga-ubuntu> .Sh LIBRARY
<zyga-ubuntu> .Lb libkeep
<nacc> zyga-ubuntu: does that possibly mean there is no libkeep manpage?
<zyga-ubuntu> that depends, it's in my source tree
<zyga-ubuntu> in section .3
<nacc> http://web.mit.edu/freebsd/head/contrib/groff/tmac/doc-syms
<nacc> it looks like it can't find it locally as it's running?
<nacc> ie d doc-str-Lb-\*[doc-arg\n[doc-arg-ptr]]
<zyga-ubuntu> aha, I probably need to install that
<zyga-ubuntu> I read that file but I didn't undetstand the syntax yet
<nacc> it's rough :)
<zyga-ubuntu> I found this by grepping, following from man source, looking for --warnings
<zyga-ubuntu> I use this command to run the "checker"
<nacc> zyga-ubuntu: ah, see `man groff_mdoc` for valid .Lb values
<zyga-ubuntu> PAGER=cat LANG='en_US.UTF-8' MANWIDTH=80 man --warnings -E UTF-8 -l keep_alloc_free.3 >/dev/null
<zyga-ubuntu> thank you
<nacc> zyga-ubuntu: you might need a mdoc.local?
<nacc> and need to defien a str-Lb-libkeep, i think
<zyga-ubuntu> yeah
<zyga-ubuntu> where does mdoc.local live?
<nacc> zyga-ubuntu: /etc/groff/mdoc.local apparently
<nacc> so that doesn't help you much :/
<zyga-ubuntu> well, man page looks ok, that's one I'm willing to ignore
<nacc> yeah
<zyga-ubuntu> thank you for teaching me about tihs
<zyga-ubuntu> *this
<nacc> zyga-ubuntu: np, learninng right alongside you :)
<kyrofa> Hrmm... setuptools masks output
<kyrofa> Er, I mean testtools
<kyrofa> Too many tools
<wililupy> kyrofa: I re-installed the OS and I was able to install conjure-up. Good thing too. There were a bunch of updates that system wasn't seeing as well.
<kyrofa> wililupy, good deal, yeah I imagine that would cause all sorts of issues
<kyrofa> wililupy, thanks for getting back to me!
<wililupy> kyrofa: np. thanks for the help.
<kyrofa> Of course
<stokachu> wililupy: good to hear!
<kyrofa> sergiusens, elopio testtools.run -h lies about the options supported-- there is no verbose mode :P
<kyrofa> Just look at this bug, how embarrassing https://bugs.launchpad.net/testtools/+bug/872906
<mup> Bug #872906: python -m testtools.run discover -v doesn't set verbosity <runner> <testtools:Triaged> <https://launchpad.net/bugs/872906>
<kyrofa> So we of course timeout
<kyrofa> The investigation continues
<elopio> kyrofa: we can easily make our own runner, printing whatever we want. For example, I combined some things from unittest and testtools to make the concurrent runner.
<sergiusens> oh well, you know, maybe thomi can give you some ideas on your issue
<thomi> I have been summoned!
<elopio> kyrofa also, once we move all the tests into snapcraft/tests, we don't need discover. We can just run the module.
<thomi> kyrofa: yeah, the 'discover' command is a bit of a hack, and ideally shouldn't be used on the command line
<kyrofa> Actually, thomi if you have a sec, could you give me your thoughts on the bug that's sucking the lifeblood out of me?
<thomi> sure thing
<kyrofa> https://bugs.launchpad.net/snapcraft/+bug/1717921
<mup> Bug #1717921: CI: BlockingIOError about 50% of the time <Snapcraft:Confirmed> <https://launchpad.net/bugs/1717921>
<kyrofa> thomi, note that the error always seems to come from unittest's runner
 * thomi reads
<kyrofa> thomi, I was hoping the testtools runner would fare better, but without verbose mode Travis just times out thinking it died
<thomi> kyrofa: Travis requires some output on stdout or it kills the job?
<kyrofa> thomi, yep
<kyrofa> Fun times
<kyrofa> There are ways to hack around it, but without output it's difficult to track progress as well
<thomi> huh, and the individual tests are longer than the timeout? Even in non-verbose mode, testtools will print a '.' after every test
<kyrofa> Some, yeah
<thomi> kyrofa: Are you able to point me to the code where you setup the subprocess calls? I think you're correct that this is related, and I suspect what's happening is that the Process stdout or stderr pipes are filling up
<kyrofa> thomi, most subprocess calls go through common.run{_output}, defined here https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/common.py#L66
<thomi> thanks
<kyrofa> thomi, we're using check_call or check_output though, each of which handle reading off their own stdout/stderr
<kyrofa> (at least I thought)
<thomi> hmmm, yes, it seems it should
<thomi> I was pretty sure there was a warning in the python docs about ensuring process stdout pipes didn't get full, but I can't see it now, maybe it was a python2 consideration only
<kyrofa> thomi, that's for setting stdout or stderr=PIPE with check_call
<kyrofa> In which case the caller is responsible to emptying them
<thomi> check_output simply calls run with stdout=PIPE. Does the same consideration not apply there as well?
<kyrofa> thomi, run is fine assuming it also called communicate afterward, no?
<kyrofa> Yeah here's the warning on check_call: "
<kyrofa> Note
<kyrofa> Do not use stdout=PIPE or stderr=PIPE with this function. The child process will block if it generates enough output to a pipe to fill up the OS pipe buffer as the pipes are not being read from. "
<kyrofa> Here: https://docs.python.org/3/library/subprocess.html#subprocess.check_call
<thomi> I see - check_call is implemented by calling `call()`, but `check_output` is implemented in terms of `run` and `Popen`
<thomi> kyrofa: this only happens on travis?
<kyrofa> thomi, yeah
<kyrofa> Super weird
<kyrofa> Although I'm not running the entire suite locally, maybe there's something odd that happens when the whole shebang runs
<kyrofa> s/not/now/
<thomi> I'd be tempted at this point to try and create a minimal reproducer in a separate repo. It'd be interesting to see what's required to trigger it consistently
<kyrofa> Yeah that's not a bad idea
<kyrofa> I wonder if lxc might be involved as well
<thomi> if it is, that's at least easy to test locally
<kyrofa> thomi, anyway, I don't mean to suck your lifeblood too, but if you could mull it over in the back of your mind I'd be thankful
<thomi> yeah - I will - let me know if you make any progress, you've got me interested now.
<kyrofa> Will do! I'll set up a test repo shortly and see if I can manage to get it happening
<thomi> If you want an easy way to create lots of tests (assuming for the moment that lots of tests running in parallel is part of what's required to trigger this) look at `testscenarios` - you can programmatically multiply a single test N times.
<mup> PR snapcraft#1641 closed: lxd: catch CalledProcessError in _container_run <bug> <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1641>
<mup> PR snapcraft#1647 opened: lxd: better surfacing of errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1647>
<sergiusens> elopio kyrofa ^
<jdstrand> tyhicks: hey, I noticed in https://github.com/snapcore/snapd/pull/3998 that you are using EPERM. this is consistent with all of our conversations, but I forgot until recently that apparmor and DAC return EACCES. I wonder if it would make sense to use EACCES instead? note that device cgroup uses EPERM
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<elopio> snappy-m-o autopkgtest 1647 xenial:amd64 xenial:arm64 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<tyhicks> jdstrand: I don't really have an opinion on the matter but I'll be happy to talk through it
<tyhicks> jdstrand: it may require a case-by-case evaluation per syscall
<tyhicks> jdstrand: the man pages for setuid(), setresuid(), etc., don't mention EACCES as a possible return value but do mention EPERM
<jdstrand> tyhicks: oh hmm
<jdstrand> tyhicks: does apparmor retrun !EACCES depending on the access?
<tyhicks> jdstrand: I don't think it is possible for an LSM to cause EACESS to be returned for those syscalls (I may be wrong about that...)
<tyhicks> jdstrand: I'm not sure off the top of my head
<zyga-ubuntu> jdstrand: I recall -13
<zyga-ubuntu> which is indeed EACCES
<jdstrand> zyga-ubuntu: yes, I looked at this recently for open, but I hadn't considered that they might set errno differently depending on syscall
<jdstrand> tyhicks: well, ultimately it doesn't matter. I was asking for consistency
<jdstrand> tyhicks: and I did notice that apparmor and device cgroup were different with open
<tyhicks> jdstrand: I don't necessarily think that they do set errno different depending on the syscall
<jdstrand> EACCES vs EPERM
<tyhicks> jdstrand: rather, I think there's a subset of syscalls that don't have LSM hooks
<jdstrand> right...
<jdstrand> tyhicks: so, you're saying that if there is a hook, the LSM can set it to whatever it wants (eg, apparmor uses EACCES)
<jdstrand> tyhicks: I don't quite understand if there isn't a hook... I mean, if there isn't a hook, there isn't a mediation point for the LSM
<tyhicks> just a sec, I'm tracing some apparmor hooks
<tyhicks> jdstrand: AppArmor return EPERM in a couple instances (capability checks and profile transitions)
<jdstrand> tyhicks: seccomp is different in that it doesn't use the LSM hooks though. why wouldn't it set errno to something else? I guess I could understand with setuid and friends cause setting it to something else might lead to programs not behaving correctly since they might be checking for EPERM
<tyhicks> jdstrand: sometimes those EPERMS are passed on and they're ignored in other cases
<jdstrand> tyhicks: ok, good to know
<tyhicks> jdstrand: when you say, why wouldn't it set errno to something else?"
<tyhicks> bah
<tyhicks> jdstrand: what errno value are you talking about when you say, "why wouldn't it set errno to something else?"
<jjohansen> tyhicks, jdstrand: yep EACCESS when policy says no, EPERM in a couple of places when its not so much policy as some other violation
<jdstrand> tyhicks: if we use SECCOMP_RET_ERRNO() and set it to EACCES, why would the kernel return something else?
<tyhicks> jdstrand: it won't (we must have misunderstood each other somewhere)
<jdstrand> (that was my question. I may have answered myself with setuid and friends)
<jdstrand> tyhicks: you said something about not being able to set EACCES for setuid. or did I misunderstand?
<tyhicks> jdstrand: I was just saying that I don't think an LSM can intervene in a setuid() syscall and, if that's true, no applications are going to expect EACCES to be returned from setuid()
<tyhicks> maybe jjohansen can correct me if I'm wrong there
<jdstrand> tyhicks: I didn't think seccomp was a true LSM in that regard. as for setuid and whether we should set EACCEs for it, that is worth considering for sure
<jdstrand> I think I can test that real quick
<tyhicks> jdstrand: I'm not talking about seccomp when I say LSM
<tyhicks> jdstrand: I'm talking about selinux, apparmor, smack when I say LSM
<jdstrand> tyhicks: ok. well, I was only talking about your seccomp PR :)
<jdstrand> so I was a bit confused when you started talking about LSMs :)
<tyhicks> wut? you mentioned AppArmor in your first message on this topic :)
<tyhicks> we're just talking in circles at this point :)
<jdstrand> oh pfft
<jdstrand> I wasn't clear
<jdstrand> "I wonder if it would make sense to use EACCES instead?"
<tyhicks> I think we both feel like EPERM is the right thing for snapd's seccomp filter to return, right?
<jdstrand> s/EACCES in your PR instead"
<jdstrand> my question was wondering if your PR should be changed to EACCES for consistency with apparmor
<jdstrand> but there is a very good argument against doing that with setuid
<tyhicks> I think EPERM is a good default to go with for now. There may be some specific syscalls where we prefer to return EACCES instead of EPERM once we start widely testing a number a snaps with the new confinement.
<jdstrand> tyhicks: that's fair. thanks and sorry for the extra circle or two
<tyhicks> jdstrand: no problem - I'm a bit anxious to see how existing snaps will react to the change
<jdstrand> I suspect most will eventually die in weird ways with cascading failures
<jdstrand> I suspect setpriority will be the one that isn't so bad
<jdstrand> from what I've seen, the return code is often not checked for that, but that isn't at all fatal
<tyhicks> yeah, that'll be nice to not result in a kill
<jjohansen> jdstrand: an LSM certainly can interfere with the setuid syscall, I think the hook has been removed atm but it could be reintroduced
<tyhicks> (that was me that said that)
<tyhicks> jjohansen: I was just going off of the hooks that currently exist
<tyhicks> jjohansen: how long ago was that?
<jjohansen> tyhicks: hrmm, a couple years ago, when there was some unused hook cleanup, it is one I would like back for apparmor
<jjohansen> I'm not the only one who wants a couple of the user related hooks to return
<jjohansen> its hard to argue for them without the code to do something with them though
<tyhicks> interesting, thanks
#snappy 2017-11-01
<elopio> snappy-m-o autopkgtest 1647 xenial:armhf xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<mup> PR snapcraft#1648 opened: sources: get svn revision with --show-item flag <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1648>
<mup> PR snapd#4110 opened: many:  have a timestamp on store assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/4110>
<mup> PR snapd#4111 opened: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
 * ogra_ really likes the new animations for download and install 
 * Chipaca is happy that ogra_ likes it
<pedronis> Chipaca: hi
<pedronis> Chipaca: #4111 might be something you could review when you have time
<mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
<Chipaca> pedronis: already looking at it yes
<Chipaca> pedronis: we still have no answer for how to turn off these flags :-(
<Chipaca> beyond reinstalling
<pedronis> Chipaca: snap refresh foo
<pedronis> that's the answer Gustavo gave
<pedronis> Chipaca: : https://forum.snapcraft.io/t/make-ignore-validation-sticky-and-send-the-flag-over/2139/2
<Chipaca> hmmm
<Chipaca> we're probably not doing the right thing today in a couple of places then
<pedronis> that's also the behavior implemented by the branch
<pedronis> and tested
<pedronis> at least for this flag
<pedronis> Chipaca: notice that at least for channel there's special code to do something even if there's no refresh (though for channel we also have switch)
<pedronis> adding similar code for this is one of the TODOs
<pedronis> Chipaca: I'm talking about this:  https://github.com/snapcore/snapd/pull/4111/files#diff-4f584006240926759b614bfd921c5fc0R938
<mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
<pedronis> Chipaca: so I think I'm following the spec afaiu
<Chipaca> pedronis: yeah, that 'do something in refresh when no update' is the missing bit i guess?
<pedronis> yes
<pedronis> but it's annoying enough that I prefer to do it in a separate PR
<pedronis> (also we leaved without it for channels for a long while)
<pedronis> s/leaved/lived/
<Chipaca> pedronis: OTOH maybe it's an argument to make switch do this instead of refresh, when no update
<pedronis> for channels we do both
<pedronis> also I fear switch as designed is too channel specific
<pedronis> to involve it in this
<pedronis> anyway IÂ personally don't see any of that as blocker to the main change
<Chipaca> pedronis: why is switch too channel-specific?
<pedronis> snap switch -h
<pedronis> switch switches channel
<pedronis> if we want it to do other flag toggling I'm not sure the name is great or it is easy to explain
<Chipaca> pedronis: i thought you meant it would feel unnatural to use it for this, not that we'd have to change the documentation
<Chipaca> OTOH it's true that the "strip devmode" thing doesn't work in switch
<Chipaca> i.e. it'd have to be 'snap switch --disable-devmode thesnap'
<Chipaca> or somesuch
<pedronis> yea, it's not an nice UX afaict
<pedronis> well, mostly is not a discoverable UX
<pedronis> anyway I didn't do any of this in this PR because it has huge bikeshedding potential as you see
<pedronis> Chipaca: I'm getting this from prepare in a test run (on 14.04):  + chattr -i /var/cache/snapd/names
<pedronis> chattr: No such file or directory while trying to stat /var/cache/snapd/names
<mlw> Has anyone here had an issue with cmake "finding" libGLEW.so in the wrong place. Having an issue with snapcraft unable to find it after building. Cmake config says it finds GLEW in /usr/include
<mlw> Could anyone point me in the right direction?
<mlw> I have the libglew-dev in my build-packages.
<diddledan> the cmake snapcraft plugin currently doesn't add <stage>/usr/local/lib{,/x86_64-linux-gnu} to the CMAKE_LIBRARY_PATH variable, and because the var is set in the environment it isn't possible to override using -DCMAKE_LIBRARY_PATH in configflags:
<diddledan> same for CMAKE_INCLUDE_PATH and <stage>/usr/local/include
<sergiusens> davidcalle hey, not sure how this happened, but the oldest doc in the world was revived here https://docs.snapcraft.io/build-snaps/plugins
<diddledan> why does that page have a blurb at the bottom about yocto being owned by linux foundation? I mean what relevance is there?
<diddledan> sergiusens: ^^^
<diddledan> looks like it's on all the snapcraft.io pages
<sergiusens> diddledan I don't know, I feel like I woke up in the twilight zone
<mlw> diddledan: so I'm stuck?
<mlw> the error I get reads
<mlw> CMake Error at cmake_install.cmake:36 (file):
<mlw>    file INSTALL cannot find
<mlw>    "/home/mattias/djv/parts/cmake-build/src/$CMAKE_PREFIX_PATH:/home/mattias/stage/lib/libGLEW.so".
<diddledan> mlw: my comment was unrelated
<diddledan> mlw: I was mentioning my own problem
<mlw> diddledan: ah, ignore me :)
<diddledan> mlw: although it does look like your problem might be similar
<mup> PR snapcraft#1649 opened: add stage/usr/local/lib to cmake library path <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1649>
<sergiusens> stgraber jdstrand any ideas about this? "Setup snap "lxd" (4778) security profiles (cannot setup seccomp for snap "lxd": " on a travis run today -> https://pastebin.ubuntu.com/25864977/
 * sergiusens goes for a walk
<jdstrand> fatal error: runtime: address space conflict'
<jdstrand> err
<jdstrand> sergiusens: I don't know. I just tried on xenial with edge core and edge lxd and it worked fine. this seems to go a golang thing due to 'runtime: address space conflict: map(0xc820000000) = 0x7fc72ab24000
<jdstrand> fatal error: runtime: address space conflict'
<jdstrand> sergiusens: I googled that and it said something about garbage collection and heap memory. did the system oom?
<jdstrand> sergiusens: looking at the trace, it looks like a heap allocation that failed
<pedronis> Chipaca: IÂ pushed my changes to #4076, it could use  a review
<mup> PR #4076: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076>
<cachio> jdstrand, hey, I am creating a test for desktop interface and I can access the /etc/xdg/user-dirs.conf and .defaults
<cachio> jdstrand, I see this https://paste.ubuntu.com/25865263/
<cachio> jdstrand, I can access to the rest of the files
<cachio> jdstrand, not sure if I need to do something else
<jdstrand> cachio: I'm confused. you can access the files but you have denials?
<jdstrand> cachio: I can say that we started to allow those files with a recent 2.29 and master PR
<cachio> jdstrand, no, I getr permission denied
<cachio> jdstrand, I am able to access to the rest of the files and dirs allowed by the interface
<jdstrand> cachio: are you on 2.28?
<cachio> in master
<cachio> jdstrand, I am creating a new test to validate the desktop interface on master
<jdstrand> that doesn't make sense. I'm looking at master now and the files are in there
<cachio> jdstrand, yes, I did the same
<jdstrand> cachio: can you paste /var/lib/snapd/apparmor/profiles/snap.test-snapd-desktop.testdesktop?
<cachio> jdstrand, https://paste.ubuntu.com/25865301/
<cachio> jdstrand, I have installed 2.28.5
<cachio> is it included on this one?
<jdstrand> cachio: that file doesn't have the rules
<jdstrand> cachio: no. it is in 2.29 and higher
<cachio>  jdstrand, well, that's the reason :)
<jdstrand> indeed :)
<cachio> I'll update
<cachio> jdstrand, hanks and sorry
<cachio> thanks
<jdstrand> np
<stgraber> sergiusens: ouch, never seen that before, that's one very unhappy snapd
<sergiusens> jdstrand the log is all the info I have, this is travis on trusty
<hurricanehrndz> How do you run a search against all the channels?
<sergiusens> seems to have been a one time thing, luckily
<Chipaca> hurricanehrndz: you can't
<Chipaca> hurricanehrndz: why do you want to do that?
<hurricanehrndz> Chipaca: Why wouldn't I, There is no snapcraft on openSUSE and I would like to use it. I know it is in the candiate channel, but I know that because I ran a search on reddit, I find it very unproductive to have to go to browser in order to find snaps
<hurricanehrndz> Chipaca: so now I'm wondering what other snaps are available on the other channels that I could make use of, but have no way to index
<pedronis> hurricanehrndz:  but snap info snapcraft   tells that
<hurricanehrndz> Oh, didn't know
<hurricanehrndz> That's what I was looking for, I think. Let me try
<hurricanehrndz> pedronis: Info only helps, if I know the snap exists
<pedronis> this works if you know the name of the snap,  but in general is not a good idea to use not stable snaps you don't know about
<pedronis> hurricanehrndz: that's a bit by design currently, if a snap is not stable, is not advertized, but can be used  (install, info etc) if one knows about it
<hurricanehrndz> pedronis: I'm a dev, so I'm okay with being on cutting edge. It just seems that find should have an option to search across all channels
<hurricanehrndz> pedronis: is there any plans to bring snapcraft to other platforms?
<hurricanehrndz> Or is a snap of snapcraft the plan?
<Chipaca> hurricanehrndz: that's a question for sergiusens i think
<hurricanehrndz> sergiusens: Do you know if there are plans to bring snapcraft to other distros
<hurricanehrndz> Thanks for all the guidance guys! :)
<sergiusens> hurricanehrndz it is a snap, so if snaps work their, it could potentially work, like all debian based distros should be ok; snapcraft with cleanbuild or persistent containers if not
<sergiusens> that said, if you want something like Fedora, we are waiting on Son_Goku ;-)
<Son_Goku> wait what?
<Son_Goku> sergiusens: what am I being dragged into now?
<sergiusens> btw, 2.35 is going to be the one that makes it to stable
<sergiusens> Son_Goku dnf?
<sergiusens> dnf in snapcraft that is
<Son_Goku> oh, you mean RPM support for snapcraft
<Son_Goku> yeah, I need to make time to hack on it again
<Son_Goku> I've been bombarded with all kinds of stuff lately
<sergiusens> Son_Goku yeah, exactly that, and no worries
<Son_Goku> hurricanehrndz: I'm working on Fedora/openSUSE support for snapcraft, it's just taking some time
<Son_Goku> unlike most folks here, I'm doing this in my free time, so it's not moving as fast as I'd like it to
<sergiusens> elopio and kyrofa are you around for a quick hangout?
<Son_Goku> I took a break last weekend to just play video games and do nothing else
<Son_Goku> Super Mario Odyssey was awesome
<sergiusens> Son_Goku heh, some of the things that get done are done in my free time as well but I totally get you as I am not context switching ;-)
<sergiusens> Son_Goku I noticed that SMO took some priority over what is considered free time
<Son_Goku> the last four weekends were spent working
<Son_Goku> I was exhausted
<Son_Goku> like, for $DAYJOB
<Son_Goku> sergiusens: as for snapcraft cleanbuild, kyrofa has to start packaging lxd for Fedora now ;)
<Son_Goku> I fulfilled my end of the bargain and made the selinux policy work with lxd, now we just need lxd in Fedora itself
<sergiusens> Son_Goku just snap install lxd on fedora!
<Son_Goku> the snap doesn't integrate with our selinux policy
<Son_Goku> so things break
<Son_Goku> I don't recall if stgraber fixed it, but it was still broken last I checked
<Son_Goku> which admittedly, was a few weeks ago
<hurricanehrndz> sergiusens: Nope not fedora, openSUSE
<hurricanehrndz> sergiusens: Thank you though
<hurricanehrndz> Son_Goku: If you need help let me know
<hurricanehrndz> Son_Goku: Thanks for all your hard work, it means a lot to all of use that are on RPM based distros
<hurricanehrndz> Son_Goku: Good for you taking a break, I know the feeling of needing a breather. It has been awhile for me, he he. I want to get back into playing games again soon.
<hurricanehrndz> Ps selinux is a pain in the ass
<Son_Goku> hurricanehrndz, SELinux isn't bad or difficult, but it's hard to get Ubuntu people to think about the other side so much ;)
<Son_Goku> their only SELinux guy left a long time ago for Google
<ogra_> if you talk about kees, he didnt leave ubuntu ... only canonical ;)
<ogra_> (he is actually a member of the ubuntu technical board )
<elopio> sergiusens finishing my workout. Will be ready in 15.
<kyrofa> sergiusens, elopio sorry, late start today, I'm around now
<kyrofa> I have coffee roasting though
<sergiusens> kyrofa elopio ok, let's join when the clock hits 10, on the weekly one
<elopio> I'm ready
<elopio> Ack
<jdstrand> sergiusens: it seems something unrelated to snappy. my guess is memory pressure
<kyrofa> Sorry guys, just finished up the coffee, joining now
<kyrofa> elopio, sergiusens darn, was it that quick? :P
<elopio> kyrofa: where are you?
<sergiusens> kyrofa we are talking still
<elopio> wrong hangout?
<kyrofa> What the heck... weekly right? I was the only one there
<kyrofa> Trying again
<om26er> Hi! re: docker snap, seems when I delete my containers and images the disk space is never freed.
<cory_fu> Are the build.snapcraft.io builders backed up or something?  I've been waiting all morning for a build of charm-tools so that I can do a release.
<om26er> cory_fu: I learned yesterday that builders are busy when gates for new Ubuntu release open.
<om26er> my build started at like 12AM last night.
<cory_fu> Ah, I see.  That makes sense
<mup> PR snapcraft#1647 closed: lxd: better surfacing of errors <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1647>
<kyrofa> Haha, oh darn, I was testing that PR. Apparently I can only approve OPEN ones
<kyrofa> +1 anyway
<diddledan> has snapd lost it's newly inbuilt xdg-open support again?
<diddledan> snapd   2.28.5+17.10
<mup> PR snapd#4112 opened: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>
<diddledan> Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
<diddledan> from dpkg -l : ii  snapd-xdg-open                                                   2.28.5+17.10                                amd64        Transitional package for snapd-xdg-open
<diddledan> weird. some apps can launch urls fine but one specific one (djv_view that I've been working with mlw to snap) can't
<diddledan> oh wait. it's a file:// url
<diddledan> bah
<diddledan> not supporting mailto: and file: urls is painful
<Chipaca> diddledan: raise it in the forum?
<diddledan> I thought I had. search isn't showing me the thread tho
<kyrofa> The forum search does that
<diddledan> why?! seems a bit backwards for a "find the thing you're after" to not show the thing you're after
<kyrofa> diddledan, haha, I'm just being mean. I just mean to say it doesn't cooperate with me either
<diddledan> aye, I've noticed it on several different times I've tried finding my previous posts
<Chipaca> diddledan: i didn't understand it until i tried to read one of the longer topics
<Chipaca> there, it's exactly what i wanted
<Chipaca> so Â¯\_(ã)_/Â¯
<sergiusens> I need to relocate, internet is down
<gsilvapt> hello all
<gsilvapt> elopio, you around?
<mup> PR snapcraft#1650 opened: Release changelog for 2.35 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
<sergiusens> elopio kyrofa ^
<kyrofa> sergiusens, elopio, ament is finally all green! Means autopkgtest is promising
<kyrofa> sergiusens, once we get this release out the door, would you mind giving snapcraft#1636 a priority? I'm seeing more people wanting to run on trusty
<mup> PR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
<sergiusens> kyrofa hmm, maybe we should get that one in now if it allows trusty, that is a big win. Is it green green?
<kyrofa> sergiusens, no autopkgtests have run there, but I can run them if we can spare the resources
<sergiusens> kyrofa we will only do trusty as a snap though
<kyrofa> sergiusens, of course
<elopio> gsilvapt: hello
<kyrofa> sergiusens, I'd also like to write some spread tests for it
<kyrofa> sergiusens, but I was able to build a ROS snap with it
<sergiusens> kyrofa for which we can just enable a new runner on our travis matrix to run the same suite without lxd
<kyrofa> Oh that's a good idea, assuming you're talking about the integration suite
<kyrofa> Although that will roughly double our PR test time...
<kyrofa> Nightly?
<kyrofa> It also assumes the testing deps we have work on trusty
<kyrofa> I can test that out
<kyrofa> Eh... no that won't work. That will pull all deps from trusty, which I bet won't work for some of our tests
<sergiusens> kyrofa don't do it now ;-)
<sergiusens> for later
<kyrofa> Sounds good
<sergiusens> kyrofa ugh, you updated the branch, I was about to merge
<sergiusens> oh well... this gives some time for elopio to review
<kyrofa> sergiusens, you still can if you're comfortable with it, results in the same thing, but yeah that's fine too
<kyrofa> I'm retesting it here anyway, a few different things have landed that should make this the last one for trusty, just verifying now
<sergiusens> kyrofa ok
<kyrofa> sergiusens, in the release notes, let's make sure we call it "initial/experimental support" :P
<kyrofa> Then we can build up our suite of tests to gain confidence
<sergiusens> kyrofa oh, a first release of anything is that, right?
<kyrofa> Haha, totally
<kyrofa> sergiusens, built the snap, works great for both the opencv demo as well as the ros-talker-listener integration test (indigo, which is one of the main use-cases for this). Green light on that front
<kyrofa> i.e. this is indeed the final PR for trusty support
<sergiusens> kyrofa great
<kyrofa> sergiusens, it doesn't look like the nodejs plugin ever runs `yarn install` if the package manager is yarn, right?
<sergiusens> kyrofa why do you ask?
<sergiusens> it is very different in the refactor
<sergiusens> but yarn install doesn't do the same as npm install
<kyrofa> sergiusens, while I'm waiting for tests to run I'm trying my first nodejs snap, who's build directions are given as yarn install && yarn run start
<kyrofa> It's not building without any options, so I've been taking a closer look at the plugin
<sergiusens> kyrofa oh, maybe let m give you the refactor
<sergiusens> kyrofa look at my nodejs-refactor branch
<kyrofa> sergiusens, trying it out now, thanks!
<sergiusens> kyrofa this reminds me about `source: .` ... that needs to leave the world as the default
<kyrofa> sergiusens, that works way better, although trying to use the tarball created by npm pack isn't working, I'll poke at that
<kyrofa> (it doesn't seem to exist, although pack seemed to succeed)
<mwhudson> so uh why do we not have snapd for trusty/{arm64,ppc64el}? is this something you should be talked to your local golang maintainer about?
<kyrofa> mwhudson, probably worth a forum post, I suspect all the snapd folks are long gone for the day
<kyrofa> sergiusens, the tarball doesn't include a 'v' in the version
<kyrofa> At least, not this one
<kyrofa> sergiusens, the package.json includes a v, but the tarball doesn't
<mwhudson> kyrofa: yeah i guess although i've rolled back my concern another level :)
<mup> PR snapcraft#1636 closed: internal: more gracefully determine host OS <bug> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
<mup> PR snapd#4113 opened: tests: test for desktop interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4113>
<kyrofa> elopio, ping on bug #1693058
<mup> Bug #1693058: can't install a snap with ca-certificates-java as a build-package <recording> <regression> <Snapcraft:Triaged by elopio> <https://launchpad.net/bugs/1693058>
<kyrofa> sergiusens, when you're able, could you take a look at bug #1724972 ? I swear I remember running into that before, but my memory is so hazy. Any chance you remember?
<mup> Bug #1724972: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <iot> <snap> <Snapcraft:New> <https://launchpad.net/bugs/1724972>
<kyrofa> I thought we fixed stuff like that in the repo
<kyrofa> Oh interesting-- that file should be filtered out completey
<kyrofa> Oh nevermind. That's just crawling
<elopio> kyrofa: pong, closed
<kyrofa> elopio, yay \o/
<kyrofa> sergiusens, elopio you'll never believe it, but snapcraft#1607 is green
<mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
<elopio> ^_^
<kyrofa> Note that I've not completely solved the problem, and while it is still a problem, it was a red herring that wasted a ton of time
<kyrofa> During review, I made a change that happened to cause an integration test to fail. However, instead of showing us that failure, unittest barfed with the exception we all know and love
<kyrofa> Now that the tests no longer actually fail, unittest isn't dying
<kyrofa> I'm still investigating why unittest is breaking this way on Travis, but it's no longer blocking this branch
<kyrofa> Until I figure out what's happening, if you see this exception, it means the tests are failing and need to be run locally
#snappy 2017-11-02
<elopio> kyrofa: ugh, that sucks. I'm sorry you had to spend so much time on that.
<kyrofa> elopio, I blame you. You asked for the change that broke the test
<kyrofa> elopio, nahh, it was educational, for sure. I learned a lot about unittest :P
<kyrofa> I updated the branch so it's running again, just to be doubly sure
 * elopio sent a long message: elopio_2017-11-02_00:15:43.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/pGtjPKvKcSNwREOGnwTVeFFe>
<elopio> kyrofa: ahh, you know me, always investing in your personal growth :D
<kyrofa> Hahahaha
<kyrofa> elopio, do you get the same error for cleanbuild?
<kyrofa> Indeed, that sounds like a snapd issue
<elopio> kyrofa, yes anything that calls lxc. It doesn't happen when running from the venv
<kyrofa> Weird
<kyrofa> Alright, dinner time here
<sergiusens> kyrofa well, lesson is, you should run the full suite locally when things fail remotely ;-)
<sergiusens> elopio mind triggering adt for everything under the sun on the 2.35 branch?
<mlw> diddledan: hey dan, are you around?
<sergiusens> kyrofa now that you rebased instead of adding an individual commit you should add an explanation in the PR
<elopio> snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64
<snappy-m-o> elopio: I've just triggered your test.
<sergiusens> elopio do we support bionic?
<elopio> sergiusens: is it ready? do-release-upgrade doesn't let me upgrade from a.
<elopio> lxc doesn't have bionic either
<sergiusens> elopio people are already on it
<sergiusens> elopio didn't you see the ubuntu-devel list? Already open for development
<elopio> sergiusens: how? latest daily live is from the 18: http://cdimage.ubuntu.com/daily-live/current/
<sergiusens> elopio changing sources.list to bionic?
<sergiusens> elopio we can already upload, debootstrap is the mechanism https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html
<elopio> snappy-m-o autopkgtest 1650 bionic:amd6
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmpmgtertxg/retry_autopkgtest.sh', '1650', 'bionic:amd6']' returned non-zero exit status 1
<elopio> snappy-m-o autopkgtest 1650 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> ahh, damn
<elopio> snappy-m-o autopkgtest 1650 bionic:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> apparently, it will run sergiusens
<elopio> snappy-m-o autopkgtest 1650 bionic:armhf bionic:arm64
<snappy-m-o> elopio: I've just triggered your test.
<mup> PR snapd#4114 opened: interfaces: don't udev tag devmode or classic snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4114>
<sergiusens> \o/
<sergiusens> elopio look at the runaway output on zesty-amd64 :/
<elopio> sergiusens: that's unfortunate. But well, it's probably time to close that socket properly.
<elopio> it's weird that the socket is not opened for this test, but maybe it's just printed late or something.
<elopio> if only I could reproduce it...
<mup> PR snapd#4115 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via kernel <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4115>
<mup> PR snapd#4116 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4116>
<mup> PR snapcraft#1651 opened: tests: move the rest of ros demos tests to integration <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1651>
<elopio> snappy-m-o autopkgtest 1651 xenial:amd64:integrationtests
<snappy-m-o> elopio: I've just triggered your test.
<zyga-solus> good morning
<zyga-solus> good morning mvo
<zyga-solus> mvo: we have a series of PRs from jamie for 2.29
<zyga-solus> I'll be with you soon
<mvo> zyga-solus: yeah, checking. I just approved 4114
<pedronis> zyga-solus: mvo: hi
<mvo> jdstrand: 4115 is not a 2.29 regression, its fallout from the changes in 2.28, right?
<mvo> hey pedronis
<zyga-solus> hello pedronis, how are you doing?
<pedronis> ok, up early (for me) because we are waiting for people doing some work for the house
<zyga-solus> mvo: 4115 was a general feature I believe, we always udev tagged devmode but we never did this at a scale introduced in 2.28
<mvo> zyga-solus: yeah, 4115 is not a regression (technically)
<zyga-solus> technically that is correct
<pedronis> mvo: I  fixed the configure snapd branch (doing the simplest possible change I think), if you want to look,   it could be mergeable and we can do more in follows up
<mvo> pedronis: cool, I have a look now. thanks for picking this up!
<zyga-solus> mvo: please don't land 4114 just yet
<pedronis> mvo: IÂ also have a couple more PRs needing review but less urgent than jdstrand stuff obviously
<mvo> zyga-solus: sure, I hold it back. whats your concern?
<mvo> pedronis: thanks, your config fix looks good, I will go over the other two commits and then I think this gets my +1
<mvo> pedronis: then I can do more reviews
<zyga-solus> mvo: I want to see why tests are just for ubuntu, they should not be
<zyga-solus> mvo: I'll test locally and push a change if they can work everywhere
<zyga-solus> just eating breakfast
<mvo> zyga-solus: cool, thanks
<mvo> zyga-solus: I also saw test failures in 14.04/reexec in spread but maybe just a fluke
<mvo> pedronis: hm, you are spot on about IgnoreHookError in configure-snapd. I think we need to make sure we do not fail hard if something is not working with the internal configure
<pedronis> mvo: we set only on install/refresh of core, IÂ suppose we could teach the handler to just log the error if some flag is set on the task
<mvo> pedronis: yeah, I can prepare a followup with this fix
<pedronis> mvo: ok, going to merge it
<mvo> thanks!
<pedronis> done
<mup> PR snapd#4076 closed: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4076>
 * zyga-solus is back now
<mborzecki> morning everyone
<zyga-solus> mborzecki: hello!
<mborzecki> i'm the new guy, starting only today :)
<zyga-solus> welcome :)
<zyga-solus> mborzecki: we have mvo and pedronis around already
<mborzecki> mvo: pedronis: hi
<zyga-solus> mborzecki: pawel and john should join soon too
<zyga-solus> (though perhaps john is off today, not sure)
<zyga-solus> mborzecki: gustavo I believe is off this week
<zyga-solus> mborzecki: sergio will join later today
<pedronis> mborzecki: welcome!
<mvo> hey mborzecki - welcome!
<mborzecki> thanks
<zyga-solus> mborzecki: fork and build the tree and look around
<mborzecki> so how does it work from here? already got an email address, launchpad accounts and SSO work
<zyga-solus> mborzecki: we're just starting with 2.29 release candidates
<zyga-solus> mborzecki: great, you also need a github account as that's where the code is (but I'm sure you have one)
<zyga-solus> mborzecki: mvo can add you to the team that owns snapd, I believe
<mvo> mborzecki: a good starting point is probably to check if our "HACKING.md" is up-to-date ,)
<mborzecki> ok, cool
<zyga-solus> ha, excellent advice :)
<mvo> mborzecki: i.e. if you can get started following that guide
<mvo> mborzecki: and if its not up-to-date we appreciate PRs about the broken bits :)
<mborzecki> ack
<mvo> mborzecki: and if you have any questions or anything we are here for you!
<zyga-solus> mborzecki: also tell us which distro your are using
<mborzecki> haha, that's the interesting part, i'm using arch atm
<zyga-solus> mborzecki: large chunk of the team is on various releases of ubuntu
<zyga-solus> mborzecki: I'm on ... many :)
<mvo> mborzecki: thats good, our instructions are probably lacking in this area
<zyga-solus> mborzecki: I don't suppose you have arch commit access, do you?
<mborzecki> i'll be sure to check them
<mborzecki> zyga-solus: nope
<zyga-solus> mborzecki: the current maintainer has abandoned our package so we're kind of stale there
<mborzecki> iirc it's in community repo, right?
<zyga-solus> that's correct
<mborzecki> arch's rules of engagement we kind of weird last time I checked, but i could poke around and see if it's possible to do something like debians nmu
<zyga-solus> mborzecki: I think we need to indicate the current maintainer as inactive but that requires a motion filed by a TU
<zyga-solus> mborzecki: and then within some weeks there's a chance to remove that TU from the package and have another TU pick it up
<mborzecki> hm, so i'm guessing you've already started the process, but it isn't going as smooth as expected?
<zyga-solus> mborzecki: flexiondotorg was looking at this last time I think, I don't know more
<mborzecki> fair enough, I'll start with trying to build the current master first and we'll take it from there
<mborzecki> which go version do you use atm? i recall zyga-solus or niemeyer mentioning 1.6, is it still the case?
<zyga-solus> mborzecki: we use different versions for each system actually, ubuntu 14.04 and 14.06 are on 1.6
<zyga-solus> mborzecki: so that's the lowest common denominator
<zyga-solus> mborzecki: on arch and on development versions of ubuntu we use the latest
<zyga-solus> mborzecki: we also have almost everything in between, I think
<mvo> mborzecki: minimal version is 1.6, not sure we care about less. it should build with everything 1.6+ if not thats a bug worth fixing
<pedronis> mvo:  about reviews,   #4106 and #4111 are the main ones, Chipaca already did a first review
<mup> PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
<pedronis> mvo: do you remember why we have both  switch-snap  and switch-snap-channel tasks?  they seems to do very similar but not quite identical things
<mvo> pedronis: I think because of a race :/ iirc the snap switch command was actually coded long before it landed and in the meantime we probably did switch-snap-channel but the old switch thing did not get updated for it
<pedronis> mvo: I see, indeed IÂ noticed also the handler for one is in the wrong place
<pedronis> mvo: IÂ probably need to do something like switch-snap-channel for ignore-validation
<mvo> pedronis: will you look at cleaning this up (just noticed the wrong place as well :/
<mvo> pedronis: or shall I create a cleanup PR?
<pedronis> mvo: is not too urgent, also they  really do slightly different things
<pedronis> so needs a bit of thinking
<pedronis> I can move the hanlder in a drive-by though
<pedronis> mvo: they probably also need to be added to the change conflict task list
<mvo> pedronis: +1
<mvo> pedronis: silly question - do we have the inverse of --ignore-validation? just looking at 4111 and was wondering how this is reset
<person112> Apologies if this isn't the right place to ask, but can interfaces be shimmed?
<person112> As in, a snap that offers interfaces that simulate an empty 'Home' or a network that never opens a socket.
<pedronis> mvo:  https://forum.snapcraft.io/t/make-ignore-validation-sticky-and-send-the-flag-over/2139/3  , the reverse of  "snap refresh --ignore-validation foo"  is just  "snap refresh foo"
<mvo> pedronis: ta
<pedronis> mvo: that's the input from Gustavo on the matter
<pedronis> mvo: I double checked, because one  also changes the current SideInfo, switch-snap-channel and switch-snap are not interchangeable, we could add a flag but not sure worth the trouble at this point
<mvo> pedronis: yeah, maybe a comment is enough to explain the subtle details
<pedronis> I'll just do a small PR to move the handler closer to the other and add them conflict management
<mvo> pedronis: sounds good
<mvo> pedronis: and I see we test the reset of --ignore-validation, great (should have read all the way before asking :)
<mvo> pedronis: 4111 is small enough to consider for 2.29.1, wdyt? how urgently does CE needs it?
<pedronis> mvo: I think they would be happy if it's 4111, the server change was deployed yesterday
<pedronis> sorry
<pedronis> if it's in 2.29
<pedronis> but I didn't promise it
<mvo> pedronis: I milestoned it, for the fix from jdstrand we will need a 2.29.1 anyway so its a good target of opportunity (also low risk afaict)
<person112> Also, is it posible to change auto-connect defaults for snaps?
<pedronis> mvo: yea, I'm working on the follows up,  but as fix it's ok standalone
<mvo> thanks pedronis
<pedronis> mvo: I have a PR open about showing the flag in snap info,  and I'm working on setting/resetting the flag even if there's no update atm, like we do for channel
 * mvo nods
<pedronis> mvo: when do you think we will cut 2.30 ?
<mvo> pedronis: early next week, but there are some important piece that are missing, i.e. the fix for the refresh-schedule we promised for 2.30
<mvo> pedronis: mostly on my plate though
<zyga-solus> mvo: early next week?
<zyga-solus> mvo: I thought that would be only after 2.29 goes to stable
<zyga-solus> mvo: ~3 weeks
<mvo> zyga-solus: the schedule is that 2.29 goes to stable on Monday
 * zyga-solus was hoping to have most of layouts in 2.30
<zyga-solus> aha :)
<zyga-solus> I guess 3.31 it is then
<pedronis> mvo: I also have some stuff that we want in 2.30 because it was delayed already quite a bit
<mvo> zyga-solus: check https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<pedronis> mvo: time to have the milestone to tag stuff?
<mvo> pedronis: +1
<mvo> pedronis: milestone added
<pedronis> thank you
<mup> PR snapd#4013 closed: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4013>
<pedronis> mvo: marked thing accordingly (especially #4106 that IÂ mentioned before)
<mup> PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<pedronis> mvo: I'm merging #4111,  it's one commit so it should be easy to cherry-pick for 2.29
<mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
<mup> PR snapd#4111 closed: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4111>
<mvo> pedronis: ta
<zyga-solus> mvo: I pushed a patch to 4114
<zyga-solus> mvo: I left some comments and I'm +1, I can also address them in a quick patch if you agree
<mup> PR snapd#4117 opened: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4117>
<pedronis> mvo: I created the cherry-pick ^
<mvo> pedronis: \o/ thank you
<mvo> zyga-solus: checking, thank you!
<mup> PR snapd#4118 opened: overlord/snapstate: cleanups around switch-snap* <Created by pedronis> <https://github.com/snapcore/snapd/pull/4118>
<mvo> zyga-solus: looks good, thanks
<pedronis> mvo:  and cleanups ^
<mvo> ta
<mborzecki> all right, as expected the code builds just fine, the tests are mostly ok. there are some issues raised by shellcheck in tests/lib/snaps/test-snapd-service/bin/{start,start-other} and tests/lib/snaps/test-snapd-service/meta/hooks/configure
<zyga-solus> mborzecki: nice, looks like some low hanging fruit to tweak
<mborzecki> i can fix those, open a PR, and we'll get through the github accounts and stuff :)
<zyga-solus> yep, sounds like a good plan
<mborzecki> btw. noticed that you're not using gometalinter but rather just the individual tools
 * zyga-solus never heard about gometalinter
<mborzecki> https://github.com/alecthomas/gometalinter sort of a frontend/driver to all the linting/checking tools for go
<pedronis> mvo: :( seems master is unhappy
<mborzecki> do i need to signoff the commits?
<zyga-solus> mborzecki: not really
<zyga-solus> mborzecki: I love to but it's just me
<mborzecki> ok, so another question, any email address or @canonical.com when signing off?
<zyga-solus> again, no rule, I use a mix, depending on how I feel about the work
<mborzecki> fair enough
<mvo> pedronis: I noticed this earlier too, I have a look in a bit
<pedronis> mvo: last one is snapd-reexec failure on 14.04 but IÂ don't understand the issue
<mup> PR snapd#4119 opened: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4119>
<mborzecki> fyi my github handle is 'bboozzoo' :)
<pedronis> mvo: seems we are installing the  same core  but don't expect that and don't get a restart
<zyga-solus> mborzecki: reviewed
<zyga-solus> mborzecki: I think you can remove the "have you signed the license agreement" stuff from your commit
<pedronis> + prev_core=3377
<pedronis> + snap install --dangerous /var/lib/snapd/snaps/core_3377.snap
<pedronis> core 16-2.29+git446.aaee286 installed
<pedronis> This leaves core tracking edge.
<pedronis> + MATCH 'Requested daemon restart'
<mborzecki> zyga-solus: i think it's only added by github PR templates, it's not part of the commit message
<zyga-solus> it's added but when you open the PR you can still remove it
<zyga-solus> you can hit the edit button and remove it still
<mborzecki> done
<mborzecki> btw. should I sign canonical CLA?
<zyga-solus> mborzecki: I don't think you need now
 * Chipaca looks around
<zyga-solus> hey ho Chipaca
<Chipaca> zyga-solus: hiya! how's things?
<zyga-solus> Chipaca: our new colleague, mborzecki is around
<mborzecki> Chipaca: hi there
<Chipaca> i was trying to spot them but with 283 people it was hard
<zyga-solus> Chipaca: damp
<Chipaca> mborzecki: o/!
<zyga-solus> Chipaca: but it might rain too :)
<Chipaca> zyga-solus: it's officially "are the clothes damp, or just wet" weather here
<zyga-solus> hehe :)
<zyga-solus> I'm in a mood to visit UK and see
<mborzecki> zyga-solus: is it not raining in warsaw yet?
<zyga-solus> mborzecki: I think it stopped now
<mborzecki> maybe it's buffering :/, damn weather
<zyga-solus> mborzecki: "loading more rain" ;) I like that
<mborzecki> ok, so what should look at now? go through PRs maybe?
<zyga-solus> mborzecki: look around, we have plenty of PRs to review
<zyga-solus> mborzecki: I think looking at that and asking questions is useful
<zyga-solus> mborzecki: you can also check our roadmap on the forum (oh, and do sign up if you haven't already)
<mvo> Chipaca: do you think https://forum.snapcraft.io/t/disk-usage-report/2372 might be a nice first task for mborzecki ?
<Chipaca> mvo: that'll touch osutils, daemon, client, and cmd/snap at a minimum
<Chipaca> mvo: but nothing particularly complex
<Chipaca> mvo: so... yes, probably? unless we want them digging into the overlord straight away
<mthaddon> hi there - I'm getting "cannot perform operation: mount --rbind /snap /snap: Permission denied" when running a snap I've installed inside an LXC - do I need to add the user to a particular group or something? (snap version 2.28.5 on 16.04)
<zyga-solus> I think today should be a "figure out the code layout day"
<zyga-solus> mthaddon: hey!
<mthaddon> o/
<zyga-solus> mthaddon: hmm hmm
<zyga-solus> mthaddon: can you tell me if the container is privileged?
<zyga-solus> mthaddon: as in, not confined at all?
<zyga-solus> mthaddon: and can you tell me what is on the outside of the LXC container?
<mthaddon> zyga-solus: I created the LXC with -c security.privileged=true. It's running on a xenial machine
<zyga-solus> mthaddon: I think, (though stgraber could confirm) that it means there's no apparmor stacking in that case, so whatever is in the container is confined by what is on the outside
<zyga-solus> mthaddon: which version of snapd do you have on the outside?
<mborzecki> i'll look around the code and will try to get a custom built snapd up and running, then i can take a look at disk usage
<mthaddon> 2.28.5 on the outside
<mvo> Chipaca: thinking about suitable tasks currently not too hard but also reasonable interessting. do you have ideas?
<zyga-solus> mthaddon: can you see if you had any apparmor denials?
<mvo> mborzecki: cool, another interessting task might be to update the arch packaging (cc zyga-solus )
<zyga-solus> oh, that's actually a very good idea
<mvo> mborzecki: or fixing the current test failure in master :)
<mvo> mborzecki: all interessting stuff :)
<mup> PR snapd#4120 opened: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>
<mthaddon> zyga-solus: I see some, but not at the time of when I run the command that's triggering the error. I had some errors during attempted building of a snap and had to install squashfsfuse and restart the lxc to be able to build the snap (and have core installed), but it eventually worked okay
<zyga-solus> mthaddon: I recall a case we investigated a good while back
<zyga-solus> mthaddon: where the problem was that snapd in the inside of a privileged lxd container was actually confined by the apparmor profile of a very out of date snapd on the lxd host
<zyga-solus> mthaddon: and we ended up saying that that is not supported much
<mthaddon> is 2.28.5 very out of date?
<zyga-solus> no, it's not
<zyga-solus> I'm just trying to grok what may be going on
<mthaddon> gotcha
<mup> PR snapd#4121 opened: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>
<zyga-solus> mvo: the 14.04 refresh-undo thing is a regression after the release recently?
<mup> PR snapd#4122 opened: configstate: add support for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>
<mvo> zyga-solus: I'm not sure, I have not investigated yet
<pedronis> mvo: I got the 14.04 snapd-reexec also on a PR
<pedronis> it seems a real issue
<pedronis> or something off with versions of things
<mvo> pedronis: 4122 adds the ignore-hook errors to the internal configure (and some more tests, I think I will add more more tests
<mvo> pedronis: yeah, I check that out
<mthaddon> zyga-solus: should I file an issue for this somewhere to make it easier to follow up on?
<mwhudson> mvo: /me points at debian packaging too :)
<zyga-solus> mthaddon: I think we could use a detailed bug and I should have a look at that
<mwhudson> mvo: mostly done, it just needs versions of dependencies checking
<pedronis> mvo: I'll look at it in a bit
<zyga-solus> hey mwhudson
<mthaddon> zyga-solus: sure, LP or GH?
<zyga-solus> mthaddon: LP please
<mthaddon> ack
<mvo> mwhudson: oh, the debian PR is updated, nice!
<mvo> pedronis: no rush
<mwhudson> mvo: uh not the PR against snapd, no :/
<mwhudson> mvo: but the repo on alioth is
<mwhudson> zyga-solus: hello
<mwhudson> zyga-solus: i am going to bed :)
<mvo> mwhudson: aha, ok
<mvo> mwhudson: we should merge your packaging still :)
<mvo> mwhudson: but another day, I guess its late for you
<zyga-solus> pstolowski: hey
<pstolowski> zyga-solus, hi!
<zyga-solus> pstolowski: which PRs should I get started with to help you out?
<pstolowski> zyga-solus, the two i've currently can be reviewed independently, and both are prerequisites for the upcoming ones, so pick any ;)
<zyga-solus> ok, I'm going to go through 4120 then
<pstolowski> zyga-solus, thanks in advance!
<pedronis> pstolowski: I'll see to look at your branches as well this afternoon or tomorrow
<pstolowski> thanks pedronis!
<zyga-solus> man, my eyes fail me today
<zyga-solus> mvo: there's going to be another tiny one for 2.29
<zyga-solus> pstolowski you found an interesting bug
<ogra_> popey, are you around ?
<zyga-solus> pstolowski: 4120 done
<ogra_> popey, how can i reack "oli" from askubuntu.com ... apparently he wants to delete all my recent snap related posts ... (i went over the 100s of long term unanswered snappy posts to point people to the forum)
<ogra_> *reach
<ogra_> seemingly that "breaks the rules of askubuntu, so I'm going to delete the most ..."
<zyga-solus>  quick break
<pstolowski> zyga-solus, thanks! ah, that, yeah, i rolled my eyes when I saw this, forgot to address it separately
<zyga-solus> pstolowski: I'll handle the 2.29 change
<zyga-solus> no worries
<zyga-solus> I'm adding a new test with some reflection
<pstolowski> cool
<mvo> zyga-solus: oh, tell me more? but after lunch :)
<mup> PR snapcraft#1652 opened: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>
<sergiusens> snappy-m-o autopkgtest 1652 xenial:amd64
<snappy-m-o> sergiusens: I've just triggered your test.
<jdstrand> mvo: re 4115 and 4116> not a direct regression, no, but the bug is exacerbated by 2.28
<zyga-solus> pstolowski: I have a test that catches the error now
<zyga-solus> jdstrand: hey :)
<zyga-solus> jdstrand: interesting iface bug pawel found today :)
<jdstrand> zyga-solus: hey
<jdstrand> zyga-solus: I haven't seen it yet (just woke up)
<zyga-solus> jdstrand: I'll send a PR up in 10 minutes
<mup> PR snapcraft#1651 closed: tests: move the rest of ros demos tests to integration <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1651>
<zyga-solus> oh boy oh boy
<sergiusens> oh man oh man
<sergiusens> :-)
<zyga-solus> mvo: two PRs up
<mup> PR snapd#4123 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
<mup> PR snapd#4124 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4124>
<zyga-solus> pstolowski: please merge this into your PR and ensure it's all green
<zyga-solus> pstolowski: thank you for finding it
<zyga-solus> jdstrand: ^
<zyga-solus> pstolowski: you will need trivial changes to type signature checks in the PR that changes them
<popey> ogra_: there is a meta chat thing on askubuntu. I'd recommend dropping in there
<popey> https://chat.stackexchange.com/rooms/201/ask-ubuntu-general-room
<popey> You're being discussed
<ogra_> heh
<jdstrand> zyga-solus: oh, eww
<jdstrand> zyga-solus: did you grep the source for other offenders?
<zyga-solus> jdstrand: not exhaustively, I just pushed this
<zyga-solus> jdstrand: I'm trying to see how far the bug goes
<jdstrand> zyga-solus: grep PermanentSlot ./*.go|grep plug: just ofono
<zyga-solus> jdstrand: beauty of dynamic typing :/
<mlw> hey diddledan, are you around?
<diddledan> yello
<mlw> Could I possibly request you to add gimp-gmic and gimp-data-extras to the stage packages for the gimp snap?
<mlw> The former more important than the latter.
<diddledan> well the gimp snap compiles gimp from source, rather than repackaging the debian package, so gmic will need compiling too. I've given it a shot and had problems, but I can't remember where I got to
<mlw> Ah, well thanks for looking.
<zyga-solus> mthaddon: hey, did you report that bug by any chance?
<pedronis> Chipaca: #4110 needs review for example (it's assertion but it's also small/clear hopefully)
<mup> PR #4110: many:  have a timestamp on store assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/4110>
<zyga-solus> mvo: I'll look at 14.04 now, maybe I can find something
<mthaddon> zyga-solus: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/1729576
<mup> Bug #1729576: cannot perform operation: mount --rbind /snap /snap: Permission denied <amd64> <apport-bug> <xenial> <snap (Ubuntu):New> <https://launchpad.net/bugs/1729576>
<zyga-solus> mthaddon: thank you
<zyga-solus> mthaddon: I'll check that after investigating master breakage now
<mvo> zyga-solus: thank
<mthaddon> ack
<mvo> zyga-solus: you
<mthaddon> zyga-solus: it's not blocking me, fwiw
<om26er> flexiondotorg: hey! re: sublime-text and android-studio, did you upload them to the store ?
<mup> PR snapd#4125 opened: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>
<zyga-solus> jdstrand: question about security-device-cgroups-serial-port, why does it fail on fedora/opensuse/debian
<zyga-solus> jdstrand: I'm staring at the interactive shell but I cannot figure it out just yet
<zyga-solus> jdstrand: do you know the reason?
<zyga-solus> mvo: interestingly 2.29 branches also fail
<mlw> diddledan: I've put architectures: [amd64], in my snapcraft.yaml, and I've added the github repo via snapcraft.io. How come it's looking to build both i386 and armhf (the latter which fails) when I've only specified one arch?
<diddledan> the architectures command doesn't actually say which architecture to build for. it says "this snap is compatible with". This is a bit of a weird situation
<mlw> So how do I tell snapcraft.io not to bother with the others?
<diddledan> you can't :-(
<mvo> zyga-solus: fails where?
<zyga-solus> mvo: on the 14.04 snapd-reexec test
<zyga-solus> mvo: so this rules out anything in master recently
<mvo> zyga-solus: yeah, I don't have anything in journalctl for the last change (core install, its change 6 for me)
<zyga-solus> mvo: I'll report when I find something
<mlw> Ok then. Well, last step is to figure out how to get the launcher configured correctly.
<mvo> zyga-solus: funny enough, if `snap change 6|grep Restart` is used things look ok
<mvo> zyga-solus: still very strange that it stopped working all by itself, no recent systemd chnage afaict (last is >2 weeks old)
<zyga-solus> mvo: yes, I still find it puzzing
 * Chipaca shakes his fist at everything
 * Chipaca goes for a cuppa
<kyrofa> sergiusens, elopio getting up to speed this morning. How's adt now? Can I help?
<mup> PR snapd#4126 opened: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4126>
<sergiusens> kyrofa should be on path with my quick fix on snapcraft#1652
<mup> PR snapcraft#1652: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>
<mvo> zyga-solus: above is a workaround but I'm not happy that I don't understand the root cause
<mvo> zyga-solus: I think we need to get back to this at some point. but right now 2.29.1 takes priority
<zyga-solus> mvo: aha
<kyrofa> sergiusens, argh. Did we run into pyramid issues again?
<sergiusens> it might be a while before we get a chance to run though, that's the queue length for the archive bionic 	1044 	- 	1086 	988 	335 	215
<kyrofa> Once the test refactor lands (snapcraft#1638) we can fix that
<zyga-solus> mvo: I have an idea, I will try it out now
<mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
<sergiusens> kyrofa no, with your skip implementation, the location of it, causing a cascading import effect
<sergiusens> kyrofa well, things need to move out of __init__
<sergiusens> we should also have one test package which is lean on auto importing
<mvo> zyga-solus: tell me please :)
<kyrofa> sergiusens, yeah, agreed
<pedronis> mvo: seems it's also failing on 2.29
<pedronis> also refresh-undo is failing, sometimes
<mvo> pedronis: yeah, I have pushed a workaround for the failing test
<mvo> pedronis: I don't understand the root cause yet though :(
<mvo> pedronis: I am looking at refresh-undo now too (running locally to see if I can reproduce)
<zyga-solus> mvo: sorry, some guests just arrived
<zyga-solus> mvo: I used this to debug an issue on 14.04 earlier
<zyga-solus> mvo: I hacked the systemd unit to redirect stdout/stderr to /var/log/snapd.log
<zyga-solus> mvo: it is a low-tech solution to journald being broken
<zyga-solus> mvo: I'll see what I get with that modification
<zyga-solus> mvo: tests are in progress, I mainly want to ensure we see the restart log
<zyga-solus> mvo: so that we know the workaround you proposed for .1 is OK
<mvo> zyga-solus: ok, note that I pushed a workaround for the test, i.e. use snap change --last=install to get the logs. would still be nice to know why journalctl starts misheaving
<zyga-solus> mvo: right, I want to ensure that workaround is safe for the time being
<zyga-solus> mvo: I agree about wanting to get to the bottom of the problem
<mvo> zyga-solus: \o/ thanks, we are in agreement
<pedronis> Chipaca: #4112 is also ready for input
<mup> PR #4112: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>
<kyrofa> snappy-m-o, github subscribe 1652
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1652 (tests: fork skip into snaps_tests).
<mup> PR #1652: Correct interface connection JSON documentation (used an object insteâ¦ <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1652>
<kyrofa> sergiusens, 2.34+git89.a25cfcc is in edge, but that commit is unknown to me
<kyrofa> Do you know what it is?
<sergiusens> kyrofa git pull -> "internal: more gracefully determine host OS (#1636)"
<mup> PR #1636: snap: don't load unsupported implicit hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1636>
<sergiusens> lol
<sergiusens> default for pounding a number is snapd PRs, oh well
<kyrofa> sergiusens, oh duh, I wasn't up to date. Sorry
<mup> PR snapd#4124 closed: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4124>
<kyrofa> Very good, we now have a snap that can be used on trusty, that's super exciting
<elopio> kyrofa: sergiusens when is a good time for you to talk about snapcraft in the code-in? what about 16 UTC?
<sergiusens> elopio is that an hour and a half from now?
<elopio> sergiusens: yes
<sergiusens> no that I am on gnome I have a hard time quickly looking at timezones :-P
<sergiusens> when you say utc I home you mean real utc (not dst) ;-)
<sergiusens> elopio can it be 1 hour 30 minutes further down?
<ogra_> dsutc
<elopio> sergiusens: so, now?
<zyga-solus> hmm, me got no logs at all
<zyga-solus> WTF
<sergiusens> elopio further into the future, not the past :-)
<sergiusens> move the pointer in time further from now, not closer (now is my reference)
<elopio> sergiusens: 18UTC works for me.
<sergiusens> elopio ok, can do if it is 30' at 18:30 as I have a knee appointment for this constant pain I've been having since I left for the past sprint
<kyrofa> sergiusens, that's what you get for fighting with the aikido masters
<elopio> 30 minutes should be enough to get us started and continue distributed. kyrofa what about you?
<kyrofa> elopio, I'm there
<elopio> ok, so if I understood correctly, from 18:30 to 19:00. I'll send the invite. Please correct it if I misunderstood.
<kyrofa> Wait... I understood 1800-(1830-driving delta)
<zyga-solus> mvo: drat
<zyga-solus> mvo: I ran it with extra logging
<zyga-solus> mvo: and it passed!!!
<zyga-solus> mvo: I didn't merge your branch yet so it was on vanilla setup
<zyga-solus> maybe it is really just random in some way
<zyga-solus> (I honestly think 14.04 needs love)
<elopio> sergiusens: do you mean start at 18:30 or finish at 18:30 ?
<sergiusens> kyrofa elopio if I can pick, 17:30 to 18:00
<sergiusens> or I will take the meeting from the waiting room ;-)
<mvo> zyga-solus: i was seeing it reliable (4/4) in my 14.04 qemu spread runs
<elopio> sergiusens: I have the community council meeting from 17 to 18.
<elopio> kyrofa sergiusens there is still plenty of time for this, what about tomorrow, maybe at 17UTC?
<zyga-solus> mvo: I was running linode (not enough ram for two vms)
<zyga-solus> mvo: but it did fail each time earlier
<zyga-solus> mvo: restarted at 15:47, let's see if it fails now
<tpatel> Does private snap auto-update on the refresh schedule if new version is available?
<mup> PR snapd#4127 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>
<tpatel> Does private snap auto-update on the refresh schedule if new version is available?
<mup> PR snapd#4128 opened: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4128>
<kyrofa> tpatel, I thought so. Does that seem to not be the case?
<kyrofa> tpatel, although I see this: https://forum.snapcraft.io/t/automatic-refresh-of-private-snaps/2530
<kyrofa> Is that the behavior you're seeing?
<tpatel> kyrofa: I have unit in the field for 7 days and I have new snap updated on the store past couple days and haven't seen it getting updated.
<kyrofa> tpatel, please join in on that thread, then. I pinged a snapd dev there to try and get it some attention
<tpatel> kyrofa, ok. I did not see any post for past 14 days on that thread so decided to raise my question here. Thanks though.
<kyrofa> tpatel, the thread is waking up. Please do add your details there
<jdstrand> mvo: note PR 4127. I didn't tag this one for 2.29 since I discovered it before anyone in nthe field noticed, but it has all the same qualities as 4115 and 4116 for inclusion
<mup> PR #4127: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>
<jdstrand> mvo: so, I'll leave it up to you
<mvo> jdstrand: checking
<mvo> jdstrand: looks good, thanks, I think we want this too, also looks reasonable small and safe
<jdstrand> mvo: I agree. note that I am off tomorrow, back monday
<jdstrand> mvo: thanks!
<Chipaca> sergiusens: is there a way for snapcraft to make a snap private, or is it web-only?
<mvo> jdstrand: thank you, special \o/ for all these fixes!
<sergiusens> Chipaca `snapcraft register <snap-name> --private`
<jdstrand> mvo: fyi, for 4114, 4415 and 4116, I'm getting unrelated spread test failures. linode:ubuntu-14.04-64:tests/main/snapd-reexec pretty consistently, but just now linode:ubuntu-core-16-64:tests/main/lxd failed
<jdstrand> I've restarted builds several times. not sure if I should stop doing that
<jdstrand> mvo: can you advise? ^
<Chipaca> sergiusens: no, it's already registered
<jdstrand> mvo: linode:ubuntu-core-16-64:tests/main/snap-auto-mount popped out in 4116
<sergiusens> Chipaca then no, web only (or maybe not even there)
<jdstrand> anyway, I'm happy to keep pressing restart build and see if one makes it if you want
<sergiusens> Chipaca we have no APIs for this
<Chipaca> sergiusens: it's doable on the web
<Chipaca> sergiusens: ok
<Chipaca> sergiusens: should we? :-)
<Chipaca> it'd make explaining what i did easier (copy-paste from terminal vs saying where to click)
<Chipaca> but, not important
<mvo> jdstrand: I noticed the snapd-reexec and there is a PR up for it. the lxd one is new as is the snap-auto-mount
<Chipaca> pedronis: do we have a way for the user to check if their macaroon is still valid?
<jdstrand> mvo: yes, but those are intermittent. I've pressed 'restart build' multiple times and they only just popped up
<jdstrand> maybe new PRs since I submitted were comitted...
<jdstrand> committed*
<zyga-solus> re
<zyga-solus> it failed now
<zyga-solus> looking
<jdstrand> mvo: I think I'll just document that the failures are unrelated
<pedronis> Chipaca: I'm not sure, this is not our most well worked out area
<zyga-solus> jdstrand: hey
<zyga-solus> jdstrand: quick request if you have the time today
<zyga-solus> jdstrand: can you please look at that one method I mentioned earlier, the one that sets up tmpfs "overlay"
<zyga-solus> jdstrand: I'll polish tests and everything else but if you disagree about the fundamental design of that I'd rather know earlier
<zyga-solus> jdstrand: do you need pointers to the code?
<pedronis> Chipaca: refresh itself doesn't gives back an error if your macaroon is expired, it just skips stuff
<pedronis> we can probably do a bit better in the new API
<Chipaca> pedronis: auto-refresh does not refresh private, for some reason
<mup> PR snapd#4129 opened: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4129>
<pedronis> Chipaca: auto refresh is not different fromÂ "snap refresh"
<pedronis> except the user 0
<pedronis> vs what you are
<Chipaca> pedronis: Â¯\_(ã)_/Â¯
<pedronis> Chipaca: we might have hit the  we don't refresh snaps as the user that installed them
<pedronis> issue
<pedronis> which we have ignored so far
<pedronis> (it's a bit of a mess)
<pedronis> there are a couple of approaches to that
<Chipaca> pedronis: to unblock these people, should i tell them to snap login as root (without sudo)?
<Chipaca> sounds horrible
<pedronis> IÂ don't know
<pedronis> Chipaca: remind me why sudo wouldn't work?
<Chipaca> pedronis: because we detect sudo and grab the actual user id
<pedronis> ah
<pedronis> so yes, maybe
<pedronis> or they stay without updates
<Chipaca> hmmm
<Chipaca> pedronis: autorefresh is done with userID 0, so no
<zyga-solus> mvo: ha
<zyga-solus> mvo: I have a log
<pedronis> Chipaca: no, what?
<zyga-solus> mvo: and it looks suspicious
<Chipaca> pedronis: doing snap login as root
<pedronis> ?
<mvo> zyga-solus: suspicious in what way? is it not resdtarting
<Chipaca> pedronis: "should i tell them to snap login as root" <- no
<zyga-solus> correct
<pedronis> Chipaca: it would fix stuff no?
<zyga-ubuntu> error: when trying to listen on /run/snapd.socket: socket "/run/snapd.socket" already in use
<Chipaca> pedronis: the _snapd user_ is 0, not the system user
<zyga-ubuntu> that's the error
<zyga-ubuntu> then snapd dies
<zyga-ubuntu> (I presume)
<pedronis> Chipaca: ah, so whoever logged in first?
<Chipaca> pedronis: no, that's 1
<Chipaca> 0 is no-one
<zyga-ubuntu> mvo: I used > rather than >> so I don't know anythin more, restarted now to get earlier logs
<pedronis> Chipaca: mmh, ok
<pedronis> so no, there's no workaround
<pedronis> we need to fix all the things
<zyga-ubuntu> mvo: perhaps we could consider doing this in 14.04 package
<zyga-ubuntu> +ExecStart=/bin/sh -c "@libexecdir@/snapd/snapd >>/var/log/snapd.log 2>&1"
<zyga-ubuntu> and add a logrotate.d entry
<mup> PR snapd#4117 closed: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4117>
<mvo> jdstrand: can we get 4114 targeted for 2.29 as well please? i.e. start from upstream/release/2.29 and cherry-pick the commits please
<mvo> zyga-ubuntu: hmmm, interessting. and strange. so you get this error when it tries to restart?
<zyga-solus> mvo: yes, that's the only thing in the log after the test
<zyga-solus> mvo: I fixed the unit to append to the log now
<zyga-solus> mvo: so we can know more in 15 minutes
<mvo> cool
<pedronis> Chipaca: I think we are converging toward the idea that private snaps are mostly for development, but this will bite also paid snaps
<Chipaca> pedronis: what does "mostly for development" mean?
<Chipaca> they still need to be refreshed, surely
<pedronis> Chipaca: I don't know
<jdstrand> zyga-solus: this popped out: http://paste.ubuntu.com/25873639/ on 17.10 classic with core from candidate
<pedronis> Chipaca: anyway afaict this never worked, it's not a regression, no?
<jdstrand> zyga-solus: I wasn't doing anything special. I can say that this snap plugs every interface via a corresponding command (I'm writing a spread test)
<zyga-solus> jdstrand: hey
<zyga-solus> jdstrand: mvo noticed this on the forum
<zyga-solus> jdstrand: this is not a new bug but we fixed logging
<jdstrand> zyga-solus: but ultimately just a missing rule
<zyga-solus> jdstrand: logs from snap-update-ns now actually show up
<jdstrand> that's nice :)
<zyga-solus> jdstrand: thank you for looking at this!
<jdstrand> zyga-solus: I'm trying to get my spread test working. will you fix the profile or shall I?
<zyga-solus> jdstrand: note that we had a very very old rule for fonts that we never implemented but this was recently done by jamesh
<pedronis> Chipaca: or maybe it worked when we were running refresh in a timer and if somebody did login as really root?
<zyga-solus> jdstrand: I'm looking at 14.04 but I can switch to that next, feel free to ignore if you have more urgent things
<cachio> mvo, any updates for the 29.1?
<jdstrand> zyga-solus: I probably won't get to it today (lots to do before I go eow), but if I have time and I see you haven't done it, I'll try
<zyga-solus> jdstrand: sounds good, I'll try to do it soon
<zyga-solus> jdstrand: should be easy rule tweak
<zyga-solus> jdstrand: spread test will be "hardest" ;-)
<pedronis> mvo: did you merged the workaround for 14.04 ?
<zyga-solus> pedronis: not yet
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/4130
<mup> PR #4130: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
<Chipaca> pedronis: yeah, refresh timer + no sudo handling would make this work
<mup> PR snapd#4130 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
<jdstrand> mvo: do you want me to do the same for 4115, 4116 and 4127?
<pedronis> Chipaca: we discussed killing the timer at some point though
<zyga-solus> jdstrand: 4130 has unrelated changes
<zyga-solus> jdstrand: please rebase -i and drop them
<jdstrand> dang it
<jdstrand> meh. cherry-pick didn't do what i wanted
<kyrofa> jdstrand, what were you hoping it'd do?
<sergiusens> meh, snapd tests flooded the adt queue
<jdstrand> grab just my commit
<Chipaca> pstolowski: when do cookies get cleaned up?
<kyrofa> jdstrand, that's exactly what cherry-pick should do. What DID it do?
<zyga-solus> mvo: I have a full log now
<zyga-solus> mvo: we are *not* restarting
<zyga-solus> mvo: I'll pastebin now
<Chipaca> pedronis: we'd have to store the user id in state, right?
<jdstrand> pulled in a bunch of stuff between 2.29 and master
<pedronis> Chipaca: maybe,   or send all the macaroons we have and let the store figure it out
<pedronis> something to do with the new api
<Chipaca> pedronis: can we do that?
<Chipaca> ah
<zyga-ubuntu> http://paste.ubuntu.com/25873750/
<jdstrand> I think anyway. redoing
<mup> PR snapd#4130 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4130>
<kyrofa> jdstrand, what did you cherry-pick? A merge commit? :P
<pstolowski> Chipaca, see removeSnapCookie in snapstate - discardSnap
<pedronis> Chipaca: currently API take only one user macaroon (via header), but the new api could take multiple but not something we can do without discussing with store people
<zyga-solus> mvo: ah, sorry, my grep was bad; we are restarting
<zyga-solus> mvo: I think your workaround is safe for 2.29
<jdstrand> kyrofa: no, the hash from my local branch
<mvo> zyga-solus: cool, waiting for spread to actually run :/
<Chipaca> pstolowski: ok, new question: why doesn't it work? :-)
<zyga-solus> mvo: is there a topic where I can put this info? I can start a new one
<mvo> zyga-solus: I think we need a new one
<zyga-solus> doing that then
<Chipaca> pstolowski: (i have 1 snap installed -- core -- and 59 cookies: 23 for core, the rest for snaps that i no longer have)
<jdstrand> kyrofa: so I did: git checkout -b foo upstream/release/2.29 ; git cherry-pick <hash from my local branch based on upstream/master>. that pulled in other commits
<pstolowski> Chipaca, oh. that's bad. I don't know without investigating. we have a spread test that checks that, should work...
 * jdstrand reads man page
<mvo> jdstrand: hm, what you did looks correct
<pedronis> Chipaca: one thing to consider/issue, is that we don't have good spread tests for private snaps atm
<pstolowski> Chipaca, hmm I can confirm I've a few leftovers on my system. but just one cookie file for core. what are the filenames of your cookies for core?
<mvo> jdstrand: I can also help, waiting for tests anyway
<kyrofa> jdstrand, yeah what you did sounds right
<kyrofa> jdstrand, can you push your local branch? I'm curious now
<jdstrand> actually, the local branch is ok. maybe I messed something up on the github end
 * jdstrand tries again
 * zyga-solus runs another 14.04 tes
<zyga-solus> my earlier data had a flaw that was causing false positives, I may have a chance to see the real error now
<Chipaca> pstolowski: the filenames of my cookies?
 * sergiusens takes a lunch break
<jdstrand> ok, yes. I thought it picked release/2.29 for the merge but it didn't, then confusion ensued
<pstolowski> Chipaca, /var/lib/snapd/cookie/*
<Chipaca> pstolowski: ah! i meant in staet
<jdstrand> mvo, zyga-solus: https://github.com/snapcore/snapd/pull/4131
<mup> PR #4131: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>
<mup> PR snapd#4131 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>
<Chipaca> state
<mvo> jdstrand: \o/
<Chipaca> pstolowski: in /var/libi/snapd/cookie i have snap.core
<Chipaca> s/bi/b/
<jdstrand> mvo: ok, did you want me to do the same for 4115, 4116 and 4127?
<mvo> jdstrand: please
<jdstrand> ok
<pstolowski> Chipaca, okay, I see junk in my state as well :(
<pedronis> Chipaca: we need to resurrect efforts in that area
<pstolowski> Chipaca, the logic around snapst.Sequence doesn't work as expected, apparently
<mvo> Chipaca: uh, junk?
<Chipaca> mvo: yeah
<Chipaca> pstolowski: it does work sometimes though, as i have no cookies for xbill :-)
<pstolowski> Chipaca, is there any magic around snapst.Sequence == 0 or snapst.Sequence == 1? wrong assumptions on my side around them?
<pedronis> well, junk, as in, too many cookies
<pedronis> not random data
<pstolowski> Chipaca, yeah, as I said, there is a spread test, but it's a very simple scenario apparently
<pstolowski> mvo, snap cookies are not always removed and left in the state and on disk
<mvo> pstolowski: hmmm, ok
<pedronis> are they no removed? or are they created even when there's one?
<pedronis> one almost never removes core
<mup> PR snapd#4132 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4132>
<pedronis> pstolowski: do we have a cooke per snap? or per revision?
<Chipaca> i can confirm that it doesn't always work: i just installed a snap, removed it, and the cookie is still there
<Chipaca> nothing refresh-ish about it :-)
<pstolowski> pedronis, right. too many are created. there should be one per snap, regardless of how many revisions you have
<Chipaca> (i was fearing it was some weird refresh thing -- but no)
<pedronis> createSnapCookie doesn't check if there is one already afaict
<mup> PR snapd#4133 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4133>
<Chipaca> so now i've installed and removed the same snap twice, and the first time it left the cookie behind, the second it didn't
<Chipaca> hmmm
<Chipaca> hmmm
<mup> PR snapd#4134 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4134>
<pstolowski> pretty weird, i just tested with brand new snap, all was cleaned up.
<Chipaca> HAH
<pstolowski> pedronis, but do LinkSnap does check snapst.Sequence.. should only createCookie for first snap installed. unless this is wrong assumption about sequence
<Chipaca> pstolowski: restart snapd between install and remove
<Chipaca> we might be being too lazy wrt loading the cookies
<Chipaca> dunno :-)
<pedronis> pstolowski: install a snap, disable it, reenable it, it will create two cookies (for example)
<jdstrand> mvo: ok, 4114, 4115, 4116, and 4127 all have PRs (4131-4134) which are milestoned to 2.29. let me know if you need anything else
<Chipaca> delicious, delicious cookies
<pedronis> IÂ think
<mup> PR snapd#4135 opened: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<pedronis> IÂ mean, I fear there are corner cases, such that just using the len of the sequence is not enough
<pedronis> or maybe not
<pedronis> something is off for sure
<Chipaca> pedronis: are you digging into this?
<pedronis> not really
<pedronis> what I see is that the code is naive, it will mutate the dict even or error
<pedronis> that's usually not what we do
<pedronis> we store things back into state usually only when we know the handler is succeding
<mvo> jdstrand: thank you
<pedronis> pstolowski: undoLinkSnap is strange there is code that check len sequence before we manipulate sequence and there is code doing the check after for something else
<pstolowski> pedronis, Chipaca I think the main problem is in snapmgr.GenerateCookies, i think this is the main source of duplicates
<pedronis> why would it be ?
<pedronis> pstolowski: UnlinkCurrentSnap has no remove cookie
<pedronis> that's also strange
<Chipaca> it seems every time i start snapd i get more cookies
<Chipaca> gah!
<Chipaca> pstolowski: you're right
<pstolowski> pedronis, the snap-cookies map uses cookieId as a key, GenerateCookies uses snap name as a key; I think this was changed at some point
<Chipaca> pstolowski: yep, that's where these are coming from
<pstolowski> and this method got out of sync
<pedronis> :/ blargh
<pstolowski> and perhaps there are edge cases as you say pedronis
<Chipaca> but also, agreed about pedronis wrt cookies not getting cleaned up on handler failure
<Chipaca> s/about/with/
<Chipaca> pstolowski: in a handler every return error needs to undo everything the handler did in there
<zyga-solus> drat 14.04
<zyga-solus> systemd behaves super oddly
<zyga-solus> quick coffee break
<pstolowski> pedronis, Chipaca I'll work on a fix. but I'm abit unclear about doDiscardSnap vs UnlinkCurrentSnap, isn't discard snap the only place to do it?
<pedronis> and there is something strange about unlink-current-snap vs its undo  (the latter create a cookie but the former doesn't remove it)
<pedronis> pstolowski: it depends
<pedronis> there are various way to it
<pedronis> but whatever you do needs to be balanced
<Chipaca> pstolowski: removing the 'break' in removeSnapCookie should go a long way to cleaning this up :-)
<Chipaca> anyway. cuppa tea.
 * Chipaca afk
<pedronis> pstolowski: it's a bit late for me, but we can chat another day about this,  what I'm noticing is that the remove/creat don't seem symmetrics to me atm
<pstolowski> Chipaca, I know I know...
<pedronis> and also that we Set cookies into the state too early in the handlers
<pstolowski> pedronis, k, thanks for taking a look at this.. I'll investigate further
<mup> PR snapcraft#1653 opened: internal: don't reuse variable in OsRelease <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1653>
<mborzecki> ok guys, i'm calling it a day
<Chipaca> YESSS
<Chipaca> it works
 * zyga-solus hugs Chipaca 
<Chipaca> zyga-solus: wait until you see it :-)
<Chipaca> anyway, forum, and then eod
<zyga-solus> I'm in 14.04 land
<zyga-solus> getting closer
<zyga-solus> feels very weird
 * Chipaca hugs zyga-solus 
<Chipaca> zyga-solus: you're needing them more than me!
<zyga-solus> Chipaca: hehe
<Chipaca> systemd *and* 14.04
<zyga-solus> Chipaca: the 14.04 abyss hugs me all the time
 * ogra_ wasnt aware there is a 14.04 solus 
<zyga-solus> ogra_: offtopic, I recently installed windows on my thinkpad
<ogra_> so where is the zyga-windows nick then ?
<zyga-solus> ogra_: so ubuntu 17.10, vm with windows 10, WLS inside
<zyga-solus> ogra_: to see what kind of "kernel" features are available :)
<ogra_> heh
<zyga-solus> ogra_: nah, I don't run irc from zyga-ubuntu-windows-wsl-ubuntu
<zyga-solus> :D
<mup> PR snapd#4131 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4131>
<mup> PR snapd#4128 closed: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4128>
<zyga-solus> mvo: that 14.04 bug is weird
<zyga-solus> I have a feeling my changes are not being used
<zyga-solus> I just added "trolololo" to a startup line to see if it shows up
<mvo> zyga-solus: hm, ok
<zyga-solus> mvo: 10 minutes to find ut
<zyga-solus> out
<zyga-solus> ha
<zyga-solus> so curious now
<zyga-solus> my changes in outer function are picked up
<zyga-solus> those on the inner one are not, so I made a mistake
<zyga-solus> looking
<zyga-solus> ha
<zyga-solus> I see it
<zyga-solus> ok, let's see what this unfolds
<zyga-solus> we seem to report one error incorrectly, swallowing the real problem
<zyga-solus> mvo: OMG :)
<zyga-solus> either it's a very simple bug
<zyga-solus> or it's very non-tricky code
<zyga-solus> er
<zyga-solus> tricky code
<zyga-solus> mvo: if you are still around, please open daemon.go
<zyga-solus> hmmm
<zyga-solus> actually, no :/
<zyga-solus> darn
 * zyga-solus keeps looking
<mvo> zyga-solus: are you sure its not a external bug?
<zyga-solus> mvo: no, just me making silly mistakes still
<zyga-solus> mvo: that lead me astray
<mvo> zyga-solus: to me it smeels like journalctl is swallowing data
<zyga-solus> yes but attempting to see what's really going on lead me on a goose chase
<zyga-solus> I should now have both correct logs _and_ not disturb socket activation
<mvo> zyga-solus: great
<mvo> zyga-solus: tests are really slow today, but I hope we can still do 2.29.1 tonight, lets see
<zyga-solus> mvo: yeah, would be good to do that
<zyga-solus> thank you for staying longer to ensure that
<mvo> zyga-solus: there is new info from the libreoffice report in the "2.29 release cycle started" thread
<zyga-solus> oh, great - looking
<zyga-solus> aha
<zyga-solus> I can fix those very quickly
<zyga-solus> mvo: the bug is that we try rw sharing and the rules are for "ro" sharing
<zyga-solus> oh, curious, we do request "ro"
<zyga-solus> hmm
<zyga-solus> oh
<zyga-solus> silly
<zyga-solus> jdstrand: around?
<zyga-solus> jdstrand: can you please review https://github.com/snapcore/snapd/pull/4136
<mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
<zyga-solus> mvo: ^
<mup> PR snapd#4136 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
<zyga-solus> mvo: I'll write a spread test
<zyga-solus> there's something weird still
<zyga-solus> the denials says flags="rw, bind"
<zyga-solus> but we definitely do "ro"
<zyga-solus> so either a bug in apparmor logging or in snapd
<zyga-solus> spread will show
<mvo> zyga-solus: this is just a warning, right?
<mvo> zyga-solus: fwiw, the refresh-undo test is also failing and it is also using journalctl output so I strongly suspect this is related
<zyga-solus> mvo: this is a warning but the bug is real
<zyga-solus> mvo: warning as in "I tried it and it failed"
<mvo> zyga-solus: ok
<zyga-solus> mvo: if we could have 4113 it would be easier to test
<zyga-solus> I'll cherry pick that in and adjust the test to cover this case
<zyga-solus> mvo: I pushed a spread test, let's see if it passes now
<zyga-solus> mvo: I'll get back to 14.04
<zyga-solus> mvo: if you want a low-risk .2 cherry-pick get the 1st commit from 4136
<zyga-solus> mvo: but only if the spread test passes please
<mvo> zyga-solus: ok, please add a PR based on 2.29 for this
<mvo> zyga-solus: for this commit
<zyga-solus> mvo: sure
<zyga-solus> done
<zyga-solus> IFF the other one passes please merge it
<mup> PR snapd#4137 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>
<zyga-solus> tagged and renamed
<mvo> zyga-solus: thank you
<zyga-ubuntu> mvo: I'll doze off until tests show something
<zyga-ubuntu> mvo: from what I can see socket activation is not passing the right stuff when things fail
<zyga-ubuntu> mvo: down to the environment, there's nothing there
<zyga-ubuntu> mvo: I'll keep shrinking my debug changes to see if I broke it
<zyga-ubuntu> but now, mental break
<mup> PR snapd#4126 closed: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4126>
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4136 has +1 from jdstrand (thank you!)
<mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
<jdstrand> np
<zyga-ubuntu> mvo: the grammar aside (I'll fix that tomorrow) I think it's worth merging
 * zyga-ubuntu restarted 14.04 test with no -reuse, to see what happens on a clean system
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: not sure if you have time before you go
<zyga-ubuntu> https://github.com/zyga/snapd/blob/feature/transparent-tmpfs/cmd/snap-update-ns/utils.go#L132
<zyga-ubuntu> if you can just eyeball that quickly
<zyga-ubuntu> and tell me if this is sane
<zyga-ubuntu> (just one function)
<zyga-ubuntu> mvo: thank you for merging master back into that fix RP
<zyga-ubuntu> *PR
<mvo> zyga-ubuntu: yeah, keen to get results
<zyga-ubuntu> uh
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4123/commits
<mup> PR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
<zyga-ubuntu> WTF?
<zyga-ubuntu> this is weird
<zyga-ubuntu> I'm 100% sure this was a rebased branch
<zyga-ubuntu> with no other stuff in it
<zyga-ubuntu> github playing tricks?
<zyga-ubuntu> mvo: I removed 2.29 milestone from https://github.com/snapcore/snapd/pull/4136
<mup> PR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>
<zyga-ubuntu> mvo: this one is for 2.29 https://github.com/snapcore/snapd/pull/4137
<mup> PR #4137: cmd/snap-update-ns: fix mount rules for font sharing (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>
<zyga-ubuntu> mvo: I force pushed on https://github.com/snapcore/snapd/pull/4123
<mup> PR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>
<mvo> zyga-ubuntu: ok, thanks. but it looks not good, tests are not running
<zyga-ubuntu> mvo: where?
<zyga-ubuntu> 4123?
 * zyga-ubuntu looks
<mvo> zyga-ubuntu: nowhere, almost none of the 2.29 PRs has started :/
<zyga-ubuntu> two failures on 4123, not sure if related to what we saw
<zyga-ubuntu> yeah, maybe we should call it a night and just carry on tomorrow
<mvo> yeah, it feels like it unfortunately
<sergiusens> mvo are you doing adt?
<sergiusens> there is starvation going on right now http://autopkgtest.ubuntu.com/running
<mup> PR snapcraft#1654 opened: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>
<mvo> sergiusens: travis
<mvo> sergiusens: heh, bionic is doing it!
<kyrofa> sergiusens, yeah, snap builders are starving too
<mvo> zyga-ubuntu: I'm slightly sad but its no good, travis is too slow to wait for it, I will continue with this first thing in the morning
 * mvo waves
<zyga-ubuntu> mvo: o/
<zyga-ubuntu> rest well
<zyga-ubuntu> 2017-11-02 22:01:49 Cannot allocate linode:ubuntu-14.04-64: no powered off servers in Linode account exceed halt-timeout
<zyga-ubuntu> well
<zyga-ubuntu> linode tries to tell me to EOD
<mvo> haha
<zyga-ubuntu> more tomorrow
<mvo> yeah
<mup> PR snapcraft#1578 closed: project_loader: quote more environment variable values <bug> <Created by malept> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1578>
<kyrofa> sergiusens, wait... we've been waiting all day and our test hasn't even started yet. Time to run the whole thing locally?
<sergiusens> kyrofa have you seen the size of the queue?
<kyrofa> Just now
<kyrofa> Insane
<kyrofa> Although not for xenial:amd64, and I don't see snapcraft in it
<kyrofa> Which is interesting. Maybe I don't now how to use it
<kyrofa> All I see there is systemd
<zyga-solus> sergiusens: what is the size of the queue?
<kyrofa> zyga-solus, autopkgtest.ubuntu.com/running
<zyga-solus> oh
<zyga-solus> 1K2
<zyga-solus> what is huge vs ubuntu?
<zyga-solus> bionic has 4K tests, man
 * zyga-solus gets back to family, ttyl
<jdstrand> zyga-solus: I didn't review it closely. the idea of putting something to the side so you can later get them seems ok in general. I can say that anything that is in the original is mounted twice (ie, in the original dir and then again on top)
<jdstrand> and you won't be able to clean that up since they are underneath (assuming I didn't mis something)
<zyga-solus> jdstrand: aha, interesting
<zyga-solus> jdstrand: I'll think about the possible consequences
<zyga-solus> tomorrow, if we have tests back, not sure about that seeing the queue size, I will make the PR proposable
<sergiusens> zyga-solus it is too big to have it cleared tomorrow, I don't know if there is fair queuing in play or not, but the archive adt is humongous
<sergiusens> kyrofa snapcraft is under the upstream tests queue
<sergiusens> search for snapcraft-daily
<kyrofa> Ah
#snappy 2017-11-03
<teej> How does Snappy differ from Flatpak?
<mup> PR snapd#4134 closed: interfaces/uhid: unconditionally add existing uhid device to the device cgroup (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4134>
<mup> PR snapd#4137 closed: cmd/snap-update-ns: fix mount rules for font sharing (2.29) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4137>
<mup> PR snapd#4127 closed: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4127>
<mup> PR snapd#4132 closed: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4132>
<mup> PR snapd#4133 closed: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4133>
<mup> PR snapd#4116 closed: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4116>
<mup> PR snapd#4114 closed: interfaces: don't udev tag devmode or classic snaps <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4114>
<mup> PR snapd#4123 closed: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4123>
<mborzecki> morning
<mvo> hey mborzecki, good morning
<mup> PR snapd#4064 closed: tests: new test for hardware-random-control interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4064>
<zyga-solus> hey
<zyga-solus> mvo: goodmorning
<zyga-solus> mvo: man, you're up early
<zyga-solus> mvo: btw, about tests being slow: http://autopkgtest.ubuntu.com/running
<mvo> zyga-solus: yeah, well, travis is the main issue
<mborzecki> zyga-solus: morning
<zyga-solus> hey mborzecki
<mborzecki> is there a checker in gocheck lib that can verify if something is in a list? something similar to this: https://godoc.org/github.com/stretchr/testify/assert#Assertions.Contains
<mborzecki> (disclaimer, i've quite heavily used testify/assert and testify/mock packages before)
<zyga-solus> mborzecki: I wrote one
<zyga-solus> mborzecki: in testutils/
<mborzecki> thx
<zyga-solus> mborzecki: ironically this was one of my first patches to snapd :D
<zyga-solus> and my first go code
<zyga-solus> "where is contains in this language"
<mborzecki> zyga-solus: you mentioned that account-control is feeding bad information on arch
<mborzecki> i'm fixing this right now (or at least that's what i think i'm doing)
<mup> PR snapd#4115 closed: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4115>
<zyga-solus> mborzecki: excellent, thank you!
<mvo> zyga-solus: 4136 is failing for real it seems
<mvo> zyga-solus: the /run/snapd/ns/snapd.test-snapd-desktop.fstab just contains fontconfig three times ?!
<zyga-solus> looking
<zyga-solus> I wrote that one "dry", without running it
<zyga-solus> autopkgtest.ubuntu.com is very slow for me
<mvo> zyga-solus: this is available in travis (which is also slow) and I have a local shell in qemu open right now, but it looks strange, almost as if we just mount systemfontconfigcachedir three times instead of systemfontsdir, systemlocalfontsdir
<mvo> zyga-solus: aha, no, the fstab file is correct in /var/lib/snapd/mount
<zyga-solus> mvo: can you paste both fstab files please
<zyga-solus> the one in /var/lib/snapd/mount/ and in /run/snapd/ns
<zyga-solus> I'll try localy but it will take some time
<mvo> zyga-solus: http://paste.ubuntu.com/25877947/
<zyga-solus> ha
<zyga-solus> that's very werid
<zyga-solus> thanks, I'll dig
<zyga-solus> mvo: if you still have the shell
<zyga-solus> before I get there
<zyga-solus> can you please nsenter and look at mountinfo
<mvo> zyga-solus: http://paste.ubuntu.com/25877952/
<zyga-solus> thank you
<zyga-solus> mounts doesn't show the source correctly
<zyga-solus> I'll run locally and debug, no worries
<mvo> zyga-solus: mountinfo looks correct, no? so its just the outside that looks fishy?
<mborzecki> do you amend/fixup/rebase/reshuffle commits in a PR or just add new ones on top?
<zyga-solus> no, mounts doesn't show this at all
<zyga-solus> mborzecki: we usually add and squash
<zyga-solus> (when merging)
<mborzecki> working around github's mess? :)
<zyga-solus> mborzecki: optimizing for review flow
<zyga-solus> mvo: if you hold the release for 30 minutes until we get a better picture I can help analyze this
<mup> PR snapd#4138 opened: release: 2.29.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4138>
<mvo> zyga-solus: too late for 2.29.1, if its something grave we need a 2.29.2
<zyga-solus> k
<mvo> zyga-solus: inside the ns I have /usr/share/fonts from the outside afaict ?
<zyga-solus> mvo: yes,
<mvo> zyga-solus: so what is missing :) ?
<zyga-solus> mvo: but please tail mountinfo (not mounts)
<zyga-solus> mvo: because the earlier pastebin was inconclusive
<zyga-solus> (mounts doesn't show the relevant stuff)
<zyga-solus> I worry about why that thing was listed three times, that's very fishy
<mvo> zyga-solus: http://paste.ubuntu.com/25877985/
<zyga-solus> this is correct
<zyga-solus> so
<zyga-solus> if this is correct, why was the other file wrong :D ?
<zyga-solus> did you just ran the test?
<zyga-solus> or experiment in some other way?
<mvo> zyga-solus: I did nothing to the system, just ran the spread test in qemu. the output looks consistent with what linode outputs
<mborzecki> i probably don't know what i'm doing, but I've updated https://github.com/snapcore/snapd/pull/4135
<mup> PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<zyga-solus> thank you, I'll look now
<zyga-solus> mborzecki: that looks very good to me
<mborzecki> btw. has anyne seen something like https://paste.ubuntu.com/25878010/ ?
<mborzecki> snapSeccompSuite.TestRestrictionsWorkingArgsUidGid failing with 'setuid u:daemon'
<zyga-solus> mvo: reproduced now
<mvo> mborzecki: not this particular error, this is the seccomp confinement test, it runs on the real (running) kernel
<zyga-solus> mborzecki: hmmm
<zyga-solus> mborzecki: just checking, you do have an user called daemon on your system, right?
<mvo> mborzecki: I assume this is the arch kernel?
<mborzecki> suprisingly, i did not see this yday, then ran pacman -Syu in the evening, and rebooted to a new kernel today :)
<mborzecki> mvo: yes, it's an arch kernel
<mvo> mborzecki: what version is that?
<mborzecki> 4.13.10-1-ARCH
<zyga-solus> it's curious btw, it seccomp is so well established that this should not fail
<mvo> mborzecki, zyga-solus maybe its argument filtering and something with daemon is different on arch?
<mborzecki> i'll poke around
<zyga-solus> mvo: perhaps
<mvo> mborzecki: whats the uid of your daemon user?
<mborzecki> daemon:x:2:2:daemon:/:/usr/bin/nologin
<mvo> mborzecki: there you go :/ the test assumes "1"
<mvo> mborzecki: {"setuid u:daemon", "setuid;native;1", main.SeccompRetAllow},
<mvo> mborzecki: i.e. it sends the setuid (native arch) syscall with arg 1 which does not work on arch. silly test !
<mborzecki> heh, i can fix that
<mvo> mborzecki: thanks
<mborzecki> btw. uid 1 is 'bin', interesting
<zyga-solus> mborzecki: it's all broken
<zyga-solus> distros don't agree on any uid other than root
<mborzecki> trying to remember what it was in yocto
<zyga-ubuntu> mvo: http://pastebin.ubuntu.com/25878071/
<zyga-ubuntu> this is the failure
<zyga-ubuntu> something is clearly wrong
<zyga-ubuntu> man :/
<zyga-solus> mvo: I _think_ I know
<mvo> zyga-solus: what are the implications of this bug?
<zyga-solus> bad stuff is in the current profile
<zyga-solus> but namespace is correct
<zyga-solus> it shows up when > 1 entry is present
<zyga-solus> but I'm a bit DOH
<mvo> zyga-solus: what is the implication of bad stuff in the current profile?
<zyga-solus> golang feature
<zyga-solus> mvo: we'll undo stuff that's not done
<zyga-solus> mvo: it will all fall apart as we try to "mend" it
<mvo> zyga-solus: when do we do that? on refresh?
<zyga-solus> when we setup security
<mvo> zyga-solus: so things will explode when snapd is restarted?
<zyga-solus> not really explode
<zyga-solus> it will not return a failure code
<zyga-solus> mvo: testing a small fix
<mvo> zyga-solus: hm, maybe I need to ask differently. this freeze/thaw is something new added, its not in 2.29 iirc. so does this affect 2.29 and if so what are the implications for the users, i.e. is it just internal or are there visialbe regressions?
<zyga-solus> mvo: unless I'm mistaken golang does something I didn't expect
<mvo> zyga-solus: looking forward to see the diff :)
<zyga-solus> mvo: this should not affect freeze/thaw
<mvo> zyga-solus: so this affects 2.29?
<zyga-solus> mvo: taking the address of a variable on iteration seems to return the same thing over and over
<zyga-solus> mvo: as if this was a loop local temporary
<zyga-solus> mvo: so :/
<zyga-solus> mvo: it's scaryt
<zyga-solus> we had this since forever
<mvo> zyga-solus: could you paste the diff? just so that I can get an idea
<zyga-solus> yes
<mvo> zyga-solus: thanks
<zyga-ubuntu> http://paste.ubuntu.com/25878114/
<zyga-ubuntu> where else are we doing something like this?
<mborzecki> zyga-solus: can you point me to the code with this iteration?
<zyga-ubuntu> why doesn't golang warn / error on this
<zyga-ubuntu> mborzecki: please look at main.go in cmd/snap-update-ns
<zyga-ubuntu>         changesMade = append(changesMade, change)
<zyga-ubuntu> a variant of this line
<zyga-ubuntu> near line 164
<zyga-ubuntu> (I applied a helper patch so there may be an offset)
<mvo> zyga-ubuntu: if we had this forever and nothing bad happens, is it critical for 2.29.1?
<zyga-solus> mvo: nobody noticed / tested >1 mount entry
<zyga-solus> mvo: I think .2 is in order now that we know really
<mborzecki> zyga-solus: it's always taking the same &change?
<zyga-solus> mvo: especially since this will really mess up all the desktop interface snaps over time
<zyga-solus> yes
<zyga-solus> mborzecki: that's what it looks like
<zyga-solus> testing a fix now
<mvo> zyga-solus: well, maybe. I want to understand what happens if we don't fix it
<zyga-solus> mvo: I can tell you in 20 minutes after another test where I undo this
<mborzecki> can you drop _, change := range ... and use for i := range changesNeeded ... { change := changesNeeded[i] .. } ?
<zyga-solus> mvo: ok, with the patch it works
<zyga-solus> mborzecki: right, I understand that now, I just found it unexpected
<mborzecki> hit this myself a couple of times, enough to make me doubt range
<mborzecki> typical scenarios is the code inside is calling goroutines or doing syscalls (which are rescheduling points)
<zyga-solus> mvo: patch pushed
<mvo> zyga-solus: I think I would slightly prefer the minmal diff that mborzecki suggests (using an for i := ... loop). anyway, sorry for being difficult
<zyga-solus> mvo: no, please look at the patch
<zyga-solus> mvo: the patch is minimal and simpler semantically
<mvo> zyga-solus: just trying to understand the implications of this
<mvo> zyga-solus: ok, checking
<zyga-solus> mvo: 14 lines changed
<zyga-solus> one character each
<mborzecki> lgtm
<zyga-solus> and thank $DIETY for spread tests!
<mborzecki> pushed another patch to https://github.com/snapcore/snapd/pull/4135 cmd/snap-seccomp tests are all passing now
<mup> PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<zyga-solus> mvo: will you take that patch?
<mvo> zyga-solus: tbh, I'm still on the fence, if its not a regression and it has not yet caused problems yet I'm not sure. but lets prepare a 2.29 PR so that we have it
<zyga-solus> mvo: ok
<zyga-solus> mvo: if you can take it I'd suggest so
<zyga-solus> mvo: it's a clear bug
<zyga-solus> mvo: and the more we use content interface the more harm it will cause
<zyga-solus> mvo: I'll make a 2.29 PR for you
<mvo> zyga-solus: thank you
<zyga-solus> done, 4139
<mup> PR snapd#4139 opened: cmd/snap-update-ns: fix collection of changes made <Created by zyga> <https://github.com/snapcore/snapd/pull/4139>
<mvo> zyga-solus: thank you
<mborzecki> FYI 'nogroup' is replaced with 'nobody' in arch
<zyga-solus> mborzecki: yeah, I'm afraid some of those tests will look like Swiss cheese
<mborzecki> zyga-solus: is 'nogroup' used in other placed in the code?
<zyga-solus> mborzecki: I don't think so, we only used it for tests
<zyga-solus> (AFAIK I made that change)
<zyga-solus> mborzecki: to work around other things that weren't common between ubuntu and solus
<mborzecki> good, this is the last unit test that fails here
<mborzecki> btw. is there a not-empty checker?
<zyga-solus> HasLen, 0 is useful
<kalikiana> good morning, snappy
<mvo> mborzecki: depends on what you need, there is "HasLen"
<zyga-solus> hey kalikiana :)
<mborzecki> Not(HasLen), 0 ?
<mup> PR snapd#4140 opened: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
<zyga-solus> mborzecki: yes
<zyga-solus> mborzecki: note that we can add IsEmpty or similar
<zyga-solus> mborzecki: it's not hard to add a new checker
<zyga-solus> mborzecki: and especially when the error messages are nicer, this could be useful
<pedronis> pstolowski: hi,  looking at #4108 again,   do we need Hooks/Apps on ConnectedSlot ?  you didn't implement Hooks
<mup> PR #4108: repo: ConnectedPlug and ConnectedSlot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/4108>
<pstolowski> pedronis, hi, we don't have Hooks on slots, per comment and implementation in snap/info.go in the existing code
<pedronis> pstolowski: but we have apps?  do we use them?
<pstolowski> pedronis, we do, they affect SecurityTags()
<mborzecki> can this https://github.com/snapcore/snapd/pull/4119 be merged, or should i rebase on top of master?
<mup> PR #4119: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4119>
<zyga-solus> looking
<zyga-solus> mborzecki: yeah, or merge master
<mup> PR snapd#4141 opened: snap-update-ns: add missing unit test for desired/current profile handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/4141>
<zyga-solus> nice!
<mborzecki> rebased and pushed
<pedronis> pstolowski: thanks
<pedronis> pstolowski: zyga-solus:  shouldn't places  in  interaces  doing   range plug.Apps  ?Â  also consider plug.Hooks ?
<pedronis> *interfaces
<zyga-solus> pedronis: yes, do you know of one that does not?
<pedronis> they all don't
<pedronis> afact
<pedronis> I'm not even sure the interface is the best given the issue
<zyga-solus> pedronis: hmm
<pedronis> zyga-solus: there's a bunch of plug.Apps in interfaces/builtin but not plug.Hooks
<pedronis> afaict
<pedronis> I suppose we didn't notice because the interfaces that need that are not typical hook plugs
<pedronis> but IÂ suppose there is an issue
<zyga-solus> indeed
<zyga-solus> I see this in common
<zyga-solus> and in other places
<pstolowski> info.go // NOTE: hooks cannot have slots
<pstolowski> ah, sorry, you're asking about plugs
<zyga-solus> yes
<zyga-solus> pedronis: it's isolated to udev handling, it seems
<zyga-solus> pstolowski: do you want to fix it or shall I?
<zyga-solus> pedronis: thank you for spotting!
<pstolowski> zyga-solus, i'm currently working on cookies issue from yesterday
<zyga-solus> ok
<zyga-solus> I'll do it
<pedronis> pstolowski: also related, IÂ notice that plugJSON has no hooks either
<pstolowski> pedronis, thanks, will fix
<pedronis> IÂ don't know if it's important, are we still using plugJSON ?
<mvo> zyga-solus: 4139 has unit tests failures, fix is trivial http://paste.ubuntu.com/25878484/ - could you please update?
<zyga-solus> sure
 * zyga-solus wonders how that happened, I go tested this
<zyga-solus> done
<zyga-solus> mvo: ah, the backport, I must have not tested that one
<Chipaca> aw, you can't make an alias into a namespace :-(
<Chipaca> - Setup manual alias "xbill-xaw.xbill-xaw" => "xbill-xaw" for snap "xbill-xaw" (cannot enable alias "xbill-xaw.run" for "xbill-xaw", it conflicts with the command namespace of installed snap "xbill-xaw")
<Chipaca> gah, mis-paste
<Chipaca> - Setup manual alias "xbill-xaw.run" => "xbill-xaw" for snap "xbill-xaw" (cannot enable alias "xbill-xaw.run" for "xbill-xaw", it conflicts with the command namespace of installed snap "xbill-xaw")
<Chipaca> (yes that is kinda backwards)
<mup> PR snapd#4138 closed: release: 2.29.1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4138>
<Chipaca> how're you doing, mborzecki ?
<mvo> oSoMoN: fwiw, I can reproduce the chromium nvidia black screen issue here
<mvo> oSoMoN: I get mknod denials for seccomp
<mborzecki> Chipaca: good, fixed all unit tests that were failing on arch, lookign into updating arch package now
<mvo> oSoMoN: and manually adding "mknod" to the seccomp profile works
<Chipaca> mborzecki: neat
<mvo> oSoMoN: well, works in the sense that when i do that, recompile the profile and start chromium it works
<mborzecki> Chipaca: there's a PR open https://github.com/snapcore/snapd/pull/4135 in case you want to sake a second look
<mup> PR #4135: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>
<oSoMoN> mvo, thanks for the feedback! do the denials indicate which node chromium is trying (and failing) to create?
<mvo> oSoMoN: I try to figure this out right now, it does not give me this data currently
<oSoMoN> mvo, you'll probably need to strace it to get that info
<mvo> oSoMoN: yes
<zyga-solus> or run it and look at /tmp
<mvo> zyga-solus: /tmp ?
<zyga-solus> well, it has to keep the node somewhere
<zyga-solus> so /tmp or /run
<zyga-solus> or $HOME
<pedronis> mborzecki:   we tend to title our PRs   with:  comma-separated relevant packages or dirs or "many"   ":"  lowercase summary
<mborzecki> pedronis: noted, thanks
<pedronis> mborzecki:   like "cmd/snap,client,daemon: show ignore-validation if set in snap info"
<mborzecki> pedronis: I can rename it now, but I'm afraid it might restart the builds
<zyga-solus> mborzecki: no need
<zyga-solus> mborzecki: just hit edit on GH
<mborzecki> updated
<pedronis> yes, this is about the PRÂ title and the merge commit, not the commits inside
<pedronis> we are not very strict, but this is the idea
<mborzecki> ok
<Chipaca> mborzecki: git log --oneline --no-merges <- we try to make this readable (it's a struggle)
<Chipaca> zyga has a link with more rationale
<zyga-solus> me? I don't recall
<Chipaca> yus
<zyga-solus> now that you said that I do recall
<zyga-solus> but I don't recall what it was :)
<zyga-solus> I recall _something_ :D
<mborzecki> aah, yeah, i'm used to rebasing a lot :) this usually kept the history linear
<pedronis> it's a struggle because we aren't as rebase happy as other projects,
<pedronis> mborzecki: yea,  general rule we don't rebase after a PR got some comments, we tend not to squash commit either unless the PR is messy, then we do
<pedronis> the results are mixed
<pedronis> also we have rules how the merge commit should look like but it's a struggle to remember to apply them when clicking in GH
<mborzecki> noted :) sorry cause i've rebased both PRs already
<mborzecki> some project do merges outside of github just to keep the history linear, iirc zephyr does that
<Chipaca> that's ok, we won't burn you alive for the first one
<Chipaca> :-)
<zyga-solus> mborzecki: github has an option to rebase nowadays
<Chipaca> (but really, these are our intentions; then things are on fire and it all goes out the window)
<mborzecki> though it's still not particularly review friendly with rebase/fixup workflow :(
<mborzecki> small things like ordering commits chronologically rather than using the order from git
<pedronis> mmh, IÂ don't this stuff in written in the form or the readmes ?
<pedronis> s/form/forum/
<mborzecki> any idea why libseccomp is linked statically into snap-seccomp?
<zyga-solus> mborzecki: because of re-exec woes
<zyga-solus> mborzecki: snapd needs to operate on systems where libseccomp is old/unpatched
<pedronis> Chipaca: are you working on aliases? or the private refresh bug?
<Chipaca> pedronis: aliases; AIUI refresh needs gustavo (and it's just one more day)
<Chipaca> pedronis: if you want to start in it feel free :-) my plate has plenty on it
<pedronis> no,  mostly asking if you had time for some reviews
<Chipaca> alwaysÂ¹
<Chipaca> 1. not always
<zyga-solus> LOL
<zyga-solus> 1. conditions apply
<Chipaca> ;)
<pedronis> Chipaca: interested in your feedback on #4112
<mup> PR #4112: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>
<Chipaca> pedronis: https://github.com/snapcore/snapd/pull/4112/files?w=1
<Chipaca> (ignore whitespace for the github diff)
<Chipaca> pedronis: hm, i would've put it in notes
<Chipaca> pedronis: then you also get it (for free) in snap list
<pedronis> well I asked for feedback,
<pedronis> otoh you get notes only with  --verbose
<Chipaca> pedronis: no, you get the expanded notes with --verbose
<Chipaca> pedronis: without it you get them a la list
<pedronis> ah, so seems the right thing to do
<pedronis> let me close this
 * Chipaca will allow it
<Chipaca> :-D
<mup> PR snapd#4112 closed: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4112>
<pedronis> Chipaca: ah, it's a cmd/snap concept, not a rest api concept
<Chipaca> yes, the client side is fine
<pedronis> good(tm)
<pedronis> Chipaca: is ignore-validation too long for notes?
<Chipaca> pedronis: do you have something better?
<pedronis> no
<mup> PR snapcraft#1652 closed: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>
<Chipaca> pedronis: 's fine
<pedronis> ah, I still need my code for the verbose case
<pedronis> that's a little odd
<sergiusens> snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64 bionic:amd64 bionic:armhf bionic:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
<zyga-solus> tests are not with me today
<mup> PR snapd#4142 opened: cmd/snapd,client,daemon: display ignore-validation flag through the notes mechanism <Created by pedronis> <https://github.com/snapcore/snapd/pull/4142>
<pedronis> Chipaca: ^
<Chipaca> pedronis: lovely
<mborzecki> zyga-solus: you introduce packaging for arch, can you take a look at this patch: https://github.com/bboozzoo/snapd/commit/1ac38e2614cef8e30d17b8800bc18c1abeac9409
<zyga-solus> looking
<mborzecki> once arch related PRs get merged, i'd like to publish this to AUR as snapd-git
<zyga-solus> mborzecki: I merged snap-confine into one package now
<zyga-solus> mborzecki: btw, did you see the packaging that was added to 2.27.x releases?
<zyga-solus> (on GH release pages)
<zyga-solus> ah, I was confused by depends on snap-confine
<mborzecki> yes, but the community package is still split into snapd and snap-confine, unless it's listed in conflicts pacman will not try to remove it
<zyga-solus> hmm
<zyga-solus> mborzecki: I see
<zyga-solus> that's unfortunate
<zyga-solus> can we do anything about that?
<mborzecki> zyga-solus: it's there, snap-confine is listed in conflicts in my patch, this should do the trick
<zyga-solus> ah, I see
<zyga-solus> +1 then
<zyga-solus> not sure if other things are done
 * zyga-solus looks
<zyga-solus> nope
<zyga-solus> look at 2.27.x releases for updated packaging
<zyga-solus> things like snap-exec etc are missing
<mvo> oSoMoN: I added some info into the forum post, chromium acts a bit strange, maybe its something specific to their code but it tries to create /dev/nvidiactl which is already avialable in the namespace and which the same pid stat()s successfully a couple of times before
<oSoMoN> mvo, thanks, that's very useful, I'll dig in chromium code to try and understand why they would do that
<mborzecki> zyga-solus: hmm looks like arch packaging was never updated to include snap-exec :/
<zyga-solus> mborzecki: not the one in the repo (as it was never upstreamed)
<mvo> oSoMoN: thanks, might be an issue on our side too, but from the strace it looks like something strange is happening in the code
<zyga-solus> mborzecki: sorry about that, arch situation is a bit unoptimal
<mborzecki> can you point me to the code?
<zyga-solus> sure
<zyga-solus> https://github.com/snapcore/snapd/releases/tag/2.27.5
<zyga-solus> there's a source package for arch attached
<zyga-solus> https://github.com/snapcore/snapd/releases/download/2.27.5/snapd-2.27.5-1-arch-srcpkg.tar.gz
<zyga-solus> a bit crude but :/
<pedronis> mvo: did you see my question about default tests for the configure-snapd code?
<mvo> pedronis: yes thank you! I started to write one and then $stuff happend :/ (the mount profile chnage bug that zyga-ubuntu found/fixed and an nvidia error)
<pedronis> it's ok, just wondered because there was no answer in the PR
<pedronis> mvo: on my side a 2nd review of #4106 would be appreciated,  and thansk for reviewing the snap  info/list change
<mup> PR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<mvo> pedronis: ok, I do that next (probably after lunch though)
<mborzecki> zyga-solus: got it, by the looks of it, it's a bit outdated and the build process is so-so (CGO_*FLAGS are not set properly)
<zyga-solus> mborzecki: that's the most recent we have, we didn't do arch releases since
<mborzecki> what's the plan then? so far there's an outdated version in snapd tree, another one on gh release page (outdated as well) and one in community repo (more outdated than both previous)
<zyga-solus> mborzecki: if you merge it with your improvements and merge back to master it should be fairly ok
<zyga-solus> ideally, update the community repo but ENOLUCK
<zyga-solus> mborzecki: we can update the packaging in master for reference
<zyga-solus> mborzecki: but we still don't have arch tests that run on PRs so it's likely to go out of date eventually
<zyga-solus> mborzecki: little by little, since you run arch daily it will help a lot in making the package healthy
<mborzecki> ok, hmm let's do this, first merge and update all pkgbuilds into master tree, make it a -git package (this should make it easy to test it directly from git)
<zyga-solus> +1
<mborzecki> then maybe add snapd-git to aur, so that the users are not blocked and  update archwiki page (if there's one)
<mborzecki> guess the last step would be getting an image for spread and adding arch to the test suite
<oSoMoN> mvo, it might be https://cs.chromium.org/chromium/src/content/gpu/gpu_sandbox_hook_linux.cc?type=cs&sq=package:chromium&l=223 , but I'm still trying to figure out where that call to mknod is issued
<mborzecki> zyga-solus: first 2 i can take care of, will need help with the last one :), how does that sound?
<zyga-solus> mborzecki: arch is supported on linode already
<zyga-solus> mborzecki: but it all sounds like a good plan
 * kalikiana coffee vreak
<mup> PR snapcraft#1655 opened: lxd: distinguish argless clean from clean -s pull <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1655>
<zyga-solus> mvo: can you do a 2nd review of 4136
<zyga-solus> this will let us merge 4141 next
<mup> PR snapd#4119 closed: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4119>
<mup> PR snapcraft#1646 closed: sources: enforce default language in subversion info <Created by clobrano> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1646>
<pedronis> seen this:  + tar czf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz /var/lib/snapd /snap /etc/systemd/system/snap-core-3386.mount /etc/environment /etc/systemd/system/snapd.service.d /etc/systemd/system/snapd.socket.d
<pedronis> tar: Removing leading `/' from member names
<pedronis> tar: /var/lib/snapd: file changed as we read it
<pedronis> are we not stopping enough stuff?
<pedronis> was on 14.04
<zyga-solus> maybe refresh timer (unlikely but maybe?)
<zyga-solus> the udev tagging situation is more complex than other backends but I think I have something that will allow us to fix it in a generic way
<zyga-solus> hey cachio, how are you feeling?
<cachio> zyga-solus, I am in a 35%
<zyga-solus> cachio: go away and recharge then
<zyga-solus> cachio: take a break, rest, it's friday
<cachio> zyga-solus, it is ok, if I feel bad I'll go to bed
<cachio> zyga-solus, mvo, the #3378 is the one to validate?
<mup> PR #3378: tests: fixes for executions using the staging store <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3378>
<cachio> core snap rev 3378
 * Chipaca looks at cachio 
<Chipaca> cachio: this is not how you get better
<Chipaca> mvo: i need to go to the school it seems; i'll be missing the standup
<Chipaca> mvo: report from me would be: still hating aliases (but still hopeful to finish before eow), and, need to look at how to handle refresh of private (and bought) snaps next week with niemeyer
<Chipaca> (via people having trouble with this in the forum)
<mvo> Chipaca: thank you
<mvo> oSoMoN: indeed, this looks like the right track
<mvo> zyga-solus: looking at 4136 in a wee bit, last I looked tests were still running but looks like that is finished now
<zyga-solus> thank you
 * sergiusens starts making his way to the bank
<sergiusens> bbiab
<zyga-solus> mvo: I'll push my PR in a moment
<mvo> zyga-solus: ta
<mup> PR snapd#4136 closed: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4136>
<pedronis> pstolowski: for the 2nd part of the issue, I think will need something like   Change.LaneTasks(lanes []int) []*Tasks that gives all the tasks in the change in the given lanes, or all of the them if one of the lanes is 0 (the default lane)
<pedronis> heh, sorry, the last bit is wrong
<pedronis> about 0
<pstolowski> pedronis, will look at snapctl issue next. thanks
<pedronis> pstolowski: np
<pstolowski> what's the quickest/recommended way of disabling a spread test entirely?
<pstolowski> via systems: ?
<mvo> pstolowski: manual: true is one way and a comment
<pstolowski> mvo, great, thanks
<mvo> pstolowski: or exit 0 in execute with an echo with the details why its disabled
<pstolowski> mvo, i'm going to propose this only against 2.29, since MR will receive a fix in next few days; makes sense?
<pstolowski> s/MR/master/
<mvo> pstolowski: yes
<mvo> pstolowski: we will still pull it into master to minimize the delta but if you target 2.29 thats great that means we can move faster
<mup> PR snapcraft#1412 opened: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<zyga-solus> offtopic, HasLen checker is particularly unhelpful about saying what the real length was
<mup> PR snapd#4106 closed: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4106>
<mup> PR snapd#4110 closed: many:  have a timestamp on store assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4110>
<mup> PR snapd#4139 closed: cmd/snap-update-ns: fix collection of changes made <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4139>
<mup> PR snapd#4143 opened: snapctl: Disable stop/start/restart (2.29) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4143>
<pstolowski> mvo, ^ this should do it
<pstolowski> kyrofa, ^ bad news :(
<zyga-solus> mvo: now doing common
<zyga-solus> mvo: behind one innocent line in common.go there are lots of interfaces that need small tweaks to consts
<mborzecki> zyga-solus: there was a template based refactoring tool for go
<zyga-ubuntu> mborzecki: uh, not worth it in this case
<mborzecki> eg?
<zyga-ubuntu> I need to tweak a few constants
<zyga-ubuntu> and change type
<mborzecki> hm change type can be done with gorename
<mborzecki> it'll update all packages that use that type
<zyga-ubuntu> mborzecki: I need to do that to about a dozen variables spread around dozen files
<zyga-ubuntu> mborzecki: I'll show you the patch and I can learn abou the tool when you see it
<mvo> pstolowski: thank you
<mvo> mborzecki: anything that needs to go to 2.29?
<mborzecki> mvo: don't think that arch fixes are a priority, so nothing from my side
<mvo> mborzecki: ta
<mvo> zyga-ubuntu: your renames are master, right? or also 2.29?
<zyga-solus> mvo: master unless you think it's 2.29 material
<zyga-solus> mvo: "renames" are not real renames, just a mental shortcut
<mvo> zyga-solus: I will wait for the PR but probably not 2.29 then
<mvo> zyga-solus: just trying to avoid a .3 by gathering all potential further changes
<zyga-solus> k
<zyga-solus> mvo: ok ready
<zyga-solus> pushing
<zyga-solus> mvo: 4144
<zyga-solus> I'll self-review for typos now
<mup> PR snapd#4144 opened: interfaces: fix udev tagging for hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/4144>
<roadmr> jdstrand: hi! hey question. You approved classic confinement for goby yesterday. Did you by chance also trigger an automated review after doing that?
<zyga-solus> mvo: read it, pushed and squashed one trivial unused variable removal
<zyga-solus> mvo: I'll check if this applies to 2.29
<zyga-solus> mvo: yep, I can propose a 2.29 variant too
<zyga-solus> close it if you don't want to take that risk
<mvo> zyga-solus: I ponder over it
<mvo> roadmr: jdstrand is not around today
<mup> PR snapd#4145 opened: Backport/udev hooks 2.29 <Created by zyga> <https://github.com/snapcore/snapd/pull/4145>
<roadmr> mvo: darn! mystery will need to wait to be solved :)
<zyga-solus> pedronis: can you have a look at 4144
<zyga-solus> pedronis: that should fix the issue you found today
<mvo> roadmr: yeah :)
<roadmr> thanks though mvo
<mup> PR snapd#4145 closed:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4145>
<mup> PR snapd#4146 opened:  interfaces: fix udev tagging for hooks (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4146>
<mborzecki> zyga-solus: you're right, does not look like this could be done with go's refactoring tools
<zyga-solus> mvo: I'll make some tea, let me know if I can help you somehow
 * sergiusens is back
<sergiusens> kyrofa might want to start looking into this https://pastebin.ubuntu.com/25880037/
<sergiusens> that is all I have from the error as the log has not been generated/exposed yet
<sergiusens> that extract is from running on bionic, which I thought would be a skip for these
<mvo> zyga-solus: quick brainstorm, can you check https://github.com/snapcore/snapd/compare/master...mvo5:refactor-ifstate?expand=1 and tell me what names you prefer? do you think overlord/ifacestate/repo is a good name for the package?
<mvo> zyga-solus: fwiw, tests for 4143 have not started yet :( so no 2.29.2 until those have run
<mborzecki> i'm done for today, gotta go pick up my kids, have a nice weekend guys
<elopio> Good morning!
<kalikiana> sergiusens: You might like to have a look at snapcraft#1655 this is to avoid `snapcraft -s pull` killing your container
<mup> PR snapcraft#1655: lxd: distinguish argless clean from clean -s pull <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1655>
<diddledan> build.snapcraft.io isn't letting me sign-into launchpad oauth: Invalid association handle
 * kalikiana waves at elopio 
<diddledan> or rather it redirects back to build.snapcraft.io but reports error
<kyrofa> pstolowski, uh oh
<kyrofa> pstolowski, what's the background there?
<pstolowski> kyrofa, it breaks with an error if run from configure hook as part of snap install/refresh. will also error out in install/refresh hooks.
<pstolowski> kyrofa, my spread test was only testing one case
<kyrofa> pstolowski, is this a case of the fix being known, just more work than can be done right before a release
<kyrofa> ?
<pstolowski> kyrofa, more work, but not on time for this .point release
<zyga-solus> re
<kyrofa> pstolowski, that's fair, I appreciate the heads up. Something you anticipate happening soon, though?
<zyga-solus> mvo: sorry, had IRL interrupt
<zyga-solus> mvo: checking your branch
<pstolowski> kyrofa, yeah, should be fixed soon and in the 2.30 release
<kyrofa> pstolowski, alright, thank you :)
<om26er> Who is responsible for transfer of snap ownership ?
<zyga-solus> mvo: hmm
<zyga-solus> mvo: please add repo.go :)
<zyga-solus> mvo: and push :)
<zyga-solus> mvo: I'll check after I really make that tea
<noise][> om26er: there are a few of us here that can do it
<kyrofa> sergiusens, huh, that one's not skipped. Maybe it's something we lost as part of the migration into snapd tests, or maybe it's something that used to work, but I'm adding a skip now
<noise][> and i'm aware we are a bit behind on the forum requests this week
<om26er> noise][: kindly transfer android-studio and sublime-text-3 from my name(om26er) to snapcrafters
<kyrofa> Oh, that's not part of the snapd suite, haha
 * zyga-solus cannot wait to snap install sublime-text-3
<om26er> The packaging was already moved under snapcrafters but the ownership didn't.
<ogra_> pfft ... vim rules ...
<zyga-solus> ogra_: yeah, but fira code font is amazing
<zyga-solus> ogra_: do you know that font?
<noise][> om26er: ok, we can get to those today, sorry for the delay
<zyga-solus> mvo: travis is starving us so badly I wonder why this is so
<mvo> zyga-solus: autsch, sorry, added repo.go now
<kyrofa> It must have passed at some point, that test has been there for a while
<ogra_> zyga-solus, is that the one with weird arrows and such ?
<zyga-solus> ogra_: yes
<zyga-solus> well, "weird"
<zyga-solus> normal actually
<om26er> noise][: thanks :)
<zyga-solus> mvo: so, first of repo is not a great name since it clashes with interfaces/repo.go and that Repository, something non-clashing would be better
<zyga-solus> mvo: what is the cycle this breaks?
<zyga-solus> mvo: I expected that we'd have something outside of ifacestate, not a nested package actually
<mvo> zyga-solus: see explaination in the preview, it allows creating a "interfaces.Repository" based on the current state from snapstate
<mvo> zyga-solus: which allows to e.g. answer the question if a content interface is already connected
<mvo> zyga-solus: that is important to know if the default-provider needs to be downloaded or not
<zyga-solus> right
<zyga-solus> hmm
<kyrofa> sergiusens, wait... that's a duplicate test!
<mup> PR snapcraft#1656 opened: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1656>
<zyga-solus> I'm a little lsot about how this makes it work (I totally believe it does, just not grok it yet)
<kyrofa> Ignore that PR for a sec, it looks like that test became a snapd test, but then was never removed
<mvo> zyga-solus: I'm open for other ideas, I'm not super happy about "repo"
<zyga-solus> snapstate->ifacestate->snapstate is the cycle that we are breaking?
<kyrofa> Man, that's gonna speed travis up so much
<zyga-solus> mvo: let me branch and see
<zyga-solus> mvo: +1 on the idea, this is just nitpick territory now
<mvo> zyga-solus: yes, snapstate imports ifacestate/repo and ifacestate imports ifacestate/repo too
<mvo> zyga-solus: we do something similar in configstate/config
<kyrofa> sergiusens, wait I lied. It's not, it's closely related
<mvo> zyga-solus: yeah, no worries, happy to bikesheed about the name, naming is hard
<mvo> zyga-solus: the three most difficult problems in cs:  naming and off-by-one errors
<kyrofa> And it's a faster one anyway
<zyga-solus> mvo: iterating
<kyrofa> mvo, very clever :P
<zyga-solus> mvo: and indentation
<mvo> zyga-solus: so once we have a name i can add some tests and cleanup around this and then use it in the default provider PR
<zyga-solus> I'm tweaking locally, one more moment please
<mvo> sure
<pedronis> my internet connection is flaky
<zyga-solus> ok
<kyrofa> sergiusens, shall I queue up a non-xenial run on snapcraft#1656 ? Perhaps not bionic though as it seems the biggest queue
<mup> PR snapcraft#1656: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1656>
<zyga-solus> mvo: pushed to my branch of the same name
<kyrofa> Oh bionic is looking pretty decent for upstream actually
<zyga-solus> kyrofa: forever people googling for "bionic libc ..." will curse ubuntu
<kyrofa> zyga-solus, I've never once googled "xenial libc" :P
<zyga-solus> kyrofa: bionic as the android libc
<kyrofa> Oh, the other way around-- I thought you meant they would find android results when they were looking for ubuntu. Gotcha
<kyrofa> Yeah they probably will!
<zyga-solus> yeah, I think >> android than ubuntu
<mvo> zyga-solus: thank you! Not sure I like "Restore", maybe "Load"?
<zyga-solus> mvo: sure
<zyga-solus> mvo: I was thinking that it should live in overlord
<zyga-solus> but that is somewhat black-hole logic
<zyga-solus> eventually everything will be in overlord
<zyga-solus> so instead I think it makes sense to speak of interfaces and state as interfaces/ifstate
<sergiusens> kyrofa just do zesty; bionic and artful will fail adt anyways
<mvo> zyga-solus: re overlord> I kept it there mostly because we have all state related things there. beside daemon/ itself all the things that are importing/manipulating state are under overlord afaict
<sergiusens> elopio kyrofa can we do that meeting one hour later? This is the time I try to avoid meetings
<mvo> zyga-solus: maybe it is one of those - we need gustavo PRs :) - but happy to use your PR as the starting point (except for "Restore" which feels a bit off to me)
<kyrofa> sergiusens, yep
<zyga-solus> mvo: sure
<elopio> sergiusens: no problem.
<zyga-solus> mvo: Load is fine, please use that
<mvo> zyga-solus: thanks
<zyga-solus> mvo: look at the package imports in ifstate.go, we can . import interfaces to almost unify this with the rest of the cod there
<kyrofa> snappy-m-o, autopkgtest 1656 zesty:i386
<snappy-m-o> kyrofa: I've just triggered your test.
<kyrofa> That queue is non-existent
<zyga-solus> mvo: some things could move sideways to utils.go (AddImplicitSlot, etc)
<zyga-solus> mvo: or elsewhere, as appropriate
<zyga-solus> mvo: it would also help to, at least in my eyes, to connect the interfaces.Repository to state handling, at least it would be "close"
<mvo> zyga-solus: not sure I understand what you have in mind. " . import interfaces" - what does ". import" mean?
<zyga-solus> import ( . "github.com/snapcore/snapd/interfaces" )
<zyga-solus> then you can say Load(...) (*Repository, error)
<zyga-solus> without having to preprend "interfaces." to most types
<mvo> hm, not sure I like that, maybe just because its unfamiliar (and its friday :)
<zyga-solus> mvo: we use it to import check.v1 (almost) everywhere
<zyga-solus> mvo: anyway, just an idea, since this code mostly deals with interface types
<zyga-solus> mvo: what do you think about 4144
<mup> PR snapd#4147 opened: ifacestate: refactor and extract ifacestate/repo <Created by mvo5> <https://github.com/snapcore/snapd/pull/4147>
<mvo> zyga-solus: ups, sorry, reading now
<roadmr> diddledan: hey you requested a bunch of snap transfers from you to snapcrafters. Did snapcrafters agree to this? :)
<pedronis> mvo: why is New  is in that package,  btw having a New for a type not defined there is strange
<kalikiana> brb
<zyga-solus> pedronis: look at my proposal in the same branch under my account
<mvo> pedronis: yeah, zyga-solus was suggesting "Restore" we also discussed "Load"
<zyga-solus> pedronis: I also moved it to interfaces/ifstate since it's closely coupled to types there
<zyga-solus> pedronis: but just more ideas
<pedronis> ifstate is a weird name
<roadmr> diddledan: also - is build.snapcraft.io still misbehaving? I just registered and built a snap without any issues
<zyga-solus> pedronis: I also tried interface/state but then I imported it as ifstate in overlord
<pedronis> it's doing very different things
<pedronis> I fear we need to think a bit more
<pedronis> there's not a stronge relation between repo stuff and conns stuff for example
<mup> PR snapd#4143 closed: snapctl: disable stop/start/restart (2.29) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4143>
<zyga-solus> no? I think repo is mostly about storing what is connected
<mvo> pedronis: yeah, it seems a bit loose right now, the PR is the first discussion point (the most minimal thing I could do to de-couple it)
<pedronis> mvo: I really need to understand what you need, because the decoupling as such doesn't make sense to me
<pedronis> it feels very arbitrary
<mvo> pedronis: my use case is that I want to answer the question "is this content interface connected" in snapstate when I decide if I need to download the default-provider
<mvo> pedronis: there is another use case in another branch but that is for later (but also 2.30)
<pedronis> IÂ don't see how moving ReloadConnections relates to that
<zyga-solus> pedronis: ReloadConnections is really Repository.Import(state)
<pedronis> sorry, IÂ don't understand
<pedronis> how do you get to repo?
<pedronis> do you build a different one in snapstate?
<pedronis> I'm probably super confused
<zyga-solus> no, sorry
<zyga-solus> overlord keeps one repository instance around
<pedronis> ?
<pedronis> and passes it to snapstate?
<zyga-solus> exposes certain functionality, I didn't look exactly if that passes the whole repo or just one method from it
<zyga-solus> my desire to keep the ifstate module closer to interfaces/ was because it's really about how the interface repository is serialized
<zyga-solus> and "deserialized" from the state
<pedronis> this branch doesn't change overload or snapstate
<pedronis> afaict
<mvo> pedronis: the new code loads a repo from state
<pedronis> ?
<mvo> pedronis: so it gets a snapshot of the current connection from the state to answer this question (what is connected right now)
<zyga-solus> I mean there's nothing new in this, just a way to untangle some cyclic imports
<pedronis> mvo: we create repos on teh fly all the time?
<pedronis> where?
<pedronis> I know how repo is used
<pedronis> there was one repo
<pedronis> inside ifacemanager
<zyga-solus> pedronis: we don't create repos on the fly (fortunately!) :)
<mvo> pedronis: we don't do that, my idea was to have code in snapstate that creates a repo on the fly in the future. but happy about alternative ideas
<pedronis> mvo: what?
<pedronis> that's kind of expensive
<pedronis> also remember we are moving to have singletons for connections
<pedronis> that's pawel work
<pedronis> so that will not work
<mvo> pedronis: meh, I was not following that new work, which PR should I look at?
<pedronis> mvo:  is not done yet
<pedronis> mvo: anyway creating repos on the fly is a  bad idea
<zyga-solus> I agree with pedronis
<zyga-solus> I wasn't expecting on-the-fly repos
<mvo> pedronis: fair enough. what options do we have?
<pedronis> mvo: have you looked at how assertstate deals with the assertions db ?
<pedronis> we stick it in the cache
<pedronis> and then can accessors  that do  state -> cache -> db   ->  answer questions
<mup> PR snapd#4147 closed: ifacestate: refactor and extract ifacestate/repo <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4147>
<mvo> pedronis: ok, I check that out, this looks good
<mvo> pedronis: I close the PR and look at the alternative approach later (or Monday). thanks for your input!
<zyga-solus> I think it's a good idea
<pedronis> mvo: sorry if I was bit harsh,  but refactoring without intended uses  are hard to parse
<pedronis> it's not about the code as such, it's more how it's going to be used
<mvo> pedronis: no worries, I got the input that I needed :) i.e. the important part to me is how snapstate can get data from the repo and I think you pointed to a good solution which is great
<pedronis> mvo: you'll probably  need anyway  a subpackage of ifacestate because of circularity but it can be focused on querying
<mvo> pedronis: yeah, I think so too
<pedronis> spread tests are very flaky again :/
<zyga-solus> what failed?
<pedronis> lots of different things
<pedronis> all a bit random
<zyga-solus> worst kind :/
 * kalikiana going to wrap up for the day
<mthaddon> hi folks, I've been able to install this (classic) snap locally. Any idea why the snapstore doesn't like it? https://pastebin.ubuntu.com/25880784/
<zyga-solus> mthaddon: no idea, how did you make it?
<roadmr> mthaddon: can you put that somewhere I can get to it? I'll run the review tools on it and see what the boggle is
<mthaddon> zyga-solus: I'm not quite sure how to answer that question. Do you want to see the snapcraft.yaml file?
<mthaddon> roadmr: will do
<roadmr> mthaddon: that message can appear if you try to upload a random file, which does not appear to be your case
<zyga-solus> mthaddon: no, just curious if it is hand made
<mthaddon> I just ran "snapcraft" in a directory containing lp:codetree, fwiw
<ogra_> mthaddon, file codetree_0.1.6_amd64.snap
<ogra_> does it talk about being a squashfs file ?
<mthaddon> yep, there now (retried at roadmr's request)
<cachio> zyga-solus, I am getting this error: cannot snap-exec: cannot read info for "test-snapd-check-fs-access": stat /var/lib/snapd/snaps/test-snapd-check-fs-access_x2.snap: no such file or directory
<cachio> zyga-solus, the file snap exists
<cachio> any idea why it could happening?
<zyga-solus> cachio: hmmm
<zyga-solus> cachio: is the snap file mounted?
<zyga-solus> any denials
<zyga-solus> how did you experience this?
<cachio> no denials
<cachio> I am testing a new test
<cachio> inlinode
<cachio> do you want access?
<zyga-solus> no, too tired today
<zyga-solus> I can look on monday
<cachio> zyga-solus, sure
<cachio> zyga-solus, enjoy your weekend
<zyga-solus> thank you, likewise
<kyrofa> snappy-m-o, github subscribe 1656
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1656 (integration tests: skip shared ROS test on non-xenial).
<mup> PR #1656: snap: do not sort the result of `snap find` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1656>
<kyrofa> snappy-m-o, github subscribe 165
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #165 (Enabling testing with new cli).
<mup> PR #165: forgot to git add the tests <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/165>
<kyrofa> snappy-m-o, github subscribe 1650
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1650 (Release changelog for 2.35).
<mup> PR #1650: Merge master onto #1623 to check tests <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1650>
<kyrofa> That's gonna get old
<elopio> sergiusens: kyrofa the other error on zesty was the git snap taking too long.
<diddledan> roadmr: does this not count? https://github.com/orgs/snapcrafters/teams/snapcrafters/members
<elopio> that's another one to simplify and demote to integration suite.
<sergiusens> elopio we could probably just remove that test, does it give us anything? Mind double checking?
<kyrofa> elopio, how do timeouts work on the autopkgtests? Is it like Travis, where it watches stdout?
<sergiusens> If it is for classic, then I think we already have that in the integration suite
<roadmr> diddledan: I saw that... well if you as a member of snapcrafters tell me you're happy with it, then I'll go ahead with the transfers
<Chipaca> niemeyer: can we make mup ignore snappy-m-o?
<diddledan> I'll move the repos across, too
<roadmr> diddledan: I just didn't want to assume, you know what they say about that. As long as you're explicitly OK with it that's fine.
<diddledan> I just hadn't got that far :-)
<sergiusens> Chipaca or better yet, ignore random numbers like 1111
<sergiusens> or #1111
<mup> PR #1111: timeout,snap: add YAML unmarshal function for timeout.Timeout <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/1111>
<roadmr> diddledan: right, I do consider a repo under snapcrafters as explicit agrement :) which is why I transferred irccloud
<Chipaca> #1111 is not a random number though
<elopio> kyrofa: it depends. One part is a counter, from the start of the test. The other is what we added on pexpect, to fail earlier adjusting the expected timeout of a command ourselves
<kyrofa> elopio, ah ha. Did pexpect timeout, then?
<sergiusens> Chipaca no I thought about it twice in a row :-)
<sergiusens> is #1234 random?
<mup> PR #1234: debian: make snapd get its environ from /etc/environment <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1234>
<diddledan> roadmr: thanks for the prudence :-)
<diddledan> roadmr: inadyn now in snapcrafters: https://github.com/snapcrafters/inadyn
<elopio> sergiusens: that's the one that tests classic confinement. We can replace it with a more simple one that reads /tmp, or something.
<elopio> kyrofa: yes: Expected output 'Snapped .*\\.snap' not found.
<roadmr> diddledan: thanks! let me wrap up a call and I'll get on the transfers. Will be done today (EDT) for sure
<diddledan> I'll note on each topic the new repo location
<roadmr> diddledan: much appreciated, that'll help with the bureaucratic side of things.
<mvo> cachio: 2.29.2 is available in beta for everything except amd64, that got corrupted and I'm rebuilding it
 * Chipaca vanishes into the night
<zyga-solus> mvo: corrupted?
<mup> PR snapd#4148 opened: Release 2.29.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4148>
<cachio> mvo, great
<cachio> mvo, starting ...
<mvo> cachio: \o/
<kyrofa> sergiusens, the deprecation notice for `snapcraft pack` is not in place, FYI
<sergiusens> kyrofa would be good to get one I'd say.
 * sergiusens crafts one up
<sergiusens> which other one is missing?
<kyrofa> sergiusens, that's it
<kyrofa> (just dn6)
<sergiusens> kyrofa oh, so the others just didn't make it to the website
<kyrofa> sergiusens, yeah deployment is a different issue
<sergiusens> kyrofa and I seem to know what it is ;-)
<kyrofa> Hmm. noise][ nessita the store is rejecting all my daily uploads with "__all__: The upload does not appear to be a valid package."
<zyga-solus> kyrofa: upload valid packages then
<zyga-solus> what is this >> thing you are uploading
<kyrofa> zyga-solus, yeah either the store is borked or LP is messing up every single build :P
<zyga-solus> kyrofa: __all__ your base are belong to us
<noise][> kyrofa: weird, can you grab the snap and try to install it locally?
<zyga-solus> kyrofa: but one thing is good
<zyga-solus> kyrofa: at least the store is not implemented in perl
<kyrofa> noise][, yeah, works fine. https://launchpad.net/~nextcloud-snappy-dev/+snap/nextcloud-daily-master/+build/101331
<noise][> weird
<noise][> can you file a bug and we can get someone to take a look on monday?
<sergiusens> kyrofa read this one please https://github.com/canonical-docs/snappy-docs/pull/145
<mup> PR canonical-docs/snappy-docs#145: deprecation notice number 6 <Created by sergiusens> <https://github.com/canonical-docs/snappy-docs/pull/145>
<sergiusens> kyrofa refresh if you've opened it, I forgot to `git add` my mods to `index.md`
<kyrofa> sergiusens, oh good catch on the index
<sergiusens> kyrofa ok, I have satisfied your demands!
<sergiusens> if you +1 I'll merge
<sergiusens> kyrofa oh, my write access has been revoked
<kyrofa> Haha, bam!
<sergiusens> davidcalle ^
<davidcalle> kyrofa: did it? I'm reading the PR
<davidcalle> kyrofa: sergiusens: has it been revoked for both of you?
<kyrofa> davidcalle, I was never cool enough to have it in the first place
<davidcalle> kyrofa: let's fix this
<kyrofa> davidcalle, well hey! Thanks!
<davidcalle> kyrofa: speaking of PR, how do you feel about these link changes: https://github.com/canonical-docs/snappy-docs/pull/136/files (in language guides: "https://forum.snapcraft.io" -> "https://forum.snapcraft.io/t/process-for-reviewing-aliases-auto-connections-and-track-requests/455 "
<mup> PR canonical-docs/snappy-docs#136: Point forum links in guides at requests guidelines topic <Created by caldav> <https://github.com/canonical-docs/snappy-docs/pull/136>
<kyrofa> davidcalle, yeah, +1 from me
<davidcalle> ty
<kyrofa> Oh my gosh the store is so slow today... I'm getting 80k
<noise][> kyrofa - API, download from CDN, ??
<noise][> "store" is a pretty broad term
<kyrofa> noise][, `snap download` whatever that is
<noise][> kyrofa: host 068ed04f23.site.internapcdn.net, and then check traceroutes to the IPs
<mup> PR snapd#4104 closed: cmd/snap-update-ns: add logging to snap-update-ns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4104>
<mup> PR snapcraft#1656 closed: integration tests: skip shared ROS test on non-xenial <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1656>
<sergiusens> snappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm64 bionic:amd64 bionic:armhf bionic:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
<mup> PR snapd#4149 opened: tests: new tests for network setup control and observe interfaces <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4149>
<kyrofa> Huh, the bot didn't tell me that the test failed
<kyrofa> snappy-m-o, github subscribe 1650
<snappy-m-o> kyrofa: I'll send you a message if a test fails in the pull request #1650 (Release changelog for 2.35).
<mup> PR #1650: Merge master onto #1623 to check tests <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1650>
<kyrofa> Oh man, totally missed that circle CI can do periodic jobs, now!
<kyrofa> elopio, FYI ^^
<kyrofa> elopio, did you also know you could run a job with SSH enabled for debugging?
<elopio> I didn't know.
#snappy 2017-11-04
<mup> PR snapd#4148 closed: Release 2.29.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4148>
<itsfemme[m]> Is it possible to proxy the network connections of a snap package for example through a vpn or tor
<itsfemme[m]> if theres proper tor integration then even hidden services can be used
<mup> PR snapd#4142 closed: cmd/snapd,client,daemon: display ignore-validation flag through the notes mechanism <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4142>
<mup> PR snapcraft#1657 opened: tests: in autopkgtests, use a tempdir in home, not in the tmpfs <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1657>
<elopio> snappy-m-o autopkgtest 1657 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
#snappy 2017-11-05
<mup> PR snapd#4118 closed: overlord/snapstate: cleanups around switch-snap* <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4118>
<Abbot> Hello, built and deployed a snap (it work deploys!), but having hopefully a minor issue with "stage-packages"
<Abbot> I am trying to include a static lib for an armhf but snap packages up the amd64 lib
<Abbot> how do you tell snapcraft to use armhf in the package?   I am building with --target-arch=armhf
<Abbot> Or, is it possible to specify a search path with the snap to use the lib that is already on the machine?  Since I already installed the needed lib to the host machine
<Abbot> if i run the app from a command line it works... if i use --shell and try to run it.. it can't find the lib.... so i am very close to getting it to work
#snappy 2018-10-29
<mup> PR snapcraft#2381 closed: tools: copy in spread-shellcheck from snapd <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2381>
<AuroraAvenue> seems to a docker issue.
<AuroraAvenue> https://askubuntu.com/questions/1088170/docker-volume-error-over-snaps
<mborzecki> morning
<zyga> Hello
<mborzecki> zyga: hey
<mborzecki> zyga: seen the news/
<zyga> Yes, interesting times
<zyga> Some small errands in the morning
<zyga> But I will be around shortly
<mvo> hey zyga !
<mvo> zyga: good morning
<mvo> zyga: interessting times indeed
<zyga> Hey mvo
<zyga> How are you feeling?
<zyga> We have one page of reviews :-)
<mborzecki> mvo: hey, nice to have you back :)
<sil2100> mvo: welcome back! ;)
<mvo> mborzecki, sil2100 thank you!
<mvo> zyga: \o/ one page of reviews - awesome
<mvo> zyga: I feel very tired :)
<mvo> but beside that very happy to be back and being able to code again
<mborzecki> mvo: i've took the liberty and pushed some changes to #6039, hope you don't mind
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<mvo> mborzecki: thank you!
<mvo> mborzecki: I have a look
<zyga> I tried to as well but I could not make it pass so I aborted
<mvo> mborzecki, zyga thank you guys! sorry that the tests were in a bad state, it was just hard to focus during the sprint but I get back to it today :)
<mvo> I hope you had a good time?
<mvo> anything I should know and missed?
<mvo> sil2100: how are the stable images looking? I just promoted snapd 2.36 to stable (after a quick smoke test)
<zyga> re
<zyga> mvo: no worries man, you did great
<zyga> mvo: I meant that I failed to make it better
<zyga> it was late that night
<zyga> mvo: we need to cherry pick one patch into stable
<zyga> mvo: please ensure this is in the next release https://github.com/snapcore/snapd/pull/6044
<mup> PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6044>
<zyga> (of any kind)
<pstolowski> morning guys, hey mvo, welcome back!
<zyga> hey pawel!
<zyga> pstolowski: did you read the news?
<zyga> today is going to be interesting
<zyga> and hey,
<zyga> fedora 29 ships tomorrow
<zyga> I wonder if people will notice that :)
<zyga> (timing is a bit unfortunate)
<zyga> mvo: not sure if good morning material
<zyga> https://github.com/snapcore/snapd/pull/5170
<zyga> this is ready and green
<zyga> and only missing an ack from gustavo
<mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<zyga> but it implements exactly what he asked for
<zyga> so maybe we can land it?
<mvo> hey pstolowski !
<mvo> zyga: nice, I have a look over the open PRs next
<zyga> woot, thank you :)
<zyga> I will work on user mounts, so many little things have landed already
<zyga> I need to run an errand around 11-13
<zyga> but otherwise I will be here
<mvo> zyga: anything else we need in 2.36?
<zyga> mvo: perhaps but not from me
<zyga> mvo: I think there are some things though
<zyga> but my mind is very rusty still
<zyga> we need to check the regression
<pstolowski> zyga: ibm&redhat, or something else?
<zyga> but I believe there was something else as well
<zyga> pstolowski: yep
<mvo> zyga: no worries, I will check if anything is marked
<zyga> pstolowski: anything from you for 2.36?
<pstolowski> right
<kjackal> https://github.com/kubeflow/kubeflow/issues/1854
<zyga> mvo: perhaps cherry pick https://github.com/snapcore/snapd/pull/5739 if feasible
<mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5739>
<pstolowski> zyga: nothing new from me for 2.36, the 2 criticals i had are there already
<zyga> pstolowski: great
<zyga> pstolowski: in 2.36 or in edge?
<zyga> (master)
<pstolowski> zyga: in release/2.36
<zyga> mborzecki: anything for 2.36 you want in badly?
<mborzecki> zyga: not really
<mborzecki> we're doing .1 already?
<mvo> mborzecki: yeah, I think we need a .1 anyway
<mvo> mborzecki: iirc zyga mentioned something critical, need to log at the branch to remember what it was exactly
<sil2100> mvo: thanks! So far so good, they're still in testing by the cert team, I'm waiting for the US to wake up to get more info
<sil2100> mvo: didn't see any news since Friday
<zyga> mvo: there's this as well: https://github.com/snapcore/snapd/pull/6026
<mup> PR #6026: cmd/snap: try not to panic on error from "snap try" <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
<mvo> sil2100: thank you
<mvo> sil2100: fwiw, the pi3 b+ works for me now with 4.15
<sil2100> mvo: should we re-spin for the new snapd? Is there anything critical in the 2.36 for core18 GA?
<zyga> and this but I presume this is in the release branch as well https://github.com/snapcore/snapd/pull/6027 (didn't check)
<sil2100> mvo: \o/ ;)
<mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
<mup> PR snapd#6053 closed: cmd/snap, daemon, strutil: use CommaSeparatedList to split a CSL <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6053>
<mborzecki> mvo: in that case https://github.com/snapcore/snapd/pull/6030 is a nice improvement and https://github.com/snapcore/snapd/pull/6049 may help resolve dbus issues we were seeing under spread
<mup> PR #6030: cmd/snap: tweak `snap services` output when there is no services <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6030>
<mup> PR #6049: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
<mup> PR snapd#6054 opened: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Created by mvo5> <https://github.com/snapcore/snapd/pull/6054>
<zyga> mvo: you can also perhaps consider https://github.com/snapcore/snapd/pull/6048 for 2.36 - it is a low risk bugfix
<mup> PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6048>
<mvo> zyga: thanks, I check that (and the ones from mborzecki) out now
<mup> PR snapd#6055 opened: tests/main: fixes for the new shellcheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/6055>
<zyga> Hey Chipaca
<Chipaca> zyga: oi music turtle
<zyga> Nice, each?
<zyga> Eh :-)
<Chipaca> yeah
<Chipaca> i think this just nerd-sniped my brother :-)
<zyga> Iâm waking up, slow day ahead
<zyga> I love things like that,
<zyga> Exactly the software that shapes imagination
<chesty> Hi, I was chatting to Chipaca earlier, he pin pointed the problem I'm having with an x2goclient snap I'm playing with. x2goclient is trying to open /var/lib/gdm3/.ssh/known_hosts when trying to open a connection (it uses libssh), my user isn't in /etc/passwd, it's on freeipa and the last entry in /etc/passwd is the gdm user with the home /var/lib/g
<chesty> dm3. So it appears libssh is trying to find my users home dir, it isn't found in /etc/passwd so it uses the home dir of the last entry in /etc/passwd.
<Chipaca> zyga: ^ is anything we're doing using the last entry in /etc/passwd when it doesn't find something?
<Chipaca> or is that libssh?
<zyga> Hmmmmm
<zyga> That would be weird, let me think and look
<Chipaca> chesty: did you add a line to /etc/passwd to check it was the last line and not some even weirder fluke?
<Chipaca> chesty: when we talked last we were talking about the qt libs, where did libssh enter? is libssh qt?  (i wouldn't think so)
<zyga> ^ smart idea!
<Chipaca> maybe it was there all the time and i missed it =)
<chesty> Chipaca, I'll do that now. btw before I was looking at x2goclients source code, it is using QDir::homePath, but I believe opening known_hosts would be done by libssh which x2goclient uses, it tunnels everything through ssh
<mvo> Chipaca: hey, good morning (have nothing for you, just want to friendly say hello :)
<Chipaca> mvo: hey! good morning =) aren't you going to take a day off or seven?
<mvo> Chipaca: yes! wed->fri I will be off
<mvo> Chipaca: but today and tomorrow I work or I will fall asleep the entire day, i.e. fighting jetlag this way :)
<mvo> Chipaca: and it works great so far (together with copious amounts of tea)
<Chipaca> chesty: https://git.libssh.org/projects/libssh.git/tree/src/misc.c#n223 says it should be falling back to HOME if getpwuid_r fails
<Chipaca> mvo: ok
<mvo> Chipaca: *but* please bear with me if I'm a bit slow today
<mvo> (mentally)
<Chipaca> mvo: we managed to get the PRs down to one page! despite my efforts
<mvo> Chipaca: I notied, I was super impressed. I think this means that gustavo/samuelle/mvo should be away more often ;)
<Chipaca> mvo: some of the ones not closed are waiting for your (plural) reviews
<mvo> Chipaca: ok - I have a look and see what I can do to fix that :)
<Chipaca> mvo: #6054 is gtg fwiw
<mup> PR #6054: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6054>
<chesty> I added a new user to /etc/passwd which is now the last entry and x2goclient/libssh now tries to open known_hosts in that users home dir
<mup> PR snapd#6054 closed: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6054>
<mvo> Chipaca: looks like it got merged already :)
<Chipaca> chesty: are you running this on amd64, and is the snap you're trying to use based on 'core'?
<chesty> yes and idk, it's ubuntu 18.04 using the 16.04 base for the snap built in a docker
<mup> PR snapd#6055 closed: tests/main: fixes for the new shellcheck <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6055>
<Chipaca> chesty: right
<Chipaca> so
<Chipaca> that ssh_get_user_home_dir is buggy
<chesty> and I believe this might  explain why things like spotify and skype snaps didn't work for me
<Chipaca> chesty: I did this: https://pastebin.ubuntu.com/p/nwTc45hDft/
<Chipaca> chesty: then I build and run it like this: gcc -Wall -o q q.c && sudo -u \#12345 ./q
<mup> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> <https://launchpad.net/bugs/12345>
<Chipaca> chesty: and that returns the last entry in /etc/passwd
<chesty> wow, you're a machine. I can't even open my editor that quick
<Chipaca> and indeed, the manpage for getpwuid_r says
<Chipaca> If no matching password record was found,  these  functions  return  0  and
<Chipaca>        store NULL in *result.  In case of error, an error number is returned, and NULL is st
<Chipaca> it's checking for error, but not for nothing-found
<chesty> sounds like you get to submit a pull request to libssh and earn another notch on your belt
<Chipaca> that check hsould be   if (rc != 0 || pwdbuf == NULL) {
<Chipaca> yeah, i'm on it
<Chipaca> I wonder if actual ssh has the same issue
<Chipaca> how do i send a pull request to libssh though
 * Chipaca looks
<mborzecki> Chipaca: hopefully not another cve for libssh :)
<mup> PR snapd#6056 opened:  cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6056>
<mborzecki> #6039 is green :)
<mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
<zyga> mborzecki: approve it :)
<mborzecki> zyga: heh pushed too many patches there
<zyga> indeed,
 * zyga did 2nd coffee
<zyga> today I feel so sleepy I can barely keep my eyes open
<zyga> what's wrong :/
<zyga> mvo: are there any agreements on 5845 (dot-files)
<mvo> zyga: unfortunately not, I will try to come up with a better name today
<mvo> zyga: and propose that and see what happens
<zyga> no worries, thank you for letting me know
<mvo> mborzecki: \o/ for 6039
<zyga> with 23 PRs left we can easily go after what's left :)
<mvo> zyga: yeah
<Chipaca> chesty: https://bugs.libssh.org/T118
<Chipaca> chesty: and if you want you can apply that patch locally to build your snap
<chesty> firstly, legen, wait for it,  dary.  Secondly, I might do that soon, I will need to learn how to build a package in a snap first.  In the meantime I'm going to work around it by modifying /etc/passwd. I still haven't got x2goclient to work, now it's complaining about a missing lib, /usr/lib/libXcomp.so.3, I added ilibxcomp3 to stage-packages but it
<chesty> 's still complaining about it missing, ldding it it looks like libpng12.so.0 is missing. I wonder if that's a package dependency bug
<mup> PR snapd#6057 opened: snap-exec: add comment about usage of ReadInfoExceptSize() <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6057>
<cjwatson> Chipaca: OpenSSH does not have the same problem, as far as I can see
<cjwatson> I don't think they have much if any code in common
<Chipaca> cjwatson: tks
<mup> PR snapd#6058 opened:  cmd/snap-exec: don't fail on some try mode snaps (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6058>
<mborzecki> hm postgresql* snap does not have ny services declared
<Chipaca> mborzecki: I think that's because they need to run as non-root
<mup> PR snapd#6056 closed:  cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6056>
<chesty> I don't understand what's going on, I added libpng12-0 to stage-packages but it's not finding its way into the snap.
<tomwardill> hi! pre-refresh hooks (again). I have a snap installed that does not have a pre-refresh hook. If i then install a new version that does, the hook does not run. It looks like the pre-refresh hook runs in the 'installed' context, not the 'to-be-installed' context. Anything I can do to fix that?
<Chipaca> tomwardill: that does not sound like something that needs fixing
<pstolowski> tomwardill: use post-refresh hook
<pstolowski> it runs in the new snap
<tomwardill> pstolowski: can a post-refresh hook reject the refresh?
<tomwardill> contextL I
<tomwardill> context: I'm trying to avoid upgrading to a version that requires database features that we don't have in the old version
<zyga> tomwardill: who ships the database4?
<zyga> tomwardill: perhaps epochs could be used to solve that?
<tomwardill> zyga: not us, we configure it, but using a connection that is provided by the machine admin
<pstolowski> tomwardill: yes it should, it's run as one of many tasks handling the transition to a new revision and if it fails, we undo everything and go back to the previous revisions
<tomwardill> yeah, it's starting to look like an epochs use case
<zyga> aha
<zyga> tomwardill: given what you said I don't think epochs can do that
<tomwardill> except we don't have superuser control, so there's not a lot we can do about it either way
<chesty> should libraries in usr/lib/x86_64-linux-gnu/ in the snap be found?
<tomwardill> zyga: ah, right.
<tomwardill> pstolowski: aha, I didn't realise post-refresh could do that, that sounds more like what I'm after then.
<zyga> chesty: if snapcraft arranges for it yes
<zyga> they are not added to LD_LIBRARY_PATH automatically
<chesty> oh, well there's my problem
<tomwardill> pstolowski, zyga: I'll give post-refresh a poke and see if that will do what I'm after. Thanks for the help :)
<pstolowski> tomwardill: sure, yw. simply make it exit with !=0 to make entire change fail
<Chipaca> chesty: that's usually done by a wrapper script
<Chipaca> tomwardill: pstolowski: zyga: note epochs aren't there yet
<chesty> Chipaca, will this work too? https://stackoverflow.com/questions/42991501/snapcraft-custom-ld-library-path
<tomwardill> ah yeah, that is also a problem for that approach :)
<Chipaca> chesty: given that that kyle is this kyrofa, i'd say it'll either work or you can harass him (you win either way!)
<Chipaca> chesty: although you two are mutually antipodean
<Chipaca> so good luck
<Chipaca> (well, not exactly, kyrofa might be -8 or something)
<pstolowski> cachio: hey!
<pstolowski> cachio: fyi, i've found the way for passing custom serial number to serial port adapters created with qemu
<mvo> has anyone seen:
<mvo> FAIL: <autogenerated>:1: ctxSuite.TestWriter
<mvo> context_test.go:50:
<mvo>     // but we copied things until the deadline hit
<mvo>     c.Check(n, check.Not(check.Equals), int64(0))
<mvo> ... obtained int64 = 0
<mvo> ... expected int64 = 0
<mvo> yet?
<zyga> waaaht?
<mvo> looks like a racy test, just happend in the snpad autobuild
<zyga> nope
<Chipaca> what's the what about?
<zyga> we could use the new int checker btw but that's unrelated
<Chipaca> that's Not() output
<Chipaca> it can be confusing
<Chipaca> it obtained int64(0), and it expected _not_ to obtain the "expected int64(0)"
<zyga> yeah, I read this now
<Chipaca> ah ok
<Chipaca> maybe we can patch Not to prepend NOT to the 'expected' line =)
<Chipaca> or append "... NOT!"
<cachio> pstolowski, nice
<cachio> do yo have an example?
<Chipaca> ... obtained int64 = 0
<Chipaca> ... expected int64 = 0 ... NOT!
<cachio> I was playing with confiugration failes
<zyga> Chipaca: that's a nice idea
<zyga> NOT :D
<zyga> (it's a nice idea)
<cachio> pstolowski, to configure any kind of device
<mvo> Chipaca, zyga btw, did we find out more about the kernel permission issue that cachio  found in 2.36 testing?
<zyga> no
<Chipaca> mvo: that's not on my radar at all
<pstolowski> https://www.irccloud.com/pastebin/fDLL0JuA/
<pstolowski> cachio: ^
<pstolowski> cachio: and it seems undocumented.. they depcreated -serial=... option but didn't document that new one
<mvo> Chipaca: ok, no worries, lets talk about it during the standup. I may have (sleepy) cycles for this :)
<mup> PR snapd#6058 closed:  cmd/snap-exec: don't fail on some try mode snaps (2.36) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6058>
<zyga> Chipaca: https://api.travis-ci.org/v3/job/447722772/log.txt
<zyga> https://www.irccloud.com/pastebin/PyCaVZMe/
<mvo> Chipaca: sorry for bothering you so much today, but have you seen http://paste.ubuntu.com/p/P2zHPvrFMJ/ before?
<zyga> I think the test should have failed when "snap save. .." failed
<zyga> missing error check?
<zyga> Chipaca: ^ FYI that's exactly the same problem :}
<mvo> heh
<Chipaca> mvo: no worries
<Chipaca> mvo: I have seen that error, but not in that test since I added the "run something from the snap" step
<Chipaca> mvo: zyga: I'll push a PR so we get more logs if it happens again
<mvo> Chipaca: ta
<cachio> pstolowski, nice
<cachio> pstolowski, is it iportant ofor you to have other information such as vendor?
<Chipaca> mvo: zyga: there was also one that happened sporadically on amazon linux,  where the uid was -2
<zyga> oh
<zyga> right
<zyga> last night
<pstolowski> cachio: only important factor is that vendor is present and constant (doesn't get random values like serial by default), which seems to be the case
<zyga> well, apart from the weekend that is
<Chipaca> mvo: zyga: I maintain what I said on Friday about that: it's my considered opinion, after much and careful thought, that i can't even.
<Chipaca> * not that much thought
<Chipaca> zyga: question: given that the size from ReadInfo wouldn't be useful for trys even if it weren't dangling, why not use an Lstat instead of a Stat?
<zyga> hmmm
<zyga> how would stat make it better?
<zyga> lstat that is you silly spellchecker
<Chipaca> zyga: the problem is that the symlink is dangling, right?
<zyga> you would stat the symbolic link itself, and?
<Chipaca> zyga: so it doesn't error out
<zyga> no, the problem is that symlink is controlled by the user
<zyga> and we are in a mount namespace
<zyga> so the user can point it a nearly arbitrary things
<zyga> we cannot traverse it, period
<Chipaca> zyga: how is the symlink controlled by the user?
<zyga> Chipaca: because whoever "snap try"ies controls it
<Chipaca> zyga: how?
<Chipaca> zyga: the symlink is created by snapd, not by the user
<zyga> the symlink is created by snapd to point to the directory picked by the user
<zyga> look at the test case in that branch
<Chipaca> ok, hold on
<Chipaca> before we go there
<cachio> pstolowski, ok
<cachio> vendor is fixed
<zyga> you can come up with creative use of "snap try /proc/..."
<Chipaca> zyga: the stat is done to get the size of the snap
<zyga> mhm
<cachio> pstolowski, so it should not be  a problem
<Chipaca> zyga: that won't work for trys
<zyga> but under the assumption that it points to a file
<zyga> which is not the case in try mode snaps
<Chipaca> zyga: hold on let me finish
<zyga> ok
<pstolowski> cachio: most likely not, i'll now for sure when i've the test passing
<Chipaca> zyga: if it's a symlink, we should not follow it for two reasons, it won't be what we need to get the size,  and the user  might have tricked snapd somehow
<zyga> aha, I see the reasoning now
<zyga> so just lstat all the time
<Chipaca> zyga: in both cases, using lstat fixes the issue
<zyga> and if it was a symlink, don't do more
<zyga> yep
<zyga> I agree
<Chipaca> zyga: the right thing would be to do lstat, check the filename,  and fill in size if it's a regular file
<Chipaca> keeps the api  simpler
<Chipaca> zyga: now, about the other thing, how would you trick snapd into pointing the symlink to something it shouldn't? via a race?
<Chipaca> hmmmm
<zyga> no
<zyga> not really
<Chipaca> well, snapd does a validation before enabling it
<zyga> what kind of validation?
<zyga> that it looks like a snap
<Chipaca> maybe it's a toctou
<Chipaca> yeh
<zyga> do we check that there are no symlinks along the way?
<zyga> do we check afterwards?
<zyga> can we then rm -rf /old/path
<Chipaca> what happens if we tell it to snap try a symlink? does it normalize?
<zyga> and then ln -s /proc/evil ?
<Chipaca> yeah
<zyga> yep
<Chipaca> lots of questions
<Chipaca> in any case the lstat is the right approach here i think
<Chipaca> but i'd like to know the answers to these other things as well =)
<Chipaca> zyga: should I push a pr?
<zyga> or I can if you want me to
<zyga> I feel sleepy and this is a good think to wake up with
<Chipaca> zyga: +1, i'm in snapshot-ate-my-brunch land
 * zyga hugs chipaca
<zyga> and takes a snapshot
<Chipaca> also need to get lunch going
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6059
<mup> PR #6059: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <https://github.com/snapcore/snapd/pull/6059>
<mup> PR snapd#6059 opened: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <https://github.com/snapcore/snapd/pull/6059>
<Chipaca> zyga: I had too much on my plate last week, but I _think_ pstolowski suggested lstat on the original pr
<zyga> perhaps but I didn't get the idea then
<Chipaca> i'm just now getting the bandwidth to think about it =)
<Chipaca> zyga: it was kyrofa !
<Chipaca> heh
<zyga> brb
<cachio> zyga, hey https://paste.ubuntu.com/p/9W39q9S2H4/
<cachio> I am getting that denial on the cifs test
<cachio> zyga, any idea if I should need to plug any other interface?
<diddledan> cachio: https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987
<mup> PR snapd#6057 closed: [RFC] snap-exec: add comment about usage of ReadInfoExceptSize() <Simple ð> <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6057>
<mborzecki> zyga: i'm runnig spread tests with centos branch rebased on current master and got a problem with parallel services, we do bind mounts from snap_foo to snap, seems like that whenerver the mount ns of a snap exists and we try to remove a location on the host that is bind mounted inside snap's ns we get device os resource busy
<mborzecki> zyga: snap-discard-ns makes the problem go away
<cachio> diddledan, nice, thanks
<zyga> mborzecki: this is a kernel bug
<zyga> It was fixed later
<zyga> I doubt we can work around it
<zyga> cachio: let me look
<zyga> Ah, I see
<zyga> cachio: let me know if we should do utab mount
<cachio> zyga, I just have pushed the changes for the test
<mborzecki> zyga: do you have a link to lp? something i could use to open a bug in rh bugzilla
<Chipaca> standup is in ten minutes?
<Chipaca> dang
<Chipaca> need to re-get-used to it
<mborzecki> w8, in 10 minutes now?
<mborzecki> hmm, dst change
<Dmitrii-Sh> mvo, Chipaca: tested on 2.36 https://bugs.launchpad.net/snapd/+bug/1791587/comments/7. Something is still wrong there
<mup> Bug #1791587: snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
<Chipaca> Dmitrii-Sh: did you (or somebody from your team) talk in SLC as we last discussed?
<Dmitrii-Sh> Chipaca: yes, I talked to mvo about this
<Dmitrii-Sh> he asked me to test on 2.36
<Dmitrii-Sh> just following up
<Chipaca> ah ok
<Dmitrii-Sh> what we agreed on is that /etc/environment should not be touched on classic systems (it isn't now by the looks of it)
<Dmitrii-Sh> and that this is a bug indeed \
<Dmitrii-Sh> just needed to test on the latest to make sure as there are release notes suggesting that it was fixed
<mvo> Dmitrii-Sh: thanks, I look into it then
<mvo> Chipaca: context> we have the in-config proxy config now, this should work so I need to figure out where the gap is
<Chipaca> mvo: AFAIK it fails when core isn't installed;  works ok after
<Dmitrii-Sh> mvo: there's a simple test: install a squid proxy on a host system, launch a container with snapd and squashfuse, remove the default gateway in that container
<Chipaca> mvo: at least that's what I got from Dmitrii-Sh week before last =)
<Dmitrii-Sh> the container will have a route only to the local subnet for communication with the host and will be able to use a proxy
<Dmitrii-Sh> Chipaca: I can try again
<mvo> Chipaca: yeeah, sounds reasonable, still puzzling that it does not work without core but something to figure out :)
<Chipaca> Dmitrii-Sh: when you built 2.36, how did you then run it?
<mborzecki> standup?
<Chipaca> omw
<mborzecki> zyga: ^^
<Chipaca> mvo: ^
<Chipaca> cachio: ^?
<mvo> Chipaca: need to restart pulseaduio first
<Dmitrii-Sh> Chipaca, mvo: yes, enabling default gateway, installing core, disabling gateway and trying to download other snaps works. I can also see that snapd connects to the proxy via strace
<mvo> JamieBennett: want to join the standup?
<zyga> what, already?
<zyga> sorry, joining
<Chipaca> mvo: i thought jamie was on holiday
<Chipaca> dunno about niemeyer
<Dmitrii-Sh> Chipaca: ran snapcraft cleanbuild, then I copied the resulting snap to the target system, unsquashfs-ed it and rsynced the /usr/lib/snapd/* and /usr/bin/snap* to relevant system dirs
<Dmitrii-Sh> Chipaca: snapcraft also builds a deb but it got deleted after cleanbuild
<Chipaca> Dmitrii-Sh: this was with no snaps installed?
<Dmitrii-Sh> Chipaca: yes, no snaps installed at first. Then I installed the core snap only and disabled the gateway
<Dmitrii-Sh> it then started to respect the proxy settings
<Chipaca> Dmitrii-Sh: the output of 'snap version' would be good, if you do over
<Dmitrii-Sh> snap --version
<Dmitrii-Sh> snap 2.36
<Dmitrii-Sh> snapd 2.36
<Dmitrii-Sh> series 16
<Dmitrii-Sh> ubuntu 18.04
<Dmitrii-Sh> kernel 4.15.0-34-generic
<Dmitrii-Sh> Chipaca: it's in the comment here https://bugs.launchpad.net/snapd/+bug/1791587
<mup> Bug #1791587: snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
<Dmitrii-Sh> btw, might be worthwhile to triage this bug for tracking
<mup> PR snapd#6060 opened: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
<mborzecki> off to pick up the kids
<zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/5170 as a satiny check before we merge it please
<mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<zyga> mvo: and if you consider it sane we could even add it to 2.36.1
<zyga> since it is a new feature
<niemeyer> Hey, I forgot to ask: how was the mic volume/quality?
<mvo> zyga: I have a look, for 2.36.1 we need to squash merge it
<zyga> that's ok
<mvo> niemeyer: quality was good afaict
<niemeyer> mvo: Thanks, it was an external USB mic, so wondering if it's good for htat kind of meeting too
 * pstolowski lunch
 * cachio lunch
 * zyga -> lunch
<mvo> zyga: 5170 looks fine, wonder if it makes sense to have a spread test that just double checks that the right files are created on connect etc?
<mborzecki> mvo: thanks for pushing that patch to 6039, i missed that comment from zyga
<mvo> mborzecki: my pleasure - thanks for all your help with this one, much more tricky than I anticipated
<Chipaca> pstolowski: when do you want to talk about that pr?
<zyga> mvo: I can look into that
<mvo> zyga: thanks! something simple if fine
<mvo> zyga: is fine
<pstolowski> Chipaca: in 30?
<zyga> re
<zyga> Chipaca, pstolowski: do you want me to participate as well?
<zyga> mvo: I wrote a test, if it passes I'll push it and merge when green
<Chipaca> pstolowski: zyga: fine by me
<zyga> just tell me when :)
<Chipaca> in 12 minutes would be ok. In 2 hours would be better =) but probably too late
 * zyga found a bug in snaps.sh make_snap
<zyga> 12 minutes would be ok but if you want we can also do tomorrow
<mvo> zyga: cool
<pstolowski> it can be tomorrow morning if you prefere that Chipaca, zyga
<Chipaca> pstolowski: zyga: tomorrow morning \o/
<zyga> yeah, I prefer to do reviews in the morning
<zyga> and coding in the evening
<Chipaca> ye
<pstolowski> sure
<zyga> Chipaca: remember the lstat thing?
<zyga> it regresses :D
<zyga> https://www.irccloud.com/pastebin/xJJ4C4SL/
<zyga> but I'd argue it doesn't regress because bind mounts are magic
<sil2100> uugh
<zyga> sil2100: ?
<Chipaca> zyga: what the wha?
<zyga> Chipaca: Lstat now shows a snap the _used_ to be broken as not broken
<zyga> but not really because it's not really broken
<zyga> because it works after the mv
<zyga> so ... :)
<Chipaca> heheh
<Chipaca> zyga: and does it _actually_ work?
<Chipaca> zyga: or is that snap now broken?
<zyga> I suspect so, it's the next thing in my pipe
<zyga> because the symlink is broke
<zyga> but the bind mount is not
<zyga> so why would it break?
<zyga> just found it funny :)
<mup> PR snapd#6061 opened: tests: fail if install_snap_local fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6061>
<zyga> Chipaca: one small for you https://github.com/snapcore/snapd/pull/6061 :)
<mup> PR #6061: tests: fail if install_snap_local fails <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6061>
 * Chipaca goes for a run
<zyga> cachio: hey
<zyga> cachio: the cifs test failed with
<zyga> https://www.irccloud.com/pastebin/I87puih6/
<zyga> Chipaca: it works,
<zyga> https://www.irccloud.com/pastebin/UR39vPVm/
<Chipaca> zyga: and with a non-trivial snap? =)
 * Chipaca is picky
<cachio> zyga, yes this is the error I mentioned before
<cachio> zyga, let me re-xecute it here
<cachio> zyga, I see this error
<cachio> [  607.220089] audit: type=1400 audit(1540832191.979:52): apparmor="DENIED" operation="open" profile="snap.test-snapd-cifs-mount.sh" name="/run/mount/utab" pid=23728 comm="mount" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0
<cachio> this denial appears with the error you displayed before
<mup> PR snapd#6062 opened: tests: add test to ensure proxy is used even without core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
<zyga> Chipaca: re
<zyga> I think it would work with any snap because:
<zyga> aww, I wanted to paste something but then spread session ended
<zyga> because the mount point shows what was there originally
<zyga> unless you start to rm file by file
<zyga> cachio: that's an attempt to modify utab
<zyga> cachio: we share utab with the host today so we should not modify it
<zyga> cachio: we should probably change the interface and debug this more
<cachio> zyga, you mean to allow access to this file as part of the interface?
<zyga> cachio: not really, we would have to make sure that file is not really there
<zyga> and allow the snap to read and write a fake copy
<mup> PR snapd#6061 closed: tests: fail if install_snap_local fails <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6061>
<cachio> zyga, ah, ok, I'll try that
<zyga> cachio: I think this needs some changes to the interface
<zyga> cachio: I can look at that tomorrow
<zyga> Chipaca: so to respond to your question:
<zyga> https://www.irccloud.com/pastebin/xgHWy2hn/
<zyga> cachio: I was trying to say that I think the test shows that some things are probably wrong and we need to revisit the interface
<zyga> Chipaca: as you can see the snap is not broken
<zyga> Chipaca: not sure if I should change the test to instead rm the snap.yaml file
<zyga> Chipaca: like this:
<zyga> https://www.irccloud.com/pastebin/9fhnCc46/
<zyga> we need a 2nd review on https://github.com/snapcore/snapd/pull/5982
<mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
 * zyga EODs
<zyga> ttyl!
<Chipaca> zyga: change the test, but RFC it so we talk about what is going on when this happens
<Chipaca> zyga: the question is: if this happens, and it happened by accident, what's the least surprising thing we can do so the user knows what's up
<Chipaca> zyga: and if it happens on purpose, double-check we're not opening the door for something dumb
<zyga> Chipaca: I pushed the change
<Chipaca> zyga: ack
 * Chipaca EODs, mostly
<cachio> pstolowski, I think I have a good solution to speedup nested vm executions
<cachio> pstolowski, I'll send you an email with the details after I can test the solution works properly
<zyga> https://www.irccloud.com/pastebin/4tieerHP/
<zyga> Chipaca: ^ is that the additional logs you were looking for?
<Chipaca> zyga: they'll be in the snapd log
<zyga> one sec
<zyga> hmm
<zyga> I cannot see that
<zyga> perhaps this is the partial log from before the feature landed?
<Chipaca> um
<Chipaca> zyga: the feature isn't landed
<Chipaca> it's got .99 of a review
<zyga> aaah
<zyga> right
<zyga> so that's all I know :)
<Chipaca> =)
<zyga> I'll re-trigger it
<Chipaca> yeah, need moar logs
<zyga> and we should both EOD
<Chipaca> yes
<Chipaca> i need to make dinner
<zyga> enjoy the evening :)
<Chipaca> or i'll be eaten alive by feral teenagers
<Chipaca> ttfn
<cachio> kyrofa, hey
<kyrofa> Hey cachio, what's up?
<cachio> kyrofa, tomorrow I'll update images and the nested vm will change the name
<cachio> on gce
<cachio> it already exists and it is called ubuntu-1604-64-virt-enabled
<cachio> and ubuntu-1804-64-virt-enabled
<cachio> it is part of a reorg I am doing
<cachio> both image names will be available the whole week
<cachio> the idea is that this week we chagne the image names
<cachio> does it work for you?
<kyrofa> cachio, no problem at all, I'll propose the change now
<mup> PR snapd#5170 closed: interfaces/builtin: add adb-support interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5170>
<kyrofa> Thanks for the heads up!
<mup> PR snapcraft#2387 opened: spread: change virt-enabled image name <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2387>
<kyrofa> cachio, that ^ look okay?
<cachio> kyrofa, the image is ready
<cachio> so if you want to test the xenial one
<cachio> you can so it, I'll create the bionic one now
<cachio> kyrofa, image for bionic is ready
<Chipaca> cachio: o/
<Chipaca> cachio: could you send me steps for creating the image so I can repro https://forum.snapcraft.io/t/8176 ?
<cachio> Chipaca, sure
<cachio> Chipaca, https://github.com/sergiocazzolato/snappy-qa-jobs
<cachio> git clone https://github.com/sergiocazzolato/validator.git
<cachio> cd validator
<cachio> sudo ./create.sh beta
<cachio> Chipaca, sudo ./create.sh beta pc-amd64
<cachio> that will create the image you need
<Chipaca> nice
<Chipaca> thanks
<cachio> amd64: sudo kvm -snapshot -smp 2 -m 1500 -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -nographic -serial mon:stdio <PATH_TO_VM_IMAGE>
<cachio> I use that command for the vm
<cachio> Chipaca, np
<Chipaca> cachio: this is uses ubuntu-image as in 16.04?
<cachio> yes
<cachio> it uses ubuntu image
<cachio> the .deb one
<Chipaca> cachio: how do i get the new kernel?
<cachio> Chipaca, ahh
<cachio> :)
<cachio> the problem is that I created my images with the old kernel on beta
<cachio> which was updated
<cachio> now you can't reproduce that
<Chipaca> cachio: well i can refresh to 18/stable or sth
<cachio> I can share my image with you perhaps
<cachio> yes
<Chipaca> but that doesn't give me a delta
<Chipaca> which might be the key difference
<Chipaca> I'm looking at that
<Chipaca> cachio: is it easy to build an image with beta snapd but stable kernel?
<cachio> otherwise I can share the image I have
<cachio> but it is gonna take some time
<cachio> Chipaca, let me check
<Chipaca> HAH
<Chipaca> it's the deltas
<Chipaca> cachio: no worrries
<Chipaca> cachio: this is not a regression, but it is a bug
<Chipaca> i shall fix
<Chipaca> â¦ somehow =)
<cachio> Chipaca, as I see you can add which snaps you want to use
<cachio> as a parameter
<cachio> but I didn't test it with the kernel
<cachio>         --channel "$CORE_CHANNEL" \
<cachio>         --output "$WORK_DIR/ubuntu-core.img" "$EXTRA_SNAPS"
<cachio> Chipaca, you can try that
<Chipaca> cachio: no worries
<Chipaca> cachio: I found the bug, as I said ^
<cachio> Chipaca, ok
<cachio> Chipaca, hehe
<cachio> much better
<cachio> Chipaca, thanks for chasing this
<Chipaca> np
<cachio> I'll go to the gym now :)
<cachio> see you tomorrow
 * cachio afk
<mup> PR snapd#6063 opened: store: also make snaps downloaded via deltas 0600 <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6063>
<Chipaca> cachio: ^ fwiw
<mup> PR snapd#6064 opened: many: move regexp.(Must)Compile out of non-init functions into variables <Created by chipaca> <https://github.com/snapcore/snapd/pull/6064>
#snappy 2018-10-30
<mup> PR snapd#6065 opened: cmd, strutil: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
 * Chipaca zzs
<mborzecki> morning
<mup> PR snapd#6066 opened: tests: fixes and new backend for tests on nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6066>
<zyga> Hello
<mborzecki> zyga: hey
<zyga> Fantastic day :-)
<mup> PR snapd#6059 closed: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6059>
<zyga> mborzecki: could you please review https://github.com/snapcore/snapd/pull/6063#pullrequestreview-169639370
<mup> PR #6063: store: also make snaps downloaded via deltas 0600 <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6063>
<zyga> it's trivial and needed for release
<mborzecki> zyga: done
<mup> PR snapd#6063 closed: store: also make snaps downloaded via deltas 0600 <Simple ð> <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6063>
<zyga> thanks!
<zyga> good morning mvo
<zyga> mvo: chipaca fixed the 0600 issue
<zyga> I Ccd you on the PR that is now in master
<zyga> how are you feeling this morning btw?
<zyga> is it also very warm for you today? In the morning it was almost 15C, very unusual for this time of year
<mborzecki> zyga: it was the same around 10pm yday ;)
<mvo> zyga: \o/ good morning
<mborzecki> zyga: if it stays like this for longer i see myself riding some bike on thursday :)
<mvo> zyga: cold here and I'm tired
<zyga> mborzecki: do it today
<zyga> I already planned it with my daughter
<mvo> zyga: but less so than yesterday so yay
<zyga> it's going to be 22C today :)
<mvo> and good morning mborzecki
<mborzecki> mvo: hey :)
<zyga> mvo: that's too bad, maybe you should sleep in after all :)
<mvo> zyga: heh - I need to get into my timezone :)
<mvo> zyga: is the fix already in 2.36? if not I cherry pick now
<zyga> mvo: it's not, please look at GitHub notifications
<mvo> zyga: I see it now, nice
<mvo> zyga: cherry-pick, thanks for the quick reviews (also to mborzecki)
<mvo> looks like 2.36.1 is ready :)
<zyga> thank you :-)
<zyga> yeah
<zyga> the classic fix is not important enough to merge, right?
<zyga> can wait for 2.37
<mvo> zyga: I think its ok to leave it unless you feel strongly about it
<zyga> no, I think it should stay out
<zyga> 2.36 is big and important and feels stable now
<mvo> yeah, I have the same feeling
<mvo> zyga: I may try to get 6062 in, field wants this
<zyga> aha
<mvo> zyga: it looks like there is a real bug there, something in the auth code goes to the net without a proxy
<zyga> yeah that looks ok
<zyga> hmm
<mvo> zyga: its hopefully small, just need to find what it is
<zyga> yep
<zyga> brb, need to tweak window shades
<zyga> it's super bright today
<mvo> zyga: ok
<pieq> Hi!
<zyga> mvo: pieq is from CE and has a question about the release schedule of 2.36.1
<mborzecki> snapshot job failed on master: https://paste.ubuntu.com/p/2xHwcG4Kf5/
<mvo> zyga: hey pieq, a rough eta is monday in 2 weeks (12 Nov). do you have any specific deadlines that we should know about?
<zyga> mborzecki: chipaca knows, we talked about it
<mvo> I will also update the snap roadmap it a bit out of date right now, sorry for that
<zyga> mborzecki: there's a PR that adds logging, it could use a 2nd review
<mborzecki> ack
<mborzecki> zyga: #6060?
<mup> PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
<zyga> yes
<mvo> zyga: I looked at it had the same question about the matchall writer as you
<zyga> hey Chipaca
<Chipaca> morning
<pieq> mvo hey, sorry for the long silence :) No specific deadline. Since 2.36 is already in beta, guess this shouldn't take too long to be released
<pieq> (I ask cause I'm interested in the snap layouts feature developed by zyga. I use it for a snap and currently it seems to work fine except for a UC16 device we have here running core 2.35.4)
<pstolowski> morning Chipaca
<Chipaca> pstolowski: 'sup
<pstolowski> Chipaca: do you have a moment to talk about the fat PR?
<Chipaca> pstolowski: yes
<Chipaca> pstolowski: hangout, or irc?
<pstolowski> zyga: you? ^
<zyga> +1
<zyga> gladly
<pstolowski> Chipaca: hangout
<Chipaca> ok, let me get set up. 5 minutes? actually 10 so i can get more coffee
<mborzecki> 'fat PR'
<Chipaca> let's call it 0930 GMT
<mborzecki> should have a label for that
<Chipaca> mborzecki: or not have them :-)
<pstolowski> Chipaca: ok, in 10min
<pstolowski> that would be a funny label i'm sure
<doko> snapcraft autopkg tests are failing in bionic, all archs
<mup> PR snapd#6067 opened: tests/main/snap-service-after-before-install: verify after/before in snap install <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6067>
<Chipaca> ChanServ: what have you *done*?!?
<Chipaca> oh hi ogra
<ogra> heh
<mborzecki> zyga: wow, applied your suggestion directly on github, didn't know it was possible
<zyga> ha, yes :)
<zyga> it's nice
<Chipaca> mvo: did #6062 actually point out the error and now it's grown the fix?
<mup> PR #6062: tests: add test to ensure proxy is used even without core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
<Chipaca> mvo: first time I looked at it it was just a spread test =)
<mborzecki> btw. maybe we should allow executing systemd-notify in daemon-notify iface?
<zyga> I'll be coding quietly in the corner, please ping me for attention
<zyga> I won't do reviews today
<mvo> Chipaca: correct
<mvo> Chipaca: let me update the description
<mvo> Chipaca: it started as a simple test to ensure this really works but it turned out that the device session stuff is not using the proxy so things explode
<Chipaca> mvo: tests ftw
<Chipaca> mvo: I wouldn't've been able to do the hackery I did last night to version.go without 'em =)
<mvo> Chipaca: yeah, nothing beats integration tests
<mvo> (except maybe real users)
<mvo> Chipaca: heh :) yeah, the version stuff is quite impressive
<mvo> Chipaca: just looked at it
<mvo> Chipaca: I want to look over the proxy stuff a bit, was wondering if some things should be methods on store.Store{} now - but my gut-feeling is no. but I'm not sure yet, maybe a new auth helper struct or something, want to medidate a bit over this. ideas welcome fwiw
<Chipaca> actual users beat everything, yes. Sometimes to death :-Ã¾
<Chipaca> mvo: me I'd like to refactor store so it doesn't pull in overlord stuff
<Chipaca> mvo: (mostly auth)
<Chipaca> so maybe there's something there
<Chipaca> i mean, maybe these two things are the same thing :-)
<mvo> Chipaca: with the proxy setting stuff we need state it seems, no?
<Chipaca> mvo: yes. But does store need to know it's state, or is there an interface that would serve?
<Chipaca> it's the things calling it that need to get the actual state; store shouldn't care
<mvo> Chipaca: aha, yeah, an interface is probably fine
<mborzecki> Chipaca: as for version, we had some code checking kernel version and VersionCompare would trip over the uname -r in Arch
<Chipaca> imo
<mvo> Chipaca: thats a good idea for direction
<Chipaca> mborzecki: the old one, or the new one, or both?
<mborzecki> Chipaca: old one, probably new one too
<pieq> mvo, zyga another question: will snap layout feature leave its experimental status with the release of snapd 2.36? Or will we still have to manually type `sudo snap set core experimental.layouts=true` before isntalling a snap using it
<Chipaca> mborzecki: AIUI our VersionCompare is just debian's
<zyga> pieq: you won't have to do that in 2.36
<Chipaca> pieq: layout is no longer experimental in 2.36 as it exists in beta today
<zyga> you can still disable it by setting it to false
<pieq> \o/
<zyga> but absence of a setting is now interpreted as true
<Chipaca> pieq: why not install beta and try it out? feedback needed
<pieq> zyga, Chipaca ok thanks for clarifying it!
<pieq> Chipaca, I already did actually, but I machinally typed the command anyway :)
<mborzecki> Chipaca: uname -r is currently 4.18.16-arch1-1-ARCH, iirc i saw 4.18.2-arch1.a2-1-ARCH at some point too
<Chipaca> /o =)
<Chipaca> mborzecki: ah, too many dashes for ours to be happy
<mvo> yeah, version compare only allows a single "-"
<Chipaca> we could relax that easily, fwiw
<mvo> (the debian version policy is written this way where we inherited this from
<mvo> )
<Chipaca> "easily" -> generalise it to arbitrary number of -s
<mvo> what would the semantic be if we do that? 1-1 is lt,gt 1 ? 1-1 lt/gt 1-1-1 ?
<Chipaca> only question that'd need answering is, is 1-1 >? 1-1-1
<Chipaca> exactly
<mvo> (we could treat it just like a ".")
<mvo> for the kernel we simply could ignore everything after the second "-" (including the second "-")
<mvo> 4.15.0-36-generic should be equal in version to 4.15.0-36-bigtable
<Chipaca> augh, i'd meant to tag you in the pr that changes version this much, but forgot (was very late...)
 * Chipaca does it now
<mvo> no worries
<Chipaca> mborzecki: is that right, on arch? ^
<Chipaca> mborzecki: and, what did we use the kernel version compare for? =)
<mvo> don't we already strip the second "-" anyway?
<mvo> fwiw, I updated the description of 6062
<mborzecki> Chipaca: it was used to guess whether we should degrade apparmor profile, but then i dropped it because the host is always using the latest mainline
<mup> PR snapd#6068 opened: ifacestate/helpers: findConnsForHotplugKey helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6068>
<pstolowski> Chipaca, zyga ^ exposing connState wasn't neccessary at the end
<mvo> Chipaca: would love to hear your opinion on https://github.com/snapcore/snapd/pull/6062#discussion_r229244418 (and the one below). if we make User{Login,Info} part of the store interface this PR would probably slightly shorter and it seems to also make sense that this is part of the store interface (even though it bloats the interface)
<mup> PR #6062: tests,store,daemon: ensure proxy settings are honored in auth/userinfo too <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
<mborzecki> zyga: pstolowski: are you taking 02.11 off too?
<zyga> yes
<mborzecki> ah, nice :)
<pstolowski> i'm not
<mvo> me too
<Chipaca> mvo: that sounds alright
<Chipaca> mvo: will comment on the pr
<mvo> Chipaca: ta, will do
<Chipaca> going for a run, bbl
<mup> PR snapd#6069 opened: ifacestate/hotplug: removeDevice helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/6069>
<sborovkov> ogra: btw, on the matter of force_turbo. The only reason we want to turn it on is because there seems to be some bug in firmware or kernel module. When we play videos it will correctly start ramping up in 1 of 30 playbacks which is so weird... The same goes about governing policy. It ramps up extremely slow. Both on core and raspbian.
<mborzecki> so today is red dead travis job day
<mborzecki> oh and opensuse mirros have hiccups again
<mborzecki> pstolowski: is information wehether a connection is auto/manual kept in the state only?
<pstolowski> mborzecki: yes
<mborzecki> pstolowski: i'm looking aroudn the code, but it does not seem to be available in ConnRef or interfaces.Info
<mborzecki> pstolowski: wondering if, in the context of https://forum.snapcraft.io/t/rfc-snap-connections-command/4296 we should show hotplug in Notes column too
<pstolowski> mborzecki: we will only auto connect hotplug slots if their interfaces are declared as such
<pstolowski> mborzecki: but yeah, we might want to show something about hotplug
<mborzecki> pstolowski: https://paste.ubuntu.com/p/TcGjVXbm5D/ snap connections output i'm currently playing with (sans manual/hotplug in the notes column)
<pstolowski> mborzecki: hotplug can be manual as well
<mborzecki> pstolowski: right, so that would be hotplug,manual in the notes
<pstolowski> mborzecki: hotplug will just create slots dynamically, some of them may auto-connect, some you need to connect manually
<mvo> Chipaca: heh, just looking at the proxy stuff it is already pretty abstracted, it does not pull anything state related in (yay)
<mborzecki> pstolowski: what the example slot names for say usb serial device?
<pstolowski> mborzecki: they are automatically generated from some key attributes - e.g. "ft232rusbuart" (one of the adapters i test with). another example "qemuusbserial" for qemu virtual adapter
<mborzecki> pstolowski: thx
<mvo> opensuse is unhappy it seems, second failure this morning related to repo install/update
<mup> PR snapd#6070 opened: store,daemon: make UserInfo,LoginUser part of the store interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/6070>
<mvo> Chipaca: ^- what we discussed, happy to move it all into a single PR if you prefer this, either way is fine for me
<mvo> Chipaca: the upside is that the mocks in the api_test get simpler too
<Chipaca> mvo: nice
<Chipaca> mvo: I'll review properly after the standup (now making lunch)
<Chipaca> trying to not get caught out like i was yesterday
<cachio> pstolowski, you can use #6066 to develop hotplug tests
<mup> PR #6066: tests: fixes and new backend for tests on nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6066>
<cachio> pstolowski, it runs in 11 minutes the test
<pstolowski> cachio: wooah, awesome!
<pstolowski> cachio: thank you, will merge into my branch and try it soon
<cachio> pstolowski, nice
<mup> PR snapd#6071 opened: ifacestate/hotplug: updateDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6071>
<Chipaca> sborovkov: is it the cpu, or the gpu ramping up?
<ogra> Chipaca, it is "delaying the cpu from ramping up" as i understood
<Chipaca> yeah, but i thought they were doing gpu decoding
<Chipaca> so maybe it's the gpu? dunno
<Chipaca> i know nothing =)
<ogra> could be ... we dont really support the proprietary driver on the Pi ... so it could well be some drawback in the opensource vc4 driver
<sborovkov> Chipaca: both I think
<mup> PR snapd#6064 closed: many: move regexp.(Must)Compile out of non-init functions into variables <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6064>
<sborovkov> Chipaca: if we have on demand scheduler ramping up of CPU happens slowly. If we play 10 second videos - they all take 60 ms per frame. Eventually it goes to the 30 ms per frame. And then if stars align they stop underclocking GPU and memory and it goes to 13 ms per frame, but that almost never happens.
<mvo> Dmitrii-Sh: thanks again for your proxy report, I updated the LP bug and pointed to the PR that should fix the issue. thanks again for reporting!
<Dmitrii-Sh> mvo: thanks for following up! I'll give it a try
<sborovkov> Chipaca, ogra and cpu usage is super low. The only thing that's taking up cpu is audio decoding which is not a lot. I found it by chance basically. 30 ms was what happened in most of the cases. Until I came back to my rpi in the next morning and it magically was taking 13 ms per frame. and since force_turbo does not overclock but prevents it to go to the low frequencies when idle that seems to be the answer. force_turbo also set couple of options like
<sborovkov> minimum frequeny for cpu, gpu and memory to higher values.
<ogra> right, it is simply not as power effectiver after you set it ... but since you dont run on battery (i assume) this is ignorable
<Chipaca> mborzecki: so... vercmp (https://git.archlinux.org/pacman.git/tree/src/util/vercmp.c) is just a frontend for alpm_pkg_vercmp, which is in https://git.archlinux.org/pacman.git/tree/lib/libalpm/version.c
<Chipaca> mborzecki: and it's just doing rpmvercmp on EVR
<Chipaca> epoch-version-release
<Chipaca> no
<Chipaca> epoch:version-release
<mborzecki> looking
 * Chipaca drags people into the madness
 * Chipaca walks away
<mborzecki> Chipaca: /* whichever number has more digits wins */ heh
<Chipaca> mborzecki: so i think that instead of supporting arch-style versions, we want to go with plan B
<Chipaca> mborzecki: run away screaming
<mborzecki> Chipaca: plan C, do nothing until required
<Chipaca> interestingly it claims to be taken from rpm, so
<Chipaca> mborzecki: that's like plan B but for sensible people
<mvo> afaict in rpm only a single "-" is speced
<mvo> aha, no - it seems they cut after the first "-" but then its legal in the "remainder"
<Chipaca> mvo: this only looks at one -; the rest are â¦ for free? i think. maybe
<mborzecki> Chipaca: https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmvercmp.c
<mvo> anyway I like the idea of ignoring it until it becomes a problem :)
<Chipaca> mborzecki: https://github.com/rpm-software-management/rpm/blob/ff4b9111aeba01dd025dd133ce617fb80f7398a0/lib/rpmvercmp.c#L94
<Chipaca> mvo: yep
<Chipaca> anyway, i'll probably split the current thing into two prs as per zyga's request
<Chipaca> but tonight when i'm in that sort of a mood
<mborzecki> since go-1.10 appears to be in xenial-updates and trusty updates, can we drop importing golang.org/x/net/context now?
<mborzecki> Chipaca: mvo: ^^
<Chipaca> mborzecki: hmm
<Chipaca> mvo: did you talk any further on removing go from main?
<mborzecki> off to pick up the kids
<mvo> Chipaca: we did not talk about removing go from main
<mvo> mborzecki: I think we can and move to go 1.9
<mvo> zyga: sent mail about /v2/interfaces
<zyga> Ack mvo
<zyga> Iâll reply in one hour
<mvo> Chipaca: snap info core and the new slightly highlighted channel that is tracked is such a nice feature (subtle but really nice)
<Chipaca> mvo: also a little bit buggy =) but yes
<mvo> Chipaca: not buggy for me :)
<mvo> Chipaca: its one of those nice touches that makes me thing that "woah, extra polish"
<Chipaca> mvo: when there is a refresh not yet applied, it might seem wrong
<Chipaca> mvo: but it's very subtle, and arguable
 * mvo nods
<mvo> Chipaca: aha, so after "snap switch" the output might be confusing?
<mvo> (until the next refresh)
<Chipaca> mvo: yes
 * mvo nods
<Chipaca> emphasis on might
<mvo> yes
<Chipaca> we might need some polish on the polish
<Chipaca> like, bold one line and caret the other
<Chipaca> or sth, dunno
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> it does make it a lot easier to spot the thing you're on
<mvo> yeah, what we have is pretty nice even with the caveats you gave
<cachio> pstolowski, I have update the branch with an intermediate solution
<cachio> hotplug takes 15 minutes with this
<pstolowski> cachio: ok, thanks for the info
<cachio> I'll continue working on another PR which uses the other aproach which takes 11 minutes
<cachio> but I need to work a bit more in order to get a good solution for all the tests
<cachio> core revert test went from 36 to 17 minutes with this approach
<cachio> that0s good improvemente
<pstolowski> cachio: yes, it's fantastic
<mup> PR snapd#6072 opened: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6072>
 * Chipaca hugs cachio 
<Chipaca> cachio: that's awesome dude
<cachio> Chipaca, tx
<zyga> re
<zyga> halloween costume procured
<zyga> Chipaca: should the polish on polish be added by polish?
 * cachio lunch
<Chipaca> zyga: SolidarnoÅÄ! or something
<zyga> haha
<zyga> nice, including ÅÂ and Ä
<Chipaca> yeah they charge extra for those, but I thought it was worth it
<mup> Issue core18#56 closed: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
<mup> Issue core18#86 closed: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
<mup> PR # closed: core18#43, core18#63, core18#72, core18#83, core18#84
<mup> Issue core18#56 opened: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
<mup> Issue core18#86 opened: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
<mup> PR # opened: core18#43, core18#63, core18#72, core18#83, core18#84
<pstolowski> cachio: just tested it, it's day and night!
<pstolowski> ty!
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2380, snapcraft#2387
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#1905, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2289, snapcraft#2354, snapcraft#2359, snapcraft#2380, snapcraft#2387
<Pharaoh_Atem> zyga: so we're finally going to have the gcp packages as part of fedora, and we're looking to figure out how to let google let us have official images in GCP
<zyga> Pharaoh_Atem: that's good to know
<zyga> thank you for sharing
<zyga> oh, I have one thing to share as well
<zyga> I was working with Zbyszek on mkosi
<Pharaoh_Atem> oh?
<zyga> and we will be working on fedora29 base snap release
<Pharaoh_Atem> sweet
<zyga> built entirely by mkosi
<Pharaoh_Atem> that's actually sweet
<Pharaoh_Atem> that's similar to what I was working on :)
<Pharaoh_Atem> I wish I had known
<zyga> it started last Friday
<zyga> sorry for not mentioning it before
<zyga> some busy days
<zyga> and then the IBM thing
<Pharaoh_Atem> yeah...
<zyga> so after Zbyszek is recovered from shock I we will meet up again to work on mkosi
<zyga> I am writing static typing support for it
<Pharaoh_Atem> cool
<zyga> so that the quality is better
<Pharaoh_Atem> mkosi is a really nice, simple tool
<zyga> and zbyszek has made it possible to build base snaps with it
<Pharaoh_Atem> sweet
<Pharaoh_Atem> which means all distros can use it
<zyga> so some more work remains but progress looks good
<zyga> yeah!
<Pharaoh_Atem> and maybe ubuntu will switch to it too :P
<zyga> I was thinking about it actually
<zyga> it remains to be seen
<zyga> but it's foundations now
<zyga> not us doing the core snaps
<zyga> (finally)
<Pharaoh_Atem> I figured mkosi would also make it easier to make lightweight bootable snaps
<zyga> anyway, we need to work on the essentials first
<zyga> shipping updated mkosi :)
<zyga> so that's that
<Pharaoh_Atem> that part is easy on the fedora side :)
<zyga> I'm working on a suse update
<zyga> and there's some fedora work scheduled this cycle, we should get much better selinux support
<zyga> so looking forward to that
<zyga> maybe (though not for sure) some work on selinux backend for services
<zyga> we'll see about that
<pstolowski> zyga: hey, do you have a moment to take a look at #6068?
<mup> PR #6068: ifacestate/helpers: findConnsForHotplugKey helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6068>
<zyga> pstolowski: yep, sure
<zyga> done
<pstolowski> zyga: thanks! fwtw i added ordering in the test
<zyga> I missed that, I see it now
<zyga> how are you planning on using this?
<zyga> should ordering be built in?
<pstolowski> zyga: ordering doesn't matter for real use.. so only relevant for tests
<pstolowski> zyga: regarding your other suggestion to have map[string]*connState, it's sensible, but I'll need to change getConns and setConns as well (and likely a few places where they are used)
<pstolowski> cause they also have map[string]connState
<zyga> pstolowski: don't change it here
<zyga> just wondering aloud really
<zyga> about the ordering still
<zyga> will the result be typically 0-2 elements long?
<pstolowski> probably yes
<zyga> could we add sorting then
<pstolowski> sure
<zyga> I'm slightly against non-deterministic ordering leaking around the code
<zyga> if it is cheap, let us just do it please
<pstolowski> yep that's fine
<zyga> thank you
<zyga> approved!
<pstolowski> thanks
<zyga> thanks :)
<zyga> offtopic
<zyga> new Mac mini looks like a pretty great deal
<Chipaca> zyga: pstolowski: I liked it more when it sorted for the tests =)
<zyga> Chipaca: nondeterminism spreads like tainted perl values :)
<Chipaca> zyga: that's what she said!
 * zyga is speechless ;)
<Chipaca> sometimes for the best
<zyga> busted!
<Chipaca> zyga: universally, not just you
<zyga> that's what she said ;)
 * Chipaca approves ALL the PRs
<zyga> kids can play when adults are off ;)
<zyga> we can revert on Monday
<Chipaca> sigh, another snapshot error with no good logs
<zyga> Chipaca: can we merge anything to make it possible to collect them?
<zyga> this reminds me, I need to prepare a proper PR for my idea for collecting logs for mount ops
<zyga> maybe there's something to learn?
<zyga> using a feature flag file I now collect logs for what happens in each mount namespace
<zyga> alonside the mount namespace
<Chipaca> zyga: #6060 is for that
<mup> PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
<zyga> yeah but that's ... not sure
<zyga> it doesn't feel right
<zyga> the matches
<zyga> *matcher
<Chipaca> zyga: I can drop that bit, all I was  doing was making the errors on read  an write the same
<zyga> I'd +1 that
<Chipaca> zyga: what is it that you don't like about the matcher?
<zyga> It feels heavy to process all output this way
<zyga> but perhaps I was mistaken
<Chipaca> zyga: as opposed to which way?
<zyga> not sure, redirecting all output to a log file when env is set
<zyga> or something similar
<zyga> but perhaps I'm just picky
<zyga> sorry about that
<Chipaca> zyga: um
<Chipaca> zyga: so, what this does is
<Chipaca> zyga: it catches and remembers the first line of stderr of tar
<Chipaca> zyga: and counts lines from there on
<Chipaca> zyga: if SNAPPY_TESTING is set,  it also writes to stderr
<zyga> using regular expressions :)
<zyga> that was the part I was objecting to
<Chipaca> hmm
<zyga> let's push that for tomorrow
<Chipaca> I'm missing what's bad, here :-/
<Chipaca> but ok
<Chipaca> tomorrow is fine
<mup> PR snapd#6073 opened: strutil: let MatchCounter work with a nil regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/6073>
<Chipaca> zyga: ^
<zyga> aha
<ackk> hi, I have a (classic) snap that stopped working (not sure when), it currently seem to just hang
<ackk> a strace stops at the exec of snap-confine
<ackk> how can I debug the issue (tried on different systems and ubuntu releases, same result)
<mup> PR snapd#6074 opened: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
<ackk> zyga, any idea what could cause this issue? ^
<Chipaca> ackk: are you using 'snap run --strace'?
<Chipaca> ackk: or are you strace'ing snap run?
<ackk> Chipaca, snap run --strace
<Chipaca> ah
<Chipaca> dunno :-)
<ackk> Chipaca, it's a published snap fwiw
<Chipaca> ackk: public?
<ackk> yeah
<ackk> Chipaca, snap install --edge --classic sshoot
<ackk> (then "sshoot")
<Chipaca> hm, something is really slow
<cachio> kyrofa, hey
<cachio> did you already merged the change on the images?
<cachio> Saviq, hey
<cachio> we are changing the name of the images with virt enabled
<cachio> if you are using them please tell me
<Chipaca> zyga: btw you might like the pretty pics on #6074
<mup> PR #6074: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
<zyga> ackk: hey
<cachio> Saviq, because a change in the names is needed
<zyga> ackk: is it spinning with 100% CPU?
<zyga> Chipaca: looking at 6074
<zyga> woah
<zyga> man
<zyga> that's impressive
<zyga> I will review tomorrow as tonight I feel too tired to think about that reasonably
<Chipaca> I'm particularly happy with the 0s
<zyga> but I want to ack the effort!
<zyga> ackk: if it is spinning on 100% CPU
<zyga> ackk: it may be in an exec loop
<zyga> ackk: it typically happens in a scenario like this:
<Chipaca> store is timing out, fwiw
<zyga> ackk: foo (command)
<zyga> ackk: foo -> snap run foo -> snap-confine -> snap-exec -> (look up and run foo) -> /snap/bin/foo -> snap run foo (Oh my...)
<Saviq> cachio: ack, not using them yet - we noticed fedora 27 is gone now? (not a problem, just in case this is unexpected)
<Saviq> should there be 29 images yet?
<cachio> Saviq, is it already released?
<ackk> zyga, it does seem something like that
<cachio> Saviq, I'll check that and create the image tomorrow
<ackk> zyga, and yes, it's spinning
<zyga> just change command
<ackk> wdym
<zyga> to use $SNAP/bin/stuff
<zyga> +1
<Chipaca> ackk: it does look like the command wrapper will find itself again
<Chipaca> ackk: especially as you're classic
<ackk> Chipaca, ah I see
<mup> PR snapd#6075 opened: tests: removing fedora 26 system from spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6075>
<mup> PR snapd#6076 opened: tests: linode execution is not needed anymore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6076>
 * mvo hugs Chipaca for 6074 - slightly crazy but in a good way :-D
<kyrofa> cachio, just merged
<mup> PR snapcraft#2387 closed: spread: change virt-enabled image name <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2387>
<ackk> Chipaca, zyga thanks, that was the reason
<zyga> ackk: cool
<zyga> I wonder if we can detect that ...
<cachio> kyrofa, perfect, thanks
<Saviq> cachio: just about - https://fedoraproject.org/wiki/Releases/29/Schedule
<cachio> Saviq, nice, thanks
<cachio> tomorrow I'll work on that
 * cachio afk
<popey> oh, 2.35.5 just released?
<zyga> mvo is busy at night
#snappy 2018-10-31
<fayg0> hey anyone here have any luck with rocket chat irc federation ?
<mborzecki> morning
<zyga> o/
<zyga> hey mborzecki
<pieq> already up zyga ?! :)
<zyga> yes
<zyga> how are you Pierre? :)
<pieq> zyga, good good! And you?
<pieq> it's finally getting cold here in Taipei :)
<zyga> really?
<zyga> it was 22C yesterday
<zyga> weather anomaly like nothing before
<zyga> today it is colder but not anywhere near being really cold yet
<pieq> well... it's 19 Â°C
<pieq> I have to put something on top of my t-shirt, that's my definition of "cold" :)
<zyga> haha, yes, that's Spain-level cold :)
<mborzecki> hmm would like to get https://github.com/snapcore/snapd/pull/5696 to a state where it can be landed
<mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>
<mborzecki> damn, cuda-samples from ijohnson is huuge
<mborzecki> and fedora 29 is out, the mirrors are down :/
<zyga> hmmm
<zyga> mborzecki: heh, yes
<zyga> I'm pulling 29 to try
<zyga> mborzecki: did you see my suggestion on 5696
<zyga> maybe we should just drop that part
<zyga> and even hardcode the mknod in snap-confine?
<zyga> golang question:
<zyga> I have a struct with another struct inside
<zyga> the inner struct is defined inline, that is, it has no type name
<zyga> how do I make literals of that type?
<mborzecki> zyga: yeah, i want to check if you can precreate the node and if stuff continues to work then we should be fine
<mborzecki> zyga: iirc it used to work like this in early cuda versions, you had to create the node manually and so on
<zyga> I think it must work
<zyga> after all, cuda creates the nodea
<zyga> and then it is there
<zyga> so ...
<zyga> if it is a fixed major/minor
<zyga> let's just do it
<mborzecki> zyga: i'm installing a snap from ian, if it works, then i'll update the PR and we can land it
<zyga> ok
<zyga> cool :)
<pstolowski> heyas
<mborzecki> zyga: there was a topic about cuda and ubuntu core, left a note there, https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/45 maybe you have some ideas
<mborzecki> pstolowski: hey
<zyga> hey pawel
<mup> PR snapd#6068 closed: ifacestate/helpers: findConnsForHotplugKey helper <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6068>
<zyga> mborzecki: interesting
<zyga> mborzecki: based on what you said I'd say the most stable, long term solution for loading firmware would be where snapd would run an internal helper in the main mount namespace
<zyga> and that helper would arrange for the firmware to be loaded
<zyga> to both detach from the need for granting apps the permission
<zyga> and to be in control of the mount namespace
<mborzecki> zyga: mhm, something like that
<mborzecki> zyga: snapctl request-firmware :)
<mborzecki> and dd that to sys node
<zyga> could be just snapd doing it itself
<zyga> we may not really need a new command
<zyga> if it is really an ioctl and dd
 * zyga installs F29 now
<mborzecki> zyga: yup, seems to work with manually created node
<zyga> another hack in Nvidia land
<zyga>  but ... whatever :)
<zyga> perhaps it should be a part of the mount profile?
<zyga> we can create symlinks
<zyga> we could create device nodes
<mup> PR snapd#6077 opened: overlord/ifacestate: use map[string]*connState when passing conns around <Created by stolowski> <https://github.com/snapcore/snapd/pull/6077>
<mborzecki> zyga: we'd need to teach snap-update-ns to create nodes
<zyga> yeah but that's not difficult in the current architecture
<mborzecki> mhm
<zyga> it's really a minor bump over symlinks
<mborzecki> wow, the tests are really slow on my gt1030
<Chipaca> o/
<zyga> hey Chipaca
<zyga> mborzecki: what does the test entail?
<pstolowski> morning Chipaca!
<mborzecki> zyga: heh, i think it's stuck
<Chipaca> I'm seeing red today
<Chipaca> and not in a berserker kind of way
<mborzecki> Chipaca: fedora got a new release :)
<mborzecki> heh maybe we should start putting fedora on manual ahead of the release
<Chipaca> mborzecki: I'm seeing failures in ubuntu things that shouldn't be failing
<Chipaca> bah
<Chipaca> yesterday the new core release meant the store was unusable from tests for a few hours
<Chipaca> then the travis osx image stopped shipping ruby -> no homebrew -> red osx test
<Chipaca> the ubuntu thing hadn't properly resolved before I had to sleep, at ~1am
<Chipaca> and now travis is fixed, and the store seems to be fine, but I'm still seeing some failures that make no sense unless the store is not fine
<Chipaca> tests/regression/lp-1693042 in particular
<zyga> regression tests are useful
<zyga> well
<zyga> interesting day
 * zyga needs coffee
<zyga> re
 * zyga got a dentist appointment at 14:30 
<zyga> but I can do the standup on the go
<chesty> I finally got x2goclient snap working, thanks for the help. After I worked around the bug in libssh x2go tried to open /tmp/.X11-unix/X0 and failed, I didn't spend anytime on looking into it as I figured there's no way around it other than classic mode, and it worked in classic mode so I'm happy. cheers
<pstolowski> :3043
<pstolowski> ups, wrong window
<Chipaca> chesty: do you have the x11 interface?
<chesty> i do, yes
<chesty> i don't have desktop or desktop-legacy
<Chipaca> chesty: the x11 interface allows access to /tmp/.X11/X0
<Chipaca> also /tmp/.X11-unix/X0
<Chipaca> (first one was a typo)
<chesty> weird, I just double checked, I definitely had and still have the x11 plug
<Chipaca> *also* /tmp/.X11-unix/X12345676543234567654345676543456765432345678
<Chipaca> :-)
<Chipaca> zyga: mborzecki: who's best for looking into ^ x11 socket denials?
<chesty> i only have 12345676543234567654345676543456765432345677 xservers running, so I don't require 12345676543234567654345676543456765432345678
<Chipaca> chesty: ah, that's your issue, 12345676543234567654345676543456765432345677 is prime
 * Chipaca hasn't really checked
<chesty> hehe, don't worry, I'm on the internet so I believe everything I read
<chesty> I've now forwarded to all my facebook friends and they believe it too
 * Chipaca becomes president of the american mathematical society
<mborzecki> Chipaca: /tmp/.X11-unix/X12345676543234567654345676543456765432345678 as in nvidia prime?
<chesty> and further more I didn't see any apparmor denies
<chesty> or warnings, it was in devmode
<Chipaca> alas, 12345676543234567654345676543456765432345677 = 7Ã13Ã1305511Ã602162345977Ã172575591847420434324601 (5 distinct prime factors)
<Chipaca> chesty: wait
<chesty> FAKE NEWS
<Chipaca> chesty: if it's in devmode, nothing is blocking your x11
<mborzecki> Chipaca: unless it's x itself
<Chipaca> chesty: and obviously x11 apps work snapped, you don't need classic for that
<Chipaca> exactly
<mborzecki> xhost + ?
<Chipaca> no :-(
<Chipaca> no xhost +
<Chipaca> bad mborzecki
<mborzecki> hehe :)
<Chipaca> bad!
<Chipaca> chesty: but, look at things that are not (strictly) snappy, for that denial
<chesty> x2goclient worked, I could see its GUI, but I think it spawns nxproxy which couldn't open /tmp/.X11-unix
<Chipaca> chesty: what happens without devmode?
<chesty> I don't understand, I might have my terms mixed up, is devmode a confinement?
<Chipaca> chesty: things are set up as in strict, but apparmor and seccomp use the unconfined profiles
 * Chipaca thinks he got the terms right there
<chesty> so when you say without devmode, I have to replace it with either strict or classic?
<Chipaca> chesty: strict, is what i meant
<Chipaca> classic is a different kettle of fish
<chesty> ok, I'm rebuilding with strict. it's take a few minutes so I'll ping you when it's done
<Chipaca> ok
<mborzecki> pstolowski: conflicts in https://github.com/snapcore/snapd/pull/6071
<mup> PR #6071: ifacestate/hotplug: updateDevice helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6071>
<popey> chesty: also, you can snap install snappy-debug, then run "snappy-debug.security scanlog" in a terminal when you run your snap to see what it thinks is missing in your interfaces
<pstolowski> mborzecki: thanks! will fix in a moment
<popey> chesty: https://docs.snapcraft.io/debugging-building-snaps/6274
<chesty> cheers popey, I actually stumbled on that last night
<chesty> previously I was looking at dmesg
<chesty> has anyone written a book yet on snapcraft? possibly hard to do atm being newish with lots of exciting changes, but I think I learn better from reading a book from page 1 to page 300. then I learn all the things I didn't know I needed to learn
<Chipaca> chesty: ssh, don't say that too loud or degville might hear you and get ideas
<ogra> being newish totally helps with that ... take notes on the side and once you are not "newish" anymore, write  the book from the notes ;)
<Chipaca> or what ogra said!
<chesty> ah, son of a gun, I need to rebuild it with desktop-launch, I have no fonts atm. I'll pastebin my yaml while I'm at it
<chesty> https://pastebin.com/Zc9zPw6M
<popey> I would make that command: desktop-launch $SNAP/bin/x2goclient (or whatever the path is to the executable)
<Chipaca> chesty: you don't need an empty . in the description, in yaml
<mup> PR snapd#6078 opened: ifacestate/ifacemgr: don't reload hotplug-gone connections on startup <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6078>
<Chipaca> chesty: also your last two lines of the description are indented more than the first line, which might look odd
<chesty> another weird thing I found after working around libssh was I was getting a message about libXcomp.so.5: file not found the file was there so I figured it was a shared library that was missing, I ran ldd on libXcomp and I added a bunch of debs explicitly in package-stage that made sure all the libraries were present that were listed in ldd and it f
<chesty> ixed that problem
<popey> i wrote a simple script which turns the output of ldd into a list of debs if that's any use?
<popey> https://gist.github.com/85644e69b4e55eed782908a79d9ed208#file-lddtostage
<popey> just point it at a binary and it will spit out a bunch of deb names
<chesty> I just had a black out. I'm back. thanks for the yaml tip Chipaca, the only reason I'm doing this is because x2goclient in 18.04 segfaults, and no one has responded to my bug report. I hadn't intended to upload it to the snap store, I'm just going to use it at work
<popey> chesty: got a link to the bug?
<chesty> here's the one against the package in ubuntu I filed. https://bugs.launchpad.net/ubuntu/+source/x2goclient/+bug/1799849
<mup> Bug #1799849: segfault when starting new session <x2goclient (Ubuntu):New> <https://launchpad.net/bugs/1799849>
<chesty> I also send a message, not a bug report, to x2go people, last I check I hadn't got a reply
<chesty> I think something changed in libssh threading, not sure though
<chesty> I got a DENIED on /home/michaelc/.ssh/known_hosts but I didn't have the ssh plug listed, rebuilding
<Chipaca> I love the "snap isn't working form me on WSL, what am I doing wrong?" bug report
<Chipaca> guess what we'll need to do someday =)
<sparkiegeek> Chipaca: +1
<Chipaca> the answer is "buy microsoft", if you were wondering
<chesty> lots of DENIED messages https://gist.github.com/chesty/428ed208c467f7f4e20c1244cfc3210a there were more than these, this is just the last. the gui still loads with these messages
<Chipaca> huh, i wonder why libuuid is blocked
<mborzecki> doesn't make sense for those libs to be blocked
<chesty> I added 2 entries regarding writing to known_hosts at the top of the file
<chesty> I'll gist my current yaml, I'm doing something wrong with the plugs, they are being ignored https://gist.github.com/chesty/903cc48cca629ccab4d5447bae4091d4
<popey> you are building this on 16.04, right chesty ?
<chesty> in the docker image snapcore/snapcraft
<chesty> DISTRIB_RELEASE=16.04
<popey> ah okay
<popey> groovy
<chesty> and I'm running it on DISTRIB_RELEASE=18.04 snap    2.36+git987.40fc2bf~ubuntu16.04.1
<chesty> I just noticed snap    2.36+git987.40fc2bf~ubuntu16.04.1 says ubuntu-16.04.1 but maybe that's right
 * pstolowski lunch
<Chipaca> oh traivs, y u so travis
<popey> Hey! I won't hear a bad word said about my mate travis!
 * ogra senses a custard-pie battle dawning
<popey> Chipaca: is there any particular reason there is no --quiet option for snap install?
<mup> PR snapd#6079 opened: [RFC] `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<mborzecki> low tech `snap connections`, RFC before I spend more time on it ^^
<zyga> mborzecki: nice!
<mborzecki> i'll start looking into cross snap service ordering if nobody minds?
<mborzecki> Chipaca: ^^ or is it something you wanted to look at?
<zyga> mborzecki: it looks very promising
<zyga> mborzecki: some ideas to think about:
<zyga> mborzecki: add --system to show system connections, hide those by default
<zyga> mborzecki: add "manual" note for non-auto connected stuff
<zyga> mborzecki: add "never" note for manually disconnected stuff
<zyga> mborzecki: add "content(foo)" note for content connections
<zyga> mborzecki: add interface(foo) if plug or slot name doesn't match interface name, remove the interface column
<mborzecki> zyga: manual is wip, some changes in the backend needed, i like the idea of adding 'never' for autoconnected but disconnected manually
<zyga> mborzecki: that's all for quick ideas
<zyga> mborzecki: some color coding or ordering could be tweaked for usability once we have a better feeling
<zyga> but I think this is super nice
<mborzecki> i'm sure Chipaca will have ideas about that :)
<zyga> mborzecki: perhaps also add --gadget or similar for IOT devices
<zyga> (like --system)
<zyga> or a note about the fact that it was made by the gadget
<mborzecki> zyga: right, connection made gadget is something we have in the backend too
<zyga> mborzecki: some more ideas
<zyga> allow showing attributes
<zyga> including labels
<zyga> and static / dynamic attributes
<Saviq> niemeyer: hey, did you ever get around to trying a fresh login to google for spread?
<kjackal> Hi snappy people, something is not right with snapd on debian 9. Just oppened forum topic https://forum.snapcraft.io/t/snapd-not-apt-installing-properly-on-debian-9/8240
<zyga> kjackal: thank you, we will check it out
<kjackal> zyga: Do we have an eta on the release of core?
<zyga> kjackal: core snap?
<kjackal> yes
<kjackal> There is a fix on apparmor profiles that allows the deployment of kubeflow on microk8s
<zyga> kjackal: is that 2.36? I think this is coming in ~2 weeks
<kjackal> In about two weeks, thank you zyga
<zyga> kjackal: the problem you are experiencing is as follows
<zyga> snapd in debian is very old but supports re-executing
<zyga> if you install core it will automatically allow snapd to run a newer version of itself
<zyga> if you install a snap by itself it will not work correctly because old snapd schedules the installation
<ogra> well, if core was never installed before shouldnt the first snap trigger the core install first ?
<zyga> I don't think we can fix this without updating snapd in Debian 9
<ogra> that doesnt seem to happen here
<zyga> ogra: it does
<zyga> ogra: but it doesn't mean new core will finish the installation
<zyga> and this is what happens here
<zyga> old core runs hooks
<zyga> and things mishbehave
<ogra> ah
<kjackal> zyga: Ok, so there are no plans in fixing this anytime soon?
<ogra> well, i dont see anything mentioning the installation of core after the "sudo snap install microk8s --classic" ... usually it prints something about core when it pulls that in
<zyga> kjackal: not that I know of
<zyga> kjackal: you must first install core
<zyga> kjackal: can you post "snap changes"
<zyga> in that thread please
<kjackal> Done, on the thread and here: https://pastebin.ubuntu.com/p/HCzBFppdBs/
<kjackal> zyga: should I try to address this on the snap side? Will this problem be present in other outdated distros?
<zyga> kjackal: I don't believe you can do anything about that yourself from within a snap
<zyga> ogra: ^ core is installed
<ogra> zyga, well, in change 5 ... after a manual "snap install core" it seems
<ogra> but not triggered by the installation of the microk8s snap
<zyga> that's weird,
<zyga> well, still
<ogra> change #1 should normally trigger the installation of core ... at least it does on my systems when i set up something that never had snapd
<zyga> we cannot do anything about old snapd
<ogra> i bet it is the --classic switch that makes it not do that (but only guessing)
<zyga> possibly
 * zyga quick lunch ahead of dentist
<kjackal> Do we have other outdated distros?
<Chipaca> mborzecki: hadn't we fixed the '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})' thing?
 * Chipaca realises the time and rushes to make lunch
<zyga> nope
<zyga> kjackal: I think Debian 9 is special in this regard
<kjackal> cool, good to know
<Chipaca> I wonder what /proc/version is on WSL
<mborzecki> Chipaca: no, we switched to using busctl to get saner error messages
<mborzecki> Chipaca: is it happening on 2.36 branch?
<Chipaca> yes
<mborzecki> i'll prep a pr with cherry pick of that change
<mborzecki> (as it went away magically too)
<pstolowski> mborzecki: standup?
<Chipaca> and my speedup version thing broke the build somehow. possible the benchmark thing
<Chipaca> cachio: ?
<mup> PR snapd#6080 opened: tests/main/interfces-accounts-service: switch to busctl, more debugging (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6080>
<mborzecki> Chipaca: ^^
<Chipaca> mborzecki: kthx
<ijohnson> mborzecki: I ticked the "allow edits from maintainers" box on my CUDA PR so you should be able to push to it. If you have time to take over that CUDA PR, go for it, I unfortunately haven't had time past few weeks. But I'm happy to run any tests in the background if you like, I have a few different NVIDIA cards I can test with
<mborzecki> ijohnson: thanks, let me try pushing the branch now
<mborzecki> ijohnson: aand pushed, yay!
<mborzecki> ijohnson: was cuda test suite super slow for you when you ran it?
<ijohnson> mborzecki: eh it takes maybe 10 minutes on my GTX 1050 but only took like 3 minutes on my titan X :P
<ijohnson> but it shouldn't hang anywhere, do you know which test it was hanging on for you?
<mborzecki> ijohnson: well, it appears stuck on my gt1030 :)
<mborzecki> ijohnson: it runs a couple of tests and appears stuck, maybe it's still crunching some numbers though it must be doing that really slow
<ijohnson> hmm that's unfortunate, but yes some of the tests are fairly intensive, but a 1030 should still be able to finish in a reasonablish amount of time. let me look at my test script and see how to make it more verbose on which test it's running so you can see which test it gets stuck
<ijohnson> oh actually it should say which sample it's running by default: https://github.com/anonymouse64/cuda-samples-snap/blob/master/bin/test-cuda.sh#L110
<mborzecki> ijohnson: it does, and i'm apparently not smart enough to figure out that you should close the window that popped up :/
<ijohnson> ah yeah that's a thing you do have to close the windows it opens, I wasn't able to figure out how to automatically close the windows
<mborzecki> ijohnson: anyways, loading nvidia-uvm and creating /dev/nvidia-uvm before i ran the samples did the trick
<ijohnson> mborzecki: good to know, thanks for testing
<mborzecki> Chipaca: so debian build also calls go generate then?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: export DH_GOLANG_GO_GENERATE=1
<Chipaca> mborzecki: in debian/rules
<mborzecki> Chipaca: interesting
<mup> PR snapd#6081 opened: overlord/ifacestate: mark connections disconnected by hotplug with hotplug-gone <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6081>
<mborzecki> heh, go geneate ./... and i learned about snap blame
<Chipaca> so it then runs this monster of a command
<Chipaca> mborzecki: look for 'go generate' in https://api.travis-ci.org/v3/job/448506794/log.txt
<mborzecki> Chipaca: wow, looks like `go generate $(go list ./...)`
<Chipaca> mborzecki: you didn't know about snap blame? :)
<Chipaca> mborzecki: with extra pie
<mborzecki> Chipaca: no i didn't, but now snap blame told me it's my fault :)
<Chipaca> mborzecki: it's obviously working correctly
<mborzecki> Chipaca: i know
<Chipaca> grah, another 2.36 failure: https://api.travis-ci.org/v3/job/448204858/log.txt
<mborzecki> Chipaca: hm some people appear to me more at fault than others, though my N=20something
<Chipaca> mborzecki: shocking
<pstolowski> zyga: another report re https://forum.snapcraft.io/t/cant-connect-interfaces-so-cant-run-snaps/8123/15 , can you comment on the fix?
<Chipaca> mborzecki: more pain from the generator :-(
<mborzecki> Chipaca: uhh, logs?
<Chipaca> dh_install: usr/bin/chrorder exists in debian/tmp but is not installed to anywhere
<mborzecki> oh, wow so it also does go install ./... ?
<Chipaca> yar
<Chipaca> mborzecki: do any of the other distros?
<mborzecki> not that i've seen
<mborzecki> Chipaca: fedora, arch and suse call go build -o ...
<mborzecki> Chipaca: it'd be fun to package a project with multiple small development tools
<Chipaca> I don't know how to tell dh_install to ignore this file
<Chipaca> hmm
<mborzecki> can yuu remove it afterwards?
<Chipaca> ah got it
<Chipaca> we're already removing several
<Chipaca> mborzecki: look at override_dh_install in debian/rules fwiw
<mborzecki> Chipaca: mhm, we do some cleanup there already
<zyga> Re
<zyga> pstolowski: looking
<zyga> Done
<pstolowski>  thanks
<mborzecki> off to pick up the kids
 * cachio afk
 * Chipaca afk
<Saviq> cachio: FYI, Fedora 29 is out
<mup> PR snapd#6082 opened: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6082>
<mup> PR snapd#6080 closed: tests/main/interfces-accounts-service: switch to busctl, more debugging (2.36) <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6080>
<mup> PR snapd#6073 closed: strutil: let MatchCounter work with a nil regexp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6073>
 * Chipaca <- dumb
<Chipaca> forgot to apply the delta to 1404 rules
<Chipaca> zyga: I changed #6060 to use the new nil regexp support in MatchCounter, if you could give it a second look sometime
<mup> PR #6060: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
<sil2100> rbasak: hey! You done with your SRU work for today?
<sil2100> Eeek, wrong channel
<sil2100> (please ignore)
<cachio> Saviq, hi, I alerady created the fedora 29 image
<cachio> I am fixing some issues araoung this now
<cachio> but you can try it
<zyga>  Chipaca +1
<zyga> approved :)
<Saviq> cachio: thanks, I'll try and add it to our CI - still can't try locally, couldn't get the right login credentials (or I've not enough privileges - Gustavo was looking into that)
<zyga> https://github.com/snapcore/snapd/pull/6074/files#r229779158 ?
<zyga> Chipaca: ^
<mup> PR #6074: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
<Chipaca> zyga: we usually do, yes
<zyga> usually?
<zyga> do we have any other files that we commit and generate?
<Chipaca> zyga: in all other cases where the file is generated, it's committed, afaik
<zyga> hmmm
<zyga> I don't suppose this file will change
<zyga> but I find it odd
<zyga> it's generated for a reason, why keep it in VCS?
<Chipaca> perhaps excepting cmd/version_generated.go
<zyga> drat, I have to go now
<zyga> sorry, I'll pick up reviews later
<pstolowski> zyga: what do you think about #6077 ?
<mup> PR #6077: overlord/ifacestate: use map[string]*connState when passing conns around <Created by stolowski> <https://github.com/snapcore/snapd/pull/6077>
<Chipaca> zyga: one reason for committing generated files is that without it you can't 'go get' the repo
<Chipaca> unless the code has been prepared for it (in this case it hasn't)
<Chipaca> zyga: what cmd/version_generated.go is populate a variable that's set elsewhere, so that one's ok
<Chipaca> zyga: if you don't have the generated file, you get version "unknown"
<zyga> pstolowski: approved, thank you
<pstolowski> thanks!
<zyga> Interesting Chipaca, I didnât know that
<zyga> It makes sense to commit based on this information
<Chipaca> grah
<Chipaca> debian now fails on 'systemctl restart snapd.socket' for no reason
<Saviq> cachio: hmm that's not something I've seen before: https://travis-ci.org/MirServer/mir/jobs/448948068
<cachio> Saviq, we are not testing on fedora-rawhide-64
<Saviq> cachio: we either, is there an image for rawhide now?
<cachio> just fedora 28 and in the future 29
<cachio> I have to create a new one
<Saviq> we've been upgrading from latest to rawhide so far
<Saviq> and that upgrade - 29 to rawhide - is what failed there
<cachio> Saviq, ahh
<cachio> ok, I'll need to do the same to create the rawhide image
<cachio> let me finish the changes to run snapd on f29
<cachio> and then I'll update fedora warhide
<cachio> just I need to fix one error on f29
<Saviq> ack, tx
<Saviq> alan_g: FYI â
<alan_g> Nice.
<zyga> cachio: hey, do you know about mkosi?
<zyga> It is pretty cool for making OS images
<zyga> And I know the upstream :-)
<zyga> It is a pet of systemd
<cachio> zyga, no, but sounds nice
<cachio> I'll take a look
<zyga> It is a single script
<zyga> Look at github/systemd/mkosi
<Chipaca> nice change of behaviour in systemd in debian-9
<Chipaca> https://github.com/snapcore/snapd/pull/6083
<mup> PR #6083: tests/lib: adjust to changed systemctl behaviour on debian-9 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6083>
<Chipaca> that'll need backporting to 2.36 as well as it's currently hurting
<mup> PR snapd#6083 opened: tests/lib: adjust to changed systemctl behaviour on debian-9 <Simple ð> <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6083>
<Chipaca> and now i must go
 * Chipaca afk for a good while now
<Chipaca> telegram works
<cachio> zyga, some tests failing on fedora 29 with the same error https://paste.ubuntu.com/p/W9fyHPZwDc/
<cachio> zyga, any idea whay it could be happening?
<zyga> Iâm afk now
<zyga> Iâll check back home
<cachio> zyga, sure, tx
<cachio> no errors on dmesg
<cachio> no errors on journalctl
<kyrofa> Hey niemeyer, are you around?
<niemeyer> kyrofa: Sort of.. I'm on security border line right now
<niemeyer> kyrofa: I've seen your mail about the arm server.  Sorry I didn't manage to look into it yet
<kyrofa> niemeyer, ah, nevermind then. Hoping to chat about extensions after the sprint, but it can wait until you're actually working!
<kyrofa> No worries on the server, when you have time
<niemeyer> kyrofa: I should be in the hotel in an hour or two.. happy to talk
<kyrofa> niemeyer, ping me if you're up for it, but no pressure
<niemeyer> Thanks, talk soon
<cachio> Pharaoh_Atem, hey, I am getting this error -> Error: Failed to synchronize cache for repo 'fedora-modular'
<cachio> I am running fedora-upgrade from 29 to rawhide
<cachio> did you know about that?
<cachio> Son_Goku, hey
<cachio>  hey, I am getting this error -> Error: Failed to synchronize cache for repo 'fedora-modular'
<cachio>  I am running fedora-upgrade from 29 to rawhide
<cachio> did you know about that?
<mup> PR snapd#6066 closed: tests: fixes and new backend for tests on nested suite <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6066>
<zyga> cachio: no idea, perhaps strace it to see what is being executed
<cachio> zyga, yes, I'll try that
<Pharaoh_Atem> cachio: yeah
<Pharaoh_Atem> I think the modular repo may not exist yet for rawhide
<cachio> Pharaoh_Atem, ahh, ok, I'll fix it, thanks
<cachio> Pharaoh_Atem, do you now when is it gonna be created?
<Pharaoh_Atem> cachio: it should technically exist now, at least it exists on my rawhide mirror (I just checked)
<Pharaoh_Atem> so I dunno
<cachio> Pharaoh_Atem, ok, thanks
<cachio> I'll try tomorrow again
<popey> ogra: i have a Wyse 120 physical terminal connected via USB serial to my Ubuntu Core laptop (Don't ask)...
<popey> http://0pointer.de/blog/projects/serial-console.html - any reason why that wouldn't work?
<popey> I have agetty running against ttyUSB3, but wondered if there was any module or something that would prevent this working
<popey> I see the module loaded in dmesg, so the serial usb device "works".
<mup> PR snapd#6083 closed: tests/lib: adjust to changed systemctl behaviour on debian-9 <Simple ð> <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6083>
<mup> PR snapd#6084 opened: tests/lib: adjust to changed systemctl behaviour on debian-9 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6084>
<mup> PR snapd#6076 closed: tests: linode execution is not needed anymore <Simple ð> <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6076>
<mup> PR snapd#6075 closed: tests: removing fedora 26 system from spread.yaml <Simple ð> <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6075>
#snappy 2018-11-01
<aisrael> Is snapcraft.yaml meant to be in the root of a project, or at snap/snapcraft.yaml?
<Chipaca> aisrael: either work
<Chipaca> aisrael: IIRC it's looked for in snap/snapcraft.yaml, or snapcraft.yaml, or .snapcraft.yaml
<Chipaca> aisrael: the nice thing about snap/snapcraft.yaml is that then the manifest.yaml also goes there
<Chipaca> it's less surprising
<aisrael> Chipaca: Is there a preference? Main reason I ask is because snapcraft 3 (snap) complains about not finding snap/snapcraft.yaml, but the docs for a python snap explicitly says to put it in the root of the project.
<Chipaca> aisrael: ah, I'm not sure but it's possible support for the other two is being phased out
<Chipaca> sergiusens might be around still, maybe he knows
<aisrael> Chipaca: okay, thanks. I'm happy to edit the docs, but wanted to make sure it was factually correct first.
<mup> PR snapd#6085 opened: tests: move fedora 28 to manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6085>
<mup> PR snapd#6084 closed: tests/lib: adjust to changed systemctl behaviour on debian-9 (2.36) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6084>
 * Chipaca watches the tumbleweeds do their thing
<mup> PR snapd#6060 closed: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6060>
<thresh> hmm, so firefox snap got upgraded and now it wont launch: http://thre.sh/stuff/ff-snap-fails.txt
<thresh> /usr/lib/snapd/snap-discard-ns firefox seemed to help
<thresh> but really?
<Chipaca> every time you need to use snap-discard-ns, it's a bug :)
<sparkieg`> I've been tracking candidate of the firefox snap as a while now, launches perfectly fine here (18.04 LTS)
<thresh> I wish I was as lucky as sparkiegeek :)
<zyga> thresh: it's a known issue fixed in 2.36,
<zyga> thresh: just discard as chipaca said but the next release will not need this hack
<Chipaca> zyga: you're here! i thought you were on holiday today
<thresh> zyga, and here I am already braced for a debugging session!
<thresh> zyga, good to know - thank you!
<zyga> I am on holiday, on our way to the cemetery
<ogra> cjwatson, is there anything wrong with the proxy for the builders ?
<ogra> Pulling xradio-driver
<ogra> Cloning into '/build/linux-generic-allwinner/parts/xradio-driver/src'...
<ogra> [01/Nov/2018:11:14:17 +0000] "CONNECT github.com:443 HTTP/1.1" 407 1773 "-" "git/2.7.4"
<ogra> fatal: unable to access 'https://github.com/fifteenhex/xradio.git/': Received HTTP code 407 from proxy after CONNECT
<ogra> from: https://launchpad.net/~build.snapcraft.io/+snap/0e2b1c47138b20d1431cf32b24b68bb3-xenial/+build/367210
<ogra> (manually cloning here works fine)
<cjwatson> it took just over two hours and does a kernel build first
<cjwatson> so the proxy auth token had almost certainly timed out
<ogra> hmm
<cjwatson> arranging to pull everything before doing the time-consuming build will work better
<ogra> well, i need to build the module after the kernel
<cjwatson> build yes, pull no
<ogra> ah, k
<popey> uhm
<ogra> shawnFUN
<cjwatson> (I don't know quite how to arrange that in snapcraft, but IIRC it's possible)
<ogra> :P
<ogra> yeah, it is "possible" just very fiddly
<Chipaca> ogra: can you make it stop?
<Chipaca> ah maybe it's done already
<Chipaca> k-lined sounds fun
<Chipaca> or maybe not
<Chipaca> hm
<mup> PR snapd#6085 closed: tests: move fedora 28 to manual <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6085>
<Gargoyle> Hey all. Just got an update for atom on the stable branch, but file dialogs still look a mess. Is there any workaround for electron apps as snaps on 18.10 yet?
<popey> Gargoyle: heya, yeah, it's a known problem.
 * Chipaca hugs ogra 
<Chipaca> ogra: be nice
<Chipaca> ogra: just because somebody is in a fighting mood doesn't mean you need to go for them
<Gargoyle> popey: OK. Was just wondering. 99% of the time I'm launching from the cmd line anyway.
<ogra> Chipaca, hmm, i thought i was nice ... or at least factual enough
<ogra> sorry if i didnt come across like that
<Chipaca> ogra: I have higher standards for team members than for members of the public :-)
<mup> PR snapd#6086 opened: overlord/snapshotstate/backend: survive missing directories <Created by chipaca> <https://github.com/snapcore/snapd/pull/6086>
 * cachio afk
<mup> Issue core18#87 opened: brightness level bar does not function smoothly <Created by Nayananga> <https://github.com/snapcore/core18/issue/87>
<mup> Issue core18#87 closed: brightness level bar does not function smoothly <Created by Nayananga> <Closed by Nayananga> <https://github.com/snapcore/core18/issue/87>
#snappy 2018-11-02
<mup> Bug #1801201 opened: Installed snap icons missing if using pixmap <Snappy:New> <https://launchpad.net/bugs/1801201>
<pstolowski> morning
<sil2100> Morning o/
<sil2100> Are zyga or mvo around today?
<pstolowski> hey sil2100!
<pstolowski> sil2100: no, he has a day off
<pstolowski> sil2100: zyga thats is; don't remember about mvo, but probably off as well
<pstolowski> morning Chipaca!
<sil2100> :<
<Chipaca> pstolowski: morning!
<Chipaca> pstolowski: thank you for the review!
<Chipaca> pstolowski: if you still have room for more, #6074 would be nice
<mup> PR #6074: strutil: make VersionCompare faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6074>
<Chipaca> pstolowski: yesterday I was wondering if you'd be taking today off as well
<pstolowski> Chipaca: added a few comments to your "survive missing..." PR; i need 2nd cup of coffee though, so if i suggested something silly, it's because of not enough coffee
<Chipaca> pstolowski: :-)
<Chipaca> pstolowski: I'll think about the  !(err == nil && exists && isDir)  vs  err != nil || !exists || !isDir
<Chipaca> pstolowski: it used to be the second way, fwiw
<Chipaca> i changed it because i thought it was clearer
<Chipaca> so maybe i was wrong =)
<Chipaca> i'll try splitting it out and see what it looks like
<pstolowski> Chipaca: thanks.
<pstolowski> Chipaca: will look at this other PR.
 * zyga is off
<zyga> (just having wifi)
<pstolowski> + pacman -Rnsc --noconfirm xdg-utils
<pstolowski> error: target not found: xdg-utils
<pstolowski> hmm
<pstolowski> Chipaca: +1 for version check optimization, with tiny suggestions
<Chipaca> pstolowski: ok
<Chipaca> pstolowski: ok to do them in a followup?
<pstolowski> Chipaca: sure
<pstolowski> Chipaca: although you'll probably not get second +1 today :}
<Chipaca> pstolowski: didn't it already have one?
<pstolowski> Chipaca: that one has
<pstolowski> Chipaca: but followup won't
<Chipaca> pstolowski: ah, you mean for the followup
<Chipaca> pstolowski: but the followup is happening anyway :)
<pstolowski> ah, ok
<Chipaca> pstolowski: (it's the rewrite of #6065 using the new version compare)
<mup> PR #6065: cmd, strutil: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>
<Chipaca> ah, actually that one already has a +1 :-D
<Chipaca> but, yeah, it's a rewrite so i'd be cheating if i used that
<Chipaca> hmmmmmmmmm
<Chipaca> mm
<Chipaca> m
<Chipaca> pstolowski: https://pastebin.ubuntu.com/p/gb9TR4268y/
<Chipaca> pstolowski: strings.Trim* is unideal
<pstolowski> jeeez
<pstolowski> ok, leave it as is ;)
<pstolowski> Chipaca: uh, i presume your earlier PR fixes the occasional error i see on travis today:
<pstolowski> - Save data of snap "test-snapd-tools" in snapshot set #1 (cannot create archive: tar: common: Cannot stat: No such file or directory (and 1 more))
<pstolowski> and everything below collapses
<Chipaca> pstolowski: yes
<pstolowski> and we won't land it today :(
<Chipaca> pstolowski: I'll push your suggestions in a bit, and then I'll land it once green
<Chipaca> it's tripping up tests too much
<Chipaca> we can always revert if it was Wrong
<Chipaca> pstolowski: btw if instead of TrimLeft I use TrimLeftFunc, it's only 10% slower and doesn't use any more memory
<Chipaca> the problem seems to be TrimLeft, which makes a cutset object
<Chipaca> cuset function object thing
<pstolowski> ack. i expected it would be slightly slower as it supports substring match.. but that's beyond my wildest expectations
<pstolowski> thanks for checking. good to know
<pstolowski> Chipaca: thanks for the changes #6086, i find these conditions much more readable now (but again, it might be personal preference)
<mup> PR #6086: overlord/snapshotstate/backend: survive missing directories <Created by chipaca> <https://github.com/snapcore/snapd/pull/6086>
<Chipaca> pstolowski: yep, i get it
<pstolowski> Chipaca: restartin #6086, travis failed with "null"
<mup> PR #6086: overlord/snapshotstate/backend: survive missing directories <Created by chipaca> <https://github.com/snapcore/snapd/pull/6086>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#98 closed: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#98 opened: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
<mup> PR snapd#6087 opened: tests: core 18 does not support classic confinement <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6087>
<ogra> cjwatson, jut FYI i think your theory about the proxy token timeout and my 2h kernel build was wrong, a 3h build finished fine yeterday (same snapcraft.yaml) https://launchpad.net/~build.snapcraft.io/+snap/0e2b1c47138b20d1431cf32b24b68bb3-xenial/+build/367710
<cjwatson> ogra: It's probably marginal and just happened to reach the relevant pull stage before the two-hour cutoff
<cjwatson> ogra: I've checked and the proxy auth token does indeed time out after two hours, as I remembered
<cjwatson> ogra: In fact, there are enough timestamps in that log that you can see it
<ogra> well, the last part in that snapcraft.yaml is a single external module build, i doubt that takes 1.5h
<cjwatson>  1 Nov 23:27:40 ntpdate[1830]: adjust time server 10.211.37.1 offset -0.010249 sec
<cjwatson> [02/Nov/2018:01:23:03 +0000] "CONNECT github.com:443 HTTP/1.1" 200 161369 "-" "git/2.7.4"
<cjwatson> just under two hours difference
<ogra> hmm, weird
<cjwatson> ogra: the slow bit might be actually packing up the snap maybe?  not sure
<cjwatson> there's not much else at that point that could be slow
<ogra> yeah and that bit has no timetamps
<cjwatson> Indeed, unfortunately
<ackk> hi, does anyone know how to make nginx run inside a snap? if I specify "user root" it tries to initgroups() and fails
<cjwatson> ackk: lp:snapstore-snap (Canonical-private) has some very hacky stuff to make that work
<ackk> cjwatson, are you using nginx from the deb or building your own?
<cjwatson> Basically shoving in https://paste.ubuntu.com/p/GK6GtfDbzh/ to stub it
<cjwatson> ackk: we use stage-packages: nginx-light
<cjwatson> and use that
<ackk> cjwatson, I see
<cjwatson> It's not pretty, but it works.  See https://forum.snapcraft.io/t/seccomp-filtering-for-setgroups/2109/7
<ackk> cjwatson, thanks
<cjwatson> np
<mup> PR snapd#6077 closed: overlord/ifacestate: use map[string]*connState when passing conns around <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6077>
<pstolowski> Chipaca: cachio are we skipping the standup?
<Chipaca> I wouldn't mind, nothing new since yesterday I don't think
<cachio> pstolowski, no idea
<pstolowski> cachio: it's up to us, there is no one else today
<cachio> pstolowski, let's skip it in that case
<cachio> pstolowski, I am working fixing tests now
<Chipaca> pstolowski: I thought degville was also with us today
<degville> Chipaca: pstolowski: yep, I'm here.
<degville> (there)
<pstolowski> Chipaca: ah, you may be right, sorry!
<Chipaca> degville: let's skip it unless you have more news for us than can fit on irc =)
<degville> that's fine :)
<mup> PR snapd#6086 closed: overlord/snapshotstate/backend: survive missing directories <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6086>
<mup> PR snapd#6088 opened: tests: add debug output for degraded test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6088>
<mup> PR snapd#6074 closed: strutil: make VersionCompare faster <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6074>
 * cachio afk
<mup> PR snapd#6088 closed: tests: add debug output for degraded test <Simple ð> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6088>
<diddledan> so, someone who shall remain nameless managed to figure out how to get GTK2 and GTK3 to both work from the same snap
<diddledan> hint, it involves removing GTK_PATH ;-p
 * diddledan pings kenvandine about that one
<diddledan> I'm just off out, but I'll write it up later
<kenvandine> hey diddledan
<diddledan> ello :-)
<diddledan> the customised desktop-gtk part (patch coming in a second message) https://www.irccloud.com/pastebin/d2kIJ3Va/
<diddledan> the patch referenced in the part https://www.irccloud.com/pastebin/nuqbPhB8/
<diddledan> add this environment somewhere that it takes hold - could just as easily be added to the patch https://www.irccloud.com/pastebin/VgcQ5ALO/
<diddledan> obviously the patch is only a patch for my use case where I'm reusing the desktop-helpers as source but to add to the desktop-helpers it can be added directly to the gtk script rather than maintained as a separate patch
<diddledan> anywho, that's all I got, I need to jet now. bbiab
<kenvandine> diddledan: cool
<mup> PR snapd#6087 closed: tests: core 18 does not support classic confinement <Simple ð> <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6087>
<Chipaca> cachio: ^
<cachio> Chipaca, good
<cachio> thanks
<diddledan> is something wrong with build.snapcraft.io? https://usercontent.irccloud-cdn.com/file/3vIFFkBZ/image.png
<popey> refresh? turn of ad blocker?
<diddledan> no ad blocker, though I am using firefox which might be blocking stuff through it's "don't track me" features
<popey> i just logged in and it worked here
<diddledan> aha. it's https everywhere extension
<popey> that stuff is all js locally
<popey> ahhhh
<diddledan> so something is being forced to https that isn't responding...
<diddledan> or not. it's working now even after re-enabling https-everywhere
<diddledan> perhaps a stodgy cache then
<kyrofa> diddledan, do you have privacy badger as well?
<diddledan> no, I haven't got that currently
<mup> PR snapd#6062 closed: tests,store,daemon: ensure proxy settings are honored in auth/userinfo too <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
<mup> PR snapd#6089 opened: tests: install dependencies during prepare <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6089>
<mup> PR snapcraft#2359 closed: [WIP] extensions: add glib <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2359>
<mup> PR snapcraft#2388 opened: project: early snapcraft.yaml validation <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2388>
<kyrofa> Of course, the first time I actually try layouts I need to create new entries in / :P
#snappy 2018-11-03
<mup> PR snapcraft#2389 opened: repo: run `apt update` before `apt install` <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2389>
<ackk> hi, anyone that could help with a rpi3 issue with ubuntu core?
<ackk> is there a tool to modify the uboot.env file?
<zyga> ackk: I'm here but I don't know enough about rpi3 to help
<zyga> ackk: the config system can toggle some options in the boot process
<zyga> ackk: but not sure what you really need
<ackk> zyga, hi, so, I have rpi3 with ubuntu core, at some point it was rebooted and didn't come back. turns out the pi2 kernel snap was updated but the var in the uboot env wasn't, so it was trying to boot from a nonexistent kernel
<ackk> zyga, I fixed that (I wonder if it's a ubuntu bug), but now the initramfs can't mount the root partition for some reason. it's ext4, but it fails after trying ext3 and ext2, saying there's some incompatibility
<ackk> I can mount it fine on my pc
<mup> PR snapd#6089 closed: tests: install dependencies during prepare <Simple ð> <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6089>
<ogra> ackk, from the runninf system you can use fw_printenv and fw_setenv to modify uboot.env
<ogra> *running
<ogra> and indeed you can manage uboot env from the uboot shell from the serial console like on all embedded boards we support
<ackk> ogra yeah I was looking for something to change it from my pc, found about uboot-go from mvo :)
<ogra> i have never seen it fail to set the vars though ... that would definitely be a bug if you didnt tinker with the card (not properly unmounting it or some such when you used it in a PC between boots)
<ackk> ogra, so it turns out the snaps for core and kerner were wrong in the env
<ackk> not sure why they didn't get updated
<ogra> i have pi's here that run the same image since 2 years without ever failing
<ackk> ogra, yeah that's weird
<ogra> the ext2/3/4 warnings are nroaml btw ... the ext4 driver loops over all possible extX versions it can support and pronts that nonsense
<ogra> *prints
<ogra> *normal
<ogra> if you can capture a full serial boot log and dump it to a pastebin i can take a look
<ackk> ogra, is it normal that the core snap is marked as disabled?
<ackk> ogra, (same for the pi2 kernel) https://paste.ubuntu.com/p/F2mrphCvfr/
<ogra> no, something is seriously broken
<ogra> what image was that originally ?
<ogra> core kernel and gadget should never be marked as disabled on UC
<ackk> ogra, the official pi3 image
<ackk> for ubuntu core
<ogra> hmm, strange
<ackk> ogra, so I tried to enable core, it rebooted but didn't come back
<ogra> i still wonder how you got into that situation in the first place
<ackk> ogra, should the pi2-kernel be enaled on a pi3?
<ogra> yes
<ackk> ogra, it's my nextcloud box, it was just there running
<ackk> ogra, I had a power loss, maybe something broke there
<ogra> the name is a bit confusing, it should be pi-kernel
<ogra> a power loss shouldnt cause this ... the system should recover
<ackk> nothing else happened
<ackk> snap_core=core_4916.snap
<ackk> snap_kernel=pi2-kernel_73.snap
<ackk> snap_mode=
<ackk> snap_try_core=core_5331.snap
<ackk> this looks better
<ogra> not really ...
<ackk> why?
<ogra> sndp should have unset snap_try_core after it verified the boot
<ackk> well it hasn't yet
<ogra> *snapd
<ackk> I just reenabled the snap
<ackk> lemme try to reboot
<ogra> echnically you should just have rebooted until the system fixed itself ... without touching anything
<ogra> if you touched any vars they might be out of sync with what snapd expects
<ackk> ogra, I did touch snap_core and snap_kernel as they were set to values that didn't exist and the pi wasn't booting
<ogra> i assume there is something wrong with the watchdog ... the system should have done this on its own (rebooting until it fxed itself)
<ogra> could it be that your SD is/was full ?
<ackk> ogra, no
<ogra> we dont really have protection against that yet
<ackk> ogra, I rebooted, but it's still on the old core
<ackk> and the try is still there
<ogra> thats the only way i can imagine that the vars point to something non-existing
<ogra> try "snap refresh core"
<ackk> ack@nextcloud:~$ df -h | grep mmc
<ackk> /dev/mmcblk0p2  3.6G  964M  2.4G  29% /writable
<ackk> /dev/mmcblk0p1  127M   38M   89M  30% /boot/uboot
<ackk> ogra, ^ fwiw
<ackk> ogra, ok it's downloading a newer core now
<ogra> lets see how that goes
<ackk> rebooting now
<ogra> good
<ackk> well, it's supposed to, it doesn't seem it is
<ogra> whats on the console ?
<ackk> ok finally
<ackk> nothing
<ackk> but it's rebooting now
<ogra> finally ? you mean it booted ?
<ackk> it's booting
<ogra> k
<ackk> ogra, ok, everything seems green now
<ogra> how does the kernel look in snap list ?
<ogra> enable again ?
<ogra> *enabled
<ackk> pi2-kernel  4.4.0-1098.106  73    stable    canonicalâ  kernel
<ackk> yep, everything enabled
<ogra> ok .. thats fine but outddated ...
<ogra> snap refresh pi2-kernel
<ogra> then you should be back up to date
<ogra> (current stable is rev 74)
<ackk> cool, thanks
<mup> Bug #1600136 changed: App indicator does not show icon for Qt apps or with custom icons <isv> <patch> <snap-desktop-issue> <verification-done> <appmenu-qt5 (Ubuntu):Fix Released by 3v1n0> <libappindicator (Ubuntu):Fix Released by 3v1n0> <qtbase-opensource-src (Ubuntu):Fix Released by 3v1n0> <sni-qt
<mup> (Ubuntu):Fix Released by 3v1n0> <appmenu-qt5 (Ubuntu Xenial):Fix Released> <libappindicator (Ubuntu Xenial):Fix Released> <qtbase-opensource-src (Ubuntu Xenial):Confirmed> <sni-qt (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1600136>
#snappy 2018-11-04
<mup> Bug #1801567 opened: /home/* access not available <Snappy:New> <https://launchpad.net/bugs/1801567>
<mup> PR snapd#6090 opened: Granted 'account_control' access to /home/** <Created by stefannilsson> <https://github.com/snapcore/snapd/pull/6090>
<mup> PR snapcraft#2390 opened: repo: document package purpose <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2390>
<mup> PR snapcraft#2391 opened: runtests: run black with --diff <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2391>
<Son_Goku> zyga, niemeyer: I've kept my word: https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310
<Son_Goku> it's now done
<mup> PR snapd#6091 opened: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/6091>
<Son_Goku> sabdfl, hey!
<Son_Goku> sabdfl, this may interest you: https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310
<Son_Goku> at least for basic snaps, things seem to work okay, but I expect there will be followup work to improve the experience going forward, now that we're going to have snapd in EPEL for RHEL/CentOS and derivatives
<Son_Goku> zyga, and minimal PR with improvements for building snapd for EL7: https://github.com/snapcore/snapd/pull/6091
<mup> PR #6091: packaging/fedora: Merge changes from Fedora Dist-Git <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/6091>
#snappy 2019-10-28
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mup> PR snapd#7608 closed: o/snapstate, etc: SnapState.Channel -> TrackingChannel, and a setter <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7608>
<mborzecki> school run, back in 30
<zyga> hey
<zyga> working on regression test for bug from Friday
<mvo> hey zyga !
<mvo> zyga: did you identify the bug ? is it a difficult one?
<mvo> zyga: also thanks for 7662 and friends
<mvo> zyga: I cherry pick this now
<mup> PR snapd#7674 opened: interfaces: de-duplicate emitted update-ns profiles (2.42) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7674>
<mborzecki> re
<zyga> mvo: re, sorry, some morning school interrupts
<zyga> mvo: not sure  yet
<zyga> mvo: give me one hour
<mvo> zyga: sure
<mvo> zyga: thanks for looking into this
<zyga> mvo: not super hard
<zyga> mvo: not kernel or anything like that
 * mvo hugs zyga 
<zyga> mvo: just overlooked and underused feature
<zyga> mvo: workaround is tiny
<zyga> mvo: proper fix requires a little bit more logic
<zyga> mvo: I'll send workaround patches in one hour
<zyga> mvo: should we have a 2.42.1 milestone on launchpad
<mvo> zyga: feel free to add it
<zyga> ok
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#7666 closed: tests: don't depend on GNU time <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7666>
<mup> PR snapd#7668 closed: tests: tweak wording in mount-ns test <Simple ð> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7668>
<mup> PR snapd#7675 opened: osutil: preseed mode helper <Prebaking> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
<mup> PR snapd#7676 opened: many: cherry pick test updates for 2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7676>
<mup> PR snapd#7677 opened: interfaces/content: workaround for renamed target <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
<pedronis> pstolowski: hi, to discuss 7675, can you make a list of the packages that would need to query PreseedMode ?
<pstolowski> pedronis: sure, will do
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7677
<mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
<zyga> mborzecki: it's a priority customer request
<zyga> mvo: the test passed a single run, force pushed with commit typo and running across all machines
<zyga> mborzecki: could you send a patch that disables xdelta for amazon?
<zyga> mborzecki: for the resend in spread
<pstolowski> pedronis: updated (added to the description)
<mborzecki> zyga: the lzo with xdelta thing pops up on amazon?
<zyga> mborzecki: yes, when invoked locally
<zyga> https://www.irccloud.com/pastebin/MKaHiW7M/
<pstolowski> pedronis: if the concern is about having a global flag like this vs passing it around, my suggestion is to have it available though the helper first like proposed (in whatever package we find suits best), then replace it with something final after all the bits are in place
<pedronis> pstolowski: where exactly is it used in apparmor ?
<pedronis> in loadProfiles ?
<pstolowski> pedronis: yes - to have --skip-kernel-load
<mup> PR snapd#7678 opened: spread: disable secondary compression for deltas <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7678>
<mborzecki> zyga: ^^
<zyga> 1-2-1
<zyga> thx
<pedronis> pstolowski: can we have a quick HO in ~15 ?
<pstolowski> pedronis: yes
<pedronis> pstolowski: going to the standup
<pstolowski> pedronis: ok, coming
 * Chipaca can't stand up yet
<Chipaca> mvo: any feedback on #7669 vs #7670?
<mup> PR #7669: snap, cmd/snap: support (but warn) deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7669>
<mup> PR #7670: cmd/snap: support (but warn) using deprecated multi-slash channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7670>
<mup> PR snapd#7635 closed: tests/lib/gendevmodel: helper tool for generating developer model assertions <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7635>
<pedronis> Chipaca: I haven't looked at them yet? what's the difference between, the summary says they are the same
<pedronis> Chipaca: do we have code for daemon yet?
<Chipaca> pedronis: the second one uses channel.Full instead of .Parse, I think it results in simpler code (the explanation is onthe second one, at the end of the description)
<Chipaca> i'll have the daemon up before the standup today
<pedronis> ok, thx
<Chipaca> i think it's the last bit left
<pedronis> Chipaca: plus reintroducing the code about risk switching
<pedronis> that we had to revert
<pedronis> it will probably need a rewrite though
<Chipaca> pedronis: i wouldn't count that as part of this, but, yes that is also missing
<Chipaca> pedronis: and then defaults
<pedronis> yes
<Chipaca> pedronis: some of this work will need tweaking for defaults, fwiw
<pedronis> yes
<Chipaca> as here we always do Full, and on install with defaults we need to not do so
<Chipaca> i was tempted to do that from the start but thought better leave it simple for now
<pedronis> Chipaca: no, the Full is probably fine, the question is more where the value comes from
<Chipaca> anyway, got a meeting coming up, need to set up
<mvo> Chipaca: was in a meeting
<mup> PR snapd#7679 opened: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
<mup> PR snapcraft#2771 opened: python plugin: skip download and wheel for local sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2771>
<zyga> mvo: https://github.com/snapcore/snapd/pull/7677 is ready for review
<mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
<zyga> mborzecki, pstolowski ^ priority customer bug
<zyga> trivial code change + tests + rationale
<pstolowski> zyga: looking
<zyga> thank you guys
<zyga> mvo: https://github.com/snapcore/snapd/pull/7677 is green
<mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
<pedronis> reviews for #7672 and #7679 would great, they are mostly reorg in preparation of actual Core 20 seed loading code
<mup> PR #7672: seed: share auxInfo20 and makeSystemSnap via internal <Created by pedronis> <https://github.com/snapcore/snapd/pull/7672>
<mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
<mvo> Chipaca: 7622 is ready for a review (after you finished the other things of course :)
<Chipaca> mvo: thanks
 * dot-tobias hi everybody
<zyga> mvo: do you want to get a security review for https://github.com/snapcore/snapd/pull/7677
<mup> PR #7677: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7677>
<zyga> otherwise it's green and we could build a new edge core/snapd snap next
<zyga> brb
<mvo> zyga: sounds like we can merge and ask security for a retrospective one
<mvo> zyga: it will just be on edge
<mvo> mborzecki: 7302 has a conflict now
<zyga> mvo: ok, mering
<mup> PR snapd#7677 closed: interfaces/content: workaround for renamed target <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7677>
<zyga> mvo: can you please remind me how to correctly trigger edge build, do I need to just do the snap build request or do I need to ensure the intermediate git is synchronized somehow?
<mvo> zyga: for the snapd it will all happen automaitcally
<mvo> zyga: for old school core its spread-cron that needs to merge a git tree first
<mvo> zyga: https://travis-ci.org/snapcore/spread-cron/branches
<zyga> mvo: so just "sit tight"?
<mvo> zyga: and "snapd-vendor-sync" there
<mvo> zyga: yeah or manually triggering this one
<mup> PR snapd#7680 opened: daemon: parse and reject invalid channels in snap ops <Created by chipaca> <https://github.com/snapcore/snapd/pull/7680>
<zyga> there's another thing called snap https://ai.google/research/pubs/pub48630/
<zyga> at some point everything will just be called foo, I guess
<cmatsuoka> hello everyone
<cmatsuoka> did we have a timezone shift at some point in the past two weeks?
<cmatsuoka> I see all events in my calendar shifted one hour, and my time zone is correct
<pstolowski> cmatsuoka: hey Claudio, welcome back!
<pstolowski> cmatsuoka: yes, we switched from summer time yesterday
<cmatsuoka> ah ok, I just wanted to make sure everything is consistent and I won't miss any meeting
<zyga> mvo: refresh-app-awareness just got more complicated
<zyga> cmatsuoka: hey :)
<zyga> I need to sync with stgraber
<mup> PR snapd#7678 closed: spread: disable secondary compression for deltas <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7678>
<zyga> mvo: I have some ideas on how to fix this
<zyga> mvo: would love to sync
<zyga> mvo: feels like a week or two of work though
<zyga> mvo: but would solve some issues in general without bothering us in the future
<zyga> mvo, mborzecki: I updated the last comment on https://github.com/snapcore/snapd/pull/7547 with some details
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<pedronis> zyga: isn't how we do the tracking vs the other bits of awareness orthogonal anyway?
<zyga> pedronis: some are intersecting, the agent is something we need the cgroup for
<zyga> pedronis: we can re-design without the agent being present
<zyga> pedronis: and continue work on the UX without that
<zyga> pedronis: the cgroup gives us tracking without breaking systemd and a possibility to install the agent
<pedronis> you mean the release the agent?
<zyga> yes
<zyga> I need to stop and think for a moment
<zyga> on how to proceed
<zyga> I need to make more tea anyway
<zyga> perhaps we can work on part of the UX without the agent now and progress towards _a_ solution that would not affect LXD or be affected by LXD
<zyga> and then integrate this so that the UX works only better
<zyga> and the backend changes silently behind the scenes once everything is aligned
 * zyga -> tea
<ijohnson> Wait so now the SU is in 1 hr
<ijohnson> Right?
<cmatsuoka> ijohnson: yes, it seems so
<ijohnson> Hmmm
<cmatsuoka> ijohnson: end of dst in europe
<ijohnson> cmatsuoka: do you follow daylight savings time? The US switches next week so next week it seems to go back to 8 am local for me
<ijohnson> But this week it's at 9 am local
<ijohnson> I saw a few weeks ago on my calendar the time went to 9 AM and was kinda excited at the prospect of having 9 am meetings all winter
<cmatsuoka> ijohnson: for me it was 10AM local time, now it's 11AM
<ijohnson> Yeah it was 8 am on Friday now it's 9 am local for me
 * ijohnson is quite confused that the timezone switch between US and EU don't at least happen at the same time 
<cachio> mvo, is the standup delayed 1 hour?
<cachio> I didn't receive the update
<cachio> it used to be automatic
<cmatsuoka> cachio: the standup should be 11AM in our timezone
<cachio> cwayne, yes
<cachio> cmatsuoka, yes}
<cwayne> :)
<Chipaca> cachio: the time didn't change, but the timezone did :)
<Chipaca> it's all the german farmers fault
<cachio> hhhehe
<cwayne> Chipaca: thats who i blame all my problems on tbh
<cwayne> bad run? german farmers did it.
<pedronis> I commented a bit on some of the channels PRs, 7670 seems good to me, assuming we don't want a special error msg in 7680
<pedronis> Chipaca: ^
<Chipaca> pedronis: ack
<Chipaca> cwayne: i haven't run in the last month because of my knee
<mup> PR snapcraft#2772 opened: remote-build: improve resiliency for https connection issues <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2772>
<Chipaca> cwayne: also the germans' fault
<cwayne> Chipaca: thats rough, mine's been wonky as hell lately too
<cwayne> damn germans
<Chipaca> cwayne: wonky knees, doo doo doo
 * cwayne has baby shark stuck in my head now
<mup> PR snapcraft#2773 opened: build providers: inject snapd snap for latest feature availability <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2773>
<mup> PR snapcraft#2774 opened: remote-build: architecture handling <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2774>
<Chipaca> sergiusens: <3 2773
<sergiusens> Chipaca: your review would be appreciated :-)
<mup> PR snapcraft#2775 opened: remote-build: add clean flag <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2775>
<mup> PR snapcraft#2776 opened: repo: convey proper error message when refreshing to invalid channel <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2776>
 * cachio lunch
 * zyga finished talking to mborzecki and EODs
<zyga> mvo: sorry, the UX doc needs to wait, I'm exhausted by the complexity today
 * mborzecki too
<pedronis> cachio: we are getting (again?) errors like:   systemctl restart systemd-journald.service
<pedronis> Job for systemd-journald.service failed.
<pedronis> See "systemctl status systemd-journald.service" and "journalctl -xe" for details.
<pedronis> cachio: https://api.travis-ci.org/v3/job/603911307/log.txt
<Chipaca> pedronis: if we are, i can try my proposed fix this evening
<Chipaca> pedronis: nearly finished reviewing 7679, but going to go out and do some exercise for a bit, will bbl
 * Chipaca pokes a few other things before going
<mup> PR snapd#7672 closed: seed: share auxInfo20 and makeSystemSnap via internal <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7672>
<cachio> pedronis, I'll take a look
<cachio> degville, hey
<cachio> I just updated the testing blogpost
<cachio> with the feedback
<degville> cachio: hello! want me to take a look?
<cachio> when you have a time could yo uplease take a look
<cachio> a quick one please
<degville> cachio: yes, of course - no problem.
<cachio> degville,thanks!!!!
<mup> PR snapcraft#2773 closed: build providers: inject snapd snap for latest feature availability <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2773>
<mup> PR snapcraft#2774 closed: remote-build: architecture handling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2774>
<degville> cachio: I've just read through your post again - made a few comments on the changes, but really only minor suggestions!
<cachio> degville, thanks a lot, I'll address them
<degville> cachio: np!
<kyrofa> Thanks guys for putting this room together to help us all with host networking (https://ai.google/research/pubs/pub48630/)
<kyrofa> Google likes snap things. https://github.com/google/snappy
<Pharaoh_Atem> libsnappy predates snapd, iirc
<kyrofa> Oh I'm well aware :P
<ijohnson> jdstrand_: hey is there any reason not to include usr/bin/paste in the base policy? that program is in both core and core18 and doesn't seem to pose any obvious security problems to me and it would simplify some shell scripting I'm doing :-)
<jdstrand> ijohnson: hey, no, I'll add it to my list. I plan to do a misc policy updates PR for 2.43 and will add this
<ijohnson> thanks jdstrand
<mup> PR snapcraft#2776 closed: repo: convey proper error message when refreshing to invalid channel <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2776>
<mup> PR snapcraft#2677 closed: erorrs: preserve quotes when printing SnapcraftPluginCommandError <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2677>
<mup> PR snapcraft#2777 opened: cli: pass channels None when not doing a push --release <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2777>
<mup> PR snapd#7622 closed: snap: make `snap known --remote` use snapd if available <Needs Samuele review> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7622>
<Chipaca> whoops
<Chipaca> pedronis: i just noticed yours was not one of the +1's on 7662 :-(
<mup> PR snapd#7681 opened: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
<Chipaca> pedronis: any issues you had with it can be addressed in 7624 though so that's probably ok
<pedronis> Chipaca: I marked myself long ago, mostly because of xerrors
<pedronis> but then there was a prereq one already landed
<Chipaca> pedronis: ah ok :) that's sorted with #7667
<mup> PR #7667: spread: enable bboozzoo/snapd-devel-deps COPR repo for getting golang-x-xerrors <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7667>
<pedronis> Chipaca: my other question is how long it takes to fail?
<pedronis> s/fail/fallback/
<Chipaca> pedronis: next to nothing
<Chipaca> pedronis: there's no retrying, is what i mean
<pedronis> ok
<Chipaca> when it's 'the socket isn't there' at least :)
<pedronis> ah
<Chipaca> i guess you could have a hung snapd that makes things slower
<pedronis> anyway that's the main case
<pedronis> the next one doesn't seem to pay attention to auth though?
<Chipaca> 7624?
<pedronis> yes
<Chipaca> I'm waiting for the master merge before looking at that one
 * Chipaca lazy
<pedronis> ok
<Chipaca> pedronis: but auth is a quick fail so should be handled ok
<pedronis> anyway I marked it as I need to look at it
<Chipaca> i'll be looking out for it in any case
<pedronis> yea, my point is I don't think the code is looking for it
<pedronis> atm
<Chipaca> hmmm
<Chipaca> i think i reviewed something along those lines in this context
<Chipaca> a previous pr about download
<Chipaca> i'll have a dig
<Chipaca> pedronis: i'll take the dog for a walk before the temperature drops more, then i'll have a look
<Chipaca> i think it might already be handled but not sure, don't remember exactly
<Chipaca> anyway, ttfn
<pedronis> same here
<pedronis> ttfn
<mup> PR snapcraft#2772 closed: remote-build: improve resiliency for https connection issues <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2772>
<mup> PR snapcraft#2777 closed: cli: pass channels None when not doing a push --release <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2777>
<mup> PR snapcraft#2768 closed: remote-build: autorecovery <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2768>
#snappy 2019-10-29
<mup> PR snapcraft#2778 opened: Release changelog for 3.9 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<zyga> good morning
<zyga> bug triage duty!
<mborzecki> zyga: hey
<zyga> hey :)
<zyga> I'm working away from office today
<zyga> I'll begin the day with some reviews
<zyga> then go to UX docs
<mup> PR snapd#7682 opened: [RFC] add kernel remodel undo tests and fix undo <Created by mvo5> <https://github.com/snapcore/snapd/pull/7682>
<zyga> mvo: small -1 comment on the 2.42.1 cherry pick PR
<zyga> mvo: 2.42 PR failed on mount ns test
<zyga> mvo: the failure indicates it is a missing lxd cleanup
<zyga> mvo: I think mborzecki sent a patch to master to fix that
<zyga> mvo: you may want to cherry pick that as well
<zyga> mvo: for context, this is how such failure looks like:
<zyga> https://www.irccloud.com/pastebin/Zxxde5Sh/
<mborzecki> zyga: mvo: this one? https://github.com/snapcore/snapd/commit/03f3210eadeb47ee3c286e2c4fb242ce67365c86#diff-413b2f27493a11371053198f7020e23f
<zyga> I think so
<zyga> abeato: gentle ping about https://github.com/snapcore/snapd/pull/7603
<mup> PR #7603: interfaces: add dpdk and hugepages interfaces <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7603>
<pstolowski> morning
<zyga> hey pawel
<mborzecki> pstolowski: hey
<mvo> zyga, mborzecki thank you, I have a look
<pedronis> mvo: hi, is #7624 ready for review?
<mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
<mvo> pedronis: yes
<mvo> store seems to give 503 right now, we have lots of red
<mup> PR snapd#7663 closed: tests: add 14.04 canonical-livepatch test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7663>
<pedronis> mvo: I made some initial comments in 7682
<mvo> pedronis: yeah, excellent
<mvo> pedronis: I was wondering if deviceCtx is the way and you suggested it for oldModel so I will add it. thank you!
<mvo> pedronis: will make the diff a bit bigger (with test updates) so I may do it as a separate PR (?)
<mvo> pedronis: and *thank you* for the  feedback!
<pedronis> mvo: np
<pedronis> did a quick on 7624 too
<mvo> pedronis: thank you!
<mup> PR snapd#7683 opened: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
 * dot-tobias good morning
<mvo> ackk: did you had a chance to test the performance of snaps inside lxd recently? we fixed some performance issues and iirc the maas team mentioned they were hit by the slow performance inside lxd
<ackk> mvo, hi, I haven't tried it recently. our issue was with squashfuse being super-slow, and particularly visible with the maas snap since it's quite big
<ackk> and a lot of small (python) files that get read at startup
<mvo> ackk: yeah, that should be fixed in current core
<ackk> mvo, nice, I'll give it a try, let you know how it goes
<mvo> ackk: thank you!
<ackk> mvo, thank you for the update
<Chipaca> hmmmmmmm
<Chipaca> morning folks
<Chipaca> mvo: tried reviewing the download one but all i'm seeing is bad news so i'm going to finish my coffee and look back later, maybe i'm just grumpy
<ackk> mvo, I'm getting "Run configure hook of "maas" snap if present (run hook "configure": cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied)" when installing the maas snap, could it be something in the configure hook or is it snapd itself?
<dot-tobias> mvo: Is there a rough date for the next stable core release? Just to get a sense if it'll be this week, next or later.
<Chipaca> ackk: https://forum.snapcraft.io/t/cannot-perform-readlinkat-on-the-mount-namespace-file-descriptor-of-the-init-process-permission-denied/6743/7
<mvo> Chipaca: oh no! I'm ready for bad news, I will steady myself
<ackk> Chipaca, thanks
<ackk> Chipaca, so I need the snapd snap, right?
<Chipaca> ackk: â¦ no?
<Chipaca> ackk: sorry i'm not sure i'm being helpful at all here
<Chipaca> ackk: are you running this on 14.04?
<ackk> Chipaca, no, bionic
<Chipaca> ackk: then it's not that, probably
<ackk> Chipaca, spinned a fresh bionic container, tried snap install --edge maas
<Chipaca> ackk: what's in 'snap version'?
 * Chipaca should add a --irc flag to snap version
<ackk> Chipaca, one sec, I'm testing with an up-to-date bionic now since I didn't update snapd (from the deb) there
<Chipaca> ackk: in which case installing core or snapd would've also fixed it via snapd updating itself
<ackk> Chipaca, fwiw https://paste.ubuntu.com/p/2rCzjTtrMM/
<ackk> I'm trying to install the maas snap but the store is flaky
<ackk> yeah it's not working
<mvo> ackk: that error rings a bell, we saw this before, probably zyga knows more
<Chipaca> ackk: "yeah it's not working" same error, or now store issues?
<Chipaca> ackk: the store is having some issues now yes
<ackk> Chipaca, store errors, sorry
<ackk> yeah I can't test right now
<ackk> mvo, btw is "core" still required for installing core18 snaps?
<ackk> mvo, installing maas didn't install it
<mvo> dot-tobias: iirc we did cherry pick your fix, right? the plan is to release 2.42.1 to beta this week and stable next week (if testing is all good). worst case stable in the week after that. but there is one pending branch that needs reviews :/
<mvo> ackk: core should not be required anymore
<mvo> ackk: on fresh systems snapd will now install core18 and snapd
<mvo> ackk: if you request a core18 only snap
<mup> PR snapd#7676 closed: many: cherry pick test updates for 2.42 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7676>
<dot-tobias> mvo: Yes, it's been merged to master (though all credit to zyga). Thanks for the timeframe, I can work with that ð
<mvo> dot-tobias: was it cherry-picked into release/2.42?
<mvo> dot-tobias: it will only be in 2.42.1 if it was cherry-picked, if not please point me to the PR
<dot-tobias> mvo: Checking
<mvo> dot-tobias: then I can (probably) cherry-pick it, I remember it was a pretty straightforward fix
<dot-tobias> mvo: Actually, it doesn't seem to be cherry-picked into release/4.42 yet. https://github.com/snapcore/snapd/pull/7655 is zyga's PR
<mup> PR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7655>
<mvo> dot-tobias: ok - now it is :) thanks for checking
<dot-tobias> mvo: ðð
<mup> PR snapd#7684 opened: tests: disable mount-ns test in release/2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7684>
<pedronis> pstolowski: what's the status of #7601 ?
<mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
<pstolowski> pedronis: i've the tab open and going to address Jamie's comment, will do today
<pedronis> ok, thx
<pedronis> mvo: did you make a card or something about unifying the default-provider extracting code?
<mvo> pedronis: uh, not yet, let me do this now
<pedronis> thx
<Chipaca> mvo: what's that about a pending branch that needs reviews?
<Chipaca> mvo: i see one pr each in both 2.42 and 2.43 milestones, but it looks like the 2.42 one needs input from foundations and the 2.43 has all the reviewage it can handle ;-p
<mvo> Chipaca: the most important one is the foundations input
<Chipaca> yeh
<Chipaca> xnox is allegedly off gallivanting though :-p
<mvo> Chipaca: yeah, I can try to get a re-review from vorlon for #7661
<mup> PR #7661: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/7661>
 * Chipaca throws flowers at vorlon 
<mvo> Chipaca: should we have a HO about 7624 ? do you think there is something fundamentally wrong with it?
<Chipaca> mvo: just started going through it again
<Chipaca> mvo: download-via-snapd needs to grow a 'resume' thing, but that's a separate pr
<mup> PR snapd#7685 opened: snapstate,devicestate: make OldModel() available in DeviceContext <Created by mvo5> <https://github.com/snapcore/snapd/pull/7685>
<mvo> Chipaca: oh, yeah, thats a good point
<ackk> mvo, I still see snapfuse at 100%cpu but perhaps that's expected?
<pedronis> mborzecki: I did a first pass on 7665
<mborzecki> pedronis: thanks
<pedronis> mborzecki: some questions/wonderings there
<ackk> mvo, yeah, it seems it's still quite slow in the case of maas
<mvo> ackk: hm, ok. it should be quicker than before, can you see what version of snapd is running inside your lxd?
<pedronis> Chipaca: hi, could you answer the question about hidden commands vs autocomplete toward the end of comments in #7589 ?
<mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<ackk> mvo, https://paste.ubuntu.com/p/2rCzjTtrMM/
<Chipaca> pedronis: probaboy
<Chipaca> probably?
<Chipaca> mvo: review done. Less bad news than this morning early.
<Chipaca> mvo: still a little bad
<Chipaca> siigh
<Chipaca> today's already been a long day
<Chipaca> i think i need more coffee
<Chipaca> starting to chase shadows
<mup> PR snapd#7686 opened: systemd: handle preseed mode <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7686>
<pstolowski> uhm... 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"
<mborzecki> pstolowski: yeah
<mborzecki> in the morning i got some 503s as well
<mvo> Chipaca: sorry for the delay, I was in a meeting - you say this gives me no progress bar for snpa donwload but iirc we don't have one today either. or am I missing something?
<mvo> Chipaca: hm, the code says there is a download progress, I'm just not seeing it, probably an issue on my side, I have a look. nevermind
<pedronis> mvo: Chipaca: I meade a suggestion there
<pedronis> *made
<pedronis> not sure it fits or not, it was a quick thought
<pedronis> Chipaca: thanks for the answer, I enquired some more :)
 * zyga is at a service center and may miss standup
<zyga> I'll make up the time in the evening to do all my responsibilities
<zyga> sorry :/
<Chipaca> mvo: i mean, try it: 'snap download core' gives you a nice progress bar
<Chipaca> pedronis: did you enquire, or did you inquire?
<mvo> Chipaca: yeah, I did something wrong, thanks for noticing this
<pedronis> Chipaca: afaict I meant enquire
<Chipaca> pedronis: phew
<pedronis> pstolowski: reviewed #7683
<mup> PR #7683: overlord/ifacestate: remove automatic connections if plug/slot missing <Created by stolowski> <https://github.com/snapcore/snapd/pull/7683>
<pedronis> pstolowski: thank you
<pedronis> pstolowski: I also made a general comment in 7686
<pstolowski> pedronis: ty
<sergiusens> mvo, jdstrand, zyga: any assistance with https://paste.ubuntu.com/p/KXHFrbYmvZ/ ? This is on an autopkgtest env for 18.04/amd64
<sergiusens> journal show Oct 29 05:37:28 autopkgtest snapd[1828]: handlers.go:460: Reported install problem for "gtk3-hello" as 2f8217c0-fa0e-11e9-b619-fa163e102db1 OOPSID
<mvo> sergiusens: are these instances resource constrained? it looks like a malloc() (well, "new") wasn't successful, maybe(?) it requested too much memory
 * mvo needs to urgently get lunch though before he can look deeper
<sergiusens> mvo: get lunch, I am not so worried about the failure itself (as I know our test works on google/spread)
<pstolowski> pedronis: i've updated #7601, would you like to take a look at this as well or can it land when green?
<mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
<pedronis> pstolowski: no, it's probably fine if zygmunt and jamie are ok with it
<pstolowski> ack
<pedronis> pstolowski: I mean, I can look if you think I should
<pstolowski> pedronis: maybe just check the comment & response re locking there. i don't think there was a deep reason it was done the way it was
<pedronis> ok
<pedronis> pstolowski: I put it in my queue, I will also merge it if everything is fine
<pstolowski> pedronis: thanks
<Chipaca> pedronis: should I do the 'hidden-but-completed' thing?
<pedronis> Chipaca: if you can, and is not too distracting, yes
<Chipaca> it's not, right now
<Eighth_Doctor> popey_, zyga, mborzecki, mvo: I've finally introduced `snapd` for EL8
<Eighth_Doctor> that was a more annoying bringup than I thought it would be
<mborzecki> but it's done now :P
<Eighth_Doctor> yeah, I'll do a PR to snapd upstream with a spec sync soon
<Eighth_Doctor> I haven't done one of those in a while
<zyga> Eighth_Doctor: thank you for persisting, congratulations!
<Eighth_Doctor> between broken architectures and missing packages due to incomplete imports, I wasn't certain EL8 was ever going to get built
<mborzecki> Eighth_Doctor: if you take away these problems, there's no more excitement in getting things done
<Eighth_Doctor> I guess so
<Eighth_Doctor> but I didn't enjoy people bitching about updated snapd releases being held up
<jdstrand> sergiusens (cc mvo, zyga): that is the memory consumption bug
<jdstrand> sergiusens (cc, mvo, zyga): can you try edge?
<Chipaca> mvo: silly question: i just noticed the completion helper for 'snap' in 1604 is ancient, is the update on its way / stuck somewhere?
<jdstrand> sergiusens: zyga did excellent PR work to fix that which is committed, and may even end up in 2.42.2 (not sure of the status of that)
<jdstrand> or is it 2.42.1 (did I say I'm not sure of the status of 2.42.N? :)
<mvo> Eighth_Doctor: e8> nice! thanks so much!
<mvo> jdstrand: 2.42.1 once we get it out, pending one review from xnox or vorlon (7661)
<mvo> Chipaca: could you tell me some more details? is the completion helper part of bash-completion there?
<Chipaca> mvo: I mean data/completion/snap that gets shipped to /usr/share/bash-completion/completions/snap
<jdstrand> mvo: cool, thanks :)
<Chipaca> mvo: this is not about completion of snapped commands
<jdstrand> mvo: I wouldn't mind 2.42.1 with that change myself :)
<Chipaca> mvo: but of the snap command itself
<Chipaca> mvo: an easy way to check: snap debug <tab>, vs snap debug model <tab>
 * zyga blushes :-)
<mvo> jdstrand: I cherry picked it already :)
<Chipaca> mvo: with the one in-tree, that second one should not offer all debug commands all over again
<mvo> Chipaca: what do we need to do to update it? (sorry, I still don't have the full picture but hopefully I'm getting there :)
<Chipaca> mvo: I don't know :) the one in-tree was fixed in August
<Chipaca> mvo: how does the .deb pick that up? maybe the .deb is older than august?
<Chipaca> or the release
<Chipaca> i guess august on master means september release so it's not unpossible for this to be alright just lagged
<mvo> Chipaca: aha, got it now - yes, I think we want 2.42.1
<mvo> Chipaca: we have no deb update in a while because of various issues
<Chipaca> ah
<Chipaca> a'ight then
<mvo> Chipaca: one of which is this postinst PR review :)
<Chipaca> mvo: are we going to be able to update before 16.04.<whatever>?
<Chipaca> mvo: because images don't ship packages from -updates so snapcraft hates us
<Chipaca> because there's all these neat features they can't depend on or sth
<Chipaca> anyway, snowballing moaning doesn't hep
<Chipaca> help*
<Chipaca> i need to get ready for standup
<mvo> Chipaca: woah, let me look
<mvo> Chipaca: me too - I fixed the issues in download but I guess this could need a refactor to unify a bit of this code
<mup> PR snapd#7687 opened: snap-bootstrap: check gadget versus disk partitions <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7687>
<jdstrand> mvo: re cherrypic, yep, thanks! looking forward to 2.42.1 in a channel somewhere :) (not pushing, just enthusiastic :)
<mvo> jdstrand: :)
<jdstrand> mvo: also, I heartily endorse the approach for snap-confine in 7661
<jdstrand> mvo: that'll be real nice to finally have fixed :)
<mvo> jdstrand: \o/
<sergiusens> jdstrand: cannot easily try edge on autopkgtests, will try later though, thanks
<Chipaca> cachio: BTW there are 63520800 ways of getting 3 tests out of 400 so the fact that you found a failing combination is quite something
<jdstrand> sergiusens: with the fact that it is a gtk3-hello demo which I bet is using the content interface, I'm inclined to say, don't worry about it for now since it will be fixed soon. if it is happening after 2.42.1 is in stable, report back (cc mvo)
 * mvo had the same thoughts
<cachio> Chipaca, there are pretty good search techniques :)
<jdstrand> pstolowski: hey, fyi, this is what I meant to say before: https://github.com/snapcore/snapd/pull/7601#discussion_r340101086
<mup> PR #7601: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7601>
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15, classic-snap#31, classic-snap#32, classic-snap#33
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<pstolowski> jdstrand: ok, i see, right. i was thinking if the unlocking/locking there was deliberate or not. semantically it looks irrelevant to me and if it had any sideffects it would be a bit fishy tbh. either way it's impossible to test / prove. maybe pedronis can recall something
<pedronis> pstolowski: I'm having a break and then I will look at that PR
<pstolowski> ty
<om26er> private jobs have taken over https://launchpad.net/builders ...
<cachio> mborzecki, hey, could yo utake a look to #7681
<mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
<cachio> please
<mup> PR snapd#7688 opened: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7688>
<cachio> It is confirmed the start-limit-hit issue on core-18
<Chipaca> om26er: private jobs do that
<jdstrand> pstolowski: ack, not a blocker or anything. thanks for thinking about it
<pstolowski> jdstrand: sure, thanks for the review!
<pstolowski> mvo, pedronis: ah, i forgot about the fix for the issue of services & install hook that we want to fix for pre-seeding, and it needs ijohnson's #7341
<mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7341>
<pstolowski> i mean #7431
<mup> PR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>
<ijohnson> pstolowski: I should update that PR with your suggestions later today, I implemented them just need to finish testing that the spread tests still work with my changes
<pstolowski> ijohnson: that's great, thanks
<Chipaca> mvo: you mind if i push some code to #7624?
<mup> PR #7624: snap: make `snap download` download via snapd if available <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
<Chipaca> not saying i will, but i might
<ijohnson> hmm it's rather confusing for github's PR diff files view that for a line changed, the "unexpanded" snippet which shows the function/unindented block of code the line is in doesn't account for the fact that the "unexpanded" part itself also changed
<cachio> zyga, could yo uplease re-review #7681
<mup> PR #7681: tests: add info that could be used to determine why journalctl is failing to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7681>
<cachio> I added a fix there
<cachio> thansk
<pedronis> pstolowski: mmh, are we losing the timing in 7601 ?
 * cachio lunch
<pstolowski> pedronis: we're passing it to SetupMany, it's measured there
<pedronis> ah
<pstolowski> indentation is a bit weird
<pedronis> pstolowski: sorry, yes, I missed it
<pedronis> pstolowski: I commented a bit more on the lock thing
<pedronis> pstolowski: and gave my +1
<pedronis> pstolowski: it can land when it is green
<pedronis> Chipaca: I commented on 7688
<Chipaca> pedronis: i saw
<Chipaca> pedronis: we can always think more :)
<pedronis> Chipaca: I can see a couple of ways out
<zyga> cachio: doing so now
<pstolowski> pedronis: thank you, yes, exactly what i was thinking
<zyga> cachio: interesting
<zyga> cachio: does this mean we can make journalctl fail if we just restart the service in a loop?
<pedronis> Chipaca: we could add code to stick (hidden) at the end of any description of hidden command that don't have it on their own. And have a flag to stop that
<zyga> cachio: if we could do that without any snapd stuff in the way, we could report a bug upstream
<zyga> cachio: it feels like explicit requests should not be counted towards the number of after which the service is not started
<Chipaca> pedronis: a contra to that is that we'd have to reflect the structs ourselves
<pedronis> Chipaca: ?
<Chipaca> to get the other flag
<Chipaca> unless you meant a flag to addCommand
<Chipaca> not a struct tag
<Chipaca> (my first read was that you meant a struct tag, like hidden:"true" completed:"true"
<pedronis> Chipaca: we have our own flags on cmdInfo
<Chipaca> right
<zyga> kenvandine: hey, personal question
<zyga> kenvandine: where can I report a bug on gnome-shell where someone I can talk to will look
<kenvandine> zyga: 7
<kenvandine> :)
<pedronis> Chipaca: can we key on Item somehow? can it be partial, how does that bit work?
<zyga> kenvandine: I have this pet bug of mine that is very frustrating
<zyga> kenvandine: and probably something silly somewhere
<kenvandine> ping Trevinho :)
<zyga> kenvandine: high-dpi in vmware results in white background
<zyga> low-dpi is ok,
<zyga> background shows
<Trevinho> pong
<zyga> kenvandine: all you need to do is to toggle 200% zoom
<zyga> and you get white background
<pedronis> Chipaca: I mean, we could also keep global maps Item -> flags, or Description -> flags (assuming they are unique enough)
<kenvandine> that's annoying
<zyga> this bug was around for about a year now
<zyga> but I never reported it, hoping someone would notice and it wouldn't be just my machine
<zyga> but now I just want to report it
<zyga> because maybe my machine has something useful on it
<zyga> it happens in vmware fusion on both my macbook and my imac
<zyga> it happens in not just ubuntu
<Trevinho> mhmh, ah so the problem is the guest
<zyga> all gnome shell is affected
<zyga> (opensuse, fedora, debian and ubuntu for sure)
<zyga> perhaps it's some texture size limit
<zyga> or something of this nature
<zyga> but
<zyga> it's a new thing
<zyga> it did work great about a year ago, using same older VMs works good now
<Trevinho> zyga: always in x11 or wayland?
<zyga> let me check
<zyga> x11
<zyga> but double checking now
<Chipaca> pedronis: go-flags figures out what things to complete, and we then get the list of whole names even if it's completing a partial
<Trevinho> zyga: and also using new vmware + old ubuntu?
<zyga> yes
<zyga> Trevinho: it's just new gnome/kernel perhaps that causes this
<zyga> one sec
<zyga> Trevinho: it happens in x11, let me log out into wayland
<pedronis> Chipaca: ok, so it sound we could make a map in addCommand as well, instead of looking at the description
<zyga> it's also 100% reproducible on my machines using latest version of everything, I can toggle back and forth
<pedronis> though in principle I have nothing agaisnt sticking (hidden) there,  it's true
<zyga> Trevinho: it affects x11 and wayland equally
<zyga> everything works great at 100% zoom in 5K
<zyga> in 200% zoom everything but background displays fine
<zyga> looking at logs now
<om26er> Is https://snapcraft.io/blog/handy-snapcraft-features-remote-build in the stable channel now ? Also can we use that to build private projects and how is the code actually pushed to launchpad builders ?
<Chipaca> pedronis: yes, we could. Assuming you mean a map of just things to skip, and there weren't synonyms where we wanted to skip only one of them, then it'd probably work
<pedronis> Chipaca: yes, just the one to skip
<om26er> IOW is it secure ?
<Chipaca> pedronis: note we only get the last command
<pedronis> ?
<zyga> Trevinho: in wayland, toggling 200% zoom gives me
<Chipaca> om26er: it is secure but as it says there your build is public
<Chipaca> pedronis: 'snap debug foo' â you get "foo"
<zyga> Trevinho: wayland journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/beonJbDn/
<pedronis> Chipaca: I see, so we cannot use item
<pedronis> but we can use description
<pedronis> assuming they are unique
<pedronis> and they should be really
<pedronis> except for a few degenerate cases that we can accept
<pedronis> like "Internal (hidden)"
<zyga> Trevinho: x11 journal fragment after setting 200% zoom https://www.irccloud.com/pastebin/6Wm8NA5u/
<zyga> Trevinho: I can report that, just point me the way
<pedronis> Chipaca: shortHelp is description ?
<zyga> thank you for looking and I'd love to know if you have any ideas
<pedronis> for commands
<Chipaca> pedronis: yes
<Trevinho> zyga: don't think journal is saying anything wrong, unless edid, but shouldn't matter for this
<zyga> yeah, apart from the background there are no problems
<Trevinho> zyga: better if you report it at https://gitlab.gnome.org/GNOME/mutter/issues
<zyga> Trevinho: nothing fails, 3D works, all the apps work flawlessly
<zyga> Trevinho: sure thing
<om26er> @chipaca that's not a problem, we want to release the software for everyone but the source code model is closed for now
<Chipaca> om26er: but if the build is public, the source is public
<Chipaca> om26er: as i read it at least
<Trevinho> zyga: also when setting 200 the WM is using native 2x or zooming?
<Chipaca> om26er: maybe confirm with somebody that knows :)
<Trevinho>  xprop -root RESOURCE_MANAGER
<zyga> Trevinho: I don't know the difference
<Trevinho> and maybe you can -spy that whiele changing the value
<zyga> let me get that output for you :)
<zyga> sure
<Trevinho> (just use -spy :))
<Trevinho> zyga: well, it's not stretched I imagine, right?
<Trevinho> it's just asking the WM to use proper scaling I assuem
<zyga> Trevinho: no, it's all nice and pretty all the time
<Trevinho> assume*
<pstolowski> pedronis: was your suggestion to also avoid 'preseed' term in the apparmor/security backend?
<om26er> Chipaca not sure who works on the build service these days, is Colin (cj watson) the right person ?
<pedronis> pstolowski: no, there is fine I think
<pedronis> I mean it's ok if you want to use a different term
<pedronis> like DiskOnly or something
<pedronis> but preseed would work too
<pstolowski> pedronis: ok, cause emulation indeed wouldn't fit
<zyga> Trevinho: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
<zyga> Trevinho: not sure how to use -spy
<Trevinho> just pass -spy, it will print you something if it changes
<Trevinho> zyga: that's at 200%?
<zyga> Trevinho: yes
<zyga> Trevinho: let me give you output at both
<zyga> I'm in x11 now
<zyga> though that matters for xprop
<Trevinho> weird, so... mh not really using internal scaling...mhmh
<zyga> https://www.irccloud.com/pastebin/oWGjJE9b/
<Trevinho> a scaled system should have Xft.dpi = scale*96
<zyga> this ix xprop -root -spy
<zyga> *this is xprop -root spy
<zyga> when going from low to high dpi
<zyga> Trevinho: let me double check if I got those initial output bits right
<Trevinho> ah, ok it changes to 192, it makes sense then
<Trevinho> I saw already, yeah... it's just showing things at 2%
<zyga> Trevinho: so at 200% it is: RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t192\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t48\nXcursor.theme:\tYaru\n"
<Trevinho> so, weird. Cause there's should no difference between that and normal 2x scaling (normal = native)
<zyga> Trevinho: and at 100% it is
<zyga> RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.dpi:\t96\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.rgba:\trgb\nXcursor.size:\t24\nXcursor.theme:\tYaru\n"
<Trevinho> yeah makes sense
<pedronis> Chipaca: I played a bit and indeed our description are basically unique, so that idea would work
<zyga> Trevinho: anything else I can try?
<Chipaca> pedronis: is it worth it?
<Trevinho> zyga: mh, no in the top of my head, should probably do some deeper debugging.
<zyga> ok
<zyga> let me report the issue
<pedronis> Chipaca: less magic, so yes
<zyga> what to include in the report?
<pedronis> Chipaca: it's fairly simple I think
<Trevinho> zyga: I use vmware player here, and I don't think that has the option visible
<pedronis> Chipaca: anyway probably simple enough that I should pick up your PR and try to fit it in there
<Trevinho> but I assume I can have the same by changing manually the conf fike
<Trevinho> file*
<cmatsuoka> zyga: patriciadomin needs more space for snap data, would it work if she just moves /var/snap to a different filesystem?
<zyga> Trevinho: I think it's a fusion thing, on a high-dpi display you get to choose to give the VM the full resolution or to give it a scaled down version (e.g. for older OSes)
<zyga> cmatsuoka: yes, it should work perfectly
<pedronis> Chipaca: but maybe your point is that you think that by default hidden commands should auto complete?
<cmatsuoka> zyga: thanks!
<Trevinho> zyga: if you instead change the option internally from the VM only?
<ijohnson> pedronis: reviewed #7679
<mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
<Trevinho> i.e from g-c-c, as that's what I'm doing here all the times, but never had such issue
<zyga> Trevinho: this is internally in the VM
<zyga> Trevinho: I didn't change the vmware fusion settings
<zyga> Trevinho: (having that high-dpi screen really makes me want to use the high-dpi for daily work)
<Trevinho> ah, but well fusion I suppose is doing something different the
<zyga> Trevinho: so to be clear, the VM on the host has a setting toggled to enable "retina" resolution (native resolution of the panel)
<zyga> Trevinho: if you toggle that down the VM gets told that resolution is half in each dimension
<Trevinho> although I've not used this in a very high dpi screen, but simulating it shoudl be the same
<zyga> Trevinho: and there's no 200% zoom to choose from
<Chipaca> pedronis: no, i'm not sure what my point is, but that is not it :)
<pedronis> Chipaca: ok, I'll try to push a PR based on yours and then we can discuss something concrete
<Chipaca> pedronis: ok
<Trevinho> zyga: ah, I see then. But well in the normal case it should just give the same display size so...
<zyga> yeah
<pedronis> Chipaca: in a bit
<Trevinho> basically the same of the player
<Trevinho> zyga: by luck changing the bg image rebuilds anything and makes it appear or no?
<zyga> Trevinho: let me check
<zyga> but I think not
<Trevinho> in theory should not be the same of what happens on resolution changes, but.. sometimes.. :)
<zyga> Trevinho: nope, no luck
<Trevinho> zyga: this seems close https://gitlab.gnome.org/GNOME/gnome-shell/issues/1175
<zyga> yeah!
<Trevinho> could be texture size problem indeed
<zyga> Trevinho: https://gitlab.gnome.org/GNOME/mutter/issues/894
<Trevinho> I suppose in some cases it should be tiled
<zyga> Trevinho: I'll grab lunch (starving) and be back soon
<zyga> Trevinho: oh actually, I think I could set a background *color* correctly
<zyga> now this option seems gone
 * Chipaca â tea
<Trevinho> zyga: I've marked as duplicate, feel free to copy&paste that text to the original bug so we don't loose the comment :)
<Trevinho> sorry, I linked it too late
<Trevinho> looks like something introduced during the 3.32 cycle though, so if running a machine with 3.30 is working, maybe would be nice to bisect 3.32 branches
<om26er> I have python3.8 in a snap and a snapcraft plugin allowing other snaps to use python3.8 https://forum.snapcraft.io/t/introducing-python3-8-as-a-snap/13923
<pedronis> ijohnson: thansk for the reviews, I tried to answer all the questions
<ijohnson> pedronis: cool looking now
<ijohnson> pedronis: thanks for the explanations, lgtm still
<pedronis> thank you
<cachio> zyga, hey, so, we can make it fail in a loop but just on ubuntu core
<cachio> it is not reproduced on classic
<vorlon> mvo, Chipaca: sorry, my slowness in reviewing that PR (aside from being sick yesterday) is that the PR is of course only showing me the delta vs the latest commit, and what I actually care about is the delta vs the current version of the packaging in bionic.  I'll get to it today
<mvo> vorlon: thank you, sorry for being so pushy about it
<Chipaca> mvo: do you know the tag of most-recently-in-bionic ?
<Chipaca> git tag i mean
<mvo> Chipaca: one sec, looking
<mvo> Chipaca: commit adee89d789e452c9d12a90625865954cae448d42 (tag: 2.40)
<zyga> Trevinho: thank you
<zyga> cachio: interesting, wonder why there
<zyga> cachio: and if you copy the config to a regular system, can we make it fail there?
<cachio> zyga, didn0't try that
<cachio> let me try
<zyga> cachio: perhaps it's something specific to the config we use on core
<zyga> cachio: cool, good luck
<Chipaca> mvo: 2.40, or release/2.40?
<mvo> Chipaca: tag is "2.40"
<Chipaca> gah, github does not help with this
<Chipaca> vorlon: sorry :) best i can do is say git diff 2.40 mvo5/snap-confine-conffile -- packaging/ubuntu-16.04
<Chipaca> but that's not particularly useful :)
<mup> PR snapd#7689 opened: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
<Chipaca> it's http://paste.ubuntu.com/p/ZZ4nK4Byq9/ fwiw
<cachio> zyga, well I found that it also fails on classic
<zyga> cachio: that's good, closer to reproducer for a bug report
<cachio> zyga, https://paste.ubuntu.com/p/jqdCqX7sTn/
<mvo> Chipaca: nice!
<zyga> cachio: why "not systemctl restart"?
<mvo> Chipaca: I pushed 7689 that probably should land before we land 7624 (tweaks the api a little bit for things we need)
<cachio> zyga, we restart until it fails
<zyga> ah, I see
<cachio> what we see is that when the tests run fast
<cachio> the service fails to be restarted
<cachio> and it is because we are reaching the start limit
<zyga> cachio: would be worth to report a bug on upstream systemd project with the question if manual restarts should count towards the failure counter
<zyga> cachio: perhaps we should reset the failure state
<zyga> cachio: and try again?
<cachio> reset the failut state?
<zyga> yes
<cachio> zyga, how can I do that?
<zyga> cachio: one sec
<zyga> there's a command for it
<zyga> it's pretty rarely used
<cachio> zyga, ahh, nice
<zyga> cachio: systemctl reset-failed
<zyga> cachio: note that we could do something else
<zyga> cachio: run systemctl _stop_ to stop the journal
<zyga> sync
<zyga> to let various IO buffers stabilize
<zyga> cachio: then start again
<zyga> cachio: the sync in the middle may give everything enough time to actually not choke
<zyga> cachio: but if stop or start fails, we could run the reset-failed command to see if we can try again
<cachio> zyga, let me try it
<zyga> cachio: good luck, I have not tried that, maybe it won't lead anywhere
<zyga> but maybe it will
<cachio> using stop / sync / start
<cachio> works well
<cachio> rexec 20 times without error
<zyga> cachio: worth giving it a shot
<cachio> zyga, fix pushed
<zyga> cachio: super
<zyga> cachio: thank you!
<cachio> zyga, to you
<mvo> pedronis: you may want to check https://github.com/snapcore/snapd/pull/7689 just to make sure that the chosen name (client.DownloadInfo) is ok. happy to adjust as needed
<mup> PR #7689: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <https://github.com/snapcore/snapd/pull/7689>
<mup> PR snapd#7690 opened: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
<pedronis> Chipaca: #7690 is what I had in mind
<mup> PR #7690: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7690>
<pedronis> mvo: seems fine
<Chipaca> hehe
<pedronis> Chipaca: ?
<Chipaca> pedronis: reviewed
<Chipaca> pedronis: "hehe" because you called it 'autocomplete', and the flag 'autocompletHidden' (sic)
<Chipaca> pedronis: when it's completion, not autocompletion
<pedronis> Chipaca: it's funny because people call it autocompletion but is not the correct term?
<Chipaca> pedronis: on the phone it is
<Chipaca> pedronis: who calls it autocompletion on the terminal?
 * Chipaca googles
<pedronis> me apparently
<pedronis> living in the future
<Chipaca> pedronis: you and 190k+ people
<Chipaca> pedronis: vs 6M+ for just 'completion'
<Chipaca> pedronis: you're the 3%
<zyga> Chipaca: this autocompletes this problem
<zyga> ;-)
<pedronis> Chipaca: the flag is the override, so don't need to set on first boot, I need to set it on any hidden command we still want to auto complete
<pedronis> mostly the key stuff I think
<Chipaca> zyga: https://i.imgur.com/9HY53al.gif
<Chipaca> pedronis: d'oh! obvs
<zyga> my day is autocomplete now
<Chipaca> zyga: https://i.imgur.com/NJZgC1W.gif
<mup> PR snapd#7691 opened: builtin/browser_support.go: allow monitoring process memory utilizatiâ¦ <Created by Erick555> <https://github.com/snapcore/snapd/pull/7691>
<pedronis> Chipaca: fixed and marked some commands back
<vidal72[m]> what "disabled" mean under "notes" in "snap list" outpout?
<Chipaca> vidal72[m]: that the snap is not enabled
<Chipaca> vidal72[m]: i.e. that it is not even mounted
<Chipaca> vidal72[m]: or, if you're seeing 'snap list --all', that it is not current
<Chipaca> vidal72[m]: why?
<vidal72[m]> Chipaca: it seems my snap was during self-update, now "disabled" is gone
<pedronis> Chipaca: wonder if this means we would like: snap debug commands  to list them all anyway
<Chipaca> pedronis: say again?
<pedronis> Chipaca: do we need a way to show all the commands implemented
<pedronis> before this PR you could
<pedronis> "snap " <TAB> away to that
<Chipaca> pedronis: i don't think we do
<pedronis> now not anymore
<pedronis> Chipaca: ok
<Chipaca> pedronis: Â«GO_FLAGS_COMPLETION=1 snap ""Â» fwiw
<pedronis> Chipaca: that will not show the hidden ones now
<Chipaca> pedronis: i know, i'm just saying you to get it non-interactively
<pedronis> yea
<pedronis> I mean that command to list commands, for us, not in general
<Chipaca> pedronis: i don't think we need it, but we can add it if we do
<Chipaca> i'ma EOD
<mup> Bug #1584590 changed: Snap install download progress neatening up <snapd:Confirmed> <https://launchpad.net/bugs/1584590>
<mup> Bug #1616629 changed: could not unmarshal state entry "snap-type" <canonical-bootstack> <snapd:Confirmed> <https://launchpad.net/bugs/1616629>
<mup> Bug #1574103 changed: Raspberry Pi 2 image LEDs are swapped. <snapd:In Progress by maciek-borzecki> <https://launchpad.net/bugs/1574103>
<mup> Bug #1630789 changed: normal users can't run snaps inside of LXD containers <verification-needed> <snap-confine:Fix Released by jdstrand> <snapd:Fix Released by tyhicks> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by tyhicks> <snap-confine (Ubuntu Xenial):Fix
<mup> Committed> <snap-confine (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1630789>
<mup> Bug #1664383 changed: running snap list <snap> on a system that has no snaps installed exits 0 <conjure-up> <snapd:Fix Released> <https://launchpad.net/bugs/1664383>
<zyga> sil2100: hello, can you please enqueue looking at https://bugs.launchpad.net/snappy/+bug/1701018 tomorrow
<mup> Bug #1701018: Splash screen is not enabled in kernel <Snappy:Confirmed> <https://launchpad.net/bugs/1701018>
<zyga> there are open PRs and I think someone should have a look at them, decide which way to go and update the bug report
<mup> Bug #1721676 changed: implement errno action logging in seccomp for strict mode with snaps  <verification-done-xenial> <verification-done-zesty> <snapd:Fix Released by tyhicks> <linux (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu Xenial):Fix Released by tyhicks> <linux (Ubuntu Zesty):Fix
<mup> Released by tyhicks> <linux (Ubuntu Artful):Fix Released by tyhicks> <https://launchpad.net/bugs/1721676>
<mup> Bug #1708527 changed: Add /proc/partitions to system-observe <snapd-interface> <snapd:Fix Released> <https://launchpad.net/bugs/1708527>
<mup> PR snapd#7688 closed: cmd/snap: make completion skip commands (& opts) that ask for it <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7688>
<mup> Bug #1583975 changed: ubuntu IoT - webcam-demo 1.0.2 - apparmor="DENIED" operation="open" profile="webcam-demo.canonical_webcam-demo_1.0.2" name="/dev/video0" pid=3898 comm="fswebcam" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 <snapd:Fix Released> <https://launchpad.net/bugs/1583975>
<mup> Bug #1648431 changed: Allow snaps to shadow mounts from core <snapd:Fix Released by kalikiana> <https://launchpad.net/bugs/1648431>
<mup> Bug #1649837 changed: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
<zyga> pedronis: kind request to look at the bug https://bugs.launchpad.net/snapd/+bug/1649837 and check if the state can be updated now
<mup> Bug #1649837: Can remove required-snaps <snapd:In Progress by pedronis> <https://launchpad.net/bugs/1649837>
<mup> Bug #1650689 changed: Channel switching (track new channel) does not work if the two channels happen to have identical snap packages <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1650689>
<pedronis> zyga: we never implemented a patch so it's still not finished, now that we have idempotent patches maybe we can finish it
<zyga> pedronis: thank you, I'll update the bug
<zyga> mvo: are you still working by any chance?
<mup> Bug #1659534 changed: userdel doesn't supports extrausers <patch> <verification-done-bionic> <verification-done-xenial> <Snappy:Fix Released> <shadow (Ubuntu):Fix
<mup> Released> <shadow (Ubuntu Xenial):Fix Released> <shadow (Ubuntu Bionic):Fix Released> <shadow (Ubuntu Cosmic):Confirmed> <https://launchpad.net/bugs/1659534>
<mup> Bug #1660879 changed: snap refresh with more than one argument produces poor error message <snapd:Fix Released> <https://launchpad.net/bugs/1660879>
<mup> Bug #1661436 changed: snap download can't find snaps from a branded store <snapd:In Progress> <https://launchpad.net/bugs/1661436>
<mvo> zyga: ish, what can I do for you?
 * cachio afk
<zyga> ah, sorry, I went upstairs for some tea
<mup> Bug #1661590 changed: GNOME Software only supports running one application from a snap <verification-done-xenial> <GNOME Software:Fix Released> <Snappy:Fix Released> <gnome-software (Ubuntu):Fix Released by robert-ancell> <gnome-software (Ubuntu Xenial):Fix Released> <gnome-software (Ubuntu
<mup> Artful):Won't Fix> <gnome-software (Ubuntu Bionic):Fix Released by robert-ancell> <https://launchpad.net/bugs/1661590>
<mup> Bug #1693423 changed: initramfs error while loading Custom ubuntu core Image on X86 but it works fine in KVM <Snappy:Invalid> <https://launchpad.net/bugs/1693423>
<mup> PR snapcraft#2778 closed: Release changelog for 3.9 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2778>
<zyga> re
 * zyga managed to put Lucy to bed
<zyga> back to bug review
<mup> PR snapcraft#2779 opened: ci: switch to travis workspaces <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2779>
<mup> PR snapd#7692 opened: tests: opensuse tumbleweed has similar issue than arch linux with snap --strace <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7692>
<mup> PR snapd#7601 closed: overlord/ifacestate: use SetupMany in setupSecurityByBackend <Needs Samuele review> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7601>
<om26er> Hi! I landed a pull request for a project that has been setup for snapcraft automatic builds but it seems the build didn't start
<om26er> https://build.snapcraft.io/user/crossbario/crossbar
<om26er> Here is the relevent PR https://github.com/crossbario/crossbar/pull/1649
<mup> PR crossbario/crossbar#1649: Base snap on python 3.8 <Created by om26er> <Merged by om26er> <https://github.com/crossbario/crossbar/pull/1649>
 * zyga EODs
<zyga> ttyl
<sil2100> zyga: ACK! Will look!
#snappy 2019-10-30
<mup> PR snapd#7691 closed: builtin/browser_support.go: allow monitoring process memory utilizatiâ¦ <Created by Erick555> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7691>
<mup> PR snapd#7693 opened: Enabled GPG plug to access extra socket <Created by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
<mup> PR snapd#7693 closed: Enabled GPG plug to access extra socket <Created by Kedstar99> <Closed by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
<mup> PR snapd#7693 opened: Enabled GPG plug to access extra socket <Created by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
<mup> PR snapd#7689 closed: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7689>
<mup> PR snapd#7692 closed: tests: opensuse tumbleweed has similar issue than arch linux with snap --strace <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7692>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> -3 in the morning
<zyga> Hey
<zyga> Iâll start sometime after 8
<zyga> Sorry about all the bug spam from last night
<mborzecki> zyga:  hey
<mup> PR snapd#7684 closed: tests: disable mount-ns test in release/2.42 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7684>
<mup> PR snapd#7661 closed: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7661>
<pstolowski> morning
<zyga> hey pawel
<zyga> hey mvo
<zyga> rebooting
<mborzecki> pstolowski: hey
<pedronis> #7679 needs a 2nd review
<mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
<mup> PR snapd#7685 closed: snapstate,devicestate: make OldModel() available in DeviceContext <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7685>
<ondra> sergiusens can you translate for me this error "Snap 'grade' was set to 'stable' but must be 'devel'." and "Set 'grade' to 'devel' or use a stable base for this snap."
<ondra> sergiusens candidate channel and something what worked yesterday
<mup> PR snapd#7679 closed: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7679>
<sergiusens> ondra: can you share your snapcraft.yaml?
<sergiusens> and build-environment
<ondra> sergiusens https://git.launchpad.net/~ondrak/ondras-snaps/+git/openhab-snap/tree/snap/snapcraft.yaml?h=milestone-ondra
<ondra> sergiusens build in LP with candidate channels for core/core18/snapcraft
<sergiusens> ondra: oh, building with candidate channel of core18 could do it, let me look into it
<ondra> sergiusens that seems like way to constraining
<sergiusens> ondra: it was done to support core20, non-stable base means you can create a non-stable snap
<sergiusens> ondra: and yes, it is a way of constraining, it is exactly what grade is
<sergiusens> but I will need to think if your use case is one we want to allow for a stable grade
<ondra> sergiusens so I will be only able to build stable grade with stable base snap installed on build machine?
 * sergiusens notices it is well before working hours and parts
<ondra> sergiusens because we build and push into non stable channels and then promote, this will essentially kill use-cases when we want test build agains future stable core snap
<mup> PR snapd#7694 opened: many: load/consume Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7694>
<mup> PR snapd#7695 opened: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7695>
 * Chipaca takes a break
<mup> PR snapd#7696 opened: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7696>
<pedronis> Chipaca: mvo: ^ those are the current PRs,  7694 is the base and the larger one
<mvo> pedronis: thank you
<Chipaca> pedronis: ack
<mup> PR snapd#7697 opened: interfaces/apparmor: handle pre-seeding mode <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7697>
<mup> PR snapd#7650 closed: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7650>
 * pstolowski lunch
<mup> PR snapd#7698 opened: seed/internal: doc comment fix and drop handled TODOs <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7698>
<mup> PR snapd#7674 closed: interfaces: de-duplicate emitted update-ns profiles (2.42) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7674>
<mborzecki> pedronis: i've updated #7665
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<pedronis> mborzecki: I put it into my queue again
<mup> PR snapd#7699 opened: release: 2.42.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7699>
<mborzecki> cachio: hi, can you check whether fedora 31 images are already available in gce?
<cachio> mborzecki, sure
<ijohnson> morning folks, how is travis doing this morning
<cachio> mborzecki, sorry, I forgot
<ijohnson> some really weird failures it seems overnight, I had a unit test fail on me for snapstate.SnapState not having a Channel field but it definitely has that field?
<cachio> mborzecki, we build fedora images
<cachio> because are not published for gce
<mborzecki> cachio: oh, using the cloud.fedoraproject.org ones?
<cachio> mborzecki, we use the cloud ones yes
<mborzecki> cachio: then 31 are up at https://alt.fedoraproject.org/cloud/
<cachio> mborzecki, I could create one by using http://fedora.c3sl.ufpr.br/linux/releases/31/Cloud/x86_64/images/
<mborzecki> cachio: sgtm, thanks!
<Chipaca> zyga: https://github.com/whitequark/unfork/blob/master/README.md
<zyga> Chipaca: I read that
<zyga> neat stuff
<Chipaca> zyga: i thought you might've
<Chipaca> but, yeah
<Chipaca> bonkers
<zyga> mvo: I simplified this stuff, no snap-confine changes required
<zyga> mvo: it's just a small go change now
<mvo> zyga: oh?
<mvo> zyga: how did you do that?
<zyga> mvo: it works super nice already
<zyga> mvo: working on snapd side now
<zyga> mvo: we can actually wire it in cmd_run.go
<mvo> zyga: what is the mechanism that you use there?
<mvo> zyga: just looking for a flag file?
<zyga> mvo: the same as before, yes
<mvo> zyga: nice
<zyga> mvo: if there's a feature flag enabled
<zyga> mvo: and the inhibit file is present
<zyga> mvo: loop on the presence
 * mvo nods
<zyga> mvo: // TODO: ask snapd for details
<zyga> mvo: it even _runs_ the app later
<zyga> it is easier and better than the idea that snap-confine execs that
<mvo> zyga: nice
<Chipaca> in unrelated news, don't do an image search for 'grub size', if you're thinking about bootloaders.
<jdstrand> woo, looks at those small snap-update-ns profiles in 2.42.1
<zyga> jdstrand: indeed :)
<jdstrand> zyga: ^ (hi)
<zyga> fixing bugs is the bests part of this job
<jdstrand> zyga: I did notice, and this isn't a big deal, that there is a blank line between every rule
<zyga> I noticed
<zyga> I'll fix it up, just a bit annoying at the time
 * jdstrand nods
<zyga> snippets are joined with "\n" automatically
<jdstrand> yeah
<jdstrand> zyga: not a big deal. loving the reduced ruleset :)
<zyga> requires either some test adjustment or some careful coding to prevent spurious \n
 * jdstrand hugs zyga 
<zyga> yeah, I will second what you said in a review
<zyga> it's surprisingly readable
<zyga> because it builds a context
<zyga> and adds incremental changes
<zyga> I didn't plan for that, it just ended up working better than I expected
<jdstrand> zyga: I know, right? that OrderedSet worked wonderfully
<jdstrand> me too :)
<zyga> jdstrand: I'm doing a small prototype but I will be pushing that cgroup PR forward soon
<zyga> jdstrand: with fixes that make lxd work
<jdstrand> zyga: sweet :)
<jdstrand> I want to update my test vms to 2.42.1 now that the dupe rules are gone, but I can what for stable
<jdstrand> I'll just have to 'settle' for fast refreshes on my laptop for the next week or so :)
<zyga> jdstrand: I noticed that it's also useful for development
<zyga> jdstrand: because system key regeneration is super fast now
<zyga> jdstrand: it was mainly slow because of this, apparently
 * zyga breaks for some food
<ijohnson> mvo: pedronis: assuming y'alls calendars are up to date, there's a 30m window in about an hour where we could meet to discuss if you want (I don't think the discussion would take 30m though)
<ijohnson> also different topic, but should I get another review on #7581, or am I good to merge that? I had to tweak the tests slightly to disable core16 tests of the Info D-Bus method, not sure if that warrants more reviews
<mup> PR #7581: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>
<mup> PR snapd#7700 opened: many: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<pedronis> ijohnson: it works for me, don't know about mvo
<mvo> ijohnson: yes, works for me
<cachio> Chipaca, hey https://paste.ubuntu.com/p/qPWP4nF48F/
<cachio> on pi3, snap list does not show latest/
<cachio> and it breaks the listing test
<ijohnson> Cool I'll just send out a calendar invite just to be sure
<cachio> Chipaca, it should show latest/edge?
<mup> PR snapd#7698 closed: seed/internal: doc comment fix and drop handled TODOs <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7698>
<mup> PR snapd#7581 closed: tests: add netplan test on ubuntu core <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7581>
<Chipaca> cachio: it depends, but probably yes
<Chipaca> mmm
 * Chipaca looks at what's on edge
<cachio> Chipaca, I just refreshed and then did snap list
<Chipaca> hmmm
<Chipaca> there might be a bug somewhere
<Chipaca> on edge
<Chipaca> I'm seeing a tracking of "latest"
<Chipaca> not "stable", not "latest/stable", just "latest"
<Chipaca> that's not good
<Chipaca> cachio: what channel are you looking at?
<cachio> I have created an image with channel stable
<cachio> and then refreshed core to edge
<cachio> and I see what I pasted
<Chipaca> cachio: let me think a bit
<Chipaca> cachio: also, let me start with something sane because my local snapd has seen some shit (and might be doing its best)
<cachio> Chipaca, hehee
<cachio> sure
<cachio> take your time
<Chipaca> cachio: also, also, most of my channels work is not on master yet
<Chipaca> cachio: and there's no code to add latest/ on master
<Chipaca> afaik?
 * Chipaca checks again
<cachio> it si merged to master I think
<Chipaca> ah, yes, there is, for the tracking channel, yes
<Chipaca> in state
<Chipaca> cachio: what does 'snap info' say for that snap?
<Chipaca> cachio: in 'tracking:'
<cachio> Chipaca, https://paste.ubuntu.com/p/TWHsVz6j6g/
<cachio> tracking : edge
<zyga> re
<Chipaca> cachio: ok give me a bit
<cachio> Chipaca, sure
 * cachio lunch
<Chipaca> cachio: ok, so i'm seeing this "latest" bug on stable; after your lunch we can talk
<Chipaca> one dge i mean
<cachio> sure
<cachio> tell me now
<cachio> lunch can wait
<Chipaca> cachio: so. tell me what you did, on the pi3
<cachio> Chipaca, so, is it a bug?
<Chipaca> there is a bug, but it's not the one you told me :) so you tell me
<cachio> hehe
<cachio> Chipaca, I created a stable image
<Chipaca> with you so far
<cachio> then I booted that image in the pi3
<Chipaca> ok
<cachio> then I refreshed the core snap from edge
<Chipaca> ok
<cachio> rebooted
<cachio> and did snap list
<cachio> that's it
<Chipaca> ok
<Chipaca> there is no code that would've magically converted the 2.42 "stable" to "latest/stable" in 2.43
<Chipaca> if you install something new, say: snap install --beta http
<Chipaca> then you'd see latest/beta
<Chipaca> the code to fix state is still up for review
<Chipaca> cachio: are you thinking of cutting edge to candidate or something?
<Chipaca> because i wouldn't ship with part of this channels work
<Chipaca> i'd recommend backing out the change, or merging the rest of it
<cachio> Chipaca, add
<cachio> ok
<Chipaca> cachio: the bug _I_ saw was that the code for 'snap list' turns "latest/stable" into "latest", which could be confusing, but it's only for display so it's not a biggie
<Chipaca> and it would not be a problem with the rest of channels
<cachio> in that case the problem is the test, but should automatically be fixed soon
<Chipaca> ok
<Chipaca> well, should be, but reviews are hard to come by :)
<cachio> Chipaca, agree :)
<cachio> thanks for the help
 * cachio lunch for real now
 * Chipaca steps away for a while
 * Chipaca lied
<Chipaca> ok, now yes
<Chipaca> bbl, ttfn
<jdstrand> zyga: in case you didn't see and possibly relevent for your pr: https://bugs.launchpad.net/bugs/1850667
<mup> Bug #1850667: cgroup v2 is not fully supported yet, proceeding with partial confinement <docker.io (Ubuntu):New> <lxd (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1850667>
<mup> PR snapcraft#2779 closed: ci: switch to travis workspaces <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2779>
<mup> PR snapcraft#2780 opened: remote-build: rename `--arch` to `--build-arch` <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2780>
<zyga> jdstrand: thank you
<zyga> jdstrand: relevant to this is https://github.com/snapcore/snapd/pull/7614
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga> jdstrand: not urgent but if you look at the PR text you can see where this is going
<zyga> jdstrand: I have code that is close to handling v2 as well
<zyga> jdstrand: but not fully working, it's been touched a while ago the last time
<zyga> jdstrand: but this moves us towards real v2 support end to end, without partial
<jdstrand> zyga: ack, thanks. it is on my list but not at the very top. hopefully late this/early next week
<zyga> jdstrand: but first, that agent needs to land
<zyga> jdstrand: no rush, I'm off on Friday
<zyga> jdstrand: really no rush, it's post vancouver topic
<jdstrand> ok, thanks
<zyga> jdstrand: but after that we could get full v2 support in about three weeks
<jdstrand> ok even better. cause the stuff in front is all pre-vancouver :)
<jdstrand> zyga: that's really cool :)
<zyga> jdstrand: yeah
<mvo> pedronis: I pushed an update to 7649
<mvo> pedronis: if that looks good I will push the same approach to 7682
<mvo> pedronis: should be small and simple to review
<pedronis> mvo: do you want me to look tonight? or tomorrow?
<mvo> pedronis: tomorrow is fine of course
<pedronis> ok
 * cmatsuoka steps into another strange race-like behavior when partitioning disks
 * Chipaca AFKs for another while
 * cachio afk
<Saviq> jdstrand: hey, I'm trying to make snapcraft compatible with strict multipass, which means piping file contents via stdio rather than throwing file paths around
<Saviq> basically I need the equivalent of: cat /tmp/tmp6q6ur_co/snapd.snap | multipass transfer - snapcraft-multipass:/var/tmp/snapd.snap
<Saviq> but when I do this in python, I'm getting a denial:
<Saviq> https://pastebin.ubuntu.com/p/6nnw6GNjWG/
<Saviq> it seems like Python is making some kind of a short circuit between the confined process and the file being read?
<jdstrand> Saviq: hey, that's funny you should mention that as I was doing an investigation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753
<mup> Bug #1849753: AppArmor profile prohibits classic snap from inheriting file descriptors <amd64> <apport-bug> <focal> <wayland-session> <AppArmor:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1849753>
<jdstrand> Saviq: it is the same issue you are seeing ('file_inherit' is blocked with snap-confine)
<jdstrand> Saviq: you could probably do: multipass transfer - snapcraft-multipass:/var/tmp/snapd.snap < /tmp/tmp6q6ur_co/snapd.snap
<jdstrand> Saviq: well, maybe not since you said python is doing this to you
<jdstrand> Saviq: I can't think of a way to do that besides making python read from /dev/stdin
<jdstrand> (and I'm not sure otoh how to make it do that)
<jdstrand> Saviq: dan from our team might have a suggestion
<Saviq> jdstrand: right, in this case the calling process (snapcraft) is classic and the callee is strict, but I suppose the same thing applies
<Saviq> but yeah I may be able to do the shell dance
<jdstrand> Saviq: that doesn't matter, it is that you are calling something in /snap/bin which calls snap run, which calls snap-confine and it doesn't have access at the profile transition when the path is revalidated
<jdstrand> Saviq: you could also trying calling something in /snap/whatever/current/... instead, outside of confinement, but that is likely not ideal
<jdstrand> s/outside/which ends up being outside/
<Saviq> yeah, a "cat file | multipassâ¦" works fine
<Saviq> "multipassâ¦ < file" has the same denial
<Saviq> which I suppose makes sense
<jdstrand> Saviq: ah, yes on both counts
<mup> PR snapcraft#2781 opened: yaml_utils: move _load_yaml from project for re-use (and add tests) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2781>
<Saviq> nowâ¦ what's the reverse of "cat"â¦ like "tee", but without printing to stdout :D
<Saviq> ah, `dd` to the rescue :P
<Saviq> but all that really won't be cross-platformâ¦
<jdstrand> there won't be an immediate fix for that bug. but there are some options to investigate before we have proper fd delegation in apparmor at least
<jdstrand> that came out wrong
<jdstrand> proper fd delegation would allow us to fix that. before we have that, there might be some things we can do, but that needs investigating
<Saviq> it looks like I'll really have to read the file into memory to feed it in againâ¦
<Saviq> what's weird(ish) is that python claims that from 3.4 onwards the fds are non-inheritable, which I thought for a bit could avoid thisâ¦
<mup> PR snapcraft#2782 opened: snapcraft: introduce click-based YAML configuration file support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2782>
<mup> PR snapd#7701 opened: overlord: add kernel rollback accross reboots manager test and fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7701>
<techalchemy> jdstrand, how's this
<jdstrand> techalchemy: thanks! :)
<mup> PR snapd#7702 opened: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<mup> PR snapcraft#2783 opened: cli: run review tools before pushing to the store if available <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2783>
<mup> PR snapcraft#2780 closed: remote-build: option renames for arch, user, and accept-public-upload <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2780>
<mup> PR snapcraft#2781 closed: yaml_utils: move _load_yaml from project for re-use (and add tests) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2781>
<mup> PR snapcraft#2784 opened: [multipass] use stdio to get data in/out of Multipass <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/2784>
<mup> PR snapd#7703 opened: cmd/snap: make 'snap list' shorten latest/$RISK to $RISK <Channels ð·ï¸> <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7703>
<mup> PR snapcraft#2785 opened: remote-build: add initial command unit tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2785>
#snappy 2019-10-31
<ijohnson> zyga: when you get in can you take a look at https://bugs.launchpad.net/snapd/+bug/1850720? thanks!
<mup> Bug #1850720: installing snap with layout on /etc/ld.so.cache results in deleted mount <snapd:New> <https://launchpad.net/bugs/1850720>
<mborzecki> morning
<zyga> ijohnson: done
<zyga> hey mborzecki  :)
<mborzecki> zyga: hey hey
<zyga> mborzecki: I think I restored my sleep budget to normal state
<mborzecki> a lot of red and a funch of stuck travis jobs?
<zyga> mborzecki: must be Thursday ;)
<zyga> mborzecki: I'll review the other PR today
<mborzecki> pedronis: mvo: hey
<mborzecki> mvo: fixed the typo in #7701 but the unit tests fail, want me to look into that?
<mup> PR #7701: overlord: add kernel rollback accross reboots manager test and fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7701>
<mvo> hey mborzecki
<mvo> mborzecki: oh, hm, hm
<mvo> mborzecki: you are welcome to look
<mborzecki> mvo:  this is what's failing there: https://paste.ubuntu.com/p/Hdzh8kbqF9/
<mvo> mborzecki: oh, fun
<mvo> mborzecki: /o\ yeah, I worked on the manager tests
<mvo> mborzecki: but did not run the whole thing
<mborzecki> mvo: haven't done much around reboots, but i can dive in and check what's happening there
<mvo> mborzecki: is the parallel install and gadget all blocked? if so, yes, a look at this would be great
<mborzecki> mvo: parallel installs is waiting for a review from zyga, jdstrand already +1'ed it
<zyga> mborzecki: yep, on my plate today
<zyga> mborzecki: I think it will land today
<mborzecki> mvo:  and gadget remodel needs reviews ;) you're welcome to do a pass there
<mborzecki> zyga: yeah, had to restart the tests
<mvo> mborzecki: aha, nice. I will do have a look
<mvo> mborzecki: cool, more eyes on the boot code are always good
<mborzecki> and wanted to take a look into #7702, see hwther i can move some stuff over from #7193
<mvo> mborzecki: I suspect its missing fixtures now
<mup> PR #7702: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
<mup> PR #7193: [WIP] many: cgroupsv2 spread run <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7193>
<pstolowski> morning
<mvo> mborzecki: yeah, it looks like the mocks are now incomplete in the booted_test. I suspect its just a matter of adding Type: snap.TypeOS etc
<zyga> wow, Tyler got mentioned on https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-speculative-behavior-swapgs-and-segment-registers
<mborzecki> btw https://medium.com/nttlabs/cgroup-v2-596d035be4d7
<mvo> mborzecki: yeah, its just a missing Type: snap.TypeBase for the snapsetup fixture
<mvo> mborzecki: I push the (trivial) fix
<mborzecki> mvo: ah ok :)
<mvo> mborzecki: thank you still!
<zyga> mborzecki: lol
<zyga> runc, the reference implementation of OCI Runtime Spec, gained the initial support for cgroup v2 just last month (PR: #2113). This is not ready for production, especially because it lacks the implementation for eBPF device controller
<mup> PR #2113: interfaces/builtin: add i2c interface <Created by bergotorino> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2113>
<zyga> mborzecki: at least they have a PR open
<mborzecki> zyga: yeah, heh
<zyga> anyway, I think we are "state of the art" in the sense that the state is shit anyway
<mborzecki> zyga: feels like switching the defaults in systemd is a bit premature, but it's fine that fedora did it, otherwise nobody would care to transition
<zyga> yeah
<zyga> I think it's just like that
<zyga> you have to toggle the experimental feature
<zyga> or it will never really work
<zyga> free systems are the beta testers
<zyga> (in fedora world)
<mborzecki> haha, that sounds familiar tbh :)
<zyga> TBH I find the whole runc/crun/podman/docker/moby stuff a terrible mess
<zyga> as in, all the $$$ behind this wants to land grab
<zyga> probably inevitable but feels like mud with leeches
<mborzecki> zyga: you left out skopeo
<zyga> I'm sure I did
<zyga> it's a zoo of new things that do part of what docker did
<zyga> all with quirky geeky names
<zyga> oh well
<mborzecki> xD
<zyga> brb, cold today, need tea
<pedronis> mvo: hi, I made a pass on 7701 (covering also the one is based on I think)
<pedronis> s/made/did/
<zyga> hey pedronis :)
 * zyga is back with hot tea
<pedronis> mvo: maybe close 7649 and keep only 7701? I find reasoning about both situations together easier
<pedronis> 7649 is very small
<mvo> pedronis: sure, happy to do that
<mvo> pedronis: thank you! will look at the feedback now
<mvo> fwiw 7651 needs a second review, it will unblock 7652
<mup> PR snapd#7649 closed: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Remodel ð> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7649>
<pedronis> mborzecki: did another pass on #7665, looking good
<mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
<mborzecki> pedronis: thanks!
<pedronis> mvo: I looked what that was, but it's my slots-per-plug stuff, I cannot do the 2nd review :)
<pedronis> mvo: thx for the review
<mvo> pedronis: haha, yes
<mvo> pedronis: would love to unblock this today
<mvo> pedronis: I updated the PR based on your feedback (7701)
<pedronis> mvo: thx, will look in a bit
<mvo> Chipaca: I updated 7624 a bit more based on your suggestions, would love to add some more tests, a second look would be great (just to doulbe check) and then your opinion if I should merge and or do some PRs with test improvements first
<Chipaca> mvo: omw
<mvo> Chipaca: no rush
<mvo> mborzecki: you got some feedback on the remodel PR, more to come :)
<mborzecki> mvo: ah ok, i'll wait with the fixes then
<mvo> mborzecki: do the fixes, thats fine, I will not be able to look for at least 1h
 * zyga -> walk 
<Chipaca> mvo: any particular reason you went with syscall.SIGINT instead of os.Interrupt?
<mvo> Chipaca: no reason, we use that elsewhere too
<Chipaca> fair
<Chipaca> drat, there's a chunk of functionality we should abstract somewhere neat
<Chipaca> :)
<Chipaca> mvo: looks good! i'll be building and testing it locally in a bit to see if i catch any other issues
<mvo> Chipaca: this is why I said I'm not super happy yet :/ it feels ok but not great (yet)
<Chipaca> mvo: maybe it's all that 'snap donwload'
<Chipaca> siiigh
<Chipaca> mvo: interrupting the download prints a spurious error message, at least in part because Download() isn't receiving a context form the command so it doesn't know it's been canceled
<Chipaca> mvo: otoh the command could know it's canceled and ignore the error at that point
<Chipaca> mvo: otoÂ²h it's third-order nits at this point
<Chipaca> mvo: otoÂ³h it's the sort of polish we like
<Chipaca> and they're ux regressions
<Chipaca> the --direct version doesn't suffer from this
<Chipaca> :-/
<Chipaca> mvo: so
<Chipaca> mvo: how about this
<Chipaca> mvo: switch the defaults, land as is, work on the nits until they're where we want them, _then_ switch the defaults
<mvo> Chipaca: nice one!
<Chipaca> mvo: maybe even make the options hidden so we can play with them without breaking stuff
<Chipaca> so don't add --direct, but add a hidden --indirect or something
<Chipaca> mvo: it feels like it's a couple of PRs of refactorings to get the UX where we want it
<Chipaca> that's my gut feeling about it, but my gut is full of shit
<Chipaca> wait
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> mvo: disadvantage is that, because people are needing this functionality, they'll start using it even if it's hidden so we'd have to carry it forever
<Chipaca> mvo: but OTOH having a hidden --indirect forever doesn't seem too onerous
<mup> Bug #1574487 changed: possibly unclean shutdown <Snappy:Fix Released> <initramfs-tools-ubuntu-core (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1574487>
<mup> Bug #1606574 changed: SSH Interface is missing <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1606574>
<zyga> Unexpected errand, 1.5 hrs
<mup> Bug # changed: 1593450, 1613971, 1624829, 1637611
<mup> Bug #1641631 changed: Raspberry Pi images do not support boot from USB <Snappy:Fix Released by alfonsosanchezbeato> <https://launchpad.net/bugs/1641631>
<mup> Bug #1642082 changed: Timestamp error when we try to sign a model assertion <snappy-docs> <Snappy:Fix Released by davidc3> <https://launchpad.net/bugs/1642082>
<mup> Bug #1646144 changed: ACLs to devices need to be supported in core  <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Fix Released by ogra> <ubuntu-core-meta (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1646144>
<mup> Bug #1646333 changed: bind mounts related to content interface plugs remain stale on snap disconnect/connect or snap updates <Snappy:Fix Released> <https://launchpad.net/bugs/1646333>
<mup> Bug # changed: 1647169, 1654588, 1655711, 1656820, 1657751, 1659149
<mup> Bug # changed: 1659724, 1659744, 1660865, 1673757, 1675054
<Chipaca> somebody's having fun on their triage day
<mup> Bug # changed: 1663177, 1671266, 1676244, 1680088, 1683368, 1705486, 1737427, 1743301
<mup> Bug #1747794 changed: cannot resolve host name  with avahi interface  <Snappy:Fix Released> <https://launchpad.net/bugs/1747794>
<mup> Bug #1758849 changed: Snap not able to enable ssh after core upgrade  <Snappy:Fix Released> <https://launchpad.net/bugs/1758849>
<mborzecki> sorry for the spam
<zyga> Errand almost done, grabbing some food now
<zyga> mvo: Iâll make it up tomorrow
<zyga> mborzecki: what is Ubuntu-core-meta?
<Chipaca> mborzecki: don't be sorry! good stuff
<mborzecki> zyga: no clue, better ask ogra
<Chipaca> zyga: it's a meta package
<zyga> I wonder if we could close some weird projects
<zyga> Or disable them from bug reports at least
<Chipaca> zyga: in particular it has nothing to do with us
<Chipaca> ubuntu-core-meta is the source of ubuntu-core-libs
<Chipaca> zyga: where are we getting dragged into it?
<Chipaca> hmmmm
 * Chipaca reads what he wrote
<Chipaca> ok, in the above, change 'us' or 'we' to 'snappy'
 * Chipaca needs to work on that some more
<Chipaca> ah, i just saw the bug
<Chipaca> so snappy isn't involved at the project level, just that bug that affected it
<Chipaca> ok
<mup> PR snapd#7699 closed: release: 2.42.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7699>
<mup> PR snapd#7704 opened: snap: extract printInstallHint in cmd_download.go <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7704>
<mup> PR snapd#7705 opened: o/devicestate: Handle preseed in firstboot [WIP] <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<pstolowski> pedronis: hey, i marked this ^ WIP because i had to push changes to parts that i intend to propose separately (and that miss tests right now), but i was impossible to avoid these bits
<zyga> Chipaca: :D
 * zyga is back from errand and lunch
<zyga> and back to coding
<zyga> mborzecki: btw, about those locks, we create locks 0600
<zyga> so no catastrophy :)
<Chipaca> zyga: https://i.imgur.com/HCe563J.jpg
 * Chipaca goes for lunch
<zyga> hmm
<zyga> Chipaca: meouch!
<mup> PR snapd#7193 closed: [WIP] many: cgroupsv2 spread run <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7193>
<pedronis> Chipaca: thanks for the review, I tried to answer your questions, maybe you have further feedback on the first and last
<Chipaca> pedronis: the .More() was to error if there was garbage after the json, fwiw
<pedronis> Chipaca: we could, it's a bit more interesting if it was a network connection
<Chipaca> joeubuntu: wait so you and joedborg _aren't_ the same person?
<Chipaca> :)
<Chipaca> true
<joedborg> Not that I know of ð
<Chipaca> joeubuntu: i learned of joeubuntu leading the robotics team at the same time i saw your nick
<joeubuntu> In the singularity all joes are unified in to one...
<pedronis> Chipaca: would it be better if that label was inside an Options struct ?
<pedronis> (I would do that change in one of the follow ups though)
<Chipaca> pedronis: not until we know what we're doing :)
<pedronis> ok
<Chipaca> pedronis: found the bug in the completion pr (i'm having lunch so figured it was a good time to poke at it)
<pedronis> ah, good
<pedronis> Chipaca: the fun with labels happens here: https://github.com/snapcore/snapd/pull/7658/files#diff-eb9825aa18d9bbbcc41ca31728af8157R75 in the later PR
<mup> PR #7658: cmd/snap-preseed: add snap-preseed executable <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>
<pedronis> there's just a TODO for now there, it relates to your work (modes and modeenv etc)
<Chipaca> pedronis: i think that's the link to the nil db pr, no the labels one :)
<pedronis> Chipaca: oops
<pedronis> https://github.com/snapcore/snapd/pull/7695/files#diff-0b649265c21137e8fd367d4a16607a82R409
<mup> PR #7695: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7695>
<pedronis> Chipaca: ^
<Chipaca> pedronis: ta
<Chipaca> i'll get to that eventually (hoping for today!)
<pedronis> Chipaca: any I have a chain with another 2 or 3 PRs on top of the ones there, so fill free to do a rename to OpenWithLabel next week
<pedronis> s/any/anyway/
<zyga> brb
<Chipaca> pedronis: with the completion tweak we no longer offer 'interfaces'; is that ok?
<pedronis> Chipaca: it's been deprecated since a while
<pedronis> but no strong opinion either way
<Chipaca> pedronis: i think it's ok, i do need to fix a test though :)
<Chipaca> very easy fix
<pedronis> use connections instead
<Chipaca> nah, the test is checking the completion of 'snap in<tab>'
<pedronis> ah ok
<Chipaca> :)
<pedronis> we still do have interface
<pedronis> singular
<pstolowski> Chipaca: whom to thank for the nice pre-baking label icon ;)
<Chipaca> yep, that's the fix
<pstolowski> ?
<Chipaca> pstolowski: not me!
<Chipaca> not this time :-D
<pstolowski> hmm
<Chipaca> but whoever did it, thank you for using the actual ð and not :bread:
<pedronis> mborzecki: good suggestion in the systemd prebaking PR
<mup> PR snapcraft#2786 opened: cli: add support for 'http-proxy' and 'https-proxy' parameters <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2786>
<pedronis> pstolowski: will you have time to stay after the standup?
<pstolowski> pedronis: yes, but i may need to drop for a while at around 4pm to pick my daughter from school
<pedronis> pstolowski: ok, let's see what we can, I would like to go over the firstboot stuff with you live
<pedronis> Chipaca: Q to your fix
<Eighth_Doctor> popey: `snapd` is now in EPEL 8, so the website needs instructions for CentOS 8
<Eighth_Doctor> the instructions should basically be the same as for CentOS 7
<Eighth_Doctor> so I think only the notes about lack of availablity on RHEL 8 and CentOS 8 need to be removed
<Eighth_Doctor> kyrofa: you might want to give me co-maintainership of squashfuse
<Eighth_Doctor> you can do that by going to https://src.fedoraproject.org/rpms/squashfuse, logging in, going to the project settings, go to users & groups, and add "ngompa" as an admin
<Chipaca> pedronis: running spread locally so can't push a fix for the typo, but made a suggestion there if you want to commit it
<degville> Eighth_Doctor: I've been tracking the EPEL updates - I'll update the install docs.
<Eighth_Doctor> degville: thanks
<Eighth_Doctor> `snapd` just synced out to EPEL 8 this morning
<degville> brilliant, thanks!
<pedronis> Chipaca: I committed
<Chipaca> nice OOM running spread locally
<mup> PR snapd#7707 opened: snap: add TestDownloadDirectStoreHappy test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7707>
<zyga> re
<zyga> family home now
<zyga> back to work
<roadmr> \o/
<zyga> mvo, pstolowski, mborzecki: we will likely visit graves tomorrow as it's bound to rain all weekend here
 * cachio lunch
<mvo> has anyone figured out why the tests are unhappy?
<Chipaca> mvo: because they hate us
<Chipaca> mvo: i've just seen an error in prepare on centos, for example
<Chipaca> + systemctl daemon-reload
<Chipaca> Failed to execute operation: Connection reset by peer
<Chipaca> and on restore, also on centos,
<Chipaca> + systemctl daemon-reload
<Chipaca> Failed to execute operation: Connection timed out
<Chipaca> it's a fractal of WAT
<Chipaca> a WATdelbrot curve
<mvo> hrm, hrm, if its all centos I'm inclined to move it to unstable-systems until its fixed
<mvo> kind of annoying that it blocks landing stuff
<Chipaca> mvo: ah it is in unstable already
<Chipaca> mvo: sorry
<Chipaca> mvo: at least this particular centos is :)
 * mvo nods
<Chipaca> the task that says CentOS contains no CentOS
<kyrofa> Eighth_Doctor, are you just looking to get squashfuse updated? Or is there a larger issue that I've missed?
<Chipaca> error: Get https://fastly.cdn.snapcraft.io/download-origin/fastly/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap?token=1572548400_b95c66d9e68375e958b164a800f1b618a0e69653: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "GlobalSign CloudSSL CA - SHA256 - G3")
<Chipaca> mvo: ^
<Chipaca> mvo: that might have something to do with the red
<mvo> Chipaca: *grumpf* not cool
<zyga> wahaat?
<zyga> SSL is such a shitshow
<zyga> ijohnson: did my response to the bug related to ldcache make sense?
<ijohnson> zyga: yes sorry for not responding in the bug, but I was able to work around it by having ldconfig work on some other file, then I just copy that file to what's bind-mounted so it never calls unlink on the file
<ijohnson> it is unfortunate that there's not much better we can do about that though
<zyga> ijohnson: I suggested a workaround
<zyga> ijohnson: a symlink would make it easier
<ijohnson> ehh not quite
<ijohnson> I tried the symlink but it still has problems
<zyga> no? is the code sensitive to symlinks?
<zyga> I see, well worth a try
<zyga> I think it will be nicer
<zyga> once we have /etc tmpfs
<ijohnson> I don't remember the issue with symlink, but I tried it and it didn't work for some reason
<zyga> or not tmpfs
<zyga> just a /var/lib/snapd/.../etc
<ijohnson> perhaps it was not an issue with the symlink directly, but anyways I have a workaround
<Eighth_Doctor> kyrofa: 1. squashfuse needs to be updated, it needs to be introduced to epel8, and squashfuse binary needs to be replaced with a symlink to squashfuse_ll binary
<zyga> mborzecki: I have some ideas on how to solve the lock issue
<kyrofa> (1) is a known issue, but squashfuse_ll is news to me. Can you give me some background?
<zyga> mborzecki: the inhibit files can be locks
<zyga> mborzecki: held by snapd
<zyga> mborzecki: and unlocked by snapd
<zyga> mborzecki: and snap run, if the files are present, try to grab a shared lock
<zyga> mborzecki: while snapd holds an exclusive lock
<zyga> mborzecki: I need to think how to create an inhibition file in a way that is race free
<zyga> mborzecki: but I think it can be done by allowing snapd to check for ability to grab the exclusive lock
<zyga> mborzecki: so if the lock is held by snap run already
<mup> PR snapd#7708 opened: parts/plugins: don't xz-compress a deb we're going to discard <Created by chipaca> <https://github.com/snapcore/snapd/pull/7708>
<zyga> mborzecki: we will know in snapd
<zyga> mborzecki: anyway, enjoy your evening
<mborzecki> zyga: we probably need to draw/write this down
<zyga> mborzecki: yeah, I'll write it down in the doc
<Chipaca> zyga: you still here?
<Chipaca> zyga: i think something's change such that google:ubuntu-18.04-64:tests/main/snap-seccomp-syscalls  fails
<Chipaca> zyga: https://paste.ubuntu.com/p/FGp43JqGGJ/
<Chipaca> or maybe that's an mvo ^ not sure
<Chipaca> looks like we got a bunch of new syscalls
<mvo> Chipaca: meh, ok
<Chipaca> most around time64
<Chipaca> mvo: so that's probably why a lot of things are red
<Chipaca> there's also a fsconfig/fsmount/fsopen/fspick thing we might be interested in :)
<Chipaca> read more about 'em here: https://lwn.net/Articles/759499/
<mvo> Chipaca: hm, thats on 18.04?
<Chipaca> they look like a change in the right direction, aiui, given some of our woes
<Chipaca> mvo: ye
<Chipaca> so i suspect this is a blocker, righ tnow
<mvo> Chipaca: I can fix this probably
<zyga> Chipaca: yes I'm here
<zyga> Chipaca: looking now
<Chipaca> p > 0.9?
<zyga> oh
<zyga> lots new
<mvo> Chipaca: yeah
<zyga> we have some problems
<zyga> clone3 :/
<zyga> it may bite us
<zyga> as soon as glibc uses it
<zyga> and we respond with EPERM
<zyga> and glibc doesn't use older clone
<zyga> Chipaca: 180.04 though is very surprising
<zyga> Chipaca: is this new seccomp in 18.04
<zyga> ?
<zyga> jdstrand: ^ do you know if we have a backported libseccomp in 18.04
<Chipaca> zyga: this is in 18.04, as above
<zyga> jdstrand: or a new kernel and libseccomp now reports new syscalls it knew about
<Chipaca> zyga: ie this is failing google:ubuntu-18.04-64:tests/main/snap-seccomp-syscalls
<zyga> Chipaca: I'll park my work and look
<pstolowski> pedronis: +1 on #7694
<mup> PR #7694: many: load/consume Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7694>
<zyga> Chipaca: testing locally
<zyga> I'll send a PR soon
<zyga> brb
<Chipaca> zyga: FWIW 4.15.0-47-generic landed in 18.04 recently
<Chipaca> zyga: no seccomp update since august afaik
<Chipaca> (that's according to the dpkg.log in this kvm 1804, fwiw)
<pedronis> pstolowski: thanks, tried to answer your question
<mup> PR snapd#7694 closed: many: load/consume Core 20 seeds (aka recovery systems) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7694>
<pedronis> Chipaca: pstolowski: I'm going now to rebase the two follow ups
<Chipaca> pedronis: thank you
<pstolowski> great
<pedronis> Chipaca: pstolowski: mvo: I rebased #7695 (firstboot stuff) and #7696 (prepare image stuff) and they are ready for review
<mup> PR #7695: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7695>
<mup> PR #7696: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7696>
<pedronis> hopefully that latter doesn't break spread tests
<jdstrand> Chipaca, zyga: I need to step away in a minute, but did the gke kernel get an update? (I didn't look at the failure either)
<pstolowski> pedronis: ty
<Chipaca> jdstrand: plain ol' 18.04 at least did
<jdstrand> Chipaca: I have like 3 minutes. can you give a url so I can see the failure?
<Chipaca> jdstrand: the failure is in https://api.travis-ci.org/v3/job/605555475/log.txt the diff expected vs found syscalls is https://paste.ubuntu.com/p/FGp43JqGGJ/
<Chipaca> jdstrand: dunno if you saw zyga say he's got a fix that he's testing locally
<Chipaca> i assume you did and you're wanting to look at what the new syscalls are to be in the loop, but thought i'd mention it just in case :)
<mborzecki> Chipaca: zyga: we need to update the list of syscalls in cmd/snap-seccomp/syscalls/syscalls.go, apparently upstream was updated
<jdstrand> Chipaca: I was curious, yes. also curious cause this shouldn't have happened unless the kernel changed iirc how the test was written
<jdstrand> but I may be forgetting the test
<jdstrand> oh, 3 minutes up. back in a little while
<mvo> pedronis: \o/
<jdstrand> Chipaca: thanks for all the info btw
 * jdstrand is now really gone
<mborzecki> Chipaca: zyga: https://github.com/snapcore/snapd/pull/7709
<mup> PR #7709: cmd/snap-seccomp/syscalls: update the list of known syscalls <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7709>
<mup> PR snapd#7709 opened: cmd/snap-seccomp/syscalls: update the list of known syscalls <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7709>
<jdstrand> oh right, we git clone libseccomp and go from there. nothing to do with the host
<jdstrand> mborzecki: thanks
<jdstrand> ok, really, really gone
<mup> PR snapd#7710 opened: snap-seccomp: add new syscalls after libseccomp update <Created by mvo5> <https://github.com/snapcore/snapd/pull/7710>
<mup> PR snapcraft#2775 closed: remote-build: add clean flag <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2775>
<kenvandine> jdstrand: any thoughts on bug 1661626
<mup> Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged by marcustomlinson> <https://launchpad.net/bugs/1661626>
<mup> PR snapd#7710 closed: snap-seccomp: add new syscalls after libseccomp update <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7710>
<zyga> AFK with kids now
<cachio> zyga, hey
<cachio> zyga, snap-seccomp-syscalls test is failing and reading the comments in the test it sayts
<cachio> # both lists should be identical, otherwise we need an update in snap-seccomp
<cachio> any idea on how to update snap-seccomp?
<Chipaca> cachio: PR already up
<cachio> Chipaca, nice, thanks
<Chipaca> cachio: https://github.com/snapcore/snapd/pull/7709
<mup> PR #7709: cmd/snap-seccomp/syscalls: update the list of known syscalls <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7709>
<cachio> Chipaca, I'll merge it once the tests pass
<cachio> it has 2 +1
<Chipaca> cachio: only if i don't merge it first :-p
<cachio> hhehee
<zyga> Iâm upstairs with now sleeping Lucy
<zyga> Maciek made the same patch but found the upstream commit so kudos to that
<zyga> Letâs mere it
 * pstolowski afk
<Chipaca> zyga: just got my first trick-or-treaters *ever*
<Chipaca> and, i must admit i did not tell them to go away
<noise][> nice, did you give them snapcraft stickers orâ¦ ?
<Chipaca> noise][: i gave them support tickets that were older than they were
<Chipaca> nah, i panicked and gave them some m&ms
<Chipaca> i've been in this house 3? maybe 4 years and this is the first time they've knocked
<noise][> m&ms was the right call
<mup> PR snapcraft#2787 opened: Safe grade <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2787>
<mup> PR snapd#7711 opened: seed: test and improve Core 20 seed handling errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/7711>
<mup> PR snapd#7712 opened: seed: support in Core 20 seeds local unasserted snaps for model snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7712>
 * cachio EoD
<mup> PR snapd#7713 opened:  seed: Core 20 seeds channel overrides support for grade dangerous <Created by pedronis> <https://github.com/snapcore/snapd/pull/7713>
<mup> PR snapd#7709 closed: cmd/snap-seccomp/syscalls: update the list of known syscalls <Simple ð> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7709>
#snappy 2019-11-01
<mup> Bug #1671266 opened: rfkill should be included in the core snap <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1671266>
<mup> PR snapd#7690 closed: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7690>
<mup> PR snapd#7714 opened: overlord: refactor mgrsSuite and extract kernelSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7714>
<mvo> pedronis_: a review for 7682 would be great. then I could use the helpers there for the base->bsae undo tests
<mvo> pedronis_: actually - 7701 (smaller) is enough :)
<pedronis> mvo: hi, yes, I wanted to ask which one of those I should review first? because the newer was merged into the older?
<mvo> pedronis: yeah, the newer one is probably the best starting point
<mvo> pedronis: so 7701 is probably the best start, its relatively small
<pedronis> mvo: I'll look now,  I was trying to give input on some older PRs that were stuck
<zyga> good morning
<zyga> hey mvo, pedronis
<zyga> how are you doing this frosty morning?
<mvo> hey zyga ! doing well
<pedronis> mvo: I reviewed 7701
<mvo> pedronis: thank you!
<pedronis> zyga: hi, did you see my question in #7700 ?
<zyga> not yet
<mup> PR snapd#7715 opened: overlord: add base->base remodel undo tests and fixe <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715>
<mup> PR #7700: many: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<mvo> pedronis: I pushed base->base remodel undo but it needs all the other ones first but at least I think we are complete in the sense that we have code written :)
<mvo> pedronis: thanks a bunch for the review!
<zyga> @pedronis I yeah, I thought about this and I think it may need to be in /var after all
<zyga> @pedronis I got into a longer exploration of the problem of locking
<pedronis> ok
<zyga> @pedronis I tried to document that in the doc but I need to remove redundant parts and make the whole thing comprehensible
<pedronis> mvo: this test seems also to have that kind of name:  TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart
<zyga> wow that's a long name :)
<mvo> pedronis: yeah, fixing all of the UpdatesBootloader ones now
<mvo> zyga: its a long test! needs a long name :)
<zyga> mvo: ChapterOne
<zyga> ;-)
<mvo> zyga: *if* you work today a review for 7651 would be great
<zyga> sure, let me start with that
 * zyga reads the spec first
<pstolowski> morning
<zyga> hey pawel
<pstolowski> pedronis: i'm changing PreseedMode to func, no strong opinion either way
<pstolowski> zyga: would you find a moment for #7675? i'd like to get it out of the way as it's a base for other PRs
<mup> PR #7675: release: preseed mode flag <Prebaking ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
<zyga> pstolowski: gladly, just after the current one
<pedronis> mvo: there's a problem with the download via snapd stuff
<mvo> pedronis: oh?
<pedronis> mvo: you get polkit prompts
<pedronis> which I'm not sure we want
<pedronis> for this
<zyga> oh?
<mvo> pedronis: oh, meh, yes. downlaod is an auth endpoint :/
<zyga> because of snapd asking polkit?
<mvo> pedronis: that sounds like we need some flag to prevent interaction
<mvo> zyga: yeah
<Chipaca> pedronis: yesterday I suggested landing the current download but with the defaults flipped
<pedronis> mvo: well, we might need to change the auth rules for the /download endpoint
<Chipaca> ie having direct being the default, with a hidden --indirect flag
<mup> Issue core18#142 opened: Stuck with blank screen on snap-core 18 Raspi 3 B+ install <Created by bernermic> <https://github.com/snapcore/core18/issue/142>
<pedronis> Chipaca: just to progress? because that's not the final goal
<Chipaca> pedronis: just to progress, yes
<Chipaca> pedronis: otherwise i see this being an open pr for quite some time, across vancouver
<jamesh> Chipaca: re. https://github.com/snapcore/snapd/pull/7589, are you happy with pedronis's suggestion for "snap routine"?  I'm fine with it myself.
<mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<pedronis> Chipaca: isn't just a matter to remove this from download ?  PolkitOK: "io.snapcraft.snapd.manage",
<Chipaca> jamesh: heh, i'm terrible with names, but let me respond over there
<pedronis> I don't think it's actually a mgmt action (in those terms) anyway
<pedronis> mvo: ^
<mvo> pedronis: hm, good point, that is probably fine
<mvo> Chipaca: beside better tests (I pushed two prs recently) and resume-partial is there anything missing from the snap download via snapd?
<pedronis> mvo: also ./snap0 known --remote account account-id=dell gives me nothing (no error either), but --direct works
<pedronis> mvo: something is off
<pedronis> with known too
<mvo> pedronis: uh, let me debug this
<pedronis> mvo: you pushed a 2.42.1 to edge?
<pedronis> that will roolback people
<mvo> pedronis: I did not, that was our stupid machinery not being updated :(
<mvo> pedronis: let me fix this, but it sounds like one of the auto-merge/auto-build bits failed
<pedronis> so my snapd doesn't have remote on /assertions
<pedronis> I suppose
<Chipaca> mvo: more real-life testing?
<mvo> Chipaca: good point :)
<Chipaca> mvo: i'd like to have a whole .N of us using it to help us find the bugs
<Chipaca> but I'd also like people to stop being horrible to each other, and here we are
<mvo> Chipaca: we will have the entire 2.43 for people to test :)
<mvo> pedronis: I can reproduce the dell issue, debugging now
<mvo> Chipaca: wdyt about removing pollkitOk from /v2/download ?
<Chipaca> mvo: nah
<Chipaca> mvo: just tell it to not do interactive
 * Chipaca looks for how to do that
<Chipaca> mvo: client.Config{Interactive: false}
<Chipaca> mvo: turns off polkit for that request
<Chipaca> bah, for any request that client emits
<mvo> Chipaca: \o/
<Chipaca> mvo: you owe jamesh a beverage
<mvo> pedronis: snap-vendor-sync repo is 40h behind, this is controlled via spread-cron, I need to check with sergio what is going on there :(
<pedronis> mvo: ok
<jamesh> mvo: the Client instance set up by the snap command sets Interactive based on whether stdin is a tty
<jamesh> in general it is going to do the right thing for non-interactive scripts
<Chipaca> mvo: jamesh: cmd/snap/main's mkClient could take a ClientConfig to override that though
<pedronis> yea, for download I think the regression is still annoying even interactively
<pedronis> we are not starting from scratch here
<jamesh> Chipaca: presumably you could just do client.Interactive = false within the command
<jamesh> I don't think anything would be using the client after the command takes control of execution
<Chipaca> degville: could / should we add a list of supported architectures to https://snapcraft.io/docs/architectures ?
<degville> Chipaca: yes, I think so - I've actually got a list in my edit, taken from build.snapcrraft.io.
<Chipaca> degville: i was just looking for that list :-)
<Chipaca> there's somebody trying to build a MIPS core image
<Chipaca> seems like they've spent some time on it already
<Chipaca> (not very effectively)
<degville> Chipaca: these are the ones I've got - s390x, ppc64el, arm64, armhf, amd64, i386.
<mvo> pedronis: I can reproduce this if I have 2.42.1 snapd and a snap client from master. snap client will sent "remote=true" to snapd but the old snapd does not know this header and returns nothing (but also no error). switching to the real edge snapd fixes this (I got reverted to 2.42.1 apparently)
<zyga> mvo: can we nuke the vendor sync repo and use github actions?
<zyga> mvo: and perhaps build the thing with github actions in a way that allows us to have the real git sha in the snap version?
<mvo> zyga: maybe, that would certainly be nice
<zyga> mvo: yeah, worth trying at least
<mvo> zyga: yes! unfortunately not today
<zyga> nope
<zyga> I don't even know if actions are out of beta yet
<zyga> I have access on my repos but I was given access ahead of general release a while ago
<pedronis> mvo: ok, at least this bit is understood, yes I got edge with 2.42.1 here too
<jamesh> github actions are so much nicer to deal with than travis
<jamesh> I've been using them on some of my personal repos too
<zyga> jamesh: that's good indicator to use them
<zyga> thanks!
<jamesh> zyga: here were my initial thoughts on the system: https://blogs.gnome.org/jamesh/2019/09/06/exploring-github-actions/
<pedronis> jamesh: I answered to John comment in #7589
<mup> PR #7589: cmd/snap: add ability to register "snap internal" commands <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<pedronis> I think we do have a path forward
<jamesh> pedronis: thanks.  For the user session systemd branch, I don't think timers and sockets need any special handling.  I put my reasoning in a comment on #7238
<mup> PR #7238: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7238>
<pedronis> jamesh: yea, I'll do a pass again on it today, then either way it will need a re-review by jdstrand
<pedronis> jamesh: btw I'm off next week
<jamesh> okay.  Thanks
<pedronis> jamesh: the fwupd one is also unblocked, it just needs a 2nd review and to get green
<mvo> pedronis, Chipaca I updated the code in 7624 to not have a polkit prompt anymore (set interactive to false)
<pstolowski> pedronis: hey, i've added a separate firstbootPreseed16 suite to yesterday's PR. one remaining "annoyance" is the copy of two helpers (makreCoreSnaps + makeSeededChange - the latter with only minor change), maybe they should be made more general to be reused by two *16 suites - although moving them to firstBoot16Suite would probably go too far since they set up specific test data. slightly on the fence about what to
<pstolowski> do about them
<pedronis> pstolowski: sorry, what is the problem? that they are *16 specific?
<pedronis> pstolowski: did you forget to add a file?
<pedronis> this diff is strange https://github.com/snapcore/snapd/pull/7705/commits/fdd697d3b89cab1101b8adbd04f082d32b3aa27e
<mup> PR #7705: [WIP] o/devicestate: handle preseed in firstboot <Prebaking ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<pstolowski> pedronis: yes i forgot the file in that one commit. look at the next commit or complete diff
<pedronis> pstolowski: so makeSeedChanges has actual differences
<pstolowski> pedronis: yes, but minor, different checkTasks* used
<pedronis> you can make a firstBoot16BaseTest with seedtest and those two? no?
<pedronis> I mean with seedtest.TestingSeed16
<pedronis> if you want
<pedronis> makeCoreSnap could be a global helper that takes a *seedtest.TestingSeed16
<pedronis> makeCoreSnaps
<pstolowski> pedronis: yes, i can do something like this
<pedronis> pstolowski: I don't strong opinions on this, need to try a bit what is readable in the end
<pedronis> I wouldn't do is chain them though firstBoot16BaseTest shouldn't contain firstBootBaseTest
<pedronis> and maybe firstBoot16BaseTest is not the best name for that one
<pedronis> pstolowski: otoh all the new tests have a slightly different style that makes something like makeCoreSnaps a bit less necessary
<pedronis> so maybe we should change to that at some point
<pstolowski> pedronis: i can also postpone these changes for a followup maybe (when you're back)?
<mvo> Chipaca: if you feel like reviewing, 7701 would be a nice one
<pstolowski> pedronis: will you find a moment today to take a look at #7706?
<mup> PR #7706: overlord/snapstate: install task edges <Prebaking ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7706>
<Chipaca> mvo: reviewing is all there is
<Chipaca> mvo: but first more coffee
<Chipaca> maybe a bite to eat as well
<jdstrand> jamesh, pedronis: re 7238, it's on my list
<zyga> hey jdstrand :)
<jdstrand> hey zyga :)
<pstolowski> i'm going afk for now. i'll check later if my #7675 can land and rebase the rest if needed
<mup> PR #7675: release: preseed mode flag <Prebaking ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
<zyga> o/
<mvo> Chipaca: sounds like a great plan!
 * mvo contemplates food as well
<mup> PR snapd#7708 closed: parts/plugins: don't xz-compress a deb we're going to discard <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7708>
<pedronis> pstolowski|afk: sorry, needed to run to have lunch
<zyga> pedronis: https://github.com/snapcore/snapd/pull/7651#pullrequestreview-310392093
<mup> PR #7651: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7651>
<zyga> pstolowski|afk: looking at your PR now
<zyga> pstolowski|afk: https://github.com/snapcore/snapd/pull/7675#pullrequestreview-310427961 (though not what you may have expected)
<mup> PR #7675: release: preseed mode flag <Prebaking ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675>
 * zyga breaks for quick tea
<zyga> it's soooo cold at home today
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/7659 should be ready now
<zyga> jdstrand: it's just the extra feature flag you asked for
<mup> PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>
<zyga> jdstrand: I'm looking at expanding spread test to cover that, just looking where to put it
<jdstrand> zyga: ok, thanks
<kenvandine> jdstrand, zyga: any thoughts on marcustomlinson's findings on bug 1661626 ?
<mup> Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged by marcustomlinson> <https://launchpad.net/bugs/1661626>
<zyga> kenvandine: no, it seems like a mess now :/
<zyga> kenvandine: feels like gsettings really needs a portal / proxy
<zyga> kenvandine: do you think there's a simple solution for all of this?
<kenvandine> there is a settings proxy, not sure the state of it though
<kenvandine> s/proxy/portal
<kenvandine> https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml
<zyga> kenvandine: how can we use this?
<zyga> I mean
<jdstrand> zyga: this is what jamesh and I briefly chatted about in the plenary room as a side discussion after a meeting. there is stuff we can probably do here, but not immediately. he summarized that discussion in the forum somewhere
<kenvandine> but that seems to be read access to the host settings
<zyga> does it need gtk change to software to use that vs doing what they needed before
<zyga> or is this some transparent proxy where we hack around and inject it and software is unmodified
<kenvandine> i don't think it helps for an app with it's own schema
<jdstrand> but that was for per app settings, not global settings now that I type that
<kenvandine> the per app is the issue here, at least this bug
<kenvandine> if i'm reading it right
<marcustomlinson> bare in mind that set and get work just fine, it's just the monitor that is broke
<kenvandine> marcustomlinson: right?  this is an app not getting change notificiations for it's own settings?
<zyga> marcustomlinson: who sends the signal?
<kenvandine> yeah, it seems to be all related to the XDG_RUNTIME_DIR
<marcustomlinson> zyga: shrug
<zyga> I'm not experienced in the desktop stack
<zyga> I cannot help without someone who knows how this works
<kenvandine> i think the app's process
<zyga> would it help if we had not modified xdg runtime dir?
<kenvandine> zyga: i think so
<kenvandine> maybe this is a bug in the helpers?
<zyga> sounds like someone needs to deep dive into this
<jdstrand> but, we can probably just add another symlink for now from $XDG_RUNTIME_DIR/dconf -> ../dconf
<zyga> I really don't know
<marcustomlinson> jdstrand: I did try that, didn't work
<zyga> my meta observation is as follows:
<kenvandine> jamesh: are you by chance still around?
<jdstrand> marcustomlinson: oh? did dconf remove it?
<zyga> I think it would be healthier for the process if instead of in the helpers this was a part of snapd's preparation of /run, when some sort of interface is used
<marcustomlinson> jdstrand: no didn't remove it, perhaps permission issue not sure
<zyga> it would teach the snapd team more a
<zyga> and it would help in fixing "what happens" part of the problem, because we have many layers
<jdstrand> marcustomlinson: a snap that plugs gsettings can acces /run/user/*/dconf, so a symlink to it should be fine
<marcustomlinson> jdstrand: well it wasn't :D
<jdstrand> marcustomlinson: ok... that isn't a lot of detail ;)
<marcustomlinson> jdstrand: I asked for assistance
<marcustomlinson> not for ears to hear the solution
<jdstrand> marcustomlinson: but, /run/user/*/dconf is different than ~/.config/dconf, so maybe it doesn't have to do with XDG_RUNTIME_DIR at all?
<jdstrand> marcustomlinson: I'm not sure what you mean be that, but if you are implying I am not trying to assist, you are wrong
<zyga> marcustomlinson: we can help with the confinement but we need someone to understand how the desktop side works well and design how it ought to work with isolation in place
<marcustomlinson> I don't have a lot of detail
<mup> PR snapd#7651 closed: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7651>
<kenvandine> i think we probably need jamesh
<marcustomlinson> zyga: yes which is what I said in my comment
<jdstrand> but if I'm being asked to look at this to investigate the whole issue rather than provide pointers to someone who will, I'll but it in backlog
<kenvandine> jdstrand: nah, i think we need jamesh to look at it
<mup> PR snapd#7695 closed: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7695>
<marcustomlinson> kenvandine: I'm happy to press on with it if you like
<pedronis> pstolowski|afk: #7695 has landed which should help with your PR
<marcustomlinson> I just saw a rabbit hole approaching and thought I'd reach out first
<mup> PR #7695: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7695>
<kenvandine> marcustomlinson: i'm betting james could point to the problem pretty quickly
<kenvandine> it's in his wheelhouse
<marcustomlinson> agreed
<jdstrand> marcustomlinson (cc kenvandine, jamesh): do note that outside of snaps, there is a /run/user/1000/dconf dir and a ~/.config/dconf dir (I know you know that, but bear with me). does an unconfined non-snap get out of sync?
<kenvandine> jdstrand: i do not think they do
<jdstrand> marcustomlinson (cc kenvandine, jamesh): I ask cause while we do the symlink trick from SNAP_USER_DATA to ~/.config/dconf, we apparently aren't for XDG_RUNTIME_DIR/dconf to /run/user/1000/dconf
<jdstrand> and to me that is interesting
<kenvandine> jdstrand: yeah, that is interesting
<marcustomlinson> jdstrand: no installing with --devmode doesn't fix it
<kenvandine> it doesn't feel like confinement
<jdstrand> iirc, and this is from *long* ago, the /run stuff was a perf optimization for fast reads. part of that optimization may be how it opens the file, or harrdoces a path, or something else
<kenvandine> i think it has to do with monkeying with paths
 * jdstrand does know otoh
<jdstrand> marcustomlinson: no, I wasn't talking about --devmode. I was talking about a non-snap
<jdstrand> vs a snap that has XDG_RUNTIME_DIR, $HOME, etc set
<marcustomlinson> jdstrand: a non-snap doesn't fall out of sync as said in the bug description
<jdstrand> the security policy should allow access to everything, but that doesn't mean dconf is going to the right places. that is all I'm saying
<kenvandine> i'm going to get jamesh to take a look
<jdstrand> jamesh: please see backscroll to see if that sparks any ideas
<pstolowski|afk> pedronis: great, ty
<jdstrand> kenvandine: thanks :)
 * zyga breaks for lunch 
<zyga> see you at the standup
<jdstrand> s/does know/doesn't know/
<jdstrand> kenvandine, marcustomlinson, jamesh: I gave my thoughts in the bug
<kenvandine> jdstrand: thanks!
<kenvandine> jdstrand: can you assign it to jamesh?  I can't seem to choose people to assign the snapd bugs to
<jdstrand> kenvandine: sure, done
<zyga> spread running
<zyga> jdstrand: I'm trying your suggestion on lxd
<kenvandine> jdstrand: thanks
<zyga> jdstrand: if it works I'll file a bug with the LXD team to update their templates
<zyga> claudio is not on irc?
<zyga> I wanted to correct my statement, the destkop has four microphones, not seven
<jdstrand> pedronis: oh, 7651 got committed while I was reviewing. there are no blocking comments from me, but please consider the feedback given
<marcustomlinson> jdstrand: thanks, well said
<jdstrand> marcustomlinson: yw :)
<pedronis> jdstrand: thanks, probably after I'm back at this point. I addressed some that were shared with zyga's here:
<pedronis> https://github.com/snapcore/snapd/pull/7652/commits/3e9a7ebe67bc054e7613489b0bcbd0e1eb9713a6
<mup> PR #7652: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652>
<pedronis> zyga: the follow ups ^
<zyga> looking
<jdstrand> pedronis: sure, just wanting to make sure you saw it. not sure since it was merged by the time I finished my review if you would
<mup> PR snapd#7716 opened: interfaces/lxd-support: Fix on core18 <Created by stgraber> <https://github.com/snapcore/snapd/pull/7716>
<zyga> ^ simple quick review
<zyga> pedronis: do you want it reviewed today?
<zyga> pedronis: or is Monday ok?
<pedronis> zyga: the entire PR ? that's a question for mvo
<zyga> yes
<zyga> the comments are good, thank you for them!
<jdstrand> 7716: approved
<zyga> stgraber: is that needed urgently?
<zyga> I kind of wish that one liner could be a .2 in a day or two
<mvo> zyga: the pr 7716? monday is ok
<mup> PR #7716: interfaces/lxd-support: Fix on core18 <Simple ð> <Created by stgraber> <https://github.com/snapcore/snapd/pull/7716>
<zyga> mvo: no, the bigger one - 7652
<zyga> mvo: I reviewed 7716 arlready
<mvo> zyga: monday is still ok, I will try to do a first pass myself today
<pedronis> jdstrand: I don't completely understand the warn/log comments
<jamesh> kenvandine, jdstrand, marcustomlinson: the settings portal is not intended for application settings: instead it is intended to share desktop settings (e.g. theme name, font choice, etc) with the sandbox
<jdstrand> pedronis: I might've been a bit terse, but the idea is that if someone uses '2', should we bubble that up instead of being silent
<stgraber> zyga: we'll want that in all distros ASAP, but I'm expecting it to take months to fully roll out again :(
<zyga> mvo: ^
<zyga> too bad we just did a .2
<zyga> stgraber: if you want we can push that to fedora and opensuse quickly
<pedronis> jdstrand: I see, but it's the machine, and the  one setting is in the store
<pedronis> jdstrand: it feels more confusing than helpful tbh
<stgraber> zyga: those two would be nice, our main blocker last time around was centos7
<jamesh> kenvandine: The plan upstream is to not have sandboxed apps talk to dconf at all.  If you have a new enough glib and set GTK_USE_PORTALS=1 it will store app settings to ~/.config/glib-2.0/settings/keyfile, which will be private to the snap
<zyga> stgraber: it would be good to run the lxd test on more places
<mvo> stgraber: if its really important we can do a 2.42.2 just with this
<zyga> stgraber: centos7 should be fast too nowadays
<stgraber> zyga: looks like thye only got >= 2.40 earlier this week
<zyga> stgraber: I'll raise this with mborzecki and mvo on Monday
<jdstrand> pedronis: that's fine
<zyga> (mborzecki is off today)
<kenvandine> jamesh: that's what i thought.  can you look for a solution to the current issue in that bug report?
<zyga> jamesh: I was thinking about one thing
<mvo> stgraber: we don't always get quick turnaround on SRUs unfortunately, thats true
<zyga> jamesh: could we have a service that steals part of the traffic so that gsettings is running through a new proxy which runs unconfined as the user
<mvo> vorlon: you are mentioned in the stable-release-udpates page for today, do you think you could have a look at the snapd sru maybe?
<stgraber> mvo: our own CI now records what the snapd version was on all the distros we test, so it's pretty easy for us to block work until the version we want is available on the distros we care the most about but yeah, it can be high latency and we completely missed the broken interface until right when we were about to push to edge...
<jamesh> zyga: what would that offer over the keyfile solution?
 * cachio lunch
<zyga> jamesh: not sure yet, I think if we had a more-less generic middleware that could do some logic and forward the call we could handle more dbus APIs sanyl
<zyga> *sanely
<kenvandine> confinement isn't the issue though
<zyga> kenvandine: it kind of is, if we had no xdg runtime dir changes we'd be okay
<zyga> but we do for confinement
<zyga> and get/set api is not scoped to what a given snap can and cannot do
<zyga> if we had a way to run code on each of those
<jamesh> zyga: the design of dconf (and gconf before it) was to store every application's settings in a common data store.  It's not obvious that we want to do that when sandboxing applications
<zyga> we could do something smart
<zyga> jamesh: I think that is fine as long as mmap is gone
<zyga> jamesh: and as long as we can limit get/set
<zyga> jamesh: (which we cannot today)
<zyga> jamesh: anyway, it's just an idea, I wanted to know what you think
<jamesh> zyga: there are only a small number of settings we want to share (themes, fonts, etc), but everything else can be private to the app
<zyga> jamesh: that's true and that's fine
<zyga> jamesh: it means it should be easy to express
<jamesh> zyga: so we store application settings in a file that ends up in $SNAP_USER_DATA, and have the portal for the shared settings
<jdstrand> jamesh: for what it is worth, I think the keyfile idea is very good. I also think that the concept of sometime soon(ish) bind mounting /run/user/uid/snap.... onto /run/user/uid and adding in what we want to expose, leaving XDG_RUNTIME_DIR as /run/user/uid, is going to solve a lot of things
<jamesh> no need for a config access daemon with ACL support
<zyga> jamesh: sure, but again, this is just an excuse to try out an idea in our heads: we could use this for gsettings, for network-manager and perhaps for more dbus things later on
<jdstrand> zyga: we've discussed a dbus proxy in the past, I don't think we have a compelling use case that justifies the dev resources and risk at this point
<kenvandine> jamesh: i think we should add GTK_USE_PORTALS=1 to the  WIP gnome-3-34 snapcraft extension
<jdstrand> we have a lot with just apparmor without having to look at member data
<jdstrand> but, yes, it we really required member data mediation, we would have to come up with something
<zyga> jdstrand: odd
<zyga> I didn't have /var/snap/lxd/common/lxd/security/apparmor/profiles/lxd-my-ubuntu
<zyga>  
<zyga> in the test
 * zyga tries 16.04 
<zyga> I was running on 18.04
<zyga> no apparmor profile created by lxd?
<jamesh> zyga: there is work upstream to add connection filtering to dbus-daemon itself.  I'm not sure of the status, but I did participate in the bug reports to make sure it wouldn't be too impossible to use with snaps
<zyga> mmm, I recall some of this
<zyga> that's good
<zyga> well, just a thought
<jamesh> zyga: the basic idea was to ask dbus-daemon to create a new listening socket, and tag all connections made through that socket
<jamesh> a policy would be applied that would limit the bus names those connections could see, and what messages they could send and receive
<pedronis> mvo: is 7701 merged ?
<zyga> pedronis: doesn't seem to be
<jdstrand> jamesh: thanks for keeping an eye on that btw :) it would be a bit unfortunate to have both it and apparmor in place and deciding when/how to use what, etc, etc, but yes, what you described is something we can work with
<zyga> hmm
<zyga> stgraber: where does lxd store apparmor profiles?
<stgraber> zyga: /var/snap/lxd/common/lxd/security/apparmor
<zyga> oh, I'm silly
<zyga> thanks, it's all there now
<zyga> ETOOMANYNAMESPACES
<zyga> thank you!
<pedronis> pstolowski|afk: gave a couple of comments in 7706
<mvo> pedronis: 7701 needs a second review - I guess it could be merged with one given that its mostly test updates
<zyga> mvo: go for it
<mvo> zyga: go for the merge?
<zyga> yes
<pedronis> mvo: it would give me a chance for me to try to review the next one
<mvo> pedronis: +1
 * zyga strongly believes in trust and asking for forgiveness more than permission
<mup> PR snapd#7701 closed: overlord: add kernel rollback accross reboots manager test and fixes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7701>
<mvo> pedronis: 7682 is now ready for review as well
<pedronis> mvo: taking a break and after I'll see where I'm at on the things to finish stuff
<pedronis> s/stuff/list/
<mvo> pedronis: sure, thank you!
<mvo> Chipaca: can 7669 be merged? has two +1
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/7547#issuecomment-548788685
<Chipaca> mvo: 'needs samuele review' :)
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<pedronis> mvo: actually it should be closed, I think Chipaca's prefers next one
<pedronis> but there is a question answered
<pedronis> that related whether we should pick one or the other
 * zyga tries another approach
<Chipaca> yes, i slightly prefer 7670
<Chipaca> oh, answered?
 * Chipaca looks
<pedronis> sorry, unanswered
<pedronis> Chipaca: is this one: https://github.com/snapcore/snapd/pull/7680#discussion_r339552372
<mup> PR #7680: daemon: parse and reject invalid channels in snap ops <Channels ð·ï¸> <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7680>
<Chipaca> ah!
<Chipaca> pedronis: answered! closing 7669
<Chipaca> and adding comments to 7670 to land it
<Chipaca> thanks
<Chipaca> missed these somehow
<Chipaca> bah, i know how -- inbox 0 it isn't
<pedronis> it's ok, I just thought your were pausing these and get back later
<pedronis> they have some comments from me
<jdstrand> zyga: :(
<pedronis> Chipaca: yea, please close 7669
<mup> PR snapd#7302 closed: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302>
<jdstrand> zyga: but boy, glad we thought to test before rolling out :)
<zyga> yes
<zyga> thank you!
<zyga> mvo: this remained unaddressed https://github.com/snapcore/snapd/pull/7302#discussion_r341178203
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302>
<zyga> mvo: but I'll work with maciek to make it better
<mvo> zyga: ok
<mvo> zyga: yeah, its fine to enable during 2.43 lifetime in edge at least
<mvo> zyga: topic for monday and a detail in some way! thanks for the suggestion though
<zyga> stgraber: question about mount in lxd
<zyga> stgraber: lxd performs syscall interception for it now?
<zyga> stgraber: is there some logic that allows systemd inside the container to mount cgroups?
<stgraber> It will be able to in 3.19
<zyga> stgraber: or are cgroups mounted in some other way
<zyga> stgraber: the context is this:
<zyga> stgraber: snapd needs to mount a new cgroup hierarchy
<zyga> stgraber: a name=snapd one, with no controllers
<mvo> pedronis: 7438 is probably now also unblocked, but I leave this to you, your review list is very long so its fine if it gets dropped
<stgraber> Right now we don't intercept anything
<zyga> stgraber: I see
<zyga> stgraber: I will explore more, I'm getting EPERM now but I'll check more why
<stgraber> It's just normal userns+mntns and the kernel allowing you mounting safe virtual filesystems
<pedronis> mvo: yea, don't think I will get to that one
<zyga> stgraber: does that include cgroups?
<stgraber> cgroupfs is definitely one of those
<zyga> stgraber: I'm not experienced with userns
<zyga> ok
<zyga> I see, thanks, I'll explore more interactively
<stgraber> systemd in the container handles mounting it so it has to be unprivileged
 * zyga is making progress
<mup> PR snapd#7669 closed: snap, cmd/snap: support (but warn) deprecated multi-slash channel <Channels ð·ï¸> <Needs Samuele review> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7669>
<pedronis> mvo: Chipaca: there is no progress bar in snap download ?
<Chipaca> pedronis: there is
<pedronis> I'm not seeing it
<pedronis> or it's only when is not direct ?
<Chipaca> pedronis: what are you running
<pedronis> I'm running direct
<pedronis> I'm running mvo 7624
<mvo> pedronis: try a bigger snap
<mvo> pedronis: maybe core?
<mvo> pedronis: I did not see it for small snaps like test-snapd-tools myself
<mvo> pedronis: and then I did not implment one in the first iteration because I was blissfully unware of it :/
<Chipaca> ah you might not see it if there is no progress before it's done :)
<ijohnson> hey folks o/
<zyga> ijohnson: hey
<ijohnson> lots happening this morning it seems :-) anything in particular I can help with or review, etc. ?
<zyga> ijohnson: I think reviews are in demand
<zyga> ijohnson: mvo can point you the way
<ijohnson> it would appear so :-)
<mvo> ijohnson: 7652, 7696 would be good and 7665
<ijohnson> mvo ack
<mvo> ijohnson: probably more, but this should keep you busy :)
<mvo> ijohnson: and *thank you*
<ijohnson> happy to help :-) (also good to take a break from staring at why the chromium snap is slow)
<ogra> zyga, ubuntu-core-meta is the metapackage generated from the seed that is defining the package list ... should be owned by foundations nowadays (sorry, only just returned from IoT worldcongress and wasnt able to check IRC)
<ogra> zyga, i think sil2100 or vorlon own it now
<zyga> ogra: ah, so it's a real thing
<zyga> thank you
<pedronis> mvo: added a couple of comments to 7624, I removed the needs my review, I think is far along enough and shouldn't be blocked, but it will need a revisit at some point
<mvo> pedronis: cool, thank you!
<pedronis> mvo: the fallback to direct without sudo or auth works
<pedronis> mvo: as John said a bit more manual testing is probably in order
<mvo> pedronis: indeed, I also want to add some more unit tests
 * zyga breaks
<mup> PR snapd#7717 opened: tests/docker-smoke: add minimal docker smoke test <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7717>
<ogra> zyga, well, the seeds surely are since we are using the osfficial build system now, not sure if the metapackage is actually needed, the build of core18 might just use the task which wouldnt require a metapackage anymore
<ogra> s/core18/core18 and onwards/
<Chipaca> pedronis: #7696 LGTM
<mup> PR #7696: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7696>
<pedronis> Chipaca: thanks, it has a bug though
<Chipaca> pedronis: I saw, about classic?
<pedronis> yes
<Chipaca> pedronis: hm
<pedronis> because of the moving of setting up the directory
<pedronis> from the cmd_* to the image
<pedronis> it got lost, and the unit test didn't notice
<pedronis> I'll try to push a fix later tonight
<pedronis> otherwise you or mvo should fix it next week
<Chipaca> pedronis: no probs
<Chipaca> pedronis: lots of spread tests caught it instead :)
<pedronis> Chipaca: basically  for core  we create PrepareDir/image and use it as root
<pedronis> that's correct
<pedronis> Chipaca: for classic PrepareDir is really the root dir already
<pedronis> so no /image should be added there
 * Chipaca nods
<pedronis> and boot stuff is not relevant for classic anyway
<pedronis> also to be clear we don't have uc20 model/classic support yet
<pedronis> classic is uc 18/16 style seeds
<pedronis> for now
<diddledan> has snapd moved out of the core snap now?
<diddledan> I installed a fresh ubuntu vm and then a snap that depends on core18 and I received snapd via the snapd snap instead of the core snap via autoinstall
<pedronis> diddledan: yes for fresh installs
<diddledan> aah, only fresh installs. gotcha
<Chipaca> diddledan: and only if the first snap you install doesn't use core :)
<pedronis> diddledan: we do plan to migrate old classic system (like at some point we migrated from ubuntu-core -> core), but it isn't enabled yet
<Chipaca> ijohnson: the spread tests on that pr also failed because if the image/ thing samuele mentioned, fwiw
<pedronis> ?
<pedronis> only my PR should be affected
<pedronis> now I'm confused
<Chipaca> pedronis: yep, talking about that
<pedronis> ah
<Chipaca> pedronis: ijohnson said, on your pr, âlooks like the spread tests failed from some store 403s :-/â
<ijohnson> Oh sorry I just saw that like 4 tests failed on 403s and assume the rest of them were from similar problems
<Chipaca> pedronis: so i thought before he restarts them maybe i should point out that at least some of them are genuine (enough that i didn't notice the 403 ones he mentions)
<ijohnson> I didn't restart them
<Chipaca> ijohnson: \o/ :)
<ijohnson> I assumed y'all wanted to look
<pedronis> yea, I will fix later tonight
<ijohnson> Cool beans
<pedronis> Chipaca: anything you need my input on?
<Chipaca> pedronis: oh, just everything
<Chipaca> pedronis: :-D
<Chipaca> pedronis: seriously, no
<pedronis> jdstrand: thanks you for reviewing 7652
<pedronis> Chipaca: ijohnson: I pushed a fix to 7696, spread should tell us if I got it right, but please double check it makes sense
<Chipaca> will do
<ijohnson> Ack
 * ijohnson lunches
<jdstrand> pedronis: yw
<pedronis> jdstrand: I might try to still apply the rest of your previous PR feedback and this one today
 * pedronis dinner
<Chipaca> pedronis: // Core 16/20,  writing for the writeable partion
<Chipaca> 16/18*
<Chipaca> :)
<Chipaca> pedronis: buen provecho, and have a lovely holiday
<pedronis> Chipaca: oops
<Chipaca> pedronis: :)
<mup> PR snapcraft#2787 closed: Safe grade <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2787>
<mup> PR snapcraft#2788 opened: Release changelog for 3.9.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2788>
 * zyga returns
<vorlon> ogra, zyga: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-meta/+bug/1850538 - what is referencing ubuntu-core-meta?
<mup> Bug #1850538: Please remove ubuntu-core-meta from the archive <ubuntu-core-meta (Ubuntu):Fix Released> <https://launchpad.net/bugs/1850538>
<jdstrand> pedronis: hey, I need to update the review-tools to understand (but not do anything with) slots-per-plug and plugs-per-slot and wanted to make sure about something.
<jdstrand> pedronis: say the base decl has:
<jdstrand> slots:
<jdstrand>   foo:
<jdstrand>     allow-connection: false
<jdstrand> pe
<jdstrand> pedronis: and the snap decl has:
<jdstrand> slots:
<jdstrand>   foo:
<jdstrand>     allow-connection:
<jdstrand>       slots-per-plug: 1
<pedronis> jdstrand: first of all you could warn or prohibit initially anything but
<pedronis> allow-auto-connection:
<pedronis>    slots-per-plugs: *
<pedronis> because anything else will just end up being like the default
<pedronis> so it's confusing/distracting
<pedronis> but your call
<jdstrand> pedronis: sure
<pedronis> what's the question here?
<pedronis> that rule in the snap decl
<pedronis> is like  allow-connection: true
<jdstrand> pedronis: yes, that is exactly what I thought and wanted to confirm
<pedronis> and slot-per-plug will behind the scene be normalize away back to *
<pedronis> in snapd
<pedronis> for this specific case
<jdstrand> right. in the review-tools, I want the same evaluation rules as before. I'm only checking arity for syntax/etc
<jdstrand> but due to evaluation rules, in my scenario, I just wanted to double check the intent was allow-connection: true with the above
<pedronis> yes
<jdstrand> pedronis: ok, thanks. if you haven't started yet, enjoy your weekend :)
<jdstrand> and week! :)
<pedronis> thanks
<pedronis> still shepharding some last bits of PRs that I can
 * jdstrand nods
<pedronis> jdstrand: I applied your feedback (except some bits that were more open ended)
<jdstrand> cool, thanks :)
 * cachio afk
<ogra> vorlon, i think that was a core16 bug
<vorlon> ok, core+core16 still referenced ubuntu-core-meta yes
<ogra> https://launchpad.net/bugs/1646144
<mup> Bug #1646144: ACLs to devices need to be supported in core  <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Fix Released by ogra> <ubuntu-core-meta (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1646144>
<zyga> vorlon: I don't know what referenced it, I just noticed it being mentioned here
<ogra> zyga, ah, i thought you were referring to the line above your ping
<ogra> (which was that bug it seems)
<cyphermox> ok, so false alarm?
<ogra> alarm ?
<ogra> there was no alarm, everything is good :)
<cyphermox> ok; just making sure ;)
<mup> PR snapcraft#2789 opened: tests: update the push and release tests for staging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2789>
<mup> PR snapcraft#2790 opened: tests: skip spread tests for rust on s390x <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2790>
 * zyga breaks
<zyga> no progress
<ads20000> jdstrand My journal log is completely flooded with GNOME System Monitor snap denials on Ubuntu 19.04, what interface do I need to enable? `Nov 01 22:29:43 adam-thinkpad-t430 audit[11527]: AVC apparmor="DENIED" operation="open" profile="snap.gnome-system-monitor.gnome-system-monitor" name="/run/systemd/sessions/2"`
<ads20000> I'm pretty sure this is System Monitor out-of-the-box (well, upgraded from previous Ubuntu versions) so perhaps a bit worrying that this has happened out-of-the-box?
<jdstrand> ads20000: yeah, that is on the list for policy updates PR queued for next week
<ads20000> jdstrand: great, thanks! :)
#snappy 2019-11-02
<mup> PR snapcraft#2788 closed: Release changelog for 3.9.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2788>
<mup> PR snapd#7716 closed: interfaces/lxd-support: Fix on core18 <Simple ð> <Created by stgraber> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7716>
<mup> PR snapd#7696 closed: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7696>
<mup> PR snapd#7681 closed: tests: fix for journalctl which is failing to restart <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7681>
<mup> PR snapcraft#2789 closed: tests: update the push and release tests for staging <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2789>
<mup> PR snapcraft#2770 closed: extensions: speed up desktop-launch by not calling mkdir -p <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2770>
<mup> PR snapcraft#2790 closed: tests: skip spread tests for rust on s390x <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2790>
