[00:00] kyrofa: of course they do :) [00:00] nacc, they're essentially dynamically-created channels. Perfect for creating a snap of "this" pull request [00:01] nacc, they're ephemeral, though, and expire after a month [00:01] kyrofa: ah i see [00:01] (unless published to again) [00:01] kyrofa: interesting, will read up on it tmrw [00:01] kyrofa: snaps feel like such a moving target sometimes :) [00:01] nacc, yeah I feel ya [00:02] oooh, i think i know how to make the keygen tests quicker [00:02] Chipaca, what the heck man, were you asleep and awoke with a genius idea? [00:02] … don't we all? [00:02] Yes :P [00:04] kyrofa: also, manchester explosion has me woke [00:04] * kyrofa googles manchester explosion [00:05] Dang [00:06] Chipaca, you're not close, I hope [00:06] nor is any of my family as far as i know [00:07] Good [00:12] need to check with samuele wrt sanity, but this makes the key generation step of the tests ~20× faster [01:55] PR snapd#3383 opened: Fix spread flaky tests linode [02:50] PR snapcraft#1327 opened: tests: small updates for manual kernel tests === chihchun_afk is now known as chihchun === pbek_ is now known as pbek [04:58] I had a question regarding sanitisation of snap interfaces: https://forum.snapcraft.io/t/sanitisation-of-snaps-requested-interfaces/739 [05:43] PR snapd#3382 closed: daemon,overlord/auth: store from model assertion wins [05:49] PR snapd#3379 closed: cmd/snap,tests: show the snap id if available in snap info [06:16] PR snapd#3226 closed: snap-repair: add `snap-repair run` [06:37] good morning [06:38] mvo: hey [06:38] mvo: just to give you some more context for my message yesterday [06:38] mvo: gustavo reviewed the way we convey meta-data for interfaces and wanted to make some changes [06:38] mvo: we had a quick brainstorm session and the bottom line is that the current rest API has to be reverted to what it was before meta-data layer was merged [06:39] mvo: and the meta-data must move to a new endpoint "interface" (vs "interfaces" currently) [06:39] mvo: I will work on this and the CE blocker today [06:39] mvo: when do you plan to release? [07:11] zyga: morning! [07:14] morphis: good morning [07:15] morning [07:21] Hello, I'm not following snap development closely. I'm wondering on why the OS snap ubuntu-core was renamed to core? [07:30] mvo, zyga, pedronis, Pharaoh_Atem, niemeyer: can you guys look into https://github.com/snapcore/snapd/pull/3222 again today? Would like to get that merged soon [07:30] PR snapd#3222: many: fix test cases to work with different DistroLibExecDir [07:32] hello palasso! this was mainly to avoid confusion about cross-distro support [07:32] ty pstolowski for the answer [07:50] can it be that Linode/spread is pretty unreliable these days? Trying to get a green light on a PR which touches nothing which is tested anywhere but running into a lot of timeout issues: https://github.com/snapcore/snapd/pull/3371 [07:50] PR snapd#3371: packaging: import packaging bits for opensuse [08:04] morphis: yeah, looks like it, maybe worth poking the store people about: "DEBUG: The retry loop for https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2 finished after 4 retries, elapsed time=40.008154662s, status: Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: net/http: request canceled while waiting for connection (Client [08:04] .Timeout exceeded while awaiting headers)" [08:05] morphis: 40s and 4 retries is a pretty long wait [08:05] hi morphis in that build you had a lot of connectivity problems, seems that between linode instances and the store, at least two "dial tcp 162.213.33.92:443: getsockopt: no route to host" (162.213.33.92 is public.apps.ubuntu.com), "dial tcp 162.213.33.92:443: i/o timeout", timeouts awaiting for headers from assertions.ubuntu.com, the tests/main/completion error seems to be related to connectivity too, maybe the store was down or all the instances [08:05] involved (more than one had errors) lose connection [08:11] yeah [08:11] is pretty nasty and it looks like I am getting similar problems with all my PRs [08:12] mvo: what is a good place to poke on the store people? [08:14] kyrofa: not yet; at the time when we were adding publish-to-track support to LP, branches were only defined for stable, and automatic jobs shouldn't be publishing directly to stable. Some of the assumptions here may have changed since though [08:15] re [08:17] geez, firefox ate 3GB of ram on 4 tabs open [08:36] my 2.27 PRs need reviews [08:39] pedronis: hiya [08:46] PR snapd#3384 opened: tests: use pollinate to seed the rng [08:46] hi Chipaca, could you please take a look at ^^^? never use pollinate before, seems to be working fine with a plain call [08:51] fgimenez: yup [08:52] fgimenez: i also want to check with samuele about what happens if we use a gpg in testing that clamps keys to 1024 bits [08:55] Chipaca: great thanks! [08:59] Chipaca: where? we check that the keys we get have the expected length [08:59] pedronis: we do? where? [09:00] snap create-key seemed to be happy with them [09:00] pedronis: good morning! [09:01] Chipaca: well, when you try to sign with it, it won't (maybe that test doesn't use the key it makes, but as a general strategy across all tests doesn't work) [09:02] Chipaca: here, https://github.com/snapcore/snapd/blob/master/asserts/crypto.go#L367 [09:04] * Chipaca pokes at his internet [09:13] pedronis: sadface [09:13] pedronis: maybe i should override gpg and then un-override it when tests break :-) [09:14] Chipaca: override it with what anyway ? [09:16] pedronis: sed and more gpg :-) [09:16] Chipaca: anyway we do have a snap-sign test [09:16] zyga: step 1, CI passes on https://github.com/snapcore/snapd/pull/3365 :-) [09:16] PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup [09:16] pedronis: yeah, that's the one i was poking around in last night [09:16] Chipaca: which funnily I never seen fail [09:17] pedronis: oh, i did [09:17] pedronis: I'd point you at https://s3.amazonaws.com/archive.travis-ci.org/jobs/234990914/log.txt?X-Amz-Expires=30&X-Amz-Date=20170523T012508Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170523/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=2f9a55bec2d1b61a8c23f3b46d7c955155fc8e2f719cb66e788743bc7181c36a but travis has already been "helpful" [09:17] Chipaca: anyway what you could do is merge create-key into snap-sign [09:17] so you need less overall entropy [09:17] pedronis: the entropy doesn't seem to be the problem afaict [09:17] Chipaca: what is the problem then? [09:18] pedronis: at least, every time i've looked we've had ~3k of entropy [09:18] doesn't compute [09:18] why would create-key take forever if not that [09:18] pedronis: I'm guessing here but we might be getting penalized [09:18] for heavy cpu use [09:19] anyway my point stand [09:19] yep [09:19] we would use less CPU if we create less keys :) [09:19] don't get me wrong, we might also be running out of entropy [09:19] and i think we need to add that to the debug output [09:20] so we can see [09:20] (also to the regular output! but that's going to be harder) [09:20] Chipaca: so mergeing snap-sign create-key and the key completion test into one [09:22] [ 12.818573] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock [09:22] [ 12.829425] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock [09:22] hmpf [09:22] i wonder if we cant quieten f2fs on a kernel level [09:23] augh [09:23] who writes that code :-( [09:23] who writes "%dth" and thinks that's a good idea [09:23] someone who doesnt know about english numbering ? [09:24] but then there's like 5 other people that looked at that code and thought "fine whatever" and let it pass :-/ [09:24] yeah [09:24] anyway [09:24] always too easy to criticise other projects [09:24] * Chipaca shuts up [09:25] well, i'm sure whatever code there is probes all possible filesystems ... but only f2fs prints that stuff [09:26] apw, do you think we could quieten such f2fs messages ? [09:27] ogra_, why do you care about two lines in your dmesg ? [09:27] apw: users (actually, device developers) see them and freak out [09:27] ogra_, and indeed what is triggering them from userspace [09:27] apw, dunno, i'm german :P [09:27] Chipaca, i think device developers need to develop thicker skin :) [09:28] apw, snapd checks all attached non rootfs devices for possible snap assertions on boot ... so it mounts them once ... [09:28] * apw sticks several fingers in each of his ears ... [09:29] apw, we used to include ramdisks in that... when we did that i have about 30 of these messages ... now i get them for the one atttached usb device only ... but still only f2fs (which we never used) prints that stuff [09:29] * Chipaca wonders how apw types with several fingers in several ears [09:29] s/i have/i had/ [09:29] Chipaca, with my feet, the only way [09:29] pedal keyboards ftw [09:29] ogra_, surely we do not try all the possible filesystem types though [09:29] ogra_, that way lies _vast_ attack surface [09:30] apw, well, we just call mount i guess ... the rest is kernel [09:30] (or internal logic of mount) [09:30] ogra_, they kernel does not guess you filesystem type, that would be mount [09:30] ogra_: do we explicitly load f2fs? === pachulo_ is now known as pachulo [09:30] Chipaca, nope [09:31] ogra_, so what is on that stick which triggers that error [09:31] Chipaca, i think it is compiled in [09:31] ogra_: at least here it's a module [09:31] apw, a vfat fs [09:31] dunno on other arches etc [09:31] ogra_, ie what does blkid say on it [09:31] Chnot in xenial [09:32] Chipaca, ^ [09:32] as one would expect mount to ask what it is and then mount that specific type [09:32] ogra_: chtotally in xenial [09:32] ogra@pi3:~$ lsmod|grep f2fs [09:32] ogra@pi3:~$ grep f2fs /proc/filesystems [09:32] f2fs [09:32] ogra@pi3:~$ [09:33] ogra@pi3:~$ sudo blkid /dev/sda1 [09:33] ogra@pi3:~$ [09:33] bah [09:33] /dev/sda1: UUID="72AD-5403" TYPE="vfat" PARTUUID="7524a7a6-01" [09:33] silly IRC [09:33] ogra_: try: modinfo f2fs [09:33] heh, so why the heck is f2fs being used against it [09:33] apw, dunno, why was it being used on all the ramdisks before [09:34] ogra_, can you manually try mounting it with mount /dev/sda2 /mnt [09:34] this isnt new or anything ... [09:34] and with mount -t vfat /dev/sda2 /mnt [09:34] sort of thing [09:34] and see if the latter is quieter [09:34] * apw would suggest we should be using blkid and only attempting to mount if it is one of a very very limited set of formats, ones we are willing to work hard to keep security good on [09:35] else i could format it as some utterly nasty format and you will mount it, w [09:35] which is just asking to be attacked [09:35] i would vote for one format if i was involved, perhaps vfat [09:36] apw, neirther mount nr mount -t vfat print anything [09:36] ogra_, nothing in dmesg you mean ? [09:36] right [09:36] then you have a new mystery, who the heck is triggering that [09:36] are you using some magical go helper [09:37] pedronis, mvo, ^^^ does snapd rotate over filesystems when mounting a device to lok for assertions ? [09:37] *look [09:39] no clue, that's really for mvo [09:42] re [09:42] morphis: that's great :) [09:42] I need to catch up with PRs but first I need to prepare two important things for 2.27 for mvo [09:43] looks like this is the mount code https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_auto_import.go [09:43] zyga: do that [09:43] cmd := exec.Command("mount", "-o", "ro", "--make-private", deviceName, tmpMountTarget) [09:43] nothing fancy regarding filesystems [09:47] hmm hmm [09:47] those are two distinct mount syscalls AFAIK [09:49] because of the --make-private ?? [09:49] yes [09:49] first you do mount -o ro deviceName tmpMountTarget [09:49] then mount --make-private [09:49] it's not atomic [09:49] (mount-the-command does that internally) [09:50] mount(8) does not read fstab(5) when a --make-* operation is requested. All necessary information has to be specified on the command [09:50] line. [09:50] hmm [09:50] how do you un-duplicate a bug? [09:50] Chipaca, iirc somewhere in the target bug [09:50] ah [09:55] ogra_: I'm not sure what rotate over filesystems means, but it does look at block devices for assertions, yes [09:56] apw: aha, just finished reading backlog - sure, we can make this smarter to only mount ext{2,3,4} and vfat or maybe even only vfat [09:58] mvo: we may even do more, register a GUID [09:58] mvo: that is unique to snapd [09:58] PR snapd#3385 opened: cmd: add stub new snap-repair command and add timer [09:58] mvo: (not partition ID, but partition *type* ID) [09:59] mvo: then you can make a stick, with any filesystem, and snapd will recognize it [09:59] zyga, you don't want it to support "any" anything, if any device will mount and consume it on b [10:00] zyga, boot. that is just asking for people to exploit every possible filesystme bug [10:00] (you can still add extra requirements, but the guid makes it distinct even before we mount it) [10:00] zyga: maybe, but OTOH anything that makes it harder for people to use this feature is not ideal IMO, I like the simplicify of the current: grab random-usb-stick, copy file, done [10:00] apw: I agree [10:00] mvo: it all depends on tooling [10:00] easy is the antithisys of secure [10:01] zyga: well, yes, but its still at least one extra step: find the right tool for your $OS, download, run [10:01] mvo: more like "make disk image" website [10:01] apw: you think even limiting to vfat would be an issue? [10:01] mvo: but I agree [10:02] mvo, i would cirtainly recommend limititing it to something vfat might be that thing [10:02] apw, zyga: once I finished with my current branch I will do that then [10:02] mvo, though i would ask the security team for a recomendation if anything [10:02] apw: good point [10:09] PR snapd#3386 opened: interfaces, osutil: move flock code from interfaces/mount to osutil [10:12] PR snapd#3387 opened: cmd: auto import assertions only from vfat file systems [10:13] mvo: thank you for moving the flock code [10:15] zyga: thanks for writing it :) [10:17] mvo: what is the `wrong prefix` test from? [10:18] ah [10:18] I misread [10:18] that's just a comment [10:27] mvo, s/rotate/loop/ :) [10:27] apw, still though, why do the fs drivers print such stuff at all ... this is similar to the ext2/3 messages you get when mounting an ext4 fs, that also spills a lot scary messages [10:28] i.e. [10:28] [ 6.720679] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities [10:28] [ 6.729695] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities [10:28] [ 6.755923] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: errors=remount-ro [10:28] guys, i've a longer power outage today. i'm using my cellphone as a hotspot, but going for a lunch now and will be offline for ~1h [10:28] ogra_, so that you can diagnose why a mount fails, as all you get in user space is EINVAL [10:29] hmm [10:29] they are not scarey they are informative and useful if a mount you intended to make fails [10:29] they are scary for someone not understanding them [10:29] someone not understanding them is unlikely to be able to find them [10:30] * ogra_ had enough bugs from users that got confused by these messages over the years [10:30] that is why they are not on the screen, but in a hidden kernel buffer [10:30] yes users will always find somethign to be confused about, but in this context it is unlikely a user can even see this buffer [10:31] dmesg shows it prominently as does syslog and the kern.log file [10:31] so if an illiterate user has a prob he looks at it and reacts with "OMG filesystem errors" ... [10:31] few illiterate users know about any of those logs, or how to find them [10:32] well [10:32] and a semi-literate user will always be scared by everything [10:32] and if you don't record them, their literate friend they go and ask [10:32] will have literally nothing to work with [10:32] heh, k [10:32] computer equipement should have "no user servicable parts" on the front :) [10:33] lol [10:33] we log a lot more of that kind of thing than necessary because we are lazy in usersapce and [10:33] try things because we know the kernel will fail to do things which are silly [10:33] instead of only asking it to do things we want to do [10:34] * apw goes back to punching docker repeatedly wishing it _would_ log something useful [10:37] apw: punch harder? [10:37] if only i could punch it hard enough [10:38] maybe a hydraulic punch [10:45] PR snapcraft#1328 opened: qmake plugin: set default qt version [10:52] mvo: made a comment about snap-reapir branch, my explanation yesterday might have been confused, I still owe to update the forum entry [10:52] s/confused/confusing/ [10:54] pedronis: I requested changes on one of your PRs, so it all evens out [10:54] Chipaca: seems we have not tests for snap info directory fwiw [10:54] pedronis: there are [10:54] pedronis: just not with --verbose [10:55] so we have no ---verbose tests? [10:56] certainly none for ---verbose :-p and only a rather bare local check for --verbose [10:56] wait [10:56] taht might be yours [10:56] :-) [10:56] so, no, no tests for --verbose [10:56] Chipaca: I added it [10:57] pedronis: yeah [10:57] pedronis: any reason not to also show the sha3 for remote snaps in info? [10:58] Chipaca: we don't have that info around [10:58] ah remote ones [10:58] pedronis: it's in DownloadInfo [10:58] but not locals? [10:58] pedronis: ¯\_(ツ)_/¯ [10:59] because that needs thinking, if we want local too [10:59] it's strange that we don't store it in state [10:59] i guess it's somewhere in the asserts db? [10:59] it's in the assert db [10:59] thinking is hard [10:59] let's have lunch [11:00] pedronis: to be clear, i'm not saying this is in any way a blocker to the pr you have up [11:00] but every time i look at snap info i want to make it better :) [11:00] and then i remember making it better starts by looking at goyaml [11:01] Chipaca: anyway that's not a snap info problem, we need to think how to put the ash back into api.go [11:01] then info is easy [11:01] yup [11:01] there's remote, local unasserted, and local asserted [11:02] to consider [11:11] <_28Kb> why there's no php7 server snap? [11:14] _28Kb: what's a php7 server? [11:15] <_28Kb> like one in XAMPP [11:17] _28Kb: I don't think there's a reason [11:18] PR snapcraft#1329 opened: tour: use https for source urls [11:19] mvo: have you seen the travis error on snapd#3374? [11:19] PR snapd#3374: partition: add directory sync to the save uboot.env file code [11:19] <_28Kb> i need apache, php and mysql for my ubuntu core.. [11:20] mvo: (hint: it goes “can't load package: package github.com/mvo5/uboot-go/uenv: [...]”) [11:20] <_28Kb> i got only this nextcloud option offered [11:24] _28Kb: out of curiosity, why do you need a snap with these things? [11:24] <_28Kb> i got snappy core, so i need snaps i guess [11:25] _28Kb: _for what_? [11:25] _28Kb: that is, you don't need a server, nobody needs a server. Servers are for building services with. What service are you building? [11:26] <_28Kb> service which i could access from outside the box [11:26] _28Kb: and this is for a single box, your box, not for building a bunch of boxes that use this? [11:26] <_28Kb> through websocket for example [11:27] <_28Kb> i can't build one.. bunch is for distant future :) [11:28] PR snapd#3377 closed: asserts: simplify and adjust repair assertion definition [11:28] Chipaca, pedronis, zyga, mvo is any of you working on retry for deltas? if not, I'll do it today [11:29] _28Kb: it should be fairly straightforward to build a snap like that; nobody's done it because they haven't felt the need i guess? all the needed bits are there [11:29] pstolowski: retry in which sense? [11:29] but no [11:29] <_28Kb> ok, i see [11:31] pstolowski: i can confirm that I am not working on retry for deltas [11:32] in fact, I'm going to start working on lunch. [11:33] pedronis, ah, nvm... I thought we don't retry deltas after a quick look yesterday when we failed in the tests on travis, but looking again now and we actually do retry [12:05] PR snapd#3380 closed: cmd/snap,tests: show the sha3-384 of the snap for snap info --verbose SNAP-FILE [12:07] Chipaca: about info and sha3-384, proably leaving it out for unasserted local snaps would be ok or desired, so that would make it relatively doable [12:12] pedronis: well, snap info _could_ cheat and go look at the .snap in that case :-) [12:13] Chipaca: yes, it could but not as I said it could be argued that it doesn't make sense [12:13] s/but not/but/ [12:14] PR snapd#3388 opened: osutil: add non-blocking flock [12:16] PR snapd#3384 closed: tests: use pollinate to seed the rng [12:17] PR snapd#3378 closed: tests: fixes for executions using the staging store [12:39] mvo, hmm, your uboot change failed all tests ... something still looks for github.com/mvo5/uboot-go/uenv somewhere [12:39] ogra_: checking [12:53] PR snapd#3389 opened: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediatey refresh try [12:55] mvo: small PR of something I mentioned/we discussed ^ (also forum https://forum.snapcraft.io/t/refresh-schedule-via-core-config/434/9 ) [12:55] zyga: any progress on the work for seccomp constants resolving (the things we talked about yesterday) btw? [12:56] PR core#47 closed: keep version Makefile in sync with version-script [12:57] pedronis: very nice, thanks a lot [13:03] niemeyer: can you snapshot spread-61 as opensuse-42.2-64 when you have a minute? :-) [13:13] Is there anything apart from the "camera" plug I need to request for camera access? I'm currently running a Qt app on a computer without a camera and get the following error: [13:13] defaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.camera" [13:35] fgimenez: how much were you giggling while adding "pollinate" [13:36] * Chipaca just realised it might be funny in Spain [13:39] Chipaca: :D yes something you wouldn't hear from your grandmother [13:41] niemeyer: this is the PR I mentioned: https://github.com/snapcore/snapd/pull/3375 (also I pointed to it from aliases topic) [13:41] PR snapd#3375: snapstate,many: implement snap install --unaliased [13:42] pedronis: Thanks for the pointer [13:42] one more review wanted for snapd#3342 please [13:42] PR snapd#3342: many: refactor in preparation for 'snap start' [13:42] Chipaca: Will look into it too [13:43] niemeyer: taw [13:53] It's sad we're still blocked from using our neat state patching mechanism... [13:55] It'd be nice to be able to drag comments to different lines before the review has been delivered [13:58] niemeyer: as opposed to cut, delete, recomment? [13:58] Chipaca: Yeah [13:58] (like a caveman) [13:58] Exactly :) [13:58] niemeyer: drop wossisname a tweet [14:00] Chipaca: Who's that? [14:00] niemeyer: back when pyconar and pyconbr worked together one of the guests we brought was this github guy [14:01] (i don't even know if he's still at github :-) ) [14:01] Chipaca: The account on Twitter seems dead [14:02] ah well [14:04] PR snapd#3389 closed: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediately refresh try [14:07] mvo: thanks for merging ^ it also cuts down snapstate tests to <1s (go test displayed time) here [14:07] Chipaca: Reviewed [14:07] pedronis: Too [14:07] niemeyer: thanks, saw that, trying to add the tests John asked for [14:07]