/srv/irclogs.ubuntu.com/2019/08/27/#snappy.txt

zygagood morning06:19
zygaarnatious: hey, can you tell me how you created the container and where is it running?06:20
zygaarnatious: host info, lxd version, container info, etc06:20
mvohey zyga06:21
zyga:)06:21
zygahow are you doing?06:21
zygamvo: back to fighting that user test?06:22
zygamvo: meanwhile: https://github.com/snapcore/snapd/pull/7337 is simple and green06:22
mupPR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>06:22
zygaif you agree it is simple, that is :)06:23
mvozyga: yeah, that and one more flaky one06:23
AavarWhere is my config stored when using irssi as a snap?06:23
zygaI had a look at the two leaking lets that are on core06:24
zygaAavar: most likely in ~/snap/irssi/current/.irssi06:24
mvozyga: looking at the prs now06:24
zygamvo: and one of them was very puzzling, the one I pasted last night06:24
zygabut I'll re-read that with fresh minnd06:24
zyga*mind06:24
zygathe pastebin is https://paste.ubuntu.com/p/Pdx9qmqbdH/06:24
zygamvo: btw, one surprise from yesterday is ordering of prepare calls06:26
zygamvo: prepare-project-each is before prepare-suite-each06:26
zygaI was somewhat assuming that prepare-project-each is like prepare-task-each which doesn't exist06:26
zygamvo: in that pastebin I linked to the part I don't understand is where did the revision 1001 and 1002 come from06:27
zygawhere normally the revision map shows 36 and similar numbers06:27
mvozyga: from our fake store maybe?06:31
mvozyga: just guessing at this point, we setup a fake store for some tests06:31
zygaAhhh, interesting. That must be it! Thank you06:33
zygahey pedronis06:48
zygaI'm just looking at unit test failure in one of your PRs06:48
zygahttps://www.irccloud.com/pastebin/CKcptuEn/06:48
zygaI've seen this a few times recently06:48
pedronisweird error, I wonder why is not deterministic06:50
pedronisanyway I'm working in that area06:50
zygathanks :)06:50
pedronisso don't think you should spend time on it06:50
zygaok06:50
zygaI'll focus on review06:50
zygapedronis: https://github.com/snapcore/snapd/pull/7329 can land, I think06:51
mupPR #7329: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>06:51
mupPR snapd#7329 closed: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7329>06:51
=== pstolowski|afk is now known as pstolowski
pstolowskihello06:59
zygagood morning :)07:00
mvohey pstolowski - goooood morning :)07:00
mupPR snapd#7340 closed: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7340>07:09
mvozyga: 7338 has conflicts07:14
mupPR snapd#7339 closed: tests: don't look for lxcfs in mountinfo <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7339>07:14
zygamvo: on it07:16
zygadone07:16
mupPR snapd#7335 closed: tests: add check for snap_daemon user/group <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7335>07:17
zygapedronis: https://github.com/snapcore/snapd/pull/7323 is something you should review I think07:19
mupPR #7323: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>07:19
zygait deals with feature flags and startup behavior07:19
pedronisadded to my list07:20
pedroniszyga: that failing test is weird07:20
pedronisit's broken by design07:21
pedronisbut a bit unsure why it fails only rarely07:21
zygathose kinds are most interesting :)07:21
pedronispstolowski: did you add the MissingBase test to first boot stuff?07:25
pstolowskipedronis: checking07:27
pstolowskipedronis: yes, TestPopulateFromSeedMissingBase07:30
pedronispstolowski: something is odd with it07:30
mvozyga: 7336 should be an easy review07:30
pedronispstolowski: unasserted goes into seed.yaml, not the snap07:30
pedronisbut is working anyway, most of the time07:30
pedronisbut sometimes it fails07:30
zygamvo: mhm07:30
pedronistrying to understand why07:30
pedronispstolowski: anyway, mostly pointing out that unasserted: true is in the wrong place07:31
zygamvo: +107:31
* zyga reviews https://github.com/snapcore/snapd/pull/731307:31
mupPR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>07:31
pstolowskipedronis: hmm, sorry about that, shall i investigate?07:34
pedronispstolowski: no, I'm looking into it07:35
pstolowskiok, thanks07:40
Aavarthank you zyga ;)07:43
zygaAavar: for what? :)07:47
pedronispstolowski: here's the cleanup/fix, fyi:  https://github.com/snapcore/snapd/pull/7341/commits/709e0bd10c78fc74334d7660c7549647d04d523207:51
mupPR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>07:51
pedronispstolowski: it was creating variant of local both unasserted and asserted (under the foo* stuff), and sometimes they diverged (not sure why)07:56
pedronispstolowski: anyway, a bit of confusion all around there :)07:57
pstolowskipedronis: aaah i see07:58
mupPR snapcraft#2688 closed: Build base types <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>08:12
zygapedronis: https://github.com/snapcore/snapd/pull/7313#pullrequestreview-28001111208:13
mupPR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>08:13
zygamvo: hey08:15
zygamvo: look at this:08:15
zyga+ getent passwd snap_daemon08:15
zygasnap_daemon:x:584788:584788::/nonexistent:/usr/bin/false08:15
zygamvo: full log https://api.travis-ci.org/v3/job/576917244/log.txt08:15
zyga2019-08-27 07:47:28 Error restoring google:arch-linux-64:tests/main/system-usernames-illegal :08:15
zygaalso suspicious there08:16
zyga+ snap remove test-snapd-illegal-system-username08:16
zygasnap "test-snapd-illegal-system-username" is not installed08:16
zygatypo?08:16
zygamvo: this was in https://github.com/snapcore/snapd/pull/731608:16
mupPR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>08:17
* zyga reviews https://github.com/snapcore/snapd/pull/734108:17
mupPR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>08:17
mupPR snapd#7344 opened: snapstate: use strutil.VersionCompare() in checkVersion() <Created by mvo5> <https://github.com/snapcore/snapd/pull/7344>08:21
mupPR snapd#7333 closed: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7333>08:22
mupPR snapcraft#2689 opened: schema: kernel and snapd types do not use bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2689>08:24
mvozyga: nice, thanks, let me check08:24
mvozyga: so the catcher of the test thing did find something08:24
zygaindeed08:24
zygalook at the log in detail, I'm sure there's something there that's useful08:24
mvozyga: yeah, look08:25
sergiusensxnox: mvo does `type: kernel` always require a base or will any kernel snap work with any base?08:25
sergiusensmvo: pedronis and from last week, do we want the `type: snapd` to NOT specify a base or do we want it to specify a base (even if none or bare)? (unrelated to using a build-base)08:27
mvosergiusens: I think we do not need a base for snapd, its self contained08:29
mvosergiusens: the kernel is tricky, if it uses hooks it needs a base so that we know how to run the hooks08:29
mvohey Chipaca, good morning!08:30
Chipacamvo: 👋 !08:30
mvoChipaca: can I pester you with a question already?  I got:08:30
mvo$ snap switch test-snapd-assumes --edge08:30
mvo"test-snapd-assumes" switched to the "edge" channel08:30
mvoChannel edge for test-snapd-assumes is closed; temporarily forwarding to candidate.08:30
mvoChipaca: today which is a bit odd because the edge channel is open (and was open at the time of this message). does that ring any bells?08:30
Chipacamvo: was this in a spread test, or somewhere you have debug logs?08:31
Chipacahuh08:32
mvoChipaca: I ran this manually, was doing some exploring about "assumes:" this morning08:32
Chipacait's reproducible08:32
mvocool!08:32
mvozyga: this is a fun issue, the logs show that the snap_daemon user is added *before* test-snapd-illegal-system-username is POSTed to the daemon. very puzzling08:33
zygaPOSTed?08:34
zygaas in installed?08:34
zygawhaat?08:34
zyga:D08:34
zygamvo: I'll be back soon, let me make some tea08:34
mvozyga: yeah, at least if the journald logs are in order08:35
mvozyga: yeah, no worries, just wanted to share my puzzlement08:35
Chipacamvo: is 381b45e27773eff87bca4f8ed9b96d027bfb8ee5 part of 2.41~pre1 ?08:36
Chipacamvo: i suspect that's the issue08:36
mvozyga: found the issue, its "fun"08:38
mvoChipaca: let me check08:38
mvoChipaca: it is part of 2.41 it seems :/08:39
Chipacamvo: maybe we should back that out until we have time to fix it08:39
mvoChipaca: could we just revert it in 2.41?08:39
mvoChipaca: yeah, I think that makes sense08:40
zygamvo: oh08:40
zygamvo: tell me :)08:40
mvozyga: pr will be up shortly but its easy once spotted08:42
pedroniszyga: I tried to answer to some of your model assertion comments08:42
zygapedronis: thanks, let me look08:42
sergiusensmvo: so for kernel we will require a base for now (it can be bare)08:44
zygapedronis: I replied to some but it all makes sense08:44
zygapedronis: LGTM and iterate or iterate and LGTM, as you prefer :)08:45
mupPR snapd#7345 opened: overlord/devicestate,seed:  small step introduce seed.LoadAssertions and use it from firstboot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7345>08:50
mupPR snapd#7346 opened: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>08:51
=== Greyztar- is now known as Greyztar
mvozyga: ^- thats the one08:51
zyga /o\08:51
zygamvo: did we ship this?08:53
mvozyga: yeah, also kind of annoying that we overlooked this in the code review08:53
mvozyga: well08:53
zyga:E08:53
mvozyga: its in beta08:53
zygamvo: should such usernames be made at the time the snap is linked?08:54
zygamvo: I'm looking at this now and it's unclear when this runs08:54
pedronisit runs early but this usernames are shared08:55
pedronisso they will end up staying around either way08:55
pedronisin many cases08:55
zygapedronis: that's okay, I worry that the sequence now is [check-foo, check-users, check-bar]08:55
zygaand that check-bar fails but we already acted a little on the system, which feels wrong08:56
pedronisas I said, for the current one support user is ok08:56
pedronisbut when we add more we need to revisit this08:56
pedronisit probably merits a TODO in that PR though < mvo08:56
zygamvo: how is the patch making things better tough08:56
zygait's unclear to me08:56
pedroniswe either create all users or none08:57
pedroniswe might still fail to install the snap08:57
pedronislater08:57
zygaah, indeed08:57
pedronisbut given that the one support user08:57
pedronisis shared08:57
pedronisit's not too bad08:58
pedronisbut it might be worth revisiting at some point08:58
mvopedronis: indeed, let me add this todo08:58
mupPR snapd#7347 opened: gadget: do not error on gadget refreshes with multiple volumes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7347>09:17
zygamvo: multi volume as in multi partition?09:19
zygamvo: or multiple disks09:19
mvozyga: multiple disks09:20
zygamvo: do we have customers using that?09:20
zygaor is this just a precaution?09:20
mvozyga: we have customers using this and this is breaking ondra09:20
zyga+109:20
zygathanks for explaining09:20
zygamvo: left a suggestion, +1 anyway09:22
=== vicamo_ is now known as vicamo
popey_zyga: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500#1009:44
mupPR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>09:44
zygapopey_: looking09:44
popey_is that comment still accurate?09:44
zygaah that one09:44
zygait didn't move forward, we discussed accepting partial confinement with actual apparmor enabled but it was nacked for existing distributions09:45
zygaas we don't have the time to deal with regressions if that broke people09:46
zygathat's what the state of this is now09:46
popey_Worth updating the bug?09:46
zygait's not a great message but yeah09:46
zygaif only updating bugs in debian didn't involve email09:46
pedronismvo: approved #7346 with a comment09:51
mupPR #7346: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>09:51
mvopedronis: thanks, looking in a wee bit09:54
=== pedronis_ is now known as pedronis
* Chipaca takes a break10:05
arnatiouszyga: Container created on Ubuntu 18.04, LXD stable/3.16 snap, container config https://paste.ubuntu.com/p/JrcC89rwN2/10:05
mupPR snapd#7348 opened: snapstate,store: check assumes early before downloading the snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>10:16
mvoChipaca: bad news, it seems like reverting 7204 still gives the same error message, I can bisect10:25
Chipacamvo: rats10:26
Chipacamvo: is it actually a regression?10:26
mvoChipaca: not sure, let me try10:26
mvoChipaca: aha, I think I'm a muppet, hold on, let me retest this10:27
Chipacamvo: Rowlf?10:29
mvoChipaca: that sounds about right10:29
mvoChipaca: maybe "beaker" just needs to be renamed to "breaker"10:30
mupPR snapd#7349 opened:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/7349>10:33
mvopstolowski: your input here would be great :)10:33
Chipacamvo: https://www.youtube.com/watch?v=VnT7pT6zCcA10:35
pstolowskimvo: oh :( interesting, saying 'stable' instead will be confusing as well10:37
mvopstolowski: aha, this is latest/stale vs stable? the new default-channel stuff?10:45
mvoChipaca: lol - this is great - his expression matches my mood perfectly10:45
pstolowskimvo: yes... and with this revert we'll be showing *wrong* (imprecise/misleading) information when the snapd-side logic of keeping the track kicks in10:46
cachiozyga, hey, when you have time could you please take a look to #711010:47
mupPR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>10:47
cachiozyga, hope last one10:47
mvopstolowski: meh, ok10:48
mvopstolowski: so we need something else I guess :/10:48
mvopstolowski: there is a spread test in there that might be useful10:48
mvopstolowski: the other parts can probably be removed then10:48
=== alan_g_ is now known as alan_g
pstolowskimvo: thanks, +1 and i'll work on this soon10:51
mvopedronis: I updated 7346 with a unit test, thanks for the suggestion!10:55
zygacachio: in an hour10:55
cachiozyga, sure, thanks10:55
mvopedronis: would love your opinion on 7348 too :) but no rush11:08
pedronismvo: finishing lunch break11:09
mvopedronis: yeah, no rush, I will soon have lunch too - I was just surprised how small it was11:10
pedronismvo: commented11:17
mupPR snapd#7350 opened: tests: clean snap_daemon user and group on system-usernames-illegal test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7350>11:19
mupPR snapd#7351 opened: tests: retry checking until the written file on desktop-portal-filechooser <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>11:47
xnoxsergiusens:  at the moment, `type: kernel` works with any bases, but which base is used matters. As initramfs.img is build with binaries from the base. Thus one should be specified, and it does matter if it's core16, core18, or core20 cause then the initramfs.img has libc6 and etc. from those matching releases xenial / bionic / $devel11:52
zygare11:58
pedronisxnox: the plan is that kernels should use/specify build-base:  not a base:12:07
xnoxpedronis:  yes, that is good. initramfs.img is self contained / can be used by anyone...... but it matters what it is built out of. More like "Built-Using: bionic" in "dpkg speak", despite having no "Depends:".12:09
mupPR snapd#7346 closed: snapstate: validate all system-usernames before creating them <Test Robustness> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7346>12:20
=== ricab is now known as ricab|lunch
mupPR snapd#7352 opened: tests: always say 'restore: |' <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7352>12:37
zygaare draft branches visible by default?12:38
zygaI meant draft PRs12:39
zygahttps://github.com/snapcore/snapd/pull/7337 needs a 2nd review12:44
mupPR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>12:44
pstolowskijdstrand: hey, one correction to what i said yesterday: i was wrong when i said 'snap connect' could also be optimized for multiple connections at once like i did with automatic connections, i misremembered the code that resolves plug/slot names for connect (was thinking we can resolve multiple plugs/slots if you omit connect arguments, but we only resolve a single plug/slot if you omit them)12:45
ijohnsonhas anyone seen debian-sid-64 fail to prepare like this: https://pastebin.ubuntu.com/p/GQjg4jK4rw/ ?12:52
ijohnsonI've seen it fail to prepare on numerous builds now and it doesn't look like a transient error12:53
mupPR snapd#7353 opened: tests: simplify interfaces-account-control test <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7353>12:53
mupPR snapd#7354 opened: tests: rename fuse_support to fuse-support <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7354>12:55
mupPR snapd#7355 opened: [RFC] interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>13:00
Chipacaaugh, 2fa13:01
mupPR snapd#7110 closed: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>13:04
=== alan_g_ is now known as alan_g
=== ricab|lunch is now known as ricab
jdstrandpstolowski: thanks. it sounded like an exciting feature that I missed :)13:55
pstolowskijdstrand: :)14:11
mupPR snapd#7352 closed: tests: always say 'restore: |' <Simple 😃> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7352>14:14
zygawhy does it have to be so hot14:17
mupPR snapcraft#2674 closed:  file_utils: introduce link_or_copy_files <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2674>14:27
mupPR snapd#7203 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7203>14:46
pstolowskiChipaca: i'm working on a fix for the confusing snap switch message ("Channel %s for %s is closed; temporarily forwarding to..) caused by my #7204; i don't understand the logic of this temporary forward meesage but i assume it's fine to simply skip it for op = "switch" in showDone(), this will basically make "switch" behave as before, modulo the new track/risk behavior that will be shown correctly (thanks to14:48
pstolowskishowDone)14:48
mupPR #7204: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7204>14:48
pstolowskiChipaca: sounds sensible?14:48
Chipacapstolowski: sounds like the quickest way forwards yes14:48
Chipacathe logic probably assumes 'refresh'14:48
=== ricab is now known as ricab|brb
pstolowskiChipaca: ok, thamks14:51
pstolowski*thanks14:51
mupPR snapd#7356 opened: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7356>14:53
zygapstolowski: could you please do a pass over the three simple PRs I have14:57
zygathey are all tiny and I'd love to merge them14:57
pstolowskizyga: sure15:01
zygathanks15:01
zygathere's one -0,+0 PR :D15:01
mupPR snapd#7357 opened: Fix snap switch message <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7357>15:01
pstolowskizyga: which one?15:03
zygapstolowski: 735415:04
mupPR snapd#7358 opened: Rename die() -> die_reboot() to fix build failures with LTO enabled <Created by dcermak> <https://github.com/snapcore/snapd/pull/7358>15:06
zygaChipaca: can you look at that, it looks good-ish but I'm worried about it slightly15:10
Chipacazyga: the switch one?15:11
zygano, the die one above15:11
pstolowskizyga: did two others, not sure if these were the ones you wanted first. let me know if you need any more15:12
zygapstolowski: that's great, thank you15:12
Chipacazyga: the intention was to use the same die from the lib, wasn't it?15:18
zygaChipaca: original intention or one in this PR15:25
cachiozyga, when you have time, could you please atke a look to #715915:25
zygaChipaca: the original die is not flexible enough15:25
mupPR #7159: tests: add functions to make an abstraction for the snaps <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>15:25
zygaChipaca: I'm looking at fixing that15:25
=== Luke_ is now known as Guest27501
cachiozyga, and this one also #7256 please15:26
mupPR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>15:26
=== Guest27501 is now known as Luke
zygacachio: ok15:30
cachiothanks15:30
zygacachio: does retry argument parsing really work correctly?15:31
zygacachio: "$@" is expanded once15:31
zygaand it contains all the stuff15:31
zygayou can look at "${1:-}", and while that is not empty parse arguments15:31
zygathe problem with this method is that it just zooms through all the arguments, shifting some (not the one looked at)15:31
zygaignoring things it doesn't handle15:32
cachiochecking15:32
zygacachio: please15:32
zygacachio: perhaps it's time to use python :)15:32
zygacachio: there it's trivial15:32
cachiozyga, works well15:34
cachiozyga, https://paste.ubuntu.com/p/R9mrmSBq65/15:34
zygacachio: what happens when you pass call retry rm foo --max-attempts 215:35
cachiofails15:36
zygacachio: but that's not how it was supposed to work15:36
cachioseq: unrecognized option '--max-attempts'15:36
zygacachio: the command was not supposed to be quoted15:36
zygacachio: you call it as retry rm -rf "$XDG"15:36
zygabut your example is different15:36
zygaI'm not super happy about the parser, I can fix it tomorrow morning15:36
cachiothat works15:37
cachiowhat fails is when you use --xx at the end15:37
cachiozyga, see that https://paste.ubuntu.com/p/XGNy3ZJRgx/15:38
zygacachio: what does shift shifts from?15:40
zygacachio: when you are mid-iteration in that for loop15:41
zygacachio: I thought that shift shifts from the left of the "$@" array15:41
pedronispstolowski: Chipaca: it was very weird that this was landed withotu spread tests: https://github.com/snapcore/snapd/pull/7199/files15:43
mupPR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>15:43
pedronispstolowski: Chipaca: we should add some15:43
pedronisboth for refresh and switch15:43
pstolowskipedronis: ok, i can work on it15:46
pedronispstolowski: I'm adding a card15:47
cachiozyga, don't get you15:47
zygacachio: what's the semantics of shift15:47
zygacachio: and how does it impact the loop15:47
zygacachio: if you have a loop that goes over 1 2 3 4 5 615:47
zygacachio: and you are at 315:48
zygacachio: what does shift do?15:48
pedronispstolowski: https://trello.com/c/6oPPAjLD/312-add-spread-tests-for-https-githubcom-snapcore-snapd-pull-7199-for-both-switch-and-refresh15:48
zygacachio: does it remove "3" or "1"15:48
zygacachio: I think the loop and the parser is incorrect15:48
cachiozyga, ok, let me check that15:48
zygacachio: I'm not sure if that's "standard" but when I'm doing shell parsing I'd using a while loop15:49
zygacachio: checking to see if there are more arguments in "$@"15:49
zygacachio: looking at the one up front15:49
zygacachio: handling it, shifting it away15:49
zygacachio: terminating argument parsing (typically on --)15:49
zygacachio: or reporting an error15:49
zygacachio: there are some helpers like getopt as well but those don't always have the right precision15:50
cachiozyga, https://paste.ubuntu.com/p/C94tCPm6F7/15:51
zygaChipaca: now swap retry argument order15:52
zygaer, cachio ^15:52
zygacachio: the parser is wrong because it shifts something else than it is looking at15:52
zygacachio: it shifts "$@" - aka the magic array15:53
zygacachio: it looks at an item out of a snapshot of that array15:53
cachiozyga, I dont see in which case it could fail15:54
cachiowhen we change the order of the parameters?15:54
zygacachio: yes, but it's more fundamental, it's just not right in what it is doing15:54
mvopstolowski: with 7357 - should I close 7349 ?15:55
cachiozyga, to fix that I should create another array and remove items instead of shift?15:56
zygacachio: I think you can use shift but you must look at the first element at all times15:56
zygacachio: not at the i-th element15:56
pstolowskimvo: if we are happy about resolution, yes15:56
zygacachio: but honestly, you can just drop the parsing entirely and hard-code those15:56
zygacachio: or just use python15:56
zygacachio: where such things are easier15:57
cachiozyga, rightin python is much easier15:57
mvopstolowski: I close mine for now then, I'm not sure I understand all the implications yet but it looks like your changes are small and targeted so hopefully15:57
mvopstolowski: hopefully all fine15:57
cachiozyga, I'll try that15:58
mupPR snapd#7349 closed:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7349>15:58
cachiozyga, thanks for reviewing the change!15:58
* cachio lunch15:59
zygacachio: sure15:59
mupPR snapd#7356 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7356>16:00
* zyga breaks to rest until the call later today16:04
mvozyga: thanks for holding the fort later!16:05
zyga:)16:07
=== pstolowski is now known as pstolowski|afk
pedroniscachio: this could land https://github.com/snapcore/snapd/pull/7259 but probably needs a master merge to get green16:25
mupPR #7259: tests: just build snapd commands on go-build test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>16:25
mupPR snapd#7260 closed: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7260>16:28
mupPR snapd#7338 closed: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7338>16:28
mupPR snapd#7353 closed: tests: simplify interfaces-account-control test <Simple 😃> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7353>16:28
cachiopedronis, merged, waiting for test results in green16:39
cachiopedronis, thanks16:40
mupPR snapd#7354 closed: tests: rename fuse_support to fuse-support <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7354>16:42
* ijohnson lunches, bbiab17:43
mupPR snapd#7359 opened: overlord/snapstate: check channel names on install <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>17:44
mupPR snapd#7337 closed: tests: re-enable mount-ns test on classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7337>18:11
=== Luke__ is now known as Luke
mupPR snapd#7259 closed: tests: just build snapd commands on go-build test <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>18:30
mupPR snapd#7360 opened: snap: use deterministic paths to find the built deb <Created by sergiusens> <https://github.com/snapcore/snapd/pull/7360>19:28
sergiusensmvo: https://github.com/snapcore/snapd/pull/7092#issuecomment-52544884819:29
mupPR #7092: packaging: use snapd type and snapcraft 3.x <â›” Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>19:30
sergiusensmvo: cachio I added a link to a built snapd there ... a comment yay or nay on the snapcraft PR mentioned there would be grand.19:30
cachiosergiusens, ok, thanks19:32
mupPR snapcraft#2690 opened: remote-build: error when --user is required <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2690>20:31
mupPR snapd#7361 opened: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>21:03
mupPR snapd#7362 opened: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>21:13
mupPR snapd#7363 opened: cmd/snap-confine: fix group and permission of .info files <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7363>21:17

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