[02:53] PR snapcraft#1399 closed: ruby plugin: new plugin [02:53] PR snapcraft#1544 opened: plugins: add the ruby plugin [05:35] good morning [07:03] mvo: hello [07:13] PR snapd#3888 closed: osutil: adjust StreamCommand tests for golang 1.9 [07:15] hey zyga-ubuntu - good morning [07:17] mvo: hey, I managed to solve my zesty problem. I added some details to https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034 [07:17] Bug #1716034: Network manager stops managing Ethernet links after upgrade [07:17] mvo: I'm curious if you have the file: /etc/NetworkManager/conf.d/10-globally-managed-devices.conf [07:18] zyga-ubuntu: not on my laptop [07:18] zyga-ubuntu: but on my workstation [07:19] PR snapd#3895 opened: osutil: adjust StreamCommand tests for golang 1.9 (2.28) [07:23] mvo: interesting, I bet you have non-empty netplan config somewhere [07:27] zyga-ubuntu: possible, but that file is empty on my workstation [07:32] zyga-ubuntu: a second look at 3865 would be great, iirc this was something you suggested :) [07:34] * zyga-ubuntu looks [07:35] PR snapd#3859 closed: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master [07:36] hm, has anybody seen this: [07:36] - Setup snap "se-test" (unset) security profiles (cannot setup seccomp for snap "se-test": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root")) [07:36] ? [07:37] PR snapd#3896 opened: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master (2.28) [07:38] abeato: can you tell me more about this please? [07:38] abeato: the output of `snap version` and `snap list --all` would be great (pastebin) [07:39] mvo, was using latest from master [07:39] abeato: this looks like snap-seccomp and snapd got out of sync somehow but I wonder how that is possible nowdays [07:39] mvo, quite weird output: http://paste.ubuntu.com/25513197/ [07:41] abeato: and `snap version` ? [07:41] abeato: ohhh [07:41] master [07:41] abeato: are you running snapd from master in your local tree? [07:42] yeah [07:42] abeato: aha, I think that is the problem, you will need to build snapcore/snapd/cmd/snap-seccomp and copy that to /usr/lib/snapd/ [07:42] abeato: iirc there is a "make hack" command [07:42] mvo, oh, I see, I have to update that [07:43] mvo, ok, will try, thanks [07:43] abeato: yeah, easiest might be: "cd cmd; make hack" [07:43] abeato: there is no "make unhack" but "apt install --reinstall snapd" will take care of this [07:44] core system, but no worries, will just backup old seccomp [07:45] abeato: ok, good luck and let me know if I can help in any other way [07:45] sure, thanks! [07:53] mvo: done [07:57] PR snapd#3865 closed: many: provide systemd.MockSystemctl() helper [07:58] zyga-ubuntu: \o/ thank you [07:59] zyga-ubuntu: 3892 is an easy win now that 3865 is merged [08:00] ok [08:01] mvo: done [08:01] zyga-ubuntu: ta! [08:02] mvo: I was thinking if any tests would need a systemd.Mock() that would call the two and install NOP functions === JoshStrobl is now known as JoshStrobl|zzz [08:02] mvo: that was my initial idea but now I see that the fine-grained mockers are useful as well [08:02] mvo: thank you for doing this work! [08:26] * zyga-ubuntu -> school again [08:26] kissiel: hey :) [08:26] zyga-ubuntu: yo [08:30] PR snapd#3897 opened: systemd: do not run auto-import and repair services on classic [09:11] belated good morning all [09:11] i was just reading the news and wanted to congratulate us on getting snapd running on android [09:12] even though it's strange that autoimport on android only works on vfat and ext4 [09:12] /end sarcastic rant about the news getting the wrong end of circular sticks [09:14] Chipaca: hello [09:14] Chipaca: oh? where did you get that? [09:15] zyga-ubuntu: http://news.softpedia.com/news/canonical-aims-to-bring-its-ubuntu-snappy-technologies-to-android-devices-517677.shtml [09:16] and linkedin was the one that pointed me at that, with "your contact Gustavo Niemeyer is in the news" or sth like that [09:16] bootloaders are hard [09:25] "The seccomp argument filtering was re-enabled in this release of Snapd, which renames the "snap change" command to "snap tasks," adds new "search" alias for the "snap find" command, adds support for displaying snap types under..." [09:25] some weird sentence [09:28] * mwhudson o/ [09:28] mwhudson: hey [09:30] PR snapd#3894 closed: many: fix TestSetConfNumber missing an Unlock and other fragility improvements [09:33] "Perhaps Snap has problems on other partition types: RTFS, EXT3, NTFS, ... ? This shows some of the difficulties with other operating systems: IOS, Windows, etc. The "competitors" to Snap should be facing similar problems: Pacman, Java, etc." [09:33] * zyga-ubuntu stops reading comments [09:42] Can snapd update itself? [09:46] itsfemme[m], it does all the time [09:48] (when installing your first snap, snapd also installs the core snap ... the core snap ships snapd inside ... if the snapd in the core snap is newer than the ony installed from your distro package snapd will re-exec itself to the ne from core) [09:48] s/ony/one/ [09:50] hi, running snapd build from master I get errors like this: 2017/09/11 09:45:57.034353 helpers.go:152: cannot regenerate seccomp profile for snap "hello-world": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root") [09:50] this happens both at snapd start and when I try to install a local snap (which makes the install fail) [09:50] Chipaca: #3884 is a cleanup you maybe can look at that when you are not otherwise busy [09:50] PR #3884: store: simplify api url config [09:51] ackk, are you running from maste because you added a local patch ? [09:51] ogra_, yes [09:51] ogra_, fwiw http://paste.ubuntu.com/25513563/ is the error I get at install [09:51] ah, then i'll leave that to zyga-ubuntu :) (if you just wanted to run maste, refreshing your core snap to edge would be sufficient) [09:52] ogra_, fwiw I'm quite confident my change has nothing to do with it [09:53] anyone have any guesses what is happening here? https://launchpadlibrarian.net/336570963/buildlog_snap_ubuntu_xenial_amd64_subiquity_BUILDING.txt.gz [09:53] it passes in a local cleanbuild [09:53] zyga-ubuntu, hi, do you have any idea about the issue above? [09:54] mvo: core transition tests are again failing sometimes [09:54] ackk: perhaps, where are you running this? [09:54] mvo: https://travis-ci.org/snapcore/snapd/builds/274077647?utm_source=github_status&utm_medium=notification [09:54] (snap version is best output) [09:54] pedronis: nice, thank you [09:55] mwhudson, tried adding lsb-release to your build-deps (just for laughs) ? [09:55] ogra_: it's already there, i think it's that that's messing things up [09:55] somehow [09:55] hmm [09:55] zyga-ubuntu, http://paste.ubuntu.com/25513578/ in a xenial LXD [09:55] ogra_: that's what i said :) [09:55] heh [09:56] ackk: snapd unknown? [09:56] zyga-ubuntu, well as said it's built from master [09:56] which architecture is that? [09:56] ackk: aha [09:56] zyga-ubuntu, amd64 [09:56] ackk: I cannot context swap too much today, can you wait 30 minutes please? [09:56] zyga-ubuntu, sure [09:57] let's see if dropping lsb-release from deps helps... [09:58] oh wait, no lsb-release is not in build-deps [09:58] mwhudson, note that we explicitlly remove lsb_release from core, so if this is supposed to run on core eventually you rather want to read /etc/os-release instead [09:59] ogra_: this is subiquity so until/unless curtin can install core... [10:01] PR snapd#3898 opened: Add bcm type detection [10:03] pedronis: looking [10:05] pedronis: some of the errors might be because the store had a HW issue recently [10:06] mvo: yes, a couple are 504 from the store, but wondering about the transition one [10:06] there's not a log there though [10:06] :/ [10:07] ogra_: ah, i had lsb-release in stage-packages but not build-packages, fixing that fixed the build [10:07] pedronis: hm, not this one I assume https://travis-ci.org/snapcore/snapd/builds/274077647#L6046 (that is a 504) [10:07] :) [10:07] pedronis: or am I looking at the wrong error log? [10:09] I was confused, the log is separate now? [10:13] pedronis: not sure, I'm confused now too :) sorry, I thought I had clicked on the failure log that you mentioned earlier, but when I click that now I just see "Hang tight, the log cannot be shown until the build has started." [10:13] pedronis: fwiw, master is also failing with some 504s [10:15] mvo: I squash merged #3894 btw, you marked it for 2.28 so I suppose you want to make a cherry-pick ? [10:15] PR #3894: many: fix TestSetConfNumber missing an Unlock and other fragility improvements [10:16] pedronis: yes, thank you! [10:16] mvo: #3777 needs a master merge? [10:16] PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) [10:17] pedronis: yes, let me do that [10:23] PR snapd#3899 opened: many: fix TestSetConfNumber missing an Unlock and other fragility improvements (2.28) [10:25] mvo: the store downloads have still some problems, so tests will be a bit more bumpy for a while more [10:25] pedronis: yeah, thats ok. thanks for the heads up [10:26] pedronis: I had to open 3899, the cherry pick did not apply cleanly [10:26] ok, will look [10:27] pedronis: should be super trivial, but when it does not apply cleanly I cherry-pick, resolve and push as a new branch to get the benefit of the spread run [10:27] ah, the settle stuff [10:30] uh why are store uploads not working [10:30] eg https://code.launchpad.net/~canonical-foundations/+snap/subiquity/+build/79418 [10:30] mwhudson: it could be a side effect of a HW failure that happen recently in the datacenter [10:30] well, you have an oops [10:31] give it to wgrant or cjwatson :) [10:31] * wgrant looks [10:31] Very probable that it's related to the hardware failure [10:31] mwhudson: Yeah, that'll be the hardware failure. A retry should work. [10:31] We have people in the DC now bringing up replacement hardware. [10:32] wgrant: ok [10:32] I hadn't realised that was actually failing uploads, ugh. [10:32] Must be due to Swift communication. [10:32] ah yes retry worked [10:32] if i have to retry the upload i'll have to do the release-to-channel bit myself, right? [10:33] Sorry about that. It's the PS4.5 IR from 2017-09-09 FYI [10:33] Hm, shouldn't have to. [10:33] I'd expect it to still autorelease. [10:33] ah ok [10:33] * zyga-ubuntu waits for spread run to finish [10:33] how do I publish this now... [10:36] ah yes auto-release happened [10:42] zyga-ubuntu, fwiw I also get this error at startup: "2017/09/11 10:40:29.655727 helpers.go:99: snap "lxd" has bad plugs or slots: lxd (lxd slots are reserved for the core snap)" [10:44] ackk: did you self build that snap as well? [10:44] zyga-ubuntu, yes [10:44] ackk: then you probably lack the relevant assertion [10:44] ackk: it's a bit hard to work with [10:45] zyga-ubuntu, I only added a few options to the snapcraft.yaml, didn't change anything else [10:46] ackk: right but you cannot sign it yourself [10:46] ackk: and the assertion won't be in place [10:46] ackk: so you won't get the right interface [10:46] ackk: I honestly don't know what to do about that [10:47] store uploads still seem a bit wonky, one of my retries failed [10:50] zyga-ubuntu, so http://paste.ubuntu.com/25513886/ is release vs my build [10:50] that u:{username} is a separate thing [10:50] I'll look into that soon [10:51] ackk: 2017/09/11 10:47:28.525309 helpers.go:152: cannot regenerate seccomp profile for snap "hello-world": error: cannot parse line: cannot parse token "u:root" (line "chown - u:root g:root") -- this looks like the wrong snap-confine/snap-seccomp pair [10:52] zyga-ubuntu, ah, you mean because it's using those from the release rather than the locally built ones? [10:53] ackk: yes [10:53] zyga-ubuntu, I don't seem to have a snap-confine binary [10:54] zyga-ubuntu, will snapd look up snap-seccomp by $PATH ? [10:55] mwhudson: We're still bringing up the replacement hardware. [10:56] ackk: no [10:56] ackk: it knows exactly where to look [10:56] oh [10:56] ackk: it also may choose to re-execute from core snap [10:57] ackk: if you don't know better yet please just rebuild snapd and install the whole package [10:57] I see [10:57] thanks [10:57] ackk: you may also need to disable reexec by setting SNAP_REEXEC=0 [10:58] ackk: or use a wonky high version number [10:58] zyga-ubuntu, disable it where? [10:59] ackk: in the environment [10:59] ackk: if you want to do globally (so that it affects snapd try /etc/environment) [10:59] ok thanks [11:03] PR snapd#3892 closed: systemd: add systemd.MockJournalctl() [11:03] PR snapd#3895 closed: osutil: adjust StreamCommand tests for golang 1.9 (2.28) [11:06] PR snapd#3899 closed: many: fix TestSetConfNumber missing an Unlock and other fragility improvements (2.28) [11:07] PR snapd#3896 closed: packaging/fedora: Ensure vendor/ is empty for builds and fix spec to build current master (2.28) [11:12] * zyga-ubuntu -> lunch while https://github.com/snapcore/snapd/pull/3621 gets tested [11:12] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [11:13] jdstrand: I think that is ready for another review [11:13] jdstrand: alternatively I can split and propose separate parts [11:21] wgrant: ah so it was more "a retry will work eventually" than "a retry will work now" [11:22] mwhudson: Oh, yes, sorry. [11:23] zyga-ubuntu, fwiw I get the error about the lxd snap even with a rebuilt package, but the u:/g: errors went away [11:24] ackk: right, as I said you won't be able to rebuild lxd [11:24] ackk: as lxd has superpowers the assertion is mandatory to get an interface connected [11:24] I see [11:24] ackk: or to even have a plug/slot present [11:24] you must round trip through the store [11:25] zyga-ubuntu, is that error fatal for the snap, or just an issue for the snap actually working? [11:25] I guess i could build a simpler snap for my tests [11:25] ackk: lxd is a bit special so if you can test with another snap, please [11:25] zyga-ubuntu, ok, thanks [11:28] zyga-ubuntu: you can rebuild lxd but then you need to install with --dangerous, and connect everything manually [11:28] ogra_: yay https://drive.google.com/file/d/0B5xwucQA3JSJOTEzdkwySy04TUU/view?usp=sharing [11:28] WOHOOO! [11:28] zyga-ubuntu: that's a for develpoment approach though [11:28] sborovkov, any changes that i should merge ? [11:28] pedronis: can you? I think the base declaration will kill the slots [11:30] ogra_: not sure if I did it clean... and there is extra stuff I commented out that does not matter... https://hastebin.com/werawoyiji.diff (i.e. define changes).... I commented out drawing text since we don't do that. And used the path for drawing full screen images [11:30] zyga-ubuntu: no because --dangerous [11:31] i'm off for a walk (need to take something to the boys' school) and lunch; bbiab [11:32] o/ [11:32] zyga-ubuntu: with --dangerous we ignore all decls, that's why it's --dangerous, otoh you can develop your snap [11:33] sborovkov, i'll try with your changed patch later today .... if it doesnt break the default setup we use i think it is fine to merge ... (not sure about the psplash_fb_draw_image though) [11:34] zyga-ubuntu: look around ./overlord/ifacestate/ifacestate.go:196 [11:34] * zyga-ubuntu nods === LarreaMikel1 is now known as LarreaMikel [11:39] * zyga-ubuntu is worried about his son and goes to school [11:40] ah wait [11:40] I was looking at the calendar wrong, it's not time yet [11:43] you have a claendar entry "worry about son" ? === LarreaMikel1 is now known as LarreaMikel [11:49] sborovkov, hmm, do you know what i think ? ... my splash uses a white bg .... i think one of your white bars is simply the default bg color for the text, if we set that to your actual bg color this might work [11:49] (whitour commenting out the function) [11:49] *without [11:50] (you might eventually want to use text to show a message or so ... so lets see that we dont kill that feature completely) [11:51] ogra_: you can just undefine #define PSPLASH_STARTUP_MSG "" I think if there is no message then it won't be called [11:51] draw_text [11:52] and yeah same bg color should solve the issue [11:52] ah, right [11:52] because it tries to draw it even if there is no text now [11:52] the other "bar" might be the bg for the progressbar [11:52] yup [11:52] right, but if you take away that UI element completely the psplash-write command will likely not work [11:53] not sure if this is going to center stuff (fb->width - CORE_IMG_WIDTH)/2, - if we start at lower resoluttion x and y will be negative [11:53] so we should definitely keep the message part but make it default to the bg color [11:54] well, not if your image isnt smaller than the most minimal resolution you use [11:55] yeah but for rpi3 1080p is default one, everything else is edge case when something is not detected I guess [11:55] ogra_: who is maintaining cm3 gadget snap btw? it's now quite far behind [11:56] sborovkov, ondra and i ... since i dont have the HW i'm waiting for ondra to test the "build from source" PR https://github.com/snapcore/cm3-gadget/pull/1 [11:56] PR cm3-gadget#1: build uboot from source, pull blobs from upstream, use dtbs from archive [11:56] once thats there i'll also add the splash PR for it [11:57] it is on our both TODOs ... no worries ;) [11:57] alright :-) [12:29] mvo, zyga-ubuntu, well, at least right now 2.28 builds on Fedora [12:29] :) [12:29] so once you've made the first RC, it can be tested === ShalokShalom_ is now known as ShalokShalom [12:36] Son_Goku: \o/ [12:36] Son_Goku: thats great news [12:36] and now, when people change the dependencies, Travis should fail when they don't do the right thing [12:37] excellent! [12:37] * mvo hugs Son_Goku [12:37] I'm still furious that this was a thing for the longest time, though :( [12:38] Son_Goku: :( sorry [12:38] but at least it can't happen anymore unless someone deliberately modifies the spec to prevent vendor leaking in [12:40] it's a pain to read Travis logs though [12:52] mvo, is there any way one can download account/account-key assertions for a user from the store? [12:54] abeato, did you check "snap known --help" ` [12:54] ? [12:54] abeato: snap known --remote account should work, you will need the account-id [12:55] abeato: e.g. "snap known --remote account account-id=canonical [12:55] " [12:55] zyga-suse, zyga-ubuntu, you need to convert the os-release blacklist into a whitelist [12:56] Son_Goku: I saw your post, replied on the forum, I don't know how one is better than the other [12:56] mvo, ogra_ yayh, that works, thanks :) [12:57] Son_Goku: I'd like to remove the list altogether [12:57] Son_Goku: it's just that we cannot detect everything yet [12:57] I did not know about that --remote thing, nice [12:57] zyga-ubuntu, yes, but you're never going to be able to [12:57] Son_Goku: but white vs black list is not any different [12:57] mvo, abeato note though that only canonical has a cleatext alias fo account-id it seems ... if i want to pull my own assertioon i cant use account-id=ogra [12:57] it needs the hex string from https://dashboard.snapcraft.io/dev/account/ [12:58] zyga-ubuntu: the underlying assumption is what's broken [12:58] a blacklist implies you know it works until it doesn't [12:58] when we both know the opposite is the case [12:58] yeah, it would be great to have some sort of alias ;) [12:58] Son_Goku: let's chat on the fourm [12:59] Son_Goku: two conversations are harder to keep track [12:59] of [12:59] abeato, yeah, simply the snap namespace would do i guess (afaik thats unique too) [13:22] nessita_: hi! if I go to https://dashboard.snapcraft.io/dev/snaps/8338/rev/3/, click 'Run automated review again' I'm getting a 504 [13:22] nessita_: tried several times [13:23] ogra_, why can't splash be used for showing different splash on the first boot btw? Can't we just bundle 2 images. And check if some file exists to make sure it's first boot (or however that's possible to check). Does not look very complex to implement [13:23] jdstrand, checking! [13:25] wgrant, can the above (504 on firing the review checks again) be related to the network issues from PS45? [13:25] wgrant, as in our celery workers are not reachable [13:25] nessita_: Hm, does that hit CUD during the request? [13:25] sborovkov, well ... patches accepted ;) [13:26] nessita_: CUD is behind the bad router. [13:26] And packet loss is getting fairly bad [13:26] sborovkov, i think it would need quite some changes though since psplash actually compiles the image into the binary [13:26] (it cnverts it to a header and then includes the image data) [13:27] this is the reason why it is so small [13:27] ogra_, yeah so the change would be to compile 2 images. Or, we can show text actually [13:27] Do you know how I can check if it's first boot from inside psplash? [13:28] well, the splash gets loaded and started fom the initrd ... [13:28] so this would be a bit tricky [13:29] (since we load it before anything of the rootfs is mounted ...) [13:29] Yeah that's the main question. Because at least drawing text that it's first boot and configuration is in progress would be trivial and require almost no changes then [13:29] sborovkov, well, as i said before you should use psplash-write to draw text ... [13:30] wgrant, yeah, it has to redownload the snap [13:31] sborovkov, but that would still need changes to snapd to use psplash-write for printing some "setting up the system..." message or some such ... [13:31] jdstrand, wgrant so after a few retries, the action finally worked. There are some issues with hardware going on. [13:31] ogra_ you mean function inside psplash? [13:32] no, i mean the psplash-write tool it builds [13:32] Ah ok [13:32] The main question is still how to figure out how to know if it's first boot then [13:32] it wuld have to live in the core snap ... [13:33] the only thing actually knowing reliably that it is first boot is snapd [13:34] you can indeed have some script that toouches a flag file or some such ... but if you i.e. pwer off the board while snapd's firstbooot setup runs you might have it re-run so this isnt super reliable [13:44] sborovkov, what you can do is to change the psplash snapcraft.yaml part, include psplash-write alongside psplash itself, create an initrd/scripts/init-bottom script that looks on the rootfs and prints a message if a certain condition isnt fulfilled or so [13:45] (the build actually creates psplash-write anyway, we just dont install it in the initrd case) [13:46] if you use an initr-bottom script, the writable partition is mounted under /root so you can have your script do some checks [13:47] (the good thing with that setup is that you can actually do everything from the gadget without needing changes in core or any additional snap) [13:56] mvo: hi! did you have time to look at https://github.com/snapcore/snapd/pull/3850#pullrequestreview-60647180? [13:56] PR #3850: tests: check for negative syscalls in runBpf() and skip those tests [13:56] jdstrand: yes [13:56] jdstrand: I just updated the bug and work on a fix [13:56] oh nice [13:56] jdstrand: its a regression in libseccomp2 [13:56] jdstrand: LP 1576066 [13:57] \o/ [13:57] mvo: thanks for trackcing that down :) [13:57] jdstrand: I hope to be able to provide something useful in ~1-2h or so (most of the time is testing) [13:57] jdstrand: your welcome! next I plan to build secondary-arch binaries to test that with the build-in bpf machine as well, but first things first. I am having fun :) [13:58] :) [14:00] sborovkov, quickly hacked together ... http://paste.ubuntu.com/25514581/ something like this [14:00] ogra_ cool I will try it [14:01] well, you still need to work out the check [14:01] this will simply show the message on every boot [14:01] What about your example? [14:01] see line 20-23 in that pastebin [14:03] Yeah that's what I meant can't I just check for that? [14:03] for what ? [14:04] i'm not sure if we ship oor not ship the state.jsn on a virgin image ... you need to find a condition thats unique only on first boot [14:04] Ok understood [14:05] but for the rest this script should work to display a message [14:05] (well, perhaps not in your psplash because you removed the print text stuff ... ) [14:06] (might need to add it back) [14:16] and I'm back [14:16] paperwork done, she can now *return* by herself too [14:19] zyga-ubuntu: shocking [14:20] Chipaca: those async protocols [14:20] walk yes, but return no [14:20] ;-) [14:21] PR snapd#3900 opened: snap-seccomp: manually resolve socket() call in tests [14:55] mvo: I'm seeing failures that look like [14:55] + systemd-detect-virt -c [14:55] /bin/bash: line 58: systemd-detect-virt: command not found [14:55] zyga-ubuntu, is there a workaround for https://bugs.launchpad.net/snapd/+bug/1712930 to get the snap removed? sometimes reboot + killing squashfuse seems to work, other times the snap is left disabled,broken for a long time, then it disappears [14:55] Bug #1712930: snap-confine: mounts happen in the wrong order [14:55] mvo: have you seen this? is this fixed in master? [14:55] ackk: not yet, it's on the top of my plate though [14:55] zyga-ubuntu: no to both, slightly strange systemd-detect-virt should be available, where exactlxy do you see this? [14:56] zyga-ubuntu, cool, thanks [14:56] mvo: on 14.04 and 16.04 [14:56] ah, sorry on 14.04 only [14:56] https://s3.amazonaws.com/archive.travis-ci.org/jobs/274125373/log.txt?X-Amz-Expires=30&X-Amz-Date=20170911T145438Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170911/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=2a17a16eaf9f3fae7891d7842d7da85772bdbc14821fefb8643a9a2a3d6217c6 [14:59] zyga-ubuntu: aha, that makes (some) sense, but super strange that it starts to failing now. in what pr is that? [14:59] mvo: the long standing one about snap-update-ns [14:59] https://github.com/snapcore/snapd/pull/3621 [14:59] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [14:59] the comments that landed on top are just small changes that have no chance to cause this [15:00] hmm, store still wonky [15:00] error: received an unexpected http response code (504) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_1797.snap?t=2017-09-11T16:00:00Z&h=27f39e227e74faf690363d527e7cbbf0d92bb7fd [15:04] ogra_ hmm if I use psplash-write then I'd have to draw line for text every time I guess :-( We gave gradient on splash screen so that's not very nice, hmm. [15:04] zyga-ubuntu: downloads should be stabilizing now [15:05] zyga-ubuntu: I have a look, still puzzling [15:09] noise][: thank you [15:10] mvo: no worries, I'll inveatigate too, I just wanted to know if this is a known issue [15:11] PR snapd#3901 opened: snap-seccomp: run secondary-arch tests via gcc-multilib [15:19] sborovkov, hmm, prehaps move it to the very top or bottom ? [15:23] Still ugly though [15:23] yeah :/ [15:23] build two psplash binaries ? [15:24] hmm, so that one draws that row if it's called? [15:24] (then you can also bake the message into the png) [15:24] yeah, or even without psplash-write completely ... just have one psplash with the message and one without and show them conditionally [15:25] though you might need to show it later then since you need the mounted writable partition in /root [15:25] hmm, how does psplash-write work though? Does it call that binary again? With text parameter? [15:25] I mean if there is no text is passed I don't have to draw border [15:25] it talks to psplash ... not sure how ... perhaps through a socket [15:25] * ogra_ isnt near the code atm [15:26] Hmm then I can check what text we are getting [15:26] If there is no text I don't have to draw the row for it [15:26] yeah [15:27] well, thanks to being in the gadget you have all the freedom to hack it up to your liking :) [15:35] PR snapd#3902 opened: tests: try to fix staging tests [15:35] cachio: this ^ should help with staging tests I think, but I haven't tried a full run [15:36] pedronis, great, thanks [15:36] pedronis, I'll make a run [15:37] does anyone know what can cause this error: Mount snap "sleep" (unset) (internal error: could not unmarshal state entry "snap-type": invalid snap type: "") ? [15:38] (at "snap install" time with a local snap) [15:48] ackk: what snap --version is this? [15:48] pedronis, master [15:48] I haven't seen something like that in a long time [15:51] pedronis, I'm not sure what changed, it used to work earlier today [15:51] I just rebuilt the package to see if something was messed up, but I still get the error [15:51] jdstrand: hey [15:52] pedronis, where should snap-type be set? [15:52] is set during mount itself [15:52] after reading it from the snap [15:53] cachio: do you have fixes pending for 2.28 btw ? iirc you mentioned there are two failing tests currently? anything I could look at? [15:53] do we actually set it in non kernel/gadget/os ones ? i always through unset falls back to a defautl value [15:53] ackk: how it this snap build? [15:53] pedronis, so the snap should have that value in snap.yaml? [15:53] pedronis, from snapcraft [15:53] (was that "app" ?) [15:53] something is weird [15:54] ogra_: correct [15:54] but something is confused there [15:54] hah, i'm not *that* old :) [15:54] * ogra_ still remembers things from a year ago :) [15:54] pedronis, the snap installs on my machine (it's failing in a xenial LXD) [15:54] jdstrand: not sure if you are around, if you have a moment please have a look at the update-ns PR again, I did a round of fixes as requested [15:54] mvo, this https://paste.ubuntu.com/25515142/ [15:54] jdstrand: ignore the test failures there, we're going to address them, not related to what this PR is about [15:54] mvo, not sure why it is happening [15:55] ackk: a xenial ldx with snapd master? [15:55] ackk, and other snaps work in that container ? (did you test) [15:55] pedronis, correct [15:55] ogra_, they used to, lemme try installing one [15:55] +1 [15:55] mvo, not sure if it is a test issue or a minor bug [15:55] ogra_, they do [15:55] k, jst to be sure :) [15:56] * zyga-ubuntu sits at a parent's meeting at school [15:56] *just [15:56] so far nobody minds me working on snapd [15:56] cachio: thanks, looking [15:56] mvo, but in some cases it is leaving an end of line at the end of the file and other cases it is not leaving it, not sure why [15:56] zyga-ubuntu, chatting while the teacher talks to you ? [15:56] how rude :) === cachio is now known as cachio_lunch [15:56] cachio_lunch: oh, interessting [15:56] ogra_, fwiw http://paste.ubuntu.com/25515151/ is my snap definition [15:57] hmm [15:57] cachio_lunch: that does look like a bug (but minor), I wonder why its not determinist. I have a look, is that the only known issue right now? [15:57] ogra_: no, the teachers are not here yet [15:57] i wonder if due to the new socket stuff some validation simply falls over [15:57] ogra_: so far observing the "parents sit in the back" is very similar to "kids sit in the back" [15:57] haha [15:57] people age but behaviors don't change [15:57] yeah [15:58] ogra_, so that's the stuff i'm working on. i changed the snapcraft schema do accept that [15:58] ogra_, and snapd too [15:58] right, seems snapd misses something then [15:59] (just guessing here ... i'm not a snapd dev :) ) [16:01] ogra_, it used to work, but I'll dig more... [16:04] zyga-ubuntu: I saw, thanks! === cachio_lunch is now known as cachio [16:10] ogra_, do you know if snap-type should be set anywhere in the snap? grep doesn't find anything [16:10] only for kernel, gadget and os usually ... [16:11] not for normal app snaps [16:24] acck: there's code in snap/ that should be happy to default to app when type: is not in the snap.yaml [16:25] why is not working for your snap I don't know [16:25] or your snapd [16:25] can you look at the produced snap.yaml? [16:46] jdstrand: thanks :) === JanC_ is now known as JanC [17:02] Issue snapcraft#1442 closed: `build-snaps` === nacc_ is now known as nacc === JoshStrobl|zzz is now known as JoshStrobl [19:32] re [19:32] boy, that was one long school meeting :/ [19:33] three hours [19:33] noise][: hey, I was asked if snappy store will get any web presence and I recall there were some plans to have a public website for all the store snaps [19:33] noise][: can you tell me more about it? [19:34] zyga-suse: yes, there is work in progress now [19:35] noise][: is there any rough estimate as to when that may be visible to the public? [19:35] that's being done by the web team (with API support from us) - I don't have an ETA at the moment [19:36] noise][: thanks, [19:37] noise][: one more thing, is there any public roadmap for the store, such as the one recently made for snapd? [19:38] PR snapcraft#1545 opened: pluginhandler: error out on scriptlet errors [19:39] not at this time [19:40] hmm, so on edge xdg-open is completely borked for all my apps [19:41] Error org.freedesktop.DBus.Error.ServiceUnknown: The name io.snapcraft.Launcher was not provided by any .service files [19:41] Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonial.SafeLauncher was not provided by any .service files [19:41] great ... even on stable i cant open any links from any snap anymore [19:42] ogra_: you probably need the edge version of the debian package [19:42] ogra_: to get the service defintion [19:42] so we leave all users broken til the next release ? [19:42] (i'm no the stable core now) [19:43] *on [19:43] ogra@styx:~$ snap version [19:43] snap 2.27.5 [19:43] snapd 2.27.5 [19:43] ogra_: you need master version of the package (just get the deb from the ppa) [19:43] zyga-suse, why ? [19:43] ogra_: as the snap userd is not started otherwise [19:44] ogra_: alternatively try to start it yourself from master build [19:44] ogra_: because it needs a new systemd / upstart service file [19:44] why ? [19:44] so we tell our stable users they need to pull some stuff from master ? [19:44] no, I mean this should not have been done in master [19:44] er [19:44] in stable [19:45] if this broke in stable we need a new core release to synchronize this with userd work [19:45] i *had* edge installed, but switched to stable [19:45] mvo: ^ [19:45] right [19:45] so if stable is behaving this way then we have a problem [19:45] and restarted the snap where the error shows up after switching to stable [19:45] maybe userd work landed in core snap before the snapd code was released [19:45] ogra_: so far it was still depending on snapd-xdg-open [19:46] do you have that installed? [19:46] if nothing secretly removed it ... [19:46] ogra@styx:~$ dpkg -l |grep xdg-open [19:46] ii snapd-xdg-open 0.0.0~16.04 amd64 Opens URLs via D-Bus [19:46] ogra@styx:~$ [19:46] but that wouldnt produce such an error anyway [19:47] that it was broken in edge is fine ... [19:47] but that it doesnt fix itself when i switch to stable is not [19:47] and i dont think 2.27.5 should have it yet === ubott2 is now known as ubottu === JamieBennett_ is now known as JamieBennett === dkessel_ is now known as dkessel === rob-oi-ma_ is now known as rob-oi-ma === psftw_ is now known as psftw === posi_ is now known as posi === victorbjelkholm_ is now known as victorbjelkholm === benoitc_ is now known as benoitc === andyrock_ is now known as andyrock === stokachu_ is now known as stokachu [20:52] anyone know how to handle /usr/bin/nohup in a strict snap? i'm snapping hadoop and one of the daemon scripts calls out to /usr/bin/nohup, which greets me like this: [20:52] $ sudo hadoop.hadoop-daemon start namenode [20:52] starting namenode, logging to /var/snap/hadoop/x1/var/log/hadoop-hdfs/hadoop-root-namenode-permbox-xenial.out [20:52] /snap/hadoop/x1/usr/lib/hadoop/sbin/hadoop-daemon.sh: line 159: /usr/bin/nohup: Permission denied [20:53] jdstrand: remember in warsaw when you were all like "dude, i'll help you do all things strict!". ^^ halp ;) [20:57] kwmonroe: nohup is missing from the template. I've taken a todo to add it. in the meantime, you can ship it yourself [20:59] with ubuntu core 16, network-manager snap is installed and really the only stable way to do anything with the network since netplan has issues but I need to use the nmcli command within another snap (docker) but really in a container in that docker snap, anybody know if this is even possible? [21:03] +1 jdstrand- thanks! [21:08] wait jdstrand, before i +1 you... by "ship it yourself", you mean stage-packages: coreutils? or make a wrapper for just the nohup command? [21:33] kwmonroe: you could stage-packages it, sure. or just grab the binary and shove it into your package. whichever you prefer [21:35] ack jdstrand.. i'll stage it. this is a multi-arch snap, so i don't want the hassle of getting the right arch bin in place. thanks again! [22:02] kwmonroe: np. I'll get it upstream this week for sure [22:12] * mwhudson is confused [22:13] i have a project with source-type: git, source: . [22:13] and i seem to have to snapcraft clean between builds to get any changes i made to be noticed? [22:13] maybe i'm holding it wrong but this doesn' [22:13] t seem ideal [22:19] oh wait, obviously i need to commit changes in this setup [22:22] mwhudson: why wouldn't you use dump plugin with . ? [22:22] mwhudson: yeah, i'm assuming it's becasue git doesn't see the changes [22:23] nacc: because it's a python thing, i need to use the python plugin i think? [22:23] mwhudson: you don't *have* to :) [22:23] mwhudson: but the source != plugin [22:23] when i didn't specify source-type: i got lots of apparently unrelated crap in my snap [22:23] mwhudson: oh wait [22:23] mwhudson: sorry, confusing myself [22:23] heh heh [22:24] mwhudson: yeah, if you're using the python plugin, then i think you're right [22:45] Issue snapcraft#1439 closed: target arch default for containers [22:45] PR snapcraft#1493 closed: lxd: only pass target arch if specified explicitly [22:48] PR snapcraft#1522 closed: catkin plugin: only append PYTHONPATH if set [22:48] PR snapcraft#1545 closed: pluginhandler: error out on scriptlet errors [23:03] PR snapd#3903 opened: tests: change regex used to validate installed ubuntu core snap