| mup | PR snapd#8903 opened: tests: new core config helper <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8903> | 03:25 |
|---|---|---|
| mborzecki | morning | 05:13 |
| === JanC_ is now known as JanC | ||
| mborzecki | mvo: hey | 05:51 |
| mborzecki | quick errand, brb | 05:53 |
| mvo | mborzecki: good morning | 05:54 |
| zyga | Good morning | 06:32 |
| zyga | I will start at 9 | 06:32 |
| zyga | Good to see you mvo! | 06:32 |
| mvo | zyga: good morning. even better to see you :) | 06:33 |
| mvo | zyga: hope you are well (enough)! | 06:33 |
| mborzecki | re | 06:39 |
| mborzecki | zyga: hey | 06:39 |
| zyga | I’m going to be soon. Just had my morning painkillers | 06:40 |
| zyga | But even without them I think there is an improvement | 06:40 |
| mborzecki | zyga: something is off in centos 8 with the change from #8901 | 06:40 |
| mup | PR #8901: tests/lib/tools: apply linger workaround when needed <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901> | 06:40 |
| mvo | zyga: nice! | 06:40 |
| zyga | mborzecki: I’ll look in 20 minutes | 06:41 |
| mborzecki | zyga: thanks | 06:45 |
| mup | PR snapd#8904 opened: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8904> | 06:56 |
| zyga | re | 07:02 |
| zyga | in makeshift floor office | 07:02 |
| zyga | I'm on bug shift today | 07:02 |
| pstolowski | morning | 07:06 |
| mborzecki | pstolowski: heya | 07:07 |
| * zyga looks at the PRs | 07:11 | |
| mborzecki | funny when syncing homes with a loptop through unison it takes significantly longer because of a bunch of 1gb files in snapd source tree that were left behind after i last played with uc20 imare prepare code for the spread tests | 07:12 |
| zyga | mborzecki: can you push the syntax fixes to https://github.com/snapcore/snapd/pull/8901/files please | 07:12 |
| mup | PR #8901: tests/lib/tools: apply linger workaround when needed <Precious Logs> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8901> | 07:12 |
| zyga | heh | 07:12 |
| zyga | :) | 07:13 |
| mborzecki | haha | 07:13 |
| mborzecki | ok | 07:13 |
| zyga | commented in the RP | 07:13 |
| zyga | PR | 07:13 |
| mborzecki | zyga: ah, w8, the code that retries linger is further down | 07:14 |
| zyga | where? | 07:14 |
| zyga | I don't see any | 07:15 |
| mborzecki | zyga: line 161/169 | 07:15 |
| zyga | hmm | 07:15 |
| mborzecki | zyga: w8, 143/151 | 07:15 |
| zyga | ah I understand now | 07:16 |
| mborzecki | zyga: enabling twice should be harmless, right? it jus drops a file under /var/lib/ssytemd/linger | 07:17 |
| zyga | IIRC it does more than that | 07:17 |
| zyga | but it enabling twice should be harmless if it works right | 07:17 |
| zyga | I wonder what happens if we try and fail | 07:17 |
| zyga | fix the system | 07:17 |
| zyga | and try again | 07:17 |
| zyga | enabling linger does start all the user services | 07:18 |
| mborzecki | zyga: maybe we should disable/stop user@<uid>.service? | 07:18 |
| mborzecki | zyga: in the branch when enable fails | 07:18 |
| zyga | not sure, we'd have to look at logind to see what it does and where the current failure is placed in the sequence of calls | 07:18 |
| mup | PR snapd#8898 closed: snapdtool: helper to check whether the current binary is reexeced from a snap <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8898> | 07:31 |
| mup | PR snapd#8900 closed: tests: extra worker for google-nested backend to avoid timeout error on uc20 <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8900> | 07:31 |
| zyga | ok, my plan for today is to work some more on the udev mystery | 07:39 |
| zyga | and then do bug triage | 07:39 |
| zyga | and some iteration on branches | 07:39 |
| * mborzecki wonders how to split a 2k 'WIP' commit nicely into smaller patches | 07:47 | |
| Cruft | Why is there an autostart service running without snaps that require auto starting applications? | 08:01 |
| zyga | Cruft: the auto-start service runs once on session startup, in case there are things to do IIRC | 08:04 |
| Cruft | but through systemd and or X-gnome-autostart or whatever it is now "hidden" from freedesktop spec, wouldn't you not only be able to enable or disable the permission to do so individually but also know if that service should even run? | 08:06 |
| zyga | can you be more specific please, I'm not sure I understand what you meant | 08:07 |
| Cruft | its to help snapd make sure the snap program(s) that have autostart functionality are run on startup correct? | 08:08 |
| zyga | yes | 08:08 |
| Cruft | Wouldn't you already know upon installation and or boot that that was the case? | 08:08 |
| zyga | as those programs cannot use the normal method for starting | 08:08 |
| zyga | I'm sorry, know what? | 08:08 |
| zyga | that some programs auto-start? | 08:09 |
| Cruft | That they would otherwise autostart | 08:09 |
| Cruft | They are mounted on install right? | 08:09 |
| zyga | are you saying that the programs should notify the user somehow that they auto-start? | 08:09 |
| * zyga is confused as to what the exact problem is, sorry | 08:09 | |
| zyga | yes, they are mounted | 08:09 |
| Cruft | No. I'm saying that the auto start service should not be run unless an auto start application exists | 08:09 |
| zyga | I see what you mean now | 08:10 |
| zyga | it's much easier this way | 08:10 |
| Cruft | Also that in the event that auto start applications exist, that it can be explicitly turned off if not already possible, therefor not running after | 08:10 |
| zyga | we'd have to enable or disable this | 08:10 |
| zyga | are you saying that you'd like to control this per app? | 08:10 |
| Cruft | both | 08:11 |
| Cruft | but A makes B easier | 08:11 |
| zyga | I think they are unrelated, A is a service that you can disable per user or globally | 08:11 |
| Cruft | I can control microphone permissions but not autostart? Eh. | 08:11 |
| zyga | B is new (per user) state that needs UI and APIs to drive | 08:11 |
| zyga | autostart is not an interface | 08:12 |
| zyga | I see what you mean but it's not done this way technically | 08:12 |
| Cruft | Is it just using freedesktop conventions to determine this? | 08:12 |
| Cruft | Within the snap(s) | 08:13 |
| zyga | somewhat, but it's more complex to prevent confinement escape | 08:13 |
| mborzecki | Cruft: kind of, the app cannot drop a random file under $HOME/.config/autostart, iirc the service looks inside ~/snap/<name>/ instead | 08:13 |
| Cruft | right so its using the same xdg / .config i guess per user autostart as a determination within the snap tree? | 08:15 |
| zyga | yes | 08:15 |
| zyga | there's also some extra layer | 08:15 |
| zyga | that matches the desktop file | 08:15 |
| zyga | again, to prevent confinement esape | 08:15 |
| zyga | we cannot just use the desktop file that was created by the app | 08:15 |
| Cruft | I'm more thinking in terms of deciding to run at all | 08:15 |
| zyga | eventually there will be a portal | 08:16 |
| zyga | and the UI will be nice | 08:16 |
| zyga | this makes it work with existing programs | 08:16 |
| zyga | without new APIs | 08:16 |
| mborzecki | Cruft: maybe it's somthing to consider, but the whole selecting which app runs by tweaking gnome session is a pita since the old days | 08:17 |
| Cruft | You must understand though that people who have no autostart snaps are now having their boot further slowed by a service to autostart snaps | 08:17 |
| zyga | is it this slow? | 08:18 |
| Cruft | Its not fast, it was slower than alot when I measured. That is how I found the service. | 08:18 |
| Cruft | I have many snaps but none autostart | 08:19 |
| mborzecki | Cruft: hmm the sevice actually globs inside ~/snap/*/current/.config/autostart | 08:19 |
| zyga | Cruft: unfortunately there's no easy way to make it conditional | 08:19 |
| Cruft | right so you would know at install time | 08:19 |
| zyga | Cruft: as snapd does not mediate the act of opting into or out of autostart | 08:20 |
| Cruft | to run the service in userspace | 08:20 |
| zyga | no, we don't know at install time | 08:20 |
| zyga | we only look in that auto-start service | 08:21 |
| zyga | and if the file is there and matches something in the snap definition | 08:21 |
| zyga | we start the snap app | 08:21 |
| zyga | we don't have an event when a running app enables auto-start | 08:21 |
| Cruft | So you have no first mount etc hook | 08:23 |
| Cruft | for current or whatever | 08:23 |
| zyga | this is not related to mounting | 08:23 |
| zyga | I don't think you understand how this works | 08:23 |
| zyga | when a running app decides to enable auto-start | 08:23 |
| zyga | it drops a file into an xdg location | 08:23 |
| zyga | we only re-map $HOME so it's not the real location | 08:23 |
| zyga | that's all | 08:24 |
| zyga | when a session starts, the auto-start service scans the per-snap $HOME of each snap | 08:24 |
| zyga | and looks for the xdg auto-start information | 08:24 |
| zyga | and then acts on it | 08:24 |
| zyga | that's it | 08:24 |
| zyga | there's no more logic | 08:24 |
| Cruft | So rather than scanning post mount it scans every time you boot | 08:24 |
| zyga | it's not post mount because this is dynamic | 08:25 |
| zyga | and it's not every time you boot | 08:25 |
| zyga | it's in the user session | 08:25 |
| zyga | there's no way to statically say you want to auto start an app via xdg | 08:25 |
| Cruft | So then why isn't the service disabled if no new snaps have been installed | 08:25 |
| zyga | you must create a desktop file in a specific location in the home directory | 08:25 |
| zyga | because it's not something we considered important, when there's nothing to do it's doing nothing pretty quickly | 08:26 |
| zyga | and making it better is really hard | 08:26 |
| zyga | and again | 08:26 |
| zyga | you misunderstand how it works when you talk about installed snaps, you can have one snap and it can opt in and out of autostart | 08:26 |
| zyga | so it's not about that | 08:27 |
| mborzecki | Cruft: w8, maybe i'm confused, which service are we discussing here? /etc/xdg/autostart/snap-userd-autostart.desktop ? | 08:27 |
| Cruft | I believe that was the one | 08:27 |
| Cruft | Let me check | 08:27 |
| Cruft | yes | 08:28 |
| mborzecki | Cruft: ok, so this one starts when your graphics session is coming up, scans ~/snap/*/current/.config/autostart for relevant desktop files, starts any snaps that want autostat and exits, if there are no desktop files dropped by the snaps, then it exits | 08:30 |
| ogra | Cruft, if it would scan post mount (i.e. before even GDM starts) it would have to scan *all* users homes instead of the home of the specific user that just logged in ... that would surely be a lot slower than running at session start | 08:30 |
| ogra | snaps are mouned by systemd during boot ... way before you reach any session you could access | 08:31 |
| ogra | *mounted | 08:31 |
| Cruft | Oh believe me, I saw. | 08:31 |
| mborzecki | Cruft: so you're saying the autostart service is running still after your session is fully up, or does it run slow during startup? | 08:33 |
| Cruft | Both | 08:33 |
| Cruft | and that it shouldn't be in either case. | 08:33 |
| ogra | sounds like these are simply bugs ... | 08:33 |
| mborzecki | Cruft: can you do `ps -ef |grep userd` ? | 08:34 |
| Cruft | It could literally check during updates at the same time | 08:34 |
| * zyga is confused about updates | 08:34 | |
| Cruft | yes, there is a line with the pid, time, etc | 08:35 |
| mborzecki | Cruft: can you paste it? | 08:35 |
| Cruft | no, i'm not on that computer on this machine | 08:35 |
| Cruft | i can retype it i guess | 08:35 |
| mborzecki | Cruft: you can skip the pid, i'm interested in the command `snap userd ..` | 08:38 |
| * ogra could imagine that using a db instead of walking ~/snap/*/.config might speed up things quite a bit, but that would also mean completely moving away from freedesktop standards | 08:38 | |
| Cruft | you could shard them out in sqlite if you use that | 08:39 |
| Cruft | as they currently stand | 08:39 |
| zyga | none of that matters if apps don't use that | 08:40 |
| zyga | so we support what apps do | 08:40 |
| Cruft | I'm not sure what you're asking me to type mborzecki | 08:40 |
| mborzecki | Cruft: `ps -ef|grep userd`, there should be a command in the last column that starts with `snap userd..`, please paste/type that in the channel | 08:40 |
| ogra | he wants the most right entry of the ps output 🙂 | 08:40 |
| Cruft | snap userd | 08:41 |
| zyga | that's the other userd | 08:41 |
| zyga | not the auto-start thing | 08:41 |
| mborzecki | Cruft: that's the user session helper that exposes dbus api for snaps to request xdg-open, manage xdg-settings and some other thing i don't recall now, incoming requests are sanitized | 08:45 |
| ogra | ... and that specific one is rather unlikely to have any impact on session startup time ... | 08:46 |
| mborzecki | Cruft: so you're saying that one starts slow? | 08:46 |
| ogra | (as it starts async and nothing but snaps depend on it) | 08:46 |
| Cruft | Yes | 08:46 |
| Cruft | I can see that. I didn't realize this was go | 08:47 |
| Cruft | welp, looks like i need to Delve into it | 08:49 |
| mborzecki | Cruft: `snap userd` is actually started via dbus activation | 08:50 |
| mborzecki | Cruft: i don't think it shows up as a systemd --user service | 08:51 |
| Cruft | ah | 08:52 |
| Cruft | ok yeh I see the two dbus unconfined services for snapd userd | 08:55 |
| mborzecki | Cruft: yes, io.snapcraft.Settings and Launcher | 08:59 |
| === ricab__ is now known as ricab | ||
| zyga | mvo: o/ | 10:32 |
| zyga | mvo: 2.45 is not released, right? | 10:32 |
| zyga | I mean, I see it in groovy | 10:33 |
| zyga | but focal has 2.44 | 10:33 |
| mvo | zyga: I asked sil2100 to look at the 2.45.1 SRU, he said he will get to it today :) | 10:33 |
| mvo | zyga: but yeah, it's waiting in the unapproved queue | 10:33 |
| zyga | sure I just wanted to know | 10:34 |
| zyga | mvo: one more thing | 10:34 |
| zyga | mvo: the core snap is at 2.45 while snapd is at 2.45.1 | 10:34 |
| zyga | is that expected? | 10:35 |
| mvo | zyga: maybe because of phasing, let me double check | 10:35 |
| mvo | zyga: hm, that sounds like we need to ask cachio what is going on there | 10:35 |
| zyga | okay | 10:35 |
| zyga | thanks, I just wanted to understand where we are to update bugs that are fix commited | 10:36 |
| mup | Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374> | 10:37 |
| zyga | mvo: do you expect 2.45.1? I would like to update the launchpad milestones | 10:38 |
| zyga | oh. we have one :D | 10:39 |
| zyga | ok | 10:39 |
| mup | Bug #1878374 opened: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374> | 10:40 |
| mup | Bug #1878374 changed: UC20 stuck at installing system on specific Intel NVME stick <bot-comment> <uc20> <snapd:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1878374> | 10:43 |
| zyga | I updated all the milestones that were open | 10:45 |
| zyga | mvo: is the next release going to be 2.45.2 or 2.46? | 10:46 |
| zyga | brb | 10:50 |
| mvo | zyga: there will be a 2.45.2 most likely we have some requests for this | 10:50 |
| zyga | I see | 10:50 |
| === pedronis_ is now known as pedronis | ||
| mup | PR snapd#8905 opened: bootloader: introduce managed bootloader, implement for grub <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8905> | 10:52 |
| mborzecki | pedronis: trivial piece ^^ | 10:52 |
| pedronis | mborzecki: thanks, will try to look at it soon | 10:53 |
| mvo | degville: silly question, what should I use to add comments to a discourse page, i.e. something like "// XXX: needs update for the new fields" or similar? | 10:57 |
| degville | mvo: html comments work | 11:01 |
| degville | ie. <!-- comment --> | 11:01 |
| mvo | degville: is that what is what we use elsewhere too? if so, I will use it | 11:02 |
| mvo | degville: is the preview confused? in the preview the comment is displayed as is | 11:03 |
| degville | mvo: well, we use it on the docs pages because the html comments aren't visible in the final output. For general Discourse comments, though, it doesn't really matter - I don't think syntax highlighting works. | 11:03 |
| degville | mvo: it shouldn't be visible in the preview? | 11:04 |
| mvo | degville: hm, maybe I do something wrong, let me try again | 11:05 |
| degville | mvo: At least, I've just tried it and it's hidden for me. | 11:05 |
| mvo | degville: yeah, silly me, works | 11:06 |
| mvo | degville: thank you | 11:06 |
| degville | it's not very pretty. | 11:06 |
| mup | PR snapd#8906 opened: asserts: introduce SequenceMemberAfter in the asserts backstores <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8906> | 11:07 |
| mup | PR snapd#8907 opened: asserts: implement Database.FindSequence <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8907> | 11:07 |
| mup | PR snapcraft#3184 closed: build providers: check revision before switching <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3184> | 11:33 |
| zyga | mvo: is https://github.com/snapcore/snapd/pull/8436 something you wanted to cherry pick into 2.45.2? | 11:38 |
| mup | PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8436> | 11:38 |
| zyga | I'm asking if I should target the bug report accordingly | 11:39 |
| zyga | I set the bug to target 2.46, if you want it in 2.45.2 just ping me and I'll adjust things | 11:41 |
| mvo | zyga: iirc it was not super urgent but I can double check | 11:41 |
| zyga | sure | 11:41 |
| zyga | 2.46 is fine | 11:41 |
| zyga | I'm only asking because it was squash merged | 11:41 |
| === alan_g_ is now known as alan_g | ||
| zyga | sil2100: are we using classic eth0 or the new "stable" names on core images? | 11:50 |
| zyga | sil2100: the context is a bug where pi4 has different behavior than prior images | 11:50 |
| pedronis | ijohnson: I re-reviewed #8683 | 12:16 |
| mup | PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683> | 12:16 |
| mup | PR snapd#8908 opened: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8908> | 12:17 |
| mborzecki | pedronis: ^^ | 12:17 |
| pedronis | mborzecki: reviewed | 12:36 |
| mborzecki | pedronis: thanks | 12:37 |
| zyga | pedronis: there's a request to extend the valid language for app commands to include the = sign, so that prog --opt=value would be allowed without wrappers | 12:40 |
| zyga | pedronis: currently the allowed app expression is: | 12:41 |
| zyga | var appContentWhitelist = regexp.MustCompile(`^[A-Za-z0-9/. _#:$-]*$`) | 12:41 |
| pedronis | zyga: it's related to snapcraft dropping wrappers support for core20 | 12:41 |
| zyga | looking at this I think that adding = is probably okay | 12:41 |
| zyga | but I wanted to ask you for advice | 12:41 |
| zyga | indeed, it's mentioned in the bug report | 12:41 |
| pedronis | well, we need to think this through | 12:41 |
| zyga | sure, I've left it as whishlist | 12:42 |
| pedronis | zyga: feel free to assign to it to me | 12:42 |
| zyga | ok | 12:42 |
| pedronis | doesn't mean we'll get to it quickly, but it's blocked on me either way | 12:42 |
| zyga | sure | 12:44 |
| zyga | sil2100: do you know where to track bugs about raspberry pi kernel? | 12:44 |
| zyga | (on core) | 12:44 |
| ijohnson | Thanks pedronis | 12:49 |
| sil2100 | zyga: hm, I guess I'd have to check with the ethernet device names, can't say from the top of my head | 12:56 |
| zyga | sil2100: the bug claims that pi4 uses eth0 | 12:56 |
| zyga | sil2100: but earlier devices us en!@!#@!@#! | 12:56 |
| sil2100 | zyga: as for the pi kernel bugs, I guess they're handled as any others - so fill in a bug for linux-raspi on LP :) | 12:56 |
| mup | PR snapd#8909 opened: interfaces/apparmor: allow snap-specific /run/lock <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8909> | 12:57 |
| zyga | thanks, that's what I needed | 12:57 |
| zyga | sil2100: hmm, no such project | 12:58 |
| zyga | oh well | 12:58 |
| zyga | standup time | 12:58 |
| sil2100 | zyga: hah, it's not a project, it's a package: https://bugs.launchpad.net/ubuntu/+source/linux-raspi/ | 13:09 |
| ogra | zyga, linux-raspi for focal ... linux-raspi2 for anything before (see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1881623 that was triaged by juerg (our pi kernel maintainer) | 13:15 |
| mup | Bug #1881623: USB support missing in initrd makes booting core with writable on USB impossible <linux-raspi (Ubuntu):New> <linux-raspi2 (Ubuntu):Confirmed> <linux-raspi2 (Ubuntu Xenial):New> <linux-raspi2 (Ubuntu Bionic):New> <linux-raspi (Ubuntu Focal):New> <https://launchpad.net/bugs/1881623> | 13:15 |
| zyga | ogra: ah, a source package | 13:15 |
| zyga | ogra: got that, thanks! | 13:15 |
| ogra | yep | 13:15 |
| * zyga breaks for lunch | 13:38 | |
| mup | PR snapd#8904 closed: snapstate: use testutil.HostScaledTimeout() in snapstate tests <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8904> | 13:57 |
| zyga | re | 14:21 |
| mup | PR snapcraft#3179 closed: Maven plugin: improve error message when target libs are not found <bug> <Created by edumucelli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3179> | 14:44 |
| pstolowski | i managed to reproduce https://bugs.launchpad.net/snapd/+bug/1882957 with my spread test. funny thing is it happend after fleshing things out in the test and re-arranging some ops | 14:48 |
| mup | Bug #1882957: Snapd `internal error: connection "[slot] [plug]" not found in state` <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1882957> | 14:48 |
| cachio | mvo, hey | 14:58 |
| cachio | mvo, the snap ubuntu-clock-app isnot in the repo anymore, so the test for unity fails | 14:58 |
| cachio | do you know any other snap that could be used instead | 14:59 |
| cachio | ? | 14:59 |
| mup | PR snapd#8910 opened: usersession: support additional zoom URL schemes <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910> | 15:03 |
| mborzecki | hm gadget Update/Backup/Rollback could use a little refactor | 15:08 |
| mborzecki | anyways, errands, bbl | 15:10 |
| mvo | cachio: uh, a good question | 15:14 |
| * cachio lunch | 15:29 | |
| abeato | zyga, hey, I have seen a problem with layouts, in a qemu environment where I installed NM, it looks like the layout is not really happening, I cannot see the files inside the snap. If I look at the mount namesapce, I see:https://paste.ubuntu.com/p/sDCdbm9Jqz/ | 15:35 |
| zyga | hey! | 15:35 |
| abeato | hi :) | 15:35 |
| zyga | ah , //deleted | 15:35 |
| abeato | yeah... | 15:35 |
| zyga | I'm doing bug triage now, can you please show me some more context | 15:35 |
| abeato | I am installing on qemu, while running spread tests | 15:36 |
| abeato | I have a snap version with core18, and I install on top a core20 version of the snap | 15:36 |
| abeato | the first does not use layouts, the second does | 15:36 |
| abeato | if I reinstall the snap, things look good and there is no //deleted string | 15:37 |
| zyga | what are the layout definitions | 15:39 |
| zyga | actually, I think it's best if you report a bug | 15:39 |
| zyga | with all the details | 15:39 |
| zyga | I'll try to look at it in the evening | 15:39 |
| zyga | I have a few more bugs to go through today | 15:39 |
| abeato | zyga, sure will do - I wanted to double check if this was a known issue before | 15:40 |
| zyga | it may be known behavior | 15:40 |
| zyga | depending on the paths used | 15:41 |
| zyga | the //deleted thing is really interesting part of linux | 15:41 |
| zyga | I didn't know about it before I started working on snapd | 15:41 |
| abeato | seems like some timing problem, some times happens, some times it does not | 15:41 |
| zyga | abeato: I think it's not timing as snapd is freezing the world for mount changes | 15:43 |
| zyga | probably sequence | 15:43 |
| zyga | I'll gladly analyze it in detail and explain what's going on | 15:43 |
| ijohnson | cachio: for https://github.com/snapcore/snapd/pull/8902#issuecomment-648236050 how did you reproduce this ? | 15:49 |
| mup | PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902> | 15:49 |
| abeato | zyga, https://bugs.launchpad.net/snapd/+bug/1884806 | 15:52 |
| mup | Bug #1884806: layouts are not honored some times <snapd:New> <https://launchpad.net/bugs/1884806> | 15:52 |
| zyga | abeato: thank you! | 15:57 |
| === grumble is now known as rawr | ||
| abeato | np | 15:58 |
| zyga | abeato: btw, what is /usr/var? | 15:59 |
| abeato | zyga, a folder with some config files for NM | 16:00 |
| zyga | I mean, I don't have /usr/var on my classic system | 16:00 |
| zyga | it's a weird location | 16:00 |
| zyga | is that hardcoded in n-m? | 16:00 |
| abeato | zyga, it is the default in nm, unless you change it with config options - which we do in the deb | 16:01 |
| abeato | for the snap anyway we override it | 16:01 |
| zyga | I see | 16:01 |
| zyga | ok | 16:01 |
| zyga | I'll look more closely | 16:02 |
| zyga | can you do one quick test perhaps | 16:02 |
| abeato | sure | 16:02 |
| zyga | refresh the exact same revision twice | 16:02 |
| zyga | just install --local perhaps | 16:02 |
| zyga | and see if that has the same effect | 16:02 |
| abeato | hm I did not know that one | 16:02 |
| abeato | zyga, not sure what is that? 'snap install --local' does not exist | 16:03 |
| abeato | zyga, refreshing the same revision actually works | 16:03 |
| abeato | zyga, also disabling then enabling the snap | 16:04 |
| zyga | ah, sorry | 16:04 |
| zyga | not local | 16:04 |
| zyga | I meant --dangerous :) | 16:04 |
| zyga | and just install the .snap file | 16:04 |
| zyga | instaling the same snap file twice tests if layout system can re-construct a no-update update | 16:05 |
| abeato | zyga, yeah, that works | 16:07 |
| zyga | abeato: thanks for checking, that's useful to know | 16:07 |
| zyga | abeato: perhaps there's an issue with core18 -> core20 transition | 16:08 |
| zyga | I'll debug this | 16:08 |
| abeato | great | 16:08 |
| mup | PR snapd#8911 opened: asserts,seed: split handling of essential/not essential model snaps <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8911> | 16:13 |
| pedronis | ijohnson: this ^ tries to address some of your concerns about the seed code | 16:13 |
| ijohnson | thanks I will take a look | 16:14 |
| mvo | pedronis: I updated 8889 a bit | 16:31 |
| pedronis | mvo: thx, adding it back to my queue | 16:33 |
| mup | PR snapcraft#3185 opened: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185> | 16:44 |
| zyga | mvo: I'll take a break now, see you tomorrow | 16:59 |
| zyga | after Thursday typing won't be such a chore | 16:59 |
| cachio | ijohnson, sorry | 17:20 |
| cachio | spread -debug google-nested:ubuntu-16.04-64:/tests/nested/core/image-build | 17:20 |
| ijohnson | cachio: I am running `spread --debug -v google-nested:...:tests/nested/` now, and have not seen any failures yet | 17:20 |
| cachio | spread -debug google-nested:ubuntu-16.04-64:tests/nested/core/image-build | 17:20 |
| ijohnson | haha literally as I just sent that it failed on a tet | 17:21 |
| ijohnson | let me look | 17:21 |
| cachio | core-18 workerd perfect here | 17:21 |
| cachio | ijohnson, also failed with timeout uc20 | 17:22 |
| ijohnson | cachio: yes I just saw the uc20 failure here, I will investigate | 17:22 |
| ijohnson | actually I need to break for lunch, but will investigate more afterwards | 17:22 |
| cachio | ijohnson, something that I forgot SPREAD_USE_CLOUD_INIT=false | 17:22 |
| cachio | you need to use that to force the use of the assertion disk | 17:23 |
| cachio | otherwise by default it will use cloud_init | 17:23 |
| ijohnson | cachio: let's chat a bit later after I'm back from lunch | 17:23 |
| === ijohnson is now known as ijohnson|lunch | ||
| cachio | ijohnson|lunch, sure | 17:24 |
| cachio | mvo, should we run the unity test in nightly in case there is not any unity snap available? | 17:46 |
| ijohnson|lunch | cachio: I didn't reproduce that error with my current patchset, let me push it up before my next meeting | 17:52 |
| ijohnson|lunch | cachio: I will attach the log from my run in the PR | 17:52 |
| cachio | sure | 17:52 |
| === ijohnson|lunch is now known as ijohnson | ||
| cachio | I'll make another tun | 17:53 |
| cachio | run | 17:53 |
| ijohnson | cachio: please pull from the branch, but here's the output from my most recent run https://github.com/snapcore/snapd/pull/8902#issuecomment-648321737 | 17:55 |
| mup | PR #8902: tests: fix assertion disk handling for nested UC systems <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8902> | 17:55 |
| mvo | cachio: I think we can stop testing unity if we don't have any snaps. let's remove it | 17:55 |
| cachio | mvo, sure, thanks | 17:56 |
| mvo | yw | 17:56 |
| ijohnson | cachio: I didn't try with preparing all of these without cloud-init yet I just want to make sure that the PR is good when using cloud-init for the users, a followup will use the assertions disk | 17:56 |
| ijohnson | cachio: in other words the spread run I linked to in the PR comment doesn't have SPREAD_USE_CLOUD_INIT=false defined | 17:57 |
| ijohnson | cachio: so if you could test just normally that would be great to see | 17:57 |
| cachio | ijohnson, ok | 17:57 |
| ijohnson | thanks | 17:57 |
| cachio | let me try | 17:57 |
| ijohnson | I will look more after my meeting now | 17:57 |
| cachio | ijohnson, in core16 workerd with SPREAD_USE_CLOUD_INIT=false and without | 18:19 |
| cachio | so the fix works | 18:19 |
| cachio | let me check uc20 | 18:19 |
| ijohnson | cachio: yes let me look at why the uc20 ones failed | 18:34 |
| mup | PR snapcraft#3186 opened: Riscv64 support <Created by xnox> <https://github.com/snapcore/snapcraft/pull/3186> | 18:34 |
| ijohnson | cachio: for me, only tests/nested/core20/basic and 64:tests/nested/manual/core20-early-config failed | 18:34 |
| cachio | ijohnson, yes, this is something different | 18:36 |
| cachio | I need to take a look tomorrow to that one | 18:36 |
| cachio | ijohnson, so, on uc20 the user assertion creates the user but then I see https://paste.ubuntu.com/p/zgDk4hWFqb/ | 18:57 |
| cachio | error: too early for operation, device not yet seeded or device model not acknowledged | 18:57 |
| cachio | ijohnson, I am running again | 18:57 |
| ijohnson | cachio: ah interesting | 18:57 |
| ijohnson | cachio: I hit your bug with the /dev/mapper/loop2p1 issue, it's a race condition but I can fix it easily, I will push something up | 18:58 |
| roadmr | jdstrand: heads up, xnox is about to send your way a bug about making review-tools happy with a new architecture | 18:58 |
| cachio | perhaps we'll need to wait until seeding is copmleted, right? | 18:58 |
| ijohnson | cachio: perhaps | 18:59 |
| ijohnson | cachio: for uc20 probably yes, but the /dev/mapper issue is not related to seeding | 18:59 |
| ijohnson | (but I know how to fix it | 18:59 |
| ijohnson | ) | 18:59 |
| jdstrand | roadmr: that will be interesting to fix, as I likely will need core20 but focal has bugs in various places | 19:00 |
| roadmr | the fun | 19:00 |
| ijohnson | cachio: did you ever figure out the deal with uc20 nested VMs rebooting constantly ? | 19:14 |
| cachio | ijohnson, well, it used to reboot 1 once by using -smp 1 | 19:14 |
| ijohnson | cachio: in the log I'm looking at the nested VM got rebooted at least 10 times before the spread timeout got hit, looks like less than a minute after it booted it got rebooted | 19:15 |
| cachio | ijohnson, I saw different bug reports similar | 19:15 |
| cachio | but not sure the reason | 19:15 |
| cachio | ijohnson, reboots in install mode? | 19:16 |
| cachio | run mode? | 19:16 |
| ijohnson | cachio: in run mode | 19:16 |
| ijohnson | cachio: although actually maybe install mode too, don't remember | 19:16 |
| ijohnson | let me show you the log | 19:16 |
| cachio | it is the same I see | 19:16 |
| cachio | here in the last log | 19:16 |
| ijohnson | cachio: this is the serial boot log from the nested VM: https://pastebin.ubuntu.com/p/b9PHpFkFKm/ | 19:19 |
| ijohnson | yeah it was rebooted 6 times I guess, all the unintended reboots were in run mode | 19:20 |
| cachio | ijohnson, well this is not normal | 19:20 |
| cachio | at least should reboot 1 extra time | 19:20 |
| cachio | but not more | 19:20 |
| ijohnson | haha yeah I would agree it is not normal for a VM to get randomly rebooted 6 times at random points in the boot sequence | 19:21 |
| cachio | perhaps it is related to the usr assertion | 19:21 |
| cachio | hehehe | 19:21 |
| ijohnson | cachio: could be, this run was with SPREAD_USE_CLOUD_INIT=false just to see what happens with the assertions on all the systems | 19:22 |
| cachio | I triggered new executions with and without user assertion to see if that could be the reason | 19:22 |
| ijohnson | it eventually made it to a successful boot and is running normally now, but it did not import the assertion on uc20 | 19:22 |
| cachio | last run I did worked, it took 15 minutes to prepare the nested vm and connecto shrough ssh | 19:23 |
| ijohnson | cachio: it is very slow | 19:24 |
| cachio | ijohnson, yes | 19:24 |
| mup | PR snapcraft#3176 closed: tools: fix environment-setup to work on aarch64 <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3176> | 19:24 |
| cachio | perhaps there were some reboots | 19:24 |
| cachio | ijohnson, this is the last run https://paste.ubuntu.com/p/83MKxjngDv/ | 19:25 |
| ijohnson | cachio: I think as long as this branch is working with the default SPREAD_USE_CLOUD_INIT=true the way the tests run now, we should push forward with this branch and I can propose follow-ups to fix using assertions | 19:25 |
| cachio | ijohnson, sure | 19:25 |
| ijohnson | cachio: so it seems it is randomly failing with uc20 then | 19:25 |
| cachio | ijohnson, yes | 19:26 |
| cachio | this is related to some errors we have seen with kvm and gce | 19:26 |
| ijohnson | cachio: ok I just pushed up a fix for the loop device not available problem you saw, it should eliminate the race condition, I think we should probably merge this then and continue with a followup PR | 19:26 |
| cachio | if you run without kvm then never reboots | 19:26 |
| ijohnson | cachio: what do you think ? | 19:26 |
| cachio | ijohnson, it is ok | 19:27 |
| cachio | it is working pretty well now | 19:27 |
| cachio | just that problem but shouldn't affect the current nightly executions | 19:27 |
| ijohnson | cachio: what do you mean about not rebooting without kvm ? | 19:27 |
| ijohnson | cachio: you only see these random reboots with kvm enabled ? | 19:27 |
| cachio | we use qemu with kvm aceleration | 19:28 |
| ijohnson | i.e. -machine ubuntu-q35,accel=kvm ? | 19:28 |
| cachio | if I run without kvm acceleration those random reboots never happen | 19:28 |
| cachio | ijohnson, right | 19:28 |
| ijohnson | ah very interesting | 19:28 |
| cachio | the problem is that if we don't use kvm then the execution is very slow | 19:28 |
| ijohnson | right | 19:29 |
| cachio | and something interesting is that if we dont use ovmf the reboots don't happen | 19:29 |
| ijohnson | cachio: where did you report this bug again? I remember reading through your LP bug you filed but I don't remember where now | 19:30 |
| cachio | so it is a combination between could + ovmf + kvm | 19:30 |
| cachio | ijohnson, a time agou I created the bug in launchpad | 19:30 |
| cachio | in kvm project | 19:30 |
| ijohnson | do you have the link ? | 19:30 |
| cachio | ijohnson, let me check | 19:30 |
| cachio | ijohnson, https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1872803 | 19:33 |
| mup | Bug #1872803: VM reboots using qemu and kvm with ovmf <qemu (Ubuntu):Expired> <https://launchpad.net/bugs/1872803> | 19:33 |
| cachio | ijohnson, this issue should address that https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1882774 | 19:34 |
| mup | Bug #1882774: issues with secondary VMX execution controls <sts> <verification-done> <verification-done-focal> <Ubuntu Cloud Archive:New> <qemu (Ubuntu):Fix Released> <qemu (Ubuntu Focal):Fix Committed> <https://launchpad.net/bugs/1882774> | 19:34 |
| ijohnson | thanks cachio, very interesting | 19:36 |
| mup | Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156> | 19:56 |
| mup | Bug #1874156 opened: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156> | 20:05 |
| mup | Bug #1413410 changed: Unable to match embedded NULLs in unix bind rule for abstract sockets <aa-kernel> <aa-parser> <AppArmor:Fix Released by jjohansen> <AppArmor 2.9:In Progress> <Snappy:Invalid> <apparmor (Ubuntu):Fix Released> <https://launchpad.net/bugs/1413410> | 20:08 |
| mup | Bug #1874156 changed: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Fix Released by morrisong> <https://launchpad.net/bugs/1874156> | 20:08 |
| ijohnson | cachio: interesting, another nested uc20 w/ assertions enabled failed due to all the random reboots, but it never got through to run mode: https://pastebin.ubuntu.com/p/4ggsB5mbhY/ | 20:09 |
| cachio | ijohnson, let me try with the qemu from proposed | 20:14 |
| cachio | that could contains a fix | 20:15 |
| mup | PR snapcraft#3185 closed: cli: allow promoting from edge without --yes <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3185> | 20:35 |
| ddstreet | hi all, anyone know if snaps are building and/or providing dbgsyms yet? or is that still a future item? | 20:38 |
| ijohnson | hi ddstreet what's been recently implemented is support for gdbserver, where a gdbserver will be run from inside a snap's confinement such that you can then connect from outside snap confinement to that gdbserver to debug the snap | 20:46 |
| ijohnson | ddstreet: that will allow you to have dbgsysm exist on the host outside of the snap and debug the snap | 20:46 |
| ijohnson | there's a forum post about this here: https://forum.snapcraft.io/t/new-experimental-snap-run-experimental-gdbserver-option/18227 | 20:47 |
| ddstreet | ijohnson thanks! and are snaps now built with dbgsyms included? | 20:48 |
| ijohnson | ddstreet: that is up to each snap, most are not built with dbgsyms afaik | 20:48 |
| ddstreet | hmm ok, so do you know if at least canonical-provided snaps include dbgsyms? e.g. chromium? | 20:49 |
| ddstreet | or any documented way to tell if a snap includes dbgsym? | 20:49 |
| mup | PR snapd#8912 opened: tests: update unity app on nightly test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8912> | 20:49 |
| ijohnson | ddstreet: there is no documented way to tell if a snap includes dbgsym outside of just looking at it | 20:49 |
| ijohnson | ddstreet: why do you ask ? | 20:49 |
| ddstreet | more recently there's an email to ubuntu-devel-discuss asking how to debug chromium, and it was pointed out it's a snap now, which led to discussion about not being able to debug snaps | 20:51 |
| ddstreet | but more in general, i'm part of canonical sustaining engineering, and it's something that we are going to face at some point in the very near future | 20:51 |
| ijohnson | ddstreet: right so today you have both snap run --gdb chromium, which will run gdb inside snap confinement, but then you can't load debug symbols without modifying the snap to include those | 20:52 |
| ijohnson | ddstreet: that is helped by gdbserver, but where we still fall short is that we don't have equivalent debug symbol snaps that could be uploaded alongside the actual running snap | 20:53 |
| ijohnson | ddstreet: not sure if that's currently on the roadmap, but I know that's been discussed to have a new snap type just for debug symbols to be produced at the same time | 20:53 |
| jdstrand | roadmr: hey, in case you didn't see in the bug comment from 30 seconds ago, 20200623-2050UTC has the riscv64 update | 20:54 |
| roadmr | jdstrand: oh I didn't :) | 20:54 |
| jdstrand | roadmr: if you can pull whenever it makes sense for you, that would be great | 20:54 |
| roadmr | I'll queue it up! | 20:54 |
| jdstrand | thanks :) | 20:54 |
| * roadmr checks time | 20:55 | |
| jdstrand | xnox: fyi (and thanks again) | 20:55 |
| roadmr | just enough time to land/QA today so maybe it can be deployed tomorrow | 20:55 |
| jdstrand | xnox: ^ | 20:55 |
| roadmr | I'm off tomorrow but the awesome team might deploy | 20:55 |
| jdstrand | cool | 20:55 |
| mup | PR snapcraft#3173 closed: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173> | 21:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!