zygaSooooo sleepy06:12
zygaHey mvo06:21
mvohey zyga06:22
mvozyga: if you adress the feedback from jamie in 6846, could you please force push so that I can cherry pick more easily?06:24
mupPR snapd#6843 closed: tests: avoid removing snaps which are cached to speed up the prepare on boards <Simple πŸ˜ƒ> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6843>06:25
mborzeckizyga: mvo: hey06:25
mvohey mborzecki06:28
mupPR snapd#6831 closed: tests: retry govendor sync <Simple πŸ˜ƒ> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6831>06:32
zygalow hanging fruit: bump the delta tag please06:44
zygahttps://github.com/snapcore/snapd/pull/6855 is a bit big06:45
mupPR #6855: overlord: implement store switch remodeling  <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6855>06:45
mupPR snapd#6846 closed: cmd/snap-confine: unshare per-user mount ns once <Bug> <Simple πŸ˜ƒ> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6846>06:45
mvozyga: I cherry picked 684606:47
zygaThank you06:47
zygaI'm still working on the main dish06:47
=== pstolowski|afk is now known as pstolowski
zygahey pawel07:09
pedronismvo: hi, the PR to do store switch remodeling is up, some TODO related to conflicts, but otherwise is all there. Re-reg is a bit more complicated but not complex, needs the dedicated context and a new task kind.07:25
pedronisPRs are a bit big though (espcially tests) might need splitting.07:26
pstolowskimvo: hey, thanks for moving our 1-1!07:26
mvopstolowski: is that time ok? I'm relatively flexible thanks to mborzecki who also moved the meeting :)07:51
pstolowskimvo: yes, it's perfect!07:52
mupPR snapd#6854 closed: cmd/snap-update-ns: rename applyFstab to executeMountProfileUpdate <Simple πŸ˜ƒ> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6854>07:52
mvowe are below 60 again!07:53
mupPR snapd#6851 closed: cmd/snap: mangle descriptions that have indent > terminal width <Simple πŸ˜ƒ> <⚠ Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6851>07:53
Chipacamoin moin07:56
pstolowskihey Chipaca07:58
mupPR snapd#6856 opened: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>07:59
mupPR snapd#6850 closed: gadget: add volume level update checks <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6850>08:02
mborzeckianother one lands :)08:02
mupPR snapd#6857 opened: gadget: record sector size in positioned volume <Gadget update> <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6857>08:08
mborzeckiand one more up /o\08:08
mborzeckioff to school, back in a bit08:09
zygamborzecki: thank you08:14
zygaman, I needed this coffee08:16
Chipacapedronis: you around?08:39
pedronisChipaca: yes08:44
Chipacapedronis: wrt health-checks, is there anything you'd rather see up in a pr next?08:44
pedronisChipaca: did you push one already?08:45
Chipacapedronis: just the draft one08:45
Chipacapedronis: working on the tests still08:45
pedronisChipaca: is it too big?08:45
Chipacapedronis: no i don't think so08:45
pedronisI'm not sure I understand the question08:46
Chipacapedronis: the pr that is up, that i expect to finish today while you're travelling, covers only a small portion of the feature08:48
Chipacapedronis: so, what should i work on once that is 'done' (code complete)?08:49
pedronisChipaca: the PR runs the hook and let the hook set the health, right?08:49
Chipacapedronis: yes, post-refresh08:49
Chipacaor post-install08:50
Chipacai mean it doesn't do the pre-refresh nor the on-demand, nor the info, nor the list08:50
pedronisI think the next bit is snap info08:50
Chipacaokie doke08:50
pedronisnow that I understand the question08:50
* Chipaca is always very clear08:50
Chipacapedronis: and after that? (being optimistic here)08:51
pedronisregular running of the hook?08:52
pedronisand then the pre refresh one we need to think a bit, we can run it but we wouldn't do much with, would we?08:52
pedronisso it well might be on-demand08:53
pedronisI expect on-demand to be a bit complicated, to do the UX as we discussed it08:53
pedronisbecause we don't have anything quite like that08:53
zygawhat are you discussing? it sounds curious08:54
pedronishealth checks08:54
pedronisor you mean the last bit in particular?08:54
pedronisthe last bit is about snap health and returning info to the user for each snap as soon as it is available08:54
zygaabout on-demand things, I was wondering if there's some new functionality in hooks that is planned08:55
pedronisdon't think is about hooks08:55
pedronisit's more about how we return results08:55
pedronisfrom API08:55
pedronisbut it depends exactly how we implement it08:56
pedronisChipaca: so, info, regular,  on-demand08:59
Chipacapedronis: regular as in on-a-timer?09:00
pedronisChipaca: that part of the spec that says we run them (probably triggered from ensure) at given interval,09:01
pedronismore often if unhealthy09:01
pedronisthere are some fun issues there to, but we can have a general sketch of that before digging09:03
pedronis*there too09:03
mupPR snapd#6858 opened: cmd/snap: unit tests for debug timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6858>09:06
zygamborzecki: not sure if intersects with your work09:13
zygarunning snapd a while prints this a loooot09:13
zygamaj 10 11:00:53 yantra snapd[57785]: kernel_os.go:198: cannot get boot settings: cannot determine bootloader09:13
Chipacapstolowski: "(and optionally the)" because code is optional!09:32
* pedronis starts early travel to Lyon09:36
pedronishave great day and weekend!09:36
zygapedronis: see you soon :)09:36
zygapedronis: I'm going through geneva09:36
zygapedronis: perhaps we might even share a train ride09:37
pedronismaybe, depends on times, but will do geneva -> Lyon on Sunday09:37
zygasame like me09:37
pedronisat some point09:37
mupPR snapd#6751 closed: overlord/snapstate: perform hard refresh check <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6751>09:47
Chipacawhat was the right name for 'sideloads'?10:10
zygaChipaca: none :)10:10
zygasnap install from a file?10:10
Chipacaunsigned? unverified? unpotatoed?10:10
Chipacaunasserted, thanks10:10
zyganote, I just made that up10:10
zygabut it sounds okay :)10:10
Chipaca'twas that afair10:11
mupPR snapd#6853 closed: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helper… <Simple πŸ˜ƒ> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6853>10:20
mvosecond review for 6793 would be nice (maybe mborzecki because he already did a first pass :) ?10:22
zygamvo: mborzecki will be back in half an hour10:25
zygamvo: can I help10:25
zygamvo: I ran into another bug, don't understand it yet, looks related to recent changes10:26
zygamvo: snap-confine cannot open the base directory in /tmp10:26
zygadebugging now10:26
pstolowskimvo: https://github.com/snapcore/snapd/pull/6823 can land?10:32
mupPR #6823: packaging: build empty package on powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/6823>10:32
mvopstolowski: if it has two reviews I think it can land10:32
mvozyga: oh, where do you see this bug?10:32
zygamvo: when developing on opensuse10:33
zygamvo: just added debugging, hold on10:33
zygait's odd, I didn't see it before10:33
pstolowskimvo: 2nd review is from vorlonofportland10:34
mvopstolowski: aha, indeed, then yeah, lets merge it10:34
mupPR snapd#6823 closed: packaging: build empty package on powerpc <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6823>10:35
mvopstolowski: thank you! I also cherry-picked it into 2.3910:37
pstolowskiChipaca: 6803 has a few conflicts10:39
mvo6795 also needs a second review, should be an easy win10:41
pstolowskimvo: i've merged #6811 but we need to ping Sergio re your question about if it needs to go to 2.3910:45
mupPR #6811: tests: make create-user test support managed devices <Simple πŸ˜ƒ> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>10:45
mvopstolowski: indeed10:45
mvopstolowski: thank you!10:45
mupPR snapd#6811 closed: tests: make create-user test support managed devices <Simple πŸ˜ƒ> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>10:45
zygaI need a break10:50
zygamvo: I think master may be broken10:50
zygamvo: the /tmp changes affecte stuff that is only picked up by tests running as user10:50
zyganot fun10:50
zygaanyone can run edge and say if stuff is falling apart?10:50
zygabut first10:51
zygait's so odd11:00
zygasomething must have landed11:00
mvozyga: I just refreshed my bionic to edge and ran hello-world11:00
mvozyga: seems to be fine11:00
mvozyga: hold on, that was core not the snapd snap11:01
zygaperhaps it's something in my setup11:02
* zyga explores11:02
zygaso I get permission denied11:02
zygabut it doesn't seem like apparmor11:02
* zyga rechecks11:02
mvozyga: on my system(s) things seem to be ok - at least with test-snapd-tools.echo11:03
zygathanks for checking11:03
zygamvo: what are the permissions on /tmp/snap.test-snapd-tools?11:03
sparkiegeekis there a potential for a race when 'snap install thing-with-home-interface', then running thing-with-home-interface and expecting :home to be connected?11:06
popey_Wimpress: mvo: Chipaca you guys around for catch up at half past?11:06
sparkiegeekInterface  Plug                        Slot  Notes11:06
sparkiegeekhome       documentation-builder:home  -     -11:06
sparkiegeektrying to work out how that happened, in a fresh LXD container, immediately after 'snap install documentation-builder'11:06
zygasparkiegeek: odd, is core or snapd installed?11:07
mvozyga: drwx------ 3 root root 4,0K Mai 10 13:00 /tmp/snap.test-snapd-tools11:08
sparkiegeekzyga: good question, this is repeatedly happening in aforementioned container - in a test run, so can add debugging but loop is longer than I'd like11:08
zygamvo: thanks11:08
mvopopey_, Wimpress, Chipaca I'm around but I would not mind skipping given that we meet in lyon next week anyway11:08
zygamvo: for me it is root.users!11:08
zygamvo: whaaat?11:08
* zyga inspects11:09
zygamvo: can you remove that11:09
zygaand run it again11:09
zygaand see if that fails?11:09
zygamvo: I think I know what's wrong11:10
zygamvo: look at https://github.com/snapcore/snapd/pull/6714/files11:10
mupPR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>11:10
zygamvo: you don't see it on debian11:10
zygasee that code that changes groups?11:10
mvozyga: yes11:11
zygaI think we need that now11:11
zygawhat's the permission of /usr/lib/snapd/snap-confine?11:11
popey_mvo: ok, that's cool11:11
mvozyga: -rwsr-sr-x 1 root root 99K MΓ€r 15 20:54 /usr/lib/snapd/snap-confine11:11
zygamvo: also in snapd.snap11:11
mupPR snapd#6857 closed: gadget: record sector size in positioned volume <Gadget update> <Simple πŸ˜ƒ> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6857>11:12
* zyga is confused11:12
zygamvo: thank you11:12
mvopopey_: cool, declined it now11:13
sparkiegeekzyga: appears to be neither core nor snapd, but our good friend core1811:13
zygasparkiegeek: that's a known bug11:13
* zyga looks for the bug URL11:13
popey_bug 181931811:13
mupBug #1819318: no interfaces when installing only core18 <snapd:In Progress by zyga> <https://launchpad.net/bugs/1819318>11:14
sparkiegeekzyga: ok, and workaround is to ... manually install core too?11:14
mvosparkiegeek: yes, this will be fixed in 2.39 (which is in candidate already and should go to stable early next week)11:15
mvosparkiegeek: sorry for the trouble11:15
sparkiegeekmvo: np. Due to a separate SNAFU that took me out all of yesterday, glad to finally be able to get debugging on this and look under the curtain, happy it's a known issue11:16
mupPR snapd#6795 closed: cmd,sandbox: tweak seccomp version info handling <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6795>11:24
sparkiegeekis there a 'grep-friendly' way of determining if I'm hitting ^ that bug. i.e. snap connected documentation-builder | grep -v ':home' || snap install core ?11:27
zygasparkiegeek: just snap list is sufficient11:27
zygasparkiegeek: then snap connections will show you there are no slots11:27
sparkiegeekzyga: right, just trying to build a snippet in a Makefile to workaround the bug if I need to, but don't install core if the interface is connected11:28
zygamborzecki: hey, do you want to repeat our experiment?11:54
zygamborzecki: I'm stuck, perhaps you will just see what's obviously broken11:54
zygamvo: or you perhaps?11:56
mborzeckizyga: in 5? i'm finishing reading through pstolowski's pr12:00
mupPR snapcraft#2500 closed: cli: add remote build <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2500>12:08
zygaChipaca, pstolowski: saving data of multipass, on removal, is loooong12:10
zygaChipaca: curious, how do we remove snapshots?12:11
Chipacazyga: snap forget12:11
pstolowskizyga: uhmmm.. it can be disabled12:11
zygacan I forget all snapshots of a given snap?12:11
Chipacazyga: yes12:11
Saviqcachio: hey, any chance for a fedora-30 image please? :)12:11
Chipacazyga: not easily tho :-|12:12
Chipacazyga: maybe we should add that, although it'd be tricky12:12
zygaChipaca: I noticed12:12
zygagiven that the things are called NNN_$SNAP_NAME_*12:12
zygais that enough of a hint?12:13
zygaChipaca: can I just rm them manually?12:13
Chipacazyga: snap saved thesnap | <some magic> | xargs snap forget {} thesnap \;, or something12:13
zygaor is there state12:13
Chipacazyga: there is no state12:13
zygaoff they go :)12:13
Chipacathat was part of the design of snapshots12:13
zygathough for usability12:13
zygakilling snapshots of a snap12:13
zygavery likely useful12:13
Chipacazyga: there is state about auto-snapshots, but it shouldn't break anything if it tries to remove them and they're gone12:14
Chipacazyga: file bugs if it breaks and eats your thesis12:14
zygawho knew12:15
zygasudo has --background and --command-timeout options12:15
Chipacashould we add a --purge to snap remove to mean "don't auto-snapshot"?12:15
zygaChipaca: yeah12:15
zygafeels like something I'd do in tests12:15
zygaour tests don't have much data but removing multipass hit my fans running12:15
Chipacapstolowski: wtyt?12:15
pstolowskiChipaca: +1 to 'snap remove --purge', i like that. gives more control than all-or-nothing flag we have now12:18
Chipacawe should either put up a pr, or write something in the forum, before we forget12:19
Chipacame, i'm going to have lunch12:19
* Chipaca prioritises like a baws12:19
=== ricab is now known as ricab|lunch
cmatsuokamborzecki: PR #6849 failed some integration tests12:25
mupPR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>12:25
Saviqmborzecki: it's != its ;)12:33
mupPR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>12:33
zygamvo: mystery solved12:38
mborzeckiSaviq: duh, missed that, thanks for spotting12:41
mborzeckipstolowski: May 10 12:01:02 may101137-895818 nsenter[32024]: retry.go:120: DEBUG: Retrying because of temporary net error: &net.OpError{Op:"dial", Net:"tcp", Source:net.Addr(nil), Addr:net.Addr(nil), Err:(*net.DNSError)(0xc00006c5c0)}12:44
mborzeckiwe're logging the error as #+v ?12:45
pstolowskimborzecki: %#v, yes12:47
pstolowskithis is Debug though12:48
mborzeckipstolowski: yup, so probably fine12:51
pstolowskimborzecki: yeah, an it helps understand error conditions better if we need to peel them :}12:56
cachioSaviq, sure, I'll try today12:57
mvozyga: what is the mystery?12:58
pstolowskicachio: hey, can you take a look if that PR that we landed today needs to go to 2.39? https://github.com/snapcore/snapd/pull/681113:00
mupPR #6811: tests: make create-user test support managed devices <Simple πŸ˜ƒ> <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6811>13:00
mupPR snapd#6793 closed: cmd/snap: support for --ensure argument for snap debug timings <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6793>13:04
pstolowskiChipaca: so, i'll create forum topic re --purge and do impl sometime next week13:39
Chipacapstolowski: <313:39
pstolowskidegville: btw, we need to update documentation with automatic snapshots; is it ok if i send you a short description of it, and you flesh it out/reword and put in a proper context of existing doc?13:45
=== ricab|lunch is now known as ricab
degvillepstolowski: absolutely, yes, of course.13:49
mvoChipaca: I couldn't help it and de-conflicted 680313:54
mvoChipaca: hope you don't mind13:54
Chipacamvo: HULK SMASH13:54
Chipacamvo: sorry, i meant "thank you"13:55
Chipacamvo: typo13:55
* mvo hugs Chipaca 13:57
mupPR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>14:17
mupPR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>14:17
mupPR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>14:17
mupPR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>14:18
mupPR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>14:18
mupPR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>14:18
cachiomborzecki, zyga if you could take another look to #6541 should be great, thanks14:43
mupPR #6541: tests: change how xdg-desktop-portal is prepared and restored for desktop-portal-* tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>14:43
mborzeckicachio: ok14:43
cachiomborzecki, thanks14:43
pstolowskiChipaca: https://forum.snapcraft.io/t/automatic-snapshots-snap-remove-purge-proposal/1129415:01
* Chipaca reads15:01
Chipacapstolowski: thank you15:02
pstolowskicmatsuoka: almost forgot - safe travels!16:15
cmatsuokathanks! :)16:15
=== pstolowski is now known as pstolowski|afk
cachiopstolowski|afk, hey16:31
pstolowski|afkcachio: hey16:32
cachioI have few issues with core16:32
cachiofor example sudo usermod -a -G dialout user116:32
cachiodoes not work16:32
cachiopstolowski|afk, https://paste.ubuntu.com/p/DdZsrRCxnB/16:33
cachiois it required on core?16:33
pstolowski|afkcachio: dialout is the group owner of serial ports by default; it's needed to actually access serial ports in nested vm (because we log as regular user, not root). you can skip it but the test will need to be much simpler (no tests for actual writing to the port)16:39
pstolowski|afkcachio: but as discussed that's fine, we should start with a much simplified test16:39
cachiopstolowski|afk, ok16:41
pstolowski|afkcachio: don't worry too much about actual test, i can work on tweaking it further. just plugging in the qemu virtual serial adapter + checking if slot was created succesfully will be enough16:42
cachiopstolowski|afk, ok,16:43
cachioand at which point the test should fail?16:43
cachiocurrently on core16 when I list connections the16:43
cachioqemuusbserial doesn't exist16:43
cachiothis is not matching at all --> execute_remote "snap connections system" | MATCH "serial-port .* - .* :$SLOT_NAME"16:44
cachiobut /dev/ttyUSB0 exists16:45
pstolowski|afkcachio: it's on official core16?16:47
cachiocore 2.38.116:47
cachiothe stable one16:47
cachioit created an image on nested vm16:48
pstolowski|afkcachio: right. yes, so you won't see the slot there because hotplug changes for serial-port interface didn't land16:48
cachiomakes sense16:48
pstolowski|afkcachio: so the test will fail as soon as we check snap intrfaces, expecting the slot to be there16:48
pstolowski|afkcachio: if you see ttyUSB0 then it's good, qemu works as expected with core \o/16:49
cachiopstolowski|afk, ah, nice16:49
cachioI'll recheck on core18 and I'll create a PR so next week we can test it once the change is landed16:49
cachiopstolowski|afk, thanks16:50
pstolowski|afkcachio: np, ty! i'm signing off for this week, see you!16:50
cachiopstolowski|afk, sure, enjoy your weekend16:50
mupPR snapcraft#2541 closed: Desktop meta: strip ${SNAP} from .desktop icon <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2541>16:57
dcarmichWhen I try to run classically-confined snaps on a Salt-managed Linux system as a user, I get the error: "cannot create user data directory: /Users/username/snap/(name of snap)/version: not a directory". However, when I install them on a stock Ubuntu 18.04 VM, they run just fine as a user. Is there a specific security setting I should look for that is causing this issue?17:46
dcarmichI'm using snap version 2.38+18.04 on Ubuntu 18.04 LTS.17:46
cmatsuokaniemeyer: we managed to remove adapter:full, using adapter:none now18:13
mupPR snapcraft#2562 opened: extensions: add KF5 Neon extension <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2562>18:45
cachioSaviq, hey, image fedora-30-64 ready19:15
cachioI had to fix some issues with google packages19:16
cachiobut right now it is working19:16
cachiojust replace tha name you have set for fedora-29 and that should work19:16
mupPR snapd#6859 opened: tests: new hotplug test executed on ubuntu core  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6859>21:07
* cachio EOW21:15
mupPR snapd#6860 opened: tests: running tests on fedora 30 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>21:17

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