#snappy 2015-10-05
<zyga> good morning
<zyga> mvo: hey, did you have a safe trip home?
<dholbach> good morning
<fgimenez> good morning
<clobrano> morning o/
<Chipaca> *yawn*
<Chipaca> morning!
<Chipaca> mvo: o/
<mvo> hey Chipaca! good morning
<Chipaca> mvo: welcome back to the world of the living mr mvo!
<Chipaca> mvo: hope you've been able to rest and snuggle the family :)
<mvo> Chipaca: :) thanks! I did and it was very nice. I am currently write down all that I can remember from the sprint
<Chipaca> mvo: good idea. carry on. :)
<mvo> Chipaca: is there anything I can do for you?
<mvo> Chipaca: I guess code reviews?
<mvo> Chipaca: (haven't really looked yet :(
<mvo> Chipaca: I will certainly need a break from spec writing at some point
<Chipaca> mvo: don't worry about it *until* you need that break :)
<Chipaca> i'm in no hurry
<Chipaca> puzzled by things that are nil not being equal :)
<mvo> Chipaca: heh :)
<Chipaca> i've got thing != nil, but thing == (*snappy.SnapPart)(nil)
<Chipaca> *head scratch*
<Chipaca> on the upside, tests are hitting some weird corner cases :D
<mvo> woah
<Chipaca> ah, i know why; thing is an interface
<Chipaca> interface value
<Chipaca> \o/
<JamesTait> Good morning all; happy Monday, and happy Teachers' Day! ð
<dpm> dholbach, it seems now LP can build snaps  http://blog.launchpad.net/general/launchpad-news-september-2015
<dholbach> yep, great news, isn't it? :-D
<dholbach> I'm just finishing my patch pilot shift today, then I'll go and play around with it and then write a blog post :)
<dpm> cool :)
<Chipaca> with bug 1487010 still stuck, that means no race detector for go in wily, right?
<ubottu> bug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/1487010
<squll> Hello, I have a .snap file. We are wondering how to run this?
<mvo> squll: run "snappy install your-snap" on a snappy system, snaps will only work on snappy systems, i.e. http://ubuntu.com/snappy
<Chipaca> mvo: any chance of a review on https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716 ?
<Chipaca> mvo: http://i.imgur.com/UnlYwpF.jpg
<squll> built a snappy file, still no clue on running that
<squll> Anyone got tips?
<Chipaca> squll: how did you build it?
<squll> snappy build .
<Chipaca> squll: and how did you try to run it?
<squll> We still have no clue on even how to run that
<Chipaca> squll: and, more interestingly for me
<Chipaca> ok
<squll> And Googling 'How to run a snappy app' gives me alot of information on building
<squll> But I am not really seeing a command or something like that to run it
<Chipaca> squll: did you see mvo's reply to you the first time you asked?
<Chipaca> squll: how do you run an apk?
<squll> No I  did not
<Chipaca> <mvo> squll: run "snappy install your-snap" on a snappy system, snaps will only work on snappy systems, i.e. http://ubuntu.com/snappy
<squll> Yes I saw that
<squll> We did that indeed.
<squll> snappy versions gives us a list with that name in the list
<squll> But then I want to run it (it gives me data when executing it)
<Chipaca> squll: sorry, i'm not sure i understand
<Chipaca> squll: did you install the snap in a snappy ubuntu core system?
<squll> Yes we did
<squll> We have an Erle Rover (robot) with an small pc on it running snappy Ubuntu Core
<Chipaca> squll: ok
<Chipaca> squll: and does your snap have binaries, services, both, ...?
<squll> We are able to connect to the snappy app webinterface where we were able to run the HelloWorld snap. We find a hello-world.canonical file after some searching. That is indeed running and echo'ing hello world as expected.
<Chipaca> squll: does *your* snap, the one you built, have binaries, services, both, ...?
<squll> So then we go along and follow the tutorial of the vendor of our robot containing a snappy which prints out the date.
<squll> No it does not
<Chipaca> what prints out the date?
<squll> Well, we just don't really understand what we should expect after like a succesful build. Do we get a .canonical file or somthing?
<squll> It's just some C++ code, let me look up if there is a public github
<Chipaca> squll: hold on
<Chipaca> squll: let's slow down a bit
<Chipaca> squll: you created a snap by following the tutorial and doing "snappy build ."
<squll> Yes we did.
<Chipaca> squll: you then copied the snap to your snappy system
<Chipaca> squll: and did "sudo snappy install your-snap.snap"
<squll> We moved it to /home/ubuntu (as the tutorial tells us to do)
<Chipaca> squll: ah, you built it on the snappy system itself?
<Chipaca> squll: and did you then install it?
<squll> Yes. We are ssh-ing into the system and indeed building it on the system itself
<Chipaca> squll: sorry to repeat, but: did you, after building the .snap, install it?
<squll> Okay, hold on. We seemed to build it and let the robot blink a LED as we expected. But the whole idea of snappy is vague to us
<squll> We received a script file and after executing that, the led blinks.
<mvo> Chipaca: yes, I do that next, sorry for the delay
<tedg> Anyone know the link for sabdfl's talk at ROSCon?
<Chipaca> squll: I'm not sure whether you think you've answered my question, because I still feel you haven't
<squll> @tedg: Not found it yet, I think you should keep an eye on the social media platforms of OSRF
<nothal_> squll: No such command!
<Chipaca> mvo: thanks
<squll> Chipaca, what question you mean exactly?
<Chipaca> squll: did you, after building the .snap, install it?
<squll> We executed 'snappy install status-led-XXX.snap'. Is that what you mean by installing?\
<tedg> Funny that it was apparently live streamed, but when trying to get things the old fashioned recorded way that proves difficult :-)
<Chipaca> squll: yes.
<Chipaca> squll: ok, so "snappy list" shows that snap, then
<squll> Yes we did execute that command
<squll> Yes it does
<Chipaca> squll: so. If your snap exports binaries, you should now have things that start with status-led-* in your PATH
<Chipaca> squll: if you enter status-led- and hit <tab> they should come up
<Chipaca> umm. was "-" valid as part of a snap name? I don't remember. Anyway, not important at this stage.
<Chipaca> squll: if, on the other hand, your snap exports services, they would show up in "snappy services status"
<Chipaca> squll: sorry, snappy service status
<squll> We find an binary (what is a script) contain some shellscript
<squll> It uses the command aa-exec which needs a profile which can not be found
<Chipaca> squll: that means your snap is not a good snap :)
<squll> But it is a safe app thing, we know it is safe
<Chipaca> squll: could you pastebin your package.yaml and what you get when you run the script?
<Chipaca> squll: also, could you point me at the tutorial you followed, if it's online?
<squll> Can't find the tutorial quickly. Package is just as it should
<squll> How do I officially run a snappy app? Just as a command?
<Chipaca> squll: I'd expect most snaps at this stage to have services, with commands used only for debugging, introspection, or integration purposes
<Chipaca> squll: as to "official", as long as you're using the services (through whatever interface they provide) or binaries (through the wrappers in /apps/bin), that's about as official as it gets
<Chipaca> squll: as to your snap being "just as it should", if it were exactly as it should you wouldn't get apparmor complaining
<squll> Well I look at the  default example of a package.yml
<squll> The package.yml is following that specification
<Chipaca> squll: which is the default example of a package.yml?
<elopio> plars: any news with the lab?
<plars> elopio: I'm having some annoying issues with logstash, and with rpi, but otherwise things are going ok
<plars> elopio: last I tried, the logging was working this morning, so if you want to retry your job I can look (unless you were able to get output some other way already)
<elopio> plars: I will run it.
<plars> elopio: actually
<plars> elopio: did you already run it this morning?
<plars> elopio: someone ran something on bbb
<elopio> plars: it's scheduled to run daily, but jenkins chooses the time.
<elopio> so yesterday, at some point, it ran.
<plars> elopio:  https://www.irccloud.com/pastebin/J5R78ELe/
<dholbach> can anyone review https://code.launchpad.net/~dholbach/snapcraft/fix-pep8-and-doc-indentation/+merge/273195?
 * Chipaca looks
<Chipaca> dholbach: actually, standup; after that
<dholbach> cool thanks!
<elopio> plars: ok, that's one step closer. Still it doesn't capture those errors in the results. It should.
<elopio> plars: also, it should exit with != 0, but it says PASS.
<plars> elopio: yeah, that's a change that just landed this morning, I can redeploy with the new code in just a bit if you'd like
<elopio> plars: that would help a little.
<elopio> that output for some reason hides everything that happened on the actual run. /me checks that.
<plars> elopio: it looks like you are pointing at a bad path
<elopio> plars: where?
<plars> elopio: I guess perhaps it would be there if the earlier go bits ran
<elopio> plars: no, that's because adt-run didn't execute.
<elopio> the error is before, when we build the test binaries.
<elopio> plars: could you install this two?
<elopio> sudo apt-get install golang-go-linux-arm
<elopio>     sudo apt-get install gcc-arm-linux-gnueabihf
<plars> elopio: sure, I'll wait for the job on bbb-5002 to complete and redeploy both
<plars> elopio: try again?
<plars> elopio: I also installed the latest autopkgtest from http://launchpadlibrarian.net/218441943/autopkgtest_3.17.2_all.deb
<elopio> plars: thanks. Running.
<tedg> barry: You know, to help with the Python 3 transition, you guys should make it so the Python2 documentation isn't indexed by search engines.
<Chipaca> dholbach: long branch, but an easy ready :) lgtm.
<Chipaca> easy read*
<dholbach> thanks Chipaca!
<barry> tedg: maybe!  i almost never see py2 docs.  i have a nice chrome search shortcut for getting to the latest py3 library docs
<tedg> barry: Ah, the problem is the py2 ones come up first almost always, they're the most linked to.
<barry> tedg: i'm not sure how we can influence that, other than making those pages off limits to robots, which seems like a heavy hand
<barry> tedg: i'd go more with public shaming for even thinking about py2 :)
<tedg> barry: "To see this documentation please first watch this video on why you're a bad person if you click 'next'."
<barry> tedg: love it! :)
<wiggleworm> can someone point me to a list of basic snappy commands to get my nic running?
<wiggleworm> also can someone tell me how to list the installed pci devices - lspci does not seem to work or be installed
<Chipaca> wiggleworm: not without a lot more info on what you've got, and maybe not even then :)
<Chipaca> wiggleworm: your nic as in a network interface?
<Chipaca> wiggleworm: wrt lspci, ls /sys/bus/pci/devices might be a good place to start
<wiggleworm> @Chipaca: I ran the ls command and is shows a lot of device IDs but not "human readable" names
<nothal_> wiggleworm: No such command!
<wiggleworm> @nothal_: thanks :) - thats why I am here - I am looking for a list of basic network commands
<nothal_> wiggleworm: No such command!
<wiggleworm> I know that I have a wireless card and an ethernet card but I do not know the commands to bring them up
<Chipaca> @dance for us
<nothal_> Chipaca: No such command!
 * Chipaca thinks nothal_ is no fun anymore
 * nothal_ thinks Chipaca is no fun anymore
<Chipaca> wiggleworm: is the (ethernet) network plugged in?
<Chipaca> wiggleworm: if so it should come up on its own
<Chipaca> wiggleworm: for wireless i'm not sure; i think we ship enough bits that it should be possible, now, to bring up a wireless network, but i wouldn't know how to go about it. I'd start reading interfaces(5) and go from there.
<wiggleworm> @Chipaca: thanks, I will start there
<nothal_> wiggleworm: No such command!
<elopio> plars: things are happening, because it has been running for more than 15 minutes.
<dholbach> elopio, do you know which version of pep8 is running on the tarmac instance? (https://code.launchpad.net/~dholbach/snapcraft/fix-pep8-and-doc-indentation/+merge/273195)
<elopio> dholbach: let me check.
<plars> elopio: I never saw any output from it, but the last run I see seems to have exited with a rc of 2
<elopio> dholbach: 1.4.6-1.1build1
<dholbach> ah, ok, so that's trusty's pep8...
<elopio> dholbach: yes, tarmac is trusty.
<elopio> should I install vivid's pep8?
<dholbach> I'll see what I can do
<dholbach> that helps already, thanks
<elopio> dholbach: it would be nice to have the tests passing in both. But I prefer to land your branch soon, so let me know if it is bothering you too much.
<dholbach> I'll see if I can make it conform to both
<elopio> plars: now it says failed: http://10.55.32.109:8080/job/snappy-daily-rolling-bbb/26/console
<elopio> still no results. Can you please paste the output?
<elopio> this one must have run something because it took 1 hour to poll the result.
<plars> elopio: ^
<plars> elopio: Command failed, rc=2
<plars> no output
<elopio> plars: hum, does it timeout?
<plars> elopio: it didn't take that long to die, only about 12 min
<plars> elopio: in my logs I show that it was done trying to run after 12 min
<elopio> plars: are you looking at jenkins-snappy-daily-rolling-bbb-26669ff7f4-ddb9-4dcc-b836-28b879072a26 ?
<elopio> if it took only 12 min, there's something wrong with the results in spi. The job checked it 4 times.
<plars> elopio: I have no idea how long it takes for spi to register the results
<plars> elopio: but on my end, it's been done for a very long time
<plars> afk for a few, brb
<dholbach> elopio, it works for me in both now - maybe you want to take another look? https://code.launchpad.net/~dholbach/snapcraft/fix-pep8-and-doc-indentation/+merge/273195
<elopio> dholbach: thanks a lot
<dholbach> thanks for confirming and reviewing it initially :)
<elopio> I've been wanting to do this for a long time, but mterry doesn't like 80 column lines
<elopio> you doing it while he's no longer with us was the perfect solution :D
<dholbach> I had no idea :)
<mterry> elopio, :)
<mterry> 80 column lines are an historical accident
<elopio> dholbach: I know. I didn't say a word ;)
<elopio> mterry: we still love you and miss you.
<mterry> :)
 * dholbach hugs you all
<dholbach> have a great rest of your day everyone!
<elopio> ouch, dholbach had a typo.
<wiggleworm> Question about webdm - if its running should I be able to see port8080 in LISTEN mode
<Chipaca> wiggleworm: webdm uses port 5200, not 8080
<Chipaca> 4200*
<Chipaca> wiggleworm: what's on 8080?
<wiggleworm> @Chipaca: ok, even if its 4200 - I should still be able to see it when I run netstat -ntlp
<nothal_> wiggleworm: No such command!
<Chipaca> stop with the @s already :)
<wiggleworm> ok
<Chipaca> wiggleworm: just saying my nick is enough
<wiggleworm> no
<wiggleworm> np
<Chipaca> otherwise i'll have to ask for nothal to be kicked out, because it's annoying
<Chipaca> anyway
<wiggleworm> what does the at symbol do
<Chipaca> wiggleworm: yes, if webdm is running, i'd expect to see it in netstat
<Chipaca> wiggleworm: nothal_ is a bot, he does some useful things for us
<Chipaca> for example
<Chipaca> @reviewlist
<nothal_> https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/lp1496070/+merge/271167 | No reviews (19 days old)
<nothal_> https://code.launchpad.net/~stephen-stewart/webdm/use-correct-version-for-post-css-bemlinter/+merge/272467 | Approve: 1 (9 days old)
<nothal_> https://code.launchpad.net/~kyrofa/webdm/autorestart_services/+merge/268120 | No reviews (51 days old)
<nothal_> https://code.launchpad.net/~fgimenez/snappy/hw-assign-test/+merge/273413 | No reviews (less than a day old)
<nothal_> https://code.launchpad.net/~fgimenez/snappy/wait-for-idle-partition/+merge/273100 | No reviews (3 days old)
<Chipaca> $ sudo netstat -ntlp
<Chipaca> Active Internet connections (only servers)
<Chipaca> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
<Chipaca> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1007/sshd
<Chipaca> tcp6       0      0 :::22                   :::*                    LISTEN      1007/sshd
<Chipaca> tcp6       0      0 :::4200                 :::*                    LISTEN      3293/snappyd
<Chipaca> wiggleworm: ^
<wiggleworm> Chipaca - thanks. Mine is not showing that - I guess i do not have the service started
<Chipaca> wiggleworm: do you have it installed?
<wiggleworm> Chipaca: its says its installed - but I think its not running
<wiggleworm> Chipaca: systemctl list-units --no-pager | grep webdm
<Chipaca> wiggleworm: what does "snappy service status" say?
<wiggleworm> shows webdm_snappyd_0.9.2.service      loaded failed failed
<Chipaca> wiggleworm: time for a little journalctl
<Chipaca> wiggleworm: or
<wiggleworm> webdm   snappyd enabled; loaded; failed (failed)
<Chipaca> sudo snappy service logs webdm
<wiggleworm> Chipaca: 2015-10-05T16:45:51.766560Z systemd Started Snappy WebDM.
<wiggleworm> 2015-10-05T16:45:51.769154Z systemd Starting Snappy WebDM...
<wiggleworm> 2015-10-05T16:45:51.930078Z ubuntu-core-launcher 2015/10/05 16:45:51 Failed to listen 224.0.0.251:5353: listen udp4 0.0.0.0:5353->224.0.0.251:setsockopt: no such device
<wiggleworm> 2015-10-05T16:45:51.973332Z systemd webdm_snappyd_0.9.2.service: main process exited, code=exited, status=1/FAILURE
<wiggleworm> 2015-10-05T16:45:51.973857Z systemd Unit webdm_snappyd_0.9.2.service entered failed state.
<wiggleworm> 2015-10-05T16:45:51.974349Z systemd webdm_snappyd_0.9.2.service failed.
<wiggleworm> Chipaca: Service failed - any way to find out why?
<Chipaca> sigh
<Chipaca> i know why
<Chipaca> it can't start without a network device
<Chipaca> it's supposed to wait, but there is a timeout
<wiggleworm> my eth1 is working
<wiggleworm> Chipaca: is there a way to "modify" the wait time?
<Chipaca> wiggleworm: sudo snappy service webdm start should get you back up
<Chipaca> wiggleworm: not easily, no
<Chipaca> wiggleworm: but there is a bug about restarting services not happening
<Chipaca> need to fix that
<wiggleworm> Chipaca: another error
<wiggleworm> Chipaca: unable to start webdm's service snappyd: [start webdm_snappyd_0.9.service] failed with exit status 6: Failed to start webdm_
<wiggleworm> snappyd_0.9.service failed to load: No such file or directory.
<Chipaca> oh, that's interesting
<Chipaca> oh, wait
<Chipaca> snappyd_0.9.service?
<Chipaca> did you type that by hand, or is it missing the .2?
<Chipaca> wiggleworm: ?
<wiggleworm> Chipaca: I ran sudo snappy service webdm start and thats what popped out
<Chipaca> ok
<Chipaca> wiggleworm: and what does 'status' print now?
<Chipaca> this might be a different bug :)
<Chipaca> wiggleworm: there's a bug where sometimes service files get left behind on upgrade, i need to dig a little but it's some weird systemd integration problem, probably my fault
<Chipaca> wiggleworm: but it's benign, if it is that
<wiggleworm> Chipaca: (amd64)ubuntu@localhost:~$ snappy service status
<wiggleworm> Snap    Service State
<wiggleworm> webdm   snappyd ; not-found; inactive (dead)
<wiggleworm> webdm   snappyd enabled; loaded; failed (failed)
<Chipaca> hurr
<Chipaca> wiggleworm: what do you get from `sudo journalctl -ex -u webdm_snappyd_0.9.2.service`?
<Chipaca> (pastebin plz)
<wiggleworm> Chipaca: Sorry, I have to run. I will be back later this afternoon. I will run that and pastebin it in a little bit
<Chipaca> wiggleworm: sure
<wiggleworm> then ping you
<Chipaca> wiggleworm: i'm off too, but will read up when i return
<plars> elopio: one just finished a few minutes ago, same exit status (2) no output
<elopio> plars: I will remove the test from the script and just try creating the results json.
<wiggleworm> Chipaca: here is the pastebin you asked for http://pastebin.com/GHTfEpM0
<elopio> plars: take a look at the script. I commented out everything except the cat to the results.json. Still no payload. How come?
<plars> elopio: hmm, not sure... let me take a look
<plars> elopio: where's your script again?
<elopio> plars: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh
<plars> elopio: also, do you have the results url for spi?
<elopio> plars: not sure what do you mean
<elopio> plars: https://spi.canonical.com/orgs/canonical/results ?
<plars> elopio: https://spi.canonical.com/orgs/canonical/results... or something? what's a good search string to use?
<elopio> https://spi.canonical.com/orgs/canonical/results/ + image_unique_id
<plars> elopio: ....which is?
<elopio> plars: for the latest run, jenkins-snappy-daily-rolling-bbb-29af6fb1fb-6489-4e26-a298-28d14c6fe827
<plars> elopio: your json needs fixing
<plars> elopio: double quotes instead of single, and you need a comma between the k:v pairs
<plars> elopio: then it should work
<plars> elopio: also, try something for me
<plars> elopio: this won't matter to spi, but it will answer a question for me about my logging config, have it echo something during your script
<plars> to stdout, not just to the file
<plars> elopio: fixing the json should be enough that you can see results in the result_payload though
<elopio> plars: ugh, stupid me
<elopio> thanks, I'll give it a try.
<plars> elopio: I got the output on my end, but it looks like your payload is still missing. I think I know what's wrong though, sorry I forgot to mention, but you'll likely need to escape your quotes
<plars> elopio: \"
<plars> elopio: otherwise the json will still be missing them
<wiggleworm> Chipaca: you back yet?
<Chipaca> wiggleworm: no
<Chipaca> wiggleworm: remind me, what was it about?
<Chipaca> something about webdm not running
 * Chipaca looks at the pastebin
<Chipaca> wiggleworm: the pastebin is cut off, can you tell me what it says to the right of âFailed to listen 224.0.0.251:5353: listâ? :)
<wiggleworm> Chipaca: listen udp4 0.0.0.0:5353->224.0.0.251: setsockopt: no such device
<plars> elopio: I see your result payload now
<plars> \o/
<Chipaca> wiggleworm: this is after a reboot?
<wiggleworm> Chipaca: nope, just a sec and I will reboot and try again
<Chipaca> is there something like bzr shelve, but less dselect-before-apt?
<Chipaca> mwenning: any news wrt the race detector branch?
<Chipaca> package
<Chipaca> thing?
<Chipaca> mwhudson: ^ I meant you
<Chipaca> mwenning: bad completion, sorry
<mwhudson> Chipaca: no, i had one round of review
<Chipaca> yeh, saw that, but then nothing?
<mwhudson> Chipaca: if you know any members of ~ubuntu-sponsors...
<Chipaca> mwhudson: i fear it'll miss the boat, if it hasn't happened already :(
<mwhudson> Chipaca: it is getting pretty late :(
<mwhudson> Chipaca: i'm not sure i have the energy to get worked up about it unfortunately, i have other things on my plate
<mwhudson> (as i'm sure everyone does)
<Chipaca> mhmm
<Chipaca> i'll poke pitti tomorrow
<Chipaca> he'll be so relieved i'm not asking him about systemd, he might actually do something about it
<Chipaca> yisss
<Chipaca> after a moment of panic where i thought i'd deleted it all, the husks pipeline is now up for review
<Chipaca> \o/
<Chipaca> also: ð¤
#snappy 2015-10-06
<plars> elopio: it looks like, to me, that your image is not booting
<plars> elopio: so I'm confused as to what might have changed... I've had them connect a serial cable to the rpi and it doesn't boot for me in the lab, but boots fine at home
<plars> elopio: and I haven't tried my bbb at home yet, but both the ones in the lab fail to boot new images, but I'm not sure what might have changed
<plars> elopio: all of these worked fine recently
<plars> elopio: so I'm able to reproduce the rpi boot failure from usb at home now too
<plars> something must have changed in the image that broke this, but I'm not sure what yet, I bet it's the same problem you're hitting on bbb
<plars> elopio: I'll keep digging on it tomorrow
<plars> elopio: I would have expected bbb to work though, because it's booting snappy from the sd card
<clobrano> morning :)
<fgimenez> good morning
<dholbach> good morning
<squll> Hey, I am trying to do snappy install but when I try to install something I get this error: http://pastebin.com/zUD1C1nc
<squll> How can I update snappy link-time version?
<mvo> squll: this looks like you are using a older version of snappy, could you please try with the 15.04 image that is linked from https://developer.ubuntu.com/en/snappy/ ?
<Chipaca> pitti: you around?
<pitti> hey Chipaca
<Chipaca> mvo_: morning!
<Chipaca> pitti: hey. Do you know if it's already too late for having bug 1487010 fixed in wily?
<ubottu> bug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/1487010
<JamesTait> Good morning all; happy Tuesday, and happy Mad Hatter Day! ð
<Chipaca> JamesTait: ð© :)
<pitti> Chipaca: new packages are generally okay; but you need a more formal FF if you want to use this by some existing package (as that's a potential regression)
<Chipaca> pitti: the regression is there in wily already, this package fixes it :)
<pitti> Chipaca: ah, need re-review/sponsoring? I'll have a look after fixing langpack-o-matic
<Chipaca> pitti: please :)
<pitti> Chipaca: do you know where the "229396" version number comes from and how it changes over time?
<pitti> Chipaca: and where the upstream tarball comes from?
<Chipaca> pitti: i don't. Maybe mwhudson is still around?
<pitti> Chipaca, mwhudson: replied to the bug
<Chipaca> pitti: much appreciated
<pitti> I now sub'ed to the bug, so I get a timely notification
<Chipaca> ta
<biezpal> hi all! We've managed to run Snappy Ubuntu on Parallella board but faced stupid problem - we cannot log into system..
<biezpal> where cloud-config should be placed?
<biezpal> or how cloud-init should work in general? :)
<Chipaca> biezpal: woo! snappy on parallella :)
<soffokl> Chipaca, we with biezpal are close to it :)
<Chipaca> biezpal: how did you build the image? if you didn't specify --developer-mode or --enable-ssh (check exact flags; these from memory), you won't have ssh
<Chipaca> i'd recommend --developer-mode for when, um, developing :-p
<Chipaca> if the parallela doesn't give you serial or console, not having ssh might be a problem
<Chipaca> so, yeah :)
<soffokl> Chipaca, ssh is enabled, we have prompt, but do not know a way to set password for ubuntu user
<Chipaca> wait
<Chipaca> that's not whhat biezpal said :)
<Chipaca> soffokl: doesn't "passwd" work? i haven't tried, but know ogra dug into making extrausers work (and afaik, succeeded)
<biezpal> Chipaca, soffokl is correct, we have console invitation, but we cannot log into the system
<Chipaca> soffokl: unless you mean you have a login prompt and don't know the default ubuntu password
<Chipaca> try "ubuntu"
<soffokl> tried many times :)
<Chipaca> soffokl: biezpal: so you're saying ubuntu/ubuntu didn't work to log in?
<soffokl> yes
<soffokl> if we are using OVA, we should add seed.iso with cloud config for setting password, right? what should we use for ARM SoC?
<Chipaca> i have no idea :( sorry!
<Chipaca> you want ogra
<biezpal> Chipaca, ok, thanks, keeping dig
<zyga> pitti: hey
<pitti> hey zyga
<pitti> zyga: sorry, I lost your scrollback from last night, due  to a short power outage
<zyga> pitti: no worries
<olli> orning
<elopio> plars: I'm able to see the output!
<elopio> and yes, it says "failed to ssh"
<plars> elopio: yay, now if we can just get the image booting again :)
<plars> elopio: I'm just starting my day, had to stop last night because it was really late
<elopio> plars: details... :) I'm downloading the bbb image here to see how it goes.
<plars> elopio: any ideas on what could be happening?
<plars> elopio: I was able to reproduce the rpi problem at home last night, but not sure what's happened to it. It boots fine from sd, but when I move it to the usb stick it fails to boot, even though I've modified the uboot config to have it pull the kernel and initrd from usb
<elopio> plars: I'm not aware of any changes to the boot.
<plars> elopio: I had the people in the lab connect the serial  cable to one of the bbb boards, and unfortunately it's doing something weird... I'm getting garbled output so I can't make much out
<plars> elopio: but I can tell it's booted into snappy
<plars> elopio: but it looks like I have no network
<plars> elopio: ok, maybe not, I do seem to have network on bbb5002 now
<elopio> plars: in our kvm testing we capture the full boot log. In bbb that's a lot harder, but would be nice as a feature request.
<plars> elopio: it's in our backlog I think, but it's likely way down the list and will require some additional hardware
<plars> elopio: I'm actually kind of disappointed that this one bbb randomly worked this morning
<plars> elopio: previously, it wasn't working at all but at least it was consistent
<plars> elopio: so whatever is happening, it's not the same as the issue on rpi. On bbb, it fully boots snappy from the sd card because we can select that with the gpio - so it should be *just* like putting in an sd with snappy on it
<elopio> plars: it booted here and ssh enabled
<plars> elopio: yeah, it seems like network doesn't come up on the first boot
<plars> elopio: if I reboot it, then the network comes up fine though
<elopio> plars: so when you boot, do you see the eth0 down?
<plars> elopio: I can't see much of anything, the serial adapter they have on this thing is terrible
<plars> elopio: I was able to save off the syslog and reboot though, then I can ssh in
<plars> elopio: http://paste.ubuntu.com/12697260/
<plars> elopio: it's up but unconfigured on the first boot
<plars> elopio: http://paste.ubuntu.com/12697267/ is the ifconfig from the first boot
<Chipaca> what's a reasonable N for scrypt on armhf?
<elopio> plars: this is mine: http://paste.ubuntu.com/12697352/
<elopio> I can ssh into that ipv6 address.
<elopio> you are missing that scope/global. Could it be your router?
<plars> elopio: then why would it work after a reboot?
<plars> elopio: yours is ipv6 only?
<plars> elopio: writing an image to try it locally also
<elopio> plars: no. I'm not sure why it's not giving it a ipv4 address.
<plars> after reboot, I have:
<plars>           inet addr:10.101.50.2  Bcast:10.101.51.255  Mask:255.255.252.0
<plars>           inet6 addr: fe80::6eec:ebff:fead:3db4/64 Scope:Link
<elopio> after reboot I get ipv4, right.
<plars> elopio: interesting, this didn't use to happen
<plars> elopio: I used to be able to get ipv4 on the first boot
<elopio> plars: me too. And certainly I'm getting it on kvm.
<elopio> plars: so your router doesn't support v6? Trying to understand why you are not getting that one either.
<plars> elopio: it looks like I did get an ipv6 address, but I'm not trying to use that
<elopio> plars: https://bugs.launchpad.net/snappy/+bug/1503329
<ubottu> Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Undecided,New]
<elopio> fgimenez is trying to confirm it.
<plars> elopio: cool
<plars> elopio: I'm trying to reproduce locally too
<fgimenez> elopio, plars same here http://paste.ubuntu.com/12697627/
<plars> fgimenez: thanks for confirming
<plars> fginther: elopio: it looks like image 186 worked, and 187 did not
#snappy 2015-10-07
<dholbach> good morning
<dfletch> morning
<dfletch> can one have apt parallel to snappy?
<JamesTait> Good morning all; happy Wednesday, and happy Frappe Day! ð
<clobrano> good morning
<clobrano> Chipaca: hello, I came back on Bug #1496319 :)
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<clobrano> Chipaca: problem was adding custom Udev string as hw-assign parameter. Is there a way to check whether Udev is tested enough for this?
<soffokl> Hi all, we are still trying to execute Snappy on parallella board. Based on porting guilde, we have take beagebone rootof and our own kernel. After some configuring u-boot, we have managed to load system.
<soffokl> But after that we failed to login by âubuntu/ubuntuâ, because of system after first boot sets /var/lib/extrausers/shadow like ubuntu:!$6$tOIJâ¦
<soffokl> After removing â!â we can successfully login into system. But mount command shows that root mounted in ârwâ mode. And seems like not all mount points mounted properly.
<soffokl> ogra2, ogra_ : you are our last chance :)
<Chipaca> lool: you around?
<Chipaca> mwhudson: did you see pitti's reply on bug 1487010?
<ubottu> bug 1487010 in golang (Ubuntu) "please upload new package to reenable go's race detector on wily" [Undecided,In progress] https://launchpad.net/bugs/1487010
<lool> Chipaca: yup
<Chipaca> clobrano: i'd ask security people
<Chipaca> lool: you've ported snappy to some odd places :)
<Chipaca> lool: any hints for soffokl here?
<clobrano> Chipaca: thanks
<lool> soffokl: are you using our initrd snippets?
<lool> soffokl: http://kernel.ubuntu.com/git/rtg/snappy-tools.git/ has a tool to create the device tarball from kernel .debs
<Chipaca> clobrano: most of 'em are at something like utc-5 though
 * clobrano checking UTC-5
<clobrano> Chipaca: it's not a problem, I can wait :)
<ogra_> soffokl, and you used ubuntu-device-flash to create this image ?
<Chipaca> an ogra!
 * Chipaca faints
<ogra_> well, inofficial still :)
<Chipaca> :)
<ogra_> (but bored as hell)
<soffokl> lool, we have tried to use beagleboneblack initrd, but then our kernel failed to load.
<ogra_> then youur kernel is likely missing bits that snappy needs
<lool> soffokl: you need to have the right modules and options, either builtin modules or in the initrd
<ogra_> nah
<ogra_> you shouldnt need modules
<lool> ogra_: either builtin or as modules  :-)
<ogra_> if you use the same config we use on the beagle or on the rpi images you will have everything you need to mount the readonly root and the overlays
<soffokl> ogra_, yes, we have created image with "sudo ubuntu-device-flash core 15.04 -o my-snappy.img --size 4 --channel edge --oem beagleblack --enable-ssh --device-part=./device.tar.xz"
<ogra_> i have booted both with module-less initrds
<biezpal> ogra_, which config you mean?
<ogra_> soffokl, well, you need to create your onwn oem snap ... with the right bootloader, vmlinuz and initrd
<ogra_> biezpal, the kernel config :)
<biezpal> ogra_, where can we get the "correct" kernel config?
<biezpal> we are using our own kernel for parallella and seems like it doesn't have required for snappy bits..
<ogra_> ppisati, ^^ doo you have a link for biezpal
<ppisati> biezpal: kernel version?
<ppisati> 3.10, 3.14 or 3.18?
<ogra_> or perhaps 4.2 ?
<ogra_> :)
<ppisati> *drums*
<ppisati> 4.2 would be awesome
<biezpal> ppisati, 4.2.0  :D
<ogra_> soffokl, note that a readonly root is normal ... only a few selected bits are writable via bind mounted dirs and files, that is what the initrd is needed for
<ogra_> (it sets up the bind-mount-farm)
<ppisati> biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_packaging
<ppisati> biezpal: look at the UBUNT: [Config] commits
<ppisati> biezpal: they all touch files in
<soffokl> ogra_, thanks, we are keep reading about oem snap
<ppisati> biezpal: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_packaging
<ppisati> biezpal: cherry-picks these commits
<ppisati> biezpal: then
<ppisati> biezpal: $ ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/YOURCONFIG_defconfig arch/arm/configs/snappy/*.config
<ppisati> biezpal: and you should get a config able to boot snappy
<ogra_> soffokl, note that we switched to use a uboot.env file for the environment, but the old uEnv.txt and snappy-system.txt stuff should still work to get something to do a first boot (just rollback and update wont, but thhats a second step for porting)
<biezpal> ppisati, ok, thanks for helping..
<longsleep> yesterday i tried updating one of my test boxes to stable 6, it failed with the message that ubuntu-core was sideloaded. Is that expected?
<longsleep> ogra_: Hey, are you using predictable network interface names with rpi2 image? If so, how did you enable it, kernel parameter only?
<ogra_> longsleep, i'm actually suppressing them via kernel cmdline option corrently
<ogra_> net.ifnames=0
<ogra_> that keeps the old naming scheme
<longsleep> ogra_: Ah - but that is the default in ubuntu isnt it?
<ogra_> not sure if we use it elsewhere
<longsleep> ogra_: net.ifnames=1 is working to some level for me, but i was wondering if the interfaces should still be eth0 and wlan0
<ogra_> well.... snappy config ubuntu-core defaults to eth0 currently
<longsleep> right, but aside from that, i was kind of expecting crazy interface names with that change
<ogra_> yeah
<ogra_> depends on your HW
<longsleep> mhm ok, USB wifi is getting wlan0 names, works fine as long as you do not replace the USB device with another one
<ogra_> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
<ogra_> seems you are lucky and fall inot category 5 on that 1-5 list
<longsleep> mhm
<longsleep> this means the hardware does not provie 1, 2 or 3 or i am doing something wrong
<ogra_> right ... or you have a udev rule in place already
<longsleep> i did at least expect it to use 3
<longsleep> ogra_: why do you not use it on the rpi2? just because ubuntu-core defaulting to eth0?
<ogra_> yeah, and i get a really weird name based on the mac address (4)
<longsleep> oh
<longsleep> yeah 4 would be bad
<ogra_> (which i shouldnt according to that doc)
<longsleep> well, maybe it is enabled in the systemd build somwhere
<ogra_> iirc Chipaca said all that works fine in rolling ... never tried that
<ogra_> i added this hack to rpi specifically for 15.04 images
<Chipaca> mmh?
<Chipaca> i was probably lying, whatever it was
<Chipaca> 's a good bet
<ogra_> lol
<longsleep> anyways, i am basically fine with getting 5 - but i have some issues when an active USB wifi is removed and replaced, something is not released then and then
<longsleep> mhm, from my testing setting the kernel parameter to 0 is the same as the default behavior without the parameter
<longsleep> (stable channel though)
<ogra_> funny
<ogra_> is that on a first boot ?
<longsleep> yes
<ogra_> (wont work on subsequent ones since the udev rule exists)
<longsleep> when i remove the udev rule and reboot without the parameter it creates it again
<longsleep> same is when booting with 0 as value
<longsleep> when booting with 1, the udev rule is not created
<ogra_> yeah
<ogra_> but your kernel simply provides the old naming
<Chipaca> is this about the creation of the file for the first ethernet card?
<longsleep> ogra_: oh, so this thing depends on the kernel as well, i thought it would be systemd only
<ogra_> well, that is what the wikipage says
<longsleep> Chipaca: it is about the interface names and the udev rule stores all ethernet devices ever connected to the host
 * longsleep checks the wiki again
<ogra_> 5. Classic, unpredictable kernel-native ethX naming (example: eth0)
<ogra_> kernel-native
<Chipaca> ah
<Chipaca> but i had nothing to do with that :)
<Chipaca> all i did touching that was creation of the first-boot file for the first ethernet device
<soffokl> ogra_, we are successfully loaded with initrd, thanks again :)
<longsleep> ogra_: right, but any kernel should be the same right?
<Chipaca> which just looks for eth* and en*
<ogra_> i'm pretty sure you worked on a snappy specific bug for it :)
<ogra_> right
<longsleep> Chipaca: what file is that?
<ogra_> soffokl, \o/
<Chipaca> longsleep: /etc/networ/interfaces.d/{ethname}
<longsleep> Chipaca: ah, well you should probably extend this to also support wl*
<ogra_> in the course where we discussed that bug it turned out that rolling and 15.04 behaved differently
<ogra_> which led me to use the kernel cmdline option on rpi stable
<longsleep> i see
<longsleep> mhm funny that i do not seem to be required to use the cmdline option though
<ogra_> i agree abouth the wl* thing though
<Chipaca> longsleep: wl is wifi, sin't it?
<longsleep> Chipaca: yeah
<ogra_> yep
<Chipaca> isn't that more complicated?
<ogra_> buut if you are unluckly it could also be wifi0
<ogra_> :P
 * ogra_ has seen such devices before
<longsleep> really
<longsleep> oh my
 * Chipaca <- il ne sais rien
<Chipaca> sait*
<ogra_> rm -fr ....
<longsleep> lol
 * ogra_ removes the french
<Chipaca> :D
<Chipaca> or, D:
<Chipaca> let me get our friends out of france first!
<ogra_> heh
<longsleep> wifi is more complicated true, i am currently providing wpa config in /etc/writable/wpa_supplicant.conf
<longsleep> did not find any better writable mount to put it
<ogra_> there might be a network-manager framework at some point in the future
<ogra_> that should make it easier to just supply a snappy confg yaml for your setup
<Chipaca> longsleep: you can't configure it via the interfaces.d thing in config?
<ogra_> only to a certain extend
<longsleep> Chipaca: not if you want to be able to configure multiple networks
<ogra_> wifi config works fine via /e/n/i ... but not for the higher level encryptions
<Chipaca> longsleep: i don't think multiple networks blocks this
<ogra_> i.e. enterprise WPA and such
<Chipaca> ogra_: yeah, those always tripped me up :)
<longsleep> Chipaca: what is not blocked by multiple networks?
<ogra_> normal personal WPA2 works fine via the file
<longsleep> only for a single ssid
<ogra_> i never tried multiple :)
<longsleep> if you want roaming or have it auto pick the stronges signal it will not
<Chipaca> ah
<longsleep> =t
<Chipaca> so, let's call it "basic support"
<Chipaca> :)
<ogra_> and my WIFI APs here can properly use ESSID for roaming
<longsleep> hehe all right
<ogra_> (using the same SSID for all and have them send roaming info to the client about strenght etc)
<longsleep> ogra_: mhm so you say i should avoid using a wpa config file mhm - not sure - then i need a way to store multiple ssid/password combinations some place else and apply them from some place else
<ogra_> but thats sadly an AP feature you dont find in the home user HW
<longsleep> right, and only works for a single logical network
<ogra_> yeah
 * longsleep thinks wpa-confi option is the way to go for everyone
<ogra_> nah
<longsleep> snappy even shipts wpa_passphrase to create it
<longsleep> :)
<longsleep> -t
<ogra_> nmcli via snappy config from your oem snap is the way to go
<longsleep> nmcli oh my
 * longsleep was hoping to avoid that
<ogra_> once there is a NM framework we ship by default
<ogra_> NM offers evereything we need for GSM, LAN and WLAN
<ogra_> and whatever else
<longsleep> does NM also offer link detection? I added a new comment to https://bugs.launchpad.net/snappy/+bug/1498631/comments/10 yesterday, as dhcp is running forever even if there is no link on eth0
<ubottu> Launchpad bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [High,In progress]
<ogra_> yes, it should
<longsleep> Now the waiting is fixed with the release from yesterday but the dhcp keeps running and running
<ogra_> (plug a cable into your laptop ... it will DTRT)
<longsleep> oh, i did some brief research about ifplugd and and did not like it very much
<ogra_> is that dhclient ?
<longsleep> yes dhcclient is started for eth0
<longsleep> no matter if plugged or not
<ogra_> that should have a timeout option we can add i think
<longsleep> mhm but what when you plug it after that timeout was reached?
<ogra_> i think -1 ...
<longsleep> that is there
<ogra_> but that will only make it try once
<ogra_> oh
<ogra_> it should try only once for the duration of the timeout that was defined in dhclient.conf
<longsleep> mhm it does have some kind of interval
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ grep ^time /etc/dhcp/dhclient.conf
<ogra_> timeout 300;
<ogra_> so it should stop after 5min
<longsleep> No working leases in persistent database - sleeping.
<longsleep> and after some time it will try again
<longsleep> ok maybe i was not patient enough
<longsleep> nope its not me
<longsleep> it just started again
<longsleep> ogra_: 10:54:53 sleeping
<longsleep> ogra_: 11:00:33 DHCPDISCOVER
<ogra_> uhm
<longsleep> i did nothing with that device in the meantime
<longsleep> just journalctl
<ogra_> pitti, any idea why that happens ? "dhclient -1 <iface>" should not make it restart, no ?
<ogra_> or i'm reading the manpage wrong ... sounds like a bug
<longsleep> ogra_: well then i am reading the manpage wrong as well
<longsleep> ogra_: exit with code 2 :)
<ogra_> right
<daker> hi, anyone with some snappy/Ubuntu Core presentations ?
<longsleep> i am out for lunch now, i will dig more on this later
<ogra_> daker, i know sergiuens held a talk, but i dont know where his slides are ... (and he is off until tomorrow)
<daker> ogra_: ok, i will ask him tomorrow
<Chipaca> http://summit.ubuntu.com/ubuconla-2015/meeting/22539/hola-snappy/
<Chipaca> ogra_: ^ that one?
<ogra_> oh, right
<ogra_> you might need to pipe it through skype though to get it in a sane language
<ogra_> *g*
<daker> Chipaca: thanks
<svij> daker: depending on your language, here's another one in not-english: https://speakerdeck.com/svij/snappy-ubuntu-core
<daker> svij: thanks!
<ogra_> ppisati, err ... why do we default to "powersave" in the kernel config, thats really bad ... (first: that makes booting slow, second: we have a userspace job that forces it to ondemand after boot)
<ogra_> can we please set this back to performance by default so the boot doesnt get slowed down =
<ogra_> ?
<ogra_> (we can discuss making the usespace job configurable to then default to powersave after boot or some such)
 * Chipaca goes to lunch, while pondering the genius of http://bennyhillthis.com/
<longsleep> ogra_: so the dhclient is still trying to get an address for the not connected eth0, so i think we can say that it does not stop
<ogra_> longsleep, right, i think thats a bug .... seems pitti didnt see my ping above :)
<pitti> ogra_: I didn't get to it yet; sorry, being flood-pinged
<ogra_> i would expect it to stop doing that if -1 is used and a timeout is set in dhclient.conf
<longsleep> ok let me add it to the tracker then
<ogra_> perhaps something external restarts dhclient and doesnt respect "exit 2" though
<longsleep> ogra_: no, the pid of that dhclient did not change since 2 hours
<ogra_> wow
<ogra_> yeah, then it sounds like dhclient doesnt even exit
<pitti> I didn't follow scrollback, but -1 doesn't (seem to) be "try once and immediately exit", just "try once" (as documented)
<pitti> so it might stay around until it actually succeeds?
<longsleep> yet it stays around and flodding logs all 5 minutes with DHCPDISCOVER on eth0 lines
<longsleep> s/yet/yes
<ogra_> pitti, well, the manpage says it does try once for the duration of the timeout thats defined in dhclient.conf
<pitti> so that sounds like a bug then
<ogra_> and then it does an "exit 2"
<longsleep> let me add a new bug separate from 1498631
 * pitti runs "sudo dhclient -1 -v -i lxcbr0" (which can't succeed) and lets that sit for 5 mins
 * pitti gets grumpy, changes timeout to 30s and re-runs
<longsleep> hehe
<pitti> what kind of ridiculous default is "5 mins" anyway
<pitti> we live in an impatient world :)
<pitti> 5 mins == broken
<pitti> No DHCPOFFERS received.
<pitti> and exits with 0 (!) after 30 s
<longsleep> Maybe its only with a lease file?
<longsleep> After No DHCPOFFERS received it logs No working leases in persistent database - sleeping.
<pitti> I do have a /var/lib/dhcp/dhclient.leases
<pitti> right, I get the same
<longsleep> mhm
<pitti>       Old leases are kept around in case the DHCP server is unavailable when  dhclient
<pitti>        is  first  invoked  (generally during the initial system boot process).  In that
<pitti>        event, old leases from the dhclient.leases file which have not yet  expired  are
<pitti>        tested,  and if they are determined to be valid, they are used until either they
<pitti>        expire or the DHCP server becomes available.
<ppisati> ogra_: powersave is our default on every kernel/arch
<pitti> so that sounds plausible
<ppisati> ogra_: how much do we gain in boot time going to performance?
<longsleep> mine does not exit - the pidfile got created at 10:25 utc and it still has that pid
<pitti> longsleep: so does it log that it's re-using old leases then?
<longsleep> pitti: no there are no leases
<longsleep> (lease file is empty)
<longsleep> its the first boot actually, and it never had a link on eth0
<ogra_> ppisati, a few seconds !
<ogra_> ppisati, who decided to drop performance in our main kernels ?!?
<ogra_> thats an essential boot speed bit
<ogra_> (worked out around lucid by keybuk)
<ppisati> ogra_: let me check
<pitti> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
<ogra_> phew !
<pitti> we still have that in wily's amd64 kernel at least
<pitti> is that different on other kernels?
<ogra_> seems like
<ogra_> well, in snappy kernels
<pitti> and /etc/init.d/ondemand should change it to something else after 1 min
<ogra_> yeah
<ogra_> we want full CPU and IO throughput until we are booted
<ogra_> and after that switch to ondemand
<ogra_> if we want to switch to something else in snappy thats fine, but only after booting please
<pitti> FWIW, needing something like /etc/init.d/ondemand seems silly; I'd have thought the kernel's default scheduler would be clever enough by now
<pitti> I mean, even with ondemand/powersave it should go to full CPU if there's load; doesn't it?
<ppisati> pitti: yep
<ppisati> pitti: it just tries to go down quicker
<pitti> ppisati: right, I'm not advocating to keep "performance" all the time; I'm just asking why "ondemand" all the time is worse
<pitti> if there is demand (and there obviously is during boot) it should certainly be as fast?
<ppisati> ogra_: i was wrong, the default is still PERFORMANCE
<ogra_> i think keybuk found that it takes a bit to scale up
<ogra_> ppisati, good
<ppisati> ogra_: tough in that rpi2 kernel was powersave
<ppisati> ogra_: let me check another thing
<ogra_> pitti, so you run without full performance for a second or two during boot
<Chipaca> jdstrand: ping
<ppisati> here it is
<ppisati> arch/arm/configs/bcm2709_defconfig:CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y
<ogra_> which costs precious CPU throughput at a point where you dont want to lose it
<ppisati> ogra_: that was the default governor from the rpi config
<ogra_> ppisati, oh, please change that asap
<ogra_> we want ondemand after boot and performance during boot
<ppisati> ogra_: let me check 4.2
<ogra_> now i understand why it boots so sluggish
<ppisati> ogra_: and i'll push a a new kernel for 3.19
<Chipaca> jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273683
<ogra_> ppisati, why ? we dont use 3.19 anywhere anymore :)
<ogra_> snappy is 4.2 everywhere since last image
<ppisati> ogra_: i'm still using it :)
<Chipaca> jdstrand: marked "work in progress" because i still need to add code that uses it, but that's the crypto bits done for your guys to take a look
<longsleep> ppisati, ogra_ : Added the dhcp issue as bug #1503680
<ubottu> bug 1503680 in Snappy "dhclient for eth0 does never exit and retries dhcp foerever" [Undecided,New] https://launchpad.net/bugs/1503680
<Chipaca> oh, drat, prerequisites
<ogra_> and in snappy we run cloud-init during boot *before* the ondemand governor is used ... and cloud-init is python ... which is ultra slow on ARM in itself
<ogra_> longsleep, thanks !
<Chipaca> jdstrand: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684 <- fixed prereq's
<ppisati> CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y is the default on 4.2 rpi2 too
<ppisati> so it was just a 3.19 thing
<ppisati> ogra_: when you were referring to slowness, did it apply to 4.2 too?
<ppisati> ogra_: because it's correct there
<ogra_> ppisati, i didnt measure it recently ... in my initial images it was really slow (1-2min to boot) .... with the last image i mostly booted remote
<ogra_> i have to prepare a new rpi image this week (nobody told me we'd release a new stable one this week, i thought that was planned for teh 17th)
<ogra_> i'll do some stopwatching :)
<ppisati> ogra_: cool
<longsleep> any reason why opencryptoki is in ubuntu-core stable? I just added bug #1503681
<ubottu> bug 1503681 in Snappy "opencryptoki.service fails to start" [Undecided,New] https://launchpad.net/bugs/1503681
<ogra_> longsleep, weird, thats fixed
 * ogra_ wonders if mvo did test on all ARM arches before doing that rushed release yesterday :/
<longsleep> mhm the image i created yesterday has it installed
<ogra_> longsleep, its a duplicate in any case, let me find the bug
<ogra_> https://bugs.launchpad.net/snappy/+bug/1500020
<ubottu> Launchpad bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New]
<longsleep> let me compare it
<ogra_> ah, and i didnt milestone it so that mvo could have found it because asac didnt create a milestone
<jdstrand> Chipaca: ok, I added it to the card
<ogra_> i fixed it in wily
<mvo> ogra_: I ran on bbb and did not touch raspi
<jdstrand> s/to the/to a/
<Chipaca> jdstrand: g'morning :)
<jdstrand> Chipaca: hi!
<mvo> ogra_: oh, in a meeting right now, but I can check right after that
<ogra_> mvo, right, but there are plenty bugfixes missing seemingly ... i asked asac for a milestone and he missed creating one during the sprint
<ogra_> so the open bugs are all not milestoned
<jdstrand> Chipaca: it will likely be a couple of days-- sarnold is swamped with other reviews
<jdstrand> Chipaca: hey, do you know who implemented socket* and listen-stream?
<ogra_> mvo, but therer are some regressions due to stuff that was added for amd64
<Chipaca> jdstrand: the chipacacentric worldview is disappointed
<Chipaca> jdstrand: mvo iirc
<jdstrand> ok thanks
<jdstrand> mvo: I know you're in a meeting. after the meeting when its convenient, can you ping me re socket* and list-stream?
<jdstrand> listen*
<longsleep> ogra_: i see, well the comment says that the writable path should be added, it has not been added for ubuntu-core 6 - at least the one i got
<ogra_> longsleep, yeah, thats broken
<longsleep> ogra_: ubuntu-core 6 has 0.6.15 of ubuntu-core-config - thats why - fixed in 0.6.29
<ogra_> longsleep, thats correct, as i said there is a bunch of regressions that werent fixed
<ogra_> (and vivid has 0.6.15, which is correct too)
<longsleep> ok good, so how can i close 1503681 as duplicate
<longsleep> ah found it
<ogra_> longsleep, done
<longsleep> ok thanks :)
<mvo> ogra_: do you have bugs already for the regressions?
<mvo> jdstrand: ok, I will ping you
<ogra_> mvo, i have to dig them up, bug 1500020 is definitely one
<ubottu> bug 1500020 in Snappy "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/1500020
<ogra_> i had three, i think i closed two of them already
<ogra_> all regessions from the last additions of packages for the amd64 images
<ogra_> we definitely need to improve our milestone process for bugs ... perhaps just create ten in advance in LP or so so that doesnt get forgotten
<mvo> jdstrand: back
<jdstrand> mvo: hi!
<mvo> ogra_: yeah, this time the sprint made the timing really awkward
<jdstrand> mvo: I am writing up some documentation and noticed the new socket* and listen-stream directives for services. can you give me a two sentence summary of the feature?
<jdstrand> (just so we are on the same page-- I think I know what's going on from the docs, but I have followup questions)
<mvo> jdstrand: hm, it allows socket activated daemons with snappy
<mvo> jdstrand: the patch comes from kickinz1 for docker
<jdstrand> I see
<mvo> jdstrand: I think its somewhat documented in meta.md
<jdstrand> mvo: listen-stream says "The full path of the stream socket". is this a named socket?
 * jdstrand was looking at https://developer.ubuntu.com/en/snappy/guides/package-metadata/
<mvo> uh, its poorly documented in docs/meta.md - but at least its mentioned
<mvo> jdstrand: it can be both a path or a abstract socket with @foo
<mvo> jdstrand: or a port (haven't tested that though)
<jdstrand> mvo: are there any checks to make sure that a named path falls within the app-specific directories? does the abstract socket use namespacing? (eg, if pkgname is foo, check that abstract matches @foo_...)
<mvo> jdstrand: its essentially what SYSTEMD.SOCKET(5) is doing
<mvo> jdstrand: no checks currently, no
<jdstrand> ok, so I can make some review tools checks for those
<jdstrand> basically, I'll say its ok if it matches the app-specific TMPDIR or SNAP_APP_DATA_PATH
<jdstrand> and I'll do what I suggested for the abstract socket
<jdstrand> mvo: does that sound reasonable?
<mvo> jdstrand: yes!
<mvo> jdstrand: thanks a lot!
<jdstrand> ok
<jdstrand> now, for the bit that really concerns me: socket-user and socket-group
<jdstrand> we don't assign UIDs or GIDs
<jdstrand> how are these supposed to work?
<mvo> jdstrand: welllllll they work for docker because there is  a docker user on the image, but they don't work for anything else right now
<jdstrand> right
<jdstrand> ok
<mvo> so maybe we should not expose that option while there is no way to add users ?
<jdstrand> mvo: so I will just flag those if they are specified at all. when we support UID and GID per-snap (I was thinking this would be opt-in), we can check that it matches that
<mvo> makes sense
<jdstrand> mvo: clearly docker needs it. it is probably a doc change
<jdstrand> either don't expose it in the doc at all, or mention that it will flag a manual review
<jdstrand> mvo: how about I add a bug for the review tools and add a snappy task to update the docs so there is a little more information?
<jdstrand> mvo: and I'll submit an MP for that
<mvo> jdstrand: +1
<jdstrand> ok. it won't be until the end of the week/next week
<jdstrand> mvo: thanks for walking me through this
<mvo> thats fine! thank you!
<jdstrand> mvo: can listen-stream to a relative path or just absolute path?
<mvo> jdstrand: I think it has to be absolute (which makes it interessting)
<jdstrand> I can use current/
 * mvo nods
<jdstrand> mvo: btw, it seems that snappy build still doesn't run the tools by default
<jdstrand> mvo: I thought we agreed they should? note, I think the tools ppa needs to have a review tools upload for the recent 'architectures' changes
<mvo> jdstrand: let me check that, I was sure my branch got merged
<jdstrand> mvo: maybe it is my local snappy that is out of date...
<mvo> jdstrand: no, you are right
<mvo> jdstrand: let me chase that
<jdstrand> ok, I'll work to get the updated review tools into the ppa. again, it'll be a couple days (doc writing)
<mvo> ok
<Chipaca> elopio: mvo: https://en.m.wiktionary.org/wiki/husk
<Chipaca> anyway, i suck at names, so i'm all ears
<elopio> Chipaca: call them "meta", that fixes everything :)
<Chipaca> meta.
<elopio> I'm ok with husks actually (after the explanation of course). I would call that peel, but what do I know?
<Chipaca> elopio: thinking about it, hollejo is not the right word. Hollejo is the white thing under the orange skin and before the "gajos", for example
<Chipaca> elopio: you know what chala (as in "humita en chala") is? that's a husk
<Chipaca> the outer, leafy covering of corn is the husk
<Chipaca> and you remove a husk by husking, which would've made it more confusing in code so i called it 'load' :-p
<elopio> umm, yes. I think my mother calls hollejos the calluses in the fingers. I'm sure I've heard that somewhere, but not entirely sure where.
<elopio> no, chala makes it worst. I've only heard chala rasta. I think they are from argentina. Not sure either.
<Chipaca> https://upload.wikimedia.org/wikipedia/commons/1/13/Humitas_en_chala_tipicas_de_Argentina8.JPG
<Chipaca> mmmmmmmmm
<Chipaca> now i want some
<elopio> Chipaca: you should write a husker interface, and propose it for golang upstream. I'm sure you'll be famous.
 * Chipaca mumbles incoherently and gets back to work
<elopio> I think we call the "chalas of the corn" just "hojas".
<elopio> and humita is something like tamal de elote.
 * elopio goes for breakfast.
<mvo> Chipaca, elopio I still like something about lighweightThing, that makes it realtively easy to parse (although its a bit long :/
 * mvo gets dinner
<Chipaca> yep, long, is why i said maybe just use lightweight
<Chipaca> elopio: re-review https://code.launchpad.net/~chipaca/snappy/systemimage-exported-consts/+merge/273479 if you get a moment please
<elopio> exuvia
<elopio> I doubt we can fix it, but I'm sure we can make it worst :) https://en.wikipedia.org/wiki/Exuvia#/media/File:Euscorpion_exuvia_2.jpg
<Chipaca> exuvia works for me, but i thought it was a bit offbeat :)
<Chipaca> love magicicada exuviae stuck to trees
<elopio> Chipaca: approve, needs commit message.
<Chipaca> on it
<Chipaca> mvo: wrt https://code.launchpad.net/~chipaca/snappy/removed-pkg/+merge/273481, renamed it to RemoteManifestPath, want to take another look?
<Chipaca> mvo: otherwise i'll top-approve :)
<Chipaca> elopio: i didn't know exuviae is also another word for booty. +1 to exuvia.
<elopio> I didn't know that either. I've learned so much today!
<matiasb> hi there! quick question, if I'd want to get some review outcome for a snap package (uploaded to store, triggered manual review during auto-review), who should I ping?
<elopio> matiasb: I don't understand. You want to cause your snap to trigger a manual review?
<matiasb> elopio, nop, I submitted a package (a real one!), but it requires manual review, so I'm waiting for it (for a few days now)
<elopio> matiasb: ah, generally it's Sergio who reviews them.
<elopio> he's back tomorrow.
<matiasb> elopio, ah, ok, thanks :)
<elopio> beuno: can you give me permissions to look at the review queue?
<beuno> elopio, they are rarely handed out. What for?
<elopio> beuno: is there a staging I can look at? I just want to understand the process, and do some exploratory tests with snaps that require manual review.
<beuno> elopio, they are the same ACL list. The process is: run the security scripts (lp:click-reviewer-tools), if they fail they get rejected. You can re-request a manual review, and someone clicks a button
<elopio> beuno: ok, that works. matiasb is your source public? I would like to see the click-reviewer-tools failure in your branch.
<beuno> elopio, click-reviewer-tools is public, the rest isn't
<matiasb> elopio, I packaged transmission, so sources are public; re the errors, I can share a paste with them, but they are related to the fact that I had to tweak the default security profile
<elopio> matiasb: w00t for transmission.
<elopio> matiasb: yes, please paste the error. I'm just curious. I've just reviewed a branch with a test for the reviewer-tools and want to learn more about it to add more tests.
<matiasb> elopio, http://paste.ubuntu.com/12706117/
<elopio> thank you.
<matiasb> elopio, np, it doesn't say much, it complains I'm changing the sec profile :)
<matiasb> I couldn't find another way to work around that
<Chipaca> matiasb: wrt tweaking security profile, that's usually a "talk with jdstrand"
<Chipaca> matiasb: and he, too, can do manual reviews, specifically for this scenario :)
<matiasb> Chipaca, got it, thx; so, when jdstrand is around to take a look... :)
<Chipaca> mvo: so, for when you return: 1. leave husk/Husk; 2. exuvia/Exuvia; 3. package lightweight, type PartList
<Chipaca> mvo: husk.Byname -> lightweight.PartListByName, husks.All -> lightweight.AllPartLists
<Chipaca> mvo: all others end up waaay too long imho :)
<jdstrand> Chipaca, matiasb: fyi, unless the app comes from a trusted vendor, we don't allow security-override or security-policy in the public store (a private store could allow it). having the source open is great, but the snap may not have been built from that source
<jdstrand> matiasb: how extensive are the policy edits? perhaps they are bugs in the templated policy?
<Chipaca> jdstrand: dude, we don't do "bugs".
<Chipaca> they're miscomprehended teenager features
<matiasb> jdstrand, understood; I had to add a few extras to the default templates, as specified in the comment there, happy to workaround if possible
<jdstrand> matiasb: looking at what you put in the review, we could allow /proc/sys/kernel/random/uuid
<jdstrand> matiasb: we can't allow mounts (info leak)
<jdstrand> matiasb: and quotactl is potentially dangerous too. you should probably patch transmission to not need mounts and quatactl
<matiasb> jdstrand, ack, got it; I'll take a look and check if that's possible
<nessita> jdstrand, silly question, how would transmission workaround usage of quotactl since it needs to know if there is free space in disk to keep (or not) downloading torrents?
<matiasb> jdstrand, so I guess I will let you know if I can fix that, thanks
<nessita> ah, perhaps free disk space can be checked with other libraries
<Chipaca> nessita: because snappy doesn't (yet? evar?) support quotas, just checking df is probably enough
<ogra_> would df work ?
<ogra_> (i guess it also needs access to /proc/mounts)
<jdstrand> matiasb: the simplest would be to not perform that check at all. perhaps there is an actual alternative solution.
<nessita> Chipaca, got it, thanks
<ogra_> (i mean, perhaps something like "df ." doesnt need it, never tired)
<matiasb> jdstrand, probably, didn't review the sources in detail, but I guess it should be possible to work something out
<Chipaca> ogra_: df . does need it :(
<ogra_> ah, sad
<Chipaca> [101896.479363] audit: type=1400 audit(1444238994.246:13): apparmor="DENIED" operation="open" profile="hello-world.canonical_env_1.0.18" name="/bin/df" pid=1531 comm="env" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<ogra_> that is actually quite a drawback, i can imagine a lot usecases where apps would want to know the free space in SNAP_APP_DATA_DIR
<Chipaca> maybe there's a way to allow just that?
<ogra_> i doubt any available tool can do that without /proc/mounts or at least without accessing info about the underlying disk SNAP_APP_DATA_DIR lives in
<ogra_> i could be wrong though
<jdstrand> Log: apparmor="DENIED" operation="open" profile="hello-world.canonical_sh_1.0.18" name="/proc/3814/mounts" pid=3814 comm="df" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> yeah
<jdstrand> we need an out of process service
<jdstrand> then we could allow talking to it
<ogra_> snappy freespace
<jdstrand> df isn't in the policy now cause it needs /proc/*/mounts
<jdstrand> well, not snappy
<ogra_> "SNAP_APP_DATA_DIR has 1254MB free"
<jdstrand> apps can't use snappy :)
<ogra_> oh, indeed
<jdstrand> snapd maybe
<jdstrand> anyhoo, something our of process
<jdstrand> out*
<jdstrand> ogra_: hey, I have a couple of questions while I have you
 * jdstrand pulls them up
<ogra_> note that i'm not officially here :P ... but shoot
<jdstrand> these are actually community type questions
<jdstrand> ogra_: but please don't let me distract you from life :)
<ogra_> well, i'm on sick leave til tomorrow ... but pretty bored so just ask
<Chipaca> jdstrand: that's ogra's way of saying, you've just got to make your questions more interesting that his alternatives
<jdstrand> ogra_: do you know if there is a way or if we plan to enable via snappy config ubuntu-core to setup remove logging? ie, tell rsyslogd to send its logs to another syslog server? /etc/rsyslog.d is not a writable-path and systemd's journal doesn't do rfc syslog
<jdstrand> for me personally, making /etc/rsyslog.d a writable-path would be sufficient
<ogra_> lets do that theen
<jdstrand> but it sounds mildly interesting as an ubuntu-core config option
<jdstrand> ok, I'll file a bug
<ogra_> sounds like something thats helpful in IoT cases and such
<ogra_> (and the fix is easy enough)
<jdstrand> ogra_: next question. I tried to setup a static ip via snappy config ubuntu-core, and was successful. however, I didn't know how to setup the resolver. is that possible?
<ogra_> there are /e/n/i options (dns-servers ?) you should be able to use
 * ogra_ checks his static snappy server 
<jdstrand> oh, dns-servers are in there? I read the man page, I must've missed it
<ogra_> (amd64)ogra@aleph2:~$ grep dns /etc/network/interfaces.d/eth0
<ogra_> dns-nameservers 8.8.8.8
<jdstrand> yeah, man interfaces doesn't have it
<ogra_> yeah, seems to work here
<jdstrand> ok, awesome :) that probably needs a doc update for snappy config...
<jdstrand> I'll file a bug on that too
<ogra_> well, thats not snappy specific ... i think it is resolvconf that uses it
<jdstrand> right
<jdstrand> but my point it, it wasn't in 'man interfaces' either
<jdstrand> so I had no way to discover it
<ogra_> right, if we added it we should have patched the manpage
<ogra_> ah, wait
<jdstrand> cause it wasn't there or a snappy example. there is a snappy example for static ip (which I used), but it doesn't include dns-nameservers
<ogra_> man resolvconf has it
<jdstrand> which meant I got an ip address great, but couldn't do much
<ogra_> yeah
<ogra_> we should add it to the example
<jdstrand> I'll file a bug
<ogra_> thx
<jdstrand> next question: is there a way to setup the ntp servers?
<ogra_> hmm
<jdstrand> they seem to try to reach out to the pool ones
<jdstrand> with no way to point to an internal one
<jdstrand> s/internal/another/
 * ogra_ reads /etc/network/if-up.d/ntpdate
 * jdstrand doesn't have that file on latest snappy stable
<ogra_> /etc/default/ntpdate
<ogra_> oh ?
<ogra_> do we already have timedated ?
<jdstrand> I don't have /etc/default/ntpdate either
<jdstrand> systemd+   488  0.0  0.0 100276  2532 ?        Ssl  Oct06   0:01 /lib/systemd/systemd-timesyncd
<jdstrand> is that the same thing?
<ogra_> no, thats the new thing
<ogra_> which i dont know much about yet
<ogra_> ah
<ogra_> it has a -H <host> option
<ogra_> now i'm not sure where to configure it ...
<jdstrand> I guess that is /etc/systemd/timesyncd.conf
<jdstrand> http://www.freedesktop.org/software/systemd/man/timesyncd.conf.html
<jdstrand> but it is not a writable-path
<ogra_> so we need to add that one too
<jdstrand> ok, I'll file a bug for that too
<ogra_> yeah, seems you can just set NTP=
<ogra_> pointing to a server
<jdstrand> the last is sshd_config. it *is* a writable path. I'm just curious if there are plans to do more with it via snappy config
<ogra_> that i dont know :)
<ogra_> wouldnt be hard to add i guess
<jdstrand> well, I'm not trying to create more work
<ogra_> it is riteable because cloud-init generates the keys in that dir
<jdstrand> even though I did. though just barely :)
<ogra_> well, useful work ... everything you asked about is valid :)
<jdstrand> cool and thanks-- this was quite helpful
<ogra_> :)
 * Chipaca adds df to the rest api
<jdstrand> ogra_: hope you feel better and try not to be too bored :)
<ogra_> i'm fine, i had drilled some screw anchors into my jaw last thu ... recovery is in the last stages
 * Chipaca watches the rest api get in a race with systemd for what's left of posix
<ogra_> we should fork systemd to systemd-posix
<ogra_> ;)
<ogra_> seems forking is in fashion currently
 * ogra_ just saw the news about mjg59
 * ogra_ goes back to icepack->cheek
<Chipaca> jdstrand: ogra_
<Chipaca> (amd64)ubuntu@localhost:~$ hello-world.env
<Chipaca> /writable has 368392 blocks of 4096 bytes available (~93.390998%)
<Chipaca> jdstrand: ogra_: http://pastebin.ubuntu.com/12709065/
<Chipaca> oh, also matiasb ^
<matiasb> nice!
<matiasb> Chipaca, how can I use that?
 * matiasb looks the pastebin
<Chipaca> matiasb: gcc -D_GNU_SOURCE -Wextra -Werror -o /tmp/fakedf /tmp/fakedf.c
<matiasb> Chipaca, awesome, will try it when I get a few
<Chipaca> matiasb: then, fakedf $SNAPP_APP_DATA_PATH
<Chipaca> or fakedf $SNAP_APP_USER_DATA_PATH
<Chipaca> s/SNAPP/SNAP/ soz
<Chipaca> and apparently that's enough :)
<Chipaca> matiasb: also python has statvfs which is the same call, if you're doing python
<matiasb> Chipaca, this is for transmission, so C should be
<Chipaca> matiasb: and man 3 statvfs for the fields in the struct if you need some other info
<matiasb> Chipaca, perfect, thx!
<Chipaca> np
<Chipaca> maybe we should ship this :)
<Chipaca> hah! we already do
<Chipaca> /usr/bin/stat
<Chipaca> jdstrand: ogra_: (dunno if you're still interested in this, but) e.g. â/usr/bin/stat -f -c "%a * %s" /writable/â
<jdstrand> Chipaca: oh, nice! :)
<Chipaca> megabytes: echo $(($(/usr/bin/stat -f -c '%a * %s/1024/1024' /writable/)))
 * jdstrand add a note to update snappy-security to recommend that
 * Chipaca stops
#snappy 2015-10-08
<mvo> Chipaca: \o/ for your excellent code review
<clobrano> morning o/
<Chipaca> mvo: if you s/FIMXE/FIXME/, it'll get picked up by some tools better
<mvo> hey clobrano and Chipaca
<mvo> Chipaca: heh, thanks. sounds like I need more tea :)
<Chipaca> mvo: how was this not obvious when I clearly said âbÃ¤ bÃ¤ svarta fÃ¥râ
<mvo> :)
<mvo> fixed
<Chipaca> ouh
<Chipaca> one thing
<Chipaca> mvo: you're using %v with the output of cmd.Output()
<Chipaca> mvo: that might not be what you want
<Chipaca> cmd.Output() gives you a []byte
<Chipaca> and []byte looks like [20 75 124 94 ...]
<Chipaca> with %v i mean
 * Chipaca can only handle short sentences this early
<Chipaca> mvo: suggest using %s instead, or string(output) (although that creates a third copy)
<Chipaca> although
<Chipaca> that'd break your error message
<Chipaca> because output will probably have \n's in it
<Chipaca> mwhudson: congrats
<Chipaca> mvo: not the first time i'm thinking we should hide all this stuff inside helpers somewhere :-/
<mvo> Chipaca: uh, good point, let me fix this as well
<Chipaca> mvo: bottom line would be: either remove the ()s, or %#q and string(output)
<Chipaca> um
<Chipaca> %q, not %#q
<Chipaca> that is: either accept the \n's you'll get with %s, or quote the thing at the expense of some memory
<Chipaca> it's build anyway, not a long-lived thing :)
<mvo> Chipaca: indeed, let me add %q
<Chipaca> and now i'm off to take the boys to school
<mvo> Chipaca: see you
<Chipaca> bbi~1h
<mwhudson> Chipaca: \o.
<fgimenez> good morning
<fgimenez> hi mvo, how are you?
<mvo> hey fgimenez, good morning. I'm good, how are you?
<fgimenez> mvo, fine, a little cold this morning but anyways :)
<fgimenez> mvo, i've been working on a logging package for the integration tests, can you have a look when you have the time https://code.launchpad.net/~fgimenez/snappy/integration-tests-verbosity-flag/+merge/273670 ?
<fgimenez> mvo, no rush at all :)
<mvo> fgimenez: sure, happy to do that
<fgimenez> mvo, thanks a lot, specifically if you could address elopio's question it would be great
 * mvo nods
<dholbach> good morning
<davidcalle> Morning o/
<mvo> fgimenez: I commented in the MP, hope it makes sense, please let me know if there are any quesitons
<fgimenez> mvo, ok thx :)
<Chipaca> mvo: i have good news and bad news
<Chipaca> oh, wait
 * Chipaca checks something
 * mvo waits
<Chipaca> mvo: i have no bad news
<mvo> *puhhh*
<mvo> what was the bad news?
<Chipaca> mvo: unless "i didn't know %q worked that way with []byte" is bad news, nothing :)
<Chipaca> so the good news is, i learned that (wonder how many times i learned it before)
<Chipaca> mvo: now, can we talk about husks? :)
<mvo> Chipaca: you mean about leightweights ;)
<mvo> Chipaca: is the other stuff addressed? if so and we can not find a better name husks win
<Chipaca> mvo: i meant exuvia, sorry
<Chipaca> "other stuff"?
 * Chipaca looks
<Chipaca> i thought that was all there was
<mvo> Chipaca: I can't remember if so, then great, let me double check
<mvo> Chipaca: some inline comments about tiny bits (comments, the one panic)
<Chipaca> dude, i'd missed those entirely
 * Chipaca reads
<mvo> Chipaca: I like lightweights, so if its not too bothersome and makes stuff not too ugly I'm slightly in favour of changing (but not strongly)
<davmor2> mvo: is that because you can't lift the heavy one ;)
<mvo> davmor2: lol
<JamesTait> Good morning all; happy Thursday, and happy World Sight Day! ð   ð   ð
<Chipaca> mvo: question for you
<Chipaca> mvo: was going with lightweight.PartList
<Chipaca> mvo: but then i thought, does that make you think you can range over it? should i call it a PartBag instead?
<Chipaca> mvo: or did you mean just call it lightweight.Lightweight?
<mvo> Chipaca: hm, PartBag sounds ok, PartList is probably ok as well, but you are right, there is this association with a real list then
 * Chipaca nods
<Chipaca> mvo: hmmmmmm
<Chipaca> mvo: LoadActive() is â	return h.Load(h.ActiveIndex())â
<Chipaca> mvo: not sure it's worth it :)
<mvo> Chipaca: indeed, wasn't there error checking on the index before? or am I misrembmering?
<mvo> definitely mistyping ;)
 * Chipaca looks at merged-list
<Chipaca> mvo: there is error checking
<Chipaca> hmm
<Chipaca> mvo: so LoadActive could return nil,nil if activeIndex<0, or nil, ErrNoActiveIndex or sth
<Chipaca> either way the caller would have to handle it differently
<mvo> Chipaca: aha, ok, in this case its not worth it I agree
<Chipaca> that is, today: idx:=h.ActiveIndex(); if idx<0{not found}; if h.load(idx) errors { internal error }
<mvo> Chipaca: I just noticed in the MP what looked like repeating code that could be done in a single place, but if it actually can't â¦
<Chipaca> with active index: part,err:=h.LoadActive(); if err=NoActive{not found} else if err != nil {internal}
<Chipaca> mvo: promise i'll revisit it in a month to see how we're actually using it and add convenience methods :)
 * Chipaca adds a calendar thing
<mvo> Chipaca: deal!
<Chipaca> mvo: i think that addresses all your issues, please take a look when you cna
<Chipaca> can*
<sergiusens> morning
<Chipaca> uia! un sergio!
<Chipaca> sergiusens: morning
<mvo> Chipaca: thanks, will do
<mvo> sergiusens: good morning
<Chipaca> mvo: ah, one question about the squashfs build branch
<Chipaca> mvo: i heard something about moving build to snapcraft
<Chipaca> mvo: is that accurate?
<mvo> Chipaca: yes, eventually
<mvo> Chipaca: we still need something for our tests in snappy I think
<Chipaca> ok
<sergiusens> Chipaca, mvo the code base for lp:snappy looks so different 5 days past
<Chipaca> mvo: yes, but once snapcraft does build, let's not have two implementations of it :)
<mvo> Chipaca: yeah, I agree, at the same time I don't want to be distracted by this just now :)
 * Chipaca nods
<Chipaca> speaking of changes to lp:snappy, how do you remove tags from it?
<Chipaca> i added tags when playing with them, removed them, but they have appeared upstream somehow, and no amount of removing them makes them go away :-(
<sergiusens> Chipaca, as in bzr tags?
<Chipaca> yes
<sergiusens> Chipaca, --overwrite I think, it is extremely complicated
<mvo> does bzr tag --delete work?
<Chipaca> it works locally
<Chipaca> but --overwrite-tags says it's got nothing to do
<mvo> but not with a lp prefix?
<mvo> Chipaca: what tag should go?
<Chipaca> mvo: " " and "\t"
<sergiusens> Chipaca, interesting tags, those should stay :-P
<Chipaca> sergiusens: um. Ok. Don't --print-ids then.
<Chipaca> --show-ids i mean
<Chipaca> whaaaat
<Chipaca> no LastIndexByte before 1.5
<Chipaca> sigh
 * Chipaca fixes
<Chipaca> hmm
<Chipaca> tests pass here, with go 1.3. fail in tarmac. map output for failed tests is identical for obtained/expected.
<Chipaca> wait, they're not all identical
<Chipaca> differing keys:
<Chipaca>     'installed_size':  expected '208', got '8260'
<Chipaca> wtf
 * guest42315 EWWWW mailing lists 
<Chipaca> guest42315: ?
<guest42315> Chipaca, oh sorry /me /ame
<Chipaca> sergiusens: ping
<sergiusens> Chipaca, pong
<Chipaca> sergiusens: any ideas wrt tests failing in tarmac in weird ways?
<sergiusens> Chipaca, weird ways, no; what are you running?
<Chipaca> sergiusens: in snappy, run-checks locally passes fine, every time, with go 1.5 and 1.3, starting from a pristine directory (just like tarmac does it)
<Chipaca> sergiusens: in tarmac, https://code.launchpad.net/~chipaca/snappy/husk/+merge/273482/comments/690882
<Chipaca> sergiusens: 4 failed tests, of which 1 the obtained/expected mappings are apparently identical
<Chipaca> sergiusens: and the others differ in "installed_size", with 8k extra on disc
<Chipaca> oh, wait, 8k extra
<Chipaca> hmm
<sergiusens> Chipaca, 'snappy unpack' and snappy installed on tarmac
<sergiusens> Chipaca, could it be that?
<sergiusens> Chipaca, not sure how unit the unit test is :-)
<Chipaca> the 8k might be because i use tmpfs
<Chipaca> snappy unpack not involved
<sergiusens> Chipaca, don't use ue tmpfs locally and why would it be different?
<sergiusens> if both places use tmpfs
<Chipaca> sergiusens: in tmpfs a directory's du is 0, an empty file's du is 0
<Chipaca> sergiusens: outside of tmpfs, both of those are 4k
<Chipaca> or 2k or 16k
<Chipaca> block size
<Chipaca> dangit :(
<Chipaca> sergiusens: thank you!
<sergiusens> Chipaca, you did it all by yourself ;-)
<Chipaca> sergiusens: you're a good sounding board
<biezpal> Hi all! Is it hard to make our oem snap packages signed? :)
<Chipaca> biezpal: put them in the store?
<biezpal> Chipaca, is it enough to make it signed? actually, we just don't like "sideload" prefix :)
<biezpal> and random string in version field..
<biezpal> because of https://bugs.launchpad.net/snappy/+bug/1498396
<ubottu> Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New]
<Chipaca> oh, bug 1498396
<ubottu> bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,Fix released] https://launchpad.net/bugs/1498396
<Chipaca> i knew there was a bug about it but didn't find it when making the branch. fixed, anyway.
<Chipaca> biezpal: data dir now has a 'current' link
<biezpal> Chipaca, in current edge this bug is still exists
<Chipaca> biezpal: anyway, getting it from the store is (for now) the only way to get it auth'ed
<Chipaca> biezpal: really?
<Chipaca> maybe i should've checked first :-/
 * Chipaca checks now
<soffokl> Chipaca, we are build it from edge channel
<soffokl> sudo ubuntu-device-flash core 15.04 --channel edge --oem parallella_4.0_all.snap --device-part=device.tar.xz -o parallella1.img
<Chipaca> soffokl: biezpal: 15.04?
<Chipaca> yes, 15.04
<Chipaca> sigh
<Chipaca> needs backporting i guess
<Chipaca> i was sure that was included in the latest 15.04
<Chipaca> ah. no. it's for the next one. i remember now.
<biezpal> for the next one edge?)
<Chipaca> i mean: it's in rolling/edge
<Chipaca> i guess it's not on stable
<Chipaca> gah
<Chipaca> i mean not on 15.04
<Chipaca> biezpal: if youc reate the symlink by hand for now, things'll sort themselves out
<biezpal> Chipaca, sigh
<biezpal> thanks
<Chipaca> $ ls -l /var/lib/apps/hello-world.canonical/
<Chipaca> total 4
<Chipaca> drwxr-xr-x 2 root root 4096 Oct  8 12:03 1.0.18
<Chipaca> lrwxrwxrwx 1 root root    6 Oct  8 12:04 current -> 1.0.18
<Chipaca> biezpal: ^ :)
<biezpal> Chipaca, handmade link? :)
<Chipaca> biezpal: no, rolling edge
<Chipaca> biezpal: s/15.04/rolling/ in your u-d-f command above and you get that
<Chipaca> but rolling is the one we *actively* break :)
<Chipaca> so beware
<ogra_> we should really default to do development in 15.04 and forward port instead of the other way round
<biezpal> Chipaca, ok, i guess we can use rolling for development purposes
<sergiusens> Chipaca, can I get your opinion on https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 ?
<Chipaca> sergiusens: you can try :)
<sergiusens> Chipaca, I don't like the MP, but I don't know what else to do
<Chipaca> sergiusens: i guess the removing the dangling one if unresolved is the bit you don't like?
<Chipaca> sergiusens: BTW, $ dpkg -S /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts
<Chipaca> openjdk-7-jre-headless:amd64: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts
<sergiusens> Chipaca, oh, then that is fine and covered, what about libc6?
<sergiusens> Chipaca, I might have been having issues with ':'
<sergiusens> Chipaca, and wait
<sergiusens> Chipaca, you just confused me, the thing it links to is what I can't figure out where it comes from
<sergiusens> Chipaca, as in /etc/ssl/certs/java/cacerts
<Chipaca> ca-certificates-java i'd assume
<Chipaca> oh, oh, oh
<Chipaca> i know what's missing here
<sergiusens> Chipaca, nope
<sergiusens> Chipaca, not provided by ca-certificates-java
<Chipaca> ok, need to dig a bit more
<Chipaca> but
<Chipaca> you need to loop
<sergiusens> to loop?
<Chipaca> or does realpath do that?
<Chipaca> if it's a symlink-to-a-symlink
<sergiusens> Chipaca, oh, I can try (s/realpath/readlink/ I suppose)
<Chipaca> realpath might resolve it; check (or read docs)
<Chipaca> so
<Chipaca> that file
<Chipaca> is *probably* created by ca-certificates-java
<Chipaca> via /etc/ca-certificates/update.d/jks-keystore
<Chipaca> sergiusens: by running /usr/share/ca-certificates-java/ca-certificates-java.jar
<Chipaca> sergiusens: realpath loops
<Chipaca> sergiusens: you're set
<sergiusens> Chipaca, this MP won't work :-)
<Chipaca> still trying to understand it tbh :)
<Chipaca> ah!
<sergiusens> Chipaca, look at the bug
<Chipaca> sergiusens: so, yes, change the first readlink to realpath
<Chipaca> ... or something! i dunno
<Chipaca> programming is complicated, i'm going to have a cuppa tea
<sergiusens> Chipaca, so we don't run postinst for 'stage-packages'
<sergiusens> Chipaca, and jdstrand is not using any of the java plugins
<sergiusens> Chipaca, just downloading debs, so he doesn't have the certs; and I can't just copy because a bare bones system won't have them either
<Chipaca> right
<sergiusens> Chipaca, then there is libc6; do we want those libs in the snap or should they be allowed as dangling symlinks?
<Chipaca> sergiusens: libc6 is problematic, because nss needs to be exactly the same
<Chipaca> sergiusens: so copying it in won't work
<Chipaca> sergiusens: that's how you get segfaults or, worse, weird behaviour
<sergiusens> Chipaca, right, so I need to circle back with jdstrand to get more smarts in the click-review tool and also make sure that using 'stage-packages' requires hand holding in some cases
<biezpal> Chipaca, cat /etc/lsb-release
<biezpal> DISTRIB_ID=Ubuntu
<biezpal> DISTRIB_RELEASE=15.10
<biezpal> DISTRIB_CODENAME=wily
<biezpal> DISTRIB_DESCRIPTION="Ubuntu Wily Werewolf (development branch)"
<biezpal> (Parallella)ubuntu@localhost:~$ ls -l /var/lib/apps/parallella/
<biezpal> total 4
<biezpal> drwxr-xr-x 2 root ubuntu 4096 Oct 8 2015 ICaVaRAVXWYS
<ubottu> Ubuntu bug 4096 in meld (Ubuntu) "meld: merge new debian version" [Medium,Fix released] https://launchpad.net/bugs/4096
<soffokl> sudo ubuntu-device-flash core rolling --channel edge --oem parallella_4.0_all.snap --developer-mode --device-part=device.tar.xz -o parallella2.img
<Chipaca> ...
<Chipaca> interesting :-/
<Chipaca> wait
<Chipaca> that parallela package
<Chipaca> that was installed by u-d-f
<Chipaca> and that u-d-f is probably not recent enough to include these changes?
<Chipaca> soffokl: apt-cache policy ubuntu-device-flash if you please
<soffokl> ubuntu-device-flash:
<soffokl>   Installed: 0.31-0ubuntu1
<soffokl>   Candidate: 0.31-0ubuntu1
<soffokl>   Version table:
<soffokl>  *** 0.31-0ubuntu1 0
<soffokl>         500 http://ppa.launchpad.net/snappy-dev/tools/ubuntu/ vivid/main amd64 Packages
<soffokl>         100 /var/lib/dpkg/status
<soffokl>      0.20-0ubuntu1 0
<soffokl>         500 http://kg.archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages
<sergiusens> Chipaca, meh, ca-certificates-java.jar harcodes to /etc :/
<Chipaca> sergiusens: when/how does u-d-f get rebuilt?
<Chipaca> mvo: ok to top-approve merged-list?
<mvo> yes, done so
<Chipaca> mvo: no files were sneaked in to that branch last minute*
<mvo> :P
<Chipaca> * or so you think
<Chipaca> snuck, not sneaked. sigh.
 * ogra_ hands Chipaca a pair of sneakers
 * Chipaca snickers
<ogra_> yummy peanuts and caramel
 * ogra_ wishes he could eat that :(
<jdstrand> sergiusens: I guess you are saying some things should symlink out (libc6) but some things shouldn't (cacerts)
<jdstrand> sergiusens: if you file a bug against the click-reviewers-tools project, I'll fix it. I have a couple of other things to fix this week
<jdstrand> sergiusens: just let me know what is a legitimate symlink
<Chipaca> ogra_: you want one of these: http://pickupthefork.com/wp-content/uploads/2014/10/IMG_8754.jpg
<ogra_> mean !
<ogra_> (no sugar for me for another week  .... )
<Chipaca> ogra_: oh! i thought it was the nuts you couldn't have
<ogra_> well, i cant bite nuts :)
<ogra_> (thats another 4 weeks)
<Chipaca> hence why i thought one of those would give you the nuts+caramel thing without having to bite nuts
<ogra_> heh
<Chipaca> see, i'm so thoughtful it hurts
<sergiusens> jdstrand, ok, it's mostly libc6 things as per what we discussed with Chipaca; for cacerts, I'm solving it in the jdk plugin, the error for it is fine, but I can't fix it in a generic way for stage-packages uses because some of these are postinst hook created.
<ogra_> yay, maintainer scripts
<ogra_> :P
<jdstrand> sergiusens: won't the jdk plugin pull in a bunch of stuff I don't need?
<jdstrand> sergiusens: why can't you examine the symlinks in the directory? perhaps you could prompt to include them from the system?
<sergiusens> jdstrand, I have as a first approach https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826
<sergiusens> jdstrand, I just feel it would be weird
<jdstrand> sergiusens: at the very least, you should detect them and report them with suggestions on how to fix them, because if you don't then snapcraft will generate a package that fails review. the review tools could be the place to detect them and make a suggestion if you'd prefer
<jdstrand> but it seems like snapcraft is in a position to fix things up
<mvo> Chipaca: there are more branches ftw, just in case you are bored ;)
<Chipaca> i saw nothing
<mvo> fgimenez, elopio: could one of you install squashfs-tools on the tarmac server please?
<jdstrand> eg, "oh, cacerts is pointing to something in /etc. let me copy what is in /etc to ./snap/etc and adjust the symlink
<jdstrand> "
<jdstrand> sergiusens: ^
<sergiusens> jdstrand, yeah, I'll go with that branch and polish a bit to not include libc6 links
<sergiusens> Chipaca, u-d-f, when you dput it
<jdstrand> sergiusens: cool. btw, I don't care if you copy in place (your mp) or copy to the intended place and adjust the link (what I suggested). however, what I suggested is probably more robust if you have multiple symlinks to the same thing
<sergiusens> Chipaca, ideally the ubuntu-snappy stuff goes to the archive and then gets rebuilt and it does so prior to a release
<sergiusens> jdstrand, right, it could save more space, not sure if it would when everything is squashfs
<fgimenez> mvo, sure, give me a minute
<fgimenez> mvo, done http://paste.ubuntu.com/12714696/
<Chipaca> ogra_: did you get too track down the ipv6-only thing?
<Chipaca> (were you [going to be] doing that?)
<ogra_> ipv6-only ?
 * ogra_ hasnt heard of it
<Chipaca> fgimenez: elopio: you might want to tell ogra_ about it :)
<Chipaca> ogra_: rpi2 was coming up with only an ipv6 address (and i think fgimenez got it in kvm also once, but not consistent)
<Chipaca> ogra_: but i don't know the details
<ogra_> weird
<fgimenez> ogra_, this is the bug https://bugs.launchpad.net/snappy/+bug/1503329
<ubottu> Launchpad bug 1503329 in Snappy "not getting an ipv4 address on the first boot" [Undecided,Confirmed]
<ogra_> fgimenez, well, there was a kernel update between 186 and 187 i think
<ogra_> (no idea if related or not)
<tedg> sergiusens: So I know we wanted to get rid of the situation where plugins subclass other plugins.
<tedg> sergiusens: Did we also want to get rid of 'requires' in the plugin yaml?
<sergiusens> tedg, hmm, wasn't aware of subclassing
<sergiusens> tedg, as we discussed this last week https://code.launchpad.net/~sergiusens/snapcraft/1500902/+merge/273444
<sergiusens> still needs a round of testing for local plugins, but works fine otherwise
<tedg> sergiusens: So I think that's fine, but the specific case here is a plugin that needs Python3, including PIP support, so it doesn't make sense to copy-and-past.
<tedg> paste (should have cut-and-pasted that from somewhere)
<tedg> sergiusens: So it'd like to basically have the python3 plugin run first for everything, which is kinda what requires did.
<sergiusens> tedg, we have plugins already that base out of python3
<sergiusens> tedg, oh, the requires problem and pull phases problem is a problem of the past; it is fine if a pull phase for every part can't be completed due to an 'after'
<sergiusens> tedg, in the end, lp should not be a blocker (words out of beuno's mouth ;-) )
<sergiusens> Chipaca, mind taking another look at https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826 ?
<sergiusens> Chipaca, this time it is better
<sergiusens> ogra_, why did you break my 2fa? :-P
<ogra_> sergiusens, well, i was bored y'know
<ogra_> (what do you mean ? )
<ogra_> sergiusens, do you mean the authenticator app breakage ?
 * ogra_ fully blames bzoltan_ for that :P
 * bzoltan_ takes the blame ... do you want to punish me ;P
<ogra_> i guess he will throw argentinian steaks at you :)
<sergiusens> ogra_, hah, it is my 2fa device so now I am sort of in limbo :-P
<matiasb> Chipaca, jdstrand, o/ good news, I managed to work-around transmission issues with mount/quotactl by using statvfs, and it works! I'll be uploading the fixed version later today :)
<jdstrand> matiasb: great! :)
<ogra_> yay
<matiasb> jdstrand, btw, re random/uuid, everything seems to work ok even if that is denied by apparmor; I was thinking if I should I upload the package without any profile customization then? once the perm is added to the default template, future installs will get access? (it seems the profile is generated from the default template on install, right?)
<jdstrand> matiasb: yes on all counts. if it works fine, but remove security-policy. it will use the default template with network-client. you'll have the denial until I do the upload
<jdstrand> s/but remove/then remove/
<matiasb> jdstrand, great, that's my plan then; that should go through review without any issues and without requiring manual intervention
<jdstrand> matiasb: with that change and using 'architectures' in your package.yaml, it will pass automated review
<jdstrand> yep
<matiasb> correct
<Chipaca> matiasb: you're building it multi-arch, yes? pretty please?
<matiasb> Chipaca, yeap :)
<Chipaca> sweet
<Chipaca> pitti: you around? question about removing a service from systemd's status
<pitti> hey Chipaca
<Chipaca> pitti: hi!
<Chipaca> pitti: right now, if you have a snap with a service, and upgrade it, the old service never goes away from systemctl
<Chipaca> pitti: are we doing something wrong?
<Chipaca> we stop the service, disable it, reload-daemon
<pitti> Chipaca: you mean you don't stop the old service before upgrading?
<Chipaca> we stop it
<pitti> ah, then it should be stopped, no?
<Chipaca> we disable it
<Chipaca> we remove the service file
<Chipaca> we do a reload-daemon or daemon-reload or whatever that was
<pitti> daemon-reload
<Chipaca> but it's still there in the systemctl output
<pitti> Chipaca: with --all? yes, that's right
<pitti> shoudl be inactive/dead then, or is it still running?
<Chipaca> inactive/dead/not found
<Chipaca> not with --all though
<pitti> this happens a lot, particularly with instantiated units (foo@.service)
<pitti> Chipaca: hm, by default "systemctl" only lists active units -- if it's listed there as inactive that's a bug indeed
<Chipaca> systemctl show, not status, sorry
<pitti> ah
<pitti> you can still query e. g. the journal from the old units, or their status
<sergiusens> Chipaca, another smaller one when you feel like dropping a finger on the approve button https://code.launchpad.net/~sergiusens/snapcraft/1504174/+merge/273853
<Chipaca> pitti: oh, wait, i spotted the bug. and it's mine. sorry to bug you :-/
<Chipaca> pitti: wouldn't've spotted it without you though, so thanks ! :)
<pitti> heh
<pitti> Chipaca: so, this might just be a cosmetical thing -- systemctl status anything.service will say "not found"
<pitti> (and exit with 3)
<Chipaca> pitti: i was getting a list of all installed snaps
<pitti> Chipaca: except that for services which did exist in the past you still get the old journal
<Chipaca> pitti: not filtering by "active"
<Chipaca> so i'm *asking systemctl for it myself*
<pitti> with completely bogus names you just get not-found
 * Chipaca puts the brown paper bag back on
 * pitti pats Chipaca, no worries :)
<ogra_> sergiusens, do we have a "null" plugin now ?
<ogra_> or do i still have to abuse the copy plugin (and copy an empty README file) to just get some deb binary content
<ogra_> (i thinnk someone said that was planned)
<elopio> fgimenez: would it be too hard to add levels to the snappy/log ?
<fgimenez> elopio, not sure, i can try in a branch
<elopio> fgimenez: it would be awesome if we could make this an independent library. But just if the effort required is not too much.
<elopio> fgimenez: also, there's https://github.com/golang/glog
<fgimenez> elopio, ok thanks, i'll take a look
<sergiusens> ogra_, it was an idea, but is there any case where that would produce a good snap?
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml
<sergiusens> jdstrand, this should solve minecraft (except for libc6 libs) https://code.launchpad.net/~sergiusens/snapcraft/1500505/+merge/273826
<ogra_> sergiusens, ^^^ thats what i use now to quickly pack a tool if i need it ...
<sergiusens> ogra_, heh, the 'nop' plugin I need to propose
<ogra_> its just silly to have an empty README file to copy around just to get the staging packag
<ogra_> e
<ogra_> i mean it doesnt bother me to do it like that, it just feels a little wrong inside :)
<elopio> this is cool https://github.com/bluele/factory-go
<mvo> elopio: nice!
<jdstrand> sergiusens: thanks! I assigned the crt bug to me. I'll fix it tomorrowish
<sergiusens> elopio, I hope you like this http://bazaar.launchpad.net/~sergiusens/snapcraft/1500902/revision/235 (I am finally getting rid of most of the getattr's in there too)
 * sergiusens heads out for some errands
<tedg> sergiusens: I'm having a heck of an issue getting pip to install the aws cli binary
<tedg> sergiusens: Any ideas there. It installs the library, but not the actual thing in /usr/bin
<tedg> Considering just working around it at this point, but seems like defeat.
<sergiusens> tedg, does the setup.py declare any scripts?
<sergiusens> tedg, can you point be to the package name?
<tedg> sergiusens: It's the awscli from pypi
<tedg> Let me look for the setup.py
<tedg> Oh, oops. I did a snapcraft clean. Give me a sec to have that :-)
<tedg> sergiusens: Doesn't seem to have a setup.py
<sergiusens> tedg, it works fine in a pyvenv
<tedg> Hmm, bother.
<sergiusens> tedg, it has scripts in setup.py, it should just work
<tedg> sergiusens: I gonna have to look more tomorrow, seems so simple, sure it's a one character change.
<sergiusens> tedg, which also makes me wonder, have you tried making the python plugins work with pyvenv?
<tedg> sergiusens: we had wanted to avoid that, apparently it changes a lot, mostly stuff that the python interpreter should do on it's own. But apparently makes things weird for other cases.
<tedg> sergiusens: So, no, but I was asked to avoid it.
<sergiusens> tedg, ok; seems like we should use it from what others have said
#snappy 2015-10-09
<Rlyeh> Yesterday, I Downloaded Snappy from "http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz"for BBB
<Rlyeh> But the system didn't boot
<Rlyeh> I checked the "system-boot partition, the "uenv.txt" was empty
<Rlyeh> "system-boot" partition
<Rlyeh> And there was a install.yaml! It was not available in the version 1!
<Rlyeh> Well, do you know how can I boot the new snappy on my BBB?
<Rlyeh> Should I have to copy the uenv.txt content from version 1 to this new version? or the boot mechanism is totally changed in new version?
<Rlyeh> Here is the uenv.txt in version 1, 2 and 3 -> "http://paste.ubuntu.com/12720512/"
<Rlyeh> It's same
<Rlyeh> No solution for boot problem?!!!
<biezpal> Rlyeh, afaik, uEnv.txt should be empty. There is snappy-system.txt with all required variables
<Rlyeh> It's not booting :(
<Rlyeh> BBB jumps to debian on emmc
<tbr> Rlyeh: did you hold down S2 before connecting power to the BBB?
<clobrano> Buongiorno :)
<fgimenez> good morning
<davidcalle> Good morning
<dholbach> good morning
<longsleep> good morning snappy
<longsleep> biezpal: it is normal that uEnv.txt is empty. Snappy uses uboot.env for booting
<longsleep> biezpal: Do you have a serial console, to check what u-boot is doing?
<longsleep> biezpal: ah sorry, it was Rlyeh who asked that question
<biezpal> longsleep, np :)
<ogra_> well, Ryleh most likely didnt press S2
<longsleep> ogra_: i should probably get a BBB for testing - S2 is a button?
<ogra_> yeah ... also called "user button"
<longsleep> ok - and that controls what to boot or why does one have to press it?
<ogra_> you have to hold it down for the first time you want to boot from external media (subsequent boots from SD dont need it)
<longsleep> ahh - the bbb only boots from nand by default - i get it thanks
<ogra_> well, eMMC
<longsleep> is the eMMC removable ?
<ogra_> nope
<longsleep> i see - can snappy also boot when put on the eMMC then?
<ogra_> never tried :)
<tbr> longsleep: you can nuke the MLO on eMMC, then it will default to SD
<longsleep> tbr: right, but would be nice to avoid using an external media or have the sd available for storage
<ogra_> buut given we boot based on labels i wouldnt see why not
<ogra_> as long as you can name the partitions correctly on the MMC
<longsleep> it works fine for the odroid, though the eMCC is removable there and we do not use it because of the cost
<tbr> ogra_: I offered a while ago to look into the install script that debian uses and how that could be adapted, but then some handwaving ensued
<longsleep> how do you flash the eMMC - is there some boot loader / fastboot thing?
<longsleep> i mean if you cannot put it into your pc
<tbr> longsleep: you could flash it over USB or UART, but usually you just boot from an SD and write from the booted system to the eMMC
<ogra_> there is work going on to create a recovery img we ship in all installs ...
<ogra_> that would have a dd like installer i guess
<ogra_> and factory reset etc
<longsleep> yeah that would be nice
<longsleep> tbr: i just read the docs about it, thanks
<longsleep> ogra_: do you have an idea what happens if you have partitions with the same label on eMMC and SD ?
 * longsleep wonders which one is used
<ogra_> nope
<ogra_> havent tried
<JamesTait> Good morning all; happy Friday, and happy Curious Events Day! ð
<tbr> https://github.com/RobertCNelson/tools/tree/master/scripts - if someone wants to take a look how to adapt
<Chipaca> elopio: fgimenez: you around?
<fgimenez> Chipaca, yep
<Chipaca> fgimenez: i have a branch up for review that probably breaks stuff
<Chipaca> fgimenez: could you / would you take a look?
<Chipaca> fgimenez: https://code.launchpad.net/~chipaca/snappy/auth/+merge/273684
<fgimenez> Chipaca, sure, which one?
<fgimenez> Chipaca, ok thanks :)
<Chipaca> fgimenez: basically all non-GET rest api tests will fail
<Chipaca> fgimenez: or should :D
<Chipaca> need to add something to first boot to set a default password
<fgimenez> Chipaca, ok, thx i'll check :) we are currently testing post to packages
<Chipaca> neat
<fgimenez> Chipaca, it fails \o/
<Chipaca> heh
<Chipaca> fgimenez: thanks
<Chipaca> now we need to decide how to un-fail it :)
<fgimenez> Chipaca, ok, the tests need some adjustments though, it was passing at first :)
<Chipaca> fgimenez: oh? how?
<fgimenez> Chipaca, they was using /usr/bin/snapd instead of the compiled one
<Chipaca> lel
<fgimenez> Chipaca, also, we were checking for a 405 method not allowed response in unhandled verbs
<Chipaca> that is correct
<Chipaca> but now you'd get a 401 before that
<fgimenez> Chipaca, yes, we need to change that in the test
<Chipaca> you'd still want to check for the 405 once you're sending in credentials
<fgimenez> Chipaca, ah, ok, then that's ok
<Chipaca> ogra_: you around perchance?
<ogra_> no, not perchance ...
<ogra_> ... just regular
<Chipaca> :)
<ogra_> :)
<Chipaca> ogra_: so, REST API now needs creds to do stuff
<ogra_> whee
<Chipaca> ogra_: including things like, um, setting up creds
<ogra_> lol
<Chipaca> (nothing of this is landed yet ;)
<ogra_> so i guess we should have some snappy config way to set this to a sane default (i.e. if --developer-mode enable ubuntu/ubuntu)
<Chipaca> that, and/or "snappy passwd"
<ogra_> ah, thats new ?
<Chipaca> that's non-existent
<Chipaca> that's what i'm asking :)
<ogra_> can we also enforce updating of the  pw ?
<Chipaca> ogra_: you mean, pw age policy?
<ogra_> so that we could ship with a default on the images but enforce the update on first login via the REST api ?
<ogra_> yeah, something like the pw age policy
<ogra_> but if i dont have ssh enabled i need to be able to get in once to set a new one
<Chipaca> that's a good point, we probably want that
<Chipaca> but it's a chunk of work :)
<ogra_> yeah, i guess
<Chipaca> and not sure of the details of it
<Chipaca> ogra_: snappy config such that the oem can set default pw was what i was thinking, with it defaulting to ubuntu/ubuntu if in dev mode
<Chipaca> ogra_: and i didn't know if we'd also need a snapp passwd thing
<Chipaca> ogra_: password aging, and password policy in general, wasn't in what i'd been thinking of doing
<ogra_> well, we dont use --developer-mode on the official images we offer
<ogra_> only --enable-ssh
<Chipaca> so the cmd is a must
<Chipaca> with a nice-to-have of accepting config (just to set passwd in core) if no passwd set
<ogra_> also do we have a way to have passwords hidden in the snappy config output yet ?
<ogra_> so only *** is shown
<Chipaca> ogra_: i was thinking of doing it for coreconfig
<ogra_> yeah
<ogra_> though with a fixed lenght string so the actual PW lenght isnt guessable
<Chipaca> ogra_: was thinking of just replacing the value in the yaml with "***pasword***" or some such placeholder text, on the way out
<ogra_> yeah
<Chipaca> ogra_: which is something you could do with bip too :)
<ogra_> just to indicate there is one set
<Chipaca> (was it bip?)
<ogra_> yeah
<ogra_> the package is called ircproxy :)
<ogra_> but it uses bip
<Chipaca> ogra_: another way would be to use a special yaml thing for passwords
<Chipaca> i could dig into that if it'd be useful
<ogra_> we should ask jdstrand for input here
<ogra_> after all thats a security thing :)
<Chipaca> ogra_: echo "config: {ubuntu-core: {password: password}}" | snappy config ubuntu-core -- -
<Chipaca> \o/
<ogra_> :)
<clobrano> Hi Chipaca, any news from security guys for Bug #1496319? :)
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<Chipaca> clobrano: no
<Chipaca> clobrano: but i hear they're backlogged atm
<ogra_> and most of them are in the US....
<ogra_> where nobody works today... celebrating that guy who got lost
<clobrano> :D
<jdstrand> Chipaca: we are we needed for 1496319?
<tbr> did anyone look into snappy images for scaleway yet?
<jdstrand> beuno: fyi, I tried to accept docker in the review: OOPS ID: OOPS-3587e98ff8044c0db2885414f81ffd46
<jdstrand> kickinz1: ^
<jdstrand> beuno: I don't know how to proceed and am afraid to try to approve again
<jdstrand> beuno: it is ok to accept (kickinz1 will fix 'architectures' for next time and the security policy changes are ok)
<jdstrand> it appears to have been accepted
<jdstrand> (based on the website)
<beuno> jdstrand, I accepted it as well
<beuno> maybe we fought over accepting it
<beuno> jdstrand, I'll look into it, thanks
<jdstrand> maybe
<tedg> ogra_: That's Monday actually, US is in today :-)
<tedg> (well I imagine some people took vacation)
<ogra_> tedg, oh, not today ?
<ogra_> damn, mixed that up
<ogra_> tbr, i dont think anyone has started on that
<tbr> k
<tbr> it's interesting because it's cloud, but it's ARMv7
<ogra_> yeah
<Chipaca> fgimenez: any idea why umount would pin a cpu at 100% at the start of adt-run?
<Chipaca> 32223 root       20   0 25392  1688  1512 R   1 100.  0.0  8:52.81 umount /tmp/diskimage185973715/system
<Chipaca> like so ^
<fgimenez> Chipaca, nope atm, how do you run it?
<Chipaca> fgimenez: GOPATH=~/canonical/snappy ./run-checks
<fgimenez> Chipaca, never saw that before, from which branch are you running it?
<Chipaca> fgimenez: my auth thing
<fgimenez> Chipaca, didn't try run-checks, go run _integration-tests/main.go goes fine here, i'll check run-checks
<Chipaca> it's u-d-f hanging somehow
<Chipaca> sergiusens: you seen that?
<sergiusens> Chipaca, fgimenez if u-d-f was rebuilt, maybe check all the FDs are closed
<sergiusens> lsof
<sergiusens> it shouldn't cause a spin of the cpu
<Chipaca> oh
<Chipaca> no space left on device
<Chipaca> that might cause it
<elopio> fgimenez: could we use a link to the icon, instead of copying it into every snap?
<elopio> does that work? I'll give it a try.
<fgimenez> elopio, it would be very useful, let me know how it goes
<elopio> fgimenez: I did this service test before I realized I wanted to copy your local snaps style.
<elopio> I regret that because now every other branch depends on it.
<elopio> are you ok if I land it, and then make another branch to move the helloDBus tests to examples, and add a local snap instead?
<fgimenez> elopio, sure, np
<Chipaca> fgimenez: rebooted because my /tmp got into a mess, and now i get past the unmounting, but am still at the "ssh connection failed" bit
<Chipaca> i've never gotten past this stage
<Chipaca> how do i get it past this stage?
<fgimenez> Chipaca, which version of autopkgtest are you using?
<Chipaca> fgimenez: 3.17.3
<fgimenez> Chipaca, same here, what if you execute go run _integration-tests/main.go -release 15.04 ?
<elopio> Chipaca: did your udf fail? I get this every other time: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1496484
<ubottu> Launchpad bug 1496484 in goget-ubuntu-touch (Ubuntu) "device-mapper: remove ioctl on loop0p5 failed: Device or resource busy" [Undecided,Confirmed]
<Chipaca> elopio: when it failed, i aborted, cleared loop0p5, and redid
<Chipaca> fgimenez: doing that now
<elopio> tedg: how do I make a snappy lxc?
<Chipaca> fgimenez: getting the same âadt-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds...â
<Chipaca> fgimenez: except more than 3 seconds pass between each one
<Chipaca> and the qemu is doing *something*
<fgimenez> Chipaca, you should be able to access the image with kvm -m 512 -redir :8022::22 /tmp/snappy-test/image/snappy-rolling-edge-latest.img
<fgimenez> Chipaca, does it boot ok?
<Chipaca> well, 15.04 not rolling because you just told me to -release 15.04 :)
 * Chipaca tries it
<fgimenez> Chipaca, yes, sorry :)
<Chipaca> it's not booting
<fgimenez> Chipaca, maybe udf doesn't create it properly
<ogra_> is that 204 ?
<ogra_> (that is exactly what i wanted to have tested)
<ogra_> could be the grub changes, but these only landed in 204
<Chipaca> this is 15.04
<Chipaca> not sure the revno
<Chipaca> redoing from the start
<ogra_> u-d-f should have printed it
<fgimenez> ogra_, 15.04 204 is working fine here
<ogra_> phew !
 * ogra_ hugs fgimenez 
<ogra_> thanks !
<ogra_> that saves my weekend :)
<fgimenez> ogra_, yw :)
 * Chipaca continues to work to ruin ogra_'s weekend
<ogra_> haha
 * Chipaca likes the feeling of power
<ogra_> my heating breaking down already is ahead of you
 * ogra_ hopes it is only the oil filter being dirty and not the pump 
<Chipaca> oil filter? do you use a diesel engine to power the pump?
<ogra_> yeah, but its a clean VW one
<ogra_> :P
<davmor2> ogra_: damn you beat me to it :)
<ogra_> (i think 60-70% of german heatings still burn oil)
<Chipaca> fgimenez: retried with rolling, still no luck with the tests, but the image boots
<ogra_> its a central heating but a oli furnace
<ogra_> ... that powers it
<Chipaca> fgimenez: and i can ssh in and all
<davmor2> ogra_: yes you and america are the reason the cost of diesel rockets in the winter
<ogra_> i dont really need the heating, it is warm enough still, but it also does warm water
<Chipaca> ogra_: leaves more russian gas for the uk \o/
<ogra_> lol
<ogra_> i wish we had gas in my street ...
<ogra_> but like cable the neighborhood wasnt willing to pay for it
<ogra_> (tow streets down they have gas and 200MBit cable)
<fgimenez> Chipaca, what if, with the image booted with kvm, you run go run _integration-tests/main.go -ip 127.0.0.1 -port 8022 ?
<Chipaca> STUFF IS HAPPENING!!!!1!!!one!
<ogra_> yay
<fgimenez> Chipaca, \o/
<fgimenez> this bypass the image creation and booting part, anyway something is wrong, that should be done by the runner
<tedg> stgraber: I thought there was a snappy image for LXD, but I can't seem to find it. Am I remembering wrong or just suck at Google? :-)
<ogra_> tedg, there is an lxd snap in the store
<tedg> ogra_: Yeah, looking the other way around
<Chipaca> fgimenez: ohhh...
<Chipaca> fgimenez: after a number of reboots and stuff, this:
<Chipaca> Rebooting...
<Chipaca> bash: line 1:  1087 Killed                  bash -ec './_integration-tests/reboot-wrapper integration.test' 2> >(tee -a /tmp/adt-run.rEvouJ/command1-stderr >&2) > >(tee -a /tmp/adt-run.rEvouJ/command1-stdout)
<Chipaca> fgimenez: and now it's stuck waiting for ssh again
<Chipaca> (i can log into the system just fine)
<Chipaca> ah! but no ipv4 address!
 * Chipaca runs dhclient by hand
<fgimenez> Chipaca, you found it after all! i thought i was mistaken :) it must be the same think that elopio reported for bbb
<fgimenez> leaving, nice weekend everyone o/
<Chipaca> ogra_: elopio: have either of you ever seen a package decide it's sideloaded on update?
<elopio> Chipaca: nop.
<elopio> Chipaca: oh, I forgot. I did this because it was hard to find the test that was failing for you a couple of weeks ago
<elopio> https://code.launchpad.net/~elopio/snappy/results_on_error/+merge/273013
<longsleep> What is the best approach to add snapcraft plugins, adding an example how to use it?
<elopio> not sure if there's a better way to do it. Can you review please?
<sergiusens> tedg, until recently there was no snappy image for lxd due to all the security architecture around it
<sergiusens> recently though, apparamor gained the possibility of profiles within profiles which was one of the blockers
 * sergiusens knows he is using the terminology all wrong
<jdstrand> wait, what?
<jdstrand> I'm confused by the 'all wrong terminology'
<jdstrand> oh, snappy in lxd?
<jdstrand> right, so, apparmor doesn't yet have namespace stacking support
<jdstrand> which means that the host and the guest can't have unmodified profiles
<jdstrand> so it makes running snappy in a container harder than you'd want (should be able to if you disable apparmor for lxd on the host)
<jdstrand> the namespace stacking work has not landed yet, but it is coming. we are targeting 16.04
<tedg> Ah, okay, so elopio I was wrong about that ^
<tedg> Apparently we can't do the tests in LXD yet.
<ogra_> Chipaca, never
<sergiusens> longsleep, I don't follow, or if I do, just add a small project in the examples directory; to make sure it doesn't break even add a smaller project in integration_tests
<ogra_> beuno, you are being missed in a certain "-external" channel
<jdstrand> ogra_: fyi, I filed those three snappy bugs we talked about (nameservers, ntp and rsyslog)
<sergiusens> jdstrand, I think a little bird told me you were going to get the reviewer tools updated in ppa:snappy-dev/tools for vivid and trusty, is that correct?
<jdstrand> yes
<jdstrand> but I need to first update them for the things we agreed to :)
<jdstrand> I've started that
<jdstrand> sergiusens: ok, fix committed to trunk. the store will pick it up next week
<jdstrand> sergiusens: I have one other thing to add then I'll push to the ppa
<jdstrand> that will happen next week
<jdstrand> sergiusens: unless it is critical that you have it in the ppa sooner. let me know and I'll push what I have
<sergiusens> jdstrand, it's fine; just noticed an MP where snappy build re enabled the review tools so didn't want have havoc when the tools ppa got updated
<jdstrand> sergiusens: right, don't push that yet. feel free to add me as a reviewer
<jdstrand> sergiusens: the one thing that is left is actually so that can be turned on
<sergiusens> jdstrand, I noticed it landed while I was out; but it hasn't made it to the general population yet ;)
<jdstrand> sergiusens: ok, I uploaded review tools 0.34 to the tools-proposed ppa
 * jdstrand -> weekend
#snappy 2015-10-10
<TheRinger> can anyone tell me what the point of snappy is? Installed it on my rpi and just trying to get a general overview
<hades08> I get some error when using "lxc config edit mycontainer", could anyone help me ?
<Chipaca> ogra_: o/ :)
<ogra_> Chipaca, yo
<Chipaca> ogra_: what's the use case for sideloading an oem package? should it be allowed?
<Chipaca> up to now we only block sideloading apps when you have the same app installed
<Chipaca> so people have sideloaded frameworks over things that are installed
<Chipaca> and that breaks stuff
<Chipaca> so i'm disabling it
<Chipaca> but i don't know whether the same thing is true for oem, and whether anybody depends on it
<Chipaca> maybe i should ask longsleep, he was doing some pretty weird stuff :)
<Chipaca> ogra_: ("dunno, ask sergio" is a perfectly valid answer, and one i already have :)
<sergiusens> Chipaca, sideloading of oem was contemplated by some as a development feature, from my PoV, with our current system it should not be allowed. Only during image creation
<ogra_> Chipaca, it is needed for porting ... but only works in --developer-mode
<ogra_> Chipaca, i agree with sergiusens, it shouldnt be allowed on a running system, but the CI people might disagree (i think they want to test oem snaps like this)
<sergiusens> ogra_, half of what the oem snap does is only done on first boot though
<ogra_> right
#snappy 2015-10-11
<hades08> how to put apparmor in complain mode under ubuntu-core/snappy ?
<hades08> apparmor_parser -C ?
<hades08> plz help me ! :)
<beuno> hades08, I'd suggest emailing the snappy list
<beuno> there's nobody around today to get that answer for you
<hades08> ill have a look thx
#snappy 2016-10-10
<mup> PR snapcraft#862 opened: Add powerpc (32bit big-endian) support <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/862>
<dholbach> good morning
<trijntje_> good morning. What is the best way to grab a .jar from a website (like a github release) and place it into a snap
<mup> PR snapd#2116 opened: add build-essential as classic dep for building on arm64 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2116>
<mup> PR snapd#2114 closed: tests: add readme about spread's external backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2114>
<mup> PR snapd#2115 closed: tests: only stop a service if it is running or ok (eg. active (exited)) <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2115>
<Hanonim> Hi people !
<mup> PR snapd#2116 closed: tests: add build-essential as classic dep for building on arm64 <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2116>
<Hanonim> I'm testing snappy on KVM but when I install a snap, I can't run it
<trijntje_> I'm trying to create a snap of cromwell, a workflow management system https://github.com/broadinstitute/cromwell
<trijntje_> but I'm guessing that's not possible, because as a snap, it can't run any of the programs or scripts that are required unless they are also in the same snap?
<trijntje_> Hanonim: what can't run? the install or the snap itself
<Hanonim> trijntje: well for instance 'snappy install hello-world' works but then 'hello' doesn't (command not found)
<trijntje> what about /snap/bin/hello ?
<Hanonim> there is not /snap
<Hanonim> in /apps maybe ?
<Hanonim> there are hello-world files in /apps/bin
<Hanonim> but not /snap/bin/hello per say
<trijntje> What system are you on? On ubuntu 16.04 snaps get installed to /snap
<Hanonim> I'm trying this example (KVM)
<Hanonim> https://developer.ubuntu.com/en/snappy/start/#snappy-local
<trijntje> Hanonim: In that case I don't know, I'm sorry
<Hanonim> trijntje: no worries
<trijntje> General question: I was thing about creating a snap for cromwell, a workflow management system https://github.com/broadinstitute/cromwell but I'm guessing that's not possible, because as a snap, it can't run any of the programs or scripts that are required unless they are also in the same snap?
<mup> PR snapd#2117 opened: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2117>
<mup> PR snapd#2108 closed: devicestate: merge overlord/boot into devicestate <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2108>
<mup> PR snapd#2118 opened: overlord: merge overlord/boot pkg into overlord/devicestate <Created by mvo5> <https://github.com/snapcore/snapd/pull/2118>
<mup> PR snapd#2119 opened: tests: abort tests if an update process is scheduled <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2119>
<mup> PR snapd#2120 opened: Fix installed-size not being set in GET v2/snaps <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2120>
<Mirv> so I defined a new part at https://wiki.ubuntu.com/snapcraft/parts but snapcraft can't use it, are there other steps to be taken for it to be available? snapcraft update says already up to date (and once even did update but no change).
<Mirv> I didn't find documentation cloud parts yet at least, other than that wiki page
<trijntje> I don't think that wiki page would be used directly, otherwise anybody could just edit it an break snaps for everyone
<rvr> fgimenez: ping
<fgimenez> hi rvr :)
<rvr> fgimenez: Hey!
<rvr> fgimenez: iahmad pointed me at a document with instructions about how to run spread tests, but it's not complete and couldn't get them running
<rvr> fgimenez: So I need some help from you :)
<fgimenez> rvr, sure! :) do you want to run them againsta a running ubuntu core instance?
<rvr> fgimenez: I'm using the DragonBoard
<fgimenez> rvr, ok, we have this document now https://github.com/snapcore/snapd/blob/master/tests/external-backend.md it explains the process to execute on an external instance
<trijntje> I've succesfully create a snap and build it on amd64, but do I have to manually build and upload a snap for every architecture?
<trijntje> I also noticed that nobody actually put the architecture in their snapcraft file in the snappy playpen https://github.com/ubuntu/snappy-playpen
<ogra_> mvo, seems the pi and dragonboard unconditionally switching to stable for was not a one time issue ...
<ogra_> mvo, see bug 1631791
<mup> Bug #1631791: Pi 2 on ubuntu-core 424 no longer able to do anything <Snappy:New> <https://launchpad.net/bugs/1631791>
<ogra_> i guess this is quite serious
<ogra_> *for me
<Mirv> ok, now it works, thanks if someone did something ;)
<mvo> ogra_: yes, this is defintiely super serious - a critical bug
<trijntje> Will it ever be possible to have something like a terminal snap? Since that would need to have access to any other command that is available on the system
<kalikiana> trijntje: Check out bug 1618004
<mup> Bug #1618004: Need a classic-bin interface to see classic binaries <Snappy:New> <https://launchpad.net/bugs/1618004>
<trijntje> kalikiana: that looks very interesting, thanks. I'll comment and add my own usercase there as well
<trijntje> *usecase
<dr1337> Hi guys. Was wondering if anyone knows if Snappy has been ported to AllWinner soc?
<rvr> fgimenez: I did export SPREAD_EXTERNAL_ADDRESS=192.168.1.41:8022 (dragonboard IP)
<rvr> fgimenez: Then ./tests/lib/external/prepare-ssh.sh
<rvr> fgimenez: But the  INSTANCE_IP=localhost
<fgimenez> rvr in the call to prepare-ssh you should pass the instance ip and port as parameters
<fgimenez> rvr, something like ./tests/lib/external/prepare-ssh.sh 192.168.1.41 22
<rvr> fgimenez: Yeah, I just was reading the source of the bash script
<rvr> fgimenez: Then, where is the spread command?
<fgimenez> rvr, for dragonboard "spread -v -reuse external:ubuntu-core-16-arm-64" should work
<rvr> fgimenez: Yes, but, where is the spread command?
<ogra_> ppisati_, hmm, so i see morphis' uart oops on every boot here now ... using the last dailies
<ogra_> (on the pi3)
<ppisati_> ogra_: i'm working on it
<ppisati_> ogra_: what do you have attached to your board?
<ogra_> ppisati_, i know, just wanted you to know
 * ppisati_ download the latest daily
<ogra_> HDMI old apple USB kbd
<ogra_> i couldnt get the wifi to connect, so later i also attached an ethernet cable
<ppisati_> ogra_: is the daily built using the edge or beta channel?
<ogra_> edge
<ogra_> beta is the image on cdimage ... dailies (on people.u.c) are always edge
<fgimenez> rvr, you mean spread itself, right? you can install it with "sudo snap install spread"
<ppisati_> ogra_: i tried this morning rolling an image using edge, and i got a lot of errors because som,ething was trying to use the network while the network wasn't configured yet
<ppisati_> neet to retry
<ogra_> mvo, just FYI, i switched the dailies to core on friday
<ogra_> ppisati_, yeah there seems to be an issue with the wifi ... wired works though
<ppisati_> ogra_: one thing that i found, is that by disabling the fixed freq in config.txt, the serial oops disappear
<ogra_> well, i can surely drop that if it doesnt have other illl effects
<ppisati_> ogra_: you would loose the serial, since the core freq will keep chaning, and the srial baud rate would change too
<ogra_> hmm
<ppisati_> ogra_: but if you don't have a serial cable attached, it might make sense
<ogra_> yeah, but thats nota solution ...
<ppisati_> ogra_: it's just a workaround for the moment, until i found the root problem
<ogra_> right
<ogra_> dr1337, i dont think seires 16 has yet ... but there were 15.04 images iirc (dont ask me for what boards though)
<ogra_> dr1337, if you have a borad that uses uboot and you have the ability to rebuild the uboot with the necessary config options enabled, it should be pretty straight forward though
<ogra_> mvo, as i understand the f2fs mount errors we see on boot comes from /dev/ram* devices, do we really need to check them when looking for assertions ? (i think we should just exclude ram devices)
<ogra_> *come
<mvo> ogra_: no, this is a bug, I have a card to skip those in trello
<ogra_> ah, k
<ogra_> perhaps simply limiting it to removable devices would be enough
<ogra_> (there is a udev var for this)
<ppisati_> ogra_: so, building an image using edge, on boot i get util.py first and url_helper.py [DEBUG] stuff flooding my console
<ppisati_> they try to connect to a remote host
<ogra_> ppisati_, hmm, sounds like console-conf
<ogra_> oh, no
<ogra_> thats cloud-init i guess
<ogra_> you need a patched ubuntu-device-flash ... not sure if mvo has already pushed that as snap to the store yet
<ogra_> err
<ogra_> s/ubuntu-devlce-flash/ubuntu-image/
<ppisati_> they try to access a remote site but complain since the network is not available (and being the first boot, it's no surprise)
<mvo> ogra_: what needs patching here? sorry, I miss some context
<ppisati_> mvo: i ust built a new image using edge
<ppisati_> mvo: and during boot, my console was spammed with
<ogra_> ppisati_, https://github.com/CanonicalLtd/ubuntu-image/pull/69
<mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
<ppisati_> 'url_helper[DEBUG] can't connect http://..."
<ogra_> mvo, ^^
<ogra_> else cloud-init stays enabled
<ogra_> mvo, (since you dropped the hook from livecd-rootfs)
<mvo> ppisati_: oh, indeed, please ensure you have the latest ubuntu-image snap from edge
<ppisati_> ubuntu-image         0.5+mvo8   15   canonical  devmode
<mvo> ppisati_: please run "sudo snap refresh --devmode ubuntu-image"
<ppisati_> and 'snap refresh' says i've the latest and greatest
<ppisati_> k
<ogra_> it lies :)
<mvo> ppisati_: yeah, its a bit confusing for --devmode snaps
<ogra_> (due to missing --devmode i guess)
<ppisati_> ubuntu-image         0.5+mvo13  20   canonical  devmode
 * ppisati_ rebuilds the image
<rvr> fgimenez: This is running :)
<ogra_> we should really make that automatic ... after all snapd knows it uses devmode ...
<ogra_> so it could auto-apply the option for such snaps (and perhaps simply print a warning that devmode is on)
<rvr> fgimenez: So, do these tests check snapd?
<rvr> fgimenez: This is the output I got http://paste.ubuntu.com/23302958/
<fgimenez> rvr, it begins to look good :) some of the errors seem to be related to an outdated sorce code (ubuntu-create-user for instance)
<Mirv> is the directory for desktop file now "setup/gui" or "meta/gui"? I get conflicting docs / examples..
<Mirv> ok, I guess setup
<niemeyer> jdstrand: Do you have a moment for a call with pedronis and myself?
<davmor2> ogra_: how do you login to snapweb?
<mhall119> Mirv: awesome work on the qt 5.7 part! Does it pull source and build it, or does it use pre-build binaries?
<ogra_> davmor2, log in ?
<davmor2> ogra_: sorry access
<ogra_> i never had to .... does it have a login rfeature now ?
<ogra_> http://snapweb.local:4200/
<davmor2> ogra_: cool I'll give that a try then thanks
<ogra_> or use the IP instead of snapweb.local
<davmor2> ogra_: success
<ogra_> good
<davmor2> ogra_: I'm just using usb rather than transfering to hdd
<Mirv> mhall119: so pull (upstream only source) and build it, my qt-ubuntu dream is still alive but requires someone to guide me how to make the content interface work for real, maybe next week :)
<mhall119> Mirv: I was talking to sitter the other day, and he suggested we could build our own binary tarballs of upstream's releases, and use those for the cloud part rather than re-building it for every apps
<mhall119> that would be somewhere between what you have now and your qt-ubuntu dream, and would allow apps that don't want to use the shared version to bundle their own
<Mirv> mhall119: sure, that could work too. that's why I suggested after: [qt57] to be only used in case the app developer absolutely requires newer Qt than what is available in Ubuntu, but if the use increases the part could be changed to that.
<john-mcaleely> I'm seeing reports, which I don't fully have to hand, that some go binaries are not running on current snappy rpi images. is this a known issue?
<john-mcaleely> JohnAgosta, ^ fyi
<jdstrand> niemeyer: I'm on holiday today (and tomorrow), but saw this passing through. I can do it now if it is quick
<ogra_> given that snapd is go itself, these must be very specific go bits that dont work in your binaries then
<john-mcaleely> hmm. the log message is: Oct 1 20:59:49 PiCloud snap[3346]: runtime: this CPU has no floating point hardware, so it cannot run
<john-mcaleely> Oct 1 20:59:49 PiCloud snap[3346]: this GOARM=6 binary. Recompile using GOARM=5.
<john-mcaleely> let me dig in to how that snap is produced
<ogra_> doea snap list work (or any other snap command)
<john-mcaleely> I assume the platform is Pi2, but that's one of the things I don't have exactly, yet
<john-mcaleely> yes
<john-mcaleely> so I take your point that something odd is up
<ogra_> pi2 or 3 shouldnt make any difference
<john-mcaleely> hmm
<jdstrand> john-mcaleely: that is probably the snap-confine bug stripping out auxv. that was fixed a while ago. you should use updated images
<ogra_> the image is the same, only the uboot binary differs
<john-mcaleely> jdstrand, aha. Got a bug # so I can read?
<ogra_> LOL
<john-mcaleely> fwiw, the issue manifests after an update
 * ogra_ just found how the wifiSd card does its firmware upgrades for the embedded OS 
<ogra_> this is hilarious
<john-mcaleely> ondra, catch-up: http://pastebin.ubuntu.com/23303463/
<ondra> john-mcaleely thanks!
<jdstrand> john-mcaleely: https://bugs.launchpad.net/snap-confine/+bug/1621127
<mup> Bug #1621127: snap-confine doesn't work with new snap-run/snap-exec flow <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1621127>
<john-mcaleely> ondra, ^
<jdstrand> john-mcaleely: you need the snap-confine from xenial-proposed
<ondra> ogra_ snap list works
<john-mcaleely> should this be killing nextcloud boxes?
<jdstrand> I don't know what is in the images
<john-mcaleely> it appears to be
<ondra> ogra_ snap install hello-world and then I get GOARM complain
<ogra_> ondra, yeah, then the issue is likely the snap confine bug, GO itself seems to be fine
<jdstrand> but you can see if you have a fixed snap-confine by doing 'grep unsafe /etc/apparmor.d/usr.lib.snapd.snap-confine
<ondra> john-mcaleely funny enough nextcloud is still running :)
<jdstrand> it nothing comes back, you need an updated snap-confine/image
<ondra> ogra_ what is confine bug? :)
<john-mcaleely> ondra, this one https://bugs.launchpad.net/snap-confine/+bug/1621127
<mup> Bug #1621127: snap-confine doesn't work with new snap-run/snap-exec flow <Snappy Launcher:Fix Released by zyga> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1621127>
<ondra> jdstrand grep unsafe gives me nothing
<ondra> jdstrand I did run apt-get update && upgrade
<ondra> jdstrand what else shall I update then?
<john-mcaleely> ie, you're on a 16.04 system hosting snaps
<jdstrand> ondra: you need xenial-proposed
<ondra> jdstrand OK I have thant, I only updated snapd though
<ondra> safe to run upgrade on all?
<jdstrand> ondra: https://launchpad.net/ubuntu/+source/snap-confine/1.0.43-0ubuntu1~16.04.1
<jdstrand> ondra: I don't know everything in xenial-proposed. just grab those two debs and install
<ogra_> niemeyer, plars, http://paste.ubuntu.com/23303485/
<ogra_> ;)
<ondra> jdstrand OK snap-confine + snapd from xenial-proposed seems to do the trick for hello-world
<jdstrand> hopefully snap-confine will get through SRU this week. ara is testing it
<john-mcaleely> so why do users see broken-ness now on nextcloud boxes?
<jdstrand> ok, I'm off today so wandering off unless niemeyer catches me soon
<ara> jdstrand, well, kind of, I am asking peopole to test some of the bugs
<john-mcaleely> has something been released too early?
<niemeyer> jdstrand: Hello
<ara> jdstrand, some of those are difficult to understand what needs to be tested
<jdstrand> niemeyer: hey
<ara> jdstrand, so I am pinging the original reporters
<niemeyer> jdstrand: We can do it here so I don't disturb your holidays too much
<jdstrand> that's fine
<niemeyer> jdstrand: Our goal is to have most of the hardcoded logic in our assertions dropped in favor of snap declarations by the end of the week
<jdstrand> niemeyer: if this is about snap declarations, vyi I started the review tools stuff last week and roadmr is working on the store side
<jdstrand> niemeyer: yes, I saw the email. I think that is doable
<niemeyer> jdstrand: For that, we'll need the actual declaration in place
 * jdstrand nods
<niemeyer> jdstrand: One thing we can do is to have a short term plan for importing the actual declarations directly in the store server, and then go back to the review tools for finishing it the proper way
<niemeyer> jdstrand: As long as the assertions are up there, maintaining the status quo we have in code, we should be good to go for the RC
<jdstrand> niemeyer: roadmr and I synced last week and decided how the review tools and the store will interact. he should be unblocked for entering into the store and for snapd queries. I don't know the status of his work
<niemeyer> jdstrand: So the challenge is building a list of all assertions we need, and burning it down until friday
<jdstrand> I should be able to finish up the review tools on wed
<rvr> In which project do I fill a bug for console-conf?
<ogra_> niemeyer, plars, so all we need now is a busybox for armv5l that has dd and wget enabled, some scriptery and we can directly flash images over wifi, independent of what the devel board we want to test currently does (as long as the wifiSD card has power), i tested with beagle, both pi's and the dragonboard, they can all boot fine from the wifiSD rootfs when you dd it to the SD part and use the SD->microSd adapter
<jdstrand> (of course, that would not include a store rollout)
<niemeyer> jdstrand: Yeah, I know there's some trickery around reviewing/store interactions
<niemeyer> jdstrand: Which is why I'm proposing we side-step the initial loading so we're not blocked on that
<jdstrand> niemeyer: there is, but we have the path forward and are unblocked on each other
<niemeyer> jdstrand: As long as we have the assertion content itself, we should be able to move on in time for the RC
<jdstrand> niemeyer: aiui the store has a form field for the payload for slots and plugs. but when roadmr and I last spoke, he said entering anything in there breaks things
<niemeyer> ogra_: Interesting.. did you dd via wifi already?
<niemeyer> jdstrand: Hmm.. things?
<ogra_> niemeyer, not yet, but i should have a working setup for all of tezh above during this week
<ogra_> after finding that hilarious autorun.sh thingie the rest is just finger training
<jdstrand> niemeyer: I don't know the status of that-- but, it seems reasonable that, yes, if they can store the snap declaration for snapd to query on for lxd, docker and the kernel-module-control consumer, then the store can simply insert that payload in those form fields as if this was a subsequent run
<niemeyer> jdstrand: Right
<niemeyer> jdstrand: Cool, let's push that forward when you're back on Wed
<jdstrand> that is all +1 from me
<niemeyer> jdstrand: Have fun there!
<jdstrand> but, importantly, I am working on the review tools, not the store side. please sync with roadmr for the store side status and storing of the snap declarations
<jdstrand> (well, the review tools are store side, but I think you know what I mean)
<niemeyer> jdstrand: Yeah, thanks
<jdstrand> niemeyer: today is Candian thanksgiving so roadmr it off, but he should be back tomorrow
<jdstrand> well, I'm assuming he is off
<niemeyer> jdstrand: I think pedronis is in sync with him about that (or will be)
<jdstrand> ok great
<niemeyer> ogra_: Cool.. that's probably the trickiest part of it.. if we can get the wiif card to dd behind the device's back, the rest should work fine
<ogra_> niemeyer, shouldnt be any prob really ... just time and work :)
<ogra_> oh, whee ... wget is actually there already
<ogra_> just need dd
<ogra_> hmm, though /dev/mtdblock0 on the embedded linux only has 268K free ... we'll need to stream into dd from wget
<ogra_> and need the images uncompessed on the server since we cant unxz them
<ogra_> oh this is so much fun !!!
<ogra_> but it is astonishing how insecure these wifiSD cards are ...
<SuperJonotron> on 16.04.1 LTS, is there any way to allow access to modifying contents of the /etc/ folder?
<ogra_> niemeyer, http://paste.ubuntu.com/23303624/
<ogra_> :D
<shuduo> ogra_: hi, i flash new beta3 pi2 image and went through console-conf. After finish, I use ssh to login pi2 but it prompt password need input. Is it expected?
<ogra_> shuduo, did console-conf properly finish (i.e. telling you the ssh line you should use)
<shuduo> ogra_: yes. i have booted it and went through console-conf but did not finish. Second time I finished and ssh line told me what i need.
<ogra_> try a reboot then and file a bug that console-conf didnt finish
<shuduo> ogra_: let me re-dd and try again. if it can be reproduced i will file a bug. thanks.
<ogra_> i bet it can
<ppisati_> ogra_: morphis: i've pushed out a new image containing a new kernel - with this image i cannot reproduce the serial oops anymore, if you can test it and comment that would be nice since i plan to push it out tomorrow
<ppisati_> lp1630586
<ppisati_> bug1630586
<ppisati_> the bot is not collaborating...
<ogra_> bug 1630586
<mup> Bug #1630586: Pi3 kernel crash and is unreliable <patch> <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1630586>
<ogra_> ppisati_, it is just picky
<ogra_> (needs the space)
<shuduo> ogra_: hi, i can reproduce the issue but i'm curious it happen only i gave a specific account (my colleague). but it works well with with my launchpad account
<mup> PR snapd#2121 opened: snapy: do not auot-import from loop or non-dev devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2121>
<mhall119> JamesTait: ping
<mhall119> JamesTait: Have you proposed your ejabberd snap configs to upstream?
<mup> PR snapcraft#835 closed: Add the test upstream rules <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/835>
<mup> PR snapcraft#860 closed: In the downloader demo test, use https <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/860>
<mup> PR snapd#2122 opened: snappy: disable auto-import of assertions on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/2122>
<mup> PR snapd#2123 opened: daemon: ensure `snap create-user --known` errors on classic (unless --force-managed is added) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2123>
<thomi> Does anyone know how to specify which version of go is used to build a snap with the 'go' snapcraft plugin ?
<thomi> ahh, it seems I'm hitting https://bugs.launchpad.net/snapcraft/+bug/1616985
<mup> Bug #1616985: the go plugin doesn't support go 1.7 <plugin> <Snapcraft:New> <https://launchpad.net/bugs/1616985>
<mup> PR snapcraft#862 closed: Add powerpc (32bit big-endian) support <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/862>
<mup> PR snapcraft#849 closed: Bugfixes for gated and validate commands <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/849>
<SuperJonotron> ubuntu-core file system is read only and can't modify anything on the file system as root, is this normal?
<mup> PR snapd#2124 opened: daemon: add postCreateUserSuite test suite <Created by mvo5> <https://github.com/snapcore/snapd/pull/2124>
<mup> PR snapcraft#859 closed: Set GOBIN in go plugin build environment <Created by tasdomas> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/859>
<mup> Bug #1632085 opened: Support "fudge factor" for file system sizing <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1632085>
<mup> Bug #1632124 opened: snapd pegging cpu at 100% <Snappy:New> <https://launchpad.net/bugs/1632124>
<niemeyer> ogra_: Looks promising!
<dr1337> Hey guys do you know if canonical provides support to port to an unsupported ARM board?
<thomi> jdstrand: I understand you're the person to talk to about click-reviewer-tools warnings? I'm trying to ship a snap that contains a shell script, and getting "Could not find compiled binaries for architecture 'amd64'".
<thomi> jdstrand: I'm not sure what I should be doing differently though...
<mup> Bug #1632130 opened: Can't download snaps from ARM hardware running Classic <Snappy:New> <https://launchpad.net/bugs/1632130>
<JamesTait> mhall119, I haven't. Two reasons: 1) It's not just a straight `snapcraft`, you have to `snapcraft prime; patch -p0 < README.md; snapcraft`. 2) When I mentioned my snap of one of the ejabberd releases on the public mailing list, it was met with hostility, which rather put me off.
<JamesTait> mhall119, http://lists.jabber.ru/pipermail/ejabberd/2016-August/009066.html
<mup> Bug #1611078 changed: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
#snappy 2016-10-11
<mup> PR snapcraft#863 opened: history/status alignment fixes <Created by cprov> <https://github.com/snapcore/snapcraft/pull/863>
<Ryan___> help
<rl-ubuntu> Anyone has a guide in running .net core in snappy ubuntu core? i'm following the guide in microsoft website, i can't install because it was using apt-get install.
<Son_Goku> it's not snapped yet
<rl-ubuntu> @Son_Goku so it's possible to run a .net core in snappy ubuntu core i just need to snap it first, correct?
<nothal> rl-ubuntu: No such command!
<Son_Goku> yep
<rl-ubuntu> awesome, will try that. thanks
<mup> Bug #1612260 changed: My package is published but not showing up in the store <Snappy:Expired> <https://launchpad.net/bugs/1612260>
<mup> PR snapd#2125 opened: tests: fixed code blocks on external backend readme <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2125>
<dholbach> good morning
<oSoMoN> didrocks, hey, Iâve rebuilt my webbrowser-app snap and I was expecting that because of https://github.com/ubuntu/snapcraft-desktop-helpers/commit/46bea1d261e005eecfe532a5a23d9dd080898432 locales-all would be pulled in as a stage package, but it appears itâs not. any idea why?
<mup> PR snapd#2126 opened: tests: add spread test for `snap auto-import` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2126>
<didrocks> oSoMoN: hey! oh, interesting, let me check if I can find the online definition of the importer
<didrocks> oSoMoN: you did snapcraft update, correct?
<didrocks> I do see locales-all here
<oSoMoN> didrocks, I didnât run snapcraft update, but when checking the source of the desktop-qt5 part, it has my commit
<oSoMoN> re-running now, after running snapcraft update
<didrocks> oSoMoN: you did snapcraft clean as well?
<didrocks> because I'm unsure it dirty check properly
<oSoMoN> I ran bzr clean-tree --unknown --ignored in my branch, so there should be no leftover
<didrocks> yep!
<mup> PR snapd#2127 opened: tests: add test for auto-mount assertion import <Created by mvo5> <https://github.com/snapcore/snapd/pull/2127>
<mup> PR snapd#2125 closed: tests: fixed code blocks on external backend readme <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2125>
<oSoMoN> didrocks, now it worked, locales-all got included in my snap
<oSoMoN> looks like running snapcraft update made the differenc
<didrocks> nice! :)
<oSoMoN> difference
<didrocks> yep
<didrocks> you need to refresh the definition
<didrocks> it's like apt update if you prefer
<oSoMoN> thanks for the tip!
<seb128> it's a bit error prone that it needs to be done manually this way :-/
<didrocks> agreed, (I'm pretty sure that was already raised)
<didrocks> at least, it should tell "we have new definitions for you, please runâ¦"
<didrocks> IIRC, the concern was "too many connections to the server"
<seb128> I can see that connecting every time you use snapcraft wouldn't work either
<seb128> but maybe refreshing once a day
<seb128> then those who need to trigger an update can manually do it
<mup> PR snapcraft#864 opened: Update documentation links to developer.ubuntu.com that now redirect â¦ <Created by robert-ancell> <https://github.com/snapcore/snapcraft/pull/864>
<mup> PR snapd#2128 opened: debian: remove usage of dh-systemd <Created by vosst> <https://github.com/snapcore/snapd/pull/2128>
<mup> PR snapd#2129 opened: interface attributes: prepare plug slot hooks (phase 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2129>
<Chipaca> ogra_, once again talking about doing fancy stuff in core in #systemd and the "run systemd in initrd" comes up
<ogra_> Chipaca, well, have fun implementing it and making it work with the existing bits :P
<ogra_> Chipaca, effectively that will just make the initrd explode in size
<Chipaca> ogra_, my response was *very* polite
<ogra_> with not much benefit
<ogra_> :)
<Chipaca> ogra_, on the other hand, did we ever have a serious conversation around making initrd be the actual root?
<ogra_> Chipaca, we did in the phonedations team a few times. but not in context to snappy ... if we'd actually use initamfs-tools to create that rootfs (to only contain *exactly* what is necessary) that would surely result in an awesome but maintenance intense system
<dr1337> ogra_ what was it like working on the ninja sphere?
<ogra_> dr1337, like working with a beaglebone on streoids ;)
<ogra_> *steroids
<dr1337> How did canonical get involved in it?
<mup> PR snapd#2130 opened: store: retry store ops (phase 1) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2130>
<ogra_> dr1337, no idea ... probably a conference or some such. i only got the board and was asked to do an initial test image after the involvement was there already
<om26er> re: launchpad snap builders, which version of Ubuntu do they use ?
<ogra_> xenial i think
<om26er> I am building a snap, it works fine in a lxc container running xenial but fails to build in lp
<ogra_> how does it fail (got a build log link ?)
<om26er> ogra_: https://launchpadlibrarian.net/289187171/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz
<ogra_> om26er, i'd guess for a firewall issue
<om26er> ogra_: seems other things are downloading file from pypi
<om26er> atleast from what I can see
<daker> om26er: it says : Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known
<ogra_> i see a lot "Ignoring indexes:" above the error
<ogra_> so this is probably the first point where it actually tries to download any indexes
<om26er> hmm
<om26er> ogra_: lp bug?
<ogra_> dunno, but surely something to ask cjwatson about :)
<ogra_> he has the deeper insight here :)
<om26er> cjwatson: ^ my snap build fails in lp, it works fine in a clean lxd container I am running locally.
<cjwatson> om26er: you have to do your network access in the pull phase, not build
<om26er> the snapcraft.yaml looks like this: https://github.com/om26er/crossbar/blob/master/snapcraft.yaml
<cjwatson> om26er: I know you're trying to, but it's clearly not complete
<cjwatson> om26er: possibly due to setup_requires or similar that pip download isn't managing to follow
<cjwatson> om26er: you can probably just manually add cffi to the download step
<om26er> ogra_: ^ can you decrypt that on to how that may reflect in my snapcraft.yaml (still trying to get used to snapcraft :)
<ogra_> no, sorry, i'm not a big python guy beyond what comes from the archive (i have no biggger knowledge of pip)
<cjwatson> om26er: "python-packages: cffi" probably
<cjwatson> at least worth a go as a starting point
<cjwatson> om26er: well strictly "python-packages: cffi>=1.1.0"
<cjwatson> om26er: though you might possibly be better with "requirements: requirements.txt" instead
<cjwatson> that would get the pinned requirements recommended by upstream in this case
<om26er> ok let me try that.
<om26er> cjwatson: seems that didn't help :/ same results https://launchpadlibrarian.net/289191346/buildlog_snap_ubuntu_xenial_amd64_crossbar_BUILDING.txt.gz
<om26er> .yaml looks like this now https://github.com/om26er/crossbar/blob/master/snapcraft.yaml
<om26er> note: I used requirements-in.txt file in the tree as requirements.txt has some hash verification so its fails like http://paste.ubuntu.com/23307635/
<om26er> a successful build (local lxd) looks like this http://paste.ubuntu.com/23307708/
<cjwatson> om26er: Yuck.  Possibly wheel should be in the download phase due to this.
<cjwatson> om26er: Adding "python-packages: cffi>=1.1.0" should work around it, then.
<om26er> cjwatson: with removal of the requirements like ? or can that co-exist ?
<cjwatson> om26er: It can coexist.
<cjwatson> om26er: But I think there's a reasonable argument that this is a snapcraft bug: given that wheel may need to hit the network, it should be done in the pull phase.
<cjwatson> om26er: i.e. something like http://paste.ubuntu.com/23307726/ (totally untested)
<om26er> cjwatson: hmm wonder if there is a way to test that in lp :)
<ogra_> cjwatson, hmm, all my kernel snap rebuilds failed with a 403 error
<ogra_> that is: https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/6639 https://code.launchpad.net/~snappy-dev/+snap/dragonboard-kernel/+build/6641 https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6638 and https://code.launchpad.net/~snappy-dev/+snap/pc-kernel/+build/6637
<om26er> cjwatson: btw that did work :)
<om26er> So we need to fix that so that others don't hit that.
<om26er> *in snapcraft
<liuxg> ogra_,  if I have a ubuntu core device and it is bound to my launchpad account, may I know how I can make it work with another colleauge's launchpad on his computer?
<liuxg> ogra_, the idea is that he can login into the device witth his account instead of my account, which uses the ssh key in my computer.
<ogra_> i think the command that console-conf uses in teh backend is "snap create-user"
<ogra_> (not 100% sure though)
<liuxg> ogra_, what is the correct syntax for using the command "snap create-user"?  do I just need to supply the launchpad id?
<cjwatson> ogra_: I don't have enough logging at the moment to be able to tell you exactly why that was.  The possible causes are that the uploader hasn't signed the latest developer agreement in the store, that the uploader hasn't set a developer namespace in the store, or that the authorisation token isn't authorised for the correct package name.  (You can rule out the last of those by going through ...
<cjwatson> ... e.g. https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+authorize)
<ogra_> liuxg, i dont actually know ... doesnt snap help tell something about it ? (but i guess jst your mail address should suffice)
<cjwatson> "snap create-user --help" says you give it an email address.
<cjwatson> [create-user command arguments]
<cjwatson>   <email>:           An email of a user on login.ubuntu.com
<ogra_> cjwatson, well, thats weird, the uploader is indeed me :)
<ogra_> uh, oh
<ogra_> and i just notice that all the core builds failed to upload too ...
<cjwatson> ogra_: I'm just telling you the possible causes.  It will be one of those.  I don't know which.
<ogra_> cjwatson, can we have mail notification for that ? i havent gotten a single mail
<cjwatson> ogra_: bug please
<ogra_> will do
<cjwatson> ogra_: there's supposed to be a mail notification, so must have missed a case
<ogra_> yeah, i get mails for other failures
<cjwatson> right, BadUploadResponse doesn't have an associated notification
<liuxg> ogra_, thanks. I have not tried it yet. Maybe I will try it when I am with my colleague. I do not have his account info now.
<cjwatson> ogra_: anyway apparently the 403s are a known SCA bug in production, being looked at now
<ogra_> sigh, this is insane ... i'll be clicking authorize stuff for the next hour or so, *all* aumoated snaps failed
<cjwatson> ogra_: +authorize won't help
<cjwatson> in this case
<ogra_> ouch
<cjwatson> ogra_: once the SCA bug is fixed you should be able to retry the store upload from LP though
<ogra_> ok
<ogra_> yeah, even after authorize/re-upload i get 403's everywhere, confirmd
<ogra_> cjwatson, bug 1632299
<mup> Bug #1632299: BadUploadResponse store reply in snap uploads should trigger email notification <Launchpad itself:New> <https://launchpad.net/bugs/1632299>
<popey> what is "Initialize device" and why is it spamming my "snap changes" every 9 mins or so... http://termbin.com/rzoi ?
<cjwatson> thanks
<ogra_> popey, by reading that paste i would say it is an Error :P
<popey> heh
<popey> ogra_: worthy of a bug report somewhere do you think?
<ogra_> yeah
<popey> ok, thanks for looking
<ogra_> i guess mvo or pedronis could help you further with that one
<popey> ok, bug filed.
<mup> Bug #1632305 opened: console-conf cannot be used twice <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1632305>
<mup> Bug #1632306 opened: 'snap changes' spammed with "Initialize device" <Snappy:New> <https://launchpad.net/bugs/1632306>
<ogra_> liuxg, hah ... looks like Bug #1632305 above has a trick you can use to create your second user ;)
<mup> Bug #1632305: console-conf cannot be used twice <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1632305>
<liuxg> ogra_, where is the trick? sorry, I missed it.
<ogra_> re-run "sudo console-conf" ;)
<ogra_> seems to work if you use a new user and just dont change the network settings
<ogra_> (according to that bug)
<liuxg> ogra_, do you mean run it after ssh into the device?
<ogra_> yes, as the bug says
<pedronis> popey: it means it's failing to register itself?Â is this with a canonical image? does it have network?
<liuxg> ogra_, OK. thanks. I will have a try.
<liuxg> ogra_, so, "sudo console-conf" is now working or not. according to the bug report, it does not work yet
<ogra_> it faisl if you re-use the same user
<ogra_> (thats the bug)
<ogra_> but thats not what you want
<liuxg> ogra_, oh, so, I can set it to another user. after that, I can switch back to my own, right? if this works, it should be fine for me.
<ogra_> right
<liuxg> ogra_, thanks. it is cool. by the way, does "snap create-user" do the same thing? it seems to be the correct command
<ogra_> console-conf calls it, ye
<ogra_> s
<ogra_> (as i said in the beginning)
<mvo> popey: thanks for your bug on the init device issue, could you please attach the output of "change change 833" (or similra, one of the failing ones)
<liuxg> ogra_, ok. so, both ways work. thanks a lot
<ogra_> re-using console-conf is just  cheap way
<ogra_> popey, btw, is that the device that switched back to stable unconditionally ?
<liuxg> ogra_, right. :)
<ogra_> popey, if so, that could indeed be related
<ogra_> (teh fw_setenv command i gave you is just a hack)
<popey> mvo: done
<popey> ogra_: uhm, not sure if it's that one, I have 3
<pedronis> popey: did you reset you state at some point or something ?
<popey> not intentionally
<popey> see also bug 1631791
<mup> Bug #1631791: Pi 2 on ubuntu-core 424 no longer able to do anything <Snappy:Confirmed> <https://launchpad.net/bugs/1631791>
<popey> ooh, i have another one doing the initialize device thing
<pedronis> that error mode is weird
<popey> also, bug 1632124 is on a pi 3 which is also doing the initialize device thing
<mup> Bug #1632124: snapd pegging cpu at 100% <Snappy:New> <https://launchpad.net/bugs/1632124>
<pedronis> popey: asked a couple more questions in the bug itself
<popey> pedronis: on it, painfully slow to get snap changes as the cpu is pegged by snapd
<popey> pedronis: ok, commented
<pedronis> popey: it's creating key after key and not finding them
<pedronis> apparently
 * ogra_ notes that popey's image is still using ubuntu-core ... 
<ogra_> (newer images use the "core" package instead)
<popey> interesting
<balloons> Good morning all. Quick question -- should there be any delay from publish to availibilty in the store? I don't remember ever seeing a delay, but I'm hearing publication can take 12 hours or more sometimes
<ogra_> well, not that much, you would have to flash a newer image to get there ... but perhaps there is a bug in the code that handles both names ...
<ogra_> thats relatively new code
<ara> mmm, on a clean rpi2 clasic image as of today, doing snap install hello-world shouldn't install core instead of ubuntu-core?
<ara> I just did this and ubuntu-core was downloaded
<popey> oh, it doesn't migrate from ubuntu-core to core? I need to re-flash again?
<ogra_> popey, yes ...
<zyga> ara: hey
<popey> :(
<ogra_> ara, i think thats only happening with the next snapd revision ...
<ogra_> (defaulting to install core)
<ara> mmm, classic on rpi2 fails to install ubuntu-core as well: https://pastebin.canonical.com/167549/
<ara> hey zyga, how's korea?
<pedronis> popey: I'm quite baffled by what is going on on your pi2, seems like we write something and a second after we are not reading it
<ogra_> ara, wow, gross
<ogra_> it shouldnt try to handle any boot stuff on classic ever
<ara> ogra_, this is a clean server classic image, no dist-upgrade yet
<ogra_> probably that code isnt pi-safe :)
<ara> ogra_, do you want me to file a bug for this? if so, where? what logs?
<ogra_> ara, hmm, you should definitely dist-upgrade first to get the latest snapd
<ara> let me update snapd and see if that solves it
<ogra_> snapd, snap-confine and ubuntu-core-launcher
<ogra_> (orr just dist-upgrade)
 * ara wonders if we should produce 16.04.1.1 images with the latest packages, as so much changed
<ara> snap-confine was not even installed yet on those images
<ogra_> well, 16.04.2 will have everything
<ogra_> right, but snapd will pull it in on dist-upgrade
<ogra_> iirc it was added as dependency
<ara> yes, it does
<zyga> ara: hey, pretty and exotic
<mup> Bug #1631801 changed: snapd removes Exec lines from .desktop file on installation <Snappy:Invalid> <https://launchpad.net/bugs/1631801>
<om26er> So I need to write values to /sys/class/gpio/ is there a way to keep my snap confined and be able to do so ?
<om26er> zyga: ^
<zyga> om26er: using the GPIO interface on a correctly set up core image (only gadget can expose those)
<om26er> zyga: apart from those to be exposed, my main question is can I write to lets say /sys/class/gpio21/direction or /sys/class/gpio21/value ? Since that's what would make it be able to do it anything. Now I assume it will always require sudo ?
<om26er> on another question what would it take to ensure they are exposed on a RaspberryPi ? Does the RPi gadget snap need to do that ?
<om26er> or even is there a "gadget" snap for the Pi ?
<zyga> om26er: yes, regular permissions will still be in the way
<zyga> om26er: you'd have to write a service that can run as root to use them
<om26er> zyga: curious where does this PR stand in all this https://github.com/snapcore/snapd/pull/2065 ?
<mup> PR snapd#2065: interfaces/builtin: use udev to export GPIOs to userspace <Blocked> <Reviewed> <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
<zyga> om26er: on hold
<zyga> I was busy with roscon lately
<rvr> Is there any problem with the store?
<om26er> Currently it seems I can expose the GPIO by adding udev rule, not sure though If I can read/write values to from a confined snap, will test soon.
<rvr> snap install classic doesn't work
<rvr> vrruiz@localhost:~$ snap install hello-world
<rvr> error: cannot install "hello-world": snap not found
<om26er> WFM
<qengho> rvr: Weird. What architecture?
<rvr> qengho: arm64
<qengho> Ah hah.
<qengho> I bet no one made an arm64 package for hello-world.
<qengho> But that can be fixed in no time. ...
<rvr> qengho: Ok, but I could run spread tests just one hour ago
<rvr> and now it's giving me error with snap install classic
<qengho> rvr:  I don't know what that means.
<sergiusens> qengho hello world is arch all I think
<sergiusens> hello however isn't
<sergiusens> too many hellos
<ogra_> ogra@localhost:~$ sudo snap install hello-world
<ogra_> hello-world (stable) 6.3 from 'canonical' installed
<ogra_> ogra@localhost:~$
 * ogra_ is just testing dragonboard arm64 here
<ogra_> not classic though
<ogra_> (do we actually have classic images yet ?)
<om26er> speaking of classic, I don't see a yakkety classic RPi image anywhere.
<rvr> ogra_: I guess so, because it was working this morning
<ogra_> om26er, ask foundations :)
<ogra_> or the server team
<ogra_> or whoever cares for classic these days
<om26er> its boring, still uses linux 4.4 :p as linux-raspi2 was never updated in yakkety
<sergiusens> ogra_ maybe there needs to be clarification on what classic, the enable-classic or a classic install on the rootfs
<ogra_> oh, crap, i mis-read rvr's line above
<om26er> oh wait, 4.8 for RPi is now uploaded.
<ogra_> ogra@localhost:~$ sudo snap install classic --devmode --edge
<ogra_> classic (edge) 16.04 from 'canonical' installed
<ogra_> ogra@localhost:~$
<ogra_> works fine here
<ogra_> rvr, ^^^
<rvr> + snap install --devmode --edge classic
<rvr> error: cannot install "classic": snap not found
<rvr> Hmm
<ogra_> your order is different
<om26er> try turning it off and on again
<om26er> ;)
<rvr> lol
<rvr> This is weird
<rvr> vrruiz@localhost:~$ sudo snap install classic --devmode --edge
<rvr> error: cannot install "classic": snap not found
<mup> Bug #1632336 opened: after first boot /var/lib/snapd/seed/snaps is empty <Snappy:New> <https://launchpad.net/bugs/1632336>
<mup> Bug #1632337 opened: dragonboard beta3 image reboots during snap create-user <Snappy:New> <https://launchpad.net/bugs/1632337>
<Chipaca> popey, on the pi2/3 that get that weird device thing loop, what does "snap --version" say?
<Chipaca> popey, i mean in bug 1632306
<mup> Bug #1632306: 'snap changes' spammed with "Initialize device" <Snappy:New> <https://launchpad.net/bugs/1632306>
<mvo> popey: what revision is your core snap on currently? we are looking at the device registraiton bug reight now
<popey> popey@localhost:~$ snap --version
<popey> snap    2.16+ppa37-1
<popey> snapd   2.16+ppa37-1
<popey> series  16
<popey> on pi 2
<popey> Chipaca: ^
<mvo> popey: revision from snap list please, that will also help us
<Chipaca> popey, ta
<mvo> Chipaca: ppa37 sounds like beta3
<Chipaca> mvo, that's already in the bug :-)
<mvo> popey: *cough* sorry!
<mvo> Chipaca: autsch
<popey> yeah, i would, but running "snap list" takes aaaaaages
<popey> np
<Chipaca> mvo, ubuntu-core 16.04.1 845 canonical -
<popey> ubuntu-core  16.04.1       845  canonical  -
<mvo> popey: aha, takes ages because snapd is so busy churning :/
<popey> confirmed
<popey> it's variable, sometimes it is, sometimes not
<popey> my pi3 is churning, for sure. still not responsed to --version
<popey> popey@localhost:~$ snap --version
<popey> snap    2.16+ppa39-1
<popey> snapd   2.16+ppa39-1
<popey> series  16
<popey> ^ from pi 3
<shuduo> hello, where is right place to define snapweb should be included or not in a customized image?
<gerry_> hi I am just playing with snaps for the first time I have used the first example yaml to style what I want to do with my .jar. Unsuprisingly it does not work I was just looking if there is an easy reason? the yaml is at http://pastebin.com/69B0spML
<mup> PR snapd#2131 opened: tests add spread test for prepare-device customizing device init/registration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2131>
<mup> PR snapd#2132 opened: interfaces/builtin: enable out of process providers for locationd <Created by vosst> <https://github.com/snapcore/snapd/pull/2132>
<Chipaca> ogra_, you around?
<Chipaca> or maybe it's barry
<Chipaca> ogra_, about resizing the image to its smallest, what filesystem is it?
<ogra_> ext4
<mup> PR snapd#2133 opened: osutil: add missing unit tests for IsMounted <Created by mvo5> <https://github.com/snapcore/snapd/pull/2133>
<Chipaca> ogra_, any reason not to make it 4G and then resize2fs -M (and then truncate)?
<ogra_> Chipaca, yes, 4G takes 10.15min to dd, uses your diskspace pointlessly etc etc
<ogra_> *10-15
<Chipaca> ogra_, dd to where?
<ogra_> Chipaca, we already have a bug about this and agreement to implement it properly to only have the images as big as their content requires
<ogra_> Chipaca, to a device
<ogra_> Chipaca, that bug is why i'm so surprised that barry implemented "+50%"
<shuduo> hello ogra_, where is right place to define snapweb should be included or not in a customized image?
<ogra_> which is just nonsense
<Chipaca> ogra_, but I mean resize2fs -M before dd'ing
<ogra_> Chipaca, you need the right partition size ... so you still have an image size that is to big and having the user run resize2fs as a step of a standard install is awful
<ogra_> we have this properly automated on first boot
<ogra_> there is really no need to add other fancy hackery here
<ogra_> we just need ubuntu-image to do the thing that was agreed
<jdstrand> thomi: use 'architectures: [all]'
 * jdstrand notes he is off today and just passing through
<ogra_> shuduo, in your ubuntu-image call when you build the image
<ogra_> shuduo, there might be some way in the gadget but i dont know how that exactly works
<ogra_> s/might/should/
<ogra_> (never used it)
<zyga> tyhicks: hey
<zyga> tyhicks: can you review snap-confine change for me please
<tyhicks> zyga: hey - I can only handle something small/quick right now
<zyga> tyhicks: hmm, this is neither but it is very important
<zyga> tyhicks: alternatively just pick it up tomorrow and review/finish it (if it requires any changes)
<zyga> tyhicks: this is about /media sharing for GA
<zyga> ogra_: hey
<zyga> ogra_: I'm booting beta3 amd64 on vmware and ... I get "cannot find 'writable' partition", being dropped to initrd shell, can you help me debug this?
<tyhicks> zyga: is there an open PR?
<zyga> tyhicks: yes, two, let me give you the links
<zyga> https://github.com/snapcore/snap-confine/pull/169
<mup> PR snap-confine#169: Add spread tests for mount namespace layout <Created by zyga> <https://github.com/snapcore/snap-confine/pull/169>
<zyga> this is easy and just serves as a before/after
<ogra_> zyga, i have not even a clue how to run such an image in vmware, iirc you need to run the image though a bunch of tools to convert it etc
<zyga> while it works fine the json dump is somewhat flaky, in my tests sometimes some entries are ordered in another way and the test fails (nothing is broken but the output is different). I will look at fixing that in the next branch
<shuduo> ogra_: hmm, i can't find clues in the doc https://github.com/CanonicalLtd/ubuntu-image/blob/master/docs/gadget-yaml.rst
<zyga> ogra_: qemu-img and you've got a vmdk
<zyga> ogra_: I wonder if there's something special that qemu does for us that is missing?
<ogra_> nope, nothing special
<zyga> tyhicks: the "meat" is in https://github.com/snapcore/snap-confine/pull/168
<mup> PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168>
<zyga> ogra_: what can I do in initrd to debug this?
<zyga> tyhicks: I'll sort the output, that should fix it
<ogra_> zyga, you could boot with break=premount ... but i'D just inspect the image and the partitioning ... i guess whetever that tool does did somehow trash the partitioning
<tyhicks> zyga: oof... when do you need this reviewed by?
<zyga> tyhicks: ASAP, this is the big late feature
<tyhicks> :(
<zyga> ogra_: thanks, I'll check
<ogra_> not sure if kpartx can handle vmdk
<zyga> ogra_: I can explore from within easily
<zyga> (attach it to another VM)
<ogra_> k
<zyga> ogra_: but I strongly doubt it is corrupted, vmdk is just another wrapper for the same set of bytes
 * ogra_ hasnt used vmware in like 5 years ... so i cant really tell ... 
<ogra_> perhaps the conversion tool removes FS labels ... who knows :)
 * ogra_ curses the beta3 images ... 
<zyga> ogra_: it's a block level convertion
<ogra_> 12min dd ... still going ...
<zyga> ogra_: it doesn't understand fs or partitioning
<ogra_> (30-40sec with the dailies that have a proper size)
<zyga> ogra_: did you have any luck with that wireless SD card
<ogra_> zyga, did you see my mail ?
<ogra_> i sent a summary yesterday
<zyga> ogra_: no, I'm totally behind email
<zyga> I'll read it, thanks
<ogra_> i'm in love !!!
<ogra_> these wireless SD cards are the best since sliced bread
<zyga> ogra_: really? :D
<ogra_> 400MHz v5 CPU, 30MB ram ... linux driven ...
<zyga> ogra_: brig it next week, I'll buy some back home (or maybe in seoul)
<ogra_> just adding a bettery and you have the pÃ¼erfect IoT device
<zyga> v5 heh, maybe we can build core for v5 :)
<ogra_> nah
<zyga> how much flash?
<ogra_> only 1MB disk size on the mtd device
<zyga> oooh
<zyga> omg :)
<zyga> how big is the kernel?
<zyga> and are there sources?
<ogra_> the OS is all busybox + wpa_supplicant
<ogra_> partitally i heard
<ogra_> havent found them yet
<ogra_> there used to be sources but tanscend seems to have taken them down
<ogra_> doesnt matter though ... for our usecase i need to replace the busybox with one that has different applets enabled and add a dropbear binary with proper keyx setup ... the rest of the OS can stay as is
<zyga> ogra_: no matter, I'm happy that it works
<ogra_> it is super insecude ...
<zyga> ogra_: I bet :)
<zyga> plars: ^^ do you know about this?
<ogra_> dsont ever store your nekkid photos on such a card ;)
<zyga> ogra_: I almost wish someone made a wired version of the card :)
<ogra_> (though admittedly you are not jennifer lawrence ... the interest would probably be lower)
<zyga> hehee
<zyga> "omg how do I remover this ugly guy from my computer"
<ogra_> the card has soldering points for serial too btw
<ogra_> so you could drive serial sensors etc
<ogra_> so an Sd card+coin battery ... + whatever serial device you want to use for measuring
<plars> zyga: in a meeting, give me a bit
<zyga> plars: nothing urgent, I bet you will like what orga found for pi testing :)
<ogra_> zyga, indeed, if you dont use the SD side for image testing like we do, the SD can become your rootfs ... so the 1MB mtd size is moot
<ogra_> you'd only use it for jump-start
<ogra_> mvo, so pi3 dies with bug 1630586 now if you dont have a serial cable attached (there is a workaround in the bug i can add to the notes)
<mup> Bug #1630586: Pi3 kernel crash and is unreliable <patch> <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1630586>
<tyhicks> zyga: I'm starting to review those PRs now
<zyga> tyhicks: thanks
<zyga> ogra_: does pi2/3 have hw watchdog?
<mvo> ogra_: hm, what does that mean? image unsuitbable for publication?
<zyga> ogra_: smells like something we should enable early to let snappy recover
<zyga> (on upgrade)
<ogra_> mvo, i added a line to the notes ... see yourself if the workaround is to hard
<ogra_> zyga, i think ppisati tried to enable it on u-boot level but i think it isnt reliable
<mvo> ogra_: hm, hm, feels not ideal, how hard would it be to incoperate this - do we need a new kernel?
<ogra_> mvo, we can either kill serial completely (by removing that line) ... or wait for a new kernel
<ogra_> if you want serial you need the line ... booting without serial requires the line removed currently
<ogra_> mvo, we could default to not support serial at all on the pi3 for beta3 and upload a changed gadget .... but that makes debugging any boot probs really hard
<ogra_> ogra@localhost:~$ snap lust
<ogra_> error: Unknown command `lust', did you mean `list'?
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name        Version       Rev  Developer  Notes
<ogra_> core        16.04.1       75   canonical  -
<ogra_> pi2-kernel  4.4.0-1021-3  14   canonical  -
<ogra_> pi3         16.04-0.4     5    canonical  -
<ogra_> snapweb     0.21          16   canonical  -
<ogra_> looks fine after removing the line
<mvo> ppisati_: what do you think? how long will a new kernel with the fix for the serial issue for pi3 take?
<ogra_> mvo, given that we only had new kernels yesterday (general SRU) i guess a bit
 * ogra_ runs another pi3 test with wlan only 
<ogra_> if dd ever finishes :(
<ogra_> hmm ... console-conf startup time on pi is still not stellar :(
<plars> zyga: Yeah, I saw some emails about ogra_  doing some cools stuff with that. I look forward to hearing how it comes out, but it's all moot if we can't get network and user automatically provisioned
<plars> I've heard that there's some way of getting the user part done by putting a file on a usb stick and leaving it in the device, but I've not seen a functioning example of that yet, nor how the automatically getting the network set up without console interaction would work
<plars> mvo: I heard that you might have answers to at least part of that ^?
<ogra_> plars, why qould yu need that ?
<plars> ogra_: for provisioning the image on the device for automated testing
<ogra_> plars, the card starts in AP mode, you would only have a PC with extra WLAN card that attaches to that AP
<ogra_> there is nothing you need to do on the SD side for this
<plars> ogra_: no, I'm talking about the snappy image that we flash onto it
<ogra_> plars, ah, so you would dd the img and then push additional files to it ?
<ogra_> or mangle files
<plars> ogra_: what you're describing would let us flash the image onto the sd, which we could then boot. But if we want to run tests on it, we would need a way to provision the user and network without having to connect it to video/keyboard and have someone press buttons
<ogra_> plars, and how do you do this today ?
<plars> ogra_: I don't know... I've heard there's supposed to be something we can do with assertions
<plars> ogra_: today? We don't ever since that was changed
<ogra_> mvo, no WIFI only love on pi3 either :(
<plars> ogra_: we didn't have problems before when there was a default user, but it's not possible right now. The latest I've heard is that it should be possible soon with assertions, but no functioning example of how to do it yet
<ogra_> plars, well, you can definitely do some cloud-init stuff today ... so affectively you would push cloud-init user config to it
<plars> ogra_: where does it read that from? can you give me an example or link to documentation on how it looks and how it uses it?
<plars> that's the piece I'm missing at the moment
<zyga> tyhicks: FI, I found the missing sort in process.py, the results are now stable
<zyga> plars: we already can get user provisioned
<zyga> not sure about network
<ogra_> plars, you would need to delete a file in /etc/cloud that by default disables cloud init today ... and tzhen just use the "normal" cloud-init configuration ... whatever that is
<tyhicks> zyga: I've left my review of 169
<ogra_> plars, in any xcase that will be possible via wifi SD
 * zyga looks
<plars> ogra_: where does it get that cloud init config from if I remove the disable file?
<r2geo> hi all, can someone tell me where I can find the a stable image for RPi3? Is there an estimate when the RPi3 image may appear on http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ ?
<zyga> tyhicks: I'll fix 169 and merge this into the other one so that the essential change is visible and accurate (the mountinfo contents)
<ogra_> plars, you dd ... then remount the SD so you have the new filesystem there ... then remove /etc/cloud/disable-cloud-init.foo (or however it is called) then put your cloud-init user config into /writable/system-files/var/cloud/foobar/whatever ... call sync ... re-power the board ... done
<plars> ogra_: I'll give it a try, thanks
<ogra_> plars, everything from dd to sync in that line above would be in a simple shell script the SD card execs when you tell it to
<plars> sure
<ogra_> so regarding the wifiSD it shouldnt matter how you provision, it wont care ... all it will be is a "wlan -> nc -> dd" bridge
<ppisati_> ogra_: mvo: a kernel with the fixed serial is being prepared this week
<ppisati_> it'll go out...
<ppisati_> last week of Oct
<ogra_> phew, thats late
<mvo> ogra_, ppisati_: could we create our own kernel snap for pi3 with just this patch ? or is the amount of work too crazy?
<mup> Bug #1632387 opened: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632387>
<mup> Bug #1632388 opened: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:New> <https://launchpad.net/bugs/1632388>
<ogra_> mvo, filed ^^^ and added to the notes too
<ogra_> mvo, we surely could but thats likely a day of work or so
<ogra_> since i need to use proper debs here
<ogra_> mvo, so with these two drawbacks the pi3 is good as well
<ppisati_> ogra_: if you can build from ckt PPA, you can get it next week
<ogra_> i could set up a special build
<ogra_> mvo, ^^^
<ogra_> so next week
<mup> Bug #1632390 opened: "snap find" return unrelative snap <Snappy:New> <https://launchpad.net/bugs/1632390>
<rvr> ogra_: http://paste.ubuntu.com/23308944/
<rvr> ogasawara: I reinstalled the image, the device has access to the internet, but snap install still doesn't work
<rvr> Oops
<rvr> ogra_: ^
<ogra_> rvr, weird, it definitely worked here
<rvr> ogra_: Also, there are suspicious messages in the syslog about dragonboard-kernel
<ogra_> (i have trashed the Sd now for pi3 testing)
<rvr> ogra_: Yeah, fgimenez could also install it
<ogra_> smells like something went wrong with your initial setup
<plars> hmm, I haven't tried it yet without removing that cloud-init.disabled, but after I removed it from my image and rebooted, it just gets stuck in a boot loop
<plars> shows the 4 raspberries, black screen, repeat
<ogra_> plars, because you have no conbfig in place
<plars> no other output...
<ogra_> cloud-init goes mad if you run it without any config
<rvr> ogra_: Wifi and account setup went fine
<plars> ogra_: I tried it with one, but perhaps I need it to have a different filename/path? I put a very basic one to just create the user in /writable/system-data/var/lib/cloud/cloud-init.conf
<ogra_> plars, yeah, there are special dirs underneath var/lib/cloud/ you need to use
 * ogra_ forgot the exact bits 
<ogra_> plars, if you have access to some 15.04 image, that should have everything ... we used to use this for sertting up the ubuntu user
<plars> ogra_: I'll see if I can find one somewhere
<ogra_> for series 16 there will be some additional changes to make it actuall yuse snap create-user ... but for a first smoke test the old 15.04 stuff should suffice
<ogra_> rvr, did your board not reboot after creating the user ? i think fgimenez and me both had that issue ... perhaps that fixes something you dont have gotten fixed then
<rvr> ogra_: Right, no reboot
<zyga> tyhicks: how are you doing on that other branch?
<rvr> ogra_: I'll try that
<ogra_> rvr, and that is mvo's beta3 test image ?
<ogra_> or are you on one of my dailies
<rvr> ogra_: untested
<ogra_> ok. same here
<fgimenez> ogra_, rvr all the beta3 images are affected, there's a fix for it that hasn't landed yet
<ogra_> then i dont really know whats different
<ogra_> fgimenez, i dont see any reboots on the pi's
<tyhicks> zyga: haven't made much progress just yet and I am about to have to step away for a short appointment
<tyhicks> zyga: it'll be my top priority after I return
<zyga> tyhicks: do you mind if I rebase it to clean up the spread test?
<zyga> tyhicks: no changes to any of the c code
<fgimenez> ogra_, i found the issue on the pi3, all the images are affected afaik, maybe you didn't wait enough
<tyhicks> zyga: now would be a great time for that
<zyga> tyhicks: thanks, I'll do that then
<zyga> tyhicks: when will you get back?
<tyhicks> zyga: about an hour from now
<ogra_> fgimenez, well, i just finished a pi3 (wired network, hdmi/usb kbd with the uart fix in config.txt) ... no reboot at all and works just fine
<zyga> ah, ok, I _might_ be around still
<zyga> though 1:38 AM now ;-)
<plars> ogra_: no luck - I copied over the user-data file from an old image to the same path on my sd, and I still get the reboot loop. Maybe fgimenez has tried this?
<ogra_> plars, well, there might be bugs :)
<ogra_> i just know how it is supposed to work
<ogra_> and my wifiSd setup will still take a while til it is ready, so we have time
<ogra_> (to fix the bugs)
<ogra_> plars, iirc there were two dirs and two files in 15.40
<ogra_> *04
<ogra_> did you copy both ?
<plars> ogra_: yes, the meta-data one was the same as I already have thre
<plars> *there
<ogra_> one for user and one for system stuff
<ogra_> ah, k
<fgimenez> ogra_, mmm i see it happening on the untested image, sometimes during console-conf, sometimes after, but the issue is there, after the first reboot all goes fine
<plars> ogra_: This was the path and contents of the user-data one: https://www.irccloud.com/pastebin/3AZ5Etxv/
<ogra_> plars, could you try a daily image instead ? that you see nothing but berries is definitely also wrong ... we fixed that a while ago in the dailies and about 2h ado in the beta candidates
<rvr> Argh
<rvr> Same after reboot
<rvr> error: cannot install "classic": snap not found
<fgimenez> ogra_, this PR fixes the problem https://github.com/snapcore/snapd/pull/2117
<mup> PR snapd#2117: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2117>
<plars> ogra_: ah, that could be then... let me re-download. I grabbed it from here, but it looks like the pi3 image is gone (and no db410c yet too): http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/
<plars> ogra_: so there's no new daily yet?
<ogra_> plars, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> every day :)
<plars> oh nice!
<ogra_> fgimenez, right ... but that only causes a normal reboot with the "system will reboot in 10 min" warning on the console ... the reboot in console-conf when creation the user looks more like a crash
<ogra_> *creating
<fgimenez> ogra_, yes, it's the same issue
<ogra_> fgimenez, why did i get the notification after the dragonbaord was set up then ?
<ogra_> (i.e. after the reboot that happened in the middle of console-conf)
<ogra_> i dont think they are the same ...
<fgimenez> ogra_, not sure, i'm having a lot of unrelated reboots in dragonboard, something different is happening there
<ogra_> (but it is moot anyway, teh fix will land andd we'll see if console-conf will work then)
<ogra_> i did two installs and only had one reboot in each of them when console-conf ran snap create-user ... reliable and reproducable in both tests i did
<ogra_> i didnt use the first one long enough to know if i also had the 10min waring then ... i definitely had it on the second install though
<ogra_> fgimenez, do you run your board with the mezzanine board attached ?
<ogra_> (i do)
<ogra_> prehaps that has some influence
<fgimenez> ogra_, on dragonboard i have the firstboot reboot as in the rest of images and then a lot more of them
<ogra_> weird
<fgimenez> while executing the suite
<rvr> ogra_: fgimenez: Could my U1 account be misconfigured?
<ogra_> rvr, how would that be misconfigured ? if you have an ssh key it will download it
<lucacome> hello
<fgimenez> ogra_, no mezzanine here, looks nice :)
<rvr> ogra_: Well, I'm trying to guess why snap install works for you and not for me
<lucacome> do you know if there are any statistics about the adoption of snap?
<ogra_> fgimenez, aha ... we default to serial console only on the dragonboard currently ... i bet you have more instability because it tries to write console stuff to serial
<fgimenez> ogra_, well only the uart to usb adapter card
<ogra_> that *is* the mezzanine board ;)
<fgimenez> ogra_, aha! then yes :)
<ogra_> http://www.96boards.org/products/mezzanine/
<fgimenez> i thought you were talking about this http://www.96boards.org/products/mezzanine/linksprite-7-display-kit/
<ogra_> http://www.96boards.org/products/mezzanine/uarts/
<fgimenez> yep that's it
<ogra_> right
<ogra_> ok, so it isnt that
<ogra_> sad, i had some hope :P
<rvr> I have an UART to USB adapter, for programming atmel chips
<rvr> I guess it can be used with the Dragonboard connecting the correct pins
<plars> ogra_: I can't seem to open the writable partition from your image directly, not even after I write it to the sd. Maybe that's something to do with the resize?
<ogra_> plars, nope ... there is still some wiggle room
<plars> ogra_: [1951890.585324] EXT4-fs (dm-1): bad geometry: block count 118499 exceeds size of device (118272 blocks)
<ogra_> you should be able to write a few mb
<ogra_> "exceeds size of device" ?!?
<ogra_> what size is that SD =
<ogra_> ?
<plars> similarly, when I try to do it with the sd: [1951839.136126] EXT4-fs (mmcblk0p2): bad geometry: block count 118499 exceeds size of device (118272 blocks)
<plars> ogra_: the first one was just trying to open the raw image file after running it through kpartx
<plars> ogra_: the second was after writing it to an 8GB sd
<fgimenez> rvr, at last i'm getting the same error installing classic on dragonboard, it seems that the error comes from the store http://paste.ubuntu.com/23309074/
<rvr> fgimenez: !!!!
<rvr> So at the end, I am not mad ;)
<rvr> Although I was getting mad!
<ogra_> plars, works fine here ... i can plug the SD in and nautilus auto-mounts the partitions
<plars> ogra_: strange - is that with the pi3 image?
<ogra_> plars, with all images ...
<ogra_> the geometry is indeed wrong, but it should still be mountable
<plars> mine doesn't mount... extraction went ok but I didn't check the checksum. Let me retry downloading. I'll grab another one too as a sanity check
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls /media/ogra/
<ogra_> system-boot  writable
<ogra_> this i get when re-plugging the SD after dd'ing it
<rvr> fgimenez: Who do manage the store?
<ogra_> why does it work for me then ... very weird
<rvr> fgimenez: Ok, snap install works with ubuntu-snappy/16.04/current/
<ogra_> are both of you using --devmode --edge ?
<rvr> ogra_: I just installed hello world in Dragonboard with that image
<rvr> No devmode nor edge
<rvr> But I couldn't do that with the untested image
<ogra_> you need it for classic
<ogra_> there is no stable classic package
<ogra_> (never has been)
<ogra_> ogra@anubis:~/datengrab/images/snappy$ df -h /dev/sdc*
<ogra_> Dateisystem    GrÃ¶Ãe Benutzt Verf. Verw% EingehÃ¤ngt auf
<ogra_> udev            7,8G       0  7,8G    0% /dev
<ogra_> /dev/sdc1       127M     22M  105M   17% /media/ogra/system-boot
<ogra_> /dev/sdc2       3,3G    313M  2,9G   10% /media/ogra/writabl
<ogra_> plars, ^^^ i just freshly dd'ed
<ogra_> re-plug .... and i get the above
<fgimenez> ogra_, yes, that comes from the suite https://github.com/snapcore/snapd/blob/master/spread.yaml#L117
<ogra_> ogra@anubis:~/datengrab/images/snappy$ touch /media/ogra/writable/foo.txt
<ogra_> touch: '/media/ogra/writable/foo.txt' kann nicht berÃ¼hrt werden: Keine Berechtigung
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo touch /media/ogra/writable/foo.txt
<ogra_> ogra@anubis:~/datengrab/images/snappy$
<ogra_> plars, ^^^
<ogra_> that works too
<plars> ogra_: just re-downloaded, checking again now
<ogra_> fgimenez, are you sure prefixing the options is supposed to work ?
<ogra_> sudo snap install classic --devmode --edge
<ogra_> that is what i use all the time
<pmcgowan> ogra_, hey do you know about the network bridges snapd sets up
<rvr> classic (edge) 16.04 from 'canonical' installed
<ogra_> nope
<rvr> So there is something wrong with the untested image and the store
<ogra_> pmcgowan, you mean netplan ? thats pitti-land
<pmcgowan> ogra_, I see lxdbr0
<fgimenez> ogra_, yes, according to snap install --help the install options should go between "install" and the snap name
<pmcgowan> its grabbing an address that is screwing me up I suspect
<ogra_> fgimenez, well, i always use it the other way around ...
<ogra_> and it works here
<fgimenez> ogra_, good to know that works too :)
 * ogra_ dd's another dragon image to verify ... cant be that everything works for me but doesnt for you guys 
<ogra_> are we actually using the same image ?
<ogra_> :P
<ogra_> pmcgowan, well, i'm pretty sure snapd doesnt set up any lxc network devices
<rvr> The untested one, Oct 7th
<ogra_> pmcgowan, unless you install an lxc snap or use snapcraft cleanbuild there is nothiong that involves lxc/d in snappy
<ogra_> rvr, yes
<pmcgowan> ogra_, ok somethig else then
<plars> ogra_: ok, it seems I'm able to mount the dragonboard one, but not the pi3 one
<ogra_> plars, well, all the above was pi3
<plars> ogra_: weird
<ogra_> plars, else it would have been sdc8 and 9
<plars> Yeah
<ogra_> ogra@localhost:~$ sudo snap install classic --devmode --edge
<ogra_> classic (edge) 16.04 from 'canonical' installed
<ogra_> ogra@localhost:~$
<ogra_> fginther, rvr ^^^ i'm looged in for the first time ...
<ogra_> ogra@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.4.0-1024-snapdragon #27-Ubuntu SMP Fri Aug 12 11:45:29 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
<ogra_> ogra@localhost:~$
<ogra_> no issues at all with classic
<ogra_> i dont get it ...
<rvr> :-/
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name                Version       Rev  Developer  Notes
<ogra_> classic             16.04         17   canonical  devmode
<ogra_> core                16.04.1       74   canonical  -
<ogra_> dragonboard         16.04-0.17    23   canonical  -
<ogra_> dragonboard-kernel  4.4.0-1024-3  9    canonical  -
<ogra_> snapweb             0.21          17   canonical  -
<ogra_> ogra@localhost:~$
<ogra_> do your versions match ?
<rvr> I don't get any list
<ogra_> ( core 74 specifically )
<ogra_> so weird
<ogra_> as if we had different boards
<ogra_> (or different images)
<zyga> ha
<zyga> found it
<zyga> damn, that was silly
<zyga> I should sleep
<ogra_> silly is the new clever i heard
<ogra_> ;)
<zyga> hehehe
<zyga> well, clever is the "has regular sleeping patterns" thing
<ogra_> sleeping is for the week^Wweak
<ogra_> (or so)
<mup> Bug #1632085 changed: Support "fudge factor" for file system sizing <Ubuntu Image:In Progress by barry> <https://launchpad.net/bugs/1632085>
<plars> ogra_: tried the cloud-init bits on dragonboard, it boots at least, but no network, no user - still wants manual config :(
<plars> nothing in cloud-init.log too
<tyhicks> zyga: I'm back and can start looking at 168 again - are you close to pushing the rebased version?
<zyga> tyhicks: yes, but don't worry, just keep on reading and commenting
<zyga> tyhicks: I'll merge
<zyga> tyhicks: I was just not sorting the stuff correctly and I cannot imagine it even worked at all
<kyrofa> zyga, why are you here?
<zyga> kyrofa: well, you know me
<zyga> kyrofa: but I had a great day
<kyrofa> zyga, tsk tsk
<kyrofa> zyga, manage to avoid more meetings?
<zyga> kyrofa: and I just love the feeling when something works well
<zyga> kyrofa: I will just smile and say I was far away from other people ;)
<kyrofa> zyga, good ;)
<zyga> kyrofa: this place is amazing
<zyga> kyrofa: I found so many cool things today
<kyrofa> zyga, does your new hotel have that soup?
<zyga> kyrofa: soup?
<zyga> kyrofa: which one?
<kyrofa> That one you like for breakfast
<zyga> kyrofa: this place has no food, I moved to the old town, there are restaurants like *everywhere* here
<kyrofa> Ah, that sounds _great_
<zyga> kyrofa: I did't try the breakfast here yet, I had onigiri for breakfast
 * zyga googles to check if he rememebers the name right
<zyga> yep
<zyga> I don't remember the korean name though
<kyrofa> Ah, nice
<zyga> this hotel is so not enterprise level though :) the room is the size of the bed in the other one :)
<zyga> but it's fun, the owner even learned some polish today to surprise me
<zyga> tyhicks: I just pushed to https://github.com/snapcore/snap-confine/pull/169/files
<mup> PR snap-confine#169: Add spread tests for mount namespace layout <Created by zyga> <https://github.com/snapcore/snap-confine/pull/169>
<zyga> tyhicks: I'll merge this into the other branch and resolve conflicts
<zyga> tyhicks: how do you feel about the 2nd branch?
<tyhicks> zyga: still processing it - this is a lot of change to the most complex part of the project :)
<tyhicks> zyga: no deal breakers yet
<zyga> tyhicks: fingers crossed then, thank you for working on this!
<tyhicks> zyga: np - nice job on getting something working
<tyhicks> zyga: do you have a link to that doc that you wrote up before starting to implement this?
<zyga> yeah, give me a second
<zyga> there's one thing I didn't comment on that's somewhat bad
<zyga> bootstrap pollutes the main NS if it dies mid-way
<zyga> I was looking for ways to avoid that but I don't think this is possible
<zyga> there might be a way to detect abnormal termination and use a child to help clean up but this is imperfect
<zyga> tyhicks: I think there was no doc this time, it was for the ns sharing but not for this
<zyga> tyhicks: we had a pastebin and a shell prototype
<tyhicks> zyga: the main NS is only polluted due to /tmp/snap.rootfs_XXXXXX having mounts set up inside of it, correct?
<tyhicks> zyga: ah, I must have gotten those two confused - thanks for looking
<zyga> tyhicks: yes, that directory will still have some stale bits if we terminate abnormally
 * tyhicks nods
<thomi> Thanks jdstrand, I'll try that. I must have missed it in the docs on snapcraft.io?
<zyga> damn
<zyga> well, just anoying
<zyga> tyhicks: AFAIK I removed cgroups because they get mounted in unexpected order, so I was thinki that I should sort stuff so that I can do deterministic remapping but parts of the sorted strings are random
<tyhicks> zyga: ok, skip cgroups for now
<tyhicks> zyga: that is frustrating
<zyga> I'll sort twice,first after partial derandomization (just paths) and then after everything else is derandomized
<zyga> I'll just test this a few more times before I push it again, you really have to reboot the test machine to see this fail
<kgunn> noise][ you about?
<tyhicks> zyga: I've just submitted my review
<kgunn> nessita_: or you about?
<zyga> tyhicks: thank you, checking
<pmcgowan> snapd wont run for me today, http://pastebin.ubuntu.com/23309681/
 * kyrofa needs a nap, back in a bit
<kgunn> nessita_: noise][ so i'll just leave my query here...long time ago :) i made "mir-server" namespace in the store... i suppose at the time i said amd64 for supported arch's
<kgunn> i now have armhf and arm64 snaps available, is there any way to change the namespace to reflect this? so that i can upload these for folks?
<pmcgowan> also seeing Oct 11 19:39:39 localhost snapd[3538]: error: cannot downgrade: snapd is too old for the current system state (patch level 4)
<kgunn> ...at least, it's not obvious to me how i might do it looking at my options in myapps.developer.com
<josepht> kgunn: have you tried to upload one of the new architecture's snaps?
<kgunn> josepht: ironically...did just now....and i see it's saying arm64...so it's smart that way
<kgunn> ?
<josepht> kgunn: yes, that's been my experience.
<kgunn> cool thanks josepht i was having nightmares thinking i was going to have to create a new store namespace just for arch support
<josepht> kgunn: no problem
<mup> Bug #1632452 opened: snappy store still indicates Martin Albisetti for publishing <Snappy:New> <https://launchpad.net/bugs/1632452>
<mup> PR snapd#2133 closed: osutil: add missing unit tests for IsMounted <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2133>
<mup> PR snapd#2127 closed: tests: add test for auto-mount assertion import <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2127>
<mup> PR snapd#2126 closed: tests: add spread test for `snap auto-import` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2126>
<mup> PR snapd#2121 closed: cmd/snap: do not auto-import from loop or non-dev devices <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2121>
<mup> PR snapd#2117 closed: snapstate: avoid reboots if nothing in the boot setup has changed <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2117>
<mup> PR snapd#2119 closed: tests: abort tests if an update process is scheduled <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2119>
<mup> PR snapd#2124 closed: daemon: add postCreateUserSuite test suite <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2124>
<mup> PR snapd#2118 closed: overlord: merge overlord/boot pkg into overlord/devicestate <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2118>
<mup> Bug #1632452 changed: snappy store still indicates Martin Albisetti for publishing <Software Center Agent:New> <https://launchpad.net/bugs/1632452>
<mup> PR snapd#2134 opened: overlord/devicestate: recover/mark as seeded devices that were first booted with the old external approach <Created by pedronis> <https://github.com/snapcore/snapd/pull/2134>
<benbro> any update on this?
<benbro> https://bugs.launchpad.net/snappy/+bug/1584779
<mup> Bug #1584779: Upgrade a running snap without restarting it <Snappy:Confirmed> <https://launchpad.net/bugs/1584779>
<mup> PR snapd#2135 opened: cmd/snap: simplify auto-import mountinfo parsing <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2135>
<mup> PR snapd#2136 opened: tests/lib: prepare ubuntu-core with core from beta <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2136>
<mup> PR snapd#2134 closed: overlord/devicestate: recover/mark as seeded devices that were first booted with the old external approach <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2134>
<mup> Bug #1632508 opened: Get a way to differentiate uninstall/shutdown from snap update in stop script <lxd> <Snappy:New> <https://launchpad.net/bugs/1632508>
#snappy 2016-10-12
<mup> Bug #1619245 changed: console-conf does not allow to create a user for offline devices <Snappy:Fix Released> <subiquity (Ubuntu):Invalid> <https://launchpad.net/bugs/1619245>
<mwhudson> um why am i waiting for cloud-init to time out today
<ahoneybun> mhall119: popey still kicking?
<Brad__> Hello
<mup> PR snapcraft#865 opened: Add `init-plugin`  <Created by jaymell> <https://github.com/snapcore/snapcraft/pull/865>
<dholbach> good morning
<dholbach> didrocks, davidcalle, do you think we could steal a bit of the playpen CI and document it so we can explain upstreams how to set up a build/publication run with CI in a doc somewhere?
<dholbach> ethercalc just merged my snapcraft.yaml and they seem interested
<didrocks> dholbach: sure, but it only produces amd64 snaps
<didrocks> dholbach: I'm going to go to a dark hole (recording some videos)
<didrocks> but we can discuss afterwards
<dholbach> didrocks, sure, let's chat later
<mup> PR snapd#2137 opened: tests: run ubuntu-core-upgrade on own machine <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2137>
<mup> PR snapd#2136 closed: tests/lib: prepare ubuntu-core with core from beta <Created by niemeyer> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2136>
<om26er> where to find latest all-snap for RPi2 that is not 4gb in size ?
<pitti> ogra_, morphis, slangasek: nplan is now in xenial-updates, including all NM and systemd fixes; so you should be able to drop these from the overlay PPA
<pitti> (it also includes that NM naming hack)
<om26er> does static ip + custom dns work now ? (I remember there was an issue with that)
<ogra_> pitti, YAY !
<dr1337_> ogra_: what's the best place to start to build a system image for an IoT device using snappy core?
<ogra_> dr1337_, what hardware ?
<dr1337_> ogra_: ARMv7a
<dr1337_> ogra_: BSP is kind of working at the moment
<ogra_> is it supported by a kernel we have ? (linke linux-generic)
<dr1337_> ogra_: I'm using mainline at the moment
<ogra_> no patches ?
<dr1337_> ogra_: 4.8.1 so I guess I could just merge the patches
<dr1337_> ogra_: no patches
<ogra_> ok, so kernel side you might be able to just use the arhive kernel. that makes it easier
<ogra_> *archive
<ogra_> dr1337_, http://bazaar.launchpad.net/~ogra/+junk/linux-generic-bbb/files this is what i use to build the beaglebone kernel snap from the archive kernel deb
<dr1337_> you mean this? - https://github.com/snapcore/sample-kernels/tree/master
<ogra_> you might need to switch it to yakkety somehow
<ogra_> once you have this done you need to create a proper bootloader setup ... we only support uboot and grub atm
<dr1337_> ogra_ isn't xenial supported yet?
<ogra_> xenial doesnt have 4.8 debs
<dr1337_> ogra_: I have uboot and kernel loading
<ogra_> right, you will need to make some adjustments to the build time config of uboot
<dr1337_> ogra_: I actually have a rootfs running 16.04.1 core base
<ogra_> we load our environment from a binary blob file and only support raw kernel and initrd loading .... these three things need to be enabled in your uboot binary
<ogra_> then you need to create the binary blob from your default uboot env and add the snappy specific script and variables
<ogra_> once you have all this working, you wrap it together with image partitioning info into a gadget snap
<dr1337_> ogra_ what's the binary blob file for?
<dr1337_> could you point me in the direction of some documentation?
<ogra_> it is similar to uEnv.txt ... but since it has a fixed size you can not corrupt it easily when the filesystem underneath gets issues ...
<ogra_> not yet, i have to write some :)
<dr1337_> ogra_ is that similar to a boot.scr file?
<ogra_> during the boot process both, uboot itself as well as the booted OS can write to the config ... if you use a uEnv.txt file on top of a fat system things can get shuffled around and at some point your file gets corrupt
<ogra_> no, it is an actually binary blob, imagine a raw partition for the config ... now take the content and put it into a img file ... that is more how it works
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/
<ogra_> that are our gadget snap source trees
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/beagleblack/README explains how the binary blob gets created
<ogra_> and here is an example of the uboot config changes we use http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi3/uboot.patch
<om26er> pitti: in netplan world how can I disable wireless power management, any pointers ?
<pitti> om26er: that's outside of netplan or even NM; I suggest starting with powertop
<pitti> that has toggles for everything, and also shows you which sysfs attribute to toggle
<dr1337_> ogra_: thanks mate
<pitti> (for scripting it)
<ogra_> dr1337_, i'll most likely do a series of blog posts soon and work with the doc team on a proper porting guide
<ogra_> just need to find some time :)
<dr1337_> ogra_ would love to find out more - we have plans on putting ubuntu core on our "hub" for production
<om26er> ... if I can get that running on a Pi
<dr1337_> essentially it's a resurrected ninja sphere ;)
<ogra_> awesome ... !
<dr1337_> ogra_: a bit painful though - working with more exotic hardware this time
<ogra_> well, that shouldnt get in your way for doing a basic port
<ogra_> and since there is a beaglebone setup deriving from it shouldnt be to hard for your setup
<dr1337_> ogra_ well I did spend a whole day banging my head against the table why i couldn't get a UART TTY working with a core rootfs
<dr1337_> turns out it was missing udev
<ogra_> you mean a base rootfs ?
<dr1337_> which is kind of understandable if you're running core fore cloud VMs
<dr1337_> yeah
<ogra_> (core definitely has udev ;) )
<dr1337_> ogra_ not this guy - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-arm64.tar.gz
<dr1337_> actually i meant this one - http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04-core-armhf.tar.gz
<ogra_> dr1337_, well, the core in there is wrong :)
<ogra_> (in the name i mean)
<dr1337_> ogra_: erm....wtf?
<ogra_> http://cdimage.ubuntu.com/ubuntu-base/releases/16.04/release/ubuntu-base-16.04.1-base-armhf.tar.gz
<ogra_> the "core" named image is just for backwards compatibility ... technically the core name is now reserved for snappy
<ogra_> and the old "core" was completely renamed to "base"
<dr1337_> ogra_: omg...if only i had known
<ogra_> and base is a way smaller packageset
<ogra_> (it is pretty much exactly what you get with "debootstrap --minbase")
<dr1337_> ogra_ yeah makes sense now
<om26er> pitti: I was able to disable wifi power management from classic environment on all-snap. (iwconfig, the friend :)
<om26er> ogra_: it adds lxd group but lxd still does not start, AFAIK, lxd needs to be a system group
<om26er> zyga: 'home' interface does not connect automatically when I install my snap, is that a bug ?
<om26er> my snapcraft.yaml looks like this http://bazaar.launchpad.net/~om26er/+junk/crossbar-snap-pkg/revision/1
<om26er> network and network-bind connect automatically however.
<ogra_> om26er, so make it one
<ogra_> (the -r option to groupadd makes it one)
<om26er> ogra_: how can I delete the previously added lxd group ?
<ogra_> om26er, hmm, i guess that only works manually
<om26er> ogra_: know the filename/location ?
<ogra_> (remove it from /var/lib/extrausers/group and /var/lib/extrausers/gshadow)
<Brad_> Hello
<Brad_> Hi John.
<Brad_> Is anyone creating snaps, here?
<mup> PR snapcraft#863 closed: history/status alignment fixes <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/863>
<mup> PR snapcraft#864 closed: Update documentation links to developer.ubuntu.com that now redirect â¦ <Created by robert-ancell> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/864>
<liuxg> sergiusens, ping
<sergiusens> liuxg just ask the question ;-)
<liuxg> sergiusens, last time, I reported a bug regarding installing a local debian package. https://bugs.launchpad.net/snapcraft/+bug/1604669, it was fixed. My question is that how I can make use of it. is there any example for it? thanks
<mup> Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1604669>
<sergiusens> liuxg just do source: <path to source>
<liuxg> sergiusens, what plugin should I use?
<sergiusens> liuxg sources and plugins are orthogonal
<sergiusens> liuxg but I guess if you just want to unpack, use dump
<liuxg> sergiusens,  yes, I just want to install a local debian only. OK. I will have a try. thanks. so "orthogonal" should also work, right?
<sergiusens> liuxg USE dump
<liuxg> sergiusens, many thanks
<rharper> ogra_: hi, I've been trying to find out which part of the build process (using ubuntu-image and my own provided core snap I rebuilt with a PPA to inject a new cloud-init with some snappy changes for system-user assertion);  injects the /etc/cloud/cloud-init.disabled into the system-data partition ... I didn't see anything in the core snap, nor in the pc.gadget or ubuntu-image tool ...
<ogra_> rharper, it is actually snap prepare-image i think ... it will create the file if it finds no cloud-init stuff inside the gadget ... then ubuntu-image just blindly copies /etc inot the img
<ogra_> so to have it not created you need to ship your cloud-init configuration in the gadget snap ... now ... i dont exactly know how the format has to be ... you have to ask someone from the snapd team .... mvo perhaps
<rharper> ogra_: ok, is prepare image part of ubuntu-build ?   a quick grep through mvo's git repo of ubuntu-build didn't hit any lines with cloud-init.disabled
<ogra_> prepare-image is a snap command ... "snap prepare-image"
<rharper> ah
<ogra_> ubuntu-image just calls it
<rharper> there's a whole lot of indirection here =)
<ogra_> yeah
 * rharper goes to read snapd prepare-image code
<ogra_> rharper, https://github.com/snapcore/snapd/pull/2101
<mup> PR snapd#2101: image: support gadget specific cloud.conf file <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2101>
<rharper> ogra_: thanks
<ogra_> that looks relevant
<ogra_> for deeper insight ask niemeyer or mvo
<ogra_> (i.e. i have no clue whats the expected format inside that file, where it lands on the filesystem etc etc)
<rharper> right
 * rharper goes to make his own gadget snap
<ogra_> snappidisnap
 * ogra_ sticks his head back into wifiSD card code
<mup> PR snapd#2138 opened: many: removed frameworks target, and some leftover frameworks helpersâ¦ <Created by chipaca> <https://github.com/snapcore/snapd/pull/2138>
<attente> pitti: hey, about #1580740, i see two problems. one is the fake xdg-open script can't be found by the script (which i think is a problem with the snap itself), the other is that nothing is pulling in snapd-xdg-open on the iso
<mup> Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-done> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740>
<ogra_> attente, i thought the first one was a snap-confine issue
<attente> ogra_: i think the problem is that we don't have the fake xdg-open script anywhere that the snap can find it
<ogra_> it should be in /usr/lical/bin inside of the ubuntu-core snap
<ogra_> *local
<seb128> it's in the ubuntu-core snap no?
<seb128> that dir is not in the path though
<attente> ogra_: seb128: i did a strace, but it doesn't find it at all
<ogra_> (or in future-speak ... in the core snap :)
<seb128> attente, is the binary there on disk?
<seb128> dunno if ubuntu-core got updated to have it
<ogra_> ogra@styx:~$ ls /snap/ubuntu-core/current/usr/local/bin/
<ogra_> apt  apt-cache  apt-get  no-apt  xdg-open
<seb128> it was outdated for a while, I had to change channel to get it
<seb128> but that was like in august
<seb128> it might be because that dir is not in PATH
<attente> so the telegram snap needs to add it to the path then?
<ogra_> it should be ... but to be sure you can indeed add it to PATH in your wrapper
<seb128> dunno
<seb128> but j_dstrand said it was weird to have in /usr/local anyway
<sergiusens> attente what is the path?
<seb128> we should probably just move it to /usr/bin
<sergiusens> the path I need to add that is
<ogra_> seb128, tricky ... since the original lives there
<sergiusens> yeah, that would be best seb128
<attente> sergiusens: /snap/ubuntu-core/current/usr/local/bin
<seb128> ogra_, but the original is not in the ubuntu-core snap
<ogra_> so on pd based systems you would have a clash
<sergiusens> ogra_ welcome dpkg divert ;-)
<ogra_> i.e. it would require quite some dpkg-divert hackery if you want to use similar build scripts for both snaps
<attente> the other problem still exists too. nothing pulls in snapd-xdg-open on the iso and it isn't seeded
<ogra_> which is awful
<seb128> attente, sergiusens, is that snap trying to call xdg-open directly? we have a .desktop that makes the mimetype association so gio functions should work
<seb128> attente, right, snapd should probably recommends it?
<seb128> but that's up to mvo I guess
<ogra_> attente, i think it was supposed to be merged into either snaapd or snap-confine
<sergiusens> seb128 honestly have no idea; but I have seen direct calls in some other code
<attente> seb128: strace seems to show it looking for the xdg-open binary
<seb128> k
<ogra_> the sepearate package was an interim afaik
<seb128> well try the PATH thing
<ogra_> yeah
<ogra_> ogra@styx:~$ hello-world.env |grep ^PATH
<ogra_> PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<ogra_> ogra@styx:~$
<ogra_> yeah, not in PATH by default ... but i think the desktop launchers add it
<seb128> is that snap using the desktop launcher?
<ogra_> (we could just stuff it into /usr/games instead of /usr/local :P )
<rharper> created an updated pc gadget to include some cloud-init config, build the gadget snap, updated my model to use the new gadget, signed the model and now building, I get a prepare-image failure, http://paste.ubuntu.com/23313239/
<rharper> anyone ever debug a "ERROR:ubuntu-image:Crash in state machine" with prepare-image ?
<ogra_> rharper, well, it says it cant find your gadget snap
<iliv> how can I donwload source of package (snapcraft.yaml, etc.) for a package that can be installed with snap install $SNAP?
<mup> PR snapd#2137 closed: tests: run ubuntu-core-upgrade on isolated machine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2137>
<ogra_> iliv, you ahve to ask the packager for it
<ogra_> *have
<iliv> ogra_, okay, thanks!
<rharper> ogra_: hrm, I thought the syntax for a local gadget snap was the name of the snap (without the .snap) extension?
<ogra_> in the assertion, yeah
<rharper> right
<rharper> ogra_: here's the model assertion I have http://paste.ubuntu.com/23313336/
<ogra_> rharper, everything after the underscore is a version string ... drop it
<ogra_> you only want the name (pc)
<rharper> ok, but the .snap file I pass via --extra-snaps is OK to include that string? or just rename it all ?
<ogra_> i think it doesnt matter
<rharper> got it working now; thanks !
<ogra_> :)
<om26er> Hi! One of the projects that I am snapping reads /var/lib/dbus/machine-id, in strict mode it gives me permission denied, what's the remedy ?
<nacc> om26er: presumably an interface to dbus / that file
<mup> PR snapd#2135 closed: cmd/snap: simplify auto-import mountinfo parsing <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2135>
<mup> Bug #1632453 opened: snapd won't start on dragonboard <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1632453>
<om26er> nacc: right, so it seems instead of permission denied, the issue is that it cannot find that file within its path. So as you say an interface might help here (not sure though what the solution would be).
<om26er> http://paste.ubuntu.com/23313607/
<nacc> om26er: right, in the snap itself, i doubt that file exists
<nacc> om26er: /var/lib/dbus may not exist either, possibly
<nacc> om26er: you may want to look at adding a 'shell' application to drop to a shell in your snap's environment to debug
<nacc> om26er: and then you could see if adding appropriate pacakge dependencies would fix it (i doubt it, as that's a runtime file)
<nacc> om26er: by default, i don't think your snap has any dbus connection
<sergiusens> narc om26er snap run --shell <snap-name.app-name>
<nacc> sergiusens: ah cool, thanks!
<sergiusens> narc ^
<nacc> sergiusens: i thought it might exist, but couldn't recall :)
<sergiusens> darn. Double fail
<nacc> heh
<sergiusens> Autocorrect kills me with irc handles
<om26er> nacc: sergiusens right, so whats the solution :)
<sergiusens> om26er simple one is to make it not depend on /var/lib/dbus
<nacc> om26er: i'm guessing either remove that dep, or add an interface that provides it to snaps
<om26er> sergiusens: hmm, that's an upstream project that I don't control.
<om26er> to be precise: https://github.com/crossbario/crossbar
<nacc> om26er: it falls back though?
<nacc> om26er: in the code, if it can't read machine-id, it falls back to socket.gethostname()
 * sergiusens wonders why everyone is so afraid of forking
<sergiusens> it is the BETTER patching afer all
<nacc> "On Linux, it is universally available, given that "
<nacc> sergiusens: snaps do violate some public blog posts :)
<nacc> http://0pointer.de/blog/projects/ids.html
<nacc> fwiw, that's the link in crossbar's source as to why they picked that file
<om26er> nacc: not sure if it fallbacks, it rather just skips, so the config file ultimately does not have machine_id. I have seen multiple times that causing some kind of error from crossbar
<om26er> adding the machine id manually fixes that, so its a bug
<nacc> om26er: oh it might be that socket.gethostname() returns nothing? depends on where it's run, i guess
<nacc> om26er: a bug in what? i'd say it's a bug in your snap :)
<sergiusens> nacc I bet you can use /proc/self/sessionid
<nacc> sergiusens: ack
<nacc> it seems to be just an arbitrary string to uniquely identify the machine
<om26er> nacc: yes, thats that I mean :)
<nacc> om26er: so i'd fork and try with something that is available to snaps (just point to your github tree instead of upstream) -- probably can even do a PR to update upstream eventually? Or add an actual interface (if you want), but the latter is probably slower
<om26er> nacc: any thing that requires changes upstream is a deal breaker IMO. So would try the slower path but I think there have been conversations on @snapcraft about accessing files from other system directories, so I'll keep a close eye on that.
<nacc> om26er: why? you can fork trivially in github and build against your fork?
<sergiusens> om26er I disagree about changing upstream
<sergiusens> with that mind set nothing new would ever happen
<om26er> nacc: I am working with upstream to get their package officially uploaded. this whole app-my_name scheme is what I am trying to avoid.
<nacc> om26er: right, but it's not reasonable to say you can snap your application without any modifications
<nacc> afaict
<nacc> there are assumptions being made, such as this one assumign d-bus is present in the snap
<nacc> *accessible perhaps
<om26er> sergiusens: historically its been proved that not all upstreams feel excited to change their code to work with a specific project, so the status-quo does exist. Something that cannot be denied.
<om26er> nacc: assumption based on suggestions from people working on systemd and pulseaudio and probably dbus.
<nacc> om26er: yes, still an assumption
<sergiusens> om26er the discussion for me is over as you are not even trying
<om26er> sure
<ogra_> niemeyer, dude !
 * ogra_ goes offline
<Croepha> hi, is anyone familiar with an issue where running /snap/bin/ubuntu-image fails when calling snap prepare-image with a complaint about opening the model assertion with no such file or directory, but when I run snap prepare-image directly with the same arguments it works?
<mup> Bug #1632886 opened: [Feature Request] Per App Firewall Settings <Snappy:New> <https://launchpad.net/bugs/1632886>
#snappy 2016-10-13
<dholbach> good morning
<ejat> hi, how can i upgrade
<ejat> Name          Date       Version Developer
<ejat> ubuntu-core   2015-08-28 1       ubuntu
<ejat> to the latest?
<ejat> ?
<didrocks> ejat: hey, there is unfortunately no upgrade path between ubuntu core 15.04 and 16, you will need to reinstall
<ejat> on thanks didrocks
<ejat> https://developer.ubuntu.com/en/snappy/start/#snappy-azure <-- how to get the 16.xx to azure .. the same step ?
<nhaines> ejat: you may need to wait until Ubuntu Core is released.
<didrocks> yeah, it's only beta3 for now, we have images for amd64, x86 and pi2
<Quacky2200> Hey, I normally package my application into a deb with the right binaries, as it's a node.js, how could I make sure it downloads a stable release from github and make sure to install the binaries, or should I use the nodejs plugin (it would install the necessary node dependencies right)?
<Quacky2200> If I wanted a snap to pull from GitHub, does it always pull the latest source or the latest release source?
<Son_Goku> zyga, how will this handle more than one different core snap being used on the same system?
<Son_Goku> for example: ubuntu 14 core snap, ubuntu 16 core snap, fedora 24 core snap, centos 7 core snap, opensuse 42.1 core snap, mageia 6 core snap all being used by different snaps
<zyga> Son_Goku: I don't know, let's make this a sprint topic
<Son_Goku> the snap-confine code *look like* it only can handle one core snap
<zyga> Son_Goku: yes, right now only one snap is supported
<zyga> Son_Goku: technically snap-run should probably just tell it wich one to use
<zyga> Son_Goku: but let's discuss the details at the sprint
<Son_Goku> sure
<ejat> ok noted nhaines n didrocks
<popey> is there some way to recover from:-
<popey> popey@localhost:~$ snap list
<popey> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<zyga> popey: check why snapd stopped
<OerHeks> popey, what is the status of snapd.refresh.service ?
<OerHeks> systemctl status snapd.refresh.service >> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592503
<mup> Bug #1592503: "snapd.refresh.service" fails to start on startup <amd64> <apport-bug> <xenial> <Ubuntu GNOME:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1592503>
<popey> hm, will poke at it some more
<popey> thanks
<ogra_> popey, did your board switch channels again ?
<ogra_> (the fw_setenv hack i gave you recently might not be persistent, it doesnt switch the channel, only forces the working ubuntu-core)
<popey> ogra_: dunno, how can i tell?
<ogra_> cat /proc/cmdline
<ogra_> see which core is picked there
<popey> 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=592 bcm2708_fb.fbheight=448 bcm2709.boardrev=0xa02082 bcm2709.serial=0xe377e4ab smsc95xx.macaddr=B8:27:EB:77:E4:AB bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=tty1,115200 elevator=deadline root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=ubuntu-core_424.snap snap_
<ogra_> 424
<ogra_> looks like it switched back to stable again
<popey> :(
<popey> is this install doomed?
<popey> do i need to reflash to get to a known good state?
<ogra_> dunno, you have to ask mvo if/how you can switch back to edge
<popey> tempted to nuke from orbit
<popey> as it seems badly broken
<ogra_> you will need to reflash anyway at some point, there wont be a cross-grade option to go from ubuntu-core to core
<popey> is core now in the unstable images?
<ogra_> this bug is very serious though ... if you can, keep the SD
<popey> so if i grab an image today I'll have the new shiny
<popey> ok, happy to keep it to poke at it
<ogra_> right, it is in the dailies (they ahve some issues though) and in the new beta
<popey> if i go for beta3 (which I think I saw announced yesterday?) will I be on dailys?
<ogra_> you will be a few days behind the daily
<popey> but will it update to daily?
<ogra_> oh, wait, i dont think we released the arm images yet
<ogra_> no
<ogra_> it will only update to the next beta set of snaps
<ogra_> dailies are built with the edge channel, betas with the beta one
<ogra_> (anfd thechnically the board should never ever switch channels on its own :P )
<popey> heh
<zyga> tyhicks: hey
<zyga> tyhicks: I've addressed most of the things you pointed out, I'm just testing the far simplified apparmor profile
<zyga> tyhicks: can you please have a look, I didn't squash or rebase anything
<mup> PR snapd#2139 opened: cmd/snap: tweak unknown command error message <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2139>
<mup> PR snapd#2140 opened: snap: validate and stringify plug/slot attributes early <Created by pedronis> <https://github.com/snapcore/snapd/pull/2140>
<mup> PR snapcraft#866 opened: Bug/1619193 <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/866>
<mup> PR snapd#2131 closed: tests add spread test for prepare-device customizing device init/registration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2131>
<zyga> tyhicks: if you are around I could use a re-review of the media-sharing branch
<popey> ogra_: think I should file a bug for my pi flipping channel?
<ogra_> popey, i the the one you filed is sufficient
<popey> ok
<tyhicks> zyga: hey - I'll take a look
<tyhicks> zyga: I need to take care of a couple other quick things first
<Quacky2200> @thibautr_ @didrocks - I just got your email. I thought I might as well tell you I'm here in case you want to chat rather than email. I'm thinking of just trying to package my snaps similarly to debs with binaries rather than trying to build them separately.
<nothal> Quacky2200: No such command!
<Quacky2200> thibautr_    didrocks - I just got your email. I thought I might as well tell you I'm here in case you want to chat rather than email. I'm thinking of just trying to package my snaps similarly to debs with binaries rather than trying to build them separately.
<didrocks> Quacky2200: oh, excellent! Do not hesitate to ask questions here if you have any :)
<didrocks> (in some meetings right now)
<tyhicks> zyga: looking now
<apol> hi, I'm working on a snapd client. when I call the actions calls (i.e. POST /v2/snap/something) I get a 401 Unauthorized error message. Could anybody point out how should I acquire the privilege?
<mup> PR snapd#2141 opened: overlord/devicestate: don't spam the debug log on classic <Created by chipaca> <https://github.com/snapcore/snapd/pull/2141>
<Quacky2200> @apol is it your own API? You will probably need a token to use the api
<nothal> Quacky2200: No such command!
<apol> Quacky2200: is that a wild guess? it's not my own API, I'm writing a client that talks to the official snapd
<Quacky2200> Well the 401 error means that the client is actually getting a connection and since a 401 means you're unauthorised, then it means you can't use it without authorisation. Typically API's use a token to authorise a user rather than credentials.
<Quacky2200> apol: yes it's a guess...
<apol> yes, I know what a 401 is and I've read the documentation
<apol> I was hoping there would be someone here that knows how it actually works
<Quacky2200> apol: Sorry I can't help more, however, did you use it on something that worked before?
<apol> hm? snap cli client works as long as I use sudo, so I'm guessing we'd need to use policykit and an external process, but I'm not entirely sure
<Quacky2200> Why would policykit send a 401 request, surely policykit would just block the request altogether?
<apol> I'm not using policykit, I'm using the same socket as default
<Quacky2200> Oh sorry, I apologise -_-
<mup> Bug #1633111 opened: Missing API documentation for /v2/snaps/[name] POST <Snappy:New> <https://launchpad.net/bugs/1633111>
<apol> Quacky2200: the answer was in the docs, FYI: Authentication over the unix socket is delegated to UNIX ACLs, and uses SO_PEERCRED to determine privilege levels. In essence this means that a user will be either authenticated or trusted, with the latter restricted to the superuser.
<Quacky2200> apol: Ahh I'm glad you found the answer :)
<mup> PR snapd#2141 closed: overlord/devicestate: don't spam the debug log on classic <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2141>
<tyhicks> zyga: review done!
<oparoz> Hello, 16.10 can't load any snaps, they segfault. Any issue logged yet for that?
<didrocks> not that I know of, maybe open one with some coredumps info if you can?
<oparoz> Thanks didrocks. It's just been reported by a user, so I'll see if he can do that
<didrocks> great! thanks oparoz
<mup> PR snapd#2142 opened: tests: skip auto-mount and auto-import tests on systems without trusted test keys <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2142>
<mup> Bug #1633141 opened: gadget.yaml should specify disk/volume image sizing behavior <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1633141>
<mup> PR snapd#2143 opened: overlord: check that the first installed gadget matches the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2143>
<mup> PR snapd#2144 opened: overlord/snapstate: skip removing the snap on install if it's in the seed dir <Created by chipaca> <https://github.com/snapcore/snapd/pull/2144>
<Croepha> hi, is anyone familiar with an issue where running /snap/bin/ubuntu-image fails when calling snap prepare-image with a complaint about opening the model assertion with no such file or directory, but when I run snap prepare-image directly with the same arguments it works?
<mup> PR snapcraft#867 opened: Handle 'broken' validations that don't match refresh-control <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/867>
<mup> PR snapcraft#868 opened: Parametrize call args for pluginhandler <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/868>
<mup> PR snapd#2144 closed: overlord/snapstate: skip removing the snap on install if it's in the seed dir <Created by chipaca> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2144>
<mup> PR snapd#2142 closed: tests: skip auto-mount and auto-import tests on systems without trusted test keys <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2142>
<zyga> tyhicks: thanks
<zyga> tyhicks: let me know if the explanation I gave makes sense
<tyhicks> zyga: it did, I'm happy with the PR :)
<Croepha> so, if snaps run in a separate filesystem namespace, then accessing the cwd doesn't work reliably right? and is this a known issue? ie. accepted issue?
<kyrofa> Croepha, indeed, the cwd might not be accessible from the snap
<Croepha> kyrofa, gotcha ok thanks, that hung me up for a while couldn't figure out why the ubuntu image command couldn't find my files, newb mistake i guess
<kyrofa> Croepha, I'm not familiar with ubuntu-image yet, but that's not part of the snap's documentation or anything?
<Croepha> kyrofa: this is what I was following
<Croepha> https://github.com/CanonicalLtd/snappy-docs/blob/master/core/images.md
<Croepha> seems to be the most up to date
<kyrofa> Croepha, and you installed it in devmode?
<Croepha> yea
<zyga> Croepha: if that happens we move to /var/lib/snapd/void
<kyrofa> Croepha, you should probably log a bug against snappy-docs, then
<Croepha> so. fyi, to fix, I just bind mounted stuff into my home directory
<Croepha> and used that
<Croepha> that seemed to work across snap commands
<zyga> tyhicks: I just added one more patch
<zyga> tyhicks: I need to review the code later for more cases of this
<zyga> tyhicks: mount -o bind,r?{shared,private,slave} seems to really be different than two separate operations
<zyga> tyhicks: I reviwed the .json files and saw that /etc/alternatives was "shared" (like /media) so I fixed that
<zyga> tyhicks: I'll check the kernel sources and play with more examples when I'm properly awake, just FYI
<tyhicks> zyga: ok, I'm off tomorrow so I won't be able to review
<zyga> tyhicks: wanna see it now? :)
<zyga> (it's short)
<tyhicks> zyga: oh, I thought you had more changes to make
<tyhicks> yeah, I'll look now
<zyga> the .json files now look good (only one shared)
<tyhicks> zyga: have you pushed yet?
<zyga> https://github.com/snapcore/snap-confine/pull/168/commits/a6bedacfc6821c40ec39fa309ec2e5beee737614
<mup> PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168>
<zyga> just now
<zyga> oh, I see a typo there (rslave vs slave)
<zyga> pushed again
<tyhicks> I left the same comment seconds before you pushed :)
<zyga> Thanks, I'll do the rest tomorrow, I'll try to get back to sleep now
<tyhicks> good night
<wililupy> Trying to build an Ubuntu-Core image and I get the following error:
<wililupy> cannot fetch and check prerequisites for the model assertion: account-key
<wililupy> and a key I don't recognize. I'm using the doc in https://github.com/CanonicalLtd/snappy-docs/pull/13
<wililupy> Ahh, figured it out.
<wililupy> How do I delete a registered key in snapcraft?
<niemeyer> jdstrand: Heya
<niemeyer> tyhicks: Heya^2
<jdstrand> niemeyer: hey
<niemeyer> How're things going in snap-confine land?
<tyhicks> hi!
<tyhicks> niemeyer: good as far as I know :)
 * jdstrand too
<niemeyer> tyhicks, jdstrand: Anything pending in terms of reviews for media sharing, etc?
<tyhicks> niemeyer: I've reviewed everything that zyga has pushed and it has my ack
<tyhicks> niemeyer: he spotted something a little odd in the json files for the test and he's going to take a look at that tomorrow
<tyhicks> niemeyer: but I think it is just about ready to be merged
<niemeyer> \o/
<niemeyer> tyhicks: Great to hear!
<niemeyer> This one had me worried for a little while
<tyhicks> niemeyer: it is great news but I have to say that zyga deserves the biggest pat on the back
<tyhicks> yeah, that was some complex stuff
<niemeyer> tyhicks: Yeah, he did a great job there
<niemeyer> despite the bad timing
 * tyhicks nods
<jdstrand> yeah, that was pretty crazy
<jdstrand> it happily fixed an issue in mountinfo along the way
<zyga>  hmm?
<zyga> which issue?
<zyga> (yeah, I cannot get back to sleep again)
<jdstrand> the docker workaround
<zyga> damn week is so messed up ;)
<zyga> ah
<zyga> yes, I know what you are talking about now
<qengho> :w
<qengho> Gah.
<kyrofa> qengho, that's a gnarly mustache
<zyga> all I see is a duck face
<zyga> kyrofa: how's your jetlag?
<kyrofa> zyga, killer man. I got some weird stomach bug, too
<zyga> kyrofa: for real? here you have to go to a market to buy those
<kyrofa> zyga, hahaha
<zyga> kyrofa: I'm sorry, hope you get better soon
<kyrofa> zyga, thanks, yesterday was dreadful but I seem to be on the mend today
<Quacky2200> I don't mind yet lag or being ill too much as to the continue of coughing to extremism, the repetitive dreams or vertigo
<zyga> I did a loop on the bus here today, the outside of town is totally different, I'm going to see if I can get somewhere far tomorrow and snap some photos
<kyrofa> zyga, yeah, try to get out in the country a bit! Go eat in a small town
<zyga> kyrofa: I feel like I do every day
<kyrofa> zyga, I felt like I barely saw the sky there :P
<zyga> kyrofa: this place is different, it's the old part of the city, I live within the city walls :)
<zyga> kyrofa: I wish I had two weeks here
<blackboxsw> Question out of left field for folks. If I continue to release snaps the the stable channel, they are not automatically updated are they? From the docs it looks like the user would have to perform a snap refresh <mysnap>  http://snapcraft.io/docs/core/updates
<qengho> blackboxsw: That's a great question. Users get updates automatically from whatever channel they got the package from last time.
<qengho> blackboxsw: snapd has a scheduler. I don't know the delay, but on average, a could of hours after your upload.
<qengho> blackboxsw: make sure it's marked "published" in the store.
<blackboxsw> qengho, thanks so much for clarification
<blackboxsw> qengho, were there other docs I should have looked at to glean that information? http://snapcraft.io/docs/core/update seems to mention the transactional refresh, but I didn't see mention of snapd here
<qengho> blackboxsw: it feels a little weird to me that it's automatic, so I could be wrong in suggesting it's always like that.
<blackboxsw> from http://snapcraft.io/docs/core/snapd I see "A store where developers can easily make their software directly available to users and from which devices can automatically pull updates on a daily basis."
<qengho> blackboxsw: the code that implements that is so new that it could be the web site hasn't synch'ed up with reality.
<blackboxsw> +1 qengho
<qengho> blackboxsw: https://github.com/snapcore/snapd/blob/98c8e937625ce3134cf17025d8f0eb3e1016259a/docs/autoupdate.md
<blackboxsw> excellent reference thanks qengho
<qengho> blackboxsw: Welcome. Make something awesome!
<blackboxsw> count on it ;)
<wililupy> is the gadget snap for amd64 still called pc?
<wililupy> Does anyone have an example assertion for building a vanilla ubuntu-core image? The one I used a month ago no longer works, and I am not trying to build on Pi, so the one in the documentation doesn't serve me too well.........
<wililupy> I am using "gadget": "pc" and it is failing right after it says fetching pc
#snappy 2016-10-14
<mup> Bug #1571497 changed: snapd crashes on slot disconnection <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1571497>
<mup> Bug #1628592 changed: no camera slot in pi2 or pi3 image <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1628592>
<guy_davis> Hiya, anyone installed dockerd on snap core 16 beta?  Looking to evaluate Ubuntu Snappy as a minimal OS for hosting docker containers.
<mup> Bug #1633289 opened: network-observe plug is not working for dracnmap snap <Snappy:New> <https://launchpad.net/bugs/1633289>
<dholbach> good morning
<ejat> morning
<mardy> how can I specify which Ubuntu release should be used by "stage-packages" and "build-packages"?
<vicamo> hi there, do any one know where to send a merge proposal for ubuntu snap-confine package?
<vicamo> would like to propose a change to enable running snappy on Ubuntu M10
<Rick_> Hello
<Rick_> Does someone know the solution of No ssh keys found, at creating user profile setup
<mup> PR snapd#2145 opened: cmd/snap: update remove command help <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2145>
<ogra_> mardy, i dont think you can (by default it uses the hosts sources.list ...)
<mardy> ogra_: OK. It would be nice if there was a way to specify that in snapcraft.yaml, so that one would know in which release a certain snap was built
<ogra_> mardy, well, for now you can put it in the description or so
<mardy> yep
<ogra_> long term -> file a whishlist bug ;)
<ogra_> though since you dont really need to use any debs i'*m not sure it is an option thats wanted by default
<ogra_> (you can make your snapcraft.yaml complex and build all deps for source for example ... i.e. you wouldnt need to use any debs if you like)
<zyga> vicamo: hey
<zyga> vicamo: I'm the maintainer of snap-confine, please send me a pull request on github
<zyga> vicamo: can you tell me more about what you were working on?
<vicamo> zyga: I have to modify the apparmor rules for ubuntu for snap-confine package
<vicamo> I guess that's not for the rest of the world?
<zyga> vicamo: can you tell me more about what you need to modify and why?
<vicamo> zyga: it's an open bug in https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1633367
<mup> Bug #1633367: missing ptrace options needed by snap-confine <snappy> <systemd> <Canonical System Image:New> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1633367>
 * zyga looks
<zyga> vicamo: can you tell me which kernel version are you using on m10
<vicamo> zyga: a pretty outdated 3.10
<ogra_> could be worse ... could be 2.18 :P
<zyga> vicamo: does it include the patched apparmor stack?
<vicamo> zyga: yes, it has, but again, outdated 3.1 or so
<zyga> vicamo: I mean the updated patch for 3.10 kernels?
<zyga> vicamo: one sec
<zyga> vicamo: https://github.com/snapcore/sample-kernels
<mup> PR snapcraft#869 opened: Bring docs/upload-your-snap.md in line with http://snapcraft.io/docs/â¦ <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/869>
<zyga> vicamo: in any case, please fork snap-cofnine and open a pull request
<zyga> vicamo: the code is on github.com/snapcore/snap-confine
<zyga> vicamo: I'll work with jamie to review it
<zyga> vicamo: and be sure to try current master
<vicamo> zyga: that sameple kernel has a 3.10 tree, but its apparmor part is not up-to-date, either
<zyga> vicamo: a large change just landed
<zyga> vicamo: ah, I see, I wasn't aware of that
<Rick_> At the first boot of snappy core, at the login/registration, where i must fill in my email, it is saying that there are no ssh keys found and that my account could not be breate
<Rick_> created
<zyga> Rick_: your keys are taken from your launchpad.net account
<Rick_> Could someone help me?
<vicamo> I've also checked the rest of snap-confine code base on github, I need to land a change in the apparmor rules, not snap-confine itself
<zyga> vicamo: that is in src/snap-confine.apparmor.in
<Rick_> Zyga: Thank you!
<vicamo> zyga: ah!
<Rick_> Zyga: How can i get my keys?
<Rick_> I created my account, and tried it again, but the same error, the account could not be created, no ssh keys found
<Rick_> Aah, i must register a key, using launchpad.net i saw, gonna try i
<Rick_> *it
<Brad__> join
<Brad__>  hello
<Brad__> Anyone creating snaps?
<Brad__> Anyone here?
<ogra_> only 302 people
<Brad__> Oh !
<davmor2> ogra_: I'm not I'm breaking them :P
<ogra_> heh, true :)
<Brad__> That's about as far as i have got, too
<ogra_> thats a good start ;)
<zyga> Rick_: look at your launchpad profile, there's a SSH section there
<Rick_> Thanks Zyga, i followed the instructions and it is working. :) Jeahh Thankss, This awnser was the only one i could find
<zyga> Rick_: I'm glad to hear that :)
<vicamo> zyga: https://github.com/snapcore/snap-confine/pull/170 pr ready, but it seems CI is currently broken?
<mup> PR snap-confine#170: Add apparmor ptrace options for snap-confine <Created by vicamo> <https://github.com/snapcore/snap-confine/pull/170>
<Brad__> Can anyone help me create a basic calculator, chat or notepad snap? I tried the yaml on github but it says an error msg. Do i need to install packages? Has anyone got some yaml code which will work?
<Brad__> bump
<Brad__> only 302 people
<ogra_> !patience
<ubottu> Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com or http://ubuntuforums.org or http://askubuntu.com/
<ogra_> ;)
<Brad__> oh, thank :)
<ogra_> it might be helpful if you pasted the error you get on paste.ubuntu.com and give the pastebin url so people can look at it
<Brad__> okay, great!
<Brad__> http://paste.ubuntu.com/23322759/
<ogra_> Brad__, so you are using a PPA that has no xenial packages it seems
<Brad__> okay -do you know how i can the xenial packages? Or exclude the PPA?
<ogra_> snapcraft uses your hosts apt sources ... disable it on your PC and snapcraft wont try to use it
<ogra_> (alternatively call "snapcraft cleanbuild" that will build inside a container and not use the info from the host machine)
<Brad__> okay, thanks so much. do you know how i can disable it? :)
<ogra_> well, how did you enable it ... ? :)
<ogra_> you obviously set it up once ... to install ubuntu-tweak i guess
<Brad__> oh, :/ :)
<ogra_> just go to your software sources in the settings and turn it off there
<Brad__> great. thank you.
<mup> PR snapd#2146 opened: asserts: remove serial-proof type <Created by emgee> <https://github.com/snapcore/snapd/pull/2146>
<mectors> sudo snap create-user --sudoer --json tadhackuser@gmail.com
<mectors> error: while creating user: cannot create user: device already managed
<mectors> ???
<mectors> Why can I not add another user to Ubuntu Core 16
<mectors> found it. You have to logout
<mattyw> hey folks, which repository should snap be coming from on trusty?
<mattyw> (snapd that is)
<mup> PR snapd#2147 opened: asserts: validate optional account username <Created by emgee> <https://github.com/snapcore/snapd/pull/2147>
<zyga> mattyw: eventually the same one
<zyga> mattyw: the trusty archive
<mattyw> zyga, I was expecting to just be able to do apt-get install snapd, but it can't be found
<joc_> zyga: hi, if you are happy with the comments from jamie could you merge my PR in to your branch https://github.com/zyga/snapd/pull/2
<mup> PR zyga/snapd#2: Make sure gpio exported before apparmor setup <Created by jocave> <https://github.com/zyga/snapd/pull/2>
<zyga> mattyw: It's not available yet
<mup> Bug #1632453 changed: snapd won't start on dragonboard <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1632453>
<zyga> joc_: I'll check that out next week, I'm on holidays, in theory, this week
<mup> PR snapd#2146 closed: asserts: remove unused serial-proof type <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2146>
<zyga> joc_: (but hey, /media support landed today)
<joc_> zyga: ok that's fine, lets see if we can get it resolved next week
<zyga> joc_: we'll work on the release next week
<zyga> joc_: face to face will be faster
<joc_> +1 :)
<zyga> (hopefully over beer at the bar)
<mattyw> zyga, ok thanks
<mattyw> zyga, is there a ppa it can be got from though?
<liuxg> ogra_, now I am removing a snap, but it shows me "2016-10-14T11:54:33Z ERROR cannot remove snap file "lights", will retry in 3 mins: umount: /snap/lights/x1: not mounted". what shall I do next? I just want to remove the app.
<ogra_> well, why is the snap not mounted ?
<ogra_> did you manually unmount it ?
<liuxg> ogra_, it was mounted yesterday. today, I want to install a new version. Before that, I wanted to remove it first.
<liuxg> ogra_, No, I did not do that.
<liuxg> ogra_, using snap list, it shows "lights                            x1              devmode,disabled,broken"
<ogra_> well, it looks like you tinkered with it manually somehow
<liuxg> ogra_, frankly, I did not do that.
<ogra_> check snap changes and take a look at the offending change there with "snap change <number>"
<liuxg> ogra_, I quit the command by Ctrl+c. then http://paste.ubuntu.com/23323101/
<ogra_> well, obviously take a look at 92
<liuxg> ogra_, what can I look at?
<ogra_> the details of that change
<liuxg> ogra_, in the step, it just happened like the message I showed you.
<liuxg> ogra_, where can I find the detail of the changeï¼
<ogra_> <ogra_> check snap changes and take a look at the offending change there with "snap change <number>"
<liuxg> ogra_, http://paste.ubuntu.com/23323114/
<ogra_> Error   2016-10-14T11:51:46Z  2016-10-14T11:54:24Z  Remove security profile for snap "lights" (x1)
<ogra_> now, no idea why that fails
<ogra_> probably ask someone from the snapd team or security how o debug this further
<ogra_> *how to
<ogra_> (and file a bug if you are sure you havent manually tinkered with the snap in any way)
<liuxg> ogra_, it is ok. thanks. Have a good night! I really do not know how to debug this kind of issue.
<ogra_> that is why i point you to people that do know :)
<ogra_> (i dont either and for me it is also still early afternoon btw ;) )
<liuxg> ogra_, many thanks. it is a night here :) I may find someone to help out.
<ogra_> perhaps zyga has an idea (seems mvo is off today)
<didrocks> even if there has been some manual tinkering, it's a good use case to make snapd reliable against that and recover its state from it :)
<didrocks> like not being mounted sounds like the code isn't there anymore, and it's safe to proceed
<ogra_> yes, which is why i suggested to file a bug :)
<didrocks> yep!
<kgunn> cjwatson: if you're about, i have a particular snap build failure that seems "sticky" to a particular project
<kgunn> https://launchpadlibrarian.net/289526453/buildlog_snap_ubuntu_xenial_amd64_miral-snap_BUILDING.txt.gz
<kgunn> i mean i can build that locally & the error is a unknown to me...wondering if you could take a look and give me your $0.02
<ogra_> kgunn, try adding the ubuntu image build PPA to your snap build
<ogra_> we have a fixed bzr
<ogra_> or enable proposed, the fix is there as well, but not yet landed
<kgunn> ogra_: ah thanks!
<kgunn> ogra_: so just proposed instead of "updates"
<ogra_> bug 1606203
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <verification-needed> <Bazaar:Fix Committed by vila> <Snapcraft:Invalid by sergiusens> <bzr (Ubuntu):Fix
<mup> Released> <bzr (Ubuntu Xenial):Fix Committed by cjwatson> <https://launchpad.net/bugs/1606203>
<ogra_> kgunn, yeah
<kgunn> ta
<cjwatson> oh, I've been meaning to verify that
<cjwatson> kgunn: hey, if you enable proposed and it works, could you do me a favour and replace the verification-needed tag on that bug with verification-done?
<kgunn> happy to
<cjwatson> 'cos that was basically what I was going to test
<cjwatson> and definitely use proposed rather than the PPA, that way it's a valid test for SRU verification purposes
<kgunn> cjwatson: ah, same error...but wonder, is it b/c i'm targeting xenial?
<kgunn> https://code.launchpad.net/~kgunn72/+snap/miral-snap/+build/6938
<niemeyer> jdstrand: ping
<cjwatson> kgunn: you didn't enable -proposed there
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Yo, good morning
<niemeyer> jdstrand: How're things going in snap-declaration land?
<cjwatson> kgunn: and, well, yes it's because you're building from xenial, but the proper fix for that isn't to build from some other series, it's for us to get this fix verified :)
<cjwatson> kgunn: huh.  you did *try* to enable -proposed.  but no mention of it in the build log ...
<cjwatson> that's weird
<jdstrand> niemeyer: I have checks against the base declaration working, except for alternations. after that, will add the bits for when the store gives the payload
<kgunn> cjwatson: lemme know if you want me to try something else
<jdstrand> niemeyer: so the review tools are pretty close. it took longer than I expected but it should be solid
<cjwatson> kgunn: let me scratch my head about this for a bit first
<kgunn> you bet
<jdstrand> niemeyer: I don't know the status on the store side
<niemeyer> jdstrand: As we discussed earlier in the week, the main concern at this point is the snap-declaration text itself
<niemeyer> jdstrand: We need the text ready so that we can take out the hardcoded logic
<niemeyer> jdstrand: We can import the initial declarations by hand if necessary
<niemeyer> jdstrand: But we need them there so that we can update and release snapd
<jdstrand> niemeyer: yes. my understanding was that the store guys were going to put that in the store db
<niemeyer> jdstrand: Right, but do we have "that"? :)
<jdstrand> roadmr: can you comment on that work ^
<niemeyer> jdstrand: The question is really the snap-declaration body for the constraints
<roadmr> jdstrand: sure, give me a bit as I'm OTP
 * jdstrand nods
<niemeyer> jdstrand: We're in touch with matiasb as well, who's working on the feature and aware of these ideas
<jdstrand> I see
<niemeyer> jdstrand: So the main thing I'm bothering you about (sorry!) is the final/real text for the base and the individual snaps that allows us taking out the hardcoded logic.. with that in hands we can land the declarations and update snapd
<cjwatson> kgunn: ah, this is because you're building against a PPA and they have confusingly different rules
<matiasb> jdstrand, fyi, from the store UI it is already possible as reviewer to push update plugs/slots for a snap declaration
<cjwatson> ogra_: did you have a snap that builds only from the primary archive where you could test the bzr fix in -proposed?
<jdstrand> matiasb: ok. so, for example, I can handcraft the payload for lxd, and the store will regenerate the snap declaration for snapd to consume?
<ogra_> cjwatson, hmm, not really ... all my snaps that need bzr actually also need to use the PPA for other bits
<matiasb> jdstrand, exactly
<jdstrand> ok cool
<jdstrand> niemeyer: so, since that is done ^ shall I transition to making the change to the base declaration in snapd? I need that anyway and I also worked through that a bit yesterday, so it should be quick
<jdstrand> quickish
<niemeyer> jdstrand: Yeah, that plus the few special allowances we have would be great to have ready, thank you!
<jdstrand> it's possible I might need some help with the testsuite, but I'll know more when I get in there
<jdstrand> ok, I'll move to that
<roadmr> jdstrand: finally of the phone, but yeah, what matiasb said, the store is already spitting out snap-declaration with plugs/slots which can be edited by reviewers. Plus it gets a small amount of validation against the most basic shot-in-the-foot scenarios
<jdstrand> roadmr: ack. I made several commits to the review tools. I need to pivot to snapd now, but the tools should be ready for a pull pretty soon after I finish with snapd
<roadmr> jdstrand: awesome! we can push that to the store when available, and there's a switch we can flip if things misbehave, so at least we'd call the tools "the old way" (no slots/plugs for preapproval). Recall we'll be sprinting next week so that may affect response times a bit
<jdstrand> I definitely remember we'll be sprinting next week :)
<cjwatson> ogra_: all right, let me see if I can hack something up
<ogra_> i can surel dpo something like that too, but a nnit later today if you dont get to it
<roadmr> jdstrand: hehe :)
<ogra_> *but a bit
<cjwatson> ogra_,kgunn: OK, verified now, I expect it'll be released on Monday (no SRU releases on Friday, normally)
<mup> PR snapd#2140 closed: asserts,snap: validate attributes to a JSON-compatible type subset <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2140>
<mup> PR snapd#2138 closed: many: removed frameworks target, and some leftover frameworks helpersâ¦ <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2138>
<mup> PR snapd#2145 closed: cmd/snap: update remove command help <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2145>
<mup> PR snapd#2107 closed: client,daemon,cmd: add payment-declined error kind <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2107>
<mup> PR snapd#2139 closed: cmd/snap: tweak unknown command error message <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2139>
<kgunn> ogra_: hey what was the ppa containing the fix for this lp issue?
<abeato> jdstrand, ofono PR refreshed after changing the comment. Spread tests are failing but it looks unrelated to the PR
<abeato> "cannot bind mount /snap/core/current//var/lib/console-conf -> /var/lib/console-conf with flags 0x85007. errmsg: Permission denied"
<Croepha> Hi
<Croepha> So, using current version of snapcraft using kernel plugin is most current way to make a kernel snap for core 16 right?
<kyrofa> Croepha, yep
<ogra_> kgunn, https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<Croepha> and by current version i mean the version that ubuntu desktop 16.04 sais is stable?
<Croepha> says
<Croepha> kyrofa: ok thanks :)
<jdstrand> pedronis: hey, so I have an updated base declaration, but all the snowflake handling in the testsuite is taking me a bit to sort through
<pedronis> jdstrand: we need a bit to coordinate
<pedronis> jdstrand: do you want to push something for me to look at?
<pedronis> jdstrand: also are now all interfaces mentioned at least once in slots or plugs?
<jdstrand> let me push something
<jdstrand> pedronis: https://github.com/jdstrand/snapd/tree/finish-decl-based-checks
<pedronis> jdstrand: so basically need to work to make test pass again?
<jdstrand> pedronis: that and then to remove the hardcoded stuff for lxd, docker, etc, and then to make pass again.
<jdstrand> pedronis: I saw a snowflake for snapd-control too
<pedronis> yes
<pedronis> we didn't block it
<pedronis> anyway before this can land
<pedronis> we need all the matching decl in the store
<jdstrand> oh, it is deny-auto-connection: false still in the base declaration
<jdstrand> so that is stilla  snowflake
<jdstrand> pedronis: should I change that now?
<pedronis> jdstrand: I think the idea is to change everything
<pedronis> but we need the decls
<pedronis> that one is snapweb?
<jdstrand> I can supposedly add the decls
<pedronis> and IÂ don't know what else
<pedronis> jdstrand: maybe matiasb can also help telling how to search things that use some of those plugs
<matiasb> pedronis, jdstrand, we should be able to search CPI for plugs/slots, at least for plugs/slots declared in the yaml (I think, maybe cprov can confirm?)
<cprov> matiasb: I am not sure it's working, we never finished that implementation.
<matiasb> ah, ok, I can try and take a look to confirm
<jdstrand> pedronis: ok, I updated snapd-control to not auto-connect but the testsuite doesn't show there is an error there, which I expected it would
<jdstrand> pedronis: (I made the change in the base decl)
<Elleo> is there some way to make URL opening work from snappy apps? I'm currently trying to snap up podbird, but external links using Qt.openUrlExternally() just result in things like "Unable to detect a web browser to launch 'http://community.ubuntu.com/contribute/translations'"
<jdstrand> matiasb, cprov: I was told I would be able to add plugs and slots via the web form now. is that the case?
<pedronis> jdstrand: that sound strange, wrong syntax, I see the test that should fail
<ogra_> Elleo, try adding /usr/local/bin to your PATH ...
<ogra_> Elleo, inside yor snap that is
<Elleo> ogra_: okay, thanks
<ogra_> which reminds me ... jdstrand was there any conclusion about the /usr/local/bin stuff inside the core snap yet ?
<matiasb> jdstrand, correct, when reviewing a snap revision, you should now have an interfaces section with a link to the form to update the snap declaration
<pedronis> jdstrand: I need to have dinner, back in a bit
<jdstrand> matiasb: is that something I can do without an upload? ie, I go find lxd, then add the necessary plugs/slots and then it is done, or does it have to be tied to an upload?
<cprov> matiasb: https://search.apps.ubuntu.com/docs/#slots, not exactly a direct filter, more like 'given the provided slots, omit incompatible plugs' ...
<jdstrand> cprov: I barely remember the context for that. I think I mentioned it to mvo and he agreed it needed to be fixed
<jdstrand> err
<jdstrand> cprov: nm
<jdstrand> ogra_: ^
<ogra_> jdstrand, ah, well ... thats about teh xdg-open hack we ship (but also a fake "apt" that just echost "please use snap" )
<ogra_> i guess a topic for next week then
<matiasb> jdstrand, not tied to an upload, you can update the declaration at any time; link available there atm because it is expected that you may need to update a decl if review indicates so
<cprov> jdstrand: It's definitely not useful atm and it's not even supported for snap-specific searches (v1/snaps/search), we should not count on this.
<cprov> matiasb: ^
<matiasb> jdstrand, you can try with this search: https://search.apps.ubuntu.com/api/v1/snaps/search?fields=name,plugs,slots (4 pages)
<matiasb> jdstrand, that will return all snap pakages, and their indexed values for plugs/slots, I guess that should help
<jdstrand> matiasb: in this url: https://search.apps.ubuntu.com/api/v1/package/Oulq6jI8qkI4ScWVafl3VsxSsd52HSGu is Oulq6jI8qkI4ScWVafl3VsxSsd52HSGu the snap id?
<jdstrand> matiasb: also, that page is incomplete
<jdstrand> but that's ok
<jdstrand> today, all slots implementations are flagged for manual review by the store
<jdstrand> actually, that's not true
<jdstrand> I need everything
<cprov> jdstrand: try this https://pastebin.canonical.com/168034/
<cprov> for overview purposes
<jdstrand> cprov: that's incomplete. for example, locationd is not listed: https://myapps.developer.ubuntu.com/dev/click-apps/5666
<cprov> jdstrand: it's not published on stable channel
<jdstrand> cprov: what is the query for alls snaps and all channels?
<cprov> jdstrand: unfortunately not, search was designed to operate on stable only.
<jdstrand> docker isn't either
<jdstrand> I guess I'll just have to go with what I know is implementing the slot side and using the plugs
<jdstrand> matiasb: I'm looking at the web form. do I need to add 'slots:' to the slots textarea or will it add it for me?
 * jdstrand tries on a test snap
<cprov> jdstrand: Snap admin/overview APIs are non-existent at moment and we are starting to miss them.
<jdstrand> hmm
<jdstrand> matiasb: if I add this to slots: {"bluez": {"allow-connection": {"plug-publisher-id": [".*"]}}}
<jdstrand> matiasb: I get "could not sign assertion (cannot assemble assertion snap-declaration: plug-publisher-id in allow-connection in slot rule for interface "bluez" contains an invalid element: ".*")"
<jdstrand> I can use something else, but that seems like a bug
<matiasb> jdstrand, that's an error from SAS... pedronis, fyi ^
<jdstrand> {"bluez": {"allow-connection": {"plug-snap-type": ["app"]}}} worked
<pedronis> jdstrand: regexps are not supported in id lists
<pedronis> (they are not in the spec as far as IÂ know)
<jdstrand> I thought they were supported anywhere a string is
<jdstrand> anyway, no matter for now, I can do a different thing
<pedronis> jdstrand: no
<pedronis> jdstrand:  Plug and slot attributes are specified with the following syntax
<pedronis> and the it mentions regexps
<jdstrand> pedronis: so, I can add the snap declarations to the store. and I can pull out the lxd, docker, etc hard coded things. I think I'll need help with getting the testsuite working properly though
<pedronis> jdstrand: understood
<jdstrand> pedronis: I also don't know how to 'turn it on' per se. iiuc, the base declaration changes are what do that. is it enough for me to compile a snapd with my base decl change, then try to install something from the store and see that it fails, then adjust the snap decl in the store and see that it works?
<pedronis> jdstrand: yes
<jdstrand> ok, let me try that
<pedronis> we still want to cover with the unit tests
<jdstrand> of course
<pedronis> but yes, to try for real we need that
<jdstrand> I'm not sure how to fake a snap declaration in the testsuite
<jdstrand> iirc, we were testing primarily against the base decl, not a snap decl
<pedronis> jdstrand: no we already did a bit of that, see the test for LXD
<pedronis> and mockSnapDecl
<pedronis> you can pass in plugs and slots stanzas
<pedronis> (not used yet but supported by that)
<jdstrand> pedronis: ok, so I'm still not clear on who is doing what
<pedronis> jdstrand: well it makes for you to fill in as much snap decl as possible, and then to push the branch as far as possible but reasonable and then IÂ pick up from there
<pedronis> jdstrand: I have another couple of things to finish/start first so I cannot simply jump on that right now
<jdstrand> ok. I think I see what I need to do with lxd. let's see how far I get
<jdstrand> pedronis: fyi, https://github.com/snapcore/snapd/commit/173152497e8e3e9d1966982ca4cd875376d94590 - I expected the second test to fail
<pedronis> jdstrand: why is the first one also passing, with IsNil?
<pedronis> jdstrand: I agree, I need to try and debug
<jdstrand> pedronis: well, on the first one I was trying to create a snap decl that would allow the lxd snap to auto connect
<jdstrand> pedronis: did I not do it right?
<pedronis> jdstrand: I really need to grab your branch and play a sec
<pedronis> jdstrand: let me try
<pedronis> jdstrand: you have lxd-support on both slots and plugs side of the base decl for example, remember only one side of those is used
<jdstrand> pedronis: oh, the very first one shouldn't pass, you are right. I had IsNil, I meant to have NotNil
<jdstrand> TestAutoConnectionLxdSupport
<jdstrand> cand := s.connectCand(c, "lxd-support", "", "") <- should fail
<pedronis> yea
<pedronis> but passes
<pedronis> because of what IÂ mentioned
<jdstrand> lxdDecl := s.mockSnapDecl(c, "lxd", "J60k4JY0HppjwOjW8dZdYc8obXKxujRu", "canonical", plugsSlots) <- should pass
<jdstrand> oh
<jdstrand> hmm
<jdstrand> ok, that explains snapd-control too
<pedronis> jdstrand: it's the rule we wrote down
<pedronis> not let me try to understand the other one
<pedronis> now
<jdstrand> pedronis: remind me why only one side?
<pedronis> jdstrand: you decided that
<pedronis> or you mean technically?
<jdstrand> I don't recall deciding that... maybe I was thinking of something else
<jdstrand> anyway, let me see if I can make it work with the current implementation
<pedronis> jdstrand:  # - the final decision is taken by evaluating the opinion of the snap plug,
<pedronis> #   then the snap slot, then the base plug, and finally the base slot, in that
<pedronis> #   order. The first of those that define any rule about the circumstance is
<pedronis> #   taken as the final decision. No merging is performe
<pedronis> d
<jdstrand> the no merging I was thinking was between the snap and base declarations
<jdstrand> but I see in the plugs side there is no auto-connection, so it goes through
<pedronis> jdstrand: well, you also reviewed the code
<jdstrand> man, this is tricky to get the base declaration correct
<pedronis> it sort of means
<pedronis> you can only use one side for most stuff
<pedronis> or it gets delicate
<jdstrand> indeed
<jdstrand> that is the sort of thing that was hard to see until stuff was implemented and tried to be put into use
<jdstrand> anyway, working through it
<pedronis> I don't expect doing merge
<pedronis> to make the life easier for the code
<pedronis> so probably it wouldn't be easy to understand
<pedronis> what happens
<pedronis> though it my DWIM
<jdstrand> I'm not suggesting we change it. I'm only saying that it makes defining the base declaration tricky and I have to work through some of the corner cases
<pedronis> jdstrand: yea, that's why being to write tests reasonably is good
<pedronis> being able
<jdstrand> hrm
<pedronis> jdstrand: about there other test is not picking up the slots declaration, trying to see why
<jdstrand> I'm not sure this is going to work right for super-privileged interfaces. maybe I need to rethink what that means
<jdstrand> cause it makes no sense to use 'plugs' for a plugging snap cause you can't specify the plug-snap-id on the plugs side
<pedronis> well if you are in snap
<pedronis> it doesn't make sense to limit by snap-id
<pedronis> you just say
<pedronis> yes
<jdstrand> pedronis: I'm trying to be able to say "only the lxd snap may use lxd-support'
<pedronis> jdstrand: you can say it on lxd snap
<pedronis> though
<pedronis> anyway still working through your other failing test
<jdstrand> if I use deny-connection: true in the slots side of the base declaration, what does that mean for an implicit slot?
<pedronis> ?
<pedronis> it means nothing can connect
<pedronis> (that's not specific to implicit though)
<pedronis> but you can override in the snap plug rule
<jdstrand> pedronis: ok, let me put it this way: can you show me a base decl for implicit slot 'foo' that should be denied to everyone. and then a snap decl for a snap that plugs: [foo] that allows it?
<pedronis> base-decl:
<pedronis>    slots:
<jdstrand> (denied to everyone on the plugs side that is)
<pedronis>    foo:
<pedronis>    deny-connection: true
<pedronis> snap-decl
<pedronis> plugs:
<pedronis>    foo:
<pedronis>    allow-connection: true
<pedronis> ?
<jdstrand> right, that is what I was planning to do, but what does that mean on the slots side for an implicit slot?
<pedronis> sorry
<pedronis> I'm not parsing that sentence
<jdstrand> ie, will the core snap not connect?
<pedronis> connect to what?
<jdstrand> there are two side of a connection
<jdstrand> a slot and a plug
<pedronis> jdstrand: we discussed this
<pedronis> jdstrand: this checks happen at higher level
<pedronis> so the implicit side does whatever
<pedronis> it does
<pedronis> that's about installation
<pedronis> I imagine
<pedronis> jdstrand: we don't check these rules
<jdstrand> so you are saying I should ignore the fact that an interface is implicit?
<pedronis> until we are giving two sides
<pedronis> s/giving/given/
<jdstrand> and an implicit slot only has one side in the code?
<pedronis> I don't know
<jdstrand> right, me either
<jdstrand> which was why I was trying to be careful here
<pedronis> I suspect is lower level than this
<pedronis> IÂ haven't seen anything that connect those as things
<jdstrand> let me just try to work through it the way we were thinking (slot only in base decl and plug snap decl override)
<pedronis> I suspect the implicit stuff is written when you have connections
<pedronis> but is not a connection
<pedronis> or something like that
<jdstrand> also, what does this mean:
<jdstrand> base decl:
<jdstrand> slots:
<jdstrand>   foo:
<jdstrand>     allow-installation: false
<jdstrand> within the context of an implicit slot
<pedronis> probabbly means you cannot refresh the snap os
<jdstrand> right
<jdstrand> that isn't great :)
<jdstrand> which is why I had:
<jdstrand> plugs:
<pedronis> installation rules
<pedronis> should mostly be about
<jdstrand>   lxd-support:
<pedronis> snap-type
<jdstrand>     allow-installation: false
<pedronis> or be on the plugs side
<jdstrand> but that doesn't work
<pedronis> why?
<jdstrand> I mean, it would work, but then I have both sides in the base decl
<pedronis> that's ok
<pedronis> as long they are not about the same kind of rule
<pedronis> we can add a sanity check test about that sort of stuff
<pedronis> installation rules vs connection vs auto-connection
<pedronis> are orthogonal
<pedronis> that order for each
<jdstrand> the allow-installation rules are weird though in that the snap id isn't in there
<pedronis> is not about any rules in general
<pedronis> s/that order/that order is/
<jdstrand> I would have to do in the snap decl
<jdstrand> plugs:
<jdstrand>   lxd-support:
<jdstrand>     allow-installation: true
<pedronis> yes
<jdstrand> I guess that is good enough
<jdstrand> cause the snap id is up above
<pedronis> yes
<jdstrand> ok
<pedronis> I honestly  hope/expect
<pedronis> most snap level
<pedronis> rule to be simple turn on
<pedronis> something denied in general
<pedronis> but allowed for this one
<pedronis> snap
<pedronis> jdstrand: ok, I find out the issue with your tests as it is
<pedronis> jdstrand: you are using  slot rules on the plug side
<pedronis> even the passing test is wrong
<jdstrand> pedronis: I'm reworking this base on our conversation
<pedronis> jdstrand: anyway let me show you the diff so we are on the same page
<pedronis> jdstrand: http://pastebin.ubuntu.com/23324868/
<pedronis> s/docker-support/lxd-support/
<pedronis> and lxdDecl goes into the cand.SlotSnapDeclaration side
<jdstrand> oh, haha
<pedronis> it's lxd is offers the slot
<pedronis> we check slot rules only on the slot snap
<jdstrand> lxd-support is an implicit slot
<pedronis> and plug rules only on the plug snap
<pedronis> ah ok
<pedronis> then the test is a bit non-sensical
<pedronis> but anyway we discussed
<pedronis> this stuff
<jdstrand> let me work through it
<pedronis> ok
<pedronis> but the infra seems to do the right things
<pedronis> but positive tests are delicate
<pedronis> (given that allow is the default)
<jdstrand> we also discussed it weeks ago. putting it into practice with the nuances that are there is tricky
 * jdstrand is working through it
<pedronis> jdstrand: I understand, just saying not seeing a bug yet
<mup> PR snapd#2148 opened: many: introduce an assertion format iteration concept, refuse to add unsupported assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2148>
<barry> hi all; i'm wondering if the python plugin for snapcraft has changed has changed recently.  my snapcraft.yaml that used to build ubuntu-image now does't get all the stage-packages installed correctly: https://github.com/CanonicalLtd/ubuntu-image/blob/master/snapcraft.yaml
<barry> it worked fine for 0.7ubuntu1 (2016-10-06)
<barry> but now it can't import 'attrs'
<sergiusens> barry define recently
<barry> sergiusens: as of oct 6
<sergiusens> barry the deb, right? Then the answer is no https://launchpad.net/ubuntu/+source/snapcraft
<sergiusens> unless you updated much after that
<barry> sergiusens: interesting.  i'm fairly sure i would have picked that one up
<sergiusens> barry we run an extra `pip wheel` since then and do an explicit `pip download`
<sergiusens> barry for which I wanted to follow up with you on some other topic; seems there is a change in direction on what `install_data` should do in setup.py and that the whole thing is moving into a declarative setup. Any insight on that? I want the default plugin to follow the future and if necessary come up with another plugin that would live in the past
<barry> sergiusens: i see all the whls in parts/ubuntu-image/packages but not in stage/user/lib/python3/dist-packages.  do i need to explicitly stage things in stage-packages?
<sergiusens> barry those should be in lib/pythonXX/site-packages
<barry> sergiusens: there's not even a site-packages directory in stage/usr/lib/python3.5
<sergiusens> barry oh, add lib to your filters
<barry> (or a dist-packages)
<barry> ah
<barry> thanks, trying that
<barry> sergiusens: do you mean setup.cfg?
<sergiusens> barry this was part of the warning email I sent a month ago or so; $SNAP/lib is PYTHONUSERBASE
<barry> sergiusens: i feel a sense of deja vu ;)
<barry> sergiusens: thanks
<sergiusens> barry np
<sergiusens> barry this thread https://github.com/pypa/pip/issues/2874#issuecomment-109429489
<barry> sergiusens: i have a short day today.  let me look at this in detail on monday
<sergiusens> barry sure, no rush; it is future planning after all
<barry> cool
<mup> PR snapd#2149 opened: Finalize declaration based checks <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2149>
<jdstrand> pedronis (cc niemeyer): fyi, https://github.com/snapcore/snapd/pull/2149. see the comments-- I updated the store
<mup> PR snapd#2149: Finalize declaration based checks <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2149>
 * jdstrand is heading out for a while
<niemeyer> jdstrand: Sounds great, thank you!
<mup> Bug #1633638 opened: Can no longer install snaps with multiline plugs <Snappy:New> <https://launchpad.net/bugs/1633638>
<mup> PR snapd#2150 opened: tests: unflake ubuntu-core-reboot <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2150>
<niemeyer> jdstrand, matiasb: this looks like a bug in the assertion text, or in the assertion parser:
<niemeyer> https://bugs.launchpad.net/snappy/+bug/1633638
<mup> Bug #1633638: Can no longer install snaps with multiline plugs <Snappy:New> <https://launchpad.net/bugs/1633638>
<pedronis> niemeyer: doesn't make a lot of sense, the parsing should be the same on the server and client
<pedronis> matiasb: did we ignore some error somewhere ? ^
<pedronis> or it's roundtripping bug
<pedronis> but no
<niemeyer> jdstrand: Huston, we have a problem
<niemeyer> jdstrand: We need to revert the new decls in the store.. I failed to anticipate the fact old snapd's can't parse maps in assertions.. we'll need to tune the infra early next week
<niemeyer> Meanwhile, can you please take out the new slot/plug syntax, and keep it safe so we can readd next week?
#snappy 2016-10-15
<kyrofa> Hrmm... getting 500s from the store
<kyrofa> received an unexpected http response code (500) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/njObIbGQEaVx1H4nyWxchk1i8opy4h54_120.snap?t=2016-10-16T00:07:18Z&h=0ba6a1a8d394e41c7482b1b0059c67e37b03b260
<kyrofa> So I guess not the store, but a CDN layer
<jdstrand> niemeyer: ack, removing/saving
<niemeyer> jdstrand: Thank you, sorry for the trouble!
<jdstrand> niemeyer: ok, should all be reverted now. np, the hard part was everything else
<niemeyer> jdstrand: Outstanding, thank you! Next week we'll sit together with the server team and plan the proper reintroduction
<niemeyer> We need these back in still next week
<niemeyer> So hopefully we'll have some great ideas over the weekend! ;)
<jdstrand> sounds good
<niemeyer> A safe and pleasant trip for you
<jdstrand> niemeyer: you too! :)
<mup> Bug #1633638 changed: Can no longer install snaps with multiline plugs <Snapcraft:New> <https://launchpad.net/bugs/1633638>
<blackboxsw> jdstrand, niemeyer thanks for the quick assessment on the above ^
<blackboxsw> works for me now
<blackboxsw> snap installs aren't blocked for me anymore
<mup> Bug #1612757 changed: getpid system call is blocked by seccomp under confinement <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1612757>
<mup> Bug #1612595 changed: openstack-compute-controller require fchown system call <openstack> <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1612595>
<mup> Bug #1633638 opened: Can no longer install snaps with multiline plugs <Snappy:New> <https://launchpad.net/bugs/1633638>
<sborovkov> Hello. I am using classic image and wondering how do I get core dumps for snaps? Is there setting for their location? I am getting message that core dump is created. But I can't find it.
<raztafari_> Anyone using nextcloud with snappy and know how to mount an external drive to the raspi?
<mup> Bug #1633638 changed: Can no longer install snaps with multiline plugs <Snappy:Fix Released> <https://launchpad.net/bugs/1633638>
<enoch85> hey guys, if kyrofa around?
<jdstrand> ogra_: fyi, I approved linux-generic-bbb (and adjusted the review tools, but need a store sync). you still need to publish
<ogra_> jdstrand, ah, thanks
<jdstrand> kgunn: fyi, mir-server approved and I pressed the publish button
<kgunn> jdstrand: thanks!
<raztafari_> Can i change the file /etc/fstab somehow in ubuntu snappy, want to add a hard drive ?
<raztafari_> with the sudo command it says the file system is read only
<raztafari_> hello ?
<leftyfb> raztafari_: you should be able to remount / as read/write
<raztafari_> leftyfb: hi, do you know the command for that?
<leftyfb> raztafari_: try: sudo mount -o remount,rw /
<raztafari_> leftyfb: thank you! will try
<raztafari_> leftyfb: it made no difference still read-only file system
<leftyfb> raztafari_: once you remount, did you try logging out and back in?
<raztafari_> No will try that ^^
<leftyfb> raztafari_: other than that, I'm not sure. I actually don't have that much experience with ubuntu core at the moment
<ogra_> fstab is generated on boot ... better add a systemd mount unit
<ogra_> else your change is gone the next boot
<raztafari_> leftyfb: nope, still the same..
<raztafari_> ogra_: Ok, i want to change the nextcloud data folder and move it to an external hard drive since i don't have an 500gb micro sd card :P Maybe thats not even possible in snappy?
<ogra_> thats possible but more complex
<ogra_> you need to give the snap access to the right interface
<ogra_> then it can monitor external mounts in /media
<ogra_> (and access/mount/umount)
<raztafari_> okey, oh lets not go more complex :P
<ogra_> i dont know how well the integration with the mount interface in nextcloud is yet, perhaps kyrofa knows but he might be travelling this weekend (like most of us)
<raztafari_> Can't really figure out why they made a snappy build if it's running onyl from the microSD
<ogra_> well, it isnt more complex if the interface integration works (then it is simply a "snap connect" call)
<raztafari_> ogra_: okey, thanks anyway for your help!
<ogra_> np
<Sir_Gallantmon> Almost time to fly...
#snappy 2016-10-16
<dr1337> ogra_ is it possible to run snappy from mainline kernel? Are there specific patches beyond AppArmor that are required for snappy to run?
<mup> PR snapd#2151 opened: asserts,interrfaces/policy: allow OR-ing of subrule constraints in plug/slot rules <Created by pedronis> <https://github.com/snapcore/snapd/pull/2151>
<mup> PR snapd#2152 opened: many: normalize interface int attributes to int64 in their internal repr <Created by pedronis> <https://github.com/snapcore/snapd/pull/2152>
<mup> PR snapd#2153 opened: asserts: introduce an optional freeform model-display-name <Created by pedronis> <https://github.com/snapcore/snapd/pull/2153>
<zyga> jdstrand: hey
<zyga> jdstrand: are you at the holtel yet?
<mup> PR snapd#1613 opened: interfaces/builtin: add dbus-app interface <Blocked> <Reviewed> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<mup> PR snapd#2154 opened: make snap run not talk to snapd for finding the revision <Created by mvo5> <https://github.com/snapcore/snapd/pull/2154>
<mup> PR snapd#2150 closed: tests: unflake ubuntu-core-reboot <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2150>
<mup> PR snapd#2152 closed: many: normalize interface int attributes to int64 in their internal repr <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2152>
<sborovkov> c
<GnuHiatus> Is it ok to package open source software to snap?
<GnuHiatus> For example, Adobe's brackets
#snappy 2017-10-09
<PhoenixMage> Hi all
<PhoenixMage> zyga-solus: Has your layout remapping stuff been released yet?
<zyga-solus> PhoenixMage: no, but it's slowly taking shape
<zyga-solus> PhoenixMage: I hope to land the first user visible thing today
<zyga-solus> PhoenixMage: and then the most useful user visible thing (overlayfs)
<PhoenixMage> zyga-solus: Nice, let me know if you need a guinea pig
<PhoenixMage> Now I am back from vacation
<PhoenixMage> Need to get some Olimex Lime2 boards I think
<zyga-solus> PhoenixMage: I could use code review right away :)
<zyga-solus> PhoenixMage: if you are interested in that I can show you the way
<zyga-solus> ok, 50% sent to school, time for some work
<PhoenixMage> zyga-solus: Code is not my strong suit :/
<zyga-solus> PhoenixMage: I see, thank you for the offer still
<zyga-solus> pstolowski: hello
<zyga-solus> pstolowski: I was wondering how much work is needed to land https://github.com/snapcore/snapd/pull/3972 and let you iterate
<mup> PR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
<pstolowski> zyga-solus, hey!
<pstolowski> zyga-solus, 3972 itself is ready and captures item 1 of the plan I hope (https://forum.snapcraft.io/t/preparing-the-interfaces-logic-for-connection-hooks/2184)
<pstolowski> zyga-solus, items 2 and 3 are ready and I'm about to push a PR for that
<pstolowski> zyga-solus, item 4 ready too (will be part of same PR)
<zyga-solus> pstolowski: I wonder if we can get a 2nd review for 3972 today
<zyga-solus> pstolowski: maybe chipaca can help?
<pstolowski> zyga-solus, I need the second review from Gustavo
<pstolowski> zyga-solus, the sprint this week isn't going to help :/
<PhoenixMage> zyga-solus: Configuration and troubleshooting is more my area
<zyga-solus> ikey: hey, around?
<seb128> https://errors.ubuntu.com/problem/65c0ce797c1e385496c43cb7d869f3e2c0bc55ab looks like it could be a snappy issue?
<seb128> those reports have that error message
<seb128>  hook configure in snap "core" failed: cannot change profile for the next exec call: No such file or directory
<zyga-solus> seb128: looking
<zyga-solus> seb128: typically that means ubuntu package reused on !ubuntu kernel
<seb128> zyga-solus, thanks, I guess those reports don't have enough details to be useful then
<zyga-solus>  4.11.1-041101-generic
<zyga-solus> look at the kernel
<zyga-solus> that looks like the mainline kernel
<zyga-solus> I've been working on some patches that will let us work on mainline kernels soon, I may be able to put that into 2.29
<mup> PR snapd#4011 opened: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <https://github.com/snapcore/snapd/pull/4011>
<mup> PR snapd#4012 opened: cmd: add autoget case for solus <Created by zyga> <https://github.com/snapcore/snapd/pull/4012>
<mup> PR snapd#4013 opened: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013>
 * __chip__ hugs mwhudson 
<__chip__> mwhudson: just realised the two oldest PRs are yours
 * zyga-solus -> food
<c-lobrano> elopio: Hi, I'm on bug 1604815, but there might be a problem with the tests. The test_release_snap_to_invalid_channel triggers the same BAD RESPONSE reply of the bug, but the response payload doesn't seem the one expected (https://dashboard.snapcraft.io/docs/api/snap.html#id3) since the "errors" key is paired with a str and not with a list of dicts. Can you confirm, or am I missing something? Thanks!
<mup> Bug #1604815: The error when trying to release a revision that's not a integer is ugly <bitesize> <Snapcraft:In Progress by c-lobrano> <https://launchpad.net/bugs/1604815>
<zyga-solus>  re
<zyga-solus> now back to work
<mup> PR snapd#4012 closed: cmd: add autogen case for solus <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4012>
<niemeyer> pstolowski: Let's see if I can look quickly before the plenary starts here
<zyga-solus> niemeyer: hey
<zyga-solus> niemeyer: how's the sprint?
<pstolowski> niemeyer, o/, thanks
<niemeyer> pstolowski: Sent a first review
<niemeyer> pstolowski, zyga-solus: Let's please try to have sane code..
<niemeyer> zyga-solus: Sprint starting just now
<zyga-solus> niemeyer: ack
<zyga-solus> pstolowski: I left a comment on the PR
<zyga-solus> man, I should have read more kernel docs
<zyga-solus> I found a good way to solve another problem
<__chip__> zyga-solus: ...? :-)
<zyga-solus> __chip__: notify_on_release is such a natural
<__chip__> zyga-solus: sysctl -w kernel.global-warming=0 ?
<zyga-solus> haha
<zyga-solus> that'd be nice
<__chip__> who's standup-able today?
<zyga-solus> I am
<__chip__> me too
<zyga-solus> using notify_on_release I can solve an existing problem naturally
<__chip__> zyga-solus: isn't the release-agent snapside?
<wdouglass> when i snap runs, is it chrooted to the /snap/packagename/xx/ directory? i'm trying to figure out how paths work in a snap
<wdouglass> like if i do 'snap run --shell packagename' it's not chrooted, but the environment is set up
<__chip__> wdouglass: it's not chrooteed, no; what exactly are you trying to figure out?
<wdouglass> __chip__: i'm trying to run a tkinter program, and it can't find 'init.tcl'
<wdouglass> i'm trying to set the paths properly, and in a way that's portable.
<__chip__> wdouglass: "snap run --shell" is the exact same environ
<wdouglass> hmm ok
<__chip__> oooh, that should be fun
<__chip__> wdouglass: we haven't snapped a tcl thing before? strange
<zyga-solus> __chip__: snapside? I mean it snapd could then do the cleanup properly
<wdouglass> well I haven't
<wdouglass> i'm very new at this
<zyga-solus> wdouglass: it's not as simple as that
<zyga-solus> wdouglass: when snap runs it gets a mount namespace with the designated base snap as the rootfs
<zyga-solus> wdouglass: and a few things changed all around the place to make the world workable
<zyga-solus> wdouglass: the shell advice is very useful, explore and look around
<__chip__> wdouglass: https://stackoverflow.com/questions/39177158/tcl-cant-find-init-tcl-in-a-snap-package
<zyga-solus> wdouglass: you may also look at how mounts are laid out
<wdouglass> i saw that stackoverflow -- i'm trying to have as little impact on my upstream package as possible.
<__chip__> ah
<__chip__> wdouglass: but the answer there doesn't seem (at a quick read) to impact the upstream code at all?
<pstolowski> niemeyer, thanks for the review
<__chip__> zyga-solus: âthe kernel runs the command specified by the contents
<__chip__> of the "release_agent" file in that hierarchy's root directoryâ
<wdouglass> hmmm...guess i didn't really understand the "glue" section. i'll look into that
<__chip__> wdouglass: the "wrappers" are little scripts that set up the environ before calling the binaries
<wdouglass> ok, so i can just put those wrappers next to my snapcraft.yaml, and then use the 'copy' plugin to put them in the right place?
<__chip__> yes
<wdouglass> awesome. Thanks for the clarification
<zyga-solus> __chip__: right, that's what I need
<__chip__> zyga-solus: but my point was that "that hierarchy" is snapside
<zyga-solus> hmm, I don't follow
<zyga-solus> snap-side as in ?
<zyga-solus> where?
<zyga-solus> __chip__: my intent is to have that run snap-discard-ns (indirectly0
<zyga-solus> __chip__: this would allow us to simplify snap-confine
<__chip__> zyga-solus: i mean it runs inside the namespace, doesn't it?
<zyga-solus> __chip__: I don't think so
<zyga-solus> but even if that's the case it's not a problem
<__chip__> ok, fair enough
<zyga-solus> __chip__: we can setns outside and unmount what we have to
<zyga-solus> __chip__: setns, unmount, unlink, done
<zyga-solus> that and the locking
<wdouglass> hmmm....ok, the tcl wrapper thing worked. thanks for that. Now there's a new problem! i'm getting some fontconfig errors. "Unable to update the static FcBlanks"
<wdouglass> is there a trick to getting fontconfig working?
<zyga-solus> and now I notice that chipaca is *not* on irc
<zyga-solus> __chip__: so does that give 4011 two +1s?
<zyga-solus> I +1d the orinal
<zyga-solus> original*
<zyga-solus> note that I need to also update the packaging trees but nvidia is not tested much
<zyga-solus> I shall better to that
<zyga-solus> __chip__: are you using python ;)
<__chip__> zyga-solus: in what sense?
<__chip__> zyga-solus: this nick comes from my python days, yes
<__chip__> for when i was feeling "special"
<__chip__> or i wanted to pull __lucio__'s leg
<zyga-solus> haha
<zyga-solus> I was wondering the dunder semantics of chip(object)
 * ikey blinks at the zyga-solus 
<zyga-solus> o/
<zyga-solus> ikey: I picked up one of your branches
<zyga-solus> ikey: I pushed a new one up with conflict fixes, I'll do one more tweak to it and let's land it
<ikey> oh thanks bud
<ikey> ive been hammered with this gnome work the last few days -_-
<ikey> (3.26 stack update + systemd + llvm + ....)
<zyga-solus> ikey: thank you for putting it up, I'll try to land the other branches soon too
<ikey> you are too good. ^_^
<zyga-solus> does anyone know when v2 cgroups will be around?
<zyga-solus> jdstrand, tyhicks ^ you maybe?
<cachio> niemeyer, I saw this error: 2017-10-09 13:08:29 Discarding linode:ubuntu-14.04-64 (Spread-78), cannot connect: cannot connect to linode:ubuntu-14.04-64 (Spread-78): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain
<cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/285355223
<cachio> I'll check if there are more like this
<cachio> Son_Goku, hey, I saw some test errors setting up fedora
<cachio> ++ dnf -q -y --refresh install expect
<cachio> Error: Failed to synchronize cache for repo 'updates'
<Son_Goku> linode *grumbles*
<cachio> Son_Goku, any idea what could be causing that?
<Son_Goku> I think Linode has a registered mirror for their IP block with Fedora MirrorManager
<Son_Goku> so all requests to the metalink and mirrorlist return Linode's mirror
<Son_Goku> but when it's mid metadata sync, the repomd.xml file doesn't exist, so that happens
<zyga-solus>  ahh
<cachio> Son_Goku, ah, ok, any workaroud at least to manage that error?
<zyga-solus> Son_Goku: nice work
<Son_Goku> cachio: force a different mirror or try again later?
<Son_Goku> really, someone needs to talk to Linode about how they rsync from tier 1 mirrors
<Son_Goku> they probably are using the wrong rsync options to keep things sane during update
<zyga-solus> Son_Goku: can you jump into #linode and ask them, all the linode staff seems to be lurking there
<zyga-solus> Son_Goku: and I think you are the best qualified to explain how to do that properly
<Son_Goku> I guess
<cachio> Son_Goku, agree
<cachio> with zyga
<__chip__> cachio: are you ok with https://github.com/snapcore/snapd/pull/3951/commits/a803b5a0af7f86e461f2a5d21c0b9d4aa0935511 ?
<mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
<cachio> __chip__, checking
<cachio> __chip__, yes, lgtm
<__chip__> ok, i'll merge when green then
<mup> PR snapd#4011 closed: cmd: correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4011>
<mup> PR snapd#3978 closed: cmd: Correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3978>
<mup> PR snapd#4014 opened: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>
<wdouglass> hmmm..ok so it looks like the fcblanks thing is a red herring. i'm getting a segfault somewhere in TCL
<zyga-solus> wdouglass: you probably are missing fonts, core has no fonts
<wdouglass> that make sense, thanks
<zyga-solus> wdouglass: it's a work in progress from our end, for now you can use one of the workarounds people use that inject fonts and some fontconfig env variables
<ogra_> use the desktop launcher and the snapcraft desktop part
<ogra_> alternatively here is an example with a wrapper script https://github.com/ogra1/jtiledownloader (make sure to have something in your stage-packages that pulls in fontconfig and some fonts ... i.e. a theme package)
<wdouglass> so i just stage-package a theme and it should work. Cool! trying this now.
<ogra_> well, you need the env variables the wrapper sets as well
<zyga-solus> wdouglass: i don't know - I suspect you need a bit more but I really don't know
<wdouglass> ogra_: alright cool, i'm already using a wrapper for tcl (meantioned above) so i'll just add more variables there
<ogra_> right, even though jtiledownloader is java, the font stuff should work for tcl too
<wdouglass> ok, so that got rid of my fcblanks problem, but i'm still getting a segfault as soon as I create my first Tk widget
<wdouglass> oh wait, i may have missed a variable...
<zyga-solus> __chip__: let's land this one please https://github.com/snapcore/snapd/pull/4014
<mup> PR #4014: packaging: update nvidia configure options <Created by zyga> <https://github.com/snapcore/snapd/pull/4014>
<__chip__> zyga-solus: this is the other half of the previous one?
<wdouglass> it works! thanks so much guys!
<__chip__> wdouglass: huzzah!
<zyga-solus> yep
<elopio> good morning
<__chip__> hah, i approved twice
<__chip__> not that it's a day i'm easily distracted or anything
<elopio> clobrano: hello! The unit tests use a fake server with hardcoded replies.
<c-lobrano> elopio: hi! Yes, I saw it. I'd like to have a double check, before changing this test
<elopio> c-lobrano: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fake_servers/api.py#L382 That line is wrong. We should put the message in a list.
<elopio> that's why we are not very happy with the fake servers.
<c-lobrano> :)
<c-lobrano> elopio: is that just a list or a list of dictionaries?
<c-lobrano> elopio: the format seems to be {"name": ["reason"]}
<c-lobrano> I meant, errors :[ {"name": ["reason"]}] (quite complicated)
<elopio> yeah, a list of dictionaries, with the field as the key, and a list of strings as the value.
<elopio> let me try to release to an invalid channel, to get the exact reply from the store.
<c-lobrano> ook, so I could expect more that one "reason" per key?
<c-lobrano> alright, thanks a lot
<elopio> c-lobrano: ahh, this one is different: {'success': False, 'errors': 'Track does not exist: invalid', 'error_list': [{'code': 'invalid-field', 'message': 'Track does not exist: invalid'}]}
<elopio> let me now try to release to not a number and see if it's the same.
<elopio> c-lobrano: {'success': False, 'error_list': [{'code': 'invalid-field', 'message': "The 'revision' field must be an integer"}], 'errors': {'revision': ['This field must be an integer.']}}
<c-lobrano> elopio: uhm, ok. The problem is that StoreReleaseError is at the edge of "too complex" :D
<c-lobrano> elopio: I need to find a simple solution
<c-lobrano> error_list is actually quite nice
<jdstrand> zyga-solus: note we are both sprinting (cc tyhicks), but my understanding is that practically speaking, v2 cgroups won't be around by default until the issues surrounding them not being able to be used at the same time are resolved
<jdstrand> (same time as v1)
<ikey> so then does snapd mandate legacy cgroup hierarchy in systemd?
<jdstrand> iirc, there were a lot of discussions about how to make that happen, but no concrete plan that people are working on. stgraber would also be able to orrect me
<jdstrand> ikey: I think that what we would want to support is that when systems are using only v2 cgroups, snappy shuld be able to detect that nand use them
<ikey> yea
<ikey> good job my systemd is set to legacy then i guess xD
<jdstrand> my point was that I don't really know when a system can reasonably be v2
 * ikey encountered that issue in the past with docker already
<jdstrand> there are a lot of technical challenges with mixing the two that need to be reasonably resolved
<zyga-solus> jdstrand: thank you for the note
<zyga-solus> jdstrand: I'm making progress, I think we are in a good position
<mup> PR snapd#3951 closed:  snap: add new `snap pack` and use in tests  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3951>
<__chip__> zyga-solus: what's missing for snapd#3958?
<mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
<zyga-solus> __chip__: niemeyer asked for a wait for review
<zyga-solus> I'm happy as is
<elopio> c-lobrano: you can split the big function in subfunctions. There can be one like _get_text_for_store_release_errors_401_and_403.
<c-lobrano> elopio: right, that would be a good idea
<c-lobrano> elopio: but with error_list I should be able to format a nice message passing only the dictionary
<c-lobrano> and runtest.sh isn't complaining so far :)
<mup> PR snapd#4014 closed: packaging: update nvidia configure options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4014>
<__chip__> zyga-solus: i suspect master is broken (but it might be just this PR)
<__chip__> let me push this out and check master before frightening you, better
<__chip__> zyga-solus: phew. looks like just this PR. sorry for the scare.
<__chip__> in my defense it's not _my_ pr :-)
<zyga-solus> __chip__: ouch, is that my doing?
<zyga-solus> __chip__: let me see how I can help
<__chip__> zyga-solus: no, it's mvo's doing, in mvo's branch
<zyga-solus> __chip__: which branch is that?
<__chip__> zyga-solus: master is fine
<zyga-solus> ah, uff
<zyga-solus> good
<zyga-solus> I'm deep in systemd and cgroups
<__chip__> zyga-solus: https://github.com/snapcore/snapd/pull/3995/commits/d1dab9d03903efa3d10e39d3d0ce44683ebf23fa
<mup> PR #3995: snap: support "command: foo $ENV_STRING" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3995>
<zyga-solus> going from "aha, eureka" to "darn s***"
<zyga-solus> and back
<zyga-solus> hmm
<zyga-solus> didn't I like push to that branch?
<__chip__> zyga-solus: systemd <4-dimensional emoji that turns mazlow's pyramid on end and breaks several international conventions on human rights> cgroups ?
<__chip__> zyga-solus: github says no
<zyga-solus> __chip__: I just feel it's a bit complex and not working
<zyga-solus> __chip__: odd
<zyga-solus> ah that was https://github.com/snapcore/snapd/pull/4006
<mup> PR #4006:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4006>
<zyga-solus> I just found this odd because I also made a chmod +x patch
<__chip__> heh
<__chip__> zyga-solus: i didn't --force, promise
<zyga-solus> """
<zyga-solus> cgroup empty notification is seriously broken unfortunately in the
<zyga-solus> kernel the way it is currently implemented. And we'll miss the
<zyga-solus> callouts in a number of cases (for example, if somebody has any dir in
<zyga-solus> a cgroup still we get no events for it. It's also not available at all
<zyga-solus> inside of containers, since the callouts take place on the main pid
<zyga-solus> namespace, and nowhere else)."""
<zyga-solus> ^- I should get a drnk
<zyga-solus> *drink
<__chip__> drnk snds rght
<ogra_> jdstrand, zyga-solus ... http://paste.ubuntu.com/25708869/ note that i uninstalled the ubports-instller snap before i plugged in the SD card reader in that log
<ogra_> this mess goes on and on ...
<ogra_> looks like uninstalling the snap left some udev stuff around
<zyga-solus> ogra_: looking
<zyga-solus> ogra_: is pid 29417 still alive?
<ogra_> ogra@styx:~/Devel/model-creator$ ps ax|grep 29417
<ogra_>  9179 pts/5    S+     0:00 grep --color=auto 29417
<ogra_> nope
<zyga-solus> the comm name is interesting
<zyga-solus> ogra_: are you still seeing those messages
<ogra_> yes, every time i plug or remove the SD card reader
<zyga-solus> ogra_: interesting
<zyga-solus> jdstrand: I'm lost, it looks like a bug
<ogra_> it definitely does
<ogra_> note the snap uses devmode by default https://github.com/ubports/ubports-installer/blob/master/snapcraft/snapcraft.yaml
<ogra_> (though that should be obviousl from the "ALLOWED" messages)
<zyga-solus> right, I'm trying to see what's going on here
 * zyga-solus puts this laptop back on the charger and gets to do something on the othe rone
<mup> PR snapcraft#1596 closed: tests: move ruby demo test to snapd integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1596>
<mup> PR snapcraft#1348 closed: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1348>
<mup> PR snapcraft#1382 closed: rust plugin: make libc configurable <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1382>
<mup> PR snapcraft#1387 closed: [WIP] tests: reenable the cleanbuild integration test <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1387>
<mwhudson> __chip__: two oldest?? hah
<mwhudson> i guess i'm glad random contributors from outside the company have a better time
<mup> PR snapd#3995 closed: snap: support "command: foo $ENV_STRING" <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3995>
<__chip__> facubatista: o/
#snappy 2017-10-10
<mup> PR snapcraft#1598 opened: recording: do not crash when snapd is not installed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1598>
<mup> PR snapd#4006 closed:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4006>
<mup> PR snapcraft#1589 closed: Update default node engine to 6.11.3 <Created by flexiondotorg> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1589>
<mwhudson> if someone is bored (ha, ha), they could look into why classic snap builds on artful fail like this: https://launchpadlibrarian.net/340314110/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz
<mwhudson> on ppc64el only, i should add
<zyga-solus> good morning
<zyga-solus> today is another cgroup day, hopefully one with fewer disappointments
<kalikiana> good morning
<zyga-solus> o/
<kalikiana> hmmm two of my PRs have landed, this is a good start
<kalikiana> zyga-solus: how's your poleflu? (I think that's what you called it :-P)
<zyga-solus> kalikiana: thank you, I feel much better now
<zyga-solus> kalikiana: getting into the habit of using longe sleeves and other warm-keeping stuff helps
<zyga-solus> kalikiana: I really miss the sun, it's almost winter here
<zyga-solus> kalikiana: rain will just turn to snow one day (any day)
<kalikiana> yeah, sunny days are over it seems :-(
<kalikiana> sergiusens: I'm very confused. I thought you merged https://github.com/snapcore/snapcraft/pull/1348 https://github.com/snapcore/snapcraft/pull/1382 but you just closed them? Some discussion would be helpful here
<mup> PR snapcraft#1348: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1348>
<mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1382>
<mup> PR snapd#3964 closed: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3964>
<naveed> help
<ackk> hi, is there a way in snapd to perform operations when a plug is connected/disconnected? I mean perform actions in snapd itself, not something like external scripts
<naveed> i am using Dell gateways 5000 and try to connect my mobile via bluetooth for sending data
<naveed> but when i enter connect it gives error "org.bluez.error failes"
<naveed> fasorry failed
<mup> PR snapcraft#1599 opened: Fixed StoreReleaseError format for BAD REQUEST error <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1599>
<zyga-ubuntu> ackk: hey
<zyga-ubuntu> ackk: it's coming along but it's not ready
<zyga-ubuntu> ackk: pstolowski is working on interface hooks that fire when you connect/disconnect things
<ackk> zyga-ubuntu, ah, I see
<ackk> zyga-ubuntu, ok, so for now I guess the socket activation stuff will need to be started/stopped on snap start/stop, it can't be done when the network-bind plug is actually connected/disconnected
<ackk> that's fine
<zyga-ubuntu> yes
<ackk> zyga-ubuntu, ok, thanks
 * kalikiana short break
 * zyga-ubuntu -> break 
<kalikiana> sliff
<zyga-ubuntu> re
<spineau> jamesh: hello, I'd like to know if the polkit support added to 2.28 allows pkexec to work from the snap (and obeys to the policy file(s)  installed in /usr/share/polkit-1/actions/)
<mup> PR snapd#4015 opened: run-checks: use nakedret to check for naked returns on long functions <Created by chipaca> <https://github.com/snapcore/snapd/pull/4015>
<cjwatson> mwhudson: investigated: https://github.com/snapcore/snapcraft/pull/1600
<mup> PR snapcraft#1600: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1600>
<mup> PR snapcraft#1600 opened: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1600>
<zyga-ubuntu> __chip__: standup?
<mvo> __chip__: we had a test failure from the new progress bar in the ppa builds, I can give you details in a sec
<mvo> __chip__: also, whats up with this nick? is this the new default
<Eighth_Doctor> Yo
<Eighth_Doctor> man, it sucks not having my main laptop
<Eighth_Doctor> I have to remember all the IRC channels I'm active in and add them
<ikey> and worse than that you're not even the 9th or 10th..
 * ikey feels for you.
<ikey> erm. i mean *hi :)
<Eighth_Doctor> haha
<Eighth_Doctor> well, at least you got it :)
<ikey> aye :]
<Eleventh_Doctor> this laptop is configured with an older version of my profile
<Eleventh_Doctor> I carried it forward from various IRC clients and various laptops before I started over on the new laptop
<Eleventh_Doctor> my Linux laptop has always used some variation of this nick ;)
<Eleventh_Doctor> I've never been a huge fan of the 9th
<Eleventh_Doctor> the 10th is awesome, though
<ogra_> the elleventh is still my favourite
<Eleventh_Doctor> mine too
<sergiusens> kalikiana closed them because they had no changes in 2 weeks++ and failing tests
<kalikiana> sergiusens: That's not true. They had commits in the last few days
<sergiusens> kalikiana "kalikiana added some commits 18 days ago "
<sergiusens> on both of those
<Eleventh_Doctor> sergiusens: it lists by author date
<Eleventh_Doctor> which is irrelevant
<Eleventh_Doctor> if you amend commits, that date doesn't change
<sergiusens> ah, that can make sense Eleventh_Doctor
<Eleventh_Doctor> I learned after the last couple of times my PR has been closed for looking out of date that people read the GH web interface and take it literally
<sergiusens> kalikiana you still have many PRs open, focus on fixing them one by one instead of all at once
<Eleventh_Doctor> so I rewrite the author dates every time now
<sergiusens> as you may be eating up the travis qutoa for everyone else
<sergiusens> kalikiana or do them all in parallel, but run the suite locally
<sergiusens> the full suite
<Eleventh_Doctor> zyga-solus: ping
<kalikiana> sergiusens: Well, the local runs aren't the problem, I'm getting killed by false negatives...
<sergiusens> Eleventh_Doctor it is so hard to keep track of your irc handles! ;-)
<Eleventh_Doctor> well, I really don't use this laptop very much
<Eleventh_Doctor> so these nicks don't show up often
<sergiusens> Eleventh_Doctor finally off the mac ;-)
<Eleventh_Doctor> oh, this is a Mac
<Eleventh_Doctor> it just runs Linux ;)
<mvo> Chipaca: https://launchpadlibrarian.net/340343990/buildlog_ubuntu-xenial-arm64.snapd_2.28.1+git425.72389e7~ubuntu16.04.1_BUILDING.txt.gz is the link, I can extract the failure for you in a sec to a pastebin
<Eleventh_Doctor> this MacBook has been running Fedora for the last two years
<mvo> Chipaca: http://paste.ubuntu.com/25713767/
<Eleventh_Doctor> it's much more performant than it was when it ran Mac OS X
<mvo> Chipaca: fwiw, the error looks "interessting"
<sergiusens> kalikiana document that analysis in the PR so everyone is aware of it then and find the root cause
<mvo> Chipaca: I mean, something with the bytes download counting is wrong 95B vs 99B
<Chipaca> hah
<Chipaca> i wondered about that while writing the test
<zyga-ubuntu> Eleventh_Doctor: hey
<Chipaca> and then thought "nah, it can't be so slow as to be less than this"
<Eleventh_Doctor> zyga-ubuntu: I pushed snapd updates, I need karma!
<zyga-ubuntu> Eleventh_Doctor: aha, I'll look at F26 then
<zyga-ubuntu> Eleventh_Doctor: what's this nickname about? :D
<Chipaca> mvo: easy to fix. Will fixing master be enough?
<Eleventh_Doctor> zyga-ubuntu: this is my Linux laptop
<zyga-ubuntu> Eleventh_Doctor: oh, nice, a new one?
<Eleventh_Doctor> with more or less my original IRC configuration carried through various laptops/clients
<Eleventh_Doctor> actually, this is my oldest laptop that still works
<Eleventh_Doctor> a 2009 MacBook Pro
<Eleventh_Doctor> but instead of Mac OS X, it runs Fedora
<Eleventh_Doctor> I wiped it as soon as the warranty ran out
<ogra_> pffft warranty
<Eleventh_Doctor> well, with the proprietarization of laptop components, it's gotten really hard to service them myself :(
<Eleventh_Doctor> and a lot of laptop warranties void on changing the OS
<Eleventh_Doctor> (which is dumb and potentially illegal, but there's not a lot I can do)
<mvo> Chipaca: yes
<Eleventh_Doctor> zyga-ubuntu: snapd v2.28.1 with the backport of the distro check fixes
<Eleventh_Doctor> https://bodhi.fedoraproject.org/updates/?packages=snapd
<zyga-ubuntu> Eleventh_Doctor: huh? and is apple really doing thaT?
<Eleventh_Doctor> zyga-ubuntu: Yes
<zyga-ubuntu> Eleventh_Doctor: can you point me to where it says so?
<zyga-ubuntu> because that's definitely not legal in EU
<Eleventh_Doctor> it may be US specific :(
<Eleventh_Doctor> it's not legal per-se in the US either
<Eleventh_Doctor> but Apple retains the right to refuse servicing for any reason
<Eleventh_Doctor> my next go around, I'm probably picking up a Dell XPS
<Eleventh_Doctor> they're turning into nice beefy laptops while remaining really lightweight
<Eleventh_Doctor> they ship with Ubuntu or Windows, but that can be easily fixed :)
<zyga-ubuntu> Eleventh_Doctor: I'd be surprised if apple really refused that but IDK
<Eleventh_Doctor> it's usually not Apple directly that refuses
<Eleventh_Doctor> but the service centers that aren't operated by Apple
<Eleventh_Doctor> also, removing macOS removes the necessary bits for service center diagnostics to run
<Eleventh_Doctor> because apparently that's a thing
<Eleventh_Doctor> which is why they ask for admin credentials to the laptop :/
<zyga-ubuntu> Eleventh_Doctor: eh, I know that last bit, I refused
<zyga-ubuntu> (and they did service me)
<Eleventh_Doctor> I used to leave it dual-booted with an empty and useless macOS
<sergiusens> ppisati_ hey, what was your bug again? I will have time to fix it today
<Chipaca> mvo: snapd#4016 is the fix
<mup> PR #4016: progress: be more flexible in testing ansimeter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4016>
<mvo> Chipaca: thanks a bunch
<mup> PR snapd#4016 opened: progress: be more flexible in testing ansimeter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4016>
<mvo> Chipaca: eh, thanks a lot
<mvo> Chipaca: sorry, I learned the difference between "thanks a bunch" and "thanks a lot" only recently. anyway, thanks :)
<zyga-ubuntu> you know
<zyga-ubuntu> I find it hard to name test snaps
<mvo> test1
<mvo> test2
<mvo> :P
<zyga-ubuntu> I think it would help if we could have a local name in the directory with the task
<zyga-ubuntu> right, if those were local and would not compete with other "snap testing interfaces" it'd be easier
<cachio> mvo, this is the error in zesty https://launchpadlibrarian.net/340372113/buildlog_ubuntu-zesty-ppc64el.snapd_2.27.6+17.04_BUILDING.txt.gz
<cachio> on ppc
<cachio> the rest is working properly
<mvo> cachio: yeah, I just tried to find the root cause but failed so far
<jamesh> spineau: it won't make any difference there: my changes were all about getting snapd to talk to polkit to provide access control to its own API.  Allowing confined services to talk to polkit (and install default policies) is a different matter.
<jamesh> spineau: it isn't on my radar, but it would be worth bringing up on the forum.
<spineau> jamesh: ok, I see. thanks
<Chipaca> mvo: what difference between thanks a bunch and a lot have you learned?
<mvo> Chipaca: someone from the uk explained that often "thanks a bunch" is ironic/sarcastic. I had no idea before and I think I confused a lot of native speakers :)
<mvo> Chipaca: but maybe its just specific parts of the world where it is used like this
<Eleventh_Doctor> mvo: it has different meanings depending on tone
<Eleventh_Doctor> in the US, it's primarily not used sarcastically
<Eleventh_Doctor> but in the east coast, it is
<mvo> Eleventh_Doctor: aha, that is interessting
<jamesh> mvo: both can be used sarcastically.  It depends on the tone
<Eleventh_Doctor> thanks is often used sarcastically
<mvo> geh, english is a complicated language :)
<jamesh> something irc doesn't convey very well
<mvo> thanks jamesh
<Eleventh_Doctor> :/
<mvo> jamesh: yeah, irc lacks the nuances :-D
<Eleventh_Doctor> if you think English is bad, Japanese is way worse
<Eleventh_Doctor> the *whole* reason for emoji is to deal with that problem
<mvo> Eleventh_Doctor: heh, fun!
<Eleventh_Doctor> and of course, emoticons have been used in text long before computers for the same reason
<Eleventh_Doctor> but Japanese has the special problem of conveying meaning and feeling almost entirely through tone
<Eleventh_Doctor> they don't have emotion words, per se like English does
<Eleventh_Doctor> so there's not an explicit set of "profane" words
<Eleventh_Doctor> the *way* you say it turns certain words "profane"
<Chipaca> mvo: yeah, the tone is important; otherwise it's mostly used interchangeably (and "thanks a lot" can be and does get used sarcastically as well)
<Chipaca> OTOH, https://en.wiktionary.org/wiki/thanks_a_bunch
<Eleventh_Doctor> "thanks a lot" is the American equivalent to "thanks a bunch"
<Chipaca> says UK usage is unambiguously sarcastic, which is news to me (but then maybe i should go out more)
<Eleventh_Doctor> UK uses thanks a bunch entirely sarcastically
<Eleventh_Doctor> but outside of the east coast in the US, it's not necessarily so
<Eleventh_Doctor> the *only* reason it is that way in the east coast is due to the stronger European heritage there
<Eleventh_Doctor> but "thanks a lot" is unambiguously sarcastic in most of the US
<Chipaca> silly UKans, going over there, UKing the place up
<Eleventh_Doctor> this is primarily because "a bunch" is rarely used in the US
<Eleventh_Doctor> "a lot" is the primary form
<Eleventh_Doctor> the UK reverses this, since "a lot" isn't used very much there
<Chipaca> the bottom line is: never thank anybody for anything
<mvo> yeah, it sounds like it - meh :/
<mvo> I guess a simple "thanks" is what I should remember
<Eleventh_Doctor> ;)
<Chipaca> mvo: go with "gramercy"
<Eleventh_Doctor> "thanks", "thank you" work well enough
<Chipaca> then everybody will have to look it up, giving you time to run away
<niemeyer> o/
<mvo> hey niemeyer! how are you?
<niemeyer> mvo: Did we land the squashfs-fuse thing?  I recall we talked about it and agreed to land it, but I don't recall actually shipping it
<niemeyer> mvo: Pretty good, thanks
<niemeyer> mvo: Had the internal session this morning.. almost uneventful.. roadmap remains mostly the same, with one critical item added above others which we need to discuss
<mvo> niemeyer: squashfs-fuse did not land, lets push it high on the stack
<mvo> niemeyer: will you update the roadmap with the new item(s)?
<niemeyer> mvo: I'd like to talk about it first
<Eleventh_Doctor> mvo: wait, what?
<Eleventh_Doctor> what's this about squashfuse support not landing?
<niemeyer> mvo: As it's a bit of a high-level requirement right now.. would like to build ideas so we can write down something more concrete
<niemeyer> mvo: Ugh.. man.. how did we forget that again :(
<niemeyer> Shame on us
<mvo> niemeyer: high-level> sounds good
<mvo> niemeyer: yes :(
<mvo> niemeyer: I finish my current task (should not take long) and get to it, if we rush it it can still go into 2.29
<niemeyer> Eleventh_Doctor: It's just about making it easier to work with.. won't affect you
<mvo> mostly for lxd
<Eleventh_Doctor> ah
<niemeyer> mvo: Thank you! 2.29 it is then
<Eleventh_Doctor> well, that already landed for Fedora snapd ;)
<Eleventh_Doctor> mainly because kyrofa asked for it and actually did the work to make it possible in Fedora
<mvo> Eleventh_Doctor: nice - btw, is that you Neal? if so, you have too many nicks ;)
<Eleventh_Doctor> yes
<ogra_> is kyrofa secretly using fedora now instead of ubuntu ?
<ogra_> :)
<ogra_> (because he gets the features faster there)
<Eleventh_Doctor> :D
<Eleventh_Doctor> he's also working on packaging LXD for Fedora
<ogra_> whee !
<Eleventh_Doctor> so that we have it properly integrated with container-selinux
<mvo> Eleventh_Doctor: heh, do you have more nicks that I should be aware of :) ?
<Eleventh_Doctor> umm...
<cachio> mvo, niemeyer zyga-ubuntu pstolowski this is the doc for the core snap built as part of the spread-cron run https://forum.snapcraft.io/t/building-and-testing-the-core-snap-on-edge-channel/2419
<ogra_> mvo, evey nick you dont recognize :)
<Eleventh_Doctor> just check my netmask
<ogra_> just assume it is neal
<Eleventh_Doctor> it should always say ngompa/fedora
<Eleventh_Doctor> err, fedora/ngompa
<pstolowski> cachio, thanks!
<Eleventh_Doctor> I also submitted a PR to container-selinux to add LXD support: https://github.com/projectatomic/container-selinux/pull/42
<mup> PR projectatomic/container-selinux#42: Add support for LXD <Created by Conan-Kudo> <https://github.com/projectatomic/container-selinux/pull/42>
<niemeyer> mvo: Just recalling, we'll do it as a "snapfs" right?
<mvo> cachio: fwiw, I think the ppc64el issue we have right now should not halt hte 2.28.1 core snap release, we need to figure out what is going on there but core for ppc64el is ready at 2.28.1 so the build is fine
<cachio> mvo, niemeyer zyga-ubuntu pstolowski, it is related to the PRS; https://github.com/snapcore/spread-cron/pull/49 and https://github.com/snapcore/spread-cron/pull/48
<mup> PR spread-cron#49: Task to build core snaps in launchpad <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/49>
<mup> PR spread-cron#48: Adding commits information on snapd-vendor launchpad repo <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/48>
<mvo> niemeyer: yeah, iirc we agreed on snapfs
<kyrofa> ogra_, haha, no, but the way I test stuff on fedora is running fedora instances via lxd
<ogra_> :)
<kyrofa> ogra_, that experience was not great
<mvo> niemeyer: did we ever write a forum post or something?
<ogra_> i can imagine
<cachio> mvo, ok, so we should go first to stable with the 2.28.1?
<Eleventh_Doctor> kyrofa: I'll get you to switch to Fedora yet :P
<Eleventh_Doctor> anyway guys, I gotta get going
<Eleventh_Doctor> my day job awaits
<mvo> cachio: I think it should not hold back core, I will investigate, we probably need a 2.28.2 for the SRU for zesty but that should be ok
<niemeyer> mvo: I don't think so.. :(
<diddledan> does snapd set the order of snaps to be mounted when it starts up? I appear to be seeing my system try to connect interfaces to core before core has been started and thus the interfaces are not present yet
<pstolowski> niemeyer, hello! i hope you have a good sprint!
<Eleventh_Doctor> WOO!
<Eleventh_Doctor> my laptop is now repaired!
<pstolowski> niemeyer, i've addressed the main point you had for #3972 and left some comments
<mup> PR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
<cachio> mvo, ok, I'll promote to stable the 2.28.1 in that case
<ikey> sooo i might've created the child of satan but
<diddledan> :-o
<ikey> i made a magic script that seems to be able to create a dist vendor tarball for snapd..
<diddledan> devil child!
<ppisati_> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1718886
<mup> Bug #1718886: snapcraft.yaml: add dpkg-dev to the build deps <patch> <linux (Ubuntu):Confirmed> <snapcraft (Ubuntu):New> <linux (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Xenial):New> <https://launchpad.net/bugs/1718886>
<ikey> diddledan, https://hastebin.com/fafolohoma.sql :P
<ppisati_> sergiusens: actually i already found what the problem was, and there's a patch attached
<ppisati_> sergiusens: but i'm not entirely sure of the fix
<cachio> mvo, core snap 2.28.1 promoting to stable
<mvo> cachio: thanks! time for a forum post - niemeyer do you want to do the forum post that announces 2.28.1?
<mup> PR snapd#4017 opened: store: add download caching <Created by mvo5> <https://github.com/snapcore/snapd/pull/4017>
<cachio> mvo, niemeyer promotion completed
<mvo> cachio: \o/
<cachio> mvo, testing the refresh on my machine
<cachio> working \o/
<sergiusens> ppisati_ thanks
<sergiusens> ppisati_ weren't you having a problem with the `source` entry the week before last?
<ppisati_> sergiusens: the build dir, src is ok, it's decompressed correctly there, but .config i thought wasn't being copied to the build dir
<ppisati_> sergiusens: but it turned out it was copied, it's just that the kbuild plugin doesn't expect the .config to be already there
<ppisati_> sergiusens: ah crap
<ppisati_> sergiusens: i pasted you the wrong lp bug
<ppisati_> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1722494
<mup> Bug #1722494: .config disappears from build dir <Snapcraft:New> <https://launchpad.net/bugs/1722494>
<ppisati_> sergiusens: sorry :(
<kyrofa> Hey elopio, you around?
<elopio> Hello
<kalikiana> o/
<kyrofa> elopio, good morning! I want to figure out a good solution for the slow ROS tests, one that scales
<kyrofa> You mentioned labeling it as slow so that it doesn't run on travis, seems reasonable. But then they'd run on autopkgtests?
<kyrofa> Or is that something that we still need to develop?
<elopio> kyrofa: I'm exploring options. Trying to launch tests on the PPA daily, with some help in #ubuntu-release
<kyrofa> elopio, okay good deal. Just let me know what to do on that ament PR once you've settled on a path?
<elopio> kyrofa: that's my idea, not yet implemented because I don't yet know how. If you need to run a slow test, the bot can trigger it in a PR for you, no problem there.
<kyrofa> Oh, we do have that today? That works fine for me
<elopio> The problem is when you forget or don't know that you should trigger the.slow test.
<elopio> Currently, the beta branch takes care of it, but poorly.
<kyrofa> Fortunately the ros-related stuff is pretty obvious. I could see that being an issue with other stuff, of course
<kyrofa> elopio, okay so I could label that test as "slow" today and just run the autopkgtests?
<elopio> kyrofa I haven't pushed anything about slow tests yet. But can do it quickly after my two autopktests prs land.
<elopio> Tomorrow
<kyrofa> Ah ha, okay, sorry! P:
<kyrofa> elopio, perfect
<kyrofa> elopio, no huge rush, just trying to get a clear picture of what I can do
<elopio> kyrofa would you like to comment on he pr "slow" or poke the bot in the chat?
<kyrofa> elopio, definitely. You guys have been busy
<elopio> kyrofa, sorry, I don't understand your answer. So you would like both?
<kyrofa> elopio, haha, we're completely missing each other here, I'm not sure what "both" is :D
<kyrofa> elopio, as I understand it, you're working on two things: daily autopkgtests on the daily PPA to replace the beta PR, and a "slow" filter to not run stuff on Travis. Right?
<ackk> it seems some unittests fail if you have squasfuse installed
<sborovkov> Hi, where is network config file on ubuntu core? (Want to check if interface is using dhcp or not from inside the snap)
<ackk> because of Type=squashfs vs Type=fuse.squashfuse in systemd configs
<elopio> kyrofa right. My question is how would you like to trigger the slow tests in your PR.
<kyrofa> elopio, ohhh
<kalikiana> ackk: what tests are those?
<kalikiana> are you running in a container?
<kyrofa> kalikiana, snapd ones I assume
<kyrofa> elopio, I would rather have something on github than the chat, personally
<elopio> sergiusens it seems I need to have upload permissions to trigger snapcraft PPA tests. I think I will apply to be per-package uploader for snapcraft.
<elopio> kyrofa OK, I will add that to the todo
<kalikiana> elopio: kyrofa Something akin to "Fixes: #1234" maybe? But probably more than just the word "slow"
<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>
<elopio> And probably, I should move the bot here.
<kalikiana> +1
<kyrofa> elopio, yeah something like that. Thinking that through, what would that do exactly: just trigger the autopkgtests?
<kyrofa> elopio, is there a way to filter the autopkgtests? So that I could say "please run exactly THESE slow tests" rather than every single one?
<elopio> Yup, and the autopkgtest will have an env var slow=true
<elopio> Nop, filter specific tests is more work. Maybe next week ;)
<elopio> I can add env vars for suite=snapd filter=ros
<kyrofa> elopio, yeah, that would be cool
<mup> PR snapd#4018 opened: interfaces: fix udev rules for tun <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4018>
<kyrofa> But yeah, just being able to trigger from the commit would be nice. What happens when I push a new commit though, is there a way to remember "oh yeah, I need to run autopkgtests on this too" ?
<kalikiana> ^^ I would've thought you can put it in the PR description
<kalikiana> GitHub reads both comments and the description
<kyrofa> kalikiana, yeah that would work
<kyrofa> elopio, one last question: snapcraft#1591, do we agree that it doesn't buy us anything?
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<Son_Goku> Hey
<Son_Goku> mvo_, do you plan to put simplified highlights in the GitHub releases?
<kalikiana> kyrofa: the better solution was the wait script, no?
<kyrofa> kalikiana, no, it was stuuuupid
<kalikiana> I saw another Pr timing out today
<kyrofa> kalikiana, it just masks _all_ output
<kyrofa> kalikiana, wait, timing out because it took more than ten minutes with no output?
<kyrofa> kalikiana, i.e. stalled?
<kyrofa> Son_Goku, I typically just look at the debian/changelog :P
<Son_Goku> that's too verbose for updateinfo
<Son_Goku> and mvo_ already publishes that as changelog entries for me ;)
<Son_Goku> I guess I'll just make up something
<Son_Goku> but I already have the "full" changes: https://koji.fedoraproject.org/koji/buildinfo?buildID=981596
<sergiusens> elopio for adt? is that a new thing?
<kalikiana> kyrofa: It was `test_stage_rust_with_source_subdir (test_rust_plugin.RustPluginTestCase) test_rust_plugin.RustPluginTestCase.test_stage_rust_with_source_subdir ... The job exceeded the maximum time limit for jobs, and has been terminated.`
<kyrofa> kalikiana, yeah that's different
<kyrofa> kalikiana, we can't fix that
<kyrofa> kalikiana, that's Travis' maximum time for free service
 * Son_Goku sighs
 * Son_Goku wishes we used GitLab
<kyrofa> Son_Goku, I dumped an annoying amount of time trying to see if I could tie github to gitlab ci
<Son_Goku> I did it for one of my projects that's hosted on GitHub still
<sergiusens> wait, not the PR description, we do not want to trigger them before the travis tests are green
<sergiusens> elopio ^
<Son_Goku> basically, set it up to mirror and let it run CI on mirror pulls
<kalikiana> kyrofa: So... how come these work otherwise? Should we be splitting these up?
<sergiusens> should be a comment, and the general practise should be, after the travis tests are green
<kyrofa> kalikiana, if Travis' network barfs momentarily, it'll push some over the edge
<Son_Goku> you can also write a custom webhook service to pull and push automatically
<kyrofa> sergiusens, that's not something the bot can wait for?
<sergiusens> kyrofa maybe
<kyrofa> sergiusens, just talking idealisms here :P
<kyrofa> sergiusens, elopio, kalikiana perhaps we should throw together a quick doc of our ideal, and then see what we can accomplish?
<kyrofa> Rather, what we require, and how ideally it would work
<sergiusens> forum post please
<kalikiana> btw elopio can you please re-review? https://github.com/snapcore/snapcraft/pull/1577 https://github.com/snapcore/snapcraft/pull/1587 kyrofa maybe you can also have a look, a second reviewer is still needed
<mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
<mup> PR snapcraft#1587: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
<kyrofa> sergiusens, alright I'll put that on my TODO after pip/reviews
<sborovkov> How to check if interface is using dhcp on snappy? anyone?
<kalikiana> sergiusens: kyrofa This one needs a re-review from the two of you https://github.com/snapcore/snapcraft/pull/1412
<mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<kyrofa> kalikiana, can you please write a description for snapcraft#1577 ? I'm not sure what problem it's solving/feature it's adding
<mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
<kalikiana> sergiusens: I also addressed your comments on https://github.com/snapcore/snapcraft/pull/1546 though maybe it needs more discussion? Running define and search "locally" wasn't explicitly talked about I think. I don't know if there's potential conerns here
<mup> PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
 * zyga-ubuntu watches catalan news 
<elopio> kyrofa yes, I think print stdout might be good, but not very useful right now. For container tests is probably a must have.
<elopio> sergiusens it's for triggering autopktest on demand, tied to a PPA, not a PR.
<elopio> And the bot can probably wait until Travis is done. Not sure how, but sounds doable. First iteration will be a human poller ð
<kalikiana> kyrofa: Oops, that was meant to have a forum link. I added the link and a summary of the issue now.
<ikey> just seen this. https://git.launchpad.net/~osomon/+git/chromium-snap/commit/?id=0c573c3da6957d868f830fd923728dc13eba4e8d
<ikey> bless
<kalikiana> I read `Clear Santa` there, wondering for a moment what that meant
<ikey> hah
<niemeyer> mvo_: I have a bunch of happy people here about 2.28 :)
<niemeyer> zyga-ubuntu: Review on #3999
<mup> PR #3999: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/3999>
<niemeyer> Will follow on when I find another break
<mvo_> niemeyer: yay! great to hear
<zyga-ubuntu> niemeyer: thank you
<niemeyer> zyga-ubuntu: np, and as I said there, happy to see this moving forward, thanks!
<zyga-ubuntu> niemeyer: thanks, I'll update the PR and will land it shortly
 * zyga-ubuntu is super nervous to see what is going on in catalonia now, worried about friends :/
<zyga-ubuntu> mvo_: 4018 merged now, can be cherry-picked
<mup> PR snapd#4018 closed: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018>
<ackk> niemeyer, finally managed to update https://github.com/snapcore/snapd/pull/3916 with the changes you requested
<mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
<zyga-ubuntu> mvo_: do you need a backport for 2.28?
<zyga-ubuntu> or will you do locally
<kalikiana> FYI going to wrap up for the day in the next 30min
<mvo_> zyga-ubuntu: I can do it locally (cherry-pick). looks like the tests are stuck right now :/
<mvo_> zyga-ubuntu: aha, not the tests the travis display, thanks for merging it
<mup> PR snapd#4016 closed: progress: be more flexible in testing ansimeter <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4016>
<mvo_> zyga-ubuntu: 2.28.2 is uploaded to the PPA with the fix for https://github.com/snapcore/snapd/pull/4018
<mup> PR #4018: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018>
 * zyga-ubuntu hugs mvo_ 
<zyga-ubuntu> thank you :)
<mup> PR snapd#4019 opened: release: snapd 2.28.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4019>
<mvo_> zyga-ubuntu: *thank you* and koza of course
<mvo_> zyga-ubuntu: I get dinner now, once the build finishes  Iwill build a new core
<zyga-ubuntu> ok
<zyga-ubuntu> I'm working on more spread test
<kalikiana> elopio: I got `exceeded the maximum time limit for jobs` twice in a row here... https://github.com/snapcore/snapcraft/pull/1512 :-(
<mup> PR snapcraft#1512: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
 * kalikiana leaving it at that for now
<elopio> kalikiana: yes, that job is now too big. We have to improve it.
<elopio> sergiusens: please land this: https://github.com/snapcore/snapcraft/pull/1598
<elopio> and then this: https://github.com/snapcore/snapcraft/pull/1595
<mup> PR snapcraft#1598: recording: do not crash when snapd is not installed <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1598>
<mup> PR snapcraft#1595: tests: fix the skip of snapd integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1595>
<elopio> sergiusens: and I think we are good to release. Or at least, good to find any other blockers.
<sergiusens> elopio great
<mup> PR snapcraft#1598 closed: recording: do not crash when snapd is not installed <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1598>
<kalikiana> elopio:  Do you have a plan for that yet? It looks to be blocking my PR now
<elopio> kalikiana: we have to review all the tests in that suite. Some can be demoted to unit tests, some are better in the snapd integration suite. Some are just running more steps than needed.
<elopio> I don't think we have any tests that take more than 10 minutes in there, but if we do, they should be tagged as slow.
<elopio> and, if everything fails, ask for money to pay for more travis time.
<kalikiana> I guess by adding another Go integration test I'm just causing the kettle to bubble over...
<kalikiana> Actually no, I'm not even adding one there, just modifying the check
<kalikiana> Hrm
<mvo_> cachio: snapd 2.28.2 is ready in the beta channel for a new round of testing. fixes a tiny issue in the tun udev rules and a bugfix in the dhcp code on core when the IP address changes between dhcp leases
<cachio> mvo_, perfect
<cachio> I'll start now
<mvo_> cachio: thanks a bunch
<mvo_> cachio: I will do a SRU upload based on this one now, I don't see the ppc64 compile error with 2.28.2 in my test ppa so fingers crossed
<cachio> mvo_, perfect
<elopio> snappy-m-o help
<snappy-m-o> All commands
<snappy-m-o>  AutopkgtestGithub
<snappy-m-o>  Trigger the autopkgtests for GitHub pull requests.
<snappy-m-o> â¢ snappy-m-o /autopkgtest - (undocumented)
<snappy-m-o>  Backup
<snappy-m-o>  Backup related commands.
<snappy-m-o> â¢ snappy-m-o /backup - Backup everything.
<snappy-m-o>  ChatRoom
<snappy-m-o>  This is a basic implementation of a chatroom
<snappy-m-o> â¢ snappy-m-o /room join - Join (creating it first if needed) a chatroom.
<snappy-m-o> â¢ snappy-m-o /room leave - Leave a chatroom.
<snappy-m-o> â¢ snappy-m-o /room topic - Get or set the topic for a room.
<snappy-m-o> â¢ *snappy-m-o /room invite
<snappy-m-o> â¢ â¢ Invite one or more people into a chatroom.
<snappy-m-o> â¢ snappy-m-o /room occupants - List the occupants in a given chatroom.
<snappy-m-o> â¢ snappy-m-o /room list - List chatrooms the bot has joined.
<snappy-m-o> â¢ snappy-m-o /room destroy - Destroy a chatroom.
<snappy-m-o> â¢ snappy-m-o /room create - Create a chatroom.
<snappy-m-o>  Flows
<snappy-m-o>  Management commands related to flows / conversations.
<snappy-m-o> â¢ snappy-m-o /flows status - Displays the list of started flows.
<snappy-m-o> â¢ snappy-m-o /flows start - Manually start a flow within the context of the c
<snappy-m-o> alling user.
<snappy-m-o> - snappy-m-o /flows stop - Stop flows you are in.
<snappy-m-o> - snappy-m-o /flows kill - usage: flows_kill [-h] user flow_name
<snappy-m-o> - snappy-m-o /flows show - Shows the structure of a flow.
<snappy-m-o> - snappy-m-o /flows list - Displays the list of setup flows.
<snappy-m-o>  Health
<snappy-m-o>  Core plugin for bot lifecycle and health related commands.
<snappy-m-o> â¢ snappy-m-o /restart - Restart the bot.
<snappy-m-o> â¢ snappy-m-o /uptime - Return the uptime of the bot
<snappy-m-o> â¢ snappy-m-o /status gc - shows the garbage collection details
<snappy-m-o> â¢ **
<snappy-m-o> snappy-m-o /status load - shows the load status
<snappy-m-o> - snappy-m-o /status - If I am alive I should be able to respond to this one
<snappy-m-o> - snappy-m-o /shutdown - usage: shutdown [-h] [--kill] [--confirm]
<snappy-m-o> - snappy-m-o /status plugins** - shows the plugin status
<snappy-m-o>  Help
<snappy-m-o>  Core plugin of help related functions.
<snappy-m-o> â¢ snappy-m-o /apropos - Returns a help string listing available options.
<snappy-m-o> â¢ snappy-m-o /about - Return information about this Errbot instance and version
<snappy-m-o> â¢ snappy-m-o /help - Returns a
<snappy-m-o> help string listing available options.
<snappy-m-o>  Plugins
<snappy-m-o>  Commands to manage the plugins of the bot by chatting.
<nacc> elopio: fun.
<snappy-m-o> â¢ snappy-m-o /repos install - install a plugin repository from the given source or a known public repo (see...
<snappy-m-o> â¢ snappy-m-o /plugin blacklist - Blacklist a plugin so that it will not be loaded automatically during bot sta...
<snappy-m-o> â¢ snappy-m-o /repos search - Searches the repo index.
<snappy-m-o> â¢ snappy-m-o /plugin config - configure or get the configuration / configuration template for a specific
<snappy-m-o> pl...
<snappy-m-o> - snappy-m-o /repos update - update the bot and/or plugins
<snappy-m-o> - snappy-m-o /plugin activate - activate a plugin. [calls .activate() on the plugin]
<snappy-m-o> - snappy-m-o /plugin unblacklist - Remove a plugin from the blacklist
<snappy-m-o> - snappy-m-o /plugin deactivate - deactivate a plugin. [calls .deactivate on the plugin]
<snappy-m-o> - snappy-m-o /plugin reload - reload a plugin: reload the code of the plugin leaving the activation status ...
<snappy-m-o> - snappy-m-o /repos - list the current active plugin repositories
<snappy-m-o> â¢ snappy-m-o /repos uninstall - uninstall a plugin repository by name.
<snappy-m-o>  SnapcraftGithub
<snappy-m-o>  Handle GitHub webhooks from the snapcraft repository.
<snappy-m-o> â¢ snappy-m-o /github build - usage: github_build [-h] pull_request_number
<snappy-m-o> â¢ snappy-m-o /github subscribe - usage: github_subscribe [-h] pull_request_number
<snappy-m-o>  Utils
<snappy-m-o>  Core Errbot utils commands.
<snappy-m-o> â¢ snappy-m-o /render test - Tests / showcases the markdown rendering on your current backend
<snappy-m-o> â¢ snappy-m-o /history - display the command his
<snappy-m-o> tory
<snappy-m-o> - snappy-m-o /whoami - A simple command echoing the details of your identifier. Useful to debug iden...
<snappy-m-o> - snappy-m-o /echo - A simple echo command. Useful for encoding tests etc ...
<snappy-m-o> - snappy-m-o /log tail - Display a tail of the log of n lines or 40 by default
 * nacc wonders why Drone hasn't kicked in yet :)
<elopio> wow, I didn't know it was that long.
<elopio> snappy-m-o /autopkgtest 1583 xenial:amd64
<snappy-m-o> Command "" / " /autopkgtest" not found.
<snappy-m-o>  Did you mean "snappy-m-o /autopkgtest" ?
<elopio> what???
<elopio> snappy-m-o autopkgtest 1583 xenial:amd64
<snappy-m-o> @elopio: I've just triggered your test.
<nothal> snappy-m-o: No such command!
<snappy-m-o> Command ":" / ": No" not found.
<nacc> lol
<elopio> ok, almost there :D
<nacc> This definitely reads like a HAL9000 problem.
<elopio> snappy-m-o subscribe 1583
<snappy-m-o> Command "" / " subscribe" not found.
<snappy-m-o>  Did you mean "snappy-m-o /github subscribe" ?
<elopio> yes, I meant that, but without the slash apparently
<elopio> snappy-m-o github subscribe 1583
<snappy-m-o> You're not allowed to access this command from this user
<elopio> snappy-m-o github subscribe 1583
<snappy-m-o> elopio: I'll send you a message if a test fails in the pull request #1583 (ament plugin: new plugin).
<mup> PR #1583: snap: remove meta/kernel.yaml again <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1583>
<elopio> snapcraft#1583
<mup> PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583>
<mup> PR snapcraft#1601 opened: snapcraft.yaml: don't die if build dir exists <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1601>
<kyrofa> elopio, easiest review on the planet ^^ . Enables building the snap from src
<kyrofa> sergiusens, the snapcraft snap contains both python3.5 and 3.6. Is there a forgotten filter on the 3.5 coming from the snapcraft part?
<mup> PR snapcraft#1602 opened: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602>
<elopio> kyrofa: almost there ^ I have to wait 10 minutes every time I make a typo, so I pushed it for you to review.
<kyrofa> Hahaha
<mwhudson> cjwatson: awesome, thanks
<mwhudson> !
<Peyam> hi
<jdstrand> niemeyer: hey, stgraber has a stop the line issue I think with lxd and 2.28 regression
<Peyam> Im trying to uninstall qucs-s from my distro
<Peyam> nothing happens
<jdstrand> niemeyer: he can give the details
<stgraber> niemeyer: with the latest stable core snap update, the "lxd:lxd" interface is now considered invalid, causing anything that would otherwise be connected to it to be dropped
<Peyam> this is what Happen when I try to uninstall qucs-spice in software center: Detailed errors from the package manager follow:
<Peyam> snapd returned status code 400: Bad Request
<stgraber> I just noticed it when the Ubuntu Core server running the backend for the online LXD demo dropped offline, investigating the reason I saw it rebooted an hour ago for a core snap change and lxd-demo-server couldn't connect to lxd anymore
<stgraber> as a workaround I just upgraded that server to the edge channel for the core snap which gives me a git build of snapd that includes jdstrand's fix
<Peyam> anyone?
<jdstrand> niemeyer: that fix was https://github.com/snapcore/snapd/pull/4004
<mup> PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
<AlbertA> is there a way to specify lightweight checkouts for bzr source types?
<elopio> kyrofa: any idea why ros-example.launch-project --help could be failing on that test? I might be a little tired now, but I don't understand the problem.
<elopio> manually it works.
<kyrofa> elopio, I see no failures at the moment, you must have restarted it. However, I notice that you removed the absolute path. Could that have anything to do with it?
<elopio> ohh, I see  cannot change current working directory to the original directory:
<kyrofa> Oh, in /tmp?
<elopio> yes, we are in /tmp
<kyrofa> How does anything _else_ work?
<elopio> kyrofa: I don't know. Sometimes things work on tmp, sometimes they don't
<elopio> ```/tmp$ ros-example.launch-project --help
<elopio> Usage: roslaunch
<elopio> ```
<elopio> oh well, I have no idea how to paste this from riot to irc. But the idea is that it works manually, when I'm in /tmp. Now trying with the test after chdir to home.
<zyga-solus> jdstrand: so PR 4004 needs to go into 2.28.3?
<mup> PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
<kyrofa> Huh. I can never do stuff out of /tmp
<mup> PR snapcraft#1603 opened: tests: add /snap/bin to PATH in autopkgtests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1603>
<elopio> snappy-m-o autopkgtest 1603 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
<nacc> elopio: nice
<nacc> elopio: although snappy-m-o said that before too :)
<Chipaca> snappy-m-o: dance for me
<snappy-m-o> Command ":" / ": dance" not found.
<Chipaca> snappy-m-o: improve your error messages
<snappy-m-o> Command ":" / ": improve" not found.
<Chipaca> snappy-m-o: ok, ok, so: first, improve your sentience
<snappy-m-o> Command ":" / ": ok," not found.
<nacc> Chipaca: heh
<elopio> you are breaking him. :'(
 * Chipaca knows the singularity will be averted by a misquoted string
<Chipaca> snappy-m-o: how many tests would autopkgtest test if autopkgtest could test tests?
<snappy-m-o> Command ":" / ": how" not found.
 * Chipaca ~> z
<elopio> snappy-m-o autopkgtest 1602 xenial:amd64 xenial:armhf xenial:arm64 artful:amd64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> thank you my friend!
<kyrofa> snappy-m-o, it's nice to see you here. You were so annoying in telegram
<snappy-m-o> Command "," / ", it's" not found.
<elopio> not less annoying here :)
<cjwatson> any reason why people who don't actively need to use its services shouldn't ignore the bot?
<cjwatson> (I already ignore several other bots)
<elopio> this room is full of bots, so I couldn't just let it take the / commands. And apparently, it's not prepared for any of the alternatives.
<elopio> cjwatson: it's a phase, it will pass...
<cjwatson> elopio: sure; what I want to know is does it provide anything useful to people who aren't actively driving it
<cjwatson> if it doesn't I will ignore it
<elopio> cjwtason: you can just ignore until you have to test a snapcraft pull request in arm.
<elopio> snappy-m-o autopkgtest 1595 xenial:armhf xenial:arm64 xenial:amd64
<snappy-m-o> elopio: I've just triggered your test.
#snappy 2017-10-11
<ikey> https://lists.debian.org/debian-devel/2017/08/msg00090.html <- thats a lot of words for "we kinda want snapd working."
<mup> PR snapcraft#1600 closed: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1600>
<mup> PR snapcraft#1595 closed: tests: fix the skip of snapd integration tests in armhf <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1595>
<CreateChange> hello, where can i find an actual list of snap packages
<CreateChange> i am struggling to that end
<zyga-ubuntu> good morning
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: hrm, hrm, looks like we need 2.28.2 and pull in #4004 (nice number). I didn't see this pr and I'm not sure I would have spotted the significance. did we improve the validation in 2.28 or why did it start breaking suddenly?
<mup> PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
<zyga-ubuntu> mvo: hello, I think this is lxd on core (not classic) and we never touched this
<zyga-ubuntu> mvo: so lxd-as-a-snap vs lxd slot provided by core
<zyga-ubuntu> mvo: I think it was never working but perhaps my assumptions are wrong
<zyga-ubuntu> mvo: and it looks untested, maybe we test it in the nightly "important snaps work" thing but I didn't check yet
<zyga-ubuntu> mvo: although, the wording "stopped working" in the lxd bug report seems to imply improved validation
<mvo> zyga-ubuntu: yeah, stgraber indicated it is a regression - anyways, I am fixing now but would love to understand better why we see it now, maybe pawel knows
<zyga-ubuntu> mvo: as far as I understand it interface validation never prevented snaps from refreshing (we juts logged it) and while this has changed rencently it's not 2.28 material
<mvo> zyga-ubuntu: yeah, its not the refresh, its the connection that is no longer working for him
<zyga-ubuntu> mvo: hmm, on Ubuntu 14.04 we only have 2.27.5 available, why is that?
<zyga-ubuntu> mvo: I was trying to understand a failure in 2.27.6 when installed on 14.04
<zyga-ubuntu> mvo: it would fail with Failed to enable unit: File snapd.refresh.timer: No such file or directory
<mvo> zyga-ubuntu: 2.27.6 should be in proposed, also via core re-exec
<mvo> zyga-ubuntu: what failure on trusty is that, is there a forum post?
<zyga-ubuntu> mvo: it's this bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1722075
<mup> Bug #1722075: package snapd 2.27.6~14.04 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 <amd64> <apport-package> <package-from-proposed> <zesty> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1722075>
<zyga-ubuntu> mvo: but I think it's weirder than I initially thought
<mup> PR snapd#4019 closed: release: snapd 2.28.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4019>
<mvo> zyga-ubuntu: is it 2.28.3 material? i.e. should I hold back this release?
<zyga-ubuntu> mvo: no, I think it's not meant to work
<zyga-ubuntu> mvo: but I'm still looking
<zyga-ubuntu> mvo: 17.04 system (upgrade from 16.10) with 14.04 package
<mvo> zyga-ubuntu: thanks for investigating
<mup> PR snapd#4020 opened: tests: add test for lxd interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/4020>
<mwhudson> __chip__: my snapcraft pr is only about half way down the list, they must be slacker than you guys :)
<mwhudson> zyga-ubuntu: so um i guess we should package 2.28.2 for debian?
<zyga-ubuntu> mwhudson: yes, I think so
<zyga-ubuntu> mwhudson: btw, interesting observation
<zyga-ubuntu> mwhudson: recent 9.2 stable release of debian had brand new flatpak
<zyga-ubuntu> mwhudson: perhaps we could do the same
<mwhudson> zyga-ubuntu: good thing i don't have anything at all to do between now and artful release, eh?
<mwhudson> zyga-ubuntu: hmm
<mwhudson> zyga-ubuntu: although 2.28 should work ok via reexec thanks to the graceful apparmor stuff you did
<zyga-ubuntu> mwhudson: I need to fix my VM box (reinstall the OS on new drive and then copy data over)
<zyga-ubuntu> mwhudson: yep but we could try to get it into 9.3, if there is one
<zyga-ubuntu> mwhudson: we could pick the right stable release and go along with it
<mwhudson> yeah that'd be good
<zyga-ubuntu> hmm, has the new snap pack landed?
 * zyga-ubuntu looks
<kalikiana> o/
<mup> PR snapd#4015 closed: run-checks: use nakedret to check for naked returns on long functions <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4015>
<mup> Issue snapcraft#1604 opened: Homebrew still on snapcraft 2.33 <Created by jedvardsson> <https://github.com/snapcore/snapcraft/issue/1604>
<zyga-ubuntu> homebrew?
<zyga-ubuntu> wow
<zyga-ubuntu> and mup is still using wrong URLs for github issues
<__chip__> zyga-ubuntu: snap pack is on master, if that's your q
<zyga-ubuntu> yep, that's what I wanted, thank you
<mup> Issue snapcraft#1605 opened: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <Created by wmmihaa> <https://github.com/snapcore/snapcraft/issue/1605>
<mvo> cachio: good morning. we have a new 2.28.3 that fixes an issue with the lxd interface in the beta channel
<mup> PR snapd#4021 opened: release: snapd 2.28.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4021>
 * zyga-ubuntu -> tea
<zyga-ubuntu> spread test for content looks good; I fixed some issues and found one missing case that is now handled (source bind mount)
<zyga-ubuntu> oh, chipaca is gone?
<zyga-ubuntu> jdstrand: hello
<zyga-ubuntu> jdstrand: not sure if you are up yet but I'd like to review and land https://github.com/snapcore/snapd/pull/3965
<mup> PR #3965: interfaces/mount: add support for parsing x-snapd.{mode,uid,gid}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
<zyga-ubuntu> jdstrand: it has one +1 already and I could use a review from you next
<Chipaca> pedronis: are you really around?
<Chipaca> i guess it's early even if he were
<zyga-ubuntu> Chipaca: o/
<zyga-ubuntu> thank you for the response on the froum
<zyga-ubuntu> how are you feeling
<Chipaca> zyga-ubuntu: better today, thank you
<Chipaca> i'll be off to physio in a bit, that also helps
<mup> PR snapcraft#1606 opened: kbuild plugin: if the parts build dir already contains a .config file, use it as the base config <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1606>
<Chipaca> ok, off to physio
<mup> Issue snapcraft#1604 closed: Homebrew still on snapcraft 2.33 <Created by jedvardsson> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1604>
<ackk> it seems my snap is not able to resolve hostnames, but it has the 'network' interface (and it's connected). how can I debug what's going on?
<mup> Issue snapcraft#1605 closed: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <Created by wmmihaa> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1605>
<kalikiana> ackk: I find running it in devmode helpful in case something's being blocked by apparmor because you'll get log messages
<ackk> kalikiana, so, it seems it's trying to access stuff under hostfs, like resolv.conf or os-release
<ackk> but it shouldn't really need that
<ackk> I mean, having the "network" plug it should have connectivity?
<popey> As a user, I have a snap which I think broke in 2.28. To confirm, how do I easily go back to core 2.27?
<kalikiana> popey: `snap revert` gets you back to the previous revision, you can also do `snap revert core --revision=2925` for a specific one, but afair it must be one of the last three you had on your system
<zyga-ubuntu> popey: can you share more information
<popey> hiri is broken on my nvidia laptop
<popey> works on my intel laptop
<popey> it _used_ to work
<popey> I am trying to figure out if hiri broke their snap or we did
<kalikiana> ackk: Yes. Probably something's trying to be smart. Although /etc/os-release should be accessible just fine, other things may be blocked
<zyga-ubuntu> popey: can you show any apparmor denials
<zyga-ubuntu> popey: and confirm that it works on 2.27.x
<popey> uh
<popey> https://forum.snapcraft.io/t/apparmor-denials-for-hiri-after-updates/2432
<zyga-ubuntu> popey: also can you run hiri from command line with SNAP_CONFINE_DEBUG=yes
<popey> I asked how I can go back to 2.27 :D
<ackk> kalikiana, I see stuff like Oct 11 10:36:48 snap kernel: [2414545.321369] audit: type=1400 audit(1507718208.501:1586): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/etc/nsswitch.conf" pid=5797 comm="lxc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga-ubuntu> ah, wait
<popey> Tell me that and I will :)
<ackk> kalikiana, I doubt lxc is opening that file explicitely
<zyga-ubuntu> popey: that's all I need
<zyga-ubuntu> thank you
<mup> PR snapd#4021 closed: release: snapd 2.28.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4021>
<kalikiana> ackk: does lxd have no network? if that's the case you might want to `snap disable lxd; snap enable lxd`. I've seen it some time ago and that was my work-around
<zyga-ubuntu> popey: can you please help me out
<zyga-ubuntu> popey: I need you to do this:
<kalikiana> ackk: and, put those logs in a bug report ideally
<zyga-ubuntu> popey: sudo /usr/lib/snapd snap-discard-ns hiri #  (correct the snap name if needed)
<ackk> kalikiana, disable/enable didn't work
<ackk> kalikiana, the snap has the network plug connected
<zyga-ubuntu> popey: SNAP_CONFINE_DEBUG=yes snap run --shell hiri
<ackk> kalikiana, lxd does have network, lxc doesn't seem to
<popey> alan@hal:~$ sudo /usr/lib/snapd snap-discard-ns hiri
<popey> sudo: /usr/lib/snapd: command not found
<zyga-ubuntu> popey: sudo SNAP_NAME=hiri strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri -o snap-confine.strace
<ackk> kalikiana, but lxd runs unconfined
<zyga-ubuntu> popey: popey sorry, /usr/lib/snapd/snap-discard-ns hiri
<zyga-ubuntu> (missing /)
<popey> kk
<kalikiana> ackk: I'm not following... `lxc` is just the command line tool of lxd. What exactly is not working?
<ackk> kalikiana, if I run lxc image list ubuntu:
<zyga-ubuntu> popey: snap-confine should never access /sys/module/nvidia_modeset/uevent so I'm curious what is going on
<ackk> kalikiana, that fetches the simplestreams index from the image server. that fails
<zyga-ubuntu> popey: also paste snap version here (I only care about the distrO)
<ackk> kalikiana, a curl of the same url from cmdline of course works
<popey> zyga-ubuntu: hang on
<kalikiana> ackk: Can you tr `lxc image list --debug --verbose ubuntu:` and see if it gives some diagnostics?
<popey> http://paste.ubuntu.com/25719311/
<popey> alan@hal:~$ snap version
<popey> snap    2.28.1
<popey> snapd   2.28.1
<popey> series  16
<popey> ubuntu  16.04
<popey> kernel  4.10.0-35-generic
<popey> zyga-ubuntu: ^ What next?
<ackk> kalikiana, just the same error: Get https://cloud-images.ubuntu.com/releases/streams/v1/index.json: lookup cloud-images.ubuntu.com: no such host
<elopio> snappy-m-o autopkgtest 1603 xenial:amd64 xenial:armhf xenial:arm64 artful:amd64 zesty:arm64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1602 xenial:amd64 xenial:armhf zesty:amd64
<snappy-m-o> elopio: I've just triggered your test.
<zyga-solus>  popey: please exit the shell
<zyga-solus> popey: and run strace command again outside
<popey> ok
<zyga-solus> sorry for the confusing input
 * zyga-solus fixed his T430 just now 
<popey> zyga-solus: are you expecting an strace file, because I have none, just spat to terminal
<popey> zyga-solus: http://paste.ubuntu.com/25719391/
<zyga-solus> popey: perhaps put -o just after strace
<zyga-solus> but let me read this
<kalikiana> ackk: Maybe ask in #lxc-dev I'm running out of ideas
<ackk> kalikiana, ok, thanks
<zyga-solus> popey: sudo SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /snap/core/current/usr/lib/snapd/snap-exec hiri.hiri
 * zyga-solus is walking in the dark here but let's keep our minds open
<popey> zyga-solus: http://paste.ubuntu.com/25719424/
<zyga-ubuntu> oooh
 * zyga-ubuntu found a bug
<zyga-ubuntu> (elsewhere)
<zyga-ubuntu> *man*
<zyga-ubuntu> popey: when you ran this, did you see any denial?
<popey> zyga-ubuntu: [Wed Oct 11 12:11:09 2017] audit: type=1400 audit(1507720265.562:197783): apparmor="DENIED" operation="file_mmap" profile="snap.hiri.hiri" name="/snap/core/3017/usr/lib/snapd/snap-exec" pid=26893 comm="snap-exec" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0
<popey> thats the only denial when i re-ran your strace above
<zyga-ubuntu> hmmm, that's weird
<zyga-ubuntu> it says that the profile disallows running snap-exec
<zyga-ubuntu> ah
<zyga-ubuntu> sorry
<zyga-ubuntu> ok
<zyga-ubuntu> re-run that with snap-exec path of just /usr/lib/snapd/snap-exec
<zyga-ubuntu> (so everything the same but with different command at the end
<popey> cannot snap-exec: cannot parse revision "": invalid snap revision: ""
<popey> alan@hal:~$ sudo SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /usr/lib/snapd/snap-exec hiri.hiri
<popey> ^ was the command
<zyga-ubuntu> right
<zyga-ubuntu> after sudo add SNAP_REVISION=... where ... is the real revision of hiri
<zyga-ubuntu> (little by little)
<popey> ok
<popey> alan@hal:~$ sudo SNAP_REVISION=15 SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /usr/lib/snapd/snap-exec hiri.hiri
<popey> seems to be just sat there
<zyga-ubuntu> look at denials please
<popey> nothing
<Chipaca> zyga-ubuntu: what does snap-confine.strace do?
<zyga-ubuntu> it's just a file name
<Chipaca> d'oh
<Chipaca> so, jd.strand shared a magic strace of magics
<Chipaca> strace -o /tmp/trace -D -f -vv -e '!_newselect,select,clock_gettime' -- /usr/bin/snap run <thing>
<Chipaca> the filtered-out thing is the important bit imho
<zyga-ubuntu> popey: ls -ld /sys/module/nvidia/version
<Chipaca> without that strace gets bamboozled by go
<Chipaca> (or by our unusual usage of go)
<popey> -r--r--r-- 1 root root 4096 Oct  2 20:44 /sys/module/nvidia/version
<zyga-ubuntu> popey: ok
<zyga-ubuntu> I'm lost
<zyga-ubuntu> snap list --all
<zyga-ubuntu> popey: and please revert to one of the older core revisions you have on your system (the previous one)
<zyga-ubuntu> popey: then discard the namespace and try again
<popey> https://pastebin.canonical.com/200343/ is my snap list --all
<popey> (sorry, contains private snaps so not publicly sharing)
<zyga-ubuntu> kk
<popey> so core 2898 which is 16-2.27.6 i guess?
<Chipaca> popey: don't forget to stand on the _left_ side of your _right_ foot while reverting, and the order is: adopt stance, start whistling tune, execute commands, leave stance, stop whistling
<popey> <3
<zyga-ubuntu> popey: core                  16-2.27.6                    2844  canonical         core,disabled
<zyga-ubuntu> popey:  try tihs one
<zyga-ubuntu> popey: actually
<zyga-ubuntu> before you do that
<zyga-ubuntu> popey: try Chipaca's advice on how to strace
<Chipaca> need i mention that the tune is rms's free software tune, backwards and in a minor key?
<flexiondotorg> zyga-ubuntu: popey is reverting to 2898.
<flexiondotorg> His irc client is a snap and froze. Which is why he is not replying right now.
<popey> phew!
 * Chipaca ROTBL
 * flexiondotorg end popey-proxy mode
<popey> ok, interestingly my irc clent (irccloud-desktop) locked up during 'phase 2' whatever that is, but carried on after the rollback which is neat. well done team :)
<popey> installed:   16-2.27.6 (2898) 85MB core
<zyga-ubuntu> flexiondotorg: interesting!
<popey> Ok, hiri now works fine atfer rolling back to 2.27
<zyga-ubuntu> popey: try hhir now
<zyga-ubuntu> popey: ok
<zyga-ubuntu> popey: please do this:
<zyga-ubuntu> popey: send me all the apparmor profiles from /etc/apparmor.d/snap.core.*.usr.lib.snapd.snap-confine
<popey> zyga-ubuntu: sent
<popey> (email)
<zyga-solus> thanks
<zyga-solus> let me look
 * zyga-solus walks between kitchen and office
<zyga-ubuntu> popey: ok so the working one is 2898
 * zyga-ubuntu looks
<zyga-ubuntu> popey: it makes no sense :/ it looks like the new profile is more forgiving actually
<popey> zyga-ubuntu: we have confirmed that this is also the case with a completely different snap, on another nvidia machine which is 17.10
<popey> reverting to core 2898 made the snap work there too.
<zyga-solus> popey: it looks like nvidia is affected in general
<popey> also an opengl snap
<zyga-solus> not specific to hiri
<popey> yes
<zyga-solus> now would be a good time for me to have easy way to use nvidia :/
<zyga-solus> (which I don't)
<popey> This is not the first time this problem has bitten us.
<zyga-solus> I understand, we don't have any testing of nvidia AFAIK
<popey> Indeed, wasn't pointed at you. It's common across the company.
<zyga-solus> I meant me for debugging, I think we need to fix our release process to include simple "works / not works" opengl testing on intel, nvidia and amd GPUs
<popey> I happen to be lucky enough to have two laptops side by side, nvidia and intel, so pick this stuff up. Not everyone has that luxury
<zyga-solus> or just nvidia for a start
<zyga-solus> popey: I have 3 but all intel
<popey> I understand you can spin up a machine in AWS with a GPU
<popey> There's your problem :)
<zyga-solus> popey: with ubuntu kernel?
<popey> Hm, good question. I am not sure.
<zyga-solus> probably not
 * zyga-solus looks on ebay
<popey> separately, will I be stuck on rev 2898 now I reverted to it?
<popey> or will the next update push me forward again?
<zyga-solus> popey: not sure, I think refresh vs revert but not sure if this is implemented
<popey> Shall I file a bug in snapd for this?
<popey> Feels somewhat critical
<zyga-solus> popey: no, the forum thread is enough
<popey> ok
<popey> zyga-solus: do you need remote access to an nvidia machine (I have a desktop here I can slap 16.04 on)?
<zyga-solus> popey: that wold help
<popey> lemme dig it out, one mo
<zyga-solus> popey: thank you
<zyga-ubuntu> mvo: what is the status of your nvidia box?
<zyga-ubuntu> mvo: I have a laptop but unused, I could try to boot it from live media or maybe swap HDD and install that way (it's not used by me and has other os)
<mvo> zyga-ubuntu: I have a nvidia card somewhere I don't use it usually, but I can plug it in
<zyga-ubuntu> mvo: if that fails I'll try to install ubuntu on mine
<mvo> zyga-ubuntu: let me try to find it, any opengl game will do?
<zyga-solus> mvo: yes
<zyga-solus> mvo: or just try hiri
<mvo> zyga-ubuntu: what did change in this area recently? could it be snap-confine?
<zyga-solus> mvo: I was looking at the diff between the snap-confine profiles and we did change various things for how the lib directory is called in solus and elsewhere
<zyga-solus> mvo: but we never ever touch the file we get the denial on
<zyga-solus> mvo: so I think something else may be broken
<zyga-solus> mvo: and we just see the weird side effect
<mvo> zyga-solus: I see  - I wonder how we can test this in an integration test
<zyga-solus> mvo: modprobe nvidia (maybe) if it sticks
<mvo> zyga-ubuntu: what file gets the denials
<zyga-solus>  [ 2879.277628] audit: type=1400 audit(1507710260.432:1680): apparmor=âDENIEDâ operation=âopenâ profile="/snap/core/3017/usr/lib/snapd/snap-confine" name="/sys/bus/pci/drivers/nvidia/uevent" pid=13789 comm=âsnap-confineâ requested_mask=ârâ denied_mask=ârâ fsuid=0 ouid=0
<zyga-solus> not sure how this happens
<zyga-solus> hold on, I think I know
<zyga-solus> jdstrand said that nvidia is not in sysfs the regular way and added a hack for supporting udev tagging, remember?
<zyga-solus> one sec
<zyga-solus> b17d5ba8d46c269dbaba08c0484a13e1e1c9e9e7
<zyga-solus> mvo: it is this patch
<mvo> zyga-solus: strange that denial, I add the card now, bbiab (need to open the machine etc)
 * Chipaca needs to reboot, brb
<zyga-solus> k
<zyga-solus> mvo: I'm making a patch
<zyga-solus> popey: still there?
<zyga-solus> popey: refresh to stable again
<popey> ok
<zyga-solus> popey: and edit the profile in /etc/apparmor.d/
<zyga-solus> popey: the one for snap-confine on revision 3017 (if I recall correctly)
<zyga-solus> anyway, the latest one
<zyga-solus> popey: ls /sys/bus/pci/drivers/nvidia/
<zyga-solus> popey: in the file you are editing go to line 6 (so inside the { } spanning the whole file)
<zyga-solus> popey: and add this line(s) (waiting for your ls output)
<zyga-solus> popey: /sys/bus/pci/drivers/nvidia/uevent r,
<zyga-solus> popey: then save the file and use "apparmor_parser -r /etc/apparmor.d/snap.core.3017.usr.lib.snapd.snap-confine" to re-load
<zyga-solus> popey: then start hiri again
<popey> ok. took a while to get to refresh core. updated now
<zyga-ubuntu> popey: thank you
<popey> alan@hal:~$ ls /sys/bus/pci/drivers/nvidia/
<popey> 0000:01:00.0  bind  module  new_id  remove_id  uevent  unbind
<zyga-ubuntu> ok
<zyga-ubuntu> add the uevent line as I said, reload the profile and start hiri
<zyga-ubuntu> we'll iterate till it works
<popey> ok
<popey> so added that one uevent r line
<popey> hiri still core dumps
<zyga-solus> denials?
<popey> [Wed Oct 11 13:09:07 2017] audit: type=1400 audit(1507723743.250:198339): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17939/mounts" pid=17939 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<popey> [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.825:198340): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/etc/" pid=17939 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<popey> [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.833:198341): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17953/mounts" pid=17953 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<popey> [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.837:198342): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17954/mounts" pid=17954 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<zyga-solus> nothing else? can you connect the mount interfaces
 * ogra_ sets +q on popeybot 
<ogra_> :P
<zyga-solus> or try a some simple opengl snap/
<popey> i have another gl one that broke
<popey> https://www.irccloud.com/pastebin/saHHCGu4/
<popey> (for ogra)
<ogra_> heh
<popey> https://www.irccloud.com/pastebin/1NEBw33c/
<popey> and another
<ogra_> you can ignoe inet6
<zyga-ubuntu> popey: works?
<popey> no
<popey> all broken
<popey> https://www.irccloud.com/pastebin/FZfuNsJx/
<ogra_> (and we shoudl really quieten it, they should not be printed if there is no v6 network configured)
<zyga-ubuntu> ok
<mvo> zyga-solus: \o/ for making a patch, let me know once I can test something
<zyga-ubuntu> mvo: still at the /o\ stage, I need to wrap my head around this, I assumed a simple tweak would do but I think we tag things incorrectly somewhere and there are devices missing in the namespace
<zyga-ubuntu> mvo: so no patch yet
<zyga-solus> popey: can you try a richer patch please
<zyga-solus> +    # See https://github.com/snapcore/snapd/commit/b17d5ba8d46c269dbaba08c0484a13e1e1c9e9e7
<zyga-solus> +    /sys/bus/pci/drivers/nvidia/uevent r,
<zyga-solus> +    /dev/nvidia[0-9]* r,
<zyga-solus> +    /dev/nvidiactl r,
<zyga-solus> +    /dev/nvidia-uvm r,
<zyga-solus> popey: reload the profile and watch journalctl -f
<zyga-solus> popey: then restart hiri
<Chipaca> what was the generic name, on the phone, of things that mediated access to things? like the file manager
<zyga-solus> Chipaca: media hub
<ogra_> Chipaca, content-hub
<popey> ok
<zyga-solus> ah
<zyga-solus> sorry :)
<ogra_> but media-hub was clÃ¶ose enough ;) (same thing. just for media files)
<Chipaca> right, the content hub was one of them, wasn't there a name for all of them?
<zyga-solus> trusted helper?
<ogra_> trusted helper was the equivalent to snap intefaces
<zyga-solus> well, not really
<zyga-solus> we will use trusted helpers in snapd (we already use some)
<popey> still broken..
<ogra_> (to allow direct accesds to bits ... like location or so)
<zyga-solus> anyway, distraction
<zyga-solus> popey: any denials?
<zyga-solus> did you reload the profile?
<zyga-solus> popey: try discarding the namespace (just to be sure, I don't think we need to)
<popey> http://paste.ubuntu.com/25719780/
<popey> i did reload the profile
<popey> ^ me running hiri, goxel and ohmygiraffe
<popey> tried discarding namespace too, also fails
<zyga-solus> popey: go to /sys/fs/cgroup/devices
<zyga-solus> popey: what do you have there
<popey> lots of files, anything in particular you're interested in?
<zyga-solus> popey: snap.*
<popey> http://paste.ubuntu.com/25719806/
<zyga-solus> great
<zyga-solus> go to hiri
<zyga-solus> then show devices.allow please
<popey> it's an empty file
<popey> --w------- 1 root alan 0 Oct 11 13:23 devices.allow
<zyga-solus> cat it
<popey> alan@hal:/sys/fs/cgroup/devices/snap.hiri.hiri$ sudo cat devices.allow
<popey> cat: devices.allow: Invalid argument
<zyga-solus> aww, drat
<zyga-solus> ok, one sec
<zyga-solus> darn
<zyga-solus> we don't log that
<zyga-solus> so
<zyga-solus> it's the oldest part of snap-confine
<zyga-solus> and one I barley touched
<zyga-solus> so it doesn't log anything useful
<zyga-solus> I'm afraid we need some build/edit cycles
<Chipaca> is this something breaking in 2.28, or is it broken before that?
<popey> am installing 17.10 on an nvidia machine here for you if that helps
<zyga-solus> Chipaca: 2.28
<Chipaca> zyga-solus: is it a blocker?
<zyga-solus> popey: yes, very much
<zyga-solus> Chipaca: yes
<Chipaca> zyga-solus: am I sad?
 * Chipaca is sad
<Chipaca> popey: thank you for spotting it though
<popey> np
<Chipaca> zyga-solus: what aren't we testing?
<Chipaca> do we need to have an nvidia 16.04 box as part of qa?
<zyga-solus> Chipaca: absolutely
<Chipaca> ok
<Chipaca> how do we do this?
<zyga-solus> Chipaca: I'd just make sure that cachio has a nvidia box to test on
<zyga-solus> Chipaca: and then try external target
<Chipaca> cachio: you're about to become a gamer dude
<zyga-solus> Chipaca: and ensure we run opengl snaps as a part of that
<Chipaca> :-D
<popey> (don't forget AMD) :)
 * Chipaca forgets AMD because it sucks
 * Chipaca looks for a fight
<zyga-solus> popey: we have no amd-specific code
<popey> shocked emoji
 * Chipaca stops looking for a fight and starts looking for tea
 * zyga-solus is starving, I need to break for food now
<mvo> zyga-solus: took a little bit, had to tweaks various things in artful and had the wrong nvidia driver (how is a user supposed to know twhich of nvidia-NNN he/she needs?). anyways, I can test things now too
<zyga-ubuntu> mvo: I think the driver package makes that
<zyga-ubuntu> mvo: did you install the proprietary driver?
 * kalikiana moving to a coffee shop, back in a bit
<zyga-ubuntu> mvo: I'd like to know which devices are in the cgroup
<zyga-ubuntu> popey: can you cat devices.list
<zyga-ubuntu> popey: on your existing machine
<popey> yes
<popey> http://paste.ubuntu.com/25719909/
<zyga-ubuntu> popey: so
<zyga-ubuntu> popey: it looks like we don't do nvidia part correctly
<zyga-ubuntu> nvidia is 195
<zyga-ubuntu> I'll update the forum
<zyga-ubuntu> popey: what do you have in "ls -l /dev/nvidia*"
<zyga-ubuntu> popey: we may be able to test a fix on your system with some shell
<popey> https://www.irccloud.com/pastebin/AindIubf/
<popey> i have a desktop machine here ready for you
<popey> pm...
<zyga-ubuntu> popey: ok, let me ssh in and play,
<zyga-ubuntu> popey: but I see what is broken
<zyga-ubuntu> not sure why yet
<popey> kk
<popey> needs an update, so apt dist upgrade while you do other things :)
 * popey gets quick bite to eat
<popey> will listen out for pings
<tai271828> hi, question: do we have kernel snap that is corresponding to "proposed kernel"? especially for pi2 kernel.   may anyone know and please tell me the answer? (googled "pi2 kernel snap" and I think the answer is "no")
<ogra_> tai271828, proposed as in the proposed deb archive ?
<tai271828> ogra_: yes, and I just found this https://launchpad.net/pi2-kernel-snap
<ogra_> tai271828, the beta and candidate channels get uploads in sync with the proposed deb
<tai271828> ogra_: hmmm, cool, then I must misunderstand something, thanks for clarifying
<tai271828> ogra_: thanks!
<ogra_> tai271828, note that the pi2 kernel in stable is actually stuck due to the missing ability to upgrade gadgets on devices ... typically the snaps woould move on from beta/candidate to stable (but without working gadget upgades they wouldnt boot, the binary blobs are to old in the stable gadget currently)
<tai271828> ogra_: got it, thanks for the useful information.
<ogra_> :)
<mup> PR snapd#4022 opened:  interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4022>
<slangasek> hi, what has changed between core snap 2898 and core snap 3017?  Because this has broken the subiquity server image, /var/lib/snapd/seed doesn't seem to get processed correctly at boot and so subiquity doesn't start
<mvo> slangasek: there were quite a few changes, do you have more details in what way things break? what can I do to reproduce?
<slangasek> mvo: you can download and boot http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/artful-live-amd64.iso
<mvo> slangasek: thanks, downloading now
<slangasek> mvo: the only thing visible in the systemd journal is that snap-confine can't find libudev.so.1
<mvo> slangasek: any denials in dmesg?
<ogra_> mvo, systemd from the PPA out of sync with the distro llibudev ?
<slangasek> mvo: apparmor="DENIED" on /rofs/etc/ld.so.cache
<ogra_> wow, where would /rofs come from ?
<slangasek> it's a live image
<ogra_> ah
<slangasek> so root is an overlayfs + squashfs
<slangasek> and the real path is not the apparent path
<slangasek> so I guess one of the changes was to confine snap-confine itself?
<slangasek> mwhudson: ^^ so, that's what's going on with the latest image
<mvo> slangasek: we always had snap-confine confined
<ogra_> we do have a patch to systemd in the PPA that makes the core snap have a differentlly versioned libudev package thoough
<ogra_> mvo, that should have gone into a live-build hook instead i guess
<ogra_> (til the actual systemd SRU lands)
<slangasek> oh
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<slangasek> indeed, there's also a denial for /rofs/lib/x86_64-linux-gnu/libudev.so.1.6.6
<slangasek> which is probably the real one
<slangasek> so, should we be extending the apparmor profile to account for /rofs as a special case?
<ogra_> given that the fix is actually something that should rather live in /etc/sysctl.d, we shoulld probably just rework it to come either via a llive-build hook or via ubuntu-coe-config
<ogra_> oh
<ogra_> that perhaps as well :)
<slangasek> jdstrand: ^^ ping
<zyga-ubuntu> popey: I rebooted your machine, let's hope it re-connects
<popey> i see black screen
<popey> with a mouse cursor
<popey> (It could just be slow)
<popey> it's back, desktop up
<mvo> ogra_: that systemd package can be removed from the ppa
<mvo> ogra_: let me kill it now
<ogra_> +1
<kalikiana> sliff
<mvo> ogra_: the actual fix is in the core build git
<mup> PR snapd#4023 opened: tests: fix econnreset scenario when the iptables rule was not created <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4023>
<ogra_> ah, right
<slangasek> mvo, ogra_: does removing this systemd package from the ppa relate to the apparmor denials, or something else?
<ogra_> slangasek, just to "out of sync with the archive regarding versioning" ... i think the denial actually requires the addition oof /rofs
<slangasek> ok
<slangasek> I'll chase jdstrand in person, thanks :)
<mvo> slangasek: what I wonder about is why this worked before. we always had an apparmor profile around snap-confine and never allowed /ro
<ikey> ok further to my slightly skewiff snapcraft forum post, i need to create a snap without a core dependency, and apparently "bare" is the way for this. are any ubuntuisms expected of my snap, and is it possible for me to properly have my /lib64 /usr/lib64 /usr/bin etc directories present in my snap?
<mup> PR snapcraft#1606 closed: kbuild plugin: if the parts build dir already contains a .config file, use it as the base config <bug> <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1606>
<jdstrand> mvo: slangasek tracked me down. I suspect that the compiler options changed and libudev isn't being linked in statically
<ikey> i want to make a decent steam snap and ironically that means not using ubuntu for the base of it, hence the query..
<jdstrand> mvo: I have a vague recollection that zyga touched this semi-recently (I could be wrong). We have traditionally statically linked in libseccomp and libcap (and honestly, libudev). not sure why this would've changed...
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia0 195:0
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidiactl 195:255
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia-uvm 247:0
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia0 195:0
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidiactl 195:255
<zyga-ubuntu> DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia-uvm 247:0
<zyga-ubuntu> asdadsa
<ikey> lol
<zyga-solus> popey:
<popey> zyga-ubuntu: i see ohmygiraffe
<zyga-solus> popey: is there a giraffe on your screen?
<popey> yes
<zyga-ubuntu> popey: \o/
<jdstrand> mvo: slangasek mentioned udev as the denial. I see /rofs/etc/ld.so.cache referenced in backscroll. that might be related-- not sure when ld.so will be used if all libs are statically linked. if so, we need to add that to the profile
<slangasek> jdstrand: fwiw I just checked, and linkage of snap-confine is not different between the two images
<slangasek> although, do I need to look at snap-confine within the core snap itself?
<slangasek> sec, let me nest my loop mounts one level more
<jdstrand> mvo (cc slangasek): however, I wouldn't expect snaps to work *today* on a live session, so this isn't a regression, is it?
<jdstrand> slangasek: you would need to look in core, yes
<jdstrand> (cause eof reexec)
<slangasek> jdstrand: looked inside core_2898; snap-confine in there is also dynamically linked against libudev
<zyga-solus> popey: is hiri running?
<popey> no
<slangasek> jdstrand: and this is a regression for subiquity specifically, which somehow *did* work before the core update, even if other snaps apparently do not
<popey> zyga-ubuntu:
<popey> its slowly loading
<slangasek> jdstrand: (we had it working in the 17.04 image, and it was working in artful dev until today)
<zyga-solus> ah
<popey> yes, i see hiri now
<zyga-solus> popey: wooot
<zyga-solus> popey: so we have a fix
<popey> yay
<jdstrand> slangasek: I wonder why subiquity is (now?) using a snap...
<jdstrand> I mean, why is snap-confine running at all?
<jdstrand> cause, if we fixed this issue and made snap-confine be happy, it'll then launch something that will be sad (if in strict mode)
<slangasek> jdstrand: that is also not new - it was a) let us move faster with subiquity during release freeze, b) dogfood snaps, c) make subiquity something that anyone can download into a maas ephemeral environment
<slangasek> it's a classic snap, not strict
<jdstrand> ok. I find this quite curious. what happens if you allow /rofs/etc/ld.so.cache?
<jdstrand> I guess you just need read?
<slangasek> I expect so
<slangasek> allow it> by editing the apparmor profile in the live env?
<jdstrand> slangasek: yes
<jdstrand> grab the profile that corresponds to the core snap
<jdstrand> slangasek: use snap list to get the revision of core. then edir /etc/apparmor.d/snap.core.<rev>.usr.lib.snapd.snap-confine
<jdstrand> slangasek: if that is ro, just cp /snap/core/current/etc/apparmod.d/usr.lib.snapd.snap-confine
<jdstrand> slangasek: then modify and load that copy
<slangasek> jdstrand: well, thus far 'snap list' says nothing, because things fail early enough that the seed is never fully processed AFAICS.  But yeah, I'll dig, thanks
<jdstrand> zyga-solus: fyi, rofs might actually be a future consideration for snap-confine.d (ie, snapd detects it is in a live image, adds some policy)
<jdstrand> zyga-solus: all future, nothing to do now
<zyga-solus> jdstrand: hello
<zyga-solus> jdstrand: future as in in the next 6 days for artful release?
<zyga-solus> jdstrand: we need your review on https://github.com/snapcore/snapd/pull/4022
<mup> PR #4022:  interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4022>
<jdstrand> slangasek: you don't need snp listist then, just copy out of current like I said
<zyga-solus> jdstrand: it's an urgent fix for 2.28.x
 * jdstrand nods
<zyga-solus> mvo, jdstrand: if we need this rofs support for the artful release we should know and do this now so that it's ready
<zyga-solus> (on time)
<mup> PR snapcraft#1588 closed: lxd: use SUDO_UID for ID mapping <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1588>
<zyga-solus> slangasek, jdstrand: if you are sprinting now and make this decision please tell mvo and me ASAP
<slangasek> zyga-solus: we are sprinting but are in different rooms ;)
<mup> PR snapcraft#1348 opened: repo: setup a foreign arch and sources <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348>
<mup> PR snapcraft#1382 opened: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<slangasek> aaaand now I've booted this image again and the problem did not reproduce. yay?
<ogra_> lol
<slangasek> so possibly racy on top of everything
<mup> PR snapd#4024 opened: debian: fix replaces/breaks for snap-xdg-open (thanks to apw!) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4024>
<zyga-solus> slangasek: not yay
<zyga-solus> slangasek: mvo said it doesn't work for him
<slangasek> zyga-solus: snapd doesn't work, or reproducing doesn't work?
<slangasek> I just rebooted and reproduced the failure again
<mvo> slangasek: I had downloaded the image, booted and it failed
<mvo> slangasek: let me try again
<mvo> slangasek: but yeah, looks racy
 * kalikiana food
<mvo> zyga-*: http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/artful-live-amd64.iso
<jdstrand> mvo, zyga-solus: reviewed 4022
<mvo> jdstrand: what shall we do about the /ro issue from slangasek? add support for that too?
<mvo> jdstrand: I'm still puzzled how this evar worked?
<slangasek> jdstrand: so if I edit the profile under /etc/apparmor.d, apparmor_parser -r, and systemctl restart snapd, snapd overwrites the profile again and loads the original
<slangasek> jdstrand: so I'm not sure how I should test the result
<jdstrand> mvo: fyi, I recommended even better future-proofed rules
<mvo> jdstrand: in 4022? yeah, +1 for that
<mvo> slangasek: please don't restart snapd, it should be fine without a restart
<jdstrand> mvo: re 4022> note, I recommended one set, and 3 seconds ago recommended a better set
<slangasek> mvo: so what should I do in order to test?
<mvo> slangasek: and yes, on restart it will rewrite the rules, it is very opionated about that
<slangasek> all the snaps get unmounted
<mvo> jdstrand: heh, ok
<jdstrand> mvo: I'm puzzled too
<jdstrand> slangasek: the test is, load the profile and don't restart snapd
<mvo> slangasek: uh, you need to restart snapd so that it applies the seed, right?
<slangasek> jdstrand: ok but then what?
<jdstrand> slangasek: then launch whatever subiquty is doing
<slangasek> what subiquity is doing is running the bits from the snaps, that are not mounted, because snap-confine failed and things were rolled back :)
<mvo> slangasek: what changes did jdstrand suggest?
<jdstrand> that is a fun spelling
<ackk> kalikiana, so it seems that adding the network slot to the lxc app actually makes it not work with network :)
<ackk> quite odd
<slangasek> mvo: adding /rofs/etc/ld.so.cache as a test
<jdstrand> mvo: an r rule for the /rofs/ ld.so.cache
<jdstrand> (that isnt the full path
<jdstrand> )
<mvo> slangasek: ta, I can try that and snap install /var/lib/snapd/seed/snaps/* manually
<jdstrand> man, irc is *laggy*...
<slangasek> ah, testing that here as well
<jdstrand> yes, snap install  a classic snap
<slangasek> apparmor profile overwritten again
<jdstrand> then run snap run --shell snap.command
<jdstrand> that is enough to get snap-confine going
<slangasek> but this time the core snap has stayed mounted
<zyga-ubuntu> popey: is the giraffe still around?
<popey> yes
<slangasek> jdstrand: I see apparmor denials for both ld.so.cache and libudev
<zyga-ubuntu> jdstrand: where did you push it?
<jdstrand> zyga-ubuntu: I haven't pushed anything
<zyga-ubuntu> ah sorry
<jdstrand> slangasek: I suggest copying the fileand loading that
<jdstrand> snapd shouldn't rewrite the file and load it then (and if it does, at least your changes aren't overwritten, you need only reload)
<slangasek> jdstrand: oh, because the file doesn't have to have the same name as the path?  hurr ok
<jdstrand> yes
<jdstrand> slangasek: it is the contents of the file that matter. the filename is just convention
<slangasek> jdstrand: ok.  I have to add rofs for both libudev and ld.so.cache, and then I get farther... and then we get the same error for libpthread.so.0
<jdstrand> mvo: I'm curious. with 4022, with only the code changes, the apparmor rules are required?
<slangasek> jdstrand: why are the libs from the rootfs being used instead of those inside the snap?
<slangasek> isn't that the real issue here?
<mvo> jdstrand: I am not sure if they are strictly required, I had some denials when testing hiri
<popey> zyga-ubuntu: giraffe is back!
<zyga-ubuntu> popey: great
<zyga-ubuntu> popey: so it works
<zyga-ubuntu> I'll close the window now, that's all I need
<zyga-ubuntu> popey: thank you very very much
<jdstrand> slangasek: I think what was maybe happening before is that snapd was considering the live session as "not Ubuntu' and running snapd in non-restrictive mode
<jdstrand> mvo: does that sound plausible? ^
<popey> zyga-ubuntu: np, shall I shut this down now?
<mvo> jdstrand: let me check os-release
<zyga-ubuntu> popey: yes, I think it's good now
<popey> kk
<zyga-ubuntu> popey: just label it "zyga" and put it on the shelf ^_^
<zyga-ubuntu> (kiddin)
<popey> was about to ask :D
<jdstrand> (and snap-cofine's profile wasn't loaded and between the two, things worked cause snap-confine wasn't confined)
<mvo> jdstrand, slangasek: fwiw, I added /rofs/a-bunch-of-libs, now it fails on /vow/upper/var/lib/snapd/cookie
<jdstrand> yeah, this is exactly the road I was talking to slangasek about running snaps in t he live image the other day
<jdstrand> we aren't gong to fix this whack-a-mole
<jdstrand> we need the previous behavior when on live session
<jdstrand> snap-cofine should not be confined and snapd needs to be cool with that
<mvo> jdstrand: well, os-release says ID=ubuntu so previous versions *should* have confined it too
<mvo> jdstrand: but obviously reality disagrees with me
<zyga-ubuntu> jdstrand: aha
<jdstrand> this is indeed puzzling
<zyga-ubuntu> jdstrand: by sayin "shoud not be confined" do you mean that in live sessions we should unload the profile
<slangasek> previous working image still available at http://cdimage.ubuntu.com/ubuntu-server/daily-live/20171010.1/artful-live-amd64.iso for comparison
<zyga-ubuntu> jdstrand: or just disable apparmor in the kernel?
<jdstrand> oh
<jdstrand> yes
<jdstrand> slangasek: I thought for live fs there was something about detecting if apparmor was there and not using it
<jdstrand> passing apparmor=0
<jdstrand> something in the init script
<slangasek> oh?  let me see
<slangasek> I don't find any references to that in livecd-rootfs
<jdstrand> something... (I can't recall the details)
<slangasek> a userspace process is allowed to disable apparmor after boot?
<mvo> jdstrand: that sounds very plausible to me, if apparmor is disabled we detect that and things should work
<kalikiana> ackk: Interesting. Not what I would've expected...
<jdstrand> ah
<jdstrand> mvo, slangasek: I bet what is happening is that the apparmor initscript is not loading /etc/apparmor.d. *but* snapd is reexcing and loading snap-confine's profile
<jdstrand> mvo, slangasek: so napd needs to detect if on live session and not do that
<jdstrand> slangasek: disable apparmor after boot> no. userspace can choose to not load profiles though
<jdstrand> mvo: fyi, /lib/apparmor/functions /profile-load has: [ -d /rofs/etc/apparmor.d ]  && exit 0 # do not load if running liveCD
<jdstrand> I gotta run
<slangasek> test -d /rofs/etc/apparmor.d && exit 0
<slangasek> that's in the apparmor init script
<mup> PR snapcraft#1573 closed: WIP project_loader: parse YAML without processing it <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1573>
<zyga-ubuntu> I wonder how can we detect that
<zyga-ubuntu> being in live session
<ogra_> well, see above ... if /rofs exists ...
<mvo> slangasek: the old image (based on 2898) fails in the same way for me
<ogra_> (there are many other indicators though ... )
<kalikiana> kyrofa, sergiusens: Can I get a final review on https://github.com/snapcore/snapcraft/pull/1412
<mup> PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412>
<mvo> jdstrand: (see above, the previous 2898 is broken for me as well)
<mvo> slangasek, jdstrand: on reboot it works now
<jdstrand> mvo: so, reexec for snap-confine is loading the appropriate profile into the kernel. it shouldn't on livefs (see reference from me and slangasek, above)
<jdstrand> mvo: in the reexec code, just looke for /rofs/etc/apparmor.d and don't load
<jdstrand> that should immediately fix this issue
<zyga-ubuntu> jdstrand: ok
<jdstrand> I can't comment on when it was first introduced
<jdstrand> (the regression)
<jdstrand> . we've had reexec for ages, so not sure what it is showing up only now
<ogra_> perhaps it should simply boot completely without reexec in live ?
<kalikiana> sergiusens: elopio: Also a real review here would be appreciated https://github.com/snapcore/snapcraft/pull/1568
<mup> PR snapcraft#1568: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568>
<ogra_> (given thats a simple env var that might be easier to implement)
<jdstrand> ogra_: that would be simple. I don't know the requirements for livefs
<ogra_> just use the deb until you install
<jdstrand> that does seem reasonable to me. mvo? ^
<elopio> kalikiana: I'm still confused by that one. Aren't we checking the md5 of the .snap file?
<mvo> jdstrand: yes, working on a patch now
<ogra_> mvo, just addint SNAP_REXEC=0 to casper defaults would do
<kalikiana> elopio: Then let's discuss it :-) Yes, md5sum is used to see if the files are the same
<ogra_> (assuming server uses casper for live)
<mvo> ogra_: interessting - jdstrand, what do you think about about "<ogra_> mvo, just addint SNAP_REXEC=0 to casper defaults would do"?
<kalikiana> elopio: Did you run it more than once with the same container while testing? If you do a cleanbuild you won't see a difference
<elopio> kalikiana: so, I don't understand why it knows that the core snap is the same and doesn't reinstall it, but it doesn't work the same way for the snapcraft snap and it is reinstalled?
<jdstrand> mvo: I think that is very reasonable
<jdstrand> I suspect you can test that right now
<elopio> kalikiana: Sergio said it's because core comes from the store, and the snapcraft snap is a --dangerous install. But if we are checking the .snap, I don't understand that difference.
<jdstrand> I forget how casper works otoh
<kalikiana> elopio: Was the snapcraft snap the same? From your comment I can't tell
<mvo> jdstrand: could you pass it to steve, he seems to have dropped from irc. I will wait for his feedback and otherwise I will go ahead with a 2.28.4 with the nvidia fix but without any special subiquity
<jdstrand> I need to focus on the sprint atm. I'' check back
<jdstrand> mvo: yes
<kalikiana> elopio: it should work for x versions as well, as long as the md5sum matches
<zyga-ubuntu> mvo: please don't fork 2.29 before we backport all the fixes from 2.28 to master
<mvo> jdstrand: thank you! I will be here waiting for feedback
<mvo> zyga-ubuntu: +100
<elopio> kalikiana: I think so. I built a snapcraft.snap from your branch. Installed it with --dangerous. Ran container builds once, core and snapcraft are installed. Ran it again, only snapcraft is installed.
<elopio> so it's identifying the repeated core. But as far as I understand, it should also identify the same snapcraft. Unless I'm missing a step or misunderstanding something...
<kalikiana> elopio: Yeah. It's just the .snap files.
<kalikiana> elopio: Does the code make sense to you? I don't know if there's a case I'm missing...
<elopio> I think it makes sense. From reading the code, I got the idea that both store and local snaps would be checked and installed only if needed. kalikiana is there something you want me to try here?
<elopio> kyrofa: ping. We are getting this in artful and zesty: http://paste.ubuntu.com/25720772/
 * kalikiana thinking
<kyrofa> elopio, those tests should be tagged as xenial-only
<kyrofa> elopio, are you moving them around by any chance?
<kalikiana> sergiusens: btw this is also waiting on your re-review https://github.com/snapcore/snapcraft/pull/1546
<mup> PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
<kalikiana> elopio: I just tried here again, with a new container, works 100% fine... `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft -d pull` twice, second time I get `Not re-injecting same version of 'snapcraft'`
<kalikiana> elopio: Did you test this way also?
<elopio> kyrofa: I don't think I've touched them. And I see no != xenial skip in there. I can add it.
<elopio> kalikiana: I tried without the `-d pull`. I can try again
<kalikiana> elopio: The `-d` is just so you see the message, any command is fine
<kalikiana> pull is just the cheapest operation
<kyrofa> elopio, hmm. That error isn't really unusual though, I'm surprised we haven't seen it more
<kyrofa> elopio, we should add a way to ack pubkeys
<elopio> kyrofa: so, how does it pass on xenial if it can't validate the keys? Could this be caused by a newer apt version or something like that?
<kyrofa> elopio, yeah maybe. Or sha1 invalidation?
<kyrofa> We need to investigate
<kyrofa> Rather: I will investigate :)
<kyrofa> I've got a few things on my queue though-- can it wait a bit?
<elopio> kyrofa: do you want me to propose the skip?
<kyrofa> elopio, it depends on how soon you need those tests to pass
<elopio> kyrofa: I don't yet have the xenial results yet, but it seems to me that's the last blocker for the release. I'm not sure if sergiusens wanted to release this week, or the next.
<zyga-solus>  /me -> math with son, ping if emergency
<elopio> kalikiana: so, please confirm the steps I'm running. Checkout your no-reinject branch, build a snap from that branch, install that snap. snapcraft init, and SNAPCRAFT_CONTAINER_BUILDS snapcraft twice.
<kalikiana> elopio: assuming you have =1 in there like I did above, yes
<kalikiana> elopio: Do you see log messages about installing or "not re-injecting"?
<elopio> I will let you know in a few minutes when I have the snap built.
<elopio> I didn't run with --debug, I will do that this time.
<kalikiana> elopio: Okay. Thanks a lot!
<elopio> kalikiana: now it seems to work: http://paste.ubuntu.com/25720936/
<elopio> I can't explain how I got the log with only snapcraft reinstall :/
<zyga-solus> mvo: re, all good?
<mup> PR snapcraft#1590 closed: setuptools: conditional Debian-specific deps <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1590>
<kalikiana> elopio: Interesting. The inherent problem with manual testing I guess...
<elopio> kalikiana: oh wait, maybe I know!
<elopio> on my previous log, my snapcraft version was x2. So I reinstalled the snap snap, and ran two container builds from scratch.
<elopio> kalikiana: http://paste.ubuntu.com/25720968/ same log as before. Any idea how x2 could be different from x1?
<mvo> zyga-solus: still waiting for slangaseks feedback is seeding SNAP_REEXEC=0 in casper is sufficient
<jdstrand> mvo: I advised slangasek to use SNAP_REEXEC=0 and he is testing that
<mvo> jdstrand: cool, thanks
<slangasek> jdstrand, mvo: I am somewhat contended right now (just pulled into another meeting), I am going to test it as quickly as possible but don't know if I'll get it done before lunch (eta 20m)
<mvo> slangasek: thank you, keep me updated. I'm preparing a new snapd right now but will wait with the release until you had a chance to test the env string
<mvo> slangasek: I will just wait for your feedback
<slangasek> ok
<slangasek> mvo: does that mean that, once tested, you will be fixing this via snapd and I don't need to change livecd-rootfs?
<mvo> slangasek: the other way around :)
<slangasek> mvo: once tested, I will change it in livecd-rootfs and you will make no changes to snapd? :)
<mvo> slangasek: if the re-exec env does not work for you I can fix in snapd, otherwise I will leave it out of snapd
<slangasek> ok
<mvo> slangasek: correct
<elopio> kalikiana: here's an idea. When snapcraft is x2 in the host, in the container it will be installed as x1 on the first execution. On the second execution it compares x2 with x1, and then reinstalls it on the container. Now both the host and the container have x2, so the third execution will not reinstall it. Would that make sense?
<mvo> slangasek: I think it makes more sense to customize the env in casper than to hardcode this behaviour in snapd. if you give me a pointer how I can do it I can test it here myself
<slangasek> mvo: the rootfs is an overlay, so everything is editable; I was going to drop a snippet into /etc/systemd/system/snapd.service.d/ that sets Environment=SNAP_REEXEC=0
<slangasek> mvo: file extension must end in .conf, and Environment must be set under a [Service] block
<mvo> slangasek: ta
<mvo> slangasek: testing now
<slangasek> mvo: tested here also, and it passed
<jdstrand> mvo: this isn't super-urgent since the apparmor accesses for snap-confine for the nvidia thing are safe, but I'm really puzzled how a stat on a file in /dev is causing those for you. I *think* the root cause was that my original PR was always intended for 2.28, but for some reason didn't make it there (so that is something to consider how to improve)
<kalikiana> elopio: Ah. Yes. It would be looking for the same x2.snap which wouldn't be there.
<mvo> slangasek: reliable?that is great
<kalikiana> elopio: Unfortunately the x is a continuous number, nothing we can do here
<mvo> jdstrand: I'm not sure either, I think we need to do a proper retrospect on this
<mvo> jdstrand: when the fires are out of course :)
<zyga-suse> jdstrand: could it be the snappy-dev-app helper?
<mvo> jdstrand: so probably post-sprint
<jdstrand> mvo: sure, that's fine. there were several issues. I want to make sure they are all knownand addressed
<mvo> jdstrand: yeah, I think we are in agreement
<mvo> jdstrand: do you think we need more for the .4 release?
<jdstrand> mvo: for example, I thought I did the initial PR inenough time for it to be in 2.28 (indeed, I worked on it with priority so it would be there), but I must have missed a fork
<mvo> jdstrand: I can check the exact timing
<kalikiana> sergiusens: Can this be merged, please? https://github.com/snapcore/snapcraft/pull/1512
<mup> PR snapcraft#1512: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
<jdstrand> mvo: so, why did I miss that, how can I not miss it in the future, how can snapd team make that easier for me. that sort of thing
<zyga-suse> jdstrand: was the PR tagged for 2.28?
<zyga-suse> (tagged as in github milestone)
<mvo> jdstrand: +1
<jdstrand> mvo: obviuosly there is the QA aspect (why didn't QA see that an lxd consuming snap broke, why didn't qa see that opengl failed on nvidia)
<jdstrand> (I know that last one, the CI tests don't have nv hardware, which is why I mocked it)
 * jdstrand happens to also not have nvidia hardware
<zyga-suse> jdstrand: qa process doesn't involve nvidia unfortunately
 * jdstrand nods
<jdstrand> zyga-suse: right, so we need to figure out how to do that, even if manual, whenever we see changes for nv
<jdstrand> eg, hey zyga-suse, I patched something with nvidia, can you test real quick?
<zyga-suse> jdstrand: agreed
<zyga-suse> jdstrand: we were discussing similar measures
<jdstrand> niemeyer also said we should all run candidate.
<zyga-suse> jdstrand: all releases smoke tested on nvidia HW
<zyga-suse> jdstrand: and also all nvidia-touching code really tested as well
<jdstrand> anyway, don't have to discucss here. niemeyer and I talked about it. I'd like to participate in the post-mortem to make sure I know all the agreements and can adhere to them
<zyga-suse> +1
<jdstrand> zyga-suse: yeah
<jdstrand> like, I *knew* nvidia was busted. so I did the PR. unfortunately it didn't hit .28(failing), the fact that I happened to notice nv would fail was a failing. if we actually needed additional apparmor rules, that was also a failing (I'm really curios if they were actually needed)
<jdstrand> ok, lunch
<mup> PR snapcraft#1536 closed: repo: implement :target suffix for package names <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536>
<zyga-suse> jdstrand: we need apparmor permissions to stat files, right?
<kalikiana> elopio: Can you please comment on the PR? I'm really trying to get my list of PRs down :-D
<elopio> uh, sorry, my comment was caught in a network issue.
<kalikiana> elopio: Ah, I see it now... not to be demanding, but I was thinking *review* comment ;-)
<mvo> slangasek: for me the journy was slightly more complicated, when I do "printf "[Service]\nEnvironment=NO_REEXEC=0" > /etc/systemd/system/snap.subiquity.started.service.d/no-rexec.conf" (and added the basedir) things work, but it needs to be that because the "snap run" that starts subiquity is indepedent of snapd and will not inherit the environment
<elopio> kalikiana: you have it.
<mvo> slangasek: *if* this is a sufficient workaround for now I will go ahead with 2.28.4
<mvo> slangasek: and leave the re-exec disable to casper. I can help with the PR if you point me to the right branch once .4 is out :)
<kalikiana> elopio: Ah, you did it separately. This distinction between "just comment" and proper reviews is really silly... but anyway, thanks a lot!
<slangasek> mvo: yes, that looks like a sufficient workaround to me
<slangasek> mvo: I'm going to shove it into livecd-rootfs rather than casper
<mvo> slangasek: thank you, that sounds good as well, let me know if I can help
<kalikiana> kyrofa: Can you please check this one again? I addressed your comments https://github.com/snapcore/snapcraft/pull/1577
<mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
<kalikiana> also elopio ^^
<elopio> kalikiana: I like that distinction. I don't feel good about -1 a PR when I don't understand something. Like in this case.
<elopio> one could argue that a -1 is the right thing to do, because this behaviour should have been explained in a PR comment somewhere. But still it's not clear if it's my fault because I'm being dumb, until we dig further.
<kalikiana> elopio: Hmm yeah. To me it would be clearer if you could have a ? icon there, and turn it into a +1 or -1 as needed, like the "approve" and "discmiss" buttons you get at the bottom
<kalikiana> Really the fact that it splits the work-flow so weirdly is what bugs me
<mvo> a review for 4024 would be great
<kalikiana> you missed the # there
 * zyga-suse looks
<mup> PR snapd#4024 closed: debian: fix replaces/breaks for snap-xdg-open (thanks to apw!) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4024>
<zyga-suse> ah, I just looked from another computer :)
<mup> PR snapcraft#1348 closed: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348>
<zyga-suse> mvo: tests on 4022 are incredibly slow
 * kalikiana still waiting on #1587 and #1577 wondering if sending European chocolates to his colleagues would help
<mup> PR #1587: store: deal with 404 froms the SSO store properly <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1587>
<mup> PR #1577: daemon, cmd/snap: refresh --devmode <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1577>
 * zyga-suse -> supper and clenaup
<Chipaca> kalikiana: presumably snapcraft#1587 and snapcraft#1577
<mup> PR snapcraft#1587: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
<mup> PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
<kalikiana> Chipaca: Thanks, yeah. I guess ids are not unique...
<Chipaca> kalikiana: yeah, and they're similarly small numbers
<Chipaca> otherwise mup does guess they're something else (e.g. #1688531)
<mup> Bug #1688531: Remove whitespace line between tracks in 'snap info' <snapd:Fix Committed by chipaca> <https://launchpad.net/bugs/1688531>
<Chipaca> anyway, EOD for me
<Chipaca> o/
<jdstrand> zyga-suse: you do *not* need apparmor rules for the files to stat them. you need read on the directory the files are in. That is why I am puzzled why the /dev accesses were needed (and why the /sys denials popped up).
<jdstrand> I suspect the /sys accesses are just noise and that the /dev accesses are not needed at all
<zyga-suse> aha, interesting
<zyga-suse> I didn't know that, I agree that some of those are probably not needed in that case
<jdstrand> this is why the mocked nvidia devices passed the test
<zyga-suse> I was trying to be conservative in hard situation (time running out, remote access to hardware)
<jdstrand> spread tests
<zyga-suse> I'll gladly research why the sys access showed up
<jdstrand> I'm super-curious on that. also curious if they still show up if they are just noise
<jdstrand> I suspect they are cause snap-confine isn't going to do anything with any of that. it is just going to stat the files and add them to the cgroup
 * zyga-suse was hoping to do some updates on snap-update-ns but today turned out different
<zyga-suse> I found a bug where snap-update-ns doesn't do what it should, I need to debug that
<zyga-suse> but now I need a break
<zyga-suse> o/
<jdstrand> I suspect the udev lib calls snap-confine does a little earlier are triggering those, then udev ignores nvidia and moves on. then we stat and are good
<jdstrand> zyga-suse: my curiosity is certainly not a reason to deprioritize other things :)
<jdstrand> I would like to remove the /dev rules if possible
<zyga-suse> no no, it's not your fault, I'm just tired and I want to wrap up that branch before jumping onto other topics
<zyga-suse> who knows, maybe in .5 :)
 * zyga-suse knocks on wood
<jdstrand> cause access to the devices is more than the setuid snap-confine needs (though, it is just read, but still)
<zyga-suse> jdstrand: I'm surprised stat is not triggering apparmor checks btw
<jdstrand> there is a bug on that
 * jdstrand finds
<zyga-suse> jdstrand: it's an information leak via (very) expensive enumeration
<zyga-suse> aha
<zyga-suse> so it will be changed eventually?
<jdstrand> https://bugs.launchpad.net/apparmor/+bug/1655435
<mup> Bug #1655435: stat() unconditionally allowed via apparmor_inode_getattr() <AppArmor:Triaged> <https://launchpad.net/bugs/1655435>
<jdstrand> zyga-suse: not in a way that we wouldn't know about it
<jdstrand> and also, not any time soon
<jdstrand> apparmor could conceivably grow a 'stat' perm (as opposed to read and write)
<jdstrand> but backc in the day that was implemented and it was amazingly annoying. no one is working on it
<zyga-suse> not a weekend project?
<mvo> zyga-suse: yeah, I am waiting for two tests right now :/
<zyga-solus> I'm assembling furniture
<mvo> zyga-suse: 4022 is green now
<zyga-solus> I think we are doing the same thing lately :)
<mvo> zyga-solus: heh, enjoy, I will do 2.28.4 now - but first I check the forum if there is anything else we need to do
<zyga-solus> good call
<mup> PR snapd#4022 closed:  interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4022>
<mup> PR snapd#4025 opened: release: merge the snapd 2.28.4 changes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4025>
<mvo> cachio_afk: just a heads-up - we should have a 2.28.4 in beta in ~1h that fixes the opengl issue
<mup> Bug #1722882 opened: Ubuntu Core 16: Error: cannot refresh "pi2-kernel": snap "pi2-kernel" has changes in progress <Snappy:New> <https://launchpad.net/bugs/1722882>
<jdstrand> zyga-suse: heh, no, not a weekend project. I mean, the mediation itself wouldn't be bad (iirc), it would be the policy implications.
<zyga-solus> jdstrand: do you think it's feasible to introduce a change that is backwards compatible?
<zyga-solus> jdstrand: (stat keeps being allowed in absence of policy but can be controlled)
<mvo> zyga-solus: just fyi, the world is conspiring against us: https://code.launchpad.net/~snappy-dev/+snap/core/+build/90572 - my fresh core build with 2.28.4 does not upload to the store :/
<mvo> a review for 4025 would be great
<zyga-solus> mvo: :-(
<zyga-solus> mvo: I'll review it in a sec
<mup> PR snapd#4025 closed: release: merge the snapd 2.28.4 changes back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4025>
<mvo> cachio_afk: 2.28.4 is in beta now and ready for testing towards candidate
<jdstrand> zyga-solus: yes. it is possible to say 'you haven't specified any stat rules, so I'll let you stat. if you add a stat rule, every stat is mediated. that is possible
<zyga-suse> jdstrand: maybe I could work on that eventually, I'd like to
<jdstrand> zyga-solus: honestly though, there are a number of info leaks-- I'd prefer to see fixing those. all of a sudden mediating stat is ging to be *painful* for policy
<zyga-suse> anything small?
<jdstrand> I would suggest going to #apparmor on OFTC and asking if there is something bitesize
<zyga-suse> ok
<jdstrand> the one I want is kernel variable, so @{pid} corresponds to your pid
<jdstrand> but that is not at all bitesize :)
<mup> PR snapd#4020 closed: tests: add test for lxd interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4020>
<mup> PR snapcraft#1607 opened: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
<JonelethIrenicus> any way to not have snap directories show up as actual drives in applications?
<JonelethIrenicus> For some reason applications like Firelight pick them up as seperate drives.
<gouchi> check udisk2 interfaces ?
<gouchi> https://docs.snapcraft.io/reference/interfaces
<JonelethIrenicus> thanks I will
<kyrofa> gouchi, how will that help with hiding the mounted snaps?
<gouchi> oops sorry I misread
<gouchi> I understood how to access drives
<gouchi> sorry my mistake
<kyrofa> JonelethIrenicus, snaps are simply squashfs images mounted into place
<kyrofa> JonelethIrenicus, those applications are probably picking them up like any other disk image
<mup> PR snapd#4026 opened: overlord/auth: continue for now supporting UBUNTU_STORE_ID if the model is generic-classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/4026>
#snappy 2017-10-12
<mup> PR snapcraft#1608 opened: tests: fix the duplicate plainbox test scenarios <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1608>
<zyga-solus> o/
<zyga-ubuntu> it seems another 2.28 point release is ahead
<mup> PR snapcraft#1609 opened: tests: remove the duplicate nodejs integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1609>
 * zyga-ubuntu fires spread to debug snap-update-ns issue
<mup> PR snapcraft#1610 opened: tests: reenable the cleanbuild integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1610>
<zyga-ubuntu> mvo: good morning
<zyga-ubuntu> mvo: guess what day is it today?
<zyga-ubuntu> mvo: release day
<mvo> zyga-ubuntu: excited! and good morning
<mvo> zyga-ubuntu: I have release day every month ;)
<zyga-ubuntu> mvo: pedronis sent a PR for 2.28
<zyga-ubuntu> mvo: looks like something we need to spin .5 for
<mvo> oh nos
 * mvo looks
<zyga-ubuntu> mvo: I've added debugging for the bug I found in snap-update-ns and I'm waiting for the debug shell to show up
<mvo> zyga-ubuntu: aha, nice
 * zyga-ubuntu learns that logger.Noticef doesn't just work :/
<mvo> zyga-ubuntu: hu?
<zyga-ubuntu> mvo: well, in a CLI program it does nothing at all
<zyga-ubuntu> mvo: I noticed it is also not working early in initialization of snapd
<zyga-ubuntu> mvo: it is "enabled" somewhere during startup
<zyga-ubuntu> I'll look but for now I swapped that for fmt.Printf
<zyga-ubuntu> I think I solved the bug now, I'll spend an extra moment to link output from snap-update-ns to task log
<zyga-ubuntu> and look at that noticef thing
<mvo> zyga-ubuntu: aha, thank you. just read up on the background for 4026, looks like we need a .5
<zyga-ubuntu> mvo: I didn't read upon it but I trusted the 2.28 tag
<zyga-ubuntu> ok, one more run on fedora and I'll push
<mvo> could someone do a second review of 4026 please?
<zyga-ubuntu> mm
<zyga-ubuntu> mvo: what is the back story?
<zyga-ubuntu> there's nothing on the PR
<mvo> zyga-ubuntu: backchannel, let me forward
<mvo> zyga-ubuntu: check your mail
<zyga-ubuntu> k
<mvo> (please)
<zyga-ubuntu> thank you
 * zyga-ubuntu reviews this now
<zyga-ubuntu> mvo: silly question, which store is used on the generic model when UBUNTU_STORE_ID is unset?
<zyga-ubuntu> mvo: should we not return mod.Store() if UBUNTU_STORE_ID is unset?
<mvo> zyga-ubuntu: hm, good point
<zyga-ubuntu> (nothing like silly questions)
<zyga-ubuntu> mvo: let's tweak that test to have a case like that
<zyga-ubuntu> if the outcome is sensible then +1 but I think it may be a missing cae
<zyga-ubuntu> *case
<mvo> zyga-ubuntu: looks like the generic model is not defining a store so the end result is the same, but I agree with you, it seems cleaner to not rely on this
<mup> PR snapd#4027 opened: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <https://github.com/snapcore/snapd/pull/4027>
<mup> PR snapd#4028 opened: interfaces/mount: don't generate legacy per-hook/per-app mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4028>
<zyga-ubuntu> mvo: ok, I can work on that now
<mup> PR snapd#4029 opened: packaging: remove .mnt files on removal <Created by zyga> <https://github.com/snapcore/snapd/pull/4029>
<zyga-ubuntu> mvo: I pushed a few trivial branches up and I'm working on the extra test case and tweak in behavior
<zyga-ubuntu> mvo: maybe you could review the three I pushed
<zyga-ubuntu> mvo: it seems we should not actually tweak the logic there
<mvo> zyga-ubuntu: I reviewed the first already, will do the others in a bit
<zyga-ubuntu> mvo: I pushed a test case, let me know if this is sensible
<zyga-ubuntu> thank you!
<mvo> zyga-ubuntu: not tweak it, why not?
<zyga-ubuntu> mvo: not sure how to tweak it
<zyga-ubuntu> mvo: if the variable is unset, should we use the model?
<zyga-ubuntu> mvo: the test at least shows us current behavior, maybe it's right, maybe not
<zyga-ubuntu> mvo: if you tweak the condition now look at what happens to the tests there
<zyga-ubuntu> mvo: I don't know what the correct behavior is here
<mvo> zyga-ubuntu: aha, ok. lets wait for pedronis then
<mvo> zyga-ubuntu: did you ask you question in the PR?
<zyga-ubuntu> mvo: I pasted our conversation there
<zyga-ubuntu> I'll look at bridging snap-update-ns logs with the task that uses it now
<mvo> ok
<mvo> I will tweak my caching branch based on the nice feedback from pstolowski and then move to squashfs-fuse
<zyga-ubuntu> ok
<zyga-ubuntu> squashfs-fuse?
<mup> PR snapd#4023 closed: tests: fix econnreset scenario when the iptables rule was not created <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4023>
<Chipaca> moin moin
<Chipaca> ogra_: question for you: all pi zeros are As, right? i mean, armel and all that?
<ogra_> Chipaca, if you mean armv6, afaik yes ... i think popey and flexiondotorg own them (for moe detail)
<ogra_> *more
<zyga-ubuntu> Chipaca: hey
<Chipaca> ogra_: AFAIK they appear spontaneously in geek kit
<Chipaca> a friend just told me he suddenly found he had 5 of them
<Chipaca> he's never bought one
<ogra_> heh
<ogra_> thats funny
<Chipaca> :-)
<Chipaca> OTOH this is the guy that managed to install ubuntu with no x, by just clicking 'next'
<Chipaca> also he thought he'd installed ubuntu on one of the zeros (which i was pretty sure wasn't possible)
<zyga-ubuntu> Chipaca: huh, how did he get them?
<Chipaca> zyga-ubuntu: tech shows and the like
<Chipaca> zyga-ubuntu: in the uk they come in magazines
<ogra_> are you sure it's a zero ?
<zyga-ubuntu> Chipaca: nice
<zyga-ubuntu> Chipaca: if you are interested in a review, https://github.com/snapcore/snapd/pull/4008 is juicy
<mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
<Chipaca> ogra_: that's what he said :-)
<zyga-ubuntu> (and very important to me)
<ackk> mvo, hi, is there something utterly wrong with my PR or is CI having issues on 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>
<zyga-ubuntu> ackk: looking
<ackk> zyga-ubuntu, thanks
<zyga-ubuntu> Formatting wrong in following files:
<zyga-ubuntu> /tmp/static-unit-tests/src/github.com/snapcore/snapd/wrappers/services_gen_test.go
<zyga-ubuntu> /tmp/static-unit-tests/src/github.com/snapcore/snapd/snap/validate_test.go
<zyga-ubuntu> go fmt is your friend
<zyga-ubuntu> I recommend good editor integration (ask for advice if you use vim)
<mvo> ackk: what zyga-ubuntu said, we can help you by pushing to your branch if you want
<ackk> zyga-ubuntu, I do have linting, must have missed it
<ackk> lemme fix it
<ackk> uhm "buffer is already go-fmt'd"
<ackk> indeed go fmt doesn't report anything
<zyga-ubuntu> ackk: maybe gofmt -s ?
<zyga-ubuntu> maybe save/diff
<ackk> ah
<zyga-ubuntu> I can look if you want
<ackk> zyga-ubuntu, where do you run linting (to check how you run it)
<zyga-ubuntu> ackk: run-checks --static I believe
<zyga-ubuntu> ackk: we use gofmt (not go fmt) and pass the -s (simplify expressions) flag
<zyga-ubuntu> ackk: I suspect it is that, it bit me a few times
<ackk> ah, that's probably why
<ackk> go-mode uses go fmt
<ackk> why are there even two things for the same job? :)
<zyga-ubuntu> because it's perl^Hgo
<zyga-ubuntu> ;-)
<ackk> heh
<ackk> zyga-ubuntu, mvo should be fixed now, thanks
<zyga-ubuntu> great, thank you :)
<Chipaca> zyga-ubuntu: did a bit of it
<zyga-ubuntu> thank you!
<zyga-ubuntu> Chipaca: do you think I should split it into more PRs?
<zyga-ubuntu> Chipaca: I can take the secure mkdir bits out
<Chipaca> zyga-ubuntu: my brain is swimming in the sweet molasses of sleep, still
<Chipaca> zyga-ubuntu: it's quite possible the pr is fine as it stands; wait a bit for me to be properly awake?
<zyga-ubuntu> sure :)
<zyga-ubuntu> we woke up before 6 today; stark contrast from 8:30 in spain
<zyga-ubuntu> plus the fact that it's dark outside
<Chipaca> zyga-ubuntu: my checkpoint was because you're obviously active on the pr, so i didn't want to have 20 questions for you in two hours instead of 5 now and 5 later
 * zyga-ubuntu nods
<ackk> does snapcraft validate the yaml file entirely via yaml schema or is there also programmatic validation for some cases?
<mup> PR snapcraft#1611 opened: plainbox-provider plugin: init PROVIDERPATH <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1611>
 * zyga-ubuntu -> break for light meal and tea
<popey> huh, irccloud-desktop snap no longer works since I updated to 2.28 and rebooted.
<popey> alan@hal:~$ irccloud-desktop
<popey> udev_enumerate_scan failed
<popey> No apparmor denials
<ackk> popey, maybe related to https://forum.snapcraft.io/t/weird-udev-enumerate-error/2360 ?
<popey> magic, thanks
<ackk> it seems it's fixed in artful https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1713536
<mup> Bug #1713536: udev: boot script does not trigger subsystem coldplug <architecture-s39064> <bugnameltc-158070> <severity-medium> <targetmilestone-inin1604> <verification-done> <verification-done-xenial> <verification-done-zesty> <Ubuntu on IBM z Systems:Fix Committed by canonical-foundations>
<mup> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Committed> <systemd (Ubuntu Zesty):Fix Committed> <systemd (Ubuntu Artful):Fix Released> <https://launchpad.net/bugs/1713536>
<zyga-ubuntu> popey: does it happen again?
<popey> i replied on the forum
<zyga-ubuntu> ta
<popey> it happens every time i try and launch irccloud-desktop
<zyga-ubuntu> hmm hmm hmm
<popey> ooh
<zyga-ubuntu> ?
<popey> other snaps fail too
<zyga-ubuntu> yes, this is generic udev code path
<popey> ok
<zyga-ubuntu> no denials at all?
<zyga-ubuntu> (not even for snap-confine?)
<zyga-ubuntu> do you have nvidia on this box?
<popey> no denials, yes, nvidia
<zyga-ubuntu> man, /o\
<zyga-ubuntu> popey: which driver are you using? I wonder if this is related to anything we saw yesterday
<popey> ii  nvidia-375                                     375.66-0ubuntu0.16.04.1      amd64                        NVIDIA binary driver - version 375.66
<popey> apparently
<zyga-ubuntu> popey: can you use gdb to put some breakpoints and see where it fails?
<popey> uhhhh
<zyga-ubuntu> or can you open that 2nd laptop and see if it happens there
<zyga-ubuntu> I can do it remotely
<zyga-ubuntu> (note: I tweaked stuff there so you may need to apt-get install --reinstall snapd
<popey> it doesn't happen on my 17.10 intel laptop
<zyga-ubuntu> (and replace any conffile changes)
<zyga-ubuntu> yeah, I suspect this will also tell us something else
<popey> can dig that machine out again and boot it up, sure
<zyga-ubuntu> why we had to add those apparmor rules that jdstrand didn't expect
<zyga-ubuntu> or why we got a denial
<zyga-ubuntu> we didn't get to the bottom of that
<popey> so you want me to do that?
<zyga-ubuntu> popey: if you coupld please check out if it affects that other machine I will gladly investigate remotely
<popey> kk
<popey> doing now
<zyga-ubuntu> thank you
<popey> remember it's running artful, and ackk says its fixed there?
<zyga-ubuntu> ah, and your machine that is affected?
<zyga-ubuntu> is it also artful?
<popey> The machine that is affected is my 16.04 nvidia machine
<ogra_> it was 16.04 for me too
<popey> ^ monster main laptop which got rebooted last night
<popey> My secondary (thinkpad, intel) 17.10 laptop does not see the issue
<ogra_> and nvidia ....
<popey> booting the slow old desktop you had access to, to test that
<zyga-ubuntu> k
<popey> (which is 17.10 nvidia)
<popey> Grr. This machine has basically locked up doing "apt remove snapd"
<zyga-solus> hmm
<zyga-solus> can you move to a VT?
<popey> (it's a deb installed locally by you, not from the repo, so I can't --reinstall, I have to remove/reinstall)
<popey> i can ssh in
<popey> (as can you) :D
<zyga-solus> oh, right
 * zyga-solus looks
<zyga-ubuntu> popey: locked up as in UI is frozen?
<popey> yeah
<popey> seems apt has finished removing
<zyga-ubuntu> feel free to reboot it if that helps
<popey> doing
<zyga-ubuntu> it is back now
<zyga-ubuntu> I'm installing snapd
<popey> kk
<mup> PR snapd#4030 opened: many: add internal squashfuse copy as "snapfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/4030>
<zyga-ubuntu> popey: that machine is not affected :/
<popey> I can install 16.04 on it
<zyga-ubuntu> mvo: you don't happen to have 16.04 on your desktop?
<zyga-ubuntu> popey: if that's not a burden, please
<popey> I'll make it dual boot
<zyga-ubuntu> popey: I think I should find myself an nvidia box
<zyga-ubuntu> thanks
<popey> also, thanks for introducing me to ubuntu-drivers --autoinstall :D
<popey> I had never seen that before!
<zyga-ubuntu> situation demands creative solutions :)
<mvo> zyga-ubuntu: I have access to a 16.04 machine but its not my main machine, why?
<mvo> zyga-ubuntu: or do you need a 16.04 nvivida machine? that is more complicated, I can do a live-usb stick run on that
<zyga-ubuntu> mvo: popey is preparing dual-boot on a machine with nvidia GPU
<popey> installing now...
<zyga-ubuntu> mvo: and I'll look at what udev is doing to and what may make it fail this way
<mvo> ok
<mvo> zyga-ubuntu: let me know if I should dig out a livecd
<zyga-ubuntu> thank you
<ogra_> zyga-ubuntu, oooh https://forum.snapcraft.io/t/call-for-testing-gimp/1281 see third last post
<ogra_> another one
<zyga-ubuntu> ogra_: I suspect it's something we, ahem, did for nvidia
<zyga-ubuntu> digging
<mvo> zyga-ubuntu: oh, do you have a theory about this failure?
<ogra_> up to now it seems all users hitting it also use nvidia
<zyga-ubuntu> mvo: no but it is clearly related
<zyga-ubuntu> mvo: curiosuly it only affects 16.04
<zyga-ubuntu> mvo: or at least I hope
<ackk> how can I have a field in the snapcraft schema that's either a string or an integer?
<zyga-ubuntu> mvo: if it does affect 17.04 and popey's machine was just unaffected (for whatever reason) we're in deeper waste water
<zyga-ubuntu> ackk: snapcraft schema is just json schema
<mvo> zyga-ubuntu: fwiw, I don't see any of this on my 17.10
<ackk> there doesn't seem to be similar cases at the moment
<mvo> zyga-ubuntu: I can try on a 16.04 now, installing gimp, right?
<zyga-ubuntu> ackk: http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.25
<zyga-ubuntu> ackk: type: [int, string]
<zyga-ubuntu> (sorry, integer)
<ackk> oh
<mvo> zyga-ubuntu: also - hiri appears to be not working still for the reporter in the forum :/
<ackk> I thought it could be just one of them
<ackk> thanks zyga-ubuntu
<zyga-ubuntu> ackk: you can use richer syntax if you want to put different constraints on both
<zyga-ubuntu> ackk: e.g. specific range of ints or specific set of strings
<ackk> zyga-ubuntu, that's cool
<zyga-ubuntu> mvo: so my theory is some of the nvidia changes coupled to specific behavior in udev cause us not to see what udev expects to see (perhaps some data in /run) and then things go belly up
<zyga-ubuntu> mvo: my hope is that with popey's machine and gdb I can see what's the culprit easily
<ackk> zyga-ubuntu, do you have a link on how to do that (type-based constraints)?
<zyga-ubuntu> mvo: I'm also scavenging for HDDs to install 16.04 on an old laptop I have
<zyga-ubuntu> ackk: no, sorry, I think they removed that from the schema, let me look for one more moment
<mup> PR snapcraft#1382 closed: rust plugin: make libc configurable <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
<ackk> zyga-ubuntu, ah, I think I found it https://cswr.github.io/JsonSchema/spec/multiple_types/
<mvo> zyga-ubuntu: does the udev_enumerate error happens only on nvidia? did ogra_ have a nvidia on the machine he hit it with?
<ogra_> mvo, yes i did
<zyga-ubuntu> ackk: ah, I'm wrong
<zyga-ubuntu> ackk: http://json-schema.org/latest/json-schema-validation.html#rfc.section.6.28
<zyga-ubuntu> ackk: you can use oneOf to define schema that applies
<zyga-ubuntu> ackk: so oneOf: [{type: "integer"}, {type: "string"}]
<zyga-ubuntu> ackk: and then you can put extra constraints in each
<zyga-ubuntu> mvo: it looks like it
<mup> PR snapcraft#1512 closed: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512>
<zyga-ubuntu> mvo: unfortunately following udev source dry is a bit hard as it's doing a whole lot of things
<zyga-ubuntu> not that many things can fail though so I think we can find it
<mvo> zyga-ubuntu: ok, I create a 16.04 disk now too, just in case, looks really important
<popey> zyga-ubuntu: sorry for the delay, seems you can't just install 16.04 on a system which already has 17.10 - ext4 extended attributes cause 16.04 to freak and shit the bed
<zyga-ubuntu> popey: you can disable them
<popey> i booted to 17.10 to resize the partition
<zyga-ubuntu> popey: boot to 17.04 and use tune2fs
<popey> re-rebooting to 16.04 to install
<zyga-ubuntu> popey: tune2fs -O^metadata_csum
<zyga-ubuntu> that will fix it
<zyga-ubuntu> (been there done that)
<popey> hah
<popey> thanks
<zyga-ubuntu> popey, mvo: there's a logging feature
<zyga-ubuntu> we can enable it
<zyga-ubuntu> just one sec
<ogra_> geez, really ?!?! we do incompatible filesystem changes between two releases ?
<ogra_> thats insane
<zyga-ubuntu> popey: on your affected machine
<popey> maybe i have an old 16.04 iso on my stick
<zyga-ubuntu> popey: export SYSTEMD_LOG_LEVEL=verbose_debug
<zyga-ubuntu> popey: for now that's it, try running it again
<popey> where will i expect more logging to appear?
<zyga-ubuntu> no idea yet
<zyga-ubuntu> that part of the code is generated on compile time
<zyga-ubuntu> I'm trying to see
<zyga-ubuntu> there's SYSTEMD_LOG_TARGET=
<zyga-ubuntu> but not sure what the values are :/
<zyga-ubuntu> popey: try also setting SYSTEMD_LOG_TARGET=console
<zyga-ubuntu> popey: (you can try journal or syslog as well)
<zyga-ubuntu> popey: then run snap that fails to start
<popey> nothing in journalctl if i set those vars and run a snap
<zyga-ubuntu> and no denials either?
<popey> correct
<popey> (16.04 installing finally)
<ogra_> zyga-ubuntu, you could try "udevadm monitor"
<ogra_> popey, ^^
<popey> no output
<ogra_> :(
<ogra_> well, thats exactly what i observed too ... no log output anywhere ... neither dmesg, nor journald nor syslog
<zyga-ubuntu> I'll patch snap-confine to enable udev logging
<zyga-ubuntu> or not, this is not doing anything anymore
 * zyga-ubuntu looks deeper
<zyga-ubuntu> popey: can it be reproduced on your other machine?
<popey> other is 17.10/intel, no
<popey> ooh, i have another other other machine which is 16.04 intel
 * popey tries on that
<zyga-ubuntu> popey: and on the one with 16.04 and nvidia?
<zyga-ubuntu> does it fail there?
<popey> stil installing on that one
<popey> fails on my main laptop, which is 16.04 nvidia of course
<zyga-ubuntu> ah, ok
<popey> tested on intel 16.04 laptop, don't see the issue here
<popey> (however, ogra_ said it was 'solved' with a reboot, so dunno if I just havent triggered the issue on this laptop yet)
<ogra_> yeah, i cant reproduce it since that reboot
<popey> huh, this clean 16.04 install is offering me an upgrade to 17.04
<popey> i thought we only did lts to lts offers on lts releases
<ogra_> is that 16.04 or 16.04.x ?
<ogra_> might be the original 16.04 allows that
<popey> not sure, lsb_release shows 16.04.3 now
<popey> but I'm mid dist-upgrade which probably changed that
<ogra_> hm, weird
<ogra_> better ask in #ubuntu-release if thats desired
<popey> ya
 * zyga-ubuntu has some annoying back pain :/
<zyga-ubuntu> popey: can you reproduce the issue on your machine?
<popey> back pain!? Yes, I have that too! Shall i file a bug?
 * Chipaca goes for a run
<ogra_> yes, please, i'll happily confirm
<ogra_> (or rather un-happily ....)
<ogra_> heh
<ogra_> seems https://launchpad.net/spine actually exists
<kalikiana> :-D
<kalikiana> nice one
<zyga-ubuntu> popey: any luck
<zyga-ubuntu> ?
<popey> just dist upgrade finished and its rebooting
<popey> you should have ssh access, but not tested snaps yet
<popey> took ages to dist-upgrade 700+ packages
<popey> zyga-ubuntu: just installing a test snap on it now
<ogra_> popey, makes you really want an ubuntu core based desktop eh ? :)
<popey> hah
<zyga-ubuntu> popey: I still get connection refused
<popey> huh
<popey> oh, not installed ssh server
<popey> one mo
<popey> it doesnt have the nvidia driver yet
<popey> but you should be able to get in now?
<zyga-ubuntu> logged in, thanks
<popey> its set to auto login, and boot to 16.04 so feel free to reboot or whatever
<zyga-ubuntu> thank you
<zyga-ubuntu> popey: I launched the giraffe, I'm afraid it works
<popey> you're not on binary nvidia driver tho
<zyga-ubuntu> popey: aah
<zyga-ubuntu> thanks!
<zyga-ubuntu> installing now
<zyga-ubuntu> but this is excellent
<zyga-ubuntu> if it fails after installation we'll have clear evidence that the relationship is real
<popey> good point
<zyga-ubuntu> rebooting
<popey> zyga-ubuntu: desktop is up
<zyga-ubuntu> reproduced!
<zyga-ubuntu> ok
<zyga-ubuntu> thank you for setting this up!!!
<popey> np
<jdstrand> zyga-ubuntu: ohh
<jdstrand> zyga-ubuntu: artful without nvidia: /snap/bin/test-policy-app.network-control: udev_enumerate_scan failed
<zyga-ubuntu> jdstrand: that's just wonky
<zyga-ubuntu> jdstrand: I'll focus on 16.04 now
<zyga-ubuntu> jdstrand: but ... wonky!
<ogra_> zyga-ubuntu, you should probably add the word "nvidia" somewhere to your post ... nothing in the thread talks about it yet
<ogra_> "the binary driver" could be anything :)
<zyga-ubuntu> +1
<zyga-ubuntu> done
<jdstrand> zyga-ubuntu: zyga-ubuntu it's repeatable. I suspect something wrong with that interface. gimme a sec
<ogra_> thx
<zyga-ubuntu> jdstrand: network-control? I see this on opengl and ohmygiraffe
<zyga-ubuntu> jdstrand: I'm on artful and I never reproduced it here FYI
<mcphail> My giraffe is dead on 16.04 o/
<popey> mcphail: do you get the udev error message on the command line?
<zyga-ubuntu> we're working on reviving it
<mcphail> Yep. Using nvidia drivers
<mcphail> zyga-ubuntu: :)
<zyga-ubuntu> jdstrand: side note, terrible C apis without any error information
<zyga-ubuntu> "I failed but beats me why"
<jdstrand> yes
<jdstrand> zyga-ubuntu: seriously
<jdstrand> network-control is messed up
<jdstrand> zyga-ubuntu: udev doesn't like this line: KERNEL=="tun[0-9]*", TAG+="snap_test-policy-app_network-control"
<zyga-ubuntu> jdstrand: interesting
<zyga-ubuntu> jdstrand: I don't use that interface here but opengl has SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_ohmygiraffe_ohmygiraffe"
<zyga-ubuntu> if it's the regexp it looks just the same
<zyga-ubuntu> jdstrand: how do you know it doesn't like it?
<jdstrand> there's a lot of regexes that look fine. opengl works fine here
<ogra_> https://github.com/snapcore/snapd/pull/4018/files
<mup> PR #4018: interfaces: fix udev rules for tun <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4018>
<ogra_> there was a recent change ^^
<jdstrand> zyga-ubuntu: because I commented it out of /etc/udev/rules.d/snap.test-policy-app then did: sudo udevadm trigger && for i in /snap/bin/test-policy-app.* ; do echo -n "$i: " && $i -c "echo ok" ; done 2>&1 | grep -v ok
<ogra_> (not sure it is realted, but it changed the line right befor the tun[0-9] one)
<zyga-ubuntu> aha
 * zyga-ubuntu returns to gdb
<jdstrand> gimp does not have network-control
<jdstrand> ogra_: you are seeing this today?
<ogra_> no, i have never seen it again
<jdstrand> popey: you are seeing this now?
<ogra_> (but i also did not reboot my desktop since i reported it)
<popey> "this"?
 * jdstrand is going to have to change rooms soon
<jdstrand> popey: udec scan issue
<jdstrand> udev
<ogra_> jdstrand, popey can reliably reproduce it and zyga-ubuntu is remotely logged in to the machine
<popey> i am unable to run some snaps on my 16.04 system, yes.
<jdstrand> ok
<jdstrand> popey: ok, nm I'll work with zyga-ubuntu
<popey> kk
<popey> he has access to an nvidia 16.04 desktop on my desk here
<jdstrand> zyga-ubuntu: do you have KERNEL=="nvidia*", TAG+="..." in your /etc/udev/rules.d/* file?
<zyga-ubuntu> stepping over now
<zyga-ubuntu> yes
<zyga-ubuntu> this is 2.28.1 still
<zyga-ubuntu> SUBSYSTEM=="drm", KERNEL=="card[0-9]*", TAG+="snap_ohmygiraffe_ohmygiraffe"
<zyga-ubuntu> KERNEL=="nvidia*", TAG+="snap_ohmygiraffe_ohmygiraffe"
<zyga-ubuntu> KERNEL=="vchiq",   TAG+="snap_ohmygiraffe_ohmygiraffe"
<jdstrand> zyga-ubuntu: if you comment out the nvidia one, does it stop?
<jdstrand> ie, does the scan work?
<jdstrand> zyga-ubuntu: you need to udevadm trigger
<jdstrand> zyga-ubuntu: changing rooms. brb
<jdstrand> zyga-ubuntu: I'm back. did it work? all you need to do is 'snap run --shell ohmygiraffe' I think
<jdstrand> eg, edit /etc/udev/rules.d/70-snap.ohmygiraffe.rules, sudo oudevadm trigger ; snap run --shell ohmygiraffe
<zyga-ubuntu> jdstrand: I didn't try yet, I'm in gdb going down to the place where it fails
<zyga-ubuntu> I think I found it
<jdstrand> zyga-ubuntu: well, the point is with nvidia that this is more fallout from not including the my nvidia fix in 2.28. ie, nvidia should be fixed with yesterdays hotfix
<zyga-ubuntu> it fails in enumerator_scan_devices_tags
<zyga-ubuntu> specifically this call inside:                 r = enumerator_scan_devices_tag(enumerator, tag);
<jdstrand> that doesn't surprise me. nvidia* isn't a thing (the sysfs issue)
<zyga-ubuntu> jdstrand: checking without the nvidia tag now
<zyga-ubuntu> jdstrand: it still fails
<zyga-ubuntu> zyga@zyga-P55A-UD3:~/systemd-229/src$ ls /run/udev/tags/snap_ohmygiraffe_ohmygiraffe -l
<zyga-ubuntu> total 0
<zyga-ubuntu> -r--r--r-- 1 root root 0 Oct 12 13:01 +drivers:nvidia
<zyga-ubuntu> -r--r--r-- 1 root root 0 Oct 12 13:01 +module:nvidia
<zyga-ubuntu> -r--r--r-- 1 root root 0 Oct 12 13:01 +module:nvidia_uvm
<zyga-ubuntu> -r--r--r-- 1 root root 0 Oct 12 13:41 c226:0
<zyga-ubuntu> I think this is not right
<jdstrand> zyga-ubuntu: dude, it isn't :)
<jdstrand> zyga-ubuntu:  udev tagging requires things to be exposed in sysfs
<zyga-ubuntu> I understand, I mean that I removed that line and re-triggered udev
<jdstrand> zyga-ubuntu: nvidia is not GPL so it isn't in there. this is the whole reason I did the PR in snap-confine for nvidia
<jdstrand> ok
<jdstrand> so, did the scan fail even though the line was not in there?
<zyga-ubuntu> yes
<zyga-ubuntu> and after the scan I expected those files in /run/udev/tags/../ to go away
<jdstrand> hmm
<zyga-ubuntu> after removing them it works okay (the tags)
<jdstrand> zyga-ubuntu: I suspect that the subsystem drm one above might be the problem then
<kalikiana> brb, coffee break
<jdstrand> zyga-ubuntu: oh
<zyga-ubuntu> aha, interesting
<jdstrand> actually, that might be ok
<zyga-ubuntu> note, they were not added back after running trigger again (
<zyga-ubuntu> (after removing them)
<jdstrand> zyga-ubuntu: so, now that the tags are removed, with the nvidia one commented out and udevadm trigger done, does it work?
<jdstrand> ok good
<zyga-ubuntu> yes
<jdstrand> so *yes*, the pr yesterday fixes it at least after a reboot
<zyga-ubuntu> well
<zyga-ubuntu> ...
<zyga-ubuntu> I spoke too soon
<zyga-ubuntu> I removed the tags
<zyga-ubuntu> and I was running /bin/true
<zyga-ubuntu> real app fails
<zyga-ubuntu> ://
<jdstrand> does the real app have the new tags?
<zyga-ubuntu> jdstrand: I was running snap-confine manually (instead of the real app)
<zyga-ubuntu> oddly enough after re-adding that nvidia tag to udev rules I don't get the files in /run/udev/tags/.../ back
<zyga-ubuntu> is udevadm trigger really the right thing?
<jdstrand> ok. can we back up. can you removed the tags, make sure that nvidia is commented out of the /etc/udev/rules.d for that app, run udevadm trigger, then snap run --shellapp
<jdstrand> s/app/ app/
<zyga-ubuntu> I'll run what we really do for udev
<jdstrand> there might be bugs in udev trying to tag nvidia since it isn't sysfs compatible
<jdstrand> I suspect it is partially doing things
<jdstrand> so we need a clean state
<zyga-ubuntu> one se
<zyga-ubuntu> c
<zyga-ubuntu> jdstrand: ok, with the nvidia udev rule commented out, I ran udevadm control --reload-rules, followed by udevadm trigger
<zyga-ubuntu> I don't see the nvidia device tags
<zyga-ubuntu> trying to run the app
<zyga-ubuntu> I cannot create GL context, it fails
<jdstrand> that's different from the scan issue
<zyga-ubuntu> let me reboot that machine
<zyga-ubuntu> yes
<jdstrand> that is because snap-confine doesn't add the nvidia devices to the cgroup
<zyga-ubuntu> I suspect now it doesn't crash from udev things
<zyga-ubuntu> aahh
<zyga-ubuntu> right
<zyga-ubuntu> that makes sense
<jdstrand> ie, you aren't running s snapd with yesterday's fix
<zyga-ubuntu> let me try with updated snap-confine from the branch
<zyga-ubuntu> so what does it tell us? all is fine and we need to roll out .4?
<zyga-ubuntu> (fingers crossed)
<jdstrand> zyga-ubuntu: all you need is --beta
<zyga-ubuntu> ok
<jdstrand> zyga-ubuntu: nvidia is fine with .4
<zyga-ubuntu> I'll refresh to beta
<jdstrand> Imean, feel free to test again
<jdstrand> but, I found a problem with network-control. I'm testing that againmyself
<zyga-ubuntu> aha
<zyga-ubuntu> jdstrand: it works now
<zyga-ubuntu> popey: thank you for setting this up and allowing us to test this
<jdstrand> ok, good
<zyga-ubuntu> jdstrand: I'll go to the standup now
<zyga-ubuntu> jdstrand: let us know if we need a .5
<zyga-ubuntu> (I mean, mvo will do a .5 anyway)
<zyga-ubuntu> for another issue
<zyga-ubuntu> but we'd like to know if we can pull in a fix from you
<mvo> zyga-ubuntu: yeah, we need one anyway, we just need to know if we need one more fix in it or not
<zyga-ubuntu> right
<zyga-ubuntu> mvo: tests unhappy about squasfuse
<zyga-ubuntu> because of silly stuff like
<zyga-ubuntu> imported/squashfuse/m4/pkg.m4:89:22: "occurence" is a misspelling of "occurrence"
<zyga-ubuntu>  /o\
<ackk> mhm, shellcheck errors in snapd master for me
<ackk> zyga-ubuntu, what shellcheck version should I be using?
<zyga-ubuntu> ackk: post 16.04
<zyga-ubuntu> or remove it
<zyga-ubuntu> (shellcheck)
<zyga-ubuntu> and re-configure
<ackk> zyga-ubuntu, fails on artful
<ackk> with 0.4.6
<mup> PR snapcraft#1608 closed: tests: fix the duplicate plainbox test scenarios <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1608>
<mup> PR snapcraft#1611 closed: plainbox-provider plugin: init PROVIDERPATH <bug> <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1611>
<zyga-ubuntu> ackk: what's the failure?
<ackk> zyga-ubuntu, http://paste.ubuntu.com/25726179/
<ackk> they seem legit
<mup> PR snapcraft#1599 closed: Fixed StoreReleaseError format for BAD REQUEST error <Created by clobrano> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1599>
<c-lobrano> \0/
<zyga-ubuntu> ah, they are really legit
<zyga-ubuntu> feel free to fix those if you want
<mup> PR snapcraft#1601 closed: snapcraft.yaml: don't re-use build dir <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1601>
<mup> PR snapd#4031 opened: interfaces/network-control: remove incorrect rule for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031>
<jdstrand> mvo, zyga-ubuntu: https://github.com/snapcore/snapd/pull/4031 should fix the udev scan error with netwrk-control. I'm a bit puzzled why spread tests didn't reveal this, since we are testing network-control connections. perhaps it is becahse the tun module isn't loaded in spread? unfortunately, I'm very booked today, so I cannot deeply test that pr or investigate why spread didn't catch it
<mup> PR #4031: interfaces/network-control: remove incorrect rule for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031>
<ackk> zyga-ubuntu, and now I get http://paste.ubuntu.com/25726221/
<ackk> which seems somewhat worse :)
<kalikiana> re
<ackk> wait, why is GOPATH a list?
<ackk> oh, TIL it's not a single dir
<ogra_> jdstrand, hmm,. wont that break tun devices (given there is allways numbering on the actual device)
<jdstrand> ogra_: no. tun[0-9]* are virtual devices like other network devices. they don't show up in /dev, so don't need to be added to the device cgroup, so don't need to be tagged
<ogra_> jdstrand, then shoulldnt we do the same for tap ? o do they actually ceate dev nodes ?
<jdstrand> maybe
<jdstrand> let me see how they work (I verified tun0 as virtual)
<ogra_> it just looked inconsistent to me when checking your PR
<jdstrand> A TUN/TAP driver does provide a virtual network interface ...
<jdstrand> yes, I'll remove that. good catch
<zyga-ubuntu> jdstrand: question: why does it cause havok when we have a rule like that?
<zyga-ubuntu> jdstrand: I would have assumed udev will just find nothing to do
<mvo> zyga-ubuntu: re /usr/lib/nvidia : no such file or directory
<ackk> zyga-ubuntu, https://github.com/snapcore/snapd/pull/4032 fwiw
<mup> PR #4032: fix shell errors from shellcheck <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4032>
<mup> PR snapd#4032 opened: fix shell errors from shellcheck <Created by albertodonato> <https://github.com/snapcore/snapd/pull/4032>
<ogra_> mvo, it is usuallly versioned
<ogra_> ah, no, i'm lying
<ogra_> ls -d /usr/lib/nvidia*
<ogra_> /usr/lib/nvidia  /usr/lib/nvidia-361  /usr/lib/nvidia-367  /usr/lib/nvidia-375  /usr/lib/nvidia-375-prime
<zyga-ubuntu> mvo: sorry, one of those that ogra_ mentioned
<zyga-ubuntu> ackk: thank you!
<jdstrand> zyga-ubuntu: re question> seems like a bug. no idea
<zyga-ubuntu> jdstrand: thank you for confirming that, I feel the same
<zyga-ubuntu> jdstrand: I had a, perhaps, related case while exploring systemd network config
<zyga-ubuntu> jdstrand: when I input wrong matching filter (I had a typo)
<zyga-ubuntu> jdstrand: the match would target *all* devices
<zyga-ubuntu> jdstrand: and rename all network interfaces to the same name in some random order, ending terribly
<zyga-ubuntu> jdstrand: could it be that udev sees something it doesn't like, ignores that condition and then blats the assignments to everything it knows about?
<ogra_> slangasek, did you see my llast comment on bug 1707888 (i think there is still one subiquity issue there)
<mup> Bug #1707888: ethernet defaults for unconnected device are wrong <subiquity:New> <https://launchpad.net/bugs/1707888>
<slangasek> ogra_: so your argument is that we should have a different default netplan config for console-conf?
<slangasek> I'm not convinced this is what's expected for ubuntu-core in generall
<slangasek> I understand that for certain devices we might want to be able to specify which interfaces are dhcp by default vs not
<slangasek> so I'm fine to un-dupe
<ackk> zyga-ubuntu, np, thanks for looking at the PR
<ogra_> slangasek, well, my argument is that a nic config i never touched should not leave me with some unwanted configuration for that nic
<slangasek> ogra_: "that you've never touched" - you mean when you acked the screen saying that console-conf sees the device, and will try to do dhcp on it?
<ogra_> slangasek, IMHO a first boto of a core device should come up with all NICs off by default and only afte i configured one it should be used
<slangasek> ogra_: that is not a generally applicable rule.
<ogra_> slangasek, well, yes and no ... if i manually configure wlan on a pi3 (which has wlan0 and eth0 ) but never touch anything else, then my ack will still leave me with a full configured eth0 that i did not configure
<slangasek> I can accept that individual devices might need to specify a different default policy per NIC.  I do not agree that this is a sensible default policy for all ubuntu-core devices.
<ogra_> what is the use for it ?
<slangasek> you know console-conf is an optional setup step?
<slangasek> not all devices are going to have console-conf as the first boot experience.  some have to be non-interactive.
<ogra_> you *need* to either go through subiquity, cloud-init or apply some assertion to actually get a poper network config
<slangasek> non-interactive + no network by default == expensive doorstop
<ogra_> withooout either of these you should noot suddenly have the device online
<slangasek> I've never heard assertions mentioned in the context of network config, are there docs on this?
<ogra_> welll, you can somehoow suplly a netplan yaml ... not sure how that works though
<ogra_> in any case what does the DHCP by default gain you apart fom insecurity if you dont have a poperlly configued rest of the system ?
<slangasek> it gains you... the ability to talk to the store and actually come up as a snappy system
<ogra_> (and 2min hangs oon boot if you actualy do not configure eth0)
<ogra_> also note that eth0 *only* works because we foce the new naming schemes off via the kernel cmdlline
<jdstrand> mvo, zyga-ubuntu: I want to be very clear that https://github.com/snapcore/snapd/pull/4031 needs to be in 2.28.5
<mup> PR #4031: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031>
<ogra_> (by setting net.ifnames=0 ... it wont work at all when you drop that)
<zyga-ubuntu> jdstrand: noted
<mvo> jdstrand: I targeted it for 2.28.5
 * jdstrand is worried about net infrastructure snaps
<ogra_> (you just end up with a brooken hardcoded eth0 device in netplan.yaml)
<zyga-ubuntu> jdstrand: you have a unit test failure now
<ogra_> slangasek, to talk to the store ? without having the device configured ?
<ogra_> (you want an account and keys and all ...)
<mvo> zyga-ubuntu: any ideas how to further debug the hiri&nvidia-384 issue? if I strace it I see a mmap() before it dies
<ogra_> (which you get via the assertion or manual config)
<zyga-ubuntu> mvo: strace the outside of snap copy
<zyga-ubuntu> mvo: and strace the one inside
<zyga-ubuntu> mvo: it's super tedious though :/
<zyga-ubuntu> mvo: does devmode help?
<zyga-ubuntu> mvo: and one more idea
<zyga-ubuntu> mvo: nsenter into the mount namespace
<zyga-ubuntu> mvo: and see if *that* works
<zyga-ubuntu> mvo: then you have no seccomp, no apparmor, no cgroups
<zyga-ubuntu> mvo: is it our layout or is it something else
<mvo> zyga-ubuntu: devmode helps with the debugging but still fails
<mvo> zyga-ubuntu: I can `snap run --shell hiri`, thats fine, but when I try to run it boom
<zyga-ubuntu> mvo: no, not like that
<zyga-ubuntu> mvo: just nsenter
<zyga-ubuntu> mvo: I'll see if 16.04 + hiri work on my system, I found a HDD I can swap inside
<mvo> zyga-ubuntu: just nsenter -m... has the same problem
<zyga-ubuntu> mvo: that's good to know
<mvo> zyga-ubuntu: crash in libnvidia-glcore.so.
<zyga-ubuntu> mvo: so it's not our confinement
<zyga-ubuntu> mvo: just our laoyut
<zyga-ubuntu> *layout
<zyga-ubuntu> mvo: hmmmm
<zyga-ubuntu> mvo: a view of /proc/pid/maps inside and out could help
<zyga-ubuntu> mvo: run hiri on the outside and pastebin a copy
<zyga-ubuntu> ikey: hey
<zyga-ubuntu> ikey: I tried to add indent to solus a few days ago
<zyga-ubuntu> ikey: but I failed miserably
<mvo> zyga-ubuntu: actually I think it is the confinement in some way, I managed to run it from inside the namespace now
<zyga-ubuntu> mvo: can you look at /sys/fs/crgroup/devices/.../devices.list?
<mvo> zyga-ubuntu: sure: "a *:* rwm"
<zyga-ubuntu> that's "all devices"
<zyga-ubuntu> (AFAIK)
<zyga-ubuntu> hmm, that's odd, I would expect a concrete list
<zyga-ubuntu> maybe this snap is not using opengl?
<zyga-ubuntu> (as the interface)
<mvo> zyga-ubuntu: it is using opengl, I'm in devmode right now for easier debugging
<jdstrand> zyga-ubuntu (cc mvo): unit test fixed
<zyga-ubuntu> thanks!
<mvo> zyga-ubuntu: nsenter, setup the right library path> hiri launches. `snap run hiri` -> not
<mvo> thanks jdstrand
<zyga-ubuntu> mvo: may I ask what did you tweak to make it work inside the namespace?
<mvo> zyga-ubuntu: I just setup the LD_LIBRARY_PATH
<mvo> zyga-ubuntu: I think that was all
<mvo> zyga-ubuntu: I will try again
<zyga-ubuntu> mvo: did you get any seccomp kill?
<mvo> zyga-ubuntu: I think not
<zyga-ubuntu> mvo: those are not DENIED (the message is different)
<mvo> I check, I just got a machine crash
<zyga-ubuntu> mvo: so you made it work inside nsentere'd namespace with some LD_LIBRARY_PATH tricks
<zyga-ubuntu> but not inside the devmode confinement, right?
<mup> PR snapcraft#1612 opened: cross compile: enable cross compilation of i386 kernel on x86-64 hosts <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1612>
<kalikiana> sergiusens: wrt https://github.com/snapcore/snapcraft/pull/1568 the problem is that x revisions are arbitrary, so installing the same snap on two systems may lead to different filenames - different filenames won't ever be compared with my code... now, after some rubber ducking, I realize, I could try to query the snap in use in the container: except, it'll be ugly, `snap info` can't be parsed nicely, `file -b` sort of works...
<kalikiana> pondering what to do here
<mup> PR snapcraft#1568: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568>
<mvo> zyga-ubuntu: correct
<zyga-ubuntu> mvo: you could disable apparmor/seccomp/cgroup initialzation and see if that makes it work
<zyga-ubuntu> mvo: and then re-enable until you find the one that breaks it
<zyga-ubuntu> once we know which of the backends it is we can look at it more closely
<mvo> zyga-ubuntu: thanks, thats a good one - its setup_devices_cgroup()
<kalikiana> sergiusens: I'm thinking to go with `file -b` in all cases, since hypothetically you could also have a revision from the store that's not being used...
<mvo> zyga-ubuntu: well, or snappy_udev_init()
<zyga-ubuntu> mvo: ha
<zyga-ubuntu> mvo: so...
<zyga-ubuntu> mvo: disable devmode please
<zyga-ubuntu> mvo: restart the thing and look at devices.list again
<zyga-ubuntu> mvo: we can add stuff there, one by one,
<mvo> ok
<mvo> on it
<zyga-ubuntu> mvo: and you can start the app (from a snap run --shell session)
<zyga-ubuntu> mvo: just don't restart the app as it will re-configure the cgroup
<zyga-ubuntu> mvo: let's start with a list of devices you get, as a baseline
<zyga-ubuntu> mvo: then let's look at /dev/nv* on the outside and look for missing things
 * zyga-ubuntu hugs mvo who fights this tirelessly
<slangasek> ogra_: 2 minute hang on boot is a separate question, and that is in progress with an extension to the netplan schema
<itsfemme[m]> wishlist item: setting per snap VPN/tor configs
<ogra_> slangasek, what about the hardcoded NIC name ? if we ever drop the net.ifnames=0 it willl be boken anyway
<ogra_> *broken
<ogra_> it only works today because there is an actual eth0 ... which do dont have anymore once you enable "predictable NIC names"
<mvo> zyga-ubuntu: ha!
<mvo> zyga-ubuntu: looks like /dev/nvidia-modset was missing
<mvo> zyga-ubuntu: and nvidia-uvm has a different major number for me than in hte source. I will push a PR shortly. this was a PITA
<mvo> zyga-ubuntu: thank you so much for your help
<zyga-ubuntu> mvo: can you amend the forum post with the numbers of each of those? I'll cross check with the kernel docs and with my machine
<zyga-ubuntu> mvo: and compare (if you can) to 17.10 machine on same HW)
<zyga-ubuntu> mvo: last thing I want is a per-kernel-version if statement
<mvo> zyga-ubuntu: meh, looks like nvidia-uvm gets its major number somewhat dynamically :(
<zyga-solus> mvo: ok, we can stat it and add a code path that does the right thing
<slangasek> ogra_: subiquity does not hard code the name eth0, only ubuntu-core does that
<ogra_> slangasek, i think netplan does
<slangasek> no
<ogra_> we dont apply a default yaml i think
<ogra_> hmm
<mvo> zyga-solus: yeah, looking at this next
<mup> PR snapd#4033 opened: snap-confine: add support for handling /dev/nvidia-modeset <Created by mvo5> <https://github.com/snapcore/snapd/pull/4033>
<ogra_> ubuntu-core-config (0.6.40+ppa11) xenial; urgency=medium
<ogra_>   * etc/netplan/00-snapd-config.yaml:
<ogra_>     - add default network config
<ogra_>  -- Michael Vogt <michael.vogt@ubuntu.com>  Fri, 30 Sep 2016 19:26:34 +0200
<ogra_> slangasek, ok, you are right :)
<ogra_> so it is actually self inflicted pain .. but shouldnt subiquity completely overwrite that ?
<slangasek> ogra_: "overwrite" it how?  netplan brings up the network devices however they've been pre-configured, then subiquity (console-conf) gives the user the option to reconfigure... that's it
<ogra_> slangasek, well, subiquity calls netplan generate and netplan apply at the end, or doesnt it ?
<ogra_> i would expect the generate to actually generate a new config
<slangasek> well, it does, no?
<zyga-ubuntu> mvo: reviewed
<ogra_> the question is, does it pick up that dhcp setting from the former file or is that something thats a default inside subiquity (for eth0)
<mvo> zyga-ubuntu: thanks, working on it. funny, was what I wanted to do in a followup anyway :)
<zyga-ubuntu> mvo: if you stat you can drop the constants
<zyga-ubuntu> just stat the filename and apply that
<zyga-ubuntu> it should be tiny and if jdstrand reviews we can get this in quickly
<mvo> zyga-ubuntu: it is tiny
<mvo> zyga-ubuntu: is it ok for me to amend the commit? for easier cherry picking?
<zyga-ubuntu> mvo: yes
 * zyga-ubuntu always rebases if nobody looks
<zyga-ubuntu> mvo: I'm checking kernel tree for 254
<zyga-ubuntu> it's not defined as a static number in admin-guide.txt but it might be just stale
<mvo> zyga-ubuntu: no worries, I use major/minor now everywhere
<Chipaca> anybody have systemd.unit(5) from trusty to hand?
<zyga-ubuntu> Chipaca: one sec
<zyga-ubuntu> http://manpages.ubuntu.com/cgi-bin/search.py?q=systemd.unit&op=&cx=003883529982892832976%3A5zl6o8w6f0s&cof=FORID%3A9&ie=UTF-8
<mvo> pedronis: do you think you have a moment to answer the question that zyga-ubuntu has in 4026 ?
<zyga-ubuntu> Chipaca: :-(
<zyga-ubuntu> Chipaca: let me boot my vm
<om26er> Hi! Which Ubuntu Core image shall I be using for reliable bluez support ?
<zyga-ubuntu> om26er: hey, ubuntu core doesn't ship bluez, there's a bluez snap and the kernel you use for a device provides the needed bits
<zyga-ubuntu> om26er: short answer: it's complicated
<om26er> zyga-ubuntu: I installed the bluez snap, didn't know about a special kernel
<om26er> I am on edge channel currently
<om26er> ...of Ubuntu Core.
<zyga-ubuntu> om26er: which kernel snap are you using now?
<om26er> zyga-ubuntu: pi2-kernel  4.4.0.1074.74  42    canonical  kernel
<zyga-ubuntu> ah
<zyga-ubuntu> so you are talkin about raspberry pi :)
<om26er> yeah
<zyga-ubuntu> for that I think ppisati or ogra_ can give better advice, I would also recommend discussing this in a thread on forum.snapcraft.io so that others can reuse the knowledge
<ogra_> om26er, you still need some hackery to power up the BT devices on the pi
<ogra_> om26er, https://bugs.launchpad.net/snappy/+bug/1674509/comments/30
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<om26er> oh, I was kind of looking to use UbuntuCore+bluez in a production level software.
<om26er> android <--> BLE
<zyga-ubuntu> mvo: reviewed
<om26er> ogra_: which Ubuntu Core image shall I be using ?
<ogra_> om26er, the edge one
<om26er> I would prefer Stable but WiFi is broken on that one badly.
<om26er> even the edge image crashed for me once, while setting up wifi
<om26er> ...had to run the setup again.
<ogra_> om26er, well, you need the edge gadget and a kernel newer than stable ... so install from edge, switch coe to stable and the kernel snap to beta or so
<ogra_> s/coe/core/
<zyga-ubuntu> mvo: reviewed (again)
<mvo> zyga-ubuntu: \o/
<om26er> who maintains the bluez snap ?
<ogra_> om26er, koza
<zyga-ubuntu> koza: ^
<om26er> koza: when will bluez 5.47 graduate to stable ?
<om26er> also is there a python example for talking to bluez(snap) in another confined snap ?
<zyga-ubuntu> mvo: can you review https://github.com/snapcore/snapd/pull/4031 please
<mup> PR #4031: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4031>
<koza> om26er, snap or deb?
<om26er> koza: snap
<ogra_> koza, we should prehaps schedule some time at the sprint to get that pi3 bluez stuff finished ;)
<zyga-ubuntu> mvo: it looks like this week, while bumpy, is also very much relevant for getting important (and long standing) bugs fixed
<koza> om26er, it is currently in edge, do not have a date in my mind; do you need it for something?
<ogra_> (there is still the hciattach script we need etc)
<koza> ogra_, yes we should
<om26er> koza: nothing specific, though I was building it from source on raspbian and the latest there was 5.47, so wanted to make sure I was using similar stack.
<koza> om26er, snap is at 5.44 and you should be fine with it until the 5.47 lands. i have landing card for it already but not a fixed date ahead of me. cannot do it over night as testing takes time
<om26er> koza: ok no problem. is BLE/GATT working fine on that release ?
<om26er> 5.44 I mean.
<koza> om26er, it is working well
<koza> om26er, it gets better with every bluez release however 5.44 isitself is solid
<ikey> when does the "base snap" functionality land properly?
 * ikey has plans for them
<zyga-ubuntu> ikey: we're working on them still but basics are available in 2.28.x
<ikey> ok
<zyga-ubuntu> ikey: we need tooling around building and using them though
<zyga-ubuntu> ikey: and there are still some hard-coded assumptions (like /proc, /sys and perhaps some we like less)
<ikey> well for my needs its basically i pre-prepare a root and point at it
<ikey> well, /proc /sys aren't so bad i dont think
<zyga-ubuntu> :)
<zyga-ubuntu> yep
<ikey> but multiarch assumptions might be a slap in the face
<ikey> if they exist
<ikey> though relative ../ symlinks can solve that
<zyga-ubuntu> mvo has a minimal base snap
<zyga-ubuntu> I think it has very little inside
<om26er> koza: sounds great. If you could share some working examples that would be really helpful. Even a basic pair, ping/pong would suffice.
<ikey> can a base snap be run? or just exposed as a dependency?
<ikey> ideally id want a self contained snap, but if its not possible then fine
<zyga-ubuntu> https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-base-bare
<zyga-ubuntu> that's a base snap
<ikey> oh
<zyga-ubuntu> you can just start from that
<ikey> so id build that with snapcraft?
<zyga-ubuntu> and we'll gladly resolve issues
<zyga-ubuntu> yep
<ikey> ok
<mup> PR core#61 opened: Also "mask" services when disabling them <Created by mvo5> <https://github.com/snapcore/core/pull/61>
<zyga-ubuntu> as you find them :)
<ikey> and is snapcraft going to punch me in the face for using a peasant OS?
<ikey> and not having dpkg?
<zyga-ubuntu> :/
<zyga-ubuntu> probably
<zyga-ubuntu> but
<ikey> lol
<zyga-ubuntu> it's just a snap pack thing
 * om26er will be doing websockets(actually WAMP) over BLE.
<zyga-ubuntu> so you don't need snapcraft for this
<zyga-ubuntu> just mksquashfs
<ikey> aha
<ikey> ok thats good
<zyga-ubuntu> we added a new "snap pack" command in master
<koza> om26er, start with our documentation to bluez snap and bluez itself: https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/index
<koza> om26er, any bluez example will work with core, DBus interfaces are the same
<mvo> zyga-ubuntu, ikey I don't know most of the context but I will comment anyway. there is a "bare" base snap that can be used. it has *nothing* inside except for directory mount-points. no libc, no content
<ikey> thats good, no libc
<ikey> ok ill give you context, cant keep this quiet long
<ikey> make it easier :P
<ikey> im going to make a solus derived runtime that caters exclusively to steam
<om26er> ogra_: where to get hciattach for this: https://bugs.launchpad.net/snappy/+bug/1674509/comments/30
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<ikey> and ship a strict linux-steam-integration entry point in it
<ikey> so it'll be a build of steam that actually doenst suck, and will work the same on any distro
<ikey> even distros that cant multilib
<ikey> it'll fix the various performance and functionality issues with the existing steam stuff
<mvo> ikey: woah, that sounds pretty specacular!
<ikey> i had *originally* planned to do this in flatpak land a long time ago but it suffers design deficiencies
<ikey> notably the layering and driver functionality
<ikey> the driver stuff in snapd for nvidia is much better
<ikey> (because we can trust nvidia proprietary driver C ABI)
<zyga-ubuntu> ikey: I'd like to understand your insight into that to avoid such issues in snapd in the future
<ikey> zyga-ubuntu, flatpak tries to strongly discourage new root imagery
<ikey> so you inherit from another all the time
<ikey> even the KDE runtime does this
 * zyga-ubuntu hugs mvo who fixed nvidia for a lot of people just now :)
<ikey> they also use glvnd inside the flatpak runtimes
<ikey> and dynamically download/install a related series..
<ikey> doesnt *actually* use the host driver
<mvo> zyga-ubuntu: a busy day, one more fix (xdg-open) and then I call it a day and get a big beer^Wtea
<ikey> its.. ya. its wrong.
<ikey> also the flatpak system is using flatpak-builder (json, seriously?), with yocto derived images
<ikey> i had to poke them forever before they started using any secure cflags anywhere, but theres no optimisation at all
<ikey> so any flatpak app is going to run like a spud.
<ikey> the runtime is just a meta distro, not a real distro
<ikey> so my steam snap would be a solus derived runtime that can also make additional tweaks to cover full abi compatibility for steam runtime & games..
<ikey> and take the pressure off the distros finally.
<zyga-ubuntu> ikey: wow, that's pretty darn cool
<ikey> https://github.com/ikeydoherty/runtime-abi-check <- also working on this in parallel so we can assert a full runtime compatibility check
<zyga-ubuntu> ikey: do you think you could be more vocal about it, I'm sure many people will want to hear this
<ikey> zyga-ubuntu, well id tried to keep it under wraps at first but ive a big mouth :P
<ikey> cats out of the bag first and even people on reddit have sussed out what im up to
<ikey> s/first/now/
 * ikey unbraintwitches
<zyga-ubuntu> ikey: let us know if we can help
<ikey> certainly - this is basically what my vague snapcraft post was about the other day btw :P
 * ikey goes to spill the beans properly on G+
<ogra_> om26er, it comes with the snap
<zyga-ubuntu> ogra_: thank you for testing https://github.com/snapcore/core/pull/61#pullrequestreview-68970473 !!!
<mup> PR core#61: Also "mask" services when disabling them <Created by mvo5> <https://github.com/snapcore/core/pull/61>
<ogra_> zyga-ubuntu, waiting for travis and willl merge then too
<zyga-ubuntu> mvo: I assume you want that for the new core
<ogra_> we definitely do
<ogra_> (breaks a customer)
<mup> PR core#61 closed: Also "mask" services when disabling them <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/61>
<zyga-ubuntu> Chipaca: can you do a quck 2nd on https://github.com/snapcore/snapd/pull/4027
<mup> PR #4027: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <https://github.com/snapcore/snapd/pull/4027>
<Chipaca> probably
<mup> PR snapd#4029 closed: packaging: remove .mnt files on removal <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4029>
<Chipaca> zyga-ubuntu: +1
<zyga-ubuntu> thank you
<mup> PR snapd#4027 closed: spread: allow setting SPREAD_DEBUG_EACH=0 to disable debug-each section <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4027>
<ikey> https://plus.google.com/+Solus-Project/posts/ZL8C2wBqbfg
 * ikey has let knowledge slip
<zyga-ubuntu> ikey: :heart: (I wish IRC did this)_
<ikey> :D
<ikey> fwiw i once wrote an IRC client in java years ago (Called it Dave2) - and I thought the best way to implement smilies would be to use a web view. And it worked fantastically
<ikey> That is, until the other guys on the channel figured out a flaw in my plan. And started sending <img src=...
<zyga-ubuntu> goatse on IRC never looked the same
<ikey> lol
<zyga-ubuntu> :>
<mup> PR snapcraft#1612 closed: cross compile: enable cross compilation of i386 kernel on x86-64 hosts <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1612>
<ikey> p much
<popey> zyga-ubuntu: what irc client do you use?
<zyga-ubuntu> popey: irssi on ubuntu, hexchat on solus, polari on fedora and suse
 * ikey still holds a stupid preference to xchat over hexchat for old timey sake
<popey> file:///home/alan/Pictures/Screenshot%20from%202017-10-12%2016-59-24.png https://usercontent.irccloud-cdn.com/file/yPkV6ROY/Looks%20great%20in%20irccloud%20%3A)
<ikey> like i have some irrational grudge against hexchat
<zyga-ubuntu> I'd like to write an IRC client one day, would be a good way to learn about socket APIs (in C obviously)
<ogra_> zyga-ubuntu, pfft C ... kool kids write it in shell !
<ikey> zyga-ubuntu, sooo i did an evil with that once
<ogra_> shell with whiptail UI
<ikey> a malloc-free IRC client in C
<ikey> (CLI only)
<ikey> i say this one thing and you cry: variable length arrays
<zyga-ubuntu> ogra_: "would you like to send a message" dialog window in ncurses?
<ogra_> yeah !
<zyga-ubuntu> ikey: alloca?
<zyga-ubuntu> ikey: malloc free is a noble goal
<ikey> VLAs, like
<ikey> argument of size in function definition
<zyga-ubuntu> ikey: I really have a lot of respect for reliable software that can function as a finite state machine and have no memory allocation
<ikey> then: char blob[n]; from function parameter
<ikey> thats a special kind of evil lol
<zyga-ubuntu> ikey: right, all stack based, allowed by modern C (well, as of C99)
<ikey> sure
<ikey> but should be killed with fire :P
<ikey> (quite easy to kill them)
<popey> zyga-ubuntu: should I switch to core edge channel in anticipation of exciting fixes coming down the pipe soon? :)
<popey> </hopeful>
<zyga-solus> popey: yes, later today when mvo rebuilds new core
<popey> super
<zyga-solus> mvo: but I think you can keep beta
<zyga-solus> er
<zyga-solus> popey: ^
<popey> oh ok
<zyga-solus> because it will go there for cachio to test
 * kalikiana hopping on a train, will check back in a bit later
<kalikiana> elopio: perhaps also interesting for you, I may have found a way to make those x revisions match... will push later after I can test it properly
<kalikiana> it occurred to me the 'current' snap makes more sense than the exact filename
<mup> PR snapd#4034 opened: dbus: ensure io.snapcraft.Launcher.service is created on re-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/4034>
<mvo> popey: yeah, later today, some things have no landed yet, but some good fixes on the way
<mvo> zyga-ubuntu: I would like to merge 4026 even with the open questions, wdyt?
<mup> PR snapd#4031 closed: interfaces/network-control: remove incorrect rules for tun <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4031>
<mvo> Chipaca: you mentioned earlier you are ready for reviews - 4034 needs one
<zyga-solus> mvo: mmm
<zyga-solus> mvo: can you telegram gustavo? maybe pedronis is around and can give a quick yes/no
<zyga-solus> (please)
<ikey> soo uhm
<ikey> whats developer namespace?
<ikey> on snapcraft form
<zyga-solus> ikey: your developer nickname
<zyga-solus> ikey: when you snap install foo it is "foo from developer bar"
<zyga-solus> where bar is the namespace
<ikey> oh
<ikey> so ikey
<ikey> lol
<zyga-solus> and foo is the snap name
<zyga-solus> yep
<zyga-solus> :D
<ikey> cheers :D
<zyga-solus> but
<ikey> ya idk why this wants my address, not getting it :p
<zyga-solus> you can make it "solus" or something like that if youwant
<ikey> nah we'll have more solus devs over there in future
<zyga-solus> ok
<ikey> my ego isnt this large :P
<zyga-solus> eventually you should be able to have a solus account and many people publishing there
<zyga-solus> there are simple ways of doing that now
<ikey> probably put Solus in company name..?
<zyga-solus> ^_^ no idea
<ikey> should i call my snap "linux-steam-integration" or just "lsi" ?
<ikey> more thinking in case valve gets uppity
<zyga-solus> Lovely Startup Interface
<ikey> linux-steam-integration it is
<ikey> and im guessing Ubuntu (public)
<ikey> oh wow, the dashboard is so unity 8
<zyga-solus> oh?
<zyga-solus> in what way/
<zyga-solus> I haven't looked at it in a long time
<ikey> icons etc
<ikey> https://ibin.co/3dY4toqN8qV8.png
<ikey> lol
<zyga-solus> ah, indeed :)
<zyga-solus> is that dashboard.snapcraft.io?
<ikey> yeah
<zyga-solus> yeah :)
<zyga-solus> I think it needs some UX love
<zyga-solus> (probably already in some pipe)
<ikey> aye
<ikey> so normally i can just do snap register i guess?
<ikey> ah snapcraft register
<ikey> makes sense - context n all
<zyga-solus> yes
<zyga-solus> log in
<zyga-solus> then register
 * ikey thinks he might be at the point of no return now
<ikey> lol
<zyga-solus> terrible stuff sucks but great stuff sucks all the time :)
<ikey> hah nice
<ikey> oh one thing i didnt figure earlier zyga-solus
<ikey> can a base snap run? or must it be split as app + base
<Chipaca> mvo: +1 with two Qs
<zyga-solus> ikey: it depends on what you mean
<zyga-solus> ikey: I don't think we tried apps on base snaps yet
<ikey> ok so ill keep it simple and have a split runtime
<zyga-solus> ikey: but you can certainly ship executables inside
<ikey> basically ill make linux-steam-integration depend on solus-gaming-runtime or something
<zyga-solus> ikey: I think we'll find dragons, I'll gladly fix anything you run into
<ikey> thinking more from the delta perspective if i need hotfixes in LSI its likely better to split them
<zyga-solus> oh, indeed
<ikey> *registers new snap*
<ikey> lol
<zyga-solus> for base snaps you will run into "stale base snap bug" so you may need to unmount /run/snapd/ns/foo.mnt (where foo is the app snap) from time to time
<ikey> ah ok
<ikey> hm ill call it solus-runtime-gaming - we might end up expanding this stuff, who knows
<ikey> nice having a common basename
<mcphail> i'm loving the sound of this
<ikey> well from my perspective its about time solus shared its toys
<ikey> our pride and joy is our steam gaming lol
<zyga-suse> darn
<ikey> darn because you suddenly realised you're on suse?
<ikey> or..?
<zyga-suse> I suspended my laptop because I was looking for something on the other side of the lid and I just closed it (a little)
<ikey> ow
<zyga-suse> trying to resume it
<ikey> xD
<zyga-suse> hmm
<zyga-suse> so mouse works
<zyga-suse> but keyboard input does not
<zyga-suse> ....
<ikey> o_O
<zyga-suse> I can move to VT and log in there
<zyga-suse> but I cannot get any input in the desktop session
<zyga-suse> I see a lot of "gdk_device_update_tool: assertion `GDK_IS_DEVICE (device)` failed
 * ikey thinks hard reboot
<zyga-suse> I'll reboot, too tired to debug another thing today
<zyga-suse> I think I was fully up-to-date
<zyga-suse> I'll check in a sec
<zyga-solus> hmm
<zyga-solus> I thought hexchat remembers my config
<zyga-solus> odd
 * Chipaca EODs (mostly)
<zyga-solus> see you tomorrow john!
<zyga-solus> ikey: you know
<zyga-solus> one bit of complaint (or just observation perhaps)
<ikey> ?
<zyga-solus> playing with all the distros
<zyga-solus> and updating them on a regular basis
<zyga-solus> pacman has the most silly command to use
<ikey> -Syu
<ikey> lol
<zyga-solus> "pacman -Suy" (maybe --soy-milk)
<ikey> XD
<Pharaoh_Atem> pacman has the dumbest syntax in the world
<zyga-solus> solus has a nice UI tool
<ikey> we have derpy "eopkg" which is so easy to typo
<zyga-solus> but "eopkg it" is more like "freud id" in my head
<zyga-solus> why not "install"
<ikey> you can eopkg install
<zyga-solus> ah
<ikey> `it` is just a shorthand
<ikey> it supports both
<zyga-solus> man, I didn't notice :)
<ikey> :D
<ikey> `eopkg help` will sort you right out
<zyga-solus> yeah, I just typed that
<ikey> fwiw that command will change one day
<zyga-solus> and I'm fully up-to-date
<ikey> it was eopkg because evolve os
<zyga-solus> ah
<ikey> yeah sync window is tomorrow
<zyga-solus> I was wondering what "e" stands for
<zyga-solus> btw, I had a package to share
<zyga-solus> unfinished
<ikey> gnome 3.26, systemd 235, etc
<ikey> oh ok
<zyga-solus> but maybe you can do it
<mvo> Chipaca: \o/
<Pharaoh_Atem> zyga-solus: Evolve OS
<Pharaoh_Atem> eopkg was forked from PiSi from Pardus
<ikey> many moons ago
<ikey> fwiw we didnt originally fork it, we continued the development of it as pardus abandoned it
<ikey> but then pardus anka got pissy with us for calling it pisi still
<Pharaoh_Atem> Solus OS (deb) became Evolve OS (pisi), which became Solus again
<ikey> so we renamed it
<ikey> Ehm
<Pharaoh_Atem> did I miss a step?
<ikey> SolusOS 2 (pisi) became Evolve OS (pisi)
<zyga-solus> ikey: https://gist.github.com/zyga/754d14715963ecc8b72f6d39059ffa1b
<Pharaoh_Atem> ah
<Pharaoh_Atem> whoops
<ikey> yeah its complex :P
<zyga-solus> ikey: I wanted to build it but man, that indent program is old shit
<ikey> xD
<zyga-solus> ikey: I had to use the debian .orig tarball which is unofficial but has fixes
<ikey> oh sweet holy jesus
<zyga-solus> ikey: and even with..
<zyga-solus> yeah
<zyga-solus> and it doesn't build :-(
<ikey> -Wno-implicit-int
<zyga-solus> but I wanted to use it
<zyga-solus> ikey: it's all old crap
<Pharaoh_Atem> fuck eww
<zyga-solus> I wanted to share in case you can make it magically work
<zyga-solus> and get a first package into solus :)
 * ikey has a lookie
<zyga-solus> ikey: it fails on docs now
<zyga-solus> ikey: the --sections option grew into two and I got stuck trying to unf*** that and regen autotools
<ikey> lol
<zyga-solus> ikey: I think it's one of those old unloved packages and GNU folks still demand dead tree signature mailed to US somewhere
<zyga-solus> so debian forked it but nobody loves still
<zyga-solus> love is hard when it's GNU/Love
<ikey> all you need is gnu...
 * ikey cooks a patch
<zyga-solus> ikey: I'd love to see what happens next, where does this package go to end up on my laptop
<ikey> [Package] Creating /home/build/work/indent-dbginfo-2.2.11-1-1-x86_64.eopkg ...
<ikey> [Package] Creating /home/build/work/indent-2.2.11-1-1-x86_64.eopkg ...
<ikey> [Package] Building complete
<ikey> so basically i stole some fedora/arch packages from arch repo
<zyga-solus> you make it look too easy
<ikey> and added one new patch
<zyga-solus> I spent a few hours on this
<ikey> https://hastebin.com/raw/xokonixera
<zyga-solus> ^_^
<ikey> so yeah in terms of our pipeline
<ikey> it ends up in our phabricator git "at some point"
<ikey> we issue "make publish" which creates a git tag, and tells the build controller the tag and source name
<ikey> build server asks build controller for a job, told to check out indent @ certain tag
<ikey> (immutable git repos too)
<ikey> builder checkouts the tag, builds the guy local, lets the build controller know how it went
<ikey> uploads logs to log server via ssh pubkey, and uploads eopkg to ferryd on package server incoming directory on pubkey ssh
<ikey> the builds are done with solbuild which use light container chroots
<ikey> no networking allowed, etc
<ikey> ferryd sees some incoming files turn up (fsnotify), and scans the .tram file
<ikey> it describes the full payload and sha256sums
<ikey> (and the target, i.e. "unstable")
<ikey> then if its legit, and passes initial inspection, ferryd will create a job to include it into unstable
<ikey> which is about 8 seconds after hitting the incoming directory
<zyga-solus> and stable?
<ikey> it also spawns off background jobs to see if it can delta it
<zyga-solus> is that waiting for another stable release?
<ikey> stable is a weekly sync
<ikey> we stabilise the entire repo over the course of one week
<zyga-solus> ah, wow, speedy!
<ikey> and we sync it on a friday now
<ikey> so ill literally do: ferryctl pull unstable shannon
<ikey> ~10s later the repo is synced
<ikey> and the index is updated, letting the updates out
<ikey> in the background it'll be off checking the delta mappings and creating new deltas for this upgrade path
<ikey> later on i check ferryctl status to see if its complete, tell it to reindex, and bam, delta path is available too
<ikey> realistically unstable is the "real" distro, and shannon is a lagging snapshot release of unstable
<ikey> meaning we do a full solus release once a week
<ikey> just without ISOs
<ikey> for this week we've gone from systemd 218 to 235, gnome 3.24 to gnome 3.26, new gstreamer, etc. we're ballsy :P
<zyga-solus> how do you test it?
<ikey> initially we'll do local ISOs
<ikey> which is basically: cd Solus/solus-image-budgie; make
<ikey> then "make boot"
<ikey> once we're happy with our ISO and VM testing, we'll upgrade our own systems on the unstable repos and test the changes
<zyga-solus> make boot just boots it?
<ikey> yep
<zyga-solus> is that manual or automatic?
<ikey> it just calls out to qemnu
<zyga-solus> e.g. if gnome is f***d, how do you know?
<ikey> *qemu
<ikey> we test it
<ikey> like we manually check the ISO
<ikey> ive seen what a reliance on openQA does :)
<ikey> im also running the gnome 3.26 stack right now
<ikey> same as all contributors
<ikey> we dogfood
<ikey> we also check our logs (dmesg/journalctl) and we have some early warning systems for "you're in trouble)
<ikey> f.e. we use abireport on all of our repos
<zyga-solus> I'm interested because of our, *ahem*, issue this week
<zyga-solus> we need to re-visit our testing policy
<ikey> aah
<ikey> so every change in solus looks something like this:
<ikey> https://dev.solus-project.com/R2955:370f0e60dcbc5db67249eb42384dfafaeeac3748
<ikey> as you can imagine, it gives us a really clear heads up
<ikey> we only do the package.yml, but the abireport + pspec stuff is all automatic
<ikey> combine that with the sync approach + cadence, it actually solves an awful lot of problems before they can happen
<ikey> whereas distinct waterfall channels tend to make things too complicated :)
<mup> PR snapcraft#1613 opened: cross compilation: enable cross compilation of i386 kernel on x86-64 â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1613>
<mup> PR snapd#4035 opened: Fix econnreset test when the download needs a retry <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4035>
<mup> PR snapd#4032 closed: fix shell errors from shellcheck <Created by albertodonato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4032>
<kyrofa> Hey elopio, how hard would it be to run a suite of snapd tests on a trusty lxc?
<elopio> kyrofa: Easy. Just add an argument to the lxd launch script. And a new entry in travis.yml.
<elopio> How well snapcraft runs in trusty from source , no clue.
<kyrofa> Badly. Exactly why I want tests covering it once I fix it
<kyrofa> elopio, actually, what I really care about is ensuring that the snapcraft _snap_ runs there. Which is sort of a different problem entirely, huh
<kyrofa> elopio, do we have any tests that ensure the snap works?
<elopio> We have the spread tests. And once we finish the branch from sergiusens for pushing the snap for every PR, I want to switch all the integration tests to run from the snap.
<kyrofa> Are the spread tests run from travis?
<kyrofa> Or elsewhere?
<elopio> Yes, but on the daily travis cron
<kyrofa> elopio, do we need to actually publish the snap in order to test it? We could build it and cache it
<kyrofa> Then follow-on stages could use it
<kyrofa> But yeah okay, I'll add spread tasks for this since I believe they have trusty machines available
<elopio> According to the Travis docs, we should share it using an external service. aws or ftp. But, we can't use credentials on PRs.
<elopio> I think it's better to push to the store, and dog food our own process.
<elopio> +1 on the spread test.
<kyrofa> elopio, alright. Note that we might hit a few minutes of store caching
<mup> PR snapd#4033 closed: snap-confine: add support for handling /dev/nvidia-modeset <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4033>
<AlbertA> jdstrand: we have consolidated mir-libs into mir-kiosk... so the mir-kiosk snap is now the provider of mir-libs content i/f slot... can we ask to enable autoconnection of mir-libs plug (similar to what we had for mir-libs snap) for mir-kiosk?
<mvo> zyga-solus: the world is conspiring again - tests for 4034 take forever to even start
 * ikey is back to being the antichrist on reddit
<mvo> zyga-solus: once those are finisehd I'm keen to merge 4026 too even if we don't get a reply, I would love to push out 2.28.5 tonight but given the state of tests, maybe tomorrow
<jdstrand> AlbertA: it is good that you are asking this cause things have changed a bit in the process that I've been meaning to circle back to you on. Can you add a formal request using https://forum.snapcraft.io/t/process-for-reviewing-aliases-auto-connections-and-track-requests/455?
<AlbertA> jdstrand: sure thanks!
<kyrofa> elopio, the plugins integration tests are reliably running over in Travis. I'd like to split them. Any opinion on a logical split?
<jdstrand> AlbertA: I haven't looked at the snap, but just a heads up, as part of the conversation you may be asked to change the value of the 'content' attribute (again, maybe you won't need to. we can discuss on the list)
<elopio> kyrofa I don't want to split them, I would like to make the Ruby and cargo plugins faster. Give me a minute...
<mup> PR snapd#4026 closed: overlord/auth: continue for now supporting UBUNTU_STORE_ID if the model is generic-classic <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4026>
<kyrofa> elopio, alright, let me know. I'll move to testing ROS on artful. But those tests running over is starting to stand in the way of things landing
<elopio> https://gist.github.com/elopio/db8adee5a0ab4505835e0dc85ffcc105
<elopio> It seems to me that 3 minutes for a hello world snap is too much.
<kyrofa> elopio, I mean... you're building ruby from source
<elopio> And I proposed two PRs yesterday to remove 4 tests. That's 4-6 minutes less. A little time to get real fixes in place.
<AlbertA> jdstrand: ok, is this good? https://forum.snapcraft.io/t/mir-kiosk-mir-libs-auto-connection/2452
<elopio> kyrofa: yes, I'm thinking about a ruby snap. Does that make sense?
<kyrofa> elopio, well, the plugin explicitly supports multiple versions of ruby
<kyrofa> elopio, what are your plans there?
<kyrofa> elopio, that would also require the ruby to be staged
<kyrofa> elopio, so, stage-snaps
<elopio> Multiple snaps or tracks. And fall back to build from source
<elopio> Right, stage snaps. To me, that's the solution for our slow tests. Not more splits.
<kyrofa> elopio, that's an 18.04 task
<kyrofa> How long are we gonna wait? :P
<elopio> And the other thing is parallelization. Yesterday I finally got the nested containers working.
<elopio> But, we need to build the snap first, to test he same thing in the container.
<kyrofa> elopio, also, that raises a lot of questions. Who will maintain all these ruby snaps? Will we also need to start maintaining ros2 snaps?
<kyrofa> How about rust?
<elopio> 18.04 starts next week ð
<elopio> I think us and snapcrafters, if upstream doesn't accept them.
<elopio> And yes, ros snaps, snaps for everything that makes our hello worlds slow. Or well, that's my idea. If we don't go that path, the split.
<elopio> One suite for python, one for Ruby, one for cargo.
<jdstrand> AlbertA: yes, the request looks fine. thanks!
<kyrofa> So to be clear: in order to make tests pass that are failing today, you want to 1) develop stage-snaps, 2) develop ruby-snaps that are good enough to upstream, and 3) find a home for them?
<kyrofa> elopio, not everything will work well within a snap, too. Gems will be fun. ros2 will be more fun
<kyrofa> I'm not sure we should put all our eggs in that basket just yet
<elopio> First, remove duplication. That's ready today. Then parallelization, we only need to send the snap somewhere.
<elopio> Then, make the plugins faster.
<elopio> If all else fails, mark the tests as slow and live with them.
<zyga-solus> re
<zyga-solus> mvo: I agree about 2.28.5
<zyga-solus> mvo: let me look at PRs now
<mvo> zyga-solus: just one left, pedronis merged his
<zyga-solus> yep, I see
<zyga-solus> reading it now
<zyga-solus> added a comment
<zyga-solus> reading rest
<zyga-solus> mvo: +0.5, not sure about that condition I indicated
<zyga-solus> mvo: I'll check back
<kyrofa> elopio, figured out the ROS failure
<kyrofa> elopio, fix coming
<cachio> zyga-solus, there?
<kyrofa> elopio, due to new python3-apt
<cachio> zyga-solus, in pi 2 and 3 when I set and unset a var for the core like in the test snapctl-configure-core
<zyga-solus> yes
<cachio> in the config file it is being removed the new line at the end of the file
<cachio> it is making the test fail
<cachio> and I think it is kind of bug
<cachio> but the core works well
<cachio> zyga-solus, any idea why it could be happenning just for the pi's?
<elopio> tx kyrofa
<zyga-solus> I think there are pi specific implementations of coreconfig
<zyga-solus> maybe a bug there? is that a regression?
<zyga-solus> I'm honestly too tired to debug this tonight
<cachio> zyga-solus, yes, it is a regression but it comes from like a month
<zyga-solus> aha
<zyga-solus> mvo: ^ let's dalay for tomorrow
<zyga-solus> mvo: I'll prepare pi2 and pi3 and we can iterate
<zyga-solus> cachio: please drop a thread with description of the problem
<cachio> zyga-solus, sure
<zyga-solus> thank you, sorry, just too tired + back pain (kids decided to invade us last night and we slept like fish in a can)
<zyga-solus> I'm AFK now
<mvo> zyga-solus: hm, just a \n missing?
<cachio> mvo, yes
<cachio> mvo https://paste.ubuntu.com/25728285/
<cachio> that is the error
<mvo> zyga-solus: hm, hm, I'm too tired tonight, but we can look tomorrow early
<mvo> cachio: thanks
<cachio> mvo, sure, no hurry, I'll write a forum post
<mvo> ta
<mvo> I wait for tests for 4034 and then call it a day
<cachio> mvo, are you gonna include that in 28.5?
<mup> PR snapcraft#1614 opened: apt repo: allow insecure repos <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1614>
<kyrofa> elopio, that's for you ^^
<elopio> kyrofa: I'm on holidays today. I'll review it tomorrow.
<kyrofa> elopio, oh! I'm sorry, I didn't know, I wouldn't have been bothering you!
<elopio> Don't worry. I would have told you to stop bothering me if you were :)
<kyrofa> Good :)
<kyrofa> elopio, what are you up to, then? Just hangin out?
<mup> PR snapcraft#1615 opened: schema: improve invalid app, hook, and part errors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1615>
<mup> PR snapcraft#1616 opened: store: guide to account creation upon login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1616>
#snappy 2017-10-13
<zyga-ubuntu> o/
<mvo> hey zyga-ubuntu
<zyga-ubuntu> hey, sorry for being late, just waking up
<zyga-ubuntu> mvo: did you see my comment here? https://github.com/snapcore/snapd/pull/4034#discussion_r144391820
<mup> PR #4034: dbus: ensure io.snapcraft.Launcher.service is created on re-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4034>
<mup> PR snapd#4034 closed: dbus: ensure io.snapcraft.Launcher.service is created on re-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4034>
<mvo> zyga-ubuntu: I did not, sorry
<mvo> zyga-ubuntu: fixing that now in an extra branch :/
<zyga-ubuntu> mvo: no worries, thank you
<mup> PR snapd#4036 opened: interfaces/dbus: drop unneeded check for release.ReleaseInfo.ForceDevMode <Created by mvo5> <https://github.com/snapcore/snapd/pull/4036>
<mvo> zyga-ubuntu: -^
<zyga-ubuntu> ay
<zyga-ubuntu> thank you!
<mvo> zyga-ubuntu: 4035 needs a second review, that is also 2.28 material (mostly to make cachios life easier)
<zyga-ubuntu> k
<zyga-ubuntu> done
<mup> PR snapd#4035 closed: Fix econnreset test when the download needs a retry <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4035>
 * zyga-ubuntu needs a 2nd coffee
<zyga-ubuntu> sorry guys I just feels so sleepy today
<zyga-ubuntu> mvo: question about 2.28, I noticed that some PRs were going into master, are you tracking the cherry-pick list/
<zyga-ubuntu> hey john
<Chipaca> zyga-ubuntu: 'sup
<Chipaca> at this end, my 'just add conditions' branch is turning into a bit of a monster
<Chipaca> the kind of thing i then need to split into three
<Chipaca> i think i'll split it now, even if it's a bit of an ouroboros
<mvo> zyga-ubuntu: yes, release/2.28 should be up-to-date
<mvo> zyga-ubuntu: i.e. all the things got cherry-picked
<mvo> zyga-ubuntu: I'm trying to make sense of the pi3 issue that sergio reported right now but I don't have a pi3 so its a bit guesswork. could you run the specific test on a pi3?
<mvo> (you have one, right?)
<mvo> zyga-ubuntu: its external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade - ideally with debug to get an idea what is going on inside it
<zyga-solus> mvo: yes
<zyga-solus> mvo: setting this up now
<mup> PR snapd#4036 closed: interfaces/dbus: drop unneeded check for release.ReleaseInfo.ForceDevMode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4036>
<mvo> zyga-solus: thank you. one of the logs says "snap "core" has changes in progress
<mvo> zyga-solus: so it might be auto-refreshing to something while the test is running
<zyga-solus> mvo: sorry for the lag, the card didn't boot and I had to arrange keyboard/monitor; flashing edge image now
<zyga-solus> mvo: offtopic, if you are using the wayland version of gnome on your x250 I found the UI scaling option to be invaluable and working very well (on artfuL)
<mvo> zyga-solus: my x250 is still on zesty, I think I upgrade today
<mvo> zyga-solus: I updated the forum topic from sergio, its a very strange behaviour
<mvo> zyga-solus: it looks like the reboot does not go through uboot or at least not through the normal uboot snap_boot handler
<mvo> zyga-solus: i.e. snap_mode=try should never happen after a reboot because the bootloader checks/changes that
<mvo> zyga-solus: so I'm curious what you see if you watch the terminal
<mup> Bug #1718942 changed: running favorited snap shows two icons in Ubuntu dock <artful> <Snappy:Fix Released> <gnome-shell-extension-ubuntu-dock (Ubuntu):Fix Released> <https://launchpad.net/bugs/1718942>
<mvo> zyga-solus: eh, watch the attached monitor
<zyga-solus> mvo: I'll be ready to fire this in ~10 minutes
<zyga-solus> right
<zyga-solus> I can also plug in serial tty if you think that is useful
<mvo> zyga-solus: the more logging the better. its one of those "can't happen" scenarios
<zyga-solus> ok
<mvo> zyga-solus: I mean, the only explaination I have right now is craziness like kexec or similar
<mvo> i.e. bypass uboot entirely
<zyga-solus> ok, serial also attached
<zyga-solus> just waiting for the copy to finish
 * zyga-solus worries that the card may be busted or just super slow
<zyga-ubuntu> writes are ~1MB/s
<mvo> zyga-ubuntu: I can  recommend scandisk extreme, that is what I'm using and they are pretty swift. but I guess that is not helpful right now :)
 * zyga-ubuntu tweets something
<zyga-ubuntu> https://twitter.com/zygoon/status/918754849063358464
<zyga-ubuntu> mvo: just as a sanity check, I'll be testing this revision 4eafe60b201706ebd317891ab226832b45d23f12
<mvo> zyga-ubuntu: fwiw, I ordered a pi3 now too, shoudl have done that a long time agi
<zyga-ubuntu> mvo: copy complete, let's see if it boots
<mvo> zyga-ubuntu: autsch :( what happend?
<mvo> zyga-ubuntu: and thanks for the extra test for 4eafe60b201706ebd317891ab226832b45d23f12
<mvo> zyga-ubuntu: there is a spread test for it, but but but :)
<mvo> zyga-ubuntu: better safe than sorry
<zyga-ubuntu> mvo: nothing, they cards just stopped working one day
<zyga-ubuntu> oddly there's nothing on serial port
<mvo> zyga-ubuntu: on the montior?
<zyga-ubuntu> the monitor is showing normal boot stuff
<zyga-ubuntu> maybe I got the wires wrong?
<mvo> zyga-ubuntu: I vaguely remember the serial port was not enabled for some reason on the pi3 but I might be wrong. ogra_ will know
<zyga-ubuntu> I'll make sure after initial setup
<mvo> ta
<zyga-ubuntu> ok, board up and running, I'll check serial
<ogra_> mvo, zyga-ubuntu serial is enabled in non-stable
<zyga-ubuntu> ogra_: I'm on the edge image
<ogra_> it was nitialllly not enablled on the pi
<zyga-ubuntu> ogra_: how can I check it's enabled? I didn't see any gettys in the process list
<zyga-ubuntu> mvo: funny, I saw "snap repair run"
<zyga-ubuntu> root      1144  0.0  0.2   4340  2192 ttyS0    Ss+  08:37   0:00 /bin/bash /usr/share/subiquity/console-conf-wrapper --serial
<zyga-ubuntu> I see this, could that be it?
<ogra_> check /boot/uboot/cmdline.txt on a running system or cmdline.txt on the system-boot partition when checking the SD from a PC
<zyga-ubuntu> dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty0 elevator=deadline rng_core.default_quality=700
<ogra_> there you go
<ogra_> both are enabled
 * zyga-ubuntu swaps RX/TX
<zyga-ubuntu> yep
<ogra_> :)
<zyga-ubuntu> ok, ready for testing
<zyga-ubuntu> mvo: ok, shall I run one specific test or all of main?
<zyga-ubuntu> external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade  ?
<zyga-ubuntu> running that
<mvo> zyga-ubuntu: yes, that one
<zyga-ubuntu> I'll keep you posted
<zyga-ubuntu> I think this will take a while
<mvo> zyga-ubuntu: yes :/ its the last piece of the puzzle
<mvo> zyga-ubuntu: once that is under control we can do 2.28.5
<zyga-ubuntu> sorry for not having core prepared last night
<zyga-ubuntu> mvo: 1st restart
<zyga-ubuntu> I really wished I ran this with --verbose-but-without-protocol-dump
<zyga-ubuntu> mvo: 2nd reboot
<zyga-ubuntu> mvo: 3rd reboot
<zyga-ubuntu> mvo: 4th reboot
<zyga-ubuntu> (man, that's a lot)
<mvo> zyga-ubuntu: yes
 * zyga-ubuntu wasn't aware this test did so much rebooting
<zyga-ubuntu> restoring now
<zyga-ubuntu> mvo: what do we do if it passes/
 * zyga-ubuntu looks at his dead SD cards and wonders if there will be a uSD-sized HDD one day
<mvo> zyga-ubuntu: we ask cachio to use a second sd card and retry
<zyga-ubuntu> mvo: http://pastebin.ubuntu.com/25731170/
<zyga-ubuntu> mvo: you can retry the test from office.zygoon.pl
<zyga-ubuntu> mvo: I should just change the network config to static IP
<mvo> zyga-ubuntu: thats fine
<mvo> zyga-ubuntu: I assume the card from sergio is in a strange state. however I really want to get to the bottom of it, need to wait for him but I will prepare 2.28.5
<zyga-ubuntu> mvo: ok
<zyga-ubuntu> mvo: you should be able to ssh into office.zygoon.pl and ssh into pi3-1 now
<zyga-ubuntu> mvo: and run the test any number of times
<zyga-ubuntu> mvo: ttyUSB1 is now attached to the serial console
<mvo> zyga-ubuntu: I will run it again a couple of times but I suspect it will just work. but who knows
<zyga-ubuntu> mvo: I ran prepare-remote as my own user, not sure if you have to repeat
<mvo> ta
 * kalikiana coffee break
<zyga-ubuntu> I'll try to organize my attic over weeekend
<zyga-ubuntu> and move the lab devices there
<zyga-ubuntu> this should give me a more convenient x86 box available as lab controller
<ogra_> mvo, hmm, any idea why we did get these upload error mails for core ?
<ogra_> (the snaps seems to be where they should be)
<ogra_> " __all__: Can not create a new snap for core, the name is already taken and owned by someone else." is also a weird error i havent seen before
<mvo> ogra_: should be fixed by noe
<mvo> ogra_: by now
<mvo> ogra_: did you get "Store authorization failed for core" mails earlierÃ
<ogra_> yeah, i see they are where they should be, i was just wondering what it was
<mvo> ?
<ogra_> nope
<ogra_> only one per arch for the last build
<mvo> ogra_: it was using the wrong authorization for the automatic store uploads, it is now using the canonical store account again (as it should) so things are fine again. the token did expire (valid for 1y)
<ogra_> ah
<ogra_> thanks
<popey> mvo: zyga-ubuntu does core in edge (rev 3201) have the nvidia fixes?
<zyga-solus> popey: no idea
 * zyga-solus looks
<mvo> popey: yes
<popey> oooh
 * popey refreshes
<mvo> popey: it should have them, including the fixes for nvidia-375+
<mvo> popey: please let us know :)
<popey> Try and stop me :)
<zyga-ubuntu> mvo: question
<zyga-ubuntu>   edge:      16-2.28.4+git434.8c9d7e9 (3201) 87MB -
<zyga-ubuntu> what is the git revision?
<zyga-ubuntu> and what is the dot there?
<ogra_> the first one is just a counter
<ogra_> iirc
<mvo> zyga-ubuntu: the git revision is 8c9d7e9 but for lp:snapd-vendor
<zyga-ubuntu> ahhh
<zyga-ubuntu> thanks
<popey> not fixed
<zyga-ubuntu> what /o\
<popey> http://paste.ubuntu.com/25731340/
<zyga-ubuntu> hmmm
<zyga-ubuntu> mvo: we don't refresh udev profiles
 * zyga-ubuntu looks to confirm
<zyga-ubuntu>             shouldRefresh := (backend.Name() == interfaces.SecuritySecComp || backend.Name() == interfaces.SecurityAppArmor)
<zyga-ubuntu> yes /o\
<zyga-ubuntu> mvo: I'll make a branch
<zyga-ubuntu> darn
<mvo> zyga-ubuntu: yes, darn indeed
<zyga-ubuntu> should we just do all?
<zyga-ubuntu> or too risky?
<zyga-ubuntu> I wanted to do all since day one but we were conservative then
 * ogra_ wonders if there could be any bad impact on core 
<mvo> zyga-ubuntu: lets add udev for 2.28 and all for master ?
<ogra_> i.e. with custom gadgets where people have custom slots
<zyga-ubuntu> k
<mvo> zyga-ubuntu: will we udev reload a lot?
<mvo> i.e. will this be slow or cause storms of udev events?
<zyga-ubuntu> mvo: done https://github.com/snapcore/snapd/pull/4037
<mup> PR #4037: overlord/ifacestate: refresh udev backend on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/4037>
<zyga-ubuntu> mvo: it's only done if something is really different
<zyga-ubuntu> mvo: so should be ok-ish
<mvo> \o/
<zyga-ubuntu> mvo: though
<zyga-ubuntu> mvo: we re-run trigger anyway
<ogra_> mvo, i wouldnt be that much concerned about storms of events but about device name changes or some such ...
<zyga-ubuntu> mvo: as we don't know if the rules on disk were loaded
<zyga-ubuntu> mvo: let's try this and see what we get
<zyga-ubuntu> popey: thank you for catching this
<mup> PR snapd#4037 opened: overlord/ifacestate: refresh udev backend on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/4037>
<popey> zyga-ubuntu: no problemo
<popey> I am keen to play zzt ;)
<popey> Uh, I mean, open my irc client
<mvo> zyga-ubuntu: could we do something very targeted for 2.28?
<mvo> zyga-ubuntu: I targed it to master now, this way we can land in edge, trigger build and ask popey to refresh, then we cherry pick to 2.28. sounds good?
<zyga-ubuntu> mvo: done
<mvo> zyga-ubuntu: ta!
<zyga-ubuntu> mvo: I have two branches though
<mvo> thats fine
<zyga-ubuntu> mvo: one for 2.28 with just udev
<zyga-ubuntu> mvo: and one for master with all
<mup> PR snapd#4039 opened: overlord/ifacestate: refresh all security backends on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/4039>
<mvo> ok
<mvo> I'm setting up a 16.04/nvidia machine in the meantime
 * mvo feels uneasy not being able to reproduce
<mup> PR snapd#4040 opened: interfaces: add USB interface number attribute in udev rule for serial-port and hidraw interfaces <Created by musicguitar> <https://github.com/snapcore/snapd/pull/4040>
<zyga-ubuntu> mvo: install 16.04 and stable
<zyga-ubuntu> mvo: then refresh to beta
<zyga-ubuntu> mvo: no wait, install a snap before you do the beta refresh
<zyga-ubuntu> mvo: that should trigger this
<popey> my zyga desktop is still powered on and available if you need it
<zyga-ubuntu> popey: no, it's fine, I think this patch will change that correctly
<popey> kk
<zyga-ubuntu> mvo: meanwhile 3 runs on pi3-1 are green, still going
<mvo> great
<ackk> why can't I see prints() in snapcraft unittests?
<ackk> *print()s
<zyga-ubuntu> ackk: probably intercepted by the testing framework
<ackk> might be something in testscenarios I guess
<ackk> oh wait, FakeTerminal
 * zyga-solus -> lunch
<mup> PR snapcraft#1617 opened: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
<zyga-ubuntu> mvo: welcome back
<zyga-ubuntu> what did you change?
<mvo> zyga-ubuntu: switch to xorg from wayland
<kalikiana> ppisati: Hey! I just saw your snapcraft PR
<kalikiana> ppisati: Thanks for looking into it! Do you need any help with it? I'm thinking we could have a very simple unit test for it
<zyga-ubuntu> re
<zyga-ubuntu> ok, let's look at the tests
<ppisati> kalikiana: if you feel like writing a unit test for it, go ahead - i'm really bad with that stuff
<kalikiana> Yeah, I can do that.
<kalikiana> ppisati: Just to check first, should the return be ''? In the new PR there's no value
<mup> PR snapd#4039 closed: overlord/ifacestate: refresh all security backends on startup <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4039>
<mvo> zyga-ubuntu: I baby-sit a core build now, then we can test the fix
<ppisati> kalikiana: empty string or nothing have the same effect
<zyga-solus> mvo: ta
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4037 is green now
<mup> PR #4037: overlord/ifacestate: refresh udev backend on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/4037>
<kalikiana> ppisati: Hmmm this `'CROSS_COMPILE={}'.format(None)` gives me `'CROSS_COMPILE=None'`, though, which seems wrong?
<kalikiana> I guess it might be ignored by kbuild?
<zyga-solus> kalikiana: why wrong?
<zyga-solus> I mean, it's valid python :)
<zyga-solus> just looks wrong as a string
<kalikiana> zyga-solus: Well, by wrong I mean the result looks wrong
<kalikiana> Literally in terms of human eyes
<mvo> zyga-ubuntu: yeah, waiting for confirmation before the merge mainly
<kalikiana> zyga-solus: This gets passed to kbuild
 * kalikiana knows very little about what's normal in kbuild terms
<zyga-ubuntu> mvo: tests passed on pi3
<zyga-ubuntu> mvo: though the counter is off :)
<zyga-ubuntu> zyga@fyke:~/snapd$ SPREAD_EXTERNAL_ADDRESS=192.168.3.3:22 spread -v -debug -reuse -repeat 5  external:ubuntu-core-16-arm-32:tests/main/ubuntu-core-upgrade
<zyga-ubuntu> 2017-10-13 12:47:47 Successful tasks: 6
<zyga-ubuntu> wat?
<zyga-ubuntu> -repeat is -repeat-in-addition-to-the-one-you-selected
<mvo> zyga-ubuntu: heh, ok
<mvo> zyga-ubuntu: I get lunch while waiting for the builds I think
<kalikiana> ppisati: aside from that detail, are you going to add an error message for the non-x86 case? or do you want me to do that also?
<kalikiana> I think what you suggested in the bug sounds pretty good
<kalikiana> the use case of the op is exactly that
<ppisati> kalikiana: if arch != x86_64, it raises the exception there so you get a 'Cross compiling XXX on YYY is not supported' error
<kalikiana> ppisati: Yeah, was just wondering if it should be more specific in this case, like "Cross compiling for i686 is only supported from x86-64"
<kalikiana> Although maybe the existing one is good enough
<kalikiana> ppisati: Can you add me to your branch? Then I can push the tests
<mup> PR snapd#4041 opened: cmd,packaging: enable apparmor on openSUSE <Created by zyga> <https://github.com/snapcore/snapd/pull/4041>
<mup> PR snapd#4037 closed: overlord/ifacestate: refresh udev backend on startup <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4037>
<kalikiana> ppisati: Nevermind, seems I was able to push already. Again, thanks for working on this
<jdstrand> mvo: is a 2.28.5 expected in beta/candidate today?
<jdstrand> mvo: hi btw :)
<mvo> jdstrand: yes
<mvo> popey: could you try edge please with your example snap?
<mvo> jdstrand: we are just doing on confirmation about https://github.com/snapcore/snapd/pull/4039
<mup> PR #4039: overlord/ifacestate: refresh all security backends on startup <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4039>
<mvo> jdstrand: well, a variant for 2.28 that only refreshes udev in addition to seccomp and apparmor
<popey> mvo: will do
<mvo> jdstrand: this is needed to ensure the broken profiles get flushed
<mvo> popey: thank you!
 * popey notes a new install bar thing
<mvo> popey: yes, new feature, if you like it send \o/ to Chipaca
<kalikiana> sergiusens: not sure if you're on yet, but FYI I'll be on a train in ~30 and have a longer lunch, killing some overtime from the late nights this week, but will check in later/ be available for q's
<popey> I thought my terminal was broken initially
<popey> :)
<popey> still broken I'm afraid
<mvo> zyga-ubuntu: -^
<zyga-ubuntu> ack
<popey> http://paste.ubuntu.com/25731820/
<zyga-ubuntu> popey: can you look at /etc/rules.d/
<zyga-ubuntu> popey: look at the file for the snap
<zyga-ubuntu> popey: can you paste it?
<popey> i assume you mean /etc/udev/rules.d
<mvo> it is the right version, that git revision contains the fix
<popey> alan@hal:/etc/udev/rules.d$ pastebinit 70-snap.zzt.rules
<popey> http://paste.ubuntu.com/25731823/
<zyga-ubuntu> popey: yes, sorry
<zyga-ubuntu> popey: okay
<zyga-ubuntu> popey: please go to /run/udev/tags
<zyga-ubuntu> popey: then to app in question
<zyga-ubuntu> and list files there and paste here
<popey> http://paste.ubuntu.com/25731827/
<zyga-ubuntu> this looks like a bug in udev
<zyga-ubuntu> ok
<zyga-ubuntu> can you please
<mvo> jdstrand: are people asking on the sprint already?
<zyga-ubuntu> sudo udevadm control --reload
<zyga-ubuntu> sudo udevadm trigger
<zyga-ubuntu> oh man
<popey> done
<popey> (still busted)
<zyga-ubuntu> mvo: we do "sudo udevadm control --reload-rules"
<zyga-ubuntu> mvo: but help has only --reload
 * zyga-ubuntu checks
<zyga-ubuntu> popey: ok, thank you, no new theories yet
<popey> ok
<popey> lunch
<popey> biab
<zyga-ubuntu> popey: the files in /run... didn't change?
 * popey looks
<popey> same time/date on them
<zyga-ubuntu> k
<zyga-ubuntu> popey: if you remove the nvidia ones
<zyga-ubuntu> and then run the app?
<jdstrand> mvo: no, but last night I noticed in the forum someone with multiple network devices having trouble with network-control
<popey> so rm /run/udev/tags/snap_zzt_zzt/*nvidia*  ?
<zyga-ubuntu> yp
<zyga-ubuntu> yep
<mvo> jdstrand: ta
<jdstrand> mvo: mwinter and the frr snap
<popey> success
<zyga-ubuntu> mvo: ok, I just checked that "--reload" and "--reload-rules" are the same (it's an alias)
<zyga-ubuntu> popey: ok
<zyga-ubuntu> can you reboot
<zyga-ubuntu> I think it's a bug in udev
<popey> ugh
<zyga-ubuntu> mvo: we can do a cleanup thing that would go around all the udev snap tags and rm those files
<zyga-ubuntu> mvo: (via the udev backend)_
<popey> ok, will reboot
<zyga-ubuntu> mvo: +1/-1?
<kalikiana> elopio: We really need to split up the tests, two of my PRs now "failed" because of timeouts, and they were fine before... maybe we can discuss it a bit later if you have some time
<zyga-ubuntu> mvo: I think this could go to udev's Initialize (in master) and to udev init() in 2.28
<jdstrand> mvo: thanks for working on this
<Son_Goku> zyga-ubuntu: what happens if the snap-confine is linked to libapparmor and apparmor isn't available?
<zyga-ubuntu> Son_Goku: at runtime as in compiled but disabled on boot? nothing bad, it's been supported for months this way
<Son_Goku> well, that is, userspace support is there, but not kernel space
<zyga-ubuntu> jdstrand: not sure if you have the time for that but I did some updates on https://github.com/snapcore/snapd/pull/4008 -- I don't need a security review but another "still on the right/wrong" track review
<mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
<mvo> zyga-ubuntu: hm, but people will have to reboot anyway?
<zyga-ubuntu> Son_Goku: same
<zyga-ubuntu> mvo: no
<zyga-ubuntu> mvo: if we remove those files then it's ok
<Son_Goku> so then why didn't you do this with openSUSE before?
<zyga-ubuntu> mvo: (popey just tested that)
<zyga-ubuntu> Son_Goku: because before the backend was not enabled at all and snap-confine didn't run without any app profiles
<mvo> zyga-ubuntu: oh, he did? I thought he said it did not work, if it does, excellent, lets do it
<zyga-solus> mvo: please check backlog to ensure I'm not confusing things
<mvo> zyga-ubuntu: didn't he say "<zyga-ubuntu> I think it's a bug in udev"
<mvo> zyga-ubuntu: eh, I mean, didn't he say he will reboot?
<mvo> popey: hey, did removing the files help?
<zyga-solus> mvo: he didn't reboot yet (I assumed, as that was his IRC system)
<zyga-solus> mvo: better to ask though, sure :)
<mvo> zyga-solus: aha, I see "success"
<mvo> zyga-solus: I'm still slightly confused, lets see what he says :)
 * zyga-solus moved from kitchen back to office desk
<zyga-solus> yes
<mvo> zyga-solus: but yeah, lets add workaround/cleanup
<zyga-solus> I worry we don't have a full picture of udev behavior
<zyga-solus> mvo: ok, I'm on it
<mvo> ta
<zyga-ubuntu> mvo: question, shoud snap-confine do this (so that we know it runs before 1st snap runs)
<popey> zyga-ubuntu: after rebooting, apps work (however, that's what ogra did without any updates)
<zyga-ubuntu> mvo: or should snapd do this (but it may start after the snap)_
<zyga-ubuntu> popey: if you go to stable
<zyga-ubuntu> popey: they should stop to work again
<zyga-ubuntu> popey: then you can go to edge
<popey> ok, lets test
<zyga-ubuntu> popey: and they will stay broken
<zyga-ubuntu> popey: and removing those files from /run will fix it again (assuming you are on edge)
<zyga-ubuntu> popey: that's my theory
<popey> ok
<zyga-ubuntu> popey: udev doesn't remove tags for nvidia because of $unknown reason (and probably sysfs)
<popey> reverted to stable, and things are not as clear cut.
<zyga-ubuntu> meaning?
<popey> zzt and ohmygiraffe fail with the x issue
<popey> can't create a gl context
<popey> irccloud loads fine
<zyga-ubuntu> can you look at udev rules
<zyga-ubuntu> ah
<zyga-ubuntu> wait
<zyga-ubuntu> right
<zyga-ubuntu> popey: because stable doesn't reload udev rules :)
<zyga-ubuntu> popey: so you have to disable/enable
<popey> remove/install the snap good enough?
<zyga-ubuntu> yes thouh disable/enable is faster
<popey> nope
<popey> removed / installed zzt, still broken
<popey> (on stable core)
<zyga-ubuntu> good
<popey> ok
<zyga-ubuntu> now go to edge
<zyga-ubuntu> and it should stay broken
<popey> ok
<zyga-ubuntu> then remove the files and it should work
<zyga-ubuntu> and then reboot after saying on edge and it should work out of the box
<zyga-ubuntu> (that's my theory)
<zyga-ubuntu> sorry for tha hands-on exercise :/
<mvo> zyga-ubuntu: hm, hm, ideally snap-confine, I'm slightly worried that the code will be more complex there
<zyga-ubuntu> mvo: right
<zyga-ubuntu> mvo: maybe snapd is "good enough"
<zyga-ubuntu> Chipaca: ^ what do you think?
<popey> went to edge and zzt works now
<zyga-ubuntu> popey: !!
<zyga-ubuntu> popey: without removing?
<Chipaca> zyga-ubuntu: sorry, what's the context?
<mvo> popey: please try beta that should fix the gl context bug
<popey> ohmygiraffe works too
<zyga-ubuntu> Chipaca: we're trying to figure out where to put some clenaup code: in snap-confine/C or in snapd/go
<popey> yes, without removing
<Chipaca> zyga-ubuntu: what does the cleanup code do?
<Chipaca> zyga-ubuntu: and is it distro-specific, or will everybody need it?
<zyga-ubuntu> popey: then something doesn't hold, maybe that's just my confusion about stable not having refresh for udev
<zyga-ubuntu> Chipaca: rm /run/udev/tags/snap_*/*nvidia
<zyga-ubuntu> -f
<zyga-ubuntu> (literally that)
<zyga-ubuntu> I think it's a generic thing
<mvo> zyga-ubuntu: we could add a systemd unit?
<zyga-ubuntu> mvo: I'm puzzled,
<zyga-ubuntu> mvo: not in reexec easily
<Chipaca> zyga-ubuntu: who wrote those files?
<zyga-ubuntu> Chipaca: udev
<popey> mvo: on beta ohmygiraffe fails, segfault
<mvo> zyga-ubuntu: hm, good point
<zyga-ubuntu> Chipaca: it seems (though I may be wrong) that udev doens't remove them
<Chipaca> zyga-ubuntu: how much do we love udev? (no ignore this question)
<popey> same for zzt
<zyga-ubuntu> Chipaca: with a retractable baton
<zyga-ubuntu> no, I'm kidding
<zyga-ubuntu> udev is fine, it's just an edge case
<mvo> popey: what version of the nvidia driver do you have installed? apt list --installed nvidia-*
<zyga-ubuntu> popey: note that unless you use edge you will not see reliable behavior
<Chipaca> zyga-ubuntu: how do these things persist over reboot?
<zyga-ubuntu> popey: as non-edge doesn't reload udev
<Chipaca> zyga-ubuntu: or is it a "upgrade to new snapd, now wrong udev rules" thing?
<zyga-ubuntu> popey: and your piror revision of snapd is relevant to "works/doesnt"
<zyga-ubuntu> Chipaca: those don't persist, it's just a classic reexec fix
<zyga-ubuntu> Chipaca: it seems, though we need to test this, that udev doesn't remove those tags
<zyga-ubuntu> mvo: can you try testing this
<zyga-ubuntu> mvo: on your machine
<mvo> zyga-ubuntu: I need to do a bit of fiddling, but probably
<zyga-ubuntu> mvo: just look if /run/udev/tags/snap_*/*nvidia go away
<zyga-ubuntu> mvo: after going from stable to edge, with reexec without a reboot
<zyga-ubuntu> mvo: note that after going to stable from edge you will have fake state with udev from edge and rest from stable so it's not a reliable measurement
<zyga-ubuntu> s/fake/deceiving/
<zyga-ubuntu> mvo: and download caching branch, perfect for that :) thank you for making it
<zyga-ubuntu> mvo: I'll hold and do the fixup in go if we need to
<zyga-ubuntu> I need to break, my back is killing me :/
<mvo> zyga-ubuntu: ok, I can reproduce it with "hiri"
<mvo> zyga-ubuntu: I get "udev_enumerate_scan failed"
<mvo> zyga-ubuntu: I installed it before, then I refresh core to edge and the nvidia-files are still in run/udev/tags and hiri still fails to start
<mvo> zyga-ubuntu: if I move those files away hiri starts
<Chipaca> hmmm
<ogra_> did you add code to e-generate all rulles ?
<ogra_> *re-generate
<ogra_> if so, just rm them ?
<ogra_> (before re-generation)
<Chipaca> if the problem goes away with a reboot, and only happens on nvidia, would it be fair to publish an errata and fix it for 2.29?
<mvo> zyga-ubuntu: if I move the files back, things fail again
<Chipaca> or are there headless, unattended devices out there that use nvidia?
<popey> zyga-ubuntu: mvo you don't need me for a bit do you?
<mvo> popey: I can reproduce it now too, thank you. we may ask you in ~1-2h to double check our fix
<popey> kk
<mvo> Chipaca, zyga-ubuntu just double checked (it was kind of expected) - a reboot makes the problem go away. but I'm not happy telling our users that bth
<Chipaca> mvo: is this breakage only in .4?
<Chipaca> or is it in .1 also?
<Son_Goku> mvo: that snapfuse thing looks gross
<Son_Goku> is it really true that `apt upgrade` won't upgrade components that pull in new dependencies?
<Son_Goku> that seems like broken behavior
<popey> you want apt dist-upgrade
<pstolowski> zyga-solus, Chipaca, mvo i'm not coming to the standup today, i've a guy coming to mount blinders etc in my apartment
<popey> its not broken, it's documented, desired
<Chipaca> popey: not sure how desired, given 'apt update' does the dist upgrade :-)
<Chipaca> upgrade*
<mvo> Son_Goku: firefighting right now, but happy to tell the full (sad) backstory, in a nutshell popey is right, its the behaviour of apt-get upgrade nice 1997 (roughtly) and some people use it, probably more out of ignorance than anything else
<Chipaca> pstolowski: you're so lazy man
<popey> eh?
<Chipaca> popey: apt upgrade == apt-get dist-upgrade
<popey> update doesn't dist-upgrade
<mvo> Chipaca: almost
<Chipaca> mvo: la la la la
<Chipaca> :-)
<mvo> Chipaca, popey apt upgrade will add new package but never remove packages
<popey> Chipaca: Ah okay, you said "apt update" does dist-upgrade
 * mvo fixed that back in the day
<Chipaca> popey: yes, because my brain is a not particularly firm blancmange
<popey> :D
<zyga-ubuntu> mvo: re,
<Son_Goku> now I'm glad that apt never won out in the rpm distros
<Son_Goku> that's really stupid behavior
<zyga-ubuntu> mvo: ok
<popey> It was often desired on systems where you were happy to upgrade existing software you've audited, but didn't want new stuff sneaking in
<zyga-ubuntu> mvo: so now that you can reproduce
<popey> *shrug*
<zyga-ubuntu> mvo: can you please confirm that after going to a build with udev reload patch we still keep the nvidia tag files in /run/udev/tags?
<zyga-ubuntu> mvo: (i.e. it's a bug in udev)
<Chipaca> popey: AIUI it's merely flipping a default config, where apt-get uses one default and apt uses another, but i might've misunderstood
<Son_Goku> that's an incredibly stupid default
<mvo> zyga-ubuntu: I did that, I refreshed to edge and the files are still there
<popey> It's not a default
<popey> you typed the wrong command :)
<mvo> zyga-ubuntu: fwiw, I am testing a small cleanup
<popey> holding it wrong etc
<Son_Goku> :/
 * Chipaca wonders if Son_Goku accidentally ate trollflakes instead of cornflaes for breakfast
<zyga-ubuntu> mvo: thank you
<mvo> Son_Goku: its a feature with its time and its place, however the sad thing is that it got cargo culted mostly because "apt-get dist-upgrade" sounds scary (and would remove stuff) and people use apt-get upgrade for the wrong reasons. fortunately apt upgrade fixes it
<Son_Goku> yeah, I've seen people say "never use dist-upgrade" at work
<Son_Goku> afaik, all dist-upgrade does is process Breaks/Replaces (aka, do proper upgrade)
<Son_Goku> mvo: I just used smart most of the time before the new apt command became available ;)
<popey> no
<popey> People are silly :)
<Chipaca> *shocked*
 * Son_Goku gasps
<Chipaca> mvo: i'll be in the standup in a minute (getting tea)
<zyga-ubuntu> Chipaca: https://www.youtube.com/watch?v=0du72G8CeOY
<ogra_> popey, but *you* know the weirdest people
<popey> hello ogra_
 * ogra_ grins
<Chipaca> popey: just to double-check, your nick rhymes with "ropey", not with "popeye", right?
<popey> yes
<Chipaca> phew
<diddledan> popey, the dopey
<diddledan> popey: you're dopey, right? :-p
<popey> people call me poppy or popeye too
<popey> i used to get a surprising number of hits to my blog for people searching for "popey and olive oil"
<diddledan> haha
<diddledan> you ought to make a page for that
<diddledan> give them something to actually read
 * ikey wonders how many hits come from "in London a knight a popey interred"
<ikey> *london lies
 * ikey wakes up
<diddledan> wakey wakey ikey
<ikey> ty lol
<diddledan> popey needs to invent a boxing match special move, similar to the rope-a-dope
<ogra_> after alll we're the only disto who has A Pope ;)
 * diddledan pontificates
<ikey> lol
<diddledan> I still say we should get popey canonised
<ogra_> to shoot him at what exactly though ?
<ikey> ogra_, the hopes and dreams of the innocent
<ogra_> heh
<diddledan> nono, turn him into a saint
<ikey> now when you say saint
<ogra_> before or after we shot him ?
<diddledan> lol
<ikey> you dont mean like howard saint right?
<diddledan> well usually they need to be dead
<diddledan> popey: we're killing you off
<ikey> thats quite the job requirements
<ogra_> https://www.mysteryscenemag.com/images/film_tv/the_saint_w_halo.jpg
<diddledan> haha, great series
<ikey> "Required: 10 years experience with being generally nice, 8 years experience with being generally not alive"
<diddledan> they did a straight-to-netflix movie with some random fella and eliza dushku (of Buffy the Vampire and Dollhouse)
<ikey> ooo its friday the 13th
<diddledan> :-o
 * ikey avoids hockey all day
<ogra_> it so is
 * diddledan goes back to bed
<ikey> if i meet anyone called jason im noping myself back all the way home
<ikey> or even more terrifying than that
<ikey> if i bump into lindsay lohan
 * ikey shudders
<ogra_> http://dlisted.com/wp-content/uploads/2014/05/lilomolly2014.jpg
<Son_Goku> the work buildsystem is down today :(
<Son_Goku> this... is... not good
<ikey> the picture or the build system?
<ikey> i mean both are pretty out there
<ogra_> so it is a vacation buildsystem then
<ikey> lol
<Son_Goku> ikey: both
<Son_Goku> :D
<mup> PR snapd#4042 opened: snap-confine: cleanup incorrectly created nvidia udev tags <Created by mvo5> <https://github.com/snapcore/snapd/pull/4042>
<mup> PR snapd#4041 closed: cmd,packaging: enable apparmor on openSUSE <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4041>
<zyga-ubuntu> jdstrand: hey, can you please review https://github.com/snapcore/snapd/pull/4042
<mup> PR #4042: snap-confine: cleanup incorrectly created nvidia udev tags <Created by mvo5> <https://github.com/snapcore/snapd/pull/4042>
<zyga-ubuntu> jdstrand: it's urgent for us to get this before EOD
<cachio> mvo, zyga-ubuntu running the test with logging enabled
<cachio> I had to restart the screen to enable it
<Son_Goku> zyga-ubuntu: can you give positive karma to the snapd updates in Fedora, since popey can't?
<mvo> cachio: thank you
<cachio> mvo, https://paste.ubuntu.com/25732470/
<mvo> cachio: oh my
<cachio> mvo, does it help?
<mvo> cachio: that explains why we don't have updated defaults
<mvo> cachio: can you mail me your uboot.env file from the card? the one that it cannot read?
<mvo> cachio: oh, nevermind - uEnv.txt? we don't use this since ages. sorry. ogra_ is the error/warning from https://paste.ubuntu.com/25732470/ expected on the pi3?
<ogra_> yeah, thats normal
<mvo> cachio: -^
<ogra_> it normally just skips
<ogra_> (we should remove the old code that looks for it and prints the message but it isnt any blocker in any way)
<cachio> mvo, I sent you the screen log
<mvo> cachio: hmmmm, "^MFAT: Misaligned buffer address (3ab0b570)
<mvo> "
<mvo> ogra_: -^ have you seen this before?
<carroarmato0> Hello, I'm trying to build a snap package containing a Go application. I managed to snap it correctly, however I encountered the following issue security tag snap.12to8.12to8 not allowed   due to the fact that the app's name starts with a number.... any way to fix this without having to rename the upstream project ?
<mvo> cachio, ogra_ the relevant part is http://paste.ubuntu.com/25732499/ I think - we try to store snap_mode=trying but that fails with the given error and so the system boots in try mode and it goes into the installed core. so mystery solved, now we need to understand why the buffer is misaligned and what that means. the error comes from uboot
<ogra_> mvo, no, thats also normal
<mvo> ogra_: it is?
<ogra_> yes
<zyga-solus> Son_Goku: no, because we're going to do .5
<zyga-solus> :/
<zyga-solus> Son_Goku: we found a number of issues
<Son_Goku> god damn it
<zyga-solus> Son_Goku: I was meaning to tell you but I forgot, sorry
<Chipaca> carroarmato0: that looks like a bug to me
<zyga-solus> Son_Goku: that's all the week really :/
<ogra_> mvo, and you will find that nothing gets corrupted, thats about the ram buffer only
<ogra_> cachio, mvo, rather check the content by stopping the boot and lloking at the printenv output
<ogra_> *looking
<mvo> ogra_: well, what cachio is seeing is a device that boots in snap_mode=try and never gets to "snap_mode=trying" (or snap_mode="")
<zyga-solus> mvo: hmm
<mvo> ogra_: and *if* the error is not a red-herring that would fit the picture
<ogra_> right, but none of the messages are anything out of the ordinary
<zyga-solus> mvo: I saw some misaligned fat errors in dos tools
<zyga-solus> mvo: it was fixed >> xenial AFAIK
 * zyga-solus looks
<Chipaca> carroarmato0: is your snap public?
<ogra_> cachio, mvo, there are corruption issues where uboot doesnt init the SD coreectly and prints timeout messages *before* even loading uboot.env
<ogra_> that happens with some new sandisk cards
<carroarmato0> Chipaca:  no, but there is an old existing issue for it on launchpad
<ogra_> (which are also not working i.e. in my desktop SD reader)
<cachio> ogra_, it was working until the last build
<ogra_> (i.e. a general issue with these cards and linux)
<carroarmato0> Chipaca:  kinda figured maybe someone knows a workaround for it or has been fixed in the meantime :)
<carroarmato0> Chipaca:  hang on, I'll look it up
<zyga-solus> mvo: this error comes from the following patch https://lists.denx.de/pipermail/u-boot/2015-September/228813.html
<cachio> I tried with 2 cards and I see the same error
<carroarmato0> Chipaca:  https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1636016
<mup> Bug #1636016: snapcraft should warn of invalid name <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1636016>
<zyga-solus> ogra_: ah, you're talking about that bug where some optimization would clobber the cards and there's a growing blacklist
<ogra_> cachio, well, do you see any timeout messages something like "sdhc ... something, something ... increating timeout by ... millisecs"
<zyga-solus> ogra_: right/
<ogra_> zyga-solus, mainly the sandisk extreme cards
<ogra_> the very latest batch seems to have some issues
<Chipaca> carroarmato0: I can confirm it's a bug, yes
<Chipaca> carroarmato0: and i've got a minimal reproducer
<ogra_> i can get them to mount on my laptop but my PC doesnt see them at all ... both on xenial both using the same USB reader
<zyga-solus> is that the card that cachio is using?
<ogra_> i think he used an ultra crad
<ogra_> *card
<ogra_> (if thats the same he showed me in YNC)
<zyga-solus> ogra_: very appropriate tweet from this morning https://twitter.com/zygoon/status/918754849063358464
<ogra_> *NYC
<Chipaca> carroarmato0: it's a bug in snapd, not snapcraft, though
<ogra_> heh
<Chipaca> carroarmato0: or â¦ hm
<zyga-solus> Chipaca: let's roll the fix into 2.28
<Chipaca> carroarmato0: reading #1589613 it might not be
<mup> Bug #1589613: Snap app names are too permissive <verification-done> <Canonical Click Reviewers tools:Invalid> <Snapcraft:Fix Released by kyrofa> <snapcraft (Ubuntu):Fix Released> <snapd (Ubuntu):Fix Released by kyrofa> <snapcraft (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Xenial):Fix Released>
<mup> <snapcraft (Ubuntu Yakkety):Fix Released> <snapd (Ubuntu Yakkety):Fix Released by kyrofa> <https://launchpad.net/bugs/1589613>
<mvo> ogra_: any ideas what might cause a pi3 from staying at "snap_mode=try" would be appreciated. if you could guide him to any further debug ddata, that would be great. I don't really see (except for a write failure) how the uboot does not go from "snap_mode=try" to "snap_mode=trying"
<Chipaca> so
<Chipaca> snap and app names
 * mvo takes a short break
<carroarmato0> Chipaca:   I search for other snap packages which might start with a number in their name. Stumbled upon the 0ad game. https://uappexplorer.com/snap/ubuntu/play0ad   I'm not sure if they worked around the problem by naming it  play0ad rather than 0ad... or they just chose to name it like that right off the bat
<Chipaca> we explicitly allow them to start with a number
<ogra_> mvo, as i said ... the printout from "printenv" when intercepting the boot
<ogra_> cachio, ^^^
<carroarmato0> Chipaca:   snapcraft has no issue at all generating snaps beginning with a number
<Chipaca> but then snap-confine aborts
<mvo> ogra_: will that happen before or after "snappy_boot" ran? because snappy_boot is when uboot toggles from snap_mode=try to trying and saves the env
<Chipaca> zyga-solus: so, why does snap-confine reject valid app names?
<carroarmato0> Chipaca:  but the issue occurs after you installed the snap and try executing the command
<carroarmato0> Chipaca:  I can provide you the  snapcraft.yaml if you want
<ogra_> mvo, i think the countdown runs before anything gets changed ... :/
<Chipaca> carroarmato0: no, thank you, i have a minimal reproducer as i said
<zyga-solus> Chipaca: let me look
<zyga-solus> Chipaca: probably because we don't reuse the regexp
<Chipaca> zyga-solus: that's the how, not the why :-)
<zyga-solus> looking
<Chipaca> zyga-solus: there's even a comment in snap.ValidateName which says "keep in sync wiht these two others"
<Chipaca> zyga-solus: we obviously haven't :-)
<zyga-solus> I know, I wrote the comment
<Chipaca> zyga-solus: the regexp in snapd is basically [a-z0-9]* except it must have at least one [a-z]
<zyga-solus> what's the snap name?
<carroarmato0> Chipaca: zyga-solus:  it's  12to8
<zyga-solus> 12to8, gotcha
<Chipaca> carroarmato0: anything starting with a number
<carroarmato0> Chipaca: zyga-solus:  indeed
<zyga-solus> testing
<Chipaca> zyga-solus: http://pastebin.ubuntu.com/25732561/
<cachio> ogra_, I don't see that
<cachio> ogra_, I use an extreme sdcard
<zyga-solus> hmm
<zyga-solus> +       // Regression test: 12to8
<zyga-solus> +       sc_snap_name_validate("12to8", &err);
<zyga-solus> +       g_assert_null(err);
<zyga-solus> Chipaca: this passes
<zyga-solus> maybe we ... have another routine?
<Chipaca> zyga-solus: it's the app name that's the problem, not the snap name
<zyga-solus> maybe not snap name but security token
<zyga-solus> what's the error message?
<Chipaca> security tag snap.123test.123test not allowed
<zyga-solus> right
<zyga-solus> we use
<zyga-solus> +       // Regression test: 12to8
<zyga-solus> +       sc_snap_name_validate("12to8", &err);
<zyga-solus> +       g_assert_null(err);
<zyga-solus> or I cannot copy and paste
<Chipaca> :-)
<mvo> cachio: so the log is nice, it shows are doing a single reboot only, so somehow the snap_mode is not changed *or* it is not written to disk, one of those
 * Chipaca hugs zyga-solus 
<zyga-solus> wow, copy is greyed out
<zyga-solus> WTF
<zyga-solus>             "^snap\\.([a-z](-?[a-z0-9])*)\\.([a-zA-Z0-9](-?[a-zA-Z0-9])*|hook\\.[a-z](-?[a-z])*)$";
<zyga-solus> must be vim with some fancy pants terminal mouse support in solus
<zyga-solus> so that's the regexp
<Chipaca> zyga-solus: yeah, that's notably different
 * zyga-solus compares to snap.go
<zyga-solus> I see
<zyga-solus> Chipaca: changing
<Chipaca> zyga-solus: ^[a-zA-Z0-9](?:-?[a-zA-Z0-9])*$
<carroarmato0> Chipaca:  zyga-solus:  0:)  http://www.osnews.com/images/comics/wtfm.jpg
<Chipaca> zyga-solus: also the hook one will fail
<Chipaca> carroarmato0: i think zyga-solus's wtf was about copy being greyed out, but it doesn't mean you're not right
<cachio> mvo, ogra_ this is the printenv https://paste.ubuntu.com/25732587/
<zyga-solus> Chipaca: I think we have one more copy
<cachio> do you see anything weird on there?
<Chipaca> carroarmato0: also I don't know if 0:) is a smiling angel or a shouting person with a unibrow
<Chipaca> zyga-solus: we do
<Chipaca> probably
<cachio> mvo, ogra_ this is stopping the boot
<zyga-solus> Chipaca: I think in snap-update-ns
<Chipaca> we always do things in threes
<zyga-solus> in the C code there
<carroarmato0> Chipaca:  smiling angel it is
<ogra_> cachio, thats fine, gimme a sec
<ogra_> cachio, try: run snappy_boot
<ogra_> that should move on
<zyga-solus> Chipaca: what is (?:...)
<ogra_> see if that changes anything, prints errrors etc
<kyrofa> Chipaca, carroarmato0 disallowing numbers at the beginning is on purpose, I remember the discussion
<zyga-solus> kyrofa: we changed that when 2048 came out
<zyga-solus> or something like that
<carroarmato0> zyga-solus:  hahahaha
<carroarmato0> zyga-solus:  priorities :D
<zyga-solus> kyrofa: it's just internal misalignment in snapd
<cachio> ogra_, in progress
 * ogra_ is in a meetzing now
<zyga-solus> woah
<zyga-solus> Chipaca: why do we allow UPPER CASE snap names?
<zyga-solus> Chipaca: in snap-confine
<zyga-solus> man this is hairy
<kyrofa> zyga-solus, so... snapcraft and the store need to be updated now? Do we have a cross-project bug or anything?
<ogra_> for developers with tourette ?
<Chipaca> zyga-solus: not snap names, but yes snap apps
<zyga-solus> kyrofa: not sure, I think it's only snap-confine accepting the same set as snapd (for now)
<zyga-solus> Chipaca: aah
<zyga-solus> that makes sense
<Chipaca> kyrofa: do they though?
<Chipaca> carroarmato0: did you publish your snap?
<carroarmato0> Chipaca:   no I haven't. Have been playing around with it to learn how snaps work
<Chipaca> kyrofa: i ask because carroarmato0 here built a snap with an app both of which started with a number, so at least snapcraft seems to be a'ight
<kyrofa> Chipaca, ah, no indeed
<kyrofa> Chipaca, I was mistaken. We must have made that change along with you
<Chipaca> kyrofa: it's as if we sometimes talked to each other
<carroarmato0> Chipaca:  the application is opensource, so if you want I could look into publishing it
<Chipaca> kyrofa: sounds horrible
<kyrofa> Chipaca, blech, you think I'd remember
<Chipaca> carroarmato0: there's no rush
<Chipaca> kyrofa: it probably involved beer
<kyrofa> Probably
<carroarmato0> Chipaca:  but not sure if I'll keep it updated though
<zyga-solus> libsnap-confine-private/classic-test.c:55:13: warning: âtest_is_on_classic_with_long_lineâ defined but not used [-Wunused-function]
<Chipaca> carroarmato0: probably best to not do it until you're sure, then
 * zyga-solus prepares more fixes
<carroarmato0> Chipaca: indeed, don't want to deploy abandonware :)
<Chipaca> carroarmato0: you could install xbill-xaw and use it to reflect about what you nearly did
 * zyga-solus looks at other parts of the code
<zyga-solus> carroarmato0: the good news is that this will land today and will be in the release
<carroarmato0> zyga-solus:  oh cool.
<carroarmato0> zyga-solus:  as soon as it lands will keep the ticket on launchpad updated
<zyga-solus> Chipaca: can you review please
<mup> PR snapd#4043 opened: cmd/snap-confine: update valid security tag regexp <Created by zyga> <https://github.com/snapcore/snapd/pull/4043>
<zyga-solus> I'll do one more PR
<cachio> ogra_, it did not started any more
<cachio> https://paste.ubuntu.com/25732634/
<carroarmato0> zyga-solus: Chipaca:  I will be going now.  Thanks for the assistance. Will keep an eye out for the update and update the issue in launchpad. :) cheers
<cachio> ogra_, it hangs
<zyga-solus>  o/
<cachio> mvo, ogra_ I'll be off 30 minutes
<ogra_> cachio, hmm, are you sure it hangs and didnt just switch to tty console ?
<Chipaca> zyga-solus: won't that fail if a snap called 123 has the temerity of shipping a hook?
<zyga-solus> ikey: hey, where is the indent git tree for me to clone/build
<Chipaca> 123test*
<zyga-solus> Chipaca: looking
<cachio> ogra_, I can't connect through ssh anymore
<ogra_> cachio, and no screen attched ?
<ogra_> (could be that the direct running of snappy_boot simplly omits the serial tty option from the cmdline)
<ikey> zyga-solus, oh didnt know you wanted me to push it
<ikey> gizza sec
<cachio> ogra_, just 1 screen and it is attached
<zyga-solus> ikey: yeah, it could save me a hop to an ubuntu machine :)
<ogra_> cachio, nothing on that ?
<ikey> ya giz 2 secs
<cachio> ogra_, the output of that screen is what I pasted
<Chipaca> oSoMoN: did you call play0ad play0ad because 0ad didn't work, or because of some other reason?
<ogra_> cachio, i meant a HDMI screen ... not the screen app :)
<ikey> zyga-solus, https://dev.solus-project.com/source/indent.git
<zyga-solus> Chipaca: +       g_assert_true(verify_security_tag("snap.123test.hook.configure", "123test"));
<ikey> and i stuffed the build in unstable repo for you
<zyga-solus>  
<zyga-solus> this passes
<zyga-solus> ikey: thank you!
<zyga-solus> Chipaca: did I understand your question correctly? this is correct, right?
<oSoMoN> Chipaca, "0ad" is not allowed because it starts with a digitâ¦ there's a bug filed for that, let me try and find it
<zyga-solus> oSoMoN: it should be allowed (by snapd) nowadays
<Chipaca> zyga-solus: did you change the regexp, or did I misread it the first time?
<zyga-solus> Chipaca: I didn't change it
<zyga-solus> Chipaca: I force-pushed to fix one tests that now passes
<Chipaca> zyga-solus: I shall put on the dunce hat and sit in the corner and thing about cookies
<cachio> ogra_, seending a pic by email
<ogra_> ok
<cachio> I'll need to go now
<Chipaca> zyga-solus: +1
<zyga-solus> Chipaca: I'll make fmt (after installing indent) and push
<cachio> ogra_, which is your email?
<ogra_> cachio, oga@ubuntu.com (or @canonical.com as you like)
<oSoMoN> Chipaca, IÂ can't find that bug again, I'd swear IÂ had filed one
<cachio> oga or ogra?
<oSoMoN> zyga-solus, oh that's good news, I'll try again when IÂ get some spare time
<ogra_> cachio, damn ... my R key is shaky ... ogra indeed
<cachio> ogra_, sent
<zyga-solus> ikey|afk: woot, I also learned about using different profiles :)
<ikey|afk> :D
<ikey|afk> -p main-x86_64 ^^
<ikey|afk> ok bbiab
<mup> PR snapd#4044 opened: cmd/libsnap: enable two stranded tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4044>
<zyga-solus> right :)
<zyga-solus> mvo: https://github.com/snapcore/snapd/milestone/13 we have three branches now
<zyga-solus> jdstrand: kind ping about https://github.com/snapcore/snapd/pull/4042
<mup> PR #4042: snap-confine: cleanup incorrectly created nvidia udev tags <Created by mvo5> <https://github.com/snapcore/snapd/pull/4042>
<zyga-solus> ogra_: hey
<zyga-solus> ogra_: so, I'm lost with this FAT/pi3 issue
<zyga-solus> ogra_: can you please explain it to me how you understand it?
<ogra_> zyga-solus, i dont yet ...
<ogra_> zyga-solus, point is that none of the messages mentioned yet were anything unusual
<zyga-solus> did cachio upload his image anywhere?
<zyga-solus> (of his card)
<ogra_> he mailed it to me ... and it shows that i was wrong assuming "run snappy_boot" would be enough ...
<zyga-solus> no, I mean his whole SD card image
<ogra_> it is useless (misses bits from the cmdline)
<ogra_> nope
<ogra_> only a pic from the screen
<ogra_> zyga-solus, i doubt that would help you though
<ogra_> ah
<ogra_> [    0.000000] Kernel command line: 8250.nr_uarts=1 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa22082 bcm2709.serial=0x1dffa1eb smsc95xx.macaddr=B8:27:EB:FF:A1:EB bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty0 elevator=deadline root=/dev/disk/by-label/writable net.ifnames=0
<ogra_> init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=core_x1.snap snap_kernel=pi2-kernel_43.snap
<ogra_> so manually rrunning snappy_boot switched to the core_x1 properly ... at least we know that bit
<ogra_> hmm
<ogra_> and the cmdline actually looks correct ...
<ogra_> so why does he end up in an initrd prompt then ...
<ogra_> https://imgur.com/a/YA3p9 is the image he mailed ... and that looks actually morre like a generral SD breakage
<ogra_> sadly the actual error would be several lines above ... what you see thee is onlly fallout
<ogra_> hmm
<ogra_> unless core_x1.snap is actually corrupt ...
<ogra_> mvo, do we know how exactly core_x1.snap was assembled ? i'm wondering if the bootloader doesnt actually DTRT here and simply switch back as it should
<ogra_> that photo seems to agree that there is something wrong with the rootfs assembling
<ogra_> anyway ... i need to go afk too for at least 2h
<zyga-solus> ogra_: yeah, it looks like the SD card reads lorem ipsum on all blocks
<zyga-solus> ogra_: I think it's a test-made core
<zyga-solus> ogra_: looking at the test ...
<ogra_> zyga-solus, well, i wouldnt go that far ... but probably on the core squashfs
<zyga-solus> http://pastebin.ubuntu.com/25732826/
<zyga-solus> this is the test that was executed
 * zyga-solus reads
<zyga-solus> actually
<zyga-solus> since this runs on ubuntu-core-16 target, I suspect it may contain a core that was built from the git tree
<zyga-solus> (with some hackery obviously)
<zyga-solus> but not sure, I've never used external targets
 * zyga-solus looks
<zyga-solus>     0) cmd="snap install --dangerous /var/lib/snapd/snaps/core_$(cat prevBoot).snap" ;;
<zyga-solus> it looks like just previous core snap is sideloaded
<ogra_> i wonder why he doesnt just use --revision and the store
<ogra_> (saves you from using --dangerous ... )
<zyga-solus> probably simplicity
<ogra_> anyway, really out now (need to mow the lawn before it gets to dark)
<zyga-solus> ok
<zyga-solus> lol
<zyga-solus> it's dark already here :)
<ogra_> the simplicity of building a complete core vs using one from the store ?
 * zyga-solus imagines ogra with a flashlight and a mower 
<zyga-solus> ogra_: it's not building one, it's just installing one on disk
<zyga-solus> simplicity of passing --dangerous :)
<ogra_> haha, not that dark yet ... i want to manager to finish at least half the garden before 19:00
<ogra_> ah
<zyga-solus> go
<zyga-solus> :)
<cachio> zyga-solus, the upload failed
<cachio> grrrrr
<cachio> zyga-solus, I'll build it on jenkins
<cachio> zyga-solus, so you can download from there
<mvo> zyga-solus: hey, thanks, looking at the PRs now
<zyga-suse> mvo: thank you
<mvo> cachio_: hey, anything new, new theories? I was also wondering if the same problem is reproducable in the edge core
<cachio_> mvo, no, did you see the image that I sent?
<zyga-suse> mvo: no new theories
<mvo> cachio_: no, could you paste me the link again please?
<mvo> zyga-suse: did you manage to reproduce it as well?
<cachio_> mvo, which link?
<mvo> cachio_: the image
<mvo> cachio_: aha, i have it now
<zyga-solus> mvo: no, no luck, cachio_ didn't upload the image he was using, I suspect it may be his card more than the image though
<ogra_> mvo, https://imgur.com/a/YA3p9
<mvo> cachio_: autsch - when/how did that happen? i.e. after what action?
<ogra_> mvo, i dont think it is the bootloader at all but the self assembled core_x1.snap
<ogra_> mvo, after i asked him to stop the boot and "run snappy_boot" manually
<ogra_> mvo, the dmesg output shows the cmdline is fine so i suspect there is something with the core snap itself
<ogra_> mvo, which woulld mean the bootloader does exactly the right thing and rolls back
<zyga-solus_> re, sorry
<mvo> ogra_: that is just the core from /var/lib/snapd/snapd/core_$(currentBoot), so its essentially the snap downloaded from the store
<mvo> cachio_: do you have the busybox prompt in front of you?
<mvo> cachio_: if so, does ls /var/lib/snapd/snaps show a core_x1.snap ?
<ogra_> mvo, why is it called core_x1.snap then ?
<ogra_> oh
<ogra_> because it was sideloaded before
<ogra_> indeed
<ogra_> silly me
<cachio_> mvo, let me connect a keyboard
<mvo> cachio_: thanks
<cachio_> doesn't work the keyboard with the pi3 at this momento
<cachio_> mvo, I tried with 2 and not working
<ogra_> likely no usbhid module in the initrd ... :/
<ogra_> you coudl try to boot again with console=tty1 dropped from the cmdline.txt
<ogra_> that should give you the initrd shell on serial
<cachio_> ogra_, tty1 or tty0?
<ogra_> well, the "not serial" one :)
<cachio_> ogra_, I have this time dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
<ogra_> remove "console=tty0"
<ogra_> then all output should only go to serial
<ogra_> (including the initrd shell)
<cachio_> ok
<ogra_> the first console= arg on a kernel cmdline always means ""here prints the kernel to" the seond means "print all userspace output to this" (i.e. after starting initrd) ... if you have only one console= it will be used for all output
<ogra_> (and input indeed)
<cachio_> excelent
<cachio_> ogra
<cachio_> (initramfs) ls /var/lib
<cachio_> ls: /var/lib: No such file or directory
<ogra_> ls /root/var/lib
<ogra_> the writable partition should be mounted under /root
<cachio_> ok
<mvo> ogra_, cachio_ - so there is a new kernel in edge,beta,candidate for pi2, uploaded 2days, 7h ago
<mvo> cachio_, ogra_ I wonder if using the stable kernel/gadget makes a difference?
<mvo> cachio_ ogra_ or if the previous version of the kernel (r42) would help.
<cachio_> mvo, we can try
<mvo> cachio_: does this match the time when the problems started? 2d ago?
<cachio_> mvo, yes
<ogra_> ogra@pi3:~$ snap list pi2-kernel
<ogra_> Name        Version        Rev  Developer  Notes
<ogra_> pi2-kernel  4.4.0.1075.75  43   canonical  kernel
<ogra_> mvo, that kernel silently upgraded on my pi3 here
<ogra_> (and works fine)
<ogra_> mvo, you cant boot the stable kernel ... it will fail
<mvo> ogra_: right, I'm sure its fine most of the time, but I'm a bit desperate right now
<mvo> ogra_ cachio_ so no stable kernel, I can make r42 available again I think
<ogra_> (well, it might boot but many bits will be missing or not work)
<ogra_> yeah, use edge
<ogra_> so cachio_ can refresh to edge
<mvo> ogra_: the thing is, this test started to fail ~2d ago and all changes in snapd/core we did are unrelated to booting
<ogra_> yeah
<mvo> ppisati: I switched the pi2-kernel r42 to edge for a short time
<mvo> cachio_: snap refresh --edge pi2-kernel
<mvo> cachio_: should give you r42 now
<mvo> cachio_: this version is ~3 weeks old
 * ogra_ goes to pack up the lawnmower and stuff 
<ogra_> brb
<cachio_> mvo,  I need 10 minutes
<cachio_> I am flashing again
<mvo> cachio_: sure, thanks a lot for your diligence in this issue. I'm excited about this potential clue, this is the best theory in the last few hours
<jdstrand> mvo, zyga-solus: re 4042, done
 * jdstrand steps away
<kyrofa> Any snapcraft peeps around today?
<kyrofa> GH is super quiet
<ogra_> kyrofa, talk to that kyrofa guy, i think he works on snapcraft at times ;)
<cachio_> mvo, refreshing ...
<jdstrand> mvo, zyga-solus: after thinking about it, please answer https://github.com/snapcore/snapd/pull/4042#issuecomment-336506560
<mup> PR #4042: snap-confine: cleanup incorrectly created nvidia udev tags <Created by mvo5> <https://github.com/snapcore/snapd/pull/4042>
<kyrofa> ogra_, I HAVE been! And I'm STILL lonely
 * ogra_ hugs kyrofa 
<kyrofa> Haha
<zyga-solus> re
<zyga-solus> jdstrand: looking
<zyga-solus> jdstrand: thank you for your review
<zyga-solus> mvo: I'm baby-sitting family computers (sigh), I'll look at the patch and spread test in ~30
<zyga-solus> mvo: shall we call it a (release) day and regroup early tomorrow to build a core snap and push it for testing
<zyga-solus> mvo: please reply to jdstrand's question as well, I'm checking the tree
<cachio_> mvo, running test
<cachio_> using kernel 42
<mvo> zyga-solus: maybe, I can push the release to beta, thats fine. what patch/spread are you refering to? for 4042?
<mvo> cachio_: ohhhh, I'm curious how it goes
<zyga-solus> mvo: patch requested by jdstrand and spread test to ensure this works
<zyga-solus> mvo: please see his feedback
<mvo> zyga-solus: excellent, thank you
<kalikiana> kyrofa: would you feel like having a look at this PR? https://github.com/snapcore/snapcraft/pull/1613 not mine for a change, tho I added the unit test for it
<mup> PR snapcraft#1613: cross compilation: enable cross compilation of i386 kernel on x86-64 â¦ <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1613>
<cachio_> mvo, same issue
<kyrofa> kalikiana, sure. I've got some up for review as well
<zyga-solus> mvo: but disclaimer, still hacking on family crap PCs
<kalikiana> kyrofa: I'm just looking at the queue now, so will get right to it
<mvo> cachio_: /o\
<ogra_> cachio_, grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null
<ogra_> can you paste the output ?
<ogra_> (on the pi)
<kalikiana> kyrofa: quick q on https://github.com/snapcore/snapcraft/pull/1614 - do you have any reference/ bug for the change? I think it makes complete sense, just wondering if there's some background to follow up on later
<mup> PR snapcraft#1614: apt repo: allow insecure repos <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1614>
<kyrofa> kalikiana, no, it's the ROS error we're getting in the autopkgtests for anything beyond xenial
<zyga-solus> ogra_: good idea
<zyga-solus> ogra_: we can see the manufacturer ID
<mvo> zyga-solus: I will deal with the feedback from jamie, no worries, fix the PC :)
<ogra_> zyga-solus, and the vendor ... and compare it to http://paste.ubuntu.com/25566047/ and http://pastebin.ubuntu.com/25566134/ which are two cards i know are failing regulary
<cachio_> ogra_, https://paste.ubuntu.com/25733320/
<zyga-solus> mvo: I'd rather not but "bla bla bla, internet is broken (shouting)"
<zyga-solus> ogra_: yeah, good idea
<ogra_> yeah, but no match
<ogra_> its a sandisk ... but not a mmodel i know as failing
<kalikiana> kyrofa: Ah. Alright. Maybe file a bug for it as a reminder.. approved in any case
<kyrofa> kalikiana, we need a discussion around it, I need to write a forum post
<kyrofa> At least... I think that's what I'm supposed to do these days :P
<mvo> zyga-solus: do you remember what PR introduced adding the nvidia udev tags?
<zyga-solus> mvo: I think the one from garry, let me find it
<kalikiana> kyrofa: True, bugs don't work as well for proper discussions - which reminds me, wasn't there something else you were going to post in the forum? I'm trying to recall, it was something I was going to chime in on...
<mvo> zyga-solus: I want to improve my comment to make sure i refer to the right PR
<kyrofa> kalikiana, yeah, our ideal for slow tests
<mvo> zyga-solus: I think I can use 4022 as the reference, nevermind
<ogra_> cachio_, any chance you can try with another SD to make sure its not that ?
<kalikiana> kyrofa: Yup, that's it. Feel free to poke me once you post it, in case I don't see it right away
<zyga-solus> mvo: one sec
<cachio_> ogra_, I tried with 2
<cachio_> ogra_, I can try another one
<ogra_> both sandisk ?
<zyga-solus> mvo: https://github.com/snapcore/snapd/pull/3617/files
<mup> PR #3617: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3617>
<zyga-solus> this one
<cachio_> ogra_, yes
<ogra_> do you have a non-sandisk ?
<cachio_> ogra_, yes
<cachio_> a toshiba one
<ogra_> can you try with that one ?
<cachio_> yes
<ogra_> just to make sure ...
<cachio_> ogra_, running
 * Chipaca quietly walks out the back and pops a beer open
<mvo> cachio_: how is it looking so far? with the different card?
<zyga-solus_> mvo: I see the patch now
<Son_Goku> openSUSE infrastructure is now down
<zyga-solus_> mvo: woah, nice spread test
<zyga-solus_> mvo: ^^
<zyga-solus_> mvo: you will have failing opensuse tests
<Son_Goku> mvo: all openSUSE tests need to be disabled for the next two days
<zyga-solus_> two days? are they re-painting the data center?
<Son_Goku> they're doing maintenance on the power systems
<mvo> Son_Goku: woah, thank you
<mvo> zyga-solus_: thanks
<Son_Goku> it broke us here at work too ;)
<mvo> zyga-solus_: we can simply disable suse then (set to manual)
<zyga-solus_> mvo: yes
<zyga-solus_> mvo: let's do it in this PR
<zyga-solus_> mvo: so that we can land one PR instead of two
<cachio_> mvo, ogra_ with the toshiba card same error
<zyga-solus_> Son_Goku: thank you for the tip
<zyga-solus_> cachio_: stamp and send the card to mvo for debugging
<mvo> zyga-solus_: looks like opensuse is already on manual
<zyga-solus_> cachio_: (physical card)
<ogra_> cachio_, thanks, then it is definitely not a card issue
<zyga-solus_> mvo: ooops, I didn't know that
<zyga-solus_> (not great but I'll deal with that)
<Son_Goku> mvo: note that the openSUSE repositories will be up
 * zyga-solus_ writes this down
<Son_Goku> but osc build will not work
<zyga-solus_> mvo: what is this for?
<zyga-solus_> +    mv $SNAP_MOUNT_DIR/core/current.renamed $SNAP_MOUNT_DIR/core/current
<zyga-solus_> it seems unrelated
<mvo> zyga-solus_: the previous test is causing havoc
<zyga-solus_> aah
<zyga-solus_> thanks
<mvo> zyga-solus_: its breaking things on purpose
<zyga-solus_> right
<zyga-solus_> and not doing restore, gotcha
<zyga-solus_> cachio_: I'm 90% serious about that SD card
<cachio_> zyga-solus_, I live in cordoba, it could take 1 week :)
<zyga-solus_> cachio_: that's fine
<zyga-solus_> cachio_: I think it's something we should understand for 2.29.x
<ogra_> cachio_, send a pidgeon ;)
<ogra_> cachio_, so you see this prob since 2.28.4 landed ? could you do the same test with a candidate image (which still has 2.28.1 ) ?
<mvo> cachio_: or use the same image and "snap refresh --candidate core"
<mvo> cachio_: and then do the test?
<cachio_> mvo, refreshing
<mvo> ta
<Son_Goku> zyga-solus_: for building the packages for openSUSE, are we using `osc build`?
<mup> PR snapd#4044 closed: cmd/libsnap: enable two stranded tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4044>
<mvo> zyga-solus_: 4044 does not cherry-pick without conflicts, I will skip that one (as its tests only)
<mup> PR snapd#4043 closed: cmd/snap-confine: update valid security tag regexp <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4043>
 * mvo waits for tests for 4042
<kalikiana> elopio: I think you might want to re-trigger these tests? I see some network outage there causing "failures"
<kalikiana> https://github.com/snapcore/snapcraft/pull/1602
<mup> PR snapcraft#1602: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602>
 * elopio checks
<elopio> kalikiana: we need Kyle's branch first to get everything to green.
<kalikiana> kyrofa: I see some conflicts here https://github.com/snapcore/snapcraft/pull/1602
<mup> PR snapcraft#1602: tests: add the slow tag for ros snapd integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1602>
<kalikiana> elopio: Hm? I thought it's the other way around?
<kalikiana> Maybe I'm getting "hen and egg" confusion here
<kyrofa> elopio, +1 it then, let's get it in there
<kalikiana> The failures at least look like false negatives to me
<kyrofa> elopio, well, perhaps we should run an autopkgtest on it?
<kyrofa> kalikiana, not the zesty one
<elopio> well, yes, we need everything to be green :D
<kyrofa> kalikiana, it dies with a NO_PUBKEY
<elopio> 1603 and 1614 are chicken and egg.
<kalikiana> Oha. Indeed.
<kalikiana> kyrofa: Right, *that* PR. Now I see where I was confused :-D
 * kalikiana morns launchpad prerequisite branches for a moment
<kyrofa> kalikiana, yeah I feel ya
<kyrofa> elopio, not chicken and egg, 1614 is required for 1603. It's more like chicken and human
<kyrofa> Human requires the chicken in order to eat it
<kalikiana> lol
<kalikiana> kyrofa: Now I see your old avatar as I'm reading this, where you look very ominous and slightly philosophical
<kyrofa> My old avatar? I looked like a child in my old one, not philosophical
<elopio> well everything is approved. We just need Sergio to push the merge button.
<kyrofa> elopio, I finally have that power again, do we need to wait?
<cachio_> mvo, https://paste.ubuntu.com/25733615/
<cachio_> I'll need to reflash againg
<elopio> kyrofa: no need to wait. Maybe just run autopkgtest in your 1614 to check that the error is indeed gone.
<kyrofa> elopio, zesty good enough? Or artful as well?
<mvo> cachio_: oh, so the same error ?
<jdstrand> mvo: hey, are you using the system-image seed to build the core snap or something else?
<mvo> cachio_: snap change 6 ? does that show the same
<cachio_> mvo, I could not go to 2.28.1
<mvo> jdstrand: we are using live-build, why?
<mvo> cachio_: aha, so what is this pastebin about, what version was used in the test?
<kyrofa> snappy-m-o, autopkgtest something something
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmpc66uz1ql/retry_autopkgtest.sh', 'something', 'something']' returned non-zero exit status 1
<kyrofa> Oh good, I was close
<jdstrand> mvo: and does live-build use seeds?
<mvo> jdstrand: I think so, why?
<jdstrand> mvo: we have a sizing request and want to be looking at the right thing to understand what is exactly being pulled in and how
<elopio> kyrofa: just one, anyone.
<kyrofa> snappy-m-o, autopkgtest 1614 zesty:amd64
<snappy-m-o> kyrofa: I've just triggered your test.
<mvo> jdstrand: aha, I think we have some room here, plus base snaps will make this a lot easier in the near future
<cachio_> mvo, I was in 28.4 after run the test
<mvo> jdstrand: /usr/share/snappy/dpkg.list
<mvo> cachio_: ok
<cachio_> mvo, I tried to refresh to candidate but it failed
<mvo> cachio_: oh, that failed too
<jdstrand> mvo: yep, aware of that file. ok thanks
<cachio_> I am refreshing again from a new one
<mvo> cachio_: so it seems refreshes are broken for all cores
<mvo> cachio_: what kind of error do you get? i.e. snap change 8
<cachio_> mvo, 1 minute, I am checking in my other pu3
<cachio_> I need a bigger usb hub
<zyga-solus_> re
<zyga-solus_> mvo: ack about skipping that PR
<zyga-solus_> how are things?
<Pharaoh_Atem> mvo: the dates are wrong in the fedora changelog
<Pharaoh_Atem> you put Tue Oct 11, but Oct 11 was a Wednesday
<cachio_> mvo, same error with 28.1
<cachio_> mvo, I am gonna run with another pi3
<cachio_> to see if the problem is in the board
<mup> PR snapcraft#1618 opened: states: add scriptlets to build state <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1618>
<mvo> cachio_: thanks a lot
<mvo> zyga-solus_: thinks are so so
<mvo> zyga-solus_: if we are happy about 4042 I will merge it into 2.28
<cachio_> mvo, I don't know what else to try
<cachio_> mvo, I'll try to save in disk the images that I use for beta validation
<cachio_> so if we need to reproduce something we have the images used for the tests
<mvo> cachio_: yeah, I ordered a pi3, should be here early next week and I can try to make sense of this. testing in a second pi3 is certainly an idea
<cachio_> mvo, I already tested in 2 pi3
<mvo> cachio_: oh and always the same
<cachio_> mvo, yes
<cachio_> this is the output of the change
<cachio_> https://paste.ubuntu.com/25734001/
<cachio_> from beta to candidate after the test fail
<mvo> cachio_: same error
<cachio_> mvo, ye
<cachio_> s
<mup> PR snapd#4042 closed: snap-confine: cleanup incorrectly created nvidia udev tags <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4042>
<zyga-solus_> re
<mvo> zyga-solus_: any last concerns about 4042 or release/2.28? if not I will push to beta
<mvo> zyga-solus_: cachio_ had the refresh error now with 2.28.1 too, all a bit of a myserty, maybe you can try to reproduce with your pi3 using the same steps on monday. I will do so as well once my pi3 is here
 * mvo spread tests 4042
<zyga-solus_> mvo: let's see
<zyga-solus_> nick zyga-solus
<zyga-solus> mvo: no, that's fine
<zyga-solus> I read your improved patch and I was very happy about the test
<zyga-solus> mvo: let's see if this is releasable
<zyga-solus> man you should skip monday with a day like this
<mvo> zyga-solus: lets get it to beta and annouce in the forum, then we can keep debugging the pi3 issue, I would like to understand that before we go to stable anyway
<zyga-solus> mvo: agreed
<zyga-solus> mvo: thank you for staying so late tonight
<zyga-solus> mvo: you made all of this possible!
<kyrofa> elopio, other, unrelated errors in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-snapcraft-daily/zesty/amd64/s/snapcraft/20171013_184638_e91b2@/log.gz
<kyrofa> Are those real errors, or should we re-run?
<cachio_> mvo, also pawel has a pi3
<cachio_> he has 2 in fact
<mup> PR snapd#4045 opened: snap-confine: cleanup broken nvidia (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4045>
<mvo> zyga-solus: -^ because the cherry-pick does not apply cleanly
<ryebot> is it possible to `snap download` for a different arch, somehow? Alternatively, what url is the snap client hitting to perform the download? Does it need auth?
<zyga-ubuntu> mvo: ack
<zyga-ubuntu> the spread test conflicted?
<zyga-ubuntu> mvo: reviwed
<mvo> zyga-ubuntu: yeah, its a new test, I forgot about that
<zyga-ubuntu> mvo: hmm
<zyga-ubuntu> core                     16-2.28.4+git434.8c9d7e9  3201  canonical     core,disabled
<zyga-ubuntu> how did this happen?
<zyga-ubuntu> aha
<zyga-ubuntu> I think my fault http://pastebin.ubuntu.com/25734299/
<zyga-ubuntu> hmm
<zyga-ubuntu> then again, not sure
<elopio> kyrofa: :( I had not seen those container builds errors before...
<mvo> zyga-ubuntu: hm, is it hanging there?
<mvo> zyga-ubuntu: it might be the new security re-generation?
<zyga-ubuntu> mvo: root     21944  0.0  0.0   8864  1092 ?        D    12:31   0:00 /snap/core/current/usr/lib/snapd/snap-confine snap.core.hook.configure /usr/lib/snapd/snap-ex
<zyga-ubuntu> no, it's in D state
<zyga-ubuntu> unkillable
<zyga-ubuntu> I tried to gdb attach to it, gdb is also borked
<zyga-ubuntu> nothing in syslog
<zyga-ubuntu> I'll reboot :/
<gouchi> Hi
<gouchi> we want to be able to browse / and even if we have home, removable-media and udisks2 interfaces it seems we can't browse it
<gouchi> https://github.com/libretro/retroarch-snap/blob/master/snapcraft.yaml#L12
<gouchi> is there other interface we need to enable ?
<kalikiana> elopio: would you mind giving https://github.com/snapcore/snapcraft/pull/1587#issuecomment-336521348 another look? I got a +1 from Kyle
<mup> PR snapcraft#1587: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
<elopio> Sure
<zyga-ubuntu> mvo: I had to hard-reboot, that process prevented systemd to reboot
<zyga-ubuntu> mvo: ok, I'm tracking stable now
<zyga-ubuntu> I'll refresh as soon as you push the new update
<gouchi> we will check log first
<kalikiana> elopio: Thanks!
 * kalikiana wrapping up the late night shift now - so much for my plan of killing overtime :-D
<mup> PR snapd#4045 closed: snap-confine: cleanup broken nvidia (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4045>
<mup> PR snapd#4046 opened: release: snapd 2.28.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4046>
 * zyga-solus noticed that "snap refresh" perpetually refreshes atom
<zyga-solus> which is following stable
<zyga-solus> and always at revision 36
<zyga-solus> but still refreshes each time anyway
<zyga-solus> but that's for tomorrow
<zyga-solus> o/
#snappy 2017-10-14
<aladdin> hi
<aladdin> I am  trying snap package on 17.04 and it seems I can't launch libudev apparmor denied
<aladdin> it was not the case on 16.04
<aladdin> how can I make it work ?
<aladdin> any tips ?
<aladdin> [  209.830706] audit: type=1400 audit(1508009153.258:10): apparmor="DENIED" operation="open" profile="/snap/core/3017/usr/lib/snapd/snap-confine" name="/rofs/lib/x86_64-linux-gnu/libudev.so.1.6.5" pid=5571 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
#snappy 2017-10-15
<mup> PR snapd#4046 closed: release: snapd 2.28.5 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4046>
#snappy 2018-10-08
<Son_Goku> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1614162
<Son_Goku> zyga: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d3e4a6577d
<mborzecki> morning
<zyga> hey mborzecki
<zyga> Pharaoh_Atem: thank you for the note, hopefully someone will merge the fix
<zyga> oh
<mborzecki> zyga: hey
<zyga> it's been proposed to bodhi :)
 * zyga needs to wake up properly
<zyga> I will test it with the build process and report !
<mborzecki> zyga: have you gotten around indcluding more flags in -ldflags=-extldflags=-static on opensuse?
<zyga> mborzecki: no, I haven't touched opensuse in a while
<zyga> (i.e. still broken as before)
<zyga> on old release
<mborzecki> damn, i'm trying to find a way through the shell quoting mess
<zyga> yeah :/
<zyga> on the up side
<zyga> indigo is in devel:languages:go now
<zyga> maybe some part of the mess can be handled elsewhere
<mborzecki> i think it only works in rpm spec because the spec is processed outside of shell :/
<zyga> I'm not fully here yet, need to get dressed and take Bit for a wlak
<zyga> *walk
<mup> PR core-build#34 opened: travis.yml: fix xenial base tarball URL <Created by mvo5> <https://github.com/snapcore/core-build/pull/34>
<zyga> and back now
<zyga> hey moo :)
<mvo> hey zyga
<zyga> man, I need to teach the spell checker that mvo and moo are *not* the same :D
<zyga> how are you doing guys?
<mvo> zyga: doing well, how are you?
<zyga> good, just finishing coffee :)
<mborzecki> -ldflags=-extldflags=-foo is an abomination
<mborzecki> -ldflags "-extldflags '-foo'" behaves differently
<pstolowski> morning
<mborzecki> and bash if very funny splitting -ldflags=-extldflags='-foo -static' into -ldflags=-extldflags=\'foo -static, so you get 2 options and -static is passed to go build pfff
<mborzecki> ended up doing the 'array' expansion trick
<mup> PR core-build#33 closed: fix typo for handle_writable_paths() <Created by madper> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/33>
<mup> PR core-build#34 closed: travis.yml: fix xenial base tarball URL <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/34>
<mup> PR snapd#5942 closed: client: speedup unit tests <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5942>
<mup> PR snapd#5941 closed: systemd, wrappers: speed up wrappers unit tests <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5941>
<mup> PR core18#70 closed: hooks: add rfkill <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/70>
<mup> PR snapd#5939 closed: tweak .travis.yml so we no longer get weird env output in the logs <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5939>
<mup> PR snapd#5943 closed: osutils: unit tests speedup; introduce Â«run-checks --short-unitÂ» <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5943>
<dot-tobias> zyga: Good morning and sorry to bother you (again) with a layouts question: https://forum.snapcraft.io/t/snap-layouts/7207/3?u=tobias â Happy for any suggestion that resolves this issue, since I cannot publish my snap without this ð
<zyga> good morning, looking
<zyga> dot-tobias: hey, can you double check this on edge?
<zyga> though let me double check that edge is really edge now, release messes that up
<zyga> eh, no
<zyga> edge is not edge :/
<zyga> mvo: how soon can we get edge builds back to normal?
<dot-tobias> zyga: Happy to check once edge is edge :-)
<zyga> dot-tobias: I'll check locally soon, just let me wrap something up
<dot-tobias> zyga: Sure, glad you have time for this at all ð
<mup> PR core18#72 opened: writable-path: enable persistent journal <Created by mvo5> <https://github.com/snapcore/core18/pull/72>
<mvo> zyga: meh, one sec
<mvo> zyga: I restored edge
<mvo> zyga: and triggered a vendor sync manually
<mvo> zyga: I suspect that vendor-sync is not running automatically right now (cc cachio)
<zyga> mvo: thank you again
<zyga> mvo: reviewed ^
<mvo> thank you!
<mup> PR snapd#5451 closed: interfaces: honor static attributes when reloading conns <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5451>
<mup> PR snapd#5497 closed: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5497>
<niemeyer> Mornings
<Chipaca> moin moin
<zyga> hey guys
<mvo> hey niemeyer and Chipaca
<mvo> Chipaca: nice job on the test speedups!
<Chipaca> today's a weird day for me, one of the boys is at a new school having a trial day, and I need to go do a tour of it at 1pm (so no 2pm standup for me)
<Chipaca> mvo: :-D
<Chipaca> mvo: mborzecki: I struggled with where to draw the line between shortening sleeps, and skipping on testing.Short()
<Chipaca> mvo: mborzecki: so feedback very appreciated
<Chipaca> i started also working on overlord, but it's a lot hairier
<Chipaca> :)
<mvo> Chipaca: yeah
<mvo> Chipaca: my only concern is slow/overcommited hardware but we can tweak things into the other direction once we get results from autopkgtest
<Chipaca> mvo: maybe, maybe, we tell autopkgtest to only run --short-unit now
<mvo> niemeyer: if you could add github.com/snapcore/pi-gadget to the things that mup watches, that would be great!
<mvo> ogra: your feedback on github.com/snapcore/pi-gadget pull 9 would be great
<niemeyer> mvo: Thanks for the reminder
<mup> PR #9: Added the travis config file <Created by elopio> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/9>
<niemeyer> mvo: DOing it right away
<mvo> thank you!
<mup> PR snapd#5945 opened: overlord/snapstate: block parallel installs of snapd, core, base, kernel, gadget snaps <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5945>
<niemeyer> mvo: SHould be up
<mup> PR snapd#5946 opened: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
<pstolowski> morning niemeyer
<niemeyer> o/
<mup> PR snapd#5947 opened: many: cleanup remaining parallel installs TODOs <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947>
<zyga> niemeyer: I heard that Brazil has some exciting election time now
<Chipaca> oh man
<Chipaca> mborzecki: how does a user learn about instances?
<mup> PR core18#73 opened: hooks: run console-conf after snapd.seeded.service <Created by mvo5> <https://github.com/snapcore/core18/pull/73>
<Chipaca> mborzecki: I suspect the install docs is where. In which case, we need a longer explanation :-)
<mborzecki> Chipaca: from the docs atm
<mborzecki> Chipaca: you mean snap install help?
<Chipaca> mborzecki: yeah. Maybe work with degville to get a concise paragraph in there about 'em
<Chipaca> right now it only makes sense if you know what they are already
<mborzecki> Chipaca: yes, the pr only mentions instance key but now how it can be used
<ogra> mvo, perhaps also bump the tag of the pi2 u-boot build o they are on the same version
<ogra> s/o/so
<mvo> ogra: sure, will do
<niemeyer> zyga: Yeah, pretty interesting
<niemeyer> In a sad way
<mborzecki> Chipaca: so you're saying "" would pop up in place of snap.TypeApp?
<niemeyer> It's OMG what will the crazy guy do, vs. let's continue 16 years of recession
<zyga> niemeyer: yeah, it seems the chances of the reasonable candidate are pretty slim in the 2nd round
<mborzecki> Chipaca: hm we set TypeApp if type was empty in Yaml, but when using store data we leave whatever the store sent :/
<niemeyer> zyga: The second candidate is not reasonable either.. it's continuing the 16 years of power abuse
<zyga> in that case the reasonable thing is to really leave, which is depressing for all, impossible for many
<niemeyer> Right
<mborzecki> pedronis: quick question, having a model assertion, kernel and gadget need to be valid 'store' snap names too, not only required-snaps?
<ogra> mborzecki, you can use --extra-snaps (at the cost of upgradeability and interface auto-connections)
<ogra> with ubuntu-image that is
<Chipaca> mborzecki: handling "" as well would be the safe route
<Chipaca> mborzecki: but, supposedly it's  now never "" outside of tests
<Chipaca> mborzecki: butÂ², we don't validate this fact
<Chipaca> we probably should if we're going to assume it inside
<Chipaca> bah
<Chipaca> mborzecki: all it'd  take is a tweak to snap/types.go's unmarshallers
<Chipaca> we already (still!) have a check for type "application"
<Chipaca> could add "" to the list :)
<Chipaca> or, live dangerously and remove "application" _and_ "" support
<mvo> ogra, apw I would like to upload http://paste.ubuntu.com/p/HnXmvSHCww/ to cosmic and to our core18 ppa (and possible sru to bionic) - does that look sensible?
<ogra> mvo, totall
<ogra> y
<ogra> go ahead
<mvo> ogra: a bit of a meta question, it looks like hwclock from busybox tries to open some files in /dev/rtc - are there devices where we use fixrtc that actually have a rtc device?
<mvo> ogra: thanks
<ogra> mvo, there are "hat's" for the pi providing rtc
<mvo> ogra: thanks
<ogra> (and indeed there are other arm board with rtc too)
<mvo> ogra: I will update the comment with that info
<ogra> in general fixrtc needs an overhaul though due to the stuff that zyga found (kernel not updating timestamp of the rootfs on shutdown because of the readonly mount)
<mvo> ogra: I updated http://paste.ubuntu.com/p/3VNNRmqZpj/ with a comment
<ogra> mvo, well, i wouldnt make that "pi" specific ... fixrtc is in all our arm installs
<ogra> (armhf that is ....)
<mvo> ogra: thanks, updated again http://paste.ubuntu.com/p/wdQDrzqTqv/
<ogra> mvo, looks good
<pedronis> mborzecki: I'm not sure I understand the question
<mborzecki> pedronis: there was a TODO in device_asserts to check whether required-snaps are valid store snap names when decoding model assertion
<mborzecki> pedronis: i've extended this to cover kernel, gadget and base
<pedronis> ok
<pedronis> remember kernel and gadget takes = as well now
<mup> PR snapd#5948 opened: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
<mborzecki> pedronis: ^^
<apw> mvo, if it is always using /dev/misc/rtc, you could do like
<apw> [ -e /dev/misc/rtc ] && ...
<mvo> apw: yeah, I was thinking about this, it tests /dev/rtc /dev/rtc0 /dev/misc/rtc in busybox. the downside of adding the checks is that then we need to keep the initramfs code in sync with busybox/kernel - if this search paths ever change we will most likely not notice. OTOH it seems very unlikely this changes (famous last words)
<mup> PR core-build#35 opened: scripts/ubuntu-core/rootfs: fix mkdir error when the file exists <Created by mvo5> <https://github.com/snapcore/core-build/pull/35>
<apw> mvo, oh for a -q options ... oh well
<mvo> apw: yeah, --quiet would rock. I looked at the source, busybox is a bit simple in this regard unfortunately
<apw> yeah sure it is
<mup> PR snapd#5945 closed: overlord/snapstate: block parallel installs of snapd, core, base, kernel, gadget snaps <Parallel installs â> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5945>
<zyga> oh boy
<zyga> so
<zyga> not sure how to proceed
<zyga> I want to run snapd in a "container"
<zyga> (ish)
<zyga> it seems that I need to run systemd in the container as well
<zyga> and to make it a proper container enough so that it doesn't bite the host
<mvo> zyga: that sounds right, could you use lxd?
<zyga> no
<zyga> because I really need to craft everything in a specific way
 * zyga proceeds to unshared more 
<zyga> la la la
<zyga> running systemd partially unshared is fun,
<zyga> (where fun == reboot to fix your system)
<zyga> some small progress made,
<mborzecki> cachio: i'm playing with arch-apparmor image you prepared and #5894 branch, seems to be working now, i'll a full run of arch tests on this image
<mup> PR #5894: many: enable AppArmor on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5894>
<mborzecki> off to pick up the kids
<zyga> I need to take the dog out
<zyga> ttyl
<mup> PR core-build#35 closed: scripts/ubuntu-core/rootfs: fix mkdir error when the file exists <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/35>
<ogra> oh damn ... its a holiday in the us !
<ogra> (so i guess no jdstrand today ... )
<ogra> mvo, shellcheck isnt happy with your initramfs-tools-ubuntu-core it seems
<ogra> In ./hooks/resize line 20:
<ogra> . /usr/share/initramfs-tools/hook-functions
<ogra> ^-- SC1091: Not following: /usr/share/initramfs-tools/hook-functions was not specified as input (see shellcheck -x).
<mvo> ogra: aha, thanks - where do you see that? i have a look
<ogra> mvo, i got a mail from LP with link to the build log ... https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/15520942/+files/buildlog_ubuntu-bionic-amd64.initramfs-tools-ubuntu-core_0.7.45+ppa2_BUILDING.txt.gz
<mup> PR snapcraft#2325 closed: plugins: remove the python2 and python3 plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2325>
<mvo> ogra: aha, I see, the bionic build?
<ogra> yeah
<mvo> ogra: i guess this is why we did not see this before, the test runs on xenial and bionic is more strict. I will fix in a wee bit
<mborzecki> re
<mup> PR snapcraft#2322 closed: project_loader: add build-environment part property <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2322>
<rbasak> Is there a quick way to get an unpacked snap to use with "snap try", apart from me unpacking the snap by hand?
<rbasak> "snap unpack" doesn't appear to exist
<zyga> rbasak: unsquashfs
<zyga> rbasak: we have snap pack because certain arguments to squashfs matter
<zyga> rbasak: and because we also do some validation (AFAIR)
<zyga> rbasak: on the "unpack" phase there's not much to do
<zyga> though I agree that for consistency we perhaps might
<rbasak> zyga: aha! Just want I wanted. Thanks. Saves my mount/rsync/unmount triple :)
<rbasak> zyga: perhaps document that in "snap help try"? Eg. "The try command installs an unpacked snap into the system for testing purposes, such as one extracted from a snap with unsquashfs(1)." - then I'd have found it.
<rbasak> s/one/a directory/ perhaps
<rbasak> Or maybe "the"
<zyga> mmm, yeah, that feels like a good idea
<Chipaca> or maybe just add 'snap unpack' :)
<Chipaca> hello from just-out-of-the-meeting--land
<ogra> jdstrand, arent you celebrating that guy who got lost looking for india today (just asw MP comments from you) ?
<ogra> read: are you working ?
<ogra> s/asw/saw/
<mup> PR snapd#5949 opened: osutil,asserts,daemon: support force password change in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5949>
<mup> PR core-build#36 opened: initramfs: fix shellchecks on bionic <Created by mvo5> <https://github.com/snapcore/core-build/pull/36>
<cachio> cwayne, hey, do you know the status of 2.35.4?
<cachio> is it ready to go to cnadidate?
<rbasak> mvo: around? Taking the current edge git-ubuntu snap, if copy $SNAP/usr/local/bin/quilt to /tmp inside a snap shell and apply your MP to that, running quilt results in "Illegal instruction (core dumped)". I'll dig deeper.
<sergiusens> rbasak: if you move $SNAP/usr/local/bin/quilt the $ORIGIN based rpaths will most likely be wrong
<rbasak> the local/bin/ files are just wrappers that set PATH and LD_LIBRARY_PATH
<rbasak> I've narrowed it a bit.
<rbasak> If I just set PATH and LD_LIBRARY_PATH to the core snap only, then everything crashes with SIGILL. Including ls, ldd, etc.
<sil2100>  mvo: hmmm, interesting, a fresh image built with the new model assertion doesn't segfault with probert on my raspi3 anymore
<sil2100> mvo: this is really annoying, how could this issue suddenly disappear?
<sil2100> mvo: I also have proper wired networking, no crashes in console-conf
<sil2100> Let me try a complete vanilla image
<mvo> rbasak: woah, let me try to reproduce this myself
<mvo> rbasak: you really find all the interessting bugs :)
<mvo> sil2100: oh, so you have wired and wireless?
<mvo> sil2100: note that for me it works on the pi without wifi
<mvo> sil2100: but on the 3b+ with wifi I still had issues (looks like crashes)
<mvo> sil2100: let me try on the 3b+ again
<sil2100> mvo: I couldn't connect to my wireless AP but it didn't crash or anything
<sil2100> I have a regular 3b
<mvo> sil2100: and you see the wireless in the config?
<sil2100> So on a vanilla image I see a crash in console-conf
<cjwatson> build.snapcraft.io now builds for all architectures by default: https://forum.snapcraft.io/t/more-architectures-enabled-in-build-snapcraft-io/7733
<sil2100> Similar to the one ondra reported, with console-conf crashing because it cannot run snap create
<sil2100> *create-user
<mvo> sil2100: ok, let me try again on my pi3
<sil2100> mvo: I'm also trying different combinations right now
<mvo> sil2100: about snap create - I pushed a PR to run console-conf after snapd.seeded.service - this way console-conf should have a fully working snapd and some of the issues we saw earlier should be fixed
<ogra> argh ! build.s.io all of a sudden produces s390x and ppc64el builds !
<ogra> crazy world
<cjwatson> See ten lines back :)
<Chipaca> "all architectures", but still no builds for RCA 1802
<Chipaca> psh
<cjwatson> I regret that we also don't build for Doric columns
 * cachio lunch
<Chipaca> nor for for the TMS320C80
<Chipaca> it's like you're not even trying
 * cjwatson looks forward to that contract
<ogra> heh
<mvo> sil2100: yeah, on my pi3b+ I also now see console-conf, nice. also disturbing why it suddenly works, I will try with a fresh dd of the image again to see if its maybe firstboot related
<mup> PR core18#73 closed: hooks: run console-conf after snapd.seeded.service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/73>
<ogra> sil2100, FYI core 16 edge works fine on my b+ over here ... i think we can push the gadgets to stable
<sil2100> ogra: ok, let's coordinate regarding that tomorrow
<ogra> (just got mine on sat.)
<ogra> sil2100, +1
<sil2100> mvo: strange indeed - anyway, as for the config, if I checked correctly I had no wlan in the yaml but I guess that's normal since I didn't configure it - since somehow it was unable to connect to my AP
<sil2100> But maybe I simply forgot the password ;o
<mvo> sil2100: heh
<mvo> sil2100: I couldn't connect to my wlan either so maybe something with the kernel or userland
<ogra> just use core16, it works fine :P
<ogra> always that upgrade obsesion :P
<sil2100> Ok, but at least we can now properly use the images on the pi
<sil2100> ogra: ;)
<mvo> sil2100: I also had no wired network on the pi3 b+ so maybe something with that model, my pi2 was fine
<mup> PR snapd#5623 closed: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5623>
<niemeyer> mvo: Sent a note on #5871.. it's a LGTM, but I screwed up the review and sent a comment too soon, sorry
<mup> PR #5871: snapstate: only report errors if there is an actual error  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5871>
<niemeyer> pedronis: ping
<mvo> niemeyer: thanks!
<mvo> sil2100: so good news and bad news - after a fresh flash still no crash on the pi3 b+, so yay! but also no network (not wired nor wirelss)
<mborzecki> arch & gce, a story of crng init :/ https://paste.ubuntu.com/p/SwKw5C7XKS/
<sil2100> mvo: ouch
<sil2100> grrr
<pedronis> niemeyer: pong
<pedronis> niemeyer: the code will work as you expect it,  I was trying not to use parent in the docs of this, but the model is more that a child store is extended by including more (parent) stores
<ogra> mvo, are you sure the right dtb is being used (the core of the b+ is identical to the other pi3's, only peripherials differ and they are declared in the dtb)
<mup> PR snapcraft#2300 closed: [WIP] plugins: remove implicit source <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2300>
<mup> PR snapcraft#2326 opened: plugins: remove implicit source <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2326>
<niemeyer> pedronis: "extension" is fine, the question is because it sounds like the who-extends-whom is reversed
<niemeyer> pedronis: The thing declaring the friendly stores is the one that accepts (extends) snaps from the listed ones
<pedronis> niemeyer: yes, it exposes snaps from those
<niemeyer> pedronis: Ah, "expose" might be a nicer way to convey it
<pedronis> niemeyer: "returns further stores that are exposed by this store" ?
<pedronis> "by" or "through"
<niemeyer> pedronis: Returns stores holding snaps that are also exposed but this one, or something along those lines
<pedronis> ok
<pedronis> thx
<pedronis> niemeyer: changed
<pedronis> mvo: have you branched again 2.36 or not yet?
<mup> PR snapcraft#2324 closed: plugins: remove the ament plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2324>
<mvo> pedronis: not yet branched again
<mvo> pedronis: once 2.35.4 hits candidate I will push the next beta of 2.36
<mvo> ogra: not sure at all :) any hints appreciated
<pedronis> mvo: ok, waiting for my main 2.36 left branch to get green
<pedronis> I got the 2nd 11
<pedronis> *+1
<mvo> yay
<ogra> mvo, well, do you have /boot/uboot/bcm2710-rpi-3-b-plus.dtb ?
<ogra> else it will just automatically use bcm2710-rpi-3-b.dtb ...
<mvo> ogra: yes, that file is there
<ogra>  /proc/device-tree/model also shows the Plus dtb to be used ?
<Chipaca> travis getting 50kb/h from that gce archive
<Chipaca> :-(
<mvo> ogra: let me try, I need to hack myself in first, I can't create a user via console-conf right now :/ so give me 5min
<ogra> thats why i never use canonical models during development ... system-user assertion FTW ;)
<mvo> ogra: heh :) cat /proc/device-tree/model ;echo
<mvo> Raspberry Pi 3 Model B Plus Rev 1.3
<ogra> looks fine ... so the dtb is definitely correct
<ogra> do you see NICs at all in /proc/net/dev ?
<mvo> ogra: yeah, also console-conf shows them, but they are just not working for some strange rseason
<ogra> oh
<mvo> even for wired which is weird
<mvo> (link led is on fwiw on pi and router)
 * mvo pokes some more
<pstolowski> cachio: hey, you were mentioning on the sprint a spread test extending nested vm helpers (if i remember correctly); did you make progress with this?
<cachio> pstolowski, no but I could start working on in today
<cachio> after the ubuntu cosmic PR is ready
<pstolowski> cachio: ack, thanks
<zyga> anyone from the store, my uploads go away as "__all__: The upload does not appear to be a valid package"
<zyga> but it installs just fine locally :/
<zyga> any ideas?
<pstolowski> niemeyer: any chance for a re-review of #5759? also, the other 3 hotplug PRs have +1s but need one more review
<mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<Chipaca> EOD o/
<niemeyer> pstolowski|afk: yeah, excellent chances.. :)
<niemeyer> pstolowski|afk: Not all today probably, though
<mup> PR snapd#5882 closed: many:  support and consider store friendly-stores when checking device scope constraints <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5882>
<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#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR snapd#5950 opened: tests: running the snapd tests on Ubuntu 18.10 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5950>
<Chipaca> cachio: hi
<Chipaca> cachio: if you could review #5938, we can land it and then your #5950 won't fail any more...
<mup> PR #5938: tests/lib: rework the CLA checker  <Created by chipaca> <https://github.com/snapcore/snapd/pull/5938>
<mup> PR #5950: tests: running the snapd tests on Ubuntu 18.10 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5950>
<cachio> Chipaca, sure
<cachio> Chipaca, reviewing
<mup> PR snapd#5938 closed: tests/lib: rework the CLA checker  <Created by chipaca> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5938>
#snappy 2018-10-09
<mup> PR snapcraft#2326 closed: plugins: remove implicit source <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2326>
<mborzecki> morning
<mup> PR core18#74 opened: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <https://github.com/snapcore/core18/pull/74>
<mup> PR core18#74 closed: hooks: use core18.start-snapd.service for ordering <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/74>
<mup> PR snapd#5910 closed: snapshotstate: restore to current revision <Snapshots ð¸ó > <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5910>
<mup> PR core18#75 opened: static: show snapd firstboot messages on /dev/console  <Created by mvo5> <https://github.com/snapcore/core18/pull/75>
<mup> PR core18#75 closed: static: show snapd firstboot messages on /dev/console  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/75>
<zyga> o/
<mborzecki> zyga: hey
<mvo> hey zyga and mborzecki
<mup> PR core18#76 opened: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <https://github.com/snapcore/core18/pull/76>
<zyga> :-)
<mup> PR core18#76 closed: static: make run-snapd-from-snap wait for seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/76>
<mvo> uh, on the pi I get "backend.go:319: cannot create host snap-confine apparmor configuration: cannot s
<mvo> ynchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/
<mvo> snap-confine.snapd.1122.m8GcXdqQ5cDR~: no such file or directory" quite often
<mvo> at firstboot seeding
 * mvo wonders what is going on there
<pstolowski> mornings
<mvo> hey pstolowski
<zyga> mvo: didn't we fix that?
<zyga> mvo: is the pi using anything modern or is this the release image?
<zyga> (release as in 16.04)
<mvo> zyga: let me check, it should use master
<mvo> zyga: rev is 2.35.4+git1480.gdb577fc
<mvo> from 7h ago
<zyga> hmm, then it looks real
<mvo> I'm debugging a different issue right now, we look after this but it looks scary as it breaks first boot seeding
<zyga> k
<mvo> its a race most likely
<mvo> does not happen all the time
<mvo> and I think not at all on quick HW like amd64
<mvo> plus it is (currently) mask by this other bug that console-conf runs too early
<zyga> mvo: is https://github.com/snapcore/snapd/pull/5917 still something we want (AFAIK you want to branch master so back ports are not needed)
<mup> PR #5917: cmd/snap: attempt to start the document portal if running with a sessâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5917>
<mup> PR snapd#5927 closed: cmd/snap-update-ns: remove empty placeholders used for mounting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5927>
<mvo> zyga: I think its something we want
<zyga> k, just land it then
<zyga> note, the master version landed already
<mvo> zyga: I will branch again once 2.35.4 is in candidate
<mvo> zyga: aha, ok
<zyga> this is just a back port
<mvo> ok
<pedronis> mvo: I still have a small image.go PR to do (now that everything in snapd itself has landed), can be backported after the main branching tough
<mvo> pedronis: ok, thank you
<mvo> zyga: I think I have an idea about the bug, will go full force once I am finished with the current console-conf sync issue
<zyga> let me know what you find
<mup> PR snapd#5951 opened: spread-shellcheck: fix interleaved error messages, tweaks <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
<mborzecki> anyone wishing to review #5947 and #5948 ? feel free to do one or both
<mup> PR #5947: many: cleanup remaining parallel installs TODOs <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947>
<mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
<mborzecki> pstolowski: any of your hotplug PRs need attention?
<mborzecki> pstolowski: i have #5860 open
<mup> PR #5860: interfaces/hotplug: helpers and struct updates <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
<zyga> mborzecki: I can do after noon
<pstolowski> mborzecki: you can review that one, yes; i generally miss Gustavo's reviews on all of them. i'll have new PRs today I think, i'm going to split my code and propose complete feature in 2-3 pieces, so there will be new material to review. thanks for asking!
<zyga> still fighting that test
<mup> PR core18#77 opened: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <https://github.com/snapcore/core18/pull/77>
<niemeyer> pstolowski: Sorry, haven't managed to get to the rest of them yesterday (did get to the key gen one).. will put the others at the top of my queue today
<pstolowski> niemeyer: sure, thanks for the device key review, addressed your feedback and trying to land (travis is not cooperating, again)
<mup> PR core18#77 closed: hooks: ensure serial-console-conf also runs after core18.start-snapd.service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/77>
<mup> PR core-build#36 closed: initramfs: fix shellchecks on bionic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/36>
 * zyga -> small break
 * zyga is about to throw the towel on the overlayfs test
<ogra> cjwatson, did the builders become stricter with the recent changes ? i just did manual re-builds of some of my snaps that never had probs building and all of a sudden they fail to release ... there are warnings about host libs being pulled in but i think they were there before and did not make the snap get stuck
<cjwatson> ogra: no
<ogra> weird
<cjwatson> ogra: "failed to release" is from the store, not from the builders, anyway
<ogra> yeah, but i dont even see the re-built snaps in the store ... like they never arrived
<cjwatson> so this is either due to snapcraft or due to the review tools, probably; unlikely to be the builders
<cjwatson> ogra: it's not fair to ask me to speculate on this without giving me a link
<ogra> https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860
<ogra> aha !
<ogra> Temporary failure in name resolution
<ogra> looks liek some internal DC thing
<ogra> (sorry, i only looked at build.s.io ... could have checked LP directly)
<cjwatson> That's the ENOMEM issue on ackee
<cjwatson> It is SUPER WEIRD
<ogra> are there chances clicking retry will work (else i'll just leave it as is for the moment, there were no important snaps re-built, only because of security notifications)
<cjwatson> We have three workers that run various jobs such as store uploads; as of a few weeks ago, occasionally one of them gets into a state where it starts getting ENOMEM for all attempts to allocate memory, despite there being loads of memory free and all the other usual things you might check in this situation
<cjwatson> This results in a bunch of things failing, including DNS resolution
<ogra> weird indeed ...
<ogra> yeah
<cjwatson> Hmm, one of the workers is in that state right now
<ogra> it might be a good idea to forward the error message to the build.snapcraft.io log or some such
<ogra> especially since the only link to look at LP is at the top of the log iself ... not sure how many people will actually use that to find out more
<cjwatson> The BSI log is just the build log
<cjwatson> Can't do that
<cjwatson> I have a spec for improvements to LP's store upload process
<cjwatson> It's probably not next on my list but maybe the one after that
<ogra> well, this is mostly about the UI of build.s.io ... not even sure thats in your area of things :)
<ogra> having some direct link to the LP build or some more info than a bland "Failed to release" with no further info on the page would help
<cjwatson> Evan says we're not allowed :P
<ogra> haha
<cjwatson> (to have a direct link to LP)
<ogra> yeah ... i got that
<mup> PR core18#78 opened: static: show seed progress on console on firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/78>
<mup> PR core18#78 closed: static: show seed progress on console on firstboot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/78>
<cjwatson> ogra: Bug in the BSI UI, I think - it's meant to show it but there's a confusion about ![] not being true in JS
<ogra> ah
<mup> PR snapd#5952 opened: tests/ifacestate: moved asserts-related mocking into helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
<mborzecki> why are timers/sockets enabled in StartServices() rather than AddSnapServices() ?
<pstolowski> pedronis: can you take a look ^ ?
<pedronis> pstolowski: yes, after lunch
<cjwatson> ogra: Anyway, you can try using Retry, though due to the various problems outlined in https://docs.google.com/document/d/1vabN2wBNtGdBqShN1xi9a-osfGPtmA8EARdXfs2kfDI it's possible that it will require a full rebuild in order to be uploadable
<ogra> cjwatson, well, i just tried retry and got a permission error
<ogra> seemingly i'm not allowed to retry
<cjwatson> A permission error saying what precisely?
<cjwatson> Oh, from https://launchpad.net/~build.snapcraft.io/+snap/3fc16b55a813a672666c6ff13690918e-xenial/+build/323860 ?  Yeah, LP doesn't know that you own the snap on BSI.
<ogra> right
<cjwatson> I've hit Retry but it probably won't work
<ogra> well, that particular snap is less important anyway ... and i'll trigger rebuilds for the others
<cjwatson> Yeah, that hit the silly duplicate-snap-content error from the store
<cjwatson> Which is one of the things my spec covers
<mup> PR core18#79 opened: snap-snapd-from-snap: remove all debug output <Created by mvo5> <https://github.com/snapcore/core18/pull/79>
<Chipaca> if/when you spot a unit test on travis taking ages talking to the apt mirror, please let me know
<Chipaca> I want those logs
<Chipaca> e.g. https://travis-ci.org/snapcore/snapd/jobs/439058232
<mup> PR snapd#5953 opened: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <https://github.com/snapcore/snapd/pull/5953>
<ogra> ppisati, hmm, 4.4.0-1099-raspi2 doesnt have the modules fix yet ? (i just had an upgrade on my pi's and the splashes went away)
<ogra> cjwatson, hmm, are we short on arm builders again (all my retried builds now sit in "building soon" state for all amr arches)
<ogra> *arm
<cjwatson> ogra: see #is-outage please
<cjwatson> work in progress
<ogra> ok
<mborzecki> https://paste.ubuntu.com/p/gTn99BMxhg/ snap services with sockets and timers
<niemeyer> pstolowski|lunch: Nitpick (and optional, obviously):
<niemeyer>  			// attribute name and value are separated by null character
<niemeyer> That's exactly what the code below it says
<niemeyer> more clearly
<dot-tobias> zyga: re: https://forum.snapcraft.io/t/snap-layouts/7207/4?u=tobias â Added an answer, but it seems there's something else going on there. I'm running a command in my install hook to copy files over from $SNAP/folder/subfolder/* to $SNAP_DATA/subfolder, could it be that? This happens even when I completely remove the âpartly duplicated file nameâ section from the layout stanza.
<niemeyer> pstolowski|lunch: Ah, there's something else.. will comment on the PR
<zyga> dot-tobias: I don't think the hook is a factor, it runs after the setup process, in any case, if you can share a snap that I can play with (even a dummy one that has this bug) it would help as I was unable to reproduce this
<dot-tobias> zyga: Will cook up something, thanks
<cachio> pstolowski|lunch, hey, already working in nested suite
<mborzecki> Chipaca: niemeyer: i see you've discussed including timers in snap services commands, i've posted a note in the topic https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/33 feel free to provide suggestions
<mborzecki> cachio: hey, https://github.com/snapcore/spread-images/pull/17 had to execute those manually, but afaict the host after those changes appears to work fine
<mup> PR spread-images#17: tasks/google/update-arch-linux: tweak Arch image update <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/17>
<cachio> mborzecki, nice, checking
<mup> PR snapcraft#2323 closed: go plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323>
<niemeyer> mborzecki: Thanks!
<Chipaca> oh, what a surprise, opensuse failing agian :-((((((
<Chipaca> can we add a rule, "to be supported by snapd, your distro's mirror archive must be *this* available"?
<mup> PR snapcraft#2327 opened: pluginhandler: remove prepare, build and install scriptlets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2327>
<cachio> mborzecki, works!!
<niemeyer> mborzecki: Responded
<mup> PR snapcraft#2328 opened: godeps plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328>
<rbasak> mvo_: I put a reproducer in bug 1796017
<mup> Bug #1796017: git ubuntu build-source fails with missing libreadline.so.6 <usd-importer:In Progress by racb> <https://launchpad.net/bugs/1796017>
<rbasak> I'm a bit baffled as to why this doesn't work. Is there anything else going on eg. seccomp?
<rbasak> Or other necessary environment changes that I missed?
<cachio> mborzecki,
<mup> PR core18#79 closed: snap-snapd-from-snap: remove all debug output <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/79>
<ogra> argh
<ogra> sergiusens, !!!
<ogra> Snapping 'pi-kiosk' |
<ogra> Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap
<ogra> Stopping local:snapcraft-sadly-choice-amoeba
<ogra> Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap"
<ogra> sergiusens, thats a snapcraft cleanbuild of a snap using build-on/run-on ...
<ijohnson> ogra: stop naming your snap "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')])"
<sergiusens> ogra: we'll get kyrofa to take a look when he gets in
<ogra> i'd kind of expect the resulting snap file not to contain python code in its name
<sergiusens> but, cleanbuild is also deprecated to a baseless world
<ogra> so how do i build my snaps now ?
<sergiusens> ogra: if you set a base, you get a build vm
<ogra> sergiusens, so i need to touich all the snaps i have ?
<ogra> (for re-builds when getting security notifications ??)
<sergiusens> ogra: no, if you do not change anything, you don't need to touch anything
<ogra> cjwatson, i know you are busy with the outage ... but i see some weird cross build behaviour on the builders that i can not reproduce locally either with a plain build or withz a snapcraft cleanbuild
<ogra> checking for arm-linux-gcc... /usr/bin/arm-linux-gnueabihf-gcc
<ogra> checking whether the C compiler works... no
<ogra> configure: error: in `/build/pi-kiosk/parts/psplash/build':
<ogra> configure: error: C compiler cannot create executables
<mup> PR snapcraft#2329 opened: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329>
<ogra> the fun part is that theer is a part before that just used /usr/bin/arm-linux-gnueabihf-gcc to build a binary
<cjwatson> ogra: I have no idea, sorry.  Try catting config.log after the failure to get more details
<ogra> hmm., k
<mborzecki> Chipaca: can you take a quick look at https://github.com/snapcore/snapd/pull/5951 ?
<mup> PR #5951: spread-shellcheck: fix interleaved error messages, tweaks <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
<Chipaca> mborzecki: what do you think about my 'activator' comment?
<mup> PR snapcraft#2330 opened: pluginhandler: remove big solidus workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330>
 * Chipaca ~> school run*
<Chipaca> * wee (maybe)
<ackk> hi, is there a way to specify the container image/release when running "snapcraft cleanbuild"?
<mup> PR snapd#5759 closed: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<ogra> cjwatson, here we go https://launchpadlibrarian.net/392453534/buildlog_snap_ubuntu_xenial_amd64_ae16fdc83ee020a5817d7f0243e105b5-xenial_BUILDING.txt.gz seems while my desktop and cleanbuild automatically install binutils-arm-linux-gnueabihf when i add a "build-packages" entry for gcc-arm-linux-gnueabihf, the LP builder doesnt do so
<ogra> at least thats my guess for:
<ogra> configure:2973: /usr/bin/arm-linux-gnueabihf-gcc    conftest.c  >&5
<ogra> collect2: error: ld returned 1 exit status
<ogra> grrr ! IRC
<ogra> configure:2973: /usr/bin/arm-linux-gnueabihf-gcc    conftest.c  >&5
<ogra> /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crt1.o: No such file or directory
<ogra> /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find crti.o: No such file or directory
<ogra> collect2: error: ld returned 1 exit status
<ackk> sergiusens, hi, maybe you have insights on my question above?
<ogra> aha !
<ogra> libc6-dev-armhf-cross iss a recommends ... ok
<ogra> *is
<ogra> cjwatson, thanks for pointing in the right direction i think i got a workaround for that one (though it is still weird that cleanbuild doesnt expose that issue)
<niemeyer> Hey folks.. I'm back
<ogra> whee ! a properly cross built gadget snap on build.snapcraft.io !!!!
<ogra> https://launchpad.net/~build.snapcraft.io/+snap/ae16fdc83ee020a5817d7f0243e105b5-xenial/+build/349077
<ogra> very nice !
<sergiusens> ackk: no, there is not; we are moving to a new model which will be trickled by the use of bases.
<mup> PR snapd#5954 opened: [wayland] explicitly permit file locking for wayland lock <Created by gerboland> <https://github.com/snapcore/snapd/pull/5954>
<ogra> jdstrand, so i have https://dashboard.snapcraft.io/snaps/dashkiosk-client-image-config/revisions/11/ ... using a self-provuded udisks2 interface, is there any chance you would approve that or should i rip out the code using that interface ?
<ogra> jdstrand, source is at: https://github.com/ogra1/dashkiosk-client-image-config
<ackk> sergiusens, I see, so there's currently no way of cleanbuilding a core18 snap
<ondra> kyrofa ping
<sergiusens> ackk: no, for that you probably want to be on edge and set SNAPCRAFT_BUILD_ENVIRONMENT=multipass (and set base: core18)
<kyrofa> ondra, hey there
<ackk> sergiusens, ah I see. I do use edge and core18 base
<ackk> sergiusens, so this will only be available on multipass?
<sergiusens> ackk: just missing the env then, but edge should switch to creating the VM by default real soon
<ackk> sergiusens, thanks
<sergiusens> ackk: for the time being yes, it what was agreed to during the roadmap sprint. Next cycle we will bring back lxd
<ondra> kyrofa hey
<ondra> kyrofa can you please check https://code.launchpad.net/~ondrak/+snap/toolbox
<ondra> kyrofa for whatever reason on arm64 it breaks when priming
<cjwatson> ogra: mm, may be the sort of thing that gets ironed out by moving to a common build container/VM/whatever
<ogra> cjwatson, well, fallout of --no-install-recommends i think
<ogra> apparently the cleanbuild lxd container installs recommends by default
<cjwatson> ogra: which is in the LP build chroots' apt.conf
<cjwatson> ogra: hence my comment
<ogra> right
 * cachio lunch
<kyrofa> ondra, is peekfd an app?
<ondra> kyrofa yep
<kyrofa> ondra, looks like you're using usr/bin/peekfd as an app, but for whatever reason on arm64 it doesn't exist (not that the traceback is turned into a nicer error on edge)
<ondra> kyrofa unless it exist only on armhf and x86 and not on arm64
<kyrofa> s/not/note/
<kyrofa> Yeah not sure why, but that's the issue
<ondra> kyrofa can one define app per arch in this case?
<kyrofa> ondra, I'm afraid not
<ondra> kyrofa damn, so need to remove it from all, or bug against package I guess
<kyrofa> ondra, or add a wrapper that can handle it not being there and error out
<kyrofa> But yeah, I'd look into why it's not there
<ondra> kyrofa unrelated question, I have project which has two flavours. Ideally I'd like to build it from same branch, but that means two different snapcraft.yaml files, is there easy way to handle this?
<kyrofa> ondra, snapcraft doesn't have a way to consume two snapcraft.yamls, if that's what you're asking. Launchpad doesn't support it, either
<ondra> kyrofa yep, something along those lines
<roadmr> sergiusens: hi! what are the implications of https://bugs.launchpad.net/snapcraft/+bug/1794805 for the snapcraft parts service? https://parts.snapcraft.io/v1/parts.yaml
<mup> Bug #1794805: Remove wiki parts <18.10-build-vm> <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1794805>
<joc> hehe was just about ask my own question :)
<joc> sergiusens: with the remote parts wiki going, will there be some other method of re-using parts definitions across snaps? and what timescales are we looking at for this being unavailable?
<mup> PR core18#80 opened: static: show some progress during firstboot <Created by mvo5> <https://github.com/snapcore/core18/pull/80>
<sergiusens> roadmr: should keep on working, you use the deb, correct?
<sergiusens> joc: https://forum.snapcraft.io/t/proposal-templates/6019
<sergiusens> joc: if you are using bases, they are gone
<roadmr> sergiusens: I mean for the service itself - will it still be used or do we need to sunset it?
<roadmr> sergiusens: (but if it's expected to keep working for people using the .deb or something else, not a problem, it can stay up as long as needed)
<sergiusens> roadmr: when no one else builds with no base defined is the time we can put it to sleep
<roadmr> sergiusens: gotcha, that's exactly what I wanted to know. Thanks!
<roadmr> (sounds like that might be a long time in coming, but that's ok - parts service is quite lightweight, it can stay there indefinitely)
<joc> sergiusens: by "using bases" do you mean having e.g. "base: core18" in my snapcraft.yaml?
<sergiusens> joc: yes
<joc> oof
<mvo> Chipaca: so I would like to have a way to make "progress.Spin()" show stuff even when `snap watch` is not run from a terminal. the easiest way seems to be to add Spin() to quiteProgress but I wonder if that is the right option. maybe an option to waitMixin?
<mvo> Chipaca: wdyt?
<mup> PR snapcraft#2329 closed: pluginhandler: remove legacy plugin loading without project <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2329>
<Chipaca> mvo: 1 sec
<mvo> Chipaca: no rush :)
<Chipaca> mvo: I like it (in fact I thought it did that already)
<Chipaca> mvo: maybe only show the message if it changes?
<mup> PR core18#80 closed: static: show some progress during firstboot <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/80>
<mvo> Chipaca: aha, ok - so far it is doing a print on Notify() but not on Spin(msg)
<Chipaca> not sure how often we're calling Spin with the same message
<mvo> Chipaca: +1
<Chipaca> mvo: yep, just saw that
<mvo> Chipaca: awesome, I will make it happen (and +1 on checking if the message changes)
<sergiusens> joc: the deb will not break, it is essentially frozen; which means it will get no new features either
<Chipaca> mvo: OTOH, if this is for running it on /dev/console, is that not a tty? (or are we checking stdin instead of stdout?)
<mvo> Chipaca: we check stdin
<Chipaca> mvo: isn't that a bit silly?
<mvo> Chipaca: of course we could simply check stdout
<mvo> Chipaca: I guess :)
<Chipaca> of course by now there are people depending on us checking stdin
<Chipaca> but we could check both :)
<Chipaca> bah, dunno
<Chipaca> wtyt?
<Chipaca> we could also switch to checking stdin, and warn people via the forum
<mvo> Chipaca: one slightly complication is that my code does "snap watch --last=seed | tee -a /dev/console"
<Chipaca> "this was silly, we fixed it, sorry if we broke you but surely you agree it's less silly now"
<Chipaca> mvo: boo :-)
<Chipaca> er
<mvo> Chipaca: because we still want these messages in journalctl -u
<Chipaca> mvo: so why not 'snap watch --last=seed < /dev/console | tee -a /dev/console?
<mvo> Chipaca: aha, nice
<Chipaca> s/\?/'?/
<mvo> Chipaca: yeah, that should work, let me quickly test
<Chipaca> mvo: also, I'd recommend writing it '--last=seed?'
<Chipaca> unless you know for sure there is a seed change already
<mvo> Chipaca: yeah, I totally know
<Chipaca> k
<mvo> Chipaca: but good advice, thanks
<jdstrand> ogra: does it honor the slot side of the contract for udisks2? in other words, does it ship udisks2 such that other snaps can connect to it and use udisks2?
 * zyga resumes work on user-mounts
<zyga> hey jdstrand, how are you?
<ogra> jdstrand, well, it runs a daemon that spawns udisksd when a USB key is plugged in ...
<jdstrand> zyga: hey, pretty good. very busy :) how are you?
<zyga> jdstrand: had an interrupt but made a lot of progress for user mounts today
<zyga> jdstrand: expect some patches relatively quickly :)
<ogra> jdstrand, not sure what else the udisks2 "contract" requires ... the daemon-script is rather specifc to import a neplan yaml file if it exists ... and since this is for embedded systems it a) has an install hook check that prevents it from being installed on non-core and b) does not run udisksd permanently
<jdstrand> ogra: if you slots udisks2, then your snap is expected to provide the udisks2 service
<jdstrand> ogra: why are you slotting udisks2?
<ogra> jdstrand, well, how else would i get mounting to work from a snap ?
<jdstrand> ogra: I don't know what your snap does. have it plugs udisks2 and then talk to udisks2 to do that for you?
<ogra> i'd just use a udev monitor script and call mount driectly, but there are no interfaces offering that
<mup> PR core18#81 opened: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <https://github.com/snapcore/core18/pull/81>
<jdstrand> ogra: this sounds like a conversation for the forum. I suggest stating what it is your snap requires, and how you'd like to get there
<ogra> jdstrand, https://github.com/ogra1/dashkiosk-client-image-config/blob/master/netplan-import ... thats the daemon script ... it watched udev for udb block device plug events ... if one is there, it mounts the usb block device and looks for a netplan config
<ogra> *watches
<ogra> s/udb/usb/
<mup> PR core18#81 closed: static: tweak run-snapd-from-snap to avoid having to change `snap watch` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/81>
<ogra> jdstrand, well, i need the snap for a demo at IoT worldcongress next week, i'll just rip out that feature, i doubt i'll have the time to re-implement it differently in time
<ogra> effectively i just need an interface that allows me to run mount/umount and we dont have that
<jdstrand> ogra: you are calling udisckstl, why not plugs: [ udisks2 ] and have the udisks2 snap installed?
<jdstrand> then just talk to that other snap
<ogra> do we have that for all arches ?
 * ogra checks 
<ogra> hmm, k
<jdstrand> ogra: I see an armhf in edge
<kyrofa> Hey ogra, any ideas on this? https://askubuntu.com/questions/1082277/socketcan-device-on-ubuntu-core
<jdstrand> it's old, but it is there
<ogra> edge ... hmm
<zyga> roadmr: hey
<roadmr> hehey zyga ! how goes it!
<zyga> I need a hand in debugging a store side bug (presumably)
<zyga> remember that snap?
<zyga> I tried it again
<ogra> ah, also in stable
<jdstrand> ogra: looks like morphis did it. that would be the ce team now I guess
<zyga> first time I kept the hack with chmod
<zyga> it passed
<zyga> second time it did not
<zyga> I think something else is wonky
<jdstrand> yes, and stable
<zyga> I can show you the error I'm getting, it's very terse though
<ogra> jdstrand, thanks, i'll try to use that one ... effectively simply having snapd allow you to import a netplan config (like we allow system-user assertions) would be the proper solution after all
<roadmr> zyga: sure, error would be nice
<zyga> roadmr: let me re-make it, I also had issues with snapcraft in that run
<ogra> jdstrand, trying to create appliance images that do not force you to attach a serial cable to configure wlan ... (and that already have the screen occupied, so you cant use console-conf there)
<ogra> jdstrand, if i reject the held snap, i should be capable to upoad again without them getting stuck in the sotre review ?
<ogra> *store
<ogra> kyrofa, i think thats actually one for awe, i dont have moch experience with CAN bus stuff (but he has)
<jdstrand> ogra: yes
<ogra> kyrofa, but it looks like we are lacking an interface to even use them on core
<ogra> jdstrand, my prob with adding more snaps to the image is that snapd takes 3-5 min per snap on first boot btw ... i'm already at a 20min first boot with this image
<ogra> but i guess i'll ave to bit that bullet for now
<ogra> *bite
<zyga> roadmr: got them
<zyga> The store was unable to accept this snap.
<zyga>   - __all__: The upload does not appear to be a valid package.
<roadmr> \o/
<zyga> that's all I got
<roadmr> yeay
<zyga> the package can be installed locally obviously
<zyga> note: I did the upload as root
<zyga> as a user snapcraft crashes
<zyga> kyrofa: ^ wanna see?
<roadmr> zyga: hm, can you either run the review tools on the package locally to see what they say, or shoot me a copy of the built snap?
<zyga> roadmr: could I just send you the snap please?
<roadmr> zyga: sure thing
<kyrofa> zyga, I'm missing context, what are you doing?
<zyga> kyrofa: I'm using snapcraft push *.snap
<zyga> and it crashes with ...
<zyga> https://www.irccloud.com/pastebin/164aZPmQ/
<ogra> kyrofa, i forwarded the question to tony now ...
<ogra> kyrofa, did you see my issue with the architectures build-on/run-on thing under cleanbuild above ?
<ogra> kyrofa, :
<ogra> <ogra> Snapping 'pi-kiosk' |                                                                                                                           
<ogra> <ogra> Snapped pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap
<ogra> <ogra> Stopping local:snapcraft-sadly-choice-amoeba
<ogra> <ogra> Retrieved "pi-kiosk_18-0.1_OrderedDict([('build-on', 'amd64'), ('run-on', 'armhf')]).snap"
<ogra> it somehow includes python code snippets in the final snap name
<roadmr> zyga: hm we may need jdstrand's help on this
<zyga> oh/
<zyga> roadmr: what's the error from the review tools?
<roadmr> zyga: https://pastebin.canonical.com/p/8Sj2fXx5M4/
<zyga> hmm, wasn't this the same error as before?
<roadmr> zyga: I think that python traceback from the failure to rm is causing the store to barf (because it expects the tools output to be json - even if I say --json it has that Python thing at the end)
<zyga> those as not writable by owner
<roadmr> zyga: yes, I fixed that store-side, but IIRC your earlier snap didn't show this output from the tools
<zyga> ahh
<zyga> I See
<roadmr> if the tools can't clean up and barf like this, I can't fix that store-side directly :/
<jdstrand> zyga: where is this snap?
<zyga> jdstrand: sent via wormhole to roadmr
<roadmr> jdstrand: the top-level dir ias this mode drwx------
<zyga> it's just a fedora base I was sending before
<jdstrand> I'd need the snap if I'm going to look at fixing the review tools
<zyga> jdstrand: I can wormhole it to you as well if you don't mind
<jdstrand> that's fine
<roadmr> it's not huge, only 18 MB
<zyga> sent
<jdstrand> ok, I'll take a look at it
<roadmr> jdstrand: I suspect the fix will be similar to what I did store-side https://bazaar.launchpad.net/~ubuntuone-pqm-team/software-center-agent/trunk/revision/5055
<jdstrand> zyga: while I have you. can I get your opinion on something
<jdstrand> roadmr: ack, thanks
<jdstrand> zyga: so, I need to add 'unsafe' to the default template
<zyga> sure, I'm all ears
<jdstrand> zyga: but it fails spread cause apparently opensuse 42.3 has a too old apparmor_parser
<kyrofa> ogra, yuck, that's interesting
<zyga> right, I remember that branch
<jdstrand> zyga: that doesn't know what 'unsafe' is
<roadmr> actually - the review tools' recursive_rm appears to be identical to what we have in the store, so pretty sure my fix will apply :D
<jdstrand> zyga: so, I think the most correct solution is to use apparmor_parser from the core snap. however, I don't want to do that in this PR because whenever we move to this sort of scenario, it has a long tail of little fixes
<jdstrand> zyga: we can do that in a future pr
<zyga> would a parser from core produce binary compatible with the host kernel?
<jdstrand> zyga: sure, why not?
<jdstrand> the parser is fully aware of the kernel
<zyga> that's good
<jdstrand> using the parser in core would mean we could update apparmor in Ubuntu only to fix parser bugs, enhancements, etc, etc
<jdstrand> kinda like how we pulled back xenial's apparmor to trusty
<jdstrand> we could do that 'forever'
<zyga> ok
<jdstrand> and not worry about other distro's apparmor
<jdstrand> anyhoo
<zyga> so that's the preferred solution
<jdstrand> that is the ideal
<zyga> and in the meantime?
<jdstrand> but, again, I don't want to do that, so we have some choices
<jdstrand> I explored the idea of having a parser features list and populating it, just like we do with the features dir
<zyga> oh, that's interesting
<jdstrand> it works, but there are a number of test case mockings which got me wondering if there is another way
<jdstrand> (especially since if we go the apparmor_parser from core route, we just rip out this code)
<zyga> btw, what is the unsafe vs safe transition about?
<jdstrand> secure_exec
<jdstrand> ie, stripping LD_LIBRARY_PATH
<jdstrand> it is explained in the pr
<jdstrand> so the other option is, if we are PartialAppArmor already, we know we don't have a new enough parser, so don't use unsafe if PartialAppArmor
<zyga> ah
<zyga> ok
<jdstrand> this is cheap, but mildly inaccurate, but since the code is going to be ripped out soon, who cares?
<zyga> that would partially regress arch and opensuse tumbleweed though
<jdstrand> so... do you care?
<jdstrand> :)
<zyga> ha
<zyga> so that's the question
<zyga> I think that's fine if you are really going to do the full deal
<zyga> as in schedule wise
<zyga> I'm sure you would
<jdstrand> zyga: that's the thing, arch and tumbleweed should have a new enough apparmor_parser, so I can special case them or do something with downgradeConfinement, etc so they get unsafe
<zyga> in that case I think we're good
<jdstrand> or not, and just say that they don't get unsafe until we use the parser from core
<jdstrand> well, as it happens, I have a new manager now and slowly coming out from the last couple months
<jdstrand> I can add moving apparmor_parser from core to the roadmap
<jdstrand> err
<jdstrand> moving to apparmor_parser from core to the roadmap
<zyga> +1
<zyga> we should do the same for snap-seccomp
<jdstrand> I mean, this has a ton of benefits way beyond this
<zyga> for statx and the lkike
<zyga> *like
<jdstrand> yeah
<zyga> we should also answer the question of reexec=0 distros
<jdstrand> sure, but to me, we would always use the apparmor from core, regardless of reexec
<jdstrand> or do you see a problem with that?
<zyga> technically no
<zyga> but policy wise it could be borderline iffy
<jdstrand> who's policy?
<jdstrand> fedora shouldn't care-- they don't have apparmor
<zyga> but they have seccomp
<zyga> I imagine this is the same deal
<zyga> but anyway, we don't have to discuss this now,  I think technically we are in agreement
<zyga> and we can keep the code that uses distribution tools
<jdstrand> zyga: well, if we are planning on keeping the code, probably need parserFeatures
<jdstrand> we don't necessarily need to downgrade to PartialConfinement though
<jdstrand> that's a 3rd option. I check to see if the parser supports a syntax we know older ones don't have, and then populate something in snapd (other than PartialAppArmor) that we can query when using that one rule
<jdstrand> sorta sounds like based on this conversation that is possibly the best path forward
<zyga> jdstrand: we can probably use system key for that
<zyga> or a combination of system key and locally held state in AppArmor backend
<jdstrand> right, I was initially thinking of that
<jdstrand> ok, I'll just go that route for now
<zyga> ok
<jdstrand> zyga: thanks
<zyga> my pleasure :)
<ogra> jdstrand, fyi, works very nicely with the udidks2 snap, thanks for the hint (if only the firstboot wouldnt be 5min longer now)
<jdstrand> ogra: nice! :)
<jdstrand> ogra: I wonder why it takes so long... that seems like a bug?
<ogra> jdstrand, yeah, its a known go bug with checksumming sha256 stuff on arm ... snapd uses that when installing a snap for the first time ... so each snap delays the firstboot
<ogra> jdstrand, ijohnson has sent a fix upstream some months ago but that has still not been included
<ogra> (go upstream)
<ogra> picking sha256 for snaps was a bit overzealous ;)
<ijohnson> it's actually sha3 hashing
<ogra> ah, i thought it was 256
<ogra> some sha :P
<ijohnson> well it's sha3 with length 256
<ogra> sha-la-la :)
<zyga> ha
<zyga> I was _just_ typing that
<ijohnson> (although I thought that snapd used 384, but my fix fixes all sha3)
<ogra> (sorry, hard day ... tired and silly)
<ogra> zyga, welcome to my level of sillyness then :)
<zyga> ogra: I'm always silly
<zyga> I feel quite at home
<ogra> heh
<ogra> mvo, i saw yu landed the password expiry stuff ... any chance that goes into some non-edge channel before the weekend ?
<ogra> (likely not, but i thought i'd ask at least)
<mvo> ogra: there is a good chance actually - to hit beta, once the current beta moves to candidate I will do a new 2.36~pre2
<mvo> ogra: and that will move to beta
<ogra> beta sounds perfect ...
<mvo> sil2100: the various races for the pi firstboot (and dragon) are hopefully all under control now, I guess we just need to dig into the probert issue (and someone needs to test on a dragonboard)
<mvo> sil2100: I will push new test images later tonight or early tomorrow but nothing special about them, just current edge (and soon beta) for core18 and friends
<mvo> sil2100: (mostly just fyi)
<zyga> jdstrand: I subscribed you to https://bugs.launchpad.net/snappy/+bug/1796362
<zyga> please check my last comment there
<mup> Bug #1796362: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:Incomplete> <https://launchpad.net/bugs/1796362>
<zyga> mvo: is dragonboard fixed now? I can test it if you need that
<jdstrand> roadmr: can you pull r1132. it has the fix for zyga's snap
<zyga> mvo: do you want to do a simple boring review with a function rename
<zyga> jdstrand: oh, that was quick, thank you!
<mvo> zyga: dragonboard - I'm not sure its fixed, let me build a new test image. I fixed some firstboot races
<zyga> k
<mup> PR snapd#5955 opened:  cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<sil2100> mvo: thanks! I'm usually just building images myself to always have the latest core, but I know there are others that were doing some tests on the pre-built ones
<sil2100> mvo: I saw a lot of good fixes getting merged today, thanks for those!
<sil2100> mvo: we're still working on some bits and pieces to enable dailies, but now with the official assertions we can push things a bit more forward
<mvo> sil2100: great, thank you. building them yourself is fine of course :)
<mvo> zyga: dragonboard is up at http://people.canonical.com/~mvo/core18/
<mvo> zyga: but no rush
<mvo> zyga: also I'm not sure things will be better than at the sprint, but you never know :)
<mvo> sil2100: fixes> yeah, nothing beats testing on real HW there were some races
<mup> PR snapcraft#2331 opened: meson plugin: add support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2331>
<jdstrand> zyga: hey, can you add this to your list: https://github.com/snapcore/snapd/pull/5739 (waiting for spread tests to finish)
<mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739>
<mup> PR snapcraft#2332 opened: waf plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2332>
<mup> PR snapcraft#2328 closed: godeps plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2328>
<thresh> popey, pingie "download button" art
<roadmr> jdstrand: hi! sure will do
<mup> PR snapcraft#2330 closed: pluginhandler: remove big solidus workaround <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2330>
<popey> thresh: i pinged design about that yesterday, and was told it's in the lawyers queue for licensing.
<popey> thresh: thanks for the ping :)
<mup> PR snapcraft#2333 opened: catkin, catkin-tools: add support for bases <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2333>
<mup> PR snapcraft#2248 closed: plugin: update catkin plugin to support melodic <do-not-merge-yet> <Created by NickZ> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2248>
<mup> PR snapd#5861 closed: cmd/libsnap: add functions for handling facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5861>
<mup> PR snapd#5859 closed: many: introduce facts, export experimental features as facts <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/5859>
#snappy 2018-10-10
<zyga> o/
<pstolowski> mornings
<pstolowski> pedronis: hey, thanks for the review! i've updated #5952
<mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
<pstolowski> niemeyer: woah, thanks for the reviews on hotplug stuff!
<alexlarsson> zyga: HAH! flatpak got a haters site before snap! i won! :)
<zyga> alexlarsson: (insert meddling kids comment)
<zyga> alexlarsson: I firmly believe we are both building the better future for app developers
<alexlarsson> No no no
<alexlarsson> We're evil masterminds!
<zyga> alexlarsson: I woundn't mind that website much if the person was not anonymous
<alexlarsson> Man, you're not following the PLAN!
<zyga> ah, where is my script :)
<zyga> "what are we going to do tonight brain"
<alexlarsson> I think my problem with it is that *all* the things in there all apply to .deb/.rpm too (other than potentially flathub having less resources for CVE fixing than some distros)
<alexlarsson> So, what do they recommend?
<zyga> still one thing I would agree on, the sandboxing tech available in linux is still spotty, there are compromises for early usability
<zyga> I think those are fine as long as we are 100% honest about it
<alexlarsson> Well, *allowing* a sandbox is better than not allowing it. And if we enforced it no apps would work and people would make hater sites for that.
<alexlarsson> can't win the internet
<zyga> alexlarsson: although I think flatpack could use some of the --classic prompts from snapd
<zyga> alexlarsson: to install an app that has wide-open access to one's system requires to be explicit about it
<alexlarsson> We do that in the CLI
<alexlarsson> but gnome-software doesn't atm
<zyga> mmm, I see
<alexlarsson> org.gnome.gedit/x86_64/stable        flathub a03b66681bce
<alexlarsson>   permissions: ipc, wayland, x11
<alexlarsson>   file access: host, xdg-run/dconf, ~/.config/dconf:ro
<alexlarsson>   dbus access: ca.desrt.dconf, org.gtk.vfs.*
<alexlarsson> Is this ok [y/n]:
<alexlarsson> and we track it so you get deltas displayed on update
<zyga> alexlarsson: those are super technical and end with a yes-no question
<zyga> those are really asking "do you want this app or not"
<zyga> I think it could still use a lot of polish and change to the final prompt
<alexlarsson> Yeah, but its *hard* though
<alexlarsson> like
<Chipaca> alexlarsson: g-s doesn't? i thought we'd fixed that?
<alexlarsson> many of those are instant sandbox escape
<alexlarsson> x11 => escape
<zyga> I think we should phrase it around "do you want to give this application access to your system"
<alexlarsson> write to home => escape
<alexlarsson> write to dconf => escape
<zyga> not around technojargon that even system developers may not fully grasp (the consequences of granting)
<zyga> dconf? because auto-start unconfined this way?
<alexlarsson> (i'm sure there is a list of things that is spawned stored somewhere in dconf)
<zyga> right
 * zyga wonders what we do about dconf
<alexlarsson> We want to do a portal for it
<alexlarsson> but it hasn't happened yet
<alexlarsson> TingPing is looking at it soon
<alexlarsson> org.freedesktop.ibus.engine.anthy.common add-word-command ['/usr/bin/kasumi', 'kasumi', '-a']
<alexlarsson> dconf exploit
<alexlarsson> org.gnome.desktop.default-applications.office.calendar exec 'evolution -c calendar'
<alexlarsson> another one
<alexlarsson> Basically, i think its to risky to try to describe it in non technical words and give people the feeling that they only gave "secure" access
<alexlarsson> The only thing i think is possible is to mark what we consider a good sandbox with some "sandbox" tag
<alexlarsson> and then the rest is, "do you trust these guys, oh and here is some techincal gobbeligok"
<zyga> hmm, I think I recall we did apparmor for dconf somehow
<zyga> but perhaps that didn't materialise in the end
<zyga> one that would see the get/set arguments (normal apparmor dbus doesn't)
<zyga> I agree on the trust aspect
<zyga> it's either strong tech or it is trust
<niemeyer> pstolowski: np
<niemeyer> Mornings
<zyga> hey hey
<Chipaca> there is no runuser in 14.04 /o\
 * Chipaca thinks SRU thoughts
<diddledan> Chipaca: careful, that kinda thinking leads to dangerous places
<Chipaca> IKR
<diddledan> next thing you'll be doing a version bump
<zyga> Chipaca: please update centos kernel too ;)
<diddledan> yes. and replace yum with apt-get
<Chipaca> zyga: I'll file an SRU for that
<Chipaca> zyga: OH WAIT
<diddledan> that'ld be an epic project - a seamless upgrade from centos to debian or ubuntu :-p
<diddledan> i.e. one that doesn't require a separate boot disk
<Chipaca> reminds me of a conversation we had way back in the CÃ³rdoba LUG
<zyga> diddledan: curl flash.io/whatever  | sudo dd of=/dev/sda
<zyga> ;-)
<Chipaca> right about when macro virii became "popular", and we were building linux distros of the size of these things
<Chipaca> anyhoo
<diddledan> speaking of virii /me downloads backorifice and sub7
<diddledan> I'm hip now
<Chipaca> I guess what I need to do is make maybeRunuserCommand check the release and use sudo if runuser isn't available
<Chipaca> â¦ or maybe run sudo always?
<Chipaca> grmbl grmbl grmbl
<diddledan> I love maybe functions - maybeSaveDataThatCannotBeLost
<diddledan> and then you get really functions - reallySaveTheData
<zyga> niemeyer: is this for real? https://twitter.com/Zondi_Elihle/status/1049557185502609409
<Chipaca> diddledan: names are hard; suggestions always welcome
<Chipaca> i'd have a tattoo, if i did tattoos
<mborzecki> morning
<pstolowski> hey mborzecki o/
<zyga> hey guys
<mup> PR snapd#5953 closed: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5953>
<zyga> thank you again mvo
<mvo> zyga: for what?
<zyga> for that PR
<mvo> zyga: I mean, appreciated :)
<mvo> zyga: oh, yeah
<mvo> zyga: it was slightly tricky to find but simple in the end
<niemeyer> zyga: That's so over the top that it's hard to believe indeed.. let me check
<pstolowski> mborzecki: do you have a moment for https://github.com/snapcore/snapd/pull/5952 ?
<mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
<dot-tobias> zyga & niemeyer: re tweet â https://twitter.com/_majubs/status/1049794758162432002
<mborzecki> pstolowski: will do
<zyga> ah
<mvo> pstolowski: I just did that one
<niemeyer> dot-tobias, zyga: There are many non-joke programs in Multi Show, and it's a channel from Globo which tends to be trustable..
<pstolowski> mvo: ah, thanks!
<pstolowski> mborzecki: no need then, thanks!
<dot-tobias> niemeyer ,zyga: Maybe the security cam footage is real and they added a satirical âinterviewâ â his answers are just so full with double-entendre and humor ð
<niemeyer> dot-tobias, zyga: Yeah, it's a joke.. JS, "Satirical Journal"
<Chipaca> zyga: hey
<Chipaca> zyga: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<Chipaca> zyga: what did that mean?
<zyga> it mean that snap-confine was not confined but should be
 * Chipaca looks for his trout
<zyga> it runs on a kernel with apparmor support that is enabled
<zyga> but it has no profile of itself
<Chipaca> zyga: this is inside a 14.04 spread thing
<zyga> so it chooses to stop operating
<zyga> it means that apparmor service did not load apparmor profile for snap-confine
<zyga> is this in a live CD?
<Chipaca> zyga: no, spread, using the qemu backend, on 14.04
<zyga> uname -a?
<Chipaca> Linux autopkgtest 4.4.0-135-generic #161~14.04.1-Ubuntu SMP Tue Aug 28 11:17:49 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<zyga> hmmm
<zyga> magic
<mup> PR #161: Fix unclean tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/161>
<zyga> what is the status of apparmor.service?
<Chipaca> mup: go home, you're drunk
<mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<Chipaca> zyga:    Loaded: error (Reason: No such file or directory)
<zyga> oh, there you go
<Chipaca> zyga: um
<Chipaca> zyga: wait, this is 14.04
<zyga> so?
<Chipaca> zyga: no systemd
<zyga> on 14.04 it should still be there
<mborzecki> heh https://github.com/snapcore/snapd/pull/5951 travis status on github is still pending, but the travis job has successfuly finished 13h ago
<zyga> aaaah
<zyga> oh boy
<Chipaca> i mean, systemd isn't in charge
 * zyga thinks
<mup> PR #5951: spread-shellcheck: fix interleaved error messages, tweaks <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
<zyga> so, ...
<zyga> er
<zyga> I forgot the upstart equivalent
<Chipaca> mborzecki: hi! do you remember why I switched snapshots to use runuser instead of sudo?
<zyga> Chipaca: can you please look at /sys/kernel/security/apparmor
<zyga> and cat the policy file
<mborzecki> Chipaca: nope, was sudo an option?
<zyga> er
<zyga> sorry
<Chipaca> zyga: 1 sec
<Chipaca> zyga: when do we print that message, in particular?
<zyga> cat /sys/kernel/security/apparmor/profiles
<zyga> not policy, profiles
<zyga> Chipaca: when snap-confine starts up and noticed this
<Chipaca> zyga: so
<Chipaca> zyga:  test-snapd-tools.echo hello
<Chipaca> zyga: works
<Chipaca> # su -l -c 'test-snapd-tools.echo hello' test
<Chipaca> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<diddledan> who has access to the forum? should this post be reinstated? it appears to have been flagged for some reason: https://forum.snapcraft.io/t/call-for-testing-savage-xr-battle-for-newerth-game/7754
<zyga> yes
<zyga> Chipaca: because then it's not privilege ecalation
<zyga> you were root
<Chipaca> diddledan: too many  links on a newcomer topic
<Chipaca> diddledan: unhidden
<diddledan> aha
<diddledan> thanks
<mborzecki> Chipaca: i think we moved from a helper to a goroutine with set*uid and then to runuser
<Chipaca> zyga: I don't understand
<Chipaca> mborzecki: i did try sudo first
<Chipaca> mborzecki: in fact the variable in which I build the command is still called sudoArgs :)
<zyga> Chipaca: when you are the user test
<zyga> snap-confine gives you root
<zyga> so it looks for confinement
<mborzecki> Chipaca: hah :) so something must have been off about it then
<zyga> when you were root, we just carry on
<zyga> it is the logic we picked a while ago
<Chipaca> mborzecki: exactly, and I remember you suggesting runuser instead, but I don't remember why
<Chipaca> mborzecki: so, I'm going to just plug sudo back in there and see what breaks :-D
<mborzecki> Chipaca: sec, let me check the logs
<mvo> niemeyer: when you have a moment, could you please check if the name in the system-user assertion to force a password change (pr 5949) is ok. right now it is using "force-password-change: {true,false}"
<mup> PR #5949: osutil,asserts,daemon: support force password change in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5949>
<Chipaca> zyga: so how do I work around this?
<niemeyer> mvo: That sounds great already
<zyga> Chipaca: well, figure out why the profile was not loaded
<zyga> it should have
<zyga> fist of all, please check if the profile is really absent
<Chipaca> zyga: how do i check that?
<mborzecki> Chipaca: https://paste.ubuntu.com/p/jNc3bTXKDR/
<mborzecki> i should trim the log file
<zyga> Chipaca: please look at /sys/kernel/security/apparmor/profiles
<Chipaca> zyga: snap.test-snapd-tools.echo (enforce)   (and a bunch more)
<zyga> do you see one for snap-confine itself?
<zyga> this is about snap-confine profile, not app-specific profile
<Chipaca> # grep snap-confine /sys/kernel/security/apparmor/profiles
<zyga> snap-confine effectively kills itself by choice
<Chipaca> zyga: yes, two results, which irc won't show as pasted because they start with / :)
<zyga> haha
<Chipaca> # grep snap-confine /sys/kernel/security/apparmor/profiles
<Chipaca> /usr/lib/snapd/snap-confine (enforce)
<zyga> yes, thank you IRC
<Chipaca> /usr/lib/snapd/snap-confine//mount-namespace-capture-helper (enforce)
<zyga> so that's the main profile
<zyga> what we are missing is the reexec profile
<zyga> this very much feels like the bug mvo just fixed
 * Chipaca hugs mvo
<zyga> is /var/lib/snapd/apparmor/snap-confine present?
<Chipaca> zyga: no
<zyga> an /var/lib/snapd/apparmor?
<zyga> mkdir it please and restart snapd
<Chipaca> wait
<Chipaca> yes
<Chipaca> yes, it's there, just empty
<Chipaca> (i misread ls's output /o\)
<zyga> ok, restart snapd and let's see
<Chipaca> how do i restart snapd on 14.04
<Chipaca> man
<zyga> ha
<zyga> sudo service restart
<zyga> AFAIR
<zyga> but I may not remember much
<Chipaca> it looks like snapd is running under systemd
<zyga> oh right
<zyga> well
<Chipaca> there
<Chipaca> restarted
<zyga> any new profiles?
<Chipaca> JamieBennett: are snaps part of the 14.04 ESM offer?
<Chipaca> zyga: not that i can see
<JamieBennett> Chipaca: not that I know of
<JamieBennett> Chipaca: why?
<Chipaca> JamieBennett: because I'd be happier if we could stop worrying about 14.04 soon :)
<JamieBennett> :)
<Chipaca> zyga: so now what
<zyga> Chipaca: I assume you have the core snap installed
<Chipaca> zyga: i do
<zyga> Chipaca: upon restart of snapd I would expect to see the reexec profile in the places you looked
<zyga> ah
<zyga> wait
<zyga> I'm silly
<zyga> the reexec profile is in /etc/apparmor.d
<zyga> is there one in /etc/apparmor.d/snap.core.$NUMBER.usr.lib.snapd.snap-confine
<Chipaca> zyga: no
<zyga> any logs from snapd?
<Chipaca> zyga: plenty
<Chipaca> this is in spread, so all debug knobs are on
<zyga> oh man
<Chipaca> "all" <- most
<zyga> can you please pastetem?
<Chipaca> zyga: as of the last restart?
<mborzecki> pedronis: splitting validation from snap is quite a puzzle
<zyga> yeah, though no need to limit them just paste what you have
<mborzecki> Chipaca: so sudo vs runuser was just about package dependencies?
<Chipaca> mborzecki: looks like it, but i'll need to test
<Chipaca> mborzecki: thank you for those logs :)
<Chipaca> zyga: https://pastebin.ubuntu.com/p/Mc8jwBqMXk/
<Chipaca> zyga: slightly truncated horizontally; let me know if you need the full width
<zyga> hmmm, nothing out of the ordinary
<zyga> I don't know, why is the profile not there ?
<zyga> hmm
<zyga> actually
<zyga> perhaps when we installed the core snap and the directory was missing
<zyga> can you refresh core
<zyga> to anything
<Chipaca> sure 1 sec
<zyga> that ought to trigger the right thing
<Chipaca> refreshing to beta
<Chipaca> (was on edge)
<Chipaca> hmm, it hangs
<Chipaca> hmm
<Chipaca> oh no it worked
<Chipaca> just no progress bar
<Chipaca> wat
<Chipaca> anyway, one wat at a time
<zyga> no progrÃ¨s bar?
<Chipaca> zyga: # ls /etc/apparmor.d/
<Chipaca> abstractions  cache  disable  force-complain  local  sbin.dhclient  snap  tunables  usr.lib.snapd.snap-confine	usr.sbin.cups-browsed  usr.sbin.cupsd  usr.sbin.rsyslogd  usr.sbin.tcpdump
<niemeyer> mvo: LGTM.. couple of trivial optional suggestions only
<zyga> hola accents
<zyga> Chipaca: hmmm no idea, something is bad
<mvo> niemeyer: thank you!
<Chipaca> zyga: :-/
<niemeyer> mvo: np and thanks!
<Chipaca> zyga: should I throw it away and hope it doesn't happen a second time?
<zyga> mmm, mmm ...
<zyga> mmm
<zyga> I'm having conflicts in my head
<Chipaca> zyga: just push --force
<Chipaca> mborzecki: getting back to runuser-vs-sudo, I'll just add a check and if runuser isn't there, try to use sudo instead
<Chipaca> zyga: i'm going to take a break, and go do some physio; if there's anything I should do with this trusty vm let me know otherwise i'll be killing it when i get back
<zyga> Chipaca: ack
<pedronis> mborzecki: ah,  as I said, just an idea, might be too much of a pain to do quickly now
<pedronis> it might be easier to have a copy of the regexp for now
<mborzecki> pedronis: interesting idea nonetheless, but i think it's more of a followup material
<mborzecki> pedronis: i've added snap/name package and moved some validation code there
<mborzecki> pedronis: could be beneficial in the long run
<mup> PR snapd#5951 closed: spread-shellcheck: fix interleaved error messages, tweaks <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5951>
<sil2100> ogra: hey! Should I kick new pi3 stable images now?
<mvo> sil2100: how are things looking on the pi3b+? anything I can/should test?
<mvo> Chipaca: I'm inclined to merge 5944 and just see what will happen in adt
<mvo> Chipaca: the only open question was slow machines here
<mvo> Chipaca: and we will get tests on the pi
<mup> PR snapd#5940 closed: store: speedup unit tests <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5940>
<mup> PR snapd#5917 closed: cmd/snap: attempt to start the document portal if running with a sessâ¦ <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5917>
<pstolowski> pedronis: hey, can you re-review #5952 when you have a moment?
<mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
<ogra> sil2100, yeah ... saw your mail, note that pi2 and dragonboard need updating too
<ogra> mvo, at least core 16 edge seems to be fine on pi3 b+ here
<ogra> (and after the rebuild also stable)
<mup> PR snapcraft#2327 closed: pluginhandler: remove prepare, build and install scriptlets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2327>
<mvo> ogra: interessting, I had trouble with uc18, I will dig into it
<ogra> mvo, what kind of trouble ?
<ogra> booting should generally work
<mvo> ogra: yeah booting is fine, I had no network
<ogra> (not sure about preipherials with the 4.15 kernel, havent tested with it, but 4.4 is definitely fine, i'm just using it here on a b+)
<mvo> ogra: ok, cool
<mup> PR snapcraft#2332 closed: waf plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2332>
<mvo> ppisati: hey, with uc18 and kernel 4.15 from the snap I have no networking on my pi3 b+. do you have any suggestions for me how to debug this? does 4.15 work on classic ubuntu with the 3b+?
<ogra> mvo, you said /proc/net/dev shows them ... sounds less like a kernel issue then
<mup> PR snapcraft#2333 closed: catkin, catkin-tools: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2333>
<mup> PR snapd#5871 closed: snapstate: only report errors if there is an actual error  <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5871>
<mvo> ogra: yeah, they are visible but not connected, neither wifi nor wired
<ogra> right, but the modules seem to load and init the HW ...
<ogra> which makes it sound suspiciously like userspace
<mvo> ogra: maybe, the same image works on the pi3 (without b+) as a dateapoint
<ogra> well, they have the same wifi AFAIK ... but the b+ has a different ethernet NIC
<mborzecki> pedronis: i've pushed a fix with copied snap name validation, but if you'd like to entertain the idea of a separate package, I did a quick implementation here: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/validate-name-separate-package
<ogra> so at leat wifi should work the same as in the normal pi3
<mvo> mborzecki: fwiw (without having looked at the package you just linked to) I like the idea of a snap/validate package
<mborzecki> pedronis: i actually sort of like it, probably needs some tweaking still, but could be interesting
<mborzecki> mvo: snap/validate may be harder because some validation code touches Info and inside structs directly, so Info would have to be defined elsewhere too
<mborzecki> mvo: that PoC is a snap/name with name validation code pulled out, so that you could import it safely in assserts
<mvo> mborzecki: aha, I see
<mborzecki> mvo:  in that sense it's mostly the validation functions which are pure and take plain arguments
 * mvo nods
<ppisati> mvo: yes, it works
<ppisati> mvo: let me dig out my board and test it
<mvo> ppisati: ok, thank you. I guess I need to compare dtb versions and all that to see whats going on?
<mvo> ppisati: pardon my ignorance, can I just download an armhf bionic image to test this? or will I need to grab a special ubuntu image somewhere?
<mvo> actually maybe my pi3 b+ is just broken, I need to test for this as well
<ppisati> mvo: afaik foundation never produced a rpi3(b+) image, so you probably need to roll your own
<ppisati> mvo: from time to time i build some classic images just for debugging, let me find one that works
<mvo> ta
<ogra> mvo, just use a core 16 edge to verify the HW
<mborzecki> Chipaca: can you do a quick pass over https://github.com/snapcore/snapd/pull/5946 again?
<mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
<cachio> mvo,hello
<cachio> mvo, about sru validation
<mvo> ogra: sounds sensible
<mvo> cachio: hey
<cachio> mvo, I have seen some errors which could be related to the snapd.socket which I mentioned yesterday
<cachio> https://paste.ubuntu.com/p/2Nyq9GtppF/
<mvo> cachio: thanks! hm, hm, the error looks a bit mysterious, any feedback from the checkbox/plainbox people about this?
<cachio> mvo, I can't reproduce the same error which I see in the logs but if I could reproduce another related to the snapd.socket
<cachio> if you restart the snapd.socket in a look it fails after several tries
<cachio> mvo, similar error to the once which is in this log
<cachio> https://api.travis-ci.org/v3/job/438978598/log.txt
<mvo> cachio: thanks, checking
<cachio> mvo, for i in $(seq 100); do sudo systemctl restart snapd.socket; done
<cachio> this fails
<cachio> if you restart the socket with some sleep time it works well
 * pstolowski lunches
<mvo> cachio: interessting - do you see anything in the journalctl log when this happens?
<mvo> cachio: anything that indicates *why* it fails?
<cachio> mvo, no
<cachio> mvo, nothing in the logs
<cachio> oct 10 08:23:32 cachiomachineold snapd[14837]: main.go:121: Exiting on terminated signal.
<cachio> mvo, this https://paste.ubuntu.com/p/sGzrBMt2CK/
<Chipaca> mvo: yay, thank you for merging 5944
<Chipaca> mborzecki: looking at 5946
<Chipaca> mborzecki: grah. Still not happy with the wording, and yet I don't like blocking on this
<Chipaca> mborzecki: I'll have a bite to eat and think about this a bit
<cachio> mvo, this is the log what I have
<cachio> https://paste.ubuntu.com/p/sfpTMSjqTC/
<cachio> mvo, systemd could be stopping the restart
<cachio> not sure if the error on the tests are related to the same
<mup> PR snapd#5956 opened: image: fetch device store assertion if available <Created by pedronis> <https://github.com/snapcore/snapd/pull/5956>
<pedronis> mvo: ^
<ogra> did #5746 land in any releae yet ?
<mup> PR #5746: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746>
<ogra> (i dont see any version tag on the PR)
<jdstrand> zyga: fyi, re dconf-- there was the idea, design and an implementation that was never agreed to for dconf mediation
<mborzeck1> hm a bunch of tests returns early when there's partial confinement, wonder if instead of just looking at partial we could look at specific features reported by snap debug sandbox-features
<Chipaca> zyga: so, on 14.04, refreshing core to beta _and then back to edge_ makes the error go away
<zyga> oh
<zyga> with the profile in place?
<zyga> I think it was the missing dir
<Chipaca> zyga: i see no file in /etc/apparmor.d/ with a revision in it
<Chipaca> zyga: so what does refreshing back and fro do, that restarting snapd doesn't?
<zyga> installing core snap is speciall
<zyga> we do per-core-rev snap-confine profile generation then
<zyga> can you peek at the list of profiles in sysfs/
<Chipaca> remind me where that was plz?
<Chipaca> ah found it
<Chipaca> yes
<Chipaca> /snap/core/5694/usr/lib/snapd/snap-confine (enforce) etc
<zyga> so that's that
<Chipaca> so what's the fix?
<Chipaca> do we need to generate those on startup?
<Chipaca> zyga: and, why does this only hit 14.04?
<zyga> I don't think it hits any specific release, it depends on packaging shipping a directory or not
<zyga> perhaps we are not
<Chipaca> zyga: which is the directory that should, or shouldn't, exist?
<zyga> one sec
<mup> PR snapcraft#2334 opened: schema: enfore string for versions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2334>
 * Chipaca goes to hang up some washing
<zyga> Chipaca: the one on 563b94dc8fd4ea10daef9e176301efc141c9c5b3
 * Chipaca looks
<zyga> that it is...
<zyga> dirs.SnapConfineAppArmorDir,
<zyga> and I think that is /var/lib/snapd/apparmor/snap-confine
 * zyga checks
<zyga> yes, that's the one
<Chipaca> ok, i'll cycle the spread and check that
<cachio> mborzecki, hi, to merge #5894 you need the apparmor image by default, right?
<mup> PR #5894: many: enable AppArmor on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5894>
<mborzecki> cachio: yes
<mborzecki> cachio: i've switched the image there
<cachio> ok, let me update the default image with apparmor enabled
<cachio> that should go by default
<mborzecki> cachio: hm i think it should be ok to update the default image, snapd will generated the profiles but s-c will not use them, so the spread suite should not be affected
<Chipaca> zyga: and does it have to exist, or does it have to not exist?
<zyga> I think it should not exist for a broken system symptom
<zyga> since mvo's patch creates it
<cachio> mborzecki, ok
<mvo> pedronis: thanks, looking at your PR now
<Chipaca> zyga: I can confirm that adding a mkdir -p /var/lib/snapd/apparmor/snap-confine early in prepare_project makes the bug go away
<zyga>  whee
<zyga> I wonder how/why we missed it this long
<Chipaca> zyga: because we don't have many tests that do su â¦ <something from a snap>
<mvo> if the fix is merged, why are we still seeing this?
<zyga> aaah
<zyga> good point
<Chipaca> mvo: which fix
<zyga> Chipaca: the patch ID I referenced
<Chipaca> ah
<Chipaca> I don't know :)
<mvo> Chipaca: https://github.com/snapcore/snapd/pull/5953
<mup> PR #5953: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5953>
<mvo> Chipaca: maybe its missing in antoher place as well
<Chipaca> mvo: for extra fun, with core tracking edge, snap refresh --beta core && snap refresh --edge core makes the bug go away
<mvo> Chipaca: fun!
<Chipaca> mvo: easy to reproduce: boot a 14.04, install snapd etc etc, and then try Â«su -l -c 'test-snapd-tools.echo ohi' testÂ»
<mvo> Chipaca: sorry, I missed parts of the backtrace, what is the exact error message oyu get?
<mvo> *you
<Chipaca> mvo:  snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<mvo> Chipaca: aha, ok - I think this is slightly different from my fix
<mvo> Chipaca: I think in your case setupSnapConfineReexec is not run at all
<mvo> Chipaca: again pardon my ignorance, how do I reproduce this?
<Chipaca> mvo: spread -shell qemu:ubuntu-14.04-64:tests/main/<choose one>
<Chipaca> mvo: and then, snap install test-snapd-tools
<pstolowski> niemeyer: i've addressed your comments to hotplug PRs; #5860 needs your re-review
<mup> PR #5860: interfaces/hotplug: helpers and struct updates <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
<Chipaca> mvo: and then, su -l -c 'test-snapd-tools.echo ohi' test
<pstolowski> niemeyer: and once it's ready it will unblock all the other PRs for landing
<mvo> Chipaca: ta
<Chipaca> mvo: 14.04 only, not 16.04, and mkdir -p /var/lib/snapd/apparmor/snap-confine in prepare_project makes it go away, as does going to beta and back
<Chipaca> mvo: that's all i know :)
<Chipaca> now i need to propose a pr that'll fall back to sudo if runuser isn't there, because 14.04
 * Chipaca stashes his spread fixes
<mvo> Chipaca: ok, running this now and having a look
<mvo> 5950 needs a second review
<mborzecki> Chipaca: https://paste.ubuntu.com/p/hVYnc6DBv2/
<mborzecki> Chipaca: snap services with your suggestion
<mup> PR snapd#5950 closed: tests: running the snapd tests on Ubuntu 18.10 <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5950>
<pstolowski> mborzecki: i was 4 seconds quicker... the typo goes in ;)
<mborzecki> haha :)
<Chipaca> mvo: i just failed to reproduce this though :-/ dunno
<mvo> Chipaca: ok
<mvo> Chipaca: my spread is still running
<Chipaca> mborzecki: looking
<Chipaca> mborzecki: what do _you_ think of it?
<Chipaca> I wish we had a single word that meant "see details", for one
<Chipaca> we're abusing the hyphen a bit :)
<mborzecki> inquire
<mvo> Chipaca: works for me (with latest master)
<mborzecki> what was the thesaurus thing niemeyer used?
<Chipaca> mvo: as in, you could reproduce it, or it failed?
<mvo> Chipaca: it does not fail
<Chipaca> mvo: grr
<mvo> Chipaca: and I also see the right snap-confine.core.5694 profile in /var/lib/snapd/apparmor/profiles
<mvo> Chipaca: was it reliable to reproduce before for you?
<Chipaca> mvo: 4 out of 4 times
<mvo>  /o\
<mvo> hm, hm, hm
<Chipaca> mvo: but maybe all i need to do is merge master?
<pedronis> Chipaca: hi, could you look at #5956 , it's small, it's a follow up to something you already reviewed
<mup> PR #5956: image: fetch device store assertion if available <Created by pedronis> <https://github.com/snapcore/snapd/pull/5956>
<mvo> Chipaca: worth a shoot
<Chipaca> pedronis: yep, on my list
<pedronis> thx
<Chipaca> mvo: let me see if i can repro just doing what i did before
<Chipaca> mvo: and then i'll merge master
<Chipaca> mvo: (what i did before should be what you just did now, but â¦ Â¯\_(ã)_/Â¯)
<mvo> ok
 * Chipaca ~> tea and standup
<niemeyer> mborzecki: Just add .com :)
<mborzecki> debian-9-64 prepare failing? https://paste.ubuntu.com/p/zGNDtwyKVB/
<mvo> sil2100: if I want to propose changes to console-conf for uc18, what git PR should I base it on?
<mvo> cachio: a link to a log with "	
<mvo> Sergio Cazzolato	3:23 PM
<mvo> snap list
<mvo> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: read unix @->/run/snapd.socket: read: connection reset by peer" would be great
<mvo> zyga: http://people.canonical.com/~mvo/core18/core18-dragonboard-18-beta20181009.img
<zyga> mvo: thnx
<zyga> 5 minutes to download
<mvo> zyga: ta
<ogra> mvo, btw, thanks for quietening the boot, it i noticeable ... (noticeable enough that i now notice that mount seem to print "ext4" twice on startup)
<ogra> *it is
<zyga> mvo: flashing now, the rest of the hardware is ready
<zyga> what do I need to test exactly?
<ogra> this 2min timeout because we hardocde eth0 in the config is still super annoying ... i wish we could leave that hardcoded bit out :(
<zyga> mvo: check your telegram
<zyga> feel free to push to niemeyer
<zyga> mvo: let me know if you need more testing
<zyga> niemeyer: bottom line, it doesn't work
<niemeyer> Ack
<niemeyer> We just need that captured somewhere in a way people can follow up
<zyga> I have a photo and a short clip. I can add that anywhere appropriate
<mborzecki> cachio: just to be clear, i should switch back to the default arch image now?
<zyga> mvo: where shall I add the test result?
<mvo> zyga: let me add a bug
<mvo> zyga: thanks, this is exactly the old bug
<zyga> thank you
<zyga> will my testimony on the bug report suffice?
<cachio> mborzecki, yes
<cachio> the default one has apparmor enabled now
<mborzecki> cachio: the problem with restarting snapd.socket reproduces in https://github.com/snapcore/snapd/pull/5948 i've pushed a commit to get more logs
<mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
 * cachio nice
<cachio> mborzecki, nice
<cachio> I'll take a look after lunch
 * cachio lunch
<mup> PR snapcraft#2331 closed: meson plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2331>
<mvo> mborzecki, cachio I also hit it in my PR and also in debian-9
<sil2100> mvo: hey! So we don't have any git repos for what's in the images, which is a big ugh, for now you can prepare a PR for the master branch of subiquity and we'll cherry pick it to the PPA
<sil2100> mvo: maybe it's a good idea for me to create a git repo for it
<sil2100> For tracking
<sil2100> console-conf/subiquity was always slightly hacked-in ;/
<sil2100> ogra, lool: I kicked a new stable series of images for 16
<ogra> sil2100, awessome !
<cwayne> sil2100: hm?
<sil2100> cwayne: I think we poked you about that on the sprint, we'll be asking you for some testing of the rpi3 images since we'd like to update those
<sil2100> cwayne: for pi3 b+ support
<sil2100> For now I kicked the images only
<cwayne> sil2100: righto, so those are ready to test?
<sil2100> cwayne: not yet! Just kicked the builds, wanted to send you a poke with the image links already
<sil2100> Those should be available soonish
<ogra> sil2100, we really want to update all arm/arm64 images, the pi2 as well as the db are also massively behind in stable
<ogra> but they are less urgent though
<sil2100> I guess we'll start with the pi3's for now, not sure we have enough capacity to take on all the others this week
<ogra> (pi2 is missing thermal and power-mgmt fixe in the binary firmware and misses interface declarations in snapcraft.yaml in stable)
<sil2100> Too much going on
<sil2100> ogra: are those changes in the pi2 edge gadget already?
<ogra> dragonboard has a ton of changes from ondra to support the internall MMC and such that we also want to ue in customer projects
<sil2100> Or should I kick a new build for those to be picked up?
<ogra> sil2100, yeah
<ogra> well, they are in the git tree since ages
<sil2100> Ok o/
<ogra> not sure if pi2 also hass not picked them up ...
<ogra> *has
<mborzecki> cachio: so now it's no reproducing anymore :/
<ogra> declare it fixed then ;)
 * zyga -> post office
<ogra> sil2100, given the state of the arm builders i guess you can forget about re-building the gadget anyway for today (i had no luck with a single build all day here, started to build my snaps locally)
<mborzecki> cachio: 3rd restart and still not reproduced
<ondra> @ogra without resize fix, new gadget will fail when booted from internal storage (unless you are quick to call resize after first boot)
<ogra> ondra, oh, ok
<ogra> sil2100, hold back on the dragonboard then
<kyrofa> Hey ondra, you around?
<ondra> kyrofa yep
<mvo> sil2100: ok, I would like to work on the experience of the console-conf-wrapper but lets catch up tomorrow whats the best way for me to do this and how we get into into the image
<ondra> ogra it works with sdcard, this only issue when booting from emmc
<mvo> sil2100: (in a meeting right now)
<ogra> ondra, hmm, which we havent much promoted anyway
<ondra> ogra yep
<kyrofa> ondra, can you share a snapcraft.yaml using layouts?
<ogra> graaaah !
<ogra> so just as i'm done doing my chromium snap build on my pi locally and finished the upload the build.s.io armhf builders come back to life !!!
<mborzecki> ogra: how long did that take? :) a day?
<ogra> well, it uses the binary deb ... just some snap stuff around it ... so only 1h
<mborzecki> oh, that's cheating :)
<ogra> hahaha
<ogra> yeah
<kyrofa> zyga, are the target paths or any part of the declaration of a layout validated?
<kyrofa> At the string level, I mean
<sergiusens> ogra: do you even have enough ram to successfully build that from source?
<ogra> there is always swap
<ogra> just delays the build by another half day i guess :)
<ogra> but i'm sure you *can* build it from source on a Pi if you wanted
<mup> PR snapd#5957 opened: overlord/snapshotstate/backend: fall back on sudo when no runuser <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
<mup> PR snapcraft#2335 opened: lifecycle: remove lxd support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2335>
<cachio> mborzecki, I was trying to reproduce it here, left some scripts running an hour and could't reproduce it
<mup> PR snapd#5958 opened: NOT-REVIEW: tests: Add debug info main suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5958>
<zyga> kyrofa: yes
<zyga> kyrofa: all of it is
<kyrofa> zyga, I see logic sanity checking what the mounts actually are, but I haven't found any regex
<zyga> kyrofa: it's not a simple regex.
<zyga> there are rules and more rules
<zyga> kyrofa: the up side is that snap validate checks that
<kyrofa> Yeah just wanted to see if there was a sanity check I could run up front, but it seems not
<mup> PR snapd#5959 opened: systemd: extend Status() to work for socket and timer units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5959>
<mborzecki> cachio: dropped the debug commit in #5948 since the problem stopped reproducing, i'm quite sure it'll reproduce now that i gave up ;)
<mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
<mup> PR snapd#5860 closed: interfaces/hotplug: helpers and struct updates <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5860>
<mup> PR snapd#5863 closed: overlord/ifacestate: add hotplug slots with implicit slots <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5863>
<mup> PR snapd#5880 closed: interfaces/repo: two helper methods for hotplug <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5880>
<mup> PR snapcraft#2336 opened: schema, meta: support layout <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2336>
<Chipaca> ooh, guess what, suse failing again
<mup> PR snapcraft#2335 closed: lifecycle: remove lxd support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2335>
 * cachio afk
<mup> PR snapcraft#2337 opened: pluginhandler: library detection instead of injection <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2337>
<smoser> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1797218
<mup> Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1797218>
<smoser> is that known ?
<mup> PR snapcraft#2336 closed: schema, meta: support layout <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2336>
<luk3yx> When I try and build my snap on Ubuntu 18.04 (it needs newer libraries), I get this error:
<luk3yx> The linker version '2.23' used by the base 'core' is incompatible with files in this snap
<luk3yx> Can I fix it without compiling with older 16.04 libraries?
<ijohnson> luk3yx: are you using `base: core18` in your snapcraft.yaml?
<luk3yx> No, do I need it?
<mup> PR snapcraft#2338 opened: schema, meta: support layout <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2338>
<ijohnson> if you are building a snap that targets using 18.04 libraries, then yes you need to add `base: core18` to your snapcraft.yaml
<luk3yx> If I add that, will build.snapcraft.io use 18.04 libraries?
<ijohnson> I believe that build.snapcraft.io was recently updated to work with core18 bases, so yes it should work
<luk3yx> Thanks.
<luk3yx> The build is erroring because of a missing package: CalledProcessError: Command '['lxc', 'exec', 'lp-xenial-ppc64el'...
<luk3yx> I think that means it's not using 18.04.
<ijohnson> Can you link to a more complete build log? I'm not sure that means it's not using 18.04
<mup> PR snapcraft#2339 opened: lifecycle: switch to multipass by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2339>
<ijohnson> Also are you intending to build your snap on ppc64el?
<luk3yx> No, build.snapcraft.io did it for me.
<luk3yx> Could not find a required package in 'build-packages': libluajit-5.1-dev
<luk3yx> When a local apt search displays it.
<ijohnson> Okay, so firstly you can specify what specific architectures you want to build your snap on using the `architectures` yaml spec
<ijohnson> See https://forum.snapcraft.io/t/architectures/4972
<ijohnson> Secondly, I think I mispoke earlier, build.snapcraft.io doesn't support using core18 as a base and you need to use launchpad for it, see https://forum.snapcraft.io/t/core18-base-in-build-snapcraft-io/7715
<luk3yx> Now build.snapcraft.io is being unresponsive with removing repos, it says 'IntegrityError'.
<luk3yx> Is there a tutorial for setting up a launchpad build?
<ijohnson> I don't know of any tutorials for setting up launchpad snap, but basically the process is make an Ubuntu SSO account if you haven't already, then configure your project to have an upstream remote at launchpad, i.e. for git add a new launchpad remote and push the code there. Then on launchpad.net there's a thing you can click to setup a snap package from that code you pushed
<ijohnson> Re: IntegrityError, I am not sure about that
<ijohnson> You might try asking in #launchpad about that
<luk3yx> Thanks, I think I've created it.
<luk3yx> It appears to have worked.
<kyrofa> zyga, do you know of anything that changed recently on debian? https://github.com/nextcloud/nextcloud-snap/issues/745
<mup> PR snapcraft#2340 opened: pack: restrict snap pack to just type app <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2340>
<mup> PR snapcraft#2338 closed: schema, meta: support layout <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2338>
<mup> PR snapcraft#2340 closed: pack: restrict snap pack to just type app <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2340>
<mup> PR snapcraft#2341 opened: schema, meta: support command-chain <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2341>
<sergiusens> kyrofa: did we ever merge that LD_LIBRARY_PATH you did to make trusty work?
<sergiusens> I think this is a good opportunity to bring it back
#snappy 2018-10-11
<sergiusens> kyrofa: you have on failing unit
<mborzecki> morning
<zyga> Good morning everyone:-)
<mvo> hey zyga
<mborzecki> zyga: mvo: hey
<mvo> good morning mborzecki
<zyga> kyrofa: looking
<zyga> kyrofa: at least on am64 116 is setgroups, perhaps that is a local config issue; nothing changed on Debian AFAIK
 * zyga resumes documenting snap-confine 
<mborzecki> wow, that debian 9 thing when snapd socket is restarted is annoying
<mborzecki> basically reproduces every time in 5948, but stops when i push the commit with extra debug information
<mvo> mborzecki: gar, anyoing indeed
<pstolowski> mornings
<zyga> hey pawel, mvo
<mup> PR snapd#5960 opened: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960>
<mborzecki> should be a simple one ^^
<mup> PR snapd#5894 closed: many: enable AppArmor on Arch <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5894>
<mborzecki> mvo: do you plan to merge master to 2.36 branch or should I prepare a backport of 5894?
<mvo> mborzecki: I plan to merge master once more
<mvo> mborzecki: I need to check the status of the tagged PRs
<mborzecki> mvo: i tagged 5960, hope you don't mind
<mvo> mborzecki: I don't - and if I do I just ignore it ;)
<zyga> dot-tobias: hello, I replied on the thread about the issue you found
<dot-tobias> hi zyga! Yes I saw that, was just about to reply that I found the issue. It actually was the install hook, will post details in the thread as soon as I cleaned up my snapcraft.yaml ð Thank you very much again!
<zyga> woot, that's great!
<zyga> mvo: can we enable layouts wit the 2.36?
<zyga> I think they are really ready now
<dot-tobias> zyga: (and sorry for suspecting snapcraft to be the culprit instead of my own incompetence ð )
<zyga> definitely not more buggy than other features :)
<zyga> dot-tobias: I'm happy you are using snaps and was interested enough to try out new features
<mvo> zyga: this one PR of yours needs a second review, right? then yes it can go in
<zyga> I can change the approach any way deemed necessary
<mvo> zyga: *nod*
<mvo> zyga: I personally would just remove the experimental.layouts entirely not support defaults
<zyga> sure, shall I just do that?
<mvo> zyga: but I understand there is a possible use-case
<zyga> but really it's the first thing that goes out of experimental stage
<mvo> zyga: I don't feel super strong about it but I think it would make it much quicker to review :)
<zyga> so I wanted to be more conservative
<mvo> zyga: good point
<zyga> we don't really have a well defined process yet
<mvo> zyga: maybe gustavo has a stronger opinion
<mvo> zyga: yeah, thats a good point
<mvo> niemeyer: layout is the first experimental feature that goes out of experimental. the question came up how we do this: a) switch the default of experimental.layouts to "true" (so that users can still disable it) or b) just remove the option entirely because we now consider it "ready" (cc zyga). what is your opinion on this?
<zyga> mvo: (with apologies) https://twitter.com/lolamby/status/1049949985406705666
<mvo> zyga: I don't get it?
<zyga> do you recall how I always type apt-get out of a habit and you always correct me with just "apt"?
<mvo> zyga: yeah, but I don't get why the twitter picture has the simley on apt-get and the disgusted face on apt
<zyga> do you know this meme?
<mvo> zyga: I mean, are there really people who dislike the progress bar?
<mvo> zyga: I don't, sorry
<zyga> well, apparently, it's not my tweet :)
<mvo> zyga: maybe thats the problem :)
<mvo> zyga: I guess there is someone on the internet for everything
<mvo> zyga: I just have to ask :)
<Chipaca> morning peeps
<pedronis> Chipaca: hi
<pedronis> mborzecki: hi, I added a couple of small comments to the asserts PR
<pedronis> mborzecki: btw did you see my comment over one of your old PRs about going over "for snapName ..." cases, most of them should be isntanceName I think
<mborzecki> pedronis: `for snapName ..` in the general codebase?
<pedronis> mborzecki: yes, there not that many
<Chipaca> mvo: do you remember, in snap pack, why we do all the exclusion work instead of asking mksquashfs to do it?
<mborzecki> pedronis: i don't recall it, but agree it makes sense to revisit the code places that do that
<pedronis> mborzecki: otherwise I would not suggest it, but they are also confusing atm
<pedronis> mborzecki: I count about 20 of them, vs ~900 general uses of snapName
<pedronis> some of which are correct and some are not, but don't think we would to fix those in one go
<pedronis> some will be taken care by looking at the for cases
<pedronis> s/we would/we want/
<mvo> Chipaca: I think by mistake, if mksquashfs can do it so should we
<mvo> Chipaca: we should also think about using fakeroot in snap pack
<Chipaca> mvo: it's can do exclusion by globs and regexpses
<mvo> Chipaca: or at least warn/error if we are not
<Chipaca> mvo: you don't need fakeroot unless you're packing os or core, right?
<mvo> Chipaca: cool, that sounds like a nice simplification
<Chipaca> mvo: but we do needd -all-root for apps
<Chipaca> i'm working on exactly that :)
<mvo> Chipaca: the review tools will complain if you `snap pack` and the uid inside the squash is != 0
<Chipaca> bah
<mvo> Chipaca: aha, right
<mvo> Chipaca: yeah -all-root
<Chipaca> i worked on a bunch of stuff snapcraft needs / could use from snap pack
<mvo> Chipaca: except for os of course
<mvo> Chipaca: nice!
<mvo> Chipaca: \o/
<Chipaca> that was last night
<Chipaca> today i'm picking it apart into branches and adding tests for people to read :)
<mvo> good stuff
<Chipaca> the using mksquashfs's exclusion bits is for later
<Chipaca> mvo: first up is using different flags depending on type, and using it from core if available
<niemeyer> mvo: Having the option to disable it sounds very interesting for us to be able to debug potential issues we observe after the feature goes live
<mborzecki> Chipaca: if you're stil up for reviews today, can you take a look at https://github.com/snapcore/snapd/pull/5960 ?
<mup> PR #5960: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960>
<Chipaca> mborzecki: nice
<mborzecki> people came in asking, i couldn't refuse :)
<mvo> niemeyer: ok, that is how zyga implemented it currently (kept the option but switch the default). so that sounds great
<niemeyer> mvo: And in either case, it would be polite to not error harshly if someone is trying to enable the feature that used to be experimental in the past release.. a grace period would be nice, so switching the default solves that as well
 * mvo nods
<Chipaca> mvo: niemeyer: panic("No more experiment for you!")
<chesty> I created a simple snap with the x2goclient package that's in ubuntu 16.04, when I install and run it I have no fonts. here's the snapcraft.xml https://pastebin.com/xJSKq1J2 any ideas? this is my first snap, so it's likely to be a simple mistake
<niemeyer> Chipaca: I'm sure people would appreciate that ;)
<popey> chesty: you don't have enough plugs. You probably want to at least add 'desktop' and 'desktop-legacy'
<Chipaca> niemeyer: ikr
<popey> chesty: https://forum.snapcraft.io/t/desktop-app-support-qt/6833
<chesty> popey, cheers, rebuilding now
<mborzecki> on master, tests running on amazon-linux-2 are hitting 'No space left on device'
<zyga> Brb
<zyga> re
<pedronis> Chipaca: thx for the review
<zyga> mvo, niemeyer: great, I'm happy I wrote it that way then :)
<zyga> the weather is very much not like autumn but the pressure feels low, I feel far to sleepy today
<mup> PR snapd#5956 closed: image: fetch device store assertion if available <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5956>
<sil2100> mvo: hey! I just quickly set up a github branch for the core deb subiquity package: https://github.com/CanonicalLtd/subiquity/tree/core/bionic
<pedronis> mvo: I should make a backport for #5956 now, right?
<mup> PR #5956: image: fetch device store assertion if available <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5956>
<sil2100> mvo: so in case you have any fixes you'd like to submit to the core-used bionic package, submit a PR there
<sil2100> I guess this will make things easier to coordinate
<mvo> pedronis: no need for a backport for 5956
<mvo> pedronis: I will merge master
<mvo> sil2100: ok, cool, I have a look
<pedronis> mvo: ah, ok
<pedronis> I thought you did that already
<pedronis> anyway, thanks :)
<chesty> popey, that fixed the font issue, thanks. I think I now need the home plug as it won't save the ssh server fingerprint, and then it should be rough enough is good enough. cheers.
<popey> the home interface won't allow access to ~/.ssh, if that's what you're after
<popey> chesty: maybe you can set an environment: HOME: $SNAP_USER_DATA, to force x2go to store stuff in the snaps home directory
<chesty> OK. will try that. thanks
<chesty> I haven't got it to work yet, x2goclient pops up a box saying the server is unknown, do you trust the host, clicking OK closes the box and it reopens with the same question. i can see the home dir is set to ~/snap/x2goclient/x1 I think x2go has it's own dir for ssh host keys...hmmm, I don't know how to debug it, strace doesn't seem to work
<mup> PR snapcraft#2334 closed: schema: enfore string for versions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2334>
<mvo> pstolowski: I am looking at a issue that was reported by the cloud team, when adding lxd as a snap boottime decreased and while looking at it it seems like a good chunk of the time is spend on connecting (see https://bugs.launchpad.net/cloud-images/+bug/1796137/comments/28) - iirc we had some pending work to run apparmor_parser less often - do you know more about where we stand here ? (cc zyga)
<mup> Bug #1796137: huge and slow image 20181002 due to seeded lxd snap <cloud-images:Confirmed> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1796137>
<mvo> (cc zyga)
<zyga> mvo: I know - there are two aspects of that
<zyga> one is done, I think it needs a review (I will check in a sec) but it is only polishing the existing state, not changing it significantly
<zyga> this involves just calling apparmor parser once for many profiles
<zyga> it offers modest improvements
<zyga> the big win comes from something we need to design first,
<zyga> when you connect many interfaces to a snap, you will have a lot of intermediate state
<zyga> that state may or may not be observed by hooks that get invoked
<zyga> if the state is not observed by any hooks we probably don't need it
<zyga> we could cut the number of invocations to apparmor parser significantly, from O(N) to O(1), if we do this optimisation
<zyga> it would involve making a connection and marking interface security as dirty or in need of triggering (dpkg style)
<zyga> and then performing those triggers
<zyga> the trick is making this while preserving semantics and correctness
<zyga> all in face of undo and what not
<zyga> that is not done or even drafted
<zyga> we just understand and recognise the problem
<mvo> zyga: ok
<mvo> zyga: that does not sound like a low hanging fruit at all
<zyga> no, it's not
<mvo> zyga: the cloud team would like to see improvements before cosmic :/
<zyga> feels like a cycle of rework
<zyga> that's unlikely to happen
<zyga> I think it would be easier without any hooks but given that we inject hook tasks and just do nothing in them if there is no hook to run makes optimisation much more challenging
<zyga> we could brainstorm this after user mounts
<zyga> in about a week and a half from now
<zyga> (promise!)
<pstolowski> mvo: i haven't looked at this. as zyga says not trivial. perhaps one relatively "quick win" (but probably not significant) would be to avoid scheduling interface hooks that don't exist (which is usually the case)
<om26er> Is there a snap out there to enable printer sharing on UbuntuCore ?
<mvo> pstolowski: that sounds good and easy and would avoid some cluttering in the output
<zyga> pstolowski: I agree, if we could pull that off we would have an open slate to perhaps optimise the special case of no hooks at all
<pstolowski> i think currently we mark all hooks optional, schedule the tasks only to realize hook script is not there and nothing happens
<zyga> and then solve the more general case of some hooks
<zyga> with no hooks at all we could add a trigger cycle just after the autoconnect cycle
<zyga> and keep regular connect / disconnect as-is
<zyga> also reducing complexity
<pstolowski> mvo: i can look at avoiding running non-existing hooks
<mvo> pstolowski: thanks that would be great I think
<mvo> pstolowski: once you have something, please add the PR into the bug so that the progress/work is visible to them
<mborzecki> pedronis: 5948 should be good now, now if only that spread job would pass
<mvo> sil2100: I filed #1797342 with the console-conf issue
<mup> Bug #1797342: console-conf crashes on UC18 on arm64 (dragonboard and pi3 in 64bit mode) <subiquity:New> <https://launchpad.net/bugs/1797342>
<pedronis> mborzecki: ack
<mup> PR snapd#5961 opened: snap/pack, snap/squashfs: use type to determine mksquashfs args <Created by chipaca> <https://github.com/snapcore/snapd/pull/5961>
<Chipaca> sergiusens: ^^
<Chipaca> mvo: also perhaps you're intersted ^
<sil2100> mvo: so it still happens for the dragonboard, huh?
<zyga> . sil2100 correct
<Chipaca> om26er: there's a cups snap
<zyga> sil2100: I tested it yesterday
<mvo> Chipaca: very! thank you
<sil2100> Had hopes that since I couldn't reproduce it on my pi3, it was gone
<mvo> Chipaca: just need to juggle between tasks
<Chipaca> mvo: psh
<mvo> sil2100: yeah, I'm trying to build a pi3-64 image to make testing easier
<mvo> sil2100: dragonboards are just rare :/
<zyga> sil2100: if you want I can give you my dragon for debugging
<zyga> either remotely via my office or I can just hand you one in person
<mvo> zyga: heh, nice that you have it so close
<om26er> Chipaca: are you talking about https://forum.snapcraft.io/t/call-for-testing-openprintings-printing-stack-snap-printing-in-a-snap/4406 (printing-stack-snap) ?
<Chipaca> zyga: fwiw (didn't catch this in the scrollback) we landed the pr to coalesce apparmor_parser calls a week ago
<Chipaca> om26er: yes
<mvo> Chipaca: aha, nice
<om26er> if so, it seems to not be available for armhf. I admit that was missing from my initial question.
<mvo> Chipaca: this means with 2.36~pre they should see *some* improvements at least
<mvo> Chipaca: I will dig out the pr number and paste into the report
<zyga> Chipaca: ah, thank you for that
<zyga> mvo: ^ so the low hanging fruit is merged
<mvo> zyga: ta
<Chipaca> https://github.com/snapcore/snapd/pull/5469 fwiw
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5469>
<mvo> Chipaca: nice
 * om26er is trying to convert a RaspberryPi into a print sharing server in our co-working space.
<popey> om26er: google cloud print?
<mvo> om26er: till did some works on a cups snap recently maybe he can help
<Chipaca> mvo: yep, that's printing-stack-snap
<Chipaca> lots of good info in that forum post
<mvo> nice
<om26er> @popey How will that work ? The printer is connected to the RPi which is connected to the office internet. How do we discover the printer if it isn't shared ?
<popey> om26er: I'm not sure tbh. But I have seen people use it to share printers easily, especially older USB printers.
<zyga> last time I looked it uses a host with the right software and local printer drivers to create a bridge between the printer and the google service
<zyga> so you send your print jobs to the cloud,  where they are pulled by the host with this service and sent to the local, pre-cloud, printer
<zyga> at some point any chrome installation was able to be the helper host
<zyga> and would allow a Chromebook print
<mborzecki> zyga: any chrome installation? sounds scary
<zyga> I think you have to enable it but yeah
<zyga> the idea was that there would be _someone_ with a windows + chrome laptop or desktop
<mborzecki> next step, print still from chromecast :)
<zyga> that would share a "legacy" printer
<mborzecki> as in the chromecast dongle
<mborzecki> mvo: any idea what's the status of cups snap?
<mvo> mborzecki: no, sorry, I did not follow it closely
<sil2100> mvo: since the issue is still around, I have also poked mwhudson to help out since he does own a dragonboard himself
<mvo> sil2100: aha, nice
<mvo> sil2100: do you think you could upload a probert with debug symbols to the foundations ppa so that we can get a core18 in edge that is easier to debug? I guess I can't do that mysefl because of lack of permissions(?)
<mup> PR snapd#5962 opened: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<ogra> mvo, can you remove kiosk.autoconnect.service from the pi-gadget ? that interface is gone with mir 1.0 (it now uses the wayland interface for everything) so the hack can go too
<sil2100> mvo: we didn't have debugging symbols in probert?
<mvo> ogra: sure
<mvo> sil2100: iirc we didn't when we poked at it in brussels
<mup> PR snapd#5963 opened: tests/hotplug: spread test for hotplug based on dummy interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5963>
<sil2100> mvo: ok, I'll look at that in a minute
<mup> PR snapd#5952 closed: tests/ifacestate: moved asserts-related mocking into helper <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5952>
<mborzecki> Chipaca: took your idea of stacking the erorr messages, the diff is slightly larger than expected https://paste.ubuntu.com/p/tFyFBth5w8/, i'm thinking of landing #5960 with suggestions from zyga and doing a follow up with that change
<mup> PR #5960: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5960>
<mborzecki> and then we can bikeshed about error messages :)
<zyga> brb
<zyga> while it's sunny and lovely outside
<zyga> I think I have a cold
<zyga> so ... brb
<Chipaca> mborzecki: sgtm
<Chipaca> hmm, hmm
<Chipaca> not sure 'cannot validate' is the right way to say 'we validated it, and found it lacking'
<zyga> cannot allow
<Chipaca> mborzecki: I think context should be added by the caller
<Chipaca> that is
<Chipaca> "cannot validate snap 'foo': %v" should be what the caller of Validate() does
<Chipaca> not Validate itself
<Chipaca> because
<Chipaca> then you can say "cannot pack thesnap/" or "cannot install some.snap" or â¦
<Chipaca> instead of having "cannot pack thesnap/: cannot validate "the.snap": â¦"
<mborzecki> mhm
<Chipaca> but maybe that's too hard :)
<zyga> good point Chipaca
<Chipaca> we already mostly do this
<Chipaca> we do os.MkDir() and then "cannot mkdir: %v"; we don't expet MkDir to have the context
<Chipaca> but when we write both sides of the code it's harder to remember, i guess
<Chipaca> dunno
<Chipaca> maybe i just need lunch
<pedronis> mborzecki: I looked a bit again at snap and Validate*, seems a snap/names package with the various Validate for name like things, and maybe even the regexps exposed could make sense
<dot-tobias> Is it possible to use plugin artifacts across builds, but refresh my app's source? I.e. using the Ruby or nodejs plugin, keep the built ruby/node runtime but refresh the pulled-in code from the part's repository? If I'm not overlooking something, the current snap clean my-part removes everything related to that part?
<mborzecki> pedronis: in case you missed the diff i sent yesterday, https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/validate-name-separate-package that's the thing i was working on, i can tweak it further and propose it after 5948
<zyga> dot-tobias: this is a question for sergiusens or kyrofa but they may be around later since they are in another timezone
 * zyga is happy to know time namespaces are coming to the kernel
<zyga> feels appropriate somehow
<pedronis> mborzecki: I see, no I hadn't looked at it, yes seems to go were I was thinking
<pedronis> *where
<dot-tobias> zyga: Thanks, will keep a watch on the room list then ð
<zyga>  dot-tobias consider asking on the forum as well
<mborzecki> pedronis: cool
<dot-tobias> zyga: Will do that
<sil2100> mvo: btw. did you see my e-mail question about the inconsistency in new model assertion names for core18?
<pstolowski> mvo: the hooks optimization looks promising, i did the change but need to accomdate a large number of existing tests which inspect tasks
<mvo> pstolowski: great, thanks for this heads up
<mvo> rbasak: I followed up on 1796017 we can sync up after lunch, my comments are probably not super helpful :/
 * mvo lunch
 * pstolowski lunch
<sergiusens> dot-tobias: sort of, but mind asking that on the forum so everyone benefits from the full answer?
 * Chipaca lynch
<ogra> whom ?
<ak2766> When I execute `snap list` or `snap find` I see some publishers have a green tick beside their name - what does that indicate?
<zyga> that the publisher is *verified*
<pedronis> identity wise
<ak2766> @zyga - thanks - I was overthinking it then...
<ak2766> @pedronis - thanks too
<Chipaca> ak2766: what were you thinking it was?
<Chipaca> ak2766: and, how could we improve the output of 'snap list --help' to better explain it?
<zyga> Chipaca: [ v - identity of the publisher has been verified] (legend)
<Chipaca> zyga: wasn't asking you :-Ã¾
<Chipaca> (we trialled legends and they didn't really work)
<Chipaca> they're helpful the first N times, and then just get in the way
<Chipaca> where N is â¦ hard to get right
<Chipaca> (because I looked at only showing the legend the first N times :) )
<rbasak> mvo: ack
<mup> PR snapd#5960 closed: snap, wrappers: support restart-delay, generate RestartSec=<value> in service units <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5960>
 * Chipaca remembers he had lunch cooking and goes to tend to it before the fire alarm does
<Chipaca> the report of my lunch's death was an exaggeration
<dot-tobias> sergiusens: Re: plugin artifacts â Sure, here's the topic I opened for this: https://forum.snapcraft.io/t/keep-plugin-artifacts-environments-across-cleanups-for-faster-iteration/7834
<jdstrand> zyga: I wonder if it is possible to optimize the fastpath-- ie, when everything goes right, which is the normal case
<zyga> yes, I believe so
<zyga> do you have in your backlog the discussion between mvo, pstolowski and me?
<jdstrand> zyga: cause looking at http://paste.ubuntu.com/p/RYd5mDB76q/, it is clear that it is taking 1-2 seconds to load the lxd profiles, but we do the whole group over and over again for now reason
<jdstrand> (which I know you know, I phrased it that way for others in the channel)
<jdstrand> zyga: I do
<zyga> ah. ok :-)
<jdstrand> s/now/no/
<jdstrand> I mean, I know the reason. I mean, there is no reason we have to do it that way :)
<jdstrand> meh. the point is, maybe the situation can be improved for the normal case without having to rearchitect everything to handle the failure cases as efficiently
<jdstrand> I don't have anything specific to suggest; just posing the question
<sil2100> pedronis: hey! Did you see my e-mail question regarding the model name inconsistencies for core18? Just wanted to know if I should special-case those names or will they still be changed
<pedronis> sil2100: it's not a question for me, it's more mvo
<pedronis> but afaict they are decided
<pedronis> *afaik
<sil2100> That would be too bad!
<sil2100> Oh well
<sil2100> mvo: once you're back ^
<zyga> jdstrand: the failure case is, I think, to just abort the op and re-setup security in the undo path
<zyga> (with no optimisations)
<zyga> I think it's not that hard as I initially thought actually
<zyga> because the bulk of it is in the auto-connect logic
<ak2766> @Chipaca - I was thinking it had something to with whether it was a full container or needed --devmode...
<zyga> that is one function
<zyga> where we can just buffer the changes
<zyga> post-process them
<zyga> and then execute whenever someone needs to observe the current state
<Chipaca> ak2766: aha
<Chipaca> ak2766: if it needed devmode you wouldn't see it in 'snap find', fwiw
<Chipaca> ak2766: and in snap list, it'd say devmode in the notes
<Chipaca> i'll be adding colour to the notes sometime soon
<jdstrand> zyga: oh, that is interesting. yes, you could queue everything up, then at the end, say 'run the queue', but the queue is smart (eg, a hash) and doesn't have duplicates
<zyga> for ... in auto-connect-things { connect(plug, slot) and mark security as dirty; if hook { make security clean }; } make security clean;
<ak2766> thanks - good to know... I'm new to snap - the apt-get lxd was running like a dog and soneone suggested I try snap - never going back...
<zyga> jdstrand: apart from writing tests changes it should be fairly small
<zyga> (involving no new backend logic probably)
<Chipaca> ak2766: glad to know it's being useful; do let us know when we mess up :)
<jdstrand> +1000 :)
<zyga> *probably*
<jdstrand> :)
<zyga> I didn't think deeply about interaction with other backends though
<zyga> shall we buffer for everything
<zyga> or just special case apaprmor
<zyga> if we special case it is the case we thought about before
<zyga> but I think we should not special case
<zyga> to be even more efficient
<zyga> and have predictable properties (no intermediate state)
<jdstrand> we precompile seccomp. I don't know how measurable an impact it would make, but there is computation there, so probably worth doing
<zyga> I'm happy to do this after user mounts
<jdstrand> udev is just writing out files
<zyga> yeah and also totally generic in that sense
<zyga> less udev triggers, less apparmor, less seccomp, less selinux relabelling or what else we need to do
<jdstrand> I mean, it would benefit for efficiency, but maybe not phase 1
<jdstrand> actually, there is the trigger, yes. probably should include that too
<zyga> I actually think this is phase one and last, there would be no phases, just introduce the delayed setup to the auto-connect function
<zyga> (in my head this doesn't change regular connect / disconnect)
<jdstrand> wfm
<zyga> anyway, just an idea, I didn't attempt this yet so there may be something we've missed
<mvo> sil2100: I will reply in a bit, have not seen it
<ak2766> @Chipaca - definitely will - if I needed to post to a forum, do you have something akin to https://stgraber.org/
<jdstrand> zyga: right. the idea is each of the backends knows the difference between dirty and clean
<Chipaca> ak2766: https://forum.snapcraft.io (in the topic in case you forget)
<jdstrand> zyga: dirty is writing out the files. clean is running some command on them
<ak2766> @Chipaca - I've just joined snapcraft.io
<jdstrand> zyga: that should work
<zyga> jdstrand: perhaps, though I would even avoid writing the files, dirty is we know we want to do it and that's that;
<zyga> we can always compute the current state
<zyga> clean is that we actually do it because someone wants to use the state
<zyga> this way backends don't change
<jdstrand> zyga: the only trick is ensuring that we never end up in a permanent dirty state
<zyga> well, that's nice too
<zyga> dirty state is ... nothing happened :)
<zyga> we have a connection in the state
 * Chipaca ~> cuppa tea and something to much during the meeting
<zyga> but nothing else
<zyga> so on reboot we will setup security and things will be back to normal
<zyga> (in case we lose power in the dirty state)
<zyga> but I would only record the connection changes of auto-connect *after* we clean after the loop
<jdstrand> zyga: well, the thing is, we need the thing being written out to disk to be all of them, but the command to run them to only be at the end
<niemeyer> Folks, I've got a conflicting meeting today at the same time as our standup, please don't wait for me.. I'll join if it doesn't happen or ends early
<zyga> jdstrand: yes but I think that approach is more complex
<jdstrand> zyga: I think that requires a small change to the backends, no?
<zyga> it doesn't harm us not to write anything
<zyga> we don't call backend.setup at all until all of the connections are established
<jdstrand> no, it wouldn't. assuming we end up with the same thing written out
<zyga> well, that's guaranteed by the design of the security model
<zyga> based on the ensure logic
<jdstrand> zyga: I'm thinking: plugs: [ a, b, c ]
<zyga> I think that's easier
<mup> PR snapd#5949 closed: osutil,asserts,daemon: support force password change in system-user assertion <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5949>
<zyga> niemeyer: ack
<jdstrand> zyga: but only c is plugged at the end when the command is run (ie, we forgot to record a and b into the files written to disk)
<zyga> jdstrand: btw, I wrote something I want to share, a detailed walkthrough through snap-confine, I want to have this in the forum so that people can review my persistent per-user mount namespace patches
<mup> PR snapd#5964 opened: overlord/snapstate: export getFeatureFlagBool <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5964>
<zyga> jdstrand: that's the thing
<jdstrand> zyga: re aside> we had something like that before. it is good to have it updated
<zyga> jdstrand: in the idea where we don't run setup at all
<zyga> jdstrand: the fact that [a, b, c] are connected is not known to anyone but the auto-connect loop
<zyga> once we are done we setup security for the set of affected snaps
<zyga> and that's that
<zyga> before we start that setup nothing on the system knows about the connection (not even snapd state)
<jdstrand> zyga: I see. I haven't looked at all the code in a very long time. I'm not saying there is a problem or advocating a solution. I'm just describing what I'd be concerned about
<zyga> jdstrand: right
<zyga> jdstrand: after thinking about it briefly earlier today I changed my mind about teaching backends about this
<zyga> because precisely this is less complex to do correctly
<jdstrand> zyga: hey, that's great :)
<zyga> we can only forget to setup security in the end, and that implies the connection is just absent
<zyga> so that's not any more dangerous
<zyga> I was really only concerned about hooks
<zyga> because hooks do need to see the partial state
<zyga> but current logic has no distinction between a hook that exists for sure
<zyga> and a hook that simply may exist
<zyga> so it's hard to optimise if the sequence is like
<zyga> [compute-intermediate-1, maybe-observe-1, compute-intermediate-2, maybe-observe-2, ...]
<zyga> pstolowski is looking at discarding the maybe-observe-N that really are no-ops
<zyga> so that we know exactly when to setup security
<zyga> it is also interesting that the security setup involves a subset of affected snaps
<jdstrand> I dont follow that last sentence
<zyga> but effectively in the end the full set is obtained
<zyga> a simple example
<mup> PR snapd#5965 opened: interfaces/tests: use TestInterface instead of a custom local helper <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5965>
<zyga> we auto connect core
<pstolowski> pstolowski: what is maybe-observe-*, sorry? ;)
<zyga> and there are two snaps [a, b] that connect network
<zyga> we get core:network a:network
<zyga> and core:network b:network (well, swapped around but you get the idea)
<zyga> assuming that both have hooks that need to observe the network being connected
<zyga> we need to setup security for (core, a), (core, b)
<zyga> where ( ... ) denotes the set of snaps affected by a connection
<zyga> we don't need to re-setup security for a when we do the intermediate state for b
<pstolowski> i'm looking at not creating prepare-* or connect-* hook tasks at all if they are no-ops (ie. hooks not present)
<zyga> pstolowski: that's perfect, that is what I meant
<pstolowski> okay
<pstolowski> it's not affecting profile generation at all, but it should save some cycles as we serialize hooks execution
<zyga> +1
<cwayne> sil2100: heya, so one thing we found in testing: whenever the 3b+ reboots were getting a new MAC address
<jdstrand> mvo: where are we in the 2.36 cycle? is there time to get stuff in?
<jdstrand> mvo: hi btw :)
<mvo> jdstrand: in a meeting - but yes, still time until later today
<mvo> jdstrand: but there may be exceptions for you
<sil2100> ogra: ^
<zyga> mvo: ^
<sil2100> cwayne: hm, thanks
<sil2100> cwayne: I wonder if ogra saw the same thing during his testing
<ogra> sil2100, worth filing a bug but not worth holding back the image for IMHO
<ogra> i didnt actually check the MACs i must admit
<ogra> but the b+ uses a new ethernet NIC so it is well possible
<ogra> we can add a fix for this in later iterations
<sil2100> ogra: yeah, if it's something we can fix out-of-image then +1 on that
<ogra> well, it might need a new gadget at some point and the payload in the gadget isnt upgradeable (only metadata) ... so it might also need a new image eventually
<ogra> but having a b+ image with changing MAC is still better than not having a b+ image at all
<jdstrand> mvo: there are 2 maybe 3 things: https://github.com/snapcore/snapd/pull/5739, then an upcoming k8s interfaces PR (profile updates with 2 new interfaces) and possibly a 'miscellaneous profile updates' PR. I don't know how feasible it is for all of it. I know kjackal_bot *really* wants 5739 and it is passing now
<ogra> we have many peopel eagerly waiting for it
<ogra> *people
<mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739>
<sil2100> ogra: a bit troublesome then, we'd have to mention that in some release notes
<ogra> yes
<sil2100> Not sure if we have any for core16
<ogra> you can mention it in the forum thread wher people are sitting and tapping their feet
<ogra> sil2100, https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509
<sil2100> lool: hey! Since you were the one requesting the pi3b+ support first hand, would you be fine with images that don't have constant MAC addresses?
<ogra> sil2100, i'll start working on that in ~10 days and produce a fix ... currently i#m just busy with preparing for IoT worldcongress and next week i'll persent there ... after that i can take care of that bug ... but i dont think we should delay the image another two weeks
<cwayne> sil2100: from our end we'd definitely prefer it fixed first
<cwayne> plars: ^
<ogra> k
<plars> it's a serious problem for anyone who needs to access it remotely
<ogra> i think cwayne is authoritative here
<cwayne> As it is it will mess with our lab setup
<ogra> ok
<cwayne> ogra: <3
<ogra> sil2100, then i'm with plars and cwayne
<ogra> i'll try to squeeze in some time tomorrow, perhaps the fix is simple
<ogra> (with luck is its just an addition to the devicetree ... and worst case it needs the same initrd scrit the dragonboard uses, bth are fixable via the kernel snap)
<cwayne> We're happy to help and test along the way ogra
<ogra> ok
<ogra> cwayne, plars i assume thats only with wired ?
<ogra> (wlan should be identical to the normal pi3)
<cwayne> That's my understanding
<ogra> good
<mup> PR snapcraft#2342 opened: nodejs plugin: update to the latest 8.x LTS version <Created by anthonyfok> <https://github.com/snapcore/snapcraft/pull/2342>
<sil2100> ogra, cwayne, plars: yeah, +1 on that
<ogra> btw https://snapcraft.io/mac-spoofer :P
<sil2100> lool: ^
<sil2100> The problem is, this week probably we'll be switching off core16 image builds for a bit to enable core18 ones
<sil2100> We want to enable core18 ones but then we'll have to wait for a livecd-rootfs SRU to get released in xenial to be able to switch on core16 ones again
<ogra> and here we go: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/lan78xx.c?id=760db29bdc97b73ff60b091315ad787b1deb5cf5
<ogra> ppisati, ^^^ do you know if we have this in the pi 4.4 kernels ?
<sil2100> If that's it then we'll need a new image for the fix indeed
<ppisati> ogra: i think we do
<ogra> sil2100, nah, if this one fixes it we only need a kernel update
<ppisati> let me check
<ogra> sil2100, the prob is if there are bits needed in the u-boot config or a u-boot patch ... then we need a new gadget and gadgets are not upgradeable (you are stuck with the first bootloader binary and config you install on core)
<ppisati> ogra: nak, we don't have it
<ogra> thought so
<ppisati> ogra: do we need that? i guess so
<ogra> ppisati, think it is hard to add ?
<ppisati> ogra: nah, it appears easy
<ogra> it would be helpful indeed :)
<sil2100> ogra: don't we have the kernel in the boot partition as well? Oh, or is this built as a module?
<ppisati> ogra: i'm working on mvo's rasp3b+ regression, i'll move to this immediately after
<ogra> i still need some idea how to injetc a fixed MAC into the DT though ...
<ogra> sil2100, the kernel in the boot partition gets updated when the snap gets updated
<ogra> ppisati, <3
<sil2100> ogra: ok, nice
<ogra> sil2100, the only non-upgradeable bit is the bootloader (sadly)
<ogra> fixes in that area require a re-flash
<ogra> (and new image indeed)
<pstolowski> mborzecki: zyga can you take a look at #5964 and #5965? these are real trivials
<mup> PR #5964: overlord/snapstate: export getFeatureFlagBool <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5964>
<mup> PR #5965: interfaces/tests: use TestInterface instead of a custom local helper <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5965>
<mvo> ppisati: oh, nice! could you reproduce the no-carrier on eth0?
<zyga> done
<jdstrand> zyga: would you mind taking a look at https://github.com/snapcore/snapd/pull/5739 ? You have a request changes and I've fixed it and it passes
<mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739>
<zyga> not at all, looking
<mborzecki> jdstrand: can you take a look at https://github.com/snapcore/snapd/pull/5947 ? there's one trivial commit to interfaces/builtin which may be of interest to you
<mup> PR #5947: many: cleanup remaining parallel installs TODOs <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5947>
<jdstrand> mborzecki: done
<mborzecki> jdstrand: thanks!
<zyga> jdstrand: replied :)
<zyga> jdstrand: this is nice because we could use something similar for parser bugs eventually
<zyga> jdstrand, roadmr: is the review tools bug that I bumped into last week really fixed
<zyga> I mean fedora29 snap I uploaded and hit that cleanup issue
<mup> PR snapd#5964 closed: overlord/snapstate: export getFeatureFlagBool <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5964>
<ppisati> mvo: yes, and i'm debugging it
<zyga> I'm asking because I tried to upload it again and hit the same error
<roadmr> zyga: I haven't yet deployed the updated reviewer-tools to the store :/ working on it
<zyga> roadmr: ah, thank you for the explanation
<roadmr> zyga: so it is fixed in the tools themselves but I'm not yet using the fixed version
<zyga> no worries!
<zyga> it's not urgent
<roadmr> zyga: if all goes well, it'll be out today.
<mup> PR snapd#5965 closed: interfaces/tests: use TestInterface instead of a custom local helper <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5965>
<mvo> ppisati: awesome, thank you !
<mborzecki> zyga: do you know if it's really broken? https://www.reddit.com/r/linux/comments/9n50ba/lets_see_why_flatpak_and_sandboxing_are_awesome/e7kld6h/
<mvo> jdstrand: thanks for the update. I have a look at 5739. do you have an estimate when the other bits you plan will be ready? (roughly?)
<jdstrand> mvo: I will have the feedback from zyga addressed for 5739 in a few minutes (running ./run-checks now)
<jdstrand> mvo: I will do the fast parts of miscellaneous profile updates next (~1 hour?). I will move to the k8s PR next. a few hours I would say
<mup> PR snapd#5966 opened: snap: overhaul validation error messages <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5966>
<jdstrand> zyga: responded to feedback: https://github.com/snapcore/snapd/pull/5739
 * zyga -> walk
<mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5739>
<rbasak> Does anyone else always forget whether they're in a snap run --shell or not? A PS1 change would be nice, though I'm not sure if that's appropriate for snap run to arbitrarily do by default.
<zyga> jdstrand: +1
<jdstrand> rbasak: since it went to the group I'll chime in and say I've never forgotten that :)
<jdstrand> zyga: thanks!
<jdstrand> mvo: ok, zyga approved 5739 and all feedback is addressed. spread is running (it took 4 times yesterday for a good run yesterday (unrelated to my changes)). do you want a 2.36 PR?
 * cachio afk
<niemeyer> Chipaca: Before you spend time on it, added some comments on the --lines topic
<Chipaca> niemeyer: the problem is that, right now, the results you see if you don't scroll are the least relevant
<Chipaca> we could also auto-pager, but some people don't like that :)
<niemeyer> Chipaca: It's a common behavior to have more relevant at the top
<Chipaca> oh, it's the right thing to do, to have the most relevant at the top
<Chipaca> i don't mean to imply otherwise
<niemeyer> Chipaca: If the list is too long, either I want to see a long list so I can go through it, or my search was poorly done
<niemeyer> Chipaca: In the first case, I want to see the list.. in the second case, I may opt to reissue the command with a better search instead of knowing about 25 results
<mvo> jdstrand: no need for a 2.36 pr right now, I will merge master back (not that many changes so far)
<mvo> jdstrand: and some hours sounds fine
<mborzecki> zyga: i'm thinking of tuning the spread tests to do https://paste.ubuntu.com/p/q5skPJqRXg/ on case by case basis
<niemeyer> Chipaca: Do you have sample searches that made you wish for the change in behavior?
<Chipaca> niemeyer: some simple and perhaps over-broad ones, like 'snap search game'
<Chipaca> niemeyer: or 'snap search developer'
<jdstrand> mvo: great, thanks!
<niemeyer> Chipaca: Interesting.. these are good examples of the two cases I mentinoed
<niemeyer> Chipaca: Searching for developer is a bit pointless, so improving the parameter would be better.. searching for game, clearly one wants to browse through results
<Chipaca> niemeyer: snap find 'developer tool' :)
<Chipaca> but, yeah
<Chipaca> i do see your point
<Chipaca> niemeyer: next time i come across a really bad one i'll take note :)
<zyga> re
<zyga> mborzecki: +1, this is why I introduced the command in the first place
<mborzecki> zyga: yup, now with the profile info and features we can pick an choose
<zyga> and have better coverage
<mborzecki> if opensuse leap 15 was in we could use that too
<mborzecki> zyga: it had the right kernel if i'm not mistaken?
<mborzecki> or was it just TW?
<zyga> TW
<zyga> leap 16 will be good
<zyga> Chipaca: snap find "for raspberry pi"
<rbasak> mvo: around?
<rbasak> mvo: your suggestion actually works well for me.
<rbasak> And allows me to fix it for now at least I think.
<rbasak> mvo: http://paste.ubuntu.com/p/Yx2f4gKM55/
<rbasak> Because quilt calls awk via PATH, and that allows me to insert a wrapper.
<rbasak> More generally, could you use patchelf or whatever to make all paths to the loader in the core snap relative? Would that break anything?
 * rbasak wonders if the kernel will even accept that
<mvo> rbasak: nice
<mvo> rbasak: I guess we could its just risky
<mvo> rbasak: patchelf sometimes also is called breakelf
<mvo> rbasak: we had some known issues (to be faire mostly with go binaries)
<rbasak> What role does the core snap play for classic snaps?
<mvo> rbasak: none really, I mean classic snaps mostly deliberately avoid it
<mvo> rbasak: for the reasons we ran into, its hard to use it from a classic snap
<rbasak> nacc is offline right now
<rbasak> I wonder what caused the use of the core snap like we're doing in git-ubuntu in the first place.
<rbasak> Because another way to solve this would be to build our own awk.
<rbasak> And avoid the core snap altogether - which I think is the default if we don't point to it?
<mvo> rbasak: or just include the one from the distro via stage-packages
<mvo> rbasak: but yeah, thats probably easier and more controlled
<rbasak> Good point :)
<mvo> rbasak: i.e. you would know exactly what awk you get (and what quilt etc) so less risk
<mvo> rbasak: plus these bits are not very big
<rbasak> Oh. Using stage-packages will make it a symlink to /etc/alternatives
<rbasak> But that can be hacked around
<mvo> rbasak: gar
<mvo> rbasak: I really dislike /etc/alternatives nowdays :)
<ogra> who doesnt
<rbasak> :)
<mvo> jdstrand: do you mind if I commit a unit test to 5739 around release/apparmor.go:probeAppArmorParser ?
<mup> PR snapd#5967 opened: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5967>
<pstolowski> zyga, mborzecki one more trivial please, if you have a moment: #5967
<zyga> sure
<mup> PR #5967: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug ð> <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5967>
<mup> PR snapd#5968 opened: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968>
<jdstrand> mvo: re 5739> not at all
<jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/5968
<mup> PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968>
<mvo> jdstrand: cool, I updated the 5739 and added a diff with my suggestions - if those look sensible I can commit/push
<mvo> jdstrand: looking at this new one now
<mvo> jdstrand: I can also do the tweaks in a followup
<mvo> jdstrand: its just "sugar" :)
<jdstrand> mvo: please see the git commit for the dbus private bus for maximum context
<mvo> ta
 * Chipaca afk
<pstolowski> mborzecki, zyga ty!
<mvo> zyga: 5867 has a conflict
<zyga> mmm
<jdstrand> mvo: ok, I commented in the PR. feel free to adjust based on the paste if so inclined
<jdstrand> mvo: thanks!
<mvo> jdstrand: thank you
<zyga> mvo: resolved inside github
<zyga> I'll grab coffee,  brb
<mvo> jdstrand: heh - thats what you get with code reviews, conflicting opinions ,)
<mvo> jdstrand: don't worry I take care of it and we land your PR its fine as is
<jdstrand> mvo: :) thanks!
 * jdstrand hugs mvo 
<jdstrand> mvo: ok, now let me resurrect my k8s branch. this will be a few hours
<mvo> jdstrand: no worries, I check back later tonight then
<jdstrand> mvo: if you have to move faster than me, go ahead. I'll let you know if I don't want it for 2.36
<jdstrand> but I'm working on it now
<mup> PR snapd#5969 opened:  apparmor: add unit test for probeAppArmorParser and simplify code  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5969>
<zyga> re
<zyga> reviewed mvo
<mvo> jdstrand: one more question - since what ubuntu release do we have "unsafe" ? roughtly ? 16.04? 18.04?
<mvo> zyga: ta
<zyga> mvo, thank *you*
<mvo> zyga: I want to do a spread test for this too just to be on the safe side
<zyga> mvo: note that the original failed in spread, this is why we knew
<mvo> zyga: heh - tests ftw!
<jdstrand> mvo: it was introduced in 2016. it is in 2.10.95 which was backported to trusty
<mvo> jdstrand: thanks, I add a spread test that ensures this works on ubuntu then
<jdstrand> cool, thanks
<lool> sil2100: I dont have strong objections about random MAC, but is this a regression specific to that image or 3B+?
<lool> ogra: ^
<lool> sil2100: best to get in touch wiht ogra in general, he understands the lower levels much better than I do
<cwayne> lool we only saw it on pi 3b+.  It would severely impact my teams ability to auto-test it so we'd prefer it fixed before release
<Chipaca> jdstrand: unit test failure in #5968
<mup> PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968>
<Chipaca> jdstrand: https://travis-ci.org/snapcore/snapd/jobs/440193822#L1540
<jdstrand> :\ I ran them locally
 * jdstrand looks
<ogra> lool, sil2100, given that b+ was not supported *at all* before it is indeed not a regression
 * mvo hugs Chipaca for adding the staged tests in travis
<jdstrand> darn it, I didn't run it on that
 * jdstrand fixes
<Chipaca> :-D
 * Chipaca takes all the hugs he can get
<mvo> jdstrand: no worries
<lool> sil2100: given cwayne's feedback, let's hold on calling this gold I guess
<mvo> jdstrand: running this is "cheap" now :)
<lool> ogra, cwayne: any idea on how to fix this?
<ogra> lool, right, thats the plan
<lool> is it a boot assets issue?
<ogra> lool, there is a patch https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/lan78xx.c?id=760db29bdc97b73ff60b091315ad787b1deb5cf5 that allows it to set it from the dtb ... i'll be looking for a way to inject the serial into that from u-boot
<jdstrand> mvo: I noticed that refactoring. really nice :)
<ogra> lool, injecting it into the dtb is a boot asset thing (uboot.env most likely) ... the rest is kernel and paolo already agreed to pull that patch into the next kernel
<lool> ogra: how do the rpi official upstream images manage it?
<jdstrand> Chipaca (cc mvo): thanks, fixed
<ogra> lool, not sure but i'll find out ... i know that debian specifically added this kernel patch tough ...
<niemeyer> Chipaca: This is looking very nice: https://travis-ci.org/snapcore/snapd/builds/440193821
<niemeyer> Chipaca: Thank you!
<ogra> lool, actually the patch comes from raspberrypi.org https://lore.kernel.org/lkml/1524066323-109628-2-git-send-email-phil@raspberrypi.org/
<ogra> so i assume they are using it too ...
<niemeyer> jdstrand: Quick question on #5968
<mup> PR #5968: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5968>
<jdstrand> niemeyer: hi
<mvo> zyga: one idea 5867
<zyga> mm
<zyga> lookinf
<zyga> mvo: +1 if you have that handy to push
<zyga> (my tree is full of user mounts)
<zyga> nice idea, thank you
<mvo> zyga: ta
<mvo> zyga: if your pr is green I will merge and followup, otherwise I can push into the pr
<mvo> zyga: anyway, I will deal with it :)
<mvo> Chipaca: you mentioned mksquafs doing the exclude pattern, are you working on this ? it sounds like a great idea the more I look at the snap pack code
<jdstrand> niemeyer: answered
<zyga> thank you mvo
<niemeyer> jdstrand: Thanks for explaining
<ogra> plars, https://paste.ubuntu.com/p/whNnhnQCRx/ could you cross check if your MAC in the dtb differs ?
<mup> Bug #1797423 opened: "Channel <blank> for poedit is closed; temporarily forwarding to stable." when amending a locally installed snap <Snappy:New> <https://launchpad.net/bugs/1797423>
<ogra> if it does we actually only need the patch added to the kernel and should be good to go
<plars> ogra: hmm, I can't seem to break into uboot from the console, do I need serial for it?
<ogra> yeah, i guess it defaults to serial input
<ogra> U-Boot> printenv stdin
<ogra> stdin=serial
<ogra> yeah
<ogra> (though i'm using a kiosk gadget here ... not sure what the generic pi3 one uses, i have used device specific pi gadgets in ages)
 * ogra checks GH
<ogra> https://github.com/snapcore/pi3-gadget/blob/master/uboot.env.in says "stdin=serial,usbkbd" so it should theoretically work
<smoser> hi. wondering if anyone can help out https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1797218
<mup> Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1797218>
<smoser> at this point, a few hours from final freeze of ubuntu 18.10, it looks like the only possible solution is to drop seeding of snaps in ubuntu cloud images.
<zyga> smoser: looking
<zyga> smoser: are cloud images using overlayfs?
<zyga> smoser: can we pull oops 4d395dae-ccc5-11e8-90ca-fa163e102db1 ?
<smoser> pull ?
<ogra> zyga, you mean https://errors.ubuntu.com/oops/4d395dae-ccc5-11e8-90ca-fa163e102db1 ?
<smoser> one use case for our cloud images (used in maas deployment and other cases) is overlayroot.
<ogra> https://errors.ubuntu.com/oops/4d395dae-ccc5-11e8-90ca-fa163e102db1
<ogra> err
<ogra>  ERROR run hook "install": cannot create lock directory /run/snapd/lock: Permission denied
<ogra> zyga, ^^^
<plars> ogra: do I need to do anything before run loadfiles? I get an error
<plars> ** Bad device 0:1 0x00200000 **
<plars> ogra: but fdt print ethernet still gives me output:
<ogra> nope, loadfiles loads kernel, dtb and initrd ...
<plars> https://www.irccloud.com/pastebin/ptELLP5i/
<zyga> ogra: is this a container?
<zyga> that's so weird
<zyga> it feels like a container that runs on snapd with unstacked apparmor
<ogra> plars, \o/ it differs !! so just the kernel patch is enough !
<zyga> smoser: I see
<zyga> smoser: let me think then
<ogra> plars, thanks a lot
<zyga> smoser: can I see such an image somewhere
<zyga> pull it and boot it in qemu for experiments?
<plars> ogra: great news! happy to help :)
<zyga> ogra: thank you for the oops
<ogra> zyga, no idea, i just gave you the error msg from the oops you mentioned ;)
<zyga> I suspect I understand the problem
<zyga> smoser: ^
<zyga> smoser: but I need a this image to provide a fix
<zyga> mvo: ^ if this is true we need this for 18.10 final
<ogra> lool, so the kernel patch is the right thing, the upstream firmware actually seeds local-mac-address in the devicetree with a unique MAC already, our kernel just doesnt pick it up
<zyga> smoser, mvo, jdstrand: ^ it seems that cloud images use overlayfs and need extra permissions for our various apparmor profiles
<lool> ogra: cool
<zyga> jdstrand: it seems that we cannot create the lock directory because the real permission is /upper/run/snapd/lock or something like that
<smoser> zyga: you need this image ?
<zyga> smoser: do you have apparmor denials (domes | grep DENIED)
<zyga> smoser: please, it would allow me to test and fix this
<smoser> i provided recreate instructions
<smoser> and you can download the image from cloud-images.ubuntu.com
<zyga> thank you
<ogra> zyga, would be odd if /run was a part of an overlay though, i'd consider that a gross design bug, it should simply be tmpfs
<zyga> I'll do that now
<zyga> ogra: well, that is my current theory, more in some time
<smoser> ogra: right. /run is not a overlay
<zyga> smoser: which one of http://cloud-images.ubuntu.com/cosmic/current/ should I get?
<smoser> that would be odd for sure. overlayfs over a tmpfs backed by a tmpfs
<ogra> heh
<smoser> i'd get cosmic-server-cloudimg-amd64.img
<ogra> it would make a funny anecdote though :)
<zyga> thanks, getting that
<jdstrand> why are cloud images using overlayfs?
<zyga> jdstrand: dunno
<mup> PR snapd#5967 closed: interfaces/hotplug: rename HotplugDeviceKey method to HotplugKey, update test interface <Hotplug ð> <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5967>
<zyga> smoser: can you please tell me how to run that image in qemu?
<ogra> makes them more cloudy ?
<jdstrand> and yes, why /run of all things?
<zyga> jdstrand: I suspect they use ephemeral images with overlayfs for Maas
<zyga> but I'm just guessing
<zyga> jdstrand: right? :)
<Odd_Bloke> This was found during curtin testing, so I believe you are correct, this is ephemeral images.
<smoser> these are just standard images
<jdstrand> it looks like they are
<smoser> they're booted with overlayroot=tmpfs
<smoser> command line
<zyga> smoser: do I need any magic for cloud init or whatever?
<Odd_Bloke> Right, but being used in an ephemeral context, right?
<zyga> I'm not a cloud expert
<jdstrand> this is currently unsupported, but we have overlayfs detection logic-- it could be updated
<smoser> you'll need to provide some way to get into the image
<smoser> either
<smoser> a.) provide a cloud-init seed of some sort (and have it set a password for login)
<smoser> b.) mount the image, set a root password, unmount it
<jdstrand> but just cause snap-confine is updated, doesn't mean snaps are going to run correctly. this is not a bug as much a missing feature
<zyga> yeah, I agree
<jdstrand> use of overlayfs is not at all transparent to apparmor
<jdstrand> that said, I'm surprised other things in the cloud image, like dhclient, would work
<zyga> smoser: are all cloud images using ovelayfs / - that is - is this a generic problem?
<jdstrand> (in this ephemeral env)
<zyga> or can we solve a specific case and be okay because normally they use a regular filesystem?
<zyga> jdstrand: depending on how this is set up
<zyga> jdstrand: apparmor.service is not started
<zyga> jdstrand: so maybe all confinement is off
<zyga> apart from snapd
<jdstrand> right
<zyga> smoser: can you provide a cloud-init blob with some dummy password please
<jdstrand> so, we could detect this, bump everything down to PartialAppArmor
<zyga> and show me how to run this?
<zyga> jdstrand: I believe that we are failing on snap-confine
<jdstrand> and adjust snap-confine enough to not die
<zyga> the profile allows it to mkdir /run/snapd/lock
<zyga> but we cannot
<zyga> so plain partial would not work
<zyga> yeah
<zyga> that might work
<zyga> *might*
<zyga> I still don't understand the use of overlayfs and the intent to use snaps in that context fully
<jdstrand> zyga: yes, I'm assuming we could do something similar for it like with livecd. I'm worried about when snap-confine then runs and tries to launch stuff and all snaps die
 * jdstrand doesn't either
 * jdstrand goes back to k8s
<smoser> i updated bug with recreate instructions that are about as simple as possible.
<zyga> thank you
<pedronis> smoser: when were snaps added to those?  did they work and now they stopped? or just not yet tested in all the relevant situations?
<smoser> there are a lot of moving parts so its not easy to say.
<cachio> pstolowski|afk, which hotplugs do you need to simulate?
<smoser> but i suspect the key change that caused this to fail was the transition of lxd from being installed in the image as a debian package
<cachio> pstolowski|afk, insert usb?
<smoser> to being a pre-seeded snap
<smoser> that happened 10181002
<smoser> (https://bugs.launchpad.net/cloud-images/+bug/1796137)
<mup> Bug #1796137: huge and slow image 20181002 due to seeded lxd snap <cloud-images:Confirmed> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1796137>
<pedronis> smoser: I see, where snaps not really used until then?
<pedronis> anywy lxd is one of the most demanding snaps as well
<pedronis> in terms of moving parts
 * jdstrand notes that lxd is only shipped as a snap now
<smoser> snaps would have been used via user instalaltion or cloud-init '#snap' configuration.
<pedronis> jdstrand: I know, it still seems that some use case went untested
<smoser> but probably not in conjunction with overlayroot
<smoser> the key difference being use cases that did not involve snaps (such as vmtest or maas installation) worked fine
<smoser> but now use of the system is generally not possible as it never gets fully booted.
<smoser> in this overlayroot scenario
<pedronis> smoser: does mass installation need lxd? is that overlayroot situtation temporary, or something the machine then run with forever?
<smoser> temporary. maas installs in a overlayroot environment.
<smoser> then reboots into the installed environment.
<pedronis> but we have one image that now has a lxd snap
<pedronis> that we don't need
<pedronis> but tries to be seeded/do stuff ?
<pedronis> I mean don't need in that situation
<smoser> "one image" in that yes, one base image is used for many things.
<pedronis> smoser: are those snaps meant to carry over to the installed environment, or will there be a different boot where snapd is not seeded yet
<smoser> well, on first boot of the installed environment it will have exactly the same content as the image.
<smoser> so it will seed its own snap
<smoser> and will not have been booted with overlayroot
<pedronis> so the snapd seeding we get in overlayroot env is just unfortunate? it just happens but we don't need it?
<pedronis> smoser: I'm basically trying to understand if things need to work or just not explode, also it would seem this seeding is a waste (not that we have a clean way to turn it off afaik)
<pedronis> atm
<pedronis> zyga: we don't drop  connections on refreshes right? unless some plug/slot went away
<zyga> pedronis: correct
<smoser> seeding in the overlayroot environment is not needed currently.
<pedronis> zyga: mvo: maybe the cheapest thing is to somehow fail the sanity check in that env?
<smoser> if /snap is on a overlayroot, just disable snapd
<Chipaca> mvo: I'll be looking at using mksquashfs's exclude thing, unless you want to get your hands dirty with that
<Odd_Bloke> smoser: pedronis: zyga: FWIW, subiquity is a snap that, I think, is in a overlayroot environment and works.
<Odd_Bloke> So we need to be careful to not turn things off with a big hammer that breaks other use cases.
<pedronis> Odd_Bloke: intersting, I imagine it's a classic snap tough?
<Odd_Bloke> Yes, I believe it is.
<pedronis> yea, it is
<Odd_Bloke> But that does mean that snapd still needs to function in an overlayroot environment, so I don't think we can just disable it as suggested by smoser.
<mup> PR snapd#5968 closed: interfaces: updates for default, screen-inhibit-control, tpm, {hardware,system,network}-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5968>
<smoser> yeah, i' not sure how subiquity is working
<Odd_Bloke> It's classic, so it may just skip the AA stuff that's failing?
<smoser> fwiw, the ' cannot create lock directory /run/snapd/lock: Permission denied'
<smoser> is kind of misleading
<smoser> as
<smoser> $ ls -l /run | grep snap
<smoser> srw-rw-rw-  1 root root    0 Oct 11 17:52 snapd-snap.socket
<smoser> srw-rw-rw-  1 root root    0 Oct 11 17:52 snapd.socket
<smoser> $ ls -l /run/snapd
<smoser> ls: cannot access '/run/snapd': No such file or directory
<smoser> so  its not really that it can't create /run/snapd/lock its that /run/snapd does not exist.
<rharper> smoser: I created that
<rharper> before snapd starts and it still fails
<rharper> you can quickly test creating that dir before the snap install on bionic to confirm
<rharper> I had to use aacomplain on snap-confine to allow it to complete
<rharper> the trickery IIUC is that snapd has to transition the apparmor rules from /etc/apparmor.d to the verison present in the core snap;  the linked bug I found mentions this
<smoser> Odd_Bloke: do we have evidence that subiquity install works ?
<smoser> in cosmic
<Odd_Bloke> smoser: Good question.
<Odd_Bloke> vorlon: ^
<Odd_Bloke> I'm downloading the ISO ATM.
<mvo> pedronis, smoser just finished reading backlog - having a sanity.Check for this sounds indeed like a great option
<smoser> well, other than potentially meaning subiquity does not work
<mvo> smoser: yeah, I lied when I said I read backlog - I wasn't quite finished :/
<mvo> smoser: a shame, its a straightforward fix
<mvo> well "fix"
<Odd_Bloke> WTB 10G NICs on cdimage.u.c
<zyga> Iâm a bit AFK with the kids but I will resume working in this bug as soon as I can
<smoser> boot of http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/cosmic-live-server-amd64.iso
<smoser> seems to get to a place where i could isntall
<smoser> ie, i think subiquity is running
<smoser> and 'snap install hello && hello' works
<Odd_Bloke> hello is confined?
<Odd_Bloke> Yes.
<smoser> snap version and uname are the same between the two (comment 11 recreate and core image boot)
<smoser> err... subiquity boot
<vorlon> smoser, Odd_Bloke: subiquity absolutely works, every successful install w/ the server live image relies on subiquity as a snap
<smoser> so whats different?
<vorlon> classic vs non-classic snap?
<vorlon> I was aware that non-classic snaps don't work on overlayfs
<smoser> well, hello works in one and does not in the other.
<Odd_Bloke> Is lxd in the subiquity image?
<vorlon> how do you mean, "works in one"?
<vorlon> I haven't checked if lxd is in the subiquity image.  It should be.
<smoser> snap list in the subiquity image does *not* have lxd
<smoser> and i did mis-informa  bit.
<smoser> hello works subiquity image (snap install hello, hello)
<smoser> but fails to install (due to general brokenness) in cosmic
<smoser> but installs but fails to run in "boot bionic enable overlayroot reboot" case as described in comment 13
<vorlon> smoser: the subiquity image has code to prevent re-exec of snapd from the core snap
<vorlon> did you already handle that?
<smoser> i did what i showed in that comment.
<smoser> nothing else.
<vorlon> what comment?
<smoser> comment 13 on bug 1797218
<mup> Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1797218>
<vorlon> smoser: https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-server/includes.binary/overlay/lib/systemd/system/snapd.service.d/no-reexec.conf
<smoser> vorlon: http://paste.ubuntu.com/p/jJDvTgKzwd/
<smoser> thats bionic overlayroot -> tmpfs
<vorlon> smoser: ok.  that looks like the known incompatibility between non-classic snaps and overlayfs that we ran into previously.
<vorlon> I don't know why a 'snap install hello' would work on the subiquity image
<smoser> well.
<smoser>  http://paste.ubuntu.com/p/PGkK3bfRf9/
<vorlon> bionic?
<smoser> no
<smoser> that is cosmic
<smoser> were do writes go on installer environment ?
<vorlon> tmpfs
<smoser> ok. i was thinking that might be the difference.
<vorlon> cosmic is snapd 2.35.4+18.10; bionic-updates is snapd 2.34.2+18.04
<smoser> cosmic *image* (that fails entirely differently) is the same version as installer environment.
<vorlon> which is the cosmic image failure?
<smoser> as shown in description in 1797218
<vorlon> even if you set SNAP_REEXEC=0?
<smoser> i did not try that. i can quickly.
<smoser> well, it doesnt seem that reexec change fixes anything
<smoser> http://paste.ubuntu.com/p/6KB34MctXt/
<mvo> 5867 needs a second review
<mup> PR snapd#5970 opened:  snapstate: tweak GetFeatureFlagBool() to have a default argument  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5970>
<vorlon> smoser: is this in the ephemeral boot?
<vorlon> smoser: I mean, is it the ephemeral boot case being broken that caused you to care about this?
<smoser> what caused me to care about this is a green dot in jenkins going red.
<smoser> which is due to vmtest (curtin's test harness) starting to fail
<smoser> which does use overlayroot
<vorlon> smoser: workaround forming itself in my mind is for overlayroot package to disable the snapd service when overlayroot is in used
<vorlon> subiquity uses an overlayfs
<vorlon> but does not use overlayroot to implement that
<vorlon> so there'd be no impact to any of the places that snaps on overlayfs currently work
<smoser> i'd rather understand why.
<vorlon> sure
<smoser> and i'd also rather revert the thing that broke this
<vorlon> but I think the above workaround is something to keep in our back pocket
<smoser> than make other people change to accomodate
<vorlon> by which you mean, revert the move of lxd to a snap?
<smoser> yes
<mup> PR snapd#5971 opened: interfaces: include invalid type in Attr() error <Created by mvo5> <https://github.com/snapcore/snapd/pull/5971>
<zyga> re
 * zyga notices a bit of backlog
<cachio> sergiusens, hey, I see some tests related to plainbox failing on snapd sru http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd
<cachio> sergiusens, any idea if it could be an issue or it is a tests problem?
<mup> PR snapcraft#2341 closed: schema, meta: support app command-chain <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2341>
<mup> PR snapcraft#2343 opened: schema, meta: add "full" app adapter <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2343>
#snappy 2018-10-12
<sergiusens> cachio: that is a test that recently broke, joc can put you up to speed on that.
<cachio> sergiusens, great, thanks
<mup> PR snapcraft#2339 closed: lifecycle: switch to multipass by default <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2339>
<mup> PR snapcraft#2344 opened: schema: remove the deprecated snap keyword for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2344>
<mup> PR snapcraft#2345 opened: build providers: remove the qemu implementation <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2345>
<mup> PR snapd#5972 opened: tests: initial setup for testing current branch on nested vm and hotplug management <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5972>
<zyga> good morning
<mvo> good morning! 5867 needs a second review
<mborzecki> morning
<mvo> hey mborzecki
<mvo> mborzecki: if you have a moment, a second review for 5867  would be great
<mborzecki> mvo: looking
<mborzecki> mvo: left a comment there
<pstolowski> heyas
<mborzecki> pstolowski: hey
<mvo> hey pstolowski ! good morning
<mup> PR snapd#5913 closed:  daemon: expose snapshots to the API <Snapshots ð¸ó > <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5913>
<mup> PR snapd#5879 closed: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5879>
<Chipaca> morning
<Chipaca> who was it that said something about everything being green, yesterday
<Chipaca> you've doomed us all
<mborzecki> heh ;)
<zyga> Hey
<zyga> (again)
<zyga> Sorry I sent kids to school and overslept again if that is a thing
<zyga> Iâll be down shortly
<Chipaca> WRT "Sorry I sent the kids to school", homeschooling sucks tho
<lool> ogra: how long to land the kernel patch in source and a kernel deb and a kernel snap?  :-)
<pstolowski> mvo: hey, wrt to hooks optimization from yesterday, hijacking seems to be the only painpoint. the problem is this: in ifacestate.Connect() i know which hooks exist based on snapinfo.Hooks (it has all hooks defined explicitely and also those not defined but present on the disk in meta/hooks). but hijacked ones (core - configure only?) are exceptional as (afaiu) they don't have to be listed in snap yaml (and they have no
<pstolowski> file on the disk). ideally i'd just ask hookmgr if a (snap, hook) IsHijacked, but we don't have access to hookmgr there. any thoughts on this? there would be no issue if we required hijacked hook to be explicitely listed in the snap yaml.
<Chipaca> ohhh, nice, there's a spread test that hasn't been working for who-knows-how-long and we didn't know because pipefail :-(
<mvo> Chipaca: *gar* we should simply kill pipefail again
<mvo> Chipaca: I think it trades one horror for another
 * Chipaca looks at mvo
<Chipaca> mvo: yes, yes it does
<Chipaca> mvo: my looking at you was because I was looking at 'git log -p' for the test in case
<Chipaca> mvo: you should feel guilty
<mborzecki> Chipaca: which one?
<Chipaca> nothing serious :)
<mvo> pstolowski: hm - I need to look but if adding the one hijack we have to meta/snap.yaml for core that seems ok
<mvo> Chipaca: which oneÃ
<Chipaca> still, let me guilt some cake out of mvo
<mvo> Chipaca: ?
<Chipaca> mvo: tests/main/help/task.yaml
<mvo> Chipaca: guilt is my default emotion
<Chipaca> mvo: grep -e and grep -E are *not the same thing*
<pstolowski> mvo: but how about reverts?
<mvo> Chipaca: *cough* indeed - this looks like you reviewed this though ;) I usually write '(foo|bar)'
<Chipaca> mvo: and in particular, grep -evFx 'foo|bar' will always fail because the pattern is now vFx and 'foo|bar' the file to search for
<Chipaca> mvo: yep, i missed this too
<Chipaca> mvo: but what's the fun in blaming myself when I can blame somebody kilometers away
<mvo> Chipaca: :( what an annoying bug
<mvo> Chipaca: haha
<Chipaca> anyway, nothing serious, i'll just be removing the test entirely soon :-)
<Chipaca> (because I know how to do this in static tests now :-) )
<mvo> Chipaca: shame that its review friday or we could just push a pr that removes pipefail again
<Chipaca> mvo: i think we've already removed pipefail, otherwise this would've failed?
<mvo> Chipaca: oh, ok
<Chipaca> but, yeah no, pipefail is just choosing one bag of bugs over another
<mvo> Chipaca: I thought you discovered while looking at it
<mvo> Chipaca: anyway, I get back to core18
<Chipaca> nah, while looking at running it 'by hand' for a static check
<Chipaca> mvo: enjoy your eighteen cores
<Chipaca> sergiusens: do you have tests for packing things with weird exclusion lists?
<dot-tobias> I'm having trouble installing snapcraft or git through apt in the classic snap on Core stable. âE: Sub-process /usr/bin/dpkg returned an error code (1)â â Does someone have a hint how I can fix that?
<mup> PR core18#82 opened: hooks: use hkp:// to fetch the key from the keyserver <Created by mvo5> <https://github.com/snapcore/core18/pull/82>
<ogra> lool, thats a ppisati question, he said he'd put it nxt on his TOOD
<ogra> *next
<lool> ogra: Hmm ok, should we put a workaround in place?
<lool> I realize we have been without a 3b+ compatible image since Jan/Feb, but I'm keen to wrap up this effort, especially since UC18 is coming soon
<pedronis> mvo: pstolowski: hijacking exists for core configure only, pstolowski are you doing your change in hookstate, and just for interface hooks?
<pedronis> *and not just
<dot-tobias> (re my own question five minutes ago): seems like this error line: âupdate-alternatives: error: error creating symbolic link '/etc/alternatives/jsonschema.dpkg-tmp': No such file or directoryâ is the root cause; once I've created /etc/alternatives everything works fine
<pedronis> pstolowski: we run configure even before we have the core
<pedronis> so we cannot depend on it being there in the meta yaml
<pedronis> by definition
<sil2100> mvo: thanks for the PRs for console-conf! I'll release them into the PPA in some moments
<mvo> sil2100: I have one more pending
<pedronis> pstolowski: we need to do snap set system before we have core
<pstolowski> pedronis: no, i'm doing it in ifacestate.Connect only for interface hooks. i know hijacking is for core configure only, but it's kinda 'open-ended' and made extensible
<mvo> sil2100: testing it right now
<pedronis> pstolowski: we cannot make it mandatory to have it in meta.yaml anyway
<pedronis> pstolowski: it's designed exactly to work even before the snap there
<pstolowski> pedronis: i see
<pedronis> pstolowski: honestly if you are changing ifacestate, I would ignore the problem for now
<mvo> mborzecki: hm, I just go "error: internal error: unsupported download with instance name "/home/mvo/devel/snaps/core18/core18_18_amd64.snap"" from ubuntu image - that looks like a recent change, no?
<pstolowski> pedronis: i could naively make an exception for core configure in ifacestate, but that would circumvent hijacking (which in the future can have more hijacked stuff, at least in theoyr)
<ogra> lool, well, honestly .... i wouldnt have held back on this issue but the test lab wil not be able to manage when their IPs change, i dont think its a biggie and it will be easily fixed with a kernel update
<ogra> and image with a known issue is still better than no image at all ... any workarounds would be rather hackish
<ogra> *and an
<pedronis> pstolowski: I don't understand how configure relates to ifacestate
<pedronis> I'm getting a bit lost
<mborzecki> mvo: what was the command?
<mborzecki> mvo: ah it was from ubuntu image
<lool> ogra: I was thinking u-boot var to override mac address, perhaps via cmdline/initrd
<pstolowski> pedronis: ifacestate.Connect() with my change will only create HookTask if it sees given hook. and if it doesn't create task for core configure, then hijacking will not even have a chance to run
<lool> but yeah, I agree it's hackish
<mvo> mborzecki: yes, via --extra-snaps
<lool> ogra: alright, let's fix it cleanly and take the time
<ogra> lool, well, that first needs an initrd hack to make use of that uboot var
<Chipaca> mvo: ogra: who "owns" the classic snap?
<pedronis> pstolowski: what's the relation between ifacestate.Connect and core configure ?
<pedronis> core configure is not an interface hooks
<pedronis> pstolowski: I'm missing something here
<ogra> Chipaca, theoretically mvo and me i guess
<mborzecki> mvo: that's weird, it's like it's calling Download(/home/mvo/....core18_18_amd64.snap)
<pstolowski> pedronis: aaah, you're right, silly me
<pstolowski> of course
<Chipaca> ogra: mvo: dunno if you read dot-tobias's report above, but it looks like we've broken it recently with /etc/alternatives shenanigans
<mvo> Chipaca: uh
<ogra> Chipaca, i used it yeterday ... i that core 16 ?
<pstolowski> pedronis: so yeah, it's theoretical problem anyway in case of future hijacked hooks
<ogra> +s
<Chipaca> ogra: did you use it to install something that tried to write to /etc/alternatives?
<pedronis> pstolowski: I don't think we need to solve it now, anyway as I said given the nature of hijack
<pstolowski> (i got carried away with configure hook because of that)
<pedronis> expecting it to be in the yaml
<ogra> nah, just to build a snap with snapcraft
<mvo> dot-tobias: thanks for the report! we will fix it soon
<pedronis> would not be a solution
<ogra> did we change alternatives handling in core 16 ? i thought that was an 18 thing
<mvo> mborzecki: aha - nevermind, its not validation its just a stupid error message
<mvo> mborzecki: typo in the path
<mvo> mborzecki: so it does stat() fails -> tries to download
<mvo> mborzecki: which is silly, if it looks like a path it should give a useful error. sorry for the noise
<mborzecki> mvo: right, we could produce more useful error in image.go:acquireSnap()
<mborzecki> mvo: in case the snap ends with .snap
<mvo> mborzecki: yeah, not high priority but definitely a good improvement
<mborzecki> mvo: also funny cause it would actually poke the store to get that snap? :)
<mborzecki> (if it wasn't for that instance name check)
<mvo> mborzecki: yeah
<dot-tobias> mvo, ogra: I just double-checked, the error occurs on a raspi 3B with core 16-2.35.2 stable (rev 5546) and classic snap 16.04 rev 26 (edge)
<dot-tobias> (/etc/alternatives thing with apt install)
<Chipaca> dot-tobias: and this was trying to install what?
<dot-tobias> Chipaca: Tried installing git and snapcraft (independently)
<mup> PR snapd#5944 closed: cmd/snap: speed up unit tests <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5944>
<ogra> weird, i did the same just yesterday
<ogra> on a dragoboard though but that shouldnt matter
<mborzecki> Chipaca: left some comments in #5955 and #5957
<mup> PR #5955:  cmd/snap, tests: snapshots for all <Snapshots ð¸ó > <â Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
<mup> PR #5957: overlord/snapshotstate/backend: fall back on sudo when no runuser <Snapshots ð¸ó > <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
<Chipaca> mborzecki: yep, just reading
<Chipaca> mborzecki: when you say "list" i'm assuming you menan "list-snapshots" or some such?
<mborzecki> yes
<Chipaca> mborzecki: note "saved" was not my decision, but was arrived at after much discussion
<mborzecki> ahh ok, so then it
<Chipaca> same for all of the commands in there, actually
<mborzecki> 's ok for me
<Chipaca> onlu one I winged was check
<Chipaca> only*
<mborzecki> Chipaca: maybe we could make that check help message more friendly
<Chipaca> mborzecki: Â«check-snapshot tells you if your ð¸ó  is actually a ðÂ»?
 * Chipaca runs
<mborzecki> eggplant?
<Chipaca> vegetable
<mborzecki> haha
<Chipaca> mborzecki: https://www.dictionary.com/e/emoji/eggplant-emoji/
<mborzecki> well, hashsums feels brutalist :)
<mborzecki> wow, that's one interesting emoji
<Chipaca> hehe
<mborzecki> mvo: the logs are here https://forum.snapcraft.io/t/snapd-not-responding/7867/6
<mborzecki> hm should failure in catalog refresh be fatal?
<mborzecki> nvm, the errors are only logged, the machine is rebooting though
<mvo> mborzecki: hm, hm, the logs are not exactly telling much :(
<mvo> mborzecki: I guess we need grub-editenv list next to see if something strange in our boot config is happening
<mvo> mborzecki: but it might be something external rebooting, like a broken watchdog or something
 * mvo scratches head
<zyga> mvo: systemd knows why the system rebooted
 * zyga tires to remember how
<mborzecki> zyga: journalctl -b -1 ?
<zyga> I think there was something deeper
<zyga> perhaps it was not systemd but UEFI
<zyga> AFAIK the boot reason is stored for user space to know
<zyga> but starting with the last boot log would be useful
<mvo> zyga: did scott get back to you last night about the overlay issue btw?
<mvo> zyga: I wonder what the status here is and if we need some last minute fixes
<zyga> mvo: I read the backlog
<zyga> and I have the data to reproduce this
<zyga> I think it is problematic, we were not expecting this use case
<zyga> give me a moment
<zyga> woah!
<zyga> I managed to install a snap
<zyga> after installing core
<zyga> but then core install failed
<zyga> and I got a snap without core
 * zyga collects changes
<zyga> http://paste.ubuntu.com/p/q7pNPtJKNH/
<zyga> mvo: the system is using overlayfs
<zyga> mvo: AppArmor service is active (despite some logic that disables it when / is overlayfs, the logic doesn't trigger in this case because the backing directory is different,
<zyga> snapd detects the overlay and injects a special profile for snap-confine
<zyga> but that profile is probably not active, we did not reload the profile of the system-loaded snap-confine (the one in /etc, not from the core reexec)
<pedronis> mvo: one of the conclusion was that they don't actually need snapd to work
<pedronis> in that context
<pedronis> indeeed is a bit of waste of snapd to seed there
<zyga> I think there is a real bug still
<pedronis> but they have use case with overlayfs that need to work to some extent
<pedronis> zyga: it's ok, I just expected them to then lament that we made seeding work but then boot there is slow :)
<zyga> heh :)
<pedronis> I mean fixing bug is orthogonal to turning off snapd there anyway
<mvo> pedronis: aha, thank you
<zyga> interestingly, in the scenario today we do not reexec
<zyga> because 18.10 is ahead of stable
<zyga> that probably compounds the bug I mentioned
<zyga> but something more is fishy, hold on
<zyga> aha
<pedronis> mvo: I think last words sounded like they could probably work around things on their side by disbaling snapd.service completely there
<pedronis> that sounded what steve was proposing
<zyga> we grant permission: "/media/root-rw/overlay/{,**/}" r,
<zyga> and the denial is: "/overlay/" r,
<mup> PR snapd#5973 opened: image: improve validation of extra snaps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5973>
<zyga> I suspect the paths differ because of something that was done in intrd
<mborzecki> mvo: this should catch the typos and invalid names ^^
<mvo> mborzecki: nice
<zyga> mvo: we can detect and add a hack
<zyga> with that changed I can install and run a simple snap
<zyga> trying to install lxd now
<zyga> trying to use lxd for whatever
<zyga> mvo: lxd doesn't work because it cannot setup networking
<zyga> failed to list ipv4 rules for LXD network lxdbr0 (table filter)
<zyga> there are no more denials
<zyga> so perhaps missing module or something like that
<zyga> anyway, I think that we can fix the immediate issue they saw with a one liner hack
<zyga> but it's not something I'm very proud of
<zyga> mvo: let me prepare a patch, you can decide
<mvo> zyga: ta
<mvo> and 5971 needs a review
<Chipaca> mvo: i retried 5971 ~5 times last night
<Chipaca> fyi
<mvo> Chipaca: meh, that sounds nasty
<mvo> Chipaca: failures all over the place? or some pattern?
<mvo> things look very red in general right now :/
<Chipaca> mvo: no discernible pattern
<zyga> mvo: what is the magic LP:# syntax that is picked up by gnome-terminal
<zyga> for launchpad bug references
<Chipaca> wat
<mvo> zyga: in changelogs we use LP:#1234
<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>
<zyga> thanks!
<cjwatson> missing a space there
<mvo> zyga: *but* gnome-termainal I'm not sure
<mvo> cjwatson: aha, thanks (^- zyga)
<cjwatson> LP: #1234
<cjwatson> https://help.launchpad.net/Code/Git#Linking_to_bugs has the regex
<mvo> ta!
<zyga> hmm
 * zyga found more weirdness
<zyga> but anyway
<zyga> patch incoming
<zyga> mvo: I think there will be two patches, one is ready, the other one may be needed to trigger regular snap-confine profile reload
<zyga> we don't have code for that, do we?
<zyga> plus this will go south if someone notices and fixes the apparmor.service unit not to start
<mvo> zyga: hm, hm
<mup> PR snapd#5974 opened: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <https://github.com/snapcore/snapd/pull/5974>
<zyga> mvo: ^
<zyga> mvo: I also updated the bug report
<zyga> I will check the other part of this issue now
<mvo> ta
<zyga> mvo: ok, I looked
<mup> PR snapd#5975 opened: ifacestate/hooks: only create interface hook tasks if hooks exist <Created by stolowski> <https://github.com/snapcore/snapd/pull/5975>
<zyga> we are good, we do reload profiles
<pstolowski> mvo, zyga, pedronis ^
<mvo> pstolowski: thanks
<mvo> ha! 5971 is green - now it just needs reviews :)
<pstolowski> mvo: i'm curious how it improves situation
<niemeyer> mvo: Minor suggestion for the message on #5971 and LGTM
<mup> PR #5971: interfaces: include invalid type in Attr error <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5971>
<mvo> niemeyer: thank you!
<mup> PR snapd#5739 closed: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5739>
<mup> PR snapd#5867 closed: many: enable layouts by default <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5867>
<zyga> \o/
<Chipaca> mvo: question for you sir: is there anything using .snapignore that you know of?
<mup> PR snapd#5971 closed: interfaces: include invalid type in Attr error <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5971>
<mvo> Chipaca: I don't know
<Chipaca> :+1:
<Chipaca> :)
<mvo> Chipaca: is it supported by snapcraft too?
<mvo> Chipaca: or just by us?
<Chipaca> mvo: no
<mvo> Chipaca: ok, then I think its fine to kill it
<Chipaca> mvo: it's from 2015
<mvo> Chipaca: its cargo cult from click
<Chipaca> yep
<Chipaca> mvo: and what about the exclusion of DEBIAN/?
<Chipaca> sounds weird also
<mvo> Chipaca: same I would say
<Chipaca> mvo: maybe we don't need exclusions at all :-)
<mvo> Chipaca: killemall
<mvo> Chipaca: haha
<mvo> Chipaca: really?
<mvo> Chipaca: are those the only patterns? we are an inclusive bunch
<Chipaca> mvo: well, snapcraft very carefully builds the thing
<Chipaca> mvo: nah, we have a bunhc
<Chipaca> bunch
<mvo> good point
<mup> PR snapcraft#2345 closed: build providers: remove the qemu implementation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2345>
<mup> PR core18#82 closed: hooks: use hkp:// to fetch the key from the keyserver <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/82>
<zyga> pstolowski: reviewed the hooks PR
<mborzecki> zyga: wonder if we could improve detection of snap mount dir in snapd, say what if we could ask snap-confine for the right path (i.e. the path it was configured with)?
<zyga> mborzecki: I would actually do it backwards
<zyga> mborzecki: have snapd tell snap-confine
<pstolowski> zyga: thanks! looking
<zyga> and have the entire logic in dirs.go in one place
<zyga> mborzecki: it's not supposed to be a new PR Friday but I have a PR that removes the directory configure option from snap-confine that I mentioned a few times
<mborzecki> zyga: yeah, one source of truth would be nice
<zyga> one source of facts ;-)
<mborzecki> zyga: as for no-new-PRs, I opened one :P although a simple one
<zyga> mborzecki: let's explore this on monday
<zyga> and devote this day to important fixes and reviews
<zyga> mvo: have you seen the overlay PR:?
<ppisati> ogra: we already have facilities to set the mac address from DT: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?h=raspi2&id=d093067d07ffba9f50d38a2e572f7ddbd36daf5a
<ppisati> ogra: check drivers/of/of_net.c::of_get_mac_address
<ppisati> ogra: it's the same stuff as the other patch
<ppisati> ogra: oh, same for LEDs
<ppisati> ogra: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?h=raspi2&id=1ad73f268cedf4a7999fabf9aecb77e0f0cd3c00
<pstolowski> zyga: replied
<zyga> yep, I see
<jdstrand> mvo: hi! as you probably saw in the email, I didn't finish the k8s interfaces, but I could today. I just have a couple of open questions I can discuss with niemeyer to clean things up for the review
<zyga> jdstrand: hey
<jdstrand> niemeyer: hi! do you have a few minutes to discuss some kubernetes interfaces?
<jdstrand> that I'm working on
<jdstrand> niemeyer: I have 3 questions
<jdstrand> hey zyga :)
<zyga> jdstrand: can you look at https://github.com/snapcore/snapd/pull/5974
<mup> PR #5974: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <https://github.com/snapcore/snapd/pull/5974>
<zyga> it's very short, just tell me what you thibnk
<jdstrand> zyga: what does mountinfo say about this system?
<zyga> jdstrand: the test I added shows the mountinfo data exactly from the affected system
<zyga> and I still have it booted if you have any questions
<jdstrand> zyga: that shows a single entry, yes, but are there multiple?
<zyga> multiple overlayfs-es?
<jdstrand> eg, maybe there are layered overlayfs
<zyga> no, there's only one
<zyga> let me pastebin the whole file
<zyga> http://paste.ubuntu.com/p/6kgSyPjJGG/
<zyga> I have to "paste" the URL by hand because $reasons
<mborzecki> when a snap has sockets or timers, snapctl stop <snap> only stops the service, but not the sockets nor timers, then #5777 addresses that, but when snapctl start is issued it starts sockets, timers and the service :/
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<zyga> mborzecki: I'm more re-affirmed that we should expose the full set of services, sockets and timers inside the snap and not outside
<zyga> mborzecki: and on the outside, only expose "knobs" that are arbitrary subsets of the real set
<zyga> mborzecki: that are defined by the snap developer
<mborzecki> zyga: well, atm you cant really disable a socket or a timer from inside the snap
<mborzecki> idk feels like we're missing something or trying to hide too much
<zyga> I agree
<jdstrand> zyga: you are supposed to end up with this rule: '"###UPPERDIR###/{,**/}" r,' which becomes '"/overlay/{,**/}" r,'
<jdstrand> zyga: which should cover '/overlay/'
<zyga> right
<zyga> jdstrand: am I missing something/
<jdstrand> zyga: oh, you are saying that you fixed *that*
<zyga> yes
<zyga> :D
<jdstrand> I thought you were saying that still remained
<zyga> no no, it's working with this patch
<zyga> but I cannot explain the behaviour of the kernel
<jdstrand> ok, well the overlayroot thing is doing a pivot_root or something
<zyga> hmmm, I'm not sure it does
<zyga> but it may
<zyga> but ...
<zyga> the upper and lower paths are still available
<zyga> I mean, /media/... all of that exists and shows the real stuff
<zyga> btw
<zyga> I noticed something odd, look at the path of the workdir
<zyga> yes, it ends with _
<zyga> why?
<ogra> ppisati, well, then i dont get why it does not work ... does the code actually use "local-mac-address" from the DT ?
<jdstrand> I was wondering about that too. but that is setup by whatever did the mount
<jdstrand> well, typically
<zyga> yep
<ogra> ppisati, because thats where it is in the DT
<jdstrand> maybe the kernel changed
<jdstrand> zyga: what package is used to setup the mount?
<zyga> I don't know but there is /etc/overlayroot.local.conf
<zyga> let me look
<zyga> looks like overlayroot
<mvo> jdstrand: yeah, saw it but no worries, if its isolted we can cherry pick it later
<zyga> jdstrand: cloud-initramfs-tools
<ijohnson> mborzecki: what do you think I should do with #5777 ? I haven't gotten a chance to add tests, but from the forum it seemed unclear that everyone was on board with `snap stop <service>` always also stopping the associated sockets/timers, which is what I implemented
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<jdstrand> ah, cloud-initramfs-tools
<zyga> jdstrand: reading that now
<zyga> god how I hate shell
<jdstrand> # PERSIST_DIR will persist after pivot-root
<zyga> miles of shell in initrd
<jdstrand> so, something is doing that
<zyga> yeah
<zyga> but it is set to /run/initramfs
<jdstrand> that's good enough for me to explain the directory
<jdstrand> that dir, yes
<jdstrand> the point is, its talking about the initramfs pivot, etc
<Chipaca> zyga: is your lab & mac available for some poking?
<zyga> Chipaca: sure
<Chipaca> zyga: ok thanks
<Chipaca> zyga: ssh: Could not resolve hostname imac-pro-zygmunt.local: Name or service not known
<zyga> ah, I think I tried to fix the hostname
<zyga> one sec
<Chipaca> heh
<zyga> moved from wired to wifi
<zyga> try ipro-zygmunt.local please
<Chipaca> better
<zyga> I renamed it because while I had both connections macOS would rename the hostname to unclash it with itself
<zyga> jdstrand: so how do you feel about the PR
<zyga> I think nothing short of teaching apparmor about pivot root will break this
<zyga> but if that happens all hell will break loose
<zyga> (we'll notice)
<jdstrand> ah, the man page talks about overlayroot doing a chroot
<jdstrand> zyga: I like the pr fine. I don't like why we don't know why the path is what it is
<zyga> brb, the dog is telling me it's time to go
<zyga> jdstrand: grepping for pivot_root in the package yields nothing
<zyga> jdstrand: but chroot *is* used
<zyga> jdstrand: btw, I looked at /proc/self/root and it was /
<zyga> is that expected if a chroot happened?
<zyga> (I'll reply from the phone)
<jdstrand> yes, and with chroot, you'll see the beginning of the path for the chroot (ie, the chroot directory is known to apparmor)
<zyga> Another question is why this happens here and not on the live cd
<zyga> Is it just a coincidence that it works on the live cd?
<zyga> About chroot, so are you saying that since I saw / and not some longer path then chroot did not happen?
<jdstrand> zyga: I'm saying that a) I didn't read or trace the whole source to figure out exactly what is happening but that b) we know it is using a combination of overlay and chroot (as opposed to overlay and pivot_root)
<jdstrand> zyga: so I responded to the PR with that in mind
<jdstrand> zyga: in summary, I approved it, but please adjust the comment
<zyga> Ack
<zyga> Thank you
<mup> PR snapd#5976 opened: interfaces: improve Attr error further <Created by mvo5> <https://github.com/snapcore/snapd/pull/5976>
<jdstrand> niemeyer: can you ping me when you have a couple of minutes, I don't want to just fire of the questions with no context
<jdstrand> off*
<mup> PR snapd#5973 closed: image: improve validation of extra snaps <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5973>
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: I have a few meetings back to back now, but later in the afternoon it's open.. happy to chat
<jdstrand> niemeyer: hi!
<jdstrand> niemeyer: I think this should be quick
<jdstrand> niemeyer: the context is that we want interfaces to support k8s worker nodes
<jdstrand> niemeyer: and this is defined as kubelet and kubeproxy
<jdstrand> niemeyer: which are two different daemons
<jdstrand> niemeyer: so I have 2 interfaces, currently named k8s-kubelet and k8s-kubeproxy. I think that should change
<jdstrand> niemeyer: to use -support at least. eg, k8s-kubelet-support or just kubelet-support
<jdstrand> probably the latter
<jdstrand> thoughts?
<jdstrand> (and of course, kubeproxy-support (or whatever))
<jdstrand> niemeyer: these are similar to other -support interfaces in that we are granting special things that only these need
<mup> PR snapd#5977 opened: release: 2.36~pre2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5977>
<mup> PR snapd#5947 closed: many: cleanup remaining parallel installs TODOs <Parallel installs â> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5947>
<popey> On a clean core install, if you snap refresh it reboots twice. One for core, one for kernel. Why doesn't it bundle them in one boot?
<ogra> popey, never heppened to me ... weird
<ogra> *happened
<popey> might be pilot error
<ppisati> ogra: uhm, ok
<ppisati> ogra: let me dig in
<ogra> ppisati, i definitely see the MAC changing in the running system but i also see the MAC fixed in the DT ... so something isnt properly picked up
<ppisati> ogra: do you get a random MAC at every reboot?
<ogra> ppisati, yes ... ifconfig shows a different one every boot ...
<ogra> the devicetree has the same one in "local-mac-address" though
<ogra> (the same non-changing one that is ... differing from ifconfig output)
<ppisati> ogra: ok
<smoser> zyga: i think i root-cause diagnosed that bug. commented on your pull request.
<zyga> smoser: looking
<smoser> sorry for the bikeshed conversation with jdstrand (i hadn't noticed he'd commented there) on the code comments :)
<smoser> but i do think it better to mention the 'overlayroot' package than "Ubuntu server 18.10"
 * pstolowski late lunch
<roadmr> zyga: time to try that snap upload that was giving you trouble - the required version of reviewer tools is now in the store
<jdstrand> smoser: the overlayroot man page and scripts specically say they used chroot. if pivot_root was used, I would expect the directory to be '/', not '/overlay/' in the apparmor denial. regardless. the comment can be further generalized. the code was never meant to be completely generalized for any overlay situation
<zyga> roadmr: thanks, I will try now
<zyga> I tried earlier today without success
<zyga> smoser: looking at the source of the package I was unable to find the use of pivot_root but I did see chroot
<jdstrand> smoser: but rather only meant to handle specific situations where we know snaps are being run in a overlayfs situation. we need better apparmor/overlay support in the kernel to be better
<mvo> cachio: I triggered the 2.36~pre2 core build, should be in edge ~1h
<smoser> jdstrand: overlayroot is a "normal" initramfs hook. it sets up some mounts and then lets initramfs do its normal pivot and exec of /sbin/init
<mvo> (max)
<zyga> smoser: ah, I see, this explains it then
<zyga> and is in sync with the pivot_root behaviour of apparmor
<jdstrand> well except that upperdir is showing up as /overlay/ somehow with apparmor
<jdstrand> I don't know the overlyroot and initramfs stuff well enough to explain why it is happening that way
<smoser> jdstrand: did you read my comment ?
<jdstrand> I did
<niemeyer> jdstrand: +1 to dropping the k8s- prefix
<smoser> the code just should not assume that the first field '/cow' in casper
<smoser> means anything
<niemeyer> jdstrand: Are their needs different enough to justify the two interfaces, or would it be worth exploring the potential for a single one?
<jdstrand> smoser: as mentioned, this code can't be generalized without better apparmor/overlay support in the kernel
<smoser> rather it needs to parse /proc/mounts in reverse order to find the second field that matches.
<smoser> it can be generalized for at least these 2 cases.
<smoser> but yes, i do understand that apparmor and overlayfs aren't the best of friends.
<jdstrand> niemeyer: ok, well, there is an existing kubernetes-support interface, but it is ancient and nothing uses it
<jdstrand> niemeyer: jcastro (yes, that ancient) was super jazzed about k8s as a snap so I through something together for comment and then never heard anything back
<niemeyer> jdstrand: But are they mostly the same?
<jdstrand> niemeyer: they is significant overlap, yes. the old kubernetes-support has overlap with docker-support too though
<jdstrand> s/is//
<cachio> mvo, nice
<jdstrand> niemeyer: see https://github.com/snapcore/snapd/compare/master...jdstrand:k8s-worker-interfaces?expand=1
<jdstrand> niemeyer: but kubelet needs more than kubeproxy
<jdstrand> niemeyer: and kubelet needs a lot
<jdstrand> niemeyer: specifically, kubelet needs to do mounts into the container, but kubeproxy does not
<niemeyer> I see
<jdstrand> niemeyer: so it would be nice if kubeproxy didn't have those accesses
<jdstrand> niemeyer: we could have attributes for flavors of a single interface
<jdstrand> which achieves the desired security properties, but isn't as transparent to the user of the system
<niemeyer> jdstrand: +1
<jdstrand> ok, I'll refact to use attributes
<jdstrand> refactor
<niemeyer> jdstrand: If we have nothing using kubernetes-support, we should probably kill it
<jdstrand> niemeyer: well, or, I could just use it with attributes :)
<jdstrand> pedronis: can you do a store search to see if anything is using the kubernetes-support interface?
<jdstrand> niemeyer: I'll work through those details, but I have another interesting question
<pedronis> jdstrand: in a meeting, I can in a bit
<jdstrand> niemeyer: so, you may recall the probelsm with ptrace
<jdstrand> pedronis: thanks
<niemeyer> jdstrand: Meeting rolling too, but feel free to go ahead and I'll reply once I'm off
<jdstrand> niemeyer: specifically, the kernel triggers a ptrace (trace) denial in situations when an application is not actually trying to attach and read its memory/etc
<jdstrand> niemeyer: eg, certain invocations of 'ps' will cause ptrace denials
<jdstrand> niemeyer: that use of ptrace is harmless enough, but we can't tease out the difference in policy between that and a full on gdb-style "I'm taking you over" ptrace
<jdstrand> niemeyer: because the kernel doesn't give us the info to do that (it is kinda similar to how SYS_ADMIN is a catchall for a lot of things. 'trace' groups unrelated things together
<jdstrand> )
<jdstrand> niemeyer: ok, so, we need to allow 'ps' in, say, system-observe (that is the point of the interface), but we don't ptrace (trace) of unconfined, etc, etc because that would constitute a sandbox escape
<jdstrand> niemeyer: all of the above is context for the fact that we have 'deny ptrace (trace)' rules sprinkled in a couple interfaces to cut down on ridiculously verbose logged denials, but allow the use of something like 'ps' (ps will trigger the denial but work fine otherwise)
<mup> PR snapd#5777 closed: wrappers/services.go: don't start disabled services <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<jdstrand> niemeyer: *but* k8s actually needs 'ptrace (trace)' to function. because you can't undo a deny rule, the k8s worker can't (currently) specify 'plugs: [ system-observe ]'
<mup> PR snapd#5970 closed:  snapstate: tweak GetFeatureFlagBool() to have a default argument  <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5970>
<jdstrand> niemeyer: which brings me to my point: I'd like for the worker to user standard interfaces like system-observe, network-control, etc rather than copying stuff from those into the k8s interface to avoid the deny rule
<Chipaca> mvo: I remembered what I was going to say in the standup and then forgot
<jdstrand> niemeyer: but wanted you opinion on how to do it. the option I'm currently liking is that system-observe, network-control, etc have the same default behavior, but we add an interface attribute (eg, 'omit-ptrace-deny: true') which, when specified, simply skips adding those rules to the policy
<Chipaca> mvo: cachio: starting with 2.36 I'd like to add a new step to the release checklist; how do I go about doing that?
<jdstrand> niemeyer: in these specific cases, that's ok security wise, because we are default deny and the access is still block by the interface. but it allows another interface to be used in conjunction with it
<jdstrand> niemeyer: another route is not expose it to the snap developer and instead simply reuse the rules unconditionally in the k8s interface
<jdstrand> niemeyer: but don't pull in the ptrace rules. eg, system-observe internally has systemObserveConnectedPlugAppArmor, so we might break that into systemObserveConnectedPlugAppArmor and systemObserveConnectedPlugAppArmorDenyPtrace. then in kubernetes-support it adds systemObserveConnectedPlugAppArmor to its policy
<jdstrand> niemeyer: so it would get all of it by simply using 'plugs: [ kubernetes-support ]'
<jdstrand> niemeyer: a 3rd option is trying to work out a new 'ptrace' or two, but I don't quite know what that would look like
<jdstrand> niemeyer: a new 'ptrace' interface*
<jdstrand> niemeyer: I don't really want to pursue that last option now-- it is roadmapped (not product roadmapped, mind you) as something to look into in the future
<jdstrand> niemeyer: ..
<zyga> smoser: about parsing proc/mounts, we do parse it and in the right order too
<zyga> smoser: it's just that according to the kernel the upperdir is different
<zyga> smoser: this is probably because of pivot_root
<zyga> smoser: so unless I misunderstood something there is nothing that we can do better
<zyga> smoser: please do correct me if I'm wrong, I can show you what we do today in the code if that helps
<zyga> (actually, we don't iterate over the mount entries in reverse order, that's an omission on my part)
<zyga> smoser: the logic is on https://github.com/snapcore/snapd/blob/master/osutil/overlay_linux.go#L27
<rharper> zyga: why does apparmor not see the same mount path as present in the mountinfo ?
<zyga>  rharper I believe this is a kernel question that only jjohansen can answer
<zyga> rharper: but in general apparmor doesn't "see" pivot root
<zyga> so if you setup a profile with some paths
<zyga> then pivot root
<zyga> the profile is not changed
<niemeyer> jdstrand: I see.. hmmmm
<rharper> zyga: interesting
<zyga> and applies to the paths as they are
<zyga> rharper: what is more interesting IMO
<zyga> is that mountinfo doesn't reflect this either
<zyga> so if you mount something like overlayfs
<zyga> and pivot_root
<zyga> the paths lie
<niemeyer> jdstrand: The attribute feels too much like a hack for very difficult to understand reasons, for a person that isn't developing snapd
<zyga> they may or may not be representable in the new root
<zyga> but the kernel just says "those are the paths"
<zyga> where in other places it actually hints at the fact they are no longer there
<zyga> just not in this case
<zyga> rharper: in the ephemeral Maas image case the kernel really says "overlayfs is mounted there and those are the options"
<zyga> but it doesn't render the mount options with the relation of the current root
<zyga> it just seems to say what they were at the time mount happened
<rharper> zyga: it seems fine for pivot_root to close of some mounts if they're not available under the new root; but why can other things "See" the old paths ?
<zyga> rharper: this is unusual in the sense that other parts of mountinfo are always rendered from the perspective of the observer
<jdstrand> niemeyer: yes, it is weird. also, one could argue that kubelet can't function without system-observe, so why have it as a separate interface that could be manually disconnected
<niemeyer> jdstrand: We might come up with something like an AllowPtrace() method in the intenral AppArmor specification, and when the profile is being generated, check if AllowPtrace is on, otherwise deny it
<zyga> rharper: as I said above :) it's a jj question
<rharper> zyga: =)
<niemeyer> jdstrand: This is relatively clean, and prevents exposure of implementation difficulties
<jdstrand> niemeyer: iiuc, you are saying that in k8s we would set AllowPtrace such that in system-observe it can ask if AllowPtrace is set and make a decision. correct?
<niemeyer> jdstrand: Almost.. Imagine a method AllowPtrace() which sets a private attribute allowPtrace=true in the apparmor Specification
<niemeyer> jdstrand: This would generally be false
<jdstrand> oh
<niemeyer> jdstrand: When the apparmor is being generated, we always deny it, unless one of the interfaces allowed it
<niemeyer> s/apparmor/apparmor profile/
<jdstrand> right. at the very, very end, before writing it out, we can see if it is set
<jdstrand> and if it is, do something
<jdstrand> I like that
<niemeyer> Right, exactly.. if nothing enables it, we deny it
<niemeyer> Then the interfaces that want to enable it would call the method instead of putting it directly into the profile
<jdstrand> it yes, that is very nice indeed
<jdstrand> I think I can use this idea with a problem I had with a conflicting x modifier between home and docker-support
<jdstrand> cool
<jdstrand> niemeyer: ok, my 3rd question was what to do with the existing kubernetes-support. if pedronis tells me nothing is using it, i'll just take it over
<jdstrand> niemeyer: thank you! :)
 * jdstrand really like the spec variable idea
<jdstrand> likes*
<pstolowski> mvo: do you want to take a look at https://github.com/snapcore/snapd/pull/5975 or can i land when green?
<mup> PR #5975: ifacestate/hooks: only create interface hook tasks if hooks exist <Created by stolowski> <https://github.com/snapcore/snapd/pull/5975>
<pstolowski> (it has 2 reviews)
<mvo> pstolowski: yes, I had a quick peek already and it looked good but I did not do a line by line proper review
<mvo> pstolowski: let me look again
<mvo> pstolowski: and thanks for doing this so quickly!
<mvo> Chipaca: what step?
<mvo> Chipaca: aha, right
<mvo> Chipaca: I think sergio is maintaing this checklist now
<pstolowski> mvo: yw, happy to move to something else other than hotplug ;)
<Chipaca> mvo: cachio: updating the brew formula
<niemeyer> jdstrand: Glad it sounds reasonable.. let's see if it works out
<mvo> pstolowski: *g*
<Chipaca> mvo: cachio: I'll do 2.36, and then I'd like to hand it off (should be just chaning a version number and updating a hash)
<Chipaca> changing*
<smoser> ok. i'm back. and reading
<smoser> zyga, rharper pivot_root issues aside, snapd's logic there is broken
<smoser> it is trusting the first field of /etc/fstab to mean something
<smoser> it does not mean anything
<zyga> smoser: ? can you be more precise please
<smoser> overlayroot uses 'overlayroot' as the 'fs_spec' for the mount it does
<smoser> casper uses '/cow'
<smoser> the kernel ignores it
<smoser> as overlayroot reads the relavent values from 'fs_file' (second field) and upperdir=,workdir=
<zyga> we do not read /etc/fstab
<smoser> sorry
<zyga> we read /proc/self/mountinfo
<smoser> not fstab. proc/mounts
<smoser> or mountinfo
<smoser> same thing really
<mvo> cachio: 2.36~pre2 is in beta now
<zyga> so what are we doing wrong?
<zyga> we look at the filesystem type
<zyga> smoser: we are not looking at the backing device
<zyga> which as you say can be anything
<zyga> we are looking at the filesystem type "overlay" and the mount point "/"
<smoser> ok. re-reading as i assumed /proc/mounts let me see
<rharper> smoser: https://github.com/snapcore/snapd/blob/master/osutil/mountinfo_linux.go
<zyga> we don't use proc mounts because it has fewer things exposed
<zyga> smoser: and to be clear, our logic did trigger in the image I tested
<zyga> it just used the wrong path, as instructed to by the kernel
<zyga> all I did in the fix was to re-map it manually because we know what happens in this particular case
<zyga> (where "knows" is perhaps too strong but you know what I mean)
<rharper> https://bugs.launchpad.net/apparmor/+bug/1703674
<mup> Bug #1703674: inconsistent required directory rules needed with overlayfs <aa-kernel> <AppArmor:New> <https://launchpad.net/bugs/1703674>
<rharper> zyga: is that the bug that tracks the "odd" requirement for the path ?
<smoser> ok. zyga this is casper /proc/1/mountinfo
<smoser> http://paste.ubuntu.com/p/ftMNjsv8tx/
<zyga> rharper: I don't know - perhaps
<smoser> and this is overlayroot
<smoser> http://paste.ubuntu.com/p/b4PZXYhCF7/
<smoser> I *think* that you are reading the 10th field of line 9 (/cow) in casper to mean something
<zyga> 28 0 0:24 / / rw,relatime shared:1 - overlay overlayroot rw,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_
<zyga> I don't think we do
<zyga> we read the fstype filed
<zyga> not the backing store
<zyga> https://github.com/snapcore/snapd/blob/master/osutil/mountinfo_linux.go#L183
<Chipaca> I'm going afk for a few hours. Have a great weekend, y'all!
<zyga> Chipaca: enjoy :)
<zyga> smoser: the first field after the -
<Chipaca> zyga: i'll be asking for logs of this conversation later, to catch up -- super interesting
 * Chipaca off
<smoser> zyga: i'm reading https://github.com/snapcore/snapd/blob/master/osutil/overlay_linux.go#L58
<smoser> "if mount source is path, strip it from dir"
<zyga> smoser: as ultimate proof I can show you this https://github.com/snapcore/snapd/pull/5974/files#diff-989405fde2087a02f99e11b0c532699dR88
<mup> PR #5974: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <https://github.com/snapcore/snapd/pull/5974>
<smoser> mount source does not mean anything
<pedronis> jdstrand: no snap has been granted use of kubernetes-support
<cjwatson> diddledan: hi, you've typoed "build-on" as "build on" in your audacity snapcraft.yaml
<zyga> smoser: ah, I missed that aspect
<zyga> I was focusing on the triggering
<smoser> i pointed to that line in my comments!
<smoser> :)
<zyga> let me think, I think this came from jdstrand
<diddledan> oh fudge
<diddledan> thanks cjwatson
<zyga> sorry, I missed that
<cjwatson> (noticed because LP emailed me an oops report)
<diddledan> yey
<smoser> well, zyga you were derailed by my 'fstab' comments. which i understand were confusing.
<zyga> hmm
<zyga> but 			if dir, ok := entry.SuperOptions["upperdir"]; ok {
<zyga> dir is the upper path
<smoser> that part is right.
<cjwatson> it should go somewhere more useful, and arguably shouldn't oops, but ...)
<smoser> well, right for this :)
<pedronis> jdstrand: but maybe you were asking if anything has kubernetes-support plug, that is a trickier question
<zyga> jdstrand: can you explain that part please: https://github.com/snapcore/snapd/blob/master/osutil/overlay_linux.go#L58
<zyga> smoser: I never saw mount source being a path
<zyga> I'm curious as well now
<zyga> smoser: thank you for persisting! I totally missed that
<cjwatson> diddledan: same for gnome-twitch, but I see you noticed that too :)
<jdstrand> pedronis: that is good enough. it needs an installation constraint
<diddledan> yup, both fixeded
<cjwatson> ta
<diddledan> thanks for the alert :-)
<jdstrand> pedronis: so it would have to be granted the use for anyone to use a snap with it
<jdstrand> zyga: what is the question? all of this is very casper specific. we knew it would have to be updated if the livecd pattern changed
<diddledan> (some people might say I'm a "lert")
<zyga> jdstrand: the question is why do we interpret mount source in overlayfs detector
<zyga> jdstrand: since mount source is unused arbitrary string in the cases I'm familiar with at least
<jdstrand> because of the way casper set it up, it was something we could look at
<jdstrand> yes
<zyga> jdstrand: that's interesting, thanks!
<zyga> smoser: so we should look at casper
<jdstrand> it's not 'dependable'
<zyga> but I think the path is (probably) an accident more than a feature, I wonder if overlayfs itself uses it
<zyga> I will finish writing a test for something I have and return to this
<jdstrand> https://github.com/snapcore/snapd/commit/0f40f37c416587bd2e3b51db66601262869d2dc7
<diddledan> am I correct with my belief that snaps don't expose url handlers currently? i.e. vscode in a snap cannot hook the vscode:// url scheme from the system (I'm triggering it with a non-snap process, so it's not the confinement out of another snap that's a problem): https://github.com/Microsoft/vscode-pull-request-github/issues/573
<zyga> diddledan: they do
<zyga> diddledan: grep for vscode in generated desktop files in /var/lib/snapd/desktop
<diddledan> what am I looking for?
<jdstrand> zyga: see the above commit. the detection is completely arbitrary based on what we observed. it was always known that if something changed or we wanted to support something else, we'd need to do things differently
<zyga> diddledan: desktop files can declare URL handlers
<zyga> jdstrand: thank you, I see
<zyga> I will dig into that shortly after the other bug
<zyga> diddledan: let me grep my system
<popey> zyga: isnt the list hard wired?
<jdstrand> so, right now it is looking for '/cow', cause that is what we know casper does
<zyga> popey: which list?
<popey> mailto: http etc
<popey> we discussed this in belgium
<zyga> that's in the snap handler
<jdstrand> so the upperdir is /cow/upper, but because of the pivit root htat becomes simply /upper
<zyga> not in what is published to the system
<jdstrand> pivot*
<jdstrand> so yes, now I see smoser's point fully
<zyga> jdstrand: right I think we were not discussing the pivot aspect, just that overlayfs mount source (which is "overlay" or "overlay root" or "whatever unused") was being used by the logic
<zyga> right
<zyga> +1
<zyga> popey: vscode is not defining any
<zyga> popey: compare to telegram desktop for example:
<zyga> telegram-desktop_telegramdesktop.desktop:MimeType=x-scheme-handler/tg;
<popey> but even if it did, it woudln't work, surely, because they're hard wired in snapd
<popey> yes, that one doesnt work
<popey> because it's not listed in snapd
<jdstrand> zyga (cc smoser): ok right, it has all come back to me. in a general fashion, we can't tell that something is going to pivot_root and to what from simply the mountinfo entry. so for the livecd, we try to discover if we think it is a livecd mountinfo entry, and then do stuff (assuming it will be consistent)
<zyga> what is hard wired?
<popey> the list of handlers
<zyga> popey: if the handler is registered the opening that URL from the desktop does work
<popey> we discussed this in belgium, talking about extending the list
<zyga> snaps cannot open such links though
<kyrofa> zyga, I'm trying to use snap try in 2.35.2 and I'm getting "cannot snap-exec: cannot read info for "my-snap-name": cannot find installed snap "my-snap-name" at revision x1: missing file /var/lib/snapd/snaps/my-snap-name_x1.snap" whenever I try to run the app. Any ideas?
<diddledan> the new window action has the wrong Exec line, too: https://www.irccloud.com/pastebin/TA7qUMzu/
<zyga> kyrofa: are you using encrypted FS?
<jdstrand> zyga (cc smoser): if we have this: overlayroot / overlay rw,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_ 0 0
<kyrofa> zyga, full, yeah. Used to work
<zyga> diddledan: indeed (ouch)
<zyga> mvo: ^
<jdstrand> zyga (cc smoser): then, in theory, we could look for 'overlayroot' instead of '/cow', and then try to do something with upperdir
<jdstrand> zyga (cc smoser): for the overlroot case
<zyga> yeah
<kyrofa> zyga, not home dir encryption
<zyga> we could hold a map of the use cases we saw and apply a transofrmation
<jdstrand> ie, '/' + basename(upperdir)
<zyga> kyrofa: where is your snap?
<zyga> kyrofa: as in in the filesystem
<zyga> popey: extending the list is something we can discuss and arrange for, I'm not opposing that
<kyrofa> zyga, /var/lib/snapd/snaps
<zyga> wait, you had that snap there?
<kyrofa> zyga, oh wait, sorry, misunderstood
<zyga> h
<zyga> so where was it when you tried it?
<kyrofa> zyga, in my home dir somewhere
<zyga> did you remove the prime/ directory?
<zyga> and built it again?
<zyga> can you please paste /proc/self/mountinfo, grep for the snap to make the output shorter
<kyrofa> No, just ran `snap try prime` and then tried running the command immediately
<zyga> (ideally one line)
<kyrofa> zyga, oh wait, actually, it was in /tmp. I bet that's the issue huh
 * cachio lunch
<zyga> mmm, perhaps but I want to see the mountinfo anyway
<zyga> but most likely so
<zyga> because snap-exec cannot handle that
<zyga> well
<zyga> actually, ignore me
<zyga> it should not matter
<zyga> at that stage it should be mounted in /snap/...
<zyga> do you see your snap mounted there?
<pstolowski> cachio: the nested vm PR seems to have failed misteriously ("null"), is it too expensive to build ubuntu image maybe?
<pstolowski> cachio: btw, added a few comments, this is going to be great, thanks for working on this
<kyrofa> zyga, https://paste.ubuntu.com/p/sgdjp5v3tg/
<kyrofa> zyga, yeah, it's mounted in /snap/my-snap-name/x1
<zyga> kyrofa: this looks correct
<zyga> mmm
<zyga> hold on, I need to break for dinner now
<zyga> kyrofa: please hold this bug :)
<mvo> zyga: in a meeting right now, would love to get a tl;dr summary in a bit
<zyga> k
<mup> PR snapd#5977 closed: release: 2.36~pre2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5977>
<mup> PR snapd#5978 opened: interfaces: don't allow snaps to write to $HOME/bin <Created by zyga> <https://github.com/snapcore/snapd/pull/5978>
<zyga> jdstrand: ^
<mup> PR snapd#5976 closed: interfaces: improve Attr error further <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5976>
<mborzecki> pstolowski: hey, can you take a look at https://github.com/snapcore/snapd/pull/5948 ?
<mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
<pstolowski> mborzecki: sure
<mborzecki> pstolowski: thanks!
<mborzecki> pstolowski: responded :)
<zyga> re
<pstolowski> mborzecki: ok, i'm still on it
<smoser> zyga, jdstrand just as an fyi. http://paste.ubuntu.com/p/pzDk8bZMjb/
<smoser> if i change overlayroot like ^ and update initramfs then it works
<smoser> as basically this puts '/media/root-rw' in the source (fs_spec) option fed to 'mount' for my overlay mount
<smoser> and that makes it happy.
<zyga> smoser: ack
<smoser> but that will break 'overlayroot-chroot' command
<zyga> smoser: I'm not familiar with that command but I think with the workaround I proposed for snapd we don't need to change anything else
<smoser> which relies on finding 'overlayroot' in /proc/mounts
<smoser> well, that command is probably not used by anyone other than me.
<smoser> but it allows you to easily remount rw and jump into the "real root" to make a change
<mup> PR core18#83 opened: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <https://github.com/snapcore/core18/pull/83>
<zyga> roadmr: trying now
<zyga> roadmr: no change
<zyga> same error as last time
<roadmr> mm
<roadmr> zyga: did the snap change?
<zyga> I rebuilt the snap but I believe it didn't change at all
<zyga> the error is :
<zyga>   - __all__: The upload does not appear to be a valid package.
<mup> PR core18#84 opened: hooks: port classic mode generation to UC18 <Created by mvo5> <https://github.com/snapcore/core18/pull/84>
<roadmr> zyga: let me check the snap I have against the tools
<zyga> thank you
<zyga> mvo: man, you are killing it on Friday :)
<zyga> mvo: how about locale?
<zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/5974
<mup> PR #5974: osutil: workaround overlayfs on ubuntu 18.10 <Created by zyga> <https://github.com/snapcore/snapd/pull/5974>
<roadmr> zyga: the tools work fine with the snap build I have, so perhaps your rebuild did introduce more evil. Wormhole?
<zyga> sure
<mvo> zyga: whats the status for 5974 ? do we need it?
<mvo> zyga: if so, for 2.35? 2.36?
<mvo> zyga: I can review after dinner in a bit
<zyga> mvo: I think we need it
<zyga> for whatever ships
<mvo> zyga: for whatever ships would be 2.35.5
<mvo> zyga: do we need it like *now* i.e. tonight/before the weekend?
<zyga> mvo: I'm not sure what to answer
<zyga> smoser: ^
<zyga> smoser: so we need it like now, tonight, before the weekend?
<smoser> I think that submitting as "zero day SRU" is fine.
<smoser> all users of overlayroot and our images are broken
<smoser> which is clearly bad, but
<smoser> the two users that i'm aware of are
<smoser>  a.) open-iscsi autopackage test http://autopkgtest.ubuntu.com/packages/o/open-iscsi/cosmic/amd64
<smoser>  b.) curtin vmtest (we just put in a workaround to disable snapd)
<smoser>  c.) MAAS installation.  this works fine because they disable apparmour
<smoser> so I personally dnot think there is reason for fire-drill upload at this point since we have it well understood.
<smoser> but... if there was an upload going to happen anyway
<smoser> then i think that that pull request should be taken
<smoser> even in its simple form it fixes default use-case
<smoser> zyga: ^
<smoser> mvo: ^
<zyga> ack thanks
<zyga> I think we will still release but for another reason
<zyga> and we can piggy back this patch
<plars> ogra: I can't recall, is bluetooth expected to work on our rpi images?
<plars> ogra: nm, I found https://bugs.launchpad.net/snappy/+bug/1674509 - I thought there was something like that but that it had been resolved already
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<zyga> roadmr: any finings?
<zyga> findings :)
<roadmr> zyga: still fighting kibana for the logs
<zyga> thank you
<smoser> zyga: for now the solution is just to special case '/media/root-rw/overlay' as you did ?
<zyga> yes
<zyga> next week we can explore better options
<smoser> i think thats appropriate for now.
<smoser> thank you
<zyga> without time pressure
<zyga> thank you! and double so for pointing out the other aspect of the current solution :)
<roadmr> zyga: does git-lp still exist/work?
<zyga> roadmr: I don't know, I'm not using it
<roadmr> ok :)
<roadmr> zyga: hey any chance you could retry pushing the snap? log spew is making it very hard to find the exact entry I need
<roadmr> having a shorter time window owuld help :)
<zyga> doing now
<zyga> done
<roadmr> thanks!
<jjohansen> rharper, zyga: its a limitation in the LSM atm that we are working on fixing by extending the hooks available
<zyga> jjohansen: thank you for confirming this, so our prediction about pivot_root being the cause are correct?
<zyga> jjohansen: would you consider it a separate bug that mountinfo doesn't show correct paths after pivot_root?
<zyga> (in the mount options field)
<jjohansen> yes, we see the pivot_root and can mediate it but we can't properly update/track it because its a permission hook, not a stateful hook which means the pivot_root might actually not happen, and if we track at that point, and it fails we are completely messed up
<jjohansen> well, no more messed up than now I suppose, its mess up one way or the other
<zyga> I mean, regardless of apparmor in this case
<jjohansen> atm namespaces in general are a problem because we don't have hooks to perform permission checks or track unshare or setns
<jjohansen> right, it messes up apparmor not the kernel
<zyga> jjohansen: right but I was specifically asking about just plain /proc/self/mountinfo
<zyga> part of the problem is that apart from the apparmor aspect we got confused by the path reported by the kernel there
<zyga> it seems like a bug in overlayfs
<zyga> or mountinfo rendering of itself
<mup> PR snapcraft#2346 opened: ruby plugin: add support for base <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2346>
<jjohansen> overlayfs is another issue
<jjohansen> you have two mounts
<smoser> i never expected mountinfo to be updated.
<jjohansen> will potentialy more
<jjohansen> s/will/well/
<smoser> id have ben surprised if two processes (one with an NS change and one without) saw different values for 'upperdir='
<zyga> smoser: mountinfo is updated when you pivot normally
<zyga> for all the other paths
<jjohansen> yep
<zyga> smoser: but the upperdir (being a mount option string) is probably just printed verbatim
<jjohansen> pivot_root is magic
<zyga> it just seems that using system paths in mount options is not that common
<smoser> right.
<smoser> but essentially you're just feeding '-o' as a string to the filesystem
<zyga> right
<smoser> so anything could go in there and is only properly understood by that specific fs
<zyga> right
<zyga> but it could be :)
<roadmr> zyga: hey do you have the exact filename for the snap you tried to upload? pm if you like
<zyga> yes, same as I gave you but ..
<roadmr> zyga: I'm not finding anything in logs, makes me suspect it's barfing even before being able to determine the snap id
<roadmr> because I'm searching with snap id and getting nothing
<smoser> oh. hm.. zyga so in http://paste.ubuntu.com/p/P2pdtCDn2v/
<smoser> whihc is a "post-pivot" /proc/1/mountinfo
<zyga> roadmr: fedora29.2018.10.12.x86_64.snap
<smoser> did the kernel remove '/cow' from some string above line 9 ?
<roadmr> thanks zyga
<smoser> i couldnt understand how 'upperdir=/cow/upper' was a thing at the point of that mount
<zyga> 30 1 0:24 / / rw,relatime shared:1 - overlay /cow rw,lowerdir=//installer.squashfs://filesystem.squashfs,upperdir=/cow/upper,workdir=/cow/work
<zyga> probably it existed in the initrd
<zyga> mkdir /cow
<zyga> ...
<zyga> pivot
<zyga> I played with pivot and overlayfs almost all of last week
<smoser> bah. duh
<smoser> i guess i was just expecting to see *some* '/' mount
<zyga> trying to write a spread test for the live CD fix
<zyga> mm
<smoser> but the initramfs / doesn't get represented anywhere
<zyga> you have / mount
<zyga> overlay is there :)
<zyga> nothing else
<smoser> yeah. but i was expecting to see something above that line.
<zyga> the fact that overlay still holds onto a mounted filesystem
<zyga> that we cannot see
<zyga> is not visible
<smoser> right.
<zyga> if you had a process living in the initrd namespace
<zyga> you would see that
<zyga> it's actually easier to reason about
<zyga> just make a mount namespace
<smoser> :)
<zyga> do a overlayfs + pivot there
<zyga> and see what you see in mountinfo
<zyga> you can get to one-liner overlatyfs + /proc
<zyga> *overlayfs
<zyga> but you can see the backing store in the initial mount namespace
<zyga> roadmr: perhaps the permissions on the snap directory tree are unusual?
<smoser> ok. yeah, well that is enough for me today.
<zyga> or something else is making it fail
<smoser> i really should be looking at other things.
<zyga> :-)
<smoser> thank you
<zyga> thank you smoser :)
<ogra> plars, sadly not, i pinged koza on the forum about it today as well ...
<ogra> the bluez snap delivers everything we need but it needs manual intervention to actually initialize the BT stack
<plars> ack
<mup> PR snapd#5979 opened: install: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5979>
<mup> PR snapcraft#2343 closed: schema, meta: add "full" app adapter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2343>
<mup> PR snapcraft#2346 closed: ruby plugin: add support for base <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2346>
<mup> PR snapcraft#2347 opened: extensions: support adding root properties <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2347>
<kyrofa> Any update on when 2.36 will be stable?
<roadmr> zyga: still around?
<mup> PR snapd#5978 closed: interfaces/home: don't allow snaps to write to $HOME/bin <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5978>
<mup> PR snapcraft#2344 closed: schema: remove the deprecated snap keyword for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2344>
<mup> PR snapcraft#2347 closed: extensions: support adding root properties <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2347>
<mup> PR snapcraft#2348 opened: extensions: remove root extensions <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2348>
<mup> PR snapd#5980 opened: interfaces/apparmor: conditionally add explicit deny rules for ptrace <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5980>
<mup> PR snapcraft#2349 opened: extensions: use extension docstring <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2349>
#snappy 2018-10-13
<mup> PR snapcraft#2348 closed: extensions: remove root extensions <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2348>
<mup> PR snapcraft#2350 opened: extensions: parse all declared extensions before applying <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2350>
<mup> PR snapcraft#2351 opened: tests: use valid snap names in unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2351>
<mup> PR snapd#5981 opened: interfaces/many: updates to support k8s worker nodes <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5981>
<mup> PR snapcraft#2351 closed: tests: use valid snap names in unit tests <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2351>
<mup> PR snapcraft#2352 opened: tests: use valid snap names in unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2352>
#snappy 2018-10-14
<mup> Bug #1797745 opened: "ln: failed to create symbolic link" in deepin 15.7 <Snappy:New> <https://launchpad.net/bugs/1797745>
<mup> PR snapcraft#2352 closed: tests: use valid snap names in unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2352>
<mup> PR snapd#5982 opened: interfaces/many: conditionally use 'unsafe' with change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
<mup> PR snapcraft#2342 closed: nodejs plugin: update to the latest 8.x LTS version <Created by anthonyfok> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2342>
#snappy 2019-10-07
<mborzecki> morning
<mvo> mborzecki: great job on 7166 - thanks that this is landed now
<mborzecki> mvo: yw, it was fun :P
<mborzecki> mvo: btw. got a report from fedora user about snapd dying due to ABRT, got the logs eventually
<mborzecki> mvo: what happens is that the system goes to sleep, once it's woken up systemd kills snapd due to watchdog timeout :/
<mvo> mborzecki: oh no!
<mvo> mborzecki: we can't be the only ones affected by this, this sounds like a very generic issue - or are we using the watchdog wrong in some way?
<mvo> (I guess its a bit early to ask these questions :)
<zyga> good morning
<mborzecki> zyga:  hey
<zyga> mvo: thank you for the review on https://github.com/snapcore/snapd/pull/7549
<mup> PR #7549: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549>
<zyga> I'm sorry for being absent on Friday
<zyga> I was a full-time mom for the last three days
<pokk> Good morning
<mvo> hey zyga - good morning!
<pokk> zyga: Speaking from experiance imho that is both wonderful and sucks. I hope you get decently paid while home with sick kids at least
<zyga> pokk: paid with hugs and diapers :)
<pokk> zyga: that's great :)
<zyga> mborzecki: can you do a 2nd review on https://github.com/snapcore/snapd/pull/7549 please
<mup> PR #7549: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549>
<mvo> sil2100: good morning! could you please have a look at the pending snapd SRU in the unapproved queue? and who should I poke about universe SRUs? I did a drive-by rxtx sru to bionic on sunday to fix the arduino IDE in bionic, pretty trivial and was wondering if I need to poke someone else?
<sil2100> mvo: hey! Let me take a look at those then
<mvo> sil2100: thank you
<sil2100> hm, weird, someone accepted snapd to disco but didn't for bionic and xenial
<sil2100> Anyway, looking into that
<sil2100> Ah
<sil2100> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1840740/comments/3
<mup> Bug #1840740: [SRU] 2.41 <verification-needed> <verification-needed-disco> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):New> <snapd (Ubuntu Bionic):Incomplete> <snapd (Ubuntu Disco):Fix Committed> <https://launchpad.net/bugs/1840740>
<sil2100> mvo: can you address that by any chance?
<mvo> sil2100: uh, sorry, I must have missed that
<mvo> sil2100: will look into a fix, please reject
<sil2100> mvo: ok! Give me a poke once you re-upload, I can review those then - in the meantime, I'll look at rxtx
<mvo> sil2100: thanks, will probably take a bit until I will reupload, need to medidate over this a bit :/
<mvo> (mostly the test-case part)
<sil2100> mvo: I suppose xenial also has the same change, so I'll reject that as well
<mup> PR snapd#7544 closed: tests: fix snapd-failover test for core18 tests on boards <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7544>
<mup> PR snapd#7549 closed: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7549>
<mborzecki> mvo: based on https://github.com/golang/go/issues/19810 i think we could try to replace the time.Ticker in cmd/snapd/main.go with time.After(), but that's about the only idea i have atm
<mborzecki> and we ping systemd at twice the required frequency, while systemd should be smart enough to use monotonic timers
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> mborzecki: ta
<mborzecki> mvo:  updated https://github.com/snapcore/snapd/pull/7543
<mup> PR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
<mvo> mborzecki: thank you, much appreciated. sorry for the nitpicking there but it took me a couple of minutes(!) before my first cup of tea to understand the defer. which probably says more about me than the code :/
<mborzecki> mvo:  no worries :)
<mup> PR snapd#7430 closed: overlord/snapstate: add SetTaskSnapSetup helper + unit tests <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7430>
<mborzecki> zyga:  some comments in #7547
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<mborzecki> zyga: iirc we'd stil want to degrade gracefully, but maybe my memory is playing tricks
<mup> PR snapd#7437 closed:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7437>
<zyga> mborzecki: I'm not sure, we'll see
<zyga> mborzecki: thank you for the review, I should have posted the more fresh version last week but nothing is lost :) You'll see it soon enough
<Chipaca> mvo: pedronis: more and more i wonder why we did /v2/download instead of just having a download action on /v2/snaps
<pedronis> Chipaca: because of different response ?
<Chipaca> i guess it makes it easier to change our mind / fine-tune the rules for access, but eh
<Chipaca> pedronis: pr'aps. Or maybe because then we can use it to download things that aren't snaps?
<pedronis> that might happen
<Chipaca> pedronis: mvo: have you talked about the assertions side of 'snap download' when going via snapd?
<Chipaca> pedronis: mvo: also 'snap known --remote'
<pedronis> Chipaca: mvo added a remote option to the assertion end point
<mvo> Chipaca: yeah
<pedronis> it has landed
<pedronis> afaik
<Chipaca> neat
<mvo> Chipaca: we are ready pretty much, hold on a sec
<mvo> Chipaca: I just chunked the PR up into small bits
<mborzecki> zyga: so far it's looking good, all things considered the change should be rather simple as we discussed before :)
<zyga> mborzecki: yeah, I was just thinking about how to stage it
<zyga> mborzecki: perhaps the next chunk to land for real would be the cgroup alone, without the agent
<zyga> mborzecki: and after that just the agent
<zyga> mborzecki: does that sound okay?
<zyga> mborzecki: I worry that together it will be less approachable
<mborzecki> zyga: yeah, just the cgroup change would be functionally identical to what we have now
<mvo> Chipaca: https://github.com/snapcore/snapd/compare/master...mvo5:snap-download-via-snapd?expand=1 this is the full pr, it needs a bit of polish still around the edges that are not proposed yet but once my other two prs are  merged the rest is hopefully eay
<mvo> Chipaca: fwiw, 7533 and 7510
<Chipaca> mvo: pedronis: completely unrelated and so I either write it down as a TODO, or forget about it: do we want to change the cache (as in store/cache) to use the same format for sha3 as 'snap info'? right now it's different which makes it harder to use the two together
<mvo> Chipaca: I think that makes sense
<pedronis> Chipaca: in which sense together?
<pedronis> the cache is an implementation detail
<Chipaca> pedronis: 'snap info --verbose some-snap' tells you the sha, but you can't then look in the cache to know which file it is
<pedronis> is this for debugging?
<Chipaca> yes
<pedronis> Chipaca: it means we need to look at both formats for a while?
<Chipaca> pedronis: you can always 'sudo find /var/lib/snapd/cache | sudo xargs snap info --verbose ' but that is really expensive, particularly on slow machines
<Chipaca> pedronis: yes
<Chipaca> i've added a card
<pedronis> Chipaca: we could also have snap debug list-cache or something
<pedronis> anyway it's kind of bottom of the queue given all the things
<Chipaca> yeah :)
<Chipaca> pedronis: ooh, snap debug cache might be useful
<mvo> yeah, thats a nice idea
<Chipaca> not just for the snap cache
<pedronis> Chipaca: but given is low, it should really go to the forum as backlog, not as a card, we already have cards that need to move back to the forum
<Chipaca> ah
<Chipaca> sorry
<pedronis> Chipaca: 19.10 TODO is really for stuff we must do
<pedronis> it can go to upcoming if we were sure it would be done soon
<pedronis> but we aren't sure of that :)
<zyga> coffee
<mborzecki> pedronis: #7541 can land
<mup> PR #7541: seed/seedwriter: support for extra snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7541>
<pedronis> mborzecki: mvo: thanks
<mup> PR snapd#7541 closed: seed/seedwriter: support for extra snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7541>
<pedronis> mvo: mborzecki: pstolowski:  #7556 is ready for review, is the actual switch to use seedwriter in image.go, there is quite a bit of red in it
<mup> PR #7556: image,seed/seedwriter: switch image to use seedwriter.Writer <Created by pedronis> <https://github.com/snapcore/snapd/pull/7556>
<pedronis> mvo: #7462 needs a re-review
<mup> PR #7462: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7462>
<mvo> pedronis: thanks
<mvo> pedronis: I have a look
<mvo> pedronis: just sent you a mail about something unrelated, would be great if you could have a look
<mvo> pedronis: (but not high priority)
<Chipaca> mvo: #7533 now suffering from the context conflict that mborzecki called out
<mup> PR #7533: client: add support to use the new "download" API <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7533>
<pstolowski> pedronis: ty
<mvo> Chipaca: let me fix it
<pedronis> I'll swithc to doing some reviewing after lunch
<pedronis> *switch
<mvo> pedronis: thanks
 * Chipaca takes a break
<mborzecki> - Download snap "test-snapd-dbus-consumer" (6) from channel "beta" (stream error: stream ID 1; PROTOCOL_ERROR)
<mborzecki> meh, again
<mborzecki> how did we fix it the last time?
<mvo> mborzecki: maybe its failing 3 times?
<mvo> mborzecki: we only retry for protocol errror
<mvo> mborzecki: so if it happens multiple times in the same stream eventually it fails iirc
<mvo> mborzecki: what pr is that?
<mborzecki> mvo:  https://github.com/snapcore/snapd/pull/7543
<mup> PR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
<mborzecki> mvo: https://travis-ci.org/snapcore/snapd/jobs/594466695
<mborzecki> mvo: from the logs it does not look like snapd retried due to PROTOCOL_ERROR
<mvo> mborzecki: I see some retries here
<mvo> mborzecki: let me look further
<mborzecki> mvo: i must be looking at other tests, I see a retry due to unexpected EOF and then there's protocol err but no retry
<mvo> mborzecki: oh, interessting, I have one tests here with "Retry because of: stream error: stream ID 1; PROTOCOL ERROR
<mvo> mborzecki: but I have no looked at all of them yet
<mborzecki> mvo:  one failure also kept getting &errors.errorString{s:"unexpected EOF"}
<mvo> mborzecki: yeah
<mvo> mborzecki: I think I see what you see, one test seems to not retry
<mvo> mborzecki: I wonder if different bits of the code in http2 produce slightly different protocol errors or what is going on there, its very strange
 * mvo should look closer before making strong assertions like "very strange"
<mborzecki> mvo: perhaps, but we look for 'PROTOCOL_ERROR' which appears in the non retry case too
<mborzecki> mvo:  and it's the same ubuntu 16.04-32 system, so cannot be go version change at play
<mvo> mborzecki: right, in the log it seems like the total time of the attemp is ~3m30 so things looks pretty bad
<mvo> mborzecki: to download yq
<mvo> mborzecki: so maybe just a fastly issue?
<zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/7547
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> mborzecki: I think it has a chance to pass and get merged now
<zyga> mborzecki: I will put the agent on hold for a sec and do a branch from this to fix setting up cgroup for classic snaps as well (the omission I mentioned earlier)
<zyga> mborzecki: then come back to integrate the agent
<zyga> rogpeppe: hello
<rogpeppe> zyga: hiya
<zyga> rogpeppe: do you have any updates for us? is there a chance to get the SD image?
<rogpeppe> zyga: unfortunately my dad thought he'd dropboxed the image before going away, but only did a zip file with just the script instead, sadly
<zyga> ah, I see
<rogpeppe> zyga: so i'm waiting for him to get back from his travels (soon, I think)
<zyga> that's okay, just keep us posted if you can get the image
<zyga> thank you :)
<zyga> we are moving some stuff behind the scenes to make the pi more reliable in conjunction with other developers from beyond the snapd team
<zyga> it's not something that will be done overnight but I think that at least one annoying thing can be fixed in the next one or two releases (the reboot getting stuck there)
<Chipaca> mborzecki: did you save the protocol error log?
<mborzecki> Chipaca: i still ahve the log opened
<Chipaca> mborzecki: can you get at the 'raw' log?
<pedronis> pstolowski: I did pass over 7355, just nitpicks of various importance
<pedronis> *a pass
<mborzecki> Chipaca: sure, just a sec
<pstolowski> pedronis: ty
<mborzecki> Chipaca: https://paste.ubuntu.com/p/bFgCsXWvzX/
<Chipaca> hah!
<pedronis> pstolowski: a question could we/should we consider using SetupMany in setupSecurityByBackend ?
<Chipaca> mborzecki: mvo: AFAICT the problem is that we got protocol error not on doing the request but on downloading
<Chipaca> mborzecki: mvo: i.e., we might need to add the same check to ShouldRetryHttpResponse?
<mvo> Chipaca: aha, I missed that
<Chipaca> not sure tho
<mborzecki> ah, it's called directly in the store package
<mborzecki> Chipaca: duh, but we call SHouldRetryError() there too
<Chipaca> mborzecki: yeah i was wrong (surprise!)
<Chipaca> the RetryHttpResponse will say yes because it's 206
<Chipaca> wait, no, it'll say no for that same reason
<Chipaca> huh
<pstolowski> pedronis: indeed! good idea, we could save a little there as well. i can do in a followup
<mup> PR snapd#7557 opened: interfaces/mount: account for cgroup version when reporting supported features <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>
<mborzecki> zyga: ^^
<zyga> ack
<zyga> looking
<zyga> +1
<zyga> mborzecki: we don't have 31 tests yet, right?
<mborzecki> zyga: we don't, there was an image cachio prepared a while ago, but that was before 31 branched iirc
<zyga> I see
<zyga> ok,
<zyga> it would be good to discuss this today
<zyga> I could use 31 image
 * Chipaca takes a deep breath and reminds himself he's not here to remove the stupid from random people
 * Chipaca goes to check on lunch
 * mvo hugs juliank for his command-nof-found upload
<ogra> will that finally fix core18 ?
<juliank> :)
<mborzecki> off to pick up the kids
<pedronis> mborzecki: did a pass with some questions on the timeutil bits of #7443
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pedronis> Chipaca: do you remember why given it takes at most one snap we support taking multiple in the json to /download?
<mup> PR snapd#7558 opened: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <https://github.com/snapcore/snapd/pull/7558>
<mup> PR snapd#7543 closed: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
<bloodearnest> Chipaca: o/ - to follow up on refresh issues from last week - when do the systemd files get regenerated in the refresh action? It looks like at some point we're getting services started that are pointing at old snaps working directory
<Chipaca> bloodearnest: if you have a recent 'refresh' change
<Chipaca> bloodearnest: you can 'snap tasks --last=refresh'
<bloodearnest> Chipaca: thanks
<Chipaca> bloodearnest: but it is: run pre-refresh hook, stop services, remove aliases, remove current symlink, copy data, â¦ , post-refresh hook, start serviecs
<bloodearnest> Chipaca: does start services include generating the systemd files?
<bloodearnest> Because the services seem to be starting up with the old working directory
<zyga> mborzecki: hey
<zyga> mborzecki: can you quickly decide if I should open the named cgroup PR (away from draft mode)
<zyga> mborzecki: or finish the change to include classic snaps as well first
<mborzecki> zyga: i think it's ok to open it now while to code is small, then classic can be done later as part of #7302 (or an intro to that PR)
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<zyga> okay, I'll do so now
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7547 is open now
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> mborzecki: do you want to add that snap mount unit to 7302?
<ackk> zyga, hi, it seems I managed to reproduce the issue with "snap try" and rsyncing files, leading to snapd not finding the executable in the snap
<zyga> hey, cool, do you have it scripted by any chance?
<mborzecki> zyga: i'll try a separate PR, just to see the whole spread suite run
<zyga> something we can play with and debug?
<zyga> mborzecki: Ok
<ackk> zyga, no, I don't have a way to reproduce it, it just happens
<ackk> zyga, but I could debug, if you have commands I can run
<zyga> ackk: what is the error message you see that is the immediate problem?
<ackk> $ maas
<ackk> execv failed: No such file or directory
<ackk> zyga, ^
<zyga> are you able to execute more commands now to explore this?
<ackk> zyga, and of course, $SNAP/command-maas.wrapper and $SNAP/bin/maas (which is called by that one) are there
<ackk> zyga, yeah
<zyga> ackk: can you ls -ld /snap/maas/current
<ackk> zyga, lrwxrwxrwx 1 root root 2 Oct  7 10:23 /snap/maas/current -> x1
<zyga> ackk: snap run --strace=raw maas
<zyga> ackk: is x1 the expected correct revision?
<zyga> ackk: cat /proc/self/mountinfo | grep -F '(deleted')
<zyga> er
<ackk> zyga, yes
<zyga> fix the quote please
<ackk> zyga, nothing there
<ackk> also:
<ackk> $ snap run --strace=raw maas
<ackk> error: exit status 1
<zyga> ackk: cat /proc/self/mountinfo | grep maas
<ackk> zyga, FTR this is in a bionic container
<zyga> right, I recall those are used
<zyga> and are most likely a factor
<zyga> I'd love to understand what's the key bit that is broken
<ackk> zyga, https://paste.ubuntu.com/p/8VcMZhmtrS/
<zyga> ackk: dmesg | grep DENIED
<zyga> ackk: also, sudo nsenter -m/run/snapd/ns/maas.mnt -- in the resulting shell cat /proc/self/mountinfo | grep -F deleted
<ackk> zyga, on the host or in the container?
<ackk> (the dmesg)
<zyga> ackk: hmmm, should be the same AFAIK
<zyga> so either
<ackk> zyga, I used to run snappy-debug on the host, or I would miss some denials
<ackk> not sure if it's relevant
<zyga> hmm, perhaps there's something I don't understand about lxd
<zyga> try on the host please
<ackk> zyga, https://paste.ubuntu.com/p/JSXhbrR4PV/
<ackk> zyga, empty result for deleted mountinfo
<zyga> hum
<zyga> [92186.616879] audit: type=1400 audit(1570431426.676:2750): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-maas_<var-snap-lxd-common-lxd>" profile="/snap/snapd/4605/usr/lib/snapd/snap-confine" pid=4605 comm="snap-confine" family="netlink" sock_type="raw" protocol=15 requested_mask="send receive" denied_mask="send receive"
<zyga> <- this is interesting, separately from the issue that affects you
<zyga> ackk: can you navigate around in that nsenter shell, to see if the executables are where you expect
<ackk> zyga, this would be basically $SNAP right?
<zyga> yeah, but SNAP is not set, so manually
<ackk> sure
<zyga> ackk: one more idea, SNAP_CONFINE_DEBUG=yes snap run ... (as you run maas otherwise)
<ackk> $ SNAP_CONFINE_DBUG=yes snap run -- maas --help
<ackk> execv failed: No such file or directory
<ackk> zyga, ^
<ackk> zyga, afaict executables are there in the right place
<zyga> SNAP_CONFINE_DEBUG=yes
<zyga> DBUG vs DEBUG
<zyga> interesting, perhaps it is failing to exec something other than the app
<ackk> ugh
<ackk> zyga, http://paste.ubuntu.com/p/jdKzRHbFsH/
<zyga> holly molly
<zyga> I suspect I know what this is
<zyga> from the nsenter shell
<zyga> can you ls -ld /usr/lib/snapd/snap-exec
<Chipaca> bloodearnest: sorry, missed your question. Actually writing the service files is part of the "link-snap" step, i.e. "make snap available to the system"
<zyga> ackk: this is a core18 system?
<zyga> ackk: as in
<zyga> ackk: a classic system with core18 and snapd snap?
<ackk> zyga, correct
<ackk> zyga, snap-exect not found
<ackk> zyga, bingo :)
<Chipaca> bloodearnest: i'm very curious to know what the cause of the weirdness you're seeing is, fwiw
<zyga> and you happen to follow which snapd channel?
<zyga> ackk: ls -ld /usr/lib/snapd
<Chipaca> bloodearnest: if you're looking at 'snap tasks --last=refresh' note you might also find interesting info in 'snap debug timings --last=refresh'
<ackk> zyga, http://paste.ubuntu.com/p/wTsT8yPBHF/ tl;dr all stable
<ackk> zyga, /usr/lib/snapd is there
<zyga> is it a directory?
<zyga> what's in it?
<ackk> zyga, yes: drwxr-xr-x 2 root root 0 Oct  1 05:44 /usr/lib/snapd
<ackk> zyga, but, empty
<zyga> uhuhhh
<zyga> okay
<zyga> I strongly suspect I know what this is
<zyga> mvo: ^
<zyga> ackk: the good news, it's high up our stack
<zyga> ackk: the bad news, it's not your system, it's a real general bug
<zyga> ackk: can you do snap changes please?
<ackk> zyga, well, makes me feel less bad :)
<ackk> zyga, in the nsenter or outside?
<mvo> zyga: oh no
<zyga> ackk: outside please
<zyga> ackk: is this reported anywhere?
<zyga> ackk: I think  you might have already
<zyga> mvo: I think the tools problem is more severe
<ackk> zyga, http://paste.ubuntu.com/p/2MdPHqdyfd/
<zyga> mvo: with enough rotations I suspect we unmount /usr/lib/snapd from actively used namespaces
<ackk> zyga, I don't remember if I did report it, unfortunately I never found a reliable way to make it fail. since last time we talked about it, it hasn't happened anymore and I tried a loop of rsync's
<zyga> ackk: can you attempt to pinpoint when the issue occurred for you this time?
<zyga> ackk: in that log, at which time was it
<zyga> ackk: was it _before_ all of this?
<ackk> zyga, no, I mean I've "snap try"'d and removed a bunch of times
<ackk> zyga, but basically snap try , bunch of rsync -> broken
<ackk> zyga, I didn't snap try from an already installed snap, if that helps
<zyga> hmm
<zyga> hmm
<zyga> right
<zyga> I wonder if snapd refreshed in the middle of all the "snap try" commands anywhere
<Chipaca> mvo: pedronis: wrt downloads, if we want top drop action and change snaps to snap, we should do that before or together with 7510
<ackk> zyga, the snapd snap says refreshed 33d ago
<zyga> hmm
<zyga> in that case I know less, it's not my initial assumption
<pedronis> Chipaca: for clarity (hopefully) I wrote this, related to channel stuff, https://trello.com/c/GTSFCPG5/292-do-not-switch-tracks-with-risk-only-channel-specification-snap-refresh-switch#comment-5d9b456d31aa8d1b410bcdc2
<zyga> ackk: the maas snap has a configure hook?
<ackk> zyga, yes
<zyga> right?
<zyga> ok
<ackk> which does a lot
<zyga> so each snap try runs stuff
<ackk> zyga, correct
<zyga> ackk: can you please share the exact rsync command you are using
<zyga> I'll try to reproduce this with a demo snap with a configure hook
<mup> PR snapd#7559 opened: tests: change regex to validate access to cdn during snap download <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7559>
<ackk> zyga, https://paste.ubuntu.com/p/B69smBJ73N/
<ackk> zyga, where build/dev-snap/prime is the prime dir that gets snap try'd
<mvo> Chipaca: in a meeting right now
<zyga> and on the container you "snap try build/dev-snap/prime?
<ackk> zyga, correct
<zyga> ok
<zyga> hmm, for now I have no more ideas
<zyga> thank you for reporting this again
<zyga> I'll write a test tomorrow and see if I can hit something
<zyga> your host is 16.04 or something newer?
<zyga> the container was 18.04 IIRC
<bloodearnest> Chipaca: thanks, testing a new release now, will report back
<ackk> zyga, my host is bionic
<ackk> zyga, sorry, it's dingo
<zyga> ah, perfect.
<zyga> so I have the same setup readty
<zyga> ok, I'll keep you posted, thank you again
<ackk> zyga, thank you for the help
<pedronis> Chipaca: mvo: I would do that I think (I find the current state confusing with all the extra checks)
<pedronis> mvo: what's the status of this https://github.com/snapcore/core/pull/83 ?
<mup> PR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mvo> pedronis: I think it never got reviews :/
<mvo> pedronis: I can fix the conflict and double check that its up-to-date
<pedronis> mvo: reviews from whom? foundations?
<pedronis> there's a review by ogra fwiw
<mvo> sil2100: silly question, should the split of snapcore/pi3-gadget be on snapcore/pi-gadget (the "unified" one we use in core18)
<mvo> sil2100: actually I guess I should ask in the PR
<ogra> pedronis, well, more a yoga lesson :) but yeah ... +1 for that one
 * cachio lunch
<pedronis> zyga: is this being or was fixed: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1785410 ?
<mup> Bug #1785410: Can not open Gnome snaps as they are not connected to Â«gnome platform snapÂ» <amd64> <apport-bug> <bionic> <snapd:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1785410>
<mvo> Chipaca: I missed the earlier bits, what should happen with 7510? we remove "action=download"?
<Chipaca> mvo: either in 7510 or before it, we drop action and change snaps to snap
<mvo> Chipaca: ok, will do
<pedronis> mvo: probably best to call it snap-name,  we might have download by id
<mvo> pedronis: great advise
<zyga> pedronis: not sure if this instance, many similar issues were
<zyga> many issues having similar observable result
<zyga> I'll inspect that bug and respond
<pedronis> zyga: you made a card specifically about this one, that's why I'm asking: https://trello.com/c/CFDRWAg5/206-content-connection-issues-https-launchpadnet-bugs-1785410
 * zyga breaks to rest 
<mup> PR snapd#7560 opened: daemon: change /v2/download API to take "snap-name" as input <Created by mvo5> <https://github.com/snapcore/snapd/pull/7560>
<mvo> Chipaca: -^
<mvo> pedronis: a quick review on 7560 would be great, should be quick and simple
<pedronis> mvo: I was already looking at it
 * mvo hugs pe
 * mvo hugs pedronis 
<pedronis> pstolowski: this is done now, right?  https://trello.com/c/2lsJLlXB/316-revisit-fix-per-revision-snap-configuration-handling
<pstolowski> pedronis: yes
<pedronis> pstolowski: is it in 2.42 or will it be in 2.43 ?
<pedronis> Chipaca: this is done now:  https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 ?
<mup> PR snapd#7560 closed: daemon: change /v2/download API to take "snap-name" as input <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7560>
<mup> PR snapd#7561 opened: tests: update system-usernames test now that opensuse-15.1 works <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7561>
<Chipaca> pedronis: not yet, not in full
<cachio> zyga, hey
<cachio> zyga, I am trygin to fix an issue in opensuse
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/594484689#L1747
<pedronis> Chipaca: when you have a moment could you update it to reflect what is missing? or maybe create a new post if you think it's too old to reopen, in which case remove the tagging on the first, thank you
<cachio> it is just happening with the last update
<pstolowski> pedronis: 2.42. however it was only a small cleanup (not a fix)
<pstolowski> pedronis: i mean, nothing for release notes imho
<zyga> cachio: snapd is built without apparmor on opensuse leap
<zyga> that test should not run there
<zyga> cachio: check exclusion rules please
<cachio> zyga, systems: [-ubuntu-core-*, -debian-*]
<cachio> it is currently running on leap 15.1
<pedronis> pstolowski: thx, just wanted to know which done lane to use
<mup> PR snapcraft#2709 closed: incorporate content provider snaps in dependency resolution <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2709>
<joedborg> hey zyga, have you got 5 minutes?
<mup> PR snapd#7562 opened: tests: chech the apparmor_parser when the file exists on snap-confine test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7562>
<mup> PR snapcraft#2743 opened: meta: warn about command mangling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2743>
<mup> PR snapcraft#2744 opened: project_loader: load build-environment after snapcraft environment <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2744>
#snappy 2019-10-08
<mup> PR snapcraft#2744 closed: project_loader: load build-environment after snapcraft environment <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2744>
<mup> PR snapcraft#2745 opened: tests: introduce gtk3 test for gnome extension <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2745>
<NickZ> I hate npm so much
<mup> PR snapd#7561 closed: tests: update system-usernames test now that opensuse-15.1 works <Simple ð> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7561>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mborzecki> school run, back in 20 or so
<pokk> Good morning. Any updates to the rsync snap?
<mup> PR snapd#7559 closed: tests: change regex to validate access to cdn during snap download <Simple ð> <Created by sergiocazzolato> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7559>
<mborzecki> re
<pstolowski> morning
<zyga> o/
<zyga> joedborg: I do now, sorry for being absent last evening
<mborzecki> pstolowski: zyga: hey
<mborzecki> zyga:  some comments under #7547
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> thanks, looking
<zyga> thanks for spotting the odd mode, I'll change that
<zyga> the rest of the comments are easy to apply, I'll adjust that shortly
<mborzecki> mvo:  can you take a look at https://github.com/snapcore/snapd/pull/7557 ? could land easily
<mup> PR #7557: interfaces/mount: account for cgroup version when reporting supported features <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>
<zyga> brb
<mvo> mborzecki: yes
<mborzecki> mvo: thank you!
<mup> PR snapd#7557 closed: interfaces/mount: account for cgroup version when reporting supported features <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>
<mborzecki> mvo: system-key has a Version field witha comment that need to bump it when adding new inputs, however it looks like we never bumped when adding new fields
<mborzecki> mvo: this field https://github.com/snapcore/snapd/blob/master/interfaces/system_key.go#L60
<mvo> mborzecki: uh, right - we should
<mvo> mborzecki: in a meeting right now
<Chipaca> mborzecki: we could set it using reflect (or, maybe better, test it using reflect)
<Chipaca> mborzecki: i'll push a pr to do that
<mborzecki> Chipaca: yeah, that's another point, we unmarshal and then test, assuming we can actually unmarshal the thing
<Chipaca> mborzecki: in the tests you mean? or where?
<mborzecki> Chipaca: https://github.com/snapcore/snapd/blob/master/interfaces/system_key.go#L210
<pstolowski> degville: hey, can you update https://bugs.launchpad.net/snappy/+bug/1823343 and/or reassign to appropriate project if neccessary?
<mup> Bug #1823343: Getting Started Intro out of date <Snappy:New> <https://launchpad.net/bugs/1823343>
<mborzecki> Chipaca: it's assume that the old format can be unmarshalled into the new struct, not sure if it's worth to make it super safe though
<Chipaca> mborzecki: what would you do differently there?
<Chipaca> I mean, I'd look at unmarhsaling from the file and using .More() etc but still
<Chipaca> mborzecki: it assumes it's backwards-compatible which doesn't seem like too much of a stretch (and we can/should test for it)
<mup> Bug #1781789 changed: snapctl doesn't advertise that it's an internal tool <snapd:Confirmed> <https://launchpad.net/bugs/1781789>
<mborzecki> Chipaca: super safe would probably be unmarshal into a struct with a single Version `json:"version"` field, or map, though as i wrote, it's probably not worth it and assuming backwards compat is reasonable (we control the format after all and it's quite simple)
<mup> Bug #1805162 changed: Impossible to get newly settled props <configure> <props> <snapctl> <snapset> <validation> <snapd:New> <https://launchpad.net/bugs/1805162>
<zyga> brb
<mup> Bug #1746564 changed: snapd should not allow --classic installation for snaps with strict confinment mode <Snappy:Fix Released> <https://launchpad.net/bugs/1746564>
<degville> pstolowski: will do - thanks!
<Chipaca> huh, in 304d3a72ed68fb00cd3afec27bc302c618d1ed1a we dropped 'core' from systemKey
<zyga> small break as Lucy just has to be on my hands having saw me
<mup> Bug #1781790 changed: snapctl start gives error message that is useless to beginners, and nothing of it is explained in --help or a man page (which doesn't seem to exist) <Snappy:New> <https://launchpad.net/bugs/1781790>
<abeato> pedronis, hi, would it be possible to update https://forum.snapcraft.io/t/the-gadget-snap/696 with the new role types that ondra introduced for lk?
<abeato> pedronis, I think I can do the edit if you are fine with that
<mup> Bug #1803002 changed: Multiple SELinux alerts on install / uninstall on Fedora 29 <Snappy:Fix Released> <https://launchpad.net/bugs/1803002>
<mup> PR snapd#7563 opened: interfaces: bump system-key version (and keep on bumping) <Created by chipaca> <https://github.com/snapcore/snapd/pull/7563>
<Chipaca> mborzecki, mvo, maybe something like this ^
 * pstolowski walk, bbiab
<mborzecki> Chipaca: why 9 though? :)
<Chipaca> mborzecki: git log -p interfaces/system_key.go
<mborzecki> Chipaca: fair enough
<Chipaca> mborzecki: and count fields added/removed
<Chipaca> there's 8 additions and 1 removal
<Chipaca> mborzecki: also, it just lines up with the number of fields
<Chipaca> so, yay for coincidences
<mup> PR snapd#7564 opened: interfaces: add cgroup-version to system-key <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
<Chipaca> mbuahah
<mborzecki> Chipaca: ok, so ^^ depends on your PR
<Chipaca> aww
 * Chipaca likes it when nice things are said about code he wrote
<pedronis> abeato: yes, please do edit, and ping me when is done, I can check
<mborzecki> pedronis: do you think we should explicilty error out on mon1-mon1 (which is the same as mon1)?
<abeato> pedronis, cool, will do
<pedronis> abeato: (I was in meeting)
<abeato> :)
<pedronis> mborzecki: seems unlikely enough that it might make sense, can be a follow up though
<mborzecki> pedronis: ok, i'll push the tweaks only then, and leave this for the next PR
<mborzecki> pedronis: updated #7443
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<abeato> pedronis, I've updated https://forum.snapcraft.io/t/the-gadget-snap/696 now
<mvo> Chipaca: really nice PR!
<mvo> mborzecki: reading backlog now
<Chipaca> I need to go move my car, will bbiab
<mborzecki> zyga:  hmmm https://paste.ubuntu.com/p/7KmCHRxVGC/ that's on disco
<mborzecki> zyga:  it's as if snap.mount was started after snap-core-*.mount
<thresh> howdy.  is there are repo for 18.04 with a recent snapcraft in .deb?
<abeato> sil2100, I have updated and added comments to https://github.com/CanonicalLtd/ubuntu-image/pull/175
<mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
<mup> Bug #1652265 changed: Initialization changes are removed right after first boot <Snappy:Invalid> <https://launchpad.net/bugs/1652265>
<mup> Bug #1654130 changed: Adding a tag indicating manual connection is needed when displaying interfaces <snapd:Triaged> <https://launchpad.net/bugs/1654130>
<mup> PR snapd#7565 opened: snap-repair: add addtional comment about trust in runner.Verify() <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7565>
<mup> Bug #1750840 changed: [Enhancement] Please show (optionally) size consumed by snap in snap list <enhancement> <Snappy:New> <https://launchpad.net/bugs/1750840>
<mup> PR snapd#7566 opened: snap-repair: add missing check in TestRepairBasicRun <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7566>
<pstolowski> degville: another one: https://bugs.launchpad.net/snappy/+bug/1790153 (i've no idea if the suggestion for the bug report is correct, may need verification)
<mup> Bug #1790153: Documentation: easy-openvpn typos <Snappy:New> <https://launchpad.net/bugs/1790153>
<Chipaca> pstolowski: WRT comparing keys with deepequals, the issue is that current code assumes that a key that looks at some aspect and determines it to correspond with go's default value (e.g. an empty list), and a key that doesn't look at that aspect at all, compare as equal when they're not
<degville> pstolowski: thanks - I'll check and update.
<pstolowski> Chipaca: hmm i see, ok
<pstolowski> degville: sorry, one more: https://bugs.launchpad.net/snappy/+bug/1749538
<mup> Bug #1749538: refresh time docs lacks the correct command <docs> <Snappy:New> <https://launchpad.net/bugs/1749538>
<pedronis> zyga: hi, I sent you a non-urgent email about forum gardening
<degville> pstolowski: it's no problem, but the bigger issue is these are for Core Docs which have many more problems than these small issues, all of which is being worked on separately (the 'report issue' link on those pages goes to Snappy on LP, which is why we're getting them).
<mvo> pedronis: I sent the mail about repair assertion test now and CCed you
<mvo> pedronis: hope it did reach you :)
<pedronis> mvo: saw it
<pstolowski> degville: uhm, i see. can they be re-assigned manually to Core Docs then?
<degville> pstolowski: not sure there's a single entity we can assign them to.
<mvo> pedronis: great, no action needed just wanted to double check that my mail setup is happy again
<zyga> pedronis: ack
<degville> pstolowski: I'll bring it up in the standup, but I think it's probably best these are won't fix while we wait for the updated Core Docs to be published and replace these old ones.
<mup> PR snapd#7567 opened: snap-repair: error if run as non-root <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7567>
<mup> PR snapd#7568 opened: snap: when running `snap repair` without arguments, show hint <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7568>
<Chipaca> is there a way to get apparmor confinement working in debian? (in a forum-explainable way)
<mup> PR snapd#7552 closed: tests: add new option "invert" to retry-tool <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7552>
<Chipaca> if so please https://forum.snapcraft.io/t/use-classic-confinement-for-dynocsv-app/13543/10?u=chipaca
<sil2100> abeato: thanks!
<Chipaca> mborzecki: #7564 has conflicts
<mup> PR #7564: interfaces: add cgroup-version to system-key <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
<mup> PR snapd#7563 closed: interfaces: bump system-key version (and keep on bumping) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7563>
<mborzecki> Chipaca: ack, thx
<Chipaca> mborzecki: :-)
<mup> PR snapd#7256 closed: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<dot-tobias> ogra: Do you have experience with USB WiFi dongles on Raspberry Pi 3B/3B+ running Ubuntu Core? I'm planning to add dual interface support to my gadget, currently investigating proper dongles since the official Raspberry one is now EOL
<mup> PR snapd#7569 opened: snap: remove limit of 32 characters for version <Created by cjp256> <https://github.com/snapcore/snapd/pull/7569>
<mup> PR snapd#7570 opened: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
<ogra> dot-tobias, not with core, i have used dongles before on a pi2, if you get one the kernel supports OOTB it should just work on core though
<dot-tobias> ogra: Thanks! Do you happen to know where I can find info which ones have kernel support (I guess chipset names)?
<ogra> (i used to use a wired USB dongle on my dragonboard with core for quite some time ... that worked well too, i dont see a reason why a wlan one should be any different (as long as there is a driver in the kernel)
<ogra> hmm not really ... i think asix and realtek might be a good bet
<mborzecki> Chipaca: i've updated #7564
<mup> PR #7564: interfaces: add cgroup-version to system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
<mup> PR snapd#7569 closed: snap: remove limit of 32 characters for version <â Blocked> <Created by cjp256> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7569>
<Chipaca> 2fa...
<mup> PR snapcraft#2746 opened: elf: handle missing dependencies not found on system <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2746>
<zyga> rogpeppe: flashing now
<zyga> mvo: ^ that magic SD card
<zyga> mborzecki: I fixed the instance problem
<mup> PR snapd#7571 opened: sandbox/cgroup: refactor process cgroup helper to support v2 and named hierarchies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7571>
<mborzecki> zyga: ^^ prepping up for named hierarchy
<vidal72[m]> is there an official way to pass additional env var to snap, like flatpak --env=xxx?
<Chipaca> vidal72[m]: in what sense?
<Chipaca> vidal72[m]: usually if it's an app, it'll get most of your environment as is
<Chipaca> vidal72[m]: if it's a service, you can use 'systemctl edit'
<vidal72[m]> Chipaca: I want to add anv env which isn't in global environment
<Chipaca> vidal72[m]: as a user, or as a packager?
<vidal72[m]> user
<Chipaca> vidal72[m]: FOO=bar the-thing-to-run
<vidal72[m]> yeah, however this work only if I run it directly
<Chipaca> vidal72[m]: as opposed to what?
<vidal72[m]> btw is TMPDIR honored by snap?
<Chipaca> no
<Chipaca> bah
<Chipaca> no, but
<Chipaca> the snap binary will get it
<Chipaca> so it's up to that
<Chipaca> that is: if you do TMPDIR=/foo/bar some-snapped-app
<Chipaca> snap won't do anything with TMPDIR, but will pass it in
<vidal72[m]> Chipaca: as opposed to some launcher
<Chipaca> whether soem-snapped-app does something with it is up to that app
 * Chipaca checks
<Chipaca> actually that might be wrong
<vidal72[m]> I wondered because TMPDIR is usually dropped by suid binaries
<Chipaca> yeah it looks like TMPDIR and TEMPDIR are not passed in
<Chipaca> ah well
<Chipaca> vidal72[m]: was that the env var you were wanting to set?
<vidal72[m]> one of them :)
<Chipaca> vidal72[m]: you could copy (or edit in place) the generated .desktop file
<Chipaca> vidal72[m]: it'll be in /var/lib/snapd/desktop/applications
<vidal72[m]> yes, however if desktop file changes with some update I will miss it
<Chipaca> vidal72[m]: if you go for 'copy', copy it to ~/.local/share/applications, but be mindful of refreshes
<Chipaca> exactly
<mvo> zyga: omg! I can't wait to see/hear results
<vidal72[m]> my concrete use case was opening files in external apps in firefox which needs both GTK_USE_PORTAL and TMPDIR
<vidal72[m]> unfotunately for what I read snap thinks it's mozilla issue to solve and mozilla thinks it's snap's :)
<mup> PR snapcraft#2742 closed: cli: use click utilities for login prompts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2742>
<Chipaca> vidal72[m]: ?
<Chipaca> vidal72[m]: it's not just a matter of setting env vars
<vidal72[m]> does snap support xdg-portal?
<Chipaca> vidal72[m]: yes
<Chipaca> wait
<Chipaca> no
<Chipaca> vidal72[m]: no
<Chipaca> not yet
<vidal72[m]> ah
<Chipaca> vidal72[m]: it's almost all there though
<Chipaca> vidal72[m]: (on master)
<Chipaca> in fact i think master might already have all the bits
<Chipaca> hm, there might be a couple of PRs still pending
<Chipaca> vidal72[m]: jamesh knows more (probably asleep now though)
<vidal72[m]> anyway for FF the problem is namespaced /tmp and lack of TMPDIR override
<vidal72[m]> so even with xdg-portal support it won't work
<vidal72[m]> https://forum.snapcraft.io/t/sharing-files-via-tmp/1613/15
<Chipaca> vidal72[m]: I don't think namespaced tmp will break once we have portals, I don't see how it would, but if it does we can probably fix it
<Chipaca> vidal72[m]: that topic is not about portals at all
<zyga> mvo: I need to clean my desk :D
<vidal72[m]> Chipaca: well it break even flatpak
<zyga> mborzecki: ack
<zyga> looking now
<vidal72[m]> which jas full portal support
<mvo> xnox: is it a known issue that "test memory" on the eoan daily installier just gives an error and does not load anything?
<vidal72[m]> the thing is FF/TB always saves temp files to /tmp or TMPDIR and they won't be visible for any other app
<Chipaca> vidal72[m]: and what does that have to do with portals?
<mvo> xnox: ups, that is disco, flashed the wrong thing
<vidal72[m]> Chipaca: the portal passes file app can't reach and fail
<vidal72[m]> what they do in flatpak is setting TMPDIR=xxx in wrapper
<ogra> well, that wouldnt work in snaps
<ogra> since /tmp is a very special dir inside the confinement
<xnox> mvo:  yes
<xnox> mvo:  are you on bios or uefi?
<vidal72[m]> ogra: the point is to set something else than /tmp
<zyga> mborzecki: reviewed, please check
<ogra> while you could set $TMPDIR it could point only to some dir inside the confined area anyway ...
<vidal72[m]> ogra: Chipaca like this https://src.fedoraproject.org/rpms/firefox/blob/0adc4aecec45e195b0f6cbcdb1625839846482bc/f/firefox.spec#_710
<mvo> xnox: uefi
<mvo> xnox: is it just a problem on uefi?
<Chipaca> ogra: well, snap-confine has special handling of TMPDIR and TEMPDIR, so
<ogra> vidal72[m], where would you set it to ? it wouldnt be any dir thats accessible on the filesystem because it lives in the confined space
<vidal72[m]> ogra: yes but not every dir is namespaced likr /tmp
<ogra> so something outside of that space wouldnt see it
<xnox> mvo:  not really. It's just there is a uefi app we ship that one can execute for memory testing on uefi.
<xnox> mvo:  not sure if that is hooked up correctly w.r.t. secureboot etc. at one point it wasn't.
<xnox> in general it should work
<xnox> mvo:  is your machine busted? and can you run the vendor's self-test from bios stuff?
<mvo> xnox: ok, once I finished flashing eoan I will give it a go and if it fails pester someone - who is the best person?
<vidal72[m]> ogra: does snap namespace /run/user/$uid?
<mvo> xnox: not busted, just wanted to play with it to see if memory is stble
<xnox> mvo:  cyphermox who is off today i think. or just open a bug against
<ogra> Chipaca, sure, the point is that the portal runs on your desktop, unconfined ... while FF runs inside the confined space ....
<mvo> xnox: cool, will give it a go, thank you! (usb stick takes forever to write :/
<xnox> mvo:  against shim
<Chipaca> i'm off to the doc's
<Chipaca> ttfn
<mvo> xnox: ta
<Floflobel_> hello, how can I see the history of all "refresh" that snapd has performed?
<vidal72[m]> ogra: https://forum.snapcraft.io/t/firefox-url-handler-does-nothing/5329/6 and https://bugzilla.mozilla.org/show_bug.cgi?id=1461759
<ogra> vidal72[m], you could try pointing FF to $SNAP_USER_DATA (which translates to ~/snap/firefox/current/)
<ogra> thats one of the two dirs that can be used to share data with the host
<ogra> (the other is $SNAP_DATA but thats only root writable (for services/daemons and such))
<vidal72[m]> yes, but but it have to be done through TMPDIR=$SNAP_USER_DATA and this is blocked
<vidal72[m]> unless you add it to shell wrapper
<vidal72[m]> which will be overwrittent with update...
<zyga> vidal72[m]: please file a bug with the details and I will consider it
<vidal72[m]> zyga: I linked to opened bugs
<zyga> vidal72[m]: thanks, I'll add them to my backlog
<zyga> vidal72[m]: I'm debugging something else and I cannot focus on this problem but I want to say I'm interested
<vidal72[m]> I think it's mozilla job but they don't seem to agree
<vidal72[m]> zyga: no problem, thx
<ogra> vidal72[m], well, i'm pretty sure the issue is that you try to override it ... if TMPDIR was simply set in the snapcraft.yaml of the firefox snap i bet it would work ... so yeah, that would be a firefox issue after all ... us lacking a mechanism to override would be our issue (though i guess that will need some deep securit review first)
<vidal72[m]> does TMPDIR from snapcraft.yaml passes through snap suid binary?
<zyga> vidal72[m]: no but there's a mechanism to do so
<zyga> vidal72[m]: there's a pass-through system
<zyga> vidal72[m]: it may also be a bug that setting TMPDIR is not respected in practice but that's a simple fix if so
<vidal72[m]> flatpak has same issue if bubblewrap is installed as suid https://github.com/flatpak/flatpak/issues/2641
 * cachio lunch
<mup> PR snapd#7572 opened: gadget: rename "boot{select,img}" -> system-boot-{select,image} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7572>
<mvo> xnox: memtest works on eoan usb installer, sorry for the noise. but a different question I installed eoan now (on real HW) on an uefi system with the default installer options and it looks like it did not create a uefi system partition for me - didn't it do that in the past?
<xnox> mvo: there usually is one already, and we always reuse it.
<xnox> mvo:  so didn't create => do you mean you have no esp and booted the usb stick in bios mode?
<mvo> xnox: its a fresh disk with nothing on it
<xnox> mvo:  give me your /var/log/installer/
<mvo> xnox: I might have booted in bios mode
<xnox> mvo:  how did you create the usb stick?
<mvo> xnox: I selected boot menu and usb stick but that might have triggered bios
<mvo> xnox: let me retry this
<xnox> mvo:  boot menu may list the usb stick multiple times.
<mvo> xnox: do you still want the log?
<xnox> mvo:  pick the one that sounds fanciest.
<xnox> mvo:  just try rebooting
<mvo> xnox: doing now
<xnox> mvo:  also you might want to disable legacy boot fallback in bios
<mvo> xnox: uefi makes this all rather annoying
<xnox> mvo:  cause then it will not show you the bios boot options of the stick
<mvo> xnox: sometimes I wonder how our users manage to install stuff :/
<xnox> unfortunately we kind of have to make the sticks "dual-bios-uefi" bootable
 * mvo is maybe just getting dumb
<xnox> mvo:  they go to azure.com and click the biggest orange button they see
<mvo> xnox: hahaha
<mvo> xnox: yeah, selecting the "other" usb stick in the boot menu did the trick, thanks again and sorry for the noise
<mup> PR snapcraft#2747 opened: nodejs plugin: fix errors when building in confinement <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2747>
 * Chipaca â dinner
<mvo> Chipaca: 7533 could do with a re-review, hopefully I addressed all your points
<mup> PR snapd#7533 closed: client: add support to use the new "download" API <Needs Samuele review> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7533>
<mup> PR core-build#55 opened: Drop abootimg support, not used anymore <Created by xnox> <https://github.com/snapcore/core-build/pull/55>
<mup> PR snapd#7565 closed: snap-repair: add additional comment about trust in runner.Verify() <Needs Samuele review> <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7565>
<mup> PR snapd#7510 closed: daemon: make /v2/download take snapRevisionOptions <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7510>
<mup> PR snapd#7573 opened: [RFC] client: add support for the new "/v2/assertions/%s?remote=true" <Created by mvo5> <https://github.com/snapcore/snapd/pull/7573>
<mup> PR snapd#7574 opened: [RFC] client: add KnownOptions to Know() and support remote assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7574>
<mup> PR snapd#7575 opened: cmd/model: add authority-id to verbose fields <Needs Samuele review> <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7575>
#snappy 2019-10-09
<zyga> good morning
<mborzecki> zyga: morning
<zyga> hey :)
<mborzecki> mvo: hey
<mvo> hey mborzecki
<zyga> hey mvo
<zyga> quick comment, do you remember the remodel kernel work? there's a test that reliably fails in osc build, there's a trello card for it
<zyga> I wanted to look now but if you know more I'd love to get help
<mvo> zyga: can you point me to the log?
<mvo> zyga: the remodel kernel test takes a while iirc, we had to increase the settle timeout on arm
<mvo> zyga: is it maybe that?
<zyga> that's the same tet
<zyga> but it failed on my xeon ;D
<mvo> also with a timeout?
<zyga> it's hard to say, there's very little useful stuff when settle fails
<zyga> I complained that it should not be time-based at all but this is not a simple problem to solve
<zyga> mvo: https://trello.com/c/foU3iOrs/321-investigate-testremodelswitchtodifferentkernel-failure
<zyga> mvo: the whole output is
<zyga> https://www.irccloud.com/pastebin/8NhFWypY/
<mvo> zyga: this happens on your opensuse as well?
<zyga> no, it only happens in 'osc build'
<zyga> though my master is "after" 2.42
<mvo> zyga: is it easy to submit test builds? I could add something that prints more debug
<zyga> mvo: it's not remote
<zyga> it's local
<zyga> mvo: it's like dpkg-buildpackage
<zyga> mvo: anything extra can be added, just make a patch against 2.42
<zyga> mvo: if you push a branch I can extract the patch and run it easily
<zyga> mvo: I would like to make some general changes to the tests later on
<zyga> though I doubt this will be fasst
<zyga> 1) log all handlers that executed during failed test
<zyga> 2) change settle in tests to just do more stuff as long as handlers want to run, remove the timeout entirely
<zyga> 3) patch tests that measure failure to introduce callback to break further loops
<zyga> current time based code is simply not reliable and not engineered correctly as tests IMO
<pstolowski> mornings
<zyga> pstolowski: hey :)
<zyga> man, I'm so sleepy today
<zyga> the rain, the low pressure
<zyga> coffee, sorry
<mvo> hey pstolowski - good morning!
<zyga> mvo: sorry if I came across cranky, I just think we need to acknowledge shortcomings and not just paper over them with "this is how it's been done"
<mvo> zyga: not cranky at all
<mvo> zyga: let me just finish this one thing here and then I can do something, probably something like for _, t := range chg.Tasks() { fmt.Printl(t.Kind(), t.Status()) }
<zyga> yeah
<zyga> flashing the card again, last night I had issues and somehow I could not get the card to copy from macos
<zyga> (new sandbox for all apps)
<zyga> mvo: macos catalina switched to ... read only image as root filesystem
<zyga> mvo: yeah :)
<zyga> mvo: ubuntu personal
<zyga> mvo: /Users (/home for macos) and /Applications are writable
<zyga> rest is not
<zyga> and they live on a different apfs dataset (like zfs thing)
<mborzecki> zyga: updated #7571
<mup> PR #7571: sandbox/cgroup: refactor process cgroup helper to support v2 and named hierarchies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7571>
<zyga> checking
<mborzecki> zyga: is there a place like /var/log on osx where system logs land? wonder how it's combined with the read only filesystem image
<zyga> mborzecki: actually macos has /home /var /usr and all that
<zyga> they are just hidden
<zyga> this is the current mount table
<zyga> https://www.irccloud.com/pastebin/r4LiHBk7/
<zyga> mborzecki: and yeah, there is /var/log
<zyga> mborzecki: this is also interesting
<zyga> https://www.irccloud.com/pastebin/fRUAdcOV/ls%20-la%20%2F%20
<zyga> note that /home is /System/Volumes/Data/home
<zyga> where Data is the new writable part of apfs
<zyga> mborzecki: the new PR looks nice
<zyga> mborzecki: approved
<mborzecki> zyga: thx
<pedronis> mvo: hi, I made this comment:  https://github.com/snapcore/snapd/pull/7538#issuecomment-539882778 let me know if you prefer me to go over line by line
<mup> PR #7538: tests: use `snap model` instead of `snap known model` in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7538>
<mup> PR snapd#7575 closed: cmd/model: add authority-id to verbose fields <Needs Samuele review> <Simple ð> <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7575>
<mvo> pedronis: thanks, looking now
<mvo> pedronis: no need to go over it line by line, thanks, I will make the changes
<mvo> zyga: I created github.com/mvo5/snappy:debug-remodel-kernel-zyga with some extra debug (quite small right now). please run when you get a chance and let me know what it outputs
<zyga> mvo: thank you
<zyga> mvo: I've rebased on 2.42, trying now
<zyga> mvo: new log https://www.irccloud.com/pastebin/EUXdHkdl/
<mvo> zyga: aha, looks like something in the mock restart is not working
<zyga> mvo: I'm logged into the image from rogpeppe
<zyga> refreshing snaps now
<zyga> we'll know in a second if it crashes on reboot
<rogpeppe> zyga: sometimes it doesn't :)
<zyga> rogpeppe: fingers crossed
<zyga> I have serial output
<zyga> so we'll know what is attempted at least
<rogpeppe> zyga: the other thing is that it surely shouldn't be rebooting very often
<zyga> and I should send the raspi-tool to snapd into some contrib/ directory
<rogpeppe> zyga: how often would you expect? is it usual for it to try to reboot once or twice a day?
<mvo> zyga: will look into this a little bit
<zyga> rogpeppe: not sure, one sec
<zyga> Chipaca: from that device
<mvo> rogpeppe: the only valid reason to reboot that often is if it tracks edge for core/kernel everything else is most likely a bug
<zyga> Chipaca: system-shutdown messages https://www.irccloud.com/pastebin/sSWsFr69/
<mvo> rogpeppe: thank you so much for helping us tracking this down!
<mvo> zyga: thank you, super curious about this
<rogpeppe> mvo: i hope you do! :)
<zyga> rogpeppe: it updated to 2.42 correctly
<Chipaca> zyga: those messages are fine
<zyga> ok
<zyga> oh
<zyga> it reboots instantly?
<zyga> what?
<zyga> I snap refreshed
<zyga> it rebooted
<zyga> then it reboots again
<zyga> straight away
<zyga> mvo: suggestion for improvement
<zyga> mvo: uboot script should log basics
<zyga> like booting that kernel and this base
<zyga> and in this mode
<zyga> would be great to see
<zyga> mvo: snapd change after update
<zyga> it seems that 2nd reboot was the only one
<zyga> snap change on successful 2nd reboot https://www.irccloud.com/pastebin/4X2z8O6R/
<zyga> I'll reboot manually to see if it boots ok
<zyga> rogpeppe: sadly, it works :/
<pedronis> mborzecki: question in #7443
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<zyga> rogpeppe: I'll leave it running
<rogpeppe> zyga: one thing you could do is just leave it running
<rogpeppe> zyga: lol
<zyga> rogpeppe: to see how it ages for a few days
<zyga> :D
<rogpeppe> zyga: yup. i guess it might be that we've got two pi's both with buggy h/w
<zyga> rogpeppe: could it be the SD card?
<Chipaca> could it be that the additional hardware somehow destabilises the pies?
<rogpeppe> zyga: i used a different SD card too
<zyga> interesting
<zyga> how is the hardware connecteD?
<rogpeppe> zyga: and it's a decent quality SD card, not much used.
<rogpeppe> zyga: connected to the network?
<zyga> no, any custom stuff added to your pi?
<zyga> not network
<rogpeppe> zyga: nothing custom added
<Chipaca> there goes that hypothesis then :)
<rogpeppe> zyga: there was an RTC and a pi-glow on the old pi, but not on this one
<zyga> I can send you my pi if you want to swap :)
<rogpeppe> zyga: that's an interesting thought. the other thing i might try (sorry) is to use a different OS.
<zyga> that would be an interesting data point as well
<pstolowski> Chipaca: hey, health-check task is not executed on install if flags&skipConfigure != 0 (because we return early and don't schedule config hook - see the bottom of doInstall); intended or a bug?
<mborzecki> pedronis: iirc it's not strictly needed, though i kind of highlights the thing happens every day
<pedronis> mborzecki: highlights or confuses people like me :)
<mborzecki> pedronis: hah ok, i can drop it
<pedronis> mborzecki: one possible reading is that it triggers every day of the month
<pedronis> anyway with /1
<pedronis> the "spec" is not great
<mborzecki> duh, it is not :/
<pedronis> mborzecki: if it's not strictly needed I would drop it, less mental burden to read it. The spec says " Values may be suffixed with "/" and a repetition value, which indicates that the value itself and the value plus all multiples of the repetition value are matched. Two values separated by ".." may be used to indicate a range of values; ranges may also be followed with "/" and a repetition value." of which I'm not sure how to
<pedronis> interpret in practice
<mborzecki> i'm looking at the spec, and we may have a bug there, at laest on older systemd versions
<mborzecki> there's no .. range on xenial :/
<mborzecki> but out snap with timers does not fail, so, the bug is only for numbered ranges
<mborzecki> another conclusion is that since we had no bug reports or complains about snap install failing, then people do not use it at least in snap.yaml
<pedronis> mborzecki: we'll need to update this, right? https://forum.snapcraft.io/t/timer-string-format/6562
<mborzecki> yes
<pedronis> also  before you could do mon1-fri2,  right?   now you need something like  mon1-sun,,mon2-fri ?
<mborzecki> yes, mon1-fri or mon-fri2 (or mon2-fri)
<mborzecki> so at most the range can describe 8 days, eg mon1-mon
<pedronis> ok, not sure I'm worried,  also the other one does quite do the same thing
<pedronis> just making sure I understand
<pedronis> *does not quite do
<mvo> zyga: I updated the kenrel-remodel debug PR, will probably produce a lot of output now, could you please run it?
<zyga> sure
<zyga> one sec
<zyga> mvo: try to rebase on 2.42 next time
<pedronis> zyga: mvo: are you looking into TestRemodelSwitchToDifferentKernel ?
<zyga> mvo: building now
<mvo> pedronis: yeah, it seems to fail for zyga in obs
<zyga> pedronis: mvo is really, I'm just the test runner
<zyga> mvo: in osc, not obs (I didn't push yet)
<mvo> pedronis: its a bit strange I cannot reproduce and I'm a bit lost
<pedronis> there's a card, I will move it and put you on it
<zyga> osc - dpkg-buildpackage, obs -> that thing in the cloud
<zyga> mvo: new log coming up
<mvo> zyga: thanks, is there an ocd as well?
<zyga> ocd? :D
<mvo> zyga: just kidding
<zyga> hahaha
<zyga> I was suspecting some :D
<mvo> zyga: we also have obi here
<mvo> zyga: SCNR
<zyga> same here
<zyga> very useful
<zyga> SCNR?
<mvo> zyga: sorry-could-not-resist
<mvo> zyga: these short acronyms are just too hard for me to remember :)
<mvo> zyga: anyway, hope it gives me clues but I have *no* idea right now
<pedronis> I can look as well at some point if it remains a mystery, not quite right now
<pedronis> though
<zyga> mvo: the log is large and got truncated from my screen, give me a sec to grab it from disk
<mvo> zyga: only the bits before the test failure are of intersst
<mvo> zyga: you could also modify the buld to just run the remodel test during the build
<zyga> the build takes a second, it's just the timeout that we are waiting for
<pedronis> pstolowski: in practice we use SkipConfigure only in firstboot code, doesn't really answer either way
<zyga> ok, collecting now
<mvo> mborzecki: 7572 has an arch specific failure in the spread logs that I have not seen before, could you please have a look before I restart the build?
<mvo> mborzecki: (not urgent :)
<Chipaca> pstolowski: bug
<pedronis> Chipaca: pstolowski: notice that in practice we don't want that behavior, is right now immaterial, we don't want to run health-checks before at least the essential snaps are installed, so what we do for configure there, would apply also for health-checks
<pedronis> so in practice is a feature, just obscurely expressed
<pstolowski> pedronis: true
<ogra> mvo, zyga, ondra showed me a bootchart yesterday and we noticed that there are a gazillion unsquashfs calls during seeding ... why is that (i.e. if we extract metadata or some such, why dont we mount/umount the squashfs and cp the file which is a ton times faster and less CPU hungry)
<zyga> ogra: we unsquash to look at info AFAIR
<ogra> right, thats was my guess
<zyga> ogra: but yeah, I agree
<pedronis> pstolowski: basically renaming the flag SkipConfigureAndHealthCheck would also work
<ogra> *that
<Chipaca> ogra: at one point we determined it to be cheaper to unsquash it to extract just one file, than to mount it
<mvo> we also do some checks before we consider a snap safe to mount but I don't remember the specifics there for firstboot
<zyga> we could save on one op entirely by mounting to /tmp/$RANDOM and then moving the mount over to final location
<zyga> mvo: IMO our checks are not in the "safe to mount" category
<zyga> mvo: it's valid vs invalid but not safe
<pedronis> either way, we will do nothing without measuring
<pedronis> also it's a delicate area under churn
<pedronis> so also nothing very soon
<pedronis> ogra: I recommend to create a forum topic with some of those logs, and we'll see
<ogra> Chipaca, well, on first boot of a low end system it significantly eats CPU
<zyga> mvo: it's still running, it's odd - I had a look at the log file it's running under now and it keeps printing open /dev/null and open /bin/false
<Chipaca> ogra: yes. I sent an email about this three years ago.
<Chipaca> ogra: I profiled it
<zyga> mvo: the log is crashing pastebin :D
<zyga> one sec
<mvo> zyga: heh, I just need the last few lines
<mvo> zyga: well, I need to see why its not converging, i.e. what it tries to run over and over again
<zyga> [  618s] trying to run: runMgrForever Doing 1... []
<zyga> [  618s] trying to run: runMgrForever Doing 1... []
<zyga> [  618s] trying to run: runMgr1 Do 1... []
<zyga> [  618s] trying to run: unknown Do ... []
<pedronis> runMgrForever is in overlord_test.go ?
<pedronis> no managers_test.go
<zyga> there's a long sequence of those
<zyga> but earlier there's also this
<pedronis> do we have a test that doesn't clean up?
<zyga> https://www.irccloud.com/pastebin/8PTTypwd/
<pedronis> anyway it seems unrelated
<zyga> then there's a long wall of
<mvo> zyga: how big is the log? maybe you can put it into google drive?
<zyga> sure, one sec
<mvo> zyga: something along the lines of "] Done link-snap Make snap "brand-kernel" (2) available to the system [2019-10-09T08:11:58Z INFO Requested system restart.]" is what I'm hoping for
<zyga> gedit hangs for a while while pasting
<zyga> 2019
<Chipaca> ogra: mail subject 'booting the pi', 26 Jan 2017
<Chipaca> ogra: fwiw
<zyga> mvo: 32M
<zyga> mvo: uploading now
<mvo> zyga: woah
<ogra> Chipaca, hmm, that talks about sha3 and keccac
<Chipaca> ogra: yes
<Chipaca> ogra: having profiled, those were the slow things
<Chipaca> ogra: that's what we mean by 'we will do nothing without measuring': measure first, determine what is slow, see how to improve it
<Chipaca> ogra: optimising away the calls to mskquashfs will do nothing if those calls are not the thing slowing down first boot
<Chipaca> unsquashfs*
<Chipaca> of course, it's entirely possibe that those calls are now slow
<Chipaca> but after having received exactly 0 responses to my original mail I'm not going to waste time on this again
<ogra> Chipaca, well, they eat CPU via userspace while mount/umount via the kernel dont
<ogra> the outcome of your mail was in the end that ijohnson developed assembly to improve sha3 (even though that has never been merged or is in use anywhere still)
<mup> PR snapd#7538 closed: tests: use `snap model` instead of `snap known model` in tests <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7538>
<mup> PR snapd#7566 closed: snap-repair: add missing check in TestRepairBasicRun <Simple ð> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7566>
 * mvo hugs pedronis 
<pedronis> mvo: #7568 needs a tweak (or I am confused)
<mup> PR #7568: snap: when running `snap repair` without arguments, show hint <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7568>
<pedronis> there is some mark down in the error message which I don't think we do
<pedronis> heh, Markdown
<mvo> pedronis: sure, let me fix this
<mborzecki> grr old systemd
<ondra> Chipaca I'm collecting some bootcharts I can share with you
<ondra> Chipaca those are the one ogra mentioned
 * zyga is somewhat hungry
<zyga> making progress on cgroup branches, I'll have something to share soon
<zyga> trying to eliminate the extra binary now
<zyga> well, it works, just needs some cleanup still
<zyga> mborzecki: ^ FYI
<Chipaca> ondra: I'm not sure what you expect to do with them though
<zyga> heh, I just noticed that we have cmd/snapd-generator that claims to be snapd-workaround-generator
<Chipaca> ondra: ogra: if I'm reading the bootcharts right, the unsquashfs calls are not a big contributor to the overall boot? most don't even register as taking any time at all, only three (of 23) take more than a second
<ogra> Chipaca, they eat CPU .. all of them have pretty bold blue bars .... onn a multicore system that wont be significant, on single cores it will bite
<Chipaca> ogra: sure. So if we avoid them we save... .01% of the overall boot time? or how much?
<ogra> not on multicore where your IO is rather serialized
<ogra> err
<ogra> s/multi/single/
<Chipaca> that boot time is, still, over 5 minutes. The total sum of all time spent on unsquashfs is less than 10 seconds.
<ogra> point is it wastese ressources that we could avoid
<ogra> sure, there is something else going on with the system ondra took the bootchart
<ogra> i'm not saying this needs urgent fixing or anything but it is an obvious place for improvement
<ondra> Chipaca my main focus is what is happening between ~40 and ~140 seconds
<ogra> right, it *feels* like there is a Sleep(100) somewhere in snapd's code :D
<ondra> Chipaca it takes almost 100s to start snapd from snapd snap, and I don't seem to get timing for this anywhere, or logs
<Chipaca> ondra: have you enabled debug logs?
<ogra> but thats unrelated to the unsquashfs ... i'm just pointing out that unsquashfs is wasteful and it would be nic to improve it
<ogra> *nice
<ogra> i'm not asking for an urgent fix but for considering to improve it if there is time
<pedronis> ogra: please write something on the forum with data, these IRC discussions will go nowhere
<ogra> will do
<Chipaca> ogra: what pedronis said. Thanks!
<ondra> Chipaca I'd need to use custom snapd snap I guess
<ondra> Chipaca or how to do it at first boot
<Chipaca> ondra: no, you just need to drop a file in etc/systemd/system/snapd.service.d
<ondra> Chipaca also it seems like it's before we start snapd, so logs in snapd will not help
<Chipaca> ondra: you can do that if you pause the bootloader for ex
<ogra> it would be cool if we could enable debug options for snpd on the kernel cmdline BT
<ogra> W
<ondra> Chipaca can you give me example of that service, I will drop it to the image
<ogra> adjusting the cmdline on firstboot is very easy .. while injecting a file to the rootfs is hard
<Chipaca> ondra: $  cat /etc/systemd/system/snapd.service.d/debug.conf
<Chipaca> [Service]
<Chipaca> Environment=SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7
<Chipaca> ondra: ^ I also sent an email asking anybody developing things on snapd to have this, ages ago (and it's all over the forum)
<Chipaca> ondra: or, it might be easier, to just drop those two env vars in /etc/environment
 * pstolowski walk, bbiab
<Chipaca> ondra: in core18, given it's a funkier service, you might need to adjust the service name
<ondra> Chipaca Ok thanks, I will try that
<Chipaca> ondra: i.e. /etc/systemd/system/core18.start-snapd.service.d/debug.conf
<Chipaca> mvo: I notice this service doesn't source /etc/environment, that's probably not good
<Chipaca> ondra: or maybe it's snapd.seeding.service?
<Chipaca> ondra: at this point I don't know which service actually starts snapd :-|
<Chipaca> in core18
<mvo> Chipaca: oh, good point
<pedronis> Chipaca: different ones at different points
<Chipaca> mvo: do you know how that dance happens?
<Chipaca> i can't find a snapd.seeding.service but it's in the bootchart
<pedronis> there's a bootstrapping one then it does a bit of seeding then snapd restarts
<mvo> Chipaca: yes, snapd itself writes it
<pedronis> as the real service I think
<Chipaca> mvo: from where?
<pedronis> wrappers/core18.go
<mvo> Chipaca: i.e. when snapd starts and there is nothing on the system yet it calls wrappers/core18.go
<Chipaca> pedronis: but there isn't a seeding there either
<pedronis> are you sure it's seeding?
<pedronis> there is no such thing afaik
<pedronis> there's a seeded service
<pedronis> that one doesn't snapd
<Chipaca> pedronis: https://private-fileshare.canonical.com/~okubik/bootchart-20191008-1710.svg
<Chipaca> pedronis: there's a snapd-seeding.service
<ondra> Chipaca I think this one core18.start-snapd.service
<pedronis> Chipaca: it's not a service, it's an ephemeral unit
<pedronis> Chipaca: from here (as ogra said): https://github.com/snapcore/core18/blob/master/static/usr/lib/core18/run-snapd-from-snap
 * pedronis lunch
<Chipaca> ondra: wrt not sure if it's snapd or not, snapd is running from t=39s at least
<Chipaca> ondra: so debug logs should shed some light on what's going on there
<ogra> Chipaca, pedronis https://forum.snapcraft.io/t/unsquashfs-vs-mount-during-firstboot-seeding/13614/1 ... (really just a suggestion for times where you guys dont have other things to do :) )
<ondra> Chipaca https://private-fileshare.canonical.com/~okubik/boot-plot.svg
<ondra> Chipaca if you look here, we only mount snap-snapd-5038.mount  around 130 second
<ondra> Chipaca and snapd is started at 140 second
<Chipaca> yep
<ondra> Chipaca and my interest is before 140
<ondra> Chipaca also from boot-chart you can see that during that time system is relatively idle
<ondra> once it starts seeding, it pegs on core well, there we would need to consider parallel jobs to speed it up. but that first 100s seems to be as easier to address now
<Chipaca> ondra: what is it waiting for?
<ondra> Chipaca you tell me :)
<ondra> Chipaca why do you thing I'm digging into it, I want to know as well :)
<Chipaca> ondra: can you stop it inside the initramfs just before it pivots in?
<Chipaca> i.e. before systemd kicks in
<ogra> Chipaca, pedronis, ondra https://forum.snapcraft.io/t/allowing-snapd-debug-options-to-be-set-on-kernel-cmdline/13615
<Chipaca> but after everything is mounted
<ogra> :)
<Chipaca> ogra: tks
<ogra> we need whishlist tags in the forum :D
<ondra> Chipaca possibly, what do you want to do there?
<Chipaca> ondra: add 'set -x' to run-snapd-from-snap :-)
<ogra> ondra, break=bottom ... then you can modify /writable
<ogra> (indeed only stuff thats not inside snaps :P )
<ondra> Chipaca but that one is core18 snap
<Chipaca> ondra: copy it somewhere, edit it, bind mount it back
<ogra> heh
<ondra> Chipaca you are bringing big guns right away :)
<mup> PR snapd#7576 opened: spread.yaml,.gitignore: sync ignored files <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7576>
<ondra> Chipaca I guess I can also create own core18 snap can't I?
<Chipaca> ondra: probably, yes :)
<pedronis> pstolowski: btw, are you using core18 for your spike ?
<ondra> ogra is that right to have in core18 snap things like dev/null dev/random dev/urandom dev/zero ?
<ogra> it doesnt do harm
<ondra> ogra seems to me useless
<ogra> (but in general these things should be handled by devtmpfs which we mount already in the initrd)
<ogra> yeah, they likely are ... unless you have a kernel without devtmpfs
<ogra> (these are rare but i guess they still exist)
<ondra> Chipaca anything else you want me to modify in core18 snap? set -eux -> set -x?
<ondra> Chipaca I will sprinkle that file with few echos once on it
<ogra> set -x should be enough ... you dont need eu (said boris johnson ...)
<Chipaca> ondra: get some timestamps in there as well
<Chipaca> ondra: dunno where the log will end up :)
<Chipaca> hopefully the journal?
<Chipaca> if so no timestamps needed
<Chipaca> dunno
<ondra> Chipaca I will see
<ondra> Chipaca let me run test boot
<mborzecki> pstolowski: pedronis: pushed a fix to #7443, we had an actual bug on systems with systemd older than 233
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pedronis> mborzecki: thanks, I'm a bit confused about the places where the comments mention 28 and the ranges have 29
<mborzecki> pedronis: heh, right so the 28th day is part of the range genrated by actual calculation, while 29-31 is the bit that varies from month to month (or year), but technically a month can have anywhere from 28 to 31 days
<mborzecki> perhaps i should leave a note that 28th is included in the range added further down the code
 * Chipaca takes a break
<pstolowski> re
<pstolowski> pedronis: no, not yet, i'm using cloud image (core + lxd)
<pedronis> pstolowski: ok, that will have it's complications
<pedronis> maybe
 * zyga -> tea
<mup> PR snapd#7577 opened: overlord: set fake sertial in TestRemodelSwitchToDifferentKernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7577>
<mborzecki> pedronis: force pushed a comment about 29-31 day range
<ondra> Chipaca https://paste.ubuntu.com/p/fQQXtCBSnQ/
<ondra> Chipaca with different formatting https://paste.ubuntu.com/p/q5MFkKy5cw/
<ondra> Chipaca attempts to overlay that file failed though
<Chipaca> ondra: and is the time you need to know about the time between 11:36:25 (131.827907) and 11:38:20 (247.375225), there?
<Chipaca> ondra: because if so, that _is_ snapd running, and you should be able to set env vars to get it to print more debug info
<Chipaca> ondra: add --setenv="SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7" to the systemd-run call, there
<ondra> Chipaca but 'Started Start the snapd services from the snapd snap.' is only printed at the end
<ondra> Chipaca and don't you connect eligible plugs and slots before you start snapd?
<Chipaca> ondra: yes, but "started" does not mean "just did the exec"
<Chipaca> ondra: snapd is the thing doing the connecting
<ondra> Chipaca true
<Chipaca> those log lines about connecting come from snapd
<Chipaca> oooh! kernel parameter!
<Chipaca>  systemd.setenv=SNAPD_DEBUG=1
<Chipaca> ^ that should work!
<Chipaca> says the manpage
<ondra> Chipaca OK let me test
<Chipaca> ondra: you can pass it more than once (if you also need _HTTP) but just SNAPD_DEBUG=1 should be enough
<ondra> Chipaca OK
<ondra> Chipaca I might got bind mount working
<ondra> Chipaca so i will get logs from this boot first
<ondra> Chipaca do you want logs from snapd.service then?
<Chipaca> ondra: just the ones from that first run
<ondra> Chipaca but from which service?
<Chipaca> ondra: snapd-seeding.service
<ondra> Chipaca do you mean snapd.seeded.service ?
<Chipaca> ondra: no, I mean snapd-seeding.service
<Chipaca> ondra: as in what systemd-run starts in that script
<Chipaca> that's the mystery snapd
<Chipaca> that's the one you want to look at
<ondra> Chipaca I cannot see such a service
<Chipaca> ondra: where are you looking?
<ondra> systemctl status snapd-seeding.service
<ondra> Unit snapd-seeding.service could not be found.
<Chipaca> ondra: it doesn't have a unit file
<Chipaca> ondra: journalctl will know of it though
<Chipaca> ondra: journalctl -u snapd-seeding.service should have it
<ondra> Chipaca OK I need to re-run boot as logs rotated now
<Chipaca> ondra: wait a mo'
<ondra> Chipaca how can I increase journal buffer?
<Chipaca> ondra: there was a way to make it non-ephemeral, maybe ogra knows offhand
<Chipaca> ondra: systemd.journald.forward_to_syslo
<Chipaca> syslog*
<Chipaca> ondra: in the commandline
<ondra> Chipaca but on core18 we have no syslog
<ogra> i didnt know there is a cmdline option ... i only know you can create a dir (was it /var/log/journal ???) that will then automagically be used for journald logs
<Chipaca> ondra: I didn't know that :)
<ogra> yeah, no more syslog
<ondra> Chipaca will it create it?
<Chipaca> no
<ondra> Chipaca then no syslog
<Chipaca> bah, i dunno
<ogra> i guess it will just try to write to logger
<Chipaca> but
<Chipaca> ondra: but
<ogra> (and not find it ...)
<ondra> Chipaca so I do actually have a log from seeding service
<Chipaca> ondra: edit that script, and redirect the output from systemd-run to somewhere
<Chipaca> that should work
<ogra> well, creating that dir should also work for persistent logs
<Chipaca> ondra: actually it might _not_ be in the journal, it might all be spewed out from the script
<ondra> Chipaca but it's useless https://paste.ubuntu.com/p/sw5sNBp6WK/
<ogra> they are binary files though
<Chipaca> I could check but I'm not sure it's the same in 16 and 18
<Chipaca> ondra: that's not debug output :-|
<ondra> Chipaca booting now with debug env from cmd line
<Chipaca> and I can confirm the output from the systemd-run does reach the journal (but I think your recent pastebin does, too)
<ondra> Chipaca actually reading logs over ssh seems to messed it up, check this https://paste.ubuntu.com/p/ZFB78ycbMz/
<Chipaca> ondra: if the rotation is still getting in the way, we can either tweak journald.conf, or have it forward to kmsg and bump the kmsg buffer (but that might be expensive on a low lowmem board)
<ondra> Chipaca it's fine if I know what logs to get there is time to do it once I can access seeded device
<Chipaca> ondra: is that with -u snapd-seeding.service ?
<Chipaca> ondra: it looks like the logs of the start-snapd-wotsit script
<Chipaca> which would not be in snapd-seeding.service log
<Chipaca> (and yes there is noise in that that could be avoided... :-| )
<ondra> Chipaca sudo journalctl --all -u snapd-seeding.service is always empty
<Chipaca> ondra: what was https://paste.ubuntu.com/p/sw5sNBp6WK/ ?
<ondra> Chipaca core18.start-snapd.service
<Chipaca> gr
<ogra> welcome to our world :P
<Chipaca> ondra: and if you foraward_to_kmsg ?
<ogra> (debugging the indebuggable)
<Chipaca> ondra: I've got another option
<ondra> Chipaca OK now with extra verbosity I do not get start of the log :(
<Chipaca> ondra: forwarding to kmsg?
<Chipaca> ondra: or without?
<Chipaca> I don't know which of all the options you've gone for :)
<ondra> Chipaca without
<ondra> Chipaca BTW it's clear from journalcrl of whole system, there is only kernel chatty from 40 to 140 second
<ondra> Chipaca no changes to where journal goes for now
<Chipaca> ondra: ok, I'm downloading a core18 for amd64, and will play around with it until I can get logs for that first boot snapd
<Chipaca> ondra: I'll let you know
<ondra> Chipaca looks like we have no journald.conf at all, so it should be easy to add one to etc
<Chipaca> ondra: feel free to do so :)
<Chipaca> seems silly that it doesn't have a kernel option for setting storage as it has for everything else
<Chipaca> hmm
<Chipaca> ondra: so, on amd64, all I need to do is set systemd.setenv=SNAPD_DEBUG=1 in the kernel commandline, and when I log in after creating my account and etc I have logs for snapd-seeding.service
<Chipaca> ondra: https://paste.ubuntu.com/p/kSmxKc6zKw/
<ogra> ogra@pi4:~$ ls /etc/systemd/journald.conf
<ogra> /etc/systemd/journald.conf
<ogra> my core18 image has journald.conf here
<ondra> ogra not mine
<ogra> weird
<ondra> ogra I can add it, but how do I increase max size
<ogra> given we are most likely using the exact same core18 snap
<ondra> it's set to 10M
<Chipaca> ondra, ogra: where did you get yours from?
<ondra> ogra also it is not in core snap
<ogra> mine is my pi4 custom image ... but that uses core18 from stable
<ogra> ogra@pi4:~$ snap info core18|grep refresh
<ogra> refresh-date: 6 days ago, at 22:09 UTC
<Chipaca> journald.conf is there, and writable, in the amd64 core
<Chipaca> core18*
<ogra> same here
<ogra> ogra@pi4:~$ sudo touch /etc/systemd/journald.conf
<ogra> ogra@pi4:~$
<ondra> ogra ah RuntimeMaxUse=
<Chipaca> ondra: what core18 are you running, that it doesn't have this file?
<ondra> Chipaca edge
<ondra> Chipaca rev 1202
<Chipaca> ondra: what arch?
<ondra> armhf
<ogra> same here ... but stable
<Chipaca> ondra: core18 1202 has etc/systemd/journald.conf
<ondra> Chipaca armhs?
<Chipaca> 1202 is armhf
<ogra> 1202
<ogra> :)
<ogra> would be surprising if it vamished all of a sudden
<Chipaca> ondra: UBUNTU_STORE_ARCH=armhf snap download core18 --edge
<Chipaca> ondra: unsquashfs core18_1202.snap etc/systemd/journald.conf
<Chipaca> ondra: less squashfs-root/etc/systemd/journald.conf
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> ogra: yeah it'd be a bug
<ondra> Chipaca OK my bad, I must have had type when searching
<ondra> sorry I have it too :)
<ackk> sergiusens, hi, any chance you could take a look at https://github.com/sergiusens/snapcraft-preload/pull/34 and https://github.com/sergiusens/snapcraft-preload/pull/36 ?
<mup> PR sergiusens/snapcraft-preload#34: preserve LD_PRELOAD from the calling environment (fixes #33) <Created by albertodonato> <https://github.com/sergiusens/snapcraft-preload/pull/34>
<mup> PR sergiusens/snapcraft-preload#36: use SNAP_INSTANCE_NAME instead of SNAP_NAME for prefixing /dev/shm fiâ¦ <Created by albertodonato> <https://github.com/sergiusens/snapcraft-preload/pull/36>
<Chipaca> ondra: so now I'm suspicious of your "it's empty" :-|
<Chipaca> anyway, i've got an up to stand
<ondra> Chipaca non it is not :)
<ondra> Chipaca ogra anyway it only exists in core snap, and not in overlay /etc
<ondra> which is probably good, as I can add mine
<zyga> sorry auth
<ondra> I'm increasing buffer 4times so I should have now more time
<Chipaca> core18 has an overlay /etc ??
<ondra> Chipaca overlay of /etc/systemd/
<ondra> Chipaca how would we add new units :)
<ogra> ogra@pi4:~$ grep etc/systemd /etc/system-image/writable-paths
<ogra> /etc/systemd                            auto                    persistent  transition  none
<ogra> ogra@pi4:~$ cat /etc/issue
<ogra> Ubuntu Core 18 on \4 (\l)
<ogra> if you dont have the journald.conf file then something with your initrd is broken
<ogra> (transition means it copies the content from core to /writale on first mount)
<Chipaca> ondra: sorry, overlay is a bad word (overlayfs ...)
<ogra> well, the point is that it *should* be in the overlay /etc
<ogra> if it isnt, there is a bigger prob
<ogra> ogra@pi4:~$ ls /writable/system-data/etc/systemd/journald.conf
<ogra> /writable/system-data/etc/systemd/journald.conf
<ondra> ogra did we find more bugs ? :)
<ogra> smells like ... if you are sure the file inst there at least
<ogra> *isn't
<ondra> ogra if I have file there, will ill override it?
<ogra> if you have the file there it is fully writable
<ogra> so you ccan just edit
<ondra> ogra no if I have already file there, it will not nuke it, right?
<ondra> ogra ignore me it should not
<ogra> yeah, it wont
<ogra> transition only copies once on first mount ... in subsequent mounts it just uses whats there
<ogra> (so you could even create a new file there)
<ondra> Chipaca https://paste.ubuntu.com/p/bq6b39PBJ4/
<Chipaca> ondra: so there you go
<Chipaca> ondra: and, snap debug timings 1, for more info
<ondra> Chipaca ?
<ondra> Chipaca how to get more logs?
<ogra> "error trying to compare the snap system key: system-key missing on disk"
<ogra> is that relevant ?
<Chipaca> ogra: nah, that's expected on first boot
<ogra> or does the system-key only come in with initialize-device ?
<ogra> right
<ogra> so the gap is before "Load: validated crc32" ... i guess the checksumming is slow then ?
<ogra> (once again)
<roadmr> crc32 wow what a throwback
<ondra> ogra no that is check of lk boot env
<ondra> ogra that takes 1ms
<ogra> hmm, well, there is a long gap before it runs
<Chipaca> ondra: did you run 'snap debug timings 1'?
<ondra> ogra exactly, and I want to know why
<Chipaca> ondra: or even just 'snap changes'
<ogra> ch-ch-ch-changesss
 * ogra humms david bowie
<ondra> Chipaca https://paste.ubuntu.com/p/FsdG3V4Fjg/
<mup> PR snapd#7578 opened: sandbox/cgroup, overlord/snapstate: move helper for listing pids in group to the cgroup package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7578>
<mborzecki> zyga: ^^
<zyga> thanks
<ogra> ondra, that doesnt seem to list the bootloader stuff ... perhaps check change 2 instead ?
<Chipaca> ondra: also, --verbose
<ondra> ogra that only shows last 2 changes :)
<ondra> Chipaca no it always start at number 3
<Chipaca> those are task numbers, not change numbers
<Chipaca> but
<Chipaca> ondra: snap debug timings --verbose 1
<Chipaca> ondra: and, as ogra said, also look at change 2
<Chipaca> change 2 will have the keys generation
<zyga> mborzecki: look again
<ondra> Chipaca it does not give me change 1 or 2 https://paste.ubuntu.com/p/Yj5Q2HYpp9/
<Chipaca> ondra: the "1" in "snap debug timings --verbose 1" is \change 1
<Chipaca> ondra: please also run the same command but for change 2, i.e. "snap debug timings --verbose 2"
<ondra> Chipaca and 'snap debug timings --verbose 2' will only print timing around change 206
<Chipaca> ondra: the numbers under the ID column in that output are about tasks
<ondra> Chipaca ah sorry
<ogra> soooo complicated !
<Chipaca> ondra: what else do you have in "snap changes"?
<ondra> Chipaca so change 2 is two tasks, and both take 1 combined
<ondra> Chipaca just starting services and initialize device
<Chipaca> ondra: can I see the output of 'snap changes' please
<ogra> what do you pay ?
<ondra> Chipaca https://pastebin.canonical.com/p/pzJTRfPtdq/
<ogra> :P
<Chipaca> ondra: ok, the changes you want to look at are 1 and 6
<ogra> yeah, 6
<ondra> Chipaca https://paste.ubuntu.com/p/dtgwn5C9SK/
<ondra> is that waiting 56s on key generation?
<Chipaca> ondra: yes
<Chipaca> ondra: so
<Chipaca> ondra: your random is probably empty
<mborzecki> zyga: replied, i had a really trivial check in mind there
<ogra> two times actually, no ?
<ondra> but is that blocking boot?
<Chipaca> ondra: get more randomses
<Chipaca> ogra: no, one is the sub of the other
<ogra> ah, k
<Chipaca> ondra: yes, you can't boot with an empty random pool
<ogra> right, i see the indendation in the summary when looking closer :)
<ogra> ondra, did you already add the cmdline changes for rng_core ?
<Chipaca> ondra: your device probably has a hardware rng you can plug in â¦ somehow?
<ondra> Chipaca still even if blocking, and that's a bit odd to block at that stage, it only explain 56s there
<ondra> ogra yep rng_core is there
<ondra> ogra rng_core.default_quality=700
<ogra> yeah, that should have improved a little bit ... (i'd expect a few seconds less ... so 80-90 vs the 100 before)
<ondra> ogra  I do not think it improved
<ogra> well, perhaps a missing kernel config ? rng_core is tied to the kernel SW rng
<ogra> (and will bee quietly ignored if the kernel doesnt have it)
<ondra> ogra what config would be that?
<ondra> Chipaca when do we need that random number first time?
<ondra> ogra CONFIG_HW_RANDOM ?
<ondra> ogra as that is enabled
<ogra> CONFIG_HW_RANDOM and sub-options of that (see menuconfig)
<ondra> ogra is there actually device node which I should see?
<ogra> ondra, tyhicks was the one that went over the whole rng stuff back then ... he might know what other options are needed (he also suggested the cmdline option ... which back then helped a lot on a beaglebone where we saw the slowness first9
<ogra> not with in-kernel rng
<ogra> if you want to use a device node there is likely some other kernel config option thats specific to that HW
<ogra> and gives you HW rng ... (if the SoC actually has it at all)
<ogra> you probably want to take a look at the original android config
<ondra> ogra like CONFIG_HW_RANDOM_MTK :)
<ondra> ogra and enabled
<ogra> fooor example :)
<ogra> tat might need userspace bits ... not sure
<Chipaca> ondra: you probably have things in dmesg about not having enough entropy?
<Chipaca> when we need it â to generate keys
<roadmr> ð
<ogra> we should just generate them at build time ... makes everything easier ... and everyone has the same key ... :)
<ogra> ondra, btw, do you also see the slowness on second boot ?
<ogra> (i assume not)
<ondra> ogra nope, sub 30 seconds
<ogra> perhaps we should simply tell the customer to boot the device once in-factory
<ondra> ogra from kernel code, there is driver using TZ to generate rn, so this should be fast
<ogra> make it part of the flashing procedure
<ogra> "power on ... leave it sit for 5min"
<ogra> (unconnected)
<ogra> timer wont be enough to get entropy
<ogra> you need interrupts
<ogra> attach a mouse and wiggle it :)
<ondra> Chipaca stupid question but task ID is assigned when task is started, is that correct?
<ondra> Chipaca and tasks from change id 1 will run before tasks from change 2
<ondra> Chipaca because random number generation is run as task 200+
<ondra> Chipaca this is way after snaps were seeded
<ondra> wow lot's of dead ppl here
 * Chipaca got better
<ondra> Chipaca did you see my question about task IDs?
<ondra> Chipaca is that ID assigned when task was started?
<ondra> Chipaca so I can assume they go in sequence?
<Chipaca> ondra: I did not see your question
<ondra> Chipaca OK last two question I did ask now
<Chipaca> ondra: they go in sequence at the time of task creation, which might not line up exactly with task execution
<ondra> Chipaca OK, so then this random key generation might take some time, but it's run way way later
<ondra> Chipaca so it's not that 100s we are looking into
<ondra> Chipaca it's task id 200+ and change 6
<ondra> Chipaca we are looking into 100s before or at the beginning of change 1
<ondra> Chipaca like task id 1 and 2
<Chipaca> ondra: I â¦ what? why?
<Chipaca> ondra: if it's before snapd starts, then it's somebody else you should be talking to
<ondra> Chipaca that 100 is before we start seeding, rsa key is generated after seeding
<ondra> Chipaca nope, it's this log https://paste.ubuntu.com/p/5jx9kcfZXV/
<ondra> Chipaca or in that seeding log, there is that pause
<ondra> Chipaca rsa-key comes after seeding
<Chipaca> ondra: ok
<ondra> Chipaca so can I get more logs there?
<Chipaca> ondra: did you ever get me a 'snap debug timings --verbose 1'? i might have closed it already
<ondra> Chipaca yes I did, https://paste.ubuntu.com/p/Yj5Q2HYpp9/
<ondra> Chipaca task 4 there is too late, this is after that quiet period
<Chipaca> ondra: 101ms is too late?
<Chipaca> ondra: can you actual timestamps on the journal output, or is it too late for that?
<Chipaca> ondra: the way I read the one you pasted is probably wrong
<ondra> Chipaca probably too late now
<ondra> Chipaca I have timing from start of the boot
<Chipaca> ondra: ok, maybe you can help me then
<Chipaca> ondra: https://paste.ubuntu.com/p/bq6b39PBJ4/
<ondra> Chipaca which is then 0
<Chipaca> in that one
<Chipaca> ondra: the numbers in the left column are seconds in offset since the 'logs start', yes?
<ondra> Chipaca time in that log is relative from 0 which is device power on
<Chipaca> ondra: ah
<ondra> Chipaca since device power on
<Chipaca> ondra: and how do I compare with other things?
<ondra> Chipaca and yes, seconds from device power on
<ondra> Chipaca all the logs and boot chart is in seconds from device power on
<ondra> Chipaca snap changes are not though
<Chipaca> nor is '-- Logs begin at Wed 2019-10-09 13:00:46 UTC, end at Wed 2019-10-09 13:10:02 UTC. --'
<ondra> Chipaca so depends what do you want to compare it to?
<ondra> Chipaca OK there you go, you have also log start
<Chipaca> ondra: that doesn't help, does it?
<Chipaca> ondra: what wall clock time does the gap happen at?
<ogra> bootchart looks at the kernel counter
<ogra> which starts at 0 when the kernel fires up
<ondra> Chipaca but what are you interested in? Absolute time when service started, or actual time processing
<ondra> ogra and I did same for journal logs
<ogra> (same thing you get with dmesg if you dont use -T )
<ondra> ogra so you can link them to bootchart
<ondra> ogra and same you get with journalctl -o short-monotonic
<ogra> ah, i didnt knwo that one (i rarely want the kernel timer anyway)
<ondra> Chipaca but if I tell you wall clock time wha will you compare it to?
<Chipaca> ondra: what's the output of 'snap debug timings --verbose --ensure=seed' ?
<ondra> Chipaca https://pastebin.canonical.com/p/3NRRGZYJ9S/
<ondra> Chipaca '75739ms            -  state-from-seed             populate state from seed'?
<Chipaca> ondra: how many more seconds do you need to find?
<ondra> Chipaca what is that?
<ondra> Chipaca what do you mean 'how many more seconds'?
<Chipaca> ondra: last time I found you 50s and your first reaction was "i need more"
<Chipaca> so here i am finding you more
<Chipaca> that's a chunk of time
<ondra> Chipaca no, that 50 seconds you found is when services run
<ondra> Chipaca device communicated
<ondra> Chipaca so they are not helping me at all
<Chipaca> yes, that was your second reaction
<ondra> Chipaca that's 50 seconds to connect to the store to check for update, but at that point device will be already communicating with user, so that 50s is for me irrelevant
<Chipaca> ondra: I regret trying to help you, now
<ondra> Chipaca well then just tell me "yep, during first boot we stop for 100s before we start seeding, this is feature"
<Chipaca> the first thing I told you before trying to help you was that years ago I pointed out that first boot on armhf takes 5+ minutes because of things
<Chipaca> and now, several hours of trying to walk you through it all I point you at the logs that show you that same bit of information
<Chipaca> I have no idea what you're so upset about at this point
<ondra> Chipaca this is smart speaker, it takes 5 minutes to boot, before it can connect to the phone. that 5 minutes does not include or is affected by that 50 seconds key generation, as you do not have internet anyway.
<Chipaca> but you have the data, right there
<ondra> Chipaca but you can connect over the BT to provision WiFi, while device is generating rsa-key
<Chipaca> I am not talking about those 50 seconds for key generation, I am talking about _these_ 300 seconds of seeding
<ondra> Chipaca so it's not having any effect on user experience
<ondra> Chipaca I accept seeding takes time, related to number of snaps
<ondra> Chipaca but snapd snap seeds for 150 seconds, that seems odd
<ondra> Chipaca and nobody complains about that, I'm just wondering why we have 100s of nothing, Now you explain me this is feature. And you should just take it
<ondra> Chipaca thanks for help
<Chipaca> ondra: at what point did I say this was a feature and you should just take it
<ondra> Chipaca at point that you said I was not happy with 50s discovery, which are post seeding
<Chipaca> ...?
<ondra> Chipaca I told you those make no difference
<Chipaca> ondra: I still don't see how I told you that. I see you saying I did, though.
<Chipaca> or maybe saying I _should_
<Chipaca> but I won't, because it isn't
<Chipaca> ondra: could you please snap install http, and pastebin 'http snapd:///v2/changes select==all'
<ondra> Chipaca https://pastebin.canonical.com/p/k8Q6ryzwhn/
<Chipaca> ondra: where does 2019-10-09T13:06:29.005541125Z fall WRT the missing time?
<Chipaca> is that before or after the time we're looking for?
<ondra> Chipaca that's after
<ondra> Chipaca I think we are looking for things before 2019-10-09 13:03:00
<ondra> Chipaca more precise between 2019-10-09 13:01:26 and 2019-10-09 13:03:00
<Chipaca> ondra: where do those timestamps fall in https://paste.ubuntu.com/p/bq6b39PBJ4/ ?
<ondra> Chipaca between 40 and 140
<ondra> Chipaca from what I understand, logs star is when kernel started
 * zyga calls it a day
<Chipaca> ondra: just in case, is there anything in any of the other --ensure= options?
<Chipaca> anything in the times we're looking at
<ondra> Chipaca I did get whole journal if you want
<ondra> Chipaca I could not see anything there though
<ondra> Chipaca let me paste it for you
<Chipaca> ondra: there's a little more detail in the timings output
<Chipaca> ondra: can you patch the snapd for first boot, or is that too much?
<ondra> Chipaca not that is actually fairly easy
<ondra> Chipaca unlike core as I learnt
<ondra> Chipaca https://pastebin.canonical.com/p/Bzv44GKwmD/
<Chipaca> ondra: out of curiosity, what are these about?
<Chipaca> [   42.310781] localhost kernel: CPU3 killed.
<ondra> Chipaca just some MTK kernel verbosity :)
<Chipaca> hmm
<ogra> Chipaca, at least it is a friendly killer ... i have seen other boards where daemons kill their children and such ... way more blood there
<Chipaca> ondra: so if I give you a patch for snapd you can apply it to your snapd?
<ondra> Chipaca yep
<ondra> Chipaca that wont' be problem
<Chipaca> ondra: http://paste.ubuntu.com/p/DWYXndYs5C/
<Chipaca> ondra: won't be too informative but hopefully it'll give us somewhere to start looking
<Chipaca> hmm
<Chipaca> ondra: it'll need the debug trick still
<ondra> Chipaca sure I will let you know once I have it
 * cachio lunch
<ondra> Chipaca it will take some time, as my LP git sync is now hanging to run sync 'as soon as possible' for past 15 minutes
<ondra> Chipaca time is relative thing
<ogra> blame einstein
<Chipaca> only important if you're going fast, so it doesn't apply to this board
 * Chipaca hides
<cjwatson> If you're routinely waiting for an LP git import, it's probably a sign that you should be hosting the repository directly on LP instead.  Imports are best-effort
<ogra> but thats less funny because you cant complain then ...
<ondra> cjwatson it's a bit pain to push to two locations as snapd is in github, but I guess best option
<ondra> cjwatson as now I'm waiting over half an hour and still nada
<roadmr> folks, so: mir-kiosk has a plugs: - x11, so it offers x11 for other snaps to connect to it, right?
<cjwatson> ondra: Hm, one of our importds doesn't seem to be doing much though, let me see
<ondra> cjwatson thanks
<ondra> cjwatson I did create copy git repo to kick build now, so it should be OK
<Chipaca> ondra: I'm off but I'll check back later tonight
<ondra> Chipaca no worries I have some other tasks anyway, let's check tomorrow
<cjwatson> ondra: Repaired the stuck worker, so it should be doing a better job of keeping up with imports now anyway
<ondra> cjwatson thank you :)
<ondra> Chipaca https://paste.ubuntu.com/p/WMKkCPSBjg/
 * cachio afk
<ogra> roadmr, i think that plug is only for running mir-kiosk on desktop systems .... to actually run an x11 app on top of mir-kiosk (which only offers wayland to apps) your app needs to ship Xwayland and set that up through a wrapper .... the app also needs a loopback slot/plug x11 setup
<ogra> roadmr, i.e. line 50,56 and 81 in https://github.com/ogra1/opencv-demo-snap/blob/master/snap/snapcraft.yaml
<roadmr> thanks ogra, that'll be useful as a reference
<mup> PR snapd#7579 opened: interfaces/network-setup-observe: add Info D-Bus method accesses <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7579>
#snappy 2019-10-10
<mup> PR snapd#7580 opened: spread.yaml: exclude vendor dir <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7580>
<mup> PR snapd#7581 opened: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>
<mup> PR snapcraft#2748 opened: meta: warn about command mangling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2748>
<mborzecki> morning
<mup> PR snapd#7564 closed: interfaces: add cgroup-version to system-key <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7564>
<mborzecki> school run, back in 30 or so
<mborzecki> re
<mborzecki> mvo: morning
<mup> PR snapd#7568 closed: snap: when running `snap repair` without arguments, show hint <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7568>
<mup> PR snapd#7567 closed: snap-repair: error if run as non-root <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7567>
<mvo> hey mborzecki
<mvo> mborzecki: good morning
<mborzecki> mvo:  can you take a look at https://github.com/snapcore/snapd/pull/7571 ?
<mup> PR #7571: sandbox/cgroup: refactor process cgroup helper to support v2 and named hierarchies <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7571>
<mvo> mborzecki: uh, I think I wanted to do this yesterday already :/
<mvo> mborzecki: let me do this *now*
<zyga> sorry, had super stubborn kids
<zyga> one is still at home
<zyga> ugh :|
<zyga> ok, let's try to focus...
<mborzecki> mvo: thanks!
<zyga> mvo: https://twitter.com/samerhaj/status/1182121464813756419
<zyga> and check out the next tweet there, vmware working on this?
<zyga> esxi for raspi anyone?
<mborzecki> zyga: wow, nice
<zyga> I, for one, would not mind a raspberry pi with a proper boot stack
<mborzecki> zyga:  any clue how does uefi/acpi combo could handle hats?
<zyga> no idea
<mvo> mborzecki: added a comment, please let me know if it makes sense or if its too terse. happy to talk here as well if you want :)
<mborzecki> mvo: looking
<mborzecki> mvo: i see, it's a bit yagni right now, once we land the named hierarchy, the string will no longer the be controller name, but insteadf a named hierarchy name ('snapd' in this case)
<mvo> mborzecki: right, landing it is fine
<mvo> mborzecki: I was mostly wondering if consumers of the ProcGroup() need to know what matcher to create
<mvo> mborzecki: or if we could simply keep using a string here
<mvo> mborzecki: and the string in the future might be "snapd"
<mvo> mborzecki: or is this not how it will work :) ?
 * mvo obviously has less context
<mborzecki> mvo: hm you'd have to pass name=snapd to be explicit, or "" when you mean a unified hierarchy, feels a bit too magical
<mvo> mborzecki: hm, but we know internally in the cgroup module if we are unified or mixed so could we leverage this knowledge?
<zyga> mvo: we use cgroup v1 even in unified mode
<zyga> so perhaps it's all going to be simplified eventually
<zyga> s/use/going to use/
<mvo> ok, I don't want to rathole this too much, sry! it just seems to me right now right now we only have one user of "cgroup.ProcGroup" and we always use freezer here so I wonder if we could encapsulate the knowledge that its freezer/something-else inside the cgroup package itself maybe?
<zyga> we could but the cgroup package doesn't know that, it's the overlord that knows this; I think it's fine as is, it will change shortly, perhaps before the next release
<mborzecki> mvo: zyga: hm so perhaps we could have a separate call cgroup.SnapProcGroup which internally knows whether to ask for freezer or a named group?
<zyga> it is my understanding that by the time we are done it will use a different selector or a hard-coded string for the new location
<zyga> I really don't think we need to do more now
<zyga> just land and iterate
<zyga> meanwhile, I'm back to https://github.com/snapcore/snapd/pull/7576
<mup> PR #7576: spread.yaml,.gitignore: sync ignored files <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7576>
<zyga> why does something so simple have to be so hard :D
<mvo> zyga: userd is currently using it and it does not know about freezer either, does it? its just snap-confine that knows about freezer (or am I missing something?)
<zyga> userd is using cgroups?
<mvo> zyga: I did a "git grep ProcGroup" and a match there
<mborzecki> zyga: yeah, it is, that's the next thing, we'll probably need some api that encodes information about how snap cgrups are made
<mvo> zyga: fwiw, I disagree with "why does something so simple have to be so hard"
<mborzecki> zyga: it's for checking whcih snap the talking to userd over dbus comes from
<zyga> oh, I didn't notice that
<zyga> I just read that code
<mvo> mborzecki: sry again for lack of context - but do we need (external) api for how cgroups are made? mostly wondering if we can keep most of this knowledge internal to the cgroup package
<zyga> mvo: (I was referring to the gitignore PR)
<mvo> zyga: oh, sorry
<mvo> zyga: then I misunderstood :)
<zyga> mvo: ignoring in spread and git consistently is haaard :)
<mvo> zyga: I thought it was about my bikesheding api here :)
<zyga> and it should not
<zyga> no no, sorry
<mvo> zyga: git hard> makes sense ;)
<zyga> mborzecki: I wonder if the pid usage in userd could go away
<zyga> and use /proc/pid/root instead
<zyga> but that's a separate conversation
<zyga> we discussed this with james, as long term API for discovering snap processes
<zyga> brb, need tea, coffee
<zyga> I'll catch up on the thread here
<mborzecki> mvo: we don't, that's why the cleanups are being done, afaik we have 3 places rightr now that made up the grup names themseleves, userd, snapstate/refresh and s-u-n
<zyga> but mostly want to unbreak that gitignore branch
 * zyga loves the acronym s-u-n
<mborzecki> mvo: 'groups are made' as in how the path under the relevant group mount point is constructured for a snap :)
<mvo> mborzecki: oh, this is spread out right now? yeah, a good reason to consolidate it :)
<mvo> mborzecki: anyway, my concern with the PR as it is is just that the current code in userd has cgroup.ProcGroup(pid, "freezer"). that seems to require knowledge in userd about freezer that should probably not be needed there. the new code now also adds the fact that its a v1controller there. so it seems like it makes this slightly worse. I think we can land but we should reverse the direction in the next prs to require less knowledge about how exa
<mvo> ctly we do cgroups outside of the cgroup package. does that make sense?
<zyga> back with coffee
<zyga> mvo: I agree that eventually we should instead have an API that refers to app / hook tracking
<zyga> and similar pid discovery
<zyga> and encapsulate the cgroup logic there
<zyga> I still would merge this as-is and iterate because velocity and not-worse-than-before
<zyga> mborzecki: last night I needed to sober up after looking at 22MB binaries
<zyga> so I started making those few-kb, built-with-C, hello-world programs that don't need libc
<zyga> that was refreshing
<zyga> offtopic: I found a great use for raspi zero -- it's the cheapest reliable serial logging device I've had
<zyga> just plug a wire and log away
<mborzecki> mvo: right, i mean it makes sense, we should be able to figure everything out in cgrup package given the security tag
<mborzecki> (hopefully)
<zyga> mborzecki: I would not even use cgroup as the wrapper
<zyga> we may end up not using cgroups eventually
<zyga> the package should be conceptual - pid tracking and discovery, it may use cgroups internally
<mborzecki> zyga: snaptrack? :P
<zyga> but what it should really have is functions like PidsOfSnap and SnapOfPid or similar
<zyga> pidof ;-)
<mborzecki> mvo: since you're doing reviews already, can you take a look at this one too? https://github.com/snapcore/snapd/pull/7578 again it's moving some pieces scattered around into the cgroup pacakge
<mup> PR #7578: sandbox/cgroup, overlord/snapstate: move helper for listing pids in group to the cgroup package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7578>
<zyga> ok
<zyga> back to gitignore
<mvo> mborzecki: 7578> sure - the title is promising for sure!
<mborzecki> mvo: hope the content doesn't disappoint :P
<pstolowski> morning
<mborzecki> pstolowski:  hey
<zyga> hey pawel :)
 * zyga reads how git does .gitignore
<zyga>  /o\
<zyga> git has a screen full of global variables
<mvo> mborzecki: love it
<mvo> mborzecki: I would even go a bit further and hide pidsCgroupDir from the outside
<mvo> mborzecki: but fine as is
<mup> PR snapd#7571 closed: sandbox/cgroup: refactor process cgroup helper to support v2 and named hierarchies <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7571>
<zyga> mborzecki: so I had a look at those exclude patterns
<zyga> and I have the following compromise
<zyga> mborzecki: git needs /foo to exclude a file ./foo won't cut it
<zyga> mborzecki: spread's use of tar is exactly the opposite
<mborzecki> hahah
<zyga> mborzecki: it requires ./foo and /foo won't cut it
<zyga> I think it's fine if I document it
<zyga> it's better then sending garbage
<zyga> and better than not working
<zyga> I don't see any way out of this for now
 * mvo has some eoan problems today and regrets upgrading to it
<zyga> mvo: what happens?
<zyga> mvo: I'm running on a similar-ish thinkpad and apart from suspend resume killing input (ha ha) it works okay (sob)
<Chipaca> fitting that you regret upgrading to eoan in the morning
<mvo> zyga: its on my desktop, sound issues, stuttering and it always select the wrong output on login so I need to go to gnome-settings etc
<zyga> mborzecki: oh god
<zyga> mborzecki: tar has --exclude-vcs-ignores
<zyga> mborzecki: it reads .gitignore directly
<zyga> can I just path spread instead?
<zyga> mvo: man, that sucks :/
<zyga> mvo: it's the future though, better bite the bullet and report them
<mvo> zyga: doing that but its a bit of a time sink this is why I regret it
<zyga> indeed
<mvo> Chipaca: hahaha
<mvo> Chipaca: took a while until the penny dropped
<Chipaca> mvo: no regrets
<mborzecki> zyga: hm can we teach spread about --exclude-vcs-ignores then?
<zyga> I just did locally
<mborzecki> it'll take a while to land it though
<zyga> it doesn't seem to work
<mborzecki> hahahah
<zyga> running a debug session to see if the files really got copied
<zyga> it's driving me insane
<zyga> I hate doing this, it breaks all C testing I work on
<mborzecki> well, i'm trying to teach postrm and snap-mgmt about the snap.mount unit :/ so i feel you
 * zyga hugs mborzecki :)
<mborzecki> btw. noticed something intersting in the tests, we've supposedly stopped lxd service (and i guess any containers it ran), but then removing /var/snap/lxd/comon/ns/mntns fails with EBUSY
<zyga> are you sure it stopped containers?
<mborzecki> well, i guess i hope it did
<zyga> --debug doesn't work if project prepare fails
<zyga> WAAAAAAAAAAT
<zyga> ah, no, spread is picky where --debug is
<zyga> man
<zyga> mborzecki: the plot thickens, the ignore patterns work
<zyga> but it's removal that matters now :D
<zyga> man, dpkg, you sure are picky
<Chipaca> zyga: what're you fighting against? I think I missed that bit
<zyga> Chipaca: being able to spread a tree with built files while also passing debian build package thing that hates them
<zyga> Chipaca: almost there though
<zyga> now that I see what the error message is
<Chipaca> zyga: ah
<Chipaca> ondra: if/when you have more time to poke at that slow boot, given your last pastebin, the next step would be to do a profiling of the slow step
<ondra> Chipaca I did some progress with more logs
<ondra> Chipaca in the meeting now, but will report back
<Chipaca> k
<mborzecki> zyga:  there was a snap.mount unit before?
<zyga> mborzecki: I got it :)
<zyga> mborzecki: so... back to your question
<zyga> there used to be but we nuked it and got the snap.mount.service
<zyga> AFAIR
<zyga> mborzecki: why?
<zyga> mborzecki: but I don't recall exactly why
<zyga> mborzecki: gobs of complexity
<zyga> mborzecki: note there's also a snapd-generator
<zyga> mborzecki: look at cmd/snapd-generator/
<zyga> it creates a mount unit AFAIR
<mborzecki> looking at some postinst helpers, and there's a comment about snap.mount in 2.31
<zyga> I think we used to have snap.mount
<mborzecki> deb postinst
<zyga> but it was too "strong"
<zyga> so we moved it to the generator conditionally
<zyga> or something like that
<zyga> and the snap.mount.service is a separate beast for $REASONS
<zyga> I honestly don't recall, I'd have to dig
 * Chipaca steps away for a bit (washing machine beeping)
<mborzecki> zyga: no need, just curious
<zyga> one more place and I think this is good
<zyga> mborzecki: heh, now the delta code sends the crap again
<zyga> or is it...
<zyga> I don't see it in the tree anymore
<zyga> but I do see it in the tarball we make early on
<mborzecki> ehh debhelper
<Chipaca> https://bugs.launchpad.net/snapd/+bugs?field.status%3Alist=NEW is a thing of beauty
<seb128> Chipaca, try that on the ubuntu package :)
 * Chipaca kickbans seb128 
<seb128> sorry *g*
<zyga> mborzecki: it's fun, disabled the repack helper for a second and I see tar is still ask to send the stuff over
<Chipaca> :*)
<zyga> mborzecki: maybe it's a bug in tar
<zyga> checking
<zyga> yeah
<zyga> tar is not respecting those
<zyga> looking deeper
<zyga> man this used to be easier
<mvo> Chipaca: no open bugs
<mvo> Chipaca: \o/
<zyga> mvo: no open bugs?
<zyga> did we just close them for 5 minutes to feel better ;) ?
<mvo> zyga: thats what LP told me
<mvo> "
<mvo> There are currently no open bugs.
<mvo> "
<mvo> zyga: in https://bugs.launchpad.net/snapd/+bugs?field.status%3Alist=NEW
<mvo> zyga: its a lie of course, it should be "no open bugs in this filtered view"
<zyga> :D
<zyga> I see it now
<mvo> but I like the other string better
<mvo> :)
<zyga> 369 open bugs make a man feel honest about himself and that to err is human
<mvo> being a software developer humbles me every single day^Wminute
<Chipaca> zyga: #1761621 sounds like fun for you
<zyga> mmm
<Chipaca> zyga: it's private because of a stacktrace, i presume, let me know if you can't see it
<zyga> I can
<zyga> I'll look later todaty
<Chipaca> ah i see you in the list, even
<Chipaca> anybody with better stacktrace-reading chops than myself (basically all of y'all), #1762686 is a puzzle
<Chipaca> hah! I'd forgotten the "Ubuntu was created for the red-eyed onanists engaged in anal balancing act"
<Chipaca> I wonder if there's a non-escalating way of telling them that was unappropriate
<Chipaca> inappropriate, even
<cjwatson> That isn't just obvious ban-fodder?
<Chipaca> mvo (and maybe cachio when he's around): anything we should do about #1734845 ?
<mup> Bug #1734845: hook (core) configure â exit status 1 cannot create lock directory /run/snapd/lock â Permission denied <snapd (Ubuntu):New> <https://launchpad.net/bugs/1734845>
<Chipaca> cjwatson: I don't know the policy, nor the tools available to enforce it; maybe i should, if i'm going to start calling people out on this kind of stuff
<Chipaca> and I am going to call people out on it
<cjwatson> Was this on Launchpad?
<Chipaca> yes
<cjwatson> I failed to find it
<Chipaca> cjwatson: #1818584
<mup> Bug #1818584: snaps applications can't open files on an USB key <amd64> <apport-bug> <disco> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1818584>
<cjwatson> OK, your response is probably appropriate for what seems like a first offence from a frustrated person.  If they escalate let me know and we'll take administrative action
<Chipaca> cjwatson: will do
<Chipaca> mvo: your input (or your redirect to somebody else) on #1747735 would be good
<mup> Bug #1747735: command-completion for 'snap' on 14.04 does not recommend snapd <trusty> <command-not-found (Ubuntu):Won't Fix> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1747735>
<mvo> Chipaca: in a meeting, will get back to you
<Chipaca> a bug for snapd/ubuntu: gnome display manager it's slow with devuan
 * Chipaca is nearly WATed out
<zyga> mborzecki: debugged it
<zyga> maaaan
<mborzecki> zyga: ok, i think i have worked around dh_systemd_start, but heh it's ugly
<ogra> Chipaca, stop complaining, just fix it !
<ogra> (its just a quick port to sysvinit to fix that devuan problem)
<Chipaca> ogra: in the _description_ of the bug they say "it was only solved by installing the Nvidia drivers."
<Chipaca> ogra: so the bug is... probably? that nouveau drivers are slow?
<ogra> ah, then it is easy, just make the nvidia drivers a hard dep of snapd
<Chipaca> chocolate por la noticia
<ogra> (how would it work on devuan *at all* ? there is no systemd, logind or any other of the lennartisms in it)
<mup> PR snapd#7578 closed: sandbox/cgroup, overlord/snapstate: move helper for listing pids in group to the cgroup package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7578>
<mup> PR snapcraft#2743 closed: meta: warn about command mangling <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2743>
<mup> PR core18#140 closed: run-snapd-from-snap: check for snapd.service existing too <Created by anonymouse64> <Merged by sil2100> <https://github.com/snapcore/core18/pull/140>
<ondra> Chipaca hi
<ondra> Chipaca I added more logs and essentially this is all down to sha384 :(
<Chipaca> ondra: I feel like you owe me a beer or something for not believing me
<ondra> Chipaca as when we preparing seed, we calculate sha384 while we are parsing seed.yaml
<Chipaca> ondra: would've saved us both a few hours of work :)
<ondra> Chipaca I'm happy to get you beer :)
<ondra> Chipaca but it's not key generation, this is snap assertion validation
<Chipaca> ondra: strange that you don't see the io or cpu usage of it though, maybe things aren't lining up properly in the bootchart?
<ondra> Chipaca also interesting one is, if I calculate it from shell, I get 100% cpu load and I get it also 2 as fast for all snapc
<Chipaca> ondra: _before_ even looking at key gen etc i said it was probably still the sha3
<Chipaca> :-/
<ondra> Chipaca I loop through all snaps, and it's not taking me as much time
<ondra> Chipaca ah, sorry for that, I did miss sha3 message from you
<ondra> Chipaca I did not know we calculate sha3 before we start seeding, I though we do that at time of actual snap seeding
 * pstolowski walk, bbiab
<ondra> Chipaca but cpu load is indeed something puzzling
<mup> PR snapd#7580 closed: spread.yaml: exclude vendor dir <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7580>
<Chipaca> ondra: look for an email with subject 'booting the pi', 26 Jan 2017
<mvo> Chipaca: snap on trusty - oh well
<Chipaca> mvo: ikr
<ondra> Chipaca ahh nice, found it
<mvo> sil2100: thanks for merging the latest core18 PR from ijohnson ! our of curiosity, when do we plan the next stable core18 snap release?
<mvo> sil2100: we have this fix and the netplan update in edge, would be great if those would make it to stable soon(ish)
<Chipaca> ondra: wrt looping through all the snaps: did you unmount them and drop caches first
<Chipaca> ondra: it's possible a large chunk of it is i/o
<Chipaca> depends on how slow the sd card is maybe
<ondra> Chipaca no I did not umout them
<Chipaca> ondra: i'm assuming having them mounted keeps them in the cache somehow but could be wrong
<Chipaca> ondra: also, what are you using to hash them from shell?
<sil2100> mvo: yw! In theory today's a Thursday, so if the timing is right it should get picked up by automation into beta and then to certification testing - we might be able to get it to stable around Monday
<mvo> sil2100: amazing, thank you
<ondra> Chipaca may be some, but I doubt entire snap and all, that would be half of all mem available
<Chipaca> ondra: because sha3-384 is not sha384
<ondra> Chipaca I just called sha384sum
<Chipaca> ondra: yeah, that's the wrong hash
<ondra> Chipaca ah
<Chipaca> that's an easy hash :)
<ondra> Chipaca which one to use then?
<Chipaca> ondra: snap install sha3384 ?
<mvo> pedronis: 7556 has two +1, my two nitpicks can easily be done in a followup, I would love to see this landing so that the next pr is smaller, wdyt?
<diddledan> re: https://discourse.ubuntu.com/t/testing-default-snap-apps-against-equivalent-deb-apps-slow-start-times/12875/17 the desktop launcher script runs gdk-pixbuf-query-loaders and gtk-update-icon-cache and gio-querymodules.. could we utilise the $SNAP_DATA or $SNAP_COMMON directories for these caches and generate them in an install and/or refresh hook?
<mup> PR snapcraft#2746 closed: elf: handle missing dependencies not found on system <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2746>
<ondra> Chipaca yep. now time alines more
<ondra> Chipaca damn it, no cheap wins :(
<Chipaca> diddledan: is there a way to do it incrementally so a user can also have local stuff?
<diddledan> those caches only parse files that are distributed within the snap or runtime-snap so the user won't have their own local stuff, AFAIK
<Chipaca> then why is it done at install at all?
<Chipaca> why isn't it in the snap itself?
<Chipaca> anyway, â lunch
<diddledan> it is in the snap currently as part of desktop-launch script which wraps the actual command
<diddledan> I was thinking we could extract it from running every launch to only running once when the snap is installed or refreshed
<diddledan> at the moment it conditionally runs on refresh at launch time. so we can move it to refresh-time so that the initial launch after a refresh is perceviably faster
<diddledan> i.e. in the launch script it has equivalent of `if refreshed, rebuild caches, then run the app`
<mvo> mborzecki: did you had a chance to look at the error log in 7572?
<mup> PR snapd#7572 closed: gadget: rename "boot{select,img}" -> system-boot-{select,image} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7572>
<mborzecki> yeah, but it dodn't make any sense though, if it keeps repeating we'll probably need to take a closer look at either glibc or go in arch
<mborzecki> mvo: ^^
<mvo> mborzecki: ok, thats fine. lets assume its just a glitch
<mborzecki> mvo:  might be serious though, afaict it was related to thread local storage
<mvo> mborzecki: hm, ok
<mborzecki> zyga: tests/main/lxd is leaking this: https://paste.ubuntu.com/p/zkY96DMsT6/
<mborzecki> zyga: or, iow lxd is leakingthis
<mborzecki> i suppose the debug output should include findmnt
<zyga> that's curious
<zyga> the common/ns/mntns thing is a bind mounted mount namespace
<zyga> I really really wish lxd removal would clean up
<zyga> mborzecki: can we paper over this with lxd-tool patch?
<zyga> mborzecki: tests/lib/bin/lxd-tool
<zyga> though it's more serious as it seems to break actual "snap remove", right?
<mborzecki> zyga: we can, stil, removing lxd snap does not clean this up
<mborzecki> yup
<mup> PR snapd#7582 opened: spread: include mounts list in task debug output <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7582>
<mborzecki> zyga: ^^
<zyga> mborzecki: +1 but would you mind changing that to co via prepare-restore.sh --debug-each and move the code there. This way more shellcheck love is applied.
<mborzecki> zyga: this is covered by spread-shellcheck already
<zyga> debug: | ?
<mborzecki> zyga:  i mean spread.yaml
<mborzecki> hmm let me double check
<zyga> mborzecki: https://github.com/snapcore/spread/pull/89
<mup> PR spread#89: runner: pass --exclude-vcs{,-ignores} to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
<mborzecki> zyga: yup, debug && debug-each are covered by spread-shellcheck
<zyga> mborzecki: fair enough, +1
<zyga> though I'd still prefer to have less things in the main yaml
<zyga> but that's not a problem for this
<zyga> mborzecki: I think we should re-check the leak checker
<zyga> mborzecki: and see if we can land it for classic
<zyga> mborzecki: even if core is still leaking other stuff I didn't fix
<mborzecki> Chipaca: mvo: https://github.com/snapcore/spread/pull/89 might interest you as well
<mup> PR spread#89: runner: pass --exclude-vcs{,-ignores} to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
<zyga> mborzecki: we'd know earlier
<mborzecki> zyga: wodner if that's something that snapd could police as well
<zyga> mborzecki: that's a whole new world there
<mborzecki> otoh lxd is a special snowflake
<mup> PR snapd#7583 opened: usersession: drive by fixes for things flagged by unused or gosimple <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7583>
<mborzecki> really simple PR ^^
<Chipaca> I wish I knew what these stacktraces were about
<Chipaca> they're just â¦ noise
<mup> PR snapd#7576 closed: spread.yaml,.gitignore: sync ignored files <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7576>
<zyga> brb
<mborzecki> Chipaca: which ones?
<Chipaca> mborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1841384 or https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1762686 for ex
<mup> Bug #1841384: snapd crashed with SIGSEGV <amd64> <apport-crash> <eoan> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1841384>
<mborzecki> Chipaca: interesting, in https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1762686 there's an awful lot of threads stuck in receiving from a client, probably via the snapd socket
<mup> Bug #1811534 changed: snap - install skype warning - main.go: should be wrapped in (i18n) <i18n> <snapd:Incomplete> <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1811534>
<mup> PR snapcraft#2748 closed: meta: warn about command mangling <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2748>
<mborzecki> Chipaca: then in the other one, there's only a single thread that's not stuck in something sleep related, and it's calling runtime.scanobject (b=824633781392, gcw=0xc000044170) at /usr/lib/go-1.11/src/runtime/mgcmark.go:1140
<mborzecki> Chipaca: hm memory corruption perhaps?
<zyga> man, it's raining like hell again
 * mborzecki was hoping for a bike ride today
<zyga> yeah
<zyga> me too
<zyga> it's looking like Saturday will be nice
<zyga> 20C and sun, wow
<mup> PR snapd#7584 opened: .gitignore: pair of trivial changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7584>
<zyga> mborzecki: ^
<mup> PR snapd#7585 opened: spread.yaml: drop exclude list, use .gitignore <Created by zyga> <https://github.com/snapcore/snapd/pull/7585>
<zyga> pstolowski: it's a one liner to measure the time it really took to run configure
<zyga> pstolowski: I can show you where to patch
<zyga> pstolowski: it's useful to do this if you have the rest of the setup
<pstolowski> zyga: sure
<zyga> pstolowski: on an os/exec.Cmd you can get .ProcessState which has .SystemTime and .UserTime
<zyga> just log them after the process terminates
<zyga> it's that simple
<pstolowski> zyga: ah, that, right, i think we discussed that at some point some time ago
<zyga> yeah, JFinallyDI
<zyga> mvo: if you can review the spread change it woulod help me a little
<mvo> zyga: sure thing
<mvo> zyga: you may need to remind me toromorrow though
<mvo> zyga: today is super busy :/
<mvo> (for me)
<zyga> mvo: it's a one liner
<zyga> https://github.com/snapcore/spread/pull/89 :)
<mup> PR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
<cmatsuoka> cachio: I got this error in the test log, do you know how can I get more information on what failed? https://api.travis-ci.org/v3/job/596058356/log.txt
<cmatsuoka> cachio: look for "build failed"
<cmatsuoka> cachio: ah ok, just found an error messages several lines above that
<cmatsuoka> cachio: but that line number doesn't make any sense :\
<ijohnson> ondra, Chipaca if you want faster SHA3 on arm, please +1 this issue https://github.com/golang/go/issues/28148
<zyga> cachio: perhaps you could look at https://github.com/snapcore/spread/pull/89
<mup> PR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
<zyga> pstolowski: can you please look at https://github.com/snapcore/snapd/pull/7584 -- 3 lines
<mup> PR #7584: .gitignore: pair of trivial changes <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7584>
<zyga> gitignore
<roadmr> does snapd identify if a snap requires a specific content snap and install the content snap automagically?
<roadmr> (i.e. snapian)
<mborzecki> roadmr: afaik snap.yaml must name a default-provider for a given content plug
<roadmr> mborzecki: and the named default-provider snap gets auto-installed/
<roadmr> ?
<mborzecki> roadmr: yes
<roadmr> thanks mborzecki :)
<Chipaca> ijohnson: out of curiosity, how hard would it be to pull that in to our snapd build for armhf?
<roadmr> you're pulling my armhf
<ijohnson> not too hard, it would be a little awkward IIRC because the hashers in crypto aren't used directly they're registered with the hash package and so we'd have to go use the hasher from sha384 directly rather than using crypto
<ijohnson> Chipaca: ^
<ijohnson> the big thing why I don't think we should do that is because now we have to maintain that SHA3 crypto code
<Chipaca> yeah i get that
<Chipaca> but https://go-review.googlesource.com/q/hashtag:%22crypto-assembly%22+(status:open)
<Chipaca> does not fill me with hope
<ijohnson> Chipaca: yeah from talking some of the other go devs, the main person who does crypto + assembly review for Go is very very busy and has had a lot of other $GOOGLE things to do in recent years
<Chipaca> brb, rebooting
<mup> PR snapd#7583 closed: usersession: drive by fixes for things flagged by unused or gosimple <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7583>
<mvo> pedronis: do you mind if I merge 7462 (the  grade support for models in uc20?)
<pedronis> mvo: I can do it, one sec
<mup> PR snapd#7462 closed: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7462>
<mvo> pedronis: thanks
<mvo> pedronis: 7556 can probably also be merged, the suggestions could be done in a follouwp, this would unblock the next review I think(?)
<pedronis> mvo: it's about documenting, maybe renaming TargetFunc, right ?
<ondra> Chipaca I managed to shave 40s from that boot now :)
<pedronis> mvo: and a typo
<pedronis> mvo: I can merge and then I would apply those in the follow up
<pedronis> if that's ok
<ondra> Chipaca it will need reviewing from someone who can understand more implications of what I changed
<pstolowski> mborzecki: some questions/comments to schedule fix PR
<ondra> Chipaca but thats ~80s to ~40s
<mvo> pedronis: yeah, lets do it this way (merge+followup)
<ondra> Chipaca see bootchart https://private-fileshare.canonical.com/~okubik/bootchart-20191010-1545.svg
<mvo> pedronis: thank you!
<ondra> ogra https://private-fileshare.canonical.com/~okubik/bootchart-20191010-1545.svg
<mup> PR snapd#7556 closed: image,seed/seedwriter: switch image to use seedwriter.Writer <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7556>
<ondra> mvo pedronis this could be something we might consider for landing once polished, see the difference in cpu from 60 to ~100 second
<ondra> https://private-fileshare.canonical.com/~okubik/bootchart-20191010-1545.svg and https://private-fileshare.canonical.com/~okubik/bootchart-20191008-1710.svg
<Chipaca> ondra: what is the change?
<mvo> ondra: what exactly?
<mvo> ondra: do you have a diff or something?
<ondra> Chipaca mvo diff soon
<ondra> Chipaca mvo but I'm calculating sha3384 in parallel
<ondra> so this will be even faster on multicore devices
<ondra> on 4cores this cut hashing to half, and it's mostly because one snap is 3x bigger then next biggest
<ondra> mvo Chipaca one of you just need to review if I'm not messing up with snap seeding order
<pedronis> we are touching that code quite a bit atm
<pedronis> so it's probably easiest to just see the diff and measure it and do it again if it's useful
<ondra> pedronis are any of your changes parallelising hash calculation?
<pedronis> no, but we intergrating UC20 code
<pedronis> which does still differently
<ondra> pedronis right
<ondra> I will prepare clean diff
<pedronis> is this a change in seed16.go ?
<pedronis> or the older code?
<ondra> I still think this is worth to consider, as we sit there for 2 minutes with one core maxed and rest of the system is idling
<ondra> pedronis in seed16.go
<pedronis> ok
<pedronis> that shouldn't change a lot anymore
<pedronis> but we'll see
<pedronis> clean diff is a good start
<ondra> pedronis +1
<ondra> Chipaca mvo it influenced order how snaps are seeded
<ondra> so it will still need some tweaking there
<pedronis> ondra: that doesn't sound right
<pedronis> to be clear
<ondra> pedronis well this is first shot and I'm just checking how to address this
<pedronis> #7558 is ready for review
<mup> PR #7558: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <https://github.com/snapcore/snapd/pull/7558>
<pedronis> Chipaca: there are also bits in boot there ^
<Chipaca> k
<Chipaca> i don't think i'll get to that today
<pedronis> np
<pedronis> just fyi
<mup> PR snapd#7584 closed: .gitignore: pair of trivial changes <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7584>
<zyga> pedronis: you have two entries in the meeting notes for Thursday
<zyga> is one of them for Friday or should they be merged?
<Chipaca> zyga: one is pedronis' clone
<zyga> that explains it :)
<Chipaca> anyhoo, i'm outa here
<Chipaca> see y'all tomorrow
<zyga> good call :)
<Chipaca> ð
 * zyga hugs Chipaca 
<zyga> bye :)
 * Chipaca hugs back
<zyga> niemeyer: hello, low priority but also low effort request to look at a small change to spread: https://github.com/snapcore/spread/pull/89
<mup> PR spread#89: runner: pass --exclude-vcs-ignores to tar <Created by zyga> <https://github.com/snapcore/spread/pull/89>
 * cachio afk
<mup> PR snapcraft#2749 opened: storeapi: add StoreErrorList to handle store errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2749>
<joedborg> hey zyga
<zyga> hey
<zyga> it's a little late so I may not respond instantly
<zyga> but please leave me a message and I'll get to it as soon as I can
<joedborg> zyga: ah apologies, i keep missing you
<joedborg> just wondering if you can help with what exception i need to add to apparmor for
<joedborg> `[285928.025967] audit: type=1400 audit(1570741250.597:1384598): apparmor="DENIED" operation="signal" profile="docker-default" pid=703 comm="kubelet" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.kubernetes-worker.kubelet"`
<zyga> no need to apologize, it's not our fault :)
<zyga> sure
<zyga> this means that the profile called 'docker-default' constrains a process with pid 703 so that it cannot receive the kill signal from a process labelled snap.kubernetes-worker.kubelet'
<zyga> if you can craft the docker-default profile then it's a one liner to change
<zyga> AFAIR, without checking something like: signal (receive) peer=snap.kubernetes-worker.kubelet,
<zyga> note that the permission applies on both sides
<zyga> so the snap.kubernetes-worker.kubelet needs a send permission with the appropriate peer
<zyga> joedborg: does this make sense?
<zyga> joedborg: you can constrain the signal further with set=(...)
<joedborg> zyga: is there a quick line i can get round it with?
<joedborg> * that i can add to app armor
<zyga> signal (receive) set=(kill) peer=snap.kubernetes-worker.kubelet,
<zyga> though note that the peer here specifies the snap name
<zyga> so only that snap (and only that snap) would work
<zyga> it may require some more ooomph
<zyga> perhaps the signal could be accepted from any snap that can send it
<zyga> so you could just say:
<zyga> signal (receive) set=(kill) peer=snap.*
<zyga> (make sure to add the trailing comma)
<joedborg> zyga: thanks, i'll try that now
<joedborg> it's just a further PoC, so I can arrest it if and when it works :)
<zyga> joedborg: cool :)
<zyga> joedborg: yeah, try that, let me know if it works or not
<joedborg> zyga: sadly not, I added that to the profile `/var/lib/snapd/apparmor/profiles/snap.kubernetes-worker.kubeletÂ¬
<joedborg> * `/var/lib/snapd/apparmor/profiles/snap.kubernetes-worker.kubelet`
<zyga> that's not the profile
<zyga> look at what I said above
<zyga> this is confining the process using the docker-default profile
<zyga> whatever owns and writes *that* profile must change
<zyga> when you have two processes with apparmor profiles
<zyga> and they signal each other
<zyga> the sender needs the send permission for the peer
<zyga> (and you have that or the denial would say profile=snap.foo.bar)
<zyga> the recipient needs the corresponding permission
<zyga> that matches the peer
<zyga> it's funny but you can craft an apparmor profile that denies sigkill with this
<zyga> (from unconfined)
<zyga> joedborg: does this make sense?
<joedborg> zyga: how do i get at the docker-default profile?
<zyga> joedborg: I don't know that, presumably something writes one, one sec
<joedborg> zyga: i can't see it in `/var/lib/snapd/apparmor/profiles/`
<zyga> it's not a profile made by snapd
<zyga> so I suspect the snap itsef makes it
<zyga> ijohnson: ^^ perhaps you know?
<zyga> joedborg: in other words, no amount of changes to snapd will fix it
<ijohnson> let me read the scrollback
<zyga> the profile you must change is made or belongs to another package, presumably just docker
<zyga> ijohnson: tl;dr; do you know if docker snap makes "docker-default" apparmor profile?
<zyga> and if so, do you know how to change the code that makes it so that it has one more line
<ijohnson> ah yes docker-default is generated by docker/runc when you create containers
<ijohnson> in the docker snap we had to patch the docker-default profile to allow containers to start properly when dockerd is confined by snapd/apparmor
<joedborg> ijohnson zyga so there's nothing i can do on a running system to patch this?
<ijohnson> essentially, the default docker-default profile only allows unconfined processes to talk to it, so confined ones like dockerd inside the docker snap are denied as you see above
<ijohnson> joedborg: unfortunately IIRC dockerd generates the docker-default profile in /tmp, loads it into the kernel and then deletes the /tmp profile, so no I don't think you can do to a running system to patch this
<zyga> joedborg: not without fighting with docker
<ijohnson> you need to patch dockerd to modify the docker-default profile to include that line
<joedborg> zyga: ijohnson well containerd in my case
<zyga> joedborg: you could create a profile that is the same, has one more permission, and load that
<ijohnson> err yeah
<joedborg> zyga: ijohnson: I can carry on in devmode and log it as a bug?
<zyga> but that would have to be done again each time docker decided to reload the profiles
<ijohnson> containerd/dockerd/runc/moby/the kitchen sink/a bag of chips/
<zyga> joedborg: you'd have to run docker in devmode
<ijohnson> jodbord: nah I don't think so, because you need the docker-default profile to be in devmode, not the snap
<ijohnson> there's a way to launch a container with containers having their apparmor profiles turned off though
<ijohnson> err that was akward to say
<zyga> actually
<ijohnson> there's an option to dockerd/containerd/whatever to launch containers without the docker-default profile
<zyga> nah, that's not a good idea
<ijohnson> I can't remember off the top of my head
 * zyga remains quiet
<ijohnson> zyga: yeah it's not a good idea, but it's the same as running in devmode
<joedborg> zyga: ijohnson: so this is for the kubernetes-worker snap which has containerd bundled inside the snap
<zyga> I was thinking about using aa_complain
<zyga> but I think that only works if you can point it to a profile text
<ijohnson> joedborg: ah if you're building the snap then you can just patch dockerd/containerd
<joedborg> ijohnson: how? :)
<ijohnson> joedborg: this is the patch we used in the docker snap for github.com/docker/docker (aka github.com/moby/moby): https://git.launchpad.net/~docker/+git/snap/tree/dockerd-patches/snappy-apparmor-tweaks.patch
 * zyga doesn't know that and returns to audiobooks and assembly
<ijohnson> zyga: go do that and stop working :-)
<zyga> thank you ijohnson
<zyga> joedborg: you are in good hands :)
<joedborg> thanks zyga, sorry to have kept you at your desk
<ijohnson> joedborg: how are you building containerd?
<joedborg> ijohnson https://github.com/charmed-kubernetes/snap-kubernetes-worker/blob/master/snap/snapcraft.yaml
<joedborg> it's being built in the snap
<ijohnson> hmm this snapcraft.yaml is a bit weird, is there a reason you use `go get ...` instead of the source spec for all these parts?
<joedborg> ijohnson: i thought we had similar issue that jdstrand got into the containerd profile
<joedborg> ijohnson: yeah because kubernetes doesn't build things properly
<ijohnson> but anyways since you're building containerd from scratch patching it shouldn't be too much work
<ijohnson> hmm well still you could let snapcraft check it out, that would save you rebuild times, but oh well
<joedborg> ijohnson: can you give commit hashes to snapcraft?
<ijohnson> yes, `source: github.com/....` and then do `source-commit: SHA`
<ijohnson> joedborg: see https://snapcraft.io/docs/snapcraft-parts-metadata#heading--source
<joedborg> ijohnson: thanks, i'll add that in the todo to look at
<ijohnson> joedborg: so you need to patch https://github.com/containerd/containerd/blob/1ac546b3c4a3331a9997427052d1cb9888a2f3ef/contrib/apparmor/template.go
<ijohnson> that's the "docker-default" profile in containerd AFAICT
<ijohnson> I don't actually see anything named docker-default in containerd, so I assume it's probably k8s or something else that is using the docker-default name when driving containerd
<joedborg> ijohnson: cool, thanks, and there's no way to do this outside of containerd upstream?  I might (and probably) mixing different issues, but I think that jdstrand and I saw a similar signal violation (of containerd inside the snap) and fixed it in the template for the interdace
<joedborg> *interface
<ijohnson> joedborg: jdstrand is the apparmor expert so perhaps I'm mistaken but when I went through this excercise for the docker snap, we had to patch docker because the issue was not that the _snap_ processes were being denied stuff from apparmor, but rather that the _container_ processes were being denied stuff and the container processes are under a different apparmor label, so that different label has to be modified
<ijohnson> If you look in docker-support interface, you can see that there's a rule to allow transition between the snap apparmor label and an apparmor profile named docker-default, so dockerd can launch a process, which will be confined by the snap's apparmor profile, then have that process transition to the container apparmor profile
<ijohnson> I see that this k8s snap is using docker-support, so actually I assume that is part of why you need to use docker-default even when k8s is driving containerd, as there's no transition rule for i.e. containerd-default apparmor profile that I see
<ijohnson> joedborg: the only other thing I could think of would be to launch every container with a manually specified apparmor profile, but that might interfere with users who have their own apparmor profile they want to launch containers with
<joedborg> ijohnson: yeah i get that, it's an issue we've been seeing a lot - where directories inside the container are being given readonly; even though they're confined by the pivot route
<joedborg> ijohnson: I suspect we added some to get the PoC working but, in fact, we need to open the containerd profile up a bit more by patching the file you suggested
<joedborg>  /pivot route/pivot root/
<ijohnson> joedborg: another useful patch you might want to look at from the docker snap is the one that changes pivot_root to just chroot all the time, because when you pivot_root then apparmor doesn't understand that your new files you touch are really prefixed with the old_root parameter
<ijohnson> so that leads to you having to add all these random accesses that ideally wouldn't be necessary since the container isn't ever touching any host files or base snap files, it's just using it's own rootfs from $SNAP_DATA or somewhere, so it's fine to let it use whatever files it wants
<ijohnson> joedborg: that patch is here: https://git.launchpad.net/~docker/+git/snap/tree/dockerd-patches/snappy-real-chroot.patch
<joedborg> ijohnson: ah thatâs sounding like weâre seeing the same thing, cool.  Just reading that patch
<ijohnson> yeah I recommended to someone a long time ago that as they start working on building k8s into a strict snap they should look at the docker snap, but apparently that advice was forgotten
<ijohnson> ð¤·ââï¸
<joedborg> ijohnson: yeah, docker isnât cool anymore so weâve gone down the containerd path ð
<ijohnson> ... and yet still have the same problems ð¤
<ijohnson> ð
<mup> PR core-build#54 closed: initramfs: update unlock keyfile parameter <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/core-build/pull/54>
<joedborg> ijohnson: haha yes, seem so.  we had time pressure for the poc so I think the rules jdstrand put in were to get the basics cleared.  we could reconcile when heâs back?  itâd be nice to sort this properly (and we could get a free containerd snap too)
<ijohnson> joedborg: yeah that sounds good
<ijohnson> I think jdstrand is back next week iirc
<joedborg> ijohnson: awesome. yeah I think so too.   thanks a lot for your help :)
<ijohnson> np, happy to help while z y g a should be offline :-)
#snappy 2019-10-11
<mup> PR snapcraft#2749 closed: storeapi: add StoreErrorList to handle store errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2749>
<mborzecki> morning
<mborzecki> zyga: i'm playing a bit with repck in spread, instead of a 5.5MB archive i usually got, i'm getting 2.8MB now
<mborzecki> mvo:  morning
<mvo> hey mborzecki ! good morning
<mup> PR snapd#7582 closed: spread: include mounts list in task debug output <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7582>
<pstolowski> morning
<zyga> Good morning
<zyga> Iâll start later today, just doing morning dog walk
<zyga> See you in 30
<zyga> mborzecki: try that with spread doing gitignore and the matching snapd branch please
<zyga> back
<pstolowski> mvo: #7558 can land, or do want to wait for Samuele?
<mup> PR #7558: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <https://github.com/snapcore/snapd/pull/7558>
<zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/7547/files a little
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<bloodearnest> Chipaca: o/ - FYI, I worked around the this issue with services failing on refresh, and filed this bug for your consideration:
<bloodearnest> https://bugs.launchpad.net/snapd/+bug/1847723
<mup> Bug #1847723: Config hook is run after services start during refresh <snapd:New> <https://launchpad.net/bugs/1847723>
<Chipaca> bloodearnest: what about the different -refresh hooks?
<Chipaca> bloodearnest: e.g. post-refresh?
<Chipaca> bloodearnest: ISTR post-refresh comes right before start-services
<bloodearnest> Chipaca: so, my fix was to regenerate the config in post-refresh in my snap. But I think that that argubly shouldn't be nessesary?
<Chipaca> ah i see you mention that i the bug
<bloodearnest> yeah
<bloodearnest> I'm sure there's things I'm missing, but it was a suprise to me that the config hook ran after services had been started
<Chipaca> bloodearnest: I'll let pstolowski and/or pedronis figure out whether the current behaviour is correct or not :-)
<bloodearnest> sure, thanks for your time
<pstolowski> bloodearnest, Chipaca yes, this (config hook running after services start) has been known for a long time (and we know it's annoying), we touched that briefly with pedronis even recently with the conclusion that we might reconsider the order if there are strong arguments
<bloodearnest> pstolowski: great. Well, consider that bug this user's vote on the isssue :) It's a dual of the install/config hook interplay really, where services can start before config hook as run there too.
<Chipaca> bloodearnest: OTOH I can imagine snaps with the opposite problem, needing the services running for 'configure' to make sense?
<Chipaca> brb, installing eoaiun
<zyga> Chipaca: oh my :-)
<zyga> I wonder what your experience will be like
<Chipaca> zyga: slow
<Chipaca> the only machines i have that i'm willing to sacrifice to the goddess eoan are slow
<mup> PR snapd#7586 opened: interfaces/optical-drive: additional permission needed by mir-kiosk-kodi <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7586>
<mup> PR snapd#7587 opened: spread: generate delta when using google backend <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7587>
<mborzecki> zyga: mvo: ^^ this should fix the source package size uploaded by spread for a while
<zyga> nice
<zyga> thank you
<bloodearnest> Chipaca: very possiblly :)
<mvo> mborzecki: nice one!
<xiaoji> does anyone know How to statistics the number of software in gnome-software
<zyga> xiaoji: gnome-software is a tarball, what it shows when you build and run depends heavily on configuration
<Chipaca> xiaoji: by "software" do you mean packages? apps? binaries?
<Chipaca> xiaoji: and do you mean the number installed, available for install, ...?
<Chipaca> xiaoji: and do you mean how many does gnome-software show, or do you mean how do you get gnome-software to show you the number?
<xiaoji> thanks
<xiaoji> yes
<xiaoji> I want to know how many software can be installed and have been installed in gnome-software
<mup> PR snapd#7588 opened: cmd/snap: add a "snap internal portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<Chipaca> jamesh: that's not the first internal command we have, any reason to add the new toplevel 'internal', etc?
 * zyga installs gobs of updates
<Chipaca> xiaoji: why are you asking in this channel?
<xiaoji> I have asked on many channel and many IM..
<xiaoji> sorry
<Chipaca> xiaoji: where?
<Chipaca> xiaoji: as zyga pointed at, gnome-software is the frontend to a number of backends, and not all those backends offer a count. Also you haven't told me what "software" is, nor on what distro you are
<Chipaca> for example, if "software" is a package, and you are on a debian-derived distro, you can answer "how many are installed" via the backend tools
<Chipaca> i guess the same is true for other distros
<Chipaca> so it's not clear you know what you are asking
<Chipaca> so, how to answer you? your question is unclear, to begin with
<xiaoji> I am on ubuntu 18.04
<Chipaca> are you using flatpak?
<xiaoji> no,only install software from software-center
<Chipaca> i thought you could get flatpak via the software-center, but ok
<Chipaca> xiaoji: and, what is "software"?
<Chipaca> xiaoji: is a library-only debian package, "software"?
<Chipaca> xiaoji: is bash "software"?
<xiaoji> .. I dont know
<Chipaca> xiaoji: ok. Going back a step, why do you want to know statistics about this?
<xiaoji> I saw many software in gnome-software,they have icon. I want know how many
<mup> PR snapd#7558 closed: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7558>
<jamesh> Chipaca: I seem to remember zyga suggesting it during previous discussions, and it seemed like a reasonable idea.  I can remove that part of the PR quite easily though
<zyga> jamesh: I still like it
<Chipaca> jamesh: i don't think it's a bad idea, and i like the refactor, but i feel it should be separate from the feature
<Chipaca> and maybe we should discuss moving other internal commands to this
<jamesh> Chipaca: I can split it out easily enough: it's the first commit.
<Chipaca> jamesh: neat
<Chipaca> jamesh: I'd expect pedronis to have an Opinion about that, and he's off today
<Chipaca> just fyi
<Chipaca> Wimpress: is there anything like an eoan mate installer already?
<Chipaca> facubatista: "eoan mate", https://flic.kr/p/6wqZBC
<Chipaca> xiaoji: so, for an approximation
<Chipaca> xiaoji: open a terminal, and see if you have the "appstreamcli" command
<Chipaca> xiaoji: if you do, then the number of things gnome software offers you is the number in Summary of "appstreamcli status", *plus*, the output of "wc -l /var/cache/snapd/names"
<Chipaca> approximately; some things might be counted twice in the above
<Chipaca> if you _don't_ have appstreamcli, you need to 'sudo apt install appstream' and then 'sudo apt update' for the number to be right
<Chipaca> both numbers should be ~2k or more
<Chipaca> although it varies by arch and region
<mup> PR snapd#7589 opened: cmd/snap: add ability to register "snap internal" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<Wimpress> Chipaca: Do you mean an iso image for Ubuntu MATE 19.10?
<Chipaca> Wimpress: i think i found it at http://cdimage.ubuntu.com/ubuntu-mate/daily-live/current/HEADER.html
<Chipaca> heh, dunno why google took me to the header, but ok
<Wimpress> Yep, that's what you want ð
<mborzecki> pstolowski: replied in #7443
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pstolowski> mborzecki: ok
<Chipaca> Wimpress: ooh, installer crashed :-)
<facubatista> Chipaca, a mate, indeed, why eoan?
<Chipaca> facubatista: eoan â maÃ±anero
<Chipaca> roughly
<facubatista> Chipaca, ah, didn't know that
<Chipaca> facubatista: https://en.wikipedia.org/wiki/Eos
<Chipaca> facubatista: "diosa de la aurora"
<Chipaca> facubatista: I would've written that as "diosa del aurora" but maybe la->el to avoid vowel clash is frowned on these days?
<facubatista> Chipaca, much funnier name the roman equivalent
<facubatista> "mater matuta"
<Chipaca> facubatista: :)
<Chipaca> xnox: if the ubuntu installer crashes, is there anything useful or interesting for you?
<Chipaca> or should i just do over
<Chipaca> (maybe not pick zfs next iteration)
<xnox> Chipaca:  if it installed /var/log/installer otheriwse /var/log/syslog /var/log/partman and like /var/log/ubiquity
<xnox> Chipaca:  possibly check with didrocks & jibel as they have been working on zfs bit in desktop iso.
<Chipaca> xnox: it did not install, I don't think, it was fairly early in the process
<xnox> ack
<Chipaca> I now (after a few minutes) got the "system program problem detected" dialogue
<Chipaca> maybe the "report problem" button gets all those bits of info?
 * Chipaca might be overly optimistic
<xnox> it will
<xnox> but you can also do $ ubuntu-bug ubiquity
<xnox> (will ask for SSO login.....)
 * Chipaca clicks the button and waits patiently
<Chipaca> xnox: ack
<mborzecki> zyga: hmm lxd snap https://paste.ubuntu.com/p/HzGx7PG4pc/
<jibel> Chipaca, give me the bug # once it's reported
<Chipaca> jibel: will do, thanks
<Chipaca> still waiting on apport
<Chipaca> xnox: the "report bug" button didn't seem to do anything fwiw, at least, no apport activity from there
<xnox> Chipaca:  ubuntu-bug ubiquity
<Chipaca> yep
<xnox> Chipaca:  at least that should make a thing in /var/crash/*
<xnox> Chipaca:  any files from /var/crash/* will be useful
<Chipaca> oh god my lp password with no password manager
 * Chipaca reaches for scp
<Chipaca> jibel: #1847748
<mup> Bug #1847748: installer crashed <amd64> <apport-bug> <eoan> <ubiquity-19.10.18> <ubuntu-mate> <ubiquity (Ubuntu):New> <https://launchpad.net/bugs/1847748>
<Eighth_Doctor> mvo, zyga, mborzecki: https://bugzilla.redhat.com/show_bug.cgi?id=1760568
<Eighth_Doctor> any of you have any idea of a way to fix this?
<Chipaca> jibel: let me know if you need any more info from the system before i nuke it and start over
<mborzecki> Eighth_Doctor: saw it in the monring, but wanted to try it myself
<Eighth_Doctor> ðï¸
<jibel> Chipaca, thanks. I'll comment on the report
<mborzecki> Eighth_Doctor: but yes, /var/home is a problem
<mborzecki> Eighth_Doctor: also, not sure why silverblue is not using a bind mount for /var/home -> /home
<zyga> Eighth_Doctor: looking
<zyga> aha, this one
<Eighth_Doctor> mborzecki: that's what langdon and I said too...
<Eighth_Doctor> but unfortunately it's an ostree thing :(
<zyga> there is a way to fix it but not anytime soon IMO
<zyga> enough stuff to fix :/
<zyga> we could remap $HOME to /home/$LOGNAME
<zyga> but that's far from close
 * pstolowski walk & lunch
<zyga> output from gtest is an unreadable mess
<mborzecki> zyga: duh, they changed it like 2 releases back
<zyga> yeah, but it only matters when you have to look
<Eighth_Doctor> zyga: can we add `/var/home` as an allowed redirection?
<Eighth_Doctor> or maybe just follow the symlink and bind-mount the target?
<Eighth_Doctor> (I assume that's what we're doing here with the homedir perm?)
<kjackal> Is there an interface that would allow a command to stop and/or start a service? https://forum.snapcraft.io/t/stop-and-or-start-a-service-from-a-command/13649
<zyga> Eighth_Doctor: not easily
<zyga> there's more to it than that
<mborzecki> off to pick up the kids
<Chipaca> jibel: from your comment I gather you don't need more info and I can re-install
<ondra> Chipaca mvo https://github.com/snapcore/snapd/pull/7590
<mup> PR #7590: seed: seed16: run adding snaps in parallel <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590>
<mup> PR snapd#7590 opened: seed: seed16: run adding snaps in parallel <Created by kubiko> <https://github.com/snapcore/snapd/pull/7590>
<ondra> Chipaca if you help me to land this, I will owe you one extra beer :P
<Chipaca> ondra: hmmmmmmmmmmmm
<Chipaca> ondra: I suspect it needs locks in addEssential, at least
<Chipaca> ondra: but that's just a quick pass
<Chipaca> ondra: I'll take a deeper look later
<ondra> Chipaca not really
<ondra> Chipaca I did keep order there
<Chipaca> ondra: you are writing to a shared map from multiple goroutines
<ondra> Chipaca have a look, only non assync is gadget
<Chipaca> ondra: that's what i mean
<ondra> Chipaca errors are written to shared map
<ondra> Chipaca but there does not seem to be anything which would be related othetrwise
<ondra> have a look
<Chipaca> will do
<Chipaca> ondra: in any case just the fact that you found out this speedup opportunity is awesome
<Chipaca> so I'm happy
<Chipaca> I might be even happier after reviewing this, who knows
<Chipaca> i just don't have the mental bandwidth right now to do it properly :-)
<ondra> Chipaca of course, this is not critical :)
<ondra> Chipaca and it's not remedy to all, make no different on single core, or if you have 3 snaps
<Chipaca> ondra: yeah, for that we need go to take ian's sha3 patches
<Chipaca> ondra: there we get ~60% speedups across all armhf
<ondra> Chipaca imagine combined those two :)
<Chipaca> ondra: ikr
<ondra> Chipaca unless that assembly code also utilises multicore
<Chipaca> i'm sure there exist people that can write multicore assembly
<Chipaca> i think it's all black magic anyway
<vidal72[m]> hi, every time I open firefox it tries to read /var/lib/snapd/desktop/icons which is blocked by apparmor. Is it something fixable?
<Chipaca> vidal72[m]: what snapd version are you on?
<vidal72[m]> Chipaca: one from ubuntu 19.04
<Chipaca> vidal72[m]: what does 'snap version' say?
<vidal72[m]> I'm not on that machine atm, give me a sec
<vidal72[m]> Chipaca: 2.42 series 16
<Chipaca> vidal72[m]: are you sure you're seeing these messages with that version? (it's from yesterday)
<ogra> old stuff then :P
<vidal72[m]> yes, just reproduced minute ago
<Chipaca> jamesh: have you seen this?
<ogra> vidal72[m], is that on app startup or if you do some specific action (opening a file or whatnot)
<jibel> Chipaca, yes, I've enough info, thanks
<Chipaca> jibel: good because i'm already finishing the re-install :-) this time around i had no issues
<jamesh> Chipaca: it's not surprising that apps would try to read various paths under /var/lib/snapd/desktop: that directory is included in $XDG_DATA_DIRS, and various specs say to check all locations contained there
<vidal72[m]> ogra: app startup
<Chipaca> jamesh: hrm, i thought we'd added desktop/icons as ok as part of your icons work
<Chipaca> maybe i was confused then
<jamesh> Chipaca: not for the benefit of confined apps: that was for the host
<Chipaca> ah
<Chipaca> should we add a rule just to not have it spam syslog?
<Chipaca> (i don't mean a rule to allow the read)
<vidal72[m]> +1
<jamesh> perhaps
<vidal72[m]> is it sensitive dir? I think desktop/applicationds are allowed to read
<jamesh> browser-support currently allows access to /var/lib/snapd/desktop/applications, yes
<jamesh> but it probably shouldn't
<jamesh> it's not really useful and is a data leak
<vidal72[m]> I think those should be both allowed or both denied
<vidal72[m]> my icons folder is empty anyway
<jamesh> presumably firefox was trying to access /var/lib/snapd/desktop/icons previously, but it didn't warn due to the directory not existing
<jamesh> as long as we have that directory in XDG_DATA_DIRS, I agree that warnings for access denials are just noise
<vidal72[m]> jamesh: desktop-legacy also allows desktop/applications https://github.com/snapcore/snapd/blob/release/2.42/interfaces/builtin/desktop_legacy.go#L229
<jamesh> vidal72[m]: yep.  I don't think it is useful there either, since neither interface provides a way to launch those applications or access e.g. referenced icons
<vidal72[m]> heh, why it was added then? isn't it needed for xdg-open?
<vidal72[m]> which doesn't work in ff anyway but that's another story...
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7591
<mup> PR #7591: cmd/snap-confine: remove loads of dead code <Created by zyga> <https://github.com/snapcore/snapd/pull/7591>
<mup> PR snapd#7591 opened: cmd/snap-confine: remove loads of dead code <Created by zyga> <https://github.com/snapcore/snapd/pull/7591>
<Chipaca> zyga: can you lead the standup? I don't think I'm going to make it
<zyga> syre
<zyga> *sure
<Chipaca> zyga: thynks
<zyga> ny proolbm
<Chipaca> :)
<jamesh> vidal72[m]: I wouldn't be surprised if the rules grew out of watching the audit logs for various apps without fully thinking through whether it made sense
<zyga> see you at the standup
<Chipaca> zyga: probably not, that's the point :)
<vidal72[m]> jamesh: should I make PR which deny desktop/{applications,icons} then?
<jamesh> vidal72[m]: similar to the icons case, /var/lib/snapd/desktop/applications existed, so it would generate audit messages without the rule allowing read access
<Chipaca> vidal72[m]: jamesh: suspect jdstrand might need to peep into this
<jamesh> vidal72[m]: perhaps start a thread on the forum and tag @jdstrand.
<vidal72[m]> ok
<vidal72[m]> another thing: did anyone considered allowing writing to @{PROC}/@{pid}/clear_refs https://forum.snapcraft.io/t/call-for-testing-chromium-browser-deb-to-snap-transition/11772/17
<Chipaca> zyga: wait i thought mvo was off today
<degville> Chipaca: he's here - he changed his mind apparently.
<mvo> Chipaca: I was considering it
<vidal72[m]> jamesh: done https://forum.snapcraft.io/t/reading-var-lib-snapd-desktop-applications-icons/13650
<zyga> mvo: thank you for the review :)
<zyga> did you read the commit messages?
<vidal72[m]> interestingly snap-store snap wants to read my /home/user/documents dir on each startup which is blocked
<sparkiegeek> hmm, how does one use (install, run) snaps inside a docker container? is that even plausible?
<roadmr> ð¤¯
<sparkiegeek> roadmr: you have tips? :)
<roadmr> only to run away as fast as you can!
 * roadmr does, woohooo
<sparkiegeek> well I was hoping zyga would just tell me that it all works :D
<zyga> sparkiegeek: no can do :(
<zyga> sorry, docker is not able to run docker either
<sparkiegeek> k, am I basically SOL?
<zyga> I'm afraid so
<roadmr> sparkiegeek: why must it be docker?
<sparkiegeek> zyga: np, knowing is better than flailing around
<sparkiegeek> roadmr: Reasonsâ¢
<roadmr> aha, got it :0
<roadmr> heeh :)
<Chipaca> man this system feels slow even over ssh
<ijohnson> ondra, Chipaca: IIRC the SHA3 NEON assembly is not parallelized, so each core has it's own NEON processor and the parallel speedup that ondra has should multiple together with the assembly patches
<ogra> we should also test on an imx6ull to see if there is any impact on single-core SoCs (positive or negative)
<ijohnson> the imx6ull would definitely benefit from the SHA3 patches (I actually tested on one of those :-D ), probably not so much from ondra's parallelization patch though
<ogra> well, the first is a given, the latter is what caused my question :)
<ogra> it might improve, leaving the ordering to the kernel effectively ... or it might degrade because it tries to parallelize where it can not
<ondra> ogra go seems to be somehow smart about loading, so if one tasks pegs the core, it will probably not try to run too many in parallel
 * zyga -> lunch
<Chipaca> cmatsuoka: after much chuntering, I have a booted core!
<Chipaca> jibel: not being too scientific, it seems on this system I need to let it finish disk activity for partitioning before choosing country and creating the user, or it fails
<Chipaca> jibel: "not too scientific" == tried it both ways twice
<Chipaca> popey: Wimpress: I think mate would be better if it waited for seeded before giving you login
<Chipaca> better first boot, you'd get the welcome app for one
<ogra> ondra, well, i'd still perfer if you could hand it to cwayne to see actual results on real imx6ull hw
<Chipaca> cmatsuoka: - Update assets from gadget "pc" (44) (cannot read current gadget snap details: invalid volume "pc": invalid structure #2 ("Recovery"): invalid role "system-recovery": unsupported role)
<Chipaca> cmatsuoka: expected?
<ondra> ogra feel free to get him involved
<ogra> well, you got the patched binary :P
<ogra> i'm just sayig we should make sure to have them in the loop before this goes to stable
<ogra> i guess they'll run QA anyway
<ogra> (on that HW)
<Chipaca> cmatsuoka: mvo: core20 needs to drop the ConditionKernelCommandLine=snap_core from snapd.system-shutdown.service
<Chipaca> :)
<Chipaca> i need to dig into what creates that now that it's automagically put in etc by somethingorother
<Chipaca> not now tho; now, tea
<abeato> sil2100, hey, not sure if you saw my update to https://github.com/CanonicalLtd/ubuntu-image/pull/175 ?
<mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
<mvo> chrisccoulson: indeed, good point
<chrisccoulson> mvo, was that meant for me?
<mvo> chrisccoulson: sorry, for Chipaca
 * Chipaca hands chrisccoulson a "got called Chipaca" beginners badge
 * roadmr is now nown as Choadmr
 * Chipaca wonders if roadmr knows what a choad is
 * roadmr googles
 * roadmr is now known as google-before-changing-nick-mr
<Chipaca> :)
<ijohnson> Chipaca: thoughts on #1847788 ? is this a bug or "AsDesigned"?
<mup> Bug #1847788: reverting and installing a snap deletes a disabled revision that should be kept <snapd:New> <https://launchpad.net/bugs/1847788>
<kjackal> Is there a problem if I maintain a channel branch (eg edge/strict) with a strictly confined snap revision while the rest of the snap revisions in the channel are classic? https://forum.snapcraft.io/t/mixing-strictly-confined-and-classic-snap-revisions-in-a-channel/13652
<zyga> kjackal: migrations from one and the other are not automatic
<zyga> you can go classic -> strict
<Chipaca> ijohnson: the one that's removed is _blacklisted_ (because revert)
<zyga> but not the other way around
<Chipaca> ijohnson: so that changes the behaviour a bit
<Chipaca> ijohnson: you could instead snap refresh --revision x1, that should dwyw?
<ijohnson> Chipaca: I want to keep revision x2 though
<ijohnson> (though this is for a test, so bit of an arbitrary use case)
<kjackal> thanks zyga, it is going to be only me using this channel branch for demo purposes (i hope)
<Chipaca> ijohnson: yeah, it sounds like you want a refresh, not a revert
<Chipaca> ijohnson: it's also possible it's a bug, but i think the refresh should leave x2 there
<ijohnson> basically I want to keep like 4 revisions of a snap around, going back and forth between them with reverts and refreshes without any of them being garbage colledged
<Chipaca> if that makes sense
<zyga> kjackal: you can use a branch
<zyga> kjackal: not a channel
<Chipaca> ijohnson: why not with refreshes?
<zyga> that's good for demos
<ijohnson> I do need a revert though because I'm testing that revert does the right thing too :-)
<Chipaca> ijohnson: Â¯\_(ã)_/Â¯ revert will discard things after 'current'
<kjackal> zyga: I am probably messing up the terminology edge/strict is a channel with strict being a branch, yes/no ?
<zyga> no, that's a risk level
<ijohnson> Chipaca: yes that seems to be what it does now, but do you think that's a bug or AsDesigned?
<zyga> you can create an actual branch
<zyga> like demo
<zyga> edge/demo
<zyga> or demo/edge, I don't recall
<zyga> people need to refresh to it explicitly
<Chipaca> ijohnson: i mean, https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L291
<ijohnson> zyga: demo/edge has demo as a track, while edge/demo has demo as a branch IIRC
<Chipaca> ijohnson: // discard everything after current
<Chipaca> ijohnson: it's very intentional :-)
<kjackal> I thought the channel had a <track>/<risk>/<branch> format
<zyga> you are probably right, as I said I don't recall
<zyga> my whole point is that it's a good way for actual demos
<Chipaca> kjackal: it should be fine, subject to the limitations of branches
<kjackal> yeap, thank you people
<Chipaca> i mean, they expire after a while unless you keep on pushing to them
<Chipaca> that sort of thing
<ijohnson> Chipaca: git blame says this was from mvo with commit message "review feedback" :-/
<ijohnson> alright if it is AsDesigned that's fine I guess
<ijohnson> just makes my tests more complicated
<zyga> "review feedback" is the worst
<Chipaca> ijohnson: https://github.com/snapcore/snapd/pull/1457
<mup> PR #1457:  snapstate: drop revisions after "current" on refresh <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1457>
<Chipaca> i mean, it's not good, but you grab the commit hash and look it up and you see the review feedback
<Chipaca> so it's not _the worst_ :)
<Chipaca> oh god, "retest this please"
 * Chipaca hugs spread
<Chipaca> ijohnson: what do you need the revision to still be there after revert for?
<Chipaca> ijohnson: i mean, which is the path that you're testing for?
<ijohnson> because I want to reuse the revision later in a different permutation, i.e. one test case is reverting backwards in time to that revision to make sure things work, another use case is to refresh to that revision
<ijohnson> I think if I re-order how I have the tests to do the reverts last it should be simpler, but also some of my tests could be using refresh instead of revert
<ijohnson> Chipaca: if it's helpful look at the comment at the top of https://github.com/snapcore/snapd/blob/e1d284981c5380ee9252bb77b878b44716a92829/tests/main/disabled-svcs-kept-happy/task.yaml
<Chipaca> ijohnson: you can also refresh back and then revert forwards
<ijohnson> hmmmm yes I suppose I could revert forwards couldn't I
<mup> PR snapd#7591 closed: cmd/snap-confine: remove loads of dead code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7591>
<mvo> ijohnson: uh, what did I do ? also - sorry for the terrible commit message
<ijohnson> mvo: no worries, your PR from 3 years ago just makes my PR more complicated
<mvo> ijohnson: I will read backlog after dinner hopefully
<mvo> ijohnson: sorry for that
<ijohnson> mvo: it's not important you don't need to read the backlog unless you want to
<Chipaca> mvo: after dinner it's THE WEEKEND
<ijohnson> Chipaca is right, the weekend is more important :-)
<mup> PR core-build#56 opened: writable-paths: enable create writable /etc/systemd/user <Created by mvo5> <https://github.com/snapcore/core-build/pull/56>
<mvo> Chipaca: *cough* good point
<Chipaca> ok, I'm EOW'ing
<Chipaca> have a good'un, those of you who remain! but do get out of here and do other stuff also
<mup> PR snapcraft#2750 opened: cli: clean up StoreClientCLI <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2750>
<mup> PR snapcraft#2750 closed: cli: clean up StoreClientCLI <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2750>
<mup> PR snapd#7554 closed: recovery: update fde-utils calls <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7554>
<mup> PR snapcraft#2751 opened: tests: move cli store push/upload tests to FakeStoreCommands <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2751>
#snappy 2019-10-12
<mup> PR core-build#56 closed: writable-paths: enable create writable /etc/systemd/user <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/56>
<mup> PR snapd#7592 opened: vendor: update fde-utils to latest master <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7592>
<Gargoyle> Hi snappy peeps!
<Gargoyle> I've got an issue with apparmor - not directly related to snaps, but I wonder if some of you are familiar enough to help.
<Gargoyle> The /etc/apparmor.d/abstractions/mysql is listed as being in the main apparmor package (https://packages.ubuntu.com/eoan/amd64/apparmor/filelist) but it's missing on my system and re-installing apparmor is not putting it into place.
<Gargoyle> I could manually copy it from unpacking the .deb - but I'd like to figure out why apparmor is not installing it
<cjwatson> Gargoyle: you'll need to pass the --force-confmiss option to dpkg
<cjwatson> Gargoyle: by default it considers removing a conffile (the subcategory of configuration files that are done by shipping them directly in .debs and having dpkg manage them) to be a sysadmin choice that should be respected unless told otherwise
<Gargoyle> ahh. I see.
<Gargoyle> So somewhere along the way I made the choice to remove that file (even if I didn't mean to) and apt/dpkg is respecting that "choice"?
<cjwatson> Sounds like it
<Gargoyle> So "dpkg -i temp/apparmor_2.13.3-5ubuntu1_amd64.deb --force-confmiss" would be the fix (I have downloaded the .dep using "apt download apparmor")
<mup> PR snapd#7592 closed: vendor: update fde-utils to latest master <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7592>
#snappy 2019-10-13
<alkisg> Hello! I'm developing the new LTSP version, which is "netbooted systems: squashfs over nfs/tmpfs/overlayfs".
<alkisg> The problem is that snaps fail to run with: cannot create lock directory /run/snapd/lock: Permission denied
<alkisg> journalctl shows some DENIED messages about snap-confine, and I'm thinking maybe it fails to properly detect the overlayfs root
<alkisg> Logs: http://termbin.com/fdy9 - any hints?
<mup> PR snapd#7593 opened: recovery-tool: add sfdisk wrapper <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7593>
