=== Guest76648 is now known as icey [05:07] morning [05:44] good morning [05:44] hey zyga [05:44] wow, I had a good sleep today [05:44] I woke up, looked outside and noticed it's not dark anymore [05:44] and it was about 4AM [05:45] mvo: I have a small proposal in 5202 [05:45] might make reviewing logs a little bit less frustrating [05:45] zyga: yeah, I saw that [05:45] zyga: was just about to comment [05:49] PR snapd#5201 closed: interfaces/apparmor: use helper to load stray profile [05:49] mvo: zyga: hey [05:50] zyga: thanks for doing the renames in 5199 [05:50] :-) [05:50] ooooh! [05:50] finally!!! [05:51] * zyga got an email that his 3d printer has shipped [05:51] after months of waiting [05:52] I suspect this means that weekend will be spent on "some assembly required" [05:53] mborzecki: can you please have a 2nd look on 5155 [05:54] looking [05:54] I bought a USB-C power bank at the airport [05:55] it works with laptops and phones alike so I was looking forward to use it with my thinkpad [05:55] but obviously, there's a bug and the kernel doesn't say "hey, I'm a type-c power sink, gimme power" and it doesn't charge in linux [05:55] hey mborzecki good morning [05:55] the power bank has fantastic reviews all around and works everywhere else [05:55] a bit of a sigh :) [05:56] so I will go on a type-c bug hunt to see why [05:56] I just found this interesting that in the future, even charging needs a non-trivial stack of software that must work just right === chihchun_afk is now known as chihchun [06:42] pedronis: added tests for setup-profiles undo in #4996 [06:42] PR #4996: overlord/ifacestate: store and use revision with security profiles set [06:48] PR snapd#5143 closed: tests: speed up save/restore snapd state for all-snap systems during tests execution [06:49] mvo: do you happen to remember if LTS to LTS update kicks in at the first point release? that is 16.04 will update but only to 18.04.1? [06:50] tests are rather red today [06:50] and often end with [06:50] The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over). [06:50] zyga: yes, first point release [06:51] ah, thanks for confirming that [06:52] zyga: testsuite> anything in particular you noticed? when I looked earlier it was some repo that could not be cloned [06:52] the thing is, I don't know, it's just red and overflowing logs [06:52] I've yet to find an efficient way to find what broke [07:00] eh [07:01] * zyga filed the bug on dh-golang only to notice (at the end of the report) that the email address is "zyga@debian-9" [07:01] bugs via email ftw :/ [07:01] debian FTW [07:02] well, it should show up here, eventually: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dh-golang;dist=unstable [07:04] new TLD debian-9 :) [07:04] hm, having .ubuntu as a TLD would be cool === pstolowski|afk is now known as pstolowski [07:04] morning [07:05] hey pstolowski [07:05] pstolowski: hey [07:05] mvo: ICANN awaits your application :P [07:05] morphis: hey, andbox-support PR needs some love [07:05] mborzecki: heh, maybe a bit too much work for my free evenings ;) [07:06] mvo: it's just 5000 and you own it [07:06] custom TLD were approved a while a go [07:06] zyga: 5000 of what currency? [07:06] USD AFAIK [07:06] zyga: yeah, but you also need to make some comitments technically iirc, no? I don't remember the details though [07:07] heh, doped to dogecoins :) [07:07] s/doped/hoped/ [07:07] oh [07:07] it's more pricy than that [07:09] $185,000 [07:09] ouch [07:11] autsch indeed [07:35] journal cursors break some tests [07:35] it looks like buffering is in theway [07:36] iirc there's a --sync flag but it didn't work on 14.04 or sth [07:37] anyways, in snapd-notify test, i think it'd be better to systemctl show -p SubState and ActiveState directly [07:37] it failed on a totally unrelated test now [07:39] zyga: hey! I know, but I am waiting for general feedback from jdstrand first before doing any further work. I have a side-channel conversation with him on this already. [07:39] morphis: ack [07:39] the PR might go into a completely different direction [07:39] you still need to add those tests [07:39] all interfaces need tests :) [07:39] so ... just saying [07:40] Hi! [07:40] hey Moruy [07:41] Can I set up a package mirror snap? [07:42] zyga: I know, but will skip that until we're at that point :-) [07:42] Moruy: would you like to mirror snap packages or install a snap that mirrors some other packages? [07:44] I want to mirror that "https://api.snapcraft.io/", but it's locked in source code. [07:45] Moruy: you want to deploy this instead: https://forum.snapcraft.io/t/announcing-snap-enterprise-proxy-beta/4666 [07:45] you cannot mirror api.snapcraft.io as it is not a static website [07:48] Frankly, I want setup up a mirror that similar with docker mirror. [07:48] you cannot mirror the snap store, the only supported configuration is local deployment of a snap proxy [07:50] reverse proxy? [07:50] please read the post I linked to [07:52] (ಥ⌣ಥ) [07:52] Is there some way to purge old revisions of snaps in one go? [07:52] I have run out of disk space, and the old revisions are eating a ton of it [07:53] popey: nope, I don't think there is [07:53] :( [07:54] 24G /var/lib/snapd/snaps/ [07:54] popey: find the top three using ncdu [07:54] and remove those specifically [07:54] that's not very user friendly [07:54] (and yes, I already did that) [07:57] Enterprise Proxy is so complex and I will try reverse proxy to mirror it. [07:57] it won't work Moruy [07:59] https://forum.snapcraft.io/t/configure-number-of-old-revisions-to-keep/2337/4 [07:59] :( [08:02] api.snapcraft.io low download speed, it not has any CDN using. [08:02] Moruy: all downloads are using the CDN [08:03] PR snapd#5204 opened: data: add helper that can generate/start/stop the snapd service [08:03] zyga: ^- this is based on what we talked about yesterday [08:03] yep, looking [08:03] sigh [08:03] where are google credentials for spread stored? [08:03] * zyga cannot find them [08:06] moin moin [08:07] zyga: travis secrets maybe? [08:07] mvo: one thing that core18 needs, that I don't know a tidy way of getting it there short of forking, is the system-shutdown helper [08:07] no, it's that thing you need to keep somewhere on your disk [08:08] mvo: … although, it's copied every time, so maybe just copy it from the snapd snap [08:08] hmm [08:09] Chipaca: yeah, it seems like we can run it from the snapd snap [08:09] mvo: reviewed [08:10] zyga: thank you [08:10] Chipaca: the PR is just opened is about making our service work on bases, we probably need to plug it in there (also repairs and all the other services we use) [08:10] How terrible is this? https://www.irccloud.com/pastebin/MMTaDh6u/purge_old_snap_revisions.sh [08:10] ^ zyga / Chipaca - opinions? [08:11] popey: I have *lots* of opinions [08:11] * Chipaca clicks the link [08:11] I don't think you need to close all snaps [08:11] what if I still have a snap running [08:11] disables snaps don't run [08:11] like firefox which I have running for days, and it's refreshed already [08:11] *disabled [08:11] ahhh [08:11] bummer :) [08:12] popey: it won't be happy if you do [08:12] popey: OTOH, we also do it [08:12] so, it won't be super sad either [08:12] warning is really just ass-covering [08:12] 12G /var/lib/snapd/snaps/ [08:12] it's halved the amount of space used [08:12] (I ran it before you reviewed it) :) [08:13] popey: the idea is sane [08:13] zyga: thanks for the review. I ran it on a core18 system. why? anything that looks suspicious? [08:13] thanks [08:13] mvo: no, I just was curious since we don't have any automated feedback yet [08:14] popey: I'd criticise the shell, but if it works and it's just a personal tool it's probably fine [08:14] zyga: yeah, I was thinking what can be done, spread testing this at this point is hard :/ or a bit theoretical, i.e. I could very that the output looks vaguely correct but the real start is harder [08:14] So you don't think it's a good idea to share it Chipaca ? [08:14] (people *keep* asking for this feature) [08:15] popey: in its present state, yes don't share it [08:15] popey: making it robust and sharing it, … a little torn about it [08:15] making it a feature and releasing it [08:15] snap remove --disabled [08:16] would be nice to have a "snap set system.keep-revision=" option [08:16] yeah, i'd rather do that :-) [08:16] both things [08:16] in fact, today's friday, means we can do 20% stuff right? [08:16] meanwhile, disks are ffilling up :) [08:16] ohh [08:16] Friday [08:16] coming back from holidays mid week is weird [08:16] I thought it is Tuesday [08:16] zyga: it's not friday for you! you've had too much fun [08:16] * Chipaca takes away zyga's friday rights [08:17] * Chipaca adds extra tails to his whip [08:17] Chipaca: I await the day when we are both at a bar in Spain and have a beer together watching the sea quietly shimmer outside [08:17] Chipaca: (the sea in Spain is oddly silent) [08:18] zyga: in barcelona, yeah [08:18] long beach [08:18] other places not so much [08:19] Chipaca: at this point the only question is "when" [08:20] zyga: either in the next month, or not for a ~year [08:20] judging by past performance of the home office [08:21] popey: how about: https://pastebin.ubuntu.com/p/6KWZXtJWwS/ [08:21] mvo: one tiny tiny nitpick re 5183 (feel free to ignore) [08:21] * Moruy [08:22] Chipaca: oh, that's prettier. I like that. Thanks, learned something too :) <3 [08:22] popey: shellcheck says I should use -r on the read, but I don't know if that's portable [08:22] popey: also, it needs a comment about GDPR complaince just before 'set -eu' [08:23] lulz [08:23] Chipaca: https://askubuntu.com/questions/1036633/how-to-remove-disabled-unused-snap-packages-with-a-single-line-of-command [08:23] earn some karma by pasting it there :) [08:23] Chipaca: you're clearly excluding 'eu', so no gdpr notice needed [08:24] pstolowski: thank you for the review. I think I can just remove those line and it makes sense to cleanup the control file too [08:25] Chipaca: LOL [08:25] * zyga googles for those google credentials [08:28] Chipaca: remember when I was playing with flatpak edit? [08:28] gedit [08:28] popey: https://askubuntu.com/a/1040131/711 [08:28] I just noticed that left ~/.var on my disk [08:29] with lots of goo inside [08:29] * popey upvotes [08:29] thanks Chipaca [08:29] zyga: are you looking for ~/.config/gcloud/application_default_credentials.json ? or something else [08:29] ah [08:29] yes, thank you pedronis ! [08:30] popey: I dount this will get me over the 10k hump though :-) [08:30] Chipaca: there are a thousand other snap questions you could answer :) [08:30] which would [08:31] popey: I got very demotivated last time I did a round of questions there as there were a lot about how much my work sucks [08:31] popey: but i'll give it another go sometime soon (or you can point me at 'em) [08:31] we have a bot in our slack channel which announces them all every morning to motivate us to answer them. [08:33] https://askubuntu.com/unanswered/tagged/snap?tab=noanswers [08:33] ones with no answers, tagged with snap. === chihchun_afk is now known as chihchun [09:03] popey: if you know somebody in jetbrains, maybe forward https://askubuntu.com/q/988315/711 to them [09:05] popey: in askubuntu, how do you flag something that should be a bug report instead? [09:05] it's not 'too broad' -- it's too narrow :-) [09:06] mmh, pstolowski, I had forgotten but auto-connect was simply ignoring conflicts, it still seems right tbh [09:06] so only reconnect could have this bug [09:07] looking [09:09] pedronis: hmm, yes and no.. we would never auto-connect in case of conflict, no? [09:09] pstolowski: don't we have a test exactly about that? [09:10] jdstrand: if you're feeling lyrical, https://askubuntu.com/q/789231/711 [09:11] * zyga takes the dog out [09:16] pedronis: indeed we have. now i wonder if the test is doing the right think, or if there is something else [09:16] *thing [09:16] pstolowski: by definition if we reached autoconnect we are done with our link-snap and setup-profiles, otoh the other side if it's conflicting hasn't [09:16] pedronis: right, that's it [09:16] pstolowski: so it will do autoconnect later and shouldn't get a conflict [09:17] and it will actually prevent running everything twice i think [09:17] yes [09:18] okay, so probabaly i shouldn't touch autoconnect logic [09:18] but you changed ConnectOnInstall [09:18] so you need to do something [09:19] yes [09:19] pstolowski: btw the same logic would probably also have worked for reconnect [09:19] except reconnect is less best-effort [09:19] than autoconnect [09:19] so not sure we can trust the fact that the other side will do reconnect [09:21] also probably we care about errors more [09:23] yes [09:25] pstolowski: otoh we wouldn't need the helper, and also doing things twice is strange problematic on its own [09:25] even for reconnect [09:30] pstolowski: anyway I think we should indeed put back autoconnect to ignore error/conflicts [09:30] pstolowski: keep the full new logic only for reconnect [09:37] pstolowski: added a couple of comments about this [09:37] thanks [09:42] PR snapd#5183 closed: snapcraft.yaml: add minimal snapcraft.yaml with custom build [09:46] PR snapd#5205 opened: packaging: fix description [09:47] is there a hook firing when a new revision is applied? [09:48] I mean when a snap get refressed/upgraded can I run anything? [09:52] its the configure hook [10:00] pstolowski: question: on reconnect the hook see the dynamic attributes as set on connect, right? not just the static ones? [10:01] pedronis: yes, the will come from prepare- hook [10:01] *they [10:01] pstolowski: no, that is not what I mean [10:01] I probably should look at the code [10:02] pedronis: it should see potentially new attributes as that's the goal of reconnect [10:02] but perhaps i misunderstand the question [10:03] pstolowski: it doesn't [10:03] pstolowski: I thought that on a reconnect we would set the dynamic attributes as their are on the connection that is redone [10:03] but it seems we start from scratch [10:03] yes we start from scratch [10:04] pstolowski: the issue is if the slot side reserve some resource on connect, it willl do it again on reconnect [10:04] there should be a way for it to reuse the same resource [10:04] one way would be to give the last set state of the dynamic attrs [10:04] maybe there's another way [10:04] but starting completely from scratch [10:05] seems too simple [10:06] pedronis: perhaps we should run disconnect hooks then [10:06] pstolowski: it it picks a new resources the slot wouldn't even know the old one is not in use anymore [10:06] otherwise we have same problem as discussed before with undoing stuff [10:06] pstolowski: then it really becomes disconnect/connect [10:06] it would work, but seems inefficent [10:06] * zyga made some ice coffee [10:06] today is a pretty hot day [10:07] pedronis: when validating uniqueness of appstream-ids, we'll bail out only during snap pack --check-skeleton, but when installing a snap we'd just log something, does that sound ok? [10:07] pedronis: yes it would definately be inefficient and add even more hooks run every time [10:07] pstolowski: :( [10:07] pstolowski: anyway, do you see the problem I'm describing? [10:07] pedronis: we can pass existing values, it just adds more complexity for hook authors [10:07] pedronis: yes yes [10:08] mborzecki: do we have other things we treat like that? hard error on pack, just logged on install? [10:09] pedronis: i don't think so [10:09] mborzecki: so maybe not [10:09] just error [10:09] in both cases [10:09] fair enough [10:10] i mean review tools should probably catch this, so such snap would not be in he store anyway [10:10] mborzecki: yea, I pinged jdstrand in the forum about that [10:10] (hopefully?) [10:10] mborzecki: anyway atm there are not many snaps with this set [10:10] yup, fair point [10:11] hmm, shouldn't "snap get system refresh.timer" work? [10:11] well, i know of telegram for sure, and there's also one that i just published tests-snapd-appstreamid [10:11] wow, some heavy rain [10:11] like in some jungle :) [10:11] maciek@galeon:~ sudo snap get system refresh.timer [10:11] 00:00-24:00/192 [10:11] Chipaca: ^^ [10:12] mborzecki: it doesn't here [10:12] did we stopped storing it in the config if it's the default? [10:12] and the error message is rather poor [10:12] Chipaca: what does it say? [10:12] $ snap get system refresh.keep-inactive [10:12] error: snap "core" has no "refresh" configuration option [10:12] I don't have either schedule or timer [10:13] aah ok, you've never set it [10:13] in my refresh config [10:13] er, well, same with .timer :-) [10:13] Chipaca: can you try set and then get ? [10:13] Chipaca: snap refresh --time prints it though? [10:13] pedronis: yes [10:13] mborzecki: sure, if i set it it works [10:14] mborzecki: the issue is that at some point at least for schedule we were setting it in the config even when we picked the default [10:14] Chipaca: or snap get system -d [10:14] pedronis: yeah, iirc it was set as in set-set, but then that went away when refresh timer was introduced with the comment that we should not set it if it's unset [10:15] Chipaca: ^ [10:17] PR snapd#5206 opened: get-deps: work with an unset GOPATH too [10:21] mvo your simple pr failed with [10:21] The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over). [10:22] PR snapd#5207 opened: overlord/{config,snap}state: the number of inactive revisions is config [10:23] ^ 'snap set system refresh.keep-inactive=99' (for popey) [10:23] can we get that -v filter-out PR merged? [10:24] zyga: do we know it helps? it's been -v since forever, what did change? [10:25] I still find a bit too hackish [10:25] we spawn more machines [10:25] ? [10:25] so if something fails early we see all the goo out of package building multiplied numerous times (per machine) [10:25] I ran dpkg-buildpackage and it's far shorter now [10:25] try it, it's really much more readable [10:40] zyga: I enjoyed getting all the emojis way too much [10:40] it's a high bar, but I will strive for it more often [10:57] PR snapd#5208 opened: interface hooks: update old AutoConnect methods [11:02] pstolowski: do you need more input from me? connect vs reconnect state is probably something to mention at the standup [11:03] pedronis: indeed; no, thank you for the review [11:17] Chipaca: btw, do I remember correctly that we still need to give proper error codes to conflict errors? [11:24] mvo: do have a SRU in progress for xenial? [11:26] Chipaca: s/code/kind/ [11:30] pedronis: possibly [11:31] pedronis: we also have not advanced returning error kinds on async jobs [11:34] Chipaca: is that related? [11:35] pedronis: I don't know the context of your question :-) so, maybe [11:35] Chipaca: we get conflict error because creating the changes, no? [11:35] I do remember you had a case for returning errors on async [11:35] pedronis: s/because/before/ yes [11:36] so they should be async indeed [11:36] i mean sync [11:36] heh [11:36] but I don't remember what it was [11:37] Chipaca: hey, question [11:37] how to debug completion tests? [11:37] better yet [11:37] I'm in the debug shell [11:37] how do I run them? [11:37] zyga: https://forum.snapcraft.io/t/debugging-tab-completion/4198 ? [11:37] zyga: ah [11:38] failure log https://www.irccloud.com/pastebin/yC9IEnv0/ [11:38] zyga: expect -d -f thefailingthing.exp [11:38] zyga: or drop the -d to understand the error, then add it back to understand why the error [11:40] I need to export those variables? [11:40] zyga: which variables? [11:40] OUT, KEY etc [11:40] otherwise I get an error instantly [11:41] after setting some vars [11:41] more errors https://www.irccloud.com/pastebin/9NmWJCbi/ [11:41] zyga: ah, sorry was looking at the main/completion [11:42] zyga: yes, look at task.yaml for that [11:43] zyga: that last one is an error? [11:43] that looks like success to me [11:43] maybe i'm missing something [11:44] does anything in https://api.travis-ci.org/v3/job/378833810/log.txt look like an error? [11:44] zyga: in the first thing you pasted there was an error [11:44] 05:10 < pedronis> mborzecki: yea, I pinged jdstrand in the forum about that [11:44] pedronis: I just came online, but may have missed it if it wasn't last night. what topic? ^ [11:44] zyga: 'does <....> match <..>? no\n timed out' [11:45] zyga: that's what errors look like [11:45] jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327 [11:45] Chipaca: honestly all those tests look like magic to me [11:45] and I have no idea why it fails [11:45] zyga: it failed because it completed nothing [11:45] zyga: why did it complete nothing? can you reproduce that? [11:46] jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327/29 [11:46] Chipaca: ... perhaps? tell me what to do [11:46] zyga: standing in that directory, type test-snapd-complexion [11:46] the branch enables apparmor [11:46] but I don't see any denials [11:46] ok [11:46] jdstrand: it's about review-tools checking that common-id doesn't get repeated across apps in the same snap [11:46] zyga: it should offer 'a/ b/ bar baz d/ foo' [11:46] zyga: (same as 'ls ' would) [11:47] google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion [11:47] test-snapd-complexion test-snapd-complexion.two [11:47] it seems it doesn't [11:47] (i lied, ls wouldn't) [11:47]