| stormmore | ok what I am missing, I am trying to creatte a classic snap. it builds but after I install it using --classic --dangerous and try and run the command it keeps getting unable to allocate memory errors after hanging for a while? | 01:42 |
|---|---|---|
| mup | PR snapd#3819 closed: hooks: do not error when hook handler is not registered (2.27) <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3819> | 02:49 |
| mup | PR snapcraft#1515 opened: tests: use a fake pip, instead of mocking everything <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1515> | 05:26 |
| mvo | mwhudson: so I checked and it looks like x/crypto/ssh/terminal brings in x/sys/unix - for 2.28 I need to find a way to make this build again on powerpc. I will poke a bit to see what can be done | 05:51 |
| mup | PR snapd#3822 opened: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3822> | 06:48 |
| zyga-suse | good morning, sorry for a late start, had some woes with kids | 08:02 |
| zyga-suse | mvo: I saw some concenring test failures again | 08:08 |
| zyga-suse | mvo: I assumed it was caused by my branch but then it failed only partially, | 08:09 |
| mvo | zyga-suse: what failures are those? | 08:10 |
| zyga-suse | mvo: if you look at https://github.com/snapcore/snapd/pull/3621 you will see that upgrade/basic failed with Run install hook of "core" snap if present (internal error: no registered handlers for hook "install") | 08:10 |
| mup | PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 08:10 |
| zyga-suse | the latest rebuild didn't fail this way | 08:10 |
| zyga-suse | the log is in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170828_165347_9cd1b@/log.gz | 08:10 |
| zyga-suse | I'm worried there's still a race somewhere that we don't handle | 08:11 |
| zyga-suse | I'll look at the code there and try to figure out what must happen for this to show up | 08:12 |
| mvo | zyga-suse: it seems like 3816 has not landed yet, so seening this error seems to be ok still. or am i missing something? | 08:12 |
| mvo | zyga-suse: but yeah, please do go ahead | 08:12 |
| mvo | zyga-suse: and see if you can find out more | 08:12 |
| zyga-suse | mvo: not sure if this is really related, | 08:13 |
| mvo | ok | 08:13 |
| zyga-suse | that PR was to fix rollback/downgrades | 08:13 |
| zyga-suse | here we fail on upgrade | 08:13 |
| zyga-suse | so I suspect the mechanism of the failure is different | 08:13 |
| Chipaca | woo! go tyhicks | 08:22 |
| zyga-suse | hey Chipaca :) | 08:23 |
| zyga-suse | what is that about? | 08:23 |
| Chipaca | zyga-suse: recent seccomp efforts coming together | 08:24 |
| zyga-suse | ah, indeed | 08:24 |
| pedronis | zyga-suse: as far has me know that happend when changelog has the wrong version, so reexec doesn't work | 08:24 |
| pedronis | s/has me/as we/ | 08:25 |
| zyga-suse | pedronis: ah! perhaps that may explain it, I merged master later on | 08:25 |
| zyga-suse | thank you! | 08:25 |
| mvo | Chipaca: hey, good morning! | 08:31 |
| mvo | Chipaca: would love to get your advice on 3815 - but ready when you are :) | 08:32 |
| mup | PR snapd#3816 closed: hooks: do not error out when hook is optional and no hook handler is registered <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3816> | 08:39 |
| mup | PR snapd#3750 closed: snapstate: integration test for undoing a daemon restart on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3750> | 08:41 |
| mvo | mwhudson, pedronis: the powerpc build failure (because of the crypto update) should be fixed with 3822 - slightly ugly though | 08:42 |
| Chipaca | mvo: so... on core, source complexion.sh from /etc/skel/.bashrc ? | 08:45 |
| Chipaca | completion.sh i mean | 08:45 |
| mvo | Chipaca: yeah, that might be an option, will not help with exiting installs, but otherwise nice and simple | 08:45 |
| mvo | Chipaca: does the PR look otherwise ok? if it does I would love to see it merged as it blocks a lxd test | 08:46 |
| pedronis | Chipaca: hi | 08:47 |
| Chipaca | mvo: me, I would've done it differently, but it's fine as it is | 08:47 |
| pstolowski | mvo, hey, 3773 has a conflict | 08:47 |
| Chipaca | mvo: I mean, I would've looked at having osutil.IsWritable(dirs.CompletersDir) or somesuch | 08:47 |
| mvo | Chipaca: happy to do it differently, what would be your approach? | 08:47 |
| mvo | Chipaca: aha, even better, yeah, let me do that | 08:48 |
| Chipaca | mvo: but that is more work :-) | 08:48 |
| mvo | pstolowski: thanks, checking | 08:48 |
| mvo | Chipaca: thats fine if quality(more_work) > quality(less_work) :) | 08:48 |
| Chipaca | mvo: but if that existed, then noCompletion := !osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompleteSh) | 08:49 |
| Chipaca | mvo: and the rest stays unchanged | 08:49 |
| mvo | Chipaca: indeed, I will tweak | 08:49 |
| mvo | Chipaca: do you think we should rename "complexion" to "test-snapd-complexion" or just ignore that for now? | 08:49 |
| zyga-suse | hopefully back | 08:50 |
| zyga-suse | I learned that the new mac randomization thing doesn't love me | 08:50 |
| Chipaca | mvo: if it goes to the store, it needs renaming | 08:50 |
| mvo | zyga-suse: fwiw, I looked into the mount issue that lxd reported yesterday and it looks like real work (not just change two lines) :/ | 08:50 |
| Chipaca | mvo: if it doesn't go to the store i don't care :-) | 08:50 |
| mvo | Chipaca: I think I could tweak things so that it does not have to go through the store | 08:50 |
| mvo | Chipaca: I have a look | 08:50 |
| Chipaca | mvo: ah, i see it's already in the store? | 08:50 |
| zyga-suse | mvo: I came to the same conclusion | 08:51 |
| zyga-suse | mvo: I plan on working on that today | 08:51 |
| mvo | Chipaca: yes, but we can unpublish it again | 08:51 |
| Chipaca | mvo: if /tests/lib/snaps/complexion and test-snapd-complexion are the same thing, then yes let's rename the former | 08:51 |
| mvo | Chipaca: they are - ok, that works for me, I will tweak the branch | 08:51 |
| Chipaca | ok | 08:51 |
| Chipaca | pedronis: i know my pr has a conflict, but i'm also slight blocked waiting for a store issue so i'm in no hurry to deconflict it right now | 08:52 |
| Chipaca | as if that landed some people might panic | 08:52 |
| Chipaca | maybe i should label it | 08:52 |
| Chipaca | first coffee, then label | 08:52 |
| * Chipaca goes | 08:52 | |
| mvo | zyga-suse: do you have a plan yet? it seems like we may need to get back and add a "WantedBy=local-fs-pre.target" with a special "snap-confine ensure-shared-mounts" (or snap-helper or somesuch). or what do you have in mind? | 08:54 |
| zyga-suse | no plans yet, I'm still hoping we can do this somehow from snap-confine alone | 08:54 |
| zyga-suse | even if it requires more wokr | 08:54 |
| mvo | zyga-suse: AIUI the problem is that systemd itself will load all the mount units at the same time (or before) it starts the daemons. so when snap-confine runs and fixes the /, /snap rshare thing stuff is already mounted there and that causes the havoc | 08:55 |
| mvo | zyga-suse: so AFAICS we need to tweak the system boot ordering to make sure the remount happens earlier | 08:56 |
| mvo | pstolowski: 3773 is de-conflicted | 08:57 |
| zyga-suse | mvo: remember that snap-confine can remount anything inside its namespace so ... well, I need to look really | 08:57 |
| pstolowski | mvo, thx! | 08:57 |
| mvo | zyga-suse: ok | 08:57 |
| * zyga-suse fights his network plan | 09:03 | |
| pedronis | Chipaca: let's mark it blocked then | 09:04 |
| * zyga-suse wonders if anyone wants to review https://github.com/snapcore/snapd/pull/3621 | 09:08 | |
| mup | PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 09:08 |
| zyga-suse | mvo: ^ that's my top priority for 2.28 feature | 09:08 |
| zyga-suse | just to see if it breaks people | 09:08 |
| mvo | zyga-suse: I would prefer the https://discuss.linuxcontainers.org/t/snapd-cant-remove-old-revisions-when-running-inside-lxd/452/3 fix first | 09:09 |
| zyga-suse | mvo: sure but 3621 doesn't need any work from me anymore | 09:10 |
| mvo | zyga-suse: aha, cool | 09:10 |
| zyga-suse | mvo: as I said I'm working on that, I only meant that that review is my only one that counts for 2.28 so far | 09:10 |
| mvo | zyga-suse: aha, I see. this is the thing you taged for 2.28, thats fine | 09:14 |
| zyga-suse | yes | 09:14 |
| mup | PR snapd#3818 closed: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818> | 09:25 |
| pedronis | 3621 needs a jdstrand review though | 09:26 |
| mvo | zyga-suse: do you think we need input from jdstrand for 3818 ? | 09:27 |
| zyga-suse | hmmm, sorry, perhaps yes | 09:29 |
| zyga-suse | I was closing my tabs and I saw 2+1's | 09:29 |
| zyga-suse | and since this affects all plugs, it's something we should still ask jamie about | 09:29 |
| mvo | zyga-suse: no worries, lets just make sure we do not release before he had a chance to weight in :) | 09:29 |
| zyga-suse | +1 | 09:29 |
| * zyga-suse is fed up with the network, wants to call it quits and have a walk | 09:30 | |
| zyga-suse | I was trying to git push/pull for the past ten minutes | 09:30 |
| pedronis | mvo: what's the state of snapd#3625 ? at least one of the snapcraft PRs it mentions isn't merged yet | 09:30 |
| mup | PR snapd#3625: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625> | 09:30 |
| pedronis | is it blocked? | 09:30 |
| mvo | pedronis: yes, it is blocked right now :/ | 09:31 |
| zyga-suse | mvo: do we need any design for that | 09:31 |
| zyga-suse | mvo: or just some coding? | 09:31 |
| zyga-suse | it would be great if 2.28 had _a_ level of base snap support | 09:31 |
| pedronis | you are getting ambitious there | 09:33 |
| pedronis | Chipaca: do you plan to still do something in snapd#3398 ? | 09:33 |
| mup | PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398> | 09:33 |
| pedronis | it seems unclear if it needs more work OTOH it has 2 +1 | 09:33 |
| mvo | zyga-suse: with 3625 we would have basic support, the snapcraft stuff is only needed for specialized tests, I can make simpler tests | 09:34 |
| zyga-suse | mvo: not sure if priority, just saying it would be nice | 09:34 |
| mvo | zyga-suse: I think the two of us need to agree on how snap-confine should handle bases :) then this is good to go, I would love to have it for 2.28 as well and it seems like we are close | 09:34 |
| zyga-suse | ok, let's try to discuss this in 2-3 hours | 09:34 |
| mvo | zyga-suse: sounds good! | 09:34 |
| mvo | pedronis: yeah, I will sort it out, if zyga and I can agree on snap-confine I will just write simpler tests for now until snapcraft is ready | 09:35 |
| mvo | zyga-suse: welcome back | 09:35 |
| mvo | zyga-suse: in 2-3h sounds good | 09:35 |
| === JoshStrobl|Work is now known as JoshStrobl | ||
| zyga-suse | mvo: it will likely be an IRC/telgram audio call | 09:35 |
| mvo | zyga-suse: sure | 09:36 |
| pedronis | what should happen with snapd#3617 ? | 09:36 |
| mup | PR snapd#3617: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617> | 09:36 |
| pedronis | it's marked for 2.28 | 09:36 |
| mvo | zyga-suse: I know your bandwidth is limited currently, we can just discuss by typing | 09:37 |
| mvo | pedronis: wasn't it just one extra change that needed backing out, otherwise it was ok? if so, I guess I could do that | 09:37 |
| pedronis | I don't know, I suppose zyga knows | 09:40 |
| pedronis | it says to remove the opengl stuff | 09:41 |
| zyga-suse | hmm? opengl stuff | 09:46 |
| zyga-suse | ah | 09:47 |
| zyga-suse | I see | 09:47 |
| zyga-suse | let me look at what needs doing on that PR | 09:47 |
| zyga-suse | it is a major change and bugfix for CE | 09:47 |
| zyga-suse | aha | 09:48 |
| pedronis | anyway lots of PRs needing jdstranda afaict | 09:51 |
| pedronis | Chipaca: did you see my question? | 09:53 |
| Chipaca | i did not | 09:53 |
| pedronis | Chipaca: do you plan to still do something in snapd#3398 ? | 09:53 |
| mup | PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398> | 09:53 |
| Chipaca | pedronis: working on it right now | 09:53 |
| pedronis | ah ok | 09:54 |
| Chipaca | i'm going to need zyga and morphis' help to test this, at least | 09:54 |
| Chipaca | but it should work :-) | 09:54 |
| * Chipaca shoves it at linode | 10:08 | |
| pedronis | mvo: I'm going to tentatively merge snapd#3697 | 10:09 |
| mup | PR snapd#3697: docs: add PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3697> | 10:09 |
| mvo | pedronis: ta! | 10:10 |
| mup | PR snapd#3697 closed: docs: add PULL_REQUEST_TEMPLATE.md <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3697> | 10:11 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mup | PR snapd#3823 opened: tests: rename complexion to test-snapd-complexion <Created by mvo5> <https://github.com/snapcore/snapd/pull/3823> | 10:23 |
| mup | PR snapcraft#1516 opened: lxd: LXD not installed when using remote <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1516> | 10:23 |
| mvo | Chipaca: 3815 is ready for you | 10:24 |
| mvo | Chipaca: but no rush, its lunchtime here I think | 10:24 |
| * Chipaca ~> break & lunch | 10:46 | |
| * zyga-suse_ considers taking today off | 10:59 | |
| mvo | zyga-suse_, pedronis: I updated/de-conflicted 3617, this should be ready to do in now (waiting for tests still). but it has two +1 and looks sensible overall | 11:05 |
| zyga-suse | mvo: I'm going to call it quits today | 11:08 |
| zyga-suse | I'm just frustrated | 11:08 |
| zyga-suse | trying to fix my network | 11:08 |
| zyga-suse | need to put my mind at ease | 11:08 |
| mup | PR snapd#3824 opened: Do not match any file or directory in or under /sys/bus/pci/devices/ <Created by adglkh> <https://github.com/snapcore/snapd/pull/3824> | 11:16 |
| mup | PR core#55 opened: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55> | 11:18 |
| === alan_g is now known as alan_g|lunch | ||
| Chipaca | mvo: install-store seems really unhappy in snapd#3815 | 12:29 |
| mup | PR snapd#3815: wrappers: ensure bash completion snaps install on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815> | 12:29 |
| === alan_g|lunch is now known as alan_g | ||
| Chipaca | mvo, morphis_, zyga-*, would appreciate your input on snapd#3398 | 12:50 |
| mup | PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Blocked> <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398> | 12:50 |
| jdstrand | mvo: re nmcli: trunk has 'socket AF_NETLINK - -', so does release/2.27 | 12:55 |
| jdstrand | mvo: if this is on 2.27, then something isn't regenerating the policy | 12:56 |
| pedronis | jdstrand: there's a branch for you to look at | 12:59 |
| pedronis | jdstrand: https://github.com/snapcore/snapd/pull/3818 | 12:59 |
| mup | PR snapd#3818: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818> | 12:59 |
| jdstrand | pedronis: ok | 12:59 |
| pedronis | it was merged a bit too quickly but as far I understood mvo is waiting on your feedback there | 13:00 |
| jdstrand | mvo: so, it looks like snap.network-manager.networkmanager.src has 'socket AF_NETLINK - -', but snap.network-manager.nmcli.src does not | 13:00 |
| jdstrand | mvo: let me check the plugs, hold on | 13:01 |
| jdstrand | mvo: ah, yes, only the networkManagerPermanentSlotSecComp has 'socket AF_NETLINK - -' | 13:01 |
| jdstrand | mvo: nmcli may need an AF_NETLINK rule | 13:02 |
| jdstrand | (weird, people tested that) | 13:02 |
| jdstrand | mvo: I'll look into it and send something up | 13:02 |
| jdstrand | oh, you sent it up | 13:03 |
| jdstrand | KOBJECT_UEVENT, yeah, that's fine | 13:03 |
| * jdstrand comments | 13:03 | |
| jdstrand | pedronis, mvo: +1d | 13:04 |
| jdstrand | mvo: thanks for looking into that | 13:04 |
| pedronis | Chipaca: mvo: snapd#3815 needs a master merge now ? | 13:32 |
| mup | PR snapd#3815: wrappers: ensure bash completion snaps install on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3815> | 13:32 |
| Chipaca | pedronis: yeah, that's what we said in the standup i think | 13:39 |
| Chipaca | niemeyer: may I be curious and ask how you generate the review sprint page? | 13:40 |
| niemeyer | Chipaca: Go application that talks to both APIs | 13:41 |
| Chipaca | niemeyer: sounds very credential-y | 13:42 |
| Chipaca | niemeyer: i might have formatting suggestions, but i'll create them by hand before suggesting we code them | 13:43 |
| niemeyer | Chipaca: Not too much.. luckily both ends have simplified versions of the full fledged auth that just requires a token | 13:43 |
| Chipaca | also, not now, now -> reviews | 13:43 |
| niemeyer | Chipaca: That's generally what I do too | 13:43 |
| niemeyer | Chipaca: (looking at them by hand first) | 13:43 |
| Chipaca | niemeyer: snapd#3398 is the pr i mentioned in the standup, btw | 13:44 |
| mup | PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398> | 13:44 |
| Chipaca | it _has_ two greens, but the conversation in the pr prompted the extra work | 13:44 |
| niemeyer | Chipaca: Thanks | 13:44 |
| mvo | pedronis: I do the master merge now | 13:47 |
| mvo | jdstrand: thanks a bunch | 13:47 |
| mvo | jdstrand: I will backport that to 2.27 now | 13:47 |
| ogra_ | popey, hmm ... didnt oyu once have a xonotic ansp (or do i mis-remember) | 13:52 |
| ogra_ | *snap | 13:52 |
| ogra_ | snap find doesnt reveal one | 13:52 |
| popey | yes | 13:52 |
| popey | not in the store, because it was too huge | 13:52 |
| popey | I didn't optimise the assets iirc | 13:53 |
| popey | not looked at it for a few months though., i think flexiondotorg has looked at it more recently than me, and had other issues | 13:53 |
| ogra_ | ah, is size an issue ? | 13:54 |
| ogra_ | (apart from taking long for uploads) | 13:54 |
| * popey pokes flexiondotorg | 13:54 | |
| * flexiondotorg feels a poke in ribs. | 13:54 | |
| popey | I was going for a headshot, but okay | 13:55 |
| flexiondotorg | Yep, I did start a Xonotic snap. | 13:55 |
| flexiondotorg | https://code.launchpad.net/~flexiondotorg/+junk/snap-xonotic | 13:55 |
| flexiondotorg | Haven't tested it recently. BUt last time I did there was no audio. | 13:55 |
| popey | oh that was it | 13:55 |
| ogra_ | ah | 13:56 |
| flexiondotorg | Could well be fixed now, I've not tested in ages. | 13:59 |
| ogra_ | well, i was just curious, thanks | 13:59 |
| * popey kicks off a build to see | 14:00 | |
| ogra_ | (i was pondering to package stage9 ... but it is 1.9G big so collecting some info about possible probs in advance) | 14:00 |
| mvo | Chipaca: 3398 looks great | 14:12 |
| Chipaca | mvo: just saw your comments; replying | 14:13 |
| mvo | a review for 3822 would be nice | 14:15 |
| mvo | Chipaca: my comments are mostly nitpick, I think this can go in | 14:15 |
| Chipaca | whoops, something is buggy in 3398 | 14:17 |
| Chipaca | tests failures look scary-real | 14:17 |
| niemeyer | Chipaca: Btw, on #3398, if there's extra work, the easiest way to make that clear is to just send another review saying Request Changes | 14:20 |
| niemeyer | Chipaca: This would put both GH and the board in the right state | 14:20 |
| niemeyer | mvo: Looking | 14:20 |
| niemeyer | Btw, just updated the board icons style.. seems much better now.. | 14:21 |
| niemeyer | Much easier to see the work | 14:21 |
| Chipaca | hmm, liked the grey blank box more than the questionmark, but otherwise it does seem clearer, yes | 14:22 |
| Chipaca | mvo: who groks the 14.04 delta? | 14:26 |
| mvo | Chipaca: nobody, code duplication == pain :/ | 14:26 |
| Chipaca | mvo: asking because I'd like to go over the diffs in rules and etc and make sure they're ok | 14:27 |
| mup | PR snapcraft#1513 closed: lifecycle: outdated step should raise SnapcraftError <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1513> | 14:30 |
| Chipaca | mvo: e.g. there's a block that re-sets VENDOR_ARGS in 14.04, that seems suspicious | 14:32 |
| Chipaca | in fact it looks like a whole block is dupe'd | 14:32 |
| Chipaca | mvo: i'll figure it out :-) | 14:33 |
| mvo | Chipaca: thank you, much appreciated | 14:33 |
| Chipaca | just a SMOP, and tea | 14:33 |
| mup | PR snapd#3822 closed: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3822> | 14:35 |
| mup | PR snapcraft#1505 closed: errors: introduce ContainerError <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1505> | 14:42 |
| mthaddon | hi folks - would this be the right place to ask about getting https://bugs.launchpad.net/snapd/+bug/1699768 backported to xenial? It's a dependency for some k8s charm work | 15:01 |
| mup | Bug #1699768: "snap set" causes snapd crash <snapd:Fix Released by stolowski> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1699768> | 15:01 |
| Riddell | https://blog.neon.kde.org/index.php/2017/08/29/great-web-browsing-coming-back-to-kde-with-falkon-new-packaging-formats-coming-to-kde-with-snap/ | 15:02 |
| === cachio is now known as cachio_lunch | ||
| mup | PR snapd#3815 closed: wrappers: ensure bash completion snaps install on core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3815> | 15:11 |
| Chipaca | mthaddon: xenial is what we ship to, so i'd assume it's getting backported | 15:14 |
| Chipaca | mthaddon: mvo might know more | 15:15 |
| Chipaca | mthaddon: also, hi :-) | 15:15 |
| mthaddon | Chipaca: o/ | 15:15 |
| Chipaca | Riddell: woo :-) | 15:15 |
| Chipaca | mvo: do you know if 14.04 needs/doesn't need --enable-static-libapparmor --enable-static-libseccomp? | 15:15 |
| niemeyer | pedronis: snapd#3616 has one review | 15:22 |
| mup | PR snapd#3616: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616> | 15:22 |
| niemeyer | Anyone up for a second one? | 15:22 |
| stormmore | ok back to figuring out why my hello world snap works fine until I change it to a classic snap! | 15:29 |
| ogra_ | boo, classic snaps :P | 15:30 |
| nacc | stormmore: what happens as a classic snap? | 15:31 |
| stormmore | nacc: I keep getting a unable to allocate memory type error | 15:31 |
| nacc | stormmore: can you pastebin the full output? | 15:32 |
| nacc | stormmore: and/or maybe strace it? | 15:32 |
| pedronis | niemeyer: thanks | 15:33 |
| niemeyer | stormmore: Logs might also help in some cases | 15:33 |
| niemeyer | stormmore: Ping jdstrand if you think it's something that the application is being blocked on | 15:33 |
| stormmore | nacc: give me a few to make sure I wasn't "imagining things" yesterday but sure... I started using the hello expample from the docs and the only thing I changed was the containment to classic | 15:33 |
| niemeyer | pedronis: np | 15:33 |
| niemeyer | Lunch, biab for more | 15:33 |
| stormmore | niemeyer: nacc: I suspect just a simple AppArmor problem but didn't get that far in troubleshooting | 15:34 |
| mvo | Chipaca: 14.04 does not need these static builds, we only need it for 16.04 and for the core snap | 15:38 |
| mvo | mthaddon: if you switch core to "candidate" this should work, we plan to release 2.27 on Monday | 15:38 |
| Chipaca | mvo: but 14.04 does need the static builds because of dependencies | 15:38 |
| mvo | Chipaca: oh, does it? in this case, ok | 15:38 |
| Chipaca | mvo: of libpcap | 15:38 |
| Chipaca | mvo: not of the other things | 15:38 |
| mthaddon | mvo: cool, thx | 15:39 |
| Chipaca | mvo: but, my question is, would you rather it weren't static? | 15:39 |
| mvo | Chipaca: either way is fine | 15:39 |
| Chipaca | mvo: that is: is it worth making the diff between the rules bigger? | 15:39 |
| mvo | Chipaca: I would like to keep the diff as small as possible :) | 15:39 |
| Chipaca | me too | 15:39 |
| Chipaca | mvo: i'd also like to know if we really need the override_dh_systemd_ blocks | 15:40 |
| mvo | Chipaca: yes, was wondering about that myself. wasn't it you who added it a *long* time ago :) ? | 15:40 |
| Chipaca | mvo: lies! | 15:41 |
| * Chipaca runs away | 15:41 | |
| Chipaca | mvo: i'll test that separately | 15:41 |
| Chipaca | too many changes would be baad | 15:42 |
| mvo | Chipaca: +1 | 15:43 |
| pedronis | Chipaca: you are working on the real failures in #3398 | 15:57 |
| pedronis | ? | 15:57 |
| Chipaca | pedronis: yes | 16:01 |
| pedronis | thx | 16:01 |
| stormmore | nacc: niemeyer: actually got a different error this time /smh - https://pastebin.canonical.com/197040/ is the output from the commands from snap creation to running hello | 16:03 |
| === cachio_lunch is now known as cachio | ||
| cachio | mvo, https://paste.ubuntu.com/25424909/ | 16:04 |
| nacc | stormmore: reading | 16:04 |
| cachio | mvo, I am trying to understand why this test is making the snapd service gives that error when it is stopped | 16:05 |
| cachio | mvo, any idea? | 16:05 |
| nacc | stormmore: my initial guess is a conflict between the go in your snap and the go on your system | 16:05 |
| nacc | stormmore: i'm not entirely sure how go works | 16:06 |
| mup | PR snapd#3825 opened: tests: add nmcli regression test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3825> | 16:06 |
| Chipaca | dpkg-architecture: error: DEB_TARGET_ARCH is not a supported variable name | 16:08 |
| Chipaca | hmmm | 16:08 |
| nacc | stormmore: although if you didn't use cleanbuild, i'm not sure, i guess it just uses the host to build | 16:08 |
| nacc | Chipaca: manpage says since 1.17.14 :) | 16:08 |
| Chipaca | mvo: how do you spell “dpkg-architecture -qDEB_TARGET_ARCH” in Ye Olde Trvsty? | 16:09 |
| Chipaca | nacc: maybe you know then ^ :-) | 16:09 |
| stormmore | nacc: not to mention the app is just the gnu-hello C package | 16:09 |
| nacc | stormmore: err, right :) but the backtrace is go something something :) | 16:11 |
| nacc | Chipaca: looking, i'm not sure off the top of my head | 16:11 |
| ogra_ | you dont happen to have a go "hello" in your path, do you ? :) | 16:11 |
| ogra_ | (overriding the snap) | 16:12 |
| nacc | Chipaca: still looking (spinning up a trusty env to see) | 16:15 |
| Chipaca | nacc: that's very kind of you, thanks! | 16:15 |
| Chipaca | maybe on trusty DEB_TARGET_ARCH would always be DEB_BUILD_ARCH? | 16:16 |
| mvo | Chipaca: -qDEB_HOST_ARCH probably but its not quite the same but should be close enough | 16:17 |
| mvo | Chipaca: let me know, I need to get dinner now but will read backlog | 16:17 |
| mvo | the lxd-test branch (3372) is GREEN for the first time evar I think :) | 16:18 |
| * mvo happy and & | 16:18 | |
| nacc | Chipaca: yeah HOST_ARCH is the closest thing that's documented, at least | 16:18 |
| nacc | Chipaca: it seems like TARGET_ARCH wsa introduced for exactly this problem :) | 16:18 |
| stormmore | nacc: ok strace hello showed an error about not being root! (running it as sudo strace hello right now filled my terminal backscroll so don't have the specifics right now) | 16:18 |
| Chipaca | i'm not sure target_arch is the one we wanted anyway | 16:19 |
| nacc | stormmore: ah yes, strace might need to be root | 16:19 |
| Chipaca | it says target is for when building cross-toolchain | 16:19 |
| nacc | stormmore: the strace would only have helped see what was giving back ENOMEM, but if you're not seeing that anymore, it's not likely to help | 16:19 |
| Chipaca | ie building something for running on A to build things for B | 16:19 |
| Chipaca | mvo: so, i'm going to change it to DEB_HOST_ARCH | 16:20 |
| stormmore | nacc: I forget that as I don't use it as much as I probably should ;-) | 16:20 |
| nacc | Chipaca: yeah, techincally you have 3 build, host and target | 16:20 |
| Chipaca | mvo: as trusty has that, and it's what we want | 16:20 |
| Chipaca | nacc: yup | 16:20 |
| nacc | Chipaca: agreed you shouldn't need target unelss you're building the cross-toolchain itself | 16:20 |
| Chipaca | as our thing is not a compiler, host == target anyway | 16:20 |
| Chipaca | exactly | 16:20 |
| nacc | Chipaca: yep | 16:20 |
| pedronis | I pushed review feedback to snapd#3616 which needs a 2nd review | 16:26 |
| mup | PR snapd#3616: cmd/snap-repair: check signatures of repairs from Next <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3616> | 16:26 |
| Chipaca | gaaah | 16:29 |
| * Chipaca shakes his fist at GNU coreutils | 16:30 | |
| cachio | Chipaca, any idea why this tests could be causing this? https://paste.ubuntu.com/25424909/ | 16:36 |
| Chipaca | cachio: I don't understand what I'm looking at, there | 16:37 |
| cachio | Chipaca, first is the test, then is the error that it is produced | 16:38 |
| Chipaca | cachio: but that error isn't in that code | 16:38 |
| Chipaca | cachio: that's in the prepare somewhere | 16:38 |
| cachio | the error is in the reset.sh | 16:38 |
| cachio | when it stops the service | 16:38 |
| cachio | on ubuntu 14 | 16:39 |
| stormmore | nacc: I am back at the original error with the sudo strace hello /smh - http://paste.ubuntu.com/25425936/ is a "chunk" of the strace inc the end | 16:39 |
| cachio | it is so sporadic | 16:39 |
| cachio | Chipaca, I can't reproduce it from local, I made a research on travis executions and there is a relation between the test regression/lp-1599891 and that failure | 16:40 |
| cachio | Chipaca, but I can't understand what it causing this | 16:40 |
| Chipaca | cachio: digging | 16:42 |
| Chipaca | cachio: question: can you look at the timers when this happens? | 16:44 |
| cachio | Chipaca, well, is is almost impossible to reproduce it for me | 16:44 |
| Chipaca | sigh | 16:44 |
| Chipaca | cachio: the thing that's returning an error is the 'systemctl stop', yes? | 16:45 |
| cachio | Chipaca, yes | 16:45 |
| Chipaca | cachio: the "job" that was canceled is the request to stop | 16:45 |
| cachio | yes | 16:45 |
| Chipaca | cachio: this might be a consequence of the previous daemon-reload | 16:45 |
| Chipaca | or not | 16:46 |
| Chipaca | i don't know | 16:46 |
| cachio | Chipaca, it could be | 16:46 |
| Chipaca | but, basically, you'd need to harden the code against this failure | 16:46 |
| cachio | it is really weird, it is just happening on trusty | 16:46 |
| Chipaca | not terribly surprised | 16:47 |
| Chipaca | cachio: how many times do you need to loop to reproduce one of these? | 16:47 |
| cachio | about 2000 | 16:47 |
| Chipaca | man | 16:47 |
| cachio | but in travis is happening more frecuently | 16:47 |
| Chipaca | cachio: how long does that take? | 16:47 |
| cachio | Chipaca, 2000 running from my local | 16:48 |
| cachio | Chipaca, I have a test made for that | 16:48 |
| cachio | it takes like 2 hours | 16:48 |
| Chipaca | cachio: one thing you _could_ try is to add a sleep between those two | 16:48 |
| cachio | perhaps more | 16:48 |
| Chipaca | on the other hand | 16:48 |
| Chipaca | why even do the daemon-reload if you're going to stop it | 16:48 |
| Chipaca | maybe do them in the other order: stop, then daemon-reload? | 16:48 |
| Chipaca | in fact | 16:49 |
| Chipaca | stop snapd | 16:49 |
| Chipaca | _then_ reset_classic | 16:49 |
| Chipaca | _then_ daemon-reload | 16:49 |
| Chipaca | … unless reset_classic uses snapd? | 16:49 |
| Chipaca | dunno :-) | 16:49 |
| cachio | Chipaca, ok, I'll try changing the order and see what happens | 16:51 |
| Chipaca | cachio: plan B would be to check for the error and try again | 16:51 |
| cachio | yes, in parallel I am doing that | 16:51 |
| Chipaca | cachio: it could be as easy as: while ! systemctl stop snapd\*; do sleep .1; done | 16:52 |
| cachio | Chipaca, i have an infinite look for this | 16:52 |
| Chipaca | or less hang-friendly, for i in {1..10}; do systemctl stop snapd\* && break; done | 16:52 |
| Chipaca | + a sleep in there somewhere | 16:52 |
| nacc | stormmore: oh a seccomp failure | 16:53 |
| cachio | Chipaca, running again | 16:54 |
| cachio | with a loop trying to force the errror | 16:54 |
| stormmore | nacc: yeah that is why I think I am doing something silly, trying a cleanbuild now and might even try upgrading my snap core to candidate | 16:59 |
| Chipaca | cachio, niemeyer, please don't forget to revisit snapd#3484 | 17:11 |
| mup | PR snapd#3484: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484> | 17:11 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| cachio | Chipaca, sure | 17:12 |
| Chipaca | mvo: snapd#3502 looks good, but I see there are changes requested by jdstrand that you claim to have implemented by i don't see (a newline, but also a long comment) | 17:14 |
| mup | PR snapd#3502: snap-seccomp: add more tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502> | 17:14 |
| niemeyer | Chipaca: Thanks, commented | 17:16 |
| Chipaca | mvo: does 14.04 have snapd-xdg-open? | 17:25 |
| Chipaca | looks like no | 17:26 |
| Chipaca | mvo: what's gbp.conf? | 17:29 |
| pedronis | Chipaca: where is that? | 17:37 |
| mvo | Chipaca: iirc we have no snapd-xdg-open in 14.04, we said 14.04 would be server side support | 17:46 |
| mvo | Chipaca: gbp.conf is git-build-package | 17:46 |
| Chipaca | mvo: i left those things alone for noe | 17:51 |
| Chipaca | now* | 17:51 |
| mvo | Chipaca: sounds good, thank you | 17:52 |
| Chipaca | mvo: but, “diff -urN ubuntu-14.04/ ubuntu-16.04/” FTW | 17:52 |
| Chipaca | lots of questions | 17:52 |
| Chipaca | mvo: e.g. the differing maintscripts | 17:52 |
| Chipaca | the breaks/replaces in 14.04 seem to have lagged (i bumped those -- let me know if it was wrong) | 17:53 |
| Chipaca | also the postrm script probably needs syncing again | 17:53 |
| mvo | I think 3617 is ready for merging, if someone wants to have a final look (maybe jdstrand?) thats welcome otherwise I will merge it later or in my morning | 17:53 |
| mvo | Chipaca: woah, thanks a lot. I can have a look at the diff/PR in my morning, really appreciated | 17:54 |
| mup | Issue snapcraft#1477 opened: multi-arch build packages <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1477> | 17:54 |
| Chipaca | mvo: with the upcoming debian-unstable work, keeping these things sane (and non-obvious differences documented) is going to be a must | 17:55 |
| mvo | Chipaca: indeed, I would love to brainstorm a bit if we can somehow merge/symlink way more of the common things, its a DRY desaster right now | 17:58 |
| mvo | Chipaca: anyway, your PR helps a lot already, thanks again | 17:58 |
| mvo | Chipaca: 3398 looks like a real winner, once tests are green, I would love to see it going in and we can further optimize the packaing in followup branches | 17:59 |
| mvo | looks like 3805 just needs a second review and can go in | 18:00 |
| jdstrand | mvo: commented. LGTM | 18:06 |
| mup | PR snapd#3826 opened: devices/iio: add read/write for missing sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3826> | 18:27 |
| stormmore | nacc: niemeyer: I think I have figured it out and it is pretty silly... I changed the command to use bin/hello in the snapcraft.yaml and it is working | 18:29 |
| niemeyer | Hmm.. the new lxd test in spread takes 2 to 3 minutes to run.. | 18:33 |
| mup | PR snapd#3372 closed: tests: add basic lxd test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3372> | 18:36 |
| * ikey grasses up onlyoffice https://twitter.com/only_office/status/902447739023368192 | 18:38 | |
| niemeyer | ikey: Fingers crossed :) | 18:42 |
| ikey | Yeah I'm not good with the whole subtlety thingy | 18:42 |
| ikey | lol | 18:42 |
| Chipaca | jdstrand: 3805 has a weird MockFindGid that isn't a mock and isn't in export_test.go, but other than that (and a couple of nits) it's good to go | 18:44 |
| jdstrand | Chipaca: thanks. I was havig some trouble using findGid from the _test.go file and based this on something else in the tree | 18:45 |
| Chipaca | jdstrand: usually you'd have an export_test.go | 18:46 |
| Chipaca | jdstrand: and that would be in the main package, not in the _test package | 18:46 |
| Chipaca | jdstrand: but as it's called _test it only gets built for tests | 18:46 |
| Chipaca | jdstrand: so in there you'd do, simply, “var FindGid = findGid” | 18:46 |
| Chipaca | jdstrand: and then in that package's tests thepackage.FindGid(...) and it'd DWYW | 18:47 |
| niemeyer | cachio: Are you taking over snapd#3484 from fgimenez, or do we expect him to be on that tomorrow? | 18:49 |
| mup | PR snapd#3484: tests: add autopilot-introspection interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3484> | 18:49 |
| cachio | niemeyer, he said he was going to finish this one tomorrow | 18:50 |
| cachio | otherwise, I'll take it | 18:50 |
| cachio | niemeyer, federico is working until the 31st | 18:51 |
| niemeyer | cachio: Sounds great, thanks | 18:53 |
| cachio | niemeyer, I'll sync with him tomorrow again | 18:54 |
| jdstrand | Chipaca: ok, let me play with that. thanks! | 18:56 |
| Chipaca | jdstrand: you can look at release/export_test.go's ReadOSRelease as an example | 18:58 |
| Chipaca | niemeyer: getting html back from linode again | 18:58 |
| niemeyer | /o\ | 18:59 |
| Chipaca | niemeyer: more like <o/> | 19:02 |
| Chipaca | it seems to have fixed itself though | 19:03 |
| jdstrand | Chipaca: huh, that was easy. I thought I tried this and it didn't work... | 19:06 |
| * jdstrand shrugs | 19:06 | |
| jdstrand | Chipaca: thanks! | 19:06 |
| mup | PR snapd#3617 closed: interfaces/builtin: use udev tagging more broadly <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3617> | 19:12 |
| mvo | Chipaca: the issue with 3398 is that snapd.install needs a directory as the second argument, there is a file there right now. check man dh_install and sorry that I have not spoted that earlier :/ | 19:15 |
| mvo | Chipaca: at the end of the man-page there is a suggestion about renames though | 19:17 |
| jdstrand | roadmr: hi! can you give me the output of https://dashboard.snapcraft.io/dev/snaps/8252/rev/12/ ? | 19:34 |
| jdstrand | roadmr: it says unexpected output | 19:34 |
| jdstrand | (in the store) | 19:34 |
| roadmr | jdstrand: sure! | 19:34 |
| roadmr | jdstrand: found it will just be a sec | 19:40 |
| roadmr | jdstrand: https://pastebin.canonical.com/197058/ | 19:41 |
| jdstrand | hmm, that's curious | 19:42 |
| jdstrand | roadmr: thanks | 19:42 |
| jdstrand | roadmr: do you happen to know when that review started and when it completed? | 19:44 |
| roadmr | jdstrand: completed at 15:33:12.756 | 19:45 |
| roadmr | trying to get the start timestamp | 19:46 |
| jdstrand | kenvandine: can you press the 'request manual review' button here: https://dashboard.snapcraft.io/dev/snaps/8252/rev/12/ | 19:46 |
| kenvandine | jdstrand, sure | 19:47 |
| kenvandine | jdstrand, button pushed :) | 19:47 |
| jdstrand | kenvandine: thanks | 19:49 |
| roadmr | jdstrand: the scan started at 15:33:11.785 | 19:50 |
| jdstrand | roadmr: that is weird and likely unrelated to the reaping code | 19:51 |
| jdstrand | roadmr: have you seen any other 'unexpected output' since r922 went out? | 19:51 |
| roadmr | jdstrand: what's weird? | 19:51 |
| mup | PR snapcraft#1509 closed: project_loader: process stage package grammar <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1509> | 19:51 |
| jdstrand | roadmr: that snap has that file. the fact that it is gone made me think something came along and removed the review directory | 19:52 |
| roadmr | jdstrand: hm... indeed | 19:52 |
| jdstrand | roadmr: (ie, lingering reaping bug), but i don't think so based on the timestamps. I'll re-review that code to be sure | 19:52 |
| roadmr | jdstrand: the last instance of "os.rmdir(dirPath) FileNotFoundError: [Errno 2] No such file or directory: | 19:53 |
| jdstrand | roadmr: there aren't any fs errors on that machine, are there? | 19:53 |
| roadmr | jdstrand: was from Aug 23rd, and no "unexpected output" until this one just now | 19:53 |
| jdstrand | ah | 19:53 |
| roadmr | jdstrand: I could have it looked at, I haven't seen anything in any logs or alerts | 19:53 |
| roadmr | jdstrand: I want to think we have alerts for misbehaving disks :) | 19:53 |
| jdstrand | if the last rmdir was from the 23rd, then it really shouldn't be that code, since this review would've triggered that | 19:54 |
| roadmr | right... | 19:54 |
| jdstrand | roadmr: ok, let me review the code. unless I say something, I'll just keep an eye on this | 19:54 |
| roadmr | ok, let me know if you need more info | 19:55 |
| Chipaca | ok, time for a dog to stretch its legs | 19:55 |
| jdstrand | roadmr: actually, do you have any 'Could not remove ...' in syslog? | 19:55 |
| Chipaca | 7k steps worth of dogwalking coming up -- should be back just after spread finishes :-D | 19:56 |
| roadmr | hm... let's see | 19:56 |
| roadmr | Chipaca: so do you walk 3.5k steps one way, then turn back? | 19:56 |
| roadmr | (and come back the same way, I guess) | 19:56 |
| kenvandine | jdstrand, thx for the review | 19:58 |
| roadmr | jdstrand: hm, no "Could not remove" in the logs. I only have application logs, no real access to syslog :( but, I can have it checked by someone with access | 19:59 |
| jdstrand | roadmr: ok, that's alright. it was just the one. let's keep with me reviewing and keeping an eye on it | 20:02 |
| jdstrand | kenvandine: np | 20:02 |
| roadmr | ok jdstrand let me know | 20:03 |
| niemeyer | pedronis: Around still? | 20:14 |
| pedronis | niemeyer: yes | 20:15 |
| niemeyer | pedronis: I'm a bit confused on 3573.. I can just add the notes on the review, or we can quickly talk if you want to be unblocked early tomorrow | 20:15 |
| niemeyer | snapd#3573 | 20:15 |
| mup | PR snapd#3573: overlord: always try to get a serial, lazily on classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/3573> | 20:15 |
| pedronis | niemeyer: we can talk quickly | 20:16 |
| niemeyer | pedronis: The main thing is about how "generic" apparently have two different keys | 20:16 |
| niemeyer | has | 20:16 |
| pedronis | one is for staging | 20:17 |
| niemeyer | And generic is named models as a side effect.. is that a test-only thing or is that an actual plan? | 20:17 |
| pedronis | ah, in that sense | 20:17 |
| pedronis | there are two keys, yes | 20:17 |
| pedronis | one for models , one for serials | 20:17 |
| pedronis | on is an offline key, the other in an online key | 20:18 |
| pedronis | canonical has the same btw | 20:18 |
| niemeyer | Ah, models is a key name, not an account name, sorry, I was confused indeed | 20:18 |
| pedronis | yes | 20:18 |
| pedronis | it just a label | 20:19 |
| pedronis | generic has models and serials | 20:19 |
| niemeyer | Yeah | 20:19 |
| pedronis | canonical for example has root, store and models or something like that | 20:19 |
| niemeyer | pedronis: Alright, thanks.. that was the only hanging point.. will review the rest | 20:19 |
| cachio | pedronis, is it ok if I submit a fix to make the fedora tests pass again? | 20:33 |
| pedronis | cachio: I have a PR open to reenabled them, snapd#3755 | 20:34 |
| mup | PR snapd#3755: try to reenable fedora spread tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3755> | 20:34 |
| pedronis | you mean to push something there? | 20:34 |
| cachio | yes | 20:35 |
| pedronis | yes, it's fine | 20:35 |
| cachio | I mean to push some fixes for tests that are currently failing | 20:35 |
| cachio | there are 2 tests failinf | 20:36 |
| pedronis | cachio: yes, you can push to that PR of mine | 20:36 |
| pedronis | I created it because I was the one turning them off | 20:36 |
| cachio | pedronis, great, tx | 20:36 |
| tpatel | Has anyone have issue with socket options SO_BINDTODEVICE not receiving data? | 20:52 |
| stormmore | I am really starting to enjoy creating a snap | 21:35 |
| nacc | i've got a classic snap that just updated (i own the snap) and after the update a script in the snap is for some reason not seeing a new python dependency (i've got a script in the snap that calls another program in the snap, which is failing from that script). Calling that program directly, though, is succeeding. I'm not entirely sure how to debug at this point | 23:11 |
| nacc | oh i wonder if it's a symlink issue with the snaps | 23:17 |
| nacc | well, that wasn't it | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!