=== chihchun_afk is now known as chihchun [06:34] PR snapcraft#1295 opened: Record build packages [06:57] good morning [06:57] * zyga has reproduced the issue affecting debian [06:57] locally [06:57] (finally) [06:58] morphis: thanks for your help, I'll either contribute a debian-creation script to autopkgtest or vendorize it to build spread images in my repository [06:58] zyga: np, which issue did you reproduce exactly? [06:58] the hanging configure hook? [07:01] morphis: yes [07:01] morphis: essentially I only got the image created late last night and I left it at the spread -debug prompt [07:01] zyga: that one happens on a regular debian installation with snapd installed from the archive [07:01] yes, I'm replying on the forum [07:02] zyga: this really much looks like we miss something in 2.24 which was fixed in 2.23.6 [07:06] morphis: hmm [07:06] zyga: interesting, however we broke distros like debian with this which would validate a hotfix for 2.24 and again proves that we always have to release snapd and a core snap in sync [07:07] morphis: wait [07:07] morphis: I'm 100% sure mvo merged all of 2.23.x into 2.24 [07:07] morphis: what this 2.24 sems to be lacking is a timeout on the hook [07:07] morphis: or a way to let it fail [07:07] morphis: this VM is up for 10 hours now [07:08] and the hook is still running? [07:08] morphis: and the hook is up for 10 yours still [07:08] morphis: yep [07:08] morphis: let's check the 2.24 tree to be sure we're not missing anything [07:09] ok [07:09] spineau: good morning :) [07:10] morphis: I found one small bug btw [07:10] zyga: morning zyga [07:11] in spread setup [07:12] morphis: PR coming up in a sec, just describing it [07:15] morphis: https://github.com/snapcore/snapd/pull/3264 [07:15] PR snapd#3264: tests: remove quoting from [[ ]] when globs [07:15] morphis: and https://github.com/snapcore/snapd/pull/3265 [07:15] PR snapd#3265: spread: add spread target qemu:debian-9-64 [07:15] morphis: now to investigate 2.24 [07:15] PR snapd#3264 opened: tests: remove quoting from [[ ]] when globs [07:15] PR snapd#3265 opened: spread: add spread target qemu:debian-9-64 [07:29] morphis: signed off is a personal preference, I just think it is important as a declaration of intent, there is no formal requirement to use it [07:30] zyga: yeah it is, but what are you signing off? [07:31] for the kernel its clear but for other projects its not unless explicitly stated somewhere [07:31] morphis: oh, right, I do use the same semantics [07:31] morphis: I think there is no other well-known semantics for that line [07:31] it normally refers to https://developercertificate.org/ [07:32] yep, (though I think I read that elsewhere, I wasn't aware of this domain before) [07:34] zyga: I think the linux foundation has its own copy of this [07:34] just wasn't sure what this means in the context of snapd as we have the CLA too [07:35] morphis: I think it formally does nothing but I really wish we had it over the CLA :) [07:35] morphis: so 2.24 should have a timeout [07:35] morphis: so checking WTF [07:39] zyga: however, should we go in the meantime with https://github.com/snapcore/snapd/pull/3259 to get all other PRs unblocked? [07:39] PR snapd#3259: tests/upgrade: force install core snap from beta for debian [07:39] morphis: yes [07:40] I'll merge it now [07:40] ok [07:40] thanks [07:40] PR snapd#3259 closed: tests/upgrade: force install core snap from beta for debian [07:41] ok, let's merge master into some PRs and get some breakfast :) [07:41] :-) [07:47] ok, done [07:47] morphis: thank you, sorry for taking so long to merge this :) [07:47] morphis: I'll open a new thread to investigate the hook timeout issue [07:47] zyga: why not reusing the one we already have? [07:49] https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464 [07:49] morphis: separate topic [07:49] morphis: I linked them though [07:54] hmmm [07:54] so I removed overlord/hookstate/Context.timeout (field in the struct) and no test captured that, looking deeper [07:57] ok, breaking this to really eat something... [08:23] Sorry for the basic question, but I am a bit confused after the folder structure changed: [08:23] If I have "snapcraft.yaml" in a folder named "snap", should "setup/gui/app.desktop" be inside "snap" as well? [08:24] I moved most files into the "snap" folder after snapcraft told me "plugins" should reside there. [08:33] hi so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1657254 [08:33] Bug #1657254: console-conf - unable to connect over proxy [08:33] so the ui side is pretty easy [08:34] but once the user has provided a proxy, the thing to do is stick it in /etc/environment and systemctl restart snapd? [08:34] mwhudson: probably,yes [08:38] zyga— o/ [08:38] zyga— you're feeling like finishing a review today? :-D [08:41] zyga— snapd#3264 is gtg once green, but random tests are failing in debian? [08:41] PR snapd#3264: tests: remove quoting from [[ ]] when globs [08:47] Chipaca: hey [08:47] Chipaca: wrt 3264 yes, I'll merge master to fix it but spread is already overloaded [08:48] Chipaca: yes, I do feel like code reviews but I want to get to the bottom of hook timeout not working first [08:48] Chipaca: how are you doing? :) [08:50] jdstrand— snapd#2969 has conflicts [08:50] PR snapd#2969: interfaces: mediate netlink sockets via seccomp [08:50] zyga— doing alright i think [08:51] finally got an appointment with physio wrt my back (nhs physio takes ages) [08:51] so hopefully i'll have that fixed and be able to get back to running soonish :-) [08:53] Chipaca: I hope you will [08:58] zyga— what was the cause (and fix) for “hsearch_r failed for |S_IFREG: No such process”? [09:03] Chipaca: snap-confine from distro used when profile was made by snapd from core snap [09:03] Chipaca: where are you seeing tihs [09:04] * mwhudson reads the code systemd uses to process EnvironmentFile= directives... [09:04] * Chipaca hugs mwhudson [09:04] why would you do this to yourself [09:04] the documentation is lacking [09:04] zyga— running snapd from master [09:04] zyga— on my dev laptop [09:04] Chipaca: hmm hmm [09:04] Chipaca: self built deb? [09:05] Chipaca: build&install snap-confine [09:05] zyga— no deb [09:05] Chipaca: it'll help [09:05] Chipaca: tip: make hack [09:05] ah [09:05] (in cmd/) [09:05] zyga— you've probably got the autoconf invocation in your bash history; care to share? [09:06] Chipaca: ./autogen.sh [09:06] Chipaca: make hack :) [09:06] Chipaca: that's all you need [09:06] that had a lot more options before [09:06] :-) [09:06] whoo. i like [09:06] * Chipaca runs it again without -n [09:07] :D [09:07] PR core-build#9 opened: Add writable boot for android-boot "bootloader" [09:08] zyga— that sorted it, thanks! [09:23] PR snapd#3258 closed: cmd/snap-confine/tests: fix shellcheck on recently added files [09:40] Chipaca: I found something fishy in 2.24 [09:40] Chipaca: can you look at (in master) overlord/hookmgr/context.go [09:40] zyga— you want chips with that? [09:40] Chipaca: ha, I wish :D [09:40] Chipaca: the Context.timeout field is unused [09:41] zyga— in master it's overlord/hookstate/context.go [09:41] Chipaca: but Context.Timeout uses Context.setup.Timeout [09:41] ah, right [09:42] so I know we have a test that checks hook timeouts [09:42] but I also see this reliably not time out in spread :/ [09:42] the code there looks sane. I'll try to add debugging to see what really happens [09:43] the tests set Timeout on the setup also [09:46] zyga— i reckon that timeout in the context is a leftover bugish [09:47] yep [09:47] zyga— do you have a snap that should time out and doesn't? for testing here [09:47] ok, I'll start with 2.24 and focus on the test that checks it really works [09:48] Chipaca: yes, upgrade/basic as of 07182f7b1b7f7679f9e32f1511cc1669179c90f8 [09:48] Chipaca: but only on debian [09:48] Chipaca: where we don't have apparmor [09:48] Chipaca: if you look at 2eda8023ca28060e5a027822969399bfe89ee508 instead you can run this reliably in qemu [09:49] Chipaca: though you need a qemu image [09:50] Chipaca: (or via linode) [09:50] zyga— what hook isn't timing out? [09:50] config? iface? [09:50] device? [09:51] Chipaca: the way I understand it, the upgrade/basic test installs 2.24 and upgrades to master [09:51] Chipaca: so if 2.24 already had timeouts (and I think it does based on what I read) it should not hang with the hook there forever [09:51] ifacestate does not set a timeout [09:52] neither does devicestate [09:52] only config does [09:52] and it sets it to 5 minutes, overridable by SNAPD_CONFIGURE_HOOK_TIMEOUT environ [09:53] prepare.sh sets SNAPD_CONFIGURE_HOOK_TIMEOUT to 30s [09:53] for snapd [09:53] Chipaca: configure on core [09:55] Chipaca: and there is a timeout set, it's 5 minutes [09:55] Chipaca: it hangs because seccomp is enabled and core-support is disconnected [09:55] Chipaca: so seccomp kills part of snapctl [09:55] Chipaca: that's all expected [09:55] Chipaca: what is wrong is the timeout [09:55] Chipaca: task logs does not show we even try to kill it [09:55] hmm [09:56] zyga— does it not timeout, or does the killemall or something after it hang? [09:57] Chipaca: re, switched to mobile [09:57] Chipaca: I'm uploading a debian spread image in case you want to try [09:58] zyga— dunno if you saw my q about killemAll [09:59] Chipaca: no, sorry [09:59] Chipaca: lost in irc transition [09:59] zyga— does it not timeout, or does the killemall or something after it hang? [10:04] Chipaca: it does not, it just keeps waiting for it to run [10:05] Chipaca: and according to my reading of the code, if it were timing it out the task log would say so [10:05] Chipaca: look at... [10:05] https://forum.snapcraft.io/t/tests-broken-in-master/457/10 [10:05] the tail of that [10:05] Chipaca: the qemu image will be uploaded in 9 minutes [10:11] i think it's all Son_Goku's fault [10:11] * Chipaca hides [10:13] Chipaca: https://www.dropbox.com/sh/7k7qdo82vjjscy7/AADu7UsMsYXd5NYExOysgSx9a?dl=0 === zyga_ is now known as zyga [10:13] Chipaca: you can get that image there [10:13] zyga— question: why not compressed? [10:14] Chipaca: qcow2 [10:14] i mean, i don't mind, my connection is fast enough :-) [10:14] Chipaca: it is compressed :) [10:14] but your upload is slow [10:14] Chipaca: I was just _uploading_ that :) [10:14] Chipaca: yeah, I was sending it over 3G [10:14] Chipaca: landline is sllooooow 0.1MB/s [10:14] zyga— qcow2 isn't compressed by default, and if it is it's readonly [10:15] Chipaca: over 3G I had 0.3MB/s outdoors and (I noticed by accident) 2.5MB/s while standing on the staircase inside the house [10:15] Chipaca: aha, do you think I can make it smaller then? [10:15] zyga— resonant cavities ftw [10:16] yeah but I was surprised :) [10:17] agreed, it'd be surprising to me too :-) [10:17] a happy surprise [10:17] knowing the mechanism does not make it any less fortunate [10:19] ? [10:19] Son_Goku: I think chipaca was joking [10:20] Son_Goku— niemeyer isn't around to blame for everything, so it's your turn [10:20] we're trying to figure out what's going on wiht an apparently non-functional timeout on configure hooj [10:20] hook [10:20] zyga— bzip2 of the img would've saved 26% [10:22] debian-9-64.img: 1.351:1, 5.920 bits/byte, 26.00% saved, 789250048 in, 584078746 out. [10:22] anyway [10:23] what was i doing? [10:23] coffee. [10:24] zyga— how do you log in to the image you sent me? [10:24] ah [10:24] debian/debian [10:24] :-) [10:27] Chipaca: I added a readme file now [10:28] I'll re-compress it, drat :) [10:28] though I'll check xz [10:28] xz [10:28] zyga— is xz threaded now? [10:28] actually, never mind. I was going to coffee. [10:28] haha, enjoy :) [10:28] I have no idea [10:28] the compressor seems not to be [10:35] I commented on https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464 [10:38] Chipaca: downto 474MB [11:01] Chipaca: so I made this https://spread.zygoon.pl/ [11:07] zyga— configure: error: xfs/xqm.h unavailable [11:07] morphis— ^ [11:08] looks like build deps are wrong on debian [11:08] Chipaca: where do you get that? [11:09] Chipaca: hmm, odd, you may need xfsprogs-dev for this [11:10] zyga, Chipaca: we have xfslibs-dev in debian/control [11:11] morphis— i get this on debian after doing `sudo apt build-dep snapd` and then running autogen.sh from cmd/ [11:11] Chipaca: this gets you deps for what is in the distro [11:11] and that has not brought in xfslibs-dev [11:12] Chipaca: not for what you have in the tree [11:12] Chipaca: ah, on debian we have snapd 2.21 only [11:12] ah [11:12] i should've done build-dep ./ [11:12] yeah [11:12] yeah that brings it in [11:12] sorry for the noise then :-) [11:12] np :-) [11:13] zyga— and 'make hack' falls over because no apparmor_parser [11:13] boo, etc [11:15] Chipaca: did you configure with --disable-apparmor? [11:16] morphis: I ./autogen.sh --disable-apparmor [11:16] morphis: but I don't see that passing the option on to configure [11:17] morphis: but it does have debian-specific opts iin there [11:17] morphis: what should i do? [11:18] debian-specific opts in the configure script? [11:18] no, in autogen.sh [11:18] --libexecdir=/usr/lib/snapd [11:18] AFAIK autogen.sh checks for /etc/os-release and configures accordingly === chihchun is now known as chihchun_afk [11:19] morphis: yes, but all it does for debian is the above, no --disable-apparmor [11:19] Chipaca: but for `make hack` it looks like the easiest way is to disable the apparmor profile installation manually in Makefile.am [11:19] and even with disable-apparmor, "make hack" tries to use apparmor_parser [11:20] yeap [11:20] yeah seems to be a short coming of the Makefile.am implementation [11:22] Chipaca: looks like we need a if WITH_APPARMOR in there [11:22] also, would be extra neat if 'make hack' dtrt wrt the go binaries as well [11:23] Chipaca: yes [11:24] * zyga breaks for lunch [11:36] zyga: I think I set things up to reproduce the thing, but it didn't work (or rather, it worked). After lunch can you walk me through this? [12:06] re [12:06] Chipaca: yes [12:06] Chipaca: gladly! [12:06] zyga: so, how do i repro? :-) [12:06] zyga: do we want to keep our sync meeting today or do we want to drop it with Alex and Jamie both being out? [12:07] morphis: let's drop it [12:07] zyga: ok [12:07] morphis: fyi, I'd like to collect more images on http://spread.zygoon.pl/ [12:07] zyga: done [12:07] morphis: thanks [12:08] zyga: I can contribute a fedora-25-64 image [12:08] morphis: I can also start auto-building all the images and keeping them the web [12:08] morphis: great! [12:08] morphis: ideally you'd share something I can wget [12:08] Chipaca: ok, let's try this together [12:09] Chipaca: give me a sec for the current run to complete [12:09] zyga: i'm on detached head 2eda8023c [12:09] zyga: let me compress and upload [12:09] morphis: great [12:09] morphis: perhaps you can upload to dropbox? [12:09] zyga: built snap-confine, -exec, and d, running d with SNAP_REEXEC=0 et al [12:09] don't really use dropbox [12:10] morphis: ok [12:10] zyga: but will upload to my server [12:10] Chipaca: so, I didn't get that far, so far I can run it if I run the upgrade/basic test on debian-9-64 [12:10] Chipaca: this starts with 2.24 [12:10] Chipaca: and updates to master [12:10] (though the update fails) [12:10] Chipaca: give me a few more minutes for the current run to fail [12:11] Chipaca: so I think that what we need to try instead, if you want interactive session, is to get 2.24 [12:11] Chipaca: add some debugging if you like [12:11] Chipaca: build the deb and install it on debian-9 [12:11] Chipaca: and then snap install core [12:11] Chipaca: (stable) [12:11] Chipaca: and see what happens [12:11] Chipaca: it should break because of seccomp [12:11] Chipaca: but then we should time out the hook after 5 minutes [12:11] Chipaca: do you agree? [12:13] zyga: I'll try [12:15] Chipaca: ok I will too [12:17] Chipaca: re snapd#2969> ack, thanks. fixed [12:17] PR snapd#2969: interfaces: mediate netlink sockets via seccomp [12:19] zyga: you should review stuff ^ :-) [12:19] PR snapd#3252 closed: tests,cmd/snap-confine: port older snapd-discard-ns tests [12:20] Chipaca: aha, I guess so [12:20] * zyga opens a new ta [12:20] *tab [12:21] ah, it is this branch [12:21] * zyga read it already [12:22] ogra_: I tried the after: [desktop-qt5] step you recommended. Are there any requirements for it to work? Currently, it fails on a clean build with an error "No such file or directory: [...]/mypart/install/bin", where mypart is a completely different part in snapcraft.yml. [12:22] However, if I remove it, build again, then add it, and build once more, it works. [12:22] Seems like it depends on other parts to create an install dir for some reason. [12:24] zyga: uploading .. [12:24] Checked the backgrace, and it happens in _file_collides. [12:24] backtrace* [12:25] Must be that _file_collides assumes other parts actually install something. [12:36] gah, my network, what is going on :/ === petevg is now known as petevg_afk [12:43] niemeyer: if you drop by, you requested changes on snapd#3026, zyga did as requested (on 14/03, ie 50 days ago), branch LGTM, is it OK to merge as is? [12:43] PR snapd#3026: cmd/snap-confine: use defensive argument parser [12:44] Chipaca: Heya [12:45] Chipaca: That's not true.. I've looked at this PR last week and it wasn't fixed [12:45] niemeyer: git disagrees, but maybe he forgot to push [12:45] Chipaca: Happy to have a look again when we have a break here [12:45] or maybe i'm misreading what github says [12:46] anyway, yeah, take a gander [12:47] Chipaca: One of us is misreading.. I see "cmd/snap-confine: simplifiy error handling from argument parser" few days ago [12:48] ¯\_(ツ)_/¯ [12:49] niemeyer: yeah, github just said "added commits on 14 mar" here [12:49] had to look into commits to see that detail [12:56] zyga: https://mm.gravedo.de/files/fedora-25-64.img.xz [12:57] Son_Goku: any time to check https://bugzilla.redhat.com/show_bug.cgi?id=1444819 again? [13:03] Chipaca: standp? [13:03] morphis: thanks! [13:04] morphis: thanks, I have it now [13:07] PR snapd#3266 opened: interfaces: allow plugging DBus clients to introspect the slot service [13:26] hmmm [13:26] zyga: with qemu-img we can create a local qcow2 image that used an http image as the backing file; this'd probably be faster than downloading the images [13:27] zyga: (but you'd have to de-xz the .img for that) [13:28] zyga: if you have ssh access to spread.zygoon.pl and can xunz -k, i can test this [13:30] Chipaca: yes, sure [13:30] Chipaca: it's my server [13:30] zyga: there exist servers that only give you ftp access, to this day /o\ [13:31] Chipaca: decompressing [13:31] Chipaca: FYI, my test is now doing this: [/] Run configure hook of "core" snap if present [13:31] zyga: yeah, here as well (taking way too long at it) [13:32] Chipaca: done [13:32] Chipaca: how do you make those magic qemu images? [13:32] Chipaca: and does qemu cache anything? [13:34] if you use http you can easily decompress during download on the fly btw ... [13:35] URL=http://cdimage.ubuntu.com/ubuntu-base/xenial/daily/current/xenial-base-amd64.tar.gz [13:35] CHROOT=xenial-test-chroot [13:35] wget -q -O - $URL | zcat - | sudo tar x -C $CHROOT [13:35] zyga: qemu-img create -f qcow2 -b https://spread.zygoon.pl/debian-9-64.img debian-9-64.img [13:35] that wont use any disk space and decompress during download [13:35] (works fine with xzcat too) [13:35] ogra_: my point is we don't use _most_of the image, so we can avoid downloading it [13:36] ogra_: ooh [13:36] nice [13:36] ah,. completely, yeah [13:36] let's try that [13:37] wget -q -O - $URL | html2text | grep .... <- easy way to grep through website content ;) [13:37] ogra_: .xz doesnt work [13:37] but plain does :) [13:37] it boots [13:37] ogra_: worth a try for sure but is that fetching it in streaming still or will it use http range requests to read partially? [13:37] pretty neat!!! [13:37] cpaelzer, i think wget just streams ... [13:38] ogra_: in the use as qcow backing file I meant [13:38] directly to stdout at lest ... so it depends whet the next command in the pipe does [13:38] cpaelzer: the qemu-img approach does range requests afaik fwiw [13:39] cpaelzer, well, i never used it in that context ... [13:39] ok that I expected, be careful then [13:39] * ogra_ uses it mostly to stream tarballs to disk to avoid debootstrap [13:39] Chipaca: ok, the test just failed for me! [13:39] I'd assume something in the order of a few hundreds individual requests might take as long as the full image :-) [13:39] Chipaca: no mention of restarts! [13:40]