/srv/irclogs.ubuntu.com/2018/10/05/#snappy.txt

=== chihchun is now known as chihchun_afk
mupPR snapd#5926 closed: store: tweak unmatched refresh result error log <Simple 😃> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5926>01:23
mupPR snapcraft#2318 closed: meta: add support for the license field <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2318>01:25
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== JanC_ is now known as JanC
=== JanC is now known as Guest80969
=== chihchun_afk is now known as chihchun
mborzeckimorning05:02
zygaHey hey05:26
zygaTime to get to work05:27
mborzeckizyga: anything interesting happened yday?05:39
zygaHmmm06:10
zygaSome things yeah06:12
zygaCurrently taking the dog out so harder to type06:12
mupPR snapd#5923 closed: overlord: don't make become-operational interfere with user requests (2.35) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5923>06:41
mupPR snapd#5924 closed: overlord: don't make become-operational interfere with user requests (2.36) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5924>06:41
mupPR snapd#5928 closed: cmd: put our manpages in section 8 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5928>06:44
mborzeckihm our socket unit files should probably just have `Wants=<mount unit> sockets.target` and we should not use network.target in there06:50
mvomborzecki: indeed06:57
mborzeckii'll open a PR06:58
mvota06:58
mborzeckii'll be good to have it cherry picked to 2.36 too06:58
mborzeckifrom what i found in systemd source code, when there's a cycle it'll drop/delete the job(s) that is/are not directly required by the anchor job (the main job that's at the top of transaction chain?)07:01
mborzeckii guess if stars align and you're unlucky enough some target may be dropped (network.target maybe?) or nm service/start job, then you'd end up without wifi/eth whatever07:02
zygamvo: are you tracking all the 2.36 PRs for backports?07:03
mborzeckigood question, mvo should i open backport PRs to 2.36 of #5898 and #5905?07:06
mupPR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5898>07:06
mupPR #5905: store: gracefully handle unexpected errors in 'action' response <Simple 😃> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5905>07:06
pstolowskimornings07:09
mvomborzecki: I think we can ignore the test one but the other one yes please07:14
mvomborzecki: if its a single commit I can cherry pick07:14
mborzeckimvo: please cherry-pick the simple one07:14
mborzeckimvo: as for the test one, it has some tweaks/cleanups in the code, so it'd still be useful, i"ll open a PR for that07:15
mvomborzecki: ok07:15
mvomborzecki: cherry-picked07:15
mborzeckimvo: ta07:15
zygamvo: should I prepare a chain of backports?07:18
mupPR snapd#5234 closed: snap: add `snap list --format=...` option <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5234>07:19
mvozyga: for what exactly?07:19
zygaFor things I tagged 2.36 and landed in master07:19
mupPR snapd#5929 opened: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5929>07:20
mvozyga: let me have a look07:20
zygaOk, please let me know07:20
mvozyga: given a) we need to do a 2.35.3 and b) how much 2.36 prs are tagged I wonder if we should simply take master for ~pre2, we didn't merge anything scary iirc07:22
zygaMmmm, interesting07:24
zygaWhat is the motivation for 2.35.3?07:24
mvozyga: we need a fix for the unionfs issue on the livecd07:25
zygaAh07:25
mvozyga: without that the snaps on the live media do not start07:25
zygaOverlayfs07:26
mvozyga: which is release criticial for cosmic07:26
zygaBut sure07:26
mborzecki+1 for ~pre2 from master07:26
mvook, let me prepare 2.35.3 and then I look at this, until then, no more backport PRs please :)07:27
zygaOk07:35
ackkhi, I'm getting the following error when trying to run a command from a snap: cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_zr48qw//lib/modules: No such file or directory07:38
ackk 07:38
ackk(the same happens to a service in the snap)07:38
zygaackk: this is fixed in master07:45
zygaTry beta/edge perhaps07:45
ackkzyga, of what?07:45
ackksnapd?07:45
zygaYes07:46
zygaWell, core snap07:46
ackkyeah that worked.07:48
pedronismvo: hi, seems we don't have a 2_35 tag in the forum?07:48
mvopedronis: looking07:49
mvopedronis: I added one now07:49
pedronisthanks07:49
mvopedronis: and added it to "clarification on seed.loaded"07:49
pedronismvo: yes, did the same, added 2.36 as well07:50
pedronisthank you07:50
pedronis:)07:51
mvo:)07:52
Chipacamorning peeps! welcome to Friday :) how do we close PRs today?08:25
zygaWholesale08:27
Chipacalooking at my own PRs: #5879 can use another review08:27
mupPR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>08:28
Chipacaand #5888 also08:28
mupPR #5888: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>08:28
zygaI’ll help08:28
Chipacawheee :)08:28
zygaJust back hurts somewhat today08:28
Chipacazyga: you were fine yesterday before you decided to do this dodge "sleep" thing08:28
Chipacadodgy*08:29
Chipacaalso, review stuff or I'll make your browsers crash with emoji overload from looking at the pr page08:29
zygaYeah, yesterday was too long08:30
zygaNot enough walking08:30
Chipacaah, yeah, that'd suck08:31
Chipacayesterday I went to the gym and thought I'd had a bad day, turns out i was just pushing myself too hard (still got through 600kcal in an hour)08:31
Chipacaniemeyer: I got an email telling me you changed the standup meeting, but it looks the same to me. What's different?08:35
Chipacaniemeyer: (morning!)08:35
niemeyerChipaca: moin! If I didn't do anything wrong, I just declined today's event08:36
mvoniemeyer: he is off today, no?08:36
niemeyerYes, in theroy at least :)08:36
mvoheh08:36
* Chipaca reaches for his get-off-irc-then stick08:37
Chipacaniemeyer: :) enjoy08:37
Chipacagoogle calendar is wacko, but holidays are good08:37
mupPR snapd#5930 opened: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5930>08:58
mborzeckimvo: ^^08:59
mvomborzecki: cool! looking08:59
Chipacazyga: is #5170 ready for re-review?09:00
mupPR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>09:00
mvomborzecki: uh, do we need this for 2.35 as well?09:00
mvomborzecki: thats not a regression, is it?09:00
mborzeckihm, i'd say yes09:00
zygaChipaca: I think so but let me double check09:00
mborzeckimvo: let me open a PR for 2.35 so that it gets a full spread run09:01
mvomborzecki: uh, ok. that means 2.35.409:01
Chipacazyga: if so, I'd say @-mention the j of the d strand09:01
zygayes John, it is ready09:01
zygaI wanted to get an ack from Gustavo first as s-j is busy lately09:01
zygato avoid re-review if we change direction09:02
mborzeckimvo: while at it, i'd like to get the feedback if the change, once in edge, fixes problems people have observed09:02
mvomborzecki: silly question but we remove network-online.target so what did we do that triggered a regression09:05
mvomborzecki: hm, I see we just changed it to network.target09:05
mvomborzecki: ok, but that is no regression, is it? I mean this was broken before09:06
mvomborzecki: (may still be a good idea to do a .4 for this but I want to figure out if we have to because of regression or if its "optional")09:06
zygaIMO serious bugs are serious bugs, regression or not09:06
mvozyga: we had this serious bug from day one09:08
mvozyga: well, since we added socket activation09:08
zygalet's fix it and move on :)09:08
mvozyga: there is a cost, I'm not saying we shouldn't do it just want to understand the details09:09
mvomborzecki: you have a review, looks great, just one comment09:09
Chipacazyga: #5469 is also blocked on gustavo09:12
mupPR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>09:12
Chipacazyga: and that one's blocking a customer09:12
mvoChipaca: my dotfiles as well09:12
* Chipaca wants mvo's dotfiles09:12
ChipacaI'll auction them at sotheby's or something09:13
mvoChipaca: haha09:13
mvomborzecki: I pushed a tiny addition to your PR09:13
mvomborzecki: (i.e. resolving my comment)09:14
mvomborzecki: after thinking about this I think you (and zyga) are right, this is worth a 2.35.409:14
niemeyerzyga: BTW, to unblock the snap-update-ns work, I suggest simply looking for the presence of a flag file on a good location that only root can write09:18
niemeyerzyga: Flag file could be .experimental-snap-update-ns for example09:19
zyganiemeyer: yeah, I can just assume it's set for now. It's good enough to move the rest forward. We can discuss the details next week09:19
niemeyerzyga: This file is a trivial one-liner anywhere you want to test for it09:19
zyganiemeyer: perhaps this can even do away without an experimental flag it if lands after this release09:19
niemeyerzyga: as long as we're sure it works09:20
zygayep09:20
zygasomething like facts could be useful later on though for things we kind of abuse facts for today (like telling snap-confine that a given snap is in classic mode without any way to abuse it)09:21
zygaor telling snap-confine what snapd thinks about the distribution directory layout09:21
zygabut regardless, for user mounts we can unblock09:22
mvomborzecki: happy to help with the backport of 5930 to 2.3509:24
Chipacaniemeyer: if you're not not here, #5469 is the 4th-oldest PR, waiting for your re-review, blocking a customer. Not flagged as urgent though so if you _are_ not here, go away already09:29
mupPR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>09:29
mvomborzecki: aha, its there, nice!09:31
mborzeckimvo: from what i understand, adding network.target and being wanted by sockets.target made us move the network target to be reached before 'basic', with defautl dependencies being basic and sysinit, NM which ash Before=network.target + defaults made a cycle09:31
mvomborzecki: aha, that makes sense09:32
mupPR snapd#5931 opened: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5931>09:35
niemeyerChipaca: There's no relevant internal or external design changes in there which would greatly benefit from my input (I think?).. if you and the team are comfortable that the change in behavior is correct, I suggest just going ahead09:35
mborzeckimvo: full PR to 2.35  ^^09:35
mvota09:35
Chipacaniemeyer: neat. I'll document this by retracting your PR.09:36
Chipacadismissing it even09:36
mvoChipaca: is it land-it-friday today :) ?09:37
Chipacaoh yes09:37
Chipacamvo: we hit 50 PRs yesterday09:37
mborzeckimvo: 5930 needs your +1 too :)09:37
Chipacamvo: you know how that affects me :)09:37
mvomborzecki: indeed and a second review09:38
mvoChipaca: haha, sounds like a good plan09:38
Chipacaniemeyer: now go away and enjoy yourself doing … whatever it is people do out there09:38
Chipaca:)09:39
zygamvo: merge everything ;)09:39
Chipacamvo: I'm even using my gh.go thing (which made me merge a bit too overeagerly yesterday, to pedronis's chagrin)09:39
zygaChipaca: wow, the icons on hot plug are ... really nice!09:39
Chipacahehe09:40
niemeyerYes, I'm doing something very important right now by constructing a Minecraft head out of a cardboard box.. lots of focus required :P09:40
Chipacaniemeyer: ah. Make sure you get the derp eyes just right.09:40
Chipacaniemeyer: otherwise you might accidentally herobrine09:41
zygaand we will have to remove him in a point release!09:41
* zyga wonders who gets Minecraft lore references...09:42
ogradid you guys break core ? my edge images just exploded in my face09:42
zygaogra: break core on Friday? what are we, workaholics?09:42
niemeyerYeah, we were trying to break it for a while..09:42
* niemeyer steps out quietly..09:43
ograavahi cant start anymore https://paste.ubuntu.com/p/RzH4y8TZDm/ and the only snap that got updated on this image was core09:43
ogra(the image was feshly built from edge yesterday evening)09:43
zygaogra: and seriously, no idea, does it work if you switch core to stable?09:44
ograon it, waiting for the reboot09:44
zygathank you09:44
Chipacazyga: #5469 GTG at your discretion09:45
ograyes, works fine i can ping the mdns addres again09:45
mupPR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>09:45
ogra*address09:45
ograseems whatever landed in edge does not create XDG_RUNTIME_DIR for the app snaps09:46
zygaChipaca: thanks, I think it is file to land09:46
Chipacacool cool09:46
mvoogra: core traveled back in time from edge to 2.35.309:46
mvoogra: now it has traveld back09:47
mvoogra: but will soon travel again for 2.35.409:47
ogramvo, well, something broke09:47
mupPR snapd#5469 closed: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5469>09:47
mvoogra: yeah09:47
ograbtw, is it normal that gadgets never survive delta generation ? all other snaps i push do it fine09:49
zygahmm?09:49
ograError generating delta: There has been a problem while processing a snap delta.09:49
ogra  - Delta service failed to apply delta successfully09:49
ograFalling back to pushing full snap...09:49
ograwith snapcrft push09:49
ogra*snapcraft09:49
zygano idea but I doubt it's desired09:49
ograk, because i have only seen it with gadgets09:50
zygaogra: look if snap craft leaves a log with the reason for the failure09:50
ogranope, doesnt ... (and i would be surprised, i think thats all happening server side after the upload)09:51
zygano, the delta is local09:52
zygait is a local delta for speeding up the upload09:52
ograah09:52
ograindeed09:52
ogramy brain is kind of friday today :P09:52
axinohi09:56
zygahello axino09:56
axinoo/ zyga09:56
axinois this the proper place to ask how to get a snap owned by ~snapcrafters ?09:56
zygaaxino: I think the forum is the better place09:57
zygaperhaps popey can help though09:57
popeyhello10:00
popeyaxino: which snap?10:00
axinopopey: a "redis" snap I'm currently building10:00
popeyaxino: have you spoken to the upstream redis people? :)10:01
axinopopey: heh, I have not :)10:01
popey(We'd rather snaps went upstream first, rather than direct to snapcrafters)10:01
axinoindeed, indeed10:02
axinoI'll see what I can do10:02
axinozyga popey : thanks !10:03
zygaChipaca: do you have a second10:04
zygai see a failure in something that looks like travis job stages10:04
zygawould you mind having a look?10:04
zygaI know nothing about that10:04
zygahttps://travis-ci.org/snapcore/snapd/jobs/43709602910:04
Chipacazyga: where?10:04
* Chipaca clicks10:04
Chipacazyga: is that the right link?10:05
zygatwa10:05
zygayes10:05
zyga: /home/travis/.travis/job_stages: eval: line 98: syntax error near unexpected token `newline'10:05
zygaline 45010:05
Chipacahuh10:06
mvoI suspect thats from travis itself, no?10:06
zyganot sure10:07
zygabut looks like it's not a fatal but real proble10:08
Chipacazyga: whatever it is, it seems to be innocuous10:08
Chipacazyga: i see the same error in successful runs10:08
Chipacae.g. https://travis-ci.org/snapcore/snapd/jobs/43456143910:08
Chipacazyga: with any luck the things it's spewing there aren't parts of any key :-)10:08
Chipacai'll dig a little anyway10:09
zygayeah, we just name variables with long hexadecimal names ;)10:09
zygathanks! just something that caught my eye10:09
Chipacazyga: https://github.com/travis-ci/travis-ci/issues/617410:10
zygawow10:11
zygawe must up our use of bug report images10:11
mupPR snapd#5929 closed: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5929>10:12
Chipacahmmmmmmmmmmmₘₘₘₘₘₘₘₘₘₘ10:15
mborzeckilittle ₘ ?10:15
Chipaca𝗡𝗼10:17
ChipacaI wonder if the secure: encoding is brittle in that it needs to be in the exact same place in the yaml for it to work10:18
ChipacaOTOH the tests pass, so _something_ is working :)10:18
ChipacaI'll try moving them up to the top level later10:18
mvohrm, hrm, it looks like opensuse tests are failing again10:23
mvodidn't we put those on manual? curl error 52 when talking to their repo10:23
mupPR snapd#5932 opened: spread: put openSUSE to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/5932>10:26
mborzeckimvo: yes, in master at least10:27
mvoit looks like it got reverted, I think we need it again, right now things are failing and I want to release 2.35.4 :/10:28
mborzeckimvo: uh, ok, they were manual in master on wednesday :)10:28
mborzeckihttps://status.opensuse.org/ still partial outage of mirroring infra10:28
mborzeckiwonder if the page is actually updated10:29
zygamvo: yes but we reverted that10:33
zygamborzecki: yeah, I saw changes yesterday10:33
zygamvo: sorry about that, I flipped it back after seeing good results on my local machine10:33
zygammm10:37
zygapstolowski: about getHotplugSlots10:37
pstolowskizyga: yes?10:38
zygathey override any implicit slots10:38
zygaas in10:38
zygaactually, any slots10:38
zygashould we not check that there are no clashes?10:38
mvohrm, also travis is handing out slots really slowly10:39
pstolowskizyga: they won't, it's not visible in this PR, but when they are generated i ensure they have unique name (by appending a number if neccessary etc)10:40
zygaunique name among what set?10:41
pstolowskizyga: but perhaps an extra check + internal error here is a good idea?10:41
mborzeckihmm Chipaca degville you install snaps 'on' the system or 'in' the system? because the long and short help message disagree on this10:42
Chipacaon, in, to10:43
mborzeckipick one basically?10:43
Chipacai don't have a strong reason to pick one over another10:43
pstolowskizyga: unique among all existing slots in the repo and all remembered slots for currently missing devices10:43
Chipacamaybe degville does :)10:43
zygapstolowski: mm, but here we are presented with _a_ snap10:43
zygawe don't know what that snap has beforehand10:43
zygaI'd add a check, similar to implicit slots, that ensure we don't overwrite10:43
pstolowskizyga: i see what you mean, but this is a system snap, so only implicit + hotplug slots, no?10:46
zyga+ whatever is defined in snap.yaml :)10:46
pstolowskihmmm do we actually do/support that?10:47
pstolowskizyga: ok, i'll check that, thanks for the remark!10:49
zygathanks, I'm reading the rest10:49
ograsil2100, your latest edge image seem to not have the latest pi3 gadget (i can sadly currently not check the gadget in the sstore atm, there was an issue when mvo tried to switch me over from @ubuntu.com to @canonical.com) can you re-build the edge image and make sure at least rev 27 of the gadget is in ?11:00
ograsil2100, ondra tested on the b+ and a locally built image works fine, but the one on cdimage seems to still have rev 2211:01
sil2100ogra: wait, how is that possible? I checked the manifest and it said 27, as per my e-mail11:02
sil2100Is the manifest wrong?11:02
sil2100We build edge images daily btw.11:03
ogradunno ... one sec11:03
ograhttp://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz11:03
sil2100http://cdimage.ubuntu.com/ubuntu-core/16/20181005/ubuntu-core-16-armhf+raspi3.manifest11:03
sil2100ogra: the images in the 'edge' directory haven't been updated since beginning of the year11:04
sil2100http://cdimage.ubuntu.com/ubuntu-core/16/current/11:04
sil2100This is what should be used11:04
ograouch11:04
ograwe should clean that up then ;)11:04
sil2100Yeah, not sure why it's so confusing!11:04
sil2100Need to poke Steve next week why it's like that ;p11:04
sil2100(maybe there's some purpose for that, or maybe something broke that was supposed to use the edge/ directory)11:05
ograsil2100, there was initially ... websites had hardcoded links that needed to persist but i think thats bogus now11:06
ograo we hould clean up or at least set proper channel links there11:07
ogra*so11:07
=== chihchun is now known as chihchun_afk
degvillemborzecki, Chipaca: sorry, only just seen this. I think I have a slight preference for *on* - but no strong feelings. You usually say 'I put Firefox on the computer' so it kind of makes sense that we keep to that casual usage.11:14
zygait depends if the Firefox is quiet and doesn't move much, in that case you really have to put it in the computer and screw the side door tightly11:19
Chipacasee, this is why i don't have a preference, i'm still using chrome11:19
cachioChipaca, hey11:20
zygaif you put chrome on your Firefox you may lose warranty11:20
zygait makes the fur sticky11:20
cachiodid you ping me yesterday?11:20
degvilleThe teenage years were tought, but my Firefox seems to be finally past that stage.11:20
degvilles/tought/tough11:20
Chipacacachio: I did, but it's no longer relevant11:23
Chipacanow I'm worried for zyga's kids when they teen11:23
cachioChipaca, hehee11:24
cachioko11:25
zygaChipaca: technically they now are11:25
zygaChipaca: wanna be afraid more?11:30
zygaI may become a grandpa in the next 15 years11:30
Chipacazyga: I don't need flags to Unlinkat, fwiw11:31
zygano?11:31
Chipacanope11:31
zygaI'm looking forward to one to simplify some code11:32
Chipacaonly flag Unlinkat knows today is AT_REMOVEDIR, which I don't want11:32
zygaright, that's the one I want11:32
Chipacahehe11:32
Chipacasys/unix's Unlinkat does have that11:32
Chipacafwiw11:32
zygago itself has it11:32
zygajust doesn't expose it11:33
zygaI really don't like that logic11:33
zygait's either sys call or stdlib11:33
zygabut in golang,it's a bit of both11:33
Chipacazyga: #593311:40
zygammm11:40
mupPR #5933: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>11:40
cachiomborzecki, hey11:40
ograzyga, (and probably kenvandine ) https://lists.ubuntu.com/archives/ubuntu-users/2018-October/295405.html11:40
mupPR snapd#5933 opened: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>11:41
cachioI created the arch image with apparmor enabled but ...11:41
mborzeckicachio: hey11:41
zygaogra: feels like interface(s) that fuel the gnome system monitor need improvements11:41
cachiomborzecki, I am having a problem wiht this machine11:42
zyga pstolowski some reviews on hot plug PRs11:42
Chipacaogra: is having the journal on disk the default?11:42
cachiomborzecki, it is not starting the google services11:42
ograzyga, yeah ... note that we a) ship it by default and b) default to journald-to-disk logging now11:42
cachiomborzecki, so it can't be used by spread11:42
ograChipaca, i think so11:42
zygameta comment I would prefer a pub-sub model over blind logging11:42
zygabut that's what we have11:42
ograat least with 18.1011:43
mborzeckicachio: is it possible to access it via ssh?11:43
cachiomborzecki, it happens when we update the packages on that machine11:43
cachiomborzecki, no, via seria console11:43
mborzeckicachio: can i access that?11:43
cachiomborzecki, let me start one for you11:43
Chipacaogra: why isn't it being rotated?11:45
ograChipaca, works differently ... its a ringbuffer and is by default limited to a certain percentage of the rootfs disk11:46
ograon a multi terabyte disk 4GB is nothing ;)11:46
mvo5930 needs a second review11:47
* Chipaca looks11:48
Chipacahuh, i thought i'd done this one already11:49
Chipacagrrr opensuse11:55
* Chipaca ~> lunch-making11:55
zygaChipaca: commented11:56
mborzeckioff to pick up the kids11:56
* cachio afk11:59
cachio~ 10 mins11:59
Chipacazyga: d'oh, fixed12:08
zyga:D12:09
pstolowskizyga: thank you!12:22
diddledanpopeycore sounds like an awesome music genre12:23
mupPR snapd#5931 closed: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5931>12:41
zygaI'll stop reviewing now12:43
zygamy back is not great today and it's hard to focus12:44
mupPR snapd#5932 closed: spread: put openSUSE to manual <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5932>12:47
zygaChipaca: hey12:55
zygaChipaca: I realized the touch bar is good for one thing for sure :)12:55
zyga🐶🐼🐰🐽12:56
zygairc was never this 🕷12:56
* diddledan needs to google to find out how well it's supported in Linux12:58
pstolowskizyga: :D12:59
Chipacadiddledan: zyga: all you need to do is remember all the unicode code points, and then <ctrl>+<shift>+u1f577 <whitespace> gives you 🕷 tadaa13:03
diddledanhah13:03
zyga😭13:03
zygatouchbar is useless then13:04
Chipacazyga: U+1F631 FACE SCREAMING IN FEAR13:07
Chipacabrb renaming Hotplug to 🌶🔌13:11
mupPR snapd#5930 closed: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5930>13:16
mupPR snapd#5888 closed: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5888>13:29
axinopopey: do you know a good example of a charm hosted upstream and building automatically ? I'm mostly wondering how to dynamically handle snap versions13:31
mupPR snapd#5934 opened: release: 2.35.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5934>13:40
Chipacahmm, I know how i can speed up this :-D13:41
* Chipaca will do it on Monday13:41
mupPR snapcraft#2293 closed: build providers: use the new snapcraft: remote for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2293>13:44
zygasigh13:52
zygamvo: yeah, I will just rebuild :/13:52
mvozyga: rebuild the kernel?14:00
zygayep14:00
mvocachio: 2.35.4 is in the beta channel now14:01
cachiomvo, nice14:10
cachioI'll start14:11
cachiothanks14:11
mvocachio: thank you!14:14
=== chiluk_ is now known as chiluk
mupPR snapd#5935 opened: po: sync translations from launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/5935>14:32
* zyga uses this moment to build the kernel a few times 14:35
zygamvo: you win the PR of the year award15:10
zyga+42,937, -2,72915:10
zygawow15:10
stgrabermvo: hey there, so for those unix socket problems, (first network-online, then network.target), do we have an ETA for that landing in 18.10?15:11
stgrabermvo: we've seen a few reports of startup regression in cloud instances and the like ever since we started seeding LXD as a snap and enabled socket activation15:11
mborzeckistgraber: the 'fix' thing has landed in master, 2.36 and 2.3515:22
mborzeckiwould appreciate if you can check it on your end with core from edge (provided it's alreay been published)15:22
mupPR snapd#5934 closed: release: 2.35.4 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5934>15:31
mvostgraber: I uploaded the fix some hours ago into cosmic15:38
mvostgraber: let me see15:38
mvozyga: haha - this PR is great, isn't it?15:38
stgrabermvo: ah, is it in the queue?15:38
mvostgraber: yes15:39
zygamvo: yes but also somewhat worrying, bad i18n can cause issues15:39
mvostgraber: waiting for approval15:39
stgrabermvo: ok, let me review it quickly then15:39
zygathough go is much safer than C ever was so .. not terrible :)15:39
mvozyga: indeed15:39
mvostgraber: \o/15:39
stgrabermvo: accepted15:40
mvostgraber: cool, thanks15:42
pstolowskito whom should i bow for the nice beautification of the hotplug label in github? ;)15:42
mvopstolowski: probably Chipaca15:43
Chipacalies15:43
* Chipaca reads what he's been accused of15:43
mvopstolowski: thats my guess at least15:43
Chipaca<Chipaca> brb renaming Hotplug to 🌶🔌15:43
Chipaca:-)15:44
pstolowskibecause he loves unicode?15:44
zyga🌋15:44
pstolowskiChipaca: looking forward to parallel installs label ;)15:45
Chipacapstolowski: Probably a bit much :) I'll revert it to the older one15:45
mvopstolowski: unicode + beautiful sounds very much like Chipaca :)15:45
Chipacathere15:45
zyga15:45
mvozyga: haha15:45
Chipaca#588015:45
mvoChipaca: I think its fine15:45
mupPR #5880: interfaces/repo: two helper methods for hotplug <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5880>15:45
Chipaca#559615:46
mupPR #5596: [WIP] Parallel installs integration <Parallel installs ⛓> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>15:46
Chipacazyga: ^ at your command15:46
pstolowski:)15:46
zygaChipaca: please add one for user mounts 🏇15:47
zygajust because Friday is fun15:47
pstolowskiheh15:47
Chipacazyga: that chains thing doesn't work on github though15:47
Chipacazyga: no contrast15:47
zygabtw, I think we could use projects rather than labels (for this)15:47
zygammm15:47
* zyga looks15:47
mborzeckizyga: Chipaca: you can close it15:47
mborzeckithat parallel installs WIP15:47
Chipacazyga: you can create and edit labels too, you know? :)15:47
Chipacawhoa that was quick15:48
mupPR snapd#5596 closed: [WIP] Parallel installs integration <Parallel installs ⛓> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>15:48
Chipacamborzecki: no more parallel installs label then?15:48
mborzeckiChipaca: there will be one or two PRs more15:49
Chipacaah ok15:49
Chipacazyga: projects sounds nice, but I don't think they'll fit without quite a bit of admin on our end15:50
zygaadmin? they are just like labels, just pick and go15:51
mborzeckiheh we have this silly thing in arch in gce: https://paste.ubuntu.com/p/BJKrJ3yp7y/ so ssh starts, and then 10 minutes later actually starts listening on ports, wtf??15:51
mborzeckinetwork is up way before that15:51
Chipacazyga: "automated kanban with pull requests" using issues and stuff to trigger it15:51
mborzeckisshd is actually After=network.target15:51
zygaChipaca: I don't know what you just said but that's fine, it's Friday and I'm booting my kernels15:52
Chipacazyga: I think I'm going to go for a friday run, and then i'm going to have friday pizza and friday beer and maybe some friday guitar15:52
zygaI have a bottle of cider upstairs15:52
zygabut maybe I will take a ride on a bike before winter strikes15:53
ograwinter ?15:53
ogrado you also belive in santa ?15:53
ograwinter are over ... :P15:53
ogra*winters15:54
mborzeckiw8, aren't they coming?15:54
ogranah, we're letft with endless autumn now until jumping directly into summer in march15:54
zygawinter is coming, something something15:57
zygamy office is going to be feezing15:57
zygait's not well insulated15:58
mvoChipaca: if you do this you miss my review for 5913 ;)15:58
mvoChipaca: but +100, run+pizza sounds way more fun15:58
Chipacanooooo15:58
* ogra pokes the armhf builders on build.s.io with a pointy stick ... come on your x86 firends have finished the 2min build 30 min ago ... there is no reason to say "Building soon" !15:58
Chipacamvo: I've been told I said the run was at 5, so if it's not 5 they're not going yet15:58
zygamvo: it's actually slower than the desktop :/15:58
zygabut well, it's a laptop :)15:59
Chipacamvo: _now_ i'm off. But I'll give the review a look before the beer.16:00
mvozyga: what is slower than the desktop?16:02
zygathe laptop16:02
mvoChipaca: heh, no need, enjoy your WE16:02
mvozyga: aha, ok16:02
pstolowskiChipaca: any chance for +1 on https://github.com/snapcore/snapd/pull/5497 (i did the rename)?16:06
mupPR #5497: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>16:06
pstolowski(nad now as i fixed the trivials in my PRs, travis hates everything again)16:07
pstolowskiChipaca: ah, you're off. have a good weekend!16:08
pstolowskigood idea, actually16:08
=== pstolowski is now known as pstolowski|afk
ogracjwatson, put away the mop ! (... watching armhf on https://launchpad.net/builders)16:09
cjwatsonogra: see #launchpad-ops16:10
ogra(well, in fact watching arm64 but waiting for armhf capacity)16:10
cjwatsonogra: IS is working on it16:10
ograah, good16:10
ograthanks (i just wanted to make a bad friday joke anyway :P )16:11
mvoChipaca: added some comments, hope I'm not too annoying, I guess I shouldn't review when hungry16:15
mupBug #1796362 opened: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:New> <https://launchpad.net/bugs/1796362>16:26
mupPR snapd#5933 closed: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5933>17:26
zygait's still building...17:29
zygaI tweaked a few things and restarted the process twice17:29
zygamainly to add space to the VM :)17:29
zygaand to up the thread count17:29
mupPR snapcraft#2323 opened: go plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323>17:35
sergiusensmvo: that is probably close to your heart in case you want to check ^17:36
ChipacaEOW18:02
Chipacao/18:02
zygalinux-image-4.18-unsigned from cosmic, dpkg-build in a VM + music + some casual browsing took  76 minutes and wrote over 40GB of data!18:21
Pharaoh_Atemzyga, mvo: this should be fixed now: https://github.com/snapcore/snapd/commit/79b85c4009032cf61864ced46b97abe3793efbee18:41
mupPR snapcraft#2324 opened: plugins: remove the ament plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2324>18:41
mupPR snapd#5936 opened: Revert "spread: put openSUSE to manual" <Created by zyga> <https://github.com/snapcore/snapd/pull/5936>18:44
zygathanks Pharaoh_Atem18:45
mupPR snapcraft#2325 opened: plugins: remove the python2 and python3 plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2325>19:00
pedroniszyga: do you remember why we validate plug/slot name only when they are added to the repo and not when parsing snap.yaml ?19:07
zygammmmm19:09
zygaI was hoping we would validate the yams and then each added one19:10
zygabut I don't remember at this time more19:10
zygaI mean, we should definitely validate in the yaml19:10
zygaAFAIK we moved validation there even (the patterns)19:10
pedronisactually we don't validate them even when adding19:11
pedronisis done in AddSlot/AddPlug19:11
pedronisbut that is not really used19:11
zygammm19:11
* zyga looks19:11
pedronisyou can have a 22.33 slot afaict19:12
pedronis(unless I'm missing something)19:12
zygacorrect19:12
zygawow, that's bad :/19:12
zygaAddSnap calls Validate19:13
zygabut Validate doesn't19:13
zygaI guess we call sanitise19:13
zygain the end19:14
zygaperhaps that's why?19:14
zygabut the name validation should be done earlier19:14
pedronisdoes sanitize check the name?19:14
zygano, it's an optional helper, it used to be different before but not anymore19:15
zygalooking at this briefly nothing does now19:15
pedronisyea19:15
pedronisseems you can have fairly random plug/slot names atm19:15
zygaI'll fix that19:15
zygacorrect19:15
pedroniswe do have ValidateSlot/PlugName in snap but is not used in validate code19:20
jdstrandzyga: does opensuse-42.3-64 correspond to tumbleweed?19:21
zygapedronis: yep, branch coming up soon19:23
zygajdstrand: no, that is LEAP 42.3 (older LEAP, current one is .. 15)19:23
zygatumblweed is just that19:23
pedroniszyga: same for ValidateInterfaceName btw19:23
pedronisnot called19:23
zygapedronis: yeah, they are called from interfaces/19:24
zygaI moved them to snap to de-duplicate the code19:24
zygabut something got lost along the way19:24
pedronisbut not in all relefvant cases19:24
pedronisanyway we want to use them in validate code itself19:24
pedroniswonders if there are weird plug/slot out there19:25
pedronisgiven the missing validation19:25
* jdstrand wonders why spread -list doesn't list anything with opensuse any more19:25
pedronisjdstrand: it might have been set ot manual19:25
pedronisnot sure if that influences -list or not19:25
zygajdstrand: opensuse was disabled19:25
zygahttps://travis-ci.org/snapcore/snapd/builds/43776566219:25
jdstrandI'm looking at an old travis failure19:25
jdstrandoh, heh, ok19:25
jdstrandzyga: otoh, if I'm in the code that it setting up a snippet in one interface, can I query if another interface is specified/connected?19:29
zygaI don't believe so19:29
jdstrandthat's sucky19:29
zygawhat would you like to do?19:29
jdstrandme fears about 'ix' in the home interface have thus come true19:30
jdstrandmy*19:30
zygaI see19:30
zygawell, we _could_ fix that19:30
zygathe specification could gain a query API19:30
zygalike spec.IsTypeConnected("home")19:30
zygait's not hard to add in our model now19:30
jdstranddocker-support will need a change-profile unsafe... rule, but docker snaps have home connected. the combination causes a parser error19:31
jdstrandso I need to strip out the 'ix' there19:31
pedronismmh19:31
pedronisthat is not a simple problem19:32
pedroniswe don't connect interfaces as groups19:32
pedronisthey come one by one19:32
pedronisso we would need to deal with both directions19:32
jdstrandfor this, I really only need to know if docker-support is plugged at all19:32
pedronisit can get connected later19:33
jdstrandbecause in practice, anything using that will have it connected (it is a super privileged interface)19:33
pedronisjdstrand: you don't know if they will be connected in a given order19:33
pedronisor the other19:33
jdstrandso in practice it will always be connected. and I only need this for the docker-support interface19:33
jdstrandpedronis: that's is what I'm saying. for this very specific case, I don't actually care about connection order because in practice, in the real world, if docker-support is in plugs, it will be connected, because of the nature of how we grant snap declarations for it19:34
pedronisjdstrand: I'm not understanding, it sounds fragile or I'm missing something19:35
jdstrandpedronis: so, to unblock the k8s work, I only really need in the home interface to know if docker-support is plugged, not connected. if it is, we just assume it is connected and drop the ix19:35
jdstrandpedronis: it isn't fragile, it makes a simple assumption19:35
zygapedronis: that's fine, I think, because if it is connected later the same method will be called (to compute the policy) and we can just do the right thing19:35
zygapedronis: it doesn't have to check both ways, it can just check the current state19:36
jdstrandin the home interface, behave like normal in all cases unless docker-support happens to be plugged. then drop some ix rules19:36
pedroniswhat does plugged mean?19:36
jdstrandand by plugged, I do *not* mean connected19:36
pedronisthat the snap has a plug?19:36
jdstrandwhether it is connected or not, you don't get ix if your snap plugs docker-support with home19:36
jdstrandplugs:19:36
jdstrand  home: null19:37
jdstrand  docker-support: null19:37
jdstrandin this case *only*, home drops some ix rules19:37
pedronisI seee19:37
pedronisit's kind of a hack and a layering violation tough19:37
jdstrandyes19:37
jdstrandbut when we added the ix rule to the home interface, we added a potential apparmor conflict19:38
jdstrandthat conflict is here now, because docker-support must have a special rule to fix k8s. it didn't exist before19:39
jdstrandI warned about this btw19:39
zygapedronis: 593719:39
zygajdstrand: another idea19:39
mupPR snapd#5937 opened: snap: validate plug and slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/5937>19:39
zygajdstrand: you can fix this in compose19:39
jdstrandbut I couldn't forsee the use case that would cause the problem19:40
zygajdstrand: AddConditinalSnippet("...", func() { ... })19:40
zygathen at compose level we can decide19:40
zygasomething along those lines19:40
jdstrandzyga: oh, where is that?19:40
zygawe don't have that19:40
zygabut it is another thing we could add19:40
zygathen interfaces are still "easy"19:40
zygaand operate at their own layer19:40
zygabut the backend can do smarter things when combining snippets19:41
zygaright?19:41
zygait's a bit late so I won't jump at implementing that now but I think it is doable19:41
zyga(both this and exposing connections to the specification, technically, probably one is cleaner than the other)19:41
jdstrandzyga: well, I could probably do something right before the snippets are written out and do the equivalent of a sed. that would be pretty terrible though19:42
zygathat's deriveContent19:42
zygain apparmor/backend.go19:42
jdstrandyeah19:42
pedronisjdstrand: anyway ConnectedPlug has Snap so you should be able to get to the info19:42
jdstrandI think I will propose something with ConnectedPlug cause the logic would be simple, if a bit of a hack, and easier to remove once there was a proper solution19:43
zygahmmm19:44
zygajdstrand: can you tell me what you would do?19:44
jdstrandin the home interface:19:44
zygaI'm not sure connected plug and the info are enough tell you something is or is not connected19:44
zygaI hope I'm wrong though :)19:44
jdstranduse_ix = true19:44
zygammm19:44
jdstrandif docker-support in plugs:19:44
jdstrand   use_ix = false19:45
jdstrand...19:45
zygaah, regardless of connection status?19:45
jdstrandyes19:45
zygaah, that's doable easily19:45
zygago for it :)19:45
jdstrandright19:45
zygabut my suggestion is19:45
zygalook at interface type rather than the name19:45
zygaI'm sure you meant that19:45
zygabut just wanted to say that just in case :)19:45
zygaFriday evening and all that19:45
* jdstrand nods19:45
zygapedronis: I'll add a spread test for the validation later on, today I just want to see if this passes as-is19:46
zygaif any tests we have now have invalid plug and slot names by accident19:46
jdstrandthe above is 'wrong' cause technically use_ix is only false if docker-support is connected. but in practice you need an installation constraint for docker-support and so if we grant that you get auto-connect too19:46
jdstrandand, the type of snap that has docker-support is, well, docker, and it will fall over without it, so disconnecting is infeasible for a working snap19:47
jdstrandreally, we shouldn't have interface combinations that conflict with each other, but alas, we do19:47
pedroniszyga: wonder if we should validate the interface name in the slots and plugs19:47
pedronisas well19:47
zygaperhaps but that one is more or less harmless19:48
pedronisit it's invalid it will also be a non-existing interface so we will ignore it19:48
pedronisatm19:48
zygaand we do validate that at some stage against known interfaces19:48
zygawe said we would not reject unknown interfaces19:48
zygajust ignore them19:48
pedronisyes19:49
zygaso I think that's the best we can do19:49
zygawe _could_ validate the actual name but that's a small extra19:49
pedronisbut this is about malformed names, no unknown19:49
pedronisnot unknown19:49
zygaI mean, I don't oppose it, I think we already do at another level19:49
zygabut perhaps I'm wrong as with the initial validation19:49
zygabut all known names are not malformed :)19:49
zygaso if not known then we don't care19:49
zygastill, I see your point19:49
zygawe could just be more aggressive about invalid names in general19:50
pedroniszyga: I just think it would be more consistent, and given we are adding it for slots and plugs19:51
pedronisit would be a good idea19:51
pedronisinstead of adding it later19:51
pedronisagain19:51
zygayes19:51
zyga+119:51
zygapedronis: pushed19:57
zygapedronis, jdstrand ^ review on that appreciated20:00
zygawould love to see it in 2.36 for mvo20:00
pedroniszyga: +1 with a comment20:00
Pharaoh_Atemzyga: are we looking to have 2.36 soon?20:00
zygaI hope so20:00
zygapedronis: I saw, good point,20:00
Pharaoh_Atemalso...20:00
* Pharaoh_Atem pokes kyrofa20:00
jdstrandzyga: what pr?20:01
zygajdstrand: 593720:01
zyga`plug "plug" has invalid interface name "i--face"`20:02
zygaanyone wants to suggest better wording?20:03
pedronisinvalid inteface name "i--face" for plug "plug"20:04
pedronis?20:04
zyganicer, thanks20:06
zygapushed20:08
zygathanks pedronis, that's a very good find for Friday evening20:09
pedroniszyga: it's actually jdstrand that made me go dig into this, because he noticed that one could happily use numbers20:10
pedronisin those places (because of our type-directed YAML parsing of some things)20:10
pedronis1234 plug anyone20:10
zyga1337 plugs FTW20:12
* zyga clones ubuntu kernel and sees that only 12% managed to flow so far :/20:13
zygaI guess I'll be patching tomorrow20:13
zygahave a great night everyone!20:13
jdstrandbye zyga :)20:14
kyrofaHey there Pharaoh_Atem20:21
Pharaoh_Atemkyrofa: how are things coming along with snapcraft?20:21
kyrofaPharaoh_Atem, pretty good from my perspective, but it depends on what exactly you're looking for!20:23
Pharaoh_Atemwell, principally being able to reasonably use it to produce Fedora based snaps ;)20:25
kyrofaPharaoh_Atem, there are two things I can think of that will be needed. First of all, the way snapcraft will be supporting other bases is by way of VM images for the base, so a fedora one will be required. Second, snapcraft is still missing any sort of dnf backend20:27
kyrofaEither one of those could be tackled independently from the other20:30
Pharaoh_Atemkyrofa: the VM images thing is going to be a problem for running snapcraft in a koji build or something20:46
Pharaoh_Atemsince they'll be running in restricted nspawn containers20:46
kyrofaPharaoh_Atem, there is a "destructive" mode as well that will run on the host, but that will still require the dnf backend20:48
kyrofaIt also isn't quite as clean20:49
Pharaoh_Atemthat's fine20:49
Pharaoh_AtemKoji purges the container environments after use420:49
Pharaoh_Atem*use20:49
Pharaoh_Atemit's not stupid enough to reuse them20:49
kyrofaYeah similar to what we do20:49
Pharaoh_Atemthere are a few build systems that do reuse chroots, but they're irrelevant since no large distro uses them20:50
Pharaoh_Atemkyrofa: I tried to write a DNF backend a long time ago, but it was too hard :(20:50
kyrofaPharaoh_Atem, the only thing you might consider is, let's say we have a fedora VM image: how different will it be from koji?20:51
Pharaoh_Atemkyrofa: koji does a mock container setup20:51
Pharaoh_Atemthe main things are: no real devfs, no kernel access, etc.20:51
Pharaoh_Atemand in the case of Fedora's Koji instance, no internet access20:51
cjwatsonSounds familiar, though we use throwaway VMs rather than containers.  Sounds like koji might in fact be an even more restrictive environment than Launchpad in some ways from the POV of snapcraft20:53
kyrofaIndeed20:53
kyrofaPharaoh_Atem, sounds like this is all moot without dnf support though, which isn't really on our immediate roadmap20:53
Pharaoh_Atemcjwatson: SUSE's OBS is equally restrictive, though they default to VMs20:54
cjwatsonYeah, I'm surprised Fedora doesn't in fact20:54
Pharaoh_Atem(they support LXC containers as a fallback)20:54
cjwatsonMaybe they have fewer untrusted builds20:54
Pharaoh_Atemcjwatson: Fedora COPR (where our PPA-like infra is) uses VMs20:55
cjwatsonRight, makes sense20:55
Pharaoh_Atemsince Koji is used _exclusively_ for distro packages, containers work fine20:55
cjwatsonWe deliberately share infra between the two uses because it gives us better density20:55
Pharaoh_Atemif the two systems were to merge (as I hope they will eventually), it'll probably be build VMs20:55
Pharaoh_Atemkyrofa: if I could get some help from you, I'd like to look at getting snapcraft a DNF backend soon20:58
Pharaoh_Atemtoday, every major RPM based distro (and some minor ones) have DNF in a functional state so that their distro repos can be managed with it20:59
Pharaoh_Atemeven Yocto derivatives that use RPM (like Wind River Linux) use DNF now20:59
kyrofaPharaoh_Atem, sure thing. Not sure what your schedule is like, but mine will be a little more open after 18.10 ships21:00
Pharaoh_Atemthat's probably a reasonable window for me too21:00
kyrofaGood deal21:00
Pharaoh_AtemI did this a while ago, but obviously didnt' get far: https://github.com/Conan-Kudo/snapcraft/blob/repo_rpm/snapcraft/internal/repo/_rpm.py21:01
mupPR snapd#5937 closed: snap: validate plug and slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5937>21:25
mupPR snapd#5921 closed: spread-shellcheck: use threads to parallelise <Simple 😃> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5921>21:26
mupPR snapd#5936 closed: Revert "spread: put openSUSE to manual" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5936>21:26
mupPR snapd#5938 opened: [test] Tweak cla checker <Created by chipaca> <https://github.com/snapcore/snapd/pull/5938>23:04

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