/srv/irclogs.ubuntu.com/2019/02/01/#snappy.txt

mupPR snapcraft#2456 opened: plugins: add colcon plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2456>01:22
mborzeckimorning06:12
mupPR snapd#6462 closed: snap-confine: fix incorrect "sanity timeout 3s" message <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6462>07:17
mupPR snapd#6463 closed: snap-confine: increase locking timeout to 30s  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6463>07:18
=== sabdfl_ is now known as sabdfl
Saviqsergiusens, mwhudson: I believe we got the multipass build going on bsi before we moved it under Canonical, and yeah last I checked it wasn't possible to set up a build if you were only a collaborator07:22
zygaHi07:38
Saviqmoaning07:39
mvohey zyga ! good morning07:39
mvohey Saviq07:39
zygaGood morning07:39
mborzeckizyga: mvo: Saviq: hey guys07:47
mborzeckizyga: feeling better today?07:47
zygamvo: so-so, I was just thinking if I should be off and back in bed to be on the safe side07:47
mvomborzecki: good morning07:47
mvozyga: sure, do it07:47
zygamvo: I was thinking about the timing issue yesterday07:47
zygamvo: I will investigate one aspect and then probably just quit (I'll file paperwork for both days)07:48
zygamvo: there's a reliable way to trigger the issue07:48
mvozyga: sure07:48
mvozyga: oh?07:48
zygamvo: I want to see what happens now with 2.37.x as far as systemd is concerned07:48
zygamvo: sure, just put a long sleep in the main process after forking the helper07:48
zygamvo: if there's a difference to 2.36 I will look at patching that07:49
mvozyga: aha, I see07:49
Saviqzyga: "put a long sleep... after forking..." that's re: your day off, is it? ;)07:50
zygahaha07:51
zygafork & exec and then I will be off ;)07:51
zyga(for a few days at least)07:51
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:59
mborzeckipstolowski: hey08:02
pedronispstolowski: hi, couldn't the doHotplugAddSlot bit be separated out in a PR before being used?08:04
pstolowskipedronis: hi, yes it could, i wasn't sure if we want to separate further. shall i do this?08:05
pedronispstolowski: yes, but I left a comment there as well, one sec08:05
pedronispstolowski: ok, added one comment08:06
pedronis(for now)08:06
pstolowskipedronis: km thanks08:06
mupPR snapd#6456 closed: interfaces: add network-manager-observe interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6456>08:12
=== phoenix_firebrd is now known as murthy
=== ricab is now known as ricab|brb
ograsil2100, hey ho ... do you currently use ubuntu-image to create the classic pi images (and a gadget for classic) ?09:16
sil2100ogra: yeah, pi3 for now, and using currently a slightly modified gadget tree for classic09:21
sil2100ogra: (we want to merge it into one gadget repo in the next iteration)09:21
sil2100I hope waveform will help with that ;)09:21
ograsil2100, do you have the gadget code public ... ?09:22
sil2100ogra: sure, it's used in our daily builds so yes09:23
sil2100https://github.com/CanonicalLtd/pi3-gadget/tree/classic09:23
ograthanks !09:23
sil2100ogra: it has some messy bits right now (some hacks to workaround various missing pieces here and there) and well, the custom classic bootscript is very simple as we didn't have time to create one that would do our things for both classic and core09:24
sil2100I blame it on time constraints of course09:25
ograsil2100, uh, why did you re-inroduce boot.scr ? took us years to get that fixed upstream to allow uEnv.txt files09:25
sil2100ogra: yeah, so that was not the best decision I made, we'll be going back to using uenv soon, I used boot.scr because: a) that's what ryan's pi3 classic images used and b) that's what flash-kernel upstream was using for the pi309:26
ograwow, that code is miles apart from the core gadgets09:26
sil2100But yeah, it's something we'll change back in the nearest weeks09:26
sil2100Which part of the code? ;)09:27
ograMakefiles instead of letting snapcraft do everyrthing (i.e. only a snapcraft.yaml) ... boot.scr ... copying blobs around instead of building from source09:28
sil2100ogra: yes, the Makefile and copying blobs is all that will go 'upstream'09:29
sil2100ogra: we can't use snapcraft to do all the things because snapcraft is in universe, and we need to build the gadget trees in our livefs builders (livecd-rootfs)09:29
sil2100ogra: and we need to pull all the blobs from the archive as everything we build officially for classic should use existing binaries from the archive, not building them 'in place'09:30
ograoh, and you cant use the snapcraft snap during build either ?09:30
sil2100No, since livecd-rootfs needs to only use debs, we're not relying on snaps in any point of our image build process09:31
ograoh my ... yeah, then that setup is probably best09:31
sil2100So I had to switch to a Makefile, which made things eh, very complicated09:31
=== ricab|brb is now known as ricab
ograyep, i know what you mean09:31
sil2100The boot.scr is a mistake, I know ;p09:32
ogramy "getting in touch with snaps" was exactly the other way around ... everything was a Makefile ... nowadays everything is just snapcraft.yaml09:32
sil2100I was going back and forth with that one sadly09:32
ograyeah, its not easy09:32
ograin core its a bit better since we need to pre-build the whole environment as an image09:33
sil2100First I used uenv like core, but then saw flash-kernel and our unofficial images and well, switched, but that's actually not what we want - and it was already a bit too late then09:33
ograso no need for a boot.scr, all customization happens when the env is created09:33
ogracore only used uEnv.txt in 15.0409:34
ograwe quickly moved to a full environment build09:34
sil2100Yeah, and we need to have a common scenario for both core and classic, so I'll switch back to u-boot.env09:34
ogramakes everything easier to maintain :)09:34
ograsil2100, BTW, why do you build separate images, you could have a single universal Pi image that runs on all Pi's we support (at least for armhf ... arm64 only for all Pi3 models)09:37
Chipacamvo: o/09:37
Chipacamvo: two things for you (ish?)09:38
Chipacamvo: one, https://forum.snapcraft.io/t/the-road-to-core18/5547/2409:38
Chipacamvo: two, https://forum.snapcraft.io/t/cant-set-permission-set-hardware-observer/8695/609:38
ograsil2100, (note i dont want to mimic adam smith :P ... just an interest question)09:38
sil2100ogra: that's the plan as well! Right now they're called pi3 images, but we're pretty confident that the pi3 armhf images we have will just work on the pi209:39
sil2100ogra: but we don't brand them that way yet as we didn't commit to making sure that's really the case09:40
waveformah, more reading (have not come across uEnv.txt yet!)09:40
sil2100ogra: for now we're only concentrating on making the pi3 arm64 one working09:40
ograsil2100, https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md should be interesting ... you can use conditionals in config.txt to switch to the right u-boot/kernel.img based on the HW the first stage bootloader detected09:40
sil2100waveform: hah! Well, we'll be just using u-boot.env in our case, just like the core snap09:40
waveformI shall be testing on "all the Pis" when I get a spare moment!09:40
waveformogra, yup - includes may be useful too (to avoid trampling users changes to config.txt)09:41
ograsil2100, thats what i use in my core universal Pi gadget ... https://github.com/ogra1/pi-kiosk-gadget09:41
sil2100ogra: yeah, didn't use it but saw that in the config.txt of core18 gadgets, seemed nice and useful09:41
sil2100ogra: we have that in the universal pi gadget for core18 as well, although a bit messy ;p09:41
ograwaveform, ah, you are the Pi-guy ? welcome to the madhouse ;)09:42
mvoChipaca: thank you09:42
waveformogra, yup - surrounded by the things (and the madness :)09:42
sil2100ogra: yes, waveform will make our Pi experience amazing ;)09:42
ograsil2100, because i initially wrote it :) i'm known for "messy but working, ... needs work" stuff ... you know me ;)09:42
sil2100I guess we all have projects like that ;)09:43
ograyeah09:43
mupPR snapd#6415 closed: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>09:48
mupPR snapd#6464 opened: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6464>09:49
mvowaveform: nice - welcome!09:50
mvomborzecki: firstboot measure, the above is my RFC/idea how to get started, very simple but should give us something to start from (if pedronis  is happy with the initial shape :)09:50
mborzeckimvo: ok, will look in a bit09:51
mborzeckimvo: snap analyze-blame :P09:51
ogranow that would be a thing09:52
ogra!09:52
mvomborzecki: haha - I like that09:52
pedronismvo: I'm a bit worried you did that at all :)09:52
mborzeckimvo: iirc zyga has a branch to collect some timing measures too, we closed it didn't we?09:54
zygayes09:54
zygaI have it on github09:54
mvopedronis: its just a quick outline, promised I will not touch it more09:54
mvomborzecki: yeah, I reference to zyga PR09:54
zygaspecifically the ring buffer code is IMO good to merge09:54
mvomborzecki: zyga approached it from the other side, I think we need to agree on the shape first (with pedronis) then we can take those bits, YAGNI and all that09:55
mborzeckiyup, agreed09:55
mvozyga: yeah, there is a FIXME in there that point to the ringbuffer09:55
zygaI started with the assumption that snapd should know timing data about any part of the stack09:55
* mvo really likes snap analyize09:56
zygak09:56
zygaI didn't read any of the PRs09:56
pedronisyes, don't carried away too much before I look at things09:56
mvozyga: its fine, no worries, I think we will need most of your stuff its just approaching it from the other direction09:56
* dot-tobias waves hello10:02
* Chipaca waves back10:06
Chipacapedronis: both my PRs are ready for re-reviews, if you're wondering what to do :-p10:22
mupPR snapd#6465 opened: overlord/ifacestate: hotplug-add-slot handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>10:25
pstolowskipedronis: ^ it grew some extra tests not present in the main branch10:26
Chipacapedronis: unrelatedly, if I have a ClientSnapFromInfoSnap(*info.Snap) (*client.Snap, error), should I put it in cmd/ (next to the similar ClientAppInfosFromSnapAppInfos(apps []*snap.AppInfo) ([]client.AppInfo, error) ) ?10:28
Chipacait'd be used by daemon and cmd/snap10:28
pedronisChipaca: yes, seems those two need to be together10:37
pedronispstolowski: thanks, in my queue10:37
pedronispstolowski: are you blocked or are you looking again at EnsureBefore ?10:37
pstolowskipedronis: yes, i'm looking at ensurebefore, not blocked10:40
pedronispstolowski: thx10:47
mborzeckishould we land #6422 and see if that makes the occasional mount issue on ubuntu-core-18 go away?10:49
mupPR #6422: tests/prepare: prevent console-conf from running <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>10:49
pedronisChipaca: thanks, yes your PRs are likely the next things I look at10:50
mupPR snapcraft#2438 closed: rust plugin: new link for rustup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2438>11:14
mupPR snapcraft#2454 closed: baseplugin: add a proper exception for cross-compilation support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2454>11:14
dot-tobiasStruggling with cross-compilation in multipass VMs / snapcraft 3.x, super grateful for any “you're holding it wrong” hints: https://forum.snapcraft.io/t/snapcraft-3-x-cross-compilation-amd64-armhf-in-multipass-vm/975811:53
mupPR snapd#6426 closed: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6426>12:05
Chipacamvo: ping12:30
Chipacapopey: ping?12:30
Chipacaoh, fosdem12:30
Chipacafossdem?12:30
ChipacaWimpress: also fosdem?12:31
=== alan_g_ is now known as alan_g
WimpressChipaca: Hi12:45
WimpressSorry, was head down. I'm available. Not a FOSDEM.12:46
WimpressI don't have anything to discuss, but if you've got something we can jump on a call?12:46
ChipacaWimpress: ah, er, I went off to prepare lunch (it's cooking rn), mvo did similarly i think12:58
leinardiHi, when I try to run my app from the snap I'm getting an error related to gnome-3-26-1604, even if I specified gnome-3-30-1804 and core18. Can someone give me some hints on how to fix this? More details here: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/1713:21
zygakenvandine: ^13:21
zygaleinardi: you might need to wait for people from US time-zones to be up though13:21
kenvandineHey13:21
Chipacaleinardi: are the connections ok?13:21
zygahey kenvandine :-)13:22
Chipacamaybe we got the content interface plugged wrong or sth13:22
kenvandineThat message just means the content snap isn't mounted13:22
zygakenvandine: does 3-30-1804 exist?13:24
zygamvo: iterating on the regression test, it's trickier than it should perhaps :/13:24
kenvandinezyga: it's only in edge and untested13:25
kenvandineleinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-180413:26
zygakenvandine: is there a plan to make it stable, 18.04 was shipped a while ago and core18 is a thing for a few weeks now13:26
kenvandinewe're shipping a bunch of snaps with gnome-3-28-1804 already13:27
kenvandineif $SNAP/gnome-platform doesn't exist or is empty it prints out that error to connect it13:28
zygaah13:28
zygaI missed 28 vs 3013:28
kenvandineright now the scripts are hard coded to gnome-3-26-1604 for that print statement13:28
zygamborzecki: ^ it would be great if we had a way to get slot attributes via snapctl13:29
zygae.g. snapctl slot-info --print-attr=content "gnome-platform"13:29
zygaso that a message like that doesn't have to be hard-coded13:29
mborzeckizyga: hm iirc there's snapctl get --slot/--plug13:31
zygaoh, I didn't know13:31
zygadoes it show stuff like attributes easily?13:31
zygaI'm mainly after usability from shell13:31
mborzeckiidk13:32
Chipacazyga: you can just run it :-)13:32
Chipacaerror: error running snapctl: interface attributes can only be read during the execution of interface hooks13:33
ChipacaI lied13:33
mborzeckiheh13:33
zyga~/go/src/github.com/snapcore/snapd/tests/regression/lp-1813963 $ snapctl get --plug :opengl13:33
zygaerror: error running snapctl: interface attributes can only be read during the execution of interface hooks13:33
zyganot useful13:33
Chipacaquoth the raven, Y THO13:34
mborzeckipoe rolling in his grave13:34
kenvandinezyga: speed is very important there13:34
kenvandinewe don't want to slow down desktop-launch13:34
zygasure13:34
zygait should be zippy13:34
zygafast13:34
zygasnappy even13:34
kenvandineit needs to be as fast as checking for the contents of the directory :)13:34
zygasure but now it is fast but misleading13:35
Chipacaright, the fast path yes, but if it fails you can be slower reporting the error13:35
kenvandinebut... it would be a big improvement13:35
zygait needs to be useful and fast13:35
kenvandineah13:35
kenvandinegood point13:35
=== ricab is now known as ricab|lunch
kenvandinewe'll look at doing that in the gnome extension of snapcraft13:35
Chipacaerror handlers have all the time in the world¹13:35
zygagood point13:36
* zyga recalls a special parser that has a fast path for correct code and a super-generic error path for any errors that is then causing re-parsing with a parser crafted for careful errors at the expense of longer parsing time13:36
Chipacain other news, cabbage does not shrink while cooking. I'm eating out of a bucket today.13:37
zygamvo: whee13:44
zygait passed13:44
zygaman that was tricky13:44
leinardi> <kenvandine> leinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-180413:45
leinardikenvandine, wait, so gnome-3.28.1804 actually has Gnome 3.30? I need 3.30, can't use 3.2813:46
kenvandinethey are both built from 18.04, gnome-3-30-1804 isn't a real thing yet13:47
kenvandineit's not in stable because it's not complete yet13:47
kenvandineand it will ultimately be built from the build snap, not the archive13:47
leinardiso, there is no current way to get gnome 3.30 to work with snap? should I just wait to release my app with it?13:49
WimpressI've just installed `multipass` on a clean install of 18.10.13:50
WimpressEvery multipass command I issue results in: `dropping privs did not work` which is an error being thrown by snapd-confine.13:51
WimpressJust want to know if this is a known issue before I got digging.13:52
Chipacazyga: ^13:52
zygaWimpress: no13:52
zygahmm hmm hmm13:52
zygaWimpress: I will check in a moment but can you please open a bug13:52
zygaWimpress: and attach13:52
zygaSNAPD_DEBUG=1 multipass13:53
zygaI will handle the rest13:53
WimpressSure thing.13:53
pedronisChipaca: I did a review of #635613:57
mupPR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>13:57
Chipacapedronis: ta13:57
Wimpresszyga: You can stand down. We have a case of use error.13:58
zyga:D13:58
zygawhat did you do?13:58
WimpressI've just notice the terminal I was use is logged in as root.13:58
Chipacapedronis: the call to SetStatus needs to happen before the call to EnsureBefore, right?13:59
pedronisChipaca: no, doesn't matter, given you holding the lock13:59
Chipacak14:00
pedronisChipaca: we tend to do it last, lots of examples14:00
pedronisin ifacestate14:00
Chipacapedronis: isn't the status set to done as soon as the handler returns with no error?14:00
pedronisChipaca: yes, but we release the lock in the middle of that14:00
pedronisso not guarentee14:00
pedronisthat we get there14:00
abeatojdstrand, hey, was wondering if you had seen my comment about NM controlling netplan: https://github.com/snapcore/snapd/pull/5915#issuecomment-45469500414:01
mupPR #5915: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5915>14:01
sergiusensWimpress: hmm, multipass works fine on the current devel I am typing from14:01
kenvandineleinardi: i can take another look at your snap in a bit, i'm in a meeting for the next couple hours14:02
Wimpresssergiusens: It was user error on my part.14:16
jdstrandabeato: I had and need to circle back to it (it is on my todo). thanks for the reminder14:36
abeatojdstrand, great, thank you14:36
pedronisabeato: which snaps need this? just our own NM?14:38
pedronisjdstrand: fwiw I'm also thinking about this problem14:38
abeatopedronis, just that one, yes14:39
* jdstrand nods14:42
Chipacapedronis: wrt putting fromChange 'last', that'd be last before flags, right? or actually last?14:46
=== ricab|lunch is now known as ricab
pedronisChipaca: actually last15:13
Chipacapedronis: ack15:15
Chipacapedronis: and the filter also after the flags?15:15
jdstrandis there a problem with lp snap builds? I tried to request a build from something and all it says is 'Failed to build' with no buildlog15:15
cjwatsonjdstrand: #is-outage15:17
ograjdstrand, theer seem to be other timeouts too15:17
cjwatsonswift takes out librarian which takes out a bunch of random stuff15:17
ograah, cjwatson beats me15:17
jdstrandcjwatson: thanks15:19
pedronisChipaca: that's fine, not as a strong opinion on that15:28
leinardikenvandine, sure thanks! I'll go offline soon, if you can please reply on the forum post: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/2715:31
zygamvo: given is-outage I wonder if we can release today15:49
mvozyga: we released15:54
zygaI mean about .215:54
zygacan we even go to beta?15:54
zygamvo: interesting observation from just now15:56
zygaI fixed one more typo15:56
zygathe service fails correctly now15:56
zygabut :)15:57
zygait is "working" during the startup phase15:57
zygaI wonder if snap-confine or snap-run perhaps should be able to tell systemd "hold on, not really there yet"15:57
zygasystemctl start snap.foo.bar.service # <- while snap-confine is running the service appears to be operational15:57
zygaI realise this is a daemon=simple service15:57
zygajust was not expecting it, I guess15:58
cjwatsonzyga: note that the swift that the LP librarian uses isn't the same as the one that the snap store uses15:58
zygacjwatson: ah, uff, that's good news15:59
cjwatsonat most it could cause a problem for builds; if you have something built it won't matter though15:59
cjwatson(also it looks like it might be fixed)15:59
zygamvo: the test is passing now, I will experiment with the two extra variants that pedronis suggested16:10
mvozyga: thank you - I will take a break and get back to it then16:13
zygak16:13
cjwatsonjdstrand: try again now?16:16
zygamvo: going through smoke testing main/regression with my patch16:31
zygamvo: in parallel iterating on the variants pedronis suggested16:31
zygamvo: so far all good16:31
zygajdstrand: hey16:31
zygajdstrand: do you have a moment to discuss a regression I introduced to snap-confine?16:31
zygajdstrand: a quick look at a patch fixing that, I can give you context about the earlier discussion I had with pedronis and mvo16:32
zygajdstrand: if you cannot do it now that's fine, we can try next week16:32
jdstrandzyga: if it isn't urgent, next week would be better16:40
jdstrandzyga: and hello :)16:40
zygajdstrand: hey :)16:40
zygajdstrand: it's urgent-ish but I think it can wait (CC: mvo)16:41
zygajdstrand: I will open the PR and let anyone comment in case someone wants to over weekend16:41
jdstrandzyga: if you do it that way, ping me with the PR and perhaps I can get to it later today16:44
zygathank you!16:45
zygaI have a patch now but I'm trying to reduce it in scope so that it can do less side-effects and damage16:45
diddledanLukewh: did the build.snapcraft.io get fixed for https://github.com/canonical-websites/build.snapcraft.io/issues/1181?16:54
pstolowskipedronis: hey, i'm fighting with ensurebefore.. as soon as i enhance the "naive" fix with "if !o.ensureTimer.Stop() { <-o.ensureTimer.C }" it hangs around it16:55
diddledanI'm seeing the snaps again that had disappeared, but I'm not sure if it's because of a fix or just my dumb luck that I received a different set of data from the API when I refreshed (my bug was https://github.com/canonical-websites/build.snapcraft.io/issues/1175) but it seems identical to popeys16:55
diddledanpopey's16:55
mvozyga: thanks16:57
mvozyga: yeah, what I heard from abeato was that monday is ok but if not I can jump on it now16:58
zygamvo: I have the patch now16:58
zygareduced16:58
mvozyga: is there a PR yet? abeato was also keen to look at the details16:58
zygayes16:58
mvozyga: aha, nice - with pedronis suggestions?16:58
ChipacaI'm going to take a break for a while. Will bbl, in a couple of hours. If you go before I'm back, have a great weekend!16:59
zygayes16:59
zygasorry, messed up my branch names (wip vs fix) opened properly now17:00
mupPR snapd#6466 opened: cmd/snap-confine: handle death of helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>17:00
zygajdstrand: ^17:00
zygapedronis: ^ FYI17:00
zygaat least for _this_ test it works correctly17:00
zygaand feels like a safe thing to releae17:01
zyga*release17:01
zygathere are more children but this is the only pipe handling17:01
zyga(so yay)17:01
mvozyga: sweet, shorter17:01
zygayes, the test, now devoid of critical typos, is most of the code17:02
zygaI was thinking about a negative test17:02
zygaedit-out the sleep and see things work17:02
zygabut I will let everyone comment first17:02
zygaI ran main suite successfully with this change17:03
zygaand, surprisingly, it even works on 14.0417:03
pedroniszyga: thanks for checking out simplifying the change at least for now, have a bit of head ache so I will let other look at it today, calling it a week17:03
zygapedronis: that's a good plan :)17:03
pedronishave a great weekend!17:03
zygapedronis: likewise!17:06
zygajdstrand: note, this fixes a private consumer bug, I can subscribe you for context17:06
zygajdstrand: done now, you should be able to see the bug17:07
* zyga EOWs17:09
Lukewhdiddledan: We haven't released build.snapcraft.io recently, so I assume magic has made it work for you again. I'm going to leave your bug open as it still needs further investigation. Please update the bug if it happens again!17:20
diddledanwilldo17:20
diddledanthanks17:20
=== pstolowski is now known as pstolowski|afk
mupPR snapcraft#2457 opened: lifecyle: avoid installation of snaps in docker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2457>18:54
=== Howard is now known as Guest24234
mupPR snapcraft#2458 opened: clean: error out on invalid or missing yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2458>20:24
=== Luke_ is now known as LUke
=== LUke is now known as Luke
mupPR snapcraft#2459 opened: catkin plugin: describe how to build all packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2459>23:16

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!