| zyga | hello | 07:53 |
|---|---|---|
| mvo | hey zyga | 07:55 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:11 |
| kjackal | Hi, is there something wrong with the snap store? "error: unable to contact snap store " from my local machine and from aws when installing microk8s | 08:12 |
| mvo | kjackal: yeah, the store is not fully operating right now, see https://status.snapcraft.io/ | 08:15 |
| zyga | kjackal: I'm seeing timeouts | 08:15 |
| pstolowski | kjackal: indeed - https://status.snapcraft.io | 08:15 |
| nekoseam | api.snapcraft.io is coming back up when? | 08:31 |
| mbeneto | Hi, is the Global Store down? | 08:45 |
| zyga | mbeneto: see status.snapcraft.io please | 08:47 |
| mbeneto | zyga: thanks, I didn't know about that | 08:49 |
| mup | PR snapd#6495 opened: many: collect time each task runs and display with `snap change <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495> | 08:52 |
| === sparkieg` is now known as sparkiegeek | ||
| sparkiegeek | we're actively working on bringing the store back up, please be patient with us | 09:07 |
| zyga | sparkiegeek: thank you :) | 09:12 |
| mvo | zyga: did you see that the statx syscall is getting backported to libseccomp in bionic? do you think this affects us? | 09:39 |
| zyga | mvo: it will affect us as follows: | 09:39 |
| zyga | (I saw some chatter over email) | 09:39 |
| zyga | mvo: statx is present in the default seccomp templatte | 09:40 |
| zyga | mvo: statx will no longer resolve to unknown system call | 09:40 |
| zyga | mvo: statx will become present in seccomp profiles | 09:40 |
| zyga | mvo: some tests may start passing unexpectedly | 09:40 |
| mvo | zyga: thanks! but no ill effects for real-world workloads except tests? | 09:41 |
| zyga | no, things will only be better | 09:42 |
| mvo | I like the sound of that :) | 09:42 |
| pedronis | mvo: I marked #6495 blocked because I should review older things first, I don't think it can go in as is (I'm mostly worried that is a bit premature to put this in the main commands/API) | 09:59 |
| mup | PR #6495: many: collect time each task runs and display with `snap change <id>` <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495> | 09:59 |
| mvo | pedronis: fair enough, would it help if I remove the client bits and move them into debug? or would you prefer to leave this all alone ? | 10:00 |
| pedronis | mvo: it's probably best to have a chat about this first | 10:02 |
| mvo | pedronis: ok | 10:03 |
| === ricab is now known as ricab|brb | ||
| === ricab|brb is now known as ricab | ||
| zyga | Chipaca, pedronis: can you please double check that this is what we want: https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35?u=zyga | 11:02 |
| mup | PR snapd#6495 closed: many: collect time each task runs and display with `snap change <id>` <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6495> | 11:04 |
| zyga | FYI https://twitter.com/slpnix/status/1095640072999915520 | 11:06 |
| zyga | pedronis: ^ | 11:06 |
| Chipaca | zyga: what do you mean we can't return a synchronous error because we refresh assertions? | 11:10 |
| zyga | Chipaca: befure we get to UpdateMany we block for a long time to do assertion refreshes | 11:11 |
| Chipaca | zyga: yes | 11:11 |
| zyga | I'm not an expert on this part of the stack but this is what I found yesterday | 11:11 |
| Chipaca | zyga: but that's in the synchronous bit | 11:11 |
| zyga | ? | 11:11 |
| zyga | that is before we create tasks | 11:12 |
| zyga | and while the client waits for the response? | 11:12 |
| Chipaca | yes | 11:12 |
| pstolowski | hmm i'm still getting net/http: request canceled while... on api.snapcraft.io every time i run a spread test, even though status of the store is all green | 11:12 |
| zyga | Chipaca: that's unexpected and contrary to my assumptions about what should go where | 11:13 |
| Chipaca | pstolowski: yeah, store is not out of trouble yet | 11:13 |
| Chipaca | 'snap find' takes ages even when it works | 11:13 |
| Chipaca | zyga: ok | 11:13 |
| pstolowski | Chipaca: ack, thanks for confirming | 11:13 |
| Chipaca | zyga: I wasn't giving an opinion :-) | 11:14 |
| Chipaca | zyga: I was just stating a fact | 11:14 |
| Chipaca | zyga: now, ideally it would either be a lot faster, or be done in a task, but if moved to a task we lose the ability to error out entirely | 11:15 |
| Chipaca | the speed of refreshing assertions sucks | 11:16 |
| zyga | Chipaca: here I'm specifically after one aspect; gustavo wanted to have the refresh bail out synchronosuly (quickly) when we can check that a snap is busy | 11:16 |
| Chipaca | zyga: yes | 11:16 |
| Chipaca | zyga: so check before the assertion refresh | 11:16 |
| pedronis | Chipaca: zyga: is something that we need to fix/improve but is not trivial and cannot be done before we have fixed other issues | 11:16 |
| zyga | AFAIK this is not possible today | 11:16 |
| Chipaca | zyga: why? | 11:17 |
| zyga | Chipaca: yesterday you or pedronis commented it should be even later, but perhaps I misunderstood | 11:17 |
| pedronis | zyga: fast is a relative concept, what is your concern? | 11:17 |
| zyga | Chipaca: that is even before update is called, unless I'm missing something | 11:17 |
| pedronis | anything done in the sync part is considered "fast" | 11:18 |
| zyga | pedronis: synchronous error before we do anything | 11:18 |
| * pstolowski errand | 11:18 | |
| zyga | pedronis: if I can place it before the assertion check that would be enough | 11:18 |
| Chipaca | zyga: if by fast you mean synchronous, snapstate.Update can and does do things before starting the change | 11:18 |
| pedronis | zyga: what is the problem putting it after? | 11:18 |
| zyga | pedronis: it's noticeably slow and feels like bad user experience | 11:18 |
| pedronis | zyga: sorry, not relevant, other things are checked at that point | 11:19 |
| pedronis | as I said, not something we can fix *now" | 11:19 |
| zyga | sure, that's fine | 11:19 |
| zyga | so what is the design I should pursue, is the one I drafted in the forum post acceptable? | 11:19 |
| Chipaca | zyga: so, as i was saying, if by fast you meant synchronous, snapstate.Update | 11:19 |
| pedronis | any point that is reasonable and not bug introducing is fine in Update | 11:20 |
| pedronis | we need to speed it up | 11:20 |
| zyga | ok | 11:20 |
| pedronis | but as I said it's orthogonal, not easy problem | 11:20 |
| zyga | Chipaca: I meant as in not involving any network IO but as I understand that is difficult now, we can improve it later | 11:20 |
| Chipaca | zyga: if by fast you meant *actually* fast, you can call something from daemon | 11:20 |
| Chipaca | er | 11:20 |
| Chipaca | zyga: you can't mean without any network io | 11:20 |
| Chipaca | without network you can't know if there is an update available | 11:21 |
| pedronis | Chipaca: please, don't suggest horrible things | 11:21 |
| zyga | Chipaca: yes, without any at all, if you say "snap refresh foo" you can bail out knowing that foo ruuns | 11:21 |
| Chipaca | zyga: there might not be any updates for foo | 11:21 |
| zyga | Chipaca: it obviously applies to a subset of cases | 11:21 |
| Chipaca | zyga: why would you bail in that case? | 11:21 |
| Chipaca | "close all your open windows for the update" "k" "no updates available" "HULK SMASH" | 11:22 |
| pedronis | let's not be silly here | 11:22 |
| zyga | Chipaca: I was trying to convey the discussions from cape town, in the case where you can check that nothing can be done locally, you can provide an appropriate message that teaches the uses about this mechanic | 11:22 |
| pedronis | zyga: I can only repeat conceptually any point in Update is considered "fast" | 11:23 |
| zyga | OK | 11:23 |
| zyga | I think the draft I wrote now is actionable and in line with what we want | 11:23 |
| zyga | if you can give me a +1 on that I will carry on working towards that | 11:24 |
| Chipaca | pedronis: zyga: I'd suggest putting it at the top of `doUpdate`, fwiw | 11:24 |
| Chipaca | zyga: is the draft the forum post from where I came? | 11:24 |
| pedronis | Chipaca: that would be fine with me | 11:24 |
| zyga | Chipaca: yes, after iterating on this yesterday and today I moved all the logic into one helper that can be called from doUpdate | 11:24 |
| Chipaca | I somehow missed that we wanted to do this before knowing there was an update available and would like to express my concern about the ux of that | 11:25 |
| pedronis | Chipaca: I don't think that was the plan | 11:25 |
| pedronis | that doesn't make sense | 11:25 |
| pedronis | even | 11:25 |
| Chipaca | IKR | 11:25 |
| * pedronis -> lunch | 11:25 | |
| zyga | hm | 11:26 |
| zyga | so +1 or -1? | 11:26 |
| pedronis | to what? | 11:26 |
| pedronis | checking in doUpdate ? | 11:26 |
| pedronis | +1 | 11:26 |
| pedronis | afaiu right now | 11:26 |
| zyga | to all of https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35 | 11:26 |
| pedronis | ah, that's new | 11:26 |
| Chipaca | zyga: there are conceptual errors in that, which is what I opened with, so -1 | 11:27 |
| pedronis | I need to read it :) | 11:27 |
| zyga | ok, please comment on it with clarifications | 11:27 |
| zyga | I will carry on with tests | 11:27 |
| zyga | the way I structured this is easy to change | 11:27 |
| zyga | so any changes are OK | 11:27 |
| Chipaca | zyga: nothing in /34 where you describe the thing implies "before checking the store for updates" | 11:28 |
| zyga | Chipaca: I tried to capture it in 'snap refresh s2' case | 11:32 |
| zyga | but I was aware of the logic around assertions so I made it clear that this is not happening | 11:32 |
| sparkiegeek | store is fully operational again | 11:49 |
| Chipaca | sparkiegeek: woo, thank you | 11:50 |
| sparkiegeek | Chipaca: np, repair work was handled by rest of the team | 11:55 |
| sparkiegeek | but if you could please give us batched assertion requests we would have a better chance of coming back up quicker :) | 11:56 |
| Chipaca | er | 12:02 |
| Chipaca | sparkiegeek: will do | 12:02 |
| * Chipaca puts a bow on it | 12:02 | |
| Chipaca | or was that lipstick | 12:02 |
| Chipaca | eh | 12:02 |
| sparkiegeek | ⋈ | 12:02 |
| === alan_g is now known as alan_g_ | ||
| Chipaca | mvo: did you see my question on https://github.com/snapcore/snapd/pull/6034#discussion_r256025287 ? | 12:15 |
| mup | PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034> | 12:15 |
| audiophilo | Hi, i'm using rhytm ferret extensively on acoustic drums. If i pick bass drum and snare drum as a reference for splitting i can have a problem when they are played at the same time by the drummer. Since it's unlikely that bass and snare are hit at the very exact moment, rhytm ferret will create 2 very-close and unusefull regions (Attachment 1: https://imgur.com/pYpnYLd) that will create a more annoying behaviour when using P | 12:18 |
| audiophilo | osition -> Snap position to grid (Attachment 2: https://imgur.com/l5uwFmr). I thought that it would be great to add an option in rhytm ferret where you can add a value in ms to determine a minimum distance from a cut to the other. Do you think this could be a nice idea? | 12:18 |
| Chipaca | audiophilo: are you in the right channel? | 12:19 |
| audiophilo | nope. LOL | 12:20 |
| Chipaca | audiophilo: phew | 12:20 |
| audiophilo | :D | 12:20 |
| Chipaca | for a moment I thought I'd lost it | 12:20 |
| audiophilo | too many tabs, i got confused. Sorry | 12:20 |
| Chipaca | audiophilo: good luck with your … ferret … snaring? | 12:21 |
| Chipaca | sounds like fun anyway | 12:21 |
| audiophilo | Chipaca, thank you very much. Well it's not very funny actually. But very usefull :D | 12:22 |
| cachio | mvo, hey | 12:22 |
| cachio | mvo, I am going to promote the snapd snap | 12:22 |
| cachio | I would like to know why those versions are not in beta right now | 12:22 |
| mvo | cachio: thank you | 12:25 |
| mvo | cachio: we can discuss why 2.37.2 is not in beta after lunch, gtg now, sorry. will be back soon | 12:25 |
| cachio | mvo, np, enjoy lunch | 12:26 |
| mup | PR snapd#6496 opened: many: collect time each task runs and display with `snap debug change-timings <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6496> | 12:26 |
| pedronis | mvo: could you merge master in #6404, it seems to still require old deps | 12:30 |
| mup | PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404> | 12:30 |
| zyga | brb, taking a small break now | 12:40 |
| cachio | pstolowski, hey, yesterday I was running the hotplug test | 12:41 |
| cachio | I left a comment on the PR about the results | 12:41 |
| === ricab is now known as ricab|lunch | ||
| pstolowski | cachio: yes, thank you i saw it. i was trying to debug it today but store was mostly offline | 13:00 |
| pstolowski | cachio: did you run that test only on 16.04? | 13:11 |
| mup | PR snapd#6497 opened: features,cmd/libsnap: add new feature "refresh-app-awareness" <Created by zyga> <https://github.com/snapcore/snapd/pull/6497> | 13:26 |
| mup | PR snapd#6498 opened: cmd/libsnap: add cgroup-pids-support module <Refresh Awareness> <Created by zyga> <https://github.com/snapcore/snapd/pull/6498> | 13:32 |
| zyga | two early branches from the refresh app awareness work | 13:33 |
| === sparkieg` is now known as sparkiegeek` | ||
| === sparkiegeek` is now known as sparkiegeek | ||
| cachio | pstolowski, yes, only on 16.04 | 13:39 |
| mvo | pstolowski: 6404> sure | 13:49 |
| pstolowski | cachio: i've just run it on 16.04 (failed) and 18.04 (passed). i wonder if it's something qemu-related. it seems as unplugging and then re-plugging device back in qemu doesn't trigger the udev add event on 16.04, but i'll need to investigate this closer. qemu on 16.04 is 2.5, in 18.04 - 2.11 | 13:51 |
| pstolowski | cachio: nb, running nested 16.04 vm under 18.04 (to have newer qemu) doesn't seem possible since we build snapd deb on the host, so dependencies are wrong | 13:55 |
| cachio | pstolowski, yes | 13:56 |
| cachio | pstolowski, how are you running this? | 13:57 |
| pstolowski | cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug | 13:59 |
| pstolowski | cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=xenial spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug | 13:59 |
| pstolowski | cachio: i once mixed that up accidently and that didn't work because of what i said above | 14:00 |
| Chipaca | zyga: wrt getting the apps from the check, earlyEpochCheck is already loading them, we can change it to either return or have it passed in | 14:09 |
| === ricab|lunch is now known as ricab | ||
| cachio | jdstrand, hey, could you please take a quick look to #6376? | 14:29 |
| mup | PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376> | 14:29 |
| cachio | thanks | 14:29 |
| jdstrand | cachio: I will not be able to look at it for a little while, but will today. sorry for the delay | 14:31 |
| cachio | jdstrand, thanks | 14:32 |
| pstolowski | cachio: what's the new simple syntax for nested vm tests? | 14:47 |
| zyga | Chipaca: thanks for the hint, let me look :) | 14:47 |
| cachio | pstolowski, for xenial | 14:48 |
| cachio | spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug | 14:48 |
| cachio | for bionic | 14:48 |
| cachio | SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug | 14:48 |
| pstolowski | cachio: thanks | 14:51 |
| cachio | pstolowski, taw | 14:51 |
| cachio | yaw | 14:51 |
| zyga | Chipaca: interesting, that is perfect | 15:28 |
| mup | PR snapd#6499 opened: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499> | 15:40 |
| zyga | jdstrand: hey | 15:45 |
| zyga | jdstrand: not sure if you are around but https://github.com/snapcore/snapd/pull/6499/files :) | 15:45 |
| mup | PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499> | 15:45 |
| * cachio lunch | 15:48 | |
| mup | PR snapd#6500 opened: dirs: add PidsCgroupDir <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6500> | 16:00 |
| === alan_g is now known as alan_g_ | ||
| mup | PR snapcraft#2468 closed: many: support for stage-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2468> | 16:14 |
| zyga | Chipaca: can you please review the dirs change quickly | 16:14 |
| zyga | I can then propose more useful stuff | 16:14 |
| Chipaca | zyga: I've got to agree with mvo, no point to the pr on its own | 16:15 |
| zyga | there is a hidden point, I love reusing commit messages | 16:15 |
| zyga | no need to write "branch" description | 16:15 |
| zyga | but I can close it and merge it into the bigger one | 16:15 |
| pedronis | Chipaca: https://github.com/snapcore/snapd/pull/6501 | 16:23 |
| mup | PR #6501: tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501> | 16:23 |
| mup | PR snapd#6501 opened: tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501> | 16:23 |
| mup | PR snapd#6500 closed: dirs: add PidsCgroupDir <Simple 😃> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6500> | 16:35 |
| mup | PR snapd#6502 opened: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502> | 16:35 |
| zyga | Chipaca: ^ :) | 16:36 |
| zyga | Chipaca: I mainly wonder if you will ask me to use a different type for PID | 16:36 |
| Chipaca | zyga: it's an int32, right? | 16:37 |
| zyga | int | 16:37 |
| * Chipaca looks | 16:37 | |
| zyga | (because it was the easy choice) | 16:37 |
| zyga | we only read it from text files | 16:37 |
| zyga | and print | 16:37 |
| mup | PR snapcraft#2470 opened: Enable support for strictly confined multipass <Created by gerboland> <https://github.com/snapcore/snapcraft/pull/2470> | 16:38 |
| Chipaca | zyga: I'd be a teeny tiny bit happier if they were int32, mostly because that signals intentional...ness?] | 16:39 |
| zyga | do we have a type for that | 16:39 |
| Chipaca | zyga: 'int' in go often means "yeah it's a number but i didn't think too much about it' | 16:39 |
| zyga | so that I don't have to spell it everywhere? | 16:39 |
| Chipaca | zyga: no | 16:40 |
| Chipaca | zyga: grep -ri pid.int32 tho | 16:40 |
| t1mp | hello. I have a python+Qt app that works fine, but after snapping it, some dialogs don't open when I click the button to open them. | 16:57 |
| t1mp | How can I debug this? For example, how do I enter the snap container and then launch python inside? | 16:57 |
| pedronis | mvo: pstolowski: I did another pass over some of your PRs | 16:58 |
| pstolowski | pedronis: ty! | 16:59 |
| mvo | pedronis: \o/ | 17:00 |
| zyga | t1mp: hey | 17:04 |
| t1mp | hello zyga | 17:04 |
| zyga | t1mp: you can run "snap run --shell snapname" | 17:04 |
| t1mp | I just did snap run --shell qmenta-uploader :) | 17:04 |
| zyga | and then look at wrapper scripts typically generated by snapcraft in $SNAP directory | 17:04 |
| t1mp | but I guess some env vars are missing | 17:04 |
| zyga | yeah | 17:04 |
| zyga | those are in the wrappers | 17:04 |
| t1mp | right :) | 17:04 |
| zyga | eventually it will all be inside a delcarative system but that's not done yet | 17:04 |
| t1mp | I think you told me once, last year, but I forgot since in the meantime I didn't have to worry about it | 17:05 |
| mvo | pstolowski: btw, I see a lot of "udev monitor observed ... event for ..." in my snapd from git - should we make this a debugf instead of a noticef | 17:06 |
| t1mp | strange. I am opening a QtQuick.Dialogs.FileDialog. It works when I run the app 'locally', but not when I run it from a snap. | 17:07 |
| pedronis | mvo: I think some of the new PRs turn some Noticef into Debugf, not sure if that is one of those | 17:07 |
| zyga | any denials/ | 17:07 |
| zyga | I'm about to EOD (or at least break for dinner) but I can look later | 17:07 |
| mvo | pedronis: aha, thanks | 17:08 |
| t1mp | zyga: no errors/warnings at all. (I did get a bunch before, but I fixed them all and it still doesn't work, so that doesn't seem to be the problem). | 17:08 |
| t1mp | zyga: thanks, enjoy your dinner :) | 17:08 |
| t1mp | Speaking of which, I need to eat too. | 17:09 |
| pstolowski | cachio: ping | 17:16 |
| cachio | pstolowski, yes | 17:25 |
| mup | PR snapd#6503 opened: tests: use snap which takes 15 seconds to install on retryable-error test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6503> | 17:45 |
| * cachio afk | 17:54 | |
| pstolowski | cachio: hey, sorry, fyi when you're back: | 18:23 |
| cachio | pstolowski, hey | 18:24 |
| pstolowski | cachio: i've made a quick hack to use qemu-virgil in nested.sh, but it needs more work - https://paste.ubuntu.com/p/t8tdRFCdyY/ | 18:24 |
| pstolowski | cachio: hey | 18:24 |
| cachio | pstolowski, nice, test is passing with that change? | 18:25 |
| pstolowski | cachio: no, i think the failure on 16.04 is actual bug in hotplug code, i found one specific issue in the code and now checking a fix | 18:26 |
| pstolowski | cachio: i'm not sure if we will need newer qemu or not | 18:26 |
| cachio | pstolowski, ah, nice, that test worked in that case | 18:26 |
| pstolowski | cachio: if so, then it will need more work. the snap uses strict mode by default, but it's problematic because we use /dev/tty* for our virtual devices, so i used devmode. also i'm not sure if qemu-system-i386 is supported, there snap doesn't have binary for that | 18:28 |
| pstolowski | cachio: (the snap = the qemu-virgil snap) | 18:28 |
| pedronis | mvo: this is the question Chipaca was referring to in the standup: https://github.com/snapcore/snapd/pull/6034#discussion_r255888988 | 18:28 |
| mup | PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034> | 18:28 |
| cachio | pstolowski, ah, ok | 18:29 |
| cachio | pstolowski, otherwise we could continue using the current way | 18:30 |
| pstolowski | cachio: yes, i'll know by tomorrow if old qemu is ok | 18:31 |
| pstolowski | cachio: ok, 1 bug fixed and i hit another one, interesting those happened on 16.04! good! eod | 18:40 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | pedronis: thank you, looking | 18:42 |
| cachio | pstolowski|afk, nice, thanks for fixing those ones, see you tomorrow | 18:43 |
| * Chipaca takes the walk for a dog | 19:00 | |
| mup | PR snapd#6504 opened: tests: not checking 'tracking channel' after refresh core on nested execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6504> | 19:05 |
| Wimpress | Snapcraft pro tips is live streaming now! | 20:01 |
| Wimpress | https://www.youtube.com/watch?v=DtZySQgBxmM | 20:01 |
| t1mp | I guess that's useful, since the snapcraft docs are outdated. https://docs.snapcraft.io/debugging-building-snaps/6274 with snapcraft 3, there is no prime/ dir so those docs are not helpful | 20:07 |
| Wimpress | @degville ^ | 20:09 |
| ijohnson | do we have a list anywhere of which distros enable re-exec for the core snap and which don't? | 20:11 |
| degville | thanks Wimpress. noted. | 20:14 |
| mup | PR snapcraft#2471 opened: test: test-beta <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2471> | 20:35 |
| t1mp | I can no longer let my snap open a file select dialog.. :s It works fine in my (python+QtQuick) app, but after snapping it, the new dialog simply doesn't show up any more. Did anyone else encounter this? | 20:42 |
| Facu | Hello! I'm stuck building a snap for my project (a pure Python one: `fades`)... | 20:47 |
| Facu | - if I try to build it in my desktop I get another weird error ( https://forum.snapcraft.io/t/the-linker-version-2-23-used-by-the-base-core-is-incompatible-with-files-in-this-snap/7430/13 ) | 20:47 |
| Facu | - if I try to build it in my laptop I get another weird error ( https://forum.snapcraft.io/t/error-you-must-give-at-least-one-requirement-to-install-when-building-a-snap/9946 ) | 20:48 |
| Facu | - if I try build.snapcraft.io to build it, I go and request it manually, it appears during some seconds the row (after past builds 7 months ago) "Number: requested" and "Build trigger: Manual build", but after those seconds that row disappears and it's as if I never tried to build it | 20:49 |
| Facu | is there anything else I could try? thanks! | 20:49 |
| NickZ | Facu: the first post is outdated; lxd is no longer required for building snaps. If you specify "base: core16" or "base: core18" in your snapcraft yaml, it'll build it in a VM | 21:06 |
| Facu | NickZ, I should use "base: core18", as I'm in Bionic, right? | 21:06 |
| NickZ | yeah, if you want your snap to target bionic, you should use that | 21:06 |
| Facu | NickZ, I want my snap to target everything | 21:07 |
| NickZ | Only for the build step; it makes sure that whereever you're building this snap, it will always use the bionic packages when pulling in dependencies and building | 21:07 |
| NickZ | you can use it everywhere | 21:07 |
| Facu | it's installing multipass now :o | 21:09 |
| NickZ | yup | 21:10 |
| Facu | NickZ, it's Launching a VM (retrieving an image, it seems), so I guess that unblocked the problem | 21:17 |
| Facu | NickZ, aaaaaand it looks it worked :) | 21:27 |
| Facu | NickZ, thanks!!! | 21:29 |
| mup | PR snapcraft#2472 opened: project loader: do not leak a part's build-environment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2472> | 21:32 |
| NickZ | Facu: awesome, np man | 21:32 |
| mup | PR snapd#6034 closed: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6034> | 22:51 |
| Odd_Bloke | I have a single shell script that I want to include in a snap that is otherwise Python-only; how do I simply copy a file from my git repo somewhere in to my snap? | 22:53 |
| Odd_Bloke | (I've been trying to do this with arguments to the Python plugin, but perhaps this needs to be a separate part?) | 22:53 |
| stgraber | Odd_Bloke: separate part using the dump plugin | 22:53 |
| Odd_Bloke | Thanks! | 22:53 |
| stgraber | you could also use an override on your existing part and then use that to cp stuff around but that's gross :) | 22:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!