/srv/irclogs.ubuntu.com/2020/05/27/#snappy.txt

mborzeckimorning05:24
zygaHey05:43
zygamborzecki: I will be around in about an hour05:44
mborzeckizyga: hey05:44
mupPR snapd#8745 closed: tests: port xdg-open-compat to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8745>06:02
mupPR snapd#8746 closed: tests: port xdg-open to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8746>06:03
zygathanks!06:21
zygamborzecki: it would be good to review the f32 branch from sergio06:21
zygaonce merged we should have those green ticks again06:21
mborzeckizyga: yeah, i'll be pushing some fixes there06:21
zygaok06:21
zygabrb again06:24
mborzeckimvo: hey06:33
mvogood morning mborzecki06:35
mupPR snapd#8743 closed: tests: cherry-pick test fixes from master (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8743>06:39
mvo8351 needs a second review06:46
mupPR snapd#8661 closed: configcore: add "service.console-conf.disable" config option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8661>06:48
pstolowskimornings!07:03
mupPR snapd#8748 opened: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>07:04
pstolowski#8533 has been unblocked and needs 2nd review07:09
mupPR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>07:09
mupPR snapd#8749 opened: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>07:18
zygajamesh: https://github.com/snapcore/snapd/pull/8748#pullrequestreview-41892930707:36
mupPR #8748: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>07:36
pstolowskimvo: thank you for 8749!07:36
pedronispstolowski: hi, could you review #8351 ? also do poke Sergio about your #853307:39
mupPR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>07:39
mupPR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>07:39
pstolowskipedronis: yes07:39
zygapstolowski: https://github.com/snapcore/snapd/pull/8709#pullrequestreview-41892630207:41
mupPR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>07:41
pstolowskizyga: thanks!07:41
jameshzyga: thanks.  I guess one difference is that the systemd in CentOS 7 supports user units, but they just don't run the instance.07:43
zygajamesh: what do you mean by supports?07:44
jameshwhereas 14.04's systemd doesn't support them at all07:44
zygaah07:44
zygacentos 7 is compiled without that IIRC07:44
zyga(explicitly disabled)07:44
zygabut those are shades of gray I suppose07:44
jameshzyga: as in "systemctl --user --global enable some-user-unit.service" succeeds on Centos 707:44
zygaAh, that's weird, perhaps not fully disabled07:44
zygabut officially disabled per RH design07:45
jameshzyga: I guess in some ways it is similar to Ubuntu Core, where it is technically possible to set up a user session but it is rarely done07:46
jamesh(granted that will probably change in future)07:47
zygabrb, small breakfast07:56
ograhmm ... is there a snapctl command that can tell me if seeding is done ?07:58
zygaogra: snapctl?08:04
zygaor snap?08:04
ograzyga, snapctl (or the rest API)08:07
ograa customer wants to check the state from inside a snap08:07
ograi know he could loop over the changes output via the API until "Initialize device" is marked "done" but wanted to know if there is a more integrated and less hackish way08:08
zygaI don't think this is supported08:08
zygalet me look08:08
zyganope08:09
zyganot supported08:09
ograok, then looping over changes it is ...08:10
jameshogra: the snapd.seeded.service systemd service runs "snap wait system seed.loaded".  If you've got access to the REST API, you could presumably do the same08:18
=== ijohnson_ is now known as ijohnson
=== tomwardill_ is now known as tomwardill
ograjamesh, hmm, how would i get that info from the api beyond looping over the changes ?08:20
ograi dont see any rest endpoint that could give me that info beyond the chnages output08:21
jameshogra: check what /usr/bin/snap does?08:21
jameshogra: looks like it's effectively doing "snap get system seed.loaded" every 500 milliseconds until it returns true08:22
ograoh, its aconfig option !!!08:22
ograthanks ! i totally forgot about that bit08:22
ograso there *is* a snapctl way in the end :)08:23
jameshsnapctl will only give you your own config though, right?08:23
jameshnot the system snap's configuration08:24
ograit queries "system" in that case08:24
ograwell, a gadget can do that08:24
ograiirc08:24
jameshyou'd know more about that than me :-)08:24
zygaogra: snap and snapctl have different APIs08:26
ograzyga, well, he has the API ... so using "GET /v2/snaps/[name]/conf" should be able to get him "system" configs, no ?08:27
zygawhat do you mean by "he has the API"08:28
jameshpresumably he has snapd-control level access08:28
zygaah08:28
zygain that case then yes08:28
ograteh question comes from a customer with brand store08:28
ograright08:28
ogrageez, we need customer docs for this 108:28
ogra!08:28
* ogra makes note08:28
ograi know some that *actually* loop over the changes output to find out :)08:29
* zyga debugs with -seed= again08:48
zygahey, reproduced08:55
zygaha08:56
zygafunny08:56
zygalet's write an invariant to find the culprit08:56
zygasome test nukes some packages but doesn't reload systemd08:57
zygaso the invariant will find systemd that complains abou "some units changed on disk"08:57
zygaand this will lead us to the test breaking stuff08:57
zygaeureka09:27
zygatests/upgrade/basic user unit snapd.session-agent.socket changed on disk09:27
zygain fact09:29
zygait keeps getting changed09:29
zygahmmmm09:29
zygaI wonder why09:29
zygamaybe we should not be agressively rewriting it09:29
zygabut that's just noise09:30
zygathere's another test that breaks dbus.socket09:31
zygafortunately not that many tests need fixes09:53
zygaabout half a dozen one liners09:53
zygamvo: ^ another lesson learned09:53
zygasystemd units have state in memory and on disk09:53
zygaand in memory state is the one that counts09:54
zygaunits are modified by tests and left stale in memory after "restoring" the disk state09:54
mvozyga: oh, woah, nice catch09:56
zygayeah, it manifested as a random failure that I managed to reproduce with -seed09:56
zygaand ended up being a dbus.socket that's only in memory because the disk file is gone09:56
zygaand cannot be activated (because no .service because also gone)09:56
zygaso some test removes dbus.socket/service but the bigger find is that the in-memory state matters09:57
zygawriting and running tests is useful but I think we could write a boot about integration testing now09:57
zyga*book :)10:03
mupPR snapd#8747 closed: tests: port snap-routine-portal-info to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8747>10:04
mborzeckireading bug reports, it's amazing how people quickly jump to reinstalling the system whenever even a smallest issue pops up10:15
zygamborzecki: do you know windows made that super easy?10:16
zygamaybe it's something they learned and apply to other OSes10:16
mborzeckizyga: seriously? my experience with windows reinstall was that it was a huge waste of time10:16
zygamborzecki: why?10:17
mborzeckithough it did fix issues there ;)10:17
zygamborzecki: btw, windows 10 reinstall is super easy10:17
zygait's literally 4 clicks from the start menu10:17
zygaand the experience is quite nice10:17
mborzeckihaven't reinstalled 10 yet, maybe i'm not using it enough10:17
zyga(can preserve apps or just data, entirely unattended)10:17
zygamborzecki: https://github.com/snapcore/snapd/pull/8693/files has some spurious changes10:18
mupPR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>10:18
zygaare they relevant or can we nuke them?10:18
mborzeckizyga: yeah, noticed them after i pushed the changes, don't think it's worth another spread run though10:18
zygaok10:18
zygaI resolved a conflict10:18
zygabut didn't notice this until after10:19
mborzeckihah ;)10:19
zygaone thing that I miss on !windows is family management10:19
mborzeckionce it's green, we should land it10:19
zygayeah10:19
zygacontrol over time, app access and even browser page access10:19
mborzeckihaha i talked with mvo about a killed linux app that could do that10:20
zygaI really wish we had something comparable10:20
mborzeckiwhich would be great, and we probably have the right technology to do it already10:20
zygayeah but it's either really well done and useful or it's not useful at all :/10:20
zygaloopholes => not useful, poor UX => not useful, not localized => not usefl10:20
zygathough I bet it would be good to have something and work from there10:20
zygaI think one major problem is that it requires central authority and accounts to be easy to use10:21
mborzeckiwell, we don't have anything there yet, so ;)10:21
zygayeah10:21
mborzeckipedronis: added some comments under https://github.com/snapcore/snapd/pull/856910:21
mupPR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>10:21
zygaeven limiting time is hard10:21
zygagdm would have to cooperate10:21
mborzeckipedronis: is that the last PR in that series?10:22
pedronismborzecki: I saw, thx10:22
* zyga needs to manage browser tabs, brb10:22
pedronismborzecki: it's the main one, but no, as the description says there will be a couple more follow ups, one is almost ready, but is not proposed yet10:22
mborzeckiok10:22
pstolowskizyga: can you take another look at #8639?10:24
mupPR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>10:24
zygaha10:24
zygasure10:24
zygaI just looked at another branch and though that was the same one :)10:24
mborzeckiheh, something weird about go compiler10:26
zygahmm?10:26
mborzeckitook #8749, dropped the default: case like so https://paste.ubuntu.com/p/NJSFCQkF8N/, then compiler complains about ./services.go:90:1: missing return at end of function10:27
mupPR #8749: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>10:27
mborzeckiby looking at the code i see that there always is a return in the switch cases there10:28
mupPR core20#69 opened: hooks: remove redundancy from timezone settings <Created by mvo5> <https://github.com/snapcore/core20/pull/69>10:30
mborzeckiheh this is weird https://play.golang.org/p/-Bxl-hPNAeu10:30
mvomborzecki: heh, this looks familiar10:31
zygamborzecki: go doesn't do proper analysis10:31
mborzeckimvo: yup, the pr you opened10:31
zygaerring on the "compile quickly"10:31
mvomborzecki: I was surprised as well10:31
zygait sucks but it's a known issue10:31
mborzeckimvo: wonder whether the compiler would even determine that panic code is unreachable10:32
mvomborzecki: if it can it should be easy to fix the bug :)10:32
mvomborzecki: I mean, the bug/issue that this requires a return still10:32
mborzeckifamous last words :P10:32
mvolol10:32
mvoactually rofl10:32
mvoyeah, I will not try or I get sucked into a black hole10:33
zygamborzecki: I wonder if: if false { println("DUPA") }10:33
zygamborzecki: compiles in a way where DUPA is gone from the binary10:33
mborzeckihaha if works https://play.golang.org/p/j2VSn1xex7K10:34
mvomborzecki: woah, that's "funny10:34
mvo"10:34
zygait's weird especially considering that go's switch/case degenerates to if-then-else tree10:35
mupPR snapd#8351 closed: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>10:37
mborzeckifunny that it's quite happy when there's a default case10:38
mborzeckiso bools in a switch are tri-state, true, false, something-in-between10:41
pstolowskipedronis: is #8569 ready to be reviewed?10:41
mupPR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>10:41
pstolowskimborzecki: that's peculiar10:42
mupPR core20#69 closed: hooks: remove redundancy from timezone settings <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/69>10:45
zygamvo: thank you for that test btw10:47
zygamvo: I wonder if we could integrate some other things there10:47
zygalike timedatectl10:47
mborzeckitime to file a bug in go10:47
zygasetting timezone10:47
zygasetting NTP10:47
zygaall super basic stuff10:47
zygabut it was broken on more than one occasion10:47
mupPR snapd#8750 opened: tests: improve oom-vitality tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8750>10:48
mvozyga: you mean 69?10:49
zygamvo: you proposed something relevant yesterday10:49
zygato snapd10:49
mvozyga: aha, yes - we can, it's strange, partly this is covered by interface tests10:49
mvozyga: but I suspect it's much cleaner to have a dedicated test10:49
zygayeah but I think there's a difference, those tools often use DBus APIs10:50
zygaand perhaps there's some factor where a tool modifies something directly vs issues a call10:50
zygaso good to have a dedicated basic-management test like that10:50
zygapstolowski: https://github.com/snapcore/snapd/pull/8351#discussion_r43102886110:51
mupPR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>10:51
mvozyga: cool, thanks, I will work on the system-settings a bit more I guess10:52
zygaI actually wonder10:52
zygain your core system deployments10:52
zygadid you set things like hostname, timezone and ntp manually?10:52
* zyga breaks focus to finish some reviews10:54
zygapstolowski: https://github.com/snapcore/snapd/pull/8639#pullrequestreview-41907998210:57
mupPR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>10:57
* zyga found the broken test11:00
mupPR core20#70 opened: Fix localtime <Created by xnox> <https://github.com/snapcore/core20/pull/70>11:03
mupPR core20#71 opened: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <https://github.com/snapcore/core20/pull/71>11:06
zygabrb, coffee11:13
zygait's hard to use the coffee machine11:14
zygawhen one kid is constantly remote-schooling in the kitchen :D11:14
pedronispstolowski: zyga: I asked a new question in #869111:21
mupPR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>11:22
pedronispstolowski:  #8569, yes11:24
mupPR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>11:24
pedronisthere are some open questions and tweaks but in itself is good to go11:24
zygapedronis: looking11:24
zygareplied11:26
zygagah, I wish spread used mosh instead of ssh11:29
zygamosh is so nice for roaming11:29
mupPR core18#154 opened: Test timezone contents and symlink <Created by xnox> <https://github.com/snapcore/core18/pull/154>11:30
mupPR core20#71 closed: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core20/pull/71>11:35
zygapedronis: testing.global.session testing.netgate testing.global.invariant11:38
zygapedronis: how do those sound to you?11:38
pedroniszyga: I'm thinking, I'm actually starting to think that for most of them the problem is a bit self-inflicted11:42
zygapedronis: because they have before/after parts?11:48
* zyga probably doesn't follow11:48
pedronisno, because it's not clear why we need most of them on PATH, they aren't used enough to justify that and the naming problem it creates11:49
zygapedronis: they are on PATH so that they do not require sourcing via $TESTSLIB11:50
zygain the past we had functions that were bad for other reasons11:50
pedroniswhat it has to do with sourcing11:50
zygabut required sourcing and this was tedious11:51
zygaah, because they were functions and not on path, you had to get them somehow11:51
pedronisthese are not functions11:51
zygaright11:51
pedronisalso as I said, the tedious argument doesn't apply to many of them11:51
pedronisthey are not used enough to make it a good reason11:51
zygasure but some are super common, are you suggesting to drop them from path/11:51
pstolowskii think part of the reason they are in PATH is to make them usable to debug tests easily when in spread shell11:51
zygaoh, that's useful as well11:51
* zyga didn't think about that11:51
zygayou can paste stuff from a test and it mostly works11:52
zyga(depending on how much you paste)11:52
pedronispstolowski: again, I don't thinkt that argument applies equally11:53
pedronisto all of them11:53
zygaI don't see a problem with them being on path11:53
zygatesting.foo is a good solution if we need to have unique prefix11:54
pstolowskiyes. i'm not even too concerned about testing.not tbh, it's just a prefix11:54
pedronisat some we can't start to explain that we did something to avoid tedious, and then circle back there, testing.negate is fairly tedious11:57
pedronistbh11:57
zygapedronis: not is not tedious :)11:58
pedronisexactly11:58
zygapedronis: but importing something or $TESTSLIB/tools/not is also a bit tedious11:58
zygabut not might be a special case11:58
pedronismy point is that I don't trying to find a solution that works for all of them11:58
pedronisis a goal11:58
zygaas it's super short and small and frankly not related to snapd11:58
zygaI think handling session-tool and retry-tool should be the goal11:58
zygaas those are used fairly often11:59
zygathe rest can be another class that doesn't need the same solution11:59
pedronisalso shellcheck is not helping here12:00
zygain which sense?12:00
pedronisthat it forces quotes, I understand where it comes from12:01
pedronisbut sometimes you know what is in your env var12:01
zygaone more idea is to multiplex everything through one tool that is on path12:02
zygasnapd-testing ...12:03
zygasnapd-test-helper ... or whatever we name it12:03
pedronisthat might be part of the solution12:03
zygathen it's one item on path and pretty easy to even handle migrations12:03
pstolowskiyes that's an interesting idea12:03
zyga(assuming we migrated to the tool in the first place)12:03
zygawe could even call it12:04
zyga"the-tool"12:04
zygaexcept that's for core 2012:04
pedronisno12:04
zygaI was totally kidding :)12:04
zygatestctl sounds like systemd thing12:04
zygathough "testctl foo" could invoke "testctl-$foo" so we'd have a simple way to use various languages (like we do now)12:05
zygaso I kind of like that more and more12:05
zygaand the rest would not need to be on path eventually12:06
* zyga is surprised12:09
zyga-.mount unit changed on disk https://www.irccloud.com/pastebin/oVaMhye7/12:09
zygahow is this even possible?!?12:09
zygamborzecki: ^ any ideas?12:09
zygaah, we modify fstab12:10
zygafun12:10
zygafixed now12:10
mborzeckizyga: yup, the test touches fstab12:11
mborzeckiand -.mount is autogenerated12:11
zygayeah12:12
zygaanother one from another test12:12
zygartkit-daemon.service changed on disk https://www.irccloud.com/pastebin/JCg4YEkc/12:12
zygathe test installs/removes that12:12
zygapedronis: do you have a feeling on what to do with test names then?12:20
zygapedronis: which way do we go12:20
pedronisnot yet12:21
zygas/test names/test tool names/12:21
zygaok12:21
zygaI'm happy to apply the change, when you make up your mind12:21
zygaI think we could also have a two-tier system, where some rarely used tools can have different properties12:21
zygaas some are indeed used a few times in the entire project12:22
zygacachio: is the ubuntu 16.04-32 (note -32) image using EFI?12:22
cachiozyga, it supports uefi, not really sure if it is using it, I suppose that yes12:23
zygaok12:23
zygaI think it boots in legacy mode12:23
zygabut that's fine12:23
zygaI was just curious12:24
pedroniszyga: when do you want to discuss refresh awareness, tomorrow morning after the desktop meeting?12:24
cachiozyga, we are not enabling any security feature, so by default iirc the systems use the legacy mode12:24
zygapedronis: that sounds great12:24
zygapedronis: I will push all my changes by then12:24
zygapedronis: I took a small detour to fix various random issues I ran into but test coverage is close to being good now and I still have a few more patches to send12:25
cachiozyga, but it is managed by the gce hypervisor and there is not details in the docs about  it12:25
zygacachio: ok, I guess it's uncommon to use 32 bit systems so maybe they don't boot them with uefi12:25
cachiozyga, just few line explaining the high level12:25
zygacachio: I only noticed because boot/efi was missing12:25
pstolowskicachio: hi! could you take a look at https://github.com/snapcore/snapd/pull/8533 ? also updated #871012:28
mupPR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>12:28
mupPR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>12:28
cachiopstolowski, sure12:28
zygapstolowski: do you need any reviews for the preseeding changes?12:32
jdstrandmvo: hey, fyi I approved PR 870612:33
mupPR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>12:33
zygajdstrand: \o/12:33
jdstrandmvo: I looked for another PR for it against 2.45.1 but didn't see it12:34
zygajdstrand: if you are doing reviews, could you look at the /usr/share/doc interface again? It has +2 and just needs your final ack12:34
zyganothing changed wrt permissions12:34
jdstrandzyga: heh, yes. that was the next one12:34
zygasuper!12:34
zygafedora 32 PR is almost entirely there, just one test queued and it will be entirely green12:35
zygabringing average green levels up by a large margin12:35
cachiopstolowski, I left few comments12:36
zygabrb12:41
zygare12:44
cachiomvo, hey, https://paste.ubuntu.com/p/hFFjC3Nwj3/12:45
cachioI see this error to build12:45
cachiomvo, is any dep missing?12:45
mupPR core18#154 closed: Test timezone contents and symlink <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core18/pull/154>12:48
mupPR core20#70 closed: Fix localtime <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core20/pull/70>12:49
mvocachio: hm, is sbuild installed ?12:50
cachiomvo, yes12:52
pstolowskicachio: ty12:52
cachiopstolowski, reviewing the other one12:52
zygamvo: can you please force merge https://github.com/snapcore/snapd/pull/8693 - it failed on a snap run --strace timeout that's random and known12:54
mupPR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>12:54
zygaand I'd like to avoid an hour of testing xenial again, it's not related to the PR12:54
mupPR snapd#8693 closed: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8693>12:57
zyga\o/12:57
cachioyesss12:58
zygathanks!12:58
mupPR snapd#8751 opened: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8751>12:59
mupPR snapd#8752 opened: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8752>12:59
zygastandup!12:59
mvocachio: please try installing "schroot"13:22
zyganot sure how you work but using a pair of laptops to run tests in one checkout while another is busy editing works for me13:26
roadmrI use a hand-cranked OLPC to ssh into an old mainframe in the basement I got from ebay13:40
ograonly works if you have kids to operate the crank, no ?13:41
* cmatsuoka looks in ebay for a new basement13:42
zygahaha13:42
mupPR snapd#8753 opened: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8753>13:42
zygacmatsuoka: buy two13:42
zygaogra: do you have any music equipment?13:42
ograzyga, do you mean soundcards (a few) or instruments (none) ?13:43
zygamidi synth13:43
roadmrogra: right, so I have the kid crank it for a while, then work a while, then cranking break... and so on13:43
ogranah ... but i guess one of the soundcards i have could do midi stuff13:43
cmatsuokazyga: I'm considering a korg wavestate, but it's not available here yet13:44
zygacmatsuoka: I'd like to find either an MT32 for some dos games or SC-D70 for some other dos games13:44
mupPR snapd#8750 closed: tests: improve oom-vitality tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8750>13:45
cmatsuokazyga: the canvas sounds much better13:45
zygait's also a bit more modern, has pc style AC input and even usb port13:45
zygabut only available in japan13:45
zygaso.... bummer13:46
cmatsuokazyga: a friend of mine had both in the 90s, but I doubt they're still in working conditions13:46
zygathere are some on ebay, they seem to be in great shape13:46
zygathe only thing that may need replacement is a CR32 battery13:46
cmatsuokaI mean, the canvas was the SC-55 I think13:46
pstolowskicachio: updated #853313:47
mupPR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>13:47
zygacmatsuoka: ah, that's a good unit as well13:47
zygaI guess anything after SC-55 is good for games that used general midi, not the preceeding mt32 de-facto standard13:48
ogramy biggest soundcard i have is a Xonar DX virtuoso 100 ...13:49
mupPR snapd#8742 closed: snap-mgmt: perform cleanup of user services (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8742>13:49
ograbut my focus was more on high bitrate playback and surround for gaming13:49
ograless on producing music13:49
cmatsuokazyga: I specifically remember that Sierra's Dagger of Amon Ra sounded so much better in it compared to Adlib/Sound Blaster, except for the archeologist song which only played in the Sound Blaster13:50
zygahuh? :)13:50
zygaI find it fascinating that each game was composed for a particular hardware stack as all the midi synthesizers were not really backwards compatible13:51
cmatsuokazyga: https://en.wikipedia.org/wiki/The_Dagger_of_Amon_Ra13:51
zygaso you may need a few to have the correct unit for each game13:51
zygaI never played it, looks interesting (all sierra games are)13:52
zygahttps://www.gog.com/game/the_dagger_of_amon_ra :)13:52
cmatsuokait looks reasonably priced :)13:53
zygafor me the price is ~3 euro13:53
cmatsuokalisted as 3.39 euro here13:54
zygayep13:54
mupPR snapd#8667 closed: interfaces/fwupd: allow bind mount to /boot on core <:secret: Needs security review> <Security-High> <Created by woodrow-shen> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8667>13:54
zygayou can easily extract it with innoextract and play on any system13:54
ograthere is also https://snapcraft.io/gog-galaxy-wine13:56
zygaogra: nah, too many layers: )13:57
ograheh13:57
zygaI'm somewhat sceptical about snaps like that13:57
zygawould be a totally different story if it was endorsed by gog13:57
ograwell, make diddledan talk them into endorsing it 😉13:58
zygaI think that won't be easy14:01
zygagog is a huge company now14:01
zygaI doublt they would +1 it14:01
zyga*doubt14:01
ograwhy ? it is spreading their stuff14:01
zygaquality and support14:01
* ogra taps foot ... why are LP builders so slow today ...14:01
ograi need an s390x or ppc64el ... they are always first while the other arches still "pending build"14:01
roadmrmainframe in the basement ;)14:07
ogra😄14:08
zygabrb for lunch14:08
mupPR snapd#8709 closed: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8709>14:19
jdstrandmvo, pedronis, zyga: hey, so now that the security team is ramping up the people that can help (eg, amurray and emitorino, though currently things ultimately go through me still), I think it would be better to use the 'Needs security review' tag going forward. In this manner, a member of our team can go to14:36
jdstrandhttps://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%2214:36
zyga+114:36
zygasounds great to me14:36
pedronisjdstrand: works for me14:36
jdstrandmvo, pedronis: and see what is what. I'm not sure why that tag as a non-ascii symbol in it...14:36
jdstrandmvo, pedronis: if people forget and just add me, I'll add that tag14:37
jdstrandso we can all work together on it14:37
* jdstrand does that now14:37
jdstrandijohnson: you probably are interested in that too ^14:37
* mvo is in a meeting14:38
jdstrandemitorino: fyi, https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%22 (though you don't need to do anything with that now)14:39
emitorinoack jdstrand14:39
mvojdstrand: I can remove the strange non-ascii thing in there if you want14:39
pedronisjdstrand: there are some PRs that are changes request by you, don't know if you want the tag on those, or you will track them yourself given you started the conversations14:40
jdstrandmvo:14:40
jdstrandmvo: please if you don't mind :)14:40
jdstrandpedronis: I will continue to track those myself14:40
jdstrandI think it is on the person to track things they requested changes on14:40
pedronisjdstrand: ok14:40
jdstrandI need to step away for a bit, but will read backscroll14:41
mvojdstrand: removed14:41
mvozyga: do you mind if I remove the per-user mount ns tag?14:42
zyganot at all14:42
zygalet's nuke it14:42
jdstrandemitorino: here is a better link: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+security+review%22+ (cc amurray)14:43
jdstrand(that will still show open ones where we've commented)14:43
emitorinojdstrand, yeah figured out the label, thanks anyway!14:43
jdstrandemitorino: you might want to peruse what I've commented on today for questions for tomorrow, but only if you have time14:44
emitorinosure thing jdstrand, thanks!14:44
mupPR snapd#8754 opened: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8754>14:44
pedronisjdstrand: emitorino: we will also still use Security-High for things that have some urgence, we'll give things both tags I suppose (cc mvo)14:46
mvo+114:46
mvoyeah14:46
mvomostly added the other one to avoid accidents14:46
mvowhere stuff gets merged too early14:47
mvo(as hapend with the serial port fix)14:47
pedronisjdstrand: emitorino: also as usual things that have a milestone are usually higher priorities than ones that don't14:47
zygamvo: we have green ticks on github now :)14:47
mvozyga: we do - it's magic!14:48
emitorinoack pedronis14:48
niemeyerissue #12314:48
mupPR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>14:48
niemeyermup_: You there?14:49
mup_niemeyer: I apologize, but I'm pretty strict about only responding to known commands.14:49
niemeyermup_: issue #12314:49
mupPR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>14:49
mup_niemeyer: PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>14:49
niemeyerIt's not overhearing..14:50
niemeyerAh, I know why14:50
niemeyerissue #12314:51
mup_PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>14:51
mupPR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>14:51
niemeyerissue #20014:51
mup_PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>14:51
mupPR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>14:51
niemeyerissue #855814:52
mup_PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>14:52
mupPR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>14:52
niemeyerSorry, will stop now :)14:52
pedronis:)14:53
mupPR snapd#8578 closed: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>14:54
mup_PR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>14:54
mupPR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>14:54
zyganiemeyer: while you are looking, mup had a bug where it would give a link to "issue" vs "issues" (or the other way around)14:54
akikkernel/os snaps? weren't snaps for application containment?14:54
zyganiemeyer: not sure if you noticed or if you fixed that now14:54
niemeyerzyga: Should be fixed on the new instance14:54
zygaah, superb :)14:54
niemeyerThere are several other changes as well, big and small14:54
zygaakik: kernel snaps are used on core devices where snapd manages the entire OS14:54
mvoyeah, nice!14:54
mvothanks niemeyer !14:54
niemeyermvo: np, sorry it took a while14:54
akikzyga: core devices?14:55
zygaakik: there are other snap types used there, that are not seen on regular (non-iot) systems14:55
zygaakik: ubuntu core is a full OS for IOT systems14:55
akikzyga: is that only for ubuntu core then?14:55
zygaakik: we use "core" to describe them, vs "classic" for all other systems with other package managers and typical behavior14:56
ograakik, snap is a fully fledged package format, you can package services (daemons), cli apps, kernels, bootloaders and desktop apps14:56
zygaakik: kernel snaps? yes, they are only used for core devices14:56
zygaakik: a core device has at minimum, a kernel snap, a base snap used for booting (e.g. core20) and a gadget snap14:56
zygaakik: and any number of application snaps14:56
ograubuntu core is completely built from snap packages, no apt, deb, dfn, rpm support on them14:56
zygajdstrand: will review-tools need changes to know about new interfaces? (like system-packages-doc) or is that automatic?14:57
zygaakik: you can use it on a raspberry pi, for example14:59
zygaakik: if you are not familiar that is a great way to learn14:59
akikzyga: i'm a classic kinda guy15:00
ograyou dont know what you'Re missing then :)15:01
akiki don't want to see the linux landscape fragment any more15:02
ografragment ?15:03
ograi doubt anything like core exists anywhere else, not sure what would be fragmented here15:04
akikkernel/libs/desktop environments/application containers15:05
akikthat's what i meant with fragmentation15:05
akiksomebody might not want to run snaps if they are slower to start15:05
* zyga really goes for lunch15:05
zygaakik: it's temporary, we'll get it fixed15:06
akikheh15:06
akikdoubt it15:06
akikoh that slow start?15:06
akiksorry i understood wrong15:06
zyga?15:06
akiki thought you meant fixing the fragmentation15:06
ograwell, thats not up to us15:07
ograwhen we started doing snaps in 2014 nothing like this existed15:07
ograyou cant blame us for innovating really15:07
zygaI'm unsure what kind of fragmentation you are talking about15:07
zygathat different people do different things?15:07
akikkernel/libs/desktop environments/application containers15:07
akiksome company might package their application only to some certain format15:08
zygawhat about them15:08
akikthat's fragmentation15:08
zygaI still don't get it15:08
ograakik, but thats not our fault !15:08
zygathat desktop environments exists?15:08
zyga*exist15:08
zygaor that libraries exist?15:08
zygawhat is fragmented?15:08
ograprobably kernels 🙂15:09
* zyga would like to know what akik meant15:09
akikthat some application might not run if the environment that is available does not match what the application needs15:09
zygaakik: can you give me an example please?15:09
akikvendor a packages the app in a snap only. the user is not able to run the snap15:11
ograthen we need to fix that for the user15:11
ograand he should tell us ... file a bug etc15:11
ograi dont see what this has to do with fragmentation though15:12
akikdifferent distros have different kernels and library versions15:12
ograyes, and snapd takes that into account for most of them15:13
akikyes this was just about fragmentation15:13
ogratake a look at the distro list over therehttps://snapcraft.io/zoom-client15:13
ogra bah15:13
ograhttps://snapcraft.io/zoom-client15:16
akikfragmentation regarding application containers means that there are snap, flatpak, appimage15:16
ogradoes allowing all of these different distros to use the same app really look like fragmentation ?15:16
akikogra: i didn't mean snap when talking about fragmentation15:16
ogranote that these 55 different distros are not all of the,15:16
ograthem15:16
akiki meant these -> kernel/libs/desktop environments/application containers15:16
akikthe 3 first ones15:16
ograwell, you wont use a kernel or gadget snap outside of an ubuntu core system15:16
ograsnaps have a builtin self-test and roll-back mechanism, they guarantee you that your kernel automatically goes back to the former version if an upgrade fails, your new version causes an OOPS etc etc ... this is very unique but utterly needed in IoT, embedded and industrial15:17
ograif you'D use a deb you would have to send out a technician to your 3G tower in the woods to fix the device that hung with a kernel OOPS15:18
ograkernl snaps solve that elegantly15:18
ograthere is no "fragmentation" here it is innovation 😉15:18
ograand if you mean missing kernel security features that cause distros to not adopt snapd to have snap support ... well, thats on them ... there isnt much we can do about, if you look at the zoom-client link i gave you above, there are 55 different distros listed that *are* able to install and use it15:20
ograif there are any that can not people like zyga and his team will happily help the distro devs to make it work15:21
ograactually ... looking at that distro list makes me wonder ... what the heck is "windowsfx 10"15:23
=== mup_ is now known as mup
pedroniszyga: the new interface will need to be documented15:26
zygare15:40
zygapedronis: good point, I'll do it now15:40
zygaackk: note that snap isolates you from everything but kernel and services and their IPC api15:41
zygaakik: ^15:41
zygasorry ack15:41
zygatab eager complete ;)15:41
ogrause hexchat !15:41
zygaakik: so no matter what libs you are using, you should be able to use the snap15:42
zygaakik: if you think this is fragmentation, package an app for 4-5 distributions15:42
zygathen after a month, do an update15:42
zygathat's fragmentation15:42
akikyes that's what i meant15:43
zygaakik: I see now15:43
zyga"akik> ogra: i didn't mean snap when talking about fragmentation"15:43
ograwell, hard to avoid ...15:45
ogradifferent distros (need to) stabilize on top of different releases of software ...15:45
mupPR snapcraft#3145 closed: cli: migrate upload and release to new channel-map <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3145>15:46
ograoften driven by the distros purpose (my distro only wants to use LTS upstream kernels because enterprises use it ... your distro being a desktop focused thing probably wants the very latest cool kernel graphics improvements so you pick the latest tip kernel)15:47
ograi remember that when we started in 2004 there were not even upstream release schedules for most things ... Xorg, kernel, gnome ... all released on their own schedules and things were massively varying across distros ... that has changed over the years15:49
ograso it got a lot better already ...15:49
* zyga ran back to the office15:55
zygamy kids are behaving like crazy today15:55
zygadegville: hi, I sketched a small document for the new interface: https://forum.snapcraft.io/t/the-system-packages-doc-interface/1778816:00
zygaadvise and comments are appreciated16:00
mupPR snapd#8755 opened: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>16:13
* cachio lunch16:13
* zyga cachio: https://github.com/snapcore/snapd/pull/8755#pullrequestreview-419410456 (first comment is the one I'm interested in)16:37
mupPR #8755: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>16:37
jdstrandzyga: yes, the review-tools need a change (and snappy-debug). it is already on my todo16:48
jdstrandcc emitorino ^16:49
zygajdstrand: ack16:51
jdstrandpedronis: yep16:54
jdstrandpedronis: (security high and milestone)16:54
pedronisjdstrand: ack16:54
jdstrandit would be nice if the milestone was more prominent, but easy to see once know what to look for16:54
jdstrandfyi, there are no milestoned PRs waiting on us now16:54
jdstrandI'm continuing to go through the list though16:55
mupPR snapcraft#3146 closed: build providers: snap sw to channels if injecting <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3146>17:17
mupPR snapd#8756 opened: tests: skip interfaces-openvswitch for centos 8 in nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8756>18:02
mupPR snapd#8691 closed: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8691>18:07
mupPR snapd#8691 opened: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>18:12
* cachio afk19:06
* zyga EODs19:24
zygapedronis: https://github.com/snapcore/snapd/pull/8691#pullrequestreview-41954223019:31
mupPR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>19:31
* zyga really EODs :)19:31
mupPR snapd#8533 closed: image, tests: core18 early config <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8533>20:18
jdstrandijohnson (cc emitorino): fyi, https://forum.snapcraft.io/t/nvme-block-devices-support/17736/320:55
jdstrandijohnson: I'm also reviewing the PR and will comment there as well20:55
ijohnsonNice thanks jdstrand also FYI I'm off today/tomorrow21:00
* ijohnson will remember to silence IRC notifications next time :-) 21:00
jdstrandijohnson: enjoy your time off! you now have a short story to read :)21:00
jdstrandijohnson: not sure how much you like reading short stories on deep technical debugging :P21:01
jdstrandijohnson: sorry for the interuption21:01
diddledanI think we should ping ijohnson, too ;-p21:01
=== KindTwo is now known as KindOne
mupPR snapd#8751 closed: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8751>21:43
mupPR snapd#8752 closed: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8752>21:43
mupPR snapd#8754 closed: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8754>21:43
=== genii_ is now known as genii

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