[01:11] <_28Kb> i wonder why snapcraft is only available as apt and not as snap too [01:19] _28Kb: IIRC it is available as a snap too. [01:27] <_28Kb> snap find snapcraft finds nothing [01:42] for some reason it isn't in the store. Maybe it is not stable. There are snaps here: https://launchpad.net/~sergiusens/+snap/snapcraft It was announced here: https://lists.ubuntu.com/archives/snapcraft/2017-March/003711.html [01:42] Probably best to stick to using it from xenial-updates as it says here: https://snapcraft.io/create/ [01:43] <_28Kb> it's ok.. I'm trying this apt version.. result should be the same > make my own snap :) === chihchun_afk is now known as chihchun === JanC is now known as Guest52949 === JanC_ is now known as JanC [06:02] PR snapd#3144 closed: overlord,release: disable classic snap support when not possible [06:04] PR snapd#2982 closed: daemon: add desktop file location for app to the API [06:08] mvo: thanks! [06:08] mvo: I have one other PR in a bit which would be nice to get into 2.24 [06:09] morphis_: sure, happy to review [06:10] need to make snap-confine building fine on i386 on other distros [06:10] mvo: btw. does QA do any testing of snapd on debian when we do releases? [06:15] morphis_: thats up to the debian maintainers [06:15] I see [06:15] morphis_: we as a team don't do any currently, but I would love to fix that [06:15] morphis_: i.e. having a spread debian machine [06:15] right, that is what I think I will look into next as debian is the next natural target for this after Ubuntu [06:23] mvo: https://github.com/snapcore/snapd/pull/3146 [06:23] PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support [06:24] PR snapd#3146 opened: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support [06:28] Son_Goku: ^^ [06:34] morphis_, I've jenkins jobs running spread tests on debian sid for releases [06:35] morphis_, but it is not really useful right now since lot of tests are failing due to confinement [06:36] morphis_, it's pretty straightforward to run on debian with autopkgtest [06:37] PR snapcraft#1236 closed: snap: use the gpg tarball instead of git:// [06:37] jibel: nice! [06:38] jibel: do you have some instructions? [06:39] morphis_, yeah, I can show you the code [06:40] morphis_, school run, back in 15min and I'll show you [06:41] jibel: ok, just ping me [07:49] hi, is there a guide for setting up a caching proxy for snapstore like apt-cacher for debs? === sergiusens_ is now known as sergiusens [08:13] good morning [08:13] oops: hey, not yet but it should be doable [08:14] oops: I was pretty interested in that actually but I didn't get to try anything [08:14] oops: snapd respects proxy settings so it might be possible to build a specialized proxy that just caches snaps / assertions [08:14] * zyga looks at PRs [08:17] mvo: thank you for updating the /snap sharing PR, looking at it now [08:19] mvo: let me see if I can help with locking [08:21] morphis_, re-spread on debian, for lack of better documentation, the code to create the VM, run the tests are there http://bazaar.launchpad.net/~canonical-platform-qa/snapcore-qa-tests/trunk/files/head:/cross-distro/Debian/ [08:21] morphis_, and the job definition to deploy in Jenkins is there http://bazaar.launchpad.net/~canonical-platform-qa-jenkins/qa-jenkins-jobs/trunk/files/head:/jobs/snapcore-qa-tests/ [08:21] morphis_, basically, there is a script called create_debian to create the testbeds [08:22] morphis_, then an wrapper around autopkgtest to run the tests from git or the deb package [08:23] hi mvo we got the same errors in the latest 2.21 -> edge reexec scenario https://travis-ci.org/snapcore/spread-cron/builds/219142686 if you could take a look when you have a minute that would be great (no rush at all), this execution was triggered after the last core snap was published to edge this morning (uses that snap for the test) [08:26] jibel, morphis_: I'd love to get some debian love here: https://github.com/zyga/spread-qemu-images [08:27] fgimenez: hm, I have a look - strange [08:28] jibel: thanks! [08:28] zyga: will have a look [08:29] jibel: just a FYI, zesty needs a 2.23.6ubuntu1 upload with a tiny diff for cloud stuff, I am preparing this now. should not afffect anything else but zesty [08:32] fgimenez: aha, we have snapd FTBFS currently in the PPA, this is why the tests fail [08:35] mvo: great thank you! we can retrigger the test when snapd builds correctly, or just wait for the next core publication to edge [08:36] fgimenez: its slightly mysterious why it fails, given that it builds fine in spread (regular spread) [08:36] fgimenez: I'm still looking at this (sort of, next, some more stuff is pending right now :/) [08:37] mvo: ok thanks let me know if i can be of any help [08:58] zyga: re locking> adding it is fine with me, maybe extracting the lock code from the ns_initialize thing as a helper and put it around the /snap bind mount code? [09:00] i.e.: re [09:01] mvo: yes, I think that is desirable, I was thinking about host_support module where we have a function that initializes the host [09:01] mvo: (with a way to pass a set of functions to call) [09:01] zyga: have you started working on the other Prune test ? otherwise I can work on that [09:01] zyga: lets keep it simple for now [09:01] pedronis: yes but I didn't finish, if you can wait I could try to finish and let you review it [09:02] ok [09:02] mvo: very simple, just one varadic function that grabs the lock and processes a NULL terminated argument list of functions to call [09:02] mvo: then it doesn't have to live in one module [09:02] mvo: and it should be easy to adjust the existing code [09:02] mvo: what do you think? [09:03] zyga: that will work. I was thinking about lock_for_snap(snapname); ensure_snap_shared_mount(); unlock_for_snap(snapname); but maybe thats too simplistic [09:04] zyga: and extract the locking into that lock_for_snap() (or whatever name) [09:04] ogra_— you around? [09:04] zyga: but again, you know that part way better so feel free to adjust [09:05] mvo: let me make something quickly and share that with you [09:05] Chipaca, sure [09:05] ogra_— sorry to bother you :-) but, did you see the email about gpio pins on the rpi? [09:05] zyga: sure [09:05] zyga: thank you! [09:06] ogra_— it's a reply to an email from the prehistoric past (~january) [09:07] Chyeah, i see it ... nothing changed, we cant upgrade the gadget on the pi yet ... only edge works [09:07] ogra_— it being in edge is a change over your last email though (where you say you'll put it in edge) [09:08] right [09:08] ogra_— want to reply, or would you rather i did? [09:08] ogra@pi3:~$ snap interfaces | grep -c gpio [09:08] 27 [09:08] (on edge) [09:08] :-) cool [09:10] maybe we could use tracks as a workaround until we let gadgets upgrade? [09:10] anyway, was just worried that email would get lost in the deluge [09:11] (if your inbox is as busy as mine is todya, it's very busy) [09:11] yeah, same here but well enough structured that i dont miss mails ;) [09:12] my filters are usually quite good, but failed me on this :-) [09:12] and it's all so interesting /o\ [09:12] oh, wait ... he says debian armhf [09:12] sounds like he runs a classic debian install with snapd on it [09:13] there you wont have these interfaces indeed ... only what snapd delivers [09:13] unless they've gone and built a debian-based core + gadget? [09:13] doubt it though [09:13] yeah, highly [09:14] they would have to mix in the PPA packages to even have it booting [09:14] that would be a messy image i guess [09:20] since canonical is killing unity/convergence, does that mean ubuntu core and snappy will die too? [09:21] zyga: you have time to give the fedora packages another spin today? [09:21] nanodrone: no [09:21] why do yall have an '_' next to your names right now? [09:21] nanodrone— the opposite if anything [09:22] nanodrone: read the announcement https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/ [09:22] nanodrone— snappy and ubuntu core are the IoT in “growing Ubuntu for cloud and IoT” [09:22] OH! [09:22] that's awesome. [09:22] nanodrone— :-) [09:23] what DE do you guys use? [09:23] hey Chipaca, i have this wip branch https://github.com/snapcore/snapd/compare/master...fgimenez:expect-snap?expand=1 for using the expect snap in snapd's suite and enable a bunch of tests on ubuntu-core systems, currently there are 3 failing tests http://paste.ubuntu.com/24326565/ could you please have a look when you have a moment? [09:24] fgimenez— sure! [09:24] right now i need to take a break because the washing machine just finished :-) [09:24] Chipaca: thx np! :) [09:24] morphis_: yes [09:24] zyga: thanks [09:24] nanodrone— I use unity 7. I have a couple of fallbacks (I'd have to dig into backups to find my xmonad config, but it's there), but I'm really used to the super+N for switching :-) [09:25] what super+N switching !! [09:25] nanodrone— "windows key" + a number, to switch to that number app? [09:25] the windows key is called "super" [09:25] (because of the space cadet keyboard) [09:25] no i know that but is it on unity? [09:26] nanodrone— if you're in unity 7 now, press and hold super [09:26] i switched to ubuntu-gnome-desktop like yesterday. [09:26] hah [09:27] it does have an extension that lets you switch like that. between windows and workspaces. [09:27] nanodrone— you dock the apps on the launcher, and then super+ switches to that app [09:27] fgimenez: where is the script that does the auto-importing/creating for the vendor branch? [09:27] anyway. that washing crumpling as i sit here and chat [09:27] * Chipaca runs [09:28] i'm gonna miss the unity touch handles :( :( [09:28] PR snapcraft#1237 opened: repo: enable elementary [09:31] mvo: it's this spread task https://github.com/snapcore/spread-cron/blob/snapd-vendor-sync/target/tasks/snapd-vendor-sync/task.yaml it is executed by spread-cron after every merge to snapd's master + green build [09:31] fgimenez: it looks like for some reason the makefile in data/systemd is missing [09:32] fgimenez: and I know why [09:32] fgimenez: I will let you know, thanks for the file [09:34] mvo: np, thank you, plz ping me if the sync task needs any tweaking [09:34] fgimenez: PR is on the way, its our silly .gitignore it seems [09:35] PR snapd#3147 opened: git: ignore only the cmd/Makefile{,.in} [09:39] fgimenez: -^ [09:46] PR snapcraft#1233 closed: docs: update contribution guide [09:48] “cannot open mount namespace of the init process: Permission denied” [09:48] zyga— does that mean anything in any language I may speak? :-) [09:49] Chipaca: it says that you ran into the kernel bug and we are running reassociate fix somehow [09:49] Chipaca: I think this got disabled, maybe the branch is still unmerged [09:49] Chipaca: looking [09:49] fgimenez— how is the expect snap getting installed? I don't remember if it's classic or devmode or what [09:51] Chipaca: it's installed with --devmode in the tests, this is the snapcraft.yaml file http://bazaar.launchpad.net/~snappy-dev/snappy-hub/expect/view/head:/snapcraft.yaml [09:51] mvo: can you fetch my remote and look at the locking brnach please [09:51] Chipaca: it's merged [09:51] Chipaca: so if you see that this is old snap-confine [09:51] zyga— how old? [09:51] Chipaca: aha, and we maaaay be just affected by lack of run-from-core on snap-confine [09:51] zyga— fgimenez is getting it a lot in http://paste.ubuntu.com/24326565/ [09:51] Chipaca: current :/ [09:51] * zyga looks [09:52] when using expect form a snap to run things from other snaps [09:53] Chipaca: I think we're lucky actually, it seems that 2.23.6 did not have any re-associate code ye [09:53] Chipaca: aaah [09:53] Chipaca: yes [09:53] Chipaca: that will happen then [09:54] Chipaca: that's what I was fixing but then we ran into kernel woes [09:54] Chipaca: you need to put that on hold until we get a new kernel in 6 weeks [09:54] fgimenez— ^ :-/ [09:54] mvo: have a look [09:54] mvo: if you agree with the direction I can work on the TODOs and propose this [09:55] zyga: where should I look? [09:55] mvo: in my remote, in the 'locking' branch please [09:55] mvo: or here https://github.com/snapcore/snapd/compare/master...zyga:locking?expand=1 [09:55] Chipaca: zyga ok thanks a lot, will wait then, i was getting also a kernel dump on syslog but it is not showing up anymore [09:55] zyga: ta [09:55] mvo: have a look at snap-confine.c changes [09:56] fgimenez— sad panda [09:56] Chipaca: me too :/ [09:59] Chipaca: np :) i'm realizing now that tests/main/completion, which was also failing, is calling "snap create-key", which gets stuck on ubuntu-core systems, i'll skip it too and wait for the new kernel to be out [10:00] zyga: I'm too simple for this, it looks nice and yet I would still prefer sc_lock(), sc_unlock() over this. sorry, maybe someone who enjoys C more should have a look and give feedback [10:00] mvo: if you do that you need to pass state to unlock [10:00] mvo: it's harder [10:00] mvo: why do you want that? [10:01] zyga: the state would be the lock_fd? [10:01] mvo: yes [10:02] zyga: I want it mostly because it feels simpler and I like simple. but again, I may just be the wrong person for this [10:02] mvo: you also have the "scope" which lets us use one function for everything [10:03] mvo: whatever we do, I'll -1 the share code without locking [10:03] zyga: sure, I understand that. but sc_lock(); sc_initialize_ns_groups();sc_unlock(); also is in a single scope and feels simpler. [10:03] mvo: so feel free to modify this or suggest changes [10:04] zyga: sure, thats totally fine [10:04] zyga: I will ponder a bit over the locking [10:04] mvo: locking is two-fold [10:04] mvo: we have gobal locking [10:04] mvo: and per-snap locking [10:04] zyga: yes, for this we need the global lock, right? [10:04] mvo: yes [10:04] zyga: and do we have global locks already? [10:04] mvo: though the way I coded it it is holding the global lock longer, I think I could release it separately [10:05] mvo: only the one in namespace initialization code [10:05] mvo: if we carry on with my proposal all those locks get removed [10:05] zyga: ok, so that would have to be extracted into a helper? [10:06] mvo: hmm? no [10:06] mvo: the helper is the new function [10:06] mvo: everything else just gets simplified, remove all the other locks [10:07] mvo: I pushed a small simplification so that locking is clearer [10:07] mvo: I can show you what I mean [10:08] mvo: e.g. on the sc_initialize_ns_groups [10:08] mvo: do you want that? [10:08] zyga: one question first - is it always acquiring a global lock? [10:08] mvo: yes [10:09] zyga: hm, I think I need to read this carefully then, I think I don't understand it [10:09] mvo: with global_lock(): do_global_init; with snap_lock(snap_name): do_snap_init(snap_name); [10:09] mvo: note that this is true both now (as is) and with this proposal [10:10] mvo: we always grab the global lock to unshare /run/snapd/ns [10:10] mvo: that python-ish example missed one important point [10:10] zyga: aha, so NULL in sc_call_while_locked() means global lock? [10:10] mvo: with global_lock(): \t do_global_init; \n with snap_lock(snap_name): \t do_snap_init(snap_name); [10:10] mvo: yes [10:11] mvo: (we can hold the global lock for a shorter amount of time) [10:13] zyga: thanks, I understand the code now, I'm just not liking it, again, don't get me wrong, nothing is "wrong". its just does not feel right to me, but I get back to the branch and look at it with fresh eyes in a little bit [10:14] mvo: if you want I can split the helper to lock/unlock [10:14] mvo: just ensuring it is used correctly gets slightly harder [10:14] mvo: but I can quickly do that if you prefer [10:15] zyga: for my PR I would love to have that, yes. there could be a followup that uses the context manager and people who enjoy C more could then weight in and give their opinion [10:22] PR snapd#3148 opened: errtracker: never send errtracker reports when running under SNAPPY_TESTING [10:24] mvo: look again please [10:25] mvo: I can now look at removing the redundant locking [10:25] mvo: I should also port the sanity timer code to locking.[ch] [10:25] mvo: so that we never hang while holding the lock [10:26] mvo: er, not holdin, trying to grab it [10:26] fg [10:28] zyga: can you approve https://github.com/snapcore/snapd/pull/3146 too? [10:28] PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support [10:29] morphis_: done [10:29] zyga: thanks [10:29] PR snapd#3146 closed: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support [10:30] o/ [10:30] has anyone got any pointers for snapping Qt guis? [10:30] I get seg faults in strict and no fonts in classic [10:37] mvo: any feedback? [10:37] joedborg: nope, sorry :/ [10:40] zyga: let me check [10:41] Chipaca, https://extensions.gnome.org/extension/413/dash-hotkeys/ [10:41] I think it's this bug https://bugs.launchpad.net/snappy/+bug/1621568 [10:41] Bug #1621568: Unable to access system fonts [10:43] zyga: yes, I like it, I would also remove the bits that are not needed yet (and you can reintroduce later), i.e. sc_call_while_locked() is not yet used afaict and also the typedef for sc_locked_fn. but I can also do that if you want, the lock helper is what I wanted :) [10:46] mvo: I'm on it [10:46] mvo: I'll remove locking elsewhere [10:46] zyga: thank you! [10:46] mvo: just finishing tests [10:48] nanodrone— hope springs eternal, etc [10:49] so... for this branch, I need the changes in the branch to be "inside" the core [10:49] currently running tests with --debug, and bind-mounting inside there, works [10:49] no idea what you mean Chipaca [10:50] nanodrone— the two sentences after 'hope springs eternal' weren't about unity vs gnome :-) [10:50] nanodrone— if your question is about 'hope springs eternal', https://en.wikipedia.org/wiki/Hope_Springs_Eternal [10:50] thanks [10:50] np [10:51] as I was saying :-) [10:51] thanks for being patient with my englisch [10:51] i need to have the stuff from this branch in-core [10:51] is there already a helper for this, or do i bind-mount in prepare/umount on restore? [10:58] mvo: ok look again please [11:01] mvo: https://github.com/snapcore/snapd/pull/3149 [11:01] PR snapd#3149: cmd: make locking around namespaces explicit [11:01] PR snapd#3149 opened: cmd: make locking around namespaces explicit [11:04] Chipaca: for whom is that question? [11:04] pedronis: I can now go back to the 2nd test [11:04] Chipaca: we do build a core in our tests and stick some stuff in it [11:05] Chipaca: do you need a pointer? [11:05] I mean spread tests [11:05] zyga: this line https://github.com/snapcore/snapd/compare/master...zyga:locking?expand=1#diff-5819ab7ed3c9b218d0b74c369e621862R114 looks a bit odd, why the "void " in front? [11:05] mvo: ah, copy paste error [11:05] mvo: (that's the function definition actually) [11:05] PR snapd#3147 closed: git: ignore only the cmd/Makefile{,.in} [11:05] good catch :) [11:06] zyga: thanks [11:06] pedronis— I'll take a look [11:07] pedronis— i'm not sure they were for anybody in particular :-) [11:07] sometimes i just need to ask for the brain to kick in [11:07] zyga: I suspected that. can I also have a #define SC_LOCK_GLOBAL NULL or ideally without #define? so that I can write sc_lock(GLOBAL) instead of sc_lock(NULL) :) ? [11:08] mvo: trivial review on https://github.com/snapcore/snapd/pull/3148 [11:08] PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING [11:08] zyga: ta [11:08] zyga: yeah, thank you! I will fix the typo [11:08] mvo: maybe a trivial function sc_lock_global() instead? [11:08] zyga: sure, works as well [11:08] mvo: I'll add one [11:09] ta [11:10] Chipaca: see update_core_snap_for_classic_reexec and setup_reflash_magic in tests/lib/prepare.sh [11:12] mvo: done [11:12] Chipaca: this could be a forum topicy I suppose, "How do we ensure we use the branch bits in spread tests" [11:12] pedronis— good idea. i'll do that. [11:13] pedronis— also i think i'll change update_core_snap_for_classic_reexec to copy all of /usr/lib/snapd, not just bits of it [11:17] http://i.imgur.com/QMMtsAt.gif === hikiko is now known as hikiko|ln [11:19] Chipaca: can I get a 2nd review on https://github.com/snapcore/snapd/pull/3135 [11:19] PR snapd#3135: interfaces/mount: add high-level Profile functions [11:20] Chipaca: gustavo already +1d it [11:24] pedronis— comme çi? https://forum.snapcraft.io/t/you-add-files-to-snapd-how-do-you-run-tests-against-them-if-theyre-needed-inside/181 [11:26] zyga, hey, do you have any PRs I should re-review? [11:26] pstolowski: I was just looking [11:26] pstolowski: give me a sec [11:27] zyga— lovely pr, good one. [11:30] Chipaca: thanks! [11:30] Chipaca: I don't get your comment there [11:30] zyga— I mean, osutil.osutil.AtomicWriteFlags(0) is about as descriptive as just '0' [11:31] zyga— maybe we want an const AtomicWriteDefault AtomicWriteFlags = 0 [11:32] zyga— hopefully that made sense despite me mangling it :-) [11:33] aaah [11:33] yes now I get it [11:33] yeah, +1, [11:33] I'll merge the branch but we can do a follow up with this [11:34] PR snapd#3135 closed: interfaces/mount: add high-level Profile functions [11:34] Chipaca, pstolowski, mvo: I could use feedback on tiny RFC branch: https://github.com/snapcore/snapd/pull/3138 [11:34] PR snapd#3138: interfaces/mount: add Change.Perform [11:35] Change.DanceForMe [11:35] zyga— you get my attention in two minute chunks, which is the time the 'prepare' stage of tests take [11:36] chunky [11:36] Chipaca: you can also +1 a structure here: https://github.com/snapcore/snapd/pull/3129 [11:36] PR snapd#3129: interfaces/mount: add InfoEntry type [11:36] Chipaca: feel free to suggest different names (those match the C code) [11:36] * zyga runs for lunch, see you at the standup [11:50] re [11:56] ah, standup is not in 5 minutes but an hour and five minutes [11:56] mvo: will you review the locking branch? [12:01] zyga: yes [12:02] great, thank you :) [12:03] * Chipaca ~> lunch [12:03] also, whee, so close to passing tests [12:13] mvo: updaed [12:13] updated* [12:13] Chipaca: yes, stuff is much greener lately :) [12:17] zyga— I was being selfish and talking about my own WIP branch [12:17] but not so selfish i'd actually have lunch [12:17] darnit [12:17] got pulled into something else as leaving [12:17] now *really* lunch [12:27] niemeyer: replied to https://github.com/snapcore/snapd/pull/3095 -- have another look please [12:27] PR snapd#3095: cmd/snap-update-ns: add C preamble for setns [12:30] fgimenez: can you re-review https://github.com/snapcore/snapd/pull/3145 please [12:30] PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition [12:31] mvo: one more on https://github.com/snapcore/snapd/pull/3148 -- sorry, I should have noticed earlier [12:31] PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING [12:32] zyga: i've done it already, dropped a comment about the last changes, we are loosing the network interface check with them === hikiko|ln is now known as hikiko [12:33] pstolowski: did your first branch that adds attributes to all the methods finally land? [12:33] fgimenez: loosing the check? [12:34] zyga: yes, with your changes we no longer check that the network plug of the test snap is connected after the transition [12:35] aha, let me check [12:35] :) [12:35] fgimenez: so, test-snapd-python-webserver, right? [12:36] aha [12:36] I see what you mean now [12:36] sorry :) [12:37] fgimenez: can I do it explicitly for network rather than network.*? [12:38] zyga: np! :) sure, i think ":network +test-snapd-python-webserver" should do it, wdyt? [12:40] yep, added [12:40] thanks, your initial diff confused me [12:40]