/srv/irclogs.ubuntu.com/2019/11/19/#snappy.txt

=== jamesh_ is now known as jamesh
mborzeckimorning06:35
mborzeck2damn isp06:40
=== mborzeck2 is now known as mborzecki
mupPR snapd#7747 closed: gadget: skip fakeroot if not needed <Simple πŸ˜ƒ> <Created by cmatsuoka> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7747>07:33
zygahey07:38
mborzeckizyga: hey07:38
zygamborzecki: check out "Sourcetrail"07:38
zygait's FOSS just now07:38
zygapretty neat IMO07:38
mborzeckizyga: hmmm 'something went wrong'07:39
zygamborzecki: did you finish all of the HR training?07:39
mborzeckizyga: yup07:39
zygahttps://github.com/CoatiSoftware/Sourcetrail07:39
zygadid you have any issues?07:39
mborzeckizyga: with the hr training?07:39
zygaI had to re-do one from scratch because the in progress version was stuck on last page without ability to "sign" the result07:39
zygayes07:40
zygaI finished everything but more like at 1-2AM07:40
mborzeckizyga: so sourcetrail is like a better gnu global web mode?07:42
zygaI have no idea what that is07:44
zygahey mvo07:44
zygahow did you sleep?07:44
mvohey zyga ! much better. did stay up longer and had a relatively good sleep07:50
mvozyga: and you?07:50
mborzeckimvo: hey07:50
zygamvo: I managed to sleep at 2:30 - 3:00 AM07:51
zygabetter than yesterday for sure07:51
zygamvo: I shared this with Maciek earlier: https://github.com/CoatiSoftware/Sourcetrail07:52
zygait's neat, I played with it a little07:52
zygatheir website is slashdotted now07:53
zygabut should recover eventually07:53
mvozyga: 2:30am - 3:00 am ? that is still not great :/07:53
mvohey mborzecki07:53
mvozyga: oh, nice07:53
=== pstolowski|afk is now known as pstolowski
pstolowskimorning08:03
mvohey pstolowski ! good morning08:05
zygagood morning pawel08:06
mborzeckipstolowski:  hey08:07
zygamvo: I think I should take a swap day today08:32
zygamvo: yesterday was okay to "burn" the day on HR and some random reviews08:32
zygabut today I feel so tired and sleepy, in the morning, that I really think I need to just take it easy and sleep/rest all day08:32
zygaand not pretend to work effectively08:32
mvozyga: sure, thats fine08:33
Mirvif there's someone who is not really badly sleep deprived and has access to openSUSE Tumbleweed, please update to 20191116 and check if you can reproduce what I have bug #185311009:16
mupBug #1853110: On up-to-date openSUSE Tumbleweed all snaps show "broken" <snapd:New> <https://launchpad.net/bugs/1853110>09:16
zygaj,,09:16
zygahmm09:16
pstolowskiMirv: hey! yes i'm actually looking at it right now09:17
zygapstolowski: thank you09:18
pstolowski(it's my bug triaging day today)09:18
Mirvzyga: you are not counted into that someone according to log above :D take care.09:18
Mirvpstolowski: ok, thanks!09:18
zygathank you so much guys09:18
* zyga returns to cleaning the office 09:18
Mirvapparmor was updated but not sure what was changed https://lists.opensuse.org/opensuse-factory/2019-11/msg00264.html - that said, disabling apparmor does not seem to help me09:21
pstolowskiMirv: i'm installing tumbleweed atm as i don't have it handy09:21
zygapstolowski: it eats gobs of space09:22
zygapstolowski: using btrfs and snapshots09:22
zyganot very vm friendly09:22
zygayou may want to disable snapper (snapshot thing)09:22
Mirv..or just select ext4 for everything in advanced setup instead of btrfs09:23
pstolowskizyga, Mirv good to know, thanks, yeah, too late to change fs, will look at disabling later09:33
mvoa second review for 7745 would be great09:49
mvoshould be simple and will unblock 774609:50
zygamvo: let me do it09:50
Mirvpstolowski: so for example I've rocketchat-desktop installed, and with sudo mount /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt I get: mount: /mnt: mount failed: Operation not permitted.09:52
MirvI wish there was something meaningful in some log, but I can't find any09:52
zygaMirv: look at audit log09:54
zygaMirv: /var/log/audit/audit.log09:54
MirvI tried, but I did not find other than "ype=AVC msg=audit(1574157270.914:590): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.signal-desktop.signal-desktop" pid=7789 comm="apparmor_parser"" type of messages09:56
zygathat's odd09:58
pstolowskiMirv, zyga: i cannot reproduce the exact mount issue, but something is definately broken. all snaps get mounted, also after reboots. but i can get a snap to run only after i install it, and until reboot. after reboot i get "cannot change profile for the next exec call: No such file or directory09:59
pstolowskisnap-update-ns failed with code 1: File exists" for all snaps09:59
zygapstolowski: did you enable snapd.apparmor.service?09:59
pstolowskiprofiles seem to be in place, snaps mounted09:59
zygait's part of the install docs09:59
pstolowskiah, i missed that10:00
zygamvo: https://github.com/snapcore/snapd/pull/7745#pullrequestreview-318910411 + 110:00
mupPR #7745: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7745>10:00
mupPR snapd#7745 closed: snap-bootstrap: add go-flags cmdline parsing and tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7745>10:01
mvozyga: thank you!10:02
pstolowskizyga: right that was it10:04
mvoalso 7712 needs a second review (a bit more work but really important to move forward with uc20)10:05
pstolowskiMirv: ok, cannot reproduce on fresh install, wonder what when wrong on your box. do you have everything updated, no held dependencies etc?10:06
MirvI do see "missing file /snap/.../meta/snap.yaml" type of messages but that's obvious since nothing is mounted, it's just annoying that regarding the "Operation not permitted" I'm not finding anything, and sudo systemctl stop apparmor + sudo systemctl stop snapd.apparmor do not help so it does not seem to be apparmor that's denying the permission (also as nothing is in audit.log)10:06
pstolowskiMirv: the fact you cannot even mount .snap manually is a key, that's pretty weird10:07
Mirvpstolowski: :( everything is updated, nothing seems to be held10:07
Mirvpstolowski: yes it is10:08
Mirvsquashfs is installed, that's one thing that I thought about10:08
pstolowskiMirv: that's not even a snapd issue but something more fundamental10:08
pstolowskiMirv: is it a standard suse kernel?10:08
Mirvpstolowski: standard yes. but I have another TW laptop at 20191112, I'll update that one too and see if it gets broken or not10:09
pstolowskiMirv: also, can you try mount -v /var/lib/snapd/snaps/rocketchat-desktop_97.snap /mnt (-v for verbose)10:10
Mirvpstolowski: not anymore verbose with that10:11
Mirvpstolowski: ah, it's loop devices broken, somehow.. I can't mount an iso either10:12
Mirvbut yes this is not snapd anymore10:13
mupBug #1853122 opened: Facing requires classic confinement error <Snappy:New> <https://launchpad.net/bugs/1853122>10:13
zygaMirv: losetup -a?10:13
zygamaybe you ran out of loopback devices10:13
Mirvzyga: empty10:14
zygacan you try:10:14
zygaMirv: losetup -f /path/to/a/squashfs/file/10:15
zyga(as root)10:15
zygaperhaps also with -r for --read-only10:15
Mirvhmm, losetup: cannot find an unused loop device10:15
zygaso that's the problem10:15
zygacan you strace it?10:16
Mirvyep, and from there I can see that there's nothing ls /dev/loop*10:17
zygado you have loop-control?10:17
Mirvnot even that10:17
zygaI don't know what makes it10:17
zygaon my system that is 10:23710:17
pstolowskiMirv: thanks for updating the bug report!10:23
Mirvpstolowski: sorry for taking your time :( it very effectively seemed like "snapd broken" for a long time..10:24
Mirvso currently I've filed openSUSE bug report, but then again my other laptop did not break. mknod /dev/loop-control c 10 237 helps. I'll follow up on the more relevant channels, maybe of course snapd current report a bit more if loop devices are broken.10:25
mupBug #1853122 changed: Facing requires classic confinement error <snapd:New> <https://launchpad.net/bugs/1853122>10:25
zygapstolowski: consider adding a check that /dev/loop-control exits and has major/mior10:25
zygasanity check, that is10:26
pstolowskizyga: exactly10:26
pstolowskiMirv: no worries. we do some sanity checks, and i think this problem highlights one other potential problem that we may want to check10:26
xnoxChipaca:  mvo: https://raw.githubusercontent.com/snapcore/pc-amd64-gadget/20/grub.cfg-recovery  note improvements 1) variables select the default entry by id 2) all recovery systems are enumerated 3) entries are created per-mode / per-system 4) no idea what duplicate hotkeys will do 5) added menuentry to go back to UEFI setup, as my VM is too quick10:39
xnoxit's kind of evolution of previous globgging, with type entries.10:39
xnoxand the cmdline is now correct.10:40
xnoxi was thinking that load_env --file /systems/$snapd_recovery/grubenv could e.g. declare the modes that are supported, and then generate entries for modes that a given recovery system can do?10:41
Chipacaxnox: I too was thinking of an env per system10:41
mvoxnox: sounds good! should we handle this stuff via PRs or do you prefer to commit directly to master?10:41
xnoxit was a rewrite, thus i just pushed it to master10:42
Chipacaxnox: i'm not sure the logic for default= is sane there though10:42
Chipacaxnox: shouldn't that be set after the loop?10:43
xnoxChipaca:  mvo: we were meant to have design for the boot menu right....? because it matters what order things are shown, what the text / hotkeys are, what they do, how they are grouped.10:43
xnoxChipaca:  it is set if there is a default provided in the global env (i.e. boot that next); otherwise it is set each time a new better system is found.10:44
xnoxmvo:  Chipaca: and we need to like search for ubuntu-boot and add entry to chainload "normal mode" grub right?10:45
* xnox also dislikes run/recover. I would prefer "normal/recover/install" such that hotkeys are unique: n r i10:46
mvoxnox: I pushed https://github.com/snapcore/core20/pull/13 with a very first draft of the separation of writable-path from initramfs. its the old code almost untouched. I will look to add tests and then we can start refactoring I think10:47
mupPR core20#13: handle-writable-paths: extract the writable-path handling <Created by mvo5> <https://github.com/snapcore/core20/pull/13>10:47
mvoxnox: but its what you had in mind, rightß10:47
mvo?10:47
mvoniemeyer: it would be great if https://github.com/snapcore/core20/ pull requests could be added to mup10:48
* mvo needs to step out for ~10min10:48
niemeyermvo: Heya10:48
niemeyermvo: Sure, will do10:48
xnoxmvo:  yes, that is the right approach, and a good starting point. It shouldn't live in /etc though, and can always iterate that once we create it as an entry point.10:50
pstolowskiChipaca: hey, why was this assigned to some other team? https://bugs.launchpad.net/snapd/+bug/185148011:05
mupBug #1851480: Hooks are not included in slot/plug label expressions <snapd:Confirmed for glancr> <https://launchpad.net/bugs/1851480>11:05
zygapstolowski: community11:08
pstolowskizyga: someone specific is going to fix it?11:11
mvoxnox: yeah, do you prefer /usr/lib/something/handle-writable-path?11:11
Chipacapstolowski: that's dot-tobias11:12
pstolowskiChipaca: ah, ok11:12
xnoxmvo:  /usr/lib/core/handle-writable-paths yeah11:12
Chipacapstolowski: they said on 2019-11-07 they'd get to it "next week", and that they'd report progress11:13
Chipacapstolowski: so maybe it's time to jiggle the plug11:13
mvoxnox: cool, will move it over11:14
zygapstolowski: yes, though please reassign if you want to fix it sooner11:16
mupPR snapd#7749 opened: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>12:09
cachio mvo hey12:13
cachio#7749 is to fix the issue I raised about that test on pi3?12:14
mupPR #7749: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7749>12:14
mvocachio: it *could* be related but it was the outcome of a discussion with mborzecki about the snapd failover robustness and we wanted to make sure our tests are complete (i.e. testing that we didn't just restart into the right snapd but also ensuring that its stable accross the restart)12:16
mvocachio: you need to remind me about this pi3 issue, I don't recall :/12:16
cachiomvo, sure12:17
cachioI see this error https://paste.ubuntu.com/p/xBhPYrjfVf/12:17
mupPR snapd#7750 opened: sanity: check /dev/loop-control device as part of sanity checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/7750>12:18
cachiomvo, It happens after we install the broken snapd12:18
mupPR snapd#7712 closed: seed: support in Core 20 seeds local unasserted snaps for model snaps <Priority πŸ‡> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7712>12:20
mvocachio: thanks, thats interessting. is this happening all the time or just sometimes?12:21
cachiomvo, all the time12:21
mvocachio: do you know when this started to happen?12:23
mvocachio: or is it happening since forever?12:24
mvocachio: also I assume this happens on all the Pis, not just pi3, pi2 as well?12:24
cachiomvo, checking logs12:25
mvocachio: thank you, no rush, I get lunch now but that is interessting, I wonder if there is a race with that path12:26
cachiomvo, 2.42 execution12:28
cachiofirst time I saw that12:28
cachioI raised the issue at that moment12:28
cachioand then I did a manual execution to get more info12:29
cachiolast week12:29
cachiomvo, I mostly reproduced that on pi312:30
cachioon pi2 not sure12:31
cachiojust once on pi2, it was during 2.42.112:32
cachiomvo, it is not happening all the time on pi312:37
cachiomvo, this is an execution during last week https://trello-attachments.s3.amazonaws.com/5da8bc830df86851446e9d4e/5dcf78cb5984618fb21cd5d7/1a9b05bfb0491c8faad045fc9f6143d3/snapd_2.42.1%2Bgit1140.g9173632_(5459)_pi3-refresh-18_arm32.log12:37
cachiothis is all stable + snapd from edge12:38
cachioand it works well12:38
pstolowskicachio: is this still the case https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635 ?12:50
mupBug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852635>12:50
cachiopstolowski, yes12:52
cachiopstolowski, this is the last log https://travis-ci.org/snapcore/spread-cron/builds/61333343812:52
cachiofrom yesterday12:53
pstolowskicachio: ok, thanks, will investigate12:53
cachiopstolowski, thanks12:53
mvocachio: thank you! interessting find, I wonder what is going on there, our code did not change in a while, maybe systemd did change somehow13:48
=== ricab is now known as ricab|bbl
mborzeckipstolowski: https://devfest.withgoogle.com/#devfest-map try poland14:09
pstolowskimborzecki: thanks14:09
mupPR snapd#7748 closed: overlord: fix the get command help message <Simple πŸ˜ƒ> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7748>14:22
pstolowskicachio: fwtw i run spread -debug google:ubuntu-18.04-64:tests/main/mount-ns and it didn't fail14:24
mborzeckicachio: pstolowski: do you have the log?14:31
pstolowskimborzecki: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/185263514:33
mupBug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1852635>14:33
mupPR snapd#7751 opened: cmd: fix the get command help message <Simple πŸ˜ƒ> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>14:37
cmatsuokamborzecki: did it over in the right message: https://github.com/snapcore/snapd/pull/775114:37
mupPR #7751: cmd: fix the get command help message <Simple πŸ˜ƒ> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751>14:37
cachiopstolowski, are yo uusing the image test-bionic-1 ?=14:38
cachiomborzecki, this is the last error https://travis-ci.org/snapcore/spread-cron/builds/613333438#L185014:40
mborzeckicmatsuoka: thanks, will take a look14:41
pstolowskicachio: no, how do you mean?14:42
cmatsuokamborzecki: thanks for noticing that, I grepped for the faulty message and I think I didn't expect more than one instance14:43
pstolowskicachio: ah, you mentioned it in the beginning of output in the bug report14:45
pstolowskicachio: how do i get it?14:46
ijohnsonmborzecki: regarding epochs on #7431, I don't think we should do anything for that, AFAICT it should just work with epochs, my gut feeling is that if there is something special that should happen with disabled services and epochs the "transitioning" snap between epochs should take care of that in post-refresh, pre-refresh hooks IMHO14:48
mupPR #7431: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>14:48
ijohnsonanyways do you think I'm ok to land that PR now since it's green? (CC mvo)14:48
ijohnsonmvo: also should we get a +1 from jdstrand on #7731 before merging?14:49
mupPR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open (LP: #1776873) <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>14:49
mvoijohnson: yeah, a review for 7731 from jdstrand would be great, should be fine but best to double check with him14:50
ijohnsonack14:50
mvoijohnson: let's merge 7431, it got two +1 and conceptually samuele had looked at it so AFAIK we should not block on him14:51
cachiopstolowski, I created it by updating and upgrading bionic and then rebooting it14:52
ijohnson\o/ I'm on it14:52
mvoijohnson: great, thanks for this one!14:52
mupPR snapd#7431 closed: overlord/snapstate: don't re-enable and start disabled services on refresh, etc <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7431>14:53
* ijohnson can't wait for pstolowski to rewrite all of that code for preseeding and review it all again14:53
mupPR snapcraft#2809 opened: project-loader: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2809>14:53
pstolowskiijohnson: yay14:54
ijohnsonpstolowski: I'm not quite done going through my backlog of forum/email/github notifications, did you submit a PR adding 'k' to the serial-port apparmor rules? If not I can do that15:14
ijohnsonlooks like jdstrand gave a +1 to adding 'k' to the rule15:14
ijohnsonhttps://forum.snapcraft.io/t/not-able-to-start-configure-custom-built-ubuntu-core/14142/23?u=ijohnson15:14
pstolowskiijohnson: he did, but he also said he was going to do it afaiu15:16
ijohnsonah I see his other comment now, nvm :)15:17
* cachio lunch15:18
mupPR snapd#7752 opened: tests: enable degraded test on arch linux after latest image updates <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7752>15:19
mborzeckiijohnson: yeah, i was wondering about the snap service naming, it's totally up to whoever builds the snap, so you can have a service named A, then the user disables it, the publisher renames A to B, the user proceeds to disable B, then A returns as something completely new and gets disabled because we carry the history of the disabled service names, but it a corner case so meh ;)15:19
ijohnsonwell the question I would have is when you say "A returns as something completely new", how do you qualify something completely new? :-) it has the same name, so the publisher probably intended some kind of connection between the first service and it's reincarnation15:21
ijohnsonbut yes that is a corner case15:21
=== ricab|bbl is now known as ricab
mupPR snapcraft#2810 opened: build-providers: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2810>16:35
ijohnsonChipaca: I think the snapd REST API wiki docs need an update, see https://forum.snapcraft.io/t/facing-requires-classic-confinement-error/1416316:40
Chipacahmm16:40
* Chipaca looks16:40
Chipacaijohnson: oh, doc seems to be wrong, not outdated16:41
ijohnsonwrong == outdated ?16:42
Chipacaijohnson: /v2/snaps never took options16:44
ijohnsonright got it16:44
Chipacaso all those options descriptions should be on /v2/snaps/<snap>16:44
=== pstolowski is now known as pstolowski|afk
Chipacaaugh17:14
* Chipaca takes a break17:14
ijohnsondegville, when you get a chance can you take a look at making the docs changes for https://bugs.launchpad.net/snapd/+bug/1612440 ?17:21
mupBug #1612440: Full systemd socket activation support <lxd> <Snapcraft:New> <snapd:Fix Released> <https://launchpad.net/bugs/1612440>17:21
degvilleijohnson: will do, thanks for letting me know.17:23
ijohnsonthanks!17:29
jk0neHello!  I am beginning an upgrade of the snapcraft forums.  The forum will be in read-only mode until this is completed.  ETA: less than one hour.17:41
ChipacaEOD for me it is17:53
ChipacaπŸ‘‹17:53
jk0neforum.snapcraft.io has been upgraded. Maintenance is complete.18:32
mupPR snapcraft#2811 opened: extractors: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2811>18:32
degvillethanks jk0ne!18:39
ograhmm18:46
ograjk0ne, not sure if that was your intent ... https://imgur.com/a/es4hRK918:46
ogra(has anyone else lost all CSS from the forum ?)18:47
ograbah ... ok, now it is back but i'm hard logged out ...18:48
ec0looks OK here18:48
ogra(and cant remember my credentials since the silly forum doesnt use SSO)18:48
jk0neogra: I think you might have hit it during the actual reload.  Let me know if you are seeing issues still.19:03
ograjk0ne, nope, seems ok now19:15
jk0neglad to hear19:17
mupPR snapcraft#2812 opened: store: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2812>23:24
mupPR snapcraft#2813 opened: pluginhandler: address errors from mypy uprev <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2813>23:39

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