| mup | PR snapd#6477 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6477> | 05:35 |
|---|---|---|
| mup | PR snapd#6479 opened: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6479> | 05:40 |
| mborzecki | morning | 06:10 |
| === phoenix_firebrd is now known as murthy | ||
| mborzecki | mvo: morning | 08:05 |
| mvo | mborzecki: hey, good morning | 08:05 |
| mborzecki | mvo: there was bit of trouble with osx builds yday, fortunately john reminded me of how yaml is super ambiguous about numerical vs string representation | 08:06 |
| mvo | mborzecki: yeah, I saw that, thank you! | 08:06 |
| mvo | mborzecki: I updated the 2.37 version now as well and removed esc.bold | 08:07 |
| mborzecki | mvo: i think we could cherry-pick the path warning for .2 too | 08:07 |
| mborzecki | oh, ok | 08:07 |
| mvo | mborzecki: yeah, we could, probably won't hurt either way | 08:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 08:12 |
| mborzecki | pstolowski: hey | 08:13 |
| pedronis | hello | 08:16 |
| mvo | hey pstolowski and pedronis | 08:23 |
| mborzecki | hey pedronis | 08:23 |
| mborzecki | we're down to 43 PRs, not bad | 08:23 |
| mvo | indeed and 6479 will land as soon as its green so 42 effectively | 08:24 |
| mup | PR snapd#6380 closed: interfaces: add more permissions to network-manager slot <Created by alfonsosanchezbeato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6380> | 08:29 |
| mup | PR snapd#5915 opened: interfaces/network-setup-control: allow calling netplan generate/apply <⛔ Blocked> <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915> | 08:30 |
| * dot-tobias waves hello | 09:03 | |
| mup | PR snapd#6479 closed: cmd/snap, overlord/snapstate: silently ignore classic flag when a snap is strictly confined (2.37) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6479> | 09:07 |
| Saviq | is there a way to force "prune" of old snap revisions? | 09:09 |
| pedronis | Saviq: in which sense? we keep a fixed number of them per snap | 09:16 |
| Chipaca | Saviq: snap list --all, and some scripting | 09:17 |
| Chipaca | Saviq: also, you can configure how many to keep, down to a minimum of 2 | 09:17 |
| Chipaca | Saviq: https://superuser.com/questions/1310825/how-to-remove-old-version-of-installed-snaps | 09:18 |
| Saviq | right, that! thanks | 09:22 |
| mup | PR snapd#6480 opened: release: 2.37.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6480> | 09:29 |
| zyga | hey | 09:36 |
| zyga | I'm just popping in briefly now | 09:36 |
| zyga | mvo: have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 ? | 09:36 |
| mup | Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141> | 09:36 |
| mvo | zyga: I have not, that sounds alarming | 09:37 |
| mvo | zyga: the second user who is affected is using 4.15 so it looks like its not disco only | 09:38 |
| zyga | yeah but it's not widespread either, I haven't seen this on any of my machines | 09:38 |
| zyga | I bet we're missing something | 09:38 |
| mvo | xnox: re 1814141> any denials in dmesg? (cc zyga) | 09:38 |
| mvo | zyga: yeah | 09:39 |
| zyga | oh, I didn't notice who reported it! | 09:39 |
| zyga | mvo: there's a new version of apparmor around 2.13 | 09:43 |
| zyga | mvo: wonder if that is related | 09:43 |
| zyga | mvo: but it doesn't feel like just apparmor, we would die on many other things before | 09:43 |
| pedronis | well, the error is very specific | 09:43 |
| pedronis | cannot read mount namespace identifier of pid 1 | 09:44 |
| pedronis | where do we do that? | 09:44 |
| zyga | we check if we are in pid-1 mount namespace | 09:44 |
| zyga | but | 09:45 |
| zyga | we do that after we check if we are confined or not | 09:45 |
| zyga | so either we are confined but the profile is no longer sufficient | 09:45 |
| zyga | or we are not confined at all (apparmor disabled on boot) but we get denied somehow? | 09:45 |
| zyga | perhaps this is a container so outer container profile is too strict | 09:45 |
| pedronis | or we lost the setuid bits? | 09:46 |
| popey | Chipaca: snap has "pack" - should it not also have an 'unpack'? Which does whatever unsquashfs does? | 09:46 |
| zyga | pedronis: I think we need to get more information from xnox | 09:47 |
| Chipaca | popey: nobody's asked for it :-) | 09:47 |
| pedronis | there is nothing really special into unpacking a snap | 09:47 |
| pedronis | zyga: mvo: also we do run tests on disco, no? | 09:49 |
| pedronis | but as root? | 09:49 |
| zyga | pedronis: no, we don't | 09:50 |
| zyga | pedronis: not in typical travis-spread run | 09:50 |
| mvo | pedronis: we should start that soon, when sergio is back | 09:50 |
| zyga | pedronis: we run many things as root but a single test running as an user would pick this up | 09:50 |
| zyga | (if it was totally broken) | 09:50 |
| mvo | I think we have some tests that run snaps as user | 09:51 |
| pedronis | ok | 09:52 |
| pedronis | anyway we need more info | 09:52 |
| mvo | yes, at least in the smoke suite some interface tests run as user we should probably add a very simple explict one still | 09:52 |
| * mvo does that | 09:52 | |
| zyga | mvo: fun idea: run prepare/restore as root, run execute as non-root | 09:53 |
| mup | PR snapd#6481 opened: tests: run test snap as user in the smoke test <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6481> | 10:10 |
| === murthy is now known as phoenix_firebrd_ | ||
| mvo | zyga: hm, interessting idea | 10:11 |
| Chipaca | pedronis: thank you for the review | 10:16 |
| pstolowski | mvo: will you have time to take a look at https://github.com/snapcore/snapd/pull/6322 (after release stuff is over)? | 10:20 |
| mup | PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322> | 10:20 |
| mvo | pstolowski: yeah, sounds like something for later today or tomorrow (assuming 1814141 isn't a new fire :/) | 10:23 |
| pstolowski | uhm | 10:28 |
| mborzecki | arch package updated | 10:43 |
| mvo | mborzecki: \o/ | 10:43 |
| mvo | pstolowski: we have a new beta 2.37.2 - if you still have the rpi around, helping with the validation would be most welcome, I created a trello card with the individual tasks | 10:47 |
| pstolowski | mvo: sure, will do | 10:48 |
| pedronis | Chipaca: hi, did you see my ping about doing a review pass on 6079 given you reviewed some of the prereq | 10:50 |
| Chipaca | pedronis: I did not | 10:55 |
| Chipaca | pedronis: on it now | 10:55 |
| pedronis | Chipaca: thank you | 10:55 |
| === phoenix_firebrd_ is now known as murthy | ||
| Chipaca | grah, we're being inconsistent with our help strings again :-( | 11:23 |
| pedronis | Chipaca: can't we write tests about some of the rules? or is too much NLP? | 11:25 |
| Chipaca | pedronis: we do have some tests | 11:25 |
| Chipaca | but apparently not one for this :-) | 11:25 |
| Chipaca | which makes me think maybe we didn't discuss & agree on it | 11:25 |
| pedronis | Chipaca: what is about? | 11:27 |
| pedronis | Chipaca: I mean, what more we should be consistent about and aren't ? | 11:31 |
| Chipaca | pedronis: sorry didn't see your q | 11:31 |
| Chipaca | pedronis: see "snap list --help" | 11:31 |
| Chipaca | pedronis: some options' description ends with a period, some don't | 11:32 |
| pedronis | Ah | 11:32 |
| Chipaca | it's silly but it irks :-) | 11:32 |
| pedronis | Chipaca: what is your preference? | 11:33 |
| Chipaca | pedronis: with | 11:34 |
| Chipaca | bah, in an ideal world with unicorns and flying cars and no climate change, all but the last option description ends with a ;, and the last one with a . | 11:35 |
| pedronis | Chipaca: do we more with or more without | 11:35 |
| mup | PR snapcraft#2455 closed: cli: retrieve error data from provider <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2455> | 11:35 |
| Chipaca | (fun fact: we'd have to i18n the ;) | 11:35 |
| Chipaca | pedronis: dunno, i'll look into this later | 11:35 |
| Chipaca | in the middle of the 'connections' pr | 11:35 |
| Chipaca | mborzecki: ping | 11:35 |
| pedronis | Chipaca: I don't the whole constute a sentence and there is scansion in other ways | 11:36 |
| mborzecki | Chipaca: pong | 11:36 |
| pedronis | Chipaca: so I don't have a strong opinion | 11:36 |
| Chipaca | pedronis: you a verb there | 11:36 |
| pedronis | Chipaca: oops, I don't think the whole of options constitue a sentence | 11:36 |
| Chipaca | mborzecki: if I disconnect all the connections of a snap, 'snap connections' doesn't notice | 11:36 |
| Chipaca | mborzecki: wondering if I'm holding it wrong | 11:37 |
| mborzecki | Chipaca: hmm | 11:37 |
| === murthy is now known as phoenix_firebrd_ | ||
| Chipaca | bah, "doesn't notice", that's not quite true | 11:37 |
| pedronis | Chipaca: fwiw, I'm slightly in favor of without myself ... but I'm interested whether we tended to do one or the other as well | 11:37 |
| pedronis | as I said no very strong opinion here, I do agree we shouldn't do both tough | 11:37 |
| pedronis | that is just sloppy | 11:38 |
| Chipaca | the difference is just very subtle | 11:38 |
| Chipaca | pedronis: same here | 11:38 |
| mborzecki | Chipaca: doesn't notice how? | 11:38 |
| Chipaca | mborzecki: sorry, it does, it's just very subtle | 11:39 |
| Chipaca | this is home, when you disconnect it: | 11:39 |
| Chipaca | icdiff:home :home home disconnected,manual | 11:39 |
| Chipaca | super clear it's disconnected | 11:39 |
| Chipaca | this is personal-files, when you disconnect it: | 11:39 |
| Chipaca | icdiff:gitconfig - personal-files - | 11:39 |
| pedronis | why the difference? | 11:40 |
| mborzecki | Chipaca: right, there is no slot, so no connection, we could show 'disconnected' in the notes column to make it clear | 11:40 |
| === phoenix_firebrd_ is now known as murthy | ||
| Chipaca | mborzecki: but home does show the slot it would connect to when disconnected | 11:41 |
| Chipaca | why are these so different when they're only different in their autoconnection | 11:41 |
| Chipaca | and that's just an assertion away | 11:41 |
| Chipaca | also, silly question, shouldn't removing a snap reset its connections? | 11:42 |
| Chipaca | if I disconnect something, remove the snap, and then install the snap, shouldn't it have the default connections connected? | 11:42 |
| mborzecki | Chipaca: afaik we keep the undersired conenctions in case you install it again | 11:42 |
| Chipaca | how do I tell it to connect that which it would've connected? | 11:43 |
| mborzecki | Chipaca: explicitly with snap connect | 11:43 |
| Chipaca | mborzecki: but that leaves it manually connected | 11:43 |
| Chipaca | icdiff:home :home home manual | 11:44 |
| mborzecki | Chipaca: yes, because it's a manual connection now | 11:44 |
| mborzecki | Chipaca: afaiu there's no going back to the intial state now | 11:45 |
| Chipaca | so how do i reset it to not be manual? | 11:45 |
| Chipaca | :-( | 11:45 |
| mborzecki | Chipaca: so the difference in presentation, what about showing (dis|un)connected in the notes column when there was no slot for a plug? | 11:46 |
| Chipaca | mborzecki: what does --all do when you specify a snap? | 11:46 |
| Chipaca | mborzecki: +1 to show disconnected when it's disconnected | 11:47 |
| mborzecki | Chipaca: --all is quite useless when you name a snap unfortunately, but i didn't error out there | 11:47 |
| mborzecki | Chipaca: we're back at https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/5 with parameters and presentation | 11:48 |
| Chipaca | mborzecki: playing with it "for real" always iterates these things | 11:49 |
| mborzecki | Chipaca: mhm | 11:50 |
| Chipaca | mborzecki: some more comments on the PR itself | 11:51 |
| mborzecki | Chipaca: thanks! | 11:51 |
| Chipaca | mborzecki: https://i.imgur.com/9s6nQG4.png ? | 11:58 |
| Chipaca | (that is: dim repeated snap names?) | 11:58 |
| mborzecki | Chipaca: fancy | 11:59 |
| Chipaca | hm, i should add a 'dim' property to escapes, separately | 11:59 |
| Chipaca | mborzecki: don't get me wrong the pr looks good | 12:01 |
| Chipaca | mborzecki: i'm just wanting to be super nitpicky about ux because we got it wrong three times already :-) | 12:01 |
| mborzecki | hahah :) | 12:02 |
| mup | PR snapd#6482 opened: [RFC] cmd/snap: make 'snap list' show disabled snaps dimmed <Created by chipaca> <https://github.com/snapcore/snapd/pull/6482> | 12:23 |
| * Chipaca had his fun, and now goes for lunch | 12:23 | |
| jdstrand | mvo, zyga: fyi, I'm going to start looking at apparmor 2.13 for disco soon (assuming I can ever get away from things that keep preempting it :\) | 12:48 |
| zyga | ack | 12:51 |
| zyga | jdstrand: suse has it now | 12:52 |
| jdstrand | so does Debian | 12:52 |
| zyga | yes, I think I saw it in sid as well | 12:56 |
| pedronis | Chipaca: thanks for #6356, a few small comments still | 12:56 |
| mup | PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356> | 12:56 |
| === ricab is now known as ricab|lunch | ||
| zyga | mvo: fedora builds under way, I will keep you posted, going back to bed :/ | 13:00 |
| roadmr | zyga: bed? are you sick... oh wait I know why you're sleep deprived! hang in there! | 13:02 |
| zyga | roadmr: yeah, sick | 13:02 |
| roadmr | oh ouch :( get better, zyga | 13:02 |
| zyga | thank you :) | 13:02 |
| zyga | jdstrand: can you look at https://launchpadlibrarian.net/409976796/journalctl__grep_DENIED__tail.txt | 13:19 |
| zyga | this is from https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1814141 | 13:20 |
| mup | Bug #1814141: fail to run any snap after snapd refresh, reinstalling snapd from the archive is a temporary fix <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1814141> | 13:20 |
| zyga | jdstrand, mvo: I added a hypothesis to that bug report | 13:23 |
| pstolowski | jezz pi3 tests are soo sloow, 195/262 and it's already over 3h | 13:27 |
| zyga | mborzecki: ping | 13:46 |
| === ricab|lunch is now known as ricab | ||
| Son_Goku | niemeyer, mvo, Chipaca, zyga, mborzecki: so snappy variant is now a thing in fedora-release: https://src.fedoraproject.org/rpms/fedora-release/c/f171adca021ec0a2c599ce7c87f841c7face5f69?branch=master | 14:27 |
| Son_Goku | :D | 14:27 |
| Chipaca | woop woop :-) | 14:28 |
| mborzecki | Son_Goku: nice! | 14:28 |
| zyga | thank you, that's a great milestone! | 14:28 |
| Son_Goku | now I just need to simplify and rework my tool for building the base snap | 14:28 |
| Chipaca | Son_Goku: a SMOP | 14:29 |
| Chipaca | :-) | 14:29 |
| Son_Goku | ? | 14:29 |
| Son_Goku | haha | 14:30 |
| Son_Goku | indeed it is | 14:30 |
| niemeyer | Son_Goku: Woo, nice! | 14:31 |
| Son_Goku | now I just need snapcraft to know how to consume fedora content using dnf | 14:31 |
| mvo | Son_Goku: woah, amazing! | 14:31 |
| * mvo hugs Son_Goku | 14:31 | |
| Son_Goku | 😊 | 14:32 |
| Son_Goku | niemeyer, do you think you could see if snapcraft folks would prioritize integrating support for dnf as a backend as an alternative to apt? | 14:32 |
| Son_Goku | I'm fairly confident by now that I'll have fedora releng pushing official base snap stuff for fedora 30 | 14:33 |
| Son_Goku | I just need to figure out _what_ should be in it :P | 14:33 |
| Chipaca | sergiusens: ^ | 14:34 |
| niemeyer | Son_Goku: It seems reasonably easy.. not sure if the snapcraft folks (e.g. Sergio :-) would do that first, or if it might be easier to just contribute an initial patch that abstracts the package management away | 14:36 |
| Son_Goku | I did write a skeleton patch to separate the backend from the interface two years ago | 14:36 |
| niemeyer | Son_Goku: If nothing else, that would make it easier to discuss the design | 14:36 |
| Son_Goku | I'll need to check how much of that is needed now with snapcraft 3.0 | 14:36 |
| Son_Goku | sure | 14:37 |
| niemeyer | Son_Goku: It probably hasn't changed much, and it should now also be easier to integrate it nicely since we have proper base (IOW, multi image) support | 14:37 |
| Son_Goku | right | 14:37 |
| Son_Goku | niemeyer, part of this is that if there are problems with DNF interfaces/APIs, we can start poking the DNF team to look at fixing them | 14:37 |
| Son_Goku | if we can't fix them ourselves, that is | 14:37 |
| Son_Goku | as a package manager developer, you better than anyone else can understand how "weird" snapcraft's use-case is | 14:38 |
| niemeyer | Son_Goku: Once you have a better idea of how this should work, feel free to schedule (or ask to) a meeting with you, sergiusens, cmatsuoka, pedronis, and myself | 14:38 |
| Son_Goku | will do, though I can't say I know who cmatsuoka is? | 14:38 |
| niemeyer | He's hanging here.. Claudio Matsuoka.. he's recently joined the team and will be working on snapcraft in the next few weeks at least | 14:39 |
| Son_Goku | nice | 14:39 |
| Son_Goku | well, for the moment, I'm focused on getting the base snap work done | 14:39 |
| Son_Goku | but it's something that's on my infinitely long TODO :) | 14:40 |
| jdstrand | pedronis: hey, I'm looking at https://github.com/snapcore/snapd/blob/master/interfaces/policy/policy.go#L98 | 14:43 |
| jdstrand | pedronis: meh, nm for the moment | 14:44 |
| jdstrand | pedronis: no, actually, that function is checking the slots (snap decl, then base) then checking the plugs (snap decl, then base) | 14:45 |
| pedronis | jdstrand: sorry, not following what you are pointing to | 14:46 |
| jdstrand | pedronis: such that, if there is an error (aka, aiui, something that would prevent installation), then something in the slots that prevented installation would preempt something in the plugs that might allow it | 14:47 |
| jdstrand | pedronis: checkSlot will look at snap then base | 14:47 |
| pedronis | jdstrand: that is correct | 14:47 |
| pedronis | slots and plugs are orthogonal at that level | 14:47 |
| pedronis | it's not like connections | 14:47 |
| pedronis | you cannot unblock installing a slot | 14:48 |
| jdstrand | I was expecting the logic to be different | 14:48 |
| pedronis | by telling something about plugs | 14:48 |
| jdstrand | I see | 14:48 |
| pedronis | that wouldn't make sense | 14:48 |
| pedronis | jdstrand: I mean that logic is correct and doing otherwise feels like would be wrong security wise | 14:50 |
| jdstrand | pedronis: ok. basically, I'm rewriting the snap decl checks in the review tools to use the same procedure as snapd. I chose installation since it was before connection in the file, but it has a different algorithm that I don't need to worry about. thanks for clearing that :) | 14:50 |
| pedronis | jdstrand: but I can confirm, connection checks and installation checks are very different | 14:51 |
| pedronis | jdstrand: for connection is about can this plug be connected to that slot, but sides have a voice | 14:52 |
| * jdstrand nods | 14:52 | |
| pedronis | jdstrand: for installation, is can I install a snap sporting a plug of this interface, can I instal a snap sporting this slot? and plug and slot of the same interface on a snap are really unrelated for this | 14:53 |
| jdstrand | yeah | 14:53 |
| jdstrand | that isn't expressed in the spec afaics, so that would be another point to finetune | 14:53 |
| jdstrand | ok, thanks! that reminder helps a lot | 14:54 |
| pstolowski | mvo: when the beta validation test says "(for snapd promotion)", does it mean anything for the test? | 14:56 |
| cmatsuoka | Son_Goku: looking at how dpkg support was implemented, adding support to dnf/rpm shouldn't be too hard | 15:04 |
| mvo | pstolowski: its just a reminder for myself | 15:04 |
| mvo | pstolowski: this means this particular test is used to test the snapd snap | 15:05 |
| mvo | pstolowski: the other tests are about the "core" snap | 15:05 |
| Saviq | hey, does `snap` have a way to wait for snapd to be ready? | 15:05 |
| mborzecki | Son_Goku: posted karma for EPEL update | 15:05 |
| Son_Goku | cmatsuoka, I already contributed support to dump rpms a couple of years ago | 15:05 |
| mvo | pstolowski: so in theory we could release core once all tests are done and later snapd (once those tests are done) | 15:05 |
| mvo | pstolowski: does that make sense? | 15:05 |
| Son_Goku | cmatsuoka, it's just that adding proper support for an rpm distro as a repo source was really hard | 15:05 |
| cmatsuoka | Son_Goku: it would certainly require a lot of tests and experimentation after the basic support is in place | 15:08 |
| cmatsuoka | Son_Goku: what were the main problems you found back then? | 15:08 |
| pstolowski | mvo: hmm, kind of; i don't know how to run "beta validation core18 - fresh install pi3 (for snapd promotion)" then per sergio's instructions | 15:08 |
| Son_Goku | cmatsuoka, well, back then, I couldn't figure out how to make the code do the right thing | 15:09 |
| Son_Goku | because snapcraft didn't know bases | 15:09 |
| pstolowski | mvo: sounds like it's more than just installing beta of core18 on pi3 and running the tests with dev_snapd_pi_18 | 15:10 |
| cmatsuoka | Son_Goku: oh I see. it should be easier now :) | 15:10 |
| Son_Goku | and also, snapcraft goes back and forth between in chroot and out of chroot | 15:10 |
| mvo | pstolowski: that should be enough, use the fresh image of UC18 generator with the validator thing and run the dev_snapd_pi_18 | 15:10 |
| mvo | pstolowski: that should be ok | 15:10 |
| Son_Goku | and one other problem is that the package manager likes to record its stuff in the databases in /var/lib/rpm and /var/lib/dnf | 15:10 |
| pstolowski | mvo: allright | 15:10 |
| pstolowski | mvo: thanks | 15:10 |
| Son_Goku | and we _need_ that information to be writable during snap build time | 15:11 |
| Son_Goku | or rather $SNAP/var/lib/rpm and $SNAP/var/lib/dnf | 15:11 |
| Son_Goku | we can obviously not include them on the layered snap, but the way the package manager works requires that | 15:12 |
| Son_Goku | and of course, figuring out how to block "updating" base libraries | 15:12 |
| Son_Goku | the last part, I have an idea for, but the others I don't | 15:12 |
| cmatsuoka | Son_Goku: so now you could theoretically use a fedora base in the build provider, install all the packages you need there during the snap build | 15:15 |
| Son_Goku | right | 15:15 |
| cmatsuoka | the build provider being a multipass vm | 15:15 |
| Son_Goku | oh right | 15:15 |
| Son_Goku | we don't have multipass in Fedora yet... | 15:15 |
| cmatsuoka | it's installabe as a snap | 15:16 |
| Son_Goku | and in fedora infra, we have to be able to run snapcraft in a chroot | 15:16 |
| cmatsuoka | I run multipass on a bare metal fedora, it works well | 15:16 |
| Son_Goku | I thought multipass only makes ubuntu VMs? | 15:16 |
| Son_Goku | that's not particularly useful in this case | 15:17 |
| cmatsuoka | but wait, let me understand exactly what you are trying to accomplish here :) | 15:17 |
| Son_Goku | I want: | 15:17 |
| Son_Goku | 1. to be able to build snaps using a fedora base | 15:17 |
| Son_Goku | 2. to be able to use snapcraft for snaps to be built on top of the fedora base, even officially by fedora packagers | 15:17 |
| Son_Goku | 3. to be able to run snapcraft within Koji, the fedora build system | 15:18 |
| cmatsuoka | ok. then you need snapcraft to recognize fedora (or a specific version of fedora) as a base. then during the build process snapcraft would instance a fedora VM, install rpm packages, stage, prime and produce the snap | 15:19 |
| cmatsuoka | at runtime, you would need a fedora base image to support the snap created on top of the fedora base VM | 15:20 |
| Son_Goku | the main issue is that Koji does not allow VM creation | 15:21 |
| Son_Goku | Koji instantiates target-specific chroots, and runs the stuff in there | 15:21 |
| Son_Goku | and they're not privileged enough to spin up VMs | 15:21 |
| cmatsuoka | can we run lxd containers there? | 15:22 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| cmatsuoka | we should have support to lxd providers in some near future | 15:22 |
| Son_Goku | no | 15:22 |
| Son_Goku | no lxd packaged in fedora, and no support in koji | 15:23 |
| Son_Goku | the former would be required for the latter | 15:23 |
| cmatsuoka | I also run lxd from snap on my fedora system, but you probably want something more "native" | 15:24 |
| cmatsuoka | I can't say for sure if snapcraft would work with a plain chroot provider, perhaps sergiusens could enlighten us here | 15:25 |
| sergiusens | cmatsuoka: we have nothing built out for chroots today | 15:26 |
| cmatsuoka | sergiusens: but that would be feasible? | 15:28 |
| sergiusens | cmatsuoka: I suspect --destructive-mode could work and then it could be just like those docker images people build | 15:28 |
| cmatsuoka | sergiusens: yes, that's my feeling as well | 15:28 |
| cmatsuoka | Son_Goku: so you could set up your chroot, put snapcraft and the source project there, and run snapcraft in destructive mode inside the chroot | 15:30 |
| cmatsuoka | Son_Goku: the dnf-aware snapcraft | 15:30 |
| Son_Goku | okay, so there's a mode there | 15:31 |
| cmatsuoka | Son_Goku: yes, currently the default is to use a build provider such as multipass (and, in fact, it's the only provider available right now) | 15:32 |
| cmatsuoka | Son_Goku: but you can also tell snapcraft to not use the provider, and run in the host environment | 15:32 |
| cmatsuoka | this is the "destructive mode" | 15:33 |
| Son_Goku | does multipass use libvirt? | 15:33 |
| Son_Goku | ah, so it does | 15:33 |
| Son_Goku | it'd be cool if it was packaged in Fedora and could use the Fedora-published VM images | 15:34 |
| Son_Goku | or at least if the snap could make fedora VMs too | 15:34 |
| cmatsuoka | currently multipass itself is packaged as a snap and runs on fedora, but I don't know if there's a fedora image availability | 15:37 |
| cmatsuoka | s/availability/available right now/ | 15:38 |
| Saviq | hey all, is there a `snap waitforready` of some kind that will ensure I'm not calling `snap install` before snapd is ready? | 15:38 |
| Chipaca | Saviq: yes | 15:39 |
| Chipaca | Saviq: there's even a service that uses that, that we use in cloud? i think? | 15:39 |
| Chipaca | Saviq: snapd.seeded.service | 15:40 |
| Chipaca | Saviq: does a "snap wait system seed.loaded" | 15:40 |
| cmatsuoka | Saviq: do we have any fedora image available for multipass? | 15:40 |
| Saviq | Chipaca: the socket doesn't exist yet here so that won't work... | 15:41 |
| Chipaca | Saviq: whoa | 15:41 |
| Chipaca | Saviq: how does the socket not exist yet? what's starting your thing? | 15:41 |
| Saviq | Chipaca: lxd container | 15:42 |
| Chipaca | Saviq: 1. wait for the socket (it should get created really early in boot) | 15:42 |
| Chipaca | Saviq: 2. as above :-) | 15:42 |
| Chipaca | Saviq: is it a systemd unit? | 15:42 |
| Saviq | Chipaca: no, just driving snapcraft from outside the container | 15:42 |
| Chipaca | Saviq: note the socket gets created before the snapd binary is started | 15:43 |
| Saviq | I know, socket activated | 15:43 |
| Chipaca | yup | 15:43 |
| Chipaca | meaning it's in relatively early boot | 15:43 |
| Saviq | but still, I get ENOFILE when trying to install a snap | 15:43 |
| hunterk | new installs of my snap package (i.e., not updates) have started complaining about "mkdir: cannot create directory ‘/home/[username]/snap/[packagename]’: Read-only file system". Does anyone know what would cause this? | 15:43 |
| Saviq | oh well, will get bash to wait for the socket | 15:43 |
| Saviq | or just try to install a couple times ;P | 15:44 |
| Chipaca | pedronis: in laneSnaps, your argument to pass in the tasks seems to mean I should actually pass in the rerefresh task (so the id and tasks are obviously in sync) | 15:44 |
| Saviq | cmatsuoka: I've not tried, but https://alt.fedoraproject.org/cloud/ should work | 15:44 |
| Saviq | as long as it has cloud-init | 15:44 |
| pedronis | Chipaca: that makes sense | 15:44 |
| cmatsuoka | Son_Goku: ^^ | 15:44 |
| Chipaca | pedronis: it's going to break the unit tests :-) but easy to fix | 15:45 |
| Son_Goku | it does have cloud-init | 15:45 |
| pedronis | Chipaca: yes, it's a change, but I tried to explain why I think it makes sense :) | 15:45 |
| Saviq | Son_Goku: `snap install multipass --classic --beta; multipass launch https://...` will tell you soon enough whether it works or not | 15:45 |
| Chipaca | pedronis: i agree | 15:46 |
| Son_Goku | I'll have to try that later, then :) | 15:46 |
| mup | PR snapcraft#2460 closed: build providers: recreate instance if base changed <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2460> | 15:50 |
| Saviq | Son_Goku: fwiw the OpenStack image seems to work fine, there's probably rough edges as we're assuming dpkg inside at the moment | 15:54 |
| Son_Goku | yeah | 15:54 |
| Saviq | also a bug in our snap packaging prevents the `launch https://` from working - need to download the image and `launch file://` | 15:55 |
| Saviq | and `dnf makecache` takes quite a while, we should not wait for that | 15:56 |
| mup | PR snapcraft#2462 opened: Release changelog for 3.1.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2462> | 15:56 |
| Saviq | Son_Goku: feel free to file bugs under https://github.com/CanonicalLtd/multipass/issues/new as you encounter them :) | 15:57 |
| Saviq | hey all, we want to transition multipass to core18 and realized there's a case where the upgrade needs user intervention to avoid data loss, what's the state-of-the-art approach to this situation? forcing a rollback (how)? failing one of the hooks (which)? | 16:16 |
| Saviq | epochs are not a thing yet, are they? would they be of help? | 16:16 |
| JnR | Oh thank god a Snap chat | 16:16 |
| JnR | modprobe: FATAL: Module msr not found in directory /lib/modules/4.15.0-45-generic | 16:16 |
| JnR | Wtf is msr? | 16:16 |
| JnR | I was building a Snap with lxd | 16:17 |
| JnR | I have Linux Mint | 16:17 |
| JnR | Sorry I meant how do I get the msr. I have an idea what it is | 16:18 |
| Saviq | JnR: hey, this module lets you ~interrogate the BIOS to find out about virtualization support | 16:18 |
| Saviq | JnR: would you please file an issue in https://github.com/CanonicalLtd/multipass/issues/ | 16:19 |
| Saviq | JnR: and in the mean time run `kvm-ok` that will guide you through ensuring your system can build snaps through multipass | 16:19 |
| Saviq | some reading about why that's needed https://forum.snapcraft.io/t/reasoning-behind-the-move-to-multipass/9648 | 16:20 |
| JnR | Saviq at what point run kvm-ok? in substitute of snapcraft? | 16:20 |
| JnR | I haven't heard that command mention in any articles | 16:21 |
| Saviq | JnR: just once, now is fine | 16:21 |
| Saviq | the msr module won't be needed if kvm is already set up proper | 16:21 |
| mup | PR # closed: snapd#5644, snapd#5915, snapd#5962, snapd#6034, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, | 16:21 |
| mup | snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6406, snapd#6410, snapd#6413, snapd#6418, snapd#6436, snapd#6464, snapd#6465, snapd#6469, snapd#6472, snapd#6476, snapd#6478, snapd#6480, snapd#6481, snapd#6482 | 16:21 |
| JnR | INFO: /dev/kvm exists | 16:23 |
| mup | PR # opened: snapd#5644, snapd#5915, snapd#5962, snapd#6034, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, | 16:23 |
| mup | snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6406, snapd#6410, snapd#6413, snapd#6418, snapd#6436, snapd#6464, snapd#6465, snapd#6469, snapd#6472, snapd#6476, snapd#6478, snapd#6480, snapd#6481, snapd#6482 | 16:23 |
| JnR | KVM acceleration can be used | 16:23 |
| JnR | Is that the appropriate response? | 16:23 |
| === phoenix_firebrd is now known as murthy | ||
| Saviq | JnR: yes, can you please run snapcraft now and if it fails, please pastebin the whole log? | 16:23 |
| JnR | Saviq Yes sir | 16:24 |
| JnR | https://pastebin.com/LvAxLmfP | 16:28 |
| JnR | I ran it in debug mode | 16:28 |
| JnR | https://pastebin.com/RaXcfRFH | 16:29 |
| JnR | Sorry I forgot the 2nd half | 16:29 |
| ChrisTownsend | The real question is why isn't `/dev/kvm` there? | 16:30 |
| ChrisTownsend | That's the first check the script does and if that fails, it detects if the msr module is available, and if not, it tries to load it. | 16:30 |
| ChrisTownsend | JnR: Does `/dev/kvm` exist on your machine? | 16:31 |
| JnR | ChrisTownsend yes I just ran kvm-ok 5 minutes ago | 16:31 |
| JnR | INFO: /dev/kvm exists | 16:31 |
| ChrisTownsend | JnR: Ok, hmm... | 16:32 |
| JnR | KVM acceleration can be used | 16:32 |
| JnR | ChrisTownsend I did read that Linux Mint has problems. I don't know why but it was the only OS they mentioned | 16:32 |
| ChrisTownsend | JnR: I wonder if it somehow blocks even classic installed snaps from accessing /dev. | 16:33 |
| greyback | JnR: you mentioned you are using lxd? How exactly? | 16:33 |
| ChrisTownsend | Just guessing, I have no proof at all. | 16:34 |
| ChrisTownsend | greyback: I think multipass is being used and not lxd. | 16:34 |
| JnR | https://docs.snapcraft.io/build-on-lxd/4157 | 16:34 |
| JnR | That's what I was following | 16:35 |
| Saviq | yeah with `base: $anything` multipass is used by default these days | 16:35 |
| greyback | aha, then that's a problem, as lxd installed from a snap does not have /dev/kvm access | 16:36 |
| greyback | running multipass inside lxd fails with that exact error | 16:36 |
| JnR | greyback Seriously? No wonder I'm running in circles | 16:36 |
| Saviq | oh you're *inside* lxd | 16:37 |
| JnR | I thought the snapcraft website would be a good place to start... | 16:37 |
| ChrisTownsend | I didn't realize snaps could be installed inside a lxd container... | 16:37 |
| ChrisTownsend | But yeah, I guess that makes sense:) | 16:38 |
| JnR | No wonder It took me 2 hours to get it to calm down about multipass | 16:38 |
| greyback | JnR: unfortunately yeah. You're better off avoiding lxd for now. | 16:38 |
| Saviq | sergiusens: https://docs.snapcraft.io/build-on-lxd/4157 seems like could need some love... | 16:38 |
| Saviq | s/need/use/ | 16:38 |
| Chipaca | sergiusens: degville wrt build-on-lxd, maybe just a warning at the top "this only applies if you don't have base:"? | 16:44 |
| Chipaca | oh it already has that | 16:44 |
| Chipaca | hmm | 16:44 |
| Chipaca | ¯\_(ツ)_/¯ | 16:44 |
| degville | Chipaca: mmm... I could make it clearer, rather than easily skipoverable. | 16:46 |
| Chipaca | so the problem was that that document explains how to make snapcraft build inside lxd | 16:47 |
| Chipaca | which is different from running snapcraft inside lxd to build in whatever | 16:48 |
| Chipaca | at least AIUI | 16:48 |
| JnR | What's the point of a disclaimer if it's not going to work? | 16:48 |
| JnR | Unless the disclaimer said "Doesn't work" of course | 16:49 |
| Saviq | JnR: it is going to work, *if* you snapcraft.yaml does not have "base: " stanza in it | 16:49 |
| Chipaca | JnR: Saviq: hold on | 16:50 |
| Saviq | ok /me backs out anyway | 16:50 |
| JnR | Saviq ohhhh ok I have no idea what you mean | 16:50 |
| Chipaca | JnR: Saviq: that document that JnR pointed to, explains how to set up snapcraft to build things using lxd instead of multipass | 16:50 |
| JnR | Chipaca Was I not supossed to use Multipass at all? | 16:51 |
| Chipaca | Saviq: I don't know if the document is still accurate, you know more than (or as much as) I do probably about that | 16:51 |
| Chipaca | JnR: what you are trying to do is _something completely different_ | 16:51 |
| Chipaca | JnR: but, due to the limitations of language, it's hard to explain the difference between getting into a riddle | 16:51 |
| Chipaca | JnR: you're running snapcraft inside lxd, and want to use it to build things inside there | 16:52 |
| JnR | Chipaca I'm fine with that but I just want to make it a point I followed the guide decently | 16:52 |
| Chipaca | JnR: so the question is, how did you follow a guide that tells you how to make snapcraft run lxd, and ended up having lxd run snapcraft | 16:53 |
| JnR | Chipaca Of course you're going to make me feel foolish now you know an exponential amount more than me | 16:53 |
| Chipaca | JnR: be nice | 16:53 |
| Saviq | JnR: if you're already in a container dedicated to this build, run `snapcraft --destructive-mode` | 16:54 |
| JnR | Chipaca Sorry I'm kinda joking my bad. But I was not in a container | 16:54 |
| Saviq | it is destructive because it will try and install packages in there | 16:54 |
| JnR | I started the container I didn't go in it | 16:54 |
| * Saviq biab | 16:54 | |
| JnR | I thought it was basically a virtual environment | 16:55 |
| JnR | Sometimes you guys forget what it's like to learn this subject | 16:58 |
| ChrisTownsend | JnR: Are you using snapcraft from the archive or from the snapcraft snap? | 16:58 |
| JnR | ChrisTownsend I downloaded everything from Snap | 16:59 |
| ChrisTownsend | JnR: I see "load_entry_point('snapcraft==2.43.1+18.4', 'console_scripts', 'snapcraft')()" which leads me to believe you are using the archive version. | 16:59 |
| ChrisTownsend | JnR: Can you run "which snapcraft" and give me the output? | 16:59 |
| JnR | I used snap to download and after some error I refreshed everything as well | 16:59 |
| JnR | usr/bin/snapcraft | 17:00 |
| ChrisTownsend | JnR: Ah, ok, this is your problem. It's defaulting to the old, incompatible version. Can you try `/snap/bin/snapcraft --help` just to see if that is there? | 17:01 |
| JnR | ok | 17:02 |
| ChrisTownsend | JnR: Also, `/snap/bin` in your $PATH is last, so your system will try to use other executables first. | 17:02 |
| JnR | https://pastebin.com/sjHFpYbm | 17:03 |
| JnR | Your first request | 17:03 |
| JnR | '/snap/bin' is in my path. I put it there and just checked again | 17:04 |
| ChrisTownsend | JnR: Ok, that is what we need...but that traceback is due to the exported `SNAPCRAFT_BUILD_ENVIRONMENT=lxd` env var. | 17:04 |
| sergiusens | JnR: on lxd, considering that you are on the correct image, you can use `--destructive-mode` | 17:05 |
| JnR | I'm assuming that's like --force? | 17:05 |
| ChrisTownsend | JnR: Is it first in your path or last? | 17:05 |
| ChrisTownsend | `/snap/bin` that is. | 17:06 |
| JnR | '/var/lib/snapd/snap/bin:/snap/bin:/var/lib/snapd/snap/bin' this is the end of my $PATH | 17:06 |
| JnR | It's a fresh Linux install theres not much | 17:07 |
| ChrisTownsend | JnR: Also, let's try to clean up from this and start afresh... | 17:07 |
| sergiusens | JnR: yes, in some ways, just more in your face wrt potential damage to the system where it is run on | 17:07 |
| ChrisTownsend | JnR: So first, unset `SNAPCRAFT_BUILD_ENVIRONMENT=lxd` by doing `SNAPCRAFT_BUILD_ENVIRONMENT=`. | 17:07 |
| ChrisTownsend | JnR: Then do `snapcraft clean` (not the /snap/bin/ version). | 17:08 |
| ChrisTownsend | JnR: Then I think you will want to just use multipass instead of lxd since that is the way things are going. I know, the tutorial you are referring to, but I think it would be better to go the multipass way. | 17:10 |
| ChrisTownsend | JnR: Then you can do `export SNAPCRAFT_BUILD_ENVIRONMENT=multipass` | 17:10 |
| ChrisTownsend | JnR: And then you should just be able to do `/snap/bin/snapcraft` | 17:11 |
| ChrisTownsend | JnR: I hope this helps. | 17:11 |
| JnR | But the reason I went towards lxd was the warning about Linux Mint having trouble with the base method | 17:11 |
| JnR | Is that not correct? | 17:12 |
| JnR | I'm pretty much quoting | 17:12 |
| ChrisTownsend | JnR: I'm not familiar with that warning. Do you have a link I can read or the such? | 17:13 |
| ChrisTownsend | JnR: Also, which snap are you trying to build? I'd like to look at its snapcraft.yaml and see if it's defining a base. | 17:14 |
| JnR | ChrisTownsend Actually I tried a guide previously that mentioned Mint... Damn it was probably outdated. My snapcraft.yaml is terrible I was using trial and error when I hit that bump. I just ran snapcraft again and it went great except for some of my files being misplaced | 17:18 |
| JnR | ChrisTownsend I mean I mistyped their location | 17:18 |
| JnR | An error occurred when trying to execute 'sudo -i snapcraft snap' with 'multipass': returned exit code 2. | 17:18 |
| JnR | I did get this error though | 17:18 |
| JnR | I didn't use sudo I swear | 17:19 |
| ChrisTownsend | JnR: Sorry, I got disconnected...could you repeat the last couple of things you said? | 17:19 |
| JnR | An error occurred when trying to execute 'sudo -i snapcraft snap' with 'multipass': returned exit code 2. | 17:19 |
| JnR | That was the only real error I got that wasn't my misspelling | 17:20 |
| sergiusens | Chipaca: btw, for the highly requested `--use-lxd` I would need a non root user way to retrieve the currenly installed snapcraft and its base (or core). | 17:20 |
| JnR | I didn't use sudo | 17:20 |
| JnR | Nvm it went away on debug. All is well | 17:21 |
| JnR | Thanks for the help | 17:21 |
| ChrisTownsend | JnR: So it's working? | 17:23 |
| sergiusens | mvo: hey there! Just a reminder that you never got back to me on https://bugs.launchpad.net/snapcraft/+bug/1805219 | 17:23 |
| mup | Bug #1805219: .snapcraft <19.04> <19.04-external> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1805219> | 17:23 |
| JnR | ChrisTownsend My only problem left is just that it's saying my binary files don't exist. Probably just a typo | 17:25 |
| JnR | I'm not using to referring to exe files in linux | 17:25 |
| pedronis | mborzecki: are you reusing anything from #6464 in the end? | 17:26 |
| === murthy is now known as phoenix_firebrd_ | ||
| mup | PR #6464: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6464> | 17:26 |
| ChrisTownsend | JnR: Ok, good luck! | 17:28 |
| JnR | ChrisTownsend Sorry I'm so close and I'm clearly not formatting this file correctly. One more favor | 17:30 |
| JnR | https://pastebin.com/DKV7cjjS | 17:30 |
| JnR | I know it's probably totally jacked up I just kinda went with trial and error | 17:30 |
| JnR | I can't load the files properly | 17:31 |
| ondra | sergiusens seems like passthrough is not passing through. is there some extra level of intelligence in passthrough? | 17:35 |
| === phoenix_firebrd_ is now known as murthy | ||
| ChrisTownsend | JnR: Well, the 'base: core18' in there explains why multipass was being used in your example. But as far as the snapcraft.yaml, yeah, I'm not really sure what you are trying to accomplish there. Maybe someone else here that is an expert on this can help??? | 17:52 |
| pedronis | pstolowski: I did (re)reviews of the current hotplug PRs | 17:53 |
| pstolowski | pedronis: great, thank you | 17:54 |
| mvo | sergiusens: thanks, looking | 17:58 |
| pstolowski | pedronis: replied | 18:06 |
| pstolowski | (to some suggestions, not all) | 18:06 |
| pstolowski | mvo: pi3 just finished for me, two failures this time - smoke/install and sanbox; these are the ones that failed 2.37.1 validation right? | 18:07 |
| pstolowski | *pi3 tests | 18:07 |
| mvo | pstolowski: I look at the failures | 18:08 |
| mvo | pstolowski: can you please paste me the failures? | 18:08 |
| pstolowski | mvo: http://paste.ubuntu.com/p/K84f6yWmmq/ | 18:09 |
| mvo | pstolowski: those look like test issues to me, re-running those would be great | 18:11 |
| mvo | pstolowski: maybe tomorrow? | 18:11 |
| pstolowski | mvo: sure | 18:12 |
| pstolowski | eod for now, cu | 18:12 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | pstolowski|afk: just the two that failed, I'm almost 100% positive this will be fine | 18:12 |
| mvo | pstolowski|afk: enjoy - thanks for your help today! | 18:12 |
| pstolowski|afk | o/ | 18:12 |
| Saviq | hey all, we want to transition multipass to core18 and realized there's a case where the upgrade needs user intervention to avoid data loss, what's the state-of-the-art approach to this situation? forcing a rollback (how)? failing one of the hooks (which)? | 18:28 |
| Saviq | epochs are not a thing yet, are they? would they be of help? | 18:28 |
| mup | PR snapd#6464 closed: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6464> | 18:28 |
| mup | PR snapcraft#2463 opened: Pass --work-dir param for out-of-tree builds <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2463> | 18:54 |
| pedronis | Chipaca: I answered your question, also somehow I missed the FileName suggestion, anyway I would keep Filename | 19:25 |
| Chipaca | k | 19:25 |
| Chipaca | pedronis: thanks | 19:26 |
| Chipaca | pedronis: i'm going to ignore it until the morning :-) | 19:26 |
| bashfulrobot | Quick question I hope. With snapcraft 3, the cleanbuild command is not longer allows when using the base keyword. What is the proper way to build with a clean environment? | 20:04 |
| bashfulrobot | oh, think I found it. set `SNAPCRAFT_BUILD_ENVIRONMENT multipass` and then simply the `snapcraft` command. | 20:09 |
| roadmr | bashfulrobot: jeopardy answer (I don't know, just throwing it out there so it sticks on the wall maybe?) - all builds are done in a multipass vm and so are a "clean environment" by default | 20:09 |
| bashfulrobot | roadmr: I think you are right | 20:10 |
| roadmr | \o/ | 20:10 |
| bashfulrobot | Unless you set 'host', 'managed-host', or 'multipass' | 20:10 |
| roadmr | ah, I didn't know about those :) | 20:17 |
| sergiusens | bashfulrobot: cleanbuild is still there if not using bases, no need to play with those environment variables | 20:23 |
| JnR | Apparently since earlier I've been stuck in some VMX ROOT MODE | 20:47 |
| mup | Bug #1814971 opened: 'up arrows' in snap info version list are hard to read and parse <Snappy:New> <https://launchpad.net/bugs/1814971> | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
