[00:38] PR snapcraft#1494 closed: Parameter forwarding for java object was blocked when using wrapper script [02:32] PR snapcraft#1528 opened: recording: record the machine information collected by uname [04:05] PR snapcraft#1529 opened: recording: record the packages installed in the machine [04:44] 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] see you then [06:09] PR snapd#3837 closed: overlord/snapstate: rename HasCurrent to IsInstalled, remove superfluous/misleading check from All [06:34] PR snapd#3556 closed: client,daemon,snap,store: add license field [06:41] mvo: hello [06:43] hey zyga-ubuntu [06:47] mvo: today is the 1st day of school for us, how about your kids? [06:47] zyga-ubuntu: school started 2 weeks ago here [06:47] zyga-ubuntu: how was getting up ? [06:49] mvo: woah, two weeks? that's brutal :) [06:49] mvo: so no august holidays? [06:49] mvo: it was all right, with the exception of my son we all woke up at 6am [06:49] zyga-ubuntu: holidays started early here [06:50] zyga-ubuntu: nice! [06:50] mvo: we introduced new rules to make sure nothing flashly/briht/(tv/computer) is on past 21:00 [06:50] zyga-ubuntu: the only thing I hate is the getting-up early [06:50] zyga-ubuntu: that sounds reasonable [06:50] 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] mvo: and I'm looking forward to working at 6:30 soon [06:52] mvo: trivial comments from gustavo on https://github.com/snapcore/snapd/pull/3625 [06:52] PR #3625: many: end-to-end support for the bare base snap [06:54] zyga-ubuntu: yeah, working on them now and then I will merge [06:55] zyga-ubuntu: there are some easy ones in the queue that just need a second review [06:55] zyga-ubuntu: e.g. 3844 [06:59] mvo: I'll have a look, going bottom up [07:01] zyga-ubuntu: please leave some of the scary looking out, I have not branched 2.28 yet [07:01] zyga-ubuntu: but want to do in a little bit, so please not the debian/ dir changes [07:01] zyga-ubuntu: and also not 3727 (that needs a second review anyway) [07:05] mvo: noted [07:07] ok, one more and I'm going to pick them up [07:08] zyga-ubuntu: pick which one up? [07:11] mvo: my kids :) [07:11] mvo: I'm reading https://github.com/snapcore/snapd/pull/3777/files [07:11] PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) [07:14] ok, I'll read the rest later, going to school, ttyl [07:18] zyga-ubuntu: bye [07:18] pstolowski: good morning! [07:18] mvo, morning! [07:20] 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] mvo, indeed, i'll look at it shortly, thanks! [07:23] ta [07:27] PR snapd#3795 closed: daemon: let client decide whether to allow interactive auth via polkit === JoshStrobl|AFK is now known as JoshStrobl [07:55] g'morning, all [07:56] Good morning [07:58] 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] mimag1: I think the source of a python part can be a directory [08:00] e.g. source: . [08:00] I have that and in that directory I have the package and an setup.py [08:01] plugin: python and plugin-version: python3 [08:01] mimag1: and what doesn't work? [08:01] "Could not find a version that satisfies the requirement pytiip (from versions: )" [08:01] No matching distribution found for pytiip [08:02] mimag1: can you share your whole yaml so i can reproduce this? [08:03] 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] mvo: but, what do you think of that approach? [08:06] PR snapd#3842 closed: store: have an ad-hoc method on cfg to get its list of uris for tests [08:06] PR snapd#3844 closed: overlord/snapstate: SetRootDir from SetUpTest, not in just some tests [08:06] re, back from school, now peace and quiet for the rest of the day [08:06] parts: [08:06] pytiip: source: repos/pytiip plugin: python python-version: python3 [08:09] 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] mvo: say aw is an atomicwriter [08:11] mvo: and aw.Write() fails, for whatever reason [08:11] popey, same cpu and wlan device, might even work with the nanopi-air image [08:11] mvo: so now you need to close it and remove the file, without committing [08:12] mvo: if close is commit, that's harder [08:12] Chipaca: aha, yes, good point. will things work if you do "aw.Write(); aw.Commit(); aw.Write(); aw.Commit()"? [08:12] mvo: no, at least as written, Commit imples Close [08:13] mvo, Chipaca: maybe commit and rollback [08:13] to make it crystal clear what they are [08:13] zyga-ubuntu: what would rollback do? [08:13] i [08:14] the way i wrote it, the creator of the aw is the one that needs to handle cleanup on error [08:14] just like with 'plain' files [08:14] 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] mvo: hmm... good point. Atomize()? :-P [08:15] (still feeling bad about having a Fooer interface that doesn't have a Foo() method) [08:16] Chipaca: yeah, and the enhanced version is called Fusionize() [08:16] Unionize() [08:16] lol [08:18] What is required from a python directory to make the python plugin work? [08:18] Chipaca: I mean rollback as a rename of close [08:18] 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] zyga-ubuntu: but rollback to me would imply it cleans up the tempfile also [08:19] 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] something along the lines of Finalize would work for me [08:20] looking at synonyms now [08:21] Done() [08:21] RealllyHitTheDisk() [08:21] * zyga-ubuntu needs to read that PR [08:28] Enfeoff() \o/ [08:29] Achoo()? === chihchun is now known as chihchun_afk [08:36] mimag1: so [08:36] mimag1: this is kinda silly i fear [08:36] * Chipaca tries something else [08:41] what is silly? === chihchun_afk is now known as chihchun [08:52] mimag1: I'm afraid I'm stumped; you'll have to get help from an actual snapcrafter [08:52] it _should_ work, as far as i know, and in fact it seems to half work and then lose itself [08:53] @Chipaca exactly my experience [08:53] mimag1: No such command! [08:54] nothal: dance for me [08:54] exactly my experience [08:54] nothal: Which command is wrong? === JoshStrobl is now known as JoshStrobl|Work [08:58] mimag1: nothal is a bot, that can take commands explicitly starting them with @ [08:59] mimag1: as @ is not usually used to start messages in irc, it used to work [08:59] but then other chat systems happened, and nothal hasn't adapted [09:00] 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] that's https://forum.snapcraft.io/ or https://rocket.ubuntu.com/channel/snapcraft [09:02] Thank you Chipaca [09:15] 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] Can't really find something in the docs so far [09:17] pstolowski: do we have a forum post about the new install/remove hooks? anything I could link to? [09:18] mvo, not yet, but I'll create one soon [09:18] pstolowski: thank you [09:30] mzanetti, mvo, psstolowski: +1 on that forum post. I have written some configure hooks but I guess there is a better way [09:43] wow, we are at 17 open PRs [09:43] * zyga-ubuntu reviewed a repair PR, fist in a long time [09:43] lookin at more [09:44] Chipaca: one thing I wanted to share with you, not sure if you used it yet [09:44] Chipaca: you probably know about this already [09:45] zyga-ubuntu: spit it out already :-D [09:45] Chipaca: but please read the section on O_TMPFILE in open(2) [09:45] Chipaca: this allows you to create a file, write all data, set mode and ownership [09:45] Chipaca: and only make it show up, atomically [09:45] Chipaca: or die with the process [09:45] Chipaca: it's a very compelling API [09:46] Chipaca: I wanted to make sure you know about it, and with that note, I'm going to review the rest [09:46] I did not know about this [09:46] thank you [09:46] zyga-ubuntu: 3.11 is << our minimal kernel version, i take it? [09:46] my pleasure :) [09:46] ondra: ^? [09:47] 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] (i mean, the minimal kernel version our users are using, which is almost certainly < than the one we support) [09:47] Chipaca: though a perfect implementation would degrade gracefully [09:47] nice [09:47] i'll wait for ondra to speak up (or 301 me) [09:47] Chipaca: in general, it's a very good API to have for atomicity [09:48] 301? [09:48] Chipaca hey [09:48] zyga-ubuntu: "ask so-n-so" [09:49] Chipaca I think it was even 3.10 [09:49] ondra: as in, people using 3.10 with snappy? [09:49] ondra: do you know if it's tweaked to also have O_TMPFILE? [09:49] Chipaca I think there were some attempts, but using is probably too strong statement [09:49] zyga-ubuntu: grep -r O_TMPFILE /usr/share/go-1.6 and weep [09:49] ondra: :-) ok [09:52] zyga-ubuntu: I'd have to look into how this behaves for the wrong kernel and the wrong filesystem, to fallback properly [09:52] ESYS [09:52] AFAIR [09:52] but please check [09:55] zyga-ubuntu: the docs say EISDIR (kernel) or EOPNOTSUPP (filesystem) [09:56] ahh, sorry then, I must be wrong [10:00] PR snapd#3625 closed: many: end-to-end support for the bare base snap [10:06] zyga-ubuntu: how do you use O_TMPFILE to replace an existing file? [10:07] zyga-ubuntu: linkat doesn't let you replace files [10:08] Chipaca: you can still link it to .foo and then call move [10:11] hmmm [10:12] the cleanup story becomes a lot harder [10:12] hmm hmm [10:12] Chipaca: in which way? [10:12] zyga-ubuntu: "close it, and if it was created, remove it" [10:12] meaning we'd probably have to make something on the object itself [10:12] Chipaca: note that this was just a suggestion, if it makes anything harder then by all means, ignore it: ) [10:12] zyga-ubuntu: i like it, i'm just thinking it through [10:13] loudly and using you as the sock puppet [10:14] Chipaca: oh, one related note: https://betanews.com/2017/09/03/android-oreo-linux-kernel/ [10:14] haha, my pleasure :) [10:14] All SoCs productized in 2017 must launch with kernel 4.4 or newer. [10:14] zyga-ubuntu: your network is so lagged it's fun [10:14] so 4.4 is a good bet for many new pieces of hardware [10:14] * Ping reply from zyga-ubuntu: 1.631 second(s) [10:14] Chipaca: my network is actually brilliantly fast now [10:14] oh? [10:15] I saw 0.6 on my end [10:15] not sure where that much of a lag is coming from [10:15] zyga-ubuntu: i just pung jamie and got .3s [10:15] so it's not me :-) [10:16] jamie is 0.7 [10:16] * zyga-ubuntu pings pawel [10:16] yeah, consistently getting 1+ seconds (and i only noticed because of how delayed your answers were) [10:16] pawel is 0.6 [10:16] weirdish [10:16] anyway, I was never happier with any network before [10:16] zyga-ubuntu: good to know [10:16] highest bandwidth and mobility [10:17] * zyga-ubuntu stops bragging [10:17] zyga-ubuntu: and you get 1TB (or 1Tb?) [10:17] yes [10:17] a month [10:17] and it's not location-bound [10:17] I'm seeing 12-15MB/s to ubuntu archive [10:18] I haven't tried much more though :) [10:18] * zyga-ubuntu sees rain outside and feels like being in London === chihchun is now known as chihchun_afk [10:29] pedronis: you asked a question in 3642 - is that something that needs more work or are you happy with the reply? [10:31] mvo: one sec [10:31] 16 requests :) [10:31] 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] pedronis: why do I imagine half your house on fire [10:32] hopefully not, but there was a zero chance it could :/ [10:32] pedronis: probably https://www.youtube.com/watch?v=1EBfxjSFAxQ [10:32] a non-zero [10:33] pedronis: uh, good lucj [10:33] luck [10:35] * zyga-ubuntu sees red in travis :/ [10:35] pedronis: stay safe! [10:36]

