/srv/irclogs.ubuntu.com/2018/11/09/#snappy.txt

mwhudsonhey i broke snapcraft https://launchpadlibrarian.net/396538792/buildlog_snap_ubuntu_xenial_ppc64el_go-tip_BUILDING.txt.gz01:09
mupPR snapd#6121 opened: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>01:20
mupIssue core18#89 opened: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>01:49
mborzeckimorning06:14
mborzeckibrb06:19
zygaGood morning06:43
zygamwhudson: hello06:43
mborzeckizyga: hey06:43
zygaQuick question sir: what is the Debin policy for golang builds. That is, what more is needed in top of vanilla go build to do what packaging macros do06:44
mwhudsonzyga: i don't understand the question06:45
mwhudsonzyga: but basically you have a bunch of golang-*-dev packages for your build depends06:45
zygaFor example: in openSUSE to be compliant you need to pass -buildmode=pie to “go build”06:46
zygaIs there something like that in Debian?06:47
mwhudsonah06:59
mwhudsonno06:59
mwhudsonyou can, you can override dh_auto_build to run dh_auto_build -- -buildmode=pie or whatever06:59
mwhudson(if you particularly hate i386 users...)07:00
mwhudsonzyga: you should probably join #debian-golang on oftc07:00
zyga I should, yes07:01
zygaI have a deeper interest but I’m tired and wanted to have a slow morning today07:01
zygaSo still AFK07:02
zygaGood morning mvo07:14
mborzeckimvo: hey07:23
mvohey zyga and mborzecki07:34
mvozyga: 6118 contains the fix for snap-confine we dicussed yesterday07:34
zygaHey07:40
=== pstolowski|afk is now known as pstolowski
pstolowskimorning08:07
mvogood morning pstolowski08:10
zygamvo: I’m still afk, doing a slow start today08:12
zygaSorry about that08:12
mvozyga: now worries, still waiting for travis in any case08:14
pstolowskitrivial https://github.com/snapcore/snapd/pull/6117 needs 2nd review08:17
mupPR #6117: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6117>08:17
ackkmvo, hi, I run in another issue yesterday with core18 only installed: https://github.com/snapcore/core18/issues/8908:22
mvoackk: thanks, looking08:23
mupPR snapd#6120 closed: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6120>08:27
mborzecki#6065 needs a 2nd review08:29
mupPR #6065: cmd: make coreSupportsReExec faster <Created by chipaca> <https://github.com/snapcore/snapd/pull/6065>08:29
mvomborzecki: I have a look, sorry this was on my list but slipped08:35
mborzeckipedronis: hi, did you happen to git push to the wrong remote by accident? origin/pedronis-localInstallCleanup-doc08:35
mupPR snapd#6117 closed: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6117>08:36
mvomborzecki: I'm looking at 6039 and the error tweak there right now - or is that something you are already doing?08:50
mborzeckimvo: yeah, just started08:52
mborzeckimvo: do you want to look into this or shuld i?08:52
mvomborzecki: its fine, just go ahead, I will do more reviews then09:00
mupPR snapd#6065 closed: cmd: make coreSupportsReExec faster <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6065>09:06
mvopedronis: is 6070 something you want to look at (at a high level) or can I just go ahead and merge?09:07
mvozyga: do you know the status of 5696?09:17
threshis snap store dead again?09:21
mborzeckimvo: it needs a 2nd review09:21
threshThe Snap Store encountered an error while processing your request: internal server error (code 500).09:21
pedronismborzecki: hi,  do we have spread tests about refreshing parallel installed snaps through the store?09:23
mupPR snapd#6119 closed: sanity, release, cmd/snap: refuse to try to do things on WSL <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6119>09:23
pedronismborzecki: no,  I used direct editing in github, I will remove the branch now that is merged09:23
mborzeckipedronis: no, i don't think we have any, we have tests for install but not for refresh, i can look into adding one09:25
pedronismborzecki: yes, I think we should have some09:25
pedronisthank you09:25
pedronismvo: can you give me a bit more context about 6070 ?09:26
pedronisand hi09:26
mvopedronis: sure, let me update this09:26
mvopedronis: context in the PR description I assume?09:27
pedronismvo: what's the coverage like of those function in store?09:29
mvopedronis: the coverage change with this PR you mean? I checked that the bits that get mocked are also tested inside store but let me run the percentages09:30
=== alan_g is now known as alan_g_
zygamvo: good for merge AFAIK09:41
pstolowskipedronis: could this land https://github.com/snapcore/snapd/pull/6072 ? got 2 reviews and is probably uncontroversial as it's touching  the udevmon bits10:02
mupPR #6072: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6072>10:02
pedronispstolowski: yes, seems fine in itself10:05
pstolowskithanks10:06
mborzeckimvo: pedronis: i've updated 6039 with new error kind10:08
mborzeckizyga: can you take a look at #5696 and +1 it if it looks ok for you?10:09
mupPR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>10:09
pedronismborzecki: would try to get a review from John first10:09
mborzeckipedronis: ok10:10
pedronisI requested one there10:10
pedronisI will look after him10:10
pedroniszyga: are you blocked by 6116, or can you go forward and just deal with tweaks down the line?10:11
pedronisanyway I see there are comments there10:12
mvopedronis: I updated 6070 with pointers to the tests and a bit more motivation, I hope this is what you asked for, if I misread, please let me know10:17
zygapedronis: I can move forward10:19
pedroniszyga: thx10:19
pedronismvo: ah, you added a test as well10:19
threshis there any way to use JVM inside a snap, without providing the JVM itself?  Like a plug, maybe?10:20
mvopedronis: yeah, one was missing actually, not a super critical one but it was missing :)10:20
threshI don't really want to ship JVM as a part of VLC snap, but in case of Blu-Ray discs (which have Java-based menus) it can be useful10:21
mvozyga: 6118 is ready for review, tests are green except a curl 51 error on opensuse :/10:22
pedronisthresh: theoretically there should be a way to have a content snaps for this, like we do for gnome library, the question is how to coordinate/mantain this, maybe something to discuss with advocacy/snapcrafters10:22
pedronisthresh: sounds a fine forum discussion10:23
zygaUh10:24
pedroniszyga: ?10:24
pedronismvo: btw have we broken the coverage reports, I don't see them in recent green PRs10:25
pedronis?10:25
mupPR snapd#6122 opened: Tests core18 base configure 2.36 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6122>10:26
zygaI mean the 51 error on suse10:26
zygaarchive woes10:26
mvopedronis: yeah, I haven't seen them either, let me look10:26
* zyga works on some reviews now10:26
zygasorry for starting late and everyone10:27
mvopedronis: I can't install codecov for snapcore/snapd - only an admin can do this, so looks like we need to ask Gustavo10:31
pedronismvo: why do we need to install it? did github change something so that we need to install it again?10:32
mvopedronis: I don't know, I don't see it in the installed services or the installed github apps anymore10:32
pedronisI see10:32
mvopedronis: I don't know why it went away :/ I will dig a bit more but not sure I have enough prems to do much10:32
pedronismvo: no, that's fine10:33
pedronissounds like we need niemeyer10:33
pedronisand as we know a general question about getting more people with the perms10:33
pedronisyour and/or me10:33
mvopedronis: yeah10:36
* pedronis dives back into reviews10:38
kyrofacjwatson, I want to thank you for your email, and let you know that we're at the snapcraft summit this week with very little brain space for anything else, but will get back to you next week if that's alright10:44
tomwardillkyrofa: colin is off today10:47
kyrofatomwardill, well then, that works out10:49
mvoa review for https://github.com/snapcore/core18/pull/83 would be great10:57
mupPR core18#83: add swapfile support (ported from ubuntu-core-config) <Created by mvo5> <https://github.com/snapcore/core18/pull/83>10:57
mupPR core18#84 closed: hooks: port classic mode generation to UC18 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/84>11:00
mvoand https://github.com/snapcore/core18/pull/88 :)11:00
mupPR core18#88: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <https://github.com/snapcore/core18/pull/88>11:00
zygamvo: do you need https://github.com/snapcore/snapd/pull/6118 squashed?11:01
mupPR #6118: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6118>11:01
mborzecki#5897 should be ready for landing once jdstrand approves it11:01
mupPR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>11:01
mupPR snapd#6118 closed: tests: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6118>11:01
zygamvo: I'd like to squash merge and add https://github.com/snapcore/snapd/pull/5696 to 2.36.1, what do you think?11:10
mupPR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5696>11:10
Chipacamvo: I only get grey reviews in core1811:10
mvoChipaca: thanks11:12
mvoChipaca: I think we need to talk to foundations why this is11:12
mupPR snapd#5696 closed: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>11:15
mvoChipaca: thanks for the reviews! while you are here,  any idea about https://github.com/snapcore/core18/issues/8911:16
mborzeckizyga: 5696 squash merged as requested ;)11:16
zygathanky you! :)11:16
Chipacamvo: I'll take a look11:17
mupPR snapcraft#2400 closed: tests: fix maven spread test <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2400>11:17
mupPR snapcraft#2401 closed: ci: reduce spread system declarations <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2401>11:20
Chipacamvo: yes a few11:23
Chipacamvo: ideas i mean11:23
Chipacamvo: core18 doesn't have the completer bits. I presume they're in the snapd snap11:24
Chipacamvo: but core18 also does not have bash completion itself11:25
mvoChipaca: oh, interessting - /usr/lib/snapd, right? that should be available via the host (deb package)11:25
Chipacamvo: it's got all the completers, but not the completion11:25
zygapstolowski: updated https://github.com/snapcore/snapd/pull/6116 :)11:25
zygaI used a slightly different function name11:25
mupPR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116>11:25
mvoChipaca: aha! so just a misisng package in there?11:25
Chipacamvo: perhaps11:25
mvoChipaca: that should be easy to fix :)11:25
pstolowskizyga: thanks! will take a look in a moment11:26
zygathank you11:26
Chipacamvo: yes it looks like it's missing the bash-completion package11:27
Chipacamvo: should  that be from core, or in snapd itself? dunno11:27
mvoniemeyer: when is a good time for you to chat about the dotfiles/files/sensitive-files naming? should we have a quick HO with pedronis  maybe later today about it? or early next week?11:27
niemeyermvo: Heya11:28
Chipacamvo: probably from core as it's used in the context of the snap-provided completer, i.e. with the base11:28
niemeyermvo: I can do it now11:28
mvoChipaca: making that part of core18 seems ok, no?11:28
Chipacamvo: sitll digging to see if this would be enough though11:28
Chipacamvo: i think so yes11:28
niemeyerJust let me grab my power cable so laptop doesn't run off in the middle11:28
Chipacamvo: 'snap run --shell' doesn't work :-(11:29
pedronisniemeyer: mvo: I can do it if it doesn't drag too long (almost lunch), otherwise we will need a follow up11:30
mvoChipaca: ta, let me know if you need help but hopefully the PR against core18 is trivial11:30
niemeyerpedronis: Yeah, same here11:30
mvosame here11:31
mvoI'm in the standup HO, ready when you are11:31
zygahey niemeyer :)11:32
Chipacamvo: CompleteSh = filepath.Join(SnapMountDir, "core/current/usr/lib/snapd/complete.sh")11:36
Chipacamvo: so not just a core fix, needs a snapd change11:37
mvoChipaca: :/ ta11:38
Chipaca!osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompletersDir)11:38
Chipacahmmm11:38
* Chipaca wonders how many non-existent writable things exist out there11:39
zygamvo: what we discussed last night https://github.com/snapcore/snapd/pull/612311:53
mupPR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>11:53
mupPR snapd#6123 opened: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>11:53
* zyga -> quick lunch break11:53
mvozyga: ta, I check after lunch12:03
mupPR snapd#6124 opened: tests: simple reproducer for snap try and hooks bug <Created by stolowski> <https://github.com/snapcore/snapd/pull/6124>12:19
cachiomvo, pedronis hey, I need to go to make a study now12:29
cachioI'll try to by for the stand up12:29
cachioperhaps a bit late12:29
* cachio afk12:30
pedroniszyga: on a system with snapd snap we add implicit slots to it, right?12:40
pedronispstolowski: ensureSystemSnapIsPresent seems to have the wrong implementation now ^, also the name should probably have "is" or nothing, "ensure" sounds like it will install it if it's not there12:43
pstolowskipedronis: wrong because of CoreInfo implementation?12:46
pedronispstolowski: yes12:47
pedronisit doesn't account for when snapd is used for that12:47
pedronispstolowski: I suppose zyga can remind us what's the best way to get that info12:48
pedronisseems we need a bit more help from mapper12:51
pedronisactually12:51
pstolowskipedronis: we may need to revisit repo code and its guessSystemSnap(), there is some fuzzyness there12:52
pedronismaybe, not sure it's related12:52
pedronisthis code I'm talking about is all in ifacestate12:53
pedronisatm12:53
pedronispstolowski: will we rerun the interface hooks when a hotplug slot that was gone reappers?13:00
pstolowskipedronis: yes. and we will run disconnect hooks when you unplug13:02
pedronispstolowski: should we clear the dynamic attributes of gone connections then?13:03
pedronispstolowski: for context, I'm looking at the byHotplug case in doDisconnect13:03
pstolowskipedronis: we probably could. are you thinking about just optimization or something more?13:04
pedronispstolowski: will we end up using them by mistake when we reconnect?13:04
pedronisthat's more my question, not worried about opt13:05
zygapedronis: I updated https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394/3 - let me know if that answers your questions13:08
pstolowskipedronis: looking at the code, in Connect we start off with empty dynamic attributes, so this should not happen13:08
zygaUnless you disagree I want to work on a fix for this issue now, that would limit re-packaging to just snap-exec, outside of 16.04 world13:08
zygaalternatively I can work on snap-confine and work with mvo on this in the evening13:09
pedroniszyga: I need to re-read the forum post first, I think you should continue on user namespaces until I understand more13:09
zygaok13:10
pedronispstolowski: ok, I think it would be marginally cleaner/safer to reset them but can be done in any PR, not urgent13:10
zygapedronis: the only impact now is testing recent distributions13:10
pstolowskipedronis: allright13:10
zygapedronis: it is not a problem in actual production use13:10
zyga(even in future distributions)13:10
pedroniszyga: yea, that's why I don't think you should jump on it13:10
zygaok13:10
zygamvo: 6122 approved13:11
zygadid you say 2.36.1?13:11
pstolowskipedronis: shall i look at printing a warning on snap try & hooks, or do we want to think about it some more?13:12
pedronispstolowski: no, you should look, likely with a bit of input from zyga how to fix ensureSystemSnapIsPresent, unless you have already something else13:13
pedronisI fear adding that warning is messy13:13
pstolowskipedronis: ok13:16
pedronispstolowski: btw, if it wasn't clear, I'm still absorbing the already landed hotplug code atm13:17
pstolowskipedronis: yes, yes, it was clear13:17
pstolowskipedronis: thanks13:18
mupPR snapd#6122 closed: tests,snap-confine: add core18 only hooks test and fix running core18 only on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6122>13:32
zygaheh13:40
zygaI just realised we need facts for one more reason13:40
zygawe need to know the PATH to set13:40
zygafedora29 cannot use ubuntu PATH13:40
pedroniszyga: I re-read the forum topic, there is definitely more to clarify before it can be acted on, I can write more there and/or we can chat on it next week13:50
zygapedronis: thank you, I think if you write some more questions or concerns we can think about them and then have a call next week13:52
zyganote, I just talked to pawel about monday13:52
zygaour government decided to make Monday a holiday just now13:53
zygaso I will (or should be) off13:53
pedroniszyga: one first question, do we run our tests mostly with reexec on all distros? even if they default to not reexec13:53
zygait's not reexec13:53
zygait's re-packaging of core that breaks this13:54
zygawe run with native setting of reexec13:54
zygaso enabled where it works13:54
pedroniszyga: ok, but some of your proposal don't make in the non reexec case13:54
pedronismake sense13:54
zygathere are two proposal: solution and workaround13:55
pedronisno there are many bits13:55
zygasolution is to build snapd with ubuntu 16.04 toolchain and re-package core with that build results13:55
mupPR snapd#6125 opened: release: 2.36.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6125>13:55
pedronisno, you propose to change some bind mounting too13:55
zygathe workaround is to stop repackaging with the special exception of snap-exec13:55
zygabecause snap-exec is safe13:55
pedronisthat doesn't make sense in general13:55
zygaindeed, sorry, that is a special case of what we do today on core18 snaps13:55
zygawe cannot use the host package as source for certain binaries13:56
zygawe must bind mount from snapd.snap13:56
pedronisif we don't reexec13:56
pedronisor depending on which binary13:56
zygayes, even if we don't reexec13:56
pedronisit's complicatted13:56
zygaI mean when we run a core18 snap app,13:56
zyga(I agree)13:56
pedronisanyway it's not ready to be worked on13:56
zygawe _may_ in some cases use host binaries with ill effects13:56
pedronisI'll write some this in the post later13:56
zygathank you!13:56
zygait's super complicated because of many possible interactions13:57
zygaI think in general the solution case is easy, it would just cost test time to build snapd twice13:57
zygaand it matches reality in non-test useage13:57
zygathere are certainly some tweaks to do for core18 and fedora29 based snaps13:57
zygabut those are nearly not as broken as the repackaging today13:57
mupPR snapd#6116 closed: cmd/libsnap: add simplified feature flag checker <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6116>14:03
ogramvo, so when you install an app on UC18 today ... it is very likely that this app pulls in core16 (simply since we only have very few UC18 core apps yet) ... once the apps switch to core 18, do we have some automation to remove the core16 snap automatically once nothing depends o it anymore ?14:06
ograif not ... could we add that ?14:07
mborzeckimvo: can you publish the files to github release page?14:09
zygamvo: yes please, I'll release 2.36.1 for suse too14:10
mvomborzecki: yes, will do so in a little bit14:10
mupPR snapd#6072 closed: ifacestate/udevmonitor: added callback to signal end of enumeration <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6072>14:11
mvoogra: we have no auto-cleanup of unused bases yet but its planned14:12
ogragood14:13
ackkogra, there are also a few issues currenty if you don't have "core" installed14:13
ograit just struck me that 3xcore16 on disk will easily eat 200-300MB14:13
ografor devices with 4GB MMC (which we have a lot) thats quite a lot14:13
zygaogra: we may save a lot soon14:25
zygaI'll tell you more after the standup14:26
ograinteresting14:26
zygare14:38
zygaogra: golang can now strip correctly14:38
zygatl;dr14:38
zygawe can investigate14:38
ograzyga, that doesnt help much with the core snap size i fear14:39
zygaogra: it's way bigger because of snapd14:39
zygaanyway14:39
zygapstolowski: let's chat in an hour or two14:39
zygaI need to get home14:39
ogra(i dont think there is a single go binary in it apart from snapd)14:39
pstolowskizyga: sounds good, i need (late) lunch14:39
Chipacaogra: also there's a config to only keep 2x instead of 3x14:40
ogra\o/14:42
ograthat was about time !!!14:42
ograawesome !14:42
Chipacaogra: there since 2.3414:44
Chipacaogra: https://github.com/snapcore/snapd/pull/520714:44
mupPR #5207: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5207>14:44
ograyou guy need a promotion agent !!! such features deserve way more noise ... even TV ads for thi particular one ;)14:45
ogra*guy14:45
ogra*guys14:45
ograbah14:45
Chipacaogra: and you need a keyboard with two S keys in a hot-hot configuration14:45
ograyeah ... i'm so sad this KBD *again* only lasted 1y ... i really like it14:46
ografunnily usually the vowels break ... this is the firsst time i killed an S14:46
Chipacafun fact: snap.BaseDir() is not the directory of the base of a snap14:57
pstolowski:)14:58
=== alan_g is now known as alan_g_
* cachio lunch14:59
jdstrandmborzecki: hi, fyi, I approved PR 5897, but please fix the two typos before merging15:10
mupPR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>15:10
mborzeckijdstrand: thanks for the review, i'll look into it in a while15:10
jdstrandmborzecki: thanks!15:11
Chipacamvo: let me know when you have 5-10' to go over /usr/lib/snapd/* wrt bases15:17
mvoChipaca: in a meeting right now15:17
Chipacamvo: yea15:17
Chipacamvo: you have all the fun, i know15:17
mvoChipaca: we bind mount this ususally, either from the host or from the snapd snap15:17
mvoChipaca: yeah, envy me!15:18
mvoackk: the fix for the issue you reported about core18 onyl on classic went into 2.36 we will sru this either today or early monday15:47
mvocachio: everything except i386 is ready for beta validation15:51
ackkmvo, \o/ thanks15:52
mvothank *you* for reporting and the reproducer!15:55
mvocachio: i386 is now also ready for beta validation15:58
ograppisati, oh my ... bug 1802320 sounds like you had a really painful time just for some blinking15:59
mupBug #1802320: rpi3bp+: ethernet leds don't blink <patch> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1802320>15:59
ppisatiogra: yep, actually fixing the leds made the ethernet controller die16:01
ppisatiogra: but in the end it was fun16:01
ograheh16:01
kenvandinewhat provides location-observe?16:08
kenvandinesudo snap connect gnome-clocks:location-observe16:09
kenvandineerror: snap "core" has no "location-observe" interface slots16:09
pedroniskenvandine: afaik only the locationd snap provides that16:10
pedronisbut I don't have enough context to say what that is, or what we should do instead16:11
pedronissorry, s/what that is/why that is/16:11
zygaFinally home16:12
zygaTea and work16:13
zygaMaybe coffee instead16:16
pedroniszyga: I wrote a bit more in that forum post, it's a bit rambly I fear, I don't think it yet capture the problem in a way that one can tell yes, this is the problem. Also I'm confused if we have related bugs outside of tests, I suppose not, but reading your comment it sounds like we do16:17
pedroniszyga: either way, not urgent to answer, do it when you feel good/rested16:18
pedronis*it's a bit rambly, it there is my own answer16:20
pedronispstolowski: in case I finish going through the preexisting code, can you tell me where I should start the important reviews for hotplug?16:21
pstolowskipedronis: sure, let me take a look16:21
kenvandinepedronis: thanks16:26
cachiomvo, running16:28
pstolowskipedronis: i suggest the simple #6082 first; then three PRs closely related to each other: #6069, #6114, #610016:29
mupPR #6082: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6082>16:29
mupPR #6069: ifacestate/hotplug: removeDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6069>16:29
mupPR #6114: overlord/ifacestate: handler for hotplug-disconnect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114>16:29
mupPR #6100: overlord/ifacestate: hotplug-remove-slot task handler <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6100>16:29
pedronispstolowski: thx, I'll see how far I get on monday16:31
cachiozyga, do you have the link for this python utility16:38
cachio?16:38
dot-tobiasIs launchpad currently unavailable? Estimated build time for my snaps is 5+ hours, and is still at 5h after 2h wait.16:40
ogradot-tobias, https://launchpad.net/builders is always a good place to check16:41
mupPR snapd#6126 opened: dirs, wrappers, overlord/snapstate: make completion + bases work <Created by chipaca> <https://github.com/snapcore/snapd/pull/6126>16:45
dot-tobiasogra: thanks!16:45
zygacachio: yes, one sec16:58
zygapedronis: offtopic, https://github.com/snapcore/snapweb is pinned if you go to GitHub.com/snapcore/ perhaps we should unpin it as it's not really maintained16:59
zygacachio: this is here https://github.com/snapcore/core-build/tree/master/initramfs/testing17:00
zygacachio: I think it's not useful as-is for you directly17:00
zygacachio: but it should be not too hard to extract a little bit out17:00
zygacachio: that can drive kvm and do the snapshot / restore17:00
kenvandinemvo: i just learned there's a "bare" snap.  Would it make sense for a content snap like gtk-common-themes to use base: bare?17:00
zygakenvandine: hey17:01
kenvandinehey zyga17:01
zygakenvandine: content snaps don't provide apps17:01
zygakenvandine: I don't think it needs to be using the bare base17:01
kenvandineoh, so if no app is defined it won't care?17:01
zygaprecisely17:01
kenvandinegreat17:01
zygabases are the roots for running stuff17:02
zyganothing to run, nothing to care about :)17:02
kenvandineawesome17:02
cachiozyga, tx17:03
Chipacaum17:04
Chipacawell17:04
Chipacazyga: if it doesn't say base: <something>, we'll dutifully install core for it17:04
zygaChipaca: we should change thta17:04
zygaChipaca: so that no apps == no base needed, no prerequisites17:05
Chipacajust confirmed, 'snap install gtk-common-themes' pulls in core17:05
zygafun17:06
zygaI'll file a bug17:06
Chipacakenvandine: can you think of a core18-based snap that uses gtk-common-themes?17:06
Chipacai notice gimp doesn't17:06
kenvandineChipaca: yes, several17:06
kenvandineevince17:07
kenvandinegnome-chess17:07
kenvandinegnome-clocks in candidate17:07
Chipacahm17:07
Chipacathat's interesting, maybe the check is smarter now17:07
* Chipaca wonders17:07
kenvandineChipaca: i'm in the process moving all the gnome snaps to core18/gnome-3-28-180417:08
Chipacaah,no, there we go17:08
Chipacait got 'core' as well17:08
kenvandinenot moving the seeded snaps just yet though :)17:08
Chipacazyga: on a bare system (no snaps at all), snap install gimp -> you get core18 and gimp; snap install evince -> you get fun17:08
Chipacacore, core18, evince, gnome-2-28-potato, gtk-common-themes17:08
pedroniszyga: Chipaca: we cannot change what no base means,  we might need a way to express no base tough17:10
kenvandinebase: none ?17:11
kenvandinefor gtk-common-themes17:11
pedronisthat will try to find a snap called none atm17:12
zygaChipaca: https://bugs.launchpad.net/snapd/+bug/180254117:12
mupBug #1802541: Installing a snap without any apps or hooks should depend on the base snap <snapd:New> <https://launchpad.net/bugs/1802541>17:12
zygapedronis: I think we could just be smart about what prerequisites to pull17:12
zygapedronis: but we'd have to see the snap.info of a snap from the store17:12
zygaincluding apps/hooks17:12
Chipacazyga: i think you a not17:13
pedroniszyga: maybe17:13
Chipacazyga: note we aready get the raw yaml to look at content interface thinigs17:13
Chipacathings17:13
zyga ah, I didn't know that17:14
zygawe may also need to know if hooks exist17:14
zygaeven if undeclared in yaml17:14
zygait would be nice if snapcraft created full hook defs17:14
pedronisthat is a bit balooning17:14
Chipacazyga: i edited the description to include a 'not', and changed the wording a bit17:14
pedronisanyway good that is captured in a bug17:14
Chipacazyga: "even if undeclared in yaml", when are they declared?17:15
zygaChipaca: when they need interfaces17:16
zygathey _can_ be declared17:16
zygait would be neat if store knew17:16
zygayep17:16
zygacachio: about that python kvm thing, you can clone the repo and run it locally17:17
kenvandinezyga: thanks for the bug report, that was exactly the issue i was concerned with17:17
zygacachio: the main idea is that you can just talk to kvm to make a super fast snapshot17:17
zygaand restore it17:17
zygain the project I linked to it is used to drive tests17:17
zygathat run on the inside17:17
zygathe whole VM is reverted before each test17:17
zygaso it's always 100% pristine17:18
zygasince it is written for testing initramfs it is a bit specific in how it operats17:18
zyga(tests are written in python and are defined on the host, are transformed to shell and run in the initrd in the guest)17:18
zygabut that's all orthogonal to the main idea of snapshots17:18
zygaI mainly mentioned it because it is extremely fast17:18
zygathat test def setup ran >>10 tests in pristine VM per_second_ on my old laptop17:19
mupPR snapd#6125 closed: release: 2.36.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6125>17:20
mvohm, 6039 needs a second review17:21
zygalooking17:21
mvozyga: you reviewed it already17:21
mvo:)17:21
zygaah :/17:21
=== pstolowski is now known as pstolowski|afk
pedronismvo: Chipaca should look at it17:28
pedronis#603917:28
mupPR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>17:28
cachiozyga, it is pretty nice17:31
cachioit is using the snapshot features provided by qemu17:31
cachiozyga, it also set the qemu monitor17:32
cachioand uses it to save/restore the vm17:33
cachiothis it nice17:33
pedronisChipaca: zyga: I wrote something in the bug about the challengens17:37
zygapedronis: thanks, I replied17:50
zygaI think it's not a high priority problem17:50
zygabut we should take it into account if we change how installation works17:50
mborzeckizyga: fyi, gpg 2.2.10 is in arch too, but the test that fails in TW does not seem to fail there18:10
zygaisn't it disabled there?18:10
zygaif not then that is indeed curious18:11
zygasomething else is at play18:11
zygabut that's also reassuring :)18:11
mborzeckiheh, let me check18:11
zygamborzecki: would you be interested in looking at the makefile in https://github.com/snapcore/snapd/pull/611118:11
mborzeckizyga: it's not18:11
zygaI think it would (or might be) good fit for arch18:11
mupPR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>18:11
mborzecki(not disabled)18:12
zygashould cut the boilerplate18:12
zygaand provide consistency18:12
zyga(ack)18:12
zygauh, 19:00 on Friday18:13
zygasorry about that :)18:13
zygawell, I'll get back to some coding I want to finish but I don't expect reviews at this time :)"18:13
mborzeckizyga: checked pacman log, gnupg update to 2.2.10 arrived on 05.09, so it's been a while18:14
mborzeckizyga: as for the PR, i looked briefly in the morning but didn't leave any comments, imo there should a way of overriding things like -buildmode, fedora does =pie, arch doesn't care and yocto does =shared by default18:15
zygayes18:16
zygathat's indigo18:16
mborzeckizyga: also LC_ALL=C.UTF-8 is non standard glibc extension18:16
zygathis is just temporary18:16
zygaall of the go build policy is handled by indigo18:16
zygaish -- I think we need something like that18:16
zygaI mean18:16
zygaLC_ALL=C won't pass tests18:16
zygawe need either a real locale18:16
zygaor C.UTF-818:16
pedroniszyga: about those gpg tests, have you tried what the test tries manually on a box, without expect etc in the way? that seems step one to understand if it's a test issue vs other18:17
pedronisI mean a box with the affected distro18:17
mborzeckizyga: or fix the culprit18:17
zygapedronis: partially, I only ran it in a test VM as I wasn't fully familiar with what that test was doing to keys, I can run it on my machine easily though18:18
zyga(I'm developing on tumbleweed for the last few weeks18:18
zygamborzecki: remember this was for release :)18:18
zygamborzecki: to fix it we just need to set environment in a bunch of tests18:19
pedronisChipaca: given that #6039 is introducing that error, maybe that fact that is not good is a blocker :)18:19
mborzeckizyga: heh, i see that now, * instead of ✓18:19
mupPR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>18:19
zygamborzecki: yes :)18:20
zygaChipaca: ^18:20
zygaChipaca: tests don't mock locale so they fail if you have unset LANG and stuff18:20
pedronisChipaca: this is 2.37 material, if you have suggestion for a better error, please suggest18:20
mborzeckiChipaca: pedronis: how about `classic confinment requested, but snap %q is not a classic confined snap` ?18:21
mborzeckithe original version by mvo was `classic confinment requested for a non classic confined snap', maybe a variant of this could work18:22
pedronismborzecki: I think Chipaca is suggesting that it's one of those longer messages, explaining a bit the concept as well18:23
pedronisI'm honestly a bit too tired right now to make a suggestion18:23
pedronislike the ones for SnapNeeds*18:23
pedronismaybe the error needs to carry the actual confinement to help produce a better error18:24
pedronismessage18:24
pedronisas well18:25
mupPR core-build#37 opened: Introduce recovery-mode for factory-reset <Created by slimjim777> <https://github.com/snapcore/core-build/pull/37>18:25
pedronismborzecki: Chipaca: I copied this convo in the PR18:27
Chipacapedronis: mborzecki: sorry i was afk18:28
* Chipaca looks at errors.go18:29
Chipacamborzecki: pedronis: i'm very tired so not sure this suggestion is any good, but something like "snap %q is not compatible with --classic" would spell out exactly what the user did wrong18:30
Chipacamy main complaint is that it doesn't tell the user what they did wrong, and doesn't tell them how to fix it18:30
Chipaca"wtf drop that --classic nonsense" would work too18:31
Chipacamborzecki: pedronis: let's all EOW and worry on Monday/Tuesday/whatever is the appropriate day next week18:31
mborzeckiack :)18:31
zyga2.36.1 in opensuse now18:39
zygamborzecki: is arch package up to date? :-) (wink wink)18:39
mborzeckihehe18:39
mborzeckinah, haven't pushed an update yet18:39
zygaI will push the snapd sync in a moment18:39
zygaor maybe not,18:40
zygait's trivial bump of two lines18:40
zygacan wait18:40
pedronisChipaca: it's fine, as I said it's not urgent to land afaict and I'm tired too18:41
pedronisChipaca: I pasted that into the PR in case18:45
* pedronis goes away18:45
zygao/18:45
pedronisttfn18:45
Chipacao/ eow here18:49

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