[00:38] <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>
[02:32] <mup> PR snapcraft#1528 opened: recording: record the machine information collected by uname <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1528>
[04:05] <mup> PR snapcraft#1529 opened: recording: record the packages installed in the machine <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1529>
[04:44] <zyga-suse> good morning
[04:44]  * zyga-suse will start at 9:30 because of the 1st day at school and some coordination/assistance required
[04:44] <zyga-suse> see you then
[06:09] <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>
[06:34] <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>
[06:41] <zyga-ubuntu> mvo: hello
[06:43] <mvo> hey zyga-ubuntu
[06:47] <zyga-ubuntu> mvo: today is the 1st day of school for us, how about your kids?
[06:47] <mvo> zyga-ubuntu: school started  2 weeks ago here
[06:47] <mvo> zyga-ubuntu: how was getting up ?
[06:49] <zyga-ubuntu> mvo: woah, two weeks? that's brutal :)
[06:49] <zyga-ubuntu> mvo: so no august holidays?
[06:49] <zyga-ubuntu> mvo: it was all right, with the exception of my son we all woke up at 6am
[06:49] <mvo> zyga-ubuntu: holidays started early here
[06:50] <mvo> zyga-ubuntu: nice!
[06:50] <zyga-ubuntu> mvo: we introduced new rules to make sure nothing flashly/briht/(tv/computer) is on past 21:00
[06:50] <mvo> zyga-ubuntu: the only thing I hate is the getting-up early
[06:50] <mvo> zyga-ubuntu: that sounds reasonable
[06:50] <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
[06:51] <zyga-ubuntu> mvo: and I'm looking forward to working at 6:30 soon
[06:52] <zyga-ubuntu> mvo: trivial comments from gustavo on https://github.com/snapcore/snapd/pull/3625
[06:52] <mup> PR #3625: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625>
[06:54] <mvo> zyga-ubuntu: yeah, working on them now and then I will merge
[06:55] <mvo> zyga-ubuntu: there are some easy ones in the queue that just need a second review
[06:55] <mvo> zyga-ubuntu: e.g. 3844
[06:59] <zyga-ubuntu> mvo: I'll have a look, going bottom up
[07:01] <mvo> zyga-ubuntu: please leave some of the scary looking out, I have not branched 2.28 yet
[07:01] <mvo> zyga-ubuntu: but want to do in a little bit, so please not the debian/ dir changes
[07:01] <mvo> zyga-ubuntu: and also not 3727 (that needs a second review anyway)
[07:05] <zyga-ubuntu> mvo: noted
[07:07] <zyga-ubuntu> ok, one more and I'm going to pick them up
[07:08] <mvo> zyga-ubuntu: pick which one up?
[07:11] <zyga-ubuntu> mvo: my kids :)
[07:11] <zyga-ubuntu> mvo: I'm reading https://github.com/snapcore/snapd/pull/3777/files
[07:11] <mup> PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777>
[07:14] <zyga-ubuntu> ok, I'll read the rest later, going to school, ttyl
[07:18] <mvo> zyga-ubuntu: bye
[07:18] <mvo> pstolowski: good morning!
[07:18] <pstolowski> mvo, morning!
[07:20] <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
[07:21] <pstolowski> mvo, indeed, i'll look at it shortly, thanks!
[07:23] <mvo> ta
[07:27] <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>
[07:55] <Chipaca> g'morning, all
[07:56] <mimag1> Good morning
[07:58] <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?
[08:00] <Chipaca> mimag1: I think the source of a python part can be a directory
[08:00] <Chipaca> e.g. source: .
[08:00] <mimag1> I have that and in that directory I have the package and an setup.py
[08:01] <mimag1> plugin: python and plugin-version: python3
[08:01] <Chipaca> mimag1: and what doesn't work?
[08:01] <mimag1> "Could not find a version that satisfies the requirement pytiip (from versions: )"
[08:01] <mimag1> No matching distribution found for pytiip
[08:02] <Chipaca> mimag1: can you share your whole yaml so i can reproduce this?
[08:03] <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
[08:03] <Chipaca> mvo: but, what do you think of that approach?
[08:06] <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>
[08:06] <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>
[08:06] <zyga-ubuntu> re, back from school, now peace and quiet for the rest of the day
[08:06] <mimag1> parts:
[08:06] <mimag1>   pytiip:     source: repos/pytiip     plugin: python     python-version: python3
[08:09] <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?
[08:11] <Chipaca> mvo: say aw is an atomicwriter
[08:11] <Chipaca> mvo: and aw.Write() fails, for whatever reason
[08:11] <ogra_> popey, same cpu and wlan device, might even work with the nanopi-air image
[08:11] <Chipaca> mvo: so now you need to close it and remove the file, without committing
[08:12] <Chipaca> mvo: if close is commit, that's harder
[08:12] <mvo> Chipaca: aha, yes, good point. will things work if you do "aw.Write(); aw.Commit(); aw.Write(); aw.Commit()"?
[08:12] <Chipaca> mvo: no, at least as written, Commit imples Close
[08:13] <zyga-ubuntu> mvo, Chipaca: maybe commit and rollback
[08:13] <zyga-ubuntu> to make it crystal clear what they are
[08:13] <Chipaca> zyga-ubuntu: what would rollback do?
[08:13] <Chipaca> i
[08:14] <Chipaca> the way i wrote it, the creator of the aw is the one that needs to handle cleanup on error
[08:14] <Chipaca> just like with 'plain' files
[08:14] <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"?
[08:15] <Chipaca> mvo: hmm... good point. Atomize()? :-P
[08:15] <Chipaca> (still feeling bad about having a Fooer interface that doesn't have a Foo() method)
[08:16] <mvo> Chipaca: yeah, and the enhanced version is called Fusionize()
[08:16] <Chipaca> Unionize()
[08:16] <mvo> lol
[08:18] <mimag1> What is required from a python directory to make the python plugin work?
[08:18] <zyga-ubuntu> Chipaca: I mean rollback as a rename of close
[08:18] <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
[08:18] <Chipaca> zyga-ubuntu: but rollback to me would imply it cleans up the tempfile also
[08:19] <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
[08:20] <Chipaca> something along the lines of Finalize would work for me
[08:20] <Chipaca> looking at synonyms now
[08:21] <zyga-ubuntu> Done()
[08:21] <zyga-ubuntu> RealllyHitTheDisk()
[08:21]  * zyga-ubuntu needs to read that PR
[08:28] <Chipaca> Enfeoff() \o/
[08:29] <zyga-ubuntu> Achoo()?
[08:36] <Chipaca> mimag1: so
[08:36] <Chipaca> mimag1: this is kinda silly i fear
[08:36]  * Chipaca tries something else
[08:41] <mimag1> what is silly?
[08:52] <Chipaca> mimag1: I'm afraid I'm stumped; you'll have to get help from an actual snapcrafter
[08:52] <Chipaca> it _should_ work, as far as i know, and in fact it seems to half work and then lose itself
[08:53] <mimag1> @Chipaca exactly my experience
[08:53] <nothal> mimag1: No such command!
[08:54] <Chipaca> nothal: dance for me
[08:54] <mimag1> exactly my experience
[08:54] <mimag1> nothal: Which command is wrong?
[08:58] <Chipaca> mimag1: nothal is a bot, that can take commands explicitly starting them with @
[08:59] <Chipaca> mimag1: as @ is not usually used to start messages in irc, it used to work
[08:59] <Chipaca> but then other chat systems happened, and nothal hasn't adapted
[09:00] <Chipaca> mimag1: wrt your issue, i'd suggest asking in the forum, or in rocketchat (snapcrafters use rocketchat more than the forum, i think)
[09:00] <Chipaca> that's https://forum.snapcraft.io/ or https://rocket.ubuntu.com/channel/snapcraft
[09:02] <mimag1> Thank you Chipaca
[09:15] <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.
[09:15] <mzanetti> Can't really find something in the docs so far
[09:17] <mvo> pstolowski: do we have a forum post about the new install/remove hooks? anything I could link to?
[09:18] <pstolowski> mvo, not yet, but I'll create one soon
[09:18] <mvo> pstolowski: thank you
[09:30] <mimag1> mzanetti, mvo, psstolowski: +1 on that forum post. I have written some configure hooks but I guess there is a better way
[09:43] <zyga-ubuntu> wow, we are at 17 open PRs
[09:43]  * zyga-ubuntu reviewed a repair PR, fist in a long time
[09:43] <zyga-ubuntu> lookin at more
[09:44] <zyga-ubuntu> Chipaca: one thing I wanted to share with you, not sure if you used it yet
[09:44] <zyga-ubuntu> Chipaca: you probably know about this already
[09:45] <Chipaca> zyga-ubuntu: spit it out already :-D
[09:45] <zyga-ubuntu> Chipaca: but please read the section on O_TMPFILE in open(2)
[09:45] <zyga-ubuntu> Chipaca: this allows you to create a file, write all data, set mode and ownership
[09:45] <zyga-ubuntu> Chipaca: and only make it show up, atomically
[09:45] <zyga-ubuntu> Chipaca: or die with the process
[09:45] <zyga-ubuntu> Chipaca: it's a very compelling API
[09:46] <zyga-ubuntu> Chipaca: I wanted to make sure you know about it, and with that note, I'm going to review the rest
[09:46] <Chipaca> I did not know about this
[09:46] <Chipaca> thank you
[09:46] <Chipaca> zyga-ubuntu: 3.11 is << our minimal kernel version, i take it?
[09:46] <zyga-ubuntu> my pleasure :)
[09:46] <Chipaca> ondra: ^?
[09:47] <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
[09:47] <Chipaca> (i mean, the minimal kernel version our users are using, which is almost certainly < than the one we support)
[09:47] <zyga-ubuntu> Chipaca: though a perfect implementation would degrade gracefully
[09:47] <Chipaca> nice
[09:47] <Chipaca> i'll wait for ondra to speak up (or 301 me)
[09:47] <zyga-ubuntu> Chipaca: in general, it's a very good API to have for atomicity
[09:48] <zyga-ubuntu> 301?
[09:48] <ondra> Chipaca hey
[09:48] <Chipaca> zyga-ubuntu: "ask so-n-so"
[09:49] <ondra> Chipaca I think it was even 3.10
[09:49] <Chipaca> ondra: as in, people using 3.10 with snappy?
[09:49] <Chipaca> ondra: do you know if it's tweaked to also have O_TMPFILE?
[09:49] <ondra> Chipaca I think there were some attempts, but using is probably too strong statement
[09:49] <Chipaca> zyga-ubuntu: grep -r O_TMPFILE /usr/share/go-1.6 and weep
[09:49] <Chipaca> ondra: :-) ok
[09:52] <Chipaca> zyga-ubuntu: I'd have to look into how this behaves for the wrong kernel and the wrong filesystem, to fallback properly
[09:52] <zyga-ubuntu> ESYS
[09:52] <zyga-ubuntu> AFAIR
[09:52] <zyga-ubuntu> but please check
[09:55] <Chipaca> zyga-ubuntu: the docs say EISDIR (kernel) or EOPNOTSUPP (filesystem)
[09:56] <zyga-ubuntu> ahh, sorry then, I must be wrong
[10:00] <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>
[10:06] <Chipaca> zyga-ubuntu: how do you use O_TMPFILE to replace an existing file?
[10:07] <Chipaca> zyga-ubuntu: linkat doesn't let you replace files
[10:08] <zyga-ubuntu> Chipaca: you can still link it to .foo and then call move
[10:11] <Chipaca> hmmm
[10:12] <Chipaca> the cleanup story becomes a lot harder
[10:12] <Chipaca> hmm hmm
[10:12] <zyga-ubuntu> Chipaca: in which way?
[10:12] <Chipaca> zyga-ubuntu: "close it, and if it was created, remove it"
[10:12] <Chipaca> meaning we'd probably have to make something on the object itself
[10:12] <zyga-ubuntu> Chipaca: note that this was just a suggestion, if it makes anything harder then by all means, ignore it: )
[10:12] <Chipaca> zyga-ubuntu: i like it, i'm just thinking it through
[10:13] <Chipaca> loudly and using you as the sock puppet
[10:14] <zyga-ubuntu> Chipaca: oh, one related note: https://betanews.com/2017/09/03/android-oreo-linux-kernel/
[10:14] <zyga-ubuntu> haha, my pleasure :)
[10:14] <zyga-ubuntu> All SoCs productized in 2017 must launch with kernel 4.4 or newer.
[10:14] <Chipaca> zyga-ubuntu: your network is so lagged it's fun
[10:14] <zyga-ubuntu> so 4.4 is a good bet for many new pieces of hardware
[10:14] <Chipaca> * Ping reply from zyga-ubuntu: 1.631 second(s)
[10:14] <zyga-ubuntu> Chipaca: my network is actually brilliantly fast now
[10:14] <zyga-ubuntu> oh?
[10:15] <zyga-ubuntu> I saw 0.6 on my end
[10:15] <zyga-ubuntu> not sure where that much of a lag is coming from
[10:15] <Chipaca> zyga-ubuntu: i just pung jamie and got .3s
[10:15] <Chipaca> so it's not me :-)
[10:16] <zyga-ubuntu> jamie is 0.7
[10:16]  * zyga-ubuntu pings pawel 
[10:16] <Chipaca> yeah, consistently getting 1+ seconds (and i only noticed because of how delayed your answers were)
[10:16] <zyga-ubuntu> pawel is 0.6
[10:16] <zyga-ubuntu> weirdish
[10:16] <zyga-ubuntu> anyway, I was never happier with any network before
[10:16] <Chipaca> zyga-ubuntu: good to know
[10:16] <zyga-ubuntu> highest bandwidth and mobility
[10:17]  * zyga-ubuntu stops bragging
[10:17] <Chipaca> zyga-ubuntu: and you get 1TB (or 1Tb?)
[10:17] <zyga-ubuntu> yes
[10:17] <zyga-ubuntu> a month
[10:17] <zyga-ubuntu> and it's not location-bound
[10:17] <zyga-ubuntu> I'm seeing 12-15MB/s to ubuntu archive
[10:18] <zyga-ubuntu> I haven't tried much more though :)
[10:18]  * zyga-ubuntu sees rain outside and feels like being in London
[10:29] <mvo> pedronis: you asked a question in 3642 - is that something that needs more work or are you happy with the reply?
[10:31] <pedronis> mvo: one sec
[10:31] <zyga-ubuntu> 16 requests :)
[10:31] <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
[10:32] <Chipaca> pedronis: why do I imagine half your house on fire
[10:32] <pedronis> hopefully not, but there was a zero chance it could :/
[10:32] <Chipaca> pedronis: probably https://www.youtube.com/watch?v=1EBfxjSFAxQ
[10:32] <pedronis> a non-zero
[10:33] <mvo> pedronis: uh, good lucj
[10:33] <mvo> luck
[10:35]  * zyga-ubuntu sees red in travis :/
[10:35] <zyga-ubuntu> pedronis: stay safe!
[10:36] <zyga-ubuntu> <kill-timeout reached>
[10:36] <zyga-ubuntu> does anyone know what the timeout is?
[10:36] <zyga-ubuntu> it would be awesome if spread said that
[10:40] <Chipaca> zyga-ubuntu: and in the end I'm writing stuff that looks alarming like Rollback
[10:42] <zyga-ubuntu> Chipaca: does that mean I get two +1s or two -1s?
[10:43] <Chipaca> zyga-ubuntu: I don't know.
[10:43] <Chipaca> zyga-ubuntu: I'm calling it Cancel, anyway
[10:43] <zyga-ubuntu> Cancel is nice
[10:43] <zyga-ubuntu> oh
[10:43] <Chipaca> zyga-ubuntu: because mvo's point about calling Commit multiple times makes some sense
[10:43] <zyga-ubuntu> feels like context
[10:43] <Chipaca> (only some, because you can't commit multiple times in sql afaik)
[10:44] <Chipaca> zyga-ubuntu: only doing this refactor so it's easier to do the tmpfile later
[10:47] <ogra_> grmbl
[10:47] <ogra_> why dont i have a /dev/fb0 in my initrd on the pi
[10:53] <ogra_> zyga-ubuntu, so any ideawhy the opengl interface fix is not in edge ?
[10:53] <ogra_> i thought we do rebuilds of the edge deb for every commit ?
[10:54] <ogra_> s/commit/merged PR/
[10:54] <ogra_> mvo, ^^ is that not the case ?
[10:55] <mvo> ogra_: yes, that should be the case, lets check the edge ppa
[10:55] <mvo> ogra_: when did the fix land?
[10:55] <ogra_>  mvo5 merged commit 6d8d625 into snapcore:master 4 days ago
[10:55] <ogra_> says GH
[10:56] <ogra_> apparently snapd FTBFS since the 31st
[10:56] <ogra_> (well, on arm and i386)
[10:58] <pedronis> zyga-ubuntu: I think kill-timeout  is 20m , that's what in spread.yaml
[10:58] <ogra_> mvo, if i read the log right (not sure i do) it fails in the github.com/snapcore/snapd/x11 test
[10:59] <ogra_> ah, no, there are earlier ones
[11:00] <mvo> ogra_: hm, 4 days ago
[11:00] <ogra_> uh
[11:00] <ogra_> bad system call
[11:00] <ogra_> https://launchpadlibrarian.net/335269966/buildlog_ubuntu-xenial-armhf.snapd_2.27.5+git354.834024b~ubuntu16.04.1_BUILDING.txt.gz
[11:00] <mvo> ogra_: yeah, but that is already 4 days old
[11:01] <ogra_> yep
[11:01] <mvo> ogra_: and this should be fixed in master
[11:01] <mvo> ogra_: looks like our automatic merging via snap-cron is not working
[11:01] <ogra_> did fgimenez take all his PPA scripts with him ?
[11:01] <mvo> ogra_: I have a look, but maybe I need cachio
[11:01] <mvo> ogra_: this is actually possible :(
[11:01] <ogra_> (might be the build was triggered under his user)
[11:01] <mvo> ogra_: I mean, its possible that the upload creds got removed with his account
[11:02] <ogra_> yeah
[11:03] <ogra_> under "uploader" there is "no signer" ... https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
[11:03] <ogra_> (never seen that)
[11:03] <zyga-ubuntu> ogra_: no, no idea, maybe due to imminent release
[11:03] <zyga-ubuntu> ogra_: I really really wish we had a setup where edge == master in all cases
[11:03] <ogra_> zyga-ubuntu, well, see above we lost the daily snapd deb
[11:03] <zyga-ubuntu> ogra_: and releases would build from a separate PPA and separate recipe of core
[11:03] <ogra_> zyga-ubuntu, it is !
[11:03] <mvo> ogra_: I retriggered the job, that should give me some data, if that fails I need to talk to cachio
[11:04] <mvo> ogra_: but the date (2017-08-31) is suspecious, that is the date that federico left
[11:04] <ogra_> zyga-ubuntu, only if mvo does a relese build manually it isnt usually ... but thats really short snapshot times
[11:04] <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
[11:04] <zyga-ubuntu> pedronis: thank you!
[11:04] <zyga-ubuntu> ogra_: again, I wish it was never
[11:04] <ogra_> zyga-ubuntu, we onyl ever have to delete the deb that was manually uploaded to the image ppa
[11:05] <ogra_> so the manual step changes it and the manual step switches it back ... for full release control
[11:05] <zyga-ubuntu> well, we don't need that
[11:05] <zyga-ubuntu> we need control over beta, candidate and stable
[11:05] <ogra_> zyga-ubuntu, though if the shema i develoed ages ago with federico would have been implemented you wouldnt have that setp ever :)
[11:05] <zyga-ubuntu> edge should be on autopilot all the time
[11:05] <zyga-ubuntu> I'm sure we can improve things :)
[11:05] <ogra_> we have a roperly worked out build plan
[11:06] <ogra_> just never implemented
[11:06] <ogra_> *properly
[11:06] <ogra_> it is exactly focused to fix your complaint ... :)
[11:06] <ogra_> *on fixing
[11:08] <ogra_> mvo, i'll try to trigger a build of https://code.launchpad.net/~snappy-dev/+recipe/snapd-vendor-daily ... lets see
[11:08] <ogra_> (speak up if i shouldnt please)
[11:10]  * ogra_ clicks the button
[11:18] <mvo> ogra_: the vendor sync thing ran some minutes ago, I will double check
[11:20] <mvo> ogra_: ok, powerpc and s390x fail but the rest is building
[11:20] <ogra_> well, arm64 isnt done yet :)
[11:20] <ogra_> but yeah, looks better already
[11:22] <ogra_> mvo, the upload log looks weird as well though ... might be we need to manually delete the old package
[11:22] <ogra_> https://launchpadlibrarian.net/335757858/upload_1442402_log.txt
[11:25] <mvo> ogra_: thats ok
[11:25] <ogra_> ok
[11:25] <mvo> ogra_: I think what happend is that the sync also triggered an upload
[11:25] <ogra_> ah
[11:25] <mvo> ogra_: and then you triggered one manually and the changelog version is the same
[11:25] <mvo> ogra_: which is fine because the content is the same :)
[11:25] <ogra_> indeed
[11:26] <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
[11:27] <ogra_> mvo, will do
[11:30] <ogra_> edge build running
[11:38] <greyback> hey, should tha RPI3 image automatically resize the writable partition to fill the SD card on first boot?
[11:39] <ogra_> greyback, yes
[11:39] <greyback> ogra_: didn't work for me just now (today's daily edge). I'll log bug
[11:40] <ogra_> greyback, there iss a log kept in /run/initramfs (note thats a tmpdir though ... so it is gone if you reboot)
[11:40] <greyback> ogra_: ack. I'll reflash and grab that for you
[11:41] <ogra_> greyback, als include df -h /writable please (and syslog and dmesg output)
[11:41] <ogra_> *also
[11:41] <greyback> *nod*
[11:41] <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
[11:42] <greyback> oh interesting. I didn't get a cheap one at least
[11:43] <ogra_> http://elinux.org/RPi_SD_cards
[11:43] <ogra_> not sure how valid that still is though ... originally created 2012
[11:47] <zyga-ubuntu> get a HDD
[11:47] <zyga-ubuntu> screw SD
[11:48] <ogra_> heh
[11:48]  * zyga-ubuntu waits for first boot-from-CD rpi hack
[11:48] <ogra_> are USB-CD drives still being sold ?
[11:49] <greyback> https://pastebin.ubuntu.com/25464779/ - resize doesn't appear to error out, but no change
[11:50] <zyga-ubuntu> ogra_: yesd
[11:50] <zyga-ubuntu> ogra_: and arguably, still useful :)
[11:50] <ogra_> pfft
[11:51] <ogra_> greyback, hmm, looks all fine (apart from the size)
[11:51] <ogra_> greyback, how big is that SD ?
[11:51] <greyback> ogra_: 32GB
[11:51] <zyga-ubuntu> 4cm by 2cm
[11:51]  * zyga-ubuntu hides
[11:51] <greyback> :D
[11:52] <ogra_> zyga-ubuntu, then he would need to fold it to fit into the slot :P
[11:52] <ogra_> that might indeed be the prob then :P
[11:53] <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
[11:53] <greyback> ogra_: I typically unmount before flashing. But let me try once more, to be totally certain.
[11:55] <greyback> kde, why did you remount something I explicitly unmounted
[11:55] <ogra_> heh
[11:59] <greyback> ogra_: ok, that did it. Apologies for the noise
[12:01]  * Chipaca ~> run and lunch
[12:03] <ogra_> greyback, np
[12:04] <zyga-ubuntu> jdstrand: hey, around?
[12:06] <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
[12:06] <greyback> ogra_: noted. Will try
[12:06] <greyback> ogra_: fixing the udev script did the job too
[12:07] <ogra_> indeed ...
[12:07] <ogra_> the new core should generate it propely from the start though
[12:08] <zyga-ubuntu> jdstrand: so I'll just leave you a message
[12:08] <zyga-ubuntu> jdstrand: I'm looking ad child profiles but I get compile errors
[12:09] <zyga-ubuntu> jdstrand: the apparmor reference has this worring statement:
[12:09] <zyga-ubuntu> jdstrand:  <path> 'x' '->' <profile list> ',' (not yet supported)
[12:09] <zyga-ubuntu> jdstrand: it does have:  ('safe' | 'unsafe') <path> <qualifier>'x' [[' ->' <profile name>] ['+' <profile name>]] ','
[12:09] <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
[12:15] <zyga-ubuntu> ahhh
[12:15] <zyga-ubuntu> darn :)
[12:16] <zyga-ubuntu> jdstrand: so just for information, I was stuck on the fact that the child profile cannot have dashes in it
[12:22] <mvo> zyga-ubuntu: jdstrand is off today afaik, labor day in the us
[12:33] <zyga-ubuntu> mvo: ah I didn't know
[12:33] <zyga-ubuntu> anyway I'm progressing, I just launched a run of tests/main/ with child profile on snap-update-ns
[12:33] <zyga-ubuntu> which gives me enough time to make something to drink :)
[12:35] <zyga-ubuntu> hmm
[12:35] <zyga-ubuntu> mvo: after base snap patches landed in master my tests started to fail
[12:39] <mvo> zyga-ubuntu: what tests exactly?
[12:39] <zyga-ubuntu> https://travis-ci.org/snapcore/snapd/builds/271651836?utm_source=github_status&utm_medium=notification base-snaps spread test
[12:40] <zyga-ubuntu> mvo: I'm runnin a sequence with -debug so I'll get to that soon
[12:40] <zyga-ubuntu> just curious what happened there
[12:41] <zyga-ubuntu> oh man, it's raining crazy
[12:43] <mup> PR snapd#3846 opened: debian: add missing flags when building static snap-exec <Created by mvo5> <https://github.com/snapcore/snapd/pull/3846>
[12:43] <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
[12:43] <mvo> zyga-ubuntu: heh
[12:44] <zyga-ubuntu> mvo: it passed just a moment ago, before the merge
[12:44] <zyga-ubuntu> mvo: but that's fine, I'll get to the bottom of this
[12:44] <zyga-ubuntu> mvo: but I wanted to mention this in case it affects 2.28
[12:45] <mvo> zyga-ubuntu: yeah, its a new test
[12:47] <ogra_> dang !
[12:48] <ogra_> no framebuffer device in pi initrd's without a gazillion of drm/kms modules :/
[12:49] <mvo> zyga-ubuntu: hm, I guess the problem is that snap-update-ns needs to be static linked
[12:49] <mvo> zyga-ubuntu: same problem as snap-exec, if you run it *inside* the bare base there is no libc
[12:50] <zyga-ubuntu> mvo: that makes sense
[12:51] <zyga-ubuntu> mvo: thanks, I'll make the modifications
[12:52] <zyga-ubuntu> ah
[12:52] <zyga-ubuntu> darn, meeting is coming up and I'm parched
[13:03] <ogra_> ppisati, do you think building vc4 intob the kernel would do any harm on rpi ?
[13:03] <ogra_> (specifically if the dtb overlay does not get used)
[13:23] <ikey> heh http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=apparmor-4.13%2boutoftree
[13:23]  * ikey yoinks it
[13:27] <ppisati> ogra_: waste of some memory, probably
[13:27] <ppisati> ogra_: what's the matter with it being a module?
[13:27] <zyga-ubuntu> Chipaca: I did a quick review of the packaing branch, I'll do a deeper one now
[13:28] <zyga-ubuntu> Chipaca: also dropped a crazy suggestion that may, ironically, be nicer if you think along the same lines
[13:28] <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
[13:29] <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
[14:03] <Chipaca> zyga-ubuntu: wrt your cray-cray suggestion, is mwhudson going to nyc?
[14:03] <Chipaca> zyga-ubuntu: because it's the kind of crazy that requires all hands on beer
[14:04] <Chipaca> but, maybe? it's probably doable
[14:04] <Chipaca> for debian-ish things at least
[14:04] <Chipaca> hope you don't mean also for non-debianish
[14:05] <zyga-ubuntu> Chipaca: I think so
[14:05] <zyga-ubuntu> Chipaca: so far I meant debian-ish
[14:05] <ikey> lol all hands on beer
[14:05] <zyga-ubuntu> Chipaca: which will give us enough rope for various debian+ubuntu releases
[14:06] <zyga-ubuntu> ikey: very serious topic that
[14:06] <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
[14:06] <zyga-ubuntu> ;)
[14:06] <ikey> ill settle for cider :P
[14:06] <ppisati> ogra_: at least, in theory, we should definitely try it :)
[14:06] <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
[14:06] <ogra_> ppisati, ahh, well, i generated and loaded a vc4modules.img ... i see all modules loaded but still no /dev/fb0
[14:06] <ikey> ya, chinwag.
[14:07] <Chipaca> ya
[14:07] <diddledan> you got a floppy chin, ikey ? :-p
[14:07] <ikey> nah i upgraded to an ssd shin
[14:07] <Chipaca> the beer is completely optional, and if anybody involved were opposed to it, it wouldn't feature at all
[14:07] <diddledan> aah
[14:07] <diddledan> beer sounds like a plan
[14:07] <ikey> beer is a cultural lubricant for the mind
[14:07] <ikey> (im irish, we have this nailed.)
[14:08] <diddledan> although considering it's only 3pm in the UK it might be a bit looked-down-upon
[14:08] <ikey> "liquid lunch"
[14:08] <ikey> >_>
[14:08] <diddledan> lol
[14:08] <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)
[14:08] <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)
[14:08] <ikey> oh i know
[14:08] <Chipaca> k
[14:08] <Chipaca> i just happen to know the people involved :-)
[14:08] <ikey> gotcha :D
[14:09] <Chipaca> zyga-ubuntu: now we need _you_ to get to nyc, don't we
[14:09] <Chipaca> :D
[14:09] <zyga-ubuntu> indeed,
[14:10] <ikey> at least the nyc flights wont be as bad as some of the US flights ive done
[14:10]  * zyga-ubuntu needs to break for a moment
[14:10] <ikey> (which was UK -> Amsterdam -> Portland OR usually)
[14:11] <ppisati> ogra_: weird... but if you let the system boot till userspace, fb0 is there, right?
[14:11] <ogra_> yep
[14:11] <ogra_> just not when stopping with break=premount
[14:11] <greyback> ikey: yuk, and no pre-clearance in Dublin
[14:11] <Chipaca> zyga-ubuntu: on the subject of that PR though, if 14.04 no longer needs snap.mount.service.wotsit, let's nuke it
[14:11] <Chipaca> i don't know how to go about nuking it, but let's
[14:12] <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..
[14:12] <ikey> actually worse than that is likely getting from tullamore to dublin in the first place :p
[14:12] <greyback> ikey: hah :)
[14:13]  * ikey has had "streets of new york" stuck in his head for 2 weeks though
[14:14] <zyga-ubuntu> Chipaca: not sure, check if it is installed
[14:14] <zyga-ubuntu> Chipaca: is it really shipped by the package
[14:14] <zyga-ubuntu> Chipaca: maybe it is, maybe not
[14:14]  * zyga-ubuntu really afk
[14:15]  * ikey should get a super obnoxious solus t-shirt printed off before heading out that way
[14:15] <Chipaca> zyga-ubuntu: in that's the actual packaging code used to package the package, it's packaged
[14:16] <pedronis> why I'm getting network time of 2106
[14:16] <greyback> ikey: we wouldn't recognise you without it ;)
[14:17] <ikey> ah sure you will
[14:17] <greyback> and stickers. A project dosn't exist without stickers
[14:17] <ikey> just look for the angriest looking person in nyc
[14:17] <ikey> (i have b*tchy resting face something chronic)
[14:17] <zyga-ubuntu> pedronis: must be that new internet... ipv6 they call t
[14:18] <ikey> plus ill have the cap :p
[14:18] <greyback> ikey: ah, we'll just have to give you some things to be legitimately angry about then
[14:18] <ikey> maybe ill get the head mad max'd again so i stick out
[14:19] <diddledan> new internet my foot. those kids today don't know they're born without trying the original internet!
[14:19] <ikey> greyback, you'd have a hard time not spotting this loon: https://ibin.co/3ZEhYhoxZ3Gf.jpg
[14:19] <ogra_> ppisati, hah .. i now just added all modules to my modules.img ... now i got fb0 (but psplash does hang )
[14:20] <greyback> ikey: so you're the one they speak of in Tullamore...
[14:20] <ikey> XD
[14:20] <greyback> it all becomes clear
[14:20] <ogra_> seems i was just missing some module (6though not sure which one)
[14:21] <diddledan> ALL the modules!
[14:21] <ogra_> only 10 o so :)
[14:21] <diddledan> bah. put moar!
[14:23] <ogra_> sigh .. this drm stuff gives me headdaches
[14:23] <ikey> who *really* needs graphics tho..
[14:23] <ogra_> ikey, shush, greyback is here :P
[14:24] <diddledan> what has a gui ever done for us?!
[14:24]  * ikey stands with the peoples fronts of nano
[14:24] <ikey> or is it the nano people's front..
[14:24] <diddledan> oh, I thought it was the popular front of Nano
[14:24] <ikey> still. what has the gui ever done for us?
[14:25] <diddledan> what happened to the popular front of people's nano?
[14:26]  * ikey slaps 4.13 kernel
[14:26]  * diddledan compiling ring-gnome-client
[14:27] <ikey> can certainly see how much of apparmor has gone upstream
[14:27] <ikey>  ...-Artful-jj-s-kernel-s-apparmor-4.13-outof.patch |  4023 ++++++
[14:27] <ikey>  ...-Artful-s-master-next-apparmor-implementa.patch | 13659 -------------------
[14:27]  * ogra_ dances around diddledan 
[14:27] <diddledan> is that an ironic "how much got upstreamed"?
[14:27] <ikey> no
[14:27] <diddledan> s/ironic/sarcastic/
[14:28] <ikey> for the 4.12.x kernels we had a 13.5k line patch
[14:28] <ikey> now we have a 4k line patch
[14:28] <diddledan> aha, that's pretty awesome then
[14:28] <ikey> aye
[14:28] <ikey> granted ive no idea if its gonna work but hey thats what unstable repos are for
[14:28] <diddledan> let those kernel dudes futs with looking after it :-p
[14:29]  * ikey is regrettably solus kernel dude
[14:29] <ikey> lol
[14:29] <ikey> ok admittedly im solus many-dude..
[14:29] <diddledan> aren't you solus <everything> dude, though?
[14:29] <ikey> many, not everything :p
[14:29] <ikey> we have other dudes
[14:30] <diddledan> like flexiondotorg is Ubuntu Martin <everything> dude :-p
[14:30] <ikey> lol ubuntu martin
[14:30] <ikey> i do a fair bit but you can see from https://build.solus-project.com/ its not just me
[14:30] <ogra_> ikey, boo, get more dudettes !
[14:30] <ikey> and a lot of stuff is landing other peoples patches
[14:30] <ikey> (from the community)
[14:31] <ikey> ogra_, ah true enough. tech needs more dudettes
[14:31] <ogra_> !
[14:31] <zyga-ubu1tu> ikey: 4.14 has more
[14:31] <ogra_> dudettes  ?
[14:31] <ogra_> cool
[14:32]  * ikey cries when he notices a new lts kernel too
[14:33] <cachio> ogra_, hey
[14:33] <ogra_> hey cachio
[14:33] <cachio> ogra_, working with console conf currently
[14:33] <cachio> and I see a problem in the dragonboard when I try to reconfigure the wifi settings
[14:33] <cachio> https://paste.ubuntu.com/25465490/
[14:33] <cachio> ogra_, it gives me a timeout error
[14:34] <cachio> any idea what could be causing that
[14:34] <cachio> if I run the same in the pi3 it works perfectly
[14:34] <ogra_> not really ... but my first look would go at netplan ...
[14:34]  * diddledan twiddles his thingies waiting for build
[14:35] <diddledan> https://imgs.xkcd.com/comics/compiling.png
[14:35] <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
[14:36] <ogra_> cachio, though the log looks like it comes up in the end
[14:36] <ogra_> Sep  4 14:26:17 localhost systemd-networkd[2984]: wlan0: Configured
[14:36] <cachio> ogra_, yes
[14:36] <ogra_> but you seem to have configured ipv6
[14:36] <cachio> it makes the configuration but it gives hte error
[14:36] <ogra_> perhaps that is getting in your way here
[14:36] <diddledan> frak
[14:36] <cachio> ogra_, I tried with ipv6 and without and the error is the same
[14:36] <diddledan> I got a stage package name wrong
[14:38] <diddledan> I really wish SNAPCRAFT_CONTAINER_BUILDS=1 didn't die on me
[14:41] <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 :-)
[14:41] <mup> PR #3845: osutil: include a variant of AtomicWrite* that takes an io.Reader <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>
[14:42] <mvo> Chipaca: heh, let me have a look again
[14:45] <zyga-ubuntu> ok, my apparmor profile works great
[14:45] <zyga-ubuntu> let's merge master and let's adjust build rules for snap-update-ns
[14:45] <zyga-ubuntu> mvo: thank you again :)
[14:49] <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
[14:50] <mvo> zyga-ubuntu: my pleasure
[14:50]  * zyga-ubuntu tests again
[14:55] <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.
[14:56] <zyga-ubuntu> om26er: hey, which interface is that?
[14:57] <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
[14:57] <om26er> zyga-ubuntu: org.kde.screensaver
[14:57] <zyga-ubuntu> om26er: so you would like to be the screensaver or talk to an existing screensaver?
[14:58] <om26er> zyga-ubuntu: I want to lock the screen and also check if its already locked.
[14:58] <om26er> (remotely)
[14:58] <zyga-ubuntu> I see, one sec
[14:58] <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>
[14:59] <zyga-ubuntu> om26er: so there's the screen-inhibit-control but it only allows one method
[14:59] <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
[15:00] <zyga-ubuntu> om26er: let me look at them
[15:00] <zyga-ubuntu> om26er: looking quickly I don't see any screensaver stuff there, so it would be a new interface
[15:00] <zyga-ubuntu> om26er: that interface will be provided by classic systems
[15:01] <zyga-ubuntu> om26er: and once connected it would allow your app to query the state
[15:01] <om26er> zyga-ubuntu: ah, shall I file a bug for that ?
[15:01] <zyga-ubuntu> om26er: as well as controll it (which might be a separate interface, not sure yet)
[15:01] <zyga-ubuntu> om26er: can you please open a forum thread
[15:01] <zyga-ubuntu> om26er: we kind of use forum more than bug tracker
[15:01] <om26er> I will do that.
[15:01] <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
[15:01] <zyga-ubuntu> om26er: thank you!
[15:03] <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"
[15:04] <zyga-ubuntu> om26er: no
[15:04] <zyga-ubuntu> om26er: interfaces have four elements
[15:04] <zyga-ubuntu> om26er: permanent plug and slot specification
[15:04] <zyga-ubuntu> om26er: and per-connection plug and slot specification
[15:04] <zyga-ubuntu> om26er: it depends on the interface what those do
[15:05] <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)
[15:05] <zyga-ubuntu> om26er: which interface did you specify?
[15:05] <zyga-ubuntu> kde-screensaver-dbus?
[15:06] <om26er> zyga-ubuntu: yes: https://github.com/om26er/linux-desktop-manager/blob/master/snap/snapcraft.yaml#L31
[15:06] <om26er> the commented lines at the end.
[15:06] <zyga-ubuntu> om26er: that's for *being* on the bus
[15:07] <zyga-ubuntu> om26er: the summary says: "allows owning a specifc name on DBus"
[15:07] <zyga-ubuntu> om26er: you don't want that
[15:08] <om26er> my understanding of dbus interfaces is very limited, so the terminologies confuse me =)
[15:09] <zyga-ubuntu> om26er: I can explain
[15:09] <zyga-ubuntu> om26er: the word interface is very overloaded
[15:09] <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)
[15:09] <zyga-ubuntu> om26er: there are dbus terms and snapd terms that apply
[15:10] <om26er> diddledan: that bit was clear, yes.
[15:10] <diddledan> :-)
[15:11] <zyga-ubuntu> mvo: hmmm
[15:11] <zyga-ubuntu> (cd _build/bin && GOPATH=$(pwd)/.. CGO_ENABLED=0 go build github.com/snapcore/snapd/cmd/snap-update-ns)
[15:11] <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
[15:11] <zyga-ubuntu> mvo: why did you set CGO_ENABLED=0 there
[15:11] <zyga-ubuntu> (I just copied that)
[15:12] <om26er> zyga-ubuntu: the only thing in dbus word that I don't understand is "owning a DBus interface". Other things are pretty clear.
[15:13] <diddledan> that would be like a snap slot. it is a service that you provide
[15:13] <cachio_lunch> mvo, FYI, 2.27.5 it is already in the mirrors
[15:13] <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.
[15:13] <mvo> zyga-ubuntu: because CGO_ENABLED=1 pulls in glibc and friends
[15:13] <cachio_lunch> I tested the upgrade and it works
[15:13] <zyga-ubuntu> mvo: and that is bad?
[15:14] <cachio_lunch> mvo, the smoke tests pass
[15:14] <mvo> zyga-ubuntu: for a static build yes
[15:14] <diddledan> so owning a dbus name/interface means you're listening for communication to that name
[15:14] <om26er> O Hi cachio_lunch =)
[15:14] <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
[15:14] <cachio_lunch> hi, om26er
[15:15] <mvo> cachio_lunch: great!
[15:15] <zyga-ubuntu> and cgo == not static?
[15:15]  * cachio_lunch gonna lunch now
[15:15] <mvo> zyga-ubuntu: well, that was the only way I found to disable dynamic linking, maybe there are more ways?
[15:16] <mvo> zyga-ubuntu: hold on a sec, I will create an example in a sec
[15:17] <diddledan> mvo: quick gooling: go build --ldflags '-extldflags "-static"' file.go
[15:17] <diddledan> I haven't tested whether that works tho
[15:17] <zyga-ubuntu> mvo: no need, I'll explore
[15:17] <zyga-ubuntu> mvo: I'm trying to make snap-update-ns static :)
[15:18] <pedronis> so I learned if /var/lib/systemd/clock  gets a strange mtime you are in for a lot of "fun"
[15:18] <mvo> diddledan: thanks a bunch!
[15:18] <diddledan> I got that from http://blog.madewithdrew.com/post/statically-linking-c-to-go/
[15:18] <mvo> zyga-ubuntu: indeed, you need something different from what I needed for snap-exec :)
[15:18] <zyga-ubuntu> mvo: fun
[15:19] <zyga-ubuntu> mvo: maybe rewrite snap-update-ns in C? ;-))
[15:19] <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
[15:19] <diddledan> the new kids would have you do it swift or rust
[15:19] <mvo> zyga-ubuntu: *cough*
[15:19] <zyga-ubuntu> ;-)
[15:19]  * zyga-ubuntu tries
[15:19] <ikey> then spoil it all and use glib :p
[15:19] <mvo> good luck
[15:19] <zyga-ubuntu> and also re-registers his spanish car in poland
[15:20] <zyga-ubuntu> ikey: we cannot use glib without doing a security review on it
[15:20] <zyga-ubuntu> ikey: setuid code is totally paranoid
[15:20] <ikey> oh i was being scathingly sarcastic
[15:20] <ikey> if you have any way in which to avoid using glib, do so.
[15:20]  * zyga-ubuntu works from the middle of a local gov office, changing plates
[15:20] <zyga-ubuntu> uff :)
[15:21] <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?
[15:22] <zyga-ubuntu> darn
[15:22] <zyga-ubuntu> my number plates end with RH
[15:22] <zyga-ubuntu> no ubu plates
[15:24]  * zyga-ubuntu is starving now
[15:24] <zyga-ubuntu> hmm
[15:24] <zyga-ubuntu> mvo: it built?
[15:25] <zyga-ubuntu> but not static :/
[15:28] <om26er> zyga-ubuntu: fyi: https://forum.snapcraft.io/t/need-an-interface-to-lock-the-screen/1972
[15:28] <zyga-ubuntu> om26er: +1
[15:29] <Chipaca> pedronis: any objections to having atomatt merge+rebase #3780?
[15:29] <mup> PR #3780: many: configure store from state, reconfigure store at runtime <Blocked> <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
[15:30] <Chipaca> or just rebase, dunno why i'm saying merge+rebase
[15:31] <Son_Goku> mvo, I don't see a release/2.28 branch?
[15:32] <Son_Goku> zyga-ubuntu, I'm considering backporting https://github.com/snapcore/snapd/pull/3260 to 2.27.5 for Fedora
[15:32] <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>
[15:32] <Son_Goku> what do you think?
[15:33] <zyga-ubuntu> Son_Goku: ooooh
[15:33] <zyga-ubuntu> Son_Goku: yes, sure
[15:33] <zyga-ubuntu> Son_Goku: I think the patch is small
[15:33] <Son_Goku> I'm sick of all desktop snaps not working correctly because of no xdg-open
[15:33] <zyga-ubuntu> Son_Goku: (well, isolated)
[15:34] <zyga-ubuntu> Son_Goku: I'm worried about selinux, we should iterate on some more rules
[15:34] <Son_Goku> I can probably guarantee we need to spend a cycle bringing the rules up to date with changes in 2.28
[15:35] <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>
[15:35] <Chipaca> 16 PRs and counting
[15:35] <zyga-ubuntu> Son_Goku: yes, I think so
[15:36] <zyga-ubuntu> Chipaca: isn't that a nice view? :)
[15:36] <zyga-ubuntu> Chipaca: we need to core some more ;-)
[15:36] <mvo> Son_Goku: yeah, still at ~rc1, I have not pushed anything yet, want to run a smoke test first
[15:36] <zyga-ubuntu> Chipaca: I will land two RPrs by tomorrow evening
[15:36]  * zyga-ubuntu waits in a car that now lacks insurance
[15:36] <mvo> zyga-ubuntu: your PR built?
[15:36] <zyga-ubuntu> mvo: yes but I get confusing outcomes
[15:36] <zyga-ubuntu> mvo: I hand-looked at the bianry but it was dynamic
[15:36] <zyga-ubuntu> mvo: but I may have looked at the wrong one
[15:37] <zyga-ubuntu> isn't it silly that an insured car is no longer insured as soon as you change the number plates?
[15:39] <Chipaca> zyga-ubuntu: that depends on jurisdiction :-)
[15:39] <zyga-ubuntu> Chipaca: indeed,
[15:40]  * Chipaca feels DOS'ed by zyga-ubuntu
[15:44] <zyga-ubuntu> huh?
[15:45] <Chipaca> zyga-ubuntu: I spent several seconds waiting,
[15:47] <zyga-ubuntu> haha
[15:47] <zyga-ubuntu> I wrote too many apparmor rules
[15:47] <zyga-ubuntu> , is like a semicolon to me now
[15:48] <Chipaca> /o\
[15:48] <Chipaca> zyga-ubuntu: reminds me of the auto-unbox operator in python
[15:50] <Chipaca> mvo: in snapd#3839, did you mean to drop the ? ?
[15:50] <mup> PR #3839: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3839>
[15:52] <pedronis> mvo: will you look into my last #3773 comments ? it's
[15:52] <mup> PR #3773: snap-repair: execute the repair and capture logs/status <Created by mvo5> <https://github.com/snapcore/snapd/pull/3773>
[15:57] <cachio> om26er, happy to see you are working around snappy
[16:00] <om26er> cachio: me too =)
[16:04] <mvo> pedronis: I will check that first thing in the morning, sorry, was busy with release prep
[16:04] <mvo> Chipaca: not sure, I have a look
[16:05] <mvo> cachio: fwiw, 2.28 is in the beta channel now
[16:05] <mvo> cachio: well, 2.28~rc1 :)
[16:06] <zyga-ubuntu> + snap install --edge core
[16:06] <zyga-ubuntu> core 30.58 MB / 83.09 MB   36.80% 112.28 KB/s 7m58ss
[16:06] <zyga-ubuntu> hmm
[16:06] <zyga-ubuntu> that is linode
[16:06] <zyga-ubuntu> is linode running on an expired 3G sim card?
[16:06] <zyga-ubuntu> that would explain things
[16:07] <ogra_> ISDN FTW!
[16:08] <cachio> mvo, great, I'll start its validation
[16:09]  * zyga-ubuntu eats supper in his car
[16:09] <mvo> cachio: thanks!
[16:24]  * zyga-ubuntu is looking at a night in a car
[16:25] <ogra_> caravaning ?
[16:26] <zyga-ubuntu> haha, on the front seat
[16:26] <zyga-ubuntu> we were supposed to buy the insurance over the phone
[16:26] <zyga-ubuntu> but ... ENOCALLS
[16:26] <zyga-ubuntu> and online insurance shows x2 the amount we just talked about
[16:26] <zyga-ubuntu> so ... waiting
[16:26] <zyga-ubuntu> and we'd rather not leave it here
[16:26] <zyga-ubuntu> because it's not insured, so once stolen, ...
[16:26] <ogra_> oh my
[16:26] <zyga-ubuntu> well
[16:27] <zyga-ubuntu> sucks to own a internal combustion ass dragging apparatus
[16:33] <pedronis> Chipaca: I answered there
[16:34] <Chipaca> pedronis: i saw
[16:34] <Chipaca> pedronis: i went
[16:34] <Chipaca> pedronis: wait i got the order wrong
[16:35] <pedronis> Chipaca: as long as your systemd doesn't think it's 2106, you should be fine :)
[16:38] <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 ?
[16:40] <Chipaca> ogra_: it's 2106, none of our ssl certs work any more
[16:40] <Chipaca> ogra_: sorry
[16:41] <ogra_> dang
[16:48] <zyga-ubuntu> pedronis: ensure min tls or something
[16:48] <zyga-ubuntu> pedronis: maybe it misfired
[16:52]  * zyga-ubuntu is tired and cold now
[16:53] <zyga-ubuntu> and it is raining again
[17:11] <Son_Goku> zyga-ubuntu: let's see how this goes... https://src.fedoraproject.org/rpms/snapd/c/4761d994bd7c8194e1180bfe995ac1be03fa8f0a?branch=master
[17:14] <zyga-ubuntu> Son_Goku: nice!
[17:14] <zyga-ubuntu> Son_Goku: is the godbus dep available as a package/
[17:14] <Son_Goku> I'm pleased to see that go mandates real tabs, though
[17:14] <Son_Goku> zyga-ubuntu, Yep
[17:14] <Son_Goku> https://koji.fedoraproject.org/koji/packageinfo?packageID=18330
[17:15]  * zyga-ubuntu is running out of juice
[17:15] <Son_Goku> have juice shipped to you :)
[17:15] <zyga-ubuntu> I'm still stuck in my car
[17:15] <zyga-ubuntu> that I cannot drive
[17:16] <zyga-ubuntu> that my wife cannot drive because I'm the owner and after moving property from spain only the owner can
[17:16] <zyga-ubuntu> and even if I could drive
[17:16] <zyga-ubuntu> we cannot go anywhere
[17:16] <zyga-ubuntu> because we cannot get insurance now
[17:16] <zyga-ubuntu> because everything sucks that's why
[17:16]  * zyga-ubuntu is getting grumpy
[17:16] <Son_Goku> haha
[17:18] <Son_Goku> aww
[17:18] <Son_Goku> the cake is a lie
[17:18] <Son_Goku> go mandates spaces for indentation :(
[17:19] <Son_Goku> wait, no, that's just the diff viewer being stupid
[17:19] <zyga-ubuntu> what? go doesn't care
[17:20] <zyga-ubuntu> what a f*** day
[17:22] <Son_Goku> it's not that bad of a day
[17:23] <Son_Goku> I have the day off today, which is why I'm able to do anything at all :)
[17:23] <Chipaca> Son_Goku: I'm sure he meant "fine"
[17:23]  * zyga-ubuntu hugs Son_Goku 
[17:23]  * zyga-ubuntu walks home
[17:24]  * Son_Goku is building new snapd 2.27.5 for F25, F26, and F27
[17:24] <Son_Goku> it build seems to be going well in rawhide, so why not
[17:26] <Son_Goku> zyga-ubuntu, can anyone get in touch with robert-ancell?
[17:27] <Son_Goku> his tarballs for snapd-glib 1.17 and 1.18 are missing: https://github.com/snapcore/snapd-glib/releases
[18:00] <niemeyer> Son_Goku: He participates in the forum
[18:00] <Son_Goku> does he announce snapd-glib releases there?
[18:01] <niemeyer> Son_Goku: Don't recall seeing announcements there, but that'd be quite nice actually
[18:01] <Son_Goku> I mean, I'll always know about new releases because release-monitoring.org is awesome
[18:16] <pedronis> zyga-suse: ensure min tls is not run anywhere yet
[18:17] <pedronis> this was my dev box
[18:17] <pedronis> seems something confused ntp for a sec and it all went to future/hell from there
[18:18] <pedronis> seems timesyncd doesn't recover from that on its own
[18:18] <pedronis> also because it seems indeed once you are some much in the future lots of protocols/things stop working
[18:25]  * zyga-suse mutters something about back to the future
[18:25] <zyga-suse> also having a car sucks
[18:25] <zyga-suse> also polari, the gnome IRC client, sucks
[18:26] <Son_Goku> welp
[18:33] <Sir_Gallantmon> gah, godbus wasn't submitted to f26 stable
[18:34] <Sir_Gallantmon> no wonder the build failed
[18:34]  * Sir_Gallantmon pushes it
[18:57] <om26er> use IRCCloud then.
[19:08] <Son_Goku> niemeyer, all of these links are broken: https://forum.snapcraft.io/t/the-roadmap/1973
[19:09] <niemeyer> Son_Goku: How did you get to the topic then?  This was supposed to be unlisted :)
[19:09] <Son_Goku> ...
[19:09] <Son_Goku> wut
[19:10] <Son_Goku> but... I can see it?
[19:10] <niemeyer> Son_Goku: Yeah, unlisted != private
[19:10] <niemeyer> Son_Goku: How did you get the first link?
[19:10] <Son_Goku> email
[19:10] <niemeyer> Weird
[19:10] <niemeyer> That's not very unlisted :P
[19:11] <Son_Goku> I'm not sure what to think about snapd growing support for managing services
[19:11] <niemeyer> Son_Goku: The links seem to work fine in the web UI
[19:11] <Son_Goku> when I clicked them it kept giving me 404s
[19:11] <Son_Goku> and 403s
[19:11] <Son_Goku> in this case, I got access denied
[19:11] <niemeyer> Son_Goku: What's the URL it goes to?
[19:12] <Son_Goku> https://forum.snapcraft.io/t/1908
[19:12] <Son_Goku> https://forum.snapcraft.io/t/262
[19:12] <Son_Goku> https://forum.snapcraft.io/t/1232
[19:12] <Son_Goku> and so on
[19:12] <niemeyer> Son_Goku: I can go to those URLs even without auth
[19:12] <Son_Goku> :S
[19:12] <Son_Goku> I don't know anymore
[19:13] <niemeyer> The fact you got the email is probably a bug.. but not a very serious one
[19:13] <niemeyer> Unlisted is just "don't list" really.. it's still public content
[19:14] <Son_Goku> ah
[19:14] <niemeyer> I'm finishing it still
[19:14] <Son_Goku> welp, anyway, on another note, I got 2.27.5 built for Fedora
[19:14] <niemeyer> Son_Goku: Can you please forward me the email?
[19:14] <niemeyer> I'll probably file a bug upstream
[19:15] <Son_Goku> email addr?
[19:15] <Son_Goku> and I backported userd because I'm sick of people complaining that desktop snaps can't do the right thing...
[19:15] <Son_Goku> and xdg-open is finally really dead
[19:15] <Son_Goku> err, snapd-xdg-open
[19:19] <Son_Goku> niemeyer: forwarded
[19:26] <niemeyer> Son_Goku: Thanks!
[19:26] <niemeyer> Son_Goku: You subscribe with the mailing list mode, right?
[19:26] <Son_Goku> yep
[19:26] <Son_Goku> I miss too much otherwise
[19:26] <niemeyer> Cool, that should be enough for them to track it down
[20:27] <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
[20:27] <exedore6> I’m either missing something, or barking up the wrong tree.
[20:27] <exedore6> Any thoughts?
[20:30] <Son_Goku> exedore6 yes, you can only use the stuff in the snap
[20:30] <Son_Goku> you can link some other things through defined interfaces, but that's pretty much it
[20:31] <exedore6> And you can’t tell the apache in a snap to bind to say, port 81. Right?
[20:31] <exedore6> Instead of whatever the packager used.
[20:31] <exedore6> Because of the security features.
[20:32] <Son_Goku> pretty much
[20:32] <Son_Goku> as far as I know, at least
[20:32] <exedore6> I can live with that. Makes more sense now. How about different interfaces?
[20:32] <Son_Goku> you're really not supposed to have snaps binding to the lower ports, but they do anyway
[20:33] <Son_Goku> everything is developer controlled
[20:33] <exedore6> That makes all the sense in the world. It doesn’t really seem the place for a service.
[20:33] <Son_Goku> after a snap is made, there's very little a user can do with it
[20:33] <Son_Goku> snaps are designed to favor the developer of the software in terms of configuration, control, and delivery
[20:34] <exedore6> So my impression that they’re killer for fat-applications, and fine for webapp demos, they’re the wrong tool for that job.
[20:34] <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
[20:34] <Son_Goku> but again, entirely up to the developer
[20:35] <Son_Goku> all snap user data is supposed to live there
[20:35] <exedore6> Thanks a bunch.
[20:36] <Son_Goku> exedore6, also note that snap confinement is only currently available on Ubuntu
[20:37] <Son_Goku> and Solus
[20:37] <Son_Goku> it should become available in openSUSE Tumbleweed after the 4.14 kernel release (hopefully)
[20:38] <Son_Goku> proper confinement support is TBD for RH/Fedora, Arch/Gentoo Hardened, as there's no SELinux backend for snapd yet
[21:57] <King_InuYasha> hey robert_ancell
[21:58] <robert_ancell> King_InuYasha, hello
[21:58] <King_InuYasha> did you get my email about the snapd-glib tarballs?
[21:59] <King_InuYasha> ugh
[21:59] <robert_ancell> King_InuYasha, yep, fixing it now
[21:59] <King_InuYasha> awesome
[21:59] <King_InuYasha> I'm guessing you're going to be releasing 1.19 as well
[22:00] <King_InuYasha> will that work okay with 2.27.5, or do I need to backport the license field stuff to snapd for it?
[22:02] <robert_ancell> King_InuYasha, the license stuff just defaults to NULL if the snapd doesn't support it.
[22:02] <King_InuYasha> ah, excellent
[22:03] <robert_ancell> But this still requires some store work before it will be populated, so not sure when that will be done.
[22:03] <King_InuYasha> it's painful enough to backport things in snapd
[22:03] <King_InuYasha> I just did it today for userd
[22:03] <robert_ancell> In general, I try to make snapd-glib work with any version of snapd
[22:03] <King_InuYasha> nice
[22:04] <robert_ancell> Next step, is seeing if I can get the translations to work
[22:04] <King_InuYasha> heh