| === pbek_ is now known as pbek | ||
| === pstolowski|afk is now known as pstolowski | ||
| mvo | pstolowski: good morning :) | 07:18 |
|---|---|---|
| pedronis | mvo: hi, I'm going to merge #5502 today | 07:23 |
| mup | PR #5502: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502> | 07:23 |
| mvo | pedronis: ok, I look at it now | 07:28 |
| mvo | pstolowski: interessting fix in the osutil/udev PR - is this a signed/unsigned issue? | 07:50 |
| mvo | s/is/was/ | 07:50 |
| pstolowski | mvo: yes | 07:50 |
| pedronis | mvo: thx | 07:51 |
| mvo | pstolowski: interessting | 07:51 |
| pstolowski | mvo: it wouln't happen if my tests didn't use 0xff's to simulate invalid offset | 07:51 |
| mvo | pedronis: thank you, nice improvement, also nice to see how much cleaner it got | 07:52 |
| mvo | pstolowski: a, sweet | 07:52 |
| mvo | pstolowski: I was wondering how you get such a big offset that its a problem on 32bit | 07:52 |
| mvo | pstolowski: nice to know there was a test for it! | 07:52 |
| pstolowski | mvo: i'm not quite sure why it didn't panic on 64bits though. | 07:52 |
| pstolowski | mvo: but i added debug and it clearly showed negative number there | 07:53 |
| mvo | pstolowski: I assume its because on 64bit 0xff000000 will not wrap to a neagative number (space in the 64 bit int left). but I have not really looked at the details so I might be wrong | 07:54 |
| mvo | Chipaca: good morning | 07:56 |
| pstolowski | mvo: i think you're right. re your earlier question, the test parses crafted garbage data | 07:56 |
| Chipaca | mvo: it is! how're you today? | 07:56 |
| mvo | fun! the degraded test found that we have a sshgurad.service that is broken in our test images | 07:56 |
| mvo | pstolowski: tests ftw! nice job | 07:56 |
| mvo | Chipaca: I'm well, thank you! having fun reading code and poking at our boot stuff | 07:57 |
| pstolowski | i made a quickfix in the PR and also proposed it upstream | 07:57 |
| mvo | Chipaca: hope you are well too? | 07:57 |
| mvo | pstolowski: ta | 07:57 |
| Chipaca | tests ftw indeed | 07:58 |
| mvo | Chipaca: I'm also loosing hair over the question *why* the snap-run-hook test fails on core18 | 07:58 |
| Chipaca | mvo: yep! looking forward to the day | 07:58 |
| Chipaca | mvo: SCSI Chain overterminated | 07:58 |
| mvo | Chipaca: *cough* those were the days | 07:58 |
| * Chipaca thinks the bofh excuse database needs updating | 07:59 | |
| pstolowski | nb, it's interesting Go chose to return int from len() | 07:59 |
| Chipaca | pstolowski: uint is a second-class citizen | 07:59 |
| mvo | pstolowski: fun, there is even a stack-overflow question about why go is doing that (and the answer even makes some sense) | 08:00 |
| pstolowski | mvo: do you have a link? | 08:09 |
| mvo | pstolowski: https://stackoverflow.com/questions/39088945/why-does-len-returned-a-signed-value | 08:10 |
| pstolowski | mvo: thanks, interesting explanations | 08:12 |
| Chipaca | pedronis: with 5502 landed, should I work on snapshotstate, or should i wait for a followup? | 08:14 |
| Chipaca | pedronis: and what about #5474 | 08:14 |
| mup | PR #5474: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474> | 08:14 |
| pstolowski | hmm interesting failure of google:ubuntu-16.04-64:tests/main/interfaces-accounts-service | 08:18 |
| pstolowski | https://www.irccloud.com/pastebin/XyMk8wi7/ | 08:18 |
| Chipaca | quoth the raven, WAT | 08:19 |
| mvo | meh, I get quota CPUS exceeded | 08:37 |
| mvo | in my latest PR | 08:37 |
| Chipaca | mvo: have we alerted people about the sshguard service thing? | 08:50 |
| mvo | Chipaca: not yet, might be related to our image | 08:51 |
| mvo | Chipaca: I mean to our version of the cloud-image | 08:51 |
| Chipaca | mvo: ah, i thought we were using stock | 08:51 |
| mvo | Chipaca: I'm not sure, I wanted to check with cachio | 08:51 |
| mvo | Chipaca: its slightly strange because sshguard is universe | 08:51 |
| Chipaca | ah | 08:52 |
| popey | https://forum.snapcraft.io/t/snap-refresh-fails-no-such-file-or-directory/6413 | 08:58 |
| popey | If someone has a moment to look at that I'd appreciate it | 08:58 |
| Chipaca | popey: https://i.imgur.com/iJoG4Ks.jpg | 09:02 |
| popey | IKR | 09:02 |
| popey | (I have seen this before, but only now have captured it) | 09:02 |
| ogra_ | must be all these airplanes interfering with the cosmic rays at your place | 09:04 |
| Chipaca | popey: the most WAT bit is that after the Error, r319 is active | 09:04 |
| popey | fun, right? | 09:04 |
| Chipaca | i.e the one it just said didn't exist | 09:04 |
| Chipaca | waiiit | 09:04 |
| popey | this isn't even a manky machine that's been running forever with all kinds of crap on it | 09:04 |
| Chipaca | feck | 09:05 |
| popey | it's a vm I woke up to test something unrelated | 09:05 |
| Chipaca | I mean, <curses> | 09:05 |
| Chipaca | it looks like we're adding the prerequisite N times | 09:05 |
| Chipaca | that can't be good | 09:05 |
| popey | so this is a snapd bug? :) | 09:09 |
| Chipaca | 3 times | 09:09 |
| Chipaca | yes | 09:09 |
| popey | \o/ | 09:10 |
| popey | I mean, oh dear. | 09:10 |
| popey | Thanks for looking at it. | 09:10 |
| Chipaca | popey: where's my emoji for person-blowing-a-raspberry | 09:10 |
| popey | colon thorn | 09:10 |
| popey | :þ | 09:10 |
| Chipaca | >:þ then | 09:11 |
| Chipaca | aka the angry lisping viking | 09:11 |
| popey | shall I file a bug in snapd? | 09:11 |
| Chipaca | popey: let me dig a little bit more first please | 09:11 |
| popey | okeydokey | 09:11 |
| Chipaca | my first dumb test of printing the name of the prerequisite when we decide to install it (after checking it wasn't due to be installed) shows that we're installing things that are already due to be installed | 09:12 |
| Chipaca | ooooh | 09:12 |
| Chipaca | this is probably because that snap is the default provider for a bunch of stuff | 09:12 |
| Chipaca | innit? | 09:12 |
| popey | ¯\_(ツ)_/¯ | 09:13 |
| * Chipaca talks to itself | 09:15 | |
| Chipaca | popey: yep, just repro'd it, on install | 09:18 |
| popey | yay | 09:19 |
| Chipaca | still digging further | 09:19 |
| Chipaca | (there is a race, which is why you're not seeing it all the time) | 09:19 |
| Chipaca | so, yeah | 09:21 |
| Chipaca | we r dumb | 09:21 |
| Chipaca | popey: I'll work on a fix, but feel free to file a bug | 09:22 |
| popey | kk | 09:22 |
| popey | thanks | 09:22 |
| Chipaca | popey: interestingly the refresh succeeded, also | 09:35 |
| Chipaca | I mean, the change failed, but everything installed | 09:35 |
| popey | yeah, when I have seen this in the past, I run "snap refresh" and it says it has nothing to do | 09:35 |
| Chipaca | yep | 09:36 |
| popey | also also, in other news "snap refresh" and "snap install" now take a phenomenally long time to actually do anything | 09:36 |
| popey | I feel like I'm staring at a broken computer when i run snap refresh or install these days | 09:36 |
| Chipaca | :-( | 09:36 |
| Chipaca | popey: I know, they used to be so zippy! :-( | 09:36 |
| Chipaca | interfaces code is _slow_ | 09:36 |
| popey | 14 seconds to do nothing | 09:37 |
| popey | i just refreshed then tried to refresh again, 14 seconds for the second run | 09:37 |
| Chipaca | popey: wait, it takes that long to say 'nothing to do'? | 09:37 |
| popey | yes | 09:37 |
| Chipaca | that's not what I thought you meant | 09:37 |
| Chipaca | let me try | 09:37 |
| pedronis | Chipaca: I will merge trunk in the follow ups, they will need review but you can start working on snapshot, you basically need to use AddAffectedSnapsByAttr | 09:37 |
| popey | https://www.irccloud.com/pastebin/JadUttj8/ | 09:37 |
| Chipaca | pedronis: and drop the old kludgy conflicts stuff | 09:37 |
| pedronis | yes | 09:38 |
| popey | wtf is it doing for 14 seconds? | 09:38 |
| Chipaca | popey: snap list | wc -l | 09:38 |
| pedronis | Chipaca: I alos need to update the wiki, there's quite a few kinds not mentioned there | 09:38 |
| Chipaca | popey: plz | 09:38 |
| Chipaca | pedronis: :-( thanks :-) | 09:38 |
| popey | 205 | 09:38 |
| Chipaca | do you have SNAPD_DEBUG enabled? | 09:39 |
| popey | god i hope not | 09:39 |
| popey | how can I tell? | 09:39 |
| Chipaca | popey: nah it shouldn't slow things down, just log more | 09:39 |
| Chipaca | popey: (and we've asked canonicalers to have it enabled (and SNAPD_DEBUG_HTTP=3 at least iirc) so we can figure out one-off errors from the logs) | 09:40 |
| Chipaca | popey: “journalctl -u snapd” would have a lot of DEBUG lines | 09:40 |
| popey | define " a lot" :) | 09:40 |
| Chipaca | popey: more than 0 | 09:40 |
| popey | i haz 0 | 09:40 |
| Chipaca | so, not a lot | 09:41 |
| Chipaca | :-) | 09:41 |
| popey | want another bug? | 09:41 |
| popey | news to me btw that you've asked canonicalers to have debug enabled | 09:41 |
| Chipaca | popey: if you can (even momentarily) turn on debug, we can see where the bug is | 09:41 |
| popey | ok | 09:41 |
| Chipaca | popey: I can forward you the email :-) | 09:41 |
| Chipaca | popey: subject «suggestion to work with debug enabled in snapd», from a year ago | 09:42 |
| popey | unread :) | 09:43 |
| * Chipaca goes to the shed to get a 2x4 | 09:43 | |
| popey | I have enabled this before (to debug store slow download issues) and having debug switched on made the error go away | 09:44 |
| popey | I am reluctant to enable these things as it makes my system behave differently than the people I talk to every day | 09:44 |
| popey | normals don't enable this, and neither to devs | 09:44 |
| Chipaca | popey: the _only_ thing setting these debug flags does, afaik, is change the logging options | 09:44 |
| popey | lies :) | 09:44 |
| Chipaca | popey: but I see your point | 09:44 |
| pedronis | well, but turning it off and on is worse | 09:45 |
| pedronis | it involves a restart | 09:45 |
| pedronis | which is sure to change things | 09:45 |
| popey | https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/7?u=popey | 09:45 |
| pedronis | given how snapd works | 09:45 |
| Chipaca | popey: snap downloads should be much faster since we switched to fastly | 09:45 |
| Chipaca | popey: but, snap refresh != snap downloads | 09:46 |
| popey | i have seen user reports of slow downloads | 09:46 |
| Chipaca | popey: 14 seconds for snap refresh, with 200 snaps, is rather unique which is why i'd like to see logs of it to know who's being slow | 09:46 |
| popey | https://askubuntu.com/questions/1056606/from-what-url-snaps-are-downloaded | 09:46 |
| popey | for example | 09:46 |
| popey | I am frustrated though, because the general response seems to be "ah well, can't do anything without debug data" | 09:46 |
| pedronis | Chipaca: a review of #5515 would be appreciated | 09:46 |
| mup | PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515> | 09:46 |
| popey | right, just enabled debug, now snap refresh is instant | 09:47 |
| Chipaca | popey: ok | 09:47 |
| Chipaca | popey: keep it enabled for a while and tell us if it gets slow | 09:47 |
| popey | will do, thanks | 09:47 |
| Chipaca | popey: pretty please | 09:47 |
| Chipaca | popey: (this would be bad news, or good news, because it'd indicate a bug in a part of snapd we're itching to change) | 09:48 |
| pedronis | Chipaca: ? is this a do nothing refresh | 09:48 |
| Chipaca | pedronis: yes | 09:48 |
| pedronis | Chipaca: do we have plans to change that? | 09:48 |
| Chipaca | pedronis: see his pastebin | 09:48 |
| pedronis | don't think so | 09:48 |
| Chipaca | pedronis: if it's snapd getting slow after a while because state in-memory means walking whatever bit of state takes 14+ seconds, then yes it's us | 09:49 |
| popey | hahaha, its gone slow again already :D | 09:49 |
| Chipaca | popey: e-e-excellent. gib logs. | 09:49 |
| popey | which logs, how? | 09:49 |
| Chipaca | popey: journalctl -u snapd | 09:49 |
| Chipaca | popey: from the latest 'started snapd' line | 09:50 |
| popey | http://paste.ubuntu.com/p/syNYjKjB64/ | 09:50 |
| popey | oh, too late, that's all of it | 09:50 |
| Chipaca | popey: that's not debug logs | 09:50 |
| popey | :( | 09:50 |
| popey | I typed what you asked | 09:50 |
| popey | maybe snapd didnt restart | 09:50 |
| * popey tries again | 09:51 | |
| popey | my bad, line 4709 onwards http://paste.ubuntu.com/p/xKMMN3fSdg/ | 09:52 |
| Chipaca | popey: if « journalctl -u snapd | grep DEBUG: » is empty, it didn't work | 09:52 |
| Chipaca | ah | 09:52 |
| Chipaca | now yes :-D | 09:52 |
| popey | haha, is that 200 stabs of the store api ? :) | 09:52 |
| Chipaca | oh | 09:52 |
| Chipaca | for the asserts refresh | 09:53 |
| pedronis | assertions, it's 1 or 2 api calls per snap | 09:53 |
| pedronis | we have plans to improve | 09:53 |
| pedronis | that but not immediate plans | 09:53 |
| Chipaca | the snaps refresh api call itself is super fast: 10:51:29.410762 to 10:51:30.377175 | 09:54 |
| popey | gold star for you :) | 09:54 |
| Chipaca | bah, 'super fast', less than a second | 09:54 |
| pedronis | :) | 09:54 |
| popey | dirty brown star for the store :) | 09:54 |
| Chipaca | it's python, less than a second is it doing its best | 09:54 |
| mvo | as a quick fix, could we do the assertion update only for non-interactive refreshes or something | 09:54 |
| * Chipaca suddenly finds himself to be evil | 09:55 | |
| pedronis | no | 09:55 |
| pedronis | we can't | 09:55 |
| pedronis | because validation | 09:55 |
| mvo | indeed | 09:55 |
| Chipaca | popey: could you file a bug, on snapd *and* snapstore, that having 200 snaps means refreshes take way too long | 09:55 |
| popey | sure thing! | 09:55 |
| popey | on it | 09:55 |
| Chipaca | popey: include these logs (from the last bit on), and the 'time' log | 09:55 |
| popey | Thanks for spending time to help me debug | 09:55 |
| popey | will do | 09:55 |
| Chipaca | taw | 09:55 |
| Chipaca | pedronis: dunno if you saw that we add prereqs twice and that breaks things | 09:56 |
| pedronis | Chipaca: no | 09:56 |
| pedronis | Chipaca: that's mvo actually :) | 09:56 |
| Chipaca | pedronis: true, that | 09:56 |
| Chipaca | mvo: it's all your fault! | 09:56 |
| mvo | Chipaca: meh | 09:56 |
| Chipaca | mvo: *all* of it | 09:56 |
| pedronis | maybe | 09:57 |
| Chipaca | mvo: even brexit | 09:57 |
| * mvo crumbles in depair | 09:57 | |
| Chipaca | i'm telling the bbc | 09:57 |
| pedronis | it depends exactly how it fails | 09:57 |
| mvo | Chipaca: do you have a reproducer | 09:57 |
| Chipaca | mvo: it's racy, but yes: snap install gnome-system-monitor gnome-calculator | 09:57 |
| Chipaca | mvo: if it fails to repro, clean up with: snap remove gnome-system-monitor gnome-calculator gnome-3-26-1604 gtk-common-themes | 09:57 |
| pedronis | theoretically there's only one prereq running at a time | 09:58 |
| Chipaca | basically a snap can have another snap more than once in its prereqs | 09:58 |
| Chipaca | and we don't check for that | 09:58 |
| pedronis | Chipaca: a snap, or a pair of snaps? | 09:58 |
| pedronis | ah, a snap | 09:59 |
| Chipaca | pedronis: just one should be enough | 09:59 |
| Chipaca | in fact it shold repro with just one | 09:59 |
| mvo | Chipaca: ok, once I finished wrestling with the snap-run-hook failure on core18 I'm on this one | 09:59 |
| Chipaca | mvo: already fixing it here | 09:59 |
| pedronis | Chipaca: mvo: it's because they added themes to the gnome lib snap itself | 09:59 |
| mvo | Chipaca: \o/ even better | 09:59 |
| pedronis | so now some snaps get to it through the snap and through gnome | 09:59 |
| pedronis | so we have a snap that is a default provider both for a snap and a default provider of that snap | 10:00 |
| pedronis | fun | 10:00 |
| pedronis | should also be easy to solve | 10:00 |
| popey | https://bugs.launchpad.net/snapstore/+bug/1782112 tada | 10:00 |
| mup | Bug #1782112: snap refreh is slow with lots of snaps installed <snapd:New> <Snap Store:New> <https://launchpad.net/bugs/1782112> | 10:00 |
| Chipaca | pedronis: wondering whether to solve it at install time, or at work-out-prereqs time | 10:01 |
| Chipaca | pedronis: the latter seems saner, the former more foolproof | 10:01 |
| pedronis | Chipaca: mmh | 10:02 |
| pedronis | Chipaca: in theory it should work already, but the theory is fragile | 10:02 |
| pedronis | apparently | 10:02 |
| popey | I'm surprised we don't send a blob of data to the store with the list of everything we want rather than 200 separate requests. | 10:02 |
| popey | seems terribly inefficient | 10:02 |
| pedronis | popey: that is the question | 10:03 |
| popey | Ah okay. Ignore me :) | 10:03 |
| pedronis | popey: everybody has a different list so caching would be defeated | 10:03 |
| pedronis | it needs bit more cleverness, some compromise | 10:03 |
| mvo | pedronis: if you could have a look at 5491 again today that would be greatly appreciated | 10:06 |
| pedronis | Chipaca: I mean in theory when we install gnome itself we should detect that the themes are already being installed, that doesn't seem to work though | 10:06 |
| popey | I appreciate I'm a bit of an outlier with 200 snaps installed :) | 10:06 |
| popey | blazing a trail | 10:06 |
| Chipaca | pedronis: because we create the task list and only add it to state if the whole thing worked | 10:06 |
| * mvo hugs pop'trailblazer'ey | 10:06 | |
| pedronis | Chipaca: yes, but we atomically do that for each snap | 10:06 |
| pedronis | or at least that's the intention | 10:06 |
| pedronis | needs bit of digging | 10:07 |
| pedronis | Chipaca: anyway in one of the plans we would do all of this upfront | 10:07 |
| Chipaca | pedronis: I can show you where we're not checking for dupes, if you want | 10:08 |
| Chipaca | maybe I should check for dupes at both places, for extra extraness | 10:08 |
| pedronis | Chipaca: but the dupes are indirect | 10:08 |
| pedronis | in this case no? | 10:08 |
| pedronis | so I'm not sure how there can be a place | 10:08 |
| pedronis | (afair current code) | 10:09 |
| Chipaca | pedronis: snapstate's defaultContentPlugProviders already gets the duplicated names | 10:09 |
| pedronis | ? | 10:09 |
| pedronis | from which snap | 10:09 |
| pedronis | so it's silly bug? not a deep bug? | 10:09 |
| Chipaca | I forget but give me a moment to undo my fix and di can tell you | 10:09 |
| Chipaca | pedronis: it seems to be, yes | 10:10 |
| pedronis | ok | 10:10 |
| pedronis | I see we were assuming that a snap will not repeat the default provider | 10:10 |
| pedronis | but they do | 10:10 |
| mvo | *cough* thats a silly bug indeed. thanks pedronis and Chipaca | 10:10 |
| Chipaca | pedronis: for gnome-system-monitor, defaultContentPlugProviders returns: gtk-common-themes, gtk-common-themes, gtk-common-themes, gnome-3-26-1604 | 10:12 |
| pedronis | wonderful | 10:12 |
| pedronis | seems 2.34 material even | 10:12 |
| Chipaca | pedronis: for gnome-calculator, gtk-common-themes, gtk-common-themes, gnome-3-26-1604, gtk-common-themes | 10:12 |
| pedronis | if that is still possible | 10:12 |
| Chipaca | it's surprising that it works some of the time :-) | 10:12 |
| Chipaca | I'll fix defaultContentPlugProviders to not return dupes, and leave the slightly hairy code in handlers alone | 10:13 |
| mvo | pedronis: yes, looks like we need a .1 anyway | 10:13 |
| Chipaca | it'll fix this issue and not make things harder for us | 10:13 |
| pedronis | Chipaca: thx | 10:14 |
| * Chipaca looks for the unit tests of defautContentPlugProviders, and fails | 10:14 | |
| ogra_ | jdstrand, i'd appreciate a manual apoproval at https://dashboard.snapcraft.io/snaps/xdmcp-client/revisions/1/ (uses the new mir-kiosk snap with a loopback x11 plug for Xwayland, source is at https://github.com/ogra1/xdmcp-client/ ) | 10:20 |
| popey | oooh | 10:20 |
| ogra_ | i plan to extend that with a few other clients and turn it into a thin-client appliance ;) (vnc, rdp ... ) | 10:21 |
| popey | great idea. | 10:21 |
| popey | I had no success getting an app working with mir-kiosk, so will look at yours for inspiration | 10:22 |
| ogra_ | it sadly needs layouts to make Xephyr happy (hardcodes paths to binaries in the code) ... for normal apps it shoudl be a lot easier though | 10:23 |
| pstolowski | i keep getting cannot allocate new Google server for ubuntu-18.04-64: quota 'CPUS' exceeded. Limit: 600.0 in region us-east1 from travis | 10:26 |
| mvo | pstolowski: I saw this as well and asked zyga to ask Gustavo about it. Hopefully he or cachio can help | 10:28 |
| pstolowski | mvo: ack, thanks | 10:28 |
| ppisati | ogra_: i'm debugging the snapcraft.yaml build issue for xenial and bionic, feel free to drop it if you have anything else | 10:30 |
| ogra_ | ppisati, https://forum.snapcraft.io/t/linux-4-15-0-snaps/6401/5 | 10:31 |
| ogra_ | ppisati, and there seems to be an issue with "no such target "firmware_install" at the end of the build | 10:32 |
| ppisati | ogra_: yep, i have patch similar to that | 10:32 |
| ogra_ | right, then only the missing firmware_install target is left .... | 10:33 |
| ppisati | ogra_: 3794440b47ceada080b365e281b76313c7a2e255 | 10:33 |
| ogra_ | grepping the whole tree the only mention of firmware_instakk is in debian/scripts which i thought wouldnt be run ... | 10:33 |
| ogra_ | *firmware_install | 10:33 |
| boxrick | Hello, I added some values to the environment of my machine ( proxy ) and need the snapd service to reload those, is this possible without a full restart of the service? | 10:43 |
| boxrick | And second if I wish to pin a package version, is that doable? | 10:43 |
| boxrick | IE disable auto refresh | 10:43 |
| Chipaca | boxrick: there are several knobs you can use to change when a refresh happens, but you can't disable it from the device, no | 10:46 |
| Chipaca | mvo, pedronis, #5522 is the fix | 10:46 |
| mup | PR #5522: overlord/snapstate: dedupe default content providers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5522> | 10:46 |
| Chipaca | feel free to tag it and target it appropriately | 10:46 |
| Chipaca | boxrick: what're you wanting to stop refreshing, and why? | 10:47 |
| boxrick | Since if and when it breaks, I want it to be in a controlled fashion. Or perhaps a checked upgrade in my dev environment before I roll it out in the real world. | 10:49 |
| boxrick | Similar reasons I pin to software versions in config management | 10:50 |
| boxrick | If I have a working environment, I need that to remain consistent. | 10:50 |
| Chipaca | boxrick: as far as I know you get that level of control when you use a branded store | 10:52 |
| Chipaca | boxrick: if this is for a device, you can also do revision pinning (but i'm not sure that isn't also tied to a branded store) | 10:53 |
| ogra_ | i think it is | 10:53 |
| ogra_ | (you actually pin it in the store ... ) | 10:54 |
| Chipaca | ogra_: k | 10:54 |
| ogra_ | (AFAIK at least ... :) ) | 10:54 |
| Chipaca | boxrick: depending on the snap, in some cases it'll be appropriate to let production track stable and have a canary tracking candidate | 10:55 |
| boxrick | Any of example of how I can pin a version? | 10:55 |
| Chipaca | or I could just be talking to a wall | 10:56 |
| * Chipaca wanders off | 10:56 | |
| boxrick | Perhaps I have missed your point I apologise. | 10:58 |
| boxrick | Well kind of unrelated, reloading enviroment. Any tips without a full snapdrestart? | 10:59 |
| boxrick | Or some way of printing out the current environment that it has loaded up. | 11:02 |
| ogra_ | boxrick, i'd just try "systemctl reload snapd" ... technically that should reload the units config, parctically no idea if snapd picks it up though | 11:05 |
| ogra_ | *practically | 11:05 |
| boxrick | Sadly not, seems I will have to poke the systemd service to find the PID then check the environment of that PID | 11:11 |
| Chipaca | boxrick: how did you set the environment? | 11:12 |
| boxrick | Just setting /etc/environment | 11:12 |
| boxrick | ( Proxy settings in this case ) | 11:13 |
| boxrick | Which I then need snapd to read | 11:13 |
| boxrick | And just restarting it every time is super ugly. | 11:13 |
| Chipaca | boxrick: 'every time'? | 11:13 |
| Chipaca | boxrick: (not sure why it's super ugly, but you can't change the environment of another process; not easily at least) | 11:14 |
| boxrick | Well for example, I am deploying this with config management | 11:14 |
| boxrick | So as part of a task it needs to make sure the environment is installed and snapd is running with it for example | 11:15 |
| ogra_ | well, systemctl reload should send a kill -HUP to the daemon ... and i would expect it to also process the .service file ... if snapd respects the -HUP it should then pick up the new env | 11:15 |
| boxrick | Reload just bombs out with unsupported which is ashame | 11:16 |
| boxrick | Not to worry anyway, I have a workaround. Its just a little long winded | 11:16 |
| Chipaca | ogra_: systemctl reload does not work like that | 11:16 |
| ogra_ | oh ? | 11:16 |
| niemeyer | Heya | 11:17 |
| niemeyer | mvo: Any good hints about why the systems were hanging? | 11:17 |
| Chipaca | ogra_: systemctl reload needs the service to have an ExecReload line | 11:17 |
| niemeyer | I'm gcing just now | 11:17 |
| ogra_ | ah | 11:17 |
| ogra_ | so it isnt sysv-init ... who'd have thought that ! :) | 11:17 |
| Chipaca | ogra_: and, on the other hand, sending a HUP does not cause an environment re-read :-) | 11:17 |
| ogra_ | depends on the daemon ... i have seen some do it | 11:18 |
| r3r57 | Hello, after I restart my computer I regularly get the following error when running some snap applications: 'cannot change profile for the next exec call: No such file or directory \n snap-update-ns failed with code 1: No such file or directory'. I don't know whether it's a distribution specific issue or not and I'm not able to fix it myself. Does anyone have a clue what might be the problem here? Thank you in advance. | 11:27 |
| popey | r3r57: what's the output of "snap version" please? | 11:28 |
| r3r57 | popey, 'snap 2.32.9 snapd 2.32.9 series 16 solus 3.9999 kernel 4.17.3-81.current' | 11:28 |
| popey | ahh, i think zyga mentioned this problem recently. I believe there is a workaround. | 11:29 |
| Son_Goku | niemeyer, zyga, mvo: woohoo! https://pagure.io/flock/issue/87 | 11:29 |
| Son_Goku | note the tag on the right ;) | 11:29 |
| popey | yay | 11:29 |
| zyga | Hey r3r57 | 11:30 |
| zyga | There is a workaround but ikey needs to fix solid | 11:31 |
| zyga | Solus | 11:31 |
| zyga | Hey Son_Goku | 11:31 |
| Son_Goku | zyga, I just sent the confirmation email to bexelbie for our talk | 11:31 |
| zyga | That looks very good | 11:32 |
| r3r57 | zyga, okay thank you, did you mind tell me the workaround or should I ask in #solus? | 11:33 |
| Son_Goku | this is good news to wake up to after having to stay up late last night for an OpenStack server migration last night :) | 11:33 |
| zyga | r3r57: no, Just harder to type from my phone | 11:35 |
| zyga | Do this please | 11:35 |
| zyga | sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/* | 11:36 |
| r3r57 | magic | 11:37 |
| r3r57 | zyga, popey, thanks for your help, everything is working again. | 11:38 |
| r3r57 | and good luck with your talk ;) | 11:38 |
| popey | Excellent, thanks zyga | 11:38 |
| pedronis | Chipaca: I updated the wiki https://github.com/snapcore/snapd/wiki/REST-API/_compare/2b0fc8772a1ac9cb57585f32e24ebd9a169fe940...acf58ecbbb071c4be741431ac648f9c5f0b63202 if you could double check | 11:38 |
| pstolowski | mvo: hey, a question to https://github.com/snapcore/snapd/pull/5456 | 11:47 |
| mup | PR #5456: snapstate: refuse to remove bases or core if snaps need them <Created by mvo5> <https://github.com/snapcore/snapd/pull/5456> | 11:47 |
| === pstolowski is now known as pstolowski|lunch | ||
| zyga | mvo: there? | 11:57 |
| zyga | mvo: please fetch my remote | 11:57 |
| zyga | mvo: and see if 47665f978a1d94ed44b3943a1d33f0e39be96459 makes any difference | 11:57 |
| kenvandine | can anyone help me understand why /proc/mounts is significantly different from inside a snap that from the host? | 12:22 |
| kenvandine | /dev/loop30 /snap/spotify/13 squashfs ro,nodev,relatime 0 0 | 12:22 |
| kenvandine | on the host | 12:22 |
| kenvandine | and | 12:22 |
| Chipaca | kenvandine: because snaps have their own private mount namespace | 12:22 |
| kenvandine | /dev/loop30 /var/lib/snapd/hostfs/snap/spotify/13 squashfs ro,nodev,relatime 0 0 | 12:22 |
| kenvandine | in the snap | 12:22 |
| kenvandine | we're trying to figure out how to filter out the noise in the gnome-system-monitor snap | 12:23 |
| kenvandine | andyrock, ^^ | 12:23 |
| Chipaca | ah. Maybe zyga has insight into that. | 12:24 |
| andyrock | I guess what happens to all the udev (and afterall udev-udisks2 rules) | 12:25 |
| ogra_ | i thought that was long fixed | 12:28 |
| ogra_ | oh ... "in the snap" ... sorry, missed that | 12:29 |
| kenvandine | ogra_, yeah... looks terrible in the gnome-system-monitor snap, which is seeded | 12:30 |
| kenvandine | ogra_, andyrock had patched libgtop2 to filter it out, but it filters based on what the host sees not the snap | 12:31 |
| ogra_ | right ... but that was fixed through a udev rule ... which likely doesnt apply from inside the sanp | 12:31 |
| ogra_ | yep, i remember discussiong it with him back then | 12:31 |
| ogra_ | did you try to ship said libgtop version in your snap ? | 12:32 |
| kenvandine | yes | 12:32 |
| ogra_ | dang | 12:32 |
| kenvandine | but it filters with a mnt of /snap | 12:32 |
| kenvandine | there are other things showing up inside the snap as well, that don't on the host | 12:32 |
| kenvandine | like /etc/alternatives | 12:32 |
| kenvandine | and others | 12:33 |
| ogra_ | well, so filter with the hostfs prefix too | 12:33 |
| ogra_ | /var/lib/snapd/hostfs/snap is effectively /snap | 12:33 |
| kenvandine | yeah | 12:33 |
| kenvandine | but that would still leave noise | 12:33 |
| ogra_ | so you could just extend the filter | 12:33 |
| kenvandine | /dev/loop55 /var/lib/urandom squashfs ro,nodev,relatime 0 0 | 12:34 |
| kenvandine | for example | 12:34 |
| kenvandine | the mount points are all over the place | 12:34 |
| kenvandine | maybe we should ignore all loop | 12:34 |
| kenvandine | not sure those are useful for gnome-system-monitor | 12:34 |
| ogra_ | but that would break something like mounted isos | 12:34 |
| ogra_ | (in case you want to allow people seeing them) | 12:34 |
| pedronis | pstolowski|lunch: I merged the conflict streamling branch, as expected there are conflicts with disconnect-hooks | 12:35 |
| kenvandine | not sure those are interesting | 12:35 |
| ogra_ | probably a combo of loop and squashfs | 12:35 |
| kenvandine | andyrock, what do you think? | 12:35 |
| andyrock | kenvandine: I say that to filter snaps we need to extend the filter | 12:37 |
| andyrock | let me check for the others | 12:37 |
| ogra_ | it will get really bad if you start having layouts too ... | 12:37 |
| kenvandine | maybe we can filter all squashfs | 12:38 |
| andyrock | kenvandine: btw the proposed upstream fix it this: https://gitlab.gnome.org/GNOME/libgtop/merge_requests/2 | 12:38 |
| kenvandine | the real use case for gnome-system-monitor is to see how much snap you have left | 12:39 |
| kenvandine | s/snap/space :) | 12:39 |
| === pstolowski|lunch is now known as pstolowski | ||
| pstolowski | pedronis: right. thanks | 12:39 |
| zyga | kenvandine: because a snap runs with pivot root and many things in the mount namespace are different | 12:44 |
| zyga | You will also find that the x- mount options are stored in a file in user space | 12:45 |
| ogra_ | i'm not so sure "nodev" is good filter ... tht just tells that char and block devices *inside* the filesystem should be ignored | 12:45 |
| zyga | And that file is off when looked at from inside a snap | 12:45 |
| ogra_ | you will also have it by default on nfs mounts or samba shares .. | 12:45 |
| zyga | So libmount will not return those flags | 12:45 |
| ogra_ | (and i think udisks also sets it by default for everything it automounts under /media ... ) | 12:46 |
| Chipaca | pedronis: https://pastebin.ubuntu.com/p/YfPFpgQdDw/ | 12:46 |
| Chipaca | or maybe mvo | 12:46 |
| Chipaca | dunno | 12:46 |
| Chipaca | :-) just rfc as to whether that is too informal | 12:46 |
| Chipaca | and, i need to go get the boys | 12:47 |
| Chipaca | ttfn | 12:47 |
| ogra_ | tma ! | 12:47 |
| ogra_ | (too many acronyms) | 12:48 |
| kenvandine | :) | 12:48 |
| mvo | Chipaca: nice | 12:49 |
| mvo | Chipaca: ttfn | 12:49 |
| mvo | zyga: running | 12:50 |
| zyga | thanks | 12:50 |
| mvo | zyga: running your python code | 12:50 |
| zyga | note that the patch includes support for sd_notify use inside the service | 12:51 |
| zyga | but it should be fully optional | 12:51 |
| mvo | zyga: ok | 12:51 |
| andyrock | zyga: is /proc/filesystems visible inside a snap? | 12:54 |
| zyga | yes | 12:54 |
| zyga | though confinement may block it | 12:54 |
| zyga | so it's there (/proc, /sys and /dev are) | 12:54 |
| zyga | but apparmor and device cgroups prevents access to arbitrary parts of it | 12:55 |
| thresh | so uh | 12:55 |
| thresh | how do I go about moving the publisher rights for the snap to a different account? | 12:55 |
| thresh | as opposed to granting another account publisher rights | 12:56 |
| thresh | we (VLC) originally used our supreme leader's account to publish it, and then he granted me publish rights | 12:56 |
| timothy | hi, I have a problem to generate any snap: | 12:57 |
| timothy | Err http://security.ubuntu.com/ubuntu bionic-security/main DEP-11 64x64 Icons | 12:57 |
| ogra_ | thresh, i think you need to file a post under the store category in the forum | 12:57 |
| timothy | Hash Sum mismatch | 12:57 |
| ogra_ | thresh, there should be a documented way (also in the forum) | 12:57 |
| thresh | thanks ogra_ | 12:58 |
| ogra_ | thresh, and while i have you here ... would it be possible to have an armhf build of vlc (i'm recently working on kiosk images for arm boards and having a vlc snap would be really helpful) | 12:58 |
| thresh | we don't have hardware for that | 12:59 |
| ogra_ | well, i'd be fine with just having it switched on in build.snapcraft.io ... or do you use your own buuld infra ? | 13:00 |
| thresh | yes, we build the snaps on our infra | 13:00 |
| ogra_ | ah, k | 13:00 |
| popey | or launchpad could mirror it | 13:00 |
| popey | and build _only_ the armhf build | 13:00 |
| ogra_ | yeah | 13:00 |
| thresh | also I've just checked and kde neon repos (which we use to get newer Qt) dont have armv7/aarch64 packages | 13:01 |
| ogra_ | ah, ouch | 13:01 |
| mvo | cachio: welcome back! | 13:01 |
| thresh | *maybe* when we switch to 1804 core... | 13:01 |
| zyga | core18 | 13:02 |
| zyga | cachio: hey :) | 13:02 |
| thresh | right | 13:05 |
| thresh | I would very much like not to depend on anything external to ubuntu repos, but that's impossible at the moment | 13:05 |
| Chipaca | mvo: 5522 merged, was a single commit | 13:20 |
| Chipaca | ogra_: dunno if your tma was on purpose or not, but TTFN started at ITMA :-) | 13:26 |
| andyrock | zyga: would be possible to get /run/mount/utab visible inside a snap? | 13:27 |
| andyrock | in this way we could mount all the squashfs with a x- user option | 13:28 |
| andyrock | and the snap can read /run/mount/utab in order to filter out some squashfs | 13:28 |
| mvo | Chipaca: thanks, I will cherry-pick it | 13:31 |
| mvo | Chipaca: cherry-picked and pushed, thanks again | 13:32 |
| zyga | andyrock: yes but note that it would be not showing the content you expect | 13:32 |
| zyga | andyrock: we can meet and discuss this but it's not a trivial problem | 13:33 |
| zyga | let me show you some notes | 13:33 |
| zyga | https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987/5 | 13:33 |
| === abeato_ is now known as abeato | ||
| cachio | mvo, these are some results for 2.34 https://paste.ubuntu.com/p/Rmxw9t2NF6/ | 13:44 |
| zyga | mvo: hey, can you add to 2.34.1 a patch that fixes CUDA | 13:47 |
| zyga | ah, please ignore me, they are out | 13:48 |
| mvo | cachio: looking, thank you | 13:53 |
| cachio | mvo, oood, I am checking 32 bits right now | 13:53 |
| andyrock | zyga: regarding the private utab file proposed here https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987/5, would it show all the squashfs e.g. (/etc/ssl, /var/lib/sudo, etc.) ? | 14:10 |
| zyga | andyrock: we really don't know | 14:11 |
| zyga | I'd rather not do that | 14:11 |
| zyga | because we have no sane way of keeping that file correct now | 14:11 |
| pstolowski | https://github.com/snapcore/snapd/pull/5433 needs 2nd review and is simple | 14:30 |
| mup | PR #5433: interfaces/repo: added AllHotplugInterfaces helper <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5433> | 14:30 |
| zyga | pedronis: thank you for the review of the remapper | 15:39 |
| zyga | I will address the comments | 15:39 |
| zyga | I'm super excited to see this land | 15:39 |
| pedronis | zyga: I think mvo is workong on it as well | 15:40 |
| zyga | yes, we just talked about it, mvo needs to work on release bits for a sec | 15:40 |
| zyga | and I have a moment before the next session | 15:40 |
| mvo | pedronis: just looking at 2.34 test failures, annoying :/ | 15:42 |
| zyga | gustavo just mentioned | 15:42 |
| pedronis | ah | 15:42 |
| zyga | we have 17 days for core18 | 15:42 |
| zyga | so ... | 15:42 |
| zyga | I pushed an update to the remapping branch | 15:49 |
| zyga | just one comment left | 15:49 |
| mvo | zyga: ta | 15:49 |
| zyga | we need to use the configstate.RemapToResponse in a few places | 15:50 |
| zyga | adding those now | 15:50 |
| mvo | cachio: looking at your failure list now, I think - external:ubuntu-core-16-64:tests/main/snap-interface and - external:ubuntu-core-16-64:tests/regression/lp-1721518 should be fixed with pr 5525 | 15:55 |
| zyga | and pushed now | 15:55 |
| mup | PR #5525: tests: cherry-pick test fixes from master for 2.34 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5525> | 15:55 |
| zyga | mvo: it's ready | 15:55 |
| zyga | I'll resume signal work | 15:56 |
| mvo | zyga: yay, I will check in 5min or so, just going over some more failures | 15:56 |
| mvo | zyga: thanks for that! | 15:56 |
| zyga | sure :) | 15:56 |
| cachio | mvo, yes | 15:57 |
| cachio | mvo, thanks for this | 15:58 |
| cachio | I'll take a look after lunch | 15:58 |
| mvo | cachio: maybe also the catalog-refresh, just pushed a cherry-pick | 15:58 |
| mvo | cachio: I think the prepare-image-uboot one is just a slow network, so hopefully (if 5525 passes) we will be green | 15:59 |
| mvo | again :) | 15:59 |
| cachio | mvo, yes | 16:00 |
| zyga | mvo: DOH | 16:00 |
| zyga | I'm such a moron :) | 16:00 |
| zyga | mvo: I know why the python version fails | 16:00 |
| zyga | because it doesn't have the file trigger | 16:00 |
| cachio | prepare-image-uboot used to faile because of network slowness | 16:00 |
| mvo | zyga: oh, of course, racy | 16:03 |
| mvo | cachio: yeah, cool | 16:03 |
| zyga | so I'll propose a python version | 16:03 |
| mvo | cachio: almost done then I think | 16:03 |
| zyga | with the file "notification" | 16:03 |
| mvo | zyga: thank you | 16:03 |
| zyga | and that should be good | 16:03 |
| cachio | mvo, yes, for 32 bits we have the same issues, so it should be fixed for free | 16:04 |
| zyga | mvo: do you want me to propose that fix in a separate PR or roll it into PR 5410 | 16:09 |
| mup | PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410> | 16:09 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | zyga: it sounds like a separate is ok | 16:12 |
| zyga | doing that now | 16:12 |
| pedronis | zyga: mvo: 5491 still needs a 2nd review | 16:14 |
| zyga | mvo: pushed https://github.com/snapcore/snapd/pull/5526 | 16:20 |
| mup | PR #5526: tests: fix raciness in stop mode tests <Created by zyga> <https://github.com/snapcore/snapd/pull/5526> | 16:20 |
| zyga | pedronis: ack | 16:20 |
| zyga | mvo: I updated 5410 with explanation about the raciness | 16:21 |
| zyga | we have lunch now so I'll check back later | 16:21 |
| mvo | zyga: ta | 16:26 |
| razer2 | The snap for Spotify does not run on Debian. | 16:44 |
| cachio | niemeyer, https://forum.snapcraft.io/t/how-to-deploy-spread-gce-gleaner/6422 | 16:54 |
| cachio | please ping me in case something else is needed | 16:54 |
| mvo | 5525 needs a review, all cherry-picks so should be trivial | 17:06 |
| mvo | (cherry-picks to 2.34) | 17:07 |
| pedronis | 5527 needs to be tagged core18 ? | 17:56 |
| mvo | cachio: new 2.34.1 beta will be ready soon (next 1h) | 17:56 |
| mvo | pedronis: yes | 17:56 |
| pedronis | mvo: did you backport 5522 ? | 17:57 |
| mvo | pedronis: yes, cherry-picked it directly | 17:59 |
| pedronis | I see it now | 18:01 |
| pedronis | sorry | 18:01 |
| zyga | can someone please review https://github.com/snapcore/snapd/pull/5521 | 18:09 |
| mup | PR #5521: snap-confine: mount internal tooling even for the core snap on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5521> | 18:09 |
| zyga | mvo: are you wrapping up for today? | 18:16 |
| zyga | MATCH failed again | 18:26 |
| zyga | man | 18:26 |
| cwayne | mvo: and this beta will have that canbus interface PR? | 18:27 |
| zyga | cwayne: yes | 18:27 |
| zyga | it does | 18:27 |
| cwayne | yay :) | 18:27 |
| cwayne | jhodapp: ^ | 18:28 |
| mvo | zyga: not yet | 18:42 |
| mvo | cwayne: yes | 18:43 |
| mvo | cwayne, cachio new beta should be ready in ~30min or so | 18:45 |
| cachio | mvo, waiting ifor this to validate it | 18:46 |
| niemeyer | cachio: Thanks! | 18:46 |
| cwayne | mvo: will keep an eye out, thanks | 18:48 |
| cachio | niemeyer, yaw | 18:48 |
| mvo | thanks guys | 18:54 |
| === JanC_ is now known as JanC | ||
| mvo | cachio, cwayne 2.34.1 ready in beta | 19:08 |
| cachio | mvo, already downloading inmages | 19:08 |
| cwayne | mvo: already testing :) | 19:09 |
| mvo | cwayne: \o/ | 19:11 |
| * cachio afk | 19:18 | |
| jhodapp | cwayne, woohoo! | 19:22 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
