/srv/irclogs.ubuntu.com/2020/04/15/#snappy.txt

ijohnsonhey cmatsuoka what's up00:02
* ijohnson is mostly there he thinks00:02
cmatsuokahmm I forgot what I was going to say00:06
cmatsuokaanyway00:06
cmatsuokaI see many test failing because pi-kernel is not available, do you know what happened there?00:07
ijohnsoncmatsuoka: hmm could be store outage00:10
ijohnsoncmatsuoka: I can see the pi-kernel on my arm64 machine now00:10
cmatsuokaijohnson: could you try to download the snap?00:11
ijohnsonlet me try00:11
ijohnsoncmatsuoka: you need to specify a channel, there is no latest channel on the pi-kernel00:12
cmatsuokaah I see00:12
ijohnsonif you do `snap download pi-kernel --channel=20/edge` it works00:12
ijohnsonbut just `snap download pi-kernel` won't work00:12
cmatsuokabut did that change recently?00:13
ijohnsoncmatsuoka: hmm don't think so00:13
cmatsuokabecause some old tests started to fail00:14
ijohnsonhmm did you check the full snapd service logs?00:14
ijohnsonthe spread tests will always do verbose HTTP logging for when they talk to the store00:14
ijohnsonso you should see some 400s or 500s if the store was having a fit00:15
cmatsuokalet me see...00:15
cmatsuokaijohnson: https://github.com/snapcore/snapd/pull/8495/checks?check_run_id=58721996400:18
mupPR #8495: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <https://github.com/snapcore/snapd/pull/8495>00:18
cmatsuokaijohnson: maybe you can see something there that could tell us what's happening00:19
cmatsuokaoh it's in prepare-image00:20
ijohnsoncmatsuoka: yeah looks like store having a fit00:20
ijohnsonhttps://www.irccloud.com/pastebin/6ZKFXKKS/00:20
ijohnsonstore responded with 42900:20
mupPR snapcraft#3037 closed: plugins: introduce v2.CMakePlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3037>00:20
cmatsuokatoo many requests00:21
cmatsuokapft, ok00:21
cmatsuokado you know when it resets the request counter?00:22
ijohnsoncmatsuoka: just restart the test, it's usually temporary00:23
cmatsuokaok good, thanks, will do that00:24
ijohnsonnp00:24
mupPR snapcraft#3042 opened: repo: minor debug log tweaks <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3042>01:08
mupPR snapcraft#3034 closed: repo: add initialize_snapcraft_defaults() to set default source lists <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3034>01:47
mupPR snapcraft#3040 closed: V2 autotools plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3040>01:50
mupPR snapcraft#3042 closed: repo: minor debug log tweaks <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3042>02:17
jameshcjp256: I've updated PR 3031 to use a custom parameter type.  Let's see how that goes.03:31
mupPR #3031: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3031>03:31
mupPR snapd#8499 opened: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>04:05
mborzeckimorning05:53
zygaGood morning06:24
mvogood morning zyga06:24
zygaHow are you guys06:25
zygaHopefully today I will make progress on dbus06:25
mborzeckizyga: mvo: morning guys06:27
mborzeckihave you seen https://github.com/snapcore/snapd/pull/8496 ?06:27
mupPR #8496: interfaces/apparmor: use differently templated policy for non-core bases <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8496>06:27
mborzeckisupper happy this is moving forward06:28
mvogood morning mborzecki06:29
zygamborzecki: not yet06:36
zygabut we talked about this in Toronto06:36
pstolowskimorning07:01
zygahey pawel :)07:03
mborzeckipstolowski: hey07:05
mborzeckihhm trying to investigate the context deadline exceeded thing that happens in our tests randomly https://paste.ubuntu.com/p/zr6fNXMMbf/07:39
mborzeckibut looking at go stdlib side, the whole timeout detection in http.Client.do() looks quite brittle07:40
mborzeckiheh `time.Now().After(deadline)` heh if this is true then Client.do() returns httpError{timeout:true} otherwise it's urlError07:48
pedronismvo: hi07:59
mvopedronis: hi08:00
pedronismvo: #8489 is all green but of course the required things don't exist there, it needs reviews and you will have to land it manually I suppose08:00
mupPR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>08:00
pedronismborzecki: zyga:  ^ needs reviews08:02
zygamm08:03
mvopedronis: yeah, it does not have review, once it does I can land it manually and adjust the required things in the settings08:03
pedroniszyga: do you noticed/know why it seems we don't get the tooltip/panels with the detected error lines anymore?08:04
zygayeah, I noticed08:04
zygaI was looking at why just now when looking at this diff08:04
zygaI think            echo "::add-matcher::.github/spread-problem-matcher.json" needs to be in an earlier step08:05
zygaor there's a typo08:05
pedronisbut it happens  not only here08:05
pedronisalso weirdly enough the emails I get have the count08:05
zygahmm08:06
pedronismvo: could you land #8488, it failed on the store in one test,  it will unblock various other PRs08:08
mupPR #8488: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8488>08:08
mvopedronis: sure, will do08:10
mvopedronis: meh, I had no idea how annoying efi vars are :(08:13
mvopedronis: anyway, landed08:13
mupPR snapd#8488 closed: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8488>08:13
pedronismvo: thank you, I will pick up now Claudio's #846308:13
pedronisnow08:13
mupPR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>08:13
mvozyga,pedronis: re, looks like network is a bit unstable today, did I miss anything in the last 20min08:40
zygamvo: I'm doing a review of your actions patches08:41
zygamvo: hopefully nothing else08:41
pedronismvo: I updated #8463 if you want to double check my changes08:42
zygamvo: https://github.com/snapcore/snapd/pull/8489#pullrequestreview-39357058308:42
mupPR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>08:42
mupPR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>08:42
jameshAre updates to core20/edge held up for manual review?08:45
=== pedronis_ is now known as pedronis
=== pedronis_ is now known as pedronis
mupPR snapd#8498 closed: run-checks: use consistent "Checking ..." style messages <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8498>08:59
mborzeckiomg that github workflow PR, wish we didn't need to have this hack09:00
mvomborzecki: you mean the amount of duplicated code?09:00
mvomborzecki: that is very sad indeed09:01
mborzeckiand the full workflow name appears in the jobs list :/09:01
mborzeckiand it's controlled by repo level switches :/09:01
mborzeckiand it's all duplicated09:01
mborzeckimvo: a clever hack nonetheless ;)09:01
mborzeckifeels like gh actions are half baked atm09:03
mvomborzecki: yeah, I wish we had yaml ancors or anything really09:04
jameshrustup generates their workflows from parameterised source yaml files09:05
mborzeckijamesh: but it's done offline right?09:05
mborzeckior is there an action that does that? :)09:06
jameshmborzecki: yes.  The generated workflows need to be committed to git09:06
mborzeckiwe still need the dependency on the unit tests09:07
mborzecki(even if we were to split workflows per spread ssytem)09:07
zygamvo, mborzecki: jobs and steps can have a name and an ID09:08
zygawe can keep the ID as is but give it a shorter name09:09
zygabrb09:21
mupPR snapd#8500 opened: httputil: fix client timeout retry tests <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8500>09:31
mborzeckishoud help with random failure in httputil retry tests ^^09:31
mborzeckistill a mess, but nothing we can do, especially when sticking to older go versions09:31
mborzeckimvo: zyga: so a silly thought about gh actions, what if we just accept to run the unit tests more than once, and run it on the target system if possible (eg. via a docker container and whatnot) or a reasonmable default eg 18.0409:38
zygamborzecki: that's what mvo did, no?09:38
mborzeckizyga: i mean workflow per spread system09:38
zygayeah09:38
zygaas for running them only in spread09:38
zygaI disagree09:38
zygathat's somewhat slower and much more costly09:39
zygabut we can just try09:39
mvomborzecki: you suggest one workflow per spread system and each workflow would have the unit tests first?09:40
pedronisI think we should try to live with a setup for a bit, after mvo split lands, before making other changes09:40
zygayeah09:41
pedroniswe are really blocked at the moment by everything being red and and needing full re-run or mvo override09:41
zygaI would only make cosmetic tweaks (names) so that it's nicer on a PR page09:41
mvoor we land it and do cosmetic tweaks in the followup :)09:41
mvo?09:41
mvo(it still needs a +1)09:41
zygayes totally09:41
* zyga checks the comments09:42
mborzeckimvo: yes, the unit test could run in a docker container of the target system or some known default if there's none or just run the spread unit test job on the target system separately first09:42
pedronisthat seems it would slow down things09:43
pedronisanyway it all sounds more work than we can afford atm09:43
mborzeckithe downside it it'd obviously take longer, the upside is that unit tests would run on more systems where they happen o fail sometimes when mocking is lacking09:43
mborzeckibut you can also restart workflows :P09:44
mvomborzecki: we run the unit tests in spread on the target too (tests/unit/go)09:44
pedronisthis all sounds a discussion to have at the earliest in 3 weeks09:45
pedronistbh09:45
mvothe trade-off is unit tests first or the risk of spinning up 50 machines that all fail09:45
zygaFYI: I scaled down my deployment to 7 nodes (currently busy) to force some traffic onto canonistack instances09:48
zygaif something falls over I will scale back up09:48
mborzeckihmmm could we cache the job results somehow?09:48
zygahttps://github.com/snapcore/snapd/pull/8489#pullrequestreview-39362149109:49
mupPR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>09:49
zygamborzecki: yes09:49
mborzeckias in, cache the result of unit tests or individual spread tests09:49
zygamborzecki: we could09:49
zygamborzecki: that's actually pretty brilliant09:49
mborzeckiand then skip those jobs when workflow restarts?09:49
zygamborzecki: if sha matches and is green09:49
zygajust go ahead :)09:49
mvooh, that's interessting09:49
zygawe could use the cache action for that09:49
zygamvo: https://github.com/snapcore/snapd/pull/8489#pullrequestreview-39362149109:50
mupPR snapd#8489 closed: github: partition the github action workflows <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8489>09:52
zygamborzecki: can you merge master or rebase https://github.com/snapcore/snapd/pull/850009:52
mupPR #8500: httputil: fix client timeout retry tests <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8500>09:52
zygamborzecki: it will need the new checks to pass anyway09:52
zygamborzecki: and I want to use it as a guinea pig09:52
mborzeckihaha ok09:53
zygawith a bit of luck canonistack workers will now pick it up09:53
mborzeckihmm Error restoring google:ubuntu-18.04-64:tests/completion/ (apr150717-345956) : read tcp 10.113.57.178:48146->35.229.25.208:22: read: connection reset by peer09:55
mborzeckidid we run out of some quota on gce?09:56
zygano, probably my fault09:56
zygalet's wait for 20 minutes to see if the new setup works09:56
mupPR snapd#8494 closed: tests: preserve size for centos images on spread.yaml <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8494>09:57
zygamborzecki: we should figure out caching for "go test"09:59
zyga7 minutes of each run is there09:59
mupPR snapd#8495 closed: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8495>09:59
mborzeckiehh more of that `Error restoring google:ubuntu-20.04-64:tests/main/parallel-install-services (apr150717-996191) : read tcp 10.113.57.84:36100->34.74.8.8:22: read: connection reset by peer`10:00
zygawe are mow using canonistack as well as my "cloud"10:02
zyga6 workers but hopefully with way better network10:02
zygawe have enough memory and CPU load is low10:02
zygaand network is much faster actually10:03
mborzeckihmm https://github.com/snapcore/snapd/pull/8499 wat?10:20
mupPR #8499: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>10:20
zygahmmm?10:21
zygamborzecki: maybe he has a github repo10:22
zygawe can send a PR with a response10:22
zyga/ thank you for this comment10:22
mborzeckiit's probably some weird snap that produces lots of data in $SNAP_DATA or somesuch10:23
zygamborzecki: lol10:23
zygahe made a typo10:23
zygaso we didn't waste money "testing" that PR10:23
zygamvo: I guess that's one for you to handle10:23
zygamvo: https://github.com/snapcore/snapd/pull/849910:24
mupPR #8499: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>10:24
* mvo is in a meeting10:25
zygabrb10:36
mborzeckidamn, error: cannot download snap "pi-kernel": no snap revision available as specified10:57
mborzeckikeeps repating10:57
=== pedronis_ is now known as pedronis
mborzeckiweird, why it's using 20-pi3/edge while xnox's xnox-core-20-pi-arm64.model is using 20/edge11:00
mvomborzecki: yeah, I think the kernel team did something to "pi-kernel"11:00
pedronisI think 20-pi3 doesn't exist anymore11:00
mborzeckixnox: do you know whether we should be using 20/edge for pi kernels now?11:00
pedronisalso why are we 20 there ?11:00
pedroniswe using 20 there?11:00
mvooh, funny "pi-kernel" has no latest track anymore11:01
mvoso snap info pi-kernel gives no reply11:01
mborzeckipedronis: this is what we're using https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/developer1-pi-uc20.model.json11:01
pedronisI think that's broken now11:02
mborzeckiok, the official (?) model ubuntu-core-20-pi-arm64.model is using 20/stable, so 20/edge is ok right?11:03
pedronismborzecki: yes11:03
pedronisI think so11:03
xnoxmborzecki: please stop using that, and instead use canonical signed dangerous model that is now available from models repo & from assertions service.11:06
mupPR snapd#8501 opened: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8501>11:06
xnox20/edge is the way to go11:06
mborzeckixnox: thanks!11:07
pedronisthat's our own prepare-image tests11:07
ograxnox, a post on the forum would be really nice (where to find models etc) ... though probably post-release11:09
ograso our customers can start rolling their own core20 imgs11:09
xnoxogra:  no =) nobody shall find out anything about core20 ever.11:10
ograhaha11:10
* xnox giggles11:10
pedronismvo: for latest you need pi2-kernel I think, pi-kernel is 18/20 only afaict11:10
zygacachio: hey11:16
zygacachio: around? :)11:16
mupPR snapd#8502 opened: github: try caching test results <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8502>11:38
mborzeckizyga: ^^11:39
zygayeah, noticed :)11:39
mborzeckizyga: poor man's test result cache11:40
=== pedronis_ is now known as pedronis
cmatsuokazyga: hey11:57
zygammm11:57
zygawhat's up :) ?11:58
cmatsuokazyga: are you aware of snap-confine-undesired-mode-group errors in fedora? or are these fixed already in master?11:58
zygacmatsuoka: can you show me the log please11:58
cmatsuokasure, just a sec11:58
zygacmatsuoka: there's one thing in master that is fixing the only known, to me, failure of this test11:59
cmatsuokahttps://github.com/snapcore/snapd/pull/8495/checks?check_run_id=58754678911:59
mupPR #8495: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8495>11:59
zygayes11:59
zygathis is fixed in master11:59
cmatsuokaexcellent, thanks!11:59
pedroniscmatsuoka: hi, I worked a bit on #8463, it should be ready to land I think, but it's very red (for various reasons)12:09
mupPR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>12:09
cmatsuokapedronis: I just checked it, thanks for the fixes/improvements12:10
pedroniscmatsuoka: Chris asked you to review: https://github.com/snapcore/secboot/pull/4612:12
mupPR secboot#46: Make SealKeyToTPM enforce a key size of 64-bytes <Created by chrisccoulson> <https://github.com/snapcore/secboot/pull/46>12:12
cmatsuokaack12:12
mupPR snapcraft#3039 closed: build providers: setup initial apt source configuration <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3039>12:40
mborzeckimvo: can you use your superpowers and merge https://github.com/snapcore/snapd/pull/8501 ?13:07
mupPR #8501: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8501>13:07
mvomborzecki: sure13:23
mborzeckimvo: thanks!13:23
mupPR snapd#8501 closed: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <⚠ Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8501>13:24
mvomborzecki: does 8476 look ok otherwise (beside this one point you made there)13:27
zygaok, I can now turn off my home server13:36
zygawe have 38 workers in two locations13:37
roadmrzyga: maybe you can lease some DC capacity from Stéphane :)13:38
zygaroadmr: that's an interesting idea13:38
zygamvo: ^ we probably could :)13:38
mupPR snapd#8476 closed: secboot: add tpm support helpers <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8476>13:39
mvozyga: heh, interessting13:41
* zyga breaks for lunch13:53
mupPR snapd#8481 closed: cmd/snap-update-ns: handle EBUSY when unlinking files <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8481>13:59
mupPR snapd#8485 closed: cmd/snap/debug/boot-vars: add opts for setting dir and/or uc20 vars <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8485>13:59
zygathank you mvo!14:13
pedroniscmatsuoka: not really urgent but we should probably merge secboot_tpm.go and tpm.go at some point, they are not big, it's not very clear what each does. the other option is to rename secboot_tpm.go to something else14:16
mupPR snapd#8500 closed: httputil: fix client timeout retry tests <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8500>14:21
ijohnsonzyga: so is robust mount namespace updates already enabled by default on master ?14:22
cmatsuokapedronis: agree, I considered that myself when moving tpm.go to secboot but decided to propose that later to avoid changing too much in a single step14:23
zygaijohnson: yes it is14:28
ijohnsonnice14:28
zygaijohnson: 2.45 will have it14:28
* zyga is partially away, prepping food 14:28
pedronisijohnson: cmatsuoka: I did some digging about the SecureBoot variable14:33
cmatsuokapedronis: ah interesting, any new finding?14:34
pedroniscmatsuoka: see the PR comments14:34
* cmatsuoka checks14:34
zygahmmmm15:16
zygadid canonistack just die?15:16
roadmrdeadstack15:17
zygahmm15:19
zyganot sure what happened15:20
mupPR snapd#8453 closed: [RFC] travis.yml: re-enable travis <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8453>15:20
ijohnsonpedronis: #8497 is ready again15:22
mupPR #8497: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8497>15:22
pedronisijohnson: I was in meetings, looking now15:25
ijohnsonthanks15:29
pedronisijohnson: commented15:33
ijohnsonpedronis: do you want a separate PR/rebase to extract just the change for https://github.com/snapcore/snapd/pull/8497#discussion_r408941648 ?15:40
mupPR #8497: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8497>15:40
* zyga settles for quiet work15:41
pedronisijohnson: maybe yes, I would expect a test change for it in some form15:41
ijohnsonpedronis: ok, fwiw that was changed in the PR that's open15:42
ijohnsonthat will be easy to extract out though15:42
mupPR snapd#8503 opened: boot/bootstate20: fix bug in try-kernel cleanup <Bug> <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8503>15:46
ijohnsonpedronis: broken out as ^15:46
pstolowskimvo: i've pushed my early config test to https://github.com/stolowski/snapd/tree/core18-early-config15:47
jdstrandsil2100 (cc mvo): hey, the core20 snap is failing with https://paste.ubuntu.com/p/DrhfhjWG9y/. can you confirm this is ok or not?15:47
pstolowskimvo: to run it: google-nested:ubuntu-18.04-64:tests/nested/manual/core-early-config15:47
cmatsuokacachio: unfortunately we still need sb enabled to be able to run the full encryption test15:48
cmatsuokacachio: error: cannot seal the encryption key: cannot store encryption key: cannot add EFI secure boot policy profile: cannot compute secure boot policy digests: the current boot was performe15:48
cmatsuokad with secure boot disabled in firmware15:48
jdstrandsil2100 (mvo): I'm going to approve it to unblock the queue, but please look into it15:51
mvopstolowski: thanks, in a meeting right now, will have a look once that is over15:53
cachiocmatsuoka, is that on classic?15:54
pedronisijohnson: thanks, it wasn't clear that the calls number where not a consquences of some of the refactorings15:54
mvojdstrand: thanks, problably https://paste.ubuntu.com/p/DrhfhjWG9y/ is something for xnox to review15:54
ijohnsonpedronis: yes the refactor actually exposed the bug :-)15:54
cmatsuokacachio: mm, yes, the test is supposed to run on classic15:55
cachiocmatsuoka, ok, I'll take a look15:55
xnoxmvo:  can you explain that output?15:56
cmatsuokacachio: thanks, I'll run a few more tests here and will be back after lunch15:56
cachiocmatsuoka, just first let me finish the tests changes I did15:56
cachiocould you give me a link to your tests?15:56
xnoxmvo:  i.e. these files were removed from .deb's in focal, and hence new revisions of core20 snap don't have them......15:56
mvoxnox: jdstrand runs a tool that compares the files from one base to the next base and when stuff is removed it alerts and blocks the snap15:57
ijohnsonmborzecki: around?15:57
xnoxmvo:  why are you asserting contents of .deb's that are part of core20 snap?15:57
cmatsuokacachio: yes, of course. I'm running the test with PR #840915:57
mvoxnox: I don't, the store-review-tools do15:57
mupPR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>15:57
mvoxnox: it's there to ensure that bases are stable and drop support15:57
xnoxjdstrand:  those files are dropped in focal, despite equivalent functionality still present.15:58
xnoxjdstrand:  you should see new added files, like subiquitycore/palette.py15:58
xnoxjdstrand:  and that systemd-timesyncd is now a standalone package, which is included.15:58
jdstrandxnox: ack, that's fine. thanks!15:59
jdstrandxnox: just wanted to make sure it was intentional15:59
xnoxjdstrand:  it was =)15:59
xnoxjdstrand:  if you have questions like these in the future, core20 bug tracker is on github snapcore/core20 issues15:59
xnoxjdstrand:  or foundations-crew@lists.canonical.com as foundations owns/builds core2016:00
cachiocmatsuoka, nice, I'll take a look after lunch as well16:00
jdstrandxnox: right, that is why I pinged sil2100, but I can change the workflow16:00
xnoxjdstrand:  he mostly deals with "stable" like core18 / core1616:01
xnoxjdstrand:  core20 will be dead to me next thursday! and onto bootstrapping core2216:01
jdstrandxnox: heh, so should foundations-crew@lists.canonical.com be used for core16 and core18?16:01
sil2100I like how xnox said "stable" ;)16:01
jdstrandmvo: ok, so core20 revisions are now passing automated reviews again and should be caught up in a few minutes16:02
xnoxjdstrand:  yes you can. foundations-crew@ is one stop shop for core snaps, subiquity, netplan, etc.16:02
jdstrandok, thanks16:03
* cachio lunch16:03
jdstrandxnox: that list is internal only, right?16:04
xnoxjdstrand:  yes.16:05
mvocmatsuoka: looks like 8463 is ready to land but one core20 test is failing, i.e. google:ubuntu-core-20-64:tests/core/basic20, could you please disable this part of the test and/or move to nested (if disable, TODO:UC20: is probably fine). then this can land16:34
mvocmatsuoka: nevermind16:44
mvocmatsuoka: pushed it16:45
cachiocmatsuoka, I don't see any nested test on #840916:56
mupPR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>16:57
cachiocmatsuoka, is that the PR?16:57
cmatsuokacachio: yes, the test is currently in tests/main/uc20-create-partitions-encrypted, it will be moved to nested17:02
cachiocmatsuoka, ah17:04
cachiook17:04
pedronisthis failure is weird: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/1163/signedlogcontent/31?urlExpires=2020-04-15T17%3A04%3A50.7188367Z&urlSigningMethod=HMACV1&urlSignature=n1FukofiSafDmCcRwGnoncpLJS8mfgpiWZRJABATpvc%3D17:06
ijohnsonpedronis: that url seems to be expired17:07
ijohnsonwhich PR was that from?17:07
pedronisijohnson: your PR17:07
ijohnsonI noticed an odd lxd error from 8503, but I saved the logs and restarted the check17:08
ijohnsonah okay so same thing I saw17:08
ijohnsonI'm looking into the issue now17:08
pedronisyes, weird failure in a lxd regression test17:08
pedronisijohnson: it failed also in your other pr17:10
pedronisso maybe it's real17:10
ijohnsonthat's silly17:10
* ijohnson will look more into it after lunch17:10
=== pedronis_ is now known as pedronis
zygawhat was the failure?17:17
zyga(in the lxd regression test)17:17
cmatsuokapedronis: what would be a good place to define the kernel command line used in tpm sealing?17:40
pedronisijohnson: that test is failing for master too17:46
zygapedronis: do you have logs?17:46
zygawhich test is it?17:46
pedronissomething thinks we should have snapd around17:48
pedronisbut actually we have core17:48
pedronis# lxc file push /usr/bin/snap bionic/usr/bin/snap17:48
pedronisError: open /snap/snapd/current/usr/bin/snap: no such file or directory17:48
zygaah17:48
zygaI think I know that this is17:48
zygaone moment17:48
zygaI think it's a race, I've seen things like that today17:49
zygalxc launch ...17:49
pedronisit's google:ubuntu-18.04-64:tests/regression/lp-187165217:49
zygalxc file push ...17:49
zygathat fails17:49
pedronisit fails on master, running alone17:49
zygaI added lxc exec -- ls -l ...17:49
zygathat makes the container "ready" somehow17:49
zygapedronis: thanks, I'll run it now17:49
pedroniscmatsuoka: the bootloaders should know about this, but for now you can hard code it in devicestate if it's easier17:52
cmatsuokapedronis: ok, thanks17:53
pedroniscmatsuoka: actually is not devicestate, right? this goes into snap-boostrap?17:53
pedronisanyway you can hard code it in snap-boostrap for now17:54
cmatsuokamm, yes, it's in snap-bootstrap17:54
* ijohnson is back17:59
ijohnsonzyga: did you reproduce/fix the issue?18:00
zygaijohnson: yes, not yet18:13
ijohnsonah finally my spread run just got there I've got it now too18:14
zygaso18:14
zygathis is weird18:14
zygathere are two systems18:14
zygathe host and the container18:14
zyganeither has snapd snap18:15
zygayet18:15
zygalxc file push says18:15
zygaError: open /snap/snapd/current/usr/bin/snap: no such file or directory18:15
zygathis is lxd 4.0.018:15
zygamaybe lxd bug?18:15
stgraberyou must have SNAP or SNAP_NAME in the environment18:15
ijohnsonstgraber: we don't18:16
zygaindeed18:16
ijohnsonhttps://www.irccloud.com/pastebin/dtcv3kfp/18:16
zygaand this passed recently as it's a fix for the bug that was plaguing lxd (from snapd side)18:16
stgraberwhat's the "lxc file push" you're running?18:16
zygalxc file push /usr/bin/snap bionic/usr/bin/snap18:16
zygaI'm copying the snap command from the host (deb) to the guest18:16
zygasince the host has locally built snapd18:17
stgraberhmm, odd18:17
ijohnsonstgraber: if I switch to 3.23/stable channel the same command works18:18
ijohnsonand actually switching back to 4.0/stable channel again the same command fails again18:18
ijohnsonlooks like a lxd regression to me18:18
stgraberhmm, we didn't touch any of the file code between 3.23 and 4.018:18
zygayeah, I just tried that too18:18
zygastgraber: did you release 4.0 recently?18:19
stgraberwe did just switch the snap over to core18 though18:19
ijohnsonzyga: did you see the same behavior?18:19
zygayes18:19
zygaworks perfectly on 3.2318:19
zygaijohnson: shall we update LXD channel and call it a day?18:20
ijohnsonzyga: yeah I think that's fine for now18:20
ijohnsonI'll file a PR18:20
zygathank you!18:20
zygamay I suggest something?18:20
zygaijohnson: adjust the test to respect a variable18:20
stgrabertesting with current 4.0 with same file push here to see if it reproduces easily18:20
zygaand update the variable in spread.yaml18:20
zygaI think I missed that we have this in the first place when I wrote the test18:20
ijohnsonzyga: that's a great idea sure18:21
zygathanks!18:21
stgraberroot@sateda:~# nsenter --mount=/run/snapd/ns/lxd.mnt  -- ls -lh /usr/bin/snap18:21
stgraberlrwxrwxrwx 1 root root 32 Mar 11 05:46 /usr/bin/snap -> /snap/snapd/current/usr/bin/snap18:22
stgraberthat would be why ^18:22
zyga!!!18:22
zygathat's weird18:22
zygahow did we get that symlink?18:22
stgraberpresumably this wasn't that way on core16 so that wasn't a problem18:22
zygais that a core18 regression?18:22
zygais 3.23 using a different base?18:22
stgraberI mean, it's still a bug, it shouldn't actually pull the thing from inside the snap, it needs to pull it from the host18:22
stgraberyeah, we switched based from core to core18 a few hours ago18:22
zygaindeed18:22
zygathis makes sense18:23
stgraberroot@sateda:~# nsenter --mount=/run/snapd/ns/lxd.mnt  -- ls -lh /var/lib/snapd/hostfs/usr/bin/snap18:23
stgraber-rwxr-xr-x 1 root root 14M Oct 30 12:17 /var/lib/snapd/hostfs/usr/bin/snap18:23
zygacool, do you need a bug report for tracking?18:23
stgraberthat's still fine and it should be using that18:23
stgraberyou can if you want, but I'll probably have it fixed in 5min or so18:23
zygaok, no need then18:23
stgraberINFO[04-15|18:27:30] Pushing /var/lib/snapd/hostfs/usr/bin/snap to /usr/bin/snap (file)18:27
stgraberthat's more like it18:27
stgraberI absolutely hate that logic...18:27
stgrabersuch a mess to support absolute and relative paths, with and without symlinks in the middle, ...18:28
stgraberzyga, ijohnson: https://github.com/lxc/lxd/pull/719818:29
mupPR lxc/lxd#7198: shared/util: Never look into the snap <Created by stgraber> <https://github.com/lxc/lxd/pull/7198>18:29
stgraberwill be in the stable snap in the next 4-5 hours I'd say18:29
ijohnsoncool thanks stgraber18:29
zygastgraber: you like to live dangerously ;-)18:29
zygabut I admire that18:29
stgraberI've been doing daily stable cherry-picks lately18:29
zygaah18:29
zygaI see18:29
zygathat's interest18:29
zyga*interesting18:29
zygaperhaps something we could do?18:29
ijohnsonahhhh we would have many folks very mad if we did as many stable releases as often as lxd :-)18:30
stgraberwell, we have pretty reasonable testing on all distros and architecture, that's why it takes 4-5 hours before we're pretty confident it's not horribly broken :)18:30
zygastgraber: having a regression test for push would be great tho :D18:30
stgraberyeah, not very practical to test in CI since we don't use any snaps there, but I'll sneak some file push testing into our snap tests18:31
stgrabertest added18:33
zygathank you :)18:33
ijohnsonzyga: fancy a +1 before you EOD? https://github.com/snapcore/snapd/pull/850418:36
mupPR #8504: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8504>18:36
ijohnson:-)18:36
zygalooking18:36
zygaI'm not EODing yet18:36
zygadeeeeply in dbus18:36
ijohnsonone might say you are dbusly in dbus18:36
* ijohnson stops18:36
mupPR snapd#8504 opened: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8504>18:36
zygahahaha18:36
zyga+118:37
zygathere's something magic about the words18:38
zyga"in progress"18:38
zygathat's so much better than "queued" we had before18:38
mupPR snapd#8505 opened: spread.yaml: switch back to latest/candidate for lxd snap <Test Robustness> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8505>18:44
zygaijohnson: ^ nice18:46
ijohnsonin progress does sound much better18:46
ijohnsonI think in general whenever we need to do things like this, i.e. revert something to unbreak master while something is fixed, we should always open a PR undoing that change at the same time so at least we remember because there's an open PR about changing18:47
zygayes18:47
ijohnsoni.e. same thing when we move a system to unstable, we should open another PR which moves it back to stable18:47
ijohnsonpedronis: we fixed the lxd issue on master18:48
ijohnsonwell we have a PR open18:48
mupPR snapd#8463 closed: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8463>18:48
pedronisijohnson: I see18:49
pedronisijohnson: anyway proves why I'm not a fan of dangling symlinks in bases18:50
ijohnsonpedronis: yes but also why we should be very strict about letting snaps access things in bases too18:51
pedronisyes18:52
ijohnsonpedronis: also did you discuss with maciej about picking up the necessary changes to gadget pkg et al to enable mbr support for create-partitions? should I try to push that forward? I was kinda hoping that he would pick that up but I keep forgetting to ask him before he EODs18:52
pedronisijohnson: I don't know, it's actually a prereq to make the run mode changes relevant, right? because it's install time?18:53
ijohnsonpedronis: yes18:53
ijohnsonyes it's a blocker I mean18:54
pedronisijohnson: have you started the other bootloaderKernelState ?18:54
ijohnsonI'm wrapping it up now, but I need to figure out a way to write tests for it, I'd rather not rewrite the dozens of tests we already have for bootstate20 to use a mock uboot bootloader, etc.18:55
pedronisijohnson: maybe just write direct tests for it?18:56
pedroniswe probably need to reorg some of the other tests as table tests so that they are easier to reuse18:56
ijohnsonpedronis: yes perhaps, need to think about it a little bit18:56
pedronisor have a actual test mixins18:56
pedroniswe don't have a lot of the latter but we don sometimes18:57
ijohnsonyeah we could refactor some of the tests big chunks to use helpers too18:58
ijohnsonlots of the tests are just bootloader setup anyways18:58
pedroniscmatsuoka: is #8409 ready for Chris to look at it?18:59
mupPR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>18:59
cmatsuokapedronis: will be in a minute, pushing a final commit19:00
cmatsuokapedronis: pushed19:01
mupIssue core20#36 closed: SSH login shell says the system was minimized and to run "unminimize", but should not <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/36>19:23
mupPR core20#42 closed: drop `unminimize` instructions that are not applicable on Core <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/42>19:23
mupPR snapd#8284 closed: config: add system.store-certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8284>19:52
mupPR snapd#8503 closed: boot/bootstate20: fix bug in try-kernel cleanup <Bug> <Simple 😃> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8503>19:58
mupPR snapd#8504 closed: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <⚠ Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8504>20:05
mupPR snapd#8506 opened: Add libnvidia-opticalflow as Nvidia library <Created by joedborg> <https://github.com/snapcore/snapd/pull/8506>20:37
joedborghey everyone, if someone could take a quick look at ^ it'd be much appreciated20:37
mwhudsonwhat determines what ends up in parts/$PART/install/usr/lib/python3/dist-packages using the python plugin?21:36
mupPR snapcraft#3043 opened: package-repositories: initial schema and meta read/write support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3043>22:17
mupPR snapcraft#3044 opened: build providers: use ubuntu-ports mirrors for non-x86 platforms <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3044>22:45

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