/srv/irclogs.ubuntu.com/2020/02/13/#snappy.txt

mupPR snapd#8127 opened: interfaces/cpu-control: allow to control cpufreq tunables <Created by alexmurray> <https://github.com/snapcore/snapd/pull/8127>00:42
mborzeckimorning06:13
pstolowskimorning08:00
zygagood morning08:00
mborzeckipstolowski: mvo_: zyga: pedronis: morning guys08:01
mupPR snapd#8102 closed: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8102>08:02
mupPR snapd#8125 closed: data/selinux: unify tabs/spaces <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8125>08:17
mborzeckipushed snapd update to arch and updated https://src.fedoraproject.org/rpms/snapd/pull-request/8 in fedora, but i see Eight_Doctor isn't around :(08:18
mupPR snapd#8124 closed: tests: Fix core revert channel after 2.43 has been released to stable <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8124>08:19
* zyga is in the office08:32
zygaI need to shift a few hours back08:32
* zyga grabbed quick breakfast08:54
mupPR snapd#8015 closed: [RFC] daemon, store: support download resume from /v2/download <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8015>09:35
mborzeckizyga: some questions in #812309:50
mupPR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>09:50
pedronispstolowski: hi, let me know when #8003 can be reviewed again09:51
mupPR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>09:51
pstolowskipedronis: hey, it can (when becomes green)09:55
zygamborzecki: thank you, looking09:57
* zyga reboots10:20
* zyga dives into failures10:26
mupPR snapd#8109 closed: [RFC] o/devicestate: don't prune tasks immediediately <Preseeding 🍞> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8109>10:37
mborzeckihmm in tests prepare we cache the snaps, core among them, then proceed to `snapd download --$CORE_CHANNEL core` obviously the cached version is from stable  but tests run with edge10:51
zygahmmm11:09
mupPR snapd#6708 closed: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>11:12
pedronismvo_: thanks for spotting the Println in Ian's PR, I saw them but then forgot to mention them somehow11:16
mupPR snapd#8128 opened: o/devicestate: OperationalTime helper for Prune (1/2) <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8128>11:20
pstolowskijust saw failover test failure, does anyone remember if it's the same we saw before? https://pastebin.ubuntu.com/p/8n4GPdfp32/11:28
mupPR snapd#6708 opened: packaging/ubuntu: enable PIE hardening flags <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>11:30
mborzeckipedronis: mvo_: i've updated Ian's boot base PR11:43
mborzeckii'll do one last pass in case we missed something11:43
mupPR snapd#8126 closed: release: 2.43.3 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8126>11:51
zygahmm, more snapd failover failures12:13
* zyga checks pawel's messages from earlier today12:13
zygahttps://www.irccloud.com/pastebin/8RcV0Ocb/12:15
mborzeckizyga: do you have the debug log?12:15
zyganope :/12:15
zygamvo_: we should update https://salsa.debian.org/debian/snapd12:17
=== mvo_ is now known as mvo
mvozyga: yes12:19
mborzeckithe fonts in snaps seem to be rendered correctly on fedora, why do they render as boxes on arch?12:44
mborzeckicachio: hi, can you enable epel8 in our centos-8 images? should be as simple as `dnf install -y epel-release`12:54
cachiomborzecki, sure12:55
zygaI'm seeing a failure on core 1612:55
mborzeckicachio: thanks!12:55
zygalikely unrelated to the PR12:55
zygadid we change anything core prepare/restore lately?12:55
mborzeckizyga: what failure?12:55
zyga+ mount --bind /home/gopath/src/github.com/snapcore/snapd/tests/regression/lp-1805838/bad-snap-seccomp /snap/snapd/current/usr/lib/snapd/snap-seccomp12:55
zygamount: mount point /snap/snapd/current/usr/lib/snapd/snap-seccomp does not exist12:55
zygathis is the final error12:55
zygawe try to bind mount test file over snap-seccomp from snapd snap12:56
zygabut it's not there12:56
zygadebug output shows12:56
zygahttps://www.irccloud.com/pastebin/Ilmc7Kxz/12:56
zygawhich confirms that we don't have snapd snap12:56
mborzeckibut $SNAP_MOUNT_DIR/snapd exists12:57
mborzeckiweird12:57
mborzeckizyga: maybe a snapd on core failover left something? this landed ~2 days ago12:58
zygaaha12:58
zygaI suspect so12:58
zygalet me run my mount detector :P12:58
zygawhich test was that? test/failover?12:58
zygatests/main/failover?12:59
mborzeckizyga: i mean, maybe a directory /snap/snapd is left behind12:59
zygaaha12:59
zygaindeed, this is core 16 so probably no snapd snap12:59
zygabut the directory may be enough to fool the logic12:59
* zyga checks12:59
zygathanks!12:59
mborzeckizyga: tests/main/ubuntu-core-snapd*13:00
zygamborzecki: hmm13:02
zygamborzecki: the comment there talks about REBOOT and restore13:02
zygacannot we reboot in restore?13:02
zygamborzecki: what removes snapd.snap in that restore code?13:03
vidal72[m]hi, what's the reason https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0#diff-2bc16f6bf7e15ff07cc61fb337428314 didn't make it to any 2.43.x release?13:04
mborzeckizyga: iirc restore on core does not expect snapd snap and any of the 'trickery' that we do there13:04
zygamborzecki: I don't understand how that is related13:05
zygamborzecki: can restore do REBOOT?13:05
zygaanyway, I'm running the test13:05
zygaI suspect it is broken as it doesn't seem to clean up after itself13:05
zygathanks for the tip, I would chase this for a while without success13:05
mborzeckizyga: idk, probably it can, but the problem ehre was that project restore has assumptions about the state of the system at that point13:06
zygamborzecki: that may be but task-level restore runs before13:06
zygaso it can do whatever, reboot, and then hand off to suite code13:06
ppd1990Hi. I have a question concerning glvnd in spand: As far as I can see (snap-confine/mount-support-nvidia.c#L555), snapd mounts the host's glvnd dir to /var/lib/snapd/lib _if_ the nvidia module is loaded. Why not for mesa though? Some apps need that for their GL context on wayland.13:07
zygappd1990: hey13:07
zygappd1990: we never knew about that, can you tell us more please13:07
zygappd1990: but also because nvidia binary driver is usually abi compatible with everything13:08
zygappd1990: and FOSS libs are more or less random13:08
zygappd1990: so it's more of an exception than the rule13:08
pstolowskipedronis: in the followup to #8128 i'm using release.PreseedMode in the overlord to avoid prung when preseeding, is that ok for now? i'd like to attack release.preseedmode after remaining preseed PRs land13:08
mupPR #8128: o/devicestate: OperationalTime helper for Prune (1/2) <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8128>13:08
zygappd1990: FOSS graphics is usually bundled into the app snap (bad but common) or into one of the helpers (like gnome content snap)13:08
vidal72[m]zyga: do you know when https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 will land in 2.43.x?13:09
pedronispstolowski: it's ok, we need to rediscuss what exactly we want to do about release.PreseedMode, my original plan doesn't entirely work13:09
pedronisbut release is still a slightly horrible place for it13:09
zygavidal72[m]: my guess would be never13:09
zygavidal72[m]: it will be in 2.4413:09
zygavidal72[m]: unless it is in 2.43 release branch13:10
zygabut if it were you would not be asking13:10
ppd1990zyga: Hey :). Yes, that's true. I'm mostly only concerned with /usr/share/glvnd/egl_vendor.d/50_mesa.json. If that's not in __EGL_VENDOR_LIBRARY_DIRS, gdk throws something like this on wayland: "No GL implementation is available"13:10
pstolowskipedronis: sure. you mean the original plan of DeviceContext-like approach?13:10
pedronispstolowski: yes13:11
pedronispstolowski: anyway, let's talk about it when you reach a point where you want to attack it13:11
zygappd1990: can you give me an example on how to reproduce this13:11
zygappd1990: ideally as a bug report so that I can track it as well13:11
zygappd1990: including host distro / gpu / snap app13:11
zygappd1990: but the short answer is that the dots are not connected there13:11
zygappd1990: we had some plans but they never materialized13:12
ppd1990zyga: Take solvespace, an app that uses the gnome-extension. Simply pointing __EGL_VENDOR_LIBRARY_DIR to $SNAP/gnome-platform/usr/share/glvnd/egl_vendor.d is enough. So almost everything is set up and working13:14
pstolowskipedronis: ok, will do, thanks13:15
zygappd1990: should that be handled by the gnome extension? it can influence the environment13:15
zygaalso is __EGL_VENDOR_LIBRARY_DIR an implementation detail or something we can rely on long term?13:15
ppd1990zyga: It does indeed. But only if it finds /var/lib/snapd/[...]/egl_vendor.d13:15
ppd1990zyga: Which brings me back to "why is that mounted on nvidia only" :)13:16
zygappd1990: because that belongs to extended nvidia support which as a rule takes libraries from the host13:16
zygappd1990: and ... thats that13:16
zygano nvidia - dormant code path13:16
vidal72[m]zyga: what's the policy about what lands in releases then? That commit was done about one month before 2.43 release and isn't in release while similar commits done in recent days are already there: https://github.com/snapcore/snapd/commits/2.43.3/interfaces/builtin13:16
ppd1990zyga: I see. So that's more of a snapcraft thing then13:17
zygavidal72[m]: this is a question for our release manager, mvo13:17
cachiomborzecki, hey13:17
cachiohttps://paste.ubuntu.com/p/cxmZjbq4JM/13:17
cachioI see this error when I try to install depdencies in centos813:17
zygappd1990: I would personally like to remove nvidia support entirely13:17
zygappd1990: and ship those files via snaps13:17
cachioI am trying to install the snap dependencies13:17
zygappd1990: (shared snaps)13:17
mborzeckividal72[m]: looks like we forgot to set a milestone and do a cherry-pick13:17
zygappd1990: but that's not moving forward13:17
cachiomborzecki, but it works when we run tests on travis, right?13:18
ppd1990zyga: It's almost like you guys are solving non-trivial problems :D13:18
zygappd1990: it's a combination of lack of experience and known-how as to how mesa is moving13:18
zygappd1990: and lack of time on our side to dive into it and commit13:19
mborzeckimvo: can you cherry pick https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 to 2.43 in case we do another patch release?13:19
zygappd1990: if you'd like to help by drafting how that ought to look like we can help13:19
mborzeckicachio: yes, the set of packages for centos-8 is bit differnt, more like fedora, look at the changes in https://github.com/snapcore/snapd/pull/808313:20
mupPR #8083: spread: add CentOS 8 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>13:20
zygappd1990: ideally we'd ship a set of userspace libs as snaps, one per "driver" whatever that means13:20
zygappd1990: snapd would figure out which to install13:20
zygappd1990: possibly a matrix of driver and base snap used which defines the ABI13:20
cachiomborzecki, ok13:20
zygappd1990: and snapcraft would cull the libraries that belong to the driver from built snaps13:20
mborzeckizyga: where 'driver' means a mesa snap probably or sth13:21
zygappd1990: there's also some configuration as defined by magic environment and random files13:21
zygappd1990: and that _should_ be it13:21
cachiomborzecki, in that case I'll not install the dependencies yet13:21
zygappd1990: assuming the host provides the kernel and any services that the driver needs13:21
zygappd1990: matching the host driver (userspace side) is possible in the realm of snaps13:21
zygappd1990: but none of this is implemented13:21
zygamborzecki: hmmm, -shell-after shows we have snapd13:22
mborzeckizyga: snap or directory?13:22
zygamborzecki: everything13:22
zygamborzecki: working mounted and all that13:22
zygamborzecki: when you wrote this test, how were you expecting the recovery to work?13:23
zygappd1990: btw, if my idea of how this ought to work is wrong based on your experience, please do tell13:24
mborzeckizyga: mvo wrote the test iirc :P let me see what's happening there13:24
zygaoh?13:24
zygamborzecki: commit 31312f02c18660a71c856f7c0f413e8c9c41a59013:25
zygathat says you wrote it ;13:25
mborzeckizyga: yeah, took over mvo's branch at some point, suashing merging, resetting, probably author got reset, nvm, i'll try to fix it13:25
ppd1990zyga: I have little experience and my question was fueled by an incomplete understanding of the interface between host and the snap environment13:25
zygamborzecki: aha, I se13:25
zyga*see13:25
zygamborzecki: yeah13:26
zygamborzecki: ok let me handle that for now13:26
zygaI'll share my ideas in a moment13:26
mborzeckizyga: ok, the problem is that we need to stop the snapd process, clean up everything it wrote to /etc/systemd/system/* and stop the hacky-mount-unit13:26
mborzeckizyga: basically restore to snapd from 'core' rather than 'snapd' snap13:27
zygayeah13:27
zygaI agree13:27
ppd1990zyga: But your ideas are very interesting and seem to go in the direction of "more explicit interfaces" and less of "let's "mix" host & snap. Should be mostly OK"13:28
zygappd1990: somewhere along there is the desire to stop mixing host /etc13:29
zygappd1990: and provide a synthetic etc that is writable and snap-specific13:29
zygappd1990: but $fonts $pam $random_stuff and others all need to be handled13:29
pedronispstolowski: +1, the summary and description needs the rename13:33
pstolowskisure, thanks13:33
ppd1990zyga: It reads like a very extensive problem if apps are not required to conform to a very limited "snap-platform"13:39
zygappd1990: wild-west apps can ship and use anything13:39
zygappd1990: but we want to provide a sensible base for the vast majority13:39
cachiomborzecki, image ready13:41
mborzeckicachio: thanks!13:41
cachiomborzecki, yaw13:41
ppd1990zyga: As a mere user/packager, I like it a lot. I feel things are moving into the right direction; that's for sure13:41
ppd1990So thank you for doing what you do @snap(d|craft) team13:43
zygappd1990: you are welcome, it's always good to get questions and opinions from the wider community :)13:44
zygamborzecki: https://github.com/snapcore/snapd/pull/6708#pullrequestreview-35822726113:48
mupPR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>13:48
zygamvo: I'll join in 5 minutes13:57
mvozyga: ok13:59
mvopedronis: https://github.com/snapcore/snapd/pull/807814:24
mupPR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>14:24
zygacachio: I have your PR open, I'm sorry I didn't get to it yet14:29
zygaI'll focus more on reviews after unblocking this bug14:29
cachiozyga, np14:29
cachiotake your time14:29
roadmrjdstrand: tools r20200211-blahblah is now in production \o/14:32
jdstrandroadmr: woohoo! :)14:34
ijohnsoncachio: sorry I missed your ping yesterday, your explanation makes sense I don't think we need to write unit tests for that spread bit at this time, but I will try to test your PR with those commands locally14:38
mborzeckizyga: hmm that snapd snap is a local repack? so rev will be unset, and the code allows removal in such scenario afaict (cc pedronis)14:44
zygamborzecki: that's probably what happens14:44
zygamborzecki: it failed to be removed after simplification14:44
mborzeckizyga: do you have snap list maybe?14:44
zygamborzecki: it worked when it was broken14:44
zyganot anymore14:44
zygawaiting for another run14:44
mborzeckizyga: hmm error: cannot remove "snapd": snap "snapd" is not removable: snapd required on core devices14:48
mborzeckizyga: maybe it was the failover test?14:48
zygano, it was the non-failover one14:48
zygahold on14:48
mborzeckizyga: ubuntu-core-snapd installs snapd snap from the store14:48
mborzeckizyga: while the other one does magic hackery14:49
mupPR snapcraft#2930 closed: extensions: Handle case when user-dirs.dirs exits but not user-dirs.locale <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2930>14:56
mupPR snapcraft#2929 closed: elf: fixes for corrupt shared objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2929>14:59
ijohnsonmvo: is #8077 ready then?14:59
mupPR #8077: boot: enable base snap updates in bootstate20 <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>14:59
* cachio lunch15:18
zygamborzecki: maybe this15:22
ijohnsonpstolowski: mind giving a quick re-review to https://github.com/snapcore/snapd/pull/7904 ? we should have a version of snapcraft that supports using `build-base: core` _without_ `type: snapd` released soon so it would be good to be ready to land this PR when that happens so we can make xnox happy :-)15:24
mupPR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>15:24
zygamborzecki: 812915:25
mupPR snapd#8129 opened: tests: remove snapd in ubuntu-core-snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>15:25
mupPR snapcraft#2934 opened: meta: fix for missing content slot's 'content' property <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2934>15:26
pstolowskiijohnson: yay, sure!15:27
mupPR snapcraft#2935 opened: build providers: remove tzdata workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2935>15:38
zygamborzecki: what do you think?15:39
mupPR snapd#8077 closed: boot: enable base snap updates in bootstate20 <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8077>15:42
mborzeckizyga: i'm surprised that snap remove snapd line works15:47
zygabecause it is broken15:47
mupPR snapcraft#2936 opened: build providers: clean up LXD startup message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2936>15:47
zygabut I believe this does fix master15:48
zygaI added robustness and critical labels to it15:49
zygamborzecki: I updated the description to be meaningful15:52
zygaforce pushed to squash and fix shellcheck15:56
zygamborzecki: please review :)15:56
zygait's really annoying when master is broken15:56
ijohnsonzyga: which PR ?16:03
zygahttps://github.com/snapcore/snapd/pull/812916:03
mupPR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>16:03
ijohnsonthanks looking now16:03
zygathank you!16:04
zygaI should make some coffee16:09
pedronisijohnson: I reviewed #811216:14
pedronisthanks for it16:14
mupPR #8112: tests: move main/ubuntu-core-* tests to core/ suite <Simple 😃> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>16:14
ijohnsonthanks pedronis16:14
om26erroadmr hey! can you please check if flatbuffers snap has any issues in the store. The publisher has been getting some build failure notifications due to wrong version string; we just fined that https://github.com/google/flatbuffers/pull/572716:14
mupPR google/flatbuffers#5727: [snap] Fix versioning <Created by om26er> <Merged by aardappel> <https://github.com/google/flatbuffers/pull/5727>16:14
ijohnsonpedronis: I'll change those things and then merge when it's green16:15
pedronisthx16:15
pedronisijohnson: it might conflcit with #8129 ?16:16
ijohnsonhmm16:16
mupPR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>16:16
ijohnsonpedronis: oh yes it might, but it's just a file rename so I can merge master to resolve that easily enough I think16:17
roadmrom26er: I'll check in a bit16:17
* zyga combines coffee with dinner16:20
roadmrom26er: latest upload/build was 17h ago, still getting this bogus version string ".11.0+git226.gcc08c083"16:20
om26erroadmr we just landed the new PR, I am hoping that will trigger a new build then16:21
om26erthough I don't see anything here https://launchpad.net/builders16:21
om26erroadmr are you able to force a build ?16:22
roadmrom26er: might take a bit to kick off the build, I'd suggest waiting a few mins16:22
om26eralright, sounds good16:22
roadmrom26er: do let me know if it hasn't built in a couple of hours16:23
om26erroadmr, I will, thanks16:24
mupPR snapd#8130 opened: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130>16:56
pedronispstolowski: I think we can close 7836 ?16:58
mupPR snapd#7836 closed: o/ifacestate: fix binding of implicit hooks to implicit slots on core snap <Bug> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7836>17:01
pstolowskipedronis: yes, done, i may pick it up again at a later time17:01
pstolowskiif needed17:01
pstolowskiijohnson: we want build-base:core in https://github.com/snapcore/snapd/pull/7904, no? I don't see any change to the PR since I last reviewed it17:03
mupPR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>17:03
ijohnsonpstolowski: oh I must have mis-force-pushed good catch!17:03
pedronispstolowski: didn't really do a full review, but I made a comment on 813017:09
pstolowskity17:09
ijohnsonzyga: mind if I force push the change mborzecki requested to #8129 to your PR? Also your PR will conflict with #8112, so if it's okay I would like to land that, then I can rebase that PR and apply the fixed maciej requested18:15
mupPR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>18:15
mupPR #8112: tests: move main/ubuntu-core-* tests to core/ suite <Simple 😃> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>18:15
zygaijohnson: not at all18:15
ijohnsonzyga: cool thanks!18:15
mupPR snapcraft#2934 closed: meta: fix for missing content slot's 'content' property <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2934>18:27
mupPR snapcraft#2937 opened: spread tests: do not attempt to remove snapd snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2937>18:42
zygaijohnson: thanks for restarting, macos build now passed18:54
om26erroadmr flatbuffers build didn't trigger yet. Can you force it manually ?18:55
ijohnsonzyga: np, my PR didn't pass non-ubuntu spread so I retriggered it, I guess we will see which PR passes tests first :-)19:03
zygaone of those days19:05
zygabut I'm happy we're moving forward19:05
ijohnsonindeed19:06
roadmrom26er: sorry, I cannot :( maybe the snap owner can?19:35
om26erroadmr, ok, will wait it off today and will "find" him tomorrow (I guess on GitHub) ;)19:36
roadmrom26er: thanks - I can check with Colin tomorrow morning about why this might not have been triggered; it should trigger on new commits to master19:37
zygaijohnson: it's merged!20:07
* zyga takes the dog out, ttyl20:07
ijohnsonzyga: ack seems your PR beat mine :-)20:07
ijohnsonI will include the patch in my PR20:08
mupPR snapd#8129 closed: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8129>20:08
mupPR snapd#8112 closed: tests: move main/ubuntu-core-* tests to core/ suite <Simple 😃> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>20:12
mupPR snapd#8131 opened: boot: add current_kernels to modeenv <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8131>20:26
mupPR snapcraft#2936 closed: build providers: clean up LXD startup message <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2936>21:03
mupPR snapcraft#2938 opened: remote build: default to snapcraft's stable channel <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2938>21:09
mupPR snapd#8047 closed: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8047>21:21
* cachio afk21:40
Marcin_PLHello. How can I uninstall Snap completely, including virtual 93MB drive? I am using LMDE.21:48
zygaMarcin_PL: hey21:54
zygaMarcin_PL: it depends on the system you are using,21:54
zygaMarcin_PL: but if you are using a dpkg/apt based system "sudo apt purge snapd" is one command21:54
zygaMarcin_PL: keep in mind this will remove snapd, all snap apps and their data21:54
zygaMarcin_PL: in rpm world there's a similar command using either yum, dnf or zypper21:55
zygaMarcin_PL: if you tell us which distribution you are on, we might help21:55
Marcin_PLI got APT21:55
Marcin_PLLMDE is Mint on Debian21:55
zygaMarcin_PL: was there something specific that made you remove snapd?21:59
Marcin_PLHuh, thanks - looks it helped. I tried as usual apt(-get) remove snapd and there was still the core package mounted as /dev/loop0; now it's gone. I hope after the reboot it will not appear again. :)22:00
zygaMarcin_PL: they should be gone, barring bugs in the postrm script22:01
Marcin_PLThanks again22:02
zygaMarcin_PL: you are welcome :)22:03

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