#snappy 2015-08-31
<dholbach> good morning
<fgimenez> good morning
<emilebosch> mornign sir :D
<fgimenez> hey emilebosch :)
<ogra_> mvo, mind taking a look at bug 1490115 ? i wonder if i'm on the wrong path having steve so strongly opposing
<ubottu> bug 1490115 in initramfs-tools-ubuntu-core (Ubuntu) "build a fully generic initrd.img without modules" [Undecided,New] https://launchpad.net/bugs/1490115
<zyga> ogra_: good morning, I tried a random wifi adapter I had with rpi2, it didn't work because of missing firmware. The same adapter obviously works on regular ubuntu. What is the selection criteria for the firmware we ship?
<zyga> ogra_: NB: the driver is present, just the firmware is not
<ogra_> zyga, hmm, not sure, i thought we ship all of linux-firmware in the device tarball
<ogra_> oh, wait ... we probably dont in the rpi one
<zyga> ogra_: :D
<ogra_> do you have an example filename of one firmware file ?
<zyga> ogra_: nice
<zyga> ogra_: I don't remember (I was using it locally yesterday, let me refresh my memory
<zyga> ogra_: and side question, is there a way to force snapy to update core snap when it is sideloaded
<ogra_> sudo snappy update ubuntu-core ?
<zyga> it say "no no, sideloaded, go away" in nicer way
<ogra_> (you can not really sideload it, can you ? )
<zyga> ogra_: I built the image with the same shell command you gave me
<zyga> ogra_: and that's what I got
<mvo> ogra_: sure, I have a look. debuging initramfs stuff right now, not exactly fun
<zyga> ogra_: (and don't ask me how I copied it to an sd card when all the readers I could find were not working)
<zyga> ogra_: netcat to a beagle bone black booted from emmc
<ogra_> ouch
<zyga> ogra_: the driver is r8188eu
<zyga> ogra_: I can give you the exact message I get on rpi2 but I need to get loads of coffee first
<zyga> ogra_: and I was on 149 and AFAIR we're at 152 now
<zyga> on rolling
<ogra_> zyga, heh https://bugs.launchpad.net/raspbian/+bug/1424469
<ubottu> Launchpad bug 1424469 in Raspbian "firmware-realtek is missing rtl8188eufw.bin" [Undecided,New]
<ogra_> not only ubuntu :)
<zyga> ogra_: oh, fun :)
<zyga> ogra_: thanks
<ogra_> zyga, can you file a snappy bug pointing out that we need to ship the content of linux-firmware in the device tarball ?
<ogra_> (and assign it to me for fixing it in 15.04.3)
<zyga> ogra_: on lp:snappy?
<ogra_> yeah
<zyga> ogra_: yep
<zyga> ogra_: thanks a lot
<ogra_> we dont have the kernel in the archive yet
<ogra_> (else you coudl file it against that)
<zyga> ogra_: I cannot assign it to you https://bugs.launchpad.net/snappy/+bug/1490436
<ubottu> Launchpad bug 1490436 in Snappy "Ship contents of linux-firmware in the device tarball for rpi2" [Undecided,New]
<zyga> ogra_: even though I can, looking for "ogra" returns nothing in that assignment pop-up
<zyga> ogra_: weird
<ogra_> done
<mvo> ogra_: so I looked at the bugreport and wonder if we simply can build our own initramfs thats radically different from the distro one?
<ogra_> mvo, we already do
<ogra_> by using initramfs-tools-ubuntu-core ...
<ogra_> you wont boot snappy without the scripts from there
<ogra_> shipping MODULES=none in a conf.d file from that packge would be enough to not have any modules inside
<ogra_> but what i also want it a similar setup to the one we use on the phone where we build the initrd binary in a package ... so that you can just pull the package and grab initrd.img from /usr/lib
<mvo> ogra_: aha, ok. I wasn't aware of the phone idea
<ogra_> i outlibed that in my last comment
<ogra_> *outlined
<mvo> ogra_: looks like I was not reading this part carefully enough then :P I know quite a bit now about the ubuntu-core-roofs now (more than I want!). I managed to make it boot though with the new kenrel/os decoupling, still a lot of ugly stuff left that I need to fix first
<mvo> before it can go in
<ogra_> generally we should just start with MODULES=none ... but i also want to get the initrd generation out of the rootfs build process
<mvo> ogra_: yes, agreed. the new kernel snap should give us some interessting options here
 * ogra_ poinnts to bug 1490107 for the last statement
<ubottu> bug 1490107 in livecd-rootfs (Ubuntu) "rootfs contains all initramfs dependencies and tools" [Undecided,New] https://launchpad.net/bugs/1490107
<ogra_> having a binary initrd ready made in a .deb would save us from a lot of hackery to fix this bug :)
<mvo> ogra_: i.e. we will need something that takes a kernel and makes a snap out of it. that might be a good sstarting point to rethink how we crate the initramfs, we could build it as part of this convertion
<ogra_> i wouldnt do it dynamic at all
<mvo> ogra_: silly question, so the phone already is using a deb to create the initird?
<ogra_> yes
<mvo> could we simply re-use this for us too? or are you concerned about duplication?
<ogra_> its a rather ugly buuld process since we do it on a package builder ... so it need sto jump through some fakeroot/fakechroot setup
<ogra_> *needs to
<ogra_> yes, we could re-use it
<ogra_> right away with a few filename and dependency changes in teh package i think
<mvo> ogra_: hm, ok. ugly sounds â¦ ugly
<mvo> :/
<ogra_> yeah, the curse of package buildds :)
<ogra_> the package is ubuntu-touch-generic-initrd if you want to take a look
 * mvo looks
<ogra_> hmm, LP doesnt seems to like this package ... weird
<mvo> ogra_: hm, not that ugly, I mean, when you described I expected it to be much worse
<ogra_> well, ugly enough, but the best way to build it atm
 * mvo nods
<dholbach> is https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 still required?
<pindonga> hi all... I've been making some progress with my snap package, however I'm now having issues with the service not starting properly. When I run systemctl start the logs say the service is starting but nothing happens ; however when I manually execute the command specified in the systemd unit file (including env vars etc) the daemon starts correctly and stays up
<pindonga> I don't see anything in the logs
<pindonga> any ideas how i can debug and find out what's going on?
<ogra_> hmm if ubuntu-core-launcher has issues running it it usually writes to syslog ... weird that you dont see anything
<pindonga> ogra_, the weird thing is that I run the ubuntu-core-launcher cmd manually from the shell and it works fine
<ogra_> no apparmo denials or seccomp blocks in the log ?
<pindonga> no, I've set the snap to unconfined for now to avoid anything related to lock down perms
<ogra_> ah
 * ogra_ isnt sure the unconfined profile applies to seccomp actually
<pindonga> ogra_, still nothing in syslog about seccomp though
<ogra_> did you check with sc-logresolve ?
<pindonga> no, but I just run it and nothing is returned
<pindonga> ogra_, this is what I see when I install the snap: http://paste.ubuntu.com/12237761/
<pindonga> after that I run ps and nothing shows up
<pindonga> ie, the process I'm looking for is not running
<mvo> pindonga: is this 15.04 or rolling? if rolling we have a nice snappy service status command that hopefully helps debugging
<pindonga> mvo, it's the raspi2 img, which I think is 15.04
<pindonga> mvo, should I switch to rolling? how?
<mvo> pindonga: its fine, journalctl will also give you all the info hopefully
<pindonga> mvo, journalct -xe doesn't show anything usefu
<pindonga> just says Unit ... has begun starting up
<mvo> pindonga: you need to figure the system unit name by looking into /etc/systemd/system and systemctl status $servicename
<mvo> pindonga: hm, what does systemctl status give you? if it stops or dies it should be visible there
<pindonga> http://paste.ubuntu.com/12237805/
<pindonga> but ps shows the process is not running
<ogra_> GRRR ... so parted on armhf calls the partition table "msdos" while parted on amd64 calls the partition table "mbr" on the same device
<ogra_> yay, standards
<ogra_> :P
<mvo> pindonga: hm, what does "systemctl start p910nd_p910nd_0.97" print?
<pindonga> nothing
<mvo> pindonga: and systemctl status p910nd_p910nd_0.97 after the start? still nothing?
<pindonga> mvo, the same as before
<pindonga> active: Inactive (dead)
<pindonga> + the log about starting the deamon
 * mvo scratches head
<pindonga> mvo, if I run the cmd as specified in the systemd unit file the process stays up
<pindonga> ie, SNAP_APP=... TMPDIR=... ... /usr/bin/ubuntu-core-launcher p910nd.sideload p910nd.sideload_p910nd_0.97 /apps/p910nd.sideload/0.97/p910nd
<pindonga> so this is something related to systemd afaict
<mvo> pindonga: and journalctl p910nd_p910nd_0.97 has nothing to add I presume?
<mvo> pindonga: would you mind pushing your snap somewhere? chinstrap or peple.cc or something, then I can have a look maybe
<pindonga> mvo, the only thing that shows up in journalctl is
<pindonga> Aug 31 12:18:37 localhost.localdomain systemd[1]: Started p910nd - simple printer daemon.
<pindonga> Aug 31 12:18:37 localhost.localdomain systemd[1]: Starting p910nd - simple printer daemon...
<pindonga> mvo, sure
<mvo> pindonga: hrm, it really should at least print a exit-status if it started it in vain
<pindonga> mvo, chinstrap.canonical.com:~ricardo/p910nd_0.97_multi.snap
<rsalveti> fgimenez: welcome back :-)
<fgimenez> hey rsalveti, thanks! still trying to catch up.. :)
<rsalveti> yeah :-)
<sergiusens> ogra_: that's strange, u-d-f used to create them both with 'msdos' before moving to gpt
<sergiusens> mvo: pindonga just in case 'sudo journalctl -u p910nd_p910nd_0.97.service'
<ogra_> sergiusens, well, thats a USB kesy carrying my writable part, it was created with the "disks" tool from the desktop ... it is just weird that parted on different arches seems to output different things
<ogra_> (not hard to fix but still weird)
<pindonga> sergiusens, doesn't add any new data
<pindonga> :/
<mvo> pindonga: looks like "type=forking" is needed, is there a way to start it in no-fork mode maybe?
<pindonga> mvo yes
<pindonga> if you run it with -d
<pindonga> (contrary to what you'd expect :/)
<mvo> pindonga: please try to add that to the systemd file and that should work then
<pindonga> although it also prints out debugging info
<pindonga> mvo, is this something that would be otherwise fixed via seccomp perms?
<mvo> thats a strict systemd thing
<pindonga> mvo, ok, running with -d doesn't really work, bc it exists right away
<pindonga> mvo, but adding Type=forking to the unit file does
<pindonga> mvo, does this mean I need to provide my own unit file in the snap?
<pindonga> or can I tell snappy to create it using Type=forking somehow?
<mvo> pindonga: hm, looks like we need to add a option for snappy then so that you can have type=forking.
<pindonga> mvo, until then, can I ship my own unit file with the snap somehow?
<pindonga> mvo, shall I file a bug for this? where?
<sergiusens> mvo: btw, would be nice to get your opinion on https://code.launchpad.net/~sergiusens/snapcraft/less-source/+merge/269547
<pindonga> sergiusens, q about snapcraft... how can I tell snapcraft to crosscompile my snap for armhf ?
<ogra_> you cant yet
<pindonga> so I still need to manually build my snaps for arm?
<ogra_> (planned feature indeed)
<ogra_> you need to run your snapcraft on arm or in an armhf chroot
<pindonga> ah, k
<pindonga> any ETA for that one? it means you can't use snapcraft (yet) to build multi-arch snaps iiuic
<pindonga> (asking just to know, no pressure :))
<ogra_> no, sorry, no idea
<pindonga> no worries
<mvo> pindonga: we don't support raw unit files right now, but we should and you are the use-case now :) https://bugs.launchpad.net/snappy
<pindonga> mvo, I'll file the bug
<pindonga> thx
<mvo> sergiusens: on the phone right now, but I have a look
<pindonga> mvo, https://bugs.launchpad.net/snappy/+bug/1490574
<ubottu> Launchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Undecided,New]
<mvo> thanks pindonga
<dholbach> not sure if folks saw the message earlier, but is https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 still required?
<dholbach> or can it just be rejected?
<dholbach> can somebody take a look at https://code.launchpad.net/~dholbach/snapcraft/start-0.2/+merge/268321 as well?
<zyga> sergiusens: 'da icons'
<zyga> sergiusens: I should introduce you to git-lp ;)
<sergiusens> zyga: no, I don't want to create an engineering process that only I would use ;-)
<sergiusens> zyga: still waiting for lp integration for git, then it will all be over...
<zyga> sergiusens: what are you missing?
<sergiusens> zyga: the API to query MPs for git to be exposed
<zyga> sergiusens: it's there
<zyga> sergiusens: we're using it for a few months daily
<zyga> sergiusens: I wrote a few tools that talk to it
<zyga> sergiusens: (also in daily use)
<sergiusens> zyga: really? Then I'm just waiting on elopio :-)
<zyga> sergiusens: heh, ok, if you want I can tell you some more about it
<zyga> sergiusens: the UI is a bit iffy but it's all there
<sergiusens> zyga: and python3-launchpadlib works ootb?
<zyga> sergiusens: yes
<zyga> sergiusens: I fixed the only two issues that I found a few months ago
<zyga> sergiusens: I have a PPA with backports for 14.04+
<zyga> sergiusens: ^_^
<zyga> sergiusens: I'm really pushing an agenda here
<zyga> sergiusens: but I'm willing to get stuff done to make it happen
<ogra_> ricmm, rsalveti, new resize code uploaded to wily ...
<ogra_> (so we can test it in rolling/edge first)
<rsalveti> ogra_: cool
<rsalveti> ricmm seems to be off today, but yeah
<ogra_> super ugly :(
<rsalveti> we can use it for further testing
<rsalveti> yeah, let's hope it works
<ogra_> i tested the hell out of it for the last three days
<ogra_> it works, but still ... ugly ...
<rsalveti> right
<ogra_> parted doesnt allow non-interactive fixing of the GPT
<ogra_> so the only option was to re-create it based on the original data
<sergiusens> elopio: https://code.launchpad.net/~sergiusens/snapcraft/source-tests/+merge/269649
<zyga> sergiusens: quick quiestion, I'm working on env changes
<zyga> sergiusens: I have some prerequisites
<zyga> sergiusens: I'd like to change run() not to expand shell globs
<zyga> sergiusens: and be quote-safe
<zyga> sergiusens: (and the question is a ack/nack on the concept)
<fgimenez> elopio, before i forget, i proposed a mp for the ssh timeout thing https://code.launchpad.net/~fgimenez/snappy/extended-ssh-timeout/+merge/269631 wip until autopkgtest lands
<elopio> cool.
<zyga> sergiusens: offtopic: ...........Warning: unable to find "test_relexepath" in the path
<elopio> plars: we need to collect the serial console output from the board.
<elopio> is that hard?
<sergiusens> zyga: yeah, I haven't looked into fixing that, as well as the rogue cp's printed while running the tests
<plars> elopio: yes, there's nothing even connected to the serial console
<zyga> sergiusens: ok
<plars> elopio: can't you just grab syslog at the end of your run?
<zyga> sergiusens: I think I have a working strategy for env transition
<zyga> sergiusens: I'll show you the code in a sec
<sergiusens> zyga: and wrt env changes, just propose something if it is not much work to get the discussion moving forward
<elopio> plars: the problem is with the reboots. The ssh is killed, and if it fails to reboot we won't know what happened.
<zyga> sergiusens: yep
<plars> elopio: it will likely take some effort given the nature of these boards, and the fact that I don't think we have any kind of serial console server in the lab
<zyga> I'm trying not to break everything while cleaning it up
<zyga> that's where all the hard parts are
<plars> elopio: would likely take some custom connectors as well
<elopio> plars: where should I file feature requests for you?
<plars> elopio: do something for me please: send an email to me, chris, and ara about the problem, I'll make sure we get a story created for it, but that way they are aware
<plars> elopio: is reboot failing right now? and isn't reproducing outside of the automation a better option for debugging when things go wrong anyway?
<ogra_> mvo, bug 1490608 (probably cjwatson is interested)
<ubottu> bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608
<zyga> down to only one failing test
<elopio> plars: chris who?
<plars> elopio: wayne
<elopio> plars: we have some bugs in failover reboot, yes.
<fgimenez> elopio, for the cloud instances nova console-log INSTANCE_ID
<elopio> and we can reproduce outside. But if it fails in the lab, without the log we won't know if it was a known bug or something knew.
<elopio> fgimenez: :o thanks!
<fgimenez> nice evening everyone o/
<kyrofa> sergiusens, ping
<kyrofa> sergiusens, unping
<sergiusens> kyrofa: do you expect me to operate in fifo or lifo?
<sergiusens> :-)
<kyrofa> sergiusens, :P
<kyrofa> sergiusens, does ubuntu-core-launcher come from the ubuntu-core snap?
<sergiusens> kyrofa: it comes from the 'ubuntu-core' snap alright (even if it isn't a snap today ;-) )
<kyrofa> sergiusens, is it a .deb?
<sergiusens> kyrofa: https://launchpad.net/ubuntu-core-launcher/trunk
<sergiusens> kyrofa: yes
<kyrofa> sergiusens, that's what I was looking for! Thank you :)
<sergiusens> np
<Seshu> @rsalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage'
<nothal> Seshu: No such command!
<Seshu> nothal: What?
<Seshu> rsalveti: I added my local project to snapcraft.yaml and did 'snapcraft stage', it stops saying "no rule to make install"
<Seshu> rsalveti: do I have to add install rules into my makefile?
<Seshu> rsalveti: I already get the .deb files from my treditional build...how do I do snapcraft?
<ted> Seshu, This might be helpful: https://developer.ubuntu.com/en/snappy/snapcraft/
<ted> Seshu, Not as much the rules, as a definition on how to pull together your package.
<Seshu> Thanks ted. I'm following the link and the examples.
<Seshu> My build system bundles into .deb packages. I'm trying to see if I can start snapcraft from using the .deb files already built on my local build system...
<Seshu> The closest example I found is wget...I see it pulls the deb package into stage/build directory and continues to create snap...I'm trying to if that pull step could be a copy .deb from my local build directory and continue.
<ted> Seshu, It's not that flexible right now, as it can only pull from the version of the archive on your current machine.
<ted> Seshu, We do want to make it more flexible, but the deb stuff needs to grow some.
<ted> Seshu, You might be more effective using one of the autotools/cmake/python-project/etc. types to build your package.
<Seshu> ok ted.
<Seshu> What do I do if I get "parts libcurl3 and libnm-glib4 have the following files in common:" on snapcraft with plugin: ubuntu
<ted> Seshu, I think you'll probably have one instance if the ubuntu plugin, with all the packages listed for it. That way it can share dependencies.
<Seshu> Hi ted. how to I specifiy package list?
<Seshu>     libmosquittopp1:         plugin: ubuntu     libcairo2:         plugin: ubuntu     libnm-glib4:         plugin: ubuntu     libjsoncpp0:         plugin: ubuntu     libcurl3:         plugin: ubuntu
<Seshu> This is how I'm having now...
<Seshu> I tried giving     libmosquittopp1:    libcairo2:        libnm-glib4:     libjsoncpp0:      libcurl3:         plugin: ubuntu
<Seshu> It throws error
<ted> Seshu: deps:\n\tplugin: ubuntu\n\tpackages: [libmosquittopp1, libcairo2]
<Seshu> Oh! okay.
<Seshu> Let me try that...
<Seshu> Perfect! that resolved... :)
<Seshu> Thanks much!
#snappy 2015-09-01
<dholbach> good morning
<mvo> elopio: hi, if you are still up, I wonder if I should top-approve sergios branches for snapcraft or if he prefers to do that himself
<mvo> hey dholbach, good morning
<dholbach> thanks mvo
<fgimenez> good morning
<zyga> good morning
<Chipaca> goood morning!
<ogra_> mvo, do we want to wait til there is any feedback on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791661 for the SRU of bug 1323732 ? seems a user has issues creating users in 15.04 (on the ML)
<ubottu> Debian bug 791661 in shadow "support for alternative passwd location (i.e. libnss-extrausers)" [Wishlist,Open]
<ubottu> bug 1323732 in adduser (Ubuntu Vivid) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [Undecided,New] https://launchpad.net/bugs/1323732
<ogra_> or should we perhaps just push it to the PPA
<mvo> ogra_: this is in wily, no?
<mvo> ogra_: aha, you mean for 15.04? yeah, going the ppa route is fine here I think
<Chipaca> mvo: o/
<Chipaca> mvo: so, comapreDirs
<mvo> hey Chipaca
<Chipaca> mvo: compares the output of ls
<mvo> Chipaca: no, compardirs is terrible
<Chipaca> mvo: that's a huge red flag
<Chipaca> but
<Chipaca> BUT
<mvo> Chipaca: I was wondering about https://code.launchpad.net/~mvo/snappy/snappy-lp1468831-race/+merge/269155
<Chipaca> because it's a controlled test scenario
<Chipaca> it wouldn't be too terrible
<Chipaca> however
<Chipaca> it's comparing the ctimes, which we don't care about
<Chipaca> isntead of the mtimes or the atimes which we apparently do care about
<mvo> oh, sorry, I get it now, its connected
<Chipaca> also it
 * mvo shuts up and listens
 * Chipaca derails
<Chipaca> i was going to say "also it compares the time format instead of asking ls to use something smarter", but i'm not sure that would be a win
<Chipaca> I mean, you can tell ls to --time-style=+%s for example
 * mvo nods
<Chipaca> but if we're just comparing for equality that's fine
<Chipaca> and, given the comment about atime/mtime in RSyncWithDelete, I think we *do* care about equality
<Chipaca> so that means the test is wrong, and the fix is hiding it instead of fixing it :)
<Chipaca> so
<Chipaca> rant mode off
<Chipaca> fix mode on
<Chipaca> i guess what we want is to have ls print the atime and the mtime, if those are truly what we care about
<mvo> yeah, absolutely agreed, I will reject the branch
<Chipaca> hm, ls can't print both atime and mtime at the same time
<elopio> fgimenez: ping. I made some good progress on the subunit repo. Can you please check the pull requests? https://github.com/elopio/subunit/pulls
<elopio> I couldn't find how to do something like prerequisits in git, so if you don't start from the older it might be a mess.
<fgimenez> elopio, ok np i'll take a look
<Chipaca> mvo: default for ls is mtime (i thought it was ctime, for some reason), so we're not preserving it in RSyncWithDelete?
<mvo> Chipaca: hm, its using cp -a
<Chipaca> mvo: but for single files
<Chipaca> mvo: directories it's making itself
 * Chipaca wonders why that isn't a single cp call
<Chipaca> ah, because of the filesareequal check
<Chipaca> so
<Chipaca> i know how to unbreak the test, now :)
<mvo> yeah, the dirs are indeed missing
<mvo> yay, thanks Chipaca
<mvo> and sorry for the trouble :/
<Chipaca> hah. no worries.
<Chipaca> sorry for the rant
<mvo> all good, terrible code there
<Chipaca> yuss
<Chipaca> mvo: how does http://pastebin.ubuntu.com/12244247/ look?
<mvo> Chipaca: much nicer
<Chipaca> mvo: OTOH i could move that to CopyFile
<Chipaca> mvo: and just use CopyFile here
<Chipaca> but maybe make it different branches
 * Chipaca agrees with himself already
<mvo> heh
<mvo> cleanup++
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/fix-1468831/+merge/269728 would be that then
<mvo> \o/
<Chipaca> mvo: not top-approving because integration tests
<Chipaca> oooh, mp failed?
<mvo> helpers/helpers.go:503: impossible type assertion:
<mvo>  *syscall.Stat_t does not implement os.FileInfo (missing IsDir method)
<mvo> looks like it
<Chipaca> dah
<Chipaca> mvo: forgot .Sys() :(
<Chipaca> mvo: fixed
<Chipaca> mvo: in https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 you say elopio's comment is addressed, but .. you forgot to push it?
<mvo> Chipaca: indeed, sorry again
 * Chipaca takes a break
<sergiusens> mvo: thanks for the reviews!
<ogra_> sergiusens, wrt bug 1490741 ... shouldnt u-d-f bail out when using a RPi2 snap with a generic tarball ?
<ubottu> bug 1490741 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash creates an rpi2 image that won't boot" [Undecided,New] https://launchpad.net/bugs/1490741
<ogra_> or did i do something rong with the meta data in the pi2 snap ?
<ogra_> *wrong
<sergiusens> ogra_: it shouldn't fail, no; it will use the one from s-i
<ogra_> thats bad
<sergiusens> ogra_: that is the catch to --developer-mode, no hand holding
<sergiusens> ogra_: yeah, you need to put this upstream ;-)
<ogra_> ah
<ogra_> yeah, i think we need a mechanism to define what device tarballs an oem snap can be used with
<sergiusens> ogra_: how would you start enabling a board if not?
<sergiusens> ogra_: well, with what mvo is doing right now and with what I did here http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/ that is no longer going to be necessary
<ogra_> oh, it should all be open while developing ... but package.yaml should have an optional enttry that can bind us to a certain device tarball
<sergiusens> ogra_: but the device tarbal is just a tar
<ogra_> currently :)
<sergiusens> ogra_: when it becomes a snap, I hope the gadget would define it
<ogra_> yeah
<sergiusens> ogra_: since it would be pulled from the store, so it needs the name
 * ogra_ turns the u-d-f task on the bug invalid but keeps the snappy one open then
 * Chipaca is trying to figure out https://code.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/+merge/269717
 * ogra_ twiddles thumbs waiting for shadow to be published in the PPA
<fgimenez> Chipaca, yes, it's a bit involved :)
<fgimenez> Chipaca, in build_test we used var definitions for testing the dependency calls
<Chipaca> mhmm
<Chipaca> fgimenez: but here's the thing
<Chipaca> fgimenez: a var is not a closure
<Chipaca> there's nothing to "refresh"
<fgimenez> Chipaca, well, maybe the wording is not correct, we first define the var here http://bazaar.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/view/head:/_integration-tests/testutils/build/build.go#L46
<fgimenez> Chipaca, when we call this afterwards, it doesn't take the value of the environment variables if we don't redefine it
<fgimenez> Chipaca, this used to work before 1.5
<Chipaca> hmm
<Chipaca> fgimenez: and you get the same error every time without this change?
<fgimenez> Chipaca, yep
<Chipaca> fgimenez: and if you do "export GOMAXPROCS=1" before running the test?
<fgimenez> Chipaca, let me try..
<Chipaca> fgimenez: because what changed was that in 1.5 GOMAXPROCS defaults to the number of cores; before it was 1
<Chipaca> fgimenez: and getenv is per-process
 * Chipaca writes a small testcase to check this just in case
<fgimenez> Chipaca, ah! ok, shouldn't GOARCH be the same for all of them?
<fgimenez> Chipaca, i'm getting this http://paste.ubuntu.com/12244578/ after removing the var redefinition line
<Chipaca> fgimenez: i'll dig into it in a bit
<fgimenez> Chipaca, ok thanks! :)
<Chipaca> oooooh
<Chipaca> fgimenez: shouldn't osGetenv return something?
<Chipaca> i mean
<Chipaca> fgimenez: in the tests
<Chipaca> fgimenez: you're rewriting osGetenv
<Chipaca> fgimenez: with fakeOsGetenv
<Chipaca> fgimenez: that does not return anything
<Chipaca> i.e. it always returns an empty string
<Chipaca> fgimenez: may i suggest you keep an environ map[string]string in the test, and set things in it from fakeSetenv, and return things from it in fakeGetenv?
<fgimenez> Chipaca, yes that makes a lot of sense, let me take a look
<Chipaca> actually making it a map[string]struct{string, int, int} would be the way I'd do it, actually
<Chipaca> fgimenez: i'll show you what i mean in a diff, give me a few
<Chipaca> fgimenez: something like http://pastebin.ubuntu.com/12244793/ might work, but it would involve changing a number of tests appropriately
<Chipaca> fgimenez: advantage of this is you have a single place where you track reads, writes and current value of the environment
<Chipaca> fgimenez: disadvantage might be that it's a bigger change from where the code is right now
<Chipaca> fgimenez: whereas the simpler change would be http://pastebin.ubuntu.com/12244813/
<Chipaca> fgimenez: i feel it'll make things harder to follow in the long term, but not particularly strongly :)
<Chipaca> fgimenez: also note you would have spotted this error earlier if you didn't use the "bare return" thing as much as you do
<fgimenez> Chipaca, yep :) thanks for that, i was thinking in the latter option that you proposed, i'll put hands on it
<Chipaca> fgimenez: in both cases note i haven't tested the code :)
<fgimenez> Chipaca, np :)
 * Chipaca is now on lunch break
<Chipaca> pitti: i have the silliest systemd question, and sadly for you your name is soldered to systemd in my mind
<pitti> hey Chipaca -- heh :)
<pitti> Chipaca: you could ask anyone in the vast systemd maintenance team in Ubuntu!
<Chipaca> pitti: if I do, e.g.,: sudo journalctl -u urfkill -o json-pretty
<Chipaca> pitti: it returns a series of lines, with a json document per line
<Chipaca> um
<Chipaca> json, not json-pretty
<Chipaca> :)
<Chipaca> pitti: json-pretty to read it, json to parse it :)
<Chipaca> pitti: anyway. you get that, a series of json objects
<pitti> right
<pitti> looking at it here, for systemd-udevd, as i don't have urfkill
<Chipaca> pitti: in the first one, the systemd unit is in the "UNIT" key
<Chipaca> pitti: in the following ones, it's in "_SYSTEMD_UNIT"
<Chipaca> pitti: this feels like a bug
<Chipaca> pitti: but I don't know
<pitti> Chipaca: it for sure is
<Chipaca> *gasp*
<pitti> I mean, I don't see how this would be deliberate
<Chipaca> well, it's certainly not what's documented :)
 * Chipaca updates his system just in case
<pitti> Chipaca: it's the same with -o verbose or export, i. e. not just a presentation problem; I guess it's actually wrong in the db
<pitti> yep, should always be _SYSTEMD_UNIT as per systemd.journal-fields(7)
<Chipaca> pitti: i wonder whether it's different on purpose, so you get the unit the first time and don't bother if it's not there because it's the same?
<Chipaca> that sounds contrieved though
<Chipaca> and aggregates poorly
<pitti> yeah
<pitti> Chipaca: do you mind filing it at https://github.com/systemd/systemd/issues or should I proxy it for you?
<Chipaca> pitti: i wouldn't mind filing it
<pitti> Chipaca: cool, thanks; if this is blocking you I'll see to fix it this week, but I suppose it's easy enough to work around for now?
<Chipaca> it is
<Chipaca> pitti: it's also only the first one for any service, for you?
<pitti> Chipaca: yes, consistently (tried 3)
<pitti> Chipaca: in a fresh VM I see two UNIT=, though
<pitti> but either way, this is inconsistent and undocumented
<Chipaca> pitti: I'll file the bug, you add that to it :)
<pitti> ack
<Chipaca> pitti: https://github.com/systemd/systemd/issues/1106
<pitti> Chipaca: thanks, I'll watch what upstream says and if appropriate look into it
<Chipaca> pitti: ta
<Chipaca> pitti: there you go then
<pitti> Chipaca: ah! so this is "message from pid 1 about unit foo" vs. "message from unit foo"
<Chipaca> pitti: yep, so it might be a bug in documentation as opposed to implementation
<Chipaca> as the docs don't mention UNIT nor any other mysterious "couple of other keys"
<pitti> Chipaca: yeah, I just followed up wrt. that
<Chipaca> heh. jinks.
<Chipaca> jinx*
<Chipaca> anyway, you know what time it is?
<Chipaca> time for a cuppa tea
<pitti> and again
<pitti> Chipaca: good idea!
<pitti> Chipaca: I was about to yell "Tool time!" :)
<rickspencer3> is there a bug # for snappy-remote install doesn't work with webdm?
<Chipaca> pitti: do you know what they mean wrt trusted/untrusted fields?
<pitti> "Fields prefixed with an underscore are trusted fields, i.e. fields that are
<pitti>        implicitly added by the journal and cannot be altered by client code."
<Chipaca> pitti: where's that?
<pitti> Chipaca: in man systemd.journal-fields
<Chipaca> pitti: gotcha
<ted> sergiusens, Do you have a snapcraft branch where you're removing the ubuntu plugin?
<pitti> Chipaca: so, a client using libsystemd journal_* can set arbitrary fields, but not those prefixed with _
<Chipaca> pitti: k :)
<sergiusens> ted: not pushed yet
<sergiusens> ted: still in the works (writing tests)
<ted> sergiusens, Can you push so I can base off of that?
<Chipaca> rickspencer3: how does it not work?
<Chipaca> rickspencer3: http://pastebin.ubuntu.com/12246078/
<rickspencer3> Chipaca, the last time I tried it, it didn't work, and I was told that it was a bug
<rickspencer3> oh
<Chipaca> rickspencer3: ah, maybe sergiusens knows more then
<rickspencer3> Chipaca, I did $snappy-remote install --url=ssh://webdm.local or something
<rickspencer3> Chipaca, oh
<rickspencer3> no, you are installing webdm
<rickspencer3> I meant installing a different snap using webdm
<rickspencer3> instead of the ip address
<ogra_> you mean using avahi ;)
<ogra_> (webdm.local is an avahi address, perhaps the go implementation that the webdm package ships has issues)
<Chipaca> I think it's snappy-remote doing something smart with --url that does not include avahi
<Chipaca> it also does not hand it straight off to ssh, which means you can't use fake ssh hostnames
<ogra_> also note that you can only have the same avahi address once in your network ... i.e. if you have a BBB on the same network running another webdm instance that calls for issues
<Chipaca> *also* also note I don't think avahi will work to kvm
<Chipaca> mvo: wrt bug 1491011, if your snappy doesn't have a service, you don't have the fix. If it does have service, and you're seeing this, then caca.
<ubottu> bug 1491011 in Snappy "[webdm] fails to start webdm on rpi2 if no network is attached" [Undecided,New] https://launchpad.net/bugs/1491011
<mvo> Chipaca: uh, I'm not sure I understand, thats webdm, it has a service
<Chipaca> mvo: yes
<Chipaca> mvo: what does "snappy service status webdm" print
 * Chipaca forgot the 'status' verb
<ogra_> i think i said before that i dont think it is wrong if webdm doesnt start when no network is available
<mvo> Chipaca: its on 15.04, do we have snappy service there already?
<ogra_> what *is* important though is that it starts as soon as you connect network
<Chipaca> mvo: then you don't have the network brouhaha fix :)
<mvo> Chipaca: aha!
<mvo> Chipaca: now I understand
<Chipaca> mvo: it's not backported, and landed in wily together with "service", hence that question
<mvo> Chipaca: cool, do you happen to remember the bugnumber?
<mvo> Chipaca: I can have a look in a bit then
<Chipaca> bug 1466672
<ubottu> bug 1466672 in Snappy 15.04 "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672
 * Chipaca hugs --fixes
<Chipaca> mvo: ^
<mvo> ta
<mvo> I will do a backport in a bit
<ogra_> zyga, you had issues wirth missing firmware IIRC ... there is a http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz that contains all of linux-firmware now
<ogra_> (in case you feel like trying it)
<Chipaca> zomg, next week school starts again
<elopio> fgimenez: I'm not sure how to make an anonymous struct inside a for.
<elopio> that sounds scary too.
<elopio> fgimenez: I was copying the style from here: https://github.com/golang/go/wiki/TableDrivenTests
<fgimenez> elopio, yes :) it's just to replace the flagtest var definition in that example with the struct itself, readability could suffer though
<fgimenez> elopio, i've seen an example here http://talks.golang.org/2015/tricks.slide?utm_source=golangweekly&utm_medium=email#12
<tedg> sergiuse1s: Not sure if it got lost in the various disconnects, can you push your branch so I can build on it?
<elopio> fgimenez: yes, -1 for that. Maybe I'm too used to testscenarios.
<tedg> sergiuse1s: Should be fine without tests for what I need.
<elopio> what I think we should do is to add scenarios to go check.
<fgimenez> elopio, that would be great
<zyga> ogra_: thanks a lot, I'll check it out
<ogra_> thanks
<sergiuse1s> tedg: oh, I don't think I can share just yet, still not glued in
<tedg> sergiuse1s: Hmm, okay. The problem I'm running into is needed a global package library. Putting things in python-project causes them to conflict with python the base one.
<sergiuse1s> tedg: I think I understand, going to start the drive back home, we can continue then
<tedg> sergiuse1s: K
<tedg> barry: Reading through the pip docs and learning about wheels. Do you think we need to support those in Snapcraft?
<tedg> Not sure how often they're used, or if everyone just uses the source versions.
<barry> tedg: yes, i think so.  the python ecosystem is definitely transitioning to wheels, although for python modules which include extension modules (e.g. sharedlibs), it's problematic on linux.  there's ongoing discussions about how that will work.  pure python, np
<tedg> barry: Okay. But as I'm reading more that seems separate from pip though, right? Pip can just build wheels?
<fgimenez> nice evening everyone o/
<barry> tedg: yes.  pip will build wheels, although our debuntu version of pip is in serious need of an update (it's on my todo)
<tedg> barry: Is there any reason I'd want to have pip build wheels and install from those? Seems like a no-op for our purposes.
<ogra_> mvo, hmm, did i hand you https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1490608 yet ? i know you asked for it
<ubottu> Launchpad bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New]
<mvo> ogra_: yes, you mentioned it and I failed to look at it
<ogra_> i guess thats foundations material anyway, no ?
<mvo> well, yes, I would still guess if someone of us does it it will be faster
<mvo> they are usually super busy
<ogra_> nah, they just pretend to ... its all scripted :P
<barry> tedg: it may not matter in practice.  i think pip wheelifying packages is mostly an implementation detail
<ali1234> o/
<ogra_> hey ali1234
<ali1234> so my problem is essentially that i want all the read-only goodness of snappy, but my hardware is designed around the raspberry pi model a+, and the 2b simply won't fit
<ali1234> debian jessie appears to have the same version of golang and ubuntu 15.04
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-armhf.manifest ...
<ogra_> thats the list of files ...
<ali1234> i've seen those manifest files
<ali1234> but no idea what to do with them
<ali1234> like, what tkes the list and builds an image?
<ogra_> you would want to build them on raspbian
<ali1234> i'd expect most of them already exist
<ali1234> raspbian has literally everything debian has afaik
<ogra_> we use live-build to build the images ... with modifications and configs living in the livecd-rootfs package
<ogra_> there is an old project of mine that i'm about to re-vivie for "building at home"
<ogra_> https://launchpad.net/project-rootstock-ng
<ali1234> hah, rootstock, i remember that
<ogra_> that should allow you to build a rootfs
<ogra_> beyond the rootfs you need a device tarball http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ check the armhf one here ...
<ali1234> what does that do?
<ogra_> carry kernel, firmware blobs and modules
<ali1234> rootfs just manages updates and things?
<ogra_> no
<ogra_> snappy manages the updates
<ogra_> currently using the same mechanism the phones use (system-image)
<ogra_> soon switching away from that ... (everything becomes a snap )
<ogra_> beyond rootfs and device tarball you need an oem snap ... that has your bootloader setup
<ogra_> once you have these three you can feed them into ubuntu-device-flash which generates an image for you
<ogra_> out of these three files
<ogra_> your prob will be that you cant really use the store, even if you get it up and running ...
<ali1234> yeah... i've seen the ubuntu-device-flash stuff too
<ali1234> i'm not concerned about using the store, i want to package my own software
<ogra_> all binaries in the store are built for armhf indeed
<ali1234> my only dependency is gstreamer
<ali1234> which i assume i'd have to bundle anyway
<ogra_> yeah
<ali1234> so step 1 would be to check if debian has all the packages from the device image manifest and then port any that are missing?
<ogra_> right
<ogra_> a lot of the magic is in the initrd, in the snappy binary and in systemd units ...
<ali1234> "system-image-snappy-common" - bet debian doesn't have that...
<ogra_> (nad in the bootloader setup too)
<ali1234> is that package the snappy tool itself?
<ali1234> no, that's ubuntu-snappy
<ogra_> i think the ubuntu-snappy package buulds it
<sergiusens> tedg: oh, you are working on the pip plugin, no wonder your questions, I guess you missed the comment, but zyga was close to having a pip plugin in place
<ali1234> okay well that's something to be going with, thanks
<ogra_> ali1234, just come back if you have more questions (you surely will) ... i'm curious how that experiment turns out :)
<tedg> sergiusens: Oh, okay. Perhaps I should look at a different one then. That was at the top of the backlog.
<sergiusens> tedg: well no worries if you decide to tackle it, not sure zyga has the same agenda we do, but he said he was close
<tedg> sergiusens: I can pause what I'm doing to talk to him tomorrow (I think he's EU timezone) and start on another plugin.
<tedg> sergiusens: I think that we really want to have the shared root ubuntu package support for it, otherwise you have to play with the python plugin.
<tedg> sergiusens: Which really doesn't make a lot of sense.
<tedg> Haha, I lose. The ROS instructions depend on pip :-)
<rickspencer3> does anyone know any tricks regarding getting wifi to work on the bbb?
<ogra_> rickspencer3, plugging in a device we ship the deriver for and following https://wiki.debian.org/WiFi/HowToUse#Command_Line should be enough i think
<ogra_> *driver
<rickspencer3> hmmm, I think I did that
<ogra_> is the device detected ? do you see an interface for it in /proc/net/dev after you plugged it in ?
<pindonga> hi, I'm getting this from snapcraft when building a package using the ubuntu plugin... any idea what I'm missing? no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget line 355.
<rickspencer3> ogra_
<rickspencer3> $ ls /proc/net/dev
<rickspencer3> /proc/net/dev
<ogra_> cat
<ogra_> (meow :) )
<rickspencer3> just lo and eth0
<ogra_> ah, smells like either the driver or some sirmware is missing
<ogra_> *frimware
<ogra_> bah !
<ogra_> check syslog when plugging it in
<rickspencer3> ogra_, http://pastebin.ubuntu.com/12247479/
<ogra_> rickspencer3, ah, ralink ...
<rickspencer3> ogra_, not supported?
 * rickspencer3 sobs
<rickspencer3> I bought it on a whim because it was specifically supported by bbb debian
<ogra_> no, just a constant source of pain :)
<rickspencer3> ogra_, sorry, I don't quite grock, are you saying I am out of luck with this particular dongle?
<ogra_> seems to need the mt7601u module
<rickspencer3> ogra_, ok, what should I do? buy a different dongle?
<beuno> rickspencer3, some guy on the mailing list had the same problem
<beuno> there might not be a dongle that has the module in our kernel
<ogra_> rickspencer3, gimme a bit to read up about it :)
<rickspencer3> well, I know that at least one person got at least one dongle working with rpi2 and snappy
<beuno> rickspencer3, yeah, the rpi2 kernel comes with some modules
<ogra_> hmm, so it should be supported by rt2800usb ...
<ogra_> which we also ship in the device tarball
<rickspencer3> ogra_, well, this image is oooold
<ogra_> (on RPi2 the firmware is missing though )
<ogra_> rickspencer3, uname -r ?
<rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ uname -r
<rickspencer3> 3.19.0-23-generic
<ogra_> not that old then
<rickspencer3> well, I run updates :)
<ogra_> try sudo modprobe rt2800usb
<ogra_> and see if that thinks it knows the device (re-plug if needed)
<rickspencer3> lol
<rickspencer3> $ try sudo modprobe rt2800usb
<rickspencer3> -bash: try: command not found
<ogra_> haha
<rickspencer3> ogra_, I reran  cat /proc/net/dev
<rickspencer3> still just lo and eth0
<ogra_> and syslog
<ogra_> (also after re-plugging with the module loaded)
<rickspencer3> Sep  1 18:46:29 localhost kernel: [ 1300.551733] usbcore: registered new interface driver rt2800usb
<ogra_> nothing else
<ogra_> ?
<ogra_> even when re-plugging the device ?
<rickspencer3> ogra_, no, everything looks the same
<ogra_> the musb-hdrc error in your paste actually indicates a deeper prob with USB i think
<rickspencer3> /proc/net/dev, syslog, etc...
<rickspencer3> awesome!
<ogra_> i guess thats one for ppisati
<ogra_> rickspencer3, if you want to try the same on the RPi, i have a device tarball in preparation that contains all wifi firmware we have at http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz ... perhaps the Pi works better here
<rickspencer3> ogra_, ok, rpi2 is coming up next
<ogra_> the beagle musb issues are legendary :)
 * rickspencer3 finishes transferring bbb to new case
<ogra_> and as old as homers oddisey i think
<rickspencer3> ogra_, not sure what you mean, is it something that we need to fix generally, is it just my specific dongle?
<ogra_> rickspencer3, there are general issues with USB on BBB since forever
<rickspencer3> ogra_, right, but are you saying we are out of luck on bbb, or that we need to hack around the issues?
<ogra_> it got a lot better over the years but there are still issues
<ogra_> well, forst of all you should file a bug and let ppisati know
<ogra_> so he can take a look
<rickspencer3> ogra_, anything else useful I can add to this?
<rickspencer3> https://bugs.launchpad.net/snappy/+bug/1491094
<ubottu> Launchpad bug 1491094 in Snappy "wifi USB dongle fails to work" [Undecided,New]
<ogra_> rickspencer3, i extended the subject line and will point paolo to it tomorrow
<rickspencer3> thanks ogra_
#snappy 2015-09-02
<seshu> hello
<zyga> good morning
<dholbach> good morning
<fgimenez> good morning
<dholbach> mvo, hey hey
<dholbach> can you kick off a build of https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily?
<dholbach> why is it not set to automatic?
<dholbach> or daily
<dholbach> or whatever the setting is
<mvo> dholbach: sure, let me check why its not automatic
<dholbach> <3
<mvo> fixed and triggered a new build
<dholbach> mvo, https://code.launchpad.net/~dholbach/snapcraft/build-deps-syntax/+merge/269853
 * mvo hugs dholbach
<ogra_> ppisati, mind to take a look at bug 1491094 ?
<ubottu> bug 1491094 in linux (Ubuntu) "wifi USB dongle fails to work with musb-hdrc error" [Undecided,Incomplete] https://launchpad.net/bugs/1491094
<dholbach> mvo, once it's merged we can try to build the branch again ;-)
<ppisati> ogra_: BBB? or rpi2?
<ppisati> ogra_: i guess the first
<dholbach> mvo, merged
<ogra_> ppisati, yeah ...
<ogra_> ppisati, sadly rick seems to be back on US timezone, so it might take a bit to get a full syslog
<ppisati> ogra_: do you know if he receive just a single warning or more than one?
<Chipaca> *yawn*
<Chipaca> mo'in people
<ogra_> ppisati, i had him re-plug it a few times and he said thats all that is printed in syslo
<ogra_> g
<ppisati> ogra_: so just a single warning, i guess
<ogra_> as i understand it it should use the rt2800usb ... but seems the kernel doesnt even get that far
<ogra_> (we also tried plugging with the module manually loaded which according to rick made no difference at all ... )
<ppisati> and on a x6 box, it worked, right?
<ppisati> testing on a vivid kernel would be awesome
<ogra_> i thinnk so ...
<ppisati> *x86
<ppisati> let me add some comments to the lp bug
<ogra_> cool, thanks
<ppisati> this thing
<ppisati> "Product: Ð"
<ppisati> this is particularli scary
<ogra_> thats minicom i bet
<ogra_> (getting the actual syslog would likely help a lot)
<ogra_> ppisati, there is another bug where your input might help ... bug 1489412
<ubottu> bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412
<ogra_> i'm notz really sure what to do with it ... turning off turbo mode on the NIC seems to help a little, but doesnt make the issue go away
<ppisati> ogra_: so, about the smsc9xx there
<ppisati> ogra_: i spinned a new kernel with min_free = 32k
<ppisati> and i rebased on the latest 3.19 stable
<ppisati> ogra_: but i didn't update the meta yet
<ogra_> ah, cool, i'll make sure to pull that in for 15.04.3
<ppisati> ogra_: when is the release?
<ogra_> my script doesnt use the meta, it just pulls the newest binary kernel from your PPA
<ogra_> not sure
<ogra_> mvo, do we have some schedule for 15.04.3 ?
<ogra_> or ETA
<mvo> ogra_: I'm not aware of one
<ogra_> ppisati, so the debian way then :) when its ready
<ppisati> :(
<ppisati> i would like to have some testing before we mass deploy
<ppisati> you know...
<ogra_> (which means if you want something specifically, we can hold it back for that)
<ogra_> well, we can indeed ask for testing and haven people use the 15.04 edge channel
<ppisati> about the first bug, i have a match for that usb vendor/product id on a 4.2 wily kernel:
<ppisati> drivers/net/wireless/mediatek/mt7601u/usb.c:    { USB_DEVICE(0x148f, 0x7601) },
<ppisati> but i don't have that match on 3.19
<ppisati> and
<ppisati> Documentation/usb/hotplug.txt:    USB_DEVICE (vendorId, productId)
<ogra_> ah
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864
<dholbach> hey rsalveti, I was playing around with snapcraft a bit more - do you think I should triage the list of open bugs right now and tag the ones which have to do with first user experience or something, so we can have all of them in one list? if yes, which name should we use?
<dholbach> mvo, ^ too
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 is a quick fix I could do myself :)
<guest42315> Snappy Ubuntu Core on Banana Pi BPI-M2 http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432
<ogra_> guest42315, nice !
<Chipaca> pitti: script -qfc
<pitti> Chipaca: heh, nice trick! do you know how much overhead that has?
<Chipaca> pitti: about 23
<Chipaca> maybe 24
<pitti> I mean per line/read/block
<pitti> (what's that unit?)
<Chipaca> pitti: sorry, i was being mean. I have no idea of overhead, but I don't think it's much. It does create a file.
<pitti> script -qfc "sh -c 'sleep 30 & echo payload'" /dev/null |cat
<pitti> even that works
<pitti> but this unifies stdout and stderr, doesn't it?
<Chipaca> hm, probably
<Chipaca> is that bad?
<pitti> ah yes, it does
<pitti> I need to keep them separate/intact, yes
<pitti> but it's a nice trick anyway for other use cases, much simpler than using redirection and tail -f
<pitti> and having to clean up tail
<pitti> so thanks for the trick!
<Chipaca> pitti: and if you take it deeper?
<Chipaca> pitti: e.g. script -qfc '1>stdout 2>stderr commands here'
<pitti> I played around with exec, redirections, fifos, bash's <(command) all morning; it's ridiculously difficult
<pitti> Chipaca: yeah, and then tail -f them both; that's what autopkgtest does on the "outside", as that only needs to be set up once per test
<pitti> but once for every single command is heavier (and also it's brittle as hell), so I was hoping there was something simpler
<Chipaca> ah, you probably also want -e, to get the exit code of the process
<pitti> it took me two months or so to get that "background tail -f" robust enough, and it's still far from perfect
<Chipaca> pitti: are you ssh'ing in, or how are you running these things?
<pitti> Chipaca: depends on the backend; "schroot", "lxc-attach", "ssh", or via a socket for Qemu's case (serial console)
<Chipaca> uff
<Chipaca> pitti: for ssh, a simple -t works
<Chipaca> ie ssh -t yadda yadda
<Chipaca> pitti: what you want is to have a tty
<pitti> right, with PTYs there's no problem
<Chipaca> pitti: but it's simple enough, i think, in C
<Chipaca> pitti: so maybe you need to write a little C :)
<pitti> yeah, in C it wouldn't be a problem at all
<pitti> just that I can't assume that I'm able to compile anything on the target
<Chipaca> then write C :)
<pitti> my testbed could be a read-only phone or snappy without even a compiler
<Chipaca> pitti: it's standard library C; you can cross-compile it without breaking a sweat
<pitti> Chipaca: well, setting that up (lots of C code and making autopkgtest depend on lots of cross compilers and dynamically shoveling binaries to the testbed) sounds a lot harder than my ugly 15 lines of "kill leftover processes" shell hack :/
<Chipaca> arm-linux-gnueabihf-gcc-4.9 -Wall -o blah blah.c && scp/put/cp/whatevs && etc
<pitti> maybe perl
<pitti> perl-base is still essential
<Chipaca> pitti: I'd expect you to say that two months ago, before spending two months on tail :)
<ogra_> pitti, store the PIDs in a file and loop over it with kill when the parent dies  ?
<ogra_> via a trap cleanup command ...
<Chipaca> pitti: perl works, also, i think
<pitti> anyway, quite a number of people have answered, and I found some related discussions on various forums
<pitti> so at least I'm now reasonably sure that I wasn't missing something obvious
<Chipaca> ogra_: you'd have to strace -f to grab all the clones & forks
<ogra_> Chipaca, well, or just start everything through a wrapper function
<Chipaca> pitti: "try" from libio-pty-perl's examples is probably a good place to start
<Chipaca> anyway. to lunch.
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo ubuntu-device-flash core --channel edge --device device-pi2-0.16.tar.xz --oem pi2.canonical --developer-mode --install webdm -o kvm-rolling.img rolling
<ogra_> [sudo] password for ogra:
<ogra_> WARNING: this option should only be used to build azure images
<ogra_> Determining oem configuration
<ogra_> great ...
<ogra_> now if it could tell me *WHICH* option "this option" is :P
<ogra_> ah, obviously --device ...
<tbr> debug output is overrated
<ogra_> heh
<rickspencer3> hey, is there an easy way to change the channel that my bbb is on?
<rickspencer3> I think I'd like to get daily updates on it
<ogra_> rickspencer3, no idea if that works ... but try system-image-cli --switch (with a lot of -vvv to increase verbosity)
 * rickspencer3 tries
<ogra_> i guess switching channels will become easier as soon as we dropped system-image
<rickspencer3> ogra_, does it not need an argument for the channel to switch to?
<ogra_> sure, like on the phone
<ogra_> (up to you want you want to switch to)
<rickspencer3> ogra_, so, I want to switch to 15.04 edge, is there somewhere that shows me how to formulate that argument?
<ogra_> ubuntu-core/15.04/edge ...
<ogra_> note that this channel is on manual though
<ogra_> only gets builds if we upload changes to the PPA or before a release
<rickspencer3> manual is good for edge, I think
<rickspencer3> ogra_, oh, is there a better channel if I want to test latest bug fixes, etc...?
<Chipaca> fwiw, channel switching is Not Supported
<ogra_> wily ... ubuntu-core/rolling/edge ... that has daily builds but also the highest chance of breaking
<ogra_> Chipaca, i think it worked for me last time on RPi ... but cant roll back or some such
<rickspencer3> ogra_, so, the argument is ubuntu-core/rolling/edge ?
<ogra_> yes
<Chipaca> i'm not saying it won't work; i'm saying if it works, huzzah, but if it breaks oh well :)
<ogra_> yeah
<rickspencer3> and it will get automatically update each day, and maybe break a lot?
<ogra_> i dont remember what was broken on my RPi test ... but iirc it initially worked ... and either didnt upgrade or didnt roll back anymore
<rickspencer3> I guess I can just get another sd card and put a more stable version on it :)
<ogra_> yeah
<rickspencer3> looks like it is trying to upgrade it :)
<rickspencer3> [systemimage] Sep 02 12:35:29 2015 (1239) Upgrade path is 155 :)
<rickspencer3> (note the ":)" is mine
<ogra_> well, we should add more smileys to log output :)
<ogra_> you could then also indicate error severity through them ;)
<ogra_> :/ <- bad ... :( <- severely bad ... X( <- totally dead
<rickspencer3> ogra_, that would be brilliant
<rickspencer3> or just emojis
<rickspencer3> says it is rebooting, I'll take that as a good sign
<ogra_> well, UTF8 is often broken in serial terminal apps :)
<ogra_> but yeah, emojis would rock
<rickspencer3> emoticons it is, let's get the spec started ;)
<rickspencer3> well, it didn't reboot itself
 * rickspencer3 reboots, braces for impact
<rickspencer3> ogra_, so, it rebooted and my led blinking snap started!
<rickspencer3> I take that as a good sign
<rickspencer3> is there a way for me to confirm that I am now on the channel that I wanted to be on?
<ogra_> rickspencer3, sudo snappy list -v
<ogra_> abd system-image-cli -i
<rickspencer3> ubuntu-core 2015-07-29 4       ubuntu*
<rickspencer3> ubuntu-core 2015-09-02 155     ubuntu
<ogra_> seems it didnt switch
<rickspencer3> oh?
<rickspencer3> oh well, I guess I'll just set up a new sd card with the right channel later
<ogra_> * indicates the active one
<rickspencer3> at least it didn't hose my board
<ogra_> you can force the swtich ... one sec
<ogra_> fw_printenv |grep ^snappy_ab
<ogra_> what does that print ?
<rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab
<rickspencer3> Cannot access MTD device /boot/uboot/uboot.env: No such file or directory
<ogra_> oh
<ogra_> hmm, you said this install is old ..
<ogra_> seems it is really old :)
<rickspencer3> ogra_, if this is going to become a yak shaving exercise, I suggest that we call channel switching "unsupported" and I can flash a new sd card at my leisure
<ogra_> we *do* call it unsupported ;)
<rickspencer3> well, right, that's my point ;)
<ogra_> but you are running into issues with an ancient bootloader setup
<rickspencer3> ok, sounds like a reflash is in order anyway, then
<ogra_> it wouldnt even switch on normal upgrade i fear
<ogra_> yeah
<rickspencer3> are there any docs on how I would use use snappy config?
<ogra_> well, it isnt very user friendly yet
<rickspencer3> I want to write a snap where you can define the gpio pin to use after installing the snap
<ogra_> you need to create a yaml file and pipe it into the command
<rickspencer3> ogra_, so, I could write go code that takes an argument in a form post
<rickspencer3> uses that to write a yaml file
<ogra_> i think sergiusens had some demo code for that
<ogra_> piping from a here doc
<rickspencer3> then pipes that yaml file in snappy config?
<ogra_> oh, if you want to do it on image level you should be able to define it in the package.yaml of a custom oem snap
<rickspencer3> ogra_, no, I want to do it on the snap level
<rickspencer3> i.e. the snap is in the store
<ogra_> (where you would also define your app snap as a requirement)
<rickspencer3> then it can be configured to use the specified gpio pins
<ogra_> ah, right, yeah , then you need to create a yaml file and run snappy config manually after install
<rickspencer3> so the end user will have to edit the yaml file on the board and run the command
<rickspencer3> ouch
<ogra_> nah, it will be more userfriendly
<ogra_> but this is the status quo
<ogra_> we have to many other construction areas atm ... config is only very basic yet
<rickspencer3> ok, I'll look at sergiusens code when he wakes up if he can point me to it :)
<sergiusens> rickspencer3: I don't have any code
<rickspencer3> oh
<rickspencer3> lol
 * sergiusens has been awake for 3 hours already
<sergiusens> ogra_: rickspencer3 you can also do snappy install [snap] [config]
<rickspencer3> sergiusens, I meant "wake up" in a totally figurative way :)
<rickspencer3> sergiusens, is there documentation that I can use anywhere?
<ogra_> ah, thats new to me
<sergiusens> ogra_: it's in the --help (snappy install --help)
<rickspencer3> so, my idea for the snap is that when the board is ready to be connected to over ssh, it blinks a led
<ogra_> sergiusens, yeah i tried "snappy help" :P
<ogra_> (no, i'm lying indeed)
<rickspencer3> is there a way that a snap could easily tell if ssh is ready?
<rickspencer3> i.e. from Go code?
<sergiusens> rickspencer3: so you indeed want a config to configure where that LED is
<rickspencer3> sergiusens, yeah
<sergiusens> rickspencer3: you would need special permissions to check it at the service level
<sergiusens> rickspencer3: the thing you can do today is poll the port and wait for the ssh signature
<rickspencer3> there are 2 things I don't know: 1. how to determine if ssh is running, 2. how to allow the developer to config the gpio pin
<rickspencer3> sergiusens, I can't do that with just the normal network permissions?
<rickspencer3> seems like I could do a loop and just ping it over localhost?
<sergiusens> rickspencer3: yes, we don't have any security in place for fine grained networking :-/
<rickspencer3> sergiusens, yes I can do that, or yes I can't do that?
<sergiusens> rickspencer3: ping over localhost or over the main interface
<Chipaca> ogra_: rickspencer3: cdparanoia has emoticons for status output
<sergiusens> rickspencer3: yes you can!
<rickspencer3> ok, that sounds easy enough
<Chipaca>          :-)  Normal operation, low/no jitter
<Chipaca>          :-|  Normal operation, considerable jitter
<Chipaca>          :-/  Read drift
<Chipaca>          :-P  Unreported loss of streaming in atomic read operation
<Chipaca>          8-|  Finding read problems at same point during reread; hard to correct
<Chipaca>          :-0  SCSI/ATAPI transport error
<Chipaca>          :-(  Scratch detected
<Chipaca>          ;-(  Gave up trying to perform a correction
<Chipaca>          8-X  Aborted read due to known, uncorrectable error
<Chipaca>          :^D  Finished extracting
<ogra_> hah
<sergiusens> Chipaca: that reminds me of mac system 7
<Chipaca>     c.Check(logs, DeepEquals, []map[string]interface{}{{"a": 1}, {"a": 2}})
<Chipaca> ... obtained []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}}
<Chipaca> ... expected []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}}
 * Chipaca goes looking for somebody to wap over the head
<mvip> Alexander -- this is Viktor from Screenly. Sorry, forgot your nick, but please just wanted to join the channel and say hi.
<Chipaca> asac: ^
<mvip> Thanks :)
<mvip> Oh and i see mectors is hanging out here too :)
<mectors> mvip of course
<mvip> :)
<rickspencer3> o/ mvip
<mvip> Need to brush up on my bitchx skills. Haven't spent much time on IRC in the last decade :)
<bartkusedvinas> Hello there. I need some help that I can't find yet on Google. How do I add to may #cloud-config DOCKER_OPTIONS :/ does anyone use it?
<bartkusedvinas> Is it possible to write to /var/lib/apps/docker/1.6.2.003/etc/docker.conf via cloud-config?
<mvip> Are there any examples out there of running X11 apps in snaps?
<mvip> bartkusedvinas: isn't /var residing on /, which is mounter r/o?
<bartkusedvinas> you are right, it is read only
<tedg> zyga: There is a rumor that you're working (and close to completing) pip support for snapcraft. Is it true?
<mvip> bartkusedvinas i'm by no mean a Snappy expert, but my guess is that it's mounted as r/o on boot. As such, you can not modify that file (unless you hackishly re-mount it *inside* cloudinit)
<tedg> bartkusedvinas: Snaps themselves have a configuration interface, which the docker framework should use. I'm not sure if it is though.
<bartkusedvinas> mvip: sounds right... tho, i bet that those who are using docker want to add DOCKER_OPTIONS='-H tcp://0.0.0.0:4243'
<bartkusedvinas> however i can't find what is the right approch to do so
<ogra_> bartkusedvinas, the shipped cloud-init is only used for bringing up the system ...
<ogra_> not for tinkering with snaps
<tedg> mvip: I think that deb2snap was used to make some Xapps run, but I can't think of an example.
<tedg> mvip: Is there are particular one you're trying to run? Many have Mir backends available as well.
<ogra_> bartkusedvinas, well, you are likely not using docker standalone ... but run something in it
<ogra_> bartkusedvinas, for that something you would create a snap that uses the docker framework
<ogra_> and in that snap you would set such options
<mvip> tedg: Well, yeah, have some things in mind, but was just curious if there were any examples out there. `deb2snap` seems somewhat hackish.
<tedg> mvip: It is :-)
<mvip> tedg: :)
<mvip> Just out of curiousity, how's Docker configured on Snappy. Is it run on the host, or is it running within a snap?
<mvip> Because I saw a Docker snap when I was playing with it on the RasPi
<tedg> mvip: I wrote up an examle using Qt/QML, but that is with the Mir backend: http://gould.cx/ted/blog/Creating_a_QML_snap_with_Snapcraft
<ogra_> bartkusedvinas, i guess kickinz1|afk could help (if he werent afk) he maintains the docker framework snap and also the owncloud snap that uses it
<mvip> tedg: Oh cool. Thanks.
<kickinz1> mvip docker is a framework snap
<mvip> kickinz1 ah ok
<mvip> still getting used to the Snappy lingo
<ogra_> ha, speaking of the devil :)
<bartkusedvinas> thanks. i want to try snappy as alternative to coreos
<bartkusedvinas> with coreos i had the following cloud-config which would open access to docker https://gist.github.com/edvinasbartkus/8ed0e61a7c7980c087f1
<bartkusedvinas> so I would be able to use deploy tools to deploy to coreos docker's my containers
<ogra_> yeah, this is the stuff you would do in a start script of the snap i talked about
<bartkusedvinas> i see
<ogra_> http://paste.ubuntu.com/12253305/ i.e. this is the start script used by the owncloud snap
<ogra_> i assume you would have something similar in a coreos-docker.snap
<mvip> kickinz1 so if Docker is a Snappy framework, i then presume it is running on the host and then snappy is responsible for communicating with Docker, right?
<kickinz1> mvip, yes, docker is running on the host, there are some specific apparmor profile management.
<bartkusedvinas> I was expecting to find some easy recipie like this https://gist.github.com/edvinasbartkus/a99dd8bf12f717c7c6f5 :))
<mvip> kickinz1 got it. Thanks.
<bartkusedvinas> @orgra_ thanks for the hint to the script. will try to improvise my way ;)
<nothal> bartkusedvinas: No such command!
<kickinz1> mvip, but for now you can connect directly to docker-daemon, be aware, that if you want to do some docker build, docker load/save, you need to have your files in $HOME/apps/docker.$VERSION/
<bartkusedvinas> @nothal yeah, i am  aware :) i was expecting just to have such easy solution :P
<nothal> bartkusedvinas: No such command!
<kickinz1> $HOME/apps/docker/$VERSION/
<ogra_> bartkusedvinas, well, i'm pretty sure such an easy setup is possible too ...
<mvip> kickinz1 got it.
<ogra_> bartkusedvinas, the point in snappy is that you are completely confined ... so you would never modify any of the system setup of docker but ship your own
<Chipaca> pitti: question for you sir
<Chipaca> pitti: what should "journalctl -q -u something-that-does-not-exist" print, given the -q?
<bartkusedvinas> @ogra_ thanks
<nothal> bartkusedvinas: No such command!
<ogra_> you should leave out the  @ :)
<bartkusedvinas> oh :) sorry for being newby
<bartkusedvinas> and even spelling like a newbie :))
<pitti> Chipaca: you mean wrt. the -- No entries --? -q is documented as "Suppresses any warning messages regarding inaccessible system journals when run as a normal user.", but I see how one would want to shut up that message too :)
<ogra_> no worries ...
<ogra_> usually the ubuntu bots dont use @ but ! ... nothal is special in this channel
<Chipaca> pitti: the "No journal files were found." was more the thing i was expecting it to suppress
<Chipaca> as it stands -o json outputs json except when it doesn't
<Chipaca> making it somewhat annoying :)
<pitti> Chipaca: I don't get that
<pitti> $ journalctl -q -u something-that-does-not-exist
<pitti> -- No entries --
<pitti> $
<Chipaca> $ journalctl -q -u potato
<Chipaca> No journal files were found.
<Chipaca> -- No entries --
<dholbach> sergiusens, is there a switch for snapcraft to force-rebuild everything? or how do you normally use it? (rm -rf parts stage snap; snapcraft)?
<pitti> Chipaca: but this should be fixed anyway -- "-- no entries --" is quite useless for json output/parsing too
<zyga> tedg: hehe
<zyga> tedg: yes, let's talk
<zyga> tedg: I'm working on this hard
<zyga> tedg: and I'd love to have an accomplice
<tedg> zyga: Do you have a branch pushed?
<zyga> tedg: no, I got into a few blockers, if you want we can sync and talk about that but I'm packed with meetings now
<zyga> tedg: we could invite you to a meeting in 25 minutes (monthly catch up on snappy)
<zyga> tedg: that could help as wel
<zyga> well
<tedg> zyga: Uhm, okay. I'm not looking for more meetings ;-)
 * ogra_ notes down ... ted ... looking for more meetings ... 
<tedg> Heh, thanks ogra_
<ogra_> :)
<zyga> lol
<zyga> tedg: so let's just talk here
<zyga> tedg: tell me about your approach
<zyga> tedg: and I'll tell you what I did and what I got stuck on
<tedg> zyga: I was looking at adding a field to the python projects for adding a requirements.txt
<tedg> zyga: Grab it, install it, party on. â my approach :-)
<zyga> tedg: mmm
<zyga> tedg: have you run into the numerous issues in python3app implementation today
<zyga> tedg: it's pretty much all wrong now
<zyga> tedg: it bleeds the python stuff from the system into the snap stage area
<tedg> Not sure what python3app is? python3-project ?
<zyga> yep
<zyga> I never remember if it's -project or -application
<zyga> but yes
<zyga> e.g. you pip install requirements and it ignores stuff you have locally installed
<tedg> Ah, I don't have anything from pip locally installed :-)
<zyga> not from pip
<zyga> from the system
<zyga> I have patched that heavily
<tedg> So it needs to restrict its search path. Sounds like an envvar?
<zyga> tedg: more than that
<zyga> tedg: you really need to run the python from the stage area
<zyga> tedg: there's no clean way to do it otherwise
<zyga> tedg: and you essentially need to do what virtualenv does to be correct
<tedg> Sure, but that's handled by setting up the path correctly.
<zyga> tedg: then there are some interesting issues related to that but that's
<zyga> tedg: path? yeah
<zyga> tedg: well
<zyga> tedg: no, just running the right python explicitly
<tedg> Eh, okay. That can work too.
<zyga> tedg: anyway, it's clear that you just run the right python with the right extra PYTHONHOME helpers and perhaps python -S (so that site is not imported)
<zyga> tedg: then you get empty python and pip install works
<zyga> tedg: I ran into some other issues though
<zyga> tedg: and that's where I'm stuck now (though just stuck with ENOTIME)
<tedg> zyga: K, do you have a branch somewhere that I can look at?
<sergiusens> dholbach: I'm rm'ing, but I do want to at least add a 'clean' statement
<zyga> tedg: I have it locally but it's all teribble as I was trying to figure out how to upstream it
<zyga> tedg: let me show you the diff in a sec
<zyga> (really stuck in meetings)
<dholbach> sergiusens, it looks like it's necessary to remove the sideloaded package in a snappy system as well when using snappy-remote and not updating the version number
<dholbach> so I can't just build a new snap and snappy-remote it again
<sergiusens> dholbach: oh, Chipaca fixed that, for rolling at least
<dholbach> <3
<dholbach> I love you guys
<ogra_> sergiusens, oh ? including apparmor profile updating ?
<ogra_> (i thinnk that didnt work in the past)
<zyga> tedg: can you tell me more about what test projects you are trying to bundle with pip?
<sergiusens> ogra_: dholbach the version is basically ignored and hashed, sideloading has no upgrade paths in any case, so it is all fine
<ogra_> ah, cool
<ogra_> in the past even for locally sideloaded snaps the apparmor profile wasnt updated when i didnt bump the version
<Chipaca> ogra_: the version in the file is ignored for sideloaded
<ogra_> Chipaca, yup. got that now
<Chipaca> ogra_: it's a base62 hex string of the timestamp in ns
<Chipaca> base 50, not base 62, sorry
<Chipaca> anyway
<Chipaca> it's an apparently random string of a-yA-Y
<Chipaca> such that something installed later always compares as newer
<Chipaca> as long as your clock isn't completely full of it, that is :)
<Chipaca> this means rollback still works as expected
 * sergiusens reboots to enable VT on this laptop
<tedg> zyga: Looking more at the feature genericly. I don't have a specific project I need to package.
<tedg> zyga: To have something to play with I was looking at Jasper, but it's a huge thing to get working, but provides a nice example.
<zyga> tedg: I think it would be healthy to set up some projects as canaries, that you can build "complex" stuff
<zyga> tedg: thanks, I'll have a look at that
<zyga> tedg: as a sanity check, add checkbox-ng to that list, it's very important for an ongoing project we're doing
<zyga> tedg: one thing I think needs more help is building C extensions
<zyga> tedg: the requirements file needs to be coupled with a list of debian packages you need on the outside to build your stuff
<zyga> tedg: stanity check for that is lxml2
<tedg> zyga: How does PIP express those dependencies?
<zyga> tedg: it doesn't at all :D
<zyga> tedg: but it's very very important
<zyga> tedg: without this you won't get important things (requests)
<zyga> tedg: and it's sad but that's what it is
<tedg> Guess we'll have to take those on a case by case basis. But it means having to parse the file by ourselves :-/
<ogra_> hmm, funny ... why does the rolling initrd on my Pi not attempt to resize at all
<ogra_> oh
<ogra_> probably because i should update to the new initrd in the device tarball :P
<ogra_> super irritating that /usr/share/initramfs-tools/scripts/local-premount/resize exists in my rootfs :P
<ogra_> (but not in the binary initrd)
<elopio> fgimenez: sorry, I stayed in bed a little later today.
<fgimenez> elopio, np! :) we can move our meeting a bit later
<elopio> fgimenez: thanks for the subunit reviews. I'll make the changes.
<fgimenez> elopio, ok thanks, when you have time take a look at https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176
<dholbach> tedg, do you know what's up with https://bugs.launchpad.net/snapcraft/+bug/1491301?
<ubottu> Launchpad bug 1491301 in Snapcraft "qmldemo example doesn't work" [Undecided,New]
<elopio> sergiusens: or somebody, do you know how to make something like a prerequisite branch in git?
<elopio> fgimenez: on it. I pushed the two subunit branches.
<sergiusens> elopio: I'd ask the lp guys, cjwatson maybe knows
<elopio> I'll wait for them.
<tedg> dholbach: Hmm, no. I'll blame sergiusens ;-)
<tedg> Let me look at it.
<elopio> fgimenez: wow, nice catch on that branch. Now I understand the mess.
<elopio> mvo: sorry, my suggestion on https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 was wrong. I'm testing Federico's proposal now.
<dholbach> thanks tedg
<dholbach> another example is broken as well: https://bugs.launchpad.net/snapcraft/+bug/1491303
<ubottu> Launchpad bug 1491303 in Snapcraft "tomcat-maven-webapp example doesn't work" [Undecided,New]
<mvo> elopio: no problem
<elopio> ev: about my request for git, if we want to save the master configuration in a repository, we will need to run git on the master.
<elopio> it's run by the plugin, so we don't need to access the shell manually. But it's not useful in this case to install git in a slave.
<fgimenez> elopio, thx maybe we could try to refactor things there
<elopio> fgimenez: I think it's clear. The mess is because the behaviour is different in uboot, but your new comments make that ok.
<mvo> sergiusens: I plan to look into u-d-f tomorrow for bigger rootfs, I would also like to increase /boot while at it to something like 256mb, what do you think? we no longer need system-a,b
<sergiusens> mvo: sounds good, you can also look at my branches in lp:~snappy and reuse those if you want (there's uflash and an import of mostly everything into lp:snappy)
<mvo> ogra_: if you have some you could have a look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 at some point, just to see if there is anything obviously wrong (except for the fixmes :)
<mvo> sergiusens: oh, do you think that should be the way forward? to use uflash instead of u-d-f?
<sergiusens> mvo: I do, I really do; it will be easier to separate old world order from the new world order
<sergiusens> mvo: http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/
<sergiusens> mvo: would need some polishing, but that's where I left things before the Lex sprint
<sergiusens> mvo: I did some general snappy cleanup there (moving away from helpers) so it is not all that easy to follow; but if you want, I can get these branches up to speed with the latest trunk
<ogra_> mvo, hmm ... dont you create a bunch of loops there ?
<mvo> sergiusens: ok, I check tomorrow
<mvo> ogra_: probably, not sure that can be avoided
<mvo> ogra_: because the os is on /writable
<ogra_> mvo, the rootfs snap should not live in the writable partition
<ogra_> yeah
<ogra_> thats a prob
<ogra_> how would i do a factory reset ? wiping writable would wipe everything
<ogra_> the rootfs should be a readonly img in /boot
<ogra_> or better in system-boot
<mvo> ogra_: thats what we will do with the recovery, there will be a os/kernel in /boot to always go back to
<ogra_> in fact i'd even say the rootfs should be a readonly img in system-boot/a or b
<ogra_> mvo, yeah, but still that mount loop of bind mounting stuff on top of itself isnt good
<mvo> ogra_: we also have this mandate to stay within two partitons
<ogra_> mvo, yes, readonly bits should stay in system-boot
<ogra_> so you end up with system-boot and writable
<mvo> ogra_: if we put the entire os into system-boot we need a much bigger partition and it can no longer be vfat
<ogra_> oh ?
<mvo> (at least until we also move to squash/ext.img)
<ogra_> the readonly img is biger than 1G ??
<ogra_> *bigger
 * ogra_ cant imagine that 
<ogra_> it should be a few 100 M
<ogra_> if at all
<mvo> the core is ~90Mb and a kernel ~120Mb
<ogra_> yeah, thats far from the 2G limit for vfat
<mvo> and we want to keep at least two each, so we need ~500mb
<ogra_> right, still plenty of space
<mvo> right, but it also means we need to move to squashfs in one step
<mvo> we can unpack on vfat
<ogra_> why would you unpack ?
<mvo> because right now the kernel and the os are regular snaps and snaps are unpacked (currently) until we move to squashfs
<mvo> we will get there, but not right now
<ogra_> well make it unpack a single img file then
<ogra_> you want to loop mount that anyway
<ogra_> no matter what the format is
<ogra_> i dont think the loop you create currently is safe at all
<mvo> that could be a way, yes. I would prefer to keep snaps the same, this is what I dislike about the approach
<mvo> ogra_: unsafe in what way?
<ogra_> dunno, i have to think about it but it makes me twitch heavily
<mvo> ogra_: ok
<ogra_> i did something similar for the first iteration opf the phone and stgraber pointed out a lot of flaws with that
 * ogra_ will have to dig up that conversation 
<beuno> ah, you might be
<mvo> ogra_: that would be nice, I obviously do not want unsafe stuff, but I also want to understand whats unsafe about it
<mvo> ogra_: I can ask him directly too if thats helpful (but after dinner)
<ogra_> yeah
<ogra_> probably even better having him take a look at the code
<mvo> great, I will ask him
<ogra_> it makes me twitch heavily :)
<mvo> thanks for the feedback!
<mvo> well, we will get to the squashfs eventually :) it will all be good. and to the recovery and all the other missing bits
<ogra_> (even though i did something similar with the loop mounted img files on the phone )
<mvo> but yeah, if its not safe, its not safe and we need to skip the step
<ogra_> i dont see a need for squashfs here
<ogra_> its a nice extra but not really necessary
<ogra_> the img files can even be ext2
<mvo> ogra_: well, s/squashfs/binary-images/
<ogra_> (and probably should, for speed)
<mvo> stgraber: so if you have a moment at some point, a quick look at https://code.launchpad.net/~mvo/ubuntu/wily/initramfs-tools-ubuntu-core/new/+merge/269945 would be cool and how horrible (or not) the approach is
 * mvo gets dinner
<ogra_> mvo, one thing that comes immediately to mind is that i can indeed edit content in /writable/system-data/os/ubuntu-core.sideload/${snappy_os}/*  at any time, it isnt actually readonly only the bind mount on top is
<ogra_> so i have always full write access to the original files
<stgraber> commented
 * ogra_ commented too 
 * tedg thought some of these nicks weren't LP bots, apparently was wrong.
<sergiusens> mvo: still around?
<mvo> sergiusens: yes, but almost ready for eod
<sergiusens> pindonga: did you log a bug about the forking issue in the systemd unit?
<pindonga> yep
<sergiusens> pindonga: can I have the number? I can't find it :/
<pindonga> looking
 * sergiusens sucks at bug searching in lp
 * pindonga thanks firefox for remembering seen urls
<pindonga> https://bugs.launchpad.net/snappy/+bug/1490574
<ubottu> Launchpad bug 1490574 in Snappy "add support for raw systemd unit files" [Critical,Triaged]
<sergiusens> pindonga: ah, the title was ignored by my eyes :-) I thought we just wanted to support forking processes
<pindonga> sergiusens, we probably do
<pindonga> it's just I didn't enough it when I filed the bug :)
<pindonga> s/enough/know/
<sergiusens> tedg: btw https://code.launchpad.net/~sergiusens/snapcraft/ubuntu-core/+merge/269938 feel free to slaughter it ;-)
#snappy 2015-09-03
<dholbach> good morning
<fgimenez> good morning
<dholbach> can anyone explain this? http://pastebin.ubuntu.com/12261129/
<mvo> kickinz1: I pushed your branch for docker, thanks again
<mvo> dholbach: uh
<mvo> dholbach: let me try to reproduce
<fgimenez> dholbach, mvo it seems to be already reported https://bugs.launchpad.net/snappy/+bug/1474658
<ubottu> Launchpad bug 1474658 in Snappy "Can't install hello-dbus-fwk & mir: snappy package not found" [Undecided,Confirmed]
<dholbach> oh ok, thanks fgimenez!
<kickinz1> mvo thanks!
<ogra_> mvo, so after your comments about vfat and size issues yesterday i looked up the sizes again ... max file size is 4GB on fat32 ... and max volume size lies between 2TB and 16TB depending on the sector size, i doubt we'd run into any probs with that
<ogra_> https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 ...
<mvo> ogra_: thanks, I was thinking about it last night and I think we need to jump straight to the images, I had hoped we could have a intermediate step to have less churn in the code
<ogra_> yeah
<mvo> ogra_: your and stephans comments make a lot of sense
<ogra_> we had similar discussions when we did the phone design :)
<ogra_> there was some training here in advance ;)
<mvo> heh :)
<mvo> I think we could do it as a intermediate step, but then why bother and go all the way
<ogra_> i actually dont think it matters if you use system-boot or writable since both hold a writable system ... writes to system-boot just happen a lot less which makes it a bit safer ...
<ogra_> if you want an immediate step, keep everythingn as is, but just ship img files inside the respective snaps
<ogra_> instead of whatever it is now (tarballs ?)
 * mvo nods
<mvo> it seems like the work for this is almost the same as going all the way, so I think all the way it is
<ogra_> ok
<ogra_> that makes us depend on squashfs though ... which means we need a solution for the module in case we want a generic initrd
<mvo> indeed
<ogra_> a modules.img formatted as ext2 would work, or we compile squashfs into the kernel or we postpone generic initrds
<ogra_> (sadly modules.img would benefit most from squashfs :P )
<mvo> hm, I guess we need to talk to the kernel guys how horrible squashfs into the kernel is
<ogra_> well, if it even works :)
<mvo> I still don't full understand the benefit from the generic initrd (but thats just my ignorance) so I can't comment how horrible postponing that would be
<ogra_> easy porting, less maintenance
<ogra_> you dont have a way to just tell the kernel build tools to generate an initrd for you during kernel build ...
<ogra_> so you need to create a chroot of the target arch, install all bits in there and run update-initramfs ... or you garb a binar initrd from one of the device tarballs and modify (and potentially break) it
<ogra_> sigh, my typing sucks
<mvo> I wonder if we could improve the tooling that generates the kernel snap from the kernel binary we get
<mvo> this is what I do right now (add some stuff to the initrd)
<mvo> we could also generate it there and have some fancy config that contols what goes in/out
<mvo> but yeah, the tooling we have right now is not great
<ogra_> right, we could just provide tooling ... but it is still a debootstrap, chroot etc if you build it from scratch ...
<ogra_> quite some effort ...
<ogra_> and automated modifying would mean quite some scriptery
<ogra_> in case you want to use a "template" initrd
<ogra_> we need to somehow make sure all arches and ports are on the same page wrt scripts and binaries in the initrd ... if i use a 15.04/foo image it needs to be the same initrd in use on my bananapi as there is in the azure cloud
<ogra_> else debugging will become painful
 * mvo nods
<asac> read in some email that we have snappy service now in trunk? whats the syntax/semantic of that?
<ogra_> asac, snappy service start|stop|status
<asac> ogra_: ok... log would be nice too i guess :)
<asac> ogra_: no restart?
<ogra_> Chipaca, ^^^ ?
<ogra_> i guess also restart
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy service help
<ogra_> Unknown command `help'. Please specify one command of: disable, enable, restart, start, status or stop
<ogra_> ;)
<asac> ogra_: how do i list the services available that i can put as argument?
<ogra_> good question
<asac> :)
<ogra_> i think its the name of the snap ...
 * ogra_ tries
<asac> ogra_: you can have multiple services per snap
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy service status webdm
<asac> so cant be just that
<ogra_> Snap	Service	State
<ogra_> webdm	snappyd	enabled; loaded; active (running)
<ogra_> (had to install webdm first)
<asac> ok maybe that applies for all services in a snap?
<ogra_> so whatever snappy list gives  you i guess
<asac> the service is snappyd here :)
<asac> not webdm
<asac> at least the column titles suggest such
<ogra_> oh,. right
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo snappy service disable webdm snappyd
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy service status webdm
<ogra_> Snap	Service	State
<ogra_> webdm	snappyd	disabled; loaded; active (running)
<asac> ic so mnaybe also status webdm snappyd
<ogra_> yeah, but for webdm that prints just the same
<ogra_> no idea if it actually filters or just gets ignored
<asac> looking  at code it seems to get filtered
<ogra_> cool
<asac> so just webdm stop should stop all
<ogra_> well, in any case it works
<asac> whch is also neat
<asac> just need log imo
<ogra_> and is pretty intuitive given i have used it for the first time 5min ago ;)
<asac> then no need to fiddle with systemd cli anymore
<asac> hehe
<mvo> yes, that was the reason for it
<Chipaca> pindonga: morning sir. I just came accross a log entry that has no _SOURCE_REALTIME_TIMESTAMP. Please advise...
<Chipaca> um
<Chipaca> pindonga: not you :)
<Chipaca> pitti: you ^^
<Chipaca> pitti: http://pastebin.ubuntu.com/12261699/
<pitti> Chipaca: the manpage describes it as optional
<pitti> i. e. only if it's different from __REALTIME_TIMESTAMP
<Chipaca> ah, gotcha
<Chipaca> ta
<pitti> Chipaca: (or the source isn't trusted)
<sja_> Hey Guys! (Hopefully) quick question: I need pppd to establish a ppp connection from a snap. Should I include the binary from ubuntu repos in my snap?
<Chipaca> sja_: yes
<ogra_> sja_, we dont care ;) ...
<Chipaca> ah, better answer
<ogra_> sja_, you could also build your own binary :)
<Chipaca> sja_: the one from ubuntu might be hardwired to look for things in /etc/
<Chipaca> i don't know
<ogra_> (it is often more convenient to use it from the archive indeed )
<sja_> :-) So it's to me to keep it up ti date
<ogra_> yeah
<ogra_> you got all the freedom to use whatever suits your needs :)
<sja_> ok. Well, pppd should not be updated so often. It's not the hot new technology. ;-)
<ogra_> effectively the snap only uses binaries ... how you produced them is up to you
<ogra_> in case of pppd Chipaca is right, it might expect files in locations you cant control ...
<ogra_> so you might need to invoke it with cmdline options that override this
<ogra_> (if it supports that)
<sja_> yes. Hopfully if all params given, it'll not look for files in /etc, but I#ll see it in the logs.
<ogra_> yeah
<sja_> thanks.
<sja_> @asac greetings from openHAB team, I'll start a new try to make an openHAB-Snap the next weeks.
<nothal> sja_: No such command!
<asac> sja_: oh awesome!
<asac> :)
<asac> welcome
<asac> on above, i think ricmm was talking about including pppd in core... not sure if that happened or we decided against it
<ogra_> uh
<asac> ricmm: what did we end up doing?
<sja_> Ok, my setup is, that I have an USB stick with a specific usb id (great for udev) which is then available on /dev/ttyUSBX. To talk to the stick, I connect via pppd to that tty and have a new network interface ppp0. For that I have to set a route like Â´ip -6 route add fc00::/10 dev ppp0`
<sja_> So, I'm fine with an own pppd binary in my snap, but I worry about the route now.
<sja_> And I need IPv6
<ricmm> asac: my suggestion was to include pppd in core, as well as wdt
<ricmm> commonly used low level services like that, however the discussion stalled at some point
<ogra_> ricmm, where do you draw the line then ? you'd also want pppoed and whatnot
 * ogra_ guesses it sums up 
<sja_> I see that there is a problem on keeping the core clean and simple. Wouldn't it be better to give the community good guide on how to include those kind of binaries off the default ubuntu repos? Together with cross compiling for armhf.
<sja_> Maybe that would be enought for most of the snap authors.
<ogra_> sigh
<ogra_> seems there were some serious user changes in some package in wily ... all images that do a passwd check during build failed
<ogra_> hmm, could be rsyslog
<mvip> Looks like there are still some `apt` leftovers in Snappy. For instance, /etc/cron.daily/apt
<ogra_> mvip, can you file a bug for that ?
<mvip> ogra_ sure. What's the bugtrack URL?
<ogra_> see the channel topic :)
<mvip> ogra_: my bad :)
<mvip> ogra_: https://bugs.launchpad.net/snappy/+bug/1491781
<ubottu> Launchpad bug 1491781 in Snappy "apt leftovers in Snappy (cron)" [Undecided,New]
<ogra_> thanks !
<mvip> np
<ogra_> oh my ... rsyslog jumped from 7.4.4 to 8.12 with the last upload ...
<ogra_> changing *everything*
<ogra_> (1.4MB diff :/ )
<sja_> One more: What about ntp? I think this should be part of core, think about ssl handshakes and so on.
<ogra_> sja_, there are plans for systemd-timesyncd
<ogra_> not sure where we stand with that though
<sja_> ogra_ ok, thanks
<rickspencer3> what should I do if I want to put snappy on my bbb with developer mode, and ssh enabled, and I want to be getting daily updates?
<rickspencer3> i.e. is there such an image, do I have to use udf to make one?
<ogra_> rickspencer3, snappy update should still work
<ogra_> i think we only disable the autopilot
<ogra_> (which you can enable via snappy config for the ubuntu-core package
<ogra_> )
<rickspencer3> ogra_, so, which image should I download, and will ssh and developer mode be set up automatically?
<ogra_> i think our prepared  images all have developer mode enabled (i could be wrong though)
<rickspencer3> ok, I'll try it out
<ogra_> mvo, i see pending changes from you in livecd-rootfs, is it ok to upload that (i need a change to fix the image build failures)
<mvo> ogra_: yeah, go for it
<ogra_> great, thanks
<ogra_> systemd dropped a group ... all images fail :/
<ogra_> and the number of images using the check obviously grew ...
<ogra_> i guess we need to find a better mechanism if that grows even more ... this will eat my whole afternoon
<Chipaca> why do we even ship cron & at?
<mvo> a good question  we probably should not
<beuno> so you can run cron every hour?
<Chipaca> beuno: man systemd.timer
<Mikaela> I prefer to use cron, because it's easier and doesn't require writing two systemd units. cron also runs even when loginctl isn't running for normal users.
<ogra_> mvo, that rm -f dance at the end of 500-move-kernel-to-device-tar.binary starts getting hilarious ...
<mvo> ogra_: :-/
<ogra_> i wonder if we couldnt cover half of it with purging the kernel package and linux-firmware
<ogra_> so only removing the initrd would be left
<Chipaca> Mikaela: but you don't get to write either in snappy world
<Mikaela> I don't understand
<Chipaca> Mikaela: yes
<Chipaca> Mikaela: you say you prefer to use cron
<Chipaca> Mikaela: but you can't
<Chipaca> Mikaela: that is, a snap can't add a crontab entry
<Mikaela> what happened to "crontab -e"?
<ogra_> not oable by a snap unless the snap ships cron inside (and has that pointing to SNAP_APP_DATA_DIR for the crontab)
<ogra_> *doable
<ogra_> indeed you could do crontab -e via ssh as user/admin (if we made the crontab cache dir writable) ... buut a snap cant
<ogra_> -u
<Mikaela> exaxmple, I have dynamic DNS update script. On normal devices I use https://github.com/Mikaela/scripts/blob/gh-pages/bash/ydns-simple#L12 on my phone I have to use the ydns-simple.* from https://github.com/Mikaela/shell-things/tree/master/etc/systemd/system/sailfish
<Mikaela> I wasn't thinking about packages, but user putting their task to crontab
<Mikaela> at I have never used though
<Chipaca> Mikaela: but how would the user have ydns?
<Mikaela> by curling it as from what I understood it's still possible to run scripts and compile outside of snaps
<Chipaca> Mikaela: you don't have curl, you don't have dig
<Chipaca> Mikaela: you don't have wget
<Mikaela> copy-paste to vi?
<ogra_> you would do it via the ydns.mikaela snap :) which shipd a script "set-ydns-timer"  and sets the timers inside the snap env
<ogra_> *ships
<ogra_> (and inside your snap you can have curl,wget,dig ...
<ogra_> )
<Mikaela> and the script would have to be edited to take the user details from external file
<Chipaca> Mikaela: my point was that your "ydns-simple" script tries to use tools that are not present on a snappy core system
<Mikaela> I see
<Chipaca> Mikaela: cron is the least of your troubles
<ogra_> right, you can only do it inside a snap
<Chipaca> Mikaela: a snappy core system is (or tries to be) *very* stripped down
<ogra_> might even get rid of bash at some point
<Chipaca> yep
<Chipaca> but not openssl, hopefully :)
<Mikaela> the very doesn't seem to be enough emphatized
<Chipaca> and ydns-simple doesn't set -e, so it'll be fun
<ogra_> snappy core = systemd, the snappy binary, HW enablement and all the glue needed to make these three work
<ogra_> everything else is a snap on top of this
<Chipaca> exactly. Everything not in that list is either exceptional (openssl), POSIXish (grep), or we-haven't-gotten-around-to-nuking-it
<Chipaca> python3, for example
<Chipaca> perl, i hope
<Chipaca> awk, maybe
<Mikaela> how about openssh-server?
<Chipaca> what about it?
<ogra_> thats indeed part of developer mode ...
<Mikaela> so it hasn't disappeared anywhere
<Chipaca> Mikaela: but it's not there (or at least, not running) without --developer-mode
<Mikaela> I see
<ogra_> new wily image building
 * ogra_ hopes the changes were enough to make it build now 
<Mikaela> rolling/edge again seems to timeout with "vagrant up"
<Chipaca> Mikaela: where?
<Mikaela> % vagrant init http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/core-edge-amd64-vagrant.box && vagrant up
<Chipaca> Mikaela: do you get any logs?
<Mikaela> moment
<Mikaela> http://paste.ubuntu.com/12263034/
<Mikaela> the stable works
<Chipaca> ogra_: is that a you thing ^?
<elopio> ogra_: or somebody, how can I pass the debug boot option to the kernel with kvm ?
<mvo> elopio: do you have kvm in front of you are you mean in the lap?
<mvo> elopio: if its a one off thing you can go into the grub menu and append "systemd.log_level=debug" (or "debug" if you want the kernel debug)
<elopio> mvo: so, I can unpack the img and edit the grub conf, right?
<mvo> elopio: yes, that works too
<mvo> elopio: whats the use-case? I wonder if we should provide something easier, we have no esasy way right now to extend the grub cmdline
<elopio> mvo: how do I enter grub manually, to give it a try first?
<mvo> elopio: kvm -m 1500 snappy.img should show you a grub boot menu for 3s, there you can do the usualy "hit e for edit" dance
<elopio> mvo: just playing with the options of initramfs. With debug, it says it will write a file with all the shell calls it makes.
<mvo> elopio: aha, I see
<ogra_> Chipaca, no idea, looks like --enable-ssh or --developer-mode was missing when the image was created ... i never used any cloud stuff
<ogra_> sigh, seems livecd-rootfs wasnt in the wily archive when i started the image build
 * ogra_ tries again, it should have migrated now
<Chipaca> rsalveti: who builds the cloud stuff, ie http://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/ ?
<Chipaca> rsalveti: seems something is broken :)
<rsalveti> utlemming: ^
<ogra_> \o/
<ogra_> finally !
<ogra_> images are building again
<elopio> ogra_, mvo: I can go set the debug option in image #141. For some reason, in #159 it doesn't work.
<ogra_> how do you set it ?
<ogra_> just adding "debug" on the cmdline in grub.cfg ?
<elopio> ogra_: I go to grub and add debug to the linux line.
<ogra_> ah, interactively
<elopio> ogra_: yes.
<mvo> elopio: you don't get debug and it works otherwise? or it fails in a bigger way?
<elopio> mvo: I don't get the /dev/.initramfs/initramfs.debug file.
<elopio> but I think I see the boot printing a lot more info, let me confirm that.
<ogra_> hmm
<ogra_> elopio, are you sure it is /dev not /run/initramfs/ ?
<ogra_> should be the latter
<elopio> ah, so in 141 it's in /dev and in 159 is in /run
<ogra_> init:		exec >/run/initramfs/initramfs.debug 2>&1
<ogra_> thats what grep gets me in initramfs-tools
<elopio> ok, this doesn't work for us anyway because it only prints Running /scripts/init-premount. It doesn't print what the premount does.
<ogra_> well, there is only one script in premount (the resize) and that writes its own log in /run/initramfs
<elopio> ogra_: I only see another file in /run/initramfs, fsck-writable. How do I get that resize log?
<ogra_> it gets only written if it resizes
<ogra_> else the script is a no-op
<ogra_> you need to have the writable partition leave 10% free space, else it wont kick off
<elopio> good, let me check on the cloud.
<ogra_> free= unpatitioned
<elopio> ogra_: I found something like this to check the free %: sudo parted /dev/mmcblk0 unit % print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
<ogra_> i usually just dd 1GB to the end of the kvm image ...
<elopio> but I'm wondering, how can I know the right /dev name for the disk I want?
<ogra_> findfs LABEL=writable
<elopio> ogra_: but that gives me the partition. I need to strip the partition number, which sometimes is #, sometimes is p#.
<ogra_> also if you want to look at the code ... boot the VM ... look at /usr/share/initramfs-tools/scripts/local-premount/resize
<elopio> I wanted a magic command that tells me the disk where a partition is.
<ogra_> there is no magic command sadly ... there is some magic parsing sysfs
<ogra_> line 25-27
<ogra_> in the above script
<elopio> ok, let me play with that.
<elopio> too much shell for me today :)
<ogra_> err, i was looking at the wrong versioon ... might not be 25-27
<ogra_> ah, 26-28 in the actual code :)
<ogra_> writable_part="$(findfs LABEL=writable)"
<ogra_> syspath="$(dirname $(realpath /sys/class/block/$(basename $writable_part)))"
<ogra_> device="$(realpath /dev/block/$(cat $syspath/dev))"
<ogra_> partition=$(cat $syspath/$(basename $writable_part)/partition)
<elopio> ogra_: I'm looking at the source branch, but yes, I found it.
<ogra_> yeah, i was looking at a local copy ...
<elopio> ogra_: what happens if I don't want my partition to be resized? Like I flash my sd card with snappy, and I'm leaving the last part of the card for something else.
<ogra_> elopio, you cant prevent it currently
<Chipaca> mvo: i can haz review of https://code.launchpad.net/~chipaca/snappy/logs/+merge/270048 ?
<ogra_> elopio, the code is also still far from ideal ... instead of re-writing the GPT from scratch parted should just fix it and resize ... that will all need more love later
<mvo> Chipaca: sure thing
<elopio> ogra_: I'm finding initramfs really cool, and your hack to do the resize is nice too. And well, it seems to work.
<ogra_> well, until you lose power in the middle of rewriting the GPT :)
<ogra_> then you completely lost
<ogra_> for doing it proper we'll need bug 1490608 fixed at some point
<ubottu> bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] https://launchpad.net/bugs/1490608
<elopio> um, that sounds ugly.
<ogra_> so it takes a nanosecond instead of two seconds ...
<ogra_> keeping the potential breakage window smaller and being less intrusive
<ogra_> effectively it should be just an option i can give when calling "parted resizepart" so that GPT doesnt need its own finction
<ogra_> *function
<ogra_> its a compromise :)
<ogra_> until we can have the real thing
<elopio> ogra_: and can you fix the gpt if you find it corrupted on boot?
<ogra_> elopio, parted can ... it just cant do it from a script
<ogra_> GPT stores a backup of the table at the end of the disk usually
<ogra_> if you now write the image to a bigger disk that backup doesnt align
<ogra_> its a simple copy to the right place ...
<elopio> I get it.
<ogra_> but since it cant do it scripted currently i had to competely re-write the GPT for now
<ogra_> this is not to stay :)
<ogra_> (it is a nice hack ... but has potential for breakage in it if it dies during re-writing)
<ogra_> (though the timing of the dieing needs to be prefect to actually break it ...  the window is very small ... like 1sec or even less)
<elopio> ogra_: so tell me if this makes sense:
<elopio> 1. add a test to the current snappy integration suite to check with parted that the free space at the end is less than 10%.
<elopio> 2. Make an image with less than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that nothing was resized.
<elopio> 3. Make an image with gpt and more than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that the free space at the end is less than 10%.
<elopio> 4. Make an image with mbr and more than 10% at the end, boot it on kvm with this initramfs-tools-ubuntu-core in -initrd and check that the free space at the end is less than 10%.
<ogra_> elopio, for 2:
<ogra_> dd oflag=append conv=notrunc if=/dev/zero of=kvm-rolling.img bs=1MB count=1000
<ogra_> thats what i use for testing
<ogra_> appends 1GB
<ogra_> i'm not sure hwo you want to achieve 4 ... that would need hackery inside ubuntu-device-flash
<ogra_> since the partition table type is hardcoded per arch (x86 = GPT ... arm = mbr)
<elopio> I had no idea how to achieve 2-4. That was the next step after defining the tests :)
<ogra_> the list looks fine ... but 4 will likely mean to test on armhf
<elopio> ogra_: do we need a snappy image for 2-4? Can't we just prepare a disk, throw it to kvm and check the prints during initramfs?
<elopio> we don't need to check that it actually boots. Just that the premount worked.
<ogra_> hmm, you need a partition labeled "writable" beyond that it should just work, yeah
<elopio> well, it would be a lot nicer if we could run parted to do the check, not just check the prints.
<elopio> maybe, we can use break=boot, and do the check there.
<ogra_> sure, you can just run parted after the resize has run
<elopio> ogra_: as you can see, I'm just throwing everything I read last night. Please tell me if I'm giving stupid options here.
<ogra_> you could do that from a local-bottom script even ...
<ogra_> no stupid options here :)
<elopio> I have no idea what a local-bottom script is.
<ogra_> the same thing as a local-premount script just run later :)
<elopio> ah, right.
<ogra_> initramfs starts /init (the script) ... that processes all the subdirs under scripts/ at certain points
<ogra_> so if you want to verify something you could just create a local-bottom subdir and dump your check script in
<elopio> ogra_: ahhh, that's smart.
<elopio> I like that.
<ogra_> initramfs-tools is super flexible :)
<elopio> ogra_: ok, so what I'm missing here is how to create the disk for the .img to use with kvm. Any pointers for that?
<ogra_> well, all you need is a writable partition i think
<ogra_> depends if you actually want to boot or if just dumping the info about the resize is enough
<ogra_> else you'd also need system-a at least
<elopio> I think i'd prefer to avoid booting.
<elopio> on this bottom script, exit with != 0 if the free space is more than 10%. I can do that by just copying things from your resize script.
<elopio> I'm not sure how to signal sucess.
<elopio> I'll just start. ogra_: I'll make cards for the four tests pasting our discussion in there. Feel free to add suggestions there.
<ogra_> cool, thanks
<tedg> Okay, this isn't going to work. I think that pip is going to have to be its own plugin. Refactor after lunch.
#snappy 2015-09-04
<eikeon> Anyone running an ubuntu core AMI on EC2 and know how to get it to recognize a bigger volume. I end up with the same size filesystems regardless of how big I make the root volume at EC2 launch time
<miken> Small fix to the snapcraft tutorial: https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
<fgimenez> good morning
<mvo> hey fgimenez, good morning
<fgimenez> hi mvo!
<dholbach> good morning
<miken> Hi people o/ Small MP with some updates for the tutorial: https://code.launchpad.net/~michael.nelson/snapcraft/fix-golang-tutorial-to-match-changes-from-r132/+merge/270131
<miken> Also, is the daily-build of snapcraft manually triggered? Current one in the PPA is quite a way back from trunk (r135)
<Chipaca> mvo: I've not blocked your two new-stuff-in-the-yaml branches with a needs-fixing just because i don't know if they're urgent or not
<Chipaca> mvo: if they're urgent, we can easily land docs after
<Chipaca> mvo: otherwise i'd be happier if the docs got updated together with the code
<mvo> Chipaca: yeah, good point, thanks a lot. I am also not sure how urgent it is, but docs are pretty big so I will that,  thanks for the prompt review
<Chipaca> mvo: docs should be fairly straightforward also :)
<mvo> yep
<Chipaca> if you find yourself writing "chapter 2: of how the service begot its socket, and the events that unfolded henceforth", start over
<Chipaca> thenceforth?
<Chipaca> thenceforth is a word.
 * mvo is stunned by that and looks it up
<mvo> Chipaca: reading the classics lately :) ?
<Chipaca> xchat doesn't underline it, and it underlines "xchat" :)
<Chipaca> mvo: lately? no. But I read Munchausen as a kid, and it stays with ya
<mvo> hihi
<Chipaca> ("thenceforth" makes sense, given "henceforth" is from here, and not from there)
<Chipaca> (which is why you should be suspicious of it; nothing in english makes sense and isn't out to stab you)
<JamesTait> Good morning all; happy Friday, and happy Bring Your Manners To Work Day! ð
 * Chipaca either always brings what manners he has
<Chipaca> s/either//
<mvo> kickinz1|lunch: hey, I'm working on http://paste.ubuntu.com/12117177/ right now and would like to ask if we could make "socket: yes/no implicit, i.e. if there is a listen-stream we always use socket: yes. or is there a use-case were we have a socket without a listen-stream?
<mvo> kickinz1|lunch: plus I would like to rename "SocketUser" to socket-user to make it more yamlish
<mvo> kickinz1|lunch: sounds ok?
<Chipaca> mvo: ping
<mvo> Chipaca: pong
<Chipaca> mvo: hiya. I just noticed, in the socket branch, that you're not using generate*FileName in two places where you could. Is it because there's not much to it and you've had to prune the directory off it anyway? Or just because you didn't notice?
<mvo> Chipaca: I think I did not noticed, mind to point to the lines? maybe I did notice and forgot about it too, but in any case worth a comment at least (or a fixing)
<Chipaca> mvo: inline
<mvo> ta
<Chipaca> i'd already half-asked inline before pinging you :)
<ogra_> mvo, so i was looking around a bit ... we should be able to call genext2fs as last step in livecd-rootfs to actually generate .img files of the rootfs and publich them on cdimage ... that way you would only have to pick them up from there without tinkering to generate a rootfs snap
<ogra_> then we could just install them wherever we like ... (system-boot or writable or wherever)
<mvo> ogra_: sounds reasonable, we will have to add the meta/* stuff to it as well plus it will have to be squashfs
<ogra_> why, we could start with simple ext2
<mvo> ogra_: I made some progress yesterday on that
<ogra_> ah, ok
<mvo> ogra_: if it does not work out, I'm happy to go back to ext2 of course
<ogra_> right ...
<Chipaca> mvo: are you going to wait for a review from kickinz1|lunch ?
<mvo> Chipaca: probably not, I guess he is busy, we can probably land
<mvo> ogra_: in case you are fiddling with the image building, I think we need squashfs-tools soon :)
<ogra_> mvo, thats a dep of livecd-rootfs i think
<ogra_> will need some code changes to produce img files though
<ogra_> unless you want to keep the tarballs for porters or whatnot and do the squashing at snap build time
<mvo> ogra_: I have a script that builds images out of the cdimage artifacts
<mvo> ogra_: I don't mind either way really
<ogra_> i think keeping the tarball makes it easier for others to inspect the rootfs
<mvo> ogra_: I guess best to discuss with the store guys what the most sensible process for this is
<ogra_> so if you already have a script. lets use that
<mvo> ogra_: yeah, sounds good to me to keep it
 * ogra_ hes to check if the RPi kernel actually has squashfs at all 
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ sudo modprobe squashfs
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat /proc/filesystems |grep squash
<ogra_> 	squashfs
<ogra_> ok, that was quick :)
<mvo> yay!
<ogra_> well, i have a complteley module-less initrd in the device tarball atm ...
<ogra_> need to adjust that
<mvo> ogra_: could you simpliy add it to the kernel ?
<ogra_> mvo, paolo could ... ppisati ^^^
<ogra_> ppisati, we need squashfs built into the kernel
<mvo> ogra_: its not going to happen before the weekend, no worries :) I'm just making better progress right now than I had hoped, but that can chnage quickly on the next road-block
<ogra_> right, i want to be prepared on all devices for it :)
<ppisati> ogra_: k, i'll add it to -generic, v/raspi2 and w/raspy2
<ogra_> v and w ?
<ppisati> ogra_: vivid and wily
<ogra_> ah :)
<ppisati> ogra_: 3.19 and 4.2
<ogra_> oh, right, we have two kernels now
 * ogra_ will need to adjust his build script too 
<elopio> ogra_: can you please review https://code.launchpad.net/~elopio/snappy/test_free_space/+merge/270137 ?
<Chipaca> sergiusens: ping
<ogra_> elopio, as far as my go knowledge goes it looks ok
<ogra_> (thats not very far, mind you :) )
<sergiusens> Chipaca, pong
<elopio> ogra_: that's good enough, thanks :)
 * sergiusens was having issues with irssi and freenode
 * sergiusens said, hell it is Friday and installed xchat
<ogra_> +1
<ogra_> xchart FTW
<ogra_> *xchat
<tedg> sergiusens: Did my long rambling e-mail about ubuntu packages make any sense?
<sergiusens> tedg, heh, I'm trying to figure it out, I think I understood the TODOs and the WANTs
<tedg> sergiusens: K :-)
<sergiusens> tedg, let me get back to you in a bit
<elopio> ogra_: when I run parted on the bbb it tells me that there's one block not used.
<elopio> is that a bug, or is that ok?
<ogra_> hmm, do you have the exact output ?
<ogra_> it should be fine i think
<elopio> Warning: Not all of the space available to /dev/vda appears to be used, you can
<elopio> fix the GPT to use all of the space (an extra 1 blocks) or continue with the
<elopio> current setting?
<elopio> ogra_: ^
<ogra_> elopio, huh ? thats BBB ??
<elopio> ogra_: sorry, no, kvm.
<ogra_> ah
<ogra_> well, doesn it resize fine beyond that ?
<elopio> ogra_: it has 0.04% free at the end, so my test passes.
<elopio> I just have to ignore the stderr. What I'm asking is if that's ok to ignore.
<ogra_> as long as there is a proper filesystem on disk and it resized, yeah ignore it for now ... the whole GPT handling will change anyway
<elopio> ack.
<sergiusens> ogra_, elopio that error bust me too when doing the uflash PoC with the recvory image
<ogra_> sergiusens, even when not resized ?
<ogra_> hmm, livecd-rootfs doesnt have anything about subgid subuid ...
<ogra_> sergiusens, aha ... bug 1475749 ... seems slangasek already fixed it in wily
<ubottu> bug 1475749 in Canonical System Image "usermod --add-subuids fails for users not in /etc/passwd" [High,New] https://launchpad.net/bugs/1475749
<sergiusens> ogra_, even when no resized (just when adding a partiton on top of something that already exists)
<ogra_> sergiusens, ok, thats a general issue with the kvm GPT then ... funny that i dont see it here
<elopio> happy anniversary dholbach!
<ogra_> not yet :P
<dholbach> thanks elopio :)
<ogra_> but yeah, welcome to the ten-year-club dholbach :)
<dholbach> thanks ogra_ :)
<fgimenez> nice weekend everyone o/
<slangasek> ogra_: bug #1475749> and in vivid-proposed, if you want to verify the fix
<nothal> Bug #1475749: usermod --add-subuids fails for users not in /etc/passwd <Canonical System Image:New> <shadow (Ubuntu Vivid):Fix Committed> <http://launchpad.net/bugs/1475749>
<ubottu> bug 1475749 in Canonical System Image "usermod --add-subuids fails for users not in /etc/passwd" [High,New] https://launchpad.net/bugs/1475749
<ogra_> slangasek, thanks, will do
 * Chipaca -> mostly EOW
<sergiusens> ted, so back to stage-packages, either we do it like build-deps but put them in $TOPDIR/stage or grab them before each pull and it goes into $TOP/parts/$part/installdir (and conflicts managed with the filtering thing that needs to get done)
<sergiusens> mvo, still around? if yes, do you know how the conflict resolution rules are for that 'packages' entry?
<mvo> sergiusens: what packages entry exactly?
<sergiusens> mvo, in the spec, at the very end
<tedg> sergiusens: Sorry, I missed your message. Someone else already has "ted" on Freenode :-(
<tedg> sergiusens: I like the idea of letting dpkg do the filtering, I think it knows more about what can overlap and what can't.
<tedg> Seems like they haven't used it in 9 weeks thoughâ¦ getting close.
<sergiusens> tedg, I'll need to take that one level higher the decision making process; for now pull/unpack are done before pull now
<sergiusens> tedg, I'm going to see if I can make the plugin stage-packages part of the yaml in a clean way (maybe it will end up being what you want
<tedg> sergiusens: Makes sense
<sergiusens> tedg, do you have code for the pip plugin somewhere?
<tedg> sergiusens: Pushed to here: lp:~ted/snapcraft/python-pip
<tedg> Might be kinda hacked though
<tedg> I was screwing with it trying to get it to work.
<sergiusens> tedg, no worries
<sergiusens> tedg, why don't you call pip install directly?
<sergiusens> tedg, and another question, why not just do pip install from the build stage?
<tedg> sergiusens: You mean by importing the module?
<sergiusens> tedg, yeah
<tedg> sergiusens: In that case it was a python2 vs 3 thing.
<tedg> sergiusens: I was trying to keep things in pull for the LP builders.
<tedg> sergiusens: I think we'd also have to have the module in the host system to include it? No?
<sergiusens> tedg, for the lp builders, the lifecycle rolls over the comple cycle for a part before going to the next, so I'm not sure we can separate this at all without drastic changes
<sergiusens> tedg and I don't grep that last line about includes :-)
<tedg> sergiusens: I don't think it goes over the complete cycle if you just do "snapcraft pull" as a command, no?
<tedg> sergiusens: I think it only does the complete cycle for each with all.
<tedg> sergiusens: I was thinking that you don't want to install pip into the host system. But I guess you could, except for the potential python version mismatch.
<sergiusens> tedg, ah, good point on calling 'snapcraft pull'
<sergiusens> tedg, yeah, let's not install pip on the host :-)
<sergiusens> tedg, but depending on python-pip brings in pip into the part
<tedg> sergiusens: Seems like we need a way to specify build-deps vs. runtime deps I guess.
<tedg> sergiusens: I could, for instance, have a python build system like Waf but not want python in my snap.
<sergiusens> tedg, isn't that what filesets is for?
<sergiusens> filesets/stage and filesets/snap respectively
<tedg> sergiusens: Yeah, but then if you're talking about an ubuntu package you'd need to know all the files in the package.
<tedg> sergiusens: We could perhaps auto-populate that.
<sergiusens> tedg, I'd exclude by default, then again; the staging terminology in snapcraft is confusing
<sergiusens> there are two stages in a stage it seems; the part stage and the general stage
<tedg> Huh, I didn't realize that.
<sergiusens> tedg, oh wait, nevermind
<sergiusens> tedg, I had that stuck on my mind for a while and now I self settled it
<tedg> Left brain vs. Right brain. Fight! ;-)
<sergiusens> tedg, btw, this is why I asked about pip 'bin/python2: cannot import name IncompleteRead; 'pip' is a package and cannot be directly executed'
<sergiusens> tedg, and calling pip directly pkg_resources.DistributionNotFound: pip==1.5.6
<tedg> sergiusens: I think that comes from the path issue, you need to be able to call the python2 binary that is installed so that you're using the right pip.
<tedg> sergiusens: The environments weren't quite right for that. I'm not sure if we're going to have to go down to the full virtualenv path. I was hoping to avoid it though. Just to keep things simpler.
<sergiusens> tedg, might be necessary; in any case I think I can say that with my latest MP you are unblocked :-)
<sergiusens> I asked mvo to review the code on Monday as well (and to have him validate it against the spec).
<sergiusens> I'm going to implement the fileset stuff now and table the plugin listing for now; there are some encapsulation and delegation of concern issues there if I want to top level it
<tedg> sergiusens: Cool, I'll update on Monday. Oh, wait, Tuesday :-)
<tedg> sergiusens: Thanks!
#snappy 2016-09-05
<mup> PR snapd#1811 closed: interfaces/builtin: usb serial-port support via udev <Blocked> <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1811>
<mouloud> hello  , how can i know what are the exact parts my snap will need !
<liuxg> does anyone know how to find out whether my bluetooth on my raspberry pi is enabled or not? I want to make use of the bluetooth to find sth.
<OerHeks> rfkill list all # should tell you
<pitti> ogra_: hm, I cannot reproduce this with dnsmasq as server (just followed up to the bug); maybe you can attach your dhcpd config to the bug? can you reproduce this with a VM/container as well, or only with your device?
<mup> PR snapd#1839 closed: interface: network_manager: enable resolvconf <Created by tonyespy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1839>
<dholbach> hey hey
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<dholbach> good to see you're back again! :)
<didrocks> thanks! :-) been a long time with your holidays starting a week before mine! :)
<dholbach> yes :)
<trijntje> Hi all, any devs around that know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930
<mup> Bug #1609930: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
<mvo> ogra_: hey, did you write the images for the pi2 that had the corruption problems with "dd conv=sparse" ?
<mwhudson> morning
<mwhudson> mvo, ogra_: any last minute console-conf / RTM panics?
<mwhudson> i have on my machine here a UI that lets you plug in ESSID / password for wlan but i'm not proposing trying to get that into RTM
<mvo> mwhudson: I had some strange error from the network on the pi2, that console-conf could not connect to the users api endpoint of the store, however I have not investigated further, as the pi2 as more (and bigger) problems currently
<mwhudson> mvo: uh, hm
<Kaleo> mvo, hey you had a failure in https://github.com/snapcore/snapd/pull/1845  TestSignBuildMissingKey.pN58_github_com_snapcore_snapd_cmd_snap_test.SnapSignBuildSuite
<mup> PR snapd#1845: tests: use the real model assertion when creating the core test image <Created by mvo5> <https://github.com/snapcore/snapd/pull/1845>
<Kaleo> mvo, I suppose it was unrelated to your PR, as I'm hitting the same issue locally with another PR
<Kaleo> mvo, how did you get rid of it? :)
<mvo> Kaleo: we noticed some minutes ago and we will debug/fix, just ignore until then, should be quick
<Kaleo> mvo, sweet
<ogra_> mvo, with and without
<ogra_> mwhudson, err, why do you hold that ssid stuff back ? just to land it right after rtm ? (we will need it in any case)
<mwhudson> ogra_: just wanting to avoid last minute breakage
<ogra_> well, that means no dragonboard image then (only wlan)
<mwhudson> ogra_: would you like an image to test?
<mwhudson> well core snap
<ogra_> we dont have a gadget for the dragon yet either ... but sure ... having something ready to test might be good once i got the gadget ...
<ogra_> the vfat corruption klind of held us up
<ogra_> so i didnt get to dragon yet
<mwhudson> shipping is hard :(
<mwhudson> bah, just missed a publisher run :(
<mvo> ogra_: fwiw, I put some info into the fs corruption bug and a tiny reproducer
<ogra_> ah, awesome
<ogra_> well, i'm not sure it is mtools ... afauik for a vfat you also need to align the partition to the block size the vfat has ... i.e. if the vfat has 512 byte blocks, the partition nees to start and end on a pyhsical point thats divisible by 512 bytes
<ogra_> i havent checvked that if we do that
<mvo> ogra_: I pushed a potential fix to my branch
<mvo> ogra_: check the LP page, I will play with the new image now, but its clear that mtools causes havoc, the fs is already corrupted when it finishes
<mwhudson> ogra_: https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot <- latest core snaps there have wifi ui
<mwhudson> in console-conf
<mwhudson> (packages in https://launchpad.net/~canonical-foundations/+archive/ubuntu/ubuntu-image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial)
<ogra_> awesome, thanks ... will test that once i got to roll a new image
<mwhudson> ogra_: np, hope it works, i haven't tested it at all! (the config it produces looks sane but that's as far as i can get)
<mwhudson> qemu seems not to emulate any wlan interfaces
<ogra_> yeah ... i think kvm allows to attach host wlan devices though
<ogra_> mvo, afaik we have working mtools code in debian-cd somewhere
 * ogra_ remembers that we used to run into similar probs back in the arm team days
<mvo> ogra_: working as in not-corrupting?
<ogra_> yes
<mvo> ogra_: its interessting, it seems to be subdir releated or recursive copy
<mvo> ogra_: my reproducer is fine when not using subdirs but I didn't want to sink too much time into finding workarounds
<ogra_> how about if you do the recursion yourself in a shell loop ?
<ogra_> and copy file by file
 * ogra_ found the old code ... http://paste.ubuntu.com/23136465/
<mvo> ogra_: that might work
<ogra_> mkdosfs ... vs mkfs.vfat
<mvo> ogra_: no subdirs no recursive (-s) in that script, I would bet this works fine
<ogra_> yes, but we had to do the 512byte alignment ...
<ogra_> dd if=/dev/zero of="$IMAGE" bs=512 count=0 seek="$IMG_SIZE_BLOCKS" >/dev/null 2>&1
<ogra_> and
<ogra_> VATSTART=$(parted $IMAGE unit B print|grep "^ 1"|awk '{print $2}')
<ogra_> VATSIZE=$(LANG=C fdisk -l ${IMAGE} 2>/dev/null|grep W95 |awk '{print $5}')
<ogra_> though that was using CHS with sfdisk
<trijntje> Hi all, does anyone know about the progress of https://bugs.launchpad.net/snappy/+bug/1609930
<mup> Bug #1609930: Support license acceptance <Snappy:New> <https://launchpad.net/bugs/1609930>
<mwhudson> ogra_: i am horrified to learn that this sort of thing is still a problem in 2016 :(
<ogra_> haha
<mwhudson> ogra_: at least you don't have to deal with the buggy FAT parser in omap3 (?) ROMs?
<ogra_> yeah
<mvo> ogra_: hm, no luck with recursion either
<ogra_> IMAGE_SIZE=$((134217728/512))
<ogra_> mkdosfs -F 32 -C $IMAGE.vfat $IMAGE_SIZE
<ogra_> mvo, ^^^ no fsck errors for me with that ^^^
<mvo> ogra_: oh?
<ogra_> how the heck do i verify it now ... seems i cant loop mount it
<mvo> ogra_: https://pastebin.ubuntu.com/23136501/ I still get that
<mvo> ogra_: I mean, I still get fsck errors wit hthat
<mvo> ogra_: or am I misunderstanding what you suggested?
<ogra_> i'm suggesting to replace line 7
<ogra_> mkdosfs -F 32 -C $IMAGE.vfat $((134217728/512))
<ogra_> try that instead
<mvo> ogra_: aha, mkdosfs
<mvo> ogra_: like this https://pastebin.ubuntu.com/23136505/ ?
<ogra_> well, you want the dd
<ogra_> oh, or not
<ogra_> -C might be enough actually
<mvo> ogra_: I get the same corruption error with the pastebin script
<ogra_> weird, i dont
<ogra_> bah ...
<ogra_> actually naming the image corrently helps :P
<ogra_> *correctly
<mvo> ogra_: oh, fun, it seems racy, I don't get it all the time
<ogra_> heh
<ogra_> mcopy has a-b option ...
<Kaleo> fgimenez, you uploaded test snaps to the store for spread tests. Is that a typical thing to do? can I just upload one myself for my own tests?
<ogra_> b
<ogra_> Batch mode. Optimized for huge recursive copies, but less secure if a crash happens during the copy
<ogra_> hmm, doesnt help either
<Kaleo> morphis, I believe I fixed everything you noted in https://github.com/snapcore/snapd/pull/1775
<mup> PR snapd#1775: interfaces: add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
<Kaleo> morphis, I added a spread test but it depends on a snap that is pending review for publication in the store
<ogra_> mvo, how about using mmd to create dir tree on the target and then iuse mcopy per file
<Kaleo> morphis, can you check that everything is to your liking?
<morphis> Kaleo: will have a look, thanks!
<Kaleo> :)
<fgimenez> Kaleo, hey :) yes, we have a bunch of test snaps uploaded to the store that are used by the snapd spread suite, previously we used snaps currently there (hello-world for instance) but we needed to control the state of these snaps in order to make proper assertions and have reliable results
<mvo> ogra_: https://pastebin.ubuntu.com/23136531/ works 1/2 the time
<fgimenez> Kaleo, these test snaps are owned by the canonical shared account, so that we don't get locked on a specific user
<ogra_> mvo, well, then we just run it twice :P
<mvo> *cough*
 * mvo lunch
<Kaleo> fgimenez, oh good, who can upload with that account?
<ogra_> mvo, hmmm do you call "mdir /" in there ?
<ogra_> err
<ogra_> mmd / i mean
<fgimenez> Kaleo, mvo can help you, and thanks for the test! :) looks great
<Kaleo> fgimenez, :)
<Kaleo> mvo, I would like to upload a test snap to the store
<Kaleo> test-snapd-thumbnailer-consumer
<Kaleo> mvo, http://people.canonical.com/~kaleo/test-snapd-thumbnailer-consumer_1.0_amd64.snap
<Kaleo> mvo, generated from https://github.com/snapcore/snapd/pull/1775
<mup> PR snapd#1775: interfaces: add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
<mvo> Kaleo: did you upload this already under your account? if so we need to talk to nessita. you will need to delete it from your account and I can then upload it to the shared account
<mup> PR snapd#1847 opened: many: discard preserved namespace after removing snap <Created by zyga> <https://github.com/snapcore/snapd/pull/1847>
<Son_Goku> morning
<ogra_> mvo, heh... thats what oi call pragmatic :) ... back to loop mounting
<ogra_> s/oi/i/
<jgdx> getting a build failure, missing a header file that builds fine without snapcraft. The dep is in the build-packages section.
<jgdx> usr/include is missing in stage/. Wut
<davidcalle> stub, hi, can you tell me a bit more about the magic names for license files? Is there somewhere (I guess no doc yet, so in code form maybe) where these are referenced?
<stub> davidcalle: The magic names for license files are mentioned nowhere
<stub> davidcalle: We used to have a way of referencing the license (using license: in snapcraft.yaml). Now we don't.
<davidcalle> stub: ok, I'll let someone invested in re-adding the feature reply then.
<ogra_> pitti, so looking at the leases file excerpt (attached to the bug), the uid stuff looks pretty inconsistent ...
<ogra_> what creates that uid string ? networkd ?
<pitti> ogra_: yes, that's a "DUID" (https://tools.ietf.org/html/rfc3315#section-9)
<pitti> ogra_: by default it's generated from /etc/machine-id
<ogra_> well, the non netplan images do not send it
<pitti> right, isc-dhcp sends the  hostname
<ogra_> see the top of the leases excerpt ...
<pitti> we can also set ClientIdentifier=mac
<pitti> (this is what isc-dhcp does, I suppose)
<ogra_> we should probably do that then
<pitti> ogra_: the question is, why does your /etc/machine-id change?
<ogra_> hmm
<ogra_> i wouldnt know anything that explicitly deletes it
<ogra_> in our boot process
<Kaleo> mvo, I had uploaded it but deleted it right away
<pitti> ogra_: can you compare it between two boots, when the IP changes?
<ogra_> sure
<pitti> ogra_: i. e. I'm not too fussed about setting ClientIdentifier=mac, but /etc/machine-id changing sounds bad for many other reasons
<ogra_> definitely ...
<ogra_> it normally doesnt change .... but perhaps something in the way we now create images using ubuntu-image makes do so
<Kaleo> pitti, is autopkgtest compatible with snaps?
<pitti> ogra_: could be that /etc/machine-id is not writable or not a persistent file at all (then a random one is generated on boot and bind-mounted)
<ogra_> it is writeable and our handling of writable files hasnt changed
<mvo> Kaleo: yeah, now we need nessita, she will need to delte it from your account in the db so that I can reupload it, the name is now claimed :)
<pitti> Kaleo: no, ATM it only knows about dsc and click; until the last CDO sprint at least there was no test specification for snaps
<mvo> Kaleo: we will also need to change the hash, but unsquash/resquash is hopefully enough for this
<nessita> mvo, hi! I'm here
<nessita> what snap?
<Kaleo> nessita, can you delete test-snapd-thumbnailer-consumer ?
<Kaleo> nessita, from my account fboucault
<nessita> Kaleo, one sec
<morphis> niemeyer: ping
<niemeyer> morphis: Heya
<morphis> niemeyer: hope you had a good weekend :-)
<zyga> morphis: hey
<tvoss> mvo: hey there, any thoughts on my comment in https://github.com/snapcore/snapd/pull/1785
<mup> PR snapd#1785: many: add vendoring of dependencies by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/1785>
<morphis> zyga: hey!
<morphis> niemeyer: any reason why the hidraw and udisks2 interface PRs are not merged yet?
<niemeyer> morphis: Yeah, it was good, thanks
<niemeyer> morphis: hidraw we probably just need to rename it, udisks2 I didn't manage to get to it
<niemeyer> morphis: Let's speak after the standup please
<morphis> niemeyer: ok
<nessita> Kaleo, do you have a link t your package? I can't find it
<zyga> morphis: did you guys do the /media mount propagation change yet?
<morphis> zyga: no, jdstrand and tyhicks are working on that
<morphis> zyga: the patch ssweeny had didn't work so we followed up with jdstrand and tyhicks to get a solution in time for RTM
<zyga> morphis: they are off today
<zyga> morphis: and RTPM is today, right?
<morphis> zyga: plan was actually ( ssweeny correct me if I am wrong) that a patch is ready on tuedsay
<morphis> zyga: or better said, we provide a fix for this after RTM
<Kaleo> nessita, I deleted it from the store's interface
<zyga> morphis: I see, ok
<Kaleo> nessita, it was at https://myapps.developer.ubuntu.com/dev/click-apps/5861/
<nessita> Kaleo, so that's enough
<Kaleo> nessita, oh ok
<Kaleo> mvo, ^
<nessita> Kaleo, is gone :-)
<Kaleo> :)
<mvo> Kaleo_: you should have mail
<Kaleo_> mvo, I do :)
<Kaleo_> mvo, what's the next step?
<mvo> Kaleo_: in a meeting right now, lets talk in ~15min
<Kaleo_> k
<mvo> pitti: it looks like the latest images have no entries in /etc/resolv.conf for the nameserver (at least in kvm) with netplan, a second dhclient eth0 fixes it. is that something known? or can I do anything to debug this?
<zyga> morphis: hey, niemeyer asked me to ensure that udisks2 gets merged only if it makes sense (snap-confine makes it really work as expected)
<Kaleo_> pitti, thanks
<morphis> zyga: ok, for that we miss the patch jdstrand and tyhicks are working on
<pitti> mvo: not known, but confirmed in a container
<pitti> mvo: is that actually breaking anything?
<zyga> morphis: do you know if this will be ready tomorrow?
<zyga> morphis: I think gustavo would rather not merge the interface before we merge this change
<pitti> mvo: oh -- do you have libnss-resolve installed? I suppose not
<morphis> zyga: https://paste.ubuntu.com/23137062/ is what I got from ssweeny, jdstrand and tyhicks
<pitti> mvo: it's in ubuntu-standard, but maybe that isn't installed in snappy images; where would be the place to seed it?
<mup> PR snapd#1848 opened: snap: ensure that plug and slot names are unique <Created by zyga> <https://github.com/snapcore/snapd/pull/1848>
<ogra_> pitti, we dont even seed ubuntu-minimal ;)
<ogra_> pitti, livecd-rootfs in the image PPA is the place for adding a package
<ogra_> pitti, but why not just make it a dependency of nplan if it needs it
<pitti> so that, or making it a dependency of netplan
<pitti> well, it's not conceptually a netplan thing
<pitti> would be the same with ifupdown or NM, we changed the resolver a while ago
<ogra_> ogra@anubis:~/datengrab/devel/branches/ubuntu-image-mvo$ sudo snap install ubuntu-image_0.5+mvo1_amd64.snap --devmode --force-dangerous
<ogra_> [sudo] Passwort fÃ¼r ogra:
<ogra_> error: unknown flag `force-dangerous'
<ogra_> GRRR
<ogra_> snapd ! stop changing every day !
<mvo> ogra_: today just use "--dangerous"
<ogra_> mvo, well --devmode is enough
<mvo> ogra_: tomorrow it will "--might-exlode"
<ogra_> haha
<mvo> ogra_: aha, yeah, devmode adds it implicitely
<ogra_> yep
<mvo> pitti: thats fine, I can add it to livecdrotootffs
<ogra_> ffs ? heh
 * ogra_ notes mvo had a clown for breakfast :D
<popey> pbek: did you know qownnotes in the store doesn't launch?
<popey> pbek: alan@gort:~$ /snap/bin/qownnotes
<popey> /snap/qownnotes/149/bin/desktop-launch: line 144: /home/alan/usr/bin/QOwnNotes: No such file or directory
<pitti> mvo: still thinking where to put it -- container images have the same issue
<pitti> (containers with netplan, I mean -- ifupdown calls resolvconf by itself)
<mvo> pitti: I will add it manually for now to unblock us
<popey> pbek: running it manually works, like this:- $ /snap/qownnotes/149/bin/desktop-launch /snap/qownnotes/149/usr/bin/QOwnNotes
<pitti> mvo: ok; that should work, still doesn't feel completely right
<ogra_> oh man ...
<mvo> ogra_: one thing for classic, without ubuntu we have no password for the local sudo user anymore  so our sudo classic env needs a nopasswd
<mvo> pitti: ok, once you have a different solution, just let me know
 * ogra_ broke with his rule to never post political or religious statements on social media ... i should have known what happens :/
<pitti> ogra_: Je suis McPomm?
<ogra_> pitti, yeah
<ogra_> mvo, did you see my PR for classic-snap ?
<ogra_> (should perhaps be a bind-mount though ... but cp felt safer that moment)
<mvo> ogra_: no, looking now
<ogra_> :)
<ogra_> fixes sudo
<mvo> ogra_: does it? and its in the store already?
<ogra_> yes
<ogra_> happy to revert if you want to bind mount instead though
<mvo> ogra_: hm, dosn't for me then :/
<mvo> ogra_: no, copy is fine
<ogra_> the issue is that the console-conf user isnt in the extrausers db
<mvo> ogra_: and I'm not in the sudo group
<ogra_> thats fine
<ogra_> there should be a sudoers.d snippet for the user
<mvo> ogra_: right, not in classic
<ogra_> we cant change the sudo group since it needs to be in the readonly /etc/group
<ogra_> oh, then we probably also need to copy the snippet
<mvo> ogra_: yeah
<niemeyer> morphis, zyga: To be clear, I'd like to hold the interface if it _only_ makes any sense once the snap-confine change goes in
<ogra_> funny, why did that work for me
<mvo> ogra_: I have no idea :)
<ogra_> hmm, wasnt cyphermox' cloud-init stuff merged into u-i ? ... i still see the cloud-init mess on boot
<niemeyer> morphis, zyga: Because snap-confine is in that tricky place right now where we have several non-trivial changes in progress, and I can't quite see which them will make it into RTM
<zyga> niemeyer: I think that is the case today, morphis what do you think?
<niemeyer> Having an interface that doesn't work at all for its intended purpose on RTM won't be very helpful
<ogra_> pitti, so you are right, i get a new machine-id for whatever reason
<ogra_> (sadly a reboot takes over 10min thanks to cloud-init on the pi currently ... no fun to test/debug)
<ogra_> mvo, fix for u-i looks good ... third reboot and my image is still fine
<mvo> ogra_: yay
 * ogra_ shakes head
<ogra_> [   47.485605] cloud-init[2662]: 2016-09-05 14:00:33,698 - util.py[WARNING]: did not find either path /sys/class/dmi/id or dmidecode command
<ogra_> that was fixed in all distro tool using dmidecode like 5 years ago for arm ...
<ogra_> i wish c-i would make use of existing tools, that would really save having to fix things over and over
<ogra_> s/tool/tools/
<mvo> ogra_: you will like the most recent livecd-rootfs upload ;)
 * ogra_ checks
 * ogra_ hugs mvo wildly 
<ogra_> mvo, so that ubuntu-core -> core rename ... did i understand niemeyer correctly that only the handling in snapd is needed for RTM and we'll do the actual switch later ?
<ogra_> also, what happens with the actual product name for the images
<mvo> ogra_: this is still under investigation, maybe nothing for rtm because its too risky
<ogra_> (i.e. the download area on cdimage)
<ogra_> iirc slangasek and sabdfl both agreed the product name should be kept for the actual img files (especially in the light that we renamed ubuntu-core to ubuntu-base exactly for this)
<ogra_> (renamed -> the old core tarballs that is)
 * ogra_ will just wait til the investigation is done then :)
<ogra_> hmm, the last snapd build in the PPA failed again on arm64 ...
<mvo> ogra_: I upload a fix for classic with the sudoers.d now (unless you are already on it)
<ogra_> nope, still poking around on the pi2 atm ... so many bugs :/
<ogra_> ARGH !
<ogra_> ogra@localhost:~$ sudo snap install classic --edge --devmode
<ogra_> [-] Make snap "ubuntu-core" (354) available to the system
<ogra_> ...
<ogra_> damn ... forgot about the broken setup ... now it rolled me back to the last stable ubuntu-core
<ogra_> ogra@localhost:~$ sudo snap install ubuntu-core --edge
<ogra_> error: cannot install "ubuntu-core": snap "ubuntu-core" already installed
<ogra_> evilo !
<ogra_> about time that we get the model assertion
<mvo> ogra_: we have it, I hope to be able to create an image today with it for the pi2, waiting for the cloud-init change to lnad first
<ogra_> mvwell, there is a lot more ... like the machine-id changing every boot
<ogra_> mvo, ^^
<mvo> ogra_: aha, and I wanted to enable classic for multiple sessions, right now iirc we restrict to one but I think thats not needed
<ogra_> and for dragonboard we probably need the console-conf with wlan support
<mvo> ogra_: it does?
<ogra_> mvo, yeah
<mvo> meh
<mvo> ogra_: do you happen to know why?
<ogra_> https://bugs.launchpad.net/snappy/+bug/1619721
<mup> Bug #1619721: IP changes with every reboot  <Snappy:New> <nplan (Ubuntu):Incomplete> <https://launchpad.net/bugs/1619721>
<ogra_> not yet ... and a reboot taking 10min doesnt really help ... so i'm waiting for the cloud-init drop here too
<mvo> ogra_: machine-id or IP?
<pbek> popey: thank you for reporting, I couldn't even test for a while because I get: "multiple nvidia drivers detected, this is not supported"
<mvo> ogra_: heh :)
<ogra_> one is a result of the other
<mvo> ogra_: ahhhh
<ogra_> netplan transfers the machine-id now
<ogra_> pbek, Bug 1615248
<mup> Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248>
<ogra_> there is a workaround
<pbek> ogra_: thank you, I know. but I fear removing my envidia directories because currently two are in use...
<ogra_> in use ?
<ogra_> how can there be more than one in use ? :)
<mvo> ogra_: ordering again? dbus-uuidgen running before the writable-paths are mounted maybe?
<pbek> I don't know
<ogra_> if you tend to switch back and forth between two drivers, just rename the dir for the one not in use ...
<ogra_> there is no way that both are in use on a single boot
<ogra_> [  OK  ] Started Snappy daemon.
<ogra_> [  OK  ] Stopped Snappy daemon.
<ogra_> [FAILED] Failed to start Snappy daemon.
<ogra_> See 'systemctl status snapd.service' for details.
<ogra_> oh, lovely
<ogra_> thats what you get when being auto-rolled-back by 20 revisions :P
<popey> pbek: happy to test any time.
<pbek> ogra_: I put my heart into it and moved some away ;)
<ogra_> yeah, just rename them, worst case you can move them back
<pbek> popey: thanks a lot, that's my current desktion file: https://git.launchpad.net/~pbek/qownnotes-snap/tree/setup/gui/QOwnNotes.desktop
<pbek> and that's the yaml: https://git.launchpad.net/~pbek/qownnotes-snap/tree/snapcraft.yaml
<ogra_> uhm ...
<ogra_> ogra@localhost:~$ mount |grep machine-id
<ogra_> tmpfs on /etc/machine-id type tmpfs (ro,relatime,size=94216k,mode=755)
<ogra_> ogra@localhost:~$ grep machine-id /etc/system-image/writable-paths
<ogra_> ogra@localhost:~$
<ogra_> mvo, ^^^ any idea where that bindmount comes from ?
<ogra_> ogra@localhost:~$ grep -r machine-id /usr/share/initramfs-tools/*
<ogra_> ogra@localhost:~$
<ogra_> definitely not from the initrd
<ogra_> why the heck is it a tmpfs at all
<pitti> ogra_: systemd mounts it as that if the root fs lacks a machine-id and is not writable
<pitti> ogra_: check dmesg
<ogra_> oh my
<ogra_> can we prevent that somehow ?
<ogra_> ogra@localhost:~$ dmesg|grep machine-id
<ogra_> [   11.400424] systemd[1]: Installed transient /etc/machine-id file.
<ogra_> ogra@localhost:~$
<ogra_> i assume it does that before processing fstab ?
<pitti> yes
<pitti> but the initrd should mount it if it's a symlink/mount, why doesn't it?
<ogra_> the initrd doesnt mount anything
<ogra_> it creates an fstab
<pitti> I thought we changed it to mount the writable parts of /etc in initrd
<ogra_> nope
<pitti> well, that was for system-image
<pitti> but it's the same problem
<mvo> still suspect its the ordering, i.e. we mount too late, i vaguely remember a similra 15.04 issue
<ogra_> i mounts one or two dirs that are actually needed by systemd to start at all ...
<pitti> you *can't* mount stuff in /etc during boot
<ogra_> but beyond that it only creates fstab
<pitti> well, at least not stuff that is needed for boot
<ogra_> iirc i even filed a bug that we should move it ... but james told me back then it was desired that systemd gets a chance to do fscks
<ogra_> so we never moved it to the initrd
<pitti> I do remember having written a PR which moves it
<pitti> maybe it was moved back
<ogra_> for initramfs-tools-ubuntu-core ?
<ogra_> i'm sure it never landed
<pitti> well, whatever we used in system-image
<ogra_> you probably did it for the phone
<pitti> *nod*
<ogra_> Bug #1512361
<mup> Bug #1512361: /etc/writable should be handled by the initrd, not by rootfs builds <Snappy:Triaged> <initramfs-tools-ubuntu-core (Ubuntu):Confirmed for ogra> <livecd-rootfs (Ubuntu):Confirmed for ogra> <https://launchpad.net/bugs/1512361>
<pitti> curious that this even works at all -- stuff in /etc/systemd/ also won't be considered for boot if it gets mounted during boot only
<ogra_> ah, no, thats something different
<pitti> for snaps that install boot services
<ogra_> aha, there is Bug 1423529
<mup> Bug #1423529: writable partitions not fsck'd. <Snappy:Fix Released by jamesodhunt> <https://launchpad.net/bugs/1423529>
<pitti> in comment #4 -> i-t has fsck'ed / and /usr for a while
<pitti> it wuold then also need to fsck /writable
<ogra_> well
<ogra_> / is /writable nowadays
<pitti> ah, so much the better
<ogra_> http://bazaar.launchpad.net/~jamesodhunt/ubuntu/vivid/initramfs-tools-ubuntu-core/bug-1423529/revision/51
<pitti> so why do we need any mounts in /etc in the first place?
<ogra_> because there might be rw files ?
<pitti> well, everything on / should be writable then :)
<niemeyer> ogra_: regarding "iirc slangasek and sabdfl both agreed the product name should be kept for the actual img files (especially in the light that we renamed ubuntu-core to ubuntu-base exactly for this)"
<ogra_> ogra@localhost:~$ grep -c etc /etc/system-image/writable-paths
<ogra_> 23
<pitti> plus /usr, /lib, /snap etc. bind-mounted from snaps/images
<ogra_> and we dont want the whole of etc to be writable
<niemeyer> ogra_: Yes, that's still right.. the rename is specifically for the *snap*, not the product, and not the images
<pitti> argh -- I had hoped with the all-snaps thing the writable bind mounts madness would have gone :)
<ogra_> niemeyer, ok, thanks for confirming :)
<niemeyer> Part of the point of renaming the snap is exactly this, actually.. that snap is not the product
<ogra_> yeah
<niemeyer> ogra_: Yes, that's still right.. the rename is specifically for the *snap*, not the product, and not the images
<niemeyer> Part of the point of renaming the snap is exactly this, actually.. that snap is not the product
<mvo> pitti: hm, how far are we from an empty etc? i.e. would it even boot?
<pitti> ogra_: well, IMHO we want /etc to be very small and completely writable
<ogra_> there is an echo in the room :)
<ogra_> pitti, i'm sure we dont :)
<mvo> pitti: last time we talked about this, the software was not ready, is it now?
<niemeyer> ogra_: I think there's a bug in my client, actually :)
<ogra_> heh
<pitti> mvo: this has never been started; I made a proposal a few years back but it got shot down
<ogra_> pitti, well, probably not the thing to change a day before RTM now +
<mvo> pitti: yeah, I remember that, I think there is a good chance for it to get resurrected
<mvo> ogra_: yeah, not today, but I think there is agreement that we want to move into this direction, no?
<pitti> ogra_: heh, yes
 * didrocks remembers that as well, and also some proposals for the default systemd preset on the ML
<ogra_> for now i guess we want to bind-mount machine-id from the initrd then
<ogra_> that will be a bit fiddly ... but doable ... (we need to create it on first boot etc)
<didrocks> oh you are still using my "Installed transient /etc/machine-id file" patch? :)
 * didrocks just backlogged
<ogra_> didrocks, ?
<didrocks> I did that patch IIRC a year and half ago or so for snapd in systemd
<didrocks> as you don't provide even an empty file by default IIRC
<ogra_> hmm
<ogra_> looking at the filesystem ...
<ogra_> ogra@localhost:~$ ls -l /var/lib/dbus/machine-id
<ogra_> lrwxrwxrwx 1 root root 15 Sep  5 13:58 /var/lib/dbus/machine-id -> /etc/machine-id
<didrocks> hence the tmpfs
<pitti> didrocks: it's not a patch, it landed upstream at that time and has lived a happy life ever since :)
<ogra_> why cant we link it the other way around ?
<pitti> didrocks: you actually did it for the life system, I think
<didrocks> oh right, live systemâ¦
<didrocks> pitti: I don't remember which ones went upstream and the ones which didn't
<ogra_> make /var/lib/dbus writable and create the file in there ... and ship a dnagling link in the readonly image
<pitti> doesn't help
<pitti> it would still be dangling when booting
<ogra_> it does help messing with /etc
<pitti> also, that's opposite of what upstream dbus does
<pitti> IMHO it's best to set up /etc in initrd, especially now that / alreaady gets fscked
<pitti> everything else will keep causing bugs
<pitti> we've had like 10 bugs due to that in touch, and now they all come back
<pitti> /var and /usr are suported to be separate partitions, but not /bin, /sbin, /lib and /etc
<mup> PR snapd#1674 closed: interfaces/builtin: add udisks2 and removable-media interfaces <Critical> <Reviewed> <Created by ssweeny> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1674>
<ogra_> pitti, that sounds very buggy
<ogra_> (that lasdt line of you)
<ogra_> why would etc not be allowed to be a separate partition
<ogra_> it surely was for decades
<pitti> for sure not
<pitti> you could never have /etc/init.d or /etc/rc?.d on a separate partition, for example
<pitti> or stuff in /lib etc.
<ogra_> well, technically you can since we use initramfs
<pitti> it works a bit better now as we e. g. got rid of /etc/mtab madness
<pitti> sure, if you mount it in the initrd, all is well
<pitti> but you can't expect the init system to mount /etc when /etc is the place to describe what to mount and do for boot :)
<ogra_> yeah, indeed
<pitti> so, again: mount everything in /etc/, /lib, /bin/, /sbin in the initramfs, and we'll stop having subtle bugs like that
<ogra_> mvo, triggering a new ubuntu-core ... seems snapd (amd64) and livecd-rootfs now got published
<ogra_> running
 * zyga would love to have a call around initramfs using code derived from snap-confine to setup the root fs
<ogra_> zyga, sounds like a great series 18 feature :P
<zyga> ogra_: perhaps earlier
<ogra_> yeah, but definitely not for RTM ... and unlikely for GA
<zyga> ogra_: feels fragile to differ on the root filesystem layout
<zyga> ogra_: yes, I agree
<zyga> ogra_: note: call != implemented
<zyga> ogra_: just to figure out what we want in the end
<ogra_> well, if you can get snap-confine into the initrd ... withough making it grow by tens of megabytes ...
<zyga> ogra_: snap-confine is ~50KB stripped
<zyga> ogra_: note, it would not be snap-confine, just code derived from it, like snap-setup-filesystem or something
<zyga> ogra_: so that we have consistency
<ogra_> zyga, ah, and i guess it is go and has no deps ?
<zyga> ogra_: it's C
<zyga> ogra_: no deps for this part
<ogra_> hmm, lovely
<ogra_> oh man ...
<zyga> what?
<ogra_> will we ever n3eed to use machine-id in the ubuntu-core running in classic ?
<zyga> no
<zyga> we will never ever ever see it
<ogra_> to actually have the file rw bind mounted i need to create the file in the readonly rootfs
<ogra_> but that will mean that only the initrd can actually put values in there
<ogra_> else it would be an empty readonly file
<zyga> ogra_: there are some tricks you can use
<zyga> ogra_: to avoid the file altogether
<zyga> ogra_: but note that we don't use /etc from the core snap
<ogra_> ok, that should be safe then
<ogra_> i just wonder if we will one day
<zyga> ogra_: I doubt it, it's the same machine and hence same machine-id
<ogra_> hmm,. why is there no uuidgen on the image
<zyga> ogra_: use the kernel for that
<ogra_> yeah
<ogra_> cat /proc/sys/kernel/random/uuid|tr -d -
<ogra_> that will do it
<pbek> popey: I changed the snapcraft.yml: "    command: desktop-launch ${SNAP}/usr/bin/QOwnNotes --snap" (I added "${SNAP}/"), it seems to work now
<mvo> pitti: hm, seeding libnss-resolve made things worse apparently, I have no name resolution on my pi2 currently
<pbek> popey: I removed that on Aug 31th to make it build on Launchpad and deploy it to the store... we'll see what happens today
<mvo> pitti: and can't login because of that to debug further (*sigh*)
<pitti> mvo: ok, I think about how to fix that more properly (feel free to report a bug to track it)
<ogra_> pitti, mvo http://paste.ubuntu.com/23137470/ ... (needs a "touch etc/machine-id" in livecd-rootfs too
<ogra_> )
<mvo> ogra_: typo " teh w"
<ogra_> fixed already :P
<mup> PR snapd#1845 closed: tests: use the real model assertion when creating the core test image <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1845>
<ogra_> does the code look ok ?
<ogra_> bah, reconnect
<ogra_> <ogra_> does the code look ok ?
<ogra_> <ogra_> what i still dont get is why this never showed up as an issue in u-d-f built images
<ogra_> <ogra_> having the id change every boot must have more fallout
<ogra_> <ogra_> pitti, does that mean you want the libnss-resolve addition rolled back ?
<ogra_> <ogra_> (i need to touch livecd-rootfs now)
<ogra_> <ogra_> (... and can do that in the same upload)
<ogra_> <ogra_> or mvo ^^^
<mvo> ogra_: I wonder if there is more ubuntu-image issues
<mvo> ogra_: let me quickly retry this with u-d-f
<ogra_> mvo, i would suspect so
<mvo> ogra_: please revert my upload, I don't know what happend, but it seems like it break the core
<ogra_> damn ... one second to late
<mvo> ogra_: both the libnss-resolve and the masking of the unit
<mvo> hm, ok
 * ogra_ does another upload 
<mvo> ogra_: maybe you can figure something out, I can't ssh into the image anymore with the latest edge
<ogra_> mvo, masking of the unit means the clud-init one ?
<mvo> ogra_: yes, well, I think so, I have no idea if it is related
<mvo> ogra_: maybe not
<ogra_> might be that you dont get host keys
<ogra_> oh, lovely ... the initrde change means indeed i may also re-roll all kernels
<morphis> zyga: just forwarded you the mail from ssweeny
<zyga> morphis: yep, I see it
<zyga> morphis: I'll investigate today
<morphis> zyga: awesome!
<SamYaple> is there a to get snappy to --no-install-recommends the stage/build packages?
<pbek> popey: qownnotes 16.09.2 works again
<popey> ooh pbek I'll update
<pbek> popey: are you using it under Unity or under Mate?
<popey> yes
<popey> :)
<popey> (unity)
<pbek> 16.04 I suppose...
<pbek> popey: could you please be so kind and test if some icons are not visible if you use the QOwnNotes dark mode?
<pbek> Andrew from http://www.webupd8.org/2016/09/qownnotes-is-note-taking-and-todo-list.html mentioned something about that, but I can't reproduce it under my 15.10 Unity vm (I use KDE Neon on my desk)
<ogra_> SamYaple, hmm, i thought thats the default
<pbek> popey: you could switch to the #qownnotes room, if you don't want to pollute #snappy ;)
<SamYaple> ogra_: oh it might be. i noticed a bloated install and assumed. ill double check!
<ogra_> ogra@anubis:~/datengrab/devel/branches/snapcraft$ grep -r recommends *
<ogra_> debian/changelog:  * Do not install recommends for build or stage pkgs. (LP: #1500375)
<ogra_> snapcraft/internal/repo.py:                               '--no-install-recommends', '-y',
<mup> Bug #1500375: inconsistent build results due to wrong usage of recommends <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1500375>
<ogra_> looks like
<stub> Where do I grant access to my private snap?
<bull_> snapcraft pull
<bull_> hello guys
<bull_> what  snapcraft pull will do ??
<niemeyer> ogra_: The ubuntu-core tests started working again.. did you fix anything on your end?
<bull_> it will pull all parts right ??
<ogra_> niemeyer, i reverted the former change
<ogra_> on mvo's request
<niemeyer> ogra_: What was the change?
<ogra_> disabling of cloud-init and addition of libnss-resolve
<ogra_> time to try another rpi image
<bull_> guys pull, prime, and stage can be run for specified parts and alone to perform actions on all parts ??
<niemeyer> ogra_: Ok, something is not quite right there then
<ogra_> niemeyer, heh,. a *lot* is not quite right atm
<niemeyer> ogra_: What else is not right?
<ogra_> well, obviously nobody ever noticed that we re-generate the machine-id on every boot ... netplan brought that to light (every reboot now gets a new IP)
<ogra_> cloud-init causes 5-10min boot time on pi images built using ubuntu-image
<ogra_> we dont have support for wlan in console-conf yet (there is a test package, but debugging the other stuff kept me fry trying it yet) ... which excluded pi3 and dragonboard from RTM
<ogra_> *excludes
<ogra_> s/fry/from/
<niemeyer> ogra_: Probably nobody ever noticed many bugs that we know about and many bugs that we also don't know about.. that's why we need a period of polishing after the RTM image goes out this week
<ogra_> niemeyer, most of it is ubuntu-image related ... some of it is due to the missing bmodel assertion mvo told me (snap list is empty on arm builds, snap install trashes everything etc)
<ogra_> -b
<niemeyer> ogra_: Yes, we're not using ubuntu-image for this release due to those bugs
<ogra_> niemeyer, sure. the issue is that we need working images for an RTM release
<ogra_> niemeyer, oh, would have been nice if someone told me :P
<niemeyer> ogra_: yep, and I believe we're going to have one :)
<ogra_> right
<ogra_> u-d-f images are fine and solid
<niemeyer> ogra_: Yeah, we agreed to use that for the release on Friday, precisely because ubuntu-image looks too unstable ATM
<ogra_> right
<niemeyer> We have a few weeks to get that sorted
<ogra_> what do we do with assertions ?
<ogra_> i assume we want u-d-f to put them in place
<niemeyer> Yeah, definitely
<ogra_> so the resulting image doesnt need to be re-flashed
<niemeyer> Indeed
<niemeyer> Although that's not a blocker
<niemeyer> the reflashing part, specifically
<niemeyer> We do want the assertions in place for this release so we can test it
<ogra_> oh, i thought that was how RTM was defined
<ogra_> stable enough that you dont need to re-flash
<ogra_> ogra@localhost:~$ mount|grep machine
<ogra_> ogra@localhost:~$ mount|grep machine
<ogra_> /dev/mmcblk0p2 on /etc/machine-id type ext4 (rw,relatime,data=ordered)
<ogra_> \o/
<ogra_> yay, at least one positive thing ... lets see if netplan behaves now
<niemeyer> ogra_: The point of GA is precisely to have the golden image that may be flashed on devices
<niemeyer> ogra_: So no "re-flash" would be an oxymoron on this case
<SamYaple> what would be the best way to a2enmod something in apache2 with snappy? at runtime?
<ogra_> niemeyer, well, that was what i understood regarding RTM ... we held back releasing any images for a long time because RTM was supposed to be at a quality that users do not need to re-flash but can upgrade to get to GA (and report bugs along the way)
<ogra_> i dont really mind if it isnt like that anymore though
<ogra_> it is just what i understood in the various discussions
<niemeyer> ogra_: As I said, it'll probably still be the case.. we just won't block on that as we need to hit some deadlines
<niemeyer> ogra_: If we can't generate the proper image because ubuntu-image is too buggy today, that's life.. we'll find a way to hit the deadline and release a proper image soon
<ogra_> pitti, so i fixed the machine-id issue ... and the IP seems to persdist *after the second boot* ... i.e. i do a first boot, run console-conf, that tells me the ssh credentials and IP to use and after the second boot i get a new IP ... and this IP sticks on subsequent boots but is indeed not the IP that console-conf told me
<ogra_> niemeyer, yeah, i'm not worried i think we did hit the worst bugs the last two days already, eveything aheadf wont be that bad :)
<niemeyer> That's good to hear
<ogra_> the vfat one was the hardest ...
<ogra_> costed me two days and mvo one ... and lots of testing and poking in the dark
<ogra_> (who would have guessed that mtools/mcopy cant handle subdirs with long names :) )
<ogra_> mvo, so the machine-id stuff is fixed, new kernels and ubuntu-core is up with the fixes, libnss-resolve and the cloud-init drop were reverted ... (sadly my IP still changes til second boot so there is still something else) ... on my pi2 the name resolution works fine FWIW
<ogra_> and indeed ...
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try 'snap install hello-world'.
<ogra_> ogra@localhost:~$
 * ogra_ would really like tio be able to test the last classic shell fixes :/
<mup> PR snapd#1849 opened: cmd/snap: fix test suite (no Exit(0) on tests!) <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1849>
 * ogra_ decides thats enough for a day :)
<ahasenack> do snaps have access to the environment proxy variables?
<ahasenack> or is the env sanitized before running the commands inside the snap?
<ahasenack> or, is there another way to tell a snap to use a proxy?
<ogra_> i dont think the snap sees anything of the outer environment by default
<ahasenack> this is not a service, it's a command I'm running while my env has the proxy vars
<ahasenack> hm, sort of. This command talks to a daemon inside the snap
<ogra_> well, even user commands run confined
<ogra_> install hello-world ... run "hello-world.env"
<ahasenack> good idea
<ahasenack> heh, it has the proxy vars
<ahasenack> "hello-world.env|grep -i proxy" shows them
<ogra_> well, du you use a stack of wrappers in your command ?
<ogra_> perhaps the next wrapper doesnt have them anymore
<ahasenack> it's not my snap, I'm debugging it and I'm actually just about to file a bug
<ahasenack> was just wondering if there was some sort of global proxy setting for snaps
<ahasenack> like lxd has, for example
<mup> PR snapd#1826 closed: interfaces: add interface for hidraw devices <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1826>
<dave_uy> I'm working on a Snap package for the Bitsquare application. It is a Java FX application. Here is my https://github.com/dmp1ce/bitsquare-snap/blob/master/snapcraft.yaml. I am getting the error "Could not find any built jar files for part"
<dave_uy> Can someone tell me where I might be going wrong?
<mup> PR snapd#1848 closed: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
<mup> PR snapd#1848 closed: snap: ensure that plug and slot names are unique <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1848>
<morphis> niemeyer: thanks for merging!
<niemeyer> morphis: np, it'd be nice to use that same function that joc added on that PR in the serial-port interface as well
<niemeyer> But that's polishin
<niemeyer> g
<morphis> niemeyer: sure, I will chat with him tomorrow that we rework that in a follow up PR
<tvoss> zyga: o/ so a rebuild later, the test only fails on amd64
<tvoss> mvo: o/
<mvo> hey tvoss
<tvoss> mvo: hey, did you have a chance to take a look at my comment on the vendor branch?
<mvo> tvoss: not yet, sorry
<tvoss> mvo: ah okay, so not-installed does not work on trusty
<mvo> tvoss: aha, yes, I saw that, have not looked yet, probably trivial to fix with a simple "rm tmp/usr/bin/uboot-go" in debian/rule
<tvoss> mvo: ack
<mup> PR snapd#1850 opened: tests: remove silly [Service] entry from snapd.socket.d/local.conf <Created by mvo5> <https://github.com/snapcore/snapd/pull/1850>
<tvoss> zyga: are you fine with taking test_restrictions_working_args out of the check target? test failures seem to be spurious
<tvoss> zyga: let me know what you think: https://github.com/snapcore/snap-confine/pull/124
<mup> PR snap-confine#124: Remove test producing spurious results on trusty <Created by vosst> <https://github.com/snapcore/snap-confine/pull/124>
<mwhudson> morning
<elopio> mwhudson: good morning.
#snappy 2016-09-06
<I> oh
<I> heyyy
<I> This thing is funny
<Guest43857> okie
<Guest43857> nnn
<Guest43857> ???
<mup> Bug #1620442 opened: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <Snappy:New> <https://launchpad.net/bugs/1620442>
<mvo> ogra_: so when disabling cloud-init we don't get ssh host keys generated anymore, that was the issue yesterday, I added a simple job for that in ubuntu-core-config, that hopefully fixes this issue
<liuxg> ogra_, ping
<mvo> liuxg: still early for him, probably not around before
<mvo> liuxg: at least 1h
<liuxg> mvo, ok. thanks. I just flashed my new raspberry pi 3 device. it is very strange that sometimes my device cannot get an IP (it is connected to my router). I cannot use ssh to see what's happening there.
<mvo> liuxg: can you see in your router that the router does not assign an ip? when you can not connect?
<liuxg> mvo, yes, that is exactly what happened here. Initally it was fine, and I could connect to it. Then I rebooted, it became something like that. I tried to reboot it a number of times, and at one time, i got an IP again. I thought it was fine. I rebooted, then I could not get the ip again :)
<liuxg> mvo, I have checked the cable, and change different cables. there should be no problem with the cable. it works well with raspberry pi 2 device.
<liuxg> mvo, I am not sure whether it is a hardware issue or not. This is a newly purchaed board.
<mvo> liuxg: the system that configures the network changed to "netplan" recently, it sounds like fallout from that, can you attach a keyboard and monitor to the pi3 maybe? that might be useful to figure out more
<liuxg> mvo,  the thing is that my HDMI does not seem to work.
<liuxg> mvo, do you have any older image which did not use netplan? I want to have a try with that. thanks
<mvo> liuxg: not 100% certain but http://people.canonical.com/~mvo/all-snaps/16/old/all-snaps-pi2.img.xz is a good candidate
<liuxg> mvo, I am using raspberry pi 3 instead of pi 2. the pi 2 works well here. however, it does not have the bluetooth. I want to use the bluetooth on pi 3 to do a demo.
<mvo> liuxg: aha, ok. in this case you need ogra, I don't have any pi3 images available
<mvo> liuxg: sorry
<liuxg> mvo, yeah, that is why I am trying to reach mvo. thanks for your helping on this.
<zyga> o/
<LY> Is Ubuntu 16.04 supported on NUC6i5syk
<zyga> LY: hello, can you be more specific about the device? is this an intel nuc?
<LY> NUC is a mini PC from Intel
<LY> http://ark.intel.com/products/89188/Intel-NUC-Kit-NUC6i5SYK
<zyga> LY: I believe all intel CPUs are supported
<LY> is there any web page to look at
<ogra_> liuxg, http://people.canonical.com/~ogra/snappy/all-snaps/ but that might be missing a lot of fixes
<ogra_> (already two weeks outdated and the next image will look totally different)
<liuxg> ogra_, where can I find the latest software? I flashed the software and refreshed the system. After that I cannot get the IP again.
<liuxg> ogra_, you are apprecited to give me a download link. I will use the pi 3 as a demo device in the tomorrow's Amazon hackathon event here.
<ogra_> liuxg, you *must* run the console-conf tool else the device wont have a network config (console-conf sets up the netplan configuration) ... either use a serial cable or HDMI
<ogra_> i guess that you dopt get an IP is becausse netplan was never set up
<ogra_> *dont
<mup> PR snapd#1841 closed: store: switch device session to use device-session-request assertion <Critical> <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1841>
<ogra_> note that obn newer images you also dont have a user or any way to log in without running the console-conf firstboot wizard
<liuxg> ogra_, my HDMI is not working unfortunately. I do not know how to enter the login screen.
<liuxg> ogra_, then do you have an older image?
<ogra_> well, the only other way is a serial cable
<ogra_> yes, under the url above
<ogra_> as i said, it is two weeks old ...
<liuxg> ogra_, with that, intially, I used ssh and I got into it, but now no matter how I reboot the system, I cannot get the IP. I do not know why it is inconsistent.
<ogra_> because it auto-upgrades i guess
<mup> PR snapd#1850 closed: tests: remove silly [Service] entry from snapd.socket.d/local.conf <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1850>
<ogra_> so after the upgrade it waits for the console-conf input
<liuxg> ogra_,  so, I should disconnect it first when it boots, then connect to it again, plugin and ssh. let me try this.
<ogra_> liuxg, well, once it is connected the upgrade can always happen
<ogra_> it happens in background
<zyga> morphis: o/
<liuxg> ogra_, I know, but I might have already logged in :)
<ogra_> not sure what job you need to disable to have it not do that
<morphis> zyga: hey!
<liuxg> ogra_, it is weird that it worked for me for a while, and then it stopped.
<ogra_> yes, because we upgrade ubuntu-core all the time
<mvo> ALL THE TIME - actually ;)
<ogra_> haha
<mvo> (SCNR)
<ogra_> mvo, no cloud-init looks lovely here !
<liuxg> ogra_, I even did a refresh, and it did upgrade the system. after that, what should I do ?
<ogra_> liuxg, you would have to run the tool
<ogra_> for which you need any kind of console access
<liuxg> ogra_, I need to run " console-conf"? that's it?
<ogra_> no
<mvo> ogra_: yeah, kvm is happy, I'm checking pi2 now
<ogra_> it runs on all ttys ... you just need to hit enter
<liuxg> ogra_, do you mean I just need to hit enter after I boot the device?
<ogra_> liuxg, yeah, on a tty
<liuxg> ogra_, you said that I should set the netplan, right?
<ogra_> no. console-conf does that
<liuxg> ogra_, ok. in fact I have a cable, but I do not see the screen
<mup> PR snapd#1851 opened: interfaces: serial-port use udevUsbDeviceSnippet <Created by jocave> <https://github.com/snapcore/snapd/pull/1851>
<ogra_> mvo, so the image seems to work just fine ... but i still have the IP changing on second boot (then it persists) ... and indeed i can still not install snaps
<ogra_> beony this this image looks really good
<mvo> ogra_: do you have a /etc/resolv.conf error? this is on pi2 or kvm?
<liuxg> ogra_, this problem does not happen to pi2
<ogra_> ogra@localhost:~$ ping web.de
<ogra_> ping: unknown host web.de
<ogra_> ogra@localhost:~$
<ogra_> oha ...
<mvo> ogra_: /etc/resolv.conf?
<ogra_> that worked with all images yesterday
<mvo> ogra_: what does it look like? and pi2 or kvm?
<ogra_> ogra@localhost:~$ cat /etc/resolv.conf
<ogra_> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
<ogra_> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
<ogra_> ogra@localhost:~$
<ogra_> pi2
<mvo> ogra_: yeah, that looks very wrong
<mvo> ogra_: I mean, empty
<ogra_> yeah
<ogra_> i guess yesterday cloud-inuit did set it up
<mvo> ogra_: I seeded libnss-resolve again, I had hoped it would fix it
<mvo> ogra_: yes, I suspect so too
<mvo> ogra_: I suspect some race, I had it on firstboot (empty resolv.conf), second boot is fine, trying more now
<ogra_> does libnss-resolv need any config  ?
<ogra_> mvo, well, there is definitely a massive difference between first boto and the setup after console-conf ran ... else my IP wouldnt change
<ogra_> *boot
<ogra_> hmm, manually restarting the resolvconf service has no effect
<mvo> ogra_: hm, all my subsequent boots are fine so far, quite annoying
<mvo> ogra_: i.e. they have the same IP and get a valid resolvconf file
<ogra_> pitti, wheer should i find the actual network config now ... beyond netplan
<ogra_> mvo, for me it is the exact opposite
<pitti> ogra_: cat /run/systemd/network/
<pitti> err, ls
<pitti> well, "in"
<ogra_> ah, i was looking in /etc/systemd/network/
<pitti> they are not original config, just generated, so they shouldn't be in /etc/
<ogra_> yeah
<ogra_> well, that part looks fine ... still my IP changes exactly once
<ogra_> right after the system told me which one to use to log in :P
<mvo> ogra_: hrm, hrm, no idea what it is, but really hard to reproduce for me, both pi2 and kvm give me a valid resolv.conf, however fgimenez reorted he also had this issue on kvm
<pitti> different machine-id for firstboot vs. second boot?
<ogra_> pitti, nope
<pitti> resolv.conf is a bug, but unrelated to the IP
<ogra_> machine-id is created on first boot by initrd ... before any network is up
<pitti> no, installing libnss-resolve should auto-add itself to /etc/nsswitch.conf and enable the service
<pitti> no config necessary
<ogra_> pitti, http://paste.ubuntu.com/23140573/
<mvo> ogra_: does nsswitch.conf look valid?
<mvo> ogra_: i.e. have "resolve" in the hosts?
<ogra_> hosts:          files resolve dns myhostname
<ogra_> networks:       files
<ogra_> pitti, this time i dont really see any difference in the client requests ...
<mvo> can't reproduce this still, a bit annoying, all working for me
<ogra_> uid and mac are identical
<mup> PR snapd#1852 opened: asserts: update trusted account-key asserts with names <Created by emgee> <https://github.com/snapcore/snapd/pull/1852>
<ogra_> pitti, but i can fully reliably reproduce it ... after console-conf ran the IP changes once
<ogra_> which is very unfortunate since it doesnt match what console-conf gave you for login
<ogra_> mvo, well, my install is reliably broken regarding name resolution ... i dont get any resolv.conf setup here
<ogra_> so if you have any other ideas :)
<ogra_> happy to test
<pitti> "systemctl status systemd-resolved" â running?
<ogra_> i think not ... let me check again
<ogra_> ogra@localhost:~$ systemctl status systemd-resolved
<ogra_> â systemd-resolved.service - Network Name Resolution
<ogra_>    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
<ogra_>    Active: inactive (dead)
<ogra_>      Docs: man:systemd-resolved.service(8)
<ogra_> aha
<pitti> /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf  runs resolvconf
<pitti> ... which updates /etc/resolv.conf
<ogra_> yeah, and manually starting it fixes it
<ogra_> so why does it think it was vendor-disabled ?
<pitti> without libnss-resolve we need to find something else to call it with the DNS servers picked up by networkd, that's what I still need to think about
<ogra_> oh, i read that wrong, sorry
<pitti> ogra_: probably more likely "not enabled"
<ogra_> yeah
<ogra_> but thats weird, given that mvo says it works for him ... for me it only worked before console-conf
<mvo> ogra_: uh, its disabled for me as well!
<pitti> ogra_: do you have a /etc/systemd/system/multi-user.target.wants/systemd-resolved.service symlink?
<ogra_> why do you have name resolution then ?
<ogra_> ogra@localhost:~$ ls -l /etc/systemd/system/multi-user.target.wants/systemd-resolved.service
<ogra_> ls: cannot access '/etc/systemd/system/multi-user.target.wants/systemd-resolved.service': No such file or directory
<ogra_> nope
<mvo> I bet writable path again :(
<ogra_> nah
<pitti> so /var/lib/dpkg/info/libnss-resolve\:amd64.postinst didn't run
<ogra_> mvo, that dir is mouonted in initrd
<ogra_> hmm ... unless
<pitti> I was suspecting mounting /etc/systemd/system from fstab, but apparently not that then
 * ogra_ chacks the writable-paths file
<ogra_> oh man
<ogra_> ogra@localhost:~$ grep systemd /etc/system-image/writable-paths
<ogra_> # systemd
<pitti> this shoudl already happen during building the image, no?
<pitti> I mean creating the enablement symlink and running libnss-resolve's postinst
<ogra_> ogra@localhost:~$ grep systemd /etc/system-image/writable-paths
<ogra_> # systemd
<ogra_> /etc/systemd/system                     auto                    persistent  transition  none
<ogra_> /var/lib/systemd/random-seed            auto                    persistent  transition  none
<ogra_> /var/lib/systemd/rfkill                 auto                    persistent  transition  none
<ogra_> /etc/systemd/network                    auto                    persistent  transition  none
<ogra_> /etc/systemd/system.conf.d              auto                    persistent  transition  none
<ogra_> /etc/systemd/user.conf.d                auto                    persistent  transition  none
<ogra_> we need to rip it out there indeed
<mvo> ogra_: its also not in /snap/ubuntu-core/current/etc/systemd/system/multi-user.target.wants hm, hm
<ogra_> mvo, yeah, thats a mess ... we bind mount the dir twice
<ogra_> once from initrd, once from fstab
<ogra_> that cant work
<mvo> ogra_: well, if its not in the pristine ubuntu-core snap, something is wrong in the livecd-rootfs install, no?
<ogra_> 	# Mount the systemd overlay so that we have a complete root partition during boot
<ogra_> 	mkdir -p "${rootmnt}/writable/system-data/etc/systemd/system"
<ogra_> 	mount -o bind "${rootmnt}/writable/system-data/etc/systemd/system" "${rootmnt}/etc/systemd/system"
<ogra_> from the initrd
<pitti> if [ "$1" = configure ] && [ -z "$2" ]; then
<pitti>     echo "First installation detected..."
<pitti> ^ do you have that line in the image build log?
 * ogra_ checks https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/4472
<pitti> yep
<ogra_> Setting up libnss-myhostname:armhf (229-4ubuntu7) ...
<ogra_> First installation detected...
<ogra_> seems so
<pitti> and it also shows update-rc.d
<ogra_> Setting up libnss-myhostname:armhf (229-4ubuntu7) ...
<ogra_> First installation detected...
<ogra_> twice
<pitti> also from linbnss-resolve
<pitti> (the other is from -myhostname)
<pitti> so that should have created the symlink
<ogra_> oops, yeah, wrong paste
<pitti> oh, and as it added it to nsswitch.conf it must have run
<ogra_> right, but the code above doesnt copy anything
<ogra_> it blindly bind mounts
<ogra_> then adds it to fstab
<ogra_> then writable-paths tries to copy something but doesnt find anything
<ogra_> i guess
<ogra_> we need copy code in the initrd and remove the dir from writable-paths
<ogra_> hmm
<ogra_> thats a bit tricky ... we actually want to copy from the squashfs ...
<ogra_> oh, fun !
<ogra_> 138                         # mount all /etc dirs right now, not later when fstab is
<ogra_> 139                         # processed, as it will cause races.
<ogra_> 140                         case $1 in
<ogra_> 141                             /etc*)
<ogra_> 142                                 [ -d "${rootmnt}/writable/system-data/$1" ] || mkdir -p "${rootmnt}/writable/system-data/$1"
<ogra_> 143                                 mount -o bind "${rootmnt}/writable/system-data/$1" "${rootmnt}/$1"
<ogra_> 144                                 ;;
<ogra_> 145                             *)
<ogra_> pitti, so your etc code *is* in the initred
<ogra_> *initrd
<pitti> what is "my etc code"?
<pitti> you mean systemd-resolved.service  enablement symlink?
<ogra_> pitti, the code we talked about yesterday
<ogra_> all of /etc is bind mounted from initrd
<pitti> ah, for setting up /etc in the initrd?
<pitti> I thought you said /writable was now spelled /
<ogra_> after the initrd, yes
<pitti> (I do remember that code, but it was from touch times)
<ogra_> but it only bind mounts ... doesnt look like it copies existing content from the target
<ogra_> which would explain why we miss the files/links
<ogra_> oh
<ogra_> mvo, do you use a working model assertion ?
<ogra_> ogra@localhost:~$ ls /snap/
<ogra_> ogra@localhost:~$
<ogra_> ...
<ogra_> ogra@localhost:~$ sudo mount -o loop /var/lib/snapd/snaps/ubuntu-core_483.snap /mnt/
<ogra_> ogra@localhost:~$ ls /mnt/etc/systemd/system/multi-user.target.wants/
<ogra_> cgmanager.service  cron.service        pppd-dns.service  rsyslog.service        snapd.firstboot.service  ssh.service
<ogra_> cgproxy.service    networking.service  remote-fs.target  snapd.boot-ok.service  snapd.service            ubuntu-fan.service
<ogra_> ogra@localhost:~$
<ogra_> hmm, yeah, it is definitely missing here too
<ogra_> pitti, so what would create the systemd-resolved.service symlink ?
<ogra_> normally
<pitti> ogra_: libnss-resolve.postinst â systemctl enable systemd-resolved
<ogra_> and that works inside chroots ?
<ogra_> systemctl i mean
<pitti> it should, let me check
<pitti> Setting up libnss-resolve:amd64 (231-4ubuntu1) ...
<pitti> First installation detected...
<pitti> Checking NSS setup...
<pitti> Created symlink /etc/systemd/system/multi-user.target.wants/systemd-resolved.service â /lib/systemd/system/systemd-resolved.service.
<pitti> (in a yakkety schroot)
<pitti> but this "Created symlink.." is missing from the image build log
<ogra_> hmm, we dont get that much output
<ogra_> the log stops at First installation detected...
<ogra_> err
<ogra_> at the NSS line actually
<ogra_> Setting up libnss-resolve:armhf (229-4ubuntu7) ...
<ogra_> First installation detected...
<ogra_> Checking NSS setup...
<ogra_> Setting up watchdog (5.14-3ubuntu0.16.04.1) ...
<pitti> yes, as nsswitch.conf gets updated
<ogra_> i dont see the "Created symlink"
<ogra_> (the fun question here is, why does name resolution work in console-conf (it downloads the ssh key from LP just fine)
<ogra_> )
<pitti> because nss-resolve
<pitti> or wait, the daemon isn't running
<ogra_> and why doesnt it work after console-conf then ?
<nhaines> kyrofa: I was poking at Nextcloud quite a bit, and I think it's time to upgrade my cloud server.  But the snap is really out of date.  Do you have any plans for that or should I roll my own?  Also, should I complain really loudly that upstream didn't accept your patcH?
<fgimenez> ogra_, here it works for a while and after some time it stops working, the name resolution is lost http://paste.ubuntu.com/23140676/
<ogra_> pitti, i dont see any code in the debian dir of the currenmt systemd package that would call "enable systemd-resolved.service"
<pitti> ogra_: debian/libnss-resolve.postinst
<ogra_> wheer should that run ...
<pitti> the insert_nss_entry did run
<ogra_> pitti, well, either i'm blind or that isnt there
<ogra_> right
<ogra_> but not the enable
 * pitti blinks -- it's right there..
<pitti> ogra_: oh! xenial?
<ogra_> pitti, http://paste.ubuntu.com/23140681/
<pitti> I'm looking at yakkety, we started https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver in yakkety only
<ogra_> thast what i see looking at the source of the systemd package
<ogra_> right ... so thats our issue i guess
<pitti> ok, that explains it; should have thought about that earlier
<ogra_> do you want to fix it in systemd or should i add a livecd-rootfs hook ?
<pitti> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=62d8aa9f5
<pitti> the starting is irrelevant for chroots, just live systems
<pitti> ogra_: I can SRU it if that doesn't block you for too long
<ogra_> it might ...
<ogra_> mvo, ^^^ opinion ?
<pitti> in the meantime, you can add a "systemctl enable systemd-resolved.service" after installing libnss-resolve to the image build scripts
<ogra_> right
<mvo> ogra_: let me re-read, was distracted
<pitti> and point to the SRU bug to drop it again once it's fixed
<ogra_> yeah
<ogra_> let me add it as a temp solution
<pitti> oh wait
<pitti> there's more to it
<pitti> you also wouldn't have /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf in xenial
<pitti> and a few fixes to resolved itself
<ogra_> oh my
<pitti> so hold your horses please, using resolved in xenial isn't what we can do very easily
<ogra_> well, luckily release is on thu. only :P
 * ogra_ grins
<pitti> (and remove nss-resolve from the image build scripts again)
<ogra_> hahahaha
<pitti> Ubuntu == devel series for me :)
<mvo> pitti: if we can get it into the ppa:snappy-dev/image that would unblock us
<pitti> hm, I thought I had a resolveconf hook in networkd on xenial
<ogra_> thats pretty gross though :)
<mvo> oh, ok, so revert this again
<mvo> hm,
<ogra_> (using the PPA for a whole init system backport i mean)
<pitti> nonono
<mvo> so what is the best bet for working resolv.conf for us?
<pitti> mvo: let me check/think about this for a sec
<pitti> I'm just done being tvoss' slave for systemd on 14.04 for snapd, so now I can be your's :)
<mvo> yay
 * mvo cracks the wip
<mvo> and the whip as well
<ogra_> lol
<ogra_> dont crack the WIP on purpose ... we do that enough already by accident
<pitti> so yeah, we didn't integrate networkd on xenial at all yet
<pitti> all the resolver/networkd/netplan work went into y only
<pitti> oh, wrong, we already do have systemd-networkd-resolvconf-update.{path,service}
<ogra_> oh ... another fun fact ...
<ogra_> ogra@localhost:~$ sudo systemctl enable systemd-resolved.service
<ogra_> Created symlink from /etc/systemd/system/multi-user.target.wants/systemd-resolved.service to /lib/systemd/system/systemd-resolved.service.
<ogra_> ogra@localhost:~$ ls /mnt/etc/systemd/system/multi-user.target.wants/
<ogra_> cgmanager.service  cron.service        pppd-dns.service  rsyslog.service        snapd.firstboot.service  ssh.service
<ogra_> cgproxy.service    networking.service  remote-fs.target  snapd.boot-ok.service  snapd.service            ubuntu-fan.service
<ogra_> ogra@localhost:~$
<ogra_> hmm, perhaps i should look in the right dir ... ignore that
<ogra_> it is there as it should ...
 * ogra_ reboots to see what happens
<pitti> mvo, ogra_: is systemd-networkd-resolvconf-update.path running for you?
<ogra_> where do i find out ?
<pitti> systemctl status systemd-networkd-resolvconf-update.path
<mvo> pitti:  Active: active (waiting)
<pitti> ack, good
<pitti> mvo: sudo systemctl status systemd-networkd-resolvconf-update.service ?
<pitti> did it ever run?
<ogra_> here too ... though note that i just ran "sudo systemctl enable systemd-resolved.service" before the reboot
<pitti> ogra_: yeah, should be unrelated
<ogra_> ogra@localhost:~$  systemctl status systemd-networkd-resolvconf-update.path
<ogra_> â systemd-networkd-resolvconf-update.path - Trigger resolvconf update for networkd DNS
<ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.path; static; vendor preset: enabled)
<ogra_>    Active: active (running) since Tue 2016-09-06 08:24:29 UTC; 21s ago
<pitti> (also, please undo any resolved stuff on your image)
 * ogra_ disbales and reboots again
<ogra_> *disables
 * ogra_ praises mvo again for disabling cloud-init ... the first time i see reasonable boot times on arm
<ogra_> ogra@localhost:~$ systemctl status systemd-networkd-resolvconf-update.path
<ogra_> â systemd-networkd-resolvconf-update.path - Trigger resolvconf update for networkd DNS
<ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.path; static; vendor preset: enabled)
<ogra_>    Active: active (waiting) since Tue 2016-09-06 08:25:28 UTC; 37s ago
<ogra_> ogra@localhost:~$
<ogra_> after reboot
<ogra_> ogra@localhost:~$ ping web.de
<ogra_> ping: unknown host web.de
<ogra_> ogra@localhost:~$
<pitti> I took a xenial VM, added a network config, removed it from ifupdown, and /etc/resolv.conf has my nameserver
<pitti> hmm
<pitti> ogra_: systemctl status systemd-networkd-resolvconf-update.service
<ogra_> pitti, without a running systemd-resolved.service ?
<pitti> ogra_: yes
<pitti> plain OOTB xenial cloud image
<ogra_> ogra@localhost:~$ systemctl status systemd-networkd-resolvconf-update.service
<ogra_> â systemd-networkd-resolvconf-update.service - Update resolvconf for networkd DNS
<ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.service; static; vendor preset: enabled)
<ogra_>    Active: inactive (dead) since Tue 2016-09-06 08:26:00 UTC; 1min 37s ago
<ogra_>   Process: 2608 ExecStart=/bin/sh -c for timeout in `seq 30`; do out=$(sed -n "/^DNS=/ { s/^DNS=/nameserver /; p}" /run/systemd/netif/state); [ -z "$out" ]
<ogra_>  Main PID: 2608 (code=exited, status=0/SUCCESS)
<pitti> oh, so it did run
<pitti> grep DNS /run/systemd/netif/state
<ogra_> ogra@localhost:~$ cat /run/systemd/netif/state
<ogra_> # This is private data. Do not parse.
<ogra_> OPER_STATE=routable
<ogra_> ogra@localhost:~$
<pitti> le huh, no DNS server through DHCP?
<pitti> none in "networkctl status" either, I assume?
<ogra_> ogra@localhost:~$ networkctl status
<ogra_> â        State: routable
<ogra_>        Address: 192.168.2.22 on enxb827eb04db1c
<ogra_>                 fe80::ba27:ebff:fe04:db1c on enxb827eb04db1c
<ogra_>        Gateway: 192.168.2.1 (DrayTek Corp.) on enxb827eb04db1c
<pitti> I have "DNS: 10.0.2.3" here
<pitti> ok, so that's not at all the direction I was suspecting
<pitti> mvo: does "networkctl status" show a "DNS:" for you?
<ogra_> on my desktop i dont have DNS in there either
<ogra_> (though i guess that doesnt tell anything ... NM manages the network there)
<pitti> ogra_: supposedly you use NM there and networkd isn't even running
<pitti> yes
<pitti> "journalctl -t systemd-networkd" SVP
<ogra_> ogra@wall2:~$ grep domain-name-servers /etc/dhcp/dhcpd.conf
<ogra_> option domain-name-servers 217.237.150.115, 217.237.151.205;
<ogra_> #  option domain-name-servers ns1.internal.example.org;
<ogra_> ogra@wall2:~$
<ogra_> thats what my DHCP should provide
<pitti> "grep -r DNS= /run/systemd/netif" -> nothing there?
<ogra_> http://paste.ubuntu.com/23140773/
<ogra_> ogra@localhost:~$ grep -r DNS= /run/systemd/netif
<ogra_> ogra@localhost:~$
<ogra_> bah
<pitti> ok, so DHCP was received, but no name servers
<ogra_> i hate IRC and slashes !
<ogra_> ogra@localhost:~$ grep -r DNS= /run/systemd/netif
<ogra_> /run/systemd/netif/leases/3:DNS=217.237.150.115 217.237.151.205
<ogra_> /run/systemd/netif/links/3:DNS=217.237.150.115 217.237.151.205
<ogra_> /run/systemd/netif/links/3:MDNS=no
<ogra_> ogra@localhost:~$
<pitti> ah!
<ogra_> IRC swallows lines that startz with slash
<ogra_> nothing in tehj journalctl output though+
<pitti> yes, so my awful shell hack in /lib/systemd/system/systemd-networkd-resolvconf-update.service is not working
<pitti> it's fortunately gone in y, but not yet in x
<ogra_> but given that just enabling systemd-resolved.service works, what would be the issue with that ?
<ogra_> as a workaround at least
<pitti> ogra_: well, in xenial resolved still has a number of bugs and crashes, I wouldn't recommend it yet
<ogra_> k
<pitti> works for simple cases, but we got reports about problems with DNSSEC or domains which are only served by particular interfaces etc.
<nhaines> pitti: would you say those bugs haven't not yet been resolved?
<pitti> some of them have, but there is still a privacy issue in y open that's on my list
<ogra_> nhaines, no, he hasnt resolved the resolved bugs yet
<ogra_> pitti, well, i think we could live with a few bugs for RTM if we know it will be fixed by final release
<pitti> ogra_: can you please file a bug with the symptom (missing DNS in /etc/resolv.conf) and the output of the above grep? against systemd? (for SRUing)
<pitti> ogra_: I can give you an instant fix for the image build, and we SRU the proper fix
<ogra_> pitti, yeah
<pitti> ogra_: can you please edit /lib/systemd/system/systemd-networkd-resolvconf-update.service:
<pitti> ExecStart=/bin/sh -c 'for timeout in `seq 30`; do out=$(sed -n "/^DNS=/ { s/^DNS=/nameserver /; p}" /run/systemd/netif/state /run/systemd/netif/leases/* | sort -u); [ -z "$out" ] || break; sleep 1; done; echo "$out" | /sbin/resolvconf -a networkd'
<pitti> ogra_: if it's readonly, copy it to /etc/systemd/system/ and edit it there
<ogra_> reboot ?
 * ogra_ reboots
<pitti> ogra_: sure, that or restart the network, but reboot should work
<ogra_> ogra@localhost:~$ ping web.de
<ogra_> PING web.de (82.165.230.17) 56(84) bytes of data.
<ogra_> 64 bytes from bap.web.de (82.165.230.17): icmp_seq=1 ttl=248 time=17.0 ms
<ogra_> ^C
<ogra_> \o/
<ogra_> so i guess just dumping the file into /etc/systemd/system from livecd-rootfs is the quick fix for us
<ogra_> hmm
<pitti> ogra_: ok, great; can you please file that bug and add some seddery to the image build scripts until then?
<ogra_> or not ... better to only change it in the readonly side
<pitti> ogra_: TBH I'd sed it in /lib; having files in /etc in writable is hard to upgrade from
<ogra_> pitti, yeah
<ogra_> so the last network bit is ... why do i get a different ip on first boot ... (or why do i get one at all)
<pitti> ogra_: sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
<ogra_> i guess the NIC should not even go up when console-conf hasnt run yet
<ogra_> pitti, ok
<pitti> ogra_: I think during firstboot there is some catch-all policy that tries to run DHCP on every interface
<pitti> ogra_: do you have more than one?
<ogra_> ogra@localhost:~$ cat /proc/net/dev
<ogra_> Inter-|   Receive                                                |  Transmit
<ogra_>  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
<ogra_>   sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
<ogra_> enxb827eb04db1c:   34780     336    0    0    0     0          0         0    17005     118    0    0    0     0       0          0
<pitti> ogra_: hypothesis: you have two, you get two DHCP responses, and the other one gets a response/the IP first
<ogra_>     lo:   25600     320    0    0    0     0          0         0    25600     320    0    0    0     0       0          0
<ogra_> only one
<ogra_> but yeah, i see the dhcp request before the system even gets to console-conf
<pitti> hm, what does that then
<pitti> I thought console-conf woudl isntall that default policy, but apparently not then
<ogra_> there must be some other default thing
<ogra_> which we priobably want to disable
<pitti> some firstboot something presumably (I hope that defualt policy goes away after console-conf
<ogra_> well, the IP stays after second boot
<pitti> I've seen some "match: { name: "en*" } dhcp4: true" thing somewhere
<ogra_> udev ?
<pitti> no, snappy specific
<ogra_> hmm
<ogra_> note that on this system specifically the snappy firstboot stuff doesnt run
<ogra_> still broken here
<ogra_> so i doubt it is that
<pitti> ogra_: https://github.com/snapcore/snapd/pull/1830/files
<mup> PR snapd#1830: firstboot: only configure en* and eth* interfaces by default <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1830>
<pitti> thta's what I've seen recently
<ogra_> i thought it was cloud-init ... but that is also gone in the current image
<pitti>  firstboot/firstboot.go
<pitti> thus presumably the snappy.firstboot.service thing
<ogra_> right
<ogra_> doesnt run
<ogra_> [  OK  ] Started OpenBSD Secure Shell server.
<ogra_>          Stopping Network Service...
<ogra_> [  OK  ] Stopped Network Service.
<ogra_>          Starting Network Service...
<ogra_> [FAILED] Failed to start Run snappy firstboot setup.
<ogra_> See 'systemctl status snapd.firstboot.service' for details.
<pitti> ogra_: check if it does run when console-conf is active?
<ogra_> [  OK  ] Started Network Service.
<ogra_> it never runs
<pitti> so it did run
<pitti> (failed, sure, but that stil means it could have written the default policy before it failed)
 * mwhudson blinks
<ogra_> (it cant because i dont have a proper model assertion)
<ogra_> mvo, ^^^
<mwhudson> ogra_: snapd.firstboot.service does two things, the first is writing /etc/netplan/01-snapd-config.yaml, the second is the thing that fails
<mwhudson> i'm fairly sure
<ogra_> could indeed be that the model assertion check is only at the end or some such
<pitti> uh, is that still in /etc?
<pitti> this really belongs into /run and removed ASAP
<ogra_> ogra@localhost:~$ ls /etc/netplan/
<ogra_> 00-snapd-config.yaml
<ogra_> ogra@localhost:~$
<mwhudson> pitti: console-conf overwrites it
<ogra_> sadly i cant check what is in there before console-conf
<ogra_> because we dont have the ubuntu user anymore
<ogra_> i cant get in
<pitti> ogra_: systemd.debug-shell
<pitti> Ctrl+Alt+F9
<ogra_> on serial console ?
<pitti> hm, that's tricky indeed :)
<ogra_> heh
<mwhudson> jtag!
 * mwhudson unhelpfuls
<ogra_> well, if we are sure thats the issue, mvo could just rip that out of firstboot.go i guess
<pitti> we need a secret "escape to shell" key in console-conf, clearly :)
<zyga> o/
 * zyga needs a review on https://github.com/snapcore/snap-confine/pull/125
<mup> PR snap-confine#125: Combine mount namespace setup into one function <Created by zyga> <https://github.com/snapcore/snap-confine/pull/125>
<ogra_> sounds like it needs to go anywway
<pitti> ogra_: no, I'm not sure at all
<pitti> with just one NIC there is no reason why the DUID should be different on first boot
<zyga> mwhudson: wanna look?
<pitti> (and received IP)
<zyga> mwhudson: this is just prep work for upcoming mount namespace sharing
<ogra_> pitti, well, if one runs dhclient and the other runs networkd ...
<pitti> unless something calls dhclient manually, instead of networkd
<ogra_> *snap* :)
<pitti> but why would it install a netplan policy and then run dhclient?
<mwhudson> zyga: i want to go to bed unfortunately
 * zyga was about to ping _morphis about it
<zyga> mwhudson: sure, no worries :)
<zyga> mwhudson: I was surprised to see you up so late
 * ogra_ needs to take care of the cats ... back in 10 or so
<zyga> _morphis: ^^ how about you?
<mwhudson> ogra_, pitti: uh is there a /etc/network/interfaces as well or something like that?
<ogra_> mwhudson, nothing in it though
<pitti> no interfaces.d/ either?
<mwhudson> ok good
<ogra_> unless netplan actually wipes it
<zyga> ssweeny: or you perhaps?
<pitti> no, it doesn't, that would be rude
<mwhudson> not unless you ask it to, and we don't
<ogra_> ogra@localhost:~$ cat /etc/network/interfaces.d/
<ogra_> cat: /etc/network/interfaces.d/: Is a directory
<ogra_> ogra@localhost:~$ ls /etc/network/interfaces.d/
<ogra_> ogra@localhost:~$
<ogra_> err
<ogra_> ogra@localhost:~$ cat /etc/network/interfaces
<ogra_> # interfaces(5) file used by ifup(8) and ifdown(8)
<ogra_> # Include files from /etc/network/interfaces.d:
<ogra_> source-directory /etc/network/interfaces.d
<pitti> SLASH SLASH
<ogra_> ogra@localhost:~$
<pitti> (oh, I thought it was hiding the ls results again)
 * ogra_ -> cats ... else my ears blow up
 * mwhudson crashes
 * pitti off to running and lunch, bbl
<mvo> ogra_: firstboot runs correctly but it fails to stamp for some reason, was looking into this
<ogra_> mvo, ah, k, i thought that was the assertion thing still
<mvo> ogra_: I don't know why it fails on pi2, it works on kvm(the firstbot stamp)
<didrocks> mvo: hum, is it known that snap revert doesn't restore the apparmor profile as it should?
<mvo> ogra_: but snap list works, right? if that works and shows snaps then the firstboot stuff worked
<ogra_> mvo, nope
<mvo> didrocks: definitely not
<didrocks> even if the snap was installed in devmode, it's not restored
<ogra_> snap list doesnt work and i see nothing in /snap
<didrocks> installed a snap
<mvo> ogra_: oh, snap changes?
<didrocks> upgraded
<didrocks> snap revert
<mvo> ogra_: snap change 1?
<didrocks> Sep  6 12:21:28 tidus kernel: [16442.393449] audit: type=1400 audit(1473157288.721:3153): apparmor="DENIED" operation="open" profile="snap.face-detection.service" name="/dev/video0" pid=23620 comm="face-detection-" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<didrocks> which was allowed before ^
<ogra_> ogra@localhost:~$ snap changes
<ogra_> error: no changes found
<ogra_> ogra@localhost:~$ snap change 1
<ogra_> error: cannot find change with id "1"
<ogra_> ogra@localhost:~$
<mvo> ogra_: sudo systemctl status snapd.firstboot.service
<ogra_> mvo, http://paste.ubuntu.com/23140968/
<zyga> morphis: hey
<zyga> morphis: around?
<morphis> zyga: yes
<mvo> ogra_: could you pastebin /var/lib/snapd/state.json please? you have not logged into this system yet, right? snap login was not run? because if so, don't pastebin it will contain credentials
<ogra_> {"data":{"patch-level":3},"changes":{},"tasks":{},"last-change-id":0,"last-task-id":0}
<zyga> morphis: https://github.com/snapcore/snap-confine/pull/125
<mup> PR snap-confine#125: Combine mount namespace setup into one function <Created by zyga> <https://github.com/snapcore/snap-confine/pull/125>
<ogra_> mvo, thats all
<ogra_> mvo, and i have run console-config indeed
<zyga> morphis: just small reorg/cleanup so that all the essential mount stuff happens in a spot that is easy to work with once mount namespace sharing shows up
<morphis> zyga: ok, but this doesn't fix the problem with one snap mount sth in /media, right?
<ogra_> pitti, bug 1620559 for you
<mup> Bug #1620559: /etc/resolv.conf is empty on snappy <Snappy:New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1620559>
<zyga> morphis: nope, this is just a cleanup thing
<mup> Bug #1620559 opened: /etc/resolv.conf is empty on snappy <Snappy:New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1620559>
<zyga> morphis: I had a look at the code and I have an idea
<zyga> morphis: I need to investigate it a little further though
<morphis> zyga: ok
<didrocks> mvo: is that enough info for you? https://bugs.launchpad.net/snappy/+bug/1620560
<mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
 * didrocks won't again be able to demo revert next week it seems :/
<mup> Bug #1620560 opened: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
<mvo> didrocks: should be, I will look in a wee bit
<didrocks> thx!
<ogra_> mvo, fix for DNS uploaded ... i'll trigger new ubuntu-core snaps once livecd-rootfs finished
<ogra_> mvo, so should i try to delete the state file and reboot to see what firstboot creates then ?
<mvo> ogra_: please do
<mvo> ogra_: another showstopper :/
<didrocks> mvo: FYI, I try to reload in unconfined mode the profile, but still doesn't work:
<didrocks> Sep  6 12:36:33 tidus kernel: [17346.954285] audit: type=1400 audit(1473158193.260:3432): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.face-detection.service" pid=25891 comm="apparmor_parser"
<didrocks> restarting the service
<didrocks> Sep  6 12:36:54 tidus kernel: [17368.030680] audit: type=1400 audit(1473158214.336:3433): apparmor="DENIED" operation="open" profile="snap.face-detection.service" name="/sys/bus/usb/devices/" pid=25900 comm="face-detection-" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<didrocks> (and others like /dev/video0â¦)
<ogra_> mvo, also, how do i use the model assertion now ? i'm still building with the local one
<didrocks> so can be something wrong in the profile resetted
<ogra_> you said you have one for the pi ?
<ogra_> ogra@localhost:~$ sudo systemctl status snapd.firstboot.service
<ogra_> â snapd.firstboot.service - Run snappy firstboot setup
<ogra_>    Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled)
<ogra_>    Active: failed (Result: exit-code) since Tue 2016-09-06 08:27:33 UTC; 11s ago
<ogra_>   Process: 2431 ExecStart=/usr/bin/snap firstboot (code=exited, status=1/FAILURE)
<ogra_>  Main PID: 2431 (code=exited, status=1/FAILURE)
<ogra_> Sep 06 08:27:27 localhost.localdomain systemd[1]: Starting Run snappy firstboot setup...
<ogra_> Sep 06 08:27:33 localhost.localdomain snap[2431]: error: need a model assertion
<ogra_> ...
<ogra_> mvo, ^^^^
<mvo> ogra_: uhh
<mvo> ogra_: ls /var/lib/snapd/seed/assertions ?
<ogra_> well, the image was built with the locally hacked together assertion
<mvo> ogra_: is that your locally build image ;) or one from me?
<mvo> ogra_: ha!
<ogra_> and with that env var set
<mvo> ogra_: that explains it all
<ogra_> ok
<mvo> ogra_: yeah, you need the real one, check msg
<ogra_> mvo, can i hack that up for pi3 and dragonbaord ro do we need them created
<ogra_> *or
<ogra_> mvo, also, i guess i shouldnt set UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 anymore ?
<mvo> ogra_: well, I can send you one (untested) for the dragonboard, but for pi3 we need to create a new one, that is a bit involving because it needs a special signature
<ogra_> oh, why is that different ?
<mvo> ogra_: we have no signed model assertion for that yet
<ogra_> k
<zyga> didrocks: hey
<zyga> didrocks: about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1620560
<mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:In Progress by zyga> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
<zyga> didrocks: do you have the system that had this issue
<zyga> didrocks: can you pastebin snap changes please
<zyga> didrocks: or add it to the bug report
<zyga> didrocks: and then "snap change 123" where 123 are some interesting events (like revert)
<ogra_> mvo, so now my console-conf hangs at "Contacting store ..."
<ogra_> i assume it is supposed to eventually do something ? (sits there since 5 min now)
<ogra_> oh
<ogra_> now i get an errtor
<ogra_>         error: bad user result: cannot create user "ogra@ubuntu.com": Get
<ogra_>     https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup
<ogra_>                          login.ubuntu.com: no such host
<ogra_> hah
<ogra_> DNS
<mvo> ogra_: yeah, no dns
<ogra_> damn
 * ogra_ waits for livecd-rootfs to finish 
<mvo> ogra_: lets wait for your fix and hope that that was really all we needed
 * mvo lunch
<ogra_> well, i guess i can hack the SD
<ogra_> ah, crap ... not as easy ...
<ogra_> bah .... and now my serial is messed up
<ogra_> \o/
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name         Version       Rev  Developer  Notes
<ogra_> pi2          16.04-0.15    25   canonical  -
<ogra_> pi2-kernel   4.4.0-1021-2  12   canonical  -
<ogra_> ubuntu-core  16.04.1       483  canonical  -
<ogra_> ogra@localhost:~$
<ogra_> mvo, works !!
 * ogra_ installs classic
<ogra_> Processing triggers for libc-bin (2.23-0ubuntu3) ...
<ogra_> (classic)ogra@localhost:~$
<ogra_> whee !
<zyga> didrocks: ?
<zyga> morphis: any chance for that review?
<zyga> morphis: if no I'd like to know now so that I can merge it and iterate
<ogra_> hmm
<ogra_>           error: bad user result: cannot communicate with server: Post
<ogra_>        http://localhost/v2/create-user: dial unix /run/snapd-snap.socket:
<ogra_>                        connect: no such file or directory
<ogra_> thats not so good i suppose
<ogra_> wow
<ogra_> so putting something into writable/system-data/etc/systemd/ will not get me any units in there after first boot
<pitti> ogra_: thanks for the bug report, will prep/upload SRU later (I have a few other things queued anyway)
<ogra_> yeah, no hurry (if the workaround works at least)
<pitti> ogra_: well, the workaround is the fix, it just needs to get into the package properly :)
<ogra_> (and if the PPA publisher ever publishes livecd-rootfs i can actually test it :P )
<ogra_> damn ...
<ogra_> hacking up the image definitely doesnt work
<ogra_> now firstboot fails again
<jgdx> didrocks, hey, how do I debug this: I have a package in build-packages which contents is not in parts/<part>/install
<didrocks> zyga: updated
<jgdx> it's libgsettings-qt-dev and this is some relevant output: http://pastebin.ubuntu.com/23141137/
<didrocks> jgdx: the content is never in parts/<part>/install of build-packages
<didrocks> build-packages are build requirements, they are not installed on the system
 * ogra_ doesnt get it 
<jgdx> didrocks, okay, but it fails none the less: http://pastebin.ubuntu.com/23141141/
<zyga> didrocks: thanks
<didrocks> jgdx: can you make a verbose cmake build? That way, you can see the -I and other includes path
<jgdx> didrocks, okay, but where are those headers located? Should be located*
 * ogra_ sighs ... why do DNS timeouts always take the lifetime of a hamster 
<ogra_> *twiddle tumbs*
<zyga> ogra_: because pidgeons ;-)
<didrocks> jgdx: I think snapcraft unpack them in parts/<partname>/ubuntu/ but upstream can confirm/deny :)
<ogra_> zyga, ha, i knew there was a relation 1
<ogra_> !
<jgdx> didrocks, okay. Can you please name names? :)
<jgdx> didrocks, and here's the verbose make failure: http://pastebin.ubuntu.com/23141161/
<didrocks> jgdx: sergiusens and kyrofa may help you
<jgdx> didrocks, thanks!
<didrocks> yeah, I don't see /ubuntu
<didrocks> yw ;)
<jgdx> sergiusens, kyrofa, could you please take a look at that backlog ^
<jgdx> didrocks, well /ubuntu has a bunch of debs in download, and a couple of files in folders /var and /etc
<jgdx> i.e. no headers in /ubuntu
<didrocks> might be another folder than this one which is for stage-packages then, I didn't look closely at build-packages
 * jgdx re-reads docs on build vs stage packages
<jgdx> I thought -dev packages would go in the build-packages section, but I guess that's not entirely correct
<ogra_> pitti, hmm, the fix doesnt seem to work
<ogra_> oops, i take that back
<ogra_> the store was just veeeeery sloooow
<ogra_> pitti, and FYI, i seem to keep the same IP now
<ogra_> whatever it was, it seems fixed
<ogra_> BAH
<ogra_> ogra@localhost:~$ htop
<ogra_> mkdir: cannot create directory â/home/ogra/snap/htopâ: Permission denied
<ogra_> ogra@localhost:~$
<ogra_> looks like snapd or snap-confine now have issues
<ogra_> sigh
<ogra_> ogra@localhost:~$ ls -lh
<ogra_> total 4.0K
<ogra_> drwxr-xr-x 3 root root 4.0K Sep  6 11:47 snap
<ogra_> GRRRR !
<ogra_> zyga, ^^^^ didnt you fix that one ?
<zyga> I did
<ogra_> well, still there
<zyga> can you reproduce this?
<zyga> I bet that is not snap-confine
<zyga> did you sudo run any snaps?
<ogra_> i'm pretty sure i can ... if your first snap contains a binary that requires to be run with sudo
<zyga> aj
<zyga> I didn't fix that,
<ogra_> i.e. i always install the classic snap first
<zyga> hmmm
<zyga> that was never reported
<ogra_> which requires you to run "sudo classic" to enable the shell
<zyga> right
<zyga> can you plresqe report that
<zyga> snap confine creates the directory as the user
<zyga> but sudo just switches the user
<zyga> ogra_: note that today (unless my memory fails me) snap run may also create the directory
<zyga> mvo: ^^ does snap-run + exec mkdir $HOME/sanp/$SNAP_NAME/{$SNAP_REVISION,$SNAP_COMMON} ?
<ogra_> zyga, bug 1620592
<mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy:New> <https://launchpad.net/bugs/1620592>
<ogra_> now you have a report :)
<mup> Bug #1620592 opened: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy:New> <https://launchpad.net/bugs/1620592>
<zyga> ogra_: thanks
<pitti> ogra_: err, what? it's a kind of maaa-giiic? âª ?
<pitti> ogra_: anyway, thanks for confirming!
<ogra_> pitti, perfect song for this week btw ;)
<zyga> pitti: sudo snap-confine just mkdir's stuff as root
<ogra_> (would have been freddy mercury's 70th yesterday)
<pitti> ooh
<qengho> dang.
<pitti> zyga: sorry, ECONTEXT?
<ogra_> so yay ... we have working pi2 images ... now on to dragonboard ...
<ogra_> (after lunch)
<mvo> zyga: snap run should create the dirs now, yes
<mvo> zyga: once that lands
<didrocks> hum, the store keeps resetting my connection
<didrocks> starting to download ubuntu-core, but then:
<didrocks> - Download snap "ubuntu-core" from channel "stable" (read tcp 10.42.0.81:55008->77.242.195.171:443: read: connection reset by peer)
<didrocks> (after downloading few MB)
<ogra_> peer ! that evil norwegian !
<didrocks> ahah :)
<pitti> ogra_: ... Steinbrueck?
<ogra_> pitti, does he also reset connections ?
<ogra_> i thought he only uses fahrradketten :)
<pitti> ogra_: yes, he has a lot fewer now that he's not a minister any more
<ogra_> true
<ogra_> :)
<didrocks> nessita: any known issue on the store side for those connections to be continuously reset? ^
<didrocks> (and hey! ;))
<nessita> didrocks, not that I know of, but let me check
<nessita> didrocks, and hi! :-) Is this when downloading snaps?
<didrocks> nessita: yeah, snap install <anything>, (trying to download ubuntu-core as first snap installed on this system)
<didrocks> small rpi2 with the cloud image on it
<nessita> didrocks, is this only affecting you or someone else? any chance your ISP is acting up?
<ogra_> "small rpi"
<didrocks> nessita: could be, I tried on my laptop, no issue here
<noise][> didrocks: any strange network hops on your lan?
<ogra_> vs the 1m^2 rpi ?
<didrocks> but it could be something is acting up on my rpi2 connexion
<noise][> from the pi to the world
<didrocks> noise][: none from what I saw, at least, pings aren't lost
<noise][> try a longer tcp/http conn to some other host?
<zyga> pitti: don't worry
<noise][> e.g. download a file from elsewhere (without hidden reconns)
<zyga> mvo: so that with snap-confine and snap-run both doing this, should we do something about it
<didrocks> noise][: ok, trying to wget an iso or so
<ogra_> zyga, definitely .... but not urgent for RTM i'dsay
<zyga> mvo: specifically, about using patching the sudo bug
<noise][> a conn-reset mid download is unlikely to be from the CDN side
<zyga> ogra_: you are right, I will fix that for 1.0.42 after RTM
<didrocks> nessita: noise][: used successfully wget http://cdimage.ubuntu.com/ubuntu/daily-live/current/yakkety-desktop-i386.iso
<didrocks> no drop
<didrocks> could it be that snapd, the go tcp stack is more sensible to small drops?
<mvo> zyga: what is the sudo bug? sorry that I am missing context here
<mvo> zyga: aha, the one ogra reported
<liuxg> ogra_, tomorrow, I will go to office to find a monitor and try it out there. If I can see the display in the monitor, i just login and type anything in the console, it should work, right?
<mvo> zyga: I think snap run fixes that
<mvo> zyga: it does not use HOME, it uses user.Current().HomeDir from go
<mvo> zyga: for the mkdir
<ogra_> liuxg, no, if you see the login prompt you hit enter and it should bring up the config too
<ogra_> mvo, so pi2 looks releasable to me
<ogra_> with latest ubuntu-core
<liuxg> ogra_, I have a USB keyboard at home, can I do it at home now even without the monitor? I insert it into one of the USB port, is this fine?
<ogra_> if you cant see anything ? i doubt it
<liuxg> ogra_, ok, I got it, once I have done it this way, it should work straightforwardly, and I will not do it any more, right? by the way, will this be fixed in the coming releases?
<ogra_> fixed ?
<liuxg> ogra_, I mean in the future, if I flash a new release software, shall I do the same again?
<liuxg> ogra_, for the current pi 2 image, I do not need to do anything like this and it works out of the box.
<mvo> ogra_: ok, creating new test images
<ogra_> liuxg, if you flash an image you alsways need to do the first setup
<ogra_> mvo, a pi3 medel assertion would really help ...
<ogra_> given that it is trivial to create the gadget
<ogra_> (i'm pretty scared about the dragonboard with the 7 partitions ... )
<liuxg> ogra_, thanks. I got it.
<ogra_> liuxg, the console-conf is now a hard requirement ... you need to set up the network and the SSO user
<ogra_> the image gets tied to your store account now
<zyga> tyhicks`: jdstrand: https://github.com/snapcore/snap-confine/pull/126
<mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
<zyga> morphis: ^^
<Kaleo_> mvo, what's the next step with the test-snapd-thumbnailer-consumer snap? :)
<zyga> stgraber: ^^
<liuxg> ogra_, so what is the account for login? my store account or the default "ubuntu"?
<mvo> Kaleo_: I approved it, you just need to publish it now
 * zyga has a few more patches for snap-confine today
<ogra_> liuxg, "ubuntu" is gone ... the firstboot config asks you for your store account ... contacts the store, verifies the credentials and pulls your ssh key from LP ...
<zyga> jdstrand, tyhicks`: this is high priority for me, the code, even if lands, is not live, I just want to find holes in my reasoning along the way
<ogra_> liuxg, and you can only log in via ssh now ... password-less with the ssh key
<zyga> ogra_: fill them with 0s ;)
<ogra_> zyga, whom ?
<Kaleo_> mvo, done, thanks!
<zyga> ogra_: the dragonboard partitions
<ogra_> haha
<ogra_> yeah, i'm sure the board will like that
<zyga> ogra_: it will NOPit ;-)
<jgdx> any way to avoid having this happen? http://pastebin.ubuntu.com/23141319/
<ogra_> heh
<liuxg> ogra_, this is really new to me. so what is the correct ssh command to login? ssh my_canonical_email_address@IP_address?
<ogra_> liuxg, the tool tells you at the end
<ogra_> usually "ssh $LP_NAME@$IP"
<liuxg> ogra_, you mean after I press enter? OK. I will have a try tomorrow, thanks for your kind help :)
<ogra_> it prints it on the screen
<ogra_> after you press enter the tool starts and asks you for the nextwork config
<ogra_> *network
<ogra_> after that it asks for your account data and does the store auth dance... then iit tells you how to ssh into the board
<ogra_> but you really need a working console for this
<liuxg> ogra_, thanks. I understand it better.
<liuxg> ogra_, I do not know why my HDM does not work with my p3. it works with my DELL laptop. The monitor is also a DELL model. it does not work with the p2 as well.
<ogra_> yeah, thats bad ... and you have no TV or some such you could use instead ?
<liuxg> ogra_, I have TV, I am not sure whether it works with it. it is a Samsung model.
<ogra_> well, it should
<liuxg> ogra_, again, thank you!
<ogra_> np
<Kaleo_> mvo, will it take time before it's available to "snap install" ?
<Kaleo_> mvo, oh, no it's instant just it was only published in the edge channel, thanks
<mvo> Kaleo_: correct, almost instant
<mup> PR snapd#1853 opened: osutil: call sync after cp if requested. overlord/snapstate/backend: switch to use osutil instead of another buggy call to cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/1853>
<liuxg> ogra_, I finally see the hdmi output, it firstly showed "no network initialization", and now, it shows 4 strawberry on the screen.
<liuxg> ogra_, I did not see the login prompt, it just showed "No network initialization". I am now flash the image again to see how it works.
<Kaleo_> jdstrand, we have an app in a snap connected to the home interface which requests a thumbnail of an image in the home folder to the thumbnailer service via dbus, the thumbnailer service uses aa_query_label to verify that the app has indeed the rights to read that file and it returns a non 0 value indicating that the app does not have access
<ogra_> liuxg, hit enter
<Kaleo_> jdstrand, have you ever seen that?
<jdstrand> Kaleo_: I'm familiar with that technique. it is going to need to be updated for the snappy world
<liuxg> ogra_, I did that. seems no response. I finally saw 4 red strawberries on the screen. I do not know what happened before. I am making the new disk. By the way, I changed a HDMI input in my monitor, and this one seems working with the pi device :)
<JamieBennett> ogra_, I hear dragonboard images are close, on-track for tomorrow?
<Kaleo_> jdstrand, oh ok. so is that we won't use aa_query_label anymore? or is aa_query_label going to support snappy stuff or something else?
<ogra_> JamieBennett, not at all ... we only just got pi images to work
<jdstrand> Kaleo_: tvoss put together a plan for pulseaudio recording that other trusted helpers should follow
<zyga> jdstrand: o/
<Kaleo_> jdstrand, neat, tvoss you have a link?
<JamieBennett> ogra_, Ah, OK. np for a later release.
<ogra_> JamieBennett, i'm only now starting on the dragonboard gadget .... there were to many basic issues we had to fix first
<ogra_> JamieBennett, and for the pi3 i need someone from niemeyer's team to create a model assertion for me
<ogra_> the pi3 should be a thing of a few minutes
<ogra_> JamieBennett, given that console-conf cant set up wifi yet i guess dragonboard wont be a lot of fun(we dont allow console liogins anymore and the dragon has no wired network)
<JamieBennett> ogra_, makes sense
<ogra_> but i'll do my best to get an image ready today even without network i want to make sure we have something booting
<ogra_> (my hopes are not high though, given how much we had to tinker with ubuntu-image to get the basics for pi2 right)
<jdstrand> Kaleo_ (cc tvoss): it is this I believe: https://docs.google.com/document/d/1mwLfShu3K8LNa1cYySqhM0fp06TZoKygG0bs2KB9Z4I/edit#heading=h.va0l2byp04q9, however it hasn't been approved yet by the snappy team (they/we.ve been working on rtm things for a bit)
<jdstrand> zyga: hey
<Kaleo_> jdstrand, I think I understand what the idea is in that document
<Kaleo_> jdstrand, but I'm not sure what it means for thumbnailer and whether or not it should call aa_query_label
<liuxg> ogra_, I had some output like http://imgur.com/a/2qtcf, does it mean that my ethernet card on the board is not working properly?
<jdstrand> Kaleo_: each trusted helper will need to be examined and transitioned for snappy. several of the trusted helpers on touch like media-hub and thumbnailer had little shortcuts in them like this
<ogra_> liuxg, no, ignore that ...
<Kaleo_> jdstrand, oh, was that a shortcut?
<Kaleo_> jdstrand, I had no idea
<jdstrand> Kaleo_: I can't remember the exact details for thumbnailer otoh
<Kaleo_> jdstrand, ok
<jdstrand> do you have a link to the code?
<Kaleo_> jdstrand, yes, hang on
<ogra_> liuxg, the raspberrys should go away at some point ... or they go away if you hit enter
<ogra_> try it
<liuxg> ogra_,  why is the Net Initialization skippedãduring the boot?  now I see 4 strawberries, I have a USB keyboard, hitting enter takes no effect.
<ogra_> just wait tile the leds on the board stop blibnking wildly
<Kaleo_> jdstrand, http://bazaar.launchpad.net/~unity-team/thumbnailer/trunk/view/head:/src/check_access.cpp#L59
<liuxg> ogra_, OK. I wait for more time ...
<Kaleo_> jdstrand, literally, every time an app asks for a thumbnail via dbus, thumbnailer calls query_file()
<zyga> jdstrand, tyhicks`: https://github.com/snapcore/snap-confine/pull/127/files (much smaller)
<mup> PR snap-confine#127: Don't leak root filesystem when using pivot_root <Created by zyga> <https://github.com/snapcore/snap-confine/pull/127>
<Kaleo_> I was expecting aa_query_label to set allowed to 1 when querying the thumbnail of an image in the home directory _because_ the home interface is connected by the snap who asks for the thumbnail
<jdstrand> Kaleo_: ok, so this is obtaining the security label and then seeing if something running under that label can access the file under its own profile. This seems reasonable in a snappy world. what is the issue you are having?
<Kaleo_> jdstrand, exactly. the issue is that it says that the label cannot access the file
<Kaleo_> jdstrand, allowed = 0
<jdstrand> Kaleo_: what is the file it is trying to access?
<jdstrand> zyga: ok (note tyhicks` won't be on for a little bit yet). also, I'm going to forward you a thread between me and tyhicks` re ssweeny's /run/media mounts not propogating as I think it may play a factor in this rework
<Kaleo_> jdstrand, for example /home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg
<Kaleo_> jdstrand, and I would get things such as Sep  1 18:07:16 tequila com.canonical.Thumbnailer[5162]: thumbnailer-service: [18:07:16.618] Apparmor label "snap.gallery-app.gallery-app" has no access to "/home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg"
<jdstrand> Kaleo_: is that the actual file or is that a sumlink to somewhere?
<Kaleo_> jdstrand, that's an actual file
<jdstrand> Kaleo_: can you paste /var/lib/snappy/apparmor/profiles/snap.gallery-app.gallery-app ?
<liuxg> ogra_, how long should I wait for the boot-up? still the strawberries are there after I hit the enter key. the "green" led is still blinking. I do not know what it does.
<ogra_> green is heartbeat
<ogra_> if only that blinks it should be done
<liuxg> ogra_, the 'red' one is stable now.
<ogra_> stable off ?
<Kaleo_> jdstrand, yep, comign
<liuxg> ogra_, no, iis stable "red", and it is not off
<morphis> zyga: nice!
<Fl1nt> Hi guys, any reason why ubuntu Core is not yet available in a 16.04 fashion??
<liuxg> ogra_, is there anything wrong with my board? the red led is alway on.
<ogra_> that sounds like your SD is broken
<ogra_> liuxg, i really dont get why you still dont have a seriaql cable
<ogra_> it is nearly impossible to work with developer boards without one
<ogra_> and it doesnt realÃ¶ly cost more than $10-15
<liuxg> ogra_, oh, really? then I swith one card. I have no time to buy it. would you please show me the one you get?
<zyga> jdstrand: thank you
<mvo> ogra_: pardon my ignorance, the sudo issue your reported that ~/snap is owned by root? is there a bugreport for tihs?
<zyga> mvo:     - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1620560
<mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:In Progress by zyga> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
<ogra_> liuxg, https://www.amazon.de/gp/product/B00KVUSI30 is the one i have
<zyga> er
<zyga> sorry
<zyga> wrong link
<ogra_> mvo, yes, zyga triaged it already
<zyga> https://bugs.launchpad.net/snap-confine/+bug/1620592
<liuxg> ogra_, thanks. you connect it to serial pins, right? I will buy one.
<mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy Launcher:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592>
<ogra_> liuxg, right
<zyga> jdstrand: thanks, I suspected the same thing when I was changing that code today
<Kaleo_> jdstrand, http://pastebin.ubuntu.com/23141511/
<jdstrand> Kaleo_: it seems there may be a bug in the aa_query_file() call or that the label check needs to be updated for the stacking work. I'm going to need to point you at tyhicks` for this. tyhicks`: http://bazaar.launchpad.net/~unity-team/thumbnailer/trunk/view/head:/src/check_access.cpp#L59 is failing with 'Apparmor label "snap.gallery-app.gallery-app" has no access to "/home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg"' even though snap.galler
<Kaleo_> jdstrand, oki doki
<Kaleo_> jdstrand, thank you
<jdstrand> Kaleo_: np
<jdstrand> zyga: wrt /run/media, is this something that you're able to work on now with your other mount work? (we were pulled in cause you were out). if you need us, we can continue working on it, but personally I'd like to see where your mount work ends up before looking at this again (moving target and all)
<zyga> jdstrand: not today, I need to fix some old issue wrt connect/disconnect in snapd
<zyga> jdstrand: I can work on that after
<jdstrand> zyga: sure, I just meant in general
<jdstrand> ok, thanks
<zyga> jdstrand: yes, sure
<jdstrand> awesome
<zyga> jdstrand: I'd like to review and land snap-confine fixes and features ASAP
<liuxg> ogra_, I used another SD card, and it looks like it is the same.. the red is always  on.. does it mean that the board has problems? it worked initially and used the "ubuntu" to login this afternoon
<jdstrand> zyga: sure, I'm sure tyhicks` and I can do that this morning
<ogra_> mvo, soo ... dragonboard doesnt work ... http://paste.ubuntu.com/23141530/
<zyga> jdstrand: thank you, I'm sure you can :)
<ogra_> mvo, the new gadget.yaml is at snappy-systems/snappy-hub if you want to take a look
<mvo> ogra_: checking
<ogra_> looks like snap prepare-image does expect something ubuntu-image doesnt provide
<ogra_> liuxg, no idea ... without any output from the serial console this is really hard to tell
<ogra_> liuxg, you can change the console= arg to point to tty1 in the cmdline.txt file on the system-boot partition of the SD
<liuxg> ogra_, I do not know what is really happening here. did you ever try to flash the image dated on Aug 23rd? I am not sure whether China great wall has any impact or not when updating/grading.
<ogra_> well, i cant tell you whjat happening without any output
<ogra_> *what's
<john-mcaleely> are there some images for all-snaps on dragonboard somewhere?
<ogra_> and yes, i usually boot my images once before publishing them
<mvo> ogra_: can you point me to the snapdragon snapcraft.ymla please
<jdstrand> didrocks: hi! I'm not sure if you saw, but wondering if whenever you have a chance if you could look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7
<mup> PR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7>
<liuxg> ogra_, by changing the console to tty1, I can see sth on the monitor?
<ogra_> mvo, in the gadget tree on snappy-hub/snappy.-systems
<Fl1nt> anyone?
<ogra_> liuxg, you should
<liuxg> ogra_, I will have a try, thanks
<mvo> ogra_: I mean the kernel
<Kaleo_> jdstrand, (new bug report for reference https://bugs.launchpad.net/snappy/+bug/1620635)
<ogra_> mvo, under meta/gadget.yaml
<mup> Bug #1620635: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
<mup> Bug #1620635 opened: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
<ogra_> mvo, lp:dragonboard-kernel-snap
<ogra_> but that hasnt changed in a while
<mvo> ogra_: thanks
<didrocks> jdstrand: oh I didn't, will have a look later (probably tomorrow morning)
<ogra_> john-mcaleely, probably by end of the week
<john-mcaleely> ah, ok thanks ogra_ :-)
<ogra_> john-mcaleely, theer are some but these are 100% obsolete at http://people.canonical.com/~mvo/all-snaps/
<ogra_> using old gadget, and old image build tool etc
<jdstrand> didrocks: thanks! :)
<ogra_> and are wrongly confiogured
<john-mcaleely> ogra_, understood. I will boot those with caution...
<ogra_> well, they will fall apart
<ogra_> withouot warning
<mvo> ogra_: thanks, debugging
<liuxg> ogra_, so, I change console=ttyAMA0,115200 to "console=tty1,115200", right?
<ogra_> just console=tty1
<ogra_> no speed
<Kaleo_> fgimenez, did you ever have "Error connecting: Cannot autolaunch D-Bus without X11 $DISPLAY" in your spread test due to a service being dbus activated?
<liuxg> ogra_, so the whole line is :dwc_otg.lpm_enable=0 console=tty1 elevator=deadline
<didrocks> jdstrand: thx to you :)
<ogra_> mvo, i have no idea if my gadget.yaml will work or not ... thats the first shot ...
<mvo> ogra_: sure, looking why you get the error
<fgimenez> Kaleo_, nope never saw that before sorry
<Kaleo_> fgimenez, extra question, test snaps need to support multiple architectures?
<fgimenez> Kaleo_, in the old unity test we needed to setup $DISPLAY in the test's enviroment to be able to run ubuntu-clock-app, but not sure how to pipe it to be used by the dbus activated service
<Kaleo_> fgimenez, :/
<fgimenez> Kaleo_, yes, at least amd64 and i386
<liuxg> ogra_, this time, I see the output
<Kaleo_> fgimenez, I must have missed the documentation regarding how to do that: is it both arch in one snap?
<Kaleo_> fgimenez, how is it achieved?
<ogra_> liuxg, right, if the scrolling stops you hit enter and should get the config tool
<liuxg> ogra_, it asks me to input localhost.localdomain login:
<ogra_> that sounds broken
<ogra_> oh, wait, that was an old image ...
<ogra_> try ubuntu ubuntu
<ogra_> but that image will explode with the next auto-upgrade
<liuxg> ogra_, yes it worked
<ogra_> (and you cant really easily prevent the auto upgrading)
<liuxg> ogra_, I do not know why in the first place, it did not show me that
<liuxg> ogra_, what should I do next?
<ogra_> because there was no console= entry for tty1
<fgimenez> Kaleo_, afaik you should build it in the different archs, for i386 i used a vm created with adt-buildvm-ubuntu-cloud -a i386, installed snapcraft in there, built and uploaded the snap
<ogra_> just use it ... but as i said, it will fall apart with the next auto-upgrade
<ogra_> thats all obsolete old stuff
<ogra_> and there is no backwards compatibility
<ogra_> you can try a snap refresh and see what happens after reboot
<liuxg> ogra_, with old image, it was tricky to get it continued there. should I do a refresh?
<Kaleo_> fgimenez, so it's different .snap files, 1 per arch?
<ogra_> fgimenez, geez, so compilcated ...
<ogra_> Kaleo_, just set up a snap in LP for it
<Kaleo_> ogra_, oh how is that?
<ogra_> and have to build all arches (and auto-upload)
<liuxg> ogra_, this time, I get the ip address for the device. waiting for it to boot ..
<ogra_> Kaleo_, go to your bzr or git tree on LP ...
<ogra_> Kaleo_, there is a "create snap package" link
<ogra_> then fill the form :)
<fgimenez> ogra_, good to know, thx! :)
<ogra_> :)
<Kaleo_> ogra_, ahah
<Kaleo_> ogra_, but the snap is part of the snapd git tree
<ogra_> if you saved the form there will be a "request builds" link
<ogra_> oh
<Kaleo_> ogra_, I suppose I can just push a temp tree
<ogra_> well, you could import it to LP git ...
<Kaleo_> ogra_, but what's the manual technique?
<ogra_> or push a tem tree
<Kaleo_> ogra_, is there some documentation?
<Kaleo_> ogra_, is it a single .snap file in the end?
<ogra_> i have no experience with git on LP though
<ogra_> Kaleo_, it is an automagic build and upload to the store
<ogra_> into the channels you picked in the form
<Kaleo_> ogra_, yep, I wonder how I can do that on my machine: build for multiple archs
<Kaleo_> and what the result looks like
<ogra_> it can auto-build on commits otr it can be built manually by manual request ... as you like
<ogra_> you would need actual HW
<davidcalle> Kaleo, afaik, we don't have fat snaps, one build per arch
<ogra_> at least if you dont build for x86 only
<ogra_> for x86 only you could use VMs
<ogra_> or chroots ...
<ogra_> but armhf or arm64 or ppc64el or s390x (which are all supported arches) would need real HW
<kyrofa> nhaines, hey, thanks for taking Nextcloud for a spin!
<kyrofa> nhaines, it's not really out of date-- 10 was literally just released! I'm giving it a little time before I update it in the snap so all the kinks can be worked out
<kyrofa> Because every snap automatically updates. Don't want to be too close to the bleeding edge
<kyrofa> nhaines, so yes, that snap is officially maintained by nextcloud-- it'll be updated soon
<Kaleo_> ogra_, oh ok, so there must be a trick in the store to upload each arch specific snap file
<ogra_> Kaleo_, no. you just upload them
<Kaleo_> ogra_, and it will detect it automatically ok
<ogra_> yeah
<Kaleo_> ogra_, thanks
<ogra_> np
<Kaleo_> ogra_, is that the same way for clicks??
<ogra_> Kaleo_, i dont think so
<ogra_> but it has been quite a while since i touched clicks
<ogra_> perhaps it changed
<Kaleo_> ok
<ogra_> mvo, oooh
<ogra_> Fetching drangonboard-kernel
<ogra_> error: cannot find snap "drangonboard-kernel": snap not found
<niemeyer> sergiusens: The release command doesn't take more than a single channel?
<ogra_> drangonboard != dragonboard ...
<niemeyer> sergiusens: Hello, btw! :)
<ogra_> mvo, so i fear we need a new model assertion
<mvo> oh, typo!
<sergiusens> niemeyer that is how it was spec'ed; I brought it up in Heidelberg, but we haven't had time to finalize on the change
<ogra_> yeah
<ogra_> reading the error 200 times helps :P
<sergiusens> it is contradictory with the release command which does take multiple channels
<niemeyer> sergiusens: I think people just assumed it would be obvious
<niemeyer> sergiusens: The fact we don't have closing also makes the problem worse
<sergiusens> niemeyer I am waiting on `close` to be finalized store side
<mvo> ogra_: just edit and fix for now
<mvo> ogra_: and pass the environment to skip
<niemeyer> sergiusens: Yeah, the tricky bits are definitely on the store side
<mvo> ogra_: this should unblock you to test if it boots
<ogra_> hmm, k
<niemeyer> sergiusens: Can we have the release command fixed soonish meanwhile?
<mvo> ogra_: in the meantime I trigger a new assertion
<niemeyer> sergiusens: I can easily script it locally, but it feels bad to force everybody to be using that UI
<ogra_> mvo, yeah, i dont belive it will produce something bootable ... but you never know :)
<ogra_> yeah, next weeor
<ogra_> error: cannot find boot config in "/tmp/tmp2moc952b/unpack/gadget"
<ogra_> *error
<niemeyer> sergiusens: Given the precedence on --release, the comma-separated list would be fine I think
<ogra_> oh, you need that awful dangling symlink in the gadget snap
<ogra_> sigh
<ogra_> who came up with that
<sergiusens> niemeyer err, sorry, you can release to multiple channels on puch `snapcraft push <snap-file> --release <channel1,channel2,...>`; you cannot `snapcraft release` to multiple channels; but I can add the same semantics as `push` if we agree to that
<sergiusens> the implementation is not really the problem, it is not going overboard on the UX to the point it becomes confusing to all
<sergiusens> niemeyer an hello back at you :-)
<sergiusens> niemeyer I'll get to it and will be there in 2.17 (next release)
<sergiusens> niemeyer I hope close is finalized too in order to have that in as well
<niemeyer> sergiusens: Yeah, same semantics of --release is sensible.. I actually tried that locally precisely due to the docs on --release
<mup> Bug #1620650 opened: After installing krita from beta channel, krita crashes when opening the snap. <Snappy:New> <https://launchpad.net/bugs/1620650>
<mhall119> ogra_: I've created https://bugs.launchpad.net/snappy/+bug/1620650 how do I link it to the upstream bug report?
<mup> Bug #1620650: After installing krita from beta channel, krita crashes when opening the snap. <Snappy:New> <https://launchpad.net/bugs/1620650>
<ogra_> error: cannot find boot config in "/tmp/tmpbh08e912/unpack/gadget"
<ogra_> COMMAND FAILED: snap prepare-image --channel=edge  dragonboard-model.assertion /tmp/tmpbh08e912/unpackuncaught exception in state machine step: [1] prepare_image
<ogra_> mvo, ^^^
<ogra_> mvo, what exactly is it looking for ?
<SamYaple> sergiusens: python plugin has been working amazingly! The pyc files still stick around but I have a solution for that as soon as you finish up the plugin
<SamYaple> the recursive find isn't working
<ogra_> mhall119, also affects project or allso affects distribution/package ... one iof them should offer you an url entry
<zyga> ara: is there any system that has modern-ish nvidia hardware and intel graphics that I could ssh into to do some testing and poking?
<mvo> ogra_: uboot.conf in the gadget root dir
<mvo> ogra_: a symlink to uboot.env is sufficient
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$ ls -l uboot.conf
<ogra_> lrwxrwxrwx 1 ogra ogra 9 Sep  6 16:30 uboot.conf -> uboot.env
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$
<mvo> ogra_: this will probably go away soon, right now its needed
<ogra_> it is there
<mvo> ogra_: ok, let me check
<ogra_> i took the pi2 as example :)
<mhall119> ogra_: distro/project offers me a URL, but won't let me choose ubuntu/calligra
<ogra_> mhall119, well, then i have no idea
<mhall119> "Bug watches can not be added for Ubuntu, as it uses Launchpad as its official bug tracker. Alternatives are to add a watch for another project, or a comment containing a URL to the related bug report." is what LP gives me
<ogra_> didnt you say upstream ?
<cjwatson> mhall119: upstream would be calligra, not ubuntu/calligra
<ogra_> right
<mhall119> cjwatson: is there a way to not include a distro?
<cjwatson> mhall119: select "Also affects project", not "Also affects distribution/package"
<cjwatson> I would love to rewrite that UI
<ogra_> +1
<cjwatson> well, I say "love"
<ogra_> :)
<mhall119> oh, ok, so after choosing just the package, then it takes me to a new screen where I can link the upstream bug
<cjwatson> choosing just the *project*, not the package
<cjwatson> best to keep that straight in your head
<cjwatson> but yes
<mhall119> you overestimate my head :)
<mhall119> done and done, thanks cjwatson and ogra_
<pstolowski> didrocks, hey, we're trying to repro #1620560 (no luck so far), can you attach your snapcraft.yaml so that we test the same scenario?
<mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
<ogra_> mvo, hmm, could it be a prob that the dragonboard gadget is arch all ? i see pi2 is arch armhf
<mvo> ogra_: hm, one sec, I thnk I have an idea
<jdstrand> tyhicks: fyi, going through email, Kaleo_ filed this for that thumbnailer issue: https://bugs.launchpad.net/bugs/1620635
<mup> Bug #1620635: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
<ogra_> a dragon borat !
<ogra_> http://www.clothestopose.co.uk/ekmps/shops/clarke/images/welsh-dragon-mankini-106-p.jpg
<tyhicks> jdstrand: thanks - he pinged me
 * tyhicks looks at it now
<mvo> ogra_: hm, typo in my u-d-f script
<mvo> ogra_: can you please bzr pull, you should get r300
<ogra_> u-image you mean ?
<mvo> ogra_: that should fix this issue
<ogra_> sure
<mvo> ogra_: in my u-d-f code
<ogra_> u-d-f ?
<ogra_> i dont use u-d-f
<mvo> ogra_: ubuntu-image?
<ogra_> yes, indeed
<ogra_> i used ubuntu-image all day ... the pi2 images i tested were build using u-image
<mvo> ogra_: sweet
<mvo> ogra_: ok, let me try that
<ogra_> so i'm doing the same for the dragon borat now :)
<dpm> that sounds like a fun combination...
<ogra_> dpm, http://www.clothestopose.co.uk/ekmps/shops/clarke/images/welsh-dragon-mankini-106-p.jpg
<ogra_> ;)
<mvo> ogra_: the yaml parser of u-i is unhappy, let me have a look at this
<ogra_> k
<dpm> why did I know I shouldn't have clicked on that link?
<ogra_> hahaha
<dpm> :)
<mvo> ogra_: give me some more minutes, I think I'm getting closer
<ogra_> no hurry ... i'll get some fresh coffee and such
<mvo> sounds good
<mvo> tea
<mvo> hmmmmm
<ogra_> :)
<mup> PR snapd#1854 opened: Generate account-key-request "since" header in UTC <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1854>
<mup> PR snapd#1855 opened: overlord/boot: have firstboot support assertion files with multiple assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1855>
<mvo> ogra_: its tricky, slowly getting closer
<liuxg> ogra_,  I just refresh my system, and after boot, it stops at the screens http://imgur.com/a/MNkQJ  the progess is 20% and it stops there.
<mvo> ogra_: I pushed a new dragonboard gadget snap with some yaml fixes, can you please give it a go? with that my ubuntu-image can build an dragonboard image (no idea if it boots of course)
<ogra_> mvo, did you push the changes to the branch ?
<ogra_> oh
<ogra_> i shouldnt have taken the pi2 stuff blindly :P indeed it also needs the gpt type
<ogra_> yup. seems that built
<ogra_> mvo, not even a burp on the serial console with that image
<ogra_> mvo, and it seems the order is a complete mess
<ogra_> looks like the vfat is sdc1
<mhall119> nessita: the krita developer keeps encountering this bug: https://bugs.launchpad.net/software-center-agent/+bug/1620679
<mup> Bug #1620679: Store emails incorrectly state that beta/edge packages are published when they are not <Software Center Agent:New> <https://launchpad.net/bugs/1620679>
<ogra_> mvo, is the yaml processed from bottom to top ? do i need to reverse the entires ?
<nessita> mhall119, let me see
<mvo> ogra_: I pushed everything to the bracnh
<mvo> ogra_: it was incorrect structure and the gpt uuid for the vfat thing
<ogra_> yeah, i see that
<ogra_> but still ... the vfat ends up as first partition
<nessita> mhall119, will try to have someone working on it
<ogra_> mvo, i'm also Ã¼pretty sure that content: wont work if we need img files dd'ed
<ogra_> mvo, at least by the definition in https://github.com/CanonicalLtd/ubuntu-image/blob/gadget-yaml/docs/gadget-yaml.rst
<SamYaple> what is the best practice way to run arbitary commands shell when building a snap?
<ogra_> hmm, no, i was on an old copy
<ogra_> content: image:_ is correct
<mvo> ogra_: oh, I don't claim it will work :)
<mvo> ogra_: just that its now correct yaml that u-i understands
<ogra_> mvo, well, why is the vaft the first partition ?
<ogra_> *vfat
<ogra_> and actually the only partition
<mvo> ogra_: you sound like I might have any idea ;)
<ogra_> seems it didnt even bnother to create anything but the vfat
<mvo> ogra_: heh
<mvo> ogra_: maybe just not implemented yet? let me look at the code
<mvo> ogra_: you can still use u-d-f ;)
<mvo> ogra_: I can create you an image I think, but let me first look at u-i
<ogra_> well, given u-i works for everything else it would be nice to have it work here as well
<mhall119> thanks nessita, it's not a blocker, but I do have to keep reminding him to go in and hit the publish button
<ogra_> err
<ogra_> Number  Start (sector)    End (sector)  Size       Code  Name
<ogra_>    1            2048         7812466   3.7 GiB     FFFF  sbl1
<ogra_> now thats curious
<nessita> mhall119, yeah, makes total sense, already asked psivaa to take a look :-)
<ogra_> it created a 3.7G partition
<mvo> ogra_: yeah, looks totally bogus
<ogra_> i have the feeling the structure parsing is all wrong ... it took the name of the first entry but applied everything from the vfat
<psivaa> nessita: mhall119: i'll start working on it straightaway
<ogra_> and obviously ignored any of the size entries
<mvo> ogra_: its not totally wrong, if you pass "-w /tmp/workdir" you can see under /tmp/workdir/.images that the partitions are created, not sure if sizes etc are correct, but there is something there
<didrocks> pstolowski: really? and you are installing a snap that requires special permissions?
<pstolowski> didrocks, a snap that requires a specific dbus path
<pstolowski> didrocks, zyga tried too with some other snap (not sure about the details), no luck either
<ogra_> mvo, well, the GPT doesnt know about them
<bull_> guys :) i set up daily build for snapcraft-gui on launchpad which grab fresh code from github repo , build the code and publish the debian binary to my PPA :) so you can add repo to check how hot the gui version f snapcraft is :P
<didrocks> pstolowski: I can even push you the snap files directly
<didrocks> uno momento
<pstolowski> didrocks, even better
<bull_> read more here :P    https://github.com/keshavbhatt/snapcraft-gui#install-on-ubuntu-1604-and-above
<sergiusens> SamYaple good to know, I'll fixup the py2/3 check and it should be mostly ready
<ogra_> mvo, what should -w /tmp/workdir do ? i dont see u-i create anything in /tmp
<mvo> ogra_: yeah, not arguing that its buggy :) just saying its not totally off, it does something correct
<sergiusens> SamYaple interesting that the pyc stuff doesn't work as there is an integration test there, it might be busted if it truly isn't :-(
<mvo> ogra_: it should keep its temp files there so that this can be inspected
<ogra_> weird
<ogra_> it doesnt
<didrocks> pstolowski: you just need a webcam (to ensure it initializes)
<didrocks> pstolowski: so, http://people.canonical.com/~didrocks/tmp/face-detection_1.0_amd64.snap and http://people.canonical.com/~didrocks/tmp/face-detection_2.0alpha1_amd64.snap
<pstolowski> didrocks, k
<SamYaple> sergiusens: oh. hmm. well ignore what i said for now and ill dig into it. if there is a test, it probably is me doing something wrong
<didrocks> pstolowski: install 1.0 with --devmode, then 2.0alpha1 with --devmode
<mvo> ogra_: oh, if you use the snap you need a different dir than /tmp - you get a private snap tmp
<didrocks> and then revert, and see the denial in syslogs
<mvo> ogra_: on a tempfs
<mvo> ogra_: so stuff will be created there but you won't see it
<ogra_> ah
<mvo> ogra_: super confusing when working on classic :/
<didrocks> pstolowski: if you want to enable camera, use face-detection --enable-camera
<didrocks> pstolowski: you even have a web interface on localhost:8080 ;)
<didrocks> pstolowski: keep me posted
<sergiusens> SamYaple well now that there we use pip for everything we can also just add --no-compile
<sergiusens> I think that would do the trick
<pstolowski> didrocks, oki. now i wonder if --devmode is relevant. i tested mine in strict
<bull_> damn
<mup> PR snapd#1856 opened: asserts: required account key name header <Created by emgee> <https://github.com/snapcore/snapd/pull/1856>
<didrocks> pstolowski: could be
<bull_> who is mup :D
<ogra_> mvo, right, nopw i see it creates part 0-7 and root
<didrocks> sergiusens: oh hey! I think you didn't consider golang module in the go plugin which compiles some C code, correct? (like using pkgconfig)
<mvo> ogra_: yeah, I add some debug now, I think its all broken
<mvo> ogra_: ;)
<ogra_> as usual :P
<Fl1nt> guys, what kind of isolation security can we expect from snappy?
<SamYaple> sergiusens: yea i added it locally, but that still leaves around pyc files
<Fl1nt> I mean, do snappy rely on seccomp for example?
<SamYaple> sergiusens: its still something that i was planning on adding
<SamYaple> sergiusens: speeds up install
<Fl1nt> is there an official documentation related to this sec topic?
<ssweeny> jdstrand, did you get anywhere with the shared mount stuff?
<jdstrand> Fl1nt: we use a bunch of technologies in combination for strong confinement. seccomp is one, yes. you might be interested in https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
<Fl1nt> jdstrand: nice one thx :D
<jdstrand> ssweeny: yes. tyhicks and I narrowed it down to how '/' was mounted and tyhicks came up with a possible solution. zyga is reworking the mount stuff and we've forwarded our investigation to him
<jdstrand> Fl1nt: np
<ssweeny> jdstrand, awesome, thanks for looking into this!
<ssweeny> zyga and tyhicks too
<jdstrand> yes, everyone should be thanked :)
<Fl1nt> I'm a beginner on snappy but it catch my eyes as I really think of it as a perfect mix between LXD and Docker, additionally, if coupled with some sort of orchestrator and a A/B partitioned system it could became a perfectly fitting solution on my side project ^^
<pstolowski> didrocks, ok. easily reproduced with your snaps
<SamYaple> Fl1nt: yep you are not the only one
<mup> PR snapd#1857 opened: tests: add spread test that ensures running a snap as root does not create aâ¦ <Created by mvo5> <https://github.com/snapcore/snapd/pull/1857>
<SamYaple> Fl1nt: there are dozens of us!
<mup> Bug #1620693 opened: Permission denied to access /sys/kernel/mm/hugepages/ <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1620693>
<Fl1nt> The opposite would have been really bizarre :D I think I'll dig a little bit more on it and see if my project can be based on it.
<Fl1nt> Does snapd using "interfaces" too as the snaps can provides or consumes them?
<didrocks> pstolowski: and not with another one with --devmode?
<didrocks> pstolowski: at least, good that you can reproduce :)
<pstolowski> didrocks, i haven't tried my dummy snap with --devmode yet
<SamYaple> Fl1nt: yea. look at 'plugs'
<mup> PR snapd#1840 closed: many: use symlinks instead of wrappers <Critical> <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1840>
<didrocks> pstolowski: I would love to remove --devmode, but there are 2 issues I'm getting: sqlite3 is doing chown when run as root (but chowning to euid which is 0 as well) and seccomp denies it
<didrocks> I think we discussed with jdstrand having fchown apparmor mediation to allow fchown if uid == euid
<mhall119> is there a way to upgrade a snap I installed from the beta channel to the version in the stable channel?
<mhall119> or do I have to uninstall and reinstall?
<didrocks> pstolowski: the other issue is that opencv tries to list the available webcams via /sys/bus/usb/devices
<Fl1nt> SamYaple: Thx ! really nice so! Anyone aware of a community project trying to create a "snap cloud" orchestrator?
<didrocks> I don't think we have an interface to allow that (zyga?) ^
<didrocks> mhall119: snap refresh --channel=beta doesn't work?
<mhall119> didrocks: ah, that works
<mhall119> I tried it with snap install, but not snap refresh
<zyga> ssweeny: it won't happen today though, probably down the week
<popey> dpm: lets move here :)
<ssweeny> zyga, that should be fine
<liuxg> ogra_, is bluetooth enabled on pi 3? thanks
<ogra_> liuxg, no idea
<ogra_> the firmware should be there ...
<liuxg> ogra_, I cannot connect it. strange. the same software works on Desktop
<SamYaple> Fl1nt: I am not. im pretty close to that area too
<liuxg> ogra_, how can I check whether it is enabled or not?
<ogra_> no idea
<ogra_> and i have not the time right now to dig into this
<popey> dpm: doing a make VERBOSE=1, to see if I can figure out where it's breaking
<Fl1nt> SamYaple: My heart is bouncing between bootstrapping one and attaching myself to an Openstack/K8S or Nomad related project
<mvo> ogra_: sorry, dragonboard parititioning is in a really bad state, that is something for barry or slangasek to look at, it looks like the way u-i drives sgdisk just does not quite work (or our gadget.yaml is broken :)
<jdstrand> didrocks, pstolowski: now that we have seccomp arg filtering support in snap-confine, I will be adjusting the policy for these sorts of things. I just need to get to some rtm items first
<ogra_> i would not be surprised if it was both :)
<ogra_> mvo, well, slangasek is back tomorrow iirc
<slangasek> or today
<popey> got it dpm - cd /home/alan/tmp/ubuntu-terminal-app/build/src/plugin/qmltermwidget && cp /home/alan/tmp/ubuntu-terminal-app/src/plugin/qmltermwidget/src/qmldir /home/alan/tmp/ubuntu-terminal-app/build/src/plugin/qmltermwidget/../QMLTermWidget
<popey> dpm: ^ that (whatever it is) is puting the qmldir file as QMLTermWidget
<slangasek> but I think you have a few critical bugs filed against ubuntu-image itself that I need to work through before I start taking a look at the dragonboard gadget snap
<jdstrand> didrocks: I think you can use the camera interface for that now
<jdstrand> didrocks: (the usb cameras one)
<didrocks> jdstrand: great to hear that's on its way (for fchown)
<didrocks> jdstrand: hum, I'm using the camera interface, but it doesn't give access to listing this /sys dir
<dpm> popey, ack
<jdstrand> didrocks: I made updates to camera recently for that
<ogra_> slangasek, well, i have a working pi2 image here ... built with u-image ... i just tested lvm ... that sadly blows up with having grub.cfg mounted under /boot/uboot ...
<didrocks> jdstrand: ah, maybe not released yet?
<ogra_> s/lvm/kvm/
<jdstrand> didrocks: actually, it will probably be in 2.15
<didrocks> snap    2.13+ppa207-1
<didrocks> snapd   2.13+ppa207-1
<jdstrand> its committed in trunk
<jdstrand> it's
<didrocks> jdstrand: ok, sounds excellent then! I thought it would be a security issue to be able to list every usb devices on the system, but it's not?
<slangasek> ogra_: your gadget.yaml is using things like 'size: 16' for a partition whose contents are 16k in size; size without suffix is bytes, not K.  That's probably the issue here
<popey> dpm: got it to build by removing the file QMLTermWidget and mkdiring it before running make
<ogra_> slangasek, trying to builod a dragonboard image with the new gadget gets me a single partition image though ...
<dpm> that somehow rings a bell
<ogra_> slangasek, hmm, that might indeed be
<dpm> popey, I think I had this problem quite a while ago,
<popey> dpm: it runs too, from the build dir.
<SamYaple> Fl1nt: if you go openstack, youll have to deal with nova. it hasn't worked to well for the docker plugin, so keep that in mind
<jdstrand> didrocks: it is. '# Allow detection of cameras. Leaks plugged in USB device info'
<slangasek> ogra_: we will be doing further work to toughen up the parsing to reject such things, and I'll also make a note to update the docs to document this
<dpm> not with terminal but can't remember what I had to do
<popey> heh
<jdstrand> didrocks: but camera is not auto-connected, so we allow the info leak for now
<popey> dpm: wonder if shipping an empty QMLTermWidget is sufficient
<bulldog> hi popey
<popey> hello bulldog
<popey> bulldog: hows things?
<ogra_> slangasek, WELL, FEEL FREE TO MAKE CHANGES AS NEEDED TO TEH GADGET
<ogra_> EEEK
<nacc> heh
 * ogra_ rips off the caps key 
<bulldog> popey, i  i set up daily build for snapcraft-gui on launchpad which grab fresh code from github repo , build the code and publish the debian binary to my PPA :) so you can add repo to check how hot the gui version f snapcraft is :P
<slangasek> ogra_: ENOTIME, working on ubuntu-image itself today
<ogra_> ok
<popey> bulldog: nice, now make a snap ã
<didrocks> jdstrand: makes sense! Thanks for those good news :)
<Fl1nt> SamYaple: That exactly why I'm so reluctant to work on an additional project for OS indeed :D But I deeply think that OS is the most closest project to what's enterprises are waiting for in terms of infrastructure management.
<ogra_> slangasek, but note that with mvo's tree everything seems to work rather well already
<bulldog> popey,  snapcraft-gui is capable of doing almost everything now
<ogra_> slangasek, also, we wont need cyphermox' cloud-init tree merged it is now disabled in ubuntu-core
<bulldog> popey, i will try to write snapcraft recipe for it , and will snap it with snapcraft-gui :D
<popey> :)
<popey> Snap-Inception!
<kgunn> anyone ever seen something like this?
<kgunn> Sep  6 16:19:57 localhost ubuntu-core-launcher[3625]: *** buffer overflow detected ***: /snap/mir-client/x1/usr/lib/aarch64-linux-gnu/qt5/examples/quick/demos/clocks/clocks terminated
<mvo> slangasek: is it bytes? it seems like its blocks or something, when I look at the .disks dir its not 16 bytes :)
<ogra_> slangasek, there is supposed to be some external switch later to switch it on ... current images wont run it
<mvo> slangasek: well, I guess it does not matter, its wrong, thats for sure in the gadget.yaml
<kgunn> e.g. is that the ubuntu-core-launcher complaining?
<kgunn> or mir-client
<slangasek> ogra_: and then what happens when we turn cloud-init back on in a later version of ubuntu-core, and we have all these deployed images in the wild with no cloud-init preseed?
<bulldog> popey, ppa:keshavnrj/snpacraft-gui if u wana try it :)
<popey> bulldog: maybe later, thanks
<bulldog> np
<slangasek> for that matter, how are we supposed to produce a working cloud image for testing without the use of cloud-init?
<ogra_> slangasek, we wont turn it on in core
<ogra_> slangasek, u-image or the gadget will toggle that
<ogra_> so only if you build a new image from scratch you can have cloud-init
<slangasek> hmm, ok
<slangasek> I guess that works
<ogra_> and then apply the config correcvtly
<slangasek> mvo: <cough> rounding
<ogra_> so we dont need all these workarounds we used to have
<Fl1nt> ogra_, slangasek, please don't remove cloud-init from ubuntu-core as a way to programatically provision such a node before having at least provided an alternative tool :-(
<mvo> slangasek: LOL
<slangasek> mvo: it's quite possible the dragonboard snap will still fail even after we fix the definition, there *may* be some assumptions in the current code that partitions will always be multiples of 1M in size
<ogra_> Fl1nt, it isnt removed, only disabled ...
<mvo> slangasek: yeah, I think I saw that in the code
<Fl1nt> ah, ok, didn't understood it that way :D
<ogra_> Fl1nt, it caused unbearable boot times and lots of issues on the actual images
<Fl1nt> is a gadget a preferred way to provision a specific ubuntu-core flavored node?
<Fl1nt> +using
<ogra_> the gadget is your image definition
<slangasek> ogra_: were there unbearable boot times separate from us not having the cloud-init metadata in place telling it not to go wandering around the network?
<zyga> tyhicks: will you have the tie
<zyga> tyhicks: will you have the time to review the ns sharing patch today?
<ogra_> slangasek, well, you never booted a beaglebone image ;) but no this specific one was the network thing
<Fl1nt> Ok, so I'll try to change the way I create my ubuntu-core images
<ogra_> taking about 5mins to time out every boot
<ogra_> Fl1nt, there will only be one way :)
<ogra_> Fl1nt, you will have your specific gadget for cloud images ... and that will also allow you to apply your cloud-init config
<Fl1nt> No, I mean, the way I start a node with a default ubuntu-core for x86 and then use cloud-init to specialise it. I'll rather use a gadget to describe my final intended image
<slangasek> ogra_: ok, well, it seems odd to me that a decision was made to make cloud-init enablement a toggle, adding another layer of complexity to the system, when the fix for that cloud-init behavior on top of u-i was in progress
<ogra_> slangasek, but there is no good reason to use cloud-init at all for images that dont have cloud specific setups
<ogra_> slangasek, console-conf gives us all we need
<ogra_> for images on real HW at least
<slangasek> ogra_: console-conf gives you the interactive experience, it doesn't give you the preseeded-in-the-image experience
<ogra_> andf on the arm images it really slows down the boot to run cloud-init
<ogra_> (and tit runs *every* boot)
<slangasek> well, ok
<slangasek> but "it runs every boot" should be fixed, not papered over
<ogra_> i thought thats a design thing
<ogra_> you can not have it not run
<slangasek> and now you will have to separately say "yes, turn on cloud-init" and "here's some image pre-configuration to be passed into cloud-init"
<zyga> is there any desire to rewrite cloud-init in C or something similar?
<slangasek> I don't believe it's a design decision
<Fl1nt> zyga: an alternative from CoreOS written in GOlang is available
<ogra_> slangasek, well, if i want non-interactive config i need cloud-init
<zyga> Fl1nt: is it feature complete/
<ogra_> and the gadget should define that
<Fl1nt> zyga: so far from my (little) experiments it is.
<Fl1nt> It can manipulate network, files, payloads, systemd etc
<slangasek> Fl1nt: however, we are defining new cloud-init schemas as part of snappy for things that don't previously exist
<Fl1nt> ah, didn't know that :)
<slangasek> in general, cloud-init is actively developed, so switching implementation languages is not as simple as just grabbing one from somewhere else
<ogra_> slangasek, in any case ... whatever we release as RTM doesnt really matter ... niemeyer told me yesterday that it is fine if users have to re-flash to get to GA so even if we go fully back to cloud init oon the fly thats fine ... users will then have to re-flash
<ogra_> (contrary to how i understood RTM i.e. that there wouldnt be any re-flashes anymore)
<slangasek> ogra_: "RTM" being "release to manufacturer", how is it fine for upgrades to require re-flashes again?
<niemeyer> ogra_: I didn't say it was fine.. I said we would do it if we really had to, but we're trying not to
<ogra_> so we seem to have all wiggle room we might need
<slangasek> ah, I see the message has been diluted by a game of telephone ;)
<ogra_> hmm
<mvo> ogra_: meh, now I get an "sbl1.mbn : permssion denied error" when building the dragonboard
<ogra_> huh ?
<ogra_> permission denied ?
<niemeyer> slangasek: We don't (I don't, at least) expect those images to be in final devices, btw.. I'm not a fan of RTM/GA language, but I lost that specific argument
<ogra_> the file is world readable in the gadget
<slangasek> niemeyer: hmm, ok
<tyhicks> zyga: I think jdstrand was going to try to help you out with reviews - do you want me to look at that specific one?
<zyga> tyhicks: either of you should look at it, jdstrand said he will in a couple of hours
<zyga> tyhicks: I just want to know someone will soon, that's all
<jdstrand> well, I said in a little bit
<jdstrand> I suspect it will be sooner than that when I will start :)
<tyhicks> zyga: we'll make sure that at least one of us have a look today
<zyga> thanks guys :)
<bulldog> mhall119,  hi :)
<jdstrand> zyga: so, mountinfo module is merged. the lxc pivot_root is closed. the new pivot_root is merged. the one you want to have us look at is https://github.com/snapcore/snap-confine/pull/126 (cc tyhicks) ?
<mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
<zyga> jdstrand: yes
<jdstrand> ok
<zyga> jdstrand: thats the essence, the stuff following up after that will be trivial applications of those functions in main()
<mhall119> hello again bulldog
<bulldog> wow :P mhall119  i thought u not here
<bulldog> mhall119, i made ppa for snapcraft-gui on launchpad , which auto build code from github
<sborovkov> Hello. Just tried installing snap from the private store. And had this - panic: user: unknown userid 1000. There is also stack trace. Is this like known issue? (snap did install in the end though)
<sborovkov> Oh cool. This made system go crazy as well. Login service's no starting after restart.
<mhall119> sborovkov: what private store are you referring to?
<Fl1nt> ok guys, have to been AFK a while, see you and many thanks for those intels ;-)
<mhall119> and what package did you install?
<ogra_> mhall119, i bet one from his company store :)
<sborovkov> indeed
<sborovkov> I think I've been running in this for couple of days already. Before did not see it in real time
<sborovkov> but after restart login service would hang and refuse to start
<sborovkov> and I can't even switch TTY with attached keyboard.
<ogra_> sborovkov, the ubuntu user was dropped ... (though if you upgraded the entry should still be there) and the login prompt gets intercepted now until you ran the manual configuration tool
<ogra_> sborovkov, if you hit enter you should get into a config dialog
<mup> PR snapd#1858 opened: interfaces: add stub selinux backend <Created by zyga> <https://github.com/snapcore/snapd/pull/1858>
<sborovkov> ogra_: hmm. problem is my snap shows full screen now. Can't see anything besides that. So ubuntu user is dropped on classic as well?
<ogra_> (though the new user this sets up will not have a local login ... )
<sborovkov> How do I run manual config tool?
<ogra_> we never had an ubuntu user on classic :)
<jdstrand> _morphis: fyi, I left feedback in https://myapps.developer.ubuntu.com/dev/click-apps/5870/
<ogra_> sborovkov, good question ... i dont think anyone took into account that there could be a snap grabbying the tty before the console-conf tool can run
<jdstrand> roadmr: hey, can you pull r737? this is semi-urgent. there were a couple of debug print statements that I think trip up the store
<sborovkov> ogra_: o_O are you sure there was no such user
<ogra_> yes
<ogra_> unless you create it
<sborovkov> ogra_: I mean I just flashed that image and logged in with ubuntu/ubuntu
<roadmr> jdstrand: ooh sure
<ogra_> classic usually runs an installer or an oem configurator that allows you to pick your own user name
<jdstrand> _morphis: fyi ^
<ogra_> either the debian-installer for non graphical or ubiquity fo rgraphical installs
<sborovkov> ogra_: hmm. alright. https://wiki.ubuntu.com/ARM/RaspberryPi I was always using ssh ubuntu@pi. And logging in to it without any issues. Hmm
<sborovkov> ogra_: Ok, so I guess I will just reflash, upgrade, run console-conf? And it should work, right?
<ogra_> sborovkov, well, i'm talking about snappy based images ...
<ogra_> classic images have not changed
<sborovkov> ah.
<ogra_> (though it is weird that yours have an ubuntu user ... smells wrong to me)
<sborovkov> ok. though you were talking about classic since I had this on classic.
<ogra_> (but perhaps it is like tha, i havent used a classic image on a pi)
<sborovkov> alright thanks
<sborovkov> oh well I have to reflash anyway. can't get to tty there
<ogra_> (you should really mention that you run classic in the beginning, i dont think anyone expects that in here)
<sborovkov> Sorry, I thought I did. Now looking at it I mention it midway in conversation in 1 place.
<ogra_> (even though we recommended that as an interim solution for a while ... we're all focused on snap based images :) )
<mup> Bug #1620635 changed: libapparmor's aa_query_label() always returns allowed = 0 for snaps <AppArmor:Confirmed> <Snappy:Won't Fix> <apparmor (Ubuntu):Confirmed> <https://launchpad.net/bugs/1620635>
<mup> Bug #1620755 opened: x509: certificate signed by unknown authority <certificate> <Snappy:New> <https://launchpad.net/bugs/1620755>
<SamYaple> I am a bit confused as to how to use the 'dump' plugin rather than the 'copy' plugin. is the idea that now an outside process with move the appropriate files into the */prime directory in appropriate place?
<SamYaple> is there an example I can reference?
<popey> SamYaple: i would continue using the copy plugin for now. the dump plugin has a couple of significant bugs, which should be fixed in snapcraft 2.17 I believe
<SamYaple> popey: threw that deprecation warning in there early then?
<popey> perhaps :)
<SamYaple> :) thanks
<mup> PR snapd#1854 closed: cmd/snap: generate account-key-request "since" header in UTC <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1854>
<mup> Bug #1620771 opened: /home symlink, snaps don't work <link> <snap> <symlink> <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1620771>
<mup> Bug #1620815 opened: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 <Snappy:New> <https://launchpad.net/bugs/1620815>
<kgunn> kyrofa: yo, was poking around for best way to deal with arch in building my snap helper files
<kgunn> found this
<kgunn> http://askubuntu.com/questions/757668/how-to-build-multi-arch-snaps
<kgunn> is dpm's method still the state of the art?
<kgunn> or is there something else
<mup> PR snapd#1853 closed: osutil: call sync after cp if requested. overlord/snapstate/backend: switch to use osutil instead of another buggy call to cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1853>
<mwhudson> good morning
<mwhudson> how on fire is everything today
<SamYaple> matchstick
<niemeyer> mwhudson: Nicely on fire ;)
<sam__> is there documentation to us webdm's "setting" tab to configure an application? (if anyone knows webdm)
<zyga> mwhudson: o/
<zyga> mwhudson: have a good day :)
<zyga> jdstrand: thanks for the review!
<zyga> github seems to be having some issues noiw
<mcphail> Can I poke someone (anyone) about https://bugs.launchpad.net/snappy/+bug/1574851 ? Graphical snaps are still not running with nvidia proprietary drivers. It would be great to get this fixed
<mup> Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
<zyga> jdstrand: ha,
<zyga> jdstrand: I was trying to reply to your comment on O_EXCL on the lock file and github kept failing
<zyga> jdstrand: now i know why :D
<zyga> jdstrand: you removed that comment, right?
<jdstrand> I did
<jdstrand> that was a not seeing the forest for the trees comment that tyhicks called me on :)
<zyga> jdstrand: I acked a few things, thanks a lot for the review! I will go over everything first thing tomorrow
<jdstrand> but there is a 3rd O_EXCL comment that still applies (not to use it, but why not to use it)
<jdstrand> zyga: yw :)
<zyga> yes, I saw, on the mnt file
<zyga> all in all, I think this is somewhat tricky code
<jdstrand> indeed
<zyga> I was worried about the child setting the parent process death signal a bit too late in pathalogical cases
<jdstrand> which is why an abundance of comments is good (which you've already done btw :)
<zyga> but there's no way, that I can see, to protect against that, since this prctl knob is reset across fork
<mwhudson> niemeyer: anything i can help with?
<zyga> :-)
<mup> PR snapd#1859 opened: daemon: bail from enable and disable if revision given, and from multi-op if unsupported optons given <Created by chipaca> <https://github.com/snapcore/snapd/pull/1859>
<mup> PR snapd#1859 closed: daemon: bail from enable and disable if revision given, and from multi-op if unsupported optons given <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1859>
<niemeyer> mwhudson: Actually, maybe :)
<niemeyer> mwhudson: But the problem is a bit blocked on design
<mwhudson> niemeyer: that seems to be a common theme!
<niemeyer> mwhudson: we need to create a mechanism to have local users on ubuntu-core that do not depend on network
<mwhudson> niemeyer: fwiw slangasek is trying to / going to try to set up a call between the three of us in the next couple of days
<mwhudson> niemeyer: ah right
<slangasek> oh, niemeyer is still around
<niemeyer> slangasek: Yeah.. I have wine next to me though, so I might not be entirely trustable
<slangasek> niemeyer: does that just mean "preserve the capability of cloud-init for local users"?
<niemeyer> slangasek: Hmm
<slangasek> I wouldn't expect to let someone set up a local account via console-conf, for instance
<niemeyer> slangasek: Right, that's the trickery
<niemeyer> slangasek: .. and why I don't have a great answer
<niemeyer> slangasek: We want to solve the problem without opening a hole
<mwhudson> niemeyer: this is the thing where the long term answer is providing an assertion from the store somehow?
<slangasek> ok; so would it be possible to have a call this week to flesh out the design, to unblock mwhudson?
<niemeyer> mwhudson: No, it's a more mundane problem.. someone that is cooking the actual device notices a problem and wants to debug it
<slangasek> right
<niemeyer> mwhudson: Talking to the network inside a factory is generally unreasonable..
<mwhudson> ah
#snappy 2016-09-07
<mup> PR snapd#1860 opened: misc fixes/tweaks/cleanups <Created by chipaca> <https://github.com/snapcore/snapd/pull/1860>
<nhaines> kyrofa: Nextcloud 9 feels like it came out 7 years ago!
<nhaines> kyrofa: in any case, your first ownCloud snap was a really cool proof-of-concept, the Nextcloud snap that got SSL support is amazing, and being able to say "Huh, wonder how this is looking now," run "snap install nextcloud" on my laptop, play with it, then delete the snap and not have 200 server packages installed and running is just amazing!
<nhaines> kyrofa: but I'm glad Nextcloud embraced it (despite constantly saying they're not packaging Nextcloud for distros) and I'm looking forward to migrating my cloud server to the snap.  :)
<nhaines> Also, I tried to snappify the client but failed because of some missing directory and don't have the knowledge to proceed, but for a while it looked promising, hehe.
<sabdfl> what's the best python standard library for dealing with --opts ?
<mup> PR snapd#1855 closed: overlord/boot: have firstboot support assertion files with multiple assertions <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1855>
<sergiusens> sabdfl argparse is in stdlib https://docs.python.org/3/library/argparse.html
<sergiusens> so no extras needed
<sabdfl> thanks sergiusens, i've so far just copied docopt into my snap, is that considered a bad option?
<sabdfl> i can easily fall back to argparse
<sergiusens> sabdfl docopts is great for simple CLIs, it has gotten out of control for snapcraft and its ever growing options
<sabdfl> i can believe that
<sabdfl> my cli is super simle so i will stick to it for a quick fix
<sergiusens> sabdfl for snapcraft itself I've been pondering on click http://click.pocoo.org/5/why/ ; played with it a bit and felt like a good match
<sergiusens> yeah, docopt solve the simple cli's just great
<sergiusens> it get's tricky when adding too many differing subcommands
<sabdfl> i bet
<kyrofa> nhaines, yeah, I've got the client snapped but I
<kyrofa> nhaines, I'm waiting to publish for indicators to work
<kyrofa> (indicators in snaps are broken right now)
<kyrofa> kgunn, indeed, that's the current state of the art as far as I know, but I've lost track of a bit of the most recent snapcraft features-- it may have gotten better there recently
<mup> PR snapd#1861 opened: tests: fixes to actually run the spread tests inside autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1861>
<mvo> ogra_: small bugreport around classic, it seems like running it twice gives a ugly message that dev/pts is already mounted
<mup> PR snapd#1862 opened: tests: add tests for the classic dimension <Created by mvo5> <https://github.com/snapcore/snapd/pull/1862>
<ogra_> mvo, hmm, weird, shouldnt systemd unmount it ?
<morphis> zyga: ping
<mvo> ogra_: it seems not
<morphis> mvo: can we already do sth like a factory-reset these days?
<mvo> morphis: well, sort of, but you need to be careful
<mvo> morphis: do you need a script to do that? how far do you want to go? reset everything ? including kernel/os and remove all data ?
<mvo> ogra_: I have not really investigated, more important stuff is still going on, its just cosmetic but I noticed while writing automatic tests for classic
<ogra_> morphis, can you bring that up in the filesystem layout thread i started on the ML, we will need a partiton that holds the original snaps for this i think
<morphis> ogra_: can do that
<ogra_> thanks
<morphis> mvo: thanks, was just wondering
<mvo> morphis: so essentially if you keep the stuff that firstboot puts on the image you can wipe everything else
<morphis> mvo: ok, I think tim already has something for this in place with his recovery work, but was more thinking about what we're offering for other devices
<mvo> morphis: this is probably something for the next sprint, we need a more generalized solution.
<morphis> ok
<mvo> ogra_: so I debugged why firstboot fails with ubuntu-image. it puts the grub.cfg into a different place than before. i.e. /boot/efi/EFI/ubuntu/grub.cfg (now) vs /boot/efi/EFI/ubuntu/grub/grub.cfg (before). there is a bind mount in the initramfs that assumes the grub/ location, do you know more aobut this change? I can update the initramfs code to use the other location I think, I'm just a bit puzzled
<ogra_> mvo, that was james code, not really sure why its there ... drop it and lets have some test images ?
<ogra_> (thats was also in system-ab times)
<mvo> ogra_: http://paste.ubuntu.com/23144982/
<mvo> ogra_: its stuff we still need. well, we could avoid the entire bind mount
<mvo> ogra_: but that would require changes in the snapd code too, maybe not unreasonable but a bit late
<mvo> ogra_: if the debdiff looks correct I will upload and hopefully this unblocks u-i
<mvo> u-i generated images
<ogra_> mvo, looks fine
<mup> PR snapd#1863 opened: image: have prepare-image set devmode correctly <Created by pedronis> <https://github.com/snapcore/snapd/pull/1863>
<mup> PR snapd#1863 closed: image: have prepare-image set devmode correctly <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1863>
<didrocks> pstolowski: hey! any leads on bug #1620560? (reminder that we need a fix to demo to consumer next week the revert functionality ;))
<mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1620560>
<Chipaca> sergiusens, when you're around, http://paste.ubuntu.com/23145076/
<Chipaca> didrocks, you're demo'ing a snap in devmode?
<Chipaca> sergiusens, the issue there more than anything else is the '401 None' and not-too-helpful error message
<Chipaca> sergiusens, dholbach knows more
<didrocks> Chipaca: has to, the interfaces fixes are in trunk, (and one not done)
<didrocks> Chipaca: if you have any other way around, I'll gladly take it :)
<pstolowski> didrocks, i've discussed the fix with Chipaca, looks simple, just did it and about to build and test
<didrocks> pstolowski: excellent! you think it's going to be in this week's release?
<ysionneau> in which context is executed the post-stop-command?
<ysionneau> do I have access to /usr/bin and /bin ? (for instance : ps/awk/grep/kill)
<liuxg> I compile my go project on my raspberry pi 3, and when I run it on the pi 3 device, I get "runtime: this CPU has no floating point hardware, so it cannot run this GOARM=6 binary. Recompile using GOARM=5." it is a golang project. how to correct this problem. it works well on pi 2 device. thanks
<pstolowski> didrocks, I should have MP ready today, what happens next is not in my hands, but I'll make sure everyone knows it's important
<didrocks> mvo: FYI ^
<didrocks> thanks pstolowski
<liuxg> how to configure go to compile my go project using GOARM=5. currently on my board, the version of snapcraft is 2.15.1
<mvo> didrocks: if its straightforward, happy to make sure its in, thank you
<nhaines> kyrofa: Hmm, indicators seemed to mostly work in the Telegram snap, but I haven't used that for a while because it was always out of date, too.  In any case, I'm glad you're working on that, too.  It will be good to get Nextcloud-branded stuff into Ubuntu 16.04 LTS.
<Chipaca> ysionneau, in the same context as everything else in the snap
<Chipaca> ysionneau, try "snap run --shell yoursnap" and then you can dig around yourself
<ogra_> mvo, whats with all these .moved files i always see in bzr branches after you touched them ? do you have some special bzr setup that keeps backups this way ?
<mvo> ogra_: eh, no idea, what files are those?
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$ ls -lh|grep moved
<ogra_> lrwxrwxrwx 1 ogra ogra    9 Sep  6 16:30 uboot.conf.moved -> uboot.env
<ogra_> -rw-rw-r-- 1 ogra ogra 128K Sep  6 16:30 uboot.env.moved
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$
<ogra_> before there also was a pi2.moved that i recently deleted
<ogra_> i only notice them showing up after you touched the branch ...
<ogra_> hmm, funnily this time the files dont show up in the LP UI ... the pi2.moved one did
<ysionneau> Chipaca: thanks, how can I find the snap name syntax? i've tried the name in the 1st column of "snap list" and it does not work, I guess I need to append/prepend something
<liuxg> ogra_, when I try to run "sudo classic.create" on pi 3, it gives me the error like "runtime: this CPU has no floating point hardware, so it cannot run this GOARM=6 binary. Recompile using GOARM=5."  how to correct this problem? thanks
<ogra_> liuxg, no idea ... thats definitely not related to classic ... classic is a shellscript
<ogra_> (and classic.create is long gone ... "sudo classic" is all you need)
<liuxg> ogra_, but I need to run classic.create first, then I run then sudo classic, right? I got this from one your email replies.
<ogra_> nope
<ogra_> just sudo classic
<ogra_> the creation is automatic nowadays
<liuxg> ogra_, but the "classic         classic.create  classic.reset" all 3 commands are there..
<ogra_> where did you get that classic snap from ?
<ogra_> you need --devmode --edge
<liuxg> ogra_, http://paste.ubuntu.com/23145383/, this is what happens here.
 * mwhudson blinks
<mwhudson> pretty sure the pi3 has a FPU :-)
<ogra_> liuxg, well, no idea what that is ,... there is no go in classic
<liuxg> ogra_, yes, that is exactly what I got here http://paste.ubuntu.com/23145387/
<ogra_> liuxg, --beta != --edge
<liuxg> ogra_,  sorry, I might get wrong. I will try the edge one.
<ogra_> hmm, trhough looking at the store beta and edge are the same
<mwhudson> liuxg, ogra_: fwiw, go is looking at the AT_HWCAP auxv entry wrt that message
<liuxg> ogra_, mwhudson, for pi 2, it works well for the "--beta" channel.
<ogra_> mwhudson, the tty prob is mainly that even if you have it print the issue file, it will not clear the screen and the line will appear somewhere in the middle of the boot messages that are still in the terminal
<mwhudson> ogra_: ah
<ogra_> we need to find out how to clear the screen i think
<ogra_> (which is hard ... but i know there are serial apps that can do it)
<mwhudson> ogra_: agetty claims to do it by default :/
<liuxg> ogra_, I tried to change to use "edge" channel, and it is the same thing for me http://paste.ubuntu.com/23145394/
<mwhudson> i guess putting 24 newlines in the issue file would not be considered elegant
<ogra_> liuxg, yes, as i said, checking the store revealed they are the same
<ogra_> mwhudson, and pointless if your terminal window is bigger (like mine)
<mwhudson> ogra_: 1 million newlines?
<mup> PR snapd#1864 opened: Apply flags (devmode) on revert <Created by stolowski> <https://github.com/snapcore/snapd/pull/1864>
 * mwhudson should just go to bed
<ogra_> that might work ... even on hidpi displays :P
<mwhudson> i guess it would be a bit of a waste of precious storage space in the embedded case
 * mwhudson zzz
<ogra_> adding a loop that counts from 1 to 1mio ? nah
<ogra_> and given how long it takes for python to come up it would also not siginificantly slow it down on arm :P
<mup> PR snapd#1860 closed: overlord/snapstate: misc fixes/tweaks/cleanups <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1860>
<ogra_> slangasek, so i fixed the sizes in the dragonboard gadget yaml ... using -w ./workdir to keep the content i see part0-part7.img files under .images/ in there ... all at the right size ... but looking at the resulting image there is only one partition, so i suspect however you invoke sgdisk doesnt do the right thing
<mup> PR snapd#1852 closed: asserts: update trusted account-key asserts with names <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1852>
<JamieBennett> ogra_, elopio, have you tried a usb eth adaptor with the Dragonboard, does that work for console-conf?
<ogra_> JamieBennett, nope, havent tried that yet ... i guess it depends if you have one that is supported by the mainline kernel without extra firmware
<ogra_> JamieBennett, there is a console-conf that supports wlan setup from mwhudson that i havent found the time to try yet ...
<JamieBennett> ogra_, OK, I don't think it is too much of an issue
<ogra_> JamieBennett, well, apart from the fact that you cant create a user, yeah
<ogra_> (no wifi support in console-conf ... no wired nic)
<JamieBennett> ogra_, I bet that is possible with USB eth but yes, if is an issue but not for our RTM image
<ogra_> if you have a supported USB eth key, yes ... else the image is completely unusable since you cant have a user to log in
 * JamieBennett nods
<ogra_> but all of this is moot ... we dont have a booting image at all yet
<ogra_> mvo, gave me one that was created with a hacked up u-d-f that doesnt boot ... and the one i'm trying to create with ubuntu-image ends up with only one partition
<JamieBennett> I saw Leo had something booting this morning, was that a different image?
<ogra_> no idea what leo had
<ogra_> all i got is unbootable stuff
<ogra_> hmpf ... and for some reason ubuntu-image doesnt pull the latest gadget
<ogra_> ah, now it does
<ogra_> slangasek, hmm, i dont see any sgdisk call in ubuntu-image that would set the alignment ... the dragonboard needs an alignem,nt of 1 byte ... (i.e. the -a 1 option) if i remember that right ... http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/partitioner.sh and http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt create a properly working GPT
<jgdx> where's the "plugs" docs? I'm looking at https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
<JamieBennett> jgdx, http://snapcraft.io/docs/core/interfaces
<ogra_> whee !
<ogra_> Number  Start (sector)    End (sector)  Size       Code  Name
<ogra_>    1            2048            4095   1024.0 KiB  FFFF  sbl1
<ogra_>    2            4096            6143   1024.0 KiB  FFFF  rpm
<ogra_>    3            6144            8191   1024.0 KiB  FFFF  tz
<ogra_>    4            8192           10239   1024.0 KiB  FFFF  hyp
<ogra_>    5           10240         7812466   3.7 GiB     FFFF  sec
<ogra_> getting better :)
<JamieBennett> nice
<ogra_> (far from ggood but i end up with more than one partition)
<jgdx> JamieBennett, sorry, more specifically, the plugs snapcraft.yml syntax docs
<JamieBennett> hey, its progress ;)
<jgdx> JamieBennett, and thanks!
<ogra_> yeah :)
<ogra_> but i still think the way u-image calls sgdisk is completely wrong
<JamieBennett> jgdx, you mean the available interfaces i.e. plug and slots available to snapcraft?
<JamieBennett> jgdx, that would be the interfaces that snapd exposes so in the snapd docs at `http://snapcraft.io/docs/reference/interfaces
<jgdx> JamieBennett, right. Thanks
<JamieBennett> jgdx, np
<jgdx> JamieBennett, to insert one into the snapcraft.yml I guess I'll use http://pastebin.ubuntu.com/23145601/ ?
<JamieBennett> jgdx, There are lots of examples in the playpen, let me pick one with plugs for you
<JamieBennett> jgdx, https://github.com/ubuntu/snappy-playpen/blob/master/hexchat/snapcraft.yaml
<jgdx> JamieBennett, cool, I'll look through those as well. Thank you
<mup> PR snapd#1864 closed: overlord/snapstate: apply flags (devmode) on revert <Created by stolowski> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1864>
<bull_> guys can we set source field in snapcraft file a launchpad branch ??
<bulldog> can we set bzr branch as source in snapcraft ??
<ogra_> SUCCESS !!! (nearly ... one little glitch left)
 * ogra_ is looking at console-conf on an ubuntu-image built dragonboard image
<ogra_> sadly no wlan config ... so i cant really test it ...
 * ogra_ tries to find an USB NIC
<abeato_> ogra_, I am seeing this error when executing apps in RPi3, I think caused by upgrading ubuntu-core today:
<abeato_> runtime: this CPU has no floating point hardware, so it cannot run
<abeato_> this GOARM=6 binary. Recompile using GOARM=5.
<abeato_> ogra_, any idea why is this? afaik rpi3 has vfp unit
<ogra_> abeato_, hmm, liuxg reported the same above ... weird
<ogra_> abeato_, sounds like an issue with snapd ?
<ogra_> mvo, ^^^^ any idea ?
<abeato_> ogra_, probably, snapd is running though
<ogra_> did you guys switch tio a newer go or some such ?
<mvo> ogra_: uh
<ogra_> abeato_, where diod you get that image ?
<abeato_> ogra_, your image, refreshed
<ogra_> (we dont really have any working pi3 image atm ... its all in flux this week)
<ogra_> ooooh, i'm so happy !
<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:~$ snap list
<ogra_> Name                Version       Rev  Developer  Notes
<ogra_> dragonboard         16.04-0.15    18   canonical  -
<ogra_> dragonboard-kernel  4.4.0-1024-2  8    canonical  -
<ogra_> ubuntu-core         16.04.1       511  canonical  -
<ogra_> ogra@localhost:~$
<ogra_> JamieBennett, ^^^ getting there ;)
<JamieBennett> :)
<ogra_> (but needed an USB NIC indeed)
<bulldog> ogra_, i need help
<bulldog> plz check this snpcraft http://paste.ubuntu.com/23145789/
<liuxg> ogra_, abeato_ yes, exactly, I do not know how to resolve the problem.
<mvo> JamieBennett: who is building snapweb snaps currently? I get "runtime: this CPU has no floating point hardware, so it cannot run
<mvo> this GOARM=6 binary. Recompile using GOARM=5."
<mvo> JamieBennett: when I try to run it
<jgdx> when ubuntu is upstream, what's the best way to manage the code so that it can be built as both deb and snap?
<JamieBennett> mvo, did Steve used to get you to do them?
<mvo> JamieBennett: he did but I think I did not do the latest, I figure it out, no worries
<JamieBennett> mvo, we have justinmcp_ working on it now but I do not believe he has built the project or made any changes yet
<tedg> So I have a snap that is in the store and says it is published on the edge channel, but it seems my local snapd can't install it.
<tedg> I tried refreshing the login.
<abeato_> ogra_, mvo, liuxg found a way to workaround the issue:
<tedg> Not sure where to go next.
<abeato_> sudo snap revert ubuntu-core
<abeato_> sudo snap remove <snap>
<abeato_> sudo snap install <snap>
<abeato_> the interesting thing is that I found that when I was seeing the error I saw links in /snap/bin like
<abeato_> lrwxrwxrwx 1 root root 13 Sep  7 13:04 command -> /usr/bin/snap
<abeato_> and now I get the usual script defining all $SNAP env
<abeato_> it looks like something goes wrong when installing with latest snap command?
<sergiusens> Chipaca dholbach we have plenty of bugs for this, the store only recently started to support finer grained messages which we need to support
<dholbach> ok, I see
<mvo> cjwatson: we get errors for some snaps like "runtime: this CPU has no floating point hardware, so it cannot run
<mvo> this GOARM=6 binary. Recompile using GOARM=5." has anything changed in LP recently when auto-building snaps?
<cjwatson> mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039458.html would be the most obvious recent change
<abeato_> mvo, cjwatson I do not think it is auto-building, it happens with my locally built snap
<mvo> abeato_: oh, hm
<abeato_> in my case the issue was triggered -I think- when ubuntu-core snap refreshed
<abeato_> it is an error on installation
<abeato_> weird links appear in /snap/bin instead of the usual scripts
<cjwatson> mvo: maybe it's failing to read hwcap properly?
<mvo> abeato_: the links are ok, that is a planned change
<abeato_> hm.. but those just point to /usr/bin/snap
<mvo> abeato_: yeah, `snap run hello-world` is the equivalent to /snap/bin/hello-world -> /usr/bin/snapd
<abeato_> got it
<mvo> cjwatson: hm, could be
<mvo> abeato_: but it could still be releated to that change
<mup> PR snapd#1865 opened: overlord/devicestate: POC to parametrise serial-request content/sending <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1865>
<mvo> cjwatson: yeah, it looks like the hwcap set lacks HWCAP_VFP when it is running inside the confinement
<cjwatson> missing apparmor access to /proc/self/auxv or something maybe?
<cjwatson> (not sure if that makes sense)
<mvo> cjwatson: it sounds very plausible, let me try
<ogra_> JamieBennett, http://people.canonical.com/~ogra/snappy/all-snaps/all-snaps-dragonboard.img.xz in case you want to test
<JamieBennett> ogra_, my dragonboard is with iftika now
<mvo> jdstrand: help, we have a bit of a showstopper on the pi2 image: snap run snapweb
<mvo> runtime: this CPU has no floating point hardware, so it cannot run
<mvo> this GOARM=6 binary. Recompile using GOARM=5.
<mvo> jdstrand: however - apparmor_parser -R /etc/apparmor.d/usr.lib.snapd.snap-confine
<mvo> jdstrand: and its all working
<ogra_> JamieBennett, excuses :P
<mvo> jdstrand: I see no denials in the logs
<mvo> jdstrand: I tried the suggestion from cjwatson to make /proc/self/auxv readable that seems to not have cut it :/
<mvo> JamieBennett: -^ pi2 showstopper
<shuduo> hello, i am working on pack a qml to be snap. I need add liboxideqtcore0 in stage-packages to support webview in qml. but my snap will exit since /snap/.../oxide-qt/chrome-sandbox is not owned by root but normal user same as my host. how i can install it with root?
<ogra_> slangasek, so i have everything working with the dragonboard using ubuntu-image, but the partitioning is pretty wasteful, for the next release we should go over how sgdisk is used in ubuntu-image and see if we can not make that more elegant
<roadmr> hey folks, has anybody tried the rocketchat-server snap? I installed it and get a 404 when going to http://localhost:3000, sure I'm doing something wrong but there aren't many knobs to tweak
<jdstrand> mvo: this sounds familiar... tyhicks, does that ring a bell? ^
<jdstrand> mvo: did you disable rate limiting?
<jdstrand> mvo: sudo sysctl -w kernel.printk_ratelimit=0
<jdstrand> mvo: can you show me the rule you added?
<mvo> jdstrand: I added     /proc/self/auxv r,
<jdstrand> mvo: this is the rule you want: @{PROC}/@{pid}/auxv r,
<jdstrand> mvo: /proc/self is a symlink
<jdstrand> tyhicks: if it doesn't ring a bell, that is fine
<jdstrand> I think we saw this with java...
<mvo> jdstrand: http://paste.ubuntu.com/23146014/ - not quite it seems
<jdstrand> mvo: is this for wnapweb or snap-confine?
<mvo> jdstrand: all golang apps it seems
<sergiusens> nap-web, I like that
<ogra_> +1 !
<jdstrand> snap-confine is not golang
<jdstrand> mvo: let's backup
<mvo> jdstrand: actually I'm not really sure what is going on
<mvo> jdstrand: yeah
<mvo> jdstrand: so - since very recently we have this issue that when I run a golang app on the pi2 I get the above error
<jdstrand> mvo: can you do 'sudo sysctl -w kernel.printk_ratelimit=0'
<ogra_> sergiusens, nap-web but only after snap-confect !
<mvo> jdstrand: I did that when you put it in
<jdstrand> mvo: then, can you tell me if hello-world works
<jdstrand> ok
<mvo> jdstrand: eh, when you wrote it some minutes ago
<shuduo> kyrofa, ping
<mvo> jdstrand: http://paste.ubuntu.com/23146021/
<mvo> jdstrand: the sequence is now: "snap run" (unconfined) -> "snap-confine" -> snap-exec (golang!)
<jdstrand> mvo: ok. so, snap run is not confined
<tyhicks> jdstrand: hmm... that doesn't ring any bells for me
<jdstrand> mvo: isn't snap run also golang?
<mvo> jdstrand: so it might be that this is a bug we had for a longer time but now because we use snap-exec (golang) to actually launch its manifesting itself more
<mvo> jdstrand: it is, snap run is golang but unconfined
<mvo> jdstrand: and the snap-exec step is then confined
<jdstrand> mvo: can you paste syslog?
<mvo> jdstrand: http://paste.ubuntu.com/23146025/ is strace
<jdstrand> ok, so it is snap-exec
<kyrofa> shuduo, pong
<jdstrand> oh I think I remember what this is
<jdstrand> I think there is an env var that is getting stripped out
<shuduo> hello kyrofa, i am working on pack a qml to be snap. I need add liboxideqtcore0 in stage-packages to support webview in qml. but my snap will exit since /snap/.../oxide-qt/chrome-sandbox is not owned by root but normal user same as my host. how i can install it with root?
<jdstrand> mvo: can you paste me the updated snap-confine profile?
<mvo> jdstrand: http://paste.ubuntu.com/23146034/
<kyrofa> shuduo, jdstrand might have some suggestions for working with that sandbox. I suspect it will be to disable it
<zyga> hey
<zyga> anything I can help with?
<kyrofa> shuduo, and use snappy's instead
<zyga> jdstrand, mvo: anything at all?
<jdstrand> kyrofa, shuduo: morphis just brought this up in another channel
<jdstrand> shuduo: are you part of an email thread on that?
<tyhicks> jdstrand: I don't know exactly when the env var would be getting stripped out but I should you remind you that the non-secureexec change_profile syntax was backported to xenial - let me know if/when you want details on that
<shuduo> jdstrand: hi, i don't think i'm in th thread since I just search my email and lp to look for if someone meet this issue
<shuduo> jdstrand: does that mean no solution right now?
<jdstrand> shuduo: the short answer is that you need to disable using the setuid sandbox
<tyhicks> (the non-secureexec change_profile syntax is bug 1584069)
<mup> Bug #1584069: change_profile rules need a modifier to allow non-secureexec transitions <aa-parser> <aa-tools> <verification-done> <AppArmor:Fix Committed by tyhicks> <apparmor (Ubuntu):Fix Released by tyhicks> <apparmor (Ubuntu Xenial):Fix Committed by tyhicks> <https://launchpad.net/bugs/1584069>
<jdstrand> shuduo: I'm not sure how to do that in oxide. chrisccoulson, is there an env var to set?
<shuduo> jdstrand: hmm, how? sorry i don't have many knowledge here.
<jdstrand> shuduo: chrisccoulson should be able to say
<chrisccoulson> jdstrand, OXIDE_NO_SANDBOX=1, but this shouldn't be used by production code (and environment variables aren't considered to be part of the stable API either - they're only really there for testing purposes)
<jdstrand> mvo: can you get the apparmor for xenial-proposed, then do: 's/change_profile/change_profile unsafe/' in snap-confine's profile?
<jdstrand> mvo: that is to test my hypothesis about it being a stripped variable
<jdstrand> mvo: I'm not sure that is the fix though
<mvo> jdstrand: so a new apparmor? from xenial-proposed? sure
<jdstrand> mvo: 2.10.95-0ubuntu2.2 in xenial-proposed
<shuduo> chrisccoulson: so will "command: OXIDE_NO_SANDBOX=1 desktop-launch $SNAP/usr/lib/*/qt5/bin/qmlscene $SNAP/Main.qml" work?
<zyga> jdstrand, mvo: please ensure that the patch ends up in snap-confine master too
<jdstrand> chrisccoulson: so, the problem is that we can't safely support the setuid sandbox due to the issues you already know about
<jdstrand> chrisccoulson: ie, all the capabilities, etc
<chrisccoulson> shuduo, yes, although it means you get no renderer sandbox
<jdstrand> chrisccoulson, shuduo: but the application is already sandboxed
<jdstrand> via snappy
<jdstrand> electron apps for example don't use the renderer sandbox
<mvo> jdstrand: this is actually a bit tricky, this is on an all-snap image on the pi2, so installing a snap is tricky, but I can unpack the deb and scp it
<jdstrand> I don't think oxide apps should either while we are in the state we are in wrt snappy policy and oxide sandboxing
<shuduo> chrisccoulson: sorry what means "get no rendere sandbox"? i need webview to draw a webpage with webgl objects...
<jdstrand> shuduo: it will work. he is saying this disables an internal sandboxing technique
<shuduo> jdstrand: great. my snap is for demo purpose only. :)
<jdstrand> shuduo: I'm not sure where in the 'command' line you should put the env var, but so long as it is set, oxide should work in strict mode
<jdstrand> mvo: I suspect you will need libapparmor and apparmor
<tyhicks> mvo, jdstrand: you don't need apparmor from -proposed
<jdstrand> actually, yes, I was just going to say that
<jdstrand> this was in 2.2 which is in updates now
<tyhicks> mvo, jdstrand: 2.10.95-0ubuntu2.2  from -updates is good enough
<tyhicks> ok
 * jdstrand was confused by the bug being Fix Committed still
<kgunn> dpm: hey is this still the only/preferred way to pick arch in snaps
<kgunn> http://pastebin.ubuntu.com/23146088/
<jdstrand> mvo: right, so, skip getting a new apparmor and just add 'unsafe' as I described
 * jdstrand is also wondering why there isn't a 'snap-exec' rule in the snap-confine policy. is it just forked and not execd?
<mvo> jdstrand: its execed
<tyhicks> (not sure why the bug status didn't update automatically - I've fixed it)
<jdstrand> I have to look at how snap-exec is doing its thing again, clearly
<mvo> jdstrand: AppArmor parser error for /tmp/usr.lib.snapd.snap-confine in /tmp/usr.lib.snapd.snap-confine at line 60: Exec condition is required when unsafe or safe keywords are present
<mvo> jdstrand: am I doing something wrong?
<dpm> kgunn, it's still the only way afaik, yes
<kgunn> cool
<tyhicks> mvo, jdstrand: you want 's/change_profile/change_profile unsafe \/**/'
<zyga> mvo: can I help in any way?
<jdstrand> mvo: perhaps not. I think use 'change_profile unsafe /** -> ...'
<jdstrand> tyhicks: is /** needed with the change_profile rule?
<mvo> jdstrand: \o/ works
<mvo> zyga: maybe, not yet
<mvo> zyga: looks like jdstrand found the right magic
<mvo> jdstrand: I guess this is not a permanent solution :) please help me understand what magic you are doing
<zyga> mvo: I understand we landed the run/exec branch now
<zyga> and this is the fallout?
<jdstrand> tyhicks: yes, we got there. the question I had was if '/**' was needed (and curious why)
<mvo> jdstrand, tyhicks: http://paste.ubuntu.com/23146105/ works
<tyhicks> jdstrand: it is needed but I'll have to dig through the mailing list archive to remember exactly why
<jdstrand> mvo: right, so this rule works because we are ensuring the secure exec bit is not set which makes sure the env var I was talking about that go runtime needs isn't cleared
<jdstrand> tyhicks: it isn't important
<zyga> FYI, I'm tracking this as 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:In Progress> <https://launchpad.net/bugs/1621127>
<shuduo> jdstrand, chrisccoulson i add OXIDE_NO_SANDBOX=1 before desktop-launch but snapcraft will report error "The specified command 'OXIDE_NO_SANDBOX=1' defined in the app 'Remote3DP' does not exist or is not executable                                                            1
<mvo> jdstrand: aha, I remember this one too now, we had this issue before
<jdstrand> shuduo: right, maybe add it after desktop-launch? I'm not really sure on that part. perhaps kyrofa or another snapcrafter can advise how to set arbitrary env vars
<jdstrand> mvo: iirc, it came up wrt webdm, but memory is hazy
<tyhicks> mvo: yes, I implemented this at your request :)
<kyrofa> shuduo, yeah we're working on adding environment keys to the YAML, but until then really your only option is to create a wrapper to use for your app
<mvo> tyhicks: ha!
<kyrofa> (that sets the variable)
<tyhicks> mvo: you ended up not needing it but I was stubborn and saw it through upstreaming and SRU'ing
<tyhicks> mvo: good thing I'm stubborn :)
<jdstrand> indeed
<mvo> jdstrand, tyhicks: so that is the answer? we change the profile in the way described in the pastebin?
<shuduo> kyrofa: understood. i will do it. thanks.
<mvo> tyhicks: yeah, you are a HERO
<mvo> tyhicks: (no kidding!)
<jdstrand> mvo: possibly. I want to investigate
<mvo> tyhicks: this was a serious last-minute showstopper
<jdstrand> tyhicks: I will likely need to run something by you after I investigate
<tyhicks> jdstrand: ack
<jdstrand> mvo: apply it now if it is blocking the world
<mvo> jdstrand: thanks
<mvo> and thanks to tyhicks
<cjwatson> sergiusens: re https://github.com/snapcore/snapcraft/pull/726, cprov and I were thinking that perhaps the integration test for register-key should just skip if a sufficient version of snapd isn't available (e.g. for distributions without snapd).  Do you think that's reasonable and safe, or would you rather that it failed?
<mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
<tyhicks> np!
<mvo> jdstrand: in a meeting right now, but will do after the meeting
<jdstrand> mvo: but can you point me at how how snap run/confine/exec is working?
<jdstrand> mvo: source code is fine
<mvo> jdstrand: you can play with the latest image, code is cmd/snap/cmd_run.go
<jdstrand> (and even preferred :)
<sergiusens> cjwatson I will defer that to elopio
<mvo> jdstrand: but its essentially just snap run reads all the yaml, calls snap-confine with the right security-tag which runs snap-exec
<jdstrand> mvo: it's that last bit that is throwing me
<sergiusens> cjwatson is it just to avoid bit rot on your branch?
<elopio> cjwatson: seems ok. We can make sure that snapd is in jenkins, so it will run for us.
<mvo> jdstrand: and cmd/snap-exec/main.go
<mvo> jdstrand: what last bit? snap-exec?
<jdstrand> because I don't see an 'x' rule for snap-exec
<jdstrand> I want to understand that
<mvo> jdstrand: oh, ok. is http://paste.ubuntu.com/23146025/ helpful? shows the full flow
<jdstrand> mvo: will this get me the 'latest image' you are referring to? sudo /snap/bin/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160831-amd64.img --gadget pc --kernel pc-kernel --os ubuntu-core 16
 * jdstrand would use a different date of course
<sergiusens> cjwatson merging this would make us unreleasable though as snapd might be stuck there forever so maybe a runtime check instead of a packaging dependency would help a lot
<jdstrand> mvo: that paste will be handy, yes
<zyga> mvo: one question: the pastebin flow above shows that we run ubuntu-core-launcher first, didn't we want to run snap-confine directly and remove u-c-l executable?
<jdstrand> mvo: as for after your meeting, please add a comment on why we are using 'unsafe' and please ping me for the review
<mvo> jdstrand: uploading you the latest image to https://people.canonical.com/~mvo/all-snaps/16, will take ~5min or so
<mvo> jdstrand: u-d-f is currently a bit outdated
<mvo> zyga: yes, we just need to do that
<jdstrand> mvo: I'll want all-snaps-pc.img.xz?
<zyga> mvo: noted, I was just unsure if anything changed mid-way
<mvo> zyga: if you want to help, you can prepare a new snap-confine for the ppa with http://paste.ubuntu.com/23146105/ and a comment why its needed
<zyga> mvo: already on it
<mvo> jdstrand: yes, its still uploading, ~4min eta
<mvo> zyga: \o/
<jdstrand> zyga: please ping me for the PR
<zyga> jdstrand: sure
<cjwatson> sergiusens: well, if the integration test skipped dynamically if it didn't have a new enough snapd, then it wouldn't block you, it's just that register-key wouldn't be guaranteed to work
<ackk> hi, when trying to install a snap I created with snapcraft I get the following error: "cannot find signatures with metadata for snap", am I missing something?
<mup> Bug #1621132 opened: Porting guide is out of date <Snappy:New> <https://launchpad.net/bugs/1621132>
<mvo> jdstrand: its there now
<sergiusens> cjwatson snapd is being unblocked now; my worries is for when I was going to dput and then get stuck on -proposed :-)
<mvo> slangasek: is there a way to trigger an autopkgtest to run asap? I had a failure on yakkety because of a git clone gateway timeout :/ and would love to retrigger asap to see results
<slangasek> mvo: the update_execuses.html page has a 'retry' button for failed tests if that's what you need
<slangasek> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd the 'recycle' icon :)
<slangasek> ogra_: what's currently "not great" with console-conf on serial? are there open bug reports about this?
<jdstrand> mvo: thanks
<mvo> slangasek: \o/
<slangasek> mvo, ogra_: wrt signed model assertions, where are we going to get these for the reference images we're building on cdimage infra?
<ogra_> slangasek, mvo should be able to give them to you
<mvo> slangasek: they will be available from the assertion "store", but I can forward you the ones we have
<mvo> slangasek: once we have news, the pc one is currently re-done
<zyga> mvo: how do you want the snap-confine change? debdiff? dput to the repo?
<zyga> jdstrand: ^^ along how do you want the review
<slangasek> "assertion store"> I guess that's not something I have a good interface for querying right now as part of image builds
<zyga> jdstrand: I think debdiff is easiest here unless there's a repo that I don't know about
<mvo> zyga: debdiff for final review from jdstrand and then dput I think
<mvo> zyga: but debdiff is fine, I can do the rest
<mvo> zyga: thank you, that helped me a lot
<ogra_> slangasek, i thought i had filed one ... but seems i'm wrong
<zyga> http://paste.ubuntu.com/23146292/
<shuduo> chrisccoulson: after i export OXIDE_NO_SANDBOX=1 in wrapper script and repack my snap. now it reports "[0907/231547:ERROR:browser_main_loop.cc(231)] Running without the SUID sandbox! See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the sandbox on.
<slangasek> ogra_: ok, please file so we know what we're asked to fix :)
<zyga> that's the debdiff
<zyga> mvo, jdstrand: ^^
<chrisccoulson> shuduo, yes, that's expected
<shuduo> chrisccoulson: and no app window show up...
<chrisccoulson> that's a separate issue
<chrisccoulson> Oxide won't be responsible for an app window not showing up
<slangasek> mvo: OOI, why is extra-snaps an option to prep-image rather than part of the model assertion?
<ogra_> slangasek, it would help ifr LP knew about the subiquity package :)
<ogra_> "subiquity" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
<mvo> slangasek: its fine to add extra snaps that are not strictly needed by the model assertion, i.e. we install snapweb on our images but its fine to build a image without it
<ogra_> (i clicked the "report a bug" link on https://bugs.launchpad.net/ubuntu/+source/subiquity
<ogra_> )
<slangasek> ogra_: <blink> I know subiquity is no longer in the NEW queue, I assumed somebody had accepted it rather than rejecting it...
<mvo> jdstrand: does http://paste.ubuntu.com/23146292/ look ok? I guess the first @{PROC}/@{pid}/auxv r, is not really needed (?)
<slangasek> cyphermox: do you know why subiquity 0.0.9 was rejected?  can't find the reject comment in the history in LP
<slangasek> cyphermox: and if there was a valid reason for rejecting, can you upload a new version so we can put this "no package in Ubuntu" thing to bed
<zyga> jdstrand, mvo: please ping me if you need me to dput this into the PPA
<ogra_> slangasek, it works if i file it against snappy and open a task for subiquity ... bug 1621142
<mup> Bug #1621142: no "please press enter" message shown on serial console <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621142>
<Fl1nt> Hi folks!
<jdstrand> mvo: I don't know if the auxv is needed any more. I don't think so cause snap-confine shouldn't need it itself, but not sure of how snap-exec is working yet
<eul0gy^> hi
<cjwatson> ogra_: don't assume that that hack will keep on working
<mup> Bug #1621142 opened: no "please press enter" message shown on serial console <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621142>
<ogra_> cjwatson, i assume that subiquity will be known by LP before it stops working :)
<cjwatson> ogra_: we'll probably be closing the weird partial loophole where you can sometimes open tasks against packages that only exist in PPAs as part of a project to close a security hole
<ogra_> cjwatson, today ?
<cjwatson> no
<ogra_> good :)
<cjwatson> when I finish the complicated code :P
<jdstrand> zyga (cc mvo): there is no comment in there. Please use: # NOTE: use 'unsafe /**' to disable secure exec environment scrubbing
<jdstrand> zyga (cc mvo): # This is currently required by snap-exec
<slangasek> ogra_: yes, that indeed works :/
<cjwatson> ogra_: just taking the opportunity to warn people occasionally since I suspect it may cause some consternation when we start disallowing this
<mvo> jdstrand, zyga: will do and (re)upload
<mup> Bug #1621144 opened: serial console is not cleared before console-conf runs <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621144>
<cyphermox> slangasek: it had various issues; I'll reupload
<slangasek> cyphermox: thanks
<ogra_> cjwatson, well, as long as it works right now i'm fine ... i normally dont use that :)
<mvo> jdstrand, zyga: added and uploaded
<bulldog> hey , i have a question
<bulldog> can an application packed in snap make call to /usr/bin ??
<jdstrand> mvo: did you remove the auxv access?
<Fl1nt> I don't think so as snaps are self contained apps isolated, but I'm far from being an expert bulldog
<bulldog> like if my program want to call other program installed on user system,
<bulldog> Fl1nt, it should but it is not calling
<ogra_> slangasek, three new bugs for you :)
<bulldog> if snap apps wont able to do that, that will break lots of apps and wont allow programs to call other programs and utils which some apps may use
<zyga> jdstrand: ack, do you want me to remove the auxv line while I'm at it, I noticed that mvo asked about
<zyga> ah, I see that mvo already picked it up
<mup> Bug #1621147 opened: no way to configure wifi SSID and passphrase <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621147>
<bulldog> guys fox example my app want call gsetting to change wallpaper or theme of users system how can a snap app can call gsetting ???
<kyrofa> bulldog, no blanket access to /usr/bin, but there are some utilities available there
<mvo> zyga: yeah, but if you could ensure this all goes into upstream git, that would rock
<Fl1nt> bulldog: oh, I see you call an unsnapped app ?
<bulldog> kyrofa, what you mean by   but there are some utilities available there?
<bulldog> Fl1nt, yes lots of apps do this
<kyrofa> bulldog, there's an explicit whitelist of things you can call, e.g. awk and so on
<kyrofa> bulldog, gsettings is unknown territory for me though, so I'll let someone else answer that
<bulldog> how you use grep, ls , bash, or anything which a developer can  use in their app to extend functionality
<kyrofa> didrocks maybe
<zyga> mvo: I will, I'm tracking this
<kyrofa> bulldog, yeah, those are also whitelisted
<mvo> zyga: thanks again!
<zyga> kyrofa, bulldog: apparmor will soon be able to control gsettings but the precise value of soon is unknown to me
<bulldog> kyrofa, this should not be just few list of apps
<Fl1nt> bulldog: well, in this case I'm sorry, I'm trying to be 100% committed on snaps and so using the plugs :D
<didrocks> bulldog: there are some example of wallpaper changing using gsettings even!
<slangasek> ogra_: thank you!
<ogra_> and two for ubuntu-image
<shuduo> chrisccoulson, jdstrand, kyrofa add env var in wrapper, install with devmode, it works now. its snapcraft.yaml is refer to 2048 of playgen. i guess still need other plug to run in strict mode.
<bulldog> didrocks, all wallaper changing apps do this by calling gsetting
<bulldog> didrocks, all wallaper changing apps do this by calling gsettings
<didrocks> here is an example for an icon theme changing https://github.com/ubuntu/snappy-playpen/tree/master/ubuntukylin-icon-theme
<didrocks> using the desktop-launcher, it's quite easy to get it working
<bulldog> Qprocess in qt look into /usr/bin to exec apps under linux
<bulldog> didrocks, that's different thing ,
<didrocks> bulldog: it's not, you ship some files, then call gsettings
<bulldog> didrocks, do you want programmers to program their app snap way ??
<mup> Bug #1619729 changed: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:Invalid by mvo> <Ubuntu Image:Invalid> <https://launchpad.net/bugs/1619729>
<didrocks> see the "set" command
<bulldog> thousands of developers will not do that by taking snap in mind
<didrocks> bulldog: gsettings wasn't prommed "snappy way"
<didrocks> programmed*
<didrocks> AFAIK
<zyga> bulldog: you should be able to use gsettings in dev mode, all writes go over dbus AFAIK
<zyga> bulldog: reading is done by mmaping the file, this might be a different story
<didrocks> even in non devmode, it's working in the above example ^
<bulldog> didrocks, i have app deskie which uses qt standards , and work fine on normal .deb install
<zyga> bulldog: the long story short is that gsettings support is in progress but it's not available yet
<didrocks> for both reading and writing
<bulldog> while , with snap it look for gsettings which i stagged to be available in $SNAP but it wont do anything
<didrocks> bulldog: I give you an example above with the correct wrapper and plugs to have it working even in non devmode
<didrocks> please give it a try
<bulldog> zyga, my concerns are not only about gsettings man'\
<ogra_> slangasek, to create an i386 pc gadget, can i just copy the content from generic-amd64 ? or will that explode ?
<bulldog> my question is why /usr/bin access is blocked ??
<ogra_> i suspect we need a different binary and no shim ?
<zyga> bulldog: because the content of that is unpredictable and it may not be universally available
<bulldog> if user want program do things why a packing format want him to stop him ?
<slangasek> ogra_: not different binary, pc grub is pc grub.  Copy, strike the UEFI, and done.  Do we care about non-GPT-friendly i386 BIOSes? probably not
<zyga> bulldog: so the snap you create will not work everywhere which is the idea with snaps
<zyga> bulldog: don't depend on stuff in /usr/bin, ship it
<bulldog> zyga, oh
<mvo> slangasek: fgimenez verfied #1618095 now, so if we could get an unblock even though autopkgtest is unahppy, that would be much appreciated
<mup> Bug #1618095: [SRU] 2.14.2 <verification-done> <Snappy:New> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1618095>
<bulldog> didrocks, plz explain your way to access gsettings
<ogra_> slangasek, i heard about uboot i386 requirements in the past ... not sure thats still a thing ... and surely not for now :)
<bulldog> zyga, gsettings should be directly connected to system bus, right now if you will pack unity tweak tool in snap format it will not work :D
<zyga> bulldog: gsettings is an application linked to glib, it uses a certain "protocol" or "interface" to read and to write key/values; as long as the protocol is stable you can bundle the required library and do the exact same thing (or even implement it in a compatible way separately)
<ackk> hi, what can be causing snap install to fail with "cannot find signatures with metadata for snap"?
<zyga> bulldog: gsettings, AFAIK (I could be wrong) uses mmap to read and dbus to write values
<bulldog> zyga, it will write and read data but wont change anything in real world
<slangasek> ogra_: uboot i386 would be separate from the i386 pc gadget
<ogra_> yeah, definitely
<zyga> bulldog: dbus traffic to the session bus is controlled by apparmor, the file that gsettings tries to read is derived from $HOME which is remapped by snappy
<zyga> bulldog: I don't know more details but this might explain why things don't work the way you expect
<zyga> bulldog: the short term story is that gsettigns cannot be "allowed" because of how the API looks like (the decision if something is safe or not is not at an API level but at an argument level); we are working with gsettings upstream to add mediation points so that apparmor can be used to say "this application can read this gsettings value/tree" or "that application can change the background by writing to
<bulldog> zyga, when app is not packed with snap , it simply calls /usr/bin/gsettings with args to do things , same happen with snap pack but it changes settings within the container , and do not affect ubuntu desktop
<zyga> this gsettings path"
<zyga> bulldog: snaps run under confinement, this means that certain things are not allowed without an appropriate interface
<ogra_> slangasek, hmm, if i kill the EFI,i still want to keep a system-boot vfat to carry grub.cfg, should that be named not EFI then ?
<bulldog> zyga, is there any interface yet to allow call gsettings ?
<zyga> bulldog: when the gsettings improvement is in place applications will be able to use it as they did before, assuming the desired interactions are safe, for other interactions appropriate interfaces will have to be created
<zyga> bulldog: no, because it requires upstream work in gsettings itself and that has not been finished yet
<zyga> bulldog: people are working on this
<bulldog> okay
<bulldog> ty
<slangasek> mvo: snapd> promoting, thanks!
<bulldog> zyga, wait i have one more question
<zyga> bulldog: interface creation is easy but right now there's no language to control which part of gsettings tree can be accessed
 * jdstrand notes there is a gsettings interface. it allows access to the global database. iirc one of the desktop parts makes that work right
 * zyga has deep desire to have a snap that can change backgrounds :)
<zyga> jdstrand: oh, I didn't remember this; thanks
<jdstrand> this interface is one of the transitional ones
<jdstrand> but you are right, proper app-isolated gsettings mediation is coming
<slangasek> mvo: wrt the snapd autopkgtest failures, I've only overridden with a 'force-skiptest' hint; that means other packages which snapd depends on (snap-confine), and which trigger failing autopkgtest runs, will also need to be manually resolved for now
<bulldog> zyga, i developed gui for snapcraft , which normally call /usr/bin/snapcraft , usr/bin/snap to do tasks , will it work after packaging in snap format ???
<jdstrand> and when it is available we will encourage people to use it instead of the global one
<bulldog> zyga, check out deskie wallpaper changer app :)
<zyga> bulldog: no, for the reason I outlined above, please talk to sergiusens about a possible content interface or a "snapcraft part" or another idea that would let you do this reliably and predictably
<bulldog> zyga, www.ktechpit.com/deskie-wallpaper-changer-ubuntu-linux/â
<zyga> bulldog: thanks, I will - I have some photos I took I want to release as a content snap
<bulldog> zyga, deskie get thousands of images online and let you set them as wallpaper on your request
<bulldog> https://github.com/keshavbhatt/Deskie
<zyga> I need to get back to snap-confine
<zyga> bulldog: if you have any questions feel free to ask here or on the mailing list
<roasted> possibly a dumb question, but I'm curious -- say you have a .deb built for 14.04. When attempting to install on 16.04, it cites 5 missing deps (not in repos). The .deb in question is not open source. In theory, if one really wanted, could you (somehow) take that .deb, add the missing deps, and somehow snap it? Or is that crazy talk?
<bulldog> it is powerful then variety and uses less ram :D
<zyga> roasted: yes, though some things may require extra work because of the snap filesystem layout
<bulldog> roasted, yes
<cjwatson> sergiusens: OK, yeah, with snapd released to -updates now, maybe the integration test hack isn't necessary
<bulldog> zyga, plz check this out my 14 days work :) https://github.com/keshavbhatt/snapcraft-gui
<ogra_> slangasek, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/90 please take a look ... if you think thats ok i'll roll a gadget and push to the store
<kyrofa> bulldog, is it really ppa:keshavnrj/snpacraft-gui ?
<bulldog> kyrofa, yes
<bulldog> no :D
<bulldog> wait
<kyrofa> ;)
<kyrofa> Sorry, couldn't resist
<bulldog> damn
<bulldog> kyrofa, i misspelled it :(
<bulldog> yes it is  ppa:keshavnrj/snpacraft-gui
<bulldog> you can get it from there , i have to fix it now :D
<cjwatson> sergiusens: could you rerun the travis test in https://github.com/snapcore/snapcraft/pull/726 ?
<mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
<josepht> cjwatson: you can do it as well by typing a comment with "retest this please" in it
<cjwatson> josepht: oh, that works for anyone?  thanks
<cjwatson> done
<cjwatson> sergiusens: ^- never mind
<josepht> cjwatson: I'm not sure about everyone, but it does for the PR author
<kyrofa> josepht, I thought that just was the jenkins stuff
<cjwatson> I'm not seeing a fresh build on https://travis-ci.org/snapcore/snapcraft/pull_requests as yet
<josepht> elopio: do you know what's going on here?  ^
<sergiusens> josepht cjwatson retest is just for jenkins, I'll trigger the retest of travis
<josepht> sergiusens: oh, sorry cjwatson.  Ignore me
<mup> PR snapd#1828 closed: cmd/snap,client: add snap set and snap get commands <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1828>
<bulldog> tarvis is like launchpad remote building system ??
<bulldog> wow
<bulldog> :D
<bulldog> *travis
<bulldog> made in Germany :)
<arges> hi. upgraded to snapd 2.14.2~16.04 and now when trying to install my local snap I get 'error: cannot find signatures with metadata for snap' any suggestions?
<zyga> arges: try snap install --dangerous
<zyga>           --dangerous  Install the given snap file even if there are no pre-acknowledged signatures for it, meaning it was
<zyga>                        not verified and could be dangerous (--devmode implies this)
<bulldog> zyga, how we sign a snap ??
<bulldog> i mean what  signatures we talking about ?
<arges> zyga: thanks
<arges> zyga: that doesn't work on xenial
<arges> zyga: --force-dangerous
<zyga> hhh
<zyga> arges: hmm, it does for me but perhaps I just ran master without checking
<zyga> bulldog: just by uploading it to the store
<bulldog> oh :) but he is trying local snaps he said
<zyga> bulldog: then you have to use that option
<bulldog> okay :) thanks
<bulldog> am learning travis-ci :D
<bulldog> guys snapcraft-gui build passed on travis-ci :D see here https://travis-ci.org/keshavbhatt/snapcraft-gui/builds/158252620
<mvo> slangasek: thank you! will work to make sure we have fully working autopkgtest again
<arges> jdstrand: i'm packaging up a daemon program that has a socket. I'd like that socket to have root:adm ownership, but seems like fchownat is not whitelisted for seccomp. Whats the snap way to do somethign like this?
<bulldog> kyrofa, i updated the ppa plz check it out now :)
<bulldog> mhall119, you should allow old deb store back :(
<jdstrand> arges: devmode currently
<jdstrand> arges: or alter how you think about it and do root:root 660 (or whatever)
<arges> jdstrand: hmm.
<jdstrand> users and groups aren't spec'd out yet. there are ideas
<arges> jdstrand: (reading interfaces/seccomp/template.go) why do we need per-app UID/GIDs esp. if we have something like a daemon that users in the classic dimension can interact with
<arges> jdstrand: i found bug 1446748, is there something else worth following?
<mup> Bug #1446748: implement seccomp filtering by argument <application-confinement> <ubuntu-core-launcher (Ubuntu):In Progress by jdstrand> <https://launchpad.net/bugs/1446748>
<jdstrand> arges: this is a complicated problem. snap-confine can now filter by argument. what remains is adding policy for that (which I plan to add some to allow using (perhaps the) daemon user but that is after rtm stuff
<jdstrand> arges: and then for arbitrary groups like you just suggested, exposing that in snap.yaml, figuring out what that means with classic vs all snaps, etc
<arges> jdstrand: ok
<jdstrand> arges: and then opt-in per-snap uid/groups come in later so something like postgres can drop privs to a user it wants to instead of say, 'daemon'
<bulldog> we package .deb with travis-ci too . wow
<jdstrand> arges: once I add the logic to snap-confine to map user and group names to uids and gids and then update the policy accordingly, it becomes possible to say 'allow this snap to chown to 'adm'. but figuring out what that means in terms of policy, etc is not as simple
<jdstrand> snappy interfaces mediate access to things already
<arges> jdstrand: would the application be able to do the same 'chown root:adm /thing' or would they need to use something else?
<jdstrand> arges: an application would be able to do that, sure. we'd say 'you can chown to your own uid and this other one'
<jdstrand> that type of thing
<arges> ok
<jdstrand> arges: but, what is it that you are trying to solve today? I may be able to suggest an alternative
<arges> jdstrand: ok
<mvo> pitti: still around?
<pitti> mvo: o/
<mvo> pitti: a bit of a emergency on the snappy candidate image http://paste.ubuntu.com/23147237/
<pitti> mvo: -ish
<mvo> pitti: or can someone with a more us-ish timezone help with that too?
<mvo> pitti: the resolv.conf looks strange and I have no DNS on the images currently
<pitti> mvo: uh, that looks like a sed gone wrong?
<pitti> mvo: what's the Exec= line in your /lib/systemd/system/systemd-networkd-resolvconf-update.service ?
<mvo> pitti: https://launchpadlibrarian.net/282933728/livecd-rootfs_2.420+ppa33_2.420+ppa34.diff.gz
<mvo> pitti: thats the sed
<mvo> pitti: let me look, one sec
<mvo> pitti: http://paste.ubuntu.com/23147248/
<pitti> mvo: that's obviously being applied twice
<pitti> mvo: that, or you have systemd 229-4ubuntu8 from xenial-proposed, which already contains this fix
<pitti> mvo: if you build from x-proposed, you can drop the livecd-rootfs workaround
<mvo> pitti: oh, let me check. that would explain why it suddentdly broke
<pitti> mvo: or replace it with something more robust, i. e. turn
<pitti> +sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
<pitti> into
<mvo> pitti: yes we do
<pitti> +grep -q netif/leases /lib/systemd/system/systemd-networkd-resolvconf-update.service || sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
<mvo> pitti: so I drop the workaround I think
<pitti> mvo: ah, then kill the workaround with fire, I say :)
<mvo> pitti: yeah, that sounds reasonable
 * pitti updates his arithmetic: fix + fix == boom
 * mvo hugs pitti
 * zyga is in awe of mvo 
<mvo> pitti: thanks, you saved me, I would have spend ages on this
<mvo> zyga: be in awe for pitti :)
<zyga> mvo: pitti deserves his own slice of awe but you are saving snappy today :)
<ogra_> what do you guys have with the poor awe
<awe> ;)-
<ogra_> stop slicing him :)
<zyga> lol
<pitti> yummy
<pitti> sorry for the sloppy workaround :)
 * zyga returns to gtest 
<mvo> pitti: all good, you saved the day
<mup> PR # opened: snapcraft#652, snapcraft#661, snapcraft#671, snapcraft#674, snapcraft#716, snapcraft#726, snapcraft#727, snapcraft#736, snapcraft#742, snapcraft#751, snapcraft#758, snapcraft#761, snapcraft#772, snapcraft#773, snapcraft#776
<cjwatson> sergiusens: thanks
<cjwatson> elopio: please use format> why?  % isn't deprecated
<elopio> cjwatson: for consistency, we use format everywhere.
<cjwatson> seems like a waste of typing, but whatever ...
<cjwatson> (will fix things up later, thanks)
<pitti> I think I'll jump from % directly to python 3.6's fstrings once these become available :)
<jcastro> zyga: heya, it looks like xenial-proposed has snap-confine 1.0.38-0ubuntu0.16.04.10
<jcastro> will xenial get 1.0.40 like what is in yakkety?
<cjwatson> yeah, f-strings look like actually a nice improvement, .format just feels clumsy unless you're substituting the same thing more than once
<mvo> jdstrand: did something change wit the review scripts? it looks like the ubuntu-core uploads are no longer automatically accepted in the store
<mvo> jdstrand: I see "manual review pending" now
<jdstrand> mvo: they did but they shouldn't block. can you give me the store url?
<mvo> jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/4142/
<mvo> jdstrand: I manually approved to unblock me
<jdstrand> mvo: 'grade' should not be used with 'type: os' lint-snap-v2_grade_valid
<jdstrand> mvo: I was told grade made no sense with 'type: os'
<mvo> jdstrand: fair enough, something for ogra_ to sort tomorrow I guess, but it might be snapcraft adding that
<jdstrand> that wouldn't surprise me
<jdstrand> mvo: so, I downloaded your image but I don't seem to be using snap-exec
<jdstrand> mvo: I don't have 'unsafe' in the policy and it all seems to work fine
<mvo> jdstrand: yes, it is all fine on pc, its only an issue on pi2 and I have not pushed a new image for that yet
<mvo> jdstrand: it literally build just 5min ago
<ogra_> jdstrand, yeah, thats new
<jdstrand> oh hrm
<ogra_> nothing on our side ...
<jdstrand> well, I don't need the bug to look at this I guess
<jdstrand> ogra_: grade with os snap? sounds like a snapcraft bug then. cprov provided the 'grade' branch and said that it didn't make sense with the os snap
<ogra_> jdstrand, right, new snapcraft landed today i think
<ogra_> mvo, oh, do you need to build another kernel today ?
<cprov> jdstrand: perhaps it was a mistake
<ogra_> then we need to push a new PPA snapcraft with the hhtp_proxy fix for bzr
<jdstrand> kyrofa, sergiusens: fyi, the review tools and snapcraft don't agree about 'grade' with 'type: os'. I'm told by cprov that 'grade' doesn't make sense with 'type: os'. can you guys sort that out so core uploads aren't blocked? let me know if the tools need to change
<mvo> ogra_: could be
<kyrofa> jdstrand, sergiusens cprov might be a question for ogra_ and mvo. Do you ever have core snaps that are in-development and shouldn't be in a stable channel?
<kyrofa> Honestly I don't feel like _anyone_ needs grade
<ogra_> kyrofa, sure, the dailies go to edge
<kyrofa> But if it makes sense for app snaps, then I feel like it probably makes sense for all snaps
 * ogra_ points to https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<kyrofa> ogra_, are you familiar with the "grade" stuff?
<ogra_> nope, never heard of it
<jdstrand> ogra_: doesn't grade prevent promotion to stable?
 * jdstrand is not super-familiar with the grade stuff either
<cprov> Stable and candidates
<kyrofa> jdstrand, indeed, at least that's my understanding as well
<kyrofa> Yeah
<kyrofa> I guess just to prevent a mistake?
<jdstrand> ls
<jdstrand> meh
<ogra_> well, then we definitely never want grade
<kyrofa> Because you promote?
<kyrofa> Rather than create new revs?
<ogra_> because until the OSSnapPromotion is implemented we need to migrate through the channels
<kyrofa> Yeah, makes sense
<ogra_> we wont anymore by GA ...
<kyrofa> But would anyone ever want to use that feature? I feel like it adds more complication making core snaps special cases here
<sergiusens> ogra_ so you don't need it now is different than you don't need it ever
<ogra_> but til then we need to be able to migrate
<sergiusens> I suggest a bug report and get some architect/master designer to comment
<ogra_> sergiusens, well, given that this kills the image that mvo needs to release *now* ... i'm not so sure
<sergiusens> ogra_ just add `grade: stable`
<jdstrand> that won't fix the tools
<jdstrand> the review tools don't like grade with type: os
<jdstrand> I can change that. I just don't know if I should
<ogra_> sergiusens, since i can not use the pfficial snapcraft anyway, where do i need to patch ?
<ogra_> *official
<sergiusens> jdstrand we also are just considering Ubuntu's use case, but other `type: os` builders might need it
<sergiusens> ogra_ in `snapcraft/internal/meta.py`; pop `grade` if `type` == `os`
<ogra_> (i need a hacked snapcraft in any case because bug 1606203 wont be fixed)
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1606203>
<jdstrand> sergiusens: I was not part of the discussion or design. If it is supposed to make sense for type: os, that's fine
<sergiusens> jdstrand I don't know; that is the thing :-)
<jdstrand> sergiusens: yeah, me either
<sergiusens> jdstrand we seldom discriminate if a feature should NOT affect the os snap
<sergiusens> or gadget or kernel
<jdstrand> cprov: you seem closest to this. what is your opinion considering the possibility of non-ubuntu os snaps?
<cprov> jdstrand: I think it was a mistake to discriminate os-snap on CRT
<cprov> my *mistake*
<jdstrand> ok
<jdstrand> I can fix that real quick then
<jdstrand> ogra_: you should probably still patch snapcraft since it won't land immediately
<cprov> jdstrand: can't the current os-snap be manually approved until the next SCA rollout ?
<ogra_> sergiusens, in write_snap_yaml ?
<ogra_> cprov, if it cant go to stable that doesnt help
<jdstrand> cprov: yes. he would only be patching his local copy of snapcraft so he wouldn't have to do that
<cprov> ogra_: if you use "grade: stable" they can go to stable channel
<ogra_> cprov, and to all others too ?
<cprov> yup
<ogra_> it needs to start in edge and migrate up
<ogra_> hmm, then i'll add just that to snapcraft.yaml
<jdstrand> fyi, this is fixed in review tools r739
<cprov> jdstrand: thanks, I will deploy it in staging, will be in prod ~ tomorrow noon. Is it okay to approve os-snap uploads manually until then ?
<jdstrand> cprov: if that is the only warning, yes
<ogra_> mvo, patched snapcraft uploaded to the PPA ... if you need a kernel build, wait til it promoted please (else the world will explode) and ubuntu-core snapcraft.yaml with added "grade: stable" is in the ubuntu-core build branch
<mvo> ogra_: aha, nice
 * ogra_ goes back to TV ... i'll check here occasionally though in case there is something else
<mvo> ogra_: just mild panic,
<mvo> jdstrand: the pi2 with the unsafe bit in the apparmor profile are available at http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<mvo> jdstrand: I verified that the fix works
<mup> PR snapd#1866 opened: many: add snap configuration to REST API <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1866>
#snappy 2016-09-08
<mup> PR snapcraft#777 opened: go plugin: don't put debugging symbols in generated binaries <Created by teknoraver> <https://github.com/snapcore/snapcraft/pull/777>
<mup> Bug #1621304 opened: In the profile setup, pressing enter after filling the email address does nothing <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621304>
<liuxg> does anyone have a nodejs snappy sample for reference in addition to the "shout" on in the demos? thanks
<mup> Bug #1621323 opened: On the all-snaps image, the snapweb interfaces are not connected <Snappy:New> <snapweb:New> <https://launchpad.net/bugs/1621323>
<Kaleo_> mvo, tvoss, I heard something about dbus session bus support or something. Is there something being baked related to that?
<mvo> hey Kaleo_ - no dbus session bus work is happening currently from the core team afaik, is that something important for you/your team?
<Kaleo_> mvo, I think so
<Kaleo_> mvo, wwho is the core team?
<Kaleo_> -w
<mup> Bug #1621339 opened: Unable to complete UC16 beta first boot if ESC is pressed after last step <Snappy:New> <https://launchpad.net/bugs/1621339>
<didrocks> hey mvo! Great job for yesterday's image! I'm curious if you think we'll have a snapd release today with the "revert fix" we discussed about the other day? As this is the last day for us to prepare the image for Monday's event
<Kaleo_> mvo, I've uploaded a i386 snap of test-snapd-thumbnailer-consumer (there was only an amd64 version): is that the right way to support multiple archs? automated review failed, can you let it through?
<mvo> Kaleo_: the most important person to talk to would be gustavo as he will design the feature. however he/we are busy with the "ga" release
<Kaleo_> https://myapps.developer.ubuntu.com/dev/click-apps/5863
<mvo> Kaleo_: yes and yes
<Kaleo_> thanks
<Kaleo_> mvo, great
<mvo> Kaleo_: feel free to join our standups to talk about specific feature you need
<mvo> didrocks: pavel was working on this last I checked, give me a minute to look over the open PRs
<didrocks> thx!
<mvo> didrocks: I really would love to do something for you, even something cheap and hackish like "revert --devmode" so that it preserves the flag, chippaca was also looking at it, but because of the image rush I did not pay too much attention
<mvo> Kaleo_: approved, enjoy
<Kaleo_> mvo, thank you :)
<didrocks> mvo: yeah, I guess it. But indeed, I can hide the --devmode typing quickly when doing the revert and that would work (even if snapd is only in -proposed, I can install my image with it) ;)
<mvo> didrocks: lets keep talking over the course of the day, at this time most people are still sleeping :) at least the relevant ones
<mvo> Kaleo_: my pleasure!
<mvo> I will promote the candidate ubuntu-core images to stable very soon, so if people want to do last minute tests on those :)
<didrocks> mvo: ok, I'll let you just ping me once people are ready for this :)
<didrocks> mvo: does it has reexec? that case, I'll need to ensure I'm adding the magic variable to /etc/environment in case I have to use snapd from -proposed (and so, the package version)
<mvo> didrocks: the version in xenial-updates that got promoted yesterday has re-exec disabled
<mvo> didrocks: because the sru process is now working really well for us and also because it causes some hard to understand behavior
<didrocks> ok!
<tvoss> Kaleo_: we don't need the core Team right now to unblock your work, I'm getting a coffee refill right now, will be online in a few
<Kaleo_> tvoss, COFEE
<Kaleo_> +F
<tvoss> Kaleo_: the core team, so Jamie specifically is aware of our requirements, let's coordinate a little on what we put on their plate
<tvoss> Kaleo_: for the time being, we will unblock you and get you a session dbus in a classic environment
<dholbach> hey hey
<Kaleo_> tvoss, sounds good
<Kaleo_> tvoss, and that means  DBUS_SESSION_BUS_ADDRESS needs to be set right?
<tvoss> Kaleo_: yeah, we are taking care of that stuff
<tvoss> Kaleo_: I think we can have something be eow
<tvoss> by, even
<Kaleo_> tvoss, ok
<mup> PR snapd#1816 closed: libvirt interface to allow snaps to access libvirtd on a classic host <Created by cmars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1816>
<ogra_> hmpf ... so the grade hackery didnt help
<ogra_> all ubuntu-core snaps are stuck :(
<mvo> ogra_: yeah
<mvo> ogra_: if you could give the pi3 image a quick try, that would rock
<ogra_> i'll take a deeper look into patching our snapcraft
<ogra_> mvo, both downloading atm ... i only get 200k/s from cdimage for some reason :/
<zyga> anyone versed in glib-test, is ther any sanity into how -p and -s options work for selecting tests to run
<pitti> mvo: guten Morgen
<zyga> they seem to do nothing sensible at all, I'm trying to follow the source to see what's going on
<zyga> a simple test on some-unit-test-binary -s /stuff-to-skip/ just does nothing and runs all tests with that prefix
<zyga> similarly to -p
<pitti> ogra_, mvo: IIRC you could reproduce bug 1620559, right? would you mind telling your testing result to it, so that we can mark it v-done?
<mup> Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-needed> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Committed by pitti> <https://launchpad.net/bugs/1620559>
<zyga> some values of -p seem to work but the exact criteria are eluding me, it seems the number of slashes in the test name is relevant
<pitti> mvo: does networking behave now?
<ogra_> pitti, it does
<pitti> (I guess RTM day wouldn't be the worst day for it to behave :) )
<mvo> pitti: its working fine, thanks again
<ogra_> pitti, set to verification-done
<pitti> danke
<mup> PR snapd#1867 opened: fix incorrect number of implicit interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/1867>
<mup> Bug #1621378 opened: console-conf should tell the user that the keyboard is US only <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621378>
<mup> Bug #1621380 opened: console-conf should allow to configure a hostname <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621380>
<mwhudson> mvo: did you figure out the GOARM problems in the end?
<mvo> sergiusens: please! https://bugs.edge.launchpad.net/ubuntu/+bug/1621382
<mup> Bug #1621382: launchpad building with stage packages broken <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1621382>
<mvo> mwhudson: which one of them ;)
<mvo> mwhudson: but yeah, after some mild panic attacks we got a images
<mvo> mwhudson: network was broken in between and similar but we got it all under control
<ogra_> mvo, hmm, why did my pi3 just get an ubuntu-core update in the middle of installing the classic snap ?
<ogra_> eeek !
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name         Version  Rev  Developer  Notes
<ogra_> classic      16.04    14   canonical  devmode
<ogra_> ubuntu-core  16.04.1  424  canonical  -
<ogra_> ogra@localhost:~$
<ogra_> mvo, something is wrong with the pi3 image
<mvo> ogra_: no kernel?
<ogra_> ogra@localhost:~$ systemctl status snapd.firstboot.service
<ogra_> â snapd.firstboot.service - Run snappy firstboot setup
<ogra_>    Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled)
<ogra_>    Active: failed (Result: exit-code) since Wed 2016-09-07 21:07:19 UTC; 11h ago
<ogra_>  Main PID: 1448 (code=exited, status=1/FAILURE)
<mvo> ogra_: snap change 1?
<ogra_> ogra@localhost:~$ snap change 1
<ogra_> Status  Spawn                 Ready                 Summary
<ogra_> Done    2016-09-07T21:07:20Z  2016-09-08T08:45:05Z  Generate device key
<ogra_> Done    2016-09-07T21:07:20Z  2016-09-08T08:45:14Z  Request device serial
<mvo> ogra_: snap change 2 :)
<ogra_> thats already the "install classic" call
<ogra_> no trace of firstboot in snap changes
<mvo> ogra_: nothing from firstboot? weeeeh
<ogra_> also no complaint about a missing model assertion
<ogra_> very weird
<ogra_> mvo, dragonboard is fine though ...
<mwhudson> mvo: the hwcap / "please recompile with GOARM=5" one was the one i meant
<mvo> mwhudson: oh, yes, that is the libc aux vector getting srubed by apparmor and that contains the information about the availabity of a floating point unit
<mwhudson> ah ok
<mwhudson> yes, sounds about right
<mvo> mwhudson: tyler and jamie know the even more gorry details
<mvo> but I think this is pretty much it and I changed the apparmor confinment to allow this vector to get passed unchanged
<mwhudson> yeah, go uses it for quite a few things
<matteo> elopio: I've fixed the tests for PR #777
<mup> PR snapd#1867 closed: fix incorrect number of implicit interfaces <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1867>
<mwhudson> mvo: could you subscribe snappy-dev to https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd pls? (for MIR)
<gouchi> hi
<gouchi> I got this error error: cannot find signatures with metadata for snap  when I try to test my snap package
<gouchi> didn't get this error before
<ogra_> use the --dangerous option
<ogra_> i assume you try to do a snap install ?
<gouchi> yes
<ogra_> yeah, then use that for snaps not signed by the store
<nhaines> The Ubuntu Core beta image for Rpi2 is pretty fun.  :)
<nhaines> Is there a story for wireless networking yet?
<gouchi> ogra_: error: unknown flag `dangerous'
<ogra_> nhaines, console-conf does not support it yet (it is in the pipe)
<nhaines> ogra_: "in the pipe" is good to know.
<nhaines> snapweb didn't work at all for me.
<nhaines> And 'snap find' is broken now.
<ogra_> nhaines, you can cheat indeed and put a config into /etc/netwotrk/interfaces.d/wlan0 (and reboot)
<ogra_> broken ? how ?
<nhaines> ogra_: now *that* is exactly what I wanted to know.  :)
<nhaines> ogra_: it used to list all snaps; now it simply returns an error.
<ogra_> thats by design ;)
<ogra_> not broken
<nhaines> It is a regression and probably a bad design.  ;)
<nhaines> Although I'm sure it wasn't scalable.
<ogra_> snap find can only show 100 snaps ... but the sotre has more
<nhaines> This makes it impossible to discover snaps, though.
<nhaines> (So I hope design is on it sometime.)
<ogra_> well, if you have 1mio snaps one day you realyl dont want them listed :)
<nhaines> ogra_: sure, that's what `less` is for.  ;)
<ogra_> sure ... but the less would only start after retrieving lines for 2h :P
<ogra_> (and probably cause an OOM)
<nhaines> :)
<nhaines> So there are problems.  But I was able to have Nextcloud running in all of 30 seconds and I didn't have to do any of that pesky installation or dependencies or configuration.  So there's that!
<nhaines> Should snapweb still be listening on port 4200?
<ogra_> it should ... but it has bugs and fails to start currently
<ogra_> btw... wlan -> http://paste.ubuntu.com/23149789/
<nhaines> Okay, currently broken, that's good to know, too.
<nhaines> I'm not certain that "pull all keys from Launchpad" is a "real world" solution, but I'll be damned if it wasn't absolutely perfect for me.  :D
<ogra_> it will auto-update to a fixed version ;)
<nhaines> Yes, benefit of snappy.  ;)
<nhaines> Although I sort of feel like "wireless networking setup and web administration don't work right now" could have been in the release notes.  :P
<nhaines> But I've been having plenty of fun with snapd on the desktop, and seeing Ubuntu Core 16 start to really take shape is very exciting!
<mwhudson> nhaines: do you want to try a bootleg core snap that might let you configure wifi? :)
<nhaines> mwhudson: yes, sounds like fun.  :)
<nhaines> Particularly because if it doesn't work I can file a bug and jump back to the beta release.  :)
<ogra_> well, not sure you can actually sideload ubuntu-core easily
<ogra_> i think we block that
<mwhudson> i think this would be a "make new image and reflash" sort of test
<nhaines> Not with that attitude!
<ogra_> heh
<mwhudson> builds started on https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot anyway
<ogra_> snappy = safety first :)
<gouchi> now I launch my package and I got "failed: cannot list snaps: access denied" ?
<ogra_> gouchi, wow, thats a weird one
<ogra_> havent seen that before
<nhaines> The real fun of snaps is that betatesting is really painless because reverting to known-good images is as fast as your disk controller.
<ogra_> yeah
<nhaines> gouchi: if you're on a classic desktop Ubuntu, try "snap login" again.
<ogra_> nhaines, well, that should work without
<gouchi> there must have been some changes to snapd because I could test my package
<ogra_> unless gouchi's snap calls "snap list"
<ogra_> internally
<gouchi> no it doesn't
<ogra_> yeah, i assumed so
<ogra_> if you just call snap list manually, does it also throw that error ?
<gouchi> error: cannot list snaps: access denied
<ogra_> wow
<ogra_> is that on desktop ?
<gouchi> strange I must have done something wrong during my installation
<ogra_> or "classic"
<gouchi> I am running on ubuntu 16.04 desktop
<gouchi> I just followed as usual the installation process here : https://github.com/snapcore/snapd
<ogra_> you mean you built snapd from source ?
<mup> PR snapd#1868 opened: Support revert flags <Created by stolowski> <https://github.com/snapcore/snapd/pull/1868>
<gouchi> ogra_: yes
<gouchi> ogra_: sorry for the noise there was wrong permission on /run/snapd.socket
<ogra_> dont you trust our packages ? :)
<gouchi> I try time to time the package if it is working but still failed
<gouchi> I don't understand because opengl software are working
<gouchi> if somebody wants to look here my snapcraft.yaml and wrapper with the log http://www.hastebin.com/xajesehica.coffee
<gouchi> I know I should use dump plugin instead of copy ;-)
<nhaines> ogra_: hmm, /etc/network/interfaces.d/wlan0 didn't seem to work.
<ogra_> nhaines, i used it on my pi3 and dragonboard
<ogra_> on a WPA2 network
<nhaines> Quoting my SSID and trying again.  :)
<mup> PR snapd#1869 opened: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1869>
<zyga> jdstrand: hey, around?
<nhaines> Hmm, still nothing.
<ogra_> any errors ?
<nhaines> I see in dmesg where the devices was renamed from wlan0.  But not where to.
<ogra_> renamed ?
<ogra_> well, use your wired connection to debug :)
<nhaines> [   15.286248] rtl8192cu 1-1.3:1.0 wlx74da386871f1: renamed from wlan0
<ogra_> uuuh
<nhaines> ogra_: yes, that's what I'm doing.  Althuogh...
<ogra_> realtek
<nhaines> My ifconfig-fu is now weak.
<ogra_> thats a USB wlan card, attached externally, right ?
<nhaines> Yes, I bought it specifically because it works on the RPi2 with no special drivers--particularly with Ubuntu MATE.
<nhaines> ogra_: correct.
<ogra_> i bet we dont have the firmware
<nhaines> Hmm, schade.  :)
<ogra_> check in lsmod if a module is loaded for it
<ogra_> and grep in syslog for that module name
<ogra_> i bet you find some error about missing firmware files
<ogra_> if so, file a bug and let ppisati know about it
<nhaines> Hmm, rtl8192cu, rtl_usb, rtl9281c_common, and rtlwifi are all loaded.
<ogra_> that looks ok then
<ogra_> cat /proc/net/dev ?
<nhaines> No errors in syslog.
<ogra_> well, if it was renamed, you need to rename the config file and the name of the device inside
<nhaines> Oh, it lists wlx74da386871f1.  zeros all across.
<nhaines> Hmpf. :)
<ogra_> right ..
<ogra_> these are the new "predictable" network interface names :)
<ogra_> ask lennart poettering whats predictable about them though :P
<ogra_> and indeed, it will only work if you pronounce the name three times in a row aloud
<nhaines> Well, we'll see in 30 seconds I suppo!
<nhaines> suppose!
<nhaines> ogra_: well, that worked!  So now my RPi2 running snappy is twice as useful.  ;)
<nhaines> Welll, I suppose I learned something new with /proc/net/dev.  Thanks very much for helping me troubleshoot that.  :)
<gouchi> adjust program to write to $SNAP_DATA or $SNAP_USER_DATA because the software needs to read/write in ~/.config
<nhaines> Also, just imagine me shaking my fist at Lennart Poettering.
<gouchi> So we need to patch the software to use those env variables ?
<morphis> mvo, pedronis: where can people who want to generate an image for supported devices (pi, dragonboard) get a model assertion from? Do they have to always generate one on their own or is it possible to fetch the official signed one from somewhere?
<ogra_> nhaines, heh, glad it worked
<ogra_> morphis, afaik thats still in the works, there will be a way to get it generated via the store or LP or so
<nhaines> ogra_: now to figure out how to change the hostname.  Although I do want to file a bug that nano isn't around.  :P
<morphis> ogra_: ok, so for now I have generate my own one or take it from "somewhere"
<ogra_> morphis, if you want to do basic boot testing you can use UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1  with ubuntu-image
<morphis> ah
<morphis> so I still need one but can use without signature
<ogra_> morphis, note though that will only help with boot stuff ... snap commands will not work in the booted image
<morphis> ogra_: hm
<ogra_> (firstboot will refuse to run without a signed model assertion)
<mvo> morphis: its possible to get it from the store, it will be in the assertion store in a bit, I can mail you one in the mantime
<morphis> mvo: got the pc.model already from your snapd PR
<morphis> but was wondering about one for the pi2/pi3
<ogra_> well, we need a way to use self signed ones
<ogra_> since what mvo will give you will be the official canonical assertion ...
<ogra_> whihc makes your home built images kind of official :)
<zyga> seb128: hey
<mup> PR snapd#1870 opened: store: ensure the payment methods method handles auth failure <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1870>
<zyga> seb128: do you know who manages snapd-xdg-open on github? I have a few things pending there without reply
<seb128> zyga, hey, attente did most of the work and mvo helped with review&landing I think
<seb128> zyga, I don't understand your "package for <...>" issues reports
<seb128> zyga, distributions doing packaging isn't an upstream issue
<mup> PR snapd#1871 opened: snap: lessen annoyance of implicit interface tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1871>
<morphis> ogra_: yeah
<morphis> ogra_, mvo: so what is the one in https://github.com/mvo5/snappy/blob/c230019df76d27ce7c67f3003e1c0ca945030c2d/tests/lib/prepare.sh signed with?
<morphis> ogra_: and with that we basically require people to create their own model assertion when they want to build an image which is different to the official one
<ogra_> exactly
<mup> PR snapd#1869 closed: cmd/snap: serialise empty keys list as [] rather than null <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1869>
<morphis> ogra_: good
<zyga> attente: hey, around? could you please add me to snapd-xdg-open on github / review branches
<zyga> seb128: the package bugs are just so that we have downstream packages for all the distros
<seb128> zyga, that's not an upstream issue...
<zyga> seb128: I agree it's not an upstream issue but this is an easy way to track it
 * seb128 sends zyga some postits
<ogra_> with passwords on them ?
 * seb128 writes "ubuntu/ubuntu" on the postits
<zyga> but.. I have all the ubuntu stickers already
<seb128> zyga, is there any change you need to commit? I had a look and you don't have anything major there, having an empty README is probably not bothering many people
<seb128> or is that to get a 0.1 tarball out?
<zyga> seb128: correct
<zyga> seb128: this blocks the fedora package
<seb128> why?
<mup> PR snapd#1872 opened: tests: use in-tree snap{ctl,-exec} for all tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1872>
<seb128> they for sure have git snapshot packages
<zyga> seb128: because snapshot vs release packaing
<seb128> that's a lame excuse
<zyga> seb128: and we should just release
<jdstrand> zyga: hey
<seb128> you could grab the package .tar.gz and claim that a release
<zyga> jdstrand: hello, nice to see you
<zyga> seb128: no, that's not how fedora packaging works
<zyga> seb128: anyway, this is a moot discussion
<seb128> right
<jdstrand> zyga: you too :)
<zyga> jdstrand: I did plenty of updates to the ns-support module
<seb128> zyga, well I know if some desktop packages they have that are git snapshot so it's a lame argument to block things they don't want I guess
<zyga> jdstrand: there are still a few things but I was wondering if we can merge it and iterate (after a 2nd review with the new changes)
<seb128> zyga, but as you said, no point arguing, easy enough to roll a tarball
<jdstrand> zyga: ok, I'll take a look
<jdstrand> let me get through email for anything urgent
<zyga> seb128: I mean, I could do a snapshot realease but I really don't want to, part of what I need to do is to ensure that all the distros ship the same thing and it is easier with versions
<seb128> right
<zyga> jdstrand: I'd like to propose a small branch that actually uses it, along with some simple spread tests, and let people play with the real thing
<zyga> seb128: I should also ITP snapd-xdg-open in debian
<mup> Bug #1564369 changed: sudo broken in latest classic <Snappy:Fix Released> <https://launchpad.net/bugs/1564369>
<zyga> jdstrand: there will be a change to snap-confine and a new executable snap-discard-namespace
<zyga> jdstrand: (not setuid root!)
<attente> zyga: hey, sorry, but i don't have write access to that repo either
<zyga> attente: oh, interesting
<zyga> so who does? :)
<zyga> mvo: FYI, I wrote what-is-mounted that prints json with all the details based on mountinfo
<attente> zyga: should be didrocks and mvo
<zyga> I think grep and awk are ok but if we ever need something more complex we should perhaps think about it
<zyga> didrocks: do you have commit access to snapd-xdg-open on github.com/snapcore/snapd-xdg-open?
<jdstrand> whoa
<jdstrand> how did the libvirt interface go through without security review?
<jdstrand> zyga, mvo: ^ libvirt should not auto-connect
<ogra_> well, security ... who cares :P
<jdstrand> it gives a direct path to root
<jdstrand> just like lxd and docker
<zyga> jdstrand: should it it auto-connect but be restricted?
 * ogra_ pushes code for an nsa interface that auto-connects ... lets see :P
<zyga> ogra_: make sure it doesn't show in snap interfaces
<ogra_> thats indeed the ppurpose :)
<jdstrand> zyga: there are choices to be made, sure. but there was no discussion or coordination on restricting it
<jdstrand> zyga: there is nothing in snapd that limits its use to a certain snap atm. there is nothing in the review tools that would limit it (other than the fact that the review tools would warn cause it isn't a known interface yet (thank goodness for defensive tools))
<zyga> jdstrand: sure, I don't dispute the no-review part
<jdstrand> it also doesn't have any comments on how much privilege it gives
<mvo> jdstrand: sorry, I think this one was my fault. I will push a branch that removes the auto-connect
<jdstrand> I thought there was an understanding that all security policy went through a member of the security team?
<jdstrand> ok
<abeato> mvo, hey, do you know if the issue with rpi/vfp detection has already been solved?
<mvo> abeato: yes, that is fixed
<abeato> mvo, nice, thanks
<jdstrand> mvo: if I comment on the original branch, will you incorporate the changes? (feel free to autoconnect now)
<cjwatson> Hmm, I think the autopkgtest failures on https://github.com/snapcore/snapcraft/pull/726 are a test infrastructure bug of some kind - I already added snapd to Depends in debian/tests/control, but it doesn't appear to be being installed
<mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
<jdstrand> mvo: err, feel free to make autoconnect false now
<mvo> jdstrand: yes, PR on the way
<mvo> jdstrand: sorry again
<jdstrand> ok, thanks
<mup> PR snapd#1873 opened: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/1873>
<didrocks> zyga: added
<zyga> didrocks: thank you!
<didrocks> yw
<morphis> mvo: shouldn't snapd rexec itself when I install the edge ubuntu-core snap on my desktop?
<zyga> morphis: AFAIR we disabled this lately
<ogra_> unless you have exported the env var that prevents this it should
<ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version
<ogra_> snap    2.14.2~16.04+ppa224-1
<ogra_> snapd   2.14.2~16.04+ppa224-1
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> this is definitely not the binary from the installed package
<ogra_> but from ubuntu-core
<morphis> zyga, ogra_:  export SNAP_REEXEC=1 ?
<ogra_> well, you shouldnt need to export it ...
<ogra_> at least on my machines i get the in-ubuntu-core binary without any tinkering
<ogra_> if you want to suppress it you need export SNAP_REEXEC=0 though
<zyga> morphis: I think this is set in the service environment file
<morphis> ok
<zyga> morphis: so snapd won't reexec, snap might if you set it in the shell directly
<morphis> let me try zhat
<ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service
<ogra_> EnvironmentFile=/etc/environment
<ogra_> not really
<ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems$ grep Env /etc/systemd/system/multi-user.target.wants/snapd.service
<ogra_> EnvironmentFile=/etc/environment
<ogra_> nor on my desktop
<ogra_> (both xenial)
<morphis> Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd"
<morphis> with SNAP_REEXEC=1 in /etc/environment
<morphis> ah that gives me snap sign :-)
<morphis> ogra_: you now have the unsigned model assertion for the pi somewhere?
<ogra_> pi2 or 3 ?
<morphis> both :-)
<ogra_> http://paste.ubuntu.com/23150160/
<ogra_> just replace the gadget name :P
<morphis> aye
<mvo> morphis: not anymore, re-exec got disabled
<morphis> mvo: see the log output above
<morphis> hm, now I only get a: error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure
<morphis> when I try to sign my own model assertion
<abeato> it looks like it is not possible to run strace now with a snapped command :(
<ogra_> mvo, why do i have 2.14.2~16.04+ppa224-1 in "snap ---version" then ?
<ogra_> i definitely dont have that package installed
<ogra_> mvo, dpkg -l shows snapd 2.13 installed ... snap --version the ppa string ... so i guess if you wanted to prevent re-exec this didnt work
<zyga> jdstrand: I have a quick branch for working snap-confine with ns-sharing, I am still cooking it to contain the spread tests that I wrote
<zyga> jdstrand: I didn't do the hat -> profile change update yet
<morphis> mvo, ogra_: any idea about that error message?
<zyga> jdstrand: do you know who sends the signal (in terms of apparmor peer) when prctl() set-parent-death-signal happens?
<morphis> mvo, ogra_: generated a key locally
<zyga> jdstrand, tyhicks: the relevant commit is: https://github.com/snapcore/snap-confine/commit/865c5dfb9704d71c16fafc2cf42ef95c1fd2933e
<mvo> morphis: apt list snapd shows you 2.13? this still re-execs, please apt upgrade to 2.14.2
<morphis> mvo: I've updated to 2.14.2
<jdstrand> zyga: I was actually wondering how that would show up in policy myself. aiui, the kernel will send it, so guessing that our base abstraction will allow it
<morphis> and added SNAP_REXEC=1 to /etc/environment
<morphis> mvo: which gives me
<morphis> Sep 08 15:22:25 nirvana /usr/lib/snapd/snapd[17662]: cmd.go:81: DEBUG: restarting into "/snap/ubuntu-core/current/usr/lib/snapd/snapd"
<zyga> jdstrand: yes, I was expecting the kernel to send it as well
<zyga> jdstrand: please comment on the profile there, I'll open a pull requst once I have a few more spread tests
<mvo> morphis: uh
<morphis> mvo: don't tell me that shouldn't be possible :-)
<ogra_> morphis, nope, i never signed a model assertion ...
<mvo> morphis: I'm slightly confused - so snapd is re-execing even with 2.14.2 ? SNAP_REEXEC=1 should be the only way to enable this
<ogra_> and i dont think you can "just sign" it
<ogra_> it must come from a valid store account
<mvo> morphis: sorry for being a bit thick - do you want it to re-exec or do you want to disable that?
<morphis> mvo: ok, lets correct this: I've added SNAP_REEXEC=1 to /etc/environment
<morphis> mvo: and I want rexec
<ogra_> mvo, he wants to know whats the default :)
<mvo> morphis: ok, wit hthat setting it should re-exec
<morphis> ogra_: I want snapd from edge on my desktop from the edge ubuntu-core snap :-)
<mvo> morphis: the default is now (with 2.14.2) SNAP_REEXEC=0 unless you set it to something else
<zyga> jdstrand: (separate topic) do you think snapd-xdg-open should be confined
<zyga> jdstrand: it processes input from untrusted snaps
<zyga> jdstrand: I was thinking aobut cooking a profile for it
<mvo> morphis: so SNAP_REEXEC=1 should give you re-exec - but its not working you say?
<ogra_> oh, why didnt i get a new snapd with todays upgrade
<ogra_> ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version
<ogra_> snap    2.14.2~16.04
<ogra_> snapd   unavailable
<ogra_> series  -
<ogra_> interesting
<ogra_> that output changed a lot now
<morphis> mvo: it works
<morphis> mvo: I am now getting error messages when signing a model assertion
<morphis> $ cat pi3.json| snap sign
<morphis> error: cannot sign assertion: bad GPG produced signature: it does not verify: openpgp: invalid signature: RSA verification failure
<mvo> morphis: aha, nice. well, not nice but progress. let me check
<morphis> mvo: created a key with $ snap create-key which I know want to use to sign the model
<morphis> mvo: yeah, one step forward
<ogra_> hmm, so updating to snapd 2.14.2 seems to have killed everything for me
<ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<ogra_> ogra@styx:~$ snap --version
<ogra_> snap    2.14.2~16.04
<ogra_> snapd   unavailable
<ogra_> series  -
<ogra_> ogra@styx:~$
<mvo> ogra_: anything in syslog? a crash or something?
<ogra_> thats after a simple apt install snapd
<ogra_> which got me upgraded
<ogra_> mvo, yeah http://paste.ubuntu.com/23150243/ .... seems it is very unhappy that i had an ubuntu-coore from edge running
<mvo> ogra_: yes, that is tricky
<gQuigs> what does, snapd.refresh.timer: Adding 53min 43.246331s random time." mean?
<gQuigs> and could it be messing with the system time (machine ends up off by a lot)
<zyga> gQuigs: I think it means that systemd added a randomized interval to the refresh timer
<zyga> gQuigs: there's a bug open on this but it feels like systemd is just very talkative
<gQuigs> well than that's not the cause, thanks zyga!
<jdstrand> ogra_: you probably noticed I approved all the ubuntu-core snaps
<ysionneau> can someone validate (manual review) my tfacedetect snap on Parrot private store please? It's for an emergency demo
<ogra_> jdstrand, ah, no i didnt ... did you approve more than 5 ? because we just did a test build to check if cprov's chaneg worked :P
<ogra_> *change
<ysionneau> "parrot_store_demo"
<jdstrand> ogra_: they were all from 4 hours or more ago. I think it was more than 5
<mup> PR snapd#1824 closed: tests: use ubuntu-image for the ubuntu-core-16 image creation <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1824>
<ogra_> jdstrand, hmm, so the ones from 3min ago went through automatically then i guess ... great
<ogra_> *33min
<ogra_> well, let me just start another build ... it only takes 10-15 min
<ogra_> cprov, smells like it worked ... but to be sure i'll do another one :)
<jdstrand> ogra_: https://myapps.developer.ubuntu.com/dev/click-apps/4142/rev/539/ had r739 of the tools and it passed
<jdstrand> so, yeah, looks good
<ysionneau> anyone with admin rights on the stores?
<ogra_> cprov, and thanks for the timeout fixes ... i can open the uploads overview again \o/
 * ogra_ wonders if the stats page also works 
<ogra_> ah, well, that still times out
<morphis> pedronis: already back to work? :-)
<ogra_> run pedronis run !
<cprov> ogra_: stats page was not worked on yet, revision history and snap-release are quick enough now.
<ogra_> yeah, totally ...
<morphis> mvo: already any idea what could be wrong?
<ogra_> thanks so much !
<mvo> morphis: sorry, not yet, could you pastebin yourjson? but it might be something for pedronis, he worked on this recently, we don't have a spread test unfortunately so it might simply be not fully working yet
<morphis> ok
<morphis> mvo: was just wondering as he gave me a tool to create a set of test keys and with that it works fine
<morphis> so looks like something with the setup of create-key is wrong
<morphis> mvo: https://paste.ubuntu.com/23150420/
<cjwatson> elopio: can you help me see why the autopkgtests in https://github.com/snapcore/snapcraft/pull/726 are failing?  it sort of looks like they might be taking test dependencies from master rather than from the PR branch, but I could be wrong
<mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
<cjwatson> (assuming you're the right person to ask, I'm not really sure)
<kyrofa> cjwatson, you're correct, he's the person you want. He may not be in for a little bit yet, though
<elopio> cjwatson: give me a few minutes
<elopio> cjwatson: the jenkins job only sends adt-run to the testbed, and it takes care of the installation and dependencies.
<cjwatson> I can't work out why snapd wouldn't be installed; it's listed in Depends in debian/tests/control
<elopio> cjwatson: didn't you say that this depends on a feature that's not yet in xenial-updates? If so, we might need to install it before adt-run.
<mup> PR snapd#1874 opened: snap: support assertion references in `snap prepare-image` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1874>
<cjwatson> elopio: it's in xenial-updates as of yesterday
<cjwatson> so I don't think that explains it
<elopio> cjwatson: the error is not that snapd is not installed, it's unknown flag json. pexpect sucks when the output is too different from what you expect.
<elopio> so, as far as I know, this machines should have -updates enabled. Let me check.
<cjwatson> true; but there's no record of snapd being installed in the console log
<cjwatson> oh, maybe it's preinstalled and I need to force the version?
<cjwatson> that could make a certain amount of sense
<elopio> that makes sense, true.
 * cjwatson tries that
<cjwatson> autopkgtest snaps is I think definitely not my problem
<elopio> but you have this line in tests/control: snapd (>= 2.14.2~) I thought that would make adt-run update the preinstalled one.
<elopio> I'm checking if the demos work in master.
<mup> Bug #1621525 opened: classic environment variables for daemon snaps <Snappy:New> <https://launchpad.net/bugs/1621525>
<elopio> hah, I undersetand now, you have just added that. Too fast.
<balloons> zyga, any news on when snap-confine 1.0.40 will hit xenial?
<elopio> cjwatson: this https://github.com/snapcore/snapcraft/pull/778 and a change in a branch by sergiusens are required to get the snaps suite back to green.
<mup> PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
<elopio> nothing to do with your change.
<nacc> is there a direct link to the agreement that needs to be signed before uploading snaps?
<mup> PR snapcraft#778 opened: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
<cjwatson> elopio: glad to hear it - and indeed autopkgtest integration passes on my branch now
<elopio> cjwatson: \o/ thanks. sergiusens: so waiting for your review.
<elopio> nacc: maybe nessita or noise][_` can help you there.
<nacc> elopio: thanks!
<cjwatson> nacc: https://myapps.developer.ubuntu.com/dev/tos/
<nacc> cjwatson: thanks!
<cjwatson> nacc: or https://myapps.developer.ubuntu.com/dev/agreements/new/ if what you want is a link that will prompt for a signature if the developer hasn't already signed it rather than just the text (but it redirects to /dev/click-apps/ if they have)
<nacc> cjwatson: got it, thanks!
<ogra_> booo ...
<nacc> rharper: --^ does that help? :)
<ogra_> snapctl breaks autocompletion for the snapcraft command now :P
<ogra_> (well, doesnt break but if i need to type snapcr<tab> i can as well type the full thing)
<kyrofa> ogra_, heh, sorry about that
<kyrofa> ogra_, hopefully eventually we can move it into /usr/lib/snapd, but snap-confine doesn't currently support updating the PATH
<ogra_> ah, cool then
<mup> PR snapcraft#779 opened: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779>
<rharper> nacc: thanks!
<nacc> rharper: np
<SamYaple_> sergiusens: adding in some python stuffs. Was the plan to unify the test suites as well? we are still duping alot between python2 and python3 in the test suites
<SamYaple_> sergiusens: my vote would be a new python test and then just test the python2 and python3 bits explicitly to maintain the backwards compat until fully deprecated
<zyga> balloons: it almost has, we SRU'd most of the patches. my plan is to release .41 soon and SRU that
<zyga> jdstrand: thanks for spotting another -1 :)
<zyga> jdstrand: I'll fix that in a moment
<jdstrand> :)
<zyga> jdstrand: did you have a look at the real thing?
<jdstrand> I'm going through the whole thing now
<zyga> jdstrand: I"m somewhat worried about the cgroup there, feels like we should think how shared mnt namespace + cgroup interact
<zyga> thanks! I just returned and I'm available
 * zyga finally emerged haskell toolchain on gentoo, geez that took forever
<balloons> zyga, I ask because the issue with juju snap and lxd isn't fixed in the SRU'd patches
<balloons> so any ETA? Will it be there before next week? Possible?
<zyga> balloons: can you point me to those issues?
<balloons> zyga, https://bugs.launchpad.net/snap-confine/+bug/1613845
<mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Released by zyga> <https://launchpad.net/bugs/1613845>
<mup> Bug #1621550 opened: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <https://launchpad.net/bugs/1621550>
<zyga> balloons: lxd has a quirk that owrks in devmode
<zyga> balloons: right, that might not be SRUd
<balloons> zyga, it's not. But 1.0.40 does solve it
<zyga> balloons: because we were working on SRUing higher priority tasks
<balloons> jcastro, ^^
<popey> can someone please help with this:- http://paste.ubuntu.com/23150846/ - login there and yaml - the command never runs, seems to barf at the wrapper
<popey> suggestions welcome
<balloons> zyga, the charmers summit is next week, and we'd love to highlight using snaps to get juju, but this breaks the story. That's why I was asking
<popey> (it is a very simple yaml)
<zyga> balloons: let me check the SRU queue
<zyga> looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html I see snap-confine but (I'm not super familiar with the report) I don't think it is currently in flight
<balloons> zyga, https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.10 doesn't have it, which was in proposed
<zyga> balloons: if you can help with the SRU I'd love to do it
<zyga> balloons: I cannot dput though (I'm not a core dev)
<balloons> zyga, ahh. But it would just need sponsered is all
<zyga> balloons: but I can try to work on the paperwork when it is avaialble
<zyga> balloons: does it have to be in yakkety fifst?
<balloons> zyga, is there a reason you would pursue cherrypicking, rather than just sru 1.0.40 that is already in yakkety?
<zyga> first?
<zyga> balloons: that's what we did before becasue we couldn't get an effective SRU for many weeks
<mhall119> sergiusens: has there ever been a discussion about having an "exec" plugin that would let you run some script or binary at build-time in snapcraft?
<balloons> zyga, as 1.0.40 is in yakkety, it should just be a matter of uploading it to the xenial queue and asking for an SRU
<zyga> balloons: so we tried to SRU the essential thing each time so that nothingh would regress and we would not risk any daly
<zyga> balloons: can you do that?
 * zyga should apply for per-package upload rights
<balloons> yes, you should :-)
<balloons> I cannot upload, but we can get someone to sponsor
<zyga> slangasek: could you perhaps sponsor snap-confine from yakkety into xenial-proposed so that we can work on an SRU
<slangasek> zyga: "so you can work on an SRU" - what do you mean by that? isn't the work of an SRU the preparation of the SRU bug and the preparation of the upload?
<zyga> slangasek: we just need to get the upload in the queue so that I can work on the paperwork
<zyga> slangasek: I'd like to do the full process once but I cannot upload
<zyga> jdstrand: thank you for the review, I'll fix the trivials and work on statfs change
<nacc> zyga: you can do the SRU paperwork (by which do you mean the bug update?) without the upload being in the queue
<zyga> nacc: ah, I see, so I should file the bug, document everything (delta from the desired version and proposed)?
<slangasek> zyga: you should absolutely file the bug first, the bug has to be referenced in the changelog of the SRU
<sergiusens> mhall119 yes there has, https://github.com/snapcore/snapcraft/pull/727, the general consensus is it wouldn't be in core
<mup> PR snapcraft#727: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <Conflict> <https://github.com/snapcore/snapcraft/pull/727>
<zyga> slangasek: understood
<sergiusens> SamYaple_ yeah, unifying the tests would be good
<nacc> zyga: yeah, that's my usual approach, get the bug filed first, prep per the template, then subscribe sponsors, etc.
<mhall119> thanks sergiusens, I assumed it would have come up before
<sergiusens> mhall119 that is not the first one, but we kept it open to not repeat ourselves all the time ;-)
<jdstrand> zyga: thanks for all the changes! I thought your comment changes were great
<zyga> jdstrand: I'm not sure about this typo; can you please show me where it is? https://github.com/snapcore/snap-confine/pull/126#discussion_r78042899
<mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
<mup> Bug #1621568 opened: Unable to access system fonts <Snappy:New> <https://launchpad.net/bugs/1621568>
<jdstrand> zyga: you have populate*d*
<jdstrand> zyga: oh wait. you added sc_should_populate_ns_group. please disregard
<zyga> jdstrand: ah, sorry, yes  there was a discrepancy in that function name for a moment
<zyga> jdstrand: thanks!
 * zyga learned a lot of cool things while working on snap-confine and its test suite
<balloons> zyga, are you all set for the SRU then? It should be a matter of filing the bug, and preparing a source branch to hand off
<zyga> balloons: filing the bug, yes, preparing source branch, not sure what that entails yet
<balloons> zyga, it shows you as the creator of 1.0.40 on yakkety -- what branch did you use?
<zyga> balloons: git.launchpad.net/snap-confine AFAIK
<zyga> balloons: there's a git repo there with packaging for all ubuntu releases
<zyga> balloons: this is modeled after fedora's fantastic fedpkg workflow but all it is is the debian directory in a git tree
<balloons> zyga, did mvo do all the archive work then? I see you as the package uploader
<zyga> balloons: perhaps, I don't quite know, I did send a source package to him a while ago
<zyga> balloons: I think it may have been uploaded through debian
<zyga> balloons: but my memory is very rusty there
 * zyga promises to work with mwhudson on collab-maint for snap-confine now
<balloons> zyga, I suppose to be fair since the yakkety build works as-is on xenial you could reuse the source package
<balloons> have you filed an SRU before?
<zyga> balloons: I was working on kernel SRUs in the cert team but I didn't really do an SRU for other things entirly by myself I think
<zyga> perhaps eons ago for pyotherside
<balloons> zyga, file a bug like this: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1593396
<mup> Bug #1593396: [SRU] 1.0.38-0ubuntu0.16.04.4 <snap-desktop-issue> <verification-needed> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1593396>
<balloons> zyga, the full procedure and template is here: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
 * zyga nods
<zyga> I'll look at that first thing tomorrow
<mup> Bug #1621575 opened: Poorly worded error when installing a local snap without assertions <Snappy:New> <https://launchpad.net/bugs/1621575>
<mup> Bug #1619718 changed: ubuntu-image created vfat eats itself after a while (mcopy creates wrong subdirs) <verification-needed> <Snappy:Fix Released> <Ubuntu Image:Invalid> <mtools (Ubuntu):Fix Released by vorlon> <ubuntu-image (Ubuntu):Fix Released> <mtools (Ubuntu Xenial):Fix Committed by vorlon>
<mup> <ubuntu-image (Ubuntu Xenial):Invalid> <https://launchpad.net/bugs/1619718>
<zyga> jdstrand: does this look good? https://github.com/snapcore/snap-confine/pull/126/commits/40a93a241b1fbfc34c6eb6b9e87f951b218ee1c7
<mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
<zyga> jdstrand: all I have to fix left is rm_rf sanity checks
<zyga> jdstrand: I'd like to merge this and then propose the branch that makes snap-confine use things :)
<mup> PR snapcraft#780 opened: Organize without removing files on target <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/780>
<Pharaoh_Atem> zyga: whoa, you're following dist-git style for snap-confine ubuntu packaging?
<zyga> Pharaoh_Atem: so far :) It's not fully live yet because of lots of things that we had to do ASAP but I was wondering how to use that for packaging more reliably
<zyga> Pharaoh_Atem: (in debian and ubuntu)
<zyga> Pharaoh_Atem: if you want to know what I'm up to lately look at the pull request referenced above, it's pretty neat stuff :)
<elopio> sergiusens: back to green: https://github.com/snapcore/snapcraft/pull/778
<mup> PR snapcraft#778: Use --force-dangerous when testing the installation of snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/778>
<Pharaoh_Atem> zyga: well, I'd definitely be happy to see ubuntu adopt a dist-git style system
<Pharaoh_Atem> makes it much easier to figure out what's going on :)
<zyga> well, not ubuntu, it's just me trying but I think I'll stick to it if I can :)
<zyga> Pharaoh_Atem: snapd-xdg-open was released upstream AFAIK, I'll look at updating my spec files and I think it should be good to go
<Pharaoh_Atem> did you get around to snapd-glib too?
<zyga> Pharaoh_Atem: I have what I did before, without the correct package split, if you want I can show you what I got
<zyga> Pharaoh_Atem: (so no -devel and stuff)
<Pharaoh_Atem> sure
<zyga> Pharaoh_Atem: one moment, I ran out of ram with gentoo emering webkit lately so I had to shut everything but gentoo down
<mup> PR snapcraft#778 closed: Use --force-dangerous when testing the installation of snaps <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/778>
<kgunn> yo, has anyone ever run into missing socket?...like so...
<kgunn> kg@kg-MacBookPro:~$ snap list
<kgunn> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd-snap.socket: connect: no such file or directory
<kyrofa> kgunn, are you up-to-date?
<kgunn> kyrofa: updated 2 days back
<kgunn> kyrofa: i'm on xenial + stable-phone-overlay enabled
<kyrofa> kgunn, core snap is up to date as well?
<kgunn> full disclosure :)
<kyrofa> kgunn, heh, I always assume you're using that
<kgunn> kyrofa: let me update real quick
<kyrofa> kgunn, yeah, make sure. That was an issue last week, but it should be fixed by now
<zyga> re
<zyga> Pharaoh_Atem: ok, I got my fedora up
<zyga> Pharaoh_Atem: http://paste.ubuntu.com/23151324/
<zyga> Pharaoh_Atem: (that's not much :)
<Pharaoh_Atem> it's a good start, at least
<zyga> Pharaoh_Atem: that's 0.8, 0.10 was released with some fixes (license is one of them)
 * zyga looks at refreshing that
<Pharaoh_Atem> I'm impressed that you're using the common name provides
<Pharaoh_Atem> it'll enable you to reuse the spec for openSUSE relatively easily
<zyga> I love them because they speak in the language of the problem
<zyga> the upstream pkg-confing names
<zyga> pkg-config*
<Pharaoh_Atem> the whole reason these things exist is because it's a way for us to guarantee a resource, be it a build dep or a runtime dep
<Pharaoh_Atem> regardless of packaging style
<zyga> some of the build-deps there aren't perfect, I don't quite know how vala tooling looks like today and the set I have there is what seems to work but I suspect a smaller set is sufficient
<Pharaoh_Atem> I usually use the build system as a reference to figure out build deps
<mup> PR snapd#1815 closed: interfaces: auto-connect interface required by livepatch <Created by arges> <Closed by arges> <https://github.com/snapcore/snapd/pull/1815>
<kgunn> kyrofa: just sharing, fwiw, not sure how it got goofed...but apt-get install --reinstall snapd, then systemctl start snapd did the trick
<Pharaoh_Atem> oh good, you are moving from com.canonical.* to io.snapcraft.*
<kyrofa> kgunn, huh, yeah odd
<Pharaoh_Atem> I was hoping that would happen
<zyga> just a little more and I'll have updates for 0.14
<Pharaoh_Atem> have you at least tested my selinux policy module for snapd on f24?
<zyga> Pharaoh_Atem: http://paste.ubuntu.com/23151347/
<zyga> Pharaoh_Atem: no, not yet, I really have to finish snap-confine features first
<zyga> Pharaoh_Atem: I did some work on gentoo but not much either
<zyga> Pharaoh_Atem: I want to get gentoo overlay up-to-date which is easy, just takes NaN minutes to build
<zyga> Pharaoh_Atem: I did read your code though
<zyga> Pharaoh_Atem: it's just that I'm still super-green with selinux in practice, I would not be able to write that my self yet
<zyga> Pharaoh_Atem: I pushed the partial packaging to my snapcore-fredora repo, I'll look at the proper splitting policy down the week
<jdstrand> zyga: sorry was in a meeting and had some followups. looking
<mup> PR snapd#1866 closed: many: add snap configuration to REST API <Reviewed> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1866>
<zyga> jdstrand: no worries, thanks!
<zyga> jdstrand: I added a sanity test to ensure my reasoning on nsfs is accurate: https://github.com/snapcore/snap-confine/pull/126/commits/db1a0765f6b058ab24df30931c2f357b57f243f2
<mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
<mup> PR snapcraft#726 closed: Implement basic form of `snapcraft register-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/726>
<mup> PR snapcraft#776 closed: Updated the contents of the snapcraft init template <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/776>
<sergiusens> SamYaple_ still around?
<sergiusens> SamYaple_ asked a question in snapcraft#779 ; last time they went unnoticed so making sure this one doesn't :-)
<mup> PR snapcraft#779: Do not compile pyc files when installing with pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/779>
<jdstrand> zyga: nice
<zyga> jdstrand: :) I'll fix rm_rf and merge
<zyga> jdstrand: I'll double check I didn't miss anything
<SamYaple_> sergiusens: looking
<SamYaple_> sergiusens: i noticed there were still some pyc files, but not all of them. im still not sure why. the fact remains there were less and it did shave of build time
<SamYaple_> sergiusens: oh you know what i just had a thought. I wonder if some of the pyc files are getting created when other python packages are getting installed, something importing other python packages on install or somehting
<jdstrand> zyga: hey, while you are in there, I noticed that snap-confine needs this when running over ssh: /dev/pts/[0-9]* rw,
<jdstrand> apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/pts/2" pid=28375 comm="ubuntu-core-lau" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
<jdstrand> zyga: I noticed this ssh'ing into a xenial classic system and using 'hello-world'
<jdstrand> zyga: I can do a PR if it is easier
<jdstrand> zyga: hoping you are EOD. I'll do a PR
<jdstrand> zyga: fyi, https://github.com/snapcore/snap-confine/pull/128
<mup> PR snap-confine#128: allow read/write to /dev/pts/[0-9]* needed for running snaps under ssh <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/128>
<sergiusens> SamYaple_ that might be it
<zyga> jdstrand: hmm, curious why is that?
<zyga> jdstrand: I work over ssh all day
<zyga> jdstrand: and I didn't need it
<sergiusens> SamYaple_ setup the env with https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE
<sergiusens> SamYaple_ maybe even in `env` so we don't get warnings when running from the snap even
<zyga> jdstrand: could it be ssh + screen or something like that?
<zyga> jdstrand: (the hint there is "file_inherit" btw)
<jdstrand> zyga: I suspect it has something to do with it being a classic system. I didn't dive into why. I'm not doing anything special
 * jdstrand nods
<jdstrand> I'm not using screen
<jdstrand> oh I know
<jdstrand> it is cause I am using pam-apparmor on that box
<jdstrand> sshd is confined
<mup> PR snapcraft#780 closed: Organize without removing files on target <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/780>
<jdstrand> zyga: ^
<zyga> ah, interesting
 * zyga investigates pam-apparmor
<jdstrand> zyga: The inherited fd is mediated since it isn't coming from an unconfined process.
<jdstrand> that's why
<jdstrand> so, nothing to do with classic per se
 * jdstrand modifies the comment
<zyga> jdstrand: ah, now I understand
<zyga> jdstrand: thanks for researching this, I'd like to have a bug for tracking this so that the release can refer to it
<zyga> jdstrand: I can file one if you wnat
<jdstrand> I can do it
<zyga> jdstrand: thanks, please use Fixes: ... in the commit and I'll happily merge it
<zyga> jdstrand: I can smell 1.0.41 coming out soon :)
<jdstrand> zyga: does Fixes need to be in the first line or the nody?
<jdstrand> body*
<zyga> jdstrand: like signed-off-by
<mup> PR snapd#1875 opened: Add /dev/net/tun device to network-control apparmor rules <Created by cmars> <https://github.com/snapcore/snapd/pull/1875>
<zyga> jdstrand: I just use it for easy linking
<zyga> jdstrand: it's not a standard of any kind I think
<zyga> (works nicely for x-ref between github and launchpad
<mup> Bug #1621623 opened: OpenVPN needs access to /dev/net/tun, proposal to add it to network-control interface <Snappy:New> <https://launchpad.net/bugs/1621623>
<mup> PR snapd#1876 opened: cmd/snap: make "snap find" error nicer <Created by chipaca> <https://github.com/snapcore/snapd/pull/1876>
<jdstrand> zyga: ok, done
<zyga> jdstrand: merged
<jdstrand> thanks!
<mup> PR snapcraft#773 closed: parser - Handle project name and version variables <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/773>
<mup> PR snapcraft#781 opened: Workaround bzr with auth proxies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/781>
<sergiusens> ogra_ please try that ^
<mhall119> zyga: does /opt/ inside a snap map to the system's /opt/ or is it owned by the snap?
<kyrofa> mhall119, probably the core snap
<mhall119> kyrofa: is there any pre-determined path that equates to ${SNAP}?
<kyrofa> mhall119, no, though I've used the /snap/snapname/current symlink before
<mhall119> ok, I'll go with that then
<kyrofa> mhall119, beware that isn't standardized across distros
<kyrofa> I believe it's in a different place in fedora, for instance
<mhall119> kyrofa: not from the snap's perspective, zyga says the snap will see /snap/ no matter where it's actually located on the host
<kyrofa> Hmm... okay
<mup> PR snapd#1877 opened: many: maintain all snap configurations in state <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1877>
<elopio> sergiusens: if I have a tar file, but the source is in a subdirectory, I should use source-subdir, right?
<elopio> I'm having a problem trying to build erlang. The subdir contents are copied to build, but then it tries to compile from build/subdir.
<elopio> nevermind, sergiusens unping. The problem is that bootstrap exists, but it's a directory.
 * Son_Goku sighs
<Son_Goku> zyga, ping
<ogra_>  sergiusens neat !!! will try tomorrow
<qengho> How is one supposed to use $SNAP_USER_COMMON ?
<qengho> When my app starts, that directory doesn't exist. And I don't have permission to mkdir it, it seems. "mkdir: cannot create directory '/home/username/snap/snapname/common': Permission denied"
<qengho> snapd v 2.14.1+16.10
<qengho> Maybe this next version of snapd ....
<mup> PR snapcraft#782 opened: Fix gulp plugin's npm install prefix <Created by AlexandreAbreu> <https://github.com/snapcore/snapcraft/pull/782>
<mup> Bug #1621324 opened: On the all-snaps image, snappy-debug.security can't access syslog <Snappy:Confirmed> <livecd-rootfs (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621324>
<mup> Bug #1609965 changed: snapweb store is a blank page <Snappy:Fix Released> <snapweb:Fix Released> <https://launchpad.net/bugs/1609965>
<mup> Bug #1621666 opened: It is possible to install the classic snap in a classic system <classic> <Snappy:New> <https://launchpad.net/bugs/1621666>
#snappy 2016-09-09
<mup> Bug #1617509 changed: Nothing happens when the connection goes down in the middle of an install <Snappy:Invalid> <https://launchpad.net/bugs/1617509>
<slangasek> ogra_: so do you have currently-working model assertions somewhere?  The parser behavior changed in 2.14.2 and now required-snaps "must be a list of strings", which apparently precludes an empty list
<slangasek> pedronis: it seems this is your commit, 6717dd8, which breaks compatibility with what I understood to be the defined fields for the model assertion.  This seems like a pretty major regression to me, if a well-defined model assertion is now being rejected because particular fields are not yet implemented in snapd?
<mup> Bug #1577520 changed: Support setpriority <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1577520>
<mup> PR snapcraft#783 opened: Add an integration test for autotools <Created by elopio> <https://github.com/snapcore/snapcraft/pull/783>
<mup> Bug #1617231 changed: subiquity kills serial console after regular update <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1617231>
<mup> Bug #1617236 changed: console-conf falls over trying to create already existing logdir <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1617236>
<mup> PR snapcraft#784 opened: Support globbing for organize <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/784>
<mup> PR snapcraft#783 closed: Add an integration test for autotools <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/783>
<mup> Bug #1600166 changed: Snap rely on dns-masq running on 127.0.0.1 instead of /etc/resolv.conf <Snappy:Expired> <https://launchpad.net/bugs/1600166>
<mup> Bug #1621745 opened: snapd package is missing dependency on grub-common for grub-editenv <Snappy:New> <https://launchpad.net/bugs/1621745>
<dholbach> hey hey
<mup> PR snapd#1878 opened: snap: add `snap download --assertion model/16/canonical/pc-amd64` support <Created by mvo5> <https://github.com/snapcore/snapd/pull/1878>
<mup> PR snapd#1868 closed: overlord/snapstate: support revert flags <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1868>
<mvo_> pitti: good morning! is the autopkgtest environment configured differently when it comes to starting services? I am looking at the autopkgtest failure for snapd right now and it seems like the tests that start a systemd service are failing in strange ways. or is this just coincidence? is there a way to see how the test environment s confingured? so that I can try to replicate it ?
<pitti> mvo_: it's a standard cloud image with lots of fat removed: https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n215
<pitti> mvo_: but that's exactly the same setup script that autopkgtest-buildvm-ubuntu-cloud uses (with the qemu runner)
<pitti> [Kerror: cannot fetch assertion snap-revision [9gsl0jLoeOoWE-84XWtLy5Msk7w3hd-EXGsIvnGgDnH35YaSA5KIwUrvBXrEGHp_]: Get http://localhost:11028/assertions/snap-revision/9gsl0jLoeOoWE-84XWtLy5Msk7w3hd-EXGsIvnGgDnH35YaSA5KIwUrvBXrEGHp_: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
<pitti> mvo_: that sounds like a network/proxy error?
<pitti> mvo_: I can start a test manually and then give you ssh to that instance if you want
<mvo_> pitti: hm, hm, if its the same as the qemu, let me try this once more, I had successful runs in that environment, let me try it once more
<pitti> mvo_: so that "cannot fetch assertion" is unrelated/
<pitti> ?
<shuduo> ogra_: hi, i'm booting a latest image i generated by u-d-f with edge channel on dragonboard. i see console-conf is working and registered with my launchpad account as username.it's wonderful. but i can't login with my password. may i know it's expected and how i can login?
<mvo_> pitti: no, its a real error but three are a total of 4 failures so instead of waiting for adt on the servers (which may take a long time before it gets a chance to run) I will ensure its all passing locally and add some debug output too
<mup> PR snapd#1879 opened: Systemd on trusty is different <Created by vosst> <Conflict> <https://github.com/snapcore/snapd/pull/1879>
<mup> Bug #1621769 opened: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:New for mvo> <https://launchpad.net/bugs/1621769>
<mup> Bug #1575914 changed: snaps using home interface have full access to SNAP_USER_DATA of other snaps <apparmor> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1575914>
<abeato> ogra_, how can I modify rpi3 image so tmp is storage instead of tmpfs? I run out of free space when isntalling a big snap
<ogra_> shuduo, there is no local setup, you can only log in via ssh
<ogra_> abeato, i dont think thats easy beyond manually remounting before installing the snap ... file a bug please
<abeato> ogra_, will do, to which project?
<ogra_> see topic :)
<abeato> ack
<shuduo> ogra_: great. i can ssh login w/o password now. :) BTW, I see a bug is tracking console-conf do not support SSID input. then mah i know how to config WiFi?
<ogra_> shuduo, for the moment, ssh in through a USB NIC ... then set up a config in /etc7network/interfaces.d/$devicename for the wifi
<Son_Goku> ugh
<bulldog> guys i gave sudo snap install game-2048 , then i aborted it with sudo snap abort 179 ,
<Son_Goku> I hate the world right now
<bulldog> but it downloaded whole package
<Son_Goku> I should *not* be awake this early
<ogra_> Son_Goku, coffee++
<bulldog> is it normal ?? i think it should be aborting process right when user req
<bulldog> ogra_,
<bulldog> hi
<bulldog> why abort process won't stop process , i was aborting a install process and it didnt did anything before the full package download
<bulldog> are things out of control ???
<shuduo> ogra_: but /etc/network/interfaces.d/ is empty
<ogra_> shuduo, right, you need to create a config file for the device
<bulldog> ogra_, you ignoring me  :D ??
<shuduo> ogra_: one more thing, my system seems got an OS update. then afer i reboot it, snap list got error: error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<ogra_> bulldog, i have no answer for you ... better ask the channel, thats a question for the core team
<bulldog> ok bro ,
<ogra_> shuduo, that sounds like snapd did not start ...
<shuduo> ogra_: syslog is: ...Sep  9 09:13:52 localhost systemd[1]: snapd.service: Unit entered failed state.
<shuduo> Sep  9 09:13:52 localhost systemd[1]: snapd.service: Failed with result 'exit-code'.
<shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
<shuduo> Sep  9 09:13:53 localhost systemd[1]: Stopped Snappy daemon.
<shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.service: Start request repeated too quickly.
<shuduo> Sep  9 09:13:53 localhost systemd[1]: Failed to start Snappy daemon.
<shuduo> Sep  9 09:13:53 localhost systemd[1]: snapd.socket: Unit entered failed state.
<shuduo> ogra_: so i can't rollback if snapd can't start, right?
<ogra_> right
<ogra_> but you said you rolled your own image ?
<ogra_> did ouy use ubuntu-image and wheer did you get the model assertion for it ?
<shuduo> ogra_: yes, just this afternoon
<ogra_> without signed model assertion it cant work (and afaik we dont have them for normal users yet)
<shuduo> ogra_: no, i don't know ubuntu-image already ready to be used. is it ready? i still use u-d-f
<ogra_> sudo snap install ubuntu-image --devmode --edge
<ogra_> ;)
<ogra_> but you will need a model assertion, else snapd will refuse to work ,,, and we dont really have a way for users to sign their own afaik
<bulldog> where snaps are temporarily stored while they are being downloaded by snap install command ??
<bulldog> anyone ??
<shuduo> ogra_: i install ubuntu-image, but i can't find how to generate a ubuntu core image for dragonboard with its help output
<bulldog> yes i was right , packages are fully downloaded before the abort , what a serious kind of bug lol
<ogra_> sudo ubuntu-image -c $channel $model-assertion -o $image-name
<ogra_> you can build with unsigned model assertion, but then the system wont know about the basic snaps (gadget, kernel, os)
<bulldog> snap which are being downloaded by snap install command are stored in /tmp and i can see 3 63mb game-2048 packaged which snap downloaded even i passed the abort command
<ogra_> exporting UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 adds the override
<shuduo> ogra_: but i am not able to generate image as no way to get model-assertion right now, right?
<mup> Bug #1621800 opened: Cannot install snap on RPi due to small tmpfs in /tmp <Snappy:New> <https://launchpad.net/bugs/1621800>
<ogra_> shuduo, slangasek posted two to the device mailing list yesterday
<ogra_> shuduo, http://people.canonical.com/~vorlon/amd64-generic-model.assertion
<ogra_> adjust the package names ...
<shuduo> ogra_: okay. but only amd64 and pi2. customer want it for dragonboard...
<ogra_> thats why i said you need to adjust it :)
<ogra_> the image wont be much usable though ... sice snapd wont have a basic setup
<ogra_> shuduo, why do you actually need to roll your own, are the officially released images from wednesday not enough ?
<shuduo> ogra_: got it. seems i have to give an very old image to customer
<shuduo> ogra_: do you mean the image hosted on people.c.c/~mvo/all-snaps/16?
<ogra_> no, i mean the ones that were officially announced on the mailing list on wed.
<shuduo> ogra_: let me check.. which mailing list?
<ogra_> https://lists.ubuntu.com/archives/snapcraft/2016-September/001036.html
<ogra_> you really should be sunbscibed to it ...
<ogra_> and since yesterday it seems we are singeling out device stuff into https://lists.snapcraft.io/mailman/listinfo/devices
<shuduo> ogra_: thanks a lot. i did subscribe snapcraft mailing list, but be filtered automatically so no show in inbox...
<abeato> ogra_, I do not find an easy way to remount /tmp, any suggestions?
<bulldog> bug https://bugs.launchpad.net/snappy/+bug/1621805  sudo snap abort change id wont abort snap install process before downloading full package
<mup> Bug #1621805:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
<ogra_> abeato, "sudo umount /tmp" ?
<ogra_> (reboot after you installed the snap since everything that was in tmp will be gone after the umount, you dont want to keep running like that)
<liuxg> why do I get the error "error: cannot find signatures with metadata for snap "hello_1.0_amd64.snap" when installing my snap on Ubuntu desktop 16.04?
<mup> Bug #1621805 opened:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
<ogra_> liuxg, because your snap was not signed by the store ...
<ogra_> youi need to use the new --dangerous option
<abeato> ogra_, not enough, I cannot remove /tmp after that to link it to another place. Anyway, mounting it as a bigger tmpfs now
<liuxg> ogra_, I am installing it by sideload.
<ogra_> (or --force-dangerous, not sure which one is currently the default)
<ogra_> abeato, if you umount it will use the SD
<liuxg> ogra_, so this was changed again :(
<ogra_> abeato, no need to mvoe it anywhere
<ogra_> *move
<abeato> ogra_, maybe, but it complains it is read only :/
<ogra_> oh crap
<liuxg> ogra_,  thanks for your tip. --force-dangerous is the right option for it.
<ogra_> liuxg, only for a few days ... it will become --dangerous
<liuxg> ogra_, it is too bad that we change the format frequently. developers need to follow very closely. I think it is good for the command to give us the correct tips for use.
<abeato> ogra_, 'sudo mount -t tmpfs -o size=600M /tmp' will help for the moment
<ogra_> can you note that in the bug ?
<abeato> ogra_, sure
<ogra_> thx
<ogra_> not sure hwo we can solve that ...
<mup> PR snapd#1870 closed: store: ensure the payment methods method handles auth failure <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1870>
<ogra_> *how
<ogra_> we dont want to wear out the SD and we dont want all your RAM being eaten by a /tmp mount either
<ogra_> snapd probably needs to learn to not use /tmp
<ogra_> and have its own tmpdir for downloading/installing
<shuduo> ogra_: i notice the beta image is hosted in ubuntu-snappy. i thought we already abandoned snappy ... :)
<morphis> ogra_: ping
<ogra_> well, ask mvo_ why he put it there :)
<ogra_> i would have put it under ubuntu-core :)
<ogra_> morphis, i'm actively talking here... no need to ping me, just ask ;)
<morphis> ogra_: but that gives you the freedom to respond when you have time :-)
<ogra_> haha
<mvo_> ogra_, shuduo: mostly because of the symetry with 15.04 but I'm fine if we decide to put it somewhere else
<morphis> ogra_: so quick thing, which initramfs are you using for Ubuntu Core?
<ogra_> morphis, whatever update-initramfs generates when the initramfs-tools-ubuntu-core from the PPA is in place
<morphis> I see
<morphis> ogra_: you use that one in dragonboard too?
<ogra_> (we generate two ... one without any modules when ubuntu-core is built ... the other in exactly the same way during the kernel snap build (which then potentially includes some selected modules)
<ogra_> on the official images we use the initrd created by the kernel snap builds
<ogra_> (this will eventually change and we'll split the two ... modules will go into their own, shipped by the kernel, all scripts will come from the generic one)
<Gerry_> Hi I am just struggling to make my first snap using a program I wrote in Java can anybody help me
<ppisati> $ sudo snap install --force-dangerous blabla.snap
<ppisati> error: unknown flag `force-dangerous'
<ogra_> are you on snapd from proposed already ?
<ppisati> what am i missing?
<ogra_> then you just want --dangerous
<ppisati> $ snap list
<ppisati> Name         Version     Rev  Developer  Notes
<ppisati> hello-world  6.3         27   canonical  -
<ppisati> pc           16.04-0.8   9    canonical  -
<ppisati> pc-kernel    4.4.0-36-2  19   canonical  -
<ppisati> snapweb      0.20        11   canonical  -
<ppisati> ubuntu-core  16.04.1     524  canonical  -
<mup> PR snapcraft#785 opened: Check if option is url for pip <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/785>
<ogra_> right, try --dangerous
<ppisati> it worked
<ogra_> indeed :)
<ppisati> but now is treating me for a forced reboot
<ogra_> because you also gotr a new ubuntu-core i bet
<ogra_> or did you install a kernel snap ?
<ppisati> uhm nope
<ppisati> yep
<ppisati> i guess that was it
<ogra_> yeah
<ppisati> anyhow, everything works
<ogra_> yay
<ppisati> actually this morning i tried building an image following slangsek instruction on the ml
<ppisati> using ubuntu-image
<bulldog> ogra_, when you go for sleep man ???
<ppisati> and after the reboot (without being able to install mu kernel snap)
<ogra_> bulldog, not at noon :P
<ppisati> snapd didn't start anymore
<bulldog> i see you everytime here
<ppisati> i guess i'll have to try again
<ogra_> ppisati, i guess you would need an official assertion
<Gerry_> apps:  pdfHighlighter: command: pdfHighlighter  parts: pdfHighlighter0.0.7 plugin: jdk source: pdfHighlighter0.0.7.jar
<bulldog> Gerry_, use pastebin
<ogra_> Gerry_, here is a snap that uses a jar https://github.com/ogra1/jtiledownloader
<Gerry_> ok sorry thank you
<bulldog> Gerry_, https://github.com/keshavbhatt/snapcraft-gui/
<bulldog> built-in pastebin to paste your current opened snapcraft.yaml
<mup> Bug #1619721 changed: /etc/machine-id changes with every reboot <Snappy:Fix Released> <nplan (Ubuntu):Invalid> <https://launchpad.net/bugs/1619721>
<ogra_> ogra@pi3:~$ snap list ubuntu-core
<ogra_> Name         Version  Rev  Developer  Notes
<ogra_> ubuntu-core  16.04.1  526  canonical  -
<ogra_> ogra@pi3:~$ sudo snap refresh ubuntu-core --edge
<ogra_> error: cannot refresh "ubuntu-core": snap "ubuntu-core" has no updates available
<ogra_> ogra@pi3:~$
<ogra_> mvo_, ^^^ shouldnt that work ?
<ogra_> (edge has 549 for armhf)
<shuduo> mvo_: i don't mind where they are :) just curious that since marketing team asked me "don't mention snappy any more. official name is ubuntu core."
 * ogra_ doesnt mind either as long as people can download them somewhere :)
<bulldog> sergiusens, https://bugs.launchpad.net/snappy/+bug/1621805
<mup> Bug #1621805:  sudo snap abort change id wont abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
<mvo_> ogra_: should work, maybe there really are no upgrades?
<ogra_> mvo_, there is 549 in front of me :)
<mvo_> shuduo: thanks, I guess people will weight in then at some point :)
<mvo_> ogra_: when did you hit "publish"?
<mvo_> ogra_: like - how many minutes ago?
<ogra_> it was auto-published around 6am european time (daily build)
<mvo_> ogra_: oh
<ogra_> hmm, though i had to add that silly "grade: stable" stuff ... even for edge builds ... i wonder if snapd chokes on that now
<ogra_> (but that would mean we cant do updates at all for these images, since beta != stable)
<ogra_> do you know if snapd checks fior that field somehow ?
<Gerry_> Sorry for my mistakes in advance I am a beginner http://pastebin.com/FBny8NPq
<mup> PR snapd#1880 opened: asserts: use gpg --fixed-list-mode to be compatible with both gpg1 and gpg2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1880>
<ogra_> Gerry_, check the indendation in my snapcraft.yaml, make yours look the same ... yaml is very picky about that
<Gerry_> ok thank you
<mup> Bug #1621800 changed: Cannot install snap on RPi due to small tmpfs in /tmp <Snappy:Confirmed> <https://launchpad.net/bugs/1621800>
<shuduo> ogra_ mvo_ does snapweb work well as webdm did before? i flashed a snapdragon beta image and connect to network via usb-ethernet adapter. but i can't see IP:4200 show store from other computer's browser.
<ogra_> shuduo, nope, it has bugs and currently doesnt start properly
<ogra_> (but since the snap is pre-installed some auto-update will auto-fix it ;) )
<shuduo> ogra_: got it. so "snap find *" is only way to list all available snaps, right?
<ogra_> no, there is no way to list all snaps anymore
<shuduo> ogra_: even later snapweb?
<ogra_> oh, no idea how snapweb will present them
<ogra_> but snap find wont
<shuduo> ogra_: i heard of that be designed when i was heidelberg, but wonder why it be designed so. i wonder output a full list then grepping is much helpful for mass devices management
<bulldog> there is no way :D
<bulldog> i was looking for it too
<ogra_> shuduo, afaik there will be pagination or some such in the future ... but currently there is no way and i'm not sure its a GA target
<ogra_> vila, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
<ogra_> there you go :)
<ogra_> from https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz
<ogra_> err
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel
<vila> ogra_: Thanks ! Looking
<ogra_> added the link to the bug as well
<ogra_> mvo_, i filed bug 1621843 for the above
<mup> Bug #1621843: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843>
<mup> Bug #1621843 opened: no way to switch ubuntu-core to --edge on images <Snappy:New> <https://launchpad.net/bugs/1621843>
<vila> ogra_: ok, it's in the code I suspected by via a different path
<vila> ogra_: do you control the branch url used ?
<vila> ogra_: as in, can you try replacing 'lp:~snappy-dev/kernel-snap-makefile/trunk' with 'https://code.launchpad.net/~snappy-dev/kernel-snap-makefile/trunk bee' ?
<ogra_> vila, i do control the branch, but snapcraft does the pull ... i dont control anthing around this bit
<vila> ogra_: how to you specify the branch to snapcraft is what I meant
<ogra_> i'm not sure snapcraft will recognize this as bzr branch
<ogra_> vila, http://bazaar.launchpad.net/~snappy-dev/pi2-kernel-snap/trunk/view/head:/snapcraft.yaml
<ogra_> everything else is snapcraft magic
<ogra_> if i just add a https:// to the source: option i doubt snapcraft will get along
<vila> ogra_: why wouldn't it ?
<ogra_> how would it know this is a bzr tree ?
<vila> ogra_: lp hosts bzr and git branches
<ogra_> yes, i think git on lp uses a special nomenclature to tell them apart
<ogra_> in snapcraft
<ogra_> like git+ssh:// or so
<ogra_> (i never used lp git from snapcraft yet)
<vila> ogra_: can you just try while I look at snapcraft ? ;)
<qengho> source-type: bzr   ?
<ogra_> hmmm ... these aare the official kernels i wouldnt like them to explode ...
<ogra_> but i can perhaps set a test branch up
<vila> ogra_: you lost me, they do explode right now no ?
<ogra_> qengho, is that plugin independent ?
<cjwatson> right, just use source-type: git and source: https://, if it's a public branch
<ogra_> vila, no, they dont becaause we apply the patch to snapcraft
<ogra_> ok, let me try source-type and https then
<qengho> ogra_: yes, modulo plugin overrides.
<vila> cjwatson: ha, you're there great. Is using no_proxy an option in this context ?
<cjwatson> vila: it might work in this specific case but it would break attempts to fetch from a bzr branch not hosted on LP; I initially thought that was unlikely but then somebody turned up with a real-world example ...
<ogra_> hmm, how do i make it not use the PPA snapcraft without removing the package now ...
<ogra_> i guess i have to :/
 * ogra_ feels a bit uneasy ripping apart the workign build system on a friday afternoon ... 
<vila> cjwatson: no_proxy=launchpad.net will affect only launchpad branches right ?
<ogra_> ok, patched snapcraft removed, kernel snap changed
 * ogra_ waits for the auto-build to start now
<vila> cjwatson: can you give me some hints about the setup used here ? I see 'https_proxy=https://snap-proxy.launchpad.net:3128 http_proxy=http://snap-proxy.launchpad.net:3128' and 'Revoking proxy token' but I don't get what bzr is seeing exactly
<cjwatson> rather no_proxy=bazaar.launchpad.net I guess
<vila> cjwatson: yes, sorry ;-)
<cjwatson> but might be worth a try, in the snapcraft Bazaar class or so
<vila> cjwatson: but this is specific to running on the launchpad builders no ? Or do you mean you use a special version there ?
<cjwatson> vila: the environment variables are filtered in the log to avoid leaking secrets, so it's actually going to be http_proxy=http://user:password@snap-proxy.launchpad.net:3128
<vila> haaaaaa
<vila> the root cause seems to the '\n' in the Basic header...
<cjwatson> vila: we don't use a special version; I guess we could set this in launchpad-buildd, I'm not sure which is more/less evil as a workaround
<vila> in httplib.py : _is_illegal_header_value = re.compile(r'\n(?![ \t])|\r(?![ \t\n])').search
<cjwatson> vila: ah, so maybe just that the user/password combination is too long?
<vila> cjwatson, beat me to it ;-)
<vila> max supported length is 57
<vila> cjwatson: Including 'Basic :'
<cjwatson> vila: so just raw.encode('base64').strip() -> base64.b64encode(raw) would fix it then
<vila> cjwatson: yes, in the mean time, can you use shorter user/pass ? :)
<cjwatson> not easily
<cjwatson> I mean, I don't think that would be any quicker a fix :)
<vila> oh fixing is easy, getting bzr delivered and used there.... may be longer than using short user/pass is what I meant ;)
<cjwatson> they're not that huge anyway
<vila> sure, just big enough that nobody ever reported the issue ;)
<cjwatson> username is the build cookie, password is a uuid
<cjwatson> well, build cookie plus a timestamp
<vila> do you have an example ?
<cjwatson> getting bzr delivered and used there is trivial actually - ogra_ is using a patched snapcraft at the moment, would be very easy to use a patched bzr instead
<cjwatson> just drop it into the same PPA
<vila> haaaa, here we go :)
<vila> err, but that would fix only ogra's use case right ?
<ogra_> cjwatson, well, i just removed the patched snapcraft on vila's request :P ... so yeah, if i need anything patched it would be good to land it there
<cjwatson> yeah, but there are only a handful of people affected by this
<ogra_> (preferablly before EDO :) )
<cjwatson> so we can test it in ogra_'s PPA, then SRU
<cjwatson> that would be good enough
<vila> ogra_: yeah, no pressure ;-)
<ogra_> heh
<vila> ok, let me prepare something then
<cjwatson> vila: example username is SNAPBUILD-4665-1473322419
<cjwatson> vila: example password is output of uuid.uuid4().hex
<vila> cjwatson: ack, that's 6 too much (from some manual try ;)
<vila> cjwatson: uuid.uuid4().hex[:-10] ? ;-)
<vila> ok, ok, kidding, back to preparing a patch ;)
<cjwatson> changing the proxy requires a production deployment via IS, changing what bzr does can be done without IS involvement using a PPA ;-)
<cjwatson> (actually it could be changed for everyone via the snappy-dev/tools PPA)
<ogra_> we dont really use that PPA for anything... ITYM snappy-dev/image
<cjwatson> no, I meant what I said
<cjwatson> lpnet-lazr.conf:tools_source: deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu %(series)s main
<cjwatson> I told the snappy-dev team that we were doing this, ages ago :)
<ogra_> hmm, nobody told me then ...
<cjwatson> I'm pretty sure I did!
<cjwatson> Let me check logs
<cjwatson> ah, no, I talked about it with sergiusens
<ogra_> we actually need to get rid of all PPAs for the sable builds within the next weeks
<cjwatson> and sergiusens was the one who asked us to use that PPA
<ogra_> *stable
<cjwatson> this has nothing to do with image builds, it's the PPA we use for all snap builds on Launchpad
<cjwatson> 2015-09-22.log:17:53 <cjwatson> sergiusens: are you saying that Launchpad should switch to using ppa:snappy-dev/tools rather than ppa:snappy-dev/snapcraft-daily?
<cjwatson> 2015-09-22.log:18:00 <sergiusens> cjwatson, eventually yes; but all new development (daily builds even) are in ppa:snappy-dev/tools-proposed ; we are stable enough again to start using that instead if you want
<ogra_> well, then it has to do with the image builds too :)
<cjwatson> 2015-09-22.log:18:03 <sergiusens> cjwatson, don't switch then, I'll copy to daily, the final location will be ppa:snappy-dev/tools which is the same ppa we have for everything else
<ogra_> since kernel and rootfs are both snaps built on lp nowadays
<cjwatson> I'd regard ppa:snappy-dev/tools as a bit of infrastructure
<cjwatson> just like the PPA that launchpad-buildd comes from
<ogra_> well, sounds like i should perhaps use that PPA for livecd-rootfs then
<cjwatson> so I don't think you need to remove it for the purposes of Ubuntu policies, by the same argument that launchpad-buildd isn't in the Ubuntu archive
<cjwatson> that probably wouldn't work, ppa:snappy-dev/tools isn't used for livefs builds
<ogra_> yeah
<mup> PR snapd#1881 opened: cmd/snap: i18n option descriptions <Created by chipaca> <https://github.com/snapcore/snapd/pull/1881>
<ogra_> well, ... i have a snap that uses a Makefile from snapcraft.yaml that in trun installs livecd-rootfs and calls lb build
<ogra_> (and lb config etc ...)
<ogra_> so it isnt actually a live build ... it is a live build inside a snap
<ogra_> vila, and here is the failed build using https:// and source-type: bzr ...
<ogra_> though i guess thats moot now
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/4734
<vila> ogra_: yes, sorry, I asked before getting to the bottom of it, thanks for the try
<vila> ogra_: the irony is that the '\n' in the bug subject  is hidden by the right side boxes  on https://bugs.launchpad.net/bzr/+bug/1606203 here...
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:In Progress by vila> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1606203>
<vila> yeah, good mup, you show it !
<ogra_> just get an 21:9 screen and expense it !
<zyga> ogra_: I need nvidia GPU to test some stuff, do I get to expense one too? :)
<zyga> ogra_: (even low end, just modern)
<ogra_> zyga, wel,, dont you actully need multiple ?
<cjwatson> vila: thanks for spotting the intervening \n there, I dug through that traceback a few times and got the wrong end of the stick
<ogra_> to verify the breakage as well
<zyga> ogra_: I have one old one
<zyga> ogra_: and I think the problems are only with old and most recent nowadays
<ogra_> and indeed you need multiple monitors to make sure the cards actually work :)
<zyga> ogra_: the core snap is 74M big, can we make it thinner?
<ogra_> zyga, once slangasek tells me i can drop grub from the rootfs ...
<ogra_> then it will be around 50-60
<zyga> ogra_: well, you have my blessing :)
<ogra_> yeh, but i cant break kvm images now that we released them
<cjwatson> vila: and yeah, fair call on adding a bzr task, my apologies
<ogra_> so i need to wait for steves ok
<vila> cjwatson: no worries, the urllib2 tracebacks have always been a pain and I knew the proxy support was tested in the field back in the days and covered heavily by tests.  Congrats on finding the length issue in any case ;)
<ogra_> funny how grub became a pain on snappy images and uboot is so easy now
<ogra_> but we admittedly dont use it as it was initially intended (for general ubuntu)
<bulldog> #1621805
<mup> Bug #1621805: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
<bulldog> zyga,  popey , mhall119 , please check this out  https://launchpad.net/bugs/1621805
<mup> Bug #1621805: sudo snap abort <change-id> won't abort snap install process before downloading full package <snap> <snapd> <snappy> <Snappy:New> <https://launchpad.net/bugs/1621805>
<popey> bulldog: abort isn't usually used like that, you could CTRL+C the running "snap install" rather than abort it from another window
<bulldog> popey, ctrl+c wont stop the command
<popey> yes it does
<popey> I just tested it
<popey> popey@localhost:~$ sudo snap install shadowsocks
<popey> [/] Download snap "shadowsocks" (8) from channel "stable"^C
<bulldog> command is queued in snap changes , and you have to abort them
<ogra_> popey, snap and snapd operate async ...
<bulldog> ctrl+c will cancel in frontend but commnad working in backend
<popey> oh, so it does, my bad
<ogra_> if you stop snap that might not stop snapd's operation
<bulldog> yeah
<bulldog> so its a bug.
<ogra_> or a design decision :)
<popey> yeah
<ogra_> you need input from someone from the core team
<bulldog> idk why once will support that design
<bulldog> lol
<ogra_> which all got the bug by mail, so just be patient
<bulldog> hmm
<ogra_> (it usually doesnt really help to ping random people about a bug unless you know that the person you ping will actually work on it)
<bulldog> popey,  see /tmp the snap file with download progress whould be there
<popey> bulldog: yes, i see
<popey> (this doesn't feel urgent to me)
<popey> but it's filed, so we'll let the devs deal with it
<bulldog> ogra_, i was trying to confirm the bug actually
<bulldog> popey, if you think its a bug please put a affects you in the bug page
<bulldog> i encountered with this when i was implementing install from store feature in snapcraft-gui ,
<ahasenack> how is that snapd postinst bug, can we deploy xenial images again?
<ogra_> "that snapd postinst bug" ...
<ogra_> can you be more specific ?
 * ogra_ hasnt had any snapd postinst bug here 
<ahasenack> really?
<ogra_> (on two xenial machines)
 * ahasenack fetches it
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
<mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <oil> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1621336>
<ogra_> oh, cloud
<ogra_> you should just have mentioned that and i'd had kept quiet ;)
<ahasenack> juju deployed workloads essentially
<bulldog> is there a way to find the size of snap package user wana install on system before hitting up he install command ???
<ahasenack> looks still unassigned
<ogra_> bulldog, there might be something in tehstore api
<bulldog> ogra_,  i mean is there a command in snap yet
<bulldog> ??
<ogra_> nah, you are expected to use the store api for such stuff i think
<bulldog> find should do that ,
<bulldog> like snap find vlc , should also output snap package size .
<ogra_> nah, it should only show if the package exists and the short description
<ogra_> you likely mean an equivalent to apt-cache show
<ogra_> but i doubt that will happen any time soon
<ogra_> (simply because there is a lot other stuff on the plate before)
<zbenjamin> do desktop files go into <snap>/setup/gui or <snap>/gui ?
<zbenjamin> ogra_: ^ i'm sure you know :D
<sergiusens> cjwatson fwiw, the PPA is not needed for snapcraft anymore. I recall that conversation though
<cjwatson> sergiusens: yeah, it's not needed right now but the flexibility is useful
<ogra_> zbenjamin, in your branch they go into $snap/setup/gui iirc
<zbenjamin> ogra_: ok, and in the snap itself?
<sergiusens> So thanks to vila I am killing the snapcraft hack for proxies.
<vila> sergiusens: yeah, that sounds better, thank
<ogra_> sergiusens, well, thanks anyway for taking it into account ...
<vila> sergiusens: so the issue is a real (but uncommon) one: long user/pass generated in the lp setup
<vila> ogra_, cjwatson : minimal patch available at ... ha, lp timing out :-}
<jdstrand> roadmr: hi! at your convenience (ie, not urgent), can you pull r740 of the review tools?
<ogra_> lol
<sergiusens> Lol
<vila> https://code.launchpad.net/~vila/bzr/1606203-long-auth/+merge/305328
<roadmr> jdstrand: good morning! absolutely, I'll put it in the pipeline (but not smoke it)
<jdstrand> hehe, thanks! :)
<ogra_> vila, still "updating diff" ... i guess it does that via DHL
<cjwatson> vila: wretched branch scanner.  could you force a rescan?
<cjwatson> vila: http://people.canonical.com/~cjwatson/lp-rescan-branch -> "lp-rescan-branch lp:~vila/bzr/1606203-long-auth"
<vila> cjwatson: yeah, I have that one installed locally from your last reference ;)
<vila> cjwatson: branch.unscan(rescan=True) -> [u'v.ladeuil+lp@free.fr-20160909125940-4bhgpwoenpjal97c', None] Is the None expected there ?
<vila> the revid is the right one, ran the script thrice already
<vila> hehe, here it goes ;)
<ogra_> geez ... how big is bzr ? ... bzr branch runs since 5min already
<zyga> ogra_: snap install it ;0
<ogra_> :P
<cjwatson> vila: yes, the None is the previous scanned ID
<cjwatson>         return (self.last_mirrored_id, old_scanned_id)
<vila> cjwatson, ogra_ : the MP is updated now
<cjwatson> yup, second run is normally enough
<ogra_> yeah ... branching here since a while
<ogra_> oh, bah ... no debian dir ?
<ogra_> how do i build a source deb to push to the PPA ?
<vila> right, was wondering, that's the upstream branch, what's the process ...yeah that ;)
<cjwatson> just grab the source package from the archive
<ogra_> funnily the upstream branch has an apport dir ...
<ogra_> could as well have a debian dir then
<cjwatson> you'd want that anyway in case the archive happens to have some extra patches
<ogra_> yeah ... resorting to the archive package
<vila> ogra_: soft dependency on apport, hysterical
<ogra_> vila, sure, but apport is ubuntu specific ... as is the debian dir
<ogra_> so it could have both .... seems inconsequent to only have apport there
<vila> ogra_: agreed
<vila> ogra_: but we don't rewrite history ;-)
<ogra_> heh
<ogra_> no, we repeat it :P
 * ogra_ refrains from more political comments on IRC today :)
<vila> :-X
<ogra_> and indeed colin is right ... there is a bunch of patches
<vila> ogra_: reduced when releasing 2.7, will check in a min but I doubt any of them conflict
<pitti> mvo_: the snapd.boot-ok bug, is that on someone's high prio radar?
<pitti> smoser: ^
<mvo_> pitti: what was the bugnumber again?
<smoser> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
<mup> Bug #1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades <oil> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1621336>
<vila> ogra_: yeah, nothing should conflict
<pitti> ... that
<vila> pitti: o/
<pitti> people are coming up with increasingly embarrassing workarounds :)
<pitti> Ã§a va vila
<smoser>   - "echo snapd hold | dpkg --set-selections"
<ogra_> oh how i hate packages that need all their build-deps installed to roll a source pakcage ... grrr
<vila> pitti: something like that yes ;-)
<vila> pitti: trying to help ogra_ but not sure I'm succeeding ;-)
<ogra_> vila, well, package uploaded to the PPA ... lets see
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> i'll trigger a kernel snap once it fully landed
<vila> ogra_: ack, sorry for the hassle :-}
<ogra_> vila, less hassle than having to patch snapcraft every week
<ogra_> :)
<ogra_> and lots better than having to carry a hack in snapcraft for sergiusens
<mup> PR snapcraft#781 closed: Workaround bzr with auth proxies <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/781>
<vila> ?!? how did mup do that ? 8-)
<ogra_> vila, niemeyer swings his wand and it magically does it
<sergiusens> It was me
<vila> sergiusens: well done, you got me there ;-)
<ralsina> Hi, anyone knows what is "error: cannot find signatures with metadata for snap "nikola_7.8.0_amd64.snap"
<ralsina> " when trying to install a snap I just built?
<vila> sergiusens: just a heads-up, SRU'ing bzr will take a while, ogra_ is using a shortcut by building it in its own ppa
<ogra_> ralsina, --force-dangerous (or if you are already on the snapd version from xenial-proposed, just --dangerous)
<ralsina> uo--dangerous it is, thanks!
<ralsina> ogra_: ^
<vila> cjwatson: shortest path for SRU is via debian right ?
<ogra_> for SRU ? i doubt that
<ogra_> xenial-proposed ... debian is good to get it into yakkety (which you need for the SRU)
<vila> hmm, last one came from there IIRC (or I'm confused which is not hard in this area ;)
<ogra_> last one came from doko
<vila> ogra_: right, so next step on the SRU road is debian, correct ?
<ogra_> into xenial-proposed apparently
<ogra_> yes, debian for yakkety and xenial-proposed for xenial
<vila> ogra_: from debian IIRC (paramiko breaking compat)
<ogra_> well, the changelog doesnt look like it came via debian into xenial-proposed
<cjwatson> vila: no, shortest path for SRU is to get it into yakkety first (doesn't have to be via Debian, depends what's reasonable), then cherry-pick to xenial-proposed
<vila> hmm, weird, pretty sure the original fix was by jelmer
<cjwatson> yeah, it's in sync at the moment so might as well put it in Debian
 * vila nods
<vila> faster than releasing 2.7.1
<ogra_> my PPA package was actually against xenial-updates ... https://launchpadlibrarian.net/283497088/bzr_2.7.0-2ubuntu1_2.7.0-2ubuntu2+ppa1.diff.gz ... iis clearly from doko
 * vila mumbles pqm... lucid chroot.. grumble
<ogra_> (see how i got both, dokos and my patch)
<cjwatson> vila: do you have direct upload access or do you need a sponsor?  I see you're already in Uploaders
<vila> cjwatson: very freshly in uploaders, still need sponsor (and even guidance for that matter ;-/)
<cjwatson> send me a debdiff and I'll help
<cjwatson> i.e. debdiff bzr_2.7.0+bzr6619-1.dsc bzr_2.7.0+bzr6619-2.dsc
<ogra_> for xenial-proposed you can just fish debian/patches/20_1606203-long-auth.patch out of my PPA package
<ogra_> (and add a line for it to debian/patches/series)
<vila> cjwatson, ogra_ : thanks, shuffling through my notes to find how I did it last time
<bulldog> bye
<mup> PR snapd#1851 closed: interfaces: serial-port use udevUsbDeviceSnippet <Created by jocave> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1851>
<zyga> jdstrand: hey, a small detour
<zyga> jdstrand: I'd like to land this small change https://github.com/snapcore/snap-confine/pull/129
<mup> PR snap-confine#129: Improve detection of nvidia driver on Ubuntu <Created by zyga> <https://github.com/snapcore/snap-confine/pull/129>
<tenaciousmv> hi, i had a question about the node plugin. Is there support for installs from npm-shrinkwrap.json and deps from github (vs npm)?
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/1882
<mup> PR snapd#1882: interfaces/builtin: tweak opengl interface <Created by zyga> <https://github.com/snapcore/snapd/pull/1882>
<mup> PR snapd#1882 opened: interfaces/builtin: tweak opengl interface <Created by zyga> <https://github.com/snapcore/snapd/pull/1882>
<jdstrand> zyga: , ack +1
<ogra_> oh come on ...
 * ogra_ notes the bzr upload in the PPA is still not published 
<mup> PR snapcraft#786 opened: Add `snapcraft list-keys` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/786>
 * ogra_ slowly grows more gray while hair waiting for the publisher ... 
<sergiusens> tenaciousmv not anything explicitly supported. If it is not invasive, mind adding support for it?
<tenaciousmv> looking at the code, it seems to just call npm install, so it should be supported out of the box
<tenaciousmv> but i was hitting some issues
<tenaciousmv> i'll dig a bit
<zyga> jdstrand: thank you
<mup> PR snapd#1882 closed: interfaces/builtin: tweak opengl interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1882>
<vila> cjwatson: sorry for delay something like https://pastebin.canonical.com/165172/ ?
<cjwatson> vila: seems OK but maybe add (LP: #1606203) to the changelog?  (I can do that for you if you agree)
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:In Progress by vila> <Snapcraft:Invalid by sergiusens> <https://launchpad.net/bugs/1606203>
<vila> cjwatson: yes please !
<cjwatson> ok, will test-build locally and upload if it works
<cjwatson> vila: oh, I'm also deleting a spurious "." line from the patch
<vila> cjwatson: thanks !
<sergiusens> SamYaple_ hey there, did you have a change to look at the `--no-compile` branch comment we talked about yesterday?
<vila> cjwatson: ha, I thought that was necessary when the description was longer than one line... not sure where I got that from ;)
<sergiusens> vila you might be mixing it with debian/copyright
<ogra_> rather debian/control
<ogra_> (there you add a dot to separate two paragraphs)
<ogra_> oh come one publisher ... its more than 1.5h
<vila> I should just write one line descriptions and be done ;)
<vila> ogra_: isn't the publisher just after the hour (a few mins) ?
<ogra_> well, it seems to go slower recently
<ogra_> especially for PPA builds
<mup> PR snapd#1883 opened: cmd/snap,image: teach snap download to download also assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1883>
<SamYaple_> sergiusens: i have not run it with the environment variable you suggested yet, but that shouldn't have a bearing on the patch. we still don't want to be compiling anyway (for speed purposes if nothing else)
<mup> PR snapd#1884 opened: tests: get the gadget name from snap list <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1884>
<zyga> jdstrand: I'd like to merge https://github.com/snapcore/snap-confine/pull/129
<mup> PR snap-confine#129: Improve detection of nvidia driver on Ubuntu <Created by zyga> <https://github.com/snapcore/snap-confine/pull/129>
<mup> PR snapd#1885 opened: tests: add upower-observe spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1885>
<akash> hello all i just installed ubuntu core on a nuc and saw per documentation that the command is 'snappy' not snap? is that correct?
<kyrofa> akash, it depends on which version of ubuntu you're using
<kyrofa> akash, 15.04 or 16
<akash> okay im on 15.04 it looks like
<kyrofa> akash, then yes, it's snappy
<akash> should i be on 16 to be consistent with docs? - for example im not able to execute snapcraft at command for example
<akash> ive been referring to this doc : https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<akash> and for example on 15.04 those commands for snap or snapcraft dont work
<kyrofa> akash, that's up to you. 16 is still in development, but it's definitely newer. You can still use snapcraft to build snaps for 15.04, but you need snapcraft 1.x for that which is only available on trusty through wily
<kyrofa> If you're using xenial, might as well use 16 so you can test your snaps locally
<slangasek> ogra_: you can drop grub from the rootfs any time the snappy team is happy that you no longer need u-d-f compatibility :)
<ogra_> well, there are instructions for model assertion creation upcoming i heard ... and all supported images can be built with u-image now ...
<ogra_> i'll probably wait til the instructions get promoted though ...
<ogra_> slangasek, dont we need anything from it for fwupdate ?
<slangasek> yes, for my part, I know of no blockers for dropping grub from the rootfs
<ogra_> ok
<ogra_> perfect
<slangasek> fwupdate> should not need to talk to grub at all, it only talks to uefi
<ogra_> ok
<ogra_> i wasnt sure
<slangasek> fwupdate definitely doesn't care what bootloader your os uses :)
<ogra_> cool
<ogra_> elopio, i'll roll a linux-generic-armhf kernel snap on the weekend ... that should be a good base for a beaglebone img
<ogra_> (i have seen your mail, even though i didnt answer yet :) )
<ogra_> finally !! bzr published ...
 * ogra_ pokes a kernel build 
<balloons> zyga, where did we land on the SRU for snap-confine/
<ogra_> vila, cjwatson FYI ... https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/4746 ... bzr fix works fine
<vila> ogra_: Yeeees ! Thanks for the feedback and sorry for the hassle (noob error, according to https://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/2363.4.5 almost 10 years ago, never reported before)
<ogra_> hah
<vila> The guy probably haven't finished reading RFC 2616 by the time... not to mention python 101 ;)
<ogra_> well, my python wouldnt be much better, so no worries :)
<ogra_> vila, and also ... who would be insane enough to create passwords with more than 5 chars anyway !
<ogra_> :)
<vila> ogra_: yeah, says a lot about what happened in the last 10 years :-) :--} :-D
<ogra_> definitely :)
<qengho> elopio: Will you please try chrome-test with  --disable-gpu  and tell me if it's better?
<mup> PR snapcraft#779 closed: Do not compile pyc files when installing with pip <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/779>
<qengho> jdstrand: Too bad "snap remove" doesn't mv ~/snap/pkgname to ~/.Trash/snap/ .
<jdstrand> hey, yeah-- it totally could
<jdstrand> qengho: I mean I had to jump through some major hoops to ensure I didn't lose my sideloaded snap's data
<ogra_> eeek !
<ogra_> qengho, if ever then not ~/.Trash please :)
<akash> so i have gotten a little further per 15.04 on ubuntu core, and wondering how to get snapcraft actually installed. any ideas?
<ogra_> (i.e. dont use a hidden dir so that people wonder why their disk is full with all snaps removed :P )
<qengho> ogra_: of course I mean whatever XDG defines these days for trash.
<akash> there is no apt-get on core, and hence my question, and all commands as mentioned before are snappy <command>
<ogra_> akash, first of all, you really want 16.04
<akash> ogra_ okay i was told snapcraft only works from trusty-wily is that correct?
<ogra_> no it isnt
<ogra_> for 16.04 core (which you should definitely use) you need the 16.04 snapcraft
<ogra_> for pre-16.04 ubuntu-core the 16.04 snapcraft wornt work though
<akash> ahhh okay very helpful
<akash> let me give that a shot
<ogra_> ah, i just saw the backlog ...
<ogra_> we dotn have 16.04 NUC images, but we do have 16.04 x86 images i would expect to work http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ ...
<ogra_> (you have to try)
<akash> okay...and per the documentation - https://developer.ubuntu.com/en/snappy/start/intel-nuc/ it looks like it might be outdated
<akash> if a person goes through that...they will undoubtedly hit same issues. i can file a bug to update docs
<ogra_> well, 16.04 isnnt released yet
<akash> as those commands simply dont work for 15.04
<akash> on the NUC
<ogra_> once it is the docs will point to 16.0 4
<akash> okay sounds good. - currently pointer is here - http://snapcraft.io/docs/core/usage?utm_source=developer.ubuntu.com&utm_medium=devportal&utm_term=snaps%20snapcraft%20tour&utm_content=redirect&utm_campaign=duc_snappers
<mup> PR snapd#1886 opened: tests: fix spread tests on yakkety <Created by mvo5> <https://github.com/snapcore/snapd/pull/1886>
<mup> PR snapd#1883 closed: cmd/snap,image: teach snap download to download also assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1883>
<mup> PR snapcraft#786 closed: Add `snapcraft list-keys` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/786>
<mup> PR snapcraft#782 closed: Fix gulp plugin's npm install prefix <Created by AlexandreAbreu> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/782>
<mup> PR snapcraft#784 closed: Support globbing for organize <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/784>
<jdstrand> zyga: hey, fyi, adding 'unsafe' to the policy is still not in a PR. did you queue that up somewhere?
<mup> PR snapcraft#787 opened: Release changelog for 2.17 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/787>
<cjwatson> vila: bzr tests failed when I tried to test-build that, I'm afraid - running it again so that it actually saves the build log and then I'll send it to you
<slangasek> ogra_: is http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ubuntu-core-16-pi3.img.xz corrupted?  I can't unxz it
<slangasek> unxz: ubuntu-core-16-pi3.img.xz: Unexpected end of input
<mup> PR snapd#1887 opened: cmd/snap: tweak help of 'snap download' <Created by pedronis> <https://github.com/snapcore/snapd/pull/1887>
<akash> using snapcraft and when issuing a snapcraft stage im getting this message: The 'pull' step of 'glue' is out of date. Please clean that part's 'pull' step in order to rebuild
<akash> whats the proper resolution steps to this ?
<akash> sorted it out...syntax issue
<cjwatson> vila: moving my ~/.bazaar/ aside helped a little (some of the test suite isn't properly isolated and doesn't like create_signatures = always in there), but I still get http://people.canonical.com/~cjwatson/tmp/bzr_2.7.0+bzr6619-2_amd64.build
<cjwatson> (too large for pastebin, apparently)
<vila> cjwatson: sry, was out. Looking. Can you file a bug for that isolation issue ? Shouldn't be hard to fix.
<vila> cjwatson: doh, the test has a comment: # Diff returns '2' on Binary files., your failure suggests diff returned 1 ?
<cjwatson> vila: added a note to my to-do list to file that, can't do it now.  It does indeed appear to return 1 but I can't immediately reproduce it in the 30 seconds I have available to try diff by hand.  Maybe an environment issue of some kind, I don't know, see if you can reproduce it in a sid sbuild environment?
<vila> I didn't earlier :-/
<cjwatson> vila: oh, diffutils 1:3.5-1 changelog
<akash> hoping someone can help out with a novice question - once a snap is created how does one test it? i wrote one in snapcraft and now id like to see if it works or not
<cjwatson>   * Exit status of diff for binary files that differ is now 1, not 2,
<cjwatson>     as mandated by POSIX. Closes: #737180.
<mup> Bug #737180: gnome-panel crashed with SIGSEGV in _panel_applet_frame_update_flags() <apport-crash> <i386> <natty> <gnome-panel (Ubuntu):Invalid> <https://launchpad.net/bugs/737180>
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737180
<cjwatson> that's pretty clear
<vila> cjwatson: doh
<vila> cjwatson: and this remain dormant between 2014-02 and 2014-08-31.... amazing
<vila> cjwatson: the test doesn't cover any code relying on that behavior.
<vila> err, typo above, dormant  2014-02 and 201*6*-08-31 i.e. 10 days ago.... amazing
<cjwatson> vila: OK, https://bugs.launchpad.net/bzr/+bug/1622039 and https://bugs.launchpad.net/bzr/+bug/1622044
<mup> Bug #1622039: Fails to build with diffutils 3.5 <Bazaar:New> <https://launchpad.net/bugs/1622039>
<mup> Bug #1622044: create_signature=always causes test suite failure <Bazaar:New> <https://launchpad.net/bugs/1622044>
<vila> cjwatson: excellent, thanks ! I need to sleep so won't followup right now. But as soon as I can.
#snappy 2016-09-10
<mup> PR snapcraft#788 opened: support npm install from npm-shrinkwrap.json in nodejs plugin <Created by mvayngrib> <https://github.com/snapcore/snapcraft/pull/788>
<bulldog> hi all
<bulldog> how a snap finds system tray icon ??
<bulldog> like in deb packaging i use to put a icon.xpm in certain location and gnome use to get the icon from there and set for app systray
<bulldog> everyone enjoying weekend :D ?
<bulldog> mhall119, hi :)
<tsimonq2> bulldog: not many people are online on weekends
<bulldog> guys how to copy directory with content with dump plugin help plz i did  directory/*: desktination but it returns with error directory/* no such file or dir
<bulldog> tsimonq2,  mm
<tsimonq2> !patience | bulldog
<ubottu> bulldog: 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/
<bulldog> haha
<tsimonq2> or you can email snapcraft@lists.snapcraft.io
<tsimonq2> you'll get more eyes
<bulldog> okay ty
<tsimonq2> no problem bulldog :)
<bulldog> tsimonq2, am working on https://github.com/keshavbhatt/snapcraft-gui
<tsimonq2> OH hi :)
<tsimonq2> I'm Simon from the Gitter channel
<bulldog> oh
<bulldog> :)
<bulldog> did you tried the tool yet , now its very easy to get nightly build from launchpad ppa . i set it all there to build my code from github branch
<tsimonq2> I'm running Yakkety
<tsimonq2> bulldog: https://github.com/keshavbhatt/snapcraft-gui/pull/2
<mup> PR keshavbhatt/snapcraft-gui#2: Change apt-get to apt <Created by tsimonq2> <https://github.com/keshavbhatt/snapcraft-gui/pull/2>
<bulldog> wow , i will :)
<tsimonq2> bulldog: build passes :)
<bulldog> haha ty
<bulldog> merged
<tsimonq2> bulldog: https://github.com/keshavbhatt/snapcraft-gui/pull/3
<mup> PR keshavbhatt/snapcraft-gui#3: Change apt-get to apt <Created by tsimonq2> <https://github.com/keshavbhatt/snapcraft-gui/pull/3>
<bulldog> ty , merged
<tsimonq2> bulldog: I'm also submitting a few issues as well
<bulldog> okay i will look into them
<tsimonq2> bulldog: do you know how to fix GitHub issues when you commit?
<bulldog> nope :P
<tsimonq2> bulldog: https://help.github.com/articles/closing-issues-via-commit-messages/
<bulldog> tsimonq2, there was an issue raised by a user about installation methods i closed it by providing installation method :)
<bulldog> ty , am checking it out
<tsimonq2> ok :)
<bulldog> oh i see ,
<bulldog> thanks man :)
<tsimonq2> bulldog: https://github.com/keshavbhatt/snapcraft-gui/issues/4
<bulldog> wait
<bulldog> tsimonq2, did you read the code of the current snapcraft-gui ?? this is in c++ and qt , am not good in pyqt :P
<tsimonq2> bulldog: I said it *may* need to happen
<bulldog> i will contact them if they will able to accept it as c++ tool
<tsimonq2> bulldog: regardless, they need unit tests
<tsimonq2> ok
<tsimonq2> bulldog: otherwise, do what I suggested in the issue :)
<bulldog> tsimonq2, i can make it work like snapcraft , and it is currently working well am able to snap out some apps with it .
<tsimonq2> great :)
<tsimonq2> bulldog: you know you can use Git with Launchpad and just mirror your code over there right?
<tsimonq2> or is it a recipe?
<bulldog> tsimonq2, you suggest me what should i do , you try the tool first , does it meet the standards , only way to do this is testing , more people who will test and report bugs will help me make it better
<bulldog> yeah tsimonq2  i did this
<bulldog> tsimonq2, i connected my launchpad project ,to get code from github .
<bulldog> i need help with lp , how can i fork branches from the web version of lp if you know please help. i want create separate branches there to make it easy fix specific stuffs
<tsimonq2> bulldog: where is the current code?
<bulldog> lp branch ?
<bulldog> wait
<bulldog> tsimonq2, https://code.launchpad.net/~keshavnrj/snpacraft-gui/snpacraft-gui
<bulldog> tsimonq2, this one is sync with github branch https://code.launchpad.net/~keshavnrj/snpacraft-gui/master
<tsimonq2> bulldog: that's in Bazaar...
<tsimonq2> I have an idea
<bulldog> hmm
<bulldog> tsimonq2, tell
<tsimonq2> first, rename https://launchpad.net/snpacraft-gui to snapcraft-gui if possible
<tsimonq2> then, create a Git repo
<tsimonq2> let me know when that's done
<bulldog> :D
<bulldog> :P that was done by mistake
<bulldog> tsimonq2, i think it wont change now
<tsimonq2> well make sure of that 100%
<bulldog> tsimonq2, i have to do everything from scratch i guess
<bulldog> name can be changes but url are the issues
<tsimonq2> I see
<bulldog> tsimonq2, i have a question , you seen structure of my github branch , now when link lp with github branch it fork as it is , now when i build with the recipe here on lp it cant look into source which  is inside "snapcraft-qt" dir
<bulldog> so i have separate branch on lp which is used to build tha deb package ,
<tsimonq2> it should be able to do that...
<bulldog> tsimonq2, is there something we can put in build recipe to point the builder to snapcraft-qt dir??
<tsimonq2> bulldog: maybe ask in #launchpad
<bulldog> okay ty
<tsimonq2> bulldog: https://github.com/keshavbhatt/snapcraft-gui/issues
<bulldog> omg , there are lots of i can see now :P
<bulldog> hang on am let me take them one  by one
<tsimonq2> ok
<tsimonq2> lol
<tsimonq2> bulldog: you wanted feedback? :D
<bulldog> yeah i need :P
<bulldog> on issues ?? if you think they are necessary then yes
<tsimonq2> yes there's a good amount of problems here ;)
<bulldog> tsimonq2, keep up the good work :) thanks for contributing to project , you will be counted as contributor
<tsimonq2> no problem :)
<tsimonq2> I had surgery yesterday, so I need to nap
<bulldog> tsimonq2, okay good bro :)
<mup> PR snapcraft#789 opened: Some plugins fixes <Created by ehbello> <https://github.com/snapcore/snapcraft/pull/789>
<tsimonq2> bulldog: https://github.com/keshavbhatt/snapcraft-gui/issues/10
<tsimonq2> bulldog: urgent
<bulldog> tsimonq2, wait
<bulldog> am adding some stuffs in about dialog :)
<bulldog> :D
<tsimonq2> ok
<bulldog> WTFPL should be there ??
<bulldog> :D
<bulldog> tsimonq2, which LICENSE should we choose man ?
<tsimonq2> bulldog: I'd recommend GPL-2
<bulldog> okay ty
<bulldog> can you make a commit there ?
<tsimonq2> I'm in bed, sorry :(
<bulldog> okay ,
<bulldog> take rest and get well soon bro,
<tsimonq2> thanks :)
<tsimonq2> bulldog: you have more issues to look at when you have a min
<bulldog> yeah seems like my life going to be full of issues :D
<bulldog> well i will fix each of them , thanks for your valuable time :)
<tsimonq2> no problem :)
<bulldog> am adding a contribution widget to about dialog ,
<bulldog> where file will contributions details will be loaded .
<tsimonq2> well I meant on GitHub
<bulldog> you are probably be going in the list :P
<bulldog> i got ya
<tsimonq2> as an .MD file
<bulldog> hmm i will
<tsimonq2> s/MD/md/
<bulldog> okay , will be back soon hmm ,
<tsimonq2> ok o/
<mup> PR snapcraft#789 closed: Some plugins fixes <Created by ehbello> <Closed by ehbello> <https://github.com/snapcore/snapcraft/pull/789>
<mup> PR snapcraft#790 opened: Reduces download time of `git clone` fetching just a single branch <Created by ehbello> <https://github.com/snapcore/snapcraft/pull/790>
<mup> PR snapcraft#791 opened: Crosscompilation dump copy plugins <Created by ehbello> <https://github.com/snapcore/snapcraft/pull/791>
<mup> PR snapcraft#792 opened: Fix `git clone` when transport is http and it does not support --depth <Created by ehbello> <https://github.com/snapcore/snapcraft/pull/792>
<bulldog> hola
<mup> PR snapcraft#787 closed: Release changelog for 2.17 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/787>
<bulldog> sergiusens, hi
#snappy 2016-09-11
<mup> Bug #1622336 opened: [DOC] snappy on KVM recommends cmd line that warns about RAW devices <Snappy:New> <https://launchpad.net/bugs/1622336>
<mup> Bug #1622342 opened: DOC: Snappy kvm line should have specifier for memory size <Snappy:New> <https://launchpad.net/bugs/1622342>
<akash> hello i have a snapcraft project that requires python3 and pip3 it seems to build fine, but when executing the binary it complains  about finding pip._vendor.pkg_resources.
<akash> it appears its using the python3.5 libs to try and accomplish this
<SamYaple_> akash: weve been significantly changing the python plugin around, which version of it are you using?
<SamYaple_> sergiusens: im reworking the python plugin test suites fyi
<SamYaple_> sergiusens: given my current work load, i think itll be done and passing all the tests by this coming friday
#snappy 2017-09-04
<mup> PR snapcraft#1494 closed: Parameter forwarding for java object was blocked when using wrapper script <Created by fmanea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1494>
<mup> PR snapcraft#1528 opened: recording: record the machine information collected by uname <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1528>
<mup> PR snapcraft#1529 opened: recording: record the packages installed in the machine <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1529>
<zyga-suse> good morning
 * zyga-suse will start at 9:30 because of the 1st day at school and some coordination/assistance required
<zyga-suse> see you then
<mup> PR snapd#3837 closed: overlord/snapstate: rename HasCurrent to IsInstalled, remove superfluous/misleading check from All <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3837>
<mup> PR snapd#3556 closed: client,daemon,snap,store: add license field <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3556>
<zyga-ubuntu> mvo: hello
<mvo> hey zyga-ubuntu
<zyga-ubuntu> mvo: today is the 1st day of school for us, how about your kids?
<mvo> zyga-ubuntu: school started  2 weeks ago here
<mvo> zyga-ubuntu: how was getting up ?
<zyga-ubuntu> mvo: woah, two weeks? that's brutal :)
<zyga-ubuntu> mvo: so no august holidays?
<zyga-ubuntu> mvo: it was all right, with the exception of my son we all woke up at 6am
<mvo> zyga-ubuntu: holidays started early here
<mvo> zyga-ubuntu: nice!
<zyga-ubuntu> mvo: we introduced new rules to make sure nothing flashly/briht/(tv/computer) is on past 21:00
<mvo> zyga-ubuntu: the only thing I hate is the getting-up early
<mvo> zyga-ubuntu: that sounds reasonable
<zyga-ubuntu> mvo: I walked them to school today but I expect them to walk by themselves soon, it's very close from our home
<zyga-ubuntu> mvo: and I'm looking forward to working at 6:30 soon
<zyga-ubuntu> mvo: trivial comments from gustavo on https://github.com/snapcore/snapd/pull/3625
<mup> PR #3625: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625>
<mvo> zyga-ubuntu: yeah, working on them now and then I will merge
<mvo> zyga-ubuntu: there are some easy ones in the queue that just need a second review
<mvo> zyga-ubuntu: e.g. 3844
<zyga-ubuntu> mvo: I'll have a look, going bottom up
<mvo> zyga-ubuntu: please leave some of the scary looking out, I have not branched 2.28 yet
<mvo> zyga-ubuntu: but want to do in a little bit, so please not the debian/ dir changes
<mvo> zyga-ubuntu: and also not 3727 (that needs a second review anyway)
<zyga-ubuntu> mvo: noted
<zyga-ubuntu> ok, one more and I'm going to pick them up
<mvo> zyga-ubuntu: pick which one up?
<zyga-ubuntu> mvo: my kids :)
<zyga-ubuntu> mvo: I'm reading https://github.com/snapcore/snapd/pull/3777/files
<mup> PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
<zyga-ubuntu> ok, I'll read the rest later, going to school, ttyl
<mvo> zyga-ubuntu: bye
<mvo> pstolowski: good morning!
<pstolowski> mvo, morning!
<mvo> pstolowski: look slike 3642 just needs one tiny change and its good to go :) if you look at this now it will most likely be part of 2.28
<pstolowski> mvo, indeed, i'll look at it shortly, thanks!
<mvo> ta
<mup> PR snapd#3795 closed: daemon: let client decide whether to allow interactive auth via polkit <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3795>
<Chipaca> g'morning, all
<mimag1> Good morning
<mimag1> I've been pulling my beard for a long time now and googled a lot but can't get my python snap to work. What is the best way to install a locally fetched python package?
<Chipaca> mimag1: I think the source of a python part can be a directory
<Chipaca> e.g. source: .
<mimag1> I have that and in that directory I have the package and an setup.py
<mimag1> plugin: python and plugin-version: python3
<Chipaca> mimag1: and what doesn't work?
<mimag1> "Could not find a version that satisfies the requirement pytiip (from versions: )"
<mimag1> No matching distribution found for pytiip
<Chipaca> mimag1: can you share your whole yaml so i can reproduce this?
<Chipaca> mvo: o/  i know the atomic code as it stands needs tests (and docs!); i mention in my follow-up comments that the 2nd commit is a bigger departure from what was there and thus does need 'em
<Chipaca> mvo: but, what do you think of that approach?
<mup> PR snapd#3842 closed: store: have an ad-hoc method on cfg to get its list of uris for tests <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3842>
<mup> PR snapd#3844 closed: overlord/snapstate: SetRootDir from SetUpTest, not in just some tests <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3844>
<zyga-ubuntu> re, back from school, now peace and quiet for the rest of the day
<mimag1> parts:
<mimag1>   pytiip:     source: repos/pytiip     plugin: python     python-version: python3
<mvo> Chipaca: I like the approach, slightly silly question, what is the difference between commit and close? I mean, could commit just become a close method? or do we need both?
<Chipaca> mvo: say aw is an atomicwriter
<Chipaca> mvo: and aw.Write() fails, for whatever reason
<ogra_> popey, same cpu and wlan device, might even work with the nanopi-air image
<Chipaca> mvo: so now you need to close it and remove the file, without committing
<Chipaca> mvo: if close is commit, that's harder
<mvo> Chipaca: aha, yes, good point. will things work if you do "aw.Write(); aw.Commit(); aw.Write(); aw.Commit()"?
<Chipaca> mvo: no, at least as written, Commit imples Close
<zyga-ubuntu> mvo, Chipaca: maybe commit and rollback
<zyga-ubuntu> to make it crystal clear what they are
<Chipaca> zyga-ubuntu: what would rollback do?
<Chipaca> i
<Chipaca> the way i wrote it, the creator of the aw is the one that needs to handle cleanup on error
<Chipaca> just like with 'plain' files
<mvo> Chipaca: hm, my gut-feeling is that the api would feel a bit unexpected if commit() is a thing that is final and can not called multiple times. this goes into bike-shed land but maybe "Finalize()" or something more "final"?
<Chipaca> mvo: hmm... good point. Atomize()? :-P
<Chipaca> (still feeling bad about having a Fooer interface that doesn't have a Foo() method)
<mvo> Chipaca: yeah, and the enhanced version is called Fusionize()
<Chipaca> Unionize()
<mvo> lol
<mimag1> What is required from a python directory to make the python plugin work?
<zyga-ubuntu> Chipaca: I mean rollback as a rename of close
<zyga-ubuntu> Chipaca: close and commit are indeed confusing (I agree with mvo on this) but I see the need. I would just call them more clearly
<Chipaca> zyga-ubuntu: but rollback to me would imply it cleans up the tempfile also
<zyga-ubuntu> Chipaca: indeed, I think you see my point, the actual name (rollback) may be just my knee-jerk for commit, as long as the API is sensible and clear I give my +1
<Chipaca> something along the lines of Finalize would work for me
<Chipaca> looking at synonyms now
<zyga-ubuntu> Done()
<zyga-ubuntu> RealllyHitTheDisk()
 * zyga-ubuntu needs to read that PR
<Chipaca> Enfeoff() \o/
<zyga-ubuntu> Achoo()?
<Chipaca> mimag1: so
<Chipaca> mimag1: this is kinda silly i fear
 * Chipaca tries something else
<mimag1> what is silly?
<Chipaca> mimag1: I'm afraid I'm stumped; you'll have to get help from an actual snapcrafter
<Chipaca> it _should_ work, as far as i know, and in fact it seems to half work and then lose itself
<mimag1> @Chipaca exactly my experience
<nothal> mimag1: No such command!
<Chipaca> nothal: dance for me
<mimag1> exactly my experience
<mimag1> nothal: Which command is wrong?
<Chipaca> mimag1: nothal is a bot, that can take commands explicitly starting them with @
<Chipaca> mimag1: as @ is not usually used to start messages in irc, it used to work
<Chipaca> but then other chat systems happened, and nothal hasn't adapted
<Chipaca> mimag1: wrt your issue, i'd suggest asking in the forum, or in rocketchat (snapcrafters use rocketchat more than the forum, i think)
<Chipaca> that's https://forum.snapcraft.io/ or https://rocket.ubuntu.com/channel/snapcraft
<mimag1> Thank you Chipaca
<mzanetti> hey, I'm looking for docs on how to do config file management with snappy. i.e. I need to preinstall a configuration file in SNAP_DATA (or something that's writable at runtime) and then do config updates on snap package updates.
<mzanetti> Can't really find something in the docs so far
<mvo> pstolowski: do we have a forum post about the new install/remove hooks? anything I could link to?
<pstolowski> mvo, not yet, but I'll create one soon
<mvo> pstolowski: thank you
<mimag1> mzanetti, mvo, psstolowski: +1 on that forum post. I have written some configure hooks but I guess there is a better way
<zyga-ubuntu> wow, we are at 17 open PRs
 * zyga-ubuntu reviewed a repair PR, fist in a long time
<zyga-ubuntu> lookin at more
<zyga-ubuntu> Chipaca: one thing I wanted to share with you, not sure if you used it yet
<zyga-ubuntu> Chipaca: you probably know about this already
<Chipaca> zyga-ubuntu: spit it out already :-D
<zyga-ubuntu> Chipaca: but please read the section on O_TMPFILE in open(2)
<zyga-ubuntu> Chipaca: this allows you to create a file, write all data, set mode and ownership
<zyga-ubuntu> Chipaca: and only make it show up, atomically
<zyga-ubuntu> Chipaca: or die with the process
<zyga-ubuntu> Chipaca: it's a very compelling API
<zyga-ubuntu> Chipaca: I wanted to make sure you know about it, and with that note, I'm going to review the rest
<Chipaca> I did not know about this
<Chipaca> thank you
<Chipaca> zyga-ubuntu: 3.11 is << our minimal kernel version, i take it?
<zyga-ubuntu> my pleasure :)
<Chipaca> ondra: ^?
<zyga-ubuntu> Chipaca: that patch is AFAIR not too big, it's also a prerequisite for mir and I heard it's quite common now
<Chipaca> (i mean, the minimal kernel version our users are using, which is almost certainly < than the one we support)
<zyga-ubuntu> Chipaca: though a perfect implementation would degrade gracefully
<Chipaca> nice
<Chipaca> i'll wait for ondra to speak up (or 301 me)
<zyga-ubuntu> Chipaca: in general, it's a very good API to have for atomicity
<zyga-ubuntu> 301?
<ondra> Chipaca hey
<Chipaca> zyga-ubuntu: "ask so-n-so"
<ondra> Chipaca I think it was even 3.10
<Chipaca> ondra: as in, people using 3.10 with snappy?
<Chipaca> ondra: do you know if it's tweaked to also have O_TMPFILE?
<ondra> Chipaca I think there were some attempts, but using is probably too strong statement
<Chipaca> zyga-ubuntu: grep -r O_TMPFILE /usr/share/go-1.6 and weep
<Chipaca> ondra: :-) ok
<Chipaca> zyga-ubuntu: I'd have to look into how this behaves for the wrong kernel and the wrong filesystem, to fallback properly
<zyga-ubuntu> ESYS
<zyga-ubuntu> AFAIR
<zyga-ubuntu> but please check
<Chipaca> zyga-ubuntu: the docs say EISDIR (kernel) or EOPNOTSUPP (filesystem)
<zyga-ubuntu> ahh, sorry then, I must be wrong
<mup> PR snapd#3625 closed: many: end-to-end support for the bare base snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3625>
<Chipaca> zyga-ubuntu: how do you use O_TMPFILE to replace an existing file?
<Chipaca> zyga-ubuntu: linkat doesn't let you replace files
<zyga-ubuntu> Chipaca: you can still link it to .foo and then call move
<Chipaca> hmmm
<Chipaca> the cleanup story becomes a lot harder
<Chipaca> hmm hmm
<zyga-ubuntu> Chipaca: in which way?
<Chipaca> zyga-ubuntu: "close it, and if it was created, remove it"
<Chipaca> meaning we'd probably have to make something on the object itself
<zyga-ubuntu> Chipaca: note that this was just a suggestion, if it makes anything harder then by all means, ignore it: )
<Chipaca> zyga-ubuntu: i like it, i'm just thinking it through
<Chipaca> loudly and using you as the sock puppet
<zyga-ubuntu> Chipaca: oh, one related note: https://betanews.com/2017/09/03/android-oreo-linux-kernel/
<zyga-ubuntu> haha, my pleasure :)
<zyga-ubuntu> All SoCs productized in 2017 must launch with kernel 4.4 or newer.
<Chipaca> zyga-ubuntu: your network is so lagged it's fun
<zyga-ubuntu> so 4.4 is a good bet for many new pieces of hardware
<Chipaca> * Ping reply from zyga-ubuntu: 1.631 second(s)
<zyga-ubuntu> Chipaca: my network is actually brilliantly fast now
<zyga-ubuntu> oh?
<zyga-ubuntu> I saw 0.6 on my end
<zyga-ubuntu> not sure where that much of a lag is coming from
<Chipaca> zyga-ubuntu: i just pung jamie and got .3s
<Chipaca> so it's not me :-)
<zyga-ubuntu> jamie is 0.7
 * zyga-ubuntu pings pawel 
<Chipaca> yeah, consistently getting 1+ seconds (and i only noticed because of how delayed your answers were)
<zyga-ubuntu> pawel is 0.6
<zyga-ubuntu> weirdish
<zyga-ubuntu> anyway, I was never happier with any network before
<Chipaca> zyga-ubuntu: good to know
<zyga-ubuntu> highest bandwidth and mobility
 * zyga-ubuntu stops bragging
<Chipaca> zyga-ubuntu: and you get 1TB (or 1Tb?)
<zyga-ubuntu> yes
<zyga-ubuntu> a month
<zyga-ubuntu> and it's not location-bound
<zyga-ubuntu> I'm seeing 12-15MB/s to ubuntu archive
<zyga-ubuntu> I haven't tried much more though :)
 * zyga-ubuntu sees rain outside and feels like being in London
<mvo> pedronis: you asked a question in 3642 - is that something that needs more work or are you happy with the reply?
<pedronis> mvo: one sec
<zyga-ubuntu> 16 requests :)
<pedronis> mvo: Chipaca: there's been a bit of an electric installation emergency here, I have eletricity only in half the place, internet is on the right half, but might be a bit on and off today
<Chipaca> pedronis: why do I imagine half your house on fire
<pedronis> hopefully not, but there was a zero chance it could :/
<Chipaca> pedronis: probably https://www.youtube.com/watch?v=1EBfxjSFAxQ
<pedronis> a non-zero
<mvo> pedronis: uh, good lucj
<mvo> luck
 * zyga-ubuntu sees red in travis :/
<zyga-ubuntu> pedronis: stay safe!
<zyga-ubuntu> <kill-timeout reached>
<zyga-ubuntu> does anyone know what the timeout is?
<zyga-ubuntu> it would be awesome if spread said that
<Chipaca> zyga-ubuntu: and in the end I'm writing stuff that looks alarming like Rollback
<zyga-ubuntu> Chipaca: does that mean I get two +1s or two -1s?
<Chipaca> zyga-ubuntu: I don't know.
<Chipaca> zyga-ubuntu: I'm calling it Cancel, anyway
<zyga-ubuntu> Cancel is nice
<zyga-ubuntu> oh
<Chipaca> zyga-ubuntu: because mvo's point about calling Commit multiple times makes some sense
<zyga-ubuntu> feels like context
<Chipaca> (only some, because you can't commit multiple times in sql afaik)
<Chipaca> zyga-ubuntu: only doing this refactor so it's easier to do the tmpfile later
<ogra_> grmbl
<ogra_> why dont i have a /dev/fb0 in my initrd on the pi
<ogra_> zyga-ubuntu, so any ideawhy the opengl interface fix is not in edge ?
<ogra_> i thought we do rebuilds of the edge deb for every commit ?
<ogra_> s/commit/merged PR/
<ogra_> mvo, ^^ is that not the case ?
<mvo> ogra_: yes, that should be the case, lets check the edge ppa
<mvo> ogra_: when did the fix land?
<ogra_>  mvo5 merged commit 6d8d625 into snapcore:master 4 days ago
<ogra_> says GH
<ogra_> apparently snapd FTBFS since the 31st
<ogra_> (well, on arm and i386)
<pedronis> zyga-ubuntu: IÂ think kill-timeout  is 20m , that's what in spread.yaml
<ogra_> mvo, if i read the log right (not sure i do) it fails in the github.com/snapcore/snapd/x11 test
<ogra_> ah, no, there are earlier ones
<mvo> ogra_: hm, 4 days ago
<ogra_> uh
<ogra_> bad system call
<ogra_> https://launchpadlibrarian.net/335269966/buildlog_ubuntu-xenial-armhf.snapd_2.27.5+git354.834024b~ubuntu16.04.1_BUILDING.txt.gz
<mvo> ogra_: yeah, but that is already 4 days old
<ogra_> yep
<mvo> ogra_: and this should be fixed in master
<mvo> ogra_: looks like our automatic merging via snap-cron is not working
<ogra_> did fgimenez take all his PPA scripts with him ?
<mvo> ogra_: I have a look, but maybe I need cachio
<mvo> ogra_: this is actually possible :(
<ogra_> (might be the build was triggered under his user)
<mvo> ogra_: I mean, its possible that the upload creds got removed with his account
<ogra_> yeah
<ogra_> under "uploader" there is "no signer" ... https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
<ogra_> (never seen that)
<zyga-ubuntu> ogra_: no, no idea, maybe due to imminent release
<zyga-ubuntu> ogra_: I really really wish we had a setup where edge == master in all cases
<ogra_> zyga-ubuntu, well, see above we lost the daily snapd deb
<zyga-ubuntu> ogra_: and releases would build from a separate PPA and separate recipe of core
<ogra_> zyga-ubuntu, it is !
<mvo> ogra_: I retriggered the job, that should give me some data, if that fails I need to talk to cachio
<mvo> ogra_: but the date (2017-08-31) is suspecious, that is the date that federico left
<ogra_> zyga-ubuntu, only if mvo does a relese build manually it isnt usually ... but thats really short snapshot times
<zyga-ubuntu> ogra_: no, we often have to delete a deb somewhere or rebuild a deb for edge to be back on master, probably the details elude me but the property that master == edge is not held
<zyga-ubuntu> pedronis: thank you!
<zyga-ubuntu> ogra_: again, I wish it was never
<ogra_> zyga-ubuntu, we onyl ever have to delete the deb that was manually uploaded to the image ppa
<ogra_> so the manual step changes it and the manual step switches it back ... for full release control
<zyga-ubuntu> well, we don't need that
<zyga-ubuntu> we need control over beta, candidate and stable
<ogra_> zyga-ubuntu, though if the shema i develoed ages ago with federico would have been implemented you wouldnt have that setp ever :)
<zyga-ubuntu> edge should be on autopilot all the time
<zyga-ubuntu> I'm sure we can improve things :)
<ogra_> we have a roperly worked out build plan
<ogra_> just never implemented
<ogra_> *properly
<ogra_> it is exactly focused to fix your complaint ... :)
<ogra_> *on fixing
<ogra_> mvo, i'll try to trigger a build of https://code.launchpad.net/~snappy-dev/+recipe/snapd-vendor-daily ... lets see
<ogra_> (speak up if i shouldnt please)
 * ogra_ clicks the button
<mvo> ogra_: the vendor sync thing ran some minutes ago, I will double check
<mvo> ogra_: ok, powerpc and s390x fail but the rest is building
<ogra_> well, arm64 isnt done yet :)
<ogra_> but yeah, looks better already
<ogra_> mvo, the upload log looks weird as well though ... might be we need to manually delete the old package
<ogra_> https://launchpadlibrarian.net/335757858/upload_1442402_log.txt
<mvo> ogra_: thats ok
<ogra_> ok
<mvo> ogra_: I think what happend is that the sync also triggered an upload
<ogra_> ah
<mvo> ogra_: and then you triggered one manually and the changelog version is the same
<mvo> ogra_: which is fine because the content is the same :)
<ogra_> indeed
<mvo> ogra_: I'm checking hte powerpc failure now, that looks like something with gccgo :/ otherwise I thin kwe are good and you can trigger an edge build to test your opengl fix
<ogra_> mvo, will do
<ogra_> edge build running
<greyback> hey, should tha RPI3 image automatically resize the writable partition to fill the SD card on first boot?
<ogra_> greyback, yes
<greyback> ogra_: didn't work for me just now (today's daily edge). I'll log bug
<ogra_> greyback, there iss a log kept in /run/initramfs (note thats a tmpdir though ... so it is gone if you reboot)
<greyback> ogra_: ack. I'll reflash and grab that for you
<ogra_> greyback, als include df -h /writable please (and syslog and dmesg output)
<ogra_> *also
<greyback> *nod*
<ogra_> cachio recently found that some SDs are not well supported on the Pi so not sure we can do much if the SD is in that list
<greyback> oh interesting. I didn't get a cheap one at least
<ogra_> http://elinux.org/RPi_SD_cards
<ogra_> not sure how valid that still is though ... originally created 2012
<zyga-ubuntu> get a HDD
<zyga-ubuntu> screw SD
<ogra_> heh
 * zyga-ubuntu waits for first boot-from-CD rpi hack
<ogra_> are USB-CD drives still being sold ?
<greyback> https://pastebin.ubuntu.com/25464779/ - resize doesn't appear to error out, but no change
<zyga-ubuntu> ogra_: yesd
<zyga-ubuntu> ogra_: and arguably, still useful :)
<ogra_> pfft
<ogra_> greyback, hmm, looks all fine (apart from the size)
<ogra_> greyback, how big is that SD ?
<greyback> ogra_: 32GB
<zyga-ubuntu> 4cm by 2cm
 * zyga-ubuntu hides
<greyback> :D
<ogra_> zyga-ubuntu, then he would need to fold it to fit into the slot :P
<ogra_> that might indeed be the prob then :P
<ogra_> greyback, have you made sure it was not accidentially automounted when you dd'ed to it ? i have seen issues with the partiton table when people forgot that
<greyback> ogra_: I typically unmount before flashing. But let me try once more, to be totally certain.
<greyback> kde, why did you remount something I explicitly unmounted
<ogra_> heh
<greyback> ogra_: ok, that did it. Apologies for the noise
 * Chipaca ~> run and lunch
<ogra_> greyback, np
<zyga-ubuntu> jdstrand: hey, around?
<ogra_> greyback, btw, if you refresh core right after first boot (before installing any mir bits), you should now have the fix of the GL interface
<greyback> ogra_: noted. Will try
<greyback> ogra_: fixing the udev script did the job too
<ogra_> indeed ...
<ogra_> the new core should generate it propely from the start though
<zyga-ubuntu> jdstrand: so I'll just leave you a message
<zyga-ubuntu> jdstrand: I'm looking ad child profiles but I get compile errors
<zyga-ubuntu> jdstrand: the apparmor reference has this worring statement:
<zyga-ubuntu> jdstrand:  <path> 'x' '->' <profile list> ',' (not yet supported)
<zyga-ubuntu> jdstrand: it does have:  ('safe' | 'unsafe') <path> <qualifier>'x' [[' ->' <profile name>] ['+' <profile name>]] ','
<zyga-ubuntu> jdstrand: I'll keep digging but I suspect I'm either missing something super obvious or we may have a problem with xenial
<zyga-ubuntu> ahhh
<zyga-ubuntu> darn :)
<zyga-ubuntu> jdstrand: so just for information, I was stuck on the fact that the child profile cannot have dashes in it
<mvo> zyga-ubuntu: jdstrand is off today afaik, labor day in the us
<zyga-ubuntu> mvo: ah I didn't know
<zyga-ubuntu> anyway I'm progressing, I just launched a run of tests/main/ with child profile on snap-update-ns
<zyga-ubuntu> which gives me enough time to make something to drink :)
<zyga-ubuntu> hmm
<zyga-ubuntu> mvo: after base snap patches landed in master my tests started to fail
<mvo> zyga-ubuntu: what tests exactly?
<zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/271651836?utm_source=github_status&utm_medium=notification base-snaps spread test
<zyga-ubuntu> mvo: I'm runnin a sequence with -debug so I'll get to that soon
<zyga-ubuntu> just curious what happened there
<zyga-ubuntu> oh man, it's raining crazy
<mup> PR snapd#3846 opened: debian: add missing flags when building static snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/3846>
<mvo> zyga-ubuntu: I'm not sure if that branch really had any side-effects, it really should only affect things when base: foo is used
<mvo> zyga-ubuntu: heh
<zyga-ubuntu> mvo: it passed just a moment ago, before the merge
<zyga-ubuntu> mvo: but that's fine, I'll get to the bottom of this
<zyga-ubuntu> mvo: but I wanted to mention this in case it affects 2.28
<mvo> zyga-ubuntu: yeah, its a new test
<ogra_> dang !
<ogra_> no framebuffer device in pi initrd's without a gazillion of drm/kms modules :/
<mvo> zyga-ubuntu: hm, I guess the problem is that snap-update-ns needs to be static linked
<mvo> zyga-ubuntu: same problem as snap-exec, if you run it *inside* the bare base there is no libc
<zyga-ubuntu> mvo: that makes sense
<zyga-ubuntu> mvo: thanks, I'll make the modifications
<zyga-ubuntu> ah
<zyga-ubuntu> darn, meeting is coming up and I'm parched
<ogra_> ppisati, do you think building vc4 intob the kernel would do any harm on rpi ?
<ogra_> (specifically if the dtb overlay does not get used)
<ikey> heh http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=apparmor-4.13%2boutoftree
 * ikey yoinks it
<ppisati> ogra_: waste of some memory, probably
<ppisati> ogra_: what's the matter with it being a module?
<zyga-ubuntu> Chipaca: I did a quick review of the packaing branch, I'll do a deeper one now
<zyga-ubuntu> Chipaca: also dropped a crazy suggestion that may, ironically, be nicer if you think along the same lines
<ogra_> ppisati, i have the split initrd stuff woprking here and am now loading a psplash.img with the initrd ... that works just fine if i dont enable kms ... if i do enable kms there is no /dev/fb0 until the module is loaded
<ogra_> ppisati, so either i create an additional vc4modules.img that i load alongside with psplash.img to ship the modules, or we always pull the vc4 modules into the initrd ... or we compile it in ... my main concern was if it would break when vc4 is builtin but the overlay isnt used
<Chipaca> zyga-ubuntu: wrt your cray-cray suggestion, is mwhudson going to nyc?
<Chipaca> zyga-ubuntu: because it's the kind of crazy that requires all hands on beer
<Chipaca> but, maybe? it's probably doable
<Chipaca> for debian-ish things at least
<Chipaca> hope you don't mean also for non-debianish
<zyga-ubuntu> Chipaca: I think so
<zyga-ubuntu> Chipaca: so far I meant debian-ish
<ikey> lol all hands on beer
<zyga-ubuntu> Chipaca: which will give us enough rope for various debian+ubuntu releases
<zyga-ubuntu> ikey: very serious topic that
<ppisati> ogra_: ah, i don't think so, usually overlay just enable the hw resource and the driver attaches to it - if it's not enabled, the driver won't attch and that's it
<zyga-ubuntu> ;)
<ikey> ill settle for cider :P
<ppisati> ogra_: at least, in theory, we should definitely try it :)
<Chipaca> ikey: just for the record, what I mean is that it requires a relaxed, informal, and high bandwidth conversation to come to a reasonable agreement quickly around things, before diving into the technical details of it
<ogra_> ppisati, ahh, well, i generated and loaded a vc4modules.img ... i see all modules loaded but still no /dev/fb0
<ikey> ya, chinwag.
<Chipaca> ya
<diddledan> you got a floppy chin, ikey ? :-p
<ikey> nah i upgraded to an ssd shin
<Chipaca> the beer is completely optional, and if anybody involved were opposed to it, it wouldn't feature at all
<diddledan> aah
<diddledan> beer sounds like a plan
<ikey> beer is a cultural lubricant for the mind
<ikey> (im irish, we have this nailed.)
<diddledan> although considering it's only 3pm in the UK it might be a bit looked-down-upon
<ikey> "liquid lunch"
<ikey> >_>
<diddledan> lol
<ogra_> ppisati, so there is still something missing even though the kernel auto-loads them when the dtb is turned on ... (perhaps a udev rule or whatnot)
<Chipaca> ikey: just to point out, while it often is, it can also be a barrier to some folks (which is why i'm going all explanatory)
<ikey> oh i know
<Chipaca> k
<Chipaca> i just happen to know the people involved :-)
<ikey> gotcha :D
<Chipaca> zyga-ubuntu: now we need _you_ to get to nyc, don't we
<Chipaca> :D
<zyga-ubuntu> indeed,
<ikey> at least the nyc flights wont be as bad as some of the US flights ive done
 * zyga-ubuntu needs to break for a moment
<ikey> (which was UK -> Amsterdam -> Portland OR usually)
<ppisati> ogra_: weird... but if you let the system boot till userspace, fb0 is there, right?
<ogra_> yep
<ogra_> just not when stopping with break=premount
<greyback> ikey: yuk, and no pre-clearance in Dublin
<Chipaca> zyga-ubuntu: on the subject of that PR though, if 14.04 no longer needs snap.mount.service.wotsit, let's nuke it
<Chipaca> i don't know how to go about nuking it, but let's
<ikey> greyback, yeah this time im doing dublin -> jfk (first time) so im not really looking forward too much to the hall part of it..
<ikey> actually worse than that is likely getting from tullamore to dublin in the first place :p
<greyback> ikey: hah :)
 * ikey has had "streets of new york" stuck in his head for 2 weeks though
<zyga-ubuntu> Chipaca: not sure, check if it is installed
<zyga-ubuntu> Chipaca: is it really shipped by the package
<zyga-ubuntu> Chipaca: maybe it is, maybe not
 * zyga-ubuntu really afk
 * ikey should get a super obnoxious solus t-shirt printed off before heading out that way
<Chipaca> zyga-ubuntu: in that's the actual packaging code used to package the package, it's packaged
<pedronis> why I'm getting network time of 2106
<greyback> ikey: we wouldn't recognise you without it ;)
<ikey> ah sure you will
<greyback> and stickers. A project dosn't exist without stickers
<ikey> just look for the angriest looking person in nyc
<ikey> (i have b*tchy resting face something chronic)
<zyga-ubuntu> pedronis: must be that new internet... ipv6 they call t
<ikey> plus ill have the cap :p
<greyback> ikey: ah, we'll just have to give you some things to be legitimately angry about then
<ikey> maybe ill get the head mad max'd again so i stick out
<diddledan> new internet my foot. those kids today don't know they're born without trying the original internet!
<ikey> greyback, you'd have a hard time not spotting this loon: https://ibin.co/3ZEhYhoxZ3Gf.jpg
<ogra_> ppisati, hah .. i now just added all modules to my modules.img ... now i got fb0 (but psplash does hang )
<greyback> ikey: so you're the one they speak of in Tullamore...
<ikey> XD
<greyback> it all becomes clear
<ogra_> seems i was just missing some module (6though not sure which one)
<diddledan> ALL the modules!
<ogra_> only 10 o so :)
<diddledan> bah. put moar!
<ogra_> sigh .. this drm stuff gives me headdaches
<ikey> who *really* needs graphics tho..
<ogra_> ikey, shush, greyback is here :P
<diddledan> what has a gui ever done for us?!
 * ikey stands with the peoples fronts of nano
<ikey> or is it the nano people's front..
<diddledan> oh, I thought it was the popular front of Nano
<ikey> still. what has the gui ever done for us?
<diddledan> what happened to the popular front of people's nano?
 * ikey slaps 4.13 kernel
 * diddledan compiling ring-gnome-client
<ikey> can certainly see how much of apparmor has gone upstream
<ikey>  ...-Artful-jj-s-kernel-s-apparmor-4.13-outof.patch |  4023 ++++++
<ikey>  ...-Artful-s-master-next-apparmor-implementa.patch | 13659 -------------------
 * ogra_ dances around diddledan 
<diddledan> is that an ironic "how much got upstreamed"?
<ikey> no
<diddledan> s/ironic/sarcastic/
<ikey> for the 4.12.x kernels we had a 13.5k line patch
<ikey> now we have a 4k line patch
<diddledan> aha, that's pretty awesome then
<ikey> aye
<ikey> granted ive no idea if its gonna work but hey thats what unstable repos are for
<diddledan> let those kernel dudes futs with looking after it :-p
 * ikey is regrettably solus kernel dude
<ikey> lol
<ikey> ok admittedly im solus many-dude..
<diddledan> aren't you solus <everything> dude, though?
<ikey> many, not everything :p
<ikey> we have other dudes
<diddledan> like flexiondotorg is Ubuntu Martin <everything> dude :-p
<ikey> lol ubuntu martin
<ikey> i do a fair bit but you can see from https://build.solus-project.com/ its not just me
<ogra_> ikey, boo, get more dudettes !
<ikey> and a lot of stuff is landing other peoples patches
<ikey> (from the community)
<ikey> ogra_, ah true enough. tech needs more dudettes
<ogra_> !
<zyga-ubu1tu> ikey: 4.14 has more
<ogra_> dudettes  ?
<ogra_> cool
 * ikey cries when he notices a new lts kernel too
<cachio> ogra_, hey
<ogra_> hey cachio
<cachio> ogra_, working with console conf currently
<cachio> and I see a problem in the dragonboard when I try to reconfigure the wifi settings
<cachio> https://paste.ubuntu.com/25465490/
<cachio> ogra_, it gives me a timeout error
<cachio> any idea what could be causing that
<cachio> if I run the same in the pi3 it works perfectly
<ogra_> not really ... but my first look would go at netplan ...
 * diddledan twiddles his thingies waiting for build
<diddledan> https://imgs.xkcd.com/comics/compiling.png
<ogra_> on the pi we had issues with the bind/unbind of the module that netplan does when probing, for the pi we blacklisted it ... perhaps it is something similar on the db
<ogra_> cachio, though the log looks like it comes up in the end
<ogra_> Sep  4 14:26:17 localhost systemd-networkd[2984]: wlan0: Configured
<cachio> ogra_, yes
<ogra_> but you seem to have configured ipv6
<cachio> it makes the configuration but it gives hte error
<ogra_> perhaps that is getting in your way here
<diddledan> frak
<cachio> ogra_, I tried with ipv6 and without and the error is the same
<diddledan> I got a stage package name wrong
<diddledan> I really wish SNAPCRAFT_CONTAINER_BUILDS=1 didn't die on me
<Chipaca> mvo: was your "nice" on snapd#3845 a +1-if-you-add-tests? 'cause i've added tests and everything's green so i'm wondering :-)
<mup> PR #3845: osutil: include a variant of AtomicWrite* that takes an io.Reader <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>
<mvo> Chipaca: heh, let me have a look again
<zyga-ubuntu> ok, my apparmor profile works great
<zyga-ubuntu> let's merge master and let's adjust build rules for snap-update-ns
<zyga-ubuntu> mvo: thank you again :)
<mvo> Chipaca: re 3846> would it make the unification PR simpler if I add the GCCGOFLAGS in both places? or would it be simpler if it stays as is. its funcitonal irrelevant but I am keen to make your life simpler
<mvo> zyga-ubuntu: my pleasure
 * zyga-ubuntu tests again
<om26er> Hi! I have a snap that wants to use a certain dbus interface. Is there a better way than creating a slot for that interface ? I don't want other apps to use my slot, I only want my own snap to use that interface only.
<zyga-ubuntu> om26er: hey, which interface is that?
<diddledan> om26er: you need to create a slot for it. your own snaps will auto connect to them when they're defined to plug that slot, but you can't prevent the user from manually connecting other snaps
<om26er> zyga-ubuntu: org.kde.screensaver
<zyga-ubuntu> om26er: so you would like to be the screensaver or talk to an existing screensaver?
<om26er> zyga-ubuntu: I want to lock the screen and also check if its already locked.
<om26er> (remotely)
<zyga-ubuntu> I see, one sec
<mup> PR snapd#3846 closed: debian: add missing flags when building static snap-exec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3846>
<zyga-ubuntu> om26er: so there's the screen-inhibit-control but it only allows one method
<zyga-ubuntu> om26er: so you will need a new interface or you may need to check with one of the new desktop interfaces developed by jdstrand
<zyga-ubuntu> om26er: let me look at them
<zyga-ubuntu> om26er: looking quickly I don't see any screensaver stuff there, so it would be a new interface
<zyga-ubuntu> om26er: that interface will be provided by classic systems
<zyga-ubuntu> om26er: and once connected it would allow your app to query the state
<om26er> zyga-ubuntu: ah, shall I file a bug for that ?
<zyga-ubuntu> om26er: as well as controll it (which might be a separate interface, not sure yet)
<zyga-ubuntu> om26er: can you please open a forum thread
<zyga-ubuntu> om26er: we kind of use forum more than bug tracker
<om26er> I will do that.
<zyga-ubuntu> om26er: I don't suspect there are issues creating the interface but I'm sure the security team will review the impact and decide on auto-connection
<zyga-ubuntu> om26er: thank you!
<om26er> diddledan: that actually answered one of my questions that I asked yesterday. In my testing if I defined a slot, my snap automatically got access to that  interface. Though when I tried to publish that to the store, it said it would need "manual review"
<zyga-ubuntu> om26er: no
<zyga-ubuntu> om26er: interfaces have four elements
<zyga-ubuntu> om26er: permanent plug and slot specification
<zyga-ubuntu> om26er: and per-connection plug and slot specification
<zyga-ubuntu> om26er: it depends on the interface what those do
<om26er> human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration declaration-snap-v2_slots_deny-connection (kde-screensaver-dbus, dbus)
<zyga-ubuntu> om26er: which interface did you specify?
<zyga-ubuntu> kde-screensaver-dbus?
<om26er> zyga-ubuntu: yes: https://github.com/om26er/linux-desktop-manager/blob/master/snap/snapcraft.yaml#L31
<om26er> the commented lines at the end.
<zyga-ubuntu> om26er: that's for *being* on the bus
<zyga-ubuntu> om26er: the summary says: "allows owning a specifc name on DBus"
<zyga-ubuntu> om26er: you don't want that
<om26er> my understanding of dbus interfaces is very limited, so the terminologies confuse me =)
<zyga-ubuntu> om26er: I can explain
<zyga-ubuntu> om26er: the word interface is very overloaded
<diddledan> in terms of snappy, a slot is a service that your snap provides to the system, and a plug is a definition that declares which system services your snap uses (or consumes)
<zyga-ubuntu> om26er: there are dbus terms and snapd terms that apply
<om26er> diddledan: that bit was clear, yes.
<diddledan> :-)
<zyga-ubuntu> mvo: hmmm
<zyga-ubuntu> (cd _build/bin && GOPATH=$(pwd)/.. CGO_ENABLED=0 go build github.com/snapcore/snapd/cmd/snap-update-ns)
<zyga-ubuntu> can't load package: package github.com/snapcore/snapd/cmd/snap-update-ns: C source files not allowed when not using cgo or SWIG: bootstrap.c
<zyga-ubuntu> mvo: why did you set CGO_ENABLED=0 there
<zyga-ubuntu> (I just copied that)
<om26er> zyga-ubuntu: the only thing in dbus word that I don't understand is "owning a DBus interface". Other things are pretty clear.
<diddledan> that would be like a snap slot. it is a service that you provide
<cachio_lunch> mvo, FYI, 2.27.5 it is already in the mirrors
<diddledan> an alternative way to think of it is like owning the port in networking - when you LISTEN on port 80 then only you can receive stuff sent there.
<mvo> zyga-ubuntu: because CGO_ENABLED=1 pulls in glibc and friends
<cachio_lunch> I tested the upgrade and it works
<zyga-ubuntu> mvo: and that is bad?
<cachio_lunch> mvo, the smoke tests pass
<mvo> zyga-ubuntu: for a static build yes
<diddledan> so owning a dbus name/interface means you're listening for communication to that name
<om26er> O Hi cachio_lunch =)
<mvo> zyga-ubuntu: this is done so that we can have a completely empty base snap or a base snap with different libc than glibc etc
<cachio_lunch> hi, om26er
<mvo> cachio_lunch: great!
<zyga-ubuntu> and cgo == not static?
 * cachio_lunch gonna lunch now
<mvo> zyga-ubuntu: well, that was the only way I found to disable dynamic linking, maybe there are more ways?
<mvo> zyga-ubuntu: hold on a sec, I will create an example in a sec
<diddledan> mvo: quick gooling: go build --ldflags '-extldflags "-static"' file.go
<diddledan> I haven't tested whether that works tho
<zyga-ubuntu> mvo: no need, I'll explore
<zyga-ubuntu> mvo: I'm trying to make snap-update-ns static :)
<pedronis> so I learned if /var/lib/systemd/clock  gets a strange mtime you are in for a lot of "fun"
<mvo> diddledan: thanks a bunch!
<diddledan> I got that from http://blog.madewithdrew.com/post/statically-linking-c-to-go/
<mvo> zyga-ubuntu: indeed, you need something different from what I needed for snap-exec :)
<zyga-ubuntu> mvo: fun
<zyga-ubuntu> mvo: maybe rewrite snap-update-ns in C? ;-))
<mvo> diddledan: thanks again, TBH I stopped looking at this when snap-exec build statically but zyga-ubuntu needs to still have cgo enabled so your suggestion may be a good hint for him
<diddledan> the new kids would have you do it swift or rust
<mvo> zyga-ubuntu: *cough*
<zyga-ubuntu> ;-)
 * zyga-ubuntu tries
<ikey> then spoil it all and use glib :p
<mvo> good luck
<zyga-ubuntu> and also re-registers his spanish car in poland
<zyga-ubuntu> ikey: we cannot use glib without doing a security review on it
<zyga-ubuntu> ikey: setuid code is totally paranoid
<ikey> oh i was being scathingly sarcastic
<ikey> if you have any way in which to avoid using glib, do so.
 * zyga-ubuntu works from the middle of a local gov office, changing plates
<zyga-ubuntu> uff :)
<mvo> cachio_lunch: I uploaded 2.28~rc1 to the PPA, I will let you know once it is in beta, AIUI all tests (ours and CE) will kick in automatically once it hits beta, right?
<zyga-ubuntu> darn
<zyga-ubuntu> my number plates end with RH
<zyga-ubuntu> no ubu plates
 * zyga-ubuntu is starving now
<zyga-ubuntu> hmm
<zyga-ubuntu> mvo: it built?
<zyga-ubuntu> but not static :/
<om26er> zyga-ubuntu: fyi: https://forum.snapcraft.io/t/need-an-interface-to-lock-the-screen/1972
<zyga-ubuntu> om26er: +1
<Chipaca> pedronis: any objections to having atomatt merge+rebase #3780?
<mup> PR #3780: many: configure store from state, reconfigure store at runtime <Blocked> <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
<Chipaca> or just rebase, dunno why i'm saying merge+rebase
<Son_Goku> mvo, I don't see a release/2.28 branch?
<Son_Goku> zyga-ubuntu, I'm considering backporting https://github.com/snapcore/snapd/pull/3260 to 2.27.5 for Fedora
<mup> PR #3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3260>
<Son_Goku> what do you think?
<zyga-ubuntu> Son_Goku: ooooh
<zyga-ubuntu> Son_Goku: yes, sure
<zyga-ubuntu> Son_Goku: I think the patch is small
<Son_Goku> I'm sick of all desktop snaps not working correctly because of no xdg-open
<zyga-ubuntu> Son_Goku: (well, isolated)
<zyga-ubuntu> Son_Goku: I'm worried about selinux, we should iterate on some more rules
<Son_Goku> I can probably guarantee we need to spend a cycle bringing the rules up to date with changes in 2.28
<mup> PR snapd#3831 closed: store: move device auth endpoint uris to config <Created by atomatt> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3831>
<Chipaca> 16 PRs and counting
<zyga-ubuntu> Son_Goku: yes, I think so
<zyga-ubuntu> Chipaca: isn't that a nice view? :)
<zyga-ubuntu> Chipaca: we need to core some more ;-)
<mvo> Son_Goku: yeah, still at ~rc1, I have not pushed anything yet, want to run a smoke test first
<zyga-ubuntu> Chipaca: I will land two RPrs by tomorrow evening
 * zyga-ubuntu waits in a car that now lacks insurance
<mvo> zyga-ubuntu: your PR built?
<zyga-ubuntu> mvo: yes but I get confusing outcomes
<zyga-ubuntu> mvo: I hand-looked at the bianry but it was dynamic
<zyga-ubuntu> mvo: but I may have looked at the wrong one
<zyga-ubuntu> isn't it silly that an insured car is no longer insured as soon as you change the number plates?
<Chipaca> zyga-ubuntu: that depends on jurisdiction :-)
<zyga-ubuntu> Chipaca: indeed,
 * Chipaca feels DOS'ed by zyga-ubuntu
<zyga-ubuntu> huh?
<Chipaca> zyga-ubuntu: I spent several seconds waiting,
<zyga-ubuntu> haha
<zyga-ubuntu> I wrote too many apparmor rules
<zyga-ubuntu> , is like a semicolon to me now
<Chipaca> /o\
<Chipaca> zyga-ubuntu: reminds me of the auto-unbox operator in python
<Chipaca> mvo: in snapd#3839, did you mean to drop the ? ?
<mup> PR #3839: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3839>
<pedronis> mvo: will you look into my last #3773 comments ? it's
<mup> PR #3773: snap-repair: execute the repair and capture logs/status <Created by mvo5> <https://github.com/snapcore/snapd/pull/3773>
<cachio> om26er, happy to see you are working around snappy
<om26er> cachio: me too =)
<mvo> pedronis: I will check that first thing in the morning, sorry, was busy with release prep
<mvo> Chipaca: not sure, I have a look
<mvo> cachio: fwiw, 2.28 is in the beta channel now
<mvo> cachio: well, 2.28~rc1 :)
<zyga-ubuntu> + snap install --edge core
<zyga-ubuntu> core 30.58 MB / 83.09 MB   36.80% 112.28 KB/s 7m58ss
<zyga-ubuntu> hmm
<zyga-ubuntu> that is linode
<zyga-ubuntu> is linode running on an expired 3G sim card?
<zyga-ubuntu> that would explain things
<ogra_> ISDN FTW!
<cachio> mvo, great, I'll start its validation
 * zyga-ubuntu eats supper in his car
<mvo> cachio: thanks!
 * zyga-ubuntu is looking at a night in a car
<ogra_> caravaning ?
<zyga-ubuntu> haha, on the front seat
<zyga-ubuntu> we were supposed to buy the insurance over the phone
<zyga-ubuntu> but ... ENOCALLS
<zyga-ubuntu> and online insurance shows x2 the amount we just talked about
<zyga-ubuntu> so ... waiting
<zyga-ubuntu> and we'd rather not leave it here
<zyga-ubuntu> because it's not insured, so once stolen, ...
<ogra_> oh my
<zyga-ubuntu> well
<zyga-ubuntu> sucks to own a internal combustion ass dragging apparatus
<pedronis> Chipaca: I answered there
<Chipaca> pedronis: i saw
<Chipaca> pedronis: i went
<Chipaca> pedronis: wait i got the order wrong
<pedronis> Chipaca: as long as your systemd doesn't think it's 2106, you should be fine :)
<ogra_> the question is ... does it only think it is in 2106 or is it actually ? ...if it is, could someone patch it to spit out the numbers of the lottery jackpot for next week ?
<Chipaca> ogra_: it's 2106, none of our ssl certs work any more
<Chipaca> ogra_: sorry
<ogra_> dang
<zyga-ubuntu> pedronis: ensure min tls or something
<zyga-ubuntu> pedronis: maybe it misfired
 * zyga-ubuntu is tired and cold now
<zyga-ubuntu> and it is raining again
<Son_Goku> zyga-ubuntu: let's see how this goes... https://src.fedoraproject.org/rpms/snapd/c/4761d994bd7c8194e1180bfe995ac1be03fa8f0a?branch=master
<zyga-ubuntu> Son_Goku: nice!
<zyga-ubuntu> Son_Goku: is the godbus dep available as a package/
<Son_Goku> I'm pleased to see that go mandates real tabs, though
<Son_Goku> zyga-ubuntu, Yep
<Son_Goku> https://koji.fedoraproject.org/koji/packageinfo?packageID=18330
 * zyga-ubuntu is running out of juice
<Son_Goku> have juice shipped to you :)
<zyga-ubuntu> I'm still stuck in my car
<zyga-ubuntu> that I cannot drive
<zyga-ubuntu> that my wife cannot drive because I'm the owner and after moving property from spain only the owner can
<zyga-ubuntu> and even if I could drive
<zyga-ubuntu> we cannot go anywhere
<zyga-ubuntu> because we cannot get insurance now
<zyga-ubuntu> because everything sucks that's why
 * zyga-ubuntu is getting grumpy
<Son_Goku> haha
<Son_Goku> aww
<Son_Goku> the cake is a lie
<Son_Goku> go mandates spaces for indentation :(
<Son_Goku> wait, no, that's just the diff viewer being stupid
<zyga-ubuntu> what? go doesn't care
<zyga-ubuntu> what a f*** day
<Son_Goku> it's not that bad of a day
<Son_Goku> I have the day off today, which is why I'm able to do anything at all :)
<Chipaca> Son_Goku: I'm sure he meant "fine"
 * zyga-ubuntu hugs Son_Goku 
 * zyga-ubuntu walks home
 * Son_Goku is building new snapd 2.27.5 for F25, F26, and F27
<Son_Goku> it build seems to be going well in rawhide, so why not
<Son_Goku> zyga-ubuntu, can anyone get in touch with robert-ancell?
<Son_Goku> his tarballs for snapd-glib 1.17 and 1.18 are missing: https://github.com/snapcore/snapd-glib/releases
<niemeyer> Son_Goku: He participates in the forum
<Son_Goku> does he announce snapd-glib releases there?
<niemeyer> Son_Goku: Don't recall seeing announcements there, but that'd be quite nice actually
<Son_Goku> I mean, I'll always know about new releases because release-monitoring.org is awesome
<pedronis> zyga-suse: ensure min tls is not run anywhere yet
<pedronis> this was my dev box
<pedronis> seems something confused ntp for a sec and it all went to future/hell from there
<pedronis> seems timesyncd doesn't recover from that on its own
<pedronis> also because it seems indeed once you are some much in the future lots of protocols/things stop working
 * zyga-suse mutters something about back to the future
<zyga-suse> also having a car sucks
<zyga-suse> also polari, the gnome IRC client, sucks
<Son_Goku> welp
<Sir_Gallantmon> gah, godbus wasn't submitted to f26 stable
<Sir_Gallantmon> no wonder the build failed
 * Sir_Gallantmon pushes it
<om26er> use IRCCloud then.
<Son_Goku> niemeyer, all of these links are broken: https://forum.snapcraft.io/t/the-roadmap/1973
<niemeyer> Son_Goku: How did you get to the topic then?  This was supposed to be unlisted :)
<Son_Goku> ...
<Son_Goku> wut
<Son_Goku> but... I can see it?
<niemeyer> Son_Goku: Yeah, unlisted != private
<niemeyer> Son_Goku: How did you get the first link?
<Son_Goku> email
<niemeyer> Weird
<niemeyer> That's not very unlisted :P
<Son_Goku> I'm not sure what to think about snapd growing support for managing services
<niemeyer> Son_Goku: The links seem to work fine in the web UI
<Son_Goku> when I clicked them it kept giving me 404s
<Son_Goku> and 403s
<Son_Goku> in this case, I got access denied
<niemeyer> Son_Goku: What's the URL it goes to?
<Son_Goku> https://forum.snapcraft.io/t/1908
<Son_Goku> https://forum.snapcraft.io/t/262
<Son_Goku> https://forum.snapcraft.io/t/1232
<Son_Goku> and so on
<niemeyer> Son_Goku: I can go to those URLs even without auth
<Son_Goku> :S
<Son_Goku> I don't know anymore
<niemeyer> The fact you got the email is probably a bug.. but not a very serious one
<niemeyer> Unlisted is just "don't list" really.. it's still public content
<Son_Goku> ah
<niemeyer> I'm finishing it still
<Son_Goku> welp, anyway, on another note, I got 2.27.5 built for Fedora
<niemeyer> Son_Goku: Can you please forward me the email?
<niemeyer> I'll probably file a bug upstream
<Son_Goku> email addr?
<Son_Goku> and I backported userd because I'm sick of people complaining that desktop snaps can't do the right thing...
<Son_Goku> and xdg-open is finally really dead
<Son_Goku> err, snapd-xdg-open
<Son_Goku> niemeyer: forwarded
<niemeyer> Son_Goku: Thanks!
<niemeyer> Son_Goku: You subscribe with the mailing list mode, right?
<Son_Goku> yep
<Son_Goku> I miss too much otherwise
<niemeyer> Cool, that should be enough for them to track it down
<exedore6> Iâm trying to get my head around snap, and Iâve got a (hopefully simple question) - when I install a snap, all of the dependencies are part of the package, if a server is part of the dependences (say apache for example) am I limited to using the ports that the packager used? Is this a sub-optimal use case for snappy (which isnât a problem) - where you might want to run an instance nextcloud and some other LAMP application. I feel like
<exedore6> Iâm either missing something, or barking up the wrong tree.
<exedore6> Any thoughts?
<Son_Goku> exedore6 yes, you can only use the stuff in the snap
<Son_Goku> you can link some other things through defined interfaces, but that's pretty much it
<exedore6> And you canât tell the apache in a snap to bind to say, port 81. Right?
<exedore6> Instead of whatever the packager used.
<exedore6> Because of the security features.
<Son_Goku> pretty much
<Son_Goku> as far as I know, at least
<exedore6> I can live with that. Makes more sense now. How about different interfaces?
<Son_Goku> you're really not supposed to have snaps binding to the lower ports, but they do anyway
<Son_Goku> everything is developer controlled
<exedore6> That makes all the sense in the world. It doesnât really seem the place for a service.
<Son_Goku> after a snap is made, there's very little a user can do with it
<Son_Goku> snaps are designed to favor the developer of the software in terms of configuration, control, and delivery
<exedore6> So my impression that theyâre killer for fat-applications, and fine for webapp demos, theyâre the wrong tool for that job.
<Son_Goku> if the snap is designed to export its configuration to your config directory (i.e. $HOME/snap/$SNAP_NAME), then user has control over config
<Son_Goku> but again, entirely up to the developer
<Son_Goku> all snap user data is supposed to live there
<exedore6> Thanks a bunch.
<Son_Goku> exedore6, also note that snap confinement is only currently available on Ubuntu
<Son_Goku> and Solus
<Son_Goku> it should become available in openSUSE Tumbleweed after the 4.14 kernel release (hopefully)
<Son_Goku> proper confinement support is TBD for RH/Fedora, Arch/Gentoo Hardened, as there's no SELinux backend for snapd yet
<King_InuYasha> hey robert_ancell
<robert_ancell> King_InuYasha, hello
<King_InuYasha> did you get my email about the snapd-glib tarballs?
<King_InuYasha> ugh
<robert_ancell> King_InuYasha, yep, fixing it now
<King_InuYasha> awesome
<King_InuYasha> I'm guessing you're going to be releasing 1.19 as well
<King_InuYasha> will that work okay with 2.27.5, or do I need to backport the license field stuff to snapd for it?
<robert_ancell> King_InuYasha, the license stuff just defaults to NULL if the snapd doesn't support it.
<King_InuYasha> ah, excellent
<robert_ancell> But this still requires some store work before it will be populated, so not sure when that will be done.
<King_InuYasha> it's painful enough to backport things in snapd
<King_InuYasha> I just did it today for userd
<robert_ancell> In general, I try to make snapd-glib work with any version of snapd
<King_InuYasha> nice
<robert_ancell> Next step, is seeing if I can get the translations to work
<King_InuYasha> heh
#snappy 2017-09-05
<mup> PR snapcraft#1527 closed: repo: Use os-release(5) to detect supported Linux distributions <Created by Conan-Kudo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1527>
<mup> PR snapcraft#1518 closed: project: introduce build-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1518>
<mup> PR snapd#3847 opened: tests: run the tests/unit/go everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3847>
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: no luck with static go + c
<zyga-ubuntu> mvo: I'll iterate shortly, just need to send kids to school
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: ok, good luck
<mvo> fwiw, I enabled an arful-i386 autopkgtest (outcome of the 2.27 cycle retrospect)
<mup> PR snapd#3839 closed: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3839>
<zyga-ubuntu> mvo: thanks, I had a question at the last stand-up, what happened to our ppc adt tests?
<pstolowski> morning
<zyga-ubuntu> hey pstolowski
<zyga-ubuntu> rainy day, eh?
<pstolowski> uhm
<mvo> zyga-ubuntu: we only have a ppc64, not powerpc itself
<mvo> zyga-ubuntu: is that what you mean?
<zyga-ubuntu> aha, I see
<zyga-ubuntu> mvo: I recall you ran into an issue that only affected a weird arch during the last cycle
<zyga-ubuntu> and I was wondering if we missed or ignored the adt data
<zyga-ubuntu> or if we simply didn't have any data
<zyga-ubuntu> pstolowski: hey, I looked at your huge branch
<zyga-ubuntu> pstolowski: that was a painful patch to write, I presume
<pstolowski> zyga-ubuntu, a little bit, yes ;)
<pstolowski> zyga-ubuntu, and it breaks every now and then when something new lands ;)
<mvo> zyga-ubuntu: hm, I need to look into the PRs/error logs, I don't remember that one off-ahdn
<zyga-ubuntu> mvo: can you please look at the general design of https://github.com/snapcore/snapd/pull/3810 since you requested those changes
<mup> PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<zyga-ubuntu> mvo: I will then work with pawel on reviweing that branch and landing it
<pstolowski> zyga-ubuntu, and it breaks every now and then when something new lands ;)
<pstolowski> ups, wrong window ;)
<pstolowski> zyga-ubuntu, thanks for looking at this
<mvo> zyga-ubuntu: yeah, in a short while, just lookiing into 2.28 breakage on artful/i386,s390x
<mvo> zyga-ubuntu: fwiw s/requested/suggested/
<zyga-ubuntu> mvo: sure, no rush and indeed :)
 * zyga-ubuntu managed to link statically now
<zyga-ubuntu> whee :)
<zyga-ubuntu> mvo: are you looking into "./get-deps.sh: 10: ./get-deps.sh: go: not found" ?
<mvo> zyga-ubuntu: yes, that too
<pedronis> mvo:  will not running the unit tests everywhere increase our test run time too much ?
<mvo> pedronis: that might be a problem yes, i can try to figure out other ways to run them but right now there is a gap in our testing, e.g. unit tests failed on trusty but we don't test for this anywhere
<mup> PR snapd#3848 opened: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3848>
<mvo> meh, stuff like: "/tmp/go-build037063724/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re13f596af8 for symbol `' out of range
<mvo> exit status 127" (in the zesty/ppc64el build) make me weep hard
<pedronis> pstolowski: is #3810 so big because of the changes in snap/ ?
<mup> PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
<pedronis> were they strictly necessary?
<zyga-ubuntu> mvo: hmmm, symbol "empty string"
<pstolowski> pedronis, yes, it's because the change in snap/; the change is trivial but affected lots of tests
<pedronis> pstolowski: is it needed though?
<pedronis> it doesn't make much sense on its own
<pstolowski> pedronis, not strictly neccessary, but mvo suggested a nice change to avoid code repetition in the new API
<pedronis> yes, but that's internal
<pedronis> PlugSlotData vs plugSlotData
<pedronis> a world of difference
<pedronis> yes, you noticed by needing to change so much
<pedronis> pstolowski: I don't think mvo suggestion extended to snap, it was about the new stuff
<mup> PR snapd#3849 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3849>
<mvo> pedronis: when I looked into this iirc I had to exend it to snap/ but I only looked briefly its probalby worth exploring options here
<pstolowski> pedronis, it did, I merged mvo's branch with these refactoring changes, I fixed all the tests
<pstolowski> pedronis, perhaps I accepted it too quick, not denying that, if this can be avoided then I'm ok to revert/redo this
<pedronis> pstolowski: well I data *snap.PlugSlotData
<pedronis> will probably confuse us
<pedronis> because it recreates the problems we are trying to get away from
<pedronis> s/I data/I think data/
<pedronis> we should really treat the Info stuff as immutable
<mup> PR snapd#3848 closed: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3848>
<pedronis> pstolowski: to be clear I'm not against a shared plugSlotData in the new stuff, I'm not thrilled by snap.PlugSlotData and even less so by sharing it with plugSlotData by reference
<mup> PR snapd#3849 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3849>
<mup> PR snapd#3850 opened: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3850>
<mup> PR snapd#3851 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3851>
<pedronis> pstolowski: using mutated or not copies of *Info is our current confusion/problem
<pedronis> this particular changes doesn't seem to address that
<pedronis> pstolowski: I expect some changes coming from addressing that, but the massive rework seems to not help to me
<mvo> pstolowski: sorry for having made your life more complicated
<pedronis> pstolowski: I'm happy to have a HO if this is unclear
<pedronis> mvo: did you suggest to change snap.PlugInfo ?  I saw your suggestion about the new stuff, not those
<mvo> pedronis: when I played with code I did add a snap.PlugSnapData so that it could be embedded into the new stuff
<mvo> pedronis: maybe that was wrong
<pedronis> yes, it is
<pstolowski> pedronis, thanks for the feedback, really appreciate it! i'm often missing the big picture when it comes to how the structures we have fit rogether
<pedronis> I mean, it's not wrong
<mvo> pedronis: I was mostly trying to the duplication
<pedronis> but it tempts bad stuff
<pstolowski> mvo, don't worry :)
<pedronis> and it's a massive rework
<pedronis> that muds things
<mvo> pedronis: ok, do you see another way to avoid the duplication or is that just something we need to accept if we don't want to go down the other route?
 * mvo hasn't looked into the branch since a couple of days so will have to refresh his memory
<pstolowski> pedronis, i need to revisit this branch to refresh my brain, currently finishing some other PR; will let you know later if I need more clarification
<pedronis> mvo: pstolowski: IÂ think the main point is that NewPlug/SlotData need to really copy stuff out of Info
<pedronis> and then we need to live with the consequences
<pedronis> of that
<pedronis> right now because we didn't have dynamic attrs
<pedronis> we use *Info either fromt he repo or the snap
<pedronis> in slightly mixed up ways
<pedronis> we cannot afford that once we have dynamic attrs
<zyga-ubuntu> hmm
<pedronis> so we do need big changes, but more about how the repository store stuff
<pedronis> zyga-ubuntu: the PlugInfo and SlotInfo in repo are sanitized, the ones from the snaps aren't, it seems we have no bugs yet, but super unclear if just chance
<pedronis> anyway the use of the same type makes unclear why using the wrong one would be a problem
<zyga-ubuntu> pedronis: indeed
<pedronis> given that go has types we might as well use them to our advantage, especially now we are adding the complexity of dynamic attrs
<pstolowski> pedronis, got you. that's a good point
<pedronis> pstolowski: notice that we still need to think a bit about Plug vs PlugInfo vs PlugData
<pedronis> pstolowski: as I said happy to chat a bit about options when you have time
<Chipaca> o/
<mup> PR snapd#3852 opened: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
 * zyga-ubuntu reboots
<pedronis> Chipaca: hi
<pstolowski> pedronis, ack, thanks
 * zyga-ubuntu walks his son to school, brb
<Jasem[m]> Hello, I think I found an issue with snap and AppArmor, I tried sending an email to the list
<Jasem[m]> but it bounced back
<mvo> mwhudson: hey, I ran into /tmp/go-build407282108/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re110ef6af8 for symbol `' out of range in zesty/ppc64el package building. that looks very much like bug 1711935 which you marked fix released but I see it. if it is PIE related I can try to disable PIE on ppc64el maybe?
<Jasem[m]> anywhere else?
<mup> Bug #1711935: failing to start on ppc64el: R_PPC64_ADDR16_HA 277ef287d88 for symbol `' out of range <containerd (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1711935>
<Chipaca> Jasem[m]: the forum?
<Jasem[m]> Chipaca: ok will try there
<Chipaca> Jasem[m]: you're in the right place for the chitchat around snapd, for what it's worth
<Jasem[m]> Chipaca: well, it's an odd problem. I made a snap package for KStars about a year ago, it includes INDI server. So I forgot about the package and today I found that my INDI server (not related to the one in the snap package) was crashing. Turns out it was permission issue, and it only when away to I removed the snap from the system.
<Jasem[m]> Chipaca: so for some reason, the AppArmor stuff was being applied to things outside of the snap in the reuglar system
<Chipaca> Jasem[m]: that sounds awfully like one of those "that's not how this works" memes
<Chipaca> Jasem[m]: how does the client talk to the server?
<Jasem[m]> Chipaca: you can image frustration of troubleshooting this.. 2 hours I wasn't going anywhere it was driving me insane. I think a recent update to snap or apprmor changed things. I forgot about the snap package installed last year as I was testing snap packaging.
<Chipaca> Jasem[m]: yes, i can imagine!
<Chipaca> Jasem[m]: did you see my question?
<Jasem[m]> Chipaca: the server crashes after a few seconds without any client
<zyga-ubuntu> Jasem[m]: hey
<zyga-ubuntu> JamieBennett: can you please open a bug or a forum thread?
<zyga-ubuntu> er
<zyga-ubuntu> Jasem[m]: ^
<JamieBennett> heh, I can ;-)
<zyga-ubuntu> Jasem[m]: sorry, I meant you above :)
<zyga-ubuntu> Jasem[m]: do you see any apparmor denials? dmesg | grep DENIED
<Jasem[m]> zyga-ubuntu: I didn't check that, but problem went away after the kstars snap was removed.
<Jasem[m]> Ok I don't see any DENIED related to indiserver.
<pedronis> Chipaca: do you want to give a look  at #3780 again, it was rebased  , also #3727 needs a 2nd review
<mup> PR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<Chipaca> pedronis: also a deconflict
<zyga-ubuntu> Jasem[m]: please try to reproduce the issue, collect any data such as journal logs and denials or messages from the service
<zyga-ubuntu> Jasem[m]: and let's chat
<Chipaca> pedronis: was looking at 3870 already
<zyga-ubuntu> Jasem[m]: in the end lets please open a forum topic with all the facts you managed to collect
<pedronis> mvo: #3727 needs a deconflict it seems
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<Chipaca> pedronis: opinions on snapd#3845?
<mup> PR #3845: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>
<Chipaca> it's got 1.66â¦ reviews already fwiw
<pedronis> I'll look in  a sec
<mvo> Chipaca: I can have a look too
<Chipaca> mvo: you already did, twice, and you're doing the release
<mvo> pedronis: I will work on my branches next
<mvo> pedronis: still fighting some annoying issues with our matrix of (arch,release)
<mvo> Chipaca: good point
<mvo> Chipaca: fwiw, looks very nice, thanks for improving the tests btw
<zyga-ubuntu> mvo: btw, does that mean we do 2.27.6 with build fixes?
<pedronis> Chipaca: looked at it, mostly comments on comments and names
 * Chipaca looks
<Chipaca> pedronis: Commit/Cancel? Commit/Abort?
<Chipaca> mvo: WDYT?
<Chipaca> mvo: (re pedronis' comment that Finalize is bad because Go uses it for something else, and we already use Commit for things that can't be re-committed -- and sql transactions usually can't commit twice)
<pedronis> Chipaca: usually for files the thing you can do many times is "flush"
<Chipaca> mhmm
<Chipaca> which isn't this
<Chipaca> that's called Sync in go, and you can do that on these
<pedronis> what where you thinking about commit and many times?
<pedronis> s/where/were/
<Chipaca> pedronis: mvo said he'd expect to be able to call Commit piecewise
<pedronis> I don't know why
<pedronis> anyway either Cancel or Abort are fine by me
<Chipaca> pedronis: I think it's the bread. Germans do crazy stuff with the bread.
<pedronis> Chipaca: piecewise shouds like flush
<pedronis> except here we commit to the name
<pedronis> with the rename
 * Chipaca awaits mvo's feedback
<mvo> Chipaca, pedronis: maybe its because of vcs commit that I had a mental "commit, commit" model
<mvo> the bread is another possiblity
<mvo> Chipaca, pedronis: "submit()"? "finish()"? but I have no super strong objection against commit(), just felt a bit odd to not be able to repeat it
<pedronis> we have already two Commit in the codebase
<Chipaca> nobody liked Enfeoff()
<pedronis> my brain admittedly happily keeps vcs commit and  transactional commit separate
<mvo> ok, commit it is then
<xnox> does core 16, all-snappy systems, use resolved in xenial?
<ogra_> ogra@nanopi-air:~$ ps ax|grep resolv
<ogra_>  1618 pts/0    S+     0:00 grep --color=auto resolv
<ogra_> xnox, ^^ does that answer it ? :)
<xnox> ogra_, no, but this would $ systemctl status systemd-resolved
<ogra_> xnox, we do use networkd
<Chipaca> pedronis: I've flip-flopped over having AtomicWriter being the real thing, and it being an interface. Advantage of the interface is that it's a lot easier to document. Advantage of the real thing is that e.g. you get Sync() for free (because I'd embed *os.File)
<Chipaca> pedronis: do you have an opinion on that?
<ogra_> ogra@nanopi-air:~$ systemctl status systemd-resolved
<ogra_> â systemd-resolved.service - Network Name Resolution
<ogra_>    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
<xnox> ack, thanks
<mup> PR snapd#3850 closed: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>
<mup> PR snapd#3851 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3851>
<pedronis> Chipaca: the interface is ok
<pedronis> Chipaca: do you have a use case for doing more File stuff ?
<Chipaca> pedronis: no
<Chipaca> pedronis: pushed an iteration
<Chipaca> pedronis: most notably i've rejiggered commit so the only thing that can fail once the file is in place is the final dir sync
<Chipaca> pedronis: and i've chosen to silently ignore that error
<Chipaca> (if power dies after a failed dir sync, you either have the old or the new thing -- atomicity is there)
<Chipaca> and, reasons for a failing dir sync after everything else worked, are really hard to come up with without it involving filesystem failure
<pedronis> Chipaca: wondering a bit about the flags, should we have a mutex?   are there patterns where Cancel for example could come from a different goroutine than Commit?
<Chipaca> pedronis: one of the cancels will fail with one of the appropriate errors
<Chipaca> or one of the cancel / commits
<Chipaca> er
<Chipaca> let me look at it just to be sure, but i _think_ all you get is a werider error than is user-friendly
<Chipaca> (granted that the _expected_ outcome of calling cancel and commit in different goroutines is unknown)
<Chipaca> gah
<Chipaca> i've done that thing again where i think just because something is a boolean, concurrent accesses will only get booleans
<Chipaca> pedronis: would it be fair to say, if you use these things from different goroutines, add a mutex?
<pedronis> yea, it's fair
<pedronis> maybe just a matter to write it somewhere
<Chipaca> pedronis: OK. If that's the only issue with the code as it stands, I'll address it in the first PR that actually uses these :-)
<Chipaca> BTW last night I found a place where we're doing something similar to the old "compile a constant regexp every time a function is called"
<Chipaca> (that'll be addressed in the first PR that uses this as well)
<pedronis> Chipaca: any particular reasons to stop returning the dir.Sync() error?
<Chipaca> pedronis: there's nothing useful you can do with it
<Chipaca> you can't cancel the commit
<Chipaca> you can't re-commit
<pedronis> you disk is bad and you go ahead
<Chipaca> the filesystem is probably consistent, but fucked because otherwise why would it error
<Chipaca> pedronis: stated like that, it sounds like maybe I shouldn't
<pedronis> it's  a change
<pedronis> if you are worried about Cancel
<pedronis> you can save the error
<pedronis> and return that instead of
<Chipaca> pedronis: but if I do I feel compelled to make the wording around the interface a lot more convoluted than is probably needed
<pedronis> just cannot canccle
<Chipaca> I'm going to go make lunch and think about it
<pedronis> ok, anyway not giving it a +1 yet
<pedronis> do you need an explicit -1 ?
<zyga-ubuntu> jdstrand: hello!
<zyga-ubuntu> jdstrand: if you are around today, can you please have a look at https://github.com/snapcore/snapd/pull/3621 again, I have added a child profile and massaged things into compliance build-wise
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand: as a small note, we now have snap-exec and snap-update-ns as statically linked executables
<zyga-ubuntu> jdstrand: I kept the are-we-reexecing-function in the PR even though I don't need it yet because it may come in handy later
 * zyga-ubuntu sighs 
<Chipaca> pedronis: another attempt :-)
<jdstrand> zyga-ubuntu: hey, I'll try to get to it. I need to figure out the cgroup issue and haven't been through my inbox yet, but it is very high on the list
<pedronis> Chipaca: just reverted that bit of change?
<Chipaca> pedronis: and added docs
<jdstrand> Jasem[m]: I'll just reiterate what zyga-ubuntu said and ask for more information (eg any security denials in journactl at the time the application was crashing)-- the security confinement shouldn't leak out to other processes in the way you described, and if it did, there would be logs
<jdstrand> Jasem[m]: depending on the architecture of how the client interacts with the server, or if you had a deb client and a snap client, or a deb server and a snap server installed at the same time, then there could be conflicts (not necessarily security sandbox related)
<zyga-suse> jdstrand: thank you, I'm trying to sort out last packaging quirk there
<pedronis> Chipaca: matt changed #3780, it looks reasonable/consistent now, don't know if you want to look again
<mup> PR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
<Chipaca> pedronis: i'll take a look
<pedronis> jdstrand: hi, this seems something for you:  https://forum.snapcraft.io/t/sandboxing-in-general/1984
<jdstrand> pedronis: yep, just came online, I'll get to it in a bit
<jdstrand> pedronis: thanks
<ogra_> sborovkov, https://github.com/snapcore/pi2-gadget/pull/9 ;)
<mup> PR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>
<nsg> For fun last weekend, I wrote a little snap store/repo. I downloaded the signed hello-world snap from the official store and was able to install it from my store. The question is, would it be possible to trust my own sign key and selfsign my own snaps and install them from my local store? Or is there something hardcoded in snapd that would prevent that?
<zyga-ubuntu> nsg: there is a chain of trust from the root key, yes
<cachio> mvo, did you see the error in the base snaps test?
<zyga-ubuntu> nsg: there's a forum thread about that today, I would suggest you catch up first
 * zyga-ubuntu needs to pick up his son from school, brb
<nsg> zyga-ubuntu: will do!
<mvo> cachio: I saw it but have not looked deeper yet, I had some vague idea, let me look again
<mvo> cachio: I spend my morning with seccomp and similar failures in the unittests on s390x and pppc64el :)
<cachio> mvo, ahh, ok
<xnox> mvo, btw, i am ponderring if the new libssecomp should be backported from artful to xenial, to support newer kernels etc.
<xnox> and s390x
<cachio> mvo, np, I am still researching the issues that I see in the results
<mvo> cachio: the error looks a bit like something is wrong with the branch that ubuntu-core-16-arm-32 runs from, the snapbuild version looks outdated
<cachio> mvo, after I finish beta for 2.28 I'll create a job to run the tests on core i386 and amd64
<ogra_> jdstrand, regarding the opengl stuff, note that mir works fine with the fixed udev rule (but we perhaps still want to allow access to these platform paths for other apps that rely on them)
<jdstrand> ogra_: yeah, read the thread. those other paths seem reasonable for the interface though
<jdstrand> ogra_: thanks
<ogra_> :)
<cachio> mvo, I already reviewed that but it is using the release/2.28 in all the cases
<cachio> mvo, and the version that is running in the devices is correct too
<mvo> cachio: aha, thanks. strange, I have a look at the snapbuild code, wonder what is going on there
<nsg> hm, I can't find any forum tread from the last day discussing snap selfsigning ... I'm missing something? Any pointers of what to search for? :)
<mvo> cachio: a PR for you: https://github.com/snapcore/spread-cron/pull/41 :)
<mup> PR spread-cron#41: trigger builds for zesty,artful,trusty as well as xenial <Created by mvo5> <https://github.com/snapcore/spread-cron/pull/41>
<nsg> (I'm up2date on the "External repositories" thread, if that was the one you was talking about.)
<cachio> mvo, looking
<mup> PR snapd#3853 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3853>
<sborovkov> ogra_: saw the PR, does this one work on the first boot?
<niemeyer> mvo: "add --last to snap abort and snap watch"
<niemeyer> mvo: Slightly surprised to see this one in the notes
<niemeyer> mvo: Is it just --last, or --last=foo?
 * niemeyer checks
<ogra_> sborovkov, on every boot (including the first) ... i added a pre-made snap to your bug for testing
<mvo> niemeyer: its "snap --last={install,refresh,remove,try,...}
<mvo> niemeyer: so yes, sorry for that, that should have at least an example
<niemeyer> mvo: Ah, okay, no worries.. I'll put an example in
<Son_Goku> zyga-ubuntu: please test the new snapd release for Fedora
<Son_Goku> I'd like for it to make its way through rather quickly
<sborovkov> ogra_: when you say pre-made snap, you mean gadget snap? Anyway I will pull it and try it out. Thanks a lot! Now there is much better user experience with this. We got a bunch of bugs filed when people ran the image for the first time and it was stuck on login page for a very long time, everone was writing to us that it's broken
<mup> PR snapd#3853 closed: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3853>
<ogra_> sborovkov, yes, a gadget snap with the PR included
<ogra_> sborovkov, fro userspace you can additionally use the psplash snap to run as a service
<ogra_> the system will switcxh over from one splash to the other
<sborovkov> ok that's great. this PR is for pi2-gadget only though?
<mup> PR snapd#3854 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>
<mvo> cachio: fwiw, I can reproduce the error, looking now
<sborovkov> ogra_: and I see that while pi3-gadget is still getting new commits, it does not have your commit that allow to build uboot from source for instance? Are they kinda diverging now?
<ogra_> sborovkov, pi2 and pi3 both have the build-from-source commit ... i dont have the splash PR ready for pi3 yet though
<mvo> cachio: I think I know what is going on - we need an update to test-snapd-snapbuild
<sborovkov> ogra_: ah, alright sorry. How different is pi3 gadget snap? If I tried to apply your changes from pi2 PR would it work? We only use pi3 :-(
<mvo> cachio: I'm on it
<cachio> mvo, nice
<ogra_> sborovkov, oops, i should have started with pi3 then (i actually thought you do pi2 ... heh) ... i guess it should apply
<cachio> mvo, I am going to push a fix for lxd tests
<cachio> mvo, testing it now
<mvo> cachio: sweet, thank you!
<cachio> mvo, it is quite slow here
<mvo> cachio: yeah, sorry for that :/
<mvo> cachio: you raised concerns in the PR
<cachio> mvo, np :)
<mvo> cachio: happy to move it to the nightly suite or something, I just think we need it tested :)
<mvo> niemeyer: good news, CE already did the automated test for 2.28~rc1
<cachio> mvo, yes, the idea is to run the whole test suite inside a vm with ubuntu core
<cachio> I have to see how to reuse the nested suite
<zyga-ubuntu> Pharaoh_Atem: hello, gladly, I'll test it ASAP
<zyga-ubuntu> nsg: not about self-signing but about federated / external repositories
<zyga-ubuntu> nsg: that topic is related so please look for "external repositories"
<mvo> cachio: the base test should work now on the external backends, I will rerun on my sysem
<mvo> system
<cachio> great
<mup> PR snapd#3845 closed: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3845>
<nsg> zyga-ubuntu: "the store signs them with an archive key so they can be verified (assertions)" ... I have seen that code from the source but my go skills are not the best so it's a little hard to follow. I guess there must be a public or a key signature somewhere on my computer and/or inside the snapd binary to validate the signature? My question is, where is it and can it be replaced with my own?
<niemeyer> mvo: \o/
<nsg> hm, maybe it's better to ask that instead in the thread... I will do that later :)
<niemeyer> mvo: I'm about half-way though the list, writing a section for each item
<niemeyer> mvo: Will have lunch now and do the rest afterwards
<zyga-ubuntu> nsg: its baked into snapd binary
<zyga-ubuntu> nsg: you can replace it but then none of the existing snaps will validate
<mvo> niemeyer: thanks a lot
<nsg> I see, so I need to build my own snapd then. In this case it's a feature that no other snaps validate :) (need to re-sign the core snap of course). I will see if I take the time to do this (probably not) ... the alternatives are just "wget ... && snap install --dangerous ..." but that sounded so hacky and I liked to avoid it by making a store for my self.
<ogra_> nsg, it *is* super hacky, dont do it :)
<nsg> yeah, but the other alternatives are to not use snaps at all :\
<nsg> need to have a local repo
<zyga-suse> nsg: why do you need this?
<zyga-suse> nsg: we understand that some people feel strong about it but most people don't need a local repo today
<zyga-suse> nsg: you can create private snaps today
<nsg> I like to use snaps at work for example, I must host them inside the network
<nsg> For my personal things, private snaps are just fine
<zyga-suse> I see
<ogra_> mvo, btw, if you are interested ... https://github.com/snapcore/pi2-gadget/pull/9 is the first thing that exercises "split initrd" (see the uboot.env.in bit)
<mup> PR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>
<nsg> We did consider just to package debs and deploy them inside lxd containers but snaps was a much better solution for our usecase so I tried to work my self around the problem :)
<zyga-suse> nsg: this is not available as a feature yet, it will come out of the commercial side of snapd, where people can just get a local store and point their devices there, that store could live on your land and also act as a mirror/filter for the public snap store
<ogra_> i have another PR pending (that sits on top of this one) to actually load a modules.img
<zyga-suse> nsg: for the moment you can just snap install --dangerous them
<mvo> ogra_: thanks, I check it out later, I haven't managed to find time for it yet (but I did see it)
<zyga-suse> nsg: that just skips the assertion check
<ogra_> mvo, yeah, it is more FYI, i can get reviews from oothers
<ogra_> works really well though
<mvo> ogra_: nice to hear
<ogra_> and i can easily do all the gadget bits ahead of time before the snapd changes happen
<mvo> cachio_lunch: just tests tests/main/base-snap on external: and it seems to be happy now
<jdstrand> tyhicks: hey, do you have a moment to talk about one of the next steps on seccomp deny/log rather than kill?
 * zyga-ubuntu would love to listen
<nsg> zyga-suse: if you can tell, what time frame do you think we talk about here? --dangerous can be a acceptable solution if there is a better solution over the horizon. But if we talk 2019+ it's probably better just to stick to deb:s.
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
<mup> PR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
<mup> PR core#55 opened: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>
<zyga-suse> nsg: gustavo recently posted the snapd roadmap: https://forum.snapcraft.io/t/the-snapd-roadmap
<diddledan> trying to run snapcraft container builds: - Copy snap "core" data (cannot copy "/var/snap/core/2774" to "/var/snap/core/2774": failed to copy all: "cp: cannot stat '/var/snap/core/2774': No such file or directory" (1))
<zyga-suse> nsg: having said that this is a store side feature, for that there's no roadmap that I know of
<diddledan> that 2774 is a folder which is empty
<zyga-suse> nsg: I suspect this is a ~2018 window as I hear about various commercial projects with similar needs
<zyga-suse> nsg: so please stick to snaps and let's work together on making this as nice as possible for all the use cases
<zyga-suse> diddledan: that's something Chipaca may know about
<diddledan> full log: http://paste.ubuntu.com/25472718/
<Chipaca> diddledan: known bug, i'm afraid
<diddledan> ergh
<Chipaca> diddledan: (fixed in the latest)
<Chipaca> diddledan: not sure where snapcraft comes in to it though
<zyga-suse> man, it feels good to be on a 100Mbit connection
<Chipaca> diddledan: that is: the operation that failed fails because of a known, fixed, issue
<Chipaca> diddledan: but it's an operation that doesn't happen "naturally"; what triggered this?
<diddledan> the trigger was : SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
<ogra_> zyga-suse, do you hear the "WOOSH" when sending and receiving files ?
<diddledan> using snapcraft, version 2.33+git53.69dceb8
<zyga-suse> ogra_: I don't have to count the bits anymore
<ogra_> :)
<Chipaca> diddledan: what does "snap version" output?
<diddledan> in the container or locally?
<Chipaca> diddledan: both!
<pstolowski> davidcalle, hey, i've just tested the little problem we discussed with artful. i still cannot get the expected snapcraft build output - see http://pastebin.ubuntu.com/25472726/
<pstolowski> davidcalle, any chance you forgot to push simething to your repo?
<nsg> zyga-suse: yup, I have read that post (a lot if great things in there!), 2018 sounds good. For my simple use case just an easy way to change the key would be fine to... no need of a new store (I can write something simple for that). I will try to convince my team :) Thanks for the info!
<davidcalle> pstolowski: I've tried with a clone of this repo
<diddledan> locally: http://paste.ubuntu.com/25472730/ container: https://paste.ubuntu.com/25472734/
<zyga-suse> nsg: thanks, please stay around and share your experiences
<Chipaca> diddledan: what are the containers?
<diddledan> whatever snapcraft spins up
<diddledan> lxd
<davidcalle> pstolowski: looks like you are running snapcraft from the snap dir, should be from the root
<mup> PR snapcraft#1313 closed: Meta: Version from deb <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1313>
<Chipaca> diddledan: ok, may i suggest you take all this info and open a forum topic? I suspect snapcraft is doing something screwy and triggering the bug, and while it'll go away in the next snapd release, maybe it shouldn't be doing that thing
<pstolowski> davidcalle, oh my, that's it
<davidcalle> pstolowski: aha :)
<pstolowski> davidcalle, why doesn't it complain?
<zyga-suse> ok, I think I know how to massage the %gobuild macro on opensuse into compliance
<davidcalle> pstolowski: because snapcraft.yaml can be at the root as well, so it's a valid project dir in itself
 * davidcalle note to self: add a readme!
<Chipaca> 		err = osutil.AtomicWriteFile(dst, nil, 0644, 0)
<Chipaca> WHAT
<Chipaca> why
 * Chipaca thinks
<Chipaca> ah, ok
<Chipaca> :-)
<pstolowski> davidcalle, interesting
<diddledan> Chipaca: https://forum.snapcraft.io/t/snapcraft-container-builds-triggering-a-bug-in-snapd/1990
<pstolowski> davidcalle, anyway. just got it built on artful now with hooks as expected. it installed cleanly. it failed when I made it to fail explicitely (I broke its install hook for a test). since i'm uncessful in reproducing, I may need your state.json file
<davidcalle> pstolowski: should I reproduce the issue and send it over to you?
<pstolowski> davidcalle, nb, we also have a spread test (i.e. a test with real VM) with a test snap with install hook and it has been passing too. not sure what's going on, but perhaps you got yourself into a state which somehow breaks it
<pstolowski> davidcalle, yes, that would be helpful. do you only see it on your box where you already accumulated a bit of history with snapd, or are you able to reproduce with a clean VM?
<tyhicks> jdstrand, zyga-suse: hey - I just got out of a meeting and can chat about the seccomp changes now
<zyga-suse> great
<zyga-suse> tyhicks, jdstrand: I'll adapt to any environment
<zyga-suse> personally I think we can do it on IRC here
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3850#pullrequestreview-60647180
<mup> PR #3850: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>
<jdstrand> mvo: (and hi)
<jdstrand> tyhicks: ok
<mvo> jdstrand: hi, I have no idea why it regresses, I did not dig into it yet, there was a ton more but I can do so tomorrow
<jdstrand> tyhicks: basically, my understanding is that the upstream kernel changes will be in 4.14 (the next stable kernel), there will be patches for libseccomp and seccomp-go
<mvo> jdstrand: maybe its just libseccomp ?
<jdstrand> mvo: maybe it is seccomp-go? I don't know how it interfaces with libseccomp
<zyga-suse> jdstrand: I think the changes will be in seccomp-go and libseccomp (unless they already landed in libseccomp)
<tyhicks> jdstrand: correct - the libseccomp PR is here: https://github.com/seccomp/libseccomp/pull/92
<mup> PR seccomp/libseccomp#92: Expose improved kernel logging features through libseccomp <Created by tyhicks> <https://github.com/seccomp/libseccomp/pull/92>
<mvo> jdstrand: I can dig into it tomorrow morning
<tyhicks> jdstrand: once that gets an ack, I can work on the libseccomp-golang patches
<jdstrand> mvo: zesty and artful have libseccomp 2.3.1. they also have kernel > 4.3. I didn't look at the glibc bits
<jdstrand> mvo: thanks
<tyhicks> the libseccomp-golang changes should be quick to code up
<jdstrand> tyhicks: ok, so in terms of using this in snapd, it sounds like we could do some conditional logic in snapd to detect if the feature is available, and if it is, use EPERM, else kill
<tyhicks> jdstrand: that's correct
<jdstrand> tyhicks: which is where I think we last landed
<tyhicks> jdstrand: libseccomp/libseccomp-golang will have ways for applications to test if the kernel supports the new seccomp LOG action and the new seccomp LOG filter flag
<zyga-suse> jdstrand: right, I asked about that aspect but I don't recall an answer; how can we check for this feature at runtime?
<tyhicks> zyga-suse: I responded to your question in the bug report an hour or so ago (I just returned from vacation today)
<zyga-suse> aha, perfect, I'll catch up with email then
<zyga-suse> thank you
<jdstrand> tyhicks: seeing that setpriority issue, I wonder if perhaps we should unconditionally use EPERM and conditionally set up logging based on kernel. kernel snaps could have this kernel patch and just start benefiting, but everything acts the same in terms of the snap developer
<tyhicks> jdstrand: yes, I think that's the way to do it
<jdstrand> tyhicks: perhaps there is a config option to kill instead of EPERM for systems that prefer that behavior
<tyhicks> jdstrand: IMO, I'd keep that config option in our back pocket in the case that someone asks for it
<jdstrand> tyhicks: like, maybe it is part of snap config for the core snap or something
<tyhicks> seems like added complexity that doesn't have any demand, atm
<jdstrand> tyhicks: I worry about silent denials
<tyhicks> jdstrand: good point
<jdstrand> tyhicks: a way to do this would be the kernel sees if it can log with EPERM. if it cannot, it logs this with a link to the forum. the forum tells what patch is needed for the kernel, and how to set the old behavior (snap set core seccomp=kill) or something
<jdstrand> tyhicks: this would get info to kernel developers and allow users to configure the system in a way that they could see the denials
<tyhicks> jdstrand: yeah, that could work
<jdstrand> tyhicks: so that would be a small change to snapd to read whatever the core 'snap set' would do. it could be that snapd could evaluate an env var SNAPD_SECCOMP=kill (or somthing), and the 'snap set core' simply updates snapd's systemd unit
<tyhicks> jdstrand: do you know if there's a bug for EPERM-by-default? I could only find a bug for "complain mode" (LP: #1567597)
<mup> Bug #1567597: implement 'complain mode' in seccomp for developer mode with snaps <Snappy:In Progress by tyhicks> <libseccomp (Ubuntu):Confirmed for tyhicks> <linux (Ubuntu):Fix Committed by tyhicks> <https://launchpad.net/bugs/1567597>
<tyhicks> jdstrand: I think that's a pretty clean design
<jdstrand> tyhicks: that is the only bug I know of
<jdstrand> tyhicks: I would suggest creating a forum topic so that others from the snapd team can comment on the design
<tyhicks> jdstrand: that's a good idea but I'm not sure I'll be able to do that today
<jdstrand> tyhicks: doesn't have to be today :)
 * tyhicks nods
<jdstrand> tyhicks: anytime before you start implementing things :)
<jdstrand> tyhicks: the setpriority topic just got me thinking, so wanted to bring it up snce it seems like next steps are coming soonish
<om26er> Hi! whats the practice for not having hard-coded version number in snapcraft.yaml ?
<nacc> om26er: in which sense? for your snap? or for dependencies?
<tyhicks> jdstrand: glad you brought it up so that at least a few of us are on the same page
<om26er> nacc: for my snap. In our project we have a central place where we append the version number. For our snap we still have to edit the snapcraft.yaml by hand.
<jdstrand> tyhicks: I summarized the conversation in trello
<jdstrand> tyhicks: np
<om26er> nacc: maybe something similar to what the core snap does ?
<nacc> om26er: i have no idea what it does/how, sorry
<ogra_> om26er, https://github.com/ogra1/strongswan-snap/blob/master/snap/snapcraft.yaml see "version-script:"
<ogra_> (you can freely use shell there)
<Chipaca> pedronis: quuestion for you that involves newlines in repairs :-)
<pedronis> Chipaca: yes?
<Chipaca> pedronis: how bad is it if a repair thing ends in a newline?
<Chipaca> pedronis: currently for example runnerSuite.TestNextNotFound checks that the repair ends in }
<Chipaca> and not }\n
<pedronis> where, what?
<pedronis> that's json?
<pedronis> is not a repair
<pedronis> Chipaca: which line in the test?
<Chipaca> 1179
<Chipaca> yes, the json
<Chipaca> pedronis: the problem is https://play.golang.org/p/i5tX-SBcTo
<Chipaca> switching runner.go to use AtomicFile instead of AtomicWriteFile results in an extra newline
<pedronis> and test files?
<pedronis> fails?
<Chipaca> yep
<pedronis> something is weird there, though?
<pedronis> extra newline, or a newline that is not there before?
<Chipaca> pedronis: http://pastebin.ubuntu.com/25473162/
<Chipaca> pedronis: depends which direction you're thinking in :-)
<Chipaca> pedronis: json.NewEncoder(aw).Encode(thing) adds a newline after encoding the thing, whereas json.Marshal(thing) does not
<pedronis> I'm not sure whether you are trolling me or what :)
<ogra_> lool
<ogra_> err
<ogra_> lol
<ogra_> (sorry lool )
<Chipaca> pedronis: I know nothing about repairs, so i thought i'd ask rather than just fix the tests
<pedronis> Chipaca: repair.json is  a repair status file,  as long as we can read it back we are happy
<Chipaca> pedronis: if we hash that json, i'd be breaking stuff
<pedronis> Chipaca: it's not a repair
<Chipaca> ok
<pedronis> it was actually called repair-state.json
<pedronis> at some point
 * Chipaca edits the tests with glee
<Chipaca> pedronis: sorry for the trolling (even though i think it wasn't intentional)
<pedronis> Chipaca: it's like /var/lib/snapd/state.json bu for repairs
<Chipaca> ok
<pedronis> for snap-repair
<pedronis> Chipaca: the repairs are saved as  r#.repair with a different AtomicWriteFile
<pedronis> and are assertions, those are pickier
<pedronis> but for sure don't end in }
<Chipaca> pedronis: ok :-D
<Chipaca> pedronis: actually, if you don't mind, I'll change the tests to parse the json and DeepEqual them instead of comparing them with a string? unless there was a reason to do it this way
<pedronis> it was expedient and seemed ok for the simple cases
<Chipaca> pedronis: agreed it's often simpler; just that now i've broken them with an unrelated change, so Â¯\_(ã)_/Â¯
<pedronis> we do something similar for some tests in overlord/overlord_test.go
<pedronis> Chipaca: notice that there's a helper that also writes states, freshState
<pstolowski> davidcalle, hey, can you check journalctl |grep -i "using default"
<Chipaca> pedronis: noted
<pstolowski> davidcalle, does it find anything?
 * Chipaca gives up after nearly drowning in a sea of map[string]interfaces{}
<om26er> ogra_: that did the trick, thanks.
<om26er> ogra_: how do you include the git commit info on edge channel only ?
<om26er> is there channel specific version script ?
 * Chipaca writes commit messages for zyga-suse to be proud
<mup> PR snapd#3855 opened: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <https://github.com/snapcore/snapd/pull/3855>
 * zyga-suse hugs Chipaca :-)
<zyga-suse> Chipaca: is the trim space coming from a new newline?
<Chipaca> zyga-suse: yes
<Chipaca> zyga-suse: because https://play.golang.org/p/i5tX-SBcTo
<pedronis> Chipaca: I'm probably dense today, but none of the cases in that PR seems to involve large data? what's the win?
<zyga-suse> aha
<pedronis> except snap-repair
<zyga-suse> pedronis: I think I requested that, it involves arbitrary sized data when command-not-found hints are involved
<zyga-suse> or was it also for section names and snap names?
<Chipaca> zyga-suse: yeah, but for a lot of these we know the size
<pedronis> yes, but that's not for the cases in that branch
<Chipaca> pedronis: mostly just exercising the new thing, so if you'd rather I didn't do it on most of these I won't mind
<pedronis> Chipaca: another interesting case is state.json itself  but that's mediated through state.Backend.Checkpoint taking []byte atm
<pedronis> Chipaca: given that's it's more code, I'm not super fond,  snap-repair though seems a valid one
<Chipaca> pedronis: ack
<pedronis> Chipaca: I'm a being insuffarable today?Â IÂ might be
<Chipaca> pedronis: not at all, it's a valid point
<Chipaca> the new api feels cleaner to me, but by so little, i don't mind
<Chipaca> as i say this was _mostly_ to exercise the api, see if it was sane
<zyga-suse> Chipaca: the only thing I found surprising is that defer cancel is unconditional, but is "trumped" by commit
<Chipaca> zyga-suse: i love that bit :-)
<pedronis> Chipaca: as I said exploring this vs state.json could be interesting, probably would need to a standalone thing
<Chipaca> pedronis: agreed
<Chipaca> state.json does its own thing though, i think?
<Chipaca> it uses CopyFile with the sync flag?
<pedronis> no,
<pedronis> but it's mediated through an interface
<pedronis> Chipaca: see overlord/backend.go:36
<pedronis> and  the code in overlord/state/state.go calling Checkpoint
<Chipaca> ah
 * zyga-suse is tired
<Chipaca> pedronis: ok, i'm going to close the PR, and then prune it and reopen it
 * Chipaca hugs zyga-suse 
<Chipaca> zyga-suse: why are you still here
<pedronis> thnak you
<zyga-suse> I want to solve the build blocker for suse
<zyga-suse> and dput snapd for sid
<mup> PR snapd#3855 closed: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3855>
<zyga-suse> aww, don't close that
<zyga-suse> I think it's a good change
<Chipaca> zyga-suse: i'll bring it back, for variable-sized things at least
<zyga-suse> ok
<Chipaca> zyga-suse: i might play with commands first, as that's the other big user (and it doesn't exist in code yet)
<diddledan> ogra_: I got a devmode ring working kinda. it doesn't work straight away, but instead requires you to execute two separate commands because it relies on a session dbus service which is handled by a separate executable, and even tho it's supposed to autostart it doesn't seem able to
<mup> PR snapcraft#1298 closed: jhbuild plugin: new plugin <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1298>
<diddledan> aha. strace to the rescue - it's trying to call dbus-launch which doesn't exist (needs a stage-package)
<mup> PR snapd#3780 closed: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3780>
<mup> PR snapd#3856 opened: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
<niemeyer> Pharaoh_Atem: ping
<Pharaoh_Atem> niemeyer: pong
<Pharaoh_Atem> niemeyer: what's up?
<Pharaoh_Atem> did you want something?
<niemeyer> Pharaoh_Atem: Heya
<niemeyer> Pharaoh_Atem: If/when you have a moment, I'd like to perform a quick test in the forum to aid in the bug report
<King_InuYasha> niemeyer: sure
<niemeyer> Okay, let me create a quick topic.. you'll probably get the notification again
<niemeyer> King_InuYasha: Done.. "Testing, please ignore"
<King_InuYasha> it'll take a minute before Discourse decides to send it
<King_InuYasha> heavens knows why...
<King_InuYasha> niemeyer: I didn't get any mail so far
<King_InuYasha> ah, here it is
<King_InuYasha> I just got it
<niemeyer> King_InuYasha: Alright, so now I'm sending a reply to it
<niemeyer> King_InuYasha: The question is whether you'll get that second one
<niemeyer> King_InuYasha: "And this is the reply."
<niemeyer> King_InuYasha: It should take about 5 minuts
<niemeyer> minutes
<niemeyer> King_InuYasha: Ah, and please don't visit the topic while the reply is there, otherwise the email is not sent no matter what.
<niemeyer> King_InuYasha: If you did see the reply through the web, let me know and I'll send another one.
<niemeyer> Son_Goku: ^
<Son_Goku> niemeyer: yeah, I clicked it
<Son_Goku> sorry
<Son_Goku> ...
<Son_Goku> but I got the reply anyway?
<Son_Goku> it just takes ~10 minutes
<Son_Goku> each email was sent 11 minutes after posting
<niemeyer> Son_Goku: Ah, you did get the reply?
<Son_Goku> yep
<niemeyer> Son_Goku: Super, thanks
<niemeyer> Son_Goku: Will include in the report
<Son_Goku> np
<niemeyer> Son_Goku: The mailing list mode apparently sends anyway, even if you visit the web UI then
<Son_Goku> :D
<niemeyer> Son_Goku: The normal notifications won't
<Son_Goku> I would seriously hope so
<Son_Goku> otherwise the ML mode is more broken than I thought
<niemeyer> Yeah, makes sense, at least in that case
<mup> PR snapcraft#1530 opened: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530>
<CodeMouse92__> I think I finally figured out my ongoing problem with snapping a kivy app...I need to pip install cython BEFORE pip installing kivy, which means the two need to be installed in separate steps...
<CodeMouse92__> I assume this means I need to create a second part, but I'm not 100% sure. Insight?
#snappy 2017-09-06
<mup> PR snapd#3857 opened: tests: fix lxd test for external backend  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3857>
 * Son_Goku grumbles
<Son_Goku> somehow, I just woke up at 1am :(
<Son_Goku> so... morning, I guess
<mvo> mwhudson: hey, thanks for helping with the ppc64el link error. do you know if there is any workaround?
<mvo> mwhudson: this is a blocker for 2.28 currently and I wonder what options there are
<mvo> mwhudson: nevermind, I think I found a workaround
<mup> PR snapd#3858 opened: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <https://github.com/snapcore/snapd/pull/3858>
<zyga-ubuntu> o/
<Son_Goku> meep
<Son_Goku> you know, I *really* don't like how go does compiler flags
<Son_Goku> it's a really dumb way to do things
<mvo> good morning Son_Goku (not actually morning for you I guess ;)
<mup> PR snapd#3841 closed: Do not emit cloud-init.disabled; cloud-init only runs if datasource is present <Created by raharper> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3841>
<mvo> and good morning to you zyga-ubuntu
<Son_Goku> [01:12:33 AM] Son_Goku	grumbles
<Son_Goku> [01:12:40 AM]  <Son_Goku>	somehow, I just woke up at 1am :(
<Son_Goku> [01:12:53 AM]  <Son_Goku>	so... morning, I guess
<Son_Goku> :/
<Son_Goku> this is what I get for going to sleep at 8:30pm
<mvo> Son_Goku: autsch!
<mvo> Son_Goku: that is going to be a coffee fueled day then :)
<Son_Goku> I was feeling pretty bad yesterday, so I took some Advil (headache medicine) and went to sleep
<Son_Goku> much earlier than I usually do
<Son_Goku> yeah, I might wind up drinking coffee today
<Son_Goku> I usually don't...
<mvo> Son_Goku: aha, yeah. hope you make it well through the day, I get cranky when I did not sleep enough
<Son_Goku> well, my work day begins in 6 hours
<Son_Goku> at which point, I'm going to be tired as hell
<mvo> yeah :)
<mvo> zyga-ubuntu: some easy reviews tagged with 2.28 *hint* ;)
<Son_Goku> mvo, not having pie across the board for snapd 2.28 kind of sucks, though
<mvo> Son_Goku: its just for two small helpers
<Son_Goku> snapd is made up of "small helpers" :P
<mvo> Son_Goku: and if you have !go1.7 you can simply reomove it
<Son_Goku> I wonder if this is even broken on Fedora 25 for ppc64le
<Son_Goku> we have go 1.7 there too
<mvo> Son_Goku: 2.28 probably is, 2.27 had a slightly different cflags/ldflags iirc for snap-seccomp
<zyga-suse> good morning :)
<Son_Goku> hmm
<zyga-suse> mvo: I'll have a look
<Son_Goku> 1.7.4 ~ 1.7.6
<Son_Goku> I guess there's only one way to find out...
 * Son_Goku logs into Fedora ppc64le test machines
<zyga-ubuntu> mvo: please check out https://github.com/snapcore/snapd/pull/3854#pullrequestreview-60818594
<mup> PR #3854: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>
<zyga-ubuntu> mvo: I need a re-review from jamie on https://github.com/snapcore/snapd/pull/3621 and I need to fix one opensuse packaing quirk (still fighting natively) and with merged master it should go green
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> mvo: but since it is tagged for 2.28, could you please have a look?
<zyga-ubuntu> mvo: note that we must wait for jdstrand's review for the child profile
<zyga-ubuntu> mvo: so if you want to release earlier, please drop it from the release
<mvo> zyga-ubuntu: I dropped it, I am happy to review but unfortunately it missed the 2.28 cycle
<mvo> zyga-ubuntu: I replied to 3621
<Son_Goku> mvo, I'm running through a test build of current master on Fedora 25 ppc64le
<Son_Goku> which has golang 1.7.6
<mvo> Son_Goku: nice
<Son_Goku> man... ppc64le is slow
<zyga-suse> ok
<zyga-suse> Son_Goku: it has to be, there is only one machine on the whole planet, everything else is virtualzed and over-committed ;-)
<Son_Goku> haha
<Son_Goku> you're probably not far off from the truth
<Son_Goku> at least I'm not debugging arm crap
<Son_Goku> I hate doing that
<Son_Goku> arm SoCs are even slower
 * zyga-suse just had a brilliant business idea
 * Son_Goku shoots the light bulb over zyga-suse's head
<zyga-suse> in some future where everything is running on one big machine, to sustain old business models we will still pay for traffic from A to B even though A is B,
<Son_Goku> oh god
<Son_Goku> I didn't shoot it fast enough
<zyga-suse> maybe we need a payasyougo.ko to track this
<Son_Goku> oh god damnit
<Son_Goku> someone switched the import path for cheggaaa/pb
<zyga-suse> yeah, it got switched to the canonical path
 * Son_Goku groans
<Son_Goku> zyga-suse, file a bug against the fedora cheggaaa/pb package
<Son_Goku> it needs the gopkg.in import path supported
<zyga-suse> ok, what should the bug report say?
<zyga-suse> just "please support the canonical import path via gopkg.in"?
<Son_Goku> yeah
<zyga-suse> hmm, I seem to have plenty of stale kernels
<zyga-suse> Son_Goku: ok, let me try to report that
<Son_Goku> describe what the new import path is, and why we need it added (snapd 2.28 requires it)
<zyga-suse> ok
<zyga-suse> Son_Goku: for rawhide?
<Son_Goku> mark the fedora release as rawhide, but ask for it to be added for all releases the package is provided for in the bug report
<zyga-suse> ok
<Son_Goku> poor Jan
<Son_Goku> he just updated cheggaaa/pb, too
<pedronis> mvo: hi, thanks for the review of the overlord.Mock PR
<Son_Goku> mvo: snapd git master compiles just fine today with Fedora 25 golang 1.7.6
<zyga-suse> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1488747
<Son_Goku> I'm surprised Fedora tests haven't started failing
<Son_Goku> or maybe they have and no one said anything
<Son_Goku> if that's the case, why bother having the tests... :(
<pedronis> mvo: #3727 seems to have a real unit tests issue now, probably related to some recent merge to master
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<Son_Goku> oh geez
<Son_Goku> it worked somehow
<Son_Goku> oh, no
<Son_Goku> let me guess
<Son_Goku> zyga-suse: are we giving a vendorized tarball to the snapd build in Fedora?
<zyga-suse> I don't think we do
<zyga-suse> (especially because that progress bar package was older in fedora and had UI corrputions)
<zyga-suse> *corruptions
<zyga-suse> and this was fixed in subsequent commits upstream
<Son_Goku> I mean in spread
<zyga-suse> in spread yes, we do
<Son_Goku> FUCK
<Son_Goku> damn it
<Son_Goku> the damned build tests are useless then
<pedronis> that is bound to be always helpful
<pedronis> *to not be
<Son_Goku> okay, then I need to break this
<Son_Goku> crap, this means I need to make it so patches apply cleanly with the vendor tarball
<Son_Goku> no one notices when builddeps are missing because of the stupid usage of vendor stuff
<zyga-suse> Son_Goku: indeed, that's a real problem
<zyga-suse> Son_Goku: our debian build suffers from the same thing
<Son_Goku> actually, I can just rm -rf vendor/* in %prep, I suppose
<Son_Goku> minus the vendor.json
<zyga-suse> Son_Goku: I think even with the vendor json, nothing needs that (just don't run get-deps)
<mvo> pedronis: thanks, checking
<Son_Goku> zyga-suse: remember that I need to be able to apply patches
<Son_Goku> and I'd like to not have to edit patches more than I already have to when backported
<Son_Goku> *backporting
<Son_Goku> it was somewhat annoying to backport userd to 2.27.5, but I did
<zyga-suse> what's the experience, does it work?
<Son_Goku> you tell me
<Son_Goku> the updates are sitting in bodhi right now
<Son_Goku> well, koji
<Son_Goku> for some reason they haven't made it to updates-testing yet
<mvo> Son_Goku: hm, zesty has go 1.7.4 wonder if thats related but aiui only 1.8 fixes the issue, I will dig
<Son_Goku> mvo: https://src.fedoraproject.org/rpms/golang/tree/f25
<Son_Goku> that should help
<zyga-suse> Son_Goku: how should I remove stale kernels from my fedora box?
<Son_Goku> did you change /etc/dnf/dnf.conf for installonlypkgs limit?
<Son_Goku> it should be set to 3 by default
<zyga-suse> rebooting
<zyga-suse> something broke so I booted into the recovery kernel and updated
<zyga-suse> and ...
<zyga-suse> the logo ...
<zyga-suse> and...
<zyga-suse> the same
<zyga-suse> I'll leave it for 5 minutes in case it's some timeut
<zyga-suse> but it looks broken :/
<Son_Goku> ~_~
<Son_Goku> if it's Fedora 26 or newer, then `dnf install dnf-utils; package-cleanup --oldkernels --count=3`
<Son_Goku> Fedora 25 and older will require you to actually do the work yourself :P
<zyga-suse> fedora 26
<zyga-suse> but broken at boot, let me try recovery again
<mup> PR snapd#3859 opened: packaging/fedora: Ensure vendor/ is empty for builds <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>
<Son_Goku> zyga-suse: there ^
<Son_Goku> if spread isn't failing after we do this, then there's a problem
<davidcalle> pstolowski: did you remotely access my machine last night? Because it's working now o_o
<mvo> davidcalle: maybe he did (automatic snap refresh maybe?)
<davidcalle> mvo:  doesn't look like it, I had install hooks failing 100% of the time. On stable core, artful snapd, so no recent changes on this front afaik... Unless another snap was messing with everything
<davidcalle> mvo: anyway, bug seems to be fixed, so...
<davidcalle> pstolowski: just confirmed that the install hook was being called as expected, thanks for the help
 * zyga-suse walks daughter to school
<pedronis> is Chipaca off today?
<pstolowski> davidcalle, waaat
<pstolowski> :)
<pstolowski> davidcalle, fyi, I investigated it further yestaerday's evening / this morning.. your state.json didn't show any apparent problem, only confirmed the issue (the error you saw was there). the only *theoretical* explanation I had was that for whatever reason an old version of snap-exec was used (as judging from the error message, snap-exec didn't know about install hooks). but since you didn't disable reexec, I'm clueless...
<pstolowski> pedronis, hey, are you familiar with CommandManager / cmdstate?
<pedronis> pstolowski: I think IÂ might have reviewed it, what's the question?
<pstolowski> pedronis, for some reason in a spread test I'm hitting timeout (which is very generous), as if change wasn't set to ready after finished - https://github.com/snapcore/snapd/pull/3852/files#diff-8c0b309b451b46cd7f7dac1f80654270R113  ; this is working fine in unit test where I'm not actually executing command, but mocking it and set change to ready explicitely
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
<pstolowski> pedronis, perhaps there is something about taskrunner / changes that I do not know or misunderstand
<zyga-suse> re
<pstolowski> but afaiu it should be set ready automatically when tasks are finished
<ogra_> zyga-suse, hmm, what changed in snap-confine ? seems a lot of users get "cannot locate the base snap: ubuntu-core: No such file or directory" ... grepping the source i only see this message in snap-confine/mount-support.c
<ogra_> (there are at least three threads on the forum wherre this seems to be an issue)
<zyga-suse> ogra_: hmmmm
<zyga-suse> ogra_: it's a small patch that landed that lets people use an alternate base snap as an opt-in
<ogra_> i assume it isnt snap-confine itself but smething hands it "ubuntu-core"
<zyga-suse> mvo: ^
<pedronis> pstolowski: you are keeping the lock in  runServiceCommand, how can anything else run?
<zyga-suse> ogra_: ooh
<zyga-suse> ogra_: ubuntu-core you say
<ogra_> well, read the error above :)
<zyga-suse> right, I see now
<zyga-suse> that is ... curious
<ogra_> whats even more curious is that some users in these threads show snap list with core 16-2.26.14
<pedronis> pstolowski: I don't what's happenign in your tests but for sure that code doesn't look right
<ogra_> (though that might just be a rre-exec thing ... running a newer deb version)
<pedronis> pstolowski: IÂ mean all lock mgmt in runServiceCommand seems off
<pstolowski> pedronis, ahh, thanks
<pedronis> pstolowski: seems you are mocking too much
<pedronis> btw
<pedronis> that's probably related to why the tests fowkrs
<zyga-suse> ogra_: core 2.26.14 with snapd 2.27.4
<ogra_> yeah
<zyga-suse> ogra_: but that's not possible on debian stable, it must be sid
<ogra_> because the stable core wasnt updated yet
 * zyga-suse booted debian 9
<zyga-suse> ogra_: it was, last night AFAIR
<ogra_> yup
<ogra_> ogra@anubis:~/datengrab/devel/branches/snapd$ snap info core|grep stable
<ogra_>   stable:    16-2.27.5                (2774) 85MB -
<ogra_> i stand corrected
<zyga-suse> yes
<ogra_> but that user didnt have it :)
<ogra_> (refresh can take up to 24h iirc)
<ogra_> (depending on the timers)
<zyga-suse> I'm reading https://forum.snapcraft.io/t/castersoundboard-snap-requires-deprecated-ubuntu-core/1999
<zyga-suse> here the user did have 2.27.4
<ogra_> theer is also https://forum.snapcraft.io/t/call-for-testing-warzone-2100/2001/4
<zyga-suse> so that's definitely a debian unstable
<ogra_> and cjwatson's LXD build announcement
<ogra_> (and i think i saw it once more but i cant find it)
<pedronis> pstolowski: maybe you want to give a look at #3856 , it might be useful for your tests there
<mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
<ogra_> zyga-suse, oh ... same thing but different https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884
<pedronis> Chipaca: hi
<Chipaca> pedronis: o/
<pstolowski> pedronis, ack, thanks.
<pedronis> Chipaca: #3727 and #3856 could use 2nd reviews
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
<zyga-suse> mvo: I forsee 2.27.6
<ogra_> yeah :/
<Chipaca> pedronis: ack
<Chipaca> zyga-suse: :'(
<Chipaca> does the travis log loading bog down your whole browser, or is my laptopt showing its age?
<Chipaca> if I wait for it to load it's multiple minutes; even getting to click the static log button takes a few seconds (the static logs load almost instantly)
<pedronis> it takes kind of forever
<zyga-suse> Chipaca: it's travis + javascript suxxines
<Chipaca> or maybe our logs are too verbose :-D
<pedronis> zyga-suse: spread on opensuse seems broken because of an actual issue in the scripts
<pedronis> + go install -s -v -p 4 -x macro doesnt allow us to pass any additional parameters '#' so we we have to invoke '`go' 'install`' here manually. export GOPATH=/usr/src/packages/BUILD/go:/usr/lib64/go/contrib export GOBIN=/usr/src/packages/BUILD/go/bin '#' Options used are the same as the /usr/lib/rpm/golang.sh build macro does but as it '#' doesnt allow us to amend new flags we have to repeat them github.com/snapcore/snapd/
<pedronis> here:
<ogra_> Chipaca, use lynx :P
<pedronis> can't load package: package macro: cannot find package "macro" in any of:
<zyga-suse> pedronis: where? can you give me a link to the failure please?
<pedronis> zyga-suse: here for example: https://travis-ci.org/snapcore/snapd/builds/272361316?utm_source=github_status&utm_medium=notification
 * zyga-suse looks
<pedronis> seems like a comment ends up as data
<zyga-suse> pedronis: I'm debugging something similar right now, it's the %gobuild macro that is really both go build and go install
<zyga-suse> pedronis: I'm looking for a solution
<zyga-suse> pedronis: (note that this only affects opensuse)
<pedronis> how did it make to master?
<zyga-suse> pedronis: how was this merged
<zyga-suse> pedronis: good question, my branch that is affected has not landed yet
<zyga-suse> pedronis: I'll check this out soon, looking at debian sid and possible regression
<pedronis> zyga-suse: mvo: master is broken like this :(
<pedronis> how was it merged?
<pedronis> or something has changed in suse itself?
<zyga-suse> pedronis: nothing like that would change inside leap
<pedronis> well master is red and broken
<zyga-suse> sure
<zyga-suse> I think it may be a commented-out macro
<zyga-suse> macros cannot be commented out
<zyga-suse> because of how rpm works
 * zyga-suse looks quickly
<pedronis> something doesn't compute here
<pedronis> I how did it land either way?
<zyga-suse> ogra_: interestingly, snapd in sid is not reexecing
<zyga-suse> pedronis: no idea
<ogra_> oh
<pedronis> zyga-suse:  there's a comment like  this   in the spec:     # The %gobuild macro
<pedronis> I suppose it gets interpreted anyway?
<zyga-suse> I see
<zyga-suse> though this didn't fail before
<zyga-suse> I just removed them, let's make a quick PR
<Son_Goku> zyga-suse, I feel like I should leave this broken: https://github.com/snapcore/snapd/pull/3859
<mup> PR #3859: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3859>
<zyga-suse> pedronis: I just made a PR, let's see what happens
<mup> PR snapd#3860 opened: packaging: don't include any marcos in comments <Created by zyga> <https://github.com/snapcore/snapd/pull/3860>
<pedronis> zyga-suse: seems definitely something that changed under our feet because those comments are still from Simon
<zyga-suse> pedronis: I'll check changelogs
<ogra_> huh ?
<zyga-suse> ogra_: I cannot reproduce the issue, I'll report back but I suspect it's something funky on the reporter's machine
<ogra_> how did 2.28 into beta ?
<ogra_> *get into
<zyga-suse> ogra_: mvo uploaded it
<zyga-suse> ogra_: after 2.27.5 was stable
<mvo> ogra_: its 2.28~rc1 fwiw
<ogra_> why ?
<ogra_> ah,
<ogra_> it doesnt say -rc1
<mvo> the thing that builds the versions cuts a but too aggressively it seems
<ogra_> ah
<mvo> zyga-suse: meh, do you have a handle on this issue already?
<zyga-ubuntu> mvo: which of the recent ones?
<mvo> ogra_: probably worth fixing, its slightly annoyying
<ogra_> yeah, will confuse people
<mvo> zyga-ubuntu: the name where snap-confine stops working for some people, that is rather criticial
<zyga-ubuntu> mvo: not yet, I cannot reproduce it on debian 9 and sid
<zyga-ubuntu> mvo: I asked for more information
<mvo> zyga-ubuntu, pedronis: I would say we disable suse for the moment and deal with the other crisis first, ok?
<zyga-ubuntu> mvo: and I'll check the code, what would trigger this
<mvo> zyga-ubuntu: thanks a bunch - so all reports from debian so far?
<zyga-ubuntu> mvo: technically it looks like snapd passes ubuntu-core as the name of the base snap
<zyga-ubuntu> mvo: I sent a PR that might cure suse, if it fails I'll disable it
<zyga-ubuntu> mvo: there are three reports, one is from debian "9" (but really sid apparently), the rest is unknown for now
<mvo> zyga-ubuntu: ta
<mup> PR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/55>
<mvo> zyga-ubuntu: thanks for the suse fix, interessting bug
<zyga-ubuntu> mvo: not sure if that's really it
<pedronis> mvo: it's rather mysterious
<zyga-ubuntu> mvo: I was building suse package very often and I dind't hit this
<mvo> zyga-ubuntu: it sounds likely
<zyga-ubuntu> mvo: but my packaging is different and I'm on tumbleweed, not leap
<mvo> zyga-ubuntu: yeah, like pedronis said, mysterious why it is happeing just now
<zyga-ubuntu> mvo: I'll check in detail later, the core regression is more serious
<mvo> zyga-ubuntu: +100
<pedronis> from the logs is seems like it's running macros from inside the comments
<zyga-ubuntu> mvo: golang packaging is being changed but I don't think those changes would be backported to leap
<zyga-ubuntu> mvo: maybe I'm just wron
<zyga-ubuntu> *wrong
<zyga-ubuntu> I'll sync suse packaging later to see what's not in trunk
<mvo> pedronis: yeah, this is what zyga-ubuntu fixed in his branch
<mvo> zyga-ubuntu: are all reports from the same user?
<zyga-suse> mvo: so far yes
<zyga-suse> mvo: my suspicion is that something odd is going on on his machine
<ogra_> zyga-suse, well, seems to be sid ...
<zyga-suse> yes, it must be sid
<ogra_> (surprise: unstable is unstable :) )
<zyga-suse> because it has 2.27.4-1
<zyga-suse> mvo: it looks like we append "info.Base"
<zyga-suse> mvo: as base snap name
<mvo> zyga-suse: yes, iirc if info.Base != ""
<mvo> zyga-suse: which seems reasonable, no?
<zyga-suse> yes
<Son_Goku> unless you're re-execing?
<Son_Goku> then it should break due to mismatch
<mvo> zyga-suse: fwiw, I tried with my debian9 install and had no luck reproducing the issue
<zyga-suse> same
<brunch875> sep 06 12:11:36 magpie kernel: audit: type=1400 audit(1504692696.878:207): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name="/run/systemd/resolve/stub-resolv.conf" pid=6685 comm="hexchat" requested_mask="r" denied_mask="r" fsuid=1000 ouid=102
<brunch875> uh oh...
<zyga-suse> heh, prune failed on ppc again
<zyga-suse> I bet PPC has even weirder tick/scheduling
<mup> PR snapd#3861 opened: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/3861>
<zyga-ubuntu> mvo: hmm, that feels ill-placed for that interface
<zyga-ubuntu> mvo: I wonder if we are just missing an interface for something more specific
<zyga-ubuntu> mvo: or if we should add a quirk system that lets us inject snippets for a specific snap
<zyga-ubuntu> mvo: (ideally via store assertions)
<zyga-ubuntu> mvo: so we could fix people in the wild
<mvo> zyga-ubuntu: yeah, I agree. i asked jdstrand for suggestions
<zyga-ubuntu> (though I don't think we refresh assertions, do we?)
<pedronis> complexity, schmoplixity
<pedronis> we can do a lot of stuff
<pedronis> dont' know if more moving parts will save us in the end though
<mvo> zyga-ubuntu: we could udisks2 or modem-manager or any of the kobject_uevent interfaes to livepatch
<zyga-ubuntu> mvo: "add" I presume
<zyga-ubuntu> pedronis: I think that for things like this
<zyga-ubuntu> oh, why did my laptop quit?
<zyga-ubuntu> for things like this, post-releaes issues wrt security
<mvo> zyga-ubuntu: correct
<zyga-ubuntu> it would be good to 1) fix existing specific snaps
<zyga-ubuntu> and 2) create new interfaces and let people upgrade
<zyga-ubuntu> (people=snap devs)
<zyga-ubuntu> I think we broke many things when netlink mediation landed
<zyga-ubuntu> because we started to reject things previously allowed
<zyga-ubuntu> and then proceeded to samp the extra permissions in various places
<pedronis> as I said we can do many things, but complexity is a proiblem in itself
<zyga-ubuntu> pedronis: I don't disagree in any way :)
<zyga-ubuntu> I think suse download servers are broken now
<zyga-ubuntu> I see it both at home and on linode
<pedronis> we don't even apply any of those kind of changes immediately, atm
<pedronis> you need a new revno either way
<zyga-ubuntu> I see
<pedronis> I think we need interface hooks done before we add anything more in that area
<zyga-suse> mvo: hey, noob question here: what can I monitor after dputting something to sid?
<pedronis> zyga-suse: yes, suse servers seems down
<pedronis> :/
<pedronis> time to put it to manual until other fires are out IÂ think
<pedronis> given master is broken atm
<zyga-suse> yes
 * zyga-suse pushes branch
<zyga-suse> FYI: https://status.opensuse.org/
<zyga-suse> pedronis: ah, it seems we both did it
<zyga-suse> btw, mup seems off/slow
<pedronis> that kind of day
<mup> PR snapd#3862 opened: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <https://github.com/snapcore/snapd/pull/3862>
<mup> PR snapd#3863 opened: spread: disable openSUSE on linode backend <Created by zyga> <https://github.com/snapcore/snapd/pull/3863>
<zyga-suse> mvo: can you please merge one of the two instantly
<Son_Goku> apparently fedoraproject.org DNS in Europe is having problems, too
<Son_Goku> :)
<zyga-suse> well
<zyga-suse> it must be that kind of day then
<zyga-suse> mvo: so are we doing 2.27.6?
<pedronis> likely
<zyga-suse> mvo: with fixes for canonical-livepatch
<pedronis> I think we are waiting to discuss what's best with jdstran-d
<zyga-suse> mvo: and whatever may be causing that ubuntu-core back-from-hell
<zyga-suse> mvo: we could do a hack where we never pass ubuntu-core to snap-confine, and just change that to "core"
<zyga-suse> mvo: I'm looking at theories why this could ever happen
<zyga-suse> mvo: hmm, I think I know what may be going on
<zyga-suse> mvo: my bet is that the reporter lost the current symlink
<zyga-suse> pedronis: whatever the outcome it feels like we will have a new release
<zyga-suse> mvo: I won though whatever took out /snap/core/current also blew everything else out of the water
<zyga-suse> mvo: I'm worried that it might be some crazy upgrade script that does rm -rf /snap
<pedronis> you mean in a classic snap?
<pedronis> or somebody using such  a script on their system?
<zyga-suse> I meant the upgrade script in debian (.postinst and such)
<pedronis> or part of packaging?
<zyga-suse> maybe there's some bug that causes it to run the prune code
 * zyga-suse looks
<pedronis> on ubuntu we just have postrm that rm things only on prune
<pedronis> sorry, on purge
<zyga-suse> right, but I think there's a delta with debian, looking at that now
<pedronis> zyga-suse: I merged mine turn off suse given it got green
<zyga-suse> ok
<zyga-suse> please close the other
<mup> PR snapd#3862 closed: spread.yaml: turn suse to manual given that it's breaking master <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3862>
<mup> PR snapd#3863 closed: spread: disable openSUSE on linode backend <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3863>
<zyga-suse> thank you
<zyga-suse> the postrm script look sane
<zyga-suse> pedronis, mvo: I wonder if the snap manager should ensure that all snap mount points exist and the units are mounted in its ensure loop
<zyga-suse> having something like that would give us a healing system that would fix whatever has affected that particular user
<zyga-suse> similarly to how snapd ensures security profiles are correct
<pedronis> maybe, doesn't sound 2.27+ material
 * zyga-suse break 
<pedronis> mvo: #3727 needs a master merge
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<mvo> pedronis: sure, doing that now
<mvo> zyga-suse: you should get an accept mail after dputing (sorry for the delay)
<zyga-suse> mvo: no worries
<zyga-suse> mvo: I got the mail (REJECTED, but that's another topic)
<zyga-suse> mvo, pedronis: I think that after we fix what affects canonical-livepatch we *must* teach snapd to start any services that are stopped/broken
<zyga-suse> as I bet the background service is broken on various running machines now
<zyga-suse> and while the .6 update will fix it it would only auto-start on the next reboot, defeating the purpose
<zyga-suse> Chipaca: ^
<mvo> zyga-suse: we will update livepatch too (the snap)
<ogra_> woah
<ogra_> http://paste.ubuntu.com/25478060/
<ogra_> do we never clean up when core gets updated ?
<zyga-suse> mvo: that's another solution
 * ogra_ wonders when users will start running out of inodes 
<zyga-suse> ogra_: known bug, I think
<ogra_> ah, k, then i wont file it ... looks shocking nontheless
<zyga-suse> there's a bug open for hit
<zyga-suse> for it*
<mup> PR snapd#3861 closed: interfaces: add NETLINK_KOBJECT_UEVENT to kernel-module-control <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3861>
<zyga-suse> mvo: is there any interface that allows just kobject uevent?
<zyga-suse> mvo: if no let's add it to some netlink-kobject-uevent maybe and then patch the livepatch snap to use it
<pedronis> I don't think that's the spirit, we don't have interfaces with so low granularity afaict
<pedronis> anyway seems jdstrand is thinking/looking into this
<jdstrand> let's not do that
<jdstrand> mvo and I have a plan and a workaround for livepatch
<mup> PR snapd#3864 opened: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
<zyga-suse> jdstrand: hey
<zyga-suse> jdstrand: what is the plan?
<jdstrand> that pr ^
<jdstrand> zyga-suse: that achieves what you suggested in an existing interface. and that interface is the correct place for the policy
<zyga-suse> jdstrand: thanks
<zyga-suse> mvo: I commented on the PR, would love it if you could revise the commit message
<mvo> zyga-suse: sure
 * jdstrand thought the comment was clear (and commented on it)
<jdstrand> but whatever you come up with is fine
<mvo> ogra_: are those "just" empty mount points?
<ogra_> mvo, i think so, let me check
<ogra_> mvo, confirmed
<zyga-ubuntu> Chipaca, pedronis: standup
<Chipaca> omw
<mup> PR snapcraft#1519 closed: lxd: use a unique temporary folder <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1519>
<mvo> Son_Goku: fwiw, 2.27 has working base snaps, I would love to try this with your fedora work
<mvo> Son_Goku: aiui you have a fedora base already :)?
<Son_Goku> what do you mean, working base snaps?
<Son_Goku> I have a script for making core/base snaps, yes: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
<Son_Goku> I stopped working it a while back because I can't test the output
<ogra_> now you can
<ogra_> :)
<zyga-ubuntu> re
<zyga-ubuntu> Son_Goku: I can explain
<zyga-ubuntu> Son_Goku: but yes, we can now try
<Son_Goku> I'm going to guess that my YAML needs to be different for the base snap
<ogra_> needs to be base'ic ... (muhahaha)
<pstolowski> davidcalle, hey, one more question re your issue and how it disappeared this morning - have you rebooted your box?
<davidcalle> pstolowski: yes, I tend to reboot frequently, yesterday, the day before...
<pstolowski> zyga-ubuntu, ^
<zyga-ubuntu> pstolowski: so I know what the problem is IMO
<zyga-ubuntu> pstolowski: I can revive a branch that fixes it and we can sit on the bug in apparmor that this exposes
<mup> PR snapd#3642 closed: cmd/snap: get keys or root document <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3642>
<pedronis> pstolowski: let me know if you want to have a step back chat about Plug/SlotData today or tomorrow ?
<cachio_> mvo, I see this error https://paste.ubuntu.com/25478387/
<cachio_> in most of the ubuntu cores
<pstolowski> pedronis, sure, will let you know, probably tomorrow. thanks
<pstolowski> zyga-suse, oh, so it goes deepeer
<pstolowski> zyga-ubuntu, ^
<zyga-ubuntu> pstolowski: it's pretty simple but the fix ran into a bug in the kernel
<cachio_> I reproduced it
<pstolowski> zyga-ubuntu, is this about namespaces?
<zyga-ubuntu> pstolowski: the bug is from 2016
<zyga-ubuntu> pstolowski: its open on LP
<cachio_> mvo, but not sure it is a bug or not
<Chipaca> zyga-ubuntu: 2016? psh, amateur :-p
<cachio_> mvo, it is in the border line
<pstolowski> zyga-ubuntu, why couldn't I reproduce it? and it was happening to davidcalle every day (till this morning)?
 * zyga-ubuntu just had a very interesting question from tech-illiterate friend
<zyga-ubuntu> pstolowski: I'll explain in a sec
<zyga-ubuntu> question was: should I download amd64 or i386 build of ubuntu if I have a celeron procesor, he was going for i386 because his box is not amd
<pstolowski> i'm glad though it's not a fundamental issue with install hook though
<zyga-ubuntu> I wonder how many people use 32bit systems because of that
<zyga-ubuntu> pstolowski: so the hook is in the core snap
<zyga-ubuntu> pstolowski: which is the root fs
<pstolowski> zyga-ubuntu, no, the hook is in a reguar snap
<zyga-ubuntu> pstolowski: to reproduce have two revisions of a snap and two revisions of the core
<zyga-ubuntu> pstolowski: (sorry, I meant snap-exec)
<pstolowski> right
<zyga-ubuntu> pstolowski: start on old-core and old-snap and run the snap (or any hook) so that we have a mount namespace
<zyga-ubuntu> pstolowski: now refresh core to new-core (with new hook support in snap-exec) and refresh to new-snap
<zyga-ubuntu> pstolowski: when core changes we don't have a mechanism for refreshing existing mount namespaces
<zyga-ubuntu> pstolowski: the fix, even once my branch lands, won't always refresh it either
<zyga-ubuntu> pstolowski: because we don't do it for valid reasons
<zyga-ubuntu> pstolowski: a simple fix is to run snap-exec via ... and bare with me... /var/lib/snapd/hostfs/snap/core/current/usr/lib/snap-exec
<zyga-ubuntu> pstolowski: because *that* will be always fresh
<zyga-ubuntu> pstolowski: it should be a one liner in snap run and one liner in snap-confine.apparmor.in
<zyga-ubuntu> pstolowski: try writing a case that reproduces this first
<zyga-ubuntu> pstolowski: it's a very interesting bug
<zyga-ubuntu> pstolowski: NOTE: it's sufficient to test a subset
<zyga-ubuntu> pstolowski: stat snap-exec before and after core refresh
<zyga-ubuntu> pstolowski: and if the inode is not changed, we are running the wrong one
<zyga-ubuntu> pstolowski: if you can come up with a full test that would be nice but I think it's not really needed given how hard it is to set this up
<zyga-ubuntu> pstolowski: as long as we run snap-exec via hostfs we're fine
<zyga-ubuntu> pstolowski: one more thing is that new base snap support makes this more complex
<zyga-ubuntu> pstolowski: but I think bases need to have hostfs so the fix is universal
<zyga-ubuntu> pstolowski: that's all
<zyga-ubuntu> mvo: ^
 * zyga-ubuntu returns to 14.04 debugging
<mvo> zyga-ubuntu: uh, interessting
<pstolowski> zyga-ubuntu, wow, that's interesting bug indeed. thanks for explanation! I need to copy it somewhere..
<mvo> a second review for 3854 would be great (should be trivial)
 * zyga-ubuntu looks
<Chipaca> mvo: question: why use mockCommand, instead of mocking SystemctlCmd?
<zyga-ubuntu> ah, I already did
<Chipaca> mvo: another question: why aren't i asking this in the PR?
<zyga-ubuntu> mvo: thank you for the explanation
<mup> PR snapcraft#1531 opened: Release changelog for 2.34 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1531>
<Chipaca> ah, corecfg
<Chipaca> ah
<mvo> Chipaca: I guess corecfg actually would need some work to do it this way, might not be a bad idea to convert it
 * zyga-ubuntu had an idea to have a way for a given module to offer to mock itself out
<zyga-ubuntu> so that we don't have to know how to mock internal details in tests of something else that just happen to use the public API of that first thing
<Chipaca> mvo: corecfg is already using systemd.SystemctlCmd
<Chipaca> zyga-ubuntu: ^
<Chipaca> it's not doing its own exec
<zyga-ubuntu> Chipaca: sure but there's no way to say <module>.MockEverythingExternal()
<zyga-ubuntu> Chipaca: so if <other> uses <module> it needs to know too much in its tests
<zyga-ubuntu> ideally this would be exposed for tests in the public api but not clutter the real public api
<zyga-ubuntu> I think that's hard in go
<Chipaca> zyga-ubuntu: so you're saying that knowing the details of the implementation of something, and mocking one of the details, is better than knowing the API that thing exposes and using that in your tests?
<pedronis> Chipaca: mvo: seems to be doing both
<Chipaca> pedronis: where's it calling systemctl itself?
<pedronis> it's also using  s.coreCfgSuite.SetUpSuite(c)
<pedronis> sorry
<zyga-ubuntu> Chipaca: I no, I'm saying that if I work on A that uses public api of B I should not need to know internal details of B that so that I can mock it out (again: external interactions of B)
<zyga-ubuntu> Chipaca: maybe I'm wrong but I feel it would be nice
<pedronis> Chipaca: I mean the tests are using mocking SystemctlCmd as well
<mvo> Chipaca: aha, interessting, so I mocked the wrong thing
<mvo> Chipaca: thanks, I will  tweak that
<Chipaca> zyga-ubuntu: it sounds like we agree on the premise
<pedronis> Chipaca: IÂ don't if the code is using both, IÂ asked that in the review though
<zyga-ubuntu> Chipaca: +1 :)
 * zyga-ubuntu is starving
<zyga-ubuntu> I'll skip 14.04 debugging and get a meal
<Chipaca> zyga-ubuntu: so based on that, setting SystemctlCmd is the right thing to do, and using MockCommand to replace systemctl, the wrong thing
<Chipaca> zyga-ubuntu: gah! go get food :-)
<zyga-ubuntu> Chipaca: yes
<zyga-ubuntu> Chipaca: though it'd be nice if we could standardize that more
<zyga-ubuntu> Chipaca: <module>.MockIt() or whatever
<Chipaca> zyga-ubuntu: just as soon as we standardize all modules to be <module>.DoIt()
<pedronis> Chipaca: I think zyga-ubuntu as a point here
<pedronis> Chipaca: modern style is   MockFoo(foo) (restore func())
<pedronis> or at least I hope that was his point
<Chipaca> pedronis: in export_test yes; would we want to make that part of the public api also?
<pedronis> we do sometimes
<Chipaca> ah
<pedronis> having a global that you can clobber isn't much better
<Chipaca> oh, agreed, it's not pretty
<pedronis> Chipaca: release.MockOnClassic for example
<pedronis> etc
<Chipaca> man, this battery lasts ~10 minutes :-(
<pedronis> if we need this across packages we do it
<pedronis> I mean put it in the pkg public api
<Chipaca> pedronis: sounds like an easy PR
<pedronis> they all are, they say  (at the beginning) :)
<pedronis> not looking to add another cleanup to my current pile
<Chipaca> i'll do it at some point maybe
<om26er> is there an interface that allows to take a screenshot of the desktop ? (I am not aware of technicalities on what needs read permission under X11 for that)
<Chipaca> om26er: x11 is probably good enough for that
<Chipaca> om26er: but it won't work on wayland; i don't think we've got anything that'll work there yet
<om26er> Chipaca: yeah, I am only concerned about X11 for now. Will check if just connecting x11 works.
<zyga-ubuntu> pedronis: that was the point
<zyga-ubuntu> Chipaca: ~10min on your laptop?
<Chipaca> zyga-ubuntu: it's an 8yr old battery
<Chipaca> yes
<mvo> Chipaca: this is about adding "systemd.MockSystemctlCmd()"?
<zyga-ubuntu> ah
<pedronis> it's good it hasn't exploded or deformed
<Chipaca> mvo: not in that PR
<mvo> Chipaca: I missed most of the earlier discussion
<mvo> Chipaca: it might make sense, should be easy(ish)
<Chipaca> mvo: bottom line for your PR: replace SystemctlCmd everywhere, don't use MockCommand
<zyga-ubuntu> mvo: how about systemd.MockExternalInteractions
<zyga-ubuntu> MEI
<Chipaca> zyga-ubuntu: not in that PR!
<zyga-ubuntu> MEIBI
<zyga-ubuntu> Chipaca: fair enough
<pedronis> ExternalInteractions
<pedronis> what are those?
<mvo> Chipaca: yes, that part I got out of it
<Chipaca> mvo: that's all, for your pr
<Chipaca> the rest is a bigger change that needs more work
<zyga-ubuntu> pedronis: vague stuff including things like running processes
<pedronis> MockBoundaryCrossingPokings
<zyga-ubuntu> +1
<Chipaca> zyga-ubuntu: pedronis: that would mean providing two functions at least
<pedronis> ?
<Chipaca> SystemctlCMd and  JournalctlCmd
<pedronis> Chipaca: we mock both with SystemctlCmd now ?
<pedronis> or are you saying there are two globals?
<pedronis> I don't care honestly, as long as what one has to do is understanble
<pedronis> ExternalInteraction seems a bit too vague for my taste
<Chipaca> there are two globals
<Chipaca> pedronis: yes, that was a bit my point
<Chipaca> we're trying to pretend everything is homogeneousible (?) and it clearly isn't
<zyga-ubuntu> jdstrand: hey, can you please review the changes made to https://github.com/snapcore/snapd/pull/3621 -- I'd like to land it when you give it a +1
<mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-ubuntu> jdstrand: I wrote the child profile, should be uncontroversial apart from broad/open umount
<zyga-ubuntu> jdstrand: I can tighten that further with more PRs or inside this one, as you prefer
<zyga-ubuntu> jdstrand: but landing this would allow me to propose useful enchancements
<mvo> Chipaca: an alternative would be to simpliy use "testutil.MockCommand("systemctl")" maybe? less elegant I guess
<zyga-ubuntu> mvo: what do you think about my idea to let a module offer to mock its internals out as a public API?
<Chipaca> mvo: i see MockCommand as a last resource; the path fiddling it does is rather racy
<mvo> zyga-ubuntu: yeah, I think that is consistent with other uses we have
<mvo> Chipaca: ok
<zyga-ubuntu> offtopic, I read how getenv/setenv work and OMG :/
<zyga-ubuntu> that's not a nice API
<Chipaca> zyga-ubuntu: hehe
<zyga-ubuntu> not nice because designed with stupid assumptions eons ago
<Chipaca> zyga-ubuntu: wait, did you look at it in go, or in glibc?
<zyga-ubuntu> but less setenv we do, the better
<zyga-ubuntu> in glibc
<Chipaca> zyga-ubuntu: look at it in go sometimes
<Chipaca> sometime*
<zyga-ubuntu> ah, will do
<Chipaca> zyga-ubuntu: that's the source of the raciness i mentioned
<zyga-ubuntu> Chipaca: the glibc one has other issues and I suspect gets called eventually
<Chipaca> OTOH even setenv is MT-Unsafe
<zyga-ubuntu> yes
 * zyga-ubuntu just checked
<zyga-ubuntu> which probably explains why tests fail when started with -count=1000
<zyga-ubuntu> getenv just borks
<zyga-ubuntu> and mocked commands don't get used
<Chipaca> yep
<Chipaca> zyga-ubuntu: so, we could work around that
<zyga-ubuntu> especially coreconfig tests
<zyga-ubuntu> yes, I think we ought to
<Chipaca> by tweaking the path super early
<zyga-ubuntu> design it not to fail so easily
<Chipaca> and having a single test path env
<zyga-ubuntu> I wish golang had a warning for setenv
<zyga-ubuntu> like gcc linker scripts have for gets
<Chipaca> zyga-ubuntu: just don't wish too hard
<Chipaca> zyga-ubuntu: look what happened to setuid
<zyga-ubuntu>  /o\
<mvo> cachio_: if you have a moment could you please have a look at spread-cron and in particular the snapd-vendor-sync branch? it seems like its not doing things automatically anymore. it should sync the lp:snapd-vendor branch on each merge to master but we had several merges today and nothing got merged since 21h. I think the last merge happend when I clicked a manual rebuild. maybe the actual cron thing is no longer running?
<cachio_> mvo, I saw the same and restarted the snap like 30 mins ago
<cachio_> it should be running again
<cachio_> snapd-vendor-sync is on the queue to be executed
<cachio_> mvo, not sure what happened, I'll take a look
<cachio_> mvo, I am gonna disconnect now
<cachio_> backing from the vpn
<mvo> cachio_: thank you
<mvo> Chipaca: is http://paste.ubuntu.com/25478666/ what you had in mind for better mocking of the systemctl thing?
<Chipaca> mvo: that looks an awful lot like what pedronis and zyga were suggesting, which I recommended happen in a different PR
<Chipaca> mvo: or is this a different PR
<mvo> pedronis: 3858 should be ready for another look
<mvo> Chipaca: it is a different pr, its nothing at all right now, I was waiting for tests and that seemed to be about the level of mental capacity I had left :/ so if it looks sane(ish) I can turn it into a PR
<Chipaca> mvo: ah ok :)
<Chipaca> mvo: now the same but for journalctl ;-D
<mvo> Chipaca: yeah, much less exposure that one
<mup> PR snapd#3865 opened: many: provide systemd.MockSystemctl() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3865>
<pedronis> mvo: was having a walk,  seems it gets dark earlier and if IÂ wait after dinner for my walk I end up not walking at all
<mvo> pedronis: no worries, thank you
<mvo> pedronis: enjoy the walk!
<pedronis> mvo: I'm back
<pedronis> mvo: #3727 seems mergeable to me
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<pedronis> but IÂ let you do the honors if you want/need to tweak the commit message
<mvo> pedronis: I think I take a short break now myself, feel free to merge otherwise I will when I'm back
<mvo> pedronis: your 3856 also looks ready for merging (not sure if you want to tweak further but definitely enough +1 :)
<jdstrand> zyga-ubuntu: this continues to be on my todo list. it is not forgotten. yesterday had a lot of things I had to respond to over the weekend. note I need to review more than the child profile-- I need to do a careful review of the arg parsing (and env, but I expect that part to go fast)
<pedronis> mvo: IÂ wanted to merge #3727 because I expect conflicts/needing some tweaks
<mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
<jdstrand> zyga-ubuntu: it is also extremely high on said list
<pedronis> with #3856
<mup> PR #3856: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
<jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/3864/files#r137309433
<mup> PR #3864: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
<jdstrand> mvo: I'd like you to add 'bind' to the seccomp policy. this isn't for livepatch since it gets it elsewhere, but it is so hardware-observe can standalone
<mup> PR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3727>
<jdstrand> mvo: I would've done it in another PR but it looks like you didn't update that one yet, so thought I'd mention it. if you prefer to just merge it as is, that is fine, I'll do a followup PR
<mup> PR snapd#3847 closed: tests: run the tests/unit/go everywhere <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3847>
<niemeyer> Chipaca: Hey, which release did we get tab-completion fully working again?  Isn't that 2.27?  I probably missed it in the notes
<Chipaca> niemeyer: what do you mean by "fully working"
<niemeyer> Chipaca: Usable by snaps without any local changes
<Chipaca> niemeyer: 2.27.2 had snippets, meaning it works without local changes on classic
<Chipaca> and falls over flat on core
<Chipaca> niemeyer: 2.27.4 skips creating snippets on core
<Chipaca> or maybe that's 2.27.5
<Chipaca> yeah, .5
<niemeyer> Chipaca: Aha, yeah, so it's 2.27 indeed.. I will fix the notes
<Chipaca> but 2.27 doesn't have it
<Chipaca> there are features in the .s of 2.27
<niemeyer> Chipaca: Yeah, sorry.. there's a bit of confusion around that.. I've made a mroe general 2.27 announcement since this was really when we've sorted all small blockers and updated the core snap
<Chipaca> ok
<cachio> mvo, about hte base snaps test, do you know why it did not fail on linode but it failed on the external:ubuntu-core?
<mup> PR snapd#3866 opened: many: implement fetching sections and package names periodically <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
<Chipaca> it lives!
<ogra_> hmm
<ogra_> so in my update-manager snapd is showing up as "Tool to interact with Ubuntu Core Snappy" in the UI
<ogra_> i wonder if we should change that to something less specific :)
<Sir_Gallantmon> Feel free to steal my summary and description from my package
<mvo> cachio: yes, it failed because on external it uses a snap that was build ~6month ago and on linode it uses our self-build snapbuild
<mvo> jdstrand: if you mention it in the PR I will address it next (adding bind)
<jdstrand> mvo: I did
<cachio> mvo, ok
<cachio> mvo, ok, thanks
<mvo> jdstrand: excellent, thank you
<doko> hi, please could somebody address https://forum.snapcraft.io/t/snapcraft-autopkgtest-failure/2007
 * zyga-ubuntu breaks for dinner
<zyga-ubuntu> doko: hey, good to see you
<ogra_> finally doko found his way into the proper channels :)
<jdstrand> mvo: ok, I've looked at this quite a bit. I looked to see what had network netlink rules and udev and all interfacecs that had both are fine (these are all slot implementations)
<jdstrand> mvo: I then looked at avahi and found that what it is missing is NETLINK_ROUTE, but it gets that with 'network' so no regression in that snap (I'll still fix that interface for comleteness)
<jdstrand> mvo: I then checked all the interfaces with just a 'network netlink' rule. these were all slots that were heavily checked before and have been verified by CE to work without regressions, so that should be fine
<mup> PR snapcraft#1532 opened: tests: update the meson test to latest meson requirements <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>
<jdstrand> mvo: there were three plugging interfaces with 'network netlink'-- account-control, network-control and network-observe
<jdstrand> mvo: account-control is correct and doesn't need to be changed
<jdstrand> mvo: I then looked in the store to see what plugged account-control, network-control or network-observe and found that about half plug neither hardware-observe, x11 or unity7 (ie, things that give NETLINK_KOBJECT_UEVENT)
<jdstrand> mvo: so I investigated if we should just add NETLINK_KOBJECT_UEVENT to network-control and network-observe, and looking at kernel sources in net/core, I think we should
<jdstrand> mvo: therefore, I will proactively send up a PR for network-control and network-observe for NETLINK_KOBJECT_UEVENT, even though we have no regression reports on these. this will make it so nothing in the stable channel in the public store will regress on NETLINK_KOBJECT_UEVENT, because everything that could've gotten it for free with bare 'socket' before will get the new rule via an interface that they already plugs
<mvo> jdstrand: sounds good, I guess we want to also pull this into 2.27.6 then, right?
<jdstrand> mvo: if you are rolling a 2.27.6, yes
<mvo> jdstrand: I think it makes sense
<mvo> jdstrand: if only for canonical-livepatch - even though we workaround it it feels better to do a proper fix
<jdstrand> mvo: I'll be sending up the PR for network-control and network-observe in just a bit
<mvo> jdstrand: thank you, I will look at it in my morning
<jdstrand> mvo: it'll be separate from any other policy work so it is easy to pull in
<jdstrand> mvo: should I target master, 2.28 and 2.27?
<mvo> jdstrand: we will need it in 2.27 and 2.28 and master :/  but if I can cherry pick it then one PR is enough and I just cherry-pick it
<cachio> mvo, is it gonna come a new 2.27 today?
<cachio> a beta one?
<cachio> mvo, I have physiotherapy now, I can start as soon you have something
<mup> PR snapd#3867 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3867>
<mup> PR snapd#3869 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3869>
<mup> PR snapd#3870 opened: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.27 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3870>
<jdstrand> mvo: ok, fyi ^ (3867, 3869 and 3870)
<mup> PR snapcraft#1532 closed: tests: update the meson test to latest meson requirements <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1532>
<mup> PR snapd#3871 opened: tests: fix regex to check core version on snap list <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3871>
<mup> PR snapcraft#1533 opened: demos: update the name of the remote mqtt part <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1533>
<mup> PR snapcraft#1534 opened: Fix UnboundLocalError for chmod_path in jhbuild plugin <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1534>
#snappy 2017-09-07
<mup> PR snapcraft#1533 closed: demos: update the name of the remote mqtt part <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1533>
<mup> PR snapcraft#1534 closed: jhbuild plugin: fix UnboundLocalError for chmod_path <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1534>
<mup> PR snapd#3872 opened: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
<mup> PR core#56 opened: Remove ~ubuntu* instead of cutting after the first "~" <Created by mvo5> <https://github.com/snapcore/core/pull/56>
<mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/54>
<zyga-suse> good morning
<mup> PR snapd#3873 opened: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3873>
<mup> PR snapd#3874 opened: interfaces: add netlink kobject uevent to hardware observe (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3874>
<mup> PR snapd#3875 opened: interfaces: add udev netlink support to hardware-observe (2.27) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3875>
<mvo> hey zyga-suse, good morning
<mup> PR snapd#3873 closed: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3873>
<zyga-suse> mvo: good morning, thank you for the fixes!
<zyga-suse> mvo: I edited the description on github so that it shows up in merge commits
<zyga-suse> mvo: today is the only day my kids go to school at 8:00 :/
<mup> PR snapd#3854 closed: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3854>
<jamesh> mvo: I don't suppose there is any chance of getting the last polkit PR into the 2.28 release?
<mvo> jamesh: let me check
<mvo> jamesh: has that landed in master already?
<jamesh> mvo: the only open issue from niemeyer's review was scope of the polkit action ID
<jamesh> mvo: no
<jamesh> here it is, for reference: https://github.com/snapcore/snapd/pull/3797
<mup> PR #3797: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3797>
<mvo> jamesh: yeah, I think if that makes it before the weekend there is a chance, it seems like its very low risk and the benefit is (imo) huge
<mvo> jamesh: could you please nudge niemeyer to do a second pass on 3797? and if it goes in ideally it should be squash-merged in the commit so that it can easily be cherry-picked for 2.28
<zyga-suse> mvo: how is the 2.27.6 release looking?
<jamesh> mvo: on the forum, niemeyer said he wouldn't be around for the next few days, so I don't know how that affects things
<mvo> zyga-suse: waiting for tests right now, i.e. the PR for hardware-observe
<mvo> zyga-suse: once that is green I will continue with that
<zyga-suse> mvo: do you want to wait for anything else or just release ASAP
<mvo> jamesh: meh, indeed, thats slightly sad
<mup> PR snapd#3858 closed: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3858>
<mvo> zyga-suse: I am not aware of anything else - are you?
<zyga-suse> no, just asking if there's more
 * zyga-suse has bad debian day
<zyga-suse> gpg: /home/zyga/snapd_2.27.5-1.dsc: error 58: Invocation of gpgme_op_verify
<zyga-suse> what?
<zyga-suse> well, there are updates to gpg, let's see
<mvo> zyga-suse: yeah, it should be just those two PRs (one from me, one from jamie)
<mup> PR snapd#3773 closed: snap-repair: execute the repair and capture logs/status <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3773>
<mup> PR snapd#3870 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.27 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3870>
<mup> PR snapd#3857 closed: tests: fix lxd test for external backend  <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3857>
<zyga-suse> ikey: hey, I noticed that you ship 2.27.0, do you plan on updating snapd to 2.27.5 or .6 later today?
<pedronis> FAIL: cmd_watch_test.go:44: SnapSuite.TestCmdWatch
<pedronis> cmd_watch_test.go:84:
<pedronis>     c.Check(string(buf), testutil.Contains, "\rmy-snap 50.00 KB / 100.00 KB")
<pedronis> ... container string = "\rmy-snap 0 B / 100.00 KB    0.00%\r\x1b[K"
<pedronis> ... elem string = "\rmy-snap 50.00 KB / 100.00 KB
<pedronis> I have seen a couple of times
<mup> PR snapd#3856 closed: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3856>
<Chipaca> mo'in
<zyga-suse> pedronis: I have as well, that looks like ansi escape
<zyga-suse> Chipaca: hey, thank you for the epic feedback :D
<Chipaca> what does?
<Chipaca> zyga-suse: epic feedback?
<zyga-suse> launchpad must adopt not only markdown
<zyga-suse> but greek statue images
<Chipaca> hehe
<zyga-suse> (or was it roman?)
<Chipaca> zyga-suse: https://en.wikipedia.org/wiki/Facepalm
<Chipaca> was going to point you to the image directly, but this way is funnier
<Chipaca> ogra_: you around already?
<Chipaca> zyga-suse: so to answer your actual question, french (turn-of-the-(20th)-century)
<zyga-suse> mvo: after I dput and get the ACCEPTED email (I did :), how can I track the package further?
<Chipaca> mvo: remind me, when is the cut-off for 2.29?
<pedronis> Chipaca: after the rally afaict
<Chipaca> that's nearly two months after 2.28's cut-off
<Chipaca> (granted we weren't very good at cutting off at that particular cut-off)
<pedronis> ?
<pedronis> 2.28 was Sept 4
<Chipaca> oh wait, got my dates wrong
<Chipaca> i thought i read aug 11
<Chipaca> but it's sep 11
<Chipaca> that's fine then
<Chipaca> (i'd understood 2.28 to be already forked)
<Chipaca> pedronis: Sep 4? github has it wrong then
 * zyga-suse reads https://github.com/snapcore/snapd/pull/3852/
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
 * zyga-suse looks at https://ci.debian.net/packages/s/snapd/unstable/amd64/ and :/
<mvo> zyga-suse: https://packages.qa.debian.org/s/snapd.html might be a good place
<mvo> Chipaca: in ~3 weeks time 2017-10-02
<zyga-suse> mvo: right, I managed to find that now, I wish it was more real-time tho :-)
<Chipaca> mvo: a'ight
<Chipaca> mvo: and 2.28 is already cut, right?
<Chipaca> (just checking)
<mvo> Chipaca: correct, fixes and low-risk things only
<mvo> zyga-suse: yeah, there is a bit of latency in the debian archive
 * zyga-suse looks at https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=snapd&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=important&sev-inc=normal&repeatmerged=no
<Chipaca> mvo: s/and low-risk things //
<Chipaca> mvo: :)
<mvo> Chipaca: *cough* yes!
<zyga-suse> I need to recall how to reply to those bugs
<Chipaca> zyga-suse: email?
<zyga-suse> I guess I need to stand on my right leg, curl up my right feet behind my back and pick my nose while typing with my ear
<Chipaca> zyga-suse: or do you mean "lis'n 'ere mate"?
<zyga-suse> Chipaca: right but don't forget plain text and the magic first-few-line headers
<Chipaca> zyga-suse: how could I forget
<mvo> zyga-suse: pretty much https://wiki.debian.org/HowtoUseBTS
<Chipaca> something that I never knew
<Chipaca> :-D
 * zyga-suse hugs mvo
 * Chipaca actually might have known once, but has forgotten not only the knowledge, but also the knowledge of knowing
<zyga-suse> in alternate universe debian has a web-based bug tracker with a "reply" button not using mailto:// an ubuntu is geeky and built from source
<Chipaca> zyga-suse: and we're all using something written by djb as pid 1
 * zyga-suse stops looking at the BTS and then goes back to stuffing sharp items under his fingernails
<mup> PR snapd#3875 closed: interfaces: add udev netlink support to hardware-observe (2.27) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3875>
<pedronis> https://forum.snapcraft.io/t/introducing-overlord-mock/2028
<pedronis> Chipaca: your PR had the funniest of runs,  everything failed _except_ xenial-ppc64el
<Chipaca> pedronis: :-D
<Chipaca> ikr
<Chipaca> pedronis: i've got a typo (catalog -> catalogue, apparently)
<Chipaca> but I disagree
<Chipaca> I don't know why that's considered a typo
<pedronis> it's US american vs UK
<Chipaca> nope
<Chipaca> âIn both the US and Canada, both catalog and catalogue are used, with catalogue commonly used in government and traditional institutions and catalog commonly used in informal, business, retail, and computing contexts.â
<Chipaca> it's pretentious
<mup> PR snapd#3876 opened: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3876>
<pedronis> Chipaca: that sentence doesn't say anything about the UK
<mup> PR snapd#3877 opened: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3877>
<Chipaca> pedronis: ah, i read you backwards
<Chipaca> why are we checking our spelling against british english agian?
<Chipaca> again?*
<pedronis> oxford says catalague is UK spelling
<pedronis> *catalogue
 * Chipaca goes with catalgae
<ogra_> Chipaca, i am now
<Chipaca> next it's going to object to Color vs Colour
<Chipaca> ogra_: /var/cache/snapd, how much work is it to make it happen?
<Chipaca> ogra_: good morning! had your coffee yet? here have some writable-paths nightmares instead
<ogra_> Chipaca, one deb upload and an edge rebuild
<Chipaca> ogra_: deb upload + sru, or ppa?
<ogra_> PPA
<Chipaca> ogra_: any objection to doing it?
<ogra_> none at all ... apart from "whatch it closely after the change and before committing to beta/candidate"
<ogra_> -h
<Chipaca> pedronis: if we're using british spelling, then I'm fine with it (my local tools will be happier)
<Chipaca> pedronis: if it's using US spelling, then it's just being pretentious
<Chipaca> ogra_: could you do it, please?
<Chipaca> ogra_: (not urgently)
<pedronis> Chipaca: IÂ have no clue
<Chipaca> pedronis: check for footprints
<ogra_> Chipaca, mind if i do it in https://github.com/snapcore/core-build/pull/17 (same change other dir) ?
<mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<pedronis> is there an official choice for ubuntu?
 * Chipaca wonders what was in his coffee
<ogra_> (would you approve that)
<pedronis> Chipaca: I just discovered I left extra lines in my just merged branch, this by looking at the diff IÂ posted to the forum :/
<ogra_> Chhmm, are you sure its /var/cache, not /var/lib ? (i thought you are talking about #3807 )
<Chipaca> ogra_: I don't mind! and should I approve it before or after the change
<mup> PR #3807: cmd/snap-confine,packaging: import snapd-generated policy <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/3807>
<ogra_> after
<mpt> Is it possible to make a branch from edge? And if so, why? :-)
<Chipaca> pedronis: fun!
<pedronis> Chipaca: there's always the next PR
<Chipaca> ogra_: /var/cache/snapd, for #3866
<mup> PR #3866: many: implement fetching sections and package names periodically <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3866>
<pedronis> Chipaca: we are using  github.com/client9/misspell/cmd/misspell  don't know if there's a way to enforce a dictionary
<ogra_> Chipaca, then i'll do cache and lib in that PR as well, that will help zyga-suse's issue
<pedronis> at least to avoid getting UK one place and USÂ another
<Chipaca> pedronis: https://github.com/client9/misspell/#locale
<Chipaca> :-)
<ogra_> Chipaca, i assume you want "synced" as well ?
<Chipaca> ogra_: well, it could be 'temporary'
<ogra_> (or is "copy readonlÃ¶y once and never again" enough ?)
<pedronis> Chipaca: ok, now pick your poison and change run-checks
<Chipaca> ogra_: but if temporary means in-memory, then maybe something else
<Chipaca> (one of the files that'll land there might be a couple of megs)
<ogra_> Chipaca, i have two ooptions, one copies the content from the readonly dir once on first mount (transition), the other constantly updates if new stuff shows up in the readonly partition (synced)
<Chipaca> ogra_: you have three :-) what does temporary do?
<pedronis> well temporary won't survive reboots
<pedronis> one would think
<ogra_> Chipaca, its like /run ...
<ogra_> right, what pedronis said
<Chipaca> it'll be recreated on boot (if there's network), but ok, sure, umm... 'synced'!
<Chipaca> and we could ship a default sections file :-)
<ogra_> Chipaca, it will be created on boot in any case, not just with network ... but it will come up empty
<Chipaca> ogra_: i meant the files
<ogra_> ah
<Chipaca> snapd creates them on startup
<ogra_> ok
<Chipaca> but, make it synced
<ogra_> will do
<Chipaca> i don't want these on tmpfs on little devices
<Chipaca> and if we feel like it we can ship a pre-loaded cache
<Chipaca> sounds like a win
<mvo> Chipaca, ogra_: please no changes to the ppa right now, we need to push a new 2.27.6
<mvo> later is fine, but not just now
<ogra_> mvo, only doing the PR, i'll wait fo you PR approval there ;)
<mvo> ogra_: ta
<ogra_> Chipaca, hmm, the dir doesnt exist by default, does it ?
<Chipaca> ogra_: currently it doesn't
<Chipaca> ogra_: is that a problem? do we need to change the snapd packaging first?
<ogra_> right, then i need to create it too (no mountpoint, no bind mount)
<Chipaca> right
<pedronis> mmg, no change was fine, copy-pasting from terminal issue
<Chipaca> gah, why is spellcheck _still_ not part of the static checks :-(
<mwhudson> zyga-suse: congrats on your upload :)
<Chipaca> shellcheck*
<Chipaca> (also, i should run the static checks locally more often, tut tut)
<mvo> meh, gccgo build failure on xenial/powerpc with master: https://launchpadlibrarian.net/336142278/buildlog_ubuntu-xenial-powerpc.snapd_2.27.5+git360.71a180c~ubuntu16.04.1_BUILDING.txt.gz - looks conistent
<pedronis> Chipaca: should that dir comes from snapd.dir ?
<pedronis> *dirs
<mwhudson> mvo: yay!
<Chipaca> pedronis: which dir?
<pedronis> /var/cache/snapd ?
<Chipaca> pedronis: /var/lib/snapd?
<Chipaca> pedronis: i think so yes
<mvo> mwhudson: if you have any ideas, I would be very happy. fwiw, I worked around the ppc64el issue succesfully
<zyga-suse> mwhudson: thanks for adding the ACLs!
<ogra_> i can created it from core-config as well if you want ... your choice
<ogra_> *ceate
<zyga-suse> mwhudson: I think there are some bugs to address, some low hanging fruit there
<zyga-suse> mwhudson: man pages and such
<mwhudson> mvo: how did you manage that -extldflags -no-pie?
<mwhudson> mvo: well the test is hanging
<Chipaca> dammit, i'd _fixed_ this GOPATH issue :-(
<pedronis> Chipaca: we need on classic and we need it also on core reexec fwiw
<Chipaca> pedronis: yes
<mvo> mwhudson: https://github.com/snapcore/snapd/pull/3858/files is what I did for -no-pie
<mup> PR #3858: snap-confine,snap-update-ns: add -no-pie to fix FTBFS on ppc64el <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3858>
<pedronis> stating the obvious just in case
<ogra_> yeah, then creating it from snapd is the better move
<Chipaca> pedronis: not sure where core reexec comes into it
<pedronis> so you also need a mkdir
<mvo> mwhudson: yeah, it is hanging but apparently only on powerpc (gccgo), I have a look in a bit
<ogra_> or debian/dirs
<Chipaca> ogra_: both \o/
<ogra_> :)
<pedronis> Chipaca: even if it's dirs or core , you still need to create it on classic because your code might be running before you got the new deb
<mwhudson> mvo: ah i guess that works
<Chipaca> pedronis: ah, yes
<Chipaca> i'll be tweaking that code
<mwhudson> mvo: you can also pass -ldflags=-extldflags=-no-pie to go install
<mwhudson> mvo: my enthusiasm for debugging gccgo issues is, erm, low
<Chipaca> want to have it in dirs, created on boot via initramfs-tools, created on ensure, and skipping the download entirely if unable to create
<Chipaca> i think that covers it enough
<Chipaca> but also, who reverted the GOPATH%%:* change :-(
 * Chipaca curses
<mup> PR snapd#3878 opened: tests: disable opensuse 2.28 as their infrastructure is having issues <Created by mvo5> <https://github.com/snapcore/snapd/pull/3878>
<mvo> mwhudson: aha, thanks for this hint!
<mvo> mwhudson: gccgo> yeah, its pita that we still need to support powerpc
<mwhudson> mvo: i guess i should really SRU the fix i linked into zesty but my enthusiasm for that is not very high either :)
<pedronis> Chipaca: anyway double checked, seems indeed packages tend to put their /var/cach/pkg dir into .dirs
<mup> PR snapd#3878 closed: tests: disable opensuse 2.28 as their infrastructure is having issues <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3878>
<Chipaca> pedronis: awesome, thank you for checking that
<Chipaca> pedronis: i think that makes dpkg clean it up on purge
<mvo> mwhudson: no worries
<Chipaca> pedronis: https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs
<mvo> mwhudson: the workaround is ok for now
<mup> PR core#56 closed: Remove ~ubuntu* instead of cutting after the first "~" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/56>
<mwhudson> mvo: i don't glean anything very much from that traceback of the hanging test
<mwhudson> it looks like it's just sitting there doing nothing
<mwhudson> but it's hard to be sure of course
<pedronis> Chipaca: that seems what we want, no?Â remove on purge?
<Chipaca> pedronis: yes
<Chipaca> so... which english do we use?
<Chipaca> mvo?
<Chipaca> US or UK? is behaviour wrong, or is catalog wrong? :-)
<mvo> Chipaca: UK is closer to me
<mvo> Chipaca: what is complaining  ? spellcheck?
<Chipaca> mvo: misspell, but yes
<Chipaca> for some reason i thought we were using US
<Chipaca> but we've managed to be neutral so far :-)
<Chipaca> except for one word in CONTRIBUTING.md
<Chipaca> :-)
<mvo> mwhudson: nevermind, I will dive into it
<Chipaca> I'll change it to Catalogue then
<mvo> Chipaca: lets stick with uk and solve the problem via po/en_US.po
<Chipaca> mvo: it's a variable name
<Chipaca> :-)
<mvo> *pffff* ok
<Chipaca> interestingly, without telling misspell which locale to use, it seems to use a mixture?
 * Chipaca puzzled
 * Chipaca facepalms
 * Chipaca is dumber by the day
 * Chipaca doesn't get any better by night either
<Chipaca> it wasn't catalogue vs catalog
<Chipaca> it was "cataloge"
 * Chipaca <- dumbarse
 * mvo hugs Chipaca
<Chipaca> can we add shellcheck from zesty to our ppa?
<ogra_> why to the PPA ?
<Chipaca> ogra_: how else do you get shellcehck from zesty everywhere?
<Chipaca> i mean everywhere xenialish
<Chipaca> although i guess we could just make sure we run the static checks on zesty
<Chipaca> or artful even
<ogra_> Chipaca, where exactly do you want to run shellcheck ?
<Chipaca> ogra_: if shellcheck is installed, the static checks use it
<ogra_> (do we have anything that has the PPA enabled where we use it ?)
<Chipaca> ogra_: but maybe running it on artful is good enough
<ogra_> what i mean is that typically our travis tests run shellcheck already ... before a package hits a PPA
<Chipaca> ogra_: our travis checks don't run shellcheck
<Chipaca> ogra_: if they did, they'd be red
<ogra_> oh
<ogra_> mine all do :)
<zyga-suse> ogra_: I left one comment on the core PR
<ogra_> zyga-suse, already answred ;)
<zyga-suse> thanks!
<pedronis> Chipaca: are you looking into classic revert now ?
<Chipaca> pedronis: yes
<pedronis> Chipaca: did you see #3852  ?
<mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
<Chipaca> pedronis: uh, yes
<Chipaca> didn't i submit that review?
<Chipaca> i'll look again in a sec
<pedronis> you commented but IÂ don't see a code review there
<pedronis> from you
<pedronis> mvo: did you see the comment from jdstran-d about adding bind to harward-observe ?
<mvo> pedronis: yes, I think I did that, let me double check
<pedronis> you did
<pedronis> github confused me
<mvo> pedronis: my bad, I force pushed
<mvo> pedronis: to make the cherry-pick easier
<mvo> pedronis: sorry for that, it was an exception
<pedronis> yea, now IÂ noticed
<pedronis> mvo: any reason not to merge #3864 ?
<mup> PR #3864: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <https://github.com/snapcore/snapd/pull/3864>
<mvo> pedronis: thanks, merged now
<mup> PR snapd#3864 closed: interfaces: add udev netlink support to hardware-observe <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3864>
<mup> PR snapd#3867 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3867>
<mup> PR snapd#3879 opened: release: merge release 2.27.6 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3879>
<pedronis> mvo: now that we run unit tess on more places,  SnapSuite.TestCmdWatch seems to fail randomly but often enough to be annoying, haven't looked at it yet
<pedronis> *tests
<mvo> pedronis: thanks, I have no looked either yet, there are some build issues in the edge ppa that I wanted to look at next, once these are under control I can have a look (until you beat me to it of course :)
<mvo> s/until/unless/
 * zyga-suse needs to pick up his daughter in 10 minutes
<zyga-suse> why does it have to rain all week :/
<mup> PR snapd#3880 opened: tests: add trivial canonical-livepatch test to ensure we do not break it <Created by mvo5> <https://github.com/snapcore/snapd/pull/3880>
<pedronis> mvo: IÂ looked at it briefly now, IÂ don't understand the failure mode at all
<pedronis> might also be different versions of pb ?
<mvo> pedronis: could be, we recently changed the import
<pedronis> debian-unstable seems one place where it fails
<pedronis> but not always
<pedronis> but I have seen also some autopkgtests
<pedronis> not sure
 * zyga-suse sighs
<zyga-suse> Pharaoh_Atem: that shell replacement for that ruby replacement of just using go build
<zyga-suse> ...
<zyga-suse> ikey: would you like if I could co-maintain snapd in solus?
<zyga-suse> Pharaoh_Atem: this is gobuild :-( http://pastebin.ubuntu.com/25483256/
<mup> PR snapd#3869 closed: interfaces/network-{control,observe}: allow receiving kobject_uevent() messages for 2.28 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3869>
<mup> PR snapd#3876 closed: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3876>
 * zyga-suse goes into the rain, ttyl
<mvo> pedronis: it looks like https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+build/13346641 panics in snapstate_test.go:77 which indicates that maybe 5s for settle is not enough on arm/arm64 - do you mind if I try with 10s?
<mvo> pedronis: same error on powerpc it seems, anyway, I do a test build with 15s and see if that helps
<mwhudson> mvo: the pb import change did not change the code imported at all fwiw
<pedronis> mvo: I don't mind, it's there to be able to change it
<pedronis> slow infra is slow
<mwhudson> pretty sure that library has buggy (== wall clock dependent) unit tests all of its own
<pedronis> does it have wall clock dependent behavior as well?
<mup> PR snapd#3881 opened: snapstate: give snapmgrTestSuite.settle() more time to settle <Created by mvo5> <https://github.com/snapcore/snapd/pull/3881>
<Chipaca> mvo: o/
<Chipaca> mvo: completer snippet creation support, I thought that was in 2.27.2+, with 2.27.5 having the fix for not doing it on core
<Chipaca> mvo: but it's not! how did I become confused?
<Chipaca> mvo: (I looked at git's release tags for this information)
<mwhudson> pedronis: maybe?
<pedronis> there's a REFRESH_RATE
<pedronis> so I suspect it is
<zyga-suse> re
<pedronis> which means that test is very optimistic
<pedronis> I'm surprised it didn't fail more often
<zyga-suse> mwhudson: hey, mind if I do .6 as well?
<mwhudson> zyga-suse: not at all
<zyga-suse> mwhudson: I need to re-learn the BTS insanity and reply to bug mail there
<zyga-suse> mwhudson: I'll look at doing manual page for snapctl so that we can close that one
<mwhudson> zyga-suse: debian bts sure is its own special snowflake
<zyga-suse> mwhudson: how does new packages sponsorship look like?
<mwhudson> zyga-suse: you know the bts(1) command line tool?
<zyga-suse> mwhudson: if, say, I packaged the gettext thing, could you sponsor it?
<mwhudson> zyga-suse: yes
<zyga-suse> mwhudson: no, checking
<mwhudson> uploads to NEW can't be source only and can't be done by a DM
<zyga-suse> mwhudson: does it require an operational mail server locally?
<zyga-suse> mwhudson: ah, debian still does binary uploads?
 * Chipaca murders pstolowski, review-style
<zyga-suse> mwhudson: but anyway that is fine, I just want to reduce the number of patches
<zyga-suse> Chipaca: ohh?
 * zyga-suse is grumpy because his daughter had no lunch at school today
 * Chipaca whistles innocently and cleans his blade
<mwhudson> zyga-suse: it requires something, i have mstmp which is not exactly "an operational mail server"
<Chipaca> zyga-suse: what?
<zyga-suse> school ends at 12:30 but lunch is served at 15:00, who made this schedule again?
<Chipaca> zyga-suse: your daughter is hungry, and you get angry? that's dad-level hangry right there
<matteo> lol
<mwhudson> zyga-suse: and oh yes debian still does binary uploads :)
<zyga-suse> Chipaca: just polish school crappiness and induced stress
<Chipaca> zyga-suse: if it's at 15:00 it's not lunch!
<pedronis> mvo: I fear that test needs a couple of Sleep in it
<mwhudson> maybe not for many more years though
<Chipaca> mwhudson: what're you doing awake dude
<zyga-suse> Chipaca: on top of that she had to attend the religion classes again; even though we clearly stated we didn't approve of that
<mwhudson> Chipaca: it's only 2300!
<mwhudson> but yes i should go to bed
<zyga-suse> mwhudson: have a great rest man!
 * zyga-suse looks at bts(1) and laughs at 
<zyga-suse> ``The abbreviation "it" may be used to refer to the last mentioned bug number, so you could write:  % bts severity 95672 wishlist , retitle it "bts: please add a --foo option"``
<Chipaca> zyga-suse: sounds like something somebody used to writing Perl would do
<zyga-suse> debian, where web-based bts is not an option but we parse `it` in sentences
<zyga-suse> Chipaca: yes, that's a very good bet
<Chipaca> (Perl expands your awareness of contextual information, meaning you end up thinking these sort of thoughts)
<Chipaca> (15 years later I still don't know if that's a good thing)
<pedronis> anaphoric macros come to mind
 * Chipaca doesn't put no macros in no amphorae
 * zyga-suse finally found this: https://github.com/openSUSE/golang-packaging/blob/master/golang.sh#L118
<pedronis> Chipaca: : https://en.wikipedia.org/wiki/Anaphoric_macro
<Chipaca> yes, reading that
<Chipaca> today is being educational :-)
<zyga-suse> ah
<zyga-suse> I used that without knowing this term
 * zyga-suse used to write proprietary lisp stuff back in the days
<Chipaca> I should learn lisp beyond being able to edit .emacs
<Chipaca> some day
<Chipaca> anyway, where was i
 * Chipaca got context-switched to hell
<pedronis> sorry
 * Chipaca notices it's lunch time
<Chipaca> pedronis: you weren't the one plopping things on my stack :-)
<Chipaca> well, maybe that last anaphorensic one was
<Chipaca> ok, fine, take a little blame
<Chipaca> FINE
 * Chipaca lunch
<Chipaca> also PS https://github.com/pts/pts-line-bisect/ is awesome
 * Chipaca cleaning up browser tags pre-lunch
<zyga-suse> Chipaca: I'll keep that tab for you
<Chipaca> zyga-suse: the biggest problem is that _we don't need it_ :-)
<Chipaca> our files are small enough for it not to matter
<Chipaca> bah, should probably benchmark on the bbb
<pedronis> mvo:  do you remember which test  timed out of Settle ?
<pedronis> I'm asking because when I was finishing the branch they were all fast except the one you added recently
<zyga-solus> ikey, hello ;)
<zyga-solus> Chipaca, using hexchat now
<mvo> pedronis: the TwoCores one, let me look for the exact name
<mvo> pedronis: fwiw, now only powerpc is having issues, even 30s is not enough for that it seems :(
<pedronis> ok, then something else is going on
<mvo> pedronis: TestInstallWithoutCoreTwaoSnapsWithFailureRunThough
<mvo> pedronis: including typos
<mvo> pedronis: the tests are ok on the other arches, however powerpc is the only gccgo based arch left so maybe it is something else indeed
<pedronis> mvo: 30s is not reasonable
<pedronis> we can still use  a local settle ofr a couple of tests
<pedronis> with a larger timeout
<pedronis> mvo: ppc is a big big pain :/
<mvo> pedronis: yeah, I'm running another test build on ppc now to see how things look
<mvo> pedronis: yes it is!
<zyga-solus> mvo, is the real "ppc" arch?
<mvo> pedronis: I should have results in ~20min or so
<zyga-solus> mvo, or something more recent
<mvo> zyga-solus: this is powerpc
<zyga-solus> mvo, I ask because ... I happen to have one ppc box
 * zyga-solus looks elsewhere to avoid eye contact
<ogra_> huh ? isnt powerpc dead ?
<ogra_> i thought we only do ppc64el now
<mvo> ogra_: its a zombie
<mvo> ogra_: its alive in xenial
<ogra_> oh my
<mvo> ogra_: so we need to care
<mvo> :/
<zyga-solus> shall I boot it?
<ogra_> do we really ?
<zyga-solus> (well, boot and install)
<mvo> ogra_: maybe not
<mvo> ogra_: but the default is that we do :)
<mvo> zyga-solus: wait a little bit please, I run one more test on the builder and then I will check if its a generic gccgo issue
<pedronis> mvo:  here  TestInstallWithoutCoreTwoSnapsWithFailureRunThrough  takes 6.5 seconds
<ogra_> yeah, but given it will be dead and there will likely also not be snaps anyway ...
<pedronis> so definitely 5s is low for it
<zyga-solus> mvo, sure - I *really* don't want to
<mvo> ogra_: yeah, I would love to burry it for good
<mvo> zyga-solus: heh
<mvo> pedronis: thanks for double checking!
<zyga-solus> just offering to help if last resort
<zyga-solus> man, solus is really good
<ogra_> mvo, we should start a forum discussion and if nobody complains just let it die
<pedronis> but 30+ seems a more serious problem
<pedronis> mvo: after that IÂ have  TestInstallWithoutCoreTwoSnapsRunThrough	0.161s
<pedronis> all the rest is fast
<mvo> pedronis: woah, that looks like its worth invesitgating why the other one takes so long, I wonder if it does some retries
<mvo> pedronis: I need to get some lunch now, lets talk in a bit, I shall have results from another test run then
<pedronis> mvo: I suspect it might be new behavior related to the prereq task but not sure
<pedronis> anyway, yes it's a slow test, would be good to understand/cut runtime if possible
<zyga-solus>  pedronis, is it an io-bound test?
<pedronis> ?
<zyga-solus> that test you are discussing
<zyga-solus> is it slow because of CPU, fake sleeping or IO?
<zyga-solus> maybe worth measuring with SNAPD_UNSAFE_IO=1
<pedronis> doubt that but we can try
<pedronis> more likely som retries
<mcphail> Hi everyone. Is there any possibility for a name-based virtual host layer for snaps? The idea being that multiple snaps could "bind" to port 80 and the virtual-host layer would direct to the correct one based on the requested name? That way it would be possible to run, say, the nextcloud snap and a separate server app
<zyga-solus> mcphail, hey, that's pretty interesting but we don't have anything doing that at the moment
<mcphail> OK. Cheers zyga-solus
<pedronis> it blurs a bit the distinction with other container approaches, otoh when we allow to install the same snap multiple times we might have to think about that
<pedronis> zyga-solus: no, that env var  doesn't change anything for that test
<zyga-solus> pedronis, thank you for checking
<pedronis> overlord.Mock doesn't write state to disk
<pedronis> anyway, I think IÂ have also been context-switched to hell as John put it at this point
<mvo> pedronis: hm, even brute force 120s is not enough on powerpc, so something else must be going on
 * ogra_ waits for pedronis and mvo to cross the 1h mark for the test :P
<pedronis> mvo: we should understand why it takes so long on non ppc IÂ suppose
<pedronis> it might it why it doesn't work at all on ppc
<pedronis> s/it might it/it might hint/
<mvo> pedronis: precisely
<pedronis> mvo: #3877 can be merged
<mup> PR #3877: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3877>
<mup> PR snapd#3882 opened: debian: improve package description <Created by mvo5> <https://github.com/snapcore/snapd/pull/3882>
<mvo> thanks pedronis
<mup> PR snapd#3871 closed: tests: fix regex to check core version on snap list <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3871>
<mup> PR snapd#3874 closed: interfaces: add netlink kobject uevent to hardware observe (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3874>
<mup> PR snapd#3877 closed: debian: update trusted account-keys check on 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3877>
<pedronis> mvo: now that settle is more than do Ensure 50 times, that test look strange
<pedronis> mvo:  we don't need the for loops around settle anymore
<pedronis> doesn't reduce runtime, mind
<mvo> pedronis: it looks like the outer loop is the problem, if I remove it I get runtimes of 0.8s
<mvo> pedronis: eh, 0.08
<pedronis> well I'm saying the inner loop is not needed
<pedronis> but both this consideration will not solve the ppc problem
<pedronis> mvo: there's no relation between the outer loop and settle timeout,  we  settle many times per outer loop, though as I said one settle is enough
<pedronis> mvo: we don't have  a ppc box we can access? this is not going to be fun to debug just through autopkgtest runs
<zyga-solus> pedronis: I could set one up and open access for you but not sure if it will work, it's an ancient-ish mac mini
<zyga-solus> pedronis: we could also try a qemu box
<zyga-solus> pedronis: note that ensure loop prune also often fails on ppc so it feels like golang behaves different wrt scheduling there for whatever reason
<pedronis> mvo: this is my local diff, debugging prints included:  http://pastebin.ubuntu.com/25483699/
<pedronis> it works fine here with those changes
<pedronis> run time is just 10 times whatever it takes for one loop
<pedronis> settle doesn't use timers fwiw
<mvo> pedronis: thanks, I poke at it some more now too
<mup> PR snapd#3882 closed: debian: improve package description <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3882>
<mup> PR snapcraft#1535 opened: jhbuild plugin: remove dependency on pkgconf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1535>
<pedronis> mvo: xenial-ppc64el auotpkgtest are passing though, are the failures in the PPA?  or somewhere else?  me is confused
<mvo> pedronis: yeah, in hte ppa during build
<mvo> pedronis: one sec, I give you a link
<pedronis> what's different there? though
<mvo> pedronis: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
<Chipaca> pstolowski: o/
<Chipaca> pstolowski: I was trying to think how to explain what i meant about simplifying it, but can't find an easier way (for me) than code
<mvo> pedronis: its a different build environment, I'm not sure about the details sbuild vs the autopkgtest env. I'm not sure how different hw/virtualisation is
<pedronis> mvo: ah, this is powerpc, not ppc64 el ?
<mvo> pedronis: correct
<Chipaca> pstolowski: would you mind if i wrote it and pointed you at it?
<mvo> pedronis: powerpc (32bit)
<Chipaca> pstolowski: i wish i were better at explaining :-/
<mvo> pedronis: I'm still working on the 2.28~rc2 test build, once that is done this gets my attention again
<pstolowski> Chipaca, sure
<mvo> pedronis: I'm also curious if running the tests with gccgo makes a difference
<pedronis> mvo: well we do run them
<pedronis> on other archs
<pedronis> so many moving parts
<pedronis> mvo: we have a spread test about that
<mvo> pedronis: hm, good point
<pedronis> probably me having made a panic is also not great
<pedronis> given that then it ges covered by the lock panics
<pedronis> mvo: I can try to make a cleanup PR, might be  a better baseline to investigate
<pedronis> from
<mvo> pedronis: sure, that is welcome!
<mup> PR snapd#3883 opened: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/3883>
<pedronis> mvo: done ^
<mvo> pedronis: thanks a lot!
<cachio> mvo, joining a bit late
<mvo> cachio: no problem
<sborovkov> ogra_: hmm, is there a way to tell ubuntu image to grab one of snaps from other channel? I want to build image from stable... but psplash is devmode so it can only be beta/edge
<sborovkov> and if I build it as an extra snap locally I won't be able to update/remove it :-(
<ogra_> sborovkov, i'll have to talk to jdstrand at some point about having an interface that has all bits the splash needs
<ogra_> currently the --extra-snaps way is the best way i think ...
<Chipaca> pstolowski: note i haven't tested that code! I think the main thing you might've been missing is that info.Apps is already a map (and that info.Services() exists)
<ogra_> sborovkov, though why do you use the userspace bit, i thought you start some UI anyway ... the gadget splash should be sufficient for that
<pstolowski> Chipaca, yes, exactly, I missed those
<pstolowski> Chipaca, thanks!
<sborovkov> ogra_: well I wanted to have something to show if our service is restarted
<sborovkov> so that we don't show login page
<ogra_> sborovkov, would "black" be enough ? i think you can tinker with the vt.handoff= value in cmdline.txt for that (just have it come out at a vt that doesnt have login)
<ogra_> i'd use the psplash snap only fo systems that dont have graphical bits at all, switching between the splash and your UI will likely be a "flashy" experience
<sborovkov> hmm I guess so, since restart does not happen often and would take couple of seconds
<sborovkov> I just was not sure if I need it to show up on the first boot when keys are generated and so on
<sborovkov> though that's a separate issue I guess
<ogra_> yeah, kind of ...
<ogra_> for that step you would still have the gadget splash in place anyway
<ogra_> (it only goes away once the login prompt comes up)
<sborovkov> yeah but on the first boot after login promt comes up it takes like 5 minutes of it doing stuff in background. so gadget splash would not be helpful. On the other hand it's not like I can change the image used by psplash on the first boot and later boots.
<sborovkov> oh wait, psplash does not work on the first boot
<sborovkov> so it's not gonna help anyway
<sborovkov> nvm
<ogra_> sborovkov, huh ? the gadget psplash definitely works on every boot
<ogra_> and it only goes away once the "please press enter to configure" message comes up... i.e. when console-conf starts
<ogra_> by then all device keys should have long been created
<mup> PR snapcraft#1536 opened: repo: implement :target suffix for package names <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536>
<sborovkov> ogra_: oh I was talking about psplash snap
<ogra_> sborovkov, hmm, after the login pompt comes up yoou have an additional delay ?
<ogra_> that sounds like a bug actually ... all keys should be generated once the prompt shows up
<ogra_> (and psplash from the gadget actually only stops if something takes over the tty (i.e. getty for login)
<ogra_> )
<zyga-solus> mvo: I downloaded ppc xenial iso
<zyga-solus> I can find that box and hit the install
<sborovkov> ogra_: console-conf is disabled
<sborovkov> on our image
<mvo> zyga-solus: I have access to a porter box but no rapt installed there nor go so I can't do much
<zyga-solus> mvo: I'll make lunch and try to install it
<zyga-solus> mvo: worst case it doesn't work
<ogra_> sborovkov, well, you culd try with the gadget splash and setting vt.handoff=0 ... that will keep the screen up and not show a login prompt at all ... the question is if your UI can then take over
<zyga-solus> mvo: best case I have something you can ssh into by evening
<zyga-solus> mvo: and I get the geek card back
<ogra_> sborovkov, your UI might need a chvt call ...
<sborovkov> alright I will try that, going to try to apply splash screen changes from pi2 to my pi3 gadget snap repo
<sborovkov> first
<ogra_> sborovkov, https://github.com/snapcore/pi3-gadget/pull/13 and i also added a gadget snap for pi3 to the bug
<mup> PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13>
<ogra_> (though you got custom changes i guess)
<zyga-solus> mvo: I found it
<mvo> pedronis: good news, I can reproduce the error with go-6 here apparently
<sborovkov> ogra_: ah cool will use that then, yeah, but I just need to merge it then
<ogra_> yeah ... me too (once i get a second review :) )
<mvo> zyga-solus: found the ppc?
<pedronis> mvo: on master or the simplified PRÂ ?
<mvo> zyga-solus: maybe it is not needed, it looks like I can reproduce it with go-6
<mvo> pedronis: master currently, trying your branch next
<zyga-solus> mvo: yes
<zyga-solus> mvo: ok
<mvo> pedronis: with your branch it shows a proper error (but still panics on the lock) - its not converging. I will poke more, its good to be able to reproduce it
 * zyga-solus breaks for food
<zyga-solus> mvo: I'm burning the ppc iso - just in case it is needed
<kyrofa> Urgh, forum stealing /
<mvo> pedronis: looks like the loop is the problem - runtime with loop 1: 0.3s 2: 0.7s, 3: 1.4s 4: 2.1s 5: 3.2s 6: 4.4s 7: forever. very strange
 * mvo digs further
<ogra_> sborovkov, so i just tested here ... setting vt.handoff=0 to keep the splash and then later calling "sudo chvt 1" via ssh works for me ... so your UI startup script would have to do that chvt 1 call to take over the console and yoou should be fine (*if* confinement doesnt bloock chvt here)
<kyrofa> davidcalle, I need to add a deprecation notice to https://snapcraft.io/docs/deprecation-notices, but have forgotten where that code is hosted. Help?
<kyrofa> I thought it was https://github.com/canonical-websites/snapcraft.io
<sborovkov> ogra_: ah, so this way until everything is done it will show black screen? or splash? And when my UI starts I just should use chvt then?
<ogra_> sborovkov, splash
<ogra_> and the chvt makes your UI take ooover the screen
<sborovkov> oh ok, cool
 * ogra_ wonders whats up with his keyboard and all these duplicated/triplicated chars
<sborovkov> first need to figure out why after I applied PR with splash screen my images stopped booting, I merged all other changes to my branch first. It booted. Applied splash screen PR and changed the image - it stops at PI logos above, no output from uboot at all
<ogra_> weird, the Pr doesnt change any output settings for uboot
<ogra_> you should definitely still get the loading of kernel, initrd and such ... as well as the autoboot countdown
<kyrofa> Ah ha! https://github.com/CanonicalLtd/snappy-docs
<ogra_> sborovkov, you dont happen to have dtoverlay=vc4-kms-v3d set in your config.txt i hope
<ogra_> (if thats the case there is more to do)
<sborovkov> ogra_: ah, it boots actually. But does not show splash. My image is not getting in. It went from rapsberries at top straight to my snap
<sborovkov> are there any requirements on image used?
<sborovkov> and that one in config.txt is disabled
<ogra_> sborovkov, do you use dtoverlay=vc4-kms-v3d ? (i.e. GLES)
<ogra_> ok
<sborovkov> nah
<sborovkov> we dont
<sborovkov> out qt app is not working with it
<sborovkov> not sure on details, but there is a comment where it's commented out
<ogra_> right, mir uses it though ...
<ogra_> if your Qt app dooesnt use GLES we're fine on that level
<sborovkov> I mean it's using egl
<ogra_> welll, then you actually need vc4 enabled ... which the dtoverllay above does
<sborovkov> no, it does not work with it
<ogra_> if you do "lsmod | grep drm" on a booted board, does that return anything ?
<sborovkov> one minute I need to boot another image for that, I don't have assertion for local stuff I build
<mvo> pedronis: ok, so the issue appears to be that the MockPrerequisitesRetryTimeout is too short, the taskrunner will always try to run a preprequite task next but that will see that there is a core snap task running and will trigger a retry but because the time is too short it always retries the prepreq task and never runs the core link snap task
<ogra_> (i wonder how you would use EGL without vc4)
<sborovkov> ogra_: also, is the boot image going to be resized? Boot splash is 1080p. But since I connect my display via HDMI->DVI it boots at lower resolution. Can this be the reason splash is not shown on boot?
<mup> PR snapd#3879 closed: release: merge release 2.27.6 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3879>
<sborovkov> lsmod | grep drm does not find anything
<ogra_> hmm, ok
<sborovkov> ogra_: unfortunately I have no idea on implementation details. Qt is just using FB on the rpi I think
<ogra_> sborovkov, hmm, the splash should adapt to the screen size...
<ogra_> right, that should be fine
<sborovkov> ok, I am using SRGB 8 bit
<sborovkov> image
<sborovkov> which should be fine I guess
<ogra_> i just wanted t make sure vc4 isnt turned on while in the initrd
<ogra_> theoreticallly that should be fine
<sborovkov> ok, actually let me try to boot with your vanilla splash screen
<ogra_> you should in any case get at least a white screen
<ogra_> even if the image would be broken, the bg color should change
<pedronis> mvo: ah,  I wondered about that, makes some kind of sense
<ogra_> sborovkov, your cmdline.txt has the "splash" keyword set i hope (the splash checks for that)
<pedronis> mvo: theorically we could implement something just using immidiate retries and SetBlocked, but it needs quite a bit of state tracking and the checks would be costly
<sborovkov> ogra_: yes your patch applied cleanly
<ogra_> just to make sure :)
<sborovkov> it has vt.handoff=2 quiet splash at the end
<ogra_> ok
<ogra_> i still wonder why you dont see any uboot messages
<mvo> pedronis: yeah, in practise with retry of 30s it should not be a problem, I pushed an update to 3881 and test build that now
<sborovkov> ogra_: not sure... stdout=serial, lcd... SO it should show something
<ogra_> yeah and the splash PR doesnt touch anything in that area
<ogra_> it only chnages bits that happen a lot later in the boot
<pedronis> mvo:  we probably don't need the global settle change, I would just do an explicit Settle in that test
<pedronis> mvo: we need to combine 3881 and #3883 somehow
<mup> PR #3883: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <https://github.com/snapcore/snapd/pull/3883>
<mvo> pedronis: yes, makes sense
<mvo> pedronis: I can fix that, I can also merge yours into mine
<pedronis> that works for me
<mvo> pedronis: but first I want to test build to see if my box actually is close enough to the ppc
 * mvo prepares an upload
<pedronis> fearing the ppa is even much slower ?
<pedronis> we could bump it to 100 ms  but check arch ?
<pedronis> IÂ mean bump only conditionally
 * zyga-solus breaks for a few hrs to work on kids stuff 
<mvo> pedronis: merged your branch into mine and resolved the conflicts
<pedronis> thanks, let's see how it goes
<mup> PR snapd#3883 closed: overlord/snapstate: cleanup settle and its uses <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3883>
<pedronis> mvo: I closed mine
<mvo> pedronis: ta
<mup> PR snapcraft#1537 opened: project_loader: aliases are deprecated <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1537>
<pstolowski> api.snapcraft.io has a hiccup?
<sborovkov> ogra_: meh, no, issue is not in the image. tried clean build as well just in case. Unlike old behavior where I'd get login page while everything is configured. And then my snap would show up. All I see is raspberries on the top until our snap takes over. No splash screen though :-(
<ogra_> sborovkov, even with my gadget snap ?
<sborovkov> ogra_: hmm, I am not sure, let me try vanilla snap.
<sborovkov> but the only difference from previous described behavior is your PR merged
<ogra_> and it works fine if you just revert it ?
<ogra_> the PR really only puts an additional file in place and adds an extra load command ... there is nothing it could do to actually make the ooutput before anythiing loads disappear
<sborovkov> alright, I am going to revert it and try it again. Also try vanilla snap as well, but tomorrow I guess, will tell you if I succeed
<ogra_> i'm around
<ogra_> sborovkov, you guys dont happen to come to our rally in new york, do you ?
<ogra_> (would perhaps be helpful to work face to face and with the HW in front of us)
<cachio> ogra_, hey
<cachio> ogra_, I am testing the 2.27.6 and I see it is failing on dragonboard
<pedronis> mvo: any news if it's fixing stuff?
<cachio> no space left
<sborovkov> ogra_: don't think so
<cachio> ogra_, It was running on testflinger
<ogra_> cachio, resized propely ?
<cachio> I'm trying to reproduce it on my dragonboard
<sborovkov> ogra_: alright i want to bang my head against the wall. During our image creation something image is mounted to loop0 and loop1. So I was getting the freaking same image for a last hour *facepalm*
<ogra_> oh my !
<sborovkov> because it did not unmount
<ogra_> :)
<sborovkov> during one of the builds
<cachio> ogra_, which command line do you use to flash your db?
<ogra_> cachio, i use the same everywhere ... xzcat /path/to/image| sudo dd of=/dev/sdc bs=32M
<ogra_> cachio, after explicitly running "sudo umount /dev/sdc1; sudo umount /dev/sdc2"
<ogra_> (my SD reader shows up as sdc obviously)
<cachio> ogra_, ok, I'll do the same
<cachio> I am umounting always
<ogra_> good
<cachio> ogra_, /dev/mmcblk1p9  546M  378M  128M  75% /writable
<ogra_> sigh
<cachio> ogra_, after I flashed it
<cachio> ogra_, where are the logs?
<ogra_> after the first boot ?
<ogra_> (or is that still in your PC)
<cachio> ogra_, after the first boot
<ogra_> the log is in /run/initramfs
<ogra_> and you are 100% sure nothing automounted the SD after you unmounted it ?
<ogra_> befor you dd'ed
<cachio> yes
<cachio> I checked that
<ogra_> (smeone said this week that kde always remoounts it apparnetly)
<cachio> ogra_, I ran sudo umount
<cachio> and then checked that
<ogra_> he did as well ...
 * ogra_ tries to remember who that was ... 
<cachio> ogra_, the weird think is that I ran in test flinger and it failed in 4 different dbs as well
<cachio> with the same issue
<ogra_> cachio, well, nothing changed in months in the resize code
<ogra_> so i'm surprised it doesnt resize
<cachio> https://paste.ubuntu.com/25484632/
 * ogra_ glares at "open: No such file or directory while opening "
<ogra_> but that message is even after it resized already
<zyga-solus> re
<zyga-solus> back for 40 min, then one more school meeting
<zyga-solus> ~fun
<zyga-solus> mvo: any luck with that ppc bug?
<cachio> ogra_, do you need any other log?
<ogra_> cachio, no, and i have absolutely no idea, that code has last changed in april and has not caused issues sice (at least federico never told me) so i'm a bit idea-less
<ogra_> (actually even long before april)
<cachio> ogra_, are you able to reproduce it?
<ogra_> let me try an install but i have never has resize issues since the code landed
<ogra_> *had
<cachio> ogra_, perhaps the diff is how we are building the image
<cachio> ogra_, I am using this script to create the image https://github.com/sergiocazzolato/validator/blob/master/create.sh
<cachio> I ran it using CHANNEL=beta
<ogra_> yeah, not different to what i use here, though i'm still on the ubuntu-image deb
<ogra_> so it might be the snap has changed something that breaks the partition table ... but i wouldnt expect that
 * ogra_ flashes todays daily 
<ogra_> cachio, oh, dont forget when unmounting, the dragoboard uses sdc8 and 9
<ogra_> ok, booting here
<cachio> ogra_, yes
<mvo> zyga-solus: I think its fixed
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk1p9   57G  384M   54G   1% /writable
<ogra_> cachio, ^^^
<ogra_> :/
<ogra_> so i cant reproduce it here
<zyga-solus> mvo: great, I can trash this old junk then :)
<cachio> ogra_, which image are you using?
<ogra_> cachio, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
<ogra_> (got that locally here)
<ogra_> uses edge ... but beyond that shouldnt differ
<cachio> ogra_, could you try with to generate the image with the snapd from beta?
<mvo> zyga-solus: I will know for sure once 3881 is in
<ogra_> cachio, sure, but the initrd in both should be indentical ... (teh initrd is what does the resize)
<cachio> ogra_, tx, I am gonna try with the one you used
 * ogra_ dd's beta ... 
<kyrofa> Hey all, it seems snapctl -h broke
<kyrofa> It requires a cookie
<kyrofa> Makes it difficult to figure out how to use
<ogra_> cachio, http://paste.ubuntu.com/25484910/ this is how it shoudl look like ... (there is an extra message on the tty console about the GPT not defininig the fulll disk size (which is fine), this is copy/paste from serial)
<mvo> cachio: how are the tests looking so far? all green?
<cachio> ogra_, ok, I'll check with the image that worked for you
<cachio> mvo, yes, but strugling with hte dragonboard
<cachio> mvo, it is failing on first boot to resize
 * zyga-solus managed to install 14.04 on the ppc junk
<mvo> cachio: autsch, i remember you had this issue before, right?
<cachio> it fails in testflinger for the 4 dbs
<cachio> and in my db
<ogra_> cachio, oh wow!
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk1p9  546M  378M  128M  75% /writable
<cachio> ogra_, well
<cachio> ogra_, with beta?
 * ogra_ checks if the kernel snap is any different between beta and edge
<ogra_> yes
<zyga-solus> ogra_: the ancient ppc mac has the same amount of ram as raspi3 today, isn't that silly?
<cachio> mvo, well, now ogra_ could reproduce the error
<cachio> mvo, the rest is ok
<ogra_> cachio, aha ! seems the kernel in beta has an issue
<ogra_> there are two different snaps
<ogra_> ppisati, sitll around ?
<ogra_> cachio, edge is on rev 33
<ogra_> beta on 34
<cachio> ogra_, well, that's possitive, now we know the reason
<ogra_> they have the same version string, so i guess beta and candidate were a rebuild
<ogra_> why is stzable so old on the dragonboard btw
<ogra_> thats really behind (rev 27)
<ogra_> cachio, is it urgent ? then i can re-release 33 into beta
<cachio> ogra_, yes
<cachio> ogra_, it is a fix that should be fully tested today
<cachio> ogra_, to go to candidate
<cachio> tomorrow
<ogra_> cachio, ok, 33 is in beta and candidate now ... you shoudl be able to rebuild
<cachio> ogra_,
 * ogra_ does the same 
<cachio> nice
<cachio> ogra_, tx
<ogra_> but looking at the build log of the kernel snap i dont  see anything wrong
<ogra_> very weird
<cachio> mvo, I'll restart the testing
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk1p9   57G  380M   54G   1% /writable
<ogra_> cachio, back to normal here
<ogra_> err
<ogra_> o not
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> crap
<cachio> ogra_,  :(
<ogra_> the rebuild was actually to fix the broken clock setting
<ogra_> so 33 wont work
 * ogra_ switches edge to 32 and does an edge build
<cachio> ogra_, is it ready?
<ogra_> let me test first
<cachio> sure
<ogra_> sigh
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ogra@localhost:~$
 * ogra_ switches edge back to 31 ... 
<ogra_> resize was fine btw ... but that doesnt help
<cachio> ogra_, :(
<ogra_> booting with 31
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> :(((
 * ogra_ goes to rev 30
<ondra> ogra_ sorry did not get to it, but will test that cm3 tomorrow morning
<ogra_> ondra, all fine as long as you are aware ... i'm not in a hurry
<ondra> ogra_ yeah, it's on my list :)
 * Chipaca shakes fist at stuff
<Chipaca> anyway, EOD for me
 * ogra_ joins Chipaca 
<Chipaca> yeah!
 * Chipaca shakes some more
 * ogra_ hopes this boot will finally work ... i had an appointment 20min ago :(
<ogra_> ogra@localhost:~$ snap list
<ogra_> No snaps are installed yet. Try "snap install hello-world".
<ogra_> ogra@localhost:~$
<ogra_> RAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!
<cachio> ogra_, the one we used in the previous beta was working
<ogra_> cachio, cant be
<cachio> ogra_, could we use that one?
<ogra_> do you knwo which one that was ?
<cachio> no
<cachio> I don't
<ogra_> i just switched edge to what was in stable (rev 27) and run another test now
<cachio> ok
<ogra_> ogra@localhost:~$ df -h /writable/
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk1p9   57G  384M   54G   1% /writable
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name                Version        Rev   Developer  Notes
<ogra_> core                16-2.28~rc2    2853  canonical  core
<ogra_> dragonboard         16.04-0.18     32    canonical  gadget
<ogra_> dragonboard-kernel  4.4.0-1063.68  27    canonical  kernel
<ogra_> ogra@localhost:~$
<ogra_> PHEW
<ogra_> cachio, ok, i released rev 27 to all channels
<cachio> ogra_, great
<cachio> tx
<ogra_> cachio, oh, crap and i think i know what the issue is, zyga-solus added a massive amount of quoting to all initrd scripts, i bet something now spits out a wrong number
<ogra_> there looking at the diff orf the initrd scripts (specifically resize) there is a gazillion pointless doublequotes now
<diddledan> if in doubt, quote
<diddledan> quote, quote and then quote again
<ogra_> -device_size="$(($(cat $syspath/size)/2))"
<ogra_> -sum_size="$(($(grep $(basename $device)[a-z0-9] /proc/partitions|\
<ogra_> +device_size="$(($(cat "$syspath"/size)/2))"
<ogra_> +sum_size="$(($(grep "$(basename "$device")[a-z0-9]" /proc/partitions|\
<ogra_>      tr -s ' '|cut -d' ' -f4|tr '\n' '+'|sed 's/+$//')))"
<diddledan> when you think you've quoted enough quote some more :-p
<ogra_> i bet that grep doesnt return anymore what it did before
<diddledan> is there a unit testing framework anywhere in the world for shell scripts? (I feel there should be at least one attempt)
<ogra_> yes, that is what got us the breakage
<ogra_> apt install shellcheck
<ogra_> ;)
<ogra_> and it will make aou add quotes in a lot of pointless places
<diddledan> quote all the things!
<diddledan> "
<diddledan> as long as your quotes aren't imbalanced, you'll be fine"
<diddledan> don't forget to quote your quotes or else you'll get randomness"
<diddledan> the one I really hate with shell scripts is that quotes in variables are interpreted when they're included in another line
<diddledan> thing*
<diddledan> variables aren't treated really like other languages, they're expanded BEFORE the command is parsed
<diddledan> FOO="something with 'quotes'" do_something_with $FOO; echo "probably didn't do quite what you expected, did it?!"
<diddledan> maybe we should kill bash :-p
<diddledan> or kill -9 bash
<SXX> Hello everyone.
<kyrofa> Hey there SXX
<SXX> I looking for some advice. I want snap-packaged application to use assets from /usr/share/ inside snap as it's usually do on main system.
<SXX> https://gist.github.com/ArseniyShestakov/6814ddf6085eb1a798281e31d8d30737
<SXX> Assets I need are found inside /snap/vcmi/x3/usr/share/vcmi.
<SXX> Though I feel that app while running via snap trying to read /usr/local/share of the main system which obviously prevented by apparmor
<SXX> Do I need to specify some special CMake prefix while building for snap?
<sborovkov> ogra_: alright, nice, at least I got some progress. Seems like I get no output about services that are starting. Just uboot messages showing up until my snap takes over.
<SXX> Should I somehow use $SNAP prefix in my app code?
<ParkerR> Installed Discord via the Snap package (from the Software Center) and get this when trying to run Discord http://ix.io/zFu Any ideas? (17.10 Artful)
<ParkerR> snapd   2.27.5+17.10
<mup> PR snapd#3884 opened: store: simplify api url config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3884>
<zyga-solus> jdstrand: hey
<zyga-solus> jdstrand: not sure if you did but a kind request to look at the child profile for snap-update-ns that I wrote
<kyrofa> SXX, sorry for the delay, I was in a meeting
<mwhudson> morning
<kyrofa> Morning mwhudson!
<kyrofa> SXX, yeah, you need to somehow use $SNAP there, since snaps aren't chroots
<SXX> kyrofa: i already find out snap actually able to rewrite paths for assets in /usr/share
<kyrofa> SXX, how you do that depends on the application. Apache has a config file that allows use of environment variables. Others have cli flags for redirecting it
<kyrofa> SXX, or you can use the preload part, is that what you're talking about?
<SXX> I still have a problem that our applications need to be able execute each other.
<SXX> E.g we have 3 apps: launcher, game client and server
<kyrofa> Sure
<kyrofa> What is the issue there?
<SXX> They use absolute path and desktop-launcher doesn't override that.
<SXX> I mean desktop-launch.
<nacc> SXX: you control your app, though -- so don't use absolute paths?
<SXX> True, I just looking what best practice is.
<nacc> SXX: I think hardcoded non-snap-aware paths are not best practice for snaps :)
<SXX> Yes, but it's code that works for Linux in general and I suppose there no better way to handle it other than hardcoding.
<SXX> nacc: so I suppose the right solution would be to getenv SNAP and prepend it to our internal paths?
<nacc> SXX: so, e.g., in my snap, which is classic, i have application wrapper scripts that set PATH appropriately for applications to be found (that are packaged by my snap)
<nacc> SXX: all of my applications are actually just these wrapper scripts that setup the env correctly and then exec the actual application
<SXX> nacc: thanks!
<nacc> SXX: that's admittedly just my way of doing it -- but I think that's also roughly what snapcraft does for classic snaps using plugins (I'm using the dump one currently)
<SXX> Am I getting it right that with some newer snapd if I have app like "vcmi.vcmiclient" it's will automatically get alias of vcmiclient?
<SXX> Or it's will always require user interaction to set alias?
<nacc> SXX: i think vcmi.vmci will become vmci
<SXX> yeah that I know
<SXX> I read on forums before it's was possible to manually add aliases, but it didn't work anymore.
<nacc> SXX: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18?source_topic_id=905
<nacc> SXX: so i think it's now  store thing
<kyrofa> SXX, yeah, best practice is to just write code that is flexible. Not all linux distros follow the same rules for where things go, either. When you find yourself writing an absolute path, add a cli flag or config file property for it, and you can _default_ to the absolute path
<SXX> kyrofa: Do you know how long does it take for reserved names to be reviewed / granted?
<kyrofa> SXX, I'm afraid not, that's in the store team's domain. But if you find it taking an inordinate amount of time, create a forum post in the store category and ask about it
<SXX> kyrofa: no problem, I just sent request so not big deal. I just wonder about that since I not sure if I should wait until it's granted or register temporary name for testing.
<kyrofa> SXX, I do know that it's a manual process. If you're blocked on it, register it as something else. Heck, the store folks might even be able to rename the temporary one you use
<kyrofa> SXX so I say go ahead and register <what-i-want>-sxx or whatever and use that for now
<SXX> Thanks!
<SXX> kyrofa: for the paths we expose way to set custom binary / lib / data paths in our CMake. So other distributions can really use what they want.
<kyrofa> SXX, ah, indeed. Snaps work best when the application is relocatable
<SXX> Though we still need absolute paths by default since that way it's easier to make sure development builds not conflict with installed system-wide.
<SXX> kyrofa: wait, do you mean it's make sense to just make it single-dir windows-like install for snap?
<kyrofa> SXX, hmm... I don't quite understand what you mean
<SXX> kyrofa, I added monolithic install support since I initially wanted to try ship it with Steam Runtime.
<SXX> kyrofa, my attempt is failed since runtime is horrible piece of tech, but I can still just dump game in single directory so it's use relative paths. It's what I use for my development builds so I can run several different builds side-by-side.
<kyrofa> Yeah that sounds promising
<SXX> kyrofa: thanks for your time! I'll still need to solve problem with boost::interprocess somehow, but I have some better understanding what I need to do.
<zyga-solus> hmm
<zyga-solus> zyga@mini:~$ snap version
<zyga-solus> snap    unknown
<zyga-solus> snapd   unknown
<zyga-solus> series  16
<zyga-solus> ubuntu  16.04
<zyga-solus> kernel  4.4.0-93-powerpc-smp
<zyga-solus> we're not setting version on the powerpc build?
<kyrofa> SXX of course, any time
<zyga-solus> this is vanilla snapd on powerpc
<kyrofa> zyga-solus, where on earth did you get a ppc machine? :P
<zyga-solus> kyrofa: it was in my attic
<kyrofa> Mac?
<zyga-solus> kyrofa: I can also say our xenial install media is broken, the trusty one is ok though
<zyga-solus> kyrofa: yep, my mac mini G4
<zyga-solus> aaaancient
<kyrofa> Wow, crazy
<jdstrand> zyga-solus: I left voluminous comments in the PR yesterday
<jdstrand> zyga-solus: and hi :)
<zyga-solus> jdstrand: excellent, thank you
<zyga-solus> jdstrand: I'll check it out tomorrow and iterate
<jdstrand> cool
<jdstrand> zyga-solus: note, tomorrow is a half day for me (working my morning)
<zyga-solus> aha, noted
<zyga-solus> jdstrand: all the comments are (as always) very detailed and sensible, thank you, I will iterate on this tomorrow morning, hopefully by the time you're up it would be something you could re-review
<zyga-solus> hmm
<zyga-solus> zyga@mini:~$ sudo snap install core
<zyga-solus> error: snap "core" not found
<zyga-solus> and mvo worries about ppc test suite
<zyga-solus> it's just totally broken
<zyga-solus> kyrofa: do we build core for ppc?
<kyrofa> zyga-solus, ubuntu-core is
<kyrofa> zyga-solus, not sure about core
<zyga-solus> why ubuntu-core and not core?
<zyga-solus> ah
<zyga-solus> I see
<zyga-solus> I think it's rather terribly broken
<zyga-solus> I wonder how anything passes
<kyrofa> zyga-solus, you're sure you're on ppc64el and not ppc64le or whatever other magical combinations there are?
<zyga-solus> I'm on ppc
<zyga-solus> that's the 32bit powerpc running in big-endian mode
<zyga-solus> and there's snapd preinstalled (xenial)
 * zyga-solus builds 2.27.6-1 for debian
<kyrofa> Just because snapd is preinstalled doesn't mean it's an arch the store supports
<zyga-solus> mwhudson: hey, in case you are around, I'll dput this soon
<zyga-solus> kyrofa: my point is that mvo looses grey hair over ppc (precisely that arch)
<mwhudson> zyga-solus: cool
<zyga-solus> kyrofa: and the elephant in the room is that it's totally broken
<kyrofa> mvo is LOSING hair now?
<mwhudson> zyga-solus: the ubuntu / debian architecture name is 'powerpc' :)
<kyrofa> Isn't he like 30 or something?
<zyga-solus> mvo?
<zyga-solus> heh
<jdstrand> zyga-solus: I can't guarantee I'll be able to get to it tomorrow-- my mornings are typically dominated by reacting to forum, email, irc, etc, but it will certainly remain at the top of the queue
 * zyga-solus always writes that word wrng
<zyga-solus> jdstrand: ack
<zyga-solus> thank you!
<zyga-solus> so, to complete the "hardware from hell" I need the big iron
<jdstrand> np
<mwhudson> zyga-solus: doesn't look like ubuntu-core or core exist for powerpc
<zyga-solus> mwhudson: yeah
<zyga-solus> mwhudson: *oops*
<zyga-solus> not that I care but what does snapd do on that arch there
<mwhudson> so i guess i agree that building the snapd package there is a bit pointless :)
<zyga-solus> then
<zyga-solus> if we must support it then ogra_ should arrange a build
<zyga-solus> and if not we should stop building the package and remove it from the distro and the isos
<mwhudson> i wonder if lp can even build snaps for powerpc
<zyga-solus> I'm curious how we got the "unknown" versions though
<zyga-solus> mwhudson: not without core for sure
<zyga-solus> mwhudson: but I bet it can since it can build packages
<mwhudson> i guess we can build for s390x which similarly only has devirt builders
<zyga-solus> ogra_: still up?
<zyga-solus> mwhudson: are you on ubuntu now?
<mwhudson> zyga-solus: i am on ubuntu always
<zyga-solus> mwhudson: can you check if 2.27.5 has version?
<zyga-solus> as in snap --version
<zyga-solus> my ubuntu laptop is closed now so just more convenient to ask
<kyrofa> zyga-solus, it does
<nacc> zyga-solus: i'm on 17.10
<nacc> http://paste.ubuntu.com/25486607/
<zyga-solus> I wonder how 2.27.5 has such a weird version
<mwhudson> zyga-solus: ah haha i have a test build i made for that pr installed :)
<zyga-solus> thanks nacc
<nacc> zyga-solus: np (taht's the output from `snap --version`)
<zyga-solus> and not that I see 2.27.5 in apt-cache policy, not -1 inherited from debian in some way
<zyga-solus> mwhudson: FYI the 2.27.6 merge was clean, I just copied the changelog from xenial
<zyga-solus> mwhudson: sbuilding now, will dput if green
<mwhudson> zyga-solus: yeah fair enough
<mwhudson> zyga-solus: oh yeah, changelog
<mwhudson> zyga-solus: i think i've been bringing the ubuntu changelog entries over into the debian one
<mwhudson> like the reverse of what happens when ubuntu has a delta from debian
<mwhudson> dpkg-mergechangelogs dtrt i think
<zyga-solus> hmmm, I never tried that
<mwhudson> but it's not very important
<zyga-solus> will it break where debian version is non-native and ubuntu is native?
<zyga-solus> so every other version will flip?
<mwhudson> no, that will make something (dpkg-source? dch?) complain at you but otherwise it's fine
<mwhudson> native/non-native is mostly controlled by debian/source/format anyway :)
<mwhudson> also the ubuntu package really shouldn't be native but ehhh
<zyga-solus> yes I agree strongly
<zyga-solus> it would help with silly releases that just fix debian (xenial really) packaging
 * zyga-solus install sbuild on ppc xenial 
<zyga-solus> let's rebuild this weird snapd
<zyga-solus> and see what we get
<zyga-solus> mwhudson: build passed, pushing to alioth and then dput
<zyga-solus> done
<mwhudson> zyga-solus: \o/
#snappy 2017-09-08
<SXX> Why could std::system in my app fail with "Bad system call" when apparmor is in enforce mode?
<SXX> Oh yeah, totally missed one fact.
<SXX> What is the right way to run another app from within same snap package if they require different plugs?
<SXX> I guess my attempt to make std::system on game server fail because server require network-bind while client that launching it doesn't have such permission.
<SXX> Yeah that's was it.
<mup> PR snapcraft#1414 closed: cmake plugin: call the cmake using build dir as source <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1414>
<zyga-solus> good morning
<zyga-solus> mvo: hello
<zyga-solus> mvo: I'm going to walk kids to school one more time today
<zyga-solus> mvo: but I left you some interesting topics on the forum
<zyga-solus> mvo: I can also give you a shell on the ppc box in case you get curious to try
<zyga-solus> mvo: I'll talk to you soon
<mup> PR snapcraft#1538 opened: tests: update the store failure tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1538>
<mvo> zyga-solus: thanks, see you
<mup> PR snapd#3885 opened: tests: improve the listing test to not fail for e.g. 2.28~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3885>
<mup> PR snapd#3886 opened: tests: make TestCmdWatch more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/3886>
<mvo> jamesh: hey, I think your polkit PR is good to go if we rename the name from "manage-snaps" to just "manage" for now.
<zyga-solus> re
<zyga-solus> mvo: did you see the ppc situation?
<mvo> zyga-solus: yes, "funny"
<zyga-solus> mvo: what are your thoughts on that?
<mvo> zyga-solus: I think we can trivially get a powerpc snap build, we need to ask for it though, I can not enable it
<zyga-solus> mvo: I tried to build master but got a lot of errors on get-deps
<mvo> zyga-solus: but I personally think we should kill it
<zyga-solus> mvo: if you want I can give you a shell on the box
<zyga-solus> mvo: yes, I agree
<mvo> zyga-solus: oh, really?
<zyga-solus> mvo: but I'm afraid we cannot kill it in xenial yet :/
<zyga-solus> mvo: sure, one sec
<zyga-solus> brace yourself for irony
<zyga-solus> # github.com/kardianos/govendor/vendor/golang.org/x/sys/unix
<zyga-solus> ../../kardianos/govendor/vendor/golang.org/x/sys/unix/dirent.go:16:5: error: reference to undefined name âisBigEndianâ
<zyga-solus>   if isBigEndian {
<zyga-solus> (there's 1000s of errors)
<zyga-solus> there are* 1000s of errors
<zyga-solus> this is just one
<zyga-solus> I think that x/sys/unix is broken on ppc somehow
<mvo> zyga-solus: hm, strange, I mean, the debs build
<mvo> zyga-solus: and we reverted to dependencies that do not require x/sys/unix iirc
<mvo> zyga-solus: quick review on 3881 would be great, that should fix builds on arm/ppc
<zyga-solus> great, let me look
<Chipaca> o/
<ackk> hi, I'm hitting https://bugs.launchpad.net/snapd/+bug/1691999, does anyone know what could be causing it?
<mup> Bug #1691999: Snap removal hangs inside LXD container <snapd:New> <https://launchpad.net/bugs/1691999>
<zyga-solus> ackk: hey, I think I know
<zyga-solus> ackk: it's a known issue, there's no fix yet I'm afraid
<ackk> zyga-solus, uh?
<zyga-solus> ackk: there's a bug report with extra details...
<ackk> does that mean snaps inside lxd won't work?
<zyga-solus> it works but that part is broken
<zyga-solus> https://bugs.launchpad.net/snapd/+bug/1712930
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:In Progress by zyga> <https://launchpad.net/bugs/1712930>
<ackk> zyga-solus, can you please mark my bug as duplicate ?
<zyga-solus> sure, which one?
<zyga-solus> ah
<ackk> the one I just pasted
<zyga-solus> done
<ackk> zyga-solus, thanks
<ackk> zyga-solus, unrelated, does snapd keep all old revisions of a snap when it gets updated or is there a limit?
<ackk> I noticed I have 3 versions of core installed
<zyga-solus> that's normal, snapd keeps three revisions of each snap around
<ackk> ah cool, thanks
<mvo> zyga-solus: master is failing on powerpc with new failure modes, its a bit of a whack-a-mole
<ogra_> ppisati, so we'll need another kernel snap rebuild later today, seems the shellcheck stuff that was added to the initrd completely breaks resizing on all GPT devices by adding qutes in "unusual places" ... i'll try to fix that today and will ping you once something is ready (i had to soll back the dragonboard kernel by 7 revisions in all channels to get it back working)
<ppisati> ogra_: ah! i saw some movement in the kernel snap store
<ppisati> ogra_: np, just tell me if you need anything
<ogra_> yeah,. sorry, cachio was desparate since he needed to get core tested
<ppisati> ogra_: that means it affects all images, right?
<Chipaca> hmm, just had snapmgrTestSuite.TestInstallWithoutCoreTwoSnapsWithFailureRunThrough fail at random
<ogra_> it was a bad combo ... 6 versions had the brioken fixrtc and the latest one with the fixed fixrtc had the broken shellcheck stuff
<ppisati> ouch
<ogra_> ppisati, only the opnes with GPT table ...
<ppisati> ogra_: ok
<ogra_> which means well ... only dragonboard or x86 on real devices
<ogra_> and the latter doesnt get tested at all
<ogra_> (x86 always only gets tested with qemu and there we dont esize)
<ogra_> zyga-solus, pong ... :P ... what should i start to build ?
<Chipaca> youch, that test takes 15s+ even when it passes
<ogra_> mvo, as i said yesterday already, we have never built on powerpc, only ppc64el ... whats the reason fr suddenly starting to support it ?
<zyga-solus> ogra_: sec, on the phone
<mvo> ogra_: if we make the "not support it" official we could stop spending time of fixing tests etc
<mvo> ogra_: thats where this comes from
<ogra_> mvo, it has alwaysd been official
<ogra_> mvo, we always had 6 arches since day one ... powerrpc hasnt been one of them
<mvo> ogra_: also in the sense that the distro knows that a broken powerpc build does not block a sru?
<ogra_> i never dealt with the distro srus ... but i know that we never have built core or ubuntu cre or the tarballs for powerpc
<ogra_> on request of mark initially IIRC
<ogra_> the only power arch we ever supported was ppc64el
<Chipaca> pedronis: http://pastebin.ubuntu.com/25488612/ might be of interest to you (happens every ~100 runs, here)
<ogra_> we have 4 arches we build images for (2xarm, 2xx86)  and 2 arches we onyl build core for (s390x and ppc64el)
<ogra_> and we never built for any other arches ...
<ogra_> if you want to get powerpc working all of a sudden that will likely take a lot more work to get a proper core
<zyga-solus> re
 * zyga-solus spent too much time on the phone and needs to spend more time with administrativa, sorry
<zyga-solus> mvo: tests need tweaking
<zyga-solus> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170907_220303_c073c@/log.gz
<zyga-solus> mvo: listing tests now fails on the ~rc2
<mvo> zyga-solus: check the open PRs ;)
<zyga-solus> mvo: aha :)
<mup> PR snapd#3887 opened: snapstate: auto-install missing base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3887>
<zyga-solus> sorry about that :)
<mvo> no worries
<pedronis> Chipaca: ?  it cannot fail that way on 3881
<Chipaca> pedronis: this is off master
<Chipaca> or, yesterday evening's master at least
<pedronis> Chipaca: well we made 3881 related to that
<pedronis> 3881 is a combination of PRs
<pedronis> to try to make that test saner
<pedronis> at this point we are more interested if it fails on 3881
<pedronis> not master
<Chipaca> pedronis: ah ok
<Chipaca> pedronis: i was just running tests on snapstate for the revert work and kept on tripping that one up
<pedronis> try 3881 please
<pedronis> zyga-solus: why do you appreciate full sentences in comments ?  that rule is mentioned in effective go for doc comments
<Chipaca> pedronis: as in, rebase on it and carry on doing my thing?
<pedronis> Chipaca: are you trolling again ? :)
<pedronis> IÂ don't if you can carry
<pedronis> it might not fix things for you
<Chipaca> pedronis: no! i came across that panic by doing my thing on master, do you want me to rebase on 3881 and carry on (and let you know if i see the error again), or do you want me to actively pursue the bug?
<pedronis> which bug?
<Chipaca> the panic
<mvo> pedronis: do you think 1715824 might be something I could add to the store? it seems pretty trivial and I would love to see it getting done asap
<mvo> Chipaca: panic in snapstate_test.go:77 ? that is fixed with 3881
<pedronis> Chipaca: that panic is probably the test taking to long for you
<Chipaca> ok, so no need for me to try it; i can just ignore it
<pedronis> Chipaca: I asked it to try, if you hit the bug you tell us
<pedronis> Chipaca: sorry, it sounded like it was blocking your work
<Chipaca> ah! no
<Chipaca> this is a little gem from my work:
<Chipaca> 	s.testRevertTasksFullFlags(flags, flags, flags, flags, c)
 * Chipaca grins and carries on
 * zyga-solus_ goes to fix the test suite on golang 1.9
<ogra_> davidcalle, wheer in the world is the configure hook described in our docs (i'm searching my ass off, there doesnt even seem to be a mention anywhere)
<jamesh> mvo: sorry, I missed your message.  I'll go ahead and change the polkit action ID.  Do you want me to squash the commits too?
<pedronis> jamesh: we'll just squash merged usually
<pedronis> *merge
<davidcalle> ogra_: hey, two places for now. https://docs.ubuntu.com/core/en/guides/build-device/config-hooks and https://snapcraft.io/docs/build-snaps/hooks which are being unified + install and remove hooks under the latter. Funny you are asking that right now, because I've spent the week debugging install hooks with pstolowski for this exact purpose
<mvo> jamesh: thanks, what pedronis said, we will sqush merge and then I can cherry pick for 2.28
<davidcalle> ogra_: btw, are you happy with how the two pi images are described on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3
<ogra_> davidcalle, perfect ... i hope we can get rid of it eventually :)
<davidcalle> Heh
<Chipaca> the expectation, if you have a snap installed in devmode, is that revert with no devmode would leave you still in devmode, right?
<Chipaca> i.e. snap install foo --devmode; snap refresh --edge foo --devmode; sanp revert foo -> is foo installed in devmode?
<pedronis> I suppose,  but it's a bit of an open question, IÂ mean IÂ have seen it argued differently for other flags at points
<pedronis> sounds something to clarify with Gustavo once for all when he is back
<Chipaca> now change --devmode to --classic
<Chipaca> :-)
<pedronis> yea, I have heard incosistent thing about this over time
<pedronis> I'm not surprised we do random things
<pedronis> Chipaca: how do you remove --devmode again?
<Chipaca> I shall comment in the forum topic
<Chipaca> pedronis: --jailmode
<ackk> I'm looking at the snapcraft source code (specifically the snapcraft.yaml schema), I can't find any reference to the socket activation options (socket, listen-stream). am I looking in the wrong place?
<pedronis> that's a flag too though?
<Chipaca> pedronis: the refresh itself without --devmode will drop the flag
<pedronis> Chipaca: how does one get back to all false flags ?
<Chipaca> pedronis: but that doesn't work for jailmode, for example
<pedronis> Chipaca: ah, refresh is flag dropping? but we want to change that area when we allow devmode refreshes
<Chipaca> only for devmode
<Chipaca> is it dropping
<pedronis> but see, we are changing that
<pedronis> what a mess
<Chipaca> :-)
<Chipaca> we need a table
 * Chipaca writes a table
<pedronis> thanks
<pedronis> I'm keenly intrested because  --ignore-validation shall become sticky and then there are similar questions
<pedronis> how do you drop it?
<ogra_> ackk, i think that doesnt exist anymore ... nowadays you just use the network and network-bind interfaces and let your app just do what it needs
<pedronis> do we need a 2nd flag
<pedronis> etc
<ogra_> ackk, these optins in snapcraft.yaml were a 15.04 thing
<ackk> ogra_, oh, I saw them mentioned on the website doc
<ogra_> that might be a bug (not sure)
<pedronis> Chipaca: see jocave's comment at the end of this bug:  https://bugs.launchpad.net/plano/+bug/1710552
<ackk> ogra_, so, what about https://bugs.launchpad.net/snapd/+bug/1612440 ?
<mup> Bug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Confirmed> <https://launchpad.net/bugs/1612440>
<pedronis> Chipaca: IÂ mean, we need a table but hopefully users don't need to consult it
<ackk> ogra_, (I was looking at adding the missing keys since we need it for lxd)
<Chipaca> right, the table is for us
<Chipaca> for the coding
<ogra_> ackk, well, that report is from 2016, not sure these keywords mentioned exist anymore ... you'd have to ask the snapcraft guys on rocket.ubuntu.com (in the #snapcraft channel)
<ackk> ogra_, no I mean, how could we solve that issue (not about the keys specifically), lxd would need socket activation so that the daemon is not started if it's not used
<ogra_> ackk, note that there was a massive change between 15.04 and 16, where many things got dropped and re-done from scratch, this might be among them ...
<ogra_> this could be among them ... (read: old implementation was dropped, new one doesnt exist yet)
<ackk> I see
<ogra_> talk to the snapcraft guys
<ogra_> and perhaps open a topic on the forum (see channel topic for the link) to get wider coverage
<pedronis> mvo: is the error in tests/main/listing  fixed now? because of ~rc2
<ogra_> i know that for general socket usage we switched over to the network-bind interface ... but i'm not sure that covers socket activation
<zyga-solus> ugh, arch doesn't have "shadow" group anymore
<mvo> pedronis: there is a open PR with the fix
<pedronis> ah
<mup> PR snapd#3888 opened: osutil: adjust StreamCommand tests for golang 1.9 <Created by zyga> <https://github.com/snapcore/snapd/pull/3888>
<pedronis> mvo: so 3881 has passed travis but has failed many of the other because of the ~rc2
<pedronis> mvo: do we just merge it?  merge the rc2 fix and run it again?
<mvo> pedronis: I can just merge it, maybe thats the bets
<mup> PR snapd#3881 closed: snapstate: give snapmgrTestSuite.settle() more time to settle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3881>
<mvo> pedronis: best even (sorry, typo)
<mvo> Chipaca: look like 3835 just needs a second review and is good to goâ¦
<sborovkov> ogra_: hi, is there any way to debug why splash is not showing? I am seeing uboot first now. Then nothing new shows up until my snap takes over. I've done git diff against your branch and there does not appear anything different in the build process pr snapcraft. So merge looks correct. But no splash :-(
<ogra_> sborovkov, even with my pre-built snap ?
<ogra_> (or if you use my default png in your tree)
 * ogra_ needs to go afk for like 20-30min ... brb
<zyga-solus> mvo: I tweaked 3888
<zyga-solus> force pushed for easier cherry picking
<mvo> zyga-solus: aha, nice
<mvo> zyga-solus: small comment maybe why we have the "|" in the regexp
<Chipaca> mvo: and a push to tweak the package description as per #3882
<mup> PR #3882: debian: improve package description <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3882>
<zyga-solus> ok
<mvo> zyga-solus: and feel free to force push
<mvo> Chipaca: \o/
<Chipaca> zyga-solus: could yo finish your review of #3835?
<mup> PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835>
<mvo> zyga-solus: thanks a lot!
<zyga-solus> done
<mvo> looks like travis is currently slow in giving us jobs :/
<zyga-solus> mvo: yes
<zyga-solus> mvo: :/
<pedronis> also yesterday
<mvo> yeah
<zyga-solus> must be Friday
<pedronis> it was Thursday
<sergiusens> mvo it has been slow for us too
<pedronis> we should probably try to merge a bunch
<pedronis> before adding more
<zyga-solus> mvo: I'm struggling with cmd/snap-seccomp tests, unfortunately it seems that the only user/group we can rely on is "0/root"
<zyga-solus> mvo: shadow is not even present on arch and various other users/groups have random values
<mvo> zyga-solus: isn't adm also defined in the FHS or somewhere? but yeah, passwd is a mess
<zyga-solus> mvo: yes but there's no fixed value
<zyga-solus> in any case, I can distro-patch for arch for now
<zyga-solus> and ponder without rush
<zyga-solus> I need to break for taxes now
<pedronis> mvo: is the snapctl get change in  2.28 ?
<pedronis> or only edge?
<mvo> pedronis: what change is that?
<pedronis> pstolowski's PR
<mup> PR snapcraft#1538 closed: tests: update the store failure tests <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1538>
<mvo> pedronis: you mean 3642? that is master
<mvo> pedronis: do we need it for 2.28?
<sborovkov> ogra_: yeah I tried with default png as well, does not work. Where can I get prebuilt snap? I can try it I guess
<pedronis> mvo: no, but it might have broke stuff
<pedronis> indirectly
<pedronis> in which case we might have had a regression
<pedronis> but is not yet in 2.28
<pedronis> anyway
<mvo> ok
<pedronis> travis is very non helpful
<sborovkov> ogra_: ah, right in the bug. Going to try it
<pedronis> mvo: see internal
<zyga-suse> Chipaca: hey, perhaps interesting: https://github.com/posener/complete
<zyga-suse> pedronis: that rule == the rule to use full sentences or not to use them?
<pedronis> zyga-suse: yes, just curious, as far as IÂ know our non doc comments are all over the place
<ogra_> re
<pedronis> zyga-suse: as I said I see it as strict rule for doc comments
<sborovkov> ogra_: alright, it works with your prebuilt snap. thought it does not scale good
<ogra_> well, i assume you want to use a smaller png anyway :)
<ogra_> sborovkov, so to debug this ... attach serial to your pi ... add "break=premount" to the end of the line in cmdline.txt ... then boot and you should get a shell prompt where you then can run /bin/psplash manually and such
<ogra_> i.e. inside the initrd
<sborovkov> ogra_: that's how it looks like btw https://www.dropbox.com/s/2fbdrd8wg4coudj/photo_2017-09-08_13-13-06.jpg?dl=0
<ogra_> sborovkov, heh, you are on a *eally* low resolution :)
<ogra_> *really
<sborovkov> ogra_: ehh, I don't have working serial at the moment. Ordered one from aliexpress recently. For some reason they sent me USB stick lol. Viktor has it, so may be he will debug it. I will try to figure out what else can be different in our snaps
<sborovkov> yeah it does not detect that my monitor is 1080p, I have to manuallt adjust hdmi_group and hdmi_mode
<ogra_> sborovkov, might be that we need to adjust the psplash patch for you to actually default to a lower res ...
<ogra_> oh, you guys actually tinker with config.txt settings for hdmi
<sborovkov> ogra_: the thing though is that Rpi zero has lower resolution
<ogra_> that might inded have some influence on what info the framebuffer device gives to psplash
<sborovkov> oh!
<sborovkov> interesting
<sborovkov> that's what I have in config.txt
<sborovkov> one sec
<ogra_> oour default pi gadgets dont set anything in that regard
<sborovkov> https://hastebin.com/higumepuqa.makefile
<ogra_> framebuffer_height=0
<ogra_> framebuffer_width=0
<ogra_> framebuffer_ignore_alpha=1
<sborovkov> i need fb_ignore_alpha for sure though
<ogra_> the png is clearly using an alpha channel ...
<ogra_> well, and make your own guess about width and height :)
<sborovkov> qt apps have horrible banding if it's not set
<sborovkov> alpha is not necessary for us anyway I guess
<sborovkov> so height and width
<ogra_> sure, but if there is an alpha channel in the png it will be used i guess
<ogra_> so when doing your own splash, try to have an alpha-less png
<ogra_> but i'D start with the width/height fist ...
<ogra_> *first
<ogra_> try dropping them in your own build and see if that changes something
<sborovkov> yup that's what I am trying now
<ogra_> hmm, also ... hdmi_mode=0 ...
<ogra_> that might alsoo be a prob
<sborovkov> hmm
<sborovkov> I can comment that out as well
<ogra_> try the width/height standallone first
<ogra_> that might already solve it
<sborovkov> ok
<pedronis> Chipaca: can you look at #3886 IÂ think it's reasonable but not great (it tests less)
<mup> PR #3886: tests: make TestCmdWatch more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/3886>
<ogra_> if niot we can move ove the other options ... (and then think about hoow to modify psplash to work with your setup)
<Chipaca> pedronis: not right now, sorry
 * ogra_ wonders if he'll need a new kbd soon ... seems to swallow some chars and others are duplicated even when i only press the key once
<Chipaca> too much state
<Chipaca> later
 * ogra_ notes that cherry switches dont seem to be what they used to be ... 
<pedronis> mvo: do we share limits with spread-cron?Â is it scheduling too much:  https://travis-ci.org/snapcore/spread-cron/builds
<sergiusens> pedronis I wonder if we are hit by this given we are in the same org...
<sergiusens> there is a shared pool of travis runners at the project/repo level, not sure if there is also tie in to the org
<mup> PR snapd#3889 opened: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3889>
<mvo> pedronis: that sounds likely actually - we are the same org
<sborovkov> ogra_: hmm, no, just commenting out those changes did not help. I am also getting warning about misaligned buffer address right after "reading psplash.img", not sure if that's relevant though
<ogra_> sborovkov, that is a "normal" discepancy between uboot and the kernels FAT implementations ... nothing to worry about
<ogra_> sborovkov, so try dropping more from config.txt
<ogra_> i'd move on with the hdmi_mode
 * zyga-solus lunch
 * ogra_ sighs ... 
<ogra_> i wishh i'd understand why zyga-solus's overzealous quoting broke resize fo GPT's
<Chipaca> ok, i'm stopping for lunch
 * ogra_ cries
<Chipaca> https://docs.google.com/spreadsheets/d/1jw-hsAK1ymUfpnI7MD7ML7CQcwq0KSBvGw_gf6_TmYM/edit <- if you want to have fun
<Chipaca> where "fun" means "gouge your frontal lobe out with a blunt weapon"
<Chipaca> (there's a forum post in the works to explain that sheet)
<ogra_> (i know how to fix it but i dont know why it breaks at all in the first place )
<ogra_> :(
<diddledan> I'm trying to get a heisenbug resolved. the program runs normally when using either strace or gdb, but fails as soon as I try it normally
<diddledan> ogra_: this is your fault. I'm working on ring
<diddledan> :-p
<ogra_> just package it with strace in the snap and add strace to the wrapper script :P
<diddledan> lol
<ogra_> diddledan, i fear we have to wait for working dbus activation
<diddledan> I think that's not quite the right way to do things :-p
<Chipaca> i... might have actually shipped something that ran under strace, once
 * Chipaca was young and needed the money
<ogra_> Chipaca, how good is your shell-quoting-fu ?
<Chipaca> ogra_: 7
<pedronis> mmh, travis has this on their status page:  Build delays due to GitHub outage
<diddledan> damn, I'm only 6
<diddledan> github?? dead??!
<diddledan> https://www.youtube.com/watch?v=kLzC3nPhUEM
<Chipaca> ogra_: enough to know that "$PATH:${GOBIN:-${GOPATH%%:*}/bin}" is valid sh, but not enough to know not to use it
<ogra_> Chipaca, when zyga-solus added shellchek he also added a lot of quoting to our resize script http://paste.ubuntu.com/25489386/ ... as you can see in line 28 there is "$resizeopts"
<Chipaca> mhmm
<ogra_> Chipaca, in case of gpt's resizeopts is unset while for mbr's we have resizeopts="-f"
<Chipaca> yes
<Chipaca> and
<Chipaca> that's a bug
<Chipaca> probably
<ogra_> now ... when trying to resize a gpt devices it ends up like:
<Chipaca> because, i imagine, resize2fs does not know what to do with an empty argument
<ogra_> resize2fs 1.42.13 (17-May-2015)
<ogra_> open: No such file or directory while opening
<ogra_> and i dont get why
<Chipaca> ogra_: try this: resize2fs ""
<ogra_> but it isnt an empty argument
<ogra_> hmm
<ogra_> ogra@localhost:~$ resize2fs "" /dev/mmcblk1p9
<ogra_> resize2fs 1.42.13 (17-May-2015)
<ogra_> open: No such file or directory while opening
<ogra_> ogra@localhost:~$
<ogra_> wow
 * Chipaca bows
<ogra_> but that looks rather like a bug in resize2fs
<Chipaca> why? it's literally being passed an empty string as an argument
<Chipaca> it's perfectly valid to error out on that
<ogra_> why would it interpret "" ass an arg
<diddledan> I agree, let them fix it :-p
<Chipaca> ogra_: it's not "interpreting", it's being given that as an arg
<ogra_> but it isnt even an empty string ... it is a string of zero lenght
<Chipaca> you're explicitly giving it an empty argument
<pedronis> that's who the shell works
<pedronis> s/who/how/
<Chipaca> ogra_: what is the difference between an empty string and a string of zero length?
<ogra_> i'd expect the latter to be filtered when parsing args
<pedronis> that's not how things works
<pedronis> usually
<diddledan> you need to conditionally include it: https://paste.ubuntu.com/25489423/
<ogra_> if i'd add " " i'ÃD agree it is an empty string
<pedronis> that's not an empty string
<pedronis> it's a 1-space string
<Chipaca> ogra_: " " is not an empty string ! :-)
<Chipaca> anyhow!
<Chipaca> let's move on to how to fix it, yes?
<ogra_> diddledan, i need/want to add -p anyway for both resize cases (to get better logs), so the fix is clear
<ogra_> diddledan, my prob is that i dont understand the behaviour
<diddledan> "" is an empty string - which means it is, in C-style "\0"
<diddledan> i.e. it includes a null termination
<ogra_> Chipaca, http://paste.ubuntu.com/25489429/ is my fix ...
<Chipaca> ogra_: try this: for i in "" "" ""; do printf "%q\n" "$i"; done
<pedronis> or try rm ""
<pedronis> it all works the same
<Chipaca> mhmm
<ogra_> yeah, you guys are right ..
<diddledan> putting quotes on a bash commandline, even with no contents is saying "I want an argument here". If it didn't explicitly create empty arguments then you can't check that a variable is "empty"
<ogra_> (i never use quotes for args ... but shellcheck freaks out if you dont)
<ogra_> (so i never had to bother with that)
<pedronis> that's why quoting is not always the right thing
<Chipaca> ogra_: that's ok, everybody has blind spots
<ogra_> tell that to shellcheck :P
<ogra_> if there is a $ it wants a quote :)
<Chipaca> ogra_: you _can_ tell that to shellcheck!
<ogra_> i know
<ogra_> anyway, i want more verbosity anyway for the logs, so just adding -p for the gpt case is fine
<Chipaca> ok :-)
<pedronis> I'm still not sure what adding -p means
<pedronis> depending it might not solve the problem
<Chipaca> progress, probably
<ogra_> print all actions
<pedronis> or create new ones
<ogra_> it does
<Chipaca> ummm
<Chipaca> ogra_: that does not work either!
<ogra_> i tested it already
<pedronis> Chipaca: not what it means to resize2fs, more how it's getting added
<Chipaca> because there is no option "f -p"
<ogra_> bah, crap
<Chipaca> ogra_: you want "-fp"
<ogra_> (i didntz test on mb indeed)
<pedronis> you cannot quote multiple args together
<ogra_> *mb
<ogra_> BAH
<ogra_> *mbrr
<pedronis> there are various approaches, it all depends
 * Chipaca hugs ogra_ 
 * Chipaca steals ogra_'s wallet
 * ogra_ needs a new kbd ... sniff
<ogra_> this kbd isnt a year old yet ... but l and o are producing double presses and r is ignored every now and then
<Chipaca> ogra_: take the peanut shells out from under the keys
<pedronis> that's also why "$*" and "$@" are not the same
<ogra_> yeah, that i know
<Chipaca> is the magic expansion of "$@" a bashism, or is that posix?
<pedronis> so quoting solves some issues, creates other
<ogra_> thats poosix afaik
<Chipaca> and if it's posix, does that mean other shells also have arrays?
<Chipaca> because arrays would solve the whole thing :)
<ogra_> only for args i think
<Chipaca> bah humbug
<Chipaca> this is why people use eval
<ogra_> mvo, oh, btw ... https://github.com/snapcore/core-build/pull/17 is waiting for your approval (that was the one i was holding back yesterday)
<mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<ogra_> (i'd like to land that one before the resize fix)
<pedronis> Chipaca: ogra_: is this bash or something else?
<ogra_> pedronis, posix (ash)
<mvo> ogra_: one question, then good to go. is the resize fix up as well? and what was it? do we need a new release for that?
<ogra_> mvo, i'm not sure what channel kernel snaps use to obtain the initrd, if it is stable then yes
<ogra_> mvo, i thin Chipaca needs to answer your question on thhe PR ... afaik the dir is empty in the squashfs initially
<Chipaca> me what?
<zyga-suse> ogra_: hmm? GPT? quoting?
<ogra_> zyga-suse, yep
<zyga-suse> what did I do?
<ogra_> fix is pending, all fine
<mup> PR snapd#3885 closed: tests: improve the listing test to not fail for e.g. 2.28~rc2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3885>
<zyga-suse> aha, thank you !
<ogra_> zyga-suse, http://paste.ubuntu.com/25489461/ line 29 ...
 * mvo grumbles about the amount of travis slots we get
<ogra_> zyga-suse, in GPTs the resizeopts var is unset ... the quoting turns it into an empty arg though
<ogra_> Chipaca, https://github.com/snapcore/core-build/pull/17
<mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<jdstrand> zyga-suse: in snap-seccomp, today there are 3 users/groups we care about: root, daemon and shadow. root and daemon are supposed to exist everywhere based on the LSB. shadow is not guaranteed to exist
<cjwatson> "" around $ is an excellent heuristic, but you need to use judgement.  doesn't shellcheck have a way to override it?
<zyga-suse> jdstrand: in addition the values of shadow and daemon are not constant
<mup> PR snapd#3886 closed: tests: make TestCmdWatch more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3886>
<ogra_> cjwatson, it does ... but i want the var set in the other case too so it is fine
<jdstrand> zyga-suse: if 'daemon' is not '1', then we need to use FindGid() for it like we do with shadow in main_test.go
<ogra_> cjwatson, my prob was that i didnt understand the fact that "" becoomes an empty arg that gets actually parsed
<zyga-suse> jdstrand: yes, I think that's a simple fix
<jdstrand> zyga-suse: if shadow isn't present at all, what is the group for /etc/shadow on arch?
<cjwatson> if you spend any time working with shell I strongly recommend spending some time understanding how argument handling actually works
<zyga-suse> jdstrand: root.root
<zyga-suse> jdstrand: well, root to answer your question
<jdstrand> well, that's goofy
<ogra_> cjwatson, well, before we added shellcheck everywhere i didnt even have the idea to quote in that place
<cjwatson> yeah but this is quite basic stuff :)
 * zyga-suse recalls that "someone is wrong on the internet" thing
<cjwatson> specifically with relation to the underlying libc's argv handling
<jdstrand> zyga-suse: ok, so then on arch, in template.go, we make 'shadow' distro-specific
<jdstrand> zyga-suse: let me put that another way
<zyga-suse> jdstrand: I'd just use something else, like bin or daemon
<jdstrand> zyga-suse: I figured that some distros would use a different group for /etc/shadow
 * zyga-suse listens
<cjwatson> shellcheck is absolutely right about this quoting policy in general
<mup> PR snapcraft#1539 opened: nodejs plugin: expose hidden bin path when using yarn <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1539>
<jdstrand> zyga-suse: sorry, interfaces/builtin/account_control.go
<zyga-suse> jdstrand: aha, I see, that part needs to get smarter
<zyga-suse> jdstrand: what happens if we add two seccomp arg filtering rules?
<jdstrand> zyga-suse: so, in account_control.go, I figured instead of hard coding 'g:shadow' in the accountControlConnecctedPlugSecComp, we do: 'g:%s', default to 'shadow' and then have a distro mapping for arch to set it to 'root'
<zyga-suse> jdstrand: yeah, that's doable
<zyga-suse> ugly but necessary
<jdstrand> zyga-suse: it isn't ugly
<zyga-suse> well, ugly as in "it's ugly we need this"
<jdstrand> zyga-suse: it is what is needed to handle cross-distro
<jdstrand> well, yes, it would be nice if 'shadow' was standardized, sure
<zyga-suse> I'll make that patch and once it lands upstream I'll put it into 2.27.6
<ogra_> cjwatson, well, i think using allags="-a -b -c"; command $allargs... is not actually uncommon
<jdstrand> we're going to see more and more of this sort of thing when cross-distro becomes strict
<jdstrand> some things we can just add to the policy (oh, /etc/foo is /etc/foo.d on this distro, just allow both), but sometimes we'll want something like this
<cjwatson> ogra_: Sure, but it's an exception compared to general use of $-expansions
<ogra_> indeed
<pedronis> that where eval is useful sometimes
<pedronis> it reparses
<ogra_> yep
<cjwatson> IME once you get to that point it's time to rewrite in a language that lets you control the argument list explicitly
<cjwatson> (and I've written a *lot* of shell - I'm not against its use in principle)
<jdstrand> zyga-suse: in cmd/snap-seccomp/main_test.go, you'll want to either make the g:shadow tests conditional on 'is !arch', or on 'is ubuntu|debian' or turn the mapping into a function (eg, shadowGroup() exported as ShadowGroup())
<jdstrand> zyga-suse: the latter seems best
<zyga-suse> jdstrand: I agree
<pedronis> well shellcheck recommendation basically are based on everything coming from the outside
<zyga-suse> jdstrand: I tried several simpler things but went nowhere and realized this needs to be really dynamic
<jdstrand> zyga-suse: with those small changes, you should be all set
 * zyga-suse is a bit sleepy today and nervous about doing taxes for the first time in $eons
<ogra_> is spain tax-free country ?
<zyga-suse> ogra_: I'm back in Poland now
<jdstrand> zyga-suse: sorry I wasn't awake when you started on this-- I knew we'd have to do something like this (I think I mentioned it in the PR, but maybe not)
<zyga-suse> ogra_: managing my own business
<ogra_> zyga-suse, yeah, but didnt you do taxes in spain ?
<zyga-suse> ogra_: yes but I now have to do them in two places
<pedronis> mvo: are you going to revisit #3865 ?
<mup> PR #3865: many: provide systemd.MockSystemctl() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3865>
<zyga-suse> ogra_: my monthly taxes are now in Poland
<ogra_> ouch
<zyga-suse> ogra_: and my yearly taxing will be done in Spain, this one time
<zyga-suse> ogra_: then next year just here
<ogra_> oh my
<pedronis> double taxes are not fun
<zyga-suse> not double in the typical word, I only get taxed once
 * ogra_ guesses you could pay someone doing them for you 
<zyga-suse> but I must complete the yearly cycle in Spain
<zyga-suse> as I'm a spanish resident despite being here now
<zyga-suse> it's decided by the number of days per year one inhabits a given country
<mvo> ogra_: if you are still unclear about the "why" of the behaviour it might be useful to look at: $ strace -e trace=execve true $a ; strace -e trace=execve true "$a" that might be useful
<zyga-suse> ogra_: it's not like most people know and I wanted to learn how this works a little bit
<jdstrand> zyga-suse: I don't think we want to overengineer today cause we don't know for sure what we are going to see as more and more distros go partial/strict, so what I just outlined imo should be all we do now. but, maybe we can have in the back of our mind how to handle this if there are a lot
<mvo> pedronis: I though I did, let me look at this again
<ogra_> mvo, no, i'm fine
<zyga-suse> jdstrand: I need something basic for now so that unit tests on arch pass again
<zyga-suse> jdstrand: there's been a wave of updates there
<ogra_> mvo, just waiting for an answer from Chipaca on the PR and then i'll prepare the resize one
<pedronis> mvo: there are a few small comments by me and a conflict
<zyga-suse> jdstrand: golang 1.9, pulseaudio 11, tons of stuff
<Chipaca> ogra_: on which pr?
<ogra_> (and roll up the deb and do a core ebuild etc etc)
<mvo> pedronis: yeah, sorry for this, either I forgot to push or I was dreaming that I already fixed it. on it now
<ogra_> <ogra_> Chipaca, https://github.com/snapcore/core-build/pull/17
<mup> PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
<jdstrand> zyga-suse: eg, do we want to have the dynamic stuff defined in the interfaces themselves, or do we want to have a distro.go file (or something) which is a one stop shop for these things (eg, it would have shadowGroup() and the mapping, and any other functions like shadowGroup() and their mappings)
<jdstrand> zyga-suse: fun!
<zyga-suse> jdstrand: I think distro go is nicer and mirrors our approach for packages in spread tests (also centralized)
<zyga-suse> jdstrand: though I wonder if we should just stat files in specific modules
<zyga-suse> jdstrand: and not build and maintain large tables
<zyga-suse> jdstrand: I'll start small, just to fix unit tests
<zyga-suse> jdstrand: I'll re-think this when I look at the interface problem
<Chipaca> ogra_: like so?
<ogra_> ??
<zyga-suse> jdstrand: note that especially for arch where things move all the time and it might be root.shadow before I land this ;)
<ogra_> ah, GH is slow updating
<jdstrand> zyga-suse: for pulseaudio, I suspect that would just be additional rules (that is what we would do in abstractions/audio, for example)
<zyga-suse> jdstrand: I need to see what changed first, note that arch doesn't support apparmor yet so not everything is broken
<zyga-suse> darn, I just realized why I'm sleepy
<zyga-suse> I was so sleepy I made ... chocolate milk instead of coffee
<jdstrand> zyga-suse: stat would certainly be the most dynamic, but I'm not sure I care for that
<zyga-suse> jdstrand: care as in you'd rather not see it or you don't mind seeing it but there's no urgency?
<jdstrand> zyga-suse: if arch is changing that much, we could perhaps add multiple rules, or try rules in order if range in shadow, root, foo, bar, then stat to see if it matches
<jdstrand> maybe that could work...
<zyga-suse> jdstrand: is the seccomp bytecode generator smart to combine rules?
<zyga-suse> jdstrand: and if so, what is the join function, AND or OR?
<jdstrand> zyga-suse: I don't think there is any urgency for all of this extra discussion. I suggest doing what we siad (shadowGroup()) and be done with it. the more we see, the more info we'll have to see where we want to go
<zyga-suse> jdstrand: say we allow chown root; chown shadow
<zyga-suse> jdstrand: how does that behave/combine
 * zyga-suse nods on jdstrand's point about urgency
<jdstrand> zyga-suse: think of it more like a list to match against
<zyga-suse> aha, so OR?
<pedronis> sounds like we need the system key stuff mvo was working on
<pedronis> to do that though
<jdstrand> I don't think it is implemented as a join function but if you want to think of it as OR, then ok
<ogra_> Chipaca, followup question ...
<zyga-suse> pedronis: yes, that's a possiblility
<ogra_> (on the P)
<ogra_> *PR
<mvo> pedronis: I can resurrect this work
<jdstrand> zyga-suse: because it is a list to match against, we have to be careful with '-' in the policy
<jdstrand> zyga-suse: eg chown - u:root -
<jdstrand> zyga-suse: that would allow chown to any group
<zyga-suse> right
<zyga-suse> essentially * swallowing "root"
<jdstrand> '-' can be thought of a glob, yes
<jdstrand> but, all that comes as part of PR review
<jdstrand> just don't use '-' for arch and we'll be fine :)
<ogra_> mvo, is the explanation on the PR fine with you ?
<jdstrand> zyga-suse: curious, what uid/gid is daemon in arch? in solus? in suse?
<zyga-suse> jdstrand: so... (not sure if those are constants or just particular values on my machines)
 * jdstrand was under the impression it was '1' everywhere, but the LSB doesn't actually seen to define the uid/gid
<jdstrand> seem*
<mvo> ogra_: fine with me
 * ogra_ merges
<mup> PR core-build#17 closed: switch /etc/systemd/system to "synced" mode <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/17>
<jdstrand> zyga-suse: I see now that only root is defined to be '0', so we'll want daemon_uid := FindUser('daemon') and daemon_gid := FindGroup('daemon') in main_test.go
<jdstrand> zyga-suse: is that and shadowGroup() something you want me to do or are you on it?
<zyga-suse> jdstrand: daemon, on openSUSE is 2, on solus is 6 and on arch it is 2
<zyga-suse> jdstrand: sorry, arch took a while to boot
<zyga-suse> jdstrand: and on fedora...
<jdstrand> interesting
<zyga-suse> jdstrand: yeah, I'd really welcome some standardization but then again, data migration is a pain
<pedronis> mvo: github says the conflict is still there
<mup> PR core-build#18 opened: fix resize for GPT, be more verbose for logging <Created by ogra1> <https://github.com/snapcore/core-build/pull/18>
<mvo> pedronis: oops, one sec
<ogra_> mvo, ^^^ the resize fix
<mvo> ogra_: heh, like how this is fixed
<ogra_> ;)
<mvo> pedronis: fwiw, the fact that we don't get travis slots also means we only get very slow updates into the edge ppa :/ spread-cron will only push there after master got a travis run that is green and because that takes hours currently those updates also take hours
<mup> PR snapd#3890 opened: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <https://github.com/snapcore/snapd/pull/3890>
<ogra_> zyga-suse, mind to sign off https://github.com/snapcore/core-build/pull/18 ?
<mup> PR core-build#18: fix resize for GPT, be more verbose for logging <Created by ogra1> <https://github.com/snapcore/core-build/pull/18>
<pedronis> mvo: :/
<zyga-suse> ogra_: what is '-p' being passed to? what does it do?
<mup> PR snapd#3891 opened: daemon: reach for Overlord.Loop less thanks to overlord.Mock <Created by pedronis> <https://github.com/snapcore/snapd/pull/3891>
<ogra_> zyga-suse, http://paste.ubuntu.com/25489461/ it makes resize2fs print all actions to the log (called "progress" in the manpage, but its not actually a progress indicator when redirected, just a "i'm doing this now" printout)
<pedronis> mvo: there are also unit tests problems on that branch
<jdstrand> zyga-suse: was that 'yeah' for me to do the work?
<pedronis> mvo: funnily artful-i386 is quite fast at running unit test
<jdstrand> zyga-suse: note that for daemon, we don't have the same problem as with shaodw-- it will exist everywhere
<zyga-suse> jdstrand: ah, I didn't notice your proposal to do that. I can do it later when I'm looking at arch (~Monday), if you want to tackle that before that's fine
<zyga-suse> jdstrand: I will carry it as a distro patch there to bake
<jdstrand> zyga-suse: I don't foresee specifying a lot of users and groups in the policy, so there should only be shadow for a while, then maybe a couple more down the line
<zyga-suse> jdstrand: yes, fortunately :)
<jdstrand> zyga-suse: the other users will all be the ones managed by snapd, so no problem
<zyga-suse> ogra_: commented on the PR now
 * ogra_ sighs deeply 
<mvo> pedronis: yeah, I noticed and should be good now as well, I will double check though
<zyga-suse> ogra_: hint hint: https://github.com/snapcore/core-build/blob/master/initramfs/testing/aaa-tests.py
<zyga-suse> ogra_: try writing a real test
<mup> PR snapd#3892 opened: systemd: add systemd.MockJournalctl() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3892>
<zyga-suse> well, a real unit tests
<pedronis> mvo: still failing:  FAIL	github.com/snapcore/snapd/overlord/snapstate/backend [build failed]
<pedronis> or github confused me again
<mvo> pedronis: probably legit, I need more tea
<Chipaca> mvo: pedronis: stdup?
<Chipaca> pedronis: oh hi
<pedronis> mvo: standup?
<mvo> pedronis: yes omw
<mup> PR core-build#18 closed: fix resize for GPT, be more verbose for logging <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/18>
<sborovkov> ogra_: damn ittttt. issue is not in config.txt. Something going wrong when psplash.img is built
<sborovkov> ogra_: tried everything with config.txt options
<ogra_> sborovkov, weird
<sborovkov> then I just replaced my psplash.img
<sborovkov> with yours
<sborovkov> and splash showed up
<ogra_> hmm
<ogra_> sborovkov, how are you building ?
<ogra_> on a PC ?
<ogra_> or natively onm the pi
<sborovkov> on a pc, inside docker container
<sborovkov> xenial-amd64 is used as an image
<ogra_> well, that should result in the same binary
<sborovkov> it is not
<ogra_> lzcat psplash.img | cpio -i
<ogra_> do that for both (in different tmpdirs, else one overwrites the other)
<ogra_> and check the psplash binay with "file"
<sborovkov> My version: - 472 blocks - file output: psplash.img: LZMA compressed data, streamed ;  your version: 471 blocks; same file output
<ogra_> no
<ogra_> the uncompressed img ... you want to see the binary indside
<ogra_> "lzcat psplash.img | cpio -i" will unpack it
<sborovkov> alright, one moment
<ogra_> the img is actually an initrd that we merge in ram with teh actual initrd.img when uboot loads it
<diddledan> ogra_: regarding ring. I've been digging through their sauce (tomato) and figuring out whether it can work without dbus. I _think_ it can - I'm compiling a new build now
<ogra_> i have a slight suspicion that the cross build code doesnt work for you and you end up with an x86 binary
<sborovkov> ogra_: your version has bin directory, mine has bin executable at the top level
<ogra_> oohh ?
<ogra_> thats interesting
<ogra_> https://github.com/snapcore/pi3-gadget/pull/13/files has "cp psplash initrd/bin"
<mup> PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13>
<sborovkov> cp psplash initrd/bin
<sborovkov> yeah :-)
<ogra_> so why does it not end zup there
<sborovkov> there is no such directory?
<sborovkov> that's why it copies to file?
<ogra_> it should fail and scream and shout
<ogra_> if that dir isnt theer
<sborovkov> well it does not - Priming psplash ;Snapping 'screenly-pi3'; is all I get at the end
<ogra_> do you have the psplash subdir in your source ?
<sborovkov> no errors/warnings
<sborovkov> yeah
<ogra_> in that there should be an initrd subdir ... including bin
<sborovkov> there is no bin directory there
<sborovkov> initird only
<ogra_> oh
<ogra_> well, there should be a bunch of dirs
<ogra_> not nly bin
<ogra_> also scripts
<ogra_> did you perhaps miss a git add when merging ?
<sborovkov> there is script directory
<diddledan> in other news, I've discovered systemtap
<diddledan> ^^^ it helped me narrow down where the failure was occuring so I could investigate the sauce (tomato)
<sborovkov> ogra_: https://github.com/ogra1/pi3-gadget/tree/master/psplash can't see bin here?
<ogra_> there shhouldl be psplash/initrd/bin (empty), psplash/initrd/scripts/init-top/ORDER and psplash/initrd/scripts/init-top/psplash
<sborovkov> there are psplash/initrd/scripts/init-top/ORDER and psplash/initrd/scripts/init-top/psplash
<sborovkov> no bin
<ogra_> hmm
<sborovkov> ogra_: I have your repo checked out
<sborovkov> there is no bin as well
<ogra_> yeah
<ogra_> why deos that work for me then
<jdstrand> roadmr: hi! can you take a look at https://forum.snapcraft.io/t/unexpected-output-from-click-review/2031/6
<roadmr> jdstrand: I'm on it, fighting !*$% kibana to get the output
<roadmr> jdstrand: it's the same snap I reported some days ago, remember?
<diddledan> is there a snapcraft variable exposing the default number of make threads so that I can use parallel builds in my build: scriptlet without hardcoding a value?
<roadmr> jdstrand: this is the latest one: click-review returned unexpected output for package /tmp/tmp5eXbOZ/snapped-atom.retro-causal_1.19.7_amd64.click: ERROR: Could not find '/tmp/review-tools-xhag5033'
<davidcalle> pstolowski: https://github.com/CanonicalLtd/snappy-docs/pull/98 for you
<mup> PR CanonicalLtd/snappy-docs#98: Refresh the whole page, add install and remove hooks <Created by caldav> <https://github.com/CanonicalLtd/snappy-docs/pull/98>
<ogra_> sborovkov, sorry ... i simply added a mkdir to snapcraft.yaml now before copying ... pull my tree again
<roadmr> jdstrand: I see 3 fails for this particular snap with unexpected output... and that's it. So his other one that failed review seems to have been a different cause (i.e. a genuine failure, not "unexpected output")
<cachio> mvo, 2.28.2 is on beta?
<sborovkov> ogra_: np, good thing we found the issue now
<ogra_> sborovkov, yeah, that would have bitten me badly when merging the branch in ... thanks !
 * Chipaca hunts for tea
<jdstrand> roadmr: hmm
<pstolowski> davidcalle, will do, thanks!
<roadmr> jdstrand: I found a few "could not find foo" in the source code but I can't tell which one this is. Maybe changing those to "could not find %s while unpacking" so we can better know what happened?
<pedronis> pstolowski: just noticed that AddPlug/Slot is also used in interfaces/ifacetest so cannot be moved to export_test.go but is not used a lot
<pedronis> as we said, so should be ok to change it a bit
<jdstrand> roadmr: this snap unpacks really big: 1.9G
<jdstrand> roadmr: could it have run out of space?
<roadmr> jdstrand: oh, that's a possibility. Let me check
<roadmr> jdstrand: we did not get any low-space alerts though
<ogra_> ppisati, initrd fixes have landed in the PPA, can you trigger a rebuild for pc-kernel and dragonboard-kernel ?
<jdstrand> roadmr: I think I'm going to see if I can't output json with every error
<jdstrand> roadmr: I won't be able to finish that today though
<ppisati> ogra_: ack
<ogra_> thx
<roadmr> jdstrand: no problem, we're not seeing this frequently (only those 3 cases for this snap over the past 7 days)
<pstolowski> pedronis, yes
<jdstrand> roadmr: it is also taking *forever* to complete the review (running it here under the review-tools snap)
<roadmr> how so? time to decompress?
<jdstrand> roadmr: wonder if there was an OOM
<jdstrand> roadmr: now, python3 process taking a long time
<roadmr> ok
 * ogra_ takes a break
<jdstrand> roadmr: well, *forever* is strong. less than 10 minutes
<sborovkov> ogra_: yay, I can see the splash. it does not like my picture for some reason and draws white line on it but whatever
<cjwatson> jdstrand: the daemon/bin uid/gid conflict between RH-descended and Debian-descended distributions has been a known problem for at least 20 years and everyone gave up on it
<mvo> cachio: yes, 2.28~rc2 is in beta
<cjwatson> jdstrand: at this point it is what it is and there's not much to be done
<cachio> mvo, yes, I already started beta validation for this one
<mvo> cachio: great, thank you!
<jdstrand> cjwatson: yeah, I figured as much, which is why we are doing lookups for the uid/gid in the actual. I personally just didn't realize that diversion in the tests. thanks for the historical context :)
<jdstrand> actual code*
 * zyga-ubuntu found the history lesson interesting
<zyga-ubuntu> cjwatson: is this a big old accident or was it deliberate?
<cjwatson> zyga-ubuntu: accident
<jdstrand> if it is 20 years old, that is kinda interesting
<cjwatson> zyga-ubuntu: the LSB people tried to standardise a single value and realised they couldn't
<zyga-ubuntu> I find it curious with new distros that are not derivatives, like solus
<jdstrand> guessing the LSB was documenting what was out there already and didn't want distros to have to change the uid for daemon by choosing one
<cjwatson> I don't know why Solus picked a different value, but eh, 3 values isn't particularly worse than 2
<zyga-ubuntu> cjwatson: lol, yes, that's just makes it official
<zyga-ubuntu> thu shall not have constants
<cjwatson> jdstrand: exactly, and uids/gids are more or less unchangeable
 * jdstrand nods
<zyga-ubuntu> but fedora did change the default user uid from 500 to 1000 a while back
<zyga-ubuntu> though I understand that has smaller impact (none)
<cjwatson> that's very different, and I bet they didn't attempt to migrate existing data
<zyga-ubuntu> yes, it was just on new installs
<roadmr> jdstrand: all 4 app units have ~40GB of free space
<cjwatson> migrating my user account on my 1997-installed server from 500 to 1000 has been on my list for a long time, but eh :)
<jdstrand> hehe
<zyga-ubuntu> hehe
<cjwatson> hm, no, maybe 1999
<zyga-ubuntu> guess microsoft had some ideas with uuid based account IDs
<zyga-ubuntu> cjwatson: is it really that old without reinstall?
<cjwatson> yes
<zyga-ubuntu> cjwatson: if so I find that really impresisve
<jdstrand> roadmr: ok. well, since this isn't an emergency, I'll work on cleaning up the output as mentioned so we can better diagnose this in the future
<cjwatson> reinstalling would be a ton more work than upgrading
<zyga-ubuntu> cjwatson: is it running debian?
<cjwatson> yes, first installed with pre-release potato-ish I believe
<roadmr> jdstrand: thanks.
<cjwatson> first pre-release Ubuntu images were built on it
<mup> PR snapd#3797 closed: daemon: allow polkit authorisation to install/remove snaps <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3797>
<jdstrand> ah, potato
<roadmr> jdstrand: potato???
<roadmr> ahh!
<roadmr> I see. nm me
<sborovkov> ogra_: hmm, it's not colorspace issue. interesting. I am getting this https://drive.google.com/open?id=0B5xwucQA3JSJR0JtSFVxUExKbVU (again disregard that it's gigantic, resolution on first boot is very low). That line appears in 1080p as well. Source image is 1080p. I tried both SRGB and RGB. So may be it does not like resoltuion Idk
<SuperJonotron> i have heard through a third party via canonical that the nmcli is the correct way to modify network management for ubuntu core 16 but all the docs only mention netplan and networkd which seem way more configurable via the yaml file but when you do this all sorts of dns issues come up because it seems to conflict with some other network management going on
<SuperJonotron> at this point I can switch to nmcli i think fully if I can just get information on getting an ethernet port to maintain it's static IP even if it's not plugged in since right now that is only handled via an interfaces or yaml config file with netplan but those can't be used with any stability for ubuntu core 16 from any of my testing
<Chipaca> SuperJonotron: as far as I know most ubuntu core devices don't ship network manager
<Chipaca> some do though
<Chipaca> SuperJonotron: however, the netplan instabilities you're mentioning are news to me. Could you describe the problems you're seeing in more detail in the forum?
<SuperJonotron> Chipaca: NetworkManager doesn't seem to be installed in this case but using a yaml netplan file causes a weird issue on boot due to dns issues
<roadmr> jdstrand: the app units have 16 GB RAM, so should also not be an OOM situation, though e.g. maybe processing multiple huge snaps could result in that
<SuperJonotron> if I create a yaml file with all the correct syntax, something with a network service on dns entry locks up for ~2 min on the OS boot
<SuperJonotron> it's failing to resolve dns but once it boots the dns is perfectly fine
<SuperJonotron> nmcli setting static and leaving dhcp on my second port does not have this issue but does lose static ip's when unplugged
<Chipaca> SuperJonotron: i'm sorry, i don't know enough about any of these things to help you concretely myself. This is why I suggested the forum, so people more knowledgeable (and on different timezones) can help
<Chipaca> SuperJonotron: also so that if somebody else has the same problem they find the fix :-)
<Chipaca> SuperJonotron: however, nmcli is a network manager client, isn't it? if you don't have network manager, how does it even?
<SuperJonotron> Chipaca: and there in lies the problem, the forums (https://ubuntuforums.org/showthread.php?t=2323253) have this issue and the resolution is all around NetworkManager and configuration files that are read only due to snappy's read only file system so it's an insurmountable bug so far as I can tell
<Chipaca> SuperJonotron: https://forum.snapcraft.io
<Chipaca> SuperJonotron: i doubt the url you pasted has anything to do with ubuntu core
<SuperJonotron> Chipaca: not specifically but it is the exact error message on the OS boot so it's likely a bug that lives in both systems from the same NetworkManager
<Chipaca> SuperJonotron: there is no network manager in core
<Chipaca> unless you've installed a snap of it
<Chipaca> (in which case you'd know)
<SuperJonotron> Chipaca: I have not. The docs (https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/index), as mentioned before are really conflicting since it seems nmcli is the correct way but netplan and networkd are the documented approaches but when i've used the yaml for netplan it experiences the network manager issues on boot for something not supposed to be installed
<SuperJonotron> this is why it's a very weird problem for me and i'm ready to just abandon it for nmcli if I can just get static IP to persist even when unplugged
<Chipaca> SuperJonotron: those are the docs for network manager
<Chipaca> SuperJonotron: you do not have network manager
<jdstrand> roadmr: the whole thing shouldn't be in memory so I don't think that would be the case. ok, I think we've exhausted our guesses, I'll work on the unexpected output bits
<Chipaca> SuperJonotron: could you please create a new forum topic on forum.snapcraft.io, describe exactly what you have, what you do, what you expect, and what happens instead?
<roadmr> jdstrand: yeah :( thanks... hopefully we'll get to the bottom of this.
<SuperJonotron> Chpaca: I'd lve to see official documentation to Ubuntu Core IP configurations because that's the closest thing i've found to exist and not have to go to a forum or IRC for this but I will if no such documentation exists
<Chipaca> SuperJonotron: did you try "sudo console-conf"?
<Chipaca> SuperJonotron: (on the core device)
<SuperJonotron> Chipaca: it works but doesn't work for my solution since I need a non-interactive solution so it can be interfaced with via software
<Chipaca> sigh
<sborovkov> ogra_: and actually that white line is present on your default splash. commenting out framebuffer and hdmi_mode options does not help. On 1080p it's even more noticeable - https://drive.google.com/file/d/0B5xwucQA3JSJTFBvd2FBSmZMY0U/view?usp=sharing
<Chipaca> SuperJonotron: in what way do you need it interfaced with via software? what software?
<SuperJonotron> Chipaca: the software has, or should at least, have full access to modify the IP configuration, static, DHCP, dns, default gateways, etc.  It has all the functions ready in a sense just needs to be configured for the OS it's running on
<SuperJonotron> Chipaca: the software is Niagara
<Chipaca> SuperJonotron: that sounds like something that needs full access to the device
<Chipaca> SuperJonotron: also sounds like something that should be decided at the model level, but that's neither here nor there
<Chipaca> SuperJonotron: I don't know where the netplan docs exist, as I said early on I know very little about this aspect of our stack; I repeat that your best bet will be to ask in the forum
<Chipaca> SuperJonotron: if your goal is to make your software be able to do all that no matter what networking stack the device is using, you're going to have a lot of fun
<SuperJonotron> Chipaca: it will in fact be designed to run with UC16 on a specific hardware model series
<Chipaca> unless netplan can already do the things you need, that is :-)
<SuperJonotron> Chipaca: I can lock the feature into a specific network stack but figuring out which ones work fully first is where i'm at and can't seem to find stability in any path so far
<SuperJonotron> I am currently writing a forum post on the topic
<Chipaca> SuperJonotron: thank you
<Chipaca> SuperJonotron: i look forward to learning the source of the instability you experience
<Chipaca> but
<Chipaca> next week
<Chipaca> becaue I think i'm going to EOD now
<Chipaca> mvo, pedronis, zyga-ubuntu, I'm signing off now. I'll have my laptop with me on the road, so I'll be tinkering with stuff, but won't be online
<Chipaca> o/
<pedronis> Chipaca: have fun
<Chipaca> no
<Chipaca> after this week, what i need is _boring_
<Chipaca> i'll take a 1x1 sudoku game with me
<Chipaca> :-)
<ogra_> sborovkov, interesting, i doont have such a line on any of my installs
<sborovkov> ogra_: hmm. may be another setting affecting it. about hdmi. Also I guess I do need to psplash-snap. Because there is like 10 seconds between splash screen and our snap started. And with psplash-snap I was getting the same white line there
<ogra_> sborovkov, looking at psplash.c i see http://paste.ubuntu.com/25490573/
<ogra_> namely SPLIT_LINE_POS
<sborovkov> interesting why is it even needed there
<ogra_> sborovkov, you dont need psplash-snap, you want vt.handoff=0 and have your UI only call chvt 1 after the UI is up
<ogra_> then you wont have a visible switch
<sborovkov> ok, then I will try that
<ogra_> (that is ... *if* the UI can start without the frambuffer being visible)
<ogra_> sborovkov, well, happy you have it working now, i guess the rest is simply fixes that we'll manage over time
<sborovkov> yeah :-) will just try to figure out stuff about white line, wonder what values it gets there to split like that (if it's SPLIT_LINE_POS fault indeed). And this white line is very big on 1080p. And as you can see it's actually 2 lines there on 1080p at the bottom of the screen.  I tried setting framebuffer_height to 1080 but my rpi does not start with it hmm.
<ogra_> well, in the low-res setup your image is also not vertically centered
<ogra_> i bet there is some simple math thhat goes wrong and the split line would actually be supposed to be off sceen
<ogra_> sborovkov, regarding the psplash-snap i'll try to collect some data and discuss it with jdstrand next week ... we'll need a splash interface or enhance the framebuffer one or some such (it needs a bit more than what existing interfaces provide)
<sborovkov> ok cool, thanks a lot for assistance
<ogra_> np :)
 * ogra_ really loves to work on that splash stuff :)
<sborovkov> actuaslly
<sborovkov> no need for chvt 1
<ogra_> nice !
<sborovkov> just tried vt.handoff - splash went away when our ui came up
<ogra_> perfect
<ogra_> cachio, fyi dragonboard resize is nwo fixed in edge,beta and candidate with the latest kernel snap
<ogra_> *now
<ogra_> (just tested here ... http://paste.ubuntu.com/25490624/ )
<cachio> ogra_, nice
<cachio> ogra_, THANKS
<sborovkov> ogra_: ok the issue is in the psplash.c. I just changed SPLIT_LINE_POS to 10k. Now I get one line instead of 2 at the bottom. Just need to figure out it's logic then.
<itsfemme[m]> is it possible to run a snap package on a system with PaX enabled? does snapd have some hooking mechanism perhaps that you can use to mark the flags necessary?
<itsfemme[m]> https://en.wikibooks.org/wiki/Grsecurity/The_RBAC_System#PaX_Flags
<ogra_> sborovkov, yeah, i'll lok on the weekend if i can put something into the main psplashh patch for it
<ogra_> itsfemme[m], i dubt anyone has tested that yet ... trying it and putting your findings into the forum (see channel topic) might be the best thing here
<ogra_> (i doubt anyne has yet run snapd with a gsecurity kernel that also has all the right patches for snap support)
<mup> PR snapcraft#1540 opened: plugins: extract python finder functions <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1540>
<smoser> hey. if i have a snapcraft.yaml, but i need a build-package (or stage-packages) from somewhere other than xenial , is that possible ?
<smoser> specifically, libjson-webtoken-perl is not available in xenial
<nacc> smoser: building on lp, you can specify where to build. But i'm not sure you can specify one dep come from a specific release
<smoser> nacc, thanks
<smoser> thats kind of what i thought
<nacc> smoser: it would be nice if that was possible, but i've also seen oddness about how the debs are handled (e.g., postinst isn't run, so you need to manually handle that, if necessary (e.g., alternatives that normally get setup) and I don't think there's a way to specify recommends shoudl also be installed (where recommends really are neeeded :)
<smoser> well, yeah. the 'packages' are really just installed into the build system so its sane to assume that they are rsolved within the archive that bhe build system.
<nacc> smoser: yeah
<nacc> smoser: we recently swtiched git-ubuntu over to artful for this reason (we needed newer versions)
<mup> PR snapcraft#1541 opened: [WIP] Debug fake store in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1541>
<ogra_> smoser, worst case there are always scriptlets to ise wget and dpkg -x ;) snapcraft.yaml is extremely hack friendly
<ogra_> *to use
<smoser> ogra_, thanks. i hdnt known of scriptlets
<posi> Is this a good place to ask snap questions? If so, I am having issues getting the brave webbrowser's seccomp-bpf sandbox properly functioning in the snap I built. Anything fancy I need to do?
<pedronis> mvo: I'm saying strange error in core transition tests, IÂ wonder if we didn't consider some interaction with the prereq code
<pedronis> s/saying/seeing/
<mvo> pedronis: reproducable? or in some random tests?
<mvo> pedronis: eh, random runs in travis
<pedronis> mvo: it's not even  a transition tests but I'm seeing TestSetConf taking more thant 10 minutes, and  ensureCoreTransition is in the goroutines
<pedronis> mvo: I thought it was a test that IÂ touched but no
<pedronis> mvo: here's the log
<pedronis> mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170908_125944_bd802@/log.gz
 * mvo looks
<pedronis> it's a weird one
<pedronis> that branch doesn't touch daemon (the next one does, and anyway that test isn't changed in the next either but irrelevant)
<mvo> pedronis: hm, strange indeed
<mvo> pedronis: I investigate monday
 * mvo vanishes
<pedronis> have a great weekend!
<mup> PR snapd#3893 opened: many: introduce asserts.NotFoundError replacing both ErrNotFound and store.AssertionNotFoundError <Created by pedronis> <https://github.com/snapcore/snapd/pull/3893>
<mup> PR snapcraft#1277 closed: Handle revoked-uploads case on snap-developer revokes.  <Created by psivaa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1277>
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR snapd#3894 opened: many: fix TestSetConfNumber missing an Unlock and other fragility improvements <Created by pedronis> <https://github.com/snapcore/snapd/pull/3894>
<mup> PR snapcraft#1542 opened: tests: add integration tests for build snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1542>
<mup> PR snapcraft#1428 closed: core: reexec as root for `os` snaps if necessary <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1428>
<mup> PR snapcraft#1430 closed: tests: enable the snaps installation in armhf <Created by elopio> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1430>
<mup> PR snapcraft#1535 closed: jhbuild plugin: remove dependency on pkgconf <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1535>
<mup> PR snapcraft#1539 closed: nodejs plugin: expose hidden bin path when using yarn <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1539>
#snappy 2017-09-09
<mup> Bug #1619258 opened: netplan should allow NICs to be disconnected and not stall the boot <Snappy:Confirmed> <nplan (Ubuntu):Confirmed> <https://launchpad.net/bugs/1619258>
<noise][> FYI, network issues affecting multiple services, see http://status.snapcraft.io/
#snappy 2017-09-10
<mup> Issue snapcraft#1543 opened: Unable to specify make arguments <Created by akashrajkn> <https://github.com/snapcore/snapcraft/issue/1543>
<mup> PR snapcraft#1531 closed: Release changelog for 2.34 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1531>
#snappy 2018-09-03
<zyga> Good morning
<zyga> School day today so I will be a bit preoccupied in the next few hours
<mborzecki> morning
<mborzecki> https://github.com/snapcore/snapd/pull/5753/ is an easy win
<mborzecki> mvo: hi, think we could land this? https://github.com/snapcore/snapd/pull/5753
<mvo> mborzecki: looking
<mborzecki> btw. this one is easy win too https://github.com/snapcore/snapd/pull/5752
<mvo> mborzecki: yes!
<mvo> mborzecki: 5752 failed in tests, because of grub?
<mvo> mborzecki: in any case, approved and can land as soon as tests are happy
<mvo> mborzecki: thank you
<mborzecki> mvo: thanks
<mborzecki> ok, i'm off to school
<mvo> mborzecki: good luck
<zyga> hey, daughter handled, now going to our son's new school a bit further away
<zyga> I'll be operational around 10:30
<zyga> mborzecki: request: can you do a test PR and merge zyga/fix/trespassing-v2 into your instance work to see if you can dump the workarounds? please?
<zyga> with that, I'm off to the bus stop
<pstolowski> mornings
<zyga> New school looks familiar
<mvo> a second review for 5736 would be great
<mvo> with that I can do a new 2.35.1 release
<zyga> Iâm stuck but Iâll review it now mvo
<zyga> Ah I already did
<zyga> Hey John
<Chipaca> zyga: 'sup
<zyga> School
<mvo> hey Chipaca !
<zyga> New school, new class
<Chipaca> mvo: o/!
<zyga> Want out but $REALITY
<mborzecki> re
<mborzecki> zyga: let me check your branch
<mborzecki> zyga: with mount ns mapping branch right?
<zyga> Yes
<zyga> With all of your instance features
<zyga> School is over
<zyga> Iâll be home in 15 minutes
<mborzecki> zyga: dropped the workarounds and running with your branch now
<thresh> is there anything wrong with the release process since this night?
<thresh> I've got a "
<thresh> Status
<thresh> Manual review pending
<thresh> gah.  for the newly uploaded nightly.
<thresh> "Automated review not yet completed", "Task 058f17f1-e946-43d1-a783-0aa4ca04acb0 failed"
<thresh> also, good morning.
<popey> ^ sparkiegeek
<mborzecki> mvo: is snap-failure expected to be used everywhere?
<mvo> mborzecki: snap-failure? sorry, do you have some more context for me?
<sparkiegeek> thresh, popey: good morning - can you share the name of your snap so I can take a look?
<mborzecki> mvo: got a report from arch user, apparently snapd exiter unexpectedly and systemd tried to run snap-failure
<popey> sparkiegeek: vlc
<mborzecki> mvo: iirc this would only make sense if reexec is used
<mvo> mborzecki: oh, interessting
<mvo> mborzecki: yeah, it should not run on classic
<mborzecki> mvo: we have this in snapd.service.in OnFailure=snapd.failure.service
<mborzecki> mvo: so it's tried everywhere
<mvo> mborzecki: yeah
<sparkiegeek> popey: thanks, looking
<mborzecki> mvo: i'll try to ask why it failed in the first place anyway :P
<mvo> mborzecki: please do
<niemeyer> Morning all
<mvo> mborzecki: I added an item to my todo to fix this
<niemeyer> mvo: Just did some edits on the UC16/18 doc
<mvo> niemeyer: good morning!
<mvo> niemeyer: yay, thank you
<niemeyer> mvo: Tried to make it a bit more high-level.. not quite sure about what's the audience for the doc, and the audience may also drift :)
<mvo> niemeyer: yeah, looks good, thanks for streamlining it
<niemeyer> mvo: np, let's see if we can think of other interesting deltas
<niemeyer> mvo: Thanks for putting it up as well
<mborzecki> zyga: getting some unexpected apparmor denials
 * mvo nods
<mborzecki> zyga: https://paste.ubuntu.com/p/Kdk8yjbFC9/
<mborzecki> anyone noticed that google:opensuse-42.3-64:tests/main/appstream-id is failing often? not jus the test, but afaict that particular combo
<pstolowski> mborzecki: yes
<zyga> mborzecki: looking
<zyga> mborzecki: I'm at my desk, all fuss is over today
<mborzecki> zyga: hehe, no mandatory ice cream?
<pstolowski> mborzecki: but google:ubuntu-14.04-64:tests/main/appstream-id just now
<pstolowski> *but also*
<zyga> mborzecki: ice cream? no, but we did get a sandwich on the way home
<zyga> pstolowski: I haven't seen appstream-id failures, is that new?
<mborzecki> pstolowski: heh
<zyga> [Mon Sep  3 09:28:38 2018] audit: type=1400 audit(1535966919.486:60): apparmor="DENIED" operation="capable" profile="snap-update-ns.test-snapd-layout" pid=17922 comm="3" capability=2  capname="dac_read_search"
<zyga> [Mon Sep  3 09:28:39 2018] audit: type=1400 audit(1535966920.206:61): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.test-snapd-layout_foo" name="/tmp/.snap/snap/" pid=18214 comm="3" srcname="/snap/" flags="rw, rbind"
<zyga> those two?
<mborzecki> zyga: it does a round trip to the store, so maybe somewhere there
<mborzecki> zyga: yes
<zyga> so the first one is interesting dac_read_search is just taversing unreadable directories
<pstolowski> zyga: i started noticing it today
<zyga> we should add that to the profile, looks like an obviously missing thing
<zyga> the second one is interesting
<zyga> this looks like attempt to consturct a layout over all of /snap!
<zyga> *construct
<mvo> tests are very unreliable today, its quite annoying
<zyga> mborzecki: can you share the mount profile, I suspect it is trying to create a directory, hits /snap/* and notices that this affects the host filesystem
<mborzecki> zyga: the layout test?
<zyga> mborzecki: then decides to make a mimic over /snap to avoid showing that on the host
<zyga> mborzecki: yes, the one for layout_foo
<mborzecki> zyga: ok, let me rerun this with spread
<zyga> mborzecki: with --debug please
<zyga> mborzecki: but it looks okay and expected-ish
<zyga> mborzecki: it depends if the internal namespace has the right directories to begin with
<zyga> mborzecki: I suspect we need to allow it to create instance directories
<zyga> mborzecki: look at cmd/snap-update-ns/main.go:152 please
<zyga> mborzecki: around the call to AddUnrestrictedPrefixes
<zyga> mborzecki: I suspect that needs to include the layout variant of that
<zyga> what is snapName for instances there?
<zyga> is it "test-snapd-layout" or "test-snapd-layout_foo"?
<mborzecki> zyga: _foo
<mborzecki> test-snapd-layout_foo
<zyga> mhm
<zyga> interesting
<zyga> perhaps we need the instance-less version there as well
<zyga> that would explain why it is trying to construct a mimic
<zyga> mborzecki: once it fails discard the mount namespace
<zyga> mborzecki: and set SNAP_DEBUG=1
<zyga> and run test-snapd-shell.sh /bin/true
<zyga> or something like that
<mborzecki> ack
<zyga> thank you!
<zyga> I'm preparing the PR for review
<zyga> I'll rework comments to explain the restricted mode
<zyga> and drop some unused code
<mborzecki> uh, we got some meeting
<zyga> oh?
<zyga> now?
<zyga> ah. I see
<zyga> the session is full
<zyga> :P
<zyga> what is that?
<zyga> some kind of joke
<mborzecki> haha
<mborzecki> and it doesn't work in ff
<mborzecki> because it's '2010'
<zyga> meeting has ended
<zyga> what kind of crap is that?
<zyga> why do we have to have 2000 different meeting system
<zyga> ok
<zyga> I'll ignore that
<mborzecki> zyga: https://paste.ubuntu.com/p/RdyjBJ9nM7/
<zyga> looking
<mborzecki> zyga: https://paste.ubuntu.com/p/4MXzzC7Tc4/
<zyga> yeah
<zyga> we need more logging :()
<zyga> we need to log when we decide to make a mimic and log the reason for that
<zyga> main.go:196: DEBUG: 	 * mount (/snap/test-snapd-layout/x1/bin-very-weird-place /bin/very-weird-place none rbind,rw,x-snapd.origin=layout 0 0)
<zyga> this is exactly what I said before
<zyga> it's very interesting
<zyga> because we are crating a mimic for /bin/
<zyga> (which is expected) but then because /snap/test-snapd-layout is not in the trusted path we go on to create a mimic for /snap
<zyga> but this is unexpected and in fact, not allowed by appamor
<zyga> so we fail as you saw
<zyga> thanks
<zyga> this will require a little bit of integration
<mvo> still need a second review for 5736
<zyga> doing now
<zyga> +1
<zyga> mvo: approved
<mvo> zyga: ta, 5754 is another simple one where it would be great to get a review
<thresh> sparkiegeek, so what was it?
<sparkiegeek> thresh: I re-triggered the automated review check, which then passed successfully. We've been tweaking timeouts and retry behaviour in the store, and looks like this got caught up in the transition
<Gargoyle> Anyone able to help me out with an lxc issue - getting nothing from #lxc or #lxcontainers. Pretty sure it's related to user and group mappings but I just can't get my head round it?
<zyga> mvo: that report is pretty old
<mvo> zyga: it seems to be still valid though
<zyga> yes, I'm worried that it will stay this way
<mborzecki> zyga:  it works with this diff now https://paste.ubuntu.com/p/KYVCj2vNZc/
<thresh> sparkiegeek, allright, thanks a lot!
<mvo> zyga: aha, yes, that is unfortunate
<mvo> zyga: we could try to pester sergio about it
<zyga> mborzecki: excellent!
<zyga> mborzecki: that's very reassuring :)
<zyga> mborzecki: I'm almost done documenting new things, I removed all the cruft I found and I'll open a PR shortly
<mborzecki> zyga: great, ping me for the review :P
<zyga> I will :)
<mborzecki> zyga: btw. could you do another pass on https://github.com/snapcore/snapd/pull/5713 ?
<mvo> Chipaca: any concerns about 5754? iirc you added this originally
<zyga> ouch, yes but it's pretty long so I'll do it in my review part of the day
<Chipaca> mvo: looking
<mborzecki> zyga: ack, thanks
<Chipaca> mvo: snapcraft is using that exact (w/--dirty) command, though
<Chipaca> mvo: does snapcraft still remove snapcraft.yaml if it's in snap/snapcraft.yaml?
<Chipaca> (yes I can see how that might be inconvenient for us though)
<Chipaca> sigh
<Chipaca> dunno
<Chipaca> mvo: I don't have strong opinions on this;  the command that works out the version might have been committed by me, but the whole core teem collaborated on its details
<Chipaca> it's the perfect shed
<mvo> Chipaca: thanks, just wanted to double check with you, I remove -dirty for now and will see what needs to be done to get it fixed in snapcraft
<mvo> Chipaca: I think snapcraft is running the git describe --dirty either at a different time or in a different checkout :/
<mvo> Chipaca: anyway, no worries, just wanted to double check that I don't step on toes or something :)
<Chipaca> mvo: i've got 20 of them, step all you want
 * Chipaca reveals why his typing is often poor
<sil2100> zyga, mvo: I'm awayish today, but I'll get back to you for some dragonboard logs/debugging for the console-conf segfault tomorrow
<zyga> ok
<Chipaca> hmm, got a meeting at standup time
<mborzecki> zyga: pushed everything to bboozzoo/parallel-install-snap-namespace-mapping-with-trespassing-fix branch in my fork
<zyga> ok
<zyga> note that I will not present the trespassing fix as-is, I'm making it review-friendly now
<zyga> I pushed to my branch and the last thing on my todo list is that tmpfs checker code
<zyga> you know, the one we changed during the live review
<zyga> I think it may still be wrong
<pedronis> mvo: hi, have you tried to upload snapd with the snapd type, yet?
<mborzecki>  google:opensuse-42.3-64:tests/main/appstream-id failed again
<cachio> mborzecki, it is failing in different systems
<mborzecki> cachio: heh, must be mu luck then :)
<cachio> mborzecki, I also saw some timeouts
<mborzecki> pedronis: are you aware of any troubles store side?
<pedronis> not atm
<cachio> mborzecki, pedronis https://paste.ubuntu.com/p/MkVNvYRb4H/
<cachio> I saw some of these
<mborzecki> fwiw, searching does not seem to work locally either
<mborzecki> wrz 03 14:23:47 galeon snapd[1848]: retry.go:52: DEBUG: The retry loop for https://api.snapcraft.io/v2/snaps/refresh finished after 4 retries, elapsed time=40.002221771s, status: Post https://api.snapcraft.io/v2/snaps/refresh: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
<mborzecki> it's hitting the retry loop
<cachio> mborzecki, I see error no space left on device on amazon linux
<Chipaca> mborzecki: store seems to be dying
<mborzecki> Chipaca: death by 1000 requests
<cachio> mborzecki, it is really weird because it is the only image I didnt update last week
<Chipaca> mborzecki: I â¦ hope it's more
<Chipaca> but what do I know
 * Chipaca goes to see a dog about lunch
<mvo> pedronis: not yet, thats a nice idea
<mvo> sil2100: thank you
<ogra> $ snap find foo
<ogra> error: unable to contact snap store
<ogra> is the store down ?
<ogra> ah, third try gets a response ... probably just a hiccup
<ogra> heh ... and there is a forum post about it the second i ask ...
 * zyga finishes writing a very long test
<zyga> mborzecki: the test for whole thing was missing (unit test)
<mborzecki> hm?
<Gargoyle> OK. Someone put me out of my misery - how come one is reporting lxd version 3.4 and one is reporting 3.0.1? https://paste.ubuntu.com/p/hjvZSZvRHw/
<mborzecki> Gargoyle: can you echo $PATH on both?
<Gargoyle> mborzecki: https://paste.ubuntu.com/p/N67TwFTJVy/
<ogra> Gargoyle, my guess would be you additionally have the deb installed on the first system
<ogra> /snap/bin is only appended to the system PATH, so the deb would take precedence
<mborzecki> Gargoyle: or what ogra wrote ^^
<Gargoyle> Awww nuts... Good spot
<Gargoyle> must have sneaked in before a change was made to ansible scripts. :/
<zyga> mborzecki: https://github.com/zyga/snapd/blob/fix/trespassing-v2/cmd/snap-update-ns/change_test.go#L1795
<pedronis> mborzecki: cachio:  yes, store issues,  https://forum.snapcraft.io/t/problem-request-failures-to-the-store/7177
<zyga> tadam :)
<zyga> mborzecki: question wrt pushing this
<zyga> mborzecki: one big or split?
<zyga> oh
<zyga> standup!
<Gargoyle> and now I can't re-install due to ^^^
<Gargoyle> Time for a brew! :D
<Raboo> Hi, does ubuntu core base images include tools for connecting to wireless networks? Or do you need a device with ethernet to download the wireless tools?
<zyga> Chipaca: hello
<zyga> standup?
<Chipaca> zyga: mvo: i've got a conflicting meeting
<Chipaca> zyga: mvo: uk travel provider thing
<zyga> thanks!
<mvo> Chipaca: ok, enjoy, thanks
<Chipaca> enjoyment was not in the cards
<ogra> it comes with the process
<tomwardill> hello! Just to say the store team are aware of some problems with long and failing requests, and we're looking at it, updates will be here: https://forum.snapcraft.io/t/problem-request-failures-to-the-store/7177 when we have them
<thresh> (that probably explains why snap info is slow, thanks!)
<Chipaca> Gargoyle: sudo snap info /var/lib/snapd/cache/*  -> maybe you still have the .snap locally
<Chipaca> Gargoyle: actually you might need to work a bit harder than that because the * won't expand
<Chipaca> Gargoyle: sudo find /var/lib/snapd/cache -type f -print0 | xargs -0 sudo snap info
<zyga> Brb, just a quick walk and lunch
<niemeyer> Will need to step out to run an errand.. will be back later today.
<didrocks> hey! I'm having snapcraft issues under CI (I guess something impacting the docker image). It seems to have started on Friday: https://travis-ci.org/ubuntu/yaru/builds
<didrocks> for instance: https://travis-ci.org/ubuntu/yaru/builds/423938949
<didrocks> (running "snapcraft" on the project works fine on up to date cosmic)
<popey> diddledan: is that building using snapcraft from upstream git? Looks like it is
<mvo> didrocks: i have the same issue with the "josm" snap it seems
<diddledan> ello
<popey> s/diddledan/didrocks/
<didrocks> it's using whatever the snapcraft upstream docker image is pointing at :)
<diddledan> didrocks: change your nick, foo! :-p
<diddledan> I demand priority
<didrocks> diddledan: I'm having it since 1998 ;)
<diddledan> bah
<popey> :D
<didrocks> like an good old wine :p
<diddledan> precedent, shmecedent!
<didrocks> ;)
<popey> have poked ev, as the snapcraft guys are on vacation today.
<diddledan> _all_ the snapcraft guys?!
<didrocks> thx!
<popey> yes, they're on a beach somewhere drinking mohitos
<popey> or something
<diddledan> bass turds!
<diddledan> (poo from a fish!)
 * Chipaca expects a plugin: mojito
<popey> hah
<popey> getting flashbacks to seattle
<diddledan> haha
<diddledan> what happens in seattle stays unsaid. except Wimpress's blocked credit cards
<diddledan> https://youtu.be/zcqxCeYkkhk?t=7
<mvo> fwiw, 5606 needs a second review
<mvo> (I mean, it technically has two but it changed quite a bit since the initial review from Chipaca)
<Chipaca> mvo: looking
<zyga> re
<Chipaca> mvo: pedronis should probably confirm his concerns were addressed
<Chipaca> mvo: i can then re-review if he doesn't have time to do a full pass
<mvo> Chipaca: thanks, sounds reasonable
<Chipaca> pedronis: does this mean you're re-reviewing, or leaving the road open for me to do so?
<pedronis> I'm leaving the road open
<pedronis> my original review was mostly, don't abuse context
<Chipaca> ok
<Chipaca> pedronis: it's the way context dresses
 * Chipaca runs as far away as he can
<pedronis> Chipaca: bad John, bad John
<tomwardill> Hi, the store should be operational again, let us know if you have any other (relevant) problems :)
<zyga> thank you tomwardill :)
<zyga> what was the issue?
<tomwardill> we're not entirely sure, something triggered a bit of a death spiral, then the retry built up
<tomwardill> looking for the cause now
<tomwardill> *retry traffic
<popey> "death spiral" always a catchy turn of phrase, that :)
<Gargoyle> I'm trying to re-install lxd snap (after removing old apt version). But I have lxd.service, lxd.socket and lxd-container.service in /etc/systemd/system which are all symlinked to /dev/null. What's the best way to fix this?
 * cachio lunch
<Gargoyle> That is, I am assuming that is why service lxd start/restart just returns an error about it being masked.
<MattJ> er, I had issues with lxd recently too and discovered the same thing... but I think it's normal
<MattJ> I think the snap one might be called snap.lxd or something
<MattJ> Yeah, 'snap services' lists lxd.daemon, and I have a snap.lxd.daemon service in systemctl
<Chipaca> Gargoyle: the ones in lxd will have different names
<Chipaca> Gargoyle: snap.<snap name>.<app name>.service iirc
<Chipaca> Gargoyle: snap.lxd.daemon.service, in this case
<Chipaca> MattJ: that :-)
<Chipaca> Gargoyle: however, 'service lxd' is not the thing to manipulate snap services
<Chipaca> Gargoyle: 'snap start/stop/restart/logs' are snap commands to manipulate services that are snapped
<Chipaca> and 'snap services', heh
<Chipaca> in all of them, you can use a snap name to ask for everything in a snap, or add a service name to ask about just that one
<Gargoyle> OK. So possibly still got some "old apt" / snap version mix-ups then. Now getting - Error: Get http://unix.socket/1.0: dial unix /var/lib/lxd/unix.socket: connect: connection refused
<Gargoyle> I assumed this was because lxd wasn't running.
 * Chipaca takes a break
<thresh> sparkiegeek, it seems it's the same issue again with vlc #555
<Chipaca> Gargoyle: _what_ prints that error?
<Gargoyle> lxc list
<Chipaca> Gargoyle: and what's "which lxc"?
<Gargoyle> hmm. /usr/bin/lxc
<Chipaca> Gargoyle: yeah
<Gargoyle> I'm just going to take this AWS instance out back and shoot it in the head!
<Chipaca> Gargoyle: lxc and lxd might come from different debs
<Gargoyle> nvm. I'll rebuild a clean node tomorrow without the snap/apt conflicting version.
<abeato> mvo, hey, I have noticed that there are a few very basic utils that are not included in core18: vi, ping... are those going to be add back?
<mvo> abeato: we can add things back on a case-by-case basis, iirc edge has vim-tiny already
<ogra> mvo, ping is definitely essential ... especially since you cant snap it (it is suid)
<ogra> mvo, if you need to make room, drop bash !!! ;)
<mvo> ogra: ok, let chat tomorrow, I need to run now but thats easy enough
<ogra> mvo, perhaps a forum thread would be good to collect a list
<ogra> (i'm sure there will be more and adding it throughout the cycle would be hit and miss for users in the end)
<ogra> ppisati, on my pi3 systems the wlan hangs quite frequently in recent times (i sadly dont know when it started) it seems to be dying with "brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012"
<ogra> ppisati, i found https://github.com/raspberrypi/linux/issues/1342 and https://github.com/raspberrypi/linux/issues/2453#issuecomment-396063259 upstream ... bth seemingly unsolved though :(
<ogra> (it hung three times today and 5 times yesterday ... to give you a figure)
<mborzecki> pedronis: finally opened a PR with common snap directories for install/remove of instance-keyed snaps https://github.com/snapcore/snapd/pull/5758 iirc i had a spread test to check if dirs are created, i'll try to dig it up and push it there as well (but that's for tomorrow)
<zyga> hrm!
<zyga> I may have found and edge case to an edge case
 * zyga runs hacked spread test to examine
 * Chipaca EODs
 * zyga found interesting things
<diddledan> snapd folks; question here about running postgresql which doesn't like to run as root; I said I'd get one of ya'll to pop in and comment on the possibility of running the daemon under a non-root account: https://forum.snapcraft.io/t/snapping-a-rails-app/7179/2
<Chipaca> diddledan: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461/3?u=chipaca probably?
<diddledan> thanks Chipaca . I've posted the link on the rails thread
<Chipaca> diddledan: I don't know that status of that though :-)
<Chipaca> also, I don't know what i'm doing here post-eod
<diddledan> looks like it's not ready yet
<Chipaca> procrastinating from home chores i'm sure
<Son_Goku> zyga, how are we going to deal with the lack of extrausers in Fedora?
<Son_Goku> it's not like there's a port of this functionality using sssd?
<zyga> not sure, is it relevant?
<Son_Goku> from what I can tell, it's kinda needed for supporting system users in snaps?
<Son_Goku> for services and such
<zyga> I'm not sure that's the case
<zyga> in any case we don't have support for additional users yet
<Son_Goku> oh okay
<Gargoyle> aggghhhh... deb version of lxd/lxc is installed in the AWS default 18.04 image!
<Gargoyle> That explains a lot. How can I find all it's packages and completely purge them so as not to interfere with the snap verison?
 * zyga considers taking a bike
<zyga> or
<zyga> watching archer and having supper
<zyga> or figuring out clashing symlinks
 * Gargoyle does a little dance  \o/   \\o  o//  
<Gargoyle> Containers launch properly using the snap version!
<Gargoyle> Now I just need to figure out why when the script is run by the team-city agent, it doesn't think lxc is installed.
#snappy 2018-09-04
<mborzecki> morning
<mborzecki> mvo: hi
<mvo> hey mborzecki
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/5756 looks like an easy win
<mvo> mborzecki: indeed, thank you. technically this needs a review from jamie from security but I'm not sure its really needed for such a trivial one
<mvo> mborzecki: how are tests this morning?
<mborzecki> mvo: yeah, those files are just manufacturer an product human readable strings :)
<mborzecki> mvo: hard to tell, restarted a few jobs, but those were failures from yday
<zyga> Good morning
<zyga> Mborzecki I could use some HO time today
<zyga> I found a case that doesnât work (not trespassing, that is ok)
<zyga> And I wanted to discuss if
<zyga> It
<mborzecki> zyga: ok
<mvo> zyga: good morning
<mvo> mborzecki: I will merge once tests are green
<zyga> Essentially the case is this: you have a symlink a->b in writable space, you want a->c instead
<zyga> Hey. School saga day two
<zyga> Today we just bail
<zyga> I was thinking we should I link and symlink
<zyga> I link and symlink
<mborzecki>  build has failed
<mborzecki> Build #24748 was borken
<mborzecki> hm we're not out of the woods yet
<mborzecki> wonder if we could use the fakestore in those tests
<mborzecki> mvo: can you upload the release files to github?
<mvo> mborzecki: yes, sorry, will do so in a minute
<mborzecki> mvo: thanks!
<mvo> also looks like master has a problem building on various arches in master :/ oh well, I look at this in a little bit too
<mvo> mborzecki: done
<mborzecki> mvo: thank you
<mborzecki> mvo: i'll drop snapd.failure.service and snap-failure at the package level for now
<mvo> mborzecki: please do
<mborzecki> a siminiar thing will be needed for fedora (neal if offline?) and opensuse (cc zyga)
<mborzecki> arch package updated
<zyga> re
<zyga> what's the problem?
<zyga> btw, I'm entirely re-working suse packaging
<zyga> it's a bit of a sad/happy story that I can share during the standup
<mborzecki> zyga: https://aur.archlinux.org/cgit/aur.git/commit/?h=snapd&id=a23bdc8eb207c2a1312d74377dfcf8e56e25094f
<pstolowski> mornings
 * zyga looks
<zyga> hey pawel :)
 * zyga is working from a restaurant garden today
<zyga> ahhh
<zyga> I see
<zyga> thank you for sharing mborzecki
<mborzecki> pstolowski: hey
<mborzecki> btw. have you noticed something about ohmygiraffe, or maybe it's our pulseaudio interface
<mborzecki> when i restart pulseaudio (pulseaudio -k) and start ohmygiraffe after that, there's no sound
<zyga> mborzecki: probably different filename/cookie value
<mborzecki> zyga: right, but it's read from .pulse-cookie
<zyga> is it?
<zyga> it's unlikely
<mborzecki> zyga: i'd gues .pulse-cookie contains the cookie, it's different each time pulseaudio starts, but at the same time i'd expect libpulse to read and use the new cookie
<zyga> but the cookie is in a dot file in HOME
<zyga> so it's probably not read from that
<zyga> probably read from the x server root window
<mborzecki> the log with PULSE_LOG=4 shows it's trying /run/user/1000/snap.ohmygiraffe/pulse/native to no avail
<mborzecki> and $XDG_RUNTIME_DIR/pulse is indeed empty
<mborzecki> i have a vague recollection we fied that in desktop helpers?
<zyga> maybe
<zyga> but I'd look at xprops
<mborzecki> heh, symlinked in in snap shell, works now
<mborzecki> ln -s ../../pulse/native $XDG_RUNTIME_DIR/pulse/native and magically works :/
<mborzecki> zyga: xprop -root |grep -i pulse comes up empty
<zyga> hmm
<zyga> and without pulse?
<zyga> anything else there?
<mborzecki> zyga: with or without looks the same
<zyga> are you on wayland?
<mborzecki> zyga: no x11
<mborzecki> ok, so it'd be nice to rebuild the snap to pick up the fixes in snapcraft-desktop-helpers
<zyga> in that case my theory is broken, no idea
<mborzecki> we have a fix there already (apparently i was the one to add it) whcih exports PULSE_SERVER
<mborzecki> popey: any chance you could rebuild ohmygiraffe using more recent snapcraft?
<zyga> mborzecki: I'm re-working the restricted/desiredPath into a structure that holds the pair
<mborzecki> need conffee
<zyga> cofefe
<Raboo> how do I figure out what settings a snap has?
<Raboo> btw snapcraft.io times out alot since yesterday
<Raboo> ah there is a get
<zyga> Raboo: hey
<zyga> yeah, the store was wonky yesterday, it's all resolved I heard though
<zyga> Raboo: snap configuration doesn't have a schema yet but you can indeed use get to look at the data that is set right now
<Raboo> zyga ok
<mborzecki> zyga: doesn't look resolved to me
<zyga> oh?
<zyga> the store is still wonky?
<Raboo> trying out the chromium-mir-store
<Raboo> s/store/kiosk/
<mborzecki> zyga: afaict it is
<Raboo> zyga still wonky
<zyga> :/
<ppisati> ogra_: xenial or bionic only? if we could find a way to reproduce it, it would be nice
<wgrant> zyga: It was all resolved, but is having some minor trouble now. Should be working again.
<sparkiegeek> zyga: please just look at (and refer people to) https://status.snapcraft.io
<zyga> thank you, will do
<sparkiegeek> we (store team) will keep that up to date, and avoids "I heard" games of Telephone
<Raboo> does the chromium-mir-kiosk people hang here? I'm wondering what I need to do to enable audio and webcam
<mvo> Chipaca: good morning!
<mvo> Chipaca: I think you tricked me into writing tests for store.go:download() ;)
<Chipaca> mvo: morning!
<mvo> Chipaca: we do not test this explicitly, do we?
<Chipaca> mvo: only that if wasn't covered!
<Chipaca> mvo: probably not explicitly, the tests will be fore Download
<Chipaca> or whatever
<Chipaca> mvo: can't you parametrise one of the existing tests?
<Chipaca> mvo: as in, TestDownload(*C) -> testDownloadMaybeWithRateLimit(*C, bool)
<mvo> Chipaca: not sure, afaict we mock func download away pretty much everywhere
<Chipaca> hmm
 * Chipaca looks
<mvo> Chipaca: I looked at storeTestSuite and in SetUpTest it mocks it away and I don't see where its unmocked :/ but again, maybe blind :)
<zyga> hey John, good morning
<zyga> mborzecki: hey
<zyga> do you have a sec for HO?
<mborzecki> sure
<mborzecki> sec
<mborzecki> zyga: ok, i'm there
<zyga> k, joining
<pedronis> Chipaca: mvo: we should have some tests for download,  what I'm not sure is whether we have tests for Download calling download
<Chipaca> pedronis: mvo: look for TestActualDownload
<Chipaca> pedronis: mvo: there are a bunch
<Chipaca> coverage is bright green, not the pale green of only-barely-covered
<Chipaca> zyga: hey zyga
<Chipaca> zyga: I'm assuming you mean me when you say 'hey John' :-)
<pedronis> Chipaca: mvo: SetUp stores it away to restore, it doesn't mock it  afaict
<mvo> Chipaca: clearly the tea then, thanks, I will add
<pedronis> s.origDownloadFunc = download
<mvo> Chipaca: to that family plus adding one that does the download directly
<Raboo> This is my interfaces http://termbin.com/nm9z, do I need to connect anything more to enable camera and audio for chromium-mir-kiosk?
<mvo> pedronis: yeah, thanks. I see it now, sorry for the noise
<pedronis> mvo: well store_test.go is a bit of a jungle
<pedronis> but at least this bit is kind of straighforward
<mvo> pedronis, Chipaca would you mind if I change this to use MockDownload ? to make it a bit more like the other parts?
<mvo> pedronis: yeah, sorry again
<mvo> (probably in a separate PR)
<pedronis> I don't know
<Chipaca> pedronis: mvo: it wasn't obvious fwiw, I had to add a panic() to the download() :-)
<pedronis> it's a step in the right direction otoh  I think that file needs a more general attack
<mvo> Chipaca: heh, thanks for comforting me :)
<mvo> pedronis: I would move the actual download tests into its own suite plus add mocking via export_test.go as a first step. but I'm fine leaving it if there is a bigger plan in place
<pedronis> mvo: there are not bigger plans
<pedronis> mostly noticing that Mock* is not used  much around there
<pedronis> mvo: the main issue is really that   store_test.go  is "package store"
<pedronis> only unclarity comes from that
<Chipaca> store really needs some love, yes
<pedronis> it and daemon are the few places left doding that
<mvo> pedronis: yeah
<Chipaca> daemon is 100% my fault :-|
<mvo> pedronis: I have a look
 * pedronis is only morning and I cannot type
<mvo> Chipaca: its the fault of history
 * mvo hugs Chipaca 
<Chipaca> :-)
<Chipaca> anyway, back to snapshotstate tests for me
<popey> mborzecki: sure, what's the issue I'm solving by rebuilding omg?
<Chipaca> HAH! found you, you nasty effluvia
<ackk> hi. where is "snapctl" localed in the snap? it seems it's not in path by default in hooks
<ogra> ppisati, ubuntu core 16 ... 4.4 kernel
<Chipaca> ackk: /usr/bin/snapctl
<ackk> Chipaca, oh, wait it seems it's missing in core18?
<Chipaca> ackk: shouldn't be, but :-)
<Chipaca> ackk: do you have core, or snapd snaps?
<ogra> ppisati, the systems are all the same, running a webcam with mjpg-streamer (so there is a lot of data going over the net) ...
<ackk> Chipaca, I have "core" but the snap I'm working on is based on core18
<ackk> Chipaca, confirmed, no snapctl in core18
<Chipaca> ackk: right, core18 doesn't ship any of snapd; that's shipped in the snapd snap (in the new world) or in the core snap (in the old world)
<Chipaca> ackk: snapd should be smart enough to find it and put it where it's expected though
<Chipaca> mvo: any issues here ^?
<ackk> Chipaca, so how do I base a snap on core18 and use hooks?
<Chipaca> ackk: as I say, it should just work -- you shouldn't need to care
<Chipaca> ackk: you've found a bug, maybe
<Chipaca> ackk: waiting for word from mvo who is the god of core18 and hugs
<ackk> Chipaca, should I have a "snapd" snap as well?
<ackk> I don't
<Chipaca> ackk: no you should not need it
<Chipaca> ackk: can you check if it's in /usr/lib/snapd/ ?
<Chipaca> snapctl i mean
<mvo> ackk: are you using the "beta" or "edge" of core18 ? if not, please try that
<ackk> Chipaca, it's not
<ackk> mvo, no I'm using stable, I'll try edge
<ackk> mvo, that worked, thanks
<ackk> mvo, btw are pre-refresh and post-refresh hooks already supported in released snapd?
<mvo> ackk: that should work, yes
<ackk> cool
<ackk> Chipaca, mvo  thanks
<Chipaca> pedronis: that thing where the cleanup test would freeze that had me stumped? was an actual bug :-D
<pedronis> Chipaca: ok
 * pstolowski -> school run
<ackk> Chipaca, unrelated, do you know if it's possible to run ssh confied in a snap? I've been trying but it fails on setgroups call and I can't log in
<Chipaca> ackk: ssh should work (there might even be an interface to let it get the host keys); sshd might need tweaking
<mborzecki> popey: the one i know of is it'll get properly exported PULSE_SERVER, so even if you restart pulseaudio the sound will work
<zyga> Chipaca: indeed
<ackk> Chipaca, right, I want sshd
<Chipaca> ackk: if you arm yourself with logs and patience jd_strand might be able to help
<Chipaca> ackk: sshd has a lot of levers you can pull via config :-)
<Chipaca> ackk: but: if it tries to setuid, it won't work
<ackk> Chipaca, right, I've been trying that, including AllowedUsers/Group and so on, but I couldn't get it to work
<Chipaca> setgroups sounds like part of that family
<ackk> Chipaca, right, I suspect it would work if it could use a "nobody" user
<ackk> Chipaca, basically I wanted an isolated sshd so that I can use it as a target for sshuttle-based VPNs
<Chipaca> ackk: nice
<ackk> Chipaca, it would be if it worked :)
<Chipaca> ackk: https://forum.snapcraft.io/t/multiple-users-and-groups-in-snaps/1461?u=chipaca fwiw
<ackk> Chipaca, yeah I know about that thread, it's something we'd like for the maas snap too
<Chipaca> k
<niemeyer> ackk: We discussed the idea of introducing a "daemon" user early on, using the same model of the final design.. might work for those cases before the whole thing is fleshed out
<niemeyer> Mornings, btw
<ackk> hi niemeyer, yeah I think that would be enough for our use case
<ackk> (daemons that refuse to run as root)
<niemeyer> ackk: Yeah, that's indeed the reason why that idea came up
<Chipaca> pedronis: Settle(t) always take t? I thought it was a maximum but in practice it looks like a mminimum (at least when there's cleanup involved)
<thresh> popey, sparkiegeek ping vlc stuck in store
<sparkiegeek> thresh: hmm, sorry about that :/ I've re-triggered the checks again on 3.0.4
<thresh> sparkiegeek, np and thanks!
<pedronis> Chipaca: it's complicated,   t doesn't cover time some scenarios
<Chipaca> pedronis: hmm
<Chipaca> pedronis: what I'm seeing is that cleanup gets called again and again
<Chipaca> hmm
<Chipaca> pedronis: if cleanup returns error it just gets called again?
<pedronis> Chipaca: ah, yes,  no basically cannot return errors from cleanups
<pedronis> unless you think being called forever is what you want
<Chipaca> pedronis: thank you for having me write these tests ;-)
<dot-tobias> Hi everyone. Quick question concerning the Ruby plugin: Is there a way to preserve a built Ruby version across iterations as long as I don't change the ruby-version keyword? I'm experimenting with different stage-packages and the plugin rebuilds Ruby from source on every iteration.
<sparkiegeek> thresh, popey: it is now unstuck
<Chipaca> dot-tobias: I'm not sure who, short of sergiusens or kyrofa, can answer that
<zyga> mborzecki: I think I found another logic quirk in my code
<zyga> eh eh
<zyga> but I'll commit everything and push it for review
<mborzecki> ok
<zyga> then work on your branch
<zyga> mborzecki: essentially the call to LiftRestrictions is fine
<zyga> mborzecki: but what if we did /rofs/<mimic>/a
<zyga> mborzecki: and want to make /rofs/b then?
<zyga> mborzecki: we remember that /rofs is a tmpfs we made
<zyga> mborzecki: so we'll make b
<zyga> that will work
<zyga> mborzecki: but /rofs/a/c
<zyga> mborzecki: that will go to rofs, it's a tmpfs so we carry on, then we will see an _existing_ directory a and bail out
<zyga> (because we may not attempt writes there)
<zyga> it's non-trivial :/
<zyga> mborzecki: because as I coded it so far, we only lift restrictions when making a new directory on top of a tmpfs mount point
<zyga> mborzecki: to allow /rofs/a/c we'd have to keep track of other mount ops and ensure that /rofs/a/ is not populated
<zyga> mborzecki: it can be a fix on top of this branch I suspect
<zyga> but meh, this is hard stuff
<mborzecki> heh, maybe we should try whiteboard instead :P
<zyga> mborzecki: we need the "are you evil" bit
<mborzecki> zyga: it feels like you'd need to comb through the ops and match the longest prefix of current path
<zyga> mborzecki: we also need to keep track of mount changes we started with (current mount profile)
<zyga> mborzecki: well, not sure, it's all complex (you can have filesystems and symlinks there)
<mborzecki> zyga: we could track just the current state, but then symlinks don't show up because it's kind of side channel
<zyga> mborzecki: we cannot track just the current state, we are called _update_ ns for a reason
<mborzecki> zyga: i meant tracking the 'current state' after each change, but that's not helping either
<mborzecki> zyga: btw. what if symlinks were applied last?
<zyga> mborzecki: we know in order
<zyga> mborzecki: I mean, we know it all
<zyga> but it's hard to come up with an algorithm can respond reliably to the set of questions we have
<zyga> mborzecki: pushed!
<zyga> I'm making the PR now,
<zyga> mborzecki: I have an idea how to fix /rofs/a/c
<zyga> if we know /rofs/a and we can fstat it we can check the device major number
<zyga> (and the magic/type value)
<zyga> *fstatfs
<zyga> Then we can fstatfs /rofs/a/c and also allow it iff it is still a tmpfs and has a major number that matches one of the past ones we've checked
<zyga> since we must have traversed /rofs/a/ we will know the major number
<zyga> anyway
<zyga> that's a follow-up
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5760
<zyga> mborzecki: I'll look at your PR now
<zyga> mborzecki: just to double check: https://github.com/snapcore/snapd/pull/5758
<zyga> this one?
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/5713
<mborzecki> zyga: well, you can do both :)
<zyga> ok
<zyga> mborzecki: quick question: why didn't you make the changes to apparmor?
<zyga> mborzecki: there are some typos in parallel in the PR :)
<mborzecki> zyga: default template?
<zyga> or instance specific template, either way
<zyga> anyway, reading on
<mborzecki> pedronis: hi, another one for you https://github.com/snapcore/snapd/pull/5761 :) this is first step to get the stable instance key across refresh requests (cc wgrant)
<wgrant> ooh
<baimafeima> hello, I'm curious whether it'll be possible to get snaps to run on Haiku OS: https://www.haiku-os.org/
<zyga> baimafeima: hey, that's unlikely as snaps rely on a number of linux technologies
<zyga> baimafeima: I'm not a haiku expert but I don't suppose haiku can run unmodified linux executables today
<baimafeima> Yeah
<zyga> baimafeima: so apart from the extra requirements of snapd (related to container technologies and sandboxing) you would have existing problems of just running unmodified apps that people release
<baimafeima> I just wonder whether there's any ambition among snap developers to even move beyond the linux ecosystem
<baimafeima> to make it more "universal"
<zyga> baimafeima: one by one ;)
<zyga> baimafeima: I think the answer is that it's unreasonable outside of "let's run it in a VM"
<zyga> baimafeima: I doubt the number of users there would justify the engineering work required to attempt that
<zyga> baimafeima: allowing snaps on windows would be more interesting for example
<baimafeima> zyga, yeah, I just happen to be really fascinated about haiku :D
<baimafeima> and well, they really lack software
<zyga> baimafeima: I understand that
<zyga> baimafeima: good luck with haiku!
<pedronis> mborzecki: ack
<baimafeima> zyga, thanks for the info though
<zyga> mborzecki: wow, https://github.com/snapcore/snapd/pull/5760 is green on first go :)
<zyga> no need to re-trigger tests
<zyga> that's fun :)
<wgrant> mborzecki: RequestSeed will be persisted in state somewhere, I guess?
<wgrant> I suppose it needn't be a per-snap value. Machine-global would be fine.
<mborzecki> wgrant: i planned to use seed-time which is machine global for that
<mborzecki> off to pick up the kids
 * zyga preps for lunch
<zyga> mborzecki: review of 80% sent, I'll grab some food now
<zyga> mborzecki: and there are lots of conflicts in that PR
<zyga> anywAY
<zyga> re :)
<zyga> mborzecki: resuming the review
<pstolowski|lunch> a lot of "error: unable to contact snap store" today, still
<noise][> pstolowski|lunch: we are still battling some performance issues so having internmittent timeouts
<pstolowski|lunch> noise][: ack, thanks
<pstolowski> niemeyer: thanks for the yesterday's udev review! the followup https://github.com/snapcore/snapd/pull/5632 is now much smaller (and also finally green again)
<mborzecki> re
<niemeyer> pstolowski: Thanks!
<mborzecki> zyga: yeah, the conflicts are expected, parts of the PR were landing independently
<Chipaca> state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
<Chipaca> :'(
<Chipaca> noise][: ^ is that another form of intermittent timeout?
<noise][> yes, we lock you up until the timeout is reached
<pedronis> Chipaca: we should move catalog fetching to a task btw
<ogra> noise][, given that https://forum.snapcraft.io/t/solved-request-failures-to-the-store/7177/6 claims "solved" perhaps someone from store could answer here https://forum.snapcraft.io/t/snapd-not-connecting-to-the-store-what-to-test-do/7190
<ogra> (since the latter one is more specific)
<Chipaca> ogra: "solved" y un jamÃ³n :-)
<jdstrand> I'm here
<noise][> yes, we'll get the notices updated, sorry for the delay on those
<ogra> jdstrand, do you highlight "jamÃ³n" lately ?
<jdstrand> no
<ogra> :)
<jdstrand> I saw the store failures bit
<ogra> ah
<jdstrand> but seems you are talking about different things
<zyga> jdstrand: hello
<ogra> yeah ... the review-tools are fine on 16.04 ... 18.04 still fails though
<jdstrand> I'll sync with roadmr when he is online. a new revision of the review tools should've hit prod yesterday but it doesn't seem to have
<zyga> ogra: jamon? :D
<jdstrand> ogra: yeah
<ogra> zyga, see Chipaca's last line :)
<zyga> jdstrand: I revived the trespassing fix for layouts, some churn still but at some point I'll ask you to sanity check
<jdstrand> ogra: so, depending on what he says, I'll do the same for 18.04 that I did for 16.04
<jdstrand> zyga: hey, sure
<zyga> jdstrand: there's also some related change in mount table sorting we are doing for instances
<zyga> jdstrand: I'll go through it now, to poke holes
<zyga> jdstrand: but if I fail I'll ask you to double check that aspect
<jdstrand> roadmr: good morning! what is the status of getting r1123 of the tools into prod?
<roadmr> hi jdstrand ! we've had some issues with breakage in the store since yesterday which have preempted any rollouts :/
<roadmr> jdstrand: but once the fire is out, rolling r1123 and a couple of other changes is highest priority for us
<jdstrand> roadmr: should I roll a downgraded deb for bionic or does that fire seem to be out?
<jdstrand> roadmr: (I can do the same for base: core18 snaps as I did for regular snaps. that would help some, but then there are non-LP/snapcraft.io builds that need r1123)
<jdstrand> (I can't do anything about those)
<roadmr> jdstrand: it's probably still affecting users building on 18.04
<jdstrand> roadmr: which 'it'? I know lack of r1123 is affecting users (that is what I'm wondering about with uploading a downgraded bionic). ie, is the fire almost out and therefore r1123 will make it in the next few hours, or should I prepare that downgraded deb?
<roadmr> jdstrand: it == the new snapcraft that emits those new keys :)
<roadmr> jdstrand: we might be able to do the rollout this afternoon but no promises - it might be reasonable to downgrade bionic :(
<jdstrand> roadmr: right, ok
 * jdstrand does that
<roadmr> jdstrand: because it'll be a couple of hours before we know more, and what we end up finding out may be "it's all still borked, we can't roll out yet"
<roadmr> jdstrand: sorry - this issue we've hit had particularly bad timing :(
<jdstrand> no worries
<mvo> niemeyer: the snapd snap failover test: https://github.com/snapcore/snapd/blob/master/tests/core18/snapd-failover/task.yaml
<mvo> niemeyer: sorry that I did not find it earlier, it is under the core18 subsection, I forgot about this
<niemeyer> mvo: Thanks!
<niemeyer> mvo: and np at all
<ogra> mvo, https://forum.snapcraft.io/t/core18-included-binaries/7191 ( <-- and probably also niemeyer )
<sergiusens> kjackal: hey there, can you direct me to where the microk8s project lives?
<Chipaca> niemeyer: wrt changing 'okay' to 'ack', was your expectation also that the user-facing command would become 'ack'?
<Chipaca> (maybe as an alias for 'acknowledge'?
<Chipaca> )
<pedronis> Chipaca: snap ack exists already,  for assertions
<niemeyer> Right, on both counts
<pedronis> that's why we went with okay here originally, I think
<niemeyer> Oh, wait.. the command doesn't work.. :(
<mvo> ogra: ta
<niemeyer> It's a bit awkward to see it as a verb.. it was also unexpected to see it mixed
<niemeyer> Hmmmmm
<Chipaca> niemeyer: 'snap okay' comes straight from the whiteboard fwiw
<niemeyer> Ack
<niemeyer> (or okay? :P)
<zyga> "snap dismiss"
<zyga> snap read NN (like in gentoo)
<Chipaca> snap conform
<niemeyer> zyga: That's pretty good, but as something we need to type out often "okay" feels practical, and sort of okay
<niemeyer> I cannot find any better options right away, unsurprisingly..
<roadmr> haha so just like typing any two letters on a unix system does *something*, snap $ANY_VERB is bound to eventually also do something :D
<niemeyer> We probably spent a good while finding it in the sprint
<pedronis> looking at synomyms of "acknowledge" there is nothing useful that is not many word, or long and uncommon
<Son_Goku> does anyone know why the forums are inaccessible?
<Son_Goku> hmm
<Son_Goku> was a blip
<Son_Goku> it works now
<niemeyer> Chipaca, pedronis: alright, I we want to go with "okay", indeed it sounds better to go end-to-end with it so we use the same terminology everywhere
<niemeyer> Chipaca: sorry for the false lead.. I forgot we had such a strong meaning for ack already
<roadmr> jdstrand: hey! the script that sends USN notifications for snaps, that lives in the reviewer-tools repo, right?
<zyga> niemeyer: yeah, I think okay is okay :)
<niemeyer> Okay then!
<Chipaca> zyga: I think ack is ack
<zyga> ack, okay
<zyga> meh
<zyga> can we have "snap meh"
<zyga> doing something useful? :)
<pedronis> snap blink and snap nod
<zyga> snap wink wink wink
 * mvo likes snap nod
<mborzecki> snap aye, snap nay?
<zyga> snap popey the sailor
<diddledan> https://www.youtube.com/watch?v=grtchH6SfGE
<jdstrand> Saviq: hey, can you trigger a new build for subsurface? LP/snapcraft.io should now have a downgraded snapcraft to work around the review issue
<jdstrand> roadmr: the meat of the script is there, yes. there is a small cron script that drives it that is not
<roadmr> jdstrand: ok... but the cron script mostly calls the usn script itself, right? does it by chance do a snap search to the /api/v1/snaps/search endpoint? (I think not, but checking something)
<sergiusens> jdstrand, roadmr: I am about to dput a new snapcraft, is the review thing resolved? If not I will git revert the version thing and leave it to you guys to add back when ready
<roadmr> sergiusens, jdstrand : I'm about to request the rollout with tools r1123, very likely that'll be out today
<sergiusens> roadmr: ok, sounds good
<Saviq> jdstrand: ack
<jdstrand> roadmr: thanks! that'll help people directly uploading with 'snapcraft push'
<roadmr> yep, sorry it took so long :/
<roadmr> but... fire :)
<jdstrand> roadmr: sorry, let me check
<roadmr> jdstrand: (it's not there yet :)
<roadmr> rollout has been requested, but takes a while to process/run/etc
<jdstrand> I understand
 * jdstrand is getting you the answer to your question
<roadmr> thanks :)
<ogra> mvo, did you see my last comment on the core18 binaries thread ? where are netplan and console-conf in core18 ? are they not supposed to be included anymore
 * Chipaca wanders off
 * anarcat waves
<anarcat> so what should i do with this bug report? https://forum.snapcraft.io/t/apparmor-error-after-debian-buster-upgrade/7026
<anarcat> it still, as far as i know, affects debian
<cyphermox> ogra: could you please clarify? netplan and console-conf not supposed to be included? I expect that's a mistake
<jdstrand> sergiusens: I see you closed https://github.com/snapcore/snapcraft/pull/2234. I commented there since I was reading backscrolled and asked to do so
<sergiusens> jdstrand: yeah, I reopened another one
<sergiusens> jdstrand: https://github.com/snapcore/snapcraft/pull/2235
<sergiusens> but I will look into your comments
<jdstrand> anarcat: I think zyga is looking at that
<sergiusens> jdstrand: good comments, these are the smallest snaps we can come up with to trigger each scenario as we do like our speed
<sergiusens> jdstrand: this will not however give us a 100% coverage on all the possible scenarios for keys to be generated. But we should strive to keep the ones you care about compatible, we do not plan on making backwards incompatible changes, but you never know when taking on new dependencies :-)
<jdstrand> sergiusens: are you planning on adding new keys? maybe I should adjust the tools to not care about unknown ones
<jdstrand> it isn't as interesting to report unknown manifest.yaml keys
<sergiusens> jdstrand: no, no plans; I just worry that someone will create a snap that triggers things you have not seen yet (like source-commit or those keys that only show up on very special occasions)
<jdstrand> possibly
<sergiusens> jdstrand: that said, maybe you cover everything already and I just need to check
<sergiusens> jdstrand: but, the case can be made that the snap directory of a snap is not part of the snap format
<jdstrand> sergiusens: https://git.launchpad.net/review-tools/tree/clickreviews/sr_common.py#n67
<sergiusens> it is just an artifact that snapcraft creates
<jdstrand> right
<jdstrand> I mean, snapd doesn't look at it
<jdstrand> looks like I do not have source-commit
<sergiusens> right, anything part of the snap format is in meta
<jdstrand> sergiusens: how about I add all the missing keys, but then I make it non-fatal if something is added?
<sergiusens> jdstrand: source-commit is part of snapcraft.yaml inside snap (alongside manifest.yaml)
<sergiusens> you may not be checking it at all from a quick search
<jdstrand> sergiusens: we don't look at snapcraft.yaml at all
<jdstrand> sergiusens: only manifest.yaml and only because our tool looks at it
<sergiusens> jdstrand: that's perfect, I would still treat it as json API, ignoring what you do not know about to be able to add new keys we agree upon
<jdstrand> sergiusens: ok, am I missing anything from manifest.yaml? is there somewhere I should look?
<sergiusens> well, your choice, we will most likely only add keys there that make sense to you and maybe when we decide to tackle reproduceable builds for real
<anarcat> jdstrand: cool
<sergiusens> jdstrand: it is pretty much hand crafted to not sneak in things https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta/_manifest.py#L28
<jdstrand> ok, thanks
<sergiusens> jdstrand: I will let you know if anything changes
<jdstrand> sergiusens: thanks. the added tests will be very worthwhile in that regard. I'm also removing the unknown check
<mvo> ogra: are you looking at stable? that is very small right now, beta/edge should be more current
<pedronis> mvo: is version really intended to be just "18"  in edge?
<ogra> mvo, aha, i'll make the same list fro edge then, thanks
<ogra> *for
<mvo> pedronis: there is an open pr to make it date based we could make it month based
<mvo> ogra: yw, sorry that its a bit confusing currently
<kyrofa> Hey mvo, although the yaml spec doesn't guarantee it, will the `environment` dict be evaluated in order?
<kyrofa> I assume so, just want to double check
 * cachio afk
<ogra> jdstrand, i see very curious things in my log from the hexchat snap ...
<ogra> kernel: audit: type=1400 audit(1536089686.295:34656): apparmor="DENIED" operation="open" profile="snap.hexchat.hexchat" name=2F686F6D652F6F6772612F736E61702F686578636861742F33392F2E636F6E6669672F686578636861742F7363726F6C6C6261636B2F7562756E747520736572766572732F23626561676C652E747874 pid=4797 comm="hexchat" requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
<ogra> (hexchat obvously works just fine ... as i'm just typing in it ... but this line repeats every 10 sec or so, growing my logs)
<ijohnson> ogra: you can decode the name there using aa-decode from the apparmor-utils package
<ogra> ijohnson, !
<ogra> ijohnson, thanks a lot, that helps
<mvo> kyrofa: hey, sorry for the slow reply. iirc the goyaml we use gives us a stable ordering, I can double check tomorrow
<niemeyer> It does..
#snappy 2018-09-05
<Caelum> zyga: if you have a lot of stuff to do, I can probably figure out how to rip out the suse go macros
<Doctor_Nick> is there a way to override $SNAP_USER_COMMON? snapd seems to not like my glusterfs mounted home directory
<zyga> Good morning
<zyga> Doctor_Nick: hey, can you please tell me more
<zyga> Do you have any issues with snaps?
<zyga> Network file systems may need a special tweak for confinement
<zyga> Please share any issues you have and Iâll try to help
<zyga> Caelum: Iâm progressing and I should have alpha build soon (perhaps today)
<Caelum> zyga: nice
<zyga> School run
<zyga> Hey mborzecki
<mborzecki> morning
<zyga> 6 am wake up time today
<mborzecki> heh, 630 for me, preping kids to school took a bit longer than anticipated
<zyga> Iâm on the bus :P
<zyga> Memories of commuting
<mborzecki> oh, wow :)
<zyga> (Horrors)
<mborzecki> is the bus moving? :)
<zyga> Yes
<zyga> Barely
<zyga> Iâll be operational soon
<zyga> I sent some patches to my branch
<zyga> Renamed Secure
<mborzecki> there were some stats regarding traffic jams across the eu, polish cities were in the top tier, iirc lodz was even higher than warsaw :/
<mborzecki> go version go1.11 linux/amd64, finally updated
<zyga> re
<zyga> mborzecki: in Palamos the only traffic jam was in the alley next to the school when all the parents that drive to school were dropping their kids off
<zyga> mborzecki: on 9:00
<zyga> mborzecki: work starts 9:15
<zyga> that's unfair, right? :)
<Doctor_Nick> zyga: that's exactly it
<zyga> Doctor_Nick: hey :-)
<zyga> Doctor_Nick: can you please share 'dmesg | grep DENIED\
<zyga> er
<zyga> 'dmesg | grep DENIED'
<Doctor_Nick> yeah
<zyga> I suspect a small tweak will enroll another network filesystem to the extension we did for NFS
<Doctor_Nick> hmmm
<Doctor_Nick> it's not showing up
<Doctor_Nick> cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system
<Doctor_Nick> that's the error message that I'm getting
<zyga> what is your $HOME set to?
<Doctor_Nick> i created a link from ~/snap to /stuff/snap, which is on the local disk
<Doctor_Nick> /users/nickz
<zyga> Doctor_Nick: symlinks won't cut it
<Doctor_Nick> i see
<zyga> you must create a bind mount from whatever your home directory is to /home/$LOGNAME
<zyga> and /home/$LOGNAME/snap must be a directory or a bind mount there
<zyga> sorry, it's a bit complex and symlinks are not transparent to a certain layer
<Doctor_Nick> yeah
<zyga> I can show you how to do that if you need to
<Doctor_Nick> zyga: yeah, i'd appreciate that
<zyga> Doctor_Nick: we can do a quick test first
<zyga> Doctor_Nick: then we can make that happen automatically by editing /etc/fstab
<zyga> Doctor_Nick: you will need root access, do you have that?
<Doctor_Nick> yup
<Doctor_Nick> "starbuck:/gv0 /users glusterfs defaults,_netdev,noauto,x-systemd.automount 0 0
<zyga> Doctor_Nick: excellent, do you have /home/$LOGNAME on your machine?
<Doctor_Nick> yeah, I can create it
<zyga> Doctor_Nick: please do
<Doctor_Nick> ok
<zyga> Doctor_Nick: then try this: sudo mount --rbind /users/$LOGNAME /home/$LOGNAME
<zyga> Doctor_Nick: what does HOME expand to? is it /users/$LOGNAME?
<Doctor_Nick> yup
<zyga> ok
<zyga> I suspect you will need to switch that
<zyga> but not sure actually
<zyga> I'm curious why /users and not /home - are some users on this machine local and some remote?
<Doctor_Nick> yes, that's it
<zyga> once you do that bind mount, please export HOME to the new value in a shell
<zyga> and try running a snap from command line
<zyga> (any simple snap)
<zyga> Doctor_Nick: thanks, I wish we could support this better out of the box
<Doctor_Nick> huh
<Doctor_Nick> it's still using the default home location
<Doctor_Nick> cannot create user data directory: /users/nickz/snap/vapor-master/x1: Read-only file system
<zyga> Doctor_Nick: aha, it's probably reading your home directory location from /etc/fstab still
<Doctor_Nick> ok
<zyga> Doctor_Nick: can you change that for a quick experiment
<zyga> and try again
<zyga> (we can change it back if it fails)
<Doctor_Nick> uhm
<Doctor_Nick> if I unmount this thing, my system is going to hardlock
<Doctor_Nick> i've done this before
<Doctor_Nick> https://pastebin.com/ncju0t4L
<Doctor_Nick> that's my whole fstab file
<Doctor_Nick> the setup doesn't jsut mount my home folder, it mounts all the network users who are logged in to /users
<zyga> right but we don't need to change that
<Doctor_Nick> ok
<zyga> I meant your /etc/passwd (or appropriate, whatever holds your user entry)
<Doctor_Nick> ahhhhh
<zyga> on your local system we'd change /etc/fstab to have an extra bind mount
<zyga> from memory that would look like this:
<zyga>  /users/foo /home/foo none bind 0 0
<Doctor_Nick> hey, there it goes
<Doctor_Nick> its working now
<zyga> once the /users vs /home issue is out of the way
<zyga> you may run into another issue
<zyga> but for that one we have a workaround that was made for NFS
<Doctor_Nick> ok
<zyga> and I can extend that to glusterfs easily
<Doctor_Nick> zyga: isn't there away to just override SNAP_USER_COMMON/SNAP_COMMON?
<zyga> brb
<zyga> re
<zyga> Doctor_Nick: so it's not that easy
<zyga> it's not about changing it really
<zyga> for instance /home is re-mapped inside the application container
<zyga> and /users doesn't even exist there
<zyga> we have a per-user mount namespace where we might be eventually able to do per-user $HOME remapping
<zyga> but that's not ready yet
<zyga> the apparmor needs to really really understand where _all_ home directories are
<Doctor_Nick> ah hah, ok
<zyga> so even if we allow changing that easily it would not work out of the box
<zyga> I think that really the only sane solution is doing the remapping internally in the per-snap, per-user mount namespace
<zyga> and that's something I'm working towards enabling
<zyga> then you can have any $HOME
<Doctor_Nick> yeah, that's something we'd like
<zyga> but at runtime for the snap it would show up as /home/$LOGNAME
<zyga> and would really be your $HOME in practice
<zyga> I'll make a note about this, it looks doable in a few weeks
<zyga> I need to sort out prerequisites first
<zyga> Doctor_Nick: try making the bind mount permanent by adding a line to /etc/fstab as I suggested
<zyga> and reboot just in case to test that :)
<Doctor_Nick> yeah, i'll give that a shot
<mvo> zyga: good morning! how are the tests looking today?
<zyga> thank you for sticking with snaps :)
<zyga> good morning mvo
<zyga> I pushed some things in the morning, let me look now
<zyga> last night I saw failures to prepare opensuse
<mvo> ok
<zyga> some archive skew, it was complaining about package hash
<Doctor_Nick> yeah, we're using them to deploy our server packages
<zyga> that's great :)
<zyga> are you using private snaps?
<zyga> that you build yourself
<zyga> or are those public snaps?
<zyga> hey sil2100
<Doctor_Nick> private snaps
<zyga> Doctor_Nick: that's awesome! thank you for sharing that
<zyga> mvo: my PR is progressing, no failures so far
<zyga> mvo: that's both prepare and execute failures
<zyga> so fingers crossed :)
<mvo> nice!
<Doctor_Nick> we understand that snapcraft.io is going to implement private github support sometime in the future
<zyga> Doctor_Nick: I think so but I'm not the best person to ask abou tthat
<sil2100> zyga: hey!
 * sil2100 is back from the dead more-or-less
<zyga> sil2100: are you okay?
<sil2100> zyga: yeah, just fighting a flu this week, but I feel better today
<zyga> sil2100: honey and tea
<zyga> (and rum :)
<zyga> ;-)
<mborzecki> i'll be pushing a couple of fixes for go 1.11 in a minute
<zyga> mborzecki: thank you
<zyga> mborzecki: man, tumbleweed doesn't have go 1.11 yet
<mborzecki> https://github.com/snapcore/snapd/pull/5766
<mborzecki> mvo: any chance of getting this to 2.35?
<zyga> mborzecki: I'd say: just propose a 2.35 PR
<mborzecki> wondering if we should run unit tests on arch, or just any other distro but with the latest go release
<zyga> mvo: my PR is green now, so maybe we're back to good
<zyga> mborzecki: +1
<zyga> I think
<zyga> mborzecki: can we do a pass over my PR
<zyga> mborzecki: I can take some parts and propose them and keep shrinking the main one
<zyga> mborzecki: we could identify some things that could land this way
<mborzecki> zyga: give me half an hour and we can do HO then
<zyga> sure, thank you
<mborzecki> damn, gocode stopped working with go1.11
<pstolowski> morning
<zyga> good morning pawel
<mvo> mborzecki: I'm looking at snap-failure right now, when it was triggered for your user, did that had any bad consequences
<mvo> mborzecki: going over the code it seems we want this to be available in classic as well eventually, once we use the snapd snap there its a nice mechanism to recover from bad snapds which will also work on classic
<zyga> mborzecki: Ill head home, I'll call you from there, it's too noisy here
<mborzecki> zyga: ack
<mborzecki> mvo: i'm not sure what systemd did there if OnFailure service failed too, meaning that snapd might have not been restarted at all, i can try it though
<mvo> mborzecki: oh, interessting, let me look at this
<mvo> mborzecki: it should handle this gracefully but it sounds like there is a bug
<mborzecki> mvo: is it restarted?
<mvo> mborzecki: still looking, need to ensure I got the right version :)
<mborzecki> haha ack :)
<mvo> mborzecki: yes it did restart, snapd restarted, snap-failure exited cleanly
<mvo> mborzecki: would love to learn more if you saw something different
<mborzecki> mvo: the problem the user had is that snap-failure was not shipped by the package, so snapd.failure.service exited with error
<mvo> mborzecki: aha, got it
<mvo> mborzecki: that makes sense
<mborzecki> mvo: otoh, maybe then i should just ship snap-failure instead of dropping it, but there's no reexec on arch anyway, so chaces of snapd running from the snapd snap are rather low
<mvo> mborzecki: yeah, it will only do anything if there is a snapd snap availalbe
 * zyga waits for the bus to leave
<ogra> dbus ?
<zyga> plbus :)
<zyga> haha
<ogra> :D
<mborzecki> ztm :P
<zyga> indeed
<zyga> re
<zyga> mborzecki: I'm available but no rush, working on some stuff
<zyga> mborzecki: so when you feel like it just ping me
<mborzecki> zyga: ok, just finishing a thing in snapstate
<zyga> sure :)
<mborzecki> almost there, left with 2 panics in api tests
<mborzecki> btw. we set "seeded": true in the tests, but seed-time is not set
<mvo> Chipaca: thank you for the review on the gcc thing and yeah the original version was bogus
<Chipaca> mvo: i think it worked but was frowned on
<mvo> Chipaca: yeah, it did actually, but go vet in 1.10 started complaining so it was not quite the right fix
<dot-tobias> Hi everyone. Is there any way to put a symlink in my snap's readonly part (i.e. part directory) that points to the snaps /tmp directory? I guess $TMPDIR would point to the build system's tmp directory, and when I try to create a symlink in my install hook, it aborts with âread-only filesystemâ.
<pedronis> mborzecki: well, very little code cares about seed-time sof ar
<mborzecki> pedronis: heh noticed that,  i'll be opening a RFC with snapstate changes soon, will ping you and Chipaca :)
<niemeyer> Morning all
<pedronis> it was added recently to help with the hold logic
<niemeyer> dot-tobias: That probably won't work.. you can try to make a symlink and pack it inside the snap itself, but I think the reviewing process will flag that as having symlinks pointing outside of the snap
<niemeyer> dot-tobias: You can try it, though..
<pedronis> mborzecki: I'll will try to do reviews in the afternoon
<dot-tobias> niemeyer Thanks, that's what I feared â¦  My snap is not ready for review yet, but good to know that this would be an additional bump in the road. Root problem is that the framework I'm using for my snapped (web) app has a tmp directory hardcoded at app-root/tmp
<mborzecki> pedronis: thanks
<niemeyer> dot-tobias: Hmm
<niemeyer> dot-tobias: There's a nice solution here:
<niemeyer> dot-tobias: We have an experimental feature, which is soon leaving the experimental status behind, and allows you to control the mountpoints in more detail
<niemeyer> dot-tobias: That means you could even have a tmpfs mounted on your read-only space
<niemeyer> zyga: Do we have good docs for layouts already?
<zyga> niemeyer: hey
<niemeyer> dot-tobias: This is the discussion where you can find details of the syntax:
<niemeyer> dot-tobias: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/45
<zyga> niemeyer: we only have the forum post for the layouts we had before; I didn't write anything more
<dot-tobias> niemeyer that sounds interesting. Thanks :-) Will look into it
<niemeyer> dot-tobias: The experimental feature is already working on your snapd.. you just need to enable it with "snap set system experimental.layouts=true
<niemeyer> "
<zyga> niemeyer: but that page has some extensive discussion and examples that seem like a good starting point
<niemeyer> zyga: We need a doc page for that
<zyga>  actually
<Chipaca> niemeyer: when're we dropping the experimental flag on it?
<zyga> I think we may have one, hold on
<niemeyer> Chipaca: I'm hoping very soon.. I haven't been hearing much about it lately, which is both good and bad
<zyga> no, we don't have one
<zyga> I'll start it now
<dot-tobias> niemeyer: Does enabling experimental features have any impact on releasing my snap (e. g. only on beta/dev)?
<niemeyer> dot-tobias: No.. you can release it.. it may get held back by review, but we can pass it if the feature is in a ready-enough state, which is definitely the case for layouts
<niemeyer> dot-tobias: At installation time, the snap command will warn that this depends on an experimental feature, and won't proceed unless the system acks the support for the feature via the fla
<niemeyer> flag
<dot-tobias> niemeyer: Good to hear, thanks! Will try it out and give feedback here / in the forum thread.
<niemeyer> dot-tobias: That's great, thank you. That's exactly the kind of info we need to get this feature out of experimental
<Chipaca> niemeyer: should we make it so experimental features are always enabled on edge?
<zyga> Chipaca: oooh
<zyga> that's neat :)
<Chipaca> we could even get fancy and decide which ones get auto-enabled on beta/candidate/...stable
<Chipaca> mborzecki: it took me five re-reads to find the typo you fixed in #5764
<Chipaca> keep me away from writing stuff today
<Chipaca> or maybe from proofreading stuff
<Chipaca> yeah, the latter
<mborzecki> gccooo :)
<niemeyer> Chipaca: No, I think we should still ask the *environment* in which the snap is installed to acknowledge the fact they are using an experimental feature
<niemeyer> Chipaca: Part of the point of the flag is to tell people "hey, you are using something that can disappear altogether tomorrow"
<Chipaca> point
<dot-tobias> niemeyer: Looks like I'm doing something wrong? snapcraft complains about the layout key in snapcraft.yaml â building with snapd 2.35 on ubuntu server 16.04.05 LTS, snap get system experimental returns experimental.layouts true. Using layout as a top-level construct as zyga documented in https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/2
<zyga> dot-tobias: hold on
<zyga> I'm documeting this right now, I already covered that,
<zyga> I'll share the page in a sec
<niemeyer> dot-tobias: Not sure about what's the status of snapcraft in that regard.. it should already be accepting it, but apparnetly it isn't?  You can get away with that by putting the layouts map inside a "passthrough" map in snapcraft.. that tells it to ignore the syntax and just pass it on to snapd
<dot-tobias> zyga great, thanks! Brewing fresh coffee in the meantime :-)
<zyga> *envy* :)
<niemeyer> dot-tobias: The passthrough map is literally named "passthrough".. that's probably what zyga is about to document
<zyga> yes :)
<niemeyer> zyga: Thanks for that
<zyga> dot-tobias: ok
<zyga> back?
<dot-tobias> zyga: Yes, back and trying out the layout feature with passthrough. Getting the same âcannot create writable mimicâ error like https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/64?u=tobias
<zyga> one sec
<dot-tobias> But I'm probably doing something wrong ð
<zyga> ok
<zyga> ready
<zyga> https://forum.snapcraft.io/t/snap-layouts/7207
<zyga> please read that, I'll read the error you got
<zyga> dot-tobias: :)
<zyga> niemeyer: ^ feedback welocme
<zyga> *welcome
<dot-tobias> zyga: Error was: âcannot update snap namespace: cannot create writable mimic over "/": permission denied / snap-update-ns failed with code 1â relevant snapcraft.yaml part: passthrough:
<dot-tobias>   layout:
<dot-tobias>     /mytmp:
<dot-tobias>       symlink: $SNAP_DATA/rails_tmp
<zyga> dot-tobias: you cannot create a new top-level directory. I'll adjust the error so that it is clear
<zyga> ogra, pstolowski: IIRC you made some snaps with layouts, can you have a look at https://forum.snapcraft.io/t/snap-layouts/7207 please?
<Chipaca> niemeyer: I've replied to a few of your comments on #5514, if you could take a look you'd unblock me wholly
<niemeyer> Chipaca: NIce, thanks.. will be on it in a few mintues
<zyga> dot-tobias: I assume you don't really need a new directory called /mytmp and that you were just exploring
<niemeyer> zyga: Thanks, will check
<pstolowski> zyga: sure, gladly
<dot-tobias> zyga: Yes, âexploringâ or âfumbling aroundâ ð I actually need a directory in my snap's app directory that's writable
<zyga> dot-tobias: that should be doable :)
<ogra> zyga, an example for the symlink case would be nice ... otherwise it looks good
<zyga> ogra: +1
<zyga> dot-tobias: please let me know if something about layouts is unclear from the documentation or if you are trying to achieve something and it is unclear if layouts help or how they could be used
<dot-tobias> zyga: First, thanks for the comprehensive writeup! Makes things much clearer. If I understand the âdeeply nested pathsâ section correctly: If my app contains a folder âmyfolderâ and within that, I want to have a symlink named âtmpâ pointing to $SNAP_DATA/tmp â¦ I would create a layout mapping âmyfolder/tmpâ with keyword `symlink` to $SNAP_DATA/tmp?
<zyga> dot-tobias: that limitation only applies to read-only spaces
<zyga> dot-tobias: inside $SNAP_DATA you can do anything
<zyga> if you want a symlink $SNAP_DAT/tmp -> (whatever) you can just do that
<zyga> but
<zyga> layouts are not usually used to create things in $SNAP_DATA
<zyga> (you can always do that in your application code or the configure hook)
<zyga> can you give me a concrete exapmle please?
<ogra> https://github.com/ogra1/xdmcp-client/blob/master/snap/snapcraft.yaml is an example for symlink
<dot-tobias> zyga: It's the other way round: I need a symlink pointing from âtmpâ in my app's root directory (which is read-only) to $SNAP_DATA/tmp, so that the app can write stuff at the expected path $app_root/tmp.
<zyga> ah
<zyga> that's ok
<zyga> so layout like:
<zyga> $SNAP/tmp: symlink $SNAP_DATA/tmp
<zyga> $SNAP/tmp: symlink: $SNAP_DATA/tmp
<zyga> note that this will _not_ create $SNAP_DATA/tmp
<zyga> symlink targets are NOT created by laytous
<zyga> *layouts
<zyga> you can always use a bind mount for simplicitly
<zyga> $SNAP/tmp: bind: $SNAP_DATA/tmp
<dot-tobias> zyga: Ah, that's the missing part. So I would create $SNAP_DATA/tmp in my install hook? Will explore bind mounts right now
<zyga> just try the bind layout
<zyga> it's easier
<zyga> you will not need a hook
<mborzecki> zyga: ok, going through your PR now
<zyga> mborzecki: cool, wanna HO?
<mborzecki> zyga: let me go through it first
<zyga> +1
<niemeyer> mup: you ok?
<niemeyer> Apparently the channel is still flagging off messages from unauthenticated people
<niemeyer> mup: now?
<mup> niemeyer: I apologize. I'm a program with a limited vocabulary.
<niemeyer> Yeah
<zyga> haha
<dot-tobias> zyga: Would the mount be visible when ls -la /snap/my-snap/current/? (it does not, but I'm unsure if that's because of a faulty yaml definition or the bind is only visible within the running snap)
<zyga> I love those discussions with mup :)
<zyga> dot-tobias: it's only visible from the running snap
<zyga> dot-tobias: to see it without any confinement, run your snap (say "foo") and then
<zyga> dot-tobias: sudo nsenter -m/run/snapd/ns/foo.mnt
<zyga> dot-tobias: you can always run "snap run --shell foo" but this will be fully confined and you won't be able to explore as freely
<dot-tobias> zyga: Ok, thanks. That clears things up for me, petty web-developer-turned-snapcrafter :-D
<Chipaca> niemeyer: well, on signing in to freenode it still says âDue to the persistent ongoing spam, all new connections are being set +R (block messages from unidentified users) and will be scanned for vulnerabilities. This will not harm your computer, and vulnerable hosts will be notified.â
<niemeyer> Chipaca: I assume that's for private messages.. the channel has its own setting, which apparently isn't on for ours
<niemeyer> Maybe they just forced it
<Chipaca> ah
<Chipaca> niemeyer: yep, +R is about private messages
<Chipaca> https://freenode.net/kb/answer/usermodes
<Chipaca> niemeyer: as opposed to channel mode +r
<niemeyer> I'll need to improve mup to identify itself properly on reconnections
<niemeyer> It's reasonable anyway
<Chipaca>  /msg chanserv info #snappy
<Chipaca> ^ to see what modes #snappy  has
<mup> PR snapd#5771 opened: selftest: add test to ensure selftest.checks is up-to-date  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5771>
<Chipaca> bah, chanserv seems busted
<niemeyer> Yeah, seems off.. I'm assuming they just got tired of all spamming and forced it in code for every channel
<Chipaca> k
<niemeyer> zyga: Please ping degville about the doc as well.. he seems off right now
<zyga> niemeyer: ack
<pstolowski> zyga: the doc for layouts looks fine; question on the "new entries in the / directory" limitation - is this problematic to handle, or simply not implemented yet? i can imagine this could be interesting for some weird/proprietary software
<zyga> pstolowski: it's an architectual limitation, it's very hard to pull off and would require some action to happen before we pivot_root
<zyga> pstolowski: we _could_ do it with a new filesystem eventually
<zyga> but not now
<zyga> pstolowski: we could also do it if we had snap-confine make / a tmpfs
<zyga> and start with a bind mount farm based on the base snap
<pstolowski> zyga: this doc reminded me i need to play with layouts in my problematic snap again
<zyga> _that_ would not require a new filesystem
<zyga> pstolowski: thanks, please share more feedback as you get it :)
<zyga> pstolowski: and that is something new snap-confine could just do if we choose to implement it
<zyga> pstolowski: but I haven't seen any demands for that yet
<niemeyer> Chipaca: Commented on #5514.. I think you're fully unblocked now.. please ping otherwise
<mup> PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<Chipaca> niemeyer: i replied to your first reply already :-D
<pstolowski> zyga: ack, i see. indeed, i cannot think of any particular app needing it
<niemeyer> Chipaca: I need to type faster... :P
<Chipaca> niemeyer: the problem with having warnings accumulate args is that now we need to think about expiring the args somehow
<Chipaca> niemeyer: unless I key on the format, and forget older args
<Chipaca> that'd work
<niemeyer> Chipaca: I actually had in mind keeping the exact logic you had
<Chipaca> (if I keep older args, how are they presented to the user? etc)
<Chipaca> niemeyer: so not worrying about dupes that much?
<Chipaca> ok
<niemeyer> Chipaca: It's just convenience so we don't need to Sprintf ourselves before cooking the message
<niemeyer> Chipaca: In practice, just Sprintf as first thing, and keep the rest
<niemeyer> Chipaca: (key is composed message)
<Chipaca> ok
<Chipaca> niemeyer: AddWarning -> Warn, and Warnf would be Sprintf version, ok?
<mborzecki> zyga: btw https://github.com/snapcore/snapd/pull/5760/files#diff-6cdce42a784f927f710f0f5241a8c68dR84 such an opportunity lost :)
<mup> PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places <Created by zyga> <https://github.com/snapcore/snapd/pull/5760>
<niemeyer> Chipaca: We do want dupes when the message is indeed different.. e.g. two different broken snaps
<niemeyer> Chipaca: I'd just have Warnf for now
<zyga> mborzecki: ?
<Chipaca> niemeyer: ok
<niemeyer> Chipaca: Warnf("usual message") would work fine.. only danger is embedding %s on the message
 * Chipaca nods
<Chipaca> the f should have us remembering
<zyga> mborzecki: ass usual I was reasonable ;)
<Chipaca> (problem with daemon error handlers was there was no f to remember that)
<Chipaca> :-)
<Chipaca> anyway, time for a quick break before a meeting
<Chipaca> niemeyer: thanks!
<niemeyer> Chipaca: np!
<Chipaca> niemeyer: actually, given Warnf(format, args...), i could be extra cautious and only sprintf if len(args) > 0
<Chipaca> that'll dtrt errytime
<mup> PR snapd#5772 opened: image: fix incorrect error when using local bases <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5772>
<zyga> mvo: +1
<mvo> zyga: thank you
<mvo> hrm, tests look unhappy
<mvo> opensuse?
<zyga> mvo: what are you seeing?
<ogra> hmpf ...
<ogra> apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/gnome/ScreenSaver" interface="org.gnome.ScreenSaver" member="SimulateUserActivity" mask="send" name="org.gnome.ScreenSaver" pid=5523 label="snap.qemu-virgil.qemu-virgil" peer_pid=3387 peer_label="unconfined"
<zyga> opensuse is pretty unhappy
<zyga> but for other reasons
<zyga> ogra: there's an interface that deals with screensavers, maybe a bug or extension?
<zyga> I need to run to pick up my son from school
<ogra> (screen-inhibit-control is connected ... yet i get this message every 10 sec)
<zyga> ogra: ah,
<ogra> i'll wait for jamie to get up
<zyga> ogra: I can look as well but walking to the bus stop now
<ogra> looking at the intreface code i think the "path=" line for "# gnome, kde and cinnamon screensaver" is missing bits
<ogra> it has "path=/{,ScreenSaver}" while i think it should have "path=/{,org/freedesktop/,org/gnome/}ScreenSaver" like the API rule above
<mup> PR core18#68 opened: Install rsyslog in core18 <Created by sil2100> <https://github.com/snapcore/core18/pull/68>
<mborzecki> zyga: HO?
<zyga> Za moment
<mborzecki> off to pick up the kids
<jdstrand> zyga: note that snapd could manage apparmor via the home.d mechanism. 'snap set config home=...' or something is totally doable. it's snap-confine that is the real blocker
<jdstrand> snap set core home=.... whatever the syntax is ;)
<zyga> jdstrand: I think we could do it magically automatically soon
<ogra> jdstrand, did you see above ? seems i have issues with screensaver inhibit once again ...
<mborzecki> re
<mup> PR snapd#5773 opened: tests: avoid removing core snap on reset <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5773>
<zyga> re
<zyga> back from school & lunch
<zyga> checking your feedback mborzecki :)
<dot-tobias> What's the best way to move all files of a part into a subdirectory (plugin: dump and source from git repo)? If I use organize: '*': subfolder/ like kyrofa did in https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L140 , I get an infinite recursion as snapcraft copies the part's root folder to the subdirectory again
<dot-tobias> And feedback for zyga: After some trial and error, bind-ing write-enabled locations into my app works perfectly - huge thanks, will write up my experience with layouts in the thread later.
<zyga> dot-tobias: I don't know, I'm not very familiar with how organise works actually
<zyga> dot-tobias: woot, I'm glad I could help :)
<zyga> dot-tobias: I'm working on a blocker that will allow us to soon move layouts out of beta
<zyga> kyrofa: do you know the answer to dot-tobias' question?
<zyga> kyrofa: about organise
<ogra> i tend to use "plugin: nil" and an "override-build: |" with a simple "cp -av * SNAPCRAFT_PART_INSTALL" usually
<dot-tobias> zyga: Glad to hear that layouts might soon be stable! Would bring fresh coffee to Spain, but maybe buymeacoffee or similar is faster ð Thanks a lot in any case.
<zyga> dot-tobias: I'm no longer in Spain but I appreciate the gesture :)
<zyga> (and I miss Spain:)
<dot-tobias> ogra: Just tried that, gives the same error â¦ RecursionError: maximum recursion depth exceeded ð Retrying after a full snapcraft clean right now
<mup> PR snapd#5772 closed: image: fix incorrect error when using local bases <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5772>
<dot-tobias> zyga: I should've looked up your Github profile
<dot-tobias> zyga: â¦'s location instead of your Twitter profile ð Anyway, subbed to your blog.
<zyga> oh, I should update both
<zyga> thank you!
<zyga> dot-tobias: btw, I'm at new.zygoon.plk
<zyga> I need to redirect from the old blog
<dot-tobias> check
<dot-tobias> ogra: cleaning up and your plugin nil + cp -av + organize did the trick. Thanks!
<mup> PR snapd#5769 closed: partition: remove unused runCommand <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5769>
<ogra> :)
<didrocks> hey popey! did you hear anything about the snapcraft docker image issue I mentioned on Monday? (I was hoping to see Sergio around, but seems he isn't)
<didrocks> (CI on Yaru is still failing, and so, no theme update since Friday)
<ogra> didrocks, there are a bunch of recent threads in the forum about snapcraft and docker builds
<didrocks> ogra: oh? I searched for docker and no recent result on first page (but browser search)
<didrocks> I guess I found it: https://forum.snapcraft.io/t/permission-denied-when-building-with-snapcore-snapcraft/7186
<didrocks> ok, switching to stable docker image
<mup> PR snapd#5774 opened: tests: introduce a helper for installing local snaps with --name <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5774>
<mborzecki> zyga: ^^ something you requested
<zyga> mborzecki: thank you
<didrocks> ogra: thanks a lot! Switching to stable works: https://github.com/ubuntu/yaru/pull/784
<mup> PR ubuntu/yaru#784: Use stable docker image <Created by didrocks> <https://github.com/ubuntu/yaru/pull/784>
<ogra> :)
<pstolowski> niemeyer:  i mean https://github.com/snapcore/snapd/pull/5632
<mup> PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<onyb_fr7> Hello. I am trying to create a snap for an electron app, that communicates with a Python server via HTTP (yes, I know it's weird). I therefore need my snap to have both Python and NodeJS runtimes. Does anyone know how to achieve this? This is where I am right now: http://paste.debian.net/plainh/46cb69b9
<jdstrand> ogra: jeez, everyone accesses the api slightly differently. this is the issue: interface="org.gnome.ScreenSaver"
<jdstrand> we only allow interface=org.freedesktop.ScreenSaver
 * jdstrand adds to list
<ogra> jdstrand, yeah ... thats what i guessed
<ogra> i blame qemu :P its their call
<Chipaca> mborzecki: it's weird because go-8 doesn't choke on https://pastebin.ubuntu.com/p/vsqqK6RDPn/
<mborzecki> Chipaca: using `info := &snap.Info{SideInfo: snap.SideInfo{RealName: "foo", Revision: snap.R(12)}}` works too
<mborzecki> Chipaca: i have go1.10.3 gccgo (GCC) 8.2.1 20180831 linux/amd64
<Chipaca> mborzecki: yep
<Chipaca> mborzecki: but 'go-8 test' in snap/ still fails
<Chipaca> with that error
<mup> PR snapd#5775 opened: tests: also run unit/gccgo in 18.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5775>
<Chipaca> mvo: mborzecki: ^ :-)
<mvo> Chipaca: neat
<mvo> Chipaca: ideally we also run on 16.04
<mvo> Chipaca: because that is what powerpc uses
<mborzecki> w8, it works there?
<mborzecki> on 16.04 i mean
<Chipaca> mvo: we were running on 16.04, but 16.04 amd64 is go-6
<Chipaca> mvo: go-8 is not available for amd64 16.04
<Chipaca> powerpc using go-8 in 16.04 is weird :-)
<mvo> Chipaca: yeah, sorry, what I mean is we should run on both go-6 and go-8
<Chipaca> mvo: ah. There is no go-8 for 16.04 amd64 afaik
<Chipaca> unless there's some weird and wonderful magic to get it :-)
<Chipaca> mvo: if there is, super easy to fix this test to use both :-)
<mborzecki> at least you can have go and gccgo, in arch gccgo conflicts with go, you need to choose one :)
<Chipaca> mborzecki: mbuahaha
<Chipaca> mborzecki: sorry, i need to go get some biscuits to eat with this schadenfreude
<mborzecki> heh :)
 * zyga gets a haircut
<Chipaca> Hmmm. https://pastebin.ubuntu.com/p/FMmsYMwYs3/
<Chipaca> running the unit tests with go-8 is illuminating
<Chipaca> in the same sense that a bag over the head is
<kyrofa> zyga, darn, that was quite a while before I was awake, dot-tobias seems to be gone
<zyga> No worries
<zyga> If you explain I will learn and relay next time
 * cachio lunch
<kyrofa> I needed to see the yaml I'm afraid
<zyga> kyrofa: sure, next time perhaps :)
<ijohnson> zyga: whenever you get a chance could you take a look at https://forum.snapcraft.io/t/using-snapctl-in-install-hook-to-disable-services/7214
<zyga> ijohnson: sure
<ijohnson> Thanks! The trick you told me about doesn't seem to work quite right :-/
<zyga> right, I read your post
<zyga> pstolowski, Chipaca: I don't suppose you remember if we have a test where a install hook disables a service so that it doesn't auto-start on installation?
<pstolowski> zyga: 99% sure we don't
<mvo> Chipaca: haha on the pastebin
<mup> PR snapd#5764 closed: snap: use snap.SideInfo in test to fix build with gccgo <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5764>
<mvo> cachio: pr 5776 hopefully helps with the squid issues
<mup> PR #5776: tests: port proxy test to use python tinyproxy <Created by mvo5> <https://github.com/snapcore/snapd/pull/5776>
<mup> PR snapd#5776 opened: tests: port proxy test to use python tinyproxy <Created by mvo5> <https://github.com/snapcore/snapd/pull/5776>
<cachio> mvo, great
<cachio> mvo, thanks for that
<mup> PR snapcraft#2231 closed: Release changelog for 2.43.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2231>
<Saviq> jdstrand: hey, so we've hit a snag with the wayland interface on core... /run/user/0 doesn't exist by default...
<jdstrand> Saviq: yeah, something outside of snapd would ideally create that (eg, systemd), but it doesn't. this is why the wayland interface has this: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/wayland.go#L60
<jdstrand> Saviq: ie, the slot side is allowed to create it
<Saviq> ogra: â
<ogra> jdstrand, well, that doesnt work here
<jdstrand> can you elaborate?
<ogra> Sep 05 14:09:51 localhost.localdomain kernel: audit: type=1400 audit(1536156591.188:26): apparmor="DENIED" operation="mkdir" profile="snap.chromium-mir-kiosk.chromium" name="/run/user/0/" pid=2279 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<jdstrand> that's the plugs side
<jdstrand> this is in waylandPermanentSlotAppArmor
<jdstrand> is chromium perhaps starting before wayland and trying to figure stuff out?
<Saviq> yeah chromium should never try and mkdir that should it?
<jdstrand> I mean, it shouldn't, that doesn't mean it doesn't
<ogra> it should be using the xwaland launcher from https://github.com/MirServer/xwayland-kiosk-helper/blob/wayland-updates/xwayland-preload/xwayland-kiosk-launch
<Saviq> yeah https://github.com/gerboland/xwayland-kiosk-helper/blob/wayland-updates/xwayland-preload/xwayland-kiosk-launch#L4 is wrong
<jdstrand> xwayland can create it
<Saviq> xwayland sits in with chromium
<ogra> i tried to copy that for wmx-kiosk-session and get the same behaviour
<Saviq> so it's only mir-kiosk that can
<ogra> right, XWayland lives in the client snap
<jdstrand> whatever 'slots: wayland' in the snap can do it
<Saviq> yes, that
<ogra> ok, then mir-kiosk must do it
<Saviq> ogra: and the new version does
<Saviq> https://github.com/MirServer/mir-kiosk/pull/9/files#diff-1250d6fc0bbea1fda5019f2d7fc66ce4L15
<mup> PR MirServer/mir-kiosk#9: Just use wayland interface, remove wayland-socket-dir content interface  <Created by gerboland> <https://github.com/MirServer/mir-kiosk/pull/9>
<Saviq> ogra: did you install mir-kiosk from edge/wayland-interface?
<ogra> just from edge
<Saviq> (I will remove mkdir from the wrapper, that's wrong)
<Saviq> ogra: oh yeah, then that doesn't have that
<Saviq> jdstrand: ok thanks, that explains things :)
<ogra> i dont see a edge/wayland-interface in the channels/tracks list of snap info
<jdstrand> yw
<Saviq> ogra: branches are not displayed
<ogra> bah
<Saviq> that's why I mentioned the name explicitly
<Saviq> â #mir-server
<Saviq> hmm are LP snap builders not allowed to access npm? https://launchpadlibrarian.net/386955486/buildlog_snap_ubuntu_xenial_armhf_electron-mir-kiosk-snap_BUILDING.txt.gz
<ogra> given they are also the backend for build.snapcraft.io builds they definitely should be able
<ogra> though there might be special magic involved when they run via build.s.io ... cjwatson should know
<ogra> the error is from npm itself though ...
<ogra> Saviq, https://forum.snapcraft.io/t/build-fails-behind-proxy-on-build-snapcraft-io/6951 btw ...
<Chipaca> mvo: that pastebin would be hilarious, if it weren't consistent
<Chipaca> I mean, woo it's consistent I can debug it, but otoh WTF GCCGO YOU HAD ONE JOB
<mvo> Chipaca: hehe
<mvo> Chipaca: yeah
<mvo> Chipaca: at least the snap/info.go should be fixed now :)
<Chipaca> yep
<mvo> hrm and opensuse is unhappy again
<mvo> oh well
<Chipaca> mvo: why weren't we running one spread per machine flavour?
<Chipaca> was it that travis penalises that?
<Chipaca> it'd be nice to just retry suse if suse failed, for ex
<mvo> Chipaca: yeah, I think so. you get only a fixed number of slots iirc
<Chipaca> right
<mvo> +100 on that
<sergiusens> Chipaca, mvo: you can "retry" a build by use of the travis API and making use of environment variables to drive this; we have that setup for the store team to be able to run our store tests only before each deployment
<sergiusens> mvo, Chipaca: slots are 5, and we share them among the org, but it is not really documented
<Saviq> ogra: thanks
<luv> hi there ... im wondering sometimes I can see a package gets a security fix in ubuntu but a snap with that package as a dependency is apparently not rebuilt
<luv> do you guys plan to fix this?
<Chipaca> luv: packagers get an email when that happens, fwiw
<Chipaca> luv: alerting them to the issue, so they can plan a rebuild
<Chipaca> luv: whether a rebuild is needed or not depends; sometimes the issue affects a part of a library that a program doesn't use, for example
<Chipaca> luv: and that is up to the packager to determine, mostly
<luv> i see, for example, vlc is using vulnerable ffmpeg
<luv> ok, seems it has been rebuilt two days ago :)
<luv> i have found loads and loads effectively exploitable vulnerabilities in dependencies in flatpak, seems like snap taking care of the basic security much better
<luv> oh and does fcitx work with snap?
<luv> no, fcitx is not working (testing now in sublime text), that's really lame to be honest, making snap useless for some 2 billion people :)
<popey> luv: yeah, currently ibus works, fctix doesn't
<popey> https://forum.snapcraft.io/t/cant-use-input-method-in-snap-apps/4712/29
<luv> tho everyone uses fcitx for chinese
<luv> and yes sublime text has the same vulnerability in deps as is in flatpak
<luv> and the sandbox is useless
<luv> and sublime is in the official snap store ... seems as bad as flatpak :(, but let me try the exploit first :)
<popey> sublime isn't confined
<luv> yup
<luv> what about simple stuff like setting a bigger interface font? works only for gnome apps too (like in flatpak)?
<ExoUNX> afternoon
<luv> cool, looks like my exploit is not working in snap :)
<popey> :)
<ExoUNX> I'm trying to do nextcloud.enable-https custom
<ExoUNX> and it's a huge pain
<ExoUNX> it creates a live directory that links to letsencrypt/live
<ExoUNX> which is fine, but it wont let specify example.com/cert.pem
<ExoUNX> it just wants to do its own thing T_T
<luv> how can i see the snap deps to verify it has been fixed?
<luv> talking about this one https://www.cvedetails.com/cve/CVE-2017-14867/ btw - flatpak runtimes as used on flathub are still vulnerable; i see sublime-text in snap can't be attacked but git version in the snap is 2.11.0 ... i'd like to verify it's something like 2.11.0-ubuntu5 :)
<popey> the sublime-text snap doesn't contain git
<ExoUNX> on top of that, apparently the config files are located in /var/snap/nextcloud/current/apache and I see nothing
<ExoUNX> except for logs
<luv> oh
<luv> popey: thanks ... so it comes from core or using git from my distro?
<popey> likely your distro
<luv> i guess it's the debian stable git ... that's why i get 2.11 and not vulnerable
<luv> nice
<luv> will play around more later
<popey> have fun!
<popey> I love hearing about this stuff
<jdstrand> roadmr: hi! not urgent, but can you pull r1125 whenever convenient?
<roadmr> jdstrand: sure thing
<roadmr> ugh I'll probably need to wait for tomorrow to merge it, too close to EOD for me to do QA in time :/
<roadmr> but it'll be in the queue
<jdstrand> roadmr: thanks, totally fine. enjoy your eod :)
<popey> diddledan: your mycroft snap is stuck in review. Might want to ping a store person tomorrow to unblock
<diddledan> yeah, I think it was an automated rebuild - I've not pushed anything, but it does look like it's pulled a newer mycroft, so I'll have to test it a bit before releasing widely
<mup> PR snapd#5777 opened: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<mup> PR snapd#5773 closed: tests: avoid removing core snap on reset <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5773>
<mup> PR snapcraft#2243 opened: [WIP] plugin API: support command-chain <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2243>
<Doctor_Nick> what does snapcraft use the build state for?
<Doctor_Nick> i see installed packages, installed-snaps, node-packages, etc.
#snappy 2018-09-06
<Pharaoh_Atem> zyga: https://youtu.be/UOZXERFHsW4?t=58m26s
<Pharaoh_Atem> https://youtu.be/UOZXERFHsW4?t=1h1m32s
<Pharaoh_Atem> niemeyer: nice mention by mattdm about our snap work in an interview about fedora ^
<sergiusens> Doctor_Nick: at the very end of it, you can opt-in to have that in the snap
<Doctor_Nick> sergiusens: ah hah
<sergiusens> there's an env var to allow it all the way through
<Doctor_Nick> so it's not really required for the build?
<Doctor_Nick> it's not used in staging, priming, etc.?
<sergiusens> Doctor_Nick: no, we annotate it regardless, on the step it is done on, but it should not affect following steps (unless, there is always an unless, changes in the previous step, force a rerun marking the following ones dirty)
<sergiusens> Doctor_Nick: also https://snapcraft.io/blog/introducing-developer-notifications-for-snap-security-updates
<Doctor_Nick> ok
<Doctor_Nick> is there a way to set network restrictions like "only accept connections from localhost" in the snapcraft.yaml or does that have to be done elsewhere?
<Doctor_Nick> also, why do snap daemons run as root?
<Son_Goku> zyga, snapd 2.35 has been pushed for f27 too
<zyga> Good morning
<zyga> Thank you Neal
<Son_Goku> zyga, we got some nice mentions in mattdm's recent interview on Destination Linux
<Son_Goku> you should watch it ;)
<zyga> I will, thank you for the tip :-)
<mup> PR snapd#5774 closed: tests: introduce a helper for installing local snaps with --name <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5774>
<mborzecki> morning
<zyga> good morning (again)
<zyga> both kids in school
<zyga> time to work :)
<zyga> good morning mvo :)
<mvo> hey zyga
<mborzecki> zyga: mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#5775 closed: tests: also run unit/gccgo in 18.04 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5775>
<mvo> hm,hm, on arch the interfaces-timerserver-control test is failing for me:https://api.travis-ci.org/v3/job/425119844/log.txt
<mborzecki> looking
<mborzecki> mvo: does it reproduce always? maybe it's some temporary hiccup with ntp?
<mvo> mborzecki: I saw it two times lets see if it happens again
<s10gopal> can i install ubuntu core on esp8266
<s10gopal> ?
<zyga> hey s10gopal, we haven't heard about anyone attempting that yet
<zyga> s10gopal: you'd have to have a relatively modern linux kernel and supported boot loader
<zyga> s10gopal: in addition you'd have to have golang support, I don't know if esp8266 has an arm core or if it is a separate architecture
<zyga> let us know what you learn
<s10gopal> zyga, thanks
<mborzecki> s10gopal: esp8622 is a microcontroller with wifi, there are smaller OSes you can use there (or just go bare metal) but linux is a no go
<mborzecki> s10gopal: you can try pi zero or CHIP board which are slightly larger form factor, have wifi and bt and run on linux, i don't know about ubuntu core on these though, maybe needs some research
<mvo> pi zero not yet :/
<zyga> mvo: indeed
<mvo> pstolowski|afk: hey, when you are around, could you quickly check the ifstate part of #5767? it is not used currently but given that there are some PRs in flight maybe it was added to accommodate those?
<mup> PR #5767: many: remove deadcode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5767>
<pstolowski> mornings
<pstolowski> mvo: looking
<mvo> pstolowski: thanks and good morning
<pedronis> mvo: hi, I think IÂ removed the need for that funciton when IÂ refactored conflict code and made it more blunt/conservative, but I forgot to remove it
<mvo> pedronis: aha, no worries
<mvo> pedronis: just wanted to double check because of the things in flight. thanks for confirming
<pstolowski> mvo: +1, it's fine to remove it
<mvo> ta
<pstolowski> and both pedronis and me claim forgetting to remove it ;)
<mvo> heh
<mup> PR snapd#5767 closed: many: remove deadcode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5767>
<pedronis> :)
 * pedronis is going to do reviewing this morning
<zyga> brb
<zyga> more coffee
<mborzecki> coffee, brilliant idea
<mup> PR snapd#5778 opened: snap-update-ns: remove deadcode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5778>
<mvo> zyga: ^- this one is for you, not sure if this is ok or goes to far but tests will tell (or maybe you need it for something else later?)
<zyga> looking, thank you!
<zyga> mvo: we need all of those
<zyga> they are used in the trespassing fix PR already
<zyga> (they were added as a part of -v1 review
<zyga> the comments are +1 but the removals are not needed
<zyga> mvo: https://github.com/snapcore/snapd/pull/5760
<mup> PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places <Created by zyga> <https://github.com/snapcore/snapd/pull/5760>
<mvo> zyga: aha, cool. I close it then
<zyga> thanks, I'll steal the comments though :)
<mvo> zyga: yeah, iirc they are a commit that can even be cherry picked
<zyga> yeah
<zyga> 91e746fc0d61c8e89b9c4931f3eee39bef6e9ef3
<zyga> doing that now :)
<mvo> zyga: thank you
<zyga> thank You :)
<mup> PR snapd#5778 closed: snap-update-ns: remove deadcode <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5778>
<zyga> mvo: is there any dead code in interfaces?
<mvo> zyga: chopTree
<zyga> aha
<mvo> zyga: thats the only bit
<zyga> that _may_ become unused
<zyga> it's part of another fix
<zyga> but I may end up not needing it
<zyga> thanks!
<mvo> zyga: ok, I will leave it alone
<zyga> I'll remove it if that is the case
<mvo> zyga: deadcode is not super reliable, it does not deal well with import "C" for example so I don't think we can automate it yet
<mvo> zyga: sounds good, thank you
<zyga> mvo: https://github.com/snapcore/snapd/pull/5779
<mup> PR #5779: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5779>
<mup> PR snapd#5779 opened: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5779>
<zyga> oh, mup is back :)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5780
<mup> PR #5780: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780>
<pedronis> mborzecki: I spotted one issue with locks in #5758,  I suppose because you went back and forth about where/how much to lock, anyway probably worth going again over the lock changes there
<mup> PR snapd#5780 opened: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780>
<mup> PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5758>
<pedronis> mborzecki: might also show we miss a test
<mborzecki> pedronis: ack, will do, thanks for the review
<mup> PR snapd#5781 opened: overlord: add chg.Err() in testUpdateWithAutoconnectRetry <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5781>
<mvo> ^- super trivial but would be great to get in so that I can figure out why the ppa builds are failing right now (3/6 arches failed with this error) :/
<zyga> sure
<mvo> ta
<zyga> mvo: just merge it
<mvo> yeah, I think I will
<mborzecki> pedronis: yeah, that lock, damn, don't know how i missed that :/
<pedronis> mborzecki: it's easy to see in the diff, don't think is easy to see if you did changes and then more changes,  to be honest when doing lock changes and changing one mind I would sort of recommend to start from a fresh master
<pedronis> mborzecki: I also suspect that error path is not tested
<pedronis> I mean even before
<mborzecki> pedronis: right, it should panic there now that the lock is missing
<popey> Well that's odd. popeycore is a suspended laptop. Wonder how he got here.
<popey> huh, looks like my core laptop woke up when the battery was 0%, I guess to do the hybrid suspend, but that failed
<Chipaca> popey: hybrid suspend shouldn't do that
<ogra> well, its core
<ogra> we dont really have much experience with suspending on that setup
<Chipaca> popey: hybrid suspend is: prepare for hibernation, and just before power off, instead of power off, suspend
<popey> i thought hybrid suspend did exactly that. woke from suspend to go to hibernate?
<popey> huh
<popey> ah okay
<zyga> Chipaca: that's not accurate
<Chipaca> i know
<zyga> Chipaca: nowadays firmware assists
<Chipaca> handwavy a bit
<zyga> Chipaca: firmware does the suspend to ssd by itself
<popey> this is not a new laptop
<zyga> if it's correctly configured (right partitions etc
<Chipaca> zyga: do we support that already? i thought that was ms-only magic
<zyga> yes
<zyga> for many many years now
<Chipaca> ah ok
<Chipaca> zyga: i'll have to look this up :-)
<zyga> Chipaca: it just requires sandy bridge+ (ish, I forgot which exactly)
<Chipaca> not today though
<zyga> Chipaca: bios has to support this and it has to be enabled
<Chipaca> why would you have a sandy bridge
<zyga> Chipaca: you need to have an ssd and a correct partition layout
<Chipaca> it's a safety hazard
<Chipaca> sand makes things slippy
<zyga> Chipaca: then after configured time the firmware wakes suspend-to-ram machine and suspends ram to ssd
<zyga> and shuts off
<zyga> it's _not_ booting the os
<zyga> it's documented ...
<zyga> but I cannot find the doc now :)
<zyga> anyway
<zyga> just wanted to say there are more parts that move now
<popey> indeed, anyway, it's not doing that :)
<Chipaca> i'll have to look into it; the process i've seen when i used hybrid was the one i described (a bit more complex)
<zyga> popey: boot windows and update bios
<zyga> popey: or use fwupd
<popey> hahahah
<popey> it's an x61s
<popey> from the past
<zyga> x61s, well
<zyga> then it's not that :D
<zyga> Chipaca: I have a desktop that supports that at home, it's pretty neat
<zyga> Chipaca: essentially cuts the power drain while suspended
<Chipaca> zyga: the power drain while suspended is already pretty low
<zyga> Chipaca: well, it's zero then :)
<zyga> and it fixes any magic hardware that doesn't really suspend correctly
<popey> well mine drained to 0 in a few days
<zyga> see :)
<Chipaca> right
<zyga> this is how modern laptops get month+ on suspend
<zyga> embedded IC probably still operates / LEDs blink
<zyga> but not sure really
<pedronis> Chipaca: hi, thanks for the extra tests, some Qs in #5187
<mup> PR #5187: overlord: introduce snapshotstate <Created by chipaca> <https://github.com/snapcore/snapd/pull/5187>
<Chipaca> pedronis: the var is leftover debug :-( as is the status in the notice :-((
<Chipaca> pedronis: I'll answer over there
<Chipaca> mvo: did I accidentally trick you into supporting TinyHTTPProxy
<mvo> Chipaca: *cough* the code felt very crufty so I modernized it a wee bit
<mvo> maybe not crufty but just a bit old iirc, this is from 2006 originally or something
<Chipaca> mvo: :-) that code has heritage :-D
<Chipaca> yeah
<mvo> Chipaca: so yeah, if you see further low hanging fruits, just shout
<Chipaca> mvo: https://github.com/tkmunzwa/Tiny-HTTP-Proxy/blob/master/TinyHTTPProxy.py fwiw
<Chipaca> mvo: that seems to be the most modern direct-line evolution of the one I had lying around
<Chipaca> mvo: the other way this has evolved involves 'pip install', which loses its magic
<mvo> Chipaca: thanks, I will see if there are useful bits
<Chipaca> the whole point of it, to me, was that it was a single file i could scp places and work around silly firewall rules :-)
<mvo> Chipaca: heh
<Chipaca> TinyHTTPProxy + ssh port redirection == magic
<mvo> Chipaca: that should still be possible with the version in the tree
<mvo> Chipaca: the last bit I'm considering is the selectors module that zyga  mentioned but I will try to control my ocd to cleanup further I think its already overdone. anyway, back to this failing test during package build
<mvo> the irony - my latest PR fails in the proxy test which screams - merge the proxy fix :)
<mup> PR snapd#5781 closed: overlord: add chg.Err() in testUpdateWithAutoconnectRetry <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5781>
<cjwatson> Saviq,ogra: fix for the npm proxy thing is awaiting deployment (#8 in the IS queue)
<mup> PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy <Created by chipaca> <Merged by elopio> <https://github.com/snapcore/snapd/pull/8>
<cjwatson> weird how suddenly a bunch of different people asked me about that on the same day :)
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/5780 - it's a part of the bigger one you read, needs 2nd ack
<mup> PR #5780: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780>
<mup> PR snapd#5779 closed: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5779>
<mup> PR snapd#5780 closed: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5780>
<mup> PR snapd#5782 opened: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782>
<Son_Goku> wtf
<Son_Goku> why did PR8 trigger a notification?
<ogra> cjwatson, heh ... i blame Saviq though :)
<pedronis> Chipaca: btw, there other question is basically do we leave around tar files etc when we undo? the test doesn't seem to check
<Chipaca> pedronis: I've added the check, and was about to reply "yes", but I think something is missing
<Saviq> cjwatson: ack, thanks!
<Chipaca> pedronis: I might need to add a save cleanup
<Chipaca> pedronis: to catch it
<pedronis> Chipaca: possibly yes, and remove stuff if Error
<Chipaca> pedronis: wondering how to set things up so that one tar fails long after the other tars succeeded
<Chipaca> for the test of that
<pedronis> Chipaca: remember we have mock command ?
<Chipaca> i might do it with a shallower test, ie one that mocks backend
<Chipaca> pedronis: yeah, that'd be the other approach, integration-y
<pedronis> anyway as you prefer
<zyga> Chipaca: is there something like filepath.Ext but for the non-extension part?
<Chipaca> zyga: no; if ext := filepath.Ext(path); ext != path { path = strings.TrimSuffix(path, ext) }
<Chipaca> zyga: or, grab filepath.Ext and reverse what it returns
<Chipaca> or dont
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> zyga: (ext'll always be != path unless path is "" fwiw)
<zyga> thanks, I was hoping there's something baked
<zyga> I like the TrimSuffix idea
<mvo> mborzecki: I am reading 5770 right now, curious about the attack scenario. will the store do anything with the hashed instance name or is that just stored there?
<mborzecki> mvo: afaict it's for metrics only
<mvo> mborzecki: we probably also want to hash if we generate error reports thinking about it
<mvo> mborzecki: ok
<Chipaca> pedronis: I was wrong :-) we don't need a cleanup; undo does everything we need already
<Chipaca> pedronis: it's as if i'd thought of this at some point, even :-) just not tested it
<Chipaca> having to relearn my own code here
<Chipaca> that's how long it's been
<mborzecki> mvo: erorr reports contain a lsit of installed snaps?
<Chipaca> pedronis: anyway now we'll have a test for it
<mwhudson> zyga: random thought, maybe we should grab an hour one evening in brussels or something and work on snapd in debian
<zyga> mwhudson: very much so
<mwhudson> i just can't seem to work up the motivation to do it on my own
<mvo> mborzecki: no but if a specific instance fails to install or refresh we might leak the name I have not checked the code just a idle thought
<mborzecki> mvo: ok, will take a look, addign to my todo list
<mvo> ta
<pedronis> Chipaca: :) thanks
<mvo> pstolowski: does https://paste.ubuntu.com/p/Jjc3JFDWnT/ ring any bells? it seems to be a race and we hit it ~50% of the time when bulding the edge snap currently
<mvo> pstolowski: e.g. https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+sourcepub/9385143/+listing-archive-extra
<pstolowski> mvo: looking
<mvo> thanks
<pstolowski> mvo: no, i haven't seen it before; looks like a race indeed, investigating
<seb128> hey there
<seb128> how do I tell snapd to not do any auto refrsh today?
<seb128> $ snap refresh --time
<mvo> seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z"
<mvo> seb128: then snap refresh --time should tell you that the refresh is on hold
<mborzecki> pedronis: pushed fixes, added a test where UndoSetupSnap fails, also that All() was indeed useless, the variant with Get("snaps"..) is same line count and lighter :)
<pedronis> mborzecki: I added some comments to the other ones
<pedronis> mvo: do you have anything in your pile that needs my review ?
<seb128> bah, mobile connection timeouted
<seb128> unsure if my question when through before
<pedronis> seb128: yes
<seb128> how can I disable autorefresh for the day?
<mborzecki> pedronis: thanks,
<pedronis> <mvo> seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z"
<pedronis>  seb128: then snap refresh --time should tell you that the refresh is on hold
<mup> PR snapd#5783 opened: tests: add new core16-base test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5783>
<seb128> mvo, pedronis, thanks!
<pedronis> we should grow a command but we have to discuss how to add it (we have too many commands already)
<seb128> (not very user friendly to figure out,  "$ snap refresh --help" could at least hint that (or best, include a "--skip-next" or something)
<pedronis> mvo: ^ something to (re)discuss in brussel  (how to tame our commands zoo to be able to add some more) ?
<mvo> pedronis: yeah, the parser is also very strict about the time format, having something like "snap refresh --defer 1d" would be much nicer
<seb128> that would be great
<mvo> pedronis: yeah, that sounds like a good discussion
<seb128> also n-m integration to respect the limited-bandwith flag and not refresh then would be nice
<seb128> (gnome-software/flatpak do that)
<seb128> mvo, your command confuses me, now
<seb128> $ snap refresh --time
<seb128> hold: tomorrow at 19:00 CEST
<seb128> next: today at 15:23 CEST
<seb128> it still says next is today at 15:23?
<pedronis> yes
 * seb128 is scared about his data
<mvo> seb128: limit or metered? I mean does it not do any refreshes ?
<mvo> seb128: or slows them down?
<pedronis> seb128: there is still a next but hold overrides
<seb128> metered
<seb128> it just doesn't download updates
<seb128> since you don't want to risk eating the user data plan in his back
<seb128> (well they have a switch to enable auto download in that case, but it's off by default)
<mvo> seb128: fwiw, we have a option to respect metered, "sudo snap set core refresh.metered=true"
<seb128> that integrates to n-m?
<mvo> mborzecki: maybe we should enabled metered by default? (cc seb128 )
<seb128> that sounds like a reasonable default to me
<mvo> seb128: +1
<seb128> should I open a forum post about that maybe?
<mborzecki> mvo: probably needs a +1 from niemeyer too
<dot-tobias> I'm trying to stage the directory my-part/install/include â added it to stage as `include/*` but it does not show up in stage/. other directories from stage keyword do show up. Does someone has a hint what I'm doing wrong?
<pedronis> yes, we had a long back and forth when we added it
<popey> +1 to simplifying that. The syntax is arcane and user hostile
<seb128> I'm also going to open a bug about snap refresh --time telling me that the next refresh is on a time where it's not
<mvo> seb128, pedronis hm, hm, it sounds like we should we smarter about "next: " when we also have "hold:" to not confuse users
<mvo> seb128: could you write a forum topic? I prepare a pr then
<pedronis> mvo: IÂ don't know
<pedronis> probably superficially somewhere
<seb128> mvo, is the forum or github the right place for such reports?
<pedronis> not deeply
<pedronis> code is complicated enough as it is
<mvo> pedronis: :/ ok
<mvo> seb128: forum works best, otherwise LP
<seb128> mvo, k, good
<niemeyer> What's the use case?
<niemeyer> Do we have someone that reported issues while using metered connections?
<niemeyer> (hello, btw :)
<pedronis> mvo: also remember is partly by design,  if you snap set   refresh.hold=   before that next you would still get the refresh
<mvo> niemeyer: yes
<pedronis> mvo: if you change your mind
<pedronis> is really not meant to move next
<mvo> niemeyer: seb128 was surprised that the default for honoring metered connections is "off"
<pedronis> mvo: maybe is just a better  of outputting something clearer in snap refresh --time
<mvo> pedronis: yeah, maybe its enough to be smart at the presentation layer, i.e. snap refresh --time could look at the values maybe
<seb128> niemeyer, I'm just train travelling and on mobile plan/tethering and I don't want snapd to eat my 1G monthly cap
<niemeyer> mvo: Sure, but do we have someone with actual issues reporting?
<mvo> pedronis: heh, sounds like we have the same idea
<mvo> seb128: please paste me the link to your bug about next/hold and I will have a look
<seb128> mvo, niemeyer, I'm going to start a discussion in the forum about that I guess, I think the safe default on metered connection is not eat datas since it's likely that those have a cost or a limit
<niemeyer> seb128: That's reasonable of course.. how well is the automatic detection of that scenario working nowadays?
<Son_Goku> niemeyer, we don't have any yet, iirc?
<seb128> mvo, will do, I'm going to need to jump off that train and connect to another one in like 3 min but I do once I'm settled down in the next one :)
<Son_Goku> or did that stuff get merged?
<Son_Goku> (I forgot, it's hard to keep track of all the stuff!)
<niemeyer> Son_Goku: Heya
<Son_Goku> yo
<niemeyer> Son_Goku: Not on our end.. we just honor the network manager setting
<Son_Goku> so then at least from our side, we should be fine
<niemeyer> The question is how well is the automatic detection of the scenario seb128 described
<seb128> niemeyer, I don't know about the snapd side and where it gets its info from, but network-manager has heuristics that seem to make sense to me
<Son_Goku> I suppose that depends on whether NM can figure it out, then
<Son_Goku> if it can't, then *shrug*
<Son_Goku> in my case, it usually does
<niemeyer> seb128: The question is about network-manager itself.. we just honor it.. we don't have a setting by ourselves
<niemeyer> seb128: But to change defaults, we need to have some idea of whether it will actually fix the problem reported, and whether it might create problems for others
<ogra> Saviq, btw, it might make sense to have something added to the review-tools so packages using wayland-socket-dir get auto-rejected with a deprecation message on upload ... i wonder how hard that is to add for jdstrand
<seb128> niemeyer, ok, I'm going to get the details and write on the forum with what n-m is doing exactly, we can have a discussion there then
<niemeyer> seb128: Thanks!
<seb128> yw, thanks for being interested in the topic :)
<ogra> wll, does NM know you are tethering if you do it via wlan ? (assuming you just connect to a phone hostpot (at least thats how i do train rides))
<ogra> *well
<ogra> having some manual knob might make sense in that case
<popey> nm has a switch to flip to say that
<Son_Goku> NM has a lot of switches, knobs, and probes for determining whether it should say it's on a metered connection
<Son_Goku> but last resort, you can *tell* NM it's a metered connection
<popey> right, i meant in the case of a non-automagically determined connection, the user can override by flipping a switch
<ogra> ah, i didnt know that (havent seen that in 16.04)
<Son_Goku> it doesn't exist in 16.04, iirc
<Son_Goku> most of the functionality was introduced in NM 1.4, I think?
<ogra> thats like why then :)
<Son_Goku> iirc, NM 1.0 is in 16.04
<mborzecki> ogra: there's DHCP option that convey that you're on phone hotspot, afaik only android phones set it
<ogra> ah, cool, i didnt know that !
<Son_Goku> yeah
<Son_Goku> I think iOS sends a thing too, because Macs know when its connected to hotspots
<Son_Goku> but it's not "normal" like Android's
<mborzecki> any chance we could have snapd gnome-software integration flip the switch appropriately?
<Son_Goku> mborzecki: the integration is above g-s
<Son_Goku> it's in gnome itself
<Son_Goku> specifically, NM tells GNOME that it's metered, and everything responds to that
<Son_Goku> the g-s snap probably can't access the gnome information index like g-s normally can
<ogra> but it can use the NM interface to ask NM
<Son_Goku> yes
<ogra> (at least it should be able to)
<seb128> well g-s already uses that flag in their flatpak plugin
<mborzecki> snapd asks NM if current coonnection is metered
<seb128> but it wouldn't make sense to do something for snaps there since it's not gnome-software who download/refresh snaps
<seb128> (as it does for flatpaks)
<pedronis> Chipaca: I have a question for you, do you remember why we didn't add call to validateInfoAndFlags  in snapstate.InstallPath ?
<pedronis> *a call
<ogra> right, and if snapd actually DTRT here (talking directly to NM) it should theoretically just work the right way
<mborzecki> what we need is to tell snapd that it should hold refreshes if on metered, everything else is already there
<Son_Goku> mborzecki, I thought we already do?
<Son_Goku> at least, that's what niemeyer said
<mborzecki> Son_Goku: integration with NM and holding refreshes is there but it's off by default
<Son_Goku> ah, well that helps nobody
<niemeyer> Again, the reason why the default is off is because we need to have some idea of whether it will actually fix the problem reported, and whether it might create problems for others
<mborzecki> as pedronis wrote there was some back and forth about having it on by default
<niemeyer> And we're having it again just onw..
<niemeyer> now
<niemeyer> The reason we didn't enable is because nobody knew for sure when that flag was enabled or not
<Son_Goku> how do we turn it on to find out?
<Chipaca> everybody i've talked to that was complaining about, i asked them to confirm back whether it worked or not
<Chipaca> and, nobody has so far
<mborzecki> so we're just missing a piece that talks to gnome and knows whether the user wanted to hold updates (be it system, flatpak or other) while on metered
<Chipaca> so i've brought you 0 data points
<niemeyer> mborzecki: The only piece missing is feedback, and proper information
<niemeyer> mborzecki: It's not about whether the user wants to hold or not, but about when that flag actually goes on or not
<niemeyer> IIRC, the feature was developed to fix a need for a manufacturer that had specific hardware, and knew what was going on.. they enabled it for their device, which they had strict control over
<mborzecki> niemeyer: what i meant is that if a gnome user flips it on in gnome settings (or wherever else the setting is), we can only react if there's that integration piece that conveys their choice
<niemeyer> So the feature worked well there.. but to change that to always enabled, we need a much better idea of when connections will be marked as metered
<popey> FWIW I set the free train wifi to be metered because it's slow and I need the bandwidth for other stuff.
<popey> I also defer all updates to 4am because I am often doing podcasts in the evening, and I don't want my laptop to start chugging away updating snaps unexpectedly
<ogra> but that indeed expects that your laptop is on at that time
<popey> which it often isnt
<popey> so I have to manually snap refresh
<popey> (also, it frustrates me that snapd starts doing updates immediately on wake from suspend which makes the laptop unusable for minutes)
<ogra> it doesnt kick in after you booted it again ?
<popey> no
<ogra> all my VM core images definitely do that ... i have to plan an extra 10-15min when i plan to work with one that i havet booted in a while
<popey> hm, maybe it does and I didnt notice
<popey> today I pressed the wake button and walked away to get coffee
<ogra> ecause the VM typically kicks off a core update right after boot and then reboots
<pstolowski> mborzecki, zyga hey, since you commented some time ago on https://github.com/snapcore/snapd/pull/5632 - can you re-review?
<mup> PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<zyga> sure
<mborzecki> ok
<pstolowski> ty!
<zyga> pstolowski: done
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/5632#discussion_r215580734 is the most important issue I think
<mup> PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632>
<seb128> mvo, https://forum.snapcraft.io/t/next-refresh-info-confusing-when-on-hold/7230
<seb128> sorry, internet was flaky arriving to the station
<pstolowski> zyga: hmm the err is returned in the next line?
<zyga> DOH :)
<zyga> thanks, I missed that :)
<zyga> I removed it from the review now
<seb128> and now going for my next train ;)
<pstolowski> zyga: thanks for the other suggestions1
<mborzecki> pedronis: i'm thinking about that base64, it's possible that there will be - in the encoded data, so simple '-'.split(..) might get a little confusing
<mborzecki> pstolowski: 'foo'.split('-') ofc
<mup> PR core18#69 opened: hooks: add libpam-modules <Created by mvo5> <https://github.com/snapcore/core18/pull/69>
<mup> PR core18#69 closed: hooks: add libpam-modules <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/69>
<mup> PR snapd#5784 opened: tests: run account-control test on uc16,uc18 and with different bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5784>
<pedronis> mborzecki: I really hope we don't split those keys anywhere
<pedronis> mborzecki: why the 39 -> 15 change ?
<pedronis> Chipaca: did you see my question?
<Chipaca> pedronis: no
<Chipaca> pedronis: oh
<mborzecki> pedronis: should be enough bytes, i can pass the whole lot
<Chipaca> pedronis: maybe because 'try' would fail validation in that case?
<pedronis> Chipaca: what's special about try?
<Chipaca> pedronis: used during dev when things are more likely to be broken
<Chipaca> pedronis: otoh, seems like the best time to error :-)
<pedronis> Chipaca: ?
<pedronis> Chipaca: this is about checks for --classic and --devmode , or am IÂ confused ?
<Chipaca> pedronis: ah sorry i got confused with the static path checker thing
<Chipaca> pedronis: let me look
<pedronis> mborzecki: I would keep all the bits
<mborzecki> pedronis: ack
<pedronis> for 512 it was indeed a bit overkill
<seb128> niemeyer, mvo, mborzecki, in fact https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 already has lengthy details about what n-m is doing (also the review pointed in the recent comment picks on snapd compared to gnome-software/flatpak due to that :/)
<pedronis> but this already half of that
<Chipaca> seb128: but our problem isn't afaik what n-m is doing, but that we can't enable it by default until sufficient people have confirmed it does the right thing
<pedronis> Chipaca: to be clear we are talking  validateInfoAndFlags  that you introduced a long while ago
<popey> Chipaca: do we have a test case documented and call for testing?
<Chipaca> pedronis: I'm going to chalk it down to oversight
<Chipaca> popey: I don't think we do (I'd like confirmation that this is indeed what's stopping us from making it a default though)
<pedronis> Chipaca: there are 3 places that could share a helper if InstallPath was also using it
<pedronis> but maybe something breaks
<Chipaca> pedronis: which are those?
<popey> Chipaca: if we had test case and docs I'd be happy to test it
<pedronis> Chipaca: doUpdate Install and InstallPath itself
<pedronis> they all do a couple of validate, construct (a now complicated) SnapSetup
<pedronis> and call doInstall
<Chipaca> pedronis: is there anything else calling doInstall?
<pedronis> yes
<pedronis> Revert IÂ think
<Chipaca> eh, ok
<Chipaca> mborzecki: niemeyer: mvo: am I right in thinking we're just waiting for sufficient confirmation that the n-m metered integration work does the right thing in the field, in order to enable it by default?
<pedronis> Chipaca: maybe I should just try to add it and run push the PR and see what the test says and go from there
<pedronis> if you don't recall a strong reason why is not there
<Chipaca> pedronis: +1
<Saviq> sergiusens: hey, have you seen snapcraft getting ENOPERM on host's snapcraft .snap before? https://travis-ci.org/CanonicalLtd/multipass/jobs/425154797
<Saviq> when building in a build env, that is
<sergiusens> Saviq: cleanbuild?
<Saviq> sergiusens: travis, so yeah
<Saviq> oh I mean, no, not cleanbuild
<Saviq> =lxd
<sergiusens> Saviq: yes, same, snapd changed perms on all snaps, you can use beta where we moved to a different model
<Saviq> ack
<sergiusens> Saviq: why lxd and not cleanbuild?
<ogra> does cleanbuuild work in travis ?
<sergiusens> ogra: of course it does
<ogra> (i never tried :) )
<sergiusens> ogra: https://github.com/snapcore/snapcraft/blob/master/.travis.yml#L70
<Saviq> sergiusens: I don't go through the whole build necessarily, depends on the job https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml
<ogra> oh, wow, travis even supports snaps ?
<sergiusens> ogra: yeah, we did a PR for their docs ages ago
<ogra> it definitely didnt when  used it last and still had to manually create xenial chroots
<ogra> (my experience is from a tme where they only offered precise)
<sergiusens> ogra: https://docs.travis-ci.com/user/installing-dependencies/#installing-snap-packages
<ogra> extremely cool !
<sergiusens> yeah, and they only offer xenial to enterprise users :-)
<Saviq> but with lxd, who cares! ;P
<ogra> ah, i thought they switched the default nowadays
<sergiusens> so the fact that it is slow to get to the masses might be a commercial thing more than a technical one :-)
<ogra> yeah
<Saviq> sergiusens: oh and btw, I'm abusing the fact that the build artifacts (stage, basically) ends up in $PWD and that the container is still around after it completes
<Saviq> I suppose I won't be able to rely on it soon ;P
<Saviq> sergiusens: if you have a look through our .travis.yml and suggest changes / highlight issues, that'd be great :)
<sergiusens> Saviq: abuse all you want, but you will have to make up for your crimes :-)
<ogra> why stage though ? prime feels a bit more natural
<sergiusens> Saviq: we can certainly do that, btw
<seb128> Chipaca, sorry, on a flaky internet in a train ...  what info do you need to figure out if the current code "does the right thing"? the post explains the heuristics used by n-m in details which is a good base I would think?
<ogra> seb128, you need to stay on the train for the next 48h to see if some auto-update kicks in i guess *g*
<Chipaca> seb128: well, in theory it works; in practice, we don't know
<ogra> (geez, is it friday soon ?)
<Saviq> ogra: I think prime is stripped of some test-related things that we need, but we may reevaluate for sure - and maybe amend what we prime for different build types
<Chipaca> seb128: no amount of reading about what n-m claims to do will tell us whether it breaks in some weird real-world corner case
<ogra> Saviq, yeah, prime is closest to the actual endresult though ... makes any tests more realistic i suppose (but yeah, stripped for sure)
<seb128> Chipaca, it's being used by others (GNOME, flatpak), could that help us to get some confidence?
<seb128> Chipaca, and if not what would?
<seb128> trying to understand how we can unblock the situation
<mup> PR snapcraft#2244 opened: snap: add the https transport <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2244>
<seb128> Chipaca, sorry, try is making that difficult, I was saying
<seb128> Chipaca, well "break" would mean no autorefresh on some connections, if we are afraid that buggy info could lead to system never updating we could force a refresh anyway after $peiod
<seb128>  Chipaca, users are typically on a metered connection for a limited time, being on the safe side by default and forcing after a longer period would probably save most users to hist a problem	
<seb128> Chipaca, anyway let me know if we could help giving confidence in that feature by any mean
<Chipaca> mvo: so do we need to do anything beyond tweaking the config? Is there a public test phase needed still?
<mvo> Chipaca: a good question
<pstolowski> mvo: shall i push to a new github branch and we can set up a ppa from that?
<mvo> pstolowski: yeah, that sounds reasonable
<mvo> pstolowski: (in a meeting right now (and after this one too) so may be a bit slow replying but you can just use a personal PPA probably)
<Chipaca> pedronis: snapshotstate is green again if you want to take a last look
<pstolowski> mvo: right, will try that (haven't touched ppas for >2 years, let's see how it goes ;))
<mvo> pstolowski: good luck
<pedronis> Chipaca: lgtm
<Chipaca> whee
<Chipaca> gasp
<Chipaca> now what
<mup> PR snapd#5187 closed: overlord: introduce snapshotstate <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5187>
<pedronis> Chipaca: celebration time :)
<Chipaca> pedronis: :-)
<mvo> Chipaca: \o/
<mup> PR snapd#5785 opened: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5785>
<pedronis> mvo: core16 is a base right ?
<pedronis> like core18
<pedronis> nvm checked myself
<mvo> pedronis: correct
<mvo> pedronis: (sorry in a meeting so a bit slow)
<Chipaca> pedronis: snap info tells you :-)
<pedronis> Chipaca: that's what I did indeed
<Chipaca> pedronis: :-)
<Chipaca> pedronis: in state.State's Prune(), writing() is called only if needed. deleteExpiredWarnings was calling writing() unconditionally, when it was a public method. Should I make it smarter?
<Chipaca> pedronis: should I drop it and move that logic into Prune directly?
<Chipaca> the latter would be consistent with what's there already
<pedronis> Chipaca: I'm kind of eoding,  yea, all the pruning is in Prune,
<Chipaca> pedronis: ok
<Chipaca> pedronis: have a good'un
 * cachio lunch
<Saviq> sergiusens: so here's a new issue with beta... https://travis-ci.org/CanonicalLtd/multipass/jobs/425225732 snapcraft can't find a package... https://launchpad.net/ubuntu/+source/cmake-extras is it looking at the host package list?
<sergiusens> Saviq: sent a log privately, I have a workaround for that though
<mup> PR snapcraft#2245 opened: docker: support for testing snapcraft in proposed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2245>
<Chipaca> niemeyer: #5514 is ready for another look if you're idle (har har har)
<mup> PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514>
<mvo> zyga: quick brainstorm - I'm renaming idleManager to ecoManager - or do you have a better name. I think it captures the idea behind it better than idle manager as its not about idle but more about nothing to manage
<zyga> mmm
<zyga> do you think that ecoManager could do more things (eventually) that fit into resource preservation concept?
<zyga> like unmounting unused things
<mvo> or cleaning unused bases
<zyga> or running aggressive gc once in a while
<zyga> or something like
<zyga> janitorManager
<zyga> (though I think ecoManager is better)
<zyga> or we could call it "mother"
<niemeyer> Chipaca: Thanks!
<niemeyer> mvo: Do we need a manager for that?
<mvo> sleeper
<mvo> niemeyer: not strictly but it has some nice properties
<niemeyer> mvo: It sounds like this is a cross-concern issue
<mvo> niemeyer: like that it ties use into the ensure loop
<niemeyer> mvo: Where every manager would have something to say about it
<mvo> niemeyer: we want the check to run after the ensure loop of the other managers
<mvo> niemeyer: but I'm open for ideas of course
<zyga> niemeyer: ohhh
<zyga> nice idea
<niemeyer> mvo: It just feels like this is something managers will need a chance to do something about, otherwise we'll have a manager that will be fiddling with resources of other managers
<zyga> manager.SaveThePlanet
<zyga> and then a manager could do something in response to that
<Chipaca> return false
<mvo> niemeyer: so far the bits we check are: a) number of snaps (snapstate should provide this) b) is it seeded (devicestate) c) minimal amount of time passed d) pending changes e) active daemon connections. plus it should be run after ensure ideally
<mup> PR snapcraft#2245 closed: docker: support for testing snapcraft in proposed <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2245>
<niemeyer> mvo: Sounds like something we should run less often than ensure itself
<mvo> niemeyer: I can sketch out a design that adds something like "CanGoSocketActivated" to the managers (the name sucks, just here as a stawman) and then do the other checks in its own package and/or daemon or overlord. syncing with the ensure loop is the open question in this design. should I create a hook in the overlord for this? where callbacks can be added
<niemeyer> Hmmm
<mvo> niemeyer: right, we can run it less often its just a nice property if its in sync with ensure in some way (so maybe not every ensure )
<mvo> (but of course it does not have to be in sync if that makes the other design nicer)
<Chipaca> I wonder if we can do it by niling out managers when they have nothing to do
<Chipaca> and then if every manager has gone, we go away entirely
<niemeyer> mvo: The earlier a-d list sounds a bit uneven
<Chipaca> anyway. I'm going afk for a while, will bbl (going for a run before it rains)
<niemeyer> mvo: Some of those aren't something that can be in a manager
<niemeyer> Chipaca: Enjoy!
<mvo> niemeyer: the active connections is a problem, the other bits fit ok. but again, happy to do it differently
<niemeyer> mvo: The time passed also feels misplaced
<mvo> niemeyer: I need to have dinner now but will read scrollback and also ponder about how to do it without a manager
<niemeyer> mvo: Time passed since what?  Feels like this should be in the routine that would attempt to go socket activated
<niemeyer> mvo: SOunds good.. we can catch up tomorrow morning as well
<niemeyer> mvo: Have a good one
<mvo> niemeyer: the time since startup is what is used right now
<mvo> niemeyer: yeah, tomorrow is also fine, lets see if we can find some nice pattern :)
<mvo>  s/pattern/place/
<mvo> niemeyer: thank you!
<seb128> back on stable internet!
<seb128> Chipaca, sorry for trying to start a conversation on a bumpy internet, that was not a good idea
<seb128> Chipaca, anyway might be a good topic for Brussel, if we can help building trust on that feature/stack in some way that would be nice
<seb128> users tend to hate bugs that lead to costs (understandably)
<ackk> hi, is there a way to unset a snap config option (as opposed to set it to "")?
<zyga> set it to null
<ackk> zyga, how do you do that?
<ackk> zyga, you mean set foo=null ?
<zyga> snap set foo value=null
<zyga> I think
<zyga> yes
<ackk> oh, so that's a special value
<ackk> I mean, it's not treated as string
<zyga> no, that's literally null :)
<zyga> yeah, all input is yaml
<zyga> I heard
<zyga> or json
<zyga> or ...
<zyga> now I'm confused
<ackk> zyga, although it will still show in get -d, it won't be "unset"
<ackk> (that's fine, just wondering if there was a way to actually unset
<zyga> ah
<zyga> mmm
<zyga> maybe there is
<zyga> hold on
<zyga> I don't see any
<zyga> pstolowski: ^ maybe you can clarify
<cachio> pedronis, hey, I am trying to push a snap to the staging store and I see this error
<cachio> https://paste.ubuntu.com/p/9dyxZZgkvY/
<cachio> do I need to make any change in the test account?
<pedronis> cachio: are you logged in ? what does snapcraft list-registered says ?
<cachio> pedronis, it gives the list of snaps for the user
<pedronis> then not sure
<pedronis> it's a strange error
<cachio> pedronis, who could help with that error?
<cachio> on the store side
<pedronis> cachio: I would try to login again, is that snap in the list of list-registered you get?
<cachio> pedronis, ok
<cachio> pedronis, yes it is
<pedronis> it's definitely strange,  if relogin doesn't help, ping celso maybe
<cachio> same errror after relogin
<cachio> I'll ping him
<pedronis> snapcraft --debug output might help in case
<pstolowski> zyga: there's no way to unset
<pstolowski> ackk ^
<pstolowski> that's a known issue/limitation
<cachio> pedronis, is it using the staging store? https://paste.ubuntu.com/p/rFyBk3NTG5/
<pedronis> cachio: no
<pedronis> something is off with your env
<pedronis> 'url': 'https://dashboard.snapcraft.io/dev/api/snap-push/
<pedronis> or there's  a bug in snapcraft, not respecting something for different ops
<pedronis> a *new* bug
<cachio> pedronis, that could be
<cachio> thanks for the support
<pedronis> as I said list-registered showing the snap but push failing is a bit strange
<cachio> pedronis, I'll check with snapcraft guys
<pedronis> (though the permission are different for the two ops)
<cachio> kyrofa, hey
<cachio> kyrofa, any idea why it could be not poiting to the staging store?
<cachio> https://paste.ubuntu.com/p/rFyBk3NTG5/
<kyrofa> cachio, sudo might have something to do with it-- have you tried without?
<niemeyer> Chipaca: LGTM!
<cachio> kyrofa, that was the problem
<cachio> kyrofa, tx
<pedronis> cachio:  ah, sorry IÂ didn't notice that
<cachio> pedronis, yes, me neither :(
<ackk> pstolowski|afk, I see, thanks
<Chipaca> niemeyer: excellent, thank you
<TorbenLeif> Hello, I am trying to figure out how to make snappy stop updating my VLC installation to any other versions.
<TorbenLeif> I've read the man file but I don't see a way to stop snap from refreshing a certain app :/
<Chipaca> TorbenLeif: you can't, basically
<Chipaca> TorbenLeif: and you probably shouldn't :-) why are you wanting to not update vlc?
<TorbenLeif> @Chipaca VLC Media Player, versions past 3.0.1 broke a certain feature I use regularly and so I keep having to force snappy to reinstall vlc_195.snap.
<TorbenLeif> Unfortunately VLC doesn't release any other packages so I can avoid using Snappy with it, so it sounds like I'm stuck having to do this every day :/
<mup> PR snapcraft#2246 opened: packaging: cleanup extension usage in setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2246>
<Chipaca> TorbenLeif: have you spoken to the devs? they're usually very receptive of that sort of feedback
<Chipaca> my memory is terrible but I think thresh was working on that at some point?
<ogra> yep, he is the vlc snap maintainer
<ogra> Chipaca, i thought if you use snap revert you will not get auto-upgraded til the next release shows up in the store ?
<ogra> i onder why TorbenLeif has to do that "every day" ... given that feature
<ogra> *wonder even
<mup> PR snapcraft#2244 closed: snap: add the https transport <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2244>
<Chipaca> ogra: I suspect the have the .snap, and install it every day
<Chipaca> TorbenLeif: what does "snap list --all vlc" print?
<ogra> yeah ... revert would be a lot better than sideloading the snap file
<Chipaca> TorbenLeif: as ogra says, if you "snap revert", snapd will not auto-upgrade you to the same revision -- a new revision would get auto-installed, but not the same one every time
<Chipaca> ogra: revert is probably the least known of what we think of as the main features
<Chipaca> ogra: it's not really sideloading as they have the assertion :-)
<ogra> yeah ... but given its beauty it should really get more promotion ;)
<ogra> ah
<Chipaca> ogra: ironically if they didn't have the assertion it'd be actual sideloading (i.e. --dangerous) and it wouldn't update
<ogra> oh, indeed !
<mup> PR snapd#5786 opened: tests: update prepare/restore for nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5786>
<TorbenLeif> @Chipaca vlc   3.0.3-1-3-gf09fd0d  365  stable    videolanâ  disabled
<TorbenLeif> vlc   3.0.4               555  stable    videolanâ  disabled
<TorbenLeif> vlc   3.0.1-4-g14a4897    190  stable    videolanâ  -
<Chipaca> TorbenLeif: and which is the one you want to use?
<TorbenLeif> 190 is the one I want to use permanently.
<TorbenLeif> I have it installed now, but tomorrow it'll update again.
<Chipaca> TorbenLeif: ok, so try this
<Chipaca> TorbenLeif: first: snap refresh vlc
<Chipaca> TorbenLeif: that'll leave you with the one you don't want
<Chipaca> TorbenLeif: next: snap revert vlc --revision=190
<Chipaca> TorbenLeif: that'll leave you with the one you do want, and _blacklist the newer one_
<Chipaca> TorbenLeif: you can confirm this by doing 'snap refresh' (without explicitly asking for vlc)
<Chipaca> if you 'snap refresh vlc' you un-blacklist, if I remember correctly (but i could be wrong! and i'm too tired to go look right now)
<TorbenLeif> This works, but once VLC releases a new version I just have to do this?
<TorbenLeif> Or is it a perma solution?
<Chipaca> TorbenLeif: the next different revision that gets pushed to tip of stable will replace the one you want, yes
<Chipaca> TorbenLeif: in the meantime, _talk to the vlc maintainers_
<TorbenLeif> Okay, that is great. Thank you so much for the help Chipaca!
<Chipaca> TorbenLeif: what is the feature that breaks, by the way?
<TorbenLeif> Chipaca The capture card displays a weird zoomed in disorted image post 3.0.1
<Chipaca> TorbenLeif: that seriously sounds like something they'd want to fix if they knew it was happening
<TorbenLeif> I am using an AV2USB adapter that works fine on any program as a regular video0 input except VLC post 3.0.1
<TorbenLeif> I talked to them but they have a pushy bug reporting process that I don't want to do (it involves signing up on a bug tracker and such).
<Chipaca> sounds terrible
<Chipaca> much easier to refresh the snap every day â¦ (?!?)
<TorbenLeif> It's not bad if you're really into the community, but just as a guy wanting to inform them of a problem they might be interested in knowing about, it's too much work.
<TorbenLeif> Writing a script to schedule the necessary commands to revert isn't hard now that I know the commands ^^
<Chipaca> I now regret having helped
<TorbenLeif> Because I don't want to take pictures, learn the necessary debugging commands to create the bug report and sign up for a service to do it?
<TorbenLeif> I gave them the logs they wanted in irc.
<TorbenLeif> Bah, idc. Thank you for the help anyway.
<Chipaca> TorbenLeif: because you'd rather spend my time than yours
<TorbenLeif> Not necessarily true.
<TorbenLeif> If I made the bug report it isn't fixed, it is reported.
<mup> PR snapd#5787 opened: tests: update the listing expression to support core from other channels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5787>
<TorbenLeif> Seeings as I am not a programmer for the project, either way I still need a temporary fix.
<TorbenLeif> The VLC channel didn't have a solution to temporarily fix the problem, so after a couple hours I decided reverting constantly is the best solution for me.
<TorbenLeif> I was unsure on how to do that, so I needed help with reverting snap packages. You helped teach me that.
<TorbenLeif> Even to that effect, I googled for a solution well prior to coming here and read the man page. Unfortunately documentation on snappy is lacking in this regard, and the feature I wanted didn't even exist. So no, I would have much rather found the solution during the time I spent than take up yours.
<Chipaca> TorbenLeif: I'm sorry the manpage didn't help. Reading the documentation for revert I see it's missing a mention of the blacklisting, indeed
<Chipaca> sorry for that; i'll address it tomorrow
<TorbenLeif> No need to apologize for documentation, it's a community project, not a business. Anywho, thanks again and have a good day.
<mup> PR snapcraft#2247 opened: yaml loading: properly handle unhashable types <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2247>
<mup> PR snapd#5788 opened: tests: add publisher regex to fix the snap-info test pass on sru <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5788>
#snappy 2018-09-07
<mup> PR snapcraft#2225 closed: build providers: environment setup for projects <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2225>
<mup> PR snapcraft#2247 closed: yaml loading: properly handle unhashable types <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2247>
<Doctor_Nick> what is "black"?
<Doctor_Nick> run_tests.sh requires it but I don't know what package it's located in
<Doctor_Nick> ah hah, it's in the snap store, of course
<Doctor_Nick> "The linker version '2.23' used by the base 'core' is incompatible with files in this snap:"
<Doctor_Nick> that's an issue i haven't seen before
<Doctor_Nick> any idea what this means?
<Doctor_Nick> ah, I was using the release candidate snapcraft
<Doctor_Nick> "warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in â/tmp/tmpyf6y6pvuâ"
<Doctor_Nick> now THATS quality!
<Doctor_Nick> uhm
<Doctor_Nick> does the AppVeyor CI run the self test for snapcraft?
<Doctor_Nick> is `./runtests.sh static` on snapcraft broken for anyone else? mypy throws a bunch of type errors
<mup> PR snapcraft#2248 opened: plugin: update catkin plugin to support melodic <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2248>
<Doctor_Nick> there we go
<mborzecki> morning
<mborzecki> hm got a failure in unit tests with gccgo: https://paste.ubuntu.com/p/prG9CTRNJm/
<mborzecki> it's in snapshotSuite.TestRestoreIntegration
<zyga> Hey hey
<mborzecki> zyga: hoho
<mborzecki> zyga: how's the first week of school?
<zyga> I think successful
<zyga> Janek likes his new school
<zyga> And committing is ok, he is doing it by himself now
<mborzecki> that's great :)
<zyga> And for you?
<mborzecki> zyga: so far so good, kids have already gotten into the daily routine
<zyga> ok, installed in my office now :)
<mup> PR snapd#5776 closed: tests: port proxy test to use python tinyproxy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5776>
<mup> PR snapd#5784 closed: tests: run account-control test with different bases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5784>
<pstolowski> morning
<zyga> hey pawel
<zyga> reading your hot plug PRs now :)
<zyga> I'll be right back, I could use another coffee
<mborzecki> anyone upgraded to g 1.11 already?
<zyga> mborzecki: not in tumbleweed
<mvo> I did not yet, its in cosmic but not in bionic
<zyga> anything new and interesting?
<mborzecki> damn, gocode stopped working, stracing it i found it's poking some silly locations under pkg/linux-amd64 (note - not _)
<zyga> mborzecki: actually, I should just upgrade go on macOS
 * zyga does just that
<zyga> we have spam on the forum
<zyga> who has editorial rights to kill that?
<diddledan> morning.
<diddledan> not I.
<diddledan> :-p
<mborzecki> zyga: i know Chipaca, maybe mvo as well?
<mvo> mborzecki: maybe - whats the link to the spam zyga ?
<zyga> sent in private
<mvo> zyga: thanks, removed post and user
<mvo> pstolowski: just curious but did you find any leads on the test failure?
<pstolowski> mvo: i only got succesful build in the ppa this morning a while ago, pushing some more debug. i had a long fight with debian toolchain yesterday ;}
<pstolowski> (succesful = failing on unit tests as expected)
<mup> PR snapd#5789 opened: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789>
<mvo> pstolowski: aha, great, so you can reproduce it and get useful debug out of it? great. is it worth it for me to push a tiny branch that skips the test for now so that we get edge builds back or is the fix close enough to not bother?
<mvo> pstolowski: (again, no pressure just trying to estimate what the best next step is)
<mvo> Chipaca: good morning
<pstolowski> mvo: no fix in sight, issue not yet understood, so yeah, feel free to disable the test if it's blocking
<Chipaca> mvo: it is! good morning to you too sir
<pstolowski> zyga: missied your earlier message, thanks for looking at my hotplug PRs!
<zyga> the name code is intricate
<mvo> pstolowski: thank you
<mup> PR snapd#5790 opened: overlord: skip testUpdateWithAutoconnectRetry temporarily <Created by mvo5> <https://github.com/snapcore/snapd/pull/5790>
<zyga> pstolowski: 5782 reviewed
<pstolowski> zyga: ty!
<Doctor_Nick> is there any documentation on "allow-auto-connection" for plugs?
<Chipaca> Doctor_Nick: yep
<Chipaca> Doctor_Nick: 1 sec
<Chipaca> Doctor_Nick: https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455
<mvo> Chipaca: btw, does http://paste.ubuntu.com/p/yZjys58FKc/ ring any bells?
<mvo> Chipaca: happend in a recent spread run, iirc in one of mborzecki PRs
<Chipaca> nice :-/
<mborzecki> mvo: ha, pasted it in the morning :) but nobody was around
<Doctor_Nick> Chipaca: thanks
<Chipaca> mvo: mborzecki: it does not ring a bell
<mborzecki> Chipaca: mvo: https://paste.ubuntu.com/p/prG9CTRNJm/
<Chipaca> mvo: mborzecki: but something is obviously wrong
<Chipaca> mborzecki: what mahcine?
<Chipaca> machine*
<mborzecki> Chipaca: this was with gccgo, ubuntu something, sorry don't have more details
<Doctor_Nick> Chipaca: wait, sorry, I meant the syntax for it
<Chipaca> Doctor_Nick: what do you mean, the syntax?
<pedronis> Doctor_Nick: do you have a brand store?
<Doctor_Nick> the syntax for the snapcraft.yaml file
<Doctor_Nick> not yet
<pedronis> it doesn't go in snapcraft.yaml
<Doctor_Nick> theese are private snaps so far
<pedronis> it is put in  the snap declaration assertion through the store
<Chipaca> what goes in the yaml is the connection
<Chipaca> not the auto-connection of the connection :-)
<pedronis> on that front  brand store owners have control,  we are also working to make it so that knowning the syntax is not needed
<pedronis> but is not something that can be done for one own's snaps in the main store
<pedronis> private or not
<dot-tobias> Is it possible to declare common environment variables for apps in snapcraft.yaml? https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276 only lists apps.<app-name>.environment, which I interpret as âcurrently notâ
<zyga> dot-tobias: I think so, just try it
<zyga> I mean, snap.yaml certainly allows that
<dot-tobias> zyga: When I add apps.environment to snapcraft.yaml, snapcraft complains with âIssues while validating snapcraft.yaml: The 'apps/environment' property does not match the required schema: 'command' is a required propertyâ â âenvironmentâ is interpreted as an app name here?
<zyga> dot-tobias: move environment to top-level
<mborzecki> everyone seen this on reddit yday? https://www.reddit.com/r/linux/comments/9dfag7/the_correct_frontrunner_in_the
<popey> Yes :)
<mvo> seb128: iirc you added some info about metered and network manager into the forum. I misplaced the link, could you sent it to me again please?
<seb128> mvo, I didn't because I found https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 that has all the technical detail and I though there was not much point creating a new post
<Chipaca> popey: seb128: I was meaning to update you both on this, but then seb128's train got in the way and then I forgot: yesterday at the standup we talked about enabling the feature by default, and we agreed to move forward on it -- with some level of testing to be done asap
<Chipaca> I believe that's what mvo is on right now in fact :-)
<Chipaca> but dunno :-D
<seb128> ah, great
<seb128> let us know if we can help in desktop
<Chipaca> you can always help in desktop
<popey> Chipaca: great, lemme know if I can test stuff
<seb128> (also would be good to have something to respond to review saying that flatpak cares about their users bandwith where we don't)
<dot-tobias> zyga: Right, makes sense. And works. Thank you! ð
<Chipaca> seb128: where's that review?
<seb128> Chipaca, see the most recent post on that forum topic I just pasted
<mvo> Chipaca: yeah, was just looking into this (cc seb128 )
<seb128> mvo, you rock :)
<Chipaca> seb128: "snapd supports disabling updates on metered connections; the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled" would work?
<Chipaca> seb128: and a link to the forum post perhaps
<Chipaca> seb128: is that wyat you meant as a response?
<Chipaca> seb128: "snapd supports disabling updates on metered connections, on all supported distros that have a new enough netowkr manager (on Ubuntu that means 16.04 on); the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled"
<Chipaca> seb128: if you want to include more detail :-)
<mup> PR snapd#5791 opened: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791>
<Chipaca> seb128: typo and a missing "but"
<pedronis> Chipaca: I created https://github.com/snapcore/snapd/pull/5791  to see how it goes,  at least overlord tests doesn't seem to fail with it
<mup> PR #5791: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791>
<Chipaca> seb128: or, I can answer that myself if you'd rather keep clear of omg
<seb128> Chipaca, if you want to reply that would be nice, thanks :)
<Chipaca> seb128: OTOH, nothing in the usually acrid comments seems to mention metered at all
<Chipaca> oh wait there ar emore comments
<Chipaca> pedronis: yep, will look in a mo
<seb128> right, I'm just concerned that's one of those topics where one day someone is going to be pissed off because snapd refreshed in background and created them a bill of 100â¬ on roaming and then it becomes a topic of the day for ranting against snapd and getting used to say that flatpak at least does things right blablabla
<Chipaca> eh, i'll add a comment
<mborzecki> what about a use case where there's a device which is always connected over [234]G?
<Chipaca> mborzecki: then we'll refresh at the slowest pace we can
<Chipaca> mborzecki: right?
<Chipaca> mborzecki: dude you wrote this :-)
<mborzecki> Chipaca: heh, doesn't mean i remember all the details :P
<Chipaca> seb128: comment added, but I had the temerity to include a link so it's waiting for moderation
<Chipaca> mborzecki: point :-)
<mborzecki> Chipaca: i'll refresh after 60 days anyway
<Chipaca> mborzecki: in the most dire real-world use case i know of the person could get onto wired once a month or so
<mborzecki> quesion whether that's frequent enough
<Chipaca> so I'm happy with it
<Chipaca> mborzecki: that's what we decided was the longest tolerable refresh
<mvo> seb128: if you create forum topic I can reference it in my commit changelog :)
<mborzecki> Chipaca: right, so that's 100â¬ bill every 2 months :)
<Chipaca> mborzecki: i'm trying to decide if you're trolling or not
<mborzecki> haha
<mvo> Chipaca: if you or someone else followup in the forum please let me know, wouldbe nice to include the latest discussion in the commit as a pointer to the right forum entry
<mborzecki> reminds me of a time in my previous jobs where we'd screw up stuff in redboot and they actually had to take cars, and visit some of the  power line poles or trees the base stations were mounted on :)
<Chipaca> mvo: I replied to the omgubuntu thread, as i said
<Chipaca> mvo: and pointed them to https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
<mvo> Chipaca: thanks, I missed that it was on omgubuntu
<Doctor_Nick> a snap inside of a flatpak inside of a docker container inside of a lxc container
<popey> Doctor_Nick: Don't forget appimage!!!!
<Doctor_Nick> of course
<zyga> Doctor_Nick: running on windows in a VM in a browser on a mac
<pstolowski> we need a spread test for that
<Chipaca> zyga: on an x86 emulator running on chrome on a phone
<mborzecki> guys, let me know if you need more input about metered support than that's already in the forum
<Chipaca> mborzecki: I think popey and seb128 need a clearcut this-is-how-you-test-it and this-is-what-to-test-that-we-are-not-sure-about
<popey> plus one
<Chipaca> mborzecki: especially useful if we enable it by default in edge (or beta or w/e) and then have a mini call for testing there
<mborzecki> ack, i'll finish up with the store thing i'm on right now and will add some notes to the forum thread
<mvo> Chipaca, mborzecki https://github.com/snapcore/snapd/compare/master...mvo5:refresh-metered-tweaks?expand=1 is the code change. but I am a bit lost about the process (sorry for that). should it get proposed now or shall we wait until we got testing results from users first?
<seb128> mvo, you mean for the "turn it on by default", isn't what that topic is about? I'm happy to create another one if you would prefer though
<Chipaca> I think we do need a separate topic if we're going to have a call for testing -- pointing people to a thread with 18 unrelated comments is not good for a call to action
<seb128> k
<Chipaca> mvo: same here. I guess if nobody knows a _concrete_ case where it fails, enabling it in preparation for a call for testing is good
<Chipaca> mvo: especially as we tweaked the ux a bit
<mborzecki> mvo: process questions aside, the code lgtm
 * mvo nods
<mvo> thanks, I proposed it now, lets see how that goes :)
<mup> PR snapd#5792 opened: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792>
<Chipaca> pedronis: about the wip pr, +1 fwiw (but also: tests?)
<Chipaca> pedronis: but i do get that the pr is just to see what breaks :-)
<pedronis> Chipaca: yes, exactly
<pedronis> if everything passes I'll see what needs testing
<Chipaca> mborzecki: second time through gccgo in the three places we run it without repro'ing the bug
<Chipaca> mborzecki: if you see it again, i need to know how
<Chipaca> mborzecki: it makes no sense to me :-(
<Chipaca> like two things were mkdir'ing $HOME/snaps/, or sth
<Chipaca> s/three/four/ fwiw :-)
<zyga> mborzecki: let's land 5793
<zyga> mborzecki: I'm preparing another iteration of the trespassing patch-set without the noise
<mup> PR snapd#5793 opened: cmd/snap-update-ns: separate OpenPath from the Secure struct <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5793>
<Doctor_Nick> what's the default shell in snaps?
<zyga> Doctor_Nick: what do you mean specifically?
<Doctor_Nick> my shell script in this snap package isn't working and I think it's because it's not using bash
<ogra> Doctor_Nick, /bin/sh is dash normally ...
<Doctor_Nick> ah hah
<zyga> Doctor_Nick: just use bash explicitly
<Doctor_Nick> yup
<ogra> if you want to use bash then explicitly use /bin/bash in the shebang
<Doctor_Nick> yeah
<ogra> (but live with the overhead :P )
<ogra> (typically there is no reason to not adapt your code to be POSIX compliant ...)
<ogra> https://wiki.ubuntu.com/DashAsBinSh has hints
<Doctor_Nick> yeah, it was an easy fix to use the alternative setup script
<pedronis> mmh, almost back to 50 PRs
<niemeyer> More than 20 of those are still from the review board
<niemeyer> 19 have open reviews
<niemeyer> (moin!)
<niemeyer> dot-tobias: To be clear, there's no default
<niemeyer> It's whatever was used in the bangline, as usual
<dot-tobias> niemeyer: I think you meant to ping Doctor_Nick ? ;-)
<niemeyer> dot-tobias: Sorry :)
<dot-tobias> niemeyer: no problemo :-) (&& moin)
<mvo> 5606 needs a second review then it can go in
<mvo> and 5763 a first review, hopefully simple as its just shuffling tests around
<zyga> mvo: doing
<Chipaca> niemeyer: snap run --shell runs bash, that's the most defaultish thing we have :-)
<Chipaca> imo we could add --shell=<what>
<niemeyer> Chipaca: That seems a bit cumbersome, even more because the _what_ may not be available inside the snap
<Chipaca> niemeyer: I mean, keep --shell, but add the ability for the user to say what shell they want
<Chipaca> go-flags supports this fwiw
<niemeyer> Chipaca: The issue asked was about a shell script as well, so wouldn't help here either way
<Chipaca> i know
<niemeyer> Chipaca: Right, I got that
<niemeyer> Chipaca: It won't help if they want zsh, though, or csh, or ...
<niemeyer> Chipaca: The snap does not offer it
<Chipaca> niemeyer: if you're using a base that offers /bin/sh but not /bin/bash, it won't work for ex
<niemeyer> Chipaca: We should just fallback to /bin/sh in those case
<niemeyer> s
<Chipaca> niemeyer: or, e.g., snap install busybox-static, and try to snap run --shell busybox-static
<Chipaca> niemeyer: in this one, /bin/sh is provided by the snap itself (it uses the bare base, which has nothing)
<Chipaca> still, this is all academic
<Chipaca> i need to go
 * Chipaca goes
<niemeyer> Chipaca: o/
<Doctor_Nick> yessss
<Doctor_Nick> our entire backend is snapped now
<ogra> yay, congrats !
<ogra> (whatever backend that is :) )
<Doctor_Nick> now I just have to charm it
<ogra> do a feather dance :)
<ogra> https://www.youtube.com/watch?v=dxk1BSQo8bg&feature=youtu.be&t=20
<Doctor_Nick> oh lord
<ogra> heh
<zyga> mvo: done
<mvo> zyga: ta
<niemeyer> mvo: Do we have a snapd.failure.service file?
<mvo> niemeyer: we do
<niemeyer> mvo: Huh.. that's a curious service :)
<mvo> niemeyer: yes
<mvo> niemeyer: when adding a "OnFailure=" bit in systemd this needs to be a service AFAIK
<mvo> niemeyer: this is why we have this one. do you think the name is not good or do you think the fact that we have it at all is problematic?
<niemeyer> mvo: I think it's fine given the context.. I just wasn't aware that we had it
 * mvo nods
<niemeyer> mvo: Do we run snap-repair on desktops or only on core?
<mvo> niemeyer: only on core
<niemeyer> mvo: Wonder why people are getting the message that those units are disabled
<niemeyer> It doesn't look like a bug..
<niemeyer> But people seem to think so
<niemeyer> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1776622
<mup> Bug #1776622: snapd on cosmic never finishes installing/updating. Can't install any other updates. <amd64> <apport-bug> <cosmic> <regression> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776622>
<mvo> niemeyer: yeah, I quickly scanned our postinst and its just using the systemd debhelper stuff, would be nice to get the output of "ps afx" when this hangs
<mvo> niemeyer: just to see what processes are hanging around and blocking dpkg
<niemeyer> mvo: One person there mentioned the context
<zyga> mvo: the 2nd PR is pretty long :)
<zyga> pushing on
<niemeyer> moon127: Comment #15
<mup> PR #15: do not panic if a priv.Mutex is taken/released/taken again <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/15>
<niemeyer> mup: Good try
<mup> niemeyer: I really wish I understood what you're trying to do.
<niemeyer> mup: It's okay.. you're often helpful
<mup> niemeyer: Unknown commands are unknown.
<pedronis> niemeyer: hi, #5683 needs a re-review by you
<mup> PR #5683: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683>
<zyga> thx
<zyga> mvo: almost done
<zyga> mvo: reading the new parts now
<zyga> mvo: done
<zyga> brb, coffee
<pstolowski> mvo: i've a suspiction about the cause of managers test failures, might have a fix, testing
<niemeyer> pedronis: Thanks, looking
<mborzecki> pedronis: thanks for all the reviews
<mborzecki> pedronis: i'll be landing https://github.com/snapcore/snapd/pull/5761 when it's green
<mup> PR #5761: store: use stable instance key in store refresh requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5761>
<mborzecki> (or pushing one last update if #5763 lands first)
<mup> PR #5763: store: refactor tests so that they work as store_test package  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5763>
<Doctor_Nick> is there an easy way to set network restrictions on snaps, like "only accept connections from localhost"?
<mborzecki> Chipaca: https://api.travis-ci.org/v3/job/425643055/log.txt
<niemeyer> pstolowski: #5683 is good to go
<mup> PR #5683: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683>
<mborzecki> Chipaca: this one too https://api.travis-ci.org/v3/job/425601674/log.txt it's gccgo always
<pedronis> Chipaca: I reviewed the warning one,  some small comments/wonderings
<pstolowski> niemeyer: great, ty! re-starting travis tests
<mvo> niemeyer: I contemplated your suggestions about having the managers giving input into the "go-socket-activated" mode. I did a sketch of this now in https://github.com/snapcore/snapd/compare/master...mvo5:stop-on-no-snaps-standby-helper?expand=1 - all names are strawman for now, sugestions welcome. the idea is to have a "standbyHelper" that asks around for opinions if snapd can go to sleep. it gets input from snapmanager ab
<mvo> out num snaps, devicestate about seeded, overlord about if ensure was run at least once and the daemon about the connections (check daemon.go and standby.go for the interessting bits). is this what you had in mind?
<mvo> (tests missing but I will re-add them if this looks promising)
<mvo> zyga: thank you!
<zyga> re
<zyga> Doctor_Nick: no, there's no support for that at this time
<niemeyer> mvo: Yeah, something around those lines indeed, thanks for making it real. I'll read through the code after lunch and we can quickly sync in the standup.
<Doctor_Nick> dag
<mup> PR snapd#5606 closed: many: add refresh.rate-limit core option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5606>
<Doctor_Nick> how about setting a user for a snap daemon?
<zyga> Doctor_Nick: this is on the roadmap but it is not implemented yet
<Doctor_Nick> ok
<zyga> it's designed and described extensively on the forum
<juliank> Oh, can I build against core18 now?
<pedronis> mvo: are you going to finalize #5324 soon? or should it be closed for now
<mup> PR #5324: snap: run snap-confine from the re-exec location <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5324>
<zyga> juliank: indeed you can
<juliank> I'd like to get apt snaps going
<juliank> :)
<mvo> pedronis: 5324?
<mvo> juliank: yes you can :)
<pedronis> mvo: sorry, #5234
<juliank> I have two things I want to snap: apt and flatpak. The latter mostly for lolz
<mup> PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<pedronis> even older ;)
<Doctor_Nick> zyga: is there a way to set a user as part of the snap group and just restrict what they're able to connect?
<zyga> Doctor_Nick: what do you mean by "snap group"?
<zyga> Doctor_Nick: and how is that related to connections? sorry,  I don't understand your question
<mvo> pedronis: :( yeah, its a mess of conflicts, I had not mustered the energy yet but I will make a extra strong cup of tea after lunch and give it a go again
<Doctor_Nick> wait, sorry
<Doctor_Nick> i had imagined that there was a snap group that gave users permissions to install snaps
<zyga> no, that's managed with policy kit
<zyga> and with root vs non-root
<Doctor_Nick> right
<Doctor_Nick> basically I just want to run these things as non-privileged users and only give them access to the network interface
<mborzecki> heh, i'm trying to chec this refresh on metered thing, but i can't get nm to connecto to my phone :/
<mvo> zyga: thanks, the store test PR just had lots of conflicts because the rate limit was landed - oh well :)
<mvo> zyga: but now I just need to wait for tests, thanks a lot ofr the review
<zyga> mvo: doing more
<mup> Bug #1755568 changed: Snaps are refreshed on metered connection <Snappy:Fix Released> <https://launchpad.net/bugs/1755568>
<Wimpress> Trevinho: Are you still a collaborator on the telegram-desktop snap?
<Wimpress> If so, can you change the homepage to reference telegram desktop and not your personal website please?
<Wimpress> https://snapcraft.io/telegram-desktop
<mvo> zyga: cool
<zyga> does this ring a bell?
<zyga> FAIL: snapstate_test.go:10904: snapmgrTestSuite.TestInstallDefaultProviderRunThrough
<zyga>     c.Check(len(s.fakeBackend.ops), Equals, len(expected))
<zyga> ... obtained int = 27
<zyga> ... expected int = 28
<zyga> mvo: https://github.com/snapcore/snapd/pull/5771#issuecomment-419408625
<mup> PR #5771: selftest: add test to ensure selftest.checks is up-to-date  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5771>
<mvo> zyga: ta
<zyga> Chipaca: hey, wanna see a snapshot unit test error?
<mvo> zyga: aha, yes. silly me. the problem is of course that on 14.04 the kernel selftest fails
<mvo> zyga: so this test cannot yet be enabled
<zyga> mvo: hmmm,
<zyga> mvo: but the test will not fail on 14.04 after a reboot
<pstolowski> mvo: ok, i think i've a fix, PR coming
<mvo> zyga: correct
<zyga> chipaca:  https://www.irccloud.com/pastebin/CTSwvmVM/
<mvo> zyga: its also a bit of a usability issue having the package fail to install is ugly
<mvo> zyga: I would love to enable this check once we have something like the degraded or read-only mode
<zyga> mvo: yeah, I agree
<zyga> I didn't think about the install failure aspect
<mvo> zyga: thanks for the review in any case, I will address the bits you mentioned
<zyga> is master broken now or was that just temporary in some tests?
<mvo> zyga: not sure, last master run on travis was ok
<mvo> zyga: looking
<zyga> no, you're busy
<zyga> I"ll check
<mvo> zyga: it looks like the snapstate test is failing
<mvo> http://paste.ubuntu.com/p/yZjys58FKc/
<zyga> mvo: I saw that in PR reviews, running locally
<zyga> hmm, I don't see that failure
<zyga> but I see this:
<zyga> https://www.irccloud.com/pastebin/GcPNCB8T/
<mvo> zyga: I saw this one on the running master in travis
<mvo> zyga: hu, this error is strange. in what PR do you see this?
<zyga> on master on my machine
<mvo> zyga: interessting. unfortunately I need lunch now, lets talk after that
<zyga> that's so strange
<zyga> I'm looking
<Chipaca> zyga: what machine was that (snapshotstate) error on?
<zyga> on travis
<mup> PR snapd#5794 opened: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <https://github.com/snapcore/snapd/pull/5794>
<Chipaca> zyga: travis doesn't run the unit tests, spread does
<zyga> ah, I see your point
<zyga> one sec
<Chipaca> zyga: note the error is from mkdirallchown
<Chipaca> zyga: so something fucky indeed
<Chipaca> would be good to know what
<zyga> there's a function like that?
<zyga> we have mkdirall
<Chipaca> zyga: osutil/mkdirallchown.go
<zyga> we have dupes /o\
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/5794
<mup> PR #5794: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <https://github.com/snapcore/snapd/pull/5794>
<pstolowski> also pedronis ^
<Chipaca> zyga: mbuahah
 * Chipaca goes away for a bit, again
<zyga> https://api.travis-ci.org/v3/job/425643055/log.txt
<zyga>     - google:ubuntu-18.04-64:tests/unit/gccgo
<mborzecki> seb128: Chipaca: mvo: added testing steps, along wit some screenshots https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/19
<mborzecki> off to pick up the kids
<popey> thanks mborzecki
<thresh> so how stable is core18?
<zyga> thresh: is should be stable
<thresh> thanks zyga, going to try it out
<Chipaca> mborzecki: popey: is Â«nmcli c show ... |grep connection.meteredÂ» easier than Â«nmcli --fields connection.metered c show ...Â»?
<popey> The gimp snap uses it, and it's got a fair number of users thresh
<thresh> me included!
<popey> Chipaca: that doesn't work here
<popey> Error: invalid field 'connection.metered'; allowed fields: NAME,UUID,TYPE,TIMESTAMP,TIMESTAMP-REAL,AUTOCONNECT,AUTOCONNECT-PRIORITY,READONLY,DBUS-PATH,ACTIVE,DEVICE,STATE,ACTIVE-PATH,SLAVE.
<Chipaca> popey: wat
<pedronis> Chipaca: we got the answer about that validate
<Chipaca> pedronis: i'll look in a bit
<Chipaca> pedronis: fixable?
<pedronis> need to think a bit
<pedronis> the current behavior is not great either for some cases
<Chipaca> ok
<pedronis> Chipaca: IÂ think what we might want is to not do the check if the install is really with --dangerous, but not in general if it's a file install
<pedronis> or some variation thereof
<thresh> what steps do I need to take to build against core18?  specify base: core18;  adjust stage-packages, anything else?
<zyga> thresh: that's about it
<zyga> base is the requirement, anything else is adjusting to the new environment
<thresh> got the following error after the (seemingly successful_ build: https://gist.github.com/thresheek/1c514b1b5d7981a97684f4bf4d3ee083
<thresh> cant run mksquashfs? :o
<popey> sergiusens: ^
<sergiusens> thresh: docker and snapcore/snapcraft:latest? mind switching to snapcore/snapcraft:stable or maybe this interests you https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43-1/7236
<thresh> sergiusens, docker indeed, but with a ubuntu:bionic image and snapcraft from the bionic repo.  going to try the latest snapcraft.
<sergiusens> thresh: the snapcraft in bionic proposed should fix that
<thresh> adding that atm
<zyga> no idea why it fails (my build id test)
<zyga> hmmm
<zyga> file is broken on my machine
<mborzecki> re
<zyga> strace file / https://www.irccloud.com/pastebin/lNRN08cB/
<zyga> that ... is weird!
<mborzecki> if i hone my gimp skills a bit maybe i could highlight that checkbox with a circle :)
<zyga> mborzecki: ? :)
<mborzecki> zyga: https://i.imgur.com/TDA3TwF.png
<zyga> mborzecki: just use a phone ;)
<zyga> mborzecki: can you run strace file /
<zyga> mborzecki: and paste the result please
<mup> PR snapd#5763 closed: store: refactor tests so that they work as store_test package  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5763>
<mborzecki> zyga: https://paste.fedoraproject.org/paste/jXaCOyxgcx~n56ZRGxODpQ/raw
<zyga> thanks
<zyga> hmmm
<zyga> holly crap
<zyga> so I had MAGIC set
<zyga> because I was doing experiments with mvo on the systemd bug
<zyga> and this apparently upsets file
<zyga> because MAGIC is where you can store the database of magic numbers
<zyga> man
<zyga> any
<zyga> variable
 * zyga undoes systemd hacks
<mvo> pstolowski|lunch: thank you
<mvo> mborzecki: thanks for adding the testing steps/screenshots
<mvo> zyga: heh
<mvo> zyga: fun (or not)
<zyga> mvo: fun, just man :)
<thresh> sergiusens, upgrading to 2.43.1 fixed it - thanks!
<mup> PR snapd#5795 opened: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795>
<Chipaca> zyga: where is the other mkdirallchown?
<zyga> Chipaca: cmd/snap-update-ns/MkDirall
<zyga> unless they differ in what they do
<Chipaca> zyga: does that count as duplicated? I thought we had a bunch of stuff in snap-update-ns which was there for Reasons
<Chipaca> with deduping happening if and when
<zyga> I think Reasons no longer apply actually, we move things to osutil and we call it from cnf
<zyga> but even if
<zyga> are they the same code?
<zyga> mborzecki: anther easy one
<zyga> https://github.com/snapcore/snapd/pull/5795
<mup> PR #5795: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795>
<mborzecki> overlord/snapstate/snapstate_test.go:457: C.Fatalf format %q has arg tasks of wrong type []*github.com/snapcore/snapd/overlord/state.Task
<mborzecki> this is new
<zyga> hmm
<zyga> and %q cannot do that?
<zyga> that's new indeed
<zyga> 1.11/
<zyga> ?
<mborzecki> zyga: yes
<mborzecki> hm Task does not appear to be Stringer
<zyga> nea
<zyga> neat
<zyga> so it's really broken
<Chipaca> zyga: mborzecki: standup?
<pedronis> bit strange
<zyga> joining
<mborzecki> Chipaca: i'm there :)
<Chipaca> mborzecki: i'm ignoring you
<mborzecki> haha :P
<mup> PR snapd#5783 closed: tests: add new core16-base test <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5783>
<mborzecki> Chipaca: https://api.travis-ci.org/v3/job/425651400/log.txt
<Chipaca> mborzecki: again?
<Chipaca> mborzecki: oh, interesting
<mborzecki> Chipaca: i'm trying to reproduce it with spread on 18.04 now :/
<mup> PR snapd#5746 closed: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746>
<mup> PR snapd#5790 closed: overlord: skip testUpdateWithAutoconnectRetry temporarily <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5790>
<zyga> a simple loop of mount/unmount done via systemd doesn't trigger it
<mborzecki> zyga: try snap install ... && snap remove ... like we did earlier
<zyga> bug.sh https://www.irccloud.com/pastebin/pdHILpBk/
<zyga> mborzecki: can you copy two snaps as "foo.snap" and "bar.snap" and run that ^
<zyga> yeah, trying now
<cachio> mvo, hey, did you see what I wrote?
<cachio> I got disonnected
<mvo> cachio: I did not
<cachio> mvo, any idea what to do with this? https://paste.ubuntu.com/p/jsnPzWZqhW/ it is failing on bionic
<mvo> cachio: yeah, it looks like "aws-cli" is not available in the catalog update
<mvo> cachio: does "journalctl -u snapd" show anything that the "catalog" could not be downloaded or something like this?
<mvo> cachio: or aws-cli is no longer available (which would be odd)
<mborzecki> zyga: maybe it involves udev too
<pstolowski> hmm, just got FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough
<zyga> mborzecki: mmm, interesting!
<cachio> mvo, the logs show that the catalog was refreshed
<cachio> and aws-cli snap can be installed
<cachio> but it is a classic snap
<pstolowski> zyga: is "FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough" an error you were looking at earlier today?
<mborzecki> zyga: exact line i used back then is `while true; do sudo snap install hello-world_foo hello-world_bar hello-world_baz && sudo snap remove hello-world_foo hello-world_bar hello-world_baz || break; done`
<mborzecki> oh, and it worked until i rebooted the machine :)
<zyga> thanks
<zyga> hmm ? are you saying it is not working anymore (not reproducing the problem)
<mborzecki> zyga: btw. i was also stracing systemd at that time, but it didn't happen when under strace
<zyga> bummer
<mborzecki> so besides generating a reasonable amount of logs nothing interesting happenend
<mborzecki> zyga: maybe lttng could be useful, but haven't tried that yet
<zyga> I haven't used it either
<zyga> I think we need a solid reproducer
<mborzecki> zyga: so that while loop is all that i have :)
<Chipaca> mborzecki: I'm getting a bunch of Undone instead of Error failures (which I need to address), but haven't yet hit the other one
<Chipaca> when i say 'a bunch', i mean in 100 runs of the suite i'll get one
<zyga> error on undo https://www.irccloud.com/pastebin/Xbwy557Y/
<mborzecki> Chipaca: in the prereq in flight or sth test?
<zyga> https://www.irccloud.com/pastebin/HQ9Rid1C/
<Chipaca> mborzecki: TestRestoreIntegrationFails
<Chipaca> it makes sense as it's racy
<mborzecki> Chipaca: ok, that's different then
<zyga> Chipaca, pstolowski: ^
<Chipaca> zyga: ?
<Chipaca> zyga: that doesn't seem to have anything to do with snapshotstate
<zyga> Chipaca: ctrl-c on install/remove
<Chipaca> zyga: where's the error?
<zyga> error: change finished in status "Undone" with no error message
<Chipaca> zyga: ah, ok
<Chipaca> zyga: that's a bug in cmd/snap/wait.go, probably?
<Chipaca> zyga: what does http snapd:///v2/changes/333 show you?
<zyga> https://www.irccloud.com/pastebin/nx4BNVIb/
<Chipaca> zyga: er, i meant 380
<Chipaca> not sure where i got 333 from :-)
<zyga> 380 https://www.irccloud.com/pastebin/91IpOAUy/
<Chipaca> zyga: so, either snapd should add something to the change, or snap should not expect it to be there :-)
<pstolowski> zyga: sorry, what's the context; are there multiple issues being disccussed?
<Chipaca> pstolowski: yes
<Chipaca> pstolowski: 3 at least
<Chipaca> pstolowski: was very confusing at first
<Saviq> hey, I got `snap install` hanging for 12m now on copying 512bytes of data... https://pastebin.ubuntu.com/p/WBHPhJHcpT/ anything more of interest I could collect?
 * cachio afk
<mborzecki> Chipaca: reproduced snapshotSuite.TestRestoreIntegration with spread
<mborzecki> Chipaca: running the test in isolation fails too https://paste.ubuntu.com/p/cNt2qt4NWb/ though differntly
<Chipaca> gawsh
<Chipaca> mborzecki: thanks
<Chipaca> mborzecki: is this every time?
<mborzecki> Chipaca: yes
<pstolowski> Saviq: this copying involves more directories afair, not just those you listed
<Chipaca> mborzecki: how
<mborzecki> Chipaca: no clue yet, looking into it
<Chipaca> mborzecki: the runuser thing points to an every time thing, but how did they pass for me if so?
<Chipaca> how do they continue to pass here
<Chipaca> mborzecki: I've just got a repro of the mkdirallchown error (the one with the long changeerror that mentions snap.mkdir-new)
<Chipaca> ah
<mborzecki> Chipaca: idk, it passes locally on my host, but not in gce, i have debug shell open atm
<Chipaca> mborzecki: you're running them as root in gce
<mborzecki> Chipaca: heh, yes, i should use test user?
<Chipaca> mborzecki: well.. they shouldn't fail, but they are :-)
<zyga> mborzecki: updated 5795
<Chipaca> mborzecki: runuser isn't used unless you're root
<Chipaca> at some point apparently it broke
<Chipaca> need to look
<Chipaca> probably got the args mangled somehow
<mborzecki> Chipaca: looks like it's passing tar argumens directly to runuser
<Saviq> pstolowski: it completed after 25mins... I doubt I have enough free space to take that long (and there was not much IO going on)
<Saviq> ~/snap/subsurface is 55MB
<mborzecki> Chipaca: if username == "root" || sys.Geteuid() != 0 {
<mborzecki> sys.Geteuid() == 0 ?
<pstolowski> Saviq: I see.. anything in /root/snap/subsurface?
<Saviq> sergiusens: how do I check locally if https://forum.snapcraft.io/t/builds-failing-automated-review/7112 is fixed with the latest snapcraft? where do I find manifest.yaml?
<Chipaca> mborzecki: if you're not root, or you are root but are running things for root, don't runuser
<Saviq> pstolowski: no, never launched there
<Chipaca> mborzecki: runuser ["-u" "a-user" "tar" "--create" "--sparse" "--gzip" "--directory" "/tmp/check-1422139595125391214/46/home/a-user/snap/too-snap/" "2" "common"]
<sergiusens> Saviq: that was fixed store side
<Chipaca> mborzecki: that's what's exec'ed
<Saviq> sergiusens: was it? the forum post only mentions downgrading snapcraft on the builders?
<sergiusens> Saviq: install review-tools and run them on the resulting snap when SNAPCRAFT_BUILD_INFO is set
<sergiusens> Saviq: hmm, jdstrand_ since you did the downgrade, mind updating the forum post on everything being up to speed now?
<mborzecki> Chipaca: what i mean is https://paste.ubuntu.com/p/fhFFMj29Sm/
<pstolowski> Saviq: anything in journal? grep for "data directory"
<Chipaca> mborzecki: no
<Chipaca> mborzecki: that logic is correct
<mborzecki> Chipaca: ok, so the comment above is incorrect
<Chipaca> mborzecki: "username" is the username of the user for who we're creating a snapshot
 * Saviq should do something with journald rotations... I've logs from February...
<Chipaca> mborzecki: the comment is saying the same thing i'm telling you :-)
 * Chipaca steps away from despair, breathes in, and tries to explain
<pstolowski> Saviq: that explains your earlier remark about not having enough space ;)
<Chipaca> mborzecki: we want to run with runuser if: 1. the code is running as uid 0, *and*, 2. the user we're going to switch to is not root
<Chipaca> mborzecki: 2. is only because, if you're root, and you use runuser to run something as root, .... what did you even
<Chipaca> mborzecki: I think the bug is that it's missing the --, which the manpage says is optional but probably isn't that optional
<mborzecki> Chipaca: ok, let me try that
<Chipaca> mborzecki: yep, that fixed it
<Chipaca> mborzecki: (different error now, but one that makes sense :-) )
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/4VXBbck4YF/
<Chipaca> er, without the printf :-)
<mup> PR snapd#5793 closed: cmd/snap-update-ns: separate OpenPath from the Secure struct <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5793>
<Chipaca> oops, bug
 * Chipaca fixes
<Saviq> pstolowski: no mention of "data directory" in the journal
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/PgCMDG6HJK/
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5796
<mup> PR #5796: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5796>
<Saviq> sergiusens: also, why are my parts always out of date these past days :/ I've to `clean -s pull` all the time :|
<mup> PR snapd#5796 opened: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5796>
<sergiusens> Saviq: talk to kyrofa about that; you are probably writing in the source tree
<sergiusens> Saviq: might be a good time to enable auto re-sync by default as this change is causing pain (I fell for it too)
<sergiusens> kyrofa: it would be good to say why something is considered dirty, this hit me too a while back when I was writing to curdir
<Saviq> http://paste.ubuntu.com/p/vkpZ7Rqkk2/
<Saviq> doesn't look like I am
<pstolowski> Saviq: hmm, ok, dunno then, that's what i grokked from the code. is this first time you saw that? reproducible?
<Saviq> pstolowski: I had it once before a while ago, unlikely to be reproducible
<Saviq> may be some network wait I'm hitting or some such
<mborzecki> Chipaca: maybe we should skip respetive tests if go test is ran by root
<mborzecki> Chipaca: and it's not reproducing
<Saviq> sergiusens: when using lxd environment, snapcraft inside the container is installed stable, that expected?
<mup> PR snapd#5794 closed: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5794>
<sergiusens> Saviq: yes, we disabled injection given the snapd permission changes
<Saviq> ack
<Chipaca> ok, so i got the reason for the bug
<Chipaca> about mkdirallchown
<Chipaca> now how to fix
<Chipaca> hmm
<Chipaca> :-)
<pstolowski> Saviq: might be a long shot / silly question - is your disk (ssd?) in a good shape?
<Saviq> pstolowski: not getting 25min iowaits if that's what you're asking ;)
<pstolowski> Saviq: okay, i take it as 'yes it is' ;)
<Chipaca> zyga: the fancypants O_TMPFILE wouldn't've caught this bug
<Chipaca> mborzecki: I'll have a pr up in a bit
<Saviq> pstolowski: not saying it's great, but that's rather it being slower than I'd have liked (it's more than 4 years old now), but I've no reason to think it's dying :)
<zyga> Chipaca: what was the bug?
<zyga> I mean, what was the actual problem
<zyga> I recall it's tmp is not tmp ;)
<Chipaca> zyga: in one task: mkdirallchown /foo/bar/baz
<Chipaca> zyga: in another task: mkdirallchown /foo/quux/meep
<Chipaca> zyga: when /foo does not exist
<Chipaca> now, race
<zyga> ahhh
<zyga> I see
<zyga> the fd based implementation is not "racy" in the same sense, it would have one of those fail
<zyga> well
<zyga> it would not even
<Chipaca> zyga: only because it doesn't rename
<zyga> because they to ahead and mkdir
<zyga> and just handle ENOENT
<zyga> so it would not be even noticed
<zyga> yeah
<zyga> we could change umask
<Chipaca> zyga: right, they make it in the final place, without worrying about it having the wrong uid/gid
<zyga> to ensure we create 000
<zyga> and then chown
<zyga> and chmod
<Chipaca> zyga: unless your implementation handles EEXIST it'll have a similar race
<pstolowski> Saviq: was thinking of bad sector reallocation that brings i/o to a halt and doesn't even produce errors; but yeah, it's probably something else
<Chipaca> zyga: anyway the quick fix is to add a lock :-) so i'm doing that to unbreak master
<zyga> +1
<zyga> Chipaca: var gil sync.Mutex
<Saviq> pstolowski: I'd see it in dmesg, and I don't
<zyga> pstolowski: small review on https://github.com/snapcore/snapd/pull/5762#pullrequestreview-153381760
<mup> PR #5762: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5762>
<Chipaca> mborzecki: unit tests running now, as soon as it's green i'll push
<Chipaca> mborzecki: (no tests added by these changes...)
<pstolowski> zyga: thanks
<pstolowski> zyga: i'll see if i can come up with a test case for that PR
<zyga> pstolowski: just copy paste one and remove the extra snap init
<pstolowski> zyga: btw, if you're in hotplug-reviewing spree, this one needs review as well https://github.com/snapcore/snapd/pull/5759
<mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<zyga> I'm reading it :D
<zyga> some feedback already pending,
<Chipaca> mborzecki: zyga: #5797
<mup> PR #5797: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797>
<zyga> Chipaca: ack, looking
<mup> PR snapd#5797 opened: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797>
<zyga> pstolowski: reviewed
<Chipaca> zyga: pushing with a slightly nicer description (code unchanged)
<pstolowski> zyga: thanks
<zyga> mborzecki: can you re-check please: https://github.com/snapcore/snapd/pull/5795
<mup> PR #5795: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795>
<zyga> Chipaca: done
<Chipaca> zyga: ta
<zyga> 7th day of the month and the modem shows 270GB of data traffic
<zyga> hmmmm
<Chipaca> mvo: why is 'systemctl start' trying to do 'systemd-tty-ask-password-agent'?
<zyga> Chipaca: sudo?
<Chipaca> zyga: https://launchpadlibrarian.net/387297120/psafxww
<zyga> hmmm, that's unexpected
<mvo> Chipaca: a good question, polkit prompt I would say
<mvo> Chipaca: but *why* it is doing that is a mystery
<mvo> Chipaca: \o/ this is the hanging dpkg?
<Chipaca> mvo: yes
<mvo> Chipaca: super mysterious - I would assume it only needs to do that for uid!=0
<mvo> Chipaca: hm, the man-page does not even mention polkit, it talks about disk encryption passowrds and the like
<mvo> Chipaca: I found https://bugs.freedesktop.org/show_bug.cgi?id=92430 about this
<zyga> I'll grab coffee
<zyga> it's late but I ... I'm addicted I guess :)
<pstolowski> zyga: heh, coffee here as well
<Chipaca> mvo: that last comment tho
<mvo> Chipaca: yeah, not exactly helpful
<mvo> Chipaca: also https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565617 which indicates we need to double check if debhelper systemd uses "--no-ask-password" when it runs systemctl
<mup> Bug #1565617: "polkitd.service is masked" warnings on package install while policykit-1 is unpacked but not yet configured <architecture-ppc64le> <bugnameltc-139608> <patch> <severity-high> <targetmilestone-inin16041> <systemd (Ubuntu):Fix Released by pitti> <https://launchpad.net/bugs/1565617>
<Chipaca> mvo: ps output says no
<mvo> Chipaca: /o\
<pstolowski> oh well, stateengine.go:101: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET
<mvo> pstolowski: I wonder if that is related to the issue that cachio  saw earlier about the apt hook test failure. does the store know about this (if its consistent?)
<mvo> Chipaca: /usr/bin/deb-systemd-invoke is what is actually called form the postinst, I wonder if we can add some env there to tell it to --no-ask-password
<pstolowski> mvo: store as 'store people'?
<mvo> pstolowski: yes, sorry
<pstolowski> mvo: no idea, not from me
<Chipaca> mvo: looks like that would be the ideal place to add the --no-ask-password to everything
<pedronis> pstolowski: is that error from today?
<mvo> Chipaca: yeah
<pedronis> pstolowski: or from the past days
<pstolowski> pedronis: yes, Sep 07 14:45:36
<pstolowski> pedronis: https://api.travis-ci.org/v3/job/424210574/log.txt
<pedronis> pstolowski: I'm asking in the store
<mvo> Chipaca: the log you pointed to earlier, from what bug was that? I wonder what else got upgraded there. I mean, what might happen is the following: polkit and snapd get upgraded. polkit daemon gets upgraded first, is stopped and unpacked. snapd is stopped and unpacked, snapd is started before polkit and for some reason systemctl wnats to talk to it even though uid==0 but no polkit (not started yet) so that hangs forever. a
<mvo>  bit of a wild theory so the /var/log/apt/history.log would be helperful
<mvo> Chipaca: or the full terminal log of the upgrade (to see if polkit was deconfigured before)
<mvo> (anyway some speculation at this point)
<pstolowski> pedronis: thanks; do you need that log or can i restart the tests?
<Chipaca> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1791087
<mup> Bug #1791087: snapd 2.35.1+18.10 hang on apt upgrade <snapd (Ubuntu):New> <https://launchpad.net/bugs/1791087>
<Chipaca> mvo: you asked them for 'ps afx', i asked them for 'ps afxww' when the interesting bit got elided :-)
<mvo> Chipaca: heh, woah, the joy of crufty tools
<mvo> Chipaca: thanks a lot for this
<pedronis> pstolowski: retry
<pstolowski> k
<pedronis> there may be some setup in the store that is ok for normal clients but is a problem for out tests
<zyga> re
<zyga> made coffee, cleaned the kitchen, bathroom and bedroom before $wife gets home :)
<pedronis> if it becomes a regular problem we need to think
<ogra> zyga, hey ... layouts .... if i had a content snap providing stuff into $SNAP/opt/foo and would re-map $SNAP/opt to /opt in an app snap, would /opt/foo be accesible for me ?
<Chipaca> mvo: https://pastebin.ubuntu.com/p/HJknjWkXb3/ maybe
<Chipaca> mvo: should I ask the guy to try this before we propose it?
<zyga> yes
<zyga> ogra: ^ yes
<zyga> brb, $wife is back
<ijohnson> ogra, zyga: note that the actual files are inside the content snap, not inside the current app snap
<Chipaca> mvo: I'll ask them :)
<pstolowski> pedronis: ack
<mvo> Chipaca: \o/
<gQuigs> hi there, I did a snap revert firefox yesterday (to get back to the previous beta) but today it bumped ahead again - how do I figure out what happened?
<Chipaca> gQuigs: snap list --all firefox
<Chipaca> gQuigs: or, snap info firefox
<Chipaca> gQuigs: has there been a new revision?
<Chipaca> gQuigs: otherwise, we can look in 'snap changes' to see what happened exactly
<gQuigs> Chipaca: how would I tell that bit?  I only have the 62.0b20-1 (what I reverted to) and 63.0b4-1 (which maybe has been upped in number)
<gQuigs> snap changes might do it
<gQuigs> 129  Done    today at 07:46 PDT  today at 07:47 PDT  Auto-refresh snap "firefox"
<gQuigs> but if there was an older 63.0b3 say how would I see that?
<Chipaca> gQuigs: have you tweaked it to only keep two revisions of snaps?
<gQuigs> Chipaca: nope, two other snaps have 3 versions on list --all
<zyga> ogra, ijohnson: if by "remap" you mean a rbind then yes
<Chipaca> gQuigs: but firefox just has two?
<Chipaca> strange
<pedronis> pstolowski: Chipaca:  for details, afaict  the store will refuse to serve /names more than once per second for the same client
<gQuigs> Chipaca: yup
<Chipaca> gQuigs: revision 127, current in beta, was put there on "2018-09-07T08:03:31.592103+00:00"
<Chipaca> gQuigs: so, yeap, new revision fresh this morning
<mup> PR snapd#5795 closed: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5795>
<gQuigs> Chipaca: thanks!  how did you tell that?
<Chipaca> gQuigs: right now, I looked at the store api
<Chipaca> gQuigs: we'll be exposing these dates in 'snap info' at some point (soon! i hope!)
<Chipaca> gQuigs: but I think it's also exposed on the web
<Chipaca> 1 sec
<Chipaca> gQuigs: https://snapcraft.io/firefox
<Chipaca> gQuigs: click 'more versions'
<ijohnson> zyga: ok, I misunderstood the line here to mean that the source had to be inside the current snap: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L760
<gQuigs> Chipaca: thanks a bunch!
<jdstrand_> popey, Wimpress: fyi, https://forum.snapcraft.io/t/approval-for-fwupd-classic-snap/5755/9. (granted)
<zyga> ijohnson: yes, you can use layouts to "spread" the content of a snap around
<zyga> you cannot use them to take contents from somewhere on the system and put it in other places
<Wimpress> jdstrand_: Thank you!
<ijohnson> zyga: so as long as the content interface from snap1 is connected somewhere inide $SNAP, $SNAP_DATA, etc. for snap2, snap2 is allowed to use layouts to make a new mount of the files from the content snap (snap1) somewhere else on the system (just for snap2)?
 * zyga parses that
<zyga> yes
<zyga> that's accurate
<zyga> _but_
<zyga> layouts are currently happening before content mounts
<zyga> so it depends on the peer sharing
<zyga> you will first to a layout from $SNAP/foo to /usr/foo
<zyga> then a content from $OTHER_SNAP/shared to $SNAP/foo
<zyga> which _iff_ propagation is not set to private (it's not) will propagate to /usr/foo
<zyga> from the point of view of $SNAP (not $OTHER SNAP)
<zyga> ijohnson: ^ does that make sense?
<ijohnson> Yeah that makes sense. Slightly related question, does content sharing use bind mounts?
<zyga> yes
<ijohnson> Got it
<zyga> both bind mounts and layouts use the same mount backend
<zyga> some other things do as well
<zyga> you can see the resulting mount profile in /var/lib/snapd/mount/...
<zyga> it's a fstab-like file
<zyga> (with extra options)
<ijohnson> Interesting, good to know, thanks!
<zyga> ijohnson: you can also look at the actual mount profile (that is applied to the mount namespace) in /run/snapd/ns/*.fstab
<zyga> ijohnson: those can differ as some mounts may fail (layout mounts cannot fail or the app process will not be allowed to start)
<zyga> ijohnson: snap-update-ns can look at both and apply changes to make the mount namespace have a desired look
<mvo> Chipaca: the 18.10 upgrade issue gets out of hand it seems, I got a personal mail asking why I broke snapd :/
<zyga> mvo: ouch!
<Chipaca> mvo: well? why did you?
<ijohnson> zyga: I see, also good to know
<mvo> Chipaca: I ask myself this question every day
 * Chipaca hugs mvo
 * zyga hugs them both
<Chipaca> mvo: it's friday. It's ok to tell peoplel to FOAD
 * zyga had to google that
<mvo> Chipaca: LOL
<mvo> Chipaca: I had to google it as well
 * mvo hugs Chipaca for learning something really useful
<abeato> sergiusens, hey, do you know if at some point in time snapcraft explicitly remove debug_info from binaries? or set CFLAGS in some way?
<Chipaca> oh no what have i done
<Chipaca> ââ ââ
<sergiusens> abeato: not in the form of env var...
<zyga> Chipaca: 5759 is green
<abeato> sergiusens, the thing is that since 2/3 months I saw this difference: previously there was no debug info (-g option), but now it is there. Using the autotools plugin. It looks like -g is usually the default configuration, so my guess is that snapcraft/plugin was doing something that prevented -g to be set
<abeato> sergiusens, which is fine, but I would like to know what happened
<mup> PR snapd#5796 closed: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5796>
<Chipaca> zyga: 5759? me?
<zyga> one last from the pack:
<zyga> Chipaca: hmm?
<zyga> Chipaca: your fix PR is green
<Chipaca> 5797
<mup> PR snapd#5798 opened: cmd/snap-update-ns: detach Mk{Prefix,{File,Dir,Symlink{,All}}} from Sâ¦ <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5798>
<zyga> Chipaca: can I please drag you into a quick look on a simple PR ^
<zyga> Chipaca: but I meant another PR earlier
<zyga> https://github.com/snapcore/snapd/pull/5797
<mup> PR #5797: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797>
<zyga> this is what I meant before :)
<Chipaca> ye
<Chipaca> missing a +1 though
<Chipaca> looking at 5798 now
<Chipaca> zyga: nice
<zyga> yeah, all generic (for now)
<zyga> I'll have a twist next
<zyga> though if you want _now_ is the time to move them to another package :)
<zyga> (now as in after this branch)
<Chipaca> zyga: _now_ is the time to eow, dude
<zyga> Chipaca: hold my beer
<zyga> oh wait!
<zyga> no :)
<zyga> I'm really into chopping the boilerplate off the trespassing fix and landing it
<zyga> and I'm writing a small new thing (wanna help?)
<zyga> not strictly related to snapd, related to golang strongly
<Chipaca> dunno, sounds dangerous
<Chipaca> zyga: go on then
<zyga> Chipaca: lemme push
<cachio> mvo, taking a look to the catalog, I see this
<cachio> aws-cli.aws[{"snap":"aws-cli","version":"1.15.71"}]
<mvo> cachio: uh, ok
<mvo> cachio: so maybe a real bug
<mvo> cachio: if its in the catalog
<mvo> niemeyer: I updated 5583 based on the standby helper we talked about earlier. but probably something for next week
<niemeyer> mvo: Thanks!
<niemeyer> mvo: Yeah, I'm about to jump into another meeting
<mvo> niemeyer: no worries, have a good one
<cachio> mvo, it seems to be
<pstolowski> pedronis: hmm, i see, sounds like something we should address in the tests
<Chipaca> zyga: http://r.chipaca.com/pprof001.svg
<zyga> mmm
<zyga> this 5K screen is useful now ;)
<Chipaca> zyga: looks like parseMountOpts could use some care
<Chipaca> zyga: as could assert's filesystemBackstore
<zyga> wow, yeah
<zyga> how can I reproduce this graph?
<Chipaca> also, we should probably look into whether the bug about json.RawMessage vs *json.RawMessage goes away with go 1.10 or sth
<Chipaca> zyga: the way i've got it is rather hacky, i'm sure there's a beter way, but
<zyga> no worries
<zyga> I'll look at parse now
<Chipaca> zyga: https://pastebin.ubuntu.com/p/PjMbFCk8GX/
<Chipaca> zyga: then, go tool pprof --alloc_space http://localhost:4040/debug/pprof/heap
<Chipaca> zyga: then 'web'
<Chipaca> zyga: before doing the 'go tool' thing, do some things with the snapd though
<zyga> Chipaca: quick test
<Chipaca> zyga: snap list; snap find foo; snap refresh; snap changes; snap info core http potato
<Chipaca> is what i did
<zyga> Chipaca: go to mountinfo_linux.go
<zyga> at the bottom
<Chipaca> going
<Chipaca> zyga: there
<zyga> change the map we make in that function
<zyga> to have initial size of strings.Count(opts, ",")
<zyga> +1
<zyga> and see if that makes any difference please
<zyga> I wonder if it is the map
<Chipaca> zyga: I think it's the strings.genSplit
<Chipaca> bah, maybe a bit of both
<zyga> we can easily remove one of the splits
<zyga> the 2nd one is a bit more work but we could do it if it shows up in the graph this much
<zyga> apparmor's addContent could use more love as well
<zyga> and the json thing you mentioned
<Chipaca> zyga: http://r.chipaca.com/pprof001.1.svg
<zyga> more memory!
<Chipaca> zyga: yeah, not sure what i'm seeing
<zyga> what are the arrows?
<zyga> and the memory sizes on them?
<Chipaca> zyga: injuns
<zyga> what does that mean?
<zyga> Chipaca: in any case, I think when making performance improvements common sense need not apply
<zyga> it's often surprising when one makes a change expecting a effect
<zyga> when one observes the opposite effect
<zyga> because reality is much more complicated
<Chipaca> zyga: https://stackoverflow.com/questions/35871365/interpreting-pprof-heap-diagrams
<zyga> mm, very useful
<zyga> ok
<zyga> Chipaca: so that single function allocates all that memort
<zyga> given that it usually handles just a few bytes this is very surprising
<Chipaca> zyga: it's called a lot
<zyga> hmmm, snapd calls it to make mount profiles
<zyga> and to parse fstab files
<zyga> maybe we need to just ... call it less?
<zyga> ha
<zyga> it's called for all the little bits
<zyga> it's called to know if we are in nfs land
<zyga> we could _probably_ call it from ensure
<zyga> and cache the yes-no answer
<zyga> well, then we'd call it every 5 minutes
<zyga> still
<Chipaca> whoa
<Chipaca> so,  i've got 35 snaps
<zyga> what? :)
<Chipaca> map[31:1836 18:108 44:108 11:1188 33:108 70:108 7:108 13:216 14:108 8:108 54:108 17:4428 2:8100 15:108 22:216 9:216 19:108 10:324 25:648 30:108 91:108 24:324 43:108 29:108]
<zyga> what's that map?
<Chipaca> zyga: that's len(opts):num of times called with len(opts)
<Chipaca> that's a lot of lil' maps
<Chipaca> zyga: what's the lifetime of these things?
<Chipaca> where do they go?
<zyga> they are probably very short lived but long enough to fool escape analysis
<zyga> they are used in ...
<zyga> osutil.IsHomeUsingNFS
<zyga> https://github.com/snapcore/snapd/blob/master/osutil/nfs_linux.go#L33
<zyga> so, maybe instead of a "gimme map"
<zyga> we can have a "callback on key=val" function
<Chipaca> zyga: it's also used from overlay_linux
<Chipaca> zyga: and from IsMounted
<zyga> yeah
<Chipaca> however
<Chipaca> hm
<zyga> same usage pattern
<zyga> as a side note I'm happy they _all_ use this implementation
<zyga> and not each have one of their own
<Chipaca> zyga: one easy thing with minimal changes would be to not load the options until needed
<zyga> yeah
<zyga> make it a method
<zyga> but I'd go all the way to kill the parser returning a list
<Chipaca> zyga: i.e. not load MountOptions nor SuperOptions at all in Parse, and have a LoadOptions or sth
<zyga> and have a callback style parser
<zyga> just Options()
<Chipaca> yah that might be even better
<zyga> then no list
<zyga> and almost no map
<Chipaca> yup
<zyga> neat
<Chipaca> bigger change though
<zyga> yeah true
<zyga> the option will be sufficient for most of this
<Chipaca> zyga: but yeah, building a list is going to be bad because people have a lot of snaps :-)
<zyga> loots of mounted things
<Chipaca> mhmm
<Chipaca> zyga: and then there are these crazy people implementing "layouts"
<zyga> nah, nobody would do that
<Chipaca> :-D
<zyga> the up side is that we don't look inside the mount namespaces often
<zyga> only from snap-update-ns
<zyga> and you didn't profile that s
<zyga> so whee :D
<Chipaca> zyga: it's pizza & beer time here
 * zyga hugs Chipaca 
<Chipaca> so i'm off to address that issue
<zyga> that's a good time
<zyga> though I though UK does tea time
<zyga> not beer time
<zyga> ttyl!
<Doctor_Nick> sign of troubles
<mup> PR snapcraft#2249 opened: build providers: provide support to shell in <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2249>
<mup> PR snapcraft#2250 opened: project_loader: add preflight check <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2250>
<Chipaca> Doctor_Nick: ?
<mup> PR snapcraft#2243 closed: [WIP] plugin API: support command-chain <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2243>
<mup> PR snapcraft#2251 opened: pluginhandler: stop using alias for snapcraftctl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2251>
<mup> PR snapcraft#2252 opened: Build providers debug shell <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2252>
<kyrofa> roadmr, you around?
<roadmr> hi kyrofa! I'm close to EOD but for now, still here
<kyrofa> roadmr, something funky is happening with nextcloud, it's saying reviews are held up behind something that says it still hasn't been reviewed yet, but still looks like it failed
<roadmr> kyrofa: oh ouch
<roadmr> let me have a look
<kyrofa> Thank you
<roadmr> kyrofa: this appears to be the stuck revno https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8754/
<roadmr> and the status is "Task 2e0a9939-79a3-49ea-96b5-69fa540e57e5 failed. "
<kyrofa> Indeed, and right above that "Automated review not yet completed"
<roadmr> kyrofa: I re-fired the automated review
<kyrofa> And no log anywhere
<kyrofa> roadmr, so did it fail, or not? If so, why didn't the rest continue being reviewed?
<roadmr> kyrofa: well I have logs but they'll just say that the click-reviewer-tools automated process took longer than X, even after retrying Y times
<kyrofa> Oh that's fun
<roadmr> kyrofa: after the l1TF mitigations and reboot of everything, we've found things are much much slower in our cloud :( we've bumped the timeouts significantly
<kyrofa> It seems the entire world has slowed down recently with those, yeah
<roadmr> kyrofa: but it's good that you call attention to this; we may need to up them even further. Still assessing what the world looks like now
<roadmr> kyrofa: why does nextcloud push so many revisions? do they have one for each PR or somesuch?
<kyrofa> roadmr, no thankfully, that would be far too much, these are dailies
<kyrofa> But of course, for every arch
<kyrofa> And for a few releases
<roadmr> 13 revisions over 45 minutes is about one revision every 3:30 minutes, and automated review is taking about 10 minutes for a snap this size :/
<roadmr> kyrofa: other than the L1TF armageddon, we also recently (1 month or so) enabled resquashfs enforcement, this means the snaps must be unpacked and repacked to verify the checksums. This also slows things down a bit but is necessary for security and to avoid squashfs evil
<kyrofa> roadmr, yeah I'm familiar with that one
<roadmr> kyrofa: we can maybe revisit the "if a revision fails, just leave it behind and continue checking the other ones" behavior. However, I think that's in place, buuut...
<roadmr> this case is different: the revision didn't fail-fail, but was held for manual review because the automated review couldn't be completed, so we don't know really. So in these cases we err to leaving it in "needs manual review", which does block the queue by design
<roadmr> at least the tweaks MatÃ­as did recently do allow us to manually fix things; before, these would just have gotten stuck in limbo, I'm sure you remember that too, from 3 weeks ago or so
<kyrofa> Oh yes, I remember. This too: https://forum.snapcraft.io/t/launchpad-upload-failing-waiting-for-previous-upload-s-to-complete-their-review-process/7135/2
<roadmr> right :/ due to the slowness, revision reviews are piling up in the queue :(
<roadmr> aha, interesting. kyrofa Task 27c34078-834c-4e1b-82a1-b4e2f2398fba is waiting to be retried. this is the review for 8755...
<roadmr> which is interesting because a moment ago it was "Waiting for execution". Does waiting time count against the timeout? that would suckk...
<kyrofa> Uh oh :P
<roadmr> kyrofa: ah interesting - I'd increased the timeouts but it looks like the old ones are still in effect :/
<roadmr> !%#&@% kyrofa sorry, this is my fault :( I cowboyed the timeout increases in production 2 days ago but today we did a rollout which clobbered those changes and I forgot to have them reapplied :(
<kyrofa> roadmr, that's alright, thanks for fixing
<roadmr> this is why I must always commit these changes to the source tree
<roadmr> kyrofa: a question - in https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8756/ do you have any buttons (green buttons) at the very bottom? https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8756/
<kyrofa> roadmr, no, I see reject and remove from queue only
<roadmr> oh ok...
<roadmr> I have a "rerun automated review" button, and any store admin would have that, helpful to unwedge revisions.
<kyrofa> roadmr, yeah I lost such privileges once you guys made finer-grained ones
<roadmr> sorry :(
<roadmr> aha, very interesting! kyrofa haha I like a good mystery. One of the passing tasks finished in just over 3 minutes: Task devportal.tasks.PackageReviewTask[27c34078-834c-4e1b-82a1-b4e2f2398fba] succeeded in 189.731960843s
<roadmr> kyrofa: and others are failing because they go over 6 minutes without finishing. So apparently some of the servers are slower in processing tasks than others. I'll make notes and investigate more on Monday
<roadmr> kyrofa: I think we have a slowpoke node :( I'm seeing nextcloud 8756 consistently land on that same node and time out :( I'll keep an eye on your queue and try to nudge it, but must EOD now... I've made a note of this and will look again on Monday
<mup> PR snapd#5786 closed: tests: update prepare/restore for nightly suite <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5786>
#snappy 2018-09-08
<Doctor_Nick> :D
<mup> PR snapcraft#2249 closed: build providers: provide support to shell in <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2249>
<mup> PR snapd#5799 opened: Install snap-failure binary on Fedora <Created by eyusupov> <https://github.com/snapcore/snapd/pull/5799>
<mup> PR snapd#5683 closed: overlord/patch: support for sublevel patches <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5683>
<Minoru> hi! If I want my snap to access dotfiles in user's home directory, is classic confinement my only option?
<mup> PR snapcraft#2253 opened: Build providers shell after <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2253>
<ogra> Minoru, better try the forum on weekends (see channel topic) ...
<mup> PR snapcraft#2254 opened: Build providers shell <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2254>
<mup> PR snapd#5798 closed: cmd/snap-update-ns: detach Mk{Prefix,{File,Dir,Symlink{,All}}} from Sâ¦ <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5798>
<Minoru> will do. Thanks!
#snappy 2018-09-09
<dot-tobias> (Good morning)
<onyb_fr7> I'm building a snap by specifying the source as my local directory, which is a cloned git repository. Under the parts definition, I'm using the "source" key with value "./src". However I see that Snapcraft is also copying files that's outside the "src" directory, notably the .git folder. Is there any way to ignore these extra files?
<ogra> onyb_fr7, try using "source: ." and "source-subdir: src"
<ogra> also, always use relative paths without spomething like ./
<ogra> (i.e. just "src", not "./src")
<diddledan> why is snapd denying opens on files shipped within core?! https://www.irccloud.com/pastebin/ozQJImar/
<diddledan> surely if it's in core it should _never_ be denied
<popey> diddledan: is that library in core?
<diddledan> if it isn't then why does it try to load it there?
<popey> (yes, it is)
<diddledan> (there's many libraries in that paste)
<diddledan> I'd like to hear arguments as to why it is desirable to deny access to libraries in core rather than not putting them in core to begin with
<diddledan> doesn't the whole "let's put this in core" kinda suggest that you expect snaps to use it???
<ogra> why would it allow opening random libs ?
<diddledan> why wouldn't it?
<diddledan> they're in core ffs
<ogra> the apparmor default profile doesnt blindly grant access to everything
<diddledan> core is "a shared platform that provides a base for all snaps" so if it isn't expected to read the libraries there then why are they there?
<ogra> especially if youo use /snap/foo/bar/12345/baz
<ogra> core is your / ...
<ogra> (from a snaps POV)
<ogra> why would apparmor allow any snap to access /snap/foo ?
<diddledan> that doesn't make a difference whether it's / or /core/omgzor
<ogra> it surely does :)
<diddledan> it's core ffs
<diddledan> core is shared. it's meant to be shared.
<ogra> just open it via /lib/$ARCH ;)
<diddledan> if you don't want us to access libraries from core then don't put them there
<ogra> yes, it is meant to be shared as your root as /
<ogra> not via /snap7core
<ogra> */snap/core
<diddledan> then why is "random snap" trying to read libraries from there when "random snap" hasn't been configured to do so. because something in snapd or the default setup has obviously told it about that location
<ogra> dunno, missing LD_LIBRARY_PATH entry perhaps ?
<popey> or incorrect LD_LIBRARY_PATH overriding existing
<diddledan> how is "not including a path in LD_LIBRARY_PATH" going to make an application decide "oh, I can't find this library. for **ts and giggles I'll look in this completely random arbitrary location that nobody has told me exists"
<ogra> /snap/core/current/lib/x86_64-linux-gnu is definitely identical to /lib/x86_64-linux-gnu ... but apparmor will definitely block the first
<diddledan> this is a snap that I built. I sure as hell did not tell it about /snap/core
<ogra> well, something did
<ogra> probably a bug, probably a missing or wrong LD_LIBRARY_PATH
<diddledan> therefore something in snapd or the snapcraft default wrapper scripts HAS told it about that location. I did not. therefore when I see it accessing that location which I didn't tell it about I assume that snapd has
<diddledan> if snapd is telling my application about a path then I expect that it be readable
<ogra> probably your snap ships a linker inside while it shouldnt and adds /snap/core to the lib search path
<ogra> i can only guess here
<diddledan> you seem to assume I'm a newbie
<ogra> but the DENIAL is definitely correct
<ogra> you know i'm not :)
<ogra> but all i can judge here is the DENIAL ... and thats fine ... why you get into that situation is likely a matter of debugging
<diddledan> you're spot on though. ld is included seemingly
<ogra> aha
<diddledan> wtf did that come from?!
<ogra> snapcraft should have protected you (IMHO)
<diddledan> yeah that should be a blacklisted thing
<ogra> just like libc
<diddledan> https://www.irccloud.com/pastebin/bJzKmUo7/
<diddledan> that's all the ld
<diddledan> oh boy https://www.irccloud.com/pastebin/FjigITFo/
<diddledan> so because I've got $SNAP/lib in LD_LIBRARY_PATH it's picking ld-2.23.so from there?
<diddledan> darn and blast it
<popey> ooh
<popey> good debugging
 * diddledan yells at mycroft only to get no reply because he's got a random ld.so
<diddledan> well foo
<diddledan> I'm annoyed as much at myself as at snapcraft :-p
<diddledan> this is painful :-p
 * diddledan moans more
<diddledan> now to work out how to get mycroft semaphores working
<diddledan> it's using the python multiprocessing module for something and getting permission denied which was what highlighted those others - the semaphore permission denied though doesn't appear to be causing a denied message in the logs :-(
 * diddledan goes to find consolation cookies
 * ogra hands diddledan some hot fresh coffee to have with the cookies
<diddledan> \o/
<diddledan> ...and calm
 * diddledan breathes methodically
<diddledan> https://youtu.be/v30HUOx6SYk?t=50
<ogra> :D
<diddledan> speaking of snapcraft - kyrofa and I discovered a really random edge case problem - keeping vscode open while compiling a large project that also depends on the alsa remote part I created will cause the build to die part-way through complaining that alsa changed on disk even though it didn't
<diddledan> again that was mycroft that highlighted this one
<diddledan> it seems that vscode will do something while it monitors for git changes that causes the .git folder timestamp to change. combine that with the alsa remote part which doesn't specify a source, therefore meaning `source: .` and you get snapcraft detecting that the source (.) for alsa changing
<ogra> grr, why does snapcraft close not take an --arch argument
#snappy 2019-09-02
<mborzecki> morning
<mup> PR snapd#7323 closed: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>
<zyga> School morning
<mborzecki> zyga:  hey, yeah, school morning
<zyga> I will be around shortly
<zyga> Walking back from school
<mborzecki> mvo: hey
<mvo> hey mborzecki ! welcome back
<mup> PR snapd#7384 opened: HACKING.md: clarify where "make fmt" is needed <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7384>
<mup> PR snapd#7382 closed: osutil: make flock test more robust <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7382>
<zyga> hey mvo, thank you for merging that
<zyga> mvo: btw, can you look at the corresponding non-test code
<mvo> zyga: good morning! thanks for creating it :)
<zyga> mvo: I was puzzled by how that can ever happen
<zyga> mvo: it looks like a bug in the compiler or something in our understanding
<zyga> mvo: as that function cannot return nil, nil, can it?
<zyga> mborzecki: 1st day of school and temperature drops by 10 degrees
<mvo> zyga: NewFileLock, no, that looks impossible, we are explicitly about the "nil" there.
<zyga> mvo: right? I was worried when I saw that because it feels we are missing something important
<mvo> zyga: yeah, its very confusing
<zyga> perhaps go gc bug?
<mborzecki> arch package updated
<mup> PR snapd#7385 opened: tests/cross/go-build: use go list rather than shell trickery <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7385>
<mborzecki> super simple PR ^^
<mvo> zyga: I looked at this flock issue again, I think you fixed it. the issue is that "err = lock.TryLock()" may return nil - if there is lock. but then err, Equals, osutil.ErrALreadyLocked will trigger a err->Error I think
<zyga> oh
<zyga> actually, yeah
<mvo> zyga: which causes the crash, your code now first assigns err and then checks for non-nil so this error goes away
<zyga> actually
<zyga> no wait
<zyga> hmm
<zyga> so are you saying that due to the raceiness
<zyga> the error can be nil
<mvo> zyga: correct
<zyga> and then Equals would panic?
<mvo> zyga: yes, I think so, equal will try to make it an error
<mvo> zyga: I have not looked at the details but I think so
<zyga> that's certainly plausible and more realistic that a gc bug :)
<mvo> zyga: I think "c.Assert(nil, Equals, osutil.Err..") should behave the same
<zyga> nice, you made my mind more at ease
<zyga> oh, good idea
<zyga> I'll chcek
<mvo> zyga: yeah, thanks for fixing this one! it is really an interessting one :)
<zyga> indeed
<zyga> https://www.irccloud.com/pastebin/z0RHTYJO/
<zyga> you are spot on
<mvo> yay
<zyga> that's so unexpected btw
<mvo> zyga: agreed
<mvo> zyga: ErrorMatches will DTRT - except it matches instead of equals :/
<mborzecki> off to the school with kids, back in ~1.5h
<zyga> mborzecki: good luck :)
<zyga> hey sil2100 :)
<mvo> zyga: oh no, I think this error happens in the "diff" code we added a while ago :( so gopkg.in seems to got broken by this
<mvo> zyga: that bug is on me I think :(
<zyga> ahhh
<zyga> I recall this
<zyga> well, one less but two more :D
<mvo> zyga: yeah, there is also the circular bug in github.com/kr/pretty - makes me wonder if we should simply revert that diff code
<zyga> the diff on error is somewhat useful, I wonder how hard would it be to fix it instead
<zyga> but also worried if we use old version or if upstream is dead
<mvo> zyga: I fix it, thats trivial
<mvo> zyga: I'm just a bit sad that its "1 added, 2 new bugs introduced"
<zyga> yeah, no disagreement
<zyga> "what's under this rock over here, let me turn it over"
<mvo> niemeyer: hey, good morning! if you have some spare cycles, I have a very simple gocheck PR (https://github.com/go-check/check/pull/114) that would be great to get merged. I feel bad because its an issue introduced with a PR that I originally proposed :(
<mup> PR go-check/check#114: checkers: fix misleading error for c.Check(nil, Equals, "foo") <Created by mvo5> <https://github.com/go-check/check/pull/114>
<mvo> mborzecki: can you please check if github.com/sanity.io/litter is available in fedora as a package? I wonder if we can switch away from kr/pretty as its unmaintained (and there is this cyclic references bug that can cause hangs)
<mup> PR snapd#7384 closed: HACKING.md: clarify where "make fmt" is needed <Simple ð> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7384>
<pstolowski> mornings
<zyga> hello pawel
<zyga> pstolowski: feels good to send kids to school again, no? :)
<jamesh> hi zyga
<zyga> hey, good morning
<jamesh> zyga: at GUADEC, there was a request for a snapd feature that might be quite difficult to implement
<zyga> tell us!
<jamesh> zyga: essentially they want to move the org.freedesktop.portal.Flatpak.Spawn portal interface from Flatpak to xdg-desktop-portal, and have it do something sensible for snaps
<pstolowski> zyga: haha, indeed, i just got back from there
<jamesh> this is essentially a way for a confined process to spawn a second process with even stricter confinement: https://github.com/flatpak/flatpak/blob/master/data/org.freedesktop.portal.Flatpak.xml
<jamesh> the idea being to allow applications that confine portions of their code to continue doing so when put in Flatpak/snap confinement (e.g. web browsers)
<zyga> jamesh: hmm
<zyga> what is the interface like?
<jamesh> the XML file I linked to has documentation for the interface
<jamesh> the main features are (a) pass file descriptors to spawned process, (b) optionally block network or file system access, (c) expose a restricted set of files to the spawned subprocess
<zyga> yeah, reading that now
<jamesh> It's basically something to replace the fork/unshare/exec code you might find in multi-process apps
<zyga> hmmm
<zyga> some of the concepts don't map cleanly
<zyga> what is a "sandbox" in flatpak term?
<zyga> as in flag value 4
<zyga> spawn in a sandbox
<jamesh> I need to look that up.
<zyga> is there a demo app for this or a production app that would use it?
<jamesh> I think the big one at the moment is webkit-gtk
<zyga> I think it's doable but not small or on or our roadmap for this cycle so it's hard for me to say if we can do it
<zyga> jamesh: some things there look vert flatpack specific, like ~/.var/app/$APP_ID/sandbox
<zyga> I'm sure it's all doable but we'd have to think about how to construct that
<zyga> jamesh: that dbus api is for the user session?
<jamesh> zyga: right.  I think the idea is to get something that could provide equivalent functionality
<zyga> jamesh: so you spawn it as yourself essentially, right?
<jamesh> the xdg-desktop-portal version wouldn't necessarily be identical
<zyga> I see
<jamesh> yes.  This is a user session API, same as the other portal services
<zyga> well, I'm open to this for sure
<zyga> it would be nice to explore this if we have agreement / time to do it
<jamesh> zyga: so I think "fully sandboxed" means only access to the runtime, app data and files specifically exposed in ~/.var/app/$APP_ID/sandbox
<jamesh> so snap-wise, that would be no home interface, and only access to a small subset of ~/snap/$snap_name
<zyga> almost like "all interfaces disconnected"
<jamesh> possibly, yeah.
<jamesh> zyga: If we could get this all working and it was adopted by upstreams, it would probably remove the need for the allow-sandbox flag on our browser-support interface
<zyga> jamesh: indeed, that's pretty interesting as an evolution of the concept "we package stuff as-is" to "we provide a new layer to apps"
<jamesh> zyga: in the current release of GNOME, the file manager makes use of bubblewrap to confine thumbnailer subprocesses.  So a big part of this is to allow this model to continue in the new world
<jamesh> (since you can't run bubblewrap in Flatpak's bubblewrap based sandbox either)
<zyga> mborzecki: hey
<zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/7218/files
<zyga> it's just a new spread test
<mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
<zyga> could you please have a look, make sure to read both commit messages
<niemeyer> mvo: Thanks, will have a look
<mvo> niemeyer: should be super trivial, let me know if I can help in any way
<niemeyer> mvo: It's in, thanks again!
<mvo> niemeyer: \o/
<mup> Bug #1842282 opened: can't add channel information as install downloaded snap <Snappy:New> <https://launchpad.net/bugs/1842282>
<mborzecki> re
<mborzecki> mvo: there's apackage of github.com/sanity.io/liter in fedora, it's version 1.1.0 if that makes any difference
<mvo> mborzecki: thank you
<mborzecki> mvo: hmm https://github.com/sanity.io/litter is a 404 for me?
<mvo> mborzecki: https://github.com/sanity-io/litter
<mborzecki> duh
<mborzecki> ok, works for me :P
<mborzecki> mvo: do you remember that other lib? https://github.com/davecgh/go-spew
<mborzecki> mvo: looks like litter is packaged for debian too, so we can switch to either one
<mvo> mborzecki: spew is available for centos/fedora too? cool
<mborzecki> mvo: for centos/amzn we use a bundled pacakge
<mborzecki> s/use/build/
<niemeyer> mvo: I have an on going diff sitting on my disk for a while around that area of go-check, btw..
<niemeyer> mvo: It improves a bit the way the diff is displayed in some cases
<niemeyer> mvo: But I've hit an issue with kr's diff lib.. it broke down in some nested data
<mvo> niemeyer: yes, we have a fix for this in kr/pretty
<niemeyer> mvo: Oh?
<mvo> niemeyer: it breaks on cyclic data
<niemeyer> mvo: Was that submitted upstream?
<mvo> niemeyer: https://github.com/kr/pretty/pull/58
<mup> PR kr/pretty#58: Fix infinite recursion when diffing structs with cycles <Created by stolowski> <https://github.com/kr/pretty/pull/58>
<mvo> niemeyer: also https://github.com/kr/pretty/pull/44 (which looks similar)
<mup> PR kr/pretty#44: Detect cyclic references in Fdiff() <Created by mbergin> <https://github.com/kr/pretty/pull/44>
<niemeyer> Oh, nice
<mvo> niemeyer: I can't reach him though :/ maybe he replies to twitter pings :)
<mvo> this is open for some time
<niemeyer> I can understand him :)
<niemeyer> We should just fork temporarily while this is sorted
<mvo> niemeyer: works for me
<geodb27> People : hi ! I run a lxd cluster on three virtual machines under ubuntu-18.04 lts. As you might know, lxd is shipped via snap. There seem to be a problem with the way updates are run. Indeed, the three machines are all the same considering installed os version and hardware. They, of course, have all their time maintained via ntp. Error occur when all three decide that it is time to update lxd : since the processes are ran at the same time, this
<geodb27> results in a crash of the overall cluster and require intervention to have all three systems in a production state. Question is : how does snap decide it is time to update what is installed ? If it is done internally, wouldn't it be fine to add some "salt" to the decided time so that everything does not start at the same time everywhere ?
<Chipaca> geodb27: updates shouldn't run at the same time, as there is a random element to the time
<Chipaca> geodb27: additionally, you can schedule when updates happen, so if you have a requirement for them not to happen simultaneously that is something you can configure
<Chipaca> geodb27: if you have debug logs on snapd will log when it will update next, but debug logs are very chatty so most people don't
<Chipaca> geodb27: 'snap refresh --time' will print when the next refresh will happen (mostly)
<Chipaca> geodb27: 'mostly' because right after snapd starts, and until the first time it checks, the next refresh time isn't set
<geodb27> Thanks for you answer Chipaca. I'll check how it is done on the different machines.
<Chipaca> geodb27: as to how to set the refresh timer, https://snapcraft.io/docs/keeping-snaps-up-to-date
<geodb27> Well, the problem seems somewhere else. I'll have to wait for the next lxd's snap to check what goes wrong.
 * zyga finishes calls and jumps into the fray :)
<geodb27> What is sure is that a lxd cluster is in an "undefined" state after a snap update while a single one runs fine.
<Chipaca> geodb27: i'm not sure what that means :-| maybe stgraber can shed some light?
<ppd1990> zyga: Thanks for reviewing #7366 - I've found a (I believe) satisfactory solution to only exposing appropriate gpg-agent functionality. I'd be quite glad if you could give it another look in the near future
<mup> PR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
<zyga> ppd1990: sure, thank you for iterating
<zyga> I'll look now :)
<zyga> ppd1990: you mean the S.gpg-agent.extra socket?
<ppd1990> zyga: Right
<zyga> ppd1990: that sounds very much better, I will defer the final review to jdstrand but I think that's no longer -0.5 on my end
<zyga> ppd1990: please update the PR with that
<zyga> make sure to update the summary of the interface as well, it's just text but it matters for review clarity
<geodb27> Indeed Chipaca. I'll look forward to fill in an issue on https://discuss.linuxcontainers.org/ when I face the same problem. Thanks for your kind answers anyway :-)
<ppd1990> zyga: Will do. Any opinion on it being necessary to "bend" the GPG binary in the snap to this socket? Is is somehow possible to "layout" this socket into the snap namespace instead of S.gpg-agent?
<zyga> ppd1990: not yet, not for anything in /shome
<zyga> (I meant /home/)
<zyga> ppd1990: I think if there's a workable way to point gpg there that's enough
<ppd1990> zyga: Fair enough. If it works, it works :) Shall we update the interface description to include "signing and encrypting"?
<zyga> mhm
<zyga> plas
<zyga> *please
<zyga> gosh, I cannot type today
<mup> PR snapd#7386 opened: many: refactor boot/boottest and move to bootloader/mockbootloader <Created by chipaca> <https://github.com/snapcore/snapd/pull/7386>
 * Chipaca gives zyga a keyboard that does auto-correct on the fly
<zyga> Chipaca: thakns ;)
<zyga> (that was deliberate)
 * Chipaca pushes an update to the auto-correct snap to mess with zyga
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7218 should now pass
<mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
<zyga> Chipaca: brexit news is surprising
<zyga> Chipaca: at this rate I would not be surprised in anything
<Chipaca> zyga: which part of it?
<zyga> Chipaca: the whole suspension of parliament
<Chipaca> zyga: and the "if you vote this way you'll be fired"?
<Chipaca> tyranny is fun
<zyga> game of thrones, except some people are living in it and are on the frontline
<Chipaca> "this was not meant as a tutorial!?!"
<mborzecki> zyga: about https://github.com/snapcore/snapd/pull/7385#discussion_r319827158 i did the change and it looks a bit awkward, since it's a single go build -o /dev/null for all 5 binaries (in theory all binaries are written to /dev/null)
<mup> PR #7385: tests/cross/go-build: use go list rather than shell trickery <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7385>
<zyga> aw, I see
<zyga> I forgot the binary aspect of it
<zyga> normally I was just "go building" everything
<zyga> but I didn't mind the binaries
<zyga> so what is this doing? testing that we can build?
<mborzecki> fwiw i think go build should erorr out there
<mborzecki> zyga: yes, it's cross compiling those binaries
<zyga> yeah, +1
<mborzecki> zyga: can you leave a +1 in the PR? it's green so we'll land it ;P
<zyga> sure, done!
<mborzecki> thanks!
<mup> PR snapd#7385 closed: tests/cross/go-build: use go list rather than shell trickery <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7385>
<pedronis> Chipaca: I commented on #7386, we don't have any mock* package atm
<mup> PR #7386: many: refactor boot/boottest and move to bootloader/mockbootloader <Created by chipaca> <https://github.com/snapcore/snapd/pull/7386>
<Chipaca> fair
 * Chipaca adds more mock packages to fix that issue
<pedronis> Chipaca: silly you :)
<Chipaca> :-)
<mborzecki> zyga: updated #7302
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<zyga> mborzecki: thanks, I'll look shortly
<zyga> mborzecki: 19.04 ha some more cgroup wonkiness
<zyga> my test is failing there, I think you were right, the /proc/PID/cgroup format changerd
<zyga> *changed
<zyga> I'll finish and check that out soon
<pedronis> Chipaca: +1, with comments on something related but prexisting
<mup> PR snapd#7387 opened: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<mborzecki> zyga: support script for packit ^^
<zyga> looking
<zyga> https://github.com/snapcore/snapd/pull/7387#pullrequestreview-282543875
<mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
 * zyga goes for a walk with the dog
<zyga> mborzecki: I'll review mount ns for classic snaps PR when I'm back
<ppd1990> zyga: I updated #7366. Thanks again for the guidance
<mup> PR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
<Chipaca> pedronis: thanks! I'll fix those in a followup
<mup> PR snapd#7386 closed: many: refactor boot/boottest and move to bootloader/bootloadertest <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7386>
<cachio> zyga, did you see this one? https://paste.ubuntu.com/p/MngRDC5nQm/
<zyga> re
<zyga> cachio: what about it?
<Chipaca> mvo: needing to re-login to chrome, i'm omw
<zyga> 2fa
<mup> PR snapd#7388 opened: boot, bootloader, o/snapstate: boot env manip goes in bootloader <Created by chipaca> <https://github.com/snapcore/snapd/pull/7388>
<Chipaca> pedronis, zyga, ^ includes (as separate commits) the cleanups you'd requested from previous PRs
<pedronis> Chipaca: we need to talk
<Chipaca> pedronis: ok
<cmatsuoka> mvo: about the world clocks, you'll also need an extension called "panel world clock (lite)"
<mup> PR snapd#7388 closed: boot, bootloader, o/snapstate: boot env manip goes in bootloader <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7388>
<cachio> jamesh, hey
<cachio> jacekn, https://github.com/snapcore/snapd/pull/7361#issuecomment-526330249
<mup> PR #7361: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
<mvo> cmatsuoka: ta
<cachio> jamesh, https://github.com/snapcore/snapd/pull/7361#issuecomment-526330249
<cachio> jamesh, any idea about this problem on eoan?
<mup> PR snapd#7389 opened: cmd/libsnap: make feature flag enum 1<<N style <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7389>
<Chipaca> pedronis: do we have a convetion for constants vs variables? (i think no, but thought to check)
<Chipaca> pedronis: nm
<pedronis> Chipaca: in which sense?
<Chipaca> pedronis: there was a constant defined for "snap_mode", and I wondered if we wanted it to be obvious it was a constant in usage
<Chipaca> pedronis: but then i realised it was not actually used anywhere
<pedronis> Chipaca: go doesn't have special naming convention for constants afaik
<Chipaca> pedronis: so the problem disappeared with a nice round "pop!"
<Chipaca> pedronis: :)
<mup> PR snapd#7390 opened: tests: unit test for a refresh failing on configure hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/7390>
<mup> PR snapcraft#2696 opened: shell_utils: Add SNAPCRAFT_DEBUG_SCRIPTS env variable <Created by mkg20001> <https://github.com/snapcore/snapcraft/pull/2696>
<mup> PR snapd#7391 opened: boot, bootloader, o/devicestate: boot env manip goes in boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7391>
<Chipaca> pedronis: ^^^
<cachio> mvo, hey, this is the error on pi2 https://paste.ubuntu.com/p/zzQ8Q73SY6/
<cachio> when we try to create a user
<Chipaca> cachio_: that error looks like /var/lib/extrausers isn't writable
<mup> PR snapd#7389 closed: cmd/libsnap: make feature flag enum 1<<N style <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7389>
<mvo> cachio_: what Chipaca said, can you ssh into this machine and touc a file in /var/lib/extrausers ? maybe something "funny" is going on with the writable magic
<mvo> Chipaca: so I keep poking at ondras LK pr - I played with your idea to split the types and have a "lk" and "lkPrepareImage" and that makes the code easier but it feels a bit strange. I was wondering if we should have a "func PrepareImage(gadgetDir)"  on the bootloader interface (and kill ConfigFile there which does not make sense in a world of partitions). wdyt?
<Chipaca> mvo: would the PrepareImage(gadgetDir) on bootloader avoid all the ifs?
<mvo> Chipaca: I am exploring this, the way image.go works probably also needs tweaking
<mvo> Chipaca: anyway, if its not something you looked at (yet) I keep poking, was just wondering if you had thoughts :)
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/7320 needs some attention
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> mvo: if it avoids the ifs i'm fine with it :-) i'd check with pedronis wrt core20 but i think bootloader will be growing something similar anyway? not sure
<Chipaca> zyga: ack
<mvo> Chipaca: it seems conceptually clean so I think its worth exploring, I look at the image bits now and then I will chat with pedronis if this makes sense
<Chipaca> mvo: if not, if the bootloader really needs different behaviour depending on whether it's in prepare or regular mode, then it's fine for it to be two separate things. Alternatively it might just be parametrised if the ifs are just to determine a string
<Chipaca> or, you know, subclassed if it's somewhere in the middle :-)
<zyga> and so it rains
<zyga> welcome to september kids
<mvo> Chipaca: yeah, I have sometihng without ifs now but I'm still not happy, it feels conceptually not great
<zyga> mvo: 7286 is close but I left a comment there
<pedronis> mvo: what does PrepareImage do?
<mvo> Chipaca: https://github.com/snapcore/snapd/compare/master...mvo5:lk-2?expand=1 fwiw - based on the earlier ideas
<zyga> cachio: can you look at 7218 again please
<cachio> sure
<mvo> pedronis: it would do the job of the current InstallBootConfig and setting the boot vars. its mostly there because with LK runtime and image-building time is conceptually different. the image-build needs to write to a file and the runtime to a partition. so I was thinking it would be nice to have a clear interface for this
<zyga> cachio: https://github.com/snapcore/snapd/pull/7361 seems to be more complex, do you think we can close it and open dedicated PRs for address book interface and test issue, go fmt test issue and then the remaining 19.10 mechanics
<mup> PR #7361: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
<zyga> cachio: especially since the interface test may take more iteration
<pedronis> mvo: ok, it will need some mediation for Core 20 though, because is not all a booloader problem
<mvo> pedronis: yeah, let me experiment a little bit and then I can write something up. I don't want to waste your time with something that may not be great in the end
<mvo> (s/great/helpful/)
<cachio> zyga, ok, what about moving 19.10 to manual
<zyga> cachio: that's okay too, if that helps you out
<pedronis> mvo: I am also touching all that code,
<zyga> cachio: or remove the tests from 19.10
<cachio> then we have the system in the spread yaml nad aI can create both changes
<pedronis> well touching soon
<zyga> cachio: anything that is focused on one task and can land fast is good in my book
<cachio> ok, in that case I'll remove those failing tests from 19.10
<cachio> so we can go forward
<cachio> zyga, thanks
<zyga> that sounds good, thank you
<pedronis> mvo: my worry is that not all the bootvars will be a task of the bootloader anymore
<pedronis> so we cannot move the task completely there
<pedronis> mvo: so the right interface in image is probably something like boot.PrepareImage() but exactly what it needs to take is not super clear atm
<pedronis> of course internally it would call bootloader bits as needed
<mvo> pedronis: right, I can add it to boot.PrepareImage, we probably still need something on the bootloader interface to setup a subset of the bootvars
<Chipaca> pedronis: what's your opinon on using a separate bootloader instead?
<pedronis> ?
<Chipaca> ah, missing context
<Chipaca> pedronis: <mvo> Chipaca: so I keep poking at ondras LK pr - I played with your idea to split the types and have a "lk" and "lkPrepareImage" and that makes the code easier but it feels a bit strange. I was wondering if we should have a "func PrepareImage(gadgetDir)"  on the bootloader interface (and kill ConfigFile there which does not make sense in a world of partitions). wdyt?
<pedronis> have  bootloader that we use only in prepare-image ?
<pedronis> doesnt' sound a great idea to me
<Chipaca> yeah as mvo says it feels weird :-)
<mvo> it makes the code more organized though but still feels weird
<Chipaca> pedronis: it started because currently almost everything in lk is "if inPrepareImage { one thing } else { some other thing }"
<pedronis> well
<pedronis> I think that sounds more like
<pedronis> there should be an optional interface
<pedronis> and boot.PrepareImage knows about it
<pedronis> and then the ifs prepare-image bit go under that
<pedronis> interface
<mvo> pedronis: interessting, let me ponder about this a bit
<pedronis> if I understand for most booloaders runtime interface works for prepare-image
<pedronis> this is not the case
<pedronis> for lk
<mvo> pedronis: correct
 * cachio lunch
<pedronis> so have a couple short cut methods under some PrepareImageInstaller interface
<pedronis> or something
<pedronis> boot.PrepareImage default code would use the runtime methods
<pedronis> but if it detects that interface
<pedronis> it will use the shortcuts/methods there
<mvo> pedronis: sounds good, I will work on this
<pedronis> mvo: done this way, with boot has a hub is anyway a good step for Core 20 too
<pedronis> mvo: it might be good to propse the image boot refactoring separately though
<pedronis> if you find it works
<mvo> pedronis: cool, I explore and then will push something
<pstolowski> Chipaca: was https://bugs.launchpad.net/snapd/+bug/1823680 fixed?
<mup> Bug #1823680: snap okay error unhelpful <snapd:New for chipaca> <https://launchpad.net/bugs/1823680>
<zyga> pstolowski, cachio: I made some improvements to retry command, should I push it to 7256 or open a new PR and let 7256 focus on application of that command to the two tests?
<zyga> I was about to push but based on pawel's comment I'm inclined to open a new PR instead
<cachio> zyga, is it ok for me if you want to push over the same PR
<mup> PR snapd#7379 closed: tests: add version-tool for comparing versions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7379>
<zyga> cachio: I'll open a new PR then,
<zyga> cachio: could you look at 7370
<zyga> cachio: the prerequisite has just landed and I think this is good to go
<zyga> it will fix one random failure on master
<pstolowski> zyga: i'm ok with same PR but i'd keep that particular test intact, per my comment
<zyga> pstolowski: I think it's cleaner, the original PR focused on changing the test
<pstolowski> ok
<mup> PR snapd#7392 opened: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
<zyga> cachio, pstolowski: https://github.com/snapcore/snapd/pull/7256#issuecomment-527200990
<cachio> zyga, sure
<mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<zyga> cachio: I already found some use for the retry-tool!
<zyga> it's really nice, it can be used for very powerful one liners
<zyga> check this out:
<zyga> cachio: retry-tool in action https://www.irccloud.com/pastebin/LXXgoT84/
<pstolowski> nice!
<pstolowski> i was always annoyned by writing these retry loop
<pstolowski> *loops
<zyga> yeah
<zyga> let's review it :)
<cachio> zyga, nice
<cachio> retry tools are always usefull testing :)
<pstolowski> i'll take a look tomorrow morning
<pstolowski> ty
<zyga> thanks pawel!
<zyga> ok, wrapping up one PR and calling it a day
<mup> PR snapd#7370 closed: tests: fix ephemeral mount table in left over by prepare <Test Robustness> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7370>
<zyga> thank you cachio!
<cachio> zyga, yaw
<cachio> zyga, is #7361 ok for merge now?
<mup> PR #7361: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
<Chipaca> pstolowski|afk: $  snap okay
<Chipaca> error: you must have looked at the warnings before acknowledging them. Try 'snap warnings'.
<Chipaca> pstolowski|afk: as per #6919 referenced in the bug
<mup> PR #6919: cmd/okay: Remove err message when warning file not exist <Created by ardaguclu> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6919>
<Chipaca> pstolowski|afk: and then I realised what you were asking me to do was to update the bug's status :-D done
<Chipaca> post-run brain is not best brain
<Chipaca> despite it thinking it is
<mup> PR snapd#7192 closed: tests: initial change to retry on external files download <â Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7192>
<mup> PR snapd#7361 closed: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
<mup> PR snapd#7391 closed: boot, bootloader, o/devicestate: boot env manip goes in boot <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7391>
#snappy 2019-09-03
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: kids already at school, yay ;)
<zyga> mborzecki: oldest just went to school
<zyga> mborzecki: middle one finished breakfast
<zyga> mborzecki: youngest one plays with her toys :)
<zyga> mborzecki: our son is 170 now
<zyga> he's not even 13
<zyga> mborzecki: easy landing for the morning https://github.com/snapcore/snapd/pull/7218#pullrequestreview-272716535
<zyga> mborzecki: I added the extra checks you asked for
<mup> PR #7218: tests: measure behavior of the device cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/7218>
<mborzecki> and it's green :)
<zyga> woot, thankyou
<zyga> another easy ish is https://github.com/snapcore/snapd/pull/7392
<mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
<zyga> needs 2nd +1
<zyga> also green
<mup> PR snapd#7218 closed: tests: measure behavior of the device cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7218>
<zyga> mborzecki: one more kid to walk to school, ttyl
<zyga> back now
<mborzecki> mvo: morning
<mvo> hey mborzecki
<zyga> good morning mvo
<zyga> mvo: one more review if I can grab your attention :)
<zyga> https://github.com/snapcore/snapd/pull/7392
<mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
<zyga> mborzecki: let's start chopping your classic mount namespace PR as we discussed in private
<zyga> it will help with the review and will help with figuring out what is wrong
<mvo> hey zyga
<zyga> :-)
<zyga> mvo: do you know who is the upstream of command-not-found nowadays?
<mvo> zyga: foundations, why?
<zyga> mvo: I have some patches
<mborzecki> mvo: zyga: #7393 really simple
<mup> PR snapd#7393 opened: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
<mup> PR #7393: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
<zyga> mborzecki: +1
<mborzecki> thx
<mup> PR snapd#7394 opened: tests: move debug section after restore <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7394>
<pstolowski> morning
<zyga> good morning pawel!
<pedronis> pstolowski: hi, what's the status of #7277 ?
<mup> PR #7277: [RFC] overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
 * zyga goes to read https://github.com/snapcore/snapd/pull/7381
<mup> PR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
<zyga> great for rainy morning focus :)
<pstolowski> pedronis: hi, i've addressed your feedback but not yet happy about some aspects, i need to revisit this PR, i haven't looked at it for a while
<mborzecki> pstolowski: pedronis: hi
<pedronis> pstolowski: it's the last bit of https://trello.com/c/9Clql0BE/299-first-boot-fixes , considering that the initramfs/grub stuff is more nice to have
<pedronis> and also not great time given uc20 work
<pstolowski> pedronis: ack, going to look at it today
<zyga> is it just me or is github not responding very well now?
<mup> PR snapd#7393 closed: cmd/libsnap-confine-private, cmd/s-c: use constants for snap/instance name lengths <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7393>
 * zyga short break
<mup> PR snapd#7394 closed: tests: move debug section after restore <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7394>
<Chipaca> zyga: ping
<zyga> hey
<Chipaca> zyga: hiya
<Chipaca> zyga: what's the purpose of osutil.MountOptsToFlags ?
<Chipaca> it seems very sensible, but it's not used -- instead, the unchecked MountOptsToCommonFlags is used
<zyga> let me look
<Chipaca> k
<Chipaca> not going to change it, but it caught my attention
<Chipaca> (i'm fixing compilation on darwin)
<zyga> ah,
<zyga> I see it now
<zyga> it's the layer on top of common flags that understands x-snapd and filters them out but errors on unknown flags
<zyga> let me look at that
<zyga> thanks!
<Chipaca> zyga: np! tbh it looks like the Common one should be private, if i understand the difference
<zyga> if you look at how it is used, common is the one being used because we acknowledge there are flags we don't understand that we just pass to mount
<mup> PR snapd#7395 opened: cmd/snap-confine: apply global mount namespace initialization for confined and classic snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7395>
<zyga> so I think the strict version is just unused and could be removed
<pstolowski> zyga: any thoughs on https://bugs.launchpad.net/snapd/+bug/1841137 ?
<mup> Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Triaged> <https://launchpad.net/bugs/1841137>
<zyga> pstolowski: oooh
<zyga> interesting
<pstolowski> zyga: garbage collection gone wrong?
<zyga> there's no garbage collection, it's explicitly managed malloc/free style
<zyga> the deleted aspect is super puzzling!
<pstolowski> zyga: i mean gc in the sense of removing old revisions automatically
<zyga> pstolowski: nitpick: triaged literally means: we know the severity
<zyga> setting it to triaged without setting one is weird
<zyga> pstolowski: normally mount does that
<zyga> pstolowski: libmount removes loopback devices
<Chipaca> agreed about triaged
<zyga> since I just rebooted
<Chipaca> if you don't know the severity it's confirmed, not triaged :-)
<zyga> can everyone with a longer uptime run: sudo losetup | grep deleted
<zyga> and see if it shows anything
<Chipaca> nothing right now but i have seen them before
<Chipaca> that's when they appear in unity
<Chipaca> i didn't know it was noteworthy :-)
<zyga> that's super curious
<zyga> I wonder if that's another lowlevel bug in kernel/libmount/systemd
<zyga> normally systemd doesn't handle those so more likely in libmount
<pstolowski> Chipaca, zyga noted, thanks :)
<Chipaca> what snap is it? here it's always been core when i've looked
<zyga> mvo, pedronis, mborzecki ^ perhaps you? (sudo losetup | grep deleted)
<pstolowski> Chipaca: btw thanks for updating yesterday's bug ;)
<zyga> Chipaca: those that refresh
<zyga> Chipaca: I will look at adding a test for this though
<zyga> Chipaca: refresh tree times
<zyga> Chipaca: maybe that's exactly what I saw in the core 18 leak detector
<Chipaca> pstolowski: :)
<zyga> I saw deleted revisions
<pstolowski> Chipaca: there are more snaps than just core there
<zyga> so maybe it's a real bug that just doesn't get measured because refreshes are not 10 a day
<zyga> pstolowski: thank you!
<pedronis> zyga: a bunch for core
<zyga> can you check the changes for those if you still have them
<zyga> pedronis: I assume you have high uptime
<zyga> but that's great, it's probably easy to reproduce then
<pedronis> I doubt, they are actuall old revisions
<mvo> zyga: none here it seems
<pedronis> < 7700
<zyga> thanks guys!
<mvo> (just ran your command)
<zyga> thank you
<zyga> pstolowski: thanks for sharing, I was working on this anyway without realizing it is not limited to our test suite
<pedronis> zyga: https://pastebin.ubuntu.com/p/wwXft5wyDg/
<zyga> pedronis: 18.04?
<pedronis> yes
<zyga> perfect, thank you
<mborzecki> zyga: isn't this because of preserved mount namespaces?
<zyga> no
<zyga> well
<zyga> I don't think so
<zyga> it's more involved
<zyga> the most surprising part is the deleted element
<zyga> but let me write a test first
<mborzecki> zyga: deleted seems fine to me, iirc association of a file with a loopback device is done using a file descriptor
<zyga> mborzecki: it's not fine
<zyga> IMO
<zyga> but let's check out little by litte
<zyga> it only happens when the parent dentry is removed AFAIR
<pedronis> zyga: is this the highest priority thing on your plate?
<zyga> pedronis: in terms of wrapping up, it's what I was doing anyway but I was chasing logs from runs, this gives me an idea for a test to write, maybe it will uncover the bug more directly
<pedronis> mborzecki: they are not mounted anywhere
<zyga> though there are two separate sides here, losetup deleted vs mountinfo deleted
<pstolowski> Chipaca: do you know what's the status of https://bugs.launchpad.net/snapd/+bug/1804245 ?
<mup> Bug #1804245: empty response from store when throttled allows switch to nonexistent track <snapd:New> <https://launchpad.net/bugs/1804245>
<Chipaca> pstolowski: I think i fixed that one :-) updated the bug to reflect
<pstolowski> good :)
<Chipaca> i just need to confirm
<Chipaca> i was wrong i think
<Chipaca> digging
<pstolowski> zyga: this can be closed? https://bugs.launchpad.net/snapd/+bug/1805866
<mup> Bug #1805866: On core18 system core18 snap was mounted after snapd had started <snapd:New> <https://launchpad.net/bugs/1805866>
<zyga> pstolowski: no, why?
<zyga> it's a real bug IMO
<pstolowski> zyga: ok, it's very old, i assumed it was fixed as otherwise we would probably see it more?
<zyga> pstolowski: we don't really boot that often with services, not on classic systems
<pstolowski> ok, fair enbough
 * pstolowski is stepping down from triaging job for now
<jamesh> zyga: is there anything else needed to get https://github.com/snapcore/snapd/pull/6767 merged?
<mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
<zyga> jamesh: no, just need to finish my review
<jamesh> zyga: okay, thanks.
<Chipaca> pstolowski: confirmed, fixed in 6ce906f7df2
<pstolowski> Chipaca: ty!
<Chipaca> updating the bug
<mup> PR snapd#7396 opened: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
<zyga> pstolowski: I replied to https://github.com/snapcore/snapd/pull/7392#discussion_r320176487 -- let me know if that's okay in your eyes
<mup> PR #7392: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7392>
<zyga> pstolowski: I'm happy to have a follow up
<pstolowski> zyga: ty, replied
<zyga> woot, thanks.
<mup> PR snapd#7392 closed: tests: rewrite "retry" command as retry-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7392>
<zyga> is there anything we could retry that would help us?
<zyga> snap install from the store perhaps
<zyga> any ideas?
<zyga> though that retries internally so perhaps no
<zyga> pstolowski: I cannot immediately reproduce the error with leaking loopback device
<zyga> I was wondering if being base is somehow more special
<zyga> but then the bug report did include telegram-desktop
<zyga> it may also be a more recent-ish environment (a rolling distro)
<zyga> I'll run my test on 16.04 and look at finishing some of reviews instead
<zyga> pstolowski: ^ quiet in 7397
<mup> PR snapd#7397 opened: tests: add --quiet switch to retry-tool <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
<pstolowski> zyga: right, i couldn't repro loopback issue either. perhaps we need to observe our systems more close for some time
<pstolowski> zyga: thanks for 7397!
<zyga> it means we are missing something though :)
<zyga> it's going to be good when we finally understand what it was
<zyga> pstolowski: I updated https://github.com/snapcore/snapd/pull/7256
<mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<mup> PR snapd#7398 opened: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
<mup> PR snapd#7399 opened: tests: verify retry-tool not retrying missing commands <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
<zyga> pstolowski: replied on https://github.com/snapcore/snapd/pull/7397#discussion_r320200634
<mup> PR #7397: tests: add --quiet switch to retry-tool <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
<mborzecki> pstolowski: zyga: when that happens, aren't those devices listed in nautilus sidebar too?
<zyga> mborzecki: I have *never* seen that in my sidebar on TW
<zyga> but I did see some wonkiness in unity a while ago while using a 16.04 vm
<mborzecki> zyga:  i have, i recall asking someone during last sprint about that :)
<zyga> mmmm
<zyga> more interesting to see what causes it
<mup> PR snapd#7400 opened: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> mborzecki: speaking of mounting https://github.com/snapcore/snapd/pull/7400
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> I'm reviving that MS_SHARED bugfix but this is something I found in that branch
<zyga> it's a bit unusual in the sense that it is a fix for something that was hidden by lack of sharing
<zyga> but I proposed it ahead of actual sharing
<zyga> I explain why in the PR
<zyga> I should break for coffee and then really return to reviews or I will never get them done
 * Chipaca takes a break
<zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7397#discussion_r320206281
<pstolowski> mborzecki: i think the reporter of that bug mean that when he said gnome file manager
<mup> PR #7397: tests: add --quiet switch to retry-tool <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7397>
<mborzecki> pstolowski: nautilus?
<pstolowski> mborzecki: on my 18.04 box i only have cli so can't verify; on full-blown 19.04 i couldn't reproduce in my short tests
<pstolowski> mborzecki: yes, nautilus
<mborzecki> woo, it's called files now :/
<zyga> files :)
<zyga> nice
<mborzecki> and i keep on typing nau.. in the search
<zyga> until it becomes folders ;)
<zyga> after coffee / reviews I'll change my test to refresh bases while running various apps
<zyga> and see what happens then
<zyga> pstolowski: trivial quickie https://github.com/snapcore/snapd/pull/7399
<mup> PR #7399: tests: verify retry-tool not retrying missing commands <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7399>
<zyga> this is also pretty obvious but I was unsure if there are any side effects
<zyga> https://github.com/snapcore/snapd/pull/7396
<mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
<zyga> though it feels like the original code was just buggy anyway
<zyga> mborzecki: is my reasoning correct? https://github.com/snapcore/snapd/pull/7396#discussion_r320208075
<mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
<zyga> mvo: can you please finish the review of https://github.com/snapcore/snapd/pull/7362
<mup> PR #7362: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>
 * zyga breaks
<pstolowski> good idea
 * pstolowski lunch
<pstolowski> pedronis: #7092 seems to be happy
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
 * Chipaca goes for lunch
<mvo> 6705 needs a second review now
<mvo> zyga: will do after lunch
<mborzecki> zyga: updated #7387
<mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<pedronis> Chipaca: comment on #7398
<mup> PR #7398: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <https://github.com/snapcore/snapd/pull/7398>
<pedronis> *commented
<mborzecki> zyga: duh, mounts do not look nice when there's more snaps installed https://paste.ubuntu.com/p/BHvpFx7P3X/
<mborzecki> zyga: ok, updated #7302 too
<mup> PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>
<mup> PR pc-amd64-gadget#19 closed: UC20 spike changes <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/19>
<cachio> mvo, pedronis  I need to skip the standup, perhaps arriving late but not sure, forgot I had a meeting in the school
<zyga> mborzecki: seeing double :)
<zyga> mborzecki: I have an idea about that
<zyga> mborzecki: but in the evening after round of reviews
<zyga> mborzecki: for tomorrow, ok?
<ogra> jdstrand, i have a problem ... trying to use a DHT11 sensor (temp/humidity) and output to an OLED display on a Pi3 with https://github.com/adafruit/Adafruit_Python_DHT ... i end up with https://paste.ubuntu.com/p/Z7PDBTCjkb/ ... could we add these paths to "hardware-observe" ?
<Chipaca> pedronis: interesting comments
<rbasak> I'm using Docker to run snapcraft inside Travis. Is there anything I need to do to switch to using core18?
<rbasak> Currently I'm doing: docker run -v $(pwd):$(pwd) -t snapcore/snapcraft sh -c "apt-get update -qq && apt-get install -qq git && cd $(pwd) && snapcraft"
<rbasak> I'm wondering if I need to use a different Docker image based on Bionic?
<Chipaca> rbasak: use core18 for what?
<Chipaca> does snapcraft in docker not use multipass?
 * Chipaca doesn't know
<Chipaca> i imagine not, in which case yeah you'd need a bionic image
<rbasak> Chipaca: to base my snap on core18 I mean. Ie. "base: core18" in snapcraft.yaml AIUI. Yes - that's what I was thinking.
<rbasak> Is there a published snapcraft-that-uses-bionic image?
<Chipaca> rbasak: I don't know. Maybe sergiusens does?
<zyga> cmatsuoka: can this land? https://github.com/snapcore/snapd/pull/7266
<mup> PR #7266:  recovery: update run mode variable name <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>
<cmatsuoka> zyga: on the uc20 branch, yes
<cmatsuoka> zyga: thanks
<zyga> cachio: hey, I pushed into the XDG branch of yours
<zyga> cachio: I also opened something small for your consideration: https://github.com/snapcore/snapd/pull/7396
<mup> PR #7396: tests: don't guess in is_classic_confinement_supported <Created by zyga> <https://github.com/snapcore/snapd/pull/7396>
<cachio> zyga, nice, thanks
<jdstrand> ogra: it is likely fine. they are binary files. add to the list for the next round. thanks!
<jdstrand> added*
<zyga> jdstrand: hello :)
<jdstrand> zyga: hi :)
<ogra> jdstrand, thanks !
<ijohnson> rbasak: there is not, you will need to roll your own docker image
<ijohnson> rbasak: if you're building on travis, it is probably much easier for you to just build with lxd and call snapcraft from your job definition directly, travis supports running snapcraft as a snap and lxd as a snp
<rbasak> ijohnson: OK, thanks.
<rbasak> ijohnson: do you know of any examples?
<ijohnson> rbasak, sure one minute
<ijohnson> rbasak: take a look at one of the snapcrafters snaps at https://github.com/snapcrafters/sdlpop/blob/master/.travis.yml
<rbasak> ijohnson: that's great. Thank you!
<cachio> zyga, #7256 needs a +1
<mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
<cachio> pstolowski, could you please take a quick look to #7256
<pstolowski> cachio: yes
<cachio> pstolowski, tx
<pstolowski> cachio: looks good but as i said in earlier comment i think we should wait for it to fail again an see if #7336 shows anything interesting
<mup> PR #7336: tests: add debug section to interfaces-contacts-service <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7336>
<roadmr> jdstrand: hi are you around? I have a question :) {"docker": {"allow-auto-connection": "true"} <- this implies allow-installation, right? so a snap with this in the plugs section should automatically pass review, not be held with human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (docker, docker)
<cachio> pstolowski, ok, I'll try to force the error
<cachio> pstolowski, otherwise it will take too much time
<pstolowski> cachio: force how?
<cachio> pstolowski, retrying execution
<cachio> until it fails
<pstolowski> cachio: ok
<cachio> and praying
<cachio> heheehe
<pstolowski> heh
<jdstrand> roadmr: it does not imply allow-installation
<roadmr> jdstrand: ah, ok. That makes sense
<pedronis> it does for snapd
<jdstrand> roadmr: in snapd, auto-connection, connection and installation are all separate from each other. the review-tools only look at auto-connection and installation for when to manual review
<roadmr> jdstrand: did this change? did it imply installation?
<pedronis> it doesn't respect the conventions though
<jdstrand> roadmr: nothing has changed for months
<roadmr> jdstrand: (context, someone is saying that a snap for which they have the above used to pass automated review but then started failing
<roadmr> )
<jdstrand> roadmr: right, months ago it was discovered that we weren't prompting for manual review for the docker interface when we should have. it changed then
<jdstrand> roadmr: there were a handful of snaps that were affected. they must not have uploaded anything in a while
<roadmr> jdstrand: like, 2 months ago? we narrowed the transition down to "2019-06-17 13:55 - 2 months, 2 weeks ago"
<roadmr> jdstrand: perfect, that explains it :) do you mind if I give them allow-installation? this is a snap in a brand store and they'd been using docker previously
<jdstrand> roadmr: 693121ef4ad15a0642967d5f7af69e52c1b8969d. Feb 15
<roadmr> oh that's more than 2 months ago :)
<jdstrand> pedronis: I guess it makes sense that allow-auto-connection implies installation as a practical matter, but that is not how we initially designed the feature. do you recall when that changed?
<nessita> roadmr, the date would be relevant for our bump of review tools though, not necessarily when the review tools changed
<nessita> (hi all!)
<pedronis> jdstrand: it's always been like this
<jdstrand> pedronis: oh, you mean because if it has nothing to say about installation, it is allowed
<pedronis> yes
<roadmr> nessita: indeed, but the gap is still puzzling - we certainly updated the tools between February and June, so it's weird this only started happening in June if the change was in the tools since Feb
<nessita> roadmr, right
<nessita> roadmr, have you, by any chance, downloaded the two revisions to compare if they changed anything in their manifest?
<roadmr> nessita: nope
<jdstrand> pedronis: right. that is different than auto-connection affecting installation if something does have something to say about it, which is what I meant
<jdstrand> anyhoo, yes
<jdstrand> roadmr: can you paste me their snap.yaml?
<roadmr> jdstrand: sure, incoming
<roadmr> jdstrand: https://pastebin.canonical.com/p/WJyNTTKQ8X/
<ackk> hi, testing with the confined maas snap and snapd 2.41, I'm getting https://paste.ubuntu.com/p/cJxN7B4KpP/ all of a sudden, what could it be related to?
<zyga> ackk: woah
<zyga> ackk: is it /root?
<ackk> zyga, what is?
<zyga> I think it might be confused by root :)
<zyga> ackk: there's a check that $HOME is not something crazy
<zyga> ackk: but it may not capture /root
<ackk> zyga, yeah "maas --help" works but "sudo maas --help" doesn't
<zyga> Chipaca: ^ is that us?
<zyga> Chipaca: if so that's a regression
 * jdstrand notes that when to manual review is a different question than when to apply at install time
<zyga> mvo: ^
<ackk> zyga, oddly, I had just run "sudo maas init" a little before, and that must have worked
<zyga> huh
<zyga> that's more mysterious
<ackk> lemme try a reproducer
<mvo> zyga: thanks, in a meeting
<zyga> ack
<Chipaca> ackk: what distro?
<zyga> ackk: thank you
<ackk> Chipaca, bionic
<mvo> zyga: but thanks for the heads up, please keep me updated about your finidings
<Chipaca> sudo's path should have /snap/bin on it
<mvo> might be the new systemd generator?
<Chipaca> (some distros have it in bash but not in sudo which is weird)
<Chipaca> ugh
<zyga> https://github.com/snapcore/snapd/blob/fa465e97df3b159f18c77786cdc540d2cdcd29d5/cmd/snap-confine/user-support.c#L44
<mvo> which went in with 2.41 but only in the debs
<ackk> Chipaca, I'm pretty sure cloud images don't
<Chipaca> ackk: don't what?
<ackk> Chipaca, I'm in a lxd
<ackk> don't have /snap/bin in path
<ackk> at least, not for root
<ackk> oh actually it seems they do now
<Chipaca> ackk: in 'sudo visudo', you should see /snap/bin in 'secure_path'
<zyga> I just shut down my desktop
<zyga> but https://github.com/snapcore/snapd/commit/634a17c85718f15babe9fbe3cd85a36225bcfdd3
<zyga> it could be a good attempt to add a /root home directory there to see what happenns (in spread test)
<Chipaca> ackk: maybe you installed snapd, and didn't re-login?
<ackk> Chipaca, it's there
<ackk> Chipaca, nope, that's not a fresh container
<ackk> I'm testing now in a fresh one, see if I can reproduce
<jdstrand> roadmr: because of that ^ the tools look at the slots side for both *for slots that specifiy an installation constraint in the base decl*. the base decl convention for docker here is that a slot implementation may provide a so-called superprivileged interface but another impl of the same slot might not. again, change was intentional
<roadmr> jdstrand: ah ok - got it
<ackk> Chipaca, I did relogin just now fwiw, no difference
<jdstrand> roadmr: oh, and the review-tools error is correct for that snap.yaml
<jdstrand> s/correct/expected/
<roadmr> awesome :) yes, just looks like behavior changed here and we didn't update the PD - I'll add allow-installation for them
<roadmr> (behavior changed expectedly as you explained)
<jdstrand> cool, thanks
<roadmr> thank you for explaining :)
<roadmr> I mean, it was pretty clear we needed to add allow-installation, the message says as much and fwiw I usually add both anyway - just wanted to understand why this changed
<jdstrand> roadmr: speaking of the review-tools, can you pull 20190829-1435UTC? not urgent. only meaningful change for the store is sr_lint.py: improve error message with invalid Icon paths
<roadmr> jdstrand: sure thing!
<jdstrand> thanks :)
<ppd1990> jdstrand: Hi, I'd be glad if you could weigh in on #7366 in the near future :) Am still in the office for a few hours with a little spare time for possible changes
<mup> PR #7366: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <https://github.com/snapcore/snapd/pull/7366>
 * cachio lunch
<doko> mvo: snapcraft autopkg test regressions in eoan
<jdstrand> ppd1990: yes, it is on my list for today. note there is some history that I need to dig up for why it is the way it is
<mvo> doko: hey, thanks for the heads up - sergiusens will take care of it I'm sure!
<doko> mvo: well, it would be nice if the snappy team would notice these regressions on their own  by default ...
<mvo> doko: right, I hear you and we try to be responsive. snapcraft is a different team though,
<popey_> sergiusens: ^ see comments from doko
<mvo> second review for 6705 would be great btw
<mvo> ackk, zyga, Chipaca still in meetings - is there a tl;dr on this potential regression?
<zyga> mvo: no, I took a break but I just stopped and writing a quick regression test
<ackk> mvo, I don't have a clean reproducer but it seems related to the fact that I was ending up running snapcraft --destructive-mode with the snap mounted from the prime dir, so maybe that ends up confusing snapd?
<mvo> ta
<mvo> thanks! please keep me updated, if it turns out to be a regression I want to know as soon as possible
<zyga> mvo: understood, sorry for lagging
<mvo> zyga: no worries! it was not meant as being pushy :)
<rbasak> What's the production status of core18? https://forum.snapcraft.io/t/ubuntu-core-18/5169 suggests it's experimental?
<popey_> rbasak: that's a very old post
<rbasak> It's the second hit for "snap core18" on Google.
<rbasak> The first hit goes to the store page which doesn't answer my question.
<pedronis> mvo: I will look at #6705 in my morning, slightly surprised by Chipaca's comments on it
<rbasak> I can't find any announcement that says that core18 is production now?
<mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
<Chipaca> I will go for a run now and stop surprising people
<mvo> Chipaca: enjoy!
<zyga> Chipaca: +1
<mvo> pedronis: I will fix the things that john mentioned, its a good point
<mvo> (good points)
<zyga> ackk: hey
<zyga> still around?
<zyga> ackk: what does "sudo env" say in that machine where it happened?
<zyga> ackk: feel free to paste in private if sensitive
<cwayne> rbasak: https://ubuntu.com/blog/ubuntu-core-18-released-for-secure-reliable-iot-devices
<cwayne> top of https://ubuntu.com/core too
<rbasak> cwayne: great. Thanks!
<cwayne> np :)
<mup> PR snapd#7399 closed: tests: verify retry-tool not retrying missing commands <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7399>
<ackk> zyga, https://paste.ubuntu.com/p/gDNq93zrPC/
<zyga> ackk: can you walk me through a case
<zyga> ackk: this is inside a container, correct?
<ackk> zyga, yes
<zyga> ackk: how do you access the host of the container, via ssh?
<zyga> ackk: when you access the container, how do you "jump into" it, via lxc shell?
<ackk> zyga, via ssh, but I have my home bind-mounted in the container, so I ssh with the same user
<zyga> ackk: bind mounted from the host of the container?
<zyga> ackk: so you ssh into (guest) from (host) or from a different machine?
<ackk> zyga, https://paste.ubuntu.com/p/XNq6w2sVGQ/
<ackk> zyga, no, ssh from my laptop to the lxd on it
<zyga> ackk: so (3rd computer) -> (guest) directly, via ssh?
<ackk> zyga, why 3rd computer? the containres are on my laptop as well
<zyga> ah, I understand now
<zyga> so you ssh from the laptop, which is the host, directly into the container
<ackk> zyga, correct
<zyga> ackk: and inside the container, so in (guest), the user ack exists because it was added manually?
<ackk> zyga, yes
<zyga> ackk: and when you run sudo maas, snap-confine complains and quits
<zyga> ackk: this is on 2.41 from the archive?
<ackk> zyga, 2.41 snapd snap
<ackk> from beta
<zyga> aha, the snapd snap
<zyga> ok, thank you
<zyga> let me check stuff
<zyga> can you run one simple test
<zyga> snap install snapd-hacker-toolbelt
<zyga> and see if that works
<zyga> it's just a busybox snap
<ackk> zyga, so, also the issue doesn't happen right away as I mentioned before. I have the snap installed via snap try, but was then running a sync target which ended up calling snapcraft again
<ackk> zyga, sure
<ackk> zyga, just run it?
<zyga> yeah
<zyga> so maas is in try mode?
<ackk> zyga, yes
<zyga> what is a sync target?
<ackk> zyga, (that snap works fwiw)
<zyga> ackk: can you try to unsquashfs snapd-hacker-toolbelt, edit it anyway you like (it's a static binary),
<zyga> ackk: install it in try mode
<ackk> zyga, so we have a makefile target that updates the prime/ dir based on the tree, so you can change code and have it copied. but that because of a recent change ended up calling "snapcraft --destructive-mode prime" again
<zyga> and see if you can reproduce the issue somehow
<ackk> zyga, it seems after that the snap had the issue
<zyga> so there are two aspects
<zyga> the message we saw indicates that we failed
<zyga> the details only change the error message printed
<zyga> so even if /root was handled in that logic, it would at most affect the failure message
<zyga> the reason we saw that particular message is that we got EROFS
<zyga> so we attempted to create a directory but got an EROFS error from the system
<zyga> we can strace that to see what exactly failed
<zyga> ackk: actually
<zyga> ackk: if you can still reproduce it
<zyga> please set SNAP_CONFINE_DEBUG=yes
<zyga> and run that command again
<ackk> zyga, where in the calling shell?
<zyga> that will tell us all the details without the need of strace
<zyga> ackk: after sudo
<zyga> sudo SNAP_CONFINE_DEBUG=yes maas --help
<ackk> oh ok, I don't have it right now but will try to reproduce tomorrow
<zyga> ackk: so whatever really happened, it seems something has switched your home directory, or /root to read only mode
<mup> PR snapcraft#2695 closed: spread tests: install package marker into ament index <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2695>
<jdstrand> roadmr: sorry, can you pull 20190903-1746UTC? not terribly urgent, just an update to an override for core20
<jdstrand> xnox: fyi ^
<roadmr> jdstrand: sure, her it goes
<jdstrand> roadmr: thanks!
<sergiusens> doko: mvo I did an upload last week and it was all green
<mup> PR snapcraft#2697 opened: Neon extension <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>
<mup> PR snapd#7401 opened: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
<diddledan> yootoobe: https://youtu.be/cWlYe0CE2iU
<mup> PR snapd#7402 opened: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>
#snappy 2019-09-04
<jamesh> amurray: out of interest, was there some project in particular you wanted debug symbols for?
<amurray> jamesh: I have a couple reports of crashes of my emacs snap and I am stumped how to easily enable users to get good backtraces
<jamesh> we definitely want debug symbols for the snaps seeded on the desktop
<jamesh> but there's not much to be done when they want a full design for snapcraft+store+snapd before considering any changes
<amurray> jamesh: understood this is a "hard problem" ... but if folks want snaps to be first-class on the desktop there needs to be more focus on this IMO from all parties - it's not enough to have just you pushing on it (but I am glad you were)
<jamesh> amurray: sure.  We've discussed it multiple times at previous dev summits, but when I've got more work to do than time available it is hard to prioritise something that gets ignored.
<amurray> jamesh: i hear you
<jamesh> I have gone back to update the first PR (https://github.com/snapcore/snapcraft/pull/2229) a few times to save it from bitrot, but that's about it
<mup> PR snapcraft#2229: elf: extract build ID and presence of debug info <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/2229>
<mborzecki> morning
<mborzecki> wow, +11C outside :/
<zyga> Good morning
<zyga> Wow, I have a few more so not that drastic yet
<zyga> Brrrrrr
<mborzecki> zyga: hey
<zyga> Doing school walk, be in the office soon
<Mirv> do apps like signal-desktop, spotify, discord work for you on Ubuntu under Wayland? none of them start for me on SUSE under Wayland, and I'm wondering whether there's some low hanging fruit to grap.
<Mirv> FYI https://pastebin.ubuntu.com/p/bSjqrJDhtf/
<Mirv> I tried to search for LP bug reports at one point but it didn't sound they'd be broken for everyone
<Mirv> Ubuntu defaults to X.org still so that makes it a bit different of course
<jamesh> Mirv: is Xwayland listening on the abstract namespace socket?
<Mirv> let me parse that for some time (or tell me how to check). it's running as /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -auth /run/user/1000/mutter/Xauthority -listen 4 -listen 5 -displayfd 6
<jamesh> i.e. @/tmp/.X11-unix/X0 in addition to /tmp/.X11-unix/X0
<jamesh> I think you can check with ss.  Let me work out the invocation
<jamesh> "ss -xl | grep X11" might be the best way to check
<jamesh> I see two listening sockets locally
<mborzecki> zyga: ^^ opensuse & wayland
<Mirv> there's @ too: https://pastebin.ubuntu.com/p/QVKJpjP26R/
<jamesh> I'm not sure then. The non-abstract socket is definitely blocked by snap confinement though
<Mirv> ok, let's wait for zyga then. I'm in no hurry, just starting my work day, happy to help debugging.
<zyga> back in the office now
<zyga> aha, I see the chatter about wayland and suse
<zyga> I _guess_ I'm running tumbleweed under X11, let me recheck
<zyga> logged back under wayland
<zyga> it fails on
<zyga> (and now no copy-paste, fun)
<zyga> on /run/user/1000/mutter/Xauthority
<zyga> I recall seeing this in a PR recently
<zyga> hold on
<zyga> Mirv: confirmed, adding an extra rule for that makes it work
<zyga> Mirv: is there a bug report? I'll handle the rest
 * zyga needs to work on reviews today
<zyga> good morning mvo
<mvo> hey zyga
<mvo> zyga: good morning! I also need to do reviews
<mborzecki> mvo: hey
<mvo> hey mborzecki
<abeato> morning! question about the content interface, is it possible to share only a file, or it must be a full folder?
<zyga> abeato: currently it must be a file but I have a patch to share single files stashed
<zyga> er
<zyga> must be a directory
<abeato> :D
<abeato> zyga, great, nice that we will have one file sharing soon, that will be useful if you want to share just a socker
<abeato> shocket
<zyga> sockets are more tricky
<zyga> not sure it'd work for sockets
<zyga> I have not tried
<abeato> hm, right, well, but in the end it is a file, right? mount bind should work too?
<zyga> ish,
<zyga> sockets have a tricky apparmor side
<zyga> anyway, it's a matter of checking
<abeato> right
<mup> PR snapd#7403 opened: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
<pstolowski> morning
<Mirv> zyga: there was not, I now filed bug #1842615
<mup> Bug #1842615 opened: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
<mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
<mborzecki> pstolowski:  hey
<Mirv> zyga: awesome :) meanwhile I checked the problem does not affect openSUSE Leap 15.0, so just Tumbleweed
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
<mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<zyga> Mirv: thank you
<zyga> mborzecki: yeah but I'll start with older PRs first
<zyga> or I'll starve them again :)
<ackk> zyga, hi, so I just ran into that issue again, and it doesn't have to do with snapcraft rewriting the prime dir: https://paste.ubuntu.com/p/BVDHmmCn48/
<zyga> ackk: that's interesting, can you mkdir /root/snap/maas/x1 yourself?
<zyga> ackk: or will you get a EROFS error?
<zyga> Mirv: I've updated the bug report and I'll be sending a PR to fix it later today
<ackk> zyga, the dir already exists
<zyga> ackk: is it a mount point?
<zyga> ackk: can you write through it?
<ackk> $ sudo ls -ld /root/snap/maas/x1
<ackk> drwxr-xr-x 1 root root 12 Sep  4 06:59 /root/snap/maas/x1
<mup> Bug #1842615 changed: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
<ackk> zyga, yeah I can write it as root
<ackk> I mean, write a file in it
<ackk> it's not a mountpoint
<zyga> let me look again
<zyga> that's odd
<zyga> ackk: can you please try this:
<zyga> sudo strace -o /tmp/strace.log SNAP_INSTANCE_NAME=maas
<zyga> /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
<zyga> not sure if free of typos
<zyga> but give it a try
<zyga> I'd like to see strace run of snap-confine
<zyga> to see what was the error it failed on
<ackk> zyga, that's all a single command right?
<zyga> correct
<ackk> strace: Can't stat 'SNAP_INSTANCE_NAME=maas': No such file or directory
<ackk> that can't go there, it seems
<ackk> I guess before the strace?
<zyga> sorry, my bad
<zyga> yes
<zyga> :)
<ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
<ackk> strace: exec: Permission denied
<Mirv> thank you zy_ga!
<ackk> zyga, ^
<zyga> ackk: _hmm_
<zyga> did I get strace wrong somehow
<zyga> ackk: and it didn't leave any log, did it?
<ackk> zyga, just http://paste.ubuntu.com/p/5VW47nhgv9/
<zyga> why would it do that?
<zyga> is that under lxd?
<zyga> perhaps thats why :/
<zyga> can you check on your host, if you got a denial in dmesg?
<Jonno_FTW> hello
<zyga> ackk: one more idea
<Jonno_FTW> I get this error: error: cannot add authorization: open /users/jonm/.snap/auth.json: permission denied
<Jonno_FTW> when my $HOME is on NFS
<zyga> ackk: can you install an older snapd and check if this happens?
<zyga> Jonno_FTW: hey, can you tell us the command you ran?
<zyga> Jonno_FTW: and snap version, please
<ackk> zyga, like, stable?
<zyga> yes
<Jonno_FTW> sudo snap install redis-desktop-manager, snap version 2.39.2-1.fc30
<mvo> ondra: hey, do you want to push your "lk-next" changes to "lk"? it seems you adrdress issues found in the review from chipaca?
<zyga> aha, fedora
<Jonno_FTW> yep
<zyga> mborzecki: ^ can you render ideas on how to check denials for selinux + nfs?
<ondra> mvo I will, once I test them :)
<ondra> I'm just flashing test image
<mborzecki> zyga: ackk: snap run --strace='--raw -o foo.log' maas if you can hit ^C in time
<zyga> mborzecki: that likely wont help if lxd is in control on top and denies it already
<zyga> mborzecki: I meant the case above from Jonno_FTW
<mborzecki> Jonno_FTW: can you try ausearch -m AVC and look for anything with recent time stamp
<ondra> mvo it is booting, so image prepare is working, I just want to run few core refresh tests
<ondra> mvo I already tested snapd snap update and that worked as well
<Jonno_FTW> mborzecki: there's nothing recent
<Jonno_FTW> certainly nothing from around the time I started using snap (like 30m ago)
<ackk> zyga, I can't switch to stable snapd as maas uses the system-usernames
<zyga> ackk: well, just for a test, it doesn't really have to work all the way
<zyga> just to see if this is something in 2.41
<mborzecki> Jonno_FTW: for the record, the error when you do snap login right?
<mborzecki> s/error when/error pops up when/
<ackk> zyga, mborzecki https://paste.ubuntu.com/p/D7Ddt4rZ6X/
<ackk> zyga, well it doesn't work at all as I get https://paste.ubuntu.com/p/rJ4pWKvQkC/ from snapd
<zyga> what's /snap/snap/bin/maas/current?!
<zyga> ackk: try without /snap/bin/maas, just maas
<zyga> I think that's snap run getting confused
<ackk> zyga, that's the first try there
<zyga> right, I just mean that /snap/snap is clearly wrong
<ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
<ackk> /usr/bin/strace: exec: Permission denied
<ackk> error: exit status 1
<zyga> ackk: on lxd host, can you run dmesg | grep DENIED
<zyga> I'm sure it's lxd
<ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
<zyga> ackk: that's excellent
<zyga> so that is confirmed
<zyga> ackk: to move forward we should figure out how to switch lxd's own profile on your host into permissive mode
<zyga> then we can debug forther
<zyga> *further
<zyga> ackk: do you think we can postpone until lxd developers are online?
<ackk> zyga, sure
<ackk> zyga, I don't have a real xenial host to test with unfortunately
<zyga> ackk: that's fine
<ackk> zyga, also when I tried installing maas snap from edge I didn't hit the issue, so i'm not sure what triggers it. I can run "maas init" and maas works fine, then something gets messed up
<ackk> but it might only happen in "try" mode, IDK
<zyga> the code where it fails should fail regardless of try mode
<zyga> I'd like to get to the bottom of this later today
<ackk> zyga, btw is there any chance that the snapfuse issue (taking 100%cpu in containers) could get fixed? that makes it impossible to install maas in a container
<ackk> (install from a snap and not from "try')
<mborzecki> zyga: pff the libtool patch fails on this https://paste.ubuntu.com/p/mGVnXnF5j6/ :/
<zyga> ackk: nobody on our team can fix that
<ackk> zyga, is it a kernel or lxd thing?
<zyga> ackk: please escalate that to get help
<zyga> ackk: perhaps both
<zyga> it's a fuse filesystem
<zyga> maybe the bottleneck is kernel side
<zyga> maybe userspace
<ackk> zyga, you're saying it's a bug in squashfuse?
<zyga> I don't think any of us really read that code
<zyga> ackk: it's certainly not a bug in snapd, we just mount a filesystem
<zyga> mborzecki: yeah I ran into that a number of times
<zyga> mborzecki: load of garbage :/
<mborzecki> duh, obviously there's no way to have misspell skip files :/
<zyga> mborzecki: sed it
<mup> PR snapd#7398 closed: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7398>
<zyga> mvo: I think we should all review from oldest to youngest
<zyga> it seems that the last two pages are like attic
<zyga> brb, tea
<mborzecki> zyga: added a workaround to #7403, other than that, all tests passed
<mup> PR #7403: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
<mvo> a review for 7125 would be great, small, self-contained and open since jul
<mborzecki> mvo: looking
<zyga> back with tea
<mvo> Chipaca: good morning! if you could have a look at 7383 that would be great (should be simple, just a msg tweak)
 * Chipaca looks
<Chipaca> mvo: good morning! I've been working for the last hour but having to restart x a few times to sort out some things
<Chipaca> fun with nvidia :-/
<mvo> Chipaca: no worries
<zyga> Chipaca: drivers?
<mvo> Chipaca: and good luck with X, I kinda given up on nvidia for this reason :(
<zyga> mvo: my ubuntu experience with 1030 was very good FWIW
<zyga> mvo: not so much with 2080, LTS doesn't have the drivers for it yet,
<mvo> zyga: to be fair my experience is ~1-2y old so I may be totally off
<zyga> mvo: I think it depends on how recent the OS is, there have been some great strides lately
<zyga> mvo: not sure if you remember this but a few weeks ago nvidia has opened a large number of specs for their hardware to aid nouveau
<zyga> mvo: it looks like early days of amd shift, when the tactic was to open up, but it was still a long road towards benefits
<Chipaca> mvo: zyga: i broke things by trying to update the drivers from a ppa, to get some games running â¦ undoing it was less than fun
<Chipaca> i'd forgotten how bad the quality of ppa debs was
<zyga> Chipaca: does your system work with 19.10?
<zyga> Chipaca: it's a good idea to just try that from a spare partition if it does
<Chipaca> zyga: I'm still waiting for confirmation it works with 18.04 :-/
<zyga> Chipaca: weekend evening project to check? :-)
<Chipaca> nu uh
<Chipaca> zyga: i've got way more fun weekend projects than updating a machine that works :-)
<zyga> that's fair :-)
<zyga> Chipaca: I played one game recently, control, strongly recommend it if you have the 3 evenings to finish it
<zyga> anyway, back to reviews :)
<mup> PR snapd#7396 closed: tests: don't guess in is_classic_confinement_supported <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7396>
<mborzecki> zyga: w8, 3 evenings? is that how long the game is?
<zyga> mborzecki: I think I played 6 hours each time
<zyga> well into past 3AM :D
<zyga> mborzecki: I just finished the main plot, there's more to do but that's enough for me
<zyga> mborzecki: or I'm just pretty good at aiming
<zyga> ;-)
<mborzecki> hahaha
<mborzecki> mad quake skillz? :)
<zyga> mouse sensitivity set to maximum, field of view 120, those things ;)
<zyga> just kidding though
<zyga> the game is story driven
<zyga> the combat is challenging but doesn't feel like grind
<zyga> and unlike most shooters I can remember, it is very rewarding to use the very first revolver you get all the game
<zyga> anyway
<zyga> something for evening :)
<mborzecki> zyga: fwiw, double barrel works in through all of doom too :P
<zyga> mborzecki: indeed, but that's an exception, here the game gives you one gun, sharing ammo across all forms, and as you play you unlock more forms that are more suited for specific type of combat; what it doesn't do is to give you a much better gun that obsoletes the first one
<Saviq> Chipaca: hey, you seem to know about snapshots, is it expected that `snap restore` does not restart the snap? is there something that can be done about that?
<Chipaca> Saviq: yes, it's expected; stop all services / apps before restore, start them after
<Saviq> kk
<Chipaca> Saviq: that is, if you need to
<Chipaca> Saviq: you don't always need to -- same as you don't always need to stop for a 'save'
<Saviq> Chipaca: yeah, which is why  it feels like there should be hooks for this :)
<Chipaca> Saviq: would a hook be able to know whether an app in the snap is running?
<Chipaca> (in general the answer is 'no')
<Saviq> Chipaca: an app, no, but a service, yeah
<Chipaca> (zyga's work wrt deferring refreshes while apps are running might let us fix that)
<Saviq> there's also https://forum.snapcraft.io/t/automatic-snapshot-opt-out/12131 - a `save` hook could reduce the size of the snapshot, but maybe it'd be better to have a whitelist for this particular usecase
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
<mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<pstolowski> mborzecki: sure
<mborzecki> thanks!
<zyga> jamesh: I finally reviewed https://github.com/snapcore/snapd/pull/6767#pullrequestreview-283483314
<mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
<jamesh> zyga: thanks.  Looking
<zyga> jamesh: I think my only comment that would warrant blocking are related to validation
<zyga> jamesh: on non-compliant files in meta/gui/icons
<zyga> jamesh: as well as on file sizes in that place
<zyga> jamesh: everything else is something that is good for followup
<zyga> jamesh: I'm moving on to the next review, please ping me with your opinion
<zyga> jamesh: as I said, you have +2 and you can merge as is
<zyga> jamesh: but I'm worried about opening a hole
<Chipaca> zyga: FWIW we already don't do that sort of validation on icons
<Chipaca> zyga: so it's independent from that work
<zyga> Chipaca: yes but now we read them into memory
<zyga> Chipaca: in this PR
<Chipaca> we do?
<Chipaca> where?
<zyga> ReadFile
<Chipaca> why do we ReadFile them?
 * Chipaca goes to look
<pedronis> because Ensure* does that internally
<pedronis> but I made a proposal in one of my comments
<zyga> https://github.com/snapcore/snapd/pull/6767/files#diff-1a7d1cbe7825f23c89fbefcac29f347aR82
<zyga> here
<zyga> perhaps one way to solve this
<mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
<zyga> is to extend ensure
<zyga> to give it a handle that knows what the content is
<zyga> and the size
<zyga> so they can be stream like
<ogra> oh ! gpio-control ? who breeded that ? (thats beautiful ! )
<zyga> that's a good idea separately but I would not like to just let this silently merge without pointing it out
<zyga> ogra: thank ondra
 * ogra thanks ondra 
<zyga> I'll keep doing reviews to unblock people, I said my thing
<ogra> ondra, beer for you in barcelona !
<zyga> pedronis: should I review https://github.com/snapcore/snapd/pull/6705 ?
<mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
<pedronis> zyga: I'm looking at it right now, going a bit slowly
<pedronis> also lunch
<zyga> ok, I'll pick up the next one
<zyga> mvo: hey, is https://github.com/snapcore/snapd/pull/6839 something that's ready for review?
<mup> PR #6839: devicestate: allow remodel to different kernels  <Remodel :train:> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6839>
<zyga> jamesh: this needs some comment feedback https://github.com/snapcore/snapd/pull/7073
<mup> PR #7073: interfaces: OpenGL/Vulkan drivers provided by a base should be usable <â Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7073>
<jamesh> zyga: I think the way forward for that PR was to relax the AppArmor rules for snaps using a base other than core/core18
<zyga> jamesh: indeed, can you please comment on it so that it's clear where we stand?
<jamesh> on the assumption that non bootable bases should only contain files that are intended for use by apps
<zyga> yeah, I recall the conversation about that in Toronto
<mup> PR snapd#7404 opened: cmd/snap: don't append / to snap name just because a dir exists <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7404>
<Chipaca> zyga: #7159 is an easy one
<mup> PR #7159: tests: add functions to make an abstraction for the snaps <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
<zyga> looking quickly
<pstolowski> pedronis: #7005 got 2 +1s and i adressed your earlier high-level feedback re having 'snap debug state..', would you like to take another look or can it land?
<mup> PR #7005: debug: state-inspect debugging utility <Created by stolowski> <https://github.com/snapcore/snapd/pull/7005>
<pedronis> pstolowski: it might be easier to land it and I play with it a bit once is in edge
<pstolowski> pedronis: ok, ty
<pstolowski> pedronis: i'm thinking of adding some kind of high-level simplified potential-conflict-checking command for it in the future, something rudimentary that doesn't try to replicate existing logic (because that could simply hide an existing problem), but rather list candidates for closer inspection. not sure if/how this will work in practice and how valuable it will be, but sometimes just filtering out irrelevant data
<pstolowski> from the state and setting initial focus is helpful
<zyga> jamesh: hey, question about https://github.com/snapcore/snapd/pull/7129#pullrequestreview-283531582
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> I know it's not your PR but do you know why we need to add a "get set sub-property API"?
<mvo> hm, tests are very red, shall we disable 19.10 for now?
<zyga> mvo: what is failing if I may ask?
<mvo> zyga: let me look again but pretty much everything is red
<zyga> like all tests are failing?
<zyga> I mean, there must be something that actually fails :)
<mvo> zyga: the samples I looked at this morning were 19.10 but let me re-look to see if this is actually still happening
<zyga> do you remember if a specific test was at fault?
<mvo> zyga: iirc desktop-portal but let me look again
<zyga> that fails uniformly though
<zyga> it fails on me every day, or close
 * mvo nods
<zyga> I'd be happier if we can disable the test instead
<zyga> and look at it really hard until we really understand why
<mvo> https://travis-ci.org/snapcore/snapd/pull_requests <- looks sad
<pstolowski> degville: hey! i'm looking for the best place to add documentation for snap unset and snapctl unset (and equivalents with 'set' subcommands followed by exclamation mark). seems like they need to go to https://forum.snapcraft.io/t/configuration-in-snaps/510 and https://forum.snapcraft.io/t/supported-snap-hooks/3795 ; do you know any better spot?
<mup> PR snapd#7405 opened: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7405>
<jwheare> zyga: re: 7129 my changes are almost entirely just repurposed existing code and style. i don't write go usually so feel free to make any stylistic changes you want
<jwheare> the reason i added GetSub was because i couldn't see a way in go to have multiple function heads with different numbers of arguments
<jwheare> (unlike say erlang)
<jwheare> without eliminating types and then doing dynamic type checks
<zyga> jwheare: hey, thank you for explaining that.
<zyga> I will look at this with new information after lunch
<degville> pstolowski: hello - thanks for looking! I think you're absolutely right about those locations - especially Configuration in snaps. We can always shuffle things around if the words fit somewhere better, but I think they're the best place for now.
<pstolowski> degville: great, ty! ok if if i just edit it there (new paragraphs/subsections) and you take a look afterwards?
<degville> pstolowski: yep - sounds good!
<pstolowski> ok
<ondra> ogra always ready for beer :P
<ondra> mvo sorry I was at dentist, back now and doing more testing
<ondra> mvo so far looks good
<ondra> mvo I will push changes from lk-next to PR branch
<mvo> ondra: sounds great, thank you
<ondra> mvo one more question, there is essential c header file, which should be implemented by corresponding bootloader, I was wondering where to host that header file
<ondra> mvo one option is to have it in bootloader/lkenv/snappy-boot.h
<Chipaca> hmm, is it always the same two 19.10 tests that are failing?
<ondra> mvo do you have any better idea where to host it?
<ondra> mvo OK there is problem with seeding with my test snap
<ondra> mvo I will debug, but it could be kernel seeding, when it tries to install bootimg
<Chipaca> a pox on google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
<ondra> mvo interesting is that it seems to panic when applying core18 security profiles though
<ondra> mvo I will need to create image with cloud init to log in though, first boot crash is a bit pain to debug as there is no good way to log in. So I will try update path now
<ondra> mvo ignore me, i think it's kernel seeding, it just happens right after core
<pstolowski> degville: i updated the snap get/set document, but the one about hooks & snapctl needs some more work i think, it's a little bare when it comes to snapctl
<degville> pstolowski: thank you! I'll take a look at set/get.
<mup> PR snapd#7406 opened: cmd/snap-confine: keep track of snap instance name and the snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7406>
<zyga> thanks!
<mborzecki> + '[' no = yes ']'
<zyga> test failed
<zyga> that's that ;)
<zyga> what printed that?
<mborzecki> zyga: google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
<zyga> our favourite test
<ijohnson> mborzecki: I saw the same thing on one of Chipaca's PR's last night
<ijohnson> I think it's a bug with eoan
<mborzecki> mhm, mvo has a PR disabling it
<mborzecki> for 19.10 at least
<ijohnson> mborzecki: also thanks for the review, I responded
<mborzecki> ijohnson: many dragons in snapstate handlers :) remember when i first dug into that
<ijohnson> yeah indeed!
<ijohnson> and yeah also not really sure about the `saveSnapDisabledServices` name either, it feels awkward, but I also need to do the same thing multiple places so I wanted to eliminate code duplication
<pedronis> mvo: ondra: commented on the lk PR
<ondra> pedronis thank you :)
<ondra> mvo found issue, we do not determeng run time mode correctly on device
<ondra> determine
<mup> PR snapd#7405 closed: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
 * ijohnson will miss SU again today, need to go with someone taking the citizenship oath :-)
<mvo> pedronis: thank you!
<zyga> mvo: https://github.com/snapcore/snapd/pull/7405/files#r320742967 ;-)
<mup> PR #7405: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
<zyga> geee I wish I made coffee before the call
<zyga> jwheare: so, a quick question on Get/Set DBus API
<zyga> jwheare: can the "setting" attribute  be like a obj.attr?
<zyga> that would allow us to have one get and handle everything with it
<zyga> jwheare: or perhaps / as I see the code already uses it
<mup> PR snapcraft#2698 opened: dirs: check for existence of required data directories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2698>
<ondra> pedronis I asked already mvo, but since you commented on it. I'd like to add c header file into lkenv dir for reference, otherwise I'm struggling to think about better place for it
<jwheare> zyga: i tried not to change existing apis
<mup> PR snapd#7403 closed: cmd: use libtool for the internal library <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
<Chipaca> degville, pedronis: https://twitter.com/jonworth/status/1169185705823735809
<jwheare> zyga: the / is used mainly just for logging strings tbh
<zyga> jwheare: I'm getting familiar with this area
<degville> Chipaca: ugh, thanks... if I squint, it looks like the sphinx. Riddle? Relic of lost civilisation?
<zyga> my idea was to drop the Sub methods
<zyga> and just allow more to be expressed by the property being interacted with
<mvo> zyga: re timeserver-control test - fun: https://paste.ubuntu.com/p/skNwxPPGGn/ - it looks like a version mismatch of the tools with the systemd version running
<jwheare> if you'd rather the api just be e.g. Check("default-url-scheme-handler/irc", "ircclient.desktop") or Check("default-web-browser", "browser.desktop") that's your call
<pedronis> mvo: fun not
<mvo> pedronis: yeah, so the timdatectl from the snap is 229 and does not (apparently) understand what 241 tells it
<pedronis> big mess actually, we'll need to think
<jwheare> i felt the more explicit separation of property/subproperty was a cleaner api, less magic, but i don't know the project
<Chipaca> degville: right click, view image, zoom in -- or look for the post where jon links to the svg :)
<jwheare> personally, i don't see more functions as a bad thing, in general
<pstolowski> Chipaca: yay, that's very helpful, ty ;)
<jwheare> but i have no strong feelings. if you think encoding the subproperty within the property string makes sense go for it :)
<sergiusens> pedronis: mvo sorry for insisting, but I wanted confirmation that the snapd snap builds fine with snapcraft from edge to fix  anything before another half complete release (I will start the release process with your green light)
<mvo> pstolowski: do you think you could double check if snapcraft from edge is fine with the snapd snap type?
<mvo> pstolowski: see the question from sergiusens
<sergiusens> ah, right, I did build pstolowski branch, if that is all you need, then we should be good to go (but ssome form of sanity test that could be run would be ideal)
<pstolowski> mvo, sergiusens i will
<pstolowski> mvo, sergiusens is it critical to check all build methods (lxd, multipass, destructive)?
<sergiusens> pstolowski: in general no, unless you use hardcoded paths (I fixed on in a PR last week)... if you do try either multipass (or lxd) and --destructive-mode
<zyga> mvo: because of change in formatting?
<zyga> I think I saw that
<mvo> zyga: yeah, I'm looking at it now
<mvo> zyga: hopefully not too hard to fix
<pstolowski> sergiusens: ok, thanks, i'm going to check this in a moment (with my branch)
<zyga> re
<zyga> mvo: any findings?
<mvo> zyga: in a meeting, but I see  [  503.301852] audit: type=1400 audit(1567605570.552:74): apparmor="DENIED" operation="capable" profile="snap.test-snapd-timedate-control-consumer.timedatectl-timeserver" pid=31856 comm="timedatectl.rea" capability=12  capname="net_admin"
<zyga> missing permissions, it seems
<mvo> zyga: yeah, I look some more after the meeting
<zyga> thank you
<cachio> mborzecki, Chipaca hey, could you please take a look to #7401
<mup> PR #7401: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
<Chipaca> cachio: yep
<cachio> zyga, hey, yesterday I saw you were taking a look to a problem related to the snapd snap right?
<Chipaca> cachio: nice
<cachio> zyga, it is the only concern I have before promoting this to candidate
<zyga> cachio: which specific problem, sorry - there were too many topics lately
<cachio> zyga, the one related to maas
<zyga> ah
<zyga> sorry, yes
<zyga> it's not a regression IMO
<cachio> zyga, the issue which you were discussing with ackk
<zyga> and it's specific to specific development flow
<zyga> I'd not block on it
<zyga> it's a UX issue, not a behavior change
<cachio> zyga, perfect, thanks for the info
<zyga> ackk: ^ FYI
<mup> PR snapd#7401 closed: tests: add unstable stage for travis execution <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
<mup> PR snapcraft#2699 opened: python plugin: add option to process-pipfile-lock for pipenv users <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2699>
<mup> PR snapd#7407 opened: tests: run failing tests on ubuntu eoan due to is now set as unestable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7407>
<jwheare> zyga: do i interpret your latest comment to mean you're happy with Get and GetSub etc being separate?
<zyga> yes, that's right
<jwheare> cool
<zyga> I'm reviewing technical details now
<zyga> it's close I think
<mup> PR snapd#7397 closed: tests: add --quiet switch to retry-tool <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7397>
<ackk> zyga, so you know what's causing that issue?
<zyga> ackk: no, but if you are around we can work on exploring more
<zyga> ackk: we need to switch the host's lxd profile to permissive mode
<zyga> ackk: and try strace again
<cachio> jamesh, hey, could you please take a look to the comment I left in #7351
<ackk> zyga, how do I do (and then revert) that?
<mup> PR #7351: tests: retry checking until the written file on desktop-portal-filechooser <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>
<zyga> ackk: I think you can do that in-memory
<zyga> using ...
<pstolowski> sergiusens: snapd from my PR built fine with multipass (i took a gooooood while to download all deps). i'm going to check destructive now
<zyga> ackk: there's aa-complain
<zyga> ackk: but really we want to find the profile on disk
<sergiusens> pstolowski: if what it built works,, then we are solid for moving forward :-)
<zyga> stgraber: where does lxd keep its apparmor profiles on disk?
<zyga> ackk: we need to edit one profile and add one word to make it advisory, not enforced
<ackk> zyga, how do I find it? I'm not very familiar with aa
<pstolowski> sergiusens: yeah i don't expect problem with destructive since that's already coverted by spread test in my PR.. but i can check manually for piece of mind
<zyga> ackk: unfortunately the kernel does not know so we just need to look around, hold on
<stgraber> zyga: /var/snap/lxd/common/lxd/security/apparmor/
<zyga> stgraber: thank you so much!
<zyga> ackk: let's look at that path please
<zyga> ackk: we want to change the profile that was denied
<zyga> stgraber: perhaps there's an easier way to allow strace inside a container?
<zyga> ackk: can you please remind me the DENIED line that you found then?
<stgraber> zyga: strace is allowed inside containers
<ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
<zyga> stgraber: we had a ptrace deny, perhaps it's more complex and two things together make it fail
<ackk> stgraber, ^
<ackk> stgraber, also, hi :)
<zyga> peer="unconfined"
<zyga> ackk: when you ran snap-confine manually,that was inside the container, right?
<zyga> ackk: along with sudo and strace
<zyga> all inside?
<ackk> yes
<zyga> ok
<zyga> do I read that right, that snap-confine itself is denying the trace?
<zyga> ackk: can you show me how to get to this stage? I can explore this locally somewhat faster perhaps
<ackk> zyga, well I'm not sure if you can get to that stage easily with the snap from the store
<stgraber> so we do have a ptrace restriction which prevents cross-profile ptracing to avoid cross-container security issues, I wonder if this is somehow triggering there
<zyga> ackk: I'm happy to get some fresh stuff from git and play
<zyga> stgraber: perhaps, I can just disable everything quickly locally to get to the bottom of the error that is masked behind this
<stgraber> ackk: "lxc config set NAME raw.apparmor ptrace," should allow everything
<ackk> zyga, so. you'd have to git clone lp:maas; build the snap and snap try it
<ackk> stgraber, I assume I need to reboot?
<ackk> (the container)
<stgraber> yeah
 * ackk tries
<ackk> thanks
<zyga> ackk: cloning
<zyga> ackk: so having maas cloned
<zyga> snapcraft?
<ackk> zyga, of course, after rebooting the container the issue went away :/
<zyga> ackk: oh?
<zyga> that's interesting
<ackk> zyga, yeah, I use --destructive-mode in the container
<zyga> can you rebuild maas
<zyga> and see if that breaks it again
<ackk> sure
<zyga> and then, re-run the sudo snap-confine strace line
 * Chipaca needs caffeine
 * Chipaca looks for something intravenous
<mvo> xnox: did timedatectl change in 19.10? when I run "timedatectl  set-ntp no" (or yes) the "timedatectl status" output does not change regardless of yes/no
<mvo> xnox: this is GCE so maybe this is relevant
<mvo> xnox: aha! so it looks like we have chronyc on GCE
<zyga> ooo
<zyga> mvo: so ntp is always on?
<zyga> ackk: any luck?
<mvo> zyga: sort of, yes
<mvo> zyga: anyway, I think I know what to do
<ackk> zyga, no, I rebuilt and installed the snap (via snap try), but it seems to work so far
<ackk> zyga, will try the strace if it happens again
<zyga> ackk: thank you
<ackk> zyga, still, that snap-confine line fails with permission denied
<ackk> although "sudo maas" currently works
<zyga> ackk: not with permission denied
<zyga> it's confusing
<ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
<zyga> if you look at the source
<ackk> strace: exec: Permission denied
<zyga> it has failed already
<zyga> ah, sorry
<zyga> that line does fail on strace and lxd
<Chipaca> hmm, i'm seeing repeated failures for google:ubuntu-{16,18}.04-64:tests/main/proxy-no-core
<zyga> that's strace being unable to execute snap-confine
<ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
<ackk> /usr/bin/strace: exec: Permission denied
<ackk> error: exit status 1
<ackk> zyga, ^ this one too
<zyga> yes, it's the same thing really
<xnox> mvo:  that.
<zyga> (snap run call strace)
<xnox> mvo:  they asked and we changed default to chrony
<xnox> mvo:  on gce
<ackk> zyga, ok
<JonelethIrenicus> can i change the default folder for snap configuration files?
<zyga> what does chrony do?
<zyga> JonelethIrenicus: which files?
<zyga> but most likely no, it's not very easy to do
<JonelethIrenicus> in ubuntu 19.04 it has a snap folder in the home directory
<JonelethIrenicus> it isn't a dot file
<zyga> there's a bug report for that
<JonelethIrenicus> ahh ok
<zyga> it's extremely hard to change
<zyga> I'm sorry
<JonelethIrenicus> all good
<JonelethIrenicus> just was curious why it was in my home directory like that
<zyga> JonelethIrenicus: this is bug https://bugs.launchpad.net/snapd/?orderby=-heat&start=0
<zyga> and I do intend to fix it
<zyga> b
<zyga> but to fix it properly I need to build enough infra to be able to move it first
<JonelethIrenicus> awesome thanks
<zyga> without breaking people
<zyga> so it's a bit slow
<JonelethIrenicus> right
<mvo> xnox: thanks, I will fix our test then
<zyga> I'm burned out with reviews today
<zyga> I'll switch to coding
 * Chipaca hugs zyga 
<zyga> thanks Chipaca
<zyga> writing is easier than reading
<zyga> you know what you meant up front :)
<ondra> pedronis are you OK for me to resolve comments which I already addressed? like change of error messages? Or are you gonna resolve those yourself?
<pedronis> ondra: I can do it
<pedronis> Chipaca: mborzecki: I proposed something in #7402 inspired by maciej ideas
<ondra> pedronis thanks, just want to clean it a bit, so I can see which comments still need work
<mup> PR #7402: daemon, client, cmd/snap: include architecture in 'snap version' <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>
<Chipaca> pedronis: we could think of (someday) adding cloud info there also
<Chipaca> not sure if there's a uniform way of finding out what cloud you're on (maybe via cloud-init or sth)
<ondra> mborzecki do you have good example of gadget yaml to update to update assets
<ondra> mborzecki forum post seems to be missing good example
<mup> PR snapd#7408 opened: tests: fix interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7408>
<pedronis> ondra: done
<pedronis> Chipaca: we do get that info
<tomwardill> hi! I'm trying to install snaps inside a xenial lxd, but getting "system does not fully support snapd: apparmor detected but insufficient permissions to use it". Is there a fix?
<ondra> pedronis thanks
<pedronis> Chipaca: it's a bit too much info tough, people might want not to tell us
<ondra> pedronis what do you think about option to add header file to snapd repo?
<ondra> pedronis or what is best place to have that reference header file?
<zyga> ondra: would that header file ship with snapd binary
<zyga> ondra: or just in the source repo
<ondra> zyga just in source
<ondra> zyga it is reference which should be used by bootloader
<zyga> I see
<Chipaca> pedronis: fair
<Chipaca> i'm off to the gym, will bbl
<ondra> zyga so data structure used by snapd and bootloader is in sync
<zyga> ondra: put it in a manual page
<zyga> ondra: on the forum :)
<ondra> zyga I want it somewhere from where it's easy wget
<zyga> ondra: why?
<pstolowski> sergiusens, mvo: both multipass and destructive-mode builds worked with type:snapd + build-base:core ð
<zyga> would you expect people to wget it constantly?
<zyga> because it changes all the time
<ondra> zyga as this is also needed at gadget build time, when device pre-populated env should be generated
<zyga> ondra: no, it's not
<zyga> ondra: what is needed is the structure or other type it defines
<zyga> ondra: hence my question
<zyga> ondra: is it expected to change often?
<zyga> ondra: what happens when it changes
<ondra> zyga no it does not change, but file is used by around, and I want it to be in sync
<zyga> ondra: keeping it in easy-wgettable place doesn't seem to solve any issues
<zyga> ondra: you cannot have both :)
<zyga> ondra: I think that's more important than where it is
<zyga> ondra: what happens when, eventually, it must change
<ondra> zyga if it changes, it will likely be new file, as it will have new version
<zyga> ondra: then you don't need to wget it
<zyga> it's fine to document as if it was a manual page
<zyga> because it's fixed forever in stone
<zyga> just make sure to name it, v1
<ondra> zyga so new version will be new file, this file is essentially set in stone once snapd adopts it
<ondra> zyga that's why I want single place to get it from
<zyga> I think that's the essential information
<zyga> thank you
<ondra> zyga OK where can I have it, so I can wget it?
<zyga> ondra: anywhere, because it's a constant now
<zyga> ondra: just make sure not to accidentally make go build it
<ondra> zyga so can I add it to snapd repo? :P
<zyga> ondra: go is tricky for that
<zyga> ondra: include/ perhaps (we don't have it yet)
<ondra> zyga if I only add it there, how do I make sure it's not go build?
<zyga> ondra: don't add any go files there
<ondra> zyga I though to have it right next to go version, so bootloader/lkenv/
<zyga> that's not godo
<zyga> *good
<zyga> it might get pulled for cgo build
<ondra> zyga hmm
<ondra> zyga so creating include directory?
<zyga> ondra: yeah, it seems like that to me
<ondra> zyga OK I will add it there
<ondra> zyga goog idea
<zyga> not a guarantee it will pass
<zyga> but let's see
<ijohnson> you could be tricky and add it to testdata
<zyga> I hope my comments were not snarky in reception
<zyga> I really did mean to point the light on the key issue of evolution
<zyga> because that's the hard part of this problem
<ijohnson> go ignores files in testdata, but it's not really test data so _shrugs_
<zyga> sharing an agreed structure is easy
<zyga> I'm near EOD
<zyga> looking at apparmor bits
<zyga> spread is spreading
 * ijohnson lunches
<mup> PR snapd#7409 opened: Allow a confined Wayland server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7409>
<diddledan> so you can now run the gimp snap in Windows: https://usercontent.irccloud-cdn.com/file/SXwtQQGd/image.png
<zyga> diddledan: is it stable? I had issues with the x server
<diddledan> I'm using the x server in mobaxterm
<mvo> thanks pstolowski|afk
<ondra> Chipaca please re-review my changes, I believe I have address those I commented on
<Saviq> sergiusens: is this error expected on a Pi? https://forum.snapcraft.io/t/building-for-core18-multipass-issue/8958/35
<Chipaca> ondra: will do (not right now tho)
<ondra> Chipaca thanks :)
<sergiusens> Saviq: I think ijohnson got the gist of it. This is why the meeting this Friday is important :-)
<sergiusens> Saviq: I am leaning to having that same image that is produced for multipass to be used for lxd on all architectures
 * ijohnson hopes the meeting on friday ends in snapcraft being able to make me a sandwich 
<ogra> Saviq, sergiusens, these images from friendlyarm are an awful hackish mess (and legal should really go after them for claiming this crap is based on UbuntuCore ... ) it is some self-debootstrapped rootfs with configs manually hacked up etc and somce home-brewed BSP kernel binary
<Chipaca> ijohnson: it can already make you a sandwich! the yaml is tricky though
<sergiusens> ogra: ah, interesting, but I will not go into any legal topic on a public forum :-)
<ogra> i wouldnt judge that an "error is expected on a pi" just because it fails on these hacked up vendor images
<ijohnson> I bet it uses those silly yaml anchors
<ogra> sergiusens, yeah, i shouldnt either it is just the third person on the forum in a month that has issues due to this "based on core" claim ... starts to really annoy me :)
<Chipaca> ijohnson: bÍÌ¥Ì¦ÌªÌaÌÌÍÌ«sÌeÌ«Ì¬Ì±Ì ÍÌ¬Ì¬:Ì¡Ì£Ì¦ ÌÍÌ¤ÍÌÌ¦Ì«{Ì·ÌÌ¥Ì±Ìº ÌÌ£ÍÌ¦ÌÌ¥<ÒÌÌ£Ì£Ì°<Í¡ÌªÌÌªÌ:ÌÌÌ¼ ÍÌÌ¥Ì®*ÌÍÍÌÌsÍÌºaÌ¦nÍ¡ÌÍÌ«ÍdÌ¯wÌ§ÌªÍÍÍiÌÍÌÌ¬Ì£cÌ·Ì¤ÍÌ»hÌ¹ÌÍ ÌÍÌÌÌ}Ì·Ì³
<Chipaca> or something like that
 * Chipaca is preparing dinner and might've gotten the zalgo wrong
<ijohnson> perfect
<zyga> jdstrand: hey, around?
<zyga> jdstrand: https://bugs.launchpad.net/snapd/+bug/1842615 came up today, the fix is one liner policy change
<mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
<zyga> owner /run/user/*/mutter/Xauthority r,
<zyga> I was meaning to add it but wanted to run it by you for a quick look
<mup> PR snapcraft#2700 opened: schema: build-base support for the kernel type <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2700>
<mup> PR snapd#7410 opened: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
<cachio> zyga, if you are there could tu please take a look to #7410
<mup> PR #7410: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
<cachio> it is blocking all the tests on travis
<zyga> done
<cachio> zyga, thanks!!!
<mup> PR snapcraft#2687 closed: colcon plugin: add ability to ignore packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2687>
<mup> PR snapcraft#2694 closed: multipass: fix setup exception when multipass is not found in PATH  <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2694>
<mup> PR snapcraft#2698 closed: dirs: check for existence of required data directories <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2698>
 * Chipaca hugs cachio 
#snappy 2019-09-05
<mup> PR snapd#7411 opened: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7411>
<zyga> good morning
<zyga> wow, I'm online _before_ maciek for once :)
<mborzecki> morning
<zyga> Hey Maciek :-)
<zyga> Start with reviews please
<zyga> There is a fix for master from Sergio
<zyga> Good morning mvo
<mup> PR snapd#7410 closed: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Simple ð> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7410>
<zyga> thank you mborzecki
<mborzecki> zyga: hey ;)
<mborzecki> mvo: morning to you as well
<zyga>     - google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser
<zyga>     - google:ubuntu-18.04-64:tests/main/proxy-no-core
<zyga> two failures of the day :/
<mborzecki> duh
<mvo> good morning mborzecki and zyga
<zyga> restarted already _today_
<zyga> oh well
<zyga> I'll rebase on the fix and try again
<zyga> mborzecki: I extracted https://github.com/snapcore/snapd/pull/7400 from the MS_SHARED bugfix branch
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> mborzecki: it's fairly isolated, except for apparmor changes (yuck)
<zyga> mborzecki: I'll add a ns test for writable mimic now
<zyga> last night while working on this I wrote DiffEquals checker
<zyga> it's like Equals but it requires text or error and it produces actual diffs
<zyga> I think it's fantastic and would be 99% of the benefit of whatever else we were using at the total line cost of about a dozen
<mborzecki> zyga: hmm i think the tests in snap-test.c using g_test_subprocess() are incorrect
<mborzecki> zyga: looking at this code right now, and we shouldn't be calling g_test_fail() in the subprocess when we expect the actual code-under-test to die :/
<mborzecki> zyga: fortunately the actual code is correct :P so it dies as expected
<zyga> mborzecki: oh, is that because we set the non-fatal failures?
<mborzecki> zyga: loo at the diff, https://paste.ubuntu.com/p/zKhcQ8gWgK/ we shouldn't be calling g_test_Fail() as it would mask the error case when the sc_draop_instance_key doesn't die() when we expect it to
<zyga> mmmm
<zyga> mborzecki: perhaps time to move away from die to sc_error
<zyga> it's so fragile to test that
<zyga> and error is so-much-nicer
<zyga> mborzecki: speaking of which
<zyga> I have a patch for mountinfo to use that
<zyga> I'll send it today
<zyga> it's been too long, it's half a year old by now
<zyga> mvo: I'll start slow, I stopped working past midnight
<zyga> mvo: see you at around 9:30 ish
<mvo> zyga: ok
<pstolowski> morning
<mup> PR snapd#7412 opened: tests: run dbus-launch inside a systemd unit <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7412>
<mborzecki> zyga: added some tests for sc_invocation, though will open a PR once #7406 lands
<mup> PR #7406: cmd/snap-confine: keep track of snap instance name and the snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7406>
<mborzecki> pstolowski: hey
<pstolowski> mborzecki: hi
<mborzecki> pstolowski:  can you take another look at https://github.com/snapcore/snapd/pull/7387?
<mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<pstolowski> mborzecki: yep, just need to finish another review
<mborzecki> pstolowski: sure, thanks!
<pstolowski> pedronis: hey, +1 on #7381 with a few minor remarks and two typo fixes
<mup> PR #7381: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <https://github.com/snapcore/snapd/pull/7381>
<pstolowski> mborzecki: would it make sense to move pack-source one level up (or somewhere else) since it's not fedora only?
<mborzecki> pstolowski: hm wasn't able to find a good place for it, doesn't really fit under reelase-tools
<mborzecki> pstolowski: maybe under packaging? $top/packaging/pack-source?
<pedronis> pstolowski: thank you
<pstolowski> mborzecki: yes, directly under packaging/ sounds good
<mup> PR snapd#7413 opened: hookstate/ctlcmd: fix snapctl set help message <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7413>
<pstolowski> ^ a trivial one line change of help string
<zyga> mborzecki: ack
<zyga> sorry, back now,
<zyga> I was sleeping
<zyga> feeling better now
<pedronis> pstolowski: I made some comments again in #7277
<mup> PR #7277: overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
<zyga> mvo: I'm commenting on https://github.com/snapcore/snapd/pull/7412
<zyga> oh wow
<mup> PR #7412: tests: run dbus-launch inside a systemd unit <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7412>
<zyga> that's quick :D
<zyga> mvo: retry-tool is new, usability ideas welcome
<mup> PR snapd#7404 closed: cmd/snap: don't append / to snap name just because a dir exists <Simple ð> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7404>
<jamesh> If it wasn't for xenial and centos 7, I'd suggest just spinning up a systemd user instance together with its bus
<mvo> zyga: I was tweaking things there anyway :)
<mvo> jamesh: yeah, its a bit of pita on these older distros
<pstolowski> pedronis: ty
<mvo> jamesh: i noticed serveral seconds of delay when doing "test-snapd-eds.contacs list" etc, this is normal, right?
<mvo> jamesh: I checked with both my version and the previous one and it seems to be no regression
<jamesh> mvo: is that every time or just the first time?
<mvo> jamesh: just the first time
<jamesh> so it might just be "evolution-data-server is slow to start"?
<mvo> jamesh: could be, its seconds and strace shows some sort of poll timing out
<mvo> jamesh: but its fine, I was just wondering
<pstolowski> zyga: looks like the problem is more common, fresh bug report: https://bugs.launchpad.net/snapd/+bug/1842521
<mup> Bug #1842521: Deleted snaps showing up in gnome-disks and nautilus sidebar <snapd:New> <gnome-disk-utility (Ubuntu):New> <https://launchpad.net/bugs/1842521>
<zyga> pstolowski: that's interesting
<zyga> it's an app snap that leaks then
<jamesh> mvo: I don't know specifically, but EDS is a bit over complicated
<mvo> jamesh: yeah, its fine
<jamesh> It's the kind of thing that could probably be a lot smaller if redesigned today, but there is no one to do it
<pstolowski> Chipaca: hey, can you take a look at https://bugs.launchpad.net/snapd/+bug/1838788? you're probably the best person to assess the validity and if it can be fixed
<mup> Bug #1838788: Pagination information not returned in /v2/find <snapd:New> <https://launchpad.net/bugs/1838788>
<pstolowski> (or if should be)
<pstolowski> zyga: app leaks? you mean app is stil running and holding the mountpoint?
<zyga> pstolowski: it's not a mount point
<zyga> it's a loop device
<zyga> it doesn't even have to be mounted
<zyga> just attached to a file (now deleted) on disk
<zyga> it's a different level of leak IMO
<pstolowski> zyga: i see
<zyga> I'll spend some time debugging that later, I'm adding tests for writable mimic now
<zyga> it's clear that it _is_ leaking
<pstolowski> ack
<pstolowski> slightly annoying it pollutes file manager like this
<zyga> no disagreement there
<pstolowski> uhm getting repetitive travis failures on desktop-portal-filechooser (i know this one has a PR from sergio), and two other tests failed to prepare on core16 and core18, it seems like snapd was not listening when it should be there already during prepare
<zyga> pstolowski: remember that bug where snapd starts before cores are mounted?
<zyga> maybe that happened?
<Chipaca> that happens every time in the core18 spread test (but it recovers afaict)
<Chipaca> if you run it manually you'll see snapd coming and failing to find core18's snap.yaml
<zyga> what's not great
<zyga> *that's*
<zyga> I need coffee, sorry guys, I'm very sleepy still
<pstolowski> Chipaca: thanks for updating the bug
<mborzecki> pstolowski: about that LP bug, that's what i mentioned seeing last time we discsused the problem
<Chipaca> pstolowski: I don't know how you manage to do triage erryday
<Chipaca> pstolowski: I'd be jumping out windows at this point
<zyga> Chipaca: if you were any closer I'd grab you for a bike ride together :)
<pstolowski> Chipaca: haha. not every day though.. and today i only looked at maybe 3 bugs
<zyga> Chipaca: a bit of a shame we live so far away
<zyga> Chipaca: I think the secret is that pawel's window is on the ground floor so he comes back rattled a little and carries on :D
<Chipaca> zyga: opening it before starting triage probably helps
<Chipaca> pstolowski: ssh, let me worship you without knowing the nitty gritty
<pstolowski> Chipaca: however.. it seems to me that just spending 15-30 minutes on it every day we can keep up the pace with any new bugs, so...
<zyga> *that's the sprit*
<pstolowski> :)
<pstolowski> Chipaca: one more related for you (and then i'll shut up): https://bugs.launchpad.net/snapd/+bug/1838786
<mup> Bug #1838786: Categories not returned in /v2/find results <snapd:New> <https://launchpad.net/bugs/1838786>
<pstolowski> sorry, two ;) https://bugs.launchpad.net/snapd/+bug/1838787
<mup> Bug #1838787: Website not returned in /v2/find results <snapd:New> <https://launchpad.net/bugs/1838787>
<Chipaca> i have a pr for the first one, some where
<pstolowski> Chipaca: didn't you also work on https://bugs.launchpad.net/snapd/+bug/1832767 at some point? or was it only some fixes for restricted characters?
<mup> Bug #1832767: snap info doesn't strip Markdown <snapd:New> <https://launchpad.net/bugs/1832767>
<Chipaca> pstolowski: i fixed it from the other end
<Chipaca> pstolowski: i'll update the bug
<pstolowski> thanks!
<pstolowski> mborzecki: i think we just need better help message to steer users
<mborzecki> pstolowski: in snap connections?
<pstolowski> mborzecki: i didn't remember the details of our discussions from one of the previous sprint. i had literally to play around with it to re-discover this ;)
<pstolowski> mborzecki: yes
<Chipaca> pstolowski: by "from the other end" i mean, the issue i addressed was _ugly_ markdown coming from the store, which we addressed by â¦ not sending ugly markdown :-)
<Chipaca> it can still be fairly ugly, but not full on eugh ugly
<pstolowski> mborzecki: so i can only imagine it's more confusing for users
<pstolowski> Chipaca: i see :). i thought i you meant you fixed it server side so it never sends or accepts it
<pstolowski> s/sends/returns/
<Chipaca> pstolowski: 'snap info firefox' has plenty of markdown
<Chipaca> it's just not too ugly
<pedronis> mvo: hi, is #6404 ready for re-review or not yet ?
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
 * zyga fixed one small bug and moves forward
<mup> PR snapd#7073 closed: interfaces: OpenGL/Vulkan drivers provided by a base should be usable <â Blocked> <Created by jhenstridge> <Closed by jhenstridge> <https://github.com/snapcore/snapd/pull/7073>
<mup> PR snapd#7414 opened: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<zyga> mborzecki: some feedback there
<zyga> mborzecki: I experimented with something similar, have a variant of that for dpkg that's somewhat weaker than yours
<zyga> mborzecki: I think we could join forces and craft something together
<mborzecki> zyga: sgtm, let me look at the apt-tool and your draft pr
<zyga> mborzecki: thank you
<zyga> mborzecki: if you want we can spin up a blank testbed-tool PR and land that quickly
<zyga> and add various measurement parts on top
<zyga> note that my PR does one essential change
<zyga> it fixes where we restore
<zyga> it's no longer causing the world to fall apart
<ogra> zyga, i see some weird behaviour using layuouts ... when using an install or configure hook to put a file into $SNAP_DATA and using a layout to map that file to a subdir in /etc i somehow end up with an empty file in $SNAP_DATA ... in what order do the hooks run in relation to layouts ?
<zyga> I think we should split that out as a small PR and land separately after careful review
<ogra> (looks like the copied file is overlayed by an empty one somehow, if i take the layout out of snapcraft.yaml i get a proper file as expected (just not mapped to /etc)
<ogra> )
<zyga> ogra: to answer your question, hooks cannot ever observe pre-layout filesystem
<zyga> ogra: can you file a bug, ideally with a small reproducer, I'll take a look
<ogra> so i need a wrapper and actually write into the file then ... k
<zyga> ogra: some bugs got fixed recently, 2.41 will be much better on that than before
<zyga> ogra: but perhaps there's another one
<zyga> https://github.com/snapcore/snapd/pull/7168/files#diff-d2dd0567bc81c6005b7c0f2e727f9b57R531
<zyga> er
<zyga> sorry, cannot copy paste in this wayland business
<zyga> anyway
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<zyga> mborzecki: I need to fix the die situation to release 2.41
<zyga> for opensuse
<ogra> well, i can switch my machine to beta, perhaps it works there ...
<zyga> mborzecki: mvo said he doesn't have time to review 7362
 * ogra gives it a try with 2.41
<zyga> pstolowski: ^ can you look instead, mvo said another reviewer is fine
<zyga> I can then cherry pick that into a distro patch
<mvo> pedronis: 6404 is ready yes
<pedronis> yea, added it to my queue
<pstolowski> zyga: 7362? ok, looking
<zyga> yes, thanks!
<pstolowski> allright, i remember that other PR from contributor..
<mup> PR snapd#7413 closed: hookstate/ctlcmd: fix snapctl set help message <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7413>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7400 is green, I think you are the one to review it
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
 * Chipaca ponders lunch
<zyga> more progress, more passing tests
<zyga> feels like a good day now
<pstolowski> zyga: +1 with 2 minors
<zyga> thanks, looking
<zyga> pstolowski: replied on both, can you check the first answer please
<pstolowski> yep, done, got it
<zyga> super, thank you
<mup> PR snapcraft#2700 closed: schema: build-base support for the kernel type <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2700>
 * dot-tobias says hi
<doko> mvo, sergiusens: snapcraft autopkg test failure, triggered by binutils in eoan
<ogra> fix binutls then :P
<Chipaca> pstolowski: did you resolve the core18 test prepare failures? getting them too
<Chipaca> https://travis-ci.org/snapcore/snapd/builds/581107491?utm_source=github_status&utm_medium=notification
<cachio> Chipaca, is it new?
<Chipaca> cachio: i think so
<cachio> Chipaca, I'll take a look if nobody else is already on it
<Chipaca> cachio: thanks!
<cachio> np
<cjp256> Is there an "official" recommendation/doc stating how to detect if running in a snap? I've seen a couple of apps doing it slightly differently (e.g. checking for "SNAP" or "SNAP_NAME" in environment).  Someone in #snapcraft was asking. sergiusens pointed out that snapcraft itself uses SNAP_NAME,  the preferred route to detect if being invoked by another classic snap.
<pstolowski> Chipaca: not yet, i was about to look at this. got them a couple of times since yesterday
<Chipaca> cachio: standup?
<ijohnson> cjp256: usually most folks just check for $SNAP being defined
<sergiusens> ijohnson: in the past lxd had a problem as snapcraft was calling out to it (the deb) and the in-code logic assumed it was a snap, so we check to see if the SNAP_NAME matches what we want
<mup> PR snapcraft#2701 opened: spread tests: update gnome extension tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2701>
<ijohnson> sergiusens: fair enough, I haven't written many classic snaps so I haven't run into that kind of issue
<sergiusens> assumed it was a snap as it was only checking for the existence of the export and not the value it carried... SNAP_NAME is an easier value to check against as it is fixed to the snap
<zyga> jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/7400
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> it's super small in non-test code, just interested in your opinion
<Chipaca> zyga: it might be related to the generator, as there is a target (local-fs.target) which is part of snapd.service (and .socket) critical path
<Chipaca> zyga: in 16.04, which doesn't use the generator
<Chipaca> afaik
<cjp256> It does seem like something that should be formalized one way or another and added to the docs. degville: Where do you think would be the most appropriate place?
<zyga> Chipaca: in the bug report it happened on core18 system
<zyga> Chipaca: but in either case, we need to think about what happens when snapd doesn't have snaps mounted
<zyga> Chipaca: I think only bad things will happen
<Chipaca> zyga: ??
<zyga> Chipaca: because no plugs or no slots
<zyga> Chipaca: e.g. on reboot with new kernel,  new system key
<Chipaca> zyga: why would a new system key mean no snaps mounted?
<zyga> Chipaca: new kernel -> you reboot -> you race with mounting snaps -> you lose -> you create profiles without any interfaces for apps
<Chipaca> zyga: why are you racing with mounting snaps?
<zyga> Chipaca: because snapd.service is not synchronized with .mount units
<Chipaca> zyga: it is
<Chipaca> zyga: I just said so
<zyga> how is that done?
<zyga> ah, I misunderstood that
<zyga> can you re-state please
<Chipaca> at least on 16.04, i haven't checked 18.04 but it's easy to check
<Chipaca> zyga: there's a local-fs.target
<Chipaca> zyga: mounts are done before that
<Chipaca> zyga: snapd runs after that
<Chipaca> at least, that's how it _should_ work :-)
<zyga> mmm, I see
<Chipaca> zyga: easy to check
<Chipaca> zyga: in core18, systemctl show snap-core-*.mount
<Chipaca> systemctl show snap-core-*.mount | grep Before
<Chipaca> should list local-fs.target
<zyga> they have before=snapd.service now
<zyga> hmmm
<zyga> isn't that automatic somehow?
<Chipaca> $ systemctl show snap-core18-*.mount | grep Before
<zyga> the local-fs
<Chipaca> Before=local-fs.target snapd.service multi-user.target umount.target
<zyga> something to check
<Chipaca> ^ that's 16.04, 18.04 should have the same
<zyga> oh
<zyga> show vs cat
<zyga> thanks, I didn't know about this
<Chipaca> and, snapd should have After
<Chipaca> in 16.04 that After actually includes every .mount
<Chipaca> note the mount has a before on snapd.service :-)
<Chipaca> so it *should* be doubly-sure that it won't happen
<Chipaca> there is explicit ordering
<Chipaca> now, does it work? i don't know
<Chipaca> if it doens't there's clearly a bug somewhere
<zyga> mhm
<zyga> yeah, it'd be interesting to see if we can attempt to reproduce this somehow and run it in a loop
<zyga> to gather some fresh data
<Chipaca> it might just be in the weird snapd in our core18 spread environ
<zyga> or it might be in our weird snapd-from-snap service
<Chipaca> zyga: if you can get a shell on a system showing this, systemctl analyze plot would be useful
<zyga> mmm, indeed
<mborzecki> cmatsuoka: ping me if you have questions about snap-image
<Chipaca> zyga: as last words "the treasure is buried in the" is hard to beat
<cmatsuoka> mborzecki: thanks, I'll have a good look and probably questions will appear
<zyga> Chipaca: :)
<zyga> pstolowski: remember that TV crew? they are coming back for another episode
<pstolowski> zyga: aha, what tv show is that?
<zyga> pstolowski: gliniarze or something like that
<degville> cjp256: I think documenting this is a good idea too. There currently isn't an ideal place - I do have a doc describing the running environment on my todo list, but for now it may be most useful in the snap hooks page: https://forum.snapcraft.io/t/supported-snap-hooks/3795
<mup> PR snapd#7383 closed: cmd/snap: improve help and error msg for snapshot commands <Created by galgalesh> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7383>
<mborzecki> off to pick up the kids and do groceries
<pedronis> mvo: https://github.com/snapcore/snapd/pull/6705#discussion_r321285831
<mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
<pedronis> mvo: I'll work on that today after I pushed my current state of the image refactoring
<Chipaca> pedronis: I'd rather we didn't print "lk" in error messages as it can be hard to tell from "1k"
<pedronis> Chipaca: so LK ?
<pedronis> I don't mind a ton
<pedronis> as long as it is consistent
<Chipaca> and "cannot open 1k environment file" is not impossible, as error messages go
 * ogra proposes "hackish-android-bootloader" 
<Chipaca> :)
<Chipaca> ogra: it's like swedish chef was fired from the kitchen so they picked up bootloader hacking instead
<ogra> haha
<Chipaca> ogra: also, https://www.youtube.com/watch?v=B7UmUX68KtE
<mvo> pedronis: thank you
<ogra> LOL
<ogra> PÃ¶pcÃ¸rn
<mvo> pedronis: yeah, thats nice
<ijohnson> pedronis: I'm sorry the explanation for the changes are complicated... I don't think we can do it during start-snap-services because that's too late I think, we need to disable the services before the post-refresh hook
<ijohnson> I need to think more about stop-snap-services, that might be okay because we run that after the post-refresh hook IIRC
<ijohnson> err s/post-refresh/pre-refresh/
<pedronis> ijohnson: anyway you are probably victim of having put code near something that seems wrong
<pedronis> I don't understand anymore
<pedronis> ijohnson: anyway my main worry about where we unlock remains
<ijohnson> I can look into where we unlock, I mainly just put it there because that's what mborzecki commented on, I will try to find more examples in the codebase of how that is done other places
<ijohnson> pedronis: the main thing I am trying to do is capture the state as late as possible from systemd during unlink-snap, and then restore it as early as possible in link-snap (similar for the undo handlers)
<pedronis> I don't late is a useful concept here
<pedronis> this a relatively fast operation holding the lock
<ijohnson> I realize it's not very similar to other things in the codebase since it's both very short lived and also potentially ver long lived
<pedronis> as they are on trunk
<pedronis> yes, my worry there
<pedronis> we are changing some property of this things
<pedronis> pstolowski: can you remind why of this line:  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L1311 it doesn't make sense to me atm, why would we restore a config while we are unlinking a snap
<pedronis> I would imagine we do that when linking
<pedronis> the other unlink has a save instead
<pedronis> ijohnson: anyway that's why your code confused me ^, I don't understand the lines it has close
<pedronis> now
<ijohnson> ok
<pedronis> ijohnson: anyway as I said we need either need to move those interaction with systemd close to end of the handlers, to to the stop/start ones
<pedronis> s/to to/or to/
<pstolowski> pedronis: in undoLink, afair we restore config of previous revision, because config might have already been updated e.g. by configure hook
<pedronis> pstolowski: it's part of the undo case?
<pedronis> but we do a relink at the very end
<pedronis> pstolowski: if it's right, it needs a comment, if it isn't it needs moving/going away. atm it's very confusing
<pedronis> ijohnson: also  s/end/start or end/
<pedronis> sorry
<ijohnson> what other tasks do we run after a configure hook? the only one I see is the health-check
<ijohnson> could the health-check fail and trigger things to be undone?
<ijohnson> if the health-check could fail the entire change, then I think pstolowski's code is correct as is, because the configure hook could have successfully finished and committed changes to the state that we need to restore
<ijohnson> s/health-check/any other random task that runs after the configure snap task/
<pedronis> but by definition we should run anything on an unlinked snap
<pedronis> shouldn't run
<pedronis> that's the bit I don't get
<pedronis> I'm not saying we shouldn't restore
<pedronis> I'm questioning the where
<ijohnson> hmm
<pedronis> when of it
<ijohnson> I see your point now
<ijohnson> for my case, with specifically undoLinkSnap, we could save the state of the services very early in the function rather than right before the unlink
<ijohnson> would that make more sense?
<ijohnson> because we can't save it after the unlink
<pstolowski> i need to refresh my memory re the details of config snapshots; the general idea is to switch to respective version of config whenever we switch between revisions, whether it's undo or succesfull op
<pedronis> ijohnson: yes, doing this slow things that don't want the lock either first or last seems best
<pedronis> sorry, do want the lock
<pstolowski> i'll check that code and add comments or fix if needed
<pedronis> pstolowski: thank you
<zyga> re
<pedronis> pstolowski: it got me slightly confused in a different review
<ijohnson> pedronis: ack I will make changes to that effect, do you still want me to pursue using the task for storing the list short-term and then commit it later for long term storage?
<pedronis> ijohnson: yes, think about that and see if it's better or worse
<ijohnson> I'm still not convinced we can entirely push it out to the start/stop-snap-services tasks I need to think on that a bit more
<ijohnson> okay I will see what I can do
<ijohnson> thanks for the review
<pedronis> ijohnson: keeping unlink/link fast is attractive
<pedronis> in terms of think we can reason about
<ijohnson> also did you see my questions about the new `snap model` output on your forum post?
<ijohnson> (and also my PR for that too)
<pedronis> ijohnson: yes, but didn't get to look at it yet, I saw the question
<ijohnson> okay, thanks
<pedronis> my original thought was not do that, but now not sure
<pedronis> I'm thinking about it
<ijohnson> okay, well whenever you get a chance either on the PR or the forum post is fine and I'll update the PR with whatever else you need
<ijohnson> oh one last thing, do you think I should split out the cli.StoreAccount change to a different PR?
<ijohnson> it seemed like a small change so I kept it but I could also see the case for making that a different PR
<pedronis> ijohnson: the PR at least at moment doesn't look too big, and we have nothing pressing that would need it, so seems ok
<pedronis> as is
<ijohnson> pedronis: ack, thanks
<jdstrand> zyga: I plan to (7400)
<zyga> thank you
<diddledan> ooh, 2.41 is in candidate!
<diddledan> \o/
 * diddledan reboots to loonicks to try it
<pstolowski> zyga, Chipaca annoyingly, I cannot reproduce that spread test issue we talked about on standup when running individual tests on gc
<zyga> pstolowski: it's always like that
<zyga> the magic compounds :/
<diddledan> dang. my changes in 2.41 aren't enough for makemkv to find the optical drive :-(
<diddledan> looks like it still needs another permission granted: `/sys/bus/scsi/devices r,`
<diddledan> I would expect that to be in hardware-observe. but we _could_ add a new scsi-observe if we want it more fine-grained?
<diddledan> @jdstrand ^^^^
<mup> PR snapcraft#2701 closed: spread tests: update gnome extension tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2701>
<diddledan> how do I double-check the device cgroup again to make sure it added the sg0 device into it?
<mup> PR snapd#7415 opened: tests: fix mountinfo-tool filtering when used with rewriting <Created by zyga> <https://github.com/snapcore/snapd/pull/7415>
<mup> PR snapd#7416 opened: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<pedronis> mvo: next steps ^ but it's huge instead of just big because I need to land the seed16 one
<pedronis> first
<pedronis> doing the small bootloader Find change now
<diddledan> ok, it looks like the cgroup has it assigned (actually sg2, not sg0) `c 21:2 rwm`
<diddledan> so my changes are working correctly, they're just not sufficient :-)
<mup> PR snapd#7387 closed: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
<mup> PR snapcraft#2702 opened: Release changelog for 3.8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2702>
 * cachio lunch
<mvo> pedronis: cool, I think I will have a look at this pr tomorrow
 * Chipaca â run
<mvo> pedronis: uh, 3k diff :/
 * mvo runs as well
<zyga> mvo: haha
<zyga> mvo: now you promised ;)
<mvo> zyga: heh - its actually not that huge, it contains the seed loading one (7381)
<Chipaca> mvo: *actual* run?
<mvo> Chipaca: nah, not today :(
<Chipaca> mvo: aw, had my hopes up
<Chipaca> anyway, 'm off. take care and see some of you around later. Otherwise, have a great weekend!
<zyga> Chipaca: o/
<mup> PR snapd#7417 opened: interfaces/wayland: On classic systems only consider the OS slot for auto-connect <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7417>
<pedronis> mvo: it contains the previous one as I said
<pedronis> but yes, it will be 1400 on its own
<mvo> pedronis: I'm experimenting with bases remodel right now, when testing this for real I get "invalid request: unexpected data after serial-request and optional model"
<mvo> pedronis: is this something known, am I doing it wrong?
<pedronis> mvo: experimenting in which sense?
<mvo> pedronis: doing a uc16->uc18 remodel
<pedronis> mvo: with the what kind of model?
<pedronis> in the tests?
<pedronis> for real?
<mvo> pedronis: the real models
<mvo> pedronis: should I use test models for this?
<pedronis> mvo: the issue is that the serial vault knows about remodeling, but the store doesn't
<pedronis> the real model use the store as serial vault
<pedronis> the store needs  change for that to work
<mvo> pedronis: aha, ok. that makes sense then, I will setup appropriate test models and retry :)
<mvo> pedronis: thats fine, thanks for the explaination
 * mvo needs to be afk for a few minutes
<pedronis> mvo: the store is not setup to do remodels, but I suppose we need to teach about this  kind of remodel
<pedronis> if we want to do it
<pedronis> a bit unclear though
<mup> PR snapd#7159 closed: tests: add functions to make an abstraction for the snaps <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
 * zyga is on child watch duty
<zyga> though there's one more bugfix PR coming after
<zyga> making some more progress
<zyga> about to fix duplication on core16
<zyga> need to explore because unique to 16 somehow
<Saviq> ughies https://status.snapcraft.io/
<zyga> https://xkcd.com/908/
<mup> PR snapd#7418 opened: many: pass the rootdir and options to bootloader.Find <Created by pedronis> <https://github.com/snapcore/snapd/pull/7418>
<mup> PR snapd#7362 closed: cmd: unify die() across C programs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7362>
<mup> PR snapd#7358 closed: cmd/system-shutdown: Rename die() -> die_reboot() to fix build failures with LTO enabled <â Blocked> <Created by dcermak> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7358>
<ardaguclu_> TCP connection gets lost after handshake completed for snapcraft.io
<zyga> ardaguclu_: status.snapcraft.io
<ardaguclu_> zyga: yeah, after checking there I tried myself
<mborzecki> https://paste.ubuntu.com/p/dpSXHrZtQc/ funny test failure
<jdstrand> diddledan: hardware-observe should handle that
<jdstrand> diddledan: as for the device cgroup, look in /sys/fs/cgroup/devices/snap.name.cmd/devices.list for the major:minor of /dev/sg0. can also do: udevadm info /dev/sg0 to see if the TAGS has your snap
<diddledan> Thanks, jdstrand . The device is correctly in the cgroup.
<jdstrand> \o/
<mup> PR snapd#7406 closed: cmd/snap-confine: keep track of snap instance name and the snap name <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7406>
<mvo> hrm, hrm, so commit 92a096278e040b452125260b00742ae6e62caf2c (zyg@xenial-server) breaks the cla checker in my 6404 pr - I wonder how to get out of this missery
<zyga> oops
<zyga> ah, 2016
<zyga> uff :)
<zyga> mvo: I can offer a rebase solution ;)
<zyga> (just kidding)
<zyga> can you whitelist zyga@xenial-server and
<zyga> just call it a day?
<mvo> zyga: I have no idea why it breaks :/
<mvo> zyga: I think that works - or I could rebase my patches
<zyga> I mean the rebase was a silly suggestion
<zyga> you'd have to rebase 3 years
<mvo> zyga: I wonder why it hits my PR :(
<zyga> mvo: git history caught it?
<zyga> mvo: AFAIK we take only shallow history
<zyga> so something close is related pulling it in?
<zyga> not sure
 * mvo has no idea
<jdstrand> zyga: I review PR 7400. curious, how much more is there wrt 'mount namespace robustness'?
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<jdstrand> reviewed*
<zyga> jdstrand: MS_SHARED for sure
<zyga> jdstrand: some more tests
<zyga> jdstrand: like mount-ns test for more constructs, specifically the mimic
<zyga> jdstrand: after that I think we can return to wrapping up persistence
<jdstrand> zyga: are there open PRs for these or are those all the ones you'll reopen?
<zyga> jdstrand: I'll open those, I'm trying to keep it under six
<zyga> jdstrand: some are not fully ready
 * jdstrand nods
<zyga> jdstrand: note that MS_SHARED you had reviewed before
<zyga> jdstrand: but it uncovered more issues
<zyga> jdstrand: there's something wrong with loopback devices
<zyga> jdstrand: they definitely leak
<zyga> jdstrand: apps, bases, all alike
<zyga> jdstrand: so more research into that area
<zyga> jdstrand: is there some specific concern you have?
<jdstrand> zyga: just trying to understand the scope and timing of work. this will be a blue item for us
<zyga> jdstrand: we have an item for it, under robustness
<zyga> jdstrand: you can refer to that one from your roadmap perhaps, not sure if that's useful
<zyga> jdstrand: note that most of the work involves digging and fixing tests
<zyga> jdstrand: there are relatively few patches still, compared to the amount of time
<jdstrand> zyga: yes. and we will have a similar one that is blue for me to perform the reviews to help you achieve it :)
<zyga> jdstrand: thank you :)
<zyga> jdstrand: so far most of the effort was to stabilize the test suite
<zyga> jdstrand: so that we actually get to write new tests
<jdstrand> yeah. it is all really good stuff
<zyga> I'll produce updates and answers for your questions tomorrow
<jdstrand> anyway, don't mean to dtract from your evening or change any priorities, just a simple question to help me plan
<zyga> jdstrand: no worries, it's always fine :)
 * Chipaca EOWs
<diddledan> gui snaps work in WSL2: https://usercontent.irccloud-cdn.com/file/HyrFk7TC/image.png
#snappy 2019-09-06
<zyga> good morning
<zyga> hey mborzecki
<mborzecki> zyga: morning
<zyga> I have some changes to make in https://github.com/snapcore/snapd/pull/7400
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> and then another round ad 2.41 suse package
<mborzecki> zyga:  yeah, i saw jstrand's review
<mborzecki> mvo: morning
<mvo> mborzecki: goooood morning! how are you?
<mborzecki> mvo: cold ;) +11C outside
<mvo> mborzecki: yeah, same here. but much better than the ~40 before :)
<mvo> (at least IMO)
<zyga> good morning mvo
<zyga> mborzecki: +11 wow
<mvo> hey zyga
<zyga> I'm debugging something that I changed that causes seeding to fail
<zyga> it's pretty frustrating because there's no output
<mvo> mborzecki: hm, I think we have +9 outside
<zyga> I'll try to de-focus and advance some other stuff later, maybe around noon
<mborzecki> mvo: wow, my preference is +20 all day round :P
<zyga> mborzecki: check out spain ;)
<zyga> mvo: do we have any stats on spread usage?
<mvo> zyga: stats in what sense?
<zyga> mvo: number of vm/hours used per account
<zyga> something like that
<zyga> just as trivia
<zyga> I wonder what's our record
<mvo> zyga: I'm sure gustavo has them, maybe sergio - I don't
<mup> PR snapd#7158 closed: tests: part5 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7158>
<mborzecki> off to take my son to school and take some paperwork to my accountant
<mborzecki> bbl
<zyga> o/
<pstolowski> morning
<zyga> good morning pawel
<mup> PR snapd#7418 closed: many: pass the rootdir and options to bootloader.Find <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7418>
<zyga> wow, small success
 * zyga tries the other test now
<zyga> I'm on the way towards addressing the thing that made MS_SHARED bugfix be more complex in tests
<zyga> caused by particular core16 behavior
<mborzecki> re
<zyga> mborzecki: hey
<zyga> mborzecki: I added syslog to snap-confine
<zyga> it helps when things faily mysteriously
<zyga> added some draft code to unmap /writable from snaps POV
<zyga> that could be the thing to cut the duplicated mount entries on core16 upsetting tests
<mborzecki> zyga: syslog? as in syslog(3)?
<zyga> yes
<zyga> it shows up even if the invocation is otherwise hidden
<zyga> made me realize a mistake earlier
<mborzecki> zyga: got some cleanups in s-c unit tests
<zyga> mborzecki: send them over and ping me
<pedronis> mvo: morning, I looked at #6404 again
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<mvo> pedronis: thanks, I check it out
<mvo> pedronis: I updated the LK one, let me know if you want to go one step further
<pedronis> mvo: I answered, yes, I think we should, but the change is smaller than what you thought I think
<pedronis> mvo: we don't use InstallBootConfig at runtime
<pedronis> I can look myself in a little bit
<mvo> pedronis: also 7181 is green, I think we can merge it, yes?
<pedronis> mvo: you mean 7381 ?
<pedronis> yes I will merge it and make 7416 smaller
<mup> PR snapd#7381 closed: seed,image,o/devicestate: extract seed loading to seed/seed16.go <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7381>
<zyga> yay
<zyga> I identified the core16 + core16 but that duplicated some entries that caused the MS_SLAVE test to fail originally
<zyga> the fix is super easy and obviously so
<zyga> coming up in 30-60 minutes after some more testing
<mvo> pedronis: ok, I will leave the LK one for you then, thank you :) and yes, I did mean 7381
<mvo> (fat fingers)
<zyga> it's almost over, the whole thing is aligning :)
<pedronis> mvo: done, now #7416 is it's proper size (still big, again because tests), also is not the whole thing as I said, more like ~1/3 maybe
<mup> PR #7416: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<pedronis> *its
<mvo> pedronis: ok, I try to get to it soon
<zyga> mborzecki: it passed :D
<zyga> mborzecki: mwahaha, the bug is fixed
<zyga> running full run across all systems on that test
<zyga> I'll start polishing the patch for submission
<pedronis> mvo: I pushed changed to the LK PR, please have a look when you can
<pedronis> *changes
<mup> PR snapd#7419 opened: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
<mborzecki> zyga: ^^
<mborzecki> zyga: tried to use glib goodies in test_argc_argv() and fix memory leaks there, but gave up eventually as we modify the resulting argv in sc_nonfatal_parse_args()
<pstolowski> pedronis: i'm cleaning up per-revision config stuff a bit and add some more tests
<pedronis> pstolowski: ok, thx
<mborzecki> ok, heading back home
<mup> PR snapd#7420 opened: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
<pstolowski> pedronis: i thought i found a bug in that we only restore revision config on revert but not on refresh; but we explicitely test this behavior in config-revisions spread test. i'm not sure why we wanted that
<pedronis> pstolowski: you mean a refresh to old revision?
<pedronis> it makes sense to me though that we don't reapply old config in that case
<pstolowski> pedronis: yep, snap refresh --revision=.. foo
<pedronis> pstolowski: we don't go find the old data either I think
<pedronis> revert is really the only op that says please get me back in time
<pstolowski> pedronis: ah i see what you mean
<pstolowski> thanks, all clear
<pstolowski> good i had a spread test; i've added explicit unit test now
<mborzecki> re
<mborzecki> zyga:  updated #7419
<mup> PR #7419: cmd/snap-confine: add unit tests for sc_invocation, cleanup memory leaks in tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7419>
<zyga> mborzecki: thank you
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7420
<mup> PR #7420: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
<zyga> mborzecki: +1, can you please push a change to include it in the new format
<zyga> and reformat
<zyga> it will have clang formatting (the -test.c file) so it will be a little bit nicer
<mborzecki> zyga: in the same PR?
<zyga> yeah, the -test file is new
<mborzecki> ok
<mborzecki> hmm we should be putting emacs formatting spec in *.[ch] files like systemd does
<mborzecki> fwiw emacs and vim
<zyga> mborzecki: +1
<zyga> thoguh I'm not using emacs, not sure if that is picked up universally
<zyga> mvo: I need to do an errand downtown today, I will bring my laptop with me but not sure if I will have conditions for the call
<zyga> mvo: my update is that I'm zeroing on the re-submission of MS_SHARED bug fix
<zyga> mvo: I identified two causes of the failure of the integration test in the original pull request
<zyga> mvo: one is under review now
<zyga> mvo: the other was sent yesterday and +1'd but -1'd by jamie (code ok, comment tweaks requested)
<zyga> mvo: I'll address those and try to propose the fix for MS_SHARED later today if I can
<mvo> thanks for the update zyga
<Psil0Cybin> cans omeoenm help me get snap working on kali linux?
<zyga> Psil0Cybin: hey, perhaps
<zyga> we did this enough times to have some experience
<mup> PR snapd#7421 opened: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> mborzecki: one more https://github.com/snapcore/snapd/pull/7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> I made it a draft as it will be probably discussed longer and I want  to perform some more analysis
<Psil0Cybin> zyga, tank you becasue i was having problems that my home directory is in /username and not in /home/username
<Psil0Cybin> and it would not let me run any appliations installed etc
<zyga> Psil0Cybin: that's a known limitation and it is not supported
<Psil0Cybin> shojld i provide the erorr logs?
<zyga> it's not related to the distribution
<Psil0Cybin> so how do i go bout gtting snap.d packages
<zyga> Psil0Cybin: no need, we know about this and there is no solution now
<Psil0Cybin> installed
<Psil0Cybin> dang
<zyga> you must use the regular location
<Psil0Cybin> so im completely out of luck
<zyga> that's the only outcome
<zyga> no, just put it in /home/username
<zyga> it's not a big deal, is it?
<Psil0Cybin> should not be i just installed kali and created a non root account as per guide
<Psil0Cybin> so what would i do now?
<zyga> Psil0Cybin: I don't know much about kali
<zyga> I cannot help with that directly
<zyga> so what's your actual username?
<zyga> and user home directory on the system?
<cmatsuoka> mvo: I see in the spike code that ubuntu-image is actually installing the recovery bootloader files, is it supposed to work that way in the final code, or prepare-image should do that?
<zyga> jdstrand: good day
<zyga> jdstrand: I have updated the comment and replied tyo your question on https://github.com/snapcore/snapd/pull/7400
<mup> PR #7400: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7400>
<zyga> jdstrand: I also opened two additional PRs as we discussed
<zyga> jdstrand: only one is something I'd like you to review
<zyga> jdstrand: it is https://github.com/snapcore/snapd/pull/7420
<cmatsuoka> mvo: I'm playing with snap-image to generate an image, after patching prepare-image to generate recovery (mostly from the spike code)
<mup> PR #7420: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <https://github.com/snapcore/snapd/pull/7420>
<zyga> jdstrand: the other one is something that I want to experiment more with, you can see it in https://github.com/snapcore/snapd/pull/7421 if you are curious
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> as soon as 7400 and 7420 land I will propose a v2 of the MS_SHARED fix
<zyga> mborzecki: if you can, please do a pass over  7420
<cmatsuoka> mvo: (also checking snap-image details with mborzecki)
<zyga> mvo: perhaps as well, it's something you should know about
<mup> PR snapd#7422 opened: interfaces: allow reading mutter Xauthority file <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7422>
<mup> PR snapd#7423 opened: overlord/snapstate: config revision code cleanup and extra tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/7423>
<pstolowski> zyga: https://bugs.launchpad.net/snapd/+bug/1828354 didn't have solution, right? or was it fixed elsewhere?
<mup> Bug #1828354: mount event propagation on snapd-mounted tmpfs is incorrect <snapd:In Progress by zyga> <https://launchpad.net/bugs/1828354>
<mup> PR snapd#7415 closed: tests: fix mountinfo-tool filtering when used with rewriting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7415>
<zyga> pstolowski: it has a solution but we were unable to land it, my update above (for mvo) was about that
<zyga> pstolowski: this is the MS_SHARED bug
<zyga> pstolowski: it's close to being fixed now
<zyga> pstolowski: I need to land two prerequisites and I can reopen the fix
<pstolowski> zyga: ok, thanks
<pstolowski> zyga: i'm keeping the bug 'in progress' then
<tomwardill> hello! store team here, we've got some slowness issues that are causing timeouts, etc. Info will be here: https://status.snapcraft.io/
<zyga> thank you for sharing tomwardill
<zyga> thank you jdstrand!!!
<jdstrand> np
<zyga> I'll adjust the git commit message and the comment before landing
<zyga> jdstrand: adjusted and squashed for simplicity
<jdstrand> mvo, cachio: thanks for 7288, 7346 and 7350 (system-usernames cleanups)! sorry they were needed
<cachio> jdstrand, looking
<mvo> jdstrand: no worries, the world is complicated
<cmatsuoka> mvo: I thought you would stay a bit to discuss snap-image details?
<mvo> jdstrand: thank you for making the system-user happen, 2.41 will make a few teams quite happy
<mvo> cmatsuoka: yes
<mvo> cmatsuoka: sorry, brain
<jdstrand> mvo: 7346 was a particularly nice one
<jdstrand> (validate before create)
<mvo> cmatsuoka: I'm back again
<jdstrand> mvo, cachio: hope it didn't cause too much trouble
<jdstrand> cachio: no need to look them up. just you two working through testsuite issues after the feature landed
<cachio> jdstrand, everything merged :) snap_daemon did not you
<cachio> troubles
<pstolowski> jdstrand: thanks for looking at my apparmor backend PR!
<pstolowski> (k
<pstolowski> ijohnson and pedronis  - thank you too!
<pstolowski> i think with the general approval for the direction of this PR i'll work on new tests & the feedback
<ackk> hi, out of curiosity, why is that any user can call "snapctl set-health"?
<ijohnson> pstolowski: you're welcome :-)
<pstolowski> ackk: i think that's because any app can set health status of own snap (and doesn't need euid 0 to do that). note you cannot do anything useful by running snapctl set-health manually because of missing context
<ackk> pstolowski, you mean it would only show up in snap info?
<pstolowski> ackk: it would show in snap info, yes (not sure why "only"?) - see https://forum.snapcraft.io/t/health-checks/10605
<ackk> pstolowski, I see thanks
<ackk> pstolowski, fwiw I meant, if you run it manually from a snap run --shell, you can still set it so that it shows in the status
<mup> PR snapd#7270 closed: overlord/snapstate: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
<ackk> pstolowski, what would be the context you're referring to?
<pstolowski> ackk: yes. but that's interesting case, i didn't think about it
<ackk> pstolowski, I was wondering a malicious user could just snap set-health error "everything is broken"
<pstolowski> ackk: yes i see what you mean
 * cachio lunch
<zyga> re
 * zyga reads backlog
<zyga> ackk: snap run --shell gives you a cookie
<roadmr> ðª
<zyga> ackk: snap run --shell
<zyga> echo $SNAP_COOKIE
<zyga> AFAIR
<ackk> zyga, indeed
<mup> PR snapd#7420 closed: cmd/snap-confine: fix /snap duplication in legacy mode <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7420>
<mup> PR snapd#7422 closed: interfaces: allow reading mutter Xauthority file <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7422>
<zyga> master moved by 64 revisions
<zyga> man, today is busy
<mvo> zyga: oh yes!
<jdstrand> pstolowski: you're welcome!
<mvo> code review for https://github.com/snapcore/spread/pull/69 would be great, probably needs some tweaks but a early test would be amazing
<mup> PR spread#69: Manage pagination retrieving images from google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/69>
<pedronis> ijohnson: are you are aware of this bit of code: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/backend/link.go#L152
<pedronis> ? (I was almost forgetting myself)
<pedronis> it's called by link-snap
<mup> PR snapcraft#2703 opened: build provider: allow configuration of primary apt mirror <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2703>
<pedronis> ijohnson: I left this comment: https://github.com/snapcore/snapd/pull/7270#issuecomment-528941176
<mup> PR #7270: overlord/snapstate: save disabled snap svcs on unlink snap tasks <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7270>
<mup> PR snapd#6697 closed: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<ardaguclu_> run_checks first executes gofmt and in my local machine each time it returns "formatting wrong in following lines;..."
<ardaguclu_> Am I doing something wrong, because each time I manually run gofmt to complete run_checks and see results
<ardaguclu_> I am running it 1.13, is it something because of that?
<zyga> ardaguclu_: it's a known flaw
<zyga> ardaguclu_: ignore it
<zyga> ardaguclu_: you can go test ./...
<zyga> and that's just as good
<zyga> ardaguclu_: there's a few things it doesn't do but you can check the script to see what's that
<mup> PR snapcraft#2703 closed: build provider: allow configuration of primary apt mirror <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2703>
<zyga> ardaguclu_: go fmt has changed behavior across versions
<ardaguclu_> zyga: thanks, I am going to check it.
<mup> PR snapcraft#2704 opened: extensions: create the gnome-platform directory <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2704>
<mup> PR snapcraft#2705 opened: extensions: rename extension classes to known names <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2705>
<ijohnson> thanks pedronis, sorry was afk for a bit, that makes sense
<mup> PR snapcraft#2706 opened: extensions: improve docsting (used in the cli) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2706>
<mup> PR snapd#7400 closed: cmd/snap-update-ns: don't propagate detaching changes <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7400>
<mup> PR snapd#7424 opened: fixme: move snapfrompid into osutils <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7424>
<mup> PR snapd#7425 opened: channel: introduce Resolve and ResolveLocked <Created by pedronis> <https://github.com/snapcore/snapd/pull/7425>
 * ijohnson reboots
<jdstrand> ijohnson: I went to update trello for the "rainy day list" to add 6697 and recalled from my notes something: https://github.com/snapcore/snapd/pull/6697#issuecomment-528987808
<mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<ijohnson> thanks jdstrand I'll take a look
 * cachio EOW
<mup> PR snapd#7426 opened: cmd/snap-update-ns: clarify sharing comment <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7426>
 * zyga goes to sleep
#snappy 2019-09-07
<mup> PR snapd#7424 closed: fixme: move snapfrompid into osutils <Created by ardaguclu> <Closed by ardaguclu> <https://github.com/snapcore/snapd/pull/7424>
<mup> PR snapd#7424 opened: fixme: move snapfrompid into osutils <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7424>
<rogpeppe> hi all, a raspberry pi that i maintain went into a reboot loop recently. i reflashed the sd card and it now works, so i'm guessing it's probably not a h/w problem. any ideas why this might have happened? it was previously running the same s/w for months on end without incident.
<rogpeppe> it's annoying because it's a remote system running a domestic power control system and i don't have direct access to it (physical access requires either a 900 mile drive or having the pi sent in the post)
<rogpeppe> i suspect that snappy/core auto-update might have been to blame, but it's also possible that the sd card has become unreliable
<zyga> rogpeppe: hey
<zyga> rogpeppe: do you still have the card contents from the reboot loop?
<zyga> rogpeppe: we could perform analysis to determine that
<rogpeppe> zyga: no, sorry, i had to overwrite them
<rogpeppe> zyga: i shoulda copied the card contents
<zyga> rogpeppe: I see, it's too bad because it might have been interesting to understand the cause
<rogpeppe> zyga: yeah, i thought so too
<zyga> rogpeppe: next time please "dd" the card to disk for safe-keeping
<zyga> rogpeppe: if this happens again please let us know
<zyga> we saw a few events like that but in all cases those bugs were eventually fixed
<rogpeppe> zyga: will do. i wanted to look at syslog but i'm not sure how to view journalctl logs via an sd card
<zyga> rogpeppe: I'm not sure either but there's probably a way somehow
<rogpeppe> zyga: it's quite possible this hardware is unreliable - i've just seen another random reboot
<zyga> rogpeppe: in one case we found a bug in the FAT encoding between the bootloader, linux and some dos editing tools from linux
<rogpeppe> zyga: i'm moving onto another rpi (a rpi 3 this time) and keeping fingers crossed
<zyga> rogpeppe: so the range of possible problems is wide
<zyga> rogpeppe: make sure to use a good power adapter, PI 3B+ uses way more energy and needs a reliable source
<rogpeppe> zyga: ok, that's interesting. how many amps does it need?
<zyga> rogpeppe: from the top of my head you need 2.5 or 3A
<zyga> rogpeppe: I ordered a new dedicated power supply for this reason, just waiting for the package to arrive
<rogpeppe> zyga: one thing that concerns me about my current setup: the snap that's doing the work prints quite a bit to stdout (logging messages) and that ends up churning the sd card quite a bit over the course of months.
<zyga> rogpeppe: mmm
<zyga> rogpeppe: it's a common complaint actually,
<rogpeppe> zyga: there have been a couple of occasions when i think an unexpected power outage has resulted in a corrupted sd card that's unable to boot
<zyga> there used to be some settings to disable rsyslog and make journal only log to memory but I think those never got released
<rogpeppe> zyga: at least, that's my tentative diagnosis
<rogpeppe> zyga: i'm thinking of installing some kind of battery-backed UPS device to avoid that somewhat
<zyga> rogpeppe: maybe just a powerbank?
<zyga> some powerbanks can be charged and used at the same time
<zyga> it's a low cost solution for sure :)
<rogpeppe> zyga: yeah, maybe. it needs to work reliably over a period of years
<rogpeppe> zyga: and deal ok with power outages on the order of days
<zyga> days?
<zyga> I have a pi zero wireless
<zyga> that's powered from a power bank with USB-C power delivery
<rogpeppe> zyga: yeah, this is in a fairly remote area of scotland and power outages aren't uncommon
<zyga> a larger one actually
<zyga> it lets the pi run for about a week
<zyga> I didn't try it with a more power-hungry device
<zyga> it's neat because I can use USB-C to charge the battery
<rogpeppe> zyga: the other thing i'm considering is a small pi zero or something to act as a monitor and reboot if needed, because i've seen some hangups where the pi doesn't autoreboot on crash
<zyga> while powering the PI or other devkit from the other connector
<zyga> rogpeppe: yeah, the pi doesn't have a watchdog
<zyga> so it's not reliable in this sense unfortunately
<rogpeppe> zyga: i remember seeing a UPS device that also included a real time clock, which would be ideal, but i can't seem to find it now
<zyga> gee, I wish USB battery packs could convey their charge over USB
<rogpeppe> ha, that would be cool
<zyga> yeah
<zyga> too bad USB is such a mess
<zyga> I think USB-PD is better in this regard
<rogpeppe> at least the pi doesn't seem to go back in time any more - that was a real pain for my app
<zyga> rogpeppe: that's another bug
<zyga> a combination of bugs actually
<zyga> pi has no RTC with battery power
<rogpeppe> hmm, that's twice now that this pi has scheduled a reboot and not managed to come out of it
<zyga> so each reboot it's back to 1970s
<zyga> so we used some timestamps to establish "less insane wrong time"
<zyga> like the stamp on some files in FAT
<rogpeppe> yes, that's definitely better
<zyga> but you really only get working time after you ntp
<zyga> so offline you are still in the past on reboot
<zyga> we also changed things so that time is saved back to fat on reboot
<zyga> so it's not perfect but much better
<zyga> rogpeppe: if you can get any logs that would be good
<rogpeppe> and it just failed again after powering off/on, but then succeeded the next time. i'm a bit concerned about reliablilty here.
<zyga> if you can image the SD card and help us with forensics that would be perfect
<rogpeppe> zyga: what logs would you look at?
<zyga> many things
<rogpeppe> zyga: it's booted ok again now
<zyga> snap changes to understand what snapd was doing
<zyga> journal to see what the system was doing
<zyga> the full card image to look for FAT corruption or other magic
<zyga> it all depends on initial analysis
<zyga> one small tip
<zyga> if you enable persistent journal
<zyga> you can see what happened in the past better
<zyga> mkdir /var/log/journal
<zyga> and reboot
<rogpeppe> zyga: the first time it rebooted, i got it to reboot again after a couple of tries, and the snap was still half way through installing
<zyga> rogpeppe: that's normal
<rogpeppe> zyga: i think that it decided to reboot again after it had installed (and it failed again)
<rogpeppe> zyga: oh really? ok i guess.
<zyga> rogpeppe: when snapd / kernel or other essential snap updates some updates are postponed until after that one fully finished
<zyga> which may include a reboot
<zyga> but if it reboots like 3 times that's curious
<zyga> if you can ssh and check "snap changes" that would help
<rogpeppe> zyga: i'd hope the card wasn't corrupted, as i've only just flashed it
<zyga> SD cards can permanently fail
<zyga> use a flashing tool that verifies each block
<zyga> like etcher does
<rogpeppe> zyga: when the reboot fails, it fails quickly - i don't get the core splash screen
<zyga> it's useful to spot flaky cards outright
<zyga> do you have "hands on" access to the device now?
<rogpeppe> zyga: yup
<zyga> I can recommend attaching a serial adapter to the pins on the PI
<rogpeppe> zyga: for a few hours before i need to leave
<zyga> it's useful to see what's going on early
<zyga> you can plug that to another device for monitoring
<rogpeppe> zyga: i haven't got a serial adaptor here i'm afraid
<zyga> e.g. even another PI
<zyga> rogpeppe: ah, too bad, it's useful
<rogpeppe> zyga: i should get hold of one
<zyga> USB-TTL adapters, grab a few next time on ebay
<zyga> it's mostly useful to see early boot logic
<zyga> as we log what's going on
<zyga> especially kernel / rootfs selection
<zyga> and boot mode
<rogpeppe> zyga: i presume that's not TTL as in TTL-logic
<zyga> (normal or trying new kernel or new rootfs)
<zyga> they are just called TTL to differentiate from "high" voltage real serial ports
<zyga> on pi it's 3.3V AFAIK
<rogpeppe> i think i'm behind the times on acronyms :)
<zyga> :D
<rogpeppe> FWIW when it fails to boot, the it takes about a couple of seconds before the permanent red light comes on
<zyga> which PI variant is tihs?
<zyga> *this
<zyga> speaking of which, I need to place that backorder on Pi 4 finally
<zyga> the 4GB variant is never in stock, it seems
<zyga> if it shows anything is that pi 5 will have an 8GB version
<zyga> and a SATA port ;-)
<rogpeppe> zyga: it's a pi 3, but i can't remember which exact variant. how do i tell?
<zyga> cat /proc/cpuinfo
<rogpeppe> zyga: is this the etcher tool you were talking about? https://www.techspot.com/downloads/6931-etcher.html
<zyga> yeah
<zyga> now owned by balena
<zyga> https://www.balena.io/etcher/
<zyga> still FOSS, just a way to point to a company
<rogpeppe> http://paste.ubuntu.com/p/3m8k66gtVS/
<zyga> it's remarkably good
<zyga> one sec
<zyga> that's PI 3B
<zyga> no, wait
 * zyga rechecks
<zyga> that could be 3B+
<zyga> does it have a metal can on the CPU?
<zyga> if so that's the 3B+ which needs way more power to work
<zyga> (but is also faster)
<rogpeppe> not sure. i think the cpu might be covered up by the piglow device i've got plugged in
<zyga> oh, you have pilgow?
<zyga> let me share one thing I made
<zyga> https://github.com/zyga/snappy-pi2-piglow
<zyga> it's for the time when snapd interfaces were still called "snappy skills"
<rogpeppe> ah, i've found the order: Raspberry Pi 3 Model B Quad Core CPU 1.2 GHz 1 GB RAM Motherboard
<zyga> mmm
<zyga> I should update that piglow repo to more recent snappy standards :)
<rogpeppe> i built a nice piglow library in Go
<rogpeppe> https://godoc.org/github.com/rogpeppe/misc/piglow
<rogpeppe> it's designed to work ok if used concurrently
<rogpeppe> and a command too: https://godoc.org/github.com/rogpeppe/misc/cmd/piglow
<zyga> I went to check out the gamma table :D
<rogpeppe> i'd totally forgotten about that until now :)
<zyga> I used https://github.com/zyga/snappy-pi2-piglow/blob/master/sn3218.c#L30
<rogpeppe> i think i probably nicked the gamma table from somewhere else
<zyga> I don't recall how I got those values now
<zyga> I _may_ have used something to measure the output at the time
<zyga> it was when I was still doing hardware fun projects
<rogpeppe> ha, i even gave it credit: // Stolen from github.com/benleb/PyGlow.
<zyga> yeah :)
<zyga> I'm back to tinkering
<rogpeppe> zyga: sadly it seems like my command has rotted and no longer works :(
<mup> PR snapcraft#2704 closed: extensions: create the gnome-platform directory <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2704>
<mup> PR snapcraft#2705 closed: extensions: rename extension classes to known names <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2705>
#snappy 2019-09-08
<ardaguclu_> dirs package uses osutil only for DirExists function, cutting this dependency copying DirExists into dirs package isn't meaningful?
<mup> PR snapcraft#2706 closed: extensions: improve docsting (used in the cli) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2706>
#snappy 2020-08-31
<mborzecki> morning
<mborzecki> ha, i'm not the one seeing osx failures
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mup> PR snapd#9211 closed: o/snapstate: disk space check with InstallMany <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9211>
<mborzecki> pstolowski: heya
<pstolowski> hi!
<mvo> hey pstolowski ! good morning
<pstolowski> hey mvo!
<zyga> good morning
<mup> PR snapd#9239 closed: many: misc doc-comment changes and typo fixes <Simple ð> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9239>
<pstolowski> ehhh @systemd
<pedronis> pstolowski: mvo: hi, do we need to have a chat about disk space checks?
<zyga> pstolowski: problems?
<mvo> pedronis, pstolowski maybe, I'm not super worried. was mostly thinking about something simple (like a system option) to disable the checks
<pedronis> mvo: well, some checks have landed already
<mup> PR snapd#9242 opened: github: run macOS job with Go 1.14 <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9242>
<mborzecki> heh, it's green (the macos job at least)
<mborzecki> zyga: can you take a look ^^^ ?
<pedronis> zyga: can you look at https://bugs.launchpad.net/snapd/+bug/1892895 when you have a moment
<mup> Bug #1892895: unable to allow an app to access all devices with a certain major number via a <majordev>:* device cgroup rule <snapd:New for zyga> <https://launchpad.net/bugs/1892895>
<pedronis> mborzecki: mvo: are we working on this https://bugs.launchpad.net/snapd/+bug/1776622 ?
<mup> Bug #1776622: snapd updates on focal never finish installing. Can't install any other updates. <amd64> <apport-bug> <champagne> <focal> <regression> <snapd:Confirmed for mvo> <snapd (Ubuntu):Confirmed for mvo> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1776622>
<pstolowski> pedronis: systemctl status check (what we discussed last friday wrt --root semantics difference when unit is missing) is going to be messy or maybe we need to do something else, the bahvior of systemctl status is different in 14.04. i wonder if we shouldn't land https://github.com/snapcore/snapd/pull/9241/ to unblock services PR (and in the meantime i'll work on a solution)
<mup> PR #9241: tests: do not set rsyslog.disable in core18 config defaults test <Test Robustness> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9241>
<pedronis> pstolowski: it's a real issue, no? is not just the tests
<zyga> re
<zyga> mborzecki, pedronis: ack
<zyga> (my laptop suspended during my 1:1)
<zyga> that udev permission issue is very interesting
<zyga> it kind of forces us to re-think the entire cgroup access logic
<zyga> but, there is some hope that cgroupv2 mode may allow us to do this race free
<zyga> mborzecki: reviewed
<zyga> pedronis: we should talk about that during the standup a little
<zyga> pedronis: I'll think about this and write down some ideas
<pstolowski> pedronis: it's an issue if the config flag is set (e.g. via defaults) but the service file doesn't exist
<pstolowski> i suppose it would be an issue if flag was set and then the service was uninstalled
<mup> PR snapd#9242 closed: github: run macOS job with Go 1.14 <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9242>
<mup> PR snapd#9202 closed: tests/nested/core20/tpm: verify trusted boot assets tracking  <Run nested> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9202>
<mborzecki> the nested suite seems to be doing strage stuff and the state from one test seems to leak to the next one
<mborzecki> see https://github.com/snapcore/snapd/runs/1050105329
<mborzecki> https://github.com/snapcore/snapd/runs/1050105322 this one
<zyga> hmm, let's tell sergio about it
<zyga> hopefully the nested fixes he was doing will help
<mvo> hm, I see some failures in macos-sanity in or 9238
<mvo> did we acciently break that?
<mvo> I also noticed it was not a required check :( I fixed that now
<mborzecki> mvo: it's fixed already, merge master please
<mvo> mborzecki: ta
<mup> PR snapd#9238 closed: many: check that users of BaseTest don't forget to consume cleanups <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9238>
<mvo> pedronis: I replied in 1776622
<mvo> pedronis: (just fyi)
<zyga> pedronis: small question on now-merged https://github.com/snapcore/snapd/pull/9238/files#r480014070
<mup> PR #9238: many: check that users of BaseTest don't forget to consume cleanups <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9238>
<mborzecki> zyga: the new set of denials in https://github.com/snapcore/snapd/pull/9204 looks sane
<mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
<mup> PR snapd#9240 closed: o/devicestate/devicestate_cloudinit_test.go: test cleanup for uc20 cloud-init tests <Simple ð> <Skip spread> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9240>
<mborzecki> zyga: left a note with a snippet that you can try adding to the policy https://github.com/snapcore/snapd/pull/9204#issuecomment-683683132
<mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
<mup> PR snapd#9224 closed: interfaces/utf: Add MIRKey to u2f devices <Needs security review> <Created by kobusgrobler> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9224>
<zyga> mborzecki: thank you, I'll do that
<mup> PR snapd#9243 opened: testutil: add checkers for symbolic link target <Created by zyga> <https://github.com/snapcore/snapd/pull/9243>
<zyga> mborzecki: updated, I also left a TODO to implement the equivalent session bus permission
<zyga> mborzecki: but our tests are not measuring that yet
<mborzecki> zyga: cool, let's see what will fail this time ;)
 * pstolowski lunch
<zyga> hexchat got stuck on ssl somehow
 * zyga lunch
<pedronis> cmatsuoka: I answered your doubt, hopefully correctly, in mborzecki PR
<cmatsuoka> pedronis: thanks, I'll check there
<mup> PR snapd#9201 closed: boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>
<mborzecki> pedronis: thanks, there was an implicit call to reseal the key after the first backup pass in BeforeWrite()
<cmatsuoka> pedronis: ah, that was what I thought too
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/9204#discussion_r480115407
<mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/9204>
<zyga> mborzecki: in one or in both places?
<mborzecki> zyga: just the closing ')
<mborzecki> zyga: the opening one is (`
<zyga> ah, ok
<zyga> thanks
<jdstrand> kenvandine: fyi, I've seen that firefox font thing several times since we last talked. unfortunately, I've had no time to debug :\
<jdstrand> restarting the browser does seem to correct it. that is pretty much the extent of debugging I can do atm
<mup> PR snapd#9244 opened: boot: add unit test helpers <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9244>
<cachio> pstolowski, hey, I see the preseed-lxd test failing today
<mborzecki> cmatsuoka: ijohnson: ^^ trivial PR
<cachio> pstolowski, did you see that as well?
<ijohnson> mborzecki: sure
<pstolowski> cachio: no, do you have a link?
<cmatsuoka> mborzecki: checking...
<ijohnson> mborzecki: could you also look at https://github.com/snapcore/snapd/pull/9207 ? just needs another +1
<mup> PR #9207: boot/bootstate20: reboot to rollback to previous kernel <Bug> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9207>
<cachio> pstolowski, https://github.com/snapcore/snapd/pull/9098/checks?check_run_id=1051196015#step:5:1115
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<mborzecki> ijohnson: sure
<ijohnson> thanks!
<pstolowski> cachio: is this on your PR?
<cachio> yes
<cachio> pstolowski, I updated nested
<cachio> but also the images were updated
<cachio> so I dont know what could hte the root cause
<cmatsuoka> mborzecki: added a question there about bootloader.Force(nil)
<pstolowski> cachio: /home/gopath/src/github.com/snapcore/snapd/tests/lib/preseed.sh: line 66: /mnt/cloudimg/var/lib/snapd/seed/seed.yaml: No such file or directory
<cachio> pstolowski, 6 hours ago the images in the bucked were updated
<pstolowski> cachio: it seems this path in inject_snap_into_seed is no longer valid
<mborzecki> cmatsuoka: the helper already adds a cleanup via .AddCleanup()
<cmatsuoka> mborzecki: ah ok
<cachio> pstolowski, I'll try with master to discard the problem is in my pr
<ijohnson> cachio: pstolowski: how are the tests failing ?
<mborzecki> cmatsuoka: see https://github.com/snapcore/snapd/pull/9244/files/accda18257efd4aedf6d32b3d5704709b02d50ca#diff-a69542b9519987a9ee6b8ef3f670f3cbR64
<mup> PR #9244: boot: add unit test helpers <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9244>
 * ijohnson may have written inject_snap_into_seed IIRC
<cachio> ijohnson, https://github.com/snapcore/snapd/pull/9098/checks?check_run_id=1051196015#step:5:1115
<mup> PR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>
<cachio> this is the log
<ijohnson> cachio: that link is 500 for me
<ijohnson> oh well I can just look at the PR
<cachio> 1 sec
<cachio> ijohnson, https://paste.ubuntu.com/p/gyQnPVgCNV/
<ijohnson> cachio: thanks looking now
<cachio> ijohnson, I am running on master just to see if the error is not caused by my PR
<ijohnson> cachio: that cloud image has no snaps seeded in it at all
<ijohnson> pstolowski: ^
<ijohnson> I just mounted it and this is what is in /var/lib/snapd/:
<ijohnson> https://pastebin.ubuntu.com/p/FPXJfThJ3X/
<pstolowski> ð¤
<ijohnson> seems to be a busted image to me if they dropped all snaps from the image
<mup> PR snapd#9244 closed: boot: add unit test helpers <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9244>
<pstolowski> ijohnson: can you ask/check on preseed channel?
<ijohnson> pstolowski: sure
<pstolowski> thanks
<ijohnson> pstolowski: cachio: actually before I ask, where does this image come from?
<ijohnson> cachio: I downloaded the same img as the spread test:
<ijohnson> https://storage.googleapis.com/spread-snapd-tests/images/cloudimg/bionic-server-cloudimg-amd64.img
<ijohnson> cachio: that looks like an image you maintain, is there maybe something wrong with your image there ?
<ijohnson> in the meantime, I am trying the generic image link from https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img
<cachio> ijohnson, 1 sec
<cachio> ijohnson, https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img
<cachio> this is the same Image
<ijohnson> cachio: that image from cloud-images.ubuntu.com also doesn't have snaps on it, so yeah I'll take it upstream
<ijohnson> thanks
<cachio> I copy that to gce weekly
<cachio> yaw
<mup> PR snapd#9245 opened: o/snapstate, features: add feature flags for disk space awareness <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9245>
<ijohnson> cmatsuoka: have you see install fail with this before:
<ijohnson> ```
<ijohnson> taskrunner.go:271: [change 2 "Setup system for run mode" task] failed: cannot create partitions: cannot create the partitions: partition not available: device /dev/vda4 not available
<ijohnson> ```
<cmatsuoka> ijohnson: humm, no, never seen that
<cmatsuoka> ijohnson: is it a special scenario/device?
<ijohnson> cmatsuoka: no it's from nested tests on GCE, one sec I can provide full logs (well as full as we have)
<ijohnson> cachio: huh I think something may have gone wrong with your test / organization
<ijohnson> cachio: the command being run is
<ijohnson> ` IMGURL=$(get_google_image_url_for_nested_vm ubuntu-20.04-64)`
<ijohnson> but the image it downloaded is a bionic image ?
<cachio> ijohnson, ran with master and passed
<cachio> to the issue is in my PR
<cachio> ijohnson, thanks for the hint, I'll take a look
<ijohnson> cachio: yeah I think your PR has a problem resolveing `nested_get_image_url_for_vm ubuntu-20.04-64` to a bionic image
<ijohnson> it should be getting a focal image
<ijohnson> cmatsuoka: https://pastebin.ubuntu.com/p/VdqWrf5qGS/ is the full log we have from spread
<cmatsuoka> ijohnson: ok, checking...
<mborzecki> ijohnson: restarted the spread job in 9207
<ijohnson> mborzecki: ohhhh
<ijohnson> I was looking at the spread logs
<ijohnson> ok seems I have the logs saved
<pstolowski> ijohnson: thanks for figuring that out
<ijohnson> np
<ijohnson> cachio: the issue with getting the wrong URL is that the function nested_get_image_url_for_vm takes an argument, but it isn't passing that argument through to the function nested_get_google_image_url_for_vm
<cachio> ijohnson, yes, I already fixed that
<cachio> now testing
<ijohnson> cachio: ah ok, I just left a review on your PR for that
<cachio> ijohnson, thanks
<mborzecki> errands, bbl
<mup> PR snapd#9246 opened: boot: handle canceled update <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9246>
<cmatsuoka> ijohnson: that's a very strange error, it seems that for some reason the device node is not there, even retriggering udev
<cmatsuoka> ijohnson: is it random or reproducible?
<ijohnson> cmatsuoka: I dunno I didn't try reproducing it yet
<ijohnson> I haven't ever seen it before though
<cachio> ijohnson, fix pushed
 * cachio lunch
 * zyga EODs and prepares for PT
<mup> PR snapd#9207 closed: boot/bootstate20: reboot to rollback to previous kernel <Bug> <Run nested> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9207>
<cmatsuoka> ijohnson: could you have a look at https://github.com/snapcore/snapd/pull/9138?
<mup> PR #9138: many: refactor tpm seal parameter setting <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9138>
<cmatsuoka> ijohnson: it should make the seal transition to boot a lot easier
<ijohnson> cmatsuoka: yes I will look today
<cmatsuoka> thanks
<mup> PR snapcraft#3269 opened: spread tests: remove references of core16 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3269>
<cachio> ijohnson, about the comment related to SC2120
<ijohnson> yes?
<cachio> I just copied the same we had for the google function
<cachio> because the unit test checks that and fails
<ijohnson> cachio: ok, if it fails leave it in
<cachio> ijohnson, ok, thanks
<ijohnson> I'm slightly surprised that we don't run shellcheck in such a way that shellcheck could see how the script is used, but oh well
<ijohnson> s/script/function/
<ijohnson> cachio: I reviewed #9235, I'm not sure whether we should go this route or not yet
<mup> PR #9235: tests: new tests for nested and external <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9235>
<ijohnson> cachio: I would like to see some others comment on the approach, perhaps zyga could take a look when available
<cachio> ijohnson, thanks for the review
<cachio> this should go after 9098
<ijohnson> yes
<cachio> I'll tag it
<cachio> ijohnson, I'll try to implement something like you suggested in 9235
<ijohnson> cachio: don't spend too much time on it, maybe others think this approach is ok, in which case I wouldn't want you to waste a bunch of time on implementing my suggestion
<cachio> ijohnson, we also could have tests duplicated :)
<ijohnson> cachio: true that's another option :-)
<cachio> because there are just few we need to run in both worlds
<cachio> I'll ask in the standup tomorrow
<ijohnson> yeah maybe
<mup> PR snapd#9247 opened: secboot: use EFIImage type in load sequences <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9247>
<mup> PR snapcraft#3270 opened: Add PYTHONPATH to environment (fixes #1893262) <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/3270>
<cmatsuoka> pedronis: it's easy to compose the boot chains using slice of BootImage defined in bootloader, however how do you envision the actual chain parameters being passed to the sealer?
<pedronis> cmatsuoka: ?
<cmatsuoka> pedronis: do you have time for a quick chat?
<pedronis> cmatsuoka: yes, in a couple minutes
<cmatsuoka> pedronis: thanks, I'll be in the su room
<mup> PR snapd#9248 opened: exportstate: add scaffolding for the export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9248>
<zyga> pedronis: ^ some early code for the export manager, I would appreciate ack/nack on the data structures / names
<zyga> pedronis: but you should really get some rest, let's look at it tomorrow
<cachio> zyga, hey, about zfs
<cachio> which should be the idea of that image?
<cachio> everyhing zfs?
<zyga> cachio: the 20.04 image offers a new installer option to use zfs
<zyga> cachio: it should be representative of that image
<zyga> cachio: it's a complex setup, please try a desktop install to examine it
<cachio> zyga, I see
<cachio> I'll do that
<zyga> cachio: zfs uses lots of mount points for everything,
<cachio> and see if it is possible to replicated that for gce
<zyga> cachio: it's not like ext4 but zfs
<zyga> cachio: try a desktop image locally in qemu or otherwise first
<zyga> cachio: to see how that looks like
<cachio> zyga, ok, I'll start with that
<cachio> tx
<zyga> cachio: no, thank you :)
<mup> PR snapd#9247 closed: secboot: use EFIImage type in load sequences <Simple ð> <UC20> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/9247>
<pedronis> ijohnson: cmatsuoka: I went ahead in the end and proposed this: https://github.com/snapcore/snapd/pull/9249
<mup> PR #9249: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9249>
<ijohnson> pedronis: ack
<pedronis> cmatsuoka: the Role type there might be useful for you as well
<cmatsuoka> pedronis: will check, thanks
<ijohnson> mmm I like this, Role seems much more intuitive
<mup> PR snapd#9249 opened: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9249>
<cachio> ijohnson, hi
<ijohnson> hey cachio
<cachio> running in nested I see that if I stop the vm and the service sometimes the users that I created cant login anymore
<cachio> so, first I create the instace, then I start it
<cachio> then I create the test and external users
<cachio> then I shutdown the vm and stop the service
<cachio> I do that because I need to backup the vm for future tests
<ijohnson> cachio: how are you shutting down the VM ?
<cachio> > shutdown now
<cachio> run shoutdown now
<cachio> when I cannot connect through ssh
<cachio> I stop the service
<ijohnson> cachio: before running that, on the host (not in the VM), you should run `sync`, I have seen before where if you do not sync state then file changes in the nested VM disappears
<cachio> ijohnson, ahhh, nice
<cachio> so sync in the host
<ijohnson> it's probably a bug somewhere
<ijohnson> but yeah on the host is what fixed it for me
<cachio> ijohnson, thanks, I'll try that
<ijohnson> this happened reliably to me when I was working on the cloud-init nested tests
<cachio> ijohnson, I remember that you told it in the stand up
<ijohnson> yeah hopefully this works for you
 * cachio afk
<mup> PR snapd#9250 opened: Uc20 bootloader boot image <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9250>
#snappy 2020-09-01
<mup> PR snapcraft#3271 opened: build providers: use the releases endpoint for LXD <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3271>
<mup> PR snapcraft#3272 opened: storeapi: improve to channel map docstrings <bug> <documentation> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3272>
<clmsy> Hello everyone! any chance we have a date in mind for this milestone :) https://launchpad.net/snapd/+milestone/2.46 ?
<pstolowski> morning
<mvo> good morning pstolowski
<mup> PR snapd#9251 opened: o/snapstate, features: add feature flag for disk space check on remove <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9251>
<mup> PR core#117 closed: extrafiles/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/core/pull/117>
<mup> PR snapd#9138 closed: many: refactor tpm seal parameter setting <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9138>
<zyga> I need a review for a test helper https://github.com/snapcore/snapd/pull/9243
<mup> PR #9243: testutil: add checkers for symbolic link target <Created by zyga> <https://github.com/snapcore/snapd/pull/9243>
<zyga> this will unblock my other patches as they all rely on it
<zyga> tests/main/interfaces-cups-control  is failing in a weird way on 20.10
<zyga> lpr: Error - no default destination available.
<zyga> it looks like really wants to print
<zyga> ok, I'll make coffee and will return shortly
<mup> PR snapd#8843 closed: [RFC] many: export tools from core/snapd to mount namespaces <Needs Samuele review> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8843>
<zyga> back with coffee
<zyga> mvo good morning
<zyga> how was your luck yesterday?
 * zyga spends a moment to move hexchat config to a different host
<zyga> now to prepare a ZFS test environment
<zyga> I have a pair of old 10K RPM drives
<zyga> perfect for scratch disks
<zyga> now to install them
<zyga> I live very far away from train  tracks but once a day a huge cargo train supplies the power plan and uses the horn/whistle while crossing roads
<zyga> that sound travels!
<zyga> drives installed, let's do ZFS
<mvo> zyga: hey, sorry in various meetings this morning
<zyga> hmm, I think I didn't plug power
<zyga> mvo no worries, how are you doing?
<zyga> thank you for the review on the test helper
<mvo> zyga: doing fine, wish I had more time for $things but that's it
<zyga> mvo I'm sorry, maybe it will be better with time
 * zyga checks cables as disk are not detected in bios or anywhere
<zyga> got it, the power cable was unplugged :D
<zyga-x240> ok, disks are working
<zyga> all this rebooting
<zyga> the drives have an MD array and I want to take a peek before wiping them
<mup> PR snapd#9241 closed: tests: do not set rsyslog.disable in core18 config defaults test <Test Robustness> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/9241>
<zyga-x240> pstolowski: would you mind doing a 2nd review on a small test helper
<zyga-x240> https://github.com/snapcore/snapd/pull/9243
<mup> PR #9243: testutil: add checkers for symbolic link target <Created by zyga> <https://github.com/snapcore/snapd/pull/9243>
<pedronis> mvo: I re-reviewed #9210
<mup> PR #9210: daemon: add /v2/systems "reboot" action API <Created by mvo5> <https://github.com/snapcore/snapd/pull/9210>
<mvo> pedronis: \o/ thank you
<zyga-kaveri> I've installed ZFS and am familiarizing myself with the CLI
<pstolowski> zyga-kaveri: sure
<zyga-kaveri> pstolowski: thank you, it's simple and unlocks interesting code
<zyga-kaveri> pstolowski: thank you
<mup> PR snapd#9243 closed: testutil: add checkers for symbolic link target <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9243>
<zyga-kaveri> playing with zfs
<zyga-kaveri> I used zfs on freebsd a long while ago
<zyga-kaveri> most things are similar but I don't remember the details
<zyga-kaveri> first odd thing is that creating a pool called "test" mounted it at /test
<mup> PR snapd#9252 opened: osutil: add ExchangeFiles <Created by zyga> <https://github.com/snapcore/snapd/pull/9252>
<zyga-kaveri> so I played with zfs, renameat2() fails with EINVAL, we just need to code the flock-based replacement for that
<zyga-kaveri> I'll do that now
<mup> PR snapd#9253 opened: sysconfig/cloudinit.go: add AllowCloudInit and use GadgetDir for cloud.conf <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9253>
<zyga-kaveri> mvo: I figured out why my sound broke
<zyga-kaveri> mvo: I booted a VM, this re-configures bluetooth and stuff falls a apart, known issue in vmware
<zyga-kaveri> mvo: I routinely boot infrequently used VMs to upgrade them during standup calls
<zyga-kaveri> so now I know ;0
<mvo> zyga-kaveri: ok
<ijohnson> zyga-kaveri: why the new IRC nick ?
<zyga-kaveri> ijohnson: I don't use irc cloud for a while
<zyga-kaveri> ijohnson: so each of my systems uses a distinct one to avoid clashes
<ijohnson> zyga-kaveri: right but what does kaveri mean
<ijohnson> ah I see, that's one of your machines
<zyga-kaveri> ijohnson: this is my old kaveri FM2 system
<zyga-kaveri> ijohnson: it's a AMD APU fro 2016 IIRC
<zyga-kaveri> *from
<ijohnson> ah it's an amd processor line
<zyga-kaveri> ijohnson: it's native too :)
<ijohnson> nice
<zyga-kaveri> ijohnson: I have zyga-matisse as well but that's not booted now :) (upgrades)
<zyga-kaveri> but I probably won't use it for daily work as this box is good enough for typing
<ijohnson> zyga-kaveri: I see makes sense
<ijohnson> after my irccloud subscription runs out, I'm going to try and migrate IRC to mattermost with the bridge and see how that fares
<ijohnson> I've heard mixed reviews of using the bridge like that
<ijohnson> it would be nice to have all chats in one app though
<cmatsuoka> pedronis: I have some questions related to bootloader boot chains, please let me know when you have some time to discuss
<zyga-kaveri> ijohnson: interesting, let me know how that works
<ijohnson> yeah I'm hoping it works out fine, remains to be seen how resilient / robust my local network connection actually is to get 24 hr connections, I'm sure it will cut out and I will lose/reconnect the bridge every so often
<zyga-kaveri> ah, so the bridge is local?
<zyga-kaveri> s
<mvo> pstolowski: I merged 9251 it will need a dedicated PR for 2.46. cherry pick has conflicts unfortunately
<mup> PR snapd#9251 closed: o/snapstate, features: add feature flag for disk space check on remove <Disk space awareness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9251>
<pedronis> cmatsuoka: we can chat before the 2nd Town Hall or after it? do you have a preference?
<cmatsuoka> I have both slots open, either will do
<pedronis> cmatsuoka: how much time do you think we need?
<cmatsuoka> pedronis: ten minutes or so, it should be a quick alignment
<pedronis> ok
<pedronis> cmatsuoka: done
<cmatsuoka> pedronis: thanks
<pstolowski> mvo: yes, i was expecting it due to the safeMargin helper
<pstolowski> mvo: i'll prepare it
<mvo> pstolowski: ta
<mup> PR snapcraft#3273 opened: spread tests: lock down setuptools for plainbox <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3273>
<pedronis> ijohnson: I forgot about also this option: https://github.com/snapcore/snapd/pull/9237#discussion_r481169582
<mup> PR #9237: [RFC] many: enable cloud-init on uc20 for grade signed and secured <Complex> <Run nested> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9237>
<ijohnson> sorry was afk a bit, silly plumbing problems with our new faucet
<ijohnson> pedronis: looking
<ijohnson> pedronis: right yes that's true in general, but numbering the files we copy from seed is an orthogonal concern to the current PR
<ijohnson> or maybe it's not, just that this PR doesn't change how files from seed are handled
<pedronis> ijohnson: yes, but changes the reasoning around picking a number there
<ijohnson> pedronis: how does the numbering scheme for files from seed affect the numebring scheme for the gadget ?
<pedronis> ijohnson: because the question we discussed the last time
<ijohnson> pedronis: I have not yet talked with the maas/curtin team about what numbering scheme they use and what we should fit into with that
<pedronis> ijohnson: (in a differe meeting I will get back to you in a bit)
<ijohnson> ok
<pedronis> ijohnson: my point is that we know we have the option to renumber, we don't have to pick a number based on what we expect the numbering used by curtin, we can decide when we renumber whether to renumber before or after our chosen number
<pedronis> ijohnson: we can pick 70- and make what comes from the seed either 69- or 71-
<pedronis> for example
<pedronis> depending the sematics we want
<ijohnson> ok, so does that mean we want the gadget cloud.conf to be 70 ?
<pedronis> ijohnson: I would pick "80_" as prefix
<ijohnson> pedronis: ok
<pedronis> ijohnson: I proposed something, but not 100% happy with it yet
<ijohnson> ah I forgot to fix that PR I just opened with the filename
 * ijohnson has too many open branches / prs
<cachio> zyga-kaveri, bad news, my zfs instance is not booting anymore locally, need to see which dependency caused that
<cachio> zyga-kaveri, I have a snapshot to restore
 * cachio lunch
<pstolowski> mvo: opened https://github.com/snapcore/snapd/pull/9255 ; it's slightly annoying, it's a single cherry pick but i guess it will conflict when marging back (not sure)
<mup> PR #9255: o/snapstate, features: add feature flag for disk space check on remove (2.46) <Created by stolowski> <https://github.com/snapcore/snapd/pull/9255>
<zyga-kaveri> cachio: ok, keep me poosted please
<pstolowski> mvo: basically it depended on the new helper and new error type name from another PR, but it's impossible to cherry pick those as they already depended on install-many changes
<mup> PR snapd#9254 opened: sysconfig/cloudinit.go: add DisableNoCloud to CloudInitRestrictOptions <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9254>
<mup> PR snapd#9255 opened: o/snapstate, features: add feature flag for disk space check on remove (2.46) <Created by stolowski> <https://github.com/snapcore/snapd/pull/9255>
<mvo> pstolowski: thanks, that's ok - unavoidable sometimes
<zyga-kaveri> mvo: thank you for the review
<pedronis> #9249 needs a 2nd review
<mup> PR #9249: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9249>
<ijohnson> pedronis: I reviewed 9249
<mup> PR core20#83 opened: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <https://github.com/snapcore/core20/pull/83>
<mup> PR core18#167 opened: static/writable-paths: make /etc/default/crda writable <Created by anonymouse64> <https://github.com/snapcore/core18/pull/167>
<cachio> zyga-kaveri, this is better
<cachio> https://blog.iqonda.net/ubuntu-server-20-04-zfs-root-and-oci/
<cachio> I'll try that
<cachio> zyga-kaveri, it is very hard to create a cloud image based on a desktop because I need to upload 4 GB to gcloud and I tried but at some point my internet breanks and the upload too
<pedronis> ijohnson: thanks I'll merge it and consider your comments for a follow, so cmatsuoka can possibly start using Role and its constants
<ijohnson> pedronis: sure that's fine
<cmatsuoka> pedronis: thanks, I'll use it in BootFile
<mup> PR snapd#9249 closed: boot,bootloader,gadget: apply new bootloader.Options.Role <Run nested> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9249>
<pedronis> ijohnson: created https://github.com/snapcore/snapd/pull/9256
<mup> PR #9256: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <https://github.com/snapcore/snapd/pull/9256>
<ijohnson> cool I'll have a look
<ijohnson> +1
<mup> PR snapd#9256 opened: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <https://github.com/snapcore/snapd/pull/9256>
<ijohnson> why is our assertion database so complicated :-(
<pedronis> ijohnson: anything in particular?
<ijohnson> pedronis: I am still fighting getting uc20 with test keys to finish seeding properly, I thought I had it working with just seeding the fake snapd snap, but then realized it was failing to seed actually because snap-bootstrap needs to be built with test keys too, so I need to seed both the fake snapd snap and the fake kernel snap and now my change I made to prepare-image to pick up the local assert files isn't working
<ijohnson> for multiple fake snaps
<ijohnson> what's confusing right now is that I add these assertions to the db, then immediately after seedwriter goes to find those assertions and doesn't find them somehow
<pedronis> you made a change to prepare-image ?
<ijohnson> pedronis: yes I have to change prepare-image, as it doesn't work with the test keys as I mentioned in the SU doc
<ijohnson> I changed it to (try to) import/use assert files matching the --snap file arguments
<ijohnson> otherwise, prepare-image thinks all --snap arguments are dangerous unasserted snaps
<pedronis> this is going to be very hard to land
<ijohnson> mmm
<ijohnson> I mean it's getting very hard just to get working
<ijohnson> unless I'm missing something very obvious
<pedronis> ijohnson: my idea was to point prepare-image to the fakestore
<pedronis> and have the snaps there
<ijohnson> pedronis: yeah I guess I haven't tried that yet, perhaps I should try that instead of pointing prepare-image at everything locally
<pedronis> I thought at least one of the tests I mentioned does that
<ijohnson> yes there is an example of that there, it just seemed like more work than using the local files/assertions but actually in hindsight it is probably less work if it just works
<ijohnson> it just _feels_ like providing local assertions and files to prepare-image should be simpler
<pedronis> ijohnson: the problem with what you are trying is that there's no design for it
<ijohnson> that's also what I'm confused about, because ubuntu-image specifically works like this, and I thought it worked like this because of prepare-image, but perhaps ubuntu-image has it's own magic
<ijohnson> because I can do `ubuntu-image --snap=my-local-snap.snap` and if there's an my-local-snap.assert file, then the snap is not treated as unasserted
<ijohnson> but prepare-image doesn't work that way it seems
<pedronis> ijohnson: yes, but you still need the fake store
<ijohnson> does ubuntu-image use the fake store ?
<pedronis> ijohnson: what happens in that case is that the file is locally but the assertions come from the store
<ijohnson> pedronis: ahhhhhhhhhh so it's cheating really
<ijohnson> well that's just silly but ok
<ijohnson> alright I will switch to trying to use fakestore as a proxy
<pedronis> is not silly
<pedronis> but is not very intuitive
<ijohnson> ... but what if you wanted to build an image without a connection to the store ? you have the assert files and the snap files, but you still need to talk to the store because ... ?
<ijohnson> anyways it's not material at this point I suppose
<pedronis> that's not the use case that was added for
<pedronis> the use case is I have kept old snaps and I want to rebuild an image excactly with those
<pedronis> it also shows up in some usage pattern when building classic images
<ijohnson> sorry I guess as a user it just feels very weird to say "here take these snaps and assertions and build me an image with them" and snapd then proceeds to ignore the assertions provided and goes and gets it's own assertions from the storyt
<pedronis> there's no way to say take this assertion atm though
<ijohnson> haha yes that is quite clear to me now
<mup> PR snapcraft#3273 closed: spread tests: lock down setuptools for plainbox <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3273>
<ijohnson> sorry anyways I am probably getting us both off track now
<pedronis> ijohnson: so the easiest is probably to use the fakestore only for assertions
<pedronis> still pass your snaps with --snap
<pedronis> and then maybe it should work
<ijohnson> mmm I don't think I can do that tho
<pedronis> yes
<ijohnson> whenever I try to provide --snap ... to prepare-image it says local snaps are not allowed with dangerous
<ijohnson> err not allowed with signed
<pedronis> that sounds strange but possible
<ijohnson> I mean unless ubuntu-image has some magic that prepare-image doesn't
<pedronis> ijohnson: afaict it should give that error if we could not fetch assertions for the snap
<pedronis> the check seems late enough
<pedronis> at least
<ijohnson> mmm I guess I didn't have the SAS mocking setup when I tried it, perhaps now with the right mocking of the fakestore it will work
<pedronis> ijohnson: anyway I don't know if I pointed to it, but tests/main/classic-prepare-image-no-core does what I described
<pedronis> in terms of using the fakestore only for some assertions
<ijohnson> ok
<ijohnson> pedronis: alright well that was actually much easier
 * ijohnson feels rather foolish
<pedronis> sorry
<ijohnson> nah it's my fault for being stubborn and trying to make it work the way I thought it should work
<pedronis> anyway afaict using --snap with signed (as long as we can find assertions) works, but is not tested, I should add a test
<ijohnson> yes it does work with mocking SAS
<pedronis> there's a test about this in seedwriter but is using dangerous anyway because is doing also some other things that aren't allowed
<pedronis> I should have a test with also just the allowed subset
<pedronis> and signed
<ijohnson> can I just say how thankful I am that we don't also depend on signed assets from the core20 snap
<ijohnson> if we did, then literally every snap would need to be resigned to do local builds like this
<ijohnson> I'm already at 3/4 snaps
<ijohnson> yay we at least made it out of the initramfs
 * ijohnson waits anxiously to see if we make it out of install mode
<ijohnson> mmm seems not :-/
<mup> PR snapd#9256 closed: boot,bootloader: clarifications after the changes to introduce bootloader.Options.Role <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9256>
<cachio> zyga, around?
 * pedronis calling it a day
<ijohnson> eyyyyy got it working
 * ijohnson soft EODs
<mup> PR snapcraft#3271 closed: build providers: use the releases endpoint for LXD <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3271>
<mup> PR snapcraft#3272 closed: storeapi: improve to channel map docstrings <bug> <documentation> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3272>
<cachio> ijohnson, hey, about the test in 8
<cachio> 9208
<cachio> we do have all the failover tests as part of the core suite
<cachio> is it different to have it in the nested one?
<ijohnson> cachio: well it's fine to include for the regular core suite, but I also want that test to run with secure boot and fde, even though it's not specifically fde related, it's boot related
<mup> PR snapcraft#3274 opened: schema: rename package-repository's "deb-types" to "format" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3274>
<mup> PR snapcraft#3275 opened: cli: ignore sudo warning when using multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3275>
<mup> PR snapcraft#3276 opened: meta: add suite/component validation checks for package-repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3276>
