=== Guest76648 is now known as icey | ||
mborzecki | morning | 05:07 |
---|---|---|
zyga | good morning | 05:44 |
mvo | hey zyga | 05:44 |
zyga | wow, I had a good sleep today | 05:44 |
zyga | I woke up, looked outside and noticed it's not dark anymore | 05:44 |
zyga | and it was about 4AM | 05:44 |
zyga | mvo: I have a small proposal in 5202 | 05:45 |
zyga | might make reviewing logs a little bit less frustrating | 05:45 |
mvo | zyga: yeah, I saw that | 05:45 |
mvo | zyga: was just about to comment | 05:45 |
mup | PR snapd#5201 closed: interfaces/apparmor: use helper to load stray profile <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5201> | 05:49 |
mborzecki | mvo: zyga: hey | 05:49 |
mborzecki | zyga: thanks for doing the renames in 5199 | 05:50 |
zyga | :-) | 05:50 |
zyga | ooooh! | 05:50 |
zyga | finally!!! | 05:50 |
* zyga got an email that his 3d printer has shipped | 05:51 | |
zyga | after months of waiting | 05:51 |
zyga | I suspect this means that weekend will be spent on "some assembly required" | 05:52 |
zyga | mborzecki: can you please have a 2nd look on 5155 | 05:53 |
mborzecki | looking | 05:54 |
zyga | I bought a USB-C power bank at the airport | 05:54 |
zyga | it works with laptops and phones alike so I was looking forward to use it with my thinkpad | 05:55 |
zyga | 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 |
mvo | hey mborzecki good morning | 05:55 |
zyga | the power bank has fantastic reviews all around and works everywhere else | 05:55 |
zyga | a bit of a sigh :) | 05:55 |
zyga | so I will go on a type-c bug hunt to see why | 05:56 |
zyga | I just found this interesting that in the future, even charging needs a non-trivial stack of software that must work just right | 05:56 |
=== chihchun_afk is now known as chihchun | ||
mborzecki | pedronis: added tests for setup-profiles undo in #4996 | 06:42 |
mup | PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996> | 06:42 |
mup | PR snapd#5143 closed: tests: speed up save/restore snapd state for all-snap systems during tests execution <Squash-merge> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5143> | 06:48 |
zyga | 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:49 |
zyga | tests are rather red today | 06:50 |
zyga | and often end with | 06:50 |
zyga | 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 |
mvo | zyga: yes, first point release | 06:50 |
zyga | ah, thanks for confirming that | 06:51 |
mvo | zyga: testsuite> anything in particular you noticed? when I looked earlier it was some repo that could not be cloned | 06:52 |
zyga | the thing is, I don't know, it's just red and overflowing logs | 06:52 |
zyga | I've yet to find an efficient way to find what broke | 06:52 |
zyga | eh | 07:00 |
* 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 | |
mvo | bugs via email ftw :/ | 07:01 |
zyga | debian FTW | 07:01 |
zyga | well, it should show up here, eventually: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=dh-golang;dist=unstable | 07:02 |
mborzecki | new TLD debian-9 :) | 07:04 |
mvo | hm, having .ubuntu as a TLD would be cool | 07:04 |
=== pstolowski|afk is now known as pstolowski | ||
pstolowski | morning | 07:04 |
mvo | hey pstolowski | 07:05 |
mborzecki | pstolowski: hey | 07:05 |
mborzecki | mvo: ICANN awaits your application :P | 07:05 |
zyga | morphis: hey, andbox-support PR needs some love | 07:05 |
mvo | mborzecki: heh, maybe a bit too much work for my free evenings ;) | 07:05 |
zyga | mvo: it's just 5000 and you own it | 07:06 |
zyga | custom TLD were approved a while a go | 07:06 |
mborzecki | zyga: 5000 of what currency? | 07:06 |
zyga | USD AFAIK | 07:06 |
mvo | zyga: yeah, but you also need to make some comitments technically iirc, no? I don't remember the details though | 07:06 |
mborzecki | heh, doped to dogecoins :) | 07:07 |
mborzecki | s/doped/hoped/ | 07:07 |
zyga | oh | 07:07 |
zyga | it's more pricy than that | 07:07 |
zyga | $185,000 | 07:09 |
zyga | ouch | 07:09 |
mvo | autsch indeed | 07:11 |
zyga | journal cursors break some tests | 07:35 |
zyga | it looks like buffering is in theway | 07:35 |
mborzecki | iirc there's a --sync flag but it didn't work on 14.04 or sth | 07:36 |
mborzecki | anyways, in snapd-notify test, i think it'd be better to systemctl show -p SubState and ActiveState directly | 07:37 |
zyga | it failed on a totally unrelated test now | 07:37 |
morphis | 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 |
zyga | morphis: ack | 07:39 |
morphis | the PR might go into a completely different direction | 07:39 |
zyga | you still need to add those tests | 07:39 |
zyga | all interfaces need tests :) | 07:39 |
zyga | so ... just saying | 07:39 |
Moruy | Hi! | 07:40 |
zyga | hey Moruy | 07:40 |
Moruy | Can I set up a package mirror snap? | 07:41 |
morphis | zyga: I know, but will skip that until we're at that point :-) | 07:42 |
zyga | Moruy: would you like to mirror snap packages or install a snap that mirrors some other packages? | 07:42 |
Moruy | I want to mirror that "https://api.snapcraft.io/", but it's locked in source code. | 07:44 |
zyga | Moruy: you want to deploy this instead: https://forum.snapcraft.io/t/announcing-snap-enterprise-proxy-beta/4666 | 07:45 |
zyga | you cannot mirror api.snapcraft.io as it is not a static website | 07:45 |
Moruy | Frankly, I want setup up a mirror that similar with docker mirror. | 07:48 |
zyga | you cannot mirror the snap store, the only supported configuration is local deployment of a snap proxy | 07:48 |
Moruy | reverse proxy? | 07:50 |
zyga | please read the post I linked to | 07:50 |
Moruy | (ಥ⌣ಥ) | 07:52 |
popey | Is there some way to purge old revisions of snaps in one go? | 07:52 |
popey | I have run out of disk space, and the old revisions are eating a ton of it | 07:52 |
zyga | popey: nope, I don't think there is | 07:53 |
popey | :( | 07:53 |
popey | 24G /var/lib/snapd/snaps/ | 07:54 |
zyga | popey: find the top three using ncdu | 07:54 |
zyga | and remove those specifically | 07:54 |
popey | that's not very user friendly | 07:54 |
popey | (and yes, I already did that) | 07:54 |
Moruy | Enterprise Proxy is so complex and I will try reverse proxy to mirror it. | 07:57 |
zyga | it won't work Moruy | 07:57 |
popey | https://forum.snapcraft.io/t/configure-number-of-old-revisions-to-keep/2337/4 | 07:59 |
popey | :( | 07:59 |
Moruy | api.snapcraft.io low download speed, it not has any CDN using. | 08:02 |
zyga | Moruy: all downloads are using the CDN | 08:02 |
mup | PR snapd#5204 opened: data: add helper that can generate/start/stop the snapd service <Created by mvo5> <https://github.com/snapcore/snapd/pull/5204> | 08:03 |
mvo | zyga: ^- this is based on what we talked about yesterday | 08:03 |
zyga | yep, looking | 08:03 |
zyga | sigh | 08:03 |
zyga | where are google credentials for spread stored? | 08:03 |
* zyga cannot find them | 08:03 | |
Chipaca | moin moin | 08:06 |
mborzecki | zyga: travis secrets maybe? | 08:07 |
Chipaca | 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 |
zyga | no, it's that thing you need to keep somewhere on your disk | 08:07 |
Chipaca | mvo: … although, it's copied every time, so maybe just copy it from the snapd snap | 08:08 |
Chipaca | hmm | 08:08 |
mvo | Chipaca: yeah, it seems like we can run it from the snapd snap | 08:09 |
zyga | mvo: reviewed | 08:09 |
mvo | zyga: thank you | 08:10 |
mvo | 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 |
popey | How terrible is this? https://www.irccloud.com/pastebin/MMTaDh6u/purge_old_snap_revisions.sh | 08:10 |
popey | ^ zyga / Chipaca - opinions? | 08:10 |
Chipaca | popey: I have *lots* of opinions | 08:11 |
* Chipaca clicks the link | 08:11 | |
zyga | I don't think you need to close all snaps | 08:11 |
popey | what if I still have a snap running | 08:11 |
zyga | disables snaps don't run | 08:11 |
popey | like firefox which I have running for days, and it's refreshed already | 08:11 |
zyga | *disabled | 08:11 |
zyga | ahhh | 08:11 |
zyga | bummer :) | 08:11 |
Chipaca | popey: it won't be happy if you do | 08:12 |
Chipaca | popey: OTOH, we also do it | 08:12 |
Chipaca | so, it won't be super sad either | 08:12 |
popey | warning is really just ass-covering | 08:12 |
popey | 12G /var/lib/snapd/snaps/ | 08:12 |
popey | it's halved the amount of space used | 08:12 |
popey | (I ran it before you reviewed it) :) | 08:12 |
Chipaca | popey: the idea is sane | 08:13 |
mvo | zyga: thanks for the review. I ran it on a core18 system. why? anything that looks suspicious? | 08:13 |
popey | thanks | 08:13 |
zyga | mvo: no, I just was curious since we don't have any automated feedback yet | 08:13 |
Chipaca | popey: I'd criticise the shell, but if it works and it's just a personal tool it's probably fine | 08:14 |
mvo | 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 |
popey | So you don't think it's a good idea to share it Chipaca ? | 08:14 |
popey | (people *keep* asking for this feature) | 08:14 |
Chipaca | popey: in its present state, yes don't share it | 08:15 |
Chipaca | popey: making it robust and sharing it, … a little torn about it | 08:15 |
zyga | making it a feature and releasing it | 08:15 |
zyga | snap remove --disabled | 08:15 |
mvo | would be nice to have a "snap set system.keep-revision=" option | 08:16 |
Chipaca | yeah, i'd rather do that :-) | 08:16 |
Chipaca | both things | 08:16 |
Chipaca | in fact, today's friday, means we can do 20% stuff right? | 08:16 |
popey | meanwhile, disks are ffilling up :) | 08:16 |
zyga | ohh | 08:16 |
zyga | Friday | 08:16 |
zyga | coming back from holidays mid week is weird | 08:16 |
zyga | I thought it is Tuesday | 08:16 |
Chipaca | zyga: it's not friday for you! you've had too much fun | 08:16 |
* Chipaca takes away zyga's friday rights | 08:16 | |
* Chipaca adds extra tails to his whip | 08:17 | |
zyga | 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 |
zyga | Chipaca: (the sea in Spain is oddly silent) | 08:17 |
Chipaca | zyga: in barcelona, yeah | 08:18 |
Chipaca | long beach | 08:18 |
Chipaca | other places not so much | 08:18 |
zyga | Chipaca: at this point the only question is "when" | 08:19 |
Chipaca | zyga: either in the next month, or not for a ~year | 08:20 |
Chipaca | judging by past performance of the home office | 08:20 |
Chipaca | popey: how about: https://pastebin.ubuntu.com/p/6KWZXtJWwS/ | 08:21 |
pstolowski | mvo: one tiny tiny nitpick re 5183 (feel free to ignore) | 08:21 |
* Moruy | 08:21 | |
popey | Chipaca: oh, that's prettier. I like that. Thanks, learned something too :) <3 | 08:22 |
Chipaca | popey: shellcheck says I should use -r on the read, but I don't know if that's portable | 08:22 |
Chipaca | popey: also, it needs a comment about GDPR complaince just before 'set -eu' | 08:22 |
popey | lulz | 08:23 |
popey | Chipaca: https://askubuntu.com/questions/1036633/how-to-remove-disabled-unused-snap-packages-with-a-single-line-of-command | 08:23 |
popey | earn some karma by pasting it there :) | 08:23 |
mborzecki | Chipaca: you're clearly excluding 'eu', so no gdpr notice needed | 08:23 |
mvo | 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:24 |
zyga | Chipaca: LOL | 08:25 |
* zyga googles for those google credentials | 08:25 | |
zyga | Chipaca: remember when I was playing with flatpak edit? | 08:28 |
zyga | gedit | 08:28 |
Chipaca | popey: https://askubuntu.com/a/1040131/711 | 08:28 |
zyga | I just noticed that left ~/.var on my disk | 08:28 |
zyga | with lots of goo inside | 08:29 |
* popey upvotes | 08:29 | |
popey | thanks Chipaca | 08:29 |
pedronis | zyga: are you looking for ~/.config/gcloud/application_default_credentials.json ? or something else | 08:29 |
zyga | ah | 08:29 |
zyga | yes, thank you pedronis ! | 08:29 |
Chipaca | popey: I dount this will get me over the 10k hump though :-) | 08:30 |
popey | Chipaca: there are a thousand other snap questions you could answer :) | 08:30 |
popey | which would | 08:30 |
Chipaca | 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 |
Chipaca | popey: but i'll give it another go sometime soon (or you can point me at 'em) | 08:31 |
popey | we have a bot in our slack channel which announces them all every morning to motivate us to answer them. | 08:31 |
popey | https://askubuntu.com/unanswered/tagged/snap?tab=noanswers | 08:33 |
popey | ones with no answers, tagged with snap. | 08:33 |
=== chihchun_afk is now known as chihchun | ||
Chipaca | popey: if you know somebody in jetbrains, maybe forward https://askubuntu.com/q/988315/711 to them | 09:03 |
Chipaca | popey: in askubuntu, how do you flag something that should be a bug report instead? | 09:05 |
Chipaca | it's not 'too broad' -- it's too narrow :-) | 09:05 |
pedronis | mmh, pstolowski, I had forgotten but auto-connect was simply ignoring conflicts, it still seems right tbh | 09:06 |
pedronis | so only reconnect could have this bug | 09:06 |
pstolowski | looking | 09:07 |
pstolowski | pedronis: hmm, yes and no.. we would never auto-connect in case of conflict, no? | 09:09 |
pedronis | pstolowski: don't we have a test exactly about that? | 09:09 |
Chipaca | jdstrand: if you're feeling lyrical, https://askubuntu.com/q/789231/711 | 09:10 |
* zyga takes the dog out | 09:11 | |
pstolowski | pedronis: indeed we have. now i wonder if the test is doing the right think, or if there is something else | 09:16 |
pstolowski | *thing | 09:16 |
pedronis | 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 |
pstolowski | pedronis: right, that's it | 09:16 |
pedronis | pstolowski: so it will do autoconnect later and shouldn't get a conflict | 09:16 |
pstolowski | and it will actually prevent running everything twice i think | 09:17 |
pedronis | yes | 09:17 |
pstolowski | okay, so probabaly i shouldn't touch autoconnect logic | 09:18 |
pedronis | but you changed ConnectOnInstall | 09:18 |
pedronis | so you need to do something | 09:18 |
pstolowski | yes | 09:19 |
pedronis | pstolowski: btw the same logic would probably also have worked for reconnect | 09:19 |
pedronis | except reconnect is less best-effort | 09:19 |
pedronis | than autoconnect | 09:19 |
pedronis | so not sure we can trust the fact that the other side will do reconnect | 09:19 |
pedronis | also probably we care about errors more | 09:21 |
pstolowski | yes | 09:23 |
pedronis | pstolowski: otoh we wouldn't need the helper, and also doing things twice is strange problematic on its own | 09:25 |
pedronis | even for reconnect | 09:25 |
pedronis | pstolowski: anyway I think we should indeed put back autoconnect to ignore error/conflicts | 09:30 |
pedronis | pstolowski: keep the full new logic only for reconnect | 09:30 |
pedronis | pstolowski: added a couple of comments about this | 09:37 |
pstolowski | thanks | 09:37 |
mup | PR snapd#5183 closed: snapcraft.yaml: add minimal snapcraft.yaml with custom build <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5183> | 09:42 |
mup | PR snapd#5205 opened: packaging: fix description <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5205> | 09:46 |
kjackal | is there a hook firing when a new revision is applied? | 09:47 |
kjackal | I mean when a snap get refressed/upgraded can I run anything? | 09:48 |
kjackal | its the configure hook | 09:52 |
pedronis | pstolowski: question: on reconnect the hook see the dynamic attributes as set on connect, right? not just the static ones? | 10:00 |
pstolowski | pedronis: yes, the will come from prepare- hook | 10:01 |
pstolowski | *they | 10:01 |
pedronis | pstolowski: no, that is not what I mean | 10:01 |
pedronis | I probably should look at the code | 10:01 |
pstolowski | pedronis: it should see potentially new attributes as that's the goal of reconnect | 10:02 |
pstolowski | but perhaps i misunderstand the question | 10:02 |
pedronis | pstolowski: it doesn't | 10:03 |
pedronis | pstolowski: I thought that on a reconnect we would set the dynamic attributes as their are on the connection that is redone | 10:03 |
pedronis | but it seems we start from scratch | 10:03 |
pstolowski | yes we start from scratch | 10:03 |
pedronis | pstolowski: the issue is if the slot side reserve some resource on connect, it willl do it again on reconnect | 10:04 |
pedronis | there should be a way for it to reuse the same resource | 10:04 |
pedronis | one way would be to give the last set state of the dynamic attrs | 10:04 |
pedronis | maybe there's another way | 10:04 |
pedronis | but starting completely from scratch | 10:04 |
pedronis | seems too simple | 10:05 |
pstolowski | pedronis: perhaps we should run disconnect hooks then | 10:06 |
pedronis | pstolowski: it it picks a new resources the slot wouldn't even know the old one is not in use anymore | 10:06 |
pstolowski | otherwise we have same problem as discussed before with undoing stuff | 10:06 |
pedronis | pstolowski: then it really becomes disconnect/connect | 10:06 |
pedronis | it would work, but seems inefficent | 10:06 |
* zyga made some ice coffee | 10:06 | |
zyga | today is a pretty hot day | 10:06 |
mborzecki | 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 |
pstolowski | pedronis: yes it would definately be inefficient and add even more hooks run every time | 10:07 |
pedronis | pstolowski: :( | 10:07 |
pedronis | pstolowski: anyway, do you see the problem I'm describing? | 10:07 |
pstolowski | pedronis: we can pass existing values, it just adds more complexity for hook authors | 10:07 |
pstolowski | pedronis: yes yes | 10:07 |
pedronis | mborzecki: do we have other things we treat like that? hard error on pack, just logged on install? | 10:08 |
mborzecki | pedronis: i don't think so | 10:09 |
pedronis | mborzecki: so maybe not | 10:09 |
pedronis | just error | 10:09 |
pedronis | in both cases | 10:09 |
mborzecki | fair enough | 10:09 |
mborzecki | i mean review tools should probably catch this, so such snap would not be in he store anyway | 10:10 |
pedronis | mborzecki: yea, I pinged jdstrand in the forum about that | 10:10 |
mborzecki | (hopefully?) | 10:10 |
pedronis | mborzecki: anyway atm there are not many snaps with this set | 10:10 |
mborzecki | yup, fair point | 10:10 |
Chipaca | hmm, shouldn't "snap get system refresh.timer" work? | 10:11 |
mborzecki | well, i know of telegram for sure, and there's also one that i just published tests-snapd-appstreamid | 10:11 |
zyga | wow, some heavy rain | 10:11 |
zyga | like in some jungle :) | 10:11 |
mborzecki | maciek@galeon:~ sudo snap get system refresh.timer | 10:11 |
mborzecki | 00:00-24:00/192 | 10:11 |
mborzecki | Chipaca: ^^ | 10:11 |
pedronis | mborzecki: it doesn't here | 10:12 |
pedronis | did we stopped storing it in the config if it's the default? | 10:12 |
Chipaca | and the error message is rather poor | 10:12 |
mborzecki | Chipaca: what does it say? | 10:12 |
Chipaca | $ snap get system refresh.keep-inactive | 10:12 |
Chipaca | error: snap "core" has no "refresh" configuration option | 10:12 |
pedronis | I don't have either schedule or timer | 10:12 |
mborzecki | aah ok, you've never set it | 10:13 |
pedronis | in my refresh config | 10:13 |
Chipaca | er, well, same with .timer :-) | 10:13 |
mborzecki | Chipaca: can you try set and then get ? | 10:13 |
pedronis | Chipaca: snap refresh --time prints it though? | 10:13 |
Chipaca | pedronis: yes | 10:13 |
Chipaca | mborzecki: sure, if i set it it works | 10:13 |
pedronis | 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 |
mborzecki | Chipaca: or snap get system -d | 10:14 |
mborzecki | 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:14 |
pedronis | Chipaca: ^ | 10:15 |
mup | PR snapd#5206 opened: get-deps: work with an unset GOPATH too <Created by mvo5> <https://github.com/snapcore/snapd/pull/5206> | 10:17 |
zyga | mvo your simple pr failed with | 10:21 |
zyga | 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:21 |
mup | PR snapd#5207 opened: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <https://github.com/snapcore/snapd/pull/5207> | 10:22 |
Chipaca | ^ 'snap set system refresh.keep-inactive=99' (for popey) | 10:23 |
zyga | can we get that -v filter-out PR merged? | 10:23 |
pedronis | zyga: do we know it helps? it's been -v since forever, what did change? | 10:24 |
pedronis | I still find a bit too hackish | 10:25 |
zyga | we spawn more machines | 10:25 |
pedronis | ? | 10:25 |
zyga | so if something fails early we see all the goo out of package building multiplied numerous times (per machine) | 10:25 |
zyga | I ran dpkg-buildpackage and it's far shorter now | 10:25 |
zyga | try it, it's really much more readable | 10:25 |
Chipaca | zyga: I enjoyed getting all the emojis way too much | 10:40 |
Chipaca | it's a high bar, but I will strive for it more often | 10:40 |
mup | PR snapd#5208 opened: interface hooks: update old AutoConnect methods <Created by stolowski> <https://github.com/snapcore/snapd/pull/5208> | 10:57 |
pedronis | pstolowski: do you need more input from me? connect vs reconnect state is probably something to mention at the standup | 11:02 |
pstolowski | pedronis: indeed; no, thank you for the review | 11:03 |
pedronis | Chipaca: btw, do I remember correctly that we still need to give proper error codes to conflict errors? | 11:17 |
pedronis | mvo: do have a SRU in progress for xenial? | 11:24 |
pedronis | Chipaca: s/code/kind/ | 11:26 |
Chipaca | pedronis: possibly | 11:30 |
Chipaca | pedronis: we also have not advanced returning error kinds on async jobs | 11:31 |
pedronis | Chipaca: is that related? | 11:34 |
Chipaca | pedronis: I don't know the context of your question :-) so, maybe | 11:35 |
pedronis | Chipaca: we get conflict error because creating the changes, no? | 11:35 |
pedronis | I do remember you had a case for returning errors on async | 11:35 |
Chipaca | pedronis: s/because/before/ yes | 11:35 |
Chipaca | so they should be async indeed | 11:36 |
Chipaca | i mean sync | 11:36 |
Chipaca | heh | 11:36 |
pedronis | but I don't remember what it was | 11:36 |
zyga | Chipaca: hey, question | 11:37 |
zyga | how to debug completion tests? | 11:37 |
zyga | better yet | 11:37 |
zyga | I'm in the debug shell | 11:37 |
zyga | how do I run them? | 11:37 |
Chipaca | zyga: https://forum.snapcraft.io/t/debugging-tab-completion/4198 ? | 11:37 |
Chipaca | zyga: ah | 11:37 |
zyga | failure log https://www.irccloud.com/pastebin/yC9IEnv0/ | 11:38 |
Chipaca | zyga: expect -d -f thefailingthing.exp | 11:38 |
Chipaca | zyga: or drop the -d to understand the error, then add it back to understand why the error | 11:38 |
zyga | I need to export those variables? | 11:40 |
Chipaca | zyga: which variables? | 11:40 |
zyga | OUT, KEY etc | 11:40 |
zyga | otherwise I get an error instantly | 11:40 |
zyga | after setting some vars | 11:41 |
zyga | more errors https://www.irccloud.com/pastebin/9NmWJCbi/ | 11:41 |
Chipaca | zyga: ah, sorry was looking at the main/completion | 11:41 |
Chipaca | zyga: yes, look at task.yaml for that | 11:42 |
Chipaca | zyga: that last one is an error? | 11:43 |
Chipaca | that looks like success to me | 11:43 |
Chipaca | maybe i'm missing something | 11:43 |
zyga | does anything in https://api.travis-ci.org/v3/job/378833810/log.txt look like an error? | 11:44 |
Chipaca | zyga: in the first thing you pasted there was an error | 11:44 |
jdstrand | 05:10 < pedronis> mborzecki: yea, I pinged jdstrand in the forum about that | 11:44 |
jdstrand | pedronis: I just came online, but may have missed it if it wasn't last night. what topic? ^ | 11:44 |
Chipaca | zyga: 'does <....> match <..>? no\n timed out' | 11:44 |
Chipaca | zyga: that's what errors look like | 11:45 |
mborzecki | jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327 | 11:45 |
zyga | Chipaca: honestly all those tests look like magic to me | 11:45 |
zyga | and I have no idea why it fails | 11:45 |
Chipaca | zyga: it failed because it completed nothing | 11:45 |
Chipaca | zyga: why did it complete nothing? can you reproduce that? | 11:45 |
pedronis | jdstrand: https://forum.snapcraft.io/t/support-for-appstream-id/2327/29 | 11:46 |
zyga | Chipaca: ... perhaps? tell me what to do | 11:46 |
Chipaca | zyga: standing in that directory, type test-snapd-complexion <tab><tab> | 11:46 |
zyga | the branch enables apparmor | 11:46 |
zyga | but I don't see any denials | 11:46 |
zyga | ok | 11:46 |
pedronis | jdstrand: it's about review-tools checking that common-id doesn't get repeated across apps in the same snap | 11:46 |
Chipaca | zyga: it should offer 'a/ b/ bar baz d/ foo' | 11:46 |
Chipaca | zyga: (same as 'ls <tab><tab>' would) | 11:46 |
zyga | google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion | 11:47 |
zyga | test-snapd-complexion test-snapd-complexion.two | 11:47 |
zyga | it seems it doesn't | 11:47 |
Chipaca | (i lied, ls wouldn't) | 11:47 |
Chipaca | zyga: so, tab completion isn't working in opensuse | 11:47 |
zyga | mmm | 11:47 |
Chipaca | zyga: sadface | 11:47 |
* zyga thinks | 11:47 | |
Chipaca | hold on | 11:47 |
zyga | but it used to | 11:47 |
zyga | it's just broken here in this branch | 11:47 |
Chipaca | zyga: did you enabe tab completion in that shell | 11:48 |
Chipaca | enable* | 11:48 |
zyga | oh? no | 11:48 |
zyga | how do I do that? | 11:48 |
pedronis | jdstrand: here's the wip snapd check: https://github.com/snapcore/snapd/pull/5199/commits/17d9cab6366de447c2aa8049a1fd10b05ab947d4 | 11:49 |
mup | PR #5199: many: expose AppStream IDs (AKA common ID) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5199> | 11:49 |
zyga | jdstrand: I fixed 5203 for you | 11:49 |
Chipaca | zyga: if you ls <tab><tab>, does it list things for you? | 11:50 |
zyga | Chipaca: yes | 11:50 |
Chipaca | zyga: ok | 11:50 |
zyga | also tab tab completed the command names above | 11:50 |
zyga | so some part of it must work | 11:50 |
Chipaca | zyga: you need to source one of the .complete files | 11:50 |
pedronis | mborzecki: if the snap is already created you need to ask store admins to transfer it to canonical shared account | 11:50 |
Chipaca | zyga: 1 sec | 11:50 |
zyga | thanks! | 11:50 |
jdstrand | zyga: oh, I was just looking at that | 11:50 |
zyga | I really want to get to the bottom of that | 11:50 |
zyga | to get apparmor operational in opensuse | 11:50 |
zyga | and in general, in more distros that can just opt in | 11:50 |
jdstrand | zyga: thanks | 11:50 |
zyga | jdstrand: :-) | 11:51 |
Chipaca | zyga: source hosts_n_dirs.complete | 11:51 |
zyga | ack | 11:51 |
zyga | done | 11:51 |
Chipaca | zyga: now what does test-snapd-complexion <tab><tab> do | 11:51 |
zyga | it is completing ... ip addresses? | 11:51 |
zyga | google:opensuse-42.3-64 .../tests/completion# test-snapd-complexion | 11:51 |
zyga | ::1 fe00::0 ff02::1 ff02::3 ipv6-allhosts ipv6-allrouters ipv6-localnet ipv6-mcastprefix simple/ | 11:51 |
zyga | data/ ff00::0 ff02::2 indirect/ ipv6-allnodes ipv6-localhost ipv6-loopback localhost snippets/ | 11:51 |
Chipaca | ah, right, 1 sec | 11:52 |
Chipaca | zyga: look at hosts_n_dirs.sh | 11:52 |
Chipaca | zyga: do that :-) | 11:52 |
zyga | ah | 11:52 |
Chipaca | zyga: to be clear, none of this involves apparmor or anything | 11:53 |
zyga | # cat data/hosts.txt | 11:53 |
zyga | 127.1.2.3 foo bar baz | 11:53 |
Chipaca | zyga: at least from the 'simple' side of things, this is just sanity-checking the test suite | 11:53 |
Chipaca | the 'indirect' one does the same via a snap | 11:53 |
Chipaca | and that one does involve the whole dance | 11:54 |
zyga | I see | 11:54 |
zyga | and the .two app? | 11:54 |
zyga | the .two app appears to complete stuff in practice | 11:54 |
zyga | well, they both (main app and .two app) complete the exact same thing | 11:55 |
Chipaca | zyga: that's expected | 11:55 |
Chipaca | zyga: I'll go grab lunch | 11:56 |
zyga | can I trigger the completion failure somehow from this interactive shell? | 11:56 |
zyga | ok | 11:56 |
Chipaca | zyga: i can dig into this after | 11:56 |
zyga | I'll look at the non-completion tests | 11:56 |
zyga | thanks! | 11:56 |
Chipaca | zyga: my memory is stale, probably easier for me to debug it if it's reproducible | 11:56 |
zyga | yeah, all the time | 11:56 |
Chipaca | perfect | 11:56 |
zyga | Chipaca: interestingly, only _some_ have failed | 12:04 |
zyga | many of those work | 12:04 |
Chipaca | zyga: list 'em for me :-) | 12:04 |
zyga | one sec | 12:04 |
zyga | trying to close all other instances | 12:05 |
Chipaca | k | 12:05 |
zyga | failed tests https://www.irccloud.com/pastebin/N38F51o6/ | 12:06 |
Chipaca | zyga: that's all the ones that go through (de)serialization | 12:08 |
zyga | mmm | 12:08 |
Chipaca | zyga: ie all the ones that talk to snap run | 12:08 |
zyga | mm | 12:08 |
zyga | I'll run the non-completion tests (well, running now) and see if there are any hints | 12:08 |
zyga | maybe it's something simple and obviously missing/broken | 12:08 |
Chipaca | ok | 12:09 |
* Chipaca ~> lunch or death | 12:09 | |
mvo | pedronis: there is a SRU in progress for xenial, yes. do we need anything in there? | 12:17 |
pedronis | mvo: no, just wondered, because I noticed snapd there doesn't have SNAPD_BASES_CHANNEL yet afaict | 12:19 |
mvo | pedronis: yeah, its time that 2.33 gets out of the door :) | 12:19 |
mup | PR snapd#5205 closed: packaging: fix description <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5205> | 12:19 |
pedronis | mvo: I think is in one of the 2.33 already | 12:20 |
pedronis | possibly | 12:20 |
pedronis | but yea | 12:20 |
zyga | cachio_: hey, what's the chance of us getting a tumbleweed image? | 12:22 |
mup | PR snapd#5202 closed: packaging: filter out verbose flags from "dh-golang" <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5202> | 12:22 |
zyga | Chipaca: don't waste your time please, I found the issue | 12:25 |
* Chipaca ~> second lunch | 12:25 | |
Chipaca | :-D | 12:25 |
mup | PR snapd#5155 closed: interfaces/apparmor: use strict template on openSUSE tumbleweed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5155> | 12:27 |
pedronis | heh, I meant 2.32 | 12:27 |
mvo | pedronis: indeed, 2.32.3.2 is where we are in xenial I need to chase sergio | 12:28 |
mup | PR snapd#5118 closed: packaging/opensuse: build with apparmor <Squash-merge> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5118> | 12:29 |
pedronis | pstolowski: btw, I'm thinking a bit more, I'm coming to the conclusion that we need to conflict also on connect carefully, I mean the same exact connect should be added at most once to a change | 12:30 |
zyga | cachio_: hey | 12:33 |
zyga | cachio_: can you work with me for a moment, I'd like to build a tumbleweed image for opensuse | 12:33 |
mup | PR snapd#5209 opened: packaging: add packaging for openSUSE Tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/5209> | 12:35 |
mup | PR snapd#5210 opened: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Created by zyga> <https://github.com/snapcore/snapd/pull/5210> | 12:36 |
pstolowski | pedronis: you mean when we do multiple Connects in a single change? | 12:36 |
pedronis | pstolowski: yes, I fear we will get very confused if we are not careful | 12:41 |
pedronis | because of state | 12:41 |
pedronis | and hooks | 12:41 |
pedronis | pstolowski: the connect-plug/slot-* hook cannot change the attributes anymore, is that right? only prepare can change them? | 12:45 |
zyga | https://lwn.net/Articles/755238/ <- entitlements are a little bit like interfaces | 12:48 |
mup | PR snapd#5206 closed: get-deps: work with an unset GOPATH too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5206> | 12:51 |
pstolowski | pedronis: yes | 12:54 |
Chipaca | mvo: MAGIC | 13:06 |
mvo | Chipaca: \o/ | 13:08 |
mup | PR snapd#5211 opened: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5211> | 13:15 |
mup | PR snapd#5200 closed: interfaces: reconnect, fix for autoconnect/reconnect conflict check <Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5200> | 13:21 |
mup | PR snapd#5196 closed: ifacestate: FindSnapsWaitingFor helper <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5196> | 13:24 |
pedronis | pstolowski: let me know if you want to discuss a bit about checking conflicts for connect/disconnect | 13:36 |
pstolowski | pedronis: i've headache.. not the best moment :/ | 13:36 |
pedronis | pstolowski: let's do it on monday then | 13:36 |
pstolowski | thanks | 13:36 |
mup | PR snapd#5210 closed: spread: openSUSE LEAP 42.2 was EOLd in January, remove it <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5210> | 13:36 |
pedronis | pstolowski: and get well! | 13:37 |
pstolowski | will try to propose error handling improvement in the meantime | 13:37 |
pstolowski | thanks1 | 13:37 |
mvo | pstolowski: yeah, get well! | 13:39 |
pstolowski | thanks, it's not too bad | 13:41 |
zyga | niemeyer: can you have a quick look at https://github.com/snapcore/snapd/pull/4889#discussion_r190898209 | 13:45 |
mup | PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/4889> | 13:45 |
niemeyer | Heads up: forum is about to go down for maintenance! | 13:45 |
zyga | jdstrand: is there anything to do more on #5170 | 13:47 |
mup | PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170> | 13:47 |
niemeyer | zyga: I can, but not right now.. forum migration under way | 13:47 |
jdstrand | zyga: I continue to have it on my list for today. keep in mind, it is still morning here ;) | 13:47 |
zyga | jdstrand: no worries, thank you :-) | 13:48 |
mup | PR snapd#5211 closed: snapcraft: use dpkg-buildpackage options that work in xenial <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5211> | 13:53 |
mup | PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162, | 14:04 |
mup | snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209 | 14:04 |
mup | PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5091, snapd#5122, snapd#5162, | 14:05 |
mup | snapd#5170, snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5198, snapd#5199, snapd#5203, snapd#5204, snapd#5207, snapd#5208, snapd#5209 | 14:05 |
mup | PR snapd#5212 opened: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5212> | 14:15 |
niemeyer | Forum migration completed. You may need to hard-refresh or restart your browser for it to see the new IP address. | 14:17 |
zyga | Chipaca, jdstrand: commented on https://askubuntu.com/questions/789231/how-are-snap-applications-being-protected/1040259#1040259 | 14:30 |
* popey upvotes | 14:30 | |
sil2100 | mvo: is there any reason why we're running travis checks for core18 on trusty and not on xenial? | 14:37 |
sil2100 | Just curious | 14:37 |
zyga | sil2100: travis sucks | 14:37 |
zyga | sil2100: no, we should use xenial if we can (there's a switch AFAIK) | 14:37 |
sil2100 | zyga: ok, thanks ;) | 14:47 |
sil2100 | yay travis is now giving some useful info | 14:48 |
zyga | popey: how can I mark one post as a duplicate of another (on askubuntu) | 14:49 |
Pharaoh_Atem | zyga: it'd be interesting if snapd was wired up with centos ci to use spread | 14:50 |
Pharaoh_Atem | https://wiki.centos.org/QaWiki/CI/GettingStarted | 14:50 |
Pharaoh_Atem | https://wiki.centos.org/QaWiki/CI/GithubIntegration | 14:50 |
zyga | what would be the point of that? | 14:50 |
Pharaoh_Atem | some better/more reliable backends for CI | 14:51 |
Pharaoh_Atem | the current CI stuff has been very hokey :/ | 14:52 |
zyga | yes but the problem is everyone has something and then every snapd developer needs to know how to use _each_ of those systems to work | 14:52 |
zyga | yes, I would love to see a general way to build spread images for qemu, google or other systems | 14:52 |
Chipaca | zyga: under the question, click on 'close' | 14:57 |
Chipaca | zyga: there's a "is duplicate of..." option | 14:57 |
zyga | thanks! | 14:58 |
zyga | mvo: | 14:58 |
zyga | what is this? | 14:58 |
zyga | +ExecStartPre=/bin/touch /dev/iio:device0 | 14:58 |
zyga | this is from 73ff712a89aa3bd65ab8b5b23e956413294375c8 | 14:59 |
Chipaca | zyga: a hack to fake a device for a test | 14:59 |
Chipaca | zyga: tests/main/interfaces-iiio | 14:59 |
Chipaca | iio | 14:59 |
Chipaca | io | 14:59 |
Chipaca | o | 14:59 |
zyga | why does this fail? https://www.irccloud.com/pastebin/v4Mm7FrG/ | 15:00 |
zyga | https://www.irccloud.com/pastebin/gywakiP4/ | 15:00 |
zyga | hmmhmmhmm | 15:00 |
mvo | sil2100: no good reason, if we can switch to xenial I'm all for it | 15:13 |
mup | PR snapd#5212 closed: xdgopenproxy: skip TestOpenUnreadableFile when run as root <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5212> | 15:14 |
Pharaoh_Atem | mvo: travis still can't do xenial :/ | 15:15 |
sil2100 | Seems to work here | 15:16 |
mvo | sil2100: ohhhhh, nice | 15:16 |
sil2100 | I mean, it still segfaults, but running on xenial | 15:16 |
sil2100 | (investigating further) | 15:16 |
mvo | sil2100: hm, sad that it still segfaults, I wonder if it works in a normal VM | 15:17 |
sil2100 | Let me test that | 15:20 |
sil2100 | Since there's nothing else obviously broken | 15:21 |
popey | Chipaca: is there any caching when doing "snap find"? | 15:58 |
popey | I have updated sections in the store and one isn't showing up for me | 15:58 |
popey | snap find --section=server | 15:59 |
popey | ^ that should work, but it doesn't | 15:59 |
=== mborzeck2 is now known as mborzecki | ||
noise][ | popey: two things at play - 1 hr cache on the store side (already refreshed) and i think snapd only refreshes the section list once per day | 16:10 |
=== pstolowski is now known as pstolowski|afk | ||
popey | noise][: thanks! | 16:12 |
sil2100 | mvo: I'm still looking into this, but interestingly it also segfaults on a xenial VM - from what I see it's segfaulting on executing the default override-stage scriptlet, which by default is handled by 'snapcraftctl stage' | 16:28 |
sil2100 | mvo: both for snapcraft as a snap and deb - but since I have a local reproducer I can finally dig into this properly | 16:29 |
mup | PR snapd#5213 opened: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/5213> | 16:41 |
mvo | sil2100: cool, I guess sergio will also want to know | 16:42 |
mvo | another simple review to unblock the snap (finally) 5213 | 16:42 |
mup | Bug #1773416 opened: Interface from Thunderbird/Firefox to LibreOffice/VLC <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1773416> | 16:59 |
kyrofa | Pharaoh_Atem, travis CAN do xenial, but it's pretty experimental right now | 17:14 |
kyrofa | sil2100, I can't quite determine what you're talking about from the scrollback, but snapcraft segfaulting on trusty is a known issue | 17:17 |
kyrofa | (for classic snaps anyway) | 17:17 |
kyrofa | (normal ones should be fine) | 17:17 |
kyrofa | But are you saying it's also segfaulting on xenial? | 17:18 |
Chipaca | popey: snap find doesn't cache, but sections are | 17:32 |
popey | Ok, good to know, thanks | 17:32 |
Chipaca | popey: but only for completion | 17:32 |
Chipaca | popey: if you type it, it should work | 17:33 |
popey | uh | 17:33 |
popey | nope | 17:33 |
Chipaca | hm | 17:33 |
Chipaca | hmm | 17:33 |
popey | https://www.irccloud.com/pastebin/omgnsTv3/ | 17:33 |
Chipaca | hm³ | 17:33 |
Chipaca | yes, seeing same | 17:33 |
Chipaca | hah | 17:34 |
Chipaca | popey: I'm a lying liar | 17:34 |
Chipaca | popey: of lies | 17:34 |
popey | Noted | 17:34 |
Chipaca | popey: also, this is arguably a bug | 17:34 |
Chipaca | let's argue about it :-) | 17:34 |
popey | Ok! | 17:34 |
popey | It is a bug. | 17:35 |
Chipaca | I agree. | 17:35 |
Chipaca | dammit | 17:35 |
Chipaca | how were arguments supposed to work | 17:35 |
popey | I really am top of my game today | 17:35 |
popey | Would you like me to file a bug somewhere (where?)? | 17:35 |
Chipaca | popey: nah, i'll fush a pix right now | 17:36 |
popey | \o/ <3 | 17:36 |
Chipaca | popey: as a workaround, sudo rm /var/cache/snapd/sections | 17:36 |
popey | \o/ success | 17:37 |
popey | Will everyone have to do that? (until the fix lands)? | 17:38 |
noise][ | Chipaca: presumably it updates regularly? daily? or is the bug that it is never updating? | 17:40 |
Chipaca | noise][: it updates regularly | 17:40 |
noise][ | cool | 17:41 |
Chipaca | noise][: the bug is just in the overzealous 'no such section' path | 17:41 |
Chipaca | I get it's trying to be helpful, but it could check the store if the cache doesn't have it | 17:41 |
Chipaca | that's what i'm implementing | 17:41 |
Chipaca | ok? | 17:41 |
Chipaca | check cache -> nope? check store | 17:42 |
Chipaca | and just in the --section=<foo> path | 17:42 |
Chipaca | hmm, OTOH the argument for it not being a bug is that sections are mostly static | 17:42 |
Chipaca | and we control them | 17:42 |
Chipaca | so we could just be patient :-D | 17:42 |
Chipaca | (it refreshes once a day, fwiw) | 17:43 |
popey | I want to do a social post to let everyone know about it | 17:43 |
Chipaca | popey: yes | 17:43 |
Chipaca | and I understand the motives for not having the section and not talking about it | 17:43 |
Chipaca | you want to add a section, and talk about it straight away, and have it work for early adopters and etc | 17:44 |
Chipaca | for teh buzz | 17:44 |
kyrofa | Hey Chipaca, I've got a PR up to make sure snapcraft doesn't toast the prime directory if a dev has used `snap try` on it. It works, but I'm parsing mountinfo just to see if the priming area is bind-mounted. It would be handier if snapd just exposed the mountpoint for tried snaps in the REST API. Thoughts? | 17:45 |
Chipaca | noise][: cprov: ok with you to hit the store if a user does 'snap find --section=xyzzy' and xyzzy is not in the cache? | 17:45 |
kyrofa | Er, not mountpoint, but root | 17:46 |
Chipaca | kyrofa: I agree! not sure how doable it is. Forum topic! | 17:46 |
kyrofa | Alright, I'll make one | 17:46 |
Chipaca | kyrofa: friday beer o'clock; cross-boundary problems are too deep | 17:46 |
Chipaca | kyrofa: (and that one might involve asking systemd stuff) | 17:47 |
Chipaca | or at least snapstate | 17:47 |
Chipaca | anyway, not fit for my head now | 17:47 |
* Chipaca wraps up the (un)cache one hoping to hear back from cprov and noise][ soonish | 17:47 | |
cprov | Chipaca: I don't have any objections, the store endpoint is cached for 1h. In theory, hitting the store for unknown section would give us some idea of which sections users are looking for. | 17:49 |
Chipaca | cprov: profit :-) | 17:50 |
cprov | Chipaca: exactly, thanks for working this out. | 17:50 |
Chipaca | cprov: hold on | 17:51 |
Chipaca | cprov: I'd not be hitting the store asking for one section | 17:51 |
Chipaca | cprov: I'd be hitting it asking for all sections | 17:51 |
Chipaca | there isn't an api for "is this a section" | 17:51 |
popey | Chipaca: ok, will put the social post on hold for now until I get the nod. | 17:52 |
Chipaca | popey: when was the section created? | 17:52 |
cprov | Chipaca: you are right, there is no way to hint the store on this | 17:52 |
popey | a few hours ago | 17:52 |
Chipaca | cprov: 24 hours from that, everybody will have it | 17:53 |
Chipaca | um | 17:53 |
Chipaca | popey: ^ | 17:53 |
Chipaca | cprov: a lot of people will have it before then though | 17:53 |
Chipaca | augh | 17:53 |
popey | ok so a social post on sunday to be safe | 17:53 |
Chipaca | popey: ^ | 17:53 |
popey | sound reasonable? | 17:53 |
popey | (we want to try some weekend social posts) | 17:53 |
Chipaca | popey: as this chance is going to master, and that's ~2 months from everybody getting it, next time something like this needs doing create the empty section first, and populate it for the news | 17:54 |
Chipaca | capisce? | 17:54 |
popey | Gotcha | 17:55 |
popey | So one thing I'm not clear on. Right now, today as we stand, if I tell people on Sunday to "snap find --section=server" will that work? | 17:55 |
Chipaca | popey: yes | 17:57 |
popey | Ok, great! Thanks. | 17:57 |
Chipaca | popey: snapd refreshes that on boot, and then every 24 hours | 17:58 |
mup | PR snapd#5214 opened: cmd/snap: check with snapd for unknown sections <Created by chipaca> <https://github.com/snapcore/snapd/pull/5214> | 18:04 |
Chipaca | popey: ^ | 18:04 |
popey | *hugs* | 18:04 |
cprov | thanks, Chipaca | 18:05 |
popey | cprov: i can't view sections in the web store can I? | 18:05 |
Chipaca | now i'm off to make fugazzetta | 18:05 |
Chipaca | o/ | 18:05 |
popey | o/ | 18:05 |
noise][ | popey - not yet, is on the webteam's short-term todo though | 18:06 |
popey | sweet | 18:06 |
popey | It's coming togther :D | 18:06 |
cprov | popey: no, but you can use `curl -s https://api.snapcraft.io/api/v1/snaps/sections | jq '._embedded["clickindex:sections"]'` | 18:16 |
sil2100 | kyrofa: yeah, segfaulting on xenial as well - I saw the issue you're talking about but I guess this might be different, as it's not during building a classic snap | 18:16 |
popey | seamless :) | 18:16 |
sil2100 | kyrofa: anyway, I'll be digging into that more later | 18:16 |
* sil2100 EODs for now | 18:16 | |
sil2100 | o/ | 18:16 |
jdstrand | roadmr: hi! one more small request. can you pull r1079? it is also not urgent. it can come after the first or after the first two, whatever you want | 19:05 |
niemeyer | zyga: You're hopefully not here anymore, but for monday, replied to that point | 19:06 |
zyga | Thanks | 19:07 |
zyga | I will check in some time | 19:07 |
zyga | Building stuff with bolts and nuts now | 19:07 |
pedronis | jdstrand: thanks for adding the common-id check | 19:13 |
roadmr | ohi jdstrand | 19:14 |
roadmr | jdstrand sure, r1079 will go to the queue, I'd like to roll out on Monday | 19:15 |
* mvo would love a review for 5213 pretty simple and hopefully unblocks the snapd snap building | 19:21 | |
pedronis | mvo: have some comments there, I don't understand the non-main changes | 20:05 |
erio | hello, has someone here snapped something with SDL2 ? | 22:33 |
erio | is anyone alive ? | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!