| mborzecki | morning | 05:08 |
|---|---|---|
| mborzecki | i ran #5397 job 7-8 times now, only one econnreset error, but unrelated to the fix we made, the test got 503 when trying to download the snap what looked like some store side hiccup | 06:27 |
| mup | PR #5397: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5397> | 06:27 |
| mborzecki | i have seen the mounting squashfs error reproduce a couple of times, and at least one other error which i do not recall seeing before in tests/main/validate-container-failures | 06:29 |
| mborzecki | i'll be merging the PR when the travis job becomes green again | 06:29 |
| mup | PR snapd#5408 opened: i18n: use xgettext-go --files-from to avoid running into cmdline size limits <Created by mvo5> <https://github.com/snapcore/snapd/pull/5408> | 06:49 |
| mup | PR snapd#5407 closed: tests: add fedora to distro_clean_package_cache function <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5407> | 06:51 |
| mborzecki | and opensuse downloads flaky too :( | 07:04 |
| zyga | Good morning | 07:05 |
| mborzecki | zyga: hey | 07:06 |
| zyga | I am heading to school for some errands. I will be back in an hour | 07:06 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:15 |
| mborzecki | pstolowski: heya | 07:18 |
| pedronis | mvo: hi, #5403 uses #5386 :) | 07:20 |
| mup | PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403> | 07:20 |
| mup | PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <https://github.com/snapcore/snapd/pull/5386> | 07:20 |
| mvo | pedronis: *cough* sorry and thank you | 07:23 |
| mborzecki | pedronis: hi, could you take a look at https://github.com/snapcore/snapd/pull/5387 ? :) | 07:28 |
| mup | PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387> | 07:28 |
| mborzecki | this unblocks some unit tests for snapstate | 07:29 |
| pedronis | mborzecki: will look in a little bit | 07:31 |
| mborzecki | pedronis: thank you | 07:31 |
| pedronis | mvo: are you looking at 5403 atm ? wondering if I should merge or squash merge 5386 | 07:40 |
| mvo | pedronis: not looking at it right now | 07:42 |
| mup | PR snapd#5386 closed: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386> | 07:42 |
| mup | PR snapd#5409 opened: tests: run "arp" tests only if arp is available <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5409> | 07:43 |
| pedronis | mvo: I squashed it, and rebased 5403 | 07:45 |
| zyga | I signed up my son to a new school | 07:47 |
| zyga | Heading home soon | 07:47 |
| mvo | pedronis: ta | 07:47 |
| mup | PR snapd#5397 closed: tests/main/econnreset: limit ingress traffic to 512kB/s <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5397> | 07:58 |
| mup | PR core18#42 opened: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <https://github.com/snapcore/core18/pull/42> | 08:05 |
| mvo | zyga: http://paste.ubuntu.com/p/q87HDCzFqp/ <- this is a failure I see right now on core18 with the interfaces on core PR. I guess this is what you meant yesterday when you said we also need to translate the API calls? | 08:07 |
| pedronis | mborzecki: looks good, left a comment | 08:10 |
| mborzecki | pedronis: thanks, looking | 08:11 |
| mborzeck1 | heh and gnome died again, it's probably somethign with nvidia | 08:13 |
| mborzeck1 | the host is not responding over the network | 08:13 |
| mborzeck1 | but the cursor overlay works, pff | 08:13 |
| === mborzeck1 is now known as mborzecki | ||
| ondra | mcphail install just openhab-ondra, gadget was only in case you need to use some specific usb dongle | 08:22 |
| ondra | mcphail if you are not planning to use any usb, then no need for gadget | 08:22 |
| ondra | mcphail if you want to use some usb device, share with me pid and. vid of that device I will add it. It exposes serial interface slot so you can connect plug from openhab to it | 08:23 |
| mup | PR snapd#5410 opened: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410> | 08:28 |
| Chipaca | moin moin | 08:31 |
| pedronis | Chipaca: hi | 08:31 |
| Chipaca | pedronis: 'sup | 08:31 |
| zyga | mvo: looking | 08:32 |
| pedronis | Chipaca: mainly #5403 and reviewing stuff | 08:32 |
| mup | PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403> | 08:32 |
| zyga | mvo: yes, exactly that | 08:33 |
| pedronis | Chipaca: and I pinged you here: https://github.com/snapcore/snapd/pull/5386#discussion_r198392974 | 08:33 |
| mup | PR #5386: snap: introduce a struct Channel to represent store channels, and helpers to work with it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5386> | 08:33 |
| zyga | mvo: I think it's a bit of a weirdness but we should do it | 08:33 |
| zyga | mvo: not just because of our tests | 08:33 |
| zyga | mvo: but perhaps of scripted interactions in the wild | 08:33 |
| zyga | mvo: muscle memory or bash history | 08:33 |
| zyga | mvo: I was thinking where to translate that | 08:34 |
| zyga | mvo: the repository itself is nice but perhaps too naive | 08:34 |
| zyga | mvo: the disconnect will work but I'm not sure about the connection state, as there are other translation points in the interface manager | 08:35 |
| zyga | mvo: nothing hard, just something I need to look at | 08:35 |
| mvo | zyga: yeah, I agree it should work | 08:38 |
| mborzecki | pedronis: regarding https://github.com/snapcore/snapd/pull/5387#discussion_r198401006 i can do the instanceName == info.InstanceName() in MockSnapInstance/mockSnap but i need to set instance key in mocnSnap for mount/file locations to be correct, unless i pull the common part to say mockSnapFiles and duplicate the info parsing bits in MockSnap & MockSnapInstance (which I'd like to avoid) | 08:38 |
| mup | PR #5387: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5387> | 08:38 |
| mvo | zyga: I guess the question is at what layer to translate | 08:38 |
| Chipaca | pedronis: answered your ping there | 08:38 |
| zyga | sorry for being late btw, we had to do some paperwork to move our son to a new school | 08:38 |
| Chipaca | pedronis: did you answer mvo wrt when architecture would be used, or should i? | 08:38 |
| zyga | mvo: I think we should translate in the interface manager | 08:38 |
| * Chipaca hugs zyga | 08:38 | |
| zyga | mvo: because that captures both connection state and repository connection | 08:38 |
| Chipaca | zyga: PAPERWORK IS AWESOME | 08:39 |
| zyga | hey Chipaca | 08:39 |
| zyga | hahaha | 08:39 |
| zyga | Chipaca, the recovering paperwork addict | 08:39 |
| mvo | Chipaca: he pointed me to the PR that actually uses this | 08:39 |
| Chipaca | mvo: fair | 08:39 |
| mvo | Chipaca: so I think its fine | 08:39 |
| mvo | zyga: ok | 08:39 |
| pedronis | it is used quite a bit | 08:39 |
| zyga | mvo: if you want I can look in a sec | 08:39 |
| zyga | let me just commit something quickly | 08:39 |
| pedronis | Chipaca: anyway your review of #5403 when you can would be appreciated | 08:40 |
| mup | PR #5403: many: use extra "releases" information on store "revision-not-found" errors to produce better errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5403> | 08:40 |
| zyga | Chipaca: did you reach the origami phase where instead of filling in the forms you just fold them | 08:40 |
| Chipaca | pedronis: yep, on it | 08:40 |
| zyga | and daydream | 08:40 |
| Chipaca | zyga: so, one change in the hostilization of this process that bit me and delayed me was that they changed from 'list any absences longer than 60 days' to 'list any absences' (ie trips out of the country) | 08:40 |
| Chipaca | zyga: the table had three rows | 08:41 |
| Chipaca | zyga: so you had to continue it on a separate sheet | 08:41 |
| zyga | oooh | 08:41 |
| zyga | I would go to jail if they asked me to fill in all the places I've been to correctly | 08:41 |
| Chipaca | so I filled one side of the separate sheet with all the info, turned it around to carry on … and there was a hand-drawn comic on it | 08:41 |
| Chipaca | so i guess they're getting an original piece of art together with this sumission | 08:42 |
| zyga | haha :) | 08:42 |
| zyga | fridge magnets help | 08:42 |
| Chipaca | (it's all got to be handwritten of course, because this is the nineteenth century) | 08:42 |
| Chipaca | anyhoo. I'll put that away for now and review stuff :) | 08:42 |
| * Son_Goku groans to life | 08:47 | |
| zyga | good morning | 08:48 |
| * Chipaca passes Son_Goku the mate | 08:48 | |
| * Son_Goku wobbles | 08:48 | |
| zyga | Son_Goku: maybe some quick shot of vodka to wake you up ;-) | 08:48 |
| * zyga hides | 08:49 | |
| * Son_Goku runs away | 08:49 | |
| Son_Goku | ... | 08:49 |
| * Son_Goku ambles back | 08:49 | |
| Son_Goku | zyga, have you made any progress on implementing the base snap creation to Oz? | 08:49 |
| zyga | no, I need to schedule that and really work on it soon | 08:50 |
| zyga | Son_Goku: I have fedora on w510 now so I can work natively on this | 08:50 |
| Son_Goku | :D | 08:50 |
| zyga | (and quake, that doesn't help) | 08:50 |
| Son_Goku | hah | 08:50 |
| zyga | that game really is fun, it plays surprisingly well on the trackpoint | 08:50 |
| Son_Goku | well, they _were_ a lot more common when Quake 1 was a fresh game | 08:51 |
| zyga | I would like to sync about flock and plan when we should deliver stuff | 08:51 |
| Son_Goku | yeah | 08:51 |
| zyga | also flock is where, I suspect, we can get most of this ready | 08:51 |
| Son_Goku | well, Mohan Boddu is interested in syncing with us on this at Flock | 08:51 |
| Son_Goku | most of the releng team will be there at Flock | 08:51 |
| Son_Goku | Mohan hit me up this week and was curious about our progress | 08:52 |
| * Son_Goku waves to sabdfl_ | 08:54 | |
| zyga | that's cool, I think we should not come to flock empty handed | 08:54 |
| Son_Goku | it'd be nice to come to Flock with _something_, yeah | 08:54 |
| Son_Goku | we already mechanically understand what's needed for a base snap | 08:55 |
| Son_Goku | so I don't see a reason why oz cannot make one | 08:55 |
| zyga | yeah, I agree | 08:55 |
| zyga | I think it's mostly figuring out the architecture of oz and friends to do this | 08:56 |
| zyga | do you think we will be able to reuse any of the shell scripts? | 08:56 |
| zyga | or will this all involve writing new code | 08:56 |
| * Son_Goku wishes GitHub wasn't being unresponsive right now | 08:56 | |
| Son_Goku | what shell scripts? | 08:57 |
| Son_Goku | we don't have any for making fedora base snap | 08:57 |
| Son_Goku | there is _a_ python script I wrote to make one | 09:00 |
| Son_Goku | but I think the answer is generally going to be no | 09:01 |
| zyga | I mean, those scripts | 09:02 |
| zyga | I also have some | 09:02 |
| zyga | ok | 09:02 |
| Son_Goku | we probably are going to need to adapt this to Fedora tooling, which means a kickstart definition for the base snap, and an imagefactory target for it | 09:02 |
| pedronis | zyga: I looked a bit at #5369, it's nice it is short, it's not super obvious it's correct/maintainable tough, it seems somewhat disperse | 09:03 |
| mup | PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369> | 09:03 |
| Son_Goku | zyga: https://pagure.io/fedora-kickstarts/tree/master | 09:03 |
| Son_Goku | the fedora-docker-* ks files are probably a good starting point | 09:04 |
| zyga | pedronis: thank you, do you have any ideas on how to improve it? | 09:04 |
| pedronis | zyga: well, tbh, I don't understand even if snap connect for core interaces works there and how :) | 09:05 |
| pedronis | I have a question about that there | 09:06 |
| mborzecki | pedronis: pushed a fix | 09:06 |
| zyga | pedronis: I think mvo and me discussed that operations against explicitly named core snap don't work yet | 09:07 |
| zyga | implicit operations work fine | 09:07 |
| pedronis | because of the guessing? | 09:07 |
| mup | PR snapd#5411 opened: many: remove core-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5411> | 09:08 |
| zyga | yes, the guessing knows about snapd now | 09:08 |
| zyga | it has priority if it exists (the snapd snap) | 09:08 |
| zyga | for explicit we need to add one more translation point in doConnect and doDisconnect | 09:08 |
| pedronis | zyga: anyway it sounds we would need some helpers around manipulating conns | 09:08 |
| zyga | mvo: I opened an RFC to drop core-support | 09:08 |
| pedronis | so it's clear snapd cannot get in there | 09:08 |
| zyga | pedronis: that's a good idea | 09:08 |
| zyga | pedronis: I can propose some and then the translations can happen in a single spot | 09:09 |
| zyga | mvo: I don't know if it will pass spread, let's wait and see | 09:10 |
| pedronis | mvo: you have quite a few PRs open, anything in particular that I should review or re-review? | 09:14 |
| mborzecki | Chipaca: when you're done with the paperwork, can you take another look at #5366 ? | 09:22 |
| mup | PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366> | 09:22 |
| Chipaca | mborzecki: i'm reviewing 5403 right now, i'll get to that later | 09:22 |
| mborzecki | Chipaca: thanks | 09:22 |
| mborzecki | hmm got xdg-desktop-portals installed and it's showing popoup when runing unit tests | 09:28 |
| mborzecki | haha 'Allow snap "some-snap" to open file "/tmp/check-935424627432528910/7"?' | 09:29 |
| Chipaca | pedronis: pausing review of that for a bit, will come back to it later | 09:30 |
| Chipaca | pedronis: (commented a bunch meanwhile) | 09:30 |
| mborzecki | uhh it's the launcher | 09:31 |
| Chipaca | mborzecki: I still think that just dropping "invalid instance key" is not nice | 09:32 |
| Chipaca | mborzecki: in that it's gobbledegook | 09:32 |
| mborzecki | Chipaca: invalid snap instance name? | 09:32 |
| Chipaca | mborzecki: do we call it 'instance' anywhere in user-facing stuff other than this error | 09:32 |
| Chipaca | like, does 'snap install --help' explain instances | 09:33 |
| mborzecki | Chipaca: well the feature refers to them as instances, snap install uses (or will use) --instance when installing from file, other than that there's no explicit instance | 09:34 |
| mborzecki | Chipaca: i can go with 'invalid snap name' or sth along these lines | 09:34 |
| Chipaca | mborzecki: concretely: I suggest «invalid instance key %q (see 'snap install --help')», and adding a small paragraph to the install help that explains them | 09:34 |
| Chipaca | mborzecki: the feature description is not a user-visible document :) | 09:34 |
| jack | Hi guys, | 09:34 |
| pedronis | Chipaca: but we cannot really add a paragrah yet for something that is an incomplete experimental feature | 09:35 |
| pedronis | I suppose mborzecki can add a todo there | 09:36 |
| Chipaca | yes :) | 09:36 |
| mborzecki | works for me | 09:36 |
| Chipaca | a TODO is ok | 09:36 |
| Chipaca | I can then hit him over the head with it at a later time | 09:36 |
| * Chipaca orders a gross of TODO bludgeons off of amazon | 09:37 | |
| mborzecki | haha | 09:37 |
| mvo | pedronis: thanks, most should be easy(ish), let me look for some harder ones | 09:37 |
| Chipaca | mborzecki: when the help is written, we need to line up instance key vs name between error and help to avoid confusion also | 09:38 |
| mvo | pedronis: 5392 would be nice | 09:38 |
| mvo | zyga: thank you | 09:39 |
| pstolowski | zyga: hey, #5326 when you have a moment, please | 09:39 |
| mup | PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326> | 09:39 |
| sam__ | Hi guys, I have a java web application as war file it using tomcat server. Now i want to snap it. please someone guide me. | 09:40 |
| zyga | I read it last night but I was too tired | 09:40 |
| zyga | I will do it now | 09:40 |
| mborzecki | Chipaca: pushed a patch with TODO note | 09:40 |
| tomreyn | hi! i recently read https://github.com/canonical-websites/snapcraft.io/issues/651 and https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store and am wondinerg whether embedding (privacy impacting) trackers is currently (1) considered acceptable (b) tested for and (c) how it's being handled, if at all. from my POV this is a major issue on android's primary app ecosystem, and mostly unhandled / unsolved (or rather accepted) there. | 09:45 |
| tomreyn | so i'm wondering whether what the situation with snaps is. | 09:45 |
| zyga | hey tomreyn | 09:47 |
| tomreyn | hello zyga | 09:47 |
| zyga | I don't think we have any official policy about trackers in applications yet | 09:47 |
| tomreyn | that's... a shame, | 09:48 |
| zyga | we don't run applications as a part of the acceptance process, it is fully automated | 09:48 |
| zyga | let me look at the policy that we have to be sure | 09:48 |
| pedronis | Chipaca: I answered two of your questions, will wait for more feedback | 09:48 |
| zyga | tomreyn: I don't think the store has any written policy so far, or at least I cannot find any | 09:52 |
| mup | PR snapd#5412 opened: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412> | 09:52 |
| mborzecki | trivial PR ^^ | 09:52 |
| zyga | tomreyn: I would recommend that you discuss this on the forum as it seems like a goal worth pursuing | 09:52 |
| zyga | mborzecki: +1 but use Also | 09:53 |
| zyga | so one restore less | 09:53 |
| zyga | look at what MockCommand return value MockCmd can do | 09:53 |
| mborzecki | interesting, will do | 09:54 |
| zyga | tomreyn: discussions on IRC are immediate but actually miss quite a lot of the people that participate in snaps | 09:55 |
| zyga | tomreyn: a thread on forum.snapcraft.io, in the store category, is the best way to ensure the key people read tihs | 09:55 |
| tomreyn | zyga: thanks for checking. personally i don't think snaps a a goal worth pursuing so i'm not interested in investing time on improving the policies around it. hope you don't mind. | 09:55 |
| mborzecki | zyga: pushed | 09:56 |
| zyga | tomreyn: not at all, have a nice day :) | 09:56 |
| tomreyn | thanks for your time, though. | 09:56 |
| tomreyn | zyga: another question, if you have the time: is there a policy which defines which snaps get security support by canonical (in that canonical takes measures to ensure that known security vulnerabilities are overcome in a short amount of time, similar to how the ubuntu security team does it for the supported apt repositories)? | 10:01 |
| zyga | yes, there is that | 10:01 |
| zyga | may I ask why are you interested having said that snaps are not worth pursuing? | 10:01 |
| tomreyn | oh, that's good. ubuntu 18.04 installs gnome-calculator as a snap by default, so i was hoping so. | 10:02 |
| zyga | all snaps owned (as snap names) by canonical | 10:02 |
| zyga | have secutity support guarantees | 10:02 |
| Chipaca | zyga: all snaps with a for-stable-ubuntu branch also | 10:02 |
| zyga | Chipaca: thanks, I didn't know that | 10:02 |
| Chipaca | snaps installed by default are tracking an ad-hoc branch, not latest/stable, for this purpose | 10:03 |
| Chipaca | at least that's my understanding :-) i haven't checked, not having an 18.04 to hand | 10:03 |
| Chipaca | but, as I say, curious why tomreyn is simultaneously curious and incurious | 10:04 |
| tomreyn | I can be curious about things I don't favor. | 10:04 |
| Chipaca | tomreyn: yes :) | 10:04 |
| Chipaca | tomreyn: but you said something like it 'not being worth your time', which is rather less than not favouring it | 10:04 |
| zyga | tomreyn: snaps and similar efforst are an important part of application distribution, if you look at docker it's been very influential and has changed how many people work, deploy and use software. | 10:05 |
| zyga | while you may dislike snaps or anything else, having sane, safe behavior for something used by many people is important to us | 10:05 |
| Chipaca | I don't favour systemd, myself, but here we are :) | 10:05 |
| zyga | *efforts | 10:05 |
| tomreyn | zyga: sure, i'm happy to discuss my discontent with snaps. i like decentralized architectures, the snap store is centralized. i'm an open source enthusiast, snaps opens the door too widely to proprietary software. i also think that at this time, using snaps and debugging issues from a user perspective is badly documented, so it is difficult to know how to recover from issues. | 10:06 |
| mcphail | ondra: that's great. thanks! (and thanks for the snap, too) | 10:07 |
| zyga | tomreyn: ironically distributing open source software is really hard today | 10:07 |
| zyga | much harder than proprietary software | 10:08 |
| ogra_ | tomreyn, it opens the door the same way for opensource SW | 10:08 |
| tomreyn | the way it was introduced in ubuntu was quite intrasparant. the average user does not even know there ar enow two different mechanism to install packages and they would not know where to look for problems. | 10:08 |
| zyga | I, as someone working on FOSS for about a decade now, really appreciate that software distribution is breaking away from the initial taxonomy-driven library model | 10:08 |
| ogra_ | and why would the user need to know that ? she just wants to use some software | 10:09 |
| zyga | tomreyn: as with all new software, no matter how many times new things are announced, some poeple will be taken by surprise | 10:09 |
| zyga | tomreyn: this is not unique to snaps, it's just how people deal witch change | 10:09 |
| tomreyn | ogra_: that's correct, just, traditionally, debian, and also ubuntu, wasn't as embracing to proprietary software. | 10:09 |
| ogra_ | thats not true ... ubuntus focus was always "the best user experience" ... i.e. "linux for human beings ..." | 10:10 |
| zyga | tomreyn: I think ubuntu was always driven by being nice to people and that includes being able to use the software that said people want to use, proprietary or not | 10:10 |
| * zyga hugs ogra | 10:10 | |
| ogra_ | we have shipped proprietary nvidia drivers from day one | 10:10 |
| zyga | (we are not in the same room btw, :D | 10:10 |
| ogra_ | heh | 10:10 |
| zyga | I'm in a park with my dog, working on a bench | 10:10 |
| cjwatson | that's a new value of "one" | 10:10 |
| zyga | and ogra is probably 1000km away | 10:10 |
| ogra_ | not even in the same country :) | 10:10 |
| zyga | tomreyn: note that gnome-software has a mode now (not sure if released yet as we tend to see "git master" more often than not) where you can see just FOSS software | 10:11 |
| zyga | tomreyn: that includes snaps | 10:11 |
| tomreyn | zyga: i agree about the effects of introducing new technology. but don't you think more efforts should have been spent on educating users as to what these changes mean for them, and for how they need to manage their systems? | 10:11 |
| zyga | tomreyn: I think that it is impossible to make everyone happe, I can bring some people here who will compain that I'm not addressing the issue they have, add the feature they want instead of documenting something | 10:12 |
| zyga | tomreyn: the best way to ensure it is really the best software experience across linux is to help | 10:12 |
| ogra_ | but do you think someone using gnome-software actually *wants* to "manage their system" ? they just want an easy way to get their software | 10:12 |
| zyga | become an advocate | 10:12 |
| zyga | document, explain, educate | 10:12 |
| zyga | point out issues, help address them | 10:12 |
| zyga | help with the design and with bug fixing | 10:13 |
| zyga | whatever you feel like doing or feel you are good at | 10:13 |
| zyga | we are only a handful of people | 10:13 |
| ogra_ | if you really needs to be an admin and i.e. "manage your system" you probably dive deeper into the system anyway and will learn abouut snap as you will learn about debs | 10:13 |
| zyga | we are not a mega-corp with 100M monthly budget on advertising | 10:13 |
| tomreyn | sure, there is only so much time when you have limited resources available. i did not mean to blame you or anyone for not documenting things enough. things could probably have been smoother if there had been more people available to work on it. | 10:13 |
| zyga | we cannot do everything ourselves | 10:13 |
| zyga | exatly | 10:14 |
| zyga | please feel welcome here | 10:14 |
| zyga | join us | 10:14 |
| zyga | the forum is a fantastic place to contribute | 10:14 |
| ogra_ | my mother, or sister definitely do not care about the mechanism how their SW is delivered to them as long as the apps start and run flawlessly | 10:14 |
| zyga | no coding is needed | 10:14 |
| zyga | you can document how snaps work, how they are different, you can make people see this | 10:14 |
| zyga | the forum is being used to drive documentation pages | 10:14 |
| zyga | (literally, certain posts just show up as documentation on other pages) | 10:14 |
| zyga | so anything you contribute has immediate real vlaue | 10:14 |
| zyga | *value | 10:15 |
| zyga | and it is very good to be sceptical about it | 10:15 |
| zyga | you are not the only one | 10:15 |
| zyga | seeing how snaps operate, how the policy is made is the best way to keep people working on it as a day job honest | 10:15 |
| zyga | so please, stay around, look around and see how you can help - this is how FOSS works | 10:15 |
| tomreyn | thanks for the invitation. ;) i'll decline for now (since i'm still thinking that snaps will drive ubuntu in a direction i do not want to support), but maybe my mind will change in the future, you never know. and you placed a good seed there. | 10:15 |
| zyga | in the meantime, I need to review a patch from a colleague | 10:16 |
| tomreyn | thanks for your time. | 10:16 |
| ogra_ | cjwatson, did warty not have the drivers on disk (iirc they were shipped but a manual install was needed) ? | 10:16 |
| mup | PR snapd#5413 opened: tests: purge packages installed by accounts, calendar, and contacts interface tests <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5413> | 10:17 |
| zyga | tomreyn: one last question | 10:18 |
| cjwatson | ICBW but I don't think they worked properly until hoary. In any case it was a massive controversy when we started considering doing more stuff with them by way of compiz and the like | 10:19 |
| zyga | tomreyn: do you have any software you made yourself that you share with others? | 10:19 |
| cjwatson | so it's pretty ahistorical to say that Ubuntu has always been all the way over to one end of the spectrum; we've gone back and forth a lot | 10:19 |
| ogra_ | yeah, i do remember that ... but i thougth we always had restricted on the CD from the start | 10:19 |
| ogra_ | but i probably mis-remember and t was hoary ... | 10:19 |
| ogra_ | *it | 10:20 |
| tomreyn | zyga: i contribute to an open source game, megaglest. but i didnt write it myself. it's a fork which i help manage / develop. | 10:20 |
| cjwatson | ogra_: I *think* that was only since hoary | 10:20 |
| ogra_ | k | 10:20 |
| zyga | tomreyn: are you involved in publishing aspect of that game? | 10:20 |
| ogra_ | so day "two" :) | 10:20 |
| tomreyn | zyga: i have a voice in it. what's your point? | 10:20 |
| cjwatson | oh look, I have warty images lying around | 10:21 |
| zyga | tomreyn: did you try to ensure that the latest version of your game is available in debian, ubuntu, fedora and opensuse for example | 10:21 |
| zyga | or that the bug you fixed is released there | 10:21 |
| ogra_ | i even have my original warty laptop ... but it is in some box in the basement :) | 10:21 |
| cjwatson | they had restricted on the image, but no nvidia | 10:21 |
| ogra_ | ah | 10:21 |
| cjwatson | linux-amd64-generic was in restricted for some reason | 10:22 |
| zyga | people see snaps as some uneeded evil often don't have the first hand experience in delivering software across releases of one distribution, let alone across many | 10:22 |
| ogra_ | heh | 10:22 |
| cjwatson | oh, no, nvidia-kernel-common was on the i386 install image | 10:22 |
| zyga | I wanted to know if you have experience or stories about that | 10:22 |
| cjwatson | but not amd64, presumably for reasons ... | 10:22 |
| ogra_ | amd64 was still young in 2004 ... | 10:22 |
| zyga | pstolowski: so snapctl get as a regular user can read configuration of any snap? | 10:23 |
| ogra_ | i guess nvidia didnt provide 64bit binaries back then | 10:23 |
| cjwatson | yeah, could well be | 10:23 |
| cjwatson | the baseline architecture worked well but it was still considered slightly exotic | 10:24 |
| ogra_ | yep | 10:24 |
| pstolowski | zyga: only *own* snap (needs a valid context, so needs to be run by an app itself) | 10:25 |
| tomreyn | zyga: yes, it's a hassle if you want to be compatible to all or most linux distros and make installing and upgrading easy. if the software was more widely used i would probably spend time on packaging it using flatpack. | 10:25 |
| zyga | tomreyn: maybe it is not widely used becaue it's not widely available due to packaging complexity? | 10:25 |
| tomreyn | i don't think that's the case, no. | 10:26 |
| tomreyn | Megaglest is in all major distros, and we don't get to see a lot of players. it's an old game with an old graphics engine. | 10:26 |
| zyga | pstolowski: how do you define "own" snaps? | 10:27 |
| zyga | pstolowski: I mean running "snapctl" outside of snap world | 10:28 |
| pstolowski | zyga: by presence of context | 10:28 |
| zyga | ah, isee | 10:28 |
| pstolowski | zyga: (cookie) | 10:28 |
| zyga | and without that? | 10:28 |
| zyga | pstolowski: (review sent) | 10:28 |
| pstolowski | zyga: without context snapctl get errors out (only -h flag will work) | 10:29 |
| zyga | thanks! | 10:29 |
| mborzecki | Download (curl) error for 'http://download.opensuse.org/distribution/leap/42.3/repo/oss/suse/x86_64/libcap-devel-2.22-18.16.x86_64.rpm': | 10:30 |
| mborzecki | Error code: Curl error 52 | 10:30 |
| mborzecki | Error message: Empty reply from server | 10:30 |
| mborzecki | ehh | 10:30 |
| pstolowski | zyga: thanks for the review; okay, i see where your question comes from, i'll add a comment in the code, "as is" it may look scary at first | 10:31 |
| zyga | I was thinking if we could grep for something and retry common apt/dnf/zypper/pacman/git operations | 10:31 |
| mborzecki | #5412 super simple review, anyone? | 10:31 |
| mup | PR #5412: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5412> | 10:31 |
| zyga | merge it | 10:32 |
| mup | PR snapd#5412 closed: userd: fix running unit tests on KDE <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5412> | 10:33 |
| tomreyn | zyga: so, i just reflected a bit more about my disappreciation, and to at least contribute *someething* to your efforts, i tried to condense the aspects i'm most hesitant about when it comes to snaps: privacy concerns: witht he classic apt repos i can tell pretty well that this software has received *some* level of review, and can mostly rely on this to prevent, for example, i install software which analyzes and tracks me / my use of it / the | 10:36 |
| tomreyn | computer etc. with snaps, i don't have an easy way to tell where i can rely on things to be 'clean' of such issues and where not. the other aspect is security: there are two sub aspects here: for once, very much as for the privacy concerns i have, i also might install one snap but receive some bundled software i don't want, and i have no easy way to tell whether that's so or not. the other aspect is that while it's great that security updates | 10:36 |
| tomreyn | can be shipped so easily - unless i can know what gets regular security updates and what doesn't, i can easily end up with software in a known vulnerable version, but no9t realize it. | 10:36 |
| zyga | tomreyn: I am afk for a bit. I will reply when I’m back | 10:41 |
| tomreyn | sure | 10:42 |
| ondra | mcphail feel free to ping me if I forget updating it, are you tracking stable or other channel? | 10:50 |
| popey | ondra: automate the builds! | 10:50 |
| ondra | popey I do consume product of one jenkins, which I do not have control over, so it's hard to automate fully | 10:51 |
| ondra | popey I need some job periodically checking if there is new thing on jenkins | 10:52 |
| mup | PR snapd#5414 opened: corecfg: added experimental.hotplug feature flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/5414> | 10:52 |
| ondra | popey we will eventually get jenkins intergation there, but for that we need hotplug so openhab foundation is happy to adopt snaps, long storey :) | 10:53 |
| ondra | mcphail BTW if you are in homekit camp, you might be also interested in homebridge snap | 10:53 |
| mup | PR snapd#5415 opened: interfaces: moved normalize method to interfaces/utils and made it public <Created by stolowski> <https://github.com/snapcore/snapd/pull/5415> | 10:59 |
| pedronis | mvo: I did a pass over 5392 | 11:05 |
| zyga | https://www.irccloud.com/pastebin/BJ7ooq1z/ | 11:19 |
| zyga | tomreyn: ^ | 11:19 |
| ogra_ | now ... that remonds me that i have to rebuild 4 of my snaps for the libssl CVE ... the store spammed me tonight i should do that :) | 11:28 |
| ogra_ | *reminds | 11:28 |
| mvo | pedronis: thank you! | 11:29 |
| mup | PR snapd#5416 opened: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416> | 11:37 |
| === pstolowski is now known as pstolowski|lunch | ||
| mcphail | ondra: cheers. i've just installed the stable channel. i haven't poked it yet. i'm hoping i can replace my openhabianpi installation | 11:42 |
| tomreyn | zyga: my response https://paste.ubuntu.com/p/gVWpdPFxrY/ | 11:44 |
| ogra_ | tomreyn, your assumption is wrong, the centralized store does exactly that ... it auto-reviews every upload (and even monitors it during its lifetime) | 11:46 |
| ogra_ | and thats only possible with such a centalized model | 11:47 |
| ogra_ | the security model around snaps removes most needs for manual reviews (yet they happen for some special cases like gadget snaps or kernel snaps) | 11:47 |
| tomreyn | ogra_: then how did the miner make it in there, and what about user tracking? maybe the automated review process is just not as good as a manual one? | 11:49 |
| zyga | tomreyn: in reality, there is no manual review (anywhere) that is detailed, there is only trust and reaction in case of mistakes | 11:49 |
| ogra_ | it definitely isnt ... but do you think manual reviews in distros are any better ? | 11:49 |
| zyga | nobody reads code in detail | 11:49 |
| tomreyn | you probably want them both manual and automated, though | 11:49 |
| zyga | and really nasty code can be obfuscated | 11:50 |
| zyga | tomreyn: snaps make you trust the publisher (a specific entity) rather than the middle man | 11:50 |
| ogra_ | tomreyn, note that 90% of uploads to distro archives are not regularly reviewed either | 11:50 |
| zyga | in both cases (distro and app store) there are ways to catch up with nasty software | 11:50 |
| zyga | to block it, patch it out | 11:50 |
| ogra_ | a deb usually gets an initial review and then the developer uploads on hs own afterwards | 11:51 |
| zyga | in reality there is not much difference there | 11:51 |
| tomreyn | right, snaps make the user have trust relations to *many* publishers, which is overwhelming | 11:51 |
| ogra_ | well | 11:51 |
| zyga | if you trust mozilla with firefox, use firefox as a snap, or as the tarball from their website, or as the deb in ubuntu | 11:51 |
| ogra_ | snaps rather make the user trust into the security model | 11:51 |
| zyga | tomreyn: yes but that is _reality_ | 11:51 |
| zyga | tomreyn: in the past nobody really read code | 11:51 |
| zyga | it's a myth | 11:51 |
| zyga | it was just nicely packed into one big label ($Distro) | 11:51 |
| zyga | I think that's not going to change much really | 11:52 |
| zyga | what is different is now this is explicit (you know who gives you software) | 11:52 |
| zyga | and you can get software from more authors than before (non-free software) | 11:52 |
| zyga | and you can have some guarantees about how that software operates (sandbox) | 11:53 |
| zyga | in reality there is no better model yet | 11:53 |
| ogra_ | tomreyn, btw ... thanks to the snap store otifying me i just invested 2x 2min to update 4 snaps (2 server packages, one VPN tool and a desktop app) to get the latest libssl fixes in ... that would have eaten hours of my day if the packages were not snaps | 11:53 |
| ogra_ | *notifying | 11:53 |
| tomreyn | yes, there are clearly benefits in centralization. | 11:54 |
| ogra_ | also ... the miner is a totally valid thing ... | 11:54 |
| ogra_ | the fact that the developer did not mention it in the description was not valid though | 11:55 |
| tomreyn | so a miner package which would say it is a miner and would just mine for a one hardcoded account would be fine? | 11:56 |
| ogra_ | i dont see a reason why the package format should deny maintainers to get money for the work they do ... a miner is a possible way to do that ... just not without telling your users about it in advance | 11:56 |
| zyga | tomreyn: policy is not decided on IRC | 11:56 |
| zyga | it's a process and it is done on the forum | 11:56 |
| ogra_ | tomreyn, sure, why wouldnt it ... | 11:57 |
| zyga | tomreyn: in the end one thing is clear, there's no place for deception in software | 11:57 |
| ogra_ | tomreyn, its a very valid use-case to have an UbuntuCore image with a preinstalled miner snap to maintain your 10000 node miner farm with one-click | 11:57 |
| tomreyn | then you'll need to discuss whether tracking users, probably unknowingly and against their will, is deception. | 11:57 |
| ogra_ | and in my personal opinion a miner is also a valid thing for a maintainer of opensource software to generate some income ... as long as the user knows in advance what she is getting herself into | 11:58 |
| tomreyn | anyways, i do not want to distract you off your work any loinger. thanks for the fruitful (i hope) discussion. | 11:58 |
| zyga | tomreyn: would you mind summarizing this conversation on the forum | 11:59 |
| zyga | irc is not preserved as much | 11:59 |
| ogra_ | (beyond that fact that you can deny network access ofr a snap with one click or cmdline command) | 11:59 |
| zyga | I'm sure many people will find that useful | 11:59 |
| ogra_ | yeah, that would be super nice | 11:59 |
| tomreyn | zyga: that'd be me contributing to improving snaps, but, at leats so far, i'm not yet convinced that i want to do so. sorry for disappointing... | 12:00 |
| zyga | too bad, maybe next time | 12:01 |
| tomreyn | (you did bring up a couple things which will make me reconsider a few of my POVs though) | 12:01 |
| tomreyn | thanks for that | 12:01 |
| zyga | my point about the forum is that then this conversation is not specifically about you getting some answers but the whole community getting information | 12:02 |
| zyga | about making sutff better for more than oneself | 12:02 |
| mup | PR snapd#5366 closed: snap: helper for validating snap instance names <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5366> | 12:03 |
| mup | PR snapd#5387 closed: snap{/snaptest}: set instance key based on snap name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5387> | 12:03 |
| tomreyn | i will be happy to contribute to projects whose goals i share. ;-) you are welcome to reuse what i posted here and on the pastebin, both by paraphrasing or by quoting me. | 12:03 |
| mup | PR core18#42 closed: hooks: port 008-etc-writable.chroot from core16 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/42> | 12:03 |
| mup | PR snapd#5417 opened: image: block installation of parallel snap instances <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5417> | 12:09 |
| mup | PR snapd#5402 closed: i18n: handle write errors in xgettext-go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5402> | 12:16 |
| mup | PR snapd#5418 opened: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5418> | 12:16 |
| mvo | a second review for 5361 would be great | 12:17 |
| zyga | boo | 12:18 |
| zyga | mvo: I already did that one | 12:18 |
| mup | PR snapd#5390 closed: data: add systemd environment configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5390> | 12:18 |
| Chipaca | mborzecki: "реасе" is a favourite of mine to check for invalid names | 12:19 |
| Chipaca | mborzecki: :-) | 12:19 |
| pedronis | mmh, 50 PRs | 12:19 |
| Chipaca | pedronis: working on it | 12:20 |
| * Chipaca seems nitpicky and slow today, but still | 12:20 | |
| mborzecki | wow, 49, it was ~45 in the morning | 12:20 |
| zyga | mvo: 5411 is green | 12:20 |
| mvo | pedronis: my fault - but I have a lot of simple ones | 12:20 |
| zyga | it's -377 and some comment changes that made it to +10 | 12:20 |
| pedronis | ovelord tests have become 30s long mmh | 12:23 |
| pstolowski|lunch | pedronis: managers_test is responsible for that | 12:23 |
| pedronis | need to dig a bit, seems a bit bad | 12:23 |
| pstolowski|lunch | pedronis: (and i might have added to that with the retry-conflicts tests) | 12:24 |
| cachio | zyga, hey, when you have a time, could you please take a look to #5343 | 12:25 |
| mup | PR #5343: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343> | 12:25 |
| zyga | sure | 12:27 |
| zyga | cachio: merged | 12:32 |
| cachio | thanks | 12:32 |
| zyga | I left one comment though | 12:32 |
| zyga | maybe you can squeeze that into some other PR | 12:32 |
| mup | PR snapd#5343 closed: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5343> | 12:32 |
| zyga | mborzecki: review on 5415 | 12:35 |
| zyga | er | 12:38 |
| zyga | that was pstolowski|lunch sorry :) | 12:38 |
| zyga | I'm reading your 5417 so I thought about you | 12:38 |
| zyga | mvo: funny, same review points :) | 12:43 |
| zyga | on 5415 | 12:43 |
| mvo | zyga: haha | 12:43 |
| zyga | er | 12:43 |
| zyga | 17 | 12:43 |
| mvo | pstolowski|lunch: 5415 looks like an easy one, just one suggeston from zyga missing afaict | 12:44 |
| mup | PR snapd#5419 opened: [WIP] many: switch to account validation: unproven|verified <Created by pedronis> <https://github.com/snapcore/snapd/pull/5419> | 12:49 |
| zyga | mborzecki: can you look at my comment on 5413 | 12:50 |
| === pstolowski|lunch is now known as pstolowski | ||
| mborzecki | zyga: hmm that's a bit unexpected | 12:52 |
| mvo | zyga: I have a conflicting meeting today | 12:59 |
| zyga | ack | 12:59 |
| niemeyer | mvo, zyga, mborzecki: I won't attend the standup today.. have a conflict over it | 13:00 |
| niemeyer | (in principle) | 13:00 |
| zyga | ack | 13:01 |
| * zyga tries to join | 13:02 | |
| pstolowski | pedronis: standup or other meeting? | 13:03 |
| pedronis | conflict | 13:03 |
| zyga | thank you | 13:10 |
| === alan_g is now known as alan_g_ | ||
| pstolowski | zyga, mborzecki arch-linux-64:tests/main/interfaces-content failure https://api.travis-ci.org/v3/job/397340654/log.txt ; is this the same issue you mentioned earlier this week? | 13:50 |
| mvo | zyga: did you see my earlier (last night?) paste of the test failure of the layout test on core18? | 13:57 |
| mvo | zyga: it is reproducible, it happend on my latest test run as well | 13:58 |
| abeato | niemeyer, hi, https://github.com/snapcore/snapd/pull/5309 needs another (hopefully final) round | 14:13 |
| mup | PR #5309: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309> | 14:13 |
| niemeyer | abeato: Heya, looking | 14:14 |
| abeato | great, thx | 14:15 |
| zyga | mvo: I did, thank you | 14:17 |
| zyga | mvo: how can I reproduce that, which branch to start with? | 14:17 |
| mvo | zyga: please get https://github.com/mvo5/snappy/tree/core18-all-fixes-all-tests and then run "spread -v -debug ubuntu-core-18-64:tests/main/layout | 14:19 |
| zyga | pstolowski: hmm, what's the failure there? | 14:20 |
| zyga | thanks! | 14:20 |
| zyga | pstolowski: I only see the snapd-notify error | 14:20 |
| zyga | mvo: running now | 14:26 |
| mup | PR snapd#5420 opened: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420> | 14:29 |
| zyga | pstolowski: those sysfs rules are interesting | 14:29 |
| zyga | I was not aware about some of them | 14:29 |
| pstolowski | zyga: i restarted the job shortly after; here is the error https://pastebin.ubuntu.com/p/RMyqtdzVzq/ | 14:34 |
| pstolowski | zyga: what sysfs rules? | 14:35 |
| mborzecki | zyga: #5420 addresses snap-mgmt thing | 14:35 |
| mup | PR #5420: snap-mgmt: fix for non-existent dbus system policy dir, shellchecks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5420> | 14:35 |
| mborzecki | also pushed some fixes for blocking parallel instances when preparing an image PR | 14:36 |
| zyga | mvo: reproduced (with my extra branch, investigating) | 14:38 |
| kyrofa | sergiusens, slack isn't connecting today, it seems. Are you able to? | 14:38 |
| kyrofa | Until it starts working, I'm here if needed | 14:38 |
| zyga | mvo: so | 14:39 |
| zyga | mvo: I got this error | 14:39 |
| zyga | https://www.irccloud.com/pastebin/taNSqyBH/ | 14:39 |
| zyga | this may not be the same error you got yourself | 14:39 |
| zyga | it is also a bug in the test | 14:39 |
| zyga | the test encodes assumptions about the base snap | 14:40 |
| zyga | mvo: my suggestion is to change the test | 14:40 |
| * cachio afk | 14:41 | |
| zyga | mvo: I will send you a patch shortly | 14:42 |
| mvo | zyga: cool | 14:43 |
| * zyga has flaky network with 27K photos being backed up today /o\ | 14:44 | |
| mvo | zyga: not sure about the error | 14:44 |
| zyga | mvo: the error I got may be different because I merged one of my layout fixes here | 14:44 |
| zyga | mvo: this uncovered the assumption about base snap that just don't hold | 14:45 |
| kyrofa | Oh, looks like slack is just down in general | 14:52 |
| mvo | zyga: aha, ok | 14:53 |
| mvo | zyga: I was looking at a different failure | 14:53 |
| === Caelum_ is now known as Caelum | ||
| zyga | mvo: the failure you got is fixed by my PR | 14:53 |
| zyga | mvo: so that's expected | 14:53 |
| zyga | I just wanted to see if this is correct after | 14:53 |
| zyga | vanilla master trips over the bug that this one fixes | 14:54 |
| pedronis | pstolowski: we get 5+5 s just from the retries indeed | 14:54 |
| pstolowski | pedronis: that's bad.. perhaps instead of settle we could wait the exact number of ensures | 15:01 |
| zyga | mvo: hmm, interesting, this is slightly deeper than that | 15:01 |
| zyga | mvo: the test is expected to run against the core snap | 15:02 |
| zyga | mvo: but because this is a core system it dones't run against the core snap, it runs again core18 because on all-snap systems we don't pivot | 15:02 |
| zyga | mvo: which I think is a deeper bug | 15:02 |
| zyga | mvo: this means that on core18 sytems _all_ snaps run against core18, not core! | 15:03 |
| zyga | which is a critical bug | 15:03 |
| zyga | mvo: I switched networks, are you reading this, not sure if irc works now | 15:04 |
| pedronis | pstolowski: not sure, anyway it's an area to touch again, at least I see where the time comes from now | 15:04 |
| mvo | xnox: hey, I filed bug 1778936 about the need to get a patch from xenial systemd back. I also added a debdiff, anything else I should do to ensure this is part of the next sru? | 15:04 |
| mvo | zyga: uh, that sounds nasty | 15:04 |
| mup | Bug #1778936: please re-add Support-system-image-read-only-etc.patch <systemd (Ubuntu):New> <systemd (Ubuntu Bionic):New> <https://launchpad.net/bugs/1778936> | 15:04 |
| zyga | mvo: let me look at that now | 15:05 |
| mvo | zyga: I think you are right, I just did "snap run --shell test-snapd-tools.echo" and a cat /etc/os-release and its core18 | 15:05 |
| mup | PR snapd#5418 closed: overlord/ifacestate: get/set connection state only via helpers <Core18> <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5418> | 15:06 |
| xnox | mvo, there is a systemd in-flight in the unapproved. | 15:08 |
| xnox | mvo, is this a regression since xenial? | 15:08 |
| xnox | mvo, =/ i hope i didn't drop anything else on the floor | 15:08 |
| mvo | xnox: its a regression, to be fair we had hoped to get to a clean /etc by core18 but it did not work out ./ | 15:09 |
| xnox | mvo, horum | 15:09 |
| mvo | xnox: I have not noticed any other regression | 15:09 |
| xnox | i shall dig into the history of that then quickly | 15:09 |
| mvo | xnox: fortunately the patch still applies almost cleanly | 15:09 |
| mvo | xnox: it looks like it got dropped when yakkety opened | 15:09 |
| mvo | xnox: there is no changelog entry, but with 230-1 it was dropped | 15:09 |
| xnox | mvo, ah, which is before i started systemd maintainance. i guess pitti thought it will be all fixed and dropped it post-xenial. | 15:10 |
| xnox | mvo, at one point systemd was in-sync in debian and ubuntu | 15:10 |
| mvo | xnox: https://launchpad.net/ubuntu/+source/systemd/230-1 is what I was looking at (diffhttp://launchpadlibrarian.net/261334051/systemd_229-6ubuntu1_230-1.diff.gz ) | 15:11 |
| xnox | nice | 15:11 |
| mvo | xnox: I think he just hated it ;) but thats ok, its really not great that we haven't gotten to the clean etc | 15:11 |
| xnox | mvo, do we need to talk about that in brussels? | 15:11 |
| mvo | xnox: we need this before brussels | 15:12 |
| mvo | xnox: oh, clean etc | 15:12 |
| xnox | mvo, cause i think we never got around to finalising what needs to be in-distro / on-core to get this done. | 15:12 |
| mvo | xnox: yes please | 15:12 |
| xnox | mvo, yeah clean etc. | 15:12 |
| mvo | xnox: +100 | 15:12 |
| mvo | xnox: I think it must be a combined effort of foundations,core,debian but I think the important thing is to start :) | 15:12 |
| mvo | xnox: anyway, it won't happen for core18 so we have a bit of time but I will be really sad if we don't have it for core20 | 15:13 |
| xnox | ack | 15:17 |
| mvo | xnox: ta | 15:17 |
| mvo | zyga: https://github.com/snapcore/snapd/compare/master...mvo5:core18-use-core?expand=1 <- an integration test for the bug you just found | 15:18 |
| kyrofa | sergiusens, snapcraft#2172 is all green | 15:18 |
| mup | PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172> | 15:18 |
| mvo | zyga: iirc we do something special on core, did you start looking into it? | 15:18 |
| zyga | mvo: yes, I did | 15:18 |
| zyga | thanks for the test, it's really simple | 15:19 |
| zyga | I mean | 15:19 |
| zyga | the bug | 15:19 |
| zyga | we just need to talk about it | 15:19 |
| mvo | zyga: tell me more :) | 15:19 |
| zyga | we have two options | 15:19 |
| zyga | option number one is this: detect core18 and treat it as classic (pivot root, etc) | 15:19 |
| zyga | a bit hairy but keeps the core status quo | 15:19 |
| zyga | option number two: drop all special casing, always pivot | 15:20 |
| zyga | I prefer two but it may affect core in some way | 15:20 |
| zyga | right now on core we don't do pretty much anything | 15:20 |
| zyga | we unshare the mount namespace | 15:20 |
| zyga | bind mount tmp and private /dev/pts | 15:20 |
| zyga | and that's that | 15:20 |
| zyga | so all production hacks are visible at runtime | 15:20 |
| zyga | and all the real / is there | 15:21 |
| zyga | we talked about this sometime in the past | 15:21 |
| zyga | when you first added bases to snap-confine | 15:21 |
| mvo | zyga: yeah, I think option (2) is better but more risky | 15:21 |
| zyga | I said then that we should unify core and classic to behave like classic (for the purpose of mount ns) | 15:21 |
| zyga | but chose not to do this then because we wanted to avoid the risk :) | 15:21 |
| zyga | and impact on core itself | 15:21 |
| zyga | I think we should do that again | 15:22 |
| zyga | but try to fix it at the same time | 15:22 |
| zyga | my memory is rusty but I think there's a real issue there | 15:22 |
| zyga | that unification doesn't work for a real reason | 15:22 |
| zyga | but I forgot that reason | 15:22 |
| zyga | I will do a patch that detects booted base != "core" and uses classic semantics | 15:22 |
| zyga | because this is a new slate | 15:22 |
| zyga | so new issues rather than regressions | 15:22 |
| mvo | zyga: +1 | 15:23 |
| zyga | and because this eventually puts us on a path where core is deprecated and core16 can be the special case (if we end up needing it) | 15:23 |
| zyga | ok, I'll get to it now | 15:23 |
| mvo | zyga: \o/ | 15:23 |
| sergiusens | kyrofa: no, slack no work, me fitter, happier, more productive, comfortable | 15:43 |
| zyga | mvo: core16 and core will use the same os-releaes file, right? | 15:47 |
| mvo | zyga: yes | 15:49 |
| mvo | zyga: well, we could decide but that was the plan | 15:49 |
| zyga | I think it must | 15:50 |
| zyga | I was just checking and thinking aloud :) | 15:50 |
| kyrofa | Hahaha | 15:50 |
| kyrofa | sergiusens, amen | 15:50 |
| pedronis | they need to be ideally identical in bits that snaps can see, or through snap-confine bind mounting stuff (from snapd for example) | 15:52 |
| mvo | zyga: yeah, I think pedronis is right, we may need some other way to distinguish | 15:55 |
| zyga | pedronis: I agree, it is just that now on core we don't pivot so today on core (bare "core" as boot snap) you see _everything_ that exists on the system, in general, not just what is in the core snap itself. | 15:55 |
| zyga | so on a system that moved to core16 we can attempt to keep that | 15:56 |
| zyga | but on a core18 system that runs a snap using core16 or core as base we cannot just get that for free, we need to hack things to behave this way | 15:56 |
| zyga | some things about product hacks may leak but I don't know if that matters | 15:56 |
| zyga | (as in on a real core system you may see stuff that you won't see on core18 with apps running against core16) | 15:57 |
| mvo | zyga: lets start with the simple case and just remove the special handling on core18, i.e. on core18 it always behaves like on classic, we always construct the mount namespaces from the snaps | 15:57 |
| mvo | zyga: i.e. on anything not old-core | 15:57 |
| zyga | mvo: yes, I agree | 15:57 |
| zyga | that's what I'm doing now | 15:58 |
| mvo | zyga: \o/ | 15:58 |
| pstolowski | yay, my go-udev patch merged upstream | 16:10 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | nice :) | 16:20 |
| mvo | pstolowski|afk: yay | 16:34 |
| mup | PR snapcraft#2171 closed: {catkin,python} plugin: support cleaning <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2171> | 16:50 |
| mup | PR snapd#5421 opened: tests: replace MATCH by grep to check users created for ubuntu core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5421> | 17:07 |
| sergiusens | kyrofa: 2167 is a little larget than I thought it would be :-P | 17:14 |
| kyrofa | sergiusens, ignoring the tests? | 17:28 |
| kyrofa | sergiusens, snapcraft#2172 should be all good now | 17:55 |
| mup | PR snapcraft#2172: many: add shellcheck to static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2172> | 17:55 |
| mup | PR snapd#5422 opened: devicestate: fix race when refreshing a snap with snapd-control <Created by mvo5> <https://github.com/snapcore/snapd/pull/5422> | 18:00 |
| kyrofa | Hey zyga, I'm having trouble running snaps in lxc on my desktop: cannot remount /tmp/snap.rootfs_nMP7A9/var/lib/snapd/lib/vulkan as read-only: Permission denied | 18:55 |
| kyrofa | zyga, any ideas? | 18:55 |
| zyga | oh, feels like a bug | 18:55 |
| zyga | dmesg | grep DENIED | 18:56 |
| kyrofa | Run that on the host or the guest? | 18:56 |
| zyga | either, it is lxc | 18:56 |
| kyrofa | zyga, [61955.378584] audit: type=1400 audit(1530126985.909:482): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-brave-drum_</var/snap/lxd/common/lxd>" name="/tmp/snap.rootfs_o6dcBz/var/lib/snapd/lib/vulkan/" pid=12945 comm="snap-confine" flags="ro, remount" | 19:17 |
| kyrofa | zyga, this is a vanilla, confined container | 19:22 |
| zyga | one sec | 19:22 |
| zyga | hum | 19:23 |
| zyga | is this a privileged container? | 19:23 |
| zyga | this looks like a bug in lxd to me, why is it running snap-confine under its own profile? | 19:24 |
| zyga | hmm | 19:24 |
| zyga | stgraber: ^ | 19:25 |
| kyrofa | No, it's unprivileged. Just `lxc launch ubuntu:xenial -e` | 19:25 |
| stgraber | kyrofa: what snap? | 19:27 |
| kyrofa | stgraber, any, but that particular test was cla-check | 19:27 |
| kyrofa | stgraber, happens when running any app | 19:27 |
| kyrofa | stgraber, running on bionic, lxd 3.1 via snap | 19:28 |
| stgraber | hmm, can't reproduce this here | 19:29 |
| stgraber | running a xenial container on current lxd on bionic, then install hello-world or cla-check inside the container, both work fine | 19:29 |
| kyrofa | Could it have something to do with my nvidia card? | 19:30 |
| stgraber | getting a clean 18.04 install on a maas node now to see if that behaves differently | 19:30 |
| stgraber | kyrofa: could be, yeah | 19:30 |
| zyga | nvidia? how? | 19:31 |
| stgraber | root@c2:~# hello-world | 19:31 |
| stgraber | cannot remount /tmp/snap.rootfs_uuibb2/var/lib/snapd/lib/vulkan as read-only: Permission denied | 19:31 |
| stgraber | on a system with an nvidia gpu | 19:31 |
| kyrofa | Ah! | 19:31 |
| kyrofa | zyga, just saw the word "vulkan" and took a leap | 19:32 |
| zyga | yes, that part is related | 19:32 |
| kyrofa | That's all I got :P | 19:33 |
| zyga | but the question is, why did snap-confine not get an apparmor profile | 19:33 |
| zyga | can you do this from inside the container | 19:33 |
| zyga | sudo aa-status | 19:33 |
| stgraber | kyrofa: anyway, a workaround you can probably use for now is "lxc config set NAME security.nesting true" which will unrestrict some mount operations | 19:33 |
| zyga | stgraber: what does that do? | 19:34 |
| kyrofa | zyga, sure thing: https://paste.ubuntu.com/p/55BMdHBfxy/ | 19:34 |
| stgraber | zyga: pretty much allows all mounts everywhere in the container which likely includes remounts. | 19:35 |
| zyga | this looks fine | 19:35 |
| kyrofa | stgraber, indeed, that seems to let the mount through and the app works | 19:35 |
| stgraber | zyga: I suspect the denial is correct in that it's the underlying LXD apparmor profile which refuses the mount, not the snap-confine profile that's loaded on top | 19:35 |
| zyga | stgraber: I see | 19:35 |
| zyga | so the outer profile needs to allow this as well | 19:35 |
| zyga | re | 19:40 |
| zyga | I just had a silly incident with one of the random dev boards I had around started serving everyone new IP addresses faster than my router :P | 19:40 |
| chiluk | something broke snappy gnome-calculator http://paste.ubuntu.com/p/dFJjCxpXpT/ | 19:42 |
| chiluk | how is this even possible? | 19:42 |
| kyrofa | zyga, stgraber, so how does having an nvidia card result in a mount that is denied, while none of the other mount magic is denied? | 19:42 |
| stgraber | kyrofa: probably because only that triggers some snapd hook for vulkan/gl stuff which apparently bind-mounts stuff and then does a remount,ro | 19:42 |
| zyga | kyrofa: when you have nvidia we do more things | 19:42 |
| stgraber | the remount,ro part is what apparmor denies | 19:42 |
| kyrofa | Ah, so the bind mount is okay, it's the remount that's problematic | 19:43 |
| stgraber | yep | 19:43 |
| zyga | chiluk: are the two snaps connected? | 19:43 |
| chiluk | nope ... | 19:43 |
| chiluk | but I haven't screwed with any of the snaps. | 19:44 |
| stgraber | it's safe for us to allow bind-mounts in general, remounts are more risky | 19:44 |
| kyrofa | So what is the fix for this? Does snapd need to be doing something different? | 19:44 |
| chiluk | and breaking the calculator is kind of a shit show.. | 19:44 |
| chiluk | zyga ... I could connect the two. | 19:44 |
| zyga | chiluk: can you share "snap changes" | 19:44 |
| zyga | kyrofa: the fix must happen in lxd | 19:44 |
| chiluk | http://paste.ubuntu.com/p/rJX6bPYjBV/ | 19:45 |
| chiluk | zyga... I ran snap refresh today in hopes that there was an updated snap.. | 19:45 |
| kyrofa | zyga, what is the fix? Just allowing remounts. even though they're risky? Or something more specific? | 19:45 |
| zyga | chiluk: and snap interfaces | grep gnome-calculator | 19:45 |
| zyga | kyrofa: well, to allow this specific operation | 19:46 |
| chiluk | zyga http://paste.ubuntu.com/p/gNWj9FDH5g/ | 19:46 |
| zyga | chiluk: it seems to be connected here | 19:46 |
| zyga | gnome-3-26-1604:gnome-3-26-1604 gnome-calculator,gnome-characters,gnome-logs,gnome-system-monitor | 19:46 |
| kyrofa | stgraber, can lxd allow snap-confine specifically to remount? | 19:46 |
| stgraber | kyrofa: nope | 19:47 |
| chiluk | zyga.. I believe you... and it's connected on my desktop as well, but the question still remains how did they get unconnected? | 19:47 |
| stgraber | kyrofa: apparmor doesn't let you do per-process and even if it did, there'd be nothing preventing root in the container from calling a random binary snap-confine | 19:47 |
| zyga | stgraber: what I don't undertand is how the host of other mounts/remounts we do is ok | 19:47 |
| chiluk | I haven't explicitly been doing any snappy things.. | 19:47 |
| zyga | and this is not? | 19:47 |
| zyga | chiluk: can you run: sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt | 19:47 |
| zyga | chiluk: and then: cat /proc/self/mountinfo | 19:47 |
| stgraber | zyga: I suspect the rest of the things you're doing is just bind-mounts or standard mounts | 19:48 |
| zyga | pastebin the result and exit that shell to go back | 19:48 |
| zyga | stgraber: interesting, let me check | 19:48 |
| stgraber | zyga: I don't see any case where our profile would allow for remounts | 19:48 |
| zyga | yes, that's the only place that we remount | 19:49 |
| stgraber | I have a change here which allows specifically remount,ro and nothing else, but I'm not sure that this is actually safe, at least I very much doubt that it is for privileged containers | 19:49 |
| chiluk | zyga http://paste.ubuntu.com/p/NjGJMYwkTx/ | 19:49 |
| zyga | stgraber: is this done at apparmor level, why is remounting something read-only not allowed | 19:49 |
| stgraber | zyga: because remount is a fs operation, not a mount operation, so if you pass a bind-mount from the host and do remount,ro, now the path on the host is read-only too | 19:50 |
| stgraber | zyga: which was a pretty simple DoS attack for privileged containers against their host | 19:50 |
| zyga | stgraber: you can pass MS_BIND| MS_REMOUNT to specifically make the bind mount read only, no? | 19:50 |
| zyga | and we don't do that! | 19:50 |
| stgraber | right, you don't do that :) | 19:51 |
| zyga | chiluk: can you finally paste /run/snapd/ns/snap.gnome-calculator.fstab | 19:51 |
| zyga | chiluk: this should be enough | 19:51 |
| zyga | stgraber: thanks, I will correct this shortly | 19:51 |
| zyga | kyrofa: thank you! | 19:51 |
| kyrofa | zyga, stgraber, thank you both! | 19:51 |
| chiluk | zyga http://paste.ubuntu.com/p/JwbbwbFfcV/ | 19:52 |
| zyga | kyrofa: can you please drop a topic on the forum with basic info "lxd + nvidia = sad snappy" | 19:52 |
| zyga | I will do the rest | 19:52 |
| kyrofa | zyga, of course | 19:52 |
| stgraber | kyrofa: make sure to mention the security.nesting workaround, that's not great but it works | 19:52 |
| zyga | chiluk: can you do "snap list" and share the revision of gnome-calculator and the gnome platform snap | 19:53 |
| chiluk | zyga see first pastebin | 19:53 |
| zyga | ok, sorry, looking | 19:53 |
| zyga | hmm | 19:55 |
| chiluk | zyga... It still could be something I did, but that seems unlikely... I feel like other users will probably eventually hit this. | 19:55 |
| zyga | let me read the mount table | 19:55 |
| zyga | this is what snapd claims it did: /snap/gnome-3-26-1604/64 /snap/gnome-calculator/178/gnome-platform none bind,ro 0 0 | 19:56 |
| zyga | I'm checking if that's true | 19:56 |
| zyga | curiously it doesn't seem to be true | 19:56 |
| zyga | did this happen just now? | 19:57 |
| chiluk | it's been happening for a few days.. I'm pretty sure it persists over restart. | 19:57 |
| chiluk | I guess I could check... | 19:57 |
| zyga | can you disconnect and re-connect that interface to see if this fixes it | 19:57 |
| zyga | sadly we don't log much when that part fails | 19:58 |
| chiluk | you mean run snap connect? | 19:58 |
| zyga | yes, please disconnect and re-connect gnome-calculator:gnome-3-26-1604 | 19:58 |
| chiluk | snap connect gnome-calculator:gnome-3-26-1604 | 20:00 |
| chiluk | error: snap "core" has no "content" interface slots | 20:00 |
| zyga | I think you need to spell both sides of the connection this time | 20:00 |
| zyga | sorry | 20:00 |
| zyga | it should tab-complete though | 20:00 |
| chiluk | snap connect gnome-calculator:gnome-3-26-1604 gnome-3-26-1604 | 20:00 |
| chiluk | ^^ made it work. | 20:01 |
| chiluk | as I expected. | 20:01 |
| chiluk | but I don't care about fixing this for me. | 20:01 |
| chiluk | I'm a little confused as to why it broke in the first place. | 20:01 |
| chiluk | because I can't be the only one. | 20:01 |
| zyga | can you jump into the mount ns | 20:01 |
| zyga | and collect mountinfo again please | 20:02 |
| zyga | same as last time (same commands) | 20:02 |
| zyga | I would like to diff the two | 20:02 |
| chiluk | http://paste.ubuntu.com/p/3yZmBfBB5C/ | 20:02 |
| zyga | thank you | 20:02 |
| stgraber | zyga, kyrofa: https://github.com/lxc/lxd/pull/4704 | 20:03 |
| mup | PR lxc/lxd#4704: lxd/apparmor: Allow ro bind-mounts and remounts <Created by stgraber> <https://github.com/lxc/lxd/pull/4704> | 20:03 |
| kyrofa | zyga, chiluk, just throwing this out there, but gnome-software has the ability to twiddle those as well, no? | 20:03 |
| zyga | sure enough :/ | 20:03 |
| zyga | https://www.irccloud.com/pastebin/TevxFMh7/ | 20:03 |
| stgraber | this allows the read-only bind-mounts which you should be using for both priv and unpriv + allows ro remounts for unpriv | 20:04 |
| zyga | kyrofa: yes but we _claim_ this is connected, we _claim_ it is mounted (snapd) and it's not | 20:04 |
| zyga | so clearly something was broken | 20:04 |
| chiluk | right... | 20:04 |
| kyrofa | Ah interesting | 20:04 |
| chiluk | how'd it get that way though? | 20:04 |
| zyga | stgraber: I will fix this in snap-confine, I think it's clearly our mistake because lack of MS_BIND is confusing from an API POV | 20:05 |
| zyga | chiluk: that's the question | 20:05 |
| zyga | chiluk: if you can reproduce this please tell me, I'd love to know what happened | 20:05 |
| zyga | chiluk: do you have any denials in recent history | 20:05 |
| chiluk | yeah that's unlikely. | 20:05 |
| zyga | sadly, as I said, snapd doesn't log this | 20:05 |
| chiluk | zyga.. are you talking app armor? | 20:06 |
| kyrofa | stgraber, wait, I thought ro remounts were unsafe since they set the host dir ro as well? | 20:06 |
| zyga | chiluk: yes | 20:06 |
| zyga | kyrofa: it's subtle | 20:06 |
| zyga | kyrofa: we don't want to remount the filesystem | 20:06 |
| zyga | kyrofa: we want to remount the bind mounted view | 20:06 |
| === pbek_ is now known as pbek | ||
| chiluk | zyga syslog:Jun 27 15:00:44 groovy kernel: [233210.052692] audit: type=1400 audit(1530129644.316:573): apparmor="DENIED" operation="open" profile="snap.gnome-calculator.gnome-calculator" name="/home/dchiluk/Templates/" pid=20481 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 20:07 |
| zyga | guys it's 22:06 and I have snap-confine patches all over my screen, I need to take the dog out, take a shower and not hack much more | 20:07 |
| zyga | chiluk: that's not related, so if that is the only denial you had I have no other ideas :/ | 20:07 |
| kyrofa | zyga, I think I understand what you need to change on the snapd side, I just don't understand that lxd PR, since it covers filesystem remounts, no? | 20:07 |
| chiluk | zyga looking | 20:07 |
| zyga | kyrofa: I think the lxd PR is a separate topic now, I'm not sure it is strictly speaking mandatory or safe (as stgraber explained earlier) | 20:08 |
| zyga | if fixing snap-confine is sufficient to address this we should know soon (it will be in edge in about a day) | 20:08 |
| zyga | but first | 20:08 |
| zyga | dog/shower/sleep | 20:08 |
| stgraber | kyrofa: note that I only allow those for unpriv containers where the kernel will not let them propagate to the host | 20:09 |
| zyga | ah | 20:09 |
| zyga | that's nice, I didn't know the kernel does that | 20:09 |
| zyga | how does it decide? | 20:09 |
| stgraber | by looking at the kuid tied to the original mount | 20:11 |
| stgraber | if that doesn't match your kuid then you get EPERM | 20:11 |
| stgraber | obviously that doesn't work for privileged containers as those run as real root and so you totally do have the right to go and mess with the host mount table | 20:12 |
| chiluk | zyga nothing more about calculator or snap that seems relevant in the logs. | 20:13 |
| kyrofa | stgraber, ah, interesting, okay | 20:15 |
| chiluk | zyga nothing more about calculator or snap that seems relevant in the logs. | 20:15 |
| kyrofa | stgraber, thank you for putting that together! | 20:15 |
| chiluk | zyga if it's any consolation it looks like this machine was installed with 18.04 pre-release *(probably around beta stage)... maybe that's it. | 20:17 |
| zyga | No chiluk, this happened since your last reboot | 20:24 |
| zyga | This is purely volatile state | 20:24 |
| sergiusens | kyrofa: we need to stop moving back and forth with our comm platform :-P But yeah, the code sans tests is quite large; I am not doing a light review and my state of mind right now also complicates things | 20:29 |
| kyrofa | sergiusens, haha, I sent that ages ago! Slack is back up, we can talk there if you like | 20:34 |
| kyrofa | Take your time on the review | 20:34 |
| sergiusens | well, I would rather discuss here, until I have the urge to paste something :-P | 20:36 |
| sergiusens | kyrofa: I setup matrix during the weekend and added elopio as I knew he was on, he told me you are his only other friend there :-P | 20:36 |
| kyrofa | Works for me! | 20:36 |
| kyrofa | Hahahahahaha | 20:36 |
| sergiusens | kyrofa: if you dismiss my review I lose the ability to approve from the same pane :-P | 20:40 |
| kyrofa | Oh I didn't actually realize that was a possibility in the first place. How fancy! | 20:41 |
| kyrofa | Looking forward to that one landing. Not sure how some of this has been working | 20:45 |
| mup | PR snapcraft#2172 closed: many: add shellcheck to static tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2172> | 21:32 |
| sergiusens | kyrofa: ok, so first pass on #2167 is done | 21:34 |
| mup | PR #2167: snapstate, devicestate: do not remove seed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2167> | 21:34 |
| sergiusens | kyrofa: what do you think of making the <topic>: in the merge more functional instead of locational? Else you get "many:" for most things and it loses importance. | 21:37 |
| kyrofa | sergiusens, yeah I think most of the time they're the same, sans many :P | 22:05 |
| kyrofa | I'm good with that, I'll avoid many | 22:05 |
| kyrofa | sergiusens, updated snapcraft#2167 | 23:15 |
| mup | PR snapcraft#2167: many: detect local source changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2167> | 23:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!