| _28Kb | i wonder why snapcraft is only available as apt and not as snap too | 01:11 |
|---|---|---|
| jrwren | _28Kb: IIRC it is available as a snap too. | 01:19 |
| _28Kb | snap find snapcraft finds nothing | 01:27 |
| jrwren | 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 |
| jrwren | Probably best to stick to using it from xenial-updates as it says here: https://snapcraft.io/create/ | 01:42 |
| _28Kb | it's ok.. I'm trying this apt version.. result should be the same > make my own snap :) | 01:43 |
| === chihchun_afk is now known as chihchun | ||
| === JanC is now known as Guest52949 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#3144 closed: overlord,release: disable classic snap support when not possible <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3144> | 06:02 |
| mup | PR snapd#2982 closed: daemon: add desktop file location for app to the API <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2982> | 06:04 |
| morphis_ | mvo: thanks! | 06:08 |
| morphis_ | mvo: I have one other PR in a bit which would be nice to get into 2.24 | 06:08 |
| mvo | morphis_: sure, happy to review | 06:09 |
| morphis_ | need to make snap-confine building fine on i386 on other distros | 06:10 |
| morphis_ | mvo: btw. does QA do any testing of snapd on debian when we do releases? | 06:10 |
| mvo | morphis_: thats up to the debian maintainers | 06:15 |
| morphis_ | I see | 06:15 |
| mvo | morphis_: we as a team don't do any currently, but I would love to fix that | 06:15 |
| mvo | morphis_: i.e. having a spread debian machine | 06:15 |
| morphis_ | right, that is what I think I will look into next as debian is the next natural target for this after Ubuntu | 06:15 |
| morphis_ | mvo: https://github.com/snapcore/snapd/pull/3146 | 06:23 |
| mup | PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146> | 06:23 |
| mup | PR snapd#3146 opened: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146> | 06:24 |
| morphis_ | Son_Goku: ^^ | 06:28 |
| jibel | morphis_, I've jenkins jobs running spread tests on debian sid for releases | 06:34 |
| jibel | morphis_, but it is not really useful right now since lot of tests are failing due to confinement | 06:35 |
| jibel | morphis_, it's pretty straightforward to run on debian with autopkgtest | 06:36 |
| mup | PR snapcraft#1236 closed: snap: use the gpg tarball instead of git:// <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1236> | 06:37 |
| morphis_ | jibel: nice! | 06:37 |
| morphis_ | jibel: do you have some instructions? | 06:38 |
| jibel | morphis_, yeah, I can show you the code | 06:39 |
| jibel | morphis_, school run, back in 15min and I'll show you | 06:40 |
| morphis_ | jibel: ok, just ping me | 06:41 |
| oops | hi, is there a guide for setting up a caching proxy for snapstore like apt-cacher for debs? | 07:49 |
| === sergiusens_ is now known as sergiusens | ||
| zyga | good morning | 08:13 |
| zyga | oops: hey, not yet but it should be doable | 08:13 |
| zyga | oops: I was pretty interested in that actually but I didn't get to try anything | 08:14 |
| zyga | 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:14 | |
| zyga | mvo: thank you for updating the /snap sharing PR, looking at it now | 08:17 |
| zyga | mvo: let me see if I can help with locking | 08:19 |
| jibel | 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 |
| jibel | 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 |
| jibel | morphis_, basically, there is a script called create_debian to create the testbeds | 08:21 |
| jibel | morphis_, then an wrapper around autopkgtest to run the tests from git or the deb package | 08:22 |
| fgimenez | 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:23 |
| zyga | jibel, morphis_: I'd love to get some debian love here: https://github.com/zyga/spread-qemu-images | 08:26 |
| mvo | fgimenez: hm, I have a look - strange | 08:27 |
| morphis_ | jibel: thanks! | 08:28 |
| morphis_ | zyga: will have a look | 08:28 |
| mvo | 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:29 |
| mvo | fgimenez: aha, we have snapd FTBFS currently in the PPA, this is why the tests fail | 08:32 |
| fgimenez | mvo: great thank you! we can retrigger the test when snapd builds correctly, or just wait for the next core publication to edge | 08:35 |
| mvo | fgimenez: its slightly mysterious why it fails, given that it builds fine in spread (regular spread) | 08:36 |
| mvo | fgimenez: I'm still looking at this (sort of, next, some more stuff is pending right now :/) | 08:36 |
| fgimenez | mvo: ok thanks let me know if i can be of any help | 08:37 |
| mvo | 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? | 08:58 |
| zyga | i.e.: re | 09:00 |
| zyga | 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 |
| zyga | mvo: (with a way to pass a set of functions to call) | 09:01 |
| pedronis | zyga: have you started working on the other Prune test ? otherwise I can work on that | 09:01 |
| mvo | zyga: lets keep it simple for now | 09:01 |
| zyga | pedronis: yes but I didn't finish, if you can wait I could try to finish and let you review it | 09:01 |
| pedronis | ok | 09:02 |
| zyga | mvo: very simple, just one varadic function that grabs the lock and processes a NULL terminated argument list of functions to call | 09:02 |
| zyga | mvo: then it doesn't have to live in one module | 09:02 |
| zyga | mvo: and it should be easy to adjust the existing code | 09:02 |
| zyga | mvo: what do you think? | 09:02 |
| mvo | 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:03 |
| mvo | zyga: and extract the locking into that lock_for_snap() (or whatever name) | 09:04 |
| Chipaca | ogra_— you around? | 09:04 |
| mvo | zyga: but again, you know that part way better so feel free to adjust | 09:04 |
| zyga | mvo: let me make something quickly and share that with you | 09:05 |
| ogra_ | Chipaca, sure | 09:05 |
| Chipaca | ogra_— sorry to bother you :-) but, did you see the email about gpio pins on the rpi? | 09:05 |
| mvo | zyga: sure | 09:05 |
| mvo | zyga: thank you! | 09:05 |
| Chipaca | ogra_— it's a reply to an email from the prehistoric past (~january) | 09:06 |
| ogra_ | Chyeah, i see it ... nothing changed, we cant upgrade the gadget on the pi yet ... only edge works | 09:07 |
| Chipaca | ogra_— it being in edge is a change over your last email though (where you say you'll put it in edge) | 09:07 |
| ogra_ | right | 09:08 |
| Chipaca | ogra_— want to reply, or would you rather i did? | 09:08 |
| ogra_ | ogra@pi3:~$ snap interfaces | grep -c gpio | 09:08 |
| ogra_ | 27 | 09:08 |
| ogra_ | (on edge) | 09:08 |
| Chipaca | :-) cool | 09:08 |
| Chipaca | maybe we could use tracks as a workaround until we let gadgets upgrade? | 09:10 |
| Chipaca | anyway, was just worried that email would get lost in the deluge | 09:10 |
| Chipaca | (if your inbox is as busy as mine is todya, it's very busy) | 09:11 |
| ogra_ | yeah, same here but well enough structured that i dont miss mails ;) | 09:11 |
| Chipaca | my filters are usually quite good, but failed me on this :-) | 09:12 |
| Chipaca | and it's all so interesting /o\ | 09:12 |
| ogra_ | oh, wait ... he says debian armhf | 09:12 |
| ogra_ | sounds like he runs a classic debian install with snapd on it | 09:12 |
| ogra_ | there you wont have these interfaces indeed ... only what snapd delivers | 09:13 |
| Chipaca | unless they've gone and built a debian-based core + gadget? | 09:13 |
| Chipaca | doubt it though | 09:13 |
| ogra_ | yeah, highly | 09:13 |
| ogra_ | they would have to mix in the PPA packages to even have it booting | 09:14 |
| ogra_ | that would be a messy image i guess | 09:14 |
| nanodrone | since canonical is killing unity/convergence, does that mean ubuntu core and snappy will die too? | 09:20 |
| morphis_ | zyga: you have time to give the fedora packages another spin today? | 09:21 |
| morphis_ | nanodrone: no | 09:21 |
| nanodrone | why do yall have an '_' next to your names right now? | 09:21 |
| Chipaca | nanodrone— the opposite if anything | 09:21 |
| morphis_ | nanodrone: read the announcement https://insights.ubuntu.com/2017/04/05/growing-ubuntu-for-cloud-and-iot-rather-than-phone-and-convergence/ | 09:22 |
| Chipaca | nanodrone— snappy and ubuntu core are the IoT in “growing Ubuntu for cloud and IoT” | 09:22 |
| nanodrone | OH! | 09:22 |
| nanodrone | that's awesome. | 09:22 |
| Chipaca | nanodrone— :-) | 09:22 |
| nanodrone | what DE do you guys use? | 09:23 |
| fgimenez | 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:23 |
| Chipaca | fgimenez— sure! | 09:24 |
| Chipaca | right now i need to take a break because the washing machine just finished :-) | 09:24 |
| fgimenez | Chipaca: thx np! :) | 09:24 |
| zyga | morphis_: yes | 09:24 |
| morphis_ | zyga: thanks | 09:24 |
| Chipaca | 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:24 |
| nanodrone | what super+N switching !! | 09:25 |
| Chipaca | nanodrone— "windows key" + a number, to switch to that number app? | 09:25 |
| Chipaca | the windows key is called "super" | 09:25 |
| Chipaca | (because of the space cadet keyboard) | 09:25 |
| nanodrone | no i know that but is it on unity? | 09:25 |
| Chipaca | nanodrone— if you're in unity 7 now, press and hold super | 09:26 |
| nanodrone | i switched to ubuntu-gnome-desktop like yesterday. | 09:26 |
| Chipaca | hah | 09:26 |
| nanodrone | it does have an extension that lets you switch like that. between windows and workspaces. | 09:27 |
| Chipaca | nanodrone— you dock the apps on the launcher, and then super+<the position in the launcher> switches to that app | 09:27 |
| mvo | fgimenez: where is the script that does the auto-importing/creating for the vendor branch? | 09:27 |
| Chipaca | anyway. that washing crumpling as i sit here and chat | 09:27 |
| * Chipaca runs | 09:27 | |
| nanodrone | i'm gonna miss the unity touch handles :( :( | 09:28 |
| mup | PR snapcraft#1237 opened: repo: enable elementary <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1237> | 09:28 |
| fgimenez | 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 |
| mvo | fgimenez: it looks like for some reason the makefile in data/systemd is missing | 09:31 |
| mvo | fgimenez: and I know why | 09:32 |
| mvo | fgimenez: I will let you know, thanks for the file | 09:32 |
| fgimenez | mvo: np, thank you, plz ping me if the sync task needs any tweaking | 09:34 |
| mvo | fgimenez: PR is on the way, its our silly .gitignore it seems | 09:34 |
| mup | PR snapd#3147 opened: git: ignore only the cmd/Makefile{,.in} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3147> | 09:35 |
| mvo | fgimenez: -^ | 09:39 |
| mup | PR snapcraft#1233 closed: docs: update contribution guide <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1233> | 09:46 |
| Chipaca | “cannot open mount namespace of the init process: Permission denied” | 09:48 |
| Chipaca | zyga— does that mean anything in any language I may speak? :-) | 09:48 |
| zyga | Chipaca: it says that you ran into the kernel bug and we are running reassociate fix somehow | 09:49 |
| zyga | Chipaca: I think this got disabled, maybe the branch is still unmerged | 09:49 |
| zyga | Chipaca: looking | 09:49 |
| Chipaca | fgimenez— how is the expect snap getting installed? I don't remember if it's classic or devmode or what | 09:49 |
| fgimenez | 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 |
| zyga | mvo: can you fetch my remote and look at the locking brnach please | 09:51 |
| zyga | Chipaca: it's merged | 09:51 |
| zyga | Chipaca: so if you see that this is old snap-confine | 09:51 |
| Chipaca | zyga— how old? | 09:51 |
| zyga | Chipaca: aha, and we maaaay be just affected by lack of run-from-core on snap-confine | 09:51 |
| Chipaca | zyga— fgimenez is getting it a lot in http://paste.ubuntu.com/24326565/ | 09:51 |
| zyga | Chipaca: current :/ | 09:51 |
| * zyga looks | 09:51 | |
| Chipaca | when using expect form a snap to run things from other snaps | 09:52 |
| zyga | Chipaca: I think we're lucky actually, it seems that 2.23.6 did not have any re-associate code ye | 09:53 |
| zyga | Chipaca: aaah | 09:53 |
| zyga | Chipaca: yes | 09:53 |
| zyga | Chipaca: that will happen then | 09:53 |
| zyga | Chipaca: that's what I was fixing but then we ran into kernel woes | 09:54 |
| zyga | Chipaca: you need to put that on hold until we get a new kernel in 6 weeks | 09:54 |
| Chipaca | fgimenez— ^ :-/ | 09:54 |
| zyga | mvo: have a look | 09:54 |
| zyga | mvo: if you agree with the direction I can work on the TODOs and propose this | 09:54 |
| mvo | zyga: where should I look? | 09:55 |
| zyga | mvo: in my remote, in the 'locking' branch please | 09:55 |
| zyga | mvo: or here https://github.com/snapcore/snapd/compare/master...zyga:locking?expand=1 | 09:55 |
| fgimenez | 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 |
| mvo | zyga: ta | 09:55 |
| zyga | mvo: have a look at snap-confine.c changes | 09:55 |
| Chipaca | fgimenez— sad panda | 09:56 |
| zyga | Chipaca: me too :/ | 09:56 |
| fgimenez | 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 | 09:59 |
| mvo | 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 |
| zyga | mvo: if you do that you need to pass state to unlock | 10:00 |
| zyga | mvo: it's harder | 10:00 |
| zyga | mvo: why do you want that? | 10:00 |
| mvo | zyga: the state would be the lock_fd? | 10:01 |
| zyga | mvo: yes | 10:01 |
| mvo | 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 |
| zyga | mvo: you also have the "scope" which lets us use one function for everything | 10:02 |
| zyga | mvo: whatever we do, I'll -1 the share code without locking | 10:03 |
| mvo | 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 |
| zyga | mvo: so feel free to modify this or suggest changes | 10:03 |
| mvo | zyga: sure, thats totally fine | 10:04 |
| mvo | zyga: I will ponder a bit over the locking | 10:04 |
| zyga | mvo: locking is two-fold | 10:04 |
| zyga | mvo: we have gobal locking | 10:04 |
| zyga | mvo: and per-snap locking | 10:04 |
| mvo | zyga: yes, for this we need the global lock, right? | 10:04 |
| zyga | mvo: yes | 10:04 |
| mvo | zyga: and do we have global locks already? | 10:04 |
| zyga | mvo: though the way I coded it it is holding the global lock longer, I think I could release it separately | 10:04 |
| zyga | mvo: only the one in namespace initialization code | 10:05 |
| zyga | mvo: if we carry on with my proposal all those locks get removed | 10:05 |
| mvo | zyga: ok, so that would have to be extracted into a helper? | 10:05 |
| zyga | mvo: hmm? no | 10:06 |
| zyga | mvo: the helper is the new function | 10:06 |
| zyga | mvo: everything else just gets simplified, remove all the other locks | 10:06 |
| zyga | mvo: I pushed a small simplification so that locking is clearer | 10:07 |
| zyga | mvo: I can show you what I mean | 10:07 |
| zyga | mvo: e.g. on the sc_initialize_ns_groups | 10:08 |
| zyga | mvo: do you want that? | 10:08 |
| mvo | zyga: one question first - is it always acquiring a global lock? | 10:08 |
| zyga | mvo: yes | 10:08 |
| mvo | zyga: hm, I think I need to read this carefully then, I think I don't understand it | 10:09 |
| zyga | mvo: with global_lock(): do_global_init; with snap_lock(snap_name): do_snap_init(snap_name); | 10:09 |
| zyga | mvo: note that this is true both now (as is) and with this proposal | 10:09 |
| zyga | mvo: we always grab the global lock to unshare /run/snapd/ns | 10:10 |
| zyga | mvo: that python-ish example missed one important point | 10:10 |
| mvo | zyga: aha, so NULL in sc_call_while_locked() means global lock? | 10:10 |
| zyga | mvo: with global_lock(): \t do_global_init; \n with snap_lock(snap_name): \t do_snap_init(snap_name); | 10:10 |
| zyga | mvo: yes | 10:10 |
| zyga | mvo: (we can hold the global lock for a shorter amount of time) | 10:11 |
| mvo | 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:13 |
| zyga | mvo: if you want I can split the helper to lock/unlock | 10:14 |
| zyga | mvo: just ensuring it is used correctly gets slightly harder | 10:14 |
| zyga | mvo: but I can quickly do that if you prefer | 10:14 |
| mvo | 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:15 |
| mup | PR snapd#3148 opened: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148> | 10:22 |
| zyga | mvo: look again please | 10:24 |
| zyga | mvo: I can now look at removing the redundant locking | 10:25 |
| zyga | mvo: I should also port the sanity timer code to locking.[ch] | 10:25 |
| zyga | mvo: so that we never hang while holding the lock | 10:25 |
| zyga | mvo: er, not holdin, trying to grab it | 10:26 |
| zyga | fg | 10:26 |
| morphis_ | zyga: can you approve https://github.com/snapcore/snapd/pull/3146 too? | 10:28 |
| mup | PR snapd#3146: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <https://github.com/snapcore/snapd/pull/3146> | 10:28 |
| zyga | morphis_: done | 10:29 |
| morphis_ | zyga: thanks | 10:29 |
| mup | PR snapd#3146 closed: cmd: explicitly set _GNU_SOURCE and _FILE_OFFSET_BITS for xfs support <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3146> | 10:29 |
| joedborg | o/ | 10:30 |
| joedborg | has anyone got any pointers for snapping Qt guis? | 10:30 |
| joedborg | I get seg faults in strict and no fonts in classic | 10:30 |
| zyga | mvo: any feedback? | 10:37 |
| zyga | joedborg: nope, sorry :/ | 10:37 |
| mvo | zyga: let me check | 10:40 |
| nanodrone | Chipaca, https://extensions.gnome.org/extension/413/dash-hotkeys/ | 10:41 |
| joedborg | I think it's this bug https://bugs.launchpad.net/snappy/+bug/1621568 | 10:41 |
| mup | Bug #1621568: Unable to access system fonts <snaps-interface> <Snappy:New> <https://launchpad.net/bugs/1621568> | 10:41 |
| mvo | 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:43 |
| zyga | mvo: I'm on it | 10:46 |
| zyga | mvo: I'll remove locking elsewhere | 10:46 |
| mvo | zyga: thank you! | 10:46 |
| zyga | mvo: just finishing tests | 10:46 |
| Chipaca | nanodrone— hope springs eternal, etc | 10:48 |
| Chipaca | so... for this branch, I need the changes in the branch to be "inside" the core | 10:49 |
| Chipaca | currently running tests with --debug, and bind-mounting inside there, works | 10:49 |
| nanodrone | no idea what you mean Chipaca | 10:49 |
| Chipaca | nanodrone— the two sentences after 'hope springs eternal' weren't about unity vs gnome :-) | 10:50 |
| Chipaca | nanodrone— if your question is about 'hope springs eternal', https://en.wikipedia.org/wiki/Hope_Springs_Eternal | 10:50 |
| nanodrone | thanks | 10:50 |
| Chipaca | np | 10:50 |
| Chipaca | as I was saying :-) | 10:51 |
| nanodrone | thanks for being patient with my englisch | 10:51 |
| Chipaca | i need to have the stuff from this branch in-core | 10:51 |
| Chipaca | is there already a helper for this, or do i bind-mount in prepare/umount on restore? | 10:51 |
| zyga | mvo: ok look again please | 10:58 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/3149 | 11:01 |
| mup | PR snapd#3149: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149> | 11:01 |
| mup | PR snapd#3149 opened: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149> | 11:01 |
| pedronis | Chipaca: for whom is that question? | 11:04 |
| zyga | pedronis: I can now go back to the 2nd test | 11:04 |
| pedronis | Chipaca: we do build a core in our tests and stick some stuff in it | 11:04 |
| pedronis | Chipaca: do you need a pointer? | 11:05 |
| pedronis | I mean spread tests | 11:05 |
| mvo | 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 |
| zyga | mvo: ah, copy paste error | 11:05 |
| zyga | mvo: (that's the function definition actually) | 11:05 |
| mup | PR snapd#3147 closed: git: ignore only the cmd/Makefile{,.in} <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3147> | 11:05 |
| zyga | good catch :) | 11:05 |
| mvo | zyga: thanks | 11:06 |
| Chipaca | pedronis— I'll take a look | 11:06 |
| Chipaca | pedronis— i'm not sure they were for anybody in particular :-) | 11:07 |
| Chipaca | sometimes i just need to ask for the brain to kick in | 11:07 |
| mvo | 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:07 |
| zyga | mvo: trivial review on https://github.com/snapcore/snapd/pull/3148 | 11:08 |
| mup | PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148> | 11:08 |
| mvo | zyga: ta | 11:08 |
| mvo | zyga: yeah, thank you! I will fix the typo | 11:08 |
| zyga | mvo: maybe a trivial function sc_lock_global() instead? | 11:08 |
| mvo | zyga: sure, works as well | 11:08 |
| zyga | mvo: I'll add one | 11:08 |
| mvo | ta | 11:09 |
| pedronis | Chipaca: see update_core_snap_for_classic_reexec and setup_reflash_magic in tests/lib/prepare.sh | 11:10 |
| zyga | mvo: done | 11:12 |
| pedronis | Chipaca: this could be a forum topicy I suppose, "How do we ensure we use the branch bits in spread tests" | 11:12 |
| Chipaca | pedronis— good idea. i'll do that. | 11:12 |
| Chipaca | 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:13 |
| Chipaca | http://i.imgur.com/QMMtsAt.gif | 11:17 |
| === hikiko is now known as hikiko|ln | ||
| zyga | Chipaca: can I get a 2nd review on https://github.com/snapcore/snapd/pull/3135 | 11:19 |
| mup | PR snapd#3135: interfaces/mount: add high-level Profile functions <Created by zyga> <https://github.com/snapcore/snapd/pull/3135> | 11:19 |
| zyga | Chipaca: gustavo already +1d it | 11:20 |
| Chipaca | 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:24 |
| pstolowski | zyga, hey, do you have any PRs I should re-review? | 11:26 |
| zyga | pstolowski: I was just looking | 11:26 |
| zyga | pstolowski: give me a sec | 11:26 |
| Chipaca | zyga— lovely pr, good one. | 11:27 |
| zyga | Chipaca: thanks! | 11:30 |
| zyga | Chipaca: I don't get your comment there | 11:30 |
| Chipaca | zyga— I mean, osutil.osutil.AtomicWriteFlags(0) is about as descriptive as just '0' | 11:30 |
| Chipaca | zyga— maybe we want an const AtomicWriteDefault AtomicWriteFlags = 0 | 11:31 |
| Chipaca | zyga— hopefully that made sense despite me mangling it :-) | 11:32 |
| zyga | aaah | 11:33 |
| zyga | yes now I get it | 11:33 |
| zyga | yeah, +1, | 11:33 |
| zyga | I'll merge the branch but we can do a follow up with this | 11:33 |
| mup | PR snapd#3135 closed: interfaces/mount: add high-level Profile functions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3135> | 11:34 |
| zyga | Chipaca, pstolowski, mvo: I could use feedback on tiny RFC branch: https://github.com/snapcore/snapd/pull/3138 | 11:34 |
| mup | PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138> | 11:34 |
| Chipaca | Change.DanceForMe | 11:35 |
| Chipaca | zyga— you get my attention in two minute chunks, which is the time the 'prepare' stage of tests take | 11:35 |
| ogra_ | chunky | 11:36 |
| zyga | Chipaca: you can also +1 a structure here: https://github.com/snapcore/snapd/pull/3129 | 11:36 |
| mup | PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129> | 11:36 |
| zyga | Chipaca: feel free to suggest different names (those match the C code) | 11:36 |
| * zyga runs for lunch, see you at the standup | 11:36 | |
| zyga | re | 11:50 |
| zyga | ah, standup is not in 5 minutes but an hour and five minutes | 11:56 |
| zyga | mvo: will you review the locking branch? | 11:56 |
| mvo | zyga: yes | 12:01 |
| zyga | great, thank you :) | 12:02 |
| * Chipaca ~> lunch | 12:03 | |
| Chipaca | also, whee, so close to passing tests | 12:03 |
| zyga | mvo: updaed | 12:13 |
| zyga | updated* | 12:13 |
| zyga | Chipaca: yes, stuff is much greener lately :) | 12:13 |
| Chipaca | zyga— I was being selfish and talking about my own WIP branch | 12:17 |
| Chipaca | but not so selfish i'd actually have lunch | 12:17 |
| Chipaca | darnit | 12:17 |
| Chipaca | got pulled into something else as leaving | 12:17 |
| Chipaca | now *really* lunch | 12:17 |
| zyga | niemeyer: replied to https://github.com/snapcore/snapd/pull/3095 -- have another look please | 12:27 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 12:27 |
| zyga | fgimenez: can you re-review https://github.com/snapcore/snapd/pull/3145 please | 12:30 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 12:30 |
| zyga | mvo: one more on https://github.com/snapcore/snapd/pull/3148 -- sorry, I should have noticed earlier | 12:31 |
| mup | PR snapd#3148: errtracker: never send errtracker reports when running under SNAPPY_TESTING <Created by mvo5> <https://github.com/snapcore/snapd/pull/3148> | 12:31 |
| fgimenez | zyga: i've done it already, dropped a comment about the last changes, we are loosing the network interface check with them | 12:32 |
| === hikiko|ln is now known as hikiko | ||
| zyga | pstolowski: did your first branch that adds attributes to all the methods finally land? | 12:33 |
| zyga | fgimenez: loosing the check? | 12:33 |
| fgimenez | zyga: yes, with your changes we no longer check that the network plug of the test snap is connected after the transition | 12:34 |
| zyga | aha, let me check | 12:35 |
| fgimenez | :) | 12:35 |
| zyga | fgimenez: so, test-snapd-python-webserver, right? | 12:35 |
| zyga | aha | 12:36 |
| zyga | I see what you mean now | 12:36 |
| zyga | sorry :) | 12:36 |
| zyga | fgimenez: can I do it explicitly for network rather than network.*? | 12:37 |
| fgimenez | zyga: np! :) sure, i think ":network +test-snapd-python-webserver" should do it, wdyt? | 12:38 |
| zyga | yep, added | 12:40 |
| zyga | thanks, your initial diff confused me | 12:40 |
| zyga | and I didn't understand that both network and network-bind are tested | 12:40 |
| fgimenez | zyga: yep sorry, now all looks fine, thanks! | 12:43 |
| joedborg | I'm still having trouble with fonts (or lack of) when snapping a Qt GUI - has anyone got any pointers? | 12:43 |
| pedronis | zyga: I made a comment in snapd#3095 , not clear why it cannot use a global flag to decide about bootstrap/no boostrap | 12:44 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 12:44 |
| pstolowski | zyga, no, i didn't | 12:56 |
| sborovkov | mvo: Hello, I went thorugh the list of config.txt options which we actually change in production for RPIs. The list you exposed almost 100% matches what we had to modify actually. Except those 3 parameters - could they be added to rpi-config? sdtv_aspect config_hdmi_boost hdmi_force_hotplug | 12:56 |
| mvo | sborovkov: yes, let me add those | 12:56 |
| ogra_ | mvo, ^^^ these sound all sane | 12:56 |
| zyga | pstolowski: aha, I'm working on that extra test I told you about | 12:57 |
| zyga | pedronis: looking | 12:57 |
| zyga | pedronis: replied | 12:58 |
| sborovkov | mvo: thanks! | 12:59 |
| mvo | thanks ogra_ | 13:00 |
| pedronis | zyga: we can use a build tag though | 13:02 |
| pstolowski | zyga, cool | 13:04 |
| === bruno is now known as Guest94845 | ||
| ogra_ | jdstrand, a security team comment on bug 1674509 would be appreciated | 13:20 |
| mup | Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509> | 13:20 |
| Mirv | joedborg: the first pointer usually is https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ - basically if you're fine with Qt you get from Ubuntu archives, use after: [desktop-qt5] and stage a few packages to go with your UI | 13:22 |
| davidcalle | joedborg: fyi, there is a tutorial coming up on the topic next week at tutorials.ubuntu.com | 13:24 |
| joedborg | hey Mirv, thanks for the heads up. I've already been through that :). I've also just tried to snap an Electron based app with exactly the same issue. I've tried adding a raft of font packages to stage-packages and copying the font dir on my box into prime, but no luck | 13:24 |
| Mirv | joedborg: right, I thought you might have been there already, it was just the first guess | 13:25 |
| Mirv | hmm | 13:26 |
| joedborg | Mirv: yeah, no problem :) | 13:26 |
| Mirv | I wonder then what's the difference for example between one of the examples and yours | 13:27 |
| joedborg | Mirv: the only difference I can see is that I'm just snapping a binary that's already been compiled | 13:29 |
| Mirv | joedborg: FYI I just tried the first example and the three staged packages there are enough to pull in the following font related packages: http://pastebin.ubuntu.com/24327638/ - which sound pretty much enough from packages point of view | 13:29 |
| joedborg | Mirv: whereas that's bulding QML | 13:29 |
| Mirv | joedborg: right, it's then probably related to that binary not understanding living inside a snap far enough. do you use desktop-qt5 part and desktop-launch to launch it? | 13:30 |
| Mirv | those set a whole lot of env vars, although it's not enough if the binary is hardcoding some more | 13:31 |
| Chipaca | *gasp* | 13:32 |
| Chipaca | 2017-04-06 14:32:27 Executing qemu:ubuntu-16.04-64:tests/completion/indirect:plain (1/1)... <- passed \o/ | 13:33 |
| Chipaca | woooo | 13:33 |
| ogra_ | something must be broken! | 13:33 |
| joedborg | Mirv: I don't, I just call the bin | 13:33 |
| Chipaca | ogra_— "plain" is the trivialest one; it means stuff is where it needs to be mostly | 13:33 |
| ogra_ | yeah, i was kidding indeed :) | 13:33 |
| Chipaca | ogra_— i know you were :-) | 13:33 |
| ogra_ | :) | 13:33 |
| Chipaca | but it also was worth mentioning :-) | 13:34 |
| ogra_ | yep, for that guy reading it via a google search in the logs | 13:34 |
| * ogra_ waves to that guy | 13:34 | |
| mvo | niemeyer: your opinion on https://forum.snapcraft.io/t/use-python-for-the-core-snap-configure-hook/168 would be much appreciated | 13:34 |
| Chipaca | i expect all the file-based ones to fail still (they're running now), as i need to run those as the 'test' user for access | 13:34 |
| Chipaca | mvo— as opposed to his opinion elsewhere, right? | 13:35 |
| * Chipaca grins evily | 13:35 | |
| Mirv | joedborg: right, you'd probably want to use some launcher, either the cloud one or a custom one where you first set env vars and then launch the binary. the desktop-qt5 sets these: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports + https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific | 13:35 |
| pedronis | zyga: this is what I played with locally: http://pastebin.ubuntu.com/24327653/ | 13:36 |
| niemeyer | zyga: Replied to all points in #3095 | 13:36 |
| pedronis | zyga: notice it needs -tags test when running tests | 13:36 |
| niemeyer | mvo: Thanks, let me re-read it | 13:37 |
| mvo | Chipaca: *cough* | 13:37 |
| ogra_ | mvo, oh, thanks for collecting the data there (not sure why that edit didnt put it on top of the list for me in the UI( | 13:37 |
| * zyga finished eating peanuts and drinking orange juice, now back to coding | 13:39 | |
| zyga | sorry for doing that during the call | 13:41 |
| zyga | once you start it's hard to stop :D | 13:41 |
| mvo | zyga: nobody noticed | 13:41 |
| ogra_ | you hid it very well from us | 13:41 |
| jdstrand | ogra_: commented | 13:42 |
| ogra_ | thanks ! | 13:42 |
| joedborg | Mirv: thanks! is there any example of how I used these within the yaml? | 13:43 |
| mvo | Chipaca: I added some more example to the forum entry with grouping by track (but not a new hirarchy) and without the `^` | 13:48 |
| Mirv | joedborg: well if you want to use the cloud part, just use the example from blog. if you want to define custom launcher, you could do something like this old example https://github.com/tjyrinki/timostestapp2/blob/master/snapcraft.yaml (see also launcher in the same dir that has a small portion of the possible env vars) | 13:49 |
| Mirv | just define a launcher part you then use as a command for the app | 13:50 |
| pedronis | zyga: if we can't use a build tag (too anoying) we can use a testing subpackage (bit overkill but might be easier for debian/rules) | 13:55 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#3115 closed: interfaces/unity7: support unity messaging menu <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3115> | 13:56 |
| niemeyer | mvo: replied | 13:57 |
| mup | PR snapcraft#1237 closed: repo: enable elementary <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1237> | 14:01 |
| === Trevinho_ is now known as Trevinho | ||
| === icey_ is now known as icey | ||
| Chipaca | um | 14:13 |
| Chipaca | all tests passed | 14:13 |
| Chipaca | and now what? | 14:13 |
| Chipaca | i've been working on this so long i forgot how to move forward now :-) | 14:13 |
| mvo | niemeyer_: \o/ thank you | 14:14 |
| zyga | mvo: hmm, we should have unique plug/slot names on core | 14:15 |
| pedronis | Chipaca: take a holiday? :) | 14:15 |
| zyga | mvo: and now we seem to consume network-bind and core-support | 14:15 |
| zyga | Chipaca: shave! | 14:15 |
| zyga | mvo: those should be unique | 14:15 |
| zyga | niemeyer_: ^6 | 14:15 |
| Chipaca | no! no shaving for me | 14:15 |
| mvo | zyga: yeah | 14:15 |
| Chipaca | did that a couple of years ago. Under my beard, I (a) look like my mum, and (b) am way older than i think i am | 14:15 |
| Chipaca | the beard stays | 14:16 |
| zyga | mvo: I'll have the fix in a moment | 14:16 |
| zyga | mvo: just writing test, sorry I got side-tracked on that other test I was working on | 14:16 |
| Chipaca | zyga— https://goo.gl/photos/ceE95TpmBa7DDsEN7 | 14:17 |
| zyga | Chipaca: xmas! | 14:17 |
| mvo | zyga: no worries | 14:17 |
| === daker_ is now known as daker | ||
| Chipaca | JamieBennett— #3150 | 14:27 |
| mup | PR snapd#3150 opened: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 14:27 |
| JamieBennett | \o/ | 14:28 |
| Chipaca | jdstrand— ^ tab completion; it includes changes to apparmor/template.go | 14:28 |
| Chipaca | jdstrand— some but not all of which i discussed with you | 14:28 |
| Chipaca | jdstrand— (sorry for the 'not all' :-( ) | 14:28 |
| ogra_ | so it is about time we finally remove the tab key from the keymap on our images, right ? | 14:28 |
| jdstrand | Chipaca: ok | 14:28 |
| * Chipaca *looks* at ogra_ | 14:29 | |
| Chipaca | ogra_— yeah, map it to caps lock | 14:29 |
| Chipaca | ogra_— who uses that thing anyway | 14:29 |
| * ogra_ commits "reduce size of the keymap by 1 byte to save space on IoT images" | 14:29 | |
| ogra_ | it's the small things :) | 14:30 |
| mup | PR core#31 opened: Fix pi config and add new options <Created by mvo5> <https://github.com/snapcore/core/pull/31> | 14:31 |
| mvo | ogra_: review of -^ would be great, should be trivial | 14:31 |
| ogra_ | already on it :) | 14:31 |
| ogra_ | mvo, shouldnt we just ship gawk ? so you can use sandbox ? | 14:32 |
| mup | PR core#24 closed: Rewrite meta/hooks/configure into python3 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core/pull/24> | 14:32 |
| mvo | ogra_: that would be the other option, yes | 14:33 |
| Chipaca | and of course having pushed the branch i notice bugs i thought fixed | 14:34 |
| * Chipaca pushes a little followup | 14:34 | |
| mvo | ogra_: if you could do that I will update the PR, then we can just revert that again once the hook moves to golang | 14:36 |
| ogra_ | seeding ... | 14:36 |
| mvo | ta | 14:37 |
| zyga | mvo: I found one more bug | 14:43 |
| zyga | mvo: because plug and slot name are the same | 14:44 |
| zyga | mvo: interfaces/Repository.Connected returns wrong data | 14:44 |
| zyga | oh boy :/ | 14:46 |
| zyga | mvo: can you think about an action plan where we rename the clashing plug/slots on core | 14:46 |
| zyga | mvo: and add tests so that it doesn't happen | 14:47 |
| zyga | mvo: I suspect that we added in the core snap directly | 14:47 |
| zyga | mvo: right? | 14:47 |
| zyga | mvo: I think this is the missing validation that pstolowski found | 14:47 |
| zyga | mvo: namely this: https://github.com/snapcore/snapd/pull/2932 | 14:48 |
| mup | PR snapd#2932: interfaces/repo: validate slot/plug names <Created by stolowski> <https://github.com/snapcore/snapd/pull/2932> | 14:48 |
| zyga | niemeyer_: FYI ^ | 14:48 |
| niemeyer_ | zyga: Ouch | 14:49 |
| zyga | niemeyer_: I marked https://github.com/snapcore/snapd/pull/2932 as blocked | 14:50 |
| mup | PR snapd#2932: interfaces/repo: validate slot/plug names <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/2932> | 14:50 |
| === Guest94845 is now known as brunorf | ||
| brunorf | hello everybody | 14:59 |
| brunorf | I would like to expose many commands on an snap package | 15:00 |
| zyga | brunorf: you already can | 15:00 |
| brunorf | Do I need to create one by one? | 15:00 |
| zyga | brunorf: if you want to explose multiple top-level commands (not prefixed by your snap name) | 15:00 |
| zyga | brunorf: you want to look at the new aliases v2 specification on the forum | 15:00 |
| brunorf | ok | 15:01 |
| brunorf | I will check it | 15:01 |
| brunorf | I just like to have myapp.mycommands | 15:01 |
| brunorf | but there are more than 50 commands | 15:01 |
| zyga | brunorf: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18 | 15:01 |
| zyga | brunorf: in that case just spell them out one by one | 15:02 |
| brunorf | ok | 15:02 |
| brunorf | thank you very much | 15:02 |
| zyga | mvo: ok, fix is ready, pushing | 15:05 |
| mvo | zyga: nice, thank you | 15:06 |
| niemeyer_ | Lunch, biab | 15:06 |
| zyga | mvo: but we need a plan to fix this | 15:07 |
| mvo | zyga: we added the network-client to the core snap directly. another option would be to add network-bind directly to core-support | 15:08 |
| mvo | zyga: because core-support already is uniq and only used in core | 15:08 |
| mvo | zyga: then the core snap only has a single interface and that is uniq to core | 15:08 |
| zyga | mvo: can you please have a look | 15:08 |
| zyga | mvo: I think we just need to rename the plugs on core | 15:09 |
| zyga | mvo: e.g. core:network-bind core:internal-network-bind | 15:09 |
| zyga | mvo: core:core-support core:internal-core-support | 15:09 |
| zyga | mvo: anyway, please review the code at https://github.com/snapcore/snapd/pull/3145 (maybe patch-by-patcH) | 15:10 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 15:10 |
| mvo | zyga: so core even without the transition has duplicated slot/plug names? is that what you are saying? | 15:13 |
| Chipaca | brunorf— is that a problem? | 15:14 |
| Chipaca | brunorf— at 50+ i'd expect you have some sort of a makefile, and you can generate the yaml from there | 15:15 |
| zyga | mvo, niemeyer_: https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184 | 15:15 |
| zyga | mvo: yes | 15:15 |
| zyga | mvo: there are separare issues here | 15:15 |
| zyga | mvo: the core transition is *not* related to duplicated plug/slot names in core | 15:16 |
| mvo | zyga: aha, ok. sorry, that confused me for a sec | 15:19 |
| zyga | mvo: tha's all right, I tried to summarize it at the forum | 15:19 |
| zyga | (on the forum?) | 15:19 |
| morphis_ | zyga, mvo, fgimenez: can I skip the repack step for spread somehow? seems to take ages | 15:20 |
| mvo | zyga: heh, a good question - I guess historally "on the forum" as it was a physical place. but *shrug* :) | 15:20 |
| zyga | morphis_: repack? | 15:20 |
| zyga | mvo: hehe, yes, quite curious evolution here :) | 15:20 |
| mvo | morphis_: repacking the core snap? we have something that should make it quicker by not using xz but gzip in the tests | 15:21 |
| ogra_ | zyga, forumwards! | 15:21 |
| zyga | ogra_: you should look at that post too | 15:21 |
| morphis_ | zyga, mvo: there is a repack step in spread.yaml | 15:21 |
| zyga | ogra_: it's the core snap | 15:21 |
| morphis_ | which generates some kind of delta of the project path | 15:21 |
| ogra_ | zyga, yes, read it already | 15:21 |
| ogra_ | zyga, but you are doing evil things like mangling snap.yaml | 15:22 |
| zyga | ogra_: I'm open to removing that mangling | 15:22 |
| zyga | ogra_: but it would introduce another hop between adding an interface and being able to do testing on it | 15:22 |
| zyga | ogra_: so that's why we have it | 15:22 |
| zyga | ogra_: but I agree it is tricky | 15:22 |
| mup | PR core#31 closed: Fix pi config and add new options <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/31> | 15:22 |
| mup | PR snapd#3142 closed: daemon: Give the snap directories via GET /v2/system-info <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3142> | 15:24 |
| fgimenez | morphis_: it shouldn't take too long, maybe you have large files in the project's directory? | 15:25 |
| morphis_ | fgimenez: right, I have some in there .. | 15:25 |
| morphis_ | my bad | 15:25 |
| mvo | pstolowski: 3070 is failing tests, could you have a look please? | 15:26 |
| fgimenez | morphis_: np :) | 15:26 |
| pstolowski | mvo, sure | 15:26 |
| morphis_ | fgimenez: typpical user error :-) | 15:27 |
| mup | PR snapcraft#1238 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1238> | 15:28 |
| pstolowski | mvo, unit/gccgo and unit/go fail, doesn't look related to changes in the PR | 15:29 |
| fgimenez | morphis_: yup i've hit that one more than once :) | 15:30 |
| pstolowski | mvo, let me merge master and see what happens | 15:30 |
| morphis_ | hehe | 15:30 |
| mvo | pstolowski: ta, master should be in good shape currently so fingers crossed | 15:31 |
| Chipaca | i was needing this the other day: https://making.pusher.com/go-tool-trace/ | 15:34 |
| zyga | mvo: I'll take a break afther the current call, ping me if you need me for anything for 2.24 | 15:34 |
| mvo | zyga: I think your branch just needs a second review. its the last critical one for 2.24 | 15:35 |
| mvo | zyga: but I will have dinner soon too | 15:36 |
| mikeb_ | Hi. I'm using python-daemon package to daemonize a python command. I'm trying to use it as an app: in snapcraft with a daemon type of forking. When I install the snap, I see the daemon running, but the installation of the snap never finishes - it looks like it's blocked waiting for something from the daemon. What else do I need to do in my daemon? | 16:04 |
| zyga | mikeb_: aha | 16:09 |
| zyga | mikeb_: can you report that, add a trivial example if you can | 16:09 |
| zyga | mikeb_: may be an interesting interaction with snap-confine, not sure | 16:09 |
| zyga | mikeb_: open a new topic on the forum.snapcraft.io please | 16:10 |
| mikeb_ | Sure - by report - do you mean launchpad bug or just a forum post? | 16:10 |
| zyga | mikeb_: a forum post first | 16:11 |
| zyga | mikeb_: it has better interactivity features | 16:11 |
| mikeb_ | Will do. Thanks! | 16:11 |
| zyga | mikeb_: my quick theory is that snap-confine forks to setup the mount namspeace (just once per reboot per snap) and this confuses systemd | 16:11 |
| zyga | mikeb_: thanks | 16:11 |
| zyga | mikeb_: I'll check that out tomorrow, please add this discussion there (quote it please) | 16:12 |
| zyga | mvo: I think we will do 2.24 tomorrow | 16:14 |
| zyga | mvo: there's a few more things that we need to fix | 16:14 |
| zyga | mvo: check out gustavo's post https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/5 | 16:14 |
| zyga | mvo: I can pick that up first thing tomorrow but I must leave now | 16:14 |
| === niemeyer_ is now known as niemeyer | ||
| niemeyer | mvo: I'm afraid 2.24 is something for next week | 16:26 |
| niemeyer | mvo: These plug/slot issues need some careful investigation | 16:26 |
| niemeyer | mvo: I have commented in the forum and also reviewed the related PRs | 16:26 |
| mup | PR snapd#2932 closed: interfaces/repo: validate slot/plug names <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2932> | 16:31 |
| pstolowski | ty niemeyer | 16:31 |
| niemeyer | pstolowski: np, thanks for the fix! | 16:34 |
| niemeyer | This was sitting there for a bit too long | 16:34 |
| zyga | niemeyer, mvo: updated https://github.com/snapcore/snapd/pull/3145 | 16:55 |
| mup | PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145> | 16:55 |
| mup | PR snapcraft#1239 opened: catkin plugin: create completely valid environment <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1239> | 17:35 |
| mvo | niemeyer, zyga thanks for this update, I will update the release page | 18:05 |
| Chipaca | huh | 18:13 |
| Chipaca | how did this ever work | 18:13 |
| sergiusens | jdstrand: hey, mind looking at telegram-sergiusens from edge and tell me why I can't see /usr/local/bin ? | 18:15 |
| sergiusens | zyga: or if you have some time? ^ | 18:16 |
| jdstrand | sergiusens: what release? | 18:16 |
| jdstrand | sergiusens: 16.04 classic? zesty? something else? | 18:18 |
| sergiusens | jdstrand: I am on zesty | 18:21 |
| jdstrand | sergiusens: ok, let me see | 18:21 |
| sergiusens | jdstrand: I get permission denied for anything out of that path, but other snaps have xdg-open working (which means they can access /usr/local/bin I guess) | 18:22 |
| sergiusens | thanks! | 18:24 |
| jdstrand | sergiusens: I guess you are concerned about a snapd-xdg-open scenario? | 18:38 |
| jdstrand | sergiusens: if I launch it, click Get Started and then click Settings and 'Telegram FAQ' it is reaching out to dbus but dying before any access is tried | 18:39 |
| jdstrand | sergiusens: dbus-send: /snap/telegram-sergiusens/28/lib/x86_64-linux-gnu/libdbus-1.so.3: version `LIBDBUS_PRIVATE_1.10.6' not found (required by dbus-send) | 18:40 |
| jdstrand | sergiusens: is there something else I should try? | 18:42 |
| mup | PR snapcraft#1240 opened: cli: improve push output <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1240> | 18:47 |
| pedronis | Chipaca: ? | 18:51 |
| Chipaca | pedronis— ? <- ? | 18:51 |
| Chipaca | ah! | 18:51 |
| pedronis | Chipaca: cp problems? | 18:51 |
| Chipaca | we were setting up the for-testing core by doing “cp /usr/lib/snapd/snap-confine squashfs-root/usr/lib/snapd” | 18:52 |
| Chipaca | which drops the setuid bit | 18:52 |
| pedronis | Chipaca: --preserve=mode should be the default and we run as root | 18:52 |
| mvo | Chipaca: pretty sure one of my branches fixes that | 18:52 |
| Chipaca | mvo— heh | 18:52 |
| mvo | iirc the 3027 | 18:53 |
| Chipaca | mvo— fixed it in my branch too :-) (because i also changed that bit) | 18:53 |
| pedronis | how did it ever work then? | 18:53 |
| pedronis | the cp docs are lying? | 18:54 |
| mvo | pedronis: its only done this way in the classic prepare | 18:54 |
| pedronis | ah | 18:54 |
| mvo | pedronis: the ubuntu core tests use dpkg-deb -x which preserves all the attributes | 18:54 |
| mvo | pedronis: and because we don't (yet) run snap-confine from the core snap we did not notice | 18:54 |
| pedronis | so it wasn't an issue because we weren't using snap-confine from core | 18:54 |
| mvo | correct | 18:55 |
| pedronis | ok, so cp docs a re a bit misleading :/ | 18:57 |
| pedronis | fwiw | 18:57 |
| davidcalle | mvo or ogra_ (if you are still there), do you know how these images are updated? http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ I flashed the pi3 image today and it was not on the latest stable core rev | 18:58 |
| mvo | davidcalle: cdimage is handled by steve nowdays | 18:58 |
| davidcalle | slangasek: hey ^ | 18:59 |
| davidcalle | Thanks mvo | 18:59 |
| pedronis | Chipaca: anyway I would go with -a as mvo branch does | 18:59 |
| mvo | -a ftw! | 18:59 |
| mvo | (what was Chipaca using?) | 19:00 |
| pedronis | just --preserve=mode | 19:00 |
| pedronis | which confused me | 19:00 |
| pedronis | because in theory that's part of the default | 19:00 |
| pedronis | as I said man cp doesn't say a lot about setuid | 19:00 |
| slangasek | davidcalle, mvo: hi, which rev are we expecting here? We spin the images when I know that there's a new rev of core to update to | 19:01 |
| pedronis | ah, maybe I'm reading it wrong | 19:01 |
| mvo | slangasek: I don't know, I'm just the proxy here :) | 19:01 |
| slangasek | mvo: sure - has there been a new core snap published since Mar 16? | 19:02 |
| davidcalle | slangasek: I don't have the rev at hand (was wondering about the process mostly) but I'll come back with it :) | 19:02 |
| slangasek | ok | 19:02 |
| pedronis | mvo: Chipaca: I was reading the doc wrongs, what they mean is that cp --preserve === cp --preserve=mode,ownership,timestamps | 19:02 |
| slangasek | I don't have any tooling here to detect that there's been a new rev of the core snap, so I'm at this point still dependent on someone giving me a heads up that one is published to stable | 19:02 |
| slangasek | I know that in principle we want to build these every two weeks, but without a trigger I'm at risk of building them before the new snap is available on the channel, so.. | 19:04 |
| davidcalle | slangasek: yeah, makes sense | 19:04 |
| mvo | davidcalle: rev of the pi2 for stable is 1580 - is that the one you are looking for? | 19:04 |
| mvo | slangasek: there was a handoff in the process, the stable promotion is now done by JamieBennett, I guess we need to add "notify steve to build new images for cdimage" to the stable release checklist he is using :) | 19:05 |
| slangasek | mvo: aha :) | 19:05 |
| JamieBennett | slangasek: mvo: Oh, I thought they were automatically built on new revisions? | 19:06 |
| slangasek | JamieBennett: no, I have no tooling to detect new revisions | 19:06 |
| slangasek | JamieBennett: so for the moment, if you can let me know when there are publications to either candidate or stable, that would be a big help | 19:06 |
| JamieBennett | slangasek: OK, maybe something to investigate for the future then. Will prod you on new versions. | 19:06 |
| slangasek | thanks | 19:07 |
| slangasek | I guess currently I should be spinning updates to both candidate and stable, then? | 19:07 |
| davidcalle | slangasek: mbo: the pi3 (fresh image from above) started on 1443, then refreshed to 1580 | 19:08 |
| JamieBennett | slangasek: stable now, candidate when 2.24 has been validated in beta by fginther | 19:08 |
| davidcalle | mvo* | 19:08 |
| slangasek | ok | 19:08 |
| JamieBennett | sorry fginther meant Federico | 19:08 |
| mvo | davidcalle: correct | 19:08 |
| davidcalle | Since I have the pi3 booted, is there anything odd in these changes ? changes 1 and 3 are missing | 19:10 |
| davidcalle | https://www.irccloud.com/pastebin/e4lFhjVJ/ | 19:11 |
| === foli_ is now known as foli | ||
| sergiusens | jdstrand: interesting, if I `snap run --shell telegram-sergiusens.telegram` I cannot ls or cd to /usr/local/bin; is that the way it is supposed to be? | 19:12 |
| davidcalle | (refresh of core to 1580 happened in 1 or 3, i still see it in list --all) | 19:12 |
| jdstrand | sergiusens: the ls is correct, the cd is not (ie, you can't ls but can cd) | 19:16 |
| jdstrand | sergiusens: confirmed locally. I suspect with the cd you are maybe trying to do tab completion? | 19:17 |
| jdstrand | sergiusens: (and by confirmed, I mean it is operating how I described, which is intentional) | 19:18 |
| sergiusens | jdstrand: ah, thanks for the help, that lib error is going to help me sort it out | 19:22 |
| coreycb | sergiusens, for that python import issue you couldn't recreate, are you using the daily snapcraft ppa by any chance? | 19:24 |
| sergiusens | coreycb: no, I am using the snapcraft snap, why? The daily ppa is not meant for users, not even built daily | 19:27 |
| sergiusens | coreycb: that said, the snapcraft snap is almost identical to the deb | 19:27 |
| sergiusens | hmm, but I did build on zesty, maybe there's something to that | 19:28 |
| coreycb | sergiusens, ok i'm using the 2.28+17.04 deb on zesty | 19:28 |
| mvo | niemeyer: I think 3027 is ready for a re-review - but not urgent if we need to delay 2.24 anyway | 19:33 |
| niemeyer | mvo: Looking | 19:34 |
| niemeyer | mvo, pedronis: How're doing in terms of test timing? | 19:34 |
| niemeyer | Are we blowing the limit regularly due to the move of unit tests in still> | 19:34 |
| niemeyer | ? | 19:34 |
| coreycb | sergiusens, is the snapcraft snap in the store? i can give that a try. | 19:47 |
| sergiusens | coreycb: snap install snapcraft --edge --classic | 19:50 |
| sergiusens | only on edge as you can see | 19:50 |
| coreycb | sergiusens, ok thanks | 19:52 |
| pedronis | niemeyer: my current PRs in the end passed their tests, haven't been looking a lot about that for PRs I have been reviewing | 20:15 |
| niemeyer | pedronis: Ok, let me know if you see news about this please | 20:18 |
| mup | PR snapcraft#1241 opened: help: replace dashes with underscores when printing plugins help <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1241> | 20:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
