/srv/irclogs.ubuntu.com/2019/10/24/#snappy.txt

mborzeckimorning05:31
mborzeckigoogle:ubuntu-18.04-64:tests/main/uc20-snap-recovery seems to fail randomly06:09
mupPR snapd#7650 opened: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>06:38
mupPR snapd#7651 opened: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7651>06:45
pedronismborzecki: hi, should we disable temporarely google:ubuntu-18.04-64:tests/main/uc20-snap-recovery it seems indeed flaky06:51
mborzeckipedronis: i'll try to find out what's going on there06:52
pedronisok06:52
mborzeckipedronis: can you take a look at https://github.com/snapcore/snapd/pull/7643 ? should be easy to land, it's just moving the code around into separate files06:53
mupPR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>06:53
pedronismborzecki: yes, finishing something else and then I will look06:53
mborzeckipedronis: cool, thank you06:54
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:00
zygaHey07:00
zygaOverslept07:00
zygaIncluding kids07:00
zygaSorting out stuff07:01
mborzeckihey guys07:05
mvohey mborzecki07:06
mborzeckimvo: quick question about uc20-snap-recovery test, lsblk is wrapped by retry-tool, the comment says it's a race with udev, i've also seen it fail randomly in the travis runs07:09
mborzeckimvo: the race is in udev noticind the new partitions and creating device nodes, while lsblk picks them up, right?07:09
mupPR snapd#7652 opened: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652>07:12
mvomvo: yeah, I think so, we could call udevadm I guess07:12
mvomborzecki:07:12
mvomborzecki: I'm doing a spread run right now to validate this07:12
pedronismvo: all greedy plugs PRs are up now07:15
mvopedronis: \o/07:15
pedronispstolowski: hi, I asked you a review in #7650, that's definitely an area you worked on/touched07:15
mupPR #7650: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <https://github.com/snapcore/snapd/pull/7650>07:15
pstolowskipedronis: sure, will do07:16
pedronisthx07:16
mborzeckimvo: heh, obviously spread -repeat=20 did not catch this07:19
mborzeckimvo: repeated that a couple of times, same thing07:19
mborzeckimvo: wonder if maybe there's some cross test interaction after all07:19
mvomborzecki: could be, I can also just mount the partitions directly in the test and not rely on lsblk07:21
mborzeckimvo: hm, otoh, the nodes under /dev are created by the kernel now07:22
mborzeckimvo: not all though, but /dev/loop*p* probably is07:22
pedronisit failed again fwiw also in 765007:30
mvomeh, I change from lsblk to mount for now07:31
* mvo does that right away07:31
mvosorry guys07:31
mborzeckipedronis: restarted the job in 7650, there's nothing new in the log, tests that ran earlier don't seem to be related07:37
mborzeckipstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7647 ?07:41
mupPR #7647: gadget: skip structures with MBR role during remodel <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7647>07:41
=== pedronis_ is now known as pedronis
pedronismborzecki: reviewed #764307:42
mupPR #7643: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>07:43
mborzeckipedronis: thanks! i think we could return to making the split nicer once gadget remodel (and maybe base remodel) land07:45
pedronisyea, I would also like to clean up some stuff in managers_test.go but yes, after more remodel stuff lands seems the right call07:46
pstolowskimborzecki: sure07:46
mborzeckizyga: tiny suggestion under https://github.com/snapcore/snapd/pull/7623 also the test caught something07:54
mupPR #7623: tests: check world-writable and test-owned files <Created by zyga> <https://github.com/snapcore/snapd/pull/7623>07:54
mborzeckizyga: probably needs a master merge too07:54
zygamborzecki: tests caught real bug, it is discussed in the PR08:03
mupPR snapd#7653 opened: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>08:04
mborzeckimvo: left a little comment https://github.com/snapcore/snapd/pull/7653#discussion_r33843614408:14
mupPR #7653: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7653>08:14
mvomborzecki: oh, nice! we probably want both, i.e. know we can mount it but also get all this nice information that file provides08:15
mborzeckimvo: surprisingly there's not that many methods for probing the fs type of a block device :/08:16
mvomborzecki: yeah, I'm also puzzled why lsblk is not reliable, I try to look at the code of lsblk08:16
mborzeckiChipaca: updated my old store-url branch08:54
mborzeckiChipaca: will be pushing that out soonish08:54
* zyga -> tea08:55
Chipacamborzecki: neat08:58
mborzeckiChipaca: hm haven't added it to aux info though, we have a website and media list there09:24
dot-tobiasjdstrand: Ping re https://bugs.launchpad.net/snapd/+bug/1849291/comments/2 – can I be of any help to get this into snapd soon(ish)? Sorry for nagging, but our snap pipeline is currently blocked for pressing updates, I'd need to revert a slew of NM-related changes or cherry-pick to another build branch until core allows Introspectable access for NM.09:27
mupBug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1849291>09:27
dot-tobias(Note to self: Don't assume NM access works on Core when working fine on Classic desktop 🙈)09:27
mupPR snapd#7654 opened: cmd/snap, store: include snapcraft.io page URL in snap info output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7654>09:31
mborzeckiChipaca: ^^09:31
Chipacamborzecki: yeah that'd be better,but could be a follow-up09:49
ijohnsonpedronis, mvo sorry for not getting to #7595 yesterday, but I'm looking at it now, is there a design doc for the things there I should be looking at it? is the model assertion doc the only thing?09:53
mupPR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>09:53
pedronisijohnson: there's that and there's a picture from a sprint, let me turn it into a doc quickly10:00
ijohnsonok thanks10:01
ijohnsonalso could someone restart https://travis-ci.org/snapcore/snapd/jobs/601379249 again for me? it failed on store 403s again :-/10:09
Chipacaijohnson: done10:16
ijohnson\o/10:16
Chipacaijohnson: you don't have travis permission to restart?10:17
ijohnsonI used to but it went away yesterday, I am still a GitHub member of snapcore but Travis doesn't think so anymore10:17
Chipacaijohnson: maybe you need to log back in?10:17
ijohnsonhmm I could try clearing the cache too I suppose10:17
Chipacaheh10:18
ijohnsonsigning out and back in doesn't do anything unfortunately10:18
Chipacai recently got told to clear all my cookies to debug some website10:19
Chipaca"hahaha no"10:19
ijohnson"ALL your cookies are belong to us now"10:19
Chipacathere's so much state in dem biscuits10:19
ijohnsonhuh well now it works when I go sign in fresh to another browser10:19
mborzeckiquick errand, back in 3010:21
ijohnsonalso Chipaca does the meeting time I sent out today work for you?10:23
Chipacaijohnson: both of 'em work :-) but yes10:24
Chipacaijohnson: i didn't check, is pedronis also there?10:24
ijohnsonChipaca yes and pedronis accepted the most recently sent invitation10:25
Chipacaijohnson: are you saying i should actually click accept on the invite10:26
Chipacapsh10:26
ChipacaRSVPs is for frenchies10:26
ijohnsonnext time I'll mail you a physical invite so you can't decline it10:27
Chipacayou underestimate my power10:27
Chipacacan I enjoy some schadenfreude over the "FIREFOX UPDATED WITHOUT MY KNOWLEDGE AND STOPPED RESPONDING THIS IS TERRIBLE WILL YOU PLEASE FIX IT oh wait it was the apt version never mind" thing10:31
mborzeckire10:43
mupPR snapd#7655 opened: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>10:49
zygadot-tobias: ^10:50
mupPR snapd#7646 closed: tests: update mount-ns after addition of /etc/systemd/user <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7646>10:52
mupPR snapd#7643 closed: overlord/devicestate: refactor and split into per-functionality files, drop dead code <Remodel 🚋> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7643>10:54
mupPR snapd#7656 opened: tests: verify host is not affected by mount-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>10:55
Chipacazyga: pstolowski: is either of you aware of / working on #1848516 and #1849564 ?10:57
mupBug #1848516: snap connections/interfaces shows dropped interfaces as connected after refresh <snapd:New> <https://launchpad.net/bugs/1848516>10:57
mupBug #1849564: snap connections doesn't work as expected when interface attributes change <snapd:New> <https://launchpad.net/bugs/1849564>10:57
zygaChipaca: I'm aware of the first one, working on neither10:57
zygachecking the second one10:57
Chipacamvo: with the pulsaudio transition in progress, these bugs are going to bite10:57
Chipacazyga: variation thereof10:58
mvoChipaca: uh, thanks for raising this11:03
Chipacazyga: you commented on this, so I ask you: what other projects have bugs for us? I'm adding them all to the triage doc11:16
zygaChipaca: that's a great question, let me think11:16
ijohnsonyassss finally silly spread tests passed11:17
mupPR snapd#7597 closed: overlord/snapstate: add LastActiveDisabledServices, missingDisabledServices <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7597>11:17
Chipacazyga: I'm stepping outside for a while, feel free to edit the doc :-) hopefully it makes sense wrt where to add11:17
zygaChipaca: I will11:17
zygaenojy11:17
zygaenjoy*11:18
zygapstolowski: we should look at those connections bugs11:23
zygapstolowski: let me wrap something up first though11:24
zygaI see some searching and apt-hooks failures11:26
pstolowskizyga: interesting, I will investigate later today11:26
zyga403 store side11:26
mvoI see a bunch of (random?) systemctl restart systemd-journald.service failures. anyone  else is seeing this in the tests?11:26
ijohnsonmvo: yes I see this constantly11:27
ijohnsoncachio has a PR which should fix this11:27
zygasnap recovery failures11:27
zygamvo: all the time11:27
mvozyga: I'm trying to fix those11:27
zygamvo: as in every day for as long as I can remember11:27
zygamvo: thank you so much11:27
mvozyga: but now I see failures in the other ones11:27
mvozyga: so I can't land my fix :/11:27
ijohnsonmvo: https://github.com/snapcore/snapd/pull/7605 is what cachio had to fix that I think11:27
zygareliability of the test suite is such an important part of snapd11:27
mupPR #7605: tests: configure the journald service for core systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7605>11:27
mvozyga: 7653 fwiw11:27
ijohnsonmvo: you always see it in ubuntu-core right?11:28
ijohnsonor elsewhere?11:28
ijohnsonI always only see it on ubuntu core11:28
mvoijohnson: correct11:28
mvoijohnson: lookng now11:30
mvoijohnson: the PR from sergio needs a core update to writable path or some other mean to set this :/11:31
ijohnsonah darn, is there anyway we could hack around that?11:32
pstolowskizyga: i suspect a problem around reloadConnections, afair it is not robust enough. I’ll check later, need to wrap up first pare-Bakun PR11:32
zygamvo: assuming https://bugs.launchpad.net/snapd/+bug/1849291 is fixed now, should it be targeting 2.43?11:32
mupBug #1849291: Interface network-manager should grant access to org.freedesktop.DBus.Introspectable <papercut> <snapd:In Progress by zyga> <https://launchpad.net/bugs/1849291>11:32
pstolowski*pre-bake11:32
zygasome old milestones on launchpad ought to be closed11:32
zygaI'll do that11:32
zygayay11:35
zygatwo milestones left11:35
zygamvo: and if so, what is the estimated release for 2.42 and 2.43?11:35
zygamborzecki: can you look at https://github.com/snapcore/snapd/pull/761411:36
mupPR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>11:36
mupPR snapd#7585 closed: spread.yaml: drop exclude list, use .gitignore <â›” Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7585>11:36
zygaIt'd like to start moving this forward a little11:36
mupPR snapd#7657 opened: snap: fix default-provider in seed validation <Created by mvo5> <https://github.com/snapcore/snapd/pull/7657>11:37
mvoijohnson: is the restart issue only happening on core18?11:38
mvoijohnson: or did you see it on core16 as well?11:38
zygamborzecki: also https://github.com/snapcore/snapd/pull/7656 is very simple and could land soon11:38
mupPR #7656: tests: verify host is not affected by mount-ns tests <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7656>11:38
zygamvo: I saw this issue (journal service restart) on pretty much all systems, but this is an unscientific assertion]11:39
ijohnsonmvo: pretty sure I've seen it on core16 as well11:40
mvoijohnson: yeah, I'm just going over the last couple of failures and there it is11:41
pedronisI remember I have a note about the fact that we should simply drop some connections11:44
pedronison refresh11:44
mvoijohnson: let me see if I can fix sergios pr11:44
zygacore 20 recovery fails11:47
zygais that fixed or shall we disable it11:47
zygapedronis: yes, we never implemented transitions in any way, where a snap can rename a plug or slot or actual dropping of a plug or slot where that is removed from the state11:48
zygaI need some coffee, it's such a sleepy day11:48
zygasorry, brb11:48
dot-tobiaszyga, jdstand, mvo: Hearty thank you for the fast help + fix re: NM Introspectable! One more thing to look forward to in the 2.43 release 😊11:50
dot-tobias*jdstrand ^11:50
mvoijohnson: I pushed a PR to core11:51
mupPR core#109 opened: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <https://github.com/snapcore/core/pull/109>11:52
=== ricab is now known as ricab|lunch
ijohnsonack mvo will take a look today then11:59
zygadot-tobias: a pleasure :)12:03
zygamvo: once that lands I need to adjust mount-ns test to compensate12:03
mupPR snapd#7658 opened: cmd/snap-start-pressing: add snap-start-preseed executable (1/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/7658>12:07
mborzeckipedronis: i've updated https://github.com/snapcore/snapd/pull/763012:08
mupPR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7630>12:08
pstolowskiijohnson: hey, 7431 has conflicts12:09
pedronismborzecki: addd to my queue12:32
mborzeckithx!12:32
ijohnsonpstolowski: yes I finally just merged the dependent one, will resolve asap after my meetings this morning12:37
mborzeckiChipaca: pushed changes to aux data too12:42
Chipacamborzecki: reviewed changes to aux data too12:52
mborzeckiChipaca: cool, thanks!12:52
mborzeckiChipaca: something i haven't checked, when is the aux info refreshed? bc if the store were to change the urls for any reason, would this end up being out of date?12:53
Chipacamborzecki: currently it's bumped on refresh, although my plan is to do it on checking for refreshes also12:54
mborzeckiChipaca: so it should be fine then12:54
Chipacamborzecki: that is: the refresh action fetches a bunch of data that we currently completely ignore for snaps that aren't actually refreshed, but that can and should change12:55
Chipacamborzecki: we need to run the numbers but it's quite possible it'll be less expensive to get minimal data on refresh, and do separate info calls for what actually changed12:55
=== alan_g is now known as alan_g_
Chipacabut that's something to do when we have free time12:56
* Chipaca looks at work mapped out to 204012:56
Chipaca… yeah, someday12:56
ograis there a forum thread so we can put our wishlist items on your 2040 schedule ?12:57
pedronisogra: ?13:02
ograpedronis, i was reacting to Chipaca's snarky joke :)13:03
pedronisah13:03
ogradidnt mean to scare you :)13:03
Chipacasnarky? me?!?13:05
=== ricab|lunch is now known as ricab
* zyga goes for lunch13:30
mupPR snapd#7653 closed: tests: do not use lsblk in uc20-snap-recovery test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7653>13:44
mvomborzecki: 7640 is ready for a second review13:47
ograjdstrand, the new daemon user is hardcoded to "snap_daemon" ? (i.e. i can not set a random username here ?)13:56
ijohnsonogra: yes14:01
joedborgmorning all! I've been seeing some odd snapcraft errors since late last week.  They seem to point at missing libraries, but I get different results part to part and for different libraries.  Could anyone lend their eyes please?  It's blocking some work.14:03
jdstrandogra: you may only use snap_daemon at this time14:03
Chipacajoedborg: maybe #snapcraft ?14:04
Chipacajoedborg: or are they snapd-related?14:04
joedborgthanks, i'll try there. i guess it's snappy as it's happening at build time14:05
mborzeckioff to pick up the kids14:06
jdstranddot-tobias: it might make sense to verify the changes in that PR are enough to solve your issue. the way to do that would be a) install the two snaps b) in /var/lib/snapd/apparmor/profiles/snap.network-manager.networkmanager add the receive rule from the PR, substituting the plug's name (eg, snap.mirros-one.hook.post-refresh)14:11
jdstranddot-tobias: c) in /var/lib/snapd/apparmor/profiles/snap.mirros-one.hook.post-refresh add the send rule from the PR, substituting the slot's name (eg, snap.network-manager.networkmanager)14:11
jdstranddot-tobias: d) load the profiles into the kernel with: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.network-manager* /var/lib/snapd/apparmor/profiles/snap.mirros-one*14:12
zygare14:14
zygahello jamie :)14:15
zygaI'll push forward with bugfixes tonight14:15
zyga(spread permitting, sigh)14:16
zygajdstrand: https://github.com/snapcore/snapd/pull/7655 updates as requested14:23
mupPR #7655: interfaces: allow introspecting network-manager on core <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7655>14:24
dokosergiusens: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/u/ubuntu-image/20191022_062343_f039f@/log.gz14:25
dokothis needs updating for 20.04?14:25
dokomvo: ^^^ ?14:25
mvodoko: looks like it, yes - sergiusens will have a look, he is in a meeting right now14:26
sergiusensdoko: I worked that out on #ubuntu-release already, or is this a trigger after that?14:26
dokosergiusens: is it already fixed?14:27
mupPR core#109 closed: extra-file: make /etc/systemd/journald.conf.d writable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/109>14:28
sergiusensdoko: a retrigger should fix it if sil2100 or infinity haven't done so yet14:30
sergiusensdoko: I reported my side of the fix one hour and 20 minutes ago on #ubuntu-release ... I cannot retrigger tests for ubuntu-image14:31
mvozyga, cachio new core with fix for journal.d is building14:33
cachiomvo, perfect14:33
jdstrandzyga: hi and thanks!14:35
zygamvo: thank you, I will prepare the fix for mount-ns test14:36
pedronispstolowski: I skimmed the preseed PR,  it looks good overall, my main comment will probably be naming related14:41
pstolowskipedronis: ty!14:42
sil2100mvo: hello! Once you find a few cycles today, could you formally sign-off on the uc20 u-i spec in the doc? ;)14:48
sil2100Since I'm getting poked about that constantly, especially now that I want to land the changes14:49
mvosil2100: yes, today is meeting crazy, I try14:59
sil2100mvo: thank you!15:01
pedronismvo: I made a suggestion comment in #764915:03
pedronisrelated to what we discussed15:03
mvopedronis: thank you!15:03
mupPR #7649: overlord: fix TestRemodelSwitchToDifferentKernel for bootvars <Created by mvo5> <https://github.com/snapcore/snapd/pull/7649>15:03
pedronissil2100: mvo: I could probably look at it an sign it off instead of mvo if that helps15:09
mvopedronis: that would be great15:10
mvopedronis: *if* you have some minutes, but hopefully straightforward15:10
mvomborzecki: any news on the f30 xerrors backport?15:13
mborzeckimvo: nope, filed a ticket, pinged the guy irc, but haven't heard back15:13
sil2100pedronis: I'd be +1 on that too ;)15:14
ijohnsonpedronis: left an initial review on #7595, need to finish reviewing the tests in a followup review I will submit later this morning15:14
mupPR #7595: seed/seedwriter: support writing Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7595>15:14
pedronissil2100: I made two additions, as suggestions, do they match our last understanding15:14
pedronis?15:14
sil2100pedronis: yes, approved those o/15:15
sil2100Thanks for adding them15:15
pedronisijohnson: thanks, I'll answer some of your questions in my morning15:20
ijohnsonsounds good, have a nice evening (also I scheduled a meeting with you tomorrow morning re: performance things)15:20
pedronissil2100: I filled in the table at the top with my +1, let me know if I should put in something else, not sure how you do this15:22
sil2100pedronis: that's perfect, thanks a lot o/ I'll inform my manager and land the u-i bits tomorrow - we can always follow up with fixes later when we're able to test it properly15:25
* zyga is sleepy and goes to bed15:30
pedronisijohnson: I did a pass of answering already15:45
ijohnsonpedronis: ack will take a look15:45
mupPR snapcraft#2767 opened: rust plugin: add rustup profile <Created by dalance> <https://github.com/snapcore/snapcraft/pull/2767>15:48
* cachio lunch15:55
ograppisati, so i just tried to roll a kernel snap from the raspi2 tree of eoan ... using the rsapi2 defconfig (to use it on my pi4 core images) ... and i notice that i end up with an ~800MB snap !! lookinng inside (unsquashed it is even 2GB) i see 976M in modules !16:06
ogrado we really need all this on a pi ?16:09
ogra(and how did it grow so much since bionic ?)16:10
ogra$ snap info rpi-iptv-player16:12
ograKilled16:12
ograbah !16:12
om26er@saviq is there a way to tell multipass to use all available instead of using a single core ?16:14
Saviqom26er: --cpu `nproc` when launching16:14
ograjdstrand, do we suddenly have auto-rebuilds enabled for outdated snaps ?16:14
Saviqom26er: snapcraft has a hidden env var for it, too16:14
om26erSaviq, cool that was going to be my second question :-)16:15
Saviqhttps://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_multipass/_multipass.py#L9916:15
Saviqom26er: vote on https://github.com/CanonicalLtd/multipass/issues/756 to have a setting for the defaults ;)16:15
om26erhmm, it seems to default to 2 apparently16:15
ograjdstrand, i just looked at one of my pi's and had an update this morning of one of my packages that i definitely havent touched in more than a month ... and snap info also shows "edge:      0.2 2019-10-24 (56) 42MB -"16:16
Saviqom26er: that's threads, not necessarily cores16:16
Saviq(i.e. with HT that might end up just one core)16:16
om26erSaviq thanks for info, I'll subscribe to that issue16:17
=== pstolowski is now known as pstolowski|afk
ppisatiogra: i don't work on ARM kernels anymore -- juergh and hwang4 are taking care of rpi kernels now16:17
ograppisati, ah ..16:18
ograwell, let me just express that i'm slightly shocked then ... seeing my kernel snaps triple up in size :)16:18
ppisatiogra: while shrirang and jesse work on snapdragon16:18
ppisatiogra: eh, i see what you mean16:18
ppisatiogra: we can probably reduce the size / number of kmods16:19
ograyeah i guess so16:19
ppisatiogra: thow a bug in LP about that, and we can take a look16:19
ograwill do ... not urgent indeed, i believe official pi4 core support is only on schedule for core20 anyway16:19
mvozyga: do you think you could give a second review to 7640 ?16:30
ogra$ snap stop lxd16:30
ograerror: cannot communicate with server: Post http://localhost/v2/apps: dial unix /run/snapd.socket: connect: connection refused16:30
ograGRRRR !!!16:30
ijohnsonzyga: when you get back I have some bad news for you :-( https://github.com/snapcore/snapd/pull/7547#issuecomment-54600123716:36
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <â›” Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>16:36
ijohnsonI'm looking into it and I'm hoping there's an easy way out for this16:37
* Chipaca takes a break16:38
pedronismvo: I reviewed some of your PRs16:47
=== ijohnson is now known as ijohnson|lunch
jdstrandroadmr: hey, can you pull 20191024-1700UTC?17:02
roadmrjdstrand: sure!17:02
jdstrandroadmr: thanks :)17:03
roadmr1700 how precise ;)17:04
jdstrandroadmr: just overrides and a change to the README. I used the new debian/changelog methodology as discussed before17:04
jdstrandroadmr: yeah :)17:04
roadmrthanks! jdstrand fwiw the guys who had complained about that said having the changelog from source was fine, so yay17:04
jdstrandroadmr: cool :)17:05
jdstrandogra: if something is rebuilding that, it isn't something I am aware of17:07
ograjdstrand, yeah, i just learned that build.s.io adds automatic watches for *any* "source:" line in snapcraft.yaml ... not just for the repo that carries the snapcraft.yaml17:09
ograso myth solved .. the package uses two external GH trees ... i had the impression only changing the tree itself triggers rebuilds17:10
ogra(i wonder how many of my snaps are actually broken because the initial build used some source: entry to a foreitgn trunk tree that was stable at the time i created the initial snap)17:11
ograthats probably a "feature" we should make people more aware of ... i certainly didnt knwo this17:12
ogra*know17:12
cjwatsonNot any source: line, just ones that refer to repos on github17:19
ograindeed17:20
ograstill though, i'm not even sure how many of my snaps use trunk links that might have completely fallen over after i created the snap17:20
ogra(simply bcause ... well .. development trees instead of stable ...)17:21
ogra+e17:21
zygamvo: sure17:31
zygaijohnson|lunch: uh17:31
zygaijohnson|lunch: there was a similar case before17:31
ijohnson|lunchzyga: yeah I think I remember, but this is different because what I'm thinking right now is that we put dockerd inside a cgroup and it tries to mount things underneath that group and that doesn't work because those subsystems, i.e. devices are not mounted there they are mounted in the normal system one17:34
ijohnson|lunchthis should only affect things that need to create containers and manage cgroups17:34
ijohnson|lunchanyways I will keep looking after lunch and let you know via the PR what I find17:35
jdstrandogra: oh, interesting17:49
zygajdstrand: do you want to review https://github.com/snapcore/snapd/pull/7632 -- it's the fix for the memory bug17:55
mupPR #7632: interfaces: de-duplicate emitted update-ns profiles <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7632>17:55
zygajdstrand: it has +2 but I can wait if you want to go through it carefulyl17:55
zyga*carefully17:55
=== ijohnson|lunch is now known as ijohnson
mupPR snapcraft#2766 closed: project: truncate project directory hash <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2766>18:09
cachioniemeyer, hey, I am makes a POC related to github actions18:43
cachioand I need a sa to store in the secrets to run the tests18:43
cachioniemeyer, could you please create one similar to the one we use for travis18:44
cachiowith expiration: 1 week18:44
cachioso I can test it?18:44
om26erIf that is of interest for anyone, I wrote a snap example that uses python3.8 and instead of bundling pycache files as part of the snap package, it generates them post-install. Reducing the size of the snap substantially (and in rare cases improves startup time as well) https://github.com/om26er/post-refresh-bytecompile-snap18:46
jdstrandzyga: I do. as you can see from forum traffic, I'm a bit swamped18:49
jdstrandzyga: I will review it before any other PRs18:49
zygajdstrand: no worries, thank you19:18
* cachio afk19:21
mupPR snapcraft#2763 closed: "snap debug validate-seed" fails if the slot is specified in the default-provider <Created by kenvandine> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2763>20:00
zygajdstrand: hey22:44
zygajdstrand: I just ran into a curious bug22:44
zygajdstrand: https://forum.snapcraft.io/t/classic-confinement-breaks-high-dpi-support/1386822:44
zygajdstrand: XDG_RUNTIME_DIR breaks wayland22:44
zygacc kenvandine22:44
zygabut when snap uses classic confinement, we should not set it at all IMO22:44
jdstrandzyga: I just approved 7632, but please see my comments for a follwoup22:44
zygajdstrand: I will, thank you22:46
mupPR snapd#7659 opened: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659>22:47
mupPR snapcraft#2765 closed: remote-build: initial Windows support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2765>22:49
* kenvandine looks22:49
zygajdstrand: note, command time, is running /usr/bin/time, it's just that it's rarely installed22:52
zygajdstrand: I'll fix that in a follow up22:52
zygajdstrand: command foo performs PATH lookup and skips shell built-ins22:53
zygajdstrand: but GNU time is not installed anywhere outside of ubuntu22:53
jdstrandzyga: I understand that about the lookup except bash behaves different. try it :)22:54
zygajdstrand: bash vs dash?22:54
* zyga tries22:54
jdstrandzyga: yes, as my comment mentioned with hello-world.sh22:54
zygajdstrand: what I am doing wrong? https://www.irccloud.com/pastebin/uG75D2rs/22:55
jdstrandzyga: anyway, how you fix it doesn't matter, just having it everywhere makes sense22:55
zygajdstrand: I think it only depends on /usr/bin/time being present or not, it's not in core22:55
zyga(core 16 or 18, one of those has it AFAIR)22:55
jdstrandzyga: you aren't in hello-world.sh?22:55
zygaright, it's not in core so it's not there22:55
zyganot on path22:55
jdstrandbash-4.3$ command -v time22:55
jdstrandtime22:55
jdstrandbash-4.3$ /bin/sh22:55
jdstrand$ command -v time22:55
jdstrand$22:55
zygano, I was on a 19.1022:55
zygaoh22:56
zygathat's weird22:56
zygait says that there's no time at all22:56
zyganot even built-in22:56
jdstrandzyga: it isn't in path in hello-world.sh bash either:22:56
zygaI see now22:56
jdstrandbash-4.3$ which time22:56
zygaI understand the mistake now22:56
jdstrandbash-4.3$22:56
zygathanks!22:56
jdstrandnp22:56
zygajdstrand: as for xdg runtime dir22:56
zygaI think we need to fix wayland for strict22:56
zygabut for classic I would argue that we did something wrong and need to back out22:56
zygaeven if there is some frictoin22:57
zygayes, each snap can fix it by itself22:57
zygabut I would argue it's our bug22:57
zyga*friction22:57
jdstrandwe can discuss that in the topic22:57
zygasure, sorry for splitting the conversation22:57
jdstrandas for strict, that is a longer discussion. the symlinks were never supposed to be a longterm solution22:57
jdstrandbut resources what they are...22:57
zygaI think nobody noticed this because it really manifests itself when you have fractional scaling22:58
zygaand suddenly you go via xwayland22:58
zygaand that just scales a bitmap22:58
jdstrandas someone who uses hidpi, that would be annoying22:58
jdstrandok, I gotta run. I'm getting the side eye, but wanted that PR review out the door22:59
jdstrandzyga: talk to you later23:00
zygajdstrand: sure, o/23:00
zygajdstrand: thank you for the review!23:00
zygaI know you are super busy now23:00
jdstrandzyga: np, sorry for the delay. I think I am through all the reviews/forum backlog (finally-- 2 days!! :\ )23:00
zyga:)23:01
jdstrandso, more PR reviews tomorrow23:01
jdstrandok, bye! :)23:01
mupPR core-build#55 closed: Drop abootimg support, not used anymore <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core-build/pull/55>23:02

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