[10:36] does anyone know what the timeout is? [10:36] it would be awesome if spread said that [10:40] zyga-ubuntu: and in the end I'm writing stuff that looks alarming like Rollback [10:42] Chipaca: does that mean I get two +1s or two -1s? [10:43] zyga-ubuntu: I don't know. [10:43] zyga-ubuntu: I'm calling it Cancel, anyway [10:43] Cancel is nice [10:43] oh [10:43] zyga-ubuntu: because mvo's point about calling Commit multiple times makes some sense [10:43] feels like context [10:43] (only some, because you can't commit multiple times in sql afaik) [10:44] zyga-ubuntu: only doing this refactor so it's easier to do the tmpfile later [10:47] grmbl [10:47] why dont i have a /dev/fb0 in my initrd on the pi [10:53] zyga-ubuntu, so any ideawhy the opengl interface fix is not in edge ? [10:53] i thought we do rebuilds of the edge deb for every commit ? [10:54] s/commit/merged PR/ [10:54] mvo, ^^ is that not the case ? [10:55] ogra_: yes, that should be the case, lets check the edge ppa [10:55] ogra_: when did the fix land? [10:55] mvo5 merged commit 6d8d625 into snapcore:master 4 days ago [10:55] says GH [10:56] apparently snapd FTBFS since the 31st [10:56] (well, on arm and i386) [10:58] zyga-ubuntu: I think kill-timeout is 20m , that's what in spread.yaml [10:58] mvo, if i read the log right (not sure i do) it fails in the github.com/snapcore/snapd/x11 test [10:59] ah, no, there are earlier ones [11:00] ogra_: hm, 4 days ago [11:00] uh [11:00] bad system call [11:00] https://launchpadlibrarian.net/335269966/buildlog_ubuntu-xenial-armhf.snapd_2.27.5+git354.834024b~ubuntu16.04.1_BUILDING.txt.gz [11:00] ogra_: yeah, but that is already 4 days old [11:01] yep [11:01] ogra_: and this should be fixed in master [11:01] ogra_: looks like our automatic merging via snap-cron is not working [11:01] did fgimenez take all his PPA scripts with him ? [11:01] ogra_: I have a look, but maybe I need cachio [11:01] ogra_: this is actually possible :( [11:01] (might be the build was triggered under his user) [11:01] ogra_: I mean, its possible that the upload creds got removed with his account [11:02] yeah [11:03] under "uploader" there is "no signer" ... https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages [11:03] (never seen that) [11:03] ogra_: no, no idea, maybe due to imminent release [11:03] ogra_: I really really wish we had a setup where edge == master in all cases [11:03] zyga-ubuntu, well, see above we lost the daily snapd deb [11:03] ogra_: and releases would build from a separate PPA and separate recipe of core [11:03] zyga-ubuntu, it is ! [11:03] ogra_: I retriggered the job, that should give me some data, if that fails I need to talk to cachio [11:04] ogra_: but the date (2017-08-31) is suspecious, that is the date that federico left [11:04] zyga-ubuntu, only if mvo does a relese build manually it isnt usually ... but thats really short snapshot times [11:04] 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] pedronis: thank you! [11:04] ogra_: again, I wish it was never [11:04] zyga-ubuntu, we onyl ever have to delete the deb that was manually uploaded to the image ppa [11:05] so the manual step changes it and the manual step switches it back ... for full release control [11:05] well, we don't need that [11:05] we need control over beta, candidate and stable [11:05] zyga-ubuntu, though if the shema i develoed ages ago with federico would have been implemented you wouldnt have that setp ever :) [11:05] edge should be on autopilot all the time [11:05] I'm sure we can improve things :) [11:05] we have a roperly worked out build plan [11:06] just never implemented [11:06] *properly [11:06] it is exactly focused to fix your complaint ... :) [11:06] *on fixing [11:08] mvo, i'll try to trigger a build of https://code.launchpad.net/~snappy-dev/+recipe/snapd-vendor-daily ... lets see [11:08] (speak up if i shouldnt please) [11:10] * ogra_ clicks the button [11:18] ogra_: the vendor sync thing ran some minutes ago, I will double check [11:20] ogra_: ok, powerpc and s390x fail but the rest is building [11:20] well, arm64 isnt done yet :) [11:20] but yeah, looks better already [11:22] mvo, the upload log looks weird as well though ... might be we need to manually delete the old package [11:22] https://launchpadlibrarian.net/335757858/upload_1442402_log.txt [11:25] ogra_: thats ok [11:25] ok [11:25] ogra_: I think what happend is that the sync also triggered an upload [11:25] ah [11:25] ogra_: and then you triggered one manually and the changelog version is the same [11:25] ogra_: which is fine because the content is the same :) [11:25] indeed [11:26] 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] mvo, will do [11:30] edge build running [11:38] hey, should tha RPI3 image automatically resize the writable partition to fill the SD card on first boot? [11:39] greyback, yes [11:39] ogra_: didn't work for me just now (today's daily edge). I'll log bug [11:40] greyback, there iss a log kept in /run/initramfs (note thats a tmpdir though ... so it is gone if you reboot) [11:40] ogra_: ack. I'll reflash and grab that for you [11:41] greyback, als include df -h /writable please (and syslog and dmesg output) [11:41] *also [11:41] *nod* [11:41] 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] oh interesting. I didn't get a cheap one at least [11:43] http://elinux.org/RPi_SD_cards [11:43] not sure how valid that still is though ... originally created 2012 [11:47] get a HDD [11:47] screw SD [11:48] heh [11:48] * zyga-ubuntu waits for first boot-from-CD rpi hack [11:48] are USB-CD drives still being sold ? [11:49] https://pastebin.ubuntu.com/25464779/ - resize doesn't appear to error out, but no change [11:50] ogra_: yesd [11:50] ogra_: and arguably, still useful :) [11:50] pfft [11:51] greyback, hmm, looks all fine (apart from the size) [11:51] greyback, how big is that SD ? [11:51] ogra_: 32GB [11:51] 4cm by 2cm [11:51] * zyga-ubuntu hides [11:51] :D [11:52] zyga-ubuntu, then he would need to fold it to fit into the slot :P [11:52] that might indeed be the prob then :P [11:53] 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] ogra_: I typically unmount before flashing. But let me try once more, to be totally certain. [11:55] kde, why did you remount something I explicitly unmounted [11:55] heh [11:59] ogra_: ok, that did it. Apologies for the noise [12:01] * Chipaca ~> run and lunch [12:03] greyback, np [12:04] jdstrand: hey, around? [12:06] 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] ogra_: noted. Will try [12:06] ogra_: fixing the udev script did the job too [12:07] indeed ... [12:07] the new core should generate it propely from the start though [12:08] jdstrand: so I'll just leave you a message [12:08] jdstrand: I'm looking ad child profiles but I get compile errors [12:09] jdstrand: the apparmor reference has this worring statement: [12:09] jdstrand: 'x' '->' ',' (not yet supported) [12:09] jdstrand: it does have: ('safe' | 'unsafe') 'x' [[' ->' ] ['+' ]] ',' [12:09] 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] ahhh [12:15] darn :) [12:16] jdstrand: so just for information, I was stuck on the fact that the child profile cannot have dashes in it [12:22] zyga-ubuntu: jdstrand is off today afaik, labor day in the us [12:33] mvo: ah I didn't know [12:33] anyway I'm progressing, I just launched a run of tests/main/ with child profile on snap-update-ns [12:33] which gives me enough time to make something to drink :) [12:35] hmm [12:35] mvo: after base snap patches landed in master my tests started to fail [12:39] zyga-ubuntu: what tests exactly? [12:39] https://travis-ci.org/snapcore/snapd/builds/271651836?utm_source=github_status&utm_medium=notification base-snaps spread test [12:40] mvo: I'm runnin a sequence with -debug so I'll get to that soon [12:40] just curious what happened there [12:41] oh man, it's raining crazy [12:43] PR snapd#3846 opened: debian: add missing flags when building static snap-exec [12:43] 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] zyga-ubuntu: heh [12:44] mvo: it passed just a moment ago, before the merge [12:44] mvo: but that's fine, I'll get to the bottom of this [12:44] mvo: but I wanted to mention this in case it affects 2.28 [12:45] zyga-ubuntu: yeah, its a new test [12:47] dang ! [12:48] no framebuffer device in pi initrd's without a gazillion of drm/kms modules :/ [12:49] zyga-ubuntu: hm, I guess the problem is that snap-update-ns needs to be static linked [12:49] zyga-ubuntu: same problem as snap-exec, if you run it *inside* the bare base there is no libc [12:50] mvo: that makes sense [12:51] mvo: thanks, I'll make the modifications [12:52] ah [12:52] darn, meeting is coming up and I'm parched [13:03] ppisati, do you think building vc4 intob the kernel would do any harm on rpi ? [13:03]