| mup | PR snapcraft#2225 closed: build providers: environment setup for projects <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2225> | 02:18 |
|---|---|---|
| mup | PR snapcraft#2247 closed: yaml loading: properly handle unhashable types <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2247> | 02:51 |
| Doctor_Nick | what is "black"? | 03:50 |
| Doctor_Nick | run_tests.sh requires it but I don't know what package it's located in | 03:51 |
| Doctor_Nick | ah hah, it's in the snap store, of course | 03:53 |
| Doctor_Nick | "The linker version '2.23' used by the base 'core' is incompatible with files in this snap:" | 03:56 |
| Doctor_Nick | that's an issue i haven't seen before | 03:56 |
| Doctor_Nick | any idea what this means? | 03:57 |
| Doctor_Nick | ah, I was using the release candidate snapcraft | 03:59 |
| Doctor_Nick | "warning: working around a Linux kernel bug by creating a hole of 2097152 bytes in ‘/tmp/tmpyf6y6pvu’" | 04:06 |
| Doctor_Nick | now THATS quality! | 04:07 |
| Doctor_Nick | uhm | 04:09 |
| Doctor_Nick | does the AppVeyor CI run the self test for snapcraft? | 04:10 |
| Doctor_Nick | is `./runtests.sh static` on snapcraft broken for anyone else? mypy throws a bunch of type errors | 04:40 |
| mup | PR snapcraft#2248 opened: plugin: update catkin plugin to support melodic <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2248> | 04:51 |
| Doctor_Nick | there we go | 04:51 |
| mborzecki | morning | 05:07 |
| mborzecki | hm got a failure in unit tests with gccgo: https://paste.ubuntu.com/p/prG9CTRNJm/ | 05:27 |
| mborzecki | it's in snapshotSuite.TestRestoreIntegration | 05:27 |
| zyga | Hey hey | 05:34 |
| mborzecki | zyga: hoho | 05:35 |
| mborzecki | zyga: how's the first week of school? | 05:36 |
| zyga | I think successful | 05:39 |
| zyga | Janek likes his new school | 05:39 |
| zyga | And committing is ok, he is doing it by himself now | 05:39 |
| mborzecki | that's great :) | 05:39 |
| zyga | And for you? | 05:43 |
| mborzecki | zyga: so far so good, kids have already gotten into the daily routine | 05:47 |
| zyga | ok, installed in my office now :) | 06:05 |
| mup | PR snapd#5776 closed: tests: port proxy test to use python tinyproxy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5776> | 06:31 |
| mup | PR snapd#5784 closed: tests: run account-control test with different bases <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5784> | 06:31 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:01 |
| zyga | hey pawel | 07:01 |
| zyga | reading your hot plug PRs now :) | 07:01 |
| zyga | I'll be right back, I could use another coffee | 07:01 |
| mborzecki | anyone upgraded to g 1.11 already? | 07:08 |
| zyga | mborzecki: not in tumbleweed | 07:11 |
| mvo | I did not yet, its in cosmic but not in bionic | 07:11 |
| zyga | anything new and interesting? | 07:12 |
| mborzecki | damn, gocode stopped working, stracing it i found it's poking some silly locations under pkg/linux-amd64 (note - not _) | 07:12 |
| === sparkieg` is now known as sparkiegeek | ||
| zyga | mborzecki: actually, I should just upgrade go on macOS | 07:37 |
| * zyga does just that | 07:37 | |
| zyga | we have spam on the forum | 07:38 |
| zyga | who has editorial rights to kill that? | 07:38 |
| diddledan | morning. | 07:38 |
| diddledan | not I. | 07:39 |
| diddledan | :-p | 07:39 |
| mborzecki | zyga: i know Chipaca, maybe mvo as well? | 07:41 |
| mvo | mborzecki: maybe - whats the link to the spam zyga ? | 07:43 |
| zyga | sent in private | 07:45 |
| mvo | zyga: thanks, removed post and user | 07:48 |
| mvo | pstolowski: just curious but did you find any leads on the test failure? | 07:58 |
| pstolowski | mvo: i only got succesful build in the ppa this morning a while ago, pushing some more debug. i had a long fight with debian toolchain yesterday ;} | 07:59 |
| pstolowski | (succesful = failing on unit tests as expected) | 08:00 |
| mup | PR snapd#5789 opened: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789> | 08:02 |
| mvo | pstolowski: aha, great, so you can reproduce it and get useful debug out of it? great. is it worth it for me to push a tiny branch that skips the test for now so that we get edge builds back or is the fix close enough to not bother? | 08:03 |
| mvo | pstolowski: (again, no pressure just trying to estimate what the best next step is) | 08:03 |
| mvo | Chipaca: good morning | 08:03 |
| pstolowski | mvo: no fix in sight, issue not yet understood, so yeah, feel free to disable the test if it's blocking | 08:04 |
| Chipaca | mvo: it is! good morning to you too sir | 08:04 |
| pstolowski | zyga: missied your earlier message, thanks for looking at my hotplug PRs! | 08:05 |
| zyga | the name code is intricate | 08:05 |
| mvo | pstolowski: thank you | 08:06 |
| mup | PR snapd#5790 opened: overlord: skip testUpdateWithAutoconnectRetry temporarily <Created by mvo5> <https://github.com/snapcore/snapd/pull/5790> | 08:10 |
| zyga | pstolowski: 5782 reviewed | 08:12 |
| pstolowski | zyga: ty! | 08:12 |
| Doctor_Nick | is there any documentation on "allow-auto-connection" for plugs? | 08:16 |
| Chipaca | Doctor_Nick: yep | 08:17 |
| Chipaca | Doctor_Nick: 1 sec | 08:17 |
| Chipaca | Doctor_Nick: https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455 | 08:17 |
| mvo | Chipaca: btw, does http://paste.ubuntu.com/p/yZjys58FKc/ ring any bells? | 08:18 |
| mvo | Chipaca: happend in a recent spread run, iirc in one of mborzecki PRs | 08:18 |
| Chipaca | nice :-/ | 08:18 |
| mborzecki | mvo: ha, pasted it in the morning :) but nobody was around | 08:19 |
| Doctor_Nick | Chipaca: thanks | 08:20 |
| Chipaca | mvo: mborzecki: it does not ring a bell | 08:20 |
| mborzecki | Chipaca: mvo: https://paste.ubuntu.com/p/prG9CTRNJm/ | 08:20 |
| Chipaca | mvo: mborzecki: but something is obviously wrong | 08:20 |
| Chipaca | mborzecki: what mahcine? | 08:20 |
| Chipaca | machine* | 08:20 |
| mborzecki | Chipaca: this was with gccgo, ubuntu something, sorry don't have more details | 08:21 |
| Doctor_Nick | Chipaca: wait, sorry, I meant the syntax for it | 08:21 |
| Chipaca | Doctor_Nick: what do you mean, the syntax? | 08:21 |
| pedronis | Doctor_Nick: do you have a brand store? | 08:21 |
| Doctor_Nick | the syntax for the snapcraft.yaml file | 08:21 |
| Doctor_Nick | not yet | 08:22 |
| pedronis | it doesn't go in snapcraft.yaml | 08:22 |
| Doctor_Nick | theese are private snaps so far | 08:22 |
| pedronis | it is put in the snap declaration assertion through the store | 08:22 |
| Chipaca | what goes in the yaml is the connection | 08:22 |
| Chipaca | not the auto-connection of the connection :-) | 08:22 |
| pedronis | on that front brand store owners have control, we are also working to make it so that knowning the syntax is not needed | 08:23 |
| pedronis | but is not something that can be done for one own's snaps in the main store | 08:24 |
| pedronis | private or not | 08:25 |
| dot-tobias | Is it possible to declare common environment variables for apps in snapcraft.yaml? https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276 only lists apps.<app-name>.environment, which I interpret as “currently not” | 08:30 |
| zyga | dot-tobias: I think so, just try it | 08:30 |
| zyga | I mean, snap.yaml certainly allows that | 08:30 |
| dot-tobias | zyga: When I add apps.environment to snapcraft.yaml, snapcraft complains with “Issues while validating snapcraft.yaml: The 'apps/environment' property does not match the required schema: 'command' is a required property” → “environment” is interpreted as an app name here? | 08:32 |
| zyga | dot-tobias: move environment to top-level | 08:32 |
| mborzecki | everyone seen this on reddit yday? https://www.reddit.com/r/linux/comments/9dfag7/the_correct_frontrunner_in_the | 08:32 |
| popey | Yes :) | 08:33 |
| mvo | seb128: iirc you added some info about metered and network manager into the forum. I misplaced the link, could you sent it to me again please? | 08:34 |
| seb128 | mvo, I didn't because I found https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 that has all the technical detail and I though there was not much point creating a new post | 08:35 |
| Chipaca | popey: seb128: I was meaning to update you both on this, but then seb128's train got in the way and then I forgot: yesterday at the standup we talked about enabling the feature by default, and we agreed to move forward on it -- with some level of testing to be done asap | 08:35 |
| Chipaca | I believe that's what mvo is on right now in fact :-) | 08:35 |
| Chipaca | but dunno :-D | 08:35 |
| seb128 | ah, great | 08:35 |
| seb128 | let us know if we can help in desktop | 08:35 |
| Chipaca | you can always help in desktop | 08:36 |
| popey | Chipaca: great, lemme know if I can test stuff | 08:36 |
| seb128 | (also would be good to have something to respond to review saying that flatpak cares about their users bandwith where we don't) | 08:36 |
| dot-tobias | zyga: Right, makes sense. And works. Thank you! 🙏 | 08:36 |
| Chipaca | seb128: where's that review? | 08:36 |
| seb128 | Chipaca, see the most recent post on that forum topic I just pasted | 08:37 |
| mvo | Chipaca: yeah, was just looking into this (cc seb128 ) | 08:37 |
| seb128 | mvo, you rock :) | 08:39 |
| Chipaca | seb128: "snapd supports disabling updates on metered connections; the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled" would work? | 08:39 |
| Chipaca | seb128: and a link to the forum post perhaps | 08:40 |
| Chipaca | seb128: is that wyat you meant as a response? | 08:40 |
| Chipaca | seb128: "snapd supports disabling updates on metered connections, on all supported distros that have a new enough netowkr manager (on Ubuntu that means 16.04 on); the support is not enabled by default should be soon unless field testing shows anything breaking with it enabled" | 08:41 |
| Chipaca | seb128: if you want to include more detail :-) | 08:41 |
| mup | PR snapd#5791 opened: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791> | 08:41 |
| Chipaca | seb128: typo and a missing "but" | 08:42 |
| pedronis | Chipaca: I created https://github.com/snapcore/snapd/pull/5791 to see how it goes, at least overlord tests doesn't seem to fail with it | 08:42 |
| mup | PR #5791: [WIP] overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791> | 08:42 |
| Chipaca | seb128: or, I can answer that myself if you'd rather keep clear of omg | 08:42 |
| seb128 | Chipaca, if you want to reply that would be nice, thanks :) | 08:43 |
| Chipaca | seb128: OTOH, nothing in the usually acrid comments seems to mention metered at all | 08:43 |
| Chipaca | oh wait there ar emore comments | 08:43 |
| Chipaca | pedronis: yep, will look in a mo | 08:43 |
| seb128 | right, I'm just concerned that's one of those topics where one day someone is going to be pissed off because snapd refreshed in background and created them a bill of 100€ on roaming and then it becomes a topic of the day for ranting against snapd and getting used to say that flatpak at least does things right blablabla | 08:44 |
| Chipaca | eh, i'll add a comment | 08:44 |
| mborzecki | what about a use case where there's a device which is always connected over [234]G? | 08:45 |
| Chipaca | mborzecki: then we'll refresh at the slowest pace we can | 08:47 |
| Chipaca | mborzecki: right? | 08:47 |
| Chipaca | mborzecki: dude you wrote this :-) | 08:47 |
| mborzecki | Chipaca: heh, doesn't mean i remember all the details :P | 08:47 |
| Chipaca | seb128: comment added, but I had the temerity to include a link so it's waiting for moderation | 08:47 |
| Chipaca | mborzecki: point :-) | 08:47 |
| mborzecki | Chipaca: i'll refresh after 60 days anyway | 08:48 |
| Chipaca | mborzecki: in the most dire real-world use case i know of the person could get onto wired once a month or so | 08:48 |
| mborzecki | quesion whether that's frequent enough | 08:48 |
| Chipaca | so I'm happy with it | 08:48 |
| Chipaca | mborzecki: that's what we decided was the longest tolerable refresh | 08:48 |
| mvo | seb128: if you create forum topic I can reference it in my commit changelog :) | 08:49 |
| mborzecki | Chipaca: right, so that's 100€ bill every 2 months :) | 08:50 |
| Chipaca | mborzecki: i'm trying to decide if you're trolling or not | 08:51 |
| mborzecki | haha | 08:51 |
| mvo | Chipaca: if you or someone else followup in the forum please let me know, wouldbe nice to include the latest discussion in the commit as a pointer to the right forum entry | 08:51 |
| mborzecki | reminds me of a time in my previous jobs where we'd screw up stuff in redboot and they actually had to take cars, and visit some of the power line poles or trees the base stations were mounted on :) | 08:52 |
| Chipaca | mvo: I replied to the omgubuntu thread, as i said | 08:52 |
| Chipaca | mvo: and pointed them to https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 | 08:52 |
| mvo | Chipaca: thanks, I missed that it was on omgubuntu | 08:53 |
| Doctor_Nick | a snap inside of a flatpak inside of a docker container inside of a lxc container | 08:55 |
| popey | Doctor_Nick: Don't forget appimage!!!! | 08:55 |
| Doctor_Nick | of course | 08:55 |
| zyga | Doctor_Nick: running on windows in a VM in a browser on a mac | 08:55 |
| pstolowski | we need a spread test for that | 08:58 |
| Chipaca | zyga: on an x86 emulator running on chrome on a phone | 08:58 |
| mborzecki | guys, let me know if you need more input about metered support than that's already in the forum | 08:58 |
| Chipaca | mborzecki: I think popey and seb128 need a clearcut this-is-how-you-test-it and this-is-what-to-test-that-we-are-not-sure-about | 08:58 |
| popey | plus one | 08:59 |
| Chipaca | mborzecki: especially useful if we enable it by default in edge (or beta or w/e) and then have a mini call for testing there | 08:59 |
| mborzecki | ack, i'll finish up with the store thing i'm on right now and will add some notes to the forum thread | 09:00 |
| mvo | Chipaca, mborzecki https://github.com/snapcore/snapd/compare/master...mvo5:refresh-metered-tweaks?expand=1 is the code change. but I am a bit lost about the process (sorry for that). should it get proposed now or shall we wait until we got testing results from users first? | 09:01 |
| seb128 | mvo, you mean for the "turn it on by default", isn't what that topic is about? I'm happy to create another one if you would prefer though | 09:02 |
| Chipaca | I think we do need a separate topic if we're going to have a call for testing -- pointing people to a thread with 18 unrelated comments is not good for a call to action | 09:03 |
| seb128 | k | 09:04 |
| Chipaca | mvo: same here. I guess if nobody knows a _concrete_ case where it fails, enabling it in preparation for a call for testing is good | 09:04 |
| Chipaca | mvo: especially as we tweaked the ux a bit | 09:04 |
| mborzecki | mvo: process questions aside, the code lgtm | 09:05 |
| * mvo nods | 09:06 | |
| mvo | thanks, I proposed it now, lets see how that goes :) | 09:06 |
| mup | PR snapd#5792 opened: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792> | 09:06 |
| Chipaca | pedronis: about the wip pr, +1 fwiw (but also: tests?) | 09:08 |
| Chipaca | pedronis: but i do get that the pr is just to see what breaks :-) | 09:08 |
| pedronis | Chipaca: yes, exactly | 09:08 |
| pedronis | if everything passes I'll see what needs testing | 09:09 |
| Chipaca | mborzecki: second time through gccgo in the three places we run it without repro'ing the bug | 09:09 |
| Chipaca | mborzecki: if you see it again, i need to know how | 09:09 |
| Chipaca | mborzecki: it makes no sense to me :-( | 09:09 |
| Chipaca | like two things were mkdir'ing $HOME/snaps/, or sth | 09:10 |
| Chipaca | s/three/four/ fwiw :-) | 09:10 |
| zyga | mborzecki: let's land 5793 | 09:12 |
| zyga | mborzecki: I'm preparing another iteration of the trespassing patch-set without the noise | 09:12 |
| mup | PR snapd#5793 opened: cmd/snap-update-ns: separate OpenPath from the Secure struct <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5793> | 09:13 |
| Doctor_Nick | what's the default shell in snaps? | 09:17 |
| zyga | Doctor_Nick: what do you mean specifically? | 09:17 |
| Doctor_Nick | my shell script in this snap package isn't working and I think it's because it's not using bash | 09:18 |
| ogra | Doctor_Nick, /bin/sh is dash normally ... | 09:18 |
| Doctor_Nick | ah hah | 09:18 |
| zyga | Doctor_Nick: just use bash explicitly | 09:18 |
| Doctor_Nick | yup | 09:18 |
| ogra | if you want to use bash then explicitly use /bin/bash in the shebang | 09:18 |
| Doctor_Nick | yeah | 09:19 |
| ogra | (but live with the overhead :P ) | 09:19 |
| ogra | (typically there is no reason to not adapt your code to be POSIX compliant ...) | 09:19 |
| ogra | https://wiki.ubuntu.com/DashAsBinSh has hints | 09:20 |
| Doctor_Nick | yeah, it was an easy fix to use the alternative setup script | 09:21 |
| pedronis | mmh, almost back to 50 PRs | 09:28 |
| niemeyer | More than 20 of those are still from the review board | 09:39 |
| niemeyer | 19 have open reviews | 09:39 |
| niemeyer | (moin!) | 09:40 |
| niemeyer | dot-tobias: To be clear, there's no default | 09:41 |
| niemeyer | It's whatever was used in the bangline, as usual | 09:41 |
| dot-tobias | niemeyer: I think you meant to ping Doctor_Nick ? ;-) | 09:42 |
| niemeyer | dot-tobias: Sorry :) | 09:42 |
| dot-tobias | niemeyer: no problemo :-) (&& moin) | 09:43 |
| mvo | 5606 needs a second review then it can go in | 09:45 |
| mvo | and 5763 a first review, hopefully simple as its just shuffling tests around | 09:46 |
| zyga | mvo: doing | 09:50 |
| Chipaca | niemeyer: snap run --shell runs bash, that's the most defaultish thing we have :-) | 09:50 |
| Chipaca | imo we could add --shell=<what> | 09:50 |
| niemeyer | Chipaca: That seems a bit cumbersome, even more because the _what_ may not be available inside the snap | 09:51 |
| Chipaca | niemeyer: I mean, keep --shell, but add the ability for the user to say what shell they want | 09:51 |
| Chipaca | go-flags supports this fwiw | 09:51 |
| niemeyer | Chipaca: The issue asked was about a shell script as well, so wouldn't help here either way | 09:52 |
| Chipaca | i know | 09:52 |
| niemeyer | Chipaca: Right, I got that | 09:52 |
| niemeyer | Chipaca: It won't help if they want zsh, though, or csh, or ... | 09:52 |
| niemeyer | Chipaca: The snap does not offer it | 09:52 |
| Chipaca | niemeyer: if you're using a base that offers /bin/sh but not /bin/bash, it won't work for ex | 09:52 |
| niemeyer | Chipaca: We should just fallback to /bin/sh in those case | 09:53 |
| niemeyer | s | 09:53 |
| Chipaca | niemeyer: or, e.g., snap install busybox-static, and try to snap run --shell busybox-static | 09:53 |
| Chipaca | niemeyer: in this one, /bin/sh is provided by the snap itself (it uses the bare base, which has nothing) | 09:54 |
| Chipaca | still, this is all academic | 09:54 |
| Chipaca | i need to go | 09:54 |
| * Chipaca goes | 09:54 | |
| niemeyer | Chipaca: o/ | 09:56 |
| Doctor_Nick | yessss | 10:03 |
| Doctor_Nick | our entire backend is snapped now | 10:03 |
| ogra | yay, congrats ! | 10:04 |
| ogra | (whatever backend that is :) ) | 10:04 |
| Doctor_Nick | now I just have to charm it | 10:04 |
| ogra | do a feather dance :) | 10:05 |
| ogra | https://www.youtube.com/watch?v=dxk1BSQo8bg&feature=youtu.be&t=20 | 10:06 |
| Doctor_Nick | oh lord | 10:08 |
| ogra | heh | 10:08 |
| zyga | mvo: done | 10:10 |
| mvo | zyga: ta | 10:11 |
| niemeyer | mvo: Do we have a snapd.failure.service file? | 10:12 |
| mvo | niemeyer: we do | 10:14 |
| niemeyer | mvo: Huh.. that's a curious service :) | 10:14 |
| mvo | niemeyer: yes | 10:14 |
| mvo | niemeyer: when adding a "OnFailure=" bit in systemd this needs to be a service AFAIK | 10:14 |
| mvo | niemeyer: this is why we have this one. do you think the name is not good or do you think the fact that we have it at all is problematic? | 10:15 |
| niemeyer | mvo: I think it's fine given the context.. I just wasn't aware that we had it | 10:15 |
| * mvo nods | 10:16 | |
| niemeyer | mvo: Do we run snap-repair on desktops or only on core? | 10:16 |
| mvo | niemeyer: only on core | 10:16 |
| niemeyer | mvo: Wonder why people are getting the message that those units are disabled | 10:17 |
| niemeyer | It doesn't look like a bug.. | 10:17 |
| niemeyer | But people seem to think so | 10:17 |
| niemeyer | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1776622 | 10:17 |
| mup | Bug #1776622: snapd on cosmic never finishes installing/updating. Can't install any other updates. <amd64> <apport-bug> <cosmic> <regression> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776622> | 10:17 |
| mvo | niemeyer: yeah, I quickly scanned our postinst and its just using the systemd debhelper stuff, would be nice to get the output of "ps afx" when this hangs | 10:19 |
| mvo | niemeyer: just to see what processes are hanging around and blocking dpkg | 10:19 |
| niemeyer | mvo: One person there mentioned the context | 10:19 |
| zyga | mvo: the 2nd PR is pretty long :) | 10:19 |
| zyga | pushing on | 10:19 |
| niemeyer | moon127: Comment #15 | 10:19 |
| mup | PR #15: do not panic if a priv.Mutex is taken/released/taken again <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/15> | 10:19 |
| niemeyer | mup: Good try | 10:19 |
| mup | niemeyer: I really wish I understood what you're trying to do. | 10:19 |
| niemeyer | mup: It's okay.. you're often helpful | 10:20 |
| mup | niemeyer: Unknown commands are unknown. | 10:20 |
| pedronis | niemeyer: hi, #5683 needs a re-review by you | 10:22 |
| mup | PR #5683: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683> | 10:22 |
| zyga | thx | 10:30 |
| zyga | mvo: almost done | 10:31 |
| zyga | mvo: reading the new parts now | 10:31 |
| zyga | mvo: done | 10:32 |
| zyga | brb, coffee | 10:32 |
| pstolowski | mvo: i've a suspiction about the cause of managers test failures, might have a fix, testing | 10:35 |
| niemeyer | pedronis: Thanks, looking | 10:38 |
| mborzecki | pedronis: thanks for all the reviews | 10:41 |
| mborzecki | pedronis: i'll be landing https://github.com/snapcore/snapd/pull/5761 when it's green | 10:42 |
| mup | PR #5761: store: use stable instance key in store refresh requests <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5761> | 10:42 |
| mborzecki | (or pushing one last update if #5763 lands first) | 10:42 |
| mup | PR #5763: store: refactor tests so that they work as store_test package <Created by mvo5> <https://github.com/snapcore/snapd/pull/5763> | 10:42 |
| Doctor_Nick | is there an easy way to set network restrictions on snaps, like "only accept connections from localhost"? | 10:43 |
| mborzecki | Chipaca: https://api.travis-ci.org/v3/job/425643055/log.txt | 10:46 |
| niemeyer | pstolowski: #5683 is good to go | 10:47 |
| mup | PR #5683: overlord/patch: support for sublevel patches <Created by stolowski> <https://github.com/snapcore/snapd/pull/5683> | 10:47 |
| mborzecki | Chipaca: this one too https://api.travis-ci.org/v3/job/425601674/log.txt it's gccgo always | 10:47 |
| pedronis | Chipaca: I reviewed the warning one, some small comments/wonderings | 10:48 |
| pstolowski | niemeyer: great, ty! re-starting travis tests | 10:49 |
| mvo | niemeyer: I contemplated your suggestions about having the managers giving input into the "go-socket-activated" mode. I did a sketch of this now in https://github.com/snapcore/snapd/compare/master...mvo5:stop-on-no-snaps-standby-helper?expand=1 - all names are strawman for now, sugestions welcome. the idea is to have a "standbyHelper" that asks around for opinions if snapd can go to sleep. it gets input from snapmanager ab | 10:50 |
| mvo | out num snaps, devicestate about seeded, overlord about if ensure was run at least once and the daemon about the connections (check daemon.go and standby.go for the interessting bits). is this what you had in mind? | 10:50 |
| mvo | (tests missing but I will re-add them if this looks promising) | 10:50 |
| mvo | zyga: thank you! | 10:50 |
| zyga | re | 10:51 |
| zyga | Doctor_Nick: no, there's no support for that at this time | 10:52 |
| niemeyer | mvo: Yeah, something around those lines indeed, thanks for making it real. I'll read through the code after lunch and we can quickly sync in the standup. | 10:52 |
| Doctor_Nick | dag | 10:52 |
| mup | PR snapd#5606 closed: many: add refresh.rate-limit core option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5606> | 10:52 |
| Doctor_Nick | how about setting a user for a snap daemon? | 10:53 |
| zyga | Doctor_Nick: this is on the roadmap but it is not implemented yet | 10:53 |
| Doctor_Nick | ok | 10:53 |
| zyga | it's designed and described extensively on the forum | 10:53 |
| juliank | Oh, can I build against core18 now? | 10:53 |
| pedronis | mvo: are you going to finalize #5324 soon? or should it be closed for now | 10:53 |
| mup | PR #5324: snap: run snap-confine from the re-exec location <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5324> | 10:53 |
| zyga | juliank: indeed you can | 10:53 |
| juliank | I'd like to get apt snaps going | 10:54 |
| juliank | :) | 10:54 |
| mvo | pedronis: 5324? | 10:54 |
| mvo | juliank: yes you can :) | 10:54 |
| pedronis | mvo: sorry, #5234 | 10:54 |
| juliank | I have two things I want to snap: apt and flatpak. The latter mostly for lolz | 10:54 |
| mup | PR #5234: snap: add `snap list --format=...` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5234> | 10:54 |
| pedronis | even older ;) | 10:54 |
| Doctor_Nick | zyga: is there a way to set a user as part of the snap group and just restrict what they're able to connect? | 10:55 |
| zyga | Doctor_Nick: what do you mean by "snap group"? | 10:55 |
| zyga | Doctor_Nick: and how is that related to connections? sorry, I don't understand your question | 10:55 |
| mvo | pedronis: :( yeah, its a mess of conflicts, I had not mustered the energy yet but I will make a extra strong cup of tea after lunch and give it a go again | 10:55 |
| Doctor_Nick | wait, sorry | 10:55 |
| Doctor_Nick | i had imagined that there was a snap group that gave users permissions to install snaps | 10:56 |
| zyga | no, that's managed with policy kit | 10:56 |
| zyga | and with root vs non-root | 10:56 |
| Doctor_Nick | right | 10:56 |
| Doctor_Nick | basically I just want to run these things as non-privileged users and only give them access to the network interface | 10:57 |
| mborzecki | heh, i'm trying to chec this refresh on metered thing, but i can't get nm to connecto to my phone :/ | 11:02 |
| mvo | zyga: thanks, the store test PR just had lots of conflicts because the rate limit was landed - oh well :) | 11:05 |
| mvo | zyga: but now I just need to wait for tests, thanks a lot ofr the review | 11:06 |
| zyga | mvo: doing more | 11:06 |
| mup | Bug #1755568 changed: Snaps are refreshed on metered connection <Snappy:Fix Released> <https://launchpad.net/bugs/1755568> | 11:06 |
| Wimpress | Trevinho: Are you still a collaborator on the telegram-desktop snap? | 11:07 |
| Wimpress | If so, can you change the homepage to reference telegram desktop and not your personal website please? | 11:07 |
| Wimpress | https://snapcraft.io/telegram-desktop | 11:07 |
| mvo | zyga: cool | 11:07 |
| zyga | does this ring a bell? | 11:11 |
| zyga | FAIL: snapstate_test.go:10904: snapmgrTestSuite.TestInstallDefaultProviderRunThrough | 11:11 |
| zyga | c.Check(len(s.fakeBackend.ops), Equals, len(expected)) | 11:12 |
| zyga | ... obtained int = 27 | 11:12 |
| zyga | ... expected int = 28 | 11:12 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/5771#issuecomment-419408625 | 11:17 |
| mup | PR #5771: selftest: add test to ensure selftest.checks is up-to-date <Created by mvo5> <https://github.com/snapcore/snapd/pull/5771> | 11:17 |
| mvo | zyga: ta | 11:23 |
| zyga | Chipaca: hey, wanna see a snapshot unit test error? | 11:24 |
| mvo | zyga: aha, yes. silly me. the problem is of course that on 14.04 the kernel selftest fails | 11:24 |
| mvo | zyga: so this test cannot yet be enabled | 11:24 |
| zyga | mvo: hmmm, | 11:24 |
| zyga | mvo: but the test will not fail on 14.04 after a reboot | 11:24 |
| pstolowski | mvo: ok, i think i've a fix, PR coming | 11:26 |
| mvo | zyga: correct | 11:26 |
| zyga | chipaca: https://www.irccloud.com/pastebin/CTSwvmVM/ | 11:26 |
| mvo | zyga: its also a bit of a usability issue having the package fail to install is ugly | 11:27 |
| mvo | zyga: I would love to enable this check once we have something like the degraded or read-only mode | 11:28 |
| zyga | mvo: yeah, I agree | 11:28 |
| zyga | I didn't think about the install failure aspect | 11:28 |
| mvo | zyga: thanks for the review in any case, I will address the bits you mentioned | 11:28 |
| zyga | is master broken now or was that just temporary in some tests? | 11:29 |
| mvo | zyga: not sure, last master run on travis was ok | 11:30 |
| mvo | zyga: looking | 11:30 |
| zyga | no, you're busy | 11:31 |
| zyga | I"ll check | 11:31 |
| mvo | zyga: it looks like the snapstate test is failing | 11:31 |
| mvo | http://paste.ubuntu.com/p/yZjys58FKc/ | 11:31 |
| zyga | mvo: I saw that in PR reviews, running locally | 11:33 |
| zyga | hmm, I don't see that failure | 11:34 |
| zyga | but I see this: | 11:34 |
| zyga | https://www.irccloud.com/pastebin/GcPNCB8T/ | 11:34 |
| mvo | zyga: I saw this one on the running master in travis | 11:34 |
| mvo | zyga: hu, this error is strange. in what PR do you see this? | 11:34 |
| zyga | on master on my machine | 11:35 |
| mvo | zyga: interessting. unfortunately I need lunch now, lets talk after that | 11:36 |
| zyga | that's so strange | 11:36 |
| zyga | I'm looking | 11:36 |
| Chipaca | zyga: what machine was that (snapshotstate) error on? | 11:38 |
| zyga | on travis | 11:38 |
| mup | PR snapd#5794 opened: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <https://github.com/snapcore/snapd/pull/5794> | 11:38 |
| Chipaca | zyga: travis doesn't run the unit tests, spread does | 11:39 |
| zyga | ah, I see your point | 11:39 |
| zyga | one sec | 11:39 |
| Chipaca | zyga: note the error is from mkdirallchown | 11:39 |
| Chipaca | zyga: so something fucky indeed | 11:39 |
| Chipaca | would be good to know what | 11:39 |
| zyga | there's a function like that? | 11:39 |
| zyga | we have mkdirall | 11:39 |
| Chipaca | zyga: osutil/mkdirallchown.go | 11:40 |
| zyga | we have dupes /o\ | 11:40 |
| pstolowski | mvo: https://github.com/snapcore/snapd/pull/5794 | 11:40 |
| mup | PR #5794: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <https://github.com/snapcore/snapd/pull/5794> | 11:40 |
| pstolowski | also pedronis ^ | 11:40 |
| Chipaca | zyga: mbuahah | 11:40 |
| * Chipaca goes away for a bit, again | 11:40 | |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | https://api.travis-ci.org/v3/job/425643055/log.txt | 11:42 |
| zyga | - google:ubuntu-18.04-64:tests/unit/gccgo | 11:42 |
| mborzecki | seb128: Chipaca: mvo: added testing steps, along wit some screenshots https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/19 | 11:44 |
| mborzecki | off to pick up the kids | 11:44 |
| popey | thanks mborzecki | 11:45 |
| thresh | so how stable is core18? | 11:47 |
| zyga | thresh: is should be stable | 11:48 |
| thresh | thanks zyga, going to try it out | 11:50 |
| Chipaca | mborzecki: popey: is «nmcli c show ... |grep connection.metered» easier than «nmcli --fields connection.metered c show ...»? | 11:50 |
| popey | The gimp snap uses it, and it's got a fair number of users thresh | 11:50 |
| thresh | me included! | 11:51 |
| popey | Chipaca: that doesn't work here | 11:52 |
| popey | Error: invalid field 'connection.metered'; allowed fields: NAME,UUID,TYPE,TIMESTAMP,TIMESTAMP-REAL,AUTOCONNECT,AUTOCONNECT-PRIORITY,READONLY,DBUS-PATH,ACTIVE,DEVICE,STATE,ACTIVE-PATH,SLAVE. | 11:52 |
| Chipaca | popey: wat | 11:52 |
| pedronis | Chipaca: we got the answer about that validate | 11:53 |
| Chipaca | pedronis: i'll look in a bit | 11:53 |
| Chipaca | pedronis: fixable? | 11:53 |
| pedronis | need to think a bit | 11:53 |
| pedronis | the current behavior is not great either for some cases | 11:54 |
| Chipaca | ok | 11:54 |
| pedronis | Chipaca: I think what we might want is to not do the check if the install is really with --dangerous, but not in general if it's a file install | 11:57 |
| pedronis | or some variation thereof | 11:57 |
| thresh | what steps do I need to take to build against core18? specify base: core18; adjust stage-packages, anything else? | 12:00 |
| zyga | thresh: that's about it | 12:00 |
| zyga | base is the requirement, anything else is adjusting to the new environment | 12:01 |
| thresh | got the following error after the (seemingly successful_ build: https://gist.github.com/thresheek/1c514b1b5d7981a97684f4bf4d3ee083 | 12:01 |
| thresh | cant run mksquashfs? :o | 12:04 |
| popey | sergiusens: ^ | 12:12 |
| sergiusens | thresh: docker and snapcore/snapcraft:latest? mind switching to snapcore/snapcraft:stable or maybe this interests you https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-43-1/7236 | 12:13 |
| thresh | sergiusens, docker indeed, but with a ubuntu:bionic image and snapcraft from the bionic repo. going to try the latest snapcraft. | 12:16 |
| sergiusens | thresh: the snapcraft in bionic proposed should fix that | 12:17 |
| thresh | adding that atm | 12:17 |
| zyga | no idea why it fails (my build id test) | 12:17 |
| zyga | hmmm | 12:27 |
| zyga | file is broken on my machine | 12:27 |
| mborzecki | re | 12:29 |
| zyga | strace file / https://www.irccloud.com/pastebin/lNRN08cB/ | 12:30 |
| zyga | that ... is weird! | 12:30 |
| mborzecki | if i hone my gimp skills a bit maybe i could highlight that checkbox with a circle :) | 12:30 |
| zyga | mborzecki: ? :) | 12:31 |
| mborzecki | zyga: https://i.imgur.com/TDA3TwF.png | 12:31 |
| zyga | mborzecki: just use a phone ;) | 12:32 |
| zyga | mborzecki: can you run strace file / | 12:33 |
| zyga | mborzecki: and paste the result please | 12:33 |
| mup | PR snapd#5763 closed: store: refactor tests so that they work as store_test package <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5763> | 12:33 |
| mborzecki | zyga: https://paste.fedoraproject.org/paste/jXaCOyxgcx~n56ZRGxODpQ/raw | 12:34 |
| zyga | thanks | 12:34 |
| zyga | hmmm | 12:34 |
| zyga | holly crap | 12:37 |
| zyga | so I had MAGIC set | 12:37 |
| zyga | because I was doing experiments with mvo on the systemd bug | 12:37 |
| zyga | and this apparently upsets file | 12:37 |
| zyga | because MAGIC is where you can store the database of magic numbers | 12:37 |
| zyga | man | 12:37 |
| zyga | any | 12:37 |
| zyga | variable | 12:37 |
| * zyga undoes systemd hacks | 12:37 | |
| mvo | pstolowski|lunch: thank you | 12:44 |
| mvo | mborzecki: thanks for adding the testing steps/screenshots | 12:44 |
| mvo | zyga: heh | 12:45 |
| mvo | zyga: fun (or not) | 12:45 |
| zyga | mvo: fun, just man :) | 12:45 |
| thresh | sergiusens, upgrading to 2.43.1 fixed it - thanks! | 12:45 |
| mup | PR snapd#5795 opened: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795> | 12:51 |
| Chipaca | zyga: where is the other mkdirallchown? | 12:54 |
| zyga | Chipaca: cmd/snap-update-ns/MkDirall | 12:54 |
| zyga | unless they differ in what they do | 12:54 |
| Chipaca | zyga: does that count as duplicated? I thought we had a bunch of stuff in snap-update-ns which was there for Reasons | 12:55 |
| Chipaca | with deduping happening if and when | 12:55 |
| zyga | I think Reasons no longer apply actually, we move things to osutil and we call it from cnf | 12:55 |
| zyga | but even if | 12:55 |
| zyga | are they the same code? | 12:55 |
| zyga | mborzecki: anther easy one | 12:56 |
| zyga | https://github.com/snapcore/snapd/pull/5795 | 12:56 |
| mup | PR #5795: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795> | 12:56 |
| mborzecki | overlord/snapstate/snapstate_test.go:457: C.Fatalf format %q has arg tasks of wrong type []*github.com/snapcore/snapd/overlord/state.Task | 12:57 |
| mborzecki | this is new | 12:57 |
| zyga | hmm | 12:58 |
| zyga | and %q cannot do that? | 12:58 |
| zyga | that's new indeed | 12:58 |
| zyga | 1.11/ | 12:58 |
| zyga | ? | 12:58 |
| mborzecki | zyga: yes | 12:59 |
| mborzecki | hm Task does not appear to be Stringer | 13:00 |
| zyga | nea | 13:02 |
| zyga | neat | 13:02 |
| zyga | so it's really broken | 13:02 |
| Chipaca | zyga: mborzecki: standup? | 13:02 |
| pedronis | bit strange | 13:02 |
| zyga | joining | 13:02 |
| mborzecki | Chipaca: i'm there :) | 13:02 |
| Chipaca | mborzecki: i'm ignoring you | 13:02 |
| mborzecki | haha :P | 13:02 |
| === pstolowski|lunch is now known as pstolowski | ||
| mup | PR snapd#5783 closed: tests: add new core16-base test <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5783> | 13:13 |
| mborzecki | Chipaca: https://api.travis-ci.org/v3/job/425651400/log.txt | 13:16 |
| Chipaca | mborzecki: again? | 13:16 |
| Chipaca | mborzecki: oh, interesting | 13:16 |
| mborzecki | Chipaca: i'm trying to reproduce it with spread on 18.04 now :/ | 13:17 |
| mup | PR snapd#5746 closed: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746> | 13:20 |
| mup | PR snapd#5790 closed: overlord: skip testUpdateWithAutoconnectRetry temporarily <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5790> | 13:34 |
| zyga | a simple loop of mount/unmount done via systemd doesn't trigger it | 13:36 |
| mborzecki | zyga: try snap install ... && snap remove ... like we did earlier | 13:37 |
| zyga | bug.sh https://www.irccloud.com/pastebin/pdHILpBk/ | 13:37 |
| zyga | mborzecki: can you copy two snaps as "foo.snap" and "bar.snap" and run that ^ | 13:37 |
| zyga | yeah, trying now | 13:37 |
| cachio | mvo, hey, did you see what I wrote? | 13:39 |
| cachio | I got disonnected | 13:39 |
| mvo | cachio: I did not | 13:41 |
| cachio | mvo, any idea what to do with this? https://paste.ubuntu.com/p/jsnPzWZqhW/ it is failing on bionic | 13:41 |
| mvo | cachio: yeah, it looks like "aws-cli" is not available in the catalog update | 13:42 |
| mvo | cachio: does "journalctl -u snapd" show anything that the "catalog" could not be downloaded or something like this? | 13:43 |
| mvo | cachio: or aws-cli is no longer available (which would be odd) | 13:43 |
| mborzecki | zyga: maybe it involves udev too | 13:43 |
| pstolowski | hmm, just got FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough | 13:45 |
| zyga | mborzecki: mmm, interesting! | 13:45 |
| cachio | mvo, the logs show that the catalog was refreshed | 13:46 |
| cachio | and aws-cli snap can be installed | 13:46 |
| cachio | but it is a classic snap | 13:46 |
| pstolowski | zyga: is "FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough" an error you were looking at earlier today? | 13:47 |
| mborzecki | zyga: exact line i used back then is `while true; do sudo snap install hello-world_foo hello-world_bar hello-world_baz && sudo snap remove hello-world_foo hello-world_bar hello-world_baz || break; done` | 13:47 |
| mborzecki | oh, and it worked until i rebooted the machine :) | 13:47 |
| zyga | thanks | 13:47 |
| zyga | hmm ? are you saying it is not working anymore (not reproducing the problem) | 13:47 |
| mborzecki | zyga: btw. i was also stracing systemd at that time, but it didn't happen when under strace | 13:48 |
| zyga | bummer | 13:49 |
| mborzecki | so besides generating a reasonable amount of logs nothing interesting happenend | 13:49 |
| mborzecki | zyga: maybe lttng could be useful, but haven't tried that yet | 13:50 |
| zyga | I haven't used it either | 13:51 |
| zyga | I think we need a solid reproducer | 13:51 |
| mborzecki | zyga: so that while loop is all that i have :) | 13:56 |
| Chipaca | mborzecki: I'm getting a bunch of Undone instead of Error failures (which I need to address), but haven't yet hit the other one | 13:56 |
| Chipaca | when i say 'a bunch', i mean in 100 runs of the suite i'll get one | 13:56 |
| zyga | error on undo https://www.irccloud.com/pastebin/Xbwy557Y/ | 13:56 |
| mborzecki | Chipaca: in the prereq in flight or sth test? | 13:56 |
| zyga | https://www.irccloud.com/pastebin/HQ9Rid1C/ | 13:56 |
| Chipaca | mborzecki: TestRestoreIntegrationFails | 13:57 |
| Chipaca | it makes sense as it's racy | 13:57 |
| mborzecki | Chipaca: ok, that's different then | 13:57 |
| zyga | Chipaca, pstolowski: ^ | 13:58 |
| Chipaca | zyga: ? | 13:58 |
| Chipaca | zyga: that doesn't seem to have anything to do with snapshotstate | 13:59 |
| zyga | Chipaca: ctrl-c on install/remove | 13:59 |
| Chipaca | zyga: where's the error? | 13:59 |
| zyga | error: change finished in status "Undone" with no error message | 14:00 |
| Chipaca | zyga: ah, ok | 14:00 |
| Chipaca | zyga: that's a bug in cmd/snap/wait.go, probably? | 14:00 |
| Chipaca | zyga: what does http snapd:///v2/changes/333 show you? | 14:01 |
| zyga | https://www.irccloud.com/pastebin/nx4BNVIb/ | 14:01 |
| Chipaca | zyga: er, i meant 380 | 14:02 |
| Chipaca | not sure where i got 333 from :-) | 14:02 |
| zyga | 380 https://www.irccloud.com/pastebin/91IpOAUy/ | 14:03 |
| Chipaca | zyga: so, either snapd should add something to the change, or snap should not expect it to be there :-) | 14:04 |
| pstolowski | zyga: sorry, what's the context; are there multiple issues being disccussed? | 14:04 |
| Chipaca | pstolowski: yes | 14:05 |
| Chipaca | pstolowski: 3 at least | 14:05 |
| Chipaca | pstolowski: was very confusing at first | 14:05 |
| Saviq | hey, I got `snap install` hanging for 12m now on copying 512bytes of data... https://pastebin.ubuntu.com/p/WBHPhJHcpT/ anything more of interest I could collect? | 14:09 |
| * cachio afk | 14:12 | |
| mborzecki | Chipaca: reproduced snapshotSuite.TestRestoreIntegration with spread | 14:13 |
| mborzecki | Chipaca: running the test in isolation fails too https://paste.ubuntu.com/p/cNt2qt4NWb/ though differntly | 14:14 |
| Chipaca | gawsh | 14:19 |
| Chipaca | mborzecki: thanks | 14:20 |
| Chipaca | mborzecki: is this every time? | 14:20 |
| mborzecki | Chipaca: yes | 14:20 |
| pstolowski | Saviq: this copying involves more directories afair, not just those you listed | 14:20 |
| Chipaca | mborzecki: how | 14:20 |
| mborzecki | Chipaca: no clue yet, looking into it | 14:20 |
| Chipaca | mborzecki: the runuser thing points to an every time thing, but how did they pass for me if so? | 14:21 |
| Chipaca | how do they continue to pass here | 14:21 |
| Chipaca | mborzecki: I've just got a repro of the mkdirallchown error (the one with the long changeerror that mentions snap.mkdir-new) | 14:21 |
| Chipaca | ah | 14:22 |
| mborzecki | Chipaca: idk, it passes locally on my host, but not in gce, i have debug shell open atm | 14:22 |
| Chipaca | mborzecki: you're running them as root in gce | 14:22 |
| mborzecki | Chipaca: heh, yes, i should use test user? | 14:22 |
| Chipaca | mborzecki: well.. they shouldn't fail, but they are :-) | 14:22 |
| zyga | mborzecki: updated 5795 | 14:22 |
| Chipaca | mborzecki: runuser isn't used unless you're root | 14:23 |
| Chipaca | at some point apparently it broke | 14:23 |
| Chipaca | need to look | 14:23 |
| Chipaca | probably got the args mangled somehow | 14:23 |
| mborzecki | Chipaca: looks like it's passing tar argumens directly to runuser | 14:23 |
| Saviq | pstolowski: it completed after 25mins... I doubt I have enough free space to take that long (and there was not much IO going on) | 14:24 |
| Saviq | ~/snap/subsurface is 55MB | 14:24 |
| mborzecki | Chipaca: if username == "root" || sys.Geteuid() != 0 { | 14:24 |
| mborzecki | sys.Geteuid() == 0 ? | 14:25 |
| pstolowski | Saviq: I see.. anything in /root/snap/subsurface? | 14:26 |
| Saviq | sergiusens: how do I check locally if https://forum.snapcraft.io/t/builds-failing-automated-review/7112 is fixed with the latest snapcraft? where do I find manifest.yaml? | 14:26 |
| Chipaca | mborzecki: if you're not root, or you are root but are running things for root, don't runuser | 14:26 |
| Saviq | pstolowski: no, never launched there | 14:26 |
| Chipaca | mborzecki: runuser ["-u" "a-user" "tar" "--create" "--sparse" "--gzip" "--directory" "/tmp/check-1422139595125391214/46/home/a-user/snap/too-snap/" "2" "common"] | 14:26 |
| sergiusens | Saviq: that was fixed store side | 14:26 |
| Chipaca | mborzecki: that's what's exec'ed | 14:26 |
| Saviq | sergiusens: was it? the forum post only mentions downgrading snapcraft on the builders? | 14:27 |
| sergiusens | Saviq: install review-tools and run them on the resulting snap when SNAPCRAFT_BUILD_INFO is set | 14:27 |
| sergiusens | Saviq: hmm, jdstrand_ since you did the downgrade, mind updating the forum post on everything being up to speed now? | 14:27 |
| mborzecki | Chipaca: what i mean is https://paste.ubuntu.com/p/fhFFMj29Sm/ | 14:28 |
| pstolowski | Saviq: anything in journal? grep for "data directory" | 14:28 |
| Chipaca | mborzecki: no | 14:28 |
| Chipaca | mborzecki: that logic is correct | 14:28 |
| mborzecki | Chipaca: ok, so the comment above is incorrect | 14:29 |
| Chipaca | mborzecki: "username" is the username of the user for who we're creating a snapshot | 14:29 |
| * Saviq should do something with journald rotations... I've logs from February... | 14:29 | |
| Chipaca | mborzecki: the comment is saying the same thing i'm telling you :-) | 14:29 |
| * Chipaca steps away from despair, breathes in, and tries to explain | 14:29 | |
| pstolowski | Saviq: that explains your earlier remark about not having enough space ;) | 14:30 |
| Chipaca | mborzecki: we want to run with runuser if: 1. the code is running as uid 0, *and*, 2. the user we're going to switch to is not root | 14:30 |
| Chipaca | mborzecki: 2. is only because, if you're root, and you use runuser to run something as root, .... what did you even | 14:31 |
| Chipaca | mborzecki: I think the bug is that it's missing the --, which the manpage says is optional but probably isn't that optional | 14:31 |
| mborzecki | Chipaca: ok, let me try that | 14:32 |
| Chipaca | mborzecki: yep, that fixed it | 14:32 |
| Chipaca | mborzecki: (different error now, but one that makes sense :-) ) | 14:32 |
| Chipaca | mborzecki: https://pastebin.ubuntu.com/p/4VXBbck4YF/ | 14:33 |
| Chipaca | er, without the printf :-) | 14:33 |
| mup | PR snapd#5793 closed: cmd/snap-update-ns: separate OpenPath from the Secure struct <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5793> | 14:34 |
| Chipaca | oops, bug | 14:34 |
| * Chipaca fixes | 14:34 | |
| Saviq | pstolowski: no mention of "data directory" in the journal | 14:34 |
| Chipaca | mborzecki: https://pastebin.ubuntu.com/p/PgCMDG6HJK/ | 14:35 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5796 | 14:37 |
| mup | PR #5796: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5796> | 14:37 |
| Saviq | sergiusens: also, why are my parts always out of date these past days :/ I've to `clean -s pull` all the time :| | 14:38 |
| mup | PR snapd#5796 opened: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5796> | 14:38 |
| sergiusens | Saviq: talk to kyrofa about that; you are probably writing in the source tree | 14:39 |
| sergiusens | Saviq: might be a good time to enable auto re-sync by default as this change is causing pain (I fell for it too) | 14:39 |
| sergiusens | kyrofa: it would be good to say why something is considered dirty, this hit me too a while back when I was writing to curdir | 14:40 |
| Saviq | http://paste.ubuntu.com/p/vkpZ7Rqkk2/ | 14:40 |
| Saviq | doesn't look like I am | 14:40 |
| pstolowski | Saviq: hmm, ok, dunno then, that's what i grokked from the code. is this first time you saw that? reproducible? | 14:40 |
| Saviq | pstolowski: I had it once before a while ago, unlikely to be reproducible | 14:41 |
| Saviq | may be some network wait I'm hitting or some such | 14:41 |
| mborzecki | Chipaca: maybe we should skip respetive tests if go test is ran by root | 14:43 |
| mborzecki | Chipaca: and it's not reproducing | 14:43 |
| Saviq | sergiusens: when using lxd environment, snapcraft inside the container is installed stable, that expected? | 14:43 |
| mup | PR snapd#5794 closed: ifacestate: retry on "discard-snap" in autoconnect conflict check <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5794> | 14:44 |
| sergiusens | Saviq: yes, we disabled injection given the snapd permission changes | 14:45 |
| Saviq | ack | 14:45 |
| Chipaca | ok, so i got the reason for the bug | 14:46 |
| Chipaca | about mkdirallchown | 14:46 |
| Chipaca | now how to fix | 14:46 |
| Chipaca | hmm | 14:46 |
| Chipaca | :-) | 14:46 |
| pstolowski | Saviq: might be a long shot / silly question - is your disk (ssd?) in a good shape? | 14:49 |
| Saviq | pstolowski: not getting 25min iowaits if that's what you're asking ;) | 14:52 |
| pstolowski | Saviq: okay, i take it as 'yes it is' ;) | 14:53 |
| Chipaca | zyga: the fancypants O_TMPFILE wouldn't've caught this bug | 14:53 |
| Chipaca | mborzecki: I'll have a pr up in a bit | 14:53 |
| Saviq | pstolowski: not saying it's great, but that's rather it being slower than I'd have liked (it's more than 4 years old now), but I've no reason to think it's dying :) | 14:54 |
| zyga | Chipaca: what was the bug? | 14:54 |
| zyga | I mean, what was the actual problem | 14:54 |
| zyga | I recall it's tmp is not tmp ;) | 14:54 |
| Chipaca | zyga: in one task: mkdirallchown /foo/bar/baz | 14:54 |
| Chipaca | zyga: in another task: mkdirallchown /foo/quux/meep | 14:54 |
| Chipaca | zyga: when /foo does not exist | 14:54 |
| Chipaca | now, race | 14:55 |
| zyga | ahhh | 14:55 |
| zyga | I see | 14:55 |
| zyga | the fd based implementation is not "racy" in the same sense, it would have one of those fail | 14:55 |
| zyga | well | 14:55 |
| zyga | it would not even | 14:55 |
| Chipaca | zyga: only because it doesn't rename | 14:55 |
| zyga | because they to ahead and mkdir | 14:55 |
| zyga | and just handle ENOENT | 14:55 |
| zyga | so it would not be even noticed | 14:55 |
| zyga | yeah | 14:55 |
| zyga | we could change umask | 14:55 |
| Chipaca | zyga: right, they make it in the final place, without worrying about it having the wrong uid/gid | 14:56 |
| zyga | to ensure we create 000 | 14:56 |
| zyga | and then chown | 14:56 |
| zyga | and chmod | 14:56 |
| Chipaca | zyga: unless your implementation handles EEXIST it'll have a similar race | 14:56 |
| pstolowski | Saviq: was thinking of bad sector reallocation that brings i/o to a halt and doesn't even produce errors; but yeah, it's probably something else | 14:57 |
| Chipaca | zyga: anyway the quick fix is to add a lock :-) so i'm doing that to unbreak master | 14:57 |
| zyga | +1 | 14:57 |
| zyga | Chipaca: var gil sync.Mutex | 14:57 |
| Saviq | pstolowski: I'd see it in dmesg, and I don't | 15:03 |
| zyga | pstolowski: small review on https://github.com/snapcore/snapd/pull/5762#pullrequestreview-153381760 | 15:04 |
| mup | PR #5762: ifacestate: don't initialize udev monitor until we have a system snap <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5762> | 15:04 |
| Chipaca | mborzecki: unit tests running now, as soon as it's green i'll push | 15:06 |
| Chipaca | mborzecki: (no tests added by these changes...) | 15:06 |
| pstolowski | zyga: thanks | 15:10 |
| pstolowski | zyga: i'll see if i can come up with a test case for that PR | 15:13 |
| zyga | pstolowski: just copy paste one and remove the extra snap init | 15:14 |
| pstolowski | zyga: btw, if you're in hotplug-reviewing spree, this one needs review as well https://github.com/snapcore/snapd/pull/5759 | 15:14 |
| mup | PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759> | 15:14 |
| zyga | I'm reading it :D | 15:14 |
| zyga | some feedback already pending, | 15:14 |
| Chipaca | mborzecki: zyga: #5797 | 15:23 |
| mup | PR #5797: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797> | 15:23 |
| zyga | Chipaca: ack, looking | 15:23 |
| mup | PR snapd#5797 opened: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797> | 15:24 |
| zyga | pstolowski: reviewed | 15:24 |
| Chipaca | zyga: pushing with a slightly nicer description (code unchanged) | 15:24 |
| pstolowski | zyga: thanks | 15:24 |
| zyga | mborzecki: can you re-check please: https://github.com/snapcore/snapd/pull/5795 | 15:24 |
| mup | PR #5795: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <https://github.com/snapcore/snapd/pull/5795> | 15:24 |
| zyga | Chipaca: done | 15:27 |
| Chipaca | zyga: ta | 15:33 |
| zyga | 7th day of the month and the modem shows 270GB of data traffic | 15:33 |
| zyga | hmmmm | 15:33 |
| Chipaca | mvo: why is 'systemctl start' trying to do 'systemd-tty-ask-password-agent'? | 15:34 |
| zyga | Chipaca: sudo? | 15:34 |
| Chipaca | zyga: https://launchpadlibrarian.net/387297120/psafxww | 15:34 |
| zyga | hmmm, that's unexpected | 15:35 |
| mvo | Chipaca: a good question, polkit prompt I would say | 15:36 |
| mvo | Chipaca: but *why* it is doing that is a mystery | 15:36 |
| mvo | Chipaca: \o/ this is the hanging dpkg? | 15:36 |
| Chipaca | mvo: yes | 15:36 |
| mvo | Chipaca: super mysterious - I would assume it only needs to do that for uid!=0 | 15:38 |
| mvo | Chipaca: hm, the man-page does not even mention polkit, it talks about disk encryption passowrds and the like | 15:38 |
| mvo | Chipaca: I found https://bugs.freedesktop.org/show_bug.cgi?id=92430 about this | 15:40 |
| zyga | I'll grab coffee | 15:40 |
| zyga | it's late but I ... I'm addicted I guess :) | 15:40 |
| pstolowski | zyga: heh, coffee here as well | 15:41 |
| Chipaca | mvo: that last comment tho | 15:41 |
| mvo | Chipaca: yeah, not exactly helpful | 15:41 |
| mvo | Chipaca: also https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1565617 which indicates we need to double check if debhelper systemd uses "--no-ask-password" when it runs systemctl | 15:43 |
| mup | Bug #1565617: "polkitd.service is masked" warnings on package install while policykit-1 is unpacked but not yet configured <architecture-ppc64le> <bugnameltc-139608> <patch> <severity-high> <targetmilestone-inin16041> <systemd (Ubuntu):Fix Released by pitti> <https://launchpad.net/bugs/1565617> | 15:43 |
| Chipaca | mvo: ps output says no | 15:43 |
| mvo | Chipaca: /o\ | 15:45 |
| pstolowski | oh well, stateengine.go:101: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET | 15:45 |
| mvo | pstolowski: I wonder if that is related to the issue that cachio saw earlier about the apt hook test failure. does the store know about this (if its consistent?) | 15:46 |
| mvo | Chipaca: /usr/bin/deb-systemd-invoke is what is actually called form the postinst, I wonder if we can add some env there to tell it to --no-ask-password | 15:47 |
| pstolowski | mvo: store as 'store people'? | 15:49 |
| mvo | pstolowski: yes, sorry | 15:50 |
| pstolowski | mvo: no idea, not from me | 15:50 |
| Chipaca | mvo: looks like that would be the ideal place to add the --no-ask-password to everything | 15:52 |
| pedronis | pstolowski: is that error from today? | 15:53 |
| mvo | Chipaca: yeah | 15:53 |
| pedronis | pstolowski: or from the past days | 15:53 |
| pstolowski | pedronis: yes, Sep 07 14:45:36 | 15:54 |
| pstolowski | pedronis: https://api.travis-ci.org/v3/job/424210574/log.txt | 15:54 |
| pedronis | pstolowski: I'm asking in the store | 15:57 |
| mvo | Chipaca: the log you pointed to earlier, from what bug was that? I wonder what else got upgraded there. I mean, what might happen is the following: polkit and snapd get upgraded. polkit daemon gets upgraded first, is stopped and unpacked. snapd is stopped and unpacked, snapd is started before polkit and for some reason systemctl wnats to talk to it even though uid==0 but no polkit (not started yet) so that hangs forever. a | 15:57 |
| mvo | bit of a wild theory so the /var/log/apt/history.log would be helperful | 15:57 |
| mvo | Chipaca: or the full terminal log of the upgrade (to see if polkit was deconfigured before) | 15:57 |
| mvo | (anyway some speculation at this point) | 15:58 |
| pstolowski | pedronis: thanks; do you need that log or can i restart the tests? | 15:58 |
| Chipaca | mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1791087 | 15:58 |
| mup | Bug #1791087: snapd 2.35.1+18.10 hang on apt upgrade <snapd (Ubuntu):New> <https://launchpad.net/bugs/1791087> | 15:58 |
| Chipaca | mvo: you asked them for 'ps afx', i asked them for 'ps afxww' when the interesting bit got elided :-) | 15:59 |
| mvo | Chipaca: heh, woah, the joy of crufty tools | 16:00 |
| mvo | Chipaca: thanks a lot for this | 16:00 |
| pedronis | pstolowski: retry | 16:08 |
| pstolowski | k | 16:09 |
| pedronis | there may be some setup in the store that is ok for normal clients but is a problem for out tests | 16:09 |
| zyga | re | 16:09 |
| zyga | made coffee, cleaned the kitchen, bathroom and bedroom before $wife gets home :) | 16:09 |
| pedronis | if it becomes a regular problem we need to think | 16:10 |
| ogra | zyga, hey ... layouts .... if i had a content snap providing stuff into $SNAP/opt/foo and would re-map $SNAP/opt to /opt in an app snap, would /opt/foo be accesible for me ? | 16:11 |
| Chipaca | mvo: https://pastebin.ubuntu.com/p/HJknjWkXb3/ maybe | 16:11 |
| Chipaca | mvo: should I ask the guy to try this before we propose it? | 16:11 |
| zyga | yes | 16:12 |
| zyga | ogra: ^ yes | 16:12 |
| zyga | brb, $wife is back | 16:12 |
| ijohnson | ogra, zyga: note that the actual files are inside the content snap, not inside the current app snap | 16:12 |
| Chipaca | mvo: I'll ask them :) | 16:12 |
| pstolowski | pedronis: ack | 16:12 |
| mvo | Chipaca: \o/ | 16:12 |
| gQuigs | hi there, I did a snap revert firefox yesterday (to get back to the previous beta) but today it bumped ahead again - how do I figure out what happened? | 16:19 |
| Chipaca | gQuigs: snap list --all firefox | 16:20 |
| Chipaca | gQuigs: or, snap info firefox | 16:20 |
| Chipaca | gQuigs: has there been a new revision? | 16:20 |
| Chipaca | gQuigs: otherwise, we can look in 'snap changes' to see what happened exactly | 16:20 |
| gQuigs | Chipaca: how would I tell that bit? I only have the 62.0b20-1 (what I reverted to) and 63.0b4-1 (which maybe has been upped in number) | 16:21 |
| gQuigs | snap changes might do it | 16:21 |
| gQuigs | 129 Done today at 07:46 PDT today at 07:47 PDT Auto-refresh snap "firefox" | 16:21 |
| gQuigs | but if there was an older 63.0b3 say how would I see that? | 16:22 |
| Chipaca | gQuigs: have you tweaked it to only keep two revisions of snaps? | 16:22 |
| gQuigs | Chipaca: nope, two other snaps have 3 versions on list --all | 16:23 |
| zyga | ogra, ijohnson: if by "remap" you mean a rbind then yes | 16:23 |
| Chipaca | gQuigs: but firefox just has two? | 16:23 |
| Chipaca | strange | 16:23 |
| pedronis | pstolowski: Chipaca: for details, afaict the store will refuse to serve /names more than once per second for the same client | 16:23 |
| gQuigs | Chipaca: yup | 16:23 |
| Chipaca | gQuigs: revision 127, current in beta, was put there on "2018-09-07T08:03:31.592103+00:00" | 16:23 |
| Chipaca | gQuigs: so, yeap, new revision fresh this morning | 16:24 |
| mup | PR snapd#5795 closed: cmd/snap-update-ns: re-factor pair of helpers to call fstatfs once <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5795> | 16:24 |
| gQuigs | Chipaca: thanks! how did you tell that? | 16:24 |
| Chipaca | gQuigs: right now, I looked at the store api | 16:25 |
| Chipaca | gQuigs: we'll be exposing these dates in 'snap info' at some point (soon! i hope!) | 16:25 |
| Chipaca | gQuigs: but I think it's also exposed on the web | 16:25 |
| Chipaca | 1 sec | 16:25 |
| Chipaca | gQuigs: https://snapcraft.io/firefox | 16:25 |
| Chipaca | gQuigs: click 'more versions' | 16:25 |
| ijohnson | zyga: ok, I misunderstood the line here to mean that the source had to be inside the current snap: https://github.com/snapcore/snapd/blob/master/snap/validate.go#L760 | 16:26 |
| gQuigs | Chipaca: thanks a bunch! | 16:26 |
| jdstrand_ | popey, Wimpress: fyi, https://forum.snapcraft.io/t/approval-for-fwupd-classic-snap/5755/9. (granted) | 16:26 |
| zyga | ijohnson: yes, you can use layouts to "spread" the content of a snap around | 16:26 |
| zyga | you cannot use them to take contents from somewhere on the system and put it in other places | 16:26 |
| Wimpress | jdstrand_: Thank you! | 16:26 |
| ijohnson | zyga: so as long as the content interface from snap1 is connected somewhere inide $SNAP, $SNAP_DATA, etc. for snap2, snap2 is allowed to use layouts to make a new mount of the files from the content snap (snap1) somewhere else on the system (just for snap2)? | 16:28 |
| * zyga parses that | 16:28 | |
| zyga | yes | 16:28 |
| zyga | that's accurate | 16:28 |
| zyga | _but_ | 16:29 |
| zyga | layouts are currently happening before content mounts | 16:29 |
| zyga | so it depends on the peer sharing | 16:29 |
| zyga | you will first to a layout from $SNAP/foo to /usr/foo | 16:29 |
| zyga | then a content from $OTHER_SNAP/shared to $SNAP/foo | 16:29 |
| === jdstrand_ is now known as jdstrand | ||
| zyga | which _iff_ propagation is not set to private (it's not) will propagate to /usr/foo | 16:29 |
| zyga | from the point of view of $SNAP (not $OTHER SNAP) | 16:30 |
| zyga | ijohnson: ^ does that make sense? | 16:30 |
| ijohnson | Yeah that makes sense. Slightly related question, does content sharing use bind mounts? | 16:31 |
| zyga | yes | 16:31 |
| ijohnson | Got it | 16:31 |
| zyga | both bind mounts and layouts use the same mount backend | 16:31 |
| zyga | some other things do as well | 16:31 |
| zyga | you can see the resulting mount profile in /var/lib/snapd/mount/... | 16:31 |
| zyga | it's a fstab-like file | 16:31 |
| zyga | (with extra options) | 16:31 |
| ijohnson | Interesting, good to know, thanks! | 16:33 |
| zyga | ijohnson: you can also look at the actual mount profile (that is applied to the mount namespace) in /run/snapd/ns/*.fstab | 16:34 |
| zyga | ijohnson: those can differ as some mounts may fail (layout mounts cannot fail or the app process will not be allowed to start) | 16:34 |
| zyga | ijohnson: snap-update-ns can look at both and apply changes to make the mount namespace have a desired look | 16:35 |
| mvo | Chipaca: the 18.10 upgrade issue gets out of hand it seems, I got a personal mail asking why I broke snapd :/ | 16:35 |
| zyga | mvo: ouch! | 16:35 |
| Chipaca | mvo: well? why did you? | 16:35 |
| ijohnson | zyga: I see, also good to know | 16:35 |
| mvo | Chipaca: I ask myself this question every day | 16:35 |
| * Chipaca hugs mvo | 16:35 | |
| * zyga hugs them both | 16:35 | |
| Chipaca | mvo: it's friday. It's ok to tell peoplel to FOAD | 16:35 |
| * zyga had to google that | 16:36 | |
| mvo | Chipaca: LOL | 16:36 |
| mvo | Chipaca: I had to google it as well | 16:36 |
| * mvo hugs Chipaca for learning something really useful | 16:36 | |
| abeato | sergiusens, hey, do you know if at some point in time snapcraft explicitly remove debug_info from binaries? or set CFLAGS in some way? | 16:36 |
| Chipaca | oh no what have i done | 16:36 |
| Chipaca | ₒₕ ₙₒ | 16:37 |
| sergiusens | abeato: not in the form of env var... | 16:37 |
| zyga | Chipaca: 5759 is green | 16:38 |
| abeato | sergiusens, the thing is that since 2/3 months I saw this difference: previously there was no debug info (-g option), but now it is there. Using the autotools plugin. It looks like -g is usually the default configuration, so my guess is that snapcraft/plugin was doing something that prevented -g to be set | 16:39 |
| abeato | sergiusens, which is fine, but I would like to know what happened | 16:39 |
| mup | PR snapd#5796 closed: cmd/snap-update-ns: detach BindMount from the Secure type <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5796> | 17:05 |
| Chipaca | zyga: 5759? me? | 17:05 |
| zyga | one last from the pack: | 17:05 |
| zyga | Chipaca: hmm? | 17:05 |
| zyga | Chipaca: your fix PR is green | 17:05 |
| Chipaca | 5797 | 17:06 |
| mup | PR snapd#5798 opened: cmd/snap-update-ns: detach Mk{Prefix,{File,Dir,Symlink{,All}}} from S… <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5798> | 17:06 |
| zyga | Chipaca: can I please drag you into a quick look on a simple PR ^ | 17:06 |
| zyga | Chipaca: but I meant another PR earlier | 17:06 |
| zyga | https://github.com/snapcore/snapd/pull/5797 | 17:06 |
| mup | PR #5797: osutil, o/snapshotstate, o/sss/backend: quick fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/5797> | 17:06 |
| zyga | this is what I meant before :) | 17:06 |
| Chipaca | ye | 17:06 |
| Chipaca | missing a +1 though | 17:06 |
| Chipaca | looking at 5798 now | 17:06 |
| Chipaca | zyga: nice | 17:07 |
| zyga | yeah, all generic (for now) | 17:07 |
| zyga | I'll have a twist next | 17:07 |
| zyga | though if you want _now_ is the time to move them to another package :) | 17:08 |
| zyga | (now as in after this branch) | 17:08 |
| Chipaca | zyga: _now_ is the time to eow, dude | 17:08 |
| zyga | Chipaca: hold my beer | 17:08 |
| zyga | oh wait! | 17:08 |
| zyga | no :) | 17:08 |
| zyga | I'm really into chopping the boilerplate off the trespassing fix and landing it | 17:09 |
| zyga | and I'm writing a small new thing (wanna help?) | 17:09 |
| zyga | not strictly related to snapd, related to golang strongly | 17:09 |
| Chipaca | dunno, sounds dangerous | 17:09 |
| Chipaca | zyga: go on then | 17:09 |
| zyga | Chipaca: lemme push | 17:09 |
| cachio | mvo, taking a look to the catalog, I see this | 17:12 |
| cachio | aws-cli.aws[{"snap":"aws-cli","version":"1.15.71"}] | 17:12 |
| mvo | cachio: uh, ok | 17:24 |
| mvo | cachio: so maybe a real bug | 17:24 |
| mvo | cachio: if its in the catalog | 17:24 |
| mvo | niemeyer: I updated 5583 based on the standby helper we talked about earlier. but probably something for next week | 17:27 |
| niemeyer | mvo: Thanks! | 17:30 |
| niemeyer | mvo: Yeah, I'm about to jump into another meeting | 17:31 |
| mvo | niemeyer: no worries, have a good one | 17:31 |
| cachio | mvo, it seems to be | 17:35 |
| pstolowski | pedronis: hmm, i see, sounds like something we should address in the tests | 17:41 |
| === pstolowski is now known as pstolowski|eow | ||
| Chipaca | zyga: http://r.chipaca.com/pprof001.svg | 17:52 |
| zyga | mmm | 17:52 |
| zyga | this 5K screen is useful now ;) | 17:53 |
| Chipaca | zyga: looks like parseMountOpts could use some care | 17:53 |
| Chipaca | zyga: as could assert's filesystemBackstore | 17:53 |
| zyga | wow, yeah | 17:53 |
| zyga | how can I reproduce this graph? | 17:53 |
| Chipaca | also, we should probably look into whether the bug about json.RawMessage vs *json.RawMessage goes away with go 1.10 or sth | 17:54 |
| Chipaca | zyga: the way i've got it is rather hacky, i'm sure there's a beter way, but | 17:54 |
| zyga | no worries | 17:55 |
| zyga | I'll look at parse now | 17:55 |
| Chipaca | zyga: https://pastebin.ubuntu.com/p/PjMbFCk8GX/ | 17:55 |
| Chipaca | zyga: then, go tool pprof --alloc_space http://localhost:4040/debug/pprof/heap | 17:55 |
| Chipaca | zyga: then 'web' | 17:55 |
| Chipaca | zyga: before doing the 'go tool' thing, do some things with the snapd though | 17:56 |
| zyga | Chipaca: quick test | 17:56 |
| Chipaca | zyga: snap list; snap find foo; snap refresh; snap changes; snap info core http potato | 17:56 |
| Chipaca | is what i did | 17:56 |
| zyga | Chipaca: go to mountinfo_linux.go | 17:56 |
| zyga | at the bottom | 17:56 |
| Chipaca | going | 17:56 |
| Chipaca | zyga: there | 17:57 |
| zyga | change the map we make in that function | 17:57 |
| zyga | to have initial size of strings.Count(opts, ",") | 17:57 |
| zyga | +1 | 17:57 |
| zyga | and see if that makes any difference please | 17:57 |
| zyga | I wonder if it is the map | 17:57 |
| Chipaca | zyga: I think it's the strings.genSplit | 17:57 |
| Chipaca | bah, maybe a bit of both | 17:58 |
| zyga | we can easily remove one of the splits | 17:58 |
| zyga | the 2nd one is a bit more work but we could do it if it shows up in the graph this much | 17:58 |
| zyga | apparmor's addContent could use more love as well | 18:00 |
| zyga | and the json thing you mentioned | 18:00 |
| Chipaca | zyga: http://r.chipaca.com/pprof001.1.svg | 18:01 |
| zyga | more memory! | 18:01 |
| Chipaca | zyga: yeah, not sure what i'm seeing | 18:02 |
| zyga | what are the arrows? | 18:02 |
| zyga | and the memory sizes on them? | 18:02 |
| Chipaca | zyga: injuns | 18:02 |
| zyga | what does that mean? | 18:02 |
| zyga | Chipaca: in any case, I think when making performance improvements common sense need not apply | 18:03 |
| zyga | it's often surprising when one makes a change expecting a effect | 18:04 |
| zyga | when one observes the opposite effect | 18:04 |
| zyga | because reality is much more complicated | 18:04 |
| Chipaca | zyga: https://stackoverflow.com/questions/35871365/interpreting-pprof-heap-diagrams | 18:04 |
| zyga | mm, very useful | 18:05 |
| zyga | ok | 18:05 |
| zyga | Chipaca: so that single function allocates all that memort | 18:06 |
| zyga | given that it usually handles just a few bytes this is very surprising | 18:06 |
| Chipaca | zyga: it's called a lot | 18:07 |
| zyga | hmmm, snapd calls it to make mount profiles | 18:08 |
| zyga | and to parse fstab files | 18:08 |
| zyga | maybe we need to just ... call it less? | 18:08 |
| zyga | ha | 18:08 |
| zyga | it's called for all the little bits | 18:08 |
| zyga | it's called to know if we are in nfs land | 18:09 |
| zyga | we could _probably_ call it from ensure | 18:09 |
| zyga | and cache the yes-no answer | 18:09 |
| zyga | well, then we'd call it every 5 minutes | 18:10 |
| zyga | still | 18:10 |
| Chipaca | whoa | 18:10 |
| Chipaca | so, i've got 35 snaps | 18:10 |
| zyga | what? :) | 18:10 |
| Chipaca | map[31:1836 18:108 44:108 11:1188 33:108 70:108 7:108 13:216 14:108 8:108 54:108 17:4428 2:8100 15:108 22:216 9:216 19:108 10:324 25:648 30:108 91:108 24:324 43:108 29:108] | 18:10 |
| zyga | what's that map? | 18:11 |
| Chipaca | zyga: that's len(opts):num of times called with len(opts) | 18:11 |
| Chipaca | that's a lot of lil' maps | 18:11 |
| Chipaca | zyga: what's the lifetime of these things? | 18:11 |
| Chipaca | where do they go? | 18:11 |
| zyga | they are probably very short lived but long enough to fool escape analysis | 18:12 |
| zyga | they are used in ... | 18:12 |
| zyga | osutil.IsHomeUsingNFS | 18:12 |
| zyga | https://github.com/snapcore/snapd/blob/master/osutil/nfs_linux.go#L33 | 18:13 |
| zyga | so, maybe instead of a "gimme map" | 18:13 |
| zyga | we can have a "callback on key=val" function | 18:13 |
| Chipaca | zyga: it's also used from overlay_linux | 18:13 |
| Chipaca | zyga: and from IsMounted | 18:14 |
| zyga | yeah | 18:14 |
| Chipaca | however | 18:14 |
| Chipaca | hm | 18:14 |
| zyga | same usage pattern | 18:14 |
| zyga | as a side note I'm happy they _all_ use this implementation | 18:14 |
| zyga | and not each have one of their own | 18:15 |
| Chipaca | zyga: one easy thing with minimal changes would be to not load the options until needed | 18:15 |
| zyga | yeah | 18:15 |
| zyga | make it a method | 18:15 |
| zyga | but I'd go all the way to kill the parser returning a list | 18:15 |
| Chipaca | zyga: i.e. not load MountOptions nor SuperOptions at all in Parse, and have a LoadOptions or sth | 18:15 |
| zyga | and have a callback style parser | 18:15 |
| zyga | just Options() | 18:15 |
| Chipaca | yah that might be even better | 18:15 |
| zyga | then no list | 18:16 |
| zyga | and almost no map | 18:16 |
| Chipaca | yup | 18:16 |
| zyga | neat | 18:16 |
| Chipaca | bigger change though | 18:16 |
| zyga | yeah true | 18:16 |
| zyga | the option will be sufficient for most of this | 18:16 |
| Chipaca | zyga: but yeah, building a list is going to be bad because people have a lot of snaps :-) | 18:17 |
| zyga | loots of mounted things | 18:17 |
| Chipaca | mhmm | 18:17 |
| Chipaca | zyga: and then there are these crazy people implementing "layouts" | 18:17 |
| zyga | nah, nobody would do that | 18:18 |
| Chipaca | :-D | 18:18 |
| zyga | the up side is that we don't look inside the mount namespaces often | 18:18 |
| zyga | only from snap-update-ns | 18:18 |
| zyga | and you didn't profile that s | 18:18 |
| zyga | so whee :D | 18:18 |
| Chipaca | zyga: it's pizza & beer time here | 18:18 |
| * zyga hugs Chipaca | 18:18 | |
| Chipaca | so i'm off to address that issue | 18:18 |
| zyga | that's a good time | 18:18 |
| zyga | though I though UK does tea time | 18:18 |
| zyga | not beer time | 18:18 |
| zyga | ttyl! | 18:18 |
| Doctor_Nick | sign of troubles | 19:54 |
| mup | PR snapcraft#2249 opened: build providers: provide support to shell in <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2249> | 20:07 |
| mup | PR snapcraft#2250 opened: project_loader: add preflight check <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2250> | 20:07 |
| Chipaca | Doctor_Nick: ? | 20:47 |
| mup | PR snapcraft#2243 closed: [WIP] plugin API: support command-chain <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2243> | 20:49 |
| mup | PR snapcraft#2251 opened: pluginhandler: stop using alias for snapcraftctl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2251> | 20:58 |
| mup | PR snapcraft#2252 opened: Build providers debug shell <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2252> | 21:49 |
| kyrofa | roadmr, you around? | 21:53 |
| roadmr | hi kyrofa! I'm close to EOD but for now, still here | 21:54 |
| kyrofa | roadmr, something funky is happening with nextcloud, it's saying reviews are held up behind something that says it still hasn't been reviewed yet, but still looks like it failed | 21:55 |
| roadmr | kyrofa: oh ouch | 21:55 |
| roadmr | let me have a look | 21:55 |
| kyrofa | Thank you | 21:55 |
| roadmr | kyrofa: this appears to be the stuck revno https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8754/ | 21:55 |
| roadmr | and the status is "Task 2e0a9939-79a3-49ea-96b5-69fa540e57e5 failed. " | 21:55 |
| kyrofa | Indeed, and right above that "Automated review not yet completed" | 21:56 |
| roadmr | kyrofa: I re-fired the automated review | 21:56 |
| kyrofa | And no log anywhere | 21:56 |
| kyrofa | roadmr, so did it fail, or not? If so, why didn't the rest continue being reviewed? | 21:56 |
| roadmr | kyrofa: well I have logs but they'll just say that the click-reviewer-tools automated process took longer than X, even after retrying Y times | 21:56 |
| kyrofa | Oh that's fun | 21:56 |
| roadmr | kyrofa: after the l1TF mitigations and reboot of everything, we've found things are much much slower in our cloud :( we've bumped the timeouts significantly | 21:57 |
| kyrofa | It seems the entire world has slowed down recently with those, yeah | 21:57 |
| roadmr | kyrofa: but it's good that you call attention to this; we may need to up them even further. Still assessing what the world looks like now | 21:57 |
| roadmr | kyrofa: why does nextcloud push so many revisions? do they have one for each PR or somesuch? | 21:58 |
| kyrofa | roadmr, no thankfully, that would be far too much, these are dailies | 21:58 |
| kyrofa | But of course, for every arch | 21:59 |
| kyrofa | And for a few releases | 21:59 |
| roadmr | 13 revisions over 45 minutes is about one revision every 3:30 minutes, and automated review is taking about 10 minutes for a snap this size :/ | 21:59 |
| roadmr | kyrofa: other than the L1TF armageddon, we also recently (1 month or so) enabled resquashfs enforcement, this means the snaps must be unpacked and repacked to verify the checksums. This also slows things down a bit but is necessary for security and to avoid squashfs evil | 22:00 |
| kyrofa | roadmr, yeah I'm familiar with that one | 22:01 |
| roadmr | kyrofa: we can maybe revisit the "if a revision fails, just leave it behind and continue checking the other ones" behavior. However, I think that's in place, buuut... | 22:02 |
| roadmr | this case is different: the revision didn't fail-fail, but was held for manual review because the automated review couldn't be completed, so we don't know really. So in these cases we err to leaving it in "needs manual review", which does block the queue by design | 22:02 |
| roadmr | at least the tweaks Matías did recently do allow us to manually fix things; before, these would just have gotten stuck in limbo, I'm sure you remember that too, from 3 weeks ago or so | 22:03 |
| kyrofa | Oh yes, I remember. This too: https://forum.snapcraft.io/t/launchpad-upload-failing-waiting-for-previous-upload-s-to-complete-their-review-process/7135/2 | 22:05 |
| roadmr | right :/ due to the slowness, revision reviews are piling up in the queue :( | 22:06 |
| roadmr | aha, interesting. kyrofa Task 27c34078-834c-4e1b-82a1-b4e2f2398fba is waiting to be retried. this is the review for 8755... | 22:07 |
| roadmr | which is interesting because a moment ago it was "Waiting for execution". Does waiting time count against the timeout? that would suckk... | 22:08 |
| kyrofa | Uh oh :P | 22:10 |
| roadmr | kyrofa: ah interesting - I'd increased the timeouts but it looks like the old ones are still in effect :/ | 22:11 |
| roadmr | !%#&@% kyrofa sorry, this is my fault :( I cowboyed the timeout increases in production 2 days ago but today we did a rollout which clobbered those changes and I forgot to have them reapplied :( | 22:14 |
| kyrofa | roadmr, that's alright, thanks for fixing | 22:15 |
| roadmr | this is why I must always commit these changes to the source tree | 22:15 |
| roadmr | kyrofa: a question - in https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8756/ do you have any buttons (green buttons) at the very bottom? https://dashboard.snapcraft.io/snaps/nextcloud/revisions/8756/ | 22:21 |
| kyrofa | roadmr, no, I see reject and remove from queue only | 22:23 |
| roadmr | oh ok... | 22:23 |
| roadmr | I have a "rerun automated review" button, and any store admin would have that, helpful to unwedge revisions. | 22:24 |
| kyrofa | roadmr, yeah I lost such privileges once you guys made finer-grained ones | 22:24 |
| roadmr | sorry :( | 22:25 |
| roadmr | aha, very interesting! kyrofa haha I like a good mystery. One of the passing tasks finished in just over 3 minutes: Task devportal.tasks.PackageReviewTask[27c34078-834c-4e1b-82a1-b4e2f2398fba] succeeded in 189.731960843s | 22:29 |
| roadmr | kyrofa: and others are failing because they go over 6 minutes without finishing. So apparently some of the servers are slower in processing tasks than others. I'll make notes and investigate more on Monday | 22:30 |
| roadmr | kyrofa: I think we have a slowpoke node :( I'm seeing nextcloud 8756 consistently land on that same node and time out :( I'll keep an eye on your queue and try to nudge it, but must EOD now... I've made a note of this and will look again on Monday | 22:49 |
| mup | PR snapd#5786 closed: tests: update prepare/restore for nightly suite <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5786> | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
