[01:04] <mup> PR snapd#4516 closed: spread: setup machine creation on Linode <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4516>
[06:09] <mborzecki> morning
[06:37] <mborzecki> linode:ubuntu-14.04-64:tests/main/snap-service is failing accross diferent PRs, looking into it
[07:04] <mborzecki> well, seems that the test is passing when run manually
[07:19] <zyga-ubuntu> o/
[07:19] <zyga-ubuntu> good morning
[07:26] <mborzecki> zyga-ubuntu: hey, morning
[07:27] <zyga-ubuntu> hey :)
[07:27] <zyga-ubuntu> I just made some warm coffee
[07:27] <zyga-ubuntu> we may have some unusual work to do today
[07:27] <zyga-ubuntu> is mvo around already?
[07:27] <zyga-ubuntu> hey chihchun
[07:27]  * zyga-ubuntu did a nice walk last evening, 5K in the dark and cold of winter
[07:28] <zyga-ubuntu> I didn't anticipate that I could get to so unpopulted areas of warsaw this quickly
[07:35] <zyga-ubuntu> good morning mvo
[07:39] <zyga-ubuntu> mvo: I replied to the thread with jamie now
[07:40] <mvo> hey zyga-ubuntu
[07:40] <mvo> zyga-ubuntu: thank you, checking
[07:40] <mborzecki> mvo: morning
[07:40] <mborzecki> mvo: morning
[07:41] <mborzecki> pff
[07:41] <mborzecki> wrong window :P
[07:42] <mvo> mborzecki: good morning!
[07:50] <mup> PR snapd#4528 opened: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4528>
[08:00] <kalikiana> snappy morning
[08:01] <mborzecki> kalikiana: morning
[08:03] <pstolowski> good morning!
[08:03] <mborzecki> pstolowski: morning
[08:49] <zyga-ubuntu>     - linode:ubuntu-14.04-64:tests/main/snap-service fails recently
[08:50] <mup> PR snapd#4512 closed: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4512>
[10:08] <mborzecki> zyga-ubuntu: tried running it separately a coupe of times, but all runs were successful
[10:10] <zyga-ubuntu> mborzecki: it probably needs to be ran in sequence with other tests, using the same random seed
[10:20] <ackk> sergiusens, is https://github.com/snapcore/snapcraft/pull/1617 good for merging?
[10:20] <mup> PR snapcraft#1617: Add options to configure applications socket activation <Created by albertodonato> <https://github.com/snapcore/snapcraft/pull/1617>
[10:39] <mborzecki> zyga-ubuntu: reproduced test-snap-service problem
[10:39] <zyga-ubuntu> mborzecki: what do you see?
[10:41] <mborzecki> an ancient systemd :)
[10:42] <mborzecki> zyga-ubuntu: calling reload does nothing, or iow, nothing is logged in the journal
[10:44] <zyga-ubuntu> uh
[10:44] <zyga-ubuntu> 14.04
[10:45] <mborzecki> zyga-ubuntu:   Process: 18961 ExecReload=/usr/bin/snap run --command=reload test-snapd-service (code=exited, status=0/SUCCESS)
[10:45] <mborzecki> and the service is active/running
[10:45] <mborzecki> just that there is no log
[10:49] <mborzecki> same thing after restarting the service
[10:50] <mborzecki> btw. the *.service file looks fine
[10:50] <zyga-ubuntu> any reason it would regress
[10:50] <mborzecki> i'll try something more direct, like kill -HUP $MAINPID and setup a trap in the main process
[10:50] <zyga-ubuntu> it does work sometimes
[10:55] <mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450449/ seems to work
[10:57] <mborzecki> zyga-ubuntu: https://paste.ubuntu.com/26450461/ notice how there's no long from the reload command
[10:58] <zyga-ubuntu> mborzecki: so was it just a race?
[10:59] <mborzecki> idk why journal is not capturing the reload command output
[11:03] <mborzecki> i'll open a PR and we'll see if this is enough of a fix or not
[11:03] <zyga-ubuntu> thank you
[11:10] <mup> PR snapd#4526 closed: tests: new spread test for gpg-public-keys interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4526>
[11:10] <mup> PR snapd#4529 opened: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4529>
[11:13] <zyga-ubuntu> hmm
[11:20] <adriens> hi there. I have a problem installing lxd with snap, not sure if the problem is from snap itself or the lxd package
[11:20] <adriens> snap list lxd gives: lxd   2.21     5447  canonical  -
[11:21] <adriens> $which lxd   /snap/bin/lxd
[11:21] <adriens> but $ lxd init
[11:21] <adriens> lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory
[11:24] <adriens> the command "snap run hello"  runs fine, but this app may not need shared libs
[11:29] <adriens> so I just installed chromium and it runs ok, so I guess the problem is within the lxd 'package'
[11:31] <pstolowski> mvo, hey, can #4063 land?
[11:31] <mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
[11:32] <ikey> is jdstrand back?
[11:32] <zyga-ubuntu> ikey: yes, he is
[11:33] <mvo> pstolowski: yeah, I think so, we need to set it to manual: true and cachio needs to integrate it with the spread-daily
[11:33] <ikey> awesome ty
[11:33] <ikey> Can we get some attention on this topic then please? :) https://forum.snapcraft.io/t/blowing-off-steam-lets-plan-steam-support-interface/3457
[11:34] <pstolowski> mvo, i see, so i cannot click 'merge' just yet right?
[11:34] <zyga-ubuntu> ikey: I think jamie has some backlog of topics to cover but I'm sure he will look at this as well
[11:34] <ikey> awesome, ty
[11:34] <ikey> basically i just need some basic gotchas so i can get some traction on it
[11:35] <ikey> this whole steam snap thing has been dragging on a really long time now ^^
[11:36] <mvo> pstolowski: better not yet, we need to coordinate with cachio
[11:36] <pstolowski> k
[11:42] <mup> Bug #1667829 changed: console-conf v0.0.5 crashes if no config needed <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1667829>
[12:00] <mup> Bug #1650096 changed: 'snap list' does not show devmode property after disable and re-enable a snap <Snappy:Fix Released> <https://launchpad.net/bugs/1650096>
[12:00] <mup> Bug #1666873 changed: Snap icon is not visible when called from terminal but it does when called from dash <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1666873>
[12:07] <Saviq> niemeyer: hey, when around, things went wrong somehow this morning: https://travis-ci.org/MirServer/mir/jobs/332706784
[12:07] <niemeyer> Saviq: Heya
[12:07] <Saviq> looking at https://travis-ci.org/snapcore/snapd/builds/332735121 - linode is having trouble
[12:08] <niemeyer> Saviq: Checking
[12:10] <niemeyer> Saviq: I think this is an issue on my end actually
[12:11] <Saviq> or that :)
[12:11] <niemeyer> Saviq: Well.. sort of.. the error on the snapd branch does not match the first one, and is a problem on Linode itself
[12:12] <Saviq> yeah they are different
[12:13] <niemeyer> Saviq: I'll look into this
[12:14] <Saviq> tx
[12:16]  * Chipaca returns from the dead
[12:17] <Chipaca> niemeyer: o/
[12:18] <niemeyer> Chipaca: Heya
[12:18] <Chipaca> niemeyer: when can we chat about snapshots?
[12:19] <Chipaca> or when can i read what you've written, if it's written :-)
[12:19] <niemeyer> Chipaca: I want to unblock you, so we can do that now if you have a moment.. I haven't read your forum post yet with all the spreadness yesterday, sorry, but we can catch up live
[12:19] <Chipaca> sure, let me get my earphones
[12:22] <Chipaca> niemeyer: standup h/o?
[12:22] <niemeyer> Chipaca: Yeah, there already
[12:45] <mup> PR snapd#4529 closed: tests/lib/snaps/test-snapd-service: refactor service reload <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4529>
[12:48] <sergiusens> Chipaca how was the highway "from" hell? :-P
[13:01] <Chipaca> sergiusens: rocky
[13:01] <Chipaca> sergiusens: also rolly
[13:03] <Chipaca> niemeyer: forum post updated, give it a once over in case i got it wrong
[13:17] <kalikiana> o/ sergiusens
[13:18]  * kalikiana going to have lunch in ~10
[13:19] <jdstrand> ikey: hey, I am. I've got a todo to respond to your forum post
[13:22] <kenvandine> kalikiana, sergiusens:  when will cleanbuild support building on a bionic base? There's a lxc image available at ubuntu-daily:18.04 already and we have the base-18 snap
[13:23] <ogra_> jdstrand, hey, i was just asked by a customer if we have a hdparm snap (indeed we dont) ... packaging it is less than a 20 lines snapcraft.yaml, but i cant really find an interface that would allow me to not run it in devmode ... do you have any idea ?
[13:24] <jdstrand> ogra_: I'd have to see the denials
[13:24] <ogra_> (devmode works fine as a mometary workaround ... but i fear the audit logging might actually falsify the measuring data)
[13:25] <jdstrand> I presume /dev/[sv]d* and friends
[13:25] <ogra_> jdstrand, this is what i get in devmode on my laptop https://paste.ubuntu.com/26451245/
[13:25] <ogra_> (nvme disk ... )
[13:26] <jdstrand> right nvme
[13:26] <jdstrand> anyway, that would need a new interface. it would obviously be massively powerful
[13:26] <ogra_> not sure why it touches all these loop devices
[13:27] <jdstrand> it is probably deciding that it doesn't need to look at them

[13:27] <jdstrand> I've seen that before with something
[13:27] <ogra_> (this was just hdparm -tT ... i bet there will be a lot other switches needed for the gazillion of options hdparm has)
[13:28] <ogra_> yeah, would be probably a bit over-powered ... raw-blockdevice-access or some such ..
[13:29] <jdstrand> ogra_: I suspect it would be a subset of the udisks2 slot policy
[13:29] <ogra_> ah
[13:29] <ogra_> only a subset ?
[13:29] <jdstrand> well, yeah. it doesn't have a dbus service
[13:29] <jdstrand> probably something like:
[13:29] <jdstrand> /run/udev/data/b[0-9]*:[0-9]* r,
[13:29] <ogra_> oh, udisks2 only comes from the snap ... not inside core
[13:29] <jdstrand> /sys/devices/**/block/** r,
[13:30] <ogra_> i see
[13:30] <jdstrand> /dev/sd* r,
[13:30] <jdstrand> /dev/mmcblk* r,
[13:30] <jdstrand> /dev/vd* r,
[13:30] <jdstrand> (and nvme*)
[13:30] <ogra_> yeah
[13:30] <jdstrand> probably a couple a capabilities
[13:31] <ogra_> thx
[13:31] <jdstrand> then the udev rule to tag all block devices
[13:31] <ogra_> (i might just keep it devmode for now ... after all that works for the moment ... sounds like a bigger project to add such an interface)
[13:32] <jdstrand> anyway, happy to review if you send something up. if you need me to do it, it will be a while (though let me know so I can capture this conversation)
[13:33] <ogra_> yeah
[13:34] <brunosfer> kyrofa: I'm dealing with the Go environment and setting my workspace correctly. However in my Go files I have functions that execute commands to the console such as `sudo snap install name.snap` the problem is that I need sudo privileges and when I do `sudo snapcraft` the Go env paths disappear.
[13:38] <willcooke_> mvo, do you know who can approve membership of the canonical-snapcraft email list?  kenvandine has been pending for a couple of weeks now
[13:42] <zyga-ubuntu> jdstrand: hello
[13:42] <jdstrand> zyga-ubuntu: fyi, https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471/56 (not sure you can see comments to merged PRs-- istr people have that issue)
[13:42] <jdstrand> zyga-ubuntu: hey
[13:43] <zyga-ubuntu> jdstrand: I did, I responded to them (though let me recheck)
[13:43] <zyga-ubuntu> jdstrand: if you want I can just disable the whole user/mode part for now
[13:45] <mborzecki> mvo: looks like the license field should be avaialble in the client, but we're just not showing it
[13:46] <jdstrand> zyga-ubuntu: responed via the forum
[13:46] <zyga-ubuntu> jdstrand: I'll do that quickly
[13:47] <zyga-ubuntu> jdstrand: btw, for 4329, do you think this is close to landing?
[13:47] <zyga-ubuntu> mvo will release 2.31 today
[13:48] <jdstrand> zyga-ubuntu: I'm still going through email which includes the responses to my reviews, but my feeling yesterday was, yes, 4329 is close
[13:49] <zyga-ubuntu> OK, I'll get to layouts now
[13:49] <jdstrand> I'm also surprised that 2.31 will be released today. I had a pile of policy updates... :\
[13:49] <mvo> mborzecki: yeah, it seems we also do not store it locally, i.e. when doing "snap info local-snap" the info seems to get lost
[13:50] <jdstrand> ETOOMANYHIGHPRIORITYITEMS
[13:50] <Son_Goku> EPANIC
[13:50] <jdstrand> losing a week to the sprint didn't help either
[13:50] <mborzecki> EAGAIN :)
[13:50] <zyga-ubuntu> mvo: ^^
[13:50] <zyga-ubuntu> mvo: maybe postpone 2.31 for some time?
[13:50] <jdstrand> mvo: hey, willcooke_ mentioned that xdg-settings needed to be in 2.31
[13:51] <brunosfer> Hey guys, can tell me how can I specify in the snapcraft.yaml a package in goland that I created and I need it to go to the GOROOT path into the pkg folder as a *.a lib?
[13:51] <jdstrand> mvo: I reviewed it yesterday and its close. not through email yet (so don't know if you addressed things), but wanted to touch base since 2.31 is imminent on xdg-seettings going into 2.31
[13:58] <mvo> jdstrand: *must* is a strong word
[13:58] <mvo> jdstrand: I have a meeting now but lets chat after that
[13:58] <mvo> jdstrand: there is always 2.32 but yeah, there is some stuff I would love to have in 2.31
[13:58] <mvo> jdstrand: the trouble is that statement is always true however long one waits ;)
[13:59] <jdstrand> mvo: I don't think I said 'must' :)
[13:59] <jdstrand> mvo: sure, willcooke contacted me and said it was critical
[13:59] <mvo> jdstrand: for policy updates I can certainly include it in 2.31~rc2 for example
[13:59] <mvo> jdstrand: today would be ~rc1
[14:01] <mup> PR snapd#4530 opened: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
[14:02] <jdstrand> mvo: I think I can get a PR up today/tomorrow at the latest. if it doesn't make it, well, it doesn't make it
[14:03] <jdstrand> mvo: I'll look at 4530 today
[14:03] <jdstrand> err
[14:03] <jdstrand> zyga-ubuntu: ^
[14:04] <zyga-ubuntu> jdstrand: thank you
[14:06] <mup> PR snapcraft#1617 closed: Add options to configure applications socket activation <Created by albertodonato> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1617>
[14:10] <jdstrand> zyga-ubuntu: I accidentally approved 4329. please see https://github.com/snapcore/snapd/pull/4329#discussion_r163555093 for the last remaining item
[14:10] <mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
[14:10] <zyga-ubuntu> jdstrand: ack
[14:11] <ogra_> niemeyer, mvo, pedronis has there been any progress at https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431 (we'd need it for some customer images)
[14:11] <sergiusens> kyrofa fwiw, `pkg.name not in package_names` is what makes adding libc6 as a stage-packages entry work
[14:30] <kalikiana> re
[14:36] <brunosfer> Does anyone can help me out with a doubt? In the snapcraft.yaml in a part I have `stage-packages: [libbluetooth-dev, bluez]` and I get the error `apt.cache.FetchFailedException: W:Can't drop privileges for downloading as file '/home/sid/.cache/snapcraft/stage-packages/apt/656cd207e1d22`
[14:37] <brunosfer> On Ubuntu Core Raspberry Pi 3 amrhf it works. On Ubuntu core amd64 it doesn't work...
[14:50] <Chipaca> brunosfer: are you running as root or anything like that?
[14:59] <mup> PR snapd#4531 opened: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
[15:00] <Chipaca> niemeyer: did you get a chance to review the updated text about snapshots?
[15:02] <zyga-ubuntu> mborzecki: reviewed
[15:02] <brunosfer> Chipaca: Yes, I do have to run sudo.
[15:02] <Chipaca> brunosfer: why?
[15:03] <brunosfer> Chipaca: Because installing a downloaded snap requires sudo.
[15:03] <Chipaca> brunosfer: no it doesn't
[15:03] <brunosfer> Chipaca: Let me recheck again...
[15:04] <Chipaca> brunosfer: if you're a developer, you can log in (snap login), and then snapd can see your private snaps
[15:05] <Chipaca> brunosfer: if you haven't logged in, it should prompt you for your password to confirm the operation, but not require sudo
[15:05] <Chipaca> brunosfer: sorry, i meant, you can login, in which case it won't ask you for anything, and as a plus it'll see your private snaps
[15:06] <brunosfer> Chipaca: I think we are talking about different things. Let me explain better.
[15:08] <brunosfer> Chipaca: The problem occurres in a ubuntu desktop with the snapcraft tool installed.
[15:09] <mborzecki> zyga-ubuntu: thanks, posted some example output also
[15:09] <zyga-ubuntu> mborzecki: got that, looks good
[15:10] <brunosfer> Chipaca: I have a golang file in my code that executes the cmd line `sudo snap install name.snap` and when I run the snapcraft to build the snap it throws me the error I mentioned before.
[15:10] <mcphail> zyga-ubuntu: saw your forum post about licence files. I'm still very confused about this. Most snaps will have multiple parts and muliple stage-packages, and may have many different licences. Is a single licence field appropriate?
[15:11] <Chipaca> brunosfer: for what it's worth, the "drop privileges" thing is a warning, not an error
[15:11] <zyga-ubuntu> mcphail: yes, the license field is a SPDX expression that can have many many licenses in one thing
[15:11] <Chipaca> brunosfer: but, why do you have a file in your code that does that?
[15:11] <zyga-ubuntu> mcphail: so you can see that an app uses, say, "MIT and LGPL-2"
[15:11] <Chipaca> brunosfer: (the W: before the message means 'warning')
[15:12] <Chipaca> brunosfer: and, the message is from apt, not from snap
[15:12] <mcphail> zyga-ubuntu: so do we dump multiple licences in the meta/LICENSE file?
[15:13] <zyga-ubuntu> mcphail: no, unless those are standard
[15:13] <zyga-ubuntu> mcphail: if you have that MIT and LGPL-2 example you don't need the license text for that
[15:13] <zyga-ubuntu> mcphail: the license text would only apply if you really have a custom license
[15:13] <Chipaca> mcphail: spdx license expressions allow multiple licenses
[15:13] <zyga-ubuntu> mcphail: all licenses known to SPDX are covered by the existing system
[15:13] <Chipaca> you can do license algebra! license matrixes! license eigenvectors!
[15:14]  * Chipaca runs away
[15:15] <Chipaca> mcphail: https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf
[15:16] <mcphail> ok. cheers chaps. However, all MIT licenses (for example) are bespoke to the individual packages and are supposed to be distributed with the copyright line unmodified. How do we cope with that?
[15:17] <mcphail> "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software"
[15:17] <Chipaca> mcphail: you ship the license, just not in meta/
[15:18] <mcphail> Hmm. OK. So there's inevitable duplication there between adding it to the metadata format and shipping the actual licence?
[15:18] <Chipaca> mcphail: or you ship it as meta/LICENSE (was that the file in meta/ we settled on? not sure), but also include license: MIT in the .yaml so the license itself is ignored by the business logic
[15:19] <Pharaoh_Atem> same goes for BSD licenses
[15:20] <Pharaoh_Atem> especially since BSD licenses get kinda weird
[15:20] <mcphail> heh
[15:23] <niemeyer> Chipaca: I had a chance to have lunch! :)
[15:23] <Chipaca> niemeyer: :-)
[15:23] <Chipaca> niemeyer: basically my question is whether the 'just one file' applies to all snaps in a snapshot, or if i should make them per-snap
[15:24] <niemeyer> I'm reading it now
[15:40] <mup> Issue snapcraft#1688 closed: Documentation for advanced grammar for sources <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1688>
[15:46] <Chipaca> niemeyer: poke
[15:47] <niemeyer> Chipaca: Sorry, still working on it (mid other things, appologies)
[15:48] <niemeyer> apologies even
[15:48] <Chipaca> yeah i know things a busy for you right :-)
[15:57] <niemeyer> Chipaca: Sent some initial comments there
[15:58] <zyga-ubuntu> hmm
[15:58] <zyga-ubuntu> tests are not happy
[15:59] <Chipaca> niemeyer: from your comment about the snapshot filename I understand your answer to my question is to have a single snap per snapshot
[15:59] <zyga-ubuntu> seems tests just terminate machines in random places
[15:59] <zyga-ubuntu> niemeyer: ^ perhaps related to new spread allocation
[16:00] <zyga-ubuntu> sample log: https://api.travis-ci.org/v3/job/332828272/log.txt
[16:00]  * kalikiana wishes that one day Google fixes hangout links in notifications to use the right account
[16:00] <niemeyer> Chipaca: That seems slightly more expectable and perhaps nicer to work with
[16:00] <niemeyer> Chipaca: Note we can still draw a line across multiple snapshots by sharing some information
[16:01] <niemeyer> zyga-ubuntu: Looking
[16:01] <niemeyer> zyga-ubuntu: Do you have the URL for the build?
[16:01] <niemeyer> THese files are pretty ugly to look at while raw
[16:01] <zyga-ubuntu> niemeyer: sure https://github.com/snapcore/snapd/pull/4530
[16:01] <mup> PR #4530: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <https://github.com/snapcore/snapd/pull/4530>
[16:02] <zyga-ubuntu> or https://travis-ci.org/snapcore/snapd/builds/332828271?utm_source=github_status&utm_medium=notification
[16:02] <niemeyer> zyga-ubuntu: Okay, and what sholud I look for other than 50 thousand lines?
[16:02] <zyga-ubuntu> niemeyer: look at 1st few error, it seems that the logs are just cut in random places
[16:02] <zyga-ubuntu> niemeyer: as if those machines got axed
[16:03] <zyga-ubuntu> hmm hold on, is that the right build
[16:03] <zyga-ubuntu> sorry, rechecking, too many tabs open
[16:04] <zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification <- here
[16:05] <zyga-ubuntu> we seem to die when installing packges in the first few errors
[16:05] <zyga-ubuntu> not sure what to make of that really
[16:06] <niemeyer> zyga-ubuntu: Yeah, that may be conflicts and two different systems trying to allocate the same machine.. I need to fix that today
[16:06] <niemeyer> zyga-ubuntu: Just restart for now please
[16:06] <zyga-ubuntu> thank you
[16:13] <zyga-ubuntu> niemeyer: is there anything blocking 4471 left?
[16:13] <niemeyer> zyga-ubuntu: I'll have to look at it to be able to ttell
[16:14] <mup> PR snapd#4532 opened: store: use the "publisher" when populating the "publisher" field  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4532>
[16:14] <zyga-ubuntu> ack
[16:20] <mvo> Chipaca: quick question about developer/publisher - should we expose both via the rest api?
[16:21] <mvo> Chipaca: context is that I'm looking at this right now for g-s (minimal fix is in 4532) but it looks like there is a bit more to make this nice
[16:21] <Chipaca> mvo: I fear I'm lacking context
[16:21] <Chipaca> heh
[16:21] <mvo> Chipaca: sorry, so right now it seems in our code we are not super clear when publisher and when developer is used
[16:21] <Chipaca> sergiusens: could you copy mvo on the email about ^ you sent me today?
[16:22] <Chipaca> sergiusens: looks like he's aching to fix the issue :D
[16:22] <mvo> Chipaca: and I wonder if should untangle this properly and always have those two everywhere (rest api, snap.Info etc)
[16:26] <mborzecki> `snap info` output has to be valid yaml
[16:26] <mborzecki> intersting
[16:26] <Chipaca> mborzecki: there's a bunch of TODOs on that still though
[16:26] <Chipaca> mborzecki: but, yes, ideally yes
[16:31] <mborzecki> hmm the core snap does not have the license set?
[16:39] <mvo> mborzecki: it might be that its local and therefore the license get lost
[16:39] <mvo> mborzecki: its labeled in the store as "other open source"
[16:43] <kyrofa> sergiusens, I meant to ask: what priority would you like me to give the load_plugin work? I've still got a chunk of docs to write
[16:43] <kyrofa> sergiusens, shall we create an issue for it and put it on the next milestone?
[16:43] <sergiusens> kyrofa something to do on Friday maybe or when you are on a creative block
[16:43] <sergiusens> kyrofa an issue sounds like a good plan
[16:44] <sergiusens> Chipaca ack
[16:44] <mborzecki> mvo: that's likely it
[16:44] <kyrofa> sergiusens, good call, those happen. I'll make an issue for it
[16:44] <mvo> mborzecki: yeah, I think we just need to store it locally, its store metadata
[16:46] <mborzecki> mvo: looks like a followup PR on #4531
[16:46] <mup> PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
[16:46] <cachio> mvo, 2.31 is comming today?
[16:46] <mup> Issue snapcraft#1882 opened: Toast load_plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1882>
[16:52] <mvo> cachio: I'm waiting for some PRs to get green
[16:52] <mvo> mborzecki: +1
[16:57] <cachio> mvo, ok, tx
[17:02] <ogra_> if i have an "architectures: [ all ]" snap that is installed on a system and eventually add a binary to that snap (which forces me to change to "architectures: [ foo ]" ... will that snap be upgraded on my syystem ?
[17:02] <ogra_> or would my user have to remove/install manually ?
[17:06]  * ogra_ files https://forum.snapcraft.io/t/what-happens-if-an-architectures-all-snap-becomes-arch-specific/3675
[17:11]  * kalikiana wrapping up for the day
[17:12] <om26er> popey: are you around ?
[17:15] <popey> Ya
[17:16] <om26er> popey: https://github.com/snapcrafters/sublime-text/pull/5
[17:16] <mup> PR snapcrafters/sublime-text#5: Snapcraft yaml cleanup <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/5>
[17:16] <om26er> After that I think we should move that to stable. It has been working perfectly fine.
[17:16] <mup> PR snapd#4533 opened: errtracker: include detected virtualisation <Created by mvo5> <https://github.com/snapcore/snapd/pull/4533>
[17:19] <kyrofa> nacc, did Laney ever get back to you about autopkgtests? I didn't see anything
[17:20] <popey> om26er: i dont think that architectures stanza does what you think it does
[17:20] <popey> om26er: certainly won't stop build from trying to make an i386 snap
[17:31] <om26er> popey: oh, do you know a way to do that ?
[17:32] <om26er> I always thought that would limit the architectures my snap will build on
[17:40] <nacc> kyrofa: nor I
[17:40] <nacc> kyrofa: i'll ping again
[17:44] <popey> om26er: sadly not.
[17:44] <acknack> been pouring over docs and web posts but in hours haven't found an answer to a question:
[17:45] <acknack> what sets the number of revisions kept for a snap?
[17:45] <popey> om26er: https://github.com/canonical-websites/build.snapcraft.io/issues/556
[17:45] <acknack> what or where?
[17:45] <kyrofa> acknack, I believe it's hard-coded in snapd
[17:45] <acknack> ouch.
[17:45] <popey> yeah, i believe so
[17:45] <kyrofa> acknack, why, are you wanting to change it?
[17:45] <kyrofa> (and if so, why?)
[17:45] <acknack> it's apparently > 2
[17:45] <kyrofa> Yeah, it's three
[17:46] <acknack> and i can only go back one revision by the cli?
[17:46] <nacc> kyrofa: looks like it might get re-enabled tmrw
[17:46] <kyrofa> No, you can revert multiple times, or revert to a specific revision
[17:47] <kyrofa> nacc, ah, excellent, thank you :)
[17:47] <nacc> kyrofa: yw
[17:47] <acknack> okay.  being able to revert more than one didn't make an impression during my research
[17:48] <acknack> i can specify a revision to remove. would you believe i was thinking the number of revisions would be configurable not hardcoded because of the VMS filesystem?
[17:51] <kyrofa> acknack, if that's a feature you believe would be helpful, by all means feel free to request it
[17:51] <acknack> specify a specific* revision to manually* remove
[17:51] <acknack> i can see a dev wanting a few revisions around. i was hoping to be tidy and set it to 2.
[17:51] <acknack> the apps are small enough but core is sizable
[17:54] <acknack> k. thanks. i'll have a look at the code.  is there an existing external config file for snapd?
[17:55] <acknack> otherwise, i'm thinking a cli param and a tweak to the systemd stuff which fires up snapd
[17:56] <acknack> "per snap" rev limit would be lovely but overkill, i think, yes?
[17:58] <Chipaca> in an ideal world you could say "call this bit of business logic to decide"
[17:58] <Chipaca> but... no :-)
[18:00]  * Chipaca ~> dinner
[18:01] <acknack> VMS filesystem (and later implementions in other OSes) has a root dir rev limit which is inherited and ability to set per file rev limit. just fyi.
[18:02] <acknack> external config file exists for snapd? yes/no?
[18:35] <acknack> hmm. yes, '42' is the Great Answer.  overlord provides a hook for setting upper rev limit?
[18:36] <mup> PR snapd#4528 closed: cmd/snap: improve `snap aliases` output when no aliases are defined <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4528>
[18:48]  * zyga-ubuntu cooked dinner for the first time in weeks
[18:48] <zyga-ubuntu> ttyl :)
[18:54] <acknack> okay. i surrender. not able to grasp the thread of snapd execution and locate the decision point where 3 revisions are retained when a refresh installs a new revision.
[18:56] <niemeyer> How's travis going folks?
[18:56] <niemeyer> Any issue signs?
[18:58] <niemeyer> I see some good data:
[18:58] <niemeyer> https://usercontent.irccloud-cdn.com/file/N6NEPIKG/image.png
[19:04] <kyrofa> cprov, do you have any docs on what the various ACLs mean?
[19:17] <cachio> ogra_, there?
[19:17] <ogra_> semi :)
[19:18] <ogra_> (but yes)
[19:18] <cachio> ogra_, I have some problems in a test to read from /dev/gpiomem
[19:18] <ogra_> is the interface connected ?
[19:18] <ogra_> iirc thats a brandnew interface
[19:18] <cachio> yes
[19:19] <cachio> even it fails if I do dd if=/devgpiomem
[19:19] <cachio> from the console in the pi2
[19:19] <cachio> and pi3
[19:19] <ogra_> becaue you miss a slash ? :)
[19:20] <ogra_> the device is root owned and 0600 mode ... your script needs to run as root
[19:20] <cachio> the command I run is "dd if=/dev/gpiomem of=/dev/null bs=1024 count=1"
[19:20] <kyrofa> Yeah, would be nice to _not_ need root
[19:20] <ogra_> totally
[19:20] <ogra_> just saying what i see over here :)
[19:21] <ogra_> cachio, does your command run as root ?
[19:21] <cachio> ogra_, this is the output https://paste.ubuntu.com/26453618/
[19:21] <ogra_> ah, it does
[19:21] <ogra_> hmm
[19:21] <kyrofa> ogra_, yeah you're definitely right: https://forum.snapcraft.io/t/raspberry-pi-gpio-as-a-user/3188/2
[19:22] <ogra_> i see the same here ... looks like the device itself blocks
[19:22] <ogra_> ogra@stream:~$ sudo cat /dev/gpiomem
[19:22] <ogra_> cat: /dev/gpiomem: Invalid argument
[19:23] <kyrofa> How odd
[19:23] <cachio> I see the same error running from the snap with the interface connected
[19:24] <ogra_> yeah, its the device for sure
[19:25] <cachio> ogra_, this is executing from the snap
[19:25] <cachio> https://paste.ubuntu.com/26453644/
[19:26] <cachio> If I run the snap using sudo I get the same error "dd: error reading '/dev/gpiomem': Invalid argument"
[19:28] <ogra_> yeah, nothing to do with the snap or the test
[19:29] <ogra_> cachio, thats not a stable image, is it ?
[19:29] <ogra_> (stable doesnt have *any* proper gpio support ... that was only added later)
[19:29] <cachio> ogra_, no, beta image using core from edge
[19:30] <ogra_> but not an edge gadget
[19:30] <ogra_> https://paste.ubuntu.com/26453668/
[19:30] <ogra_> see that
[19:31] <ogra_> i suspect you cant just dump gpiomem without having any gpios exported at all
[19:31] <cachio> ogra_, no, I build the images with ubuntu-image for beta validation
[19:32] <ogra_> and to export gpios you will need at least a gadget with gpio slots
[19:32] <ogra_> which are still only in edge
[19:32] <cachio> ogra_, ok, bad news
[19:32] <cachio> ogra_, is it any way to force it?
[19:32] <cachio> at least to test the interface
[19:32] <ogra_> use an edge gadget
[19:34] <ogra_> note though that i'm not sure thats the actual issue
[19:34] <mup> PR snapd#4524 closed: cmd: remove unused execArg0/execEnv  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4524>
[19:34] <mup> PR snapd#4530 closed: snap,interfaces/mount: disallow nobody/nogroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4530>
[19:35] <zyga-ubuntu> woooot :)
[19:35] <mup> PR snapd#4329 closed:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4329>
[19:36] <cachio> ogra_, ok
[19:37] <cachio> ogra_, I'll continue with another test while I figure out how to make it work
[19:37] <acknack> guess nobody wants to say which source file has the "max 3 revisions retained" decision point. np
[19:37] <acknack> ciao
[19:37] <cachio> ogra_, thaks for the support
[19:37] <zyga-ubuntu> jdstrand: only one PR from my pile left, the rest I have (behind 4471) are just tests
[19:37] <ogra_> cachio, good luck ... i'm also only guessing ...
[19:38] <jdstrand> zyga-ubuntu: cool, and that is inline with my trello card :)
[19:39] <zyga-ubuntu> jdstrand: FYI, I have full unit tests and spread tests for 4471
[19:39] <zyga-ubuntu> jdstrand: I can push those if needed, they are just super long
[19:39] <zyga-ubuntu> and I wanted to show this non-test change doesn't break tests
[19:39] <zyga-ubuntu> and that future just-test changes don't touch functionality
[19:40] <zyga-ubuntu> and that spread tests for both old and new things pass perfectly fine
[19:40] <zyga-ubuntu> all of that is ready and waiting but it makes this into a ~2K review
[19:40] <jdstrand> I'll leave that to your discretion
[19:40] <jdstrand> but glad to hear there are a bunch of tests ready to go
[19:40] <zyga-ubuntu> I think this way is just easier to land
[19:40] <zyga-ubuntu> sure, it's fully tested
[19:41] <zyga-ubuntu> I closed the initial PR because nobody would look at the full lot :)
[19:41] <jdstrand> heh
[19:44] <ogra_> cachio, it might actually be that you need to use mmap or some such to actually access gpiomem
[19:44] <ogra_> and that direct dd'ing wont work at all
[19:45]  * zyga-ubuntu has terrible headahe and wants to EOD now
[19:45] <ogra_> (like you can not directly access /dev/mem)
[19:46] <zyga-ubuntu> (you need to access /dev/mem via /dev/pointer)
[19:46]  * zyga-ubuntu states that was a terrible joke and EODs
[19:47]  * ogra_ ...  zyga-ubuntu > /dev/bed
[19:50] <zyga-ubuntu> tar zyga -f /dev/bed
[19:50] <cachio> ogra_, ok
[19:50] <cachio> that makes sense
[19:52] <zyga-ubuntu> niemeyer: linode broke again
[19:52] <zyga-ubuntu> https://api.travis-ci.org/v3/job/332769269/log.txt
[19:52] <zyga-ubuntu> (very short log)
[19:52] <ogra_> i guess a small c program with a simple "fd = open ("/dev/gpiomem", O_RDWR | O_SYNC | O_CLOEXEC)" might actually work too for the test
[19:52] <zyga-ubuntu> via https://travis-ci.org/snapcore/snapd/builds/332769268?utm_source=github_status&utm_medium=notification
[19:54] <mup> Bug #1745214 opened: snapd retains fixed number of snap revisions <Snappy:New> <https://launchpad.net/bugs/1745214>
[20:00] <sergiusens> kyrofa how do I debug a hook?
[20:00] <zyga-ubuntu> for the sake of keeping track, it was all full of 2018-01-24 19:38:47 Cannot allocate linode:fedora-27-64: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
[20:00] <zyga-ubuntu> I restarted the job now
[20:01] <kyrofa> sergiusens, make it fail and print
[20:01] <kyrofa> sergiusens, otherwise snapd swallows its stdout/stderr
[20:01] <sergiusens> kyrofa just printing enough is good? What if it is a segfault?
[20:01] <kyrofa> sergiusens, note that you can also do `snap run --hook`
[20:02] <sergiusens> kyrofa `snap run --hook` only works it is installed :-)
[20:02] <kyrofa> Ouch, that's a bit more difficult :P
[20:02] <kyrofa> sergiusens, oh, is it an install hook?
[20:02] <sergiusens> kyrofa yeah
[20:02] <sergiusens> kyrofa wait, it is a `configure` hook, but it is triggered on install
[20:03] <kyrofa> Yeah, same effect I suppose
[20:03] <kyrofa> sergiusens, try making it a command instead
[20:03] <kyrofa> Would that work?
[20:03] <sergiusens> kyrofa yeah, I was thinking about that, it probably should, let me double check
[20:04] <kyrofa> It would be cool if snapd grew some sort of `snap install --debug` mode that just printed everything from the hooks
[20:04] <kyrofa> `snap set --debug` as well
[20:10] <ogra_> cachio, there is the devmem2 untility that allows reading of registers from /dev/mem ... if you hack that up to instead open /dev/gpiomem that might work ... https://free-electrons.com/pub/mirror/
[20:10] <ogra_> here is also some general background https://elinux.org/EBC_Exercise_11b_gpio_via_mmap
[20:11] <ogra_> (not pi specific though)
[20:11] <cachio> ogra_, awesome, thanks
[20:11] <sergiusens> kyrofa found the culprit, you will smirk
[20:11] <kyrofa> sergiusens, haha, what?
[20:12] <sergiusens> kyrofa that said, snapcraft#1881 should be ready
[20:12] <mup> PR snapcraft#1881: elf: better handling for newer libc6 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1881>
[20:17] <mup> PR snapd#4534 opened: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
[20:20] <ogra_> cachio, and sisne i couldnt resist ... https://paste.ubuntu.com/26453965/
[20:20] <ogra_> *since
[20:20] <cachio> ogra_, heheh
[20:20] <ogra_> (classic)ogra@stream:~$ ./gpiotest.sh
[20:20] <ogra_> Memory mapped at address 0x76f79000.
[20:20] <ogra_> Value at address 0x3F200000 (0x76f79000): 0x21200924
[20:20] <ogra_> but i cheated using classic ;)
[20:21] <ogra_> that should be enough to prove that the interface lets you access the device
[20:21] <cachio> ogra_, hehe, let me try it on pi3
[20:22] <ogra_> i simply gepped the addess gpiomem uses from the boot log as you can see ....
[20:22] <ogra_> and tell devmem2 to simply print the content
[20:22] <mup> PR snapcraft#1883 opened: Revert "meta: create XDG_RUNTIME_DIR in wrappers. (#1818)" <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1883>
[20:23] <sergiusens> kyrofa ^ we shouldn't be doing generic workarounds ;-)
[20:24] <kyrofa> sergiusens, hahaha
[20:24]  * kyrofa smirks
[20:25] <sergiusens> kyrofa it is a bit more complex than that, we really need to get rid of `LD_LIBRARY_PATH` and friends
[20:25] <kyrofa> sergiusens, yeah, we're well on our way there I think with the readelf stuff
[20:25] <sergiusens> we end up using mkdir from `core` with libc6 from a future release
[20:26] <kyrofa>  /patchelf
[20:26] <kyrofa> Oh brutal
[20:26] <sergiusens> kyrofa yeah, we just need to be brave enough to enable it for everything ;-)
[20:26] <jamesb192> pythonpath
[20:26] <kyrofa> Yeah I'll admit that's a terrifying proposition
[20:27] <kyrofa> We should do a feature branch and do a call for testing on it alone
[20:27] <kyrofa> But if it worked... dude
[20:27] <sergiusens> it will work
[20:27] <ogra_> you could instead work on something easy and fix https://forum.snapcraft.io/t/avoiding-installation-of-build-dependencies/3665/3
[20:27] <ogra_> :P
[20:27] <sergiusens> I just need tyhicks to find the time to look closely at patchelf and verify it will not be a problem long term
[20:29] <kyrofa> ogra_, no comment
[20:30]  * ogra_ grins
[20:30] <sergiusens> ogra_ that is actually easy to fix; it is hard to test though
[20:31] <ogra_> sergiusens, well, the inability of dpkg and apt to re-locate install paths was the reason for clicks to exist initially :)
[20:31] <ogra_> IIRC
[20:31] <ogra_> (and thus snaps in the end)
[20:31] <sergiusens> kyrofa elopio are we good with snapcraft#1879
[20:31] <mup> PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
[20:31]  * ogra_ just waits to see fakechroot integrated into snapcraft :)
[20:31] <kyrofa> sergiusens, I was hoping elopio would respond to my questions
[20:32] <sergiusens> ogra_ if `which go` returns something, we use that, if not we check if a build-snaps entry for go exists and if not we default to installing the build-packages entry of go
[20:32] <sergiusens> elopio answer the questions please :-) Also, the doc ;-)
[20:33] <ogra_> sergiusens, well, if i dont have go in "build-packages" but like ... 300 libs ?
[20:33] <ogra_> how do you avoid installing them on the host ... and still are aboe to build your target
[20:33] <ogra_> *able
[20:34] <sergiusens> ogra_ once you want reproduceability you should worry on how you get `go`; it could also be staged through a part (which we already support but  install anyways)
[20:34] <ogra_> well, the request is to avoid installing build deps on the host machine
[20:34]  * sergiusens goes back to manager work and fills in some forms for the rest of the day and tomorrow
[20:50] <zyga-ubuntu> niemeyer: 4471 is green, just saying :)
[20:51] <mvo> cachio: 2.31~rc1 should be available in ~1h or so in edge, not sure if I will still be up then to promote it to beta, if not, freel free to do so yourself!
[20:52] <cachio> mvo, sure, thanks
[20:52] <niemeyer> zyga-ubuntu: I need to break something then!
[20:52] <niemeyer> ;P
[20:52] <om26er> flexiondotorg: Hi! Please merge https://github.com/snapcrafters/sublime-text/pull/6 as well.
[20:52] <mup> PR snapcrafters/sublime-text#6: Change app name to subl <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/6>
[20:52] <mvo> cachio: great, thank you! keen to see/hear how the tests go, especially on the boards :)
[20:53] <zyga-ubuntu> niemeyer: :D
[20:53] <mvo> cachio: but no worries, if its late for you already this can wait until tomorrow
[20:53] <cachio> mvo, I'll start today
[20:53] <mvo> cachio: \o/
[20:53] <cachio> mvo, let's see how it goes
[20:54] <mvo> thanks cachio, I will check mail tomorrow morning then with anticipation :)
[20:54]  * mvo waves and calls it a day
[20:54] <om26er> popey: regarding the 'architectures' stanza, it seems once I removed i386 from sublime' yaml, its only amd64 in dashboard.snapcraft.io -- so it is indeed working.
[21:45] <zyga-ubuntu> om26er, flexiondotorg: commented on sublime-text PR
[21:48] <om26er> zyga-ubuntu: I like that suggestion, will make changes to the packaging tomorrow. Can you share a sample app that uses tracks ?
[21:48] <om26er> well maybe I'll look at LXD' packaging.
[22:02] <zyga-ubuntu> om26er: lxd is one, noise][1 can suggest some as well, probably better than I can
[22:05] <kyrofa> om26er, nextcloud as well
[22:06] <zyga-ubuntu> om26er: note that you need to request tracks to be made server side
[22:06] <zyga-ubuntu> om26er: and I don't remember how this works but I think the 3 track should be default
[22:07] <kyrofa> The default is always `latest`, which is not a pointer, but a track unto itself
[22:07] <zyga-ubuntu> aha
[22:07] <kyrofa> Thus if you want the 3 track and latest track to look the same, you must release to both
[22:07] <zyga-ubuntu> kyrofa: how would you map sublime-text-2 (legacy) and sublime-text-3 into tracks?
[22:07] <zyga-ubuntu> I see
[22:07] <zyga-ubuntu> hmm
[22:07] <zyga-ubuntu> maybe a 2 track is better
[22:07] <zyga-ubuntu> and a latest track for 3
[22:07] <kyrofa> I'd create 2 and use latest for 3
[22:07] <zyga-ubuntu> the versions will convey the rest
[22:07] <zyga-ubuntu> om26er: ^ I agree
[22:08] <om26er> yeah that sounds a fine suggestion.
[22:08] <kyrofa> Then once there's a four you can create a 3 for people who don't want to upgrade
[22:08] <zyga-ubuntu> om26er: and I'd _love_ to use that
[22:08] <zyga-ubuntu> as a paying sublime user :)
[22:08] <kyrofa> However, if people stay on latest, they _will_ upgrade to four if they don't see that you released a 3 track. So you can maintain a standalone 3 track that mirrors the latest track if you want people to install from 3/stable knowing that they'll never update to 4
[22:09] <zyga-ubuntu> kyrofa: I think 4 is faaar away
[22:09] <kyrofa> (too much work in my opinion)
[22:09] <kyrofa> Yeah, it's more about supporting a specific user intent: "I never want 4, just 3" and "Yeah give me the latest thing, oh it's 3, nice"
[22:10] <zyga-ubuntu> kyrofa: btw, do you use sublime text?
[22:10] <kyrofa> Man, I barely started using atom from gedit. I'm so far behind on the editor curve
[22:11] <zyga-ubuntu> kyrofa: try it
[22:11] <om26er> so will we need to get the snap renamed or register sublime-text as new ?
[22:11] <zyga-ubuntu> it's awesome IMO
[22:11] <zyga-ubuntu> it's like atom lost 90% of its weigth
[22:11] <zyga-ubuntu> om26er: ... no idea
[22:11] <zyga-ubuntu> om26er: probably new snap is better now
[22:11] <zyga-ubuntu> and have store side kill the current one
[22:12] <kyrofa> Haha, I'm that far down the curve for a reason: I don't like change very much. I get a setup that pleases me and I use it until it no longer does or something convinces me there's a feature that I must have elsewhere
[22:12] <zyga-ubuntu> kyrofa: sublime + agola color theme (I love green variant)
[22:12] <zyga-ubuntu> kyrofa: don't look then
[22:12] <zyga-ubuntu> kyrofa: if you will look you won't stay on atom
[22:12] <zyga-ubuntu> ;-)
[22:12] <kyrofa> ;)
[22:12] <zyga-ubuntu> kyrofa: sl is an order of magnitude faster and less memory hungry than atom
[22:13] <kyrofa> Will it crash X every other time like atom and chrome do?
[22:13] <kyrofa> (does it use electron is I guess what I'm asking)
[22:13] <zyga-ubuntu> no?
[22:13] <zyga-ubuntu> it never crashed on me
[22:13] <zyga-ubuntu> no
[22:13] <zyga-ubuntu> it's not an electron app
[22:13] <zyga-ubuntu> it's really native and fantastically speedy
[22:13] <zyga-ubuntu> it also auto saves its buffers if you kill your session like I sometimes do so you don't loose any work
[22:13] <om26er> its a GTK app
[22:14] <zyga-ubuntu> yes, gtk though just for the "gimme window" really
[22:16] <zyga-ubuntu> kyrofa: it uses python for plugins
[22:16] <zyga-ubuntu> kyrofa: it has nice simple syntax extension system
[22:16] <zyga-ubuntu> kyrofa: it has it's own place for plugins/extensions (package control)
[22:16] <kyrofa> Hmm, it sounds quite nice indeed
[22:16] <zyga-ubuntu> kyrofa: it can take any python plugins you write
[22:16] <zyga-ubuntu> kyrofa: I switched from vim
[22:16] <zyga-ubuntu> and that says something
[22:16] <zyga-ubuntu> it's really fricking awesome IMO
[22:17] <zyga-ubuntu> kyrofa: and it has docs which I found surprising for most software doesn't have any
[22:26] <mup> PR snapd#4535 opened: interfaces: miscellaneous policy updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4535>
[22:28] <zyga-ubuntu> jdstrand: I'll get it in for ~rc2
[22:31] <cachio> ogra_, it works https://paste.ubuntu.com/26454638/
[22:31] <cachio> it is on pi3
[22:31] <cachio> without classic
[22:32] <jdstrand> zyga-ubuntu: thanks! that one is against master. I'm preparing a PR for 2.31 now
[22:33] <diddledan> new one: https://paste.ubuntu.com/26454647/
[22:33] <diddledan> specifically: Failed to run: /snap/lxd/current/bin/lxd forkmount 30519 /dev/.lxd-mounts/lxdmount_729321534 /root/build_gnome-terminal: Failed mounting /dev/.lxd-mounts/lxdmount_729321534 onto /root/build_gnome-terminal: Invalid argument
[22:34] <diddledan> looks like the lxd snap was refreshed 2 hours ago. possibly it didn't happen cleanly?
[22:35] <diddledan> refreshed by my system:
[22:35] <diddledan> https://www.irccloud.com/pastebin/JdJDT9OU/
[22:39] <zyga-ubuntu> jdstrand: +1
[22:41] <zyga-ubuntu> niemeyer: we have issues with https://github.com/snapcore/snapd/pull/4534 - I restarted it a few times already
[22:41] <mup> PR #4534: release: 2.31~rc1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4534>
[22:41] <niemeyer> zyga-ubuntu: What's happening there?
[22:41] <zyga-ubuntu> niemeyer: this time it aborted all 1620 tasks
[22:41] <zyga-ubuntu> niemeyer: everything:
[22:41] <zyga-ubuntu> 2018-01-24 22:27:11 Cannot allocate linode:debian-9-64: cannot find public IP for linode:debian-9-64 (Spread-5448035)
[22:42] <zyga-ubuntu> 2018-01-24 22:31:06 Cannot allocate linode:debian-9-64: cannot allocate disk linode:debian-9-64 (Spread-5448015): cannot get job details for linode:debian-9-64 (Spread-5448015): empty result
[22:42] <niemeyer> zyga-ubuntu: I'm fixing that one as we speak
[22:42] <niemeyer> zyga-ubuntu: It's still a consequence of the early issue today
[22:42] <zyga-ubuntu> excellent, thank you!
[22:42] <zyga-ubuntu> ack
[22:42] <niemeyer> zyga-ubuntu: Should be ready in a few minutes
[22:44] <diddledan> ok, snap.lxd.daemon.service is failed. already running but failed. restarting thru systemd caused lxd to complain it was already running - systemd thought it wasn't. needed to manually kill lxd processes and then restart the systemd service again
[22:45] <diddledan> working find now
[22:45] <diddledan> fine*
[22:49] <mup> PR snapd#4536 opened: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
[22:49] <jdstrand> zyga-ubuntu: fyi, https://github.com/snapcore/snapd/pull/4536
[22:49] <mup> PR #4536: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4536>
[22:49] <jdstrand> oh heh
[22:50] <jdstrand> zyga-ubuntu: I milestoned that one for 2.31.
[22:53] <zyga-ubuntu> ack
[22:53] <zyga-ubuntu> jdstrand: do you have anything else for https://github.com/snapcore/snapd/pull/4471 ?
[22:53] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[22:53] <jdstrand> zyga-ubuntu: no
[22:54] <zyga-ubuntu> ready to approve?
[22:54] <jdstrand> well, it had 3 approvals already. I didn't study all the code bits. if you want me to comment/approve on what I did look at, I can
[22:56] <niemeyer> zyga-ubuntu: Alright, please give it another shot
[22:56] <niemeyer> zyga-ubuntu: The issue was that when these errors happened in the morning, Linode allocated something completely bogus
[22:56] <zyga-ubuntu> jdstrand: I'd love that
[22:56] <zyga-ubuntu> niemeyer: trying
[22:56] <niemeyer> zyga-ubuntu: We had about 90 machines that had no IP even
[22:56] <zyga-ubuntu> uuhh
[22:56] <zyga-ubuntu> cloud is hard
[22:56] <zyga-ubuntu> is linode an openstack or a custom thing?
[22:56] <niemeyer> Software is hard, I suppose :)
[22:57] <niemeyer> Custom thing.. predates OpenStack by.. 20 years? :)
[22:57] <zyga-ubuntu> I spawned one run
[22:57] <zyga-ubuntu> ooh, that explains a lot
[22:57] <zyga-ubuntu> well, I applaud them for running so long :)
[22:57] <niemeyer> Yeah
[22:57] <zyga-ubuntu> though it feels like other clouds are more mature API wise
[22:57] <niemeyer> zyga-ubuntu: I see healthy machines spawning
[22:58] <zyga-ubuntu> niemeyer: some runs of older spread are still in flight
[22:58] <zyga-ubuntu> niemeyer: so they can affect the new runs
[22:58] <niemeyer> zyga-ubuntu: Yeah, this running bill thing is relatively new for them.. the usual business back then was a fixed low monthly price
[22:58] <zyga-ubuntu> but this will stop in ~~30 minutes or so
[22:58] <niemeyer> 23ish, I hope
[22:58] <zyga-ubuntu> yeah, I imagine, lots of "just replace my physical server" customers
[22:59] <zyga-ubuntu> niemeyer: is there any chance you can approve 4471 now? it's my last PR and the blocker for more goodies
[23:00]  * zyga-ubuntu always feels weird when he notices irssi "Day changed" notifications
[23:00] <niemeyer> No, sorry.. my family is having dinner and I'm still here getting tests running smoothly
[23:00] <niemeyer> I need to step out ASAP
[23:00] <zyga-ubuntu> k
[23:01] <niemeyer> If things go well I'll be back in business tomorrow
[23:01] <zyga-ubuntu> enjoy your evening, see you tomorrow!
[23:01] <niemeyer> zyga-ubuntu: Thanks, have a good night you too
[23:01] <niemeyer> zyga-ubuntu: It looks like they all allocated just fine now.. fingers crossed
[23:01] <zyga-ubuntu> yeah, looks good
[23:02] <zyga-ubuntu> I'm looking at "follow" log
[23:02] <zyga-ubuntu> 2018-01-24 23:02:31 Cannot allocate linode:debian-9-64: server linode:debian-9-64 (Spread-5460254) concurrently allocated, giving up on it
[23:02] <zyga-ubuntu> I'll wait till all the other runs shut down and retry if this fails
[23:47] <mup> PR snapd#4326 closed: interfaces/builtin: blacklist zigbee dongle <Decaying> <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4326>
[23:49] <mup> PR snapd#4536 closed: interfaces: miscellaneous policy updates - 2.31 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4536>
[23:50] <zyga-ubuntu> jdstrand: I'm about to EOD but my last request would to enqueue 3963 as I'm inclined to merge and interate upon that whenever you give the green light
[23:51] <zyga-ubuntu> jdstrand: as layouts move to policy topics and I have enough branches to keep reviews busy I was thinking I would look at per-user mounts
[23:51] <cprov> kyrofa: https://dashboard.staging.snapcraft.io/docs/api/macaroon.html#post--dev-api-acl- but it doesn't go in detail each acl. Can you please file a bug in lp:snapstore requesting it ? we will extend the docs